In this section, an algorithmic vision of the different phases of the MINSENS++ protocol will be given. For a better understand, each subsection corresponds to each phase of the protocol.
5.2.1 Nodes and routes discovery
In the beginning of the protocol, each Base Station bsIDbroadcasts a route request mes- sage to the network. The message has the hRREQ, bsIDi format, and is propagated epi- demically.
When a node ni receives one of that messages, it verifies if it has already received that message ("infected" by bsID). If the message is new, the emitter is added to the neighbours’ set (Ni) and defined as father of i; otherwise, the emitter is just added to Ni.
After a certain amount of time, ni sends to bsID its neighbourhood data; this data is sent through the inverse path (ie., each node sends to its father until reach bsID). This message has the hFDBK, i, Nii format.
Base Stations store the neighbourhoods’ data, in order to compute the network’s routes. In each BS, disjoint routes are computed like in INSENS (3.2.4); however, it is necessary that all the routes computed by all the BSs are disjoint. To accomplish this, a routes’ consensus is done between all BSs as explained in6.4.1. When the routes are consensual, they are saved in the routing tables that will be sent to each routes’ source.
5.2.2 Routes selection
When the routing tables’ computation is ended, they must be distributed over the net- work’s nodes. This distribution is ordered by the distance between the Base Station and the node; this way, routing tables from nearer nodes can be used to route the routing tables of the farther ones.
This messages are called route update and have the following format: hRUPD, bsID, ni, routing_tablei, where bsID is the (unique) ID of the BS, ni is the (unique) ID of the node and routing_table is the set of disjoint routes from nito bsID. The routing table is ciphered with a symmetric key (shared with the destination sensor node) in order to allow just ni to access its contents.
A sensor node (ni) stores in its final routing table the union of all the received routing tables (to different BSs).
However, a sensor node (ni) can receive a message whose destination is not it. In this case, it verifies if has in its routing table a path from the destination node (nk) until the emitting BS; if so the message is retransmitted.
When (ni) has its routing table complete (with routes to all the BSs), it declares itself as stable. This means it is ready to start disseminating and routing data over the network.
This description is summarised in Algorithm1.
Input: ID of the node nodeIdi
routingT ablei ← ∅
when m = hRU P D, bsId, nodeId, routingT ablei is received do
if nodeId = nodeIdithen
routingT ablei ← routingT ablei∪ routingT able;
else
if routingT ablei contains route to nodeId then
broadcast(m);
end end end
5.2.3 Data routing
In MINSENS++ protocol, data routing is divided in two distinct phases: 1. Routing between sensor nodes;
2. Data consensus in each Base Station.
The first phase deals with the data packets’ routing, through the computed routes, from the origin until the BSs.
In the second phase, each Base Station must manage the reception of the different replicas of a given message (received from different routes). Then, the Base Station per- forms the consensus protocol over the received data. This phase shall not be confused with the consensus referred in the end of5.1.3. The consensus referred at this point is lo- cal to each Base Station; as a different number of replicas of a given message are received by a given Base Station, a local consensus is made in order to determine the correct value of the message. Then, the product of this consensus is used as referred in the end of5.1.3
to do a distributed consensus within all the Base Stations. We can then say that the final consensual value is the result of the (distributed) consensus of many (local) consensus.
Once more, in this chapter just the local consensus will be discussed. As stated in the end of5.1.3, the distributed consensus is studied in Chapter6(page61).
5.2.3.1 Routing between sensor nodes
Sensor nodes are regularly measuring physical phenomenons and environmental vari- ables; this measured data must then be sent to the Base Stations. Data messages have the following format: hDATA, id, ni, bsID, routes, r, datai, where id is the (unique) ID of the message, niis the (unique) ID of the source node, bsIDis the (unique) ID of the BS, routes is the set of routes that will disseminate the message, r is the current route of this copy of the message and data is the ciphered data. The messages are authenticated with MAC, assuring also the integrity of the message.
MINSENS++ provides five routing modes: 1. Routing trough one random route;
2. Routing trough one route chosen accordingly with a round-robin1policy; 3. Routing trough k random routes;
4. Routing trough k random routes, balanced by Base Station; 5. Routing trough all the routes.
1Round-robin is one of the simplest scheduling algorithms. It consists in selecting each resource in a
When the data is sent just through one route, data arrives just to one BS. In the other hand, if the data is sent through more than one route, two different situations may occur: data can be sent through multiple routes just to the same Base Station or can be sent through multiple routes to different Base Stations (possibly, more than one route to each Base Station).
In Algorithm2, the routing process is presented. When a sensor node is ready to send a new message m, it broadcasts m. Another sensor node receiving m verifies if any of the routes of the message is present in its routing table; if so, the message is retransmitted; otherwise, it is ignored.
In order to reduce the messages’ number in the network, each node has a log of re- ceived messages, in order to retransmit just new messages.
Input: ID of source node nodeIdi; routing table rti; routing mode rmi
when has data ready to send do
msgId ←get new unique message identifier; routes ←get routes for rmifrom rti;
foreach r : r ∈ routes do
d ←destination of r;
broadcast(hDAT A, msgId, nodeIdi, d, routes, r, datai);
end end
when m = hDAT A, id, s, d, routes, r, datai is received do
if nodeIdi = dthen
handle reception of m;
else
if ∃route ∈ rti: routeidentifier = r then
broadcast(m);
end end end
Algorithm 2:Data messages routing protocol
5.2.3.2 Data consensus in each Base Station
This phase is started when a message reaches a Base Station, and it depends on the rout- ing mode.
When a message is routed just through one route to one Base Station, the BS validates the message and (when valid) delivers it to the application level. This validation verifies the message’s authentication and integrity.
When a message reaches a given BS through many routes, the BS stores all the dif- ferent replicas of the message. Then a consensus is made and when the BS stored more
than half of the replicas (message2_routes) with the same value, message is validated (with the consensual value). At this point, two possibilities exist: the message is just destined to that BS and after the validation, the message is delivered to application level; or the message was sent to many BSs and it’s necessary to start a consensus process between all the BSs with the local validated data (more on this in the next chapter).
It is important to understand that if the BSs agree in a given value (of a message), it is considered a valid message and passed to the application level by all the correct BSs. If a consensus is not reached, the message is simply ignored. When the message is passed to the application level, its contents are deciphered in the BSs.