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?

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 strongly suggests that whatever E1 BTS emitted them uses what I (falconia) call the buffer method. In this so-called buffer method, 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 captures were made with DTXu disabled, hence there are no SID frames. We need to do additional experiments with DTXu enabled, seeking answers not only to the mystery of DTXu half-blocks, but also to this question: when the BTS receives nothing at all after it received a proper SID block followed by a half-block, what are the payload bits in subsequent BFI=1 TRAU-UL output? If these payload bits remain equal to the last received valid SID, or perhaps equal to channel decoder output from half-block Rx (which will likely still have a bit pattern that looks like valid SID!), what does the BTS emit in bits C13 & C14 (SID classification status) of those "dummy" TRAU-UL frames?

Answers to this question matter for:

• Correct logic for turning TRAU-UL frames into TW-TS-001 when interfacing an E1 BTS to an Osmocom-based RAN;
• TFO implementation, namely, correct conversion between TW-TS-001 on the RTP leg and TFO frames.