## 3 Proposed Protocol
### Cluster Formulation, Maintenance and Update
If the node belongs to the cluster controlled by the CH generating the message, the node forwards it to its neighbours. In addition, it stores the message to a local cache in order to avoid serving the same message again. Otherwise, if the node does not belong to the cluster controlled by the CH generating the message, the node belongs to the borderline between two clusters, as shown in Figure 1. In this case, the node does not forward the message to its neighbour but instead forwards it directly to its CH. This process is very critical as it prevents the unnecessary flooding out of the scope of a cluster and allows CHs to be aware of their neighbouring CHs. The routing information, collected to the CHs' caches during the clusters formulation, facilitates the hierarchical routing mechanism, as discussed in Section 2.3. The cluster formulation and maintenance process is also shown in Figure 2.  
Figure 1: Controlled Flooding Mechanism. 2. _Routing Cache Maintenance:_ Each _MSolicitateCH_ message--broadcasted by a CH and flooded within the cluster--contains a list of the MAC addresses of the nodes that have already forwarded it since each node that serves this message appends its MAC to this list (only once due to cycle preventive mechanism). This information allows cluster nodes to learn (or update) the shortest path towards their CH and store this information in their local routing cache. 3. _Cluster Formulation Update:_ The _MSolicitateCH_ message allows nodes to be dynamically distributed among the existing clusters according to the CHs KPIs. In case that a node receives a _MSolicitateCH_ message from a neighbouring CH, it compares the received KPI with the KPI of its current CH. When this comparison overcomes a specified threshold, the node unregisters from its current CH and registers to the new CH. These tasks are accomplished with the usage of a _MRegisterNode2 CH_ and _MUnRegisterNodefromCH_ message, accordingly. This approach allows CHs to extend their lifetime since the load is re-distributed among the more powerful CHs. Figure 3: Periodic Mechanism for CH election. Figure 2: Solicitation Mechanism. The NEURON clustering mechanism allows the autonomic re-formulation of clusters and enables the adaptation of the clusters' number and formation to the existing network conditions. This mechanism is initiated either because a CH decides to return to normal operation mode or because the CH leaves the network due to an unforeseen situation. In the first case, when the KPI of the CH passes below a specified threshold, the node stops to undertake the role of CH and a _MSolicitateCHDOWN_ message is flooded within its cluster. Nodes update their routing cache and inform neighbouring CHs, provided that routing information for them is available in their routing cache. The re-clustering mechanism is then invoked and the cluster members decide to become a CH with the current probability _Pclust_. If no CH is elected, the nodes join a neighbouring cluster after receiving a neighbouring _MSolicitateCH_ message. In the second case, if the _MSolicitateCH_ message is not received within a period, the node updates the routing cache and initiates the re-clustering mechanism as previously (Figure 3). It should be noted that the CHs remove any entries from their routing cache related with neighbouring CHs if no relevant _MSolicitateCH_ message is received within a specific period.