Dynamic single frequency group for cbsds

Abstract

A system for optimizing Citizens Broadband Radio Service (CBRS) network having a Spectrum Access System (SAS) and plurality of CBRS devices (CBSDs) includes: a CBSD controller; and a channel selector (CS) configured to: i) request, via the CBSD controller, CBSDs of a first operator to report interference caused by CBSDs of other operators on a plurality of channels; ii) identify, based on the reports from the CBSDs of the first operator, a list of available low- interference channels exhibiting interference levels below a specified threshold level; iii) determine, from the list of low-interference channels, at least one common channel satisfying a required minimum bandwidth to serve as a single frequency group (SFG) for all CBSDs of the first operator; and iv) request the CBSD controller to acquire the at least one common channel from the SAS to configure the SFG.

Description

Dynamic Single Frequency Group for CBSDs BACKGROUND OF THE DISCLOSURE1. Field of the Disclosure

[0001] The present disclosure is related to 4G LTE and 5G NR-based Citizens Broadband RadioService (CBRS) networks and Open Radio Access Network (O-RAN), and relates more particularly to dynamically choosing common CBRS channels for CBRS devices (CBSDs) to avoid interference.2. Description of Related Art

[0002] Citizens Broadband Radio Service (CBRS) is a wireless communication technology thatoperates in the 3.5 GHz band. CBRS was established by the Federal Communications Commission (FCC) in the United States to create a shared spectrum approach for wireless communication. CBRS is designed to support a wide range of applications, e.g., broadband access, Internet of Things (IoT) devices, and private wireless networks.

[0003] As shown in FIG. 1, which illustrates the CBRS architecture, the spectrum is allocatedand controlled by Spectrum Access System (SAS) 101. The CBRS devices (CBSDs) 103 and Domain Proxy (DP) 102 have an interface (referenced as “WinnForum SAS-CBSD / DP Interface” in FIG.1) with the SAS 101 for this function. The interface is defined by WinnForum standard. Base Station (BS) is the RAN implementation that manages RAN protocol and operations facilitating communication between mobile devices and the network's core infrastructure. The DP is a logical entity engaging in communications with the SAS on behalf of multiple individual CBSDs or networks of CBSDs. The DP can also provide a translational capability to interface legacy radio equipment in the 3650-3700 MHz band with a SAS to ensure compliance with the regulations specified in Title 47 of the Code of Federal Regulations (CFR), § 96 (hereinafter referred to as 47 CFR § 96). The DP presents a consistent and secure interface to the SAS that can convey all messages pertaining to the SAS-CBSD interface for client CBSDs. CBSD aggregation and proxy function for large networks can be integrated within aService Management and Orchestration (SMO) system or in a standalone node. SAS 101 is a system that authorizes and manages use of spectrum for the CBRS in accordance with the regulations specified in 47 CFR § 96. Once the CBSD acquires Grants from the SAS, it can use LTE, NR or any wireless protocol to communicate with its UE. LTE CBRS is the CBRS system that uses LTE as the wireless protocol and NR CBRS is the CBRS system that uses NR as the wireless protocol.

[0004] A CBSD is part of the BS mapped to the radio unit (RU) and operates within the CBRSband, and the CBSD is further responsible for accessing, managing, and utilizing the spectrum resources. When a BS is configured for multiple sectors, each with different RUs, then the BS would have multiple CBSDs mapped to respective RUs.

[0005] The CBRS spectrum is divided into three tiers: 1) Incumbent Access; 2) Priority AccessLicense (PAL); and 3) General Authorized Access (GAA). Incumbent Access tier is reserved for the existing government and military users in the 3.5 GHz band. Priority Access License (PAL) tier, which is designed for commercial users who have obtained a license for the frequency band, is used for large-scale wireless networks and high-speed broadband. General Authorized Access (GAA) tier, which is available for unlicensed users who can access the frequency band on a non- interference basis, is designed for small-scale wireless networks and IoT devices.

[0006] FIG. 2 shows an example Grant State Machine for CBRS. Each Grant, represented by aGrantId, has its own state machine. The Grant State Machine is in the Idle state 201 if a Grant has not been approved by the SAS. A CBSD can send the SAS a GrantRequest object. If a Grant request is approved by the SAS, the SAS will send a GrantResponse object. Upon reception of a successful GrantResponse object from the SAS, the Grant State Machine transitions to Granted state 202. In Granted state, a GrantId is assigned, operational parameters are defined, and a channel is allocated. A CBSD with a Grant that is ready to commence radio frequency (RF) transmission commences Heartbeat procedure associated with the Grant by sending HeartbeatRequest object. If the SAS approves a Heartbeat Request, the SAS sends a HeartBeatResponse object authorizing the transmission. Upon reception of a successful HeartbeatResponse object, the Grant State Machine transitions to the Authorized state 203. In the Authorized state 203, the CBSD is permitted to commence RF transmission and operate in theCBRS band using the operational parameters specific to that Grant. If a CBSD receives multiple Grants, individual state machines are kept for each Grant, and individual heartbeat requests need to be sent for each Grant, possibly aggregated in a single transmission to the SAS.

[0007] The Grant State Machine transitions from the Authorized state 2003 back to the Grantedstate 2002 if the Grant is suspended by the SAS or the transmission right, as defined by the transmitExpireTime parameter in the HeartbeatResponse object, has expired. The Grant State Machine transitions to Idle state 2001 if a Grant is terminated by the SAS, relinquished by the CBSD, or expired as defined in the grantExpireTime parameter, or the SAS-to-CBSD connectivity is lost.

[0008] FIG. 3 is a signal-flow diagram illustrating an example CBRS procedure. When theCBSD 103 (e.g., O-RU) starts-up, it will register with the SAS 101 by sending a RegistrationRequest object, as shown by 301a. The RegistrationRequest object includes operational parameters of the CBSD (e.g., O-RU), including identity of the CBSD and its physical location (latitude, longitude, altitude). The SAS 101 will accept the registration by sending a RegistrationResponse object, as shown by 301b. In order to be able to find out which channels are available in the area where the CBSD 103wants to transmit, the CBSD 103 performs the Spectrum Inquiry procedure, as shown by 302a and 302b. The CBSD 103 sends the SpectrumInquiry object to the SAS 101 (as shown by 302a) with a list of channels of interest. The SpectrumInquiryResponse sent by the SAS 101 (as shown by 302b) includes all available channels in the transmission area, which transmission area is defined based on the physical location of the CBSD.

[0009] Continuing with the signal-flow diagram of FIG. 3, based on the available channels, theCBSD now chooses one or more channels (as shown by 303) and requests a Grant via the Grant Request procedure, which involves sending a Grant Request 304a and receiving a Grant Response 304b. If the request is Granted by the SAS 101, after the reception of the GrantResponse 304b, the CBSD 103 starts a first Heartbeat procedure, which involves sending a first Heartbeat Request 305a to the SAS 101 and receiving a first Heartbeat Response 305b from the SAS 101. The GrantResponse 304b will also include the maximum power that the CBSD (e.g., O-RU) can transmit, which limits possible interference in the CBRS band. After the firstsuccessful HeartbeatResponse 305b is received from the SAS 101, the CBSD 103 (e.g., O-RU) can start transmitting in the channel associated with that grant. The CBSD 103 keeps sending HeartbeatRequest object periodically to the SAS 101, as exemplified by a subsequent Heartbeat Request 306a (to which the SAS 101 sends a subsequent Heartbeat Response 306b), as a form of “keep alive” mechanism. The procedure continues and the CBSD 103 (e.g., O-RU) can continue transmitting in the channel until the SAS 101 suspends or terminates the grant via a HeartbeatResponse object asking for such suspension or termination, as shown at 307. Additionally, if the CBSD decides to stop transmitting, the CBSD will send a GrantRelinquishment object 308 to the SAS 101 to notify the SAS that it no longer needs the channel associated with that grant.

