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

Hi Harald,

The E1 chip has a global clock that is used to clock both TX and RX 
path. The RX path has a jitter buffer, but if received clock drifts 
away, the jitter buffer underruns/overflows and will be reset to its 
center. The clock is retrieved from the RX clock (TE mode) or internal 
crystal (NT mode). Clocks source can be altered by module parameters. If 
multiple E1 controllers are connected via PCM bus, the first controller 
is the clock master and the others are clock slaves. In a PBX system, 
the first controller (master) must be connected to an E1 phone line, so 
the complete system is clocked from that line. If multiple phone lines 
are used, they must have the same clock source (same provide), but may 
jitter. Therefore each RX path has a jitter buffer.

As stated above, the E1 controller connected to a phone line (provider) 
syncs to the line's clock. The TX path of the E1 uses this clock to 
transmit back to the phone provider. This way the phone provider 
receives data with the same clock as it transmits, so this is always the 
same clock source.

PH_DATA_CNF can be used to clock PH_DATA_REQ. When the data 
(PH_DATA_REQ) fits into the TX FIFO, a confirm (PH_DATA_CNF) will be 
replied by the drive immediately. If not, the confirm will be replied as 
soon as all pending data (from last PH_DATA_REQ) was written into the 
FIFO. The latency depends on the FIFO size, which is 383 samples, iirc. 
The application should activate a channel, transmit the first data 
(PH_DATA_REQ) and then add next data for every PH_DATA_CNF. This works 
with circuit switched (B-Channel) and packet switched (D-Channel/HDLC) 
data. For circuit switched data, I suggest to use 64 or 128 samples per 
request.

Best regards,

Andreas



On 12.05.2018 16:59, Harald Welte wrote:
> 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
>