Cellular Network Infrastructure » Radio Access Network » OsmoBTS

Right now, when BSC transmits an OPSTART message to osmo-bts, it is handled by common OML code in oml_rx_opstart(), which then calls BTS specific code bts_model_opstart().
This bts_mode_opstart() (hence each BTS type-specific implementation) dispatches an event to the related NM object depending on whether it went well or not: NM_EV_OPSTART_ACK or NM_EV_OPSTART_NACK

This means the FSM has not saying in whether an OPSTART should be ACKED or not, even before calling BTS low level specific implementation.
As a result, there's no easy way to for instance NACK an OPSTART if no attributes were yet applied for that NM object, or if the object is administratively locked, etc.

In order to do so, we should add a new FSM event NM_EV_RX_OML_OPSTART or alike. Each NM object should, when in proper state (DisabledOffline), call bts_mode_opstart() and if it returns an error, then send NM_EV_OPSTART_NACK.

Tip: according to TS 12.21, BTS is expected to answer with OPSTART ACK/NACK rather quickly, not necessarily after having went all the way Enabled. It's more only about signalling that it got the message and that it started the transition to Enabled state.