CBSD/DP Test and Certification Specification

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

Conformance and Performance Test Technical Specification;

CBSD/DP as Unit Under Test (UUT)

Working Document WINNF-TS-0122 Version V1.0.2

25 November 2020

Image /page/1/Picture/0 description: The image is a logo for the Wireless Innovation Forum. The logo is set against a brown background. The word "WIRELESS" is at the top, "INNOVATION" is in the middle, and "FORUM" is at the bottom. There are three circles behind the word "INNOVATION".

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 ™, WInnForum Standards™ and SDR Forum ™ are trademarks of the Software Defined Radio Forum Inc.

Contributors

Editor and Task Group Chair: Awaiz Khan, Ruckus Wireless

Other Member Representatives

• Doug Goedken, Nokia
• Idan Raz, AirSpan
• Chris Williams, Ericsson

Test and Certification for CBRS; Conformance and Performance Test Technical Specification; CBSD/DP as UUT

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) [n.9] and WInnForum.

2 Scope

The WInnForum Test Specifications define test procedures for conformance and performance testing of components of the CBRS Architecture, detailed in Section 5. This document defines test and certification procedures for CBSD and Domain Proxy components of the CBRS Architecture. A separate test specification is dedicated to SAS testing [n.10].

The conformance to the test specifications detailed herein will result in compliance to the WInnForum requirements. These test procedures alone will not be sufficient to achieve FCC certification, although they represent one of the required components.

CBSD operation, behavior or RF performance are outside the scope of this of this document, except those directly related to operation and interaction with a SAS.

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 WInnForum protocol compliance testing of CBSD and Domain Proxies, 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 code. The test code is stored in a repository maintained by WInnForum Working Group 4 [i.1].

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, "SAS Functional Architecture ", WINNF-15-P-0047 Version V1.0.0, 7 September 2015.
• [n.4] SSC-Wireless Innovation Forum, "CBRS Communications Security Technical Specification", WINNF-TS-0065-V1.x.x
• [n.5] 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.x.x
• [n.6] SSC-Wireless Innovation Forum, "Requirements for Commercial Operation in the U.S. 3550-3700 MHz Citizens Broadband Radio Service Band", WINNF-TS-0112- V1.x.x
• [n.7] SSC-Wireless Innovation Forum, "WInnForum Recognized CBRS Air Interfaces and Measurements", WINNF-SSC-0002
• [n.8] SSC-Wireless Innovation Forum, "WInnForum CBRS Certificate Policy Specification", WINNF-TS-0022-V1.x.x
• [n.9] 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.10] SSC-Wireless Innovation Forum, "Test and Certification for Citizens Broadband Radio Service (CBRS); Conformance and Performance Test Technical Specification; SAS as Unit Under Test (UUT)", WINNF-TS-0061-V1.x.x

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 Repositories,

• https://github.com/Wireless-Innovation-Forum/Citizens-Broadband-Radio-Service-Device
• https://github.com/Wireless-Innovation-Forum/Spectrum-Access-System
• https://github.com/Wireless-Innovation-Forum/Spectrum-Access-System/tree/master/cert

4 Definitions and Abbreviations

4.1 Abbreviations

CBRS: Citizens Broadband Radio Services
CBSD: Citizens Broadband Radio Service Device
CRL: Certificate Revocation List
DOD: Department of Defense
DP: Domain Proxy
ECC: Elliptic Curve Cryptography (algorithm)
EMS: Element Management System
ESC: Environment Sensing Capability
FCC: Federal Communications Commission
IOT: Inter-Operability Test
NTIA: National Telecommunications and Information Administrations
OCSP: Online Certificate Status Protocol
RAN: Radio Access Network
RSA: Rivest, Shamir, Adleman (cryptography algorithm)
SAS: Spectrum Access System
UUT: Unit Under Test

4.2 Definitions

SAS Test Harness: A collection of routines that can be executed by the test operator, to interact with the CBSD or DP/CBSD UUT via interfaces specified in [n.5]. Test Harness emulates the message sequences that would be generated by a SAS and it is used to automate critical test sequences and procedures in this document. The SAS Test Harness software is stored in a public location specified in [i.1].

Unit Under Test: A CBSD or DP/CBSD(s) that is tested for compliance with WInnForum test specification. The SAS Test Harness is used to receive and send messages with the Unit Under Test (UUT) according to the test procedures contained in this document. The term "Unit Under Test" is applied generically within this document to include, where appropriate, either a CBSD or the combination of a Domain Proxy and CBSD.

5 Test and Certification Process

Work Group 4 develops the test cases to test the UUT compliance with the requirements, protocols, specifications, and interfaces that are defined by SSC-WInnForum Work Groups 1, 2 and 3. WInnForum specification are derived from FCC, NTIA, and DOD requirements. 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 CBSD/DP UUT to the requirements developed by WInnForum and supporting FCC/DoD requirements.
• Interoperability Test (IT): 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 CBSD/DP UUT to support various traffic models and actual operations in the field.

The Protocol and Functional test cases are converted to test scripts to facilitate the development of test apparatus (emulator), which must 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 Case Classification

In addition to certification specifications and requirements, WInnForum test cases should include verification that error conditions and fault management protection to support incumbent interference management, conforming to WInnForum requirements, and meeting required performances performed by vendors prior to or during official certification process. To this end the requirements could be reviewed initially by the certification body and test cases could be classified in three classes: Certification, Acceptance, and Evidence

5.1.1 Class 1: Certification

Testing takes place in an independent, secure and supervised test center or by "Certification partners" where selected requirements are tested and officially approved as having met a standard.

5.1.2 Class 2: Acceptance

Testing conducted to determine if the requirements or specifications (e.g. WG2/WG3 specifications) are met. This testing can be done in lab inter-operability testing similar to how telecommunications equipment is currently tested. This would be focused on black-box system level testing. These tests could be either functional, performance, or inter-operability test cases.

5.1.3 Class 3: Evidence

Material that is presented that furnishes proof of compliance or operation that will satisfy outside regulators that all necessary tests have been executed and passed

5.2 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*}

TestRequirement indicates whether a test is to verify if the Unit Under Test meets FCC requirements or Technical Specifications provided by Wireless Innovation Forum. 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 The values of TestRequirement in Test ID

Table 5-2 The values of TestCategory in Test ID

Table 5-3 The values of UnitUnderTest in Test ID

Table 5-4 The values of TestFunction in Test ID

5.3 Equipment Requirements for this Test Plan

The following figure provide a high-level view of the main components required for the test configuration.

Figure 1: High level test configuration: CBSD and DP/CBSD

5.3.1 Required Vendor-Supplied Equipment for Test Process

The following equipment is required to perform test cases in this document:

• For stand-alone CBSD, vendor shall supply one CBSD
• For CBSD under control of Domain Proxy, vendor shall supply a Domain Proxy with two CBSD
• Vendor shall supply any ancillary equipment and manual procedure if required to ensure CBSD will transmit when it obtains a grant in AUTHORIZED state. This may include additional equipment such as End-User device(s), if required.
• UUT shall be UTC time synchronized

5.3.2 Test Equipment Requirements

The following test equipment are required to test the UUT:

