Electronic device and method for RIC service query

Abstract

A method performed by an E2 node is provided according to embodiments. The method may comprise an operation for receiving a radio access network (RAN) intelligent controller (RIC) service query message from a Near-real time (RT) RIC. The method may comprise an operation for transmitting a RIC service update message to the Near-RT RIC in response to the RIC service query message. The RIC service query message may include a message type, a transaction identifier (ID), and a list of RAN functions previously accepted by the Near-RT RIC. The list of RAN functions may include, for each RAN function, a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM).

Description

Electronic device and method for querying AIC service

[0001] The following descriptions relate to electronic devices and methods for RAN (radio access network) intelligent controller service queries.

[0002] 4G(4 th To meet the increasing demand for wireless data traffic since the commercialization of the 5G (5 generation) communication system, the improved 5G (5 th Efforts are being made to develop 5G communication systems or pre-5G communication systems. For this reason, 5G communication systems or pre-5G communication systems are also called Beyond 4G Network communication systems or Post-LTE systems.

[0003] To achieve high data rates, 5G communication systems are being considered for implementation in ultra-high frequency (mmWave) bands (e.g., the 60 GHz band). To mitigate radio path loss and increase the transmission range of radio waves in ultra-high frequency bands, beamforming, massive MIMO (massive MIMO), full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and large-scale antenna technologies are being discussed in 5G communication systems.

[0004] Additionally, to improve the network of the system, technologies such as evolved small cells, advanced small cells, cloud radio access networks (cloud RAN), ultra-dense networks, device-to-device communication (D2D), wireless backhaul, moving networks, cooperative communication, CoMP (Coordinated Multi-Points), and interference cancellation are being developed in 5G communication systems.

[0005] In addition, advanced coding modulation (ACM) methods such as Hybrid Frequency Shift Keying and Quadrature Amplitude Modulation (FQAM) and Sliding Window Superposition Coding (SWSC), as well as advanced access technologies such as Filter Bank Multi Carrier (FBMC), Non Orthogonal Multiple Access (NOMA), and Sparse Code Multiple Access (SCMA), are being developed in 5G systems.

[0006] In order to meet the demand for wireless data traffic, 5G system, NR (new radio or next radio) is commercialized, and it is expected that it will be able to provide users with high data transmission rate services through 5G system like 4G, and also provide wireless communication services for various purposes such as Internet of Things and services that require high reliability for specific purposes. In the current mixed system of 4th generation communication system, 5th generation system, etc., O-RAN (open radio access network) established by business operators and equipment providers defines E2AP (E2 application protocol) standard in the application protocol of E2 interface between E2 node and Near-RT (real time) RIC (RAN (radio access network) intelligent controller).

[0007] Looking back at the evolution of wireless communication over successive generations, technologies have primarily been developed for human-facing services such as voice, multimedia, and data. With the commercialization of the 5G (5th Generation) communication system, an explosive increase in connected devices is expected to be connected to communication networks. Examples of networked objects include vehicles, robots, drones, home appliances, displays, smart sensors installed in various infrastructures, construction equipment, and factory equipment. Mobile devices are also expected to evolve into diverse form factors, such as augmented reality glasses, virtual reality headsets, and holographic devices. In the 6G (6th Generation) era, efforts are being made to develop improved 6G communication systems to connect hundreds of billions of devices and objects and provide diverse services. For this reason, 6G communication systems are often referred to as "beyond 5G."

[0008] The 6G communication system, expected to be realized around 2030, will have a maximum transmission speed of terabytes (i.e., 1,000 gigabits) per second (bps) and a wireless latency of 100 microseconds (μsec). In other words, compared to 5G, the transmission speed in a 6G communication system will be 50 times faster and the wireless latency will be reduced to one-tenth.

[0009] To achieve these high data rates and ultra-low latency, 6G communication systems are being considered for implementation in the terahertz (THz) band (e.g., from 95 gigahertz (GHz) to 3 terahertz (THz)). Compared to the millimeter wave (mmWave) band introduced in 5G, the terahertz band is expected to have more severe path loss and atmospheric absorption, making it more important to develop technologies that can guarantee signal reach, or coverage. Key technologies to ensure coverage include Radio Frequency (RF) components, antennas, new waveforms that offer better coverage than Orthogonal Frequency Division Multiplexing (OFDM), beamforming, and multiple antenna transmission technologies such as massive Multiple-Input and Multiple-Output (MIMO), Full Dimensional MIMO (FD-MIMO), array antennas, and large-scale antennas. In addition, new technologies such as metamaterial-based lenses and antennas, high-dimensional spatial multiplexing using Orbital Angular Momentum (OAM), and Reconfigurable Intelligent Surface (RIS) are being discussed to improve the coverage of terahertz band signals.

[0010] In addition, in order to improve frequency efficiency and system network, 6G communication systems are developing full duplex technology that utilizes the same frequency resources at the same time for uplink and downlink; network technology that integrates satellites and HAPS (High-Altitude Platform Stations); network structure innovation technology that supports mobile base stations and enables optimization and automation of network operation; dynamic spectrum sharing technology through collision avoidance based on spectrum usage prediction; AI-based communication technology that utilizes AI (Artificial Intelligence) from the design stage and internalizes end-to-end AI support functions to realize system optimization; and next-generation distributed computing technology that realizes services with complexity that exceeds the limits of terminal computing capabilities by utilizing ultra-high-performance communication and computing resources (Mobile Edge Computing (MEC), cloud, etc.). In addition, efforts are being made to further strengthen connectivity between devices, further optimize networks, promote softwareization of network entities, and increase the openness of wireless communications through the design of new protocols to be used in 6G communication systems, the implementation of hardware-based security environments, the development of mechanisms for the safe use of data, and the development of technologies for maintaining privacy.

[0011] Research and development of these 6G communication systems are expected to enable a new level of hyper-connected experience through the hyper-connectivity of 6G communication systems, which encompass not only connections between things but also connections between people and things. Specifically, 6G communication systems are expected to enable services such as truly immersive eXtended Reality (XR), high-fidelity mobile holograms, and digital replicas. Furthermore, services such as remote surgery, industrial automation, and emergency response, which are provided through 6G communication systems through enhanced security and reliability, will be applied in diverse fields such as industry, medicine, automobiles, and home appliances.

[0012] In 6G communication systems, RAN functions are expected to be further refined, separating them into service subscribers and service providers. In service-based networks, subscription service confirmation procedures for service subscription status will be applied to various functions.

[0013] In embodiments, a method performed by an E2 node is provided. The method may include receiving a RIC service query message from a Near-RT (real time) radio access network (RAN) intelligent controller (RIC). The method may include transmitting a RIC service update message to the Near-RT RIC in response to the RIC service query message. The RIC service query message may include a message type, a transaction identifier (ID), and a list of RAN functions previously accepted by the Near-RT RIC. The list of RAN functions may include, for each RAN function, a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM).

[0014] In embodiments, a method performed by a Near-RT (real time) RIC (radio access network (RAN) intelligent controller) is provided. The method may include transmitting an RIC service query message to an E2 node. The method may include receiving an RIC service update message from the E2 node. The RIC service query message may include a message type, a transaction identifier (ID), and a list of RAN functions previously accepted by the Near-RT RIC. The list of RAN functions may include, for each RAN function, a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM).

[0015] In embodiments, an electronic device of an E2 node is provided. The electronic device may include at least one processor and a memory storing instructions. The instructions, when executed by the at least one processor, may cause the E2 node to receive a RIC service query message from a Near-RT (real time) radio access network (RAN) intelligent controller (RIC) and, in response to the RIC service query message, transmit a RIC service update message to the Near-RT RIC. The RIC service query message may include a message type, a transaction identifier (ID), and a list of RAN functions previously accepted by the Near-RT RIC. The list of RAN functions may include, for each RAN function, a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM).

[0016] In embodiments, an electronic device of a Near-RT (real time) RIC (radio access network (RAN) intelligent controller) is provided. The electronic device may include at least one processor and a memory storing instructions. The instructions, when executed by the at least one processor, may cause the Near-RT RIC to transmit a RIC service query message to an E2 node and to receive a RIC service update message from the E2 node. The RIC service query message may include a message type, a transaction identifier (ID), and a list of RAN functions previously accepted by the Near-RT RIC. The list of RAN functions may include, for each RAN function, a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM).

[0017] In embodiments, an electronic device of an E2 node is provided. The electronic device may include at least one transceiver and at least one processor. The at least one processor may be configured to receive a RIC service query message from a Near-RT (real time) radio access network (RAN) intelligent controller (RIC) through the at least one transceiver, and, in response to the RIC service query message, transmit a RIC service update message to the Near-RT RIC through the at least one transceiver. The RIC service query message may include a message type, a transaction identifier (ID), and a list of RAN functions previously accepted by the Near-RT RIC. The list of RAN functions may include, for each RAN function, a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM).

[0018] In embodiments, an electronic device of a Near-RT (real time) RIC (radio access network (RAN) intelligent controller) is provided. The electronic device may include at least one transceiver and at least one processor. The at least one processor may be configured to cause the Near-RT RIC to transmit a RIC service query message to an E2 node through the at least one transceiver and to receive a RIC service update message from the E2 node through the at least one transceiver. The RIC service query message may include a message type, a transaction identifier (ID), and a list of RAN functions previously accepted by the Near-RT RIC. The list of RAN functions may include, for each RAN function, a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM).

[0019] In embodiments, a non-transitory computer-readable storage medium is provided. The non-transitory computer-readable storage medium may include instructions that, when executed by a processor, cause an E2 node to perform operations including receiving a RIC service query message from a Near-RT (real time) radio access network (RAN) intelligent controller (RIC) and, in response to the RIC service query message, transmitting a RIC service update message to the Near-RT RIC. The RIC service query message may include a message type, a transaction identifier (ID), and a list of RAN functions previously accepted by the Near-RT RIC. The list of RAN functions may include, for each RAN function, a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a particular E2 service model (E2SM).

[0020] In embodiments, a non-transitory computer-readable storage medium is provided. The non-transitory computer-readable storage medium may include instructions that, when executed by a processor, cause a Near-RT (real time) RIC (radio access network (RAN) intelligent controller) to perform operations including transmitting a RIC service query message to an E2 node and receiving a RIC service update message from the E2 node. The RIC service query message may include a message type, a transaction identifier (ID), and a list of RAN functions previously accepted by the Near-RT RIC. The list of RAN functions may include, for each RAN function, a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a particular E2 service model (E2SM).

[0021] Figure 1 is 4G (4 th generation) shows an example of the core network of the LTE (Long Term Evolution) communication system.

[0022] Figure 2 is 5G (5 th generation) shows an example of a core network of a communication system.

[0023] Figure 3 shows an example of an architecture for O-RAN.

[0024] Figure 4a shows an example of a connection between an E2 node and a radio access network intelligence controller (RIC) in a 5G communication system.

[0025] Figure 4b shows the protocol stack of the E2 application protocol message.

[0026] Figure 5 shows the configuration of electronic devices in a wireless access network.

[0027] Figure 6 illustrates the logical functions associated with E2 messages of an E2 node and RIC in a wireless access network.

[0028] Figure 7 shows examples of functional separation between the E2 node and the RIC.

[0029] Figure 8 shows an implementation example of the E2 node and RIC.

[0030] Figure 9 shows examples of functional separation between the CU (central unit) and the RIC.

[0031] Figure 10 shows examples of RAN functions for each E2 node.

