CN117204012A - Apparatus and method for controlling E2 node in wireless communication system - Google Patents

Abstract

The present disclosure relates to a prior fifth generation (5G) or 5G communication system to be provided for supporting higher data rates beyond fourth generation (4G) communication systems, such as Long Term Evolution (LTE). According to an embodiment, a method performed by a near RT (real time) RIC (radio access network (RAN) intelligent controller (RIC)), the method comprising: transmitting a RIC control request message including information about a control action Identity (ID) to the E2 node, and receiving a RIC control acknowledge message or a RIC control failure message from the E2 node in response to the RIC control request message, wherein the RIC control acknowledge message or the RIC control failure message includes information about a RIC control result, wherein the information about the RIC control result includes at least one RAN parameter set, wherein each of the at least one RAN parameter set includes a RAN parameter ID and a RAN parameter value.

Description

Apparatus and method for controlling E2 node in wireless communication system

Technical Field

The present disclosure relates to an apparatus and method for controlling an E2 node by a Radio Access Network (RAN) intelligent controller (RIC) in a RAN. More particularly, the present disclosure relates to an apparatus and method for controlling an E2 node through an E2 message conforming to an open RAN (O-RAN) of a wireless communication system.

Background

In order to meet the increasing wireless data traffic demands since the deployment of fourth generation (4G) communication systems, efforts have been made to develop improved fifth generation (5G) or former 5G communication systems. Thus, a 5G or former 5G communication system is also referred to as a "beyond 4G network" or a "Long Term Evolution (LTE) after" system.

A 5G communication system is considered to be implemented in a higher frequency (millimeter wave mmWave) band, for example, a 60GHz band, in order to achieve a higher data rate. In order to reduce propagation loss of radio waves and increase transmission distance, beamforming, massive Multiple Input Multiple Output (MIMO), full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, massive antenna techniques are discussed in 5G communication systems.

Further, in the 5G communication system, system network improvement development based on advanced small cells, cloud Radio Access Networks (RANs), ultra dense networks, device-to-device (D2D) communication, wireless backhaul, mobile networks, cooperative communication, cooperative multipoint (CoMP), reception-side interference cancellation, and the like is underway.

In 5G systems, hybrid Frequency Shift Keying (FSK) and Quadrature Amplitude Modulation (QAM) (FQAM) as Advanced Code Modulation (ACM) and Sliding Window Superposition Coding (SWSC), and Filter Bank Multicarrier (FBMC), non-orthogonal multiple access (NOMA) and Sparse Code Multiple Access (SCMA) as advanced access technologies have been developed.

To meet the demand for wireless data services, 5G systems, new or Next Radios (NRs), have been commercialized, providing higher data rate services like 4G to users through 5G systems, also for internet of things and specific purposes. It is desirable to be able to provide wireless communication services having various purposes, such as services requiring higher reliability. The open radio access network (O-RAN) is a new Network Element (NE) and interface standard based on the existing 3GPP standard, established by aggregation (linking) and established by operators and equipment providers in a system mixed with the current fourth-generation communication system and fifth-generation system. Is defined and an O-RAN architecture is proposed.

The foregoing information is presented merely as background information to aid in the understanding of the disclosure. No determination is made, nor is an assertion made, as to whether any of the above may be applied to the present disclosure as prior art.

Disclosure of Invention

Technical problem

Aspects of the present disclosure aim to address at least the above problems and/or disadvantages and to provide at least the advantages described below.

Accordingly, it is an aspect of the present disclosure to provide an apparatus and method for generating and transmitting a message with details of an error occurring if a Radio Access Network (RAN) intelligent controller (RIC) controls an E2 node in a wireless communication system.

Another aspect of the present disclosure is to provide an apparatus and method for configuring an E2 node through a RIC, causing the E2 node to transmit error details under the control of the RIC.

Additional aspects will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the embodiments.

Problem solution

According to aspects of the present disclosure, a method performed by a Radio Access Network (RAN) intelligent controller (RIC) is provided. The method comprises the following steps: receiving a setup request message from the E2 node including RAN function information specific to the service model, the RAN function information including information about one or more control actions, transmitting a setup response message to the E2 node, transmitting a RIC control request message to the E2 node, and receiving a RIC control acknowledgment message from the E2 node. The RIC control request message includes identification information of a control action of the one or more control actions, the RIC control acknowledge message includes RIC control result information of the control action, and the RIC control result information includes a cause of an event of the control action in the specific protocol.

According to another aspect of the disclosure, a method performed by an E2 node is provided. The method comprises the following steps: a method includes sending a setup request message to a Radio Access Network (RAN) intelligent controller (RIC) that includes RAN function information specific to a service model, the RAN function information including information about one or more control actions, receiving a setup response message from the RIC, receiving a RIC control request message from the RIC, and sending a RIC control acknowledgment message to the RIC. The RIC control request message includes identification information of a control action of the one or more control actions, the RIC control acknowledge message includes RIC control result information of the control action, and the RIC control result information includes a cause of an event of the control action in the specific protocol.

According to another aspect of the present disclosure, an apparatus of a Radio Access Network (RAN) intelligent controller (RIC) is provided. The apparatus includes at least one transceiver and at least one processor. The at least one processor is configured to control the at least one transceiver to receive a setup request message from the E2 node comprising RAN functionality information specific to the service model, the RAN functionality information comprising information about one or more control actions, to send a setup response message to the E2 node, to send a RIC control request message to the E2 node, and to receive a RIC control acknowledgment message from the E2 node. The RIC control request message includes identification information of a control action of the one or more control actions, the RIC control acknowledge message includes RIC control result information of the control action, and the RIC control result information includes a cause of an event of the control action in the specific protocol.

According to another aspect of the present disclosure, an apparatus of an E2 node is provided. The apparatus includes at least one transceiver and at least one processor. The at least one processor is configured to control the at least one transceiver to send a setup request message to a Radio Access Network (RAN) intelligent controller (RIC) that includes RAN function information specific to a service model, the RAN function information including information about one or more control actions, receive a setup response message from the RIC, receive a RIC control request message from the RIC, and send a RIC control acknowledgment message to the RIC. The RIC control request message includes identification information of a control action of the one or more control actions, the RIC control acknowledge message includes RIC control result information of the control action, and the RIC control result information includes a cause of an event of the control action in the specific protocol.

According to another aspect of the disclosure, a method performed by a near RT (real time) RIC (radio access network (RAN) intelligent controller (RIC)), the method comprising: transmitting a RIC control request message including information about a control action Identity (ID) to the E2 node, and receiving a RIC control acknowledge message or a RIC control failure message from the E2 node in response to the RIC control request message, wherein the RIC control acknowledge message or the RIC control failure message includes information about a RIC control result, wherein the information about the RIC control result includes at least one RAN parameter set, wherein each of the at least one RAN parameter set includes a RAN parameter ID and a RAN parameter value.

According to another aspect of the disclosure, a method performed by an E2 node, the method comprising: receiving an RIC control request message including information about a control action Identity (ID) from a near RT (real time) RIC (radio access network (RAN) intelligent controller (RIC)), and transmitting a RIC control acknowledge message or RIC control failure message in response to the RIC control request message to the near RT RIC, wherein the RIC control acknowledge message or RIC control failure message includes information about a RIC control result, wherein the information about the RIC control result includes at least one RAN parameter set, wherein each of the at least one RAN parameter set includes a RAN parameter ID and a RAN parameter value.

According to another aspect of the disclosure, an apparatus of a near RT (real time) RIC (radio access network (RAN) intelligent controller (RIC)) includes: at least one transceiver; and at least one processor coupled to the at least one transceiver, wherein the at least one processor is configured to: transmitting a RIC control request message including information about a control action Identity (ID) to the E2 node, and receiving a RIC control acknowledge message or a RIC control failure message from the E2 node in response to the RIC control request message, wherein the RIC control acknowledge message or the RIC control failure message includes information about a RIC control result, wherein the information about the RIC control result includes at least one RAN parameter set, wherein each of the at least one RAN parameter set includes a RAN parameter ID and a RAN parameter value.

According to another aspect of the disclosure, an apparatus of an E2 node includes: at least one transceiver; and at least one processor coupled to the at least one transceiver, wherein the at least one processor is configured to: receiving an RIC control request message including information about a control action Identity (ID) from a near RT (real time) RIC (radio access network (RAN) intelligent controller (RIC)), and transmitting a RIC control acknowledge message or RIC control failure message in response to the RIC control request message to the near RT RIC, wherein the RIC control acknowledge message or RIC control failure message includes information about a RIC control result, wherein the information about the RIC control result includes at least one RAN parameter set, wherein each of the at least one RAN parameter set includes a RAN parameter ID and a RAN parameter value.

Advantageous effects of the invention

Apparatus and methods according to embodiments of the present disclosure enable an E2 node to notify a Radio Access Network (RAN) intelligent controller (RIC) of a cause based on an event occurrence (e.g., failure).

Other aspects, advantages, and salient features of the disclosure will become apparent to those skilled in the art from the following detailed description, which, taken in conjunction with the annexed drawings, discloses various embodiments of the disclosure.

Drawings

The foregoing and other aspects, features, and advantages of certain embodiments of the disclosure will become more apparent from the following description taken in conjunction with the accompanying drawings in which:

fig. 1 illustrates an example of a fourth generation (4G) Long Term Evolution (LTE) core system in accordance with an embodiment of the present disclosure;

fig. 2a shows an example of a fifth generation (5G) non-standalone (NSA) system according to an embodiment of the present disclosure;

fig. 2b shows an architecture example of an open radio access network (O-RAN) according to an embodiment of the present disclosure;

fig. 3 illustrates a protocol stack of an E2 application protocol message in a radio access network according to an embodiment of the present disclosure;

fig. 4 illustrates an example of a connection between a base station and a Radio Access Network (RAN) intelligent controller (RIC) in a radio access network according to an embodiment of the present disclosure;

Fig. 5 shows a configuration of devices in a radio access network according to an embodiment of the present disclosure;

fig. 6 illustrates logic functions related to E2 messages of an RIC and an E2 node in a radio access network according to an embodiment of the present disclosure;

FIG. 7 illustrates an example of functional partitioning between an E2 node and a RIC according to an embodiment of the present disclosure;

