Project

General

Profile

Feature #3419

TCH/H logical channel is not implemented

Added by fixeria 3 months ago. Updated about 1 month ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
trxcon
Start date:
07/26/2018
Due date:
% Done:

100%

Resolution:
Spec Reference:

Related issues

Blocks OsmoBTS - Bug #3256: BTS_Tests.ttcn: Encryption + RLL tests not executed on Lm channels (TCH/H)Resolved2018-05-10

History

#1 Updated by fixeria 3 months ago

  • Blocks Bug #3256: BTS_Tests.ttcn: Encryption + RLL tests not executed on Lm channels (TCH/H) added

#2 Updated by laforge 2 months ago

  • Status changed from New to In Progress
  • Assignee changed from fixeria to laforge
  • % Done changed from 0 to 10

I've more or less tried a 1:1 port from osmo-bts-trx but currently it's not working yet.

All received blocks cannot be decoded correctly yet:

<0006> sched_lchan_tchh.c:156 Received bad TCH frame ending at fn=692685 for TCH/H(0)
<0006> sched_lchan_tchh.c:156 Received bad TCH frame ending at fn=692689 for TCH/H(0)
<0006> sched_lchan_tchh.c:156 Received bad TCH frame ending at fn=692694 for TCH/H(0)
<0006> sched_lchan_tchh.c:156 Received bad TCH frame ending at fn=692698 for TCH/H(0)
<0006> sched_lchan_tchh.c:156 Received bad TCH frame ending at fn=692702 for TCH/H(0)
<0006> sched_lchan_tchh.c:156 Received bad TCH frame ending at fn=692707 for TCH/H(0)
<0006> sched_lchan_tchh.c:156 Received bad TCH frame ending at fn=692711 for TCH/H(0)
<0006> sched_lchan_tchh.c:156 Received bad TCH frame ending at fn=692715 for TCH/H(0)
<0006> sched_lchan_tchh.c:156 Received bad TCH frame ending at fn=692720 for TCH/H(0)
<0006> sched_lchan_tchh.c:156 Received bad TCH frame ending at fn=692724 for TCH/H(0)
<0006> sched_lchan_tchh.c:156 Received bad TCH frame ending at fn=692728 for TCH/H(0)

#3 Updated by laforge 2 months ago

  • Status changed from In Progress to Stalled
  • Assignee changed from laforge to fixeria

my code is in laforge/trxcon-tchh branch, and I'm currently a bit at a loss why it wouldn't work at all in either UL or DL.

#4 Updated by fixeria 2 months ago

  • Status changed from Stalled to In Progress
  • % Done changed from 10 to 30

It seems, the answer is in GSM 05.02, clause 7 table 1/9:

  • Unlike TCH/F, where a FACCH/F frame can be transmitted just by replacing any speech frame,
    transmission of a FACCH/H frame can only be initiated on particular frame numbers. We do know this.
  • The rules, which define frame numbers applicable for initiation of FACCH/H, are different for both DL and UL.
    This is why TCH/H implementation from OsmoBTS can not be used as-is in trxcon.

Mapping of logical channels onto physical channels:

  • FACCH/F:
both UL/DL:   B0(0...7), B1(4...11), B2(8...11,0...3)
  • FACCH/H:
FACCH/H0_UL:  B0(0,2,4,6,8,10)    B1(8,10,13,15,17,19)   B2(17,19,21,23,0,2)
FACCH/H0_DL:  B0(4,6,8,10,13,15)  B1(13,15,17,19,21,23)  B2(21,23,0,2,4,6)
FACCH/H1_UL:  B0(1,3,5,7,9,11)    B1(9,11,14,16,18,20)   B2(18,20,22,24,1,3)
FACCH/H1_DL:  B0(5,7,9,11,14,16)  B1(14,16,18,20,22,24)  B2(22,24,1,3,5,7)

I just hacked the code a bit (for sure, this is not the final solution):

