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 _______________________________________________ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community