Project

General

Profile

UL-to-DL transform » History » Version 1

falconia, 07/20/2024 12:01 AM

1 1 falconia
h1. UL-to-DL transform for classic GSM codecs
2
3
When each call leg is transcoded to G.711 by its respective [[TRAU]], the stream of frames sent toward GSM radio DL (TRAU-DL frames) is the output of a free-running speech encoder. In classic GSM design, this TRAU-DL frame stream is highly constrained: each frame position *must* be filled with either a good speech frame or (if DTXd is enabled) a valid SID frame - no other possibilities allowed. So what happens then if the stream of codec frames from leg A UL is fed directly to leg B DL, as happens in [[TFO]]? The stream of frames from leg A UL can contain BFI(Bad Frame Indication) frame gaps or reception errors, as well as both valid and invalid SID frames. How can such input be mapped to TRAU-DL output? Furthermore, call leg A may have DTX in the uplink (DTXu), while call leg B operates without DTXd (no DTX allowed on downlink) - how to resolve this potentially quite common situation?
4
5
The TFO spec devotes a few paragraphs to this problem: sections 8.2.1 and 8.2.2 in the original GSM 08.62 spec (up to Release 99), or section C.3.2.1.1 in the new TS 28.062 spec (from 3GPP Release 4 onward). However, both spec versions only say what "shall" be done without any guidance on how to do it algorithmically: the spec language is "subject to manufacturer dependent future improvements and is not part of this recommendation." Distilling the problem to its essence, the addition of TFO introduces a new type of logical transform on codec frames (and a stateful one at that!) that never appeared previously anywhere in classic GSM architecture, is not mentioned in any other spec, and is not addressed at all by any of the reference codec sources. This new transform is implemented only in the TFO block in TRAUs and nowhere else (in classic GSM architecture), and can be exercised only by establishing a TFO call between two interworking TRAUs.
6
7
h2. The difficulty of the problem
8
9
The fact that no specific bit-exact logic is prescribed in the specs may at first seem like a simplification - "I'll just do whatever is easiest" - but such reasoning would be flawed. The end goal of TFO is to establish the highest possible quality of voice path between Alice and Bob. In the case of single transcoding (a single codec leg between a type-approved, spec-compliant codec implementation in the MS and the spec-compliant transcoder implementation in the TRAU) the specs devote a lot of detail to exactly how comfort noise generation (in the case of DTX) and bad frame handling (always necessary) shall be done; some of these aspects are normative (bit-exact behavior match required for type approval), others are deemed non-normative examples, but still implemented with great care in the reference sources. When tackling the new problem of implementing UL-to-DL transform without any specific algorithmic guidance from the specs, the challenge is to design the algorithm in such a way that the result would be no worse (in terms of voice quality in the presence of comfort noise insertion and error concealment events) than what the specs provide in the case of a single transcoding - and this problem is very non-trivial.
10
11
h2. Applicability to new IP-based GSM networks
12
13
In the classic all-TDM GSM architecture, the UL-to-DL transform under consideration is needed only in TRAUs, and only if one chooses to implement TFO. However, in new IP-based GSM networks the exact same transform is needed in other places, which may not be immediately obvious:
14
15
# Interfacing E1 BTS to IP-based GSM RAN. Osmocom CNI allows such interfacing to be done with [[osmobsc:|OsmoBSC]] and its associated [[osmomgw:|OsmoMGW]], but this problem of UL-to-DL transform has not been addressed yet. When a legacy E1 BTS is lifted out of its native all-TDM environment and operated with Osmocom instead, E1-interfacing OsmoMGW takes the place of the TRAU as the source of TRAU-DL frames, and the incoming RTP stream takes the place of far-end TFO frames - hence the very same logical transform is needed.
16
# The path inside [[osmobts:|OsmoBTS]] from the incoming RTP stream to air interface DL is logically equivalent to the just-described case of OsmoMGW converting from incoming RTP to TRAU-DL output, hence a UL-to-DL transform is needed once again. However, in this case it is possible to cheat a little, as described later in this article.
17
18
h2. High hopes on Nokia TCSM2
19
20
Themyscira HQ undertook the high-cost project (in both time and money) of acquiring and bringing up a historical Nokia TRAU ([[Nokia TCSM2]]) in the hope of being able to see how at least one historical GSM equipment vendor implemented this very elusive TFO transform. This work is currently tracked in #6464. The TRAU is known to support TFO, based on playing with the management interface in the absence of E1 connections, hence the hopes are high.
21
22
h2. Shortcut in OsmoBTS
23
24
Since mid-2023, [[osmobts:|OsmoBTS]] implements a trick whereby one can take the RTP stream from call leg A and feed it to call leg B, and the result will be good even if call leg A has DTXu enabled. (In standard official terms, this type of cross-connection between call legs is called TrFO, not to be confused with TFO.) This trick is implemented despite not having any logic for true UL-to-DL transform - how is it possible?
25
26
The trick is that in OsmoBTS we control the BTS PHY directly (or directly-enough for this purpose, in the case of sysmoBTS proprietary PHY), and we can do a little more than what TRAU-DL standard interface allows. Experiments with sysmoBTS DSP PHY reveal that if we send it a zero-length payload from upper layers, the radio DL output is a bad-CRC block that induces a BFI(Bad Frame Indication) condition in the MS receiver. (The actual transmission is a block of all 0 bits, which is not the same as a valid FR/HR/EFR frame with all payload bits set to 0 because of CRC.) The same logic was then replicated in osmo-bts-trx, hence now all models have the ability to transmit an intentionally induced BFI on the downlink.
27
28
The ability to transmit induced BFIs means that when the incoming RTP stream encounters a BFI frame gap, we don't have to invoke the clever transform to fill that gap with ECU output - instead we can transmit an induced BFI in that frame position and let the spec-compliant Rx DTX handler in the MS do all of the hard work. We can also use the same capability to effect a kind of fake "logical DTXd" in the absence of physical DTXd: the physical radio DL transmitter remains on continuously, but we make the situation look like DTXd to the MS by transmitting induced BFIs in those frame positions where true DTXd would cut radio Tx. Translating from real DTXu on call leg A to this fake DTXd on call leg B is then as simple as repositioning SID frames, then aging and expiring them appropriately: the one part of UL-to-DL transform where TFO specs do say exactly what needs to be done.
29
30
When we finally fire up Nokia TCSM2 with TFO and see what it does, we'll be able to analyze how our hacky approach compares against Nokia's TRAU implementation in terms of resulting quality - but until then, we simply don't know.
Add picture from clipboard (Maximum size: 48.8 MB)