• SAS Test Harness The SAS Test Harness shall validate all required parameters are provided in the various request messages. In addition, all the parameters, whether required or optional, included in the request message shall be validated by the SAS Test Harness to ensure the parameter and its value conforms to the proper format and acceptable range according to [n.5]. The SAS Test Harness will mark the test case as "Fail" if a required parameter is not provided, or its value is not of proper format or range.
• RF measurement equipment: Equipment (such as spectrum analyzer) capable of measuring RF interface of UUT, to determine: Whether UUT is transmitting or not, including ability to measure time when UUT RF transmission starts or ends Whether UUT is transmitting within granted frequency range Can assist in determining the transmitted power of the UUT according to it granted parameters from the SAS Test Harness

This includes any ancillary RF components (attenuators, cables, couplers, etc.) which may be required to perform those measurements.

The SAS Test Harness and RF measurement equipment shall be synchronized to UTC time.

The following are outside the scope of this document:

• Choice of specific RF test equipment, and exact configuration or operation of that equipment
• Specific test setup to allow monitoring of the UUT by the RF measurement equipment

5.3.3 UUT Test Interface Requirements

The unit-under-test shall provide functionality via a vendor-defined test interface, in order to support completion of all test cases in this document. The interface is outside the scope of this test document, but shall provide a minimum set of functionalities as described below:

• 1. Method to return CBSD to an unregistered state after the conclusion of a test case. Test cases conclude with the CBSD in various states, such as Authorized grant state and actively transmitting, or may end with the SAS Test Harness providing an error condition (such as a non-zero error code, or no response). Therefore, it is necessary for the test interface to provide a method to return the CBSD to an unregistered state, prior to start of the next test case.
• 2. Method to trigger CBSD to perform the following sequence in its entirety, automatically, starting from an unregistered state, and provided each step results in a successful Response message (response code = 0):
  • a. Register with SAS
  • b. Perform Spectrum Inquiry Request (optional, if UUT supports this message)
  • c. Perform Grant Request, where UUT requests a pre-defined frequency range of operation and maxEirp, as required by the particular test case
  • d. Heartbeat the CBSD for the grantId obtained
  • e. Begin transmission within the Granted frequency range
• 3. Method to trigger CBSD to perform a Spectrum Relinquishment, if it has a valid grant in AUTHORIZED or GRANTED state.
• 4. Method to trigger CBSD to Deregister, if it is in the registered state.
• 5. Method to load test certificates into UUT, as required, for use in authentication procedures with the SAS Test Harness.
• 6. If provided by the CBSD, access to the CBSD CPI interface for entering of CPI-related registration information into the CBSD.
• 7. UUT shall be able to support a single grant request.

5.3.4 Requirements for UUT supporting several Air Interfaces

UUT which supports more than one Air Interface according to [n.7] shall execute for each supported Air Interface the UUT RF Transmit Power Measurement test case (see Table 6-3 section 7.1.4.1.1). Based on UUT vendor implementation, other test cases in Table 6-3 may be necessary for each supported Air Interface.

6 SAS-CBSD/DP Interface Conformance Test Specifications

This section includes all the test cases required for ensuring the SAS-CBSD/DP interface conforms to the specifications defined by WInnForum and directed by the requirements established by the FCC and DOD. The tables in this section identify and categorize the test cases for conformance testing.

Table 6-1 indicates the legend for test case classification in Table 6-3.

Table 6-1 Test Case Classification (for Table 6-3)

Table 6-2 defines the applicability of conditional test cases listed in Table 6-3. Test cases marked as Conditional in Table 6-3 are mandatory for devices, as defined by the UUT vendor, according to the conditional definitions below.

Table 6-2 Conditional Test Case Definitions (for Table 6-3)

Table 6-3 lists all test cases in this document, with indication of certification status (M/O/C – see Table 6-1), conditionality of test case, where appropriate (see Table 6-2), and applicability to CBSD or Domain Proxy (DP). Specifically:

• CBSD column indicates test cases which apply to stand-alone CBSD as UUT (test cases numbered as WINNF.FT.C.xxx.yy).
• DP column indicates test case which apply to a combination of Domain Proxy and CBSD(s) as UUT. For tests indicated as applicable to DP in this column: WINNF.FT.C.xxx.yy test cases are written for a single CBSD, and therefore apply to a DP with one CBSD as UUT WINNF.FT.D.xxx.yy test cases apply to a DP with two CBSD as UUT

Table 6-3 Test Case List

6.1 CBSD Registration Process

6.1.1 Definition and applicability and Scope of Test Case

This section provides test steps, conditions and procedures to test the conformance of the CBSD implementation for the CBSD Registration Procedure. A precondition is the CBSD has successfully discovered the SAS it wants to register with.

Each test generates a CBSD registration request and validates the CBSD takes the appropriate action following the SAS registration response, covering all the defined responseCodes available that pertain to the CBSD registration process in [n.5]. This includes successful registration as well, which is signified by responseCode 0.

6.1.2 Test Characteristics

Table 6-4 CBSD Registration Process Test Characteristics

6.1.3 Method of test

6.1.3.1 Initial Conditions / Test Pre-conditions

• − The pre-conditions of the test case are: CBSD has gone through SAS discovery process and can authenticate with the SAS. The exact condition of the CBSD after the discovery process are detailed in each test case.
• − The applicable structure of the RegistrationRequest parameter and RegistrationRequest object are defined in [n.5].

In summary, the CBSD parameters used for the registration process are categorized into the following [n.5]:

Required REG-Conditional Optional

Two cases are considered:

When the location and other installation parameters are reported by the CBSD, and are included in the registration message. Information may be determined solely by the CBSD, or by CPI uploading the data into the CBSD. When the location and other installation parameters are uploaded offline by a professional installer.

Note: In this Section, "Multi-Step Registration" refers to the Registration process where the REG-conditional parameters are not included in the "RegistrationRequest Object". "Single-Step Registration" refers to the Registration process where the conditional parameters are included in the "RegistrationRequest Object". A CBSD vendor may support one or more of these registration methods. Test cases apply according to the type of registration process(es) supported by the CBSD under test.

If a CBSD has a valid FCC-ID, the assumption is the measurement capability shall be included in the Registration Request. The CBSD vendor may ask the FCC for a waiver to the measurement capability. The Single-Step registration test cases assume there is no waiver and therefore the test case will fail if the measurement capability is not provided.

The commercial SAS shall not reject a CBSD Registration request due to the fact the CBSD has left the measurement capability empty. If a waiver has been obtained for the UUT, a similar test case shall be executed that is not requiring a measurement capability be supplied in the registration message. Since this is based on obtaining an FCC waiver, the waiver specific test cases are not listed in Table 6-3.

The following two rules shall also be applied for a Single-Step registration for CBSD with CPI signed data.

If the installationParam object is provided outside of cpiSignedData, the Registration request shall be rejected. The installationParam object shall be provided inside the cpiSignedData and shall include all of its REG-Conditional parameters. If incomplete, the Registration request shall be rejected.

6.1.4 Test Procedure

6.1.4.1 Successful registration (responseCode 0)

Upon a successful response from the SAS (responseCode = 0), the CBSD will generate its next message to the SAS. The SAS Test Harness when configured for verification of a particular CBSD-SAS protocol procedure (i.e. registration), will / may not respond to any subsequent messages sent by CBSD once the procedure being tested is complete.

6.1.4.1.1 [WINNF.FT.C.REG.1] Multi-Step registration

