Method and apparatus for supporting RIC produced service discovery and management for ran in a wireless communication system

Abstract

　The present disclosure relates to a method and apparatus for supporting RAN Intelligence Controller (RIC) produced service discovery and management in a wireless communication system, wherein the method performed by a first node comprises: receiving, from a second node, a first message including a list of radio access network (RAN) functions of the second node; and in response to the first message, transmitting, to the second node, a second message including service information about supported services for the second node.

Description

METHOD AND APPARATUS FOR SUPPORTING RIC PRODUCED SERVICE DISCOVERY AND MANAGEMENT FOR RAN IN A WIRELESS COMMUNICATION SYSTEM

[0001] The present disclosure relates to a wireless communication system. Specifically, the present disclosure relates to method and apparatus for supporting RAN Intelligence Controller (RIC) produced service discovery and management for Radio Access Network (RAN) in a wireless communication system.

[0002]

[0003] O-RAN (Open Radio Access Network) was established in 2018 to create an open, intelligent, virtualized, and interoperable RAN ecosystem. Its mission is to transition from traditional, proprietary RAN solutions toward an open and flexible architecture [1], enabling mobile network operators to integrate equipment from different vendors and to incorporate artificial intelligence (AI) and machine learning (ML) guided intelligence into the network system. Through the standardizations of the necessary interfaces across network elements and promoting open software and hardware, O-RAN aims to foster innovation, reduce costs, and increase flexibility, supporting enhancements in 5G and future 6G networks.

[0004] The integration of AI / ML not only enhances network performance, but also enables more efficient and precise management of network functions. It allows operators to optimize various network components and steer to a certain KPI (Key Performance Indicator) of interest in an efficient and elegant manner.

[0005] The AI / ML-driven control for RAN in the order of 10 ms-1s is implemented through the E2 interface [1], which connects the Near-RT (real time) RAN Intelligent Controller (RIC) with the existing RAN node(s). The Near-RT RIC is an O-RAN network function that enables near real-time control and optimization of services and resources of RAN nodes via fine-grained data collection and actions over the E2 interface. It subscribes various RIC services (e.g. REPORT, INSERT, CONTROL, POLICY, etc.) of RAN functions supported by E2-connected RAN nodes [2], which is subject to the capability of the RAN nodes exposed over the E2 interface by means of the E2 Service Models [2].

[0006] Recently, a new RIC service called "ASSISTANCE" has been added to the family of RIC services over the E2 interface [2][3]. Unlike existing RIC services of "REPORT", "INSERT", "CONTROL", "POLICY", and "QUERY", which are based on the principle of the Near-RT RIC acting as a consumer of services provided by E2-connected RAN nodes, this new service type is produced by the Near-RT RIC itself. The ASSISTANCE service allows a RAN node, as a service consumer, to benefit from the intelligent information processing capabilities of Near-RT RIC.

[0007] This service can assist RAN nodes by providing information that is available at the Near-RT RIC level. For example, a Near-RT RIC can generate some RAN analytics based on its internal processing or the information received from other E2-connected RAN nodes or external entities via the Y1 interface [1]. Such information might include predictions of UE or network behaviours, which can help E2-connected RAN nodes optimize their radio resource management and enhance overall performance.

[0008] Moreover, AI / ML support for NG-RAN has been introduced in 3GPP from Rel-18, which specified that an NG-RAN node may support both AI / ML model training / inference, or model inference only. From O-RAN perspective, these AI / ML capabilities can be further enhanced by enabling the Near-RT to provide AI / ML model training (or re-training) as a service to E2-connected NG-RAN nodes. By consuming these services, RAN nodes can leverage more advanced model inference to enhance decision-making and operational efficiency.

[0009] While this new service type represents a significant progress in completing the AI / ML-based intelligence cycle over the E2 interface and enhancing AI / ML integration in O-RAN eco-systems, its implementation within the Near-RT RIC and over the E2 interface is still in its early stages. Specifically, it remains unclear how RAN nodes can determine whether the E2-connected Near-RT RIC entity supports this new service type and what intelligences are available for provisions, before deciding to utilize them. Moreover, once a requested ASSISTANCE service is accepted, there is no mechanism for the Near-RT RIC to terminate the ongoing service provision to the RAN node unless explicitly requested by the RAN node. This lack of flexibility is not resilient to errors or unexpected behaviours at the Near-RT RIC. For example, if an ASSISTANCE service toward a RAN node begins to excessively drain resources or consume significant power at the Near-RT RIC, there is no mechanism for the Near-RT RIC to gracefully terminate the service. Without such method for the Near-RT RIC to initiate the removal of an accepted ASSISTANCE service, resource management and error recovery would remain challenging.

[0010] To address these challenges, this disclosure proposes mechanisms to enable RAN nodes to identify the capabilities and ASSISTANCE services offered by the Near-RT RIC, as well as to support the graceful termination of an accepted ASSISTANCE service initiated by the Near-RT RIC.

[0011] [1] O-RAN WG1, O-RAN Architecture Description

[0012] [2] O-RAN WG3, E2 General Aspects and Principles (E2GAP)

[0013] [3] O-RAN WG3, E2 Application Protocol (E2AP)

[0014]

[0015] In order to solve the above-described problems, the present disclosure provides method and apparatus for supporting RAN Intelligence Controller (RIC) produced service discovery and management for Radio Access Network (RAN) in a wireless communication system.

[0016] The technical objects to be achieved by the present disclosure are not limited to those that have been described hereinabove merely by way of example, and other technical objects that are not mentioned can be clearly understood by those skilled in the art, to which the present disclosure pertains, from the following descriptions.

[0017]

[0018] According to various embodiments of the present disclosure, there is provided a method performed by a first node. The method comprises: receiving, from a second node, a first message including a list of radio access network (RAN) functions of the second node; and in response to the first message, transmitting, to the second node, a second message including service information about supported services for the second node.

[0019] According to various embodiments of the present disclosure, there is provided a method performed by a second node. The method comprises: transmitting, to a first node, a first message including a list of RAN functions of the second node; and in response to the first message, receiving, from the first node, a second message including service information about supported services for the second node.

[0020] According to various embodiments of the present disclosure, there is provided a first node in a wireless communication system, the first node comprising a transceiver, at least one processor, and at least one memory operably connectable to the at least one processor and storing instructions performing operations based on being executed by the at least one processor, and the operations comprise all steps of a method of operating the first node according to various embodiments of the present disclosure.

[0021] According to various embodiments of the present disclosure, there is provided a second node in a wireless communication system, the second node comprising a transceiver, at least one processor, and at least one memory operably connectable to the at least one processor and storing instructions performing operations based on being executed by the at least one processor, and the operations comprise all steps of a method of operating the second node according to various embodiments of the present disclosure.

[0022] According to various embodiments of the present disclosure, there is provided a control device controlling a first node in a wireless communication system, the control device comprising at least one processor and at least one memory operably connected to the at least one processor, and the at least one memory stores instructions performing operations based on being executed by the at least one processor, and the operations comprise all steps of a method of operating the first node according to various embodiments of the present disclosure.

[0023] According to various embodiments of the present disclosure, there is provided a control device controlling a second node in a wireless communication system, the control device comprising at least one processor and at least one memory operably connected to the at least one processor, and the at least one memory stores instructions performing operations based on being executed by the at least one processor, and the operations comprise all steps of a method of operating the second node according to various embodiments of the present disclosure.

[0024] According to various embodiments of the present disclosure, there are provided one or more non-transitory computer readable mediums storing one or more instructions, and the one or more instructions perform operations based on being executed by one or more processors, and the operations comprise all steps of a method of operating a first node according to various embodiments of the present disclosure.

[0025] According to various embodiments of the present disclosure, there are provided one or more non-transitory computer readable mediums storing one or more instructions, and the one or more instructions perform operations based on being executed by one or more processors, and the operations comprise all steps of a method of operating the second node according to various embodiments of the present disclosure.

[0026]

[0027] In order to solve the above-described problems, the present disclosure can provide method and apparatus for supporting RAN Intelligence Controller (RIC) produced service discovery and management for Radio Access Network (RAN) in a wireless communication system.

[0028]

[0029] The accompanying drawings, which are included to provide a further understanding of the present disclosure and constitute a part of the detailed description, illustrate embodiments of the present disclosure and serve to explain technical features of the present disclosure together with the description. Technical features of the present disclosure are not limited to specific drawings, and features disclosed in each drawing can be combined with each other to form a new embodiment. Reference numerals in each drawing may denote structural elements.

[0030] FIG. 1 illustrates physical channels used in a system applicable to the present disclosure and an example of a general signal transmission method using the physical channels.

[0031] FIG. 2 illustrates an example of a structure of a radio frame used in a system applicable to the present disclosure.

[0032] FIG. 3 illustrates an example of a slot structure used in a system applicable to the present disclosure.

[0033] FIG. 4 illustrates an example of a slot structure of a radio frame used in a system applicable to the present disclosure.

[0034] FIG. 5 illustrates Figure 5.1-1: High Level Architecture of O-RAN.

[0035] FIG. 6 illustrates Figure 5.1-2: Logical Architecture of O-RAN.

[0036] FIG. 7 illustrates Figure 5.1-3: Uu interface for O-RAN Network Functions and O-eNB.

[0037] FIG. 8 illustrates Figure 5.2-1: O-RAN Control Loops.

[0038] FIG. 9 illustrates Figure 5.3-1: SMOSs in the SMO SBA representation.

[0039] FIG. 10 illustrates Figure 5.3-2: SMO external terminations.

[0040] FIG. 11 illustrates Figure 5.3-3: Service-based representation of the Near-RT RIC

[0026] .

[0041] FIG. 12 illustrates Figure 4.2-1: O-RAN architecture overview showing Near-RT RIC interfaces.

[0042] FIG. 13 illustrates Figure 5.1.2-1: Relationship between Near-RT RIC and E2 Node.

[0043] FIG. 14 illustrates Figure 5.3.2.2-1: RIC Service REPORT.

[0044] FIG. 15 illustrates Figure 5.3.2.3-1: RIC Service INSERT with subsequent RIC Service CONTROL responses.

[0045] FIG. 16 illustrates Figure 5.3.2.4-1: RIC Service CONTROL as response to RIC Service INSERT.

[0046] FIG. 17 illustrates Figure 5.3.2.4-2: RIC Service CONTROL initiated by NEAR-RT RIC.

[0047] FIG. 18 illustrates Figure 5.3.2.5-1: RIC Service POLICY.

[0048] FIG. 19 illustrates Figure 5.3.2.5A-1: RIC Service QUERY.

[0049] FIG. 20 illustrates Figure 5.3.2.5B-1: RIC Service ASSISTANCE.

[0050] FIG. 21 illustrates Figure 5.3.2.6-1: RIC Subscription, RIC Subscription Modification, RIC Subscription Delete, RIC Subscription Audit and RIC Subscription State Control procedures.

[0051] FIG. 22 illustrates Figure 5.3.2.6-2: RIC Subscription Delete Required and RIC Subscription Delete procedures.

[0052] FIG. 23 illustrates Figure 5.3.2.6-3: RIC Subscription Modification Required procedure.

[0053] FIG. 24 illustrates Figure 5.3.2.6-4: RIC Service Load Status and RIC Service Load Update procedures.

[0054] FIG. 25 illustrates Figure 5.5.2-1: E2 Setup procedure.

[0055] FIG. 26 illustrates Figure 5.5.3-1: Reset procedure (E2 Node initiated).

[0056] FIG. 27 illustrates Figure 5.5.3-2: Reset procedure (Near-RT RIC initiated).

[0057] FIG. 28 illustrates Figure 5.5.4-1: RIC Service Update procedure.

[0058] FIG. 29 illustrates Figure 5.5.4A-1: RIC Service Query procedure.

[0059] FIG. 30 illustrates Figure 5.5.5-1: E2 Node Configuration Update procedure.

[0060] FIG. 31 illustrates Figure 5.5.6-1: E2 Removal procedure (E2 Node initiated).

[0061] FIG. 32 illustrates Figure 5.5.6-2: E2 Removal procedure (Near-RT RIC initiated).

[0062] FIG. 33 illustrates Figure 5.5.7-1: E2 Resource Status procedure.

[0063] FIG. 34 illustrates Figure 5.5.8-1: E2 Resource Status Update procedure.

[0064] FIG. 35 illustrates Figure 6.1-1: E2AP protocol stack.

[0065] FIG. 36 illustrates Figure 8.2.11.2-1: RIC Assistance procedure, successful operation.

[0066] FIG. 37 illustrates Figure 8.2.11.3-1: RIC Assistance procedure, unsuccessful operation.

[0067] FIG. 38 illustrates Figure 8.2.12.2-1: RIC Assistance Indication procedure, successful operation.

[0068] FIG. 39 illustrates Figure 8.2.13.2-1: RIC Assistance Halt procedure, successful operation.

[0069] FIG. 40 illustrates Figure 8.3.1.2-1: E2 Setup procedure, successful operation.

[0070] FIG. 41 illustrates Figure 8.3.1.3-1: E2 Setup procedure, unsuccessful operation.

[0071] FIG. 42 illustrates Figure 8.3.2.2-1: Reset, successful operation (E2 Node Initiated).

[0072] FIG. 43 illustrates Figure 8.3.2.2-2: Reset, successful operation (Near-RT RIC Initiated).

[0073] FIG. 44 illustrates Figure 8.3.3.2-1: Error Indication, (E2 Node initiated) successful operation.

[0074] FIG. 45 illustrates Figure 8.3.3.2-2: Error Indication, (Near-RT RIC Initiated) successful operation.

[0075] FIG. 46 illustrates Figure 8.3.4.2-1: RIC Service Update procedure, successful operation.

[0076] FIG. 47 illustrates Figure 8.3.4.3-1: RIC Service Update procedure, unsuccessful operation.

[0077] FIG. 48 illustrates Figure 8.3.4A.2-1: RIC Service Query procedure, successful operation.

[0078] FIG. 49 illustrates RIC produced service discovery and management for RAN.

[0079] FIG. 50 illustrates an example of a process of operating a first device in a system applicable to the present disclosure.

[0080] FIG. 51 illustrates an example of a process of operating a second device in a system applicable to the present disclosure.

[0081] FIG. 52 illustrates an example of a structure of a first device and a second device in a system applicable to the present disclosure.

[0082]

[0083] In various embodiments of the present disclosure, "A or B" may mean "only A," "only B" or "both A and B." In other words, in various embodiments of the present disclosure, "A or B" may be interpreted as "A and / or B." For example, in various embodiments of the present disclosure, "A, B or C" may mean "only A," "only B," "only C" or "any combination of A, B and C."

[0084] A slash ( / ) or comma used in various embodiments of the present disclosure may mean "and / or." For example, "A / B" may mean "A and / or B." Hence, "A / B" may mean "only A," "only B" or "both A and B." For example, "A, B, C" may mean "A, B, or C."

[0085] In various embodiments of the present disclosure, "at least one of A and B" may mean "only A," "only B" or "both A and B." In addition, in various embodiments of the present disclosure, the expression of "at least one of A or B" or "at least one of A and / or B" may be interpreted in the same meaning as "at least one of A and B."

[0086] Further, in various embodiments of the present disclosure, "at least one of A, B, and C" may mean "only A," "only B," "only C" or "any combination of A, B and C." In addition, "at least one of A, B or C" or "at least one of A, B and / or C" may mean "at least one of A, B, and C."

[0087] Further, parentheses used in various embodiments of the present disclosure may mean "for example." Specifically, when "control information (PDCCH)" is described, "PDCCH" may be proposed as an example of "control information." In other words, "control information" in various embodiments of the present disclosure is not limited to "PDCCH," and "PDDCH" may be proposed as an example of "control information." In addition, even when "control information (i.e., PDCCH)" is described, "PDCCH" may be proposed as an example of "control information."

[0088] Technical features described individually in one drawing in various embodiments of the present disclosure may be implemented individually or simultaneously.

[0089]

[0090] General Signal Transmission Method in 3GPP

[0091] Physical Channels and General Signal Transmission

[0092] FIG. 1 illustrates physical channels used in a system applicable to the present disclosure and an example of a general signal transmission method using the physical channels. More specifically, FIG. 1 illustrates physical channels and general signal transmission used in the 3GPP system.

[0093] FIG. 1 illustrates physical channels and general signal transmission used in the 3GPP system. In a wireless communication system, the UE receives information from the eNB through Downlink (DL) and the UE transmits information from the eNB through Uplink (UL). The information which the eNB and the UE transmit and receive includes data and various control information and there are various physical channels according to a type / use of the information which the eNB and the UE transmit and receive.

[0094] A UE that is powered on again while being powered off or enters a new cell performs an initial cell search operation such as synchronizing with a base station (BS) in S11. To this end, the UE receives a primary synchronization channel (PSCH) and a secondary synchronization channel (SSCH) from the base station to synchronize with the base station and acquires information such as a cell identity (ID), etc. Further, the UE may receive a physical broadcast channel (PBCH) from the base station and acquire in-cell broadcast information. The UE may receive a downlink reference signal (DL RS) in an initial cell search step to check a downlink channel state.

[0095] The UE that completes the initial cell search may receive a physical downlink control channel (PDCCH) and a physical downlink shared channel (PDSCH) corresponding to the PDCCH to acquire more detailed system information, in S12.

[0096] Next, the UE may perform a random access procedure in order to complete an access to the base station, in S13 to S16. Specifically, the UE may transmit a preamble on a physical random access channel (PRACH) in S13, and receive a random access response (RAR) for the preamble on the PDCCH and the PDSCH corresponding to the PDCCH in S14. Thereafter, the UE may transmit a physical uplink shared channel (PUSCH) using scheduling information within the RAR in S15, and perform a contention resolution procedure such as the PDCCH and the PDSCH corresponding to the PDCCH in S16.

[0097] Next, the UE that performs the above-described procedure may perform PDCCH / PDSCH reception S17 and PUSCH / physical uplink control channel (PUCCH) transmission S18, as a general uplink / downlink signal transmission procedure. Control information that the UE transmits to the base station is referred to as uplink control information (UCI). The UCI includes hybrid automatic repeat and request (HARQ) acknowledgement / negative ACK (ACK / NACK), scheduling request (SR), channel state information (CSI), etc. The CSI includes a channel quality indication (CQI), a precoding matrix indicator (PMI), a rank indicator (RI), etc. The UCI is generally transmitted on the PUCCH, but if control information and data need to be transmitted at the same time, the UCI may be transmitted on the PUSCH. The UE may aperiodically transmit the UCI on the PUSCH based on a request / indication of the network.

[0098]

[0099] Orthogonal Frequency Division Multiplexing (OFDM) Numerology

[0100] A new RAT system uses an OFDM transmission scheme or a similar transmission scheme thereto. The new RAT system may follow different OFDM parameters from OFDM parameters of LTE. Alternatively, the new RAT system may follow numerology of existing LTE / LTE-A as it is but have a larger system bandwidth (e.g., 100 MHz). Alternatively, one cell may support a plurality of numerologies. In other words, UEs that operate with different numerologies may coexist in one cell.

[0101]

[0102] Radio Frame Structure

[0103] FIG. 2 illustrates an example of a structure of a radio frame used in a system applicable to the present disclosure.

[0104] In NR, uplink and downlink transmission consists of frames. A radio frame has a length of 10 ms and is defined as two 5 ms half-frames (HFs). The half-frame is defined as five 1 ms subframes (SFs). The subframe is split into one or more slots, and the number of slots in the subframe depends on a subcarrier spacing (SCS). Each slot includes 12 or 14 OFDM(A) symbols depending on a cyclic prefix (CP). When a normal CP is used, each slot includes 14 symbols. When an extended CP is used, each slot includes 12 symbols. The symbol may include an OFDM symbol (or CP-OFDM symbol) and an SC-FDMA symbol (or DFT-s-OFDM symbol).

[0105] Table 1 shows that when the normal CP is used, the number of symbols per slot, the number of slots per frame, and the number of slots per subframe vary depending on the SCS.

[0106] SCS (15*2^u)NslotsymbNframe,uslotNsubframe,uslot15KHz (u=0)1410130KHz (u=1)1420260KHz (u=2)14404120KHz (u=3)14808240KHz (u=4)1416016

[0107] Nslotsymbis the number of symbols in the slot. Nframe,uslotis the number of slots in the frame. Nsubframe,uslotis the number of slots in the subframe.

[0108] Table 2 shows that when the extended CP is used, the number of symbols per slot, the number of slots per frame, and the number of slots per subframe vary depending on the SCS.

