No-data output » History » Revision 2
Revision 1 (falconia, 07/20/2024 08:30 PM) → Revision 2/4 (falconia, 07/20/2024 08:39 PM)
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? 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 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]], [[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 [[ThemWi_RTP_Extensions|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.
