SAS Working Group Agreements

Version: October 17, 2023

1- All non-highlighted texts are agreed and closed
2- Yellow highlighted texts are yet to be discussed
3- Magenta highlighted texts are action items

1. General Agreements:

a. PAL-ID, and User ID

1. The userId in the PAL Shared Database will be the FRN of the licensee
2. Each SAS admin may have a mapping table internally to associate the licensee FRN (from PAL Shared Database) to the userId of all users (including lessees) to be compatible with Release 1

b. PPA-ID:

1. Re-use of PPA-IDs: A previously-used PPA-ID may be re-used, provided that it is reused at least 7 days after the last time it is exchanged through CPAS (01082021)
2. if the polygon, the frequency range (via the PAL ID), or NLCD type of a PPA changes, the PPA ID *must* be changed. Otherwise, it is recommended not to change the PPA ID (for example, when only the cluster list is modified) (01082021)

c. Grant ID

1. The grantId of expired or terminated grants shall not be re-used at any time.
2. For SASs supporting Release 2 Grant Update Feature, we suggest applying the same approach as PPA-ID (06232020)

d. SAS Channel Allocation Policy

1. PAL Channel Assignment shall follow R2-SPU-01 with no modifications:
   • a. 10 MHz channel allocation
   • b. 10 MHz Channel Raster
2. GAA Channel Allocation: SASs shall enforce minimum BW granularity and raster for channel allocation consistent with CBRS-A Rel 1 (5MHz channel BW and 5 MHz raster)
   • a. The default minimum allocation is 10 MHz, unless there is a major constraint (such as high interference environment), in which case 5 MHz is the minimum allocation
   • b. As a starting point, we agree to limit the channel allocations as described above. However, if in later phases, narrowband CBSDs request channels smaller than 5 MHz (or a channel that in not a multiple of 5MHz), we might discuss accepting the grant and provide the protections over the 5MHz channelization (as a conservative approach).

e. SAS URL

1. We do not need to harmonize how SAS URLs are assigned, as long as they are within the bounds defined by SAS-CBSD and SAS-SAS specifications. Each SAS may decide how to assign its URL for SAS-SAS and SAS-CBSD interfaces. The URLs shall be announced and reported to other SAS Administrators the SAS-SAS URL. Whether the Admin is using the same URL for SAS-CBSD and SAS-SAS interface or not, is up to the SAS admin.

f. SAS-SAS Exchange

1. All SASs exchange Full Activity Dump Record (including CBSDs, PPAs, and ESCs as defined in the SAS-SAS TS) via the "pull" mechanism defined in the SAS-SAS specification. Support for exchange of all other record types and all other access mechanisms is optional.
2. All SAS Administrators acknowledge and agree that: Any information exchanged between SAS Administrators will be governed by the Inter-SAS Agreement concerning the following two issues (a and b);
   • a. Any information exchanged between SAS Administrators will be used only for the limited purposes of spectrum allocation and interference coordination; and
   • b. CBSD ownership information (CBSD licensee name and user contact information) will not be exchanged among SAS Administrators
3. When exchanging EscInstallationParam parameter in the SAS-SAS FAD exchange process extracted from WinnF-TS-0096, we treat all parameters other than the ones which say 'If present' as mandatory. So, the following parameters are mandatory
   • a. latitude
   • b. longitude
   • c. height
   • d. heightType
   • e. antennaAzimuth
   • f. azimuthRadiationPattern

g. Grants Considered in CPAS

1. As part of CPAS process, the managing SAS shall not consider any CBSD grant that has not been included in FAD, in IAP, DPA move list, of FSS Purge List calculation process.
2. When generating FAD as part of CPAS, any grant that is "terminated" by CPAS_T1 (the time of FAD generation) shall not be included in the full activity dump.
3. Any grant included in a FAD and whose field "terminated" is set to "false" shall be considered "active" during CPAS process. This means the receiving SAS would ignore the grantExpireTime field in the FAD
4. The field "channelType" shall be ignored by the receiving SAS during IAP (only the "cbsdReferenceId" in the SAS-SAS interface shall be used to determine whether a grant shall be exluded from IAP).

h. CBSD Registration Rules

