Description:FORM 2
The Patent Act 1970
(39 of 1970)
&
The Patent Rules, 2003

COMPLETE SPECIFICATION
(SEE SECTION 10 AND RULE 13)

TITLE OF THE INVENTION

“METHODS FOR MANAGING CITIZENS BROADBAND RADIO SERVICE PROCEDURE IN OPEN-RADIO ACCESS NETWORK”

APPLICANT:

Name : Sterlite Technologies Limited

Nationality : Indian

Address : 3rd Floor, Plot No. 3, IFFCO Tower,
Sector – 29, Gurugram, Haryana, 122002

The following specification particularly describes the invention and the manner in which it is to be performed:
TECHNICAL FIELD
[0001] The present disclosure relates to wireless communication and networks, and more specifically relates to methods for managing a Citizens Broadband Radio Service (CBRS) procedure in an Open-Radio Access Network (O-RAN).

BACKGROUND
[0002] An O-RAN Radio Unit (O-RU), consisting of a radio frequency (RF) transceiver, acts as a Citizen Broadband Radio Service Device (CBSD) in an Open-Radio Access Network (O-RAN), when the O-RAN operates in a Citizens Broadband Radio Service (CBRS) spectrum. However, current O-RAN specifications do not incorporate elements and interfaces of a CBRS architecture. For the O-RU in the O-RAN to be CBRS compliant, it should fulfil RF requirements for the CBSD as defined in a Federal Communications Commission (FCC) part 96, requirements specified in WinnForum, and also be able to directly or indirectly communicate with a Spectrum Access System (SAS) by sending and receiving messages (e.g., SAS-CBSD messages or the like) over a SAS-CBSD interface as defined in the WinnForum TS-0016. The messages are encoded in a JSON (JavaScript Object Notation) format as mentioned in WinnForum specifications. A payload of the SAS-CBSD messages uses a Hypertext Transfer Protocol Secure (HTTPS)-based RESTCONF protocol. In the current O-RAN, although a service management and orchestration (SMO) module and an M-Plane protocol stack support the HTTPS-based RESTCONF protocol and a NETCONF protocol, the HTTPS-based RESTCONF protocol is optional, and the O-RU predominantly uses the NETCONF protocol for management which supports only XML encoding.
[0003] Thus, in order to facilitate communication of the O-RU (i.e., CBSD) with the SAS which is an external entity and enable an operation of the O-RU in a CBRS shared spectrum by fulfilling the requirements given by the CBRS Alliance/WinnForum, certain modifications are required in the current O-RAN architecture including, but not limited to, an ability to translate the SAS-CBSD messages to a format (e.g., XML format) that can be understood by the O-RU through a standard M-plane interface in the O-RAN and vice versa.
[0004] Some of the prior art references are given below for managing the CBRS procedure in the O-RAN:
[0005] US2020305159A1 discloses a Citizens Broadband Radio Service (CBRS) communication system that includes at least one baseband controller communicatively coupled to a spectrum access system (SAS) to allocate radio frequency (RF) channels in the CBRS communication system. The system enables a C-RAN to provide wireless service to user equipment (UE) in the CBRS band using Time Division Duplex (TDD).
[0006] US20220141668A1 discloses a computer that dynamically enforces a sanction criterion in a shared-license-access band of frequencies. A radio node communicates with the computer to receive authorization from the computer to operate in the shared-license-access band of frequencies. The radio node may request a grant to reserve 5, 10, 20, 40, 80, 100, or 150 MHz of spectrum in a particular geographic region in the CBRS from the computer. The sanction criteria may be associated with a standard (such as the 3rd Generation Partnership Project, Open Radio Access Network (O-RAN)).
[0007] US10856301B2 discloses a method implemented in a controlling node (Spectrum Access System (SAS)) for controlling resources in a shared channel. The controlling node receives a request from a network node (CBSD) for resources in the shared channel and grants the resources based on the fulfillment of criteria.
[0008] US20190115950A discloses methods and apparatus for providing quasi-licensed spectrum access within a prescribed area or venue, including to users or subscribers of one or more Mobile Network Operators (MNOs). The users or subscribers can use Citizens Broadband Radio Service (CBRS) quasi-licensed band in communicating with an access point of a radio access network.
[0009] A non-patent literature entitled “ChARM: NextG Spectrum Sharing Through Data-Driven Real-Time O-RAN Dynamic Control” discloses a Channel-Aware Reactive Mechanism (ChARM), a data-driven O-RAN-compliant framework that allows (i) sensing the spectrum to infer the presence of interference and (ii) reacting in real time by switching the distributed unit (DU) and radio unit (RU) operational parameters according to a specified spectrum access policy.
[0010] While the prior arts disclose various techniques for managing the CBRS procedure in the O-RAN, but none of the prior art references disclose the implementation of a CBRS RAN management function in the O-RAN architecture to enable the operation of the O-RU in the CBRS shared spectrum and use of the CBRS RAN management function for translation of CBRS messages in the O-RAN.

OBJECT OF THE DISCLOSURE
[0011] A principal object of the present disclosure is to solve the aforesaid drawbacks and provide methods for managing a Citizens Broadband Radio Service (CBRS) procedure in an Open-Radio Access Network (O-RAN).
[0012] Another object of the present disclosure is to facilitate communication of an Open Radio Unit (O-RU) (e.g., Citizen Broadband Radio Service Device (CBSD)) with a Spectrum Access System (SAS) to enable the operation of the O-RU in a CBRS shared spectrum.
[0013] Another object of the present disclosure is to use a CBRS RAN management function module to enable the flow of CBRS messages in the O-RAN.
[0014] Another object of the present disclosure is to provide the CBRS RAN management function module in a service management and orchestration (SMO) module (aka “SMO framework”) to enable communication between the SAS and the O-RU.
[0015] Another object of the present disclosure is to provide the CBRS RAN management function module in a Network Management System (NMS) to enable communication between the SAS and the O-RU.
[0016] Another object of the present disclosure is to provide the CBRS RAN management function module in an Open-Distributed Unit (O-DU) to enable communication between the SAS and the O-RU.