This test is mandatory for CBSD which supports multi-step registration. This test validates that each of the required parameters appear within the registration request message. The following are the test execution steps:

6.1.4.1.2 [WINNF.FT.D.REG.2] Domain Proxy Multi-Step registration

This test is mandatory for the Domain proxy that is controlling CBSDs which support multi-step registration. This test validates that each of the required parameters appear within the registration request message. This test case applies to Domain Proxy supervising two CBSDs. The following are the test execution steps:

UUT shall not transmit RF

6.1.4.1.3 [WINNF.FT.C.REG.3] Single-Step registration for Category A CBSD

This test is mandatory for CBSD which reports all Required and REG-Conditional parameters in the Registration request to the SAS, without CPI signed data. This test validates that each of the required and REG-Conditional parameters appear within the registration request message.

For a Category A CBSD which determine its own location, the test lab and vendor must agree on the required evidence showing the UUT meets the location requirement. In lieu of location verification, the vendor shall supply their test approach/procedure along with compliance data.

The following are the test execution steps:

If a waiver for the measurement capability has been obtained from the FCC for the CBSD, the WINNF.FT.C.REG.3_waiver test case shall be executed which is the same as above, but where measCapability is not required in the request message.

6.1.4.1.4 [WINNF.FT.D.REG.4] Domain Proxy Single-Step registration for Cat A CBSD

This test is mandatory for DP connected to CBSDs which report all Required and REG-Conditional parameters in the Registration request to the SAS, without CPI signed data. This test validates that each of the required and REG-Conditional parameters appear within the registration request message. This test case applies to Domain Proxy supervising two CBSDs.

For a Category A CBSD which determine own location, the test lab and vendor must agree on the required evidence showing the UUT meets the location requirement. In lieu of location verification, the vendor shall supply their test approach/procedure along with compliance data.

The following are the test execution steps:

If a waiver for the measurement capability has been obtained from the FCC for the CBSD, the WINNF.FT.D.REG.4_waiver test case shall be executed which is the same as above, but where measCapability is not required in the request message.

6.1.4.1.5 [WINNF.FT.C.REG.5] Single-Step registration for CBSD with CPI signed data

This test is mandatory for CBSD which reports all Required and REG-Conditional parameters in the Registration request to the SAS using CPI signed data. This test validates that each of the required and REG-Conditional parameters appear within the registration request message.

All Category B devices, and Category A devices not able to determine its own location require installation by a CPI. This test is for devices where the CPI enters data into the CBSD and this information along with the CPI signature are sent in the request message. Excluded from this test are devices which require the CPI to enter the information into a SAS interface. These devices would use the multiple step registration test [WINNF.FT.C.REG.1].

The following are the test execution steps:

If a waiver for the measurement capability has been obtained from the FCC for the CBSD, the WINNF.FT.C.REG.5_waiver test case shall be executed which is the same as above, but where measCapability is not required in the request message.

6.1.4.1.6 [WINNF.FT.D.REG.6] Domain Proxy Single-Step registration for CBSD with CPI signed data

This test is mandatory for DP with CBSDs which report all Required and REG-Conditional parameters in the Registration request to the SAS using CPI signed data. This test validates that each of the required and REG-Conditional parameters appear within the registration request message. This test case applies to Domain Proxy supervising two CBSDs.

All Category B devices, and Category A devices not able to determine its own location require installation by a CPI. This test is for devices where the CPI enters data into the CBSD and this information along with the CPI signature are sent in the request message. Excluded from this test are devices which require the CPI to enter the information into a SAS interface. These devices would follow the multiple step registration test [WINNF.FT.D.REG.2].

If a waiver for the measurement capability has been obtained from the FCC for the CBSD, the WINNF.FT.D.REG.6_waiver test case shall be executed which is the same as above, but where measCapability is not required in the request message.

6.1.4.1.7 [WINNF.FT.C.REG.7] Registration due to change of an installation parameter

The purpose of this test is to verify the CBSD sends notification to the SAS when an installation parameter has been changed.

This test is limited to CBSDs that support a registration parameter change/update to be made at the CBSD.

Further, this test only applies to CBSD devices that allow a registration parameter change to be made prior to sending a deregistration.

This test is not valid for CBSDs requiring a deregistration prior to allowing a parameter change to be made (for example, (i) bring CBSD out of service (deregister), (ii) change registration parameter, (iii) bring CBSD back into service (register)). Refer to the deregistration test case [WINNF.FT.C.DRG.1].

This test is also not valid for CBSDs which require registration parameter updates to be made directly into the SAS via a SAS interface.

The following are the test execution steps:

6.1.4.2 Unsuccessful registration: non-zero responseCodes

CBSD under test cannot be expected to generate a message with a missing or invalid parameter. To test for responseCode not equal to 0, the SAS Test Harness will respond to a valid registrationRequest message with a registrationResponse with a non-zero responseCode.

The purpose of these tests is to ensure that the CBSD does not transmit when a responseCode other than 0 is received. The information sent in the registration request message is not important, only that it shall conform to the protocol.

Missing/Invalid response codes are tested by injecting those responseCodes into the SAS Test Harness generated response message, even though the UUT has sent a valid message

6.1.4.2.1 [WINNF.FT.C.REG.8] Missing Required parameters (responseCode 102)

The following are the test execution steps where the Registration response contains responseCode (R) = 102:

6.1.4.2.2 [WINNF.FT.D.REG.9] Domain Proxy Missing Required parameters (responseCode 102)

This test case applies to Domain Proxy supervising two CBSDs. The following are the test execution steps where the Registration response contains responseCode (Ri) = 102 for each CBSD:

6.1.4.2.3 [WINNF.FT.C.REG.10] Pending registration (responseCode 200)

The same steps provided for WINNF.FT.C.REG.8 shall be executed for this test, with the exception that the Registration response contains responseCode (R) = 200.

6.1.4.2.4 [WINNF.FT.D.REG.11] Domain Proxy Pending registration (responseCode 200)

The same steps provided for WINNF.FT.D.REG.9 shall be executed for this test, with the exception that the Registration response contains responseCode (Ri) = 200 for each CBSD.

6.1.4.2.5 [WINNF.FT.C.REG.12] Invalid parameter (responseCode 103)

The same steps provided for WINNF.FT.C.REG.8 shall be executed for this test, with the exception that the Registration response contains responseCode (R) = 103.

6.1.4.2.6 [WINNF.FT.D.REG.13] Domain Proxy Invalid parameters (responseCode 103)

The same steps provided for WINNF.FT.D.REG.9 shall be executed for this test, with the exception that the Registration response contains responseCode R1 = 0 for CBSD1 and R2 = 103 for CBSD2.

6.1.4.2.7 [WINNF.FT.C.REG.14] Blacklisted CBSD (responseCode 101)

The same steps provided for WINNF.FT.C.REG.8 shall be executed for this test, with the exception that the Registration response contains responseCode (R) = 101.

6.1.4.2.8 [WINNF.FT.D.REG.15] Domain Proxy Blacklisted CBSD (responseCode 101)

The same steps provided for WINNF.FT.D.REG.9 shall be executed for this test, with the exception that the Registration response contains responseCode R1 = 0 for CBSD1 and R2 = 101 for CBSD2.

6.1.4.2.9 [WINNF.FT.C.REG.16] Unsupported SAS protocol version (responseCode 100)