1. CPI & Registration for CBSDs requiring CPI (All CAT B CBSDs, and CAT A CBSDs without geolocation capabilities)
   • a. If the registrationRequest includes cpiSignedData, the registration (or re-registration) request shall be rejected if installationParam (outside cpiSignedData) is also included.
   • b. If included, the InstallationParam within cpiSignedData shall include all REG-Conditional parameters. If incomplete, the Registration or re-registration shall be rejected.
   • c. If cpiSignedData is not included, pre-loaded information is used. The registration request shall be rejected with responseCode REG_PENDING if there is no pre-loaded information.
   • d. If cpiSignedData is included, the REG-Conditional information in cpiSignedData in SAS-CBSD protocol is used by the SAS, and any pre-loaded data about that CBSD is ignored
   • e. If the pre-loaded information is changed, the CBSD must re-register for the changes to take effect. The managing SAS shall not make any change in CBSD registration information without re-registration by the CBSD, and the SAS continues using the previous REG-Conditional information.
   • f. For CAT A CBSDs, we rely on CBSD certification that if CBSD cannot determine its location, it requires CPI for registration. SAS doesn't verify that requirement. SASes are not required to reject registration requests from Cat A devices which do not include cpiSignedData and do not have pre-loaded information.
2. REG-Conditional Parameters in Registration Request outside installationParameters
   • a. REG-Conditional parameters outside the installationParameters in CBSD registrationRequest (cbsdCategory, airInterface, and measCapability) are required to be provided either by CBSD in the registrationRequest message, or pre-loaded by other means such as CPI or the CBSD user. For those parameters:
     1. The CBSD may provide all of those parameters within the registrationRequest message
     2. The CBSD user or a CPI may pre-load any or all of those parameters
     3. Some of those parameters may be provided within registrationRequest message, and some pre-loaded by a CPI
     4. If a parameter is provided both within the CBSD registrationRequest message as well as pre-loaded by a CPI, and they are not completely matched, the SAS will ignore the preloaded parameter, and act according to the parameter provided within the registrationRequest.
   • b. CBSD measurement Capability
     1. If a CBSD has a valid FCC-ID, the assumption is that either it can perform measurement, and in that case CBSD is mandated to include measurement capability in Reg. Request, or CBSD has obtained FCC waiver for the measurement capability. Therefore SAS shall not reject any CBSD Reg. Request due to the fact that CBSD has left the measurement capability list empty (although the field must exist, the list may be empty).
     2. If CBSD has claimed its capability to provide measurement for obtaining the FCC-ID, SAS assumes CBSDs are certified to provide measurement capability during registration.
   • c. Antenna Beamwidth and Antenna Azimuth for Cat A
     1. If (a) the antennaBeamwidth is not 0 or 360 and (b) the antennaAzimuth is not provided, CBSD registration may be rejected.
     2. If it is not rejected, the managing SAS shall assume an omnidirectional antenna and the managing SAS shall exchange antennaBeamwidth =360 and antennaAzimuth =0 when sharing data with peer SASes.
     3. If the CBSD provides none of these parameters as part of registration, the managing SAS shall use the default values when exchanging these parameters with peer SASes. The default value of antennaBeamwidth is 360. The default value of antennaAzimuth is 0.
   • d. Interpretation of EIRP capability
     1. If the "eirpCapability" parameter is not provided in the Registration request and a CBSD registers as a CAT A, and the maximum FCC certified PSD (from FCC EAS database) is more than 20 dBm/MHz, the SAS shall reject the Registration
     2. If the maximum FCC certified PSD (from FCC EAS database) is more than 20 dBm/MHz, and the "eirpCapability" parameter is provided in the Registration request and eirpCapability <= 20 dBm/MHz (after been normalized to dBm/MHz), and a CBSD registers as a CAT A, It is up to the SAS Administrator to decide whether to accept CBSD registration or not.
        • a. Based upon recent FCC guideline (to wait for FCC official document such as KDB), if CPI is involved in registration, SAS may accept this CBSD's registration. The decision to implement this now, or wait for FCC official document is up to the SAS admin.

i. FSS-GWBL Exclusion zones and CBSD coordination (This feature is expired at the end of October 2022)

1. If the Passband of the FSS station is above 3700 MHz, no Exclusion zone is applied, even if there is a GWBL within 150 km of the station.
2. For FSS Stations with passband below 3700 MHz, and GWBL within 150 km, the EZ applies to 3650-3700, regardless of the GWBL operating frequency.
3. By default, SAS applies the FSS-GWBL Exclusion zone, unless CBSD user proves offline that it has coordinated with the FSS licensee.
4. Any proof of coordination among CBSD user and FSS licensee to allow deployment of CBSDs within 150 km of FSS station in case of presence of GWBL station in that range will be manually communicated with other SASs.
5. Such CBSD is not considered within the list of CBDS impacting the particular FSS, they have agreement with. It is considered for its possible impact on other incumbents.

j. Small GWPZs

1. For the GWPZs that are too small to include at least one grid point, there are two approaches; each SAS may use its approach
   • a. apply the protection to the vertex point, representing the location of the base station, and if not provided in the GWPZ, use the special shape of the GWPZ (e.g. tip of the pizza slice). This is called SiteCoordinate.
   • b. Protect the 4 grid points surrounding the SiteCoordinate
