AFC System to AFC Device Interface

Specification
Version 1.3

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.

© 2022 Wi-Fi Alliance. All Rights Reserved.

Used with the permission of Wi-Fi Alliance under the terms as stated in this document.
AFC System to AFC Device Interface Specification v1.3

Document revision history

Version Date YYYY-MM-DD Remarks

1.0 2021-02-28 Approved Specification

1.1 2021-11-29 Approved Specification, with the following updates:

• Corrected Message Example in section A.1
• Updated Location object (4.2.1.3) and added Elevation object to include AMSL Height
• Revised Revision of Channel Descriptions in sections 4.2.1.12 and 4.2.2.3
• Revised of Rule Set Identifier in sections 4.2.1.2 and 4.2.2.1 and added CertificationId
object section. Updated Annex A.1 accordingly
• Updated Table 19 AvailableSpectrumInquiryResponse object to explicitly state that
frequency ranges for which all emissions are prohibited shall be left out of an available
frequency response message
• Applied editorial changes to Section A.1 to correct mistake in implementing TG endorsed
contribution "AFC Interface Specification Rule Set ID Definition_r4.doc".
• Applied other minor editorial changes.

1.2 2022-04-14 Approved Specification, with the following updates:

• Updated channelCfi descriptions
• Applied clarification on available spectrum; updated References, Tables 3, 6, 19 & 20.
• Updated the footer note to 2022
1.3 2022-07-20 Approved Specification, with the following updates:
• Updated Sections 4.2.2.1 and 4.4 to improve inclusion of both frequency-based and
channel-based requests.

© 2022 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 24
AFC System to AFC Device Interface Specification v1.3

Table of contents
1 INTRODUCTION .......................................................................................................................................................... 5
1.1 References .................................................................................................................................................... 5
1.2 Definitions and acronyms .............................................................................................................................. 5
1.2.1 Shall/should/may/might word usage ................................................................................................ 5
1.2.2 Conventions ..................................................................................................................................... 6
1.2.3 Abbreviations and acronyms ............................................................................................................ 6
1.2.4 Regulatory Definitions ...................................................................................................................... 6
1.2.5 AFC System to AFC Device Interface Definitions ............................................................................ 7
2 ARCHITECTURE .......................................................................................................................................................... 8
3 MESSAGE ENCODING AND TRANSPORT ................................................................................................................ 9
3.1 General.......................................................................................................................................................... 9
3.2 JavaScript Object Notation (JSON) .............................................................................................................. 9
3.3 AFC URL ....................................................................................................................................................... 9
3.4 HTTPS......................................................................................................................................................... 10
3.4.1 HTTP .............................................................................................................................................. 10
3.4.2 TLS ................................................................................................................................................. 10
4 MESSAGE PAYLOAD AND PARAMETER DEFINITIONS ........................................................................................ 11
4.1 General........................................................................................................................................................ 11
4.1.1 Parameter Presence ...................................................................................................................... 11
4.1.2 JSON Data Types .......................................................................................................................... 11
4.2 Message Payloads for Available Spectrum Inquiry .................................................................................... 11
4.2.1 Available Spectrum Inquiry Request message .............................................................................. 11
4.2.2 Available Spectrum Inquiry Response message ........................................................................... 17
4.3 Message Payload for Standalone Vendor Extensions ................................................................................ 20
4.3.1 Standalone Vendor Extension ....................................................................................................... 20
4.4 Standard Response Code definitions ......................................................................................................... 20
APPENDIX A INFORMATIVE MESSAGE EXAMPLES .................................................................................................... 22
A.1 Example of HTTP Payload of Available Spectrum Inquiry Request message and corresponding Available
Spectrum Inquiry Response message ........................................................................................................................ 22

© 2022 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 24
AFC System to AFC Device Interface Specification v1.3

List of tables
Table 1. Abbreviations and Acronyms ........................................................................................................................ 6
Table 2. FCC Definitions ............................................................................................................................................. 6
Table 3. Definitions ..................................................................................................................................................... 7
Table 4. AFC Methods ................................................................................................................................................ 9
Table 5. AvailableSpectrumInquiryRequestMessage object .................................................................................... 11
Table 6. AvailableSpectrumInquiryRequest object ................................................................................................... 12
Table 7. DeviceDescriptor object .............................................................................................................................. 12
Table 8. CertificationId object .................................................................................................................................... 13
Table 9. Location object ............................................................................................................................................ 13
Table 10. Ellipse object ............................................................................................................................................... 14
Table 11. LinearPolygon object................................................................................................................................... 14
Table 12. RadialPolygon object .................................................................................................................................. 14
Table 13. Elevation object ........................................................................................................................................... 15
Table 14. Point object ................................................................................................................................................. 15
Table 15. Vector object ............................................................................................................................................... 16
Table 16. FrequencyRange object .............................................................................................................................. 16
Table 17. Channels object .......................................................................................................................................... 16
Table 18. AvailableSpectrumInquiryResponseMessage object .................................................................................. 17
Table 19. AvailableSpectrumInquiryResponse object ................................................................................................ 17
Table 20. AvailableFrequencyInfo object .................................................................................................................... 18
Table 21. AvailableChannelInfo object ....................................................................................................................... 18
Table 22. Response object ......................................................................................................................................... 19
Table 23. VendorExtension object .............................................................................................................................. 19
Table 24. StandaloneVendorExtension object ............................................................................................................ 20
Table 25. Response Code definitions ......................................................................................................................... 20
Table 26. SupplementalInfo object definitions ............................................................................................................ 21

