Multi tenancy support in radio access network service management and orchestration

Abstract

Described are systems, apparatuses and methods for Mobile Network Operators (MNO) to deploy Radio Access Network sharing solutions that require Service Management and Orchestration (SMO) per MNO. SMO with Multi-Tenancy support provides a mechanism so that each MNO can individually manage their non-shared resources and provide data confidentiality and easy arbitration of shared resources.

Description

MULTI TENANCY SUPPORT IN RADIO ACCESS NETWORK SERVICE MANAGEMENT AND ORCHESTRATIONDESCRIPTION OF THE RELATED TECHNOLOGY a. Field of the Disclosure

[0001] The present disclosure relates to systems and methods for radio access networks. The present disclosure is related to the design, operation, administration and management of various network elements of 4G, 5G, and further generations of a radio access network system. a. Related Technology

[0002] This disclosure describes 0AM (operation, administration and management) functions in the ORAN - SMO. The SMO entity enables an operator to engage in activities to manage radio access network components, such as provide configuration, observe and react to faults, monitor KPIs, perform audits, and so on.

[0003] The current definition of an SMO allows a single operator to use the services of a SMO. Conventionally, each operator typically manages a RAN network through an SMO since the operator owns all the resources including the infrastructure spread across geographical sites, as well as all the RAN components like O-CU, 0-DU and 0-RU. SMO is also owned by the operator and is used for all the management and operational needs of the operator. Accordingly, the SMO caters to a single operator’s requirements.

[0004] RAN is introducing sharing mechanisms like:• MORAN - where multiple RAN components like O-CU, 0-DU can be shared across multiple Mobile Network Operators (MNOs).• Shared-RU - where the 0-RU can be shared across multiple MNOs.• Network Host operator - NH0 owns the complete infrastructure and provide the resources as required to multiple MNOs to host their services.For such RAN sharing, the single deployment of SMO does not allow multiple MNOs to manage the shared and non-shared resources. Thus, the present disclosure identifies a need for multiple operators to manage a shared RAN network, where certain RAN resources are shared across operators, by using the services of a single SMO.SUMMARY OF THE DISCLOSURE

[0005] Described are implementations of a computer system, computer system components, computer apparatus, a method, and computer program products configured to execute program instructions for the method for radio access network, and operation, administration and management of various network elements of 4G, 5G, and further generations of the radio access network system. The method is performed by a computer system that comprises one or more processors and a computer-readable storage medium encoded with instructions executable by at least one of the processors and operatively coupled to at least one of the processors.

[0006] The present disclosure identifies and addresses the need for multiple operators to manage a shared RAN network (where certain RAN resources are shared across operators) by using the services of a single SMO.

[0007] In an implementation, an apparatus for RAN comprises a Multi-Tenant SMO (SMO-MT) configured to manage 0AM functionality for plurality of tenants, wherein the SMO-MT is configured to offer shared 0AM resources while keeping data for each tenant separate. The SMO-MT can be configured for a Network Host Operator (NH0) tenant to host a plurality of Mobile Network Operator (MN0) tenants The SMO-MT can be configured to allow the NHO tenant to perform one or more of: configure an O-Cloud and create a number of clusters over an 02 interface for IMS (Infrastructure Management Services); perform 0AM of the O-Cloud over the 02 interface IMS; configure and manage 0-RU resources of shared O-Radio Unit (0-RU) over an Open FH M-plane; and / or partition the shared 0-RU resourcesacross the plurality of MNO tenants using a resource partitioning Non-RT RIC Application (rApp). The SMO-MT can be configured to allow one or more of the MNO tenants to: instantiate an MNO specific network function (NF) on an O-Cloud cluster created by an NHO tenant user and perform lifecycle management (LCM) functions for MNO specific NFs over an 02 interface for Deployment Management Services (DMS); perform Fault, Configuration, Accounting, Performance, Security (FCAPS) functions for the MNO specific NFs and, for a shared O-Radio Unit (O-RU), user plane configuration of allocated shared O-RU resources for an 0 Distributed Unit (O-DU) over an 01 interface; perform RIC optimizations for the MNO specific NFs over an E2 interface; and configure, by an MNO specific O-DU, the shared O-RU with partitioned resources for the MNO. The SMO-MT can be configured to create and authenticate a plurality of users for each MNO tenant. The SMO-MT can include a database comprising a database object per MNO tenant, and the SMO-MT is configured to allow an MNO tenant of the plurality of MNO tenants to access only their database object, and the SMO-MT is configured so that the MNO tenant cannot access another database object of another MNO tenant. The SMO-MT can be configured to trigger tenant database access with tenant nodes. The SMO-MT can be configured for SMO / Network Management Systems (NMS) that serve multiple- Radio Access Technology (RAT) deployments for multiple MNO tenants. The SMO- MT can comprise an authentication module configured to authenticate each of the plurality of tenants. The SMO-MT can be configured to support SMO redundancy and resiliency.

[0008] In an implementation disclosed is a method comprising the apparatus above and configured to execute the SMO-MT functions above. In an implementation disclosed is a method and a computer program product comprising program instructions configured to execute the SMO-MT functions above when run by a processor.

