In Part 1 (Something Old) we looked at basic changes to the physical layer provided by wave 1 of 801.11ax, how these changes can affect performance, and how OFDMA enables the optimal use of the 6GHz spectrum. In this second article, we’ll explore “something new:” the challenges of discovery in 6GHz, new methods used for solving this, and how these new methods open 6GHz for many different use cases.
Is There Anybody Out There?
In previous generations, Wi-Fi clients would scan channels and send unsolicited probe requests to discover access points (APs). Scanning channels can be a timely process as beacons are only broadcast every 102400us so the client must dwell long enough to detect the beacon. At 6GHz this is 102400us x 59 channels (there are 59 20MHz channels in the new 6GHz spectrum) which is over 6 seconds. For the client, this loss in time represents a disruption in communication. Creating intolerable latency in voice and lost opportunity to hundreds of megabytes of data every time the client decides to scan. Furthermore, the previous process would be to send unsolicited probe requests (wildcard requests) to see how APs would respond. Now, remember, this is all a contention-based medium, so these probe requests and responses on every channel for every client create a significant amount of interference and at the very least, inefficient use of the spectrum.
Over the years the IEEE has introduced measures to address these roaming challenges. 802.11k was introduced to provide clients with a list of neighboring APs, 802.11v was introduced to provide a recommended AP candidate, and 802.11r was introduced to reduce the roaming time for 802.1x clients. Not all clients and infrastructure support these measures so while they helped, they did not eliminate the need for clients to send unsolicited probes.
While these IEEE updates are still available for 6GHz, the strategy for AP discovery fundamentally changes. To start with, unsolicited probe requests are no longer allowed (with one limited exception we will discuss shortly).
Three New Methods to Improve AP Discovery
Since we have already established scanning channels at 6GHz is not allowed, there are three new methods introduced in Wi-Fi 6E for finding AP candidates.
The primary method (and the one that clients typically respond to best) is called Reduced Neighbor Report (RNR). Since most, if not all, clients will have legacy band capability, there is an Information Element (IE) embedded in the legacy band beacons that list the 6GHz SSID(s) that are available on the serving AP. The client first scans the 5GHz or 2.4GHz channels and looks for this RNR element. The RNR report contains information about the 6GHz channel, SSID, BSSID, a bit of information on the AP, and the allowed power levels (Power Spectral Density). This effectively makes the 2.4GHz and 5GHz channels a control channel for the 6GHz. Clients can then send a directed probe request to those channels that are learned in the RNR to determine which 6GHz AP to join. It is important to note there can be multiple 6GHz SSIDs included in the RNR and they do not have to match the legacy SSIDs.
The information contained in an RNR is very similar to the information provided in the previously introduced 802.11v action frame. The RNR below is from a 5GHz beacon and is advertising two SSIDs on the 6GHz channel number 5. The legacy 802.11v action report below shows similar information to the RNR but the fundamental difference is twofold:
◉ This is an action frame not part of the beacon like the RNR. It is a request-response type transaction. An RNR is broadcast in the legacy band beacons.
◉ The information in the 802.11v action frame contains information about other APs on the same frequency band. The RNR only lists SSIDs broadcasted from the 6GHz band (different frequency band) as this same AP.
Figure 1: RNR on 5GHz beacon
Figure 2: 802.11v Action Frame
What if the AP is only broadcasting 6GHz? This is an unlikely condition, but nonetheless a potential one. First, scanning can be reduced by limiting the number of channels to be scanned. This is called Preferred Scanning Channels (PSC). The PSCs are the primary channels (20MHz subchannel) of the 80MHz channels. This works well since 80MHz will often be the preferred bandwidth to operate for reasons previously discussed in part 1 of this blog series. If however, lower bandwidth channels are used without RNR or additional support from the methods below, it would be very easy for a client to miss this channel which should be a consideration when using PSC with narrower band channels.
Figure 3: Preferred Scanning Channels (red)
There are two mutually exclusive options to further enhance the AP discovery in which the AP will broadcast messages an additional 4 times between the beacons or about every 20ms (configurable from 5ms to 25ms). The first method is called Fast Initial Link Setup (FILS) and is based on a previous standard of 802.11ai. This is a very lightweight message (somewhere around 100 bytes as compared to a beacon which is 500+ bytes). The second method is called “Broadcast Probe Response” or “Unsolicited Probe Response” (UPR). Like FILS, this advertisement will be broadcast at a higher rate than the beacon. However, the UPR broadcasts everything in the probe response so while it supplies the client with more information, it is a bit heavier in the amount of data transmitted repeatedly.
Teamwork Makes the Discovery Dream Work
So how do these four methods work together? First, if there are legacy band SSIDs transmitted on the AP the expectation is that the RNR will do the work of discovering the 6GHz channel, and no other method is required. In the case where only 6GHz is broadcast from the AP the most likely scenario would be the use of PSC with either FILS or UPR. Notice UPR and FILS are exclusive options, you can only use one or the other. Early testing of client devices has seen some issues with 6GHz standalone APs not being discovered with only PSC and it is needed to have FILS (or UPR) enabled to assist a client in discovering the AP. This may change over time but for the early implementations, deploying 6GHz with only 80MHz channels and PSC enabled is a good option. This allows the primary channel to match the PSC channels. In addition, enabling FILS can provide further assistance for discovery with minimal impact on performance.
Source: cisco.com
Posts
0 comments:
Post a Comment