2. The land Category is determined based on the location of the vertex of the GWPZ.

k. PPA format

1. The following fields shall be ignored by the receiving SAS: (09212021)
   • a. ppaExpirationDate
   • b. ppaBeginDate
   • c. terminated
2. The expiration date of the PAL licence(s) associated with a PPA needs not to be checked by the receiving SAS.
3. CBSD to exclude from IAP : the managing SAS may include CBSDs which are not included in the PPA contour in the field "cbsdReferenceId" of the SAS-SAS interface.

l. PAL format

The SAS shall use the licenceAreaIdentifier to identify the county. The fields where the field "Mandatory" is set to "No" in the table below can be ignored by the SAS. The "FIPS" parameter in the field "licenseAreaExtent" shall be equal to the content of "licenseAreaIdentifier".

Registration Information

m. PPA Creation

If, as a result of clipping the PPA boundary by the border of census tracts county or license area, multiple disjoint contours are created, the SAS will may reject or accept the PPA generation request when responding to PPA generation requests sent to the SAS testing API. In operation, per WG10.12 requirement, the outcome is that no single PPA is composed multiple disjoint areas. The managing SAS may handle PPA creation requests in any way that conforms with this and other WG1-0112 requirements.

n. CRL server vs. OCSP Server

SAS Admins agree to use CRL server for certificate revocation, rather than OCSP servers in all security test cases for Release 1. This agreement applies only to Release 1 testing procedure. In commercial operation, SAS Admins may decide about the server used certification revocation, based on their own decision.

o. Manual SAS Peering Process

1. For the purposes of SAS-SAS exchange, SASes will peer manually. All SASes shall manually exchange the base URL (as described in the SAS-SAS 0096 TS) and the SHA-1 hash of the peer SAS's certificate. Any request for SAS-SAS exchange which does not include a recognized SAS certificate shall be rejected with HTTP response code 403.

p. Database Update

1. GWBL daily database update is based on weekly GWBL files in ULS, not the daily GWBL files. SAS Admin shall read the weekly file every day.
2. Portal monitored DPA database is updated no faster than once a month and SAS should pull p-kml file the database in a daily basis (However, as an informative notice NTIA has agreed to update the file no faster than once a month)

q. Informing Incumbent

Email alias is used for the purpose of receiving and forwarding interference reports, submitted by CBRS commercial Incumbents. Interference reports received by any of us should be copied to this distro list, and that any SAS corresponding with a complainant should cc their response to this list, removing and proprietary or Operator private information. The first SAS receiving the notification could acknowledge the reporting incumbent, and that acknowledgement is enough. The List Administrator: Andrew Clegg aclegg@google.com Group Distribution is: cbrs-interference-report@googlegroups.com

1. The first SAS receiving the notification could acknowledge, and that acknowledgement is enough
2. Content
   • a. Date of Report
   • b. Time of Report
   • c. Lat/long of impacted point*
   • d. Identifier for the protected entity (e.g. call sign)
   • e. Impacted Frequency Channel Range
   • f. Protected Entity interference threshold
   • g. Interference level (dBm/MHz)
   • h. Date of observed interference
   • i. Time of observed interference
   • j. Last date excessive interference observed at this location
   • k. The interference level Last time
   • l. Duration of the interference being observed
   • m. Equipment used for interference measurement
   • n. Antenna characteristic of impacted entity
   • o. Beamwidth
   • p. Azimuth
   • q. Gain
   • r. (optional) Pattern
   • s. Any other notes they wish to provide (e.g. interference was intermittent, the following waveforms were seen, etc.)
   • t. Preferred technical contact info for any follow-up questions/coordination
   • u. For FSS and ESC Sensor, the lat/long of entity is required. For PPA and GWPZ, the lat/long of the impacted point within PPA or GWPZ shall be reported Below is the language used to the FCC (it is the same as above, with only formatting updates, so folks can comment which should be kept.)

Incumbent Identifying Information

• Licensee name
• type* ( PAL, GWBL, FSS)
• Phone number or email of contact point
• FCC Call Sign
• FRN
• Name of person reporting, email address, and phone number(s)
• Contact person (if different from person reporting)

Interference Information

• Date(s) & Time(s) of receiving interference
• Frequency(ies) receiving interference
• Location of interference: latitude / longitude or address
• Height above Ground level of your antenna
• Azimuth Pointing of your antenna
• Elevation Tilt (Pointing angle) of your Antenna
• Beamwidth of your Antenna
• Gain of your Antenna
• Strength of suspected Interference
• Your Interference threshold (if not a standard protected entity)
• Equipment used to detect suspected interference
• Other information useful to the analysis, and description / source of interference
• Information on interferer (if known)