[0032] Figures 11a and 11b illustrate signal flows for a RIC service update procedure.

[0033] Figure 12 illustrates an example of error resolution within a Near-RT RIC through a RIC service update procedure.

[0034] The terms used in this disclosure are used only to describe specific embodiments and may not be intended to limit the scope of other embodiments. The singular expression may include plural expressions unless the context clearly indicates otherwise. Terms used herein, including technical or scientific terms, may have the same meaning as commonly understood by those of ordinary skill in the art described in this disclosure. Terms defined in general dictionaries among the terms used in this disclosure may be interpreted as having the same or similar meaning in the context of the relevant technology, and shall not be interpreted in an idealized or overly formal sense unless explicitly defined in this disclosure. In some cases, even if a term is defined in this disclosure, it cannot be interpreted to exclude embodiments of the present disclosure.

[0035] The various embodiments of the present disclosure described below illustrate a hardware-based approach as an example. However, since the various embodiments of the present disclosure include techniques utilizing both hardware and software, the various embodiments of the present disclosure do not exclude a software-based approach.

[0036] In the following description, terms referring to signals (e.g., signal, information, message, signaling), terms referring to data types (e.g., list, set, subset), terms for operational states (e.g., step, operation, procedure), terms referring to data (e.g., packet, user stream, information, bit, symbol, codeword), terms referring to resources (e.g., symbol, slot, subframe, radio frame, subcarrier, resource element (RE), resource block (RB), bandwidth part (BWP), occasion), terms referring to channels, terms referring to network entities, terms referring to components of devices, etc. are examples for convenience of description. Therefore, the present disclosure is not limited to the terms described below, and other terms having equivalent technical meanings may be used.

