CN115866546A - Apparatus for use in RAN intelligent controller and E2 node - Google Patents

Abstract

Apparatus for use in a Radio Access Network (RAN) intelligent controller and an E2 node are provided. The present application relates to an apparatus for use in a RAN Intelligent Controller (RIC), wherein the apparatus comprises a processor circuit configured to cause the RIC to: establishing an E2 application protocol (E2 AP) RIC subscription process with an E2 node; determining to modify E2AP RIC subscription details; and establishing an enhanced E2AP RIC subscription procedure with the E2 node to support modification of E2AP RIC subscription details.

Description

Apparatus for use in RAN intelligent controller and E2 node

Priority declaration

This application is based on and claims priority from U.S. provisional application No. 63/247,745, filed on 23/9/2021, which is incorporated herein by reference in its entirety.

Technical Field

Embodiments of the present disclosure relate generally to the field of wireless communications, and more particularly, to an apparatus for use in a Radio Access Network (RAN) intelligent controller (RIC) and a RAN node (generally referred to as an "E2 node" in the present disclosure).

Background

Open Radio Access Network (O-RAN) has been working on integrating Artificial Intelligence (AI) and Machine Learning (ML) based intelligence into wireless communication networks. The aim of introducing AI and/or ML is not only to improve the performance of existing networks, but also to optimize/guide various network components to a certain Key Performance Indicator (KPI) of interest in an efficient and elegant manner.

Disclosure of Invention

An aspect of the disclosure provides an apparatus for use in a Radio Access Network (RAN) intelligent controller (RIC), wherein the apparatus comprises a processor circuit configured to cause the RIC to: establishing an E2 application protocol (E2 AP) RIC subscription process with an E2 node; determining to modify E2AP RIC subscription details; and establishing an enhanced E2AP RIC subscription procedure with the E2 node to support modification of the E2AP RIC subscription details.

Another aspect of the disclosure provides an apparatus for use in a Radio Access Network (RAN) intelligent controller (RIC), wherein the apparatus comprises a processor circuit configured to cause the RIC to: establishing an E2 application protocol (E2 AP) RIC subscription process with an E2 node; determining to modify E2AP RIC subscription details; and establishing a new E2AP RIC subscription modification procedure with the E2 node to support modification of the E2AP RIC subscription detail information.

Yet another aspect of the present disclosure provides an apparatus for use in an E2 node, wherein the apparatus comprises a processor circuit configured to cause the E2 node to: establishing an E2 application protocol (E2 AP) Radio Access Network (RAN) Intelligent controller (RIC) RIC subscription procedure with a RIC; determining that the E2AP RIC subscription detail information is requested to be modified; establishing a new E2AP RIC subscription modification required procedure with the RIC in response to a request to modify the E2AP RIC subscription details; and establishing a new E2AP RIC subscription modification procedure with the RIC in response to the establishment of the new E2AP RIC subscription modification required procedure to support a modification request for the E2AP RIC subscription details.

Drawings

Embodiments of the present disclosure are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements.

Fig. 1 shows a schematic diagram of a method for use in a near RT (near real time) RIC according to a first embodiment of the present disclosure;

fig. 2 shows a schematic diagram of a method for use in a near RT (near real time) RIC according to a second embodiment of the present disclosure;

fig. 3 shows a schematic diagram of a method for use in an E2 node according to a third embodiment of the present disclosure;

FIG. 4 shows a schematic diagram of a network according to various embodiments of the present disclosure;

fig. 5 shows a schematic diagram of a wireless network in accordance with various embodiments of the present disclosure;

fig. 6 illustrates a block diagram of components capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methodologies discussed herein, according to some example embodiments of the present disclosure; and

FIG. 7 provides a high-level view of an Open RAN (O-RAN) architecture 700; and

fig. 8 illustrates an O-RAN logical architecture 800 corresponding to the O-RAN architecture 700 of fig. 7.

Detailed Description

The following detailed description refers to the accompanying drawings. The same reference numbers may be used in different drawings to identify the same or similar elements. In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular structures, architectures, interfaces, techniques, etc. in order to provide a thorough understanding of the various aspects of the various embodiments. However, it will be apparent to one having ordinary skill in the art having had the benefit of the present disclosure that the various aspects of the various embodiments may be practiced in other examples that depart from these specific details. In certain instances, descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the various embodiments with unnecessary detail. For purposes of this document, the phrases "A or B" and "A/B" refer to (A), (B), or (A and B).

O-RAN has been working on integrating AI and ML based intelligence into wireless communication networks. AI/ML is introduced not only to improve the performance of existing networks, but also to optimize/guide various network components to certain Key Performance Indicators (KPIs) of interest in an efficient and elegant manner.

Injection and CONTROL directed to the RAN network by AI/ML based intelligence is implemented via an E2 interface from a near real time (near RT) RAN Intelligence Controller (RIC), which subscribes to various RIC services (REPORT, INSERT, CONTROL, POLICY) based on RAN functions exposed from RAN nodes. To this end, the E2 Application Protocol (E2 AP) has been specified to support management of E2 interface and RIC service subscriptions between near RT RIC and RAN nodes.

Although the basic form of RIC subscription processing initiated by near RT RIC is currently in the E2AP, the previously subscribed RIC subscription cannot be modified. Each E2AP RIC subscription that requests a subscription from a near RT RIC includes an event trigger definition followed by a list of actions that the near RT RIC wishes the E2 node (e.g., RAN node) to perform once a configured event trigger occurs. In particular for an INSERT action (where the E2 node stops processing, notifies the near RT RIC, and waits for subsequent commands when configured event triggers occur), the near RT RIC further configures an RIC Wait Time (RIC Time To Wait), e.g., how long the E2 node should Wait for subsequent commands from the near RT RIC, and whether To continue or stop processing if no subsequent commands are received within the configured RIC Time To Wait.

Near RT RIC may want to simply modify these behaviors, or modify event trigger definitions (e.g., change the frequency of performing actions) or delete specific actions associated with existing RIC subscriptions. However, this can only be achieved by near RT RIC by completely deleting existing subscriptions and re-requesting E2AP RIC subscriptions that subscribe to the modification, which is inefficient. Furthermore, the E2 node cannot request modification of an existing subscription at all (can only request complete deletion of the subscription).

In the present disclosure, in order to solve the above-described problems, a plurality of embodiments are proposed.

(1) In one embodiment, as shown in fig. 1, fig. 1 shows a schematic diagram of a method for use in a near RT RIC according to a first embodiment of the present disclosure, wherein an existing E2AP RIC subscription procedure is enhanced to support modifications of existing E2AP RIC subscription details initiated from the near RT RIC.

(2) In one embodiment, as shown in fig. 2, fig. 2 shows a schematic diagram of a method for use in a near RT RIC according to a second embodiment of the present disclosure, wherein a new E2AP RIC subscription procedure is defined to support modifications of existing E2AP RIC subscription details initiated from the near RT RIC.

(3) In one embodiment, as shown in fig. 3, fig. 3 shows a schematic diagram of a method used in an E2 node according to a third embodiment of the present disclosure, wherein a new E2AP RIC subscription procedure is defined to support a modification request initiated from the E2 node for existing E2AP RIC subscription details.

Embodiments of the present disclosure allow existing E2AP RIC subscription details to be modified between a near RT RIC and an E2 node (e.g., RAN node) over an E2 interface without inefficiently completely deleting the existing subscription and re-subscribing to the modified content. Processing efficiency may be improved in near RT RIC or E2 node implementations.

In one embodiment, the existing E2AP RIC subscription procedure may be enhanced to support modifications to existing E2AP RIC subscription details initiated from a near RT RIC, as illustrated in fig. 1 below.

Fig. 1 illustrates an example implementation of reusing an existing E2AP RIC subscription process for near RT RIC to modify E2AP RIC subscription details that have been previously subscribed to.

Specifically, in step 1 of fig. 1, the near RT RIC establishes an E2AP RIC subscription procedure with the E2 node, wherein the E2AP RIC subscription procedure may include one or more of: RIC request ID, RAN function ID, and/or subscription details.

In step 2 of fig. 1, the near RT RIC determines to modify the E2AP RIC subscription details.

In step 3 of fig. 1, the near RT RIC establishes an enhanced E2AP RIC subscription procedure with the E2 node to support modification of E2AP RIC subscription details, wherein the enhanced E2AP RIC subscription procedure may include one or more of: the RIC request ID, RAN function ID, and/or modified subscription details, and establishing an enhanced E2AP RIC subscription procedure between the near RT RIC and the E2 node comprises: a message with the RIC request ID, the RAN functionality ID, and/or the modified subscription details is communicated between the near RT RIC and the E2 node, in particular sent by the near RT RIC to the E2 node.

In one embodiment, the modified subscription details in step 3 of fig. 1 may include one or more of the following: updated event trigger definitions, and corresponding causes (if applicable); a list of one or more actions to be newly added, and detailed information thereof (e.g., RIC Action Definition IE); a list of one or more actions to modify, and updated detailed information thereof (e.g., RIC action definition IE); a list of one or more actions to delete, and a corresponding reason (if applicable); an updated RIC follow-up Action Type (RIC Subsequent Action Type), and a corresponding reason (if applicable); and an updated RIC Time to Wait, and the corresponding reason (if applicable).

In one embodiment, multiple AI or ML models are trained and used in near RT RIC.

In one embodiment, a new E2AP RIC subscription procedure may be defined to support modifications to existing E2AP RIC subscription details initiated from a near RT RIC, as illustrated in fig. 2 below.

Fig. 2 illustrates an example implementation of a new E2AP RIC subscription modification procedure for near RT RIC to modify E2AP RIC subscription details that have been previously subscribed to.

Specifically, in step 1 of fig. 2, the near RT RIC establishes an E2AP RIC subscription procedure with the E2 node, wherein the E2AP RIC subscription procedure may include one or more of: the RIC request ID, RAN function ID, and/or subscription details.

In step 2 of fig. 2, the near RT RIC determines to modify the E2AP RIC subscription details.

In step 3 of fig. 2, the near RT RIC establishes a new E2AP RIC subscription modification procedure with the E2 node to support modification of the E2AP RIC subscription details, wherein the new E2AP RIC subscription modification procedure may include one or more of: the RIC request ID, RAN functionality ID, and/or modified subscription details, and establishing a new E2AP RIC subscription modification procedure between the near RT RIC and the E2 node comprises: a message with the RIC request ID, the RAN function ID, and/or the modified subscription details is communicated between the near RT RIC and the E2 node, in particular sent by the near RT RIC to the E2 node.