3. FCC to SAS Communication for Commercial Interference Inquiries Purpose of this distribution list if for the FCC to be able to reach all SAS Admins for Interference related questions.

The List Administrator is:

• Andrew Clegg Andrew Clegg (deprecated 2025)

Group Distribution is:

• SAS Inquiry SAS Inquiry

r. Certified Maximum EIPR from FCC EAS Database

1. All SAS admins assume all certified CBSDs cover the whole spectrum regardless of the format of the FCC EAS database
2. None of the SAS admins may consider multiple max PSD for one CBSD at least in release 1 timeframe
3. To calculate PSD for each row of a CBSD record, divide EIRP reported in FCC EAS database by the exact value number obtained from rounding up the emission designator BW to channel BWs of 5, 10, 15, 20, 30, and 40 MHz as follows:
   • a. 4.5-5 MHz to 5 MHz
   • b. 8-10 MHz to 10 MHz
   • c. 13-15 MHz to 15 MHz
   • d. 17.5-20 MHz to 20 MHz
   • e. 27-30 MHz to 30 MHz
   • f. 36-40 MHz to 40 MHz
4. Use the following exception to calculate the PSD for each row
   • a. If a FCCID has values below 8-10 MHz: use the entry with highest value and less than 10 MHz to calculate the EIRP by rounding it up to 10 MHz.
   • b. If a FCCID has no values below 8-10 MHz and some values above 20MHz: use the entry with lowest value and higher than 20 MHz to calculate the EIRP by rounding it up to 20 MHz.
   • c. If a FCCID has all values between 10 MHz and 17.5 MHz: use the entry use the highest value below 20 MHz, and round up to 20 MHz
5. SAS only compares the requested grant max EIRP with the certified max EIRP (or eirpCapability, when applicable), and do not perform any antenna gain comparison
6. SAS Admins consider all power levels in the FCC EAS database are EIRP despite the "EP" grant Note as mentioned in the KDB (KDB 953436 Aug/13/2018 from FCC)
7. In case there are multiple max EIRPs for a single CBSD in FCC EAS database, SAS should use the value reported for 10 MHz channel bandwidth (as described in item 3 above) to derive certified maximum EIRP density
8. Power Output in FCC EAS database should be normalized with the channel BW (as described in item 3 above) to obtain power per 10 MHz
9. If there are multiple entries corresponding to 10 MHz for a CBSD, SAS shall use the smallest power per 10 MHz as the certified maximum EIRP.
10. For CBSDs having only one row in the FCC EAS database, the maximum ERIP density is calculated using the reported EIRP and the channel BW (as described in item 3 above), regardless of the value of the channel BW.
11. For CBSDs with multiple rows, where none of them are in the range 8-10 MHz, SASs shall consider the row with the emission bandwidth in the range of 17.5-20 MHz (interpreted as the channel BW of 20 MHz). The EIRP density is found by dividing the EIRP by the channel BW (as described in item 3 above)
12. SAS may round-up the FCC max certified EIRP to the higher integer value (ceiling of FCC max certified EIRP Spectral density in dBm/MHz).
13. The operators and manufacturers must be informed that even if the grant is at the rounded-up integer value, the device must only operate at the maximum power levels declared in the FCC application for certification

s. Discussion on Table Mountain Test case

1. SAS Admins may wish to individually extend the coordination distances for Table Mountain beyond those given in the SAS test spec (0061, section 8.14) in order to avoid corner cases in which the distances in that document are insufficient to meet the required protection criteria (I <= -88.4 dBm). There is no need for coordination among SAS Admins regarding these distances.

t. Handling CBSD Coordination agreements by the SAS

1. No automated mechanism is required by the SAS in Rel 1 to receive the coordination among different entities, such as coordination of CBSD owners and FSS operators (the subject of R0-IPM-01-e), PAL operators, etc. All those coordination agreements may be conveyed to the SAS through offline manual approaches defined by the SAS Admin
   • a. All SASs shall apply the protection methodologies (e.g. IAP, DPA move list, etc.) without considering those coordination agreements. Beyond identifying the CBSD grant and power assignments, and provided that applying those coordination agreements do not impact other incumbents, the managing SAS may apply the terms of the agreement
   • b. (Not Final, to be Conformed) Only CBSD coordinations that impact exclusion zones (e.g. FSS EXZ or inside GWPZ or PPA) are required to be exchanged with other SASs. Another approach is to agree that the managing SAS includes CBSDs/grants that are inside an EXZ with in the FAD, only if there is a coordination with the incumbent, and the therefore the receiving SAS shall not cut the CBSD/grant during pre-IAP filtering (be careful about potential impact on release test)

