Project

General

Profile

Actions

Feature #1572

closed

Circuit Switched Data (CSD) Support in osmo-bts

Added by laforge almost 8 years ago. Updated 4 months ago.

Status:
Resolved
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
  • TS 45.003: missing TCH/F2.4 channel coding
  • TS 45.003: missing FACCH/[FH]

Related issues

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

Actions
Related to OsmoMSC - Feature #4394: Circuit Switched Data (CSD) Support in osmo-mscResolvedosmith02/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-bbResolvedfixeria02/13/2020

Actions
Related to OsmoBTS - Bug #6145: osmo-bts-trx: verify correctness of the CSD rate adaptationResolvedmanawyrm08/24/2023

Actions
Related to OsmoBTS - Bug #6166: ttcn3-bts-test: TC_data_rtp_tchh48 and TC_data_rtp_tchh24 are failingRejectedfixeria09/01/2023

Actions
Related to OsmoBTS - Feature #6167: csd_v110: implement rate adaptation for TCH/F14.4New09/01/2023

Actions
Related to OsmoBTS - Bug #6168: osmo-bts-trx: proper measurement aggregation for CSDResolvedfixeria09/01/2023

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
Blocked by OsmoMSC - Bug #6110: modem-to-modem data call establishment failureResolvedfixeria07/22/2023

Actions
Actions #1

Updated by laforge about 4 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 about 4 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 about 4 years ago

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

Updated by laforge about 4 years ago

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

Updated by laforge about 4 years ago

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

Updated by laforge about 4 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 about 4 years ago

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

Updated by laforge over 1 year ago

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

Updated by laforge over 1 year 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 about 1 year ago

  • Priority changed from Low to Normal
Actions #12

Updated by laforge 12 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 12 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 12 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 12 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 12 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 12 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 11 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 11 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 11 months ago

  • Status changed from In Progress to Stalled
Actions #21

Updated by pespin 11 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 9 months ago

  • Status changed from Stalled to In Progress
Actions #23

Updated by fixeria 9 months 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 9 months 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 9 months 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 9 months 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 9 months 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 9 months 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 9 months 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 #30

Updated by fixeria 9 months ago

  • Status changed from In Progress to Stalled

fixeria wrote in #note-29:

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.

Unfortunately no progress on that since the last ticket update. Last week I worked on the following:

[1] https://cgit.osmocom.org/osmo-bts/commit/?id=282c87ab2de57bd8e36417d8553d39497b3e674c

I have to put this task on hold again because I need to work on #5500. Will resume working on this ticket next week.

Actions #31

Updated by fixeria 9 months ago

  • Checklist item TS 45.003: missing TCH/F2.4 channel coding added
  • Checklist item TS 45.003: missing FACCH/[FH] added
  • Checklist item TS 45.003 coding / interleaving set to Done
  • Checklist item RSL CHAN ACT for CT set to Done
  • Checklist item RFC4040 clear-mode RTP payload set to Done

Taking a chance to update the checkbox items:

  • The channel coding and interleaving is implemented and works. We're still missing TCH/F2.4 and FACCH.
  • RSL CHAN ACT is implemented and works, my TTCN-3 testcases do channel act/deact.
  • RFC4040 clear mode payload: there is nothing we need to do, it works AFAICT.

The rate adaptation can be quickly implemented once we get all TCH/[FH] channel modes to work with my WIP TTCN-3 tests.

Actions #32

Updated by fixeria 8 months ago

  • Status changed from Stalled to In Progress
Actions #33

Updated by fixeria 8 months ago

fixeria wrote in #note-29:

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.

I managed to get the TCH/F14.4 working, the problem was using uint8_t for the TCH.ind prim length parameter, which obviously cannot represent values like 290:

https://gerrit.osmocom.org/c/osmo-bts/+/33585 scheduler: use size_t for data_len in sched_compose*_ind() [NEW]

While debugging this, I also submitted several more fixes and improvements:

