Wi-Fi Agile Multiband

Technical Specification
Version 1.5

WI-FI ALLIANCE PROPRIETARY – SUBJECT TO CHANGE WITHOUT NOTICE

This document may be used with the permission of Wi-Fi Alliance under the terms set forth herein.
By your use of the document, you are agreeing to these terms. Unless this document is clearly designated
as an approved specification, this document is a work in process and is not an approved Wi-Fi Alliance
specification. This document is subject to revision or removal at any time without notice. Information
contained in this document may be used at your sole risk. Wi-Fi Alliance assumes no responsibility for
errors or omissions in this document. This copyright permission does not constitute an endorsement of the
products or services. Wi-Fi Alliance trademarks and certification marks may not be used unless specifically
allowed by Wi-Fi Alliance.
Wi-Fi Alliance has not conducted an independent intellectual property rights ("IPR") review of this document
and the information contained herein, and makes no representations or warranties regarding IPR, including
without limitation patents, copyrights or trade secret rights. This document may contain inventions for which
you must obtain licenses from third parties before making, using or selling the inventions.
Wi-Fi Alliance owns the copyright in this document and reserves all rights therein. A user of this document
may duplicate and distribute copies of the document in connection with the authorized uses described
herein, provided any duplication in whole or in part includes the copyright notice and the disclaimer text set
forth herein. Unless prior written permission has been received from Wi-Fi Alliance, any other use of this
document and all other duplication and distribution of this document are prohibited. Unauthorized use,
duplication, or distribution is an infringement of Wi-Fi Alliance’s copyright.
NO REPRESENTATIONS OR WARRANTIES (WHETHER EXPRESS OR IMPLIED) ARE MADE BY WI-
FI ALLIANCE AND WI-FI ALLIANCE IS NOT LIABLE FOR AND HEREBY DISCLAIMS ANY DIRECT,
INDIRECT, PUNITIVE, SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR EXEMPLARY DAMAGES
ARISING OUT OF OR IN CONNECTION WITH THE USE OF THIS DOCUMENT AND ANY
INFORMATION CONTAINED IN THIS DOCUMENT.

© 2020 Wi-Fi Alliance. All Rights Reserved.

Used with the permission of Wi-Fi Alliance under the terms as stated in this document.
Wi-Fi Agile Multiband Technical Specification v1.5

Document revision history

Version Date YYYY-MM-DD Remarks

1.0 2017-08-25 First public release.

1.3 2019-10-02 Added information pertaining to Beacon Report Enhancement ECN

1. Addresses Beacon Report fragmentation behavior
2. Support for "Last Beacon Report Indication" subelement in the Beacon Request
3. Support for "Last Beacon Report Indication" and "Reported Frame Body Fragment ID"
subelement in the Beacon Report
1.4 2020-01 Wi-Fi Agile Multiband device behavior with and without PMF is delineated in Section 2.3.2.

1.5 2020-08-03 Editorial cleanup, clarifications, and name simplification

Added clarification in 2.3.2 that OWE enabled is equivalent to RSN enabled, in terms of a STA not
trusting MBO-OCE element if PMF is not enabled.
Corrected "Last Beacon Report Indication" in 1.3 revision history

© 2020 Wi-Fi Alliance. All Rights Reserved.

Used with the permission of Wi-Fi Alliance under the terms as stated in this document.
Page 2 of 32
Wi-Fi Agile Multiband Technical Specification v1.5

Table of contents

1 INTRODUCTION .......................................................................................................................................................... 6
1.1 Scope ............................................................................................................................................................ 6
1.2 References .................................................................................................................................................... 6
1.3 Definitions and acronyms .............................................................................................................................. 6
1.3.1 Shall/should/may/might word usage ................................................................................................ 6
1.3.2 Conventions ..................................................................................................................................... 6
1.3.3 Definitions ........................................................................................................................................ 7
1.3.4 Abbreviations and acronyms ............................................................................................................ 7
2 ARCHITECTURE AND REQUIREMENTS ................................................................................................................... 9
2.1 Components .................................................................................................................................................. 9
2.2 Topology ....................................................................................................................................................... 9
2.3 Requirements .............................................................................................................................................. 10
2.3.1 Baseline requirements ................................................................................................................... 10
2.3.2 Wi-Fi Agile Multiband specific requirements .................................................................................. 10
2.3.3 Required IEEE 802.11 capabilities ................................................................................................ 11
2.3.4 Required IEEE 802.11 functionality for Wi-Fi Agile Multiband APs and STAs .............................. 12
3 WI-FI AGILE MULTIBAND PROTOCOL .................................................................................................................... 14
3.1 Introduction ................................................................................................................................................. 14
3.2 Channel and Band Indication and Preference ............................................................................................ 14
3.3 Cellular data capability indication ................................................................................................................ 15
3.4 Beacon report .............................................................................................................................................. 15
3.5 BSS transition management ....................................................................................................................... 17
3.5.1 BSS Transition Information request ............................................................................................... 17
3.5.2 AP BSS Transition Solicitation ....................................................................................................... 18
3.6 Association Disallowed Indication ............................................................................................................... 20
3.7 Fast BSS Transition .................................................................................................................................... 20
3.8 MBO Capability Indication attribute ............................................................................................................. 20
4 INFORMATION ELEMENTS, ATTRIBUTES AND FRAME FORMATS..................................................................... 21
4.1 MBO-OCE Information Element .................................................................................................................. 21
4.2 MBO attributes ............................................................................................................................................ 21
4.2.1 MBO AP Capability Indication attribute .......................................................................................... 22
4.2.2 Non-preferred Channel Report attribute ........................................................................................ 22
4.2.3 Cellular Data Capabilities attribute ................................................................................................. 23
4.2.4 Association Disallowed attribute .................................................................................................... 24
4.2.5 Cellular Data Connection Preference attribute .............................................................................. 25
4.2.6 Transition Reason Code attribute .................................................................................................. 25
4.2.7 Transition Rejection Reason Code attribute .................................................................................. 26
4.2.8 Association Retry Delay attribute ................................................................................................... 27
4.3 MBO ANQP-elements ................................................................................................................................. 27
4.3.1 MBO Query List .............................................................................................................................. 28
4.3.2 Cellular Data Connection Preference Subtype .............................................................................. 28
4.3.3 Neighbor Report in ANQP .............................................................................................................. 28
4.4 WNM-Notification Request frame ............................................................................................................... 28
4.4.1 Non-preferred Channel Report subelement ................................................................................... 29
4.4.2 Cellular Data Capabilities subelement ........................................................................................... 29
APPENDIX A (INFORMATIVE) EXAMPLES OF NON-PREFERRED CHANNEL REPORT ATTRIBUTE....................... 31
A.1 Example 1 of Non-Preferred Channel Report attribute: .............................................................................. 31
A.2 Example 2 of Non-Preferred Channel Report attribute: .............................................................................. 31

© 2020 Wi-Fi Alliance. All Rights Reserved.

Used with the permission of Wi-Fi Alliance under the terms as stated in this document.
Page 3 of 32
Wi-Fi Agile Multiband Technical Specification v1.5

APPENDIX B (INFORMATIVE) EXAMPLE GAS QUERY USING ANQP QUERY LIST AND MBO QUERY LIST .......... 32

© 2020 Wi-Fi Alliance. All Rights Reserved.

Used with the permission of Wi-Fi Alliance under the terms as stated in this document.
Page 4 of 32
Wi-Fi Agile Multiband Technical Specification v1.5

List of tables
Table 1. Definitions ................................................................................................................................... 7
Table 2. Abbreviations and acronyms ....................................................................................................... 7
Table 3. MBO-OCE IE format ................................................................................................................. 21
Table 4. MBO attribute general format .................................................................................................... 21
Table 5. MBO attributes .......................................................................................................................... 21
Table 6. MBO AP Capability Indication attribute ..................................................................................... 22
Table 7. MBO AP Capability Indication field values ................................................................................ 22
Table 8. Non-preferred Channel Report attribute ................................................................................... 23
Table 9. Preference Field Values ............................................................................................................ 23
Table 10. Reason Code Field Values ....................................................................................................... 23
Table 11. Cellular Data Capabilities attribute ............................................................................................ 24
Table 12. Cellular Data Connectivity field ................................................................................................. 24
Table 13. Association Disallowed attribute ............................................................................................... 24
Table 14. Reason Code field values ......................................................................................................... 24
Table 15. Cellular Data Connection Preference attribute ......................................................................... 25
Table 16. Cellular Data Preference Field Values ...................................................................................... 25
Table 17. Transition Reason Code attribute ............................................................................................. 25
Table 18. Transition Reason Code field values ........................................................................................ 26
Table 19. Transition Rejection Reason Code attribute ............................................................................. 26
Table 20. Transition Rejection Reason Code field values ........................................................................ 27
Table 21. Association Retry Delay attribute .............................................................................................. 27
Table 22. MBO ANQP-elements ............................................................................................................... 27
Table 23. MBO ANQP-element subtype values ........................................................................................ 28
Table 24. Non-preferred Channel Report subelement .............................................................................. 29
Table 25. Cellular Data Capabilities subelement ...................................................................................... 30

List of figures
Figure 1. Wi-Fi Agile Multiband wireless infrastructure network ................................................................ 9
Figure 2. Wi-Fi Agile Multiband wireless infrastructure network with cellular data access network ........ 10
Figure 3. MBO Query List ANQP-element payload format ...................................................................... 28
Figure 4. WNM-Notification Request frame format .................................................................................. 29
Figure 5. GAS Initial Request frame (Action frame) ................................................................................. 32
Figure 6. Example Query Request field ................................................................................................... 32
Figure 7. Example Query Request field details ........................................................................................ 32

© 2020 Wi-Fi Alliance. All Rights Reserved.

Used with the permission of Wi-Fi Alliance under the terms as stated in this document.
Page 5 of 32
Wi-Fi Agile Multiband Technical Specification v1.5

1 Introduction
This document is the technical specification for Wi-Fi Agile Multiband. This specification defines the architecture,
protocols, and functionality for devices that support Wi-Fi Agile Multiband.