u. Additional Protection Requirement by the FSS Earth Stations (Subject of R0-IPM-01-f)

1. No provisions are made in FCC FSS database to modify the FSS required protection level of -129 dBm/MHz for co-channel and OOBE protection, and -60 dB of blocking protection level. AsS a result, SAS Rel 1 is not required to dynamically adopt to the change in FSS protection level. Any such change shall be conveyed to the SASs well in advance, and in a manual fashion, and SASs may work offline to adjust their implementation accordingly.

v. Synchronizing GWPZ Land Categories

1. Wave 1 SAS administrators have agreed to shared and synchronized their calculation of GWPZ NLCD categories after Rel. 1 ICD. SAS Admins may repeat such coordination results among each other (obtained based on algorithm defined R2-SGN-04-(c)) for the updated GWPZs (GWPZs whose contours are changed) in future major versions of GWPZ database. by the end of July-2019 prior to ICD to synchronize the values 1. Wave 2 SAS Admins shall synchronize the categories with Wave 1 SAS Admins
   • a. FAD Generation and Pullout process in CPAS
     • a. We limit the operation on multiple file both for generation as well as of pulling out. Also we suggest to limit the FAD CBSD file size to approximately 50 MByte

w. GWPZ Channel BW determination

1. Scenario 1: both u_lower_frequency and u_upper_frequency are provided.

When both u_lower_frequency and u_upper_frequency are provided, the SAS will protect the GWPZ over the following frequency range:

GWPZ Low Frequency = closest multiple of 5 MHZ, equal or lower than u_lower_frequency
GWPZ High Frequency = closest multiple of 5 MHZ, equal or higher than u_upper_frequency

Example:

u_lower_frequency = "3661.00000000 MHz"
u_higher_frequency = "3671. 00000000 MHz"

In this example, the GWPZ will be protected on the frequency range [3660 – 3675 MHz]

2. Scenario 2: u_lower_frequency only is provided

When u_higher_frequency is not provided, u_lower_frequency represents the center frequency and the SAS will protect the GWPZ over the following frequency range: GWPZ Low Frequency = closest multiple of 5 MHZ, equal or lower than: u\_lower\_frequency – BW / 2 GWPZ High Frequency = closest multiple of 5 MHZ, equal or higher than: u\_upper\_frequency + BW / 2 Where BW is the bandwidth in MHz, determined by first 4 characters of the field "u_emission_designator"

Example:

u_lower_frequency = "3668.00000000 MHz"
u_higher_frequency = "MHz"
u_emission_designator = "8M88D7D"

GWPZ Low frequency = closest multiple of 5 MHz equal or lower than (3668 8.88/2) = 3660 MHz
GWPZ High frequency = closest multiple of 5 MHz equal or higher than (3668 + 8,88/2) = 3675 MHz

In this example the GWPZ will be protected on the frequency range [3660 – 3675 MHz]

3. Apply the same solution as GWPZ for FSS lower frequency (make it the floor of 5MHz granularity)

x. 2D Antenna Models

It is recommended that All SAS admins agree to implement the 2D antenna model as approved in WinnF Rel 2 requirement document (WINNF-TS-1001) 0112 as part of their Release 2 implementation. However, the feature capability exchange process as defined in Rel 2 is used to communicate the capability

y. PPAs and PPA IDs

1. Scenario 1: If a user using the same PAL Licensee, using the same channel, across two adjacent counties create a PPA, one PPA ID would correspond to multiple PAL IDs;
2. Scenario 2: If a user using the same PAL Licensee, using Contiguous or non-Contiguous channels, within the same county, using the same CBSD Cluster list, create PPAs, two different PPA IDs are created, one for each PAL ID
   • a. If in FAD, single PPA ID associated with more than one channel is sent in this scenario, receiving SAS will inform the transmitting SAS, and ignores the protection of PPAs until the correct PPA IDs are exchanged

z. FAD Failure

1. If the main FAD URL call to another SAS is failed (i.e. receives non-200 HTTP response for all retries), the SAS admin will use previous valid FAD for that SAS if it exists, otherwise ignores this SAS's data
2. If the main FAD URL to another SAS works, but one or more of the subsequent URLs fail, we know the type that has failed (PPA, ESC or CBSD), the SAS admins reverts back to previous valid Type (PPA, ESC or CBSD) for that FAD if it exists else ignore that Type all together.
3. If all FAD URLs to another SAS work but one or more records is corrupted or has incorrect values, the SAS admin reverts to previous valid record for that ID if it exists else ignore that record.

aa. ESC IDs

