[private hacking hat on]
Thinking ahead to the 35C3, I have tinkered with IuUP a bit.
I'm at the point where I have an IuUP core net node in the osmo-mgw, which auto-detects IuUP peers and removes IuUP headers coming from a 3G RNC, and inserts IuUP headers in RTP going to a 3G RNC. So far we were merely hacking over the IuUP header to mimick an Initialization ACK, and were otherwise just handing the IuUP headers through from one 3G peer to the other. I realized now that hacking up an Initialization ACK like we currently do on osmo-mgw master produces a header CRC error, which the femto cells we currently tested completely don't care about, thankfully.
Ok, so now I am de/encapsulating the IuUP from/to RTP, so that IuUP is present only on the last leg to/from an RNC. 3G to 3G calls still work well with that, now also having correct IuUP header CRCs.
And, the naive idea was that now the 2G would simply understand the RTP from the 3G and vice versa. But that's not the case, apparently. The phones at best crackle some random artifacts.
I picked a codec-list of fr3 hr3 in osmo-bsc, and tried a few AMR rates (12.2k, 5.9k, 5.2k).
So I think there's still some fundamental concept that I'm lacking. Is there anyone more familiar with AMR and/or the way 3G encodes audio, and whether there's a simple way to make them match? Where should I read on?
Would a call router like we use in the C3 POC be able to transcode when the IuUP is stripped? (I'm not even sure what the POC side is doing to connect SIP with GSM.)
I've noticed the laforge/iu_up branch in libosmocore only later, which includes an FSM that apparently does only state transitions so far. My patch has no FSM yet, since all I see on the wire is Init->InitAck, then Data PDUs, and maybe an occasional error report. Do those FSM states convey a secret of making 3G encoding readable by 2G?
Various pcaps of the status quo are here: http://kleinekatze.de/eeD0ouCo/
My IuUP branch: osmo-mgw neels/iuup http://git.osmocom.org/osmo-mgw/log/?h=neels/iuup IuUP protocol spec: 3GPP TS 25.415 (I've so far ignored most of it)
~N
Hi Neels,
thanks for looking into this.
On Wed, Oct 10, 2018 at 01:18:39PM +0200, Neels Hofmeyr wrote:
So I think there's still some fundamental concept that I'm lacking. Is there anyone more familiar with AMR and/or the way 3G encodes audio, and whether there's a simple way to make them match? Where should I read on?
The fundamental part that you're lacking is the fact that the codec payload for 3G and 2G is completely different. You will need lots of bit re-shuffling in order to make this work.
From the MGW point of view, IuUP and the 3G-style codec payload should be seen
as a different codec, and an endpoint with two connections of two different codec requires "transcoding".
The only difference here is that in case of AMR on both the IuUP and the 2G side, you don't actually transcode to PCM and re-encode, but you're really just shuffling around the bits.
Would a call router like we use in the C3 POC be able to transcode when the IuUP is stripped? (I'm not even sure what the POC side is doing to connect SIP with GSM.)
Nobody outside a 3G network will have any idea what IuUP is. Even more so, I think nobody on the planet will be able to process codec payload that is in IuUP payload format without the IuUP header. Basically either
a) you have IuUP and the related payload format, or
b) you have no IuUP and native RTP [AMR] payload format
Going in between by just removing the IuUP header you would create yet another derivative that doesn't exist so far.
I've noticed the laforge/iu_up branch in libosmocore only later,
It would have been great to first catch up about this, before investing time on an implementation. I had mentioned this branch in http://osmocom.org/issues/1936 when I wrote it close to a year ago.
which includes an FSM that apparently does only state transitions so far.
It does a bit more, such as both header and payload CRC computation / verification and should actually implement pretty much everything between the TNL and the RNL SAP and implement all primitives on both sides. It hasn't been tested yet, though. To do that, I first implemented RTP source/sink in TTCN3 and then IuUP in TTCN3, but then got distracted before putting the full setup together and write actual test cases against the libosmocore iu_up impementation.
You should be able to
* feed primitives from the transport layer (RTP) up into it using osmo_iuup_tnl_prim_up() * feed primitives from the upper layer down into it using osmo_iuup_rnl_prim_down()
The transformations are done inside the FSM using tnl_to_rnl_data() as well as rnl_to_tnl_data(). Only SMpSDU mode is implemented, which is what's used in our case.
My patch has no FSM yet, since all I see on the wire is Init->InitAck, then Data PDUs, and maybe an occasional error report. Do those FSM states convey a secret of making 3G encoding readable by 2G?
The state machines are required as soon as you actually have changes between the AMR codec rates, i.e. the actual *adaptive* part of AMR.
Also, once you are actually re-ordering ("transcoding") the payload bits, you will have to recompute the CRC. I do think the FSM should be used, rather than some other approach.
Hi Neels,
in terms of the actual payload, I believe (IIRC), that AMR over IuUP used three sub-flows. They are encoded after each other, see TS 25.415 6.6.3.27 / Figure 27a for an illustration.
Thse SDUs of each sub-flow contain the bits of one class.
The rationale for teh above lies in the structure of the RAB and the channel bundles on the Iu radio layer. Both on the radio and on the IuFP side between NodeB and RNC, there are actually three independent streams of bits, one for each of the classes.
For IuUP, it seems they are then re-combined in the RNC into one IuUP payload, but still the three separate chunks accordign to their class.
In order to get the regular RTP-AMR payload, they need to be mixed/mangled into the order specified by whatever RFC specifies the AMR payload format, I think it as https://tools.ietf.org/html/rfc3267 - whcih then refers to the IF1 format as specified in 3GPP TS 26.101, where IF1 is described in Section 4.
The order of the fields here is "logical", so if there's a given parameter that has 6 bits, then those 6 bits are consecutive. In the air interface, you may want to transmit the first two (MSB) bits in class A, the middle two in class B and the last two bits in class C. This is so the most improtant bits for speech recovery are given higher amount of forward error correction than the less important bits.
I believe the tables in Annex B of 26.101 is what's needed in terms of re-ordering.
Still, there's plenty of things that can go wrong in terms of bit-order within a byte, byte ordering, ..., and hence I think it's good to start with writing functions and unit tests for this first. GAPK might be a good place for prototyping, as it already understands the concept of different representations/bit-orders/formats for one given codec, and it has support for playback via alsa, ...
(continuing this thread in https://osmocom.org/issues/1936#change-12154 )
-
Harald Welte -
Neels Hofmeyr