[0037] In the following description, terms referring to configuration (e.g., setup, setting, arrangement, control), terms referring to signals (e.g., packet, message, signal, information, signaling), terms referring to resources (e.g., section, symbol, slot, subframe, radio frame, subcarrier, RE (resource element), RB (resource block), BWP (bandwidth part), occasion), terms for operational states (e.g., step, operation, procedure), terms referring to data (e.g., packet, message, user stream, information, bit, symbol, codeword), terms referring to channels, terms referring to network entities (DU (distributed unit), RU (radio unit), CU (central unit), CU-CP (control plane), CU-UP (user Terms such as O-DU (O-RAN (open radio access network) DU), O-RU (O-RAN RU), O-CU (O-RAN CU), O-CU-UP (O-RAN CU-CP), O-CU-CP (O-RAN CU-CP)), which refer to components of the device, are examples for convenience of explanation. Therefore, the present disclosure is not limited to the terms described below, and other terms having equivalent technical meanings may be used. In addition, terms such as '... part', '... device', '... object', '... body', etc. used below may mean at least one shape structure or may mean a unit that processes a function.

[0038] In addition, in the present disclosure, expressions such as "more than" or "less than" may be used to determine whether a specific condition is satisfied or fulfilled, but this is merely a description for expressing an example and does not exclude descriptions such as "more than" or "less than." A condition described as "more than" may be replaced with "more than," a condition described as "less than" may be replaced with "less than," and a condition described as "more than and less than" may be replaced with "more than and less than." In addition, hereinafter, "A" to "B" mean at least one of elements from A (including A) to B (including B). hereinafter, "C" and / or "D" mean at least one of "C" or "D," that is, including {"C", "D", "C" and "D"}.

[0039] Although the present disclosure describes various embodiments using terms used in some communication standards (e.g., 3rd Generation Partnership Project (3GPP), European Telecommunications Standards Institute (ETSI), extensible radio access network (xRAN), open-radio access network (O-RAN), etc.), these are merely examples for explanation. The various embodiments of the present disclosure can be easily modified and applied to other communication systems.

[0040] 4th generation (4 th generation, 4G) / 5th generation (5 thAs 5G (5th generation) communication systems (e.g., new radio (NR)) become commercialized, differentiated service support for users in virtualized networks has become required. 3GPP is a joint research project among mobile communication-related organizations, and its goal is to create a globally applicable 3rd generation mobile communication system standard within the scope of the International Telecommunication Union (ITU) IMT-2000 project. Established in December 1998, 3GPP standards are based on the advanced GSM standards, and include radio, core network, and service architecture in the scope of standardization. Accordingly, the O-RAN (open radio access network) newly defines the RU (radio unit), DU (digital unit), CU (central unit)-CP (control plane), and CU-UP (user plane), which are the nodes that constitute the 3GPP NE (network entity) and base station, as O(O-RAN)-RU, O-DU, O-CU-CP, and O-CU-UP, respectively, and additionally standardizes the NRT (near-real-time) RIC (radio access network intelligent controller). The present disclosure is to support an operator specific service model in the E2 interface where the RIC requests a service from the O-DU, O-CU-CP, or O-CU-UP. Here, the O-RU, O-DU, O-CU-CP, and O-CU-UP can be understood as objects that constitute the RAN that can operate according to the O-RAN standard, and can be referred to as E2 nodes. The interface with objects that constitute the RAN, which can operate according to the O-RAN standard between RIC and E2 nodes, uses E2AP (application protocol).

[0041] The RIC is a logical node that can collect information related to the RAN. For example, the information related to the RAN may include information related to the cell site where the terminal and the E2 node (e.g., O-DU, O-CU-CP, or O-CU-UP) transmit and receive. The RIC may be implemented in the form of a server centrally located in one physical location. For example, connections may be established via Ethernet between the O-DU and the RIC, between the O-CU-CP and the RIC, and between the O-CU-UP and the RIC. For this purpose, interface specifications for communication between the O-DU and the RIC, between the O-CU-CP and the RIC, and between the O-CU-UP and the RIC are required, and message specifications such as E2-DU, E2-CU-CP, and E2-CU-UP and definition of procedures between the O-DU, O-CU-CP, O-CU-UP, and the RIC are required. In particular, differentiated service support is required for users in a virtualized network. By concentrating call processing messages / functions generated in O-RAN into RIC, it is necessary to define the functions of E2-DU, E2-CU-CP, and E2-CU-UP messages to support services for wide cell coverage.

[0042] The RIC can communicate with an E2 node (e.g., O-DU, O-CU-CP, and / or O-CU-UP) using the E2 interface. For example, the RIC can establish an event occurrence condition through a subscription procedure with the E2 node. The RIC can establish a call processing event by generating a subscription request message and transmitting the E2 subscription request message to the E2 node. After the call processing event is established, the E2 node can transmit a subscription response message to the RIC. The E2 node can establish services provided by the Near-RT RIC. For example, the E2 node can transmit an RIC indication message (e.g., report information) to the RIC according to the subscription procedure. For example, the RIC can provide control for the E2 node (e.g., O-DU, O-CU-CP, O-CU-UP) using an RIC control message.

[0043] Figure 1 is 4G (4 th generation) shows an example of the core network of the LTE (Long Term Evolution) communication system.

[0044] Referring to FIG. 1, an LTE communication system may include a base station (110), a terminal (120), an S-GW (serving gateway) (130), a P-GW (packet data network gateway) (140), an MME (mobility management entity) (150), an HSS (home subscriber server) (160), and a PCRF (policy and charging rule function) (170).

[0045] The base station (110) is a network infrastructure that provides wireless access to the terminal (120). For example, the base station (110) is a device that performs scheduling by collecting status information such as the buffer status, available transmission power, and channel status of the terminal (120). The base station (110) has coverage defined as a certain geographical area based on the distance at which a signal can be transmitted. The base station (110) is connected to the MME (150) through the S1-MME interface. In addition to the base station, the base station (110) may be referred to as an 'access point (AP)', 'eNodeB (eNB)', 'wireless point', 'transmission / reception point (TRP)', RAN node, or other terms having equivalent technical meanings.

[0046] The terminal (120) is a device used by a user and performs communication with the base station (110) via a wireless channel. In some cases, the terminal (120) may be operated without the user's involvement. That is, the terminal (120) is a device that performs machine type communication (MTC) and may not be carried by the user. The terminal (120) may be referred to as a 'user equipment (UE)', a 'mobile station', a 'subscriber station', a 'customer-premises equipment (CPE)', a 'remote terminal', a 'wireless terminal', a 'user device', or other terms having an equivalent technical meaning.

[0047] The S-GW (130) provides a data bearer and creates or controls the data bearer under the control of the MME (150). For example, the S-GW (130) processes packets arriving from the base station (110) or packets to be forwarded to the base station (110). In addition, the S-GW (130) may serve as an anchor during handover between base stations of the terminal (120). The P-GW (140) may serve as a connection point with an external network (e.g., the Internet). In addition, the P-GW (140) assigns an IP (Internet Protocol) address to the terminal (120) and serves as an anchor for the S-GW (130). In addition, the P-GW (140) may apply a QoS (Quality of Service) policy of the terminal (120) and manage accounting data.

[0048] The MME (150) manages the mobility of the terminal (120). In addition, the MME (150) can perform authentication, bearer management, etc. for the terminal (120). In other words, the MME (150) is responsible for mobility management and various control functions for the terminal. The MME (150) can be linked with an SGSN (serving GPRS support node).

[0049] The HSS (160) stores key information and subscriber profile for authentication of the terminal (120). The key information and subscriber profile are transmitted from the HSS (160) to the MME (150) when the terminal (120) connects to the network.

[0050] PCRF (170) defines rules for policies and charging. Stored information is transmitted from PCRF (180) to P-GW (140), and P-GW (140) can perform control (e.g., QoS management, charging, etc.) on terminal (120) based on the information provided from PCRF (180).

[0051] Figure 2 is 5G (5 th generation) shows an example of a core network of a communication system.

[0052] Referring to FIG. 2, the 5G communication system may include a terminal (201), a base station (203), an access and mobility management function (AMF) (211), a session management function (SMF) (221), and a user plane function (UPF) (231). For the terminal (201), the descriptions of the terminal (120) of FIG. 1 may be referred to. For the base station (203), the descriptions of the base station (110) may be referred to. The base station (203) may be connected to the AMF (211) via the N2 interface and to the UPF (231) via the N3 interface. In addition to the base station, the base station (203) may include an 'access point (AP)', a 'radio access network (RAN) node', a '5G node (5 thThe term "next generation node" (GNB), "next generation nodeB (gNB)," "wireless point", "transmission / reception point (TRP)", "communication node", "wireless communication device", "wireless communication equipment", "network node", "network entity", or other terms having equivalent technical meanings. The AMF (211) may provide functions related to mobility management of the terminal (201), user registration, authentication, connection establishment, and / or release. SMF (221) manages the session and service quality (e.g., QoS (quality of service)) of the terminal (120) in the user plane, and can create and manage a PDU session tunnel using GPT tunneling between UPF (231) and the base station (203). UPF (231) performs the role of processing and routing user data packets, and can provide appropriate processing through classification and priority of traffic as needed. In addition, UPF (231) is connected to a data network (260) and can transmit packets through the Internet.

[0053] The area between the terminal (201) and the base station (203) may be referred to as an access network or RAN. The set of network entities connected to the base station (203) may be referred to as a 5G core network. The 5G core network may include various network functions (NFs) in addition to the AMF (211), SMF (221), and UPF (223). For example, a 5G core network may include a network slice selection function (NSSF) (241), a network exposure function (NEF) (242), a network repository function (NRF) (243), a policy control function (PCF) (244), a unified data management (UDM) (245), an application function (AF) (246), an authentication server function (AUSF) (247), and / or a service capability exposure function (SCP) (248). The NSSF (241) may provide network slice selection that matches a user (e.g., a terminal (201)). The NEF (242) may provide implementation of a service by allowing a service provider to access network resources and network functions. The NRF (243) may act as a database that can search and locate services and functions within the network. The PCF (244) may manage and control quality of service and policies in the network. The UDM (245) may manage and provide profile and subscription information of a user. AF (246) can manage network access and resource allocation for specific services or applications. AUSF (247) can manage user authentication information and perform authentication procedures. SCP (248) can expose network service functions to external applications and support service provision.

[0054] A base station (e.g., base station (203)) may be implemented in a distributed deployment according to a central unit (CU) (or control unit) configured to perform functions of upper layers of an access network (e.g., packet data convergence protocol (PDCP), radio resource control (RRC)) and a distributed unit (DU) configured to perform functions of lower layers. For example, between a core (e.g., 5GC (5G core) or NGC (next generation core)) network and a radio network (RAN), the base station may be implemented in a structure in which the CU, DU (or CU, DU, RU) are deployed in that order. The interface between the CU and the DU may be referred to as an F1 interface. A CU may be connected to one or more DUs and may be responsible for functions of a higher layer than a DU. For example, the CU may be responsible for functions of the RRC (radio resource control) layer and the PDCP (packet data convergence protocol) layer, and the DU (or the DU and the RU) may be responsible for functions of lower layers. The DU may perform functions of the RLC (radio link control) layer, the MAC (media access control) layer, and the PHY (physical) layer. As a non-limiting example, if the DU is connected to the RU (radio unit), the DU may perform some functions of the physical layer (high PHY), and the RU may be responsible for the remaining functions of the PHY layer (low PHY).

[0055] Carrier aggregation (CA) technology is a technology that combines multiple component carriers and allows a single terminal to transmit and receive signals simultaneously using these multiple component carriers, thereby increasing frequency usage efficiency from the perspective of a terminal or a base station. Specifically, according to CA technology, a terminal (e.g., terminal (120), terminal (201)) and a base station (e.g., base station (110), base station (203)) can transmit and receive signals using a wideband using multiple component carriers in uplink (UL) and downlink (DL), respectively, wherein each component carrier is located in a different frequency band. Hereinafter, uplink refers to a communication link through which a terminal transmits a signal to a base station, and downlink refers to a communication link through which a base station transmits a signal to a terminal. At this time, the number of uplink component carriers and downlink component carriers may be different.

[0056] Dual connectivity or multi connectivity is a technology that increases frequency usage efficiency from the perspective of a terminal or a base station by allowing a single terminal to be connected to multiple different base stations and simultaneously transmit and receive signals using carriers within each of multiple base stations located in different frequency bands. The terminal is connected to a first base station (e.g., a base station that provides services using LTE technology or 4th generation mobile communication technology) (e.g., a base station (110)) and a second base station (e.g., NR (new radio) technology or 5G (5 th5G) can be simultaneously connected to a base station (e.g., base station (203)) that provides services using mobile communication technology to transmit and receive traffic. At this time, the frequency resources used by each base station may be located in different bands. For example, a method that operates based on the dual connection method of LTE and NR based on the LTE core network (e.g., evolved packet core (EPC)) may be referred to as 5G NSA (non-standalone). For example, in a 5G communication system, a method that operates through 5G technology (or LTE technology and 5G technology) based on the 5G core network may be referred to as 5G SA (standalone).

[0057] Currently, discussions are underway to improve and enhance the initial 5G mobile communication technology in consideration of the services that 5G mobile communication technology was intended to support, and physical layer standardization is in progress for technologies such as V2X (Vehicle-to-Everything) to help autonomous vehicles make driving decisions and increase user convenience based on their own location and status information transmitted by vehicles, NR-U (New Radio Unlicensed) for the purpose of system operation that complies with various regulatory requirements in unlicensed bands, NR terminal low power consumption technology (UE Power Saving), Non-Terrestrial Network (NTN), which is direct terminal-satellite communication to secure coverage in areas where communication with terrestrial networks is impossible, and Positioning.

[0058] In addition, standardization of wireless interface architecture / protocols is in progress for technologies such as intelligent factories (Industrial Internet of Things, IIoT) to support new services through linkage and convergence with other industries, Integrated Access and Backhaul (IAB) that provides nodes for expanding network service areas by integrating wireless backhaul links and access links, Mobility Enhancement technology including Conditional Handover and Dual Active Protocol Stack (DAPS) handover, and 2-step random access (2-step RACH for NR) that simplifies random access procedures. Standardization is also in progress for system architecture / services such as 5G baseline architecture (e.g., Service-based Architecture, Service-based Interface) for grafting Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) that provides services based on the location of the terminal.

[0059] Once these 5G mobile communication systems are commercialized, an explosive increase in connected devices will be connected to the communication network, necessitating enhanced functionality and performance of 5G mobile communication systems and integrated operation of these connected devices. To this end, new research will be conducted on improving 5G performance and reducing complexity, supporting AI services, supporting metaverse services, and drone communications by utilizing eXtended Reality (XR), Artificial Intelligence (AI), and Machine Learning (ML) to efficiently support Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality (MR).

[0060] In addition, the development of these 5G mobile communication systems includes new waveforms to ensure coverage in the terahertz band of 6G mobile communication technology, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), Array Antenna, and Large Scale Antenna, metamaterial-based lenses and antennas to improve the coverage of terahertz band signals, high-dimensional spatial multiplexing technology using Orbital Angular Momentum (OAM), Reconfigurable Intelligent Surface (RIS) technology, as well as full duplex technology to improve the frequency efficiency and system network of 6G mobile communication technology, satellite, AI (Artificial Intelligence) from the design stage and AI-based communication technology that realizes system optimization by internalizing end-to-end AI support functions, and ultra-high-performance communication and computing resources to provide services with complexity that exceeds the limits of terminal computing capabilities. It can serve as a basis for the development of next-generation distributed computing technologies that can be realized by utilizing them.

[0061] Although FIGS. 1 and 2 illustrate 4G and / or 5G environments, this description does not limit the scope of the communication environments of the embodiments of the present disclosure. The technical principles of the embodiments of the present disclosure can also be applied to 6G and post-6G communication technologies and network environments.

[0062] Figure 3 shows an example of an architecture for O-RAN.

[0063] Referring to FIG. 3, the logical architecture of O-RAN may include a service management orchestration (SMO) (300), an O-eNB (305), an O-RU (310), an O-DU (320), an O-CU-CP (331), an O-CU-UP (332), a Near-RT RIC (340), and a Non-RT RIC (350).

[0064] The SMO (300) may be responsible for RAN management among various management domains (e.g., RAN management, core management, transport management, E2E (end-to-end) slice management) in a service provider's network. For RAN management, the SMO (300) may provide RAN optimization using the FCAPS (fault, configuration, accounting, performance, security) interface and the Non-RT RIC (350).

[0065] The O-eNB (305) may be a node providing an access network in an LTE communication system. For the O-eNB (305), reference may be made to the descriptions of the base station (110) of FIG. 1. The O-RU (310), O-DU (320), O-CU-CP (331), and O-CU-UP (332) may be network entities (or nodes) for providing an access network in an NR communication system. For the O-RU (310), O-DU (320), O-CU-CP (331), and O-CU-UP (332), reference may be made to the descriptions of the base station (203) of FIG. 2.

[0066] The Near-RT RIC (340) is a logical node for customizing RAN functionality for new services or regional resource optimization. The Near-RT RIC (340) may provide functions such as network intelligence (e.g., policy enforcement, handover optimization), resource assurance (e.g., radio-link management, advanced self-organized network (SON)), and resource control (e.g., load balancing, slicing policy). The Near-RT RIC (340) may be connected to an O-eNB (305), an O-CU-CP (331), an O-CU-UP (332), and / or an O-DU (320). Near-RT RIC (340) can communicate with O-eNB (305), O-CU-CP (331), O-CU-UP (332), and / or O-DU (320). RIC (340) can be connected to each node through E2 interface. In addition, the interface between O-CU-CP (331) and O-DU (320) can be referred to as F1-c interface. The interface between O-CU-UP (332) and O-DU (320) can be referred to as F1-u interface. In the following description, DU and O-DU, CU-CP and O-CU-CP, CU-UP and O-CU-UP can be used interchangeably.

[0067] The Non-RT RIC (350) is implemented within the SMO (300) and can communicate with the Near-RT RIC (340) via the A1 interface. Policy management services, enrichment information services, and ML (machine learning) model management services can be provided via the A1 interface. The Non-RT RIC (350) can drive content delivered via the A1 interface.

[0068] O-Cloud (360) is a cloud computing platform consisting of a set of physical infrastructure nodes that meet O-RAN requirements to host relevant O-RAN functions (e.g., Near-RT RIC (340), O-CU-CP (331), O-CU-UP (332), and O-DU (320)), supporting software components (e.g., operating system, virtual machine monitor, container runtime, etc.), and / or appropriate management and orchestration functions.

[0069] Although the O-CU-CP (331) and the O-CU-UP (332) are illustrated in FIG. 3 according to the separation of the control plane and the user plane, the embodiments of the present disclosure are not limited thereto. As a non-limiting example, the O-CU-CP (331) and the O-CU-UP (332) may be understood as one O-CU (330). In addition, although FIG. 3 exemplifies one Near-RT RIC (340), according to various embodiments, multiple Near-RT RICs may exist for the O-RAN architecture. The multiple Near-RT RICs may be implemented with multiple hardware located at the same physical location or may be implemented through virtualization using one hardware.

[0070] Figure 4a shows an example of a connection between an E2 node and a radio access network intelligence controller (RIC) in a 5G communication system.

[0071] Referring to FIG. 4A, the 5G communication system may provide arrangements of entities according to a non-standalone mode (e.g., non-standalone (NSA)) or a standalone mode (e.g., standalone (SA)). Network entities constituting a base station (e.g., base station (110) and base station (203)) may be referred to as E2 nodes, and each network entity may have arrangements according to the non-standalone mode or the standalone mode. For example, in the non-standalone mode, dual connectivity using an eNB and an E2 node may be provided to a terminal. This dual connectivity using LTE and NR may be referred to as EN-DC (E-UTRA (evolved universal terrestrial radio access) - NR dual connectivity). The CU-CP, CU-UP, and DU for operating as gNB may be connected to a Near-RT RIC (e.g., Near-RT RIC (340)) within the O-RAN architecture, and may be referred to as O-CU-CP (331), O-CU-UP (332), and O-DU (320), respectively. For example, in standalone mode, E2 nodes may be independently connected to 5GC. The E2 nodes may be referred to as O-CU-CP (331), O-CU-UP (332), and / or O-DU (320) within the O-RAN architecture. The O-CU-CP (331) may be connected to an AMF (e.g., AMF (211)) within the 5GC via an N2 interface. The O-CU-UP (332) may be connected to a UPF (e.g., UPF (231)) within the 5GC via an N3 interface.

[0072] Figure 4b shows the protocol stack of the E2 application protocol message.

[0073] Referring to FIG. 4b, the control plane includes a transport network layer and a radio network layer. The transport network layer includes a physical layer (410), a data link layer (420), an Internet Protocol (IP) (430), and a stream control transmission protocol (SCTP) (440).

[0074] The wireless network layer includes E2AP (450). E2AP (450) is used to transmit subscription messages, indication messages, control messages, service update messages, and service query messages, and is transmitted in the higher layer of SCTP (440) and IP (430).

[0075] Fig. 5 illustrates a configuration of an electronic device in a wireless access network. The structure illustrated in Fig. 5 can be understood as a configuration of an electronic device having at least one function among the Near-RT RIC (340), non-RT RIC (350), O-CU-CP (331), O-CU-UP (332), O-DU (320), and / or O-eNB (305) illustrated through Fig. 3. Terms such as '... unit', '... device', etc. used hereinafter mean a unit that processes at least one function or operation, and this can be implemented by hardware, software, or a combination of hardware and software.

[0076] Referring to FIG. 5, the electronic device may include a transceiver (510), a memory (520), and a processor (530).

[0077] The transceiver (510) provides an interface for communicating with other electronic devices within a network. That is, the transceiver (510) converts a bit string transmitted from an electronic device to another electronic device into a physical signal, and converts a physical signal received from another electronic device into a bit string. That is, the transceiver (510) can transmit or receive signals. Accordingly, the transceiver (510) may be referred to as a modem, a communication unit, a transmit unit, a receive unit, or a transmit / receive unit. In this case, the transceiver (510) enables the electronic device to communicate with other electronic devices or systems via a backhaul connection (e.g., a wired backhaul or wireless backhaul) or via a network. The transceiver (510) may include one or more transceivers.

[0078] The memory (520) stores data such as basic programs, application programs, and setting information for the operation of the electronic device. The memory (520) may be composed of volatile memory, non-volatile memory, or a combination of volatile and non-volatile memory. Furthermore, the memory (520) provides stored data upon request from the processor (530). The memory (520) may be referred to as a storage unit.

[0079] The processor (530) controls the overall operations of the electronic device. For example, the processor (530) transmits and receives signals via the transceiver (510). Additionally, the processor (530) writes and reads data to and from the memory (520). The processor (530) may be referred to as a control unit. To this end, the processor (530) may be composed of multiple processors or include at least one sub-processor. According to various embodiments, the processor (530) may control the electronic device to perform operations according to various embodiments described in the present disclosure.

[0080] Figure 6 illustrates the logical functions associated with E2 messages of an E2 node and RIC in a wireless access network.

[0081] Referring to FIG. 6, the RIC (640) and the E2 node (610) can transmit or receive E2 messages to each other. For example, the E2 node (610) can be an O-eNB (305), an O-CU-CP (331), an O-CU-UP (332), an O-DU (320), or a base station (e.g., a base station (101), a base station (203)). The communication interface of the E2 node (620) can be determined according to the type of the E2 node (610). For example, the E2 node (610) can communicate with another E2 node (616) through an E1 interface or an F1 interface. Alternatively, for example, the E2 node (610) can communicate with another E2 node (616) through an X2 interface or an XN interface. Or, for example, the E2 node (610) may communicate with the core network entity via an S1 interface or a next generation application protocol (NGAP) interface (e.g., an interface between a next generation (NG) base station (203) and an AMF (211)).

[0082] The E2 node (610) may include an E2 node function (612). The E2 node function (612) is a function corresponding to a specific xApp (application S / W) (646) installed in the RIC (640). For example, in the case of a KPI monitor, the RIC (640) may have a KPI monitor collection S / W installed, and the E2 node (610) may include an E2 node function (612) that generates KPI parameters and then transmits an E2 message including the KPI parameters to an E2 termination (642) located in the RIC (640). The E2 node (610) may include an RRM (radio resource management) (614). The E2 node (610) may manage resources provided to a wireless network for a terminal.

[0083] The E2 terminal (642) located in the RIC (640) is the terminal of the RIC (640) for the E2 message, and performs the function of interpreting the E2 message transmitted by the E2 node (610) and then transmitting it to the xApp (646). The database (644) located in the RIC (640) can be used for the E2 terminal (624) or the xApp (646).

[0084] FIG. 7 illustrates examples of functional separation between an E2 node (e.g., O-eNB (305), O-CU-CP (331), O-CU-UP (332), O-DU (320), or a base station (e.g., base station (101), base station (203)) and a RIC. The RAN standard may provide functional separation between the E2 node and the RIC. For example, the E2 node may be a CU (e.g., CU (330), CU-CP (331), CU-UP (332)). The RIC may be a Near RT RIC (340). The Near RT RIC (340) may be connected to an SMO (300) (e.g., open network automation platform (ONAP) / management and orchestration (MANO) / network management system (NMS)) via an A1 interface. For example, the Near RT RIC (340) may be a non-RT RIC of the SMO (300). The RIC (350) can be connected to the E2 node and the E2 interface. Possible functional separation options may include functional separation (700) in which the entire radio resource management (RRM) is managed by the Near-RT RIC (340) and functional separation (750) in which the RRM is selectively managed by the Near-RT RIC (340).

[0085] Figure 8 illustrates an implementation example of an E2 node and an RIC. In the scenario of the implementation example (800), the E2 node (e.g., O-eNB (305), O-DU (320), O-CU (330), O-CU-CP (331), O-CU-UP (332)) and the RIC (e.g., Near-RT RIC (340)) can be virtualized on a cloud platform (e.g., open chassis and blade-specific edge cloud) and configured on a device (e.g., server). This scenario can provide latency that is sufficiently low to meet the O-DU latency requirements. This scenario can support deployments in dense urban areas with ample fronthaul capacity that allows base band unit (BBU) functions to be pooled at a central location. Therefore, there may be no need to attempt to centralize the near-real time (RT) RIC beyond the limits of centralizing the O-DU functions.

[0086] Figure 9 shows examples of functional separation between the CU (central unit) and the RIC.

[0087] Referring to FIG. 9, functions for CU (910) (e.g., O-CU (330), O-CU-CP (331), O-CU-UP (332)) and RIC (920) (e.g., Near-RT RIC (340)) can be implemented separately or jointly. Depending on the arrangement of the functions, a deployment scenario can be determined. For example, the functions can be distributed according to deployment scenario #1 (900). They can be configured to replace only at least one intelligence-essential function (e.g., traffic steering, cell admission control (CAC) function). In deployment scenario #1 (900), the RIC (920) can be located in a separate site or exist only as another NE. For another example, the functions can be distributed according to deployment scenario #2 (950). In deployment scenario #2 (950), the RIC (920) can replace almost all functions of the CU (910) except for 3GPP I / F management (e.g., mobility function, session function, UE context function, cell context function). In deployment scenario #2 (950), the RIC (920) can be implemented as a device (e.g., server device) similar to the CU (910). For example, the RIC (920) can share all functions with the CU (910) within the same cloud.

[0088] Although two scenarios are illustrated in FIG. 9, other scenarios may also be applicable. For example, in deployment scenario #1 (900), the mobility function may be performed by the RIC (920) rather than the CU (910). Also, for example, in deployment scenario #1 (900), the UE context function may be performed by the RIC (920) rather than the CU (910). Also, for example, in deployment scenario #1 (900), the session function may be performed by the RIC (920) rather than the CU (910).

[0089] Figure 10 illustrates examples of RAN functions for each E2 node. In O-RAN, a RAN function represents a specific function in an E2 node. For example, a RAN function may include RAN internal functions for handling UEs and / or cells. A RAN function ID (identifier) ​​represents a logical identifier of a specific RAN function within an E2 node that supports one or more RIC services using a specific E2 service model (E2SM). A RAN function OID (object identifier) ​​indicates the type of E2SM and can be used to identify the definition of a RAN function. A RAN function ID is not a unique value for a RAN function, but rather an index for indicating the RAN function in the corresponding E2 node. In reality, even if the RAN function is the same, E2 nodes may map the RAN function to different RAN function IDs. Furthermore, E2 nodes may map different RAN functions to the same RAN function ID. Therefore, to know information about actual RAN functions, in addition to the RAN function ID, a RAN function definition or RAN function OID may be required.

[0090] Referring to FIG. 10, each E2 node (e.g., the first E2 node (1051), the second E2 node (1052), and the third E2 node (1053)) can provide information about RAN functions to the Near-RT RIC (1040) (e.g., the Near-RT RIC (340)) through an E2 setup procedure with the Near-RT RIC (1040). For example, the E2 node can transmit an E2 setup request message to the Near-RT RIC (1040). The E2 setup request message can include information about one or more RAN functions. The Near-RT RIC (1040) can transmit information about at least one RAN function accepted among the one or more RAN functions to the corresponding E2 node through an E2 setup response message. In this way, the Near-RT RIC (1040) can store information about the RAN functions in each E2 node.

[0091] The Near-RT RIC (1040) may be connected to E2 nodes (e.g., a first E2 node (1051), a second E2 node (1052), and a third E2 node (1053). For example, the first E2 node (1051) may store three RAN functions. The first E2 node (1051) may store E2SM-RC, Revision 2, and OID in RAN function ID #1. The OID may represent E2SM-RC. Revision 2 represents a revision counter of the corresponding RAN function. The first E2 node (1051) may store E2SM-KPM, Revision 1, and OID in RAN function ID #2. The OID may represent E2SM-KPM. The first E2 node (1051) may store E2SM-CCC, Revision 1, and OID in RAN Function ID #3. The OID may represent E2SM-CCC. For example, the second E2 node (1052) may store three RAN functions. The second E2 node (1052) may store E2SM-RC, Revision 2, and OID in RAN Function ID #1. The OID may represent E2SM-RC. The second E2 node (1052) may store E2SM-CCC, Revision 1, and OID in RAN Function ID #2. The OID may represent E2SM-CCC. The second E2 node (1052) may store E2SM-KPM, Revision 1, and OID in RAN Function ID #3. The OID may represent E2SM-KPM. For example, the third E2 node (1053) may store three RAN functions. The third E2 node (1053) may store E2SM-CCC, Revision 2, and OID in RAN function ID #1. The OID may represent E2SM-CCC.The third E2 node (1053) may store E2SM-RC, Revision 1, and OID in RAN Function ID #2. The OID may represent E2SM-RC. The third E2 node (1053) may store E2SM-KPM, Revision 1, and OID in RAN Function ID #3. The OID may represent E2SM-KPM.

[0092] The Near-RT RIC (1040) is required to store the same information as the RAN function IDs stored in each E2 node and the related information corresponding to the RAN function IDs (e.g., OID, Revision, service model, etc.). However, if there is a problem with the connection status while performing a series of procedures (e.g., E2 setup procedures) between the Near-RT RIC (1040) and the E2 node, or if an error occurs in the database within the Near-RT RIC (1040), the Near-RT RIC (1040) may store information about RAN functions for each E2 node differently from the actual configuration. For example, the Near-RT RIC (1040) may associate information indicating the E2 node (e.g., E2 node index, E2 node component ID) with an E2 node other than the E2 node. In other words, an error may occur in the index of the E2 node stored in the Near-RT RIC (1040). The Near-RT RIC (1040) can store a RAN function profile for the first E2 node (1051) in a RAN function profile (1063) for the third E2 node (1053). The Near-RT RIC (1040) can store a RAN function profile for the second E2 node (1052) in a RAN function profile (1061) for the first E2 node (1051). The Near-RT RIC (1040) can store a RAN function profile for the third E2 node (1053) in a RAN function profile (1062) for the second E2 node (1052).

[0093] In the above-described situation, the Near-RT RIC (1040) can perform an RIC service update procedure with the third E2 node (1053). The Near-RT RIC (1040) can transmit an RIC service query message to the third E2 node (1053). The RIC service query message defined in the current specification is as follows.

[0094]

[0095] For 'IE type and reference', O-RAN WG3 E2AP specification can be referenced. 'M' (mandatory) indicates that the corresponding IE is mandatory, and 'O' (optional) indicates that the corresponding IE is optional. 'Message Type' indicates the type of message (e.g., initiating message, successful outcome, unsuccessful outcome), and 'Transaction ID' can be used to uniquely identify the corresponding procedure (e.g., the RIC service update procedure) among the parallel ongoing procedures of the same type. 'RAN Functions Accepted List' indicates the full list of RAN functions accepted by the Near-RT RIC (1040). 'RAN Functions ID Item' indicates the RAN function ID ('RAN Function ID') and RAN function revision ('RAN Function Revision') for each RAN function. The above RAN function revision indicates the revision counter (or update version information, number of updates) for the corresponding RAN function.

[0096] The Near-RT RIC (1040) can transmit an RIC service query message according to Table 1 to the third E2 node (1053). The Near-RT RIC (1040) can transmit an RIC service query message indicating 'RAN function ID #1' and 'Revision 2' to the third E2 node (1053). The Near-RT RIC (1040) transmits the RIC service query message for the purpose of providing a RIC service according to E2SM-RC, but the third E2 node (1053) can feed back a RAN function corresponding to E2SM-CCC. Referring to Table 1, each RAN function item is a parameter indicating a RAN function, and only includes a RAN function ID and a RAN function revision, and does not include any other parameters. Since the RIC service query message of the Near-RT RIC (1040) does not contain any information about the definition or service model related to the RAN function, the third E2 node (1053) cannot detect that incorrect information is stored in the Near-RT RIC (1040). In other words, the third E2 node (1053) cannot detect the above-described error for a RAN function having the same RAN function ID and RAN function revision indicated by the Near-RT RIC (1040). According to the specification, the third E2 node (1053) may transmit a RIC service update message that does not include information about separate RAN functions (e.g., RAN Function Added List IE, RAN Function Modified List IE and RAN Function Deleted List IE) if the information about RAN functions (e.g., RAN Functions Accepted List) in the RIC service query message of the Near-RT RIC (1040) matches all the RAN functions supported by the third E2 node (1053).Since 'RAN Function ID #1' and 'Revision 2' are the same for both the third E2 node (1053) and the Near-RT RIC (1040), 'RAN Function ID #2' and 'Revision 1' are the same for both the third E2 node (1053) and the Near-RT RIC (1040), and 'RAN Function ID #3' and 'Revision 1' are the same for both the third E2 node (1053) and the Near-RT RIC (1040), the third E2 node (1053) can transmit an RIC service update message to the Near-RT RIC (1040) that does not include information about separate RAN functions (e.g., RAN Function Added List IE, RAN Function Modified List IE and RAN Function Deleted List IE). Therefore, the Near-RT RIC (1040) performs the RIC subscription procedure or the RIC control procedure based on the incorrect profile for the third E2 node (1053).

[0097] To solve the above-described problem, embodiments of the present disclosure describe methods for more specifically informing an E2 node (e.g., a first E2 node (1051), a second E2 node (1052), a third E2 node (1053)) of information about RAN functions or requesting all RAN functions that can be supported by the E2 node through a RIC service query message.

[0098] 1. Method 1

[0099] The Near-RT RIC (1040) may transmit an RIC service query message to the E2 node, including a RAN function ID, a RAN function revision, and a RAN function OID for each RAN function. For example, the RIC service query message may have the following format.

[0100]

[0101] For 'IE type and reference', O-RAN WG3 E2AP specification can be referenced. 'M' indicates that the corresponding IE is mandatory, and 'O' indicates that the corresponding IE is optional. 'Message Type' indicates the message type (e.g., initiation message, successful result, failed result), and 'Transaction ID' can be used to uniquely identify the corresponding procedure (e.g., the RIC service update procedure) among the parallel ongoing procedures of the same type. 'RAN Functions Accepted List' indicates the full list of RAN functions accepted by the Near-RT RIC (1040). 'RAN Functions ID Item' indicates the RAN function ID ('RAN Function ID'), RAN function revision ('RAN Function Revision'), and RAN function OID ('RAN Function OID') for each RAN function. The RAN function revision indicates a revision counter for the corresponding RAN function. The above RAN function OID can uniquely represent a specific E2 SM (service model). The RAN function OID can be used to represent a RAN function definition for a specific E2SM. Since a service model corresponding to a RAN function is indicated through the RAN function OID, a problem of information mismatch between the E2 node and the Near-RT RIC (1040) can be resolved. The RAN function OID can indicate a service model specified in the O-RAN. The RAN function OID can indicate one of a plurality of service models specified in the O-RAN.For example, the plurality of service models may include E2SM-NI (network interface), E2SM-KPM (key performance monitoring) version 1, E2SM-KPM version 2, E2SM-RC (radio control), and / or E2SM-CCC (cell configuration and control). The RAN function OID may have different values ​​depending on the service model to be indicated. For example, the RAN function OID may have the following format.

[0102]

[0103] 2. Method 2

[0104] The Near-RT RIC (1040) may transmit an RIC service query message to the E2 node, including a RAN function ID, a RAN function revision, a RAN function OID, and a RAN function definition for each RAN function. For example, the RIC service query message may have the following format.

[0105]

[0106] For 'IE type and reference', O-RAN WG3 E2AP specification can be referenced. 'M' indicates that the corresponding IE is mandatory, and 'O' indicates that the corresponding IE is optional. 'Message Type' indicates the message type (e.g., initiation message, successful result, failed result), and 'Transaction ID' can be used to uniquely identify the corresponding procedure (e.g., the RIC service update procedure) among the parallel ongoing procedures of the same type. 'RAN Functions Accepted List' indicates the full list of RAN functions accepted by the Near-RT RIC (1040). 'RAN Functions ID Item' indicates the RAN function ID ('RAN Function ID'), RAN function revision ('RAN Function Revision'), RAN function OID ('RAN Function OID'), and RAN function definition ('RAN Function Definition') for each RAN function. The RAN function revision indicates a revision counter for the corresponding RAN function. The above RAN function OID may uniquely represent a specific E2 SM (service model) (e.g., OID and E2SM in [Table 3]). The RAN function definition may indicate how an E2 node is configured to support a given function in the corresponding service model (e.g., the type of service model indicated by the RAN function OID). The RAN function definition may include information required to determine the configuration of the given function of the E2 node. The RAN function definition may include one or more RAN parameters according to the RIC service style (e.g., report, insert, control, policy).

[0107] Meanwhile, for backward compatibility, the RAN function OID and RAN function definition are configured as shown in Table 4 (e.g., optional), but embodiments of the present disclosure are not limited thereto. For example, each RAN function item of the RIC service query message may be configured as shown in the table below to ensure format consistency with the items of the RIC service update message (e.g., [Table 8] in FIGS. 11a and 11b).

[0108]

[0109] For each IE in Table 5, the descriptions in Table 4 may be referenced.

[0110] 3. Third method

[0111] The Near-RT RIC (1040) can transmit an RIC service query message to the E2 node, which includes only a message type and transaction ID. For example, the RIC service query message may have the following format.

[0112]

[0113] For 'IE type and reference', the O-RAN WG3 E2AP specification can be referenced. 'M' indicates that the corresponding IE is mandatory, and 'O' indicates that the corresponding IE is optional. 'Message Type' indicates the message type (e.g., initiation message, successful result, failed result), and 'Transaction ID' can be used to uniquely identify the corresponding procedure (e.g., the RIC service update procedure) among the parallel ongoing procedures of the same type. An RIC service query message that does not include information related to a separate RAN function can be used to request a list of all RAN functions that can be supported by the E2 node. The format of the RIC service query message can be fixed to the format of [Table 6]. The E2 node can be configured to always respond to the RIC service query message and feed back a list of all RAN functions that can be supported by the E2 node. The list of all RAN functions that can be supported by the above E2 node may include, for each RAN function, a RAN function ID, a RAN function definition, a RAN function revision, and a RAN function OID.

[0114] 4. Fourth method

[0115] The Near-RT RIC (1040) may transmit an RIC service query message containing an instruction to request the entire list from the E2 node. For example, the RIC service query message may have the following format.

[0116]

[0117] For 'IE type and reference', O-RAN WG3 E2AP specification can be referenced. 'M' indicates that the corresponding IE is mandatory, and 'O' indicates that the corresponding IE is optional. 'Message Type' indicates the message type (e.g., initiation message, successful result, failed result), and 'Transaction ID' can be used to uniquely identify the corresponding procedure (e.g., the RIC service update procedure) among the parallel ongoing procedures of the same type. 'RAN Functions Accepted List' indicates the full list of RAN functions accepted by the Near-RT RIC (1040). 'RAN Functions ID Item' indicates the RAN function ID ('RAN Function ID'), RAN function revision ('RAN Function Revision'), and RAN function OID ('RAN Function OID') for each RAN function. The RAN function revision indicates a revision counter for the corresponding RAN function. The RAN function OID can uniquely identify a specific E2 SM. The above RAN function OID can be used to indicate the RAN function definition for a specific E2SM. The 'Request Indicator' can be used as a request indicator to request the E2 node for a full list of RAN functions supported by the E2 node. The 'Request Indicator' can be used as a conditional indicator. If the E2 node determines that any information about RAN functions in the RIC service query message of the Near-RT RIC (1040) (e.g., RAN Functions Accepted List) does not match any information actually stored in the E2 node, the conditional indicator can cause the E2 node to transmit a RIC service update message containing information about all RAN functions supported by the E2 node.Through the above indicator, information mismatch between the Near-RT RIC (1040) and the E2 node can be resolved early. [Table 7] is an example in which the above indicator is added to [Table 2] of the first method, but the embodiments of the present disclosure are not limited thereto. In addition to [Table 2], the above indicator may also be added to [Table 1], [Table 4], and [Table 5].

[0118] Figures 11a and 11b illustrate the signal flows for the RIC service update procedure. The purpose of the RIC service update procedure is to update application-level RIC service-related data required for the E2 node and the Near-RT RIC to interoperate properly through the E2 interface.

[0119] Referring to FIG. 11A, in operation (1101), the Near-RT RIC (1040) may transmit an RIC service query message to the E2 node (1050). In one embodiment, the RIC service query message may include an OID corresponding to each RAN function within the RAN function acceptance list. For example, the RIC service query message may have the format of [Table 2]. In one embodiment, the RIC service query message may include an OID and a RAN function definition corresponding to each RAN function within the RAN function acceptance list. For example, the RIC service query message may have the format of [Table 4] or [Table 5]. In one embodiment, the RIC service query message may not include the RAN function acceptance list. For example, the RIC service query message may have the format of [Table 6]. In one embodiment, the RIC service query message may include an indicator for requesting the entire list when there is a mismatch with the RAN function acceptance list. For example, a RIC service query message may have the format shown in Table 7.

[0120] In operation (1103), the E2 node (1050) may transmit an RIC service update message to the Near-RT RIC (1040). Upon receiving the RIC service update message from the E2 node (1050), the Near-RT RIC (1040) may update application-level data. The updated RAN functions may be used for RIC subscription requests or RIC control messages. For example, the RIC service update message may have the following format.

[0121]

[0122] For 'IE type and reference', the O-RAN WG3 E2AP specification can be referenced. 'M' indicates that the corresponding IE is mandatory, and 'O' indicates that the corresponding IE is optional. 'Message Type' indicates a message type (e.g., initiation message, successful result, failed result), and 'Transaction ID' can be used to uniquely identify the corresponding procedure (e.g., the RIC service update procedure) among the parallel ongoing procedures of the same type. 'RAN Functions Added List' indicates information on RAN functions to be added by the E2 node (1050). 'RAN Functions Modified List' indicates information on RAN functions to be modified by the E2 node (1050). 'RAN Functions Deleted List' indicates information on RAN functions to be deleted by the E2 node (1050). Information for each RAN function includes a RAN function ID ('RAN Function ID'), a RAN function definition ('RAN Function Definition'), a RAN function revision ('RAN Function Revision'), and a RAN function OID ('RAN Function OID'). The RAN function revision indicates a revision counter for the corresponding RAN function. The RAN function OID may uniquely indicate a specific E2 SM (service model) (e.g., OID and E2SM in [Table 3]). The RAN function definition may indicate how an E2 node is configured to support a given function in the corresponding service model (e.g., a type of service model indicated by the RAN function OID). The RAN function definition may include information required to determine the configuration of the given function of the E2 node.

[0123] In response to the RIC service query message, the E2 node (1050) may transmit a RIC service update message to the Near-RT RIC (1040). For example, if the RIC service query message does not include a RAN function acceptance list, the E2 node (1050) may transmit a RIC service update message including a list of all RAN functions supported by the E2 node (1050). For example, if the information of the RAN functions in the RAN function acceptance list in the RIC service query message aligns with the information of the RAN functions supported by the E2 node (1050), the E2 node (1050) may transmit the RIC service update message without a list of RAN functions (e.g., 'RAN Functions Added List', 'RAN Functions Modified List', 'RAN Functions Deleted List' in [Table 8]). For example, if the information of RAN functions in the RAN function acceptance list in the RIC service query message does not match the information of RAN functions supported by the E2 node (1050), the E2 node (1050) may transmit a list of necessary RAN functions (e.g., 'RAN Functions Added List', 'RAN Functions Modified List', 'RAN Functions Deleted List' of [Table 8]) through the RIC service update message to ensure realignment between the E2 node (1050) and the Near-RT RIC (1040).

[0124] In operation (1105), the Near-RT RIC (1040) may transmit an RIC service update confirmation message to the E2 node (1050). If the update of at least one RAN function within the RIC service update message is successful, the Near-RT RIC (1040) may transmit the update confirmation message. For example, the update confirmation message may have the following format.

[0125]

[0126] For 'IE type and reference', the O-RAN WG3 E2AP specification can be referenced. 'M' indicates that the corresponding IE is mandatory, and 'O' indicates that the corresponding IE is optional. For details on each IE, [Table 1] to [Table 8] can be referenced. Cause information for rejection for each RAN function can be included.

[0127] In one embodiment, the information included for each RAN function in the RIC service update confirmation message may match the information included for each RAN function in the RIC service query message. For example, when a RIC service query message according to [Table 2] is transmitted, the Near-RT RIC (1040) may transmit to the E2 node (1050) a list (e.g., 'RAN Functions Accepted List' IE) including, for each RAN function, a RAN function ID, a RAN function revision, and a RAN function OID. For another example, when a RIC service query message according to [Table 4] is transmitted, the Near-RT RIC (1040) may transmit to the E2 node (1050) a list (e.g., 'RAN Functions Accepted List' IE) including, for each RAN function, a RAN function ID, a RAN function revision, a RAN function OID, and a RAN function definition.

[0128] Referring to FIG. 11B, in operation (1101), the Near-RT RIC (1040) may transmit an RIC service query message to the E2 node (1050). In one embodiment, the RIC service query message may include an OID corresponding to each RAN function within the RAN function acceptance list. For example, the RIC service query message may have the format of [Table 2]. In one embodiment, the RIC service query message may include an OID and a RAN function definition corresponding to each RAN function within the RAN function acceptance list. For example, the RIC service query message may have the format of [Table 4] or [Table 5]. In one embodiment, the RIC service query message may not include the RAN function acceptance list. For example, the RIC service query message may have the format of [Table 6]. In one embodiment, the RIC service query message may include an indicator for requesting the entire list when there is a mismatch with the RAN function acceptance list. For example, a RIC service query message may have the format shown in Table 7.

[0129] In operation (1103), the E2 node (1050) may transmit an RIC service update message to the Near-RT RIC (1040). Upon receiving the RIC service update message from the E2 node (1050), the Near-RT RIC (1040) may update application-level data. The updated RAN functions may be used for RIC subscription requests or RIC control messages. For example, the RIC service update message may have the format of [Table 8].

[0130] In operation (1155), the Near-RT RIC (1040) may transmit an RIC service update failure message to the E2 node (1050). If the Near-RT RIC (1040) has difficulty accepting the update of the RIC service update message, the Near-RT RIC (1040) may transmit the RIC service update failure message. For example, the RIC service update failure message may have the following format.

[0131]

[0132] For 'IE type and reference', O-RAN WG3 E2AP specification can be referenced. 'M' indicates that the corresponding IE is mandatory, and 'O' indicates that the corresponding IE is optional. 'Message Type' indicates the message type (e.g., initiation message, successful result, failed result), and 'Transaction ID' can be used to uniquely identify the corresponding procedure (e.g., the RIC service update procedure) among the parallel ongoing procedures of the same type. 'Cause' indicates the cause of failure, and 'Time To Wait' indicates the minimum allowed waiting time.

[0133] FIG. 12 illustrates an example of error resolution within a Near-RT RIC (e.g., Near-RT RIC (1040)) through a RIC service update procedure. FIG. 12 illustrates examples of correcting an erroneously stored RAN function profile of an E2 node within a Near-RT RIC (1040) by performing a RIC service update procedure according to the above-described methods (e.g., the first method, the second method, the third method, the fourth method, and / or a technically equivalent method). It is assumed that the RAN functions of the first E2 node (1051), the second E2 node (1052), and the third E2 node (1053) illustrated in FIG. 10 are stored within the Near-RT RIC (1040).

[0134] Referring to FIG. 12, in operation (1211), the Near-RT RIC (1040) may transmit an RIC service query message to the first E2 node (1051). In operation (1213), the first E2 node (1051) may transmit an RIC service update message to the Near-RT RIC (1040).

[0135] According to one embodiment, when following the first method, the RIC service query message may include {('Revision 2' and 'OID (e.g., indicating E2SM-RC) corresponding to RAN Function ID #1'), ('Revision 1' and 'OID (e.g., indicating E2SM-CCC) corresponding to RAN Function ID #2'), ('Revision 1' and 'OID (e.g., indicating E2SM-KPM) corresponding to RAN Function ID #3')}. The RIC service query message may have the format of [Table 2]. The first E2 node (1051) may compare information about RAN functions in the RIC service query message with information about RAN functions supported by the first E2 node (1051). For RAN Function ID #2, the first E2 node (1051) and the Near-RT RIC (1040) have different service models. For RAN function ID #3, the first E2 node (1051) and the Near-RT RIC (1040) have different service models. Therefore, the first E2 node (1051) may transmit RAN function items (e.g., a combination of RAN function ID, RAN function definition, RAN function revision, and RAN function OID) corresponding to each of RAN function ID #2 and RAN function ID #3 to the Near-RT RIC (1040). For example, the first E2 node (1051) may include {(RAN function definition, RAN function revision, and RAN function OID corresponding to RAN function ID #2 (e.g., E2SM-KPM)), (RAN function definition, RAN function revision, and RAN function OID corresponding to RAN function ID #3 (e.g., E2SM-CCC))) in the 'RAN Functions Modified List' IE of [Table 8]. The first E2 node (1051) can transmit a RIC service update message including the 'RAN Functions Modified List' IE to the Near-RT RIC (1040).

[0136] According to one embodiment, when following the second method, the RIC service query message may include {('Revision 2' corresponding to RAN function ID #1, 'OID (e.g., indicating E2SM-RC)', and RAN function definition), ('Revision 1' corresponding to RAN function ID #2, 'OID (e.g., indicating E2SM-CCC)', and RAN function definition), ('Revision 1' corresponding to RAN function ID #3, 'OID (e.g., indicating E2SM-KPM)', and RAN function definition)}. The RIC service query message may have the format of [Table 4]. The first E2 node (1051) may compare information about RAN functions in the RIC service query message with information about RAN functions supported by the first E2 node (1051). For RAN function ID #2, the first E2 node (1051) and the Near-RT RIC (1040) have different service models. For RAN function ID #3, the first E2 node (1051) and the Near-RT RIC (1040) have different service models. Therefore, the first E2 node (1051) may transmit RAN function items (e.g., a combination of RAN function ID, RAN function definition, RAN function revision, and RAN function OID) corresponding to each of RAN function ID #2 and RAN function ID #3 to the Near-RT RIC (1040). For example, the first E2 node (1051) may include {(RAN function definition corresponding to RAN function ID #2, RAN function revision, and RAN function OID (e.g., E2SM-KPM)), (RAN function definition corresponding to RAN function ID #3, RAN function revision, and RAN function OID (e.g., E2SM-CCC)) in the 'RAN Functions Modified List' IE of [Table 8].The first E2 node (1051) can transmit a RIC service update message including the 'RAN Functions Modified List' IE to the Near-RT RIC (1040).

[0137] In one embodiment, according to the third method, the RIC service query message may not include any information other than the message type and transaction ID (e.g., information about RAN functions). For example, the RIC service query message may have the format of [Table 6]. In response to the RIC service query message, the first E2 node (1051) may transmit an RIC service update message including a complete list of RAN functions supported by the first E2 node (1051). For example, the first E2 node (1051) may include {(RAN function definition, RAN function revision, and RAN function OID corresponding to RAN function ID #1 (e.g., E2SM-RC)), (RAN function definition, RAN function revision, and RAN function OID corresponding to RAN function ID #2 (e.g., E2SM-KPM)), (RAN function definition, RAN function revision, and RAN function OID corresponding to RAN function ID #3 (e.g., E2SM-CCC)) in the 'RAN Functions Modified List' IE of [Table 8]. The first E2 node (1051) may transmit a RIC service update message including the 'RAN Functions Modified List' IE to the Near-RT RIC (1040).

[0138] According to one embodiment, when following the fourth method, the RIC service query message may include {('Revision 2' and 'OID (e.g., indicating E2SM-RC) corresponding to RAN Function ID #1'), ('Revision 1' and 'OID (e.g., indicating E2SM-CCC) corresponding to RAN Function ID #2'), ('Revision 1' and 'OID (e.g., indicating E2SM-KPM) corresponding to RAN Function ID #3)} and a request indicator (e.g., Request Indicator of [Table 7]). For example, the RIC service query message may have the format of [Table 7]. The first E2 node (1051) may compare information about RAN functions in the RIC service query message with information about RAN functions supported by the first E2 node (1051). The first E2 node (1051) may recognize that it stores different information than the Near-RT RIC with respect to RAN Function ID #2 or RAN Function ID #3. In response to identifying this mismatch, the first E2 node (1051) may transmit a RIC Service Update message that includes a full list of RAN functions supported by the first E2 node (1051). For example, the first E2 node (1051) may include {(RAN function definition, RAN function revision, and RAN function OID corresponding to RAN Function ID #1 (e.g., E2SM-RC)), (RAN function definition, RAN function revision, and RAN function OID corresponding to RAN Function ID #2 (e.g., E2SM-KPM)), (RAN function definition, RAN function revision, and RAN function OID corresponding to RAN Function ID #3 (e.g., E2SM-CCC))) in the 'RAN Functions Modified List' IE of Table 8.The first E2 node (1051) can transmit a RIC service update message including the 'RAN Functions Modified List' IE to the Near-RT RIC (1040).

[0139] At operation (1221), the Near-RT RIC (1040) may transmit an RIC service query message to the second E2 node (1052). At operation (1223), the second E2 node (1052) may transmit an RIC service update message to the Near-RT RIC (1040). Like the first E2 node (1051), the second E2 node (1052) may also transmit the RIC service update message to achieve alignment with the Near-RT RIC (1040).

[0140] According to one embodiment, the second E2 node (1052) can identify a RAN function acceptance list (e.g., 'RAN Functions Accepted List' IE of [Table 2] of the first scheme, [Table 4] of the second scheme, or [Table 7] of the fourth scheme) of the RIC service query message. The second E2 node (1052) can compare information about RAN function(s) in the RAN function acceptance list with information about RAN function(s) supported by the second E2 node (1052). For example, in response to a RIC service query message according to the first scheme or the second scheme, the second E2 node (1052) can transmit a RAN function item (e.g., a combination of a RAN function ID, a RAN function definition, a RAN function revision, and a RAN function OID) corresponding to a difference according to the comparison result, via a RIC service update message. For example, in response to the RIC service query message according to the fourth method, the second E2 node (1052) may transmit, via the RIC service update message, each RAN function item (e.g., a combination of a RAN function ID, a RAN function definition, a RAN function revision, and a RAN function OID) of all RAN functions supported by the second E2 node (1052), regardless of the result of the comparison. According to another embodiment, the second E2 node (1052) may identify the RIC service query message transmitted according to the third method described above. In response to the RIC service query message, the second E2 node (1052) may transmit, via the RIC service update message, each RAN function item (e.g., a combination of a RAN function ID, a RAN function definition, a RAN function revision, and a RAN function OID) of all RAN functions supported by the second E2 node (1052).

[0141] At operation (1231), the Near-RT RIC (1040) may transmit a RIC service query message to the third E2 node (1053). At operation (1233), the third E2 node (1053) may transmit a RIC service update message to the Near-RT RIC (1040). Like the first E2 node (1051), the third E2 node (1053) may also transmit the RIC service update message for reconciliation with the Near-RT RIC (1040). In one embodiment, the third E2 node (1053) may identify a RAN function acceptance list (e.g., 'RAN Functions Accepted List' IE of [Table 2] of the first scheme, [Table 4] of the second scheme, or [Table 7] of the fourth scheme) in the RIC service query message. The third E2 node (1053) can compare information about the RAN function(s) in the RAN function acceptance list with information about the RAN function(s) supported by the third E2 node (1053). For example, in response to the RIC service query message according to the first or second method, the third E2 node (1053) can transmit a RAN function item (e.g., a combination of a RAN function ID, a RAN function definition, a RAN function revision, and a RAN function OID) corresponding to a difference according to the comparison result, via a RIC service update message. For example, in response to the RIC service query message according to the fourth method, the third E2 node (1053) can transmit, via a RIC service update message, each RAN function item (e.g., a combination of a RAN function ID, a RAN function definition, a RAN function revision, and a RAN function OID) of all RAN functions supported by the third E2 node (1053), regardless of the result of the comparison. In another embodiment, the third E2 node (1053) may identify the RIC service query message transmitted according to the third method described above.In response to the RIC service query message, the third E2 node (1053) may transmit each RAN function item (e.g., a combination of RAN function ID, RAN function definition, RAN function revision, and RAN function OID) of all RAN functions supported by the third E2 node (1053) through a RIC service update message.

[0142] By transmitting additional information (e.g., RAN function OID, RAN function definition) to the E2 node through the RIC service query message, the E2 node can be queried for more accurate RAN functions. Therefore, even if the RAN function information for the E2 node is incorrectly stored in the Near-RT RIC, the RAN function information can be correctly shared between the two nodes through the E2 service update procedure. By causing the E2 node to transmit the items (e.g., RAN function ID, RAN function definition, RAN function revision, and RAN function OID) for the RAN functions incorrectly stored in the Near-RT RIC through the above-described RIC service query message, a corrupted database in the Near-RT RIC can be recovered.

[0143] The effects that can be obtained from the present disclosure are not limited to the effects mentioned above, and other effects that are not mentioned can be clearly understood by a person having ordinary skill in the art to which the present disclosure belongs from the description below.

[0144] In embodiments, a method performed by an E2 node is provided. The method may include receiving a RIC service query message from a Near-RT (real time) radio access network (RAN) intelligent controller (RIC). The method may include transmitting a RIC service update message to the Near-RT RIC in response to the RIC service query message. The RIC service query message may include a message type, a transaction identifier (ID), and a list of RAN functions previously accepted by the Near-RT RIC. The list of RAN functions may include, for each RAN function, a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM).

[0145] For example, the list of RAN functions may further include RAN function definition information for each RAN function. The RAN function definition information may be used to provide the Near-RT RIC with the information necessary to support the corresponding RAN function in the E2 node. The RAN function OID may be used to identify the RAN function definition in the RAN function definition information.

[0146] For example, the RAN function OID may represent one of multiple service models. The multiple service models may include E2SM-NI (network interface), E2SM-KPM (key performance monitoring) version 1, E2SM-KPM version 2, E2SM-RC (radio control), and E2SM-CCC (cell configuration and control).

[0147] For example, the method may include receiving a RIC service update confirmation message or a RIC service update failure message from the Near-RT RIC. The RIC service update message may include an additional list of RAN functions, a modified list of RAN functions, and / or a deleted list of RAN functions, if the RAN functions supported by the E2 node do not match the functions in the list. The RIC service update message may not include the additional list, the modified list, and the deleted list, if the RAN functions supported by the E2 node match the functions in the list.

[0148] For example, the method may include receiving, from the Near-RT RIC, a second RIC service query message that does not include a list of RAN capabilities. The method may include transmitting, to the Near-RT RIC, a second RIC service update message. The second RIC service update message may include a list of all RAN capabilities supported by the E2 node, in response to the second RIC service query message that does not include a list of RAN capabilities.

[0149] In embodiments, a method performed by a Near-RT (real time) RIC (radio access network (RAN) intelligent controller) is provided. The method may include transmitting an RIC service query message to an E2 node. The method may include receiving an RIC service update message from the E2 node. The RIC service query message may include a message type, a transaction identifier (ID), and a list of RAN functions previously accepted by the Near-RT RIC. The list of RAN functions may include, for each RAN function, a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM).

[0150] For example, the list of RAN functions may further include RAN function definition information for each RAN function. The RAN function definition information may be used to provide the Near-RT RIC with the information necessary to support the corresponding RAN function in the E2 node. The RAN function OID may be used to identify the RAN function definition in the RAN function definition information.

[0151] For example, the RAN function OID may represent one of multiple service models. The multiple service models may include E2SM-NI (network interface), E2SM-KPM (key performance monitoring) version 1, E2SM-KPM version 2, E2SM-RC (radio control), and E2SM-CCC (cell configuration and control).

[0152] For example, the method may include transmitting a RIC service update confirmation message or a RIC service update failure message to the E2 node. The RIC service update message may include an additional list of RAN functions, a modified list of RAN functions, and / or a deleted list of RAN functions, if the RAN functions supported by the E2 node do not match the functions in the list. The RIC service update message may not include the additional list, the modified list, and the deleted list, if the RAN functions supported by the E2 node match the functions in the list.

[0153] For example, the method may include transmitting, to the E2 node, a second RIC service query message that does not include a list of RAN functions. The method may include receiving, from the E2 node, a second RIC service update message. The second RIC service update message may include a list of all RAN functions supported by the E2 node, in response to the second RIC service query message that does not include a list of RAN functions.

[0154] In embodiments, an electronic device of an E2 node is provided. The electronic device may include at least one processor and a memory storing instructions. The instructions, when executed by the at least one processor, may cause the E2 node to receive a RIC service query message from a Near-RT (real time) radio access network (RAN) intelligent controller (RIC) and, in response to the RIC service query message, transmit a RIC service update message to the Near-RT RIC. The RIC service query message may include a message type, a transaction identifier (ID), and a list of RAN functions previously accepted by the Near-RT RIC. The list of RAN functions may include, for each RAN function, a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM).

[0155] For example, the list of RAN functions may further include RAN function definition information for each RAN function. The RAN function definition information may be used to provide the Near-RT RIC with the information necessary to support the corresponding RAN function in the E2 node. The RAN function OID may be used to identify the RAN function definition in the RAN function definition information.

[0156] For example, the RAN function OID may represent one of multiple service models. The multiple service models may include E2SM-NI (network interface), E2SM-KPM (key performance monitoring) version 1, E2SM-KPM version 2, E2SM-RC (radio control), and E2SM-CCC (cell configuration and control).

[0157] For example, the instructions, when executed by the at least one processor, may cause the E2 node to receive a RIC service update confirmation message or a RIC service update failure message from the Near-RT RIC. The RIC service update message may include an additional list of RAN functions, a modified list of RAN functions, and / or a deleted list of RAN functions, if the RAN functions supported by the E2 node do not match the functions in the list. The RIC service update message may not include the additional list, the modified list, and the deleted list, if the RAN functions supported by the E2 node match the functions in the list.

[0158] For example, the instructions, when executed by the at least one processor, may cause the E2 node to receive, from the Near-RT RIC, a second RIC service query message that does not include a list of RAN capabilities, and to transmit a second RIC service update message to the Near-RT RIC. The second RIC service update message may include a list of all RAN capabilities supported by the E2 node, in response to the second RIC service query message that does not include a list of RAN capabilities.

[0159] In embodiments, an electronic device of a Near-RT (real time) RIC (radio access network (RAN) intelligent controller) is provided. The electronic device may include at least one processor and a memory storing instructions. The instructions, when executed by the at least one processor, may cause the Near-RT RIC to transmit a RIC service query message to an E2 node and to receive a RIC service update message from the E2 node. The RIC service query message may include a message type, a transaction identifier (ID), and a list of RAN functions previously accepted by the Near-RT RIC. The list of RAN functions may include, for each RAN function, a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM).

[0160] For example, the list of RAN functions may further include RAN function definition information for each RAN function. The RAN function definition information may be used to provide the Near-RT RIC with the information necessary to support the corresponding RAN function in the E2 node. The RAN function OID may be used to identify the RAN function definition in the RAN function definition information.

[0161] For example, the RAN function OID may represent one of multiple service models. The multiple service models may include E2SM-NI (network interface), E2SM-KPM (key performance monitoring) version 1, E2SM-KPM version 2, E2SM-RC (radio control), and E2SM-CCC (cell configuration and control).

[0162] For example, the instructions, when executed by the at least one processor, may cause the Near-RT RIC to send a RIC service update confirmation message or a RIC service update failure message to the E2 node. The RIC service update message may include an additional list of RAN functions, a modified list of RAN functions, and / or a deleted list of RAN functions, if the RAN functions supported by the E2 node do not match the functions in the list. The RIC service update message may not include the additional list, the modified list, and the deleted list, if the RAN functions supported by the E2 node match the functions in the list.

[0163] For example, the instructions, when executed by the at least one processor, may cause the Near-RT RIC to transmit a second RIC service query message to the E2 node that does not include a list of RAN capabilities, and to receive a second RIC service update message from the E2 node. The second RIC service update message may include a list of all RAN capabilities supported by the E2 node, in response to the second RIC service query message that does not include a list of RAN capabilities.

[0164] In embodiments, an electronic device of an E2 node is provided. The electronic device may include at least one transceiver and at least one processor. The at least one processor may be configured to receive a RIC service query message from a Near-RT (real time) radio access network (RAN) intelligent controller (RIC) through the at least one transceiver, and, in response to the RIC service query message, transmit a RIC service update message to the Near-RT RIC through the at least one transceiver. The RIC service query message may include a message type, a transaction identifier (ID), and a list of RAN functions previously accepted by the Near-RT RIC. The list of RAN functions may include, for each RAN function, a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM).

[0165] In embodiments, an electronic device of a Near-RT (real time) RIC (radio access network (RAN) intelligent controller) is provided. The electronic device may include at least one transceiver and at least one processor. The at least one processor may be configured to cause the Near-RT RIC to transmit a RIC service query message to an E2 node through the at least one transceiver and to receive a RIC service update message from the E2 node through the at least one transceiver. The RIC service query message may include a message type, a transaction identifier (ID), and a list of RAN functions previously accepted by the Near-RT RIC. The list of RAN functions may include, for each RAN function, a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM).

[0166] In embodiments, a non-transitory computer-readable storage medium is provided. The non-transitory computer-readable storage medium may include instructions that, when executed by a processor, cause an E2 node to perform operations including receiving a RIC service query message from a Near-RT (real time) radio access network (RAN) intelligent controller (RIC) and, in response to the RIC service query message, transmitting a RIC service update message to the Near-RT RIC. The RIC service query message may include a message type, a transaction identifier (ID), and a list of RAN functions previously accepted by the Near-RT RIC. The list of RAN functions may include, for each RAN function, a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a particular E2 service model (E2SM).

[0167] In embodiments, a non-transitory computer-readable storage medium is provided. The non-transitory computer-readable storage medium may include instructions that, when executed by a processor, cause a Near-RT (real time) RIC (radio access network (RAN) intelligent controller) to perform operations including transmitting a RIC service query message to an E2 node and receiving a RIC service update message from the E2 node. The RIC service query message may include a message type, a transaction identifier (ID), and a list of RAN functions previously accepted by the Near-RT RIC. The list of RAN functions may include, for each RAN function, a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a particular E2 service model (E2SM).

[0168] For one or more embodiments, at least one of the components described in one or more of the preceding drawings may be configured to perform one or more operations, techniques, processes, and / or methods as described herein. For example, a processor (e.g., a baseband processor) described herein with respect to one or more of the preceding drawings may be configured to operate according to one or more examples described herein. For another example, circuitry associated with a user equipment (UE), a base station, a network element, and the like, as described above with respect to one or more of the preceding drawings, may be configured to operate according to one or more examples described herein.

[0169] Any of the embodiments described above may be combined with any other embodiment (or combination of embodiments) unless explicitly stated otherwise. The foregoing description of one or more implementations provides examples and descriptions, but is not intended to be exhaustive or limit the scope of the embodiments to the precise forms disclosed. Modifications and variations are possible in light of the above teachings or may be learned from practicing various embodiments.

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

[0171] When implemented in software, a computer-readable storage medium (e.g., a non-transitory computer-readable storage medium) storing one or more programs (software modules) may be provided. The one or more programs stored in the computer-readable storage medium are configured for execution by one or more processors within an electronic device. The one or more programs include instructions that cause the electronic device to execute methods according to embodiments described in the claims or specification of the present disclosure. The one or more programs may be provided as a computer program product. The computer program product may be traded between a seller and a buyer as a commodity. The computer program product may be distributed in the form of a machine-readable storage medium (e.g., a compact disc read only memory (CD-ROM)), or may be distributed online (e.g., downloaded or uploaded) via an application store (e.g., Play Store™) or directly between two user devices (e.g., smart phones). In the case of online distribution, at least a portion of the computer program product may be temporarily stored or temporarily created in a device-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or an intermediary server.

[0172] These programs (software modules, software) may be stored in random access memory, non-volatile memory including flash memory, read only memory (ROM), electrically erasable programmable read only memory (EEPROM), magnetic disc storage devices, compact disc-ROM (CD-ROM), digital versatile discs (DVDs) or other forms of optical storage devices, magnetic cassettes, or may be stored in memories formed by a combination of some or all of these. In addition, each configuration memory may include multiple copies.

[0173] Additionally, the program may be stored on an attachable storage device that is accessible via a communication network, such as the Internet, an intranet, a local area network (LAN), a wide area network (WAN), a storage area network (SAN), or a combination thereof. Such a storage device may be connected to a device implementing an embodiment of the present disclosure via an external port. Additionally, a separate storage device on the communication network may be connected to a device implementing an embodiment of the present disclosure.

[0174] In the specific embodiments of the present disclosure described above, components included in the disclosure are expressed singularly or plurally, depending on the specific embodiment presented. However, the singular or plural expressions are selected to suit the presented situation for convenience of explanation, and the present disclosure is not limited to singular or plural components. Components expressed in plural may be composed of singular elements, or components expressed in singular may be composed of plural elements.

[0175] According to embodiments, one or more of the components or operations of the aforementioned components may be omitted, or one or more other components or operations may be added. Alternatively or additionally, a plurality of components (e.g., modules or programs) may be integrated into a single component. In such a case, the integrated component may perform one or more functions of each of the plurality of components identically or similarly to those performed by the corresponding component among the plurality of components prior to the integration. According to embodiments, the operations performed by a module, program, or other component may be executed sequentially, in parallel, iteratively, or heuristically, or one or more of the operations may be executed in a different order, omitted, or one or more other operations may be added.

[0176] Meanwhile, although the detailed description of the present disclosure has described specific embodiments, it is obvious that various modifications are possible within the scope of the present disclosure.

Claims

1. In the method performed by the E2 node, An operation of receiving a RIC service query message from a Near-RT (real time) RIC (RAN (radio access network) intelligent controller), In response to the RIC service query message, the operation of transmitting a RIC service update message to the Near-RT RIC is included. The RIC service query message includes a message type, a transaction ID (identifier), and a list of RAN functions previously accepted by the Near-RT RIC, The list of RAN functions includes, for each RAN function, a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM). method.

2. In claim 1, the list of RAN functions further includes RAN function definition information for each RAN function, The above RAN function definition information is used to provide the information necessary for the Near-RT RIC to support the corresponding RAN function in the E2 node, The above RAN function OID is used to identify the RAN function definition in the above RAN function definition information. method.

3. In claim 2, The above RAN function OID represents one of multiple service models, The above multiple service models include E2SM-NI (network interface), E2SM-KPM (key performance monitoring) version 1, E2SM-KPM version 2, E2SM-RC (radio control), and E2SM-CCC (cell configuration and control). method.

4. In claim 1, further comprising an operation of receiving a RIC service update confirmation message or a RIC service update failure message from the Near-RT RIC, The RIC service update message includes an additional list of RAN functions, a modified list of RAN functions, and / or a deleted list of RAN functions if the RAN functions supported by the E2 node do not match the functions in the list. The RIC service update message does not include the additional list, the modified list, and the deleted list, if the RAN functions supported by the E2 node match the functions in the list. method.

5. In claim 1, An operation of receiving a second RIC service query message that does not include a list of RAN functions from the Near-RT RIC; Further comprising the action of transmitting a second RIC service update message to the Near-RT RIC; The second RIC service update message includes a list of all RAN functions supported by the E2 node in response to the second RIC service query message that does not include a list of RAN functions. method.

6. In a method performed by a near-RT (real time) RIC (RAN (radio access network) intelligent controller), The action of sending a RIC service query message to the E2 node, Including an operation of receiving a RIC service update message from the E2 node, The RIC service query message includes a message type, a transaction ID (identifier), and a list of RAN functions previously accepted by the Near-RT RIC, The list of RAN functions includes, for each RAN function, a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM). method.

7. In claim 6, the list of RAN functions further includes, for each RAN function, RAN function definition information, The above RAN function definition information is used to provide the information necessary for the Near-RT RIC to support the corresponding RAN function in the E2 node, The above RAN function OID is used to identify the RAN function definition in the above RAN function definition information. method.

8. In claim 7, The above RAN function OID represents one of multiple service models, The above multiple service models include E2SM-NI (network interface), E2SM-KPM (key performance monitoring) version 1, E2SM-KPM version 2, E2SM-RC (radio control), and E2SM-CCC (cell configuration and control). method.

9. In claim 6, further comprising an action of transmitting a RIC service update confirmation message or a RIC service update failure message to the E2 node, The RIC service update message includes an additional list of RAN functions, a modified list of RAN functions, and / or a deleted list of RAN functions if the RAN functions supported by the E2 node do not match the functions in the list. The RIC service update message does not include the additional list, the modified list, and the deleted list, if the RAN functions supported by the E2 node match the functions in the list. method.

10. In claim 6, An operation of transmitting a second RIC service query message that does not include a list of RAN functions to the E2 node; Further comprising an operation of receiving a second RIC service update message from the E2 node; The second RIC service update message includes a list of all RAN functions supported by the E2 node in response to the second RIC service query message that does not include a list of RAN functions. method. In the electronic device of node 11.E2, at least one processor; and Contains memory that stores instructions, The above instructions, when executed by the at least one processor, cause the E2 node to: Receives a RIC service query message from a Near-RT (real time) RIC (RAN (radio access network) intelligent controller), In response to the RIC service query message, cause the Near-RT RIC to transmit a RIC service update message, The RIC service query message includes a message type, a transaction ID (identifier), and a list of RAN functions previously accepted by the Near-RT RIC, The list of RAN functions includes, for each RAN function, a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM). Electronic devices.

