CBRS Operating Requirements - 2.0

CBRS Operational and Functional Requirements (Release 2)

Document WINNF-TS-1001

Version V1.7.0 28

February 2025

TERMS, CONDITIONS & NOTICES

This document has been prepared by the CBRS Committee Work Group 1 (Operational and Functional Requirements) 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 CBRS Committee Work Group 1 (Operational and Functional Requirements).

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 a patent ("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 non-members alike) desiring to implement this specification. Information may be obtained from:

Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134

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.

Contributors

The following individuals made significant contributions to this document:

Editor: Orlett W. Pearson (Nokia) Group Chair: Andrew Clegg (Google)

Other Member Representatives:

• Serge Barbosa Da Torre (Google)
• Kumar Balachandran (Ericsson)
• Richard Bernhardt (WISPA)
• Gary Boudreau (Ericsson)
• Virgil Cimpu (Ericsson)
• Sho Furuichi (Sony)
• Fred Goldstein (WISPA)
• Dave Gurney (Motorola Solutions)
• Ariful Hannan (CommScope)
• Ariful Hannan (Google)
• Navin Hathiramani (Nokia)
• Yi Hsuan (Google)
• Chris Kurby (iPosi)
• Masoud Olfat (Federated Wireless)
• Naotaka Sato (Sony)
• Dawn Szelc (MITRE)

CBRS Operational and Functional Requirements (Release 2)

1 Introduction and Scope

The document defines Release 2 requirements on the Spectrum Access System (SAS), Citizens Broadband Radio Service Device (CBSD), End User Device (EUD), Priority Access License (PAL), and General Authorized Access (GAA) to specify the necessary operation and standards interfaces to effect a properly functioning spectrum sharing environment in the 3550-3700 MHz band.

Note: Every SAS and CBSD must go through FCC certification based on Release 1. Release 2 features and capabilities are in addition to, not instead of, Release 1.

2 Background and Principles of Release 2 Operation

It is expected that a mix of Release 1 and Release 2 SASs and CBSDs will coexist in the CBRS ecosystem for the foreseeable future. Note that FCC changes to Part 96 are, and will continue to be, included in Release 1.

Adoption of Release 2 is not mandatory. Any SAS or CBSD that supports Release 2 must function like a Release 1 SAS or CBSD when communicating with a Release 1 SAS or CBSD.

At a minimum, a SAS or CBSD supporting Release 2 must implement the Feature Capability Exchange defined in Section 6, which is the foundation for interworking between a SAS and a CBSD as well as among SASs with different releases or different support of Release 2 features. Adoption of any other Release 2 feature is optional, and the Feature Capability Exchange supports selective implementation of Release 2 optional features. If a SAS or CBSD does not successfully perform a Feature Capability Exchange with another SAS or CBSD, it must revert to Release 1 behavior when communicating with that SAS or CBSD (See Table 1).

Table 1: SAS/CBSD Operation Mode

Using the Feature Capability Exchange, SASs and CBSDs can inquire about optional Release 2 features from another SAS or CBSD or inform other Release 2 SASs and CBSDs about implementation of such features.

As part of backward compatibility with Release 1, careful consideration must be given to features impacting any coordination among SASs including features requiring substantial similarity in performing incumbent protection or other activities.

Section 6 defines the requirements to address inter-release operability as noted above and the Annexes define optional Release 2 features (unless otherwise stated) and requirements for their use.

The adoption of certain Release 2 optional features could impact the certification status of SAS and/or CBSD if they are used in certain operations. Such features are called "Regulatory Impacting features". The adoption of the other Release 2 features will not impact the certification status of SAS and/or CBSD even if they are used. Such features are called "Non-Regulatory Impacting features". Therefore, care has been taken in the Annexes to separate Regulatory Impacting features and Non-Regulatory Impacting features. Conformance with Non-Regulatory Impacting features can be asserted following the WInnForum's CBRS Release 2 Self Testing Policy [n.7]. Use of Regulatory Impacting features is subject to certification and approval by the FCC. CBSDs incorporating Release 2 Non-Regulatory Impacting features will not receive any special treatment by the SAS in calculating protection of Protected Entities. For the definition of "features", refer to [14].

Table 2 below describes the incumbent protection process used as part of interoperability between multiple SASs for a particular Regulatory Impacting Feature X. The incumbent protection method could include the IAP process or DPA Move List (DPA ML) calculation. In this table, the "Peer SAS" refers to the worst case peer SAS managing CBSDs located in the same neighborhood of a particular Protected Entity as the collection of CBSDs managed by "Managing SAS". If there are multiple peers SASs and all of the peer SASs support Feature X, the term Peer SAS could refer to any of those SASs. Otherwise "worst case" refers to the Peer SAS that does not support Feature X.

Table 2: Incumbent protection operation in multi-SAS interoperability

Note 1: Step 1: For DPA protection, no additional operations are required.
Step 2: For IAP Protected Entities, if Managing SAS does not support optional MSIRI (Annex 12), no additional operations are required.
Step 3: For IAP Protected Entities, if Managing SAS supports optional MSIRI (Annex 12), perform additional IAP using the IMG definition in Annex 12.

Figure 1 describes the architecture of requirements defined in Release 2.

Figure 1: Requirement Structure in this document

3 Keywords or Requirements Language

The following terms are used within this document and should be interpreted as described in RFC-2119:

• SHALL is a mandatory requirement (negative is SHALL NOT)
• SHOULD is recommended requirement/best practice (negative is SHOULD NOT)
• MAY is an optional requirement, i.e., something that is allowed (negative is NEED NOT)

When applicable, "shall" and "shall not" identify requirements that are mandatory for compliance with Release 2 features with no deviations from this standard. "Should" and "should not" indicate that a particular action is preferred but not necessarily required, or that (in the negative form) a certain possibility or course of action is discouraged but not prohibited. "May" and "need not" indicate a course of action permissible within the limits of the standard. "Can" and "cannot" are used for statements of possibility and capability, whether material, physical, or causal.

4 Requirement Organization

Requirements shall be uniquely identified by: REL-R#---. Where

• REL-: Applies to the WInnForum document Release Number
• R0-: Requirements directly from FCC Rules
  • R1-: Requirements derived from FCC Rules
  • R2-: Requirements imposed by WInnForum to meet FCC Rules
  • R3-: Requirements imposed by WInnForum to meet industry needs.
  • <CATEGORY> is enumerated
  • <XX>: Unique number to identify the requirement
  • <Y>: Optional and used to identify subordinate requirements, typically captured in an alphabetical list following the main requirement number (e.g., REL2-R0-IPM-01 a).

5 Definitions and Abbreviations

Protected Entity. An entity that receives interference protection from CBSDs. Such entities include federal incumbents, fixed-satellite service (FSS) earth stations, grandfathered wireless protection zones (GWPZ), PAL protection areas (PPA), environmental sensing capability (ESC) sensors, quiet zones, and certain international border areas. Some of these entities may be operating at frequencies outside of 3550 to 3700 MHz.

NOTE: The protection of grandfathered wireless protection zones (GWPZ) expired January 2022.

IAP Protected Entity: Any Protected Entity that is protected using Iterative Allocation Process (IAP) as defined in R2-SGN-16 in [1].

NOTE: The IAP Protected Entities include fixed-satellite service (FSS) earth stations, PAL protection areas (PPA), and environmental sensing capability (ESC) sensors.

Any other previously undefined terms and abbreviations first used in the current version of this document are defined above. All previously defined terms and abbreviations are available at https://cbrs.wirelessinnovation.org/acronyms. Feature-specific definitions are also captured in their associated annex and are included in this reference.

6 Mandatory Requirements for Release 2

The following provides the requirements that are mandatory for operation in Release 2. Section 6.1 provides the requirements for Feature Capability Exchange, which is the foundation for interworking between a SAS and a CBSD, as well as among SASs, to operate using common supported Release 2 features. The other foundational requirements specified in section 6.2 apply to all CBSD/DPs or SASs that support any Release 2 feature, both Non-Regulatory Impacting and Regulatory Impacting features (referred to as Release 2 CBSD/DP or Release 2 CBSD, or Release 2 SAS).

6.1 Feature Capability Exchanges

6.1.1 Feature Description

Feature Capability Exchange must be used for recognition of the "Release" supported by a peer entity and for exchanging supported Release 2 feature information with Release 2 entities.

A Release 2 SAS communicates with a Release 2 CBSD/DP using the SAS-CBSD/DP protocol defined by WG3 [2], and vice versa. A Release 2 SAS communicates with a peer Release 2 SAS using the SAS-SAS protocol defined by WG3 [3].

6.1.2 SAS General Requirements (SGN)

REL2-R3-SGN-01: Identification of Release 1 Entities

• a. A Release 2 SAS shall manage any CBSD/DP that does not exchange feature capabilities with it as a Release 1 CBSD/DP in accordance with WINNF-TS-0016 [6] and WINNF-TS-0112 [1]
• b. A Release 2 SAS shall function with any SAS that does not exchange feature capabilities with it as if it were a Release 1 SAS in accordance with WINNF-TS-0096 [12] and WINNF-TS-0112[1]

REL2-R3-SGN-02: Release 2 SAS to CBSD Feature Capability Exchange

• a. Any Release 2 SAS shall support feature capability exchange with its Release 2 managed CBSD/DPs only at CBSD Registration.
  • i. Any Release 2 SAS shall exchange its support of Release 2 optional features with its Release 2 managed CBSD/DPs only at CBSD Registration.
  • ii. Deprecated
• b. Any Release 2 SAS may exchange its support of proprietary features with its managed CBSD/DPs by using feature capability exchange only at CBSD Registration.

REL2-R3-SGN-03: Any Release 2 SAS shall exchange feature capability with all other Release 2 SASs.

REL2-R3-SGN-04: Deprecated

REL2-R3-SGN-05: Any Release 2 SAS shall support the feature capability exchange of any update of Release 2 optional features with all other Release 2 SASs.

6.1.3 CBSD and EUD Requirements (DEV)

REL2-R3-DEV-01: A Release 2 CBSD/DP that does not receive a feature capability exchange from its Managing SAS shall communicate with the SAS as a Release 1 CBSD/DP in accordance with WINNF-TS-0016 [6].

REL2-R3-DEV-02: Release 2 CBSD to SAS Feature Capability Exchange. Any Release 2 CBSD/DP shall support feature capability exchange only at CBSD Registration with its Release 2 managing SAS.

• a. Deprecated
• b. Any Release 2 CBSD/DP shall exchange only at CBSD Registration its support of Release 2 optional features it intends to use with its Release 2 managing SAS.

REL2-R3-DEV-03: Deprecated

6.2Other Foundational Requirements

6.2.1 Description

This section provides Release 2 foundation requirements other than Feature Capability Exchange. In this version of this technical specification, those include the following:

• Use of Non-Regulatory Impacting Release 2 features in SAS-CBSD communication
• Use of Regulatory Impacting Release 2 features for protection of Protected Entities

6.2.2 SAS General Requirements (SGN)

REL2-R2-SGN-31: Any Release 2 SAS shall support communication with any Release 1 CBSD/DP in accordance with WINNF-TS-0016 [6].

REL2-R2-SGN-32: Any Release 2 SAS shall support communication with any Release 1 SAS in accordance with WINNF-TS-0096 [12].

REL2-R3-SGN-06: SAS Use of Regulatory Impacting Release 2 Features for Protection of Protected Entities

NOTE 1: In this requirement, "Regulatory Impacting Release 2 feature" refers to Regulatory Impacting Release 2 feature impacting protection of a Protected Entity.

• a. If all CBSDs located inside the neighborhood of a Protected Entity (see R2-SGN-16 as specified in [1]) or a DPA are managed by the same Release 2 SAS, then the managing Release 2 SAS may use a Release 2 optional feature if it is capable of utilizing the feature, for the purpose of performing protection of that Protected Entity or DPA.

• b. If the Release 2 SAS is the only SAS that manages all CBSDs located inside the neighborhood of a Protected Entity, then the Release 2 SAS may use a Regulatory Impacting Release 2 feature for protection of that Protected Entity1. (REL2-R3-SGN-06-b defines the mandatory SAS behavior for usage of a Regulatory Impacting Release 2 feature when CBSDs managed by only one managing SAS impact the Protected Entity)

NOTE 2: The neighborhood distance is defined in R2-SGN-29 (for FSS TT&C), R2-SGN-24 (for DPA) and R2-SGN-16 (for IAP Protected Entities). The same neighborhood distance is applied to the remainder of this requirement. NOTE 3: How to apply Release 2 features to each protection methodology is feature specific and will be defined in the context of each feature.

• c. If the collection of CBSDs located inside the neighborhood of a Protected Entity are managed by the Release 2 SAS and at least one peer SAS, and if all the SASs managing those CBSDs support a Regulatory Impacting Release 2 feature, the Release 2 SAS shall use the Regulatory Impacting Release 2 feature for protection of that Protected Entity2 .
• d. If the collection of CBSDs located inside the neighborhood of a Protected Entity are managed by the Release 2 SAS and at least one peer SAS and if at least one peer SAS does not support a Regulatory Impacting Release 2 feature, then the Release 2 SAS shall perform the protection of the Protected Entity without using the Regulatory Impacting Release 2 feature.3

NOTE 4: IAP, DPA Move List calculation, or FSS Purge List calculation will be performed by using only Release 1 functions. NOTE 5: For IAP Protected Entities, the Release 2 SAS can use additional steps defined in Annex 12 for use of the Regulatory Impacting Release 2 feature beyond IAP as per REL2-R3-SGN-06-d above.

REL2-R3-SGN-07: Deprecated

REL2-R3-SGN-08: Deprecated

REL2-R3-SGN-09: SAS Use of Non-Regulatory Impacting Release 2 Features:

• a. For interworking with a Release 2 CBSD supporting Non-Regulatory Impacting Release 2 features, the Release 2 SAS shall use the Non-Regulatory Impacting Release 2 features that it supports which are also supported by the Release 2 CBSD.

• b. For interworking with other Release 2 SAS(s) supporting Non-Regulatory Impacting Release 2 features, the Release 2 SAS shall use the Non-Regulatory Impacting Release 2 features that it supports which are also supported by the other Release 2 SAS(s).

NOTE: REL2-R3-SGN-06-c defines the mandatory SAS behavior for usage of a Regulatory Impacting Release 2 feature when CBSDs managed by more than one managing SAS impacting the Protected Entity, all supporting the Release 2 feature.

NOTE: REL2-R3-SGN-06-d defines the mandatory SAS behavior for usage of a Regulatory Impacting Release 2 feature when CBSDs managed by more than one managing SAS impacting the Protected Entity and at least one of SASs does not support the Release 2 feature.

6.2.3 CBSD and EUD Requirements (DEV)

REL2-R2-DEV-04: Any Release 2 CBSD/DP shall support and be able to communicate with any Release 1 SAS.

REL2-R2-DEV-05: Any Release 2 CBSD/DP shall follow instructions from its Managing SAS regardless of the SAS being Release 1 or Release 2.

REL2-R3-DEV-04: For interworking with its Managing Release 2 SAS supporting Release 2 features, the Release 2 CBSD shall use the Release 2 features which are also supported by the Managing Release 2 SAS.

7 References

• [1] Requirements for Commercial Operation in the U.S. 3550 3700 MHz Citizens Broadband Radio Service Band, WINN-TS-0112 available at: https://cbrs.wirelessinnovation.org/release-1-standards-specifications
• [2] Signaling Protocols and Procedures for Citizens Broadband Radio Service (CBRS): Extensions to Spectrum Access System (SAS) – Citizens Broadband Radio Service Device (CBSD) Interface Technical Specification (Release 2), WINNF-TS-3002.
• [3] Signaling Protocols and Procedures for Citizens Broadband Radio Service (CBRS): Extensions to Spectrum Access System (SAS) – SAS Interface Technical Specification (Release 2), WINNF-TS-3003
• [4] T. Vincenty, "Direct And Inverse Solutions Of Geodesics On The Ellipsoid With Application Of Nested Equations", Survey Review, Volume 23, Issue 176 (01 April 1975), pp. 88-93.
• [5] https:// www.its.bldrdoc.gov/media/50674/itm.pdf section §47
• [6] Signaling Protocols and Procedures for Citizens Broadband Radio Service (CBRS): Spectrum Access System (SAS) – Citizens Broadband Radio Service Device (CBSD) Interface Technical Specification (Release 1), WINNF-TS-0016.
• [7] CBRS Release 2 Self Testing Policy, WINNF-TS-4005
• [8] WInnForum Recognized Grouping Information, WINNF-SSC-0010
• [9] Test and Certification for Citizens Broadband Radio Service (CBRS); Conformance and Performance Test Technical Specification; SAS as Unit Under Test (UUT), WINNF-TS-0061
• [10] WInnForum CBRS Protection Margin Policy, WINNF-SSC-0007
• [11] https://apps.fcc.gov/oetcf/kdb/forms/FTSSearchResultPage.cfm?switch=P&id=20673
• [12] Signaling Protocols and Procedures for Citizens Broadband Radio Service (CBRS): Spectrum Access System (SAS) – SAS Interface Technical Specification (Release 1), WINNF-TS-0096.
• [13] WINNF-SSC-0002, "Signaling Protocols and Procedures for Citizens Broadband Radio Service (CBRS): WInnForum Recognized CBRS Air Interfaces and Measurements", Wireless Innovation Forum
• [14] WINNF-SSC-0004, "SSC Release Plan", Wireless Innovation Forum

Annex 1 Enhanced CBSD Group Handling (Optional)

Annex 1.1 Feature Description

This feature enhances the existing Group handling function to support additional grouping information exchange between Release 2 CBSD/DPs and Release 2 SASs.

This feature does not specify any particular Group types, and it only supports the capability to exchange the grouping information and grouping configuration information. Also, this feature does not specify any special treatment of CBSDs nor Group-specific management policy.

Annex 1.2 Use for Operations not Impacting Part 96 Regulatory Compliance

The Enhanced CBSD Group Handling feature does not affect protection of Protected Entities, so does not impact Part 96 regulatory compliance. CBSDs using this feature will not receive any special treatment by SASs in calculation of protection of Protected Entities.

Any special treatment or Group-specific management policy including whether they may impact Part 96 regulatory compliance will be defined in the Annex associated with a specific Group type.

Annex 1.2.1 SAS General Requirements (SGN)

REL2-R3-SGN-12100: Group Applicability

• a. A SAS may support any Group type specified in this specification or WINNF-SSC-0010 [8]
• b. A SAS may handle Coexistence Group (defined in WINNF-TS-0112 [1]) during the Release 2 operation using this feature.

REL2-R3-SGN-12101: Grouping Information

• a. Upon reception of grouping information from a CBSD/DP, a SAS shall notify the CBSD/DP of whether it operationally supports the reported Group type(s) and Group ID(s).
• b. A SAS may notify the CBSD/DP of its operationally support of Group type(s) and Group ID(s) at any time.
• c. A SAS may exchange the grouping information of the registered CBSDs with its peer SASs.
• d. A SAS shall consider the CBSD as disassociated with a Group previously reported to the SAS if the latest reported grouping information received from the CBSD or the DP managing the CBSD does not include the information associated with the Group.

REL2-R3-SGN-12102: Grouping Configuration Information

• a. A SAS may notify the CBSD/DP of the grouping configuration information for the mutually supported Group type(s) and Group ID(s) at any time.
• b. A SAS may exchange the grouping configuration information of the registered CBSDs with its peer SASs.

Annex 1.2.2 CBSD and EUD Requirements (DEV)

REL2-R3-DEV-12200: Group Applicability

• a. A CBSD may choose to support any Group type specified in this specification or in WINNF-SSC-0010 [8].
• b. A CBSD may be associated with a Coexistence Group (defined in WINNF-TS-0112 [1]) during the Release 2 operation using this feature.

REL2-R3-DEV-12201: Grouping Information

• a. A CBSD associated with one or more Groups or a DP managing such CBSDs may provide the grouping information to the managing SAS outside the CBSD Registration procedure.
• b. In providing the grouping information, a CBSD associated with one or more Groups or a DP managing such CBSDs shall provide the latest information of the associated Groups.

Annex 1.2.3 System Registration Requirements (SRR)

REL2-R3-SRR-12300: Release 2 CBSD utilizing Enhanced CBSD Group Handling shall declare it to its managing SAS using the Feature Capability Exchange defined in this document.

REL2-R3-SRR-12301: Release 2 SAS utilizing Enhanced CBSD Group Handling shall declare it to its Release 2 managed CBSD using the Feature Capability Exchange defined in this document.

Annex 1.3 Use for Operations That Could Impact Part 96 Regulatory Compliance

Not applicable for this version of this document.

Annex 2 Principal-Subordinate Single Frequency Group (SFG) (Optional)

Annex 2.1 Feature Description

Principal-Subordinate SFGs accommodate connections between a group of CBSDs, typically composed of one or more principal BTS-CBSDs and one or more subordinate CPE-CBSDs under control of those BTS-CBSDs and occupying the same frequency assignment. Each CPE-CBSD is under control of one BTS-CBSD. Multiple principals qualify for membership in a single Principal-Subordinate SFG only if they are incapable of operating in different frequency assignments. The Principal-Subordinate SFG declaration and association is made using WInnForum Release 2 Feature "Enhanced CBSD Group Handling" defined in Annex 1.

Note: Membership in a Principal-Subordinate Group can suggest association of a CPE-CBSD with a specific BTS-CBSD, but it is not definitively implied as a condition of membership. The definition of a device as a CPE-CBSD is a separate registration parameter defined in Annex 6.

Definitions:

Principal CBSD: A Principal CBSD is a member of a Principal-Subordinate Single Frequency Group which needs to be authorized in order for other members of the group (Subordinate CBSDs) to be authorized.

Note: The typical instantiation of a Principal CBSD is a BTS-CBSD.

Subordinate CBSD: A Subordinate CBSD is a member of a Principal-Subordinate Single Frequency Group whose Grant from the Managing SAS, if any, refers to a frequency range of its corresponding Principal CBSD.

Note: The typical instantiation of a Subordinate CBSD is a CPE-CBSD.

Annex 2.2 Use for operations not impacting Part 96 Regulatory Compliance

A Principal Subordinate SFG does not affect protection of Protected Entities and so does not impact Part 96 regulatory compliance. CBSDs associated with this type of Group will not receive any special treatment by SASs in calculation of protection of Protected Entities.

Annex 2.2.1 System Registration Requirements (SRR)

REL2-R3-SRR-22100 Principal-Subordinate SFG Membership

• a. A CBSD shall declare its association to a Principal-Subordinate SFG using the WInnForum Release 2 Feature "Enhanced CBSD Group Handling".
• b. A CBSD that belongs to a Principal-Subordinate SFG may also belong to other Group(s) defined in this specification or WINNF-SSC-0010 [8].
• c. The SAS shall ensure the Principal-Subordinate SFG membership is persistent after a frequency reassignment.
• d. A CBSD shall retain its Principal-Subordinate SFG membership whether or not it receives a Grant when a frequency reassignment is required, unless it requests the change.
• e. All members of a Principal-Subordinate SFG shall be managed by the same SAS.

REL2-R3-SRR-22101 DEPRECATED

Annex 2.2.2 SAS General Requirements (SGN)

REL2-R3-SGN-22200 Frequency Assignment

• a. For each Subordinate CBSD within the Principal-Subordinate SFG, the SAS shall identify an available Grant frequency range which is within the frequency range of a Grant recommended and available for the Principal CBSD(s). Note: The identified frequency range can be null.
• b. The SAS shall support the capability to communicate this frequency range to the Subordinate CBSD(s).

REL2-R3-SGN-22201 Frequency Reassignment

• a. The SAS should maximize the number of Subordinate CBSDs moved to the same frequency range as the Principal CBSD's new frequency range if all members of the group cannot be moved to the same frequency range.
• b. .The SAS may allow more than one CBSD to be a Principal if they are required to operate on the same frequency range.
• c. If the SAS needs to terminate the existing Grant(s) for the Principal CBSD(s) and suggest new Grant(s) to the Principal CBSD(s) due to SASs calculation results of protection of Protected Entities, the SAS should identify to the Subordinate CBSDs (to the extent possible and preferably before the termination of their existing Grant) a new Grant frequency range that is within the frequency range(s) of new Grant(s) suggested to the Principal CBSD(s).
• d. If the SAS cannot identify to the Subordinate CBSDs a new Grant frequency range in accordance with REL2-R3-SGN-22200-c above, the SAS shall terminate the existing Grant of those Subordinate CBSDs

Annex 2.2.3 CBSD and EUD Requirements (DEV)

REL2-R3-DEV-22300 Principal-Subordinate SFG Membership

• a. A Principal-Subordinate SFG shall be created by a Principal CBSD.
• b. Subordinate CBSDs may exit the associated Principal-Subordinate SFG.

Annex 2.3 Use for Operations That Could Impact Part 96 Regulatory Compliance

Not applicable for this version of this document

Annex 3 Interdependent Single Frequency Group (Optional)

Annex 3.1 Feature Description

An Interdependent SFG is a set of CBSDs that are required by their hardware to operate on a single frequency, and whose members are not individually addressed by the SAS. The Interdependent SFG declaration and association is made using WInnForum Release 2 Feature "Enhanced CBSD Group Handling" defined in Annex 1.

Annex 3.2 Use for operations not impacting Part 96 Regulatory Compliance

Interdependent SFG does not affect protection of Protected Entities and so does not impact Part 96 regulatory compliance. CBSDs associated with this type of Group will not receive any special treatment by SASs in calculation of protection of Protected Entities.

Annex 3.2.1 System Registration Requirements (SRR)

REL2-R3-SRR-32100 Interdependent SFG Membership

• a. A CBSD shall declare its association to an Interdependent SFG using the WInnForum Release 2 Feature "Enhanced CBSD Group Handling".
• b. A CBSD which belongs to an Interdependent SFG may also belong to other Group(s) defined by WInnForum specifications or in WINNF-SSC-0010 [8].
• c. The SAS shall ensure Interdependent SFG membership is persistent after a frequency reassignment.
• d. A CBSD shall retain its Interdependent group assignment whether or not it receives a Grant when a frequency reassignment is required, unless it requests the change.
• e. All members of an Interdependent SFG shall be managed by the same SAS.

Annex 3.2.2 SAS General Requirements (SGN)

REL2-R3-SGN-32200 Frequency Assignment

• a. The SAS shall assign the CBSDs in an Independent SFG to operate on a common frequency and at a common power level when possible.
• b. If the SAS is unable to find a frequency assignment that all members can operate on, the SAS shall not provide a new Grant to members of the group.
• c. If reducing the power level of all members equally allows the whole group to operate on the same frequency assignment, the SAS may provide a new Grant to all members at that reduced power level.
• d. The SAS shall reassign the same spectrum within an Interdependent SFG in concert when reassignment is needed.

Annex 3.3 Use for Operations That Could Impact Part 96 Regulatory Compliance

Not applicable for this version of this document

Annex 4 Separable Single Frequency Group (Optional)

Annex 4.1 Feature Description

A Separable SFG is a set of CBSDs that are restricted to operate on a single frequency assignment and are designed to allow deactivation and/or control of conducted power into the antenna from each member CBSD. The Separable SFG declaration and association is made using WInnForum Release 2 Feature "Enhanced CBSD Group Handling" defined in Annex 1.

Annex 4.2 Use for operations not impacting Part 96 Regulatory Compliance

Separable SFG does not affect protection of Protected Entities so does not impact Part 96 regulations. CBSDs associated with this type of Group will not receive any special treatment by SASs in calculation of protection of Protected Entities.

Annex 4.2.1 System Registration Requirements (SRR)

REL2-R3-SRR-42100 Separable SFG Membership

• a. A CBSD shall declare its association to a Separable SFG using the WInnForum Release 2 Feature "Enhanced CBSD Group Handling".
• b. A CBSD which belongs to a Separable SFG may also belong to other Group(s) defined by WInnForum specifications or in WINNF-SSC-0010 [8].
• c. The SAS shall ensure that Separable SFG membership is persistent after a frequency reassignment.
• d. A CBSD shall retain its Separable group assignment whether or not it receives a Grant when a frequency reassignment is required, unless it requests the change.
• e. All members of an Separable SFG shall be managed by the same SAS.

REL2-R3-SRR-42101 Separable Single Frequency Group.

• a. If the SAS is unable to find a frequency assignment that all members can operate on, the SAS may deny grants to individual members of the group.
• b. If reducing the power level of some individual members allows the whole group to operate on a common frequency assignment, the SAS may reduce the power level of those individual members.

Annex 4.2.2 SAS General Requirements (SGN)

REL2-R3-SGN-42200 Frequency Assignment

• a. The SAS shall assign the CBSDs in a Separable SFG to operate on a common frequency when possible.
• b. If it is not possible for the SAS to assign the entire group to a frequency, e.g., due to protection of Protected Entities, the SAS may assign some members of the group to a different frequency while requiring others to cease transmitting or reduce power.

Annex 4.3 Use for Operations That Could Impact Part 96 Regulatory Compliance

Not applicable for this version of this document

Annex 5 Enhanced Antenna Patterns (Optional)

Annex 5.1 Feature Description

This section specifies requirements for sharing CBSD enhanced antenna pattern information with a SAS and calculation of directional antenna gain by the SAS based on that information.

Annex 5.1.1 Definitions

Front to Back Ratio (FBR). A value (in dB) provided by the antenna or equipment manufacturer that generally describes the ratio of power radiated in the boresight direction to the power radiated in the opposite direction.

Annex 5.2 Use for operations not impacting Part 96 Regulatory Compliance

Operations not impacting Part 96 Regulatory Compliance include:

• Intra-GAA operation

CBSDs using this feature will not receive any special treatment by SASs in calculation of protection of Protected Entities.

Annex 5.2.1 SAS General Requirements (SGN)

REL2-R3-SGN-52100: SAS selection of CBSD antenna gain calculation methods.

• a. The SAS shall be capable of using the following methods for calculation of the CBSD antenna gain in a direction towards a target receiver:
  • Method A: Use of one two-dimensional antenna pattern (denoted as G2D(, )) recorded in a CBSD Antenna Pattern Database as relative to Peak Antenna Gain

Note: There is no presumption that any antenna implementations are provided with the full two-dimensional pattern data used in Method A, but it is provided here for the sake of completion.

• Method B1: Use of two one-dimensional antenna patterns (denoted as GH(θ) and GV(), respectively) recorded in a CBSD Antenna Pattern Database;

• Method B2: Reserved for future use

• Method C: Use of two one-dimensional antenna patterns (denoted as GH(θ) and GV(), respectively) derived from the CBSD Registration parameters (Antenna Azimuth, Horizontal 3dB beamwidth, Vertical 3dB beamwidth, Peak Antenna Gain, Mechanical Downtilt, and Front-to-Back Ratio);

• Method D: Use of two one-dimensional antenna patterns (denoted as GH(θ) and GV(), respectively), where the horizontal antenna pattern (denoted as GH(θ)) is recorded in the CBSD Antenna Pattern Database, and the vertical antenna pattern is derived from the CBSD Registration parameters (Vertical 3dB beamwidth, Peak Antenna Gain, Mechanical Downtilt, and Front-to-Back Ratio)

• Method E: Use of the horizontal antenna pattern (denoted as GH(θ)) recorded in the CBSD Antenna Pattern Database. No vertical antenna pattern information is used.

• Method F: Use of the horizontal antenna pattern (denoted as GH(θ)) derived from the CBSD Registration parameters (i.e., Release 1 method specified in R2-SGN-20 [1]).

NOTE: Method F-based Antenna Gain calculation is not specified in this Annex as it is identical to Release 1 method specified in R2-SGN-20 [1].

• b. The SAS shall select and use one of the above methods in order of priority based on the availability of the enhanced antenna pattern information of the CBSD listed in Table 2.
  • i. For Category A CBSDs, if antenna azimuth or horizontal 3dB beamwidth are not provided or are invalid, the SAS shall assume omni-directional horizontal pattern and consider it when selecting the method in REL2-R3-SGN-52100-b.
  • ii. If FBR is not provided or is invalid, the SAS shall assume 20 dB FBR as default and consider it when selecting the method in REL2-R3-SGN-52100-b.

Table 2: Necessity of enhanced antenna pattern information in each method

REL2-R3-SGN-52101: Deprecated (divided into multiple requirements)

REL2-R3-SGN-52102: For Intra-GAA operations in Release 2, SAS may use the CBSD antenna gain calculated by using the methods in REL2-R3-SGN-52100.

NOTE: This means that "a target receiver" in REL2-R3-SGN-52100 cannot be a receiver of Protected Entities.

REL2-R3-SGN-52103: Calculation of the direction from the CBSD towards a target receiver:

• a. In all the methods specified in REL2-R3-SGN-52100, the SAS shall compute the azimuth angle, α, relative to true north from the CBSD toward a target receiver location from the associated latitudes and longitudes using Vincenty's formula [4].
• b. In Method A, Method B1, Method C and Method D specified in REL2-R3-SGN-52100, the SAS shall compute the elevation angle, , from the CBSD toward a target receiver by the method which is equivalent to the hzns() subroutine [5].
• c. The SAS shall calculate the azimuth and elevation angles ( and R) of the line between the CBSD main beam and the receiver location relative to the CBSD antenna boresight direction by using the following equations:

$$\theta_{\rm R} = \alpha - az$$

$$\varphi_{\rm R} = \beta + \cos(\theta_{\rm R}) \cdot \tau$$

where:

az: the CBSD antenna main beam pointing azimuth
τ : mechanical downtilt

Figure 1 represents the orientation of the CBSD relative to the global coordinate system. The azimuth angle az, in the global xz-plane, describes the orientation of the CBSD antenna boresight (z' axis) and is positive clockwise from True North. The mechanical downtilt τ describes the elevation angle of the antenna boresight direction, which is positive below horizon. Additionally, Figure 1 shows the orientation of a victim receiver (which could be an incumbent) in the global coordinate system described by the azimuth angle α to the projection of the incumbent into the xz-plane. The azimuth angle α is positive clockwise from True North. The elevation angle β towards the incumbent is positive above horizon (towards the sky) and negative below horizon (towards the ground).

NOTE: The equation used in c above for is based on small-angle approximation of the original equation assuming that down tilt, is limited to less than 15 degrees. To verify that the simplified equation provides a reasonable approach to the calculation of the antenna gain, WINNF compared the difference between antenna gain for antenna pattern defined in REL2-R3- SGN-52106(a) using the original equation and the simplified equations. We found that the error in the gain calculation is less than 0.75 dB worst case for -60 ≤ +60 degrees, -180 ≤ ≤ +180 degrees, as long as the tilt angle is limited to -15 ≤ ≤ + 15 degrees. The use of the simplified equation in c above requires that the deployment will not have mechanical down tilt with a magnitude of more than 15 degrees.

Figure 1: Global coordinate system illustration. The orientation of the CBSD is described by the azimuth angle az relative to True North and the down tilt angle τ. The position of the victim receiver is given by the azimuth angle α, and the elevation angle β.

The local antenna coordinate system defined by the azimuth angle θ is show in Figure 2. The pole of the coordinate system is aligned with the y' axis, and the antenna boresight direction is aligned with the z' axis.

Figure 2: Local antenna coordinate system illustrating the local azimuth angle θ, and local elevation angle φ. The antenna boresight is aligned with the z' axis.

REL2-R3-SGN-52104: Method A based Antenna Gain Calculation:

The SAS shall determine the CBSD antenna gain GCBSD(, ) using the following equation:

Where:

θ = [-180, θ1, θ2, ..., θm, ..., 180] including 0 degree
phi = [-90, phi1, phi2, ..., phin, ..., 90] including 0 degree
θm’, θm’+1: two azimuth angles closest to alpha, (θm’< alpha < θm’+1)
phin’, phin’+1: two elevations angles closest to beta, (phin’< beta < phin’+1)

REL2-R3-SGN-52105: Method B1 based Antenna Gain Calculation:

a. The SAS shall define G'H(θR), G'V(R) and G'V(180 – R) as follows:

b. The SAS shall calculate the CBSD antenna gain GCBSD(, ) by using the following equation:

The range of mechanical downtilt in this Method shall be limited to 0 to +/- 15 degrees.

NOTE: Antenna gain calculation with large mechanical downtilt is for further study (FFS).

REL2-R3-SGN-52106: Method C based Antenna Gain Calculation:

a. The SAS shall derive the horizontal antenna pattern $G_H(\theta)$ and the vertical antenna pattern $G_V(\varphi)$ from the following equations:

$$G_{H}(\theta) = - \min \left[ 12 \left( \frac{\theta}{\theta_{3dB}} \right)^{2}, \text{FBR} \right] (\text{dBi})$$

$$G_{V}(\varphi) = - \min \left[ 12 \left( \frac{\varphi}{\varphi_{3dB}} \right)^{2}, \text{FBR} \right] (\text{dBi})$$

where:

$$\theta_{3dB}$$ : Horizontal 3 dB beamwidth
$$\varphi_{3dB}$$ : Vertical 3 dB beamwidth

FBR: front-to-back ratio (FBR) in dB.

b. The SAS shall calculate the CBSD antenna gain $G_{\text{CBSD}}(\alpha, \beta)$ by using the derived patterns $G_H(\theta)$ and $G_V(\varphi)$ based on Method B1 specified in REL2-R3-SGN-52105.

The range of mechanical downtilt in this Method shall be limited to 0 to +/- 15 degrees.

NOTE: Antenna gain calculation with large mechanical downtilt is for further study (FFS).

REL2-R3-SGN-52107: Method D based Antenna Gain Calculation:

a. The SAS shall derive the vertical antenna pattern $G_V(\varphi)$ based on the Method C specified in REL2-R3-SGN-52106 (a)

b. The SAS shall calculate the CBSD antenna gain GCBSD(, ) by using the provided antenna pattern () and derived vertical antenna pattern () based on Method B1 specified in REL2-R3-SGN-52105.

The range of mechanical downtilt in this Method shall be limited to 0 to +/- 15 degrees.

NOTE: Antenna gain calculation with large mechanical downtilt is for further study (FFS).

REL2-R3-SGN-52108: Method E based Antenna Gain Calculation:

The SAS shall calculate the CBSD antenna gain GCBSD(, ) by using the horizontal antenna pattern () and 0 dB vertical antenna discrimination in all directions based on Method B1 specified in REL2-R3-SGN-52105.

Annex 5.2.2 CBSD and EUD Requirements (DEV)

REL2-R3-DEV-52200: Category A CBSD Parameter Set for Registration of Enhanced Antenna Pattern Information:

In addition to the parameter sets required or optional for Category A CBSD Registration as described in R0-SRR-01 [1], Category A CBSDs shall have a capability to provide one or multiple parameters from the following enhanced antenna pattern information during CBSD Registration:

• Antenna gain along with
  • i The 3 dB beamwidth of the horizontal antenna pattern antenna beamwidth
  • ii Antenna azimuth pointing direction
• The mechanical downtilt of the CBSD antenna
• The 3 dB beamwidths of the vertical antenna pattern.
• The front-to-back ratio (FBR)
• A specific antenna model or identifier which identifies one of the following antenna information recorded in the CBSD Antenna Pattern Database
  • i One two-dimensional antenna pattern including factors of static beamforming, and electrical downtilt
  • ii Horizontal antenna pattern including factors of static beamforming and electrical downtilt;
  • iii Combination of horizontal and vertical antenna patterns including factors of static beamforming and electrical downtilt.

REL2-R3-DEV-52201: Deprecated

REL-R3-DEV-52202: Deprecated

REL2-R3-DEV-52203: Deprecated (merged with REL2-R3-DEV-52200)

REL2-R3-DEV-52204: Category B CBSD Parameter Set for Registration of Enhanced Antenna Pattern Information:

In addition to the parameter sets required or optional for Category B CBSD Registration as described in R0-SRR-02 [1], Category B CBSDs shall have a capability to provide one or multiple parameters from the following enhanced antenna pattern information during CBSD Registration:

• The 3 dB beamwidths of the vertical antenna pattern.
• The front-to-back ratio (FBR)
• A specific antenna model or identifier which identifies one of the following antenna information recorded in the CBSD Antenna Pattern Database
  • i One two-dimensional antenna pattern including factors of static beamforming, and electrical downtilt
  • ii Horizontal antenna pattern including factors of static beamforming and electrical downtilt;
  • iii Combination of horizontal and vertical antenna patterns including factors of static beamforming and electrical downtilt.

REL2-R3-DEV-52205: The parameters listed in REL2-R3-DEV-52200 and REL2-R3-DEV-52204 may be provided to the SAS via single-step registration or multi-step registration.

Annex 5.2.3 Certified Professional Installer Requirements (CPI)

REL2-R3-CPI-52300: Registration of the Enhanced Antenna Pattern Information:

For the registration of the CBSDs supporting Enhanced Antenna Pattern feature, the CPI should choose the Enhanced Antenna Pattern Information of the CBSD listed in REL2-R3-DEV-52200 a based on the antenna calculation method in REL2-R3-SGN-52100 the CBSD User desires the SAS to apply.

Annex 5.2.4 SAS Administrator Requirements (SAD)

REL2-R3-SAD-52400: Mutual Agreement with CBSD Users:

SAS Administrators may work with CBSD Users to mutually agree on a lower bound to the antenna gain of the enhanced antenna patterns described in [REL2-R3-DEV-52200]

REL2-R3-SAD-52401: CBSD Antenna Pattern Database:

• a. SAS Administrators shall cooperate to define a CBSD Antenna Pattern Database that is available to all SASs.
• b. A record of the CBSD Antenna Pattern Database shall be designed to contain at least the following information:
  • Antenna pattern ID
• One of the following antenna pattern information:
  • o Horizontal antenna pattern including factors of static beamforming and electrical downtilt;
  • o Combination of horizontal and vertical antenna patterns including factors of static beamforming and electrical downtilt; or
  • o Two-dimensional antenna pattern including factors of static beamforming and electrical downtilt

Annex 5.2.5 System Registration Requirements (SRR)

REL2-R3-SRR-52500: Release 2 CBSD utilizing Enhanced Antenna Patterns shall declare it to its managing SAS using the Feature Capability Exchange defined in this document.

REL2-R3-SRR-52501: Release 2 SAS utilizing Enhanced Antenna Patterns shall declare it to its Release 2 managed CBSD using the Feature Capability Exchange defined in this document.

Annex 5.3 Use for Operations that could impact Part 96 Regulatory Compliance

Operations that could impact Part 96 Regulatory Compliance include:

• Protection of Protected Entities

Annex 5.3.1 SAS General Requirements (SGN)

REL2-R3-SGN-53100: Subject to REL2-R3-SGN-06, REL2-R3-SGN-07, and REL2-R3-SGN-08, instead of CBSD antenna gain calculated based on Release 1 method specified in R2-SGN-20 [1], a SAS may use the CBSD antenna gain calculated based on Method A, Method B1, Method C, Method D and Method E specified in REL2-R3-SGN-52100 for the purpose of protecting Protected Entities.

NOTE: Method F is outside the scope of this requirement because it is identical to Release 1 method specified in R2-SGN-20 [1].

Annex 6 CPE-CBSD Indicator (Optional)

Annex 6.1 Feature Description

This feature enables a CPE-CBSD to indicate to the SAS that it is a CPE-CBSD.

Annex 6.2 Use for Operations not Impacting Part 96 Regulatory Compliance

CPE-CBSD Indicator does not impact protection of Protected Entities. CBSDs using this indicator will not receive any special treatment by SASs in calculation of protection of Protected Entities.

Annex 6.2.1 SAS General Requirements (SGN)

REL2-R3-SGN-62100: A SAS shall treat a CBSD as CPE-CBSD if it receives the CPE-CBSD indication.

Annex 6.2.2 CBSD and EUD Requirements (DEV)

REL2-R3-DEV-62200: A CBSD may support this feature only if it meets R1-DEV-04 (CPE-CBSD Operation) specified in WINNF-TS-0112 [1].

Annex 6.2.3 System Registration Requirements (SRR)

REL2-R3-SRR-62300: Release 2 CBSD utilizing CPE-CBSD Indicator shall declare it to its managing SAS using the Feature Capability Exchange defined in this document.

REL2-R3-SRR-62301: Release 2 SAS utilizing CPE-CBSD Indicator shall declare it to its Release 2 managed CBSD using the Feature Capability Exchange defined in this document.

Annex 6.3 Use for Operations That Could Impact Part 96 Regulatory Compliance

Not applicable for this version of this document

Annex 7 Passive DAS (Optional)

Annex 7.1 Description

Passive DAS is a network of spatially separated Transmission Points (TPs) powered by the same single physical Radio Unit (RU), in which there are only passive elements (feeders, splitters, diplexers, etc.) between the RU and each of the TPs. Each TP associated to a Passive DAS is a CBSD. All the CBSDs associated with Passive DAS require the same spectrum (radio frequency range) assignment and have several restrictions on the allowed power. The Radio Unit (RU) is transmitting RF only when all the CBSDs (TPs) associated with the Passive DAS are authorized to transmit by the SAS. Passive DAS declaration and association uses WInnForum Release 2 Feature "Enhanced CBSD Group Handling".

Annex 7.2 Use for operations not impacting Part 96 Regulatory Compliance

Passive DAS does not impact protection of Protected Entities. CBSDs associated with this type of Group will not receive any special treatment by SASs in calculation of protection of Protected Entities.

Annex 7.2.1 System Registration Requirements (SRR)

REL2-R3-SRR-72100: Deprecated

REL2-R3-SRR-72101: All the CBSDs associated to Passive DAS shall be registered by CPI regardless of their CBSD Category

REL2-R3-SRR-72102: All the CBSDs associated to Passive DAS shall report their EIRP Capability (dBm/10MHz) as part of registration by a CPI.

REL2-R3-SRR-72103: A CBSD shall declare its association to a unique Passive DAS Group during Registration using the WInnForum Release 2 Feature "Enhanced CBSD Group Handling".

REL2-R3-SRR-72104: A CBSD that belongs to a Passive DAS Group may also belong to other Group(s) defined by WInnForum specifications.

Annex 7.2.2 SAS General Requirements (SGN)

REL2-R3-SGN-72200: Spectrum Assignment

• a) SAS shall assign the same frequency range to all CBSDs (TPs) within the same Passive DAS group.
• b) If SAS is unable to assign a frequency range, due to protection of Protected Entities, that all TP(s) within the same Passive DAS group can operate on, SAS shall not assign any frequency range for any TP.
• c) Subject to above requirements and when reassignment is needed for at least one TP, SAS shall reassign in concert the same frequency range to all TPs within the same Passive DAS group.