In one embodiment, the modified subscription details in step 3 of fig. 2 may include one or more of the following: updated event trigger definitions, and corresponding causes (if applicable); a list of one or more actions to be newly added, and its detailed information (e.g., RIC action definition IE); a list of one or more actions to modify, and updated detailed information thereof (e.g., RIC action definition IE); a list of one or more actions to delete, and a corresponding reason (if applicable); an updated RIC subset Action Type, and corresponding reason (if applicable); and an updated RIC Time to Wait, and corresponding reasons, if applicable.

In one embodiment, a new E2AP RIC subscription procedure may be defined to support a modification request initiated from an E2 node to existing E2AP RIC subscription details, as illustrated in fig. 3 below.

Fig. 3 illustrates an example implementation of a new E2AP RIC subscription modification required procedure for an E2 node to request modification of previously subscribed E2AP RIC subscription details.

Specifically, in step 1 of fig. 3, the E2 node establishes an E2AP RIC subscription procedure with the near RT RIC, wherein the E2AP RIC subscription procedure may include one or more of: RIC request ID, RAN function ID, and/or subscription details.

In step 2 of fig. 3, the E2 node determines to request modification of the E2AP RIC subscription details.

In step 3 of fig. 3, the E2 node establishes a new E2AP RIC subscription modification need procedure with the near RT RIC in response to the request to modify the E2AP RIC subscription detail information, wherein the new E2AP RIC subscription modification need procedure may comprise one or more of: RIC request ID, RAN function ID, and/or subscription details to be modified.

In one embodiment, establishing a new E2AP RIC subscription modification between the E2 node and the near RT RIC requires a procedure comprising: a message with the RIC request ID, the RAN function ID, and/or subscription details to be modified is communicated between the E2 node and the near RT RIC, in particular sent by the E2 node to the near RT RIC.

In one embodiment, the subscription details to be modified in step 3 of fig. 3 may include one or more of the following: an event trigger definition to be modified; a list of one or more actions to modify, and updated detailed information thereof (e.g., RIC action definition IE); a list of one or more actions to delete, and a corresponding reason; and RIC Time to Wait to be modified, and the corresponding reason (if applicable).

In step 4 of fig. 3, the E2 node establishes a new E2AP RIC subscription (and/or modification) procedure with the near RT RIC in response to establishment of the new E2AP RIC subscription modification required procedure to support a modification request for the E2AP RIC subscription details, wherein the E2AP RIC subscription (and/or modification) procedure may comprise one or more of: the RIC request ID, RAN function ID, and/or modified subscription details.

In one embodiment, establishing a new E2AP RIC subscription modification procedure between the E2 node and the near RT RIC comprises: a message with the RIC request ID, the RAN function ID, and/or the modified subscription details is communicated between the E2 node and the near RT RIC, in particular received by the E2 node from the near RT RIC.

System and implementation mode

Fig. 4-5 illustrate various systems, devices, and components that can implement aspects of the disclosed embodiments.

Fig. 4 shows a schematic diagram of a network 400 according to various embodiments of the present disclosure. The network 400 may operate in accordance with 3GPP technical specifications for Long Term Evolution (LTE) or 5G/NR systems. However, the example embodiments are not limited in this respect, and the described embodiments may be applied to other networks that benefit from the principles described herein, such as future 3GPP systems and the like.

Network 400 may include a UE 402, which may include any mobile or non-mobile computing device designed to communicate with a Radio Access Network (RAN) 404 via an over-the-air connection. The UE 402 may be communicatively coupled with the RAN404 over a Uu interface. The UE 402 may be, but is not limited to, a smartphone, a tablet, a wearable computer device, a desktop computer, a laptop computer, an in-vehicle infotainment device, an in-vehicle entertainment device, a dashboard, a heads-up display device, an in-vehicle diagnostic device, a dashboard mobile device, a mobile data terminal, an electronic engine management system, an electronic/engine control unit, an electronic/engine control module, an embedded system, a sensor, a microcontroller, a control module, an engine management system, a network appliance, a machine-to-machine (M2M) or device-to-device (D2D) device, an internet of things (IoT) device, and/or the like.

In some embodiments, network 400 may include multiple UEs directly coupled to each other through a sidelink interface. The UE may be an M2M/D2D device that communicates using a physical sidelink channel (e.g., without limitation, a Physical Sidelink Broadcast Channel (PSBCH), a Physical Sidelink Discovery Channel (PSDCH), a Physical Sidelink Shared Channel (PSSCH), a Physical Sidelink Control Channel (PSCCH), a Physical Sidelink Fundamental Channel (PSFCH), etc.).

In some embodiments, the UE 402 may also communicate with an Access Point (AP) 406 over an over-the-air connection. The AP 406 may manage Wireless Local Area Network (WLAN) connections that may be used to offload some/all network traffic from the RAN 404. The connection between the UE 402 and the AP 406 may be in accordance with any IEEE 802.11 protocol, where the AP 406 may be wireless fidelity

A router. In some embodiments, the UE 402, RAN404, and AP 406 may utilize cellular WLAN aggregation (e.g., LTE-WLAN aggregation (LWA)/lightweight IP (LWIP)). Cellular WLAN aggregation may involveThe UE 402 is configured by the RAN404 to utilize both cellular radio resources and WLAN resources.

The RAN404 may include one or more access nodes, such as AN Access Node (AN) 408. The AN 408 may terminate air interface protocols of the UE 402 by providing access stratum protocols including a Radio Resource Control (RRC) protocol, a Packet Data Convergence Protocol (PDCP), a Radio Link Control (RLC) protocol, a Medium Access Control (MAC) protocol, and AN L1 protocol. In this manner, AN 408 may enable a data/voice connection between Core Network (CN) 420 and UE 402. In some embodiments, AN 408 may be implemented in a discrete device or as one or more software entities running on a server computer (as part of a virtual network, for example, which may be referred to as a distributed RAN (CRAN) or virtual baseband unit pool). AN 408 may be referred to as a Base Station (BS), a next generation base station (gNB), a RAN node, AN evolved node B (eNB), a next generation eNB (ng-eNB), a node B (NodeB), a roadside unit (RSU), a transmit receive point (TRxP), a transmit point (TRP), etc. The AN 408 may be a macrocell base station or a low power base station that provides a microcell, picocell, or other similar cell having a smaller coverage area, smaller user capacity, or higher bandwidth than the macrocell.

In embodiments where the RAN404 comprises multiple ANs, they may be coupled to each other over AN X2 interface (if the RAN404 is AN LTE RAN) or AN Xn interface (if the RAN404 is a 5G RAN). In some embodiments, the X2/Xn interface, which may be separated into a control/user plane interface, may allow the AN to communicate information related to handover, data/context transfer, mobility, load management, interference coordination, and the like.

The AN of the RAN404 may each manage one or more cells, groups of cells, component carriers, etc., to provide the UE 402 with AN air interface for network access. The UE 402 may be simultaneously connected with multiple cells provided by the same or different ANs of the RAN 404. For example, the UE 402 and RAN404 may use carrier aggregation to allow the UE 402 to connect with multiple component carriers, each corresponding to a primary cell (PCell) or a secondary cell (Scell). In a dual connectivity scenario, the first AN may be a master node providing a Master Cell Group (MCG) and the second AN may be a secondary node providing a Secondary Cell Group (SCG). The first/second AN can be any combination of eNB, gNB, ng-eNB, etc.

The RAN404 may provide an air interface over a licensed spectrum or an unlicensed spectrum. To operate in unlicensed spectrum, a node may use a License Assisted Access (LAA), enhanced LAA (eLAA), and/or further enhanced LAA (feLAA) mechanism based on the Carrier Aggregation (CA) technology of PCell/Scell. Prior to accessing the unlicensed spectrum, the node may perform a media/carrier sensing operation based on, for example, a Listen Before Talk (LBT) protocol.

In a vehicle-to-everything (V2X) scenario, the UE 402 or AN 408 may be or act as a Road Side Unit (RSU), which may refer to any transport infrastructure entity for V2X communication. The RSU may be implemented in or by AN appropriate AN or stationary (or relatively stationary) UE. An RSU implemented in or by a UE may be referred to as a "UE-type RSU"; an RSU implemented in or by an eNB may be referred to as an "eNB-type RSU"; an RSU implemented in or by a next generation NodeB (gNB) may be referred to as a "gNB-type RSU" or the like. In one example, the RSU is a computing device coupled with radio frequency circuitry located at the curb side that provides connection support to passing vehicle UEs. The RSU may also include internal data storage circuitry for storing intersection map geometry, traffic statistics, media, and applications/software for sensing and controlling ongoing vehicle and pedestrian traffic. The RSU may provide very low latency communications required for high speed events (e.g., collision avoidance, traffic warnings, etc.). Additionally or alternatively, the RSU may provide other cellular/WLAN communication services. The components of the RSU may be enclosed in a weatherproof enclosure suitable for outdoor installation and may include a network interface controller to provide a wired connection (e.g., ethernet) to a traffic signal controller or backhaul network.

In some embodiments, the RAN404 may be an LTE RAN 410, including an evolved node B (eNB), e.g., eNB 412. The LTE RAN 410 may provide an LTE air interface with the following features: subcarrier spacing (SCS) of 15 kHz; a single carrier frequency division multiple access (SC-FDMA) waveform for Uplink (UL) and a cyclic prefix orthogonal frequency division multiplexing (CP-OFDM) waveform for Downlink (DL); turbo codes for data, TBCC for control, and the like. The LTE air interface may rely on channel state information reference signals (CSI-RS) for CSI acquisition and beam management; relying on a Physical Downlink Shared Channel (PDSCH)/Physical Downlink Control Channel (PDCCH) demodulation reference signal (DMRS) for PDSCH/PDCCH demodulation; and relying on Cell Reference Signals (CRS) for cell search and initial acquisition, channel quality measurements, and channel estimation, and on channel estimation for coherent demodulation/detection at the UE. The LTE air interface may operate on the 6GHz sub-band.

In some embodiments, RAN404 may be a Next Generation (NG) -RAN 414 with a gNB (e.g., gNB 416) or an NG-eNB (e.g., NG-eNB 418). The gNB 416 may connect with 5G-enabled UEs using a 5G NR interface. The gNB 416 may be connected to the 5G core through an NG interface, which may include an N2 interface or an N3 interface. The NG-eNB 418 may also be connected with the 5G core over the NG interface, but may be connected with the UE over the LTE air interface. The gNB 416 and ng-eNB 418 may be connected to each other through an Xn interface.

