Hardware Projects » E1/T1 Hardware Interface (including icE1usb) » osmo-e1d

h1. 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, ...

# 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

h2. 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

h3. 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:

<pre>

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

</pre>

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 :/