https://gerrit.osmocom.org/c/osmo-bts/+/33581 scheduler: fix wrong union field in sched_compose_tch_ind() [NEW]
https://gerrit.osmocom.org/c/osmo-bts/+/33582 scheduler: use msgb_hexdump_l2() in _sched_compose_tch_ind() [NEW]
https://gerrit.osmocom.org/c/osmo-bts/+/33583 scheduler: unify argument names/order for _sched_compose
*_ind() [NEW]
https://gerrit.osmocom.org/c/osmo-bts/+/33584 scheduler: constify data pointer in sched_compose_ind() [NEW]

Now let's see what makes the TCH/H tests unhappy.

Actions #34

Updated by fixeria 8 months ago

fixeria wrote in #note-33:

Now let's see what makes the TCH/H tests unhappy.

Turns out it's a primitive management problem in trxcon. With a few hacks I got both TCH/H4.8 and TCH/H2.4 passing.
This proves that the implementation of all CSD channels types in osmo-bts.git is correct, except the TCH/F2.4, which is still missing.

Actions #35

Updated by fixeria 8 months ago

  • Checklist item TS 45.003: missing FACCH/[FH] set to Done

Here is a not fully tested implementation:

https://gerrit.osmocom.org/c/osmo-bts/+/33586 osmo-bts-trx: implement FACCH/[FH] support for CSD

All I can say is that it does not break my Work-in-Progress TTCN-3 testcases. I still need to port this patch to trxcon and write additional testcases verifying FACCH/[FH] transmission over data channels.

Actions #36

Updated by fixeria 8 months ago

  • Checklist item TS 45.003: missing TCH/F2.4 channel coding set to Done

https://gerrit.osmocom.org/c/libosmocore/+/33650 coding: implement encoding/decoding API for TCH/F2.4 [NEW]
https://gerrit.osmocom.org/c/osmo-bts/+/33651 osmo-bts-trx: implement TCH/F2.4 support for CSD [NEW]

Actions #37

Updated by fixeria 7 months ago

All patches have been merged, so the only missing part is the rate adaptation.

Actions #38

Updated by fixeria 7 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) set to Done
  • Checklist item RA1'/RA1 rate adaptation from/to 64k set to Done
  • Status changed from In Progress to Feedback

Here is a patch implementing the rate adaptation:

https://gerrit.osmocom.org/c/osmo-bts/+/33832 l1sap: proper rate adaptation for CSD (RFC4040 'clearmode') [NEW]

I am not familiar with V.110/I.460/etc. at all, so would be great if laforge could confirm correctness of the implementation.
Note that I intentionally did not use the existing I.460 code from libosmocore.git for the sake of simplicity.

Actions #39

Updated by laforge 7 months ago

fixeria wrote in #note-38:

https://gerrit.osmocom.org/c/osmo-bts/+/33832 l1sap: proper rate adaptation for CSD (RFC4040 'clearmode') [NEW]

I am not familiar with V.110/I.460/etc. at all, so would be great if laforge could confirm correctness of the implementation.

The best way to do this validation would be to set up a CSD call between two MS and take a pcap file of the V.110 data in RTP CLEARMODE. I do have existing V.110 code for decoding such captures, which I validated against ISDN equipment doing V.110. So if the same tools can decode the V.110 in RTP clearmode, we can be satisfied with it.

Note that I intentionally did not use the existing I.460 code from libosmocore.git for the sake of simplicity.

I hope the latter really only applies to the I.460. The V.110 to "CSD specific V.110" conversion is present in libosmocore (with unit tests) and should definitely be used.

Actions #40

Updated by fixeria 7 months ago

laforge wrote in #note-39:

I am not familiar with V.110/I.460/etc. at all, so would be great if laforge could confirm correctness of the implementation.

The best way to do this validation would be to set up a CSD call between two MS and take a pcap file of the V.110 data in RTP CLEARMODE. I do have existing V.110 code for decoding such captures, which I validated against ISDN equipment doing V.110. So if the same tools can decode the V.110 in RTP clearmode, we can be satisfied with it.

Ok, will do! I'll also add unit tests as was suggested by Oliver during code review.