1.1 Scope
This specification describes IEEE 802.11 mechanisms used in the Wi-Fi Agile Multiband program and defines vendor
specific extensions to the IEEE 802.11 specification. These extensions facilitate efficient use of multiple frequency bands
available to Access Points and the Station devices that may associate with them.
This specification provides practical solutions for band steering, load balancing, and other related operational procedures.
The extensions defined in this specification are band independent and are expected to be usable across all available
unlicensed bands where Wi-Fi systems operate.
The scope of the feature requirements is limited to that defined in this specification.

1.2 References
Knowledge of the documents listed in this section is required for understanding this technical specification. If a reference
includes a date or a version identifier, only that specific version of the document is required. If the listing includes neither a
date nor a version identifier, then the latest version of the document is required. In the event of a conflict between this
specification and the following referenced documents, the contents of this specification take precedence.
[1] IEEE Computer Society, “IEEE Standard for Information Technology – Telecommunications and Information
Exchange Between Systems – Local and Metropolitan Area Networks – Specific requirements Part 11: Wireless LAN
Medium Access Control (MAC) and Physical Layer (PHY) Specifications,” (IEEE Std. 802.11-2016)

1.3 Definitions and acronyms

1.3.1 Shall/should/may/might word usage
The words shall, should, and may are used intentionally throughout this document to identify the requirements for the Wi-
Fi Agile Multiband program. The words can and might shall not be used to define requirements.
The word shall indicates a mandatory requirement. All mandatory requirements must be implemented to assure
interoperability with other Wi-Fi Agile Multiband products.
The word should denotes a recommended approach or action.
The word may indicates a permitted approach or action with no implied preference.
The words might and can indicate a possibility or suggestion and should be used sparingly.

1.3.2 Conventions
The ordering of bits and bytes in the fields within information elements, attributes and action frames shall follow the
conventions in Section 9.2.2 of IEEE Standard 802.11-2016 [1] unless otherwise stated.
The word ignored shall be used to describe bits, bytes, fields or parameters whose values are not verified by the recipient.
The word reserved shall be used to describe objects (bits, bytes, or fields or their assigned values) whose usage and
interpretation will be defined in the future by this specification or by other technical specifications/bulletins. A reserved
object shall be set to zero unless otherwise stated. The recipient of a reserved object shall ignore its value unless that
object becomes defined at a later date. The sender of an object defined by this technical specification shall not use a
reserved code value.

© 2020 Wi-Fi Alliance. All Rights Reserved.

Used with the permission of Wi-Fi Alliance under the terms as stated in this document.
Page 6 of 32
Wi-Fi Agile Multiband Technical Specification v1.5

1.3.3 Definitions
The definitions in Table 1 are applicable to this specification.
Table 1. Definitions

Term Definition

Candidate AP A Wi-Fi Agile Multiband AP to which the station is currently not associated

MBO attribute Attributes defined for the Wi-Fi Agile Multiband program

MBO ANQP-element ANQP-element defined for the Wi-Fi Agile Multiband program

MBO-OCE IE Information Element defined for the Wi-Fi Agile Multiband program

Wi-Fi Agile Multiband AP An AP that has Wi-Fi Agile Multiband features and functions enabled

Wi-Fi Agile Multiband Cellular Data Aware AP An AP that has Wi-Fi Agile Multiband features and functions enabled, and has
awareness of a cellular data network which enables the AP to indicate to a STA a
preference for the STA to switch to that cellular data network
Wi-Fi Agile Multiband multimode STA A station that is both Wi-Fi and cellular data capable and in addition has Wi-Fi Agile
Multiband features and functions enabled
Wi-Fi Agile Multiband STA A station that has Wi-Fi Agile Multiband features and functions enabled

Serving AP The AP to which an STA is associated

1.3.4 Abbreviations and acronyms

This section defines the acronyms used throughout this document. Some acronyms are commonly used in publications
and standards defining the operation of wireless local area networks, while others have been generated by Wi-Fi Alliance.
Table 2. Abbreviations and acronyms

Acronyms Definition

AAA Authentication, Authorization, and Accounting

AP Access Point

ANQP Access Network Query Protocol

BSS Basic Service Set

BSSID Basic Service Set Identifier

BTM BSS Transition Management

DS Distribution System

EPC Evolved Packet Core

ESS Extended Service Set

FT Fast BSS Transition

ID Identifier

IE Information Element

IEEE Institute of Electrical and Electronics Engineers

GHz Giga Hertz

LAN Local Area Network

MAC Medium Access Control

© 2020 Wi-Fi Alliance. All Rights Reserved.

Used with the permission of Wi-Fi Alliance under the terms as stated in this document.
Page 7 of 32
Wi-Fi Agile Multiband Technical Specification v1.5

Acronyms Definition

OTA Over the Air

OUI Organizationally Unique Identifier

PHY Physical Layer

PMF Protected Management Frames

QoS Quality of Service

RADIUS Remote Access Dial In User Service

RAT Radio Access Technology

R0KH Pairwise master key holder R0

R1KH Pairwise master key holder R1

RM Radio Measurements

SSID Service Set Identifier

STA Client Station

TBTT Target Beacon Transmission Time

TSF Timing Synchronization Function

WLAN Wireless Local Area Network

WNM Wireless Network Management

© 2020 Wi-Fi Alliance. All Rights Reserved.

Used with the permission of Wi-Fi Alliance under the terms as stated in this document.
Page 8 of 32
Wi-Fi Agile Multiband Technical Specification v1.5

2 Architecture and requirements

2.1 Components
There are multiple components that form a Wi-Fi Agile Multiband wireless infrastructure network, which may vary based
on the wireless network deployment. This section describes some of the components that form a Wi-Fi Agile Multiband
wireless infrastructure network.

• Access Point (AP): A Wi-Fi Agile Multiband wireless infrastructure network contains one or more Wi-Fi Agile
Multiband APs.
• WLAN Controller: A Wi-Fi Agile Multiband wireless infrastructure network contains zero or more WLAN
Controllers that may provide centralized management and other features and functions to interconnected AP(s).
• Client Station (STA): A Wi-Fi Agile Multiband wireless infrastructure network contains zero or more client STAs.
These client STAs may be single (WLAN only) or multimode (WLAN and Cellular) capable.
• RADIUS Server: A Wi-Fi Agile Multiband wireless infrastructure network contains zero or more RADIUS Servers
that provide Authentication, Authorization, and Accounting (AAA) services.
• ANQP Server: A Wi-Fi Agile Multiband wireless infrastructure network contains one or more ANQP servers that
provide informational services about the network. An ANQP server (as defined in [1]) in the network contains
ANQP-elements or information that can be used to derive the required ANQP-elements. The information in the
ANQP server can be obtained by the Access Network Query Protocol. An ANQP server can be co-located with an
AP or in an external server.

2.2 Topology
The topology of a Wi-Fi Agile Multiband wireless infrastructure network may vary based on components and deployment
requirements. This section illustrates two typical topologies based on the components identified in section 2.1.
Figure 1 depicts the system topology for connecting Wi-Fi Agile Multiband devices.

Figure 1. Wi-Fi Agile Multiband wireless infrastructure network

In a residential wireless network, a WLAN controller and an AAA RADIUS server may not be required. The functionality
provided by an ANQP server may be embedded in the WLAN AP or WLAN Controller.
In certain scenarios within the scope of this specification, a Wi-Fi Agile Multiband Cellular Data Aware AP could suggest
to a Wi-Fi Agile Multiband multimode STA that it should move its data traffic to a cellular data network. Figure 2 illustrates
a Wi-Fi Agile Multiband wireless infrastructure network and a cellular data access network.

© 2020 Wi-Fi Alliance. All Rights Reserved.

Used with the permission of Wi-Fi Alliance under the terms as stated in this document.
Page 9 of 32
Wi-Fi Agile Multiband Technical Specification v1.5

Figure 2. Wi-Fi Agile Multiband wireless infrastructure network with cellular data access network
The pairwise master key R0 key holder (R0KH) and the pairwise master key R1 key holder (R1KH) are components of the
Robust Security Network Association key management defined in section 13.2 of [1]. In certain scenarios, the R0KH and
R1KH could be implemented in the WLAN AP. These R0KH and R1KH elements are not present if the Fast BSS
Transition (FT) protocol is not supported.

2.3 Requirements
2.3.1 Baseline requirements
This specification assumes that all the AP and STA functions and services are implemented by Wi-Fi Agile Multiband
capable devices:

• IEEE 802.11a, IEEE 802.11b, or IEEE 802.11g

AND

• IEEE 802.11w Protected Management Frames

2.3.2 Wi-Fi Agile Multiband specific requirements

This section specifies the requirements for Wi-Fi Agile Multiband APs and Wi-Fi Agile Multiband STAs.
A Wi-Fi Agile Multiband AP shall support the following features:

• Indicates that it supports Wi-Fi Agile Multiband features

• Provides, on request from a Wi-Fi Agile Multiband STA, both pre-association and post-association, a preferred list
of BSSs within the ESS to which a Wi-Fi Agile Multiband STA is recommended to associate. If the Wi-Fi Agile
Multiband AP is cellular data aware, it optionally includes in the recommendation that the Wi-Fi Agile Multiband
STA may transfer to cellular data network(s) by providing the recommended relative preference of cellular data
network transfer for that STA.
▪ For each BSS, include the BSSID and a preference value for that BSS
▪ If a cellular data transfer is recommended, preference value for the cellular data network relative to the
recommended BSSs
▪ Include optional recommendation of cellular data transfer only if the Wi-Fi Agile Multiband STA has indicated
that it has cellular data connection available in the most recently transmitted Cellular Data Capabilities
attribute or the Cellular Data Capabilities subelement
• Unicasts an indication of whether or not new associations can be accepted in this BSS

© 2020 Wi-Fi Alliance. All Rights Reserved.

Used with the permission of Wi-Fi Alliance under the terms as stated in this document.
Page 10 of 32
Wi-Fi Agile Multiband Technical Specification v1.5

• Broadcasts an indication if new associations are not accepted in this BSS

