Project

General

Profile

Actions

Bug #3233

closed

Extremely slow FACCH processing

Added by laforge almost 6 years ago. Updated over 5 years ago.

Status:
Resolved
Priority:
High
Assignee:
-
Category:
osmo-bts-trx
Target version:
Start date:
05/04/2018
Due date:
% Done:

100%

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.


Files

20180504-TC_rll_est_ind-FACCH.pcapng 20180504-TC_rll_est_ind-FACCH.pcapng 22.6 KB pcap file (GSMTAP + RSL) of non-working FACCH case laforge, 05/04/2018 02:28 PM
20180504-TC_rll_est_ind-SDCCH.pcapng 20180504-TC_rll_est_ind-SDCCH.pcapng 27.5 KB pcap file (GSMTAP + RSL) of working SDCCH case laforge, 05/04/2018 02:28 PM
TC_rll_est_ind-FACCH.log TC_rll_est_ind-FACCH.log 5.76 MB titan log file of non-working FACCH case laforge, 05/04/2018 02:28 PM
TC_rll_est_ind-SDCCH.log TC_rll_est_ind-SDCCH.log 1.7 MB titan log file of working SDCCH case laforge, 05/04/2018 02:29 PM
facch_delay.pcapng.gz facch_delay.pcapng.gz 21.8 KB fixeria, 05/06/2018 07:48 PM
disable_clock_reset.patch disable_clock_reset.patch 444 Bytes fixeria, 05/06/2018 07:49 PM
facch_looong.pcapng.gz facch_looong.pcapng.gz 1.46 KB fixeria, 06/25/2018 02:46 PM
Actions #1

Updated by fixeria almost 6 years 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 :/

Actions #2

Updated by laforge almost 6 years 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)) //,

Actions #3

Updated by laforge almost 6 years 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.

Actions #4

Updated by fixeria almost 6 years 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!

Actions #5

Updated by fixeria almost 6 years 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.

Actions #6

Updated by laforge almost 6 years 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

Actions #7

Updated by laforge almost 6 years ago

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

Updated by laforge almost 6 years 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.

Actions #9

Updated by laforge almost 6 years 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.

Actions #10

Updated by laforge almost 6 years ago

fixeria any news about this one? It significantly decreases our test coverage, so it would be great to make some progress here...

Actions #11

Updated by fixeria almost 6 years ago

any news about this one? It significantly decreases our test coverage,
so it would be great to make some progress here...

Not yet, Harald. I will try to do something today.
Lots of trxcon related tasks are paused now, because of OS#1597.

Actions #12

Updated by fixeria almost 6 years ago

  • File facch_looong.pcapng.gz facch_looong.pcapng.gz added
  • Project changed from OsmocomBB to OsmoBTS
  • Subject changed from trxcon doesn't seem to support FACCH? to Extremely slow FACCH processing
  • Category changed from trxcon to osmo-bts-trx
  • Status changed from New to In Progress

Hmm, looks like this is not a problem of OsmocomBB/trxcon. This is a problem of OsmoBTS.
I just managed to reproduce the problem with RF-based setup: with OsmoTRX and a regular phone.

Please see the trace attached.

I am moving this issue to OsmoBTS, and will continue further debugging...

Actions #13

Updated by laforge almost 6 years ago

20:59 < fixeria> LaF0rge: it's still unclean to me: are LAPDm fill frames (0x03?, 0x01, 0x01, 0x2b...)
                 generated in OsmoBTS or in OsmoBSC, when there is nothing to transmit...
21:02 < fixeria> I think it's somehow related to this slow FACCH processing...

The "030101" is a LAPDm fill UI frame with zero length payload. It's padded with 2b... at th end.

