Cellular Network Infrastructure » Radio Access Network » OsmoBTS

The DTX specs for all 3 classic non-AMR codecs (FR1, HR1 and EFR) prescribe rather symmetric handling for uplink Rx in a BTS: for each of the 3 codecs, each received UL frame is ternary-classified as valid SID, invalid SID or non-SID speech. Furthermore, in the original E1-based architecture this classification operation (for all 3 codecs) always takes place in the BTS, immediately adjacent to the GSM 05.03 channel decoder, and the Abis output (TRAU frames) includes not only the frame payload bits, but also out-of-band control bits indicating BFI, UFI (for HR only) and this SID classification decision. There is a serious problem, however, in that these out-of-band indication bits have been dropped in the migration from E1 TRAU frames to RTP, and there are many different negative fallouts from this "simplification".

There is one further way how the problem of SID classification is more difficult for HR than for FR and EFR. In the case of both FR and EFR, the respective DTX specs (06.31 and 06.81) prescribe exact bit-counting rules whereby a received frame is declared to be a valid SID, an invalid SID or non-SID speech. Given these exact bit-counting rules, the missing C13 & C14 indication bits that have been lost in the transition from TRAU-UL frames to RTP can be trivially reconstructed on the RTP receiving end, as now implemented in osmo_{fr,efr}_sid_classify() functions in libosmocodec, and the output of these functions (or their equivalents in Themyscira libraries) can be used by all processes that need to receive an RTP stream that comes or may be coming from the uplink of a GSM call leg: network edge transcoders that need to feed this UL RTP stream to their Rx DTX handlers, and the RTP-to-DL path in OsmoBTS that needs to be prepared for the possibility of TrFO.

However, the DTX spec for HR (GSM 06.41) does NOT prescribe exact thresholds of how many non-1 bits in the SID field mark the transition from valid to invalid SID, and how many non-1 bits in this SID field mark the transition from invalid SID to non-SID speech classification. Instead this design decision is left to BTS implementors, fitting well into the architecture where this SID classification logic is closely coupled with the GSM 05.03 channel decoder. Furthermore, while the SID fields of both FR and EFR fall fully into class 1 bits (all subject to convolutional coding), the SID field of HR1 is split between class 1 and class 2 bits. A BTS uplink receiver making the SID classification decision based on how many non-1 bits occur in the SID field may very well give different weights to non-1 bit errors in class 1 vs class 2 bits, and the GSM 06.41 spec leaves the door open for BTS implementors to apply such more complex logics than a simple count of "wrong" bits as in FR and EFR SID classifiers.

So what are we going to do about this problem in Osmocom? Given the lack of "solid" SID classification rules that can be "legitimately" applied by RTP stream receivers, I propose that instead of replicating what we did for FR and EFR, we handle HR1 differently:

• Implement a SID classifier in OsmoBTS at the point of UL output, rather than at the point of DL input. For the sake of simplicity, our initial implementation of this SID classifier will look only at the hard-decision output bits from the 05.03 decoder, but we leave the door open for the possibility of tighter coupling between this classifier and the channel decoder.

• If the HR1 RTP output format from OsmoBTS is RFC 5993, the ToC octet provides the proper place to indicate the SID classification result. If this RTP output format is instead vty-configured to be TS 101 318 (which should be the non-recommended option given this SID classification problem), valid SID can be indicated by "rejuvenating" the SID frame (resetting all 79 SID field bits to 1), while invalid SID frames will have to be simply dropped from the output - treated like BFIs.

• At the point of RTP input for DL in OsmoBTS, if the RTP format is RFC 5993 (preferred), take the SID classification status from the ToC octet and use this status for TFO-like logic, i.e., for the logic of #5996 that mimics parts of TS 28.062 section C.3.2.1.1. If the RTP format is TS 101 318 (non-preferred), apply the current osmo_hr_check_sid() function, i.e., treat the frame as SID iff all 79 bits of SID field are ones.