SUMMARY
[0017] Accordingly, the present disclosure provides methods for managing a Citizens Broadband Radio Service (CBRS) procedure in an Open-Radio Access Network (O-RAN). The CBRS procedure can be a SAS-CBSD procedure. The O-RAN includes at least one Service Management and Orchestration (SMO) module, an Operation and Maintenance (OAM) function module, a Network Management System (NMS), an Open-Distributed Unit (O-DU), and an Open-Radio Unit (O-RU). The method includes enabling an exchange of at least one message (e.g., SAS-CBSD message or the like) between the O-RU and one of a Spectrum Access System (SAS) and/or a Domain Proxy (DP), wherein the SAS allocates channels to a plurality of Citizen Broadband Radio Service Device (CBSDs), and the DP manages communications with the SAS on behalf of the plurality of CBSDs. The O-RU can be a CBSD from the plurality of CBSDs. The exchange of at least one message is enabled by a CBRS RAN Management (CRM) function module, where the CRM function module acts as an interface between the O-RU and one of the SAS and the DP.
[0018] Alternatively, the method comprises facilitating the exchange of at least one message between the O-RU and one of the SAS and/or the DP over an Open Fronthaul M-Plane interface in a hybrid topology, wherein exchange of the at least one message is facilitated by the CRM function module in the SMO module.
[0019] Alternatively, the method includes facilitating the exchange of at least one message between the O-RU and one of the SAS and the DP through the O-DU in a hierarchical topology, wherein at least one message is sent over an O1 interface from the SMO module to the O-DU and then sent over the Open Fronthaul M-Plane interface from the O-DU to the O-RU, wherein exchange of the at least one message is facilitated by the CRM function module in the SMO module.
[0020] Alternatively, the method includes facilitating the exchange of at least one message between the O-RU and one of the SAS and the DP over the Open Fronthaul M-Plane interface in the hybrid topology, wherein exchange of the at least one message is facilitated by the CRM function module in the OAM function module.
[0021] Alternatively, the method includes facilitating the exchange of at least one message between the O-RU and one of the SAS and the DP through the O-DU in the hierarchical topology, wherein at least one message is sent over the O1 interface from the OAM function module to the O-DU and then sent over the Open Fronthaul M-Plane interface from the O-DU to the O-RU, wherein exchange of the at least one message is facilitated by the CRM function module in the OAM function module.
[0022] Alternatively, the method includes facilitating the exchange of at least one message between the O-RU and one of the SAS and the DP over the Open Fronthaul M-Plane interface in the hybrid topology, wherein exchange of the at least one message is facilitated by the CRM function module in the SMO module and the CRM function module interacts with the OAM function module via an Internal interface.
[0023] Alternatively, the method includes facilitating the exchange of at least one message between the O-RU and one of the SAS and the DP through the O-DU in the hierarchical topology, wherein the at least one message is sent over the O1 interface from the SMO module to the O-DU and then sent over the Open Fronthaul M-Plane interface from the O-DU to the O-RU, wherein exchange of the at least one message is facilitated by the CRM function module in the SMO module and the CRM function module interacts with the OAM function module via the internal interface.
[0024] Alternatively, the method includes facilitating the exchange of the at least one message between the O-RU and one of the SAS and the DP over a Netconf protocol-based interface in the hybrid topology, wherein exchange of the at least one message is facilitated by the CRM function module in the NMS.
[0025] Alternatively, the method includes facilitating the exchange of at least one message between the O-RU and one of the SAS and the DP through the O-DU in the hierarchical topology, wherein at least one message is sent over the Netconf protocol-based interface from the NMS to the O-DU and then sent over the Open Fronthaul M-Plane interface from the O-DU to the O-RU, wherein exchange of the at least one message is facilitated by the CRM function module in the NMS.
[0026] Alternatively, the method includes facilitating the exchange of at least one message between the O-RU and one of the SAS and the DP, wherein the at least one message is sent over the O1 interface from the OAM function module to the O-DU and then sent over the Open Fronthaul M-Plane interface from the O-DU to the O-RU, wherein exchange of the at least one message is facilitated by the CRM function module in the O-DU.
[0027] The method includes translating the at least one message to a predefined format, wherein the predefined format is an XML format and is understood by the O-RU through the Open Fronthaul M-Plane interface in the O-RAN.
[0028] These and other aspects herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following descriptions are given by way of illustration and not of limitation. Many changes and modifications may be made within the scope of the invention herein without departing from the spirit thereof.

BRIEF DESCRIPTION OF FIGURES
[0029] The invention is illustrated in the accompanying drawings, throughout which like reference letters indicate corresponding parts in the drawings. The invention herein will be better understood from the following description with reference to the drawings, in which:
[0030] FIG. 1 illustrates Citizens Broadband Radio Service (CBRS) tiers.
[0031] FIG. 2 illustrates a CBRS tiers spectrum.
[0032] FIG. 3 illustrates an overview of a CBRS architecture displaying SAS-CBSD interfaces.
[0033] FIG. 4 illustrates an overview of a general architecture of an Open-Radio Access Network (O-RAN).
[0034] FIG. 5 illustrates an example scenario in which a proposed CBRS architecture supports a CBRS in an O-RAN in which a CRM (CBRS RAN Management) function (aka “CRM function module”) is added in an SMO (Service Management and Orchestration) module in a hybrid topology.
[0035] FIG. 6 illustrates an example scenario in which the proposed CBRS architecture supports the CBRS in the O-RAN in which the CRM function module is added to the SMO module in a hierarchical topology.
[0036] FIG. 7 illustrates an example scenario in which the proposed CBRS architecture supports the CBRS in the O-RAN in which the CRM function module is added in an OAM (Operation and Maintenance) function (aka “OAM function module”) in the hybrid topology.
[0037] FIG. 8 illustrates an example scenario in which the proposed CBRS architecture supports the CBRS in the O-RAN in which the CRM function module is added in the OAM function module in the hierarchical topology.
[0038] FIG. 9 illustrates an example scenario in which the proposed CBRS architecture supports the CBRS in the O-RAN in which the CRM function module is added in the SMO and interacts with the OAM function module in the hybrid topology.
[0039] FIG. 10 illustrates an example scenario in which the proposed CBRS architecture supports the CBRS in the O-RAN in which the CRM function module is added in the SMO and interacts with the OAM function module in the hierarchical topology.
[0040] FIG. 11 illustrates an example scenario in which the proposed CBRS architecture supports the CBRS in the O-RAN in which the CRM function module is added in a Network Management System (NMS) in the hybrid topology.
[0041] FIG. 12 illustrates an example scenario in which the proposed CBRS architecture supports the CBRS in the O-RAN in which the CRM function module is added in the NMS in the hierarchical topology.
[0042] FIG. 13 illustrates an example scenario in which the proposed CBRS architecture supports the CBRS in the O-RAN in which the CRM function module is added in an Open-Distributed Unit (O-DU).
[0043] FIG. 14 illustrates various hardware elements of a network module.
[0044] FIG. 15 is a flow chart illustrating a method for managing a CBRS procedure in the O-RAN.

