Cellular Network Infrastructure » Radio Access Network » OsmoBTS

The minimal feature set we need to support is support for transparent, asynchronous at speeds 2400/4800/9600 bps.

• one 60-bit modified V.110 frame every 5ms
  • convert each of them to a normal 80-bit V.110 frame using RA1'/RA1 (resulting intermediate rate 16kbps)
  • batch four of them togethger to get from 5ms to 20ms duration
  • perform I.460 to get from 16kbps to 64kbps
  • transmit resulting 20ms @ 64kbps as RTP payload type 120

The decode of received bursts (uplink or downlink) has been hacked up in https://gitea.osmocom.org/phone-side/osmocom-bb/src/branch/laforge/csd_decode/src/host/layer23/src/misc/burst_process.c

• handle the 22-burst deinterleave/decode (via calling gsm0503_tch_f96_deinterleave and osmo_conv_decode(gsm0503_tch_f96)) from sched_lchan_tchf.c
  • this generates 240 output bits for 20ms
• iterate over the four frames contained in those 240 bits (60 bits each)
  • call @osmo_csd_12k_6k_decode_frame() to generate decoded/abstract 80bit V.110 frames from the 60bit CSD-modified frames
  • call osmo_v110_encode_frame() to encode the abstract V.110 frame into a 80bit V.110 frame
  • feed the resulting output data (16kbps, i.e. 80bit every 5ms) as 16k rate at sub-slot 0 into an 16k I.460 mux. This generates a 64kbps output stream. As we generate output for four V.110 frames (20ms), we generate 160 bytes.
  • transmit the output as 160byte RTP (RFC4040 clear-mode)

• receive 160byte RTP clearmode packets
• feed into I.460 demux, extract only 16k sub-slot 0
  • for each of the 80-bit V.110 frames contained
    • call osmo_v110_decode_frame
    • call osmo_csd_12k_6k_encode_frame
  • encode the resulting 4x 60bit using gsm0503_tch_f96_interleave / osmo_conv_encode(gsm0503_tch_f96)
  • transmit resulting bursts

• receive 60bit every 10ms (instead of 60bit every 5ms)
• use the same osmo_csd_12k_6k_decode_frame -> osmo_v110_encode_frame chain to go from 60bit to 80bit V.110 frames
• batch two 80-bit V.110 frames (so we again have 20ms worth of data)
• feed that through an 8k I.460 mux to get 20ms worth of 64kbps data

Maybe this is something fixeria or Hoernchen would want to pick up?

Intermediate status update: so far I cleaned up the scheduler a bit, so that a) we have consistent activation/deactivation approach for all kinds of lchans (no more implicit auto-active flag), and b) the burst buffers are allocated/free()d in a single place, rather than in each lchan handler individually. This will allow us to enlarge the buffers dynamically for lchans activated/modified for CSD.

https://gerrit.osmocom.org/c/osmo-bts/+/31716 osmo-bts-trx: properly activate [CBCH/]BCCH/CCCH
https://gerrit.osmocom.org/c/osmo-bts/+/31672 osmo-bts-trx: alloc/free burst buffers in trx_sched_set_lchan()

Both patches have been tested by running ttcn3-bts-test, no regressions observed.

Among with that, I have a draft patch integrating the GSM 05.03 coding/interleaving API from libosmocoding, however I am unable to test it properly yet because for some reason in osmo-bts we're using the RR specific channel mode values (see `lchan->tch_mode`) instead of the RSL specific ones. The problem is that there seems to be no one-to-one mapping between the RR and RSL values, so osmo-bts needs to be migrated to use the RSL values instead. I will see if I can solve/workaround this without having to refactor lots of code.

I implemented a very simplistic testcase in ttcn3-bts-test that activates a TCH/F for CSD (RSL_CMOD_CSD_T_9k6) and then immediately deactivates it.
osmo-bts currently NACKs the CHANnel ACTIVation request, so the testcase fails:

20230322052340703 DRSL INFO (bts=0,trx=0,ts=1,pchan=TCH/F) ss=0 Rx RSL CHAN_ACTIV (rsl.c:3720)
20230322052340703 DRSL ERROR (bts=0,trx=0,ts=1,ss=0) Channel Mode IE contains unhandled transparent CSD data rate 0x10 (rsl.c:208)
20230322052340703 DRSL NOTICE (bts=0,trx=0,ts=1,ss=0): Sending Channel Activated NACK: cause = 0x68 (rsl.c:1368)