[0009] The SMO-MT advantageously provides modules and tools for managing 0AM functionality for multiple MNOs. The SMO-MT also providesmodules and tools for managing OAM functionality for multiple MNOs for shared resources and also non-shared resources. The SMO-MT also provides modules and tools for supporting NHO deployments. The SMO-MT also provides modules and tools for arbitrating access for shared resources across MNOs. The SMO-MT is configured for all SMO / NMS that serve multiple-RAT deployments for multiple MNO. The SMO-MT ensures and provides mechanism for data isolation across all MNOs / Operators The SMO-MT also provides separate or dedicated authentication mechanisms for each of the tenants / MNO. All Redundancy and Resiliency supported by SMO are applicable to SMO-MT as well.

[0010] Exemplary advantages of the implementations as described herein include benefits from a single instance of the SMO that provides multi-tenancy - support for multiple tenants or operators to manage their individual resources. Each MNO can use the same SMO to, for example:• manage their own non-shared resources;• either manage or observe shared-resources;• retrieve faults and KPIs for the shared resources; and• independently own and manage the data of their own network.BRIEF DESCRIPTION OF THE DRAWINGS

[0011] FIG. 1 is a block diagram of a system architecture.

[0012] FIG. 2 shows an example of a User Plane Stack.

[0013] FIG. 3 shows an example of a Control Plane Stack.

[0014] FIG. 4A shows an example of high-level NG-RAN including a gNB CU and DU.

[0015] FIG. 4B shows an example of a Separation of CU-CP (CU-Control Plane] and CU-UP (CU-User Plane) in a 5G gNB.

[0016] FIG. 4C shows an example of a Separation of CU-CP (CU-Control Plane) and CU-UP (CU-User Plane) in a 4G ng-eNB.

[0017] FIG. 5A is an EN-DC architecture.

[0018] FIG. 5B is a NG-RAN architecture.

[0019] FIG. 6A shows an example of an 0-RAN architecture.

[0020] FIG. 6B shows an example of an 0-RAN 0AM architecture.

[0021] FIG. 7 illustrates a logical flow and architecture for an SM0-MT.

[0022] FIG. 8 illustrates RAN sharing when SM0 is deployed as MT.

[0023] FIG. 9 illustrates an architecture and flow for an SMO-MT.

[0024] FIG. 10 illustrates a flow for SMO-MT tenant DB object separation and access.DETAILED DESCRIPTION OF THE DISCLOSURE

[0025] Reference is made to Third Generation Partnership Project (3GPP) and the Internet Engineering Task Force (IETF) and related standards bodies in accordance with embodiments of the present disclosure. The present disclosure employs abbreviations, terms and technology defined in accord with Third Generation Partnership Project (3GPP) and / or Internet Engineering Task Force (IETF) technology standards and papers, including the following standards and definitions. 3GPP and IETF technical specifications (TS), standards (including proposed standards), technical reports (TR) and other papers are incorporated by reference in their entirety hereby, define the related terms and architecture reference models that follow.

[0026] 0-RAN.WG4.MP.0-R003-vl3.00

[0027] 3GPP TS 23.203 V 17.2.0 2021-12-23

[0028] 3GPP TS 23.501 V 18.1.0 2023-04-05

[0029] 3GPP TS 38.300 V 17.4.0 03-28-2023

[0030] 3GPP TS 36.321 V 17.4.0 2023-03-29

[0031] 3GPP TS 36.323 V 17.2.0 2023-01-13

[0032] 3GPP TS 38.321 V 17.4.0 2023-03-29

[0033] 3GPP TS 38.401 V 17.4.0 2023-04-03

[0034] 3GPP TS 38.425 17.3.0, 2023-04-03