[0010] A Domain Proxy (DP) is the entity that can handle the above-described CBRS procedureswith the SAS 101 on behalf of the CBSDs 103. The basic functionality of the DP is to be a “proxy” for the CBSD 103 (accordingly, the exchange of information with the SAS 101 in FIG. 3 can be handled by the DP, instead of the CBSD 103). Part of this includes the aggregation of the information coming from / to several CBSDs to / from the SAS. This reduces the number of messages and the number of connections that need to be established between the SAS 101 and the CBSDs 103. Additionally, this helps by offloading the CBRS functionality from the O-RU (i.e., CBSD 103) to the DP. As an example, the O-RU (i.e., CBSD 103) does not need to keep sending periodic HeartbeatRequest objects to the SAS 101, since the DP will handle that procedure on behalf of the O-RU. Accordingly, the CBSD 103 shown in FIG.3 should be interpreted as also encompassing a DP for the information exchange with the SAS 101.

[0011] Conventional RANs were built employing an integrated unit where the entire RAN wasprocessed. Conventional RANs implement the protocol stack (e.g., Physical Layer (PHY), Media Access Control (MAC), Radio Link Control (RLC), Packet Data Convergence Control (PDCP) layers) at the base station (also referred to as the evolved node B (eNodeB or eNB) for 4G LTE, or next generation node B (gNodeB or gNB) for 5G NR). In addition, conventional RANs use application-specific hardware for processing, which makes the conventional RANs difficult to upgrade and evolve. As future networks evolve to implement massive densification of networks to support increased capacity requirements, there is a growing need to reduce the capital costs (CAPEX) and operating costs (OPEX) of RAN deployment, as well as to make thesolution scalable and easy to upgrade.

[0012] Cloud-based Radio Access Networks (CRANs) are networks where a significant portionof the RAN layer processing is performed at a baseband unit (BBU) located in the cloud on commercial off-the-shelf servers, while the radio frequency (RF) interface and real-time critical functions can be processed in the remote radio unit (RRU), also referred to as the radio unit (RU). The BBU can be split into two parts: centralized unit (CU) and distributed unit (DU). CUs are usually located in the cloud on commercial off the shelf servers, while DUs can be distributed. The BBU may also be virtualized, in which case it is also known as vBBU.

[0013] The O-RAN architecture is a Cloud-based architecture specified by the O-RAN Alliance.The logical architecture of the O-RAN system is specified in [O-RAN.WG1.O-RAN- Architecture-Description-v010.00] and depicted in FIG.4. The components of the architecture include the Service Management and Orchestrator (SMO) Framework 401, the Non-Real Time (Non-RT) Radio Intelligent Controller (RIC) 402, the Near-Real Time (Near-RT) Radio Intelligent Controller (RIC) 407, the O-RAN Centralized Unit Control Plane (O-CU-CP) 409, the O-RAN Centralized Unit User Plane (O-CU-UP) 411, the O-RAN Distributed Unit (O-DU) 415, and the O-RAN Radio Unit (O-RU) 418.

[0014] The Service Management and Orchestrator (SMO) Framework 401 is responsible for themanagement of the O-RAN components (O-CU-CP, O-CU-UP, O-DU and O-RU for 5G, and O- eNB for 4G). The SMO Framework 401 uses the O2 interface 403 to connect with the O-Cloud 419. The management interface between the SMO Framework 401 and the O-RAN components is the O1 interface 404 to O-eNB and O1 interface 406 to 5G components.

[0015] The RAN Intelligent Controller (RIC) contains Radio Resource Management (RRM)functions that help control and optimize the components and the utilization of radio resources. It is divided into Non-RT RIC 402 and Near-RT RIC 407. The Non-RT RIC 402 is the functionality internal to the SMO 401. Its primary goal is to support intelligent RAN optimization, e.g., by providing policy-based guidance, Machine Learning (ML) model management, and enrichment information to the Near-RT RIC function, supporting Radio Resource Management (RRM) optimizations of the Near-RT RIC. The Non-RT RIC 402 can also perform intelligent RRM functions in non-real-time fashion (i.e., greater than 1 second). TheNon-RT RIC 402 communicates with the Near-RT RIC 407 via the A1 interface 405.

[0016] The Near-RT RIC 407 is a logical function that enables near real-time control andoptimization of radio components and resources via fine-grained data collection and actions over the E2 interface. The Near-RT RIC 407 control loop operates in the order of 10 milliseconds (10ms) to 1 second (1s). The Near-RT RIC 407 hosts one or more applications that use E2 interface 408 to collect near real-time information (e.g., on a UE-basis or a cell-basis) and provide value added services. The control over the radio components by the Near-RT RIC 407 is steered via the policies and the enrichment data provided via A1 interface 405 from the Non-RT RIC 402.

[0017] The data between the O-CU-CP 409 and O-CU-UP 411 is carried over the 3GPPinterface E1410. The data between O-CU-CP 409 and O-DU 415 is carried over the 3GPP interface F1-c 413, and data between O-CU-UP 411 and O-DU 415 is carried over the F1-u interface 414. The O-DU 415 is responsible for scheduling the data transmission over the air, and the O-DU scheduler runs a control loop in the order of milliseconds (< 10ms). The data between O-DU 415 and O-RU 418 is sent over the open fronthaul Control-User-Synchronization-Plane (Open FH CUS-Plane) 416 and open fronthaul Management-Plane (Open FH M-Plane) interface 417. The data between SMO 401 and O-RU 418 is sent over Open FH M-Plane interface 412. Other 3GPP interfaces (collectively referenced as 420 in FIG.4) are also included, e.g., X2-c, X2-u, Xn-c, and Xn-u, which interfaces carry data between O-CU-CP / O-CU-UP to other O-CU- CP / O-CU-UP, as well as NG-u interface to carry data to the 5G Core.

[0018] The Near-RT RIC decisions are based on its internal functions or applications, theconfiguration received over the O1 interface, and the temporary policies received over A1405 from the Non-RT RIC 402. In order to support the policy enforcement in the Near-RT RIC 407, the Non-RT RIC 402 can also provide enrichment information over the A1 interface.

[0019] FIG. 5 illustrates the SMO and Non-RT RIC Framework Services. Within the SMOFramework 401, the Non-RT RIC 402 has an interface A1508 to the Near-RT RIC (not shown). Being part of the SMO Framework 401, the Non-RT RIC 402 may also indirectly utilize the O1 506, O2505 and Open FH M-Plane 507 interfaces. The Non-RT RIC Framework 504 and the rApps 501 are provided within the Non-RT RIC 402 domain. Some of the Non-RT RICFramework 504 functions and services include providing policy-based guidance and enrichment information to the Near-RT RIC, data analytics, AI / ML training, inference for RAN optimization, and recommendations for configuration management actions over O1 interface.

[0020] The rApps 501 are modular applications that leverage the functionality exposed by theNon-RT RIC 402 to provide value-added services relative to intelligent RAN optimization and operation. The Non-RT RIC framework 504 functions provide services to rApps via the R1 interface 502 (which services are labeled “services that enable rApps 503” in FIG.5). The R1 interface is an Open API interface and provides a level of abstraction such that an rApp that is a producer of data (“producer rApp”) does not need to know whether there exists one or multiple consumers for that data, or the nature of that consumer. In other words, the “producer rApp” does not need to know if the consumer of the data is a “consumer rApp” or is an entity external to the Non-RT RIC 402 or SMO Framework 401. Additionally, the R1 interface 502 provides functionality such that a “consumer rApp” does not need to know if the data consumed is the product of a single entity (e.g., a single “producer rApp”), or the combined output of a complex chain of entities (e.g., a chain of rApps each consuming the value-added product of another).

