Cellular Network Infrastructure » Radio Access Network » OsmoBTS

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)

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.

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.