In some embodiments, the NG interface may be divided into two parts, a NG user plane (NG-U) interface, which carries traffic data between the UPF 448 and the nodes of the NG-RAN 414 (e.g., an N3 interface), and a NG control plane (NG-C) interface, which is a signaling interface between the access and mobility management function (AMF) 444 and the nodes of the NG-RAN 414 (e.g., an N2 interface).

NG-RAN 414 may provide a 5G-NR air interface with the following features: variable subcarrier spacing (SCS); cyclic prefix-orthogonal frequency division multiplexing (CP-OFDM) for Downlink (DL), CP-OFDM for UL, and DFT-s-OFDM; polarity, repetition, simplex, and reed-muller codes for control; and low density parity check codes (LDPC) for the data. The 5G-NR air interface may rely on channel state reference signals (CSI-RS), PDSCH/PDCCH demodulation reference signals (DMRS), similar to the LTE air interface. The 5G-NR air interface may not use Cell Reference Signals (CRS), but may use Physical Broadcast Channel (PBCH) demodulation reference signals (DMRS) for PBCH demodulation; performing phase tracking of the PDSCH using a Phase Tracking Reference Signal (PTRS); and time tracking using the tracking reference signal. The 5G-NR air interface may operate over the FR1 band, which includes the 6GHz sub-band, or the FR2 band, which includes the 24.25GHz to 52.6GHz band. The 5G-NR air interface may include synchronization signals and PBCH blocks (SSBs), which are regions of a downlink resource grid including Primary Synchronization Signals (PSS)/Secondary Synchronization Signals (SSS)/PBCH.

In some embodiments, the 5G-NR air interface may use a bandwidth portion (BWP) for various purposes. For example, BWP may be used for dynamic adaptation of SCS. For example, UE 402 may be configured with multiple BWPs, where each BWP configuration has a different SCS. When a change in BWP is indicated to UE 402, the SCS of the transmission also changes. Another use case for BWP is related to power saving. In particular, the UE 402 may be configured with multiple BWPs with different numbers of frequency resources (e.g., PRBs) to support data transmission in different traffic load scenarios. BWPs containing a smaller number of PRBs may be used for data transmission with smaller traffic load while allowing power savings at UE 402 and, in some cases, at gNB 416. BWPs containing a large number of PRBs may be used in scenarios with higher traffic loads.

The RAN404 is communicatively coupled to a CN 420, which includes network elements, to provide various functions to support data and telecommunications services to customers/subscribers (e.g., users of the UEs 402). The components of CN 420 may be implemented in one physical node or in different physical nodes. In some embodiments, network Function Virtualization (NFV) may be used to virtualize any or all functions provided by the network elements of CN 420 onto physical computing/storage resources in servers, switches, and the like. Logical instances of CN 420 may be referred to as network slices, and logical instances of a portion of CN 420 may be referred to as network subslices.

In some embodiments, CN 420 may be LTE CN 422, which may also be referred to as EPC. LTE CN 422 may include a Mobility Management Entity (MME) 424, a Serving Gateway (SGW) 426, a serving General Packet Radio Service (GPRS) support node (SGSN) 428, a Home Subscriber Server (HSS) 430, a Proxy Gateway (PGW) 432, and a policy control and charging rules function (PCRF) 434, which are coupled to each other by an interface (or "reference point") as shown. The functions of the elements of LTE CN 422 may be briefly introduced as follows.

The MME 424 may implement mobility management functions to track the current location of the UE 402 to facilitate paging, bearer activation/deactivation, handover, gateway selection, authentication, and the like.

The SGW 426 may terminate the S1 interface towards the RAN and route data packets between the RAN and the LTE CN 422. SGW 426 may be a local mobility anchor for inter-RAN node handovers and may also provide an anchor for inter-3 GPP mobility. Other responsibilities may include lawful interception, charging, and some policy enforcement.

The SGSN 428 can track the location of the UE 402 and perform security functions and access control. In addition, the SGSN 428 may perform EPC inter-node signaling for mobility between different RAT networks; PDN and S-GW selection specified by MME 424; MME selection for handover, etc. An S3 reference point between the MME 424 and the SGSN 428 may enable user and bearer information exchange for inter-3 GPP access network mobility in idle/active state.

HSS 430 may include a database for network subscribers that includes subscription-related information that supports network entities handling communication sessions. HSS 430 may provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location dependency, etc. The S6a reference point between HSS 430 and MME 424 may enable the transmission of subscription and authentication data for authenticating/authorizing user access to LTE CN 420.

PGW 432 may terminate the SGi interface towards a Data Network (DN) 436 that may include an application/content server 438. PGW 432 may route data packets between LTE CN 422 and data network 436. PGW 432 may be coupled with SGW 426 through an S5 reference point to facilitate user plane tunneling and tunnel management. PGW 432 may also include nodes (e.g., PCEFs) for policy enforcement and charging data collection. Additionally, the SGi reference point between PGW 432 and data network 436 may be, for example, an operator external public, private PDN, or operator internal packet data network for providing IP Multimedia Subsystem (IMS) services. PGW 432 may be coupled with PCRF 434 via a Gx reference point.

PCRF 434 is the policy and charging control element of LTE CN 422. PCRF 434 can be communicatively coupled to application/content server 438 to determine appropriate quality of service (QoS) and charging parameters for a service flow. The PCRF 432 can provide relevant rules to the PCEF (via the Gx reference point) with appropriate Traffic Flow Templates (TFTs) and QoS Class Identifiers (QCIs).

In some embodiments, CN 420 may be a 5G core network (5 GC) 440.5GC 440 may include an authentication server function (AUSF) 442, an access and mobility management function (AMF) 444, a Session Management Function (SMF) 446, a User Plane Function (UPF) 448, a Network Slice Selection Function (NSSF) 450, a network open function (NEF) 452, an NF storage function (NRF) 454, a Policy Control Function (PCF) 456, a Unified Data Management (UDM) 458, and an Application Function (AF) 460, coupled to each other by an interface (or "reference point") as shown. The function of the elements of the 5GC 440 can be briefly described as follows.

The AUSF 442 may store data for authentication of the UE 402 and handle authentication related functions. The AUSF 442 may facilitate a common authentication framework for various access types. The AUSF 442 may exhibit a Nausf service based interface in addition to communicating with other elements of the 5GC 440 through reference points as shown.

The AMF 444 may allow other functions of the 5GC 440 to communicate with the UE 402 and the RAN404 and subscribe to notifications regarding mobility events for the UE 402. The AMF 444 may be responsible for registration management (e.g., registering UEs 402), connection management, reachability management, mobility management, lawful interception of AMF-related events, and access authentication and authorization. AMF 444 may provide for the transmission of Session Management (SM) messages between UE 402 and SMF446 and act as a transparent proxy for routing SM messages. The AMF 444 may also provide for the transmission of SMS messages between the UE 402 and the SMSF. The AMF 444 may interact with the AUSF 442 and the UE 402 to perform various security anchoring and context management functions. Further, the AMF 444 may be a termination point for the RAN CP interface, which may include or be an N2 reference point between the RAN404 and the AMF 444; and the AMF 444 may act as a termination point for NAS (N1) signaling and perform NAS ciphering and integrity protection. The AMF 444 may also support NAS signaling with the UE 402 over the N3 IWF interface.

SMF446 may be responsible for SM (e.g., tunnel management between UPF 448 and AN 408, session establishment); UE IP address assignment and management (including optional authorization); selection and control of the UP function; configuring flow control at the UPF 448 to route the traffic to the appropriate destination; termination of the interface to the policy control function; controlling a portion of policy enforcement, charging, and QoS; lawful interception (for SM events and interface to the LI system); terminate the SM portion of the NAS message; a downlink data notification; initiating AN-specific SM message (sent to AN 408 over N2 via AMF 444); and determining an SSC pattern for the session. SM may refer to the management of PDU sessions, and a PDU session or "session" may refer to a PDU connection service that provides or enables the exchange of PDUs between the UE 402 and the data network 436.

The UPF 448 may serve as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point to interconnect with the data network 436, and a branch point to support multi-homed PDU sessions. The UPF 448 may also perform packet routing and forwarding, perform packet inspection, perform the user plane part of policy rules, lawful intercepted packets (UP collection), perform traffic usage reporting, perform QoS processing for the user plane (e.g., packet filtering, gating, UL/DL rate enforcement), perform uplink traffic verification (e.g., SDF to QoS flow mapping), transport level packet marking in uplink and downlink, and perform downlink packet buffering and downlink data notification triggering. The UPF 448 may include an uplink classifier to support routing of traffic flows to the data network.

NSSF 450 may select a set of network slice instances that serve UE 402. NSSF 450 may also determine allowed Network Slice Selection Assistance Information (NSSAI) and a mapping to a single NSSAI (S-NSSAI) of the subscription, if desired. The NSSF 450 may also determine a set of AMFs to use for serving the UE 402, or determine a list of candidate AMFs, based on a suitable configuration and possibly by querying the NRF 454. The selection of a set of network slice instances for the UE 402 may be triggered by the AMF 444 (with which the UE 402 registers by interacting with the NSSF 450), which may result in a change in the AMF. NSSF 450 may interact with AMF 444 via the N22 reference point; and may communicate with another NSSF in the visited network via an N31 reference point (not shown). Further, NSSF 450 may expose an interface based on the NSSF service.

NEF 452 may securely expose services and capabilities provided by 3GPP network functionality for third parties, internal exposure/re-exposure, AF (e.g., AF 460), edge computing or fog computing systems, and the like. In these embodiments, NEF 452 may authenticate, authorize, or limit AF. NEF 452 may also translate information exchanged with AF 460 and information exchanged with internal network functions. For example, the NEF 452 may translate between the AF service identifier and the internal 5GC information. NEF 452 may also receive information from other NFs based on their public capabilities. This information may be stored as structured data at NEF 452 or at data store NF using a standardized interface. NEF 452 may then re-expose the stored information to other NFs and AFs, or for other purposes such as analysis. In addition, NEF 452 may expose an interface based on the Nnef service.

NRF 454 may support a service discovery function, receive NF discovery requests from NF instances, and provide information of discovered NF instances to NF instances. NRF 454 also maintains information on available NF instances and their supported services. As used herein, the terms "instantiate," "instance," and the like may refer to creating an instance, "instance" may refer to a specific occurrence of an object, which may occur, for example, during execution of program code. Further, NRF 454 may expose an interface based on the nrrf service.