[0035] Acronyms3GPP: Third generation partnership project5GC: 5G Core Network5G NR: 5G New Radio5QI: 5G QoS IdentifierAAL: Accelerator Abstraction LayerACK: AcknowledgementACER: Gain and Adjacent Channel Leakage RatioADC: Analog-to-Digital ConverterAM: Acknowledged ModeAMF: Access Mobility FunctionAMBR: Aggregate Maximum Bit RateAPN: Access Point NameARP: Allocation and Retention PriorityASIC: Application Specific Integrated CircuitAWGN: Additive White Gaussian NoiseBFW: Beamforming weightBS: Base StationCNF: Cloud-Native Network FunctionCM: Configuration ManagementCP: Control PlaneCPU: Central Processing UnitC-RAN: cloud radio access networkCU: Centralized unitCU-CP: Centralized Unit - Control PlaneCU-UP: Centralized Unit - User PlaneCQI: Channel Quality IndicatorDAC: Digital-to-Analog ConverterDC: Dual ConnectivityDCI: Downlink Control InformationDDDS: DL Data Delivery StatusDFE: Digital Front EndDL: DownlinkDMRS: Demodulation Reference SignalDMS: O-Cloud Deployment Management ServicesDNN: Data Network NameDRB: Data Radio BearerDU: Distributed unit eNB: evolved Node B eMBB: Enhanced Mobile BroadbandEPC: Evolved Packet CoreEN-DCEP: Endpoint PodE-UTRAN: Evolved Universal Terrestrial Radio Access NetworkE-RAB: E-UTRAN Radio Access BearerFCAPS: Fault, Configuration, Accounting, Performance, SecurityFM: Fault ManagementFOCOM: Federated O-Cloud Orchestration and ManagementIMS: O-Cloud Infrastructure Management Services loT: Internet of ThingsIP: Internet ProtocolIWF: Interworking FunctionGBR: Guaranteed Bit Rate gNB: gNodeB (5G base station)GTP-U: General Packet Radio Service (GPRS) Tunnelling Protocol - User PlaneGW: GatewayHA: High AvailabilityKPI: Key Performance IndicatorLI: Layer 1L2: Layer 2L3: Layer 3LC: Logical ChannelLCM: Lifecycle ManagementLTE: Long Term Evolution (4G)MAC: Medium Access ControlMIMO: multiple-in multiple-outMME: Mobility Management EntityMNO: Mobile Network OperatorMR-DC: Multi-Radio Dual ConnectivityM-plane: Management plane interface between SMO and O-RUNACK: Negative AcknowledgementNAS: Non-Access StratumNB: NarrowbandNE: Network ElementNear-RT RIC: Near-Real-Time R1CNF: Network FunctionNFO: Network Function Orchestration ng: Next GenerationNHO: Network Host OperatorNIC: Network Interface CardNMS: Network Management SystemNR: New RadioNR-U: New Radio - User PlaneNSA: Non-Standalone ArchitectureOAM: operation, administration, and managementOne-CU-UP: One 0-RAN compliant Centralized Unit User PlaneOFDM: orthogonal frequency-division multiplexingOpen FH M-Plane: Open Fronthaul Management-Plane0-RAN: Open Radio Access NetworkPA: Power AmplifierPDB: Packet Delay BudgetPDCP : Packet Data Convergence ProtocolPDU: Protocol Data UnitPDCCH: Physical Downlink Control ChannelPDSCH: Physical Downlink Shared ChannelPHY: Physical LayerPM: Performance ManagementPNF: Physical Network FunctionPRB: Physical Resource BlockPRG: Physical Resource Block GroupPUCCH: Physical Uplink Control ChannelPUSCH: Physical Uplink Shared ChannelQCI: QoS Class IdentifierQFI: QoS Flow IdQFI: QoS Flow IdentifierQoS: Quality of ServiceRAN: Radio Access Network rApp: Non-RT RIC ApplicationRAT: Radio Access TechnologyRB: Resource BlockRDI: Reflective QoS Flow to DRB IndicationRF: Radio FrequencyRIC: RAN Intelligent ControllerRLC: Radio Link ControlRLC-AM: RLC Acknowledged ModeRLC-UM: RLC Unacknowledged ModeRMM: Radio resource managementRQI: Reflective QoS IndicationRRC: Radio Resource ControlRU: Radio UnitSA: Standalone ArchitectureSCTP: Stream Control Transmission ProtocolSDAP: Service Data Adaptation ProtocolSDU: Service Data UnitS-GW: Serving GatewaySINR: Signal-to- Interference and Noise RatioSMO: Service Management and OrchestrationSMO-MT: Service Management and Orchestration Multi-TenancySN: Secondary NodeSR: Scheduling RequestSRS: Sounding Reference SignalTCP: Transmission Control ProtocolTE&IV: Topology Exposure and Inventory managementTEID: Tunnel Endpoint IdentifierU-plane: User planeUPF: User Plane FunctionUE: user equipmentUL: uplinkUM: Unacknowledged ModeURLLC: Ultra Reliance Low Latency Communication

[0002] Definitions:

[0003] 01: Interface between SMO framework and O-RAN managed elements, for operation and management, by which FCAPS management, PNF (Physical Network Function) software management, file management are achieved.

[0004] 02: Interface between SMO framework and the O-Cloud for supporting O-RAN virtual network functions.

[0005] Al: Al is the interface between the Non-RT RIC function in SMO and the Near-RT RIC function.

[0006] Described are implementations of technology for a cloud-based RadioAccess Networks (RAN), where a significant portion of the RAN layer processing is performed at a central unit (CU) and a distributed unit (DU). Both CUs and DUs are also known as the baseband units (BBUs). CUs are usually located in the cloud on commercial off the shelf servers, while DUs can be distributed. The RF and real-time critical functions can be processed in the remote radio unit (RU).

[0007] RAN Architectures

[0008] FIG. 1 is a block diagram of a system 100 for implementations as described herein. System 100 includes a NR UE 101, a NR gNB 106. The NR UE and NR gNB 106 are communicatively coupled via a Uu interface 120.

[0009] NR UE 101 includes electronic circuitry, namely circuitry 102, that performs operations on behalf of NR UE 101 to execute methods described herein. Circuity 102 can be implemented with any or all of (a) discrete electronic components, (b) firmware, and (c) a programmable circuit 102A.

[0010] NR gNB 106 includes electronic circuitry, namely circuitry 107, that performs operations on behalf of NR gNB 106 to execute methods described herein. Circuity 107 can be implemented with any or all of [a] discrete electronic components, (b) firmware, and (c) a programmable circuit 107A.

[0011] Programmable circuit 107A, which is an implementation of circuitry 107, includes a processor 108 and a memory 109. Processor 108 is an electronic device configured of logic circuitry that responds to and executes instructions. Memory 109 is a tangible, non-transitory, computer-readable storage device encoded with a computer program. In this regard, memory 109 stores data and instructions, i.e., program code, that are readable and executable by processor 108 for controlling operations of processor 108. Memory 109 can be implemented in a random-access memory (RAM), a hard drive, a read only memory (ROM), or a combination thereof. One of the components of memory 109 is a program module, namely module 110. Module 110 includes instructions for controlling processor 108 to execute operations described herein on behalf of NR gNB 106.