List of figures
Figure 1. Reference Architecture of AFC System ........................................................................................................ 8

© 2022 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 24
AFC System to AFC Device Interface Specification v1.3

1 Introduction
This document is the technical specification for Wi-Fi Alliance® AFC System to AFC Device Interface, which defines a
messaging protocol and transport for the interface between an AFC System and an AFC Device. This specification
defines the architecture, protocols, and functionality for entities that support AFC System to AFC Device Interface. AFC
Devices that might support this interface include, for example, Standard Power Access Points, proxies of Standard Power
Access Points, and Fixed Client Devices.

1.1 References
Knowledge of the documents listed in this section is required for understanding this 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] IETF RFC-2616, “Hypertext Transfer Protocol -- HTTP/1.1”, June 1999

[2] NGA.STND.0036_1.0.0_WGS84 (Version 1.0.0 - July 8, 2014): Department of Defense (DoD) World Geodetic
System (WGS) 1984

[3] IETF RFC-8259, "The JavaScript Object Notation (JSON) Data Interchange Format", December 2017

[4] FCC 20-51, “Report and Order and Further Notice of Proposed Rulemaking,” ET Docket 18-295 Unlicensed Use of
the 6 GHz Band, April 24, 2020

[5] IEEE P802.11ax/D8.0, "IEEE Draft 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 Amendment Enhancements for High
Efficiency WLAN, Nov 2020

[6] IETF RFC-5246, "The Transport Layer Security (TLS) Protocol Version 1.2", August 2008

[7] IETF RFC-8446, "The Transport Layer Security (TLS) Protocol Version 1.3", August 2018

[8] IETF RFC-3647, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework",
November 2003

[9] 47 CFR § Section 15.407 - General technical requirements, https://www.ecfr.gov/cgi-bin/text-

idx?mc=true&node=se47.1.15_1407&rgn=div8

1.2 Definitions and acronyms

1.2.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 AFC
Interface Technical 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 AFC Interface Technical 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.

© 2022 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 24
AFC System to AFC Device Interface Specification v1.3

1.2.2 Conventions
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 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 specification shall not use a reserved code value.

1.2.3 Abbreviations and acronyms

Table 1 defines the abbreviations and acronyms used throughout this document. Some 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 1. Abbreviations and Acronyms

Acronyms Definition

AFC Automated Frequency Coordination

AGL Above Ground Level

AP Access Point

EIRP Equivalent Isotropically Radiated Power (in units of dBm)

HTTP Hypertext Transfer Protocol

HTTPS HTTP plus TLS

JSON JavaScript Object Notation

NRA National Regulatory Authority

PSD Power Spectral Density

TLS Transport Layer Security

URL Uniform Resource Locator

1.2.4 Regulatory Definitions

The terms defined by National Regulatory Authorities are described in this section.
The terms defined by the FCC [4] described in Table 2 are used in this document.

Table 2. FCC Definitions

Term Definition

Access Point (AP) A U-NII transceiver that operates either as a bridge in a peer-to-peer connection or as a
connector between the wired and wireless segments of the network.
NOTE: For the purpose of this document, the terms “Access Point” or “AP” refer to
those operating in the AFC-required bands (i.e., 5.925-6.425 GHz and 6.525-6.875 GHz
bands). AFC-required bands are subject to the adopted rules.
Automated Frequency Coordination (AFC) System A system that automatically determines and provides lists of which frequencies are
available for use by access points operating in the 5.925-6.425 GHz and 6.525-6.875
GHz bands.
Client Device A U-NII device whose transmissions are generally under the control of an access point
and that is not capable of initiating a network.

© 2022 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 24
AFC System to AFC Device Interface Specification v1.3

Term Definition

Fixed Client Device A client device intended as customer premise equipment that is permanently attached to
a structure, operates only on channels provided by an AFC, has a geolocation
capability, and complies with antenna pointing angle requirements.

1.2.5 AFC System to AFC Device Interface Definitions

The definitions in Table 3 are applicable to this specification.
Table 3. Definitions

Term Definition

AFC Device Generic name of entities accessing an AFC System.

NOTE: As defined in this section, such entity includes Standalone AP and Proxy
representing one or more Non-Standalone APs, and Fixed Client Devices.
AFC URL The Uniform Resource Locator address used by AFC Devices to communicate with an
AFC System
Available Spectrum A radio frequency range or set of ranges in which a Standalone AP, Non-Standalone
AP, or Fixed Client Device can operate at its location within the power limits provided by
the AFC System, provided it does not exceed the lowest applicable regulatory limits for
in-band emissions and complies with regulatory limits for out-of-band emissions. For
example, in the United States, in-band (5925-7125 MHz) power spectral density shall be
suppressed by at least 40 dB relative to maximum in-channel power spectral density,
and out-of-band emissions (below 5925 MHz and above 7125 MHz) shall not exceed -
27 dBm/MHz (47 CFR 15.407(b)(6) and (7)) [9].
Channel Center Frequency Index Based on Annex E of [5], the channel number from either the channel set column or the
channel center frequency index column in Table E-4, which can be used to calculate the
channel’s center frequency.
Non-Standalone AP A Standard Power Access Point which does not communicate with the AFC System
directly and operates based on the information of Available Spectrum provided by the
AFC System via the Proxy.
Proxy An entity engaging in communications with the AFC System on behalf of one or more
Non-Standalone APs.
Regulatory Database A database server that is managed by an NRA and that maintains the information
necessary for the calculation of Available Spectrum.
Standalone AP A Standard Power Access Point which communicates with the AFC System directly and
operates based on the information of Available Spectrum provided by the AFC System.
Global Operating Class Operating class as used in Table E-4 of Annex E of [5]

