SAS Test and Certification Specification

Test and Certification for Citizens Broadband Radio Service (CBRS);

**Conformance and Performance Test Technical Specification;

SAS as Unit Under Test (UUT)

Document WINNF-TS-0061 Version V1.5.1

7 October 2019

TERMS, CONDITIONS & NOTICES

This document has been prepared by the SSC Work Group 4 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 4.

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.

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: Kambiz Rahnavardy, Federated Wireless

Group Chair: Masoud Olfat, Federated Wireless

Other Member Representatives:

• CommScope: Ariful Hannan, Vijay Patel
• Ericsson: Virgil Cimpu, Chris Williams
• Federated Wireless: James Neel, Munawwar Sohul
• Google: Greg Billock, Kate Harrison, Yi Hsuan
• NIST: Thao Nguyen, Anirud Sahoo, Michael Souryal
• NTIA Institute for Telecommunications Sciences: Rebecca Dorch
• RED Technologies: Christophe Le Thierry, Pierre Jean Muller
• Sony: Sho Furuichi, Naotaka Sato, Takashi Usui
• WISPA: Richard Bernhardt

The group also wishes to acknowledge the support of Kasey Pugh (DISA/DSO) who participated as an observer and subject matter expert.

1 Introduction

The present document contains the Protocol Implementation Conformance Statement (PICS), test cases to ensure conformance of the components of a three-tiered Spectrum Sharing Architecture to the specifications and Requirements defined by Federal Communications Commission (FCC) and Wireless Innovation Forum (WInnForum).

2 Scope

The present document specifies test procedures to demonstrate conformance of the requirements defined in [n.8 to n.17] for the components of the CBRS Architecture, detailed in Section 5. These procedures comprise transmit characteristics, receive characteristics, and performance requirements defined by the WInnForum, Spectrum Sharing Committee. The conformance tests include protocol and functional tests necessary to ensure the components comply with Part 96 of the FCC's rules [n.15] and the WInnForum CBRS Requirements as specified in [n.12].

Not all components and interfaces in [n.3] are covered by the certification and test cases defined in this document. Development of some of the interfaces and components are out of the scope of WInnForum, and therefore no test and certification process are provided for them. The scope of WInnForum test and certification specification includes:

• Conformance of the Spectrum Access System (SAS) for protecting federal incumbents from harmful interference.
• Conformance of SAS and potentially other components and interfaces, whose functionalities are standardized by WInnForum in [n.9], [n.11], and [n.12].
• Conformance of the SAS for protecting non-federal Incumbents and Priority access licensees from harmful interference.

The functionalities of Radio Access Network (RAN) or radio device operations and functions are outside the scope of this document.

More generally, tests are only applicable to those components that are intended to support the appropriate functionality. To indicate the circumstances in which tests apply, this is noted in the "definition and applicability" part of the test.

This document only covers the test cases required for certification of the SAS components of the CBRS, and does not include the proprietary tests performed by equipment vendors.

Moreover, this document only covers the test specifications and test cases for the CBRS Architecture components, and does not include the test software. The test software is described in a repository maintained by WInnForum Working Group 4 [i.1].

Certain elements of this published WINNF specifications are subject to change and update in this release. The test elements are identified in the traceability Matrix [i.5].

3 References

3.1 Normative references

The following referenced documents are necessary for the application of the present document.

• [n.1] FCC Report and Order 15-47A1: "Amendment of the Commission's Rules with Regard to Commercial Operations in the 3550-3650 MHz Band", FCC, April 17 2015, https://apps.fcc.gov/edocs\_public/attachmatch/FCC-15-47A1.pdf
• [n.2] FCC Report and Order 16-55A1: "Amendment of the Commission's Rules with Regard to Commercial Operations in the 3550-3650 MHz Band", FCC, May 2 2016, https://apps.fcc.gov/edocs\_public/attachmatch/FCC-16-55A1.pdf
• [n.3] SSC- Wireless Innovation Forum, WG1&3 Task Group: "SAS Functional Architecture ", Working Document WINNF-15-P-0047 Version V1.0.0
• [n.4] E. Drocella, et. al., "3.5 GHz Exclusion Zone Analyses and Methodology," NTIA Technical Report TR-15-517, June 2015. Available at http://www.its.bldrdoc.gov/publications/2805.aspx
• [n.5] "NTIA Letter to FCC on Commercial Operations in the 3550-3650 MHz Band," GN Docket No. 12-354, April 14, 2015. Available online: http://www.ntia.doc.gov/fcc-filing/2015/ntia-letter-fcc-commercial-operations-3550-3650-MHz-band
• [n.6] NOAA Maritime Boundaries, Available online: http://www.nauticalcharts.noaa.gov/csdl/mbound.htm Last accessed March 16, 2016
• [n.7] https://www.census.gov/geo/maps-data/data/kml/kml\_nation.html
• [n.8] SSC-Wireless Innovation Forum, "CBRS Communications Security Technical Specification", WINNF-TS-0065 V1.1.0
• [n.9] SSC-Wireless Innovation Forum, "Signaling Protocols and Procedures for Citizens Broadband Radio Service (CBRS): Spectrum Access System (SAS) - Citizens Broadband Radio Service Device (CBSD) Interface Technical Specification", WINNF-TS-0016 V1.2.2
• [n.10] FCC List of protected FSS Sites in 3650-3700 MHz Band https://transition.fcc.gov/ib/sd/3650/grandftr.pdf
• [n.11] SSC-Wireless Innovation Forum, "Signaling Protocols and Procedures for Citizens Broadband Radio Service (CBRS); Spectrum Access System (SAS) - SAS Interface Technical Specification", WINNF-TS-0096 V1.3.0
• [n.12] SSC-Wireless Innovation Forum, "Requirements for Commercial Operation in the U.S. 3550-3700 MHz Citizens Broadband Radio Service Band", WINNF-15-S-0112 V1.6.0
• [n.13] "FSS Sites in 3650-3700 MHz", https://transition.fcc.gov/ib/sd/3650/grandftr.pdf, FCC.
• [n.14] SSC-Wireless Innovation Forum, "Test and Certification for Citizens Broadband Radio Service (CBRS); Conformance and Performance Test Technical Specification; CBSD as Unit Under Test (UUT) – DRAFT, Request for Comment", WINNF-TS-0122 V1.1.1
• [n.15] Electronic Code of Federal Regulations, Title 47, Chapter I, Subchapter D, Part 96, http://www.ecfr.gov/cgibin/retrieveECFR?gp=&SID=0076fe7586178336d9db4c5146da8797&mc=true &n=pt47.5.96&r=PART&ty=HTML.
• [n.16] SSC-Wireless Innovation Forum, "Signaling Protocols and Procedures for Citizens Broadband Radio Service (CBRS): WInnForum Recognized CBRS Air Interfaces and Measurements", WINNF-SSC-0002
• [n.17] RFC-2119, "Key words for use in RFCs to Indicate Requirement Levels", March 1997. Available at: https://tools.ietf.org/html/rfc2119
• [n.18] www.fcc.gov/cbrs-protected-fss-sites
• [n.19] Wireless.fcc.gov/ULS
• [n.20] Coordinated Periodic Activities Policy, WINNF-SSC-0008
• [n.21] Margin Policy, WINNF-SSC-0007
• [n.22] FSS Earth Station Antenna Registration System
• [n.23] Arrangement R, https://transition.fcc.gov/ib/sand/agree/files/cannb/Arrangement_R.pdf

3.2 Informative references

The following referenced documents are not necessary for the application of the present document but they assist the user with regard to a particular subject area.

• [i.1] WG4 GitHub Repository, https://github.com/Wireless-Innovation-Forum/Spectrum-Access-System
• [i.2] http://robotframework.org/
• [i.3] Deprecated
• [i.4] Deprecated
• [i.5] SSC-Wireless Innovation Forum, "CBRS Requirements Traceability Matrix", WINNF-SSC-0003

4 Definitions and Abbreviations

4.1 Abbreviations

CBRS: Citizens Broadband Radio Service
CBSD: Citizens Broadband Radio Service Device
CPAS: Coordinated Periodic Activities among SASs
CPI: Certified Professional Installer
DOD: Department of Defense
DPA: Dynamic Protection Area
EIRP: Effective Isotropic Radiated Power
ESC: Environmental Sensing Capability
FCC: Federal Communications Commission
FSS: Fixed Satellite Service
GAA: General Authorized Access
GWBL: Grandfathered Wireless Broadband Licensee
GWPZ: Grandfathered Wireless Protection Zone
HAAT: Height Above Average Terrain
IAP: Iterative Allocation Process
IOT: Inter-Operability Test
NOAA: National Oceanic and Atmospheric Administration
NTIA: National Telecommunications and Information Administration
PAL: Priority Access License
PPA: PAL Protection Area
RAN: Radio Access Network
SAS: Spectrum Access System
TLS: Transport Layer Security
UUT: Unit Under Test

4.2 Definitions

Main Test Harness: is a collection of routines that can be configured by the test operator to interact with the SAS UUT in order to execute the test cases described in this document. It includes the reference models, Admin Test Harness, SAS Test Harnesses, DP Test Harnesses, CBSD Test Harnesses, and all other test harnesses defined in this document. The Main Test Harness software is stored in a public location specified in [i.1].

SAS Under Test: A Spectrum Access System (SAS) to which the sequence of steps listed in the test specifications in this document is applied via the SAS, CBSD, and ESC Test Harnesses, the SAS Under Test exchanges sequences of simulated messages with simulated Spectrum Access Systems, simulated CBSDs, and simulated ESCs according to the test specifications in this document. In this document, it is referred to as SAS UUT (Unit Under Test).

SAS Test Harness: A collection of routines that can be configured by the test operator to interact with the SAS UUT via interfaces specified in [n.11], and automates critical test sequences and procedures in this document and [n.14]. Via these interfaces and following the specified test procedures, the SAS Test Harness emulates the SAS-SAS Messages specified in [n.11] that would be generated by one SAS. The software without SAS certificate is stored in a public location specified in [i.1].

CBSD Test Harness: A collection of routines that can be configured by the test operator to interact with the SAS UUT via interfaces specified in [n.9] and automates critical test sequences and procedures in this document and [n.14]. Via these interfaces and following the specified test procedures, the CBSD Test Harness emulates the SAS-CBSD Request Messages specified in [n.9] that would be generated by one CBSD, using a TLS connection with CBSD certificate to the SAS UUT. If multiple CBSD Test Harnesses are directly connected to the SAS UUT, each has its own TLS connection to the SAS UUT. The software without CBSD certificate is stored in a public location specified in [i.1].

DP Test Harness: A collection of routines that can be configured by the test operator to interact with the SAS UUT via interfaces specified in [n.9] and automates critical test sequences and procedures in this document and [n.14]. Via these interfaces and following the specified test procedures, the DP Test Harness emulates the SAS-CBSD Request Messages specified in [n.9] that would be generated by one or more CBSDs, using a TLS connection with DP certificate to the SAS UUT. If multiple DP Test Harnesses are connected to the SAS UUT, each has its own TLS connection to the SAS UUT. The DP function within the DP Test Harness merely aggregates the Request Messages of multiple single CBSDs and disaggregates the respective Response Messages of the SAS UUT and does nothing else (i.e., does not have any other unique functionality of a real Domain Proxy). The software without DP certificate is stored in a public location specified in [i.1].

ESC Test Harness: is a collection of routines that can be configured by the test operator to interact with the SAS UUT in order to execute the ESC functionalities of the test cases described in this document. Via these interfaces and following the specified test procedures, the ESC Test Harness emulates the messages that would be sent from an ESC system to a SAS. The ESC Test Harness software is stored in a public location specified in [i.1].

Admin Test Harness: A collection of routines that can be configured by the test operator to inject data that is required for the purpose of the test cases, into the SAS UUT. The Admin Test Harness also has the ability to recognize the completion of CPAS executed by the SAS UUT. The Admin Test Harness software is stored in a public location specified in [i.1].

Baseline State: Baseline State refers to the state of SAS UUT after it is triggered to reset by the test operator or Admin Test Harness.

Coordinated Periodic Activities among SASs (CPAS): Periodic coordination among SASs, which in Release 1 operation is comprised of scheduled external database synchronization, Full Activity Dump Exchange, IAP, and DPA move list calculation. In Release 1, these coordination activities happen daily among SASs. Note: "trigger CPAS" as used in this document differs from normal operation in the following three ways; in particular: (1) all activities will be completed as fast as possible; (2) FAD generation by the SAS UUT is omitted; (3) the SAS UUT will only pull from the external databases specified by the Admin Test Harness.

PPA Information: PPA information includes PAL Database Record and PPA (as defined in [n.11]), which includes the cluster list, list of PAL IDs, and the polygon describing the zone. When Admin Test Harness injects PPA information into SAS UUT, Admin Test Harness shall inject PAL Database Record first and then PPA Zone Definition Message.

Reference Model: Reference Model refers to a calculation implemented in the Main Test Harness. The Reference Model includes the calculation of the Propagation Models, Iterative Allocation Process (IAP), PPA creation, Antenna Gain Model (including antenna pattern), aggregate interference, and DPA Move List as specified in [n.12].

The following terms are used within this document and should be interpreted as described in [n.17]:

• 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)

5 General Principles of Certification Test Cases

The requirements, protocols, specifications, and interfaces are defined by SSC-Wireless Innovation Forum Work Groups 1, 2, and 3. The specifications are derived from FCC, NTIA, and DOD requirements. According to requirements and specifications defined by other work groups, Work Group 4 develops the test cases. The certification test cases can be classified in three classes as follows:

• Functional Test (FT): Test to validate the conformance of the Protocols and functionalities implemented in the SAS UUT to the requirements developed by WInnForum and supporting FCC/DoD requirements.
• Interoperability Test (IOT): Test to validate the interoperability between the components developed by different vendors, compliant to WInnForum Requirements.
• Field/Performance Test (PT): Test to check the capability of the SAS UUT to support various traffic models and actual operations in the field.

The Protocol and Functional test cases are converted to test scripts, which have to be validated through a process defined by WInnForum and FCC. The lab and performance testing require traffic/capacity modeling and measurement equipment.

Vendor testing could be either considered as a pre-requisite for certification process, or, by discretion of the certification management entity, they could be partially or fully considered as part of certification plan.

Certification is governed either directly by, or through a certification body designated by, the FCC, DOD, and WInnForum.

5.1 Test ID Definition

Each test case specified in this document has an associated test ID. A test ID shall be defined in the following format.

{*TestRequirement*}.{*TestCategory*}.{*UnitUnderTest*}.{*TestFunction*}.{*SubTestNumber*}

Test Requirement indicates the test is to verify if the Unit Under Test meets the Technical Specifications provided by WInnForum, which in turn are designed to be compliant with the FCC rules. The category of a test, which can be functional, interoperability, or performance, is shown in TestCategory. UnitUnderTest represents the entity under test, which can be SAS, CBSD, Domain Proxy, ESC or a combination of those entities. TestFunction indicates a particular function or requirement a test intends to verify. SubTestNumber is an integer larger than 0 to number different test cases in a group of tests performing similar test functions.

In the above Test ID format, the strings in the curly braces are replaced by values in the following tables depending on the characteristics of each test.

Table 5.1-1 The values of TestRequirement in Test ID

Table 5.1-2 The values of TestCategory in Test ID

Table 5.1-3 The values of UnitUnderTest in Test ID

Table 5.1-4 The values of TestFunction in Test ID

5.2 Test Triggers

Here is the list of causes that mandate performing the test:

• A SAS Implementation that has not gone through the certification tests, is being launched.
• Changes in a Certified SAS Implementation that may impact functionality, interoperability, or performance
• One or more changes in a Certified SAS Implementation, where the changes could impact the Protocol and Functional Test Cases specified in this document.