[0012] The term "module" is used herein to denote a functional operation that can be embodied either as a stand-alone component or as an integrated configuration of a plurality of subordinate components. Thus, each of module 105 and 110 can be implemented as a single module or as a plurality of modules that operate in cooperation with one another.

[0013] While modules 110 are indicated as being already loaded into memories 109, each module 110 can be configured on a storage device 130 for subsequent loading into their memories 109. Storage device 130 is a tangible, non- transitory, computer-readable storage device that stores module 110 thereon.Examples of storage device 130 include (a) a compact disk, (b) a magnetic tape, (c) a read only memory, (d) an optical storage medium, (e) a hard drive, (f) a memory unit comprising of multiple parallel hard drives, (g) a universal serial bus (USB) flash drive, (h) a random-access memory, and (i) an electronic storage device coupled to NR gNB 106 via a data communications network.

[0014] Uu Interface (120) is the radio link between the NR UE and NR gNB, which is compliant to the 5G NR specification.

[0015] UEs 101 can be dispersed throughout a wireless communication network, and each UE can be stationary or mobile. A UE includes: an access terminal, a terminal, a mobile station, a subscriber unit, a station, and the like. A UE can also include be a cellular phone (e.g., a smart phone), a personal digital assistant (PDA), a wireless modem, a wireless communication device, a handheld device, a laptop computer, a cordless phone, a wireless local loop (WLL) station, a tablet, a camera, a gaming device, a drone, a robot / robotic device, a netbook, a smartbook, an ultrabook, a medical device, medical equipment, a healthcare device, a biometric sensor / device, a wearable device such as a smart watch, smart clothing, smart glasses, a smart wristband, and / or smart jewelry (e.g., a smart ring, a smart bracelet, and the like), an entertainment device (e.g., a music device, a video device, a satellite radio, and the like), industrial manufacturing equipment, a global positioning system (GPS) device, or any other suitable device configured to communicate via a wireless or wired medium. UEs can include UEs considered as machine-type communication (MTC) UEs or enhanced / evolved MTC (eMTC) UEs. MTC / eMTC UEs that can be implemented as loT UEs. loT UEs include, for example, robots / robotic devices, drones, remote devices, sensors, meters, monitors, cameras, location tags, and the like, that can communicate with a BS, another device (e.g., remote device), or some other entity. A wireless node can provide, for example, connectivity for or to a network (e.g., a wide area network such as Internet or a cellular network) via a wired or wireless communication link.

[0016] One or more UEs 101 in the wireless communication network can be a narrowband bandwidth UE. As used herein, devices with limited communication resources, e.g. smaller bandwidth, are considered as narrowband UEs. Similarly, legacy devices, such as legacy and / or advanced UEs, can be considered as wideband UEs. Wideband UEs are generally understood as devices that use greater amounts of bandwidth than narrowband UEs.

[0017] The UEs 101 are configured to connect, for example, communicatively couple, with an or RAN. In embodiments, the RAN can be an NG RAN or a 5G RAN, an E-UTRAN, an MF RAN, or a legacy RAN, such as a UTRAN or GERAN. The term "NG RAN” or the like refers to a RAN 110 that operates in an NR or 5G system, the term "E-UTRAN” or the like refers to a RAN that operates in an LTE or 4G system, and the term "MF RAN” or the like refers to a RAN that operates in an MF system 100. The UEs 101 utilize connections (or channels), respectively, each of which comprises a physical communications interface or layer. The connections and can comprise several different physical DL channels and several different physical UL channels. As examples, the physical DL channels include the PDSCH, PMCH, PDCCH, EPDCCH, MPDCCH, R-PDCCH, SPDCCH, PBCH, PCFICH, PHICH, NPBCH, NPDCCH, NPDSCH, and / or any other physical DL channels mentioned herein. As examples, the physical UL channels include the PRACH, PUSCH, PUCCH, SPUCCH, NPRACH, NPUSCH, and / or any other physical UL channels mentioned herein.

[0018] The RAN can include one or more AN nodes or RAN nodes. These access nodes can be referred to as BS, gNBs, RAN nodes, eNBs, NodeBs, RSUs, MF- APs, TRxPs or TRPs, and so forth, and comprise ground stations (e.g., terrestrial access points) or satellite stations providing coverage within a geographic area (e.g., a cell). The term "NG RAN node" or the like refers to a RAN node that operates in an NR or 5G system (e.g., a gNB), and the term "E-UTRAN node” or the like refers to a RAN node that operates in an LTE or 4G system (e.g., an eNB). According to various embodiments, the RAN nodes can be implemented as one or more of a dedicated physical device such as a macrocell base station, and / or a low power base station for providing femtocells, picocells or other like cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells.