LAPDm Fill frames are sent whenever there's nothing else to send on almost all channels, except
  • downlink PCH (there's a "paging no identity") instead
  • downlink SACCH (I think one always substitues a SI5/SI6 instead of an idle frame here)
  • downlink BCCH (you simply repeat any of the system information)
In terms of the use on FACCH, I think the following rules apply if you don't have anything to transmit:
  • if the channel is in "traffic/voice" mode, send codec frames
  • if the channel is in "signaling" mode, send a LAPDm fill frame

I think those rules apply in both UL and DL direction as long as DTXu/DTXd is not enabled. Once DTX is enabled for the respective direction, no fill frames are transmitted, but only SACCH frames are sent.

Actions #14

Updated by fixeria over 5 years ago

laforge wrote:

The "030101" is a LAPDm fill UI frame with zero length payload. It's padded with 2b... at th end.

In terms of the use on FACCH, I think the following rules apply if you don't have anything to transmit:
  • if the channel is in "traffic/voice" mode, send codec frames
  • if the channel is in "signaling" mode, send a LAPDm fill frame

The trxcon's scheduler implementation follows these rules. For each active logical
channel (e.g. SDCCH, FACCH, etc.) there is a dedicated TX queue. The L2&3 applications
are sending payload frames only (i.e. they don't care about LAPDm fill frames), so if
there is nothing in a particular TX queue, the trxcon's scheduler generates:

  • a LAPDm fill frame on SDCCH and FACCH (during signalling mode),
  • a Measurement Report on SACCH (WIP https://gerrit.osmocom.org/7470/),
  • a BFI (Bad Frame Indication) on TCH.

In case of OsmoBTS, it looks like the LAPDm fill frames are being generated
by OsmoBSC/OsmoNiTB and not by OsmoBTS itself...

Actions #15

Updated by fixeria over 5 years ago

  • Status changed from In Progress to Stalled
  • Assignee deleted (fixeria)
  • Target version set to osmo-bts-trx refresh

I am not sure I can do any progress in short term here. So, I release this task for now.
It would be great to get some feedback, in particular:

  • can anyone else reproduce this bug with a normal phone?
  • is osmo-bts-trx the only BTS variant affected by this problem?

And additionally, we should make sure that OsmocomBB/trxcon does work correctly.
There is still no Dockerfile for SDR PHY, but we are working on it...

Actions #16

Updated by fixeria over 5 years ago

It seems, the initial problem of 'FACCH is not working' (BTS_Tests.TC_rll_est_ind) is related to OS#3418:

<0006> sched_lchan_xcch.c:147 Primitive has odd length 7 (expected 23), so dropping...
Actions #17

Updated by fixeria over 5 years ago

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

Updated by fixeria over 5 years ago

  • Status changed from Stalled to In Progress

I would be happy if someone could confirm that OsmocomBB/trxcon does handle FACCH properly with some
non SDR-based BTS implementation (e.g. nanoBTS or sysmoBTS).

There is a Docker build script for GR-GSM TRX now:

https://git.osmocom.org/docker-playground/commit/?id=b642b8688d510f8de4c21f58a9dd3c9d68c387a5

All you need to do is to get an USRP (B2X0 should work), and follow the guide:

https://osmocom.org/projects/baseband/wiki/SDR_PHY#Docker-images

I would appreciate LAPDm/A-bis traces of a TCH/F call.

Please note that the container requires privileged access to the host's USB devices (not merged yet):

https://gerrit.osmocom.org/10412/

I am open for any questions, and can help with setting up the HW/SW.

Actions #19

Updated by fixeria over 5 years ago

  • Status changed from In Progress to Feedback
Actions #20

Updated by laforge over 5 years ago

  • Status changed from Feedback to Resolved
  • % Done changed from 0 to 100

The Bm channels have been enabled in the test suite in Change-Id I7c0f9f9f695e089e4a30f63ec362d1e6c18abff0 related to #3256 on July 27.

The Lm channels have been enabled in the test suite in Change-Id I78f82a5f2a7b21d91692b1c99a9ff125e65cab64 related to #3256 on September 16.

I've seen Vadim's request at the end of this ticket, but this kind of request is better suited for the mailing list, and not something that should be in this bug report, which I believe has been fully resolved already. Please reopen if I'm wrong.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)