DETAILED DESCRIPTION
[0045] In the following detailed description of the invention, numerous specific details are set forth in order to provide a thorough understanding of the invention. However, it will be obvious to a person skilled in the art that the invention may be practiced with or without these specific details. In other instances, well known methods, procedures and components have not been described in details so as not to unnecessarily obscure aspects of the invention.
[0046] Furthermore, it will be clear that the invention is not limited to these alternatives only. Numerous modifications, changes, variations, substitutions and equivalents will be apparent to those skilled in the art, without parting from the scope of the invention.
[0047] The accompanying drawings are used to help easily understand various technical features and it should be understood that the alternatives presented herein are not limited by the accompanying drawings. As such, the present disclosure should be construed to extend to any alterations, equivalents, and substitutes in addition to those which are particularly set out in the accompanying drawings. Although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are generally only used to distinguish one element from another.
[0048] Now referring to figures, where FIG. 1 illustrates Citizens Broadband Radio Service (CBRS) tiers (100) and FIG. 2 illustrates a CBRS tiers spectrum (200). A CBRS is a band of the radio-frequency spectrum from 3.55 GHz to 3.7 GHz that the Federal Communications Commission (FCC) has designated for sharing among three tiers of users such as Tier 1- Incumbents (higher priority), Tier 2 - Priority Access Licensee (PAL) and Tier 3 - General Authorized Access (GAA), where higher priority users must be protected from interference by lower-priority users.
[0049] Tier 1: Incumbent access licenses include authorized federal users, fixed satellite service earth stations, and grandfathered wireless broadband licensees. The grandfathered wireless broadband group has a finite term limit on the Tier 1, and then is moved to the Tier 3. The incumbent access users are protected against interference from both the tier 2 users and the tier 3 users.
[0050] Tier 2: If incumbents aren’t using their CBRS resources, PALs have the right to utilize that spectrum. The PALs are licensed through a competitive bidding process on a county-by-county basis across the countries (e.g., the USA, India or the like). Each PAL is renewable every 10 years and consists of a 10 MHz channel within the 3.5 GHz band. Licensees are subject to a four PAL channel aggregation cap and must meet stringent performance requirements by the end of the initial license term. The PAL licensees must protect and accept interference from the tier 1 users, but they are protected against interference from the tier 3 users. The PALs have unique characteristics that set them apart from other tiers: PALs are not issued for specific channel blocks. Rather, they are assigned dynamically by SAS providers to accommodate other users and to protect incumbents. GAA users can operate within an unused spectrum channel block owned by the PAL. Therefore, the PAL users are encouraged to use the channel blocks they own, or they may have to give them up to the tier 3 user.
[0051] Tier 3: If neither incumbents nor PALs are using CBRS resources, then the GAA users can take advantage of the spectrum for their use. GAA licenses offer open, flexible access to the 3.5 GHz band for the widest possible group of potential users. This spectrum is free, subject to only the small monthly service fee provided by vendors. However, the GAA users must not cause interference to the tier 1 users or the tier 2 users and receive no protection from other GAA users. Like PALs, GAA spectrum is issued in 10 MHz channel blocks and is available for use as long as there is no other GAA user at a specific location.
[0052] The deficiencies in previous techniques (as discussed in the background section, FIG. 1, and FIG. 2) are solved by the proposed disclosure that provides a simplified Citizens Broadband Radio Service (CBRS) compliant O-RAN. The CBRS compliant O-RAN consists of a CBRS RAN Management (CRM) function in an O-RAN, which communicates with a Spectrum Access System (SAS) / a Domain Proxy (DP) and facilitates interface with an Open-Radio Unit (O-RU), which acts as a Citizen Broadband Radio Service Device (CBSD).
[0053] FIG. 3 illustrates an overview of a CBRS architecture (300). The CBRS architecture (300) includes a Spectrum Access System (SAS) (304), a SAS-CBSD interface (306), a Domain Proxy (DP) (308), and a plurality of Citizen Broadband Radio Service Device (CBSDs) (310a-310n) (collectively “310”), which are part of O-RAN (302).
[0054] The O-RAN (302) is a part of a telecommunications system which connects individual devices to other parts of a network through radio connections. The O-RAN (302) provides a connection of user equipment (UE) such as mobile phones or computers with a core network of telecommunication systems. The O-RAN (302) is an essential part of the access layer in telecommunication systems which utilizes base stations (such as eNodeB, and gNodeB) for establishing radio connections. The O-RAN (302) is an evolved version of prior radio access networks, making the prior radio access networks more open and smarter than previous generations. The O-RAN (302) provides real-time analytics that drives embedded machine learning systems and artificial intelligence (AI) back-end modules to empower network intelligence. Further, the O-RAN (302) includes virtualized network elements with open and standardized interfaces. The open interfaces are essential to enable smaller vendors and operators to quickly introduce their own services or enable operators to customize the network to suit their own unique needs. Open interfaces also enable multivendor deployments, enabling a more competitive and vibrant supplier ecosystem. Similarly, open-source software and hardware reference designs enable faster, more democratic and permission-less innovation. Further, the O-RAN (302) introduces a self-driving network by utilizing new learning-based technologies to automate operational network functions. These learning-based technologies make the O-RAN intelligent. Embedded intelligence, applied at both component and network levels, enables dynamic local radio resource allocation and optimizes network wide efficiency. In combination with O-RAN’s open interfaces, AI-optimized closed-loop automation is a new era for network operations.
[0055] The O-RAN (302) manages a Citizens Broadband Radio Service (CBRS) procedure by enabling an exchange of at least one message (e.g., SAS-CBSD message or the like) between the O-RU (aka “CBSD”) (310) and one of the SAS (304) and the DP (308). The CBRS procedure can be, for example, but is not limited to a SAS-CBSD procedure, a CBSD registration procedure, a spectrum inquiry procedure, a grant procedure, a CBSD heartbeat procedure, a CBSD grant relinquishment procedure, and a CBSD deregistration procedure message.
[0056] SAS-CBSD Procedures: The SAS-CBSD procedures describe how the SAS-CBSD messages are used and how they are combined to perform activities. A SAS-CBSD protocol is based on a HTTPS (HTTP over TLS) protocol. The HTTPS protocol provides transport level assurance that a message has been received by an intended recipient.
[0057] CBSD Registration Procedure: The CBSD (310) performs registration with the SAS (304) via the HTTPS (HyperText Transfer Protocol) over Transport Layer Security (TLS). If the domain proxy (DP) (308) is present in the O-RAN (302), then the CBSD (310) sends multiple registration requests. The SAS (304) requires certain information elements from the CBSD (310) for successful registration. The CBSD (i.e., O-RU) (310) provides information to a CRM function module (328) (as shown in FIG. 5) over a standard NETCONF interface. The CRM function module (328) may consist of a database with information on the CBSDs (310) connected to it and facilitate the creation of a registration request message that can be sent over the SAS-CBSD interface (306). The CRM function module (328) interacts with the SAS (304) and in case of successful registration, receives a registration response message, which consists of a CBSD-ID. The CRM function module (328) translates the message and communicates to the CBSD (310) that registration was successful and sends the CBSD-ID to the CBSD (e.g., O-RU) (310).
[0058] Spectrum Inquiry Procedure: The spectrum inquiry procedure allows the registered CBSDs (310) to obtain information from the SAS (304) about available channels. The CBSD (O-RU) (310) can initiate the spectrum inquiry procedure by sending a spectrum inquiry request message to the CRM function module (328) over a NETCONF interface, which translates and forwards the message accordingly to the SAS (304) over the SAS-CBSD interface (306). Based on the request passed by the CRM function module (328), the SAS (304) may send a spectrum inquiry response to the CRM function module (328) with information about the frequency range of the available channels. The CRM function module (328) translates the same to the CBSD (O-RU) (310). Based on the response received from the SAS (304), the CBSD (310) may initiate a grant request for any desired and available channel.
[0059] Grant Procedure: The CBSD (O-RU) (310) may send a grant request to the SAS (304) via the CRM function module (328) with parameters such as frequency and maximum Equivalent Isotropic Radiated Power (EIRP) it wants to use for operation. The SAS (304) may respond to the grant response that could be either successful or unsuccessful. If the grant request is successful, the CBSD (310) also receives a grant expiration time, which informs the CBSD (310) when the grant received expires.
[0060] CBSD Heartbeat Procedure: A heartbeat request object informs the SAS (304) that the CBSD (O-RU) (310) needs access to an allocated spectrum. It also allows the SAS (304) to suspend or terminate the grant. The CBSD (O-RU) (310) sends this information via the CRM function module (328). If the transmit expiration timer expires prior to reception of the heartbeat response object from the SAS (304) via the CRM function module (328), the CBSD (O-RU) (310) discontinues transmission for the grant within 60 seconds after the value of the transmit expire time parameter expires, in accordance with part FCC 96.39(c)(2). The transmit expiration timer is used to determine the time after which the CBSD (i.e., O-RU) (310) stops transmission. If the grant is suspended or terminated, the SAS (304) has the option, within the heartbeat response object, of suggesting that the CBSD should request an alternative spectrum.
[0061] The CBSD heartbeat procedure may be executed concurrently for each active grant. An active grant has a grantId and is not terminated, expired or relinquished. Additionally, the SAS (304) to a CBSD connectivity is not considered to be lost. When the Grant is terminated, expires or is relinquished, or the SAS (304) to CBSD connectivity is considered to be lost, its grantId is revoked (i.e., is no longer usable). The SAS (304) to the CBSD connectivity is considered to be lost when during seven days, there is no successful heartbeat procedure between the SAS (304) and the CBSD (i.e., O-RU) (310).
[0062] CBSD Grant Relinquishment Procedure: The CBSD (O-RU) (310) may initiate this procedure for an existing grant. The CBSD (310) shall terminate radio operations associated with this grant before initiating this procedure. The CBSD (310) sends a relinquishment request message with necessary parameters (such as cbsdID, grantID parameters) to the CRM function module (328) which forwards the same to the SAS (304) in the desired format over the SAS-CBSD interface (306). The cbsdID parameter identifies the CBSD (O-RU) (310) to the SAS (304) and the grantId parameter identifies the grant the CBSD (310) wants to relinquish. The SAS (304) responds with a relinquishment response message to the CBSD (O-RU) (310) via the CRM function module (328). If the relinquishment is successful, the CBSD (310) no longer has the authorization to operate in the spectrum associated with the relinquished grant.
[0063] CBSD Deregistration Procedures: When the CBSD (O-RU) (310) decides that it should deregister from the SAS (304), it ceases transmission associated with any grants and then sends a deregistration request object (e.g., cbsdId) to the SAS (304) via the CRM function module (328). The CBSD (310) then cancels any grants that it still believes are allocated to it. The SAS (304) marks the CBSD (310) as unregistered, removes any existing grants, and responds with a deregistration response via the CRM function module (328).
[0064] In the CBRS architecture (300), each radio transceiver using the spectrum is referred to as the CBSD (310). The Citizens Broadband Radio Service Device (CBSD) (310) is a device that communicates within a CBRS frequency range (3550-3700 MHz). The CBSD (310) obtains the grants from the SAS (304) via the SAS-CBSD interface (306). There are three types of CBSDs: Category A, Category B and End User Devices (EUD). The CBSDs (310a-310n) operating in the CBRS band can register with the SAS (304) and provide their location and other details to the SAS (304). The SAS (304) may then allocate a set of RF (radio frequency) channels that the PAL and GAA users can access. The SAS-CBSD procedures are defined in WinnForum and the SAS-CBSD interface (306) supports the transmission and reception of the messages associated with these procedures. The SAS-CBSD messages are encoded using JSON (JavaScript Object Notation) format.
[0065] A few example SAS-CBSD messages and their JSON array names as defined in the WinnForum specifications are shown in Table 1.
Sas_method_name JSON array name of a request message JSON array name of a response message
registration registrationRequest registrationResponse
spectrumInquiry spectrumInquiryRequest spectrumInquiryResponse
grant grantRequest grantResponse
heartbeat heartbeatRequest heartbeatResponse
relinquishment relinquishmentRequest relinquishmentResponse
deregistration deregistrationRequest deregistrationResponse
Table 1
[0066] The Domain Proxy (DP) (308) is an entity engaged in communications with the SAS (304) on behalf of multiple individual CBSDs (310) or networks of CBSDs (310a-310n). The Domain Proxy (308) can also provide a translational capability to interface legacy radio equipment in the 3650-3700 MHz band with the SAS (304) to ensure compliance with the FCC Part 96 rules. The DP (308) presents a consistent and secure interface to the SAS (304) that can convey all messages pertaining to the SAS-CBSD interface (306) for the CBSDs (310a-310n). The DP (308) manages communications with the SAS (304) on behalf of the plurality of CBSDs (aka “O-RUs”) (310a-310n).
[0067] The SAS (304) is an FCC-mandated function that is responsible for managing CBSDs' spectrum usage and allocating channels to CBSDs (310a-310n) upon request. The SAS (304) is also a primary entity that ensures FCC compliance of all devices (e.g., CBSDs (310a-310n)) operating in the CBRS spectrum. Since the CBRS band is an open spectrum, it can be used by different devices operating according to different wireless protocols, e.g., CBSD (310), Wi-Fi devices, etc. In addition to authorizing and managing the use of the CBRS spectrum, the SAS (304) can protect higher-tier operators from interference. The SAS (304) is aware of the nature of each CBSD’s license, e.g., PAL or GAA. The SAS (304) also has current information regarding the presence or absence of incumbent transmissions in each geographical area (gathered via the RF sensors). The SAS (304) allocates channels to the CBSDs (aka “O-RU”) (310).
[0068] FIG. 4 illustrates an overview of the general architecture of the O-RAN (302). The O-RAN (302) may further comprise a plurality of network modules (discussed later in Fig. 14). The plurality of network modules are one of a Service Management and Orchestrator (SMO) (can also be termed as “Service Management and Orchestration Framework”) (312) (aka “SMO module”), a Non-Real Time RAN Intelligent Controller (Non-RT-RIC) (314) (act as a master controller) residing in the SMO (312), a Near-Real Time RAN Intelligent Controller (Near-RT-RIC) (316), an Open Distributed Unit (O-DU) (320), the Open Radio Unit (O-RU) (aka “CBSD”) (310), and an Open Cloud (O-Cloud) (322).
[0069] The SMO (312) is configured to provide SMO functions/services such as data collection and provisioning services of the O-RAN (302). The data collection of the SMO (312) may include, for example, data related to a bandwidth of a wireless communication network and at least one of a plurality of user equipments (not shown in figures). That is, the SMO (312) oversees all the orchestration aspects, management and automation of O-RAN elements and resources and supports O1, A1 and O2 interfaces. Further, when the SMO (312) receives an order to integrate a new cell into the O-RAN (302), the SMO (312) orders the O-Cloud (322) to allocate resources present in cloud infrastructure to an access node (like the O-DU (320)) for configuring and initializing the new cell. Further, the SMO (312) manages the O-RAN network functions (NF) module (318) using an O-RAN OAM Architecture, where the O-RAN Network Functions module (318) communicates with the SMO via O1, A1, and Open Fronthaul M-plane interfaces.
[0070] As the O-RAN (302) continues to evolve towards more open architecture, opportunities for innovation in the O-RAN space have proliferated. One of the central components within the O-RAN (302) is a RAN Intelligent Controller (RIC), which provides an open hosting platform and is responsible for controlling and optimizing the RAN functions. The RIC incorporates AI/ML into its decision-making functionalities and comes in two forms: the Non-RT-RIC (314) and the Near-RT-RIC (316), which can be adapted to specific latency or control loop requirements.
[0071] The Non-RT-RIC (314) is a logical function that enables non-real-time control and optimization of the O-RAN elements and resources, AI/ML workflow including model training and updates, and policy-based guidance of applications/features in the Near-RT-RIC (316). The Non-RT-RIC (314) is a part of the SMO Framework (312) and communicates to the Near-RT-RIC (316) using the A1 interface. The Near-RT-RIC (316) is a logical function that enables near-real-time control and optimization of the O-RAN elements and resources via fine-grained data collection and actions over an E2 interface.
[0072] Non-Real Time (Non-RT) control functionality (>1s) and Near-Real Time (Near-RT) control functions (<1s) are decoupled in the RIC. The Non-RT functions include service and policy management, RAN analytics and model-training for some of the near-RT-RIC functionality, and non-RT-RIC optimization.
[0073] The O-DU (320) is a logical node hosting RLC/MAC (Medium access control)/High-PHY layers based on a lower layer functional split and supports O1, E2-du, F1-c, F1-u, OFH CUS–Plane and OFH M-Plane interfaces.
[0074] The O-RU (310) is a logical node hosting the Low-PHY layer and RF (Radio Frequency) processing based on a lower layer functional split. This is similar to 3GPP’s “TRP (Transmission And Reception Point)” or “RRH (Remote Radio Head)” but more specific in including the Low-PHY layer (FFT/iFFT, PRACH (Physical Random Access Channel) extraction). The O-RU (310) utilizes OFH CUS–Plane and OFH M-Plane interfaces.
[0075] The O-RU (310) is managed by an Open Fronthaul M-plane interface using a NETCONF protocol. The O-DU (320) and the SMO (312) can manage the O-RU (310) and correspond to NETCONF clients while the O-RU(s) (310) correspond to NETCONF server(s). The O-RAN specification has defined two configuration models for O-RU management namely: The hierarchical model and the Hybrid model. In the hierarchical model, the O-RU is managed by the O-DU (320) while in the hybrid model, the Open Fronthaul M-plane interface connects the O-RU (310) to the SMO (312) for FCAPS (fault, configuration, accounting, performance, security) functionality. Following FCAPS functions are examples of capabilities supported across the Open Fronthaul M-plane interface.
a) “Start-up” installation,
b) Software (SW) management,
c) Configuration management (O-RU parameter get/set),
d) Performance management (O-RU measurement),
e) Fault Management, and
f) File Management (O-RU data file send/receive)
[0076] Further, O-RU management functions to set parameters are done over the Open Fronthaul M-plane interface. The O-RU management functions include O-RU software management, fault management etc. Regarding this, the O-RAN fronthaul specifications prescribe various parameters as data models to achieve the required management operation. This eliminates dependency on different O-RU vendor's implementation and makes multi-vendor RAN possible.
[0077] The O-Cloud (322) is a collection of physical RAN nodes (that host various RICs, CUs, and DUs), software components (such as operating systems and runtime environments) and the SMO (312), where the SMO (312) manages and orchestrates the O-Cloud (322) from within via the O2 interface. The O-Cloud (322) refers to a collection of O-Cloud resource pools at one or more locations and the software to manage nodes and deployments hosted on them. The O-Cloud (322) will include functionality to support both deployment-plane and management services. An external entity (326) provides enrichment data to the SMO (312).
[0078] Now referring to the various interfaces used in the O-RAN (302) as mentioned above.
[0079] The O1 interface is the element operations and management interface between management entities in the SMO (312) and O-RAN managed elements, for operation and management, by which FCAPS (fault, configuration, accounting, performance, security) management, Software management, File management shall be achieved. The O-RAN managed elements include the Near-RT-RIC (316), an O-CU (Open-Central Unit (not shown)), the O-DU (320), the O-RU (310) and an O-eNB (not shown). The management and orchestration functions are received by the aforesaid O-RAN managed elements via the O1 interface. The SMO (312) in turn receives data from the O-RAN managed elements via the O1 interface for AI model training.
[0080] The O2 interface is a cloud management interface, where the SMO (312) communicates with the O-Cloud (322) it resides in. Typically, operators that are connected to the O-Cloud (322) can then operate and maintain the O-RAN (302) with the O1 or O2 interfaces.
[0081] The A1 interface enables the communication between the Non-RT-RIC (314) and the Near-RT-RIC (316) and supports policy management, machine learning and enrichment information transfer to assist and train AI and machine learning in the Near-RT-RIC (316).
[0082] An NG (Next Generation) interface connects the O-RAN network functions module (318) to a 5G core (aka “NG core”) (324). A control plane information is transmitted to a 5G access and mobility management function (AMF) that receives connection and session information from the user equipment and the user plane information is relayed to a 5G user plane function (UPF), which handles tunnelling, routing and forwarding, for example.
[0083] FIG. 5 illustrates an example scenario in which the proposed CBRS architecture (300) supports the CBRS in the O-RAN in which the CRM function module (328) is added in the SMO module (312) in a hybrid topology.
[0084] The CRM function module (328) acts as an interface between the SAS (304) or the DP (308), which are external entities and the O-RU (CBSD) (310) which is part of the O-RAN (302). The CRM function module (328) performs a translation of JSON messages from the SAS (304) or the DP (308) to the XML format for the O-RU (310) to understand over the NETCONF and vice versa. The CRM function module (328) sends and receives the SAS-CBSD procedures related messages to and from the O-RU (310) over the Open Fronthaul M-Plane interface. Further, the CRM function module (328) sends and receives the SAS-CBSD procedures related messages to and from the SAS (304) over the SAS-CBSD interface (306).
[0085] In order to accommodate the modifications carried out to the O-RAN (302) and to support the sending and receiving of the SAS-CBSD-related messages, the addition of one or more necessary parameters and procedures in an O-RU YANG module (not shown) is required for the SAS-CBSD messages. The O-RU YANG module stores one or more parameters and procedures. The one or more procedures required for the sending and receiving of the SAS-CBSD related messages are the CBSD registration procedure, the spectrum inquiry procedure, the grant procedure, the CBSD heartbeat procedure, the CBSD grant relinquishment procedure, and the CBSD deregistration procedure. The one or more parameters that define one or more SAS-CBSD procedures are discussed in the WinnForum.
[0086] By adding the CRM function module (328) to the SMO module (312), the SMO module (312) facilitates the communication of the necessary messages from the SAS (304) /DP (308) to the CBSD (O-RU) (310) over the Open Fronthaul M-Plane in the hybrid topology and vice versa. A configuration made on the O-RU (310) via the Open Fronthaul M-Plane is communicated to the O-DU (320) by using a NETCONF configuration notification capability.
[0087] FIG. 6 illustrates an example scenario in which the proposed CBRS architecture (300) supports the CBRS in the O-RAN in which the CRM function module (328) is added to the SMO module (312) in a hierarchical topology. By adding the CRM function module (328) in the SMO module (as an SMO function) (312), the CRM function module (328) facilitates the communication of the necessary messages from the SAS (304) /DP (308) to the CBSD (O-RU) (310) through the O-DU (320) in the hierarchical topology. By using the CRM function module (328), the messages are sent over the O1 interface from the SMO (312) to the O-DU (320) and the Open Fronthaul M-Plane from the O-DU (320) to the O-RU (310). The dotted/dashed line in FIG. 6 indicates the message flow between SAS (304) and the CBSD (310) in the CBRS architecture (300).
[0088] FIG. 7 illustrates an example scenario in which the proposed CBRS architecture (300) supports the CBRS in the O-RAN in which the CRM function module (328) is added to an OAM (Operation and Maintenance) function module (330) in the hybrid topology. The OAM function module (330) provides the functionality for operations, administration, maintenance, and management of a radio side of the O-RAN architecture as envisioned in the O-RAN (302). The CRM function module (328) in the OAM function module (330) facilitates the communication of the necessary messages from the SAS (304) /DP (308) to the CBSD (O-RU) (310) over the Open Fronthaul M-Plane in the hybrid topology and vice versa. A configuration made on the O-RU (310) via the Open Fronthaul M-Plane is communicated to the O-DU (320) by using the NETCONF configuration notification capability.
[0089] FIG. 8 illustrates an example scenario in which the proposed CBRS architecture (300) supports the CBRS in the O-RAN in which the CRM function module (328) is added to the OAM function module (330) in the hierarchical topology. The CBRS RAN management function module (328) in the OAM function module (330) facilitates the communication of the necessary messages from the SAS (304) /DP (308) to the CBSD (O-RU) (310) through the O-DU (320) in the hierarchical topology. By using the CRM function module (328), the messages are sent over the O1 interface from the OAM function module (330) to the O-DU (320) and the open fronthaul M-Plane from the O-DU (320) to the O-RU (310). The dotted/dashed line in FIG. 8 indicates the message flow between the SAS (304) and the CBSD (310) in the architecture (300).
[0090] FIG. 9 illustrates an example scenario in which the proposed CBRS architecture (300) supports the CBRS in the O-RAN in which the CRM function module is added in the SMO and interacts with the OAM function module (330) in the hybrid topology. The CRM function module (328) in the SMO (as an SMO function) (312) interacts with the OAM function module (330) via an internal interface and facilitates the communication of the necessary messages from the SAS (304) /DP (308) to the CBSD (O-RU) (310) over the Open Fronthaul M-Plane in the hybrid topology and vice versa. A configuration made on the O-RU (310) via the Open Fronthaul M-Plane is communicated to the O-DU (320) by using the NETCONF configuration notification capability.
[0091] FIG. 10 illustrates an example scenario in which the proposed CBRS architecture (300) supports the CBRS in the O-RAN in which the CRM function module is added in the SMO and interacts with the OAM function module (330) in the hierarchical topology. The CRM function module (328) in the SMO (as an SMO function) (312) interacts with the OAM Function module (330) via an internal interface and facilitates the communication of the necessary messages from the SAS (304) /DP (308) to the CBSD (O-RU) (310) through the O-DU (320) in the hierarchical topology. By using the CRM function module (328), the messages are sent over the O1 interface from the CRM function module (328) to the O-DU (320) and the Open Fronthaul M-Plane from the O-DU (320) to the O-RU (310). The dotted/dashed line in FIG. 10 indicates the message flow between the SAS (304) and the CBSD (310) in the architecture (300).
[0092] FIG. 11 illustrates an example scenario in which the proposed CBRS architecture (300) supports the CBRS in the O-RAN in which the CRM function module (328) is added in an NMS (332) in the hybrid topology. In the M-Plane, the NMS (332) is used to manage the O-RU(s) (310). The NMS (332) uses the NETCONF to manage the O-RU(s) (310). The NMS(s) (332) corresponds to NETCONF client(s) while the O-RU(s) (310) corresponds to NETCONF server(s). As shown in FIG. 11, the CRM function module (328) in the NMS (332) facilitates the communication of the necessary messages from the SAS (304) /DP (308) to the CBSD (O-RU) (310) over the Netconf protocol-based interface in the hybrid topology. A configuration made on the O-RU (310) via the Open Fronthaul M-Plane is communicated to the O-DU (320) by using NETCONF configuration notification capability.
[0093] FIG. 12 illustrates an example scenario in which the proposed CBRS architecture (300) supports the CBRS in the O-RAN in which the CRM function module (328) is added in the NMS (332) in the hierarchical topology. The CRM function module (328) in the NMS (332) facilitates the communication of the necessary messages from the SAS (304) /DP (308) to the CBSD (O-RU) (310) through the O-DU (320) in the hierarchical topology. By using the CRM function module (328), the messages are sent over the Netconf protocol-based interface from the CRM function module (328) to the O-DU (320) and the Open Fronthaul M-Plane from the O-DU (320) to the O-RU (310). The dotted/dashed line in FIG. 12 indicates the message flow between the SAS (304) and the CBSD (310) in the architecture (300).
[0094] FIG. 13 illustrates an example scenario in which the proposed CBRS architecture (300) supports the CBRS in the O-RAN in which the CRM function module (328) is added in the O-DU (320). The CRM function module (328)) in the O-DU (320) facilitates the communication of the necessary messages from the SAS (304) /DP (308) to the CBSD (O-RU) (310) over the Open Fronthaul M-Plane. The O-DU (320) receives the SAS-CBSD messages from the OAM Function module (330) over the O1 interface which can support the RESTCONF protocol. The dotted/dashed line in FIG. 13 indicates the message flow between the SAS (304) and the CBSD (310) in the architecture (300).
[0095] FIG. 14 illustrates various hardware elements of a network module (1400). The network module (1400) can be, for example, but not limited to, the SMO module (312), the OAM function module (330), the NMS (332), and the O-DU (320). The network module (1400) may include a processor (1402), a memory (1404), a CBRS procedure controller (1406) and a communicator (1408). The processor (1402) is configured to execute instructions stored in the memory (1404) and to perform various processes related to the present disclosure. The communicator (1408) is configured for communicating internally between internal hardware components and with external devices via one or more networks. The memory (1404) is configured to store instructions to be executed by the processor (1402).
[0096] The CBRS procedure controller (1406) enables the exchange of the message(s) between the O-RU (310) and one of the SAS (304) and the DP (308). Further, the CBRS procedure controller (1406) translates the message(s) to the predefined format, wherein the predefined format is the XML (Extensible Markup Language) format and is understood by the O-RU (310) through the Open Fronthaul M-Plane interface in the O-RAN (302).
[0097] Further, the CBRS procedure controller (1406) establishes communication between the CRM function module (328) and one of the SAS (304) and the DP (308) and facilitates the communication through the Open Fronthaul M-Plane interface between the CRM function module (328) and the O-RU (310), wherein the O-RU (310) acts as a Broadband Radio Service Device (BSD).
[0098] Further, the CBRS procedure controller (1406) adds the parameter and the procedure in an O-RU YANG module, where the parameter and the procedure are required for sending and receiving the message, and wherein the O-RU YANG module is used to store the parameter and procedure. The O-RU YANG module is a data structure that is used to store the set of parameters and procedures which are required for sending and receiving the SAS-CBSD messages between the O-RU (310) and the SAS (304) or the DP (308). The set of parameters for each procedure is defined by a standard body WinnForum.
[0099] FIG. 15 is a flow chart (1500) illustrating a method for managing the CBRS procedure in the O-RAN (302). The CBRS procedure can be the SAS-CBSD procedure. The operation (1502) is performed by the CBRS procedure controller (1406). At step 1502, the method includes enabling the exchange of at least one message (e.g., SAS-CBSD message or the like) between the O-RU (310) and one of the SAS (304) and the DP (308), wherein the SAS (304) allocates channels to the plurality of Citizen Broadband Radio Service Device (CBSDs) (310a-310n), and the DP (308) manages communications with the SAS (304) on behalf of the plurality of CBSDs. The O-RU (310) can be a CBSD from the plurality of CBSDs (310a-310n).
[00100] The method enables the operation of the O-RU (310) in the CBRS shared spectrum (i.e., the method uses the CBRS RAN management (CRM) function module (328) in the O-RAN (302), which translates the messages between the O-RU (310) and one of the SAS (304) or the DP (308) to enable the O-RU (310) to use the CBRS band).
[00101] The various actions, acts, blocks, steps, or the like in the flow chart (1500) may be performed in the order presented, in a different order or simultaneously. Further, in some implementations, some of the actions, acts, blocks, steps, or the like may be omitted, added, modified, skipped, or the like without departing from the scope of the invention.
[00102] The embodiments disclosed herein can be implemented using at least one software program running on at least one hardware device and performing network management functions to control the elements.
[00103] It will be apparent to those skilled in the art that other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention. While the foregoing written description of the invention enables one of ordinary skill to make and use what is considered presently to be the best mode thereof, those of ordinary skill will understand and appreciate the existence of variations, combinations, and equivalents of the specific embodiment, method, and examples herein. The invention should therefore not be limited by the above-described embodiment, method, and examples, but by all embodiments and methods within the scope of the invention. It is intended that the specification and examples be considered as exemplary, with the true scope of the invention being indicated by the claims.
[00104] The methods and processes described herein may have fewer or additional steps or states and the steps or states may be performed in a different order. Not all steps or states need to be reached. The methods and processes described herein may be embodied in, and fully or partially automated via, software code modules executed by one or more general purpose computers. The code modules may be stored in any type of computer-readable medium or other computer storage device. Some or all of the methods may alternatively be embodied in whole or in part in specialized computer hardware.
[00105] The results of the disclosed methods may be stored in any type of computer data repository, such as relational databases and flat file systems that use volatile and/or non-volatile memory (e.g., magnetic disk storage, optical storage, EEPROM and/or solid-state RAM).
[00106] The various illustrative logical blocks, modules, routines, and algorithm steps described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. The described functionality can be implemented in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the disclosure.
[00107] Moreover, the various illustrative logical blocks and modules described in connection with the embodiments disclosed herein can be implemented or performed by a machine, such as a general purpose processor device, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components or any combination thereof designed to perform the functions described herein. A general-purpose processor device can be a microprocessor, but in the alternative, the processor device can be a controller, microcontroller, or state machine, combinations of the same, or the like. A processor device can include electrical circuitry configured to process computer-executable instructions. In another embodiment, a processor device includes an FPGA or other programmable device that performs logic operations without processing computer-executable instructions. A processor device can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Although described herein primarily with respect to digital technology, a processor device may also include primarily analog components. A computing environment can include any type of computer system, including, but not limited to, a computer system based on a microprocessor, a mainframe computer, a digital signal processor, a portable computing device, a device controller, or a computational engine within an appliance, to name a few.
[00108] The elements of a method, process, routine, or algorithm described in connection with the embodiments disclosed herein can be embodied directly in hardware, in a software module executed by a processor device, or in a combination of the two. A software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of a non-transitory computer-readable storage medium. An exemplary storage medium can be coupled to the processor device such that the processor device can read information from, and write information to, the storage medium. In the alternative, the storage medium can be integral to the processor device. The processor device and the storage medium can reside in an ASIC. The ASIC can reside in a user terminal. In the alternative, the processor device and the storage medium can reside as discrete components in a user terminal.
[00109] Conditional language used herein, such as, among others, "can," "may," "might," "may," “e.g.,” and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain alternatives include, while other alternatives do not include, certain features, elements and/or steps. Thus, such conditional language is not generally intended to imply that features, elements and/or steps are in any way required for one or more alternatives or that one or more alternatives necessarily include logic for deciding, with or without other input or prompting, whether these features, elements and/or steps are included or are to be performed in any particular alternative. The terms “comprising,” “including,” “having,” and the like are synonymous and are used inclusively, in an open-ended fashion, and do not exclude additional elements, features, acts, operations, and so forth. Also, the term “or” is used in its inclusive sense (and not in its exclusive sense) so that when used, for example, to connect a list of elements, the term “or” means one, some, or all of the elements in the list.
[00110] Disjunctive language such as the phrase “at least one of X, Y, Z,” unless specifically stated otherwise, is otherwise understood with the context as used in general to present that an item, term, etc., may be either X, Y, or Z, or any combination thereof (e.g., X, Y, and/or Z). Thus, such disjunctive language is not generally intended to, and should not, imply that certain alternatives require at least one of X, at least one of Y, or at least one of Z to each be present.
[00111] While the detailed description has shown, described, and pointed out novel features as applied to various alternatives, it can be understood that various omissions, substitutions, and changes in the form and details of the devices or algorithms illustrated can be made without departing from the scope of the disclosure. As can be recognized, certain alternatives described herein can be embodied within a form that does not provide all of the features and benefits set forth herein, as some features can be used or practiced separately from others.
, Claims:CLAIMS

