Project

General

Profile

Actions

Bug #5172

closed

Uplink is broken: wrong TSC is sent in RSL CHANnel ACTIVation

Added by fixeria 6 months ago. Updated 6 months ago.

Status:
Resolved
Priority:
Urgent
Assignee:
Category:
-
Target version:
-
Start date:
06/04/2021
Due date:
% Done:

100%

Spec Reference:

Description

With the recent master (https://git.osmocom.org/osmo-bsc/commit/?id=3512e3cf1b7fd16dbb476d5abf2eb9c13dcc876e) none of my phones can perform Location Updating. Access Burst still triggers SDCCH activation, but after that I see no RSL DATA.ind at all. The Uplink measurements (performed by BTS) indicate that the MS does transmit on allocated resource.

DRSL INFO abis_rsl.c:1547 (bts=0) CHAN RQD: reason: Location updating (ra=0x05, neci=0x01, chreq_reason=0x03)
DRLL DEBUG lchan_select.c:91 looking for lchan SDCCH8: (bts=0,trx=0,ts=1,pchan=SDCCH8,state=UNUSED) ss=0 is available
DRLL DEBUG lchan_select.c:269 (bts=0) lchan_select_by_type(SDCCH)
DRSL DEBUG abis_rsl.c:517 (bts=0,trx=0,ts=1,pchan=SDCCH8,state=IN_USE) Tx RSL Channel Activate with act_type=INITIAL
DRSL DEBUG abis_rsl.c:1169 (bts=0,trx=0,ts=1,ss=0): meas_rep_count++=1 meas_rep_last_seen_nr=0
DRSL DEBUG abis_rsl.c:1169 (bts=0,trx=0,ts=1,ss=0): meas_rep_count++=2 meas_rep_last_seen_nr=1
DRSL DEBUG abis_rsl.c:1169 (bts=0,trx=0,ts=1,ss=0): meas_rep_count++=3 meas_rep_last_seen_nr=2
DRSL DEBUG abis_rsl.c:1169 (bts=0,trx=0,ts=1,ss=0): meas_rep_count++=4 meas_rep_last_seen_nr=3
DRSL DEBUG abis_rsl.c:1169 (bts=0,trx=0,ts=1,ss=0): meas_rep_count++=5 meas_rep_last_seen_nr=4
DRLL DEBUG chan_alloc.c:231 (bts=0) channel load average is 3.03%
DRLL DEBUG chan_alloc.c:245 (bts=0) T3122 wait indicator set to 10 seconds
DRSL DEBUG abis_rsl.c:1169 (bts=0,trx=0,ts=1,ss=0): meas_rep_count++=6 meas_rep_last_seen_nr=5
DCHAN ERROR lchan_fsm.c:1649 lchan(0-0-1-SDCCH8-0)[0x55c95c66b480]{WAIT_RLL_RTP_ESTABLISH}: (type=SDCCH) lchan allocation failed in state WAIT_RLL_RTP_ESTABLISH: Timeout

Related issues

Blocks OsmoBSC - Feature #1866: Make use of RSL RF RESOURCE INDICATION (interference measurements)Resolvedneels12/02/2016

Actions
Actions #1

Updated by fixeria 6 months ago

  • Blocks Feature #1866: Make use of RSL RF RESOURCE INDICATION (interference measurements) added
Actions #2

Updated by fixeria 6 months ago

  • Status changed from New to In Progress

Looks like a recent regression, I am trying to bisect it now...

Actions #3

Updated by fixeria 6 months ago

  • Subject changed from Uplink is broken in nanoBTS to Uplink is broken: wrong TSC is sent in RSL CHANnel ACTIVation
  • Category deleted (ip.access BTS)
  • Priority changed from High to Urgent
  • % Done changed from 0 to 60

git bisect tells me that this commit is the culprit:

c33eb8d56943b8981523754b081967e6ff5f245d is the first bad commit     
commit c33eb8d56943b8981523754b081967e6ff5f245d                            
Author: Neels Hofmeyr <neels@hofmeyr.de>                                            
Date:   Sat May 22 16:29:35 2021 +0200

    allow explixit TSC Set and TSC on chan activ / modif / assignment

I think I know what happens:

  1. By default, we use BSIC=63 and thus TSC=7 for all BTS in osmo-bsc;
  2. 8-bit Access Bursts use their own special Training Sequence, so they're detected as usual;
  3. BSC tells the nanoBTS to expect TSC=0 (in RSL CHANnel ACTIVation);
  4. BSC indicates TSC=0 (in RR Immediate Assignment) to the MS.

What's wrong?

  • osmo-bsc (for some reason) uses TSC=0 instead of default TSC=7;
  • nanoBTS does not seem to support using TSC != BSIC-TSC (7 in our case).

This is a serious regression that most likely also affects other BTS models/variants, not only nanoBTS.

Actions #4

Updated by fixeria 6 months ago

  • Assignee changed from fixeria to neels

Neels, I guess you know better how to fix this. Assigning to you.

Actions #5

Updated by fixeria 6 months ago

Updated by fixeria 6 minutes ago:

I think I know what happens:

[...]

  1. BSC tells the nanoBTS to expect TSC=0 (in RSL CHANnel ACTIVation);
  2. BSC indicates TSC=0 (in RR Immediate Assignment) to the MS.

Most likely, nanoBTS ignores the RSL Channel Identification IE and still expects TSC=7, while the MS is told to use TSC=0.

Actions #6

Updated by neels 6 months ago

  • % Done changed from 60 to 80

got a fix, and also added TSC to ttcn3-bsc-tests.
currently running the patches by all BSC tests...

Actions #7

Updated by laforge 6 months ago

as there are many BTS models that don't support per-lchan different TCS (e.g. sysmoBTS models)
we should have some kind of flag/feature/capability that is provided by the model-speciifc
code to the core BSC code about whether or not this is supported.

Any use of different TCS should then be prevented by the core BSC code on such BTS.

Actions #8

Updated by fixeria 6 months ago

laforge wrote:

as there are many BTS models that don't support per-lchan different TCS (e.g. sysmoBTS models)
we should have some kind of flag/feature/capability that is provided by the model-speciifc
code to the core BSC code about whether or not this is supported.

Any use of different TCS should then be prevented by the core BSC code on such BTS.

This is already implemented: the flag is called BTS_FEAT_MULTI_TSC and we do check it in the VTY.

Actions #9

Updated by neels 6 months ago

  • % Done changed from 80 to 90
Actions #10

Updated by fixeria 6 months ago

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

I tested with the recent versions, everything seems to work fine.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)