FIG. 8 illustrates an example implementation of an E2 node and RIC according to an embodiment of the present disclosure;

FIG. 9 illustrates an example of functional partitioning between a Centralized Unit (CU) and RICs according to an embodiment of the present disclosure;

fig. 10 illustrates an example of Mobility Load Balancing (MLB) control for different vendors according to an embodiment of the present disclosure;

FIG. 11a illustrates an example of MLB control of different vendors according to an embodiment of the disclosure;

fig. 11b illustrates signaling of a Radio Resource Management (RRM) control configuration of a near real-time (near RT) RIC according to an embodiment of the disclosure;

fig. 12a and 12b illustrate signaling of RIC-based RRM control according to an embodiment of the present disclosure;

FIG. 13a illustrates signaling of a setup procedure between an E2 node and a RIC according to an embodiment of the present disclosure;

FIG. 13b illustrates signaling of a control procedure between an E2 node and a RIC according to an embodiment of the present disclosure;

FIG. 13c illustrates signaling of a subscription procedure between an E2 node and a RIC according to an embodiment of the present disclosure;

FIG. 14a shows an example of a RIC control request message format according to an embodiment of the present disclosure;

FIG. 14b shows an example of a RIC control acknowledgment message format according to an embodiment of the present disclosure;

fig. 15 illustrates an example of an E2 service model RAN control (E2 SM-RC) control result Information Element (IE) in a RIC control acknowledgment message according to an embodiment of the present disclosure;

fig. 16a, 16b and 16c illustrate examples of RIC control acknowledgment messages for transmitting a cause IE according to embodiments of the present disclosure;

FIG. 17 illustrates an example of a subsequent action to the RIC action according to an embodiment of the present disclosure;

FIG. 18 illustrates an example of RIC mode types according to an embodiment of the present disclosure; and

fig. 19 illustrates an example of a RIC control acknowledgment message for transmitting a cause IE according to an embodiment of the present disclosure.

It should be noted that throughout the appended drawings, the same reference numerals are used to describe the same or similar elements, features and structures.

Detailed Description

The following description is provided with reference to the accompanying drawings to assist in a comprehensive understanding of the various embodiments of the disclosure as defined by the claims and their equivalents. It includes various specific details to aid understanding, but these are to be considered exemplary only. Accordingly, one of ordinary skill in the art will recognize that various changes and modifications of the various embodiments described herein can be made without departing from the scope and spirit of the present disclosure. In addition, descriptions of well-known functions and constructions may be omitted for clarity and conciseness.

The terms and words used in the following description and claims are not limited to a bookend, but are used by the inventors only to ensure a clear and consistent understanding of the present disclosure. Accordingly, it will be apparent to those skilled in the art that the following descriptions of the various embodiments of the present disclosure are provided for illustration only and not for the purpose of limiting the disclosure as defined by the appended claims and their equivalents.

It is to be understood that the singular forms "a", "an" and "the" include plural referents unless the context clearly dictates otherwise. Thus, for example, reference to "a component surface" includes reference to one or more such surfaces.

The terminology used in the present disclosure is for the purpose of describing particular embodiments only and is not intended to limit the scope of other embodiments. Singular expressions may include plural expressions unless the context clearly indicates otherwise. The terms used herein, including technical or scientific terms, may have the same meaning as commonly understood by one of ordinary skill in the art described in this disclosure. In terms used in the present disclosure, terms defined in a general dictionary may be interpreted as having the same or similar meaning as terms in the context of the related art, and are not to be interpreted in an ideal or excessively formal sense unless explicitly defined in the present disclosure. In some cases, even terms defined in the present disclosure cannot be construed as excluding the embodiments of the present disclosure.

Various embodiments of the present disclosure will be described below based on hardware methods. However, the various embodiments of the present disclosure include techniques that use both hardware and software, and thus the various embodiments of the present disclosure do not exclude the perspective of software.

Hereinafter, the present disclosure relates to a control procedure between a device in a Radio Access Network (RAN) and a device for controlling the RAN in a wireless communication system. In particular, the present disclosure relates to a program, message and method for transmitting a RIC control request message from a RIC to an E2 node over an E2 interface in a radio access network, identifying whether the RIC control request of the E2 node is made correctly or failed, and if it fails, determining the cause thereof.

For convenience of description, signal terms, terms indicating channels, terms indicating control information, terms indicating network entities, and terms indicating device components used in the following description are shown. Accordingly, the present disclosure is not limited to terms to be described, and other terms having the same technical meaning may be used.

Further, in the present disclosure, in order to determine whether a specific condition is achieved or satisfied, an expression such as greater than or less than is used, but this is merely an exemplary expression, and an expression equal to or greater than or equal to or less than is not excluded. Conditions expressed as "greater than or equal to" may be replaced with "greater than" and conditions expressed as "less than or equal to" may be replaced with "less than" and conditions expressed as "greater than or equal to and less than" may be replaced with "greater than and less than or equal to".

Furthermore, the present disclosure describes various embodiments using terms used in some communication standards, e.g., third generation partnership project (3 GPP), open radio access network (O-RAN), but this is merely an example for description. Various embodiments of the present disclosure may be readily modified and applied to other communication systems.

With the commercialization of fourth generation (4G)/fifth generation (5G) communication systems (e.g., new Radios (NRs)), differentiated services to users need to be supported in virtualized networks. The 3GPP is a joint research project of mobile communication related communities and works to write a globally applicable third generation (3G) mobile communication system standard within the scope of the IMT-2000 project of the International Telecommunication Union (ITU). The 3GPP was established in month 12 of 1998, and the 3GPP standard was based on the enhanced GSM standard and included radio and core networks and a service architecture within standardized ranges. Thus, an open radio access network (O-RAN) may redefine a Radio Unit (RU), a Digital Unit (DU), a central unit control plane (CU-CP), and a CU-user plane (CU-UP), which are nodes configured as base stations and 3GPP network entities (3 GPP NEs), respectively, as O (O-RAN) -RU, O-DU, O-CU-CP, and O-CU-UP, and may additionally standardize Near Real Time (NRT) radio access network intelligent controllers (RIC). The present disclosure supports an operator-specific service model in the E2 interface, where the RIC requests services from O-DUs, O-CU-CPs, or O-CU-UPs. Here, O-RU, O-DU, O-CU-CP, O-CU-UP may be understood as objects operable according to the O-RAN standard, included in the RAN, and referred to as E2 nodes. An application protocol (E2 AP) may be used as an interface between an RIC and an E2 node that are objects operable according to the O-RAN standard and included in the RAN.

The RIC may be a logical node that may collect information associated with a cell site in which a UE and an O-DU, O-CU-CP, or O-CU-UP perform transmission or reception. The RIC may be implemented in the form of a server centrally located (dispose) in a single physical location. Connections between the O-DU and the RIC, between the O-CU-CP and the RIC, and between the O-CU-UP and the RIC may be established via Ethernet. For this purpose, communication interface standards between O-DU and RIC, between O-CU-CP and RIC, and between O-CU-UP and RIC are required. It may be necessary to define message standards such as E2-DU, E2-CU-CP, etc. and procedures between RIC and each of O-DU, O-CU-CP, O-CU-UP. In particular, differentiated services to users may need to be supported in a virtualized network, and functions of defining messages of E2-DUs, E2-CU-CPs, and E2-CU-UPs may be required for supporting services regarding a wide cell coverage area by centrally processing messages/functions of calls generated in an O-RAN in a RIC.

The RIC may perform communication with the O-CU, O-CU-CP, and O-CU-UP using the E2 interface, and may configure conditions for generating events by generating and transmitting subscription messages. In particular, the RIC may generate and transmit an E2 subscription request (subscription Request) message to E2 nodes (e.g., O-CU-CP, O-CU-UP, and O-DU) to configure call processing events. After the configuration event, the E2 node may transmit a subscription request response message to the RIC.

The E2 node may send the current state to the RIC via an E2 indication/report. RIC can control O-DU, O-CU-CP and O-CU-UP by using E2 control messages. Various embodiments of the present disclosure may suggest an E2 indication message that includes measurement information of each UE and is transmitted from an O-DU at intervals configured in the condition of a subscription event. Furthermore, various embodiments of the present disclosure may suggest sending resource control messages from the RIC to the O-DUs.

Fig. 1 illustrates an example of a fourth generation (4G) Long Term Evolution (LTE) core system in accordance with an embodiment of the present disclosure.

Referring to fig. 1, the lte core system includes a base station 110, a terminal 120, a serving gateway (S-GW) 130, a packet data network gateway (P-GW) 140, a Mobility Management Entity (MME) 150, a Home Subscriber Server (HSS) 160, and a Policy and Charging Rules Function (PCRF) 170.

Base station 110 is a network infrastructure for providing radio access to terminals 120. For example, the base station 110 is a device that performs scheduling by collecting status information such as a buffer status, an available transmission power, and a channel status of the terminal 120. The base station 110 has a coverage area defined as a specific geographical area based on a signal transmission distance. The base station 110 is connected to the MME 150 through an S1-MME interface. In addition to base stations, base station 110 may be referred to as an "Access Point (AP)", "eNodeB (eNB)", "wireless point" and "transmission/reception point (TRP)" or other terms having equivalent technical meaning.

The terminal 120 is a device used by a user and performs communication with the base station 110 through a radio channel. In some cases, the terminal 120 may operate without user involvement. That is, at least one of the terminal 120 and the S-GW 130 is a device performing Machine Type Communication (MTC) and may not be carried by a user. In addition to terminals, the terminals 120 may be referred to as "UEs", "mobile stations", "subscriber stations", "Customer Premise Equipment (CPE)", "remote terminals", "wireless terminals" or "user equipment", or other terms having technical equivalents.

The S-GW 130 provides data bearers and generates or controls the data bearers under control of the MME 150. For example, the S-GW 130 processes a packet arriving from the base station 110 or a packet to be forwarded to the base station 110. In addition, the S-GW 130 may perform an anchor role in handover of the terminal 120 between base stations. The P-GW 140 may serve as a connection point to an external network (e.g., the internet). In addition, the P-GW 140 assigns an Internet Protocol (IP) address to the terminal 120 and serves as an anchor for the S-GW 130. In addition, the P-GW 140 may apply a quality of service (QoS) policy of the terminal 120 and manage charging data.

