FreeCalypso > hg > themwi-system-sw

comparison doc/RTP-BFI-extension @ 173:36cce9b0bbe2

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
doc/RTP-BFI-extension: article written
author Mychaela Falconia <falcon@freecalypso.org>
date Mon, 21 Nov 2022 12:17:55 -0800
parents
children a851bde42d82
comparison
equal deleted inserted replaced
172:60e2d6379fce 173:36cce9b0bbe2
1 We (Themyscira Wireless) have invented our own non-standard extension to the
2 generally accepted standard for RTP-based transport of GSM FR and EFR traffic
3 within a GSM RAN, on stretches running from a BTS to a TRAU-like component.
4
5 The fundamental question is: when the radio subsystem of the BTS does not have
6 any good traffic frame to send in a given 20 ms window, what should it do? The
7 generally accepted standard behavior is that no packet is sent, an intentional
8 gap is created in the RTP stream (the next time an RTP packet does go out, the
9 timestamp increments over the gap while the sequence number increments only by
10 1, indicating an intentional gap rather than packet loss), and apparently the
11 intent was/is that this gap in the RTP stream serves as the BFI (bad frame
12 indication).
13
14 The problem with this generally accepted gap-as-BFI approach is that it deprives
15 the downstream transcoding MGW (a "soft TRAU" of sorts) of its timing source.
16 If the TRAU-like entity on the receiving end of the RTP stream originating from
17 the BTS were an RTP to TDM gateway, there would be no problem - such a gateway
18 would have to buffer received RTP packets in order to synchronize to fixed TDM
19 timing, and the absence of an RTP packet arriving in time would serve just fine
20 as the BFI marker, signaling BFI condition to the Rx DTX handler. But what if
21 the G.711 interface on the 64 kbps side of the TRAU is also an RTP stream, this
22 time going to a PSTN-via-SIP connectivity provider? Now the TRAU-like component
23 becomes a transcoding RTP forwarding MGW without any inherently fixed timing.
24
25 If the desire is to implement a traditional TRAU in every way except for an
26 RTP-based implementation instead of TDM-based, i.e., if the desire is to emit a
27 fully continuous G.711 RTP stream from the MGW toward PSTN with comfort noise
28 generation and in-band DTMF insertion happening inside the MGW, rather than
29 emit gaps in the outgoing stream or punt CN generation (and DTMF) to VoIP
30 network elements, this task becomes dramatically easier if the BTS can be
31 forced to send an RTP packet in every 20 ms window, be it rain or shine,
32 conveying either a good traffic frame or a BFI marker.
33
34 Representing BFI markers in an RTP stream
35 =========================================
36
37 In the case of AMR codec, the existing standard RTP payload format already
38 provides an obvious way to send a BFI marker: it is the NO_DATA frame type,
39 i.e., FT=15 - see RFC 4867 section 4.3.2. That same section also categorizes
40 what we seek to do here as a "SHOULD NOT":
41
42 Note that packets containing only NO_DATA frames SHOULD NOT be
43 transmitted in any payload format configuration, [...]
44
45 However, the just-quoted directive is a SHOULD NOT rather than a MUST NOT,
46 and RFC 2119 states:
47
48 SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
49 there may exist valid reasons in particular circumstances when the
50 particular behavior is acceptable or even useful, but the full
51 implications should be understood and the case carefully weighed
52 before implementing any behavior described with this label.
53
54 Our situation is just that: in our particular circumstance (desire to implement
55 a traditional GSM TRAU in an RTP-to-RTP environment with no TDM network to act
56 as a rigid timing governor) a valid reason exists why this "SHOULD NOT" behavior
57 is not only acceptable, but becomes necessary. Thus in the case of AMR, we are
58 good - there is no need to invent our own totally non-standard extensions to
59 RTP payload format, it just needs to be a configurable option in the IP-based
60 BTS or in OsmoMGW converting from an E1-based BTS to RTP.
61
62 But what about the older FR and EFR codecs? In the case of existing standard
63 RTP payload formats for FR and EFR, there is no defined way to represent a BFI
64 condition as distinct from any possible good traffic frame, and there lies our
65 challenge.
66
67 Inventing an RTP BFI marker for FR and EFR
68 ==========================================
69
70 The existing code in osmo-bts-trx (but not in the osmo-bts-sysmo version of
71 interest to us) already contains a partial implementation of what we seek to do
72 here: it runs its own ECU instance in the case of a BFI from the channel
73 decoding layer, and if there is still no luck, there is code present to send a
74 BFI packet. The implemented behavior is not useful for us because RTP output
75 is still fully suppressed when the uplink is expected to be in DTX, and there
76 is a higher-level check in common/l1sap.c (l1sap_tch_ind() function) that also
77 suppresses RTP output, but still, the point is that someone did already write
78 code for sending an RTP packet intended to serve as a BFI. In the case of AMR,
79 that code sends out the expected NO_DATA (aka AMR_BAD) frame type - but what
80 about FR and EFR?
81
82 The existing code in osmo-bts-trx sends its FR codec BFI as a valid-looking FR
83 frame with all 260 content bits set to 0, and it sends its EFR codec BFI as a
84 valid-looking EFR frame with all 244 content bits set to 0. I (Mother Mychaela)
85 have given consideration to using this all-zeros in-band BFI representation as
86 our RTP BFI marker for ThemWi, but then rejected this idea and decided to
87 implement our own non-standard extension to RTP payload format instead,
88 described further below.
89
90 The fundamental philosophical problem which I (Mother Mychaela) have with this
91 in-band BFI representation is that in the world of ETSI and 3GPP standards, BFI
92 has always been meant to be out-of-band, not in-band. In the TRAU frame format
93 defined in GSM 08.60 there is an explicit control bit that carries BFI - the
94 condition is NOT to be derived from the 260 or 244 traffic frame bits carried
95 in data bit positions. Abusing one particular bit pattern within the regular
96 260-bit or 244-bit frame, even if it happens to be all zeros, goes against the
97 spirit of classic GSM and 3GPP. Per the specs, an FR codec frame of all zeros
98 would be a SID frame with all LAR coefficients set to 0, and standards-compliant
99 FR decoders would accept it as a valid SID frame, not as BFI. The situation is
100 likely to be even worse with EFR, where a frame of all zeros would not be
101 treated as SID (EFR SID code word is 95 ones instead of 95 zeros) and would
102 probably produce garbage at the decoder output.
103
104 Themyscira Wireless implemented solution
105 ========================================
106
107 We have invented our own non-standard extension to RTP payload format for GSM
108 FR and EFR codecs. Our extension is as follows: wherever a BTS needs to send a
109 BFI marker in the place of a traffic frame, instead of sending a 33-byte payload
110 beginning with 0xD nibble or a 31-byte payload beginning with 0xC nibble, it
111 needs to send a 2-byte payload formatted as follows:
112
113 byte 0: 0xBF signature;
114 byte 1: least-significant bit encoding TAF per GSM 06.31 or GSM 06.81,
115 section 6.1.1 in both documents; other bits are reserved.
116
117 In the uplink direction, with an RTP stream going from a BTS to our "soft TRAU"
118 MGW, our themwi-mgw recognizes these BFI packets and acts accordingly, feeding
119 BFI and TAF to the spec-prescribed Rx DTX handler for FR or EFR. However, if a
120 BTS receives these BFI marker packets in the downlink direction as a result of
121 TrFO (the RTP stream comes from the uplink of another GSM call), it simply
122 discards them without any processing - because a BTS always runs on its own TDMA
123 timing, there is no difference between receiving a BFI packet vs receiving no
124 RTP packet at all for that 20 ms frame.
125
126 Our patch to osmo-bts
127 =====================
128
129 Our current BTS is a sysmoBTS, as opposed to a T1/E1-based BTS interfaced via
130 OsmoBSC and OsmoMGW, hence the software component in need of patching is
131 osmo-bts. The patch in osmo-patches/osmo-bts-rtp-bfi.patch in the present
132 repository applies to the common part of osmo-bts, hence it should theoretically
133 work with all models, but it has only been tested with osmo-bts-sysmo. If
134 anyone wishes to play with this patch in an osmo-bts-trx environment, they will
135 probably need to remove TRX-specific ECU and BFI code from
136 osmo-bts-trx/sched_lchan_tchf.c, otherwise the two implementations will "fight":
137 the TRX-specific code will kick in on "unexpected" bad frames and times of FACCH
138 stealing, whereas the common code will fill in the new form of BFI during times
139 of uplink DTX.
140
141 Aside from the just-described incompatibility with osmo-bts-trx version, our
142 current patch has the following outstanding issues which will need to be fixed
143 before it can be proposed for merging:
144
145 * Setting of TAF based on the frame number remains to be implemented - right
146 now we always send TAF=0.
147
148 * The code will need to be extended to support AMR, and to skip out gracefully
149 in the case of totally unsupported codecs like HR1 - our current patch always
150 emits our FR/EFR BFI, implicitly assuming that the speech codec is either FR
151 or EFR, as that is how we currently run our network.
152
153 * A configuration option will need to be implemented, to be controlled from
154 OsmoBSC, enabling or disabling the non-standard behavior of sending explicit
155 BFI packets instead of gaps in the RTP stream. It would probably be best
156 implemented as a tristate option, with the choices being no BFI packets at
157 all (default), sending BFI packets only for AMR (where a standard encoding
158 exists) or sending BFI packets for AMR and also for FR & EFR, using
159 Themyscira encoding for the latter.