Report on the GSM network in Tijuana

[Mychaela Falconia]

Hello FreeCalypso community,

A little over a week ago I and my SO made a cross-border visit to
Mexico for the specific purpose of more thoroughly exploring that
lovely country's GSM network.  (MCC=334, MNC=020, Name=Telcel.)  A
basic report on this visit is posted here:

https://www.reddit.com/r/vintagemobilephones/comments/14vm1g8/the_land_of_milk_honey_and_2g_part_2/

and here are more technical details which our much more technical
community will likely find interesting:

* They do have a bigger spectrum allocation for GSM than in USA: at
least in Tijuana Telcel has a 5x5 MHz block (5 MHz DL, 5 MHz UL) in
the PCS1900 band allocated to GSM, to be contrasted with T-Mobile USA
operating GSM in front and back guard bands around their 15 MHz LTE
signal.  However, all Mexican GSM cells we've experienced are still
single-carrier, i.e., each cell is just the BCCH carrier and nothing
more.  I remember Vadim telling me that in at least one of his two
home countries (not just if it's RU or KZ) there are still commercial
operators who operate GSM with frequency hopping, which implies cells
with more than just the BCCH carrier; I was hoping to find the same in
Mexico, but nope, no such luck.

* The network-imposed order of preference for voice codec selection is
the same as on T-Mobile USA:

- If the MS supports AMR, the network selects AMR-HR;

- If the MS does not support AMR but does support EFR, the network
selects EFR;

- If the MS supports neither AMR nor EFR, the network selects FRv1;

- HRv1 appears to not be used ever - I couldn't coax the network into
assigning such TCH.

* The G.711 backhaul interface to PSTN appears to be A-law (copying EU
telecom culture) rather than mu-law like in USA.

How did I observe that A-law backhaul?  Answer: I was making test calls
from my home server to my Mexican Telcel +52 phone number via Anveo,
and following what seemed like a law of chance, it would pick different
routes.  One of the routes definitely appeared to be transcoded and
compressed along the way - I need to figure out a way to reject such
routes, no problem with paying more for proper transparent ones - but
the other route showed all signs of being a transparent one.

My sip-manual-out test program would send out its INVITE with an SDP
offer listing both PCMU and PCMA codecs, in this order of preference.
When calling +1 destinations, the answer always comes back with PCMU
selected; ditto with the compressed and transcoded route to +52 which
I need to reject.  However, on tries when I got the good route to the
+52 Telcel GSM destination, the answer was PCMA, a codec which my SDP
offer listed as non-preferred - a definite indication that PCMA is
native for the Mexican network.

During that Tijuana visit I had my Telcel SIM in a Pirelli DP-L10
phone, and for my experiments I ran RAM-based FreeCalypso VPM firmware
controlled via rvinterf and fc-shell.  I used my recently implemented
AT%SPVER command to artificially restrict the speech version list sent
to the network in the Bearer capability IE, and by doing so I coaxed
the network into giving me EFR instead of AMR.  Once I got the call
connected with EFR on the destination GSM leg and PCMA on the VoIP leg
back to my home server, I used the TCH UL play feature of Calypso DSP
(tch play command in fc-shell) to play a particular crafted sequence
of EFR codec frames into the UL of the test call; this test sequence
included spec-defined decoder homing frames.  And sure enough, I saw
the expected results in the PCMA RTP stream received by my home server:
wherever I sent two back-to-back DHFs in GSM UL, the RTP stream
featured a run of 160 0xD5 octets (EHF turned into PCMA), and the
subsequent frames matched the expected output of the EFR decoder
turned into PCMA.  Thus I got evidence confirming my hunch that the
connection is indeed byte-transparent from my calling server to the
edge transcoder of Telcel GSM network.

There is an additional quirk with networks using PCMA instead of PCMU.
When the G.711 PSTN side is PCMU, the speech encoder in GSM DL
direction normally won't send homing frames unless the G.711 source on
the far end is explicitly sending 0xFE octets, which won't happen on
its own - PCMU silence is 0xFF, but making the GSM speech encoder see
EHFs on its input requires 0xFE in PCMU.  But with PCMA it is
different: a silent PCMA channel is 0xD5 octets, and these same 0xD5
octets turn into 0x0008 in 16-bit linear PCM form - and that's an
encoder homing frame!  Thus when the PCMA input to a GSM speech encoder
is total silence, that encoder will be emitting a continuous stream of
homing frames instead of going into DTX - but change 0xD5 to 0x55
(change from the smallest positive to the smallest negative sample,
smallest in absolute value), and the GSM speech encoder starts doing
DTX.  I observed this behavior in my test calls, confirming that the
path in this direction can be byte-transparent too.

But despite all this evidence of a transparent G.711 connection, I
couldn't get TFO.  No TFO in-band signaling (IS) messages are seen in
the PCMA sample stream coming from the GSM network's edge TC, and when
I tried sending TFO_REQ IS messages in my outgoing G.711 sample stream
in RTP packets, no response was elicited.  Thus the hunt for a TFO-
supporting GSM network anywhere in the world, or a TFO-supporting TRAU
in the hands of some community members which I could play with
remotely, still continues.

Hasta la Victoria, Siempre,
Mychaela aka The Mother