I also found and fixed a bug in Wireshark causing incorrect dissection of the Channel Mode IE:

https://gitlab.com/wireshark/wireshark/-/merge_requests/10120

I figured out the mapping between RSL Channel Mode and RR Channel Mode values:

https://gerrit.osmocom.org/c/libosmocore/+/32023 gsm_04_08: document/clarify enum gsm48_chan_mode values [NEW]
https://gerrit.osmocom.org/c/libosmocore/+/32024 gsm_04_08: add more enum gsm48_chan_mode speech values [NEW]
https://gerrit.osmocom.org/c/libosmocore/+/32025 gsm_04_08: add more enum gsm48_chan_mode data values [NEW]
https://gerrit.osmocom.org/c/libosmocore/+/32026 gsm0808: handle new enum gsm48_chan_mode speech/data values [NEW]
https://gerrit.osmocom.org/c/osmo-bts/+/32027 rsl: rsl_handle_chan_mod_ie(): add missing GSM48_CMODE_* values [NEW]

This makes me closer to the goal of implementing the RSL CHANnel ACTIVation for CSD. Now I need to modify bts_supports_cm() to handle the new CSD related values. I see we already have BTS_FEAT_ECSD and BTS_FEAT_HSCSD, but not BTS_FEAT_CSD? I am planning to add one, since only osmo-bts-trx will be supporting CSD.

I reworked one of my old patches and addressed code review comments:

https://gerrit.osmocom.org/c/osmo-bts/+/31672 osmo-bts-trx: alloc/free burst buffers in trx_sched_set_lchan()
https://gerrit.osmocom.org/c/osmo-bts/+/32726 osmo-bts-trx: use direct pointer to chan_state->{ul,dl}_bursts

I also submitted a Work-in-Progress patch implementing TCH/F9.6:

https://gerrit.osmocom.org/c/osmo-bts/+/32727 [WIP] osmo-bts-trx: implement TCH/F9.6 support for CSD [NEW]

The actual channel coding logic is yet commented out, because we're missing proper burst mapping and FACCH handling.

fixeria wrote in #note-23:

I also submitted a Work-in-Progress patch implementing TCH/F9.6:

https://gerrit.osmocom.org/c/osmo-bts/+/32727 [WIP] osmo-bts-trx: implement TCH/F9.6 support for CSD [NEW]

I reworked this patch to prepare the scheduler for integrating various CSD specific TCH/F and TCH/H modes. The actual enc/dec logic is still missing - I am implementing it in libosmocore.git (new libosmocoding API). Currently running ttcn3-bts-test to see if there are any unexpected regressions caused by the associated changes.

Interestingly enough, TCH/F2.4 is somewhat special because unlike the other CSD specific modes the encoded data in this mode is interleaved over 8 consecutive bursts, so it's quite similar to regular TCH/FS (speech). For half-rate CSD we have only two channels modes: TCH/H2.4 and TCH/H4.8. Both of them are quite similar to TCH/F9.6 and employ the same interleaving algorithm, but this similarity with the full-rate CSD brings some additional complexity. One of the problems is that for half-rate CSD modes we need to perform a decoding attempt every 4th burst, while for half-rate speech we invoke the decoder every 2nd burst.

Handling of FACCH is another interesting topic. 3GPP TS 45.003 section 4.2.5 says that FACCH "disturbs" N coded bits (depending on channel mode) from the data block. So AFAIU, it does not steal the whole CSD data block, but only part of it. Not sure though what are the use cases for FACCH on CSD channels.

thanks for the update. Note that TCH/F is currently still the only mandatory feature, and
specifically only the 2.4/4.8/9.6 kBps user rates above it. Let's make sure we focus our energy
where we really need it rather than trying to implement everything else which is not needed.

laforge wrote in #note-25:

thanks for the update. Note that TCH/F is currently still the only mandatory feature, and
specifically only the 2.4/4.8/9.6 kBps user rates above it. Let's make sure we focus our energy
where we really need it rather than trying to implement everything else which is not needed.

Ack. So far I implemented TCH/F9.6, TCH/[FH]4.8, TCH/H2.4, and TCH/F14.4 in libosmocoding:

