LaForge's home page (Posts about teleocm)https://laforge.gnumonks.org/blog/categories/teleocm.atom2022-09-18T21:29:46ZHarald WelteNikolaClock sync trouble with Digium cards and timing cableshttps://laforge.gnumonks.org/blog/20220906-digium_timing_cable_troubles/2022-09-09T00:00:00+02:002022-09-09T00:00:00+02:00Harald Welte<p>If you have ever worked with Digium (now part of Sangoma) digital
telephony interface cards such as the TE110/410/420/820 (single to octal
E1/T1/J1 PRI cards), you will probably have seen that they always have a
<em>timing connector</em>, where the timing information can be passed from one
card to another.</p>
<p>In PDH/ISDN (or even SDH) networks, it is very important to have a
synchronized clock across the network. If the clocks are drifting,
there will be underruns or overruns, with associated phase jumps that
are particularly dangerous when analog modem calls are transported.</p>
<p>In traditional ISDN use cases, the clock is always provided by the
network operator, and any customer/user side equipment is expected to
synchronize to that clock.</p>
<p>So this Digium timing cable is needed in applications where you have
more PRI lines than possible with one card, but only a subset of your
lines (spans) are connected to the public operator. The timing cable
should make sure that the clock received on one port from the public
operator should be used as transmit bit-clock on all of the other ports,
no matter on which card.</p>
<p>Unfortunately this decades-old Digium timing cable approach seems to
suffer from some problems.</p>
<section id="bursty-bit-clock-changes-until-link-is-up">
<h2>bursty bit clock changes until link is up</h2>
<p>The first problem is that downstream port transmit bit clock was jumping
around in bursts every two or so seconds. You can see an oscillogram of
the E1 master signal (yellow) received by one TE820 card and the
transmit of the slave ports on the other card at
<a class="reference external" href="https://people.osmocom.org/laforge/photos/te820_timingcable_problem.mp4">https://people.osmocom.org/laforge/photos/te820_timingcable_problem.mp4</a></p>
<p>As you can see, for some seconds the two clocks seem to be in perfect
lock/sync, but in between there are periods of immense clock drift.</p>
<p>What I'd have expected is the behavior that can be seen at <a class="reference external" href="https://people.osmocom.org/laforge/photos/te820_notimingcable_loopback.mp4">https://people.osmocom.org/laforge/photos/te820_notimingcable_loopback.mp4</a> - which shows a similar setup but without the use
of a timing cable: Both the master clock input and the clock
output were connected on the same TE820 card.</p>
<p>As I found out much later, this problem only occurs until any of the
downstream/slave ports is fully OK/GREEN.</p>
<p>This is surprising, as any other E1 equipment I've seen always transmits
at a constant bit clock irrespective whether there's any signal in the
opposite direction, and irrespective of whether any other ports are
up/aligned or not.</p>
<p>But ok, once you adjust your expectations to this Digium peculiarity,
you can actually proceed.</p>
</section>
<section id="clock-drift-between-master-and-slave-cards">
<h2>clock drift between master and slave cards</h2>
<p>Once any of the spans of a <em>slave</em> card on the timing bus are fully
aligned, the transmit bit clocks of all of its ports appear to be in
sync/lock - yay - but unfortunately only at the very first glance.</p>
<p>When looking at it for more than a few seconds, one can see a slow,
continuous drift of the <em>slave</em> bit clocks compared to the <em>master</em> :(</p>
<p>Some initial measurements show that the clock of the <em>slave</em> card of the
timing cable is drifting at about 12.5 ppb (parts per billion) when
compared against the <em>master</em> clock reference.</p>
<p>This is rather disappointing, given that the whole point of a timing cable
is to ensure you have <em>one</em> reference clock with all signals locked to
it.</p>
</section>
<section id="the-work-around">
<h2>The work-around</h2>
<p>If you are willing to sacrifice one port (span) of each card, you can
work around that slow-clock-drift issue by connecting an external
loopback cable. So the <em>master</em> card is configured to use the clock
provided by the upstream provider. Its other ports (spans) will transmit
at the <em>exact</em> recovered clock rate with no drift. You can use any of
those ports to provide the clock reference to a port on the <em>slave</em>
card using an external loopback cable.</p>
<p>In this setup, your <em>slave</em> card[s] will have perfect bit clock
sync/lock.</p>
<p>Its just rather sad that you need to sacrifice ports <em>just</em> for
achieving proper clock sync - something that the timing connectors and
cables claim to do, but in reality don't achieve, at least not in my
setup with the most modern and high-end octal-port PCIe cards (TE820).</p>
</section>First steps towards an ITU-T V5.1 / V5.2 implementationhttps://laforge.gnumonks.org/blog/20211011-v52/2021-10-11T00:00:00+02:002021-10-11T00:00:00+02:00Harald Welte<p>As some of you may know, I've been starting to collect "vintage"
telecommunications equipment starting from analog modems to ISDN
adapters, but also PBXs and even SDH equipment. The goal is to keep
this equipment (and related software) alive for demonstration and
practical exploration.</p>
<p>Some [incomplete] information can be found at
<a class="reference external" href="https://osmocom.org/projects/retro-bbs/wiki/">https://osmocom.org/projects/retro-bbs/wiki/</a></p>
<p>Working with PBXs to simulate the PSTN (ISDN/POTS) network is fine to
some extent, but it's of course not the real deal. You only get
S0-buses and no actual Uk0 like actual ISDN lines of the late 80ies and
90ies. You have problems with modems not liking the PBX dialtone, etc.</p>
<p>Hence, I've always wanted to get my hand on some more real-world
central-office telephone network equipment, and I finally have a source
for so-called <a class="reference external" href="https://en.wikipedia.org/wiki/V5_interface">V5.1/V5.2</a>
access multiplexers. Those are like remote extension boxes for the
central office switch (like <a class="reference external" href="https://en.wikipedia.org/wiki/EWSD">EWSD</a>
or <a class="reference external" href="https://en.wikipedia.org/wiki/ITT_System_12">System 12</a>). They
aggregate/multiplex a number of analog or ISDN BRI subscriber lines into
E1 lines, while not implementing any of the actual call control or ISDN
signalling logic. All of that is provided by the actual telephone
switch/exchange.</p>
<p>So in order to integrate such access multiplexers in my retronetworking
setup, I will have to implement the LE (local exchange) side of the V5.1
and/or V5.2 protocols, as specified in ITU-T <a class="reference external" href="https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.964-200103-I!!PDF-E&type=items">G.964</a> and
<a class="reference external" href="https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.965-200103-I!!PDF-E&type=items">G.965</a>.</p>
<p>In the limited spare time I have next to my dayjob and various FOSS
projects, progress will likely be slow. Nonetheless I started with an
implementation now, and I already had a lot of fun learning about more
details of those interfaces and their related protocols.</p>
<p>One of the unresolved questions is to what kind of software I would want
to integrate once the V5.x part is resolved.</p>
<ul class="simple">
<li><p><a class="reference external" href="http://linux-call-router.de/">lcr</a> would probably be the most
ISDN-native approach, but it is mostly unused and quite EOL.</p></li>
<li><p>Asterisk or FreeSWITCH would of course be obvious candidates, but they
are all relatively alien to ISDN, and hence not very transparent once
you start to do anything but voice calls (e.g. dialup ISDN data calls
in various forms).</p></li>
<li><p><a class="reference external" href="http://yate.null.ro/">yate</a> is another potential candidate. It
already supports classic SS7 including ISUP, so it would be a good
candidate to build an actual ISDN exchange with V5.2 access
multiplexers on the customer-facing side (Q.921+Q.931 on it) and
SS7/ISUP towards other exchanges.</p></li>
</ul>
<p>For now I think yate would be the most promising approach. Time will
tell.</p>
<p>The final goal would then be to have a setup [e.g. at a future CCC
congress] where we would have SDH add/drop multiplexers in several
halls, and V5.x access multiplexers attached to that, connecting analog
and ISDN BRI lines from individual participants to a software-defined
central exchange. Ideally actually multiple exchanges, so we can show
the signaling on the V5.x side, the Q.921/Q.931 side and the SS7/ISUP
between the exchanges.</p>
<p>Given that the next CCC congress is not before December 2022, there is a
chance to actually implement this before then ;)</p>