[0109] SCS (15*2^u)NslotsymbNframe,uslotNsubframe,uslot60KHz (u=2)12404

[0110] The NR supports multiple numerologies (or subcarrier spacing (SCS)) for supporting diverse 5G services. For example, when the SCS is 15 kHz, a wide area in traditional cellular bands is supported, when the SCS is 30 kHz / 60 kHz, dense-urban, lower latency, and wider carrier bandwidth are supported, and when the SCS is 60 kHz or more, a bandwidth larger than 24.25 GHz is supported to overcome phase noise. An NR frequency band may be defined as two types of frequency ranges (FR1 and FR2). Values of the frequency ranges may be changed, and, for example, the two types of frequency ranges (FR1 and FR2) may be as shown in Table 3 below. For convenience of description, among frequency ranges used in an NR system, FR1 may denote "sub 6GHz range", and FR2 may denote "above 6GHz range" and may be referred to as millimeter wave (mmW).

[0111] Frequency Range DesignationCorresponding Frequency RangeSubcarrier SpacingFR1450MHz - 6000MHz15, 30, 60kHzFR224250MHz - 52600MHz60, 120, 240kHz

[0112] As described above, the values of the frequency ranges in the NR system may be changed. For example, FR1 may include a frequency band from 410 MHz to 7125 MHz, as shown in Table 4 below. That is, FR1 may include a frequency band of 6 GHz (or 5850, 5900, 5925 MHz, etc.) or higher. For example, the frequency band of 6 GHz (or 5850, 5900, 5925 MHz, etc.) or higher included in FR1 mat include an unlicensed band. The unlicensed band may be used for diverse purposes, for example, used for communication for vehicles (e.g., self-driving).

[0113] Frequency Range DesignationCorresponding Frequency RangeSubcarrier SpacingFR1410MHz - 7125MHz15, 30, 60kHzFR224250MHz - 52600MHz60, 120, 240kHz

[0114] In the NR system, OFDM(A) numerology (e.g., SCS, CP length, etc.) may be differently configured between a plurality of cells merged into one UE. Hence, an (absolute time) duration of a time resource (e.g., SF, slot or TTI) (for convenience, collectively referred to as a time unit (TU)) consisting of the same number of symbols may be configured differently between the merged cells.

[0115] FIG. 3 illustrates an example of a slot structure used in a system applicable to the present disclosure.

[0116] A slot includes a plurality of symbols in a time domain. For example, one slot includes 7 symbols in a normal CP, while one slot includes 6 symbols in an extended CP. A carrier includes a plurality of subcarriers in a frequency domain. A resource block (RB) is defined as a plurality of (e.g., 12) consecutive subcarriers in the frequency domain. A bandwidth part (BWP) is defined as a plurality of consecutive (P)RBs in the frequency domain and may correspond to one numerology (e.g., SCS, CP length, etc.). The carrier may include up to N (e.g., 5) BWPs. The data communication may be performed through an activated BWP, and only one BWP may be activated in one UE. In a resource grid, each element is referred to as a resource element (RE), and one complex symbol may be mapped to each RE.

[0117]

[0118] FIG. 4 illustrates an example of a slot structure of a radio frame used in a system applicable to the present disclosure.

[0119] More specifically, FIG. 4 illustrates a slot structure of a frame of the NR system as an exemplary system.

[0120] As illustrated in FIG. 4, a frame structure of NR is characterized by a self-contained structure in which all of DL control channel, DL or UL data, UL control channel, etc. can be included in one slot. In this instance, DL data scheduling information, UL data scheduling information, etc. may be transmitted on the DL control channel, and ACK / NACK information for DL data, CSI information (modulation and coding scheme information, MIMO transmission related information, etc.), scheduling request, etc. may be transmitted on the UL control channel. In FIG. 4, a time gap for DL-to-UL or UL-to-DL switching may exist between a control region and a data region. Further, a part of the DL control channel / DL data / UL data / UL control channel may not be configured within one slot. Alternatively, order of the channels constituting one slot may vary. (e.g., DL control / DL data / UL control / UL data or UL control / UL data / DL control / DL data, etc.)

[0121] BACKGROUND

[0122] O-RAN Architecture Description v13.00:

[0123] 2.3 Definitions and Abbreviations

[0124] 2.3.1 Definitions

[0125] For the purposes of the present document, the terms and definitions given in 3GPP TR　21.905　[i.1] and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP TR　21.905 [i.1].

[0126] E2 Node: A logical node terminating E2 interface.

[0127] Managed Element: The definition of a Managed Element (ME) is given in 3GPP TS 28.622 [2], Clause 4.3.3.

[0128] Managed Function: The definition of a Managed Function (MF) is given in 3GPP TS 28.622 [2], Clause 4.3.4.

[0129] Near-Real-Time RAN Intelligent Controller: An O-RAN Network Function (NF) comprised of the Near-RT RIC platform and Near-RT RIC Applications (xApps).

[0130] Near-RT RIC APIs: A set of service-based interfaces that can be produced and consumed by the Near-RT RIC Platform and xApps.

[0131] NOTE: Please refer to

[0026] for more information.

[0132] Near-RT RIC platform: Platform supporting A1, E2, Y1 and O1 interfaces and providing a set of services via Near-RT RIC APIs needed for xApp functionality.

[0133] Non-Real-Time RAN Intelligent Controller: A functionality within SMO comprised of the Non-RT RIC Framework and the Non-RT RIC Applications (rApps) that manages the content carried across the A1 interface.

[0134] NOTE: Please refer to

[0027] for more information.

[0135] Non-RT RIC Framework: A functionality within the Non-RT RIC that logically terminates the A1 interface and provides support for rApps, including the R1 services through the R1 interface.

[0136] NMS: A Network Management System for the O-RU as specified in

[0024] to support legacy Open Fronthaul M-Plane deployments (prior to version 5 of

[0024] ).

[0137] O-Cloud: Cloud platform that provides O-RAN standardized interfaces, hosting O-RAN defined software components.

[0138] NOTE: Please refer to [i.3] for more information.

[0139] O-eNB: An O-RAN eNB [4] or O-RAN ng-eNB [8].

[0140] NOTE: Please refer to Clause 5.3.7 for more information.

[0141] O-RAN Central Unit - Control Plane: A logical node hosting the RRC and the control plane part of the PDCP protocol.

[0142] NOTE: Please refer to Clause 5.3.3 for more information.

[0143] O-RAN Central Unit - User Plane: A logical node hosting the user plane part of the PDCP protocol and the SDAP protocol.

[0144] NOTE: Please refer to Clause 5.3.4 for more information.

[0145] O-RAN Distributed Unit: A logical node hosting RLC / MAC / High-PHY layers based on a lower layer functional split.

[0146] NOTE: Please refer to Clause 5.3.5 for more information.

[0147] O-RAN Network Function: A network function with O-RAN defined behaviors and interfaces, which can also inherit and / or extend defined behaviors and interfaces of a Network Function defined in 3GPP TS 23.501 [1].

[0148] O-RAN node: Same as an O-RAN NF.

[0149] O-RAN Radio Unit: A logical node hosting Low-PHY layer and RF processing based on a lower layer functional split. This is similar to 3GPP's "TRP" or "RRH" but more specific in including the Low-PHY layer (FFT / iFFT, PRACH extraction).

[0150] NOTE: Please refer to Clause 5.3.6 for more information.

[0151] O1: Interface used by the SMO framework, as specified in Clause 5.3.1, for operation and management of O-RAN NFs as specified in OAM Interface Specification

[0031] .

[0152] O2: Interface between SMO framework as specified in Clause 5.3.1 and the O-Cloud.

[0153] NOTE: Please refer to

[0033] for more information.

[0154] Open Fronthaul M-Plane: Management interface controlling the O-RU, generally driven from the O-DU but in the case of the hybrid topology also driven from the SMO.

[0155] NOTE: Please refer to

[0024] for more details.

[0156] rApp: Modular application that consumes and / or produces non real time management and automation services.

[0157] R1 Interface: A service-based interface between the rApps and the Non-RT RIC Framework via which R1 services can be produced and consumed.

[0158] NOTE: Please refer to

[0035] for more information

[0159] SMO: A Service Management and Orchestration framework.

[0160] NOTE: Please refer to Clause 5.3.1 for more details.

[0161] SMO External Interface: The interface between the SMO and an SMO External System.

[0162] SMO External System: A data source outside the O-RAN domain that provides data to the SMO.

[0163] NOTE: External consumers of SMO data are not addressed in the present document.

[0164] SMO Functions (SMOFs): Internal SMO entities which provide one or more SMO Services.

[0165] NOTE: An SMO Function exposes standardized interfaces which enable interoperability between SMO Functions.

[0166] SMO Service (SMOS): Standardized cohesive set of management, orchestration and automation capabilities offered by an SMO Function.

[0167] xApp: An application consuming and / or producing Near-RT RIC services via the Near-RT RIC API to provide value added control of, or guidance to the E2 Nodes.

[0168] Y1: An interface over which RAN analytics services are exposed by the Near-RT RIC to be consumed by Y1 consumers.

[0169] Y1 consumers: A role played by entities within or outside of the PLMN trust domain that consumes the Y1 services produced by the Near-RT RIC.

[0170] 2.3.2 Abbreviations

[0171] For the purposes of the present document, the abbreviations given in 3GPP TR　21.905 [i.1] and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 3GPP TR　21.905 [i.1].

[0172]

[0173] 4G 4th Generation of mobile communications

[0174] 5G 5th Generation of mobile communications

[0175] 3GPP 3rd Generation Partnership Project

[0176] 5GC 5G Core

[0177] 5GS 5G System

[0178] AAL Accelerator Abstraction Layer

[0179] API Application Programing Interface

[0180] AI Artificial Intelligence

[0181] AMF Access and Mobility Functions

[0182] CM Configuration Management

[0183] CMTS Cable Modem Termination System

[0184] CP Control Plane

[0185] CSP Communications Service Provider

[0186] CTI Cooperative Transport Interface

[0187] CUS Control User Synchronization

[0188] DC Dual Connectivity

[0189] DOCSIS Data Over Cable Service Interface Specification

[0190] DM Data Model

[0191] DME Data Management and Exposure

[0192] DTLS Datagram Transport Layer Security

[0193] E-UTRA Evolved Universal Terrestrial Radio Access

[0194] E-UTRAN Evolved Universal Terrestrial Radio Access Network

[0195] EN-DC E-UTRAN New Radio - Dual Connectivity

[0196] eNB evolved Node B

[0197] EPC Evolved Packet Core

[0198] FCAPS Fault, Configuration, Accounting, Performance, Security

[0199] FFT Fast Fourier Transform

[0200] FHGW Fronthaul Gateway

[0201] FHM Fronthaul Multiplexer

[0202] FM Fault Management

[0203] gNB next generation Node B

[0204] gNB-CU gNB Central Unit

[0205] gNB-DU gNB Distributed Unit

[0206] GUAMI Globally Unique AMF Identifier

[0207] GUMMEI Globally Unique MME Identifier

[0208] HARQ Hybrid Automatic Repeat Request

[0209] ID Identifier

[0210] iFFT inverse Fast Fourier Transform

[0211] IM Information Model

[0212] IPSec Internet Protocol Security

[0213] LLS Lower Layer Split

[0214] LTE Long Term Evolution

[0215] MAC Media Access Control

[0216] ME Managed Element

[0217] MeNB Master eNB

[0218] MF Managed Function

[0219] ML Machine Learning

[0220] MME Mobility Management Entity

[0221] Near-RT RIC Near-Real-Time RAN Intelligent Controller

[0222] NETCONF Network Configuration Protocol

[0223] NF Network Function

[0224] NG Next Generation

[0225] NG-RAN Next Generation RAN

[0226] NGAP Next Generation Application Protocol

[0227] NIST National Institute of Standards and Technology

[0228] NMS Network Management System

[0229] Non-RT RIC Non-Real-Time RAN Intelligent Controller

[0230] NR 5G New Radio

[0231] O-Cloud O-RAN Cloud

[0232] O-CU-CP O-RAN Central Unit - Control Plane.

[0233] O-CU-UP O-RAN Central Unit - User Plane

[0234] O-DU O-RAN Distributed Unit

[0235] O-eNB O-RAN eNB

[0236] O-RU O-RAN Radio Unit

[0237] OAM Operations, Administration and Maintenance

[0238] OLT Optical Line Terminal

[0239] ONU Optical Network Unit

[0240] Open FH Open Fronthaul

[0241] PDCP Packet Data Convergence Protocol

[0242] PHY Physical layer

[0243] PKI Public Key Infrastructure

[0244] PKIX Public Key Infrastructure (X.509)

[0245] PM Performance Management

[0246] PNF Physical Network Function

[0247] PON Passive Optical Network

[0248] PRACH Physical Random Access Channel

[0249] PTP Precision Time Protocol

[0250] RAN Radio Access Network

[0251] rApp Non-RT RIC Application

[0252] RIC RAN Intelligent Controller

[0253] RF Radio Frequency

[0254] RLC Radio Link Control

[0255] RRC Radio Resource Control

[0256] RRH Remote Radio Head

[0257] RRU Remote Radio Unit

[0258] RT Real Time

[0259] RU Radio Unit

[0260] SBA Service Based Architecture

[0261] SBOM Software Bill of Materials

[0262] SDAP Service Data Adaptation Protocol

[0263] SME Service Management and Exposure

[0264] SMO Service Management and Orchestration

[0265] SMOF Service Management and Orchestration Function

[0266] SMOS Service Management and Orchestration Service

[0267] SRB Signalling Radio Bearer

[0268] SSHv2 Secure Shell 2.0

[0269] TLS Transport Layer Security

[0270] TN Transport Node

[0271] TR Technical Report

[0272] TRP Transmission and Reception Point

[0273] TS Technical Specification

[0274] TU Transport Unit

[0275] UE User Equipment

[0276] UL Up Link

[0277] UP User Plane

[0278] UPF User Plane Function

[0279] WG Working Group

[0280] xApp Near-RT RIC Application

[0281] X2AP X2 Application Protocol

[0282] XnAP Xn Application Protocol

[0283] ZTA Zero Trust Architecture

[0284] 3. O-RAN Overview

[0285] 3.1 Scope and Objectives

[0286] O-RAN activities are guided by the following objectives [i.5]:

[0287] Leading the industry towards open, interoperable interfaces, RAN virtualization, and big data and AI enabled RAN intelligence.

[0288] Maximizing the use of common-off-the-shelf hardware and merchant silicon and minimizing proprietary hardware.

[0289] Specifying APIs and interfaces, driving standards to adopt them as appropriate, and exploring open source where appropriate.

[0290] The O-RAN Architecture identifies the key functions and interfaces adopted in O-RAN.

[0291] 4. General O-RAN Architecture Principles

[0292] This clause contains the general O-RAN architecture principles as described below.

[0293] The O-RAN architecture, interface specifications, and terminology shall be consistent with 3GPP architecture, interface specifications, and terminology with additions to accommodate O-RAN specific features.

[0294] This document represents the O-RAN architecture at the time of its publication and may evolve as deemed appropriate by the O-RAN ALLIANCE.

[0295] The O-RAN architecture includes a logical representation of a Radio Access Network (RAN) which extends the 3GPP specified RAN and consists of logical NFs or logical nodes (as per 3GPP TS 38.300 [8] and TR 21.905 [i.1]).

[0296] NOTE: Therefore, the terms O-RAN NFs as well as O-RAN nodes are used interchangeably to refer to some of the logical O-RAN entities, according to the context used in that particular statement. In any case, they always refer to a logical entity and not to a physical or cloudified instantiation of an O-RAN NF or an O-RAN node.

[0297] 5. O-RAN Architecture

[0298] 5.1 Overall Architecture of O-RAN

[0299] FIG. 5 illustrates Figure 5.1-1: High Level Architecture of O-RAN.

[0300] Figure 5.1-1 below provides a high-level view of the O-RAN architecture. It shows that the interfaces - A1, O1, Open Fronthaul M-plane and O2 - connecting SMO (Service Management and Orchestration) framework to O-RAN Network Functions and to O-Cloud. As depicted in this figure, the O-Cloud includes the O-Cloud Notification interface

[0028] which is available for the relevant O-RAN Network Functions (i.e., Near-RT RIC, O-CU-CP, O-CU-UP and O-DU) to receive O-Cloud related notifications.

[0301] Figure 5.1-1 below also illustrates that the O-RAN Network Functions can be hosted on the O-Cloud or on customized hardware.

[0302] All O-RAN NFs, except O-RU, are managed via the O1 interface to an authorized SMO framework.

[0303] The O1 interface exposes management services for the O-RAN NFs that are managed individually or together, as specified in the OAM Architecture specification

[0034] .

[0304] The Open Fronthaul M-plane interface, between SMO and O-RU, supports the O-RU management in hybrid mode, as specified in

[0024] .

[0305] O-RAN NFs instantiated on the O-Cloud may utilize the APIs exposed by the Accelerator Abstraction Layer (AAL) defined in

[0029] .

[0306] The Near-RT RIC O-RAN NF in figure below provides RAN analytics information services via the Y1 service interface

[0039] . These services can be consumed by Y1 consumers after mutual authentication and authorization by subscribing to or requesting the RAN analytics information via the Y1 service interface. Y1 consumers role can be played by entities which are within an PLMN trusted domain. Y1 consumers outside the PLMN trusted domain may use Y1 services in a secure manner via an exposure function, e.g., as in 3GPP TS 23.501, Clause 5.20 [1]. The framework for mutual authentication and authorization between Y1 consumers and the Near-RT RIC is not supported in the present document.

[0307] FIG. 6 illustrates Figure 5.1-2: Logical Architecture of O-RAN.

[0308] Within the logical architecture of O-RAN, as shown in Figure 5.1-2 below, the radio side includes Near-RT RIC, O-CU-CP, O-CU-UP, O-DU, and O-RU O-RAN NFs. The E2 interface connects O-eNB to Near-RT RIC. Although not shown in this figure, the O-eNB does support O-DU and O-RU O-RAN NFs with an Open Fronthaul interface between them. The Near-RT RIC, in the figure below, supports the Y1 service interface towards Y1 consumers. Y1 consumers, unlike the other network elements shown in this figure, does not denote a logical O-RAN function.

[0309] As stated earlier, the management side includes SMO Framework containing a Non-RT-RIC function. The O-Cloud, on the other hand, is a cloud computing platform comprising a collection of physical infrastructure nodes that meet O-RAN requirements to host the relevant O-RAN NFs (such as Near-RT RIC, O-CU-CP, O-CU-UP, and O-DU etc.), the supporting software components (such as Operating System, Virtual Machine Monitor, Container Runtime, etc.) and the appropriate management and orchestration functions. The virtualization of O-RU is not supported in the present document.

[0310] As shown in this figure, the O-RU provides the Open Fronthaul M-Plane interface to authorized O-DU in hierarchical mode, or to authorized O-DU and SMO in hybrid mode as specified in

[0024] and

[0034] .

[0311] NOTE: The LLS (O-DU to O-RU interface) specified in Clauses 5.3.5 and 5.3.6 (Split Option 7-2x) is the Open Fronthaul interface described in the O-RAN Open Fronthaul Specification

[0019] . Other LLS options [i.2] may be considered for reference designs when the relevant interfaces are described in specifications created by related open industry initiatives (e.g., the Small Cell Forum for Split Option 6) or in O-RAN white-box hardware specifications (e.g., Split Option 8).

[0312] FIG. 7 illustrates Figure 5.1-3: Uu interface for O-RAN Network Functions and O-eNB.

[0313] The following figure shows the Uu interface between UE and O-RAN NFs as well as between UE and O-eNB. As shown in Figure 5.1-3 below, the dotted box denotes all the O-RAN NFs required to support the Uu interface for NR. The O-eNB, on the other hand, terminates the Uu interface for LTE. Please refer to Clause 5.4.17 for more details.

[0314] 5.2 O-RAN Control Loops

[0315] FIG. 8 illustrates Figure 5.2-1: O-RAN Control Loops.

[0316] The O-RAN architecture supports at least the following control loops involving different O-RAN functionalities:

[0317] Non-RT (Non-Real Time) control loops

[0318] Near-RT (Near-Real Time) control loops

[0319] RT (Real Time) control loops

[0320] As shown in Figure 5.2-1 above, the control loops are defined based on the controlling entity and the architecture shows the other logical entities with which the control loop host interacts.

[0321] Control loops exist at various levels and run simultaneously. Depending on the use case, they may or may not interact with each other. The use cases for the Non-RT and Near-RT control loops and the interaction between the RICs for these use cases are fully defined by O-RAN Use Cases Detailed Specification

