Cellular Network Infrastructure » Radio Access Network » OsmoBSC

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.

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

https://gerrit.osmocom.org/8042 and https://gerrit.osmocom.org/8043