© 2022 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 24
AFC System to AFC Device Interface Specification v1.3

2 Architecture
This document defines the signaling protocols for the interface shown in blue in the reference architecture in Figure 1.
This architecture diagram shows three examples of AFC Devices: a Proxy, a Standalone AP, and a Fixed Client Device.

Regulatory
AFC System
Database

AFC Device 1

Proxy

AFC Device 2 AFC Device 3

Non- Non-
Fixed Client
Standalone AP Standalone AP Standalone AP
Device
1 2

Client Device 1 Client Device 2 Client Device 3

Figure 1. Reference Architecture of AFC System

© 2022 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 24
AFC System to AFC Device Interface Specification v1.3

3 Message encoding and transport

3.1 General
All the messages specified in this document are JSON objects and shall be transported by using HTTPS (HTTP plus TLS)
as specified in this section.

3.2 JavaScript Object Notation (JSON)

All the messages shall be generated by using JSON [3].
NOTE: Unicode characters are used and have a default encoding of UTF-8.
A message shall contain one JSON object, which is either a Request message, Response message or a Standalone
Vendor Extension as defined in this clause. When an AFC Device sends a message to the AFC System, one or more
requests may be aggregated together in the array of Requests contained in the Request message. In response to this
request, the AFC System shall include the same number of responses aggregated in the array of Responses in the
Response message sent to the requesting AFC Device.
A field value of JSON object may be one of the JSON data types: string, number, boolean, object, or an array of one of
those types. If a field is an object, a name for the object is given and a separate table describes fields in the object. An
AFC System and AFC Device shall ignore any unknown field within the JSON object. When an optional field is not used, it
shall be omitted. See also section 4 for more details.

3.3 AFC URL

All the messages specified in this document shall be transported between an AFC Device and an AFC System located at
an AFC URL. An AFC URL has the following format:

Format: $BASE_URL/ $METHOD

• $BASE_URL consists of at least the AFC System host name and may include one or more additional paths
• $METHOD corresponds to a pair of a request and a response message defined in section 4. AFC method names
are listed in Table 4 Vendor(s) may define additional path(s) following $METHOD if $METHOD is equal to
vendorExtensions
Table 4. AFC Methods

$METHOD Request message Response message

availableSpectrumInquiry Available Spectrum Inquiry Request Available Spectrum Inquiry
message Response message
vendorExtensions Standalone Vendor Extension message optionally defined by vendor(s). Vendor
specific version if it exists, may be indicated in this message.

An Available Spectrum Inquiry Request message is sent by an AFC Device to an AFC System for retrieval of Available
Spectrum information, and an Available Spectrum Inquiry Response message is sent by an AFC System responding to
the Available Spectrum Inquiry Request message sent by the AFC Device.
Support for vendor extensions is optional, and the format is defined by the vendor. Such definitions are outside the scope
of this document.

© 2022 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 24
AFC System to AFC Device Interface Specification v1.3

3.4 HTTPS
3.4.1 HTTP
HTTP version number shall be 1.1 as specified in [1], or a later version.
The HTTP POST method shall be used for all requests from the AFC Device to the AFC System.
HTTP request message shall include at least the following headers:

• host: <AFC System host name included in $BASE_URL>

• contentType: application/json
HTTP response message shall include at least the following headers:

• Date: <AFC System time, upon which all AFC System to AFC Device interface timers are based>
AFC shall respond with HTTP status code 404 (NOT FOUND) if it finds that invalid method is specified in the URL.
AFC shall respond with HTTP status code 400 (BAD REQUEST) if any of the following are true:

• HTTP request header does not include required header fields specified in this section
• HTTP Payload contains neither an AvailableSpectrumInquiryRequestMessage nor a StandaloneVendorExtension
object

3.4.2 TLS
TLS shall be performed for AFC authentication by the AFC Device, prior to any communication. TLS-v1.2 as specified in
[6] or newer versions of TLS (e.g., as specified in [7]) shall be used to perform authentication. Older versions of TLS shall
not be used.
During the TLS message exchange, the AFC Device shall authenticate an AFC System according to the procedures
defined in [8]. An AFC Device that is unable to successfully authenticate an AFC System shall abort the TLS connection
establishment procedure.
Subsequent to successful authentication, the AFC Device and AFC System shall negotiate a ciphersuite to use for
encrypting all communications between the two entities. The AFC Device and the AFC System shall both support at least
the following ciphersuites:

• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Stronger ciphersuites may be negotiated and used if both sides support them.
An AFC Device which is unable to successfully setup such an encrypted connection with an AFC System shall abort the
TLS connection establishment procedure.

© 2022 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 24
AFC System to AFC Device Interface Specification v1.3

4 Message payload and Parameter Definitions

4.1 General
4.1.1 Parameter Presence
Presence of a parameter field is defined by using the following indicators:
• Required (R): The field shall always be included within the object it belongs
• Conditionally-Required (CR): The field shall be included within the object it belongs to if the specified condition is
met
• Conditionally-Optional (CO): The field may be included within the object it belongs to if and only if the specified
condition is met
• Optional (O): The field may be included at any time within the object it belongs to

4.1.2 JSON Data Types

