AF_ISDN / RAW B-channels and different Rx/Tx Clocks

Harald Welte <[email protected]> Sat, 12 May 2018 16:59:54 +0200
Newsgroups gmane.linux.isdn.i4l.user
Message-ID <20180512145954.GH9313@nataraja>
Hi!

In the Osmocom project, in libosmo-abis, we have an E1 input driver for mISDN.

When using raw B-channels via mISDN, we use the following philosophy for timing our
transmits:

* Whenever we receive a PH_DATA_IND from the kernel about received data, we also
  send a PH_DATA_REQ back to the kernel

As it occurred to me recently, this might actually be problematic if the Rx and Tx
clock of the E1 link are not identical.  This is actually quite normal in a variety
of situations.  There is nothing in the E1 specs that I know of which would force
the Rx and Tx clocks to be somehow locked to each other.  Sure, there's
the general +/-50ppm accuracy, but that's it.  And if you intereconnect
between multiple clock domains (operators, PBXs, ...) , then of course
there will be some drift relative to each other.

So let's assume the Rx data is arriving at a slower clock than the clock at which we
transmit.  Over time, this will add up and at some point it will result
in a buffer underrun of the mISDN kernel code/driver, as it the hardware
will want to pull more bits for the given B-channel, but the application
code hasn't yet sent it, as it's send interval is locked to the receive
interval of PH_DATA_IND.

What is the proper solution here?  How can a userspace process use
AF_ISDN and time its PH_DATA_REQ independent of PH_DATA_IND on the Rx
side?  Thanks!


[1] http://git.osmocom.org/libosmo-abis/tree/src/input/misdn.c#n319

Regards,
	Harald

-- 
- Harald Welte <[email protected]>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)