5.3 Test Tools Required

The following modules and functionality shall be used for the conformance tests in this document:

• SAS UUT

  • The SAS UUT shall support the following triggers:
    • Reset to baseline state
    • Generate a full activity dump ("FAD generation")
    • Execute CPAS, excluding FAD generation (per [n.20])
    • Execute CPAS as scheduled (including FAD generation) (per [n.20])
    • Always request measurement reports in Registration Response
    • Always request measurement reports in Heartbeat Response
    • Reload all DPAs which may be monitored by an ESC
    • Activate DPA/channel pair
    • Deactivate DPA/channel pair
    • Enable NTIA 15-517 exclusion zones
    • Disconnect ESC
  • The SAS UUT shall support injection of the following data:
    • FCC ID
    • User ID
    • Blacklisted FCC ID
    • Conditional Registration information
    • CPI user information
    • PAL database record
    • Peer SAS (SAS Test Harness) into peer group
    • External database URL
    • Protected entities
      • PPA
      • GWPZ and GWBL
      • FSS
      • Exclusion zone
      • ESC sensor
  • The SAS UUT shall support the following additional APIs:

• Create PPA

• Propagation model query

Exactly the same information exchanged by FAD generation and exchange during CPAS shall be used by all SASs to execute the steps of CPAS

SAS Test Harness

• Appropriate logging tool to collect SAS-SAS messages from SAS Test Harness to SAS UUT and messages from SAS UUT to SAS Test Harness
• Ability to perform FAD Exchange and to be configured with FAD files
• Ability to configure the SAS Test Harness to contain CBSDs and Grants (by provding SAS Test Harness with the corresponding FAD files)

CBSD Test Harness

• Appropriate logging tool to collect messages from the CBSD Test Harness to the SAS UUT and from the SAS UUT to the CBSD Test Harness.
• Appropriate configuration tool to send SAS-CBSD Request Messages to the SAS UUT

Main Test Harness

• Ability to use different Test Harness(es)
• Appropriate logging tool for the messages received from the SAS UUT.
• Ability to check the PASS/FAIL criteria in each test case

Admin Test Harness

• Ability to inject information into the SAS UUT such as FCC ID whitelist, User ID whitelist, Blacklist Data, REG-Conditional Registration data, zone data (PPA, GWPZ, DPA, Exclusion Zone, Quiet Zone), FSS station data, ESC Sensor data, PAL database record.
• Ability to include CBSDs in the PPA cluster list
• Ability to trigger SAS UUT specific function such as to reset SAS UUT to Baseline State, to request measurement report, to send SAS-SAS Push messages, to perform CPAS and to confirm its completion by SAS UUT, to generate the Full Activity Dump"

DP Test Harness

• Appropriate logging tool to collect SAS-DP messages from the DP Test Harness to the SAS UUT and from the SAS UUT to the DP Test Harness
• Appropriate configuration tool to send SAS-DP Request Message to the SAS UUT

ESC Test Harness:

• Appropriate configuration tool to send messages to the SAS UUT

• Appropriate logging tool to collect the messages from the SAS UUT; a message log to collect messages sent between the ESC Test Harness and the SAS UUT.

• At least provide the following parameters to SAS UUT:

• DPA Index Number (s)

• DPA Activation/Deactivation flag (s)

• Channel Number (s) / frequency Range (s)

5.4 Baseline State of the SAS UUT

Unless explicitly stated otherwise as part of the test procedure, the SAS UUT will be reset to the Baseline State at the beginning of every test case. The Reset functionality causes the SAS UUT to delete at least the following data:

• Information about peer SASs (i.e. the number of peer SASs in the Baseline State is zero)
• FCC ID whitelist
• User ID whitelist
• Blacklist data
• CBSD data Record, (including Registration and Grant data)
• Pre-loaded REG-Conditional Registration data
• FSS data
• GWPZ data
• PAL database records
• PPAs
• CPI information
• All data obtained from other SASs (including SAS Test Harnesses)
• Exclusion zones which cannot be monitored by an ESC
• CBSD ID

The following are unloaded by the SAS UUT during Reset:

DPAs which may be monitored by ESCs

The following are NOT affected by Reset:

• International border data
• Census tract data
• United States Coast-line (Mean low Water line)
• Terrain Data and Land Cover
• Quiet Zones

In addition, the SAS UUT shall be configured in the following ways prior to testing:

• All scheduled behavior (external database synchronization, SAS-SAS exchange) is disabled.
• Grant duration (difference between grantExpireTime and the current time) is set to a small value.

6 SAS-CBSD Interface Conformance Test Specifications

This Section includes all test cases required to ensure the SAS-CBSD interface conforms to the specifications defined by WInnForum and as directed by the requirements established by the FCC.

6.1 CBSD Registration Procedure

6.1.1 Definition, Applicability, and Scope of the Test Case

This section provides test steps, conditions, and procedures to test the conformance of SAS implementation of CBSD Registration Procedure.

In this Section "Multi-Step Registration" refers to the Registration procedure in which the "REG-Conditional" parameters are preloaded into the SAS UUT prior to initiating the CBSD Registration Procedure and excluded from the CBSD Registration Request Message. That is, when REG-Conditional data objects including cpiSignatureData is blank. Single-Step Registration refers to the Registration procedure where the REG-Conditional parameters are included in the "RegistrationRequest Object". That is, when REG-Conditional data objects are all included, regardless of whether a CPI provided the data or not.

The main approach is for each test to create necessary conditions to generate a SAS Registration response to a request with all the responseCodes parameters defined in section 10.13 of [n.9], that pertain to the CBSD Registration Procedure in the same reference. This includes successful Registration as well, which is signified by responseCode 0 (please see the table below)

Table 6.1-1 Response Codes for CBSD Registration Procedure Test Cases (Informative)

6.1.2 Test Characteristics

Table 6.1-2: CBSD Registration Procedure Test Characteristics

6.1.3 Method of test

6.1.3.1 Initial Conditions / Test Pre-conditions

1.. All the message exchanges between the SAS UUT and the CBSD/DP Test Harness shall be done by using HTTPS. 2.. Unless otherwise specified, CBSDs registered in the course of a test case are assumed to have their FCC IDs and user IDs already whitelisted by the SAS UUT. 3.. The SAS UUT must be reset at the beginning of each test case to a baseline state.

6.1.4 Test Procedure

6.1.4.1 [WINNF.FT.S.REG.1] Array Multi-Step Registration for CBSDs (Cat A and B)

6.1.4.2 [WINNF.FT.S.REG.2] Array re-Registration of multiple CBSDs

6.1.4.3 [WINNF.FT.S.REG.3] Array Single-Step Registration for CBSDs (Cat A and B)

If any of the above conditions are not met, the SAS UUT FAILS this test. Otherwise, it PASSES.

6.1.4.4 [WINNF.FT.S.REG.4] Array re-Registration of Single-step-registered CBSD (cbsdId exists)

6.1.4.5 [WINNF.FT.S.REG.5] Missing Required parameters in Array Registration Request (responseCode 102)

6.1.4.6 [WINNF.FT.S.REG.6] Pending Registration in Array Registration Request (responseCode 200)

6.1.4.7 [WINNF.FT.S.REG.7] Invalid parameters in Array Registration Request (responseCode 103)1

1 An FCC-certified SAS is expected to conform to the behavior described for CBSDs #15 and #16, utilizing a fullyautomated mechanism for SASs to retrieve and ingest the relevant FCC-owned information.

• valid userId, fccId, and cbsdSerialNumber plus all REG-Conditional parameters for Cat A CBSD for the first CBSD
• valid userId and fccId, invalid cbsdSerialNumber, plus all REG-Conditional parameters for Cat A CBSD for the second CBSD
• valid userId, and cbsdSerialNumber invalid fccId, plus all REG-Conditional parameters for Cat A CBSD for the third CBSD
• valid fccId, and cbsdSerialNumber, invalid userId, plus all REG-Conditional parameters for Cat A CBSD for the fourth CBSD
• valid userId, fccId, and cbsdSerialNumber plus all REG-Conditional parameters for Cat A CBSD for the fifth CBSD, except an out-of-range value for latitude.
• valid userId, fccId, and cbsdSerialNumber plus all REG-Conditional parameters for Cat A CBSD for the sixth CBSD, except an invalid value for measCapability.
• For the seventh CBSD ensure:
  • cbsdCategory = "B"
  • installationParam parameter inside of cpiSignatureData: eirpCapability > 47 dBm/10MHz with valid CPI certification
• For the eighth CBSD ensure:
  • cbsdCategory = "A"
  • No cpiSignatureData is included.
  • Contents of the installationParam parameter:
    • latitude equals to 38° 52' 55.783" N
    • longitude equals to 77° 6' 49.518" W
    • height =4m
    • heightType = AGL
    • indoorDeployment = FALSE
  • All other REG-Conditional parameters valid and included

