Retronetworking » Retro-GSM

h1. No-data output from BTS in TRAU-UL

The design of TDM-based Abis requires the BTS to emit _some_ traffic frame bits in every 20 ms position, rain or shine. When the BTS did receive some bursts which it attempted to decode as a traffic frame, but the result is not deemed to be a good traffic frame, the behavior is straightforward: emit whatever bits (garbage perhaps) that did come out of the channel decoder logic, and set BFI=1 to indicate a bad frame. But what if the BTS did not receive any bursts at all - perhaps the MS is in a DTXu pause, or hasn't started transmitting yet on a newly activated channel - what should the BTS emit in the payload bits in TRAU-UL? Likewise, what should it emit if the received block was decoded as FACCH rather than TCH?

h2. Unknown-BTS TRAU-UL captures from 2020

There is a set of TRAU-UL captures "in libosmo-abis repository":https://cgit.osmocom.org/libosmo-abis/tree/contrib/trau2rtp (added by @laforge in 2020, although there is no notation as to which BTS make & model they came from); "examination of these captures":https://www.freecalypso.org/hg/gsm-net-reveng/file/tip/doc/BFI-payload-fill reveals the following details:

* As expected for all E1 BTS work in Osmocom prior to @falconia joining, DTXu was disabled in the test setup from which these captures were taken. There are no SID frames present anywhere in these TRAU-UL captures, confirming this expectation.

* There are many places where BFI=1 frames appear with a bit pattern that matches a previous frame, either exactly (EFR) or with a very specific corruption (FRv1). These frames serve as evidence that whatever BTS emitted this TRAU-UL output used the buffer method (see below) in the case of FACCH stealing, and likely also in the case of receiving nothing at all during channel activation and shutdown.

h2. Nokia InSite

As of 2024-08, there is a Nokia InSite BTS at Themyscira development HQ, and we got [[InSite_UL_captures|a set of Abis UL captures]] from it. Unlike the old captures above, our test setup has DTXu enabled, hence we were able to observe how this BTS handles receiving SID frames and [[DTXu half-blocks]]. Interestingly enough, we don't see any "no data" output during DTXu pauses, or during channel activation and shutdown: apparently this BTS always runs its GSM 05.03 channel decoder and produces new "garbage" bits even when it is receiving background interference in the absence of transmission from GSM MS. However, we do see the distinct "signature" of the buffer method (see below) being used when this BTS receives FACCH.

h2. Buffer method used by many E1 BTS and TI Calypso DSP

It appears that many E1 BTS, including both models analyzed above, use the same buffer method that was first observed on TI Calypso DSP. The idea is that the Rx Radio Subsystem maintains a buffer into which the 05.03 channel decoder writes its output, and if no new traffic bits are received, the buffer retains its previous content which is then emitted on TRAU-UL in the case of E1 BTS, or can be read out of shared memory by debug-oriented firmware in the case of Calypso DSP. This so-called buffer method was first observed when analyzing MS-side TCH DL captures made with FreeCalypso tools - in that case it is plainly obvious because the DSP sets different flag bits in its @a_dd_0[0]@ status word when it received FACCH or nothing at all, compared to "regular" BFI conditions on blocks that were decoded as speech, and one can clearly see that the payload buffer receives new bits every time speech-not-FACCH decoding was invoked (whether the result was good or bad), but retains previous bit content otherwise.

In the case of TRAU-UL output from E1 BTS, we don't have direct evidence as to whether or not each given frame results from the BTS having received FACCH (or nothing at all) as distinct from "regular" BFI conditions, but there is still indirect (circumstantial) evidence of the buffer method being used. If there is a BFI=1 frame directly after a good (BFI=0) speech frame, and the bit pattern of that BFI frame is either an exact match to the bit content of the preceding good speech frame or a very peculiar pattern of corruption derived from the latter, the BFI frame is likely buffer output, and the BTS probably received FACCH in that frame position. If such patterns are observed consistently, then the evidence for the buffer method becomes strong enough in my opinion.

h3. Peculiar corruption patterns seen with some BTS

Some E1 BTS implement the buffer method (as I call it), but with a twist: the output in BFI-no-data frame positions is not an exact copy of the last received (fully channel-decoded) frame, but a corrupted version thereof, corrupted in some strange and peculiar way that is a signature of the specific BTS model in question. In the case of the unknown BTS model that produced the outputs that were added to libosmo-abis repository in 2020, the bit corruption patterns are as follows:

* In the case of EFR, there is no corruption: the emitted BFI-no-data frame exactly matches the last actually-decoded frame, good or bad.

* In the case of FRv1, 4 different bits in the Abis TRAU-UL frame get overwritten with constant values. At first glance these 4 corrupted bits are scattered throughout the frame, but a closer look reveals that they are the last four class 2 bits in GSM 05.03 channel coding bit order. It is plausible that the internal buffer in this unknown BTS model stores the frame in GSM 05.03 bit order (just like Calypso DSP), and it is reordered to the "natural" codec bit order at the point of Abis output. The corruption that appears in TRAU-UL output is equivalent to what would be produced if the last 4 bits of TI's DSP buffer were overwritten with @4'b1001@.

In the case of Nokia InSite, we see evidence of the buffer method being used only in the case of FACCH, not in the case of the BTS receiving background interference in the absence of Tx from GSM MS. However, in the case of FACCH, there is a very peculiar pattern of corruption seen between the last channel-decoded frame (good or bad) and the subsequent "no data" output. FIXME: describe this corruption pattern.