Baloo state machine

Objective

Describe the minimal state machine implemented by the middleware layer in Baloo.

Description

For generality and simplicity, the middleware implements only a minimal state machine. A node is either in Bootstrapping, Suspended, or Running state. The state transitions result from (un)successful receptions of control packets.

An important concept of Baloo is that a node does not participate in a communication round unless it knows exactly how it is supposed to execute. In general, this implies that a node must successfully receive the control packet. The objective is that even in case of packet losses, a node never disturbs the execution of the rest of the network.

There are three binary events associated with the (tentative) reception of a control packet:

• received indicates that a non-corrupted synchronization packet has been successfully received by the radio,
• valid indicates that the received packets matches the expected format of a control packet (e.g., verifies that the magic number is correct),
• config indicates that the control packet contains a configuration section (as described here, sending the configuration in the control packet is optional).

The middleware in Baloo implements a minimal state machine where a node is either in the Bootstrapping, Suspended, or Running state.

The Baloo host is always in Running state; It always knows what should be done, since it is the one making the decisions. All other nodes start in the Bootstrapping state.

In Bootstrapping, nodes listen for some time (based on the expected length of the control slot). If no packet is received, the middleware executes the on_bootstrap_timeout() callback which allows the user to add some delay before the middleware attempt to received a control packet again (read more about Baloo's callbacks here).

As shown on the state machine, a node transition to the Running state once it has received a valid control packet with a configuration section (as described here, sending the configuration in the control packet is optional).

Once a node has bootstrapped, the reception of any control packet results in staying in the Running state. If no configuration is included in the control, the configuration parameters from the previous round are used.

If a node misses a control packet, it becomes uncertain about the configuration parameters that should be used, as they may have changed in the packet that has been missed. The following fall-back mechanism is used:

• The node transition to the Suspended state. In this state, a node does not participate in the round. The on_round_finished() callback is executed immediately and the middleware yields (see Baloo's program flow).
• The middleware opportunisticly assumes that the round period did not change and schedules the wake-up for the next round accordingly.
• In the next round, if a valid control packet with configuration is received, the node transitions to the Running state and resumes its normal operation. Otherwise, it goes back to the Bootstrapping state.

Note
This is the default behavior implemented in Baloo. Baloo's advanced state machine feature lets the user modiy this behavior through the on_control_slot_post() callback.

---

Next > Baloo - Callback functions