(Note: FCC web page-https://www.fcc.gov/media/radio/haat-calculatorcalculates HAAT at the street level to be 20m for this location. Installed on a 2nd floor of a building at an AGL of ~4m, HAAT for this CBSD will be 24 meters.)

• For the ninth CBSD ensure:
  • cbsdCategory = "A"
  • No cpiSignatureData is included.
  • Contents of the installationParam parameter:
    • eirpCapability > 30 dBm/10MHz
  • All other REG-Conditional parameters valid and included
• For the tenth CBSD ensure:
  • cbsdCategory = "B"
  • Contents of the installationParam parameter inside of cpiSignatureData:
    • indoorDeployment = TRUE
    • eirpCapability > 30 dBm/10MHz
  • All other REG-Conditional parameters valid and included by a CPI (pre-loaded into SAS)
  • No installationParam outside of cpiSignatureData is included.
• For the eleventh CBSD ensure:
  • cbsdCategory = "B"
  • Contains
    • installationParam parameter outside encodedCpiSignedData
  • All other REG-Conditional parameters valid and included
• For the twelfth CBSD ensure:
  • cbsdCategory = "B"
  • cpiSignatureData object contains at least one invalid identification-related parameter for the CPI
  • No installationParam outside of cpiSignatureData is included.
• For the thirteenth CBSD ensure:
  • cbsdCategory = "B"
  • cpiSignatureData has all the required parameters but has a mismatch on at least one parameter under encodedCpiSignedData compared to the preloaded REG-Conditional parameters
  • The installationParam parameter used for encodedCpiSignedData parameter shall contain all the required parameters being certified by the CPI.
  • No installationParam outside of cpiSignatureData is included.
• For the fourteenth CBSD ensure:
  • cbsdCategory = "B"
  • all REG-Conditional parameters are included outside cpiSignedData.
  • No cpiSignatureData is included.
• For the fifteenth CBSD ensure:
  • cbsdCategory = "A"
  • eirpCapability set to a value greater than the FCC-approved EIRP
  • No cpiSignatureData is included.
• For the sixteenth CBSD ensure:
  • cbsdCategory = "B"
  • Contents of the installationParam parameter inside of cpiSignatureData:
    • eirpCapability set to a value greater than the FCCapproved EIRP
  • No installationParam outside of cpiSignatureData is included.

CHECK SAS UUT sends a CBSD Registration Response in the form of one 16-element Array to the DP Test Harness as follows:

• SAS response includes a valid cbsdId for the first CBSD.
• The responseCode in the RegistrationResponse Object is 0 for the first and the thirteenth CBSD concluding an approved Registration
• The responseCode parameter contained in the response parameter is 103 for the rest of the CBSDs, concluding a failed Registration.

If any of the above conditions are not met, the SAS UUT FAILS this test. Otherwise, it PASSES.

6.1.4.8 [WINNF.FT.S.REG.8] Invalid REG-Conditional parameters in Array Registration Request (responseCode 103)

6.1.4.9 [WINNF.FT.S.REG.9] Blacklisted CBSD in Array Registration Request (responseCode 101)

| | The responseCode parameter contained in the response parameter is 101 for the third CBSD, concluding a failed Registration. | |--|------------------------------------------------------------------------------------------------------------------------------------------------| | | If any of the above conditions are not met, the SAS UUT FAILS this test. Otherwise, it PASSES. |

6.1.4.10 [WINNF.FT.S.REG.10] Unsupported SAS protocol version in Array Registration Request (responseCode 100)

6.1.4.11 [WINNF.FT.S.REG.11] [Configurable] One-time Registration

This configurable test covers tests for both single-step and multi-step Registration (and pending Registrations) for CBSDs (Cat A and/or Cat B) with no existing cbsdId, and with varying combinations of valid, missing, and invalid required parameters, and Reg Conditional parameters, as specified in input configuration files. The test will check the number of and value of the SAS UUT responseCode(s) to verify if they match the expected respondCode(s) as specified in the respective input configuration file.

• The response shall contain N4 RegistrationResponse objects.
• For each RegistrationResponse object:
  • The responseCode parameter contained in the response parameter shall match the corresponding expected response code listed in the configuration file.
  • If responseCode == SUCCESS, verify that the response contains a valid cbsdId.
    • Otherwise, verify that the response does not contain a cbsdId.

If any of the above conditions are not met, the SAS UUT FAILS this test. Otherwise, it PASSES.

6.1.4.12 [WINNF.FT.S.REG.12] [Configurable] re-Registration (including intervening blacklist) This configurable test covers single-step and multi-step re-Registration of CBSDs (Cat A and/or Cat B). The test may blacklist selected CBSDs during re-Registration. The test can use different sets of CBSDs for Registration, blacklisting, and re-Registration. The test will check the number of and value of the SAS UUT responseCode(s) to see if they match the expected responseCode(s) as specified in the respective input configuration file. This includes responseCode 101 (Blacklisted) where appropriate.

6.1.4.13 [WINNF.FT.S.REG.13] [Configurable] Unsupported SAS protocol version

This configurable test covers single-step Registration of CBSD(s) (Cat A and/or Cat B) where the CBSD Registration Request includes a SAS protocol version higher than the highest SAS-CBSD protocol version supported by the SAS UUT. The test will check the number of and value of the SAS UUT responseCode(s) to see if they match the expected responseCode(s) as specified in the respective input configuration file.

6.2 CBSD Spectrum Inquiry Procedure

6.2.1 Definition, Applicability, and Scope of the Test Case

This section explains test steps, conditions, and procedures for SAS Spectrum Inquiry Response to a CBSD Spectrum Inquiry Request. It assumes as a precondition that CBSD has successfully registered with the SAS and has obtained a cbsdId.

The test cases specified in this section attempt to cover the response codes as described in Table 6.2-1.

Table 6.2-1 Response Codes for CBSD Spectrum Inquiry Procedure Test Cases (Informative)

6.2.2 Test Characteristics

Table 6.2-2: CBSD Spectrum Inquiry Procedure Test Characteristics

6.2.3 Method of test

6.2.3.1 Initial Conditions / Test Pre-conditions

1.. No Channel is declared unavailable due to Federal Incumbent Protection purposes (DPA active or inactive) for OPSEC reasons, for any DPA monitored by the SAS's associated ESC (s). 2.. If CBSD is within 150 km of FSS station and a GWBL station is also within 150 km of FSS using any portion of the channel, SAS shall declare the FSS associated channel as unavailable 3.. If CBSD is inside a PPA (CBSD is not part of PPA cluster list) or GWBL zone, the associated channel is declared unavailable. 4.. For the purpose of this document, the Spectrum Inquiry response for other reasons (such as IAP) is per SAS discretion. 5.. The SAS UUT must be reset at the beginning of each test case to a baseline state

6.2.4 Test Procedure

6.2.4.1 [WINNF.FT.S.SIQ.1] Deprecated; the Test ID is Reserved

6.2.4.2 [WINNF.FT.S.SIQ.2] Response has no available channel.

6.2.4.3 [WINNF.FT.S.SIQ.3] Multiple CBSDs inside and outside the Exclusion Zone

responseCode=0

• the availableChannel includes at least the following frequency ranges with channelType set as GAA and ruleApplied as "FCC_PART_96" 3.550 MHz to the lower edge of F
  • upper edge of F to 3650 MHz,
• availableChannel includes F, with channelType set as PAL and ruleApplied as "FCC_PART_96"
• availableChannel does not include any frequency range from 3650-3700 MHz.

For C4:

• responseCode=0
• the availableChannel includes at least the following frequency ranges with channelType set as GAA and ruleApplied as "FCC_PART_96" 3.550 MHz to the lower edge of F
  • upper edge of F to 3650 MHz,
• availableChannel does not include any channel with channelType set as PAL
• availableChannel does not include any frequency range from 3650-3700 MHz.

For C5:

• responseCode = 0
• availableChannel is NULL

If any of the above conditions are not met, the SAS UUT FAILS this test. Otherwise, it PASSES.

6.2.4.4 [WINNF.FT.S.SIQ.4] DPA activated for some channels, CBSD inside DPA Neighborhood

responseCode = 0, indicating a successful inquiry of the spectrum. If any of the above conditions are not met, the SAS UUT FAILS this test. Otherwise, it PASSES.

6.2.4.5 [WINNF.FT.S.SIQ.5] Tests related to PAL Protection Area (PPA)

6.2.4.6 [WINNF.FT.S.SIQ.6] cbsdId sent in the Spectrum Inquiry Response is different from its assigned cbsdId, but the cbsdId does not exist in the SAS

6.2.4.7 [WINNF.FT.S.SIQ.7] cbsdId different from its assigned cbsdId and the cbsdId exists in the SAS.

Informative note: One recommended approach to detect the wrong cbsdId is to use the association between the cbsdId and CBSD certificate

6.2.4.8 [WINNF.FT.S.SIQ.8] Parameters in inquiredSpectrum mutually invalid

6.2.4.9 [WINNF.FT.S.SIQ.9] Multiple Requests as claimed PPAs or as GAAs

6.2.4.10 [WINNF.FT.S.SIQ.10] Array request with successful and unsuccessful responses

• The second object has cbsdId = C2 and one parameter invalid (pick one case from the single request case), but all other parameters are valid.
• The third object has cbsdId = C3. The FrequencyRange object representing the inquiredSpectrum parameter is present, but the highFrequency parameter is missing from this object.
• The fourth object has cbsdId = C4. The FrequencyRange object representing the inquiredSpectrum parameter is present, but the lowFrequency parameter is missing from this object.
• The fifth object has cbsdId = C5, but the FrequencyRange object representing the inquiredSpectrum parameter is completely missing.
• The sixth object has cbsdId missing.

CHECK SAS UUT sends a Spectrum Inquiry Response as follows:

The spectrumInquiryResponse has six objects

• For the first object
  • cbsdId = C1.
  • An array of availableChannel parameters (this may have zero element)
  • The ruleApplied shall be "FCC_PART_96"
  • The responseCode shall be 0, indicating a successful inquiry of the spectrum
• For the second object
  • cbsdId = C2.
  • no availableChannel parameter
  • The responseCode shall be 103, indicating an invalid parameter
• For the third object
  • cbsdId = C3.
  • no availableChannel parameter
  • The responseCode shall be 102, indicating a missing parameter
• For the fourth object
  • cbsdId = C4.
  • no availableChannel parameter
  • The responseCode shall be 102, indicating a missing parameter
• For the fifth object
  • cbsdId = C5.
  • no availableChannel parameter
  • The responseCode shall be 102, indicating a missing parameter
• For the sixth object
  • No cbsdId
  • no availableChannel parameter
  • The responseCode shall be 102, indicating a missing parameter

If any of the above conditions are not met, the SAS UUT FAILS this test. Otherwise, it PASSES.

6.2.4.11 [WINNF.FT.S.SIQ.11] Unsupported Spectrum (responseCode 300)

6.2.4.12 [WINNF.FT.S.SIQ.12] [Configurable] Spectrum inquiry in the presence of protected entities

This configurable array test covers spectrum inquiry request(s), optionally in the presence of protected entities. The first step is to inject Grandfathered Wireless Broadband Licensee Protected Zones into the SAS. The next step is to successfully register CBSD(s). The next step is to inject PPAs into the SAS, and to run CPAS to start protection of protected entities. Then, submit a spectrum inquiry request from previously registered CBSD(s) with varying combinations of valid, missing, and invalid required parameters. The test will check the number of and value of the spectrum inquiry SAS UUT responseCode(s) to see if they match the expected responseCode(s) as specified in the respective input configuration file. The SAS UUT response shall also include a list of available channels.

6.2.4.13 [WINNF.FT.S.SIQ.13] Blacklisted CBSD in Array request (responseCode 101)

6.3 CBSD Spectrum Grant Procedure

6.3.1 Definition, Applicability, and Scope of the Test Case

This section explains test steps, conditions, and procedures to test the conformance of CBSD Grant Procedure.

The responseCode parameters in tables 40 and 41 of [n.9] outlines the possible conditions associated with a Grant Request and the expected Grant Response from a SAS UUT. (please see the table below)

Table 6.3-1 Response Codes for CBSD Grant Procedure Test Cases (Informative)

6.3.2 Test Characteristics

Table 6.3-2 CBSD Spectrum Grant Procedure Test Characteristics

6.3.3 Method of test

6.3.3.1 Initial Conditions / Test Pre-conditions

The typical pre-conditions of the test case are the following:

The SAS UUT must be reset at the beginning of each test case to a baseline state.

6.3.4 Test Procedure

6.3.4.1 [WINNF.FT.S.GRA.1] Federal Incumbent present in the PAL frequency range requested by the CBSD who is inside the DPA Neighborhood

6.3.4.2 [WINNF.FT.S.GRA.2] Grant Array with Missing parameters

6.3.4.3 [WINNF.FT.S.GRA.3] cbsdId does not exist in SAS

6.3.4.4 [WINNF.FT.S.GRA.4] cbsdId sent by the CBSD is not its cbsdId, but of some other CBSD which is currently registered with the SAS

Informative note: One recommended approach to detect the wrong cbsdId is to use the association between the cbsdId and CBSD certificate

6.3.4.5 [WINNF.FT.S.GRA.5] SAS rejects GrantRequest if the CBSD already has a Grant from another SAS

6.3.4.6 [WINNF.FT.S.GRA.6] SAS terminates Grant upon learning that the CBSD has a Grant from another SAS

6.3.4.7 [WINNF.FT.S.GRA.7] Invalid operationFrequencyRange

6.3.4.8 [WINNF.FT.S.GRA.8] CBSD requests a frequency range which is a mix of PAL and GAA channel.

6.3.4.9 [WINNF.FT.S.GRA.9] Frequency range requested by a CBSD overlaps with PAL channel and the CBSD is inside the PPA boundary claimed by other CBSD User.

6.3.4.10 [WINNF.FT.S.GRA.10] First request granted as PAL or GAA channel, send next request for PAL or GAA channel for a partially or fully overlapped frequency range

6.3.4.11 [WINNF.FT.S.GRA.11] Un-Supported CBSD maximum EIRP

This test case tests SAS operation in response to a requested maxEirp specified in the grantRequest that is not supported for the CBSD claimed category, or compared with CBSDs certified (allowed) maximum EIRP in FCC-ID Whitelist (noted as FCC_EIRPCi for CBSD Ci below

2 An FCC-certified SAS is expected to conform to the behavior described in this CHECK process, utilizing a fullyautomated mechanism for SASs to retrieve and ingest the relevant FCC-owned information

6.3.4.12 [WINNF.FT.S.GRA.12] Blacklisted CBSD in Array request (responseCode 101)

6.3.4.13 [WINNF.FT.S.GRA.13] Requests for multiple PAL channels and for multiple GAA channels; no incumbent present in the PAL and GAA frequency ranges used in the requests.

6.3.4.14 [WINNF.FT.S.GRA.14] Deprecated; the Test ID is Reserved

6.3.4.15 [WINNF.FT.S.GRA.15] Both the requests result in unsuccessful Grant Response

6.3.4.16 [WINNF.FT.S.GRA.16] The two requests carry overlapping frequency range in the Grant Request from the same CBSD.

6.3.4.17 [WINNF.FT.S.GRA.17] [Configurable] Array Grant Request

This configurable test covers Grant tests where there is no incumbent present (Grant tests where an incumbent is present are covered in the functional tests), and can cover situations where the CBSD (Cat A and/or Cat B) Grant Request: includes frequency ranges covering GAA frequencies and/or PAL frequencies and/or combinations of GAA and PAL frequencies and/or frequencies ranges that are completely and/or partly outside the CBRS band; has a missing cbsdId and/or a cbsdId that does not exist in the SAS; has missing and/or invalid and/or valid operational parameters. The test can also include CBSD Grant Requests that fall within PPAs. The test will check the number and value of the Grant SAS UUT responseCodes (including the appropriate number of responseCodes) to see if they match the expected responseCodes as specified in the respective input configuration file, which will include codes of 0 (success), 102 (missing parameter), 103 (invalid value), 300 (unsupported spectrum), 400 (Interference), 401 (grant conflict).

CHECK The Grant Response Message from the SAS UUT must satisfy all of the following conditions:

The grantResponse parameter shall contain N1 elements:

• For each element:
  • The responseCode shall match the corresponding expected responseCode listed in the configuration file.
  • If the corresponding request contained a valid cbsdId, the response shall contain the same cbsdId.
  • If responseCode = SUCCESS, verify that the response contains a valid grantId.
    • Otherwise, verify that the response does not contain a grantId.

If any of the above conditions are not met, the SAS UUT FAILS this test. Otherwise, it PASSES.

6.4 CBSD Heartbeat Procedure

6.4.1 Definition, Applicability, and Scope of the Test Case

This section explains test steps, conditions, and procedures for SAS Heartbeat Response Message to a CBSD Heartbeat Request Message.

The approach is for each test to create necessary conditions to generate a SAS Heartbeat Response Message to a CBSD Heartbeat Request Message with all the defined responseCode parameters pertaining to the CBSD Heartbeat Procedure in [n.9]. This includes successful Heartbeat Request as well, which is signified by responseCode 0. (please see the table below)

Table 6.4-1 Response Codes for CBSD Heartbeat Procedure Test Cases (Informative)

6.4.2 Test Characteristics

Table 6.4-2 CBSD Heartbeat Procedure Test Characteristics

6.4.3 Method of test

6.4.3.1 Initial Conditions / Test Pre-conditions

The typical pre-conditions of the test case are the following:

The SAS UUT must be reset at the beginning of each test case to a baseline state.

6.4.4 Test Procedure

6.4.4.1 [WINNF.FT.S.HBT.1] Array request: Successful Heartbeat Request

This test case tests the scenario when the CBSDs move immediately into Granted State or following a Heartbeat Response.

6.4.4.2 [WINNF.FT.S.HBT.2] Array request: Successful Heartbeat Request from CBSD for Grant renewal

6.4.4.3 [WINNF.FT.S.HBT.3] Array request: Unsuccessful VERSION (responseCode 100) Initial Heartbeat Request (immediately after CBSD moves into Granted State) is from a CBSD with an unsupported protocol version by SAS.

6.4.4.4 [WINNF.FT.S.HBT.4] Array request: Successful or Unsuccessful Heartbeat Request from CBSD in Granted or Authorized state due to missing required parameters.

This test case tests the scenario when the CBSDs move immediately into Granted State or following a Heartbeat Response has required parameters missing.

6.4.4.5 [WINNF.FT.S.HBT.5] Unsuccessful Heartbeat Request from CBSD in Registered state This test case tests the scenario when the CBSD sends Heartbeat Request immediately after CBSD's Grant is terminated.

6.4.4.6 [WINNF.FT.S.HBT.6] Unsuccessful Heartbeat Request from CBSD in Registered state (immediately after CBSD's Grant is expired)

6.4.4.7 [WINNF.FT.S.HBT.7] Array request: Unsuccessful INVALID_VALUE (responseCode 103)

Heartbeat Request from CBSD in Granted or Authorized state (immediately after CBSD moves into Granted State or following a Heartbeat Response) has invalid required parameters.

6.4.4.8 [WINNF.FT.S.HBT.8] Array request: Unsuccessful BLACKLISTED (responseCode 101)

6.4.4.9 [WINNF.FT.S.HBT.9] Array request: Heartbeat Request for the Grants in Authorized state results TERMINATED_GRANT

The CBSD Heartbeat Procedure for the Grants in Authorized state results in 500 (TERMINATED_GRANT) when incumbent status has changed permanently

• Each element includes the cbsdId, and grantId that match the request from each CBSD in the array.
• The responseCode shall be 0 for the first two CBSDs concluding a successful operation.
• transmitExpireTime is set to a valid UTC time in the future for the first two CBSDs. It shall be not later than 240 seconds in the future and not later than the grantExpireTime.
• The responseCode for the third CBSD set to 500, concluding a failed operation due to termination of the Grant.
• transmitExpireTime shall be set to no later than the current time, for the third CBSD

If any of the above conditions are not met, the SAS UUT FAILS this test. Otherwise, it PASSES.

6.4.4.10 [WINNF.FT.S.HBT.10] [Configurable] Heartbeat with optional intervening Grant termination or blacklist

This configurable array test covers Heartbeat Request Messages for CBSDs with existing Grants where Heartbeat Request Messages come immediately after a CBSD moves into Granted State or following a Heartbeat Response Message; for Grant Renewal; Heartbeat Request Messages with and without missing, valid, and invalid required parameters; and Heartbeat Request Messages requiring Deregistration. The test will check the number of and value of the Heartbeat SAS UUT responseCode(s) to see if they match the expected responseCode(s) as specified in the respective input configuration file.

6.4.4.11 [WINNF.FT.S.HBT.11] Out of sync Grant state between the CBSD and the SAS

6.4.4.12 [WINNF.FT.S.HBT.12] The Grant is Suspended or Terminated in the Heartbeat Response

6.5 CBSD Measurement Report

6.5.1 Definition, Applicability, and Scope of the Test Case

This section specifies test cases to validate SAS configuring CBSD measurement report based on CBSD measurement capability, based on CBSD measurement capability in the Registration Response Message. (please see the table below)

Table 6.5-1 Response Codes for CBSD Measurement Report Test Cases (Informative)

6.5.2 Test Characteristics

Table 6.5-2 CBSD Measurement Report Test Characteristics

6.5.3 Method of test

6.5.3.1 Initial Conditions / Test Pre-conditions

The typical pre-conditions of the test case are the following:

• The SAS UUT must be reset at the beginning of each test case to a baseline state.
• cbsdId is known (C)
• SAS has registered CBSD and for some of the test cases, issued approved a Grant Request with grantId G1.

6.5.4 Test Procedure

To exercise the possible types of successful measurement report mechanisms the following aspects are tested:

• CBSD measurement capability exchange
• CBSD measurement configuration through Registration Response
• CBSD measurement configuration through Grant Response
• CBSD measurement configuration through Heartbeat Response

6.5.4.1 [WINNF.FT.S.MES.1] Registration response with measurement report configuration

6.5.4.2 [WINNF.FT.S.MES.2] Heartbeat response with measurement report configuration

6.6 CBSD Spectrum Relinquish Procedure

6.6.1 Definition, Applicability, and Scope of the Test Case

This section specifies test steps, conditions, and procedures to test the conformance of CBSD Relinquishment Procedure.

A Relinquishment Request is issued by a CBSD to inform a SAS that one or more Grants are no longer being used by the CBSD.

The approach is for each test to create necessary conditions to trigger a Relinquish Response from SAS to a Relinquish request from a CBSD with all the defined responseCode parameters in [n.9], both successful Relinquishments (responseCode 0) and unsuccessful Relinquishments (other responseCodes). (please see the table below)

Table 6.6-1 Response Codes for CBSD Grant Relinquishment Procedure Test Cases (Informative)

6.6.2 Test Characteristics

Table 6.6-2 CBSD Spectrum Relinquish Procedure Test Characteristics

6.6.3 Method of test

6.6.3.1 Initial Conditions / Test Pre-conditions

The typical pre-conditions of the test case are the following:

The SAS UUT must be reset at the beginning of each test case to a baseline state.

6.6.4 Test Procedure

To exercise the possible types of successful Relinquishment Requests the following three types of Grant Relinquishment Requests are tested:

• Grant and Relinquishment of a single Grant
• Three Grants, iteratively relinquished
• Three Grants, simultaneously relinquished as an array of three Relinquishment Requests

For invalid Relinquishment Requests, the following types of Grant Relinquishment Requests are tested:

• Grant and Relinquishment of a single Grant with an error
• Three Grants, requested for release in an array, with an error in one element of the array

6.6.4.1 [WINNF.FT.S.RLQ.1] Multiple Iterative Grant Relinquishments:

transmitExpireTime set to a value equal or less than the transmitExpireTime in the previous successful Heartbeat response. If this is the first Heartbeat response, any value for transmitExpireTime is acceptable.

If any of the above conditions are not met, the SAS UUT FAILS this test. Otherwise, it PASSES.

6.6.4.2 [WINNF.FT.S.RLQ.2] Multiple Grant Relinquishments: Successful Simultaneous Relinquishment Request of Multiple Grants (responseCode 0)

If any of the above conditions are not met, the SAS UUT FAILS this test. Otherwise, it PASSES.

6.6.4.3 [WINNF.FT.S.RLQ.3] Invalid Parameter in Relinquishment Request-Array Request

• No grantId
  • responseCode = 103

If any of the above conditions are not met, the SAS UUT FAILS this test. Otherwise, it PASSES.

6.6.4.4 [WINNF.FT.S.RLQ.4] Protocol Not Supported by SAS-Array Request

6.6.4.5 [WINNF.FT.S.RLQ.5] Missing Parameter -Array Request

6.6.4.6 [WINNF.FT.S.RLQ.6] [Configurable] Multiple Relinquishments

This configurable array test covers Relinquishment Request(s) for CBSDs with existing Grants, including Relinquishment Requests for multiple iterative Grants, simultaneous Relinquishment of multiple Grants and array relinquishment requests; and Relinquishment Requests with missing parameters. The test will check the number of and value of the Relinquishment SAS UUT responseCode(s) to see if they match the expected responseCode(s) as specified in the respective input configuration file.

| 2 | DP Test Harness sends a valid Registration Request Message with the registrationRequest parameter containing N1 >= 0 CBSDs. Verify that the responseCode for each is SUCCESS. | | | | |-------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------|--|--| | 3 | DP Test Harness sends a valid Grant Request with the grantRequest parameter containing N2 >= 0 elements. Verify that the responseCode for each is SUCCESS. | | | | | 4 | DP Test Harness sends a Relinquishment Request Message with the relinqushmentRequest parameter containing N3 >= 0 elements. | | | | | CHECK | The SAS response to the Relinquishment Request must satisfy all of the following conditions: | | | | | | | The relinquishmentResponse parameter contains N3 elements. | | | | | | For each element: | | | | | | o The responseCode shall match the corresponding expected responseCode listed in the configuration file. | | | | | | o If the corresponding request contained a valid cbsdId and grantId, the response shall contain the same grantId. | | | | | If any of the above conditions are not met, the SAS UUT FAILS this test. Otherwise, proceed. | | | | | 5 | DP Test Harness sends a Relinquishment Request Message with the relinqushmentRequest parameter containing N4 >= 0 elements. | | | | | CHECK | The SAS response to the Relinquishment Request Message must satisfy all of the following conditions: | | | | | | | The relinquishmentResponse parameter contains N4 elements. | | | | | | For each element: | | | | | | o The responseCode shall match the corresponding expected responseCode listed in the configuration file. | | | | | | o If the corresponding request contained a valid cbsdId and grantId, the response shall contain the same grantId. | | | | | If any of the above conditions are not met, the SAS UUT FAILS this test. Otherwise, it PASSES. | | | |

6.7 CBSD Deregistration Procedure

6.7.1 Definition, Applicability, and Scope of the Test Case

This section explains test steps, conditions, and procedures for SAS Deregistration Response to a CBSD Deregistration Request. (please see the table below for the responseCodes)

Table 6.7-1 Response Codes for CBSD Deregistration Procedure Test Cases (Informative)

6.7.2 Test Characteristics

Table 6.7-2 CBSD Deregistration Procedure Test Characteristics

6.7.3 Method of test

6.7.3.1 Initial Conditions / Test Pre-conditions

The typical pre-conditions of the test case are the following:

The SAS UUT must be reset at the beginning of each test case to a baseline state.

6.7.4 Test Procedure

6.7.4.1 [WINNF.FT.S.DRG.1] Valid and correct cbsdId: two DeregistrationRequest objects

6.7.4.2 [WINNF.FT.S.DRG.2] Missing cbsdId: two elements in the DeregistrationRequest parameter

6.7.4.3 [WINNF.FT.S.DRG.3] cbsdId initially exists, CBSD deregisters first by sending Deregistration request. Then sends another Deregistration request to check that SAS has indeed erased the CBSD information from its database.

6.7.4.4 [WINNF.FT.S.DRG.4] cbsdId value invalid: two request objects

6.7.4.5 [WINNF.FT.S.DRG.5] cbsdId initially exists with a Grant, CBSD deregisters, then reregisters and attempts to use the old grantId (verifying that SAS deletes Grants on Deregistration).

6.7.4.6 [WINNF.FT.S.DRG.6] [Configurable] Array Deregistration

This configurable array test covers Deregistration Request(s) for existing CBSDs, and can include Deregistration Requests with valid and invalid cbsdIds, missing cbsdIds, iterative Deregistrations, and where a CBSD reregisters, and sends a HeartbeatRequest with an old grantId. The test will check the number of and value of the Deregistration SAS UUT responseCode(s) to see if they match the expected responseCode(s) as specified in the respective input configuration file.

6.8 CBSD Device Security Validation

6.8.1 Definition, Applicability, and Scope of the Test Case

This section explains test steps, conditions, and procedures for SAS validation of CBSD security credentials.

6.8.2 Test Characteristics

Table 6.8-1 CBSD Device Security Validation Test Characteristics

6.8.3 Method of test

6.8.3.1 Initial Conditions / Test Pre-conditions

• − The SAS may be placed in a test configuration so that test certificates can be used for testing.
• − Valid certificates must be created according to the guidelines given in [n.8]. Sample code for creating test certificates is provided in [i.1]. If such test code is used, the SAS must be configured to use the test certificate root of trust.
• − The certificates required to perform the test cases may be created by the sample code provided in [i.1] or provided by a valid CBRS root of trust CA
• − The SAS UUT must be reset at the beginning of each test case to a baseline state.

6.8.4 Test Procedure

6.8.4.1 [WINNF.FT.S.SCS.1] New Registration with TLS_RSA_WITH_AES_128_GCM_SHA256 ciphersuite (No existing cbsdId)

6.8.4.2 [WINNF.FT.S.SCS.2] New Registration with TLS_RSA_WITH_AES_256_GCM_SHA384 ciphersuite (No existing cbsdId)

6.8.4.3 [WINNF.FT.S.SCS.3] New Registration with TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (No existing cbsdId)

Verify that the response contains a valid cbsdId. If any of the above conditions are not met, the SAS UUT FAILS this test. Otherwise, it PASSES.

6.8.4.4 [WINNF.FT.S.SCS.4] New Registration with TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (No existing cbsdId)

6.8.4.5 [WINNF.FT.S.SCS.5] New Registration with TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (No existing cbsdId)

6.8.4.6 [WINNF.FT.S.SCS.6] Unrecognized root of trust certificate presented during Registration.

6.8.4.7 [WINNF.FT.S.SCS.7] Corrupted certificate presented during Registration.

6.8.4.8 [WINNF.FT.S.SCS.8] Self-signed certificate presented during Registration.

6.8.4.9 [WINNF.FT.S.SCS.9] Non-CBRS trust root signed certificate presented during Registration.

6.8.4.10 [WINNF.FT.S.SCS.10] Certificate of wrong type presented during Registration.

6.8.4.11 [WINNF.FT.S.SCS.11] Blacklisted certificate presented during Registration.

6.8.4.12 [WINNF.FT.S.SCS.12] Expired certificate presented during Registration.

6.8.4.13 [WINNF.FT.S.SCS.13] Disallowed TLS method attempted during Registration.

6.8.4.14 [WINNF.FT.S.SCS.14] Invalid ciphersuite presented during Registration.

6.8.4.15 [WINNF.FT.S.SCS.15] Certificate with inapplicable fields presented during Registration.

6.8.4.16 [WINNF.FT.S.SCS.16] Certificate signed by a revoked sub-CA presented during Registration.

6.8.4.17 [WINNF.FT.S.SCS.17] Invalid certificate following an approved Registration Request

6.8.4.18 [WINNF.FT.S.SCS.18] Invalid certificate following an approved Grant Request

6.8.4.19 [WINNF.FT.S.SCS.19] Invalid certificate following an approved Heartbeat Request

6.8.4.20 [WINNF.FT.S.SCS.20] Deprecated; the Test ID is Reserved

6.9 Domain Proxy Security Validation

6.9.1 Definition, Applicability, and Scope of the Test Case

This section explains test steps, conditions, and procedures for SAS validation of DP security credentials.

6.9.2 Test Characteristics

Table 6.9-1 Domain Proxy Security Validation Test Characteristics

6.9.3 Method of test

6.9.3.1 Initial Conditions / Test Pre-conditions

• − The SAS may be placed in a test configuration so that test certificates can be used for testing.
• − Valid certificates must be created according to the guidelines given in [n.8]. Sample code for creating test certificates is provided in [i.1]. If such test code is used, the SAS must be configured to use the test certificate root of trust.
• − The certificates required to perform the test cases may be created by the sample code provided in [i.1] or provided by a valid CBRS root of trust CA
• − The SAS UUT must be reset at the beginning of each test case to a baseline state.

6.9.4 Test Procedure

6.9.4.1 [WINNF.FT.S.SDS.1] New Registration with TLS_RSA_WITH_AES_128_GCM_SHA256 ciphersuite (No existing cbsdId)

6.9.4.2 [WINNF.FT.S.SDS.2] New Registration with TLS_RSA_WITH_AES_256_GCM_SHA384 ciphersuite (No existing cbsdId)

6.9.4.3 [WINNF.FT.S.SDS.3] New Registration with TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (No existing cbsdId)

Verify that the response contains a valid cbsdId. If any of the above conditions are not met, the SAS UUT FAILS this test. Otherwise, it PASSES.

6.9.4.4 [WINNF.FT.S.SDS.4] New Registration with TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (No existing cbsdId)

6.9.4.5 [WINNF.FT.S.SDS.5] New Registration with TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (No existing cbsdId)

6.9.4.6 [WINNF.FT.S.SDS.6] Unrecognized root of trust certificate presented during Registration.

6.9.4.7 [WINNF.FT.S.SDS.7] Corrupted certificate presented during Registration.

6.9.4.8 [WINNF.FT.S.SDS.8] Self-signed certificate presented during Registration.

6.9.4.9 [WINNF.FT.S.SDS.9] Non-CBRS trust root signed certificate presented during Registration.

6.9.4.10 [WINNF.FT.S.SDS.10] Certificate of wrong type presented during Registration.

6.9.4.11 [WINNF.FT.S.SDS.11] Blacklisted certificate presented during Registration.

6.9.4.12 [WINNF.FT.S.SDS.12] Expired certificate presented during Registration.

6.9.4.13 [WINNF.FT.S.SDS.13] Disallowed TLS method attempted during Registration.

6.9.4.14 [WINNF.FT.S.SDS.14] Invalid ciphersuite presented during Registration.

6.9.4.15 [WINNF.FT.S.SDS.15] Certificate with inapplicable fields presented during Registration.

6.9.4.16 [WINNF.FT.S.SDS.16] Certificate signed by a revoked sub-CA presented during Registration.

6.9.4.17 [WINNF.FT.S.SDS.17] Invalid certificate following an approved Registration Request

6.9.4.18 [WINNF.FT.S.SDS.18] Invalid certificate following an approved Grant Request

6.9.4.19 [WINNF.FT.S.SDS.19] Invalid certificate following an approved Heartbeat Request

7 SAS-SAS Interface Conformance Test Specifications

This section specifies test cases required for SAS to verify the conformance with the technical specifications on procedures and protocols for SAS-SAS interface [n.11] and the requirements established by FCC and DOD.

7.1 SAS-SAS Security, Authentication, and Encryption Protocols

7.1.1 Definition, Applicability, and Scope of the Test Case

This section explains test steps, conditions, and procedures for SAS validation of SAS security credentials. The precondition is that the SAS UUT has been granted a valid certificate according to the processes described in [n.8].

7.1.2 Test Characteristics

Table 7.1-1 SAS Security Validation Test Characteristics

7.1.3 Method of test

7.1.3.1 Initial Conditions / Test Pre-conditions

• − The SAS may be placed in a test configuration so that test certificates can be used for testing.
• − Valid certificates must be created according to the guidelines given in [n.8]. Sample code for creating test certificates is provided in [i.1]. If such test code is used, the SAS must be configured to use the test certificate root of trust.
• − The certificates required to perform the test cases may be created by the sample code provided in [i.1] or provided by a valid CBRS root of trust CA
• − The SAS UUT must be reset at the beginning of each test case to a baseline state.
• − Unless otherwise specified, SAS Test Harnesses used in the course of a test case are assumed to be whitelisted with the SAS UUT.

7.1.4 Test Procedure

7.1.4.1 [WINNF.FT.S.SSS.1] New Registration with TLS_RSA_WITH_AES_128_GCM_SHA256 ciphersuite

7.1.4.2 [WINNF.FT.S.SSS.2] New Registration with TLS_RSA_WITH_AES_256_GCM_SHA384 ciphersuite

7.1.4.3 [WINNF.FT.S.SSS.3] New Registration with TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 ciphersuite

Confirm that HTTP status code shall be 200 (SUCCESS). If any of the above conditions are not met, the SAS UUT FAILS this test. Otherwise, it PASSES.

7.1.4.4 [WINNF.FT.S.SSS.4] New Registration with TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ciphersuite

7.1.4.5 [WINNF.FT.S.SSS.5] New Registration with TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ciphersuite

7.1.4.6 [WINNF.FT.S.SSS.6] Unrecognized root of trust certificate presented by SAS Test Harness

7.1.4.7 [WINNF.FT.S.SSS.7] Corrupted certificate presented by SAS Test Harness

7.1.4.8 [WINNF.FT.S.SSS.8] Self-signed certificate presented by SAS Test Harness

7.1.4.9 [WINNF.FT.S.SSS.9] Non-CBRS trust root signed certificate presented by SAS Test Harness

7.1.4.10 [WINNF.FT.S.SSS.10] Certificate of wrong type presented during Full Activity Dump .

7.1.4.11 [WINNF.FT.S.SSS.11] Blacklisted certificate presented by SAS Test Harness

7.1.4.12 [WINNF.FT.S.SSS.12] Expired certificate presented by SAS Test Harness

| | Or The SAS UUT sends a fatal alert message with the following parameters: AlertLevel = 2 (fatal) The SAS UUT immediately terminates the TLS session If any of the above conditions are not met, the SAS UUT FAILS this test. Otherwise, it PASSES. | |--|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| |--|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|

7.1.4.13 [WINNF.FT.S.SSS.13] Disallowed TLS method attempted by SAS Test Harness

7.1.4.14 [WINNF.FT.S.SSS.14] Invalid ciphersuite presented by SAS Test Harness

7.1.4.15 [WINNF.FT.S.SSS.15] Certificate with inapplicable fields presented during Full Activity Dump.

7.1.4.16 [WINNF.FT.S.SSS.16] Certificate signed by a revoked sub-CA presented by SAS Test Harness

7.1.4.17 [WINNF.FT.S.SSS.17] Unknown SAS attempts to establish a TLS session

7.1.4.18 [WINNF.FT.S.SSS.18] Security requirement for Full Activity Dump message Request

This test verifies that a SAS UUT can successfully validate the appropriateness of the security credentials included in a Full Activity Dump Message request from the SAS Test Harness. If the FAD request security credentials are appropriate, the SAS UUT approves the FAD request and responds with the Full Activity Dump Message. If any of the certificates turns out to be invalid, the SAS UUT rejects the request. This test case shall be re-run for all possible iterations of an "invalid certificate"

7.2 SAS-SAS Full Activity Dump Message

7.2.1 Definition, Applicability, and Scope of the Test Case

This section provides test steps, conditions, and procedures of test cases for SAS validation of the Full Activity Dump exchange procedure. SAS UUT shall have valid certificates and information to send message to SAS Test Harness, and vice versa.

7.2.2 Test Characteristics

Table 7.2-1: SAS-SAS Full Activity Dump Test Characteristics

7.2.3 Method of test

7.2.3.1 Initial Conditions / Test Pre-conditions

• SAS UUT can establish a TLS session with SAS Test Harness, as well as the other way around.
• The SAS UUT must be reset at the beginning of each test case to a Baseline State.
• Unless otherwise specified, SAS Test Harnesses used in the course of a test case are assumed to be whitelisted with the SAS UUT.
• All SAS Administrators shall adhere to information sharing requirements as described in [n.12, R2-ISC-07]

7.2.4 Test Procedure

7.2.4.1 [WINNF.FT.S.FAD.1] [Configurable] SAS UUT Response to a Full Activity Dump Pull Request

This test verifies that a SAS UUT can successfully respond to a Full Activity Dump Request from a SAS Test Harness, and that responses to all SAS Test Harnesses are consistent.

7.2.4.2 [WINNF.FT.S.FAD.2] [Configurable] Full Activity Dump Pull Command by SAS UUT

This test verifies that a SAS UUT can successfully request a Full Activity Dump and utilize the retrieved data.

8 SAS Functional Test Specifications

This section specifies the test cases required to ensure the functionalities implemented in the SAS UUT conform to the specifications, as defined by WInnForum and directed by the requirements established by FCC and DOD.

8.1 Exclusion Zone Enforcement

8.1.1 Definition, Applicability, and Scope of the Test Case

This section provides steps, conditions and procedures to test the conformance of SAS implementation of the Exclusion Zone Enforcement required by [n.1] and [n.2] prior to approval of one or more ESCs used by at least one SAS in accordance to [n.1].

The following classes of Exclusion zones are within the scope of these tests:

• Ground Based Radar Exclusion Zone
• Shoreline Exclusion Zone
• Radiolocation sites

8.1.2 Test Characteristics

Table 8.1-1 Exclusion Zone Enforcement Test Characteristics

8.1.3 Method of test

8.1.3.1 Initial Conditions / Test Pre-conditions

8.1.3.2 Test Tools Required

• Admin Test Harness, DP Test Harness
• SAS UUT supports an API trigger to enforce the Exclusion Zone Boundaries defined by NTIA in [n.4]

8.1.3.3 General Test Methodology

For the first test case, Exclusion Zones are prepared. Multiple zones can be tested at once. These zones are injected by the Admin Test Harness and some number of CBSDs are configured inside or outside the Exclusion Zones.

For the second test case, the Exclusion Zones defined in NTIA TR 15-517 [n.4] are used. The SAS UUT is triggered by the Admin Test Harness to enforce the zones.

The test results are verified by checking if the SAS UUT correctly responds to the Grant Requests from the DP Test Harness according to the distance between the CBSD and the boundary of each Exclusion Zone.

The Grant response shall be as follows according to the location of each CBSD:

• When a CBSD is inside the Exclusion Zone, the Grant shall be denied.
• When a CBSD is outside the Exclusion Zone but the distance from the boundary is less than or equal to 50 m, the Grant shall be denied.
• Otherwise, the Grant shall be accepted.

8.1.4 Test Procedure

8.1.4.1 [WINNF.FT.S.EXZ.1] Injected Exclusion Zones

8.1.4.2 [WINNF.FT.S.EXZ.2] Exclusion Zones defined in NTIA TR 15-517

Note: FCC is in process of evaluating the waiver of this test case for SAS Administrators supporting DPA functionality.

• cbsdId (Response) == cbsdId (Request)
• The response does not contain a grantId.
• For each N3 grantResponse object:
  • The responseCode = 400
  • cbsdId (Response) == cbsdId (Request)
  • The response does not contain a grantId.

If the any of the above conditions is not met, the SAS FAILS this test. Otherwise, it PASSES.

8.2 Propagation Model and Antenna Gain Calculation Testing

8.2.1 Definition, Applicability, and Scope of the Test Case

This section explains test steps, conditions, and procedures to verify that SAS correctly calculates:

1.. path loss based on propagation models as defined in [n.12], and 2.. the antenna gains of CBSDs and FSS based on locations and antenna patterns of the transmitter and the receiver as defined in [n.12].

8.2.2 Test Characteristics

Table 8.2-1 Propagation model and Antenna Gain Calculation Test Characteristics

8.2.3 Method of test

A special Propagation Model API is used for this test so that the SAS UUT can perform path loss and antenna gain calculation without exercising the rest of the SAS functions. The Propagation Model API shall be used to execute the test case outlined in this section to validate SAS UUT implementation of propagation model and antenna gain only. To execute this test, the Admin Test Harness shall send configurations of a CBSD as the transmitter, an FSS as the receiver, and a propagation model type to the SAS UUT through the Propagation Model API. After receiving the test configurations from the Admin Test Harness, the SAS UUT shall compute the CBSD antenna gain, the FSS antenna gain, and the path loss accordingly, and send the results back to Admin Test Harness through the Propagation Model API. The Main Test Harness calculates the CBSD antenna

gain, the FSS antenna gain, and the path loss with the same configurations using the reference implementation. A SAS UUT passes this test if the calculated antenna gains and path loss are within certain ranges of the results calculated by the reference implementation.

This test can be configured differently to test different scenarios.

8.2.3.1 Initial Conditions / Test Pre-conditions

8.2.3.2 Test Tools Required

The Propagation Model API used for this test includes two parts. The first part is test configurations sent by Admin Test Harness to SAS UUT. The second part is test results sent by SAS UUT to Admin Test Harness. The content of the Propagation Model API is listed in the following.

From Admin Test Harness to SAS UUT:

1. Propagation model:

Reliability level: -1, 0.05, and 0.95. A value of "-1" indicates the mean value shall be calculated. This parameter only applies to the ITM model. The mean path loss is always returned by the SAS UUT if the Hybrid model is used. The mean path loss is defined as 1 <1/> , where L is the path loss of the ITM and hybrid propagation Reference Models, and <·> denotes the statistical mean. Confidence interval is always set at 0.5 for ITM model.

2. CBSD (Tx) configuration:

• a) Latitude, longitude
• b) Height of the CBSD, and Height Type (AGL/AMSL)
• c) Antenna azimuth, peak gain, beamwidth of the CBSD
• d) Indoor or outdoor of the CBSD location