• Requests that an associated Wi-Fi Agile Multiband STA transition away from this BSS
▪ Include in the request a reason code
▪ Include in the request BSSs within the ESS to which a Wi-Fi Agile Multiband STA is recommended to
associate
- For each BSS, include BSSID and a preference value for that BSS
▪ If the Wi-Fi Agile Multiband AP is cellular data aware, optionally include in the request an indication that the
Wi-Fi Agile Multiband STA should transfer to cellular data network
- Include optional recommendation of cellular data transfer only if the Wi-Fi Agile Multiband STA has indicated
that it has cellular data connection available in the most recently transmitted Cellular Data Capabilities
attribute or the Cellular Data Capabilities subelement
- If transfer to cellular data network is recommended, include a preference value for cellular data network
relative to the other BSSs included in the request.
• Sends a mandate to a Wi-Fi Agile Multiband STA informing that it is going to be disassociated
▪ Includes in the mandate a time for which a Wi-Fi Agile Multiband STA shall delay any attempt to reassociate
to this Wi-Fi Agile Multiband AP except when user interaction requests forgetting the SSID settings.
• An Wi-Fi Agile Multiband AP shall enable Protected Management Frames (PMF) whenever RSN is enabled1 (i.e.
Beacon and Probe Response frames contain an RSN element). A Wi-Fi Agile Multiband AP shall, when RSN is
enabled, require PMF to be negotiated for use in the association when a Wi-Fi Agile Multiband STA associates
with it.
A Wi-Fi Agile Multiband STA shall support the following features:

• Indicates whether or not it has a cellular data connection available (refer to section 4.2.3)
• Provides to a Wi-Fi Agile Multiband AP a list of channels and bands on which it prefers not to be associated,
including in each list entry:
▪ Channel and band
▪ Preference value
▪ Reason code
• Makes a request to a Wi-Fi Agile Multiband AP, post-association and optionally pre-association, to provide
preferred BSSs within the ESS to which the Wi-Fi Agile Multiband STA is recommended to associate. Optionally
requesting preference of cellular data network transfer relative to the recommended BSSs to associate with.
• Requires PMF to be negotiated for use in the association whenever associating with a Wi-Fi Agile Multiband AP
that has PMF enabled1( i.e. MFPC is set to 1 in Beacon and Probe Response frames).
• If an Wi-Fi Agile Multiband STA associates with an AP with RSN and/or OWE enabled that advertises MBO-OCE
element but that does not indicate support for PMF in Beacon and Probe Response frames, the STA should
disable Wi-Fi Agile Multiband and Optimized Connectivity capabilities so that insecure use of unprotected
management frames is avoided. If the Wi-Fi Agile Multiband STA disables Wi-Fi Agile Multiband and Optimized
Connectivity capabilities, it shall not transmit the MBO-OCE Information Element, and should not indicate support
for BSS Transition management, and might either not transmit the RM Enabled Capabilities element, or set bits 4
thru 6 of that element to zero.

2.3.3 Required IEEE 802.11 capabilities

This section specifies additional IEEE 802.11 capabilities that Wi-Fi Agile Multiband APs and Wi-Fi Agile Multiband STAs
shall support.
A Wi-Fi Agile Multiband AP shall support the following capabilities:

• ANQP response with Neighbor Report ANQP-element

• Neighbor Report element with BSS Transition Candidate Preference subelement

1 IEEE 802.11-2016 [1]] requires an AP to refuse a non-FT (re)association request from a STA that has negotiated PMF if a valid security association with
that STA exists. Such a scenario may occur if, for example, a STA transitions from AP1 to AP2 and then back to AP1, before AP1 has become aware that
the first transition had occurred. For example, the STA did not send a Disassociation or Deauthentication frame to AP1, and AP1 did not (yet) become
aware that the transition had occurred, and AP1 did not (yet) complete an SA Query procedure to determine the security association no longer exists. Wi-
Fi Agile Multiband implementers are advised to ensure such scenarios do not arise and/or do not result in a degraded user experience.

© 2020 Wi-Fi Alliance. All Rights Reserved.

Used with the permission of Wi-Fi Alliance under the terms as stated in this document.
Page 11 of 32
Wi-Fi Agile Multiband Technical Specification v1.5

• BTM Request frame with:

▪ BSS Transition Candidate List Entries field
▪ Disassociation Timer field
▪ Preferred Candidate List Included bit
▪ Disassociation Imminent bit
▪ BSS Termination Included bit
• Beacon request (refer to section 3.4 for more information)
• Country element
• The "Last Beacon Report Indication Request” subelement
•
A Wi-Fi Agile Multiband STA or a Wi-Fi Agile Multiband multimode STA shall support the following capabilities:

• WNM-Notification Request frame

• Neighbor Report element
• Beacon response (refer to section 3.4 for more information)
• “Last Beacon Report Indication” subelement
• “Reported Frame Body Fragment ID” subelement
A Wi-Fi Agile Multiband AP may support the following capabilities:

• The FT protocol with the over-the-air message exchange method

A Wi-Fi Agile Multiband STA or a Wi-Fi Agile Multiband multimode STA may support the following capabilities:

• The FT protocol with the over-the-air message exchange method

• ANQP request, with Neighbor Report ANQP-element
• BTM Query frame
• BTM Response frame with:
▪ BSS Transition Candidate List Entries field
▪ Status Code field
▪ Target BSSID field
▪ BSS Termination Delay field

2.3.4 Required IEEE 802.11 functionality for Wi-Fi Agile Multiband APs and STAs
A Wi-Fi Agile Multiband AP shall use a unique BSSID for each of the BSS that it operates.
A Wi-Fi Agile Multiband AP shall set to one bits 19 (BSS Transition Management Capability) and 31 (Interworking) of the
Extended Capabilities field in the Beacon and Probe Response frames.
A Wi-Fi Agile Multiband AP shall set to one bit 19 (BSS Transition Management Capability) of the Extended Capabilities
field in Association Response frames sent to Wi-Fi Agile Multiband STAs.
A Wi-Fi Agile Multiband AP shall include an RM Enabled Capabilities element in all Beacon and Probe Response frames.
A Wi-Fi Agile Multiband AP shall include a BSS Transition Candidate Preference subelement in every Neighbor Report
included in a BTM Request frame.
A Wi-Fi Agile Multiband AP shall include a Country element in all Beacon and Probe Response frames, where the last
octet of the Country String2 field is set to 0x04.
A Wi-Fi Agile Multiband STA shall set to one bit 19 (BSS Transition Management Capability) of the Extended Capabilities
field in Probe Request and Association Request frames.
A Wi-Fi Agile Multiband STA shall include an RM Enabled Capabilities element with bit 6 set to one into an Association
Request frame sent to a Wi-Fi Agile Multiband AP.

2 Per [1], the first two octets of the Country String field are set to the country code in which the AP is operating, while the last octet being set to 0x04
indicates use of the Global Operating Class Table in Annex E of [1].

© 2020 Wi-Fi Alliance. All Rights Reserved.

Used with the permission of Wi-Fi Alliance under the terms as stated in this document.
Page 12 of 32
Wi-Fi Agile Multiband Technical Specification v1.5

A Wi-Fi Agile Multiband STA shall always include a Supported Operating Classes element in the (Re)Association Request
frames.
A Wi-Fi Agile Multiband STA shall use the reassociation process (i.e. send a Reassociation Request frame) when roaming
between Wi-Fi Agile Multiband APs indicating the same SSID, unless it has reason to believe that the AP would reject a
Reassociation Request in which case it may use the association process instead.

© 2020 Wi-Fi Alliance. All Rights Reserved.

Used with the permission of Wi-Fi Alliance under the terms as stated in this document.
Page 13 of 32
Wi-Fi Agile Multiband Technical Specification v1.5

3 Wi-Fi Agile Multiband protocol

3.1 Introduction
The goal of the Wi-Fi Agile Multiband certification program is to certify features that facilitate efficient use of multiple
frequency bands/channels available to APs and the STAs. The program is built on the fundamental premise that the APs
and STAs each have information which can aid in making the most effective selection of the spectrum band in which the
STA and AP should be communicating. By exchanging this information with each other, APs and STAs enable each other
to make decisions that collectively drive the network towards more efficient use of the available spectrum.
The following sections describe the information exchanged and the mechanisms by which APs and STAs exchange the
desired information. Where applicable, references to existing IEEE standards are provided. In instances where there is a
need to go beyond what the IEEE standards specify, the corresponding functionality, protocols and constraints are
defined.

3.2 Channel and Band Indication and Preference

A Wi-Fi Agile Multiband STA shall inform the AP of all of its channels/bands capabilities by including the Supported
Operating Classes element in the (Re)Association Request frame. A Wi-Fi Agile Multiband STA shall use the global
operating class table (refer to Table E-4 of [1]) to indicate operating classes in the Operating Classes 3 field list. In addition,
it may also indicate some or all of these operating classes using non-global operating class tables.
A Wi-Fi Agile Multiband STA shall inform its serving Wi-Fi Agile Multiband AP or candidate Wi-Fi Agile Multiband AP of
channels in which it will not operate, or prefers not to operate. This information is communicated to the Wi-Fi Agile
Multiband AP when the Wi-Fi Agile Multiband STA associates or reassociates, and when the information changes while
the Wi-Fi Agile Multiband STA is associated.
On (re)association a Wi-Fi Agile Multiband STA shall indicate non-preferred channels by including one or more Non-
preferred Channel Report attributes (refer to section 4.4.2) in the (Re)Association Request frame. The Wi-Fi Agile
Multiband AP may store the non-preferred channels for this Wi-Fi Agile Multiband STA.
An associated Wi-Fi Agile Multiband STA shall indicate to the serving Wi-Fi Agile Multiband AP that its list of non-
preferred channels has changed by transmitting a WNM-Notification Request frame with Non-preferred Channel Report
subelement (refer to section 4.4 and 4.4.1).
The Wi-Fi Agile Multiband AP shall not steer the Wi-Fi Agile Multiband STA to a channel that the Wi-Fi Agile Multiband
STA indicated as non-operable with a value zero as preference. A Wi-Fi Agile Multiband AP should use the information
supplied in the Non-preferred Channel Report attributes/subelements for associated Wi-Fi Agile Multiband STAs when
selecting a new channel for the BSS and/or for requesting a BSS transition for that specific Wi-Fi Agile Multiband STA.
Every time a Wi-Fi Agile Multiband STA informs a Wi-Fi Agile Multiband AP of its channel and band preferences, either
via the inclusion of at least one Non-preferred Channel Report attribute in a (Re)Association frame or the inclusion of at
least one Non-preferred Channel Report subelement in a WNM-Notification Request frame, the Wi-Fi Agile Multiband AP
shall replace all (if any) previously indicated non-preferred channels (irrespective of Operating Class) with the most
current non-preferred channels as indicated by the Wi-Fi Agile Multiband STA. If the Wi-Fi Agile Multiband AP receives an
indication of channel and band preferences from a Wi-Fi Agile Multiband STA where:

