Patent Application
20230037701
The present disclosure relates to systems and methods for Radio Access Networks (RANs) and relates more particularly to using Open RAN (O-RAN) Shared Cells (SC) groups.
One of the technologies recently standardized is operation over shared spectrum such as Citizens Broadband Radio Service (CBRS) band in the U.S. from 3.55 GHz-3.7 GHz. Similar shared spectrum paradigms also exist in other countries. CBRS opens new ways to use spectrum in the 3.5 GHz band in the US by sharing spectrum across legacy and new users. There are 3 tiers of users sharing the CBRS band. The first tier includes “incumbents,” who are legacy/existing users of the CBRS band, e.g., military ship-borne radars in coastal areas, military ground-based radars, fixed satellite services (FSS) receive-only earth stations (35 sites around US, mostly in coastal areas), and Grandfathered Wireless Broadband Licensees (GWBL). The second tier includes Priority Access License (PAL) users, who are CBRS Devices (CBSDs) having one or more licenses to use a portion of the CBRS band. PAL users, who have a lower priority than incumbents, are restricted to a total of 70 MHz within 3.55-3.65 GHz band in the CBRS band. The third tier includes General Authorized Access (GAA) users, who are CBSDs using the CBRS band without holding a license. GAA users, who have a lower priority than PAL users, are the lowest tier of the 3-tier architecture. GAA users can only use the spectrum if no incumbents or PAL users are using the channel at a given location. GAA users have access to the entire 150 MHz of the CBRS band.
CBSDs obtain Grants from the SAS 1001 via the SAS-CBSD interface 1004. This may be done with the assistance of a DP 1002 in the communication path, or directly between SAS 1001 and CBSDs 1003. The DP 1002 is a logical entity engaging in communications with the SAS 1001 on behalf of multiple individual CBSDs 1003 or networks of CBSDs. The DP 1002 can also provide a translational capability to interface legacy radio equipment in the 3650-3700 MHz band with a SAS 1001 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 1002 presents a consistent and secure interface to the SAS that can convey all messages pertaining to the SAS-CBSD interface 1004 for client CBSDs 1003. CBSD aggregation and proxy function for large networks can be integrated within a Service Management and Orchestration (SMO) system or in a standalone node. SAS 1001 is a system that authorizes and manages use of spectrum for the CBRS in accordance with the regulations specified in 47 CFR § 96.
The Grant transitions from the Authorized state 2003 back to the Granted state 2002 if the Grant is suspended by the SAS or the transmission right, as defined by the transmitExpireTime parameter in the Heartbeat Response object, has expired. The Grant 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. The example Grant state machine shown in
Based on the available channels, the CBSD now chooses one or more channels, as referenced by 3003 in
After the first successful Heartbeat Response is received from the SAS, the CBSD (O-RU) may start transmitting in the channel associated with that grant. The CBSD keeps sending a subsequent Heartbeat Request object periodically to the SAS, as referenced by 3006, as a form of “keep alive” mechanism. The procedure continues and the O-RU may continue transmitting in the channel until the SAS suspends or terminates the grant via a subsequent Heartbeat Response object asking for such suspension or termination, as referenced by 3007. Additionally, if the CBSD decides to stop transmitting, the CBSD 1003 will send a Grant Relinquishment object to the SAS 1001 to notify the SAS that it no longer needs the channel associated with that grant.
The Domain Proxy (DP) 1002 is the entity that can handle the CBRS procedures with the SAS 1001 on behalf of the CBSDs 1003. The basic functionality of the DP is to be a “proxy” for the CBSD. 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 and the CBSDs. Additionally, this helps by offloading the CBRS functionality from the O-RU to the DP. As an example, the O-RU does not need to keep sending periodic Heartbeat Request objects to the SAS, since the DP will handle that procedure on behalf of the O-RU.
Conventional RANs were built employing an integrated unit where the entire RAN was processed. 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 make the conventional RANs difficult to upgrade and evolve. As future networks evolve to have 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 and make the solution scalable and easy to upgrade.
Cloud-based Radio Access Networks (CRANs) are networks where a significant portion of 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) 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. Radio Frequency (RF) interface and real-time critical functions can be processed in the Radio Unit (RU), sometimes referred to as Remote Radio Unit (RRU).
The O-RAN architecture is a Cloud-based architecture specified by the O-RAN Alliance. The architecture of the O-RAN system is specified in the technical specification O-RAN.WG1.O-RAN-Architecture-Description-v03.00. The high level logical architecture of O-RAN is depicted in
The Service Management and Orchestrator (SMO) Framework 4001 is responsible for the management of the O-RAN components (O-CU, O-DU and O-RU). The SMO uses the O2 interface 40011 to connected with the O-Cloud 40012. The management interface between the SMO and the O-RAN components is the O1 interface 4007.
The RAN Intelligent Controller (MC) contains Radio Resource Management (RRM) functions that help control and optimize the components and the utilization of radio resources. It is divided in Non-Real Time RIC 4002 and Near-Real Time MC 4003.
The Non-RT RIC 4002 is the functionality internal to the SMO 4001. Its primary goal is to support intelligent RAN optimization. It provides policy-based guidance, ML (Machine Learning) model management, and enrichment information to the Near-RT MC function, supporting RRM (Radio Resource Management) optimizations of the Near-RT MC. It can also perform intelligent RRM functions in non-real-time fashion (i.e., greater than 1 second). It communicates to the Near-RT MC via the A1 interface 1008.
The Near-RT RIC 4003 is a logical function that enables near real-time control and optimization of radio components and resources via fine grained data collection and actions over the E2 interface 4008. Its control loops that operate in the order of 10 ms to 1 s. The Near-RT RIC hosts one or more applications that use E2 interface 4008 to collect near real-time information (e.g. on a UE basis or a Cell basis) and provide value added services. The Near-RT MC control over the radio components is steered via the policies and the enrichment data provided via A1 interface 1008 from the Non-RT MC 4002.
The data between the O-CU 4004 and O-DU 4005 is carried over the F1 interface 4009. The O-DU is responsible for scheduling the data transmission over the air, and the O-DU scheduler runs a control loop in the order of milliseconds (<10 ms). The data between O-DU and O-RU is sent over the open fronthaul interface.
The Near-RT RIC 4003 decisions are based on its internal functions or applications, the configuration received over O1 interface 4007 and the temporary policies received over A1 interface 1008 from the Non-RT RIC 4002. In order to support the policy enforcement in the Near-RT RIC 4003, the Non-RT MC 4002 can also provide enrichment information over the A1 interface 1008.
Within the Non-RT RIC domain, we find the Non-RT MC Framework 5004 and the rApps 5005. Some of the Non-RT MC Framework functions and services include providing policy-based guidance and enrichment information to the Near-RT RIC, data analytics, Artificial Intelligent (AI)/Machine Learning (ML) training, inference for RAN optimization, and recommendations for configuration management actions over O1 interface.
The rApps 5005 are modular applications that leverage the functionality exposed by the Non-RT MC to provide added value services relative to intelligent RAN optimization and operation. The Non-RT MC framework functions provide services to rApps via the R1 (services) interface 5006. The R1 (services) interface 5006 is an Open application programming interface (API) interface.
The R1 (services) interface 5006 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 or SMO). Additionally, the R1 (services) interface 5006 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).
A Shared Cell (SC) group is a group of Radio Units (RUs) which operate using the same channels (same component carriers) and same cell (same Physical Cell Identity), forming one “big cell”.
Although example embodiments of the present disclosure are described in the context of the Open RAN (O-RAN) architecture and a CBRS system, the present disclosed is applicable to any wireless communication system and/or wireless communication architecture. Although the example embodiments of the present disclosure are described in the context of Shared Cell grouping concept from O-RAN, the present disclosure is applicable to any group of RUs using a similar concept, e.g., a Distributed Antenna System (DAS).
In accordance with the present disclosure, a new entity, Shared Cell (SC) Controller, uses deployment information, radio resource utilization measurements, cell load measurements, signal quality measurement, operator's policies and radio capabilities to make decisions on system configuration, re-configuration, and channel allocation related to the Shared Cell groups. The SC Controller may also use artificial intelligence/machine learning to predict future system state when making decisions on system configuration and channel allocation. The dynamic nature of the channel allocation in the CBRS system makes CBRS a great candidate to take advantage of the solution provided in the present disclosure.
This present disclosure provides the Shared Cell (SC) Controller as a new entity or function in a wireless communication system operating using CBRS spectrum or any other spectrum, licensed or unlicensed. The Shared Cell (SC) Controller uses deployment information, radio resource utilization measurements, cell load measurements, operator's policies and radio capabilities to make decisions on system configuration and channel allocation. The SC Controller may also use artificial intelligence (AI)/machine learning (ML) to predict future system state when making decisions on system configuration and channel allocation. In an O-RAN architecture, the SC Controller may be implemented as an application belonging to the SMO Framework, or an application belonging to the Non-RT RIC domain, such as an “rApp”.
Shared cell definition: The operation for the same cell by several O-RUs.
The Shared Cell (SC) model as specified by the ORAN Alliance is the subject of the present disclosure. The Shared Cell Group is defined as a mode of operation of a group of O-RUs (O-RAN Radio Units), where all the O-RUs in the group use the same channel(s) (i.e., component carrier(s)) for transmission and reception. Each component carrier has a Physical Cell Identity (PCI) associated with it, and the same PCI is used in all the O-RUs in the group in that component carrier.
O-RAN defines 2 cases for realizing shared cell:
“Copy and combine” functionality is described in the technical specification O-RAN.WG4.CUS.0-v05.00 for both FHM and Cascade modes. The “copy” functionality is used in the downlink, as illustrated in
The “combine” functionality is used in the uplink, as illustrated in
As an example embodiment, a wireless communications system containing one or more Shared Cell Groups, operating in CBRS spectrum, and interfacing with the Spectrum Access System (SAS) is provided. The example embodiment of the wireless communication system can include, e.g., the following:
The O-RU Controller is defined in the technical specification O-RAN.WG4.MP.0-v05.00 as a network function that is permitted to control the configuration of an O-RU. Examples of O-RU controllers include, an O-DU, a classical Network Management System (NMS), an O-RAN Service Management and Orchestration (SMO) function, or other network automation platforms. Although the O-RU Controller is assumed to be part of the SMO in the present disclosure for the sake of simplicity, the present disclosure is not intended to be limited in such manner, and the present disclosure is applicable to any system containing an O-RU Controller, deployed in any suitable fashion.
The CBSD Controller can be implemented, e.g., as an application that serves as the interface of the O-RUs with the Spectrum Access System (SAS), using the Wireless Innovation Forum (WINNF) CBSD-SAS Interface. The CBSD Controller may include Domain Proxy (DP) functionality as well as Radio Resource Management (RRM) functionality (e.g., channel selection based on spectrum availability). The CBSD Controller can be an application belonging to the Non-RT RIC, as an “rApp”. In the present disclosure, the CBSD Controller entity is utilized in the example embodiment, but the present disclosure is equally applicable for the case where a Domain Proxy is used instead of the CBSD Controller. Additionally, for the purpose of explaining the ideas herein, we will assume the CBSD Controller/DP is deployed as an rApp. However, the present disclosure is equally applicable in case a different deployment for the CBSD Controller/DP is chosen.
As the spectrum is reused by all O-RUs in a Shared Cell group, the spectrum is shared among all the UEs that are communicating using the O-RUs in that group.
The Shared Cell (SC) Controller is an entity that uses information about available spectrum (received from SAS) and current network conditions, including Signal to Noise ratio (SNR), Signal to Interference Ratio, and other information to decide on the best Shared Cell Group configuration for the system. The decisions that the SC Controller can implement include:
Such decisions (as those outlined above) that can be taken by the SC Controller are not necessarily CBRS specific. However, the dynamic nature of the channel allocation in the CBRS system makes CBRS a great candidate to take advantage of this solution. Systems using licensed spectrum tend to follow a deployment plan, and not be dynamic in natured. Such systems tend to have predetermined and fixed configurations. However, the solution described herein can be applied to any wireless system using the Shared Cell grouping concept, or a similar concept, such as a Distributed Antenna System (DAS).
As an example, if a CBSD is allocated a given CBRS spectrum, e.g., a 10 MHz channel, this channel may be sufficient at the time of allocation to be shared with all O-RUs in the SC group. However, if the traffic in the cell increases (e.g., due to more users being connected, or higher throughput requirements) then the CBSD may ask for more spectrum. If more channels are not granted by the SAS due to unavailability, the SC Controller may choose to split a Shared Cell Group into 2 sub-groups, with each providing their own cells (i.e., separate PCI for each new sub-group), but still reusing the same frequency/channels in each sub-group. This would require the newly formed sub-groups to manage the interference they cause in one another. This can be done, for example, by adjusting antenna patterns. The sub-groups may be joined at a later point in time if more spectrum is available or if the demand decreases. For these reasons, the CBRS system is utilized as the example embodiment in the present disclosure, but the present disclosure is applicable to any system utilizing the ORAN Shared Cell concept or similar concept such as DAS.
In one example embodiment, a SC Controller is implemented and deployed as part of the Non-RT RIC. This is depicted in
In order to assist SC Controller 10001 to make decisions on Shared Cells Group configuration, measurements provided by the radio components (i.e., O-RU, O-DU, O-CU) to the SMO via the O1 interface 10006 may be used. The measurements to be provided via O1 are specified in the technical specifications 3GPP TS 28.552 and TS 36.425. These measurements may then be provided to the SC Controller via the R1 interface 10007. These measurements are not CBRS specific and they are defined in the 3GPP specifications for LTE and 5G-NR systems, whether or not CBRS is the specific spectrum that is utilized.
The following radio resource utilization measurements may be provided to the SC Controller via the R1 (services) interface 10007, e.g.:
The following cell load measurements may be provided to the SC Controller via the R1 interface 10007, e.g.:
One or more of the following signal quality measurement may be provided to the SC Controller via the R1 interface 10007, e.g.:
In addition, these and other measurements may be used by the Non-RT RIC to predict future radio resource and cell conditions using Artificial Intelligent (AI)/Machine Learning (ML) 10008, as shown in
Information regarding the O-RUs in a Shared Cell Group need also be considered in the SC Controller decision process. This includes, e.g.:
Policies may be provided to the SC Controller 10001 from the O2 interface 10010 (coming from the cloud), from External sources via the “External Capabilities” interface 10011, or via other means such as direct input from network operator technician via a GUI. Policies may include, e.g.:
In accordance with the present disclosure, at the system startup, the SC Controller (e.g., 10001 of
During regular system operation, the SC Controller will make decisions related to SC Group modification. The SC Controller may add more channel to the group, relinquishing unused spectrum, split groups or combine groups.
The SC Controller may decide to split an SC Group into two or more groups, where each group operates in a different spectrum/channel. This allows the increase in system capacity and increase in the number of more active users that can be supported in the system.
The SC Controller may decide to split an SC Group into two or more groups, where each group operates in the same spectrum. This can be beneficial if the O-RUs in the original group are not able to properly synchronize, which makes it difficult for the FHM to combine the data received from the O-RUs in the group. This solution depends on the location of the O-RUs, otherwise there may be an increase on cell edge interference.
The SC Controller may decide to combine two or more SC Groups, creating a single group. This may be beneficial if there is a scarcity of radio resources, e.g., if the SAS can only assign a single channel/component carrier in a given geographical area, then it may be beneficial to combine all O-RUs into a single group. This solution may be utilized only if the O-RUs are near each other, e.g., maybe several O-RUs in the same floor of a building. Additionally, all the O-RUs need to be connected by the same FHM or in cascade mode.
When the SC Controller decides to modify the group, it will interact with the CBSD Controller and the O-RU Controller.
If the SC Controller wants to add a component carrier to the group, it will ask the CBSD Controller to acquire a grant from the SAS. It will provide the RU Identity or CBSD Identity, the number of component carriers being asked and the bandwidth of the component carrier. After successfully acquiring the grant from the SAS, the CBSD Controller sends the information to the SC Controller. The SC Controller passes the information to the O-RU Controller which then configures the radio components. Similar process is also followed if the SC Controller wants to relinquish a channel or make a modification (i.e., remove a channel and then add a new channel).
Exemplary messages for the communication between the SC Controller and the CBSD Controller may be as follows:
From SC Controller to CBSD Controller: scCarrierRequestArray
scCarrierRequestArray:
scCarrierRequest Object:
From CBSD Controller to SC Controller: scCarrierResponseArray
scCarrierResponseArray:
scCarrierResponse Object:
The carrierInfo Object:
After getting the successful response from the CBSD Controller, the SC Controller will pass the information to the O-RU Controller for re-configuration of the radio components. Exemplary messages for the communication between the SC Controller and the O-RU Controller may be as follows:
From SC Controller to O-RU Controller: scInformationArray
scInformationArray:
scInformation Object:
The present application claims priority to U.S. Provisional Patent Application No. 63/225,708, filed on Jul. 26, 2021, which is incorporated herein by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 63225708 | Jul 2021 | US |
