Stay organized with collections
Save and categorize content based on your preferences.
The current version of the Spectrum Access System (SAS) test suite is v5.5. You
can test the interoperability between a Citizens Broadband Radio Service Device (CBSD) and
SAS by using the following test cases. Make sure that you
validate the test result in the Test Result spreadsheet provided by Google.
Requirements for SAS interoperability testing
To test SAS interoperability with a SAS model and
its software version, you need the following:
The test ID must be valid as per
Part 96 FCC ID.
For devices awaiting FCC certification, contact SAS
Support.
Test user IDs
If you're a Google SAS customer, use your existing user ID.
If you're not a customer and want to test your device, contact
SAS Support
to approve a custom user ID to use with the SAS test environment.
Device test certificates
Any CBRS device certificate works with the test
SAS environment. If you don't have a test certificate for
your CBSD or Domain Proxy (DP) device,
contact SAS Support.
The test certificates work for only the SAS test
environment.
Test case 1: CBSD registration, spectrum inquiry, grant, and heartbeat (normal operation)
This test case verifies the following:
CBSD registration procedure, grant procedure, and the first
successful heartbeat to turn on the radio.
Optionally, if CBSD sends a spectrum inquiry request, then the CBSD uses
the available channels in the spectrum inquiry response for the following grant
request.
WInnForum recognized CBRS grouping parameters
The groupingParam object array is optional and is used by Google
SAS only for General Authorized Access (GAA) coexistence
purposes.
We recommend that the CBSD sends groupingParam in the
registration request whenever possible. Because SAS accepts the
groupingParam array in the spectrum inquiry request, grant request, and
heartbeat request, the subsequent information provided by the
CBSD overrides the previous values.
A list of valid groupType values has been published in
WINNF-SSC-0010.
If the CBSD sends an invalid groupType, the SAS
responds with responseCode 103 (Invalid_value). Currently,
SAS supports the groupType values Principal_Subordinate_SFG
and Spectrum_Reuse. It stores and uploads grouping parameters to the
SAS Portal. SAS ignores
any other valid groupType values with responseCode 0 (Success).
Prerequisites
Make sure that the CBSD is not registered in the
SAS Portal and is not set to request a subset of the spectrum that is
available.
Steps
Verify the following steps:
The CBSD sends a registration request to SAS
with the FCC ID and the user ID. You can use any certified FCC ID or one that
has been confirmed along with the user ID and added to the allowlist by
SAS Support.
Learn how to connect to the test SAS environment.
Example 1: Category A CBSD single-step registration request
The CBSD sends a grant request to SAS. If a
spectrum inquiry was carried out, then the CBSD requests a frequency range
that SAS indicated is available.
If the previous heartbeat request was approved, the CBSD sends
subsequent heartbeat requests to SAS periodically based on
heartbeatInterval with the operationState field set to Authorized.
The expected results from the test are listed in the following table.
Table 2. Test case 2
Receives
Sends
Acceptable
SAS
Optional: Relinquishment request
Deregistration request
Optional: Relinquishment response
Deregistration request
CBSD
Optional: Relinquishment response
Deregistration request
Optional: Relinquishment request
Deregistration request
Stops transmitting before sending a deregistration or a relinquishment request
Test case 3a: Grant suspension: IAP pending
This test case verifies the following:
The CBSD radio turns off when SAS suspends
the CBSD's grant.
The CBSD reports the correct operation state in subsequent
heartbeat requests.
Prerequisites
A CBSD in the US has channels with limited power availability.
Some locations like Tampa, Florida and Los Angeles, California have power
budgets that are less than 37 dBm/MHz. To make it easier to simulate the
test scenario for locations along the coast, turn on the Spectrum availability
overlay for the CBRS.
Make sure that the following is true:
The CBSD sends a grant request with a maxEirp value less than
the channel's available power in dBm/MHz.
Example
{
"grantRequest":[
. . .
{
"operationParam":{
"maxEirp":25, (e.g. Assume Partial power available for
2670-2680=28dBm/MHz)
"operationFrequencyRange":{
"lowFrequency":3670000000,
"highFrequency":3680000000
. . .
}
}
]
}
The CBSD sends heartbeat requests. If the requested maxEirp
is less than or equal to partial power, SAS approves the grant.
Example 1: The first heartbeat request after a grant is approved
The CBSD sends a spectrum inquiry for the channels with
partial power. In the spectrum inquiry response, CBSD finds
the available maxEirp value in dBm on the relevant channels.
The CBSD sends a grant request with maxEirp greater than
the available power for the channels in the spectrum inquiry response.
The CBSD sends a heartbeat request.
SAS sends the heartbeat response with responseCode 501
(Suspended_Grant: IAP Pending).
Example 1: Spectrum inquiry response for an available channel with partial power
The expected results from the test are listed in the following table.
Table 3a. Test case 3a
Receives
Sends
SAS
Heartbeat requests with operationState set to
Granted after CBSD is notified that the grant has
been suspended through the heartbeat response
Heartbeat requests with operationState set to
Authorized after the CBSD is notified through the
heartbeat response that the grant has been authorized
Heartbeat responses with responseCode 0 (Success)
when the grant is not suspended
Heartbeat responses with responseCode 501
(Suspended_Grant:IAP Pending) when the grant is suspended
CBSD
Heartbeat responses with responseCode 0
(Success), as long as the suspension zone isn't
active
Heartbeat responses with responseCode 501
(Suspended_Grant), until the current grant expires and a
new grant is requested, or until additional power is available after a
CPAS cycle
The CBSD stops the transmission (turns off the radio)
less than 60 seconds after the transmitExpireTime
Heartbeat requests with operationState set to
Authorized after the CBSD is notified that the
grant has been authorized through the heartbeat response
Subsequent heartbeat requests that have operationState
set to Granted after the CBSD is notified that the
grant has been suspended through the heartbeat response
Optional: Spectrum Inquiry request to determine which channels are available
The interference calculations are complete, but SAS can't
authorize transmission with the grant because after CPAS, the
CBSD's grant is terminated and the use of low power is suggested. The
CBSD requests a grant after it receives the operation parameters
from the terminating heartbeat response.
We strongly recommend that the CBSD requests a new grant. If the
grant request is for a frequency range outside of the suspension zone's
frequency range , CBSD receives authorization to transmit in the
heartbeat response. If authorized, the CBSD resumes transmission
with a new grant. After the suspension is lifted, the CBSD resumes
transmission on the original grant and ends the interim grant. For more
information , see Troubleshoot issues with interoperability testing.
Test case 3b: Grant suspension: DPA move list activated
This test case verifies the following:
The CBSD radio turns off when SAS suspends
the CBSD's grant.
The CBSD reports the correct operation state in subsequent
heartbeat requests.
Prerequisites
Make sure that the following is true:
The CBSD is registered at a location inside the simulated suspension zone.
SAS suspends the grant when the suspension zone is active, as
specified in the suspension zone schedule.
The CBSD sends a heartbeat request.
SAS sends the heartbeat response with responseCode 501
(Suspended_Grant : IAP Pending, "The grant is suspended because it is in the
move list of a DPA that has been activated").
Optional: The CBSD sends a spectrum inquiry request after the
grant is suspended.
Example 1: Heartbeat response when the suspension zone is active
{
"heartbeatResponse":[
{
"cbsdId":"SAS-assigned device ID",
"grantId":"SAS-assigned grant ID",
"response":{
"responseCode":501,
"responseMessage":"SUSPENDED_GRANT : The grant is suspended because it is in the move list of a DPA that has been activated."
responseData = ["The grant is suspended because it is in the move list of a DPA that has been activated."]
}
}
]
}
Example 2: Heartbeat request when the grant is suspended
The expected results from the test are listed in the following table.
Table 3b. Test case 3b
Receives
Sends
SAS
Heartbeat requests with operationState set to
Granted after CBSD is notified that the grant has
been suspended through the heartbeat response
Heartbeat requests with operationState set to
Authorized after the CBSD is notified through the
heartbeat response that the grant has been authorized
Heartbeat responses with responseCode 0 (Success)
when the suspension zone is not active
Heartbeat responses with responseCode 501
(Suspended_Grant: The grant is suspended because it is in the
move list of a DPA that has been activated.") when the
suspension zone is active
CBSD
Heartbeat responses with responseCode 0 (Success) for
as long as the suspension zone isn't active
Heartbeat responses with responseCode 501
(Suspended_Grant: The grant is suspended because it is in the
move list of a DPA that has been activated.) for as long as
the suspension zone is active
The CBSD stops the transmission, (turns off the radio)
less than 60 seconds after the transmitExpireTime
Heartbeat requests with operationState set to
Authorized after the CBSD is notified through the
heartbeat response that the grant has been authorized
Subsequent heartbeat requests that have operationState set to
Granted after the CBSD has been notified through the
heartbeat response that the grant has been suspended
Optional: Spectrum inquiry request to determine which channels are available.
We strongly recommend that the CBSD requests a new grant. If the
grant request is for a frequency range outside of the suspension zone's
frequency range, CBSD receives authorization to transmit in the
heartbeat response. If authorized, the CBSD resumes transmission
with a new grant. Throughout the transmission, CBSD continues to
heartbeat on the original (suspended) grant. After the suspension is lifted,
CBSD resumes transmission on the original grant and terminates the
interim grant.
Test case 4: Grant reauthorization
This test case verifies that the CBSD can resume transmission
after the suspension zone is deactivated. The CBSD behavior
verified in this test is similar to what happens when the CBSD
grant is suspended due to DPA protection and then reauthorized after the DPA is
deactivated.
Prerequisites
Make sure that the following is true:
The CBSD is registered at a location inside the suspension
zone. For more information, see
suspension zone.
The expected results from the test are listed in the following table.
Table 6. Test case 6
Receives
Sends
SAS
Grant request
Grant response with responseCode 400 (Interference)
In this case, the CBSD is inside
the GWPZ and is requesting a grant on a protected frequency, but it can be for any
other reason.
CBSD
Grant response with responseCode 400 (Interference)
The CBSD should not start heartbeating or transmitting.
Grant request
Test case 7: CBSD deregistration and re-registration
This test case verifies that the CBSD deregisters itself from
SAS and re-registers when it is moved from one location to
another location more than 50 meters away.
Prerequisites
Make sure that the CBSD is registered, has a grant, and is heartbeating.
Example: CBSD coordinates in the initial registration request
Set the CBSD position to another location selected more than
50 meters away. This can be done by either physically moving it or by setting
its location manually.
The CBSD optionally sends a deregistration request due to the change in location.
The expected results from the test are listed in the following table.
Table 8. Test case 8
Receives
Sends
SAS
Heartbeat request that also requests grant renewal
Heartbeat response that contains a new grantExpireTime value
CBSD
Heartbeat response that contains a new grantExpireTime value
Heartbeat request with grantRenew set to true before the grant expires
Test case 9: CBSD handling of invalid or missing values
This test case shows examples of invalid requests. The CBSD does
not need to follow the instructions step-by-step, but the tester should verify that after
the CBSD receives a response code indicating that there is an error in
the request, it does not retry the same (invalid) request.
Prerequisites
Make sure that the CBSD is not registered in SAS.
Steps
The CBSD sends a registration request to SAS.
Example 1: Requests with errors
The FCC ID field in strike-through text is omitted in the request,
even though it's required for CBSD registration.
{
"registrationRequest":[
{
"fccId":"whitelisted FCC ID",
"userId":"whitelisted user ID",
"cbsdSerialNumber":"<unique device ID>",
"cbsdCategory":"A",
"airInterface":{
"radioTechnology":"E_UTRA"
},
"installationParam":{
"latitude": latitude within US,
"longitude": longitude within US,
"height":9,
"heightType":"AGL",
"indoorDeployment":false,
"antennaGain":16
},
"cbsdInfo":{
"vendor": "CBSD Vendor 1",
"model": "CBSD Model 1",
"softwareVersion": "2.0",
"hardwareVersion": "2.0",
"firmwareVersion": "2.0"
}
}
]
}
Example 2: A second registration request with latitude and longitude values
set to 0 (zero)
This is to test CBSD handling of invalid data. The CBSD is expected to
correct the fields before resending the request.
The expected results from the test are listed in the following table.
Table 9. Test case 9
Receives
Sends
Acceptable
SAS
Registration request without the necessary fields specified or with invalid values
One of the following:
Registration response with responseCode 102
(Missing_Param) and missing parameters in the
responseData field
Registration response with responseCode 103
(Invalid_Value) and the parameters with invalid values in the
responseData field
CBSD
Registration response with non-zero response code
Incomplete or invalid registration request
The CBSD must not try the same request until the error is fixed.
Test case 10: CBSD measurement reporting for RECEIVED_POWER_WITHOUT_GRANT
This test verifies that the CBSDs that support the
Received_Power_Without_Grant measurement capability send measurement reports
as prescribed in WINNF-17-SSC-0002.
Prerequisites
Make sure that the CBSD is not registered.
Steps
Verify the following steps:
The CBSD sends a registration request to SAS
that includes Received_Power_Without_Grant as one of its measurement
capabilities.
SAS replies with a registration response that includes
Received_Power_Without_Grant in the measurement report configuration.
Optional: The CBSD sends a spectrum inquiry request that contains a
valid measurement.
If the spectrum inquiry request is sent, SAS sends a spectrum inquiry
response with responseCode 0.
The CBSD sends a grant request that contains a valid measurement.
SAS sends a grant response with responseCode 0.
Result
The expected results from the test are listed in the following table.
Table 10. Test case 10
Receives
Sends
SAS
Registration request that includes
Received_Power_Without_Grant as one of the measurement
capabilities
Optional: Spectrum inquiry request that contains a valid measurement
Grant request that contains a valid measurement
Registration response
Optional: Spectrum inquiry response
Grant response
CBSD
Registration response
Optional: Spectrum inquiry request
Grant request that contains a valid measurement
Grant response
Registration request
Optional: Spectrum inquiry request that contains a valid measurement
Grant request that contains a valid measurement
Test case 11: CBSD measurement reporting for RECEIVED_POWER_WITH_GRANT
This test verifies that the CBSDs that support the
Received_Power_With_Grant measurement capability send measurement reports as
prescribed in WINNF-17-SSC-0002.
Prerequisites
Make sure that the CBSD is not registered.
Steps
Verify the following steps:
The CBSD sends a registration request to SAS
that includes Received_Power_With_Grant as one of its measurement
capabilities.
SAS replies with a registration response with responseCode 0.
Optional: The CBSD sends a spectrum inquiry request.
SAS sends a spectrum inquiry response with responseCode 0.
The CBSD sends a valid grant request.
SAS sends a grant response that includes
Received_Power_With_Grant in the measurement report configuration.
Within the first five heartbeat requests, the CBSD sends at
least one request that contains a valid measurement.
SAS sends heartbeat responses with responseCode 0.
Result
The expected results from the test are listed in the following table.
Table 11. Test case 11
Receives
Sends
Acceptable
SAS
Registration request from the CBSD that includes
Received_Power_With_Grant as one of the measurement
capabilities
Optional: A spectrum inquiry request
Valid grant request from the CBSD
Any number of heartbeat requests, with at least one of the first five
containing a valid measurement
Registration response
Optional: Spectrum inquiry response
Grant response that includes Received_Power_With_Grant in
the measurement report configuration
Heartbeat response(s) with responseCode 0
CBSD
Registration response
Optional: Spectrum inquiry request
Grant response
Registration request that includes
Received_Power_With_Grant as one of the measurement
capabilities
Optional: Spectrum inquiry request
Grant request
Any number of heartbeat requests, with at least one of the first five
containing a valid measurement
After the first successful heartbeat, the CBSD starts
transmission on the corresponding channel and power.
Test case 12: Batch requests
This test case verifies that a Domain Proxy (DP) is capable of sending batch
requests and receiving batch responses for multiple CBSDs.
In particular, this test case focuses on the following:
The batch spectrum query for multiple CBSDs
The batch grant procedure for multiple CBSDs
The first batch heartbeat to turn the radios on for multiple CBSDs
Prerequisites
Make sure that the following is true:
The CBSDs are registered with SAS.
The DP is set to request a subset of the spectrum that is available.
Steps
Verify the following steps:
The DP sends a batch spectrum query request to check available
spectrum for each CBSD.
{
"grantResponse":[
{
"cbsdId":"SAS-assigned device ID #1",
"grantId":"SAS-assigned grant ID #1",
"grantExpireTime":"YYYY-MM-DDTHH:MM:SSZ",
"heartbeatInterval":60,
"channelType": GAA,
"response":{
"responseCode":0
}
},
{
"cbsdId":"SAS-assigned device ID #2",
"grantId":"SAS-assigned grant ID #2",
"grantExpireTime":"YYYY-MM-DDTHH:MM:SSZ",
"heartbeatInterval":60,
"channelType": GAA,
"response":{
"responseCode":0
}
},
...
{
"cbsdId":"SAS-assigned device ID #N",
"grantId":"SAS-assigned grant ID #N",
"grantExpireTime":"YYYY-MM-DDTHH:MM:SSZ",
"heartbeatInterval":60,
"channelType": GAA,
"response":{
"responseCode":0
}
}
]
}
The DP sends batch heartbeat requests to SAS
periodically based on the heartbeatInterval and receives batch heartbeat
responses from SAS.
Example
{
"heartbeatRequest":[
{
"cbsdId":"SAS-assigned device ID #1",
"grantId":"SAS-assigned grant ID #1",
"operationState":"GRANTED"
},
{
"cbsdId":"SAS-assigned device ID #2",
"grantId":"SAS-assigned grant ID #2",
"operationState":"GRANTED"
},
...
{
"cbsdId":"SAS-assigned device ID #N",
"grantId":"SAS-assigned grant ID #N",
"operationState":"GRANTED"
}
]
}
SAS responds by approving the heartbeat requests.
Example
{
"heartbeatResponse":[
{
"cbsdId":"SAS-assigned device ID #1",
"grantId":"SAS-assigned grant ID #1",
"response":{
"responseCode":0
},
"transmitExpireTime":"YYYY-MM-DDTHH:MM:SSZ"
},
{
"cbsdId":"SAS-assigned device ID #2",
"grantId":"SAS-assigned grant ID #2",
"response":{
"responseCode":0
},
"transmitExpireTime":"YYYY-MM-DDTHH:MM:SSZ"
},
...
{
"cbsdId":"SAS-assigned device ID #N",
"grantId":"SAS-assigned grant ID #N",
"response":{
"responseCode":0
},
"transmitExpireTime":"YYYY-MM-DDTHH:MM:SSZ"
}
The DP sends subsequent batch heartbeat requests to SAS
periodically based on the heartbeatInterval with the field operationState,
which belongs to any particular CBSD set to Authorized if the
previous heartbeat request was approved.
Example
{
"heartbeatRequest":[
{
"cbsdId":"SAS-assigned device ID #1",
"grantId":"SAS-assigned grant ID #1",
"operationState":"AUTHORIZED"
},
{
"cbsdId":"SAS-assigned device ID #2",
"grantId":"SAS-assigned grant ID #2",
"operationState":"AUTHORIZED"
},
...
{
"cbsdId":"SAS-assigned device ID #N",
"grantId":"SAS-assigned grant ID #N",
"operationState":"AUTHORIZED"
}
]
}
Result
The expected results from the test are listed in the following table.
Table 12. Test case 12
Receives
Sends
SAS
Valid batch spectrum inquiry request, including one request for each
CBSD
Valid batch grant request, including one request for each CBSD
Valid periodic batch heartbeat requests, including one request for
each CBSD at least every heartbeatInterval
seconds
Successful batch responses to all batch requests. The
transmitExpire time in the heartbeat responses is set to a
value during four minutes.
DP
Successful batch responses to all batch requests
After the first successful heartbeat response, each
CBSD starts transmission on the corresponding channel and
power
Valid batch spectrum inquiry request, including one request for each CBSD
Valid batch grant request, including one request for each CBSD
Valid periodic batch heartbeat requests at least every
heartbeatInterval second, including one request for each
CBSD. The field operationState that belongs
to any particular CBSD should be set to
Authorized in at least one heartbeat request.
Test case 13: Oversized batch requests
This test case verifies that a Domain Proxy (DP) is capable
of handling a situation where the size of a batch request exceeds the maximum
batch size that is processed by SAS.
When the batch size is larger than maxBatchSize, SAS sends a
valid response to the first maxBatchSize requests with the responseCode
field set to 0 (Success). For the remainder of the requests,
SAS sends responseCode 106 (Not_Processed).
The default value of maxBatchSize in the production SAS environment
is 120. To support easy testing, the maxBatchSize in the test SAS
environment is 20.
In particular, this test case focuses on the grant request process to
demonstrate how to handle oversized batch requests.
We recommend that you extend this test case to include other message types, such
as registration requests, spectrum inquiry, heartbeat procedure, grant
relinquishment procedure, and deregistration.
Prerequisites
Make sure that the following is true:
The CBSDs are registered with SAS.
The DP is set to request a subset of the spectrum that is available.
Steps
Verify the following steps:
The DP sends an oversized batch grant request to SAS. The size
of the batch is N, where N is from 20 to 40. For each CBSD, the DP
requests a frequency range that SAS specified was available.
The DP receives a batch grant response from SAS.
SAS sends a valid response to the first 20 requests with the
responseCode field set to 0 (Success). SAS sets the
responseCode field to 106 (Not_Processed) for the last N to 20 items in
the batch.
Example
{
"grantResponse":[
{
"cbsdId":"SAS-assigned device ID #1",
"grantId":"SAS-assigned grant ID #1",
"grantExpireTime":"YYYY-MM-DDTHH:MM:SSZ",
"heartbeatInterval":60,
"channelType": GAA,
"response":{
"responseCode":0
}
},
{
"cbsdId":"SAS-assigned device ID #2",
"grantId":"SAS-assigned grant ID #2",
"grantExpireTime":"YYYY-MM-DDTHH:MM:SSZ",
"heartbeatInterval":60,
"channelType": GAA,
"response":{
"responseCode":0
}
},
...
{
"cbsdId":"SAS-assigned device ID #20",
"grantId":"SAS-assigned grant ID #20",
"grantExpireTime":"YYYY-MM-DDTHH:MM:SSZ",
"heartbeatInterval":60,
"channelType": GAA,
"response":{
"responseCode":0
}
},
{
"cbsdId":"SAS-assigned device ID #21",
"response":{
"responseCode":106,
"responseMessage":"The Google SAS requires that each request batch size be less than or equal to 20"
}
},
{
"cbsdId":"SAS-assigned device ID #22",
"response":{
"responseCode":106,
"responseMessage":"The Google SAS requires that each request batch size be less than or equal to 20"
}
},
...
{
"cbsdId":"SAS-assigned device ID #N",
"response":{
"responseCode":106,
"responseMessage":"The Google SAS requires that each request batch size be less than or equal to 20"
}
}
]
}
The DP sends the grant requests that have not yet been processed.
Example
The size of this batch request is less than 20 by design.
The DP receives a batch grant response from SAS.
SAS sends a valid response to all requests with the
responseCode field set to 0 (Success).
Example
{
"grantResponse":[
{
"cbsdId":"SAS-assigned device ID #21",
"grantId":"SAS-assigned grant ID #21",
"grantExpireTime":"YYYY-MM-DDTHH:MM:SSZ",
"heartbeatInterval":60,
"channelType": GAA,
"response":{
"responseCode":0
}
},
{
"cbsdId":"SAS-assigned device ID #22",
"grantId":"SAS-assigned grant ID #22",
"grantExpireTime":"YYYY-MM-DDTHH:MM:SSZ",
"heartbeatInterval":60,
"channelType": GAA,
"response":{
"responseCode":0
}
},
...
{
"cbsdId":"SAS-assigned device ID #N",
"grantId":"SAS-assigned grant ID #N",
"grantExpireTime":"YYYY-MM-DDTHH:MM:SSZ",
"heartbeatInterval":60,
"channelType": GAA,
"response":{
"responseCode":0
}
}
]
}
Result
The expected results from the test are listed in the following table.
Table 13. Test case 13
Receives
Sends
SAS
Valid batch grant request, including one request for each
CBSD for a batch size of 20 to 40 in the first
attempt
Valid batch grant requests for the second part to the batch in the
second attempt where the batch size is more than 20
Successful batch responses to the first 20 grant requests, and
responseCode 106 for the rest of the batch in the first
attempt
Successful batch responses to all grant requests in the second attempt
DP
Successful batch responses to the first 20 requests, and
responseCode 106 for the rest of the batch in the first
attempt
Successful batch responses to all grant requests in the second attempt
Valid batch grant request, including one request for each
CBSD for a batch size of 20 to 40 in the first attempt
Valid batch grant requests for the second part to the batch in the
second attempt where the batch size is more than 20
Test case 14: Passive DAS registration and grant procedure
This test case verifies the following:
The registration and grant procedure for Passive DAS
radio equipment.
Optional: The spectrum inquiry process for Passive DAS
radio equipment.
Assumptions
Deployment scenario
In this test case, we assume a Category 3 deployment scenario as defined in
WINNF-TR-5001:
A single-sector Radio Unit (RU) deployed as a Passive DAS with multiple
transmission points (TPs).
Unique CBSD identification
In this case, each TP is registered as a single CBSD with the
FCC ID and the manufacturer's serial number (MSN). The FCC ID and MSN of the
RU is combined with an extra TP ID to uniquely identify each TP. The TP ID can
be provided to SAS with suffixes in the cbsdSerialNumber. The
TP ID must be appended to the MSN of the RU with a delimiter character (:)
before the TP ID. For more information, see WINNF-TR-5001.
Indoor or outdoor determination
In this test case, we assume an indoor deployment scenario. In general, you can
deploy Passive DAS equipment either indoors or outdoors. To find the complete
list of guidelines, see
WINNF-TR-5001.
EIRP capability
For an indoor deployment, the max EIRP of each TP must be less than or equal
to 30 dBm or 10 MHz. To find examples of how to calculate the EIRP
capability for each TP, see WINNF-TR-5001.
CBSD category
For an indoor deployment, each TP must be registered as a Category A
CBSD. This can be done even if the RU is originally certified
by the FCC as a high-power Category B device. You cannot install Category B
CBSDs indoors.
CPI-assisted installation
Current FCC guidance suggests that a Certified Professional Installer (CPI)
must always install Passive DAS equipment. The reasons are as follows:
The FCC recommends CPI installation whenever you deploy a high-power
Category B RU in an indoor environment with reduced power as a Category A
CBSD.
Even if the RU is certified as a low-power Category A device, a typical TP
doesn't have automatic geolocation capability. Therefore, a CPI must always
install a Passive DAS.
Multistep registration
In this test case, we assume multistep registration. This means that before
executing the test, a CPI must pre-load installation parameters for each TP
into SAS through the SAS Portal. It's important
that the CPI specifies the eirpCapability parameter in the
InstallationParam object.
For this test case, eirpCapability must be set
to no greater than 30 dBm or 10 MHz for each TP. If not included, in
accordance with the Release 1 WInnForum specification WINNF- TS-0016,
SAS sets eirpCapability as the rounded up FCC certified
maximum EIRP of the RU. For a high-power RU, this can be greater than
30 dBm or 10 MHz, which isn't allowed for an indoor Category A
installation.
Domain Proxy (DP)
In this test case, we assume the presence of a DP that can send and receive
batch requests from SAS.
Prerequisites
Make sure that the following is true:
The CBSDs (TPs) are not registered in the SAS Portal.
The CBSDs (TPs) are set to request a subset of the spectrum
that is available.
The CPI provided registration parameters, including eirpCapability for each TP,
which are preloaded into SAS through the SAS Portal.
Steps
Verify the following steps:
To register multiple TPs, the DP sends a batch registration request
to SAS.
Example
{
"registrationRequest":[
{
"fccId":"allowed FCC ID of RU",
"userId":"allowed user ID",
"cbsdSerialNumber":"MSN of RU:TP ID #1",
"cbsdCategory":"A",
"airInterface":{
"radioTechnology":"E_UTRA",
},
"cbsdInfo":{
"vendor": "CBSD Vendor of RU",
"model": "CBSD Model of RU",
"softwareVersion": "2.0",
"hardwareVersion": "2.0",
"firmwareVersion": "2.0"
}
},
{
"fccId":"allowed FCC ID of RU",
"userId":"allowed user ID",
"cbsdSerialNumber":"MSN of RU:TP ID #2",
"cbsdCategory":"A",
"airInterface":{
"radioTechnology":"E_UTRA",
},
"cbsdInfo":{
"vendor": "CBSD Vendor of RU",
"model": "CBSD Model of RU",
"softwareVersion": "2.0",
"hardwareVersion": "2.0",
"firmwareVersion": "2.0"
}
},
...
{
"fccId":"allowed FCC ID of RU",
"userId":"allowed user ID",
"cbsdSerialNumber":"MSN of RU:TP ID #N",
"cbsdCategory":"A",
"airInterface":{
"radioTechnology":"E_UTRA",
},
"cbsdInfo":{
"vendor": "CBSD Vendor of RU",
"model": "CBSD Model of RU",
"softwareVersion": "2.0",
"hardwareVersion": "2.0",
"firmwareVersion": "2.0"
}
}
]
}
The CBSD receives a batch registration response from SAS.
The DP sends a batch grant request to SAS. For each
TP, the DP requests a frequency range that SAS specified as
available.
The maxEirp value for each TP should not be more than 30 dBm or
10 MHz for an indoor deployment.
The operationFrequencyRange field should be the same for each TP. In a
single-sector Passive DAS deployment, all TPs must use the same RF channels.
Example
{
"grantRequest":[
{
"cbsdId":"SAS-assigned device ID #1",
"operationParam":{
"maxEirp":value less than or equal to 30,
"operationFrequencyRange":{
"lowFrequency":F1 (within 3550 - 3700 MHz),
"highFrequency":F2 (within 3550 - 3700 MHz)
}
}
},
{
"cbsdId":"SAS-assigned device ID #2",
"operationParam":{
"maxEirp":value less than or equal to 30,
"operationFrequencyRange":{
"lowFrequency":F1 (within 3550 - 3700 MHz),
"highFrequency":F2 (within 3550 - 3700 MHz)
}
}
},
...
{
"cbsdId":"SAS-assigned device ID #N",
"operationParam":{
"maxEirp":value less than or equal to 30,
"operationFrequencyRange":{
"lowFrequency":F1 (within 3550 - 3700 MHz),
"highFrequency":F2 (within 3550 - 3700 MHz)
}
}
}
]
}
The DP receives a batch grant response from SAS.
Example
{
"grantResponse":[
{
"cbsdId":"SAS-assigned device ID #1",
"grantId":"SAS-assigned grant ID #1",
"grantExpireTime":"YYYY-MM-DDTHH:MM:SSZ",
"heartbeatInterval":60,
"channelType": GAA,
"response":{
"responseCode":0
}
},
{
"cbsdId":"SAS-assigned device ID #2",
"grantId":"SAS-assigned grant ID #2",
"grantExpireTime":"YYYY-MM-DDTHH:MM:SSZ",
"heartbeatInterval":60,
"channelType": GAA,
"response":{
"responseCode":0
}
},
...
{
"cbsdId":"SAS-assigned device ID #N",
"grantId":"SAS-assigned grant ID #N",
"grantExpireTime":"YYYY-MM-DDTHH:MM:SSZ",
"heartbeatInterval":60,
"channelType": GAA,
"response":{
"responseCode":0
}
}
]
}
The DP sends batch heartbeat requests to SAS periodically
based on the heartbeatInterval and receives batch heartbeat responses from
SAS.
Result
The expected results from the test are listed in the following table.
Table 14. Test case 14
Receives
Sends
SAS
Valid batch registration request, including one request for each TP
Valid batch spectrum inquiry request, including one request for each TP
Valid batch grant request, including one request for each TP
Valid periodic batch heartbeat requests, including one request for
each TP at least every heartbeatInterval seconds
Successful batch responses to all batch requests. The
transmitExpire time in the heartbeat responses is set to a
value during four minutes.
DP
Successful batch responses to all batch requests
After the first successful heartbeat response, each TP starts
transmission on the corresponding channel and power
Valid batch registration request, including one request for each TP
Valid batch spectrum inquiry request, including one request for each TP
Valid batch grant request, including one request for each TP
Valid periodic batch heartbeat requests at least every
heartbeatInterval second, including one request for each TP. The
field operationState that belongs to any particular TP should be set
to Authorized in at least one heartbeat request.
Test case 15: Sorted spectrum inquiry response
This test case verifies that the CBSD can select the highest
quality channels from a sorted spectrum inquiry response. Learn how SAS calculates channel quality.
Assumptions
The CBSD tries to transmit on a single 10-MHz wide channel.
Prerequisites
Make sure that the CBSD has been registered with
SAS for at least four hours before the test. After the
CBSD registers, SAS can take up to four hours to
calculate channel quality and ranking.
For more accurate results, give frequency management grouping information for
the CBSD either in the registration request or in the
SAS Portal. Use Test Case 1 as an example.
Steps
Verify the following steps:
The CBSD sends a spectrum inquiry request to
SAS for the entire CBRS frequency range
3550 MHz to 3700 MHz.
The CBSD receives a spectrum inquiry response from
SAS. The spectrum inquiry response returns a list of available
channels sorted from best channel quality to worst. The first object in the
availableChannel array has the best quality.
Example
In this example, the first frequencyRange object has the highest quality and will be reused in Step 3.
The CBSD sends a grant request to SAS. The
CBSD requests the channel with the highest ranking. This is the
first element in the availableChannel array of the sorted spectrum inquiry
response.
The CBSD sends heartbeat requests to SAS
periodically based on heartbeatInterval and receives heartbeat responses from
SAS. Review the requirements to send heartbeat requests in Test Case 1.
Result
The expected results from the test are listed in the following table.
Table 15. Test case 15
Receives
Sends
Acceptable
SAS
Valid spectrum inquiry request
Valid grant request for the highest ranking channel based on the spectrum inquiry response
Valid periodic heartbeat requests at least every heartbeatInterval second
Successful sorted spectrum inquiry response
Successful grant response
Successful responses for all heartbeat requests, with
transmitExpireTime included in the heartbeat responses.
CBSD
Successful sorted spectrum inquiry response
Successful grant response
Successful heartbeat responses for all heartbeat requests
After the first successful heartbeat, the CBSD starts
transmission on the corresponding channel and power.
Valid spectrum inquiry request
Valid grant request for the highest-ranking channel based on the
spectrum inquiry response
Valid periodic heartbeat requests at least every
heartbeatInterval seconds, including at least one request
in which the operationState is set to Authorized
SAS Portal
You can find spectrum availability, channel quality, and channel
ranking on the Coex tab of the CBSD in the
SAS Portal. Find the URL of the test SAS environment.
Test case 16: Same frequency
This test case verifies the following:
The CBSD or DP equipment sends the Same Frequency
identifier to SAS each time the device registers.
The Same Frequency value can be set or edited in the SAS Portal
for each device.
Prerequisites
Make sure that the following is true:
The CBSD is not registered with SAS.
The CBSD or DP doesn't share the Same Frequency ID
with SAS.
Steps
Verify the following steps:
Configure the WInnForum Same Frequency value info in the CBSD registration message.
If there's a change in the Same Frequency value, you can set up a new value
in the heartbeat request message and send it to SAS.
Optional: Use the SAS Portal to set or edit the Same Frequency
value for the CBSD.
Result
The expected results from the test are listed in the following table.
Table 17. Test case 17
Receives
Sends
SAS
Registration request or heartbeat message from the CBSD
or DP, which includes the configured Frequency Reuse value
Optional: Frequency Reuse configuration for a CBSD in
the SAS Portal
Successful registration response to the CBSD or DP
CBSD or DP
Successful registration response or heartbeat response
The Common Channel Group (CCG) label per CBSD during
registration or by heartbeat when the Frequency Reuse value changes
Test case 18: Preference for multiple 10-MHz grant requests
This test case verifies that the CBSD or DP chooses to
request multiple 10-MHz grants when multiple channels that are greater than
10 MHz are used for operation.
Prerequisites
Make sure that the following is true:
The CBSD or DP is registered with SAS.
The CBSD is configured to utilize more than 10 MHz to operate.
Steps
Verify the following steps:
The CBSD or DP sends a grant request to SAS.
The CBSD sends a spectrum inquiry request to query available
spectrum. If SAS indicates availability, then the
CBSD requests a 10-MHz channel.
The CBSD is registered with the Test SAS
within a 5 kilometer radius of [68, -164.5]. The protection entity is simulated in the Test SAS
to ensure that the EIRP available on day 1 is 6dB or more below the eirpCapability
value of the device.
The CBSD is not located near the Canadian border, a Federal Communications
Commission field office, Table Mountain, or in a National Radio Quiet Zone.
Steps
Verify the following steps:
The CBSD sends a spectrum inquiry to the Test SAS.
The spectrum inquiry response shows one or more 10 MHz channels with EIRP 6dB or more below the
eirpCapability value of the device.
The CBSD requests a grant outside of the CPAS window on a frequency according to the
EIRP shown in Spectrum Inquiry, which is 6dB or more below the eirpCapability value of the device.
SAS approves the grant.
The CBSD commences heartbeat and receives authorization for transmission.
The CBSD heartbeat continues until CPAS occurs, as configured in the Test SAS.
After CPAS occurs, the CBSD receives an operationalParam payload that denotes EIRP that's higher
than the EIRP in the existing grant and with a successful response code.
If the CBSD decides to claim the new grant with the new EIRP value, it sends a grant relinquishment
request. The Test SAS sends a response indicating successful relinquishment.
(Optional) The CBSD sends a spectrum inquiry to check the new EIRP value. The maxEirp value in the
spectrum inquiry response will match the maxEirp value in the heartbeat response from the previous step for
the granted channel as long as the grant is a multiple of 10MHz. For example, 3550MHz to 3560MHz.
Test case 21: Heartbeat extension outside of DPA areas
SAS suggests different heartbeat interval and transmitExpireTime values
depending on frequencies granted and the CBSD's location. For more
information on heartbeat operation, see
Send heartbeat requests for authorization to transmit.
This test case verifies the following:
The CBSD reads the heartbeat interval and transmitExpireTime values
from the heartbeat response.
The CBSD heartbeats according to the heartbeat interval returned by SAS.
The CBSD continues to transmit until the transmitExpireTime value is reached.
Prerequisites
To complete the steps in this test case, you must register your CBSD
both inside and outside of the suspension zone in the test SAS deployment.
Outside the suspension zone
Verify the following steps:
Register the CBSD outside the suspension zone.
The CBSD requests a grant.
The test SAS deployment sends a heartbeat response. For example:
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2024-11-26 UTC."],[],[]]