Annex 7.2.3 CBSD and EUD Requirements (DEV)

REL2-R3-DEV-72300: Deprecated

REL2-R3-DEV-72301: Deprecated

REL2-R3-DEV-72302: All CBSDs (All TPs) in the same Passive DAS Group association shall be managed by the same SAS.

REL2-R3-DEV-72303: CBSD Registering to the SAS as belonging to a Passive DAS Group association shall meet with the requirements for Passive DAS defined by the FCC in KDB 935210 D02 Signal Boosters Certification [n.11]

REL2-R3-DEV-72304: Deprecated

Annex 7.3 Use for Operations That Could Impact Part 96 Regulatory Compliance

Not applicable for this version of this document

Annex 8 Grant Update (Optional)

Annex 8.1 Feature Description

This feature enables SASs to replace a CBSD's existing grant with a new grant with the same frequency range without a grant relinquishment procedure. The feature requires operation by both the SAS and CBSD. SAS use of this feature has regulatory impacts, however CBSD/DP use of this feature does not.

There are several use cases where this Grant Update feature could be beneficial. An example of those use cases is max EIRP reduction after CPAS [10]. As a result of IAP during the CPAS process, a SAS could need to reduce the max EIRP of some of their CBSD's grants slightly. Without this feature, each CBSD needs to replace its existing Grant by obtaining a new Grant with reduced max EIRP after relinquishment of the existing Grant, leading to CBSD's service disruption. By using this feature, such CBSDs can obtain a new Grant with the reduced max EIRP without needing the Grant Relinquishment procedure. Another example is when the CBSDs with existing grants associated with the operator's PAL license, are added to a PPA. By using this feature, a GAA Grant can be replaced by a PAL Grant without relinquishing the GAA Grant.