• None of the Non-Preferred Channel Report attributes or subelements correspond to one of the Operating Classes
supported by that STA, the Wi-Fi Agile Multiband AP shall infer that the STA prefers to operate on any channel in
that Operating Class, or
• None of the Non-Preferred Channel Report attributes or subelements correspond to particular channels in an
Operating Class supported by that STA, the Wi-Fi Agile Multiband AP shall infer that the STA prefers to operate
on those particular channels.
Note: Wi-Fi Agile Multiband STA's cellular data capabilities shall not be updated unless explicitly indicated by the STA
(see section 3.3).

3 Per [1] section 9.4.2.54, a Wi-Fi Agile Multiband STA lists the operating classes in the Operating Classes field in descending order of preference.
However, a Wi-Fi Agile Multiband AP is not required to take this order into account when requesting a BSS transition for a STA.

© 2020 Wi-Fi Alliance. All Rights Reserved.

Used with the permission of Wi-Fi Alliance under the terms as stated in this document.
Page 14 of 32
Wi-Fi Agile Multiband Technical Specification v1.5

3.3 Cellular data capability indication

A Wi-Fi Agile Multiband AP may be cellular data aware, in which case it shall be able to recommend to a Wi-Fi Agile
Multiband multimode STA to transition to a cellular data network. To avoid a Wi-Fi Agile Multiband AP sending such an
indication to a non-multimode STA, or a Wi-Fi Agile Multiband multimode STA that does not have a cellular data
connection available, a Wi-Fi Agile Multiband STA shall report its cellular data capability to the Wi-Fi Agile Multiband AP
using one of the following methods:
1. Probe Request frame
A non-associated Wi-Fi Agile Multiband STA indicates its cellular data capability to a Wi-Fi Agile Multiband AP
during active scanning by transmitting a Probe Request frame to the Wi-Fi Agile Multiband AP that contains an
MBO-OCE IE with a Cellular Data Capabilities attribute (defined in section 4.2.3).
2. (Re)Association Request frame
A non-associated STA indicates its cellular data capabilities to a Wi-Fi Agile Multiband AP during (re) association
by transmitting to the Wi-Fi Agile Multiband AP a (Re)Association Request frame that contains an MBO-OCE IE
with a Cellular Data Capabilities attribute (defined in section 4.2.3).
3. WNM-Notification Request frame
An associated Wi-Fi Agile Multiband STA indicates a change in its cellular data capabilities to its serving Wi-Fi
Agile Multiband AP by transmitting a WNM-Notification Request frame that contains a Cellular Data Capabilities
subelement (defined in section 4.4.2).
A Wi-Fi Agile Multiband multimode STA shall update its cellular data capability to its serving Wi-Fi Agile Multiband AP
when there is a change in cellular data capability status, for example one of following conditions:

• Camping on a new cellular data radio access technology

• Initial connection or a handover to a cell of a new cellular data Radio Access Technology (RAT)
• Detachment or disconnection from the cellular data radio technology (for example, due to cellular data coverage
limitations or user action, ‘flight mode’)
A Wi-Fi Agile Multiband AP shall use only the most recent cellular data capability indication received from the Wi-Fi Agile
Multiband STA. A Wi-Fi Agile Multiband AP shall only send a recommendation to transition to a cellular data network to a
Wi-Fi Agile Multiband STA that has indicated it has a cellular data connection available.
Note that the presence of the MBO Cellular Data Capabilities attribute is an indication of Wi-Fi Agile Multiband capability
because all Wi-Fi Agile Multiband STAs shall include the attribute in Probe Request frames and (Re)Association Request
frames.

3.4 Beacon report

A Wi-Fi Agile Multiband AP shall send a Beacon request to an associated STA whenever it requires a Beacon report from
the STA. The AP shall only send the Beacon request to the STA if the STA indicates that it supports the associated RM
capability (as specified in section 11.11.9.1 of [1]).
The Beacon requests may be sent with the following parameters:

• Channel Number set to

▪ a specific channel (along with the appropriate global operating class) or
▪ 0 (along with the appropriate global operating class) or
▪ 255 (along with one or more AP Channel Report subelements)
• Measurement mode set to
▪ Active or
▪ Passive or
▪ Beacon Table

© 2020 Wi-Fi Alliance. All Rights Reserved.

Used with the permission of Wi-Fi Alliance under the terms as stated in this document.
Page 15 of 32
Wi-Fi Agile Multiband Technical Specification v1.5

• BSSID set to
▪ a specific BSSID or
▪ Wildcard BSSID
• Optional SSID subelement
▪ included with the SSID of the APs of interest or
▪ not included (implying Wildcard SSID)
• Optional Reporting Detail subelement
▪ included and set to 0 or
▪ included and set to 1 or
▪ included and set to 2
• Optional AP Channel Report subelement
▪ one or more of these included, along with the appropriate global operating class (if Channel Number is set to
255) or
▪ not included (if Channel Number is other than 255)
• Optional Request element
▪ not included or
▪ included and specifying a list of Element IDs
A Wi-Fi Agile Multiband AP shall not set a measurement mode in a Beacon request to an associated STA to a mode that
the STA has not explicitly indicated support for via RM Enabled Capabilities element.
A Wi-Fi Agile Multiband AP may use the information supplied in the Beacon reports from associated Wi-Fi Agile Multiband
STAs as an input into an algorithm used to select a new channel for the BSS and/or for requesting a BSS transition for
any associated Wi-Fi Agile Multiband STA. The specification of such algorithms is beyond the scope of this program.
A Wi-Fi Agile Multiband STA shall accept a Beacon request from its associated AP with measurement mode set to
Beacon Table, and respond with a Beacon report as specified in section 11.11.9.1 of [1].
A Wi-Fi Agile Multiband STA that implements the subset of FT protocols as outlined in section 3.7 shall implement support
for active and passive measurement mode Beacon requests, and indicate such support via RM Enabled Capabilities
element, as specified in [1].
A Wi-Fi Agile Multiband STA that indicates support for active and passive Beacon requests should 4 accept a Beacon
request from its associated AP with measurement mode set to active or passive, and respond with a Beacon report after
performing the appropriate procedures, as specified in section 11.11.9.1 of [1].
A Wi-Fi Agile Multiband STA that responds to an active or passive Beacon request shall not include information about
channels that do not overlap with the requested channels. A STA is allowed, but not required, to send information about
overlapping channels, in the Beacon report it sends to the AP.
A Wi-Fi Agile Multiband STA shall, when responding to a Beacon request, indicate a global operating class in Beacon
reports, except if the corresponding received Beacon or Probe Response frame indicates (for example in Supported
Operating Classes or AP Channel Report elements) a non-global operating class, in which case the STA shall indicate
either the same non-global operating class or the corresponding global operating class.
A Wi-Fi Agile Multiband STA shall indicate the last frame of the sequence of frames generated as a response to a Beacon
request when requested by an AP in a Beacon Request, as specified in section 9.4.2.21.7 of [1].
A Wi-Fi Agile Multiband STA shall report in the Beacon Report all information elements requested by the AP in a Beacon
Request, without truncating any of those elements. When necessary, the Wi-Fi Agile Multiband STA shall employ
fragmentation of the Beacon Report, as specified in section 9.4.2.21.7 of [1].

4 “Should” here means that, in normal circumstances, the Wi-Fi Agile Multiband STA shall scan the requested channels and respond with the requested
information. However, the STA may reject the Beacon request from the AP in particular circumstances where the requested scan operation would impact
the quality of experience provided by the STA, such as when it has latency sensitive traffic, the quality of which may be impacted due to the scan operation.

© 2020 Wi-Fi Alliance. All Rights Reserved.

Used with the permission of Wi-Fi Alliance under the terms as stated in this document.
Page 16 of 32
Wi-Fi Agile Multiband Technical Specification v1.5

3.5 BSS transition management

3.5.1 BSS Transition Information request
3.5.1.1 STA to Candidate AP, ANQP based

