No-data output » History » Version 2
falconia, 07/20/2024 08:39 PM
1 | 1 | falconia | h1. No-data output from BTS in TRAU-UL |
---|---|---|---|
2 | |||
3 | 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? |
||
4 | |||
5 | 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. |
||
6 | |||
7 | 2 | falconia | 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? |
8 | 1 | falconia | |
9 | Answers to this question matter for: |
||
10 | |||
11 | * Correct logic for turning TRAU-UL frames into [[ThemWi_RTP_Extensions|TW-TS-001]] when interfacing an E1 BTS to an Osmocom-based RAN; |
||
12 | * [[TFO]] implementation, namely, correct conversion between TW-TS-001 on the RTP leg and TFO frames. |