osmo-e1d¶
The envisioned osmo-e1d is a daemon that handles Osmocom E1 interfaces. Its main tasks are:
- communicate with each E1 line hardware interface via USB USB_Protocol (or UDP/IP)
- provide a per-timeslot interface towards the users (such as OsmoBSC and OsmoMGW
- likely unix domain socket based, so libosmo-abis and friends can keep their "one FD per
- provide some kind of interface by which the user application can
- perform line/interface based operations
- enumerate the list of available interfaces/lines
- obtain status information (LOS, Alarm, CRC4 errors, etc) on each line
- timeslot based
- claim/release individual timeslots
- enable/disable Rx/Tx of individual timeslots (could be implicit in claim?)
- switch individual timeslots between raw and HDLC/CRC mode
- obtain timeslot status information such as CRC16 errors, frame errors, ...
- perform line/interface based operations
- implement any internal handling required, such as
- perform tasks not implemented by the adapter hardware/firmware (CRC4 tx / rx, multiframe alignment, LOS / ALRM / state machines)
- implement HDLC on each requested timeslot
User point of view¶
A user application would be interested in performing the following operations:
- obtain a list of lines/interfaces
- obtain a list of timeslots at a given line/interface, including availability status
- select/open a given timeslot on a given line
- enable/disable a given timeslot
- switch mode (raw/hdlc) of a given timeslot
- obtain line status information like local/remote CRC4 / LOS / ALARM
- receive data from a given TS
- transmit data on a given TS
Flow Control¶
Ideally we'd want to make the writer to a timeslot-fd block until more data can be sent via the E1 device. In DAHDI/mISDN, that's easy as their drivers are part of the kernel which can mark file descriptors/sockets as write-able at arbitrary times.
If we're using sockets or pipes between the application and osmo-e1-daemon, we have to see what kind of buffering those mechanisms have built-in. running a small (attached) test program renders:
socketpair: tx_buf 1: written 4480 of 1048576 socketpair: tx_buf 2: written 4480 of 1048576 socketpair: tx_buf 4: written 4480 of 1048576 socketpair: tx_buf 8: written 4480 of 1048576 socketpair: tx_buf 16: written 4480 of 1048576 socketpair: tx_buf 32: written 4480 of 1048576 socketpair: tx_buf 64: written 4480 of 1048576 socketpair: tx_buf 128: written 4480 of 1048576 socketpair: tx_buf 256: written 4480 of 1048576 socketpair: tx_buf 512: written 4480 of 1048576 socketpair: tx_buf 1024: written 4480 of 1048576 socketpair: tx_buf 2048: written 4480 of 1048576 socketpair: tx_buf 4096: written 8064 of 1048576 socketpair: tx_buf 8192: written 16256 of 1048576 socketpair: tx_buf 16384: written 32640 of 1048576 socketpair: tx_buf 32768: written 65408 of 1048576 socketpair: tx_buf 65536: written 146176 of 1048576 socketpair: tx_buf 131072: written 292352 of 1048576 socketpair: tx_buf 262144: written 548160 of 1048576 socketpair: tx_buf 524288: written 1048576 of 1048576 pipe: tx_buf 0: written 65536 of 1048576
so on an x86_64 system with a 4.15 kernel, the minimum transmit buffer is 4480 bytes. so we will have up to 4480 bytes (equalling 560 milliseconds at a 64kBps E1 timeslot) in the transmit buffer of the application side, before it starts to block writes. This is unfortunately not very useful, as half a second of buffering in audio telephony is not acceptable. That's more than a geostationary satellite :/
Updated by laforge almost 6 years ago · 2 revisions