This document uses three primitive JSON types (respectively, string, number and boolean) and two structured types
(JSON object and array) as defined in RFC-8259 [3].

4.2 Message Payloads for Available Spectrum Inquiry

4.2.1 Available Spectrum Inquiry Request message
The HTTP Payload of Available Spectrum Inquiry Request message is represented by
AvailableSpectrumInquiryRequestMessage object defined in Table 5.
Table 5. AvailableSpectrumInquiryRequestMessage object

Fields Presence Descriptions

NAME: version R The version number of the AvailableSpectrumInquiryRequest.
DATA TYPE: string The string shall be parsed as two non-negative integers
separated by a decimal point, for example, n.m. The integer
value to the left of the decimal point (n) is the major version
number, and the integer value to the right of the decimal point
(m) is the minor version number.
NAME: availableSpectrumInquiryRequests R This field represents Available Spectrum Inquiry Request for
DATA TYPE: array of object: one or more APs or Fixed Client Devices. (4.2.1.1)
AvailableSpectrumInquiryRequest
NAME: vendorExtensions O This field contains optional vendor extensions. (4.2.2.5)
DATA TYPE: array of object: VendorExtension

4.2.1.1 AvailableSpectrumInquiryRequest object

The AFC System can determine Available Spectrum based on PSD across a range of frequencies, or based on EIRP for
a list of Channels, or both. The AvailableSpectrumInquiryRequest object shown in Table 6 includes at least one of
inquiredFrequencyRange or inquiredChannels objects.
If inquiredFrequencyRange is specified, the request is for a spectrum availability response provided by the AFC System
on the basis of frequency. If inquiredChannels is specified, the request is for a spectrum availability response provided on
the basis of channels. If both inquiredFrequencyRange and inquiredChannels are specified, the request is for a spectrum
availability response provided by the AFC System both on the basis of frequency, and on the basis of channels.

© 2022 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 24
AFC System to AFC Device Interface Specification v1.3

Table 6. AvailableSpectrumInquiryRequest object

Fields Presence Descriptions

NAME: requestId R Unique ID to identify an instance of an Available Spectrum
DATA TYPE: string Inquiry request. The value shall be unique within the request
message. See example in Appendix A
NAME: deviceDescriptor R This field contains the information of an AP or Fixed Client
DATA TYPE: object: DeviceDescriptor Device. (4.2.1.2)

NAME: location R This field describes the geographic area within which the AP or
DATA TYPE: object: Location Fixed Client Device is located, including location uncertainty.
(4.2.1.3)
NAME: inquiredFrequencyRange CR This field contains one or more frequency ranges for which the
DATA TYPE: array of object: FrequencyRange AP or Fixed Client Device is requesting spectrum availability.
One or both of inquiredFrequencyRange and inquiredChannels
shall be present. If inquiredFrequencyRange is present, it
indicates that the AFC System is to provide Available Spectrum
information on the basis of frequency. (4.2.1.11)
NAME: inquiredChannels CR This field contains one or more lists of channels for which the
DATA TYPE: array of object: Channels AP or Fixed Client Device is requesting spectrum availability.
One or both of inquiredFrequencyRange and inquiredChannels
shall be present. If inquiredChannels is present, it indicates that
the AFC System is to provide Available Spectrum information on
the basis of channels. (4.2.1.12)
NAME: minDesiredPower O This field contains the minimum desired EIRP in units of dBm.
DATA TYPE: number This field is optionally present in a query by inquiredChannels;
otherwise, it is absent. If a query by inquiredChannels is
performed and this field is absent, the AFC System shall provide
a response for all inquiredChannels which are available for use
at any power. Otherwise, if the minDesiredPower is present, the
AFC System shall provide all the inquired channels available for
use at or above the defined minDesiredPower.
NAME: vendorExtensions O This field contains optional vendor extensions. (4.2.2.5)
DATA TYPE: array of object: VendorExtension

4.2.1.2 DeviceDescriptor object

The DeviceDescriptor object fields are defined in Table 7.

Table 7. DeviceDescriptor object

Fields Presence Descriptions

NAME: serialNumber R This field contains the device serial number of an AP or Fixed Client
DATA TYPE: string Device. See example in Appendix A

NAME: certificationId R This field represents the certification IDs of an AP or Fixed Client
DATA TYPE: array of object: CertificationId Device.

NAME: rulesetIds R This field contains the identifiers of the regulatory rules supported by
DATA TYPE: array of string an AP or Fixed Client Device.
Acceptable values are:
• US_47_CFR_PART_15_SUBPART_E
Allowed field values depend on the rules of each National Regulatory
Authority.

© 2022 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 24
AFC System to AFC Device Interface Specification v1.3

4.2.1.3 The CertificationId object

The CertificationId object fields are described in Table 8.

Table 8. CertificationId object

Fields Presence Descriptions

NAME: nra R This field represents the NRA from which the certification ID of an
DATA TYPE: string AP or Fixed Client Device has been obtained.
Acceptable values are:
FCC
NAME: id R This field represents the certification ID of an AP or Fixed Client
DATA TYPE: string Device.

4.2.1.4 Location object

The Location object fields are defined in Table 9.

Table 9. Location object

Fields Presence Descriptions