A Wi-Fi Agile Multiband STA may send an ANQP request for a Neighbor Report ANQP-element to request from a
Candidate AP a prioritized list of BSSs, within the AP’s ESS, to which the Wi-Fi Agile Multiband STA may transition.
A Wi-Fi Agile Multiband STA may send an ANQP request for a Cellular Data Connection Preference subtype MBO ANQP-
element using the MBO Query List (refer to section 4.3.1) to request from a Candidate Wi-Fi Agile Multiband AP a
preference value for the STA to move to a cellular data network.
When the Wi-Fi Agile Multiband STA wants to request such information from an Wi-Fi Agile Multiband AP prior to
associating with it, it may use the Neighbor Report ANQP-element defined in section 9.4.5.19 of [1], with modifications as
described in section 4.3.3 of this specification.
In addition, or alternatively, the Wi-Fi Agile Multiband STA may also request the Cellular Data Connection Preference from
the Wi-Fi Agile Multiband AP by sending a GAS ANQP request containing the Wi-Fi Alliance Vendor Specific element
carrying an MBO Query List ANQP-element requesting for Cellular Data Connection Preference subtype (refer to section
4.3.2).
The ANQP request to the Wi-Fi Agile Multiband AP5:
1. Shall include a Query List ANQP-element requesting a Neighbor Report ANQP (refer to section 9.4.5.19 of [1])
2. May include a Query List ANQP-element requesting a Cellular Data Connection Preference subtype (section
4.3.2) and no payload to request the Wi-Fi Agile Multiband AP to include the preference value for using cellular
data connection if the STA is Wi-Fi Agile Multiband multimode STA.
On receipt of an ANQP request for a Neighbor Report ANQP-element, the Wi-Fi Agile Multiband AP shall respond with an
ANQP response6 that includes a Neighbor Report ANQP-element, as defined in section 9.4.5.19 of [1], with modifications
as described in section 4.3.3 of this specification, that:
1. Shall contain zero or more Neighbor Report elements, each of which shall correspond to a global operating class
and shall contain the BSS Transition Candidate Preference subelement (Figure 9-299 of [1]), which the Wi-Fi
Agile Multiband AP considers to be candidates for Wi-Fi Agile Multiband STA association
2. When one or more Neighbor Report elements are present:
▪ The Preference field for the most-preferred BSS shall be set to 255
▪ The Preference field values used for each level of preference shall decrement consecutively from 255, except
for excluded BSSs which shall have Preference field set to zero.
▪ The Preference field for BSS that have the same level of preference shall be set to the same value
▪ One of the Neighbor Report element shall be the AP's own BSS that corresponds to the address 1 field of the
ANQP request. If the AP does not wish for the STA to associate with its own BSS, it shall set the preference
of its own BSS to zero.
On receipt of an ANQP request for a Cellular Data Connection Preference subtype MBO ANQP-element, a cellular data
aware Wi-Fi Agile Multiband AP shall respond with an ANQP response that includes the Cellular Data Connection
Preference subtype, specifying the preference value of using the cellular data connection.
A Wi-Fi Agile Multiband AP may include one or more Neighbor Report ANQP-elements and/or a Cellular Data Connection
Preference subtype MBO ANQP-element in the same ANQP response.

5 Per [1]], the ANQP request to the AP is transmitted unicast with address 1 field set to the MAC address of the Candidate AP, and address 3 field set to
the wildcard BSSID value.

6 Per [1], the ANQP response to the STA is transmitted unicast with address 1 field set to the MAC address of the STA, and address 3 field set to the
wildcard BSSID value.

© 2020 Wi-Fi Alliance. All Rights Reserved.

Used with the permission of Wi-Fi Alliance under the terms as stated in this document.
Page 17 of 32
Wi-Fi Agile Multiband Technical Specification v1.5

3.5.1.2 STA to Serving AP, BSS Transition Management Based

A Wi-Fi Agile Multiband STA may send a BTM Query frame to its serving Wi-Fi Agile Multiband AP to request a prioritized
list of BSSs within the AP’s ESS to which the Wi-Fi Agile Multiband STA may transition.
On receipt of a BTM Query frame, the AP shall respond with a BTM Request frame (refer to section 9.6.14.9 in [1]), that:
1. Shall include a BSS Transition Candidate List Entries field (refer to section 9.6.14.9 of [1]), that:
a. Contains one or more Neighbor Report elements, each of which shall correspond to a global operating class
and shall contain the BSS Transition Candidate Preference subelement (Figure 9-299 of [1])
b. When one or more Neighbor Report elements are present:
- The Preference field for the most-preferred BSS shall be set to 255
- The Preference field values used for each level of preference shall decrement consecutively from 255,
except for excluded BSSs which shall have Preference field set to zero
- The Preference field for BSSs that have the same level of preference shall be set to the same value

c. Shall include a Neighbor Report element for the AP's own BSS that corresponds to the address 1 field of the
BTM Query frame. If the AP does not wish the STA to keep the association with the BSS, the AP shall set the
preference of its own BSS to zero.
2. May include an MBO-OCE IE in the BSS Transition Candidate List Entries field if the Wi-Fi Agile Multiband STA
has indicated that it has cellular data connection available in the Cellular Data Capabilities attribute or Cellular
Data Capabilities subelement. If included, the MBO-OCE IE shall contain the Cellular Data Connection
Preference attribute7.

3.5.2 AP BSS Transition Solicitation

A Wi-Fi Agile Multiband AP shall send an unsolicited BTM Request frame (section 11.24.7 of [1]) to an associated STA
whenever it determines to steer the STA to a new BSS (or to cellular data network) and before terminating the BSS.
The unsolicited BTM Request frame:
1. Shall indicate the recommended transition channels and BSSs using the BSS Transition Candidate List
containing zero or more Neighbor Report elements (refer Figure 9-295 of [1]). Each Neighbor Report shall
correspond to a global operating class and shall contain the BSS Transition Candidate Preference subelement
(Figure 9-299 of [1])
When one or more Neighbor Report elements are present:

a. The Preference field for the most-preferred BSS shall be set to 255
b. The Preference field values used for each level of preference shall decrement consecutively from 255, except
for excluded BSSs which shall have Preference field set to 0
c. The Preference field for BSSs that have the same level of preference shall be set to the same value
2. Shall include an MBO-OCE IE that:
a. Shall contain the Transition Reason Code attribute (section 4.2.6).
b. May contain the Cellular Data Connection Preference attribute (section 4.2.5) that specifies the preference
value of using the cellular data connection. The Wi-Fi Agile Multiband AP may include in the transition request
the Cellular Data Connection Preference attribute only if the Wi-Fi Agile Multiband STA has indicated in the
Cellular Data Capabilities attribute or Cellular Data Capabilities subelement that it has cellular data
connection available.

7 The AP will include a Cellular Data Connection Preference Attribute if it has information to convey about the relative preference of the cellular data
connection.

© 2020 Wi-Fi Alliance. All Rights Reserved.

Used with the permission of Wi-Fi Alliance under the terms as stated in this document.
Page 18 of 32
Wi-Fi Agile Multiband Technical Specification v1.5

A Wi-Fi Agile Multiband AP shall, prior to disassociating a Wi-Fi Agile Multiband STA, send an unsolicited BTM Request
frame with Disassociation Imminent field set to one to that STA (section 9.6.14.9 in [1]) in the unsolicited BTM Request
frame. When the Disassociation Imminent field is set to one, the Wi-Fi Agile Multiband AP:
1. Shall set the Disassociation Timer field to the number of TBTTs that will occur prior to the Wi-Fi Agile Multiband
AP disassociating the Wi-Fi Agile Multiband STA (section 9.6.14.9 in [1]).
2. Shall instruct the Wi-Fi Agile Multiband STA not to retry association with this BSS for the time specified in the Re-
Association Delay field of the Association Retry Delay attribute, by including in the BTM Request frame an MBO-
OCE IE containing an Association Retry Delay attribute with a non-zero value in the Re-association Delay field.
The count-down of the time until the STA may retry association with the same AP starts when the BTM Request is
received.
3. Shall send a Disassociation frame to the STA after expiry of the Disassociation Timer and no later than 2 seconds
after the Disassociation Timer expires. The AP is not expected to send a Disassociation frame if the STA has sent
a Disassociation frame to the AP beforehand, or if the AP has become aware beforehand that the STA has
already roamed away (e.g. by inter-AP communications from the target AP).
A Wi-Fi Agile Multiband AP shall, prior to terminating a BSS, send an unsolicited BTM Request frame to all associated Wi-
Fi Agile Multiband STAs by setting the BSS Termination Included field to one (section 9.6.14.9 in [1]). When the BSS
Termination Included field is set to one, the Wi-Fi Agile Multiband AP:
1. Shall not include the Association Retry Delay attribute in the MBO-OCE IE
2. Shall set the BSS Termination TSF field of the BSS Termination Duration field according to the time until the BSS
is terminated
3. Shall terminate the BSS after the BSS Termination TSF is reached 8.
On receipt of an unsolicited BTM Request frame:
1. If the Wi-Fi Agile Multiband STA rejects the Transition Management Request frame (i.e., does not intend to
disassociate from the Wi-Fi Agile Multiband AP), it shall respond with a BTM Response frame that:
a. Shall contain the Status Code field (section 9.6.14.10 in [1]) indicating reject.
b. Shall contain the MBO-OCE IE containing the Transition Rejection Reason Code (section 4.2.7).
2. If the Wi-Fi Agile Multiband STA accepts the Transition Management Request frame (i.e., intends to disassociate
with the BSS) it may respond with a BTM Response frame that shall contain the Status Code field (section
9.6.14.10 in [1]) indicating Accept. The Wi-Fi Agile Multiband STA may also include the Target BSSID field
(section 9.6.14.10 in [1]).
On receipt of an unsolicited BTM Request frame with Disassociation Imminent bit set to one and/or BSS Termination
Included field set to one:
If the BTM Request frame contains a non-zero BSS Transition Candidate List Entries field, and a BSS is available
that is in the same ESS as the serving AP and is indicated in the BSS Transition Candidate List with Preference
field set to a non-zero value, and the Wi-Fi Agile Multiband STA has not received indication from the AP that BSS
association or authentication would be unsuccessful, the Wi-Fi Agile Multiband STA shall attempt to associate
with another BSS before the Disassociation Timer expires or the BSS Termination TSF is reached.
The Wi-Fi Agile Multiband STA may include in the BSS Transition Response frame a BSS Transition Candidate List
(section 9.6.14.10 in [1]) containing Neighbor Report elements corresponding to global operating classes to inform the Wi-
Fi Agile Multiband AP of BSSs the STA has discovered in its scanning process.
If a Wi-Fi Agile Multiband STA has received an unsolicited BTM Request frame that contains an MBO-OCE IE with an
Association Retry Delay attribute indicating a non-zero Re-association Delay field, the Wi-Fi Agile Multiband STA shall not
attempt to associate with this BSS, after it has been disassociated, for the duration of the specified period.

8 In accordance with [1]], the Wi-Fi Agile Multiband STA should, when choosing another BSS with which to attempt to associate, refrain from choosing a
BSS that is indicated in the BSS Transition Candidate List Entries field with Preference value equal to zero, and refrain from choosing a BSS that is not
included in the BSS Transition Candidate List Entries field if the Abridged bit in the Request mode field is set to one.