[0021] From the perspective of the SAS, a CBSD is a radiation point, so it is mapped to the O-RU. From the perspective of the O-RAN, it is not practical to have the O-RU communicate directly to the SAS, as the O-RU is designed to be a low-cost component. In FIG.6, which illustrates an example architecture of CBRS in O-RAN, a CBSD Controller 601 implements the DP functionality, where the DP is a proxy for CBSD and interfaces (as referenced by 603) with the SAS 604. The CBSD Controller 601 can be a rApp in the non-RT RIC 402 and communicates with the Cloud Management System (CMS) 602 which is a part of the SMO Framework 401 for the configuration of the RAN components. CMS 602 manages O-RAN components including O-RU / CBSD, i.e., CMS 602 also acts as a proxy for the CBSD Controller 601 to control O-RU / CBSD so that the CBSD Controller does not need to communicate to the O- RU / CBSD directly, and hence, re-use the same functionality for non-CBRS / generic O-RAN. This helps to simplify and reduce the cost of the CBRS in O-RAN deployments.

[0022] In FIG. 7, which illustrates an example alternative architecture of CBRS in O-RAN, aCBSD Controller 701 can be provided in the SMO Framework 401, such that the CBSDController 701 can communicate directly with the CMS 702. The remaining portions of the architecture shown in FIG.7 are substantially the same as that shown in FIG.6, i.e., Non-RT RIC 402; SAS 704 interfacing (as shown by 703) the CBSD Controller 701; rApps 501; R1 interface 502; services that enable rApps 503; and Non-RT RIC framework 504.

[0023] In FIG. 8, which illustrates yet another example alternative architecture of CBRS in O-RAN, a CBSD Controller 801 can be provided as part of the CMS 802. The remaining portions of the architecture shown in FIG.8 are substantially the same as those shown in FIGS.6 and 7, i.e., SMO Framework 401; Non-RT RIC 402; SAS 804 interfacing (as shown by 803) the CBSD Controller 801; rApps 501; R1 interface 502; services that enable rApps 503; and Non-RT RIC framework 504.

[0024] In an example scenario, there can be many CBRS users (operators) operating in the samearea, each with multiple CBSDs. The CBRS users (operators) can request the same frequency grant from the SAS, thereby causing interference to each other. The SAS administrators ensure that Incumbent and PAL users are protected so that there is minimal interference to each other. However, the SAS administrators do not reject any grant requested by GAA users, as long as the grant does not interfere with the Incumbent or PAL Users. This means the GAA users can create ad-hoc interference to each other if their CBSDs are deployed nearby.

[0025] FIG. 9 illustrates an example scenario in which a CBRS operator A 911 experiencesinterference from three other CBRS operators (which can be Incumbent, PAL, or GAA operators). The operator A 911, which is a CBRS GAA operator, deploys CBSDs A1901, A2 902, A3903, and A4904. Also shown are 3 other CBRS operators B, C and D deploying CBSDs B1910, C1920, and D1930, respectively, which operators and the deployed CBSDs create interference for the CBRS operator A 911. The line between CBSDs of different operators indicate potential interference (if they operate on the same channel) due to the radio path between the CBSDs being lower than a certain threshold. That is, CBSD B1910 could create interference 941 to CBSD A1901 if both CBSDs are using the same channel. CBSD C1920 could create interference 942 and 943 to CBSD A1901 and CBSD A2902, respectively. CBSD D1 930 could create interference 944 to CBSD A3903.

[0026] Depending on the level of interference, the interference can render the CBRS unable toservice its users (UEs). For example, if the received power at CBSD A1901 from the UE is -100 dBm / PRB and the combined received power from CBSD B1910 and C1920 is -80 dBm / PRB, then the signal-to-noise-ratio (SINR) is -20 dB / PRB. This condition is not sufficient to support operation in a 4G or 5G wireless system. This is also due to the fact that the UE’s transmit power is usually much less than the one used at the CBSD.

[0027] Another requirement is to use the same frequency in all CBSDs, i.e., deployed CBSDsA1 901, A2902, A3903, and A4904 operate on the same CBRS channel(s). This has several benefits when using 4G LTE and 5G NR. One of them is to avoid inter-frequency handover. When signal strength (such as RSRP) of the UE is lower than a threshold, the serving base station (BS) (eNB or gNB) needs to schedule a measurement gap for the UE to measure the signal strength of other frequencies of other BS’s. If one of them is higher than another threshold, then the serving BS sends the handover command to the UE to switch to that frequency. This measurement gap causes the UE to stop the service with the serving BS. This results in throughput degradation, which can be up to 34% peak throughput degradation as CBRS operates using 4G / 5G TDD mode. Another benefit is to simplify the network operation as configuration inter-frequency handover parameters require additional network optimization.

[0028] OnGo Alliance (OnGoA) standard, TS-2003 Collaborative GAA CoexistenceSpecification, serves as the framework for the GAA Users (wireless operators) to coexist with one another while causing minimum interference to each other. This requires the CBRS Users to report the excessive interference caused by other users, based on which reporting the SAS administrators provide a frequency allocation plan to minimize the interference among all CBRS Users in the GAA Coordination Area (GCA). However, this process requires time, effort and manual coordination among several CBRS Users and multiple SAS administrators. Also, the frequency allocation plan, which is the only part that can be done through an algorithm such as Graph Coloring algorithm, is mostly based on RF channel model which could differ from the actual one in the field, particularly for CBSDs deployed indoor.

[0029] Moreover, neither the TS-2003 nor the SAS administrators can force the CBRS Users toaccept the frequency plan. If one of the CBRS Users in the GCA decides to opt out, then the SAS administrators will not enforce the frequency plan, which leads to the interference issue notbeing resolved. In this case, the individual CBRS User may still need an alternative plan to either avoid initiating the GAA Coexistence process or to mitigate the interference issue by the CBRS User itself.

[0030] Therefore, there is a need for a system and a method to dynamically choose the commonCBRS channels for all CBSDs such that it avoids interference from other CBRS operators without resorting to the OnGo TS-2003 process. SUMMARY

[0031] Accordingly, what is desired is a system and a method to dynamically choose thecommon CBRS channels for all CBSDs such that it avoids interference from other CBRS operators without resorting to the OnGo TS-2003 process.

[0032] According to an example system and method of the present disclosure, a SingleFrequency Group (SFG) is dynamically configured for all or a subset of CBSDs while avoiding interference from other CBRS operators.

[0033] According to an example system and method of the present disclosure, the following areimplemented: 1) The Channel Selector (CS) requests, via CBSD Controller, spectrum (channel) availability from the SAS for each CBSD. 2) The CS requests each CBSD to measure interference from other CBSDs belonging to other operators on said spectrum availability and report to the CS. 3) The CS identifies the list of low-interference channels and selects common channels for all CBSD’s from the said list, up to the required minimum bandwidth, and reports to the CBSD Controller to acquire them from the SAS to form an SFG.

[0034] According to an example system and method of the present disclosure, the following isadditionally implemented:4) If the CS cannot find common channels with low interference that satisfies the required minimum bandwidth, it splits the CBSDs into smaller multiple SFGs such that each SFG satisfies the above requirements.

[0035] According to an example system and method of the present disclosure, at least one of thefollowing is additionally implemented: 5) If the CS determines the interference landscape has changed, it modifies the number of SFGs by either combining some SFGs into one or splitting them further. 6) If the operator adds new CBSD(s), the CS goes through the procedure from requesting for Spectrum Inquiry, measurement report for some of existing and new CBSDs to determine the SFG for the new CBSD(s) and possible new SFG for existing CBSDs. 7) If the operator removes existing CBSD(s), the CS goes through the procedure from requesting for Spectrum Inquiry, measurement report to determine the SFG for the remaining CBSDs for a chance to consolidate SFGs, if applicable, into a smaller number of SFGs.