12. In claim 11, the list of RAN functions further includes, for each RAN function, RAN function definition information, The above RAN function definition information is used to provide the information necessary for the Near-RT RIC to support the corresponding RAN function in the E2 node, The above RAN function OID is used to identify the RAN function definition in the above RAN function definition information. Electronic devices.

13. In claim 12, The above RAN function OID represents one of multiple service models, The above multiple service models include E2SM-NI (network interface), E2SM-KPM (key performance monitoring) version 1, E2SM-KPM version 2, E2SM-RC (radio control), and E2SM-CCC (cell configuration and control). Electronic devices.

14. In claim 11, The instructions, when executed by the at least one processor, cause the E2 node to receive a RIC service update confirmation message or a RIC service update failure message from the Near-RT RIC; The RIC service update message includes an additional list of RAN functions, a modified list of RAN functions, and / or a deleted list of RAN functions if the RAN functions supported by the E2 node do not match the functions in the list. The RIC service update message does not include the additional list, the modified list, and the deleted list, if the RAN functions supported by the E2 node match the functions in the list. Electronic devices.

15. In the electronic device of Near-RT(real time) RIC(RAN(radio access network) intelligent controller), at least one processor; and Contains memory that stores instructions, The above instructions, when executed by the at least one processor, cause the Near-RT RIC to: Send a RIC service query message to the E2 node, Causes to receive a RIC service update message from the above E2 node, The RIC service query message includes a message type, a transaction ID (identifier), and a list of RAN functions previously accepted by the Near-RT RIC, The list of RAN functions includes, for each RAN function, a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM). Electronic devices.

Images