Spectrum Access System (SAS) - Citizens Broadband Radio Service Device (CBSD) Interface Technical Specification
Signaling Protocols and Procedures for Citizens Broadband Radio Service (CBRS)
Document WINNF-TS-0016
Version V1.2.6
25 November 2020
This document has been prepared by the SSC Work Group 3 to assist The Software Defined Radio Forum Inc. (or its successors or assigns, hereafter "the Forum"). It may be amended or withdrawn at a later time and it is not binding on any member of the Forum or of the SSC Work Group 3.
Contributors to this document that have submitted copyrighted materials (the Submission) to the Forum for use in this document retain copyright ownership of their original work, while at the same time granting the Forum a non-exclusive, irrevocable, worldwide, perpetual, royalty-free license under the Submitter's copyrights in the Submission to reproduce, distribute, publish, display, perform, and create derivative works of the Submission based on that original work for the purpose of developing this document under the Forum's own copyright.
Permission is granted to the Forum's participants to copy any portion of this document for legitimate purposes of the Forum. Copying for monetary gain or for other non-Forum related purposes is prohibited.
The Forum draws attention to the fact that it is claimed that compliance with this specification may involve the use of one or more patents ("IPR"). The Forum takes no position concerning the evidence, validity or scope of this IPR.
The holder of this IPR has assured the Forum that it is willing to license all IPR it owns and any third party IPR it has the right to sublicense which might be infringed by any implementation of this specification to the Forum and those licensees (members and nonmembers alike) desiring to implement this specification. Information may be obtained from:
QUALCOMM Incorporate
Attn: Thomas Rouse
5775 Morehouse Drive
San Diego, California, 92121
Email: [ip.disclosure@qualcomm.com](mailto:ip.disclosure@qualcomm.com)
Huawei Technologies Co., Ltd
Attn: Wang Xin
Building B1, Huawei Industrial Base
Bantian, Longgang District
Shenzhen, P.R. China 518129
Email: alex.wangxin@huawei.com
Attention is also drawn to the possibility that the Forum shall not be responsible for identifying any or all such IPR.
THIS DOCUMENT IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NON-INFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE FORUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS DOCUMENT.
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation.
This document was developed following the Forum's policy on restricted or controlled information (Policy 009) to ensure that that the document can be shared openly with other member organizations around the world. Additional Information on this policy can be found here: http://www.wirelessinnovation.org/page/Policies\_and\_Procedures.
Although this document contains no restricted or controlled information, the specific implementation of concepts contain herein may be controlled under the laws of the country of origin for that implementation. Readers are encouraged, therefore, to consult with a cognizant authority prior to any further development.
Wireless Innovation Forum ™ and SDR Forum ™ are trademarks of the Software Defined Radio Forum Inc.
The following individuals made significant contributions to this document:
Editors: Prakash Moorut, Steve Magee, and Mike Dolan (Nokia), Yi Hsuan and Greg Billock (Google), Kumar Balachandran (Ericsson), Masoud Olfat (Federated Wireless), Dave Wright and Dave Stephenson (Ruckus Wireless), Naotaka Sato and Sho Furuichi (Sony Corporation).
This document is the Technical Specification of the signaling protocol and procedures for the SAS-CBSD interface.
The key words "required", "shall", "shall not", "should", "should not", "recommended", "may", and "optional" in this document are to be interpreted as described in RFC-2119 [n.2]. In addition, the key word "conditional" shall be interpreted to mean that the definition is an absolute requirement of this specification only if the stated condition is met.
The following referenced documents are necessary for the application of the present document.
The following referenced documents are not necessary for the application of the present document but they assist the reader with regard to a particular subject area.
CBSD Citizens Broadband Radio Service Device
CBRS Citizens Broadband Radio Service.
CFR Code of Federal Regulation.
CPI Certified Professional Installer.
DP Domain Proxy
EIRP Effective Isotropic Radiated Power
FFS For Further Study
GAA General Authorized Access.
HAAT Height Above Average Terrain
HTTP Hypertext Transfer Protocol.
HTTPS HTTP over TLS.
ICG Interference Coordination Group
JSON JavaScript Object Notation.
PAL Priority Access License
PPA PAL Protection Area
SAS Spectrum Access System
TLS Transport Layer Security.
UR-ID User Registration Identity (see [n.12]).
Blacklist: A list of CBSDs that are to be denied service.
CBRS band: The 3550-3700 MHz Citizens Broadband Radio Service band.
CBSD Antenna: The radiating element(s) of the CBSD. Each CBSD has one CBSD Antenna. Note that the CBSD's antenna may be instantiated with multiple physical antennas (e.g., an antenna array for MIMO operation), but those antennas must be transmitting one aggregate waveform collectively from a single geolocation, and with a total transmit power that conforms to all the CBSD's registration parameters and authorized transmit power levels provided by the SAS in its active Grants (e.g., maximum allowable EIRP).
CBSD Registration: The procedure by which a CBSD indicates to a SAS its intention to operate. Successful registration implies a validation by the SAS that the CBSD has been FCC certified and confers on the CBSD the right to be authorized by the SAS to operate in accordance with a Grant. During the registration process, each CBSD provides a fixed location, unique identifiers (e.g., owner information, device information), Group membership, and radio-related capabilities. A successful registration procedure concludes with the SAS providing a unique identifier for that CBSD.
CBSD User: The registered entity that has operational responsibility for the CBSD.
Channel: the contiguous frequency range between lower and upper frequency limits.
Citizens Broadband Radio Service Device (CBSD): Fixed Stations, or networks of such stations, that operate on a Priority Access or General Authorized Access basis in the Citizens Broadband Radio Service consistent with Title 47 CFR Part 96 [n.8]. For CBSDs which comprise multiple nodes or networks of nodes, CBSD requirements apply to each node even if network management and communication with the SAS is accomplished via a single network interface.
Domain Proxy (DP): An entity engaging in communications with the SAS on behalf of multiple individual CBSDs or networks of CBSDs. The Domain Proxy can also provide a translational capability to interface legacy radio equipment in the 3650-3700 MHz band with a SAS to ensure compliance with Part 96 rules [n.8].
Grant: The authorization provided by a SAS to a CBSD, subject to a Heartbeat exchange, to transmit using specified operating parameters. Grants are identified by a unique Grant identifier. Once issued, a Grant's operating parameters are never changed; if new or modified operating parameters are required, then a new Grant must be obtained. The Grant's operating parameters are maximum EIRP and Channel. A Grant can be in different states as defined in section 7.
Group: A collection of CBSDs which are provided a special, common form of management by the SAS. The nature of the special management is dependent on Group type.
Interference Coordination Group: A group of CBSDs that does not require intra-group, inter-CBSD interference coordination from the SAS.
PAL reserved channel: A 10 MHz channel in the range of 3550-3650 that a SAS may establish for exclusive use of a set of one or more CBSDs that are registered as belonging to a PPA based upon acquired PAL rights.
PAL Protection Area (PPA): An area within a PAL established by a PAL owner for protecting exclusive use of channels based upon the acquisition of PAL rights. The area is based upon the coverage area of the set of CBSDs that are members of the PPA. The SAS maintains a list of CBSDs that are members of the PPA.
REG-Conditional: A parameter in the RegistrationRequest object that may be provided by the CBSD or may be provided through other means. See section 10.1.
Spectrum Access System (SAS): A system that authorizes and manages use of spectrum for the Citizens Broadband Radio Service in accordance with subpart F in [n.8].
This informative section provides the interfaces related to the protocols that are defined in this specification. The figure below is a subset of the architecture described in [i.1].
CBSD: The CBSD is a radio device that communicates in the CBRS band. It obtains Grants from the SAS via the SAS-CBSD interface.
Domain Proxy (DP): The DP is a logical entity that can represent one or more CBSD(s) to the SAS. The DP presents a consistent and secure interface to the SAS that can convey all messages pertaining to the SAS-CBSD interface for client CBSDs.
SAS: A system that authorizes and manages use of spectrum for the Citizens Broadband Radio Service in accordance with subpart F [n.8].
For further information please see:
The operation of a CBSD can be informatively described using two state machines. The registration state machine is responsible for identifying the presence of a CBSD at the SAS and determines whether the CBSD is Unregistered or Registered at the SAS. Each CBSD has one registration state machine. The Grant state machine represents the states of a CBSD Grant, i.e., Idle, Granted, and Authorized. A CBSD can have multiple Grants and each Grant corresponds to a separate Grant state machine.
Figures 2 and 3 illustrate the CBSD registration state diagram and the CBSD Grant state diagram respectively, where rectangle boxes indicate different states and arrows show possible state transitions.
In Figure 2, a CBSD starts off in the Unregistered state. An Unregistered CBSD can send a RegistrationRequest object to the SAS and if the SAS approves the registration in a RegistrationResponse object*,* the CBSD transitions to the Registered state. If the SAS rejects the registration in a RegistrationResponse object*,* the CBSD remains in the Unregistered state. A CBSD in the Registered state can also send a DeregistrationRequest object to deregister the CBSD. Once a SAS receives a DeregistrationRequest object, the SAS responds to the CBSD with a DeregistrationResponse object and declares the CBSD to be in the Unregistered state. The CBSD transitions to the Unregistered state and all existing Grants associated with the CBSD are terminated.
Notes regarding SAS implementation:
Figure 3 shows the state transitions of a CBSD Grant. A CBSD in the Registered state can request one or multiple Grants from the SAS. A Grant state machine is in the Idle state if a Grant has not been approved by the SAS. A CBSD can send the SAS a GrantRequest object. If a Grant request is approved, a new Grant is created with operational parameters and a channel allocation. The reception of a successful GrantResponse object causes transition to the Granted state. A CBSD with a Grant that is ready to commence RF transmission commences heartbeat requests associated with the Grant. If a CBSD receives multiple Grants, individual heartbeat requests are sent for each Grant, possibly aggregated in a single transmission to the SAS. If the SAS approves a heartbeat request, the Grant transitions to the Authorized state. In the Authorized state, the CBSD is permitted to commence RF transmission and operate in the CBRS band using the operational parameters specific to that Grant. The Grant transitions from the Authorized state back to the Granted state if the Grant is suspended by the SAS or the transmission right, as defined by the transmitExpireTime parameter in the HeartbeatResponse object, has expired. The Grant state transitions to Idle if a Grant is terminated by the SAS, relinquished by the CBSD, or expired as defined in the grantExpireTime parameter, or the SAS to CBSD connectivity is lost (see Section 8.6).
This section contains detailed procedures describing the transactions over the SAS-CBSD interface (see Figure 1). These procedures describe how the messages specified in section 10 are used and how they are combined to perform activities.
The SAS-CBSD protocol is based on the HTTPS (HTTP over TLS, ref. [n.4]) protocol as specified in section 9.2. The HTTPS protocol provides transport level assurance that a message has been received by the intended recipient. In this version of this specification, the procedures of section 8 will use the mechanisms provided by the HTTPS protocol to manage SAS-CBSD message delivery.
All SAS administrators shall provide a URL formatted in accordance with [n.9] to CBSD Users. One or more SAS URLs are provisioned to CBSDs and Domain Proxies using a mechanism which is outside the scope of this specification.
All SAS administrators shall ensure that for URLs corresponding to their service, all required DNS resource records (e.g., A record, see section 3.4.1 in RFC-1035 [n.14]) are provisioned and up-todate.
All SAS administrators shall provide their services using IPv4 and optionally using IPv6.
TLS mutual authentication shall be performed per [n.1] whenever a CBSD or Domain Proxy communicates with a SAS. TLS-v1.2 as specified in [n.3] shall be used to perform authentication. Previous versions of TLS (e.g., TLS-v1.1 per RFC-4346, TLS-v1.0 per RFC-2246 or SSL-v3.0) shall not be used. During the TLS exchange, mutual authentication shall be performed. The CBSD/Domain Proxy initiating the TLS connection shall authenticate the SAS, and the SAS shall authenticate the CBSD/Domain Proxy.
During the TLS message exchange, the CBSD/Domain Proxy shall authenticate a SAS according to the procedures defined in [n.4]. Server certificate validation shall be performed according to the procedures in [n.5]. A CBSD or Domain Proxy which is unable to successfully authenticate a SAS shall abort the TLS connection establishment procedure. It is implementation specific when the CBSD should re-attempt the TLS connection establishment procedure.
During the TLS message exchange, the CBSD/Domain Proxy provides its client certificate to the SAS. The SAS shall perform client certificate validation according to the procedures in [n.5]. A SAS which is unable to successfully authenticate a CBSD or Domain Proxy shall abort the TLS connection establishment procedure.
Subsequent to successful authentication, the CBSD/Domain Proxy and SAS shall negotiate a ciphersuite to use for encrypting all communications between the two entities. The ciphersuite shall be selected from the following list (ref. [n.1]):
A CBSD or Domain Proxy which is unable to successfully setup such an encrypted connection with a SAS shall abort the TLS connection establishment procedure. It is implementation specific when the CBSD/Domain Proxy should re-attempt the TLS connection establishment procedure.
All message exchanges involving communication between a CBSD or Domain Proxy and the SAS shall be performed in a TLS connection context established as described in sections 8.2 and 8.2.1. If such a TLS connection is already open, the procedures may be performed within that context. If a new connection is required, it shall be established using the same mechanisms and exception handling described in sections 8.2 and 8.2.1.
This procedure describes how a CBSD registers with a SAS as shown in Figure 4.
Informative Note: The CBSD Registration message exchange is initiated when the CBSD is in the Unregistered state (see section 7).
Figure 4: CBSD Registration Procedure.
This procedure is initiated after the CBSD has successfully discovered the SAS and performed Authentication per sections 8.2 and 8.2.1. The details of the authentication procedure are found in reference [n.1].
In the absence of the domain proxy, the CBSD first creates a secure association per section 8.2. The CBSD then initiates the Registration procedure by sending a RegistrationRequest object(userId, fccId, cbsdSerialNumber, callSign, cbsdCategory, cbsdInfo, airInterface, installationParam, measCapability, groupingParam) to the SAS. The fccId, callSign, cbsdSerialNumber, and userId parameters identify the CBSD to the SAS. The cbsdCategory, cbsdInfo, airInterface, and installationParam parameters provide specific information on the CBSD equipment capabilities. The measCapability parameter identifies the measurement reporting capabilities of the CBSD. The optional GroupingParam object requests the SAS to enroll the CBSD as a member of one or more Groups.
The SAS responds to the CBSD with a RegistrationResponse object (cbsdId, measReportConfig, response). The response parameter indicates whether the registration succeeded or failed. If the registration succeeded, the RegistrationResponse object contains a cbsdId parameter. The CBSD uses the cbsdId parameter value for all subsequent procedures with the SAS. If the cbsdId parameter value is missing or invalid in subsequent procedures, the SAS should use responseCode parameter value 103 (INVALID_VALUE) and include "cbsdId" in the responseData parameter. If the measReportConfig parameter is included in the RegistrationResponse object, the CBSD shall send the requested measurement report to the SAS (as indicated by the value of the measReportConfig parameter) per the defined semantics of the measurement capabilities in [n.21]. The measurement report requested by the SAS shall be consistent with the CBSD measurement capabilities indicated in the registration request. If the measCapability parameter contains only the empty string (""), the SAS assumes that the CBSD is not capable of reporting any measurements.
If the CBSD has any existing Grants prior to sending the RegistrationRequest object, all Grants shall be deleted. If the SAS had any existing Grants assigned to the CBSD, upon receiving the RegistrationRequest object from the CBSD, all such Grants shall be deleted.
If there is a Domain Proxy and the Domain Proxy is performing bulk CBSD registration, the Domain Proxy aggregates registration information for multiple CBSDs. The Domain Proxy sends an array of RegistrationRequest objects to the SAS which represents the aggregated CBSD registration information. Each RegistrationRequest object contains one instance of a registration request for a CBSD that the Domain Proxy is registering. Upon reception of the array of RegistrationRequest objects, the SAS initiates registration for each CBSD. The SAS responds with an array of RegistrationResponse objects, each containing a registration response to a CBSD (cbsdId, measReportConfig, response). The response parameter indicates whether the registration succeeded or failed. A Domain Proxy correlates the response objects with request objects as described in section 9.1. For requests that succeed, the Domain Proxy shall use the registered cbsdId parameter for all subsequent procedures with the SAS relative to each Registered CBSD.
If the RegistrationRequest object contains a groupingParam parameter containing a GroupParam object having the groupType parameter set to "INTERFERENCE_COORDINATION", the CBSD is requesting the SAS to not provide any intra-group, inter-CBSD interference coordination between CBSDs sharing the value of the groupId parameter provided in the request (Ref [n.8] 96.35(e), 96.41(d)(1)).
If the registration is not successful, the SAS sends a RegistrationResponse object that does not contain a cbsdId parameter, and contains a response parameter indicating failure.
If the SAS determines the registration is incomplete, the SAS returns a REG_PENDING value in the response parameter. The CBSD should periodically repeat sending the RegistrationRequest object until receiving a successful RegistrationResponse object from the SAS.
Note: For example, the REG_PENDING responseCode value can be used when the CPI needs to enter some additional part of the CBSD information.
If the SAS determines the CBSD operating privileges have been revoked, the SAS returns a BLACKLISTED value in the response parameter. When the CBSD operating privileges are restored, the CBSD may initiate a RegistrationRequest object. The method by which operating privileges are restored to the CBSD is outside the scope of this specification. The method used to trigger the CBSD registration is implementation specific.
If the SAS determines that there is an error with the format of the HTTP payload, it may return HTTP 400.
If the SAS determines an error with one of the parameters in the RegistrationRequest object, the SAS returns an INVALID_VALUE value in the response parameter along with the faulty parameter(s), see Table 40. The handling of a failure is out of scope of this specification.
If there is a Domain Proxy, the Domain Proxy can receive an aggregated list of RegistrationResponse objects, each containing a registration response to a CBSD. For each CBSD registration that fails, there will be one RegistrationResponse object per CBSD containing a response parameter having a non-zero value. For each CBSD registration that fails, the corresponding RegistrationResponse object does not contain a cbsdId parameter. The Domain Proxy matches the individual responses to the individual requests as defined in section 9.1 and takes the appropriate action, possibly involving the CBSD(s).
This procedure describes how a CBSD performs the Spectrum Inquiry procedure with the SAS. Spectrum Inquiry allows Registered CBSDs to request information on available channels. With the SAS providing available channel information, the CBSD can decide operational parameters for a Grant request. The CBSD may initiate this procedure after it has received a cbsdId value (see section 8.3.1).
Figure 5: CBSD Spectrum Inquiry Procedure.
The Spectrum Inquiry procedure may be initiated if the CBSD wants the SAS to indicate specific information on channels available for the CBSD.
If there is no Domain Proxy, the CBSD initiates the Spectrum Inquiry procedure by sending a SpectrumInquiryRequest object (cbsdId, inquiredSpectrum, measReport) to the SAS. The cbsdId parameter identifies the CBSD to the SAS. The inquiredSpectrum parameter is an array of FrequencyRange objects indicating the frequency range(s) for which the CBSD seeks information. The CBSD may request information for one or more frequency ranges as described in section 10.3. The measReport parameter provides a means for the CBSD to report measurement results.
The SAS shall return a SpectrumInquiryResponse object (cbsdId, availableChannel, response) to the CBSD with the results of the potential channel availability for the inquired spectrum. availableChannel parameter is an array of AvailableChannel objects, each of which includes a frequency range, the channelType ("PAL" or "GAA") and the regulatory rule that the SAS used to deteremine availability.
The CBSD should consider the information in the availableChannel parameter as an indication of the channels available to the CBSD.
Note: The SAS is not required to reserve any channel allocations as part of Spectrum Inquiry procedure, nor is the SAS required to guarantee that the information in the AvailableChannel object is still valid when the CBSD initiates a Grant Request procedure.
If there is a Domain Proxy and the Domain Proxy is sending bulk SpectrumInquiryRequest objects, the Domain Proxy aggregates information related to each applicable CBSD into an array of SpectrumInquiryRequest objects as described in section 10. When the Domain Proxy receives the array of SpectrumInquiryResponse objects from the SAS, the Domain Proxy matches the individual responses to the individual requests as described in section 9.1 and takes the appropriate action, possibly involving the CBSD(s).
If the SAS determines an error with one of the parameters in the SpectrumInquiryRequest object, the SAS returns a SpectrumInquiryResponse object with a response parameter including the faulty parameter(s); see Table 40. The handling of a failure is out of scope of this specification. If the cbsdId parameter is not present, a 102 (MISSING_PARAM) error shall be generated by the SAS. If the cbsdId parameter is invalid, a 103 (INVALID_VALUE) error shall be generated by the SAS. If the SAS finds the inquiredSpectrum parameter indicates a frequency range that is partially or completely outside of the CBRS band, a 300 (UNSUPPORTED_SPECTRUM) error shall be generated by the SAS.
If there is a Domain Proxy, the Domain Proxy can receive an aggregated list of SpectrumInquiryResponse objects. For each failed request, there is a failure reason in the response parameter. The Domain Proxy matches the response with the originating request as described in section 9.1 and takes the appropriate action, possibly involving the CBSD(s).
This procedure describes how a CBSD requests spectrum from the SAS. This procedure shall not be initiated until after the CBSD has successfully registered with the SAS. A CBSD is considered to be Registered when it has obtained a cbsdId value; the cbsdId value is revoked (i.e., invalidated) when the CBSD is deregistered. SpectrumInquiryRequest objects may be sent prior to sending the GrantRequest object if the CBSD wants the SAS to indicate specific information on channels available for the CBSD. A successful HeartbeatResponse object shall be received by the CBSD prior to activating its transmitter on any channel assigned during the Grant procedure.
Figure 6: CBSD Grant Procedure.
Prior to initiating a Grant request, the CBSD determines the operational parameters used in the Grant request. These operational parameters include the frequency range and maximum EIRP the
CBSD wants to use for operation. The determination of the specific operational parameters used in the Grant request depends on CBSD capabilities, current operation and configuration.
The CBSD initiates a Grant request by sending a GrantRequest object (cbsdId, operationParam, measReport) to the SAS. The cbsdId parameter identifies the CBSD to the SAS. The operationParam parameter contains the details of the Grant request including the CBSD maximum EIRP and the desired frequency range for use as described in section 10.5. The SAS may determine the eligibility of the CBSD to use PAL reserved channels by ascertaining if the CBSD (cbsdId) is a member of the set of CBSDs defining the PPA and the requested channel(s) corresponds to the PAL reserved channel(s) for that area. The SAS maintains a list of all the CBSDs that are registered members of the PPA. If the CBSD is a member of the list of CBSDs associated with a PPA, and if the requested frequency range is within that PPA's PAL reserved portion of the band, the Grant request is considered to be a PAL Grant request. If the requested frequency range is outside the PAL reserved portion of the band, or if the requesting CBSD is not a member of the appropriate PPA, then the Grant request is not considered to be a PAL Grant request, but is considered to be a GAA Grant request. The CBSD maximum EIRP indicates the maximum transmission EIRP the CBSD is requesting. The desired frequency range is a contiguous frequency range specified by low and high frequency values. The measReport parameter provides a means for the CBSD to report measurement results.
The SAS responds to the CBSD with a GrantResponse object (cbsdId, grantId, grantExpireTime, heartbeatInterval, measReportConfig, operationParam, channelType, response). The response parameter indicates whether the request succeeded or failed. If the Grant request succeeded, the SAS includes the grantId parameter, the grantExpireTime parameter, and the heartbeatInterval parameter. The CBSD uses the value of the grantExpireTime parameter to determine when the associated Grant expires. If the heartbeatInterval parameter is included, the CBSD uses the value as the maximum time interval between two consecutive HeartbeatRequest objects. Since the CBSD cannot transition to the Authorized state until the successful completion of the Heartbeat procedure, the CBSD should execute the first Heartbeat procedure following the GrantResponse object as soon as possible after the GrantResponse object is received. The channelType parameter is included if and only if the response parameter indicates SUCCESS. If the measReportConfig parameter is included, the CBSD shall send the requested measurement report to the SAS, as indicated by the value of the measReportConfig parameter, according to [n.21]. The measurement report requested by the SAS shall be consistent with the CBSD measurement capabilities indicated in the registration request. If the GrantResponse object includes an operationParam parameter, the CBSD may elect to issue a new GrantRequest object using the operational parameters included from that operationParam parameter.
If the SAS approves the Grant request, the SAS allocates spectrum according to the parameters in the operationParam parameter in the GrantRequest object. The SAS allocates the spectrum in a frequency range indicated by the lowFrequency and highFrequency parameters in the operationParam parameter. The CBSD shall not use that spectrum (i.e., activate its radio transmitter) until successfully completing the Heartbeat procedure.
If there is a Domain Proxy and the Domain Proxy is performing bulk Grant requests, the Domain Proxy aggregates information related to each applicable CBSD into an array of GrantRequest objects, each containing a Grant request of a CBSD as described in section 10. When the Domain Proxy receives the array of GrantResponse objects from the SAS, the Domain Proxy matches the individual responses to the individual requests as described in section 9.1. If the response to a specific Grant request indicates that the Grant request succeeded, the CBSD/Domain Proxy takes the appropriate action.
If the SAS determines an error with one of the parameters in the GrantRequest object, the SAS returns a GrantResponse object with a response parameter including the faulty parameter(s), see Table 40. The handling of a failure is out of scope of this specification. If the cbsdId parameter is not present, a 102 (MISSING_PARAM) error shall be generated by the SAS. If the cbsdId parameter is invalid, a 103 (INVALID_VALUE) error shall be generated by the SAS.
The SAS shall reject a Grant request which results in a Grant that includes both PAL and GAA channels. If the Grant request failed, the GrantResponse object:
If there is a Domain Proxy, the Domain Proxy can receive an aggregated list of GrantResponse objects. For each failed request, there will be a failure reason in the response parameter. The Domain Proxy matches the response with the originating request as described in section 9.1 and takes the appropriate action, possibly involving the CBSD(s).
This procedure describes how a CBSD performs the Heartbeat procedure with the SAS. The HeartbeatRequest object informs the SAS that the CBSD needs access to the allocated spectrum. It also allows the SAS to suspend or terminate the Grant. If the transmit expiration timer expires prior to reception of a HeartbeatResponse object, the CBSD shall discontinue transmission for the Grant within 60 seconds after the value of the transmitExpireTime parameter expires, in accordance with part 96.39(c)(2) (ref. [n.8]). If the Grant is suspended or terminated, the SAS has the option, within the HeartbeatResponse object, of suggesting that the CBSD request alternative spectrum based on the operationParam parameter in the HeartbeatResponse object. The CBSD Heartbeat procedure may be executed concurrently for each active Grant. An active Grant has a grantId and is not terminated, expired or relinquished. Additionally, the SAS to CBSD connectivity is not considered to be lost. When a Grant is terminated, expires or is relinquished, or the SAS to CBSD connectivity is considered to be lost, its grantId is revoked (i.e., is no longer usable).
SAS to CBSD connectivity is considered to be lost when during a seven-day period there is no successful Heartbeat procedure between the SAS and the CBSD.
Informative Note: This procedure is used by a CBSD when it has one or more Grants in the Granted or Authorized states (see section 7).
Figure 7: CBSD Heartbeat Procedure.
The CBSD initiates this procedure any time prior to the expiration of the Heartbeat Interval timer. The Heartbeat interval is defined as the time interval between the transmission of the two messages that include consecutive HeartbeatRequest objects associated with the same Grant. The timer is reset when the HeartbeatRequest object is sent to the SAS. The heartbeatInterval parameter may be included in the HeartbeatResponse object. The CBSD should send the HeartbeatRequest object as soon as a Grant is approved by the SAS.
If there is no Domain Proxy, the CBSD initiates the Heartbeat procedure by sending a HeartbeatRequest object (cbsdId, grantId, grantRenew, operationState, measReport) to the SAS. The cbsdId parameter identifies the CBSD to the SAS. The grantId parameter identifies the intended Grant for the heartbeat. The grantRenew parameter is an optional parameter. The CBSD includes this parameter and sets its value to TRUE when the CBSD wants to renew the Grant associated with the grantID. The operationState parameter is required. The measReport parameter provides a means for the CBSD to report the measurement results requested in a GrantResponse object or a HeartbeatResponse object from the SAS.
The CBSD obtains the heartbeat interval value in the GrantResponse object or in a previous HeartbeatResponse object. The SAS responds to the CBSD with a HeartbeatResponse object (cbsdId, grantId, transmitExpireTime, grantExpireTime, heartbeatInterval, operationParam, measReportConfig, response). The response parameter indicates whether the request succeeded or failed.
If the request succeeded, the SAS includes the transmitExpireTime parameter. The CBSD uses the value of the transmitExpireTime parameter to determine when the CBSD stops transmitting on the assigned spectrum. The CBSD shall treat expiry of the transmitExpireTime parameter value as the time at which the CBSD is directed by the SAS to turn off its transmitter and shall cease
transmission using the SAS authorized radio resource within 60 seconds after the value of the transmitExpireTime parameter expires, in accordance with part 96.39(c)(2) (ref. [n.8]).
If the request succeeded and the CBSD included the grantRenew parameter with a value set to TRUE in the HeartbeatRequest object, the SAS includes the grantExpireTime parameter. If included, the CBSD uses the value of the grantExpireTime parameter as the new time when the Grant expires.
If the heartbeatInterval parameter is included, the CBSD uses the value as the time interval before the next HeartbeatRequest object is sent; the CBSD continues to use this value of heartbeat interval until a new value is provided by the SAS.
If the HeartbeatRequest object succeeds, the operationParam parameter is optional in the HeartbeatResponse object. If the request fails, the SAS may include the operationParam parameter. The CBSD may ignore the operationParam parameter if it is included in the response. If the operationParam parameter is included, the CBSD interprets it as a recommendation on spectrum availability from the SAS.
In the successful HeartbeatResponse object (i.e., the response parameter indicates SUCCESS), if this is the response for the first HeartbeatRequest object following the GrantResponse object for this Grant, or the first HeartbeatRequest object following a HeartbeatResponse object with the response parameter set to SUSPENDED_GRANT, the CBSD is authorized to transmit and may initiate radio transmission any time after receiving this HeartbeatResponse object. Moreover, the CBSD shall update the heartbeatInterval and grantExpireTime based on the contents of the HeartbeatResponse object. If the HeartbeatResponse object contains the measReportConfig parameter, the CBSD shall send the requested measurement report to the SAS, as indicated by the value of the measReportConfig parameter, according to [n.21]. The measurement report requested by the SAS shall be consistent with the CBSD measurement capabilities indicated in the registration request. If the operationParam parameter is included in HeartbeatResponse object, the CBSD:
If the response parameter value indicates SUSPENDED_GRANT, the SAS shall include the transmitExpireTime parameter in the HeartbeatResponse object. The CBSD shall terminate radio operation by turning off its radio transmission associated with this Grant within 60 seconds after the value of the transmitExpireTime parameter expires, in accordance with part 96.39(c)(2) (ref. [n.8]). The CBSD shall update the Grant parameters (i.e., heartbeatInterval, grantExpireTime, transmitExpireTime) based on the contents of the HeartbeatResponse object. The CBSD may request relinquishment of the Grant at any time. If not relinquished, the CBSD shall continue sending HeartbeatRequest objects at or before the expiration of the most recently updated value of the heartbeatInterval parameter. However, the CBSD is not authorized to transmit until it receives a successful HeartbeatResponse object (i.e., the response parameter of the HeartbeatResponse object indicates SUCCESS).
If the operationParam parameter is included in the HeartbeatResponse object, the CBSD:
If the response parameter indicates TERMINATED_GRANT, the CBSD shall terminate radio operation associated with this Grant by turning off its radio transmission within 60 seconds after the time specified in the transmitExpireTime parameter according to Part 96.39.(c).(2) (ref. [n.8]). The Grant is considered terminated by the SAS. If the operationParam parameter is included in the HeartbeatResponse object, the CBSD:
If the response parameter indicates UNSYNC_OP_PARAM, the CBSD shall interpret it as an indication that the CBSD is out of sync with the SAS on Grant state. The CBSD shall turn off the radio transmission associated with this Grant within 60 seconds from receiving this responseCode value according to Part 96.39(c)(2) (ref. [n.8]), and shall relinquish the Grant by sending a RelinquishmentRequest object. The CBSD may subsequently request a new Grant.
If the measReportConfig parameter is included, the CBSD should send the requested measurement report in the subsequent HeartbeatRequest object. The measurement report requested by the SAS shall be consistent with the CBSD measurement capabilities indicated in the registration request.
If there is a Domain Proxy and the Domain Proxy is performing bulk HeartbeatRequest objects, the Domain Proxy aggregates information related to each applicable CBSD into an array of HeartbeatRequest objects, each containing a heartbeat request of a CBSD as described in section 10. When the Domain Proxy receives the set of HeartbeatResponse objects from the SAS in an array of HeartbeatResponse objects, the Domain Proxy matches the individual responses to the individual requests as described in section 9.1. If the response indicates the HeartbeatRequest object succeeded, the Domain Proxy performs the previously described CBSD behavior on behalf of the successful CBSD(s). If this is the initial HeartbeatRequest object after a successful GrantResponse object, the Domain Proxy takes the appropriate action to initiate radio transmission.
If the SAS determines an error with one of the parameters in the HeartbeatRequest object, the SAS returns a HeartbeatResponse object with a response parameter including the faulty parameter(s), see Table 40. The handling of a failure is out of scope of this specification. If the cbsdId parameter is not present, a 102 (MISSING_PARAM) error shall be generated by the SAS. If the cbsdId parameter is invalid, a 103 (INVALID_VALUE) error shall be generated by the SAS.
If there is a Domain Proxy, the Domain Proxy can receive an array of HeartbeatResponse objects. For each failed request, there will be a failure reason in the response parameter. The Domain Proxy matches the response with the originating request as described in section 9.1 and takes the appropriate action, possibly involving the CBSD(s).
This procedure describes how a CBSD can inform the SAS if a Grant is no longer needed by the CBSD. This procedure can be executed at any time by a CBSD for a non-expired Grant.
Informative Note: This procedure is used by a CBSD on a Grant in the Granted or Authorized state (see section 7).
Figure 8: CBSD Grant Relinquishment Procedure.
The CBSD may initiate this procedure for an existing Grant. The CBSD shall terminate radio operation associated with this Grant before initiating this procedure.
If there is no Domain Proxy, the CBSD initiates the Grant Relinquishment Procedure by sending a RelinquishmentRequest object (cbsdId, grantId) to the SAS. The cbsdId parameter identifies the CBSD to the SAS. The grantId parameter identifies the Grant the CBSD wants to relinquish. Upon reception of the RelinquishmentRequest object, the SAS relinquishes the spectrum assigned to the CBSD. The SAS responds to the CBSD with a RelinquishmentResponse object (cbsdId, grantId, response). If the request succeeded, the CBSD no longer has authorization to use the spectrum associated with the Grant.
If there is a Domain Proxy and the Domain Proxy is sending bulk RelinquishmentRequest objects, the Domain Proxy aggregates relinquishment information for multiple CBSDs. The Domain Proxy aggregates this information into an array of RelinquishmentRequest objects and sends the resulting JSON relinquishmentRequest array to the SAS. Each RelinquishmentRequest object contains one instance of a relinquishment request for a CBSD requesting Grant relinquishment. Upon reception of the RelinquishmentRequest object, the SAS initiates the relinquishment process for each Grant. The SAS responds to the Domain Proxy with an array of one or more RelinquishmentResponse objects. If an individual request succeeded, the associated CBSD no longer has authorization to use the spectrum associated with the Grant. The Domain Proxy matches the individual responses to the individual requests as described in section 9.1 and takes the appropriate action, with the CBSD(s).
Regardless of the reason for failure of RelinquishmentRequest object, the CBSD no longer has authorization to use the spectrum associated with the Grant.
If the SAS determines an error with one of the parameters in the RelinquishmentRequest object, the SAS returns a RelinquishmentResponse object containing a responseCode parameter indicating the error. If the responseCode parameter is set to 103 (INVALID_VALUE), the responseData parameter shall be set by the SAS to the name(s) of the parameter(s) that contained an invalid value. The handling of a failure is out of scope of this specification. If the cbsdId parameter is not present, a 102 (MISSING_PARAM) error shall be generated by the SAS. If the cbsdId parameter is invalid, a 103 (INVALID_VALUE) error shall be generated by the SAS. The CBSD shall cease use of the spectrum associated with the Grant. If the responseCode parameter indicates 103 (INVALID_VALUE) and the responseData parameter contains "cbsdId", the CBSD shall immediately terminate all transmissions and consider itself to be Unregistered.
If there is a Domain Proxy, the Domain Proxy can receive an array of RelinquishmentResponse objects. If an individual request failed and the RelinquishmentResponse object contains a responseCode parameter indicating 103 (INVALID_VALUE), the responseData parameter shall be set by the SAS to the name(s) of the parameter(s) that contained an invalid value. The associated CBSD shall cease use of the spectrum associated with the Grant. If the responseCode parameter indicates 103 (INVALID_VALUE) and the responseData parameter contains "cbsdId", the CBSD shall immediately terminate all transmissions and consider itself to be Unregistered. The Domain Proxy matches the response with the originating relinquishment request as described in section 9.1 and takes the appropriate action, possibly involving the CBSD(s).
This procedure describes how a CBSD deregisters from the SAS. The CBSD deregistration procedure is shown in the figure below.
Informative Note: This procedure is used by a CBSD in the Registered state.
Figure 9: CBSD Deregistration Procedure.
When the CBSD determines that it should deregister from the SAS, it shall cease transmission associated with any Grants and then shall send a DeregistrationRequest object (cbsdId) to the SAS. The CBSD then cancels any Grants that it still believes are allocated to it.
The SAS marks the CBSD as Unregistered, removes any existing Grants, and responds with a DeregistrationResponse object (cbsdId, response).
The CBSD should send a RelinquishmentRequest object for each Grant prior to sending the DeregistrationRequest object.
Upon receiving a DeregistrationResponse object from the SAS with a response parameter indicating SUCCESS, the CBSD concludes any remaining local aspects of deregistration and considers itself as Unregistered.
If the DeregistrationResponse object has a response parameter value other than SUCCESS, the CBSD shall consider itself Unregistered.
SAS-CBSD messages shall be encoded using JSON (JavaScript Object Notation) as defined in RFC-7159 [n.10]. Note that this means that Unicode characters are used and have a default encoding of UTF-8.
When a Domain Proxy sends a SAS-CBSD message to the SAS, multiple requests of the same type can be aggregated together in the form of a JSON array and sent in one HTTP request. Similarly, the SAS can include multiple responses in a JSON array and send it to a Domain Proxy. Therefore, a JSON-encoded SAS-CBSD message is in an array format that can accommodate one or multiple requests or responses of the same type. Different types of requests or responses shall not be included in one JSON-encoded SAS-CBSD message.
Per [n.10], JSON arrays are ordered sequences; as such, a multiple request message or multiple response message contains an ordered sequence of objects. Domain Proxies, SASs and CBSDs shall preserve array ordering. SASs receiving a message having an array of request objects shall respond with an array of response objects in which the order of the response objects is exactly matched to the order of the request objects. For example, if a SAS receives a message containing an array of three request objects, the SAS prepares the response message in which the first object in the array is the response to the first object in the request array, the second object in the array is the response to the second object in the request array and so on. When employing aggregated requests, Domain Proxies rely on this ordering to match responses with requests.
The following example shows the format of a JSON-encoded SAS-CBSD message (Registration Request Message). As shown in the example, the SAS-CBSD message contains two objects in a JSON array, whose name is registrationRequest. Each object denotes a registration request for a CBSD.
{
"registrationRequest": [
{
"fccId": "abc123",
"cbsdCategory": "A",
"callSign": "CB987",
"userId": "John Doe",
"airInterface": {
"radioTechnology": "E_UTRA"
},
"cbsdSerialNumber": "abcd1234",
"measCapability": [
"RECEIVED_POWER_WITHOUT_GRANT"
],
"installationParam": {
"latitude": 37.419735,
"longitude": -122.072205,
"height": 6,
"heightType": "AGL",
"indoorDeployment": true
},
"groupingParam": [
{
"groupId": "example-group-1",
"groupType": "INTERFERENCE_COORDINATION"
},
{
"groupId": "example-group-2",
"groupType": "INTERFERENCE_COORDINATION"
}
]
},
{
"fccId": "321cba",
"cbsdCategory": "B",
"callSign": "WSD987",
"userId": "John Doe",
"airInterface": {
"radioTechnology": "E_UTRA"
},
"cbsdSerialNumber": "4321dcba",
"measCapability": [
"RECEIVED_POWER_WITHOUT_GRANT"
],
"installationParam": {
"latitude": 37.425056,
"longitude": -122.084113,
"height": 9.3,
"heightType": "AGL",
"indoorDeployment": false,
"antennaAzimuth": 271,
"antennaDowntilt": 3,
"antennaGain": 16,
"antennaBeamwidth": 30
},
"groupingParam": [
{
"groupId": "example-group-3",
"groupType": "INTERFERENCE_COORDINATION"
}
]
}
]
}
The name of the outermost array in a JSON-encoded SAS-CBSD message maps to a SAS-CBSD message defined in section 10. Mapping of SAS-CBSD messages and the corresponding JSON array names can be found in the following table.
Table 1: Mapping of SAS-CBSD Messages to JSON Array Names
| SAS-CBSD Message Name | Reference | JSON Array Name |
|---|---|---|
| Registration Request Message | Section 10.1 | registrationRequest |
| Registration Response Message | Section 10.2 | registrationResponse |
| Spectrum Inquiry Request Message | Section 10.3 | spectrumInquiryRequest |
| Spectrum Inquiry Response Message | Section 10.4 | spectrumInquiryResponse |
| Grant Request Message | Section 10.5 | grantRequest |
| Grant Response Message | Section 10.6 | grantResponse |
| Heartbeat Request Message | Section 10.7 | heartbeatRequest |
| Heartbeat Response Message | Section 10.8 | heartbeatResponse |
| Relinquishment Request Message | Section 10.9 | relinquishmentRequest |
| Relinquishment Response Message | Section 10.10 | relinquishmentResponse |
| Deregistration Request Message | Section 10.11 | deregistrationRequest |
| Deregistration Response Message | Section 10.12 | deregistrationResponse |
HTTPS shall be used as the transport protocols for SAS-CBSD message exchanges. The TLS protocol as specified in [n.1] and HTTP version 1.1 as specified in [n.6] shall be used. The SAS
shall include its system time, upon which all SAS-CBSD protocol timers are based, in the Date HTTP header field in all SAS-CBSD messages (ref. [n.15]).
An example HTTP request message header follows:
POST /v1.2/registration HTTP/1.1
Host: www.sasadministratorapi.com
Content-type: application/json
Date: Mon, 03 Oct 2016 11:07:33 GMT
The HTTP POST method shall be used for all requests from the CBSD/DP to the SAS. The POST is sent to the SAS URL path (ref. [n.9]) which ends with the string "/{sas_version_number}/{sas_method_name}"1 to indicate the SAS-CBSD protocol version and the SAS method name for the message. Each SAS administrator chooses the base URL of its SAS service. The SAS-CBSD protocol version number shall be in the form of vx.y, where v is the string value "v", x is the CBRS release number and y is the version number. The sas_version_number of the SAS-CBSD protocol defined in this version of this technical specification shall be set to "v1.2". A SAS method corresponds to a pair of request and response messages defined in Section 10. SAS method names are listed below in Table 2.
Table 2: SAS Methods
| SAS Method Name | JSON Array Name of Request Message | JSON Array Name of Response Message |
|---|---|---|
registration | registrationRequest | registrationResponse |
spectrumInquiry | spectrumInquiryRequest | spectrumInquiryResponse |
grant | grantRequest | grantResponse |
heartbeat | heartbeatRequest | heartbeatResponse |
relinquishment | relinquishmentRequest | relinquishmentResponse |
deregistration | deregistrationRequest | deregistrationResponse |
In the event that a CPI inserts registration parameter data directly into the CBSD, a digital signature is applied to the data inserted by the CPI. See sections 10.1.3, 10.1.8, 10.1.6, and 10.1.7 for the protocol details.
The following is an example of a CpiSignedData object included in a RegistrationRequest object.
1 The curly braces indicate that the CBSD should substitute the appropriate string value for the enclosed parameter.
{
"fccId": "abc123",
"cbsdSerialNumber": "abcd1234",
"installationParam": {
"latitude": 37.425056,
"longitude": -122.084113,
"height": 9.3,
"heightType": "AGL",
"indoorDeployment": true
},
"professionalInstallerData": {
"cpiId": "10987654321AA",
"cpiName": "John Doe",
"installCertificationTime": "2017-10-11T20:30:00Z"
}
}
In this section parameters of SAS-CBSD message are described in more detail. A parameter value can be one of the primitive JSON data types, i.e., string, number, boolean, array, or object. If a parameter is an object, a name for the object is given and a separate table describes parameters in the object.
Each parameter is indicated as "Required", "Optional" or "Conditional". The definitions of these indicators are as follows:
The tables of parameters in this section have a column marked R/O/C that indicates whether the particular parameter is required, optional, or conditional.
The following criteria (called "REG-Conditional Registration Request Parameters" in this document) applies to all "REG-Conditional" parameters in the Registration Request Message in Section 10.1 and its Sub-sections, and defines the criteria by which the parameter is required to be included in the Message:
REG-Conditional Registration Request Parameters: This parameter is required by the SAS to complete the CBSD registration process, but may be omitted in the RegistrationRequest object. If not included in the RegistrationRequest object, the parameter, to the extent that it is needed by the SAS to satisfy the Part 96 Rules, shall be provided to the SAS by other means outside the protocol specified in this document, e.g., it may be provided by a CPI as required by Part 96 Rules for category B CBSDs or CBSDs without automatic location determination, or for operational reasons. Other means based on CBSD device characteristics that are beyond the scope of this specification, are not precluded from use.
Table 3: Registration Request Message
| Parameter | R/O/C | Description |
|---|---|---|
NAME: registrationRequest DATA TYPE: array of object: RegistrationRequest | Required | Array of RegistrationRequest data objects. Each RegistrationRequest data object represents a registration request of a CBSD. |
Table 4: RegistrationRequest Object Definition
| Parameter | R/O/C | Description |
|---|---|---|
NAME: userId DATA TYPE: string | Required | The UR-ID per [n.12] R2-SRR-02 conformant per section 2.2 of [n.18]. |
NAME: fccId DATA TYPE: string | Required | The FCC certification identifier of the CBSD. It is a string of up to 19 characters as described in [n.22]. |
NAME: cbsdSerialNumber DATA TYPE: string | Required | A serial number assigned to the CBSD by the CBSD device manufacturer having a maximum length of 64 octets. This serial number shall be unique for every CBSD instance sharing the same value of fccId. Each CBSD has a single CBSD Antenna (Ref. definition in section 4) and has a single cbsdSerialNumber. |
NAME: callSign DATA TYPE: string | Optional | A device identifier provided by the FCC per [n.13]. NOTE: This parameter is for further study. |
NAME: cbsdCategory DATA TYPE: string | REG-Conditional | Device Category of the CBSD. Allowed values are "A" or "B" as defined in Part 96. See “REG-Conditional Registration Request Parameters” above. |
NAME: cbsdInfo DATA TYPE: object: CbsdInfo | Optional | Information about this CBSD model. |
NAME: airInterface DATA TYPE: object: AirInterface | REG- Conditional | A data object that includes information on the air interface technology of the CBSD. See "REG-Conditional Registration Request Parameters" above. |
NAME: installationParam DATA TYPE: object: InstallationParam | REG- Conditional | A data object that includes information on CBSD installation. See "REG-Conditional Registration Request Parameters" above. |
NAME: measCapability DATA TYPE: array of string | REG- Conditional | The array of string lists measurement reporting capabilities of the CBSD. The permitted enumerations are specified in [n.21]. See "REG-Conditional Registration Request Parameters" above. |
NAME: groupingParam DATA TYPE: array of object: GroupParam | Optional | An array of data objects that includes information on CBSD grouping. |
NAME: cpiSignatureData DATA TYPE: object: CpiSignatureData | Optional | The CPI is vouching for the parameters included in this object. In addition, the digital signature for these parameters is included. |
Table 5: AirInterface Object Definition
| Parameter | R/O/C | Description |
|---|---|---|
NAME: radioTechnology DATA TYPE: string | REG- Conditional | This parameter specifies the radio access technology that the CBSD uses for operation in the CBRS band. The permitted values are specified in [n.21]. See “REG-Conditional Registration Request Parameters” above. |
NAME: latitude DATA TYPE: number | REG Conditional | Latitude of the CBSD antenna location in degrees relative to the WGS 84 datum [n.11]. The allowed range is from - 90.000000 to +90.000000. Positive values represent latitudes north of the equator; negative values south of the equator. Values are specified using 6 digits to the right of the decimal point. Note: Use of WGS84 will also satisfy the NAD83 positioning requirements for CBSDs with the accuracy specified by Part 96 [n.8]. For reporting the CBSD location to the FCC, the SAS is responsible for converting coordinates from the WGS84 datum to the NAD83 datum. See "REG-Conditional Registration Request Parameters" above. |
NAME: longitude DATA TYPE: number | REG Conditional | Longitude of the CBSD antenna location in degrees relative to the WGS84 datum [n.11]. The allowed range is from - 180.000000 to +180.000000. Positive values represent longitudes east of the prime meridian; negative values west of the prime meridian. Values are specified using 6 digits to the right of the decimal point. Note: Use of WGS84 will also satisfy the NAD83 positioning requirements for CBSDs with the accuracy specified by Part 96 [n.8]. For reporting the CBSD location to the FCC, the SAS is responsible for converting coordinates from the WGS84 datum to the NAD83 datum. See "REG-Conditional Registration Request Parameters" above. |
NAME: height DATA TYPE: number | REG- Conditional | The CBSD antenna height in meters. When the heightType parameter value is "AGL", the antenna height should be given relative to ground level. When the heightType parameter value is "AMSL", it is given with respect to WGS84 datum. For reporting the CBSD location to the FCC, the SAS is responsible for converting coordinates from the WGS84 datum to the NAD83 datum. See “REG-Conditional Registration Request Parameters” above. |
NAME: heightType DATA TYPE: string | REG- Conditional | The value should be "AGL" or "AMSL". AGL height is measured relative to the ground level. AMSL height is measured relative to the mean sea level. See “REG-Conditional Registration Request Parameters” above. |
NAME: horizontalAccuracy DATA TYPE: number | Optional | A positive number in meters to indicate accuracy of the CBSD antenna horizontal location. This optional parameter should only be present if its value is less than the FCC requirement of 50 meters. |
NAME: verticalAccuracy DATA TYPE: number | Optional | A positive number in meters to indicate accuracy of the CBSD antenna vertical location. This optional parameter should only be present if its value is less than the FCC requirement of 3 meters. |
NAME: indoorDeployment DATA TYPE: boolean | REG- Conditional | Whether the CBSD antenna is indoor or not. True: indoor. False: outdoor. See “REG-Conditional Registration Request Parameters” above. |
NAME: antennaAzimuth DATA TYPE: number | REG-Conditional | Boresight direction of the horizontal plane of the antenna in degrees with respect to true north. The value of this parameter is an integer with a value between 0 and 359 inclusive. A value of 0 degrees means true north; a value of 90 degrees means east. This parameter is optional for Category A CBSDs and REG-conditional for Category B CBSDs. See “REG-Conditional Registration Request Parameters” above. |
NAME: antennaDowntilt DATA TYPE: number | REG-Conditional | Antenna down tilt in degrees and is an integer with a value between -90 and +90 inclusive; a negative value means the antenna is tilted up (above horizontal). This parameter is optional for Category A CBSDs and REG-conditional for Category B CBSDs. See “REG-Conditional Registration Request Parameters” above. |
NAME: antennaGain DATA TYPE: number | REG-Conditional | Peak antenna gain in dBi. This parameter is an integer with a value between -127 and +128 (dBi) inclusive. See “REG-Conditional Registration Request Parameters” above. |
NAME: eirpCapability DATA TYPE: number | Optional | This parameter is the maximum EIRP in units of dBm/10MHz to be used by this CBSD and shall be no more than the rounded-up FCC certified maximum EIRP. The Value of this parameter is an integer with a value between -127 and +47 (dBm/10MHz) inclusive. If not included, SAS shall set eirpCapability as the rounded up FCC certified maximum EIRP of the CBSD. |
NAME: antennaBeamwidth DATA TYPE: number | REG- Conditional | 3-dB antenna beamwidth of the antenna in the horizontal-plane in degrees. This parameter is an unsigned integer having a value between 0 and 360 (degrees) inclusive; it is optional for Category A CBSDs and REG-conditional for category B CBSDs. Note: A value of 360 (degrees) means the antenna has an omnidirectional radiation pattern in the horizontal plane. See "REG-Conditional Registration Request Parameters" above. |
NAME: antennaModel DATA TYPE: string | Optional | If an external antenna is used, the antenna model is optionally provided in this field. The string has a maximum length of 128 octets. |
Table 6: InstallationParam Object Definition
| Parameter | R/O/C | Description |
|---|---|---|
NAME: latitude DATA TYPE: number | REG‑Conditional | Latitude of the CBSD antenna location in degrees (WGS‑84). Range −90.000000 to +90.000000. Six decimal places. SAS converts to NAD83 for FCC reporting. |
NAME: longitude DATA TYPE: number | REG‑Conditional | Longitude of the CBSD antenna location in degrees (WGS‑84). Range −180.000000 to +180.000000. Six decimal places. SAS converts to NAD83 for FCC reporting. |
NAME: height DATA TYPE: number | REG‑Conditional | Antenna height in meters. If heightType is AGL, height is above ground level; if AMSL, height is relative to WGS‑84 datum. |
NAME: heightType DATA TYPE: string | REG‑Conditional | Either AGL (above ground level) or AMSL (above mean sea level). |
NAME: horizontalAccuracy DATA TYPE: number | Optional | Horizontal accuracy in meters. Only included if < 50 m. |
NAME: verticalAccuracy DATA TYPE: number | Optional | Vertical accuracy in meters. Only included if < 3 m. |
NAME: indoorDeployment DATA TYPE: boolean | REG‑Conditional | Whether the CBSD antenna is indoors (true) or outdoors (false). |
NAME: antennaAzimuth DATA TYPE: number | REG‑Conditional | Horizontal boresight direction in degrees (0–359). Optional for Cat‑A; REG‑Conditional for Cat‑B. |
NAME: antennaDowntilt DATA TYPE: number | REG‑Conditional | Antenna downtilt in degrees (−90 to +90). Negative = tilted upward. Optional for Cat‑A; REG‑Conditional for Cat‑B. |
NAME: antennaGain DATA TYPE: number | REG‑Conditional | Peak antenna gain in dBi (−127 to +128). |
NAME: eirpCapability DATA TYPE: number | Optional | Max EIRP in dBm/10MHz (−127 to +47). If omitted, SAS uses the rounded‑up FCC certified max. |
NAME: antennaBeamwidth DATA TYPE: number | REG‑Conditional | 3‑dB horizontal beamwidth in degrees (0–360). Optional for Cat‑A; REG‑Conditional for Cat‑B. |
NAME: antennaModel DATA TYPE: string | Optional | External antenna model name (≤128 chars). |
Table 7: GroupParam Object Definition
| Parameter | R/O/C | Description |
|---|---|---|
NAME: groupType DATA TYPE: string | Required | Enumeration field describing the type of group this group ID describes. The following are permitted enumerations: "INTERFERENCE_COORDINATION". Note: Additional group types are expected to be defined in future revisions of this specification. |
NAME: groupId DATA TYPE: string | Required | This field specifies the identifier for this group of CBSDs. |
Table 8: CbsdInfo Object Definition
| Parameter | R/O/C | Description |
|---|---|---|
NAME: vendor DATA TYPE: string | Optional | The name of the CBSD vendor. The maximum length of this string is 64 octets. |
NAME: model DATA TYPE: string | Optional | The name of the CBSD model. The maximum length of this string is 64 octets. |
NAME: softwareVersion DATA TYPE: string | Optional | Software version of this CBSD. The maximum length of this string is 64 octets. |
NAME: hardwareVersion DATA TYPE: string | Optional | Hardware version of this CBSD. The maximum length of this string is 64 octets. |
NAME: firmwareVersion DATA TYPE: string | Optional | Firmware version of this CBSD. The maximum length of this string is 64 octets. |
The CbsdInfo object can be extended with other vendor information in additional key-value pairs.
Table 9: CpiSignatureData Object Definition
| Parameter | R/O/C | Description |
|---|---|---|
NAME: protectedHeader DATA TYPE: string | Required | The value of this parameter is the BASE64-encoded JOSE protected header. This is a JSON object equivalent to the JWT RS256 method or the ES256 method described in RFC 7515 [n.19] Section 3. BASE64 encoding is per RFC 4648 (see [n.20]). Valid values are equivalent to the JSON: { "typ": "JWT", "alg": "RS256" } or { "typ": "JWT", "alg": "ES256" } |
NAME: encodedCpiSignedData DATA TYPE: string | Required | The value of this parameter is the encoded JOSE payload data to be signed by the CPI's private key. This parameter is calculated by taking the BASE64 encoding of a CpiSignedData object (see Table 10) according to the procedures in RFC 7515 [n.19], Section 3. |
NAME: digitalSignature DATA TYPE: string | Required | The value of this parameter is the CPI digital signature applied to the encodedCpiSignedData field. This signature is the BASE64URL encoding of the digital signature, prepared according to the procedures in RFC 7515 [n.19] Section 3, using the algorithm as declared in the protectedHeader field. |
Note: The JOSE JSON Web Signature per RFC-7515 (see [n.19]) is used to ensure data integrity and CPI non-repudiation of the signed parameters. The JOSE compact serialization is formed by concatenating the protectedHeader, encodedCpiSignedData, and digitalSignature fields with "." Characters, as described in section 3 of RFC 7515 [n.19].
Table 10: CpiSignedData Object Definition
| Parameter Name | R/O/C | Description |
|---|---|---|
NAME: fccId DATA TYPE: string | Required | The value of this parameter is the FCC ID of the CBSD. Shall be equal to the fccId parameter value in the enclosing registration request. |
NAME: cbsdSerialNumber DATA TYPE: string | Required | The value of this parameter is the CBSD serial number. Shall be equal to the cbsdSerialNumber of the enclosing registration request. |
NAME: installationParam DATA TYPE: object: InstallationParam | Required | The value of this parameter is the InstallationParam object containing the parameters being certified by the CPI, and only those. |
NAME: professionalInstallerData DATA TYPE: object: ProfessionalInstallerData | Required | The value of this parameter is the data identifying the CPI vouching for the installation parameters included in the installationParam value contained in this object. |
Table 11: ProfessionalInstallerData Object Definition
| Parameter | R/O/C | Description |
|---|---|---|
NAME: cpiId DATA TYPE: string | Required | The value of this parameter is the ID of the CPI providing information to the SAS. This string has a maximum length of 256 octets. |
NAME: cpiName DATA TYPE: string | Required | The value of this parameter is the human readable name of the CPI providing information to the SAS. This string has a maximum length of 256 octets. |
NAME: installCertificationTime DATA TYPE: string | Required | The value of this parameter is the UTC date and time at which the CPI identified in this object certified the CBSD's installed parameters. It is expressed using the format, YYYY-MM-DDThh:mm:ssZ, as defined by [n.7]. |
Table 12: Registration Response Message
| Parameter | R/O/C | Description |
|---|---|---|
NAME: registrationResponse DATA TYPE: array of object: RegistrationResponse | Required | This parameter is an array of RegistrationResponse data objects. Each RegistrationResponse data object represents a registration response to a registration request from a CBSD. |
Table 13: RegistrationResponse Object Definition
| Parameter | R/O/C | Description |
|---|---|---|
NAME: cbsdId DATA TYPE: string | Conditional | This is a CBRS-wide unique identifier for this CBSD. This parameter shall be included if and only if the responseCode indicates SUCCESS. The CBSD shall set its CBSD identity to the value received in this parameter. The string has a maximum length of 256 octets. |
NAME: measReportConfig DATA TYPE: array of string | Optional | SAS uses this parameter to configure CBSD measurement reporting. The measurement report requested by SAS shall be consistent with the CBSD measurement capabilities reported during the registration request. The CBSD shall report the measurement listed in this array. The permitted enumerations are specified in [n.21]. |
NAME: response DATA TYPE: object: Response | Required | This parameter includes information on whether the corresponding CBSD request is approved or disapproved for a reason. See Table 14: Response Object Definition. |
Table 14: Response Object Definition
| Parameter | R/O/C | Description |
|---|---|---|
NAME: responseCode DATA TYPE: number | Required | An integer to indicate the type of result. The value 0 means the corresponding CBSD request is successful. This shall be one of the values in Table 39. |
NAME: responseMessage DATA TYPE: string | Optional | A short description of the result. |
NAME: responseData | Optional | The DATA TYPE is dependent upon the responseCode value. Additional data can be included to help the CBSD resolve failures. |
Table 15: Spectrum Inquiry Request Message
| Parameter | R/O/C | Description |
|---|---|---|
NAME: spectrumInquiryRequest DATA TYPE: array of object: SpectrumInquiryRequest | Required | Array of SpectrumInquiryRequest objects. Each SpectrumInquiryRequest object represents a spectrum inquiry request of a CBSD. |
Table 16: SpectrumInquiryRequest Object Definition
| Parameter | R/O/C | Description |
|---|---|---|
NAME: cbsdId DATA TYPE: string | Required | The CBSD shall set this parameter to the value of its CBSD identity. |
NAME: inquiredSpectrum DATA TYPE: array of object: FrequencyRange | Required | This field describes the spectrum for which the CBSD seeks information on spectrum availability. |
NAME: measReport DATA TYPE: object: MeasReport | Conditional | The CBSD uses this parameter to report measurements to the SAS. The format of the MeasReport object is provided in [n.21]. Refer to section 8 and the measurement capabilities in [n.21] for inclusion rules. |
Table 17: FrequencyRange Object Definition
| Parameter | R/O/C | Description |
|---|---|---|
NAME: lowFrequency DATA TYPE: number | Required | The lowest frequency of the frequency range in Hz. |
NAME: highFrequency DATA TYPE: number | Required | The highest frequency of the frequency range in Hz. |
Table 18: MeasReport Object Definition
| Parameter | R/O/C | Description |
|---|---|---|
| The parameters of this object are defined in [n.21]. |
Table 19: Spectrum Inquiry Response Message
| Parameter | R/O/C | Description |
|---|---|---|
NAME: spectrumInquiryResponse DATA TYPE: array of object: SpectrumInquiryResponse | Required | Array of SpectrumInquiryResponse objects. Each SpectrumInquiryResponse object represents a spectrum inquiry response to a spectrum inquiry request of a CBSD. |
Table 20: SpectrumInquiryResponse Object Definition
| Parameter | R/O/C | Description |
|---|---|---|
NAME: cbsdId DATA TYPE: string | Conditional | This parameter is included if and only if the cbsdId parameter in the SpectrumInquiryRequest object contains a valid CBSD identity. If included, the SAS shall set this parameter to the value of the cbsdId parameter in the corresponding SpectrumInquiryRequest object. |
NAME: availableChannel DATA TYPE: array of object: AvailableChannel | Conditional | This parameter is an array of zero or more data objects, AvailableChannel , which describes a channel that is available for the CBSD, see Table 21. Included: If and only if the Spectrum Inquiry is successful. |
NAME: response DATA TYPE: object: Response | Required | This parameter includes information on whether the corresponding CBSD request is approved or disapproved for a reason. See Table 14: Response Object Definition. |
Table 21: AvailableChannel Object Definition
| Parameter | R/O/C | Description |
|---|---|---|
NAME: frequencyRange DATA TYPE: object: FrequencyRange | Required | This parameter is the frequency range of the available channel, see Table 17. |
NAME: channelType DATA TYPE: string | Required | "PAL": the frequency range is a PAL channel. "GAA": the frequency range is for GAA use. |
NAME: ruleApplied DATA TYPE: string | Required | The regulatory rule used to generate this response, e.g., “FCC_PART_96”. |
NAME: maxEirp DATA TYPE: number | Optional | Maximum EIRP likely to be permitted for a Grant on this frequencyRange, given the CBSD registration parameters, including location, antenna orientation and antenna pattern. The maximum EIRP is in the units of dBm/MHz and is an integer or a floating point value between -137 and +37 (dBm/MHz) inclusive. |
Table 22: Grant Request Message
| Parameter | R/O/C | Description |
|---|---|---|
NAME: grantRequest DATA TYPE: array of object: GrantRequest | Required | Array of GrantRequest objects. Each GrantRequest object represents a Grant request of a CBSD. |
A GrantRequest object contains operating parameters that the CBSD plans to operate with. Operation parameters include a continuous segment of spectrum and the maximum EIRP.
Table 23: GrantRequest Object Definition
| Parameter | R/O/C | Description |
|---|---|---|
NAME: cbsdId DATA TYPE: string | Required | The CBSD shall set this parameter to the value of its CBSD identity. |
NAME: operationParam DATA TYPE: object: OperationParam | Required | This data object includes operation parameters of the requested Grant. |
NAME: measReport DATA TYPE: object: MeasReport | Conditional | The CBSD uses this parameter to report measurements to the SAS. The format of the MeasReport object is provided in [n.21]. Refer to section 8 and [n.21] for inclusion rules. |
Table 24: OperationParam Object Definition
| Parameter | R/O/C | Description |
|---|---|---|
NAME: maxEirp DATA TYPE: number | Required | Maximum EIRP permitted by the Grant. The maximum EIRP is in the units of dBm/MHz and is an integer or a floating point value between -137 and +37 (dBm/MHz) inclusive. The value of maxEirp represents the average (RMS) EIRP that would be measured per the procedure defined in FCC §96.41(e)(3) and shall not exceed eirpCapability - 10. |
NAME: operationFrequencyRange DATA TYPE: object: FrequencyRange | Required | This parameter is frequency range of a contiguous segment. |
Table 25: Grant Response Message
| Parameter | R/O/C | Description |
|---|---|---|
NAME: grantResponse DATA TYPE: array of object: GrantResponse | Required | Array of GrantResponse objects. Each GrantResponse object represents a Grant response to a Grant request of a CBSD. |
Table 26: GrantResponse Object Definition
| Parameter | R/O/C | Description |
|---|---|---|
NAME: cbsdId DATA TYPE: string | Conditional | This parameter is included if and only if the cbsdId parameter in the GrantRequest object contains a valid CBSD identity. If included, the SAS shall set this parameter to the value of the cbsdId parameter in the corresponding GrantRequest object. |
NAME: grantId DATA TYPE: string | Conditional | An ID provided by the SAS for this Grant. Included: If and only if the Grant request is approved by the SAS. The CBSD shall set the Grant identity for this Grant to the value received in this parameter. |
NAME: grantExpireTime DATA TYPE: string | Conditional | The grantExpireTime indicates the time when the Grant associated with the grantId expires. This parameter is UTC time expressed in the format, YYYY- MM-DDThh:mm:ssZ as defined by [n.7]. This parameter shall be included if and only if the responseCode parameter indicates SUCCESS. If the channelType parameter is included in this object and the value is set to "PAL", the grantExpireTime parameter shall be set to the value that does not extend beyond the licenseExpiration of the corresponding PAL recorded in the PAL Database [n.23]. |
NAME: heartbeatInterval DATA TYPE: number | Conditional | This parameter is a positive integer and indicates the maximum time interval in units of seconds between two consecutive heartbeat requests that the CBSD should attempt to meet. This parametershall be included if the responseCode parameter indicates SUCCESS. |
NAME: measReportConfig DATA TYPE: array of string | Optional | The SAS uses this parameter to configure CBSD measurement reporting. The measurement report requested by the SAS shall be consistent with the CBSD measurement capabilities reported during the registration request. The CBSD shall report the measurements listed in this array. The permitted enumerations are specified in [n.21]. |
NAME: operationParam DATA TYPE: object: OperationParam | Optional | If the Grant request is disapproved, using this object the SAS can optionally provide a new set of operation parameters to the CBSD for use in a new Grant request. |
NAME: channelType DATA TYPE: string | Conditional | This parameter is included if and only if the responseCode parameter indicates SUCCESS, i.e., the Grant request was successful. "PAL": the frequency range is a PAL channel. "GAA": the frequency range is for GAA use. |
NAME: response DATA TYPE: object: Response | Required | This parameter includes information on whether the corresponding CBSD request is approved or disapproved for a reason. See Table 14. |
Table 27: Heartbeat Request Message
| Parameter | R/O/C | Description |
|---|---|---|
NAME: heartbeatRequest DATA TYPE: array of object: HeartbeatRequest | Required | Array of HeartbeatRequest objects. Each HeartbeatRequest object represents a heartbeat request of a CBSD. |
Table 28: HeartbeatRequest Object Definition
| Parameter | R/O/C | Description |
|---|---|---|
NAME: cbsdId DATA TYPE: string | Required | The CBSD shall set this parameter to the value of its CBSD identity. |
NAME: grantId DATA TYPE: string | Required | The CBSD shall set this parameter to the value of the Grant identity of this Grant. |
NAME: grantRenew DATA TYPE: boolean | Optional | If set to True, the CBSD asks for renewal of the current Grant. SAS shall include a grantExpireTime parameter in the following HeartbeatResponse object. |
NAME: operationState DATA TYPE: string | Required | This parameter contains the CBSD operation state (“AUTHORIZED” or “GRANTED”). |
NAME: measReport DATA TYPE: object: MeasReport | Conditional | The CBSD uses this parameter to report measurements to the SAS. The format of the MeasReport object is provided in [n.21]. Refer to section 8 and [n.21] for inclusion rules. |
Table 29: Heartbeat Response Message
| Parameter | R/O/C | Description |
|---|---|---|
NAME: heartbeatResponse DATA TYPE: array of object: HeartbeatResponse | Required | Array of HeartbeatResponse objects. Each HeartbeatResponse object represents a heartbeat response of a CBSD. |
Table 30: HeartbeatResponse Object Definition
| Parameter | R/O/C | Description |
|---|---|---|
NAME: cbsdId DATA TYPE: string | Conditional | This parameter is included if and only if the cbsdId parameter in the HeartbeatRequest object contains a valid CBSD identity. If included, the SAS shall set this parameter to the value of the cbsdId parameter in the corresponding HeartbeatRequest object. |
NAME: grantId DATA TYPE: string | Conditional | This parameter is included if and only if the grantId parameter in the HeartbeatRequest object contains a valid Grant identity. If included, the SAS shall set this parameter to the value of the grantId parameter in the corresponding HeartbeatRequest object. |
NAME: transmitExpireTime DATA TYPE: string | Required | The CBSD shall cease transmission using the SAS authorized radio resource within 60 seconds after the value of the transmitExpireTime parameter expires, in accordance with part 96.39(c)(2) (ref. [n.8]). The transmitExpireTime is UTC time expressed in the format, YYYY- MM-DDThh:mm:ssZ as defined by [n.7]. The transmitExpireTime value shall be no later than the grantExpireTime . |
NAME: grantExpireTime DATA TYPE: string | Conditional | Required if the responseCode parameter indicates SUCCESS or SUSPENDED_GRANT and the grantRenew parameter was included and set to True in the corresponding HeartbeatRequest object. This parameter may be included at other times by SAS choice. When included, if the channelType of this Grant is “PAL”, this parameter shall be set to the value that does not extend beyond the licenseExpiration of the corresponding PAL recorded in the PAL Database [n.23]. |
NAME: heartbeatInterval DATA TYPE: number | Optional | This parameter is a positive integer and indicates the maximum time interval in units of seconds between two consecutive heartbeat requests that the CBSD should attempt to meet. This parameter is included when the SAS wants to change the heartbeat interval. |
NAME: operationParam DATA TYPE: object: OperationParam | Optional | If heartbeat request is disapproved or the SAS intends to change the CBSD operation parameters, the SAS can provide a new set of operation parameters to the CBSD using this object as a recommendation to request a new Grant |
NAME: measReportConfig DATA TYPE: array of string | Optional | The SAS uses this parameter to configure CBSD measurement reporting. The measurement report requested by the SAS shall be consistent with the CBSD measurement capabilities reported during the registration request. The CBSD shall report the measurement listed in this array. The permitted enumerations are specified in [n.21]. |
NAME: response DATA TYPE: object: Response | Required | This parameter includes information on whether the corresponding CBSD request is approved or disapproved for a reason. See Table 14. |
Table 31: Relinquishment Request Message
| Parameter | R/O/C | Description |
|---|---|---|
NAME: relinquishmentRequest DATA TYPE: array of object: RelinquishmentRequest | Required | Array of RelinquishmentRequest objects. Each RelinquishmentRequest object Represents a relinquishment request of a CBSD. |
Table 32: RelinquishmentRequest Object Definition
| Parameter | R/O/C | Description |
|---|---|---|
NAME: cbsdId DATA TYPE: string | Required | The CBSD shall set this parameter to the value of its CBSD identity. |
NAME: grantId DATA TYPE: string | Required | The CBSD shall set this parameter to the value of the Grant identity of this Grant. |
Table 33: Relinquishment Response Message
| Parameter | R/O/C | Description |
|---|---|---|
NAME: relinquishmentResponse DATA TYPE: array of object: RelinquishmentResponse | Required | Array of RelinquishmentResponse objects. Each RelinquishmentResponse object represents a relinquishment response to a relinquishment request of a CBSD. |
10.10.1RelinquishmentResponse object
Table 34: RelinquishmentResponse Object Definition
| Parameter | R/O/C | Description |
|---|---|---|
NAME: cbsdId DATA TYPE: string | Conditional | This parameter is included if and only if the cbsdId parameter in the RelinquishmentRequest object contains a valid CBSD identity. If included, the SAS shall set this parameter to the value of the cbsdId parameter in the corresponding RelinquishmentRequest object. |
NAME: grantId DATA TYPE: string | Conditional | This parameter is included if and only if the grantId parameter in the RelinquishmentRequest object contains a valid Grant identity. If included, the SAS shall set this parameter to the value of the grantId parameter in the corresponding RelinquishmentRequest object. |
NAME: response DATA TYPE: object: Response | Required | This parameter includes information on whether the corresponding CBSD request is approved or disapproved for a reason. See Table 14: Response Object Definition. |
Table 35: Deregistration Request Message
| Parameter | R/O/C | Description |
|---|---|---|
NAME: deregistrationRequest DATA TYPE: array of object: DeregistrationRequest | Required | Array of DeregistrationRequest data objects. Each DeregistrationRequest data object represents a deregistration request of a CBSD. |
Table 36: DeregistrationRequest Object Definition
| Parameter | R/O/C | Description |
|---|---|---|
NAME: cbsdId DATA TYPE: string | Required | The CBSD shall set this parameter to the value of its CBSD identity. |
Table 37: Deregistration Response Message
| Parameter | R/O/C | Description |
|---|---|---|
NAME: deregistrationResponse DATA TYPE: array of object: DeregistrationResponse | Required | Array of DeregistrationResponse data objects. Each DeregistrationResponse data object represents a deregistration response to a deregistration request of a CBSD. |
Table 38: DeregistrationResponse Object Definition
| Parameter | R/O/C | Description |
|---|---|---|
NAME: cbsdId DATA TYPE: string | Conditional | This parameter is included if and only if the cbsdId parameter in the DeregistrationRequest object contains a valid CBSD identity. If included, the SAS shall set this parameter to the value of the cbsdId parameter in the corresponding DeregistrationRequest object. |
NAME: response DATA TYPE: object: Response | Required | This parameter includes information on whether the corresponding CBSD request is approved or disapproved for a reason. See Table 14: Response Object Definition. |
In the Response object of a SAS-CBSD response message, the SAS shall include a responseCode parameter to inform the CBSD of the status of the corresponding request. The response codes are grouped into the following categories and defined in the following table. The name associated with each responseCode parameter is not included in the Response object, but can be attached to a responseCode parameter by the CBSD or other network entity for logging or human-involved troubleshooting.
Table 39: Response Code Definitions
| responseCode | Name | Description |
|---|---|---|
| 0 | SUCCESS | CBSD request is approved by SAS |
| 100 | VERSION | SAS protocol version used by CBSD is not supported by SAS |
| 101 | BLACKLISTED | CBSD is blacklisted. This responseCode is returned if the CBSD is under a SAS or FCC enforcement action and is barred from CBRS operation. In general, the CBSD should not try to re-register until actions external to this specification are taken. Note: Blacklisting behavior by the SAS and CBSD is FFS. |
| 102 | MISSING_PARAM | Required parameters missing |
| 103 | INVALID_VALUE | One or more parameters have invalid value |
| 104 | CERT_ERROR | There is an error in the certificate used to make the request (e.g. the credential is of the wrong role). Note: Most certificate errors, such as expired or syntactically invalid certificates, will cause errors at the TLS connection. |
| 105 | DEREGISTER | A CBSD receiving this responseCode is automatically deregistered by the SAS. The CBSD shall cease all transmissions, terminate all Grants, and consider itself Unregistered. The SAS may include this responseCode parameter in any message. The responseMessage parameter may contain a string describing the reason for deregistration. See NOTE 1 below. |
| 200 | REG_PENDING | Incomplete registration information. The registration process is pending. One or more REG-Conditional parameters have not yet been supplied to the SAS. The CBSD is likely to accomplish a successful registration when the missing registration information is made available to the SAS. |
| 201 | GROUP_ERROR | An error has been identified in the grouping parameters of the CBSD. |
| 300 | UNSUPPORTED_SPECTRUM | The frequency range indicated in the spectrum inquiry request or grant request is at least partially outside of the CBRS band. |
| 400 | INTERFERENCE | Requested operation parameters cause too much interference. This responseCode value indicates that the Grant request is unlikely to be successful if retried by the CBSD. |
| 401 | GRANT_CONFLICT | Conflict with an existing Grant of the same CBSD. The CBSD should be able to remediate this using the data returned in the responseData structure, by synchronizing its Grant state with the SAS and relinquishing any out-of-sync Grants. |
| 500 | TERMINATED_GRANT | The Grant is terminated. This condition occurs if, for example, incumbent status has changed permanently causing the current Grant to terminate. The CBSD shall terminate radio operation by turning off its radio transmission associated with this Grant within 60 seconds after the value of the transmitExpireTime parameter expires, in accordance with part 96.39(c)(2) (ref. [n.8]). The Grant is considered terminated by the SAS, but the CBSD may relinquish the Grant. If the operationParam parameter is included in the HeartbeatResponse object, the CBSD should consider it as a recommendation by the SAS to obtain a new Grant using the included operational parameter values, and may request a new Grant using those operational parameters. |
| 501 | SUSPENDED_GRANT | The Grant is suspended. This condition occurs if incumbent status has changed temporarily. The CBSD shall terminate radio operation by turning off its radio transmission associated with this Grant within 60 seconds after the value of the transmitExpireTime parameter expires, in accordance with part 96.39(c)(2) (ref. [n.8]). In such a case the CBSD may continue to send HeartbeatRequest objects and waiting until the Grant is re-enabled, or may relinquish the Grant and request another. If the operationParam parameter is included in the HeartbeatResponse object, the CBSD should consider it as a recommendation by the SAS to obtain a new Grant using the included operational parameter values, and may request a new Grant using those parameters. |
| 502 | UNSYNC_OP_PARAM | The Grant state is out of sync between the CBSD and the SAS. The CBSD shall turn off the radio transmission associated with this Grant within 60 seconds from receiving this responseCode value, in accordance with Part 96.39(c)(2) (ref. [n.8]), and shall relinquish this Grant. |
NOTE 1 (Informative): This is an assistive responseCode parameter value to reset the CBSD out of a situation where it is out of sync with the SAS and there is no easier solution than to reset the registration. Examples are: The CBSD has been deregistered by the owner or deregistration is required by authorities, and presumably the CBSD needs to refresh its local configuration management.
In the Response object, the SAS can optionally include supplemental data (e.g., using the responseData parameter) to help the CBSD with further investigation of the error. The following table describes supplemental data to be included with some responseCode values.
Table 40: responseData Definitions
| responseCode Value | Name | responseData Data Type / Description of error data |
|---|---|---|
| 0 | SUCCESS | Not present |
| 100 | VERSION | array of string — Protocol versions supported by the SAS administrator |
| 101 | BLACKLISTED | Not present |
| 102 | MISSING_PARAM | array of string — A list of missing parameters |
| 103 | INVALID_VALUE | array of string — A list of parameters names with invalid values |
| 104 | CERT_ERROR | Not present |
| 105 | DEREGISTER | Not present |
| 200 | REG_PENDING | array of string — A list of missing registration parameters |
| 201 | GROUP_ERROR | Not present |
| 300 | UNSUPPORTED_SPECTRUM | Not present |
| 400 | INTERFERENCE | Not present |
| 401 | GRANT_CONFLICT | array of string — The Grant ID of an existing Grant that causes the conflict. |
| 500 | TERMINATED_GRANT | Not present |
| 501 | SUSPENDED_GRANT | Not present |
| 502 | UNSYNC_OP_PARAM | Not present |
Pages