TCSM2 timing structure¶

Hierarchical timing in TDM-based GSM¶

The TDM-based GSM architecture in which Nokia TCSM2 constitutes just one component (sitting between MSC and BSC) was designed to work with hierarchical timing: each network element normally synchronizes itself to its upstream, i.e., to the network element just above it in the hierarchy, instead of operating with a free-running clock. (If a network element operates with its own free-running clock, no matter how stable, its interoperation with other network elements becomes plesiochronous, which is the opposite of hierarchical timing.) In the hierarchical timing architecture, the TCSM synchronizes ("slaves") its timing to that received from the MSC, the BSC synchronizes its timing to that received from the TCSM (ultimately coming from the MSC by way of TCSM), and the BSC then passes this network timing to the individual BTSes which use their incoming E1 timing for everything, including RF carrier generation. (Presumably the MSC likewise synchronizes itself to higher-order timing coming from the fixed, non-mobile PSTN, but this part is out-of-scope for BSS and TCSM timing.)

How Nokia TCSM2 does hierarchical timing¶

For each "unit" of TCSM2, there are between 1 and 7 E1 circuits going to the MSC (A interface) and one E1 circuit going to the BSC (Ater interface). TCSM2 is able to synchronize ("slave") its timing block to any of the MSC-side E1 circuits (one can configure the priority order as to which E1 circuit's timing takes precedence, with lower-priority circuits acting as fallback timing sources when the preferred one is down); once the timing block inside TCSM2 is synchronized to a particular E1 input, all E1 outputs from that TCSM2 unit (the Ater output and all outputs toward the MSC) follow that timing. The BSC is expected to obey the timing from the TCSM, and to talk back to TCSM with that timing. The practical implications are:

• Whichever MSC-side E1 circuit is selected as the timing master, the TCSM2 unit effectively acts as a loop-timed slave on that E1;
• The timing derived from the "master" E1 circuit is used to drive the timing on all other E1 outputs from the same TCSM2 unit;
• All other E1 inputs to that TCSM2 must follow the same timing as the chosen master, otherwise E1 frame streams taken from those inputs will be subject to slips.

Implications for a lab setup¶

In a lab setup that has neither an MSC nor a BSC, but instead connects both A and Ater E1 interfaces out of TCSM2 to a test rig, that test rig needs to meet the following requirements:

• It needs to be a timing master, i.e., it must not take its timing from the connected TCSM2 unit;
• The two E1 outputs from the test rig must have the same timing, or derive their timing from a common source.

In the current state of retronetworking (mid-late 2024), the easiest way to satisfy these requirements is to use icE1usb as the interface device, and to use both E1 ports on that adapter (which obey the icE1usb device's internal timing, ideally GPS-disciplined) to connect A and Ater. The host driving the icE1usb will need to be one of the few that can operate both E1 ports, such as RPi5 - getting a dedicated RPi5 for this purpose may be the easiest and least expensive solution.

Plesiochronous alternative¶

It is also possible to configure the timing block of TCSM2 to operate free-running, not synchronizing itself to any of the E1 inputs. The resulting operation is then plesiochronous, with the following caveats:

• To avoid slips, other elements connected to A and Ater interfaces would have to slave themselves to the timing emitted by the TCSM2;
• If the equipment on the other end of a connected E1 circuit drives its own timing (true plesiochronous operation), the frame stream taken from that E1 interface will be subject to slips.

Hypothetically speaking, an alternative lab setup would be to configure TCSM2 for plesiochronous operation, then on whatever E1 interface devices are used to talk to this TRAU, configure loop timing - in this setup there would be no slips. However, the timing stability will be that of Nokia's TCXO (see below); in contrast, the preferred configuration of icE1usb as the timing master would run on GPSDO timing, which is the best timing attainable in a low-budget lab.

Hardware implementation inside TCSM2¶

The timing master inside TCSM2 is a TCXO on the TRCO board. This TCXO is a large and prominent component, a metal can measuring 36x27 mm, 10 mm high, with these markings:

DFA 36-TR
16.384 MHz
A36060 0049

At first glance I thought this component is an OCXO, based on the large size of the can. However, the preponderance of evidence points toward this component actually being a TCXO:

• No datasheet could be found for this exact part, but there is a datasheet for other members of DFA 36 family that shows a TCXO with the same dimensions and pin arrangement;
• Web search for "DFA 36-TR" shows some sellers carrying this part (sans datasheet), and they describe it as a TCXO;
• The oscillator can on the TRCO board remains cool to the touch after running for half an hour, which is more consistent with TCXO than OCXO.

It seemed strange to me at first that Nokia used a TCXO rather than an OCXO for what appears to be a critical timing element in TDM-based GSM infrastructure - but remember that this TCXO is not meant to be free-running. In normal operation this TCXO will be steered via the DAC (see below) to match timing that comes from the MSC, and there is no significant holdover requirement: if all E1 links from a given TCSM2 unit to its parent MSC go down, that TCSM2 unit is unusable, and if a BSC loses all MSC connections (passing through TCSM units), that BSC and all of its BTSes will also become unusable. Hence there is no use case in which a BSC or TCSM needs to maintain holdover timing in the absence of a good link to an MSC - and if an MSC link is up, that link can be the timing source.

Next to the TCXO on the TRCO board there is a MAS9316N DAC - it is a 16-bit DAC that steers the voltage-controlled TCXO. In plesiochronous mode, the operator can manually set the control word for this TCXO DAC; in normal hierarchical operation, this DAC is programmed to steer the TCXO to match the timing that comes on the E1 circuit selected as the timing master.

On the interface from TRCO to Exchange Terminal modules, there are global clock outputs from TRCO (8.192 MHz clock and 8 kHz frame sync) that are wired in parallel to all ET module slots, there is a dedicated bidirectional data interface to each ET module, and there are two 8 kHz clock signals from the ET module to TRCO, one for each E1 circuit - the latter clocks are derived from incoming E1 timing and are used by TRCO to do clock disciplining.