We Claim:
1. A method for managing a Citizens Broadband Radio Service (CBRS) procedure in an Open-Radio Access Network (O-RAN) (302), wherein the O-RAN (302) comprises at least one Open-Radio Unit (O-RU) (310), and a plurality of network modules wherein the method comprises:
enabling an exchange of at least one message between the O-RU (310) and one of a Spectrum Access System (SAS) (304) and/or a Domain Proxy (DP) (308), wherein the SAS (304) allocates channels to a plurality of Citizen Broadband Radio Service Device (CBSDs) (310a-310n), and the DP (308) manages communications with the SAS (304) on behalf of the plurality of CBSDs (310a-310n).

2. The method as claimed in claim 1, wherein the plurality of network modules comprises a Service Management and Orchestration (SMO) module (312), an Operation and Maintenance (OAM) function module (330), a Network Management System (NMS) (332), and an Open-Distributed Unit (O-DU) (320).

3. The method as claimed in claim 1, wherein the CBRS procedure comprises a SAS-CBSD procedure, wherein at least one message comprises a SAS-CBSD message, wherein the O-RU (310) is a CBSD from the plurality of CBSDs (310a-310n).

4. The method as claimed in claim 1, wherein exchange of at least one message is enabled by a CBRS RAN Management (CRM) function module (328), wherein the CRM function module (328) acts as an interface between the O-RU (310) and one of the SAS (304) and the DP (308).