[0036] According to an example system and method of the present disclosure, the CBSDController measures the interference by one of the following: i) requesting CBSDs to measure its interference; ii) requesting CMS to be a proxy to request and forward the measured interference from CBSDs; or iii) requesting other node to be a proxy to request and forward the measured interference from CBSDs.

[0037] According to an example system and method of the present disclosure, in O-RANarchitecture, the CS can be implemented in SMO Framework in one of the following ways depending on the location of the CBSD controller: 1) in the case the CBSD Controller is in the Real-Time RIC (RT-RIC): a) the CS is in the CBSD Controller. b) the CS is not in the CBSD Controller but in the RT-RIC. c) the CS is in the SMO Framework and outside the CMS.d) the CS is in the CMS. 2) in the case the CBSD Controller is in the SMO Framework and outside the CMS: a) the CS is in the RT-RIC. b) the CS is in the SMO Framework but not in either the CBSD Controller or the CMS. c) the CS is in the CBSD Controller but not in the CMS. d) the CS is not in the CBSD Controller but in the CMS. 3) in the case the CBSD Controller in the CMS: a) the CS is in the RT-RIC. b) the CS is in the SMO Framework but not in either the CBSD Controller or the CMS. c) the CS is in the CBSD Controller. d) the CS is in the CMS but not in the CBSD Controller.

[0038] For this application, the following terms and definitions shall apply:

[0039] The term “network” as used herein includes both networks and internetworks of all kinds,including the Internet, and is not limited to any particular type of network or inter-network.

[0040] The terms “first” and “second” are used to distinguish one element, set, data, object orthing from another, and are not used to designate relative position or arrangement in time.

[0041] The terms “coupled”, “coupled to”, “coupled with”, “connected”, “connected to”, and“connected with” as used herein each mean a relationship between or among two or more devices, apparatus, files, programs, applications, media, components, networks, systems, subsystems, and / or means, constituting any one or more of (a) a connection, whether direct or through one or more other devices, apparatus, files, programs, applications, media, components, networks, systems, subsystems, or means, (b) a communications relationship, whether direct or through one or more other devices, apparatus, files, programs, applications, media, components, networks, systems, subsystems, or means, and / or (c) a functional relationship in which the operation of any one or more devices, apparatus, files, programs, applications, media,components, networks, systems, subsystems, or means depends, in whole or in part, on the operation of any one or more others thereof.

[0042] The above-described and other features and advantages of the present disclosure will beappreciated and understood by those skilled in the art from the following detailed description, drawings, and appended claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] FIG. 1 is a block diagram illustrating the CBRS architecture.

[0044] FIG. 2 is a schematic diagram illustrating the CBRS Grant State Machine.

[0045] FIG. 3 illustrates an example CBRS procedure.

[0046] FIG. 4 illustrates the logical architecture of the O-RAN system.

[0047] FIG. 5 shows SMO and Non-RT RIC Framework Services.

[0048] FIG. 6 shows an example architecture of CBRS in O-RAN.

[0049] FIG. 7 shows an alternative example architecture of CBRS in O-RAN.

[0050] FIG. 8 shows yet another alternative example architecture of CBRS in O-RAN.

[0051] FIG. 9 illustrates an example scenario in which a CBRS operator experiences interferencefrom three other CBRS operators.

[0052] FIG. 10 illustrates the message flow diagram of an example method according to thepresent disclosure.

[0053] FIG. 11 shows an example of interference reports from all CBSDs of operator A.

[0054] FIG. 12 shows another example of interference reports from all CBSDs of operator A.

[0055] FIG. 13 shows an example implementation of the CS as part of the CBSD ControllerrApp.

[0056] FIG. 14 shows another example implementation of the CS as an individual rApp in theNon-RT RIC, similar to the CBSD Controller.

[0057] FIG. 15 shows another example implementation of the CS in the SMO Framework andoutside the CMS.

[0058] FIG. 16 shows another example implementation of the CS in the CMS.

[0059] FIG. 17 shows another example implementation of the CS as an individual rApp in theNon-RT RIC.

[0060] FIG. 18 shows another example implementation of the CS in the SMO Framework.

[0061] FIG. 19 shows another example implementation of the CS inside the CBSD Controller inthe SMO Framework.

[0062] FIG. 20 shows another example implementation of the CS inside the CMS and outsidethe CBSD Controller.

[0063] FIG. 21 shows another example implementation of the CS as an individual rApp wherethe CBSD Controller is a part of the CMS.

[0064] FIG. 22 shows another example implementation of the CS in SMO Framework wherethe CBSD Controller is a part of the CMS.

[0065] FIG. 23 shows another example implementation of the CS as part of the CBSDController, which in turn is a part of the CMS.

[0066] FIG. 24 shows another example implementation of the CS as part of the CMS andoutside the CBSD Controller. DETAILED DESCRIPTION

[0067] FIG. 10 illustrates the message flow diagram of an example method according to thepresent disclosure. The Channel Selector (CS) 1001 sends CS Spectrum Inquiry Request 1004 the CBSD Controller 601 to send Spectrum Inquiry Request 1005 to the SAS 101. The SAS 101responds with Spectrum Inquiry Response 1006 that contains spectrum availability, and the CBSD Controller 601 forwards Spectrum Inquiry Response to the CS 1001 (as shown by the process step 1007). The CS 1001 sends the Measurement Request 1008 to the CBSD Controller 601 to request each CBSD to measure interference (as referenced by 1009) from other CBSDs belonging to other operators on said spectrum availability. If this is the first time the CBSDs have been activated (i.e., startup), then the CBSD Controller 601 can request each CBSD to measure the interference from other operators. This can be done through CMS. If the CBSDs have already been operational, see the procedure described below.

[0068] Once the measurement is available at the CBSD Controller 601, it sends the result in theMeasurement Response 1010 to the CS 1001. In the process step 1011, the CS creates a SFG by the procedure described in detail below. The CS 1001 then sends the SFG Request 1012 to the CBSD Controller 601 to configure and send the Grant Request with SFG (as referenced by the process step 1013) to the SAS 101. The SFG configuration in the Grant Request is per WinnForum standard, and it also depends on whether the SAS administrator supports the configuration. If it does not, it simply recognizes the requested frequency range in each CBSD as per WinnForum standard. Subsequently, the CBSD Controller 601 and the SAS 101 exchange several messages based on WinnForum CBRS for channel authorization (as referenced by the process step 1014). After the channels are authorized for all CBSDs, the CBSD Controller 601 configures SFG with the authorized channels to all CBSDs (as referenced by the process step 1015). This can be done by communicating with the CMS. Subsequently, the CBSD Controller 601 confirms the configuration by sending SFG Response 1016 to the CS 1001.

[0069] For creating the SFG, the CS 1001 determines whether a given channel has high or lowinterference, i.e., i) if the interference power is less than a specified low interference threshold, lowIntfTh, then the channel is considered a low interference channel, and ii) if the interferencepower is higher than lowIntfTh, then the channel is considered a high interference channel. FIG.11 shows an example set of interference reports from the CBSDs of operator A 911 illustrated in FIG.9. Let’s assume that the SAS indicates in the Spectrum Inquiry Response that channels 1-7 have been used by PAL users (and hence these channels are marked as “P” in FIG.11). The remaining channels 8-15 are available for GAA users, and therefore the CBSDs report interference on channels 8-15.

[0070] The CS 1001 (shown in FIG. 10) selects a single frequency that is common among allCBSDs (A1901 - A4904 shown in FIG.9) up to the required minimum bandwidth, e.g., 30 MHz or 3 channels. In such a case, the CS selects channels 8-10 for CBSDs (A1901 - A4904 shown in FIG.9). The CS 1001 then informs the CBSD Controller 601 (shown in FIG.10) to send the Grant Request to the SAS with channels 8-10. Once i) the SAS 101 (shown in FIG.10) sends Grant Response and ii) both the CBSD Controller 601 and the SAS 101 have exchanged the first Heartbeat Request and Heartbeat response, the channels 8-10 shown in FIG.11 are authorized to be used.