NAME: ellipse CR Description of the geographic area within which the AP or Fixed
DATA TYPE: object: Ellipse Client Device may operate, including location uncertainty, described
as an ellipse defined by the geographic coordinate of its center and
the lengths of its major and minor semi-axes (4.2.1.5). This field
shall not be included if either linearPolygon field or radialPolygon
field is included in this object. If neither linearPolygon field nor
radialPolygon field is included in this object, this field shall be
included.
NAME: linearPolygon CR Description of the geographic area within which the AP or Fixed
DATA TYPE: object: LinearPolygon Client Device is located, including location uncertainty, described as
a polygon defined by an array of the geographic coordinates of its
vertices (4.2.1.6). This field shall not be included if either ellipse field
or radialPolygon field is included in this object. If neither ellipse field
nor radialPolygon field is included in this object, this field shall be
included.
NAME: radialPolygon CR Description of the geographic area within which the AP or Fixed
DATA TYPE: object: RadialPolygon Client Device is located, including location uncertainty, described as
a polygon defined by its center and an array of vectors (4.2.1.7).
This field shall not be included if either ellipse field or linearPolygon
field is included in this object. If neither ellipse field nor linearPolygon
field is included in this object, this field shall be included.
NAME: elevation R This field indicates the height, reference frame, and vertical
DATA TYPE: object: Elevation uncertainty of the AP or Fixed Client Device antenna.

NAME: indoorDeployment O This field indicates whether the deployment of the AP or Fixed Client
DATA TYPE: number Device is located indoors, outdoor, or is unknown
• 0: unknown.
• 1: indoor.
• 2: outdoor.

© 2022 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 24
AFC System to AFC Device Interface Specification v1.3

4.2.1.5 Ellipse object

The Ellipse object fields are defined in Table 10.

Table 10. Ellipse object

Fields Presence Descriptions

NAME: center R This field represents the geographic coordinates of the center point
DATA TYPE: object: Point of an ellipse within which the AP or Fixed Client Device is located.

NAME: majorAxis R This field represents the length of the major semi axis of an ellipse
DATA TYPE: number within which the AP or Fixed Client Device is located.
The value is a positive integer in meters.
NAME: minorAxis R This field represents the length of the minor semi axis of an ellipse
DATA TYPE: number within which the AP or Fixed Client Device is located.
The value is a positive integer in meters.
NAME: orientation R This field represents the orientation of the majorAxis field in decimal
DATA TYPE: number degrees, measured clockwise from True North.
The allowed range is from 0 to 180.

4.2.1.6 LinearPolygon object

The LinearPolygon object fields are described in Table 11.

Table 11. LinearPolygon object

Fields Presence Descriptions

NAME: outerBoundary R This field represents the vertices of a polygon within which the AP or
DATA TYPE: array of object: Point Fixed Client Device is located.
At least three and no more than 15 unique vertices may be used to
define the polygon. Connecting lines between successive vertices
may not cross any other connecting lines between successive
vertices. The distance between successive vertices should not
exceed 130 km.

4.2.1.7 RadialPolygon object

The RadialPolygon object fields are described in Table 12.

Table 12. RadialPolygon object

Fields Presence Descriptions

NAME: center R This field represents the geographic coordinates of the center point
DATA TYPE: object: Point of a polygon within which the AP or Fixed Client Device is located.

NAME: outerBoundary R This field represents the vertices of a polygon within which the AP or
DATA TYPE: array of object: Vector Fixed Client Device is located.
At least three and no more than 15 unique vertices may be used to
define the polygon. Connecting lines between successive vertices
may not cross any other connecting lines between successive
vertices. The distance between successive vertices should not
exceed 130 km.

© 2022 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 24
AFC System to AFC Device Interface Specification v1.3

4.2.1.8 Elevation object

The Elevation object fields are described in Table 12

Table 13. Elevation object

Fields Presence Descriptions

NAME: height R This field represents the height of the AP or Fixed Client Device
DATA TYPE: number antenna in meters.
When the value of heightType field is “AGL”, the value of this field
shall be given relative to local ground level.
When the value of heightType field is “AMSL”, the value of this field
shall be given with respect to WGS84 datum.
NAME: heightType R This field represents the reference level for the value of the height
DATA TYPE: string field.
The allowed values are as follows:
“AGL”: Above Ground Level. Antenna height as measured relative to
the local ground level.
“AMSL”: Above Mean Sea Level. Antenna height as measured with
respect to WGS84 datum.
NAME: verticalUncertainty R This field indicates the vertical distance above and below the value
DATA TYPE: number of the height field within which the AP or Fixed Client Device is
located.
This value is a positive integer in meters.

4.2.1.9 Point object

The Point object fields are described in Table 14.

Table 14. Point object

Fields Presence Descriptions

NAME: longitude R This field represents longitude of the AP or Fixed Client Device
DATA TYPE: number location in decimal degrees. The AFC System shall assume values
in this field to have 6 decimal places of precision and shall treat the
Point object as a mathematical point with no dimensional attributes.
The precision to which this value is specified shall not be interpreted
as an indication of location uncertainty.
The allowed range is from -180 to +180. Positive values represent
longitudes east of the prime meridian; negative values west of the
prime meridian.
The value shall be relative to the WGS 84 datum [2].
NAME: latitude R This field represents latitude of the AP or Fixed Client Device
DATA TYPE: number location in decimal degrees. The AFC System shall assume values
in this field to have 6 decimal places of precision and shall treat the
Point object as a mathematical point with no dimensional attributes.
The precision to which this value is specified shall not be interpreted
as an indication of location uncertainty.
The allowed range is from -90 to +90. Positive values represent
latitudes north of the equator; negative values south of the equator.
The value shall be relative to the WGS 84 datum [2].