MME 150 manages mobility for terminal 120. Further, the MME 150 may perform authentication, bearer management, etc. for the terminal 120. That is, the MME 150 is responsible for mobility management and various control functions of the terminal. The MME 150 may interwork with a serving General Packet Radio Service (GPRS) support node (SGSN).

HSS160 stores key information and user profiles for authentication of terminal 120. If the terminal 120 accesses the network, the key information and the user profile are sent from the HSS160 to the MME 150.

PCRF 170 defines policy and charging rules. The stored information is sent from PCRF 180 to P-GW 140, and P-GW 140 may control terminal 120 (e.g., qoS management, charging, etc.) based on the information provided from PCRF 180.

The carrier aggregation (hereinafter, abbreviated as "CA") technology is a technology that combines a plurality of component carriers and simultaneously uses the plurality of component carriers to transmit and receive signals at one terminal, thereby improving the frequency use efficiency of the terminal or the base station. In particular, according to the CA technology, a terminal and a base station can transmit and receive signals using a wideband using a plurality of component carriers in Uplink (UL) and Downlink (DL), wherein the component carriers are located in different frequency bands, respectively. Thereafter, the UL instructs the communication link through which the terminal transmits signals to the base station, and the DL instructs the communication link through which the base station transmits signals to the terminal. At this time, the number of uplink component carriers and downlink component carriers may be different.

Dual connectivity or multiple connectivity is a technique for improving the frequency usage efficiency of a terminal or base station, where one terminal is connected to a plurality of different base stations and simultaneously transmits and receives signals using carriers within the plurality of base stations located in different frequency bands. A terminal may be simultaneously connected to a first base station (e.g., a base station providing service using LTE technology or 4G mobile communication technology) and a second base station (e.g., a base station providing service using NR technology or 5G mobile communication technology) to transmit and receive traffic. In this case, the frequency resources used by each base station may be located in different frequency bands. As such, the operating scheme of the dual connectivity scheme based on LTE and NR may be referred to as 5G non-independent (NSA).

Fig. 2a shows an example of a 5G NSA system according to an embodiment of the present disclosure.

Referring to fig. 2a, the 5g NSA system includes an NR RAN 210a, an LTE RAN 210b, a terminal 220, and an evolved packet core network (EPC) 250.NR RAN 210a and LTE RAN 210b are connected to EPC 250, and terminal 220 may be served by either or both of NR RAN 210a and LTE RAN 210 b. The NR RAN 210a includes at least one NR base station, while the LTE RAN 210b includes at least one LTE base station. Here, the NR base station may be referred to as a "5G node", "next generation node B (gNB)" or other terms having an equivalent technical meaning. Further, the NR base station may have a structure split into CU and DU, and the CU may also have a structure split into a CU-CP unit and a CU-UP unit.

In the structure shown in fig. 2a, the terminal 220 may perform Radio Resource Control (RRC) access through a first base station (e.g., a base station belonging to the LTE RAN 210 b), and may use functions (e.g., connection management, mobility management, etc.) provided in a control plane. Further, the terminal 220 may receive additional radio resources for transmitting and receiving data via a second base station (e.g., a base station belonging to the NR RAN 210 a). This dual connectivity technique using LTE and NR may be referred to as evolved universal terrestrial radio access (E-UTRA) -NR (EN) -Dual Connectivity (DC). Similarly, a dual connectivity technique where a first base station uses NR technology and a second base station uses LTE technology is referred to as NR-E-UTRA (NE) -DC. Furthermore, various embodiments may be applied to multiple connections and various types of CA technologies. Furthermore, various embodiments are applicable even if the first system using the first communication technology and the second system using the second communication technology are implemented in one device, or if the first base station and the second base station are located in the same geographical location.

Fig. 2b shows an architecture example of an O-RAN. For E2 service model Key Performance Indicator (KPI) (E2-SM-KPI) monitoring (KPIMON) of an E2 Service Model (SM), consider the O-RAN independence in multi-connectivity operation using E-UTRA and NR radio access technologies, whereas an E2 node may be assumed to be in an O-RAN independence mode in accordance with embodiments of the present disclosure.

Referring to fig. 2b, in an O-RAN dependent mode deployment, the eNB is connected to the EPC through the S1-C/S1-U interface and to the O-CU-CP through the X2 interface. An O-CU-CP for deploying O-RAN independent modes may be connected to a 5G core (5 GC) through an N2/N3 interface.

Fig. 3 illustrates a protocol stack of an E2 application protocol message in a radio access network according to an embodiment of the present disclosure. Referring to fig. 3, the control plane includes a transport network layer and a radio network layer. The transport network layers include a physical layer 310, a data link layer 320, an Internet Protocol (IP) layer 330, and a Stream Control Transmission Protocol (SCTP) layer 340.

The radio network layer includes an E2 application protocol (E2 AP) 350. The E2AP 350 is used to deliver subscription messages, indication messages, control messages, service update messages, and service query messages, and is transmitted in higher layers of the SCTP 340 and the IP 330.

Fig. 4 shows an example of a connection between a base station and a RIC in a radio access network according to an embodiment of the present disclosure.

Referring to FIG. 4, RIC 440 is connected to O-CU-CP 420, O-CU-UP 410, and O-DU 430.RIC 440 is a device for new services or regional resource optimization custom RAN functions. RIC 440 may provide functionality such as network intelligence (e.g., policy enforcement, handover optimization), resource guarantees (e.g., radio link management, advanced self-organizing networks (SON)), resource control (e.g., load balancing, slicing policies), and the like. RIC 440 may communicate with O-CU-CP 420, O-CU-UP 410, and O-DU 430.RIC 440 may be connected to each node through E2-CP, E2-UP, and E2-DU interfaces. Further, the interface between the O-CU-CP and DU and between the O-CU-UP and DU may be referred to as the F1 interface. In the following description, DU and O-DU, CU-CP and O-CU-CP, and CU-UP and O-CU-UP may be used interchangeably.

Although fig. 4 shows one RIC 440, multiple RIC may be present according to different embodiments. Multiple RIC's may be implemented with multiple hardware located in the same physical location, or may be implemented through virtualization using a single hardware.

Fig. 5 shows a configuration of an apparatus according to an embodiment of the present disclosure. The structure shown in fig. 5 may be understood as a configuration of a device having at least one function of the RIC, O-CU-CP, O-CU-UP, and O-DU of fig. 5. Terms such as "… … unit" or "… … unit (-er)" used hereinafter indicate a unit for processing at least one function or operation, and may be implemented using hardware, software, or a combination of hardware and software.

Referring to fig. 5, the core network device includes a communication unit 510 (e.g., a transceiver), a storage unit 520 (e.g., a memory), and a control unit 530 (e.g., a processor).

The communication unit 510 provides an interface for performing communication with other devices in the network. That is, the communication unit 510 converts a bit string transmitted from the core network device to other devices into a physical signal, and converts a physical signal received from other devices into a bit string. That is, the communication unit 510 may transmit and receive signals. Accordingly, the communication unit 510 may be referred to as a modem, a transmitter, a receiver, or a transceiver. In this case, the communication unit 510 enables the core network device to communicate with other devices or systems via a backhaul connection (e.g., a wired backhaul or a wireless backhaul) or through a network.

The storage unit 520 stores data such as basic programs, application programs, and setting information of the operation of the core network device. The storage unit 520 may include volatile memory, nonvolatile memory, or a combination of volatile and nonvolatile memory. The storage unit 520 provides stored data according to a request of the control unit 530.

The control unit 530 controls general operations of the core network device. For example, the control unit 530 transmits and receives signals through the communication unit 510. Further, the control unit 530 records data in the storage unit 520 and reads data from the storage unit 520. To this end, the control unit 530 may include at least one processor. According to various embodiments, the control unit 530 may control the apparatus to perform operations according to various embodiments explained in the present disclosure.

Fig. 6 illustrates logic functions related to E2 messages of an RIC and an E2 node in a radio access network according to an embodiment of the present disclosure.

Referring to fig. 6, ric 640 and E2 node 610 may send or receive E2 messages to each other. For example, E2 node 610 may be an O-CU-CP, O-CU-UP, O-DU, or base station. The communication interface of the E2 node may be determined according to the type of the E2 node 610. For example, the E2 node 610 may communicate with another E2 node 616 via an E1 interface or an F1 interface. Alternatively, E2 node 610 may communicate with E2 node 616 via an X2 interface or an XN interface, for example. Alternatively, E2 node 610 may perform communication through an S1 interface or a Next Generation Application Protocol (NGAP) interface, i.e., an interface between a Next Generation (NG) RAN node and an Access and Mobility Function (AMF), for example.

The E2 node 610 may include an E2 node function 612. E2 node function 612 is a function corresponding to a particular xApp (application software (S/W)) 646 installed in RIC 640. For example, in a KPI monitor, a KPI monitor collection S/W may be installed in RIC 640, and E2 node 610 may comprise E2 node function 612, E2 node function 612 generating KPI parameters, and then forwarding an E2 message comprising the KPI parameters to E2 terminal 642 located at RIC 640. The E2 node 610 may include a Radio Resource Management (RRM) 614. The E2 node 610 may manage resources provided to the radio network for the terminal.

The E2 terminal 624 located in RIC 640 is the terminal of RIC 640 for E2 messages, may perform the function of interpreting E2 messages forwarded by E2 node 610 and then forwarding it to xApp 646. A Database (DB) 644 located in RIC 640 may be used for E2 terminal 624 or xApp 646. The E2 node 610 shown in fig. 6 is a terminal of at least one interface and may be understood as a terminal of a message transmitted to the terminal, a neighboring base station, and a core network.

Fig. 7 illustrates an example of functional partitioning between an E2 node and RIC according to an embodiment of the present disclosure. The O-RAN standard provides a functional division between E2 nodes and RIC. For example, the E2 node may be a CU. The RIC may be a near RT RIC. The RIC may be connected to an Open Network Automation Platform (ONAP)/management and coordination (MANO)/Network Management System (NMS) via an A1 interface. The RIC may be connected to the E2 node through an E2 interface. The E2 interface may transmit commands. The functional partitioning options may include functional partitioning 700 to manage the entire RRM at the near RT RIC, and functional partitioning 750 to selectively manage RRM at the near RT RIC.

