## 5 Architecture Proposal Operation and Fault Tolerance  
In order to join the architecture, the new node broadcasts a \"Discovery\" message. CHs will reply with a \"Discovery ACK\" message with their position and \(\lambda\) parameter. There could be three possibilities:  
1. If it does not receive any reply within 10 seconds, it becomes a CH, so it creates the cluster and waits for new nodes. Ten seconds have been chosen because it is enough time to receive a reply from a near node. Later replies will be from nodes which are either too far or too busy. 2. If it receives some replies, but none of them are at a distance lower than the Max_distance, it becomes a CH and sends an \"H connect\" message to establish connections with selected CHs (based on their \(\lambda\) parameter). If the other CH confirms that connection, it adds this entry to its CH table and sends a \"Welcome H\" message with the last _clusterID_ in the network. The CH will choose the next available _clusterID_ for its cluster. Then, the new CH will send \"Keepalive H\" messages periodically with its _clusterID_ to its neighbor CHs to indicate it is alive. If a CH does not receive a \"Keepalive H\" message from a CH for a dead time, it would erase that entry from the database. \"Keepalive H\" messages contain sender's _clusterID_ and \(\lambda\) parameter. The CH also follows the new CM process described later. Messages sent in this case, when there is a new CH, are shown in Figure 9. Once the discovering process has finished CH node's network works as a regular OLSR network. 3. If it receives one or several replies and all of them are within a distance lower than the Max_distance, it chooses the closest CH and in case of a draw, the one with highest \(\lambda\) parameter. Then, it sends an \"M connect\" message to establish a connection with the selected CH. If the other CH confirms that connection because it has not reached the maximum number of connections, it adds this entry to its CM table, sends a \"Welcome  
Figure 8: Diameter. M\" message and the new node becomes a CM. If the CH does not agree the connection, the new node sends an \"M connect\" message to the second best CH and follows the same steps. This process is repeated until the new node reaches the last option. If the last option does not confirm the connection, the new node becomes a CH and follows the steps explained in case 2. When a CM receives a \"Welcome M\" message, it will know which its cluster is. It will send \"Keepalive M\" messages periodically to the CH to indicate it is alive. If the CH does not receive a \"Keepalive M\" message from a CM for a dead time, it will erase that entry from the database. \"Keepalive M\" messages contain the _nodeID_ of the sender, its \(\lambda\) and its \(\delta\) parameters. Steps followed when there is a new CM in this third case are shown in Figure 10.  
When there is a new CM in a cluster, it has to establish connections with CMs from other clusters. They must be the same type of CM, and then, the distance between them has to be lower than or equal to than Max_distance (remember that it could be changed by the Received Signal Strength Indication (RSSI) value or by the Signal Noise Ratio (SNR) value or by any other parameter that can be used to know if the neighbor is reachable). First, it has to send a \"CM request\" message to the CH of its cluster. This message has the requester's CM type and its position. When the CH receives this message, it changes the _nodeID_ by the _clusterID_ in the message and forwards it. It is sent only to neighboring CHs because they are the only ones that will meet the Max_distance requisites. When a CH of another cluster receives that message, it sends the message to the appropriate CM (based on the type of CM). CMs that have not reached the Max_con value will send a \"CM connect\" message to the new CM. If it  
Figure 10: Protocol opOperation for a new CM. Figure 9: Protocol operation for a new CH.