PCF 456 may provide policy rules to control plane functions to enforce these policy rules and may also support a unified policy framework to manage network behavior. PCF 456 may also implement a front end to access subscription information related to policy decisions in the UDR of UDM 458. In addition to communicating with functions through reference points as shown, PCF 456 also exhibits an Npcf service-based interface.

UDM 458 may process subscription-related information to support network entities handling communication sessions, and may store subscription data for UE 402. For example, subscription data may be communicated via an N8 reference point between UDM 458 and AMF 444. UDM 458 may include two parts: application front end and User Data Record (UDR). The UDR may store policy data and subscription data for UDM 458 and PCF 456, and/or structured data and application data for NEF 452 for exposure (including PFD for application detection, application request information for multiple UEs 402). The UDR may expose a Nudr service-based interface to allow UDM 458, PCF 456, and NEF 452 to access a particular collection of stored data, as well as to read, update (e.g., add, modify), delete, and subscribe to notifications of relevant data changes in the UDR. The UDM may include a UDM-FE (UDM front end) that is responsible for handling credentials, location management, subscription management, and the like. Several different front ends may serve the same user in different transactions. The UDM-FE accesses the subscription information stored in the UDR and performs authentication credential processing, user identification processing, access authorization, registration/mobility management, and subscription management. UDM 458 may expose a numm service based interface in addition to communicating with other NFs through reference points as shown.

AF 460 may provide application impact on traffic routing, provide access to NEF, and interact with the policy framework for policy control.

In some embodiments, the 5GC 440 may enable edge computation by selecting an operator/third party service that is geographically close to the point where the UE 402 connects to the network. This may reduce delay and load on the network. To provide an edge calculation implementation, the 5GC 440 may select a UPF 448 near the UE 402 and perform traffic steering from the UPF 448 to the data network 436 over the N6 interface. This may be based on UE subscription data, UE location, and information provided by AF 460. In this way, AF 460 may affect UPF (re) selection and traffic routing. Based on operator deployment, the network operator may allow AF 460 to interact directly with the relevant NFs when AF 460 is considered a trusted entity. In addition, AF 460 may expose a Naf service based interface.

The data network 436 may represent various network operator services, internet access, or third party services that may be provided by one or more servers, including, for example, an application/content server 438.

Fig. 5 schematically illustrates a wireless network 500 in accordance with various embodiments. The wireless network 500 may include a UE 502 in wireless communication with AN 504. The UE 502 and the AN 504 may be similar to and substantially interchangeable with like-named components described elsewhere herein.

The UE 502 may be communicatively coupled with the AN 504 via a connection 506. Connection 506 is shown as an air interface to enable communication coupling and may operate at millimeter wave or below 6GHz frequencies according to a cellular communication protocol, such as an LTE protocol or a 5G NR protocol.

UE 502 may include a host platform 508 coupled with a modem platform 510. Host platform 508 can include application processing circuitry 512, which can be coupled with protocol processing circuitry 514 of modem platform 510. The application processing circuitry 512 may run various applications for the UE 502 that obtain/receive its application data. Application processing circuitry 512 may also implement one or more layers of operations to send/receive application data to/from a data network. These layer operations may include transport (e.g., UDP) and internet (e.g., IP) operations.

Protocol processing circuitry 514 may implement one or more layers of operations to facilitate the transmission or reception of data over connection 506. Layer operations implemented by the protocol processing circuit 514 may include, for example, medium Access Control (MAC), radio Link Control (RLC), packet Data Convergence Protocol (PDCP), radio Resource Control (RRC), and non-access stratum (NAS) operations.

Modem platform 510 may further include digital baseband circuitry 516, which digital baseband circuitry 516 may implement one or more layer operations "below" the layer operations performed by protocol processing circuitry 514 in the network protocol stack. These operations may include, for example, PHY operations including one or more of HARQ-ACK functions, scrambling/descrambling, encoding/decoding, layer mapping/demapping, modulation symbol mapping, received symbol/bit metric determination, multi-antenna port precoding/decoding, wherein these functions may include one or more of space-time, space-frequency, or spatial coding, reference signal generation/detection, preamble sequence generation and/or decoding, synchronization sequence generation/detection, control channel signal blind decoding, and other related functions.

Modem platform 510 may further include transmit circuitry 518, receive circuitry 520, RF circuitry 522, and RF front end (RFFE) circuitry 524, which may include or be connected to one or more antenna panels 526. Briefly, the transmit circuit 518 may include digital-to-analog converters, mixers, intermediate Frequency (IF) components, and the like; the receive circuitry 520 may include analog-to-digital converters, mixers, IF components, and the like; RF circuitry 522 may include low noise amplifiers, power tracking components, and the like; RFFE circuitry 524 may include filters (e.g., surface/bulk acoustic wave filters), switches, antenna tuners, beam forming components (e.g., phased array antenna components), and so forth. The selection and arrangement of components of transmit circuitry 518, receive circuitry 520, RF circuitry 522, RFFE circuitry 524, and antenna panel 526 (collectively, "transmit/receive components") may be specific to details of the particular implementation, e.g., whether the communication is Time Division Multiplexed (TDM) or Frequency Division Multiplexed (FDM), at mmWave or below 6GHz frequencies, etc. In some embodiments, the transmit/receive components may be arranged in a plurality of parallel transmit/receive chains, and may be arranged in the same or different chips/modules, etc.

In some embodiments, the protocol processing circuitry 514 may include one or more instances of control circuitry (not shown) to provide control functionality for the transmit/receive components.

UE reception may be established by and via antenna panel 526, RFFE circuitry 524, RF circuitry 522, receive circuitry 520, digital baseband circuitry 516, and protocol processing circuitry 514. In some embodiments, antenna panel 526 may receive transmissions from AN 504 by receiving beamformed signals received by multiple antennas/antenna elements of one or more antenna panels 526.

UE transmissions may be established through and via protocol processing circuitry 514, digital baseband circuitry 516, transmit circuitry 518, RF circuitry 522, RFFE circuitry 524, and antenna panel 526. In some embodiments, a transmit component of UE 502 may apply spatial filtering to data to be transmitted to form a transmit beam transmitted by the antenna elements of antenna panel 526.

Similar to the UE 502, the AN 504 may include a host platform 528 coupled with a modem platform 530. Host platform 528 may include application processing circuitry 532 coupled with protocol processing circuitry 534 of modem platform 530. The modem platform may also include digital baseband circuitry 536, transmit circuitry 538, receive circuitry 540, RF circuitry 542, RFFE circuitry 544, and antenna panel 546. The components of AN 504 may be similar to, and substantially interchangeable with, the synonymous components of UE 502. In addition to performing data transmission/reception as described above, the components of AN 504 may perform various logical functions including, for example, radio Network Controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management, and data packet scheduling.

Fig. 6 is a block diagram illustrating components capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methodologies discussed herein, according to some example embodiments. In particular, fig. 6 shows a schematic diagram of hardware resources 600, hardware resources 600 including one or more processors (or processor cores) 610, one or more memory/storage devices 620, and one or more communication resources 630, where each of these processors, memory/storage devices, and communication resources may be communicatively coupled via a bus 640 or other interface circuitry. For embodiments utilizing node virtualization (e.g., network Function Virtualization (NFV)), hypervisor 602 may be executed to provide an execution environment for one or more network slices/subslices to utilize hardware resources 600.

Processor 610 may include, for example, a processor 612 and a processor 614. The processor 610 may be, for example, a Central Processing Unit (CPU), a Reduced Instruction Set Computing (RISC) processor, a Complex Instruction Set Computing (CISC) processor, a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP) such as a baseband processor, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Radio Frequency Integrated Circuit (RFIC), another processor (including those discussed herein), or any suitable combination thereof.

Memory/storage device 620 may include a main memory, a disk storage device, or any suitable combination thereof. The memory/storage 620 may include, but is not limited to, any type of volatile, non-volatile, or semi-volatile memory, such as Dynamic Random Access Memory (DRAM), static Random Access Memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state memory, and the like.

The communication resources 630 may include interconnection or network interface controllers, components, or other suitable devices to communicate with one or more peripherals 604 or one or more databases 606 or other network elements via the network 608. For example, communication resources 630 can include wired communication components (e.g., for coupling via USB, ethernet, etc.),. A cellular communication component, a Near Field Communication (NFC) component,

(or +>

Low energy) assembly, based on the status of the vehicle>

Components, and other communication components.

The instructions 650 may include software, programs, applications, applets, applications, or other executable code for causing at least any one of the processors 610 to perform any one or more of the methods discussed herein. The instructions 650 may reside, completely or partially, within at least one of the processor 610 (e.g., in a cache memory of the processor), the memory/storage 620, or any suitable combination thereof. Further, any portion of instructions 650 may be communicated to hardware resource 600 from any combination of peripherals 604 or database 606. Thus, the memory of the processor 610, the memory/storage 620, the peripherals 604, and the database 606 are examples of computer-readable and machine-readable media.