According to the WG3 decision of 2019/01/16 conference, near RT RIC supports E2 as an open logical interface for multi-vendor environments, regardless of the specific RRC-RRM algorithm implementation at nRT-RIC. The present disclosure may suggest an E2 service model radio interface control (E2 SM-RIC) paired with E2SM-NI for injecting/modifying/configuring per UE RRC messages for each I/F and Network Entity (NE). In other words, the near RT RIC may gradually improve from functional partition 750 to functional partition 700. E2 may advance to an open logical interface that is independent of the specific RRC-RRM algorithm implementation in nRT-RIC and for a multi-vendor environment.

Fig. 8 illustrates an example implementation of an E2 node and RIC according to an embodiment of the present disclosure. In the scenario of implementation example 800, E2 nodes (e.g., O-DUs, O-CUs) and RIC may be virtualized on a cloud platform (e.g., open chassis and blade specification edge cloud) and configured in devices (e.g., servers). Such a scenario may support distribution in congested metropolitan areas with large amounts of forward capacity, allowing for polling of baseband unit (BBU) functions at a central location with low enough latency to meet O-DU standby requirements. Thus, in concentrating O-DU functions, it may not be necessary to attempt to concentrate RICs near RTs. According to an embodiment, the E2SM-RIC may be optimized for an O-RAN distribution scenario that implements near RT RIC, O-CU and O-DU on an O-cloud platform.

Fig. 9 shows a functional partitioning example between CUs and RIC according to an embodiment of the present disclosure. Referring to fig. 9, function division may be performed according to a deployment scenario #1 900 or a function deployment scenario #2 950.

Deployment scenario #1 900: RIC may be located at a separate site or exist as a different NE and replaced or recommended to a small number of functions requiring intelligence.

Deployment scenario #2 950: RIC may replace almost all UE functions except 3GPP I/F management.

Although fig. 9 shows two scenarios, other scenarios may also be applied. For example, in deployment scenario #1 900, the mobility function may be performed by the RIC instead of the CU. Further, for example, in deployment scenario #1 900, the UE context may be performed by the RIC instead of the CU. Further, for example, in deployment scenario #1 900, the session configuration function may be performed by the RIC instead of the CU.

Fig. 10 illustrates an example 1000 of Mobility Load Balancing (MLB) control for different vendors according to an embodiment of the present disclosure. Such MLB may be performed under control of RRM. The first CU and the first DU may be provided by vendor a. The second CU and the second DU may be provided by vendor B. The first DU may provide a service area for vendor a. An RU connected to the first DU may provide a service area of provider a. The second DU may provide a service area for vendor B. The RU connected to the second DU may provide a service area of provider B.

It is possible to determine which cell is optimal when the UE moves through load balancing. If such load balancing is performed by different suppliers, it may be difficult to smoothly perform load balancing in a space where service areas of the suppliers overlap. That is, inter-provider areas or CU-CP areas may require inter-provider communication. For interworking of providers, RRM control may need to be centrally performed. Thus, RIC 1050 according to various embodiments of the present disclosure may be configured to perform RRM. RIC 1050 may not only receive measurements from each E2 node, but may also generate messages for controlling each E2 node. RIC 1050 may send control messages to each E2 node (e.g., DU or CU-CP, CU-UP).

Fig. 11a shows an example of MLB control for different vendors according to an embodiment of the present disclosure. First, unlike fig. 11a, if a single vendor is operating, the RAN context can be identified at the near RT RIC. In addition, trigger events/reports, insertions, policy conditions may operate. The control actions may also operate and the generic sub-function definition methods may also operate. However, as shown in fig. 11a, if multiple providers operate, the RAN context may not be identified at the near RT RIC. Furthermore, trigger events/reports, insertions, policy conditions will not operate. The control actions may not be operational or may depend on the implementation due to local RRM collisions.

A single E2SM-RAN control is difficult to operate in the O-RAN scenario of a multi-vendor environment. This is because there is a functional parity and an operational parity considering all RAN characteristics. RAN function parity indicates differences in features related to RRM functions (e.g., quality of service (QoS) handoff, load Balancing (LB) handoff, etc.). RAN operation parity indicates differences in features related to RAN operation (e.g., DC SCG bearer change procedure). Furthermore, reporting/inserting/controlling/policy actions may not identify the exact RAN context. Furthermore, reporting/inserting/controlling/policy actions may not identify trigger events/conditions from reporting/inserting/policies. Furthermore, it may be difficult to reference the RAN context in a particular deployment in a corresponding action.

Referring to fig. 11a, a wireless communication environment 1100 shows network entities configured by a total of three providers. Vendor a may be an NR vendor. Vendor B may be an LTE vendor. The provider C may be a RIC provider. To solve the above problem, an entity that manages all of the E2 nodes of whichever provider is connected is required. Since the near RT RIC may collect measurement information of different suppliers, the near RT RIC may perform management and control more easily than other entities. Thus, near RT RIC performs RRM in a centralized manner, so that the difference and compatibility problems between suppliers can be solved. Furthermore, the issues of inter-vendor variability and compatibility can be resolved even with different RATs.

Hereinafter, the near RT RIC centralized RRM may be referred to and described in this disclosure as terms such as RIC-based RRM control or E2 node zombie mode, E2SM-RIC specific mode, and the like. Note that the technical meaning of the function performed by RIC for each E2 node may be used instead of the terms shown.

Fig. 11b shows signaling of RRM control configuration of a near RT RIC according to an embodiment of the disclosure. Fig. 11b shows an example 1150 of a signaling procedure between an E2 node and a RIC. Specifically, FIG. 11b illustrates an E2I/F setup procedure and a RIC subscribe message transfer procedure between an E2 node and a RIC. Further, fig. 11b shows a procedure of transmitting RIC indication messages and RIC control messages.

Referring to fig. 11b, the E2 node may send an E2 setup request message to the RIC. An E2 node function located in the E2 node may find the RIC using a RIC IP address configured with operation-administration-maintenance (OAM) and send an E2 setup request message. In this way, the E2 node may request RIC-based RRM control. For example, the E2 node may send an E2 setup request message to the RIC, the message including that the E2 node may operate in zombie mode. Next, the RIC may receive an E2 setup response message from the E2 node. The RIC may determine from the E2 node whether the E2 node may support zombie mode, i.e., it is possible that the RIC has full control of RRM.

Referring to fig. 11b, the RIC may send a RIC subscription request message to the E2 node. A specific xApp located at the RIC requests subscription to the RIC E2 terminal function regarding specific RAN function definition functions supported by E2. According to an embodiment, the subscription request message may include information for indicating whether the RIC performs RIC-based RRM control. For example, the subscription request message may include information indicating whether the RIC operates as an E2 SM-RIC. Further, for example, the RIC may send a subscription request message including a zombie mode indicator. According to an embodiment, RIC-based RRM control may be performed based on a UE or a group of UEs including the UE. As shown in fig. 10 and 11a, RIC-based RRM control may be performed on UEs located in an area between providers or a common service area of CU-UP or a group including the UEs. In this way, the subscription request message may include an ID indicating a group (hereinafter referred to as a group identifier) or an ID indicating a specific UE (hereinafter referred to as a terminal ID/UE ID).

According to an embodiment, as shown in fig. 7, the transmission of the subscription request message and the E2 setup response message may be transmitted separately. According to another embodiment, the subscription request message of this step may be included in the E2 setup response message of this step and sent together.

In a next step, the E2 node may send a RIC subscription response to the RIC. The E2 node function of the E2 node may decode the subscription request message. The E2 node may identify whether the RIC is an E2SM RIC. The E2 node may identify whether the RIC is operating in zombie mode or whether the E2 node is operating in zombie mode.

Referring to fig. 11b, the E2 node may send an E2 RIC indication message to the RIC. The E2 node and RIC may execute a RIC indication procedure. According to embodiments of the present disclosure, the RIC indication message may include KPI reports per UE. According to an embodiment, the message container of the RIC indication message may comprise a KPI reporting service model per UE. Next, the RIC may perform RRM on the corresponding UE. Although not shown in fig. 11b, the RIC may perform RRM and generate a control message including specific information related to the resource allocation procedure. Thus, the RIC may control each E2 node.

An E2SM RIC control message may be sent to the E2 node 610. The E2 node 610 and RIC 640 may execute RIC control procedures. RIC 640 may generate E2SM-RIC control messages for the control procedures of the E2 node. For example, the E2SM-RIC control message may include a message container. The message container may include an RRC message per interface (e.g., X2 times a gNB (SgNB) addition request message).

Fig. 11b is described on a UE basis, but measurement may be performed and reported on various bases such as UE group/network slice, and RIC control may be performed.

Referring to fig. 11b, although the setup procedure, the RIC subscription procedure, the RIC indication messaging procedure, and the RIC control messaging procedure have been described in order, various embodiments of the present disclosure are not limited to the order and procedure described above. That is, in some embodiments, the E2 node and RIC may independently execute the E2 setup procedure. In some embodiments, the E2 node and RIC may independently execute a subscription program. Meanwhile, according to another embodiment, the E2 setup response message may include a subscription request message, as described above. In some embodiments, the E2 node and RIC may independently execute the RIC indication procedure. Further, in some embodiments, the E2 node and RIC may independently execute the RIC control procedure. Furthermore, the E2 node and the RIC may together or separately perform at least a portion of the above-described procedures.

Fig. 12a and 12b illustrate signals 1200 and 1250 for RIC-based RRM control in accordance with various embodiments of the present disclosure. Load balancing (e.g., MLB) between different vendors is performed through RRM control. Referring to fig. 12a and 12b, a single E2 node is depicted, but multiple E2 nodes, particularly E2 nodes of different vendors, may be applied in the same manner. RRM control can be more effectively achieved through control of RIC even though suppliers are different.

Referring to fig. 12a and 12b, the ric may process the following messages/procedures to perform the functions of the E2 node.

(1) NGAP Protocol Data Unit (PDU) session resource setting request

(2) E1 bearer context setup request

(3) E1 bearer context setup response

(4) F1 UE context modification request

(5) F1 UE context modification response

(6) E1 bearer context modification request

(7) E1 bearer context modification response