Note that I intentionally did not use the existing I.460 code from libosmocore.git for the sake of simplicity.

I hope the latter really only applies to the I.460. The V.110 to "CSD specific V.110" conversion is present in libosmocore (with unit tests) and should definitely be used.

Ack. I am using libosmocore's API for the RA1'/RA1 conversion, but my own implementation for the RA1/RA2 only.

Actions #41

Updated by fixeria 7 months ago

Found and fixed a NULL pointer dereference while testing a modem-to-modem data call:

https://gerrit.osmocom.org/c/osmo-bts/+/33858 osmo-bts-trx: tx_tch[fh]_fn(): fix NULL pointer dereference [NEW]

Actions #42

Updated by fixeria 7 months ago

  • Status changed from Feedback to Stalled

I am blocked by #6110 due to osmo-msc failing to switch a modem-to-modem call. The good news is that FACCH/F seems to be working fine on CSD channels with real UEs: the calling leg successfully completes the RR Assignment procedure.

Actions #43

Updated by fixeria 7 months ago

  • Blocked by Bug #6110: modem-to-modem data call establishment failure added
Actions #44

Updated by fixeria 7 months ago

(Note to myself) I am seeing lots of messages like this one while testing a modem-to-modem call (#6110):

DLMIB NOTICE osmo_ortp.c:0 ortp: rtp_session_avpf_enabled(): payload type not set, unreliable result returned.

It needs to be investigated why and how we end up with the RTP payload not being set.

Actions #45

Updated by fixeria 6 months ago

  • Related to Bug #6145: osmo-bts-trx: verify correctness of the CSD rate adaptation added
Actions #46

Updated by fixeria 6 months ago

laforge wrote in #note-39:

fixeria wrote in #note-38:

I am not familiar with V.110/I.460/etc. at all, so would be great if laforge could confirm correctness of the implementation.

The best way to do this validation would be to set up a CSD call between two MS and take a pcap file of the V.110 data in RTP CLEARMODE. I do have existing V.110 code for decoding such captures, which I validated against ISDN equipment doing V.110. So if the same tools can decode the V.110 in RTP clearmode, we can be satisfied with it.

I recorded a PCAP and created a separate ticket to track this. Please see #6145.

Actions #47

Updated by fixeria 6 months ago

Using two Calypso based SE K200 phones I tested the following data rates:

  • TCH/F14.4 (AT+CBST=75,0,0, 14400 bps) -- fail (missing rate adaptation)
  • TCH/F9.6 (AT+CBST=71,0,0, 9600 bps) -- works
  • TCH/F4.8 (AT+CBST=70,0,0, 4800 bps) -- works
  • TCH/F2.4 (AT+CBST=68,0,0, 2400 bps) -- works
  • TCH/F2.4 (AT+CBST=66,0,0, 1200 bps) -- works
  • TCH/F2.4 (AT+CBST=65,0,0, 300 bps) -- works

I think we can close this ticket once I'm done with the ortp related warnings.

Actions #48

Updated by fixeria 6 months ago

fixeria wrote in #note-44:

(Note to myself) I am seeing lots of messages like this one while testing a modem-to-modem call (#6110):

[...]

Here is a backtrace:

(gdb) bt
#0  my_ortp_logfn (domain=0x7ffff7ee4144 "ortp", lev=BCTBX_LOG_WARNING, 
    fmt=0x7ffff7ee56d0 "rtp_session_avpf_enabled(): payload type not set, unreliable result returned.", args=0x7fffffffd2b0)
    at ../../../src/libosmo-abis/src/trau/osmo_ortp.c:109
#1  0x00007ffff7ee05b3 in bctbx_logv () from /usr/lib/libortp.so.15
#2  0x00007ffff7ecd4ed in ?? () from /usr/lib/libortp.so.15
#3  0x00007ffff7ecd60a in rtp_session_avpf_enabled () from /usr/lib/libortp.so.15
#4  0x00007ffff7ecc9d4 in compute_rtcp_interval () from /usr/lib/libortp.so.15
#5  0x00007ffff7eccbec in rtp_session_run_rtcp_send_scheduler () from /usr/lib/libortp.so.15
#6  0x00007ffff7ed3782 in __rtp_session_sendm_with_ts () from /usr/lib/libortp.so.15
#7  0x00007ffff7f3350a in osmo_rtp_send_frame_ext (marker=false, duration=160, payload_len=160, payload=0xa0 <error: Cannot access memory at address 0xa0>, 
    rs=0x5555558d45c0) at ../../../src/libosmo-abis/src/trau/osmo_ortp.c:554