Fig. 7 provides a high-level view of an open RAN (O-RAN) architecture 700. The O-RAN architecture 700 includes four O-RAN defined interfaces-namely, an A1 interface, an O2 interface, and an open Forwarding Management (M) plane interface-that connect a Service Management and Organization (SMO) framework 702 to an O-RAN Network Function (NF) 704 and an O-Cloud 706. The SMO 702 (described in "O-RAN alliance work group 1, O-RAN operation and maintenance Interface specification, version 2.0 (12 months 2019) (" O RAN-wg1.O1-Interface-v02.00 ")) also connects to an external system 710 that provides rich data to the SMO 702. Fig. 7 also shows an O-RAN non-real time (non-RT) RAN Intelligent Controller (RIC) 712 where the A1 interface terminates in or at SMO 702, and an O-RAN near RT RIC 714 in or at O-RAN NF 704. The O-RAN NF 704 may be a VNF, such as a VM or container, located above the O-Cloud 706 and/or Physical Network Function (PNF) utilizing custom hardware. When interfacing with SMO framework 702, it is desirable that all O-RAN NFs 704 support an O1 interface. The O-RAN NF 704 is connected to the NG core 708 via the NG interface (3 GPP defined interface). The open fronthaul M-plane interface between the SMO 702 and the O-RAN radio unit (O-RU) 716 supports O-RU 716 management in an O-RAN hybrid model, as specified in the "O-RAN alliance work group 4, O-RAN fronthaul management plane specification, version 2.0 (7 months 2019) (" ora-wg4.mp.0-v02.00.00 ")". The open fronthaul M-plane interface is an optional interface to the SMO 702 included for backward compatibility purposes under the "O-RAN alliance work group 4, O-RAN fronthaul management plane specification, version 2.0 (7 months 2019) (" ora-wg4. Mp.0-v02.00.00 ")" and is intended only for managing the O-RUs 716 in a hybrid mode. The management Architecture of planar mode "O-RAN alliance work group 1, O-RAN operation and maintenance Architecture specification, version 2.0 (12 months 2019) (" O RAN-wg1.Oam-Architecture-v02.00 ")" and its relationship to the O1 interface of O-RU 716 are used for future research. The O-RU 716 terminates the O1 interface towards SMO 702 as specified in "O-RAN alliance work group 1, O-RAN operations and maintenance Architecture specification, version 2.0 (12 months 2019) (" O RAN-wg1.Oam-Architecture-v02.00 ")".

Fig. 8 illustrates an O-RAN logical architecture 800 corresponding to the O-RAN architecture 700 of fig. 7. In FIG. 8, SMO 802 corresponds to SMO 702 of FIG. 7, O-Cloud 806 corresponds to O-Cloud 706, non-RT RIC 812 corresponds to non-RT RIC 712, near-RT RIC 814 corresponds to near-RT RIC 714, and O-RU 816 corresponds to O-RU 716, respectively. The O-RAN logical architecture 800 includes a radio portion and a management portion.

The management portion/side of architecture 800 includes SMO framework 802 including non-RT RIC 812, and may include O-Cloud 806. The O-Cloud 806 is a Cloud computing platform that includes a set of physical infrastructure nodes to host relevant O-RAN functions (e.g., near RT RIC 814, O-CU-CP 821, O-CU-UP 822, and O-DU 815), support software components (e.g., OS, VMM, container runtime engine, ML engine, etc.), and appropriate management and orchestration functions.

The radio portion/side of logical architecture 800 includes near RT RIC 814, O-RAN distributed units (O-DU) 815, O-RU 816, O-RAN central unit-control plane (O-CU-CP) 821, and O-RAN central unit-user plane (O-CU-UP) 822 functionality. The radio portion/side of the logic architecture 800 may also include an O-e/gNB 810.

The O-DU 815 is a logical node that hosts RLC, MAC, and higher PHY layer entities/units (higher PHY layer) based on lower layer functional partitioning. The O-RU 816 is a logical node that hosts lower PHY layer entities/units (low PHY units) (e.g., FFT/iFFT, PRACH extraction, etc.) and RF processing units based on lower layer functional partitioning. The virtualization for O-RU 816 is FFS. The O-CU-CP 821 is a logical node that hosts the Control Plane (CP) portion of the RRC and PDCP protocols. O-CU-UP 822 is a logical node that hosts the user plane part of the PDCP protocol and the Service Data Adaptation Protocol (SDAP).

The E2 interface terminates in a plurality of E2 nodes. The E2 node is a logical node/entity that terminates the E2 interface. For NR/5G access, the E2 node includes O-CU-CP 821, O-CU-UP 822, O-DU 815 or any combination of elements as defined in the "O-RAN alliance No. 3 working group, near real-time RAN intelligent controller architecture and E2 general aspects and principles (" ORAN-wg3.E2gap.0-v0.1 "). For E-UTRA access, the E2 node includes an O-E/gNB 810. As shown in fig. 8, the E2 interface also connects O-E/gNB 820 to near RT RIC 814. The protocol on the E2 interface is based only on the Control Plane (CP) protocol. The E2 functions are classified into the following categories: (a) Near RT RIC 814 services (REPORT, INSERT, CONTROL, and POLICY, as described in "O-RAN alliance No. 3 working group, near real-time RAN intelligent controller architecture, and E2 general aspects and principles (" ORAN-wg3.E2gap.0-v0.1 "), and (b) near RT RIC 814 support functions, including E2 interface management (E2 set, E2 reset, general error condition reporting, etc.) and near RT RIC service updates (e.g., capability exchange related to E2 node function list exposed on E2).

Fig. 8 shows the Uu interface between the UE 801 and the O-e/gNB 810, and the Uu interface between the UE 801 and the O-RAN components. The Uu interface is a 3GPP defined interface (see, e.g., 3GPP TS 38.401v16.0.0 (2020-01-09), sections 5.2 and 5.3), which includes the complete protocol stack from L1 to L3 and terminates in either NG-RAN or E-UTRAN. O-E/gNB 810 is an LTE eNB supporting an E2 interface (3GPP TS 36.401v15.1.0 (2019-01-09)), 5G gNB, or ng-eNB (3GPP TS 38.300v16.0.0 (2020-01-08)). The O-e/gNB 810 can be the same as or similar to AN 408 and/or AN 504 discussed previously. The UE 801 may correspond to the UE 402 and/or the UE 502 discussed with respect to fig. 4 and 5, etc. There may be multiple UEs 801 and/or multiple O-e/gnbs 810, each of which may be connected to each other via a respective Uu interface. Although not shown in FIG. 8, O-e/gNB 810 supports O-DU 815 and O-RU 816 functions with an open fronthaul interface between them.

The Open Fronthaul (OF) interface(s) are located between the O-DU 815 and O-RU 816 functions "O-RAN alliance 4 th workgroup, O-RAN fronthaul management plane Specification, version 2.0 (7 months 2019) (" ORAN-WG4.MP.0-v02.00.00 ")," O-RAN alliance 4 th workgroup, O-RAN fronthaul control, user and sync plane Specification, version 2.0 (7 months 2019) ("ORAN-WG4. CUS.0-v 02.00") ". The OF interface(s) include a Control User Synchronization (CUS) plane and a management (M) plane. Fig. 4 and 8 also show that the O-RU 816 terminates the OF M plane interface towards the O-DU 815 and optionally towards the SMO 802, as described in "O-RAN alliance, working group 4, O-RAN fronthaul management plane specification, version 2.0 (7 months 2019) (" ORAN-wg4.Mp.0-v02.00.00 ")". The O-RU 816 terminates the OF CUS plane interface towards the O-DU 815 and SMO 802.

The F1-c interface connects O-CU-CP 821 and O-DU 815. As defined by 3GPP, the F1-c interface is located between the gNB-CU-CP and gNB-DU nodes (3GPP TS 38.401v16.0.0 (2020-01-09)), (3GPP TS 38.470v16.0.0 (2020-01-09)). However, for the purpose of the O-RAN, the F1-c interface is employed between the O-CU-CP 821 and O-DU 815 functions, while reusing principles and protocol stacks defined by the 3GPP and definitions of the interoperability profile specification.

The F1-u interface connects O-CU-UP 822 and O-DU 815. As defined by 3GPP, the F1-u interface is located between the gNB-CU-UP and gNB-DU nodes (3GPP TS 38.401v16.0.0 (2020-01-09)), (3GPP TS 38.470v16.0.0 (2020-01-09)). However, for the purpose of O-RAN, the F1-u interface is employed between O-CU-UP 822 and O-DU 815 functions while reusing principles and protocol stacks defined by 3GPP and definitions of interoperability profile specifications.

The 3GPP defines the NG-c interface as the interface between the gNB-CU-CP and AMF in 5GC (3 GPP TS 38.300v16.0.0 (2020-01-08)). NG-c is also called N2 interface (see 3GPP TS 38.300v16.0.0 (2020-01-08)). The 3GPP defines the NG-u interface as the interface between gNB-CU-UP and UPF in 5GC (3 GPP TS 38.300v16.0.0 (2020-01-08)). The NG-u interface is called the N3 interface (see 3GPP TS 38.300v16.0.0 (2020-01-08)). In the O-RAN, the NG-c and NG-u protocol stacks defined by the 3GPP are reused and can be used for O-RAN purposes.

The X2-c interface is defined in 3GPP for transmitting control plane information between enbs or between an eNB and an EN-gNB in EN-DC. The X2-u interface is defined in 3GPP for the transport of user plane information between enbs or eNB and EN-gNB in EN-DC (see e.g. 3GPP TS 36.420v15.2.0 (2020-01-09), 3GPP TS 38.300v16.0.0 (2020-01-08)). In the O-RAN, the 3GPP defined X2-c and X2-u protocol stacks are reused and can be used for O-RAN purposes.

The Xn-c interface is defined in 3GPP for the transport of control plane information between the gnbs, between the ng-enbs or between the ng-enbs and the gnbs. The Xn-u interface is defined in 3GPP for transporting user plane information between gnbs, between ng-enbs or between a ng-eNB and a gNB (see e.g. 3GPP TS 38.300v16.0.0 (2020-01-08), 3GPP TS 38.420v15.2.0 (2019-01-08)). In the O-RAN, the 3GPP defined Xn-c and Xn-u protocol stacks are reused and can be used for O-RAN purposes.

The E1 interface is defined by 3GPP as the interface between the gNB-CU-CP (e.g., gNB-CU-CP 3728) and the gNB-CU-UP (see, e.g., 3GPP TS 38.401v16.0.0 (2020-01-09), 3GPP TS 38.460v16.0.0 (2020-01-09)). In the O-RAN, the 3GPP defined E1 protocol stack is reused and adapted as an interface between O-CU-CP 821 and O-CU-UP 822 functionality.

An O-RAN non-real time (non-RT) RAN Intelligent Controller (RIC) 812 is a logical function within the SMO framework 702, 802 that enables non-real time control and optimization of RAN elements and resources; AI/Machine Learning (ML) workflow(s), including model training, reasoning, and updating; and policy-based guidance of applications/features in the near RT RIC 814.

The O-RAN near RT RIC 814 is a logical function that enables near real-time control and optimization of RAN elements and resources via fine-grained data collection and actions over the E2 interface. The near RT RIC 814 may include one or more AI/ML workflows, including model training, reasoning, and updating.

non-RT RIC 812 may be an ML training host for hosting training of one or more ML models. ML training may be performed offline using data collected from the RIC, O-DU 815, and O-RU 816. For supervised learning, non-RT RIC 812 is part of SMO 802, and ML training host and/or ML model host/participant may be part of non-RT RIC 812 and/or near-RT RIC 814. For unsupervised learning, the ML training host and ML model host/participant can be part of the non-RT RIC 812 and/or near-RT RIC 814. For reinforcement learning, the ML training host and ML model host/participant can be co-located as part of the non-RT RIC 812 and or near-RT RIC 814. In some implementations, non-RT RIC 812 may request or trigger ML model training in a training host regardless of where the model is deployed and executed. The ML model may be trained and not currently deployed.

In some implementations, non-RT RIC 812 provides a queryable catalog for ML designers/developers to publish/install trained ML models (e.g., executable software components). In these implementations, if a particular ML model can be executed in a target ML inference host (MF), non-RT RIC 812 can provide a discovery mechanism, and what number and types of ML models can be executed in the MF. For example, non-RT RIC 812 may have three types of ML directories unavailable: a design-time directory (e.g., residing outside non-RT RIC 812 and hosted by some other ML platform), a training/deployment-time directory (e.g., residing inside non-RT RIC 812), and a runtime directory (e.g., residing inside non-RT RIC 812). non-RT RIC 812 supports the necessary capabilities for ML model inference to support ML-assisted solutions running in non-RT RIC 812 or some other ML inference host. These functions enable executable software to be installed, e.g., VMs, containers, etc. non-RT RIC 812 may also include and/or operate one or more ML engines, which are packaged software executable libraries that provide methods, routines, data types, etc. for running ML models. non-RT RIC 812 may also implement policies for switching and activating ML model instances under different operating conditions.

non-RT RIC 812 can access feedback data (e.g., FM and PM statistics) about ML model performance through the O1 interface and perform the necessary evaluations. If the ML model fails at runtime, an alert may be generated as feedback to the non-RT RIC 812. How the ML model behaves in terms of prediction accuracy or other operational statistics it generates can also be sent to non-RT RIC 812 through O1. non-RT RIC 812 can also scale ML model instances running in the target MF by observing resource utilization in the MF through the O1 interface. The environment (e.g., MF) running the ML model instance monitors resource utilization of the running ML model. This may be accomplished, for example, by using an ORAN-SC component called a resource monitor in the near RT RIC 814 and/or non-RT RIC 812, which continuously monitors resource utilization. The runtime environments in near RT RIC 814 and/or non-RT RIC 812 provide scaling mechanisms to add more ML instances if the resources are low or drop below a certain threshold. The scaling mechanism may include a scaling factor, such as a number, percentage, and/or other similar data for zooming in/out of the quantity of ML instances. An ML model instance running in a target ML inference host can be automatically scaled by observing resource utilization in the MF. For example,

(K8) RuntimeEnvironments typically provide an auto-zoom feature.

The A1 interface is located between non-RT RIC 812 (located inside or outside SMO 802) and near RT RIC 814. As in the "O-RAN alliance, 2 nd working group, O-RAN A1 interface: general aspects and principles specifications, defined in version 1.0 (10 months 2019) ("ORAN-wg2. A1.Ga & P-v 01.00") ", the A1 interface supports three types of services including policy management service, enriched information service, and ML model management service. With persistent configuration "O-RAN alliance 2 nd working group, O-RAN A1 interface: general aspects and rules, version 1.0 (10 months 2019) ("ORAN-wg2. A1.Ga & P-v 01.00") "compared, the A1 strategy has the following properties: the A1 strategy is not important to traffic; a1 policy has temporary validity; the A1 policy may handle a single UE or a dynamically defined group of UEs; the A1 strategy plays a role in configuration and has priority over the configuration; and the A1 policy is non-persistent, e.g., cannot survive a restart of the near RT RIC.

For one or more embodiments, at least one component illustrated in one or more of the foregoing figures may be configured to perform one or more operations, techniques, procedures, and/or methods described in the example section below. For example, baseband circuitry as described above in connection with one or more of the foregoing figures may be configured to operate according to one or more examples described below. For another example, circuitry associated with a UE, base station, network element, etc., as described above in connection with one or more of the preceding figures, can be configured to operate in accordance with one or more examples set forth below in the examples section.

The following paragraphs describe examples of various embodiments.

Example 1 includes: an apparatus for use in a Radio Access Network (RAN) intelligent controller (RIC), wherein the apparatus comprises a processor circuit configured to cause the RIC to: establishing an E2 application protocol (E2 AP) RIC subscription process with an E2 node; determining to modify E2AP RIC subscription details; and establishing an enhanced E2AP RIC subscription procedure with the E2 node to support modification of the E2AP RIC subscription details.

Example 2 includes the apparatus of example 1, wherein the E2AP RIC subscription procedure includes one or more of: the RIC request ID, RAN function ID, and/or subscription details.

Example 3 includes the apparatus of example 1, wherein the enhanced E2AP RIC subscription procedure includes one or more of: the RIC request ID, RAN function ID, and/or modified subscription details.

Example 4 includes the apparatus of example 3, wherein establishing the enhanced E2AP RIC subscription procedure with the E2 node comprises: sending a message with the RIC request ID, the RAN function ID, and/or the modified subscription details.

Example 5 includes the apparatus of example 3 or 4, wherein the modified subscription details include one or more of: an updated event trigger definition, a list of one or more actions to be newly added, a list of one or more actions to be modified, a list of one or more actions to be deleted, an updated RIC Subsequent Action Type, and/or an updated RIC Time to Wait.

Example 6 includes the apparatus of example 5, wherein the modified subscription details further include one or more of: updating a reason defined by the event trigger, deleting a reason for the one or more actions, updating a reason for the RIC Subsequent Action Type, and/or updating a reason for the RIC Time to Wait.

Example 7 includes the apparatus of example 1, wherein the RIC is a near real-time (near RT) RIC in which a plurality of Artificial Intelligence (AI) or Machine Learning (ML) models are trained and used.

Example 8 includes an apparatus for use in a Radio Access Network (RAN) intelligent controller (RIC), wherein the apparatus comprises a processor circuit configured to cause the RIC to: establishing an E2 application protocol (E2 AP) RIC subscription process with an E2 node; determining to modify E2AP RIC subscription details; and establishing a new E2AP RIC subscription modification procedure with the E2 node to support modification of the E2AP RIC subscription detail information.

Example 9 includes the apparatus of example 8, wherein the E2AP RIC subscription procedure includes one or more of: RIC request ID, RAN function ID, and/or subscription details.

Example 10 includes the apparatus of example 8, wherein the new E2AP RIC subscription modification procedure includes one or more of: the RIC requests an ID, a RAN function ID, and/or modified subscription details.

Example 11 includes the apparatus of example 10, wherein establishing the new E2AP RIC subscription modification procedure with the E2 node comprises: sending a message with the RIC request ID, the RAN function ID, and/or the modified subscription details.

Example 12 includes the apparatus of example 10 or 11, wherein the modified subscription details include one or more of: an updated event trigger definition, a list of one or more actions to be newly added, a list of one or more actions to be modified, a list of one or more actions to be deleted, an updated RIC Subsequent Action Type, and/or an updated RIC Time to Wait.

Example 13 includes the apparatus of example 12, wherein the modified subscription details further include one or more of: updating a reason defined by the event trigger, deleting a reason for the one or more actions, updating a reason for the RIC Subsequent Action Type, and/or updating a reason for the RIC Time to Wait.

Example 14 includes the apparatus of example 8, wherein the RIC is a near real-time (near RT) RIC in which a plurality of Artificial Intelligence (AI) or Machine Learning (ML) models are trained and used.

Example 15 includes an apparatus to be used in an E2 node, wherein the apparatus includes a processor circuit configured to cause the E2 node to: establishing an E2 application protocol (E2 AP) Radio Access Network (RAN) Intelligent controller (RIC) RIC subscription procedure with a RAN Intelligent Controller (RIC); determining to request modification of E2AP RIC subscription details; establishing a new E2AP RIC subscription modification required procedure with the RIC in response to a request to modify the E2AP RIC subscription details; and establishing a new E2AP RIC subscription modification procedure with the RIC in response to the establishment of the new E2AP RIC subscription modification required procedure to support a modification request for the E2AP RIC subscription details.

Example 16 includes the apparatus of example 15, wherein the E2AP RIC subscription procedure includes one or more of: RIC request ID, RAN function ID, and/or subscription details.

Example 17 includes the apparatus of example 15, wherein the new E2AP RIC subscription modification required procedure includes one or more of: RIC request ID, RAN function ID, and/or subscription details to be modified.

Example 18 includes the apparatus of example 17, wherein establishing the new E2AP RIC subscription modification with the RIC requires a procedure comprising: sending a message with the RIC request ID, the RAN function ID, and/or the subscription details to modify.

Example 19 includes the apparatus of example 17 or 18, wherein the subscription details to be modified include one or more of: an event trigger definition to modify, a list of one or more actions to delete, and/or a RIC Time to Wait to modify.

Example 20 includes the apparatus of example 19, wherein the subscription details to be modified further include one or more of: deleting a cause of the one or more actions, and/or modifying a cause of the RIC Time to Wait.

Example 21 includes the apparatus of example 15, wherein the new E2AP RIC subscription modification procedure includes one or more of: the RIC request ID, RAN function ID, and/or modified subscription details.

Example 22 includes the apparatus of example 21, wherein establishing the new E2AP RIC subscription modification procedure with the RIC comprises: receiving a message with the RIC request ID, the RAN function ID, and/or the modified subscription details.

Example 23 includes the apparatus of example 15, wherein the RIC is a near real-time (near RT) RIC in which a plurality of Artificial Intelligence (AI) or Machine Learning (ML) models are trained and used.

Example 24 includes a computer-readable storage medium having stored thereon computer-executable instructions, wherein the computer-executable instructions, when executed by processor circuitry of a Radio Access Network (RAN) intelligent controller (RIC), cause the RIC to: establishing an E2 application protocol (E2 AP) RIC subscription process with an E2 node; determining to modify E2AP RIC subscription details; and establishing an enhanced E2AP RIC subscription procedure with the E2 node to support modification of the E2AP RIC subscription details.

Example 25 includes the computer-readable storage medium of example 24, wherein the E2AP RIC subscription process includes one or more of: RIC request ID, RAN function ID, and/or subscription details.

Example 26 includes the computer-readable storage medium of example 24, wherein the enhanced E2AP RIC subscription process includes one or more of: the RIC request ID, RAN function ID, and/or modified subscription details.

Example 27 includes the computer-readable storage medium of example 26, wherein establishing the enhanced E2AP RIC subscription procedure with the E2 node comprises: sending a message with the RIC request ID, the RAN function ID, and/or the modified subscription details.

Example 28 includes the computer-readable storage medium of example 26 or 27, wherein the modified subscription details include one or more of: an updated event trigger definition, a list of one or more actions to be newly added, a list of one or more actions to be modified, a list of one or more actions to be deleted, an updated RIC Subsequent Action Type, and/or an updated RIC Time to Wait.

Example 29 includes the computer-readable storage medium of example 28, wherein the modified subscription details further include one or more of: updating a reason defined by the event trigger, deleting a reason for the one or more actions, updating a reason for the RIC Subsequent Action Type, and/or updating a reason for the RIC Time to Wait.

Example 30 includes the computer-readable storage medium of example 24, wherein the RIC is a near real-time (near RT) RIC in which a plurality of Artificial Intelligence (AI) or Machine Learning (ML) models are trained and used.

Example 31 includes a computer-readable storage medium having stored thereon computer-executable instructions, wherein the computer-executable instructions, when executed by processor circuitry of a Radio Access Network (RAN) intelligent controller (RIC), cause the RIC to: establishing an E2 application protocol (E2 AP) RIC subscription process with an E2 node; determining to modify E2AP RIC subscription details; and establishing a new E2AP RIC subscription modification procedure with the E2 node to support modification of the E2AP RIC subscription detail information.

Example 32 includes the computer-readable storage medium of example 31, wherein the E2AP RIC subscription process includes one or more of: RIC request ID, RAN function ID, and/or subscription details.

Example 33 includes the computer-readable storage medium of example 31, wherein the new E2AP RIC subscription modification procedure includes one or more of: the RIC request ID, RAN function ID, and/or modified subscription details.

Example 34 includes the computer-readable storage medium of example 33, wherein establishing the new E2AP RIC subscription modification procedure with the E2 node comprises: sending a message with the RIC request ID, the RAN function ID, and/or the modified subscription details.

Example 35 includes the computer-readable storage medium of example 33 or 34, wherein the modified subscription details include one or more of: an updated event trigger definition, a list of one or more actions to be newly added, a list of one or more actions to be modified, a list of one or more actions to be deleted, an updated RIC Subsequent Action Type, and/or an updated RIC Time to Wait.

Example 36 includes the computer-readable storage medium of example 35, wherein the modified subscription details further include one or more of: updating a reason defined by the event trigger, deleting a reason for the one or more actions, updating a reason for the RIC Subsequent Action Type, and/or updating a reason for the RIC Time to Wait.

Example 37 includes the computer-readable storage medium of example 31, wherein the RIC is a near real-time (near RT) RIC in which a plurality of Artificial Intelligence (AI) or Machine Learning (ML) models are trained and used.

Example 38 includes a computer-readable storage medium having computer-executable instructions stored thereon, wherein the computer-executable instructions, when executed by a processor circuit of an E2 node, cause the E2 node to: establishing an E2 application protocol (E2 AP) Radio Access Network (RAN) Intelligent controller (RIC) RIC subscription procedure with a RAN Intelligent Controller (RIC); determining that the E2AP RIC subscription detail information is requested to be modified; establishing a new E2AP RIC subscription modification required procedure with the RIC in response to a request to modify the E2AP RIC subscription details; and establishing a new E2AP RIC subscription modification procedure with the RIC in response to the establishment of the new E2AP RIC subscription modification requirement procedure to support a modification request for the E2AP RIC subscription details.

Example 39 includes the computer-readable storage medium of example 38, wherein the E2AP RIC subscription process includes one or more of: RIC request ID, RAN function ID, and/or subscription details.

Example 40 includes the computer-readable storage medium of example 38, wherein the new E2AP RIC subscription modification requirement procedure comprises one or more of: RIC request ID, RAN function ID, and/or subscription details to be modified.

Example 41 includes the computer-readable storage medium of example 40, wherein establishing the new E2AP RIC subscription modification with the RIC requires a process comprising: sending a message with the RIC request ID, the RAN function ID, and/or the subscription details to modify.

Example 42 includes the computer-readable storage medium of example 40 or 41, wherein the subscription details to be modified include one or more of: an event trigger definition to modify, a list of one or more actions to delete, and/or a RIC Time to Wait to modify.

Example 43 includes the computer-readable storage medium of example 42, wherein the subscription details to be modified further include one or more of: deleting a cause of the one or more actions, and/or modifying a cause of the RIC Time to Wait.

Example 44 includes the computer-readable storage medium of example 38, wherein the new E2AP RIC subscription modification process includes one or more of: the RIC request ID, RAN function ID, and/or modified subscription details.

Example 45 includes the computer-readable storage medium of example 44, wherein establishing the new E2AP RIC subscription modification procedure with the RIC comprises: receiving a message with the RIC request ID, the RAN function ID, and/or the modified subscription details.

Example 46 includes the computer-readable storage medium of example 38, wherein the RIC is a near real-time (near RT) RIC in which a plurality of Artificial Intelligence (AI) or Machine Learning (ML) models are trained and used.

Example 47 includes a Radio Access Network (RAN) intelligent controller (RIC) as shown and described in the specification.

Example 48 includes a method as performed at a Radio Access Network (RAN) intelligent controller (RIC) as shown and described in the specification.

Example 49 includes an E2 node as shown and described in the specification.

Example 50 includes a method performed at an E2 node as shown and described in the specification.

Any of the above examples can be combined with any other example (or combination of examples) unless explicitly stated otherwise. The foregoing description of one or more implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments.

Term(s) for

For purposes of this document, the following terms and definitions apply to the examples and embodiments discussed herein.

The term "application" may refer to a complete and deployable grouping, environment in which particular functionality is implemented in an operating environment. The term "AI/ML application" or the like can be an application that contains some AI/ML models and application level descriptions.

The term "machine learning" or "ML" refers to the use of a computer system that implements algorithms and/or statistical models to perform a particular task(s) without the use of explicit instructions, but instead relying on patterns and inferences. ML algorithms build or estimate mathematical model(s) (referred to as "ML model" or the like) based on sample data (referred to as "training data," "model training information," or the like) in order to make predictions or decisions without being explicitly programmed to perform such tasks. In general, an ML algorithm is a computer program that learns about certain tasks and certain performance metrics from experience, and an ML model may be any object or data structure that is created after the ML algorithm is trained using one or more training data sets. After training, the new data set may be predicted using the ML model. Although the term "ML algorithm" refers to a different concept than the term "ML model," for purposes of this disclosure, these terms as discussed herein may be used interchangeably.

The terms "machine learning model," "ML model," and the like may also refer to ML methods and concepts used by ML-aided solutions. The "ML assistance solution" is a solution that uses an ML algorithm to solve a specific use case during operation. The ML models include supervised learning (e.g., linear regression, K-nearest neighbor (KNN), decision tree algorithms, support machine vectors, bayesian algorithms, ensemble algorithms, etc.), unsupervised learning (e.g., K-means clustering, principal Component Analysis (PCA), etc.), reinforcement learning (e.g., Q-learning, dobby tiger learning, deep RL, etc.), neural networks, and the like. Depending on the implementation, a particular ML model may have many submodels as components, and the ML model may train all of the submodels together. During reasoning, separately trained ML models can also be linked together in the ML pipeline. An "ML pipe" is a set of functionalities, functions or functional entities that are specific to an ML assistance solution; the ML pipeline may include one or several data sources of a data pipeline, a model training pipeline, a model evaluation pipeline, and participants. "participants" are entities that host the ML assistance solution using the output of ML model inference. The term "ML training host" refers to a trained entity that hosts a model, such as a network function. The term "ML inference host" refers to an entity that hosts a model during an inference mode, such as a network function (including both model execution and any online learning, if applicable). The ML host notifies the participant of the output of the ML algorithm, and the participant makes a decision on some action (some "action" is performed by the participant as a result of the output of the ML assistance solution). The term "model inference information" refers to information that is used as input to the ML model to determine inference(s); the data used to train the ML model and the data used to determine inferences may overlap, but "training data" and "inferencing data" refer to different concepts.

The term "circuitry" as used herein refers to, is part of, or includes hardware components, such as electronic circuitry, logic circuitry, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group), an Application Specific Integrated Circuit (ASIC), a Field Programmable Device (FPD) (e.g., a Field Programmable Gate Array (FPGA), a Programmable Logic Device (PLD), a Complex PLD (CPLD), a high-capacity PLD (HCPLD), a structured ASIC, or a programmable SoC), a Digital Signal Processor (DSP), and so forth, that are configured to provide the described functionality. In some embodiments, the circuitry may execute one or more software or firmware programs to provide at least some of the described functionality. The term "circuitry" may also refer to a combination of one or more hardware elements and program code for performing the functions of the program code (or a combination of circuitry and the program code for use in an electrical or electronic system). In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuitry.