The same steps provided for WINNF.FT.C.REG.8 shall be executed for this test, with the exception that the Registration response contains responseCode (R) = 100.

6.1.4.2.10 [WINNF.FT.D.REG.17] Domain Proxy Unsupported SAS protocol version (responseCode 100)

The same steps provided for WINNF.FT.D.REG.9 shall be executed for this test, with the exception that the Registration response contains responseCode (Ri) = 100 for each CBSD.

6.1.4.2.11 [WINNF.FT.C.REG.18] Group Error (responseCode 201)

The registrationRequest groupingParam is an optional field and will be validated by the SAS Test Harness if provided in the Registration Request message. This test will validate that the CBSD will remain Unregistered after receiving responseCode 201.

The same steps provided for WINNF.FT.C.REG.8 shall be executed for this test, with the exception that the Registration response contains responseCode (R) = 201.

6.1.4.2.12 [WINNF.FT.D.REG.19] Domain Proxy Group Error (responseCode 201)

The registrationRequest groupingParam is an optional field and will be validated by the SAS Test Harness if provided in the Registration Request message. This test will validate that the CBSD will remain Unregistered after receiving responseCode 201.

The same steps provided for WINNF.FT.D.REG.9 shall be executed for this test, with the exception that the Registration response contains responseCode R1 = 0 for CBSD1 and R2 = 201 for CBSD2.

6.1.4.3 Category A CBSD location update

This section is specific to Category A CBSDs that do not require professional installation. The requirement is for the Category A (non-professionally installed) to report to the SAS any location change exceeding a distance of 50m horizontally or 3m vertically within a 60 second window. It is left to the CBSD vendor and certification lab to generate the required evidence showing the UUT meets the requirement.

6.1.4.3.1 [WINNF.FT.C.REG.20] Category A CBSD location update

The test case ID is provided as a means to ensure that evidence is provided showing compliance to this requirement.

6.2 CBSD Spectrum Inquiry Process

6.2.1 Definition and applicability and Scope of Test Case

Spectrum Inquiry is an optional set of messages between the CBSD or DP/CBSD and SAS. If Spectrum Inquiry is used by the UUT, the specific Spectrum Inquiry test cases shall be executed.

This section provides test steps, condition and procedures to test the conformance of the CBSD implementation for the CBSD Spectrum Inquiry Procedure. It assumes as a precondition the CBSD has successfully discovered the SAS it wants to communicate with.

Each test generates a CBSD spectrum inquiry request and validatesthe CBSD takes the appropriate action following the SAS spectrum inquiry response.

6.2.2 Test Characteristics

Table 6-5 CBSD Spectrum Inquiry Process Test Characteristics

6.2.3 Method of test

6.2.3.1 Initial Conditions / Test Pre-conditions

• − The pre-conditions of the test case are: CBSD has gone through SAS discovery process and can authenticate with the SAS. The exact condition of the CBSD after the discovery process are detailed in each test case. The CBSD has already registered with SAS and has obtained a valid cbsdId
• − The applicable structure of the SpectrumInquiryRequest parameter and SpectrumInquiryResponse objects are defined in [n.5].

6.2.4 Test Procedure

6.2.4.1 Successful response from the SAS Test Harness

In all test cases under this category, the SpectrumInquiry Request is correct and valid. That is, the SAS Test Harness has checked that all the "Required" parameters are present in the SpectrumInquiry Request and their values are valid and correct. This part makes sure that CBSD is able to send correct and valid SpectrumInquiry Request.

6.2.4.1.1 Successful spectrum Inquiry response from SAS

This test case is incorporated into WINNF.FT.C.HBT.1, which validates successful Spectrum Inquiry messaging, if it is used by the UUT, as part of that test case.

6.2.4.1.2 Successful spectrum Inquiry response from SAS for all requests – Domain Proxy This test case is incorporated into WINNF.FT.D.HBT.2, which validates successful Spectrum Inquiry messaging, if it is used by the UUT, as part of that test case

6.3 CBSD Spectrum Grant Process

6.3.1 Definition and applicability and Scope of Test Case

This section provides test steps, condition and procedures to test the conformance of the CBSD implementation for the CBSD Spectrum Grant Procedure. A precondition is the CBSD has successfully discovered the SAS it wants to communicate with.

Each test generates a CBSD spectrum grant request and validates the CBSD takes the appropriate action following the SAS spectrum grant response.

6.3.2 Test Characteristics

Table 6-6 CBSD Spectrum Grant Process Test Characteristics

6.3.3 Method of test

6.3.3.1 Initial Conditions / Test Pre-conditions

• − The pre-conditions of the test case are: CBSD has gone through SAS discovery process and can authenticate with the SAS. The exact condition of the CBSD after the discovery process are detailed in each test case. The CBSD has already registered with SAS and has obtained a valid cbsdId.
• − The applicable structure of the GrantRequest parameter and GrantResponse objects are defined in [n.5].

6.3.4 Test Procedure

6.3.4.1 Successful responses from the SAS Test Harness

In all test cases under this category, the Grant Request is correct and valid. That is, the SAS Test Harness has checked that all the "Required" parameters are present in the Grant Request and their values are valid and correct. This part makes sure that CBSD is able to send correct and valid Grant Request.

6.3.4.1.1 Successful Grant response

This test case is incorporated into WINNF.FT.C.HBT.1, which validates successful Grant messaging as part of that test case.

6.3.4.1.2 Domain Proxy Successful Grant response

This test case is incorporated into WINNF.FT.D.HBT.2, which validates successful Grant messaging as part of that test case.

6.3.4.2 Unsuccessful responses from the SAS Test Harness

The test cases in this section are for verifying the handling of CBSD for various responseCodes in response from the-SAS Test Harness.

The actions taken in response of any responseCode are beyond the scope of this document unless mentioned in the test procedure.

6.3.4.2.1 [WINNF.FT.C.GRA.1] Unsuccessful Grant responseCode=400 (INTERFERENCE)

The following steps describe the test execution where the Grant response contains responseCode (R) = 400.

6.3.4.2.2 [WINNF.FT.C.GRA.2] Unsuccessful Grant responseCode=401 (GRANT_CONFLICT)

The same steps provided for WINNF.FT.C.GRA.1 shall be executed for this test, with the exception that the Grant response contains responseCode (R) = 401.

6.4 CBSD Heart Beat Process

6.4.1 Definition and applicability and Scope of Test Case

This section provides procedures for testing CBSD behavior during the Heartbeat Process. It assumes as precondition that CBSD has successfully discovered the SAS that it wants to register with, has successfully registered, has a successful Grant request, and is in the Granted or Authorized state.

6.4.2 Test Characteristics

Table 6-7 CBSD Heart Beat Process Test Characteristics

6.4.3 Method of test

6.4.3.1 Initial Conditions / Test Pre-Conditions

Test case entry for all test cases includes:

• Test harness SAS Discovery and Authentication by CBSD is complete
• CBSD has registered successfully with SAS Test Harness

6.4.4 Test Procedure

6.4.4.1 Successful Heartbeat (responseCode=0)

The test cases in this section test the success path for the Heartbeat process. The SAS Test Harness shall use a heartBeatInterval of 60 seconds, unless specifically provided in the test case.

6.4.4.1.1 [WINNF.FT.C.HBT.1] Heartbeat Success Case (first Heartbeat Response)