© 2022 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 24
AFC System to AFC Device Interface Specification v1.3

4.2.1.10 Vector object

The Vector object fields are described in Table 15.

Table 15. Vector object

Fields Presence Descriptions

NAME: length R This field represents a distance in meters from a specified Point
DATA TYPE: number object.

NAME: angle R This field represents the direction of a vector in decimal degrees,
DATA TYPE: number measured clockwise from True North.
The allowed range is from 0 to 360.

4.2.1.11 FrequencyRange object

The FrequencyRange object fields are described in Table 16.

Table 16. FrequencyRange object

Fields Presence Descriptions

NAME: lowFrequency R This field represents the lowest frequency of the frequency range in
DATA TYPE: number MHz.
The value shall be an integer.
NAME: highFrequency R This field represents the highest frequency of the frequency range in
DATA TYPE: number MHz.
The value shall be an integer.

4.2.1.12 Channels object

The Channels object fields are described in Table 17.

Table 17. Channels object

Fields Presence Descriptions

NAME: globalOperatingClass R This field is the global operating class used to define the channel
DATA TYPE: number center frequency indices and operating bandwidth. It may refer to the
global operating class indices defined in Annex E of [5] or to another
unique reference defined by the vendor.
NAME: channelCfi O This field is the list of channel center frequency indices for which
DATA TYPE: array of number spectrum availability is being queried. If no value is provided, the
request is for spectrum availability for all center frequency indices for
the given globalOperatingClass for channels that are entirely
contained within the bands being coordinated by AFC System.

© 2022 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 24
AFC System to AFC Device Interface Specification v1.3

4.2.2 Available Spectrum Inquiry Response message

The HTTP Payload of Available Spectrum Inquiry Response message is represented by
AvailableSpectrumInquiryResponseMessage object defined in Table 18.
Table 18. AvailableSpectrumInquiryResponseMessage object

Fields Presence Descriptions

NAME: version R The version number of the AvailableSpectrumInquiryRequest.
DATA TYPE: string The string shall be parsed as two non-negative integers
separated by a decimal point, for example, n.m. The integer
value to the left of the decimal point (n) is the major version
number, and the integer value to the right of the decimal point
(m) is the minor version number.
NAME: availableSpectrumInquiryResponses R This field contains Available Spectrum Inquiry Responses for
DATA TYPE: array of object: one or more APs or Fixed Client Devices.
AvailableSpectrumInquiryResponse
NAME: vendorExtensions O This field contains optional vendor extensions. (4.2.2.5)
DATA TYPE: array of object: VendorExtension

4.2.2.1 AvailableSpectrumInquiryResponse object

The AvaiableSpectrumInquiryResponse object fields are described in Table 19.

Table 19. AvailableSpectrumInquiryResponse object

Fields Presence Descriptions

NAME: requestId R Unique ID to identify an instance of an Available Spectrum Inquiry
DATA TYPE: string request. The value shall be same as provided in the corresponding
AvailableSpectrumInquiryRequest object.
NAME: rulesetId DATA R This field identifies the regulatory rules used by the AFC System to
TYPE: string determine spectrum availability.
Acceptable values are:
• US_47_CFR_PART_15_SUBPART_E
Allowed field values depend on the rules of each National Regulatory
Authority.
NAME: availableFrequencyInfo CR This field contains zero or more available frequency ranges and their
DATA TYPE: array of object: AvailableFrequencyInfo corresponding maximum EIRP levels. To protect incumbents,
different maximum EIRP levels could be necessary in different sub-
portions of the requested frequency range(s), therefore an array of
AvailableFrequencyInfo objects is supported.
This field shall be included if and only if availability was requested on
a frequency basis, and the AFC System supports frequency-based
requests, and the response code indicates SUCCESS. (4.2.2.2)
Any frequency range for which all emissions are prohibited (for
example, due to an exclusion zone) shall be excluded from the
response. It is the responsibility of the AP or Fixed Client Device to
configure itself, based on the regulatory spectral emission mask,
such as to ensure compliance with regulatory limits for emissions in
adjacent frequencies, as detailed in the definition of Available
Spectrum.
NOTE: If the array size is zero, it indicates that none of the
requested frequency ranges are available for the AP or Fixed Client
Device.
NAME: availableChannelInfo CR This field contains zero or more available channels and their
DATA TYPE: array of object: AvailableChannelInfo corresponding maximum EIRP levels. (4.2.2.3) To protect
incumbents, different maximum EIRP levels could be necessary on

© 2022 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 24
AFC System to AFC Device Interface Specification v1.3

Fields Presence Descriptions

different channels; therefore an array of AvailableChannelInfo
objects is supported.
This field shall be included if and only if availability was requested on
a channel basis, and the AFC System supports channel-based
requests, and the response code indicates SUCCESS.
Any requested channel that overlaps any frequency range for which
all emissions are prohibited (for example, due to an exclusion zone)
shall be excluded from the response.
NOTE: If the array size is zero, it indicates that none of the
requested channels are available for the AP or Fixed Client Device.
NAME: availabilityExpireTime CR This field contains the time when the spectrum availability specified
DATA TYPE: string in the response expires.
This field shall be included if and only if the Response Code
definitions indicates SUCCESS.
The string value shall be represented with UTC and conformant with
the following format:
FORMAT: YYYY-MM-DDThh:mm:ssZ
NAME: response R This field contains information on the outcome of the Available
DATA TYPE: object: Response Spectrum Inquiry. (4.2.2.4)