As used herein, the term "processor circuit" refers to, is part of, or includes circuitry capable of sequentially and automatically performing a series of arithmetic or logical operations, or recording, storing and/or transmitting digital data. The processing circuitry may include one or more processing cores for executing instructions and one or more memory structures for storing program and data information. The term "processor circuit" may refer to one or more application processors, one or more baseband processors, physical Central Processing Units (CPUs), single-core processors, dual-core processors, triple-core processors, quad-core processors, and/or any other device capable of executing or otherwise operating computer-executable instructions (e.g., program code, software modules, and/or functional processes). The processing circuitry may include further hardware accelerators, which may be microprocessors, programmable processing devices, etc. The one or more hardware accelerators may include, for example, computer Vision (CV) and/or Deep Learning (DL) accelerators. The terms "application circuitry" and/or "baseband circuitry" may be considered synonyms for "processor circuitry" and may be referred to as "processor circuitry".

As used herein, the term "interface circuit" refers to, is part of, or includes a circuit that enables the exchange of information between two or more components or devices. The term "interface circuit" may refer to one or more hardware interfaces, such as a bus, an I/O interface, a peripheral component interface, a network interface card, and the like.

As used herein, the term "user equipment" or "UE" refers to a device having radio communication capabilities and may describe a remote user of network resources in a communication network. The term "user equipment" or "UE" may be considered synonymous with, and may be referred to as: a client, a mobile terminal, a mobile device, a mobile terminal, a user terminal, a mobile unit, a mobile station, a mobile user, a subscriber, a user, a remote station, an access agent, a user agent, a receiver, a radio, a reconfigurable mobile, and the like. Further, the terms "user equipment" or "UE" may include any type of wireless/wireline device or any computing device with a wireless communication interface.