Annex 8.2 Use of Operations Not Impacting Part 96 Regulatory Compliance

Annex 8.2.1 CBSD and EUD Requirements (DEV)

REL2-R3-DEV-82100: DEPRECATED

REL2-R3-DEV-82101: Upon receiving the approval of the new Grant request in which the requested frequency range is exactly the same as the frequency range of an existing Grant, the CBSD shall consider the existing Grant terminated.

NOTE: The CBSD does not have to relinquish the existing Grant prior to sending such new Grant request. See R3-REL2-SGN-83100 for more information.

Annex 8.2.2 System Registration Requirements (SRR)

REL2-R3-SRR-82200: Release 2 CBSD utilizing Grant Update feature shall declare it to its Managing SAS using the Feature Capability Exchange defined in this document.

REL2-R3-SRR-82201: Release 2 SAS utilizing Grant Update feature shall declare it to its Release 2 managed CBSD using the Feature Capability Exchange defined in this document.

Annex 8.3 Use of Operations Impacting Part 96 Regulatory Compliance

Due to the impact on Release 1 WInnForum testing [9], this feature is considered impacting Part 96 regulatory compliance for SAS operations.

Annex 8.3.1 SAS General Requirements (SGN)

REL2-R3-SGN-83100: Maximum Transmission Power Update