5. The method as claimed in claim 1, wherein the method comprises facilitating the exchange of at least one message between the O-RU (310) and one of the SAS (304) and the DP (308) over an Open Fronthaul M-Plane interface in a hybrid topology, wherein exchange of the at least one message is facilitated by a CRM function module (328) in the SMO module (312).

6. The method as claimed in claim 1, wherein the method comprises facilitating the exchange of at least one message between the O-RU (310) and one of the SAS (304) and the DP (308) through the O-DU (320) in a hierarchical topology, wherein the at least one message is sent over an O1 interface from the SMO module (312) to the O-DU (320) and then sent over an Open Fronthaul M-Plane interface from the O-DU (320) to the O-RU (310), wherein exchange of the at least one message is facilitated by a CRM function module (328) in the SMO module (312).

7. The method as claimed in claim 1, wherein the method comprises facilitating the exchange of at least one message between the O-RU (310) and one of the SAS (304) and the DP (308) over an Open Fronthaul M-Plane interface in a hybrid topology, wherein exchange of the at least one message is facilitated by a CRM function module (328) in the OAM function module (330).

8. The method as claimed in claim 1, wherein the method comprises facilitating the exchange of at least one message between the O-RU (310) and one of the SAS (304) and the DP (308) through the O-DU (320) in a hierarchical topology, wherein the at least one message is sent over an O1 interface from the OAM function module (330) to the O-DU (320) and then sent over an Open Fronthaul M-Plane interface from the O-DU (320) to the O-RU (310), wherein exchange of the at least one message is facilitated by a CRM function module (328) in the OAM function module (330).