(8) DL RRC messaging

(9) F1 UE RRC message transfer

(10) F1 UE context modification request

(11) F1 UE context modification response

(12) NGAP PDU session resource setup response

If the AMF sends a message to the E2 node, the E2 node may forward the corresponding message to the RIC. That is, the E2 node may bypass and forward the corresponding message to the RIC such that the RIC interprets/processes/determines the corresponding message. The blank shown in fig. 12a and 12b indicates that the near RT RIC performs the function of each E2 node. The RIC may improve intelligent assistance functions to perform operations of RRM, such as interpretation/processing/determination of messages.

Figures 12a and 12b have been listed in chronological order, which are only used to explain the operation of the E2SM-RIC according to various embodiments of the present disclosure, but are not intended to limit the execution of specific signaling to the necessary components before other signaling. That is, according to another embodiment, some of the procedures shown in fig. 12a and 12b may be omitted. According to a further embodiment, some signaling may be performed by the RIC once. Further, examples of processing the messages of (1) to (2) are shown in fig. 12a and 12b, but the embodiments of the present disclosure are not limited thereto. Some of the foregoing examples may be interpreted/determined/processed by the RIC, but others may be performed by the E2 node in a conventional manner.

Hereinafter, in fig. 13a to 13c, in order to execute the RIC control program according to an embodiment of the present disclosure, a setup program and a subscription program between the E2 node and the RIC, and the RIC control program are described.

Fig. 13a shows signaling of a setup procedure between an E2 node and RIC according to an embodiment of the present disclosure. Herein, RIC may mean a near RT RIC.

Referring to fig. 13a, in operation 1301, the E2 node may send an E2 SETUP REQUEST (SETUP REQUEST) message to the RIC. The E2 NODE FUNCTION located in the E2 NODE may find an operation-administration-maintenance (OAM) RIC using an IP address set as the RIC, and send an E2 setup request message. The E2 setup request message may include information about RAN functions supported by the E2 node (e.g., RAN function definitions), E2 node ID information, etc. According to an embodiment, the RAN function definition value is a value set to OAM. For example, the RAN function definition value may include a STYLE ID value. The RIC may determine which call processing function the E2 node supports based on the RAN function definition value by receiving information about the setting value via OAM.

According to an embodiment, the RAN function definition may be configured in the IE format shown in fig. 13 a. The RAN function definition may include information about RIC event trigger patterns and information about RIC control patterns. According to an embodiment, the RAN function definition of the E2 setup request message is the capability of the E2 node and may include information about allowed control actions. The RAN function definition is an ID of the allowed control action (e.g., an allowed control action ID), a name of the allowed control action (e.g., an allowed control action name), information about parameters related to the allowed control action (e.g., a sequence of associated RAN parameters). For example, if the RIC control style is "dual-connected" (e.g., RIC style type=5 in fig. 18), the corresponding SgNB control operations (e.g., sgNB add/SgNB modify/SgNB release) are control action IDs and may be defined together. Meanwhile, the table shown in fig. 13a illustrates only an example of the RAN function definition IE included in the E2 setup request message of the present disclosure, and is not to be construed as limiting other embodiments of the present disclosure.

In operation 1303, the RIC may receive an E2 SETUP RESPONSE (SETUP RESPONSE) message from the E2 node. The RIC may determine whether accepting the E2 setup request message sent by the E2 node is acceptable. If it is possible to accept the E2 setup request message, the RIC may send an E2 setup response message to the E2 node.

After performing the E2 SETUP (SETUP) procedure shown in fig. 13a, the RIC may be configured to control one or more functions of the E2 node. Thus, the RIC may provide control services to the E2 node. The RIC may control the E2 node to perform at least one allowed (or configured) control action via an E2 setup procedure.

Fig. 13b shows signaling of a control procedure between an E2 node and RIC according to an embodiment of the present disclosure. Fig. 13b shows the RIC control request procedure defined in the O-RAN standard.

Referring to fig. 13b, the RIC may send a RIC control request message to the E2 node. Here, the RIC may be a near RT RIC. The RIC sends RIC control request messages to the E2 node in the call to support RAN control actions defined in the E2 service model (E2 SM). In message transmission, RIC control request acknowledgement support may be selected. Thus, the E2 node needs to send a control request acknowledge message to the RIC.

The E2 node may send a RIC control acknowledgment message to the RIC. As described above, if the RIC control acknowledgment request IE set to "Ack" is included in the RIC control request message and the E2 node successfully processes the requested RIC control procedure task, the E2 node needs to respond with the RIC control acknowledgment message.

If a RIC control acknowledge message is received, the RIC may stop the timer TRICcontrol and complete the RIC control procedure. To determine the follow-up measure, the RIC may use information included in the RIC control status IE and the RIC control result IE. The RIC control result IE may be optional.

The RIC control procedure in fig. 13b may be performed in connection with the E2 subscription procedure and the E2 setup procedure in fig. 13 a. Hereinafter, an example of a case where the RIC control program is executed in conjunction with the E2 subscription program will be described with reference to fig. 13 c.

Fig. 13c illustrates signaling of a subscription procedure between an E2 node and RIC according to an embodiment of the present disclosure. Fig. 13c illustrates signaling of the entire control procedure between E2 node, RIC and non-RT RIC according to an embodiment of the disclosure.

Referring to fig. 13c, in operation 1361, a non-RT RIC may send policies for controlling a near RT RIC to an E2 node by using an A1 interface to the RIC. The A1 interface may be defined between a non-RT RIC and a near-RT RIC. The A1 policy includes at least one of a policy for each UE, a policy for each group, a policy for each cell, or a policy for each tile, and the A1 policy may be differently configured for each service. The RIC may perform the RIC subscription procedure based on the A1 policy received in the A1 policy message. The A1 policy creation message may include, for example, a JavaScript object notation (JSON) message format. For example, in the case where a policy is set for a specific UE, the A1 policy creation message may include a UE ID. Further, for example, in the case where a policy is set for a specific cell, the A1 policy creation message may include a cell ID. Further, for example, in the case of controlling QoS, the A1 policy creation message may include GBR related to QoS.

In operation 1363, the RIC may send a RIC subscription request to the E2 node. The E2 node may send a RIC subscription response message to the RIC. The RIC creates a RIC subscription request during the subscription process. The RIC subscription request is a message for actually configuring a SERVICE (SERVICE) for controlling the E2 node. Typically, to CONTROL an E2 node, the RIC may request a subscription REPORT (REPORT) service and a CONTROL (CONTROL) service to receive measurements from the E2 node. According to an embodiment, a specific xApp located at the RIC requests that RIC E2-side functions subscribe to specific RAN function definition functions supported by E2. The E2 node function of the E2 node may decode the subscription request message. After the RIC successfully configures the event conditions requested by the E2 node function, the E2 node function of the E2 node may have successfully configured by sending an event trigger condition to the RIC in response to the subscription request.

For Reporting (REPORT) service and CONTROL (CONTROL) service subscription, one RIC subscription procedure (one RIC subscription request and RIC subscription response) may be used. However, unlike that shown in fig. 13c, for the subscription of reporting (REPORT) service, RIC subscription requests and RIC subscription responses are exchanged between RIC and E2 nodes, and for the subscription of CONTROL (CONTROL) service, RIC subscription requests and RIC subscription responses are additionally RIC and may be exchanged between E2 nodes.

In operation 1365, the E2 node may send a RIC indication (or RIC control indication) to the RIC. When an event specified in the subscribed REPORT SERVICE (REPORT SERVICE) occurs in operation 1363, the E2 node may include the relevant measurement data in the RIC indication message and transmit the RIC indication message to the RIC. For example, when a particular event condition occurs, E2 node 610 may send an E2 RIC indication message to RIC 640. According to an embodiment, the message container of the RIC indication message may comprise a KPI reporting service model in UE units.

In operation 1367, the RIC may execute a RIC control program. The RIC may send a control request message to the E2 node (RIC CONTROL REQUEST). The E2 node may send an RIC control acknowledgement to the RIC (RIC CONTROL ACKNOWLEDGE). The RIC control procedure may correspond to the control procedure of fig. 13 b.

The RIC may send a RIC CONTROL REQUEST message (CONTROL REQUEST) to the E2 node when the received measurement data satisfies a subscribed CONTROL SERVICE (CONTROL SERVICE) condition. The RIC CONTROL REQUEST (CONTROL REQUEST) may include settings (settings) required to CONTROL the E2 node. For example, for a dual connectivity configuration, the target cell IE and the IEs defined in 3GPP related to the SgNB add request may be delivered. Further, for example, for Data Radio Bearer (DRB) control, a DRB ID and IE associated with the F1 interface message may be sent. According to an embodiment of the present disclosure, the E2 node may send a RIC control acknowledge (CONTROL ACKNOWLEDGE) message to the RIC in response.

Fig. 14a shows an example of RIC control request message format according to an embodiment of the present disclosure. Fig. 14a shows the RIC control request message format specified in the O-RAN standard.

The message type is a type number specified for each message type in the standard, the RIC request ID is an ID for uniquely managing a corresponding message at the RIC, and the RAN function ID is an ID for identifying a control target function in the E2 node. Further, the selectively transmitted RIC call processing ID is an ID for identifying a previous processing. The RIC control header and RIC control message carry and send messages for controlling RAN functions. The RIC according to embodiments of the present disclosure may request a RIC control confirm message that selectively sends whether the corresponding action is successful to the E2 node using the RIC control confirm request IE. That is, if the RIC control confirm message is requested from the E2 node, the RIC may include the RIC control confirm request IE in the RIC control request message. If the RIC does not include the RIC control acknowledgement request IE in the RIC control request message, it may be interpreted that the RIC does not request the RIC control acknowledgement message from the E2 node.

Fig. 14b shows an example of RIC control acknowledgment message format according to an embodiment of the present disclosure. Fig. 14b shows a control acknowledgement of a response message as a control message defined in the O-RAN standard. The message type is a type number specified in the standard for each message type, the RIC request ID is an ID for uniquely managing the corresponding message at the RIC, and the RAN function ID is an ID for identifying a control target function in the E2 node. Further, the selectively transmitted RIC call processing ID is an ID for identifying a previous processing.