• a. The Managing SAS shall have the capability to approve the request of a new Grant in which the requested frequency range is exactly the same as an existing Grant of the CBSD in order to allow the CBSD to use the updated maximum transmission power in the same frequency range as the existing Grant without requiring the CBSD to relinquish the existing Grant.
• b. Upon approval of the new Grant request in accordance with REL2-R3-SGN-83100-a, the Managing SAS shall terminate the existing Grant.

REL2-R3-SGN-83101: Grant Type Update: The Managing SAS shall have the capability to update the CBSD's Grant type (GAA versus PAL) of an existing Grant without terminating the existing Grant and inform the CBSD of the updated Grant type for the existing Grant.

REL2-R3-SGN-83102: DEPRECATED

Annex 9 Extension to PPA Information

Annex 9.1 Feature Description

This feature extends PPA Information to include new parameters and enables SASs to exchange that information as part of PPA Information in the Full Activity Dump (FAD). New parameters include the followings:

• the FRN (FCC Registration Number) of the PAL Holder associated with a PPA

Use cases of this feature include handling multiple PPA protection, when PPAs are owned by the same licensee/operator but managed by different SAS Administrators and deployed in the proximity of each other such that some or all of the CBSDs in one PPA are in the protection neighborhood of the other PPA.

Annex 9.2 Use of Operations Not Impacting Part 96 Regulatory Compliance