diff --git a/src/host/trxcon/sched_lchan_tchh.c b/src/host/trxcon/sched_lchan_tchh.c
index 3823a5b3..45fc1633 100644
--- a/src/host/trxcon/sched_lchan_tchh.c
+++ b/src/host/trxcon/sched_lchan_tchh.c
@@ -60,7 +60,7 @@ int rx_tchh_fn(struct trx_instance *trx, struct trx_ts *ts,
         * TCH/FACCH frame, because our burst buffer carries 6 bursts.
         * Even FN ending at: 10,11,19,20,2,3
         */
-       int fn_is_odd = (((fn + 26 - 10) % 26) >> 2) & 1;
+       int fn_is_odd = !((((fn + 26 - 10) % 26) >> 2) & 1);

        /* Set up pointers */
        lchan_desc = &trx_lchan_desc[lchan->type];

so now there are no Downlink decoding errors anymore, and I see LAPDm fill frames being decoded.

#5 Updated by laforge 2 months ago

Hi Vadim,

thanks a lot for digging deeper and for finding another piece of the puzzle!

On Sat, Aug 11, 2018 at 10:38:17PM +0000, fixeria [REDMINE] wrote:

so now there are no Downlink decoding errors anymore, and I see LAPDm fill frames being decoded.

With the change of inverting fn_is_odd, I still get

<0006> sched_lchan_tchh.c:160 Received bad TCH frame ending at fn=3317 for TCH/H(0): -1
<0006> sched_lchan_tchh.c:160 Received bad TCH frame ending at fn=3321 for TCH/H(0): -1
<0006> sched_lchan_tchh.c:160 Received bad TCH frame ending at fn=3325 for TCH/H(0): -1
<0006> sched_lchan_tchh.c:160 Received bad TCH frame ending at fn=3330 for TCH/H(0): -1
<0006> sched_lchan_tchh.c:160 Received bad TCH frame ending at fn=3334 for TCH/H(0): -1
<0006> sched_lchan_tchh.c:160 Received bad TCH frame ending at fn=3338 for TCH/H(0): -1
<0006> sched_lchan_tchh.c:160 Received bad TCH frame ending at fn=3343 for TCH/H(0): -1
<0006> sched_lchan_tchh.c:160 Received bad TCH frame ending at fn=3347 for TCH/H(0): -1
<0006> sched_lchan_tchh.c:160 Received bad TCH frame ending at fn=3351 for TCH/H(0): -1
<0006> sched_lchan_tchh.c:160 Received bad TCH frame ending at fn=3356 for TCH/H(0): -1
<0006> sched_lchan_tchh.c:160 Received bad TCH frame ending at fn=3360 for TCH/H(0): -1
<0006> sched_lchan_tchh.c:160 Received bad TCH frame ending at fn=3364 for TCH/H(0): -1
<0006> sched_lchan_xcch.c:106 Received bad data frame at fn=3288 (64/104) for SACCH/TH

#6 Updated by fixeria 2 months ago

Hi Harald,

With the change of inverting fn_is_odd, I still get

Yep, it was just a quick hack. It should facilitate decoding of some
Downlink frames, but not solve the problem at all.

I have been reading (and still reading) both GSM 05.02 and 05.03, and found some more important details:

  • 228 coded bits of a TCH/H speech frame are mapped on 4 consecutive bursts,
    using the even numbered bits of the first 2 bursts and the odd numbered bits
    of the last two bursts (see 3.2.3). So, every single burst carries 57 bits
    of one coded speech frame, and 57 bits of another speech frame. This is
    also called "diagonal interleaving".
  • 456 coded bits of a FACCH/H frame are mapped on 6 consecutive bursts,
    by stealing even bits of the first 2 bursts (hu=1), all bits of the middle 2 bursts
    (both hu=1 and hl=1), and odd bits of the last 2 bursts (hl=1) (see 4.3.5).
  • Two full consecutive speech frames are stolen by a FACCH/H frame (see 4.3.5).

Now I need to understand how this is implemented in libosmocoding...

#7 Updated by fixeria 2 months ago

  • % Done changed from 30 to 80

Good news!

I've managed to make TCH/H Uplink transmission work. A call was successfully established, so
at least signalling works now. Still need to clean up some parts of the Downlink implementation.

The world of the Half Rate is full of difficulties ;)
I will upload rebased changes to Gerrit soon...