9. The method as claimed in claim 1, wherein the method comprises facilitating the exchange of at least one message between the O-RU (310) and one of the SAS (304) and the DP (308) over an Open Fronthaul M-Plane interface in a hybrid topology, wherein exchange of the at least one message is facilitated by a CRM function module (328) in the SMO module (312) and the CRM function module (328) interacts with the OAM function module (330) via an internal interface.

10. The method as claimed in claim 1, wherein the method comprises facilitating the exchange of at least one message between the O-RU (310) and one of the SAS (304) and the DP (308) through the O-DU (320) in a hierarchical topology, wherein the at least one message is sent over an O1 interface from the SMO module (312) to the O-DU (320) and then sent over an Open Fronthaul M-Plane interface from the O-DU (320) to the O-RU (310), wherein exchange of the at least one message is facilitated by a CRM function module (328) in the SMO module (312) and the CRM function module (328) interacts with the OAM function module (330) via an internal interface.

11. The method as claimed in claim 1, wherein the method comprises facilitating the exchange of at least one message between the O-RU (310) and one of the SAS (304) and the DP (308) over a Netconf protocol-based interface in a hybrid topology, wherein exchange of the at least one message is facilitated by a CRM function module (328) in the NMS (332).

12. The method as claimed in claim 1, wherein the method comprises facilitating the exchange of at least one message between the O-RU (310) and one of the SAS (304) and the DP (308) through the O-DU (320) in a hierarchical topology, wherein the at least one message is sent over a Netconf protocol-based interface from the NMS (332) to the O-DU (320) and then sent over an Open Fronthaul M-Plane interface from the O-DU (320) to the O-RU (310), wherein exchange of the at least one message is facilitated by a CRM function module (328) in the NMS (332).