This test case incorporates validation of successful Spectrum Inquiry messaging (if present) and successful Grant messaging into the Heartbeat Success case.

6.4.4.1.2 [WINNF.FT.D.HBT.2] Domain Proxy Heartbeat Success Case (first Heartbeat Response)

This test case incorporates validation of successful Spectrum Inquiry messaging (if present) and successful Grant messaging into the Heartbeat Success case.

This test case applies to Domain Proxy supervising two CBSDs.

6.4.4.2 Unsuccessful Heartbeat Test Cases (responseCode != 0)

The test cases in this section cover Heartbeat Response messages with non-zero responseCodes. Part of the pass/fail criteria of these test cases is the cessation of all UUT RF transmission. Therefore, in all test cases, after the non-zero responseCode is sent, the SAS Test Harness shall not allow any new Grant Request from the UUT to succeed.

6.4.4.2.1 [WINNF.FT.C.HBT.3] Heartbeat responseCode=105 (DEREGISTER)

6.4.4.2.2 [WINNF.FT.C.HBT.4] Heartbeat responseCode=500 (TERMINATED_GRANT)

The following are the test execution steps.

6.4.4.2.3 [WINNF.FT.C.HBT.5] Heartbeat responseCode=501 (SUSPENDED_GRANT) in First Heartbeat Response

6.4.4.2.4 [WINNF.FT.C.HBT.6] Heartbeat responseCode=501 (SUSPENDED_GRANT) in Subsequent Heartbeat Response

6.4.4.2.5 [WINNF.FT.C.HBT.7] Heartbeat responseCode=502 (UNSYNC_OP_PARAM)

6.4.4.2.6 [WINNF.FT.D.HBT.8] Domain Proxy Heartbeat responseCode=500 (TERMINATED_GRANT)

This test case applies to Domain Proxy supervising two CBSDs.

6.4.4.3 Heartbeat Response Absent Test Cases

These test cases cover the case where communication is lost between the UUT and the SAS during the Heartbeat Process.

6.4.4.3.1 [WINNF.FT.C.HBT.9] Heartbeat Response Absent (First Heartbeat)

At any time during the test, UUT shall not transmit on RF interface

6.4.4.3.2 [WINNF.FT.C.HBT.10] Heartbeat Response Absent (Subsequent Heartbeat)

The following are the test execution steps.

6.4.4.4 Heartbeat Grant Renewal Cases

Test cases in this section test Grant Renewal within the Heartbeat Process.

6.4.4.4.1 [WINNF.FT.C.HBT.11] Successful Grant Renewal in Heartbeat Test Case

6.5 CBSD Measurement Report

6.5.1 Definition and applicability and Scope of Test Case

This section explains test steps/condition/procedure for CBSD behavior for Measurement Reports.

The main test cases for Measurement Report are outlined below, in terms of Measurement Report Stimulus (in a Response message from SAS) and a Measurement Report Response (in the subsequent Request message from the UUT).

Devices which support one measurement capability must satisfy the test cases mandatory for that measurement capability. Devices which support multiple measurement capabilities must satisfy the test cases mandatory for each type of supported measurement capability.

Measurement Report Test Cases

* Note: SpectrumInquiryRequest is an optional message. If present, measReport shall be in both SpectrumInquiryRequest and GrantRequest

The Measurement Report element enumerations, formats and acceptable values are described in [n.7].

Since there is no measurement accuracy requirement, Measurement Reports are tested for proper format, but not for reporting accuracy.

6.5.2 Test Characteristics

Table 6-8 CBSD Measurement Report Process Test Characteristics

6.5.3 Method of test

6.5.3.1 Initial Conditions / Test Preconditions

Test case entry for all test cases includes:

Test harness SAS Discovery and Authentication by CBSD is complete

Additional entry requirements are outlined in each test case.

** Indicates test is Mandatory (M) or n/a to UUT which supports RECEIVED_POWER_WITHOUT_GRANT or RECEIVED_POWER_WITH_GRANT

6.5.4 Test Procedure

6.5.4.1 Measurement Capability Test Cases

Test cases in this section test the proper reporting of Measurement Capability by the CBSD.

6.5.4.1.1 Measurement Capability in Registration Request Message

Testing of CBSD measurement capability (measCapability) reporting is done in the appropriate registration test case(s): WINNF.FT.C.REG.3, WINNF.FT.D.REG.4, WINNF.FT.REG.5, and WINNF.FT.D.REG.6.

6.5.4.2 Measurement Report Test Cases

Test cases in this section test the success path for each possible Measurement Report

6.5.4.2.1 [WINNF.FT.C.MES.1] Registration Response contains measReportConfig

This test case is mandatory for CBSD supporting RECEIVED_POWER_WITHOUT_GRANT.

6.5.4.2.2 [WINNF.FT.D.MES.2] Domain Proxy Registration Response contains measReportConfig

This test case is mandatory for Domain Proxy supervising CBSD which support RECEIVED_POWER_WITHOUT_GRANT.

6.5.4.2.3 [WINNF.FT.C.MES.3] Grant Response contains measReportConfig

This test case is mandatory for UUT supporting RECEIVED_POWER_WITH_GRANT measurement reports.

6.5.4.2.4 [WINNF.FT.C.MES.4] Heartbeat Response contains measReportConfig

This test case is mandatory for UUT supporting RECEIVED_POWER_WITH_GRANT measurement reports.

6.5.4.2.5 [WINNF.FT.D.MES.5] Domain Proxy Heartbeat Response contains measReportConfig

This test case is mandatory for Domain Proxy supervising CBSD which support RECEIVED_POWER_WITH_GRANT measurement reports.

6.6 CBSD Relinquishment Process

6.6.1 Definition and applicability and Scope of Test Case

This section provides test steps, condition and procedures to test the conformance of the CBSD implementation for the CBSD Relinquishment Procedure. A precondition is the CBSD has successfully discovered the SAS it wants to communicate with.

Each test generates a CBSD relinquishment request and validates the CBSD takes the appropriate action following the SAS relinquishment response. The CBSD shall send the Relinquishment request message after stopping the RF transmission.

6.6.2 Test Characteristics

Table 6-9 CBSD Relinquish Process Test Characteristics

6.6.3 Method of Test

6.6.3.1 Initial Conditions / Test Pre-conditions

• − The pre-conditions of the test case are: CBSD has gone through SAS discovery process and can authenticate with the SAS. The exact condition of the CBSD after the discovery process are detailed in each test case. The CBSD has registered with SAS Test Harness and obtained a valid cbsdId (C). The CBSD has received a successful grant, grantId (G).
• − The applicable structure of the relinquishmentRequest parameter and relinquishmentResponse objects are defined in [n.5].

6.6.4 Test Procedure

6.6.4.1 Successful Relinquishment Request (responseCode 0)

6.6.4.1.1 [WINNF.FT.C.RLQ.1] Successful Relinquishment

6.6.4.1.2 [WINNF.FT.D.RLQ.2] Domain Proxy Successful Relinquishment

6.6.4.2 Missing Parameter (responseCode 102)

CBSD under test cannot be expected to generate a message with a missing or invalid parameter. To test for responseCode not equal to 0, the SAS Test Harness will respond to a message with a non-zero responseCode.

6.6.4.2.1 [WINNF.FT.C.RLQ.3] Unsuccessful Relinquishment, responseCode=102