3. Receiver configuration:

1.. FSS; for ITM model only (Use default values for weights w1 and w2)

• a) Latitude, longitude, height of the FSS (Lat/long could present a point within an offshore DPA. In that case, antenna height = 50m)

• b) Antenna peak gain, azimuth and elevation of the FSS

• c) Rx Antenna Gain Required; A flag to determine whether the Rx antenna gain is required

• If the flag is set to True, SAS UUT shall send the Rx antenna gain to Admin Test Harness.

• If the flag is set to False, SAS UUT doesn't need to send the Rx antenna gain to Admin Test Harness. 2.. PPA; for Hybrid model only

  • a) PPA boundary containing exactly one protection point 1.. The boundary shall also be small enough that it includes exactly one 1-arcsecond point so that the NLCD value at the location of the protection point is used by the propagation model.

From SAS UUT to Admin Test Harness

1.. Path loss in dB 2.. Tx antenna gain in dBi toward the direction of the receiver 3.. Rx antenna gain in dBi toward the direction of the transmitter

8.2.4 Test Procedure

8.2.4.1 [WINNF.FT.S.PAT.1] Propagation model and antenna gain calculation testing

For clarity, this test is written with a single CBSD and protected entity. The test code shall allow for execution of multiple non-interacting tests as part of a single test run in order to reduce total test execution time. It is recommended to test with a large number of points at one time.