As used herein, the term "network element" refers to a physical or virtualized device and/or infrastructure for providing wired or wireless communication network services. The term "network element" may be considered synonymous with, and/or referred to as: a networking computer, networking hardware, network device, network node, router, switch, hub, bridge, radio network controller, RAN device, RAN node, gateway, server, virtualized VNF, NFVI, etc.

As used herein, the term "computer system" refers to any type of interconnected electronic devices, computer devices, or components thereof. Furthermore, the terms "computer system" and/or "system" may refer to various components of computers that are communicatively coupled to each other. Moreover, the terms "computer system" and/or "system" may refer to multiple computer devices and/or multiple computing systems communicatively coupled to one another and configured to share computing and/or networking resources.

As used herein, the terms "appliance," "computer appliance," and the like refer to a computer device or computer system having program code (e.g., software or firmware) specifically designed to provide specific computing resources. A "virtual appliance" is a virtual machine image to be implemented by a hypervisor-equipped device that virtualizes or emulates a computer appliance or is otherwise dedicated to providing specific computing resources.

As used herein, the term "resource" refers to a physical or virtual device, a physical or virtual component within a computing environment, and/or a physical or virtual component within a particular device, such as a computer device, a mechanical device, a memory space, processor/CPU time, processor/CPU usage, processor and accelerator load, hardware time or usage, power, input/output operations, ports or network sockets, channel/link assignments, throughput, memory usage, storage, networks, databases and applications, workload units, and the like. "hardware resources" may refer to computing, storage, and/or network resources provided by physical hardware element(s). "virtualized resources" may refer to computing, storage, and/or network resources provided by a virtualization infrastructure to an application, device, system, etc. The term "network resource" or "communication resource" may refer to a resource accessible by a computer device/system via a communication network. The term "system resource" may refer to any type of shared entity that provides a service, and may include computing and/or network resources. A system resource may be viewed as a coherent set of functions, network data objects, or services, accessible through a server, where such system resources reside on a single host or multiple hosts and may be clearly identified.