#8  osmo_rtp_send_frame_ext (rs=0x5555558d45c0, 
    payload=payload@entry=0x7fffffffd550 "????\377\177", '\377' <repeats 14 times>, "\277", '\377' <repeats 19 times>, "????", '\377' <repeats 16 times>, "\277", '\377' <repeats 19 times>, "????", '\377' <repeats 16 times>, "\277", '\377' <repeats 19 times>, "????", '\377' <repeats 16 times>, "\277", '\377' <repeats 19 times>, "0\326\377\377\377\177", payload_len=payload_len@entry=160, duration=160, marker=marker@entry=false) at ../../../src/libosmo-abis/src/trau/osmo_ortp.c:538
#9  0x000055555559df8e in send_ul_rtp_packet_data (data_len=<optimized out>, data=<optimized out>, fn=1127737, lchan=0x7ffff6b87df8)
    at ../../../../src/osmo-bts/src/common/l1sap.c:1843
#10 l1sap_tch_ind (tch_ind=0x5555558da1b0, l1sap=0x5555558da198, trx=<optimized out>) at ../../../../src/osmo-bts/src/common/l1sap.c:1979
#11 l1sap_up (trx=<optimized out>, l1sap=l1sap@entry=0x5555558da198) at ../../../../src/osmo-bts/src/common/l1sap.c:2184
#12 0x00005555555748b7 in _sched_compose_tch_ind (l1ts=l1ts@entry=0x555555884c70, fn=fn@entry=1127737, chan=<optimized out>, data=data@entry=0x7fffffffd730 "\001", 
    data_len=data_len@entry=240, ber10k=ber10k@entry=0, rssi=-76.1363602, ta_offs_256bits=66, link_qual_cb=73, is_sub=0 '\000')
    at ../../../../src/osmo-bts/src/common/scheduler.c:826
#13 0x000055555556c8a3 in rx_tchf_fn (l1ts=l1ts@entry=0x555555884c70, bi=bi@entry=0x7fffffffdbc0) at ../../../../src/osmo-bts/src/osmo-bts-trx/sched_lchan_tchf.c:333
#14 0x0000555555575cb3 in trx_sched_ul_burst (l1ts=0x555555884c70, bi=<optimized out>) at ../../../../src/osmo-bts/src/common/scheduler.c:1601
#15 0x0000555555568bed in trx_sched_route_burst_ind (trx=<optimized out>, bi=<optimized out>) at ../../../../src/osmo-bts/src/osmo-bts-trx/scheduler_trx.c:372
#16 0x0000555555564ee2 in trx_data_read_cb (ofd=<optimized out>, what=<optimized out>) at ../../../../src/osmo-bts/src/osmo-bts-trx/trx_if.c:1104
#17 0x00007ffff7bd2faf in poll_disp_fds (n_fd=<optimized out>) at ../../../../src/libosmocore/src/core/select.c:419
#18 _osmo_select_main (polling=polling@entry=0) at ../../../../src/libosmocore/src/core/select.c:457
#19 0x00007ffff7bd308e in osmo_select_main (polling=polling@entry=0) at ../../../../src/libosmocore/src/core/select.c:496
#20 0x00005555555a3834 in bts_main (argc=3, argv=<optimized out>) at ../../../../src/osmo-bts/src/common/main.c:429
#21 0x00007ffff7827cd0 in ?? () from /usr/lib/libc.so.6
#22 0x00007ffff7827d8a in __libc_start_main () from /usr/lib/libc.so.6
#23 0x0000555555562805 in _start ()

