Hello GSM community,
As I keep working on my project seeking to build a new GSM network that will be no worse in every aspect than the one which T-Mobile USA are itching to shut down, I need a way to ferry the uplink voice stream from the BTS to my "soft TRAU" in RTP transport, but do it in a way that is semantically no-worse than what happens in the traditional T1/E1-based architecture. As part of this no-worse-than-TDM desire or requirement, I need explicit BFI markers - in other words, any time there is a 20 ms window in which there is no good traffic frame to be sent because the uplink is in DTX, because that frame was lost to bad radio conditions or because that frame was stolen for FACCH, I want my BTS to send an explicit BFI frame instead of gapping/pausing the RTP stream.
But this "simple and innocent" desire which I just expressed then turns into a perplexing question: just how would one represent an explicit BFI marker in an RTP stream? In the case of AMR codec there is a straightforward solution already provided for in the specs: simply send a NO_DATA frame. But what about FR and EFR codecs?
For my own Themyscira Wireless deployment, I currently run with my own non-standard extension to RTP transport format for FR & EFR, documented here:
https://www.freecalypso.org/hg/themwi-system-sw/file/tip/doc/RTP-BFI-extensi...
My solution works great for my purposes, and I am very happy with it. However, in the spirit of seeking at least some unity and at least some chance of patches being merged, I am making a due-diligence attempt to understand how others have addressed similar problems, and what competing solutions may already exist out in the wild.
Here is my specific question to the community, mostly the narrower Osmocom community but perhaps also the wider GSM community: where did the idea of an all-zeros frame representing BFI come from? In the current osmo-bts-trx implementation (although not in any other osmo-bts variants that I can see from the code) there is code that sends an FR codec frame of 260 zero bits or an EFR codec frame of 244 zero bits, both intended to signal BFI, under the following conditions:
1) The BFI condition exists for some reason other than the uplink being in DTX, i.e., because the frame was stolen for FACCH or was lost to radio errors, but the last frame was not a SID;
and
2) There is no ECU on the channel, or the ECU failed to provide a substitute frame.
Irrespective of specific conditions though, the key point is that someone, somewhere, at some point in time had the idea that an FR or EFR codec frame of all zeros (260 or 244 zero bits, respectively) should mean BFI. There is also a patch to gapk by Vadim, adding an FR codec EFU function, that detects a frame of all-zeros and treats it as BFI - but I am not able to tell if the very idea of such BFI representation comes from Vadim, or if Vadim simply added the code to gapk to work with what osmo-bts-trx puts out under certain conditions.
To put the question differently: does there exist any spec from ETSI or from 3GPP or from any other non-Osmocom standards body that defines an FR codec frame of 260 all-zero bits and/or an EFR frame of 244 all-zero bits to mean BFI, or is this idea a pure Osmocom invention?
The only official specs I could find for coded speech transport within RAN, between a BTS and a separate transcoder, deal with the traditional T1/E1 environment, as in GSM 08.60 and friends. In those specs BFI is signaled out of band: in GSM 08.60 TRAU frames there is a control bit carrying BFI, and another control bit carrying TAF (important for traditional Rx DTX handlers for FR & EFR), both outside of 260 data bits, and there is NO special bit pattern (all zeros or otherwise) within data frame bits themselves that would also signal BFI. Therefore, based on what I see in GSM 08.60 and other specs for T1/E1 world, I get the idea that BFI is meant to be an out-of-band signal, not in-band, and that an in-band bit pattern that signals BFI seems to go against the spirit of ETSI and 3GPP.
But maybe the problem is that I was only looking at older specs, maybe there is some newer spec from 3GPP or some other standards body written for the newer world of IP transport that officially repurposes in-band all-zeros FR and EFR codec frames to mean BFI - is there any such spec?
Moving from the realm of rhetorical questions to the realm of tangible code, here is my latest creation in the realm of GSM codecs:
https://www.freecalypso.org/hg/gsm-codec-lib/
I will make another announcement when this code reaches the level of completeness I am after, but as a short summary, I am making a librified (turned into a library) version of the official EFR codec implementation from ETSI (libgsmefr), and I have also written another library of my own (libgsmfrp) that implements Rx DTX handler functions for GSM FR, to be run as a pre-processor before passing frames to a GSM 06.10 decoder, which is typically gsm_decode() from libgsm. libgsmfrp is already integrated into my "soft TRAU" implementation in themwi-mgw, and libgsmefr will likewise be integrated when it is complete. (Right now only the decoder works in libgsmefr, the encoder remains to be finished.)
Both libgsmefr and libgsmfrp have BFI handling functions which the "soft TRAU" application needs to call when it receives a BFI marker instead of a good traffic frame, but the question of how these BFI markers should be represented in an RTP stream is outside the scope of the library - instead my themwi-mgw application currently implements ThemWi RTP-BFI-extension and calls the respective library functions.
I may be open to the possibility that I should not be inventing my own RTP-BFI-extension and should instead use in-band frames of all-zeros to represent BFI in FR & EFR, *if* there is some official spec from 3GPP etc saying so - but if that idea is an Osmocom invention rather than 3GPP, then I am going to argue for my invented alternative RTP representation instead. So which is it?
With devotion to GSM Forever, (Hasta la Victoria, Siempre,) Mother Mychaela
Hi,
On 11/28/22 00:02, Mychaela Falconia wrote:
just how would one represent an explicit BFI marker in an RTP stream? In the case of AMR codec there is a straightforward solution already provided for in the specs: simply send a NO_DATA frame. But what about FR and EFR codecs?
https://datatracker.ietf.org/doc/html/rfc3267#section-4.3.2 """ Note that packets containing only NO_DATA frames SHOULD NOT be transmitted. """
My guess is that you should indicate it with Q bit set to 0 and put whatever you want in the payload, maybe padding of zeroes of expected length based on pyaload type. https://datatracker.ietf.org/doc/html/rfc3267#section-4.3.2
In any case, in RTP you have seq nums and timestamps, which should allow you to find out if there were gaps (just check non-consecutive jumps of seq, or non-consecutive jumps of 160ms of timestamp). Mind also the RTP Marker (M) bit.
Hi Pau,
https://datatracker.ietf.org/doc/html/rfc3267#section-4.3.2 """ Note that packets containing only NO_DATA frames SHOULD NOT be transmitted. """
Yes, I am fully aware of that callout in the RFCs (the newer RFC 4867 says the same), but it is a SHOULD NOT rather than a MUST NOT. Quoting RFC 2119:
SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
And as I wrote in my RTP-BFI-extension document:
: Our situation is just that: in our particular circumstance (desire to : implement a traditional GSM TRAU in an RTP-to-RTP environment with no : TDM network to act as a rigid timing governor) a valid reason exists : why this "SHOULD NOT" behavior is not only acceptable, but becomes : necessary.
My guess is that you should indicate it with Q bit set to 0 and put whatever you want in the payload, maybe padding of zeroes of expected length based on pyaload type. https://datatracker.ietf.org/doc/html/rfc3267#section-4.3.2
I don't see how this approach would be any better than simply sending a NO_DATA frame. When those RFC authors wrote that NO_DATA frames SHOULD NOT be sent, they surely meant that the sender should leave a gap in the RTP stream instead (as you say yourself further below), not a roundabout way of saying "NO DATA" by way of Q=0.
In any case, in RTP you have seq nums and timestamps, which should allow you to find out if there were gaps (just check non-consecutive jumps of seq, or non-consecutive jumps of 160ms of timestamp).
Except that it will be too late at that point - seeing an increment of more than 160 timestamp units while the sequence number incremented only by 1 would indicate *after the fact* that the sender produced an intentional gap in its output stream, but after-the-fact doesn't do me any good - I want to have a BFI-signaling packet arrive *at the same time* when a good traffic frame would otherwise be expected.
But we are straying from the topic of my original question - my question to the lists was and still is about FR and EFR, not about AMR. In the case of FR & EFR, there is existing code in osmo-bts-trx that generates a frame of all zero bits (260 of them for FR or 244 for EFR) to signal BFI, and there is existing code in GAPK (ECU tie-in) that interprets an FR frame of 260 zero bits as BFI. My question still stands: is this representation of BFI for FR & EFR an Osmocom invention, or is there some (presumably newer) spec from 3GPP etc that specifies such?
M~
-
Mychaela Falconia -
Pau Espin Pedrol