According to embodiments of the present disclosure, the RIC control status may indicate a status in a previously requested RIC control request message. The message status may be represented as one of a success, rejection, failure, or partial success status. The E2 node may transmit a corresponding control action result through the RIC control result (the corresponding IE may be referred to as the RIC control result). The parenchymal control action results may be defined in the octet string container form of the RIC control results in the E2 service model. For example, the IE of RIC control results may be illustrated as shown in table 1 below.

TABLE 1

In this context, the label [3] indicates O-RAN-wg3.e2sm: "O-RAN working group 3, near real time RAN intelligent controller, E2 service model (E2 SM). The "services indicated by RIC control results are related to RAN functions. Here, the RAN functionality may rely on the E2 service model (E2 SM).

Fig. 15 illustrates an example of an "E2SM-RC control result" IE format in a RIC control acknowledgment message according to an embodiment of the disclosure. Fig. 15 shows an example of a control result message format 1 transmitted in the form of a single octet string container regardless of success or failure in RIC control acknowledgements defined in the present disclosure, and an example of a control result message format 2 designed in such a manner that success cause and failure cause fields are independently configured and can be transmitted together. The control result message format is extensible and additional formats may be defined. RAN function specific E2 service model (E2 SM) specifications may be recommended to include the interpretation of IEs to be used in RIC control services. A selection format listing one or more RIC control result formats may be employed.

Fig. 16 a-16 c illustrate examples of RIC control acknowledgment messages for carrying a cause IE according to various embodiments of the present disclosure.

Figure 16a illustrates a message of E2SM-RC control result format 1. The message may include a maxnofControOutcome quantity set. Each piece of information of the set may include a UE ID and a set of sequences associated with the UE. Each information of the sequence set may include a RAN parameter ID and a number of RAN parameter containers of maxnofControcouout. That is, the control result format 1 can be defined by repeating the control result in the form of a sequence as many as the number defined in maxnofControOutcome. The RAN parameter ID and the RAN parameter container may be defined by repeating the number defined in maxnofcontrolackranresource for one UE per sequence.

The parameter ID shown in fig. 16b is a function of RAN control defined in the standard per RAN control. For example, the RAN parameter ID may be defined as an integer value from 1 to 4294967296. Fig. 16c shows a failure cause defined per parameter ID defined in 3 GPP.

Fig. 16c may indicate information of RAN parameter IDs and RAN parameter containers corresponding to the corresponding parameter IDs. The table shown in fig. 16c is exemplary and is not to be construed as limiting embodiments of the present disclosure. The RAN parameter ID may define additional values other than 12 and some details of the table may change according to the addition/change/modification of the standard.

Referring to fig. 16c, according to an embodiment, the RAN parameter ID may indicate "QoS flow fail set list" (e.g., "1"). The RAN parameter container may include a QoS flow ID of "QoS flow failed set list".

According to an embodiment, the RAN parameter ID may indicate that "QoS flow fails to modify list t" (e.g., "2"). The RAN parameter container may include a QoS flow failure to modify list IE of "QoS flow failure to modify list".

According to an embodiment, the RAN parameter ID may indicate "QoS flow fails to set list" (e.g., "3"). The RAN parameter container may include a DRB fail set list IE of "DRB fail set list".

According to an embodiment, the RAN parameter ID may indicate that "DRB fails to be modified to the list" (e.g., "4"). The RAN parameter container may include "DRB failed to be modified list IE" in the "DRB failed to be modified list".

According to an embodiment, the RAN parameter ID may indicate "F1AP cause" (e.g., "5"). The RAN parameter container may include a cause IE defined in 3gpp TS 38.473.

According to an embodiment, the RAN parameter ID may indicate "E1AP cause" (e.g., "6"). The RAN parameter container may comprise a cause IE defined in 3gpp TS 38.463.

According to an embodiment, the RAN parameter ID may indicate an "XnAP cause" (e.g., "7"). The RAN parameter container may comprise a cause IE defined in 3gpp TS 38.423.

According to an embodiment, the RAN parameter ID may indicate "NGAP cause" (e.g., "8"). The RAN parameter container may comprise a cause IE defined in 3gpp TS 38.413.

According to an embodiment, the RAN parameter ID may indicate "X2AP cause" (e.g., "9"). The RAN parameter container may comprise a cause IE defined in 3gpp TS 36.423.

According to an embodiment, the RAN parameter ID may indicate a "W1AP cause" (e.g., "10"). The RAN parameter container may comprise a cause IE defined in 3gpp TS 37.473.

According to an embodiment, the RAN parameter ID may indicate "S1AP cause" (e.g., "11"). The RAN parameter container may include a cause IE defined in 3gpp TS 36.473.

According to an embodiment, the RAN parameter ID may indicate an interface name. Although not defined in the 3GPP standard (e.g., configured in the embodiment), a cause value for indicating a cause of failure may be defined. At this time, in order to refer to an Interface associated with a corresponding cause, "Interface Name" may be defined. The "interface name" may be configured to indicate an interface, such as F1/E1/Xn/X2/W1.

FIG. 17 illustrates a subsequent action example of a RIC action according to an embodiment of the present disclosure. FIG. 17 is an embodiment supporting more intelligent follow-up actions at the RIC by using the current message format. First, it is assumed that two QoS flows are mapped to a Data Radio Bearer (DRB) #1. Next, the RIC may detect that QoS flow #2 of the two QoS flows needs to communicate with a separate CU-UP through a separate DRB (e.g., the anchor point of the CU-UP needs to be changed halfway between the DU and CU-UP and in the backhaul between the CU-UP and UPF). Therefore, it is necessary to additionally generate drb#2 in the DU (act 1) and then remap the QoS flows and drb#2 (act 2). According to RIC, the corresponding actions involve several entities (actions associated with DU, CU-up#2, CU-CP and 5 GC) and may occur at different locations even if the corresponding actions fail. However, if a failure occurs and the cause of the failure is not clearly transmitted to the RIC, recovery may be delayed due to repeated failures.

According to the current standard, if such failure occurs, it is impossible to transmit information of an accurate failure location. For example, additional modifications to the existing format are unavoidable to convey detailed information such as whether DRB #2 generation failed due to Connection Admission Control (CAC) failure in the DU, whether failed due to no routing user plane tunnel address in the CU-UP, whether RRC signals failed, which CU-UP generation failed, and which I/F failed. If it is possible to transmit this additional information using the suggested format, the RIC may more effectively address the failure cause. For example, if a DRB setup (setup) fails due to CAC failure of a DU, the RIC may prevent CAC failure by allowing the DRB to be set to other DUs except the corresponding DU. Furthermore, the RIC may guide the re-adjustment of the user plane by interacting with an entity managing the transmissions to adjust a Software Defined Network (SDN) controller, for example, if there is a problem with the connection on the transport layer of the CU-UP, or may assist in coverage optimization by additional analysis of RRC reconfiguration failure actions.

Although not depicted in fig. 17, the RIC may be configured more variously by more effectively controlling the scenario of the E2 node for failure reasons. The RIC may perform DU control, DU bandwidth control, per-service control, DRB and QoS mapping in the CU-DU partitioning structure.

Fig. 18 shows an example of RIC pattern types according to an embodiment of the present disclosure. By means of fig. 18, an example of the manner in which RIC may control RIC control services of E2 nodes using RAN control is described. Any supportable RIC control service style of embodiments of the present disclosure, as well as examples of service styles shown in fig. 18, may additionally be considered.

Fig. 19 illustrates another example of a RIC control acknowledgment message for delivering a cause IE according to an embodiment of the present disclosure. An example of the message of the E2SM-RC control result format 2 will be described in detail with reference to fig. 19. A control action corresponding to a control action ID, controlled by the RIC control request, may be associated with one or more RAN parameter IDs. At this time, success or failure (or rejection) may be determined for each RAN parameter ID. For example, for dual connectivity control, one control operation of SgNB add/modify/release may be configured. For each gNB to be added, success or failure (or rejection) may be determined. The reason for fig. 16c may also be included in the RAN parameters container of the embodiment described with reference to fig. 19. That is, the embodiment described with reference to fig. 19 may refer to the cause related IE and RAN parameter ID of fig. 16 c.

Referring to fig. 19, the message may include RIC mode type information. That is, the message may depend on the RIC style. According to an embodiment, the message may include a set of maxnofcontroloutcom numbers for each mode of RIC control service. Each piece of information in the set may include a UE ID and a set of success sequences and a set of failure sequences associated with the UE. Each information in the sequence set may include a RAN parameter ID and a RAN parameter container. The successful sequence set may include as many RAN parameter IDs and RAN parameter containers as there are maxnooffcontrolackranresources 1. Furthermore, the failed sequence set may include as many RAN parameter IDs and RAN parameter containers as there are maxnooff control ackranresources 2.

According to an embodiment, the message (e.g., RIC control result of RIC control acknowledge message) may include only a successful set of sequences. At this point, the RIC control status may be configured to indicate success. Furthermore, according to an embodiment, the message (e.g., the RIC control result of the RIC control acknowledge message) may include only the failed set of sequences. At this point, the RIC control status may be configured to indicate failure (or rejection).

Further, according to an embodiment, the message (e.g., RIC control result of RIC control acknowledge message) may include both a set of successful sequences and a set of failed sequences. At this time, the RAN parameter ID and the number of RAN parameter containers included in the sequence set are independent between the successful sequence set and the failed sequence set. That is, maxnofcontrolackranresource 1 may be the same as or different from maxnofcontrolackranresource 2. At this point, the RIC control status may be configured to indicate partial success.

The CONTROL result according to the CONTROL result format 2 may be repeatedly defined in the form of "success result sequence of RAN CONTROL (CONTROL)" and "failure result sequence of RAN CONTROL (CONTROL)" in the same number as that defined in maxnoof CONTROL out. For each sequence, for one User Equipment (UE), RAN parameter IDs and RAN parameter containers may be repeatedly defined for successful RAN CONTROL (CONTROL) and failed RAN CONTROL (CONTROL) in the same number as defined in maxnofcontrolackranresources (or maxnofcontrolackranresources 1 and maxnofcontrolackranresources 2).

According to an embodiment, the RIC may detect the difficulty of the DU in UE service due to lack of cell capacity. In this case, the RIC may change the accessed DUs, instead of repeatedly controlling the access through the DUs.

