Half-rate data calls (CSD)
Mychaela Falconia
falcon at freecalypso.org
Thu Sep 26 22:12:07 UTC 2024
Hi Vadim,
> > 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.
The actual history, in forward chronological order, is something like
this:
1) For debug purposes only, TI made the intermediate interface between
speech enc/dec and channel enc/dec blocks accessible to the ARM core
by placing those a_dd_x & a_du_x buffers in the NDB API RAM page,
instead of non-ARM-accessible DSP private RAM.
1a) As a further debug/test feature, they implemented "UL play" mode
in which the output of the speech encoder can be suppressed and
replaced (at channel encoder input) with externally supplied bits.
This debug feature is NOT used by any of TI's production firmwares!
2) At some point (seems to be early in project history) OBB folks
discovered the existence of DSP debug features 1 & 1a, probably by
noticing conditioned-out (not actually compiled, and won't work if
enabled) code in TSM30 and LoCosto L1 sources that uses this mechanism
for an external loopback test where some instrument such as CMU200
receives UL and loops it back to DL. It was discovered that this
mechanism can be (ab)used to route DL voice to somewhere other than
the phone's earpiece speaker, and to source UL voice from somewhere
other than the phone's built-in mic; OBB thus acquired support for
such redirected voice operation.
3) Some time in late 2015 or early 2016 I was approached by some
"mystery" people (the kind who felt I had no need to know who they
were or what they were doing) who asked for a similar feature in
FreeCalypso. Mind you, this development was in early 2016 at the
latest, we had no FC Magnetite yet, not even FC Citrine, all we had
was the original "FreeCalypso GSM fw" that was utterly broken and
unusable. But I was badly in need of money, hence I agreed to work
with said "shadowy" people and implemented the feature they asked for.
Unfortunately I don't even know if that customer actually got what
they wanted for their money: because they were so secretive, the exact
requirements weren't communicated clearly, and I never received any
feedback. But that is how support for TCH tap modes appeared for the
first time in FreeCalypso.
4) My own attempts to use that commercially-sponsored TCH Rx feature
for more standard and open (no weird secrets) voice communication were
a failure back in 2016. Back then I incorrectly thought that the
output of GSM 05.03 channel decoder goes directly to the input of
GSM 06.10 speech decoder (I was only playing with FRv1 at the time),
but there was a key missing piece: the Rx DTX handler block, which
implements BFI handling, SID detection, error concealment and comfort
noise insertion, has to go between the other two blocks. (Looking at
the world of gapk and related support in OBB, I get a feeling that
Osmocom people at the time made the same oversight as I did.) Trying
to feed TCH DL Rx directly to libgsm produced horrible sounds, hence
I shelved the idea, and it remained shelved for years.
5) In 2022, in connection with my new work on the network side of GSM,
I learned the proper structure of this chain:
05.03 channel decoder -> Rx DTX handler -> 06.10 speech decoder
When I implemented libgsmfrp for the Rx DTX handler function (now
subsumed into libgsmfr2), I revisited the TCH tap feature of our dear
Calypso, and voila, it actually works when the decoder chain is
implemented correctly! That's how we got present-day TCH DL sniffing
and TCH UL substitution support in current FC.
6) On OBB side, when you took on the task of adding CSD support, you
must have discovered that the same mechanism that was previously used
to route voice externally (in raw codec-bits form) can also be used to
receive DL and feed UL for CSD. You may or may not have known at the
time that this DSP feature is only a debug mode not meant for
production use - but you do know now. :)
[HR CSD problem in OsmoBTS]
> Ack, this is a known problem. We don't have a ticket for it, so you're
> welcome to create one ;)
OS#6577.
[TCH/F4.8 NT handling]
> 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.
Yes, that's exactly how I concluded (from reading the code only,
having no test setup) that the logic is currently wrong.
> Here is my attempt to fix the Uplink part of the problem:
> https://gerrit.osmocom.org/c/osmo-bts/+/38301
Unfortunately I had to CR-2 this patch: this approach can't possibly
work because bit E7 (and the entire group of NIC bits) does not exist
in NT mode. As I wrote in Gerrit, the only workable solution here is
to pass an additional flag to the function from outside, indicating
the alignment position with respect to the 26-multiframe.
An example of how the same problem is addressed on GSM MS side:
https://www.freecalypso.org/hg/fc-tourmaline/file/tip/src/cs/layer1/cfile/l1_cmplx.c#l5072
Basically we have to figure out the correct frame numbers (may be
different for network vs MS, will have to check) and pass a flag into
CSD V.110 encoding function, only for this one mode.
> 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...
What we really need to do is force an artificial phase shift in the
Rx jitter buffer if and when we detect that the phase of the incoming
RTP stream does not match the phase needed for radio DL output. (I
have no spare mental capacity for AMR currently, but I suspect a
similar problem exists there in terms of CMI/CMR phase: what if the
incoming RTP stream changes actually-used modes out-of-phase with CMI
frame positions on the DL?) And since we have to deal with the jitter
buffer here, this brings us to:
I propose that we pause this effort until after we address the idea of
making themwi-rtp-lib an optional alternative to libortp. When using
themwi-rtp-lib, I can produce quite elegant implementation of whatever
phase shifts are needed, whether for TCH/F4.8 NT or for AMR CMI/CMR;
but libortp is a bone in my throat.
Speaking of which: I need to update OS#6474 with the current status of
themwi-rtp-lib...
> I did not foresee this problem, thanks for pointing it out. Likewise,
> feel free to create a ticket!
OS#6578.
Effort to be continued...
M~
More information about the Community
mailing list