# Adaptive Multi-Channel Clustering in IEEE 802.11s Wireless Mesh Networks +
## 4 The CHaChA Clustering Approach
### Online Cluster Adaptation
#### 4.4.3 Roaming between Clusters  
The coordinated transition of a CM from its previous cluster to a neighboring cluster is referred to as roaming. After reaching phase 7, roaming operations are used for cluster balancing, which is explained in more detail in Section 4.4.4. Our concept follows basic ideas of the work JRCAP [11], which also achieves balanced clusters through roaming. In JRCAP, a change of cluster membership is reserved for so-called relay nodes alone. These are edge nodes that connect neighboring clusters. When changing clusters, a negotiation takes place between the relay node and the new or old CH using ATTACH and DETACH messages, which must be acknowledged by the CHs, respectively. This provides CH-side control of roaming operations. However, unlike CHaChA, JRCAP does not provide for a dedicated base channel on which CHs announce their cluster status throughout the network. For example, the size of neighboring clusters is known only to relay nodes, which must pass it on to CHs as part of the negotiation process. Instead, CHaChA proposes a roaming variant that relies on information from CH broadcast messages as well as local 802.11s connection information. As in the related work JRCAP [11], the prerequisite for a CM to change clusters is that it is an edge node of its cluster. In addition, connection to at least one neighboring cluster must exist. CMs validate this using their 802.11s link and path lists as well as cluster information sent periodically by all CHs as broadcast messages on the base channel. This includes, among other things, the list of MAC addresses of all CMs of the respective cluster. If a mesh path exists to the CH of another cluster and at least one CM of this cluster is among the own mesh neighbors on the base channel, it is a neighboring cluster that can be switched to. If several possible roaming destinations exist, analogous to conventional cluster joining in CHaChA, the CH in smallest ALM distance is chosen. Another requirement is that the CM intending to roam does not itself act as intermediate node, connecting its CH and other CMs on the cluster channel. This is a conservative constraint, which ignores that alternative paths might exist via other nodes. However, it prevents clusters from being torn apart as a result of roaming, leading to undesirable isolation. To achieve this, neighboring CMs exchange so-called Next-Hop-to-CH (NH2 CH) messages with each other from phase 7 onward (see also Table 4 in Section 4.2). These messages provide information about which neighbor node (\"next hop\") the sender of the message is currently using on the path to its CH. If a CM does not act as next hop for any of its neighbors, it may perform a cluster switch. Figure 6 illustrates the restrictions with an example in which, out of four edge nodes, only the two outer ones do not act as next hops and are therefore allowed to roam. The roaming procedure of a CM takes place as a handover between previous and new CH according to Figure 7. Since CMs make the decision to roam independently and possibly simultaneously, there is a risk of erratic cluster changes and oscillation behavior. In the course of a bidirectional negotiation (handshake), CHs therefore decide on the acceptance or rejection of roaming requests. For example, by CH-side specification of a minimum time interval between roaming operations, a restriction on the frequency of cluster switches can be realized. To join the new cluster, the CM first sends a request to its CH in the form of a JOIN_REQ unicast message. The CH of the new cluster responds with a JOIN_RESP message to confirm or deny the request. In the absence of a response or an explicit rejection, the CM terminates the roaming operation. On acceptance, the CM analogously sends a LEAVE_REQ message to its current CH, which acknowledges it with a LEAVE_RESP message. With a final LEAVE message, the CM leaves the previous cluster and joins the new cluster using a JOIN message.