[0038] . That specification

[0038] also defines relevant interaction for the O-CU-CP and O-DU control loops, responsible for call control and mobility, radio scheduling, HARQ, beamforming etc. along with slower mechanisms involving SMO management interfaces.

[0322] The timing of these control loops is use case dependent. Typical execution time for use cases involving the Non-RT control loops are 1 second or more; Near-RT control loops are in the order of 10 milliseconds or more; control loops in the E2 Nodes can operate below 10 milliseconds. (e.g., O-DU radio scheduling).

[0323] For any specific use case, however, a stable solution would require the loop time in the Non-RT RIC and / or SMO management plane processes to be significantly longer than the loop time for the same use case in the control entities stated above.

[0324] 5.3 Description of O-RAN Architecture Elements

[0325] 5.3.1 Service Management and Orchestration (SMO)

[0326] 5.3.1.1 SMO Architecture Principles

[0327] Service Based Architecture (SBA) introduces the roles of service producer and service consumer together with standardized service-based interfaces. These standardized service-based interfaces enable interoperability within the SMO. SBA is not concerned with the implementation, but it defines logical functions in their service producer and consumer roles. When properly applied the SBA approach can enable the following:

[0328] Validates produced services with consumer use cases.

[0329] Identifies service operations with their information model defining semantic behaviour.

[0330] Specifies the API and a data model for a syntactic interface.

[0331] Identifies common services that can be produced by a single producer such as those that are commonly used by multiple internal consumers (e.g., authentication, authorization, service registration and discovery, data management, etc.).

[0332] 5.3.1.2 SMO Services (SMOSs)

[0333] 5.3.1.2.1 Introduction to SMO Services

[0334] FIG. 9 illustrates Figure 5.3-1: SMOSs in the SMO SBA representation.

[0335] In the O-RAN architecture, SMO is responsible for RAN domain management. The SMO description in this architecture document is focused on the SMO services that support the RAN. Following the SBA principles above, the SMO Services produced by the SMO are defined. A SMOF implementation can produce and / or consume any combinations of one or more SMOSs, provided that the SMOF complies with the O-RAN specifications of the interfaces exposing the SMOSs.

[0336] The Non-RT RIC SMOF example depicted in the Figure 5.3-1 below shows support for rApps and for A1 related SMOSs. Otherwise, the definition of SMOFs is in general not in scope of the O-RAN specifications, as the interoperable functional behaviour of SMOFs is specified via the SMOS Producer / Consumer roles.

[0337] The SMO Services produced by the SMO are:

[0338] RAN NF OAM SMO Service, including capabilities such as,

[0339] RAN NF Performance Assurance Management (NFPM)

[0340] RAN NF Fault Supervision Management (NFFM)

[0341] RAN NF Provisioning Management (NFCM)

[0342] Others, e.g., Tracing, Logging, etc.

[0343] Network Functions Orchestration (NFO) SMOS

[0344] Federated O-Cloud Orchestration and Management (FOCOM) SMOS

[0345] Service Management and Exposure (SME) SMOS

[0346] Data Management and Exposure (DME) SMOS

[0347] Topology Exposure and Inventory Management (TE&IV) SMOS

[0348] RAN Analytics SMOS

[0349] Service & Subnet Slice Orchestration SMOS

[0350] Service & Subnet Slice Assurance SMOS

[0351] AI / ML workflow (AIMLWF) SMOS

[0352] rApp Management SMOS

[0353] A1 related SMOSs

[0354] Software package onboarding SMOS

[0355] Policy Management and Information (PMI).

[0356]

[0357] SME SMOS supports the exposure of other SMOSs, to both internal and external SMOS consumers.

[0358] DME SMOS supports the exposure of data produced by SMOS Producers, to both internal and external SMOS consumers.

[0359] The SMOSs described in this document are represented in a service-based architecture in the Figure 5.3-1 below.

[0360] 5.3.1.2.2 SMO in the O-RAN Architecture

[0361] All the SMO Service producers represented in Figure 5.3-1 can also be SMOS consumers.

[0362] The SMO consumes services offered by other O-RAN architecture elements through four key southbound interfaces:

[0363] A1 Interface between the Non-RT RIC in the SMO and the Near-RT RIC for RAN Optimization.

[0364] O1 Interface provides SMO FCAPS support either directly or indirectly between the SMO and the O-RAN Network Functions.

[0365] In the hierarchical model, SMO FCAPS support information over O1 to the O-DU which uses the Open FH M-Plane interface to manage the O-RU.

[0366] In the hybrid model, SMO provides FCAPS support information over Open FH M-Plane interface between the SMO and the O-RU and over O1 to the O-DU which uses the Open FH M-Plane interface to manage the O-RU.

[0367] O2 Interface between the SMO and the O-Cloud to provide O-Cloud resource management and workload management.

[0368] 5.3.1.2.3 Non-RT RIC

[0369] Non-RT RIC is the functionality internal to the SMO that supports intelligent RAN optimization by:

[0370] enabling an A1-related SMOS to provide policy-based guidance over the A1 interface

[0371] enabling an A1-related SMOS to provide enrichment information over the A1 interface

[0372] enabling an A1-related SMOS to provide ML model management over the A1 interface

[0373] enabling RAN optimization actions through RAN NF OAM SMOS over O1 and Open FH M-Plane interfaces, and NFO and FOCOM SMOSs over O2 interface

[0374]

[0375] Non-RT RIC framework enables rApps which consume and / or produce services over the R1 interface. For more information, refer to

[0027] .

[0376] Non-RT RIC supports intelligent RAN optimization control loops through rApps with intervals greater than 1 second.

[0377] 5.3.1.2.4 SMO capabilities extensions

[0378] As a flexible extension mechanism, the SMO allows delivery of aspects of RAN management and orchestration functionality via rApps.

[0379] 5.3.1.2.5 External exposure of SMO capabilities and Data

[0380] FIG. 10 illustrates Figure 5.3-2: SMO external terminations.

[0381] The exposure of SMO capabilities and data to external SMO consumers is done via SME and DME respectively, as represented in an SBA approach depicted in Figure 5.3-2.

[0382] 5.3.2 Near-RT RIC

[0383] FIG. 11 illustrates Figure 5.3-3: Service-based representation of the Near-RT RIC

[0026] .

[0384] Near-RT RIC is an O-RAN NF that enables near real-time control and optimization of services and resources of E2 Nodes via fine-grained data collection and actions over the E2 interface with control loops in the order of 10 ms-1s. The Near-RT RIC hosts one or more xApps that use E2 interface to collect near real-time information (e.g., on a UE basis or a Cell basis) and provide value added services. The Near-RT RIC control over the E2 Nodes is steered via the policies and the enrichment data provided via A1 from the Non-RT RIC. Based on the available data, the Near-RT RIC generates the RAN analytics information and exposes it via Y1 interface.

[0385] The functional enhancement provided by the Near-RT RIC and the E2 Node is subject to the capability of the E2 Node exposed over the E2 interface by means of the E2 Service Model

[0025] , in order to support the use cases described in

[0038] . The E2 service model describes the functions in the E2 Node which may be controlled by the Near-RT RIC and the related procedures. For a function exposed in the E2 Service Model

[0025] , the Near-RT RIC may e.g., monitor, override, or control via policies the behavior of E2 Node.

[0386] In the event of a Near-RT RIC failure, the E2 Node shall be able to provide services but there may be an impact to certain optimization capabilities that are provided by the Near-RT RIC.

[0387] The Near-RT RIC is composed of a Near-RT RIC platform and one or more xApps

[0026] and their capabilities are exposed as services. Both the Near-RT RIC platform and an xApp can be a service producer and / or a service consumer, and these services can be accessed via the set of Near-RT RIC APIs as illustrated in Figure 5.3-3.

[0388] 5.3.3 O-CU-CP

[0389] The O-CU-CP terminates the NG-c, X2-c, Xn-c, F1-c, and E1 interfaces as well as the RRC and PDCP (for SRB) protocols towards the UE as specified in

[0010] .

[0390] The O-CU-CP terminates E2 interface to Near-RT RIC as specified in

[0022] .

[0391] The O-CU-CP is managed via O1 interface by the SMO as specified in

[0034] .

[0392] The O-CU-CP terminates NG-c interface to 5GC as specified in [8].

[0393] The O-CU-CP terminates X2-c interface to O-eNB (in case O-eNB is an O-RAN eNB), eNB, or to en-gNB in EN-DC as specified in [6] and [8].

[0394] The O-CU-CP terminates Xn-c to O-CU-UP, O-eNB (in case O-eNB is an O-RAN ng-eNB), gNB, or to ng-eNB as specified in [8] and

[0012] .

[0395] 5.3.4 O-CU-UP

[0396] The O-CU-UP terminates the NG-u, X2-u, S1-u, Xn-u, F1-u, and E1 interfaces as well as the PDCP and SDAP protocols towards the UE as specified in

[0010] .

[0397] The O-CU-UP terminates E2 interface to Near-RT RIC as specified in

[0022] .

[0398] The O-CU-UP is managed via O1 interface by the SMO as specified in

[0034] .

[0399] The O-CU-UP terminates NG-u interface to 5GC as specified in [8].

[0400] The O-CU-UP terminates X2-u interface to O-eNB (in case O-eNB is an O-RAN eNB), eNB, or to en-gNB in EN-DC as specified in [6] and [8].

[0401] The O-CU-UP terminates Xn-u to O-CU-UP, O-eNB (in case O-eNB is an O-RAN ng-eNB), gNB, or to ng-eNB as specified in [8] and

[0012] .

[0402] 5.3.5 O-DU

[0403] The O-DU is an O-RAN NF in the O-RAN Architecture. An O-DU, combined with one or more O-RU(s) connected to it, supports and is fully compatible with the functions of a gNB-DU as defined by 3GPP TS 38.401

[0010] .

[0404] The O-DU may be implemented either by virtualized or non-virtualized methods.

[0405] The O-DU terminates the E2 and the F1 interface (according to the principles described in Clause 5.4.9), and the Open Fronthaul interface (also known as LLS interface

[0019] ) as well as the RLC, MAC, and High-PHY functions of the radio interface towards the UE.

[0406] The O-DU is managed via O1 interface by the SMO as specified in

[0034] .

[0407] The O-DU terminates the Open Fronthaul M-Plane interface, towards the O-RU, to support O-RU management either in hierarchical model or hybrid model, as specified in

[0024] .

[0408] The O-DU may support CTI to a TN to control UL bandwidth allocation to TUs for UL LLS traffic on shared point-to-multipoint transport network (TN is a PON OLT or DOCSIS CMTS, TU is a PON ONU or DOCSIS Cable Modem). The CTI is specified in

[0020] and

[0021] . An informative overview of the CTI is shown in Annex A.

[0409] 5.3.6 O-RU

[0410] The O-RU terminates the Open Fronthaul interface (also known as LLS interface

[0019] ) as well as Low-PHY functions of the radio interface towards the UE. This is deployed as a PNF.

[0411] The O-RU terminates the Open Fronthaul M-Plane interface towards the O-DU and SMO as specified in

[0024] .

[0412] 5.3.7 O-eNB

[0413] In case O-eNB is an O-RAN O-eNB, O-eNB terminates the S1, X2, O1 and E2 interfaces as well as the RRC, PDCP, RLC, MAC, and PHY layers of the LTE-Uu radio interface towards the UE as specified in [4]. In case O-eNB is an O-RAN ng-eNB, O-eNB terminates the NG, Xn, O1, and E2 interfaces as well as the RRC, SDAP, NR PDCP, RLC, MAC, and PHY layers of the LTE-Uu radio interface towards the UE as specified in

[0010] .

[0414] In case O-eNB is an O-RAN ng-eNB,

[0415] the O-eNB terminates E2 interface to Near-RT RIC as specified in

[0022] .

[0416] the O-eNB is managed via O1 interface by the SMO as specified in

[0034] .

[0417] the O-eNB terminates NG interface to 5GC as specified in [8].

[0418] the O-eNB terminates Xn interface to O-eNB, gNB, ng-eNB, or O-CU-CP / O-CU-UP as specified in [8] and

[0012] .

[0419] In case O-eNB is an O-RAN eNB,

[0420] the O-eNB terminates E2 interface to Near-RT RIC as specified in

[0022] .

[0421] the O-eNB is managed via O1 interface by the SMO as specified in

[0034] .

[0422] the O-eNB terminates S1 interface to EPC as specified in [4].

[0423] the O-eNB terminates X2 interface to O-eNB, eNB, en-gNB, or O-CU-CP / O-CU-UP as specified in [4] and

[0012] .

[0424] The O-eNB supports O-DU and O-RU O-RAN NFs with an Open Fronthaul interface between them as specified in

[0019] and

[0024] .

[0425] 5.3.8 O-Cloud

[0426] O-Cloud is a cloud computing platform comprising a collection of physical infrastructure nodes that meet O-RAN requirements to host the relevant O-RAN NFs (i.e., Near-RT RIC, O-CU-CP, O-CU-UP, and O-DU), the supporting software components (such as Operating System, Virtual Machine Monitor, Container Runtime, etc.), and the appropriate management and orchestration functions which satisfy the following criteria:

[0427] Exposes the O-RAN O2 interface for cloud and workload management to provide functions such as infrastructure discovery, registration, software lifecycle management, workload lifecycle management, fault management, performance management, and configuration management.

[0428] Exposes O-RAN AAL API towards the hosted O-RAN workloads for hardware accelerator management.

[0429] Exposes O-Cloud Notification interface towards the hosted O-RAN workloads in order to notify the workloads of critical notifications (e.g., PTP synchronization states).

[0430] The virtualization of the O-RU is not supported in the present document.

[0431] 5.4 Relevant Interfaces in O-RAN Architecture

[0432] 5.4.1 Introduction to Relevant Interfaces in O-RAN Architecture

[0433] The following interfaces are defined and maintained by O-RAN:

[0434] A1 interface

[0435] O1 interface

[0436] O2 interface

[0437] E2 interface

[0438] Y1 interface

[0439] O-Cloud Notification interface

[0440] Open Fronthaul interface

[0441] R1 interface

[0442] Near-RT RIC APIs

[0443]

[0444] The following interfaces are defined and maintained by 3GPP, but seen also as part of the O-RAN architecture:

[0445] E1 interface

[0446] F1-c interface

[0447] F1-u interface

[0448] NG-c interface

[0449] NG-u interface

[0450] X2-c interface

[0451] X2-u interface

[0452] Xn-c interface

[0453] Xn-u interface

[0454] Uu interface

[0455]

[0456] Following clauses describe the termination points of O-RAN defined interfaces and 3GPP interfaces adopted by O-RAN.

[0457] 5.4.2 A1 Interface

[0458] A1 interface is between Non-RT-RIC and the Near-RT RIC

[0018] .

[0459] A1 is the interface between the Non-RT RIC in SMO and the Near-RT RIC function O-RAN NF. A1 interface supports three types of services as defined in

[0018] :

[0460] Policy Management Service

[0461] Enrichment Information Service

[0462] ML Model Management Service

[0463]

[0464] A1 policies have the following characteristics compared to persistent configuration

[0018]

[0038] . A1 policies,

[0465] are not critical to traffic;

[0466] have temporary validity;

[0467] may handle individual UE or dynamically defined groups of UEs;

[0468] act within and take precedence over the configuration;

[0469] are non-persistent, i.e., do not survive a restart of the Near-RT RIC.

[0470] 5.4.3 O1 Interface

[0471] The O1 interface is used by SMO for the management of the O-RAN NFs as defined in

[0034] and

[0031] .

[0472] 5.4.4 O2 Interface

[0473] The O2 interface is between the SMO and O-Cloud as introduced in

[0033] . The O2 interface provides two categories of services - O2 deployment management services (O2dms) and O2 infrastructure management services (O2ims).

[0474] 5.4.5 E2 Interface

[0475] E2 is a logical interface connecting the Near-RT RIC with an E2 Node as defined in

[0022] .

[0476] An E2 Node is connected to only one Near-RT RIC.

[0477] A Near-RT RIC can be connected to multiple E2 Nodes.

[0478] The E2 interface is a control plane interface that provides support for Near-RT RIC Services using E2 Application Protocol and E2 Services Models

[0022] .

[0479] 5.4.6 O-Cloud Notification Interface

[0480] The O-Cloud Notification interface allows event consumer such as an O-DU deployed on O-Cloud to subscribe to events / status from the O-Cloud. The cloud infrastructure will provide event producer to enable cloud workloads to receive events / status that might be known only to the infrastructure.

[0481] 5.4.7 Open Fronthaul Interface

[0482] The Open FH (Fronthaul) Interface is between O-DU and O-RU logical nodes

[0019]

[0024] . The Open FH Interface includes the CUS (Control User Synchronization) Plane and M (Management) Plane. In hybrid mode, the Open FH M-Plane interface connects the O-RU to the SMO for FCAPS functionality.

[0483] 5.4.8 E1 Interface

[0484] The E1 interface, as defined by 3GPP, is between the gNB-CU-CP and gNB-CU-UP logical nodes

[0010]

[0014] . In O-RAN, it reuses the principles and protocol stack defined by 3GPP but is adopted between the O-CU-CP and the O-CU-UP logical nodes.

[0485] 5.4.9 F1-c Interface

[0486] The F1-c interface, as defined by 3GPP, is between the gNB-CU-CP and gNB-DU logical nodes

[0010]

[0016] . In O-RAN, it reuses the principles and protocol stack defined by 3GPP but is adopted between the O-CU-CP and the O-DU logical nodes, as well as for the definition of interoperability profile specifications.

[0487] 5.4.10 F1-u Interface

[0488] The F1-u interface, as defined by 3GPP, is between the gNB-CU-UP and gNB-DU logical nodes

[0010]

[0016] . In O-RAN, it reuses the principles and protocol stack defined by 3GPP but is adopted between the O-CU-UP and the O-DU logical nodes, as well as for the definition of interoperability profile specifications.

[0489] 5.4.11 NG-c Interface

[0490] The NG-c interface, as defined by 3GPP, is between the gNB-CU-CP and the AMF in the 5GC [8]. It is also referred as N2 in [8]. In O-RAN, it reuses the principles and protocol stack defined by 3GPP but is adopted between the O-CU-CP and the 5GC.

[0491] 5.4.12 NG-u Interface

[0492] The NG-u interface, as defined by 3GPP, is between the gNB-CU-UP and the UPF in the 5GC [8]. It is also referred as N3 in [8]. In O-RAN, it reuses the principles and protocol stack defined by 3GPP but is adopted between the O-CU-UP and the 5GC.

[0493] 5.4.13 X2-c Interface

[0494] The X2-c interface is defined in 3GPP for transmitting control plane information between eNBs or between eNB and en-gNB in EN-DC as specified in [6] and [8]. In O-RAN, it reuses the principles and protocol stack defined by 3GPP but is adopted for the definition of interoperability profile specifications.

[0495] 5.4.14 X2-u Interface

[0496] The X2-u interface is defined in 3GPP for transmitting user plane information between eNBs or between eNB and en-gNB in EN-DC as specified in [6] and [8]. In O-RAN, it reuses the principles and protocol stack defined by 3GPP but is adopted for the definition of interoperability profile specifications.

[0497] 5.4.15 Xn-c Interface

[0498] The Xn-c interface is defined in 3GPP for transmitting control plane information between gNBs, ng-eNBs or between ng-eNB and gNB as specified in [8] and

[0012] . In O-RAN, it reuses the principles and protocol stack defined by 3GPP but is adopted for the definition of interoperability profile specifications.

[0499] 5.4.16 Xn-u Interface

[0500] The Xn-u interface is defined in 3GPP for transmitting user plane information between gNBs, ng-eNBs or between ng-eNB and gNB as specified in [8] and

[0012] . In O-RAN, it reuses the principles and protocol stack defined by 3GPP but is adopted for the definition of interoperability profile specifications.

[0501] 5.4.17 Uu Interface

[0502] The UE to eNB / gNB interface in 3GPP is denoted as the Uu interface. The Uu is a complete protocol stack from L1 to L3 and as such, seen as a whole, it terminates in the NG-RAN. If the NG-RAN is decomposed, different protocols terminate at different reference points and none of them has been defined by O-RAN. Since the Uu messages still flow from the UE to the intended eNB / gNB managed function, it is not shown in the O-RAN architecture as a separate interface to a specific managed function. For more information on the Uu interface between the UE and the NG-RAN, please refer to Clauses 5.2 and 5.3 of

[0010] .

[0503] 5.4.18 CTI (Cooperative Transport Interface)

