30 Apr
2024
30 Apr
'24
12:35 a.m.
Hello fellow retronetworkers,
For a long time I've been looking to get my hands on a traditional GSM
TRAU, a hardware converter from 16 kbit/s (or 8 kbit/s in the case of
HR) speech channels going to a traditional T1/E1 BTS to full 64 kbit/s
PCM channels, complete with speech transcoding functions per classic
GSM specs. I started this search about this time last year, but now I
am getting a little closer: I just sent a payment to Shields
Environmental, a surplus telecom equipment dealer recommended to me by
Harald, for a set of old Nokia parts that should be enough to put
together a minimal Nokia TCSM2 system. There will be some more waiting
(they still need to pack and ship my order, and then I will need to
wait for it to arrive), but it looks like I will have a new toy soon!
TCSM stands for Transcoder and Submultiplexer, which is Nokia's term
for the bank of TRAUs that sits between the MSC and the BSC in the
traditional E1-based architecture. Apparently there were 3 generations
of Nokia TCSM, with TCSM2 being the middle one. For each of these 3
generations, a "proper" TCSM installation was a giant cabinet full of
units, which is obviously *not* what I am going for in my lab - instead
I ordered just enough parts to put together the most minimal config
that is possible in TCSM2 architecture: one TC1C chassis (coming in
the present order) and one ET1TC chassis (to be ordered later).
A single "unit" of TCSM2 handles one E1 line on the Ater interface,
the i/f between the transcoding site and the BSC. If this one-E1 Ater
is used to its full capacity, it expands to 4 E1s toward the MSC with
full rate channels, or to 7 E1s with HR channels. In theory the
maximal expansion is one E1 on Ater to 8 E1s on A with HR, but TCSM2
supports a maximum of 7 A-interface E1s for each "unit" handling a
single Ater E1. However, for lab hackers like me who aren't interested
in maximum capacity, the minimal config for TCSM2 is one E1 on Ater,
one E1 on A, two TR16 transcoder cards, and a maximum of 30 simultaneous
call legs.
For this one "unit" of TCSM2, there is one TC1C chassis that hosts one
TRCO card (the main controller), from 2 to 14 TR16 cards (I am getting
the minimal two), and the power supply that takes in -48 VDC. There
is also the ET1TC chassis that holds "exchange terminal" T1/E1 cards;
I will later need to buy this chassis and one 2xE1 card from the same
dealer.
According to the docs I found, the TRCO card (the head of a TCSM2 unit)
has an RS-232 port for local management, and supposedly it is possible
to configure the unit autonomously in this manner. It normally "wants"
to be controlled from the BSC via some LAPD-based proprietary protocol
on an Ater timeslot, but it looks like Nokia also provided for "test"
operation with neither BSC nor MSC present, for which all basic settings
can be configured via that local RS-232 port. This latter mode of
operation is what I seek, as I don't have any T1/E1 MSC or BSC hardware,
nor do I seek to acquire any currently.
My intent is to connect both one-E1 A and one-E1 Ater interfaces to a
"play" machine with a dual E1 interface (either icE1usb or a Digium
card, TBD), and bring individual TRAU channels to life by feeding
TRAU-UL frames of the desired codec type (as if coming from a
freshly-brought-up TCH on a BTS) to sub-timeslots on the Ater interface.
Then see what comes out on the A interface, feed some PCM input to A
and observe Ater DL output, etc.
One big uncertainty is TFO, the in-band bit-stealing protocol inside
64 kbit/s PCM speech channels defined in GSM 08.62, later 3GPP TS 28.062.
I *really* want to play with TFO, and the hope of getting a TFO-capable
one is the main reason I just spent a ton of money on this TRAU gear.
However, it appears that TFO was an "optional" feature on TCSM2, along
with several other "optional" features like AEC and voice AGC - features
that go beyond ETSI- or 3GPP-specified standard functionality for TRAUs.
It appears that "back in the day" customers had to pay a little extra
to Nokia to get these "optional" features, but it is not clear to me
how the restriction was implemented. Did they have different firmware
versions with these features included or excluded? Or was it some kind
of license key entry system? In any case, I *really* hope that the
TRCO and TR16-S cards I just paid a ton of money for will arrive with
TFO-capable firmware in them, such that the actual feature can then be
enabled or disabled with configuration commands on the RS-232 management
port as documented...
To be continued,
Mother Mychaela