Representing BFI in an RTP stream in FR & EFR modes

[Mychaela Falconia]

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-extension

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