[0019] In some embodiments, all or parts of the RAN nodes can be implemented as one or more software entities running on server computers as part of a virtual network, which can be referred to as a CRAN and / or a vBBU. In these embodiments, the CRAN or vBBU can implement a RAN function split, such as aPDCP split where RRC and PDCP layers are operated by the CRAN / vBBU and other L2 protocol entities are operated by individual RAN nodes; a MAC / PHY split where RRC, PDCP, RLC, and MAC layers are operated by the CRAN / vBBU and the PHY layer is operated by individual RAN nodes; or a "lower PHY” split where RRC, PDCP, RLC, MAC layers and upper portions of the PHY layer are operated by the CRAN / vBBU and lower portions of the PHY layer are operated by individual RAN nodes. This virtualized framework allows the freed-up processor cores of the RAN nodes to perform other virtualized applications. In some implementations, an individual RAN node can represent individual gNB-DUs that are connected to a gNB-CU 151via individual Fl interfaces. In these implementations, the gNB-DUs can include one or more remote radio heads (RRH), and the gNB-CU 151 can be operated by a server that is located in the RAN or by a server pool in a similar manner as theCRAN / vBBU. One or more of the RAN nodes can be next generation eNBs (ng-eNBs), which are RAN nodes that provide E-UTRA user plane and control plane protocol terminations toward the UEs 101, and are connected to a 5GC via a NG interface. In MF implementations, the MF-APs are entities that provide MultiFire radio services, and can be similar to eNBs in an 3GPP architecture.

[0020] In some implementations, access to a wireless interface can be scheduled, where a scheduling entity (e.g.: BS, gNB, and the like] allocates bandwidth resources for devices and equipment in its service area or cell. As scheduling entity can be configured to schedule, assign, reconfigure, and release resources for one or more subordinate entities. In some examples, a UE 101 (or other device) can function as master node scheduling entity, scheduling resources for one or more secondary node subordinate entities (e.g., one or more other UEs 101). Thus, in a wireless communication network with a scheduled access to time — frequency resources and having a cellular configuration, a P2P configuration, and a mesh configuration, a scheduling entity and one or more subordinate entities can communicate utilizing the scheduled resources.

[0021] BS or gNB 106 can be equipped with T antennas and UE 101 can be equipped with R antennas, where in general T>1 and R>1. At BS, a transmit processor is configured to receive data from a data source for one or more UEs 101 and select one or more modulation and coding schemes (MCS) for each UE based on channel quality indicators (CQIs) received from the UE 101. The BS is configured to process (e.g., encode and modulate) the data for each UE 101 based on the MCS(s) selected for the UE 101, and provide data symbols for all UEs. A transmit processor is also configured to process system information (e.g., for static resource partitioning information (SRPI), and the like) and control information (e.g., CQI requests, grants, upper layer signaling, and the like) and can provide overhead symbols and control symbols. Processor 108 can also generate reference symbols for reference signals (e.g., the cell-specific reference signal (CRS)) and synchronization signals (e.g., the primary synchronization signal (PSS) and the secondary synchronization signal (SSS)). A transmit (TX) multiple-input multipleoutput (MIMO) processor can be configured perform spatial processing (e.g., preceding) on the data symbols, the control symbols, the overhead symbols, and / or the reference symbols, if applicable, and can be configured to provide T output symbol streams to T modulators (MODs). Each modulator can be configured to process a respective output symbol stream (e.g., for OFDM, and the like) to obtain an output sample stream. Each modulator can further be configured to process (e.g., convert to analog, amplify, filter, and upconvert) the output sample stream to obtain a downlink signal. T downlink signals from modulators can be transmitted via T antennas.

[0022] An overview of 5G NR Stacks is as follows. 5G NR (New Radio) user and control plane functions with monolithic gNB 106 are shown in FIG. 2 and FIG. 3. For the user plane, PHY (physical), MAC (Medium Access Control), RLC (Radio Link Control), PDCP (Packet Data Convergence Protocol) and SDAP (Service Data Adaptation Protocol) sublayers are terminated in the gNB 106 on the network side. For the control plane, RRC (Radio Resource Control), PDCP, RLC, MAC and PHY sublayers are terminated in the gNB 106 on the network side and NAS (Non-AccessStratum) is terminated in the AMF (Access Mobility Function) on the network side. FIG. 2 shows an example of a User Plane Stack as descried in 3GPP TS 38.300. FIG. 3 shows an example of a Control Plane Stack as described in 3GPP TS 38.300.

[0023] An NG-RAN (NG-Radio Access Network) architecture from 3GPP TS 38.401 is described below. Fl is the interface between gNB-CU 151 (gNB - Centralized Unit) and gNB-DU 152 (gNB - Distributed Unit), NG is the interface between gNB-CU 151 (or gNB) and 5GC (5G Core), El is the interface between CU- CP (CU-Control Plane) and CU-UP (CU-User Plane), and Xn is interface between gNBs.

[0024] A gNB 106 can comprise a gNB-CU-CP, multiple gNB-CU-UPs and multiple gNB-DUs. The gNB-CU-CP is connected to the gNB-DU 152 through the Fl- C interface and to the gNB-CU-UP through the El interface. The gNB-CU-UP is connected to the gNB-DU 152 through the Fl-U interface and to the gNB-CU-CP through the El interface. One gNB-DU 152 is connected to one gNB-CU-CP and one gNB-CU-UP is connected to one gNB-CU-CP. FIG. 4A shows an example of an NG-RAN Architecture as described in 3GPP TS 38.401. FIG. 4B shows an example of a Separation of CU-CP (CU-Control Plane) and CU-UP (CU-User Plane) as described in 3GPP TS 38.401.