https://gerrit.osmocom.org/c/libosmocore/+/32805 coding: use GSM_MACBLOCK_LEN gsm0503_tch_fr_decode() [NEW]
https://gerrit.osmocom.org/c/libosmocore/+/32806 coding: gsm0503_tch_f96_[de]interleave() not applicable to TCH/F2.4 [NEW]
https://gerrit.osmocom.org/c/libosmocore/+/32807 coding: declare gsm0503_tch_f96_[de]interleave() [NEW]
https://gerrit.osmocom.org/c/libosmocore/+/32808 coding: implement TCH/F9.6, TCH/[FH]4.8, TCH/H2.4, TCH/F14.4 [NEW]

all these CSD specific modes are quite similar to each other; TCH/H4.8 is fully identical to TCH/F9.6.

What's missing is:

• TCH/F2.4, which is more similar to TCH/FS and slightly more complicated,
• FACCH/F and FACCH/H - I don't know how to implement this properly.

Yesterday I spent some time on libosmocoding adding the unit tests and fixed several problems:

• the encoding functions were overwriting all bits in the given ubit_t buffer, corrupting bits of other diagonal-interleaved blocks - this is fixed in the new patchset revisions;
• the convolutional code definition for TCH/F4.8 was incorrect, causing a buffer overrun - https://gerrit.osmocom.org/c/libosmocore/+/32986.

I also changed all encoding and decoding functions to operate on unpacked bits instead of packed bits (bytes). This gives us some additional flexibility: for transparent services we can easily feed these unpacked bits to osmo_csd_xxxx_decode_frame(); for non-transparent services we can invoke osmo_ubit2pbit_ext().

I've implemented FACCH/[FH] coding API in separate functions, as was suggested by falconia (thanks!):

https://gerrit.osmocom.org/c/libosmocore/+/33003 coding: implement dedicated codec API for FACCH/[FH] [NEW]
https://gerrit.osmocom.org/c/libosmocore/+/33004 coding: test FACCH/[FH] bitstealing in test_csd() [NEW]
https://gerrit.osmocom.org/c/libosmocore/+/33005 coding: fix _tch_csd_burst_map(): do not overwrite FACCH [NEW]

TTCN-3 testcases:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33071 BTS_Tests: f_TC_speech_rtp(): run TCH and SACCH loops [NEW]
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33072 BTS_Tests: add TC_data_rtp_tch* for CSD [NEW]

Thanks to them, I fixed several problems and segfaults in both osmo-bts and osmocom-bb. One of the major problems was in rx_tchf_fn():

/* shift the buffer by 4 bursts leftwards */
if (bi->bid == 0) {
    memmove(&bursts_p[0], &bursts_p[4 * BPLEN], 18 * BPLEN);
    memset(&bursts_p[18 * BPLEN], 0, 4 * BPLEN);
    *mask = *mask << 4;
}

/* ... */

/* copy burst to end of buffer of 22 bursts */
burst = bursts_p + (bi->bid + 18) * BPLEN;
if (bi->burst_len > 0) {
    memcpy(burst, bi->burst + 3, 58);
    memcpy(burst + 58, bi->burst + 87, 58);
} else
    memset(burst, 0, BPLEN);

The problem can be visualized as follows:

  00  01  02  03  04  05  06  07  08  09  10  11  12  13  14  15  16  17  18  19  20  21 
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   | a | b | c | d |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|   |   |   |   |   |   |   |   |   |   |   |   |   |   | a | b | c | d | e | f | g | h |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|   |   |   |   |   |   |   |   |   |   | a | b | c | d | e | f | g | h | i | j | k | l |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|   |   |   |   |   |   | a | b | c | d | e | f | g | h | i | j | k | l | m | n | o | p |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|   |   | a | b | c | d | e | f | g | h | i | j | k | l | m | n | o | p | q | r | s | t |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| c | d | e | f | g | h | i | j | k | l | m | n | o | p | q | r | s | t | u | v | a | b |  <-- we lost bursts 'a' and 'b'
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
^
|--- decoding attempt happens here every bid==3

If we allocate a buffer which can fit up to 22 bursts and memcpy() new bursts at (bi->bid + 18) * BPLEN, after shifting the buffer we end decoding bursts at incorrect offset and thus getting unexpected results. I changed the code to allocate buffers which can fit up to 24 bursts and memcpy() new bursts at (bi->bid + 20) * BPLEN.

So far I managed to get working only TCH/F9.6 and TCH/F4.8; it needs to be investigated why other channel modes are not working.