[0504] Interface between the O-DU and TN to dynamically control bandwidth allocations to TUs when using a shared point-to-multipoint transport network. The CTI is specified in

[0020] and

[0021] .

[0505] 5.4.19 Y1 Interface

[0506] Y1 service interface

[0039] allows the Y1 consumers to subscribe or request the RAN analytics information provided by Near-RT RIC.

[0507] 5.4.20 R1 Interface

[0508] The R1 interface is a service-based interface between the rApps and the Non-RT RIC framework via which R1 services can be produced and consumed as specified in O-RAN TS Non-RT RIC Architecture

[0027] .

[0509] The producers of R1 services can be part of the Non-RT RIC and / or the SMO Framework. R1 services are specified in O-RAN TS R1GAP

[0035] .

[0510] 5.4.21 Near-RT RIC APIs

[0511] The Near-RT RIC APIs are a set of service-based interfaces that can be produced and consumed by the Near-RT RIC Platform and xApps as specified in O-RAN TS Near-RT RIC Architecture

[0026] .

[0512] 5.5 UE Associated Identifiers Used in O-RAN

[0513] As described earlier (Clauses 5.3.1 and 5.3.2), the Non-RT RIC and Near-RT RIC enable intelligent RAN optimization via A1, O1 and E2 interfaces respectively.

[0514] To support intelligent RAN optimization, the Non-RT RIC with rApps and Near-RT RIC with xApps utilize the knowledge of different UE associated events reported by the O-RAN NFs (excluding O-RU) over E2 and O1 interfaces. Both the Non-RT RIC and Near-RT RIC may need to correlate different UE associated events reported by the O-RAN functions for the same UE. In order to facilitate this correlation task, the reporting O-RAN NF includes a set of UE associated identifiers with any report containing UE specific information.

[0515] Table 5 corresponds to the Table 5.5 1: UE Associate Identifiers used in O-RAN.

[0516] The Table 5.5-1 below shows the set of UE associated identifiers to be reported by any O-RAN NF (excluding O-RU) over O1 and E2 interfaces for any UE associated information.

[0517] UE associated identifierReference SpecificationCommentsAMF UE NGAP ID3GPP TS 38.413

[0011] Reported by O-CU-CP and O-eNB for UEs connected to 5GC.GUAMI3GPP TS 38.413

[0011] Reported by O-CU-CP and O-eNB for UEs connected to 5GC.MME UE S1AP ID3GPP TS 36.413 [5]Reported by O-eNB for UEs connected to EPC.GUMMEI3GPP TS 36.413 [5]Reported by O-eNB for UEs connected to EPC.gNB-CU UE F1AP ID3GPP TS 38.473

[0017] Reported by O-CU-CP and O-DU.gNB-CU-CP UE E1AP ID3GPP TS 38.463

[0015] Reported by O-CU-CP and O-CU-UP.RAN UE ID3GPP TS 38.473

[0017] 3GPP TS 38.463

[0015] Reported by O-CU-CP, O-CU-UP and O-DU when available / allocated.M-NG-RAN node UE XnAP ID3GPP TS 38.423

[0013] Identifier reported when the UE operates in DC with 5GC. Reported by O-CU-CP and O-eNB.Global NG-RAN Node ID3GPP TS 38.423

[0013] Identifier reported when the UE operates in DC with 5GC. Identifies the peer gNB / ng-eNB and is reported in conjunction with the M-NG-RAN node UE XnAP ID to ensure that the UE can be uniquely identified over Xn interface. Reported by O-eNB and O-CU-CP.MeNB UE X2AP ID3GPP TS 36.423 [7]Identifier reported when the UE operate in DC with EPC. Reported by O-CU-CP and O-eNB.Global eNB ID3GPP TS 36.423 [7]Identifier reported when the UE operate in DC with EPC. Identifies the peer eNB and is reported in conjunction with the MeNB UE X2AP ID to ensure that the UE can be uniquely identified over X2 interface. Reported by O-CU-CP and O-eNB.C-RNTI (Cell Radio Network Temporary Identifier)3GPP TS 38.331 [9]Optionally reported by O-CU-CP, O-DU and O-eNB.

[0518] Additionally, the Non-RT RIC and Near-RT RIC may initiate messages towards the O-RAN NFs which are associated with specific UEs. In such cases, the Non-RT RIC and Near RT RIC may include one or more of the UE associated identifiers specified in the Table 5.5-1 above with any UE associated messages over A1 and E2 interface for identification of the UE in the O-RAN NFs.

[0519] O-RAN E2 General Aspects and Principles (E2GAP) v07.00:

[0520] 3 Definition of terms, symbols and abbreviations

[0521] 3.1 Terms

[0522] For the purposes of the present document, the terms given in 3GPP TR 21.905 [i.1], O-RAN WG1.TS.OAD

[0018] and the following apply:

[0523] E2 Service Model: collection of E2AP IEs that are specified in O-RAN WG3.TS.E2AP [2] to have RAN Function specific definitions.

[0524] RAN Function: specific functionality in a E2 Node that supports one or more RIC Services exposed by the E2 Node to the Near-RT RIC.

[0525] RIC Service: service provided on an E2 Node or Near-RT RIC for use over the E2 interface.

[0526] SCTP association: As defined in IETF RFC 4960

[0012] . In the present document, SCTP association is interchangeably used by TNL (Transport Network Layer) association.

[0527] SCTP endpoint (or end-point): As defined in IETF RFC 4960

[0012] .

[0528] 3.2 Symbols

[0529] Void.

[0530] 3.3 Abbreviations

[0531] For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [i.1], O-RAN WG1.TS.OAD

[0018] and the following apply:

[0532] RAT Radio Access Technology

[0533] TNL Transport Network Layer

[0534] TNLA TNL Association

[0535] 4 E2 interface architecture

[0536] 4.1 General architecture principles

[0537] The general principles guiding the definition of the E2 interface between Near-RT RIC and E2 Nodes are the following:

[0538] - Near-RT RIC and E2 Node functions are fully separated from transport functions. Addressing scheme used in Near-RT RIC and the E2 Nodes shall not be tied to the addressing schemes of transport functions.

[0539] - The E2 Nodes support all protocol layers and interfaces defined within 3GPP radio access networks that include eNB for E-UTRAN, 3GPP TS 36.300

[0025] and 3GPP TS 36.401 [5], and gNB / ng-eNB for NG-RAN, 3GPP TS 38.300

[0016] and 3GPP TS 38.401 [6].

[0540] - Near-RT RIC may use the set of RIC Services that are exposed by an E2 Node.

[0541] - E2 Node may use the set of RIC Services that are exposed by the Near-RT RIC.

[0542] - The E2 Node shall describe the available RIC Services using a series of RAN function and Radio Access Technology (RAT) dependent "E2 Service Models".

[0543] - E2 interfaces are defined along the following principles:

[0544] - Interfaces are based on a logical model of the entity controlled through this interface.

[0545] - One physical network element can implement multiple logical nodes.

[0546] 4.2 O-RAN architecture considerations

[0547] FIG. 12 illustrates Figure 4.2-1: O-RAN architecture overview showing Near-RT RIC interfaces.

[0548] The Near-RT RIC and E2 Nodes connected by the E2 interface, as presented in Figure 4.2-1, are part of the overall O-RAN Architecture O-RAN WG1.TS.OAD

[0018] .

[0549] With respect to the E2 interface:

[0550] - E2 is a logical interface connecting the Near-RT RIC with an E2 Node:

[0551] - The Near-RT RIC is connected to the O-CU-CP;

[0552] - The Near-RT RIC is connected to the O-CU-UP;

[0553] - The Near-RT RIC is connected to the O-DU;

[0554] - The Near-RT RIC is connected to the O-eNB.

[0555] - An E2 Node is connected to only one Near-RT RIC.

[0556] - A Near-RT RIC can be connected to multiple E2 Nodes, i.e. multiple O-CU-CPs, O-CU-UPs, O-DUs and O-eNBs.

[0557] - F1 (F1-C, F1-U) and E1 are logical 3GPP interfaces, whose protocols, termination points and cardinalities are specified in NG-RAN, 3GPP TS 38.401 [6].

[0558] The Near-RT RIC use E2 interface to collect near real-time information (e.g. UE basis, Cell basis) and provide value added services.

[0559] The protocols over E2 interface are based exclusively on Control plane protocols and are defined in O-RAN WG3.TS.E2AP [2].

[0560] 5 E2 interface

[0561] 5.1 E2 interface requirements and general principles

[0562] 5.1.1 E2 interface requirements

[0563] The E2 interface shall support the following requirements:

[0564] - E2 interface requirements and general principles shall comply with the general O-RAN architecture principles specified in O-RAN WG1.TS.OAD

[0018] .

[0565] - E2 interface shall uniquely identify each E2 Node configured to directly provide RIC Services to the Near-RT RIC.

[0566] - A given Near-RT RIC may support E2 connections from multiple E2 Nodes, each supporting a specific RAT type.

[0567] - E2 interface shall expose from the E2 Node a list of RAN Functions supporting RIC Services and the corresponding E2 Service Model.

[0568] - E2 interface shall allow the Near-RT RIC to address specific RAN Functions in a specific E2 Node.

[0569] - E2 node shall function independently of the Near-RT RIC when and if the E2 interface and / or Near-RT RIC fails.

[0570] - E2 interface shall support latency requirements for near-real-time optimization, i.e. from 10 milliseconds up to 1 second as specified in O-RAN WG1.TS.OAD

[0018] .

[0571] - RAN Functions supported over E2 interface shall be subject to the capability of the E2 Node exposed over the E2 interface by means of the E2 Service Model.

[0572] - E2 Service Model shall describe the RAN Functions in the E2 Node that may be optimized by the Near RT RIC.

[0573] - For a RAN Function exposed in the E2 Service Model, the Near-RT RIC may e.g. monitor, override or control via policies the behaviour of E2 node.

[0574] 5.1.2 E2 interface general principles

[0575] FIG. 13 illustrates Figure 5.1.2-1: Relationship between Near-RT RIC and E2 Node.

[0576] The general principles for the specification of the E2 interface are as follows:

[0577] - E2 interface is open;

[0578] - E2 interface supports the exchange of control signalling information between the endpoints;

[0579] - E2 is a point-to-point interface between the endpoints on Near-RT RIC and E2 Node;

[0580] - E2 interface definition supports interface management procedures based on principles from 3GPP RAN interfaces;

[0581] - E2 interface provides the capability to send predefined information towards the Near-RT RIC based on a pre-configured trigger event;

[0582] - E2 interface supports the ability to provide UE ID information towards the Near-RT RIC based on a pre-configured trigger event;

[0583] - E2 interface enables the Near-RT-RIC to direct the E2 Node to interrupt an associated procedure and forward the relevant information to the Near-RT RIC based on a pre-configured trigger event;

[0584] - E2 interface supports the ability to send control messages (e.g. UE basis, Cell basis) to the E2 Node;

[0585] - E2 interface supports the ability to provide the E2 Node with a set of policies to use when defined events occur;

[0586] - E2 interface supports the ability for E2 Node to inform the Near-RT RIC of what functionality it supports;

[0587] - E2 interface supports the ability to query the E2 Node for relevant RAN- and / or UE-related information;

[0588] - E2 interface supports the ability for E2 node to consume services produced by the Near-RT RIC.

[0589]

[0590] With respect to the E2 interface, the E2 Node consists of:

[0591] - Logical E2 Agent used to terminate the E2 interface, support global services and to forward / receive RIC service messages towards RAN Functions.

[0592] - One or more RAN Functions that support RIC services exposed by the E2 Node to the Near-RT RIC.

[0593] - Other RAN functions that do not support RIC Services.

[0594] 5.2 E2 interface specification objectives

[0595] The E2 interface specifications shall facilitate the following:

[0596] - Connectivity between Near-RT RIC and E2 Node supplied by different vendors;

[0597] - Exposure of selected E2 Node data (e.g. configuration information (cell configuration, supported slices, PLMNs, etc.), network measurements, context information, etc.) towards the Near-RT RIC;

[0598] - Enables the Near-RT RIC to control selected RAN functions on the E2 Node.

[0599] 5.3 Functions of the E2 interface

[0600] 5.3.1 General

[0601] The E2 functions are grouped into the following categories:

[0602] RIC services supported by RIC functional procedures:

[0603] - RIC Services (REPORT, INSERT, CONTROL, POLICY, QUERY and ASSISTANCE), as described in clause 5.3.2) supported by RIC functional procedures (RIC Subscription, RIC Subscription Modification, RIC Subscription Modification Required, RIC Subscription Delete, RIC Subscription Delete Required, RIC Subscription Audit, RIC Subscription State Control, RIC Indication, RIC Control, RIC Query, RIC Service Load Status, RIC Service Load Update, RIC Assistance, RIC Assistance Indication, RIC Assistance Halt).

[0604] Global procedures:

[0605] - Interface Management procedures (E2 Setup, Reset, E2 Node Configuration Update, E2 connection Update, E2 Removal, E2 Resource Status, E2 Resource Status Update, Error Indication)

[0606] - RAN Function procedures (RIC Service Update, RIC Service Query).

[0607] 5.3.2 RIC services and related procedures

[0608] 5.3.2.1 RIC services

[0609] Near-RT RIC may use the following RIC services provided by an E2 node:

[0610] - REPORT: Near-RT RIC uses a RIC Subscription and / or RIC Subscription Modification procedures to request that E2 Node sends a REPORT message to Near-RT RIC and the associated procedure continues in the E2 Node after each occurrence of a defined RIC Subscription procedure Event Trigger.

[0611] - INSERT: Near-RT RIC uses a RIC Subscription and / or RIC Subscription Modification procedures to request that E2 Node sends an INSERT message to Near-RT RIC after each occurrence of a defined RIC Subscription procedure Event Trigger.

[0612] - CONTROL: Near-RT RIC sends a CONTROL message to E2 Node to initiate a new associated procedure or resume an associated procedure in the E2 Node.

[0613] - POLICY: Near-RT RIC uses a RIC Subscription and / or RIC Subscription Modification procedures to request that E2 Node executes a specific POLICY during functioning of the E2 Node after each occurrence of a defined RIC Subscription procedure Event Trigger.

[0614] - QUERY: Near-RT RIC sends a QUERY message to the E2 node to retrieve RAN-related and / or UE-related information from the E2 Node.

[0615] E2 Node may use the following RIC services provided by the Near-RT RIC:

[0616] - ASSISTANCE: E2 Node sends an ASSISTANCE message to the Near-RT RIC to utilize a service offered by the Near-RT RIC.

[0617] 5.3.2.2 REPORT service

[0618] FIG. 14 illustrates Figure 5.3.2.2-1: RIC Service REPORT.

[0619] The REPORT service involves following steps:

[0620] 1) Near-RT RIC configures, and subsequently may modify, a RIC Subscription in the E2 Node with information for Indication (Report) that is to be sent by the E2 Node with each occurrence of RIC trigger event condition

[0621] 2) During normal functioning of an associated procedure in the E2 Node, a RIC Event Trigger is detected.

[0622] 3) After completing any previous RIC actions, E2 Node sends RIC INDICATION message to Near-RT RIC containing the requested REPORT information along with the originating Request ID.

[0623] 4) Associated procedure continues in the E2 Node, including any subsequent RIC actions.

[0624] 5.3.2.3 INSERT service

[0625] FIG. 15 illustrates Figure 5.3.2.3-1: RIC Service INSERT with subsequent RIC Service CONTROL responses.

[0626] The INSERT service involves following steps:

[0627] 1) Near-RT RIC configures, and subsequently may modify, a RIC Subscription in the E2 Node with information for an INSERT action, along with an associated Subsequent Action Information (Subsequent Action type, Time to Wait timer), that is to be performed by E2 Node with each occurrence of Event.

[0628] 2) During normal functioning of an associated procedure in the E2 Node, a trigger event is detected.

[0629] 3) After completing any previous RIC actions, E2 Node waits for the corresponding response for up to a defined Time to Wait period.

[0630] 4) E2 Node sends RIC INDICATION message to Near-RT RIC containing the requested INSERT information along with the originating Request ID and information to identify the associated procedure.

[0631] 5) According to the Time to Wait timer state, arrival of RIC CONTROL procedure, and Subsequent Action parameter in the RIC Subscription, the E2 Node may then:

[0632] a) RIC CONTROL REQUEST message arrives in time:

[0633] This case is described in clause 5.3.2.4.

[0634] b) The associated Time to Wait timer expires and Subsequent Action Type set to Continue:

[0635] Continue the original associated procedure, including any subsequent RIC actions, if and when the associated Time to Wait timer expires. If the Near-RT RIC subsequently sends a RIC CONTROL REQUEST message with the Call Process ID for the same associated procedure, then the E2 Node shall respond with the RIC CONTROL FAILURE message with a cause to indicate that the timer has expired. See also clause 5.3.2.4.

[0636] c) The associated Time to Wait timer expires and Subsequent Action Type set to Halt:

[0637] Halt the original associated procedure, including any subsequent RIC actions, if and when the associated Time to Wait timer expires. If the Near-RT RIC subsequently sends a RIC CONTROL REQUEST message with the Call Process ID for the same associated procedure, then the E2 Node shall respond with the RIC CONTROL FAILURE message with a cause to indicate that the timer has expired. See also clause 5.3.2.4.

[0638] 5.3.2.4 CONTROL service

[0639] FIG. 16 illustrates Figure 5.3.2.4-1: RIC Service CONTROL as response to RIC Service INSERT.

[0640] FIG. 17 illustrates Figure 5.3.2.4-2: RIC Service CONTROL initiated by NEAR-RT RIC.

[0641] The CONTROL service involves following steps:

[0642] Near-RT RIC detects an event trigger. This step may be triggered by either:

[0643] a) a previous RIC INDICATION message sent by E2 Node;

[0644] b) internal to Near-RT RIC.

[0645] 1) Near-RT RIC performs an action.

[0646] 2) Near-RT RIC sends a RIC CONTROL REQUEST message to E2 Node. This message may contain information to identify the associated procedure, and may request acknowledgement from the E2 Node. The Near-RT RIC shall set the timer TRICcontrol if either acknowledgement has been requested or the optional acknowledgement request was not present in the RIC CONTROL REQUEST message.

[0647] 3) The E2 Node cancels the associated Time to Wait timer if previously set, and initiates or resumes the associated procedure.

[0648] 4) E2 Node then:

[0649] i) If the requested control service is successfully executed, and if acknowledgement was requested or if the optional RIC Control Ack Request was not present, the E2 Node sends the RIC CONTROL ACKNOWLEDGE message with the optional RIC Control Outcome providing information about the result of the request Control service.

[0650] ii) If the requested control service fails to execute or the request is not accepted, the E2 Node sends the RIC CONTROL FAILURE message with a cause indicating the reason for failure or rejection and the optional RIC Control outcome providing information about the reason for failure to execute.

[0651] 5) If previously set, the Near-RT RIC shall cancel the TRICcontrol timer

[0652] 5.3.2.5 POLICY service

[0653] FIG. 18 illustrates Figure 5.3.2.5-1: RIC Service POLICY.

[0654] The POLICY service involves following steps:

[0655] 1) Near-RT RIC configures, and subsequently may modify, a RIC Subscription in the E2 Node with information used to configure a POLICY that is to be performed by E2 Node with each occurrence of trigger event

[0656] 2) During normal functioning of the E2 Node, a trigger event is detected.

[0657] 3) After completing any previous RIC actions, E2 Node modifies ongoing call process according to information contained in the POLICY description statement

[0658] 4) Associated procedure continues in the E2 Node, including any subsequent RIC actions.

[0659] Note that if previously configured with a dedicated RIC Subscription, the E2 Node may send a REPORT used to provide information on the associated procedure outcome. See clause 5.3.2.2 for details.

[0660] 5.3.2.5A QUERY service

[0661] FIG. 19 illustrates Figure 5.3.2.5A-1: RIC Service QUERY.

[0662] The QUERY service involves following steps:

[0663] 1) Near-RT RIC determines need for RAN and / or UE-related information from the E2 node.

[0664] 2) Near-RT RIC sends a RIC QUERY REQUEST message to E2 Node. This message contains the requested information that needs to be fetched from the E2 Node. The Near-RT RIC shall set the timer TRICquery awaiting response from the E2 node.

[0665] 3) E2 node attempts to retrieve the requested information for the Near-RT RIC.

[0666] 4) E2 Node then:

[0667] i) If the E2 node successfully retrieves the requested information for the Near-RT RIC, then the E2 node sends the RIC QUERY RESPONSE message containing the desired information.

