SOOlink Winenet datalink protocol

I’m currently re-working out the Winenet protocol which is implemented as datalink protocol in SOOlink for wireless connectivity between smart objects.
Winenet uses the so-called Unibroad transmission mode which consists in broadcasting data packets to all known neighbours but actually using a unicast mode; it allows to take advantage of a much better bandwidth in the wireless connection and to implement a simple protocol using send with acknowledgment for each packet.

So far, Winenet implements a FSM with a couple of states such as Idle, Speaker, Listener, Speaker_wait_ack, etc. leading to a quite complex handling of various scenarios. The new proposed solution is now based on 3 states only: Idle, Speaker and Listener. All acknowledgment and possible retries of packets are managed within the Speaker state.

Furthermore, each smart object owns a list of neighbours as depicted on the figure below, and for each known neighbour, we also know the list of its neighbours. This will help in managing hidden nodes and to reduce interference when a smart object is sending data.


Hence, each smart object owns a list of neighbours and their “friends”. The friends are listed in bracket.

A smart object which is showing up in the environment is recognized by the beacon packets sent by the Discovery block (every second). The smart object becomes valid by the other SOO once it has been ping’d correctly.
Depending on its agency UID, it will send a PING REQUEST and waits for a RESPONSE. This exchange will determine which can become a speaker or listener (the lowest agencyUID has the priority and becomes a speaker). But the smart object becomes speaker only if the other one has no associated speaker yet (this information is now part of the private data encoded in the beacon).