NAME: vendorExtensions O This field contains optional vendor extensions. (4.2.2.5)

DATA TYPE: array of object: VendorExtension

NOTE: If both inquiredFrequencyRange and inquiredChannels are present in the request, and the AFC System supports
both frequency-based and channel-based requests, both availableFrequencyInfo and availableChannelInfo are present in
an AvailableSpectrumInquiryResponse object that indicates SUCCESS. The object provides spectrum availability
determined on the basis of frequency, and separately, on the basis of channels.

4.2.2.2 AvailableFrequencyInfo object

The AvaiableFrequencyInfo object fields are described in Table 20.

Table 20. AvailableFrequencyInfo object

Fields Presence Descriptions

NAME: frequencyRange R This field contains a frequency range of the Available Spectrum
DATA TYPE: object: FrequencyRange information. (4.2.1.11)

NAME: maxPsd R This field contains the maximum permissible EIRP available in any
DATA TYPE: number one MHz bin within the frequency range specified by the
frequencyRange object. The limit is expressed as a power spectral
density with units of dBm per MHz. See example in Appendix A

4.2.2.3 AvailableChannelInfo object

Table 21. AvailableChannelInfo object

Fields Presence Descriptions

NAME: globalOperatingClass R This field is the global operating class used to define the channel
DATA TYPE: number center frequency indices and operating bandwidth. It may refer to the
global operating class indices defined in Annex E of [5] or to another
unique reference defined by the vendor.
NAME: channelCfi R This field is the list of channel center frequency indices which are
DATA TYPE: array of number available for use.

© 2022 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 24
AFC System to AFC Device Interface Specification v1.3

NAME: maxEirp R This field is the maximum permissible EIRP in units of dBm available
DATA TYPE: array of number for each of the channels specified in the channelCfi list, in the same
order. In addition, in any portion of the channel, the conducted PSD
plus the maximum antenna gain cannot exceed the maxEirp divided
by the channel width defined by the globalOperatingClass.

4.2.2.4 Response object

Table 22. Response object

Fields Presence Descriptions

NAME: responseCode R This field contains the type of the response.
DATA TYPE: number The value shall be integer and allowed values are shown in Table
25.
NAME: shortDescription O This field contains a short description related to the result indicated
DATA TYPE: string by the responseCode field.
The value may be a human-readable string. (Table 25)
NAME: supplementalInfo O This field contains supplemental information that can help resolve
DATA TYPE: object: SupplementalInfo failures. (Table 26)

4.2.2.5 VendorExtension object

Table 23. VendorExtension object

Fields Presence Descriptions

NAME: extensionId R This field identifies the vendor and field type of a vendor extension.
DATA TYPE: string The format and content of the extensionId field is defined by the
vendor.
NAME: parameters R This field (4.3) contains the payload as specified by the vendor
DATA TYPE: any extension identified by the extensionId field. It may be defined using
any JSON primitive or structured data type as described in section
4.1.2.

© 2022 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 24
AFC System to AFC Device Interface Specification v1.3

4.3 Message Payload for Standalone Vendor Extensions

Vendor extension messaging may be supported in standalone mode, apart from a spectrum inquiry request or response.
The high-level format is generic and supports communications in AFC-System-to-AFC-Device and AFC-Device-to-AFC-
System directions, as defined by the vendor. Vendor extension messaging is optional, but if used, certain fields may be
required by the vendor.

4.3.1 Standalone Vendor Extension

The Standalone Vendor Extension message is a free-formatted message generated by using at least
StandaloneVendorExtension object as defined in Table 24.

Table 24. StandaloneVendorExtension object

Fields Presence Descriptions

NAME: vendorExtensions R This field contains vendor extensions. (4.2.2.5)
DATA TYPE: array of object: VendorExtension

4.4 Standard Response Code definitions

Table 25 defines the Response Code values. Response Codes -1 and 0 are mandatory and shall be supported by all AFC
Systems and AFC Devices. Response Codes provided in ranges 100-199 and 300-399 are optional.
NOTE: Additional vendor-specific Response Codes may be supported, but their definition is outside the scope of this
document.
Response Codes are defined as follows:

• -1: General Failure

• 0: SUCCESS
• 100 – 199: General errors related to the protocol
• 300 – 399: Error events specific to message exchanges for the Available Spectrum Inquiry
Supplemental vendor specific extension Response Codes are outside the scope of this document and are expected to be
handled inside of the Vendor Specific Extension construct (4.3.1 Standalone Vendor Extension).
Table 25. Response Code definitions

Response
Presence Description
Code value
-1 R Name: GENERAL FAILURE
Interpretation Non-specified failure
Other Information:
0 R Name: SUCCESS
Interpretation: The request is approved by the AFC System.
Other Information: None
100 O Name: VERSION_NOT_SUPPORTED
Interpretation: Incompatible interface version number. The AFC System and/or the AFC Device do not
support the indicated interface version.
Other Information: The communication can be attempted again using a different version number. In the case of
an AFC Device attempting to communicate with an AFC System, communications with the
same version, but a different AFC System, could be attempted.

101 O Name: DEVICE_DISALLOWED

© 2022 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 24
AFC System to AFC Device Interface Specification v1.3

Response
Presence Description
Code value
Interpretation: This specific device as identified by the combination of its FCC ID and unique
manufacturer's serial number is not allowed to operate under AFC System control due to
regulatory action or other action.
Other Information: None
102 O Name: MISSING_PARAM
Interpretation: One or more fields required to be included in the request are missing.
Other Information: The supplementalInfo field shall carry a list of missing parameter names.