[0071] During the operation, the CS 1001 monitors the interference from the other operators(e.g., Operators B, C and D shown in FIG.9). The monitoring can be triggered periodically, based on specified events, or triggered manually by the operator. Once the monitoring is triggered, the CS 1001 requests all CBSDs of operator A to measure and report interference from other operators on the operating channels (channels 8-15 in the example above) and other channel availability (the CS could obtain a new Spectrum Inquiry Response from the SAS). That is, referring to FIG.10, the CS 1001 can start from sending CS Spectrum Inquiry Request 1004 or start from sending Measurement Request 1008.

[0072] Referring again to FIG. 9, because CBSDs A1901 – A4904 are transmitting on the samechannels 8-15, the measurements could be tainted by their own CBSDs, i.e., CBSD A1901 will receive signal transmitted by CBSDs A2902 – A4904. The operator A can optimize its network by keeping the inter-CBSD interference to the minimum, e.g., by implemented measures such as 1) interference measurement with coordinated blanking, or 2) utilizing UE measurements of neighbouring cells for optimal channel selection within CBRS network. In interference measurement with coordinated blanking, CBSDs A2902 – A4904 stop serving their UEs or implement blanking, and allow SBSD A1901 to measure the interference from CBSD B1910 and CBSD C1920. This procedure will rotate for all CBSDs A1-A4, i.e., CBSDs A1, A3 and A4 blank to allow CBSD A2902 to measure its interference, followed by CBSDs A1, A2 and A4 blanking, and so on. In utilizing UE measurements of neighbouring cells for optimal channel selection within CBRS network, the UE served by CBSD A1901 measures and reports interference to CBSD A1901. This reports include inter-CBSD interferences, which will be ignored by the CS, and inter-operator interferences, e.g., due to CBSD B1910 and CBSD C1920, which will be taken into consideration.

[0073] If the CS determines that no significant change in interference conditions has occurred tothe current operating frequency, then the CS does not change anything. However, if there is a change in interference conditions, e.g., as illustrated by the example set of interference reports shown in FIG.12 for the CBSDs of operator A, then the CS needs to act. The change in the interference reports shown in FIG.12 is due to CBSD D1930 in FIG.9Error! Reference source not found. having changed its channels to 8-10. It is clear that the CS cannot select channels 8-10 for CBSD A3. In fact, there is no common channel suitable to be used for all CBSDs. In this example, the CS needs to split the CBSDs into two groups (e.g., SFG1 and SFG2), each with at least one common channel.

[0074] To search for the new common channels, the operator can perform this task manually ifthe number of CBSDs are small and manageable. The operator can use a proprietary algorithm or use an Artificial Intelligence / Machine Learning engine that is available through the Non-Real Time RIC. The CS continues to monitor the interference conditions by requesting measurement reports from the CBSDs for a chance to combine the above-referenced SFG1 and SFG2 into a single group. For example, if the CS has received a new interference report (e.g., with interference pattern as shown in FIG.11), the CS can execute a search algorithm through the interference report to derive a single SFG.

[0075] If the operator adds new CBSD(s), the CS goes through the procedure from requestingfor Spectrum Inquiry, requesting measurement report for some or all of the preexisting CBSDs and the new CBSD(s) to determine the SFG for the new CBSD(s) and possible new SFG for the preexisting CBSDs.

[0076] If the operator removes existing CBSD(s), the CS goes through the procedure fromrequesting for Spectrum Inquiry, measurement report to determine the SFG for the remaining CBSDs for a chance to consolidate existing SFGs, if applicable, into a smaller number of SFGs.

[0077] In O-RAN, the CS can be implemented in the SMO Framework in different ways,depending on the location of the CBSD controller. Various options are summarized below: A) CBSD Controller is in the Real-Time RIC (RT RIC):i) CS is in the CBSD Controller (e.g., shown in FIG.13). ii) CS is not in the CBSD Controller, but in the RT RIC (e.g., shown in FIG.14). iii) CS is in the SMO, but not in the CMS (e.g., shown in FIG.15). iv) CS is in the CMS (e.g., shown in FIG.16). B) CBSD Controller is in the SMO, but not in the CMS: i) CS is in the RT RIC (e.g., shown in FIG.17). ii) CS is in the SMO, but not in either the CBSD Controller or the CMS (e.g., shown in FIG.18). iii) CS is in the CBSD Controller, but not in the CMS (e.g., shown in FIG.19). iv) CS is not in the CBSD Controller, but in the CMS (e.g., shown in FIG.20). C) CBSD Controller in the CMS: i) CS is in the RT-RIC (e.g., shown in FIG.21). ii) CS is in the SMO, but not in either the CBSD Controller or the CMS (e.g., shown in FIG.22). iii) CS is in the CBSD Controller (e.g., shown in FIG.23). iv) CS is in the CMS, but not in the CBSD Controller (e.g., shown in FIG.24).

[0078] FIG. 13 is a block diagram illustrating an example embodiment in which the CS 1305 isimplemented as an rApp in the CBSD Controller 1301. Also shown in FIG.13 are: SMO Framework 1307; SAS 1304; CMS 1302; interface 1303 linking SAS 1304 and CBSD Controller 1301; R1 interface 1306; Non-RT RIC 1308; Non-RT RIC Framework 504; and services that enable rApps 503.

[0079] FIG. 14 is a block diagram illustrating an example embodiment in which the CS 1405 isimplemented as a rApp in the Non-RT RIC 1408, similar to the CBSD Controller 1401. The CS 1405 communicates with the CBSD Controller 1401 via the R1 interface 1406. Also shown in FIG.14 are: SMO Framework 1407; SAS 1404; CMS 1402; interface 1403 linking SAS 1404 and CBSD Controller 1401; R1 interface 1406; Non-RT RIC Framework 504; and services that enable rApps 503.

[0080] FIG. 15 is a block diagram illustrating an example embodiment in which the CS 1505 isimplemented in the SMO Framework 1507. The CS 1505 communicates with the CBSD Controller 1501 via the R1 interface 1506. Also shown in FIG.15 are: SAS 1504; CMS 1502; interface 1503 linking SAS 1504 and CBSD Controller 1501; R1 interface 1506; Non-RT RIC 1508; Non-RT RIC Framework 504; and services that enable rApps 503.

[0081] FIG. 16 is a block diagram illustrating an example embodiment in which the CS 1605 isimplemented in the CMS 1602. The CS 1605 communicates with the CBSD Controller 1601 via the CMS 1602 and the R1 interface 1606. Also shown in FIG.16 are: SAS 1604; interface 1603 linking SAS 1604 and CBSD Controller 1601; R1 interface 1606; Non-RT RIC 1608; Non-RT RIC Framework 504; and services that enable rApps 503.

[0082] FIG. 17 is a block diagram illustrating an example embodiment in which the CS 1705 isimplemented as a rApp in the Non-RT RIC 1708, and the CBSD Controller 1701 is implemented in the SMO Framework 1707. The CS 1705 communicates with the CBSD Controller 1701 via the R1 interface 1706. Also shown in FIG.17 are: SAS 1704; CMS 1702; interface 1703 linking SAS 1704 and CBSD Controller 1701; R1 interface 1706; Non-RT RIC 1708; Non-RT RIC Framework 504; and services that enable rApps 503.

[0083] FIG. 18 is a block diagram illustrating an example embodiment in which the CS 1805 isimplemented in the SMO Framework 1807. The CS 1805 communicates directly with the CBSD Controller 1801 as both are in the SMO Framework 1807. Also shown in FIG.18 are: SAS 1804; CMS 1802; interface 1803 linking SAS 1804 and CBSD Controller 1801; R1 interface 1806; Non-RT RIC 1808; Non-RT RIC Framework 504; and services that enable rApps 503.

