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?

Unknown-BTS TRAU-UL captures from 2020¶

There is a set of TRAU-UL captures in libosmo-abis repository (added by laforge in 2020, although there is no notation as to which BTS make & model they came from); examination of these captures 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.

Nokia InSite¶

As of 2024-08, there is a Nokia InSite BTS at Themyscira development HQ, and we got 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.

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.

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.

Interaction with SID frames¶

What happens if an E1 BTS uses the buffer method, emits previous buffer content when it needs to put out BFI with no data, but that buffer content happens to be a bit pattern that would be classified as SID? With BFI flag set, the distinction between valid and invalid SID disappears (both are to be treated as invalid SID by the Rx DTX handler), but when the BFI condition is "nothing received" rather than "received corrupted SID", the Rx DTX handler needs to be told "unusable frame" rather than "invalid SID". What do real E1 BTS actually do in this situation?

Thankfully, the captures we got from Nokia InSite answer this question. In these captures (both FRv1 and EFR) there are some BFI=1 frames whose payload bit pattern would be classified as SID=1 by the bit-counting rules of GSM 06.31 & 06.81, yet the frame metadata flags indicate SID=0. The location of these frames in the UL stream and the signature corruption in the bit pattern indicate that these frames are cases of BFI-no-data output from the BTS. Thus we know what an E1 BTS does in this case: it transmits BFI=1 SID=0 in TRAU-UL frame metadata bits irrespective of the buffer-method bit content.

Implications for TW-TS-001 support¶

Functions that convert received Abis UL frames from the TRAU-UL format of GSM 08.60 into TW-TS-001 RTP format need to be aware of this quirk. Because SID classification rules for FRv1 and EFR (unlike HRv1) are fixed by GSM specs and because there was no room to add two more metadata bits, the out-of-band SID classification bits of GSM 08.60 TRAU-UL format (C13 & C14) are not included in the extended RTP payload format of TW-TS-001 - instead the receiver is expected to reconstruct this classification by calling osmo_{fr,efr}_sid_classify(). But what if these overhead bits in the received TRAU-UL frame don't match the payload bit content, as happens in this one special case? The conversion function needs to detect this case and handle it specially. There are two possible solutions:

1. Convert this TRAU-UL frame into BFI-no-data rather than the usual case of BFI-with-data.
2. Modify the payload bits (i.e., the deemed-bad frame payload bits sent along with BFI=1) so that the resulting frame would classify as non-SID. Forcing an arbitrarily chosen subset of 16 SID field bits (out of the total of 95) to 16 ones in the case of FRv1 or 16 zeros in the case of EFR would do the trick.

A patch for these conversion functions in libosmo-abis is coming soon.