13. The method as claimed in claim 1, wherein the method comprises facilitating the exchange of at least one message between the O-RU (310) and one of the SAS (304) and the DP (308), wherein at least one message is sent over an O1 interface from the OAM function module (330) to the O-DU (320) and then sent over an Open Fronthaul M-Plane interface from the O-DU (320) to the O-RU (310), wherein exchange of the at least one message is facilitated by a CRM function module (328) in the O-DU (320).

14. The method as claimed in claim 1, wherein the method comprises translating at least one message to a predefined format, wherein the predefined format is an XML format (Extensible Markup Language) and is understood by the O-RU (310) through an Open Fronthaul M-Plane interface in the O-RAN (302).

15. The method as claimed in claim 1, wherein the method comprises:
establishing communication between a CRM function module (328) and one of the SAS (304) and the DP (308); and
facilitating the communication through an Open Fronthaul M-Plane interface between the CRM function module (328) and the O-RU (310), wherein the O-RU (310) acts as a Broadband Radio Service Device (BSD).

16. The method as claimed in claim 1, wherein the method comprises adding at least one parameter and at least one procedure in an O-RU YANG module, wherein at least one parameter and the at least one procedure are required for sending and receiving at least one message, and wherein the O-RU YANG module is used to store the at least one parameter and the at least one procedure.