© 2020 Wi-Fi Alliance. All Rights Reserved.

Used with the permission of Wi-Fi Alliance under the terms as stated in this document.
Page 19 of 32
Wi-Fi Agile Multiband Technical Specification v1.5

3.6 Association Disallowed Indication

If a Wi-Fi Agile Multiband AP cannot accept new associations, it shall include the MBO-OCE IE with the Association
Disallowed attribute (section 4.2.4) in Beacon and Probe Response frames. When such a Wi-Fi Agile Multiband AP
receives an Association Request frame from a Wi-Fi Agile Multiband STA, it shall respond with an Association Response
frame with the Status Code field set to 17 or 30. When a Wi-Fi Agile Multiband STA receives a Beacon, Probe Response
or (Re)Association Response frame from a Wi-Fi Agile Multiband AP containing an MBO-OCE IE with the Association
Disallowed attribute, that Wi-Fi Agile Multiband STA shall not send a (Re)Association Request frame or a unicast Probe
Request frame to that AP until it receives a Beacon or Probe Response frame from that AP without the Association
Disallowed attribute.
The presence of the MBO-OCE IE with the Association Disallowed attribute in any of the Beacon, Probe Response or
(Re)Association Response frames shall be interpreted as an indication that the Wi-Fi Agile Multiband AP is currently not
accepting associations.

3.7 Fast BSS Transition

To reduce the duration of time that connectivity is lost between a Wi-Fi Agile Multiband STA and an ESS during a BSS
transition, the Wi-Fi Agile Multiband APs and the Wi-Fi Agile Multiband STAs may implement a subset of the FT protocols
described in section 13 of [1]. Those Wi-Fi Agile Multiband APs and Wi-Fi Agile Multiband STAs that implement FT shall
implement the Over-the-Air (OTA) Protocol. The Wi-Fi Agile Multiband APs and Wi-Fi Agile Multiband STAs are not
required to implement the Over-the-DS FT Protocol or FT Resource Request Protocol.
When a Wi-Fi Agile Multiband STA intends to use Fast BSS Transition from its current Wi-Fi Agile Multiband AP to a
target Wi-Fi Agile Multiband AP, the message exchange is performed by means of the OTA FT protocol, whereby the Wi-
Fi Agile Multiband STA communicates directly with the target Wi-Fi Agile Multiband AP using IEEE Std. 802.11
authentication with the FT authentication algorithm.

3.8 MBO Capability Indication attribute

Wi-Fi Agile Multiband APs shall include the MBO Capability Indication attribute in Beacon frames, Probe Response
frames and (Re)Association Response frames. This attribute indicates that the AP is a Wi-Fi Agile Multiband AP, and
whether it is cellular data aware or not.

© 2020 Wi-Fi Alliance. All Rights Reserved.

Used with the permission of Wi-Fi Alliance under the terms as stated in this document.
Page 20 of 32
Wi-Fi Agile Multiband Technical Specification v1.5

4 Information Elements, attributes and frame formats

This section defines the MBO-OCE Information Element, attributes, and frame formats for Wi-Fi Agile Multiband APs and
STAs and the Wi-Fi Agile Multiband communication protocol.

4.1 MBO-OCE Information Element

The Vendor Specific information element format (as defined in sub-clause 9.4.2.26 of [1]) shall be used to define the
MBO-OCE Information Element (MBO-OCE IE) in this specification. Little endian encoding is used for multi-byte fields and
subfields. The format of the MBO-OCE IE is shown in Table 3.
Table 3. MBO-OCE IE format

Field Size (Octets) Value (Hex) Description

Element ID 1 0xDD IEEE 802.11 vendor specific information element

Length 1 Variable Length of the following fields in the IE in octets. The Length field is a variable,
and set to 4 plus the total length of the MBO attributes.
OUI 3 0x50-6F-9A Wi-Fi Alliance specific OUI (refer to sub-clause 9.4.1.32 of [1])

OUI Type 1 0x16 Identifying the type and version of the MBO-OCE IE

MBO attributes Variable Variable One or more MBO attribute(s)

4.2 MBO attributes

The MBO attributes are defined to have a common general format consisting of a one octet MBO Attribute ID field, one
octet Length field, and variable length attribute specific Information fields, as shown in Table 4.
Table 4. MBO attribute general format

Field Size (Octets) Value (Hex) Description

Attribute ID 1 Variable Identifies the type of MBO attribute.

Attribute Length 1 Variable Length of the following fields in the attribute

Attribute Body Field Variable Variable MBO attribute specific information fields

Table 5 defines the MBO attributes and whether their support is mandatory or optional. The MBO attributes shall be
inserted in the IEEE 802.11 Management frames used for Wi-Fi Agile Multiband purposes as specified in Table 5.
Table 5. MBO attributes

Attribute Field description Management frame Mandatory/Optional

ID
AP STA AP STA

1 MBO AP Capability Indication Beacon, Probe NA M NA

Response, and
(Re)Association
Response
2 Non-preferred Channel Report NA (Re)Association M M
Request
3 Cellular Data Capabilities NA Probe Request, M M
(Re)Association
Request

© 2020 Wi-Fi Alliance. All Rights Reserved.

Used with the permission of Wi-Fi Alliance under the terms as stated in this document.
Page 21 of 32
Wi-Fi Agile Multiband Technical Specification v1.5

Attribute Field description Management frame Mandatory/Optional

ID
AP STA AP STA

4 Association Disallowed Beacon, Probe NA M M

Response, and
(Re)Association
Response
5 Cellular Data Connection Preference1 BTM Request NA CM CM

6 Transition Reason Code BTM Request NA M M

7 Transition Rejection Reason Code NA BTM Response NA M

8 Association Retry Delay BTM Request NA M M

9-100 Reserved for Wi-Fi Agile Multiband NA NA NA NA

0, 101-255 Reserved NA NA NA NA

Notes:
1. Mandatory for a Wi-Fi Agile Multiband multimode devices, NA for other Wi-Fi Agile Multiband devices

4.2.1 MBO AP Capability Indication attribute

An MBO AP Capability Indication attribute is used by a Wi-Fi Agile Multiband AP to indicate that it is Wi-Fi Agile Multiband
capable.
A Wi-Fi Agile Multiband AP shall include an MBO AP Capability Indication attribute in Beacon, Probe Response, and
(Re)Association Response frames. The MBO AP Capability Indication attribute is ordered relative to other elements in the
Beacon, Probe Response, and (Re)Association frames, as defined in Table 9-27, Table 9-34 and Table 9-30 or 9-32,
respectively, of [1]. Table 6 illustrates the format of the MBO AP Capability Indication attribute.
Table 6. MBO AP Capability Indication attribute

Field Size (Octets) Value (Hex) Description

Attribute ID 1 0x01 Identifies the type of MBO attribute.

Attribute Length 1 0x01 Length of the following field in the attribute in octets.

MBO Capability Indication 1 Variable Each bit of this field indicates whether the corresponding capability listed in
Table 7 is enabled.

The format of the MBO AP Capability Indication field is defined in Table 7.

Table 7. MBO AP Capability Indication field values

Bit(s) Description

0x80 (MSB) Reserved

0x40 When set to 1, it indicates the Wi-Fi Agile Multiband AP is cellular data aware, otherwise it indicates the Wi-Fi Agile
Multiband AP is not cellular data aware
0x20 – 0x01 (LSB) Reserved

4.2.2 Non-preferred Channel Report attribute

The format of the Non-preferred Channel Report attribute is illustrated in Table 8.
A Wi-Fi Agile Multiband STA shall use the Non-preferred Channel Report attribute to inform an AP the channels it would
prefer not to or will not operate on.

© 2020 Wi-Fi Alliance. All Rights Reserved.

Used with the permission of Wi-Fi Alliance under the terms as stated in this document.
Page 22 of 32
Wi-Fi Agile Multiband Technical Specification v1.5

One or more Non-preferred Channel Report attributes shall be included in (Re)Association Request frames as described
in section 3.2. Each Non-preferred Channel Report attribute may specify zero or more channels and their preferences as
defined in Table 8.
Table 8. Non-preferred Channel Report attribute

Field Size (Octets) Value (Hex) Description

Attribute ID 1 0x02 Identifies the type of MBO attribute.

Attribute Length 1 0x00 or Length of the following fields in the attribute in octets.
Variable
Operating Class 1 Variable Operating Class contains an enumerated value from table E-4 in Annex E of
[1], specifying the global operating class in which the Channel List is valid
Channel List Variable Variable The Channel List contains a variable number of octets, where each octet
describes a single channel number.
An empty Channel List field indicates that the indicated Preference applies to
all channels in the Operating Class.
Channel numbering is dependent on Operating Class per Annex E of [1].
Preference 1 0-255 Indicates a preference value for the above set of channels, as defined in Table
9.
Reason Code 1 0-255 Indicates the reason that the Wi-Fi Agile Multiband STA prefers not to operate
in this band/channel, refer to Table 10.

If a Wi-Fi Agile Multiband STA has no non-preferred channels across all supported Operating Classes, a single Non-
preferred Channel Report attribute is included with the Attribute Length field set to value zero and the Operating Class,
Channel List, Preference and Reason Code fields are not present.
The values of the Preference field are defined in Table 9.
Table 9. Preference Field Values

Value Description

0 Indicates a non-operable band/channel of the Wi-Fi Agile Multiband STA

1 Indicates a band/channel the Wi-Fi Agile Multiband STA prefers not to operate in

2-254 Reserved

255 Indicates a band/channel the Wi-Fi Agile Multiband STA prefers to operate in

The value of the Reason Code field is defined in Table 10.

Table 10. Reason Code Field Values

Value Name Description

0 Unspecified Unspecified reason

1 Co-located Interference An unacceptable level of interference is being experienced by the Wi-Fi Agile Multiband STA in this
channel
2 In-device Interferer The Wi-Fi Agile Multiband STA has another active connection in this channel, or near enough to this
channel to cause operating interference
3-255 Reserved Reserved

4.2.3 Cellular Data Capabilities attribute