[0084] FIG. 19 is a block diagram illustrating an example embodiment in which the CS 1905 isimplemented as part of (inside) the CBSD Controller 1901 (which, in turn, is implemented in theSMO Framework 1907). As the CS 1905 is part of the CBSD Controller 1901, the functionality and data from the CS 1905 can be called and retrieved by the CBSD Controller 1901 internally. Also shown in FIG.19 are: SAS 1904; CMS 1902; interface 1903 linking SAS 1904 and CBSD Controller 1901; R1 interface 1906; Non-RT RIC 1908; Non-RT RIC Framework 504; and services that enable rApps 503.

[0085] FIG. 20 is a block diagram illustrating an example embodiment in which the CS 2005 isimplemented in the CMS 2002, but not in the CBSD Controller 2001. The CS 2005 communicates with the CBSD Controller 2001 via the CMS 2002. Also shown in FIG.20 are: SMO Framework 2007; SAS 2004; interface 2003 linking SAS 2004 and CBSD Controller 2001; R1 interface 2006; Non-RT RIC 2008; Non-RT RIC Framework 504; and services that enable rApps 503.

[0086] FIG. 21 is a block diagram illustrating an example embodiment in which the CS 2105 isimplemented as a rApp, and the CBSD Controller 2101 is a part of the CMS 2102. The CS 2105 communicates with the CBSD Controller 2101 through the R1 interface 2106 and through the CMS 2102, as the CMS 2102 is a part of the SMO Framework 2107. Also shown in FIG.21 are: SAS 2104; interface 2103 linking SAS 2104 and CBSD Controller 2101; R1 interface 2106; Non-RT RIC 2108; Non-RT RIC Framework 504; and services that enable rApps 503.

[0087] FIG. 22 is a block diagram illustrating an example embodiment in which the CS 2205 isimplemented in the SMO Framework 2207, and the CBSD Controller 2201 is a part of the CMS 2202. The CS 2205 communicates with the CBSD Controller 2201 via the CMS 2202, as both the CS 2205 and the CMS 2202 are in the SMO Framework 2207. Also shown in FIG.22 are: SAS 2204; interface 2203 linking SAS 2204 and CBSD Controller 2201; R1 interface 2206; Non-RT RIC 2208; Non-RT RIC Framework 504; and services that enable rApps 503.

[0088] FIG. 23 is a block diagram illustrating an example embodiment in which the CS 2305 isimplemented as part of the CBSD Controller 2301, which, in turn, is a part of the CMS 2302. Also shown in FIG.23 are: SMO Framework 2307; SAS 2304; interface 2303 linking SAS 2304 and CBSD Controller 2301; R1 interface 2306; Non-RT RIC 2308; Non-RT RIC Framework 504; and services that enable rApps 503.

[0089] FIG. 24 is a block diagram illustrating an example embodiment in which the CS 2405 isimplemented in the CMS 2402, but not as a part of the CBSD Controller 2401. Also shown in FIG.24 are: SMO Framework 2407; SAS 2404; interface 2403 linking SAS 2404 and CBSD Controller 2401; R1 interface 2406; Non-RT RIC 2408; Non-RT RIC Framework 504; and services that enable rApps 503.

[0090] The following are messages exchanged between the CS and the CBSD Controller if theCS is not a part of CBSD Controller: 1) CS Spectrum Inquiry Request; 2) CS Spectrum Inquiry Response; 3) Measurement Request; 4) Measurement Response; 5) SFG Request; and 6) SFG Response. In the following sections, detailed definitions for these messages will be provided.

[0091] CS Spectrum Inquiry Request message: This message, which is sent from the CS to theCBSD Controller, is for the CS to request the CBSD Controller to send Spectrum Inquiry Request to the SAS. This message includes the Spectrum Inquiry Request defined in Wireless Innovation Forum Standard’s Interface Technical Specification WINNF-TS-016 and conditionedon the csSpectrumRequestAll parameter (which is used to reduce the messaging traffic loadbetween the CS and the CBSD Controller) and the csSpectrumRequestShallRespond parameter(which is used to re-synchronize the CBSD database between the CS and the CBSD Controller), as explained below: Parameter R / O / C DescriptionNAME: csSpectrumRequestAllRequired If the flag is true, the CBSD Controller shall DATA TYPE: Boolean send spectrum inquiry for all CBSDs. NAME: Optional If the flag value is true, the CBSD Controller csSpectrumRequestShallRespond shall respond with the spectrum availability, DATA TYPE: Boolean otherwise, it can omit if there is no change from the last response. If the flag is omitted, the CBSD Controller shall assume it is false. NAME: spectrumInquiryRequest Conditional If the csSpectrumRequestAll is true, thisDATA TYPE: array of object:field can be omitted, otherwise, this field SpectrumInquiryRequest is required. Array of SpectrumInquiryRequest objects.Each SpectrumInquiryRequest objectrepresents a spectrum inquiry request of a CBSD.

[0092] SpectrumInquiryRequest objectParameter R / O / C DescriptionNAME: cbsdId Required The CBSD shall set this parameter to the valueDATA TYPE: string of its CBSD identity. NAME: inquiredSpectrum Required This field describes the spectrum for which theDATA TYPE: array of object: CBSD seeks information on spectrum FrequencyRange availability.

[0093] FrequencyRange objectParameter R / O / C DescriptionNAME: lowFrequency Required The lowest frequency of the frequency range inDATA TYPE: number Hz. NAME: highFrequency Required The highest frequency of the frequency range inDATA TYPE: number Hz.

[0094] CS Spectrum Inquiry Response message: This message, which is sent from the CBSDController to the CS, is for the CBSD Controller to forward the spectrum inquiry response from the SAS to the CS. This message includes the Spectrum Inquiry Response message defined in Wireless Innovation Forum Standard’s Interface Technical Specification WINNF-TS-016, andconditioned on the csSpectrumInquiryResponseNoChange parameter (which is used to reduce themessaging traffic load between the CS and the CBSD Controller) or the csSpectrumRequestShallRespond parameter (which is used to re-synchronize the CBSD status between the CS and the CBSD Controller) in the CS Spectrum Inquiry Request Message, as explained below:Parameter R / O / C DescriptionNAME: Required If set to true, it indicates there is no change from csSpectrumInquiryResponseNoChange the last response. DATA TYPE: Boolean NAME: spectrumInquiryResponse Conditional If the csSpectrumInquiryResponseNoChangeDATA TYPE: array of object: is set to false or the SpectrumInquiryResponsecsSpectrumRequestShallRespond in the CSSpectrum Inquiry Request Message is true, this field is required, otherwise, this field can be omitted. Array of SpectrumInquiryResponse objects.Each SpectrumInquiryResponse objectrepresents a spectrum inquiry response to a spectrum inquiry request of a CBSD.

[0095] SpectrumInquiryResponse objectParameter R / O / C DescriptionNAME: cbsdId Conditional This parameter is included if and only if theDATA TYPE: stringcbsdId parameter in the SpectrumInquiryRequestobject contains a valid CBSD identity. If included, the SAS shall set this parameter to the value of the cbsdId parameter in thecorresponding SpectrumInquiryRequest object.NAME: availableChannel Conditional This parameter is an array of zero or more dataDATA TYPE: array of object:objects, AvailableChannel, which describes aAvailableChannel channel that is available for the CBSD. Included: If and only if the Spectrum Inquiry is successful. NAME: responseRequired This parameter includes information on whether DATA TYPE: object: Responsethe corresponding CBSD request is approved ordisapproved for a reason. See Table 14 ofWINNF-TS-016: Response Object Definition.