The FSS antenna gain calculated by the SAS UUT shall be no less than the FSS antenna gain calculated by the reference implementation minus 0.2 dB.

If any of the above conditions do not hold for at least 99.9% of trials, the SAS UUT FAILS this test. Otherwise, it PASSES.

8.3 PPA Creation Test

8.3.1 Definition, Applicability, and Scope of the Test Case

This section explains test steps, conditions, and procedures for successful execution and completion of the PPA Creation test.

8.3.2 Test Characteristics

Table 8.3-1 PPA Creation Test Characteristics

8.3.3 Method of test

8.3.3.1 Initial Conditions / Test Pre-conditions

According to [n.12, R2-PAL-05], the area of the non-overlapping difference between the maximum PPA boundary created by SAS UUT shall be no more than 10% of the area of the maximum PPA boundary created by the Reference Model.

Figure 8.3-1 Overlap of maximum PPA Boundaries created by SAS UUT and the Reference Model

In Figure 8.3-1, the zone denoted by PPAREF is the maximum boundary generated by the Reference Model, the zone denoted by PPASAS is the maximum boundary generated by the SAS UUT, and the zone denoted by PPAREF ∩ PPASAS is the overlap between the two areas PPAREF and PPASAS. Moreover, the area of a zone Z is denoted by a(Z). To test the capability of SAS UUT to fulfil [n.12, R2-PAL-05], the following criterion is checked:

$$a(PPA_{REF} \cup PPA_{SAS}) - a(PPA_{REF} \cap PPA_{SAS}) < 0.1 \times a(PPA_{REF})$$

Equation 8.3-1

Figure 8.3-2 depicts the maximum PPA boundary generated by the Reference Model (PPAREF), the maximum PPA boundary generated by the SAS UUT (PPASAS), and different choices for the PPA boundary claimed by the PAL holder (denoted as A, B, C, D, E, F, G, and H).

Image /page/136/Picture/8 description: The image shows a diagram with several labeled shapes. There are two overlapping circles, one gray and one outlined in red. The gray circle is labeled "PPASAS" with a light blue arrow pointing to it. The red circle is labeled "PPAREF" with a brown arrow pointing to it. Inside and outside of the circles are several blue shapes labeled with letters. The shapes are labeled A, B, C, D, E, F, G, and H.

Figure 8.3-2 maximum PPA Boundaries created by SAS UUT, the Reference Model, and proposed by the PAL holder

According to [n.12, R1-SPU-01], the managing SAS shall approve the claimed boundary if it is fully contained within the maximum PPA boundary generated by the SAS UUT. Therefore, the claimed boundaries B, C, and D shall be rejected by the SAS UUT. Moreover, assuming all CBSDs within cluster list are owned by the PAL holder with valid userId, the PPA boundary A shall be approved by the SAS UUT. To address other boundaries (E, F, G, and H), the Main Test Harness shall be able to take as input the PAL holder claimed boundary, and provide it as an input to SAS UUT. The PAL claimed area shall be compared with the maximum PPA boundary generated by the SAS UUT (PPASAS). In the test cases PCR.3 and PCR.6 below, the input to the test case must be generated by first running the prerequisite test case (PCR.1), manually creating the PAL holder claimed boundary, and then combining that with the input to the prerequisite test case (i.e. using the same CBSD deployment, PAL records, etc).

In this Section, a PAL service area might contain one or more census tracts that use are licensed with the same frequency assignments.

8.3.3.2 Test Tools Required

• PPA Creation Reference Model for the creation of a PPA. This Reference Model takes in a list of CBSD-IDs and an optional area description and returns a PPA-ID upon success and an error upon failure.
• A test API supported by the SAS UUT, so that the Admin Test Harness can trigger the creation of a PPA by SAS UUT.
• The test API method has two variants exercised by the test: first, creation of a PPA depending only on a specific set of CBSDs, and second, the creation of a PPA given a specific set of CBSDs and a claimed PPA boundary by the PAL holder enclosing those CBSDs.
• The inputs to the PPA creation method are as follows:
  • List of CBSD IDs
  • List of PAL IDs
  • (optional) Provided contour The SAS UUT must implement the API to return a valid PPA-ID when the PPA creation succeeds, and an error when it fails.
• A mechanism of injecting the PAL Database records into the SAS UUT.

8.3.4 Test Procedure

8.3.4.1 [WINNF.FT.S.PCR.1] Successful Maximum PPA Creation

The tests in this section verify that a SAS can correctly create a maximum PPA boundary given a set of CBSDs.

8.3.4.2 [WINNF.FT.S.PCR.2] Successful Maximum PPA Boundary Creation Clipped by Service Area Boundary

This test verifies that a SAS can create the maximum PPA boundary, being clipped by the Service Area composed of one or more adjacent Census Tracts. The CBSD locations shall be configured in a way that at least one of the CBSDs is close to the boundary of the Service Area, so that its −96 dBm/10 MHz protection contour extends beyond the service area boundary

8.3.4.3 [WINNF.FT.S.PCR.3] Successful PPA Confirmation with Claimed Boundary by PAL Holder

This test verifies that a SAS UUT shall confirm a valid PPA boundary claimed by the PAL holder, composed of one or more adjacent Census Tracts, and the claimed area is fully contained within the maximum boundary created by the SAS UUT.

To create the configuration for this test case, first execute PCR.1 and note the maximum PPA boundary generated by the SAS UUT. Use that boundary to create the PAL holder claimed contour provided in this test case. All other inputs must be identical to those used in the corresponding configuration of PCR.1.

8.3.4.4 [WINNF.FT.S.PCR.4] Unsuccessful PPA Creation with one or more CBSDs Outside Service Area

This test verifies that a SAS UUT rejects creation of a PPA boundary if at least one of the CBSDs included in the CBSD cluster list is located outside PAL holder service area, which is composed of one or more adjacent Census Tracts.

8.3.4.5 [WINNF.FT.S.PCR.5] Unsuccessful PPA Creation with one or more CBSDs not belonging to the PAL Holder

This test verifies that a SAS UUT rejects creation of a PPA boundary if at least one of the CBSDs included in the CBSD cluster list does not belong to the PAL holder.

8.3.4.6 [WINNF.FT.S.PCR.6] Unsuccessful PPA boundary Claimed by PAL Holder Not contained within Maximum PPA Boundary

This test verifies that a SAS UUT shall reject a PPA boundary claimed by the PAL holder, that is not fully contained within the maximum PPA boundary created by SAS UUT.

To create the configuration for this test case, first execute PCR.1 and note the maximum PPA boundary generated by the SAS UUT. Use that boundary to create the boundary for the PPA which is injected in this test case. All other inputs must be identical to those used in the corresponding configuration of PCR.1.

8.3.4.7 [WINNF.FT.S.PCR.7] Overlapping PPA Boundaries

This test verifies that the SAS UUT does not create or confirm PPAs with overlapping zones for the same frequency range.

To create the configuration for this test case, first execute PCR.1 and note the maximum PPA boundary generated by the SAS UUT. Use that boundary to create the PAL holder claimed contour provided in this test case. All other inputs must be identical to those used in the corresponding configuration of PCR.1.

