Page History

Introduction

Briefly describe in general terms the system/application and the purpose for which it is intended, written in non-technical terminology. Consider including a high-level architecture diagram for the system. The description should include, but is not limited to, the following:

• Key features or major functions/use cases performed by the system/application
• Architecture of the system in non-technical terms (e.g., client server, Web-based, etc.)
• System environment or special conditions

Environment Setup

• Set-up Considerations

<Briefly describe and graphically depict as appropriate the equipment, communications, and network configuration of the system in a way that a non-technical user can understand>

• User Access Considerations

<Briefly describe and graphically depict as appropriate the equipment, communications, and network configuration of the system in a way that a non-technical user can understand>

• Accessing the System

<Provide detailed information and describe the procedures necessary to access the system. If applicable, include how to get a user ID and log on to the system, as well as the actions a user must take to change and/or reset a password.>

• System Work Flow

<Describe how system flow is happening mentioning checkpoints which can be verified during flow to ensure system is working as expected>

• Exiting the System

<Mention the validation artifacts that are essential to ensure the functionality is working as expected. Also any limitation while closing the validation process>

Executing System

Describe the specific system function or feature in detail and depict graphically by including screen prints and descriptive narrative as appropriate. Ensure each screen print is captioned and has an associated tag providing appropriate alternative text

Follow the above for sub feature / use cases

Troubleshooting

• Error Messages

<Identify the error messages that a user may receive and the likely cause(s) and/or possible corrective actions for the error>

• Special Considerations

Introduction

Band Steering is a solution ensures that clients are connected to the best radio. Dual Band supported Gateway can transmit SSIDs in both 2.4GHz and 5GHz frequency band. Enabling and disabling of Band Steering can be done through dmcli command line utility.

Environment Setup

Band Steering feature requires dual band capability i.e device should be able to broadcast SSID in both 2.4GHz and 5GHz frequency. Also this feature will be of use and applicable only to 5GHz capable device. Older 2.4 GHz-only capable devices cannot benefit from this feature. Still older 2.4GHz-only clients can connect and operate on 2.4GHz frequency only.

Executing System

Band Steering by default will be disabled. The user can enabled it using dmcli command as shown below.

Enabling Band Steering Example:

Image Added

After enabling of Band Steering, the SSID broadcasted by the two interfaces are same. A 5GHz capable client will normally connect to a 5GHz client and older 2.4GHz client will connect to 2.4GHz frequency band.

Both Bands having same SSID:

Image Added

Disabling of Band Steering will reset all previously made configuration on the 5GHz band. Band Steering can be disabled by the below command.

Disabling Band Steering Example:

Image Added

Setting the Threshold value Example:

Image AddedImage Added

Client connected to 5GHz initially Example:

Image Added

Client after switching to 2.4GHz when RSSI signal goes above -25dBm Example:

Image Added

Client association and disassociation event capture:

Image Added

Troubleshooting

• Error Messages

If enabling of the Band Steering fails, then both the band will have different SSIDs, still Wifi would operate and wireless clients can connect to them.

• Special Considerations

Device should be dual band capable to support Band Steering functionality.<If applicable, describe any special circumstances, actions, exceptions, etc., that should be considered for troubleshooting.>

Support