FreeCalypso > hg > gsm-net-reveng

comparison doc/BFI-payload-fill @ 15:86a10ba0a1f8

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
doc/BFI-payload-fill: article written
author Mychaela Falconia <falcon@freecalypso.org>
date Sat, 25 May 2024 23:07:13 +0000
parents
children
comparison
equal deleted inserted replaced
14:98c0881c2af0 15:86a10ba0a1f8
1 The traditional TRAU-UL frame format of GSM 08.60 & 08.61 for FR/HR/EFR codecs
2 always includes a full payload in every frame, even those marked as BFI=1.
3 Hence a question naturally arises: what does a traditional T1/E1 BTS put in the
4 payload bits of its TRAU-UL output when there are no "received, but erroneous"
5 bits for this frame, i.e., when the speech frame position was stolen for FACCH,
6 or when nothing at all was received (no burst midambles detected), with nothing
7 to run the channel decoder on? A satisfactory answer to this question will be
8 needed by anyone who sets out to do either of the following:
9
10 a) build a new (FOSS-based) T1/E1 BTS;
11
12 b) implement GSM 08.62 TFO (in-band) in a soft transcoder that works with an
13 IP-based GSM RAN.
14
15 Case (a) is probably only a theoretical thought exercise, but case (b) is quite
16 real: I (Mother Mychaela) do very much desire to bring back in-band TFO, and do
17 so under current economic conditions that call for IP transport within GSM RAN
18 and an IP interface to G.711 PSTN. For the latter problem, the enhancements of
19 TW-TS-001 & TW-TS-002 help greatly (and are required for proper implementation
20 of TFO), but the question still remains of what should be emitted in TFO frames
21 when a no-data BFI comes in. (Most BFIs on OsmoBTS are the no-data kind; there
22 is currently little opportunity for BFI-with-data UL output.)
23
24 In order to get better insight into this question, we (the small community of
25 people who care about this topic) need to look at the Abis UL output from real
26 historical E1 (or T1) BTS implementations, and see what they actually put out
27 under these conditions. I (Mother Mychaela) do not currently own any T1/E1 BTS
28 hardware, but thankfully there are some published capture files in Osmocom which
29 we can look at. The two binary files in trau-files directory of this repository
30 have been copied from libosmo-abis/contrib/trau2rtp, where they were committed
31 some time in Anno Horribilis (2020).
32
33 Analysis of Osmocom contrib/trau2rtp files
34 ==========================================
35
36 The README file in libosmo-abis/contrib/trau2rtp describes the origin of
37 e1_ts2_efr.bin and e1_ts2_fr.bin thusly:
38
39 > The input data (*.log.bz2) was generated using strace on an osmo-nitb process
40 > while a MO-to-MT call was running on two sub-slots of TS2.
41 >
42 > The strace log is converted to a binary stream of the raw 64bit E1 slot
43 > using strace-write-parse.py
44
45 Unfortunately there is no annotation as to what make/model of E1 BTS was used
46 in the OsmoNITB test call setup that produced these logs. The same README file
47 later says:
48
49 > The code has been tested against BS-11 and RBS6000/DUG20 in both modes
50 > (loop vs. RTP) and for FR and EFR.
51
52 but that note seems to refer to the workflow of the trau2rtp.c program operating
53 directly on a "live" DAHDI timeslot, not to the provenance of the included
54 capture files.
55
56 However, despite not knowing the specific BTS model that produced the TRAU-UL
57 frame streams that have been preserved for posterity in those Osmocom-published
58 capture files, we can make some observations after parsing them with our
59 trau-parse utility in trau-decode directory:
60
61 * In both FR and EFR captures, sub-timeslot 1 comes to life first (the idle fill
62 pattern of 2'b01 changes to TRAU-UL frames), then sub-timeslot 2. Thus we can
63 infer that subslot 1 is the MO leg of the test call, and subslot 2 is the MT
64 leg.
65
66 * The FR capture looks like I expected: every TRAU-UL frame (right from the
67 point where the sub-timeslot comes to life) is of type FR UL, and various bits
68 are set as I expected from the reading of GSM 08.60 spec.
69
70 * The EFR capture exhibits this strange oddity: each subslot starts out emitting
71 FR UL frames, then switches to emitting EFR frames some significant time
72 later. (920 ms later on the MO leg and 740 ms later on the MT leg in this
73 test call capture.) I have no clue why this oddity is occuring: is it perhaps
74 an artifact of OsmoNITB initially activating the GSM timeslot as FR and then
75 switching to EFR? Or is it a quirk intrinsic to whatever BTS model these
76 captures came from?
77
78 BFI output seen in these Osmocom-published captures
79 ===================================================
80
81 Having done the preliminary analysis presented above, we can return to our
82 original question: what did that model-unknown E1 BTS emit in its BFI frames,
83 those marked with C12=1? The evidence in the artifacts under examination
84 indicates that at least this particular E1 BTS model uses the buffer method,
85 similar to what is done on the mobile side of GSM Um in the well-studied
86 Calypso DSP.
87
88 What I mean by "the buffer method" is that the Rx Radio Subsystem (as defined
89 in GSM 06.31, 06.41 and 06.81 specs) maintains a buffer, potentially persisting
90 from one Rx frame position to the next, that holds the output of GSM 05.03
91 channel decoder block and the associated SID detector. Under good Rx
92 conditions, those that lead to BFI=0 output, this buffer gets overwritten with
93 new bits on every frame, and its potentially persistent nature is not apparent.
94 However, when no new traffic bits were received, neither good nor bad, the
95 buffer holds its previous content - and this buffer content gets emitted in
96 subsequent BFI=1 frames. How can we tell by black-box observation whether a
97 given implementation uses this buffer method? When the buffer method is used,
98 the following output should be visible at the observed interface (TRAU-UL frames
99 on the BTS side or Calypso DSP a_dd_0[] buffer on the MS side):
100
101 * When a certain frame position gets stolen for FACCH in the middle of what is
102 otherwise a stream of good traffic frames (the transmitter is not cut off as
103 in DTX), the BFI=1 output corresponding to the FACCH position will have the
104 same bit content as the previous good traffic frame.
105
106 * During times of prolonged absence of radio Rx (DTX pauses, or times during
107 channel activation or shutdown), there will be occasional appearances of new
108 bits (frame positions in which some radio noise was decoded as a frame),
109 followed by exact repetitions of previous "garbage" bit content.
110
111 The behavior just described is indeed what we see in the TRAU-UL captures under
112 examination, with one exception. The exception is that in the case of plain FR
113 (not in EFR), whenever this BTS emitted a repetition of previous buffer content
114 (no new decoded bits, good or bad), 4 out of 260 bits got corrupted, or rather
115 overwritten with a fixed pattern. These 4 bits are those that appear at the
116 very end of class 2 portion in GSM 05.03 bit order; in the state of "old buffer
117 output" they get replaced with 4'b1001. When reordered from GSM 05.03 into TRAU
118 frame bit order (the natural bit order of codec parameters), these 4 bits end up
119 in disparate places, hence when we look at the output of trau-parse, we see what
120 looks like corruption in the lsb of 4 different speech parameters:
121
122 * The lsb of 2nd LARc becomes 0;
123 * The lsb of 6th LARc becomes 1;
124 * The lsb of second-to-last Xmc becomes 1;
125 * The lsb of the very last Xmc becomes 0.
126
127 The presence of this corruption (can't really call it a bug, as the output from
128 the BTS under these conditions is officially undefined garbage) does not
129 invalidate the buffer hypothesis, but on the contrary, further confirms that
130 this hypothesis is most likely correct.
131
132 EFR CRC observations
133 ====================
134
135 Taking advantage of EFR being more compact than the original FR (244 bits
136 instead of 260), the TRAU frame format for EFR adds 5 CRC-3 fields, covering
137 some of the "most important" bits of the payload. I was wondering if perhaps
138 some T1/E1 BTS may be transmitting intentionally bad CRC to indicate that they
139 got no payload bits at all, i.e., BFI with no data - but at least the (unknown)
140 BTS model from which these Osmocom-published captured were taken always emitted
141 good CRC in every TRAU-UL frame, including buffer-output frame positions which
142 were clearly "BFI with no new bits".
143
144 Ideas for software implementation of TFO
145 ========================================
146
147 The main motivator for seeking answers to the question of BFI payload fill is
148 deciding what to put in those payload bits in the case of TFO frame output when
149 the RTP-based source is BFI with no data. From the standpoint of implementation
150 costs (both the effort of implementation and CPU load in operation), the buffer
151 method looks very attractive. One implementation strategy would be to have an
152 array of 320 bits (with each bit expanded to a byte at this stage) in the
153 per-call state structure, holding the TFO frame to be transmitted. This way
154 bits that never change (sync pattern, frame type bits etc) would only be
155 initialized once and then reused for the duration of the call; the frame output
156 function executing every 20 ms would fill in the new Dn bits most of the time,
157 set new C12-15, and do the final step of packing the content of this buffer
158 into the two lsbs of outgoing PCM samples. With this approach, the processing
159 of BFI-no-data frames would entail simply skipping the step that writes the new
160 Dn bits (and associated C13-14), leaving the old bits in place - apparently the
161 exact same approach used by T1/E1 BTS and MS DSP implementors.