8.4 Aggregate Interference Protection – Single Protected Entity

8.4.1 Definition, Applicability, and Scope of the Test

This section outlines a template for test steps, conditions, and procedures for SAS to authorize CBSDs to transmit only when they do not interfere with a protected entity X. The scope of this test is to verify that the SAS continuously maintains aggregate interference below the protected entity's protection threshold, whether it is calculated at the location of the protected entity, or on grid points within a pre-defined protection area. This section only provides the template for test cases that will be referenced in subsequent sections per the protected entity type.

8.4.2 Test Characteristics

Table 8.4-1 Aggregate Interference Protection

8.4.3 Method of test

8.4.3.1 Initial Conditions / Test Pre-conditions

No more than one protected entity type is present at a time.

8.4.3.2 Test Tools Required

• Main Test Harness
• Ability to compute pathloss propagation using the ITM and hybrid propagation Reference Models and the CBSD antenna pattern Reference Model, and to compute aggregate interference at the location of the protected entity or each grid point inside the protection area of the protected entity or each grid point inside the protection area of the protected entity, using the WG4 Aggregate Interference Reference Model, as specified for protected entity X in [n.12].
  • Ability to simulate IAP with a set of active Grants using IAP Reference Model.
• SAS Test Harness(es) hosts a configurable group of Grants with CBSD locations inside and outside the neighborhood of protected entity requiring protection. The protected entity is injected by the Admin Test Harness with configurable operating parameters.
  • The necessary data in order to protect the protected entity, are exchanged with SAS UUT through a Full Activity Dump exchange. This exchange is necessary to inform SAS UUT about Authorized or Granted CBSD Grants belonging to SAS Test Harness(es).

8.4.3.3 Protected entity types and their Parameters

The following Table lists the protected entities for which IAP is applied along with their associated parameters.

For this table, please note the following:

1- In this table, the reference bandwidth (RBW), and protection threshold per the reference bandwidth for each protection entity (Th), as identified by Part 96 [n.1, 2] and in [n.12] for ESC sensors, are included. Moreover, the channel bandwidth over which SASs execute the IAP process is denoted as IAPBW. The protection threshold per IAPBW (Q) is then calculated by scaling Th for IAPBW, using the equation

$$Q = Th + 10 * \log \left{ \frac{IAPBW}{RBW} \right}$$

Equation 8.4-1

2.- In this section, Fi denotes the operating frequency of a CBSD's Grant, while Fp denotes the protected channel range of the protected entity. 3.- In this section, the actual protection threshold used for IAP is calculated by applying a predefined Pre-IAP Headroom (Mg) [n.21] at each protection threshold. The actual IAP

protection level for the protected entity = Q - Mg. A unique value of Mg is applied consistently among all SASs for each type of protected entities. Assuming the number of SASs in a peer group is $N_{SAS}$ , the allowed headroom for SAS UUT is:

$$I = 10 * log \left{ \frac{10^{\frac{Q}{10}} 1.0^{\frac{Q-Mg}{10}}}{N_{SAS}} \right}$$

Equation 8.4-2

Table 8.4-2 Protected entity reference for IAP Protection

8.4.4 Test Procedure

8.4.4.1 [WINNF.FT.S.xPR.1] Grants from Multiple CBSDs Inside and Outside the Neighborhood (Y) of a Protected Entity (X).

Execute Steps 3 through [End] of MCP.1 with the following values:

• No DPAs activated or deactivated
• K = 1
• NS = 0
• , contains a single protected entity (one PPA, GWPZ, FSS, or ESC sensor)

8.4.4.2 [WINNF.FT.S.xPR.2] Multiple CBSDs from Multiple SASs Inside and Outside the Neighborhood of the Protected Entity

Multiple CBSDs, registered with multiple SASs, located inside and outside the neighborhood (Y) of the protected entity X, request Grants for independent frequency Fi that overlaps with Fp

Execute Steps 3 through [End] of MCP.1 with the following values:

• K = 1
• NS ≥ 1
• , contains a single protected entity (one PPA, GWPZ, FSS, or ESC sensor)

8.5 ESC Protection

8.5.1 Definition, Applicability, and Scope of the Test Case

This section explains test steps, conditions, and procedures for SAS to grant CBSDs only when they do not interfere with its hosted ESC sensors. The scope of this test is to verify that the SAS continuously maintains aggregate interference below the ESC sensors' protection threshold. In addition, a test case is included to verify ESC sensor protection when multiple SASs are present. ESC sensors in all cases are active.

8.5.2 Test Characteristics

Table 8.5-1 ESC Protection

8.5.3 Method of test

8.5.3.1 Initial Conditions / Test Pre-conditions

