Project

General

Profile

Bug #3211

gscon breaks dynamic timeslots: TCH/F_TCH/H_PDCH cannot switch from PDCH to TCH

Added by neels about 1 year ago. Updated about 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
04/24/2018
Due date:
% Done:

100%

Spec Reference:

Description

The gscon FSM in osmo-bsc cannot handle the Osmocom style dyn ts switchover:
it wants to set the lchan state to Activation Requested and expects an activation ack,
while the dyn ts still wants to go through Release Requested for PDCH -> Release Ack and then request Activation.

20180424232915446 DRSL DEBUG abis_rsl.c:2638 (bts=0,trx=0,ts=2,pchan=TCH/F_TCH/H_PDCH as PDCH) starting switchover to TCH/H
20180424232915446 DRSL DEBUG abis_rsl.c:2679 (bts=0,trx=0,ts=2,ss=0) state ACTIVE -> RELEASE REQUESTED
20180424232915446 DRSL DEBUG abis_rsl.c:873 (bts=0,trx=0,ts=2,ss=0) RF Channel Release
20180424232915446 DRSL DEBUG bsc_api.c:160 (bts=0,trx=0,ts=2,ss=0) state RELEASE REQUESTED -> ACTIVATION REQUESTED
20180424232915447 DMSC NOTICE bsc_subscr_conn_fsm.c:540 SUBSCR_CONN[0x612000001d20]{WAIT_CRCX_BTS}: state_chg to WAIT_ASS_CMPL
20180424232915505 DRSL DEBUG abis_rsl.c:943 (bts=0,trx=0,ts=2,ss=0) RF CHANNEL RELEASE ACK
20180424232915505 DRSL NOTICE abis_rsl.c:972 (bts=0,trx=0,ts=2,ss=0) CHAN REL ACK but state ACTIVATION REQUESTED
20180424232915506 DRSL DEBUG abis_rsl.c:86 (bts=0,trx=0,ts=2,ss=0) state ACTIVATION REQUESTED -> NONE
20180424232915506 DMSC INFO osmo_bsc_api.c:447 Tx MSC ASSIGN FAIL
20180424232915506 DMSC NOTICE osmo_bsc_api.c:448 SUBSCR_CONN[0x612000001d20]{WAIT_ASS_CMPL}: Received Event RR_ASSIGN_FAIL
20180424232915506 DMSC INFO osmo_bsc_sigtran.c:325 Tx MSC ASSIGNMENT FAIL

Related issues

Related to OsmoBSC - Bug #2283: Inter-BSC hand-over is missing (BSC side)Resolved05/22/2017

Related to OsmoGSMTester - Feature #2581: osmo-gsm-tester: add test case: test dynamic timeslotsResolved10/18/2017

History

#1 Updated by neels about 1 year ago

This turns out to be a nontrivial refactoring: the gscon FSM must be aware of the switchover status, it must not interfere until a dyn TS is switched over.
In the old days, we would call rsl_chan_activate_lchan() "and forget"; in there we would simply exit early and from the switchover callback re-enter rsl_chan_activate_lchan().
Now that everything is embedded in a larger FSM, we can't just exit early, the calling FSM would assume the activation is already requested.

This is also related to inter-BSC HO: I want to follow pretty much the Assignment Command code path's lchan allocation.
  • for Assignment we want to allocate an lchan taking the place of the lchan already in use,
  • for MT HO we want to allocate an lchan where there is no previous lchan,
  • and for both of them we may need to wait for dyn TS to switch off PDCH (and make sure to re-enable PDCH after lchan release).
    The point being that I need a sort of lego blocks modularity, but the current code is very rigid.

At first I started adding a dyn TS switchover state to the gscon, but that state already looks like a separate FSM, and the further I get the more it strikes me:
Actually it makes most sense to have a timeslot FSM to handle dynamic timeslot switchover.

The logical continuation of that thought is to have individual lchan FSMs for activation and deactivation with timeouts as well as recovery from BROKEN_UNUSABLE state, and so on,
and to trigger the gscon FSM to carry on by events once the lchan is ready.

The question is, would refactoring all timeslot & lchan handling into FSMs turn out to be more work than teaching the gscon to wait for dyn ts switchover?
Currently, my impression is that anything else would be clumsy workarounds, and with HO and dyn TS I anyway need to thoroughly rock the lchan boat.
It seems like a chance to pull the old osmo_timer way of handling RSL Chan foo into proper FSMs, to match the rest.

Next, I'll read around the code and see what I'd be getting myself into with this course of action, maybe a dyn TS FSM is enough for now.

#2 Updated by neels about 1 year ago

  • Related to Bug #2283: Inter-BSC hand-over is missing (BSC side) added

#3 Updated by neels about 1 year ago

  • Related to Feature #2581: osmo-gsm-tester: add test case: test dynamic timeslots added

#4 Updated by neels about 1 year ago

  • % Done changed from 0 to 80

I now succeeded to place a call on a dynamic timeslot, after fixing it the easy way.
Part of the current failure is in the new gscon FSM:

  • When switching an Osmocom style dyn TS away from PDCH, we send an lchan release and expect an ack.
  • However, the gscon misinterprets that release ack as a failure to establish the new lchan for Assignment.

The proper way to fix it would be to have explicit states to handle the PDCH release, and only then continue with lchan alloc.
The easy way that saves a lot of code refactoring is to teach the gscon FSM and bsc_api.c to not fail assignment just because of that lchan release and ack.
I have patches for this, following in another comment any "minute" now.

(With the inter-BSC HO MT part, we might still get a more accurate reflection as FSM states,
but it is actually sufficient so far to rely on the old way of expecting ACK/NACK and using osmo_timer.)

Then there also is a failure actually in osmo-bts: #3235

#5 Updated by neels about 1 year ago

  • Status changed from New to In Progress
  • % Done changed from 80 to 90

#6 Updated by neels about 1 year ago

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

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)