IMPORTANCIA DEL LENGUAJE EN LA COMUNICACIÓN

The main objective of this protocol is to provide energy-efficient and robust communication. The energy efficiency is achieved by load sharing at two levels:

 Network level: cluster-head node perform traffic multiplexing over multiple paths

 Cluster level: rotation of the cluster head role every given interval of time

This will prevent energy depletion resulting from constantly using the same path for transmission or single node playing the role of cluster head.

On the other hand, storing multiple paths is not only used for load balancing but also when path failures occur. When a path fails, an alternative path can be immediately used which makes the protocol dynamically adapt to failures without delays or degradation in the quality of service. Since the role of cluster-head is energy consuming, new cluster-heads are selected after a constant period of time called round time. After each round time, one node is selected to play the role of cluster-head and one or more nodes are selected to act as cluster-head backup nodes. The backup node is used to substitute for the original cluster-head in case of failure or when the current cluster-head decide to reduce its participation in the protocol if energy level approaches a certain threshold value. As in LEACH, this algorithm uses TDMA/CDMA MAC to reduce inter-cluster, and intra-cluster collisions.

Each node knows at least two paths, one to the cluster-head and the other directly to the sink. The latter is only used when path to the cluster-head fails. All nodes in the network, sensing and cluster-head nodes perform data aggregation. The benefits of data aggregation is studied in detail in this section. Furthermore, each node suggests itself to play the role of

backup node for the current cluster round. In case of failure the cluster-head role will be handed to the backup node which will start new cluster by broadcasting an advertisement message. The backup node could be any node with enough energy. In this protocol we have introduced a

"NumHop" metric that indicates how far the cluster-head from the sensing node is. This new metric allow nodes to: 1- Select the nearest cluster-head node, which saves energy and reduces messaging. 2- Allow nodes to learn the best/shortest path to the selected cluster-head. We have also introduced a waiting time similar to one proposed in [53]. This waiting time will decrease the number of setup messages and help to form more uniform clusters (energy efficient cluster formation). The operation of our new routing protocol consists of two phases: setup phase and data transfer phase.

4.1.1 Setup phase

During the setup phase clusters are created and cluster-head nodes are selected using the threshold function given in [10].

where P is the difference of the desired percentage of cluster heads (pc) and percentage of retained clusters (pr), G is the set of nodes that have not yet become cluster-head members for the last 1/P rounds and r is the current round. Initially r will be zero as there are no clusters in the network. In [10], it was found that the optimal number of cluster-head nodes is 5% of the total number of nodes in the network. Initially, nodes are in "Waiting" state waiting to be discovered by the sink. The sink will randomly select some nodes to play the cluster-head role and flood and

"INICH" message to inform them that they have been selected to be

T(n)=

P/[1-P*(rmod(1/P))] if n Є G 0 otherwise

cluster-heads. Upon receiving the "INICH" message, nodes change their state into "Actuator" and check to find out if they are in the forwarded cluster-head list, if yes; nodes will start creating new cluster by broadcasting an advertisement message called "ImCH" message, otherwise, node will simply broadcast the received message to its neighbours. Each node will remember the node from which it has received the "INICH" message as the nearest neighbour to the sink. This path will be used for transmitting "ToS" messages directly to the sink, not through the cluster-head, in case of failures in the path to cluster-head.

When a node discover that it has been selected as a cluster-head, it broadcast an advertisement message called "ImCH" to publish its new role. Nodes will register themselves with the closest cluster-head. The closest node is known from the "NumHop" metric forwarded with the

"ImCH" advertisement message. This metric indicates the number of hops to reach the cluster-head. When a node receives and "ImCH"

message it will do the following:

a- If node already belongs to cluster, then ignore the received advertisement message

b- If waiting timer is not expired and this is the first advertisement received, the node first remembers the node from which it received the message as the closest node to cluster-head node. Second, it remembers the cluster-head node address. Third, it increment the number of hops value. Forth, it will start up the waiting timer.

During the timer life time, node will be able to receive "ImCH"

advertisements but it will only consider those advertisements with better "NumHop" metric and update its data accordingly.

c- When the timer expires, the node will assign itself to the cluster with the best "NumHop" metric. Then it calculates a value call

"Wish" and sends it to the cluster-head through the path it learned