[0668] ii) If the E2 node fails to handle the request or fails to retrieve the requested information for the Near-RT RIC, then the E2 node sends the RIC QUERY FAILURE message along with the cause for failure.

[0669] 5.3.2.5B ASSISTANCE services

[0670] FIG. 20 illustrates Figure 5.3.2.5B-1: RIC Service ASSISTANCE.

[0671] The ASSISTANCE request / response service involves following steps:

[0672] 1. E2 Node determines need for RIC Assistance service from the Near-RT RIC.

[0673] 2. E2 Node sends a RIC ASSISTANCE REQUEST message to Near-RT RIC. This message contains information about the service to be provided from the Near-RT RIC and may contain request for one or more subsequent updates.

[0674] 3. Near-RT RIC attempts to provide the requested service for the E2 Node.

[0675] 4. Near-RT RIC then:

[0676] a. If the Near-RT RIC successfully provides the requested assistance service for the E2 Node, then the Near-RT RIC sends the RIC ASSISTANCE RESPONSE message containing the desired information. This step may require Near-RT RIC to fetch information from one or more E2 Nodes.

[0677] b. If the Near-RT RIC fails to handle the request for the E2 Node, then the Near-RT RIC sends the RIC ASSISTANCE FAILURE message along with the cause for failure.

[0678] 5. If requested and if the Near-RT RIC may subsequently provide an updated assistance service for the E2 Node, then the Near-RT RIC sends one or more ASSISTANCE INDICATION message. This step may require Near-RT RIC to fetch information from one or more E2 Nodes.

[0679] 6. E2 Node may send RIC ASSISTANCE HALT message to halt the subsequent updates of the requested assistance service

[0680] 5.3.2.6 RIC service realization and relationship with E2AP procedures

[0681] The RIC Services may be realized using the following RIC Functional procedures:

[0682] RIC Subscription procedure (Near-RT RIC initiated)

[0683] - Used to install Event Trigger and associated sequence of Actions corresponding to one or more RIC services REPORT, INSERT and / or POLICY

[0684] RIC Subscription Modification procedure (Near-RT RIC initiated)

[0685] - Used to modify Event Trigger and / or add, modify and / or remove associated sequence of Actions corresponding to one or more RIC services REPORT, INSERT and / or POLICY

[0686] RIC Subscription Modification Required procedure (E2 Node initiated)

[0687] - Used to request modification and / or removal of associated sequence of Actions corresponding to one or more RIC services REPORT, INSERT and / or POLICY

[0688] RIC Subscription Delete procedure (Near-RT RIC initiated)

[0689] - Used to delete previously installed RIC Subscription

[0690] RIC Subscription Delete Required procedure (E2 Node initiated)

[0691] - Used to indicate that one or more previously installed RIC Subscriptions are required to be deleted

[0692] RIC Subscription Audit procedure (Near-RT RIC initiated)

[0693] - Used to audit list of previously installed RIC Subscriptions

[0694] RIC Subscription State Control procedure (Near-RT RIC initiated)

[0695] - Used to suspend and / or resume a list of previously installed RIC Subscriptions

[0696] RIC Indication procedure (E2 Node initiated)

[0697] - Used to carry outcome of RIC services REPORT and INSERT

[0698] RIC Control procedure (Near-RT RIC initiated)

[0699] - Used to initiate RIC service CONTROL

[0700] RIC Query procedure (Near-RT RIC initiated)

[0701] Used to request RAN and / or UE related information from E2 Node

[0702] RIC Service Load Status procedure (Near-RT RIC initiated)

[0703] - Used to request that E2 Node reports RIC Service level load updates

[0704] RIC Service Load Update procedure (E2 Node initiated)

[0705] - Used to report load status information for one or more RIC services

[0706] The relationship between RIC Services and E2AP procedures related to RIC Subscription is presented in table 5.3.2.6-1A and the relationship between RIC Services and other E2AP procedures is presented in table 5.3.2.6-1B.

[0707] Table 6 corresponds to the Table 5.3.2.6-1A: Relationship between RIC Services and E2AP Procedures related to RIC Subscriptions.

[0708] Table 7 corresponds to the Table 5.3.2.6-1B: Relationship between RIC Services and E2AP Procedures related to other RIC Functional procedures

[0709] E2AP ProcedureRIC ServiceREPORTINSERTPOLICYRIC SubscriptionInstalls one or more REPORT Services associated with a RIC SubscriptionInstalls one or more INSERT Services associated with a RIC SubscriptionInstalls one or more POLICY Services associated with a RIC SubscriptionRIC Subscription ModificationAdds, Modifies and / or Removes one or more REPORT Services associated with a RIC SubscriptionAdds, Modifies and / or Removes one or more INSERT Services associated with a RIC SubscriptionAdds, Modifies and / or Removes one or more POLICY Services associated with a RIC SubscriptionRIC Subscription Modification RequiredRequests Modification and / or Removal of one or more REPORT Services associated with a RIC SubscriptionRequests Modification and / or Removal of one or more INSERT Services associated with a RIC SubscriptionRequests Modification and / or Removal of one or more POLICY Services associated with a RIC SubscriptionRIC Subscription DeleteDeletes all REPORT Services associated with one or more RIC SubscriptionsDeletes all INSERT Services associated with one or more RIC SubscriptionsDeletes all POLICY Service associated with one or more RIC SubscriptionsRIC Subscription Delete RequiredRequests Near-RT RIC to delete all REPORT Services associated with one or more RIC SubscriptionsRequests Near-RT RIC to delete all INSERT Services associated with one or more RIC SubscriptionsRequests Near-RT RIC to delete all POLICY Services associated with one or more RIC SubscriptionsRIC Subscription State ControlSuspends and / or Resumes one or more REPORT Services associated with one or more RIC SubscriptionsSuspends and / or Resumes one or more INSERT Services associated with one or more RIC SubscriptionsSuspends and / or Resumes one or more POLICY Services associated with one or more RIC SubscriptionsRIC Subscription AuditAudits list of established RIC Subscriptions

[0710] E2AP ProcedureRIC ServiceREPORTINSERTCONTROLPOLICYQUERYRIC IndicationCarries outcome of REPORT ServiceCarries outcome of INSERT ServiceRIC ControlInitiates CONTROL ServiceRIC QueryInitiates QUERY serviceRIC Service Load StatusInitiates reporting on load of REPORT serviceInitiates reporting on load of INSERT serviceInitiates reporting on load of CONTROL serviceInitiates reporting on load of POLICY serviceInitiates reporting on load of QUERY serviceRIC Service Load UpdateCarries information on load of REPORT serviceCarries information on load of INSERT serviceCarries information on load of CONTROL serviceCarries information on load of POLICY serviceCarries information on load of QUERY service

[0711] FIG. 21 illustrates Figure 5.3.2.6-1: RIC Subscription, RIC Subscription Modification, RIC Subscription Delete, RIC Subscription Audit and RIC Subscription State Control procedures.

[0712] FIG. 22 illustrates Figure 5.3.2.6-2: RIC Subscription Delete Required and RIC Subscription Delete procedures.

[0713] FIG. 23 illustrates Figure 5.3.2.6-3: RIC Subscription Modification Required procedure.

[0714] FIG. 24 illustrates Figure 5.3.2.6-4: RIC Service Load Status and RIC Service Load Update procedures.

[0715] The RIC Subscription, RIC Subscription Modification, RIC Subscription Modification Required, RIC Subscription Delete, and RIC Subscription Delete Required procedures are used to establish, modify or delete RIC subscriptions on the E2 Node. The RIC Subscription State Control procedure is used to suspend and / or resume one or more RIC Subscriptions. The RIC Subscription Audit procedure is used to audit the list of established RIC Subscriptions.

[0716] The RIC Subscription, RIC Subscription Modification, RIC Subscription Delete, RIC Subscription Audit and RIC Subscription State Control procedures are initiated by the Near-RT RIC (Figure 5.3.2.6-1). In addition, the E2 Node may initiate a RIC Subscription Delete Required procedure to request removal of one or more existing RIC Subscriptions (Figure 5.3.2.6-2) and a RIC Subscription Modification Required procedure to request the modification or removal of one or more existing RIC services within an existing RIC Subscription (Figure 5.3.2.6-3).

[0717] RIC Service Load Update procedure is used by the E2 Node to report the RIC Service load information related to one or more RIC Services. These reports shall be sent by the E2 Node if requested by the Near-RT RIC using the RIC Service Load Status procedure (Figure 5.3.2.6-4).

[0718] 5.3.3 Combining RIC services within a common RIC Subscription

[0719] RIC services defined in clause 5.3.2 may be combined within a common Subscription with each RIC Service implemented as part of a sequence of Actions.

[0720] Where appropriate in these cases, successive REPORT or INSERT messages sent to Near-RT RIC under the same subscription event trigger would contain the same assigned Subscription Request identifier, the same optional sequence number and each message with the unique assigned Action identifier.

[0721] Examples include:

[0722] - POLICY then REPORT. In this case, at each occurrence of the defined Event Trigger, the E2 Node would be instructed to first execute a defined POLICY and then send a defined REPORT message

[0723] - REPORT then REPORT. In this case, at each occurrence of the defined Event Trigger, the E2 Node would be instructed to first send a defined REPORT message to be followed by a second defined REPORT message containing normally different information.

[0724] When more than one RIC service action has been accepted by the E2 Node then actions shall be executed as specified in O-RAN WG3.TS.E2AP [2].

[0725] 5.3.4 Combining RIC services as a sequence of RIC services

[0726] RIC services defined in clause 5.3.2 may be combined using a sequence of different RIC services implemented using a procedure executed within the Near-RT RIC.

[0727] Examples include:

[0728] - REPORT followed by POLICY. In this case, at each occurrence of the defined Event Trigger, the E2 Node would be instructed to send a defined REPORT message. The Near-RT RIC would use the information from one or more successive REPORT messages as input to a procedure that may result in a change or establishment of a RIC POLICY service.

[0729] - INSERT followed by CONTROL. In this case, at each occurrence of the defined Event Trigger, the E2 Node would be instructed to send a defined INSERT message containing information used to identify the associated procedure and then the Near-RT RIC would send a corresponding CONTROL message containing information used to identify a previous suspended associated procedure.

[0730] - REPORT followed by CONTROL. In this case, at each occurrence of the defined Event Trigger, the E2 Node would be instructed to send a defined REPORT message. The Near-RT RIC would use the information from one or more successive REPORT messages as input to a procedure that may result in a RIC CONTROL service message being sent to initiate an associated procedure in the E2 Node.

[0731] 5.4 RAN Function E2 Service Model

[0732] As described in clause 5.1 the E2 interface is used to carry messages between a given E2 Node and Near-RT RIC. These messages may contain RAN Function specific content which is described in the corresponding RAN Function specific E2 Service Model.

[0733] Each RAN Function is described in the following terms:

[0734] - RAN Function Definition. Defines the RAN Function Name and describes the RIC Services that the specific RAN Function is currently configured to present over the E2 interface.

[0735] - RIC Event Trigger Definition approach. Describes the approach to be used in RIC Subscription and RIC Subscription Modification procedures to set or modify the RIC Event Trigger Definition in the RAN Function for RIC Services REPORT, INSERT and / or POLICY.

[0736] - RIC Action Definition approach. Describes the approach to be used in RIC Subscription and RIC Subscription Modification procedures to set or modify the required sequence of RIC Action in the RAN Function for RIC Services REPORT, INSERT and / or POLICY.

[0737] - RIC Indication Header and RIC Indication Message approach. Describes the approach to be used in RIC Indication procedure for RIC Services REPORT and INSERT.

[0738] - RIC Control Header and RIC Control Message approach. Describes the approach to be used in RIC Control procedure for RIC Service CONTROL.

[0739] - RIC Call Process ID approach. Describes the approach to be used by the E2 node in RIC Indication procedure for RIC Service INSERT. The same IE is used in the subsequent RIC Control procedure for RIC Service CONTROL.

[0740] - RIC Control Outcome approach. Describes the approach to be used by the E2 node in RIC Control procedure for RIC service CONTROL.

[0741] - RAN Function Policies. Describes the set of policies that the RAN Function is configured to support and the corresponding Parameters that may be used to configure the policy using RIC Service POLICY.

[0742] - RIC Query Header and RIC Query Definition approach. Describes the approach to be used by the Near-RT RIC in RIC Query procedure for RIC Service QUERY.

[0743] - RIC Query Outcome approach. Describes the approach to be used by the E2 node in RIC Query procedure for RIC Service QUERY.

[0744] - RIC Assistance Header and RIC Assistance Message approach. Describes the approach to be used in RIC Assistance procedure for RIC Service ASSISTANCE.

[0745] - RIC Assistance Outcome approach. Describes the approach to be used by the Near-RT RIC in RIC Assistance procedure for RIC Service ASSISTANCE.

[0746] - Service Level Cause approach. Describes the approach to be used across all RIC Functional procedures for reporting service level faults.

[0747] 5.5 Global procedures

[0748] 5.5.1 General

[0749] The E2 interface supports the following global procedures:

[0750] - E2 Setup

[0751] - Reset

[0752] - Error Indication

[0753] - RIC Service Update

[0754] - RIC Service Query

[0755] - E2 Node Configuration Update

[0756] - E2 Connection Update

[0757] - E2 Removal

[0758] - E2 Resource Status

[0759] - E2 Resource Status Update

[0760] The E2 Setup, Reset, RIC Service Update, RIC Service Query, E2 Node Configuration Update, E2 Removal, E2 Resource Status and E2 Resource Status Procedure procedures are described in further details in the following clauses. E2 Connection Update is described in clause 6.2.

[0761] 5.5.2 E2 Setup procedure

[0762] FIG. 25 illustrates Figure 5.5.2-1: E2 Setup procedure.

[0763] The E2 Setup procedure is used to establish the E2 interface between the Near-RT RIC and an E2 Node. During this procedure the E2 Node provides:

[0764] - List of supported RIC services and mapping of services to functions within the E2 Node. This information is specific to each RAN Function in the E2 node and is defined by a specific E2 Service Model as described in clause 5.4

[0765] - List of E2 Node configuration information. The configuration information is specific to the E2 Node type (see clause 4.2) and based on the re-use of 3GPP RAN3 defined configuration update messages.

[0766] If the E2 Setup procedure fails, the Near-RT RIC may provide an alternative Transport Layer Information for the E2 Node to use when reinitiating the E2 Setup procedure.

[0767] 5.5.3 Reset procedure

[0768] FIG. 26 illustrates Figure 5.5.3-1: Reset procedure (E2 Node initiated).

[0769] FIG. 27 illustrates Figure 5.5.3-2: Reset procedure (Near-RT RIC initiated).

[0770] The Reset procedure is used by either the E2 Node or Near-RT RIC to reset the E2 interface.

[0771] Information previous exchanged during E2 Setup, E2 Node Configuration Update and RIC Service Update procedures shall be maintained however the outcome of all previous RIC Subscription shall be deleted from the E2 Node and E2 Node gracefully terminates any ongoing RIC Services.

[0772] The Near-RT RIC may then proceed to re-establish any RIC Subscriptions as required.

[0773] 5.5.4 RIC Service Update procedure

[0774] FIG. 28 illustrates Figure 5.5.4-1: RIC Service Update procedure.

[0775] The RIC Service Update procedure is used by the E2 Node to inform the Near-RT RIC of any change to the list of supported RIC services and mapping of services to functions within the E2 Node. This information is specific to each RAN Function in the E2 node and is defined by a specific E2 Service Model as described in clause 5.4.

[0776] 5.5.4A RIC Service Query procedure

[0777] FIG. 29 illustrates Figure 5.5.4A-1: RIC Service Query procedure.

[0778] The RIC Service Query procedure is used by the Near-RT RIC to query the E2 Node with respect to the current list of supported RIC Services. The query procedure may be used to either request a complete list of supported RIC services or to request that the E2 Node compares the list of RIC Services provided in the query message with its current list of supported RIC Services.

[0779] This procedure is initiated by the Near-RT RIC sending a RIC SERVICE QUERY message.

[0780] 5.5.5 E2 Node Configuration Update procedure

[0781] FIG. 30 illustrates Figure 5.5.5-1: E2 Node Configuration Update procedure.

[0782] The E2 Node Configuration Update procedure is used by the E2 Node to inform the Near-RT RIC of any change to the configuration of the E2 Node and / or E2 Node initiated changes to TNL Associations associated with the E2 interface. The configuration information is specific to the E2 Node type (see clause 4.2) and based on the re-use of 3GPP RAN3 defined configuration update messages.

[0783] See clause 6.2 for further details on E2 Node Configuration Update procedure usage for E2 Node initiated changes to TNL Associations associated with the E2 interface.

[0784] 5.5.6 E2 Removal procedure

[0785] FIG. 31 illustrates Figure 5.5.6-1: E2 Removal procedure (E2 Node initiated).

[0786] FIG. 32 illustrates Figure 5.5.6-2: E2 Removal procedure (Near-RT RIC initiated).

[0787] The E2 Removal procedure is used by either the E2 Node or Near-RT RIC to release the E2 signalling connection.

[0788] If the procedure is E2 node initiated, after the E2 REMOVAL RESPONSE is received, the E2 node initiates termination of all TNL associations associated with this E2 interface. The Near-RT RIC and E2 nodes releases all resources associated with this E2 interface. If the E2 Removal procedure fails, the E2 node may retry the E2 Removal procedure.

[0789] If the procedure is Near-RT RIC initiated, after the E2 REMOVAL RESPONSE is received, the Near-RT RIC initiates termination of all TNL associations associated with this E2 interface. The Near-RT RIC and E2 nodes releases all resources associated with this E2 interface. If the E2 Removal procedure fails, the Near-RT RIC may retry the E2 Removal procedure.

[0790] 5.5.7 E2 Resource Status

[0791] FIG. 33 illustrates Figure 5.5.7-1: E2 Resource Status procedure.

[0792] This procedure is used by a Near-RT RIC to request the reporting of load measurements to E2 node. During this procedure, the E2 Node provides the E2 node level resource status and traffic load information over the E2 interface.

[0793] If the E2 Resource Status initiation fails, the Near-RT RIC may retry the E2 Resource Status initiation procedure.

[0794] 5.5.8 E2 Resource Status Update

[0795] FIG. 34 illustrates Figure 5.5.8-1: E2 Resource Status Update procedure.

[0796] The E2 Resource Status Update is used by the E2 Node to inform the Near-RT RIC of the results of the resource measurements that were successfully initiated during the preceding E2 Resource Status procedure (see clause 5.5.7). After the E2 Resource Status Update is received containing information describing the available resources in the E2 Node, the Near-RT RIC may suspend the initiation of new RIC procedures or may initiate RIC Subscription Delete procedures to reduce E2 Node load.

[0797] 6 E2 interface signalling

[0798] 6.1 E2 control plane protocol (E2AP)

[0799] FIG. 35 illustrates Figure 6.1-1: E2AP protocol stack.

[0800] The control plane protocol stack of the E2AP interface is shown on Figure 6.1-1.

[0801] The transport network layer is built on IP transport. For the reliable transport of signalling messages, IETF RFC 4960

[0012] is added on top of IP.

[0802] When configurations with multiple SCTP associations are supported, the Near-RT RIC may request to dynamically add / remove SCTP associations between the E2 Node / Near-RT RIC pair. Within the set of SCTP associations established between one Near-RT RIC and E2 node pair, the Near-RT RIC may request the E2 Node to restrict the usage of SCTP association for certain types of E2 signalling. If no restriction information is provided for an SCTP association, any type of E2 signalling is allowed via the SCTP association.

[0803] The application layer signalling protocol is referred to as E2AP (E2 Application Protocol). The Payload Protocol Identifier assigned by IANA to be used by SCTP for the application layer protocol E2AP is 70. This value is to be used for all deployment configurations described in the present document. Payload Protocol Identifiers 71 and 72, also assigned by IANA for E2, are reserved for future use.

[0804] No SCTP Destination Port number value was assigned by IANA for the E2AP protocol and so networks shall rely on E2 node and Near-RT RIC configuration to select a suitable port number.

[0805] NOTE 1: E2AP messages are transported over the E2 interfaces.

[0806] O-RAN E2 Application Protocol (E2AP) v07.00:

[0807] 3 Definition of terms, symbols and abbreviations

[0808] 3.1 Terms

[0809] For the purposes of the present document, the terms given in 3GPP TR 21.905 [i.1], O-RAN WG1.TS.OAD

[0027] , O-RAN WG3.TS.E2GAP [2] and the following apply.

