CBRS Alliance Technical Work Group
Document CBRSA-TS-2001
Version V3.2.0
2022-05-23
THIS SPECIFICATION IS PROVIDED "AS IS," WITHOUT ANY REPRESENTATION OR WARRANTY OF ANY KIND, EXPRESS, IMPLIED, OR STATUTORY; AND TO THE MAXIMUM EXTENT PERMITTED BY LAW, ONGO ALLIANCE, AS WELL AS ITS MEMBERS AND THEIR AFFILIATES, HEREBY DISCLAIM ANY AND ALL REPRESENTATIONS AND WARRANTIES, INCLUDING WITHOUT LIMITATION ANY WARRANTIES OF MERCHANTABILITY, TITLE, NON-INFRINGEMENT, FITNESS FOR A PARTICULAR PURPOSE, ACCURACY, OR RELIABILITY, OR ARISING OUT OF ANY ALLEGED COURSE OF PERFORMANCE, DEALING OR TRADE USAGE. ANY PERMITTED USER OR IMPLEMENTER OF THIS SPECIFICATION ACCEPTS ALL RISKS ASSOCIATED WITH THE USE OR INABILITY TO USE THIS SPECIFICATION.
THE PROVISION OR OTHER PERMITTED AVAILABILITY OF OR ACCESS TO THIS SPECIFICATION DOES NOT GRANT ANY LICENSE UNDER ANY PATENT OR OTHER INTELLECTUAL PROPERTY RIGHTS ("IPR"). FOR MORE INFORMATION REGARDING IPR THAT MAY APPLY OR POTENTIAL AVAILABILITY OF LICENSES, PLEASE SEE THE ONGO ALLIANCE IPR POLICY. ONGO ALLIANCE TAKES NO POSITION ON THE VALIDITY OR SCOPE OF ANY PARTY'S CLAIMED IPR AND IS NOT RESPONSIBLE FOR IDENTIFYING IPR.
TO THE MAXIMUM EXTENT PERMITTED BY LAW, UNDER NO CIRCUMSTANCES WILL ONGO ALLIANCE, OR ANY OF ITS MEMBERS OR THEIR AFFILIATES, BE LIABLE FOR DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, SPECIAL, EXEMPLARY, PUNITIVE, OR OTHER FORM OF DAMAGES, EVEN IF SUCH DAMAGES ARE FORESEEABLE OR IT HAS BEEN ADVISED OR HAS CONSTRUCTIVE KNOWLEDGE OF THE POSSIBILITY OF SUCH DAMAGES, ARISING FROM THE USE OR INABILITY TO USE THIS SPECIFICATION, INCLUDING WITHOUT LIMITATION ANY LOSS OF REVENUE, ANTICIPATED PROFITS, OR BUSINESS, REGARDLESS OF WHETHER ANY CLAIM TO SUCH DAMAGES SOUNDS IN CONTRACT, WARRANTY, TORT (INCLUDING NEGLIGENCE AND STRICT LIABILITY), PRODUCT LIABILITY, OR OTHER FORM OF ACTION.
THIS DOCUMENT (INCLUDING THE INFORMATION CONTAINED HEREIN) IS PROVIDED AS A CONVENIENCE TO ITS READERS, DOES NOT CONSTITUTE LEGAL ADVICE, SHOULD NOT BE RELIED UPON FOR ANY LEGAL PURPOSE, AND IS SUBJECT TO REVISION OR REMOVAL AT ANY TIME WITHOUT NOTICE. THIS DOCUMENT IS PROVIDED ON AN "AS IS", "AS AVAILABLE" AND "WITH ALL FAULTS" BASIS. ONGO ALLIANCE MAKES NO REPRESENTATION, WARRANTY, CONDITION OR GUARANTEE AS TO THE USEFULNESS, QUALITY, SUITABILITY, TRUTH, ACCURACY, OR COMPLETENESS OF THIS DOCUMENT OR ANY INFORMATION CONTAINED HEREIN. ANY PERSON THAT USES OR OTHERWISE RELIES IN ANY MANNER ON THE INFORMATION SET FORTH HEREIN DOES SO AT HIS OR HER SOLE RISK.
IMPLEMENTATION OF A [NETWORK] AND/OR RELATED PRODUCTS OR SERVICES IS OFTEN COMPLEX AND HIGHLY REGULATED, REQUIRING COMPLIANCE WITH NUMEROUS LAWS, STATUTES, REGULATIONS AND OTHER LEGAL REQUIREMENTS ("LEGAL REQUIREMENTS"). AMONG OTHER THINGS, APPLICABLE LEGAL REQUIREMENTS MAY INCLUDE NETWORK OPERATOR REQUIREMENTS UNDER FEDERAL LAW, REQUIREMENTS RELATING TO E-911, ETC. A DISCUSSION OF SUCH LEGAL REQUIREMENTS IS BEYOND THE SCOPE OF THIS DOCUMENT. ACCORDINGLY, NETWORK OPERATORS AND OTHERS INTERESTED IN IMPLEMENTING NETWORKS OR RELATED SOLUTIONS ARE STRONGLY ENCOURAGED TO CONSULT WITH APPROPRIATE LEGAL, TECHNICAL AND BUSINESS ADVISORS PRIOR TO MAKING ANY IMPLEMENTATION DECISIONS.
OnGo Alliance 3855 SW 153rd Drive, Beaverton, OR 97003 www.ongoalliance.org info@ongoalliance.org Copyright © 2022 OnGo Alliance, All Rights Reserved
An objective of the CBRS Alliance is to allow flexible use of the CBRS band while supporting coexistence of multiple deployments. This document is a Technical Specification (TS) for coexistence between and among multiple LTE and NR networks. In this release only GAA aspects are addressed. Coexistence between CBSDs belonging to the CBRS Alliance Coexistence Group is coordinated by one or multiple Coexistence Managers (CxMs). A Coexistence Manager (CxM) combined with a SAS forms a CBRS Alliance SAS Entity (CSAS). The specification addresses requirements on the CxM pertaining to coexistence. Additionally, the specification includes GAA coexistence requirements for CBSDs including cell phase synchronization, TDD Configuration for LTE-TDD and NR-TDD CBSDs, GAA channelization and SAS-CBSD protocol extensions. The current version of the document focuses on Band 48 [11] LTE-TDD using Frame Structure 2 (FS2) [4][16] and limited support for n48 [18][19] NR-TDD deployment. Coexistence between CBSDs belonging to the CBRS Alliance Coexistence Group is coordinated by one or multiple Coexistence Managers (CxMs).
The key words "required", "shall", "shall not", "should", "should not", "recommended", "may", and "optional" in this document are to be interpreted as described in RFC-2119 [12].
Note: LTE and E-UTRA are equivalent terms for the purposes of this TS. Furthermore, unless otherwise noted, references to CBSDs refer to CBRS Alliance CBSDs.
3GPP: 3rd Generation Partnership Project
BS: Base Station
CA: Carrier Aggregation
CBRS: Citizens Broadband Radio Service
CBRSA: CBRS Alliance
CBSD: Citizens Broadband Radio Service Device
CP: Cyclic Prefix
CPAS: Cooperative Periodic Activities among SASs
DL: Downlink
DP: Domain Proxy
E-UTRA: Evolved UTRA
FFS: For Further Study
FS2: Frame Structure 2 corresponding to LTE-TDD operation in 3GPP Band 48.
FSS: Fixed Satellite Service
GAA: General Authorized Access.
GNSS: Global Navigation Satellite System
GPS: Global Positioning System
ID: Identification
LTE: Long Term Evolution
NL: Network Listening
NR: New Radio
OOBE: Out Of Band Emission
OTA: Over the Air
PAL: Priority Access License
PTP: Precision Time Protocol
RAN: Radio Access Network
RF: Radio Frequency
SAS: Spectrum Access System
SCS: Sub-Carrier Spacing
SFN: System Frame Number
SSF: Special Subframe
TAI: Temps Atomique International
TDD: Time Division Duplex
TR: Technical Report
TS: Technical Specifications
UE: User Equipment
UL: Uplink
UTC: Coordinated Universal Time
CCG (Common Channel Group): A group of CBSDs that are part of the same ICG, where all members of the CCG require the same channel assignment.
Connected Set: A set of CBSDs represented by the largest set of vertices of a graph, in which any two vertices of the set are connected to each other through at least one path in the graph.
CBRS Alliance SAS Entity (CSAS): A logical entity that comprises a WInnForum specified SAS [6] and a CBRS Alliance specified Coexistence Manager (CxM).
CxG (Coexistence Group): A group of CBSDs that abide by a common interference management policy which is used to coordinate their interference within the group. (In the context of TS-2001 Release 2, support for only a single CBRSA CxG has been defined.)
CxM (Coexistence Manager): A logical entity responsible for managing coexistence among CBSDs within a specific CxG.
GAA Channel Assignment: An operation performed by the CxM, where the CxM identifies the GAA frequency range that a particular CBSD may request from SAS and informs the CBSD and SAS of the assignment. The CBSD is expected to request grant(s) consistent with the GAA channel assignment and the SAS has the final discretion to accept or reject a CBSD's grant request to use a GAA channel.
ICG (Interference Coordination Group): A group of CBSDs belonging to the CBRSA CxG indicating that they can manage their own interference within the group, and do not require channel orthogonalization.
LTE-TDD: LTE-Time Division Duplex. In the CBRS Band, LTE-TDD corresponds to Band 48 as defined by 3GPP.
Equivalent TDD Configuration: A TDD frame configuration in which, regardless of the SCS (i.e., independently of symbol durations), all UL, DL and gap periods are strictly aligned from a timing point of view with those defined by a reference TDD Configuration.
NR-TDD: NR-Time Division Duplex. In the CBRS Band, NR-TDD corresponds to Band n48 as defined by 3GPP.
TDD Configuration: A TDD configuration for an LTE-TDD deployment is defined as a combination of a UL/DL configuration and an associated SSF configuration. A TDD configuration for an NR-TDD deployment is defined as a combination of an SCS and a TDD-UL-DL pattern for the NR frame.
Coordination of spectrum use between CBSDs within the CBRSA CxG is facilitated by exchanging information between CBSDs belonging to the CBRSA CxG and the CxM.
See Section 7 for protocol extensions to support this information exchange.
A lack of frame synchronization or the use of incompatible uplink-downlink TDD Configurations between CBSDs can create interference from high power downlink signals from the network towards UE transmissions, potentially degrading throughput due to harmful interference. Therefore, cell phase synchronization and alignment of downlink and uplink resources are necessary within TDD Configuration Connected Sets (see details in Section 6.3.1) of CBSDs belonging to the CBRSA CxG, even when those CBSDs are operated by different operators.
Several methods are available to achieve phase synchronization of TDD networks, e.g. GPS or GNSS assistance [1], PTP, and NL. It is possible to achieve multi-operator frame synchronization based on existing parameters in 3GPP specifications in a manner that is independent of the actual source of timing information.
The definition of cell phase synchronization accuracy appears in 3GPP TS 36.133, Section 7.4 [2], for LTE cells and TS 38.133, Section 7.4.1 [25] for NR cells:
Cell phase synchronization accuracy is defined as the maximum absolute deviation in frame start timing between any pair of cells on the same frequency that have overlapping coverage areas.
CBSDs shall conform with all the requirements of cell phase synchronization specified in the 3GPP TS 36.133 [2] for LTE cells and TS 38.133 [25] for NR cells, irrespective of the frequency assigned to them. In particular, the specification [2] establishes a requirement for accuracy at ≤ 3 μs for a wide area BS that has a cell radius ≤ 3 km and at ≤ 10 μs for a wide area BS that has a larger cell radius when measured against a common reference. In addition, the accuracy requirement for Home BS small cells at a propagation distance smaller than or equal to 500 m is ≤ 3 µs, while a large cell Home BS covering more than 500 m distance and operating in Network Listening (NL) mode will have to maintain Cell Phase Synchronization accuracy at a level ≤ 1.33 µs more than the time of propagation from the network synchronization source. The requirement for Home Base Stations without NL is equal to the small cell requirement. The 3GPP TS 36.133 and 3GPP TS 38.133 are the definitive references for all requirements pertaining to cell phase synchronization [2][25].
The parameters that establish synchronization are further detailed in 3GPP TS 36.401 and TS 38.401, Section 9.1 [3][26].
All LTE-TDD CBSDs and NR-TDD CBSDs belonging to the CBRSA CxG shall derive frame timing in accordance with the following requirements:
CBSDs that use CA shall maintain a common frame reference for all the component carriers in any band combinations including the CBRS band, i.e. Band 48. When a CBSD belonging to a CBRSA CxG determines or predicts it is operating outside the allowable limits required for cell phase synchronization, the CBSD shall stop radio transmission. Once the CBSD determines or predicts it is able to operate within the allowable limits required for cell phase synchronization, the CBSD may start radio transmission using spectrum grants authorized by SAS.
It is well understood in the industry that a desirable condition for multiple overlapping outdoor LTE-TDD and NR-TDD deployments to coexist in the same band is that they align their frame boundaries and use the same TDD Configuration. Asynchronous operation in the same outdoor area can lead to detrimental interference conditions, and coexistence solutions without alignment of cell phases and TDD Configurations may not be practical and/or efficient.
For indoor deployments [22][23], where the CBSD power levels are comparable to UE power levels, the restriction on utilizing the same TDD Configuration can be relaxed.
All LTE-TDD CBSDs in a CBRSA CxG shall support the uplink-downlink configurations in Table 1 with SSF Configuration 7 [4].
Table 1: Mandatory E-UTRA TDD UL/DL Configurations for the CBRSA CxG.
All NR-TDD CBSDs in a CBRSA CxG shall support NR SCS of 15 kHz or 30 kHz2 , as defined in Table 5.3.5-1 of TS 38.104.
NR CBSDs operating with 30 kHz SCS in a CBRSA CxG shall support the uplink-downlink configurations2 that are shown in Table 2, which correspond to the mandatory LTE-TDD Configurations3 . Slots shown with 'D' shall use 14 DL symbols, slots shown with 'U' shall use 14 UL symbols, and slots shown with 'S' shall have 14 symbols configured as 6 DL symbols followed by 4 Guard symbols followed by 4 UL symbols as shown in Figure 1 in order to match LTE-TDD SSF7 [17].
NR CBSDs operating 15 kHz SCS in the CBRSA CxG shall support TDD Configurations equivalent to the mandatory E-UTRA TDD Configurations shown in Table 1, where the symbols in the special slot shall be configured to match LTE-TDD SSF7 [17].
Table 2: Mandatory 30 kHz SCS NR-TDD UL/DL Configurations for the CBRSA CxG
All LTE-TDD CBSDs and NR-TDD CBSDs that are part of the same TDD Configuration Connected Set shall use the same TDD Configuration or Equivalent TDD Configurations.
Any LTE-TDD Configuration defined in [4] or the NR Equivalent TDD Configuration [17] may be used, provided all the LTE-TDD and NR-TDD CBSDs in the TDD Configuration Connected Set use the same TDD Configuration or Equivalent TDD Configurations.
Note: SCS employed for the TDD Frame configuration does not restrict k the SCS that can be employed for the PRACH preamble format.
Note: Initial NR CBSD deployments may not support both mandatory configurations, provided the CBSD stops NR operation if the CxM directs the CBSD to use a mandatory configuration that the CBSD does not yet support.
If LTE-TDD and NR-TDD CBSDs belonging to the same TDD Configuration Connected Set select different TDD Configurations, the CxM shall designate the use of one of the mandatory TDD Configurations.
In a TDD Configuration Connected Set containing only NR-TDD CBSDs, an NR-TDD Configuration not compatible with LTE-TDD may be used, provided that all NR-TDD CBSDs in the TDD Configuration Connected Set use the same SCS and NRTDD Configuration.
Coexistence measurement reports are conveyed by CBSD/DPs to the CxM using the SAS-CBSD protocol. The measurements reports are carried in the CoexMeasInfo object described in Section 7, and can be sent by the CBSD in any SAS-CBSD message that allows a GroupInfo object, including the RegistrationRequest, SpectrumInquiryRequest, GrantRequest, and HearbeatRequest [6].
The coexistence measurement reports are intended to provide the CxM with measurement information regarding the radio environment in the vicinity of the CBSD(s) that are performing or collecting the measurement, and thereby assist the CxM in its CBSD channel assignment function.
Coexistence reports may provide identification information, measurements, usability and tolerability indications. The information can pertain to the channels currently in use by the CBSD, or to other channels.
Along with a coexistence measurement report, CBSDs shall also provide the CxM with identification information about their transmitted CBRS E-UTRA/NR signals. This information is carried in cellInfo parameter of the CbrsAllianceInfo object described in Section 7. cellInfo parameter, which is an array of SignalInfo objects, shall be included in a heartbeat request when a CBSD starts to transmit a new CBRS E-UTRA/NR signal or whenever the identification information related to a CBRS E-UTRA/NR signal is modified.
The channels for which measurement information is being reported could pertain to a cell with an E-UTRA/NR TDD signal detected at the CBSD, signals corresponding to non-E-UTRA/NR TDD interferers detected at the CBSD, or E-UTRA/NR TDD signals detected by UEs connected to the CBSD.
For all reported channels, the report shall provide the frequency range for the measurements. Additionally, if the measured channel contains an E-UTRA/NR TDD signal, the report may include additional E-UTRA/NR TDD specific identification information regarding the signal, such as PCI, ECGI, etc.
For all reported channels, the CBSD may provide a ternary usability indication for the channel and may report its RSSI. Additionally, if the measured channel contains an E-UTRA/NR TDD signal, the report can contain EUTRA/NR TDD specific measurements such as RSRP and RSRQ.
If the CBSD is reporting UE-based measurement results, such reports shall contain statistical information based on UE measurement reports received by one or more CBSDs sharing the same E-UTRA/NR Cell Global Identifier. The messages will have to be duplicated for each CBSD that is part of the E-UTRA/NR Cell Global Identifier.
Coexistence Reporting Assistance Information is guidance that can be provided by the CxM to the CBSDs/DPs as input to coexistence measurement reporting. The guidance information may include a list of channels for which the CxM is interested in receiving measurement information, along with additional identifiers regarding specific E-UTRA/NR TDD cells that may exist in those channels.
For CBSDs that are members of the CBRSA CxG, only combinations of 5 MHz channel units can be used for spectrum inquiry and grant request for GAA. Thirty channel units of 5 MHz width are defined with the following frequency ranges (in MHz)
$$[3550 + (k-1) * 5,3550 + k * 5], k = 1, 2, ..., 30.$$
CBSDs shall request a spectrum grant in multiples of these 5 MHz channel units. The CxM shall follow the above GAA channelization for all frequency guidance and guard band assignments in multiples of 5 MHz. NR requires a minimum of 10 MHz contiguous bandwidth. For connected sets which include NR and LTE CBSDs the CxM shall attempt to employ the same minimum contiguous bandwidth (10MHz) for the GAA Channel Assignment process.
When a CBRSA CxG CBSD indicates membership in the CBRSA CxG, it may indicate membership in at most one Interference Coordination Group (ICG) to the CxM in a cbrsaGroupingParam parameter. ICG members are capable of managing interference among themselves, so even members with overlapping downlink coverage areas do not require non-overlapping spectrum assignments from the CxM.
A CBSD may further indicate membership in at most one Common Channel Group (CCG). A CCG shall consist of a subset of the CBSDs in a given ICG and shall indicate its CCG membership in the same cbrsaGroupingParam parameter that indicates membership in the corresponding ICG. All members of a given CCG require the same channel assignment from the CxM.
Figure 2 illustrates the relationship between CBSDs in the CBRSA CxG, ICGs, and CCGs. Note that the ICG and CCG formation are declared by the CBSD Users. The CBSD Users can form the CBSD Groups independently of the TDD Configuration which is determined by the CxM.
This section describes intra-CxG GAA Channel Assignment (defined in Section 3.2) to be used by CBRSA CxG CBSDs in the Grant Requests assuming LTE-TDD (FS2) or NR-TDD as the underlying technologies. Incumbent and PAL protection is handled by the SAS per Part-96 requirements [7] and the CxM procedures are subordinate to any decisions imposed by the SAS for this purpose.
The CxM is responsible for assigning a pool of available spectrum assigned by the CSAS for the CBRSA CxG among all CBSDs claiming membership in the CBRSA CxG.
As per Section 5, all the LTE/NR CBSDs in each TDD Configuration Connected Set use the same TDD Configuration or Equivalent TDD Configurations and are time synchronous to eliminate CBSD to CBSD or UE to UE interference between different LTE/NR-TDD systems. Indoor CBSDs which seek to opt out of TDD Configuration Connected Sets, shall also be time synchronous (per Section 5).
In this section, "coverage" refers to the CBSD downlink coverage. Considerations for coverage adjustment based on uplink performance are FFS.
The CSAS is responsible for providing the CxG with a spectrum assignment that is meant to be distributed among CBSDs within that CxG. In particular, the CSAS identifies one or more sets of CBSDs within the CBRSA CxG and provides the CxM with a spectrum assignment for each set. The CxM shall perform primary channel assignment consistent with the operation as described in this section below. The CxM is responsible for informing the serving CSAS regarding the GAA Channel Assignment.
For each set of CBRSA CBSDs identified, the CSAS provides the CxM with a list of the CBSDs in the set, information about those CBSDs, and a pool of spectrum assigned for that set. The information provided includes CBSD registration information such as the location of each CBSD, maximum EIRP or requested EIRP (if available), height above average terrain (HAAT) of the antenna placement, antenna characteristics and grouping information [15] (e.g., the contents of InstallationParam, grouping parameters, etc.).
For each set of CBSDs identified by the CSAS, using information provided by the CSAS, the CxM creates an "coverage overlap graph", which represents interference relationships between CBSDs, as follows:
After the CxM creates the coverage overlap graph, it finds different connected components of the graph, and each connected component becomes a "Channel Assignment Connected Set". At this point, the CxM considers each Channel Assignment Connected Set separately and performs the primary channel assignment independently for each Channel Assignment Connected Set:
The CxM should ensure stability over time (e.g. days) of channel assignment within the CxG as long as there is no instruction from the SAS on the change of channel availability due to the higher-tiers' activity.
Given that a significant CBSD EIRP power reduction (e.g. more than 10 dB in a typical use case) could completely invalidate the CBSD deployment goals, the CxM should recommend channel assignments to CBSDs that will not require more than an indicated EIRP power reduction from the requested EIRP level when higher tiers protection is applied. Channel assignment should also consider other aspects such as contiguous and stable channel assignments. In case the CxM is not able to assign any channel that will meet the specified CBSD maximum power reduction, this is conveyed to the CBSD.
The CxM shall convey to the CBSD the set of channels assigned. The CBSD can request one or more Grants with the appropriate requested operational parameters using these channels. Following a successful Grant Request / Response, the SAS entity within the CSAS should notify the CxM of the spectrum grant. For CBSDs relinquishing a spectrum grant during the day, the SAS entity within the CSAS may notify the CxM.
Within the spectrum assigned to the CxG by the SAS, the CxM may increase the bandwidth available to a CBSD beyond its primary channel assignment (which is an equal division of available GAA spectrum between the identified colors of a Channel Assignment Connected Set) by assigning any spectrum or part thereof that does not overlap with another CBSD's primary channel assignment, for all pairs of CBSDs where the vertices representing the two CBSDs are connected with an edge.
For CBSDs registering and requesting spectrum during the day (prior to the daily activity schedule), in a Spectrum Inquiry Request, the CSAS may provide the following possible channels for consideration, listed in no priority order. (Note: The SAS has the final authority on what spectrum to grant CBSDs that it manages.) For initial deployment, the CxM may not be operational for spectrum inquiry objects during the day.
Note 1: These are included in the list for completeness; however, most likely the CxM is not aware of other CxGs (non CBRS-Alliance CxGs) or incumbents (which would be higher tier users), thus the CxM would not know if these channels are available. The CSAS would need to decide if these channels are available.
Section 5.1.2 requires all LTE-TDD and NR-TDD CBSDs that are part of the same TDD Configuration Connected Set to use the same the same TDD Configuration or Equivalent TDD Configurations. The TDD Configuration Connected Set shall be similar to the Channel Assignment Connected Sets built by forming edges between CBSDs that have overlap of their respective - 96dBm/10 MHz contours. Note that the TDD Configuration Connected Set that the CxM constructs can be different from the Channel Assignment Connected Sets discussed in Section 6.1, which the CxM constructs for a different purpose. For example, these Connected Sets can be different in the case where indoor CBSDs opt out of the TDD Configuration Connected Set. Unless all the CBSDs in the TDD Configuration Connected Set have specified the same desired TDD Configuration, the choice of a particular mandatory TDD configuration in the corresponding TDD Configuration Connected Set shall be based on the designation of a single fallback choice for TDD Configuration that is chosen from Table 1 (which corresponds to an NR Equivalent TDD Configuration from Table 2 for SCS=30 kHz). The TDD Configuration shall be chosen by majority voting among the fallback TDD Configurations specified by CBSDs within the constructed baseline TDD Configuration Connected Set, where ties are resolved by a pseudorandom draw. The desired TDD Configuration and the fallback configuration, as well as the desired NR-TDD Configuration, are specified by the CBSD as attributes in the grouping parameter associated with CBRSA CxG.
Indoor CBSDs deployed as per the CBRSA Indoor deployment guidelines [23], shall have the option of informing the CxM of its desire to opt out of TDD Configuration Connected Sets used for TDD Configuration determination. An Indoor CBSD shall inform the CxM of its request to opt out via the attributes in the grouping parameters. Indoor CBSDs which select to opt out are not exempt from applying any mandatory TDD Configuration if requested by the CxM. The CxM shall request Indoor CBSDs to employ the mandatory TDD Configurations only when harmful interference [24] scenarios originated by the Indoor CBSDs are reported. The CxM shall consider fallback TDD preferences of Indoor CBSDs which have requested to opt out, if these CBSDs are going to be mandated a TDD Configuration.
An NR CBSD, capable of supporting NR-TDD Configurations that are not compatible with LTE-TDD Configurations, may specify the desired NR-TDD Configuration to the CxM. If, and only if, all the CBSDs in a TDD Configuration Connected Set specify the same NR-TDD Configuration, then the CxM shall allow that NR-TDD Configuration to be used by the members of the TDD Configuration Connected Set. If, at a later time, a new CBSD joins the TDD Configuration Connected Set, and the new CBSD does not desire to use a NR-TDD Configuration or desires to use a different NR-TDD Configuration, then the CxM shall change the TDD Configuration used in the TDD Configuration Connected Set to one of the mandatory TDD Configurations.
After determination of the TDD Configuration by the CxM for a given TDD Configuration Connected Set according to Section 6.3.1, the CxM shall recognize one of the following:
The CxM shall determine the new TDD Configuration to impose on the CBSDs that are part of the TDD Configuration Connected Set, either a desired TDD Configuration, or the fallback TDD Configuration. When CBSDs are being removed, the CxM will select the planned activation of a fallback TDD Configuration.
When adding a new CBSD to a TDD Configuration Connected Set, the CBSD shall be assigned initially to a single TDD Configuration Connected Set that has the greatest affinity to the CBSD; this is indicated by the edge corresponding to the highest estimated interference connection to the CBSD.
After the initial assignment, the CxM shall over time determine whether two or more TDD Configuration Connected Sets bear merging due to the introduction of the CBSD, for example during occurrences of the Cooperative Periodic Activities among SASs (CPAS) [21] process for the CxG. The decision of whether and when to reconcile will consider additional factors such as a possible change of TDD Configuration for one or more TDD Configuration Connected Sets. The exact schedule of such reconfigurations is an operational matter that is left to the discretion of the CxM.
When the CxM has identified the need for a change in TDD Configuration in a TDD Configuration Connected Set, it shall inform the SAS entity in the CSAS, and the CSAS shall terminate the grant(s) as part of the daily CPAS schedule for the CxG. The CBSD should modify its grant request(s) to reflect the new TDD Configuration as informed by the CxM. A Grant request in violation of the agreements for the CxG or the TDD Configuration Connected Set should be rejected according to the coexistence decision made by the CxM.
Synchronized CBSDs that use the same TDD Configuration do not need guard bands between cosituated CBSDs using different channels. Co-situated CBSDs are CBSDs sharing the same physical site and potentially the same antenna, i.e. sharing infrastructure or in close physical proximity.
Co-situated CBSDs that do not belong to the same ICG shall not be assigned the same frequency.
CxM should maximize the frequency separation between different ICGs as necessary.
Identified cases of harmful interference [24] may be handled by the CxM (e.g. channel reassignment, increased frequency separation, revoking opt out privileges, facilitating exchange of data) in collaboration with affected operators.
To facilitate management of the CBRSA CxG by the CxM, all CBSDs that declare themselves to be part of the CBRSA CxG exchange information with the CxM. This is accomplished by including this information in JSON objects known as CBRS Alliance Coexistence Objects transported by using various existing messages of the SAS-CBSD protocol [6] and SAS-SAS protocol [14] as needed.
The CBSD and the CSAS shall support:
The CBRS Alliance Coexistence Objects are:
In the CBSD/DP to CxM direction, the CbrsAllianceInfo object is contained in the groupInfo parameter of the GroupParam data object [6].
In the CxM to CBSD/DP direction, the CbrsAllianceConfig object is contained in the groupConfigInfo parameter of the GroupConfig data object [6]. The details are in the following subsections.
A CBSD may send grouping information to a CxM by including the groupingParam parameter in the RegistrationRequest, the SpectrumInquiryRequest, the GrantRequest or the HeartbeatRequest object [6]. The groupingParam parameter and its content are defined in [6].
An LTE-TDD or NR-TDD CBSD shall indicate membership in the CBRSA CxG by use of a single instance of the GroupParam object. In particular, it shall set groupType to "COEXISTENCE_GROUP" and groupId to "CBRS_ALLIANCE" in the GroupParam object.
GroupInfo is a data object that enables CBSD/DP to share its group information in addition to groupType and groupId as specified in [6] and [15]. The GroupInfo object and its content are specified in Table 3 to Table 14.
Table 3: GroupInfo Object Definition
| Parameter | R/O/C | Parameter Information |
|---|---|---|
NAME: cbrsAllianceInfo DATA TYPE: object: CbrsAllianceInfo | Required | This parameter includes additional group information of the CBRSA CxG. |
NAME: cbrsaVersion DATA TYPE: string | Required | This parameter indicates the version of the CBRSA Coexistence Objects(s) implemented by the CBSD/DP. The version of CBRSA Coexistence Objects sent to the CBSD/DP shall be the same as the version of the CbrsAllianceInfo object from the CBSD/DP. In this version of this specification, this parameter shall be set to the value "v3.2". |
NAME: desiredTddConfig DATA TYPE: object: EutraTddConfig | Optional | This parameter indicates the desired E-UTRA TDD Configuration or its NR Equivalent TDD Configuration. |
NAME: desiredNrTddConfig DATA TYPE: object: NrTddConfig | Optional | This parameter indicates the desired NR-TDD Configuration. It is used only by CBSDs that desire to use an NR-TDD Configuration not compatible with LTE-TDD (otherwise, for NR Equivalent TDD Configurations, the desiredTddConfig parameter shall be used). If all CBSDs in a TDD Configuration Connected Set specify the desiredNrTddConfig with the same NR TDD Configuration value, then the CxM shall allow this NR TDD Configuration to be used in the TDD Configuration Connected Set. |
NAME: usedTddConfig DATA TYPE: object: EutraTddConfig | Conditional | This parameter shall be included in the GrantRequest object, indicating the E-UTRA TDD Configuration or its NR Equivalent TDD Configuration to be used for the grant. This parameter shall not be included when usedNrTddConfig is included in this object. |
NAME: usedNrTddConfig DATA TYPE: object: NrTddConfig | Conditional | This parameter shall be included in the GrantRequest object, indicating the NR-TDD Configuration to be used for the grant. This parameter shall be specified only if the CBSD has previously received permission from CxM, in the CbrsAllianceConfig object, to use an NR-TDD Configuration that is not compatible with the LTE-TDD. This parameter shall not be included when usedTddConfig is included in this object. |
NAME: fallbackTddConfig DATA TYPE: object: EutraTddConfig | Optional | This parameter indicates the fallback E-UTRA TDD Configuration or its NR Equivalent TDD Configuration from the allowed mandatory choices in Table 1. If fallbackTddConfig is not provided by a CBSD, the CxM shall assume Configuration 2 in Table 1 or its NR Equivalent TDD Configuration as the fallbackTddConfig for that CBSD. |
NAME: cbrsaGroupingParam DATA TYPE: array of object: CbrsaGroupParam | Optional | The CBSD can optionally indicate its membership of group types defined by the CBRSA. |
NAME: cellInfo DATA TYPE: array of object: SignalInfo | Conditional | This parameter includes information about the signals transmitted by the CBSD. This parameter is included in a heartbeat request as described in Section 5.2. |
NAME: coexMeasInfo DATA TYPE: object: CoexMeasInfo | Optional | This parameter includes coexistence related measurement information. |
NAME: indoorCbsdOptOut DATA TYPE: Boolean | Optional | Indoor CBSDs may use this parameter to indicate if they request to opt out of TDD Configuration Connected Sets. True: Indoor CBSD selects to opt out False: Indoor CBSD selects not to opt out The default value of this parameter is False. |
NAME: ulDLConfig DATA TYPE: number | Required | Permitted values are 0, 1, 2, 3, 4, 5, and 6. This parameter represents either E-UTRA TDD UL/DL configuration [4] or the corresponding NR TDD Equivalent Configurations. In the case of the fallbackTddConfig, permitted values are restricted as per Table 1 (see section 5.1.2 for more details)4 |
NAME: ssfConfig DATA TYPE: number | Required | Permitted values are 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, and 10. This parameter represents E-UTRA TDD special subframe configuration [4] and can also be adapted by NR TDD CBSDs to ensure an NR TDD Equivalent Configuration. In the case of the fallbackTddConfig, permitted value is 7 (see section 5.1.2 for more details)4 |
Table 4: CbrsAllianceInfo Object Definition
| Parameter | R/O/C | Parameter Information |
|---|---|---|
NAME: cbrsaVersion DATA TYPE: string | Required | This parameter indicates the version of the CBRSA Coexistence Objects(s) implemented by the CBSD/DP. The version of CBRSA Coexistence Objects sent to the CBSD/DP shall be the same as the version of the CbrsAllianceInfo object from the CBSD/DP. In this version of this specification, this parameter shall be set to the value "v3.2". |
NAME: desiredTddConfig DATA TYPE: object: EutraTddConfig | Optional | This parameter indicates the desired E- UTRA TDD Configuration or its NR Equivalent TDD Configuration. |
NAME: desiredNrTddConfig DATA TYPE: object: NrTddConfig | Optional | This parameter indicates the desired NR- TDD Configuration. It is used only by CBSDs that desire to use an NR-TDD Configuration not compatible with LTE- TDD (otherwise, for NR Equivalent TDD Configurations, the desiredTddConfig parameter shall be used). If all CBSDs in a TDD Configuration Connected Set specify the desiredNrTddConfig with the same NR TDD Configuration value, then the CxM shall allow this NR TDD Configuration to be used in the TDD Configuration Connected Set. |
NAME: usedTddConfig DATA TYPE: object: EutraTddConfig | Conditional | This parameter shall be included in the GrantRequest object, indicating the E- UTRA TDD Configuration or its NR Equivalent TDD Configuration to be used for the grant. This parameter shall not be included when usedNrTddConfig is included in this object. |
NAME: usedNrTddConfig DATA TYPE: object: NrTddConfig | Conditional | This parameter shall be included in the GrantRequest object, indicating the NR- TDD Configuration to be used for the grant. This parameter shall be specified only if the CBSD has previously received permission from CxM, in the CbrsAllianceConfig object, to use an NR- TDD Configuration that is not compatible with the LTE-TDD. This parameter shall not be included when usedTddConfig is included in this object. |
NAME: fallbackTddConfig DATA TYPE: object: EutraTddConfig | Optional | This parameter indicates the fallback E- UTRA TDD Configuration or its NR Equivalent TDD Configuration from the allowed mandatory choices in Table 1. If fallbackTddConfig is not provided by a CBSD, the CxM shall assume Configuration 2 in Table 1 or its NR Equivalent TDD Configuration as the fallbackTddConfig for that CBSD. |
NAME: cbrsaGroupingParam DATA TYPE: array of object: CbrsaGroupParam | Optional | The CBSD can optionally indicate its membership of group types defined by the CBRSA. |
NAME: cellInfo DATA TYPE: array of object: SignalInfo | Conditional | This parameter includes information about the signals transmitted by the CBSD. This parameter is included in a heartbeat request as described in Section 5.2. |
NAME: coexMeasInfo DATA TYPE: object: CoexMeasInfo | Optional | This parameter includes coexistence related measurement information. |
NAME: indoorCbsdOptOut DATA TYPE: Boolean | Optional | Indoor CBSDs may use this parameter to indicate if they request to opt out of TDD Configuration Connected Sets. True: Indoor CBSD selects to opt out False: Indoor CBSD selects not to opt out The default value of this parameter is False. |
Table 5: EutraTddConfig Object Definition
| Parameter | R/O/C | Parameter Information |
|---|---|---|
NAME: ulDLConfig DATA TYPE: number | Required | Permitted values are 0, 1, 2, 3, 4, 5, and 6. This parameter represents either E-UTRA TDD UL/DL configuration [4] or the corresponding NR TDD Equivalent Configurations. In the case of the fallbackTddConfig, permitted values are restricted as per Table 1 (see section 5.1.2 for more details)4. |
NAME: ssfConfig DATA TYPE: number | Required | Permitted values are 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, and 10. This parameter represents E- UTRA TDD special subframe configuration [4] and can also be adapted by NR TDD CBSDs to ensure an NR TDD Equivalent Configuration. In the case of the fallbackTddConfig, permitted value is 7 (see section 5.1.2 for more details)4. |
Table 6: NrTddConfig Definition
| Parameter | R/O/C | Parameter Information |
|---|---|---|
NAME: subcarrierSpacing DATA TYPE: string | Required | NR subcarrier spacing in kHz. The permitted values are “kHz15” and “kHz30”, representing 15 kHz and 30 kHz subcarrier spacing, respectively. |
NAME: nrTddUlDlPattern1 DATA TYPE: NrTddUIDIPattern | Required | NR TDD UL-DL Pattern, similar to the one defined in [20] (section describing TDD-UL-DL-Config information element) |
NAME: nrTddUlDlPattern2 DATA TYPE: NrTddUIDIPattern | Optional | NR TDD UL-DL Pattern, similar to the one defined in [20] (section describing TDD-UL-DL-Config information element) |
| NAME: dlUlTransmissionPeriodicity DATA TYPE: string | Required | Periodicity of the DL-UL pattern in milliseconds. Permitted values are "ms0p5", "ms1”, “ms2”, “ms2p5”, “ms3", "ms4", "ms5", "ms10". |
NAME: nrofDownlinkSlots DATA TYPE: number | Required | Number of consecutive full DL slots at the beginning of each DL-UL pattern. Maximum value is 20. This parameter is an integer number. |
NAME: nrofDownlinkSymbols DATA TYPE: number | Required | Number of consecutive DL symbols in the beginning of the slot following the last full DL slot (as derived from nrofDownlinkSlots). The value 0 indicates that there is no partial-downlink slot. The symbols after the last DL symbol and before the first UL symbol, are considered to be guard symbols with no UL or DL signal being transmitted. The maximum number of symbols in a slot is 14. This parameter is an integer number. |
NAME: nrofUplinkSlots DATA TYPE: number | Required | Number of consecutive full UL slots at the end of each DL-UL pattern. Maximum value is 20. This parameter is an integer number. |
NAME: nrofUplinkSymbols DATA TYPE: number | Required | Number of consecutive UL symbols in the end of the slot preceding the first full UL slot (as derived from nrofUplinkSlots). The value 0 indicates that there is no partial-uplink slot. The maximum number of symbols in a slot is 14. The symbols after the last DL symbol and before the first UL symbol, are considered to be guard symbols with no UL or DL signal being transmitted. This parameter is an integer number. |
NAME: cbrsaGroupType DATA TYPE: string | Required | Allowed values are "CBRSA_ICG" or “CBRSA_CCG”. If cbrsaGroupType is set to "CBRSA_ICG”, the CBSD belongs to an Interference Coordination Group (ICG) defined by the CBRSA. If cbrsaGroupType is set to “CBRSA_CCG", the CBSD belongs to a Common Channel Group (CCG). A CBSD shall belong to at most one ICG and at most one CCG. |
NAME: cbrsaGroupId DATA TYPE: string | Required | This field specifies the identifier for this group of CBSDs. cbrsaGroupId shall be the concatenation of CBSD userId (as defined in [6]) and a string chosen by the user to uniquely identify the group among CBSDs with the same userId. |
Note: Table 2 describes the NR TDD Configurations for NR SCS=30 kHz that are equivalent to the mandatory E-UTRA TDD Configurations specified in Table 1. Likewise, Figure 1 only specifies the special slot configuration for NR SCS=30 kHz which is equivalent to the LTE SSF7.
Table 7: NrTddUlDlPattern Definition
| Parameter | R/O/C | Parameter Information |
|---|---|---|
NAME: dlUlTransmissionPeriodicity DATA TYPE: string | Required | Periodicity of the DL-UL pattern in milliseconds. Permitted values are "ms0p5", "ms1", "ms2", "ms2p5", "ms3", "ms4", "ms5", "ms10". |
NAME: nrofDownlinkSlots DATA TYPE: number | Required | Number of consecutive full DL slots at the beginning of each DL-UL pattern. Maximum value is 20. This parameter is an integer number. |
NAME: nrofDownlinkSymbols DATA TYPE: number | Required | Number of consecutive DL symbols in the beginning of the slot following the last full DL slot (as derived from nrofDownlinkSlots). The value 0 indicates that there is no partial-downlink slot. The symbols after the last DL symbol and before the first UL symbol, are considered to be guard symbols with no UL or DL signal being transmitted. The maximum number of symbols in a slot is 14. This parameter is an integer number. |
NAME: nrofUplinkSlots DATA TYPE: number | Required | Number of consecutive full UL slots at the end of each DL-UL pattern. Maximum value is 20. This parameter is an integer number. |
NAME: nrofUplinkSymbols DATA TYPE: number | Required | Number of consecutive UL symbols in the end of the slot preceding the first full UL slot (as derived from nrofUplinkSlots). The value 0 indicates that there is no partial-uplink slot. The maximum number of symbols in a slot is 14. The symbols after the last DL symbol and before the first UL symbol, are considered to be guard symbols with no UL or DL signal being transmitted. This parameter is an integer number. |
Table 8: CbrsaGroupParam Definition
| Parameter | R/O/C | Parameter Information |
|---|---|---|
NAME: cbrsaGroupType DATA TYPE: string | Required | Allowed values are "CBRSA_ICG" or "CBRSA_CCG". If cbrsaGroupType is set to "CBRSA_ICG", the CBSD belongs to an Interference Coordination Group (ICG) defined by the CBRSA. If cbrsaGroupType is set to "CBRSA_CCG", the CBSD belongs to a Common Channel Group (CCG). A CBSD shall belong to at most one ICG and at most one CCG. |
NAME: cbrsaGroupId DATA TYPE: string | Required | This field specifies the identifier for this group of CBSDs. cbrsaGroupId shall be the concatenation of CBSD userId (as defined in [6]) and a string chosen by the user to uniquely identify the group among CBSDs with the same userId. |
Table 9: SignalInfo Object Defintion
| Parameter | R/O/C | Parameter Information |
|---|---|---|
NAME: eutraInfo DATA TYPE: object: EutraInfo | Required | Indicates information on an E-UTRA signal or E-UTRA compatible NR signal. |
Table 10: EutraInfo Object Definition
| Parameter | R/O/C | Parameter Information |
|---|---|---|
NAME: signalEarfcn DATA TYPE: number | Required | Indicates the EARFCN of the LTE signal or NR-ARFCN of the NR signal. For signalRat = LTE, permitted values are integers between 55240 and 56739 inclusive. For signalRat = NR, permitted values are even integers between 636668 and 646666. |
NAME: signalRat DATA TYPE: string | Conditional | Indicates the RAT associated with the signal. When used in the cellInfo parameter of the CbrsAllianceInfo object, the allowed values are "LTE" and "NR". Otherwise, allowed values are "LTE", "NR", and "UNKNOWN". This parameter shall be included if used in the cellInfo parameter of the CbrsAllianceInfo object. |
NAME: signalPci DATA TYPE: number | Conditional | Indicates the PCI associated with the signal. For signalRat = LTE, permitted values are integers between 0 and 503 inclusive. For signalRat = NR, permitted values are integers between 0 and 1007 inclusive. This parameter shall be included if the EutraInfo object carries information of the transmitted signal. This parameter shall be included if used in the cellInfo parameter of the CbrsAllianceInfo object. |
NAME: signalEcgi DATA TYPE: string | Conditional | For signalRat = LTE, indicates the ECGI associated with the signal. It is a string of length 52, containing O's and 1's. For signalRat = NR, indicates the NCGI associated with the signal. It is a string length 60, containing O's and 1's. This parameter shall be included if the EutraInfo object carries information of the transmitted signal. This parameter shall be included if used in the cellInfo parameter of the CbrsAllianceInfo object. |
NAME: signalBandwidth DATA TYPE: number | Required | Indicates the bandwidth of the signal. Bandwidth of the signal is in 100's of kHz (E.g. number 200 indicates bandwidth of 20MHz). |
NAME: channelReport DATA TYPE: array of object: ChannelReport | Optional | Provides CxM reports about a set of channels |
NAME: signalReport DATA TYPE: array of object: SignalReport | Optional | Provides CxM reports about a set of detected signals |
Table 11: CoexMeasInfo Object Definition
| Parameter | R/O/C | Parameter Information |
|---|---|---|
NAME: channelReport DATA TYPE: array of object: ChannelReport | Optional | Provides CxM reports about a set of channels |
NAME: signalReport DATA TYPE: array of object: SignalReport | Optional | Provides CxM reports about a set of detected signals |
Table 12: ChannelReport Object Definition
| Parameter | R/O/C | Parameter Information |
|---|---|---|
NAME: channelFrequencyRange DATA TYPE: object: FrequencyRange | Required | Indicates the frequency range of the reported channel. |
NAME: channelUsability DATA TYPE: string | Optional | Permitted values are "USABLE", "UNUSABLE" and "UNKNOWN". Indicated values should only be interpreted as relative comparison between channel usabilities reported by CBSDs belonging to the same CCG and ICG. |
NAME: channelRssi DATA TYPE: number | Optional | Indicates the estimated RSSI of the channel in dBm. Permitted values are integers between -110 and -19 (including - 110 and -19). Indicated values should only be interpreted as relative comparison between channel RSSIs reported by CBSDs belonging to the same CCG and ICG. |
NAME: measurementInterval DATA TYPE: object: TimeInterval | Optional | This parameter indicates the time interval when the measurement included in the ChannelReport object is performed. |
Table 13: TimeInterval Object Definition
| Parameter | R/O/C | Parameter Information |
|---|---|---|
NAME: startTime DATA TYPE: string | Required | Indicates the beginning of a time interval. This parameter is UTC time expressed in the format, YYYY-MM DDThh:mm:ssZ as defined by [13]. |
NAME: endTime DATA TYPE: string | Required | Indicates the end of a time interval. This parameter is UTC time expressed in the format, YYYY-MM DDThh:mm:ssZ as defined by [13]. |
Table 14: SignalReport Object Definition
| Parameter | R/O/C | Parameter Information |
|---|---|---|
NAME: detectedSignalInfo DATA TYPE: object: SignalInfo | Required | Provides information about the detected signal |
NAME: signalTolerability DATA TYPE: string | Optional | Indicates the tolerance to interference from the reported signal. Permitted values are "TOLERABLE", INTOLERABLE" and "UNKNOWN". |
NAME: cbsdSignalRsrp DATA TYPE: number | Optional | Indicates the estimated RSRP of the detected downlink LTE waveform or estimated SS-RSRP of the detected downlink NR waveform. Permitted values are integers between -17 and 97 (including -17 and 97). The value is based on measurement at the CBSD. |
NAME: cbsdSignalRsrq DATA TYPE: number | Optional | Indicates the estimated RSRQ of the detected downlink LTE waveform or estimated SS-RSRQ of the detected downlink NR waveform. Permitted values are integers between -30 and +46 (including -30 and +46). The value is based on measurement at the CBSD. |
NAME: ueSignalRsrpHistogram DATA TYPE: array of number | Optional | A length-48 array, where each element indicates number of occurrences of UE-reported RSRP for this LTE signal or SS-RSRP for this NR signal that fall within each bin i, i =0,...,47. The RSRP range for each bin is as specified in [10], Section 6.1. |
NAME: ueSignalRsrqHistogram DATA TYPE: array of number | Optional | A length-18 array, where each element indicates number of occurrences $N_i$ of UE-reported RSRQ for this LTE signal or SS-RSRQ for this NR signal that fall within each bin i, i =0,...,17. The RSRQ range for each bin is as specified in [10], Section 6.2. |
NAME: measurementInterval DATA TYPE: object: TimeInterval | Optional | This parameter indicates the time interval when the measurement(s) included in the SignalReport object is performed. |
Based on the CBRSA Coexistence policies, described in Section 6.3, a CxM may suggest coexistence parameters for a CBSD by using the GroupConfigInfo object in the groupingConfig parameter in the RegistrationResponse, the SpectrumInquiryResponse, the GrantResponse, or the HeartbeatResponse object [6]. The GroupConfigInfo object and its content are defined in Table 15 to Table 18.
Table 15: GroupConfigInfo Object Definition
| Parameter | R/O/C | Parameter Information |
|---|---|---|
NAME: cbrsAllianceConfig DATA TYPE: object: CbrsAllianceConfig | Optional | This parameter is included if the CxM intends to configure the CBSD with specified coexistence parameter values. |
NAME: cbrsaVersion DATA TYPE: string | Required | This parameter indicates the version of the CBRSA Coexistence Objects(s) sent to the CBSD/DP. The version of CBRSA Coexistence Objects sent to the CBSD/DP shall be the same as the version of the CbrsAllianceInfo object from the CBSD/DP. |
NAME: eutraTddConfig DATA TYPE: object: EutraTddConfig | Optional | If included, this parameter specifies the E- UTRA TDD Configuration or its NR Equivalent TDD Configuration that the CBSD shall use for all its grants. |
NAME: nrTddConfig DATA TYPE: object: NrTddConfig | Optional | If included, this parameter specifies the NR-TDD Configuration that the CBSD shall use for all its grants. This parameter may be included by the CxM if the eutraTddConfig parameter is not present. |
NAME: coexMeasAssist DATA TYPE: object: CoexMeasAssist | Optional | The CxM uses this parameter to send assistance information for coexistence measurements to the CBSD |
NAME: cbsdFrequencyGuidance DATA TYPE: array of object: FrequencyRange | Optional | CxM uses this parameter to provide guidance on the frequency range(s) the CBRSA CxG CBSD is instructed to request and use going forward. Upon receiving this information, the CBRSA CxG CBSD is expected to only request and hold spectrum grants that are within the received cbsdFrequencyGuidance. In the scenario where the guidance last received from the SpectrumInquiryResponse -> availableChannel object is in conflict with the last received cbsdFrequencyGuidance, the CBSD should follow the latter for determining the frequencies on which to request spectrum grants. |
NAME: channelAssistance DATA TYPE: FrequencyRange | Optional | Indicates the frequency range of the reported channel. |
NAME: signalAssistance DATA TYPE: array of object: SignalInfo | Optional | The CxM uses this parameter to inform CBSD the list of signals the CxM is interested about. |
Table 16: CbrsAllianceConfig Object Definition
| Parameter | R/O/C | Parameter Information |
|---|---|---|
NAME: cbrsaVersion DATA TYPE: string | Required | This parameter indicates the version of the CBRSA Coexistence Objects(s) sent to the CBSD/DP. The version of CBRSA Coexistence Objects sent to the CBSD/DP shall be the same as the version of the CbrsAllianceInfo object from the CBSD/DP. |
NAME: eutraTddConfig DATA TYPE: object: EutraTddConfig | Optional | If included, this parameter specifies the E- UTRA TDD Configuration or its NR Equivalent TDD Configuration that the CBSD shall use for all its grants. |
NAME: nrTddConfig DATA TYPE: object: NrTddConfig | Optional | If included, this parameter specifies the NR-TDD Configuration that the CBSD shall use for all its grants. This parameter may be included by the CxM if the eutraTddConfig parameter is not present. |
NAME: coexMeasAssist DATA TYPE: object: CoexMeasAssist | Optional | The CxM uses this parameter to send assistance information for coexistence measurements to the CBSD |
NAME: cbsdFrequencyGuidance DATA TYPE: array of object: FrequencyRange | Optional | CxM uses this parameter to provide guidance on the frequency range(s) the CBRSA CxG CBSD is instructed to request and use going forward. Upon receiving this information, the CBRSA CxG CBSD is expected to only request and hold spectrum grants that are within the received cbsdFrequencyGuidance. In the scenario where the guidance last received from the SpectrumInquiryResponse -> availableChannel object is in conflict with the last received cbsdFrequencyGuidance, the CBSD should follow the latter for determining the frequencies on which to request spectrum grants. |
Inclusion of a parameter to indicate primary or expansion channels is FFS.
Table 17: CoexMeasAssist Object Definition
| Parameter | R/O/C | Parameter Information |
|---|---|---|
NAME: measInterval DATA TYPE: object: TimeInterval | Optional | This parameter indicates the time interval for which the CBSD shall report coexistence measurements. |
NAME: measFrequencyRange DATA TYPE: array of object: FrequencyRange | Optional | This parameter indicates the frequency range(s) for which the CBSD shall report coexistence measurements. |
Table 18: FrequencyRange Object Definition
| Parameter | R/O/C | Parameter Information |
|---|---|---|
NAME: lowFrequency DATA TYPE: number | Required | The lowest frequency of the frequency range in Hz. |
NAME: highFrequency DATA TYPE: number | Required | The highest frequency of the frequency range in Hz. |
Table 19: Change History
| Version | Date | Description |
|---|---|---|
| r1 (towards V3.0.0) | July 19, 2019 | Incorporate approved contributions for NR Coex WI: C-TG-19-431_2019.06.27_Nokia_Technical.Rel 3 NR Config Signaling (approved) C-TG-19-410_2019.04.11_Nokia_Technical.NR Config for GAA r2 (approved for Rel 3). |
| R2 (towards V3.0.0) | Aug 28, 2019 | Incorporate approved contributions for NR Coex WI: C-TG-19-436_2019.07.11_Ericsson_CR.NR TDD Configuration_r3 C-TG-19-450_2019.08.07_Nokia_Technical.NR RACH SCS and DCI Format 2_0 (approved).docx |
| r3 (towards V3.0.0) | September 18, 2019 | Incorporate approved contribution for V2.1.0: C-TG-19-415_2019.04.25_Nokia_CR.Connected Set for TDD Config Part 2 (Approved for Rel 2.x) C-TG-19-393_2019.02.21_Nokia_CR.TDD Config for New CBSD (approved) C-TG-19-394_2019.02.22_Nokia_CR.Fallback ssfConfig Value (approved) C-TG-19-397_2019.02.28_Nokia_CR.Connected Set for TDD Config (approved) C-TG-19-398_2019.02.28_CommScope-FW-Google_CR.Connected Set for TDD Config (approved) C-TG-19-387_2019.02.08_Ericsson_CR.CBSD Identification Information_r1 C-TG-19-388_2019.02.13_Commscope_CR.CXM-002-Channel Assignment_r0 |
| r4 (towards V3.0.0) | October 16, 2019 | Use the new OnGo spec template. Incorporate approved contribution C-TG-19- 475_2019.10.03_Nokia_Technical.TP_Indoor_Coex(approved).docx |
| r5 (towards V3.0.0) | December 12, 2019 | Implement agreements of resolved ballot comments on CBRSA-TS 2001-V2.0.0-r4 (towards V3.0.0). |
| V3.0.0 | February 18, 2020 | Version approved for publication |
| r1 (towards V3.1.0) | March 23, 2020 | Incorporate approved contribution to allow use of 15 kHz SSC for NR: C-TG-20-506_2020.02.06_Nokia_Technical.5G NR SCS-limited TDD patterns_r4(approved).docx |
| Version | Date | Description |
| r2 (towards V3.1.0) | March 30, 2020 | Incorporate the following approved contributions: C-TG-20-516_2020.03.20_Ericsson_CR.Align with WinnF Rel 2.docx C-TG-20-517_2020.03.26_Nokia_Technical.GAA Channelization Considerations for NR.pptx |
| r3 (towards V3.1.0) | May 4, 2020 | Implement all resolutions for ballot comments on the version towards V3.1.0. |