#8 Updated by fixeria 2 months ago

  • Status changed from In Progress to Stalled
  • % Done changed from 80 to 90

I have uploaded a change set: https://gerrit.osmocom.org/10460/

I didn't tested the speech yet, but the signalling should work. The downlink part
of TCH/H implementation needs some additional modifications, in particular:

  • the measurements should be calculated for all bursts carrying a frame,
    i.e. 4 bursts for a speech frame, and 6 bursts for a FACCH/H frame;
  • the TDMA frame number calculation also should be done properly.

So, let's keep the tip of this patch set WIP for now...

#9 Updated by fixeria about 2 months ago

  • Status changed from Stalled to In Progress

Good news: speech on both DL and UL directions is working like a charm.
I am working on DL measurements and TDMA frame calculation now...

#10 Updated by fixeria about 2 months ago

  • Target version set to Improvement of the higher layers of OsmocomBB

#11 Updated by fixeria about 1 month ago

An updated patch set has been sent for review:

New Changes:
https://gerrit.osmocom.org/10941 trxcon/scheduler: fix: don't send BFI in GSM48_CMODE_SIGN mode
https://gerrit.osmocom.org/10942 trxcon/scheduler: introduce TDMA frame math helpers

Updated Changes:
https://gerrit.osmocom.org/10459 trxcon/scheduler: introduce TCH/H TDMA frame mapping helpres [WIP]
https://gerrit.osmocom.org/10460 trxcon/scheduler: add TCH/H channel support [WIP]

The problem with calculating the correct first frame number is solved,
while the measurements are still incorrect (can be fixed later).

#12 Updated by fixeria about 1 month ago

There are also some decoding errors when changing the TCH mode:

<0005> sched_trx.c:263 (Re)configure TDMA timeslot #2 as TCH/H+SACCH
<0005> sched_trx.c:420 Activating lchan=TCH/H(0) on ts=2
<0005> sched_trx.c:420 Activating lchan=SACCH/TH(0) on ts=2
<0006> sched_lchan_xcch.c:96 Received incomplete data frame at fn=0 (0/104) for SACCH/TH(0)
<0006> sched_lchan_xcch.c:106 Received bad data frame at fn=0 (0/104) for SACCH/TH(0)
<0005> sched_clck.c:138 Clock indication: fn=22389
<0005> sched_clck.c:138 Clock indication: fn=22440
<0001> l1ctl.c:695 Received L1CTL_TCH_MODE_REQ (tch_mode=1, audio_mode=10)
<0005> sched_clck.c:138 Clock indication: fn=22491
<0006> sched_lchan_tchh.c:305 Received bad TCH frame ending at fn=22513 on TCH/H(0) (rc=-1)
<0006> sched_lchan_tchh.c:305 Received bad TCH frame ending at fn=22518 on TCH/H(0) (rc=-1)
<0006> sched_lchan_tchh.c:305 Received bad TCH frame ending at fn=22522 on TCH/H(0) (rc=-1)
<0006> sched_lchan_tchh.c:305 Received bad TCH frame ending at fn=22526 on TCH/H(0) (rc=-1)
<0005> sched_clck.c:138 Clock indication: fn=22542
<0005> sched_clck.c:138 Clock indication: fn=22593
<0005> sched_clck.c:138 Clock indication: fn=22644
<0005> sched_clck.c:138 Clock indication: fn=22695
<0005> sched_clck.c:138 Clock indication: fn=22746
<0005> sched_clck.c:138 Clock indication: fn=22797

#13 Updated by fixeria about 1 month ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100

Changes have been merged. Both traffic and FACCH/H are working.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)