Bug #5278
closedOSMO_DYN TS: in SDCCH8 mode assigns only two SDCCH
100%
Description
Writing a test to count exhaustion of SDCCH channels in the presence of dyn TS,
I noticed that OsmoBSC only assigns two SDCCH to an OSMO_DYN TS before converting the next dyn TS to SDCCH8.
Attached is a ttcn3 test that shows this.
It sets up three dyn TS,
successfully converts the first dyn TS to SDCCH8,
establishes two SDCCH on the dyn TS and expects to establish six more.
But instead, after the second SDCCH on the dyn TS, OsmoBSC issues a Channel Release for the second dyn TS.
That means it wants to convert the second dyn TS to SDCCH8, instead of assigning the third SDCCH of the first dyn TS.
It's also visible in the OsmoBSC logs:
20211023231055489 DRLL DEBUG looking for lchan TCH/F_TCH/H_SDCCH8_PDCH as SDCCH8: (bts=0,trx=0,ts=2,pchan_on_init=TCH/F_TCH/H_SDCCH8_PDCH,pchan=SDCCH8,state=IN_USE) ss=0 in type=SDCCH,state=ESTABLISHED not suitable (lchan_select.c:110) 20211023231055489 DRLL DEBUG looking for lchan TCH/F_TCH/H_SDCCH8_PDCH as SDCCH8: (bts=0,trx=0,ts=2,pchan_on_init=TCH/F_TCH/H_SDCCH8_PDCH,pchan=SDCCH8,state=IN_USE) ss=1 in type=SDCCH,state=ESTABLISHED not suitable (lchan_select.c:110) 20211023231055489 DRLL DEBUG looking for lchan TCH/F_TCH/H_SDCCH8_PDCH as SDCCH8: (bts=0,trx=0,ts=3,pchan_on_init=TCH/F_TCH/H_SDCCH8_PDCH,pchan=PDCH,state=PDCH) ss=0 interf=255=0dBm is available, after dyn PCHAN change (lchan_select.c:120) 20211023231055489 DCHAN INFO lchan(0-0-3-OSMO_DYN-0)[0x612000017da0]{UNUSED}: (type=SDCCH) Selected (lchan_select.c:320)
I suspect it is because subslots_per_pchan[] in gsm_data.c indicates 2.
When I set it to 8, my test works as expected.
[GSM_PCHAN_OSMO_DYN] = 8,
Todo: verify that nothing else breaks from this change.
Files
Updated by neels over 2 years ago
- Status changed from New to Feedback
- Assignee set to pespin
pespin, SDCCH8 on OSMO_DYN is your creation, right? Any input / would you resolve this issue?
Updated by pespin over 2 years ago
First of all, there's a test in place similar to the one you wrote, see TC_dyn_ts_sdcch8_act_deact, TC_dyn_ts_sdcch8_tch_call_act_deact. It seems however they are not testing to fill the entire set of SDCCH subslots there.
I gave the test a try. Some comments:
For some reason I see in the pcap that when lchans for SDCCH4 in TS0 are allocated, following subslots are allocated: 0,1,3. But I see no ChanAct for ss=2? Answering myself: SS=2 is CBCH.
BTW, wireshark seems to fail decoding some DTAP message in there: "..00 0001 = DTAP Group Call Control Message Type: Unknown (0x01)", both on top of RSL and on top of BSSMAP. Not sure if that's expected, maybe it's simply some garbage payload being sent by TTCN3.
Looking at generated pcap, I check the VTY output of the test (TCP conn):
OsmoBSC# configure terminal configure terminal OsmoBSC(config)# network network OsmoBSC(config-net)# bts 0 bts 0 OsmoBSC(config-net-bts)# trx 0 trx 0 OsmoBSC(config-net-bts-trx)# timeslot 2 timeslot 2 OsmoBSC(config-net-bts-trx-ts)# phys_chan_config TCH/F_TCH/H_PDCH phys_chan_config TCH/F_TCH/H_PDCH OsmoBSC(config-net-bts-trx-ts)# end end OsmoBSC# configure terminal configure terminal OsmoBSC(config)# network network OsmoBSC(config-net)# bts 0 bts 0 OsmoBSC(config-net-bts)# trx 0 trx 0 OsmoBSC(config-net-bts-trx)# timeslot 3 timeslot 3 OsmoBSC(config-net-bts-trx-ts)# phys_chan_config TCH/F_TCH/H_PDCH phys_chan_config TCH/F_TCH/H_PDCH OsmoBSC(config-net-bts-trx-ts)# end
but then, a few more instructions later, you run "show running-config":
OsmoBSC# show running-config show running-config [...] trx 0 rf_locked 0 arfcn 871 nominal power 23 max_power_red 20 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4+CBCH hopping enabled 0 timeslot 1 phys_chan_config TCH/F hopping enabled 0 timeslot 2 phys_chan_config TCH/F hopping enabled 0 timeslot 3 phys_chan_config TCH/F hopping enabled 0 timeslot 4 phys_chan_config TCH/F hopping enabled 0 timeslot 5 phys_chan_config TCH/H hopping enabled 0 timeslot 6 phys_chan_config PDCH hopping enabled 0 timeslot 7 phys_chan_config PDCH hopping enabled 0
So it looks like the config was not kept/maintained, at least when printed....
According to logs, it looks like the new dyn chan is applied. It seems indeed to be a problem with only up to 2 subslots being possible:
3902 09:57:44.990412 Oct 25, 2021 11:57:44.990412000 CEST 172.18.2.20 34618 172.18.2.203 4729 GSMTAP 276 timeslot(0-0-2-OSMO_DYN)[0x612000005620]{NOT_INITIALIZED}: (pchan_is=NONE) pchan_is=NONE max_primary_lchans=0 max_lchans_possible=2
Updated by pespin over 2 years ago
pespin wrote:
So it looks like the config was not kept/maintained, at least when printed....
According to logs, it looks like the new dyn chan is applied. It seems indeed to be a problem with only up to 2 subslots being possible:
[...]
Nevermind this, I just noticed it was due to BSC having several BSCs and wireshark not showing properly the content of the returned show running-config.
Updated by pespin over 2 years ago
- % Done changed from 0 to 90
Submitted a couple patches fixing related issues, and a ttcn3 test based on yours to make sure we track any possible future regression on this topic:
https://gerrit.osmocom.org/c/osmo-bsc/+/25939 Set subslots_per_pchan[GSM_PCHAN_OSMO_DYN] = 8
https://gerrit.osmocom.org/c/osmo-bsc/+/25940 Properly handle dyn TS TCH with vamos after updating subslots_per_pchan
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/25938 bsc: Introduce test TC_dyn_ts_sdcch8_all_subslots_used
Updated by pespin over 2 years ago
I submitted some more related patches:
https://gerrit.osmocom.org/c/osmo-bsc/+/25946 timeslot_fsm: Add assert to make sure we never go out of bounds in ts->lchan ...
https://gerrit.osmocom.org/c/osmo-bsc/+/25947 Set subslots_per_pchan_vamos[GSM_PCHAN_OSMO_DYN] = 0
Updated by neels over 2 years ago
On Mon, Oct 25, 2021 at 10:22:48AM +0000, pespin [REDMINE] wrote:
For some reason I see in the pcap that when lchans for SDCCH4 in TS0 are allocated, following subslots are allocated: 0,1,3. But I see no ChanAct for ss=2? Answering myself: SS=2 is CBCH.
Yes, that's the '00010203040506'O L3 payload sent for EST IND. It is argued
that the BSC should not care what the payload is, but IMHO it would be good to
use a sane payload instead, in all those places where we already use the dummy
payload: MSC pooling in OsmoBSC does parse it to determine the mobile identity
and choose an MSC. That code throws errors in the logs now.
Updated by pespin over 2 years ago
- Status changed from Feedback to Resolved
- % Done changed from 90 to 100
Fixes should be merged already, closing ticket.