No-data output » History » Revision 3
Revision 2 (falconia, 07/20/2024 08:39 PM) → Revision 3/4 (falconia, 08/15/2024 12:23 AM)
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 strongly suggests that matches a previous frame, either exactly (EFR) or with a very specific corruption (FRv1). These frames serve as evidence that whatever E1 BTS emitted this TRAU-UL output used them uses what I (@falconia) call 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 method. In 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 so-called 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 method, 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. Unfortunately however, those 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 were 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 DTXu disabled, hence there are no SID frames. We need to "regular" BFI conditions on blocks that were decoded as speech, and one can clearly see that do additional experiments with DTXu enabled, seeking answers not only to the payload buffer receives new bits every time speech-not-FACCH decoding was invoked (whether the result was good or bad), mystery of [[DTXu half-blocks]], but retains previous bit content otherwise. In the case of TRAU-UL output from E1 BTS, we don't have direct evidence as also to whether or not each given frame results from this question: when the BTS having received FACCH (or receives 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 all 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 it 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 proper SID block followed by 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 half-block, what 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 payload bits in the Abis subsequent BFI=1 TRAU-UL frame get overwritten with constant values. At first glance output? If these 4 corrupted payload bits are scattered throughout remain equal to the frame, but a closer look reveals that they are the last four class 2 bits in GSM 05.03 received valid SID, or perhaps equal to channel coding decoder output from half-block Rx (which will likely still have a bit order. It is plausible pattern that looks like valid SID!), what does the internal buffer in this unknown BTS model stores the frame emit in GSM 05.03 bit order (just like Calypso DSP), and it is reordered to the "natural" codec bit order at the point bits C13 & C14 (SID classification status) of Abis output. The corruption that appears in those "dummy" TRAU-UL output is equivalent frames? Answers to what would be produced if the last 4 bits of TI's DSP buffer were overwritten with @4'b1001@. this question matter for: 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 * Correct logic for turning TRAU-UL frames into [[ThemWi_RTP_Extensions|TW-TS-001]] when interfacing an E1 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 to an Osmocom-based RAN; * [[TFO]] implementation, namely, correct conversion between TW-TS-001 on the last channel-decoded frame (good or bad) RTP leg and the subsequent "no data" output. FIXME: describe this corruption pattern. TFO frames.
