Cellular Network Infrastructure » Radio Access Network » OsmoBTS

With every type of TCH UL producing an RTP stream (all speech modes, and probably CSD too), there will always be some BFI (bad frame indication) conditions: FACCH was received instead of a traffic frame, the MS was exercising DTXu and hence nothing was received at all, or the radio conditions were so bad that nothing was successfully decoded. With all OsmoBTS models other than TRX, the way in which these BFI conditions are signaled is very unified and consistent: the BTS model sends a zero-length payload to l1sap, and the common layer then reports this BFI condition in RTP as configured by the operator:

• If "rtp continuous-streaming" is enabled, every BFI condition is indicated in the RTP stream with a zero-length payload.

• In the default configuration without continuous-streaming, every BFI condition is indicated with an intentional gap in the RTP stream: no RTP packet is sent, but the timestamp counter for subsequent RTP packets is incremented over the gap. This behavior option appears to be the industry standard, as ip.access nanoBTS does the same.

Furthermore, in addition to the main path of BTS models indicating BFI conditions to l1sap with a zero-length payload on the internal interface, there is one other cause of BFI conditions in the final RTP output: the link quality check in l1sap_tch_ind(). The BTS model will sometimes send a valid-seeming traffic frame payload to l1sap, but the check in l1sap_tch_ind() will deem the link quality to be too low, and as a result the frame from the BTS model will be discarded and a BFI condition will be signaled on the RTP output instead. The important point, however, is that the form of BFI signaling in the RTP output (a zero-length RTP payload or no RTP packet at all) is always consistent, whether the BFI came from the BTS model or was imposed by the link quality check in l1sap.

The bug, however, is in the osmo-bts-trx model: unlike all other BTS model, this model invent its own BFI packet format that is emitted only under certain conditions, while for other types of BFI condition the common code in l1sap takes effect. Therefore, if one is running osmo-bts-trx, the final RTP output will exhibit a mixture of the two forms of BFI signaling: one form in some BFI frame positions, and the other form in others. The specific behavior in current osmo-bts-trx is as follows:

• BFIs following a UL SID reception will always be emitted in the common l1sap-determined form like on other models.

• The l1sap form of BFI likewise takes effect if the link quality falls below the threshold.

• However, if the decoding result was a BFI (or FACCH) under conditions of "good" link quality and the last received good traffic frame was speech (not SID), then the TRX model's own form of BFI packet will be emitted instead.

The TRX model-specific BFI packet format is OK for AMR and HR1 - it unambiguously indicates that the frame is bad - but the TRX-invented BFI packet format for FR1 and EFR is a real problem. The TRX-invented BFI packet format for FR (EFR) is a valid-looking FR (EFR) RTP encoding with all 260 (244) bits of payload set to 0. However, this representation of BFI runs counter to GSM specs: in the specs there is no in-band representation of BFI at all, instead BFI has always been an out-of-band signal, e.g., control bit C12 in TRAU frames. To a standard FR decoder, a frame of 260 zero bits is a valid SID, and to a standard EFR decoder, a frame of 244 zero bits is a valid speech frame - neither of them is a BFI marker.

This problematic representation of BFI by way of made-up all-zeros payload packets has been a part of osmo-bts-trx (but no other OsmoBTS model) since the very beginning of TRX project:

https://cgit.osmocom.org/osmo-bts/commit/?id=d10eaee4cce04aee4907b87e5bd73b9d866061b7 (for FR)
https://cgit.osmocom.org/osmo-bts/commit/?id=917cf7018b6a9ec778add719fcec1692f0e35931 (for EFR)

This incorrect representation of BFI causes the following problems:

• If an EFR call is connected via a BTS that runs osmo-bts-trx and the RTP stream is fed to a standard EFR decoder (either a network transcoder based on Themyscira libgsmefr or another GSM call leg with a standard GSM MS), the EFR decoder will see bogus, but declared-as-good all-zero-bits speech frames in the place of BFIs, and will most likely produce strange and unpleasant sounds instead of invoking its built-in spec-defined bad frame handler. This bug was most likely missed as it appears that no one in Osmocom other than me uses EFR to a significant extent, beyond minimal testing.

• The same problem behavior will occur with plain FR codec if the application of ECU to the uplink in osmo-bts-trx were to be removed or disabled - right now the ECU masks the bad format of BFI markers, as no BFI markers will be emitted when the ECU is running. I further venture an educated guess that the very idea of applying an ECU at the point of UL output from the BTS (which is wrong) may have been invented (in late 2017) as a misguided response to a misdiagnosis of the problem identified in the present ticket.

The correct solution is to remove all TRX model-specific BFI packet formats, and indicate all BFI conditions by sending a zero-length payload on the internal interface to l1sap. The common code in l1sap will then emit the correct representation of BFI in RTP per vty configuration.