If some characteristics of an ESC changes (e.g. antenna pattern, height, etc.), the managing SAS does not have to use a new ESC-ID, and the same ID can be used in FAD

ab. SAS IDs

1. The SAS ADMINISTRATOR ID is generated by each SAS Admin, and this council (SAD_Admin or SAS-Admin) would guarantee its uniqueness among all SAS admins
2. This ID is used as a prefix only for ESC and PPA data message in FAD exchange

ac. CPIR-ID

1. SAS Admins agree to Consider CPIR-ID in the CPI database case-insensitive
2. TPAs (Google, CommScope, FW) agree to make CPIR-ID in the CPI database case-insensitive.

ad. Heartbeat Relaxation (update 10/17/2023)

Given that the FCC PN on 09/19/2023 allows all the CBSDs located outside all DPA neighborhoods or having operation frequency range not overlapping the band 3550 – 3650 MHz to continue to transmit up to 24 hours on the approved grants without SAS re-authorization, SAS admins agree that these changes are not mandatory. However, if one SAS admin applies the relaxation, it shall set the heartbeatInterval no more than 30 minutes around the time T3 in CPAS process, and the transmitExpireTime of 6 hours for all the grants whose operation frequency range does not overlap the band 3550 – 3650 MHz, and all the grants given to the CBSDs located outside all the DPA neighborhoods.

1. Higher Tier Protection:

a. IAP

1. Impact of IAP on SAS-CBSD Agreement
   • a. We will consider supporting Grant Update (due to EIRP change) for release 2
   • b. If a CBSD requests a Grant during the day (i.e. that Grant has not already gone through CPAS), the SAS may accept the Grant and immediately suspend it (via the HeartbeatResponse) if the Grant cannot be authorized using the managing SAS's margin allocation.
2. All SASs shall synchronize the time IAP is performed, and the time new power profiles are executed.
3. Coordinated Periodic Activities among SASes (CPAS) Timing
   • a. [5/28/2019] The values of T1, T2, and T3 (as defined in SSC-0008) for the purpose of ICD (Initial Commercial Deployment) are agreed to be the following values. SAS Admins will revisit these numbers for commercial deployment beyond ICD.
     • i. T1=7:00 AM UTC (12:00AM PST)
     • ii. T2=7:30 AM UTC (12:30AM PST)
     • iii. T3=10:00 AM UTC (3:00 AM PST)
   • b. For commercial deployment, the numbers will be revisited no later than every 6 months beyond the first agreement.
4. (Update: 2023-08-08)
   • a. In the scenarios where the CBSD is located inside any DPA neighborhood AND the grant has the operation frequency range overlapping the band 3550-3650 MHz: For Grant requests received between $T_1$ and $T_3+240$ seconds which are not related to the power decrease, SAS uses its SAS-Specific margin from the previous day's execution of CPAS to approve and authorize those Grants requests. A SAS updates its SAS-Specific margin at $T_3+240$ seconds.
   • b. In other scenarios: For Grant requests received between $T_1$ and $T_3$ + 30 minutes which are not related to the power decrease, SAS uses its SAS-Specific margin from the previous day's execution of CPAS to approve and authorize those Grants requests. A SAS updates its SAS-Specific margin at $T_3$ + 30 minutes.
5. For IAP margin definitions and leftover calculation methodology, refer to WinnF-SSC-00007 and Appendix B in WinnF-TS-0061
   • a. Pre-IAP unassigned margins: It is the opinion of SAS Admins that aggregate interference from all CBSDs outside the neighborhood protection area of each protected entities is small and negligible if the neighborhood protection area is defined in Part 96, such as 150 km for FSS (see the Part 96 requirement). CBSDs outside the neighborhood protection area of a protected entity – even those neighborhoods defined only in WinnF-TS-00112 – are not considered in aggregate interference calculations.
6. When to start protecting the higher tier entities requiring protection (Update 2023-08-08)
   • a. In the scenarios where the CBSD is located inside any DPA neighborhood AND the grant has the operation frequency range overlapping the band 3550 – 3650 MHz:
     • i. Protection for the following protected entities begins no later than T3+240 seconds (i.e., when all power decreases have been applied): PPA (Confirmed with Verizon), FSS, ESC sensors (note: since the DPA is activated prior to establishment of ESC sensor, the DPA remains activated until SASs start protecting the corresponding ESC sensor(s)).
     • ii. DPA: Maximum 300 seconds after being notified that the DPA is active.
   • b. In other scenarios:
     • i. Protection for the following protected entities begins no later than T3+30 minutes (i.e., when all power decreases have been applied): PPA (Confirmed with Verizon), GWBL, FSS, ESC sensors (note: since the DPA is activated prior to establishment of ESC sensor, the DPA remains activated until SASs start protecting the corresponding ESC sensor(s)).
