IuUP, aka voice between 2G and 3G

historical

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, ...

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