• SAS Test Harness hosts a configurable group of active or suspended Grants with CBSD locations within and outside the 40km and 80km radius of the Sensor location. Admin Test Harness provides Sensor locations, frequency, ESC antenna pattern, and all the required operating parameters to the SAS UUT.
  • The protection threshold of -109dBm per MHz as referenced in [n.12] is used. This reference also pre-defines a 10dB/10MHz roll-off margin for Out-Of-Band CBSDs (3650-3660 MHz for Cat A, and 3650-3680MHz for Cat B.
  • ESC IAP Protection test cases are performed both for In-Band (3550-3650 MHz) CBSDs, as well as Out-of-Band CAT A CBSDs in 3650-3660 MHz and CAT B CBSDs in 3650-3680 MHz.

8.5.3.2 Test Tools Required

• Main Test Harness
  • Ability of Aggregate Interference Reference Model and IAP Reference Model to calculate the received in-band and out-of-band interference energy based on the ESC reference receiver filter and the ESC antenna pattern.

8.5.4 Test Procedure

8.5.4.1 [WINNF.FT.S.EPR.1] Single SAS ESC Sensor Protection

Perform WINFF.FT.S.xPR.1 for X= ESC sensor, Table 8.4-2 with configurable Fi

8.5.4.2 [WINNF.FT.S.EPR.2] Multiple SAS ESC Sensor Protection

Perform WINNF.FT.S.xPR.2 for X= ESC sensor, Table 8.4-2 with configurable Fi

8.6 PPA Protection

8.6.1 Definition, Applicability, and Scope of the Test Case

The purpose of this test case is to test the SAS UUT can protect one or more pre-defined PPA zones (according to R2-SGN-12 & R2-PAL-01 in [n.12]), in a protection level of 8.0dBm/10MHz on at least 95% of the points.

The aggregate interference comparisons are performed for all grid points inside and on the PPA boundary, and the SAS UUT passes these test cases if the comparisons are successful for at least 95% of the points inside and on the PPA boundary.

The test case is considering CBSDs operating co-channel with the PPA to be protected.

8.6.2 Test Characteristics

Table 8.6-1 PPA Protection

8.6.3 Method of test

8.6.3.1 Initial Conditions / Test Pre-conditions

The parameter has the following constraints: A 10 MHz PPA is used; the PPA can be associated with one or multiple PAL licenses whose assigned physical channels are on the following range: 3550-3650 MHz.

The location of the protected entity in the PPA Protection test case is equivalent to every grid point within the PPA contour. Therefore, the Aggregate Interference should be below the protection threshold Th-Mg for at least 95% of grid points inside the PPA boundary. For a grid point to be considered protected, the aggregate interference must be below the protection threshold for all frequencies at that point.

8.6.3.2 Test Tools Required

• Admin Test Harness
  • Ability to inject PPA Information through Admin Test Harness
• Main Test Harness
  • Ability to compute pathloss propagation using the ITM and hybrid propagation Reference Models and the CBSD antenna pattern Reference Model, and to compute aggregate resulting interference level on every protection point within the neighborhood of a protected entity using the WG4 Aggregate Interference Reference Model.

8.6.4 Test Procedure

8.6.4.1 [WINNF.FT.S.PPR.1] Single SAS PPA Protection

Perform WINNF.FT.S.xPR.1 for X= PPA, Table 8.4-2 with configurable Fi

8.6.4.2 [WINNF.FT.S.PPR.2] Multiple SAS PPA Protection

Perform WINNF.FT.S.xPR.2 for X= PPA, Table 8.4-2 with configurable Fi

8.6.4.3 [WINNF.FT.S.PPR.3] Protection of PPA managed by peer SAS

8.7 GWPZ Protection

8.7.1 Definition, Applicability, and Scope of the Test Case

The purpose of this test case is to verify the SAS UUT can protect one or more pre-defined GWPZ (GWBL Protection areas, according to R2-SGN-12, R0-IPM-02) with a protection threshold of -80dBm/10MHz with at least 95% coverage of the GWPZ.

The aggregate interference comparisons are performed for all grid points inside and on the GWPZ boundary, and the SAS UUT passes these test cases if the comparisons are successful for at least 95% of the points inside and on the GWPZ boundary.

8.7.2 Test Characteristics

Table 8.7-1 GWPZ Protection

8.7.3 Method of test

8.7.3.1 Initial Conditions / Test Pre-conditions

The parameter has the following constraints: A 25-50MHz GWPZ is used; the GWPZ can be associated with one or multiple GWBLs whose assigned physical channels are on the following range: [3650-3675 MHz], [3675-3700MHz], or [3650-3700MHz].

The location of the protected entity in the GWPZ Protection test case is equivalent to every grid point within the GWPZ contour. Therefore, the Aggregate Interference should be below the protection threshold Th-Mg for at least 95% of grid points inside the GWPZ boundary. For a grid point to be considered protected, the aggregate interference must be below the protection threshold for all frequencies at that point.

8.7.3.2 Test Tools Required

• Admin Test Harness
  • Ability to inject GWPZ through Admin Test Harness
• Main Test Harness
  • Ability to compute pathloss propagation using the ITM and hybrid propagation Reference Models and the CBSD antenna pattern Reference Model, and to compute aggregate resulting interference level on every protection point within the neighborhood of a protected entity using Aggregate Interference Reference Model.

8.7.4 Test Procedure

8.7.4.1 [WINNF.FT.S.GPR.1] Single SAS GWPZ Protection

Perform WINNF.FT.S.xPR.1 for X= GWPZ 25 or GWPZ 50, Table 8.4-2 with configurable Fi

8.7.4.2 [WINNF.FT.S.GPR.2] Multiple SAS GWPZ Protection

Perform WINNF.FT.S.xPR.2 for X= GWPZ 25 or GWPZ 50, Table 8.4-2 with configurable Fi

8.7.4.3 [WINNF.FT.S.GPR.3] GWPZ Exclusion Zone

One or more CBSDs, located inside a GWPZ, request Grants and are rejected

8.8 FSS Protection

8.8.1 Definition, Applicability, and Scope of the Test Case

This section explains test steps, conditions, and procedures for SAS to grant CBSDs to protect FSS earth station. The scope of this section is to verify that SAS would not authorize CBSD Grants when they interfere with FSS. In addition, test cases are included to verify FSS protection when multiple SASs are present. It is assumed that all the necessary information regarding FSS sites are available and can be injected to the SAS UUT through Admin Test Harness.

8.8.2 Test Characteristics

Table 8.8-1 FSS Protection

8.8.3 Method of test

8.8.3.1 Initial Conditions / Test Pre-conditions

• The Pre-IAP Headroom Margin for FSS TT&C and in-band is denoted as MgBlocking (dB).
• The Pre-IAP Headroom Margin for in-band FSS is denoted as MgCoChannel (dB).

The Headroom Margin for FSS out of band emission is denoted as MgOOBE (dB).

8.8.3.2 Test Tools Required

Main Test Harness configures and uses the following test tools in the test cases specified in this section.

• Propagation model Reference Model
• Aggregate Interference Reference Model
  • Antenna Gain Reference Model to simulate FSS receive antenna characteristics, and CBSD antenna including antenna gain toward the side lobes of the FSS
• FSS earth station receive antenna Reference Model (R2-SGN-21)
• IAP Reference Model
• FSS Purge List Reference Model
• Admin Test Harness
• SAS Test Harness
• DP Test Harness
• Ability of Aggregate Interference Reference Model and IAP Reference Model and Purge List Reference Model to calculate the received in-band and out-of-band emission and blocking interference energy based on the FSS reference receiver filter.

SAS Test Harness hosts a configurable group of active or suspended Grants with CBSD locations inside or outside the Protection area of the FSS

8.8.3.3 FSS filter for Blocking Protection

Figure 8.8-1, Figure 8.8-2, and Figure 8.8-3 depict the FSS receive filter mask for three different scenarios of FSS registered passbands.

Figure 8.8-1, referred to as "FSS Scenario 1", depicts a common FSS passband that starts below 3700 MHz (e.g. 3625 MHz), and extends to 4200 MHz. In this case, the portion of FSS passband the lies below 3700 MHz shall be protected from all co-channel CBRS CBSDs (in this figure, CBSD5, CBSD6, and a portion of CBSD4 Grant that is above 1). Moreover, the FSS station shall be protected from blocking effects of all CBSDs with Grants outside FSS passband (in this figure, CBSD1, CBSD2, CBSD3, and a portion of CBSD4 Grant that is below 1). Moreover, if and only if the TT&C flag is set for this FSS station, the portion of FSS passband starting from 3700 MHz extending to 4200 MHz is protected against Out Of Band Emissions (OOBE) effects of all CBRS CBSDs. For TT&C Flag refer to [n.22]. The protection methodology in this scenario applies also if the registered upper frequency is greater than 3700 MHz and no more than 4200 MHz.

Figure 8.8-2, referred to as "FSS Scenario 2", depicts an FSS passband that starts from 3700 MHz and extends to 4200 MHz. In this case, if the TT&C flag is set to ON, the FSS passband is protected against both blocking effect and OOBE from all CBRS CBSDs.

For identifying the aggregate blocking effect, the CBSD Grants that are overlapping with FSS passband are not used. The protection methodology in this scenario applies also if the registered upper frequency is greater than 3700 MHz and no more than 4200 MHz.

Figure 8.8-3, referred to as "FSS Scenario 3", depicts a common FSS passband that starts below 3700 MHz (e.g. 3625 MHz), and extends to 3700 MHz. The protection methodology in this scenario is similar to "FSS Scenario 1", with one difference. In this case, the FSS OOBE protection is not applied regardless of the value of TT&C Flag. The protection methodology in this scenario applies also if the registered upper frequency is below 3700 MHz.

$$I_{aggr}= 10log_{10} \left{ E \left[ \sum_{i=1}^{N_{Grant}} \frac{1}{PL_i} \times 10^{\left(\frac{G_{FSS_i}}{10}\right)} \right] \times \sum_{f=f_{i1}}^{f_{i2}} 10^{\left(\frac{EIRP_i(f)}{10}\right)} \times 10^{\left(\frac{mask(f)}{10}\right)} \times \Delta f \right} (dBm)$$ The portion of grants not overlapping with FSS passband

Equation 8.8-1

where:

• $I_{aggr}$ is the aggregate blocking effect from all CBSDs (dBm)
• $N_{Grant}$ is the number of CBSD Grants in the band that are within the neighborhood protection of FSS station for blocking protection.
• $EIRP_i(f)$ is the power spectral density of $i^{th}$ CBSD (dBm/MHz) toward FSS earth station at frequency f(MHz)
• mask(f) is the FSS receiver filter characteristics as the function of frequency f(MHz)
• $PL_i$ is the mean linear path loss from the $i^{th}$ CBSD to the location of FSS station
• $G_{FSS_i}$ is the FSS Rx antenna gain toward the $i^{th}$ CBSD (dB), and
• $E[\cdot]$ stands for the mean calculation
• $\Delta f$ is the frequency step size in Equation 8.8-1, and is set to 1 MHz in this specification.
• Use Linear Model for EIRP

fi1: Lower edge of CBSDi's bandwidth

fi2: Upper edge of CBSD;’s bandwidth

fP1: Lower edge of FSS' s passband

fP2: Upper edge of FSS' s passband

Figure 8.8-1 Mask Function for FSS Blocking – FSS Scenario 1: Passband starting below 3700 extending to 4200 MHz

• $f*{i1}*$ : Lower edge of $CBSDi$ ’s bandwidth
• $f*{i2}*$ : Upper edge of $CBSDi$ ’s bandwidth

fP1: Lower edge of FSS’s passband

fP2: Upper edge of FSS’s passband

Figure 8.8-2 Mask Function for FSS Blocking – FSS Scenario 2: Passband from 3700-4200 MHz

Figure 8.8-3 Mask Function for FSS Blocking – FSS Scenario 3: Passband starting Below 3700 and extending to 3700 MHz

In this section, the actual protection threshold used for IAP and FSS Purge Calculations is calculated by applying a pre-defined Pre-IAP or pre-Purge List Headroom (Mg) [n.21] at each FSS protection threshold. The actual IAP protection level or Purge list threshold for the FSS station is Q-Mg. A unique value of Mg is applied consistently among all SASs for co-channel, blocking, or OOBE protection. Equation 8.4-2 is used to calculate the allowed headroom for SAS UUT.

8.8.3.4 FSS Protection Criteria

The full passband of FSS station is denoted as , while the portion (if any) below 3700MHz is denoted as ℎ, and the portion above 3700MHz is denoted as FTTC. In normal operation, FFSS is derived from the lower frequency and upper frequency information obtained from FSS database.

To protect an FSS entity, and depending on FSS scenario depicted in Figure 8.8-1 and Figure 8.8-2, and the status of TT&C Flag, a combination of the following three criteria shall be satisfied:

• Blocking Protection
• Co-Channel Protection
• Out of Band Emission

8.8.3.4.1 Blocking protection

To test the SAS UUT ability to protect FSS stations from blocking interference, the following steps shall be performed:

1. Calculate B, the mean aggregate blocking interference to the FSS station. To calculate the aggregate blocking interference, the Main Test Harness uses
2. Equation 8.8-1 applied to the following Grants with any frequency assignment in 3550-3700 MHz:

• a. All authorized Grants managed by the SAS UUT for CBSDs that are within 40 km from the FSS station, and,
• b. Exclude the portion of Grants that overlaps with $F_{CoChannel}$ , and
• c. No out of band emissions of CBSDs are considered in this calculation.

3. Calculate Bref, the mean aggregate blocking interference obtained from the IAP Reference Model. To calculate Bref, the Main Test Harness uses
4. Equation 8.8-1 applied to the following Grants with any frequency assignment in 3550-3700 MHz:

• a. All authorized Grants managed by SAS UUT for CBSDs that are within 40 km from the FSS station, and
• b. Exclude the portion of Grants that overlaps with $F_{CoChannel}$ , and
• c. No out of band emissions of a CBSD are considered in this calculation.
• d. Use $Mg_{Blocking}$ for calculating Headroom

The Blocking Protection criterion is satisfied if and only if $B \leq Bref + \Delta_{Blocking}$ .

Note: B and Bref in this section correspond to $A_p^{IAP}$ and $A_p^{IAP,ref}$ in Section 8.10, respectively, when the protected entity is FSS Blocking.

8.8.3.4.2 Co-channel protection

To test the SAS UUT ability to protect FSS stations from co-channel interference, the following steps shall be performed. Note that the FSS station passband insertion loss is 0.5 dB, which increases the co-channel threshold in Table 8.4-2 by this value.

1. Calculate A, the mean aggregate co-channel interference to the FSS station. To calculate the aggregate co-channel interference, the Main Test Harness uses the following Grants with any frequency assignment in 3550-3700 MHz:

• a. All authorized Grants managed by the SAS UUT for CBSDs that are within 150 km from the FSS station, and
• b. Use the portion of Grants that overlaps with $F_{CoChannel}$ , and
• c. No out of band emissions of CBSDs are considered in this calculation, and
• d. Divide $F_{CoChannel}$ , into M channel bandwidths, each with the size of IAPBW; denote each as BWj (j = 1, ..., M).
• e. For each $BW_j$ , calculate the mean aggregate interference $A_j$ , which is the jth element of A:
  • If no Grants overlap with $BW_i$ , skip to j = j + 1.
  • Otherwise, use the Aggregate Interference Reference Model to calculate the aggregate interference of all Grants which partially or fully overlap with $BW_i$ .

2. Calculate Aref, the mean aggregate co-channel interference threshold obtained from the IAP Reference Model. To calculate Aref, the Main Test Harness uses the following Grants with any frequency assignment in 3550-3700 MHz:

• a. All authorized Grants managed by the SAS UUT for CBSDs that are within 150 km from the FSS station, and
• b. Use the portion of Grants that overlaps with $F_{CoChannel}$ , and
• c. No out of band emissions of CBSDs are considered in this calculation, and
• d. For each $BW_j$ , calculate the mean aggregate interference $Aref_j$ which is the jth element of Aref:
  • If no Grants overlap with $BW_j$ , skip to j = j + 1.
  • Otherwise, use the Aggregate Interference Reference Model to calculate the aggregate interference of all Grants which partially or fully overlap with $BW_i$ .
• e. Use MgCoChannel for calculating Headroom.

The co-channel protection criterion is satisfied if and only if $A_j \leq A_{ref,j} + \Delta_{CoChannel}$ for all j.

Note: $A_j$ and $A_{ref,j}$ in this section correspond to $A_p^{IAP}$ and $A_p^{IAP,ref}$ in section 8.10, respectively, when the protected entity is FSS co-channel.

8.8.3.4.3 Out of Band Emission (OOBE) Protection

To test the SAS UUT ability to protect FSS stations from OOBE interference, the following steps shall be performed. Note that the FSS station passband insertion loss is 0.5 dB, which increases the OOBE threshold in Table 8.4-2 by this value.

1. Calculate $A_{OOBE}$ , the mean aggregate OOBE interference to the FSS station. To calculate the aggregate OOBE interference, the Main Test Harness applies [n.12, R2-SGN-29] to the following Grants with any frequency assignment in 3550-3700 MHz:

• a. All authorized Grants managed by the SAS UUT for CBSDs that are within 40 km from the FSS station, and
• b. For CBSDs having multiple Grants, the Grant closest to 3700 MHz is taken into account.
• c. The OOBE aggregate OOBE interference is applied to the frequency segment $BW_1$ starting from 3700 MHz and channel bandwidth of IAPBW.

2. Calculate Aref_OOBE, the mean aggregate OOBE interference threshold obtained from the Purge List Reference Model. To calculate Aref_OOBE, the Main Test Harness applies [n.12, R2-SGN-29] to the following Grants with any frequency assignment in 3550-3700 MHz:

• a. All authorized Grants managed by the SAS UUT for CBSDs that are within 40 km from the FSS station, and

• b. For CBSDs having multiple Grants, the Grant closest to 3700 MHz is taken into account.

• c. The OOBE aggregate OOBE interference is applied to the frequency segment BW₁ starting from 3700 MHz and channel bandwidth of IAPBW.

• d. Use Mgoobe for calculating Headroom.

The OOBE protection criterion is satisfied if and only if $A_{OOBE} \le Aref_{OOBE} + \Delta_{OOBE}$

Note: $A_{OOBE}$ and $A_{POOBE}$ in this section correspond to $A_p^{IAP}$ and $A_p^{IAP,ref}$ , respectively, in section 8.10, when the protected entity is FSS out of band emission.

8.8.3.5 FSS Protection Steps

If "FSS Scenario 1" (Figure 8.8-1) with TT&C Flag = OFF, or "FSS Scenario 3" (Figure 8.8-3), regardless of the value of TT&C Flag, apply Co-Channel Protection (passband below 3700 MHz), and Blocking Protection (at 3550-3700 MHz).

If "FSS Scenario 1" (Figure 8.8-1) and TT&C Flag = ON, apply Co-Channel Protection (passband below 3700 MHz), Blocking Protection (3550-3700 MHz), and OOBE Protection to $F_{TTC}$ . OOBE Protection shall be applied prior to Co-channel Protection and Blocking Protection.

If "FSS Scenario 2" (Figure 8.8-2) and TT&C Flag = OFF, no protection is applied.

If "FSS Scenario 2" (Figure 8.8-2) and TT&C Flag = ON, apply Blocking Protection (at 3550-3700 MHz) and OOBE Protection to $F_{TTC}$ . OOBE Protection shall be applied prior to Blocking Protection.

8.8.4 Test Procedure

8.8.4.1 [WINNF.FT.S.FPR.1] Multiple CBSDs from Multiple SASs Inside and Outside the Neighborhood of an FSS Station for "FSS Scenario 1" with TT&C Flag = OFF, or "FSS Scenario 3" with configurable value for TT&C Flag.

The lower edge of FSS passband is below 3700MHz, and the upper edge of FSS passband is set at 4200MHz.

Perform xPR.2 using "FSS Scenario 1" with TT&C Flag = OFF, or "FSS Scenario 3", regardless of the value of TT&C Flag (refer to Section 8.8.3.5).

8.8.4.2 [WINNF.FT.S.FPR.2] Multiple CBSDs from Multiple SASs Inside and Outside the Neighborhood of an FSS Station for FSS Scenario 1 with TT&C Flag = ON

The lower edge of FSS passband is below 3700MHz, and the upper edge of FSS passband is set at 4200MHz.

Perform xPR.2 using "FSS Scenario 1" with TT&C Flag = ON (refer to Section 8.8.3.5).

8.8.4.3 [WINNF.FT.S.FPR.3] Multiple CBSDs from Multiple SASs Inside and Outside the Neighborhood of an FSS Station for "FSS Scenario 2" with TT&C Flag = OFF

The lower edge of FSS passband is 3700MHz, and the upper edge of FSS passband is set at 4200MHz.

Perform xPR.2 using "FSS Scenario 2" with TT&C Flag = OFF (refer to Section 8.8.3.5).

8.8.4.4 [WINNF.FT.S.FPR.4] Multiple CBSDs from Multiple SASs Inside and Outside the Neighborhood of an FSS Station for "FSS Scenario 2" with TT&C Flag = ON

The lower edge of FSS passband is 3700MHz, and the upper edge of FSS passband is set at 4200MHz.

Perform xPR.2 using "FSS Scenario 2" with TT&C Flag = ON (refer to Section 8.8.3.5).

8.8.4.5 [WINNF.FT.S.FPR.5] Grant Requests from one or more CBSDs Inside an FSS-GWBL Exclusion Zone

One or more CBSDs, located inside the 150km of the FSS site with presence of a GWBL in that area, request a Grant but are rejected. In this test case, it is assumed that there is no coordination among FSS user, GWBL user, and CBSD user to allow operation of CBSD within FSS-GWBL Exclusion zone. Such coordination agreement reported to SAS manually offline, may overrule this test case.

8.9 Federal Incumbent Protection

8.9.1 Definition, Applicability, and Scope of the Test Case

This test verifies that the SAS as the unit under test (UUT) meets established criteria for the protection of federal incumbent dynamic protection areas (DPAs). It tests the response of the SAS UUT to new Grant Requests, as well as the ability of the SAS UUT to manage the aggregate interference of existing authorized CBSD Grants when DPAs are activated. It also tests the response of the SAS UUT to loss of connectivity with the ESC.

8.9.2 Test Characteristics

Table 8.9-1 Federal Incumbent Protection

8.9.3 Method of test

8.9.3.1 Initial Conditions / Test Pre-conditions

• The SAS UUT is active and able to receive messages from the CBSD, SAS, and ESC Test Harnesses.
  • The ESC Test Harness is associated with all DPAs. The ESC Test Harness provides the ability to arbitrarily activate/deactivate DPAs.

8.9.3.2 Test Tools Required

• ESC Test Harness
  • Representing a single ESC system
  • Capable of communicating the activation of one or more DPAs and the affected channels of each activated DPA
  • With support as needed by the SAS UUT to detect loss of connectivity with the ESC Test Harness
• DPA Reference Move List Model
  • To pre-calculate the reference move list for a DPA on a frequency range, the Main Test Harness shall follow the procedure in [n.12, R2-SGN-24]. This calculation shall assume that a CBSD with an approved Grant (i.e., in the Granted or Authorized state) emits with the maximum EIRP permitted by the Grant

(maxEirp parameter in the Grant Request). The reference move list shall account for the uncertainty in the output of the reference move list model.

• Aggregate Interference Model
• SAS Test Harness
  • To create Grant configurations in the SAS Test Harness that achieve desired aggregate interference conditions, these Grants can be run through the Aggregate Interference Reference Model prior to the test to ensure they meet those conditions.
• DP Test Harness

8.9.4 Test Procedure

8.9.4.1 [WINNF.FT.S.IPR.1] In the absence of an ESC, SAS protects all ESC-monitored DPAs.3

This test does not use the ESC Test Harness. In the absence of an ESC, SAS UUT is expected to protect all ESC-monitored DPAs. In the PASS/FAIL criteria of this and following tests, ∆ is an aggregate interference uncertainty margin (dB) whose value shall be configured to be commensurate with the 95% confidence interval of the aggregate interference calculation. To reduce execution time, it is recommended to use a small number of CBSDs which are in the neighborhood of a small number of DPAs.

3 "ESC-monitored DPAs" include offshore (or coastal) DPAs as well as ground-based radar and in-port inland DPAs which are ESC-monitored in 3550-3650 MHz and always active in 3500-3550 MHz

8.9.4.2 [WINNF.FT.S.IPR.2] Activation of Multiple Offshore DPAs

In this test case, SAS UUT is expected to manage the Grants of CBSDs after DPAs are activated to meet their protection criteria. In the following, $(D_i, C_j)$ is a DPA/channel pair, where $D_i$ is a DPA ID, and $C_j$ is a CBRS channel in 3550 MHz to 3650 MHz that must be protected in DPA $D_i$ . Let DPA $D_{i+1}$ be adjacent to DPA $D_i$ , and let DPA $D_k$ be non-adjacent to DPAs $D_i$ and $D_{i+1}$ . Let $C_i$ be a second CBRS channel in 3550 MHz to 3650 MHz different from $C_j$ . In Steps 13, 16, and

19 below, is a configurable duration (seconds) to pause between DPA activations, but shall not exceed grantExpireTime provided by SAS UUT.

8.9.4.3 [WINNF.FT.S.IPR.3] CBSD Grant Request in the Neighborhood of an Activated Offshore DPA.

In this test case, SAS UUT is expected not to authorize Grant Requests from CBSDs in the neighborhood of a protection constraint of an active offshore co-channel DPA made prior to the

next move-list computation (i.e. CPAS). In the following, is the ID of an offshore DPA, and is a CBRS channel in 3550 MHz to 3650 MHz.

8.9.4.4 [WINNF.FT.S.IPR.4] CBSD Grant Request in the Neighborhood of an Activated Inland DPA.

In this test case, SAS UUT is expected to not authorize Grant Requests from CBSDs in the neighborhood of a protection constraint of an active inland DPA made prior to the next move-list computation (i.e. CPAS). In the following, is the ID of an inland DPA, and is a channel in 3500 MHz to 3650 MHz.

If any of the above conditions are not met, the SAS UUT FAILS this test. Otherwise, it PASSES.

8.9.4.5 [WINNF.FT.S.IPR.5] CBSD Grant Requests in the Neighborhood of Inactive DPAs followed by DPA Activation

In this test case, CBSDs in the neighborhood of a protection constraint of an inactive DPA request Grants after the most recent move-list computation by the SAS. After the DPA is activated, the SAS suspends or terminates the Grants, if approved. In the following, is the ID of a DPA, and is a CBRS channel in 3550 MHz to 3650 MHz.

8.9.4.6 [WINNF.FT.S.IPR.6] Broken Connectivity between the SAS UUT and ESC Monitoring DPAs on all channels

In this test case, SAS UUT is expected to manage the Grants of CBSDs after losing connectivity with the ESC to meet the protection criteria of all ESC-monitored DPAs on all channels. To reduce execution time, it is recommended to use a small number of CBSDs which are in the neighborhood of a small number of DPAs.

8.9.4.7 [WINNF.FT.S.IPR.7] Activation of a Single DPA

In this test case, SAS UUT is expected to manage the Grants of CBSDs after a DPA is activated to meet its protection criteria. In the following, ( , ) is a DPA/channel pair, where is the DPA ID of an ESC-monitored DPA or a portal-controlled DPA, and is a channel in 3500 MHz to 3650 MHz that must be protected in DPA .

8.10 Incumbent Protection – Multi Constraint Protection (MCP)

8.10.1 Definition, Applicability, and Scope of the Test Case

This test verifies that the SAS as the unit under test (UUT) meets established criteria for interference protection with multiple constraints, including FSS, GWPZ, PPA, ESC sensor, and DPA. It tests the response of the SAS UUT to Grant Requests subject to one or more of these constraints.

8.10.2 Test Characteristics

Table 8.10-1 Multiple Constraint Protection Test Characteristics

8.10.3 Method of test

8.10.3.1 Initial Conditions / Test Pre-conditions

The SAS UUT is active and able to receive messages from the CBSD, SAS, and ESC Test Harnesses.

o The ESC Test Harness is associated with all DPAs. The ESC Test Harness provides the ability to arbitrarily activate/deactivate DPAs.

8.10.3.2 Test Tools Required

• ESC Test Harness
  • Representing a single ESC system
  • Capable of communicating the activation of one or more DPAs and the affected channels of each activated DPA
  • Appropriate configuration/logging tool for this test
• DPA Reference Move List Model
  • To pre-calculate the reference move list for a DPA on a frequency range, the Main Test Harness shall follow the procedure in [n.12, R2-SGN-24]. This calculation shall assume that a CBSD with an approved Grant (i.e., in the Granted or Authorized state) emits with the maximum EIRP permitted by the Grant (maxEirp parameter in the Grant Request). The reference move list shall account for the uncertainty in the output of the reference move list model.
• Aggregate Interference Model
• IAP Reference Model
• SAS Test Harness
  • To ensure the validity of CBSD and Grant configurations in the SAS Test Harness for a given set of protection constraints, these Grants can be run through the IAP Reference Model prior to the test to ensure they can be satisfied at their requested power levels.
• DP Test Harness

8.10.4 Test Procedure

8.10.4.1 [WINNF.FT.S.MCP.1] SAS manages a mix of GAA and PAL Grants in 3550 MHz to 3700 MHz to protect configurable IAP-protected entities and DPAs.

Figure below depicts the test execution steps at a high level.

Figure 8.10-1 Overview of test execution steps

In the following, ∆ and ∆ shall be configured to be commensurate with the 95% confidence intervals of the respective aggregate interference calculations.

Delta IAP, ∆ , is the maximum allowable margin by which a SAS UUT aggregated interference, , must be bounded from the aggregate interference, , , computed by the reference Implementation, to pass any IAP related test. Commensurate with PAT.1 test case, Delta IAP, ∆ , will be 1dB.

8.11 SAS Federal Government Database Update

8.11.1 Definition, Applicability, and Scope of the Test Case

This section explains test steps, conditions, and procedures for successful execution and completion of the SAS operation to access external database managed by Federal Government, pull the data, and to update its database accordingly.

8.11.2 Test Characteristics

Table 8.11-1 Federal Government Database Update Test Characteristics

8.11.3 Method of test

8.11.3.1 Initial Conditions / Test Pre-conditions

8.11.3.1.1 The preconditions for Exclusion Zone Database Update:

• Exclusion Zone Database is available on the designated database (such as GitHub) and the SAS is able to retrieve the data from the designated Database.
• The SAS Administrator must provide adequate time to update/synchronize the SAS UUT with exclusion zone database.
  • a) Updating and implementing database on the SAS database may take some time.
  • b) Updating database may impact IAP calculation. Test Engineer should work with the SAS administrator and inquire about the time necessary for the database verification to complete.
  • c) This time can be an input to test case execution pause/wait time.
  • d) SAS Administrator will provide a means to identify when the database update/synchronization is completed
  • e) All the preconditions of Exclusion Zone test case when Exclusion Zone test case is executed, see Section 8.1