The format of the Cellular Data Capabilities attribute is illustrated in Table 11.

© 2020 Wi-Fi Alliance. All Rights Reserved.

Used with the permission of Wi-Fi Alliance under the terms as stated in this document.
Page 23 of 32
Wi-Fi Agile Multiband Technical Specification v1.5

The Cellular Data Capabilities attribute shall be included in Probe Request and (Re)Association Request frames as
described in section 3.3. The use of the Cellular Data Capabilities attribute is described in section 3.3.
Table 11. Cellular Data Capabilities attribute

Field Size (Octets) Value (Hex) Description

Attribute ID 1 0x03 Identifies the type of MBO attribute.

Attribute Length 1 0x01 Length of the following field in the attribute in octets.

Cellular Data Connectivity 1 Variable Information regarding Wi-Fi Agile Multiband STA’s cellular data capabilities as
defined in Table 12.

The values of the Cellular Data Connectivity field are defined in Table 12.
Table 12. Cellular Data Connectivity field

Value Description

0 Reserved

1 Cellular data connection available

2 Cellular data connection not available

3 Not Cellular data capable

4-255 Reserved

Note: “Cellular data connection available” indicates that the device either has an active cellular data connection or could obtain such connection (i.e.
has a cellular data connection in inactive state).

4.2.4 Association Disallowed attribute

The format of the Association Disallowed attribute is illustrated in Table 13.
The use of the Association Disallowed attribute is described in section 3.6.
Table 13. Association Disallowed attribute

Field Size (Octets) Value (Hex) Description

Attribute ID 1 0x04 Identifies the type of MBO attribute.

Attribute Length 1 0x01 Length of the following field in the attribute in octets.

Reason Code 1 Variable The reason why the AP is not accepting new associations as defined in Table
14.

The values of the Reason Code field are defined in Table 14.
Table 14. Reason Code field values

Value Description

0 Reserved

1 Unspecified reason

2 Maximum number of associated STAs reached

3 Air interface is overloaded

4 Authentication server overloaded

5 Insufficient RSSI

© 2020 Wi-Fi Alliance. All Rights Reserved.

Used with the permission of Wi-Fi Alliance under the terms as stated in this document.
Page 24 of 32
Wi-Fi Agile Multiband Technical Specification v1.5

Value Description

6-255 Reserved

4.2.5 Cellular Data Connection Preference attribute

The format of the Cellular Data Connection Preference attribute is illustrated in Table 15.
The Cellular Data Connection Preference attribute may be included in BTM Request frames as described in section
3.5.1.2.
Table 15. Cellular Data Connection Preference attribute

Field Size (Octets) Value (Hex) Description

Attribute ID 1 0x05 Identifies the type of MBO attribute.

Attribute Length 1 Variable Length of the following fields of the attribute. in octets.

Cellular Data Preference 1 Variable Indicates a preference value for the cellular data connection, as defined in
Table 16.

The value for the Cellular Data Preference field is defined in Table 16.
Table 16. Cellular Data Preference Field Values

Value Description

0 Excluded. The Wi-Fi Agile Multiband AP does not want the Wi-Fi Agile Multiband STA to use the cellular data
connection
1 The Wi-Fi Agile Multiband AP prefers the Wi-Fi Agile Multiband STA should not use cellular data connection

2-254 Reserved

255 The Wi-Fi Agile Multiband AP prefers the Wi-Fi Agile Multiband STA should use cellular data connection

The BTM Request frame may contain only the Cellular Data Connection Preference attribute or this attribute may be
included in addition to the Neighbor Report List. Use of the Cellular Data Connection Preference attribute allows the Wi-Fi
Agile Multiband AP to indicate to the Wi-Fi Agile Multiband STA its preference for the Wi-Fi Agile Multiband STA to move
its data traffic from the BSS to cellular data network. If included with a Neighbor Report List, the Wi-Fi Agile Multiband AP
can indicate the relative preference for various BSSs, channels and the cellular data connection.
When a Wi-Fi Agile Multiband STA that has indicated availability of cellular data connection receives a BSS Transition
Request frame that contains an MBO-OCE IE with a Cellular Data Connection Preference attribute, it uses the
recommendation to evaluate if and when it could move its data traffic from the BSS to the cellular data network.
A Wi-Fi Agile Multiband STA that did not indicate availability of cellular data connection shall ignore the Cellular Data
Connection Preference attribute when this is present in the BSS Transition Request.

4.2.6 Transition Reason Code attribute

The format of the Transition Reason Code attribute is illustrated in Table 17.
The Transition Reason Code attribute may be included in BSS Transition Request frames as described in section 3.5.
Table 17. Transition Reason Code attribute

Field Size (Octets) Value (Hex) Description

Attribute ID 1 0x06 Identifies the type of MBO attribute.

Attribute Length 1 0x1 Length of the following field of the attribute in octets.

© 2020 Wi-Fi Alliance. All Rights Reserved.

Used with the permission of Wi-Fi Alliance under the terms as stated in this document.
Page 25 of 32
Wi-Fi Agile Multiband Technical Specification v1.5

Field Size (Octets) Value (Hex) Description

Transition Reason Code 1 Variable Identifies the reason for this transition recommendation as specified in Table
18

The Transition Reason Code attribute is provided by a Wi-Fi Agile Multiband AP in the BSS Transition Request frame to
indicate the reason for the transition request. This attribute is mandatory in the BSS Transition Request and may be used
by a Wi-Fi Agile Multiband STA to determine its next action after receiving the BSS Transition Request from the Wi-Fi
Agile Multiband AP.
The value for the Transition Reason Code field is defined in Table 18.
Table 18. Transition Reason Code field values

Value Description

0 Unspecified

1 Excessive frame loss rate

2 Excessive delay for current traffic stream

3 Insufficient bandwidth for current traffic stream

4 Load balancing

5 Low RSSI

6 Received excessive number of retransmissions

7 High interference

8 Gray zone
Imbalance between the PHY operating margin in the downlink direction compared to the uplink direction can result in a “gray”
zone of coverage in which Wi-Fi Agile Multiband STAs can become “stalled” in certain states such as:
• Mobile is 802.11 authenticated, but not associated
• Mobile is 802.11 associated, but not EAP authenticated
• Mobile is unable to obtain an IP address via DHCP
• Mobile is unable to perform name resolution via DNS

9 Transitioning to a premium AP

10-255 Reserved

4.2.7 Transition Rejection Reason Code attribute

The format of the Transition Rejection Reason Code attribute is illustrated in Table 19.
The attribute may be included in BTM Response frames as described in in section 3.5.
Table 19. Transition Rejection Reason Code attribute

Field Size (Octets) Value (Hex) Description

Attribute ID 1 0x07 Identifies the type of MBO attribute.

Attribute Length 1 0x1 Length of the following field of the attribute in octets.

Transition Rejection Reason 1 Variable Identifies the reason for rejecting the transition request as specified in Table 20
Code

The values of the Transition Rejection Reason Code field are defined in Table 20.

© 2020 Wi-Fi Alliance. All Rights Reserved.

Used with the permission of Wi-Fi Alliance under the terms as stated in this document.
Page 26 of 32
Wi-Fi Agile Multiband Technical Specification v1.5

Table 20. Transition Rejection Reason Code field values

Value Description

0 Unspecified

1 Excessive frame loss rate expected by the Wi-Fi Agile Multiband STA if it transitions to the suggested candidate BSS(s) in the
BTM Request frame
2 Excessive delay for current traffic stream would be incurred by BSS transition at this time

3 Insufficient QoS capacity for current traffic stream expected by the Wi-Fi Agile Multiband STA if it transitions to the suggested
candidate BSS(s) in the BTM Request frame
4 Low RSSI in frames being received by the Wi-Fi Agile Multiband STA from to the suggested candidate BSS(s) in the BTM
Request frame
5 High interference expected by the Wi-Fi Agile Multiband STA if it transitions to the suggested candidate BSS(s) in the BTM
Request frame
6 Service Availability – the Wi-Fi Agile Multiband STA expects that services it needs which are available at its serving AP will not be
available if it transitions to the suggested candidate BSS(s) in the BTM Request frame
7-255 Reserved

4.2.8 Association Retry Delay attribute

The format of the Association Retry Delay attribute is illustrated in Table 21.
The attribute may be included in BTM Request frames as described in Table 21. The use of this attribute is described in
section 3.5.1.
Table 21. Association Retry Delay attribute

Field Size (Octets) Value (Hex) Description

Attribute ID 1 0x08 Identifies the type of MBO attribute.

Attribute Length 1 0x02 Length of the following field in the attribute in octets.

Re-association Delay 2 Variable Indicates the number of seconds that the Wi-Fi Agile Multiband STA shall wait
before trying to (re)associate with the BSS.
The Re-association Delay timer starts when the BTM Request frame containing
the Association Retry Delay attribute is received.

4.3 MBO ANQP-elements

The MBO ANQP-element may be included in ANQP requests and responses as described in section 3.5.1.1. The MBO
ANQP-element follows the definition specified in section 9.4.5.8 Vendor Specific ANQP-element in [1].
Table 22. MBO ANQP-elements

Field Size (Octets) Value (Hex) Description

InfoID 2 56797 As specified in Table 9-271 [1]: ANQP-element definitions (value 56797).

Length 2 Variable Length of the OUI field plus the length of the Vendor Specific content

OUI 3 0x50-6F-9A The OUI is a 3-octet field and is defined in section 9.4.1.32 in [1]. The OUI field
is set to the value used by the Wi-Fi Alliance, (value 0x50-6F-9A)
OUI Type 1 0x12 MBO ANQP vendor specific element ID

Subtype 1 Variable The Subtype field is a 1-octet field whose value identifies the MBO ANQP-
element. Values for the Subtype field are defined in Table 23.

© 2020 Wi-Fi Alliance. All Rights Reserved.

Used with the permission of Wi-Fi Alliance under the terms as stated in this document.
Page 27 of 32
Wi-Fi Agile Multiband Technical Specification v1.5

Field Size (Octets) Value (Hex) Description

Payload Variable Variable Vendor Specific Content field is a variable length field whose content is defined
by the entity identified in the OUI field.