[0025] A Layer 2 (L2) of 5G NR is split into the following sublayers is described in 3GPP TS 38.300): o Medium Access Control (MAC): The MAC sublayer offers Logical Channels (LCs) to the RLC sublayer. This layer runs a MAC scheduler to schedule radio resources across different LCs (and their associated radio bearers). o Radio Link Control (RLC): The RLC sublayer offers RLC channels to the PDCP sublayer. The RLC sublayer supports three transmission modes: RLC-Transparent Mode (RLC-TM), RLC-Unacknowledged Mode (RLC-UM) and RLC-Acknowledgement Mode (RLC-AM). RLCconfiguration is per logical channel. It hosts ARQ (Automatic Repeat Request) protocol for RLC-AM mode. o Packet Data Convergence Protocol (PDCP): The PDCP sublayer offers Radio Bearers (RBs) to the SDAP sublayer. There are two types of Radio Bearers: Data Radio Bearers (DRBs) for data and Signaling Radio Bearers (SRBs) for control plane. o Service Data Adaptation Protocol (SDAP): The SDAP offers QoS Flows to the 5GC (5G Core). This sublayer provides mapping between a QoS flow and a DRB. It marks QoS Flow Id in DL (downlink) as well as UL (uplink packets).

[0026] FIG. 4C shows an example of a Separation of 4G CU-CP (CU-Control Plane) and CU-UP (CU-User Plane). The example shown in FIG. 4B shows ng-eNB but legacy eNB also applies same architecture.

[0027] An E-UTRAN architecture is illustrated in FIG. 5A. The E-UTRAN comprises eNBs, providing the E-UTRAN U-plane (PDCP / RLC / MAC / PHY) and control plane (RRC) protocol terminations towards the UE. The eNBs are interconnected with each other by the X2 interface. The eNBs are also connected by the SI interface to the EPC (Evolved Packet Core), more specifically to the MME (Mobility Management Entity) by the Sl-MME interface and to the Serving Gateway (S-GW) by the Sl-U interface. The SI interface supports a many-to-many relation between MMEs / Serving Gateways and eNBs.

[0028] E-UTRAN also supports MR-DC via E-UTRA-NR Dual Connectivity (EN- DC), in which a UE is connected to one eNB that acts as a MN and one en-gNB 106 that acts as a SN. An EN-DC architecture is illustrated in FIG. 5A. The eNB is connected to the EPC 140 via the SI interface and to the en-gNB 106 via the X2 interface. The en-gNB 106 might also be connected to the EPC 140 via the Sl-U interface and other en-gNBs 106 via the X2-U interface. In EN-DC, an en-gNB 106 comprises gNB-CU 151and gNB-DU(s)152.

[0029] As shown in FIG. 5B, in the NG-RAN architecture, an NG-RAN node is either: a gNB, providing NR user plane and control plane protocol terminations towards the UE; or an ng-eNB, providing E-UTRA user plane and control plane protocol terminations towards the UE. (3GPP TS 38.300 17.3.0.)

[0030] As shown in FIG. 5B, the gNBs 106 and ng-eNBs are interconnected with each other by the Xn interface. The gNBs 106 and ng-eNBs are also connected by the NG interfaces to the 5GC, more specifically to the AMF (Access and Mobility Management Function) by the NG-C interface and to the UPF (User Plane Function) by the NG-U interface.

[0031] The gNB 106 and ng-eNB host functions such as functions for Radio Resource Management: Radio Bearer Control, Radio Admission Control, Connection Mobility Control, Dynamic allocation of resources to UEs in both uplink and downlink (scheduling), connection setup and release; session Management; QoS Flow management and mapping to data radio bearers; and Dual Connectivity.

[0032] In an example, control information (e.g., scheduling information) can be provided for broadcast and / or multicast operation. The UE can monitor different bundle sizes for the control channel depending on the maximum number of repetitions.

[0033] O-RAN, which is based on disaggregated components and connected through open and standardized interfaces, is based on 3GPP NG-RAN. An overview of O-RAN with disaggregated RAN (CU, DU, and RU), near-real-time RIC 155 and non-real-time RIC is shown in the figure below. Here, DU (Distributed Unit) and CU (Centralized Unit) are typically implemented using COTS (Commercial off-the-shelf) hardware.

[0034] FIGS. 6A-6B show an example of an 0-RAN architecture. In FIG. 6A, the CU and the DU are connected using the Fl interface (with Fl-C for control plane and Fl-U for user plane traffic] over the midhaul [MH] path. One DU could host multiple cells (for example, one DU could host 24 cells] and each cell can support many users. For example, one cell can support 600 RRC connected users and out of these 600, there can be 200 Active users (i.e.; users which have data to send at a given point of time].

[0035] A cell site can comprise multiple sectors and each sector can support multiple cells. For example, one site could comprise three sectors and each sector could support 8 cells (with 8 cells in each sector on different frequency bands]. One CU-CP could support multiple DUs and thus multiple cells. For example, a CU-CP could support 1000 cells and around 100,000 UEs. Each UE could support multiple DRBs and there could be multiple instances of CU-UP to serve these DRBs. For example, each UE could support 4 DRBs, and 400,000 DRBs (corresponding to 100,000 UEs] can be served by five CU-UP instances (and one CU-CP instance].

[0036] DU can be located in a private data center or it could be located at a cell-site too. CU can also be located in a private data center or even hosted on a public cloud system. DU and CU can be tens of kilometers away. CU can communicate with 5G core system which could also be hosted in the same public cloud system (or could be hosted by a different cloud provider]. RU (Radio Unit] is located at cell-site and communicated with DU via a fronthaul (FH] interface.

