Reconfiguration Algorithm

Because the algorithms of the soft or hard merger are achieved in each merging network by means of a broadcast mechanism, it is insufficient to use these algorithms in the case of merging with a very small network (Unstable network). The LHA algorithm deals with this case by using the reconfiguration algorithm, applied only on the smaller unstable network. The basic idea is that all nodes in the small network have to release their address configuration and get a new one from the big network. As there are few nodes in “Unstable network” the requesting nodes do not cause high signaling overhead. Moreover, the reconfiguration algorithm is designed to keep this cost to a minimum. Here follow the details of the algorithm.

As already explained above, the reconfiguration algorithm is selected when an unstable net- work merges with another network which has a bigger number of nodes (this may be an unstable or a stable network). Let us suppose that a stable network merges with unstable one as shown in Figure 3-20, where Y and X indicate stable and unstable networks respectively. In this case the nodes in the unstable network (X) have to release their configurations (addresses and network configuration) and then they have to get new configurations from the other merging network (Y) as shown in steps 1 and 2 in the figure.

Figure 3-20: Merging scenario in case of two networks (stable merges with unstable network)

Depending on which border node first detects the merger, there are two scenarios:

1 2 3

7 5 ₆ 8 9

4 0

mer_Th= 5

Stable network = “Y”

Where CN >= mer_Th Nodes release their addresses Unstable network = “X” Where CN < mer_Th Step 2 3 5 7 1 2 3 7 5 6 8 9 4 0 1 3 2 7 5 6 8 9 4 0 12 10 11 Step1 Request new addresses from stable network Beacon Info messages

3.6 Network Merger Algorithms

• Say a border node of network X detects the merger first. This means that it receives a

Beacon message sent by a border node from network Y. Therefore, this node follows the merging algorithm as follows:

o It compares its parameters with the parameters in the received beacon. In the figure the node detects a merger with a stable network. Because of CN< mer_Th (merger threshold) the node knows that it has to release its configura- tion.

o Then, the two border nodes exchange their information by means of info mes- sages (Info_Req and Info_Rep). Therefore, the node that receives the Beacon sends Info_Req message including its parameters and tables to the other border node which has sent the Beacon (in this case, to the node from network Y) and waits for a reply.

o Upon receipt of the request message the border node of network Y compares its data with the info received. The comparison indicates that there is a merg- ing with an unstable network. The node, then, checks its assigning list. If the node has free address it sends Info_Rep message including its information and a free address which will be assigned to the border node of network X. Other- wise, it sends the Info_Rep message including only its information to the bor- der node of network X.

o When the border node of network X receives the Info_Rep message, it starts the reconfiguring state which consists of two states as illustrated in ure 3-21.

 In “checking for change” state the node checks if the received Info_Rep

message includes a free address or not as follows:

• If there is a free address it saves the old configuration (e.g. the

old HierID), assigns itself with the free address and changes its configuration data into the new received one. Then it sends Re- lease Configuration (Rel_Conf) message to the other nodes in the network X and, also, sends New_Node message to the nodes in network Y. After that, the node set “true” value to a Boolean variable (changed) which indicates to the change in the configu- ration of this node. Then it sets a release change timeout (Tm- reCh) and enters the state “Wait for network change”.

3.6 Network Merger Algorithms

Figure 3-21: State machine of reconfiguring status

• If the Info_Rep message does not include a new address the

node sets “false” to (changed) and sends a Rel_Conf message to the other nodes in the network X. After that, the node has to wait for a timeout “Tm-reCh” to ensure that the Rel_Conf mes- sage has been received by all nodes.

 In “Wait for network change” state, the node waits for the other nodes

to complete the release of their old configuration. During the timeout (Tm-reCh) if the node receives from its neighbors any Beacon message including the old information it knows that this node has not received the Rel_Conf message. In this case it sends the message again to the sender of the old information. When the timeout period is passed, the node releases the reconfiguring status and checks the changed value. In the case of “true” value, the node resumes working as a part of the new network (network Y) with the new configuration. This means if the node receives an AA_Sol message it calculates the new address with regard to its new configuration. Otherwise, in the case of “false” value, the node begins a normal assigning algorithm like any new node join- ing the network. In this way the node gets a new address from any neighboring node of network Y. When the node receives the new con- figuration it can work as a part of the network Y.

o Upon receipt of Rel_Conf message each node from the network X has to re- lease its configuration data and try to get a new one from any node from the network Y. However, before the node requests a new address from the new

Reconfiguring

Wait for network Change

Tm-ReCh / set (finish_merger = true) [includes free address]/

Rel_Conf.br, New_Node.br, set (old HierID, Tm-ReCh), set (changed = true)

Checking for change

[info message doesn't include free address] / Rel_Conf, set (Tm-ReCh, changed=false)

Beacon [old information]/ Rel_Conf.un

Info_Rep || Info_Req [merger with bigger network and my network unstable]

Rel_Conf / Rel_Conf, set (Tm-ReCh, changed=false)

3.6 Network Merger Algorithms

network the node has to forward the message to other nodes in its network. To do that, the node enters “Wait for network change” state. As mentioned above, the node in this state waits for the duration to ensure that all nodes in its net- work have got the Rel_Conf message. Then the node release the “Reconfigura- tion” state and because changed =false in this case the node starts as a new node joining a network, as described in Section 3.5.

• The second scenario is that, the border node from the network Y detects the merger

first. This means it detects that there is a merger with unstable network because of (CN < mer_Th). the algorithm ,then, will be as follows:

o The node sends Info_Req message including its information to the border node of network X. In addition to the network configuration the message may in- clude an allocated address if the node owns a free one.

o When it receives this message, the border node of network X knows that there is a merger with a stable network and the nodes in its network have to release their configuration and get a new one from the new network. So it enters “checking for change” state and follows the algorithm as described above in the first scenario, the case where the node of X receives Info_Rep.

o When the other nodes in the network X receive Rel_Conf message they will follow the steps as mentioned above in the first scenario (the steps of “Wait for network change” state).