RDK Resources
[*RDK Preferred*]
Code Management Facility
RDK Forums
[RDK Conferences]
RDK Support
Archives
Papers & Presentations Archive
...
Table of Contents | ||
---|---|---|
|
Info |
---|
This Page is under Development |
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. Band Steering solution does upgrade steering ( from 2.4 GHz to 5 GHz) and downgrade steering (5 GHz to 2.4 GHz) which allows optimal utilization of both bands. The Steering of the Wireless clients are based on the following parameter,
...
The purpose of Band Steering feature is to maintain Wireless Clients in band best suited to them. For instance, a 5GHz capable client would be maintained in faster & wider-channeled 5GHz band but if the Received Signal Strength is lesser than the threshold value, the Client is moved to a wider-range 2.4GHz band.
The most basic prerequisite of Band Steering is both the 2.4GHz and the 5GHz frequency band must have the same SSID and passphrase. The wireless Clients will be steered to a better band only if SSID and password are same. So before performing Band Steering operations, same SSID, Authentication Mechanism and passphrase are set to both 2.4GHz and 5GHz band. The enable & disabling of the Band Steering feature is done by dmcli command. Changes are done in WiFiHal and meta-cmf-raspberypi raspberrypi layer.
Modified Wifi Hal APIs related to Band Steering are as follows,
On Enabling, checks if the Device is dual band capable and makes sure that the SSID, passphrase and Authentication mechanism is same in both 2.4GHz and 5GHz. Sets syscfg value for "band_steering_enable" as "1"
When disabled, resets the configured SSIDs, passphrase and Authentication Mechanism in 5GHz band. Also sets syscfg value for "band_steering_enable" as "0".
Returns the Band Steering status of the device, this is done by using the syscfg get "band_steering_enable" variable.
Returns true if the device can transmit SSID in both 2.4GHz and 5GHz band, else return false. The return type is the device capability to support Band Steering Feature.
A compilation flag is defined to include WiFi Band Steering related calls in the CcspWifiAgent component.
System default is added with name "band_steering_enable" to track band steering status, whether enabled/disbaled.
Pre-association Band steering:
a. When RSSI of client probe request received by AP/Gateway in 2.4GHz band is more than the threshold, then AP blocks the 2.4GHz band for the client and informs client to probe request to 5GHz.
b. If the client device continues to probe request to 2.4GHz band, AP blocks the response in 2.4GHz until client device is ready to connect to 5GHz.
c. Sometimes client devices continues to probe request to 2.4GHz though AP blocks its response, in this case, after blocking a considerable number of times during a time period, AP enters backs off period and allows client to connect to 2.4GHz. For this period, AP does not try to steer the client to 5GHz again.
Post-association Band Steering:
a. Client has associated with a non-preferred band, RSSI is checked if it is above threshold. If it is above threshold, client is disassociated from the band and Steered to preferred band using Pre-association procedure.
RSSI is the Received Signal Strength of the probe request sent by the Client to the APs for connection establishment. RSSI will always be a negative value when converted to dbm.
As we already know, 5GHz Band has bigger channel Bandwidth and more number of channel occupancy when compared to 2.4GHz band. 5GHz provides good network connection to all the clients connected for a shorter distance, unlike 2.4GHz which is suitable for longer range networks.
RSSI which determines the signal strength of the client towards AP, can have a threshold value which will help in directing/deciding as to which band the client needs to be connected to. Signal strength indirectly indicates the distance of the client from AP. It is understood that as RSSI decreases, the distance of client device from the AP increases.
However, there are certain clients which are not capable of connecting to 5GHz band, as they do not support 5GHz.
For this, the events generated when the clients probe requests to gateway have to be captured. If the clients probe request to 2.4GHz band always, they are considered to be capable of connecting only to 2.4GHz. If the clients are found to be probing requests on both 2.4GHz and 5GHz band, then they are capable of connecting to 5GHz network.
Command to obtain Signal Level value for multiple client:
a. save the Mac addresses
iw dev <interface name> station dump | grep Station | cut -d ' ' -f2 | sort | uniq
b. check the signal level for a particular Mac address
iw dev <interface name> station dump | sed -n -e '/Station <Mac address>/,/Station/ p' | grep signal |cut -d ' ' -f3 | awk '{print $1}'
API to obtain the frequency client is associated:
wifi_getRadioSupportedFrequencyBands
RSSI threshold:
RSSI threshold is set to -100 by default, based on the Real time Box behavior.
RSSI range:
-100 to 0 (To Be confirmed)
Capability of associated clients:
iw event -f
cat /tmp/event_count.txt | tr -d ' ' | grep <interface_name>:newstation<mac addr> | wc -l
The above command will check if client has probed any request to gateway in 5GHz band. If the value is NULL, it will remain connected in 2.4GHz.
draw.io Diagram | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Band Utilization is the number of channel bands occupied by clients. The Utilization threshold is set to a default value. When the Number of Clients connected to 5GHz band are more than the threshold value, the clients have to be steered to 2.4GHz band. This is done to improve the network quality to the connected clients.
Assuming, all wireless devices that support both 2.4GHz and 5GHz band will be automatically directed, to be connected to 5GHz initially. Here, if the number of clients connected to 5GHz is more than the set threshold value, i.e., 10, then network quality may degrade for the connected clients because many clients will be sharing the available band. For this, once the number of connected clients crosses threshold, few of the clients have to be steered to 2.4GHz.
Depends on:
a. Density/Number of Clients in the Band
b. Assuming client is in 2.4 GHz, Downlink Phy rate > = Phy Rate threshold , then switch to 5GHz
Assuming client is in 5GHz, Downlink Phy rate < Phy Rate threshold, then switch to 2.4GHz
c. Uplink signal
Combining:
Before the clients are steered to 2.4GHz from 5GHz band, there has to be a check to decide which clients can be steered to a preferable band. If the clients whose signal strength is low, i.e., they are far from AP are retained in 5GHz and the clients with high signal strength are directed to 2.4GHz, the clients may lose connectivity.
Hence, the RSSI threshold and Utilization threshold implementations have to be combined to achieve a better Band Steering.
a. Density/Number of Clients in the Band
iw dev <interface-name> station dump | grep Station | cut -d ' ' -f2 > /tmp/wifi_5Gstations.txt
iw dev <interface-name> station dump | grep Station | cut -d ' ' -f2 > /tmp/wifi_2-4Gstations.txt
cat /tmp/wifi_5Gstations.txt | wc -l
cat /tmp/wifi_2-4Gstations.txt | wc -l
b. Downlink Phy rate
Maximum speed of data in downlink
Need the information from driver
c. Uplink signal
Signal to Noise ratio in uplink
Need the information from driver
draw.io Diagram | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Layout
draw.io Diagram | |||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Frequency Band Client is connected to | Client capability for 5GHz | Expected behavior | Current behavior | |
RSSI signal < RSSI Threshold | RSSI signal >= RSSI Threshold | |||
5GHz | Y | Switch to 2.4GHz | Remain in 5GHz | Pass |
2.4GHz | Y | Remain in 2.4GHz | Switch to 5GHz | Pass |
2.4GHz | N | Remain in 2.4GHz | Remain in 2.4GHz | Pass |
Please refer to User Manual for Band Steering for further details.
S.no | Module | dmcli command | Description |
---|---|---|---|
1 | WiFi - TR181-WiFi-USGv2.XML | Device.WiFi.X_RDKCENTRAL-COM_BandSteering.Enable | used to enabled/disbaled Band Steering |
2 | WiFi - TR181-WiFi-USGv2.XML | Device.WiFi.X_RDKCENTRAL-COM_BandSteering.APGroup | sets/returns AP Group name |
3 | WiFi - TR181-WiFi-USGv2.XML | Device.WiFi.X_RDKCENTRAL-COM_BandSteering.Capability | returns Band Steering Device level capability |
4 | WiFi - TR181-WiFi-USGv2.XML | Device.WiFi.X_RDKCENTRAL-COM_BandSteering.History | History of Clients Steered across bands |
5 | WiFi - TR181-WiFi-USGv2.XML | Device.WiFi.X_RDKCENTRAL-COM_BandSteering.<radio-index>.UtilizationThreshold | Bandwidth Utilization threshold for 2.4/5 GHz |
6 | WiFi - TR181-WiFi-USGv2.XML | Device.WiFi.X_RDKCENTRAL-COM_BandSteering.<radio-index>.RSSIThreshold | Signal Strength threshold for 2.4/5 GHz |
7 | WiFi - TR181-WiFi-USGv2.XML | Device.WiFi.X_RDKCENTRAL-COM_BandSteering.<radio-index>.PhyRateThreshold | Physical Transmit rate thresholdrate for a Client in a band |
8 | WiFi - TR181-WiFi-USGv2.XML | Device.WiFi.X_RDKCENTRAL-COM_BandSteering.<radio-index>.OverloadInactiveTime | Threshold inactive time of a client during band overload condiiton |
9 | WiFi - TR181-WiFi-USGv2.XML | Device.WiFi.X_RDKCENTRAL-COM_BandSteering.<radio-index>.IdleInactiveTime | Threshold inactive time of a client during Idle condiiton |
...