Cellular Network Infrastructure » Radio Access Network » OsmoBTS

Some people, such as the present developer, have a desire to interconnect their Osmocom-based GSM network to their country's PSTN, and the least expensive way to do so is to use a PSTN-via-SIP connectivity provider. At least in the USA telecom environment (the underlying PSTN itself plus various providers who enable VoIP aka SIP+RTP connection to it) the cultural expectation is that G.711 RTP streams between interconnected parties are fully continuous, with a packet carrying 160 PCM samples sent every 20 ms without fail. Achieving interconnection between a private GSM network and the public national G.711 voice network requires implementation of a transcoding RTP-based MGW, and this MGW must perform all those functions that were performed by TRAUs in the original E1-backhaul GSM architecture: not only the main path of speech transcoding, but also comfort noise generation when GSM call UL goes into DTX and error concealment when GSM call UL experiences frame loss to FACCH stealing or bad radio conditions.

Implementation of the just-described TRAU functional equivalent in the form of a transcoding RTP-based MGW, with the requirement that it emits a continuous G.711 RTP stream (160 samples every 20 ms) at all times, even when generating comfort noise or substituting for lost GSM UL frames, becomes dramatically easier and better in terms of end-to-end performance (no latency or jitter artificially added by this MGW) if the IP-based BTS that sits at the ultimate origin of the UL RTP stream can be forced to emit some RTP packet every 20 ms, be it rain or shine, as opposed to the generally accepted industry standard behavior (ip.access nanoBTS, current OsmoBTS) of producing an intentional gap in the RTP stream when there are no received-from-MS speech or SID frames to be sent.

My desire is to add a vty-configurable option to OsmoBTS that would select which of several possible behavior choices should be invoked in those time windows in which there is no good speech or SID frame to be sent, corresponding to the BFI=1 condition on a traditional E1 TRAU uplink. The default will remain the same as now (produce an intentional gap in the emitted RTP stream), but other (newly added) options will be to generate one of several possible representations of BFI in RTP.

In the case of FR1 and EFR codecs, one BFI representation option I wish to support is the one invented and implemented by Themyscira Wireless:

https://www.freecalypso.org/hg/themwi-system-sw/file/tip/doc/RTP-BFI-extension

Other BFI representation options (for FR and EFR) that should be supported are:

• Sending an RTP packet with a zero-length payload. There are many places throughout Osmocom code base where (rtp_payload_len == 0) means no data, and it stands to reason that some people may naturally extend the same representation to RTP.

• Sending an RTP packet containing a normally-encoded FR or EFR frame, but with all bits of that actual FR or EFR frame set to 0. I was not able to find any standard or spec that calls for such, but osmo-bts-trx currently produces such BFI packets in some rarely-exercised corner cases.

My current focus is solely on FR1 and EFR codecs; handling of AMR and HR1 will need to be tackled separately at a later time.