17. The method as claimed in claim 15, wherein at least one procedure required for sending and receiving at least one message comprises at least one of a CBSD registration procedure, a spectrum inquiry procedure, a grant procedure, a CBSD heartbeat procedure, a CBSD grant relinquishment procedure, and a CBSD deregistration procedure.

18. The method as claimed in claim 1, wherein at least one message comprises a message related to at least one of a CBSD registration procedure, a spectrum inquiry procedure, a grant procedure, a CBSD heartbeat procedure, a CBSD grant relinquishment procedure, and a CBSD deregistration procedure message.

19. An Open-Radio Access Network (O-RAN) (302), comprising:
an Open-Radio Unit (O-RU) (310) and a plurality of network modules, wherein each network module (1400) from the plurality of network modules comprises:
a processor (1402);
a memory (1404); and
a CBRS procedure controller (1406), coupled with the processor (1402) and the memory (1404), configured to:
enable an exchange of at least one message between the O-RU (310) and one of a Spectrum Access System (SAS) (304) and/or a Domain Proxy (DP) (308), wherein the SAS (304) allocates channels to a plurality of Citizen Broadband Radio Service Device (CBSDs) (310a-310n), and the DP (308) manages communications with the SAS (304) on behalf of the plurality of CBSDs (310a-310n).

20. The O-RAN (302) as claimed in claim 18, wherein the plurality of network modules comprises a Service Management and Orchestration (SMO) module (312), an Operation and Maintenance (OAM) function module (330), a Network Management System (NMS) (332), and an Open-Distributed Unit (O-DU) (320).