Bug #5172
closedUplink is broken: wrong TSC is sent in RSL CHANnel ACTIVation
100%
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
Updated by fixeria almost 3 years ago
- Blocks Feature #1866: Make use of RSL RF RESOURCE INDICATION (interference measurements) added
Updated by fixeria almost 3 years ago
- Status changed from New to In Progress
Looks like a recent regression, I am trying to bisect it now...
Updated by fixeria almost 3 years 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:
- By default, we use BSIC=63 and thus TSC=7 for all BTS in osmo-bsc;
- 8-bit Access Bursts use their own special Training Sequence, so they're detected as usual;
- BSC tells the nanoBTS to expect TSC=0 (in RSL CHANnel ACTIVation);
- 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.
Updated by fixeria almost 3 years ago
- Assignee changed from fixeria to neels
Neels, I guess you know better how to fix this. Assigning to you.
Updated by fixeria almost 3 years ago
Updated by fixeria 6 minutes ago:
I think I know what happens:
[...]
- BSC tells the nanoBTS to expect TSC=0 (in RSL CHANnel ACTIVation);
- 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.
Updated by neels almost 3 years 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...
Updated by laforge almost 3 years 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.
Updated by fixeria almost 3 years 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.
Updated by neels almost 3 years ago
- % Done changed from 80 to 90
this patch fixes the issue:
https://gerrit.osmocom.org/c/osmo-bsc/+/24565
this patch tests it:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/24564
Updated by fixeria almost 3 years 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.