103 O Name: INVALID_VALUE

Interpretation: One or more fields have an invalid value.
Other Information: The supplementalInfo field shall carry a list of the names of the fields set to invalid value.
106 O Name: UNEXPECTED_PARAM
Interpretation: Unknown parameter found, or conditional parameter found, but condition is not met.
Other Information: The supplementalInfo field shall carry a list of unexpected parameter names.

300 O Name: UNSUPPORTED_SPECTRUM

Interpretation: The frequency range indicated in the Available Spectrum Inquiry Request message is at
least partially outside of the frequency band under the management of the AFC System
(e.g., 5.925-6.425 GHz and 6.525-6.875 GHz bands in the US).
Other Information: None
301 O Name: UNSUPPORTED_BASIS
Interpretation: The AFC System does not support any of the bases for determining spectrum availability
indicated in the request.
Other Information: None

Table 26 defines the SupplementalInfo object, which may be attached to some responseCode values.
Table 26. SupplementalInfo object definitions

Fields Presence Descriptions

NAME: missingParams CR This field contains a list of names of missing parameter(s).
DATA TYPE: array of string This field shall be included if and only if the response code indicates
MISSING_PARAM.
NAME: invalidParams CR This field contains a list of names of parameters with invalid values.
DATA TYPE: array of string This field shall be included if and only if the response code indicates
INVALID_VALUE.
NAME: unexpectedParams CR This field contains a list of names of unexpected parameters.
DATA TYPE: array of string This field shall be included if and only if the response code indicates
UNEXPECTED_PARAM.

© 2022 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 24
AFC System to AFC Device Interface Specification v1.3

Appendix A Informative Message Examples

A.1 Example of HTTP Payload of Available Spectrum Inquiry Request message and
corresponding Available Spectrum Inquiry Response message
The following JSON object is an example of an Available Spectrum Request message for an AP. The AP inquires regarding
spectrum availability on both a frequency and channel basis.

In this example request scenario, the AP queries spectrum availability on a frequency basis throughout U-NII 5. It also
requests channel availability for all 80 MHz channels in U-NII 5 & 7, and for 160 MHz channels in U-NII 5 only.

{
"version" : "1.1",
"availableSpectrumInquiryRequests":
[
{
"requestId": "11235813",
"deviceDescriptor":
{
"serialNumber": "ABCDEFG",
"certificationId":
[
{
"nra": "FCC",
"id": "EFGHIJK"
}
],
"rulesetIds": ["US_47_CFR_PART_15_SUBPART_E"]
},
"location":
{
"ellipse":
{
"center":
{
"longitude": -122.984157,
"latitude": 37.425056
},
"majorAxis": 100,
"minorAxis": 50,
"orientation": 70
},
"elevation":
{
"height": 3.0,
"heightType": "AGL",
"verticalUncertainty": 2
},
"indoorDeployment": 2
},
"inquiredFrequencyRange":
[
{
"lowFrequency": 5925,
"highFrequency": 6425
}
],
"inquiredChannels":
[

© 2022 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 24
AFC System to AFC Device Interface Specification v1.3

{
"globalOperatingClass": 133
},
{
"globalOperatingClass" : 134,
"channelCfi": [15, 47, 79]
}
],
"minDesiredPower": 24
}
]
}

The following JSON object is an example of an Available Spectrum Response message that responds to the Available
Spectrum Request message above.

The query results below are based on a scenario in which the AP has three FS channels in U-NII 5 & 7 to contend with:
6020 - 6050 MHz with 116 dB of total path loss; 6360 - 6390 MHz with 91 dB of total path loss; and 6680-6690 MHz with
129 dB of total path loss.

NOTE: Total path loss includes all factors, including BEL, propagation loss, FS antenna discrimination, etc.

{
"version": "1.1",
"availableSpectrumInquiryResponses":
[
{
"requestId": "11235813",
"rulesetId": "US_47_CFR_PART_15_SUBPART_E",
"availableFrequencyInfo" :
[
{
"frequencyRange" :
{
"lowFrequency" : 5925,
"highFrequency" : 6020
},
"maxPsd" : 23.0
},
{
"frequencyRange" :
{
"lowFrequency" : 6020,
"highFrequency" : 6050
},
"maxPsd" : 1.0
},
{
"frequencyRange" :
{
"lowFrequency" : 6050,
"highFrequency" : 6360
},
"maxPsd" : 23.0
},
{
"frequencyRange" :
{
"lowFrequency" : 6360,
"highFrequency" : 6390

© 2022 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 24
AFC System to AFC Device Interface Specification v1.3

},
"maxPsd" : -24.0
},
{
"frequencyRange" :
{
"lowFrequency" : 6390,
"highFrequency" : 6425
},
"maxPsd" : 23.0
}
],
"availableChannelInfo" :
[
{
"globalOperatingClass" : 133,
"channelCfi" : [7, 39, 55, 71, 135, 151, 167],
"maxEirp" : [27.8, 36, 36, 36, 36, 33.0, 36]
},
{
"globalOperatingClass" : 134,
"channelCfi" : [47],
"maxEirp" : [36]
}
],
"availabilityExpireTime" : "2020-11-03T13:34:05Z",
"response" :
{
"responseCode" : 0,
"shortDescription" : "Success."
}
}
]
}

© 2022 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 24