Project

General

Profile

Actions

Bug #5518

closed

osmo-bts-trx: Downlink FACCH/H scheduling is not working properly

Added by fixeria almost 2 years ago. Updated almost 2 years ago.

Status:
Rejected
Priority:
Immediate
Assignee:
Category:
osmo-bts-trx
Target version:
-
Start date:
04/09/2022
Due date:
% Done:

0%

Spec Reference:

Description

It was reported by a customer that no voice can be heard during the emergency calls, while the normal MO/MT calls are working fine. The MS originating an emergency call indicates RxQual=7 in the RR Measurement Reports, whereas the Uplink measurements generated by the BTS indicate RxQual=0. This problem is specific to TCH/H, full rate channels are not affected.

The key difference from normal calls is that emergency calls are established via the early assignment: a traffic channel gets activated in signalling mode and after the call establishment it gets modified to one of the speech modes. Also, the same problem with no voice can be reproduced in a setup with no SDCCH channels - this would force the BSC to use early assignment even for the normal calls.

After several hours of experiments with USRP B210 and after reading the source code, I found out that scheduling of the Downlink FACCH on TCH/H is completely broken. Attached you can find a PCAP file containing A-bis/RSL traces and GSMTAP Um frames showing the problem. One can see LAPDm errors and retransmissions during the call establishment. I tried downgrading osmo-bts down to 1.2.0 (Jan 2020) without any luck.

A reasonable question is why didn't ttcn3-bts-test catch this? Because we use trxcon as the MS side scheduler, which was written by looking at osmo-bts-trx as the reference implementation. There can be similar bugs in there, so in this regard we're testing the implementation against itself. Most likely it needs to be fixed too.


Files


Related issues

Related to OsmocomBB - Bug #3653: FACCH/H sometimes not received by BTS with osmocomBB+motorolaCXX New10/15/2018

Actions
Actions #1

Updated by fixeria almost 2 years ago

  • Related to Bug #3653: FACCH/H sometimes not received by BTS with osmocomBB+motorolaCXX added
Actions #2

Updated by fixeria almost 2 years ago

  • Status changed from New to In Progress

Unlike TCH/F, TCH/H imposes some additional requirements on the FACCH transmission window, i.e. a signalling frame can only be transmitted at specific TDMA frame numbers defined in 3GPP TS 45.002, table 1a.

diff --git a/src/osmo-bts-trx/sched_lchan_tchh.c b/src/osmo-bts-trx/sched_lchan_tchh.c
index f0d8ff68..0c6c1828 100644
--- a/src/osmo-bts-trx/sched_lchan_tchh.c
+++ b/src/osmo-bts-trx/sched_lchan_tchh.c
@@ -351,6 +351,17 @@ extern void tx_tch_common(struct l1sched_ts *l1ts,
               const struct trx_dl_burst_req *br,
               struct msgb **_msg_tch, struct msgb **_msg_facch);

+/* FACCH/H channel mapping for Downlink (see 3GPP TS 45.002, table 1a).
+ * This mapping is valid for both FACCH/H(0) and FACCH/H(1). */
+static const uint8_t sched_tchh_dl_facch_map[26] = {
+    [4]  = 1, /* FACCH/H(0): B0(4,6,8,10,12,15) */
+    [5]  = 1, /* FACCH/H(1): B0(5,7,9,11,14,16) */
+    [12] = 1, /* FACCH/H(0): B1(12,15,17,19,21,23) */
+    [14] = 1, /* FACCH/H(1): B1(14,16,18,20,22,25) */
+    [21] = 1, /* FACCH/H(0): B2(21,23,0,2,4,6) */
+    [22] = 1, /* FACCH/H(1): B2(22,25,1,3,5,7) */
+};
+
 /* obtain a to-be-transmitted TCH/H (Half Traffic Channel) burst */
 int tx_tchh_fn(struct l1sched_ts *l1ts, struct trx_dl_burst_req *br)
 {
@@ -427,6 +438,14 @@ int tx_tchh_fn(struct l1sched_ts *l1ts, struct trx_dl_burst_req *br)
     else
         gsm0503_tch_hr_encode(*bursts_p, msg_tch->l2h, msgb_l2len(msg_tch));

+    if (chan_state->dl_ongoing_facch == 1) {
+        if (!sched_tchh_dl_facch_map[br->fn % 26]) {
+            LOGL1SB(DL1P, LOGL_FATAL, l1ts, br,
+                "FACCH/H(%d) shall not start at fn=%u (%u)\n",
+                br->chan == TRXC_TCHH_0 ? 0 : 1, br->fn, br->fn % 26);
+        }
+    }
+
     /* free message */
     if (msg_tch)
         msgb_free(msg_tch);

This patch confirms that FACCH/H is currently scheduled at wrong frame numbers:

DL1P FATAL sched_lchan_tchh.c:443 123877/93/13/49/21 (bts=0,trx=0,ts=1) TCH/H(0): FACCH/H(0) shall not start at fn=123877 (13)
DL1P FATAL sched_lchan_tchh.c:443 123903/93/13/24/47 (bts=0,trx=0,ts=1) TCH/H(0): FACCH/H(0) shall not start at fn=123903 (13)
DL1P FATAL sched_lchan_tchh.c:443 123929/93/13/50/25 (bts=0,trx=0,ts=1) TCH/H(0): FACCH/H(0) shall not start at fn=123929 (13)
Actions #3

Updated by fixeria almost 2 years ago

  • % Done changed from 0 to 10

fixeria wrote in #note-2:

DL1P FATAL sched_lchan_tchh.c:443 123877/93/13/49/21 (bts=0,trx=0,ts=1) TCH/H(0): FACCH/H(0) shall not start at fn=123877 (13)

I found out why FACCH/H is getting scheduled at incorrect offset. In rts_tchh_fn() we have this code:

/* the FN 4/5, 13/14, 21/22 defines that FACCH may be included. */
return rts_tch_common(l1ts, br, ((br->fn % 26) >> 2) & 1);

First of all, the comment is wrong about fn=13 - it should actually be 12 according to table 1a of 3GPP TS 45.002. But the real problem is that this magic TDMA frame number check evaluates to 1 if br->fn is 13, so that a FACCH block can be scheduled despite it's not permitted to start at this offset. We should replace this magic arithmetic with a lookup table.

Actions #4

Updated by fixeria almost 2 years ago

  • % Done changed from 10 to 0

fixeria wrote in #note-3:

First of all, the comment is wrong about fn=13 - it should actually be 12 according to table 1a of 3GPP TS 45.002. But the real problem is that this magic TDMA frame number check evaluates to 1 if br->fn is 13, so that a FACCH block can be scheduled despite it's not permitted to start at this offset. We should replace this magic arithmetic with a lookup table.

False alarm. I was looking at the table 1a, which applies to VAMOS II/III capable UEs using the TSC set 2. For the normal non-VAMOS mode of operation the rules defined in table 1 apply. The multiframe layout defined in table 1a is different in a way that SACCH is shifted by one frame forward compared to the normal layout. This is why I thought we should be using fn=12 instead of fn=13.

Actions #5

Updated by fixeria almost 2 years ago

  • Status changed from In Progress to Rejected
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)