from the "ImCH" message. Finally, it forwards the "ImCH"

message with best "NumHop" value to neighbours and it can start receiving and sending data to the cluster-head node.

The "Wish" value could model node available energy and other factors that participate in playing efficiently the cluster-head role. Nodes can receive many advertisement messages from different cluster-heads and depending on the "NumHop" metric, node choose to which cluster it will belong by sending a registration request back to the cluster head. The registration message is the same as the "Wish" message for efficiency. If the node wants to register with the cluster-head node it simply generate and send a "Wish" message, otherwise, it does nothing. This combination of registration and "Wish" messages reduce messaging overhead; when a cluster-head node receive a "Wish" message it understand that the node want to belong to the cluster and the wish value represent how much suitable it is to play cluster-head role in the next round. This makes the protocol more stable that reduce messages sent over the network.

Each “Wish” message contains the address of the sending node and the path to that node in addition to the wish value. The cluster-head node uses the received “Wish” value to select backup node(s). The cluster-head will always remember the path of the node(s) that generated the best wish value. The backup node functions as a normal node and it is not aware that it was accepted as cluster-head node, this saves notifying the backup node that its not backup node any more in case the cluster-head receive better “Wish” message from different source. After the cluster-head timer expires, it will send the backup node a notification message called “NOT” to tell the backup node to start new cluster immediately.

The current cluster-head node will change to a sensing node and it will wait for an advertisement to join a cluster to become part of the network again. The cluster-head role will also be handed to backup node when a

fault happens to the current cluster-head node. However, this is limited to small set of faults like when counting an internal error or when the energy level approaches a threshold. But in case of faults like physical damage or fatal internal errors in the cluster-head the nodes will wait until they expire and join a new cluster. The table below summarize various messages sent through out the protocol lifetime.

Message Type

Description Colour

INICH Sent by sink when the protocol starts for the first time. It contains a list of selected cluster head node. Nodes receiving the message become discovered and change stat from “Waiting” to “Actuator”. This is sent only one time in the protocol life time unless new nodes are deployed. Nodes remember the node they receive the message from as the nearest neighbouring node to the sink.

Red

ImCH This is the advertisement message that selected cluster-head nodes send to publish their new role in the protocol.

Blue

NOT Sent by current cluster-head node to tell the backup node to start new cluster. cluster-head node. When a node in the path fails to send the message to next node in the path, it forwards the packet to randomly selected neighbour (Grey).

Black

Table 3: Messages summary

When a node receives an "ImCH" message, it waits for a short period of time for messages from other cluster-head nodes to arrive and choose to join the cluster with better "NumHops" metric which may arrive during this time. When the waiting time ends, the node increment the best

"NumHops" value by one and broadcast the "ImCH" message with the minimum number of hops to cluster-head. In that way, the number of setup messages in every cluster, consequently in the entire network, will

decrease dramatically. Furthermore, clusters will be formed more uniformly leading to minimum energy consumption within the cluster, thus increasing the overall network lifetime.

4.1.2 Data Transmission Phase

During the transmission phase, sensing nodes transmit data to their cluster-head. Cluster-heads aggregate received data before transmission to the sink or multiplex messages over multiple lines in case of time critical applications. The cluster-head encapsulate messages with the cluster-head address before transmission which vitalize that all packets are sent from a single node. However, the original source sensing node address can be extracted if application requires. This phase can exist and new cluster setup round can be triggered when a node approach energy threshold and backup node is absent. Otherwise, cluster-head hand its rule to the backup node smoothly without interrupting the entire cluster functionality. Each member node transmits data on its assigned time slot scheduled by TDMA. Furthermore, each cluster communicates using unique CDMA codes to avoid interference with traffic generated by other clusters. Code division multiple access [50] (CDMA) is a multiplexing scheme and a method of multiple access that encodes data with a special code associated with each channel and uses the constructive interference properties of the special codes to perform the multiplexing instead of dividing up the channel by time (as in TDMA), or frequency (as in FDMA). The election of backup nodes wishing to serve as cluster-head is done internally within the cluster depending on the energy level of each node and other related factors. This process will be initiated every time the backup nodes queue is empty which decrease the possibility of going back to complete setup phase. The last mentioned feature makes the protocol reliable and dynamically adaptable to faults.