According to an embodiment, the RIC may detect that the currently provided cell is insufficient to support the corresponding QoS Class Identifier (QCI). In order to provide a service of sufficient quality, the RIC may control switching the UE, or control changing a CU or DU to a CU or DU determined to be closer to the UE.

According to an embodiment, the RIC may configure additional cells if the bandwidth provided for the current service is insufficient and the corresponding function (e.g., E2 SM-specific RAN function ID) fails. For example, the RIC may perform an addition procedure for a Secondary Node (SN) of the DC connection, or perform a modification procedure of the SN. Further, for example, the RIC may control the E2 node to provide cells with relatively wide bandwidths to the service through cell group reconfiguration.

According to an embodiment, if handover to a target cell is not allowed, the RIC may control the E2 node to handover to another target cell. For example, for inter-DU mobility support, the RIC may control the CU to serve a particular UE with a new DU.

As shown in the above example, by acquiring the failure causes of various service functions (function failures corresponding to a specific RAN function ID in the service model), the RIC can more effectively control the E2 node. The required RIC actions may be triggered by the cause IE (or failure information) of the RIC control acknowledgment message reported by the E2 node.

According to various embodiments of the present disclosure, inter-process communication (IPC) costs may be reduced under RRM control of the RIC. In particular, if DU/CU/RIC are located in the same environment, message relay costs can be reduced. RIC may perform everything except messaging, so that the reciprocity problem according to the operation between suppliers may be solved. Furthermore, the intelligent functions of the RIC may be updated to replace specific functions between CU-UP.

According to an example embodiment of the present disclosure, a method performed by a Radio Access Network (RAN) intelligent controller (RIC), the method comprising: receiving a setup request message from the E2 node, the setup request message comprising RAN function information specific to the service model, the RAN function information comprising information on one or more control actions; sending a setting response message to the E2 node; transmitting a RIC control request message to the E2 node; and receiving a RIC control acknowledgment message from the E2 node, wherein the RIC control request message includes identification information of a control action of the one or more control actions, wherein the RIC control acknowledgment message includes RIC control result information of the control action, and wherein the RIC control result information includes a cause of an event of the control action in a particular protocol.

In some embodiments, wherein the event of the control action comprises a failure or rejection of the control action.

In some embodiments, wherein the RIC control result information comprises a RAN parameter Identifier (ID) and a RAN parameter container, wherein the RAN parameter ID indicates a specific protocol, a quality of service (QoS) flow, or a Data Radio Bearer (DRB), and wherein the RAN parameter container comprises information about a cause.

In some embodiments, wherein the RIC control result information comprises information about a manner of RIC control services, and wherein the manner of RIC control services comprises at least one of radio bearer control, radio resource allocation, connected mode mobility, radio access control, dual connectivity, carrier aggregation, or idle mode mobility control.

In some embodiments, wherein the RIC control result information comprises at least one of success sequence information of a manner of RIC control services or failure sequence information of a manner of RIC control services, wherein the success sequence information comprises a RAN parameter Identifier (ID) and a RAN parameter container for each successfully performed control action, wherein the failure sequence information comprises a RAN parameter ID and a RAN parameter container for each failed control action.

According to an example embodiment of the present disclosure, a method performed by an E2 node, the method comprising: transmitting a setup request message to a Radio Access Network (RAN) intelligent controller (RIC), the setup request message including RAN function information specific to a service model, the RAN function information including information about one or more control actions; receiving a setup response message from the RIC; receiving a RIC control request message from a RIC; and sending a RIC control acknowledge message to the RIC, wherein the RIC control request message comprises identification information of a control action of the one or more control actions, wherein the RIC control acknowledge message comprises RIC control result information of the control action, and wherein the RIC control result information comprises a cause of an event of the control action in the specific protocol.

In some embodiments, wherein the event of the control action comprises a failure or rejection of the control action.

In some embodiments, wherein the RIC control result information comprises a RAN parameter Identifier (ID) and a RAN parameter container, wherein the RAN parameter ID indicates a specific protocol, a quality of service (QoS) flow, or a Data Radio Bearer (DRB), wherein the RAN parameter container comprises information about a cause.

In some embodiments, wherein the RIC control result information comprises information about a manner of RIC control services, and wherein the manner of RIC control services comprises at least one of radio bearer control, radio resource allocation, connected mode mobility, radio access control, dual connectivity, carrier aggregation, or idle mode mobility control.

In some embodiments, wherein the RIC control result information comprises at least one of success sequence information of a manner of RIC control services or failure sequence information of a manner of RIC control services, wherein the success sequence information comprises a RAN parameter Identifier (ID) and a RAN parameter container for each successfully performed control action, wherein the failure sequence information comprises a RAN parameter ID and a RAN parameter container for each failed control action.

According to an example embodiment of the present disclosure, an apparatus of a Radio Access Network (RAN) intelligent controller (RIC) includes: at least one transceiver; and at least one processor, wherein the at least one processor is configured to control the at least one transceiver to: receiving a setup request message from the E2 node comprising RAN function information specific to the service model, the RAN function information comprising information about one or more control actions, sending a setup response message to the E2 node, sending a RIC control request message to the E2 node, and receiving a RIC control acknowledge message from the E2 node, wherein the RIC control request message comprises identification information of a control action of the one or more control actions, wherein the RIC control acknowledge message comprises RIC control result information of the control action, and wherein the RIC control result information comprises a cause of an event of the control action in the specific protocol.

In some embodiments, wherein the event of the control action comprises a failure or rejection of the control action.

In some embodiments, wherein the RIC control result information comprises a RAN parameter Identifier (ID) and a RAN parameter container, wherein the RAN parameter ID indicates a specific protocol, a quality of service (QoS) flow, or a Data Radio Bearer (DRB), wherein the RAN parameter container comprises information about a cause.

In some embodiments, wherein the RIC control result information comprises information about a manner of RIC control services, and wherein the manner of RIC control services comprises at least one of radio bearer control, radio resource allocation, connected mode mobility, radio access control, dual connectivity, carrier aggregation, or idle mode mobility control.

In some embodiments, wherein the RIC control result information comprises at least one of success sequence information of a manner of RIC control services or failure sequence information of a manner of RIC control services, wherein the success sequence information comprises a RAN parameter Identifier (ID) and a RAN parameter container for each successfully performed control action, wherein the failure sequence information comprises a RAN parameter ID and a RAN parameter container for each failed control action.

According to an example embodiment of the present disclosure, an apparatus of an E2 node includes: at least one transceiver; and at least one processor, wherein the at least one processor is configured to control the at least one transceiver to: transmitting a setup request message including RAN function information specific to a service model to a Radio Access Network (RAN) intelligent controller (RIC), the RAN function information including information about one or more control actions, receiving a setup response message from the RIC, receiving a RIC control request message from the RIC, and transmitting a RIC control confirm message to the RIC, wherein the RIC control request message includes identification information of a control action of the one or more control actions, wherein the RIC control confirm message includes RIC control result information of the control action, and wherein the RIC control result information includes a cause of an event of the control action in a specific protocol.

In some embodiments, wherein the event of the control action comprises a failure or rejection of the control action.

In some embodiments, wherein the RIC control result information comprises a RAN parameter Identifier (ID) and a RAN parameter container, wherein the RAN parameter ID indicates a specific protocol, a quality of service (QoS) flow, or a Data Radio Bearer (DRB), wherein the RAN parameter container comprises information about a cause.

In some embodiments, wherein the RIC control result information comprises information about a manner of RIC control services, and wherein the manner of RIC control services comprises at least one of radio bearer control, radio resource allocation, connected mode mobility, radio access control, dual connectivity, carrier aggregation, or idle mode mobility control.

In some embodiments, wherein the RIC control result information comprises at least one of success sequence information of a manner of RIC control services or failure sequence information of a manner of RIC control services, wherein the success sequence information comprises a RAN parameter Identifier (ID) and a RAN parameter container for each successfully performed control action, wherein the failure sequence information comprises a RAN parameter ID and a RAN parameter container for each failed control action.

According to an example embodiment of the present disclosure, a method performed by a near RT (real time) RIC (radio access network (RAN) intelligent controller (RIC)), the method comprising: transmitting a RIC control request message including control action Identity (ID) information to the E2 node, and receiving a RIC control acknowledge message or a RIC control failure message from the E2 node in response to the RIC control request message, wherein the RIC control acknowledge message or the RIC control failure message includes information about a RIC control result, wherein the information about the RIC control result includes at least one RAN parameter set, wherein each of the at least one RAN parameter set includes a RAN parameter ID and a RAN parameter value.

In some embodiments, wherein the RIC control request message includes information about a manner of the RIC control service, wherein the manner of the RIC control service is one of a plurality of manners, comprising: radio bearer control, radio resource allocation, connected mode mobility, radio access control, dual connectivity, carrier aggregation, or idle mode mobility control.

In some embodiments, where the manner in which the RIC controls the service is radio bearer control: wherein the RAN parameter ID of the information of the RIC control result indicates a DRB (data radio bearer), and wherein the RAN parameter value of the information of the RIC control result comprises a value of the DRB ID.

In some embodiments, the method further comprises: receiving an E2 setup request message from the E2 node, the E2 setup request message comprising information of RAN function definitions specific to the service model, and sending an E2 setup response message to the E2 node, wherein the information of RAN function definitions comprises a control action ID, a control action name and a related RAN parameter sequence of the control action.

In some embodiments, the information of the RIC control result includes information of a failure cause in case of failure of the RIC control request.

According to an example embodiment of the present disclosure, a method performed by an E2 node, the method comprising: receiving a RIC control request message from a near RT (real time) RIC (radio access network (RAN) intelligent controller (RIC)) comprising information about a control action Identity (ID), and sending a RIC control acknowledge message or a RIC control failure message to the near RT RIC in response to the RIC control request message, wherein the RIC control acknowledge message or the RIC control failure message comprises information about a RIC control result, wherein the information about the RIC control result comprises at least one RAN parameter set, wherein each of the at least one RAN parameter set comprises a RAN parameter ID and a RAN parameter value.

In some embodiments, wherein the RIC control request message includes information about a manner of the RIC control service, wherein the manner of the RIC control service is one of a plurality of manners, comprising: radio bearer control, radio resource allocation, connected mode mobility, radio access control, dual connectivity, carrier aggregation, or idle mode mobility control.