7. Heartbeat Responses used to apply IAP changes
   • a. If the maxEirp of a Grant must be reduced as a result of CPAS, SAS Admins agree to terminate the existing Grant and to include the operationParam object (and all subfields) in the Heartbeat Response notifying the CBSD of Grant termination. SAS Admins expect the CBSD to request a new Grant with the suggested operationParam.
8. Constraint Point Grouping for IAP
   • a. IAP calculations are performed independently for each incumbent type (ESC sensor, FSS, GWBL, PPAs).
   • b. IAP calculations are performed independently for each instance of each of incumbent type (for PPA and GWPZ, this means each PPA area or GWPZ area are considered independently).
   • c. For FSS earth Station protection, IAP calculations are performed independently for co-channel and blocking protections.
   • d. IAP calculations are performed independently for each grid point within a PPA or GWPZ.
9. IAP Channelization and constraint grouping for IAP
   • a. IAP is applied over 5 MHz bandwidths (using a 5 MHz raster), consistent with CBRS-A Release 1.
     • i. If the bandwidth occupied by the protected entity does not match this raster, SASes shall protect all 5 MHz segments which partially or fully overlap with this bandwidth (i.e. the protection criteria are expanded).
     • ii. For protected entities with dBm/MHz protection constraints, SASes perform calculations on a dBm/MHz basis. For any Grant which partially overlaps with the 5 MHz segment, SASes shall assume that the same dBm/MHz EIRP is used over the entire 5 MHz segment.
       • 1. Note that any Grants which partially overlap with the 5 MHz segment will fully overlap with the 5 MHz segment, due to the channel rasterization agreed upon in this document.
     • iii. For protected entities with dBm/10 MHz protection constraints, the constraint shall be translated to a dBm/5 MHz constraint and this more restrictive constraint shall be used by SASes.
   • b. For protected entities occupying bandwidth B > 5 MHz, IAP calculations are performed jointly over all 5 MHz segments in B.
     • i. For area-based protections, grid points are considered independently but all 5 MHz segments for a single grid point are considered together.
     • ii. "N" is considered separately for each 5 MHz segment.
     • iii. A Grant is not considered "satisfied" unless it is satisfied in all 5 MHz segments with which it overlaps.
     • iv. IAP terminates when all Grants overlapping B are satisfied.
   • c. ESC channelization:
     • i. CBSDs operating in 3550-3650 MHz: Consider minimum BW granularity and raster for applying IAP protocol consistent with CBRS-A Rel 1 (5MHz channel BW and 5 MHz raster) (contingent to FCC agreement on applying protection to larger channel bandwidths if their protection criteria are in dBm/MHz density)
     • ii. CBSDs operating in 3680-3700 MHz: No ESC protection is provided.
     • iii. The joint IAP Protection is provided over each 5MHz segment of 3550-3680 frequency range, assuming that each 5 MHz segment is a separate constraint/channel point.
     • iv. the IAP Protection Criteria is mean-level Protection
10. IAP for PPA and GWBL
    • a. For PPA that is already active, CBSDs that are part of PPA cluster list are not counted as part of "N" for IAP execution for protection of that PPA
    • b. If a user (PAL Holder) claims multiple PPAs (say PPA1 and PPA2, using the same channel), for protecting each PPA, none of the CBSDs belonging to that PAL holder can be counted toward "N" for IAP execution for protection of that PPA.
      • i. Another Approach: To protect a PPA, the interference contribution from CBSDs of other PPAs belonging to the same users shall be taken into account. When that contribution is calculated, and as long it doesn't impact other criteria (which is kind of unrealistic) the user may re-distribute the interference budgets'
    • c. For PPAs and GWBL zones that are already active, any CBSD inside the PPA or GWBL zone, requesting a grant that overlaps with the channel associated with PPA or GWBL, is immediately rejected, and will not be counted toward "N" for IAP execution for associated PPA or GWBL or any other incumbent using that channel.
    • d. At the time of daily activities, if a new PPA zone or GWBL boundary becomes active (e.g. PPA creation by managing SAS during the day, or exchanging PPA zones through SAS-SAS FAD exchange, or external DataBase synchronization for GWBL), or existing PPA zones or GWBL boundaries are modified, the SAS shall identify all CBSDs that are located inside the PPA zone or GWBL boundary, and terminate their existing authorized or suspended grants with operationParam overlapping with PPA or GWBL frequency. Those CBSD grants are not counted toward "N" for IAP execution for associated PPA or GWBL or any other incumbent using that channel.
