rf arm-profile
rf arm-profile <profile>
40MHz-allowed-bands {All|None|a-only|g-only}
80MHz support
160MHz support {Auto|Contiguous-only|Non-contiguous-only|None}
acceptable-coverage-index <number>
active-scan (not intended for use)
aggressive-scan
assignment {disable|maintain|multi-band|single-band}
backoff-time <seconds>
channel-quality-aware-arm
channel-quality-threshold <channel-quality-threshold>
channel-quality-wait-time <seconds>
client-aware
client-match
clone <profile>
cm-6ghz-band-steer
cm-band-a-min-signal <cm-band-a-min-signal>
cm-band-g-max-signal <cm-band-g-max-signal>
cm-dot11v
cm-he-min-signal
cm-he-pooling-signal-delta <cm-he-pooling-signal-delta>
cm-he-pooling-snr-thresh <cm-he-pooling-snr-thresh>
cm-lb-client-thresh <#-of-clients>
cm-lb-interval <cm-lb-interval>
cm-lb-signal-delta <cm-lb-signal-delta>
cm-lb-snr-thresh <dB>
cm-lb-thresh <%-of-clients>
cm-max-steer-fails <#-of-fails>
cm-mu-client-thresh <count>
cm-mu-snr-thresh <value>
cm-report-interval
cm-stale-age <secs>
cm-steer-backoff <secs>
cm-steer-timeout <secs>
cm-sticky-check_intvl <secs>
cm-sticky-min-signal <-dB>
cm-sticky-snr <dB>
cm-sticky-snr-delta
cm-update-interval <dB>
cm-unst-ageout-interval days <days> hours <hours>
cm-unst-ageout
default-6ghz
dynamic-bw
dynamic-bw-beacon-failed-thresh <dynamic-bw-beacon-failed-thresh>
dynamic-bw-cca-ibss-thresh <dynamic-bw-cca-ibss-thresh>
dynamic-bw-cca-intf-thresh <dynamic-bw-cca-intf-thresh>
dynamic-bw-clear-time <dynamic-bw-clear-time>
dynamic-bw-wait-time <dynamic-bw-wait-time>
error-rate-threshold <percent>
error-rate-wait-time <seconds>
free-channel-index <number>
high-noise-backoff-time <high-noise-backoff-time>
ideal-coverage-index <number>
interfering-ap-weight <number>
load-aware-scan-threshold
max-tx-power <dBm>
min-scan-time <# of scans>
min-tx-power <dBm>
mode-aware
multi-band-scan
no ...
ota-updates
ps-aware-scan
radar-backoff-time <radar-backoff-time>
rogue-ap-aware
scan mode {all-reg-domain|reg-domain}
scan-interval
scanning
video-aware-scan
voip-aware-scan
voip-aware-scan-timer
Description
This command configures the Adaptive Radio Management (ARM) profile. Adaptive Radio Management (ARM) is a radio frequency (RF) resource allocation algorithm that allows each AP to determine the optimum channel selection and transmit power setting to minimize interference and maximize coverage and throughput. This command configures an ARM profile that you apply to a radio profile for the 5 GHz or 2.4 GHz frequency band (see rf dot11a-radio-profile on page 1 or rf dot11g-radio-profile on page 1).
|
Parameter |
Description |
|
<profile> |
Name of this instance of the profile. The name must be 1-63 characters. default |
|
40MHz-allowed-bands |
The specified setting allows ARM to determine if 40 MHz mode of operation is allowed on the 5 GHz or 2.4 GHz frequency band only, on both frequency bands, or on neither frequency band. All/None/ a-only |
|
All |
Allows 40 MHz channels on both the 5 GHZ (802.11a) and 2.4 GHZ (802.11b/g) frequency bands. |
|
None |
Disallows use of 40 MHz channels. |
|
a-only |
Allows use of 40 MHz channels on the 5 GHZ (802.11a) frequency band only. |
|
g-only |
Allows use of 40 MHz channels on the 2.4 GHZ (802.11b/g) frequency band only. |
|
80MHz-support |
If enabled, 80 MHz channels can be used in the 5 GHz frequency band on APs that support 802.11ac. enabled |
|
160MHz support |
Specifies which 160 MHz mode to be assigned. This parameter does not apply to 2.4 GHz frequency band. |
|
Auto |
Allows automatic selection of contiguous frequency. |
|
Contiguous-only |
Allows to assign contiguous only 160 MHz channel bandwidth. |
|
Non-contiguous-only |
Allows to assign non-contiguous 160 MHz channel bandwidth. |
|
None |
This sub-parameter disallows assigning 160 MHz channel bandwidth. |
|
acceptable-coverage-index |
The minimal coverage that the AP should try to achieve on its channel. The denser the AP deployment, the lower this value should be. This setting applies to multi-band implementations only. 1-6 4 |
|
active-scan |
When active-scan is enabled, an AP initiates active scanning via probe request. This option elicits more information from nearby APs, but also creates additional management traffic on the network. This feature is disabled by default, and should not be enabled except under the direct supervision of HPE Aruba Networking Technical Support. disabled |
|
aggressive-scan |
When this feature is enabled, an AP radio with no clients will scan channels every second. enabled |
|
assignment |
Activates one of four ARM channel/power assignment modes. single-band (new installations only) |
|
disable |
Disables ARM channel/power assignments. |
|
maintain |
Maintains existing channel assignments. |
|
multi-band |
Computes ARM assignments for both 5 GHZ (802.11a) and 2.4 GHZ (802.11b/g) frequency bands. |
|
single-band |
Computes ARM assignments for a single band. |
|
backoff-time |
Time, in seconds, an AP backs off after requesting a new channel or power. 120-3600 240 sec |
|
channel-quality-aware-arm |
If enabled, ARM changes are based upon an internally calculated channel quality metric. When this feature is disabled, ARM initiates channel changes based on thresholds defined in this profile, and chooses the channel based on the calculated interference index value. disabled |
|
channel-quality-threshold |
Channel quality percentage below which ARM initiates a channel change. 0-100 70 |
|
channel-quality-wait-time |
If channel quality is below the specified channel quality threshold for this wait time period, ARM initiates a channel change. 1-3600 120 |
|
client-aware |
If the Client Aware option is enabled, the AP does not change channels if there is active client traffic on that AP. If Client Aware is disabled, the AP may change to a more optimal channel, but this change may also disrupt current client traffic. enabled |
|
client match |
ClientMatch helps optimize network resources by balancing clients across channels, regardless of whether the AP or the controller is responding to the wireless client’s probe requests. If enabled, the controller compares whether or not an AP has more clients than its neighboring APs on other channels. If an AP’s client load is at or over a predetermined threshold as compared to its immediate neighbors, or if a neighboring HPE Aruba Networking AP on another channel does not have any clients, load balancing will be enabled on that AP. enabled |
|
clone |
Name of an existing ARM profile from which parameter values are copied. |
|
cm-6ghz-band-steer |
Enable or disable Client Match band steers to 6GHz. |
|
cm-band-a-min-signal <cm-band-a-min-signal> |
Minimum signal level required for the targeted A band radio in a Client Match band steer move (-dBm). 0-255 dbm 75 |
|
cm-band-g-max-signal <cm-band-g-max-signal> |
Maximum signal level of the G band radio that can trigger a Client Match band steer move (-dBm) 0-255 dbm 45 |
|
cm-dot11v |
Client Match steers using 802.11v BSS Transition Management. enabled |
|
cm-he-min-signal |
Minimum signal required for the targeted HE move (-dbm). 0-255 dbm 55 |
|
cm-he-pooling-signal-delta |
Target radio should not have weaker signal strength than current source radio by the configured value. |
|
cm-he-pooling-snr-thresh |
Client match HE pooling SNR threshold (dB) at target radio |
|
cm-lb-client-thresh <#-of-clients> |
If an AP radio has fewer clients than the client match load balancing threshold defined by this parameter, the AP will not participate in load balancing. 0-100 30 |
|
cm-lb-interval <cm-lb-interval> |
Controls how often client load balancing will be done (in minutes). Set to 0 to disable Load Balancing. 0-255 minutes 5 minutes |
|
cm-lb-signal-delta |
Client match will not move a client to a new radio if the signal strength of the target AP is this dB value lower than the radio to which the client is currently associated. This parameter works differently than the cm-lb-snr-thresh value, which imposes a definite value on the target AP's signal-to-noise radio. the cm-lb-signal-delta imposes a relative constraint based upon the signal strength of the radio to which the client is currently associated. 0-20 dB 5 dB |
|
cm-lb-snr-thresh <dB> |
Clients must detect a SNR from an underutilized AP radio at or above this threshold before ClientMatch considers load balancing a client to that radio. 0-100 dB 25 |
|
cm-lb-thresh <%-of-clients> |
When ClientMatch is enabled, clients may be steered from a highly utilized channel on an AP to a channel with fewer clients. If a channel on an AP radio has this percentage fewer clients than another channel supported by the client, ClientMatch may move clients from the busier channel to the channel with fewer clients. 0-100% 20 |
|
cm-max-steer-fails <#-of-fails> |
The controller keeps track of the number of times ClientMatch failed to steer a client to a different radio, and the reason that each steer attempt was triggered. If ClientMatch attempts to steer a client to a new radio multiple consecutive times for the same reason but client steering fails each time, the controller notifies the AP to mark the client as unsteerable for that specific trigger. This parameter defines the maximum allowed number of client match steering fails with the same trigger before the client is marked as unsteerable for that trigger. 0-100 failures 5 |
|
cm-mu-client-thresh <count> |
Total number of clients that can be associated to a radio, in which the radio can still be considered for multi-user (MU) steering. 0-255 dbm 15 |
|
cm-mu-snr-thresh <value> |
Minimum SNR value of a client on the target radio, in which the radio can still be considered for multi-user (MU) steering. 0-255 dbm 30 |
|
cm-report-interval <secs> |
This interval defines how often an AP sends an updated client probe report to the controller. Each client probe report contains a list of MAC addresses for clients that have been active in the last two minutes, and the AP radio SNR values seen by those clients. 0-255 secs 30 |
|
cm-stale-age <secs> |
The controller can maintain client match data for the maximum number of supported clients for that controller platform, showing the detected SNR values for up to 16 candidate APs per client. This table is periodically updated as APs send client probe reports to the controller. This parameter defines the amount of time that the controller should retain client match data from each client probe report. Different controller types support varying numbers of clients. 7005: 1024 client 7010: 2048 clients 7030: 4096 clients 7240: 32000 clients 7220: 24000 clients 7210: 16000 clients 0- 65535 seconds 120 seconds |
|
cm-steer-backoff |
Client Match will attempt one IOS steer at the configured backoff time interval. |
|
cm-steer-timeout |
When a client is steered from one AP to a more desirable AP, the steer timeout feature helps facilitate the move by defining the amount of time that any APs to which the client should NOT associate will not respond to the AP. 0-255 |
|
cm-sticky-check-interval <secs> |
Frequency at which the AP checks for client's received SNR values. If the SNR value drops below the threshold defined by the 0-255 3 seconds |
|
cm-sticky-min-signal <-dB> |
A client triggered to move to a different AP may consider an AP radio a better match if the client detects that the signal from the candidate AP radio is at or higher than the minimum signal level defined by this parameterand the candidate radio has a higher signal strength than the radio to which the client is currently associated. (The required improvement in signal strength can be defined using the command.) 0-255 65 |
|
cm-sticky-snr <dB> |
If the client's received signal strength indicator (RSSI) is above this signal-to-noise ratio (SNR) threshold, that client will be allowed to stay associated to its current AP. If the client's received signal strength is below this threshold, it may be moved to a different AP. 0-255 dB |
|
cm-sticky-snr-delta |
A client triggered to move to a different AP may consider an AP radio a better match if the client detects that the signal from the AP radio is stronger than its current radio by the dB level defined by the cm-sticky-snr-thresh parameter, and the candidate radio also has a minimum signal level defined by the cm-sticky-min-signal parameter. 0-100 dB 10 |
|
cm-unst-ageout-interval days <days> |
The client entries in an unsteerable client list remain in effect for the interval defined by this parameter before they age out. 2 days |
|
cm-unst-ageout |
When client match and the client match unsteerable client ageout feature are enabled, the controller periodically sends APs that are not a desired AP match for a client in a list of unsteerable clients. These lists contain a list of MAC addresses for up to 128 clients that should not be steered to that AP. The following controller types support a aggregate maximum of unsteerable clients for all APs associated to that controller. 7005: 256 unsteerable clients 7010: 512 unsteerable clients 7030: 1024 unsteerable clients 7240: 8000 unsteerable clients 7220: 6000 unsteerable clients 7210: 4000 unsteerable clients |
|
default-6ghz |
Configures the ARM default-6 GHz profile. For more information, see rf arm-profile default-6ghz. |
|
dynamic-bw |
Issue the disabled |
|
dynamic-bw-beacon-failed-thresh |
The ARM dynamic bandwidth switch feature may trigger a change in the radio channel bandwidth if the number of failed beacons exceeds this value during the observation window. 1-500 30 |
|
dynamic-bw-cca-ibss-thresh |
The ARM dynamic bandwidth switch feature may trigger a change in the radio channel bandwidth if the clear channel asignment IBSS percentage drops below this value during the observation window. 1-100 10 |
|
dynamic-bw-cca-intf-thresh |
The ARM dynamic bandwidth switch feature may trigger a change in the radio channel bandwidth if the clear channel assignment interference percentage exceeds this value during the observation window. 1-100 30 |
|
dynamic-bw-clear-time |
The ARM dynamic bandwidth switch feature returns the AP radio to 80MHz channel after this clear time period if there is no high volume of traffic. 1-300 seconds 30 |
|
dynamic-bw-wait-time |
Minimum time in seconds dynamic bandwidth switch indicators have to be true to trigger a 80MHz to 40MHz bandwidth change. 1-300 seconds 30 |
|
error-rate-threshold |
The percentage of errors in the channel that triggers a channel change. Recommended value is 50%. A value of 0% disables this feature. 0-100 default-a: 70%, default-g: 70% |
|
error-rate-wait-time |
Time, in seconds, that the error rate has to be at least the error rate threshold to trigger a channel change. Recommended values are 1-100. 1-2,147,483,647 default-a: 90 seconds, default-g: 90 seconds |
|
free-channel-index |
The difference in the interference index between the new channel and current channel must exceed this value for the AP to move to a new channel. The higher this value, the lower the chance an AP will move to the new channel. 0-100 default-a: 40, default-g: 25 |
|
high-noise-backoff-time |
The duration, in minutes, for blacklisting 0-3600 720 minutes (12 hours) |
|
ideal-coverage-index |
The coverage that the AP should try to achieve on its channel. The denser the AP deployment, the lower this value should be. Recommended value is 10. 2-20 default-a: 6, default-g: 6 |
|
load-aware-scan-threshold |
Load aware ARM preserves network resources during periods of high traffic by temporarily halting ARM scanning if the load for the AP gets too high. The Load Aware Scan Threshold is the traffic throughput level an AP must reach before it stops scanning. The supported range for this setting is 0-20000000 bytes/second. (Specify 0 to disable this feature.) 1250000 bytes/second |
|
max-tx-power |
Maximum effective isotropic radiated power (EIRP) from 3 to 33 dBm in 3 dBm increments. You may also specify a special value of 127 dBm for regulatory maximum to disable power adjustments for environments such as outdoor mesh links. This value takes into account both radio transmit power and antenna gain. Higher power level settings may be constrained by local regulatory requirements and AP capabilities. 3, 6, 9, 12, 15, 18, 21, 24, 27, 30, 33, 127 default-a: 18 dBm, default-g: 9 dBm |
|
min-scan-time |
Minimum number of times a channel must be scanned before it is considered for assignment. The supported range for this setting is 0-2,147,483,647 scans. Best practices are to configure Minimum Scan Time between 1-20 scans. Recommended values are 1-20. 1-2,147,483,647 8 scans |
|
min-tx-power |
Minimum effective isotropic radiated power (EIRP) from 3 to 33 dBm in 3 dBm increments. You may also specify a special value of 127 dBm for regulatory minimum. This value takes into account both radio transmit power and antenna gain. Higher power level settings may be constrained by local regulatory requirements and AP capabilities. 3, 6, 9, 12, 15, 18, 21, 24, 27, 30, 33, 127 default-a: 12 dBm, default-g: 6 dBm |
|
mode-aware |
If enabled, ARM will turn APs into Air Monitors (AMs) if it detects higher coverage levels than necessary. This helps avoid higher levels of interference on the WLAN. Although this setting is disabled by default, you may want to enable this feature if your APs are deployed in close proximity (e.g. less than 60 feet apart). disabled |
|
multi-band-scan |
When enabled, single-radio APs try to scan across bands for rogue AP detection. enabled |
|
no |
Negates any configured parameter. |
|
ota-updates |
The option allows an AP to get information about its RF environment from its neighbors, even the AP cannot scan. If this feature is enabled, when an AP on the network scans a foreign (non-home) channel, it sends other APs an Over-the-Air (OTA) update in an 802.11 management frame that contains information about the scanning AP's home channel, the current transmission EIRP value of its home channel, and one-hop neighbors seen by that AP. enabled |
|
ps-aware-scan |
When enabled, the AP will not scan if Power Save is active. disabled |
|
radar-backoff-time |
The duration, in minutes, for blacklisting 0-3600 720 minutes (12 hours) |
|
rogue-ap-aware |
When enabled, the AP will try to contain off-channel rogue APs. disabled |
|
scan-interval |
If scanning is enabled, the scan interval defines how often the AP will leave its current channel to scan other channels in the band. Off-channel scanning can impact client performance. Typically, the shorter the scan interval, the higher the impact on performance. If you are deploying a large number of new APs on the network, you may want to lower the Scan Interval to help those APs find their optimal settings more quickly. Raise the Scan Interval back to its default setting after the APs are functioning as desired. Recommended values are 0-30 seconds. 0-2,147,483, 647 seconds 10 seconds |
|
scan-mode |
Select the scan mode for the AP: all-reg-domain: The AP scans channels within all regulatory domains. This is the default setting. reg-domain:Limit the AP scans to just the regulatory domain for that AP. all-reg-domain |
|
scanning |
The Scanning check box enables or disables AP scanning across multiple channels. Disabling this option also disables the following scanning features: Multi Band Scan Rogue AP Aware Voip Aware Scan Power Save Scan Do not disable Scanning unless you want to disable ARM and manually configure AP channel and transmission power. enabled |
|
video-aware-scan |
As long as there is at least one video frame every 100 mSec the AP will reject an ARM scanning request. Note that for each radio interface, video frames must be defined in one of two ways: Classify the frame as video traffic via a session ACL. Enable WMM on the WLAN’s SSID profile and define a specific DSCP value as a video stream. Next, create a session ACL to tag the video traffic with the that DSCP value. enabled |
|
voip-aware-scan |
HPE Aruba Networking’s VoIP Intelligent Call Handling (ICH) prevents any single AP from becoming congested with voice calls. When you enable ICH, you should also enable disabled |
|
voip-aware-scan-timer |
When enabled, the AP will not scan if the scan request falls within the scan timer of the last voice frame. Range is 50 ms—1000 ms. Default: 50 ms |
Default Profiles
AOS includes two default ARM profiles, for 5 Ghz radios, and for 2.4 GHz radios.
Channel Quality
Hybrid APs and Spectrum Monitors determine channel quality by measuring channel noise, non-Wi-Fi (interferer) utilization and duty-cycles, and certain types of Wi-Fi retries. Regular APs using ARM derive channel quality values by measuring the noise floor for that channel.
Client Match
The ARM client match feature continually monitors a client's RF neighborhood to provide ongoing client bandsteering and load balancing, and enhanced AP reassignment for roaming mobile clients. This feature is recommended over the legacy bandsteering and spectrum load balancing features, which, unlike client match, do not trigger AP changes for clients already associated to an AP.
Legacy 802.11a/b/g devices do not support ClientMatch. When client match is enabled on 802.11n-capable devices, ClientMatch overrides any settings configured for the legacy bandsteering, station handoff assist or load balancing features. 802.11ac-capable devices do not support the legacy bandsteering, station hand off or load balancing settings, so these APs must be managed on using client match.
When this feature is enabled on an AP, that AP is responsible for measuring the RF health of its associated clients. The AP receives and collects information about clients in its neighborhood, and periodically sends this information to the controller. The controller aggregates and maintains a database of information about AP transmit power elvels, client transmit power levels and AP RSSI levels as seen by clients. The controller shares this database with the APs (for their associated clients) and the APs use the information to compute the client-based RF neighborhood and determine which APs should be considered candidate APs for each client. When the controller receives a client steer request from an AP, the controller identifies the optimal AP candidate and manages the client’s relocation to the desired radio. This is an improvement from previous releases, where ARM was managed exclusively by APs, the without the larger perspective of the client's RF neighborhood.
The following client/AP mismatch conditions are managed by ClientMatch:
: Client match balances clients across APs on different channels, based upon the client load on the APs and the SNR levels the client detects from an underutilized AP. If an AP radio can support additional clients, the AP will participate in client match load balancing and clients can be directed to that AP radio, subject to predefined SNR thresholds.
: ClientMatch also helps mobile clients that tend to stay associated to an AP despite low signal levels. APs using client match continually monitor the client's RSSI as it roams between APs, and move the client to an AP when a better radio match can be found. This prevents mobile clients from remaining associated to an APs with less than ideal RSSI, which can cause poor connectivity and reduce performance for other clients associated with that AP.
: APs using ClientMatch monitor the RSSI for clients that advertise a dual-band capability. If a client is currently associated to a 2.4 GHz radio and the AP detects that the client has a good RSSI from the 5 Ghz radio, the controller will attempt to steer the client to the 5 Ghz radio, as long as the 5 Ghz RSSI is not significantly worse than the 2.4 GHz RSSI, and the AP retains a suitable distribution of clients on each of its radios.
: 802.11ax clients are best compatible with 802.11ax capable radios, resulting in better throughput and spectral efficiency. When an 802.11ax client is associated with a lower radio, ClientMatch pushes the client to the best compatible 802.11ax radio for advanced capabilities. Though STA is in good health, and is 802.11ax capable, it still sometimes connects to lower radios. ClientMatch finds a potential 802.11ax radio on the same band and the client moves to the new 802.11ax radio.
80 MHz Dynamic Bandwidth Switch
If an AP radio uses an 80 MHz channel, the radio only sends out frames out when the entire 80 MHz channel is clear, even if the AP is sending only a 20 MHz management frame or 40MHz data frame. As a result, throughput on the selected 80 MHz channel can be negatively impacted if interference occurs on both 20 MHz channels of the secondary 40MHz channel.
The ARM dynamic bandwidth switch feature allows ARM to detect the 20MHz interferers in this situation, and potentially move the AP radio to another 80MHz channel, or change the AP transmissions to 40MHz, and use the primary 40MHz channel instead.
When this feature is enabled, ARM starts a dynamic bandwidth switch observation window if load-aware scan rejects increase, and the clear channel assignment IBSS percentage (the percentage of channel traffic sent from that AP radio) drops below the value defined by the dynamic-bw-cca-ibss-thresh parameter.
If an observation window opens, and the clear channel assignment interference threshold exceeds the value defined by the dynamic-bw-cca-
intf-thresh parameter, and the number of failed beacons from the radio exceeds the threshold defined by the dynamic-bw-beacon-
failed-thresh parameter during that observation period, ARM will move the AP to another available 80MHz channel with the minimum interference index. If no other 80MHz channel is available, ARM downgrades the radio bandwidth to 40MHz.
ARM Scanning
The default ARM scanning interval is determined by the scan-interval parameter in the ARM profile. If the AP does not have any associated clients (or if most of its clients are inactive) ARM will dynamically readjust this default scan interval, allowing the AP obtain better information about its RF neighborhood by scanning non-home channels more frequently. If an AP attempts to scan a non-home channel but is unsuccessful, the AP will make additional attempts to rescan that channel before skipping it and continuing on to other channels.
Using Adaptive Radio Management (ARM) in a Mesh Network
When a mesh portal operates on a mesh network, the mesh portal determines the channel used by the mesh feature. When a mesh point locates an upstream mesh portal, it will scan the regulatory domain channels list to determine the channel assigned to it, for a mesh point always uses the channel selected by its mesh portal. However, if a mesh portal uses an ARM profile enabled with a single-band or multi-band channel/power assignment and the scanning feature, the mesh portal will scan the configured channel lists and the ARM algorithm will assign the proper channel to the mesh portal.
If you are using ARM in your network, is important to note that mesh points, unlike mesh portals, do not scan channels. This means that once a mesh point has selected a mesh portal or an upstream mesh point, it will tune to this channel, form the link, and will not scan again unless the mesh link gets broken. This provides good mesh link stability, but may adversely affect system throughput in networks with mesh portals and mesh points. When ARM assigns optimal channels to mesh portals, those portals use different channels, and once the mesh network has formed and all the mesh points have selected a portal (or upstream mesh point), those mesh points will not be able to detect other portals on other channels that could offer better throughput. This type of suboptimal mesh network may form if, for example, two or three mesh points select the same mesh portal after booting, form the mesh network, and leave a nearby mesh portal without any mesh points. Again, this will not affect mesh functionality, but may affect total system throughput.
Example
The following command configures VoIP-aware scanning for the arm-profile named “voice-arm:”
(host) [mynode] (config) #rf arm-profile voice-arm
voip-aware-scan
The following command disable deauth-based steers:
The following command enables deauth-based steers:
Command History
|
Release |
Modification |
|
AOS 8.9.0.0 |
|
|
AOS 8.8.0.0 |
|
|
AOS 8.7.0.0 |
The following parameters were added:
|
|
AOS 8.5.0.0 |
The |
|
AOS 8.2.0.0 |
The following parameters were added:
|
|
AOS 8.0.0.0 |
Command introduced. |
Command Information
|
Platforms |
License |
Command Mode |
|
All platforms |
Base operating system. |
Config mode on Mobility Conductor. |