This feature does not alter the Release 1 process by which PPA information included in the Full Activity Dump (FAD) is exchanged, so it does not impact Part 96 regulatory compliance.

This feature has no impact on CBSD/DPs.

Annex 9.2.1 SAS General Requirements (SGN)

REL2-R3-SGN-92100: SAS shall exchange the FRN of the PAL holder generating a PPA with other SAS Administrators.

Annex 9.3 Use of Operations that Could Impact Part 96 Regulatory Compliance

Not applicable, as this feature does not impact Part 96 regulatory compliance

Annex 10 Global Navigation Satellite System (GNSS) Measurements to Estimate Building Entry Loss (BEL) (Optional)

Annex 10.1 Feature Description

This feature enables the Release 2 SASs to use GNSS measurements-based BEL in propagation loss calculation instead of the BEL value of 15 dB employed for Release 1. The feature requires operation by both the SAS and CBSD.

Annex 10.2 Use for operations not impacting Part 96 Regulatory Compliance

Not applicable for this version of the document.

Annex 10.3 Use for that could impact Part 96 Regulatory Compliance

Annex 10.3.1 SAS General Requirements (SGN)

REL2-R3-SGN-103100: CBSD-measured BEL loss value in aggregate interference calculation:

If the BEL of a CBSD described in WINNF-SSC-0002 section 7.2.1 [n.13] is available to the SAS, the SAS shall use the following procedure to calculate the CBSD BEL toward the receiver of a protected entity.