[0037] The E2 nodes (CU and DU] are connected to the near-real-time RIC 155 using the E2 interface. The E2 interface is used to send data (e.g., user, cell, slice KPMs] from the RAN, and deploy control actions and policies to the RAN at near- real-time RIC 155. The application or service at the near-real-time RIC 155 that deploys the control actions and policies to the RAN are called xApps. The near-real- time RIC 155 is connected to the non-real-time RIC 161 using the Al interface.

[0038] SMO 160 manages multiple regional networks, and O-RAN NFs (O-CUs 151, Near-RT RIC 155, O-DUs 152) can be deployed in a regional data center that is connected to multiple cell sites or in cell site which is close to localized 0-RU 153 according to network requirements. Since SMO 160 Functions and O-RAN NFs are micro services and deployment-independent logical functions, SMO 160 Functions and O-RAN NFs can be composed of multiple deployment instances deployed in the same O-Cloud or in a different O-Cloud in regional data center, or in cell site according to network requirements (such as capacity, latency, security, and so on) if the secure connection among SMO160 Functions and O-RAN NFs are available.

[0039] As shown in FIG. 6B, an O-RAN compliant SMO 160 defines TE&IV 163, RAN NF 0AM 164, Non-RT RIC 161, and NFO165, FOCOM services 166. SMO 160 interacts with O-RAN NFs with 01 interface. SMO interacts with O-RU 153 with Open FH M-Plane interface and interacts O-Cloud via the 02 interface. O-RAN NF 0AM 164 manages O-RAN NF CM 173, FM 174 , PM 175 and creates O-RAN NF inventory and topology in TE&IV 163. FOCOM / NFO 166 manages O-Cloud resources and creates O-Cloud resources inventory and topology in TE&IV 163. Analytics 172 and rApp 171 in Non-RT RIC 161 can subscribe O-RAN NFs PM 174 / FM 173, 0- Cloud PM / FM data based on O-RAN NF 0AM 164 and FOCOM 166 / NFO 165.Analytics 172 / rApp 173 in Non-RT RIC 161 can retrieve the O-RAN NF and O-Cloud resource inventory and topology.

[0040] Disclosed are implementation of technology for SMO 160 support for a multi-tenancy (MT) capability.

[0041] Multi Tenancy (MT) software is configured and employed for a single deployment instance of SMO 160 that allows multiple tenants / operators 181 to have access to SMO services. With MT, each service is not duplicated based on the number of tenants 181. Instead, MT processes 01 aspects from multiple tenants 181a, 181b, 181c commonly while ensuring that the data for each MN0 is separated. While various services within the SMO 160 are common for all tenants 181a, 181b, 181c, the data per tenant 180 is separated. FIG. 7 illustrates a logical flow andarchitecture for an MT usage of the SMO 160. As shown in FIG. 7, a single instance of SMO 160 enables authenticated Users of each tenant 181, 181b, 181c , authenticated by a tenant specific authentication service 183, to perform FCAPS operations 185 on tenant specific nodes 184a, 184b, 181c.

[0042] The characteristics of such a SMO-MT 160 include that roles and access are defined - for example, roles for a NHO 182 versus roles for an MNO 181. Also, the SMO-MT 160 ensures data isolation - each tenant's 181 data is accessible only to that tenant 181. From the external interfaces’ point of view, interaction is with a single SMO 160. On interfaces like 01, an identifier for (e.g.: tenant-id) allows the SMO-MT 160 to distinguish which tenant it belongs to. As shown in the example, SMO-MT 160 functions when serving two MNOs 184a, 184b and NHO 184c.

[0043] FIG. 8 shows RAN sharing when SMO 160 is deployed as MT and a NHO tenant 182 is enabling multiple MNO operators 181a, 181b to host their services. In such a deployment.

[0044] NHO (logical instance) 182 of the SMO 160 allows NHO tenant 182 users to perform the following functions:• over O2-IMS, configure the O-Cloud and create the required number of clusters;• over 02-IMS, perform Orchestration and Management of the O- Cloud(s);• over Open FH M-plane, configure and manage the common functionalities of the shared O-RU 153;• using resource partitioning rApp, configured to partition the shared 0- RU 153 resources across multiple MNOs 184a, 184b.

[0045] MNO (logical instances) 184a, 184b of the SMO 160 allows MNO specific tenant users 181a, 181b to perform the following functions:• over O2-DMS, instantiate the required MNO specific NFs like O-CU-CP 151-CP, O-CU-UP 151-UPand O-DU 152 on the O-Cloud Cluster that has been prepared by the NHO tenant users. Note that the 02 DMS endpoint on the O-Cloud is common to all MNOs.• over 02-DMS, perform LCM functions for MNO specific NFs.• over 01, perform FCAPS functions for MNO specific NFs. Specific to shared O-RU 153, the user plane configuration of the allocated shared O-RU 153 resources is also performed towards the MNO specific O-DUs 152.• over E2, perform RIC optimizations for MNO specific NFs.MNO specific O-DUs 152 perform the following function:• over open FH M-Plane, configure the shared O-RU 153 with the partitioned resources for that MNO.

[0046] A note about the host operator: there are scenarios where one of the MNOs 181 can be a "Host Operator". Such an MNO 181 in addition also provides the infrastructure and management of the same to other MNOs 181a, 181b. In a SMO- MT 160 scenario, this is addressed by providing the host operator MNO 181 users with the roles and privileges provided to NHO 182 users.

