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

Hi Andreas,

thanks a lot for your detailed feedback.

On Mon, May 14, 2018 at 02:49:05PM +0200, Andreas Eversberg wrote:

> The E1 chip has a global clock that is used to clock both TX and RX path.

Ok, this is then a property of the specific chip[s] you are referring to.

I've studied a number of E1 LIU (Line Interface Units) some years ago as well
as more recently, and they all have separate clock domains for Rx and Tx:

* the recovered Rx clock (output from LIU towards framer)
* the Tx clock (provided by framer to LIU, but could of course also be fed
  from any other clock source, including the recovered clock).

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

so basically you're saying that the master clock of the E1 framer (HFC-E1 chip)
can be sourced either from the recovered Rx clock or generated by local XTAL,
but it will be either of the two. I see.

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

understood.

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

Ok, so there is a PH_DATA_CNF.  I had missed that, my apologies.  So in
libosmo-abis, we should probably use PH_DATA_CNF to clock the next
PH_DATA_REQ, rather than [ab]use the PH_DATA_IND (Rx of data) to trigger
a PH_DATA_REQ (tx of data)?

The background of my question is that we're currently designing a new
"software defined E1" interface within the Osmocom project.   There is a
large bulk of really interesting and rather modern GSM base stations
becoming available on the decomissioned/refurbished market for very low
cost.  However, the exsiting E1 interface cards (whether Digium+clones
or HFC-E1 based cards with mISDN support) are all rather expensive (more
expensive than the GSM BTS!) and require a PC with PCI or PCIe.

To the contrary, the Osmocom E1 adapter will be a small [primarily],
USB-attached device, which can be used with small embedded arm or x86
Linux boards (Raspi, BeagleBone, APU, ...).   We won't have any kernel
drivers for this E1 adapter, but will do "software defined E1" with all
the related code running in userspace.  However, I wanted to get the
clocking right, and was looking at mISDN.

In this use case, we always only have Abis interfaces, and we will
always only operate in NT mode, as the BTS is the TE.  The Tx clock
for the E1 will be generated by an on-board GPS-DO (as the BTS requires
highly accurate clock), and the Rx clock will be whatever clock the BTS
choses to use in the return direction.

In reailty I presume the BTS will use its received (i.e. our
transmitted) clock, or a clock derived from that.  However, I don't
think there is anything that guarantees this, so hence I was thinking
of situations where they are not derived from each other, and hence not
only phase but also frequency differences would accumulate.

For more information on this project, see
http://osmocom.org/projects/e1-t1-adapter/wiki and its sub-pages, as
well as https://media.ccc.de/v/BTB8WS

There's already some code to do the framing (FAS, CRC4, ...) in
userspace, see
http://git.osmocom.org/osmo-e1-xcvr/tree/src/osmo_e1.c?h=laforge/software
which has been verified against raw bitstream traces obtained by Dieter
using an osmo-e1-xcvr board attached to a STM32 evaluation board.

Meanwhile, Sylvain is working on a different approach, where there
isn't even any magnetics, and no LIU.  Instead, he's using some R/C
coupling to the E1 line, and feeding that into differential transceivers
of an ICE40 FPGA where he's implemented HDB3 decoding and clock
recovery.  This would be an even lower-cost approach due to not
requiring any magnetics, and no LIU.   Remember, we only want to drive
something like 1-2m of twisted pair from a BTS, and not any long-haul
lines.  Spec compliance also doesn't really matter..

To get back to the original question: I think I will likely also use
something as a PH_DATA_CNF from the transmitter back to the application
generating the data.  This allows Tx timing to be independent of Rx
timing, even if in practise it tends to match.

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)