Feature #1572
openCircuit Switched Data (CSD) Support in osmo-bts
0%
Description
- 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
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
- 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
- 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
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).
Updated by laforge over 3 years ago
- Related to Feature #4393: Circuit Switched Data (CSD) Support in osmo-bsc added
Updated by laforge over 3 years ago
- Related to Feature #4394: Circuit Switched Data (CSD) Support in osmo-msc added
Updated by laforge over 3 years ago
- Related to Feature #4395: Circuit Switched Data (CSD) Support in osmo-mgw added
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
Updated by laforge over 3 years ago
- Related to Feature #4396: Circuit Switched Data (CSD) Support in osmocom-bb added
Updated by laforge 3 months ago
- 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
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
andosmo_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
- call
- encode the resulting 4x 60bit using
gsm0503_tch_f96_interleave
/osmo_conv_encode(gsm0503_tch_f96)
- transmit resulting bursts
- for each of the 80-bit V.110 frames contained
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?
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.
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
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.
Updated by fixeria about 2 months ago
- Status changed from In Progress to Stalled
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
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.
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.
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.
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.
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()
.
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]
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.