IuUP, aka voice between 2G and 3G

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Wed Oct 10 14:50:16 UTC 2018


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.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



More information about the OpenBSC mailing list