Project

General

Profile

Bug #3233

trxcon doesn't seem to support FACCH?

Added by laforge 20 days ago. Updated 14 days ago.

Status:
New
Priority:
High
Assignee:
Category:
trxcon
Target version:
-
Start date:
05/04/2018
Due date:
% Done:

0%

Resolution:
Spec Reference:

Description

While developing the RLL tests for BTS_Tests.ttcn, I am having trouble of sending uplink FACCH frames via trxcon.

However, I'm having problems finding any code that actually relates to it. So I'm a bit at a loos how FACCH transmission is supposed to work in trxcon?

It seems like if a TCH is activated, trxcon assumes that all bursts/blocks are voice, which is wrong.

Some general rules about FACCH handling:
  • the network side can at any time schedule a FACCH instead of voice bursts
  • the MS can at any time send a FACCH (via L1CTL_DATA_REQ), which will always pre-empt (and drop!) a voice (L1CTL_TRAFFIC_REQ) at the same time. It's exactly the same in osmo-bts in the downlink. FACCH always has higher priority than voice, an a voice frame needs to be dropped whenever FACCH is transmitted.

Also, as long as the channel mode is SIGNALLING, no voice frames are ever transmitted, but basically all bursts are part of FACCH. Only once the GSM48_CMODE_SIGN is switched to GSM48_CMODE_SPEECH_*, we are permitted to send codec frames in uplink.

20180504-TC_rll_est_ind-FACCH.pcapng - pcap file (GSMTAP + RSL) of non-working FACCH case (22.6 KB) laforge, 05/04/2018 02:28 PM

20180504-TC_rll_est_ind-SDCCH.pcapng - pcap file (GSMTAP + RSL) of working SDCCH case (27.5 KB) laforge, 05/04/2018 02:28 PM

TC_rll_est_ind-FACCH.log Magnifier - titan log file of non-working FACCH case (5.76 MB) laforge, 05/04/2018 02:28 PM

TC_rll_est_ind-SDCCH.log Magnifier - titan log file of working SDCCH case (1.7 MB) laforge, 05/04/2018 02:29 PM

facch_delay.pcapng.gz (21.8 KB) fixeria, 05/06/2018 07:48 PM

disable_clock_reset.patch Magnifier (444 Bytes) fixeria, 05/06/2018 07:49 PM


Related issues

Related to OsmoBTS - Bug #3256: BTS_Tests.ttcn: Encryption + RLL tests not executed on Bm + Lm channels (TCH/F + TCH/H) New 05/10/2018

History

#1 Updated by fixeria 20 days ago

Hi Harald,

It seems like if a TCH is activated, trxcon assumes that
all bursts/blocks are voice, which is wrong.

No.

Some general rules about FACCH handling:
...

Yep, this is how FACCH is implemented in trxcon.

Please have a look:

https://git.osmocom.org/osmocom-bb/tree/src/host/trxcon/sched_trx.c#n89
https://git.osmocom.org/osmocom-bb/tree/src/host/trxcon/sched_prim.c#n188
https://git.osmocom.org/osmocom-bb/tree/src/host/trxcon/sched_prim.c#n131
https://git.osmocom.org/osmocom-bb/tree/src/host/trxcon/sched_trx.h#n292

So I'm a bit at a loos how FACCH transmission
is supposed to work in trxcon?

In short, you need to send an L1CTL message of type L1CTL_DATA_REQ
with desired 'chan_nr' and 'link_id'. Then the scheduler will itself
distinguish between voice frames and data, and prioritize FACCH.

When I have been implementing this, I followed the OsmoBTS approach.
But still I observe some strange behaviour, when FACH frames are
retransmitted a few times :/

#2 Updated by laforge 20 days ago

The problem can be reproduced by running BTS_Tests.TC_rll_est_ind from laforge/bts-rll branch of osmo-ttcn3-hacks.git.

The tests currently have testing TCH/F disabled (due to the bug described here). You'll need the following patch to re-enable it:

-               //valueof(ts_RslChanNr_Bm(1)),
+               valueof(ts_RslChanNr_Bm(1)) //,

#3 Updated by laforge 20 days ago

I'm attaching pcap + log files. In the SDCCH case the BTS receives the SABM frames as expected. On FACCH, there are no SABM received by BTS.

#4 Updated by fixeria 20 days ago

Do the attached logs contain the output of BTS_Tests.TC_rll_est_ind only?
Or all testcases together? Too much lines, hard to understand what's happening...

If possible, could you please attach the logs of trxcon with the following
debug mask: DAPP:DL1C:DL1D:DTRX:DSCH:DSCHD? Thanks!

#5 Updated by fixeria 18 days ago

Do the attached logs contain the output of BTS_Tests.TC_rll_est_ind only?

Ok, I've found the answer myself while reading the TTCN code.
The logs only related to BTS_Tests.TC_rll_est_ind. The testcase
fails due to `T := 3.0` timer is being expired...

I think the root problem is hidden somewhere in the channel
coding implementation (i.e. in libosmocoding). Please see
the attached trace, that was made using a regular phone.
LAPDm frames were captured exactly on the BTS side.

Please note that call establishment on TCH/FACCH takes much
more time (i.e. frames) that establishment on SDCCH. Both
OsmoBTS and OsmocomBB/trxcon are relying on libosmocoding.

A temporary solution to make the test pass would be to
increase the timer. And also, I am going to refactor the
reset (L1CTL_RESET_REQ) policy. Please also try to
apply the attached patch.

#6 Updated by laforge 14 days ago

FYI: Due to the problems with FACCH with the BTS_Tests/trxcon/fake_trx/osmo-bts-trx chain, I've disabled Bm and Lm channels in those tests that use g_AllChanTypes (RLL tests and encrption tests). If Bm and Lm are added to this list of channel types, then all related tests start to fail. Executing them only on SDCCH/4 and SDCCH/8 passes fine. See #3256

#7 Updated by laforge 14 days ago

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

#8 Updated by laforge 14 days ago

fixeria wrote:

A temporary solution to make the test pass would be to
increase the timer.

I will try, but I so far haven't seen the tests pass even once.

And also, I am going to refactor the
reset (L1CTL_RESET_REQ) policy. Please also try to
apply the attached patch.

unfortunately the patch doesn't change the test result / behavior, sorry.

#9 Updated by laforge 14 days ago

  • Priority changed from Normal to High

I have some higher priority issues at the moment, but I think it's rather important that we figoure out the cause of this.

Also available in: Atom PDF