The following are the test execution steps where the Relinquishment response contains responseCode (R) = 102.

6.6.4.2.2 [WINNF.FT.D.RLQ.4] Domain Proxy Unsuccessful Relinquishment, responseCode=102

This test case applies to Domain Proxy supervising two CBSDs. The following are the test execution steps where the Relinquishment response contains responseCode (Ri) = 102 for each CBSD.

6.6.4.3 Invalid Parameter (responseCode 103)

CBSD under test cannot be expected to generate a message with a missing or invalid parameter. To test for responseCode not equal to 0, the SAS Test Harness will respond to a message with a non-zero responseCode.

6.6.4.3.1 [WINNF.FT.C.RLQ.5] Unsuccessful Relinquishment, responseCode=103

The same steps provided for WINNF.FT.C.RLQ.3 shall be executed for this test, with the exception that the Relinquishment response contains responseCode (R) = 103 and responseData = "grantId".

6.6.4.3.2 [WINNF.FT.D.RLQ.6] Domain Proxy Unsuccessful Relinquishment, responseCode=103

The same steps provided for WINNF.FT.D.RLQ.4 shall be executed for this test, with the exception that the Relinquishment response contains responseCode (Ri) = 103 and responseData = "grantId" for each CBSD.

6.7 CBSD Deregistration Process

6.7.1 Definition and applicability and Scope of Test Case

This section explains test steps/condition/procedure for the CBSD Deregistration Request and its subsequent actions following the reception of the Deregistration Responses from the SAS.

A Deregistration request is issued by a CBSD to request a SAS to deregister the CBSD from the SAS. A Deregistration Request Message issued by a CBSD is provided in [n.5], Section 10.11.

In the Deregistration Response message, the SAS should echo back an array of DeregistrationResponse object. Each deregistrationResponse object consists of a cbsdId and a responseCode. If the deregistration request was successful, the responseCode should be set to 0, otherwise responseCode is set to appropriate error value. The deregistrationResponse Message and the deregistrationResponse object are provided in [n.5], Section 10.12.

Each test generates a CBSD deregistration request and validates the CBSD takes the appropriate actions following the SAS deregistration response.

These deregistration test cases assume the CBSD is the source (operator initiated, for instance reset site). Deregistrations triggered by the SAS in a response message with a responseCode of 105 are covered in other test cases.

6.7.2 Test Characteristics

Table 6-10 CBSD Deregistration Process 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:

• CBSD has registered with the SAS Test Harness and obtained a valid cbsdId (C).
• CBSD has received a successful grant, grantId (G). The CBSD is in the authorized state and is transmitting.
• CBSD UUT must provide functionality to trigger a deregistration.

From [n.5], the CBSD should send a RelinquishmentRequest object for each Grant prior to sending the DeregistrationRequest object. The CBSD will cease RF transmission with the relinquishment message.

6.7.4 Test Procedure

A Deregistration request is issued by a CBSD to request a SAS to deregister the CBSD from the SAS. A Deregistration Request Message issued by a CBSD is provided in [n.5], Section 10.11.

6.7.4.1 Successful Deregistration Request (responseCode 0)

6.7.4.1.1 [WINNF.FT.C.DRG.1] Successful Deregistration

The following are the test execution steps.

6.7.4.1.2 [WINNF.FT.D.DRG.2] Domain Proxy Successful Deregistration

6.7.4.2 Missing Parameter (responseCode 102)

CBSD under test cannot be expected to generate a message with a missing or invalid parameter. To test for responseCode not equal to 0, the SAS Test Harness will respond to a message with a non-zero responseCode.

6.7.4.2.1 [WINNF.FT.C.DRG.3] Deregistration responseCode=102

The following are the test execution steps where the Deregistration response contains responseCode (R) = 102.

6.7.4.2.2 [WINNF.FT.D.DRG.4] Domain Proxy Deregistration responseCode=102

The following are the test execution steps where the Deregistration response contains responseCode (Ri) = 102 for each CBSD..

6.7.4.3 Invalid Parameter (responseCode 103)

CBSD under test cannot be expected to generate a message with a missing or invalid parameter. To test for responseCode not equal to 0, the SAS Test Harness will respond to a message with a non-zero responseCode.

6.7.4.3.1 [WINNF.FT.C.DRG.5] Deregistration responseCode=103

The same steps provided for WINNF.FT.C.DRG.3 shall be executed for this test, with the exception that the Deregistration response contains responseCode (R) = 103 and responseData = "cbsdId".

6.8 CBSD Security Validation

6.8.1 Definition and applicability and Scope of Test Case

This section provides test steps, condition and procedures to test the conformance of the CBSD implementation for the Security Establishment Procedure. A precondition is the CBSD has successfully discovered the SAS it wants to communicate with.

Certificate generation for executing the security test cases shall be according to section 9.1.

Each test initiates communication between CBSD and SAS and verifies that the communication is started over a secured communication.

6.8.2 Test Characteristics

Table 6-11 CBSD Security Process Test Characteristics

6.8.3 Method of test

6.8.3.1 Initial Conditions / Test Pre-conditions

• − The pre-conditions of the test case are: CBSD has gone through SAS discovery process. The exact condition of the CBSD after the discovery process are detailed in each test case. The test certificates are loaded on CBSD as well as on the SAS Test Harness.

6.8.3.2 Test Certificate Generation & Use

This section describes the generation of "test certificates" as per [n.8] and their use for CBSD certification testing. Though the following sections describe and recommend the "test" certificates use for CBSD security procedure verification assuming certificates generated by [i.1] scripts, however, this does not prevent CBSD and SAS Test Harness from using other scripts / methods to generate "test" certificates for use. In case different scripts / methods are used for generating "test" certificates, the generated certificates need to follow the certificate profile described in [n.8], with the modifications as outlined in [9.1.1]. The method of use described in the section below remains same for "test" certificates generated using a different script / method.

6.8.4 Test Procedure

6.8.4.1 Successful TLS connection

In all test cases under this category, the TLS connection is established successfully between the SAS Test Harness and CBSD. A pre-condition for these tests is that Certificates at CBSD and SAS Test Harness are correct and valid. The security procedure is irrespective of the procedures defined for the SAS Test Harness to CBSD communication.

6.8.4.1.1 [WINNF.FT.C.SCS.1] Successful TLS connection between UUT and SAS Test Harness

The following are the test execution steps.

6.8.4.2 Unsuccessful TLS connection

In all test cases under this category, the TLS connection is not established successfully between the SAS Test Harness and CBSD. The security procedure is irrespective of the procedures defined for the SAS Test Harness to CBSD communication.

6.8.4.2.1 [WINNF.FT.C.SCS.2] TLS failure due to revoked certificate

Test case pre-requisite:

The certificate at the SAS Test Harness shall be marked as revoked

The following are the test execution steps.

6.8.4.2.2 [WINNF.FT.C.SCS.3] TLS failure due to expired server certificate

Test case pre-requisite:

Configure the SAS Test Harness such that server certificate is valid but expired.

The following are the test execution steps.

6.8.4.2.3 [WINNF.FT.C.SCS.4] TLS failure when SAS Test Harness certificate is issued by an unknown CA

Test case pre-requisite:

Equip the SAS Test Harness with certificate signed by an unknown CA to the CBSD.