[0096] Response Object Definition (from Table 14 of WINNF-TS-016)Parameter R / O / C DescriptionNAME: responseCode Required An integer to indicate the type of result. TheDATA TYPE: number value 0 means the corresponding CBSD request is successful. This shall be one of the values in Table 39 Response Code Definition in WINNF- TS-016 as shown also below. NAME: responseMessage Optional A short description of the result.DATA TYPE: string NAME: responseDataOptional Additional data can be included to help the DATA TYPE: Dependent on CBSD resolve failures. responseCode– see Table 40 in For spectrum inquiry response message, the WINNF-TS-016: responseDatafield is Not Present. Definitions (as shown also below).

[0097] Response Code Definitions (from Table 39 in WINNF-TS-016)Only the code related to Spectrum Inquiry Response Message is applicable. responseCode Value Name Description0 SUCCESS CBSD request is approved by SAS300 UNSUPPORTED_SPECTRUM The frequency range indicated in thespectrum inquiry request or grant request is at least partially outside of the CBRS band.

[0098] Response Data Definitions (From Table 40 in WINNF-TS-016)responseData: related to the SFG Response message. responseCodeName responseData DataDescription of Value Type error data 0SUCCESS Not present300 UNSUPPORTED_SPECTRUM Not present

[0099] Measurement Request message: This message, which is sent from the CS to the CBSDController, is for the CS to request the CBSD Controller to request for RF measurement. Parameter R / O / C DescriptionNAME: measRequest Required Array of MeasRequest objects. EachDATA TYPE: array of object: MeasRequest object represents a measure inquiryMeasRequest request of a CBSD.

[0100] MeasRequest objectParameter R / O / C DescriptionNAME: cbsdId Required The CBSD shall set this parameter to the valueDATA TYPE: string of its CBSD identity. NAME: inquiredSpectrum Required This field describes the spectrum for which theDATA TYPE: array of object: CS requests for RF measurement of the CBSD. FrequencyRange (FrequencyRange object is as defined above in connection with CS Spectrum Inquiry Request message).

[0101] Measurement Response message: This message, which is sent from the CBSDController to the CS, is for the CBSD Controller to send the measurement of the CBSDs to the CS.Parameter R / O / C DescriptionNAME: measResponse Required Array of MeasResponse objects. EachDATA TYPE: array of object:MeasResponse object represents a measurementMeasResponse inquiry response to a measurement inquiry request of a CBSD.

[0102] MeasResponse objectParameter R / O / C DescriptionNAME: cbsdId Conditional This parameter is included if and only if theDATA TYPE: stringcbsdId parameter in the MeasRequest objectcontains a valid CBSD identity. If included, the CBSD Controller shall set this parameter to the value of the cbsdId parameter in thecorresponding MeasRequest object.NAME: inquiredSpectrum Conditional This parameter is included if the cbsdId isDATA TYPE: array of object: included. FrequencyRange This field describes the spectrum for which the CS requests for RF measurement of the CBSD. NAME: measReport Conditional This parameter is included if the cbsdId isDATA TYPE: array of object: included. MeasReport The CBSD Controller uses this parameter to report measurements to the CS, one MeasReportobject for each FrequencyRange object.The format of the MeasReport object is definedbelow.

[0103] MeasReport objectParameter R / O / C DescriptionNAME: MeasReport Required This parameter includes the interference level forDATA TYPE: number the corresponding frequency range specified inFrequencyRange object. It is the RSRP of thereceived power from other vender CBSD’s.

[0104] SFG Request message: This message, which is sent from the CS to the CBSDController, is for the CS to request the CBSD Controller to create or modify SFG for each CBSD. Parameter R / O / C DescriptionNAME: sfgRequest Required Array of SfgRequest objects. Each SfgRequestDATA TYPE: array of object:object represents an SFG request of a CBSD. SfgRequest

[0105] SfgRequest objectParameter R / O / C DescriptionNAME: cbsdId Required The CS shall set this parameter to the value ofDATA TYPE: string the CBSD identity. NAME: sfgId Required The CS shall set this parameter to the value toDATA TYPE: string the SFG of this CBSD. NAME: inquiredSpectrum Required This field describes the spectrum for which theDATA TYPE: array of object: CS requests for spectrum of the CBSD. FrequencyRange (FrequencyRange object is as defined above in connection with CS Spectrum Inquiry Request message).

[0106] SFG Response message: This message, which is sent from the CBSD Controllerto the CS, is for the CBSD Controller to respond to the SFG request of the CS. The response is successful if the SAS grants and authorizes the inquired spectrum of the CBSD. Otherwise, the CBSD Controller includes the responseCode from the SAS in the message. Parameter R / O / C DescriptionNAME: sfgResponse Required Array of SfgResponse objects. Each SfgResponseDATA TYPE: array of object: object represents an SFG response to a SFG SfgResponse inquiry request of a CBSD.

[0107] SfgResponse objectParameter R / O / C DescriptionNAME: cbsdId Conditional This parameter is included if and only if theDATA TYPE: stringcbsdId parameter in the SfgRequest objectcontains a valid CBSD identity. If included, the CBSD Controller shall set this parameter to the value of the cbsdId parameter in thecorresponding SfgRequest object.NAME: inquiredSpectrum Conditional This parameter is included if the cbsdId isDATA TYPE: array of object: included. FrequencyRange This field describes the spectrum for which the CS requests for SFG of the CBSD. NAME: response Required This parameter includes information on whetherDATA TYPE: object: Responsethe corresponding CBSD request is approved or disapproved for a reason. See Table 14 and 39 in WINNF-TS-016. (Response object is as defined above in connection with CS Spectrum Inquiry Response message).

[0108] Response Code Definitions (from Table 39 in WINNF-TS-016)Only the grant-related codes below are applicable to the SFG Response Message (related to the Grant procedure). responseCode Value Name Description0 SUCCESS CBSD request is approved by SAS400 INTERFERENCE Requested operation parameters causetoo much interference. ThisresponseCode value indicates that theGrant request is unlikely to be successful if retried by the CBSD. 401 GRANT_CONFLICT Conflict with an existing Grant of thesame CBSD. The CBSD should be able to remediate this using the data returned in the responseDatastructure, by synchronizing its Grant state with the SAS and relinquishing any out-of-sync Grants.

[0109] Response Data Definitions (From Table 40 in WINNF-TS-016)responseData: related to the SFG Response message. responseCodeName responseData Data Type Description ofValue error data 0SUCCESS Not present400 INTERFERENCE Not present401 GRANT_CONFLICT array of string The Grant ID of anexisting Grant that causes the conflict.

[0110] While the present disclosure has been described with reference to one or moreexemplary embodiments, it will be understood by those skilled in the art that various changes can be made and equivalents can be substituted for elements thereof without departing from the scope of the present disclosure. In addition, many modifications can be made to adapt a particular situation or material to the teachings of the disclosure without departing from the scope thereof. Therefore, it is intended that the present disclosure not be limited to the particular embodiment(s) disclosed as the best mode contemplated, but that the disclosure will include all embodiments falling within the scope of the appended claims.

[0111] For the sake of completeness, the following list of acronyms is provided.4G 4th Generation wireless networks5G 5th Generation wireless networksCBRS Citizens Broadband Radio ServiceCBSD CBRS DeviceCS Channel SelectorDP Domain ProxyEIRP Equivalent isotropic radiated powerGAA General Authorized AccessLTE Long-Term EvolutionNR New RadioOnGoA OnGo AlliancePAL Priority Access LicensePRB Physical Resource BlockRSRP Received Signal Reference PowerRSRQ Reference Signals Received QualitySFG Single Frequency GroupSINR Signal to Interference plus Noise RatioSAS Spectrum Access SystemUE User Equipment

Claims

1. CLAIMS:

1. A system for optimizing Citizens Broadband Radio Service (CBRS) network having aSpectrum Access System (SAS) and plurality of CBRS devices (CBSDs), comprising: a CBSD controller; and a channel selector (CS) configured to: i) request, via the CBSD controller, CBSDs of a first operator to report interference caused by CBSDs of other operators on a plurality of channels; ii) identify, based on the reports from the CBSDs of the first operator, a list of available low-interference channels exhibiting interference levels below a specified threshold level; iii) determine, from the list of low-interference channels, at least one common channel satisfying a required minimum bandwidth to serve as a single frequency group (SFG) for all CBSDs of the first operator; and iv) request the CBSD controller to acquire the at least one common channel from the SAS to configure the SFG.