11. IAP Power
    • a. For its own registered CBSDs, which are Granted but waiting for IAP process to be Authorized, the requested maxEIRPs are used
      • i. For Release 1, we leave it for the managing SAS to pick the requestedEIRP (potentially up to eirpCapability of the CBSD) both for newly requested grants and existing grants
    • b. If requestedOperationParam is not provided through SAS-SAS interface, the maxEIRP value of the operationParam should be used.
12. IAP per Grant lower EIRP Limit
    • a. If during IAP, SAS needs to reduce a particular CBSD EIRP, when the EIRP reaches TBD dBm/MHz, and CBSD is still not satisfied, the IAP iteration for that CBSD is terminated.
13. IAP Open Questions:
    • a. What should SAS A do if it cannot pull from SAS B (generally not been able to synchronize)?
    • b. What should a SAS do if it's down during this time period? Can it operate again before the next update?

b. DPA Protection

1. Each DPA is protected based on 10 MHz channelization and rasterization (e.g., 35503.60MHz, 3560-3570 MHz, etc.). If the detected channel by ESC coincides with more than one 10 MHz channels, all those channels are protected.
2. DPA Move list calculation is performed and completed DPA at T3
3. Consider 10 MHz channelization for DPA move list calculation, starting from 3550 to 3650 MHz with 10 MHz Raster.
4. For CBSDs managed by other SASes, always the requestedEIRP parameter of requestedOperationParam object is used (if not provided, operaionParam is used). A managing SAS has to use the same value for its Move-List Calculation.
5. DPA Grid-Size: Define DPA Grid Size to avoid heavy DPA move list calculation per DPA
   • a. Use Grid point over the three edges (front edge, and the two side edges) of the DPA. The grid points are 3-arcsec apart
   • b. Federated wireless could provide the lat/long of all those points per DPA
6. If SAS uses its own margin to augment a CBSD power beyond the power used in DPA calculation, if DPA is activated, and if the CBSD is not part of the move-list, the managing SAS shall ensure that the CBSD is not actively transmitting with more than the power used as input to the DPA move list calculations (e.g. through suspension or through power reduction)"
7. If SAS uses its own margin for a new grant, if DPA is activated, the CBSD goes automatically into the move-list

ESC:

1. ESC Frequency notification and frequency channel to be considered for DPA protection is based upon 10 MHz channelization and rasterization starting from 3550 MHz
2. According to WG4 Ballot #2 Part 1 agreements, SAS shall be able to receive the following parameters from ESC Test Harness regarding DPA activation/deactivation
   • a. DPA Index Number (s)
   • b. DPA Activation/Deactivation flag (s)
   • c. Channel Number (s) / frequency Range (s)
3. ESC Sensor Protection level use -109 dBm/MHz and scaled to the channel BW used for IAP (According to NTIA 15-527 Report)
   • a. -89dBm/MHz detection criteria is applicable at the antenna port
   • b. -109dBm/MHz is applicable at the ESC antenna port
   • c. The protection is applied post RX filter both for inband and out of band
     • i. 0.5 dB Insertion loss is assumed for in-band (3550-3650MHz)
     • ii. 1dB/MHz response decay is assumed for 3650-3680 MHz (similar to FSS protection)
   • d. How to come up with -109dBm/MHz? (refer to item a above)
     • i. Start with -89 dBm/MHz
     • ii. X dB (e.g. 10 dB) Peak to Peak SINR
     • iii. Y dB (e.g. 10 dB) Peak to Average Ratio
4. Gating process in exchanging ESC information in FAD (update: 2023-08-22)
   • a. All the same ESCs (having the same latitude, longitude, and height) shall have the same antenna characteristics.
   • b. If one SAS admin needs to add, delete, or make any change of ESC configuration into the FAD, it shall inform other SAS admins at least ONE week before implementing the change. The information shall include the installation parameters in the perspective new FAD. Note : this ESC protection level can be overwritten by including the parameter "protectionlevel" in the ESC Sensor data object included in the FAD. The value of this parameter is an integer with a value higher or equal to -109 dBm / MHz.

2. Canadian Border Protection (2023-06-20)

According to the international agreement between FCC and ISED (Innovation, Science and Economic Development Canada), a "Sharing Zone" adjacent to the U.S./Canadian border is defined as 35 km. Unless directed otherwise by the FCC, or informed of alternative protection arrangements, and for the United States borders defined by R1-SGN-05 (WINNF-TS-0112, V1.10.0), for all CBSDs within the Sharing Zone adjacent to Canadian border and operating in 3550 3.00 MHz, the SAS shall allow spectrum grants only if the predicted Power Flux Density (PFD) at any point along the border does not exceed -114.5 dBW/m2 /MHz (or -84.5 dBm/m2 /MHz) at a height 1.5 m above ground level, using median ITM path loss.