Cellular Network Infrastructure » Radio Access Network » OsmoBTS

Note: the same script could be used for other FSMs.

Ok, when I look at dtx_dl_amr_fsm.c, the actions for each state are trivial
in that each incoming event simply transitions to the corresponding state.

However, when you look at the VLR fsm code, auto-generation is not as simple:

• things have to be verified
• some events have no clear 1:1 mapping to a state
• arbitrary actions need to be taken, like start other fsms, send messages etc.

Generate this:

https://git.osmocom.org/openbsc/tree/openbsc/src/libvlr/vlr_lu_fsm.c?h=neels/vlr
https://git.osmocom.org/openbsc/tree/openbsc/src/libvlr/vlr_auth_fsm.c?h=neels/vlr

So I doubt that fsm generation from dot will impact beyond the dtx_dl_amr_fsm.
There though it might be quite useful, given that you expect it to change a lot.

It's just matter of splitting state transition logic (completely described by .dot file) from action logic (application-specific) which I think is a good practice anyway. The former should be autogenerated and include calls to functions like ...fsm_state_XXX_evt_YYY() which will contain action logic. Btw, events should not have any mapping to states - those are orthogonal concepts, do not mix them. States are nodes of the graph representing FSM, events are the external signals which cause transitions between those nodes.

Btw, events should not have any mapping to states - those are orthogonal concepts, do not mix them.

I wouldn't call it orthogonal: each state allows a limited set of events to transition to a limited set of other states.
I assume you refer to "some events have no clear 1:1 mapping to a state"; by that I meant:
in the AMR FSM, when state X receives event foo, it always transitions to exactly state Y. But,
for example, in the http://kleinekatze.de/quooXai5/vlr_auth_fsm.dot.png FSM, the START event can
cause a transition to either the WAIT_RESP or the NEEDS_AUTH_WAIT_AI state, which depends on the
decision made in "arbitrary" C code that is also part of the FSM logic.

But let's not get carried away in theoretical discussions.

I would agree that the osmo_fsm code could be made less generalistic, to benefit
automatic generation of graphs or vice versa. Let your patches speak? :)
When writing, it would be good to incorporate the complex VLR FSMs as well.

neels wrote:

for example, in the http://kleinekatze.de/quooXai5/vlr_auth_fsm.dot.png FSM, the START event can
cause a transition to either the WAIT_RESP or the NEEDS_AUTH_WAIT_AI state, which depends on the
decision made in "arbitrary" C code that is also part of the FSM logic.

I think this should be rewritten to remove such ambiguities - for example by splitting one state into couple of separate states. I hope to get to this once autogeneration for DTX FSM is in place.

laforge wrote:

I don't think this is the way to go. In reality, you always have such
situations. the osmo_fsm code was written to be able to reflect the
state machines (with their events and states) as they are specified in
e.g. 3GPP specs.

Well, in this case we just have to ask user to supply function which will make this selection resolving the ambiguity. Anyway, let's take care about such implementation details when we'll come around to actually implementing it.