Project

General

Profile

Feature #3419

TCH/H logical channel is not implemented

Added by fixeria 27 days ago. Updated 7 days ago.

Status:
Stalled
Priority:
Normal
Assignee:
Category:
trxcon
Target version:
-
Start date:
07/26/2018
Due date:
% Done:

90%

Estimated time:
Resolution:
Spec Reference:

Related issues

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

History

#1 Updated by fixeria 27 days ago

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

#2 Updated by laforge 11 days 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 11 days 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 10 days 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 10 days 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 10 days 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 9 days 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 7 days 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...

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)