2. The system of claim 1, further comprising:in the case the CS determines the at least one common channel satisfying a required minimum bandwidth to serve as a single frequency group (SFG) for all CBSDs of the first operator is not available, the CS is further configured to: i) select at least one first common channel to serve as a first SFG for a first subset of CBSDs of the first operator; and ii) select at least one second common channel to serve as a second SFG for a second subset of CBSDs of the first operator.

3. The system of claim 1, further comprising:in the case the CS subsequently determines the interference caused by the CBSDs of the other operators on the plurality of channels has changed and the at least one common channel satisfying the required minimum bandwidth to serve as the SFG for all CBSDs of the first operator is not available, the CS is further configured to: i) select at least one first common channel to serve as a first SFG for a first subset of CBSDs of the first operator; and ii) select atleast one second common channel to serve as a second SFG for a second subset of CBSDs of the first operator.

4. The system of claim 2, further comprising: in the case the CS subsequently determines the interference caused by the CBSDs of the other operators on the plurality of channels has changed and the at least one common channel satisfying the required minimum bandwidth to serve as the SFG for all CBSDs of the first operator is available, the CS is further configured to combine the first and second subsets of CBSDs of the first operator to be served by the SFG for all CBSDs of the first operator.

5. The system of claim 1, further comprising:in the case at least one new CBSD is added by the first operator, the CS is further configured to: request, via the CBSD controller, at least the new CBSD of the first operator to report interference caused by CBSDs of other operators on the plurality of channels; and newly determine at least one common channel satisfying the required minimum bandwidth to serve as the SFG for all CBSDs of the first operator.

6. The system of claim 2, further comprising:in the case at least one new CBSD is subsequently removed by the first operator, the CS is further configured to: request, via the CBSD controller, the remaining CBSDs of the first operator to report interference caused by CBSDs of other operators on the plurality of channels; and determine whether the first and second subsets of CBSDs of the first operator can be combined to be served by the SFG for all CBSDs of the first operator.

7. The system of claim 1, wherein the CBSD controller is configured to obtain interferencemeasurements by one of the following: i) requesting the CBSDs of the first operator to measure the interference caused by the CBSDs of other operators;ii) requesting a cloud management system (CMS) to act as a proxy to request and forward the measured interference from the CBSDs of the first operator; or iii) requesting another node in the network to act as a proxy node to request and forward the measured interference from the CBSDs of the first operator.

8. The system of claim 1, wherein the CS is implemented in a Service Management andOrchestrator (SMO) Framework in one of the following configurations, depending on the implementation location of the CBSD controller: a) in the case the CBSD controller is implemented in a Real-Time Radio Intelligent Controller (RT-RIC), the CS is implemented in one of: i) the CBSD controller; ii) the RT-RIC, and outside the CBSD Controller; iii) the SMO Framework, and outside a cloud management system (CMS); or iv) in the CMS; b) in the case the CBSD controller is implemented in the SMO Framework, and outside the CMS, the CS is implemented in one of: i) the RT-RIC; ii) the SMO Framework, and outside the CBSD controller and the CMS; iii) the CBSD controller, and outside the CMS; or iv) the CMS, and outside the CBSD controller; c) in the case the CBSD controller is implemented in the CMS, the CS is implemented in one of: i) the RT-RIC; ii) in the SMO, and outside the CBSD controller and the CMS; iii) in the CBSD controller; oriv) in the CMS, and outside the CBSD controller.

9. A method for optimizing Citizens Broadband Radio Service (CBRS) network having aSpectrum Access System (SAS) and plurality of CBRS devices (CBSDs), comprising: i) requesting, by a channel selector (CS) via a CBSD controller, CBSDs of a first operator to report interference caused by CBSDs of other operators on a plurality of channels; ii) identifying, by the CS, based on the reports from the CBSDs of the first operator, a list of available low-interference channels exhibiting interference levels below a specified threshold level; iii) determining, from the list of low-interference channels, at least one common channel satisfying a required minimum bandwidth to serve as a single frequency group (SFG) for all CBSDs of the first operator; and iv) requesting the CBSD controller to acquire the at least one common channel from the SAS to configure the SFG.

10. The method of claim 9, further comprising: in the case the CS determines the at least one common channel satisfying a required minimum bandwidth to serve as a single frequency group (SFG) for all CBSDs of the first operator is not available, performing the following by the CS: i) selecting at least one first common channel to serve as a first SFG for a first subset of CBSDs of the first operator; and ii) selecting at least one second common channel to serve as a second SFG for a second subset of CBSDs of the first operator.

11. The method of claim 9, further comprising: in the case the CS subsequently determines the interference caused by the CBSDs of the other operators on the plurality of channels has changed and the at least one common channel satisfying the required minimum bandwidth to serve as the SFG for all CBSDs of the first operator is not available, performing the following by the CS: i) selecting at least one first common channel to serve as a first SFG for a first subset of CBSDs of the first operator; and ii)selecting at least one second common channel to serve as a second SFG for a second subset of CBSDs of the first operator.

12. The method of claim 10, further comprising: in the case the CS subsequently determines the interference caused by the CBSDs of the other operators on the plurality of channels has changed and the at least one common channel satisfying the required minimum bandwidth to serve as the SFG for all CBSDs of the first operator is available, performing the following by the CS: combining the first and second subsets of CBSDs of the first operator to be served by the SFG for all CBSDs of the first operator.

13. The method of claim 9, further comprising: in the case at least one new CBSD is added by the first operator, performing the following by the CS: i) requesting, via the CBSD controller, at least the new CBSD of the first operator to report interference caused by CBSDs of other operators on the plurality of channels; and ii) newly determining at least one common channel satisfying the required minimum bandwidth to serve as the SFG for all CBSDs of the first operator.

14. The method of claim 10, further comprising: in the case at least one new CBSD is subsequently removed by the first operator, performing the following by the CS: i) requesting, via the CBSD controller, the remaining CBSDs of the first operator to report interference caused by CBSDs of other operators on the plurality of channels; and ii) determining whether the first and second subsets of CBSDs of the first operator can be combined to be served by the SFG for all CBSDs of the first operator.

15. The method of claim 9, wherein the CBSD controller obtains interference measurements by one of the following: i) requesting the CBSDs of the first operator to measure the interference caused by the CBSDs of other operators; ii) requesting a cloud management system (CMS) to act as a proxy to request and forward the measured interference from the CBSDs of the first operator; oriii) requesting another node in the network to act as a proxy node to request and forward the measured interference from the CBSDs of the first operator.

16. The method of claim 9, wherein the CS is implemented in a Service Management andOrchestrator (SMO) Framework in one of the following configurations, depending on the implementation location of the CBSD controller: a) in the case the CBSD controller is implemented in a Real-Time Radio Intelligent Controller (RT-RIC), the CS is implemented in one of: i) the CBSD controller; ii) the RT-RIC, and outside the CBSD Controller; iii) the SMO Framework, and outside a cloud management system (CMS); or iv) in the CMS; b) in the case the CBSD controller is implemented in the SMO Framework, and outside the CMS, the CS is implemented in one of: i) the RT-RIC; ii) the SMO Framework, and outside the CBSD controller and the CMS; iii) the CBSD controller, and outside the CMS; or iv) the CMS, and outside the CBSD controller; c) in the case the CBSD controller is implemented in the CMS, the CS is implemented in one of: i) the RT-RIC; ii) in the SMO, and outside the CBSD controller and the CMS; iii) in the CBSD controller; or iv) in the CMS, and outside the CBSD controller.

Images