8.11.3.1.2 The preconditions for DPA Database Update:

• The DPA Database should be available in the designated database and the SAS is able to retrieve the data from the designated database.
• SAS Administrator will provide a means to identify when the database update/synchronization is completed.
  • a) Updating and implementing database on the SAS Database may take some time.
  • b) Updating database may impact the DPA move list update. The Test Engineer should work with the SAS administrator and inquire about the time to wait until Database verification should be executed.
  • c) This time can be an input to test case.
  • d) All the preconditions of the Federal Incumbent Protection test case when the Federal Incumbent Protection test is executed, is applicable here. See Section 8.9.

The Field/Format will be added when FCC releases the DPA database.

8.11.3.1.3 Pre-conditions for FSS Database Update

• FSS Database should be available in the designated database (such as GitHub) and the SAS is able to retrieve the data from the designated database.
• The SAS Administrator should provide the time it takes to update/synchronize its database with the FSS Data.
  • a) Updating and implementing database on the SAS Database may take some time.
  • b) Updating database may impact IAP calculation. Test Engineer should work with the SAS administrator and inquire about the time to wait until Database verification should be executed.
  • c) This time can be an input to test case.
  • d) All the pre-conditions of FSS IAP test case when FSS test case is executed, see Section 8.8.

The information that the SAS needs in order to be able to adequately protect FSS sites from CBDSs is available from FCC FSS database [n.18].

8.11.3.1.4 The preconditions for GWBL Database Update:

• GWBL Database should be available on the designated database (such as GitHub) and the SAS be able to retrieve the data from the designated database.
• The SAS Administrator should provide the time it takes to update/synchronize its database with the GWBL Data.
  • a) Updating and implementing database on the SAS Database may take some time.
  • b) Updating database may impact IAP calculation. Test Engineer should work with the SAS administrator and inquire about the time to wait until Database verification should be executed.
  • c) This time can be an input to test case.
  • d) All the preconditions of GWPZ IAP test case when GWPZ test case is executed, see Section 8.7.

The information that the SAS needs in order to be able to adequately protect GWPZ from CBDSs is available from FCC GWBL and GWPZ database [n.19-20].

8.11.3.1.5 The preconditions for FCC ID Database Update:

• The SAS does not need to access any dummy database for CBSD FCC ID. The SAS can access FCC CBSD database and access an existing FCC ID.

  • a) FCC will provide part 96 FCC test ID which will be posted on FCC database.
  • b) These are test IDs generated for the purpose of testing
  • c) The SAS will be instructed to remove the existing FCC ID at the beginning of the testing.

• The SAS Administrator should provide the time it takes to update/synchronize its database with FCC CBSD ID Data.

• a) Updating and implementing database on the SAS Database may take some time.

• b) This time should be an input to test case.

CBSD FCC ID verification is part of CBSD Registration Test case. For all the preconditions of CBSD Registration test case, see Section 6

8.11.4 Test Procedure

8.11.4.1 [WINNF.FT.S.FDB.1] Exclusion Zone Database Update

8.11.4.2 [WINNF.FT.S.FDB.2] DPA Database Update for DPAs which cannot be monitored by an ESC

8.11.4.3 [WINNF.FT.S.FDB.3] FSS Database Update: Adding an FSS Site

For clarity, this test is written with a single CBSD and protected entity. The test code shall allow for parallel execution of non-interacting tests in order to reduce total test execution time.

8.11.4.4 [WINNF.FT.S.FDB.4] FSS Database Update: FSS Site Modification

8.11.4.5 [WINNF.FT.S.FDB.5] GWBL Database Update: Adding a GWBL

For clarity, this test is written with a single CBSD, FSS, and GWBL. The test code shall allow for parallel execution of non-interacting tests in order to reduce total test execution time.

8.11.4.6 [WINNF.FT.S.FDB.6] GWBL Database Update: GWBL Modification

8.11.4.7 [WINNF.FT.S.FDB.7] FCC ID Database Update4

4 This test case is only applicable if the FCC provides a fully-automated mechanism for SASs to access the relevant FCC-owned information

8.11.4.8 [WINNF.FT.S.FDB.8] Scheduled Database Update

For clarity, this test is written with a single CBSD and protected entity. The test code shall allow for parallel execution of non-interacting tests in order to reduce total test execution time.

8.12 SAS WINNF Database Update

8.12.1 Definition, Applicability, and Scope of the Test Case

This section explains test steps, conditions, and procedures for successful execution and completion of the SAS operation to verify that SAS UUT can retrieve and update its database with shared PAL and CPI Databases.

8.12.2 Test Characteristics

Table 8.12-1 WINNF Database Test Characteristics

8.12.3 Method of test

8.12.3.1 Initial Conditions / Test Pre-conditions

• The preconditions for Shared PAL Database test case are defined below:
  • − The WInnForum Shared PAL Database is available on the WInnForum database and SAS UUT is able to retrieve the data from this Database.
  • − The SAS Administrator must provide the time it takes to pull/synch its database with the Shared PAL Data.
    • a. Updating and implementing database on the SAS database may take some time.
    • b. This time can be an input to test case execution pause/wait time.
  • − All the pre-conditions of PPA Creation Test Case in Section 8.3 are met.
• The preconditions for CPI Database test case are defined below:
  • − The WInnForum CPI Database is available on the WInnForum database and SAS UUT is able to retrieve the data from this Database.
  • − The SAS Administrator must provide the time it takes to pull/synch its database with the CPI Data.
    • a. Updating and implementing database on the SAS database may take some time.
    • b. This time can be an input to test case execution pause/wait time.
  • − A CPI provides its credential to SAS.
    • a. All the CPI credentials are available for this testing. The credentials can be dummy ones as along as it meets CPI credential requirements.
    • b. CPI credentials can be provided through Single-Step Registration.
  • − Successful Registration testing will be carried out for Single-Step Registration.
    • a. All the applicable preconditions of Successful Single-Step Registration Test case (REG.3) is met.

8.12.4 Test Procedure

8.12.4.1 [WINNF.FT.S.WDB.1] PAL Database Update

8.12.4.2 [WINNF.FT.S.WDB.2] CPI database update

For clarity, this test is written with a single CBSD and protected entity. The test code shall allow for parallel execution of non-interacting tests in order to reduce total test execution time.

8.13 International Border Protection

8.13.1 Definition, Applicability, and Scope of the Test Case

This section explains test steps, conditions, and procedures to verify that SAS properly handles Grants for CBSDs located near the International Borders of the US. While Part96 has not clearly outlined the requirements of the International border protection, WInnForum has defined the criteria for SAS to approve the operation of CBSDs near the border.

8.13.2 Test Characteristics

Table 8.13-1 International Border Protection Test Characteristics

8.13.3 Method of test

8.13.3.1 Initial Conditions / Test Pre-conditions

The preconditions for this test case are defined below:

• Assume no Incumbent is present near the border that impacts the Registration of the CBSD.
• Ensuring compliance with Arrangement R [n.23] along the US-Canada border, applied to 3650-3700MHz.

8.13.3.2 International Border Protection Requirement

Consistent with Arrangement R (Ref.15) and (Ref.4), WinnForum defines a "Sharing Zone" adjacent to United States border is defined as 8 km from United States border for any CBSD utilizing an antenna of which the entire main beam looks within the 160-degree sector oriented away from the closest point on the border, or 56 km from United States border for any CBSD utilizing an antenna of which any part of the main beam looks within the 200-degree sector toward the closest point on the border.

Figure 8.13-1clarifies the concept of Sharing Zone as described above. As depicted in this figure, all omni-directional antenna CBSDs are considered inside the Sharing Zone if they are within 56 km of the closet point on the border

Figure 8.13-1 Clarification of Sharing Zone along International Borders

The SAS shall allow spectrum grants to all CBSDs within the sharing zone adjacent to Canadian border over 3650-3700 MHz frequency range, only if the Power Flux Density (PFD) of CBSD transmission at any point along the border is less than $-110 \ dBW/m^2/MHz$ (or $-80 \ dBm/m^2/MHz$ ) at a height 1.5m above the ground.

Assuming the CBSD is located a distance d from its closest point at the international border (point M), its requested maximum EIRP for the grant (maxEirp) is P (dBm/MHz), maxAntGain is the maximum antenna gain of the CBSD, antGain is the antenna gain of the CBSD towards point M, and the mean ITM path loss (in linear domain) from the location of CBSD to point M at a certain height is PL, then the Power Flux Density (PFD) at point M is, calculated at frequency 3.6 GHz by:

$$PFD\left(\frac{\frac{dBm}{m^2}}{MHz}\right) = 10 * log\left(\frac{1}{PL}\right) + P + 10 * log\left(\frac{4\pi}{\lambda^2}\right)$$ $$= P - maxAntGain + antGain 1.0 * log(PL) + 32.6$$ Equation 8.13-1

• 8.13.4 Test Procedure 8..13.4.1 [WINNF.FT.S.BPR.1] Deprecated; the Test ID is Reserved 8..13.4.2 [WINNF.FT.S.BPR.2] Grant Request from CBSDs within the Shared Zone adjacent the Canadian border

8.13.4.3 [WINNF.FT.S.BPR.3] Deprecated; the Test ID is Reserved

8.14 Quiet Zone Protection

8.14.1 Definition, Applicability, and Scope of the Test Case

This section explains test steps, conditions, and procedures to verify that SAS protects designated Quiet Zones [47 CFR 1.924,]. The CBSD shall not be authorized to transmit in the Quiet Zones, without appropriate coordination.

The following Quiet Zones are considered in this test case:

1.- National Radio Astronomy Observatory (NRAO) and the Naval Radio Research Observatory (NRRO). 2.- The Table Mountain Radio Receiving Zone, Boulder County, Co.

3.- FCC Protected Field Offices. FCC has identified a number of FCC field offices that requires protection. Here is the list of the FCC protected offices:

• a. Allegan, Michigan: 42º36'20.1" N. Latitude, 85º57'20.1" W. Longitude
• b. Belfast, Maine: 44º26'42.3" N. Latitude, 69º04'56.1" W. Longitude
• c. Canandaigua, New York: 42º54'48.2" N. Latitude, 77º15'57.9" W. Longitude
• d. Douglas, Arizona: 31º30'02.3" N. Latitude, 109º39'14.3" W. Longitude
• e. Ferndale, Washington: 48º57'20.4" N. Latitude, 122º33'17.6" W. Longitude
• f. Grand Island, Nebraska: 40º55'21.0" N. Latitude, 98º25'43.2" W. Longitude
• g. Kenai, Alaska: 60º43'26.0" N. Latitude, 151º20'15.0" W. Longitude
• h. Kingsville, Texas: 27º26'30.1" N. Latitude, 97º53'01.0" W. Longitude
• i. Laurel, Maryland: 39º09'54.4" N. Latitude, 76º49'15.9" W. Longitude
• j. Livermore, California: 37º43'29.7" N. Latitude, 121º45'15.8" W. Longitude
• k. Powder Springs, Georgia: 33º51'44.4" N. Latitude, 84º43'25.8" W. Longitude
• l. Santa Isabel, Puerto Rico: 18º00'18.9" N. Latitude, 66º22'30.6" W. Longitude
• m. Vero Beach, Florida: 27º36'22.1" N. Latitude, 80º38'05.2" W. Longitude
• n. Waipahu, Hawaii: 21º22'33.6" N. Latitude, 157º59'44.1" W. Longitude