As used herein, the term "channel" refers to any tangible or intangible transmission medium used to communicate data or streams. The term "channel" may be synonymous and/or equivalent to "communication channel," "data communication channel," "transmission channel," "data transmission channel," "access channel," "data access channel," "link," "data link," "carrier," "radio frequency carrier," and/or any other similar term denoting the path or medium through which data is communicated. Further, as used herein, the term "link" refers to a connection between two devices over a RAT for sending and receiving information.

As used herein, the terms "instance," "instantiation," and the like refer to the creation of an instance. An "instance" also refers to a specific occurrence of an object, which may occur, for example, during execution of program code.

The terms "couple," "communicatively coupled," and derivatives thereof are used herein. The term "coupled" may mean that two or more elements are in direct physical or electrical contact with each other, that two or more elements are in indirect contact with each other, but yet still co-operate or interact with each other, and/or that one or more other elements are coupled or connected between what is said to be coupled to each other. The term "directly coupled" may mean that two or more elements are in direct contact with each other. The term "communicatively coupled" may mean that two or more elements may be in contact with each other via communications means, including by a wired or other interconnection, by a wireless communications channel or link, or the like.

The term "information element" refers to a structural element that contains one or more fields. The term "field" refers to the individual content of an information element, or a data element containing content.

The term "SMTC" refers to an SSB-based measurement timing configuration configured by an SSB-measurementtimingtonfiguration.

The term "SSB" refers to the SS/PBCH block.

The term "primary cell" refers to an MCG cell, operating on a primary frequency, in which a UE performs an initial connection establishment procedure or initiates a connection re-establishment procedure.

The term "primary SCG cell" refers to an SCG cell in which a UE performs random access when performing reconfiguration of a synchronization procedure for DC operation.

The term "secondary cell" refers to a cell that provides additional radio resources above a particular cell for a UE configured with CA.

The term "secondary cell group" refers to a subset of serving cells, including pscells and zero or more secondary cells for DC-configured UEs.

The term "serving cell" refers to a primary cell for a UE in RRC _ CONNECTED that is not configured with CA/DC, and only one serving cell includes the primary cell.

The term "serving cell" or "serving cells" refers to a group of cells, including special cell(s) and all secondary cells for UEs in RRC _ CONNECTED configured with CA/DC.

The term "special cell" refers to the PCell of the MCG or the PSCell of the SCG for DC operation; otherwise, the term "special cell" refers to Pcell.

Although certain embodiments have been illustrated and described herein for purposes of description, a wide variety of alternate and/or equivalent embodiments or implementations may be substituted for the embodiments shown and described to achieve the same purposes without departing from the scope of the present disclosure. This application is intended to cover any adaptations or variations of the embodiments discussed herein. Therefore, it is manifestly intended that the embodiments described herein be limited only by the following claims and equivalents thereof.

Claims (25)

1. An apparatus for use in a Radio Access Network (RAN) intelligent controller (RIC), wherein the apparatus comprises a processor circuit configured to cause the RIC to:

establishing an E2 application protocol (E2 AP) RIC subscription process with an E2 node;

determining to modify E2AP RIC subscription details; and

establishing an enhanced E2AP RIC subscription procedure with the E2 node to support modification of the E2AP RIC subscription details.

2. The apparatus of claim 1, wherein the E2AP RIC subscription procedure comprises one or more of: RIC request ID, RAN function ID, and/or subscription details.

3. The apparatus of claim 1, wherein the enhanced E2AP RIC subscription procedure comprises one or more of: the RIC request ID, RAN function ID, and/or modified subscription details.

4. The apparatus of claim 3, wherein establishing the enhanced E2AP RIC subscription procedure with the E2 node comprises sending a message with the RIC request ID, the RAN function ID, and/or the modified subscription details.

5. The apparatus of claim 3 or 4, wherein the modified subscription details comprise one or more of: an updated event trigger definition, a list of one or more actions to be newly added, a list of one or more actions to be modified, a list of one or more actions to be deleted, an updated RIC Subsequent Action Type, and/or an updated RIC Time to Wait.

6. The apparatus of claim 5, wherein the modified subscription details further comprise one or more of: updating a reason defined by the event trigger, deleting a reason for the one or more actions, updating a reason for the RIC Subsequent Action Type, and/or updating a reason for the RIC Time to Wait.

7. The apparatus of claim 1, wherein the RIC is a near real time (near RT) RIC in which a plurality of Artificial Intelligence (AI) or Machine Learning (ML) models are trained and used.

8.An apparatus for use in a Radio Access Network (RAN) intelligent controller (RIC), wherein the apparatus comprises a processor circuit configured to cause the RIC to:

establishing an E2 application protocol (E2 AP) RIC subscription process with an E2 node;

determining to modify E2AP RIC subscription details; and

establishing a new E2AP RIC subscription modification procedure with the E2 node to support modification of the E2AP RIC subscription details.

9. The apparatus of claim 8, wherein the E2AP RIC subscription procedure comprises one or more of: the RIC request ID, RAN function ID, and/or subscription details.

10. The apparatus of claim 8, wherein the new E2AP RIC subscription modification procedure comprises one or more of: the RIC request ID, RAN function ID, and/or modified subscription details.

11. The apparatus of claim 10, wherein establishing the new E2AP RIC subscription modification procedure with the E2 node comprises sending a message with the RIC request ID, the RAN functionality ID, and/or the modified subscription details.

12. The apparatus of claim 10 or 11, wherein the modified subscription details comprise one or more of: an updated event trigger definition, a list of one or more actions to be newly added, a list of one or more actions to be modified, a list of one or more actions to be deleted, an updated RIC Subsequent Action Type, and/or an updated RIC Time to Wait.

13. The apparatus of claim 12, wherein the modified subscription details further comprise one or more of: updating a reason defined by the event trigger, deleting a reason for the one or more actions, updating a reason for the RIC Subsequent Action Type, and/or updating a reason for the RIC Time to Wait.

14. The apparatus of claim 8, wherein the RIC is a near real time (near RT) RIC in which a plurality of Artificial Intelligence (AI) or Machine Learning (ML) models are trained and used.

15. An apparatus for use in an E2 node, wherein the apparatus comprises a processor circuit configured to cause the E2 node to:

establishing an E2 application protocol (E2 AP) Radio Access Network (RAN) Intelligent controller (RIC) RIC subscription procedure with a RAN Intelligent Controller (RIC);

determining to request modification of E2AP RIC subscription details;

establishing a new E2AP RIC subscription modification required procedure with the RIC in response to a request to modify the E2AP RIC subscription details; and

establishing a new E2AP RIC subscription modification procedure with the RIC in response to the establishment of the new E2AP RIC subscription modification requirement procedure to support a modification request for the E2AP RIC subscription details.

16. The apparatus of claim 15, wherein the E2AP RIC subscription procedure comprises one or more of: the RIC request ID, RAN function ID, and/or subscription details.

17. The apparatus of claim 15, wherein the new E2AP RIC subscription modification required procedure comprises one or more of: the RIC request ID, RAN function ID, and/or subscription details to be modified.

18. The apparatus of claim 17, wherein establishing the new E2AP RIC subscription modification required procedure with the RIC comprises sending a message with the RIC request ID, the RAN functionality ID, and/or the subscription details to modify.

19. The apparatus of claim 17 or 18, wherein the subscription details to be modified comprise one or more of: an event trigger definition to modify, a list of one or more actions to delete, and/or a RIC Time to Wait to modify.

20. The apparatus of claim 19, wherein the subscription details to be modified further comprise one or more of: deleting a cause of the one or more actions, and/or modifying a cause of the RIC Time to Wait.

21. The apparatus of claim 15, wherein the new E2AP RIC subscription modification procedure comprises one or more of: the RIC requests an ID, a RAN function ID, and/or modified subscription details.

22. The apparatus of claim 21, wherein establishing the new E2AP RIC subscription modification procedure with the RIC comprises receiving a message with the RIC request ID, the RAN functionality ID, and/or the modified subscription details.

23. The apparatus of claim 15, wherein the RIC is a near real time (near RT) RIC in which multiple Artificial Intelligence (AI) or Machine Learning (ML) models are trained and used.

24. A computer-readable storage medium having stored thereon computer-executable instructions, wherein the computer-executable instructions, when executed by processor circuitry of a Radio Access Network (RAN) intelligent controller (RIC), cause the RIC to:

establishing an E2 application protocol (E2 AP) RIC subscription process with an E2 node;

determining to modify E2AP RIC subscription details; and

establishing an enhanced E2AP RIC subscription procedure with the E2 node to support modification of the E2AP RIC subscription details.

25. The computer-readable storage medium of claim 24, wherein the enhanced E2AP RIC subscription process comprises one or more of: the RIC requests an ID, a RAN function ID, and/or modified subscription details.

Images