Half-rate data calls (CSD)

[Vadim Yanitskiy]

Hi Mychaela,

On 24.09.2024 06:22, Mychaela Falconia wrote:
> 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.

yes, it was done like that before my patches.  More details and links to 
all related patches I worked on can be found in OS#4396.

> 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.  [...]
> 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.

Ack, this is a known problem.  We don't have a ticket for it, so you're 
welcome to create one ;)  I realized this when looking at the logging 
produced by osmo-bts-trx while developing TCs for ttcn3-bts-test.

One can see errors about the RTP clock being out of sync:

(bts=0,trx=0,ts=5,ss=0) RTP clock out of sync with lower layer: 0 vs 160 
(0->0)
(bts=0,trx=0,ts=5,ss=0) RTP clock out of sync with lower layer: 9600 vs 
160 (0->260)

and errors about Tx primitives being dropped by the scheduler:

000260/00/00/05/04 (bts=0,trx=0,ts=5) TCH/H(0): Prim 2715635 is out of 
range (247 vs exp 260), or channel (bts=0,trx=0,ts=5,ss=0) with type 
TCH/H(0) is already disabled. If this happens in conjunction with PCU, 
increase 'rts-advance' by 5.

Looking at one of the recent PCAPs generated by ttcn3-bts-test, we can 
indeed see the delay of ~40 ms between RTP packets in each direction.

https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/lastCompletedBuild/artifact/logs/bts-tester-generic/BTS_Tests.TC_data_rtp_tchh24.pcap.gz
https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/lastCompletedBuild/artifact/logs/bts-tester-generic/BTS_Tests.TC_data_rtp_tchh48.pcap.gz

>> we even have TTCN-3 testcases for that.
> Do they check for the current behaviour which I view as a bug?

These TCs only check if the channel can be activated and data (a special 
bit pattern) can flow in both directions.  We should definitely make 
them stricter about the RTP packet timings.

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

I agree that there exists no logic that would ensure proper alignment in 
Downlink radio blocks by looking at bit E1.  We're naively assuming that 
the incoming RTP stream contains only aligned blocks.

I was puzzled when I read that "E2 bit is always 0 in RTP output", but 
after checking the code more carefully I see there's a problem indeed.

Bits E1/E2/E3 are set here:

https://gitea.osmocom.org/cellular-infrastructure/osmo-bts/src/branch/master/src/common/csd_v110.c#L109

(Sadly, our lovely cgit instance is down for some reason, so I am 
posting a link to less favorable Gitea/Forgejo.)

The problem is that `desc->num_blocks` is 2 for TCH/F4.8 NT, so the 
for-loop in csd_v110_rtp_encode() iterates only 2 (not 4) times, and 
thus `(i >> 1) & 0x01` never evaluates to 1 in this channel mode.

Here is my attempt to fix the Uplink part of the problem:

https://gerrit.osmocom.org/c/osmo-bts/+/38301

Here is a WIP/draft patch for the Downlink part, currently just dropping 
RTP packets carrying unaligned halves:

https://gerrit.osmocom.org/c/osmo-bts/+/38303 [WIP]

For TCH/9.6 we can just swap the two halves in case they're not aligned.
For TCH/4.8 we can store unaligned halves in some buffer...

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

I did not foresee this problem, thanks for pointing it out.  Likewise, 
feel free to create a ticket!  Even if the patch fixing the RTP output 
get merged soon, I don't expect myself to get back to the unaligned 
input problem soon due to other high-prio projects/tasks...

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

Unfortunately, I am not aware of such a modem/phone that can do 
half-rate data calls.  I'll check in my collection.

-- 
Best regards,
Vadim.