Table 23 defines the MBO ANQP-element subtype values.

Table 23. MBO ANQP-element subtype values

Element Name Subtype value Description (section number)

Reserved 0 N/A

MBO Query List 1 4.3.1

Cellular Data Connection Preference 2 4.3.2

4.3.1 MBO Query List

The MBO Query list provides a list of identifiers of MBO ANQP-elements for which the requesting STA is querying in an
MBO ANQP query. The MBO Query List ANQP-element is included in a GAS Query Request frame. The MBO Query List
ANQP-element shall be used in a GAS Query Request to request MBO ANQP-elements. Both the ANQP Query List [1]
and the MBO Query List may be included in a single GAS Query Request (see the example query in Appendix B).
The format of the MBO Query List payload is provided in Figure 3.

Octets: 1 1 1

MBO ANQP-element Subtype #1 MBO ANQP-element Subtype #2 MBO ANQP-element Subtype #3 (optional)
(optional)

Figure 3. MBO Query List ANQP-element payload format

The value of each MBO ANQP-element Subtype field is a Subtype drawn from Table 23. A Subtype is included in the
MBO Query List element to indicate that the STA device performing the GAS Query Request is requesting that the MBO
ANQP-element corresponding to that Subtype be returned in the GAS Query Response. The Subtypes included in the
MBO Query List element shall be ordered by monotonically increasing Subtype value.

4.3.2 Cellular Data Connection Preference Subtype

The Cellular Data Connection Preference Subtype is a MBO ANQP-element that is used by a Wi-Fi Agile Multiband AP to
provide a Wi-Fi Agile Multiband STA with a preference value to move to cellular data network, equivalent to a BSS
Transition Candidate Preference in the Neighbor Report.
The payload of the Cellular Data Connection Preference Subtype is one octet containing a value as specified in Table 16.

4.3.3 Neighbor Report in ANQP

The Neighbor Report ANQP-element defined in section 9.4.5.19 of [1] shall include the Element ID and the Length fields
in each included Neighbor Report element 9, to allow multiple reports to be parsed correctly.

4.4 WNM-Notification Request frame

The format of WNM-Notification Request frame is defined in section 9.6.14.29 in [1] and is illustrated in Figure 4.

Octets: 1 1 1 1: Variable

9 Section 9.4.5.19 of [1] says: “The Element ID and the Length fields of the Neighbor Report element, as shown in Figure 9-295, are not included”, which
contradicts with the above paragraph. Implementers of Wi-Fi Agile Multiband specification shall disregard the quoted sentence from section 9.4.5.19 of
[[1].

© 2020 Wi-Fi Alliance. All Rights Reserved.

Used with the permission of Wi-Fi Alliance under the terms as stated in this document.
Page 28 of 32
Wi-Fi Agile Multiband Technical Specification v1.5

Category WMN Action Dialog Token Type Optional Subelements

Figure 4. WNM-Notification Request frame format

Where:
The Type field is set to value 0xDD (221 – Vendor Specific) as specified in Table 9-360 in [1].
The Category, WNM Action, and Dialog Token fields are set to values defined in section 9.6.14.29 in [1].
The Optional Subelements field contains one or more Non-preferred Channel Report subelements defined in
section 4.4.1 and/or a Cellular Data Capabilities subelement defined in section 4.4.2.

4.4.1 Non-preferred Channel Report subelement

The format of the Non-preferred Channel Report subelement is illustrated in Table 24. One or more Non-preferred
Channel Report Subelements may be included in Optional Subelements field in WNM-Notification Request frame, as
defined in section 9.6.14.29 in [1]. Each Non-preferred Channel Report Subelement may specify zero or more channels
and their preferences as defined in Table 24.
Table 24. Non-preferred Channel Report subelement

Field Size (Octets) Value (Hex) Description

Subelement ID 1 0xDD The Subelement ID is set to value 0xDD (221 – Vendor Specific), as specified in
Table 9-360 in [1].
Length 1 0x04 or Variable Length of the following fields in the subelement in octets.

OUI 3 0x506F9A The OUI is set to value 0x506F9A, as used by the Wi-Fi Alliance.

OUI Type 1 0x02 The OUI Type is set to value 0x02 as used by the Wi-Fi Alliance for Non-preferred
Channel Report.
Operating Class 1 Variable Operating Class contains an enumerated value from table E-4 in Annex E of [1],
specifying the global operating class in which the Channel List is valid
Channel List Variable Variable The Channel List contains a variable number of octets, where each octet describes a
single channel number.
An empty Channel List field indicates that the indicated Preference applies to all
channels in the Operating Class.
Channel numbering is dependent on Operating Class per Annex E of [1]
Preference 1 0-255 Indicates a preference value for the above set of channels, as defined in Table 9.

Reason Code 1 0-255 Indicates the reason that the Wi-Fi Agile Multiband STA prefers not to operate in this
band/channel, refer to Table 10.

If a Wi-Fi Agile Multiband STA has no non-preferred channels in any Operating Class, the Length field is set to value four
and Operating Class, Channel List, Preference and Reason Code are not present.
Note that Non-preferred Channel Report subelement and Non-preferred Channel Report attribute are two different
structures. Non-preferred Channel Report subelement is used in the WNM-Notification Request frame and Non-preferred
Channel Report attribute is used in (Re)Association frames.

4.4.2 Cellular Data Capabilities subelement

The format of the Cellular Data Capabilities subelement is defined in Table 25. The subelement is used in Optional
Subelements field in WNM-Notification Request frame, as defined in section 9.6.14.29 in [1].

© 2020 Wi-Fi Alliance. All Rights Reserved.

Used with the permission of Wi-Fi Alliance under the terms as stated in this document.
Page 29 of 32
Wi-Fi Agile Multiband Technical Specification v1.5

Table 25. Cellular Data Capabilities subelement

Field Size (Octets) Value (Hex) Description

Subelement ID 1 0xDD The Subelement ID is set to value 0xDD (221 – Vendor Specific), as specified in
Table 9-360 in [1].
Length 1 0x00 or Length of the following fields in the subelement in octets.
Variable
OI 3 0x506F9A The OI is set to value 0x506F9A, as used by the Wi-Fi Alliance.

OUI Type 1 0x03 The OUI Type is set to value 0x03 as used by the Wi-Fi Alliance for Cellular Data
Capabilities.
Cellular Data Connectivity 1 Variable The Cellular Data Connectivity provides information regarding Wi-Fi Agile Multiband
STA’s cellular data capabilities, as defined in Table 10.

Note that Cellular Data Capabilities subelement and Cellular Data Capabilities attribute have two different structures. The
Cellular Data Capabilities subelement is used in the WNM-Notification Request frame and the Cellular Data Capabilities
attribute is used in all other frames.

© 2020 Wi-Fi Alliance. All Rights Reserved.

Used with the permission of Wi-Fi Alliance under the terms as stated in this document.
Page 30 of 32
Wi-Fi Agile Multiband Technical Specification v1.5

Appendix A (Informative) Examples of Non-preferred Channel Report

attribute
A.1 Example 1 of Non-Preferred Channel Report attribute:
Hex String:
00 05 0C 01 06 01 01

Interpretation:
00 – Attribute Id
05 – Length of following fields is 6 octets
51 – operating class 81 from global table from Annex E of [1].
01 06 – channels 1 and 6
01 – above set of channels is at preference 1 (least preferred)
01 – reason for the above preference is collocated interference

A.2 Example 2 of Non-Preferred Channel Report attribute:

Hex String:
00 06 01 28 2C 02 00 B0

Interpretation:
00 – Attribute Id
06 – Length of following fields is 7 octets
73 – operating class 115 from global table from Annex E of [1].
28 2C – channels 40 and 44
02 – above set of channels is at preference 2
00 – reason for the above preference is beacon strength

© 2020 Wi-Fi Alliance. All Rights Reserved.

Used with the permission of Wi-Fi Alliance under the terms as stated in this document.
Page 31 of 32
Wi-Fi Agile Multiband Technical Specification v1.5

Appendix B (Informative) Example GAS Query using ANQP Query List

and MBO Query List
This appendix provides example GAS queries describing how the Advertisement Protocol ANQP is transported in GAS
frames.
Figure 5 illustrates the possibility of including an ANQP Query List and an MBO Query List in a single GAS Initial Request
frame as specified in section 9.6.8.13 [1] including a request for the Neighbor Report and the Cellular Data Preference
ANQP-element.

Octets: 1 1 1 Variable 2 Variable

Category Public Action Dialog Token Advertisement Protocol element Query Request Length Query Request

Figure 5. GAS Initial Request frame (Action frame)

Where:
The value of the Category field is set to 4 (indicating the Public category), per [1].
The value of the Public Action field is set to 10 (for GAS Initial Request), per [1].
The Dialog Token field is used for matching action responses with action requests when there are multiple
concurrent action requests, per [1].
The value of the Advertisement Protocol element uses the Advertisement Protocol ID of 0 (for ANQP), as defined
in [1].
The value of the Query Request length field is set to the total number of octets in the Query Request field.
The Query Request field shown in Figure 6 comprises both the ANQP Query list and the MBO Query List, in which the
details for each ANQP-element are provided.

Octets: 6 10

Query List ANQP-element MBO Query List

Figure 6. Example Query Request field

Figure 7 gives an example of the Query Request field.

Octets: 2 2 2 9 1

ANQP Query List Info ID Length ANQP Query List Information MBO ANQP-element Header MBO ANQP-element Payload

Figure 7. Example Query Request field details

Where:
The value of the ANQP Query List Info ID subfield is set to 256 as per [1].
The value of the ANQP Query List Information subfield is set to 272 (for Neighbor Report).
The MBO ANQP-element header subfield is defined in section 4, with the Subtype field value set to 1 (for MBO
Query list).
The value of the MBO Payload field is set to 2 (indicating Cellular Data Connection Preference), as defined in
section 4.

© 2020 Wi-Fi Alliance. All Rights Reserved.

Used with the permission of Wi-Fi Alliance under the terms as stated in this document.
Page 32 of 32