As can be seen, the problem is triggered by the Uplink path. The UE sent us an IDLE V.110 frame:

(gdb) frame 11
#11 l1sap_up (trx=<optimized out>, l1sap=l1sap@entry=0x5555558da198) at ../../../../src/osmo-bts/src/common/l1sap.c:2184
2184                    rc = l1sap_tch_ind(trx, l1sap, &l1sap->u.tch);
(gdb) p (char *)msgb_hexdump(l1sap->oph.msg)
$31 = 0x7ffff6c38aa4 "[L2]> 01 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01"...

which gets converted to 80-bit V.110 frame and then mapped to 160 bytes long RTP CLEARMODE payload.

It needs to be investigated why and how we end up with the RTP payload not being set.

As far as I can see, the payload type is actually set:

(gdb) frame 8
#8  osmo_rtp_send_frame_ext (rs=0x5555558d45c0, 
    payload=payload@entry=0x7fffffffd550 "????\377\177", '\377' <repeats 14 times>, "\277", '\377' <repeats 19 times>, "????", '\377' <repeats 16 times>, "\277", '\377' <repeats 19 times>, "????", '\377' <repeats 16 times>, "\277", '\377' <repeats 19 times>, "????", '\377' <repeats 16 times>, "\277", '\377' <repeats 19 times>, "0\326\377\377\377\177", payload_len=payload_len@entry=160, duration=160, marker=marker@entry=false) at ../../../src/libosmo-abis/src/trau/osmo_ortp.c:538