This applies to :

R2-SGN-04 Propagation model requirements for the use in PPA and GWPZ Calculation R2-SGN-03 (restricted to CBSD to FSS interference only)

• a. The azimuth angle, Az, relative to true north from the CBSD toward a receiver location shall be computed from the associated latitudes and longitudes using Vincenty's formula [n.4].
• b. The elevation angle, El, from the CBSD toward a receiver is computed by the method which is equivalent to the hzns() subroutine [n.12]
• c. The CBSD antenna azimuth, Az, shall be used to calculate the angle of the line between the CBSD and the receiver location relative to the CBSD.
• d. The CBSD shall capture the GPS signal power per satellite and either calculate a loss value or send the correlation data to a server to provide the calculation. The loss data per Azimuth and Elevation angle "pixel" is the measurement reported. The calculating entity should use the lowest loss data from adjacent pixels to provide the loss measurement. The measurement can be directly routed to the SAS or routed to the CBSD which in turn will route it to the SAS. In the event a pixel is empty, that is not filled in by data, the minimum loss of the adjacent pixels can be used. In the further event that these pixels have not yet been filled in with data a default value of 15 dB shall be used. The CBSD will continue to collect data in an attempt to fill in all empty pixels. This data will be relayed to the SAS as it becomes available.
• e. For protected entities in the LOS direction for CBSD to protected entity > 1 street separation the BEL is calculated as
  • i. BEL is the min[loss(El 5 to 10 deg.) AND (Az +/- 10 deg.) from the direct angle to the protected entity] dB
  • ii. The BEL measured at GPS L1 (1575.42 MHz) shall be optionally converted to 3.5 GHz by adding values in table 1 below taken from TR-1007 figures 13 and 14
  • iii. The BEL measured at GPS L5 (1176.45 MHz) shall be optionally converted to 3.5 GHz by adding values in the table below taken from TR-1007 figures 17 and 18 .
  • iv. The total path loss for a single BEL consideration for a distance d is
    • i. $$PL(d) = BEL + PL_{model}(d) dB$$
  • v. The total path loss for a double BEL consideration for a distance d is
    • i. $$PL(d) = BEL_1 + BEL_2 + PL_{model}(d) dB$$

