Bug #3211
closedgscon breaks dynamic timeslots: TCH/F_TCH/H_PDCH cannot switch from PDCH to TCH
100%
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
Updated by neels almost 6 years 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.
- 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.
Updated by neels almost 6 years ago
- Related to Bug #2283: Inter-BSC hand-over is missing (BSC side) added
Updated by neels almost 6 years ago
- Related to Feature #2581: osmo-gsm-tester: add test case: test dynamic timeslots added
Updated by neels almost 6 years 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
Updated by neels almost 6 years ago
- Status changed from New to In Progress
- % Done changed from 80 to 90
Updated by neels almost 6 years ago
- Status changed from In Progress to Resolved
- % Done changed from 90 to 100