538     int osmo_rtp_send_frame_ext(struct osmo_rtp_socket *rs, const uint8_t *payload,
(gdb) p (int)rtp_session_get_recv_payload_type(rs->sess)
$32 = 120
(gdb) p (int)rtp_session_get_send_payload_type(rs->sess)
$33 = 120
Actions #49

Updated by fixeria 6 months ago

Below is an extract from the source code of ortp v5.2.73:

/**
 *
 *      Gets the payload description of the payload type \a index in the profile.
 *
 *@param prof an RTP profile (a #_RtpProfile object)
 *@param idx    the payload type number
 *@return the payload description (a PayloadType object)
**/
static ORTP_INLINE PayloadType * rtp_profile_get_payload(const RtpProfile *prof, int idx){
        if (idx<0 || idx>=RTP_PROFILE_MAX_PAYLOADS) {
                return NULL;
        }   
        return prof->payload[idx];
}

bool_t rtp_session_avpf_enabled(RtpSession *session) {
        PayloadType *pt = rtp_profile_get_payload(session->snd.profile, session->snd.pt);
        if (!pt){
                ortp_warning("rtp_session_avpf_enabled(): payload type not set, unreliable result returned.");
        }   
        return pt && (payload_type_get_flags(pt) & PAYLOAD_TYPE_RTCP_FEEDBACK_ENABLED);
}

From gdb we know that session->snd.pt is set to 120:

(gdb) p *rs->sess.snd.profile
$41 = {name = 0x7ffff6b0a6c0 "AV profile", payload = {0x7ffff7ef5640 <payload_type_pcmu8000>, 0x7ffff7ef5460 <payload_type_lpc1016>, 0x0, 
    0x7ffff7ef5400 <payload_type_gsm>, 0x7ffff7ef5340 <payload_type_g7231>, 0x0, 0x0, 0x7ffff7ef53a0 <payload_type_lpc>, 0x7ffff7ef55e0 <payload_type_pcma8000>, 
    0x7ffff7ef44a0 <payload_type_g722>, 0x7ffff7ef54c0 <payload_type_l16_stereo>, 0x7ffff7ef5520 <payload_type_l16_mono>, 0x0, 0x7ffff7ef52e0 <payload_type_cn>, 0x0, 
    0x0, 0x0, 0x0, 0x7ffff7ef5280 <payload_type_g729>, 0x0 <repeats 12 times>, 0x7ffff7ef4e60 <payload_type_h261>, 0x7ffff7ef4ec0 <payload_type_mpv>, 0x0, 
    0x7ffff7ef4e00 <payload_type_h263>, 0x0 <repeats 61 times>, 0x7ffff6b0a1a0, 0x7ffff6b0a0f0, 0x7ffff7ef4b00 <payload_type_amr>, 0x0 <repeats 29 times>}}

(gdb) p rs->sess.snd.profile->payload[120]
$44 = (PayloadType *) 0x0

So the problem is that there seems to be no matching profile for the CLEARMODE (120). The error message printed by ortp is rather confusing.

Actions #50

Updated by fixeria 6 months ago

fixeria wrote in #note-49:

So the problem is that there seems to be no matching profile for the CLEARMODE (120). The error message printed by ortp is rather confusing.

With this patch applied, I no longer see ortp emitted warnings in the logs:

https://gerrit.osmocom.org/c/libosmo-abis/+/34223 osmo_ortp: register a PayloadType for RTP_PT_CSDATA

Actions #51

Updated by fixeria 6 months ago

Adding some more things, for which we may want to create separate tickets:

Regarding the Uplink measurements, currently the logging is spammed with:

DMEAS ERROR measurement.c:683 (bts=0,trx=0,ts=3,ss=0) Incorrect number of SUB measurements detected! (1 vs exp 2)
Actions #52

Updated by fixeria 6 months ago

  • Status changed from Stalled to Resolved

fixeria wrote in #note-51:

Adding some more things, for which we may want to create separate tickets:

Patches reworked and submitted to Gerrit:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34276 library: RTP_Emulation: implement new RTPEM_MODE_LOOPBACK [NEW]
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34277 BTS_Tests: f_rtpem_activate(): make RTP payload type configurable [NEW]
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34278 BTS_Tests: decouple payload generation from f_rtpem_activate() [NEW]
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33072 BTS_Tests: add TC_data_rtp_tch* for CSD [WIP]

Running them on my machine I am getting the following results:

pass->FAIL BTS_Tests.TC_data_rtp_tchf144  -- this is expected, we do not fully implement TCH/F14.4
pass BTS_Tests.TC_data_rtp_tchf96
pass BTS_Tests.TC_data_rtp_tchf48
pass->FAIL BTS_Tests.TC_data_rtp_tchh48  -- TCH/H4.8 was passing before, no idea why it's failing
pass BTS_Tests.TC_data_rtp_tchf24
pass->FAIL BTS_Tests.TC_data_rtp_tchh24  -- TCH/H2.4 was passing before, no idea why it's failing

The TCH/F14.4, TCH/H4.8, and TCH/H2.4 are outside the scope of this ticket, so marking as Resolved.

Actions #53

Updated by fixeria 6 months ago

  • Related to Bug #6166: ttcn3-bts-test: TC_data_rtp_tchh48 and TC_data_rtp_tchh24 are failing added
Actions #54

Updated by fixeria 6 months ago

  • Related to Feature #6167: csd_v110: implement rate adaptation for TCH/F14.4 added
Actions #55

Updated by fixeria 6 months ago

  • Related to Bug #6168: osmo-bts-trx: proper measurement aggregation for CSD added
Actions #56

Updated by fixeria 4 months ago

For the record, I found a problem while working on #4396 and submitted several patches fixing it:

https://gerrit.osmocom.org/c/osmo-bts/+/34990 osmo-bts-trx: tx_tch[fh]_fn(): use BUFPOS macro everywhere [NEW]
https://gerrit.osmocom.org/c/osmo-bts/+/34991 osmo-bts-trx: tx_tch[fh]_fn(): rework generation of dummy FACCH [NEW]
https://gerrit.osmocom.org/c/osmo-bts/+/34992 osmo-bts-trx: tx_tch[fh]_fn(): fix sending idle CSD frames [NEW]
https://gerrit.osmocom.org/c/osmocom-bb/+/34993 trxcon/l1sched: tx_tch[fh]_fn(): fix sending idle CSD frames [NEW]

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)