Table 1 GPS L1 conversion factors

Table 2 GPS L5 conversion factors

• f. For protected entities in the LOS direction for CBSD to protected entity <= 1 street separation the BEL is calculated as
  • i. BEL is the minimum[loss(El 5 to 60, AND Az +/- 10 deg) from the direct angle to the protected entity] dB
  • ii. The BEL measured at GPS L1 (1575.42 MHz) shall be optionally converted to 3.5 GHz by adding values from table 1 .
  • iii. The BEL measured at GPS L5 (1176.45 MHz shall be optionally converted to 3.5 GHz by adding values from table 2.
  • iv. The total path loss for a single BEL consideration is
    • i. $$PL(d) = BEL + BEL_2 + PL_{model}(d) dB$$
  • v. The total path loss for a double BEL consideration is
    • i. $$PL(d) = BEL_1 + BEL_2 + PL_{model}(d) dB$$

REL2-R3-SGN-103101: In order to support this feature, the SAS shall have the capability to receive the measurement reports associated with the CBSD measurement capability "INDOOR_LOSS_USING_GNSS" specified in WINNF-SSC-0002 [n.13].

Annex 10.3.2 CBSD and EUD Requirements (DEV)

REL2-R3-DEV-103200: In order to support this feature, the CBSD shall have the measurement capability "INDOOR_LOSS_USING_GNSS" specified in WINNF-SSC-0002 [n.13].

REL2-R3-DEV-103201: The CBSD shall not send the unsolicited measurement reports associated with the measurement capability "INDOOR_LOSS_USING_GNSS" to the SAS not supporting this feature.

Annex 10.3.3 System Registration Requirements (SRR)

REL2-R3-SRR-103300: Release 2 CBSD utilizing GNSS Measurements to Estimate BEL feature shall declare it to its managing SAS using the Feature Capability Exchange defined in this document.

REL2-R3-SRR-103301: Release 2 SAS utilizing GNSS Measurements to Estimate BEL feature shall declare it to its Release 2 managed CBSD using the Feature Capability Exchange defined in this document.

Annex 11 Antenna Pattern Negotiation (Optional)

Annex 11.1 Feature Description

This feature enables the SAS to calculate an Antenna Pattern EIRP Envelope as defined in section 11.1.1 that will allow CBSDs employing Active Antenna System (AAS) to reduce the EIRP in the direction towards Protected Entities while maintaining higher EIRP in the directions where Protected Entities are not impacted. For example, the CBSD and SAS can negotiate an antenna pattern that will be used by the CBSD until a new pattern is requested by the SAS due to changes related to activation of new Protected Entities (e.g., PPAs) or the increase in the number of deployed CBSDs that will result in the need to reduce EIRP values in certain directions.

In this Annex, "CBSD" refers to the CBSD employing AAS.

Annex 11.1.1 Definitions

Antenna Pattern EIRP Envelope. The permissible EIRP in different directions at the CBSD location to ensure, at minimum, protection of Protected Entities

Annex 11.2 Use for operations not impacting Part 96 Regulatory Compliance

Not applicable for this version of the document.

Annex 11.3 Use for operations that could impact Part 96 Regulatory Compliance

Annex 11.3.1 System Registration Requirements (SRR)

REL2-R3-SRR-113100: Release 2 CBSD utilizing Antenna Pattern Negotiation feature for Active Antenna System (AAS) shall declare it to its managing SAS using the Feature Capability Exchange defined in this document.

REL2-R3-SRR-113101: Release 2 SAS utilizing Antenna Pattern Negotiation feature for Active Antenna System (AAS) shall declare it to its Release 2 managed CBSD using the Feature Capability Exchange defined in this document.

Annex 11.3.2 SAS General Requirements (SGN)

REL2-R3-SGN-113200: A SAS supporting the Antenna Pattern Negotiation feature shall have the following capabilities:

• a. To calculate an Antenna Pattern EIRP Envelope for the CBSD that will ensure proper higher-tier users protection while maximizing EIRP in the directions where Protected Entities are not impacted.
• b. To communicate the Antenna Pattern EIRP Envelope to the CBSD and request the CBSD to confirm that it will not exceed the envelope by providing the enhanced antenna pattern array used by the CBSD
• c. To check that the enhanced antenna pattern array reported by the CBSD fits within the Antenna Pattern EIRP Envelope required to protect Protected Entities
  • i. NOTE: This check can be done by using the CBSD EIRP capability applied to the antenna pattern to be able to compare it with the Antenna Pattern EIRP Envelope
• d. To use methods as specified in Annex 5 to compute CBSD Antenna Gain towards Protected Entities using the antenna pattern declared by the CBSD
  • i. NOTE: The Enhanced Antenna Pattern used in these methods can be in the antenna pattern database or provided through other means

REL2-R3-SGN-113201: A SAS supporting the Antenna Pattern Negotiation feature shall exchange the negotiated antenna pattern arrays for the CBSDs with other SASes supporting the Antenna Pattern Negotiation Feature.

Annex 11.3.3 CBSD and EUD Requirements (DEV)

REL2-R3-DEV-113300: A CBSD that supports the Antenna Pattern Negotiation feature Shall have the following capabilities:

• a. To receive an Antenna Pattern EIRP Envelope from Managing SAS
• b. To compute an enhanced antenna pattern array that will fit within the Antenna Pattern EIRP Envelope received from Managing SAS
• c. To inform the Managing SAS of the calculated enhanced antenna pattern array
• d. To ensure that its transmission will not exceed the EIRP values corresponding to the declared enhanced antenna pattern array

Annex 12 Multi-SAS Inter-Release IAP

Annex 12.1 Feature Description

This feature enables the Release 2 SAS to apply Regulatory Impacting Release 2 features for managing the Grants of its managed CBSDs located in the neighborhood of IAP Protected Entities, where CBSDs managed by other SASs not supporting the same Regulatory Impacting Release 2 features also exist. To achieve this, the concept of Interference Margin Group (IMG) which is specified as an optional Release 1 function as per R2-SGN-16-b-iv [1] is leveraged. In this requirement, "Regulatory Impacting Release 2 feature" refers to Regulatory Impacting Release 2 feature that can be used for IAP. This feature is dedicated to Release 2 SASs and has no impact on CBSD/DPs.

Annex 12.2 Use of Operations not Impacting Part 96 Regulatory Compliance

Not applicable for this version of this document.

Annex 12.3 Use of Operations That Could Impact Part 96 Regulatory Compliance

This feature is defined as Regulatory Impacting because improper use of this feature could impact protection of IAP Protected Entities.

Annex 12.3.1 SAS General Requirements (SGN)

REL2-R3-SGN-132100: If the collection of CBSDs located inside the neighborhood of an IAP Protected Entity are managed by more than one SAS, and at least one SAS does not support a Regulatory Impacting Release 2 feature, the SAS shall perform the following procedure for use of the Regulatory Impacting Release 2 feature. This occurs after performing IAP according to REL2- R3-SGN-06-d without using the Release 2 feature for protection of the IAP Protected Entity:

Step 1: Form an IMG in accordance with R2-SGN-16-b-iv [1] for all its managed CBSDs in the neighborhood of the Protected Entity.

Step 2: Calculate the interference budget of the IMG for the Protected Entity as the aggregate interference of all the CBSDs in the IMG without using the Release 2 feature.

Step 3: Subsequently manage the Grants of the CBSDs in the IMG such that the aggregate interference to the Protected Entity calculated using the Release 2 feature does not exceed the interference budget of the IMG calculated at Step 2.

Annex 13 Grant Restoration (Optional)

Annex 13.1 Feature Description

This feature enables CBSD to resume its radio transmission within a short downtime after its Grant was deleted for any reason. This is achieved by allowing the Managing SAS to temporarily store specific information about a Grant, known as the "Grant Context" after the Grant is deleted. The authorization status of the deleted Grant can then be transferred to a new Grant with the same frequency range as the stored Grant Context. This process of transferring authorization status is called "Grant Restoration". This feature can be used anytime when a Grant is deleted from the Managing SAS due to CBSD Re-registration, deregistration of CBSD or relinquishment of Grant for any reason.

In this Annex, unless otherwise noted, "new Grant" refers to a Grant which has just been approved, is in Granted State and has never gone through CPAS process. Similarly, unless otherwise specified, "old Grant" refers to a Grant whose status was transitioned from Granted/Authorized to Idle (see Grant's state machine in WINNF-TS-0016).

Use cases: Since CBSD Re-registration, CBSD deregistration and Grant relinquishment typically occur, for example, to resolve SAS-CBSD protocol failure, this feature will help reduce downtime in the field. Additionally, this feature can be used for purposes such as CBSD Reregistration for Feature Capability Update, CBSD-triggered Release update (Rel-1 to Rel-2), and CBSD certificate renewal, provided that the registration parameters used for protection of Protected Entities in Coordinated Periodic Activities among SASs (CPAS) remain unchanged.

Annex 13.1.1 Definitions

CBSD Re-registration: The procedure by which a CBSD in Registered State or a Domain Proxy on behalf of one or more CBSDs in Registered State performs CBSD Registration.

NOTE: In this Annex, the registration of a CBSD in the Unregistered State is referred to as "new CBSD Registration" to distinguish it from CBSD Re-registration.

Grant Context: A set of information associated with one approved Grant.

Annex 13.2 Use for Operations Not Impacting Part 96 Compliance

This feature is categorized into Non-Regulatory Impacting for both SAS and CBSD because this feature does not impact protection of Protected Entities.

Annex 13.2.1 System Registration Requirements (SRR)

REL2-R3-SRR-132100: Release 2 CBSD utilizing Grant Restoration feature shall declare it to its Managing SAS using the Feature Capability Exchange defined in this technical specification.

REL2-R3-SRR-132101: Release 2 SAS utilizing Grant Restoration feature shall declare it to its Release 2 managed CBSD using the Feature Capability Exchange defined in this technical specification.

Annex 13.2.2 SAS General Requirements (SGN)

REL2-R3-SGN-132200: Grant Context:

• a. The SAS shall have the capability to store the Grant Context of a Grant prior to deleting that Grant during CBSD Re-registration, deregistration of the CBSD in Registered State, or relinquishment of the Grant.
  • i. Grant Context shall include the following:
    • Grant Context identifier;
    • CBSD unique identification information (e.g., FCC ID + serial number);
    • Grant's operating parameters (i.e., frequency range, maximum EIRP);
    • CBSD's installation parameters that are used in CPAS process;
    • Information of DPA Move List(s) where the Grant is included;
    • Any other parameters (if any) that are used in CPAS process;
  • ii. The Grant Context shall expire at no later than the start of the next CPAS process after the Grant Context is stored.
  • iii. The Grant Context shall not be created for any Grant that was generated after the last CPAS process.

REL2-R3-SGN-132201: Grant Restoration:

• a. The SAS shall have a capability to inform the CBSD of information about the Grant Context of the old Grant so that the CBSD can request from the SAS a new Grant using the Grant Context in accordance with REL2-R3-DEV-132301.
• b. The SAS should issue a Grant identifier of the new Grant so that the CBSD and/or the CBSD User can associate the new Grant with the corresponding old Grant for traceability purpose.

c. The SAS shall have a capability to authorize radio transmission using a new Grant during the very first Heartbeat procedure right after approval of the new Grant requested by the CBSD in accordance with REL2-R3-SGN-132201.

NOTE: Authorization in the very first Heartbeat procedure is subject to DPA activation status if the old Grant was included in any DPA Move List.

REL2-R3-SGN-132202: Conditions for Grant Restoration:

• a. The SAS shall not apply Grant Restoration to a new Grant using the Grant Context of the old Grant if at least one of the following conditions is met:
  • The registration parameters of the CBSD indicated in new CBSD Registration or CBSD Re-registration do not equal to that are stored in the Grant Context (see REL2-R3-SGN-132200-a-i);
  • The operation frequency range of the new Grant is not exactly the same as the frequency range stored in the Grant Context (see REL2-R3-SGN-132200-a-i);
  • The maximum EIRP of the new Grant is greater than the maximum EIRP stored in the Grant Context (see REL2-R3-SGN-132200-a-i).

Annex 13.2.3 CBSD and EUD Requirements (DEV)

REL2-R3-DEV-132300: The CBSD shall have the capability to receive information from its Managing SAS about the Grant's operating parameters that can be authorized by the Managing SAS using the previously stored Grant Context [see Rel2-R3-SGN-132200].

REL2-R3-DEV-132301: The CBSD shall have the capability to request from its Managing SAS a new Grant using the information about the Grant Context received in accordance with REL2- R3-SRR-132300.

Annex 13.3 Use for Operations that Could Impact Part 96 Regulatory Compliance

Not applicable for this version of this technical specification.

Informative Appendix: Registration Update

Some of the characteristics of a registered CBSD may change during operation. The intention is that changing the parameters that do not affect any protection of Protected Entities do not necessarily trigger re-registration of the CBSD. Except for the following list of parameters:

• FCC identification number,
• unique manufacturer's serial number,
• CBSD category, and
• the physical installation parameters,

other registration parameters can be updated without the need for CBSD re-registration. Such registration update might involve interaction with a CPI.

SASs and DP/CBSDs can update some of the registration parameters without the need to reregister with the SAS. This capability is achieved by using proprietary mechanisms designed by SAS Administrators. The methodology employed is left to SAS Administrators. The methodology could be based on either the WInnForum Release 1 or Release 2 frameworks.

Appendix A: Revision History