Most important criteria: stability, i.e. clusterheads should change as seldom as possible.
Least Clusterhead Change algorithm: two conditions cause the clusterhead to change (a) two clusterheads come within range of each other (b) a node becomes desconnected from any cluster
Adjacent clusters have orthogonal codes.
Within a cluster, priority-token scheduling (PTS) is used to efficiently assign channels.
Gateways must receive packets from more than one cluster using different codes. If a gateway is not tuned to a particular cluster's code at a given time, the message sent to it is lost. Therefore, code scheduling is necessary to improve message performance.
Modified DSDV scheme called DSCR : Each node maintains 1) cluster member table for each destination node. 2) routing table used to select the next node to reach the destinatin cluster. Increasing destination-sequence numbers on routing updates are used to avoid stale updates and loops.
Clusterhead Gateway Switch Routing (CGSR): route packets alternatively through clusterheads and gateways. Rationale: Force routes to use clusterheads because clusterheads have more chances to transmit than other nodes.
MAC layer improvements, e.g. PTS and GCS, also reduces delay in routing.
CGSR+PTS+GCS yields 3 to 4 fold improvement over flat DSDV.
Path Reservation? does not yield consistent performance improvements.
Core/multicast server maintains a unique multicast identifier (Mid) for the group. Core has its own node id MSid Core floods network with Mid so that everyone else knows about it and can join if they wish. Alternatively, the Mids may be maintained in a directory server.
i sends JOIN_REQUEST to MSid using CGSR. JOIN_REQUEST is routed to MSid until it reaches any node j that's already a member of G. Node j responds with a JOIN_ACK to node i.
When an internal node n is traversed by JOIN_ACK, it records the upstream and downstream node of JOIN_ACK. Clusterhead of node i when it routes JOIN_ACK to i, records i as a member of G.
i sends QUIT_REQUEST to its clusterhead. Clusterhead updates membership info and replies with QUIT_ACK. If clusterhead has no more downstream members, it sends QUIT_ACK to its upstream node.
If a clusterhead member drops out, its downstream clusterhead nodes send a JOIN_REQUEST to the core. If a regular node moves to another cluster, its former clusterhead drops it from its member list and it sends a JOIN_REQUEST to its new clusterhead.
Loops may be formed when a moving node receives JOIN_ACK on a different path than JOIN_REQUEST. To avoid loops, any node already connected to the multicast tree must acknowledge a JOIN_ACK with a QUIT_REQUEST and forward the JOIN_ACK on its new path if this JOIN_ACK does not come from its upstream member. This enforces the policy that each node has only one upstream node.