The following are the test execution steps.

6.8.4.2.4 [WINNF.FT.C.SCS.5] TLS failure when certificate at the SAS Test Harness is corrupted

Test case pre-requisite:

The end-entity certificate at the SAS Test Harness shall be corrupted

7 SAS-CBSD/DP Interface Performance Test Specifications

This section includes all performance test cases required for ensuring the UUT conforms by the specifications defined by Winn Forum and directed by the requirements established by the FCC and DOD.

7.1 CBSD RF Power Measurement

7.1.1 Definition and applicability and Scope of Test Case

This section provides test steps, condition and procedures to demonstrate conformance of the CBSD to limitations on transmit power due to maxEirp setting of AUTHORIZED grants for that CBSD.

The methodology to measure RF transmit power of a UUT is out of scope of this document.

7.1.2 Test Characteristics

Table 7-1 CBSD Heartbeat Process Test Characteristics

7.1.3 Method of test

7.1.3.1 Initial Conditions / Test Pre-conditions

• − The pre-conditions of the test case are: CBSD has gone through SAS discovery process and can authenticate with the SAS. The exact condition of the CBSD after the discovery process are detailed in each test case.

7.1.4 Test Procedure

7.1.4.1 UUT RF Transmit Power Measurement Performance Test Case

This test case places the UUT in REGISTERED state, with a grant in AUTHORIZED state, with grant parameters: {lowFrequency, highFrequency, maxEirp}. The maxEirp value is varied by performing multiple iterations of the test case.

To perform this test case, the vendor of the UUT must declare the following parameters:

• 1. Maximum rated power (EIRP, dBm/MHz) for the UUT
• 2. Transmit dynamic range of the UUT (in EIRP, dBm/MHz). The transmit dynamic range is the difference between the largest and smallest transmit power levels over which the device may operate, under SAS approved grant.
• 3. Occupied bandwidth (OBW) of the transmitted signal for the UUT for the test case.
• 4. maxEirp values for the test case. A total of N maxEirp values shall be chosen: maxEirp = {P1, P2, ... PN} across the transmit dynamic range of the UUT.

This may also require declaration of antenna gain and any feeder loss of the product, if conducted power measurements are to be used for measurement.

To demonstrate compliance, the following parameters shall be chosen:

lowFrequency, highFrequency of the grant. These values should correspond to the bandwidth of operation for the test, appropriate to the OBW of signal under test. Where a UUT is capable of multiple bandwidth operation modes, a single bandwidth operation mode shall be chosen for this test.

The test case below shall be performed for each of the maxEirp values: {P1, P2, ... PN}, determining a pass or fail for each. The UUT must comply with the grant maxEirp parameter for each test. Choice of maxEirp values {P1, P2, ... PN} should be made with knowledge of any limitations on UUT power control steps.

The UUT should be configured during the test to apply the maxEirp values to the entire occupied bandwidth and is implicitly expected to not exceed the dBm/MHz grant requirement.

7.1.4.1.1 [WINNF.PT.C.HBT.1] UUT RF Transmit Power Measurement

Given a combination of grant parameters: {lowFrequency = FL, highFrequency= FH, Occupied Bandwidth (OBW), where OBW <= (FH – FL), maxEirp = Pi}, this test case enables the UUT to

obtain a grant with those parameters, to allow verification that the UUT complies to the maxEirp value of the grant.

The test execution steps below will yield a single measurement case. The test steps are to be repeated for each power measurement step, Pi, i = {1...N}.

8 History

V1.0.019 December 2017 Version 1.0.0 balloted and approved by the membership
V1.0.1 September 2018 Minor editorial updates for clarification
V1.0.2 November 2020 Technical clarification on Requirements for UUT supporting several Air Interfaces

9 Appendix

9.1 Test Certificate Generation & Use

This section describes the generation of "test certificates" as per [n.8] and their use for CBSD certification testing. Though the following sections describe and recommend the "test" certificates use for CBSD security procedure verification assuming certificates generated by [i.1] scripts, however, this does not prevent CBSD and SAS Test Harness from using other scripts / methods to generate "test" certificates for use. In case different scripts / methods are used for generating "test" certificates, the generated certificates need to follow the certificate profile described in [n.8], with the modifications as outlined in [9.1.1]. The method of use described in the section below is the same for "test" certificates generated using a different script / method.

9.1.1 Test Certificate Generation

Every execution of [i.1] script is designed to generate "test" certificate for each entityNote-1 – Root CA, Sub-CA, End Entity – of the CBRS PKI Hierarchy in [n.8], shown below:

Note-1: Current WInnForum GitHub cert repo scripts do not generate PAL CA and PAL end entity certificates.

Following are the key files in WInnForum GitHub cert repo for generation of test certificates:

• Openssl.conf this is a configuration file for the cert generation scripts. This file provides configuration for the Role OIDs as per [n.8] and other certificate fields like CN, policy id, basic constraints for different certificates etc.

• CACreationScript.sh this is Linux cert generation script. This script generates RSA "test" certificates for the following CBRS PKI hierarchy entities:

• CBRS Root CA

  • Sub-CAs signed by Root CA SAS Provider CA, Domain Proxy CA (with Operator Role OID), Professional Installer CA, CBSD Manufacturer CA
  • Sub-CA signed by higher order Sub-CA (CBSD Manufacturer CA): CBSD OEM CA
  • End Entity signed by respective Sub-CA SAS Provider, Domain Proxy, Installer, CBSD OEM (signed by CBSD OEM CA), CBSD (signed by CBSD Manufacturer CA)

• PowerShell\_CACreationScript.ps1 this is Windows cert generation script. This script generates the same set of "test" certificates as CACreationScript.sh.

Note: Scripts in [i.1] generate only RSA certificates. If a CBSD vendor implementation uses ECC certificates as per profile defined in [n.8], then CBSD vendor can either enhance these scripts or develop new scripts/methods for the same.

Following options are provided for key-pair to be used for "test" certificate generation:

• CA, Sub-CA certificates: Auto-generated key-pair is used. The script first uses "openssl" command to auto-generate the key pair and then uses the same to generate the "test" certificate.
• Installer end-entity certificate: Auto-generated key-pair is used.
• CBSD OEM, CBSD, DP and SAS provider end-entity certificate: 2 options are provided: Auto-generated key pair option is the default CBSD vendor can provide the key-pair on the script command-line and the same would be used to generate the CBSD and CBSD OEM certificates For DP entity certificate, CBSD vendor can provide the key-pair on the script command-line and the same would be used to generate the certificate SAS vendor can provide the key-pair on the script command line and the same would be used to generate the SAS Provider certificate

In the "test" certificates, WInnForum Poison extension (TEST OID 1.3.6.1.4.1.46609.1.999) is present as a critical extension with ASN.1 encoded NULL data (0x05 0x00)

• Presence of TEST OID in the "test" cert allows a production / deployed CBRS peer entity to reject the TLS connection when presented with "test" certificate
• A peer entity, not conforming to WInnForum CBRS PKI specification, shall reject the TLS connection request since it would not be able to identify the TEST OID critical extension

The "test" certificates for CBRS PKI entities are ".pem" format and follow the RSA certificate profile as per [n.8] with the following exceptions:

• X.509v3 Certificate policy ID value references "https://www.digicert.com/CPS" in future it would reference WInnForum CBRS PKI CP. However, this does not impact any of the CBSD certification test case.
• Some of the fields in Subject DN are fixed (through configuration file) example: State, OU, CN fields. These fixed values do not impact any of the CBSD certification test case.
• CBSD / CBSD OEM end entity certificate CN field does not contain the Device-id (of the form :) specified in RSA subscriber certificate profile in [n.8]. Instead, CN has a fixed value string, in the absence of availability of FCC-id for unit under certification test.
• Domain Proxy end entity certificate CN field does not contain the Device-id (of the form :) specified in RSA subscriber certificate profile in [n.8]. Instead, CN has a fixed value string, in the absence of availability of FRN for DP under certification test.
• SAS end entity certificate CN field does not contain the Device-id (of the form ) specified in RSA subscriber certificate profile in [n.8]. Instead, CN has a fixed value string.

Note: Generated certificates do not contain some optional and non-critical fields like Subject Alt Name, CRL Distribution Point (so no CRL or OSCP server links to check the certificate revocation status).

Each execution of the CACreationScript.sh generates certificates having a new certificate serial number, validity duration (starting with current system time), key-pair (auto-generated case only) and the digital signature though the rest of the fields including Subject DN and CN remain the same.

Following is a sample of CBSD End entity "test" certificate generated by the CACreationScript.sh script and openssl.conf file:

Certificate:
 Data:
 Version: 3 (0x2)
 Serial Number: 18083089253031301825 (0xfaf409de089d52c1)
 Signature Algorithm: sha384WithRSAEncryption
 Issuer: C=US, ST=District of Columbia, L=Washington, O=Wireless Innovation Forum, 
OU=www.wirelessinnovation.org, CN=WInnForum RSA CBSD CA-1
 Validity
 Not Before: Jul 17 06:13:04 2017 GMT
 Not After : Oct 14 06:13:04 2020 GMT
 Subject: C=US, ST=District of Columbia, L=Washington, O=Wireless Innovation Forum, 
OU=www.wirelessinnovation.org, CN=CBSD End-Entity Example
 Subject Public Key Info:
 Public Key Algorithm: rsaEncryption
 Public-Key: (2048 bit)
  Modulus:
 00:c1:09:b7:a8:9b:21:5d:2a:86:e4:c1:b7:f0:cd:
       ………………………..
 0a:e1
 Exponent: 65537 (0x10001)
 X509v3 extensions:
 X509v3 Subject Key Identifier: 
 BB:9C:7E:1C:2C:33:34:48:2F:AB:8A:D5:55:CC:7C:A4:D3:03:D4:65
 X509v3 Authority Key Identifier: 
 keyid:A1:AE:7F:EA:CF:C5:F6:46:5D:F6:83:65:FD:4A:92:46:A2:26:18:02
 X509v3 Basic Constraints: 
 CA:FALSE
 X509v3 Key Usage: critical
 Digital Signature, Key Encipherment
 X509v3 Extended Key Usage: 
 TLS Web Server Authentication
 X509v3 Certificate Policies: 
 Policy: 2.16.840.1.114412.2.1
 CPS: https://www.digicert.com/CPS
 Policy: ROLE_CBSD
 TEST: critical
 ………………………………..
 Signature Algorithm: sha384WithRSAEncryption
 fa:49:98:aa:95:35:07:92:a9:8b:d3:7e:bd:0d:02:31:ab:00:
 …………………………….
 aa:77:4b:a6:92:41:05:44
-----BEGIN CERTIFICATE-----
MIIFujCCA6KgAwIBAgIJAPr0Cd4InVLBMA0GCSqGSIb3DQEBDAUAMIGsMQswCQYD
……………………………………………..
……………………………………………..
XY0xMJyUDPxRu8caQuxeUDVAgBJP/6p3S6aSQQVE
-----END CERTIFICATE-----
                                                        Fixed Value. Actual cert would contain 
                                                        <FCC ID>:<device serial #>
                                                       TEST OID critical extension with ASN.1 
                                                       encoded NULLL value
                                                        .PEM certificate

9.1.2 Test Certificate Use

UUT and the simulated entities in the SAS Test Harness setup a secure connection using the "Test" certificates for mutual authentication.

"Test" certificates generated as per [i.1] or different method/scripts need to be installed in CBSD/DP and the SAS Test Harness before use. Following are some key points before the use of the "test" certificates:

• Complete certificate chain from end entity certificate to the Root CA certificate needs to be installed at CBSD, DP (if used) and at the SAS Test Harness.
• CBSD vendor needs to install only one of the CBSD EE or the CBSD OEM EE certificates. If CBSD vendor uses CBSD OEM EE certificate, then CBSD vendor also needs to install the CBSD OEM CA certificate.
• CBSD Vendor & Tester needs to ensure that the same Root CA certificate part of the trust chain of the CBSD/DP/SAS entity certificate is installed at CBSD, DP and the SAS Test Harness.
• If CBSD vendor implementation requires verification of SAS Root CA certificate hash, then CBSD vendor needs to calculate the hash of above generated Root CA certificate and store that as well at CBSD / DP.

Note: Installation of the CBSD, DP certificates is specific to Vendor implementation.

Although "test" certificates generated as per [i.1] are valid certificates, still the SAS Test Harness should perform the verification of "test" certificate from CBSD/DP and reject the TLS connection, logging an error, if any of these checks fail. CBSD/DP shall always verify the SAS Test Harness "test" certificate.

Verification of the "Test" certificates by entities involved in secure connection comprises following:

• Verification of the validity period of the certificate
• Verification of the Digital signature of the certificate this is done through following steps: Calculate the HMAC of the entity certificate using signature algorithm indicated in the certificate Decrypt the signature (HMAC) using the public key contained in the certificate Compare the HMAC calculated above with the decrypted HMAC to verify both the integrity of the certificate and that it belongs to the peer entity owning the private key of the key-pair.
• CBSD, DP and SAS Test Harness need to verify the complete certificate chain from the peer entity. CBSD, DP and SAS Test Harness also need to verify the Root CA certificate or its hash is same as stored / installed at its end.
• Verification of the presence of TEST OID critical extension. A test unit should check for the presence of the TEST OID in the peer certificate to ensure that peer entity is part of the test ecosystem. (Note: A production unit would treat TEST OID as unrecognized critical extension OID or as a tagging a "test" certificate. In either case, the production unit would reject the peer certificate thus preventing interaction with a test unit).
• CBSD, DP may optionally verify the SAS Role present in the certificate.

Some certificate verification checks, that a production CBSD, DP or SAS performs cannot be done on the "test" certificates. UUT, working with "test" certificates, need to bypass these checks and not fail peer authentication. Following are the checks which need to be bypassed:

• Verification of the device-id value (eg: :, : etc.) in Subject DN -> CN field.
• Verification of certificate revocation status

Test certificates for verification of CBSD behavior due to invalid SAS Test Harness certificate: CBSD is required to check that the SAS Test Harness certificate is signed by a WInnForum approved CBRS PKI Root CA. CBSD also needs to verify that the duration of the SAS Test Harness certificate is also valid as described above. To enable verification of such behavior at CBSD, corrupted, invalid and different Root CA signed certificates are placed in same directory in WInnForum GitHub repository as the test scripts for security validation. When executing these test cases (described in the following sections), tester needs to install these corrupt certificates at the SAS Test Harness.