[0810] NOTE: A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP TR　21.905 [i.1], O-RAN WG1.TS.OAD

[0027] and O-RAN WG3.TS.E2GAP [2].

[0811] E2 Node Component ID: local identifier used to uniquely identify an E2 Node component

[0812] Elementary Procedure: E2AP protocol consists of Elementary Procedures (EPs)

[0813] NOTE: An E2AP Elementary Procedure is a unit of interaction between the Near-RT RIC and an E2 Node. An EP consists of an initiating message and possibly a response message. Two kinds of EPs are used:

[0814] Class 1: Elementary Procedures with response (success or failure),

[0815] Class 2: Elementary Procedures without response.

[0816] Global E2 Node ID: global identifier of an E2 Node. Defined as the global eNB or gNB identifier and an optional local identifier of an CU-UP or DU which is required when and if an individual DU or CU-UP supports a direct E2 interface

[0817] Global RIC ID: global identifier of a Near-RT RIC

[0818] RAN Function ID: local identifier of a specific RAN Function within an E2 Node that supports one or more RIC Services using a specific E2 Service Model

[0819] RAN Function OID: RAN Function Object Identifier used to identify specific RAN function definition (i.e. E2SM used by specific RAN Function)

[0820] RIC Action ID: local identifier used Near-RT RIC to identify a specific RIC Service Action within a specific RIC Subscription Request, used by E2 Node in subsequent RIC Indication messages

[0821] RIC Call Process ID: local identifier used by E2 Node to identify the associated procedure during an Insert RIC Service Action, used by Near-RT RIC in subsequent RIC Control procedure

[0822] RIC Request ID: local identifier used to identify a specific RIC Functional procedure among all ongoing parallel procedures of the same type initiated by the same protocol peer.

[0823] NOTE: Messages belonging to the same procedure use the same RIC Request ID. The RIC Request ID is determined by the initiating peer of a RIC Functional Procedure.

[0824] Transaction ID: local identifier used to uniquely identify a Global Procedure among all ongoing parallel procedures of the same type initiated by the same protocol peer

[0825] NOTE: Messages belonging to the same procedure use the same Transaction ID. The Transaction ID is determined by the initiating peer of a Global Procedure (Near-RT RIC or E2 Node).

[0826] 3.2 Symbols

[0827] Void.

[0828] 3.3 Abbreviations

[0829] For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [i.1], O-RAN WG1.TS.OAD

[0027] and the following apply.

[0830] NOTE: An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 3GPP TR　21.905　[i.1] and O-RAN WG1.TS.OAD

[0027] .

[0831] EP Elementary Procedure

[0832] 5 E2AP Services

[0833] 5.1 E2AP procedure modules

[0834] The E2 interface E2AP procedures are divided into two modules as follows:

[0835] 1. RIC Functional Procedures;

[0836] 2. Global Procedures.

[0837] The RIC functional procedures module contains procedures used to pass application specific messages between Near-RT RIC applications and a target RAN Function in an E2 node as specified in O-RAN WG3.TS.E2GAP [2].

[0838] The Global Procedures module contains procedures that are not directly related to a specific application.

[0839] 5.2 Parallel transactions

[0840] Parallel transactions, that is, multiple ongoing E2AP procedures related to the same Application and E2 node, are supported.

[0841] 6 Services expected from signalling transport

[0842] The signalling connection shall provide in sequence delivery of E2AP messages. E2AP shall be notified if the signalling connection breaks.

[0843] 7 Functions of E2AP

[0844] The functions of E2AP are described in O-RAN WG3.TS.E2GAP [2].

[0845] 8 E2AP procedures

[0846] 8.1 Elementary procedures

[0847] Table 8 corresponds to the Table 8.1-1: Class 1 Elementary Procedures.

[0848] Table 9 corresponds to the Table 8.1-2: Class 2 Elementary Procedures.

[0849] In the Tables 8.1-1 and 8.1-2, all EPs are divided into Class 1 and Class 2 EPs.

[0850] Initiated byElementary ProcedureInitiating MessageSuccessful OutcomeUnsuccessful OutcomeResponse messageResponse messageNear-RT RICRIC SubscriptionRIC SUBSCRIPTION REQUESTRIC SUBSCRIPTION RESPONSERIC SUBSCRIPTION FAILURENear-RT RICRIC Subscription DeleteRIC SUBSCRIPTION DELETE REQUESTRIC SUBSCRIPTION DELETE RESPONSERIC SUBSCRIPTION DELETE FAILURENear-RT RICRIC Subscription ModificationRIC SUBSCRIPTION MODIFICATION REQUESTRIC SUBSCRIPTION MODIFICATION RESPONSERIC SUBSCRIPTION MODIFICATION FAILUREE2 NodeRIC Subscription Modification RequiredRIC SUBSCRIPTION MODIFICATION REQUIREDRIC SUBSCRIPTION MODIFICATION CONFIRMRIC SUBSCRIPTION MODIFICATION REFUSENear-RT RICRIC Subscription State ControlRIC SUBSCRIPTION STATE CONTROL REQUESTRIC SUBSCRIPTION STATE CONTROL RESPONSERIC SUBSCRIPTION STATE CONTROL FAILURENear-RT RICRIC Subscription AuditRIC SUBSCRIPTION AUDIT REQUESTRIC SUBSCRIPTION AUDIT RESPONSERIC SUBSCRIPTION AUDIT FAILUREE2 NodeRIC AssistanceRIC ASSISTANCE REQUESTRIC ASSISTANCE RESPONSERIC ASSISTANCE FAILURENear-RT RICRIC ControlRIC CONTROL REQUESTRIC CONTROL ACKNOWLEDGERIC CONTROL FAILURENear-RT RICRIC QueryRIC QUERY REQUESTRIC QUERY RESPONSERIC QUERY FAILURENear-RT RICRIC Service Load StatusRIC SERVICE LOAD STATUS REQUESTRIC SERVICE LOAD STATUS RESPONSERIC SERVICE LOAD STATUS FAILUREE2 NodeE2 SetupE2 SETUP REQUESTE2 SETUP RESPONSEE2 SETUP FAILUREE2 NodeRIC Service UpdateRIC SERVICE UPDATERIC SERVICE UPDATE ACKNOWLEDGERIC SERVICE UPDATE FAILUREE2 NodeE2 Node Configuration UpdateE2 NODE CONFIGURATION UPDATEE2 NODE CONFIGURATION UPDATE ACKNOWLEDGEE2 NODE CONFIGURATION UPDATE FAILURENear-RT RICE2 Connection UpdateE2 CONNECTION UPDATEE2 CONNECTION UPDATE ACKNOWLEDGEE2 CONNECTION UPDATE FAILURENear-RT RIC or E2 NodeResetRESET REQUESTRESET RESPONSENear-RT RIC or E2 NodeE2 RemovalE2 REMOVAL REQUESTE2 REMOVAL RESPONSEE2 REMOVAL FAILURE

[0851] Initiated byElementary ProcedureInitiating MessageNear-RT RICRIC Assistance IndicationRIC ASSISTANCE INDICATIONE2 NodeRIC Assistance HaltRIC ASSISTANCE HALTE2 NodeRIC IndicationRIC INDICATIONNear-RT RICRIC Service QueryRIC SERVICE QUERYE2 NodeRIC Subscription Delete RequiredRIC SUBSCRIPTION DELETE REQUIREDE2 NodeRIC Service Load UpdateRIC SERVICE LOAD UPDATEE2 Node or Near-RT RICError IndicationERROR INDICATION

[0852] 8.2 RIC Functional procedures

[0853] 8.2.11 RIC Assistance procedure

[0854] 8.2.11.1 General

[0855] This procedure is used to utilize an assistance service offered by the Near-RT RIC.

[0856] This procedure shall be initiated by the E2 Node.

[0857] This procedure uses RIC Service signalling.

[0858] 8.2.11.2 Successful operation

[0859] FIG. 36 illustrates Figure 8.2.11.2-1: RIC Assistance procedure, successful operation.

[0860] The E2 Node initiates the procedure by sending a RIC ASSISTANCE REQUEST message which shall contain a unique RIC Request ID IE, assigned by the E2 Node, to the Near-RT RIC. When the E2 Node sends the RIC ASSISTANCE REQUEST message, it shall start timer TRICassist.

[0861] At reception of the RIC ASSISTANCE REQUEST message the Near-RT RIC shall:

[0862] - Consider the RIC Assistance Header IE and RIC Assistance Message IE to determine the requested service and if available at Near-RT RIC, then Near-RT RIC shall respond back with RIC ASSISTANCE RESPONSE message for the requested service with the result contained in the RIC Assistance Header IE and RIC Assistance Outcome IE.

[0863] Upon reception of the RIC ASSISTANCE RESPONSE message the E2 Node shall stop timer TRICassist and terminate the RIC Assistance procedure.

[0864] Interactions with RIC Assistance Indication procedure:

[0865] If the optional RIC Assistance Update IE is present, the Near-RT RIC shall use the RIC Assistance Update Number IE, if present, to determine the maximum number of RIC ASSISTANCE INDICATION messages to the E2 Node to provide updates for the requested assistance service offered by the Near-RT RIC.

[0866] If the RIC Assistance Update Number IE is not present, then the Near-RT RIC shall continue to send RIC ASSISTANCE INDICATION messages until reception of the RIC ASSISTANCE HALT message.

[0867] 8.2.11.3 Unsuccessful operation

[0868] FIG. 37 illustrates Figure 8.2.11.3-1: RIC Assistance procedure, unsuccessful operation.

[0869] If the Near-RT RIC cannot accept the RIC ASSISTANCE REQUEST message it shall respond with the RIC ASSISTANCE FAILURE message with an appropriate cause value.

[0870] Upon reception of the RIC ASSISTANCE FAILURE message the E2 Node shall stop timer TRICassist and terminate the RIC Assistance Procedure.

[0871] 8.2.11.4 Abnormal conditions

[0872] Void.

[0873] 8.2.12 RIC Assistance Indication procedure

[0874] 8.2.12.1 General

[0875] This procedure is used to provide an update for an assistance service offered by the Near-RT RIC.

[0876] This procedure shall be initiated by the Near-RT RIC.

[0877] This procedure uses RIC Service signalling.

[0878] 8.2.12.2 Successful operation

[0879] FIG. 38 illustrates Figure 8.2.12.2-1: RIC Assistance Indication procedure, successful operation.

[0880] The Near-RT RIC initiates the procedure by sending a RIC ASSISTANCE INDICATION message which shall contain a unique RIC Request ID IE, assigned by the E2 Node during a previous RIC Assistance procedure, to the E2 Node, and the updated assistance service result in RIC Assistance Header IE and RIC Assistance Outcome IE. Each update of the requested assistance service shall contain a unique RIC Assistance SN IE.

[0881] Interactions with RIC Assistance Halt procedure:

[0882] If the E2 Node sends a RIC ASSISTANCE HALT message, the Near-RT RIC shall halt sending RIC ASSISTANCE INDICATION messages corresponding to the RIC Request ID IE contained in the message.

[0883] 8.2.12.3 Unsuccessful operation

[0884] Not applicable.

[0885] 8.2.12.4 Abnormal conditions

[0886] Void.

[0887] 8.2.13 RIC Assistance Halt procedure

[0888] 8.2.13.1 General

[0889] This procedure is used to halt updates for an assistance service offered by the Near-RT RIC.

[0890] This procedure shall be initiated by the E2 Node.

[0891] This procedure uses RIC Service signalling.

[0892] 8.2.13.2 Successful operation

[0893] FIG. 39 illustrates Figure 8.2.13.2-1: RIC Assistance Halt procedure, successful operation.

[0894] The E2 Node initiates the procedure by sending a RIC ASSISTANCE HALT message which shall contain a unique RIC Request ID IE, assigned by the E2 Node during a previous RIC Assistance procedure, to the Near-RT RIC.

[0895] Upon reception the Near-RT RIC shall halt the requested updates to the RIC Assistance service.

[0896] 8.2.13.3 Unsuccessful operation

[0897] Not applicable.

[0898] 8.3.13.4 Abnormal conditions

[0899] If the Near-RT RIC receives a RIC Assistance Halt request from the E2 Node that does not correspond to an ongoing RIC Assistance service, then the Near-RT RIC shall ignore the message.

[0900] 8.3 Global procedures

[0901] 8.3.1 E2 Setup procedure

[0902] 8.3.1.1 General

[0903] The purpose of the E2 Setup procedure is to exchange application level data needed for the E2 Node and Near-RT RIC to correctly interoperate on the E2 interface. This procedure shall be the first E2AP procedure triggered after the TNL association has become operational.

[0904] This procedure erases any existing application level configuration data in the two nodes and replace it by the one received.

[0905] This procedure shall be initiated by the E2 Node.

[0906] This procedure uses E2 Support Function signalling.

[0907] 8.3.1.2 Successful operation

[0908] FIG. 40 illustrates Figure 8.3.1.2-1: E2 Setup procedure, successful operation.

[0909] The E2 Node initiates the procedure by sending the E2 SETUP REQUEST message including the appropriate data to a Near-RT RIC.

[0910] If the Near-RT RIC has successfully processed the RAN Functions Added List IE then Near-RT RIC shall contain, in the E2 SETUP RESPONSE message, the RAN Functions Accepted List IE and / or the RAN Functions Rejected List IE.

[0911] If the Near-RT RIC has successfully processed the E2 Node Component Configuration Addition List IE then Near-RT RIC shall contain, in the E2 SETUP RESPONSE message, the E2 Node Component Configuration Addition Acknowledge List IE.

[0912] 8.3.1.3 Unsuccessful operation

[0913] FIG. 41 illustrates Figure 8.3.1.3-1: E2 Setup procedure, unsuccessful operation.

[0914] If the Near-RT RIC cannot accept the setup it shall respond with an E2 SETUP FAILURE message with an appropriate cause value.

[0915] The Near-RT RIC may provide an alternative Transport Layer Information IE in the E2 SETUP FAILURE message for the E2 Node to use when reinitiating the E2 Setup procedure towards the Near-RT RIC.

[0916] If the E2 SETUP FAILURE message includes the Time To Wait IE, the E2 node shall wait at least for the indicated time before reinitiating the E2 Setup procedure towards the Near-RT RIC.

[0917] 8.3.1.4 Abnormal conditions

[0918] If the first message received for a specific TNL association is not an E2 SETUP REQUEST, E2 SETUP RESPONSE, E2 SETUP FAILURE or E2 NODE CONFIGURATION UPDATE message then this shall be treated as a logical error.

[0919] 8.3.2 Reset procedure

[0920] 8.3.2.1 General

[0921] The purpose of the Reset procedure is to initialize or re-initialize the E2 Node in the event of Near-RT RIC failure or vice-versa.

[0922] This procedure does not affect the application level data exchanged during the E2 Setup procedure, E2 Node Configuration Update procedure and RIC Service Update procedure.

[0923] This procedure shall be initiated by the E2 Node or the Near-RT RIC.

[0924] This procedure uses E2 Support Function signalling.

[0925] 8.3.2.2 Successful operation

[0926] FIG. 42 illustrates Figure 8.3.2.2-1: Reset, successful operation (E2 Node Initiated).

[0927] FIG. 43 illustrates Figure 8.3.2.2-2: Reset, successful operation (Near-RT RIC Initiated).

[0928] This procedure may be initiated by either Near-RT RIC or E2 Node.

[0929] When the Reset procedure is initiated, the Near-RT RIC and E2 Node shall:

[0930] - Delete any pre-established RIC Subscriptions.

[0931] - Gracefully terminate any ongoing Near-RT RIC call processes using Insert, Control or Policy RIC Service Actions while ensuring that impact to ongoing calls for connected UE is minimized.

[0932] After the Reset has been completed, the Near-RT RIC may re-issue any required RIC Subscriptions.

[0933] Interactions with other procedures:

[0934] If the RESET REQUEST message is received, any other ongoing procedure (except for another Reset procedure) on the same E2 interface related to ongoing RIC Services shall be aborted.

[0935] 8.3.2.3 Unsuccessful operation

[0936] Void.

[0937] 8.3.2.4 Abnormal conditions

[0938] Void.

[0939] 8.3.3 Error Indication

[0940] 8.3.3.1 General

[0941] The Error Indication procedure is initiated by either the E2 Node or the Near-RT RIC to report detected errors in one incoming message, provided they cannot be reported by an appropriate failure message.

[0942] This procedure shall be initiated by the E2 Node or the Near-RT RIC.

[0943] If the error situation arises due to reception of a message utilizing RIC Service signalling, then the Error Indication procedure uses RIC Service signalling. Otherwise, the procedure uses E2 Support Function signalling.

[0944] 8.3.3.2 Successful operation

[0945] FIG. 44 illustrates Figure 8.3.3.2-1: Error Indication, (E2 Node initiated) successful operation.

[0946] FIG. 45 illustrates Figure 8.3.3.2-2: Error Indication, (Near-RT RIC Initiated) successful operation.

[0947] When the conditions defined in clause 10 are fulfilled, the Error Indication procedure shall be initiated by an ERROR INDICATION message sent from the node detecting the error situation.

[0948] The ERROR INDICATION message shall contain at least either the Cause IE or the Criticality Diagnostics IE and may include RAN Function ID IE and RIC Request ID IE.

[0949] 8.3.3.3 Unsuccessful operation

[0950] Not applicable.

[0951] 8.3.3.4 Abnormal conditions

[0952] Not applicable.

[0953] 8.3.4 RIC Service Update procedure

[0954] 8.3.4.1 General

[0955] The purpose of the RIC Service Update procedure is to update application level RIC Service related data needed for E2 Node and Near-RT RIC to interoperate correctly over the E2 interface.

[0956] This procedure shall be initiated by the E2 Node.

[0957] This procedure uses E2 Support Function signalling.

[0958] 8.3.4.2 Successful operation

[0959] FIG. 46 illustrates Figure 8.3.4.2-1: RIC Service Update procedure, successful operation.

[0960] An E2 Node initiates the procedure by sending a RIC SERVICE UPDATE message to the Near-RT RIC.

[0961] If the E2 Node has taken into operational use one or more RAN Functions supporting RIC Services, the RIC SERVICE UPDATE message shall include the RAN Functions Added List IE.

[0962] If the E2 Node has modified one or more RAN Functions supporting RIC Services, the RIC SERVICE UPDATE message shall include the RAN Functions Modified List IE.

[0963] If the E2 Node has removed from operational use one or more RAN Functions supporting RIC Services, the RIC SERVICE UPDATE message shall include the RAN Functions Deleted List IE.

[0964] Upon reception of a RIC SERVICE UPDATE message, Near-RT RIC shall update the application level data for E2 Node as follows:

[0965] - If the RAN Function Added List IE is contained in the RIC SERVICE UPDATE message, Near-RT RIC shall add each listed accepted RAN Function according to the information in the RAN Function ID IE and RAN Function Definition IE and store the corresponding RAN Function Revision IE.

[0966] - If the RAN Function Modified List IE is contained in the RIC SERVICE UPDATE message, Near-RT RIC shall modify accepted information of supported RAN Functions according to the information in the RAN Function Definition IE and update the corresponding RAN Function Revision IE.

[0967] - If the RAN Function Deleted List IE is contained in the RIC SERVICE UPDATE message, Near-RT RIC shall delete information of RAN Function indicated by the RAN Function ID IE along with the corresponding RAN Function Revision IE.

[0968] These changes may be processed in the Near-RT-RIC and may be used when issuing RIC SUBSCRIPTION REQUEST and RIC CONTROL to provide valid RAN Function ID IE.

[0969] If at least one RAN Function update request present in the RIC SERVICE UPDATE message is successful, then the Near-RT RIC shall send the RIC SERVICE UPDATE ACKNOWLEDGE message to the initiating E2 Node with:

[0970] - RAN Functions Accepted List IE indicating accepted requests to add, modify, and / or delete the corresponding RAN Function information.

[0971] - If required, the RAN Functions Rejected List IE indicating rejected requests to add, modify, and / or delete the corresponding RAN Function information.

[0972] If the Near-RT RIC receives a RIC SERVICE UPDATE message without any IE except for Message Type IE, then the Near-RT RIC shall reply with RIC SERVICE UPDATE ACKNOWLEDGE message without any IE except for Message Type IE, and shall not perform any updates to the existing application level data.

[0973] 8.3.4.3 Unsuccessful operation

[0974] FIG. 47 illustrates Figure 8.3.4.3-1: RIC Service Update procedure, unsuccessful operation.

[0975] If the Near-RT RIC cannot accept the update it shall respond with a RIC SERVICE UPDATE FAILURE message with an appropriate cause value.

