Half-rate data calls (CSD)

[Mychaela Falconia]

Hi Vadim,

> (I changed the Subject when replying, since this topic is not specific 
> to Sony Ericsson K2xx.)

Yes, I agree.

> I would be interested to play with the DSP directly using osmocom-bb 
> code base.

While I am also interested in the first part (playing with the DSP
more directly), the second part (using OBB code base to do it) is
prohibited by my personal ethics.  However, there is a way to explore
DSP functionality without resorting to OBB.  When I get around to it
(again, lots of higher priorities atm), one simple experiment will be
to #if 0 out the calls to dll_data_ul() and dll_data_dl() in l1_cmplx.c,
and see what happens.

> While working on adding CSD support for it, I had to make 
> only a small change to the layer1 firmware to get the channel coding 
> working:

Yes, I saw that commit when I looked at OBB code to see what you did
there.  But the commit you pointed out only does the obvious part of
setting TCH mode (I call it obvious because how else would you set it
given the DSP definitions in TI header files?); instead what I was
looking for was how you read out DL bits and feed your own UL bits.

It looks like OBB reads from a_dd_0 (TCH/F or TCH/H subchannel 0) or
a_dd_1 (TCH/H subchannel 1) to get DL data traffic bits, and for
transmitting UL, it relies on the same debug-only hack-feature of the
DSP that is used in "TCH play" mechanism in FreeCalypso, accessible
via fc-shell 'tch play' command.  I am OK with using this mechanism
for hacks, but because it isn't the official way, I won't use it in
production.

> In theory, both TCH/H2.4 and TCH/H4.8 should be supported by 
> osmo-bts-trx;

I still haven't tried getting my ebay-sourced UmTRX up and running,
hence I have no practical experience with osmo-bts-trx yet, but I've
been looking at its code quite a bit, and I see a big flaw in how that
support is implemented.  We both know that the 05.03 channel coder
runs at half the normal rate in these TCH/H2.4 and TCH/H4.8 modes: in
all other modes including TCH/HS, it runs 6 times per 26-multiframe,
producing/consuming a frame approx every 20 ms, but in these two
special modes it runs 3 times per 26-multiframe, producing/consuming
a frame approx every 40 ms.  However, on all RTP-based interfaces we
still need to transfer a frame every 20 ms, give or take some TDMA
jitter: TS 48.103 requires so (see section 5.6), and the same in
needed for interoperability with E1 BTS where a TRAU frame (which gets
translated to RTP) happens *exactly* every 20 ms in perfect clockwork.

It appears that the approach currently implemented in osmo-bts-trx is
to cheat on RTP interface:

* Clearmode RTP packets are sent every 40 ms instead of every 20 ms,
but the packet length is still 160 bytes and it pretends to be a 20 ms
packet;

* RA2 bit packing is done as if the IR were 16 kbit/s, when it is
actually 8 kbit/s in these modes.

Imagine a V.110 aka transparent CSD call at 4800 baud from GSM network
A that uses TCH/F4.8 to GSM network B that uses TCH/H4.8, or from a
GSM network that uses TCH/H4.8 to wireline ISDN - clearly it won't
work with the current design in place.

I do realize of course that TCH/H was not in scope for the commercial
contract that sponsored CSD support in Osmocom CNI - I saw statements
by Harald to this effect in some public Redmine tickets - thus I don't
blame you for taking this shortcut, producing an RTP-incorrect
implementation instead of none at all.  But I do wonder if you were
consciously aware of this issue, or if it is a surprise to you now.

If you agree that the current osmo-bts-trx behavior w.r.t. half-rate
CSD is a bug, I can document it as such in Osmocom Redmine, i.e.,
create a proper ticket for it.

> we even have TTCN-3 testcases for that.

Do they check for the current behaviour which I view as a bug?

Another issue caught by my sharp eye merely reading the code, while
having no setup for testing: consider TCH/F4.8 NT mode and the alignment
requirement for RLP frames.  The channel coder runs approx every 20 ms,
giving us 120 bits, and we do an RTP packet every 20 ms with these 120
bits stuffed in there as if it was V.110 with 8 kbit/s IR - so far, so
good.  But note that each 20 ms RTP packet carries only half of an RLP
frame!  In a correct implementation, bit E2 in RTP output should
alternate between successive packets, indicating RLP frame halves that
are aligned with the 26-multiframe on the air interface per GSM 05.03
section 3.4.1, and the path from RTP to radio DL will have to look for
this alignment.  Neither part is implemented in current osmo-bts-trx:
E2 bit is always 0 in RTP output, and no alignment logic exists in the
DL path.

The result is that a 4800 baud NT call from mobile A to mobile B will
work or not as a law of chance: on each receiving leg, there is a 50-50
chance of either getting correct alignment by luck, or transmitting
misaligned RLP frames on radio DL which the MS will presumably fail to
decode.  Is this bug also something you knew about but skipped for the
sake of delivering something better than nothing, or is it a surprise?
Should I likewise document it in a Redmine ticket?

The TCH/F4.8 NT bug is one which I plan on fixing eventually if no one
beats me to it, in the very distant future after all higher priorities
- but the one involving TCH/H2.4 and TCH/H4.8 I am less sure about.
In order to do anything with half-rate CSD, I would need some test MS
that supports such modes officially and properly - but I am not aware
of such MS.  Do you know of any?  Does anyone else in our wider
community know of any?  Until and unless I find such MS for testing,
I will have to operate networks with a policy that never even attempts
assigning TCH/H to any CSD calls, only TCH/F.

> If I remember correctly, it was mentioned somewhere (or by somebody in a 
> conversation) that TI's DSP has a hardware accelerated module for the 
> V.110 stuff (RA1'/RA1/RA2 functions).

Fortunately we have enough docs from TI to know exactly what hw blocks
exist in our dear Calypso.  A5/1 and GEA-whatever (not sure of number)
are indeed true hw blocks, not just DSP implementing the function with
regular C54x instructions, but the IDS block that does RAx is _not_
such hw - it is just DSP ROM code doing the work with regular C54x
instructions, just like the way it implements speech codecs, channel
coding, GMSK demodulation from I&Q and everything else.

I've done a little more digging, and it appears that the IDS block
fits in the same logical place for CSD as speech codecs do for voice
calls.  In a regular voice call, the DSP does not only GMSK and
channel coding, but also speech encoding and decoding, including
computationally intensive codecs as in HR, EFR and AMR - hence the DSP
has enough horsepower by design to do all that work.  Now replace voice
with CSD: the computational load of modulation and channel coding
stays about the same, but the cycles previously reserved for running
HR/EFR/AMR are now free.  Thus it was a perfectly sensible design for
TI to move the ARM-DSP interface for CSD a little higher than 05.03
level, and move some RAx processing into the DSP.

In TCS211-turned-FC code base, L1S calls dll_data_dl() and dll_data_ul()
from the TDMA HISR; those functions are in turn implemented in G23M
component named 'ra'.  The arguments to these functions are merely
pointers to DSP shared memory words, hence 'ra' is the component to be
studied in order to learn this DSP interface.  I looked into it a
little bit, saw that it distinguishes between transparent, RLP and fax
modes (3 in total), but haven't dug deeper.

M~