[0047] Tenant Users

[0048] SM0-MT 160 provides a mechanism to create users per MNO tenant and associate the user with a specific access control group. Each MNO can define different authentication mechanisms for their users - SMO 160 allows the MNO tenant user authentication accordingly.

[0049] Certain access control groups like sudo, sudo-mno, sudo-nho, smo- view, nho-view could be defined with specific access to SMO 160 services.

[0050] For example a user like admin@tenantl.com for a tenant 181a can be mapped to a sudo-mno access control group and will lead to access all SMO services specific to tenantl MNO.

[0051] SM0-MT Design

[0052] SMO 160 includes and maintains multiple tables 186 as part of a database 185 for an 0-RAN solution - this can include inventories, configuration, events (faults and notifications), counters and metrics. With SM0-MT 160, such tables 186 are applicable for every tenant / MNO 184. FIG. 9 illustrates an architecture and flow for SM0-MT - DB Handling. SM0-MT 160 maintains all database 185 objects per tenant 184 node. These database 185 objects are initialized during tenant creation. Defined users / roles for each tenant 181 can update only the tenant specific database 185 objects. None of the tenant 181 roles shall be able to view / update any database objects of other tenants 181.

[0053] FIG. 10 shows an architecture for tenant DB 185a object separation and access. SMO 160 has multiple functionality that needs access to the database 185 objects. Such a functionality could be triggered by nodes 184a, 184b, 184c interacting with SMO 160 like O-CU-CP 151-CP, O-CU-UP 151-UP, O-DU 152.

[0054] SMO-MT 160 ensures that only tenant specific database 185 objects are accessed for functionality triggered from tenant nodes 184a, 184b, 184c. SMO- MT 160 also ensures that only tenant specific database 185 objects are accessed for functionality triggered from the SMO 160 by any of the tenant specific roles.

[0055] It will be understood that implementations and embodiments can be implemented by computer program instructions. These program instructions can be provided to a processor to produce a machine, so that the instructions, which execute on the processor, create means for implementing the actions specified herein. The computer program instructions can be executed by a processor to cause a series of operational steps to be performed by the processor to produce a computer-implemented process so that the instructions, which execute on theprocessor to provide steps for implementing the actions specified. Moreover, some of the steps can also be performed across more than one processor, such as might arise in a multi-processor computer system or even a group of multiple computer systems. In addition, one or more blocks or combinations of blocks in the flowchart illustration can also be performed concurrently with other blocks or combinations of blocks, or even in a different sequence than illustrated without departing from the scope or spirit of the disclosure.

Claims

CLAIMS1. An apparatus for RAN comprising: a Multi-Tenant Service Management and Orchestration (SMO-MT) configured to operate, administrate and manage (OAM) functionality for plurality of tenants, wherein the SMO-MT is configured to offer shared 0AM resources while keeping data for each tenant separate.

2. The apparatus of claim 1, wherein the SMO-MT is configured for a Network Host Operator (NHO) tenant to host a plurality of Mobile Network Operator (MNO) tenants.

3. The apparatus of claim 2, wherein the SMO-MT is configured to allow the NHO tenant to perform one or more of: configure an O-Cloud and create a number of clusters over an 02 interface for IMS (Infrastructure Management Services); perform 0AM of the O-Cloud over the 02 interface IMS; configure and manage 0-RU resources of shared O-Radio Unit (0-RU) over an Open FH M-plane; and / or partition the shared 0-RU resources across the plurality of MN0 tenants using a resource partitioning Non-RT RIC Application (rApp).

4. The apparatus of claim 3, wherein the SMO-MT is configured to allow one or more of the MN0 tenants to: instantiate an MN0 specific network function (NF) on an O-Cloud cluster created by an NHO tenant user and perform lifecycle management (LCM) functions for MN0 specific NFs over an 02 interface for Deployment Management Services (DMS);perform Fault, Configuration, Accounting, Performance, Security (FCAPS) functions for the MNO specific NFs and, for a shared O-Radio Unit (O-RU), user plane configuration of allocated shared O-RU resources for an 0 Distributed Unit (O-DU) over an 01 interface; perform RIC optimizations for the MNO specific NFs over an E2 interface; and configure, by an MNO specific 0-DU, the shared O-RU with partitioned resources for the MNO.

5. The apparatus of claim 1, wherein the SMO-MT is configured to create and authenticate a plurality of users for each MNO tenant.

6. The apparatus of claim 5, wherein the SMO-MT comprises an authentication module configured to authenticate each of the plurality of tenants.

7. The apparatus of claim 1, wherein the SMO-MT includes a database comprising a database object per MNO tenant, and the SMO-MT is configured to allow an MNO tenant of the plurality of MNO tenants to access only their database object, and the SMO is configured so that the MNO tenant cannot access another database object of another MNO tenant.

8. The apparatus of claim 7, wherein the SMO-MT is configured to trigger tenant database access with tenant nodes.

9. The apparatus of claim 1, wherein the SMO-MT is configured for SMO / Network Management Systems (NMS) that serve multiple- Radio Access Technology (RAT) deployments for multiple MNO tenants.

10. The apparatus of claim 1, wherein the SMO-MT is configured to support SMO redundancy and resiliency.

Images