[0976] If the RIC SERVICE UPDATE FAILURE message includes the Time To Wait IE, the E2 Node shall wait at least for the indicated time before reinitiating the RIC Service Update procedure towards the same Near-RT RIC. Both nodes shall continue to operate the E2 with their existing RIC Service data.

[0977] 8.3.4.4 Abnormal conditions

[0978] 8.3.4A RIC Service Query procedure

[0979] 8.3.4A.1 General

[0980] The purpose of the RIC Service Query procedure is to ensure alignment between Near-RT RIC and E2 Node concerning application level RIC Service related data needed for E2 Node and Near-RT RIC to interoperate correctly over the E2 interface.

[0981] This procedure shall be initiated by the Near-RT RIC.

[0982] This procedure uses E2 Support Function signalling.

[0983] 8.3.4A.2 Successful operation

[0984] FIG. 48 illustrates Figure 8.3.4A.2-1: RIC Service Query procedure, successful operation.

[0985] The Near-RT RIC initiates the procedure by sending a RIC SERVICE QUERY message to the E2 Node.

[0986] Upon reception of the RIC SERVICE QUERY message the E2 Node shall initiate the RIC Service Update procedure according to the following considerations:

[0987] - If the RAN Function Accepted List IE is not present in the RIC SERVICE QUERY message, the E2 Node shall send the RIC SERVICE UPDATE message with the complete list of supported RAN Functions in the RAN Function Added List IE.

[0988] - If the RAN Function Accepted List IE is present in the RIC SERVICE QUERY message and aligns with the list of supported RAN Functions at the E2 Node, the E2 Node shall send the RIC SERVICE UPDATE message without the RAN Function Added List IE, RAN Function Modified List IE and RAN Function Deleted List IE.

[0989] - If the RAN Function Accepted List IE is present in the RIC SERVICE QUERY message and the list of RAN Functions in the RAN Function Accepted List IE does not align with the list of supported RAN Functions at the E2 node, the E2 Node shall send the RIC SERVICE UPDATE message with the RAN Function Added List IE, RAN Function Modified List IE and / or RAN Function Deleted List IE to ensure realignment of RAN Functions between the E2 Node and the Near-RT RIC.

[0990] The Near-RT RIC completes the RIC Service Update procedure as described in clause 8.3.4.

[0991] 8.3.4A.3 Unsuccessful operation

[0992] Void.

[0993] 8.3.4A.4 Abnormal conditions

[0994] 9 Elements for E2AP communication

[0995] 9.0 General

[0996] Clauses 9.1 and 9.2 describe the structure of the messages and information elements required for the E2AP protocol in tabular format. Clause 9.3 provides the corresponding ASN.1 definition.

[0997] The following attributes are used for the tabular description of the messages and information elements: Presence, Range Criticality and Assigned Criticality. Their definition and use can be found in 3GPP TS 36.413

[0024] .

[0998] NOTE: The messages have been defined in accordance with the guidelines specified in 3GPP TR 25.921 [i.2].

[0999] 9.1 Message functional definition and content

[1000] 9.1.1 Messages for RIC Functional procedures

[1001] 9.1.1.30 RIC ASSISTANCE REQUEST

[1002] This message is sent by the E2 Node to Near-RT RIC to request an assistance service.

[1003] Direction: E2 Node → Near-RT RIC.

[1004] IE / Group NamePresenceRangeIE type and referenceSemantics descriptionCriticalityAssigned CriticalityMessage TypeM9.2.3YESrejectRIC Request IDM9.2.7YESrejectRIC Assistance HeaderM9.2.47YESrejectRIC Assistance MessageM9.2.48YESrejectRIC Assistance UpdateO9.2.49YESIgnoreRIC Assistance Update NumberO9.2.50YESIgnore

[1005] 9.1.1.31 RIC ASSISTANCE RESPONSE

[1006] This message is sent by the Near-RT RIC to the E2 Node to provide the requested assistance service.

[1007] Direction: Near-RT RIC → E2 Node.

[1008] IE / Group NamePresenceRangeIE type and referenceSemantics descriptionCriticalityAssigned CriticalityMessage TypeM9.2.3YESrejectRIC Request IDM9.2.7YESrejectRIC Assistance HeaderM9.2.47YESrejectRIC Assistance OutcomeM9.2.51YESignore

[1009] 9.1.1.32 RIC ASSISTANCE FAILURE

[1010] This message is sent by the Near-RT RIC to inform the E2 Node that the requested RIC Assistance service failed.

[1011] Direction: Near-RT RIC → E2 Node.

[1012] IE / Group NamePresenceRangeIE type and referenceSemantics descriptionCriticalityAssigned CriticalityMessage TypeM9.2.3YESrejectRIC Request IDM9.2.7YESrejectCauseM9.2.1YESrejectCriticality DiagnosticsO9.2.2YESignore

[1013] 9.1.1.33 RIC ASSISTANCE INDICATION

[1014] This message is sent by the Near-RT RIC to the E2 Node to provide an updated response to the requested assistance service.

[1015] Direction: Near-RT RIC → E2 Node.

[1016] IE / Group NamePresenceRangeIE type and referenceSemantics descriptionCriticalityAssigned CriticalityMessage TypeM9.2.3YESrejectRIC Request IDM9.2.7YESrejectRIC Assistance SNM9.2.52YESignoreRIC Assistance HeaderM9.2.47YESrejectRIC Assistance OutcomeM9.2.51YESignore

[1017] 9.1.1.34 RIC ASSISTANCE HALT

[1018] This message is sent by the E2 Node to the Near-RT RIC to halt further updates to the requested assistance service.

[1019] Direction: Near-RT RIC → E2 Node.

[1020] IE / Group NamePresenceRangeIE type and referenceSemantics descriptionCriticalityAssigned CriticalityMessage TypeM9.2.3YESrejectRIC Request IDM9.2.7YESignore

[1021] 9.1.2 Messages for Global Procedures

[1022] 9.1.2.1 ERROR INDICATION

[1023] This message is used to indicate that some error has been detected in the E2 Node or Near-RT RIC.

[1024] Direction: E2 Node → Near-RT RIC or Near-RT RIC → E2 Node.

[1025] IE / Group NamePresenceRangeIE type and referenceSemantics descriptionCriticalityAssigned CriticalityMessage TypeM9.2.3YESignoreTransaction IDO9.2.33Required ifRIC Request IDIE is not present.YESrejectRIC Request IDO9.2.7Required ifTransaction IDIE is not present.YESrejectRAN Function IDO9.2.8YESrejectCauseO9.2.1YESignoreCriticality DiagnosticsO9.2.2YESignore

[1026] 9.1.2.2 E2 SETUP REQUEST

[1027] This message is sent by an E2 Node to a Near-RT RIC to transfer the initialization information.

[1028] Direction: E2 Node → Near-RT RIC.

[1029] IE / Group NamePresenceRangeIE type and referenceSemantics descriptionCriticalityAssigned CriticalityMessage TypeM9.2.3YESrejectTransaction IDM9.2.33.YESrejectGlobal E2 Node IDM9.2.6YESrejectRAN Functions Added List1List of RAN functions in E2 node.YESreject>RAN Function item1.. <maxofRANfunctionID>>>RAN Function IDM9.2.8Id of the declared Function.->>RAN Function DefinitionM9.2.23Definition of Function.->>RAN Function RevisionM9.2.24Revision counter.->>RAN Function OIDM9.2.31Object identifier of corresponding E2SM.-E2 Node Component Configuration Addition List1List of E2 Node component configuration information.YESreject>E2 Node Component Configuration Addition Item1.. <maxofE2nodeComponents>EACHreject>>E2 Node Component Interface TypeM9.2.26E2 Node component interface type.->>E2 Node Component IDO9.2.32E2 Node Component Identifier.->>E2 Node Component ConfigurationM9.2.27Contents depends on component interface type.-

[1030] Range boundExplanationmaxofRANfunctionIDMaximum no. of RAN Functions supported by E2 Node. Value is 256.maxofE2nodeComponentsMaximum no. of E2 Node components supported by E2 Node. Value is 1024

[1031] 9.1.2.3 E2 SETUP RESPONSE

[1032] This message is sent by a Near-RT RIC to an E2 Node to transfer the initialization information.

[1033] Direction: Near-RT RIC → E2 Node.

[1034] IE / Group NamePresenceRangeIE type and referenceSemantics descriptionCriticalityAssigned CriticalityMessage TypeM9.2.3YESrejectTransaction IDM9.2.33.YESrejectGlobal RIC IDM9.2.4YESrejectRAN Functions Accepted List0..1Complete list of Functions accepted by Near-RT RIC.>RAN Functions ID item1 .. <maxofRANfunctionID>YESReject>>RAN Function IDM9.2.8Id of the declared Function.->>RAN Function RevisionM9.2.24Revision counter.-RAN Functions Rejected List0..1Complete list of Functions not accepted by Near-RT RIC.>RAN Functions ID Cause Item1 .. <maxofRANfunctionID>YESreject>>RAN Function IDM9.2.8Id of the declared Function.->>CauseM9.2.1Reason for not accepting function.-E2 Node Component Configuration Addition Acknowledge List1Complete list of E2 Node Components in the E2 SETUP REQUEST message.YESreject>E2 Node Component Configuration Addition Acknowledge Item1.. <maxofE2nodeComponents>EACHreject>>E2 Node Component Interface TypeM9.2.26E2 Node component interface type.->>E2 Node Component IDM9.2.32E2 Node Component Identifier.->>E2 Node Component Configuration AcknowledgeM9.2.28Success or failure with Cause.-

[1035] Range boundExplanationmaxofRANfunctionIDMaximum no. of RAN Functions supported by E2 Node. Value is 256.maxofE2nodeComponentsMaximum no. of E2 Node components supported by E2 Node. Value is 1024

[1036] 9.1.2.4 E2 SETUP FAILURE

[1037] This message is sent by the Near-RT RIC to indicate E2 Setup failure.

[1038] Direction: Near-RT RIC → E2 Node.

[1039] IE / Group NamePresenceRangeIE type and referenceSemantics descriptionCriticalityAssigned CriticalityMessage TypeM9.2.3YESrejectTransaction IDM9.2.33YESrejectCauseM9.2.1YESignoreTime To WaitO9.2.5YESignoreCriticality DiagnosticsO9.2.2YESIgnoreTransport Layer InformationO9.2.29YESignore

[1040] 9.1.2.5 RESET REQUEST

[1041] This message is sent from a Near-RT RIC to an E2 Node or from an E2 Node to a Near-RT RIC and is used to request the E2 interface between the E2 node and the Near-RT RIC to be reset.

[1042] Direction: Near-RT RIC → E2 Node, or E2 Node → Near-RT RIC.

[1043] IE / Group NamePresenceRangeIE type and referenceSemantics descriptionCriticalityAssigned CriticalityMessage TypeM9.2.3YESrejectTransaction IDM9.2.33YESrejectCauseM9.2.1YESignore

[1044] 9.1.2.6 RESET RESPONSE

[1045] This message is sent by an E2 Node to a Near-RT RIC or from a Near-RT RIC to an E2 Node as a response to a RESET REQUEST message.

[1046] Direction: Near-RT RIC → E2 Node, or E2 Node → Near-RT RIC.

[1047] IE / Group NamePresenceRangeIE type and referenceSemantics descriptionCriticalityAssigned CriticalityMessage TypeM9.2.3YESrejectTransaction IDM9.2.33YESrejectCriticality DiagnosticsO9.2.2YESignore

[1048] 9.1.2.7 RIC SERVICE UPDATE

[1049] This message is sent by an E2 Node to the Near-RT RIC to transfer updated information on RIC Services supported by the E2 Node.

[1050] Direction: E2 Node → Near-RT RIC.

[1051] IE / Group NamePresenceRangeIE type and referenceSemantics descriptionCriticalityAssigned CriticalityMessage TypeM9.2.3YESrejectTransaction IDM9.2.33YESrejectRAN Functions Added List0..1List of added RAN functions in E2 node.>RAN Functions Item1 .. <maxofRANfunctionID>YESreject>>RAN Function IDM9.2.8Id of the declared Function.->>RAN Function DefinitionM9.2.23Definition of Function.->>RAN Function RevisionM9.2.24Revision counter.->>RAN Function OIDM9.2.31Object identifier of corresponding E2SM.-RAN Functions Modified List0..1List of Modified RAN functions in E2 node.>RAN Functions Item1 .. <maxofRANfunctionID>YESreject>>RAN Function IDM9.2.8Id of the declared Function.->>RAN Function DefinitionM9.2.23Definition of Function.->>RAN Function RevisionM9.2.24Revision counter.->>RAN Function OIDM9.2.31Object identifier of corresponding E2SM.-RAN Functions Deleted List0..1List of deleted RAN functions in E2 node.>RAN Functions ID Item1 .. <maxofRANfunctionID>YESreject>>RAN Function IDM9.2.8Id of the declared Function.->>RAN Function RevisionM9.2.24Revision counter.-

[1052] Range boundExplanationmaxofRANfunctionIDMaximum no. of Functions accepted by Near-RT RIC. Value is 256.

[1053] 9.1.2.8 RIC SERVICE UPDATE ACKNOWLEDGE

[1054] This message is sent by the Near-RT RIC to the E2 Node to acknowledge update of RIC Services supported by the E2 Node.

[1055] Direction: Near-RT RIC → E2 Node.

[1056] IE / Group NamePresenceRangeIE type and referenceSemantics descriptionCriticalityAssigned CriticalityMessage TypeM9.2.3YESrejectTransaction IDM9.2.33YESrejectRAN Functions Accepted List0..1List of Functions accepted by Near-RT RIC.>RAN Functions ID Item1 .. <maxofRANfunctionID>YESreject>>RAN Function IDM9.2.8Id of the declared Function.->>RAN Function RevisionM9.2.24Revision counter.-RAN Functions Rejected List0..1List of Functions not accepted by Near-RT RIC.>RAN Functions Cause Item1 .. <maxofRANfunctionID>YESreject>>RAN Function IDM9.2.8Id of the declared Function.->>CauseM9.2.1Reason for not accepting function.-

[1057] Range boundExplanationmaxofRANfunctionIDMaximum no. of Functions accepted by Near-RT RIC. Value is 256.

[1058] 9.1.2.9 RIC SERVICE UPDATE FAILURE

[1059] This message is sent by the Near-RT RIC to the E2 Node to indicate RIC SERVICE Update Failure.

[1060] Direction: Near-RT RIC → E2 Node.

[1061] IE / Group NamePresenceRangeIE type and referenceSemantics descriptionCriticalityAssigned CriticalityMessage TypeM9.2.3YESrejectTransaction IDM9.2.33YESrejectCauseM9.2.1Reason for failure.YESrejectTime To WaitO9.2.5YESignoreCriticality DiagnosticsO9.2.2YESignore

[1062] 9.1.2.10 RIC SERVICE QUERY

[1063] This message is sent by a Near-RT RIC to an E2 Node to request a E2 Node initiated RIC Service Update procedure.

[1064] Direction: Near-RT RIC → E2 Node.

[1065] IE / Group NamePresenceRangeIE type and referenceSemantics descriptionCriticalityAssigned CriticalityMessage TypeM9.2.3YESrejectTransaction IDM9.2.33.YESrejectRAN Functions Accepted List0..1Complete list of Functions previously accepted by Near-RT RIC.>RAN Functions ID Item1 .. <maxofRANfunctionID>YESreject>>RAN Function IDM9.2.8Id of the declared Function.->>RAN Function RevisionM9.2.24Revision counter.-

[1066] Range boundExplanationmaxofRANfunctionIDMaximum no. of Functions accepted by Near-RT RIC. Value is 256.

[1067] 9.1.2.17 E2 REMOVAL REQUEST

[1068] This message is sent by either the E2 Node or the Near-RT RIC to initiate the removal of the E2 signalling connection and the related resources.

[1069] Direction: Near-RT RIC → E2 Node, or E2 Node → Near-RT RIC.

[1070] IE / Group NamePresenceRangeIE type and referenceSemantics descriptionCriticalityAssigned CriticalityMessage TypeM9.2.3YESrejectTransaction IDM9.2.33YESreject

[1071] 9.1.2.18 E2 REMOVAL RESPONSE

[1072] This message is sent by either the E2 Node or the Near-RT RIC to acknowledge the initiation of removal of the E2 signalling connection and the related resources.

[1073] Direction: Near-RT RIC → E2 Node, or E2 Node → Near-RT RIC.

[1074] IE / Group NamePresenceRangeIE type and referenceSemantics descriptionCriticalityAssigned CriticalityMessage TypeM9.2.3YESrejectTransaction IDM9.2.33YESrejectCriticality DiagnosticsO9.2.2YESignore

[1075] 9.1.2.19 E2 REMOVAL FAILURE

[1076] This message is sent by either the E2 Node or the Near-RT RIC to indicate that removing the E2 signalling connection and the related resources cannot be accepted.

[1077] Direction: Near-RT RIC → E2 Node, or E2 Node → Near-RT RIC.

[1078] IE / Group NamePresenceRangeIE type and referenceSemantics descriptionCriticalityAssigned CriticalityMessage TypeM9.2.3YESrejectTransaction IDM9.2.33YESrejectCauseM9.2.1YESignoreCriticality DiagnosticsO9.2.2YESignore

[1079] PROBLEM DESCRIPTION

[1080] O-RAN (Open Radio Access Network) was established in 2018 to create an open, intelligent, virtualized, and interoperable RAN ecosystem. Its mission is to transition from traditional, proprietary RAN solutions toward an open and flexible architecture [1], enabling mobile network operators to integrate equipment from different vendors and to incorporate artificial intelligence (AI) and machine learning (ML) guided intelligence into the network system. Through the standardizations of the necessary interfaces across network elements and promoting open software and hardware, O-RAN aims to foster innovation, reduce costs, and increase flexibility, supporting enhancements in 5G and future 6G networks.

[1081] The integration of AI / ML not only enhances network performance, but also enables more efficient and precise management of network functions. It allows operators to optimize various network components and steer to a certain KPI (Key Performance Indicator) of interest in an efficient and elegant manner.

[1082] The AI / ML-driven control for RAN in the order of 10 ms-1s is implemented through the E2 interface [1], which connects the Near-RT (real time) RAN Intelligent Controller (RIC) with the existing RAN node(s). The Near-RT RIC is an O-RAN network function that enables near real-time control and optimization of services and resources of RAN nodes via fine-grained data collection and actions over the E2 interface. It subscribes various RIC services (e.g. REPORT, INSERT, CONTROL, POLICY, etc.) of RAN functions supported by E2-connected RAN nodes [2], which is subject to the capability of the RAN nodes exposed over the E2 interface by means of the E2 Service Models [2].

[1083] Recently, a new RIC service called "ASSISTANCE" has been added to the family of RIC services over the E2 interface [2][3]. Unlike existing RIC services of "REPORT", "INSERT", "CONTROL", "POLICY", and "QUERY", which are based on the principle of the Near-RT RIC acting as a consumer of services provided by E2-connected RAN nodes, this new service type is produced by the Near-RT RIC itself. The ASSISTANCE service allows a RAN node, as a service consumer, to benefit from the intelligent information processing capabilities of Near-RT RIC.

[1084] This service can assist RAN nodes by providing information that is available at the Near-RT RIC level. For example, a Near-RT RIC can generate some RAN analytics based on its internal processing or the information received from other E2-connected RAN nodes or external entities via the Y1 interface [1]. Such information might include predictions of UE or network behaviours, which can help E2-connected RAN nodes optimize their radio resource management and enhance overall performance.

[1085] Moreover, AI / ML support for NG-RAN has been introduced in 3GPP from Rel-18, which specified that an NG-RAN node may support both AI / ML model training / inference, or model inference only. From O-RAN perspective, these AI / ML capabilities can be further enhanced by enabling the Near-RT to provide AI / ML model training (or re-training) as a service to E2-connected NG-RAN nodes. By consuming these services, RAN nodes can leverage more advanced model inference to enhance decision-making and operational efficiency.

