Project

General

Profile

Actions

Feature #1572

open

Circuit Switched Data (CSD) Support in osmo-bts

Added by laforge over 7 years ago. Updated about 15 hours ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
osmo-bts-trx
Target version:
-
Start date:
02/23/2016
Due date:
% Done:

0%

Spec Reference:
Tags:
CSD

Description

Not implemented, but also probably limited interest, except
  • GSM-R heavily uses CSD and might be an intresting niche market
  • some end-to-end encrypted mobile phones also use CSD

This will need the corresponding support in the PHY, of course.


Checklist

  • add the E1/E2/E3 bits to the decoded v.110 frame based on out-of-band knowledge of user bit rate (2400/4800/9600)
  • TS 45.003 coding / interleaving
  • RSL CHAN ACT for CT
  • RA1'/RA1 rate adaptation from/to 64k
  • RFC4040 clear-mode RTP payload

Related issues

Related to OsmoBSC - Feature #4393: Circuit Switched Data (CSD) Support in osmo-bscFeedbacklaforge02/13/2020

Actions
Related to OsmoMSC - Feature #4394: Circuit Switched Data (CSD) Support in osmo-mscIn Progressosmith02/13/2020

Actions
Related to OsmoMGW - Feature #4395: Circuit Switched Data (CSD) Support in osmo-mgwResolvedosmith02/13/2020

Actions
Related to OsmocomBB - Feature #4396: Circuit Switched Data (CSD) Support in osmocom-bbIn Progressfixeria02/13/2020

Actions
Blocked by OsmocomBB - Bug #6001: osmo-gsm-tester_virtual: netreg_mass fails: Message MM_EVENT_NO_CELL_FOUND unhandled in state MM idleResolvedfixeria04/12/2023

Actions
Actions #1

Updated by laforge over 3 years ago

  • Checklist item TS 45.003 coding / interleaving added
  • Checklist item RSL CHAN ACT for CT added
  • Checklist item RA1'/RA1 rate adaptation from/to 64k added
  • Checklist item RFC4040 clear-mode RTP payload added
The support in OsmoBTS would entail:
  • implementation of the 45.003 coding / interleaving for the TCH/F9.6, TCH/F4.8, TCH/F2.4, ... channel types
  • activating the above coding/interleaving based on RSL CHAN ACT for such channels
  • performing the RA1'/RA1 rate adaptation function to get from/to 64kbps stream
  • packetize 64k stream as raw "CLEARMODE/8000" RTP as per RFC4040; 160 bytes per RTP packet; RTP payload type 120
Some relevant specs:
  • 3GPP TS 48.004 E1/T1 based L1
  • 3GPP TS 48.020 Rate Adaptation on BSS-MSC interface (RA1)
  • 3GPP TS 48.103 User plane transport / Section 5.6
  • 3GPP TS 44.021 RA1' adaptation function on radio interface
  • 3GPP TS 24.022 RLP for CS bearer and teleservices
  • 3GPP TS 43.010 PLMN connection types
  • ITU-T V.110 RA0 for async->sync

The coding/interleaving part has been started in the laforge/csd branch of libosmocore.git

Actions #2

Updated by laforge over 3 years ago

  • Tags set to CSD
  • Subject changed from Circuit Switched Data Support to Circuit Switched Data (CSD) Support

IMHO, it only makes sense to support the transparent mode (no RLP protocol).

Actions #3

Updated by laforge over 3 years ago

  • Related to Feature #4393: Circuit Switched Data (CSD) Support in osmo-bsc added
Actions #4

Updated by laforge over 3 years ago

  • Related to Feature #4394: Circuit Switched Data (CSD) Support in osmo-msc added
Actions #5

Updated by laforge over 3 years ago

  • Related to Feature #4395: Circuit Switched Data (CSD) Support in osmo-mgw added
Actions #6

Updated by laforge over 3 years ago

  • Category set to osmo-bts-trx

Some more notes:

  • Racal 6103 supports termination of data + fax CSD calls (external PC can be connected on RS232). This could be used to establish air-interface (burst level) captures using burst_ind. That in turn could generate test data for the 45.003 de-interleave/decoder part.
  • support in OsmoBTS would be restricted to osmo-bts-trx, as to our current knowledge none of the proprietary PHYs (osmo-bts-{sysmo,lc15,oc2g,octphy} support CSD channel coding
Actions #7

Updated by laforge over 3 years ago

  • Related to Feature #4396: Circuit Switched Data (CSD) Support in osmocom-bb added
Actions #8

Updated by laforge 6 months ago

  • Subject changed from Circuit Switched Data (CSD) Support to Circuit Switched Data (CSD) Support in osmo-bts
Actions #9

Updated by laforge 6 months ago

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

Actions #10

Updated by laforge 4 months ago

  • Priority changed from Low to Normal
Actions #12

Updated by laforge 3 months ago

  • Status changed from New to In Progress
Convolutional coding + interleaving submitted in

That code has been validated against an Um air interface trace beetween a Racal 6103 and a BGS-2 GSM Modem using 9600bps non-transparent bearer type.

Actions #13

Updated by laforge 3 months ago

timing wise, we have (assuming TCH/F9.6 downlink on the BTS side):
  • 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
Actions #14

Updated by laforge 3 months ago

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

For osmo-bts this nees to be modified/adapted to:
  • 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)
Plus, of course, the reverse procedure on encode:
  • 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
The primariy importance is to implement support for TCH/F9.6 and TCH/F4.8. The 9.6kbps example is shown above. For 4.8kbps we have the gsm0503_tch_f48 convolutional code, resulting in a 6kbps radio interface rate, which is converted to an 8kbps intermediate rate, which in the end uses an 8k sub-slot in the I460 multiplex. So we
  • 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?

Actions #15

Updated by fixeria 3 months ago

  • Assignee set to fixeria

I will focus on the scheduler part of this task. If it goes well, I can also handle the rest.

Actions #16

Updated by laforge 3 months ago

  • Checklist item add the E1/E2/E3 bits to the decoded v.110 frame based on out-of-band knowledge of user bit rate (2400/4800/9600) added
Actions #17

Updated by fixeria 3 months ago

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.

Actions #18

Updated by fixeria 2 months ago

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

Actions #19

Updated by fixeria 2 months ago

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.

Actions #20

Updated by fixeria about 2 months ago

  • Status changed from In Progress to Stalled
Actions #21

Updated by pespin about 2 months ago

  • Blocked by Bug #6001: osmo-gsm-tester_virtual: netreg_mass fails: Message MM_EVENT_NO_CELL_FOUND unhandled in state MM idle added
Actions #22

Updated by fixeria 15 days ago

  • Status changed from Stalled to In Progress
Actions #23

Updated by fixeria 14 days ago

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.

Actions #24

Updated by fixeria 11 days ago

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.

Actions #25

Updated by laforge 11 days ago

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.

Actions #26

Updated by fixeria 10 days ago

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.
Actions #27

Updated by fixeria 5 days ago

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

Actions #28

Updated by fixeria 4 days ago

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]

Actions #29

Updated by fixeria about 15 hours ago

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.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)