An RF group leader is a designated device that
-
analyzes real-time radio data collected by the system
-
calculates power and channel assignments, and
-
sends them to each controller in the RF group.
The RRM algorithms ensure system-wide stability, and restrain channel and power scheme changes to the appropriate local RF neighborhoods.
RF Group Leader is selected based on the controller with the greatest AP capacity (platform limit). If multiple controllers have the same capacity, the leader is selected based on the Group ID, which is a combination of the management IP address, AP capacity, random number, and so on. The one with the highest Group ID is selected as the leader.
RF Group Leader can be configured in two ways as follows:
-
Auto Mode: In this mode, the members of an RF group elect an RF group leader to maintain a primary power and channel scheme for the group. The RF grouping algorithm dynamically chooses the RF group leader and ensures that an RF group leader is always present. Group leader assignments can and do change (for instance, if the current RF group leader becomes inoperable or RF group members experience major changes).
-
Static Mode: In this mode, a user selects a controller as an RF group leader manually. In this mode, the leader and the members are manually configured and fixed. If the members are unable to join the RF group, the reason is indicated. The leader tries to establish a connection with a member every minute if the member has not joined in the previous attempt.
Note
-
When a controller becomes both leader and member for a specific radio, you get to view the IPv4 and IPv6 address as part of the group leader.
When a Controller A becomes a member and Controller B becomes a leader, the Controller A displays either IPv4 or IPv6 address of Controller B using the address it is connected.
So, if both leader and member are not the same, you get to view only one IPv4 or IPv6 address as a group leader in the member.
Pinning and cascading
If Dynamic Channel Assignment (DCA) needs to use the worst-performing radio as the single criterion for adopting a new channel plan, it can result in pinning or cascading problems.
The main cause of both pinning and cascading is that any potential channel plan changes are controlled by the RF circumstances of the worst-performing radio. The DCA algorithm does not do this; instead, it does the following:
-
Multiple local searches: The DCA search algorithm performs multiple local searches initiated by different radios in the same DCA run rather than performing a single global search that is driven by a single radio. This change addresses both pinning and cascading, while maintaining the desired flexibility and adaptability of DCA and without jeopardizing stability.
-
Multiple Channel Plan Change Initiators (CPCIs): Previously, the single worst radio was the sole initiator of a channel plan change. Now each radio in an RF group is evaluated and prioritized as a potential initiator. Intelligent randomization of the resulting list ensures that every radio is eventually evaluated, which eliminates the potential for pinning.
-
Limiting the propagation of channel plan changes (Localization): For each CPCI radio, the DCA algorithm performs a local search for a better channel plan, but only the CPCI radio itself and its one-hop neighboring access points are actually allowed to change their current transmit channels. The impact of an access point triggering a channel plan change is felt only to within two RF hops from that access point, and the actual channel plan changes are confined to within a one-hop RF neighborhood. Because this limitation applies across all CPCI radios, cascading cannot occur.
-
Non-RSSI-based cumulative cost metric: A cumulative cost metric measures how well an entire region, neighborhood, or network performs with respect to a given channel plan. The individual cost metrics of all the access points in that area are considered in order to provide an overall understanding of the channel plan’s quality. These metrics ensure that the improvement or deterioration of each single radio is factored into any channel plan change. The objective is to prevent channel plan changes in which a single radio improves, but at the expense of multiple other radios experiencing a considerable performance decline.
The RRM algorithms run at a specified updated interval, which is 600 seconds by default. Between update intervals, the RF group leader sends keepalive messages to each of the RF group members and collects real-time RF data.
Note
Several monitoring intervals are also available. See the Configuring RRM section for details.
RF grouping failure reason codes
RF Grouping failure reason codes and their explanations are listed below:
Table 2.
RF Grouping Failure Reason Codes
| Reason Code |
Description |
| 1 |
Maximum number (20) of controllers are already present in the group. |
| 2 |
If the following conditions are met:
|
| 3 |
Group ID do not match. |
| 4 |
Request does not include source type. |
| 5 |
Group spilt message to all member while group is being reformed. |
| 6 |
Auto leader is joining a static leader, during the process deletes all the members. |
| 9 |
Grouping mode is turned off. |
| 11 |
Country code does not match. |
| 12 |
Controller is up in hierarchy compared to sender of join command (static mode). Requestor is up in hierarchy (auto mode). |
| 13 |
Controller is configured as static leader and receives join request from another static leader. |
| 14 |
Controller is already a member of static group and receives a join request from another static leader. |
| 15 |
Controller is a static leader and receives join request from non-static member. |
| 16 |
Join request is not intended to the controller. Controller name and IP do not match. |
| 18 |
RF domain do not match. |
| 19 |
Controller received a Hello packet at incorrect state. |
| 20 |
Controller has already joined Auto leader, now gets a join request from static leader. |
| 21 |
Group mode change. Domain name change from CLI. Static member is removed from CLI. |
| 22 |
Max switch size (350) is reached |