[1086] While this new service type represents a significant progress in completing the AI / ML-based intelligence cycle over the E2 interface and enhancing AI / ML integration in O-RAN eco-systems, its implementation within the Near-RT RIC and over the E2 interface is still in its early stages. Specifically, it remains unclear how RAN nodes can determine whether the E2-connected Near-RT RIC entity supports this new service type and what intelligences are available for provisions, before deciding to utilize them. Moreover, once a requested ASSISTANCE service is accepted, there is no mechanism for the Near-RT RIC to terminate the ongoing service provision to the RAN node unless explicitly requested by the RAN node. This lack of flexibility is not resilient to errors or unexpected behaviours at the Near-RT RIC. For example, if an ASSISTANCE service toward a RAN node begins to excessively drain resources or consume significant power at the Near-RT RIC, there is no mechanism for the Near-RT RIC to gracefully terminate the service. Without such method for the Near-RT RIC to initiate the removal of an accepted ASSISTANCE service, resource management and error recovery would remain challenging.

[1087] To address these challenges, this disclosure proposes mechanisms to enable RAN nodes to identify the capabilities and ASSISTANCE services offered by the Near-RT RIC, as well as to support the graceful termination of an accepted ASSISTANCE service initiated by the Near-RT RIC.

[1088] [1] O-RAN WG1, O-RAN Architecture Description

[1089] [2] O-RAN WG3, E2 General Aspects and Principles (E2GAP)

[1090] [3] O-RAN WG3, E2 Application Protocol (E2AP)

[1091] DETAILED DESCRIPTION

[1092] FIG. 49 illustrates RIC produced service discovery and management for RAN.

[1093] The following description is presented in the context of the E2 interface between a Near-RT RIC entity and a RAN node [2] to illustrate specific embodiments. However, the disclosed techniques, methods, and implementations are not limited to this example and are intended to be broadly applicable to other interfaces or configurations that achieve similar functions. The scope of this disclosure extends to any suitable communication architecture supporting equivalent functionalities, without restriction to the E2 interface described herein. For example, it could be applied to the discovery or management of services produced by a Non-RT RIC entity for a RAN node inter-connected via the O1 interface [1].

[1094] A RAN node connecting E2 interface with Near-RT RIC may be an eNB or gNB in an aggregate form, or one of eNB or gNB components (e.g. CU-CP, CU-UP, or DU) if an individual component supports a direct E2 interface.

[1095] Step 1: RAN node sends an E2 SETUP REQUEST message to the Near-RT RIC to establish the E2 interface with the Near-RT RIC. The request message may expose one or more RAN functions supported and produced by the RAN node, as represented by the E2 service models [2]. For each RAN function exposed, the request message may also provide the specific services (e.g., REPORT, INSERT, CONTROL, POLICY, QUERY) specified under that RAN function that this RAN node can offer to the Near-RT RIC. This allows the Near-RT RIC to understand not only the RAN functions but also the exact services available for use within each RAN function.

[1096] Additionally, the request message may include one or more configuration information specific to the RAN node type (e.g., eNB, gNB, CU-CP, CU-UP, DU, etc.). These configuration details may be based on the configuration exchange messages specified in 3GPP for relevant RAN interfaces [2].

[1097] Moreover, the request message may include an indication to identify the ASSISTANCE service capabilities of the Near-RT RIC.

[1098] Step 2: The Near-RT RIC responds with an E2 SETUP RESPONSE message to acknowledge the request and establish the E2 interface with the RAN node.

[1099] If the Near-RT RIC is capable of producing ASSISTANCE service(s) that can be consumed by the requesting RAN node, the response message may also include the detailed information about the ASSISTANCE service(s) offered by the Near-RT RIC:

[1100] - For example, the Near-RT RIC may provide a list of RAN functions, with each function specifying the details of the ASSISTANCE services it offers. A listed RAN function may correspond to one of the RAN functions that the RAN node exposed as supported in Step 1 and contain one or more ASSISTANCE services. Alternatively, the list may include RAN functions that the RAN node did not explicitly indicate as supported in Step 1.

[1101] - For each RAN function in the list, the Near-RT RIC may further include the information detailing out the support status of the ASSISTANCE services available for use by the RAN node, to allow the RAN node to understand which ASSISTANCE service and information within that specific RAN function is supported and offered by the Near-RT RIC.

[1102] Step 3: If there are updates to the RAN functions or capabilities, the RAN node may send a RIC SERVICE UPDATE message to notify the updates to the Near-RT RIC.

[1103] If not previously retrieved, the RAN node may also include an indication to identify the ASSISTANCE service capabilities of the Near-RT RIC.

[1104] Step 4: Upon receiving the service update, the Near-RT RIC responds with a RIC SERVICE UPDATE ACKNOWLEDGE message to confirm the changes. If the RAN node included a request for ASSISTANCE service capabilities, Near-RT RIC may also provide the information about ASSISTANCE service(s) it can offer to the RAN node. This information is structured similarly to Step 2, including a list of RAN functions specifying one or more ASSISTANCE services, which may also include detailed RAN function information to clarify the support status of each ASSISTANCE service and information within each RAN function.

[1105] Step 5: If there are updates on the ASSISTANCE service capabilities in the Near-RT RIC, the Near-RT RIC may inform the updated ASSISTANCE capability information by sending a RIC SERVICE QUERY message, or via a new message, e.g. "RIC SERVICE UPDATE REQUIRED” message.

[1106] Step 6: Based on the ASSISTANCE service capabilities received from the Near-RT RIC, the RAN node may decide to utilize one or more ASSISTANCE service(s) available for use by the RAN node. To initiate this, the RAN node prepares a request based on their service definitions described in the corresponding RAN function and sends a RIC ASSISTANCE REQUEST message to the Near-RT RIC.

[1107] The Near-RT RIC processes the requested ASSISTANCE services, prepares the results, and responds to the RAN node with a RIC ASSISTANCE RESPONSE message containing the outcomes. Additionally, depending on the ASSISTANCE service definition or if specifically requested by the RAN node via Step 5b, the Near-RT RIC may provide further updates by sending one or more subsequent RIC ASSISTANCE INDICATION messages.

[1108] Step 7: In case that on-going ASSISTANCE service(s) need to be cancelled, the Near-RT RIC may send a message to the RAN node, e.g. "RIC ASSISTANCE CANCEL" message to inform the cancellation of those ASSISTANCE services previously accepted by the Near-RT RIC. The message may contain the information that can identify the ASSISTANCE service requested by the RAN node at Step 6b, with the corresponding reason for cancellation.

[1109] The reason for cancellation included in the Step 7 RIC ASSISTANCE CANCEL message may indicate RIC resource limit or processing overload when the Near-RT RIC cannot maintain the ASSISTANCE service due to internal resource constraints. Alternatively, such cancellation may be triggered when a higher-priority service needs to occupy the current resources of the Near-RT RIC or due to an operator's policy-driven terminations. Upon receiving the RIC ASSISTANCE CANCEL message, the RAN node stops utilizing the indicated ASSISTANCE service and may release resources or UE contexts allocated for that service.

[1110] Advantageous Effects

[1111] The inventions described in this present disclosure aim to enable the seamless discovery and controlled termination of services provided by Near-RT RIC and consumed by RAN nodes, by ensuring that RAN nodes can effectively identify those available services while allowing Near-RT RIC to manage resources efficiently and respond to errors or unexpected behaviors.

[1112] Features of various embodiments of the present disclosure

[1113] In the network system where services produced by a RAN Intelligent Controller (RIC) are consumed by a RAN node through an interface:

[1114] - A RAN node may be an eNB or gNB in an aggregate form, or one of eNB or gNB components (e.g. CU-CP, CU-UP, or DU) if an individual component supports a direct interface with the RIC.

[1115] - During interface setup or service update procedure, a RAN node requests the RIC to identify the service capabilities it offers that can be consumed by the RAN node.

[1116] - In response to the request, the RIC provides details about its available services that can be offered to the RAN node:

[1117] - The RIC may provide a list of RAN functions, each specifying the services it offers. A listed RAN function may correspond to one of the RAN functions that the RAN node exposed as supported in the request message and contain one or more services specified to be consumed by the RAN nodes.

[1118] - Alternatively, the list may include RAN functions not explicitly indicated as supported by the RAN node in its request.

[1119] - For each RAN function in the list, RIC may include the information about the supported services, enabling the RAN node to understand which service and related information are available for use.

[1120] - If there are updates on the service capabilities offered by the RIC, the RIC informs the changes by providing updated service capability information to the RAN node.

[1121] - Based on the service capabilities received from the RIC, the RAN node decides which service(s) to utilize:

[1122] - The RAN node prepares a request according to the service definitions described in the corresponding RAN function and sends it to the RIC.

[1123] - RIC processes the requested services, prepares the results, and responds to the RAN node containing the outcomes.

[1124] - If ongoing services consumed by the RAN node need to be terminated, the RIC sends a cancellation message to the RAN node, including the reason for the cancellation:

[1125] - The identification of the service to be cancelled is based on the information initially provided when the service was requested by the RAN node.

[1126]

[1127] [Description of claims related to a first node (Near-RT RIC)]

[1128] Below, the above-described embodiments are described in detail from a perspective of an operation of a first node (Near-RT RIC) with reference to FIG. 50. Methods to be described below are merely distinguished for convenience of explanation. Thus, as long as the methods are not mutually exclusive, it is obvious that partial configuration of any method can be substituted or combined with partial configuration of another method.

[1129] FIG. 50 illustrates an example of an operation process of a first node in a system applicable to the present disclosure.

[1130] A first node may be a Near-RT RIC, a second node may be a RAN.

[1131] In step S5010, a first node receives, from a second node, a first message including a list of radio access network (RAN) functions of the second node.

[1132] In step S5020, in response to the first message, the first node transmits, to the second node, a second message including service information about supported services for the second node.

[1133] According to various embodiments of the present disclosure, the first message is an E2 SETUP REQUEST message, and wherein the second message is an E2 SETUP RESPONSE message.

[1134] According to various embodiments of the present disclosure, the first message is a RIC SERVICE UPDATE message, and wherein the second message is a RIC SERVICE UPDATE ACKNOWLEDGE message.

[1135] According to various embodiments of the present disclosure, the service information in the second message is associated with a revised RAN function definition in which, for a RAN function included in the first message, unsupported services that are not supported by the first node are excluded.

[1136] According to various embodiments of the present disclosure, detailed information about available services included in the second message includes a list of one or more RAN functions, each RAN function specifying one or more services provided by the first node.

[1137] According to various embodiments of the present disclosure, the service information in the second message includes a list of one or more RAN functions specifying one or more services provided by the first node.

[1138] According to various embodiments of the present disclosure, the method further comprises: determining to cancel an ongoing service; and transmitting, to the second node, a cancellation message including a reason for cancellation of the ongoing service.

[1139] According to various embodiments of the present disclosure, there is provided a first node in a wireless communication system. The first node may include a transceiver and at least one processor, and the at least one processor may be configured to perform the operation method of the first node based on FIG. 50.

[1140] According to various embodiments of the present disclosure, there is provided a device controlling a first node in a wireless communication system. The device may include at least one processor and at least one memory operably connected to the at least one processor. The at least one memory may be configured to store instructions performing the operation method of the first node based on FIG. 50 based on being executed by the at least one processor.

[1141] According to various embodiments of the present disclosure, there are provided one or more non-transitory computer readable mediums (CRMs) storing one or more instructions. The one or more instructions may be configured to perform operations based on being executed by one or more processors, and the operations may include the operation method of the first node based on FIG. 50.

[1142]

[1143] [Description of claims related to a second node (RAN)]

[1144] Below, the above-described embodiments are described in detail from a perspective of an operation of a second node (RAN) with reference to FIG. 51. Methods to be described below are merely distinguished for convenience of explanation. Thus, as long as the methods are not mutually exclusive, it is obvious that partial configuration of any method can be substituted or combined with partial configuration of another method.

[1145] FIG. 51 illustrates an example of an operation process of a second node in a system applicable to the present disclosure.

[1146] A first node may be a Near-RT RIC, a second node may be a RAN.

[1147] In step S5110, a second node transmits, to a first node, a first message including a list of RAN functions of the second node.

[1148] In step S5120, in response to the first message, the second node receives a second message including service information about supported services for the second node.

[1149] According to various embodiments of the present disclosure, the first message is an E2 SETUP REQUEST message, and wherein the second message is an E2 SETUP RESPONSE message.

[1150] According to various embodiments of the present disclosure, the first message is a RIC SERVICE UPDATE message, and wherein the second message is a RIC SERVICE UPDATE ACKNOWLEDGE message.

[1151] According to various embodiments of the present disclosure, the service information in the second message is associated with a revised RAN function definition in which, for a RAN function included in the first message, unsupported services that are not supported by the first node are excluded.

[1152] According to various embodiments of the present disclosure, detailed information about available services included in the second message includes a list of one or more RAN functions, each RAN function specifying one or more services provided by the first node.

[1153] According to various embodiments of the present disclosure, the service information in the second message includes a list of one or more RAN functions specifying one or more services provided by the first node.

[1154] According to various embodiments of the present disclosure, the method further comprises: receiving, from the first node, a cancellation message including a reason for cancellation of an ongoing service.

[1155] According to various embodiments of the present disclosure, there is provided a second node in a wireless communication system. The second node may include a transceiver and at least one processor, and the at least one processor may be configured to perform the operation method of the second node based on FIG. 51.

[1156] According to various embodiments of the present disclosure, there is provided a device controlling a second node in a wireless communication system. The device may include at least one processor and at least one memory operably connected to the at least one processor. The at least one memory may be configured to store instructions performing the operation method of the second node based on FIG. 51 based on being executed by the at least one processor.

[1157] According to various embodiments of the present disclosure, there are provided one or more non-transitory computer readable mediums (CRMs) storing one or more instructions. The one or more instructions may be configured to perform operations based on being executed by one or more processors, and the operations may include the operation method of the second node based on FIG. 51.

[1158]

[1159] Wireless device applicable to the present disclosure

[1160] Examples of wireless devices to which various embodiments of the present disclosure are applied are described below.

[1161] FIG. 52 illustrates an example of a structure of a first device and a second device in a system applicable to the present disclosure.

[1162] A first device 1600 may include a processor 1610, an antenna unit 1620, a transceiver 1630, and a memory 1640.

[1163] The processor 1610 may perform baseband-related signal processing and include a higher layer processing unit 1611 and a physical layer processing unit 1615. The higher layer processing unit 1611 may process operations of the MAC layer, the RRC layer, or higher layers. The physical layer processing unit 1615 may process the operation of the PHY layer. For example, if the first device 1600 is a base station (BS) device in BS-UE communication, the physical layer processing unit 1615 may perform uplink reception signal processing, downlink transmission signal processing, and the like. For example, if the first device 1600 is a first UE device in inter-UE communication, the physical layer processing unit 1615 may performs downlink reception signal processing, uplink transmission signal processing, sidelink transmission signal processing, and the like. The processor 1610 may control the overall operation of the first device 1600 in addition to performing the baseband-related signal processing.

[1164] The antenna unit 1620 may include one or more physical antennas and support MIMO transmission / reception if the antenna unit 1620 includes a plurality of antennas. The transceiver 1630 may include a radio frequency (RF) transmitter and an RF receiver. The memory 1640 may store information processed by the processor 1610 and software, operating systems, and applications related to the operation of the first device 1600. The memory 1640 may also include components such as a buffer.

[1165] The processor 1610 of the first device 1600 may be configured to implement the operation of the BS in the BS-UE communication (or the operation of the first UE device in the inter-UE communication) in embodiments described in the present disclosure.

[1166] The second device 1650 may include a processor 1660, an antenna unit 1670, a transceiver 1680, and a memory 1690.

[1167] The processor 1660 may perform baseband-related signal processing and include a higher layer processing unit 1661 and a physical layer processing unit 1665. The higher layer processing unit 1661 may process the operation of the MAC layer, the RRC layer, or higher layers. The physical layer processing unit 1665 may process the operation of the PHY layer. For example, if the second device 1650 is a UE device in BS-UE communication, the physical layer processing unit 1665 may perform downlink reception signal processing, uplink transmission signal processing, and the like. For example, if the second device 1650 is a second UE device in inter-UE communication, the physical layer processing unit 1665 may perform downlink reception signal processing, uplink transmission signal processing, sidelink reception signal processing, and the like. The processor 1660 may control the overall operation of the second device 1660 in addition to performing the baseband-related signal processing.

[1168] The antenna unit 1670 may include one or more physical antennas and support MIMO transmission / reception if the antenna unit 1670 includes a plurality of antennas. The transceiver 1680 may include an RF transmitter and an RF receiver. The memory 1690 may store information processed by the processor 1660 and software, operating systems, and applications related to the operation of the second device 1650. The memory 1690 may also include components such as a buffer.

[1169] The processor 1660 of the second device 1650 may be configured to implement the operation of the UE in the BS-UE communication (or the operation of the second UE device in the inter-UE communication) in embodiments described in the present disclosure.

[1170] The descriptions for the BS and the UE in the BS-UE communication (or the first UE device and the second UE device in the inter-UE communication) in the examples of the present disclosure can be equally applied to the operations of the first device 1600 and the second device 1650, and redundant descriptions are omitted.

[1171] Wireless communication technologies implemented in the devices 1600 and 1650 according to the present disclosure may include LTE, NR, and 6G, as well as various other wireless communication technologies.

[1172] The claims described in various embodiments of the present disclosure can be combined in various ways. For example, technical features of the method claims of various embodiments of the present disclosure can be combined and implemented as a device, and technical features of the device claims of various embodiments of the present disclosure can be combined and implemented as a method. In addition, the technical features of the method claims and the technical features of the device claims in various embodiments of the present disclosure can be combined and implemented as a device, and the technical features of the method claims and the technical features of the device claims in various embodiments of the present disclosure can be combined and implemented as a method.

Claims

A method performed by a first node, the method comprising:receiving, from a second node, a first message including a list of radio access network (RAN) functions of the second node; andin response to the first message, transmitting, to the second node, a second message including service information about supported services for the second node.The method of claim 1, wherein the first message is an E2 SETUP REQUEST message, and wherein the second message is an E2 SETUP RESPONSE message.The method of claim 1, wherein the first message is a RIC SERVICE UPDATE message, and wherein the second message is a RIC SERVICE UPDATE ACKNOWLEDGE message.The method of claim 1, wherein the service information in the second message is associated with a revised RAN function definition in which, for a RAN function included in the first message, unsupported services that are not supported by the first node are excluded.The method of claim 1, wherein detailed information about available services included in the second message includes a list of one or more RAN functions, each RAN function specifying one or more services provided by the first node.The method of claim 1, wherein the service information in the second message includes a list of one or more RAN functions specifying one or more services provided by the first node.The method of claim 1, further comprising:determining to cancel an ongoing service; andtransmitting, to the second node, a cancellation message including a reason for cancellation of the ongoing service.A method performed by a second node, the method comprising:transmitting, to a first node, a first message including a list of RAN functions of the second node; andin response to the first message, receiving, from the first node, a second message including service information about supported services for the second node.The method of claim 8, wherein the first message is an E2 SETUP REQUEST message, and wherein the second message is an E2 SETUP RESPONSE message.The method of claim 8, wherein the first message is a RIC SERVICE UPDATE message, and wherein the second message is a RIC SERVICE UPDATE ACKNOWLEDGE message.The method of claim 8, wherein the service information in the second message is associated with a revised RAN function definition in which, for a RAN function included in the first message, unsupported services that are not supported by the first node are excluded.The method of claim 8, wherein detailed information about available services included in the second message includes a list of one or more RAN functions, each RAN function specifying one or more services provided by the first node.The method of claim 8, wherein the service information in the second message includes a list of one or more RAN functions specifying one or more services provided by the first node.The method of claim 8, further comprising:receiving, from the first node, a cancellation message including a reason for cancellation of an ongoing service.A first node comprising:a transceiver;at least one processor; andat least one memory operably coupled to the at least one processor and storing instructions that, when executed by the at least one processor, cause the first node to perform the method of any one of claims 1 to 7.A second node comprising:a transceiver;at least one processor; andat least one memory operably coupled to the at least one processor and storing instructions that, when executed by the at least one processor, cause the second node to perform the method of any one of claims 8 to 14.A control apparatus for controlling a first node, the control apparatus comprising:at least one processor; andat least one memory operably coupled to the at least one processor and storing instructions that, when executed by the at least one processor, cause the control apparatus to perform the method of any one of claims 1 to 7.A control apparatus for controlling a second node, the control apparatus comprising:at least one processor; andat least one memory operably coupled to the at least one processor and storing instructions that, when executed by the at least one processor, cause the control apparatus to perform the method of any one of claims 8 to 14.A non-transitory computer-readable medium storing one or more instructions which, when executed by one or more processors, cause the one or more processors to perform the method of any one of claims 1 to 7.A non-transitory computer-readable medium storing one or more instructions which, when executed by one or more processors, cause the one or more processors to perform the method of any one of claims 8 to 14.

Images