In some embodiments, where the manner in which the RIC controls the service is radio bearer control: wherein the RAN parameter ID of the information of the RIC control result indicates a DRB (data radio bearer), and wherein the RAN parameter value of the information of the RIC control result comprises a value of the DRB ID.

In some embodiments, the method further comprises: an E2 setup request message is sent to the near RT RIC, the E2 setup request message comprising information of RAN function definitions specific to the service model, and an E2 setup response message is received from the near RT RIC, wherein the information of RAN function definitions comprises a control action ID, a control action name and a related RAN parameter sequence of the control action.

In some embodiments, the information of the RIC control result includes information of a failure cause in case the RIC control request fails.

According to an example embodiment of the present disclosure, an apparatus of a near RT (real time) RIC (radio access network (RAN) intelligent controller (RIC)) includes: at least one transceiver; and at least one processor coupled to the at least one transceiver, wherein the at least one processor is configured to: transmitting a RIC control request message including information about a control action Identity (ID) to the E2 node, and receiving a RIC control acknowledge message or a RIC control failure message from the E2 node in response to the RIC control request message, wherein the RIC control acknowledge message or the RIC control failure message includes information about a RIC control result, wherein the information about the RIC control result includes at least one RAN parameter set, wherein each of the at least one RAN parameter set includes a RAN parameter ID and a RAN parameter value.

In some embodiments, wherein the RIC control request message includes information about a manner of the RIC control service, wherein the manner of the RIC control service is one of a plurality of manners, comprising: radio bearer control, radio resource allocation, connected mode mobility, radio access control, dual connectivity, carrier aggregation, or idle mode mobility control.

In some embodiments, where the manner in which the RIC controls the service is radio bearer control: wherein the RAN parameter ID of the information of the RIC control result indicates a DRB (data radio bearer), and wherein the RAN parameter value of the information of the RIC control result comprises a value of the DRB ID.

In some embodiments, wherein the at least one processor is further configured to: receiving an E2 setup request message from the E2 node, the E2 setup request message comprising information of RAN function definitions specific to the service model, and sending an E2 setup response message to the E2 node, wherein the information of RAN function definitions comprises a control action ID, a control action name and a related RAN parameter sequence of the control action.

In some embodiments, the information of the RIC control result includes information of a failure cause in case the RIC control request fails.

According to an example embodiment of the present disclosure, an apparatus of an E2 node includes: at least one transceiver; and at least one processor coupled to the at least one transceiver, wherein the at least one processor is configured to: receiving an RIC control request message including information about a control action Identity (ID) from a near RT (real time) RIC (radio access network (RAN) intelligent controller (RIC)), and transmitting a RIC control acknowledge message or a RIC control failure message to the near RT RIC in response to the RIC control request message, wherein the RIC control acknowledge message or the RIC control failure message includes information about a RIC control result, wherein the information about the RIC control result includes at least one RAN parameter set, wherein each of the at least one RAN parameter set includes a RAN parameter ID and a RAN parameter value.

In some embodiments, wherein the RIC control request message includes information about a manner of the RIC control service, wherein the manner of the RIC control service is one of a plurality of manners, comprising: radio bearer control, radio resource allocation, connected mode mobility, radio access control, dual connectivity, carrier aggregation, or idle mode mobility control.

In some embodiments, where the manner in which the RIC controls the service is radio bearer control: wherein the RAN parameter ID of the information of the RIC control result indicates a DRB (data radio bearer), and wherein the RAN parameter value of the information of the RIC control result comprises a value of the DRB ID.

In some embodiments, wherein the at least one processor is further configured to: an E2 setup request message is sent to the near RT RIC, the E2 setup request message comprising information of RAN function definitions specific to the service model, and an E2 setup response message is received from the near RT RIC, wherein the information of RAN function definitions comprises a control action ID, a control action name and a related RAN parameter sequence of the control action.

In some embodiments, the information of the RIC control result includes information of a failure cause in case the RIC control request fails.

The methods according to the embodiments described in the claims or specification of the present disclosure may be implemented in software, hardware or a combination of hardware and software.

With respect to software, a computer readable storage medium storing one or more programs (software modules) may be provided. One or more programs stored in the computer-readable storage medium may be configured to be executed by one or more processors of the electronic device. The one or more programs may include instructions for controlling the electronic device to perform a method according to the embodiments described in the claims or specification of the present disclosure.

Such programs (software modules, software) may be stored in random access memory, non-volatile memory (including flash memory, read Only Memory (ROM), electrically Erasable Programmable ROM (EEPROM), magnetic disk storage devices, compact Disk (CD) -ROM, digital Versatile Disk (DVD) or other optical storage devices, and magnetic cassettes.

Further, the program may be stored in a connectable storage device accessible via a communication network such as the internet, an intranet, a Local Area Network (LAN), a wide area network (WLAN), or a Storage Area Network (SAN), or a communication network by combining these networks. Such a storage device may access devices that perform embodiments of the present disclosure through an external port. Further, a separate storage device on the communication network may access the device performing the embodiments of the present disclosure.

In certain embodiments of the present disclosure, the components included in the present disclosure are represented in singular or plural form. However, for convenience of explanation, the singular or plural expressions are appropriately selected according to the proposed situation, the present disclosure is not limited to a single component or a plurality of components, and components expressed in the plural form may be configured as a single component, and components expressed in the singular form may be configured as a plurality of components.

While the present disclosure has been shown and described with reference to various embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the present disclosure as defined by the appended claims and their equivalents.

Claims (14)

1. A method performed by a near RT (real time) RIC (radio access network (RAN) intelligent controller (RIC)), the method comprising:

transmitting to the E2 node a RIC control request message including information on a control action Identity (ID), and

receiving a RIC control acknowledge message or a RIC control failure message in response to the RIC control request message from the E2 node,

wherein the RIC control confirm message or RIC control failure message includes information on RIC control results,

wherein the information about the RIC control result comprises at least one set of RAN parameters,

wherein each of the at least one RAN parameter set comprises a RAN parameter ID and a RAN parameter value.

2. The method of claim 1, wherein the RIC control request message comprises information about a manner of RIC control service,

among them, the RIC control service is one of a plurality of ways, including:

The control of the radio bearer is performed,

the allocation of the radio resources is performed,

the mobility of the connected mode is that,

the control of the radio access is performed,

the double-connection is carried out,

carrier aggregation, or

Idle mode mobility control.

3. The method according to claim 2,

in case the manner of RIC control of the service is radio bearer control:

wherein the RAN parameter ID of the information of the RIC control result indicates DRB (data radio bearer), and

wherein the RAN parameter value of the RIC control result information includes a value of the DRB ID.

4. The method of claim 1, the method further comprising:

receiving an E2 setup request message from an E2 node, the E2 setup request message including information about RAN function definitions specific to the service model, and

an E2 setup response message is sent to the E2 node,

wherein the information about the RAN function definition includes a control action ID, a control action name, and an associated RAN parameter sequence for the control action.

5. The method of claim 1, wherein in case the RIC control request fails, the information on the RIC control result includes information on a cause of the failure.

6. A method performed by an E2 node, the method comprising:

Receiving a near RT (real time) RIC (radio access network (RAN) intelligent controller (RIC)) a RIC control request message comprising information about a control action Identity (ID), and

transmitting an RIC control acknowledge message or RIC control failure message in response to the RIC control request message to the near RT RIC,

wherein the RIC control confirm message or RIC control failure message includes information on RIC control results,

wherein the information about the RIC control result comprises at least one set of RAN parameters,

wherein each of the at least one RAN parameter set comprises a RAN parameter ID and a RAN parameter value.

7. The method of claim 6, wherein the RIC control request message comprises information about a manner of RIC control service,

among them, the RIC control service is one of a plurality of ways, including:

the control of the radio bearer is performed,

the allocation of the radio resources is performed,

the mobility of the connected mode is that,

the control of the radio access is performed,

the double-connection is carried out,

carrier aggregation, or

Idle mode mobility control.

8. The method according to claim 7,

in case the manner of RIC control of the service is radio bearer control:

wherein the RAN parameter ID of the information of the RIC control result indicates a DRB (data radio bearer),

Wherein the RAN parameter value of the RIC control result information includes a value of the DRB ID.

9. The method of claim 6, the method further comprising:

sending an E2 setup request message to the near RT RIC, the E2 setup request message including information about the RAN function definition specific to the service model, and

receiving an E2 setup response message from the near RT RIC,

wherein the information about the RAN function definition includes a control action ID, a control action name, and an associated RAN parameter sequence for the control action.

10. The method of claim 6, wherein in case the RIC control request fails, the information on the RIC control result includes information on a cause of the failure.

11. An apparatus of a near RT (real time) RIC (radio access network (RAN) intelligent controller (RIC)), comprising:

at least one transceiver; and

at least one processor coupled to the at least one transceiver,

wherein the at least one processor is configured to:

transmitting to the E2 node a RIC control request message including information on a control action Identity (ID), and

receiving a RIC control acknowledge message or a RIC control failure message in response to the RIC control request message from the E2 node,

Wherein the RIC control confirm message or RIC control failure message includes information on RIC control results,

wherein the information about the RIC control result comprises at least one set of RAN parameters,

wherein each of the at least one RAN parameter set comprises a RAN parameter ID and a RAN parameter value.

12. The apparatus of claim 11, wherein the at least one processor is configured to perform one of claims 2-5.

13. An apparatus of an E2 node, comprising:

at least one transceiver; and

at least one processor coupled to the at least one transceiver,

wherein the at least one processor is configured to:

receiving a near RT (real time) RIC (radio access network (RAN) intelligent controller (RIC)) a RIC control request message comprising information about a control action Identity (ID), and

transmitting an RIC control acknowledge message or RIC control failure message in response to the RIC control request message to the near RT RIC,

wherein the RIC control confirm message or RIC control failure message includes information on RIC control results,

wherein the information about the RIC control result comprises at least one set of RAN parameters,

wherein each of the at least one RAN parameter set comprises a RAN parameter ID and a RAN parameter value.

14. The apparatus of claim 13, wherein the at least one processor is configured to perform one of claims 7 to 10.