Electronic device and method for RIC service query

Abstract

According to an embodiment, a method performed by an E2 node is provided. The method can include operations for receiving, from a near real-time (RT) intelligent controller (RIC), a radio access network (RAN) RIC service query message. The method can include operations for sending, to the Near-RT RIC, a RIC service update message in response to the RIC service query message. The RIC service query message can include a message type, a transaction identifier (ID), and a list of RAN functions previously accepted by the Near-RT RIC. For each RAN function, the list of RAN functions can include a RAN function ID, a RAN function revision version, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM).

Description

Technical Field

[0001] The following description relates to an electronic device and method for querying services of a Radio Access Network (RAN) Intelligent Controller (RIC). Background Technology

[0002] To meet the growing demand for wireless data services following the commercialization of 4G (fourth generation) communication systems, efforts have been made to develop improved 5G (fifth generation) communication systems or pre-5G communication systems. For this reason, 5G or pre-5G communication systems are referred to as beyond 4G network communication systems or post-Long Term Evolution (LTE) systems.

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

[0004] In addition, to enhance network performance, 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, mobile networks, cooperative communication, coordinated multipoint (CoMP), and interference cancellation are being developed for 5G communication systems.

[0005] In addition, advanced coding and modulation (ACM) technologies, such as hybrid frequency shift keying and orthogonal amplitude modulation (FQAM) and sliding window superposition coding (SWSC), are being developed in 5G systems, as well as advanced access technologies, such as filter bank multicarrier (FBMC), non-orthogonal multiple access (NOMA) and sparse code multiple access (SCMA).

[0006] With the commercialization of 5G systems and new or next-generation radios (NR) to meet the demand for wireless data services, high data rate services are being offered to users through 5G systems similar to 4G, and a variety of wireless communication services are expected to be available, including Internet of Things (IoT) and services requiring high reliability for specific purposes. In the current system, which is a hybrid of fourth-generation and fifth-generation communication systems, the Open Radio Access Network (O-RAN) established by operators and equipment providers defines the E2 Application Protocol (E2AP) standard in the application protocol of the E2 interface between E2 nodes and Near-Real-Time Radio Access Network (RAN) Intelligent Controllers (RICs).

[0007] Looking back at the development of generations of wireless communication, technologies primarily designed for human-facing services, such as voice, multimedia, and data, have been developed. Following the commercialization of fifth-generation (5G) communication systems, an explosive increase in the number of connected devices is anticipated. Examples of objects connected to the network include vehicles, robots, drones, home appliances, displays, smart sensors installed in various infrastructures, construction machinery, and factory equipment. Mobile devices are expected to evolve into various form factors, such as augmented reality glasses, virtual reality headsets, and holographic devices. In sixth generation (6G), efforts are underway to develop improved 6G communication systems to connect billions of devices and objects and provide a wide range of services. For this purpose, 6G communication systems are referred to as "beyond 5G" systems.

[0008] In the 6th generation (6G) communication system, which is expected to be realized around 2030, the maximum transmission speed is terabit per second (bps), and the wireless latency is 100 microseconds (μsec). That is to say, compared with the 5G communication system, the transmission speed of the 6G communication system is 50 times faster, and the wireless latency is reduced to one-tenth.

[0009] To achieve such high data transmission speeds and ultra-low latency, the implementation of 6G communication systems in the terahertz (THz) band (e.g., 95 GHz to 3 THz) is being considered. Due to more severe path loss and atmospheric absorption compared to the millimeter-wave (mmWave) band introduced in 5G, the terahertz band is expected to be of greater importance for technologies ensuring signal reach distance (i.e., coverage). As a key technology for ensuring coverage, various antenna transmission technologies need to be developed, such as radio frequency (RF) components, antennas, and new waveforms that outperform orthogonal frequency division multiplexing (OFDM) in terms of coverage, beamforming, massive MIMO, full-dimensional MIMO (FD-MIMO), array antennas, and massive MIMO. Furthermore, to improve the coverage of terahertz band signals, new technologies such as metamaterial-based lenses and antennas, high-dimensional spatial multiplexing using orbital angular momentum (OAM), and reconfigurable smart surfaces (RIS) are being discussed.

[0010] To improve frequency efficiency and enhance system networks, 6G communication systems are developing technologies such as: full-duplex technology, which enables uplink and downlink to utilize the same frequency resources simultaneously; network technologies that integrate satellite and High Altitude Platform Stations (HAPS); innovative network architecture technologies that support mobile base stations and enable network operation optimization and automation; dynamic spectrum sharing technologies that achieve conflict avoidance based on spectrum usage prediction; artificial intelligence (AI)-based communication technologies that internalize end-to-end AI support functions and leverage AI from the design phase to achieve system optimization; and next-generation distributed computing technologies that utilize ultra-high-performance communication and computing resources (e.g., mobile edge computing (MEC), cloud, etc.) to enable services with complexity exceeding the limitations of terminal computing capabilities. Furthermore, ongoing efforts are underway to enhance connectivity between devices, further optimize networks, promote the software-defined networking of network entities, and increase the openness of wireless communication by designing new protocols for use in 6G communication systems, implementing hardware-based secure environments, developing mechanisms for secure data utilization, and developing technologies for maintaining privacy.

[0011] Thanks to the research and development of 6G communication systems, the next hyper-connected experience is expected to be made possible by the hyper-connectivity of 6G communication systems, encompassing not only interconnections between objects but also connections between humans and objects. Specifically, 6G communication systems are expected to provide 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 will be provided through 6G communication systems with enhanced security and reliability, applicable to various fields such as industry, healthcare, automotive, and home appliances.

[0012] In 6G communication systems, the functions of the RAN are expected to be further subdivided and divided into service subscriber and service provider models. In service-based networks, the subscription service confirmation process based on service subscription status will be applied to various functions. Summary of the Invention

[0013] Technical solution In one embodiment, a method performed by an E2 node is provided. This method may include receiving a RIC service query message from a Near-RT Radio Access Network (RAN) Intelligent Controller (Near-RT RIC). The method may also include sending 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 a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM) for each RAN function.

[0014] In one embodiment, a method is provided performed by a Near-Real-Time (RT) Radio Access Network (RAN) Intelligent Controller (Near-RT RIC). The method may include sending an RIC service query message to an E2 node. The method may also include receiving an RIC service update message from an 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 a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM) for each RAN function.

[0015] In one embodiment, an electronic device for an E2 node is provided. The electronic device may include at least one processor and a memory storing instructions. When executed by the at least one processor, the instructions enable the E2 node to receive RIC service query messages from a Near-Real-Time (RT) Radio Access Network (RAN) Intelligent Controller (Near-RT RIC) and, in response to the RIC service query messages, to send RIC service update messages 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 a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM) for each RAN function.

[0016] In one embodiment, an electronic device for a near-real-time (RT) radio access network (RAN) intelligent controller (Near-RTRIC) is provided. The electronic device may include at least one processor and a memory storing instructions. When executed by the at least one processor, the instructions enable the Near-RT RIC to send RIC service query messages to E2 nodes and receive RIC service update messages from E2 nodes. 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 a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM) for each RAN function.

[0017] In one embodiment, an electronic device for an E2 node is provided. This electronic device may include at least one transceiver and at least one processor. The at least one processor may be configured to: receive RIC service query messages from a Near-Real-Time (RT) Radio Access Network (RAN) Intelligent Controller (Near-RT RIC) via the at least one transceiver; and, in response to the RIC service query messages, send RIC service update messages to the Near-RT RIC via 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 a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM) for each RAN function.

[0018] In one embodiment, an electronic device for a near-real-time (RT) radio access network (RAN) intelligent controller (Near-RTRIC) is provided. This electronic device may include at least one transceiver and at least one processor. The at least one processor may be configured to enable the Near-RT RIC to send RIC service query messages to E2 nodes via the at least one transceiver, and to receive RIC service update messages from E2 nodes via 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 a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM) for each RAN function.

[0019] In this embodiment, 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 an RIC service query message from a Near-Real-Time (RT) Radio Access Network (RAN) Intelligent Controller (Near-RT RIC) and, in response to the RIC service query message, sending an 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 a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM) for each RAN function.

[0020] In this embodiment, 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-Real-Time (RT) Radio Access Network (RAN) Intelligent Controller (Near-RT RIC) to perform operations including sending RIC service query messages to E2 nodes and receiving RIC service update messages from E2 nodes. 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 a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM) for each RAN function. Attached Figure Description

[0021] Figure 1 An example of the core network of a fourth-generation (4G) Long Term Evolution (LTE) communication system is shown.

[0022] Figure 2 An example of the core network of a fifth-generation (5G) communication system is shown.

[0023] Figure 3 An example of an architecture for O-RAN is shown.

[0024] Figure 4a An example of the connection between an E2 node and a Radio Access Network Intelligent Controller (RIC) in a 5G communication system is shown.

[0025] Figure 4b The protocol stack of E2 application protocol messages is shown.

[0026] Figure 5 The configuration of electronic devices in a radio access network is shown.

[0027] Figure 6 The logical functions related to E2 nodes and E2 messages of RIC in the radio access network are shown.

[0028] Figure 7 An example of functional splitting between E2 nodes and RIC is shown.

[0029] Figure 8 An implementation example of E2 nodes and RIC is shown.

[0030] Figure 9 An example of functional splitting between the Central Unit (CU) and the RIC is shown.

[0031] Figure 10 An example of the RAN functions for each E2 node is shown.

[0032] Figure 11a and Figure 11b The signal flow used for the RIC service update process is shown.

[0033] Figure 12 An example of resolving a bug in Near-RT RIC via the RIC service update process is shown. Detailed Implementation

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

[0035] In the various embodiments of this disclosure described below, hardware methods will be described as examples. However, since the various embodiments of this disclosure include techniques using both hardware and software, software-based methods are not excluded.

[0036] For ease of description, terms referring to signals (e.g., signals, information, messages, signaling), terms referring to data types (e.g., lists, sets, subsets), terms for operational states (e.g., steps, operations, procedures), terms referring to data (e.g., packets, user streams, information, bits, symbols, codewords), terms referring to resources (e.g., symbols, time slots, subframes, radio frames, subcarriers, resource elements (REs), resource blocks (RBs), bandwidth portions (BWPs), timings), terms referring to channels, terms referring to network entities, terms referring to components of equipment, etc., are illustrated. Therefore, this disclosure is not limited to the terms described below, and other terms with equivalent technical meanings may be used.

[0037] In the following description, the following terms refer to configuration (e.g., setup, setting, arrangement, control), signals (e.g., packets, messages, signals, information, signaling), resources (e.g., segments, symbols, time slots, subframes, radio frames, subcarriers, resource elements (REs), resource blocks (RBs), bandwidth portions (BWPs), timing), operational states (e.g., steps, operations, procedures), data (e.g., packets, messages, user streams, information, bits, symbols, codewords), channels, and network entities (e.g., Distributed Unit (DU), Radio Unit (RU), Central Unit (CU), CU Control Plane (CP), CU User Plane (UP), Open Radio Access Network (O-RAN) DU (O-DU), O-RAN RU (O-RU), O-RAN CU (O-CU), O-RAN CU-CP (O-CU-UP), O-RAN... The terms CU-CP (O-CU-CP) and the terms referring to components of the equipment are illustrative for ease of description. Therefore, this disclosure is not limited to the terms described below, and other terms with equivalent technical meanings may be used. Furthermore, terms such as “…unit,” “…equipment,” “…object,” and “…structure” used below may refer to at least one shape structure or a unit with processing functions.

[0038] Furthermore, in this disclosure, the terms "greater than" or "less than" can be used to determine whether a specific condition is met or satisfied, but this is merely a description of examples and does not exclude descriptions of "greater than or equal to" or "less than or equal to". A condition described as "greater than or equal to" can be replaced by "greater than", a condition described as "less than or equal to" can be replaced by "less than", and a condition described as "greater than or equal to and less than" can be replaced by "greater than and less than or equal to". Additionally, in the following text, "A" to "B" refers to at least one of the elements from A (inclusive) to B (inclusive). In the following text, "C" and / or "D" means including at least one of "C" or "D", i.e., {"C", "D" and "C and "D"}.

[0039] This disclosure uses terminology used in some communication standards (e.g., 3GPP, ETSI, xRAN, and ORAN) to describe various embodiments, but these are merely examples for illustrative purposes. The various embodiments of this disclosure can be readily modified and applied to other communication systems.

[0040] As 4G / 5G communication systems (e.g., New Radio (NR)) have been commercialized, differentiated service support for users in virtualized networks is needed. 3GPP is a joint research project among mobile communications-related organizations aimed at developing standards for third-generation mobile communication systems applicable globally within the framework of the International Telecommunication Union (ITU) IMT-2000 project. Established in December 1998, 3GPP standards are based on the Advanced GSM standard and encompass all radio, core network, and service architectures within the scope of standardization. Therefore, Open Radio Access Network (O-RAN) newly defines 3GPP Network Entities (NEs) and Radio Units (RUs), Digital Units (DUs), Central Units (CUs), Control Planes (CPs), and CU User Planes (UPs). These are nodes that configure base stations as O(O-RAN)-RU, O-DU, O-CU-CP, and O-CU-UP nodes, respectively, and also standardizes the Near Real-Time (NRT) Radio Access Network Intelligent Controller (RIC). This disclosure is used to support operator-specific service models in an E2 interface, where the RIC requests services from an O-DU, O-CU-CP, or O-CU-UP. Here, O-RU, O-DU, O-CU-CP, and O-CU-UP can be understood as entities that configure a RAN that can operate according to the O-RAN standard, and can be referred to as E2 nodes. The interface between the RIC and the E2 node, which has an entity configuring the RAN (which can operate according to the O-RAN standard), uses the Application Protocol (E2AP).

[0041] A RIC is a logical node capable of collecting RAN-related information. For example, RAN-related information may include information related to cell sites where terminals and E2 nodes (e.g., O-DU, O-CU-CP, or O-CU-UP) transmit and receive data. The RIC can be implemented as a server centrally located in a physical location. For example, it can be connected via Ethernet between O-DU and RIC, O-CU-CP and RIC, and O-CU-UP and RIC. Therefore, interface standards for communication between O-DU and RIC, O-CU-CP and RIC, and O-CU-UP and RIC have become necessary, and definitions of messaging standards such as E2-DU, E2-CU-CP, and E2-CU-UP, as well as procedures between O-DU, O-CU-CP, and O-CU-UP and RIC, are required. In particular, differentiated service support for users in virtualized networks is needed. By centralizing call processing messages / functions generated in the O-RAN onto the RIC, functional definitions for E2-DU, E2-CU-CP, and E2-CU-UP messages are required to support services for wide cell coverage.

[0042] RICs can use the E2 interface to communicate with E2 nodes (e.g., O-DU, O-CU-CP, and / or O-CU-UP). For example, an RIC can set event conditions through a subscription procedure with an E2 node. An EIC can set up call processing events by generating a subscription request message and passing it to the E2 node. After the call processing event is set up, the E2 node can deliver a subscription response message to the RIC. E2 nodes can establish services provided by the Near-RT RIC. For example, an E2 node can send RIC instruction messages (e.g., reporting information) to the RIC based on the subscription procedure. An RIC can also use RIC control messages to provide control over E2 nodes (e.g., O-DU, O-CU-CP, or O-CU-UP).

[0043] Figure 1 An example of the core network of a 4G (4G) Long Term Evolution (LTE) communication system is shown.

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

[0045] Base station 110 is the network infrastructure that provides wireless access to terminal 120. For example, 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 terminal 120. Base station 110 has coverage defined as a geographical area based on the distance at which signals can be transmitted. Base station 110 is connected to MME 150 via an S1-MME interface. Besides "base station," base station 110 may be referred to as an "access point (AP)," "eNodeB (eNB)," "radio point," "transmit / receive point (TRP)," "RAN node," or another term with equivalent technical meaning.

[0046] Terminal 120 is a device used by a user and performs communication with base station 110 via a wireless channel. In some cases, terminal 120 can operate without user intervention. That is, terminal 120 is a device that performs machine-type communication (MTC) and can be carried by no user. Besides "terminal," terminal 120 may be referred to as "user equipment (UE)," "mobile station," "subscriber station," "customer premises equipment (CPE)," "remote terminal," "wireless terminal," "user equipment," or another term with equivalent technical meaning.

[0047] S-GW 130 provides data bearers and generates or controls data bearers according to the control of MME 150. For example, S-GW 130 processes packets arriving from or to base station 110. Furthermore, S-GW 130 can perform an anchoring role during handover of terminal 120 between base stations. P-GW 140 can be used as a connection point to external networks (e.g., the Internet). Furthermore, P-GW 140 assigns Internet Protocol (IP) addresses to terminal 120 and performs the anchoring role of S-GW 130. Additionally, P-GW 140 can apply Quality of Service (QoS) policies to terminal 120 and manage account data.

[0048] The MME 150 manages the mobility of the terminal 120. Furthermore, the MME 150 can perform authentication, bearer management, and other functions for the terminal 120. In other words, the MME 150 is responsible for the terminal's mobility management and various control functions. The MME 150 can link with a Serving GPRS Support Node (SGSN).

[0049] HSS 160 stores key information and subscriber profiles used for authentication of terminal 120. When terminal 120 accesses the network, the key information and subscriber profiles are transmitted from HSS 160 to MME 150.

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

[0051] Figure 2 An example of the core network of a 5G communication system is shown.

[0052] refer to Figure 2 A 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, refer to the... Figure 1 The description of terminal 120 is provided below. For base station 203, refer to the description of base station 110. Base station 203 can be connected to AMF 211 via the N2 interface and to UPF 231 via the N3 interface. Besides "base station," base station 203 may be referred to as an "access point (AP)," "radio access network (RAN) node," "fifth-generation (5G) node," "next-generation node B (gNB)," "radio point," "transmit / receive point (TRP)," "communication node," "wireless communication device," "wireless communication equipment," "network node," "network entity," or another term with equivalent technical meaning. AMF 211 can provide functions related to mobility management, user registration, authentication, connection establishment, and / or release for terminal 201. SMF 221 can manage the session and quality of service (e.g., QoS) of terminal 120 in the user plane and uses the GPT tunnel between UPF 231 and base station 203 to generate and manage PDU session tunnels. The UPF 231 can perform the role of processing and routing user data packets, and provide appropriate processing as needed by classifying and prioritizing traffic. Furthermore, the UPF 231 can send packets over the Internet by connecting to a data network 260.

[0053] The network between terminal 201 and base station 203 can be referred to as the access network or RAN. A group of network entities connected to base station 203 can be referred to as the 5G core network. In addition to AMF 211, SMF 221, and UPF 223, the 5G core network can also include various network functions (NFs). For example, the 5G core network can include Network Slice Selection Function (NSSF) 241, Network Open Function (NEF) 242, Network Repository Function (NRF) 243, Policy Control Function (PCF) 244, Unified Data Management (UDM) 245, Application Function (AF) 246, Authentication Server Function (AUSF) 247, and / or Service Capability Open Function (SCP) 248. NSSF 241 can provide the selection of network slices suitable for users (e.g., terminal 201). NEF 242 can provide services by allowing service providers access to network resources and network functions. NRF 243 can perform the role of a database capable of searching and finding services and functions within the network. PCF 244 can manage and control quality of service and policies within the network. UDM 245 can manage and provide user profiles and subscription information. AF 246 can manage network access and resource allocation for specific services or applications. AUSF 247 can manage user authentication information and perform the authentication process. SCP 248 can expose network service functions to external applications and support service provision.

[0054] A base station (e.g., base station 203) can be implemented in a distributed deployment, based on a central unit (CU) (or control unit) configured to perform upper-layer functions of the access network (e.g., Packet Data Convergence Protocol (PDCP) and Radio Resource Control (RRC)) and distributed units (DUs) configured to perform lower-layer functions. For example, between a core network (e.g., a 5G core (5GC) or Next Generation Core (NGC)) and a radio network (RAN), the base station can be implemented in a structure where CUs and DUs are arranged sequentially (or CUs, DUs, and RUs are arranged sequentially). The interface between the CU and DU can be referred to as an F1 interface. A CU can be responsible for functions at layers higher than the DU by connecting to one or more DUs. For example, a CU can be responsible for functions at the Radio Resource Control (RRC) layer and the Packet Data Convergence Protocol (PDCP) layer, and a DU (or DU and RU) can be responsible for functions at lower layers. DUs can perform functions at the Radio Link Control (RLC) layer, the Media Access Control (MAC) layer, and the Physical (PHY) layer. As a non-limiting example, if the DU is connected to the radio unit (RU), the DU can perform some of the functions of the physical layer (high PHY), and the RU can be responsible for the remaining functions of the PHY layer (low PHY).

[0055] Carrier aggregation (hereinafter referred to as "CA") is a technique used to improve frequency utilization efficiency from the perspective of a terminal or base station by combining multiple component carriers and having a single terminal simultaneously use these component carriers to transmit and receive signals. Specifically, according to CA, a terminal (e.g., terminal 120 or terminal 201) and a base station (e.g., base station 110 or base station 203) can use multiple component carriers in the uplink (UL) and downlink (DL) respectively to transmit and receive signals over a wide bandwidth, with each component carrier located in a different frequency band. In the following text, the uplink refers to the communication link through which the terminal transmits signals to the base station, and the downlink refers to the communication link through which the base station transmits signals to the terminal. The number of uplink component carriers and the number of downlink component carriers can be different from each other.

[0056] From the perspective of a terminal or base station, dual connectivity or multi-connectivity technology is a technique used to improve frequency utilization efficiency by connecting a terminal to multiple different base stations and simultaneously using carriers in each of the multiple base stations located in different frequency bands to transmit and receive signals. A terminal can transmit and receive services by simultaneously connecting to a first base station (e.g., a base station providing services using LTE or fourth-generation mobile communication technology) (e.g., base station 110) and a second base station (e.g., a base station providing services using new radio (NR) or fifth-generation (5G) mobile communication technology) (e.g., base station 203). In this case, the frequency resources used by each base station can be located in different frequency bands. For example, a scheme operating on a dual connectivity basis of LTE and NR based on an LTE core network (e.g., Evolved Packet Core (EPC)) can be referred to as 5G Non-Standalone (NSA). For example, in a 5G communication system, a scheme operating on a 5G core network using 5G technology (or LTE and 5G technologies) can be referred to as 5G Standalone (SA).

[0057] Currently, discussions are underway regarding improvements and performance enhancements to the initial 5G mobile communication technology, considering the services that 5G mobile communication technology aims to support. Physical layer standardization is also underway, including Vehicle-to-Everything (V2X) for assisting autonomous vehicle driving by determining and increasing user convenience based on the vehicle's own location and status information; New Radio Unlicensed (NR-U) for system operation aimed at meeting various regulatory requirements in unlicensed frequency bands; NR terminal low-power technology (UE power saving); non-terrestrial networks (NTN) for direct terminal satellite communication to ensure coverage in areas where communication with terrestrial networks is not possible; and positioning.

[0058] In addition, standardization is underway in the radio interface architecture / protocol fields for the following technologies: such as smart factories (Industrial Internet of Things (IIoT)) to support new services through links and integration with another industry; Integrated Access and Backhaul (IAB) for nodes to provide extended network service areas by integrating support for wireless backhaul links and access links; mobility enhancement technologies (mobility enhancement) including conditional handover and dual active protocol stack (DAPS) handover; and two-step random access (two-step RACH for NR) to simplify the random access process. Standardization is also underway in the system architecture / service fields for the following: 5G baseline architectures (e.g., service-based architectures and service-based interfaces) for applying Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies; Mobile Edge Computing (MEC) that provides services based on the location of the terminal.

[0059] When 5G mobile communication systems are commercialized, the ever-growing number of connected devices will connect to the communication network. Therefore, it is expected that enhancements to the functionality and performance of 5G mobile communication systems, as well as the integrated operation of connected devices, will be necessary. To this end, new research will be conducted on extended reality (XR) to effectively support augmented reality (AR), virtual reality (VR), mixed reality (MR), etc., using artificial intelligence (AI) and machine learning (ML), AI service support, virtual reality service support, drone communication, etc., to improve 5G performance and reduce complexity.

[0060] Furthermore, this development of 5G mobile communication systems can serve as a foundation for the development of: new waveforms to ensure coverage in the terahertz band of 6G mobile communication technology; various antenna transmission technologies, such as full-dimensional MIMO (FD-MIMO), array antennas, and massive MIMO; metamaterial-based lenses and antennas to improve the coverage of terahertz band signals; high-dimensional spatial multiplexing technologies using orbital angular momentum (OAM) and reconfigurable smart surface (RIS) technologies; and full-duplex technologies to improve the frequency efficiency and system network of 6G mobile communication technology; AI-based communication technologies for system optimization by leveraging satellite and artificial intelligence (AI) from the design phase and internalizing end-to-end AI support capabilities; and next-generation distributed computing technologies for enabling services with complexity exceeding the limitations of terminal computing capabilities by utilizing ultra-high-performance communication and computing resources.

[0061] although Figures 1 to 2 Examples have been described in 4G and / or 5G environments, but these descriptions do not limit the scope of the communication environments described in the embodiments of this disclosure. The technical principles of the embodiments of this disclosure can also be applied to 6G and beyond communication technologies and network environments.

[0062] Figure 3 An example of an architecture for O-RAN is shown.

[0063] refer to Figure 3 The logical architecture of O-RAN can include Service Management Orchestration (SMO) 300, O-eNB 305, O-RU 310, O-DU 320, O-CU-CP 331, O-CU-UP 332, Near-RT RIC 340 and Non-RT RIC 350.

[0064] The SMO 300 can handle RAN management across various management domains within a service provider's network, including RAN management, core management, transport management, and end-to-end (E2E) slice management. For RAN management, the SMO 300 can utilize the Non-RTRIC 350 to provide Fault, Configuration, Billing, Performance, and Security (FCAPS) interfaces, as well as RAN optimization.

[0065] The O-eNB 305 can be a node that provides network access in an LTE communication system. For details on the O-eNB 305, please refer to... Figure 1 The description of base station 110. O-RU 310, O-DU 320, O-CU-CP 331, and O-CU-UP 332 can be network entities (or nodes) used to provide access to the network in an NR communication system. For O-RU 310, O-DU 320, O-CU-CP 331, and O-CU-UP 332, please refer to... Figure 2 Description of base station 203.

[0066] The Near-RT RIC 340 is a logical node used to customize RAN functionality for new services or regional resource optimization. The Near-RT RIC 340 can provide functions such as network intelligence (e.g., policy enforcement and handover optimization), resource guarantees (e.g., radio link management and advanced ad hoc networks (SON)), and resource control (e.g., load balancing and slicing policies). The Near-RT RIC 340 can connect to O-eNB 305, O-CU-CP 331, O-CU-UP 332, and / or O-DU 320. The Near-RT RIC 340 can perform communication with the O-eNB 305, O-CU-CP 331, O-CU-UP 332, and / or O-DU 320. The RIC 340 can connect to each node via an E2 interface. Furthermore, the interface between the O-CU-CP 331 and the O-DU 320 can be referred to as the F1-c interface. The interface between O-CU-UP 332 and O-DU 320 can be referred to as the F1-u interface. In the following description, DU and O-DU, CU-CP and O-CU-CP, and CU-UP and O-CU-UP can be used interchangeably.

[0067] The Non-RT RIC 350 can communicate with the Near-RT RIC340 via the A1 interface, which can be implemented in the SMO 300. Through the A1 interface, policy management services, rich information services, and machine learning (ML) model management services can be provided. 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 meets the O-RAN requirements for hosting related O-RAN functions (e.g., Near-RT RIC 340, O-CU-CP 331, O-CU-UP 332, and O-DU320), supporting software components (e.g., operating system, virtual machine monitor, container runtime, etc.), and / or appropriate management and orchestration functions.

[0069] exist Figure 3 In the diagram, O-CU-CP 331 and O-CU-UP 332 are shown respectively according to the separation of the control plane and the user plane; however, the embodiments of this disclosure are not limited thereto. As a non-limiting example, O-CU-CP 331 and O-CU-UP 332 can be understood as a single O-CU 330. Furthermore, Figure 3A Near-RT RIC 340 is shown, but according to various embodiments, multiple Near-RT RICs can exist for an O-RAN architecture. Multiple Near-RT RICs can be implemented as multiple hardware units located in the same physical location, or they can be implemented using a single hardware unit via virtualization.

[0070] Figure 4a An example of the connection between an E2 node and a Radio Access Network Intelligent Controller (RIC) in a 5G communication system is shown.

[0071] refer to Figure 4a 5G communication systems can provide entity deployments in either non-standalone (NSA) or standalone (SA) modes. Network entities configuring base stations (e.g., base station 110 or base station 203) can be referred to as E2 nodes, and each network entity can have a deployment according to either non-standalone or standalone modes. For example, in non-standalone mode, dual connectivity using an eNB and an E2 node can be provided to terminals. Such dual connectivity using LTE and NR can be referred to as Evolved Universal Terrestrial Radio Access (E-UTRA)-NR Dual Connectivity (EN-DC). The CU-CP, CU-UP, and DU used for gNB operation can be referred to as O-CU-CP 331, O-CU-UP 332, and O-DU 320, respectively, by connecting to the Near-RT RIC (e.g., Near-RT RIC 340) in the O-RAN architecture. For example, in standalone mode, an E2 node can connect independently to the 5GC. In the O-RAN architecture, E2 nodes can be referred to as O-CU-CP 331, O-CU-UP 332, and / or O-DU 320. O-CU-CP 331 can be connected to the AMF (e.g., AMF211) in the 5GC via the N2 interface. O-CU-UP 332 can be connected to the UPF (e.g., UPF 231) in the 5GC via the N3 interface.

[0072] Figure 4b The protocol stack of E2 application protocol messages is shown.

[0073] refer to Figure 4b The control plane includes the transport network layer and the radio network layer. The transport network layer includes the physical layer 410, the data link layer 420, the Internet Protocol (IP) 430, and the Flow Control Transmission Protocol (SCTP) 440.

[0074] The radio 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 at higher layers such as SCTP 440 and IP 430.

[0075] Figure 5 The configuration of electronic devices in a radio access network is shown. Figure 5 The structure shown can be understood as having Figure 3 The configuration of an electronic device showing the functions of at least one of Near-RT RIC 340, Non-RT RIC 350, O-CU-CP 331, O-CU-UP 332, O-DU 320 and / or O-eNB 305. Terms such as “…unit” and “…device” as used below refer to a unit that processes at least one function or operation and can be implemented as hardware or software, or a combination of hardware and software.

[0076] refer to Figure 5 The electronic device may include a transceiver 510, a memory 520, and a processor 530.

[0077] Transceiver 510 provides an interface for performing communication with other electronic devices in a network. That is, transceiver 510 converts a bit stream sent from one electronic device to another into a physical signal, and converts a physical signal received from another electronic device back into a bit stream. In other words, transceiver 510 can both send and receive signals. Therefore, transceiver 510 can be referred to as a modem, communication unit, transmitting unit, receiving unit, or transmit / receive unit. In this case, transceiver 510 enables electronic devices to communicate with other electronic devices or systems via backhaul connections (e.g., wired or wireless backhaul) or over a network. Transceiver 510 may include one or more transceivers.

[0078] Memory 520 stores data such as basic programs, application programs, and setting information for the operation of the electronic device. Memory 520 can be configured as volatile memory, non-volatile memory, or a combination of volatile and non-volatile memory. Furthermore, memory 520 provides stored data according to requests from processor 530. Memory 520 can be referred to as a storage unit.

[0079] Processor 530 controls the overall operation of the electronic device. For example, processor 530 sends and receives signals via transceiver 510. Additionally, processor 530 records data in memory 520 and reads data from memory 520. Processor 530 may be referred to as a controller. For this purpose, processor 530 may be configured with multiple processors, or may include at least one subprocessor. According to various embodiments, processor 530 can control the electronic device to perform operations according to the various embodiments described in this disclosure.

[0080] Figure 6 The logical functions related to E2 nodes and E2 messages of RIC in the radio access network are shown.

[0081] refer to Figure 6 RIC 640 and E2 node 610 can send or receive E2 messages to each other. For example, E2 node 610 can be an O-eNB 305, O-CU-CP 331, O-CU-UP 332, O-DU 320, or a base station (e.g., base station 101 or base station 203). The communication interface of E2 node 620 can be determined according to the type of E2 node 610. For example, E2 node 610 can communicate with another E2 node 616 through an E1 interface or an F1 interface. Alternatively, for example, E2 node 610 can communicate with another E2 node 616 through an X2 interface or an XN interface. Alternatively, for example, E2 node 610 can communicate with core network entities through an S1 interface or a Next Generation Application Protocol (NGAP) interface (e.g., the interface between Next Generation (NG) base station 203 and AMF 211).

[0082] E2 node 610 may include E2 node function 612. E2 node function 612 is a function corresponding to a specific application S / W (xApp) 646 installed in RIC 640. For example, in the case of a KPI monitor, a KPI monitor set S / W is installed in RIC 640, and E2 node 610 may include E2 node function 612, which generates KPI parameters and then transmits an E2 message including the KPI parameters to E2 terminal 642 located in RIC 640. E2 node 610 may include Radio Resource Management (RRM) 614. E2 node 610 can manage the resources provided to the radio network for terminals.

[0083] The E2 terminal 642 located in RIC 640 (which is the terminal of RIC 640 for E2 messages) performs the function of interpreting the E2 messages delivered by E2 node 610 and then delivering the E2 messages to xApp 646. The database (DB) 644 located in RIC 640 can be used for E2 termination 624 or xApp 646.

[0084] Figure 7 An example of functional splitting 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 or base station 203) and a RIC is shown. RAN standards can provide functional splitting between E2 nodes and RICs. For example, an E2 node can be a CU (e.g., CU 330, CU-CP 331, or CU-UP 332). The RIC can be a Near-RT RIC 340. The Near-RT RIC 340 can 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 can be connected to a Non-RT RIC 350 of the SMO 300. The RIC can be connected to the E2 node via an E2 interface. Possible functional splitting options may include those for the Near-RT RIC. The functional breakdown 700 of managing the entire Radio Resource Management (RRM) in 340 and the functional breakdown 750 of selectively managing the RRM in Near-RT RIC 340.

[0085] Figure 8 An implementation example of E2 nodes and RICs is shown. In the scenario of implementation example 800, E2 nodes (e.g., O-eNB 305, O-DU 320, O-CU 330, O-CU-CP 331, or O-CU-UP 332) and RICs (e.g., Near-RTRIC 340) can be configured in devices (e.g., servers) via virtualization in a cloud platform (e.g., open chassis and blade specification edge cloud). This scenario can provide sufficiently low latency to meet O-DU latency requirements. This scenario can support deployment in dense urban areas with abundant fronthaul capacity, allowing baseband unit (BBU) function pooling at a central location. Therefore, once the threshold for centralized O-DU functionality is exceeded, it may no longer be necessary to attempt to centralize RICs in a near real-time (RT) manner.

[0086] Figure 9 An example of functional splitting between the Central Unit (CU) and the RIC is shown.

[0087] refer to Figure 9The functions of the Central Unit (CU) 910 (e.g., O-CU 330, O-CU-CP 331, or O-CU-UP 332) and the RIC 920 (e.g., Near-RT RIC 340) can be implemented separately or in combination. Deployment scenarios can be determined based on the deployment of the functions. For example, functions can be distributed according to deployment scenario #1 900. It can be configured to replace only at least one smart requirement function (e.g., service guidance function or cell admission control (CAC) function). In deployment scenario #1 900, the RIC 920 can be located at a separate site or can exist simply as another NE. For another example, 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 functions, session functions, UE context functions, and cell context functions). In deployment scenario #2 950, the RIC 920 can be implemented as the same device as the CU 910 (e.g., a server device). For example, within the same cloud, the RIC 920 can share all functionalities with the CU 910.

[0088] Figure 9 Two scenarios are shown, but other scenarios can also be applied. For example, in deployment scenario #1 900, mobility functions can be performed by RIC 920 instead of CU 910. Furthermore, for example, in deployment scenario #1 900, UE context functions can be performed by RIC 920 instead of CU 910. Additionally, for example, in deployment scenario #1 900, session functions can be performed by RIC 920 instead of CU 910.

[0089] Figure 10An example of the RAN function for each E2 node is shown. In O-RAN, a RAN function indicates a specific function at the E2 node. For example, a RAN function may include intra-RAN functions for processing UEs and / or cells. The RAN function identifier (ID) indicates a logical identifier for a specific RAN function within an E2 node that supports one or more RIC services using a specific E2 service model (E2SM). The RAN function object identifier (OID) indicates the type of E2SM and can be used to identify the definition of a RAN function. The RAN function ID is not a unique value for a RAN function, but rather an index used to indicate the RAN function at the corresponding E2 node. In fact, even with the same RAN function, an E2 node can map corresponding RAN functions to different RAN function IDs. Furthermore, even with the same RAN function ID, an E2 node can map different RAN functions to their corresponding RAN function IDs. Therefore, in addition to the RAN function ID, the RAN function definition or RAN function OID may also be needed to know information about the actual RAN function.

[0090] refer to Figure 10 Each E2 node (e.g., the first E2 node 1051, the second E2 node 1052, or 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 establishment procedure with the Near-RT RIC 1040. For example, an E2 node can send an E2 establishment request message to the Near-RT RIC 1040. The E2 establishment request message may include information about one or more RAN functions. The Near-RT RIC 1040 can send information about at least one accepted RAN function among the one or more RAN functions to the corresponding E2 node via an E2 establishment response message. In this way, the Near-RT RIC 1040 can store information about RAN functions at each E2 node.

[0091] The Near-RT RIC 1040 can connect to E2 nodes (e.g., first E2 node 1051, second E2 node 1052, and third E2 node 1053). For example, the first E2 node 1051 can store three RAN functions. The first E2 node 1051 can store E2SM-RC, Revision 2, and an OID for RAN function ID #1. The OID can indicate E2SM-RC. Revision 2 indicates the revision counter for the corresponding RAN function. The first E2 node 1051 can store E2SM-KPM, Revision 1, and an OID for RAN function ID #2. The OID can indicate E2SM-KPM. The first E2 node 1051 can store E2SM-CCC, Revision 1, and an OID for RAN function ID #3. The OID can indicate E2SM-CCC. Similarly, the second E2 node 1052 can store three RAN functions. The second E2 node 1052 can store E2SM-RC, Revision 2, and an OID for RAN function ID #1. The OID can indicate E2SM-RC. The second E2 node 1052 can store the OID for E2SM-CCC, Revision 1, and RAN function ID #2. The OID can indicate E2SM-CCC. The second E2 node 1052 can store the OID for E2SM-KPM, Revision 1, and RAN function ID #3. The OID can indicate E2SM-KPM. For example, the third E2 node 1053 can store three RAN functions. The third E2 node 1053 can store the OID for E2SM-CCC, Revision 2, and RAN function ID #1. The OID can indicate E2SM-CCC. The third E2 node 1053 can store the OID for E2SM-RC, Revision 1, and RAN function ID #2. The OID can indicate E2SM-RC. The third E2 node 1053 can store the OID for E2SM-KPM, Revision 1, and RAN function ID #3. The OID can indicate E2SM-KPM.

[0092] The Near-RT RIC 1040 needs to store the same information as the RAN function ID stored in each E2 node, along with related information (e.g., OID, revision, or service model) corresponding to the respective RAN function ID. However, if there are problems with the connection state during a series of processes between the Near-RT RIC 1040 and the E2 node (e.g., E2 setup process), or if an error occurs in the database within the Near-RT RIC 1040, the Near-RT RIC 1040 may store information about the RAN functions of each E2 node differently than the actual configuration. For example, the Near-RT RIC 1040 may associate information indicating an E2 node (e.g., E2 node index or E2 node component ID) with another E2 node instead of the actual E2 node. In other words, an error may occur in the E2 node index stored in the Near-RT RIC 1040. The Near-RT RIC 1040 may store the RAN function profile of the first E2 node 1051 in the RAN function profile 1063 of the third E2 node 1053. The Near-RT RIC 1040 can store the RAN function profile of the second E2 node 1052 in the RAN function profile 1061 of the first E2 node 1051. The Near-RT RIC 1040 can also store the RAN function profile of the third E2 node 1053 in the RAN function profile 1062 of the second E2 node 1052.

[0093] In the above scenario, the Near-RT RIC 1040 can perform a RIC service update procedure with the third E2 node 1053. The Near-RT RIC 1040 can send a RIC service query message to the third E2 node 1053. The RIC service query message defined in the current standard is as follows.

[0094] [Table 1]

[0095] For "IE type and reference," refer to the O-RAN WG3 E2AP standard. "M" (Mandatory) indicates that the corresponding IE is mandatory, and "O" (Optional) indicates that the corresponding IE is optional. "Message Type" indicates the message type (e.g., initiation message, success result, or failure result), and "Transaction ID" can be used to uniquely identify the corresponding process within concurrent processes of the same type (e.g., RIC service update process). "RAN Functions Accepted List" indicates a list of all RAN functions accepted by the Near-RT RIC1040. "RAN Functions ID Item" indicates the RAN Function ID ("RAN Function ID") and RAN Function Revision ("RAN Function Revision") for each RAN function. The RAN Function Revision indicates the revision counter (or updated version information or update count) for the corresponding RAN function.

[0096] Near-RT RIC 1040 can send RIC service query messages to the third E2 node 1053 according to Table 1. Near-RT RIC 1040 can send RIC service query messages to the third E2 node 1053 indicating "RAN Function ID #1" and "Revision 2". Near-RT RIC 1040 has already sent RIC service query messages to provide RIC services according to E2SM-RC, but the third E2 node 1053 can provide feedback on the RAN function corresponding to E2SM-CCC. This is because, referring to Table 1, each RAN function item only includes the RAN function ID and RAN function revision as parameters indicating the RAN function, and does not include other parameters. Since information about the definition or service model related to the RAN function is not included in the Near-RT RIC 1040's RIC service query message, the third E2 node 1053 may not be aware that error information is stored in Near-RT RIC 1040. In other words, for a RAN function with the same RAN function ID and RAN function revision as indicated by Near-RT RIC 1040, the third E2 node 1053 may not be aware of the aforementioned error. According to this standard, if the information about RAN functions (e.g., the RAN function acceptance list) in the RIC service query message from Near-RT RIC 1040 matches the RAN functions supported by the third E2 node 1053, then the third E2 node 1053 can send an RIC service update message that does not include separate information about RAN functions (e.g., the RAN Function Added List IE, RAN Function Modified List IE, and RAN Function Deleted List IE). Because "RAN Function ID #1" and "Revision 2" are identical for both the third E2 node 1053 and the Near-RT RIC 1040, "RAN Function ID #2" and "Revision 1" are identical for both the third E2 node 1053 and the Near-RT RIC 1040, and because "RAN Function ID #3" and "Revision 1" are identical for both the third E2 node 1053 and the Near-RT RIC 1040, the third E2 node 1053 can send RIC service update messages to the Near-RT RIC 1040 that do not include separate information about RAN functions (e.g., RAN Function Addition List IE, RAN Function Modification List IE, and RAN Function Deletion List IE). Therefore, the Near-RT RIC 1040 performs the RIC subscription procedure or the RIC control procedure based on the error profile used by the third E2 node 1053.

[0097] To address the aforementioned issues, embodiments of this disclosure describe a scheme for more specifically notifying E2 nodes (e.g., first E2 node 1051, second E2 node 1052, or third E2 node 1053) of information about RAN functions, or requesting all RAN functions supported by the E2 nodes, via RIC service query messages.

[0098] 1. Option 1 The Near-RT RIC 1040 can send RIC service query messages to E2 nodes for each RAN function, including the RAN function ID, RAN function revision, and RAN function OID. For example, the RIC service query message can have the following format.

[0099] [Table 2]

[0100] For "IE type and reference", refer to the O-RAN WG3 E2AP standard. "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, success result, or failure result), and the "Transaction ID" can be used to uniquely identify the corresponding process within concurrent processes of the same type (e.g., RIC service update process). "RANFunctions Accepted List" indicates a list of all RAN functions accepted by Near-RT RIC 1040. "RANFunctions 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 the revision counter used for the corresponding RAN function. The RAN Function OID can uniquely indicate a specific E2 service model (SM). The RAN Function OID can be used to indicate the RAN function definition for a specific E2SM. Because the RAN function OID indicates the service model corresponding to the RAN function, the information mismatch between E2 nodes and 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 multiple service models specified in the O-RAN. For example, multiple service models may include Network Interface (E2SM-NI), Critical Performance Monitoring (E2SM-KPM) Revision 1, E2SM-KPM Version 2, Radio Control (E2SM-RC), and / or Cell Configuration and Control (E2SM-CCC). The RAN function OID can have different values ​​depending on the service model it is intended to indicate. For example, the RAN function OID can have the following format.

[0101] [Table 3]

[0102] 2. Option Two The Near-RT RIC 1040 can send RIC service query messages to E2 nodes for each RAN function. These messages include the RAN function ID, RAN function revision, RAN function OID, and RAN function definition. For example, the RIC service query message can have the following format.

[0103] [Table 4]

[0104] For “IE type and reference”, refer to the O-RAN WG3 E2AP standard. “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, success result, or failure result), and “Transaction ID” can be used to uniquely identify the corresponding process in parallel ongoing processes of the same type (e.g., RIC service update process). “RAN FunctionsAccepted List” indicates a list of all RAN functions accepted by Near-RT RIC 1040. “RAN Functions IDItem” indicates the RAN function ID (“RAN Function ID”), RAN function revision (“RANFunction Revision”), RAN function OID (“RAN Function OID”), and RAN function definition (“RAN FunctionDefinition”) for each RAN function. The RAN function revision indicates the revision counter used for the corresponding RAN function. The RAN function OID can uniquely indicate a specific E2 service model (SM) (e.g., the OID and E2SM in Table 3). RAN function definitions can indicate how an E2 node is configured to support a given function in a corresponding service model (e.g., the type of service model indicated by the RAN function OID). RAN function definitions can include information needed to determine the configuration of a given function of an E2 node. RAN function definitions can include one or more RAN parameters based on RIC service styles (e.g., reporting, insertion, control, or policy).

[0105] Meanwhile, for backward compatibility, RAN function OIDs and RAN function definitions are configured as shown in Table 4 (e.g., optional), but embodiments of this disclosure are not limited thereto. For example, for items whose format matches that of the RIC service update message (e.g., Figure 11a and Figure 11b As shown in Table 8, each RAN function item of the RIC service query message can be configured as shown in the following table.

[0106] [Table 5]

[0107] For each IE in Table 5, refer to the description in Table 4.

[0108] 3. Third Option The Near-RT RIC 1040 can send RIC service query messages to E2 nodes that include only the message type and transaction ID. For example, the RIC service query message can have the following format.

[0109] [Table 6]

[0110] For "IE type and reference", refer to the O-RAN WG3 E2AP standard. "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, success result, or failure result), and "Transaction ID" can be used to uniquely identify the corresponding process within concurrent processes of the same type (e.g., RIC service update process). RIC service query messages that do not include separate information related to RAN functions can be used to request a list of all RAN functions supported by the E2 node. The format of the RIC service query message can be fixed as shown in Table 6. In response to the RIC service query message, the E2 node can be configured to always return a list of all RAN functions supported by the E2 node. The list of all RAN functions supported by the E2 node can include the RAN function ID, RAN function definition, RAN function revision, and RAN function OID for each RAN function.

[0111] 4. Fourth Option The Near-RT RIC 1040 can send RIC service query messages to E2 nodes, including indicators for requesting a complete list. For example, the RIC service query message can have the following format.

[0112] [Table 7]

[0113] For "IE type and reference", refer to the O-RAN WG3 E2AP standard. "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, success result, or failure result), and "Transaction ID" can be used to uniquely identify the corresponding process within concurrent processes of the same type (e.g., RIC service update process). "RAN FunctionsAccepted List" indicates a list of all RAN functions accepted by the Near-RT RIC 1040. "RAN Functions IDItem" indicates the RAN Function ID ("RAN Function ID"), RAN Function Revision ("RANFunction Revision"), and RAN Function OID ("RAN Function OID") for each RAN function. The RAN Function Revision indicates the revision counter used for the corresponding RAN function. The RAN Function OID can uniquely indicate a specific E2 SM. The RAN Function OID can be used to indicate the RAN function definition for a specific E2 SM. The "Request Indicator," as a request indicator, can be used to request a list of all RAN functions supported by the E2 node. The "request indicator" can be used as a condition indicator. If even a single piece of information about RAN functions (e.g., the RAN function acceptance list) in the Near-RT RIC 1040's RIC service query message does not match the information actually stored in the E2 node, the condition indicator can cause the E2 node to send a RIC service update message including information about all RAN functions that can be supported by the E2 node. This indicator allows for early resolution of information mismatches between the Near-RT RIC 1040 and the E2 node. Table 7 is an example of Table 2 in which the indicator is added in the first scheme, but embodiments of this disclosure are not limited thereto. In addition to Table 2, the indicator can also be added to Tables 1, 4, and 5.

[0114] Figure 11a and Figure 11b The signal flow used for the RIC service update process is illustrated. The purpose of the RIC service update process is to update application-level RIC service-related data, which is necessary for proper interoperability between E2 nodes and Near-RT RICs via the E2 interface.

[0115] refer to Figure 11aIn operation 1101, Near-RT RIC 1040 can send an RIC service query message to E2 node 1050. According to an embodiment, the RIC service query message may include the OID corresponding to each RAN function in the RAN function acceptance list. For example, the RIC service query message may have the format of Table 2. According to an embodiment, the RIC service query message may include the OID and RAN function definition corresponding to each RAN function in the RAN function acceptance list. For example, the RIC service query message may have the format of Table 4 or Table 5. According to an 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. According to an embodiment, when it does not match the RAN function acceptance list, the RIC service query message may include an indicator for requesting the complete list. For example, the RIC service query message may have the format of Table 7.

[0116] In operation 1103, E2 node 1050 can send a RIC service update message to Near-RT RIC 1040. When Near-RT RIC 1040 receives the RIC service update message from E2 node 1050, Near-RT RIC 1040 can update application-level data. The updated RAN functions can be used for RIC subscription requests or RIC control messages. For example, the RIC service update message can have the following format.

[0117] [Table 8]

[0118] For "IE type and reference", refer to the O-RAN WG3 E2AP standard. "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, success result, or failure result), and "Transaction ID" can be used to uniquely identify the corresponding process within concurrent processes of the same type (e.g., RIC service update process). "RAN FunctionsAdded List" indicates information about RAN functions to be added by E2 node 1050. "RAN Functions Modified List" indicates information about RAN functions to be modified by E2 node 1050. "RAN Functions Deleted List" indicates information about RAN functions to be deleted by E2 node 1050. Information for each RAN function indicates the RAN Function ID ("RAN Function ID"), RAN Function Definition ("RAN Function Definition"), RAN Function Revision ("RAN Function Revision"), and RAN Function OID ("RAN Function OID"). The RAN Function Revision indicates the revision counter used for the corresponding RAN function. RAN function OIDs can uniquely identify a specific E2 service model (SM) (e.g., the OIDs and E2SMs in Table 3). RAN function definitions can 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). RAN function definitions can include the information needed to determine the configuration of a given function of an E2 node.

[0119] In response to a RIC service query message, E2 node 1050 may send a RIC service update message to Near-RT RIC 1040. For example, if there is no RAN function acceptance list in the RIC service query message, E2 node 1050 may send a RIC service update message that includes a list of all RAN functions supported by E2 node 1050. For example, if the information about RAN functions in the RAN function acceptance list in the RIC service query message aligns with the information about RAN functions supported by E2 node 1050, E2 node 1050 may send a RIC service update message that does not include a list of RAN functions (e.g., “RAN Functions AddedList,” “RAN Functions Modified List,” or “RAN Functions Deleted List” in Table 8). For example, if the information about RAN functions in the RAN function acceptance list in the RIC service query message is not aligned with the information about the RAN functions that E2 node 1050 can support, E2 node 1050 can send the required list of RAN functions (e.g., “RAN Functions Added List”, “RAN Functions Modified List”, or “RAN Functions Deleted List” in Table 8) via the RIC service update message to ensure realignment between E2 node 1050 and Near-RT RIC 1040.

[0120] In operation 1105, Near-RT RIC 1040 can send a RIC service update confirmation message to E2 node 1050. If the update of at least one RAN function in the RIC service update message is successful, Near-RT RIC 1040 can send an update confirmation message. For example, the update confirmation message can have the following format.

[0121] [Table 9]

[0122] For "IE type and reference", please refer to the O-RAN WG3 E2AP standard. "M" indicates that the corresponding IE is mandatory, and "O" indicates that the corresponding IE is optional. For the content of each IE, please refer to Tables 1 through 8. Information regarding the rejection reason for each RAN function may be included.

[0123] According to an embodiment, the information included in the RIC service update confirmation message for each RAN function can be matched with the information included in the RIC service query message for each RAN function. For example, when sending an RIC service query message according to Table 2, the Near-RT RIC 1040 can send a list (e.g., "RAN Functions Accepted List" IE) to the E2 node 1050 for each RAN function, including the RAN function ID, RAN function revision, and RAN function OID. As another example, when sending an RIC service query message according to Table 4, the Near-RT RIC 1040 can send a list (e.g., "RAN Functions Accepted List" IE) to the E2 node 1050 for each RAN function, including the RAN function ID, RAN function revision, RAN function OID, and RAN function definition.

[0124] refer to Figure 11b In operation 1101, Near-RT RIC 1040 can send an RIC service query message to E2 node 1050. According to an embodiment, the RIC service query message may include the OID corresponding to each RAN function in the RAN function acceptance list. For example, the RIC service query message may have the format of Table 2. According to an embodiment, the RIC service query message may include the OID and RAN function definition corresponding to each RAN function in the RAN function acceptance list. For example, the RIC service query message may have the format of Table 4 or Table 5. According to an 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. According to an embodiment, when it does not match the RAN function acceptance list, the RIC service query message may include an indicator for requesting the complete list. For example, the RIC service query message may have the format of Table 7.

[0125] In operation 1103, E2 node 1050 can send a RIC service update message to Near-RT RIC 1040. When Near-RT RIC 1040 receives the RIC service update message from E2 node 1050, Near-RT RIC 1040 can update application-level data. The updated RAN functions can be used for RIC subscription requests or RIC control messages. For example, the RIC service update message can have the format shown in Table 8.

[0126] In operation 1155, Near-RT RIC 1040 can send a RIC service update failure message to E2 node 1050. If it is difficult to accept the update via the RIC service update message, Near-RT RIC 1040 can send a RIC service update failure message. For example, the RIC service update failure message can have the following format.

[0127] [Table 10]

[0128] For "IE type and reference", refer to the O-RAN WG3 E2AP standard. "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, success result, or failure result), and "Transaction ID" can be used to uniquely identify the corresponding process within concurrent processes of the same type (e.g., RIC service update process). "Cause" indicates the cause of the failure, and "Time To Wait" indicates the minimum allowable waiting time.

[0129] Figure 12 An example of resolving a bug in Near-RT RIC (e.g., Near-RT RIC 1040) via the RIC service update process is shown. Figure 12 The document describes an example of a RAN function profile in Near-RT RIC 1040 that corrects incorrect storage of E2 nodes by performing a RIC service update process according to the aforementioned schemes (e.g., the first scheme, the second scheme, the third scheme, the fourth scheme, and / or technically equivalent schemes). It assumes that... Figure 10 The RAN functions of the first E2 node 1051, the second E2 node 1052, and the third E2 node 1053 are shown in the Near-RT RIC 1040.

[0130] refer to Figure 12 In operation 1211, Near-RT RIC 1040 can send a RIC service query message to the first E2 node 1051. In operation 1213, the first E2 node 1051 can send a RIC service update message to Near-RT RIC 1040.

[0131] According to an embodiment, when the first scheme is adopted, the RIC service query message may include {(“Revision 2” and “OID” corresponding to RAN function ID #1 (e.g., indicating E2SM-RC)”), (“Revision 1” and “OID” corresponding to RAN function ID #2 (e.g., indicating E2SM-CCC)”), and (“Revision 1” and “OID” corresponding to RAN function ID #3 (e.g., indicating E2SM-KPM)”)}. The RIC service query message may have the format of Table 2. The first E2 node 1051 can compare the information about RAN functions in the RIC service query message with the 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 can send to the Near-RT RIC 1040 a RAN function item (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. For example, the first E2 node 1051 can include {(RAN function definition, RAN function revision, and RAN function OID corresponding to RAN function ID #2 (e.g., E2SM-KPM) and (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 send to the Near-RT RIC 1040 a RIC service update message including the “RAN Functions Modified List” IE.

[0132] According to an embodiment, when the second scheme is adopted, the RIC service query message may include {(“Revision 2”, “OID (e.g., indicating E2SM-RC)” and the RAN function definition corresponding to RAN function ID#1), (“Revision 1”, “OID (e.g., indicating E2SM-CCC)” and the RAN function definition corresponding to RAN function ID#2), and (“Revision 1”, “OID (e.g., indicating E2SM-KPM)” and the RAN function definition corresponding to RAN function ID#3)}. The RIC service query message may have the format of Table 4. The first E2 node 1051 can compare the information about RAN functions in the RIC service query message with the information about RAN functions supported by the first E2 node 1051. For RAN function ID#2, the first E2 node 1051 and Near-RT RIC 1040 have different service models. For RAN function ID#3, the first E2 node 1051 and Near-RT RIC 1040 have different service models. Therefore, the first E2 node 1051 can send to the Near-RT RIC 1040 a RAN function item (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. For example, the first E2 node 1051 can include {(RAN function definition, RAN function revision, and RAN function OID corresponding to RAN function ID #2 (e.g., E2SM-KPM)) and (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 send to the Near-RT RIC 1040 a RIC service update message including the “RAN Functions Modified List” IE.

[0133] According to an embodiment, when the third approach is adopted, the RIC service query message may not include other information (e.g., information about RAN functions) besides the message type and transaction ID. For example, the RIC service query message may have the format of Table 6. The first E2 node 1051 may send an RIC service update message in response to the RIC service query message, which includes a list of all 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)) and (RAN function definition, RAN function revision and RAN function OID corresponding to RAN function ID#3 (e.g., E2SM-CCC))} in the “RANFunctions Modified List” IE of Table 8. The first E2 node 1051 may send a RIC service update message including the “RAN Functions Modified List” IE to the Near-RT RIC 1040.

[0134] According to an embodiment, when the fourth scheme is adopted, the RIC service query message may include {(“Revision 2” and “OID” corresponding to RAN function ID #1 (e.g., indicating E2SM-RC)”), (“Revision 1” and “OID” corresponding to RAN function ID #2 (e.g., indicating E2SM-CCC)”), and (“Revision 1” and “OID” corresponding to RAN function ID #3 (e.g., indicating E2SM-KPM)”)} and a request indicator (e.g., “Request Indicator” in Table 7). For example, the RIC service query message may have the format of Table 7. The first E2 node 1051 can compare the information about RAN functions in the RIC service query message with the information about RAN functions supported by the first E2 node 1051. The first E2 node 1051 can recognize that, regarding RAN function ID #2 or RAN function ID #3, the first E2 node 1051 stores information that is different from the information of the Near-RT RIC. In response to recognizing this mismatch, the first E2 node 1051 may send a RIC service update message including a list of all 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)) and (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 send a RIC service update message including the “RANFunctions Modified List” IE to the Near-RT RIC 1040.

[0135] In operation 1221, Near-RT RIC 1040 can send a RIC service query message to the second E2 node 1052. In operation 1223, the second E2 node 1052 can send a RIC service update message to Near-RT RIC 1040. Similar to the first E2 node 1051, the second E2 node 1052 can also send RIC service update messages for alignment with Near-RT RIC 1040.

[0136] According to an embodiment, the second E2 node 1052 can identify the RAN function acceptance list (e.g., the “RAN Functions Accepted List” IE of Table 2 in the first scheme, Table 4 in the second scheme, or Table 7 in the fourth scheme) of the RIC service query message. The second E2 node 1052 can compare the information about RAN functions in the RAN function acceptance list with the information about the RAN functions supported by the second E2 node 1052. For example, in response to the RIC service query message according to the first or second scheme, the second E2 node 1052 can send a RAN function item (e.g., a combination of RAN function ID, RAN function definition, RAN function revision, and RAN function OID) corresponding to the difference based on the comparison result via an RIC service update message. For example, in response to the RIC service query message according to the fourth scheme, the second E2 node 1052 can send 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 second E2 node 1052 via an RIC service update message, regardless of the comparison result. According to another embodiment, the second E2 node 1052 can recognize the RIC service query message sent according to the third scheme described above. In response to the RIC service query message, the second E2 node 1052 can send 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 second E2 node 1052 via an RIC service update message.

[0137] In operation 1231, Near-RT RIC 1040 may send an RIC service query message to the third E2 node 1053. In operation 1233, the third E2 node 1053 may send an RIC service update message to Near-RT RIC 1040. Similar to the first E2 node 1051, the third E2 node 1053 may also send an RIC service update message for alignment with Near-RT RIC 1040. According to an embodiment, the third E2 node 1053 may identify the RAN function acceptance list (e.g., the “RAN Functions Accepted List” IE of Table 2 in the first scheme, Table 4 in the second scheme, or Table 7 in the fourth scheme) of the RIC service query message. The third E2 node 1053 may compare the information about RAN functions in the RAN function acceptance list with the information about the RAN functions supported by the third E2 node 1053. For example, in response to a RIC service query message according to the first or second scheme, the third E2 node 1053 can send a RAN function item (e.g., a combination of RAN function ID, RAN function definition, RAN function revision, and RAN function OID) corresponding to the difference based on the comparison result via a RIC service update message. For example, in response to a RIC service query message according to the fourth scheme, the third E2 node 1053 can send a RIC service update message for 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, regardless of the comparison result. According to another embodiment, the third E2 node 1053 can recognize a RIC service query message sent according to the third scheme described above. In response to the RIC service query message, the third E2 node 1053 can send a RIC service update message for 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.

[0138] By delivering additional information (e.g., RAN function OID or RAN function definition) to the E2 node via RIC service query messages, a more accurate RAN function can be queried from the E2 node. Therefore, even if the RAN function information on 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 process. By having the E2 node send items (e.g., RAN function ID, RAN function definition, RAN function revision, and RAN function OID) on the RAN functions incorrectly stored in the Near-RT RIC via the aforementioned RIC service query messages, the corrupted database in the Near-RT RIC can be recovered.

[0139] The effects that can be obtained from this disclosure are not limited to those described above, and any other effects not mentioned herein will be clearly understood by those skilled in the art to which this disclosure pertains, based on the following description.

[0140] In one embodiment, a method performed by an E2 node is provided. This method may include receiving a RIC service query message from a Near-RT Radio Access Network (RAN) Intelligent Controller (Near-RT RIC). The method may also include sending 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 a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM) for each RAN function.

[0141] For example, the list of RAN functions can also include RAN function definition information for each RAN function. RAN function definition information can be used to provide the information required by Near-RT RIC to support the corresponding RAN function at the E2 node. RAN function OIDs can be used to identify the RAN function definition in the RAN function definition information.

[0142] For example, a RAN function OID can indicate one of multiple service models. These multiple service models may include E2SM-Network Interface (NI), E2SM-Critical Performance Monitoring (KPM) version 1, E2SM-KPM version 2, E2SM-Radio Control (RC), and E2SM-Cell Configuration and Control (CCC).

[0143] 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. If the RAN functions supported at the E2 node do not match the functions in the list, the RIC service update message may include an add list, a modify list, and / or a delete list for RAN functions. If the RAN functions supported at the E2 node match the functions in the list, the RIC service update message may not include the add list, modify list, and delete list.

[0144] For example, the method may include receiving a second RIC service query message from the Near-RT RIC that does not include a list of RAN functions. The method may also include sending a second RIC service update message to the Near-RT RIC. In response to the second RIC service query message that does not include a list of RAN functions, the second RIC service update message may include a list of all RAN functions supported at the E2 node.

[0145] In one embodiment, a method is provided performed by a Near-Real-Time (RT) Radio Access Network (RAN) Intelligent Controller (Near-RT RIC). The method may include sending an RIC service query message to an E2 node. The method may also include receiving an RIC service update message from an 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 a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM) for each RAN function.

[0146] For example, the list of RAN functions can also include RAN function definition information for each RAN function. RAN function definition information can be used to provide the information required by Near-RT RIC to support the corresponding RAN function at the E2 node. RAN function OIDs can be used to identify the RAN function definition in the RAN function definition information.

[0147] For example, a RAN function OID can indicate one of multiple service models. These multiple service models may include E2SM-Network Interface (NI), E2SM-Critical Performance Monitoring (KPM) version 1, E2SM-KPM version 2, E2SM-Radio Control (RC), and E2SM-Cell Configuration and Control (CCC).

[0148] For example, the method may include sending a RIC service update confirmation message or a RIC service update failure message to the E2 node. If the RAN functions supported at the E2 node do not match the functions in the list, the RIC service update message may include an add list, a modify list, and / or a delete list for RAN functions. If the RAN functions supported at the E2 node match the functions in the list, the RIC service update message may not include the add list, modify list, and delete list.

[0149] For example, the method may include sending a second RIC service query message to the E2 node that does not include a list of RAN functions. The method may also include receiving a second RIC service update message from the E2 node. In response to the second RIC service query message that does not include a list of RAN functions, the second RIC service update message may include a list of all RAN functions supported at the E2 node.

[0150] In one embodiment, an electronic device for an E2 node is provided. The electronic device may include at least one processor and a memory storing instructions. When executed by the at least one processor, the instructions enable the E2 node to receive RIC service query messages from a Near-Real-Time (RT) Radio Access Network (RAN) Intelligent Controller (Near-RT RIC) and, in response to the RIC service query messages, to send RIC service update messages 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 a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM) for each RAN function.

[0151] For example, the list of RAN functions can also include RAN function definition information for each RAN function. RAN function definition information can be used to provide the information required by Near-RT RIC to support the corresponding RAN function at the E2 node. RAN function OIDs can be used to identify the RAN function definition in the RAN function definition information.

[0152] For example, a RAN function OID can indicate one of multiple service models. These multiple service models may include E2SM-Network Interface (NI), E2SM-Critical Performance Monitoring (KPM) version 1, E2SM-KPM version 2, E2SM-Radio Control (RC), and E2SM-Cell Configuration and Control (CCC).

[0153] For example, when executed by at least one processor, this instruction can cause an E2 node to receive a RIC service update confirmation message or a RIC service update failure message from the Near-RT RIC. If the RAN functions supported at the E2 node do not match the functions in the list, the RIC service update message may include an add list, a modify list, and / or a delete list for RAN functions. If the RAN functions supported at the E2 node match the functions in the list, the RIC service update message may not include the add list, modify list, and delete list.

[0154] For example, when executed by at least one processor, this instruction can cause an E2 node to receive a second RIC service query message from the Near-RT RIC that does not include a list of RAN functions, and to send a second RIC service update message to the Near-RT RIC. In response to the second RIC service query message that does not include a list of RAN functions, the second RIC service update message may include a list of all RAN functions supported at the E2 node.

[0155] In one embodiment, an electronic device for a near real-time (RT) radio access network (RAN) intelligent controller (Near-RTRIC) is provided. The electronic device may include at least one processor and a memory storing instructions. When executed by the at least one processor, the instructions enable the Near-RT RIC to send RIC service query messages to E2 nodes and receive RIC service update messages from E2 nodes. 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 a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM) for each RAN function.

[0156] For example, the list of RAN functions can also include RAN function definition information for each RAN function. RAN function definition information can be used to provide the information required by Near-RT RIC to support the corresponding RAN function at the E2 node. RAN function OIDs can be used to identify the RAN function definition in the RAN function definition information.

[0157] For example, a RAN function OID can indicate one of multiple service models. These multiple service models may include E2SM-Network Interface (NI), E2SM-Critical Performance Monitoring (KPM) version 1, E2SM-KPM version 2, E2SM-Radio Control (RC), and E2SM-Cell Configuration and Control (CCC).

[0158] For example, when executed by at least one processor, this instruction can cause the Near-RT RIC to send a RIC service update confirmation message or a RIC service update failure message to the E2 node. If the RAN functions supported at the E2 node do not match the functions in the list, the RIC service update message may include an add list, a modify list, and / or a delete list for RAN functions. If the RAN functions supported at the E2 node match the functions in the list, the RIC service update message may not include the add list, modify list, and delete list.

[0159] For example, when executed by at least one processor, this instruction can cause the Near-RT RIC to send a second RIC service query message to the E2 node that does not include a list of RAN functions, and to receive a second RIC service update message from the E2 node. In response to the second RIC service query message that does not include a list of RAN functions, the second RIC service update message may include a list of all RAN functions supported at the E2 node.

[0160] In one embodiment, an electronic device for an E2 node is provided. This electronic device may include at least one transceiver and at least one processor. The at least one processor may be configured to: receive RIC service query messages from a Near-Real-Time (RT) Radio Access Network (RAN) Intelligent Controller (Near-RT RIC) via the at least one transceiver; and, in response to the RIC service query messages, send RIC service update messages to the Near-RT RIC via 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 a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM) for each RAN function.

[0161] In one embodiment, an electronic device for a near-real-time (RT) radio access network (RAN) intelligent controller (Near-RTRIC) is provided. This electronic device may include at least one transceiver and at least one processor. The at least one processor may be configured to enable the Near-RT RIC to send RIC service query messages to E2 nodes via the at least one transceiver, and to receive RIC service update messages from E2 nodes via 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 a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM) for each RAN function.

[0162] In one embodiment, a non-transitory computer-readable storage medium is provided. This non-transitory computer-readable storage medium may include instructions that, when executed by a processor, cause an E2 node to perform operations including receiving an RIC service query message from a Near-Real-Time (RT) Radio Access Network (RAN) Intelligent Controller (Near-RT RIC) and, in response to the RIC service query message, sending an 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 a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM) for each RAN function.

[0163] In this embodiment, 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-Real-Time (RT) Radio Access Network (RAN) Intelligent Controller (Near-RT RIC) to perform operations including sending RIC service query messages to E2 nodes and receiving RIC service update messages from E2 nodes. 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 a RAN function ID, a RAN function revision, and a RAN function object identifier (OID) indicating a specific E2 service model (E2SM) for each RAN function.

[0164] For one or more embodiments, at least one of the components described in one or more of the foregoing figures may be configured to perform one or more operations, techniques, processes, and / or methods as described in this disclosure. For example, a processor (e.g., a baseband processor) described in this disclosure in conjunction with one or more of the foregoing figures may be configured to operate according to one or more examples described in this disclosure. As another example, circuitry associated with user equipment (UE), base stations, network elements, etc., as described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more examples described herein.

[0165] Unless otherwise expressly stated, any of the above embodiments may be combined with any other embodiment (or combination of embodiments). The foregoing description of one or more implementations is for illustration and explanation, but is not intended to limit the scope of the embodiments or to exhaustively describe the precise forms disclosed. Modifications and variations are possible in accordance with the above teachings, or may be obtained from practice with various embodiments.

[0166] The methods described in the embodiments of the claims or specification of this disclosure can be implemented in hardware, software, or a combination of hardware and software.

[0167] When implemented as software, a computer-readable storage medium (e.g., a non-transitory computer-readable storage medium) may be provided for storing one or more programs (software modules). One or more programs stored in the computer-readable storage medium are configured to be executed by one or more processors in an electronic device. One or more programs include instructions to cause the electronic device to perform a method according to the embodiments described in the claims or specification of this disclosure. One or more programs may be included and provided in a computer program product. The computer program product can be traded as a product between a seller and a buyer. 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 via an app store (e.g., the Play Store). TM This refers to the online distribution (e.g., downloading or uploading) of computer program products, or the direct distribution (e.g., downloading or uploading) between two user devices (e.g., smartphones). In the case of online distribution, at least a portion of the computer program product may be temporarily generated or at least temporarily stored in a machine-readable storage medium, such as the memory of a manufacturer's server, an app store's server, or a relay server.

[0168] Such programs (software modules, software) can be stored in random access memory, non-volatile memory including flash memory, read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), disk storage devices, optical storage devices (e.g., optical disc-ROM, digital versatile optical disc (DVD), or other formats), or magnetic tape cartridges. Alternatively, it can be stored in a memory configured with some or all of these. Furthermore, multiple configuration memories may be included.

[0169] Additionally, the program can be stored in an attachable storage device that can be accessed via a communication network such as the Internet, intranet, local area network (LAN), wide area network (WAN), or storage area network (SAN), or a combination thereof. Such a storage device can be connected to a device executing embodiments of this disclosure via an external port. Furthermore, a separate storage device on the communication network can also be connected to a device executing embodiments of this disclosure.

[0170] In the specific embodiments described above, the components included in this disclosure are represented in a singular or plural form according to the presented embodiments. However, the singular or plural expression may be appropriately chosen for ease of explanation, and this disclosure is not limited to singular or plural components; even components expressed in a plural form may be configured in a singular form, or components expressed in a singular form may be configured in a plural form.

[0171] According to various embodiments, one or more of the aforementioned components may be omitted, or one or more other components may be added. Alternatively or additionally, multiple components (e.g., modules or programs) may be integrated into a single component. In this case, according to various embodiments, the integrated component may still perform the one or more functions of each of the multiple components in the same or similar manner as the corresponding component of the multiple components performed one or more functions prior to integration. According to various embodiments, the operations performed by a module, program, or other component may be performed sequentially, in parallel, repeatedly, or heuristically, or one or more of the operations may be run in a different order or omitted, or one or more other operations may be added.

[0172] Furthermore, specific embodiments have been described in detail in this disclosure, and of course, various modifications are possible without departing from the scope of this disclosure.

Claims

1. A method executed by an E2 node, the method comprising: Receives RIC service query messages from the Near-RT RIC intelligent controller of the near-real-time RT radio access network; as well as In response to the RIC service query message, a RIC service update message is sent to the Near-RT RIC. The RIC service query message includes 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 includes the RAN function ID, RAN function revision, and RAN function object identifier (OID) indicating a specific E2 service model (E2SM) for each RAN function.

2. The method according to claim 1, in, The list of RAN functions also includes RAN function definition information for each RAN function. The RAN function definition information is used to provide the information required by the Near-RT RIC to support the corresponding RAN functions at the E2 node. The RAN function OID is used to identify the RAN function definition in the RAN function definition information.

3. The method according to claim 2, wherein, The RAN function OID indicates one of a plurality of service models, wherein the plurality of service models include E2SM-Network Interface NI, E2SM-Critical Performance Monitoring KPM Version 1, E2SM-KPM Version 2, E2SM-Radio Control RC, and E2SM-Cell Configuration and Control CCC.

4. The method according to claim 1, further comprising receiving a RIC service update confirmation message or a RIC service update failure message from the Near-RT RIC. in, If the RAN function supported at the E2 node does not match the functions in the list, the RIC service update message includes a list of added RAN functions, a list of modified RAN functions, and / or a list of deleted RAN functions. If the RAN function supported at the E2 node matches the function in the list, then the RIC service update message does not include the add list, the modify list, and the delete list.

5. The method according to claim 1, further comprising: Receive a second RIC service query message from the Near-RT RIC that does not include a list of RAN functions; as well as Send a second RIC service update message to the Near-RT RIC. In response to a second RIC service query message that does not include the list of RAN functions, the second RIC service update message includes a list of all RAN functions supported at the E2 node.

6. A method executed by a Near-RT RIC (Near-Real-Time Radio Access Network) intelligent controller, the method comprising: Send an RIC service query message to the E2 node; as well as Receive RIC service update messages from the E2 node. The RIC service query message includes 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 includes the RAN function ID, RAN function revision, and RAN function object identifier (OID) indicating a specific E2 service model (E2SM) for each RAN function.

7. The method according to claim 6, in, The list of RAN functions also includes RAN function definition information for each RAN function. The RAN function definition information is used to provide the information required by the Near-RT RIC to support the corresponding RAN functions at the E2 node. The RAN function OID is used to identify the RAN function definition in the RAN function definition information.

8. The method according to claim 7, wherein, The RAN function OID indicates one of a plurality of service models, wherein the plurality of service models include E2SM-Network Interface NI, E2SM-Critical Performance Monitoring KPM Version 1, E2SM-KPM Version 2, E2SM-Radio Control RC, and E2SM-Cell Configuration and Control CCC.

9. The method according to claim 6, further comprising sending a RIC service update confirmation message or a RIC service update failure message to the E2 node. in, If the RAN function supported at the E2 node does not match the functions in the list, the RIC service update message includes a list of added RAN functions, a list of modified RAN functions, and / or a list of deleted RAN functions. If the RAN function supported at the E2 node matches the function in the list, then the RIC service update message does not include the add list, the modify list, and the delete list.

10. The method according to claim 6, further comprising: Send a second RIC service query message to the E2 node, excluding the list of RAN functions; as well as Receive the second RIC service update message from the E2 node. In response to a second RIC service query message that does not include the list of RAN functions, the second RIC service update message includes a list of all RAN functions supported at the E2 node.

11. An electronic device for an E2 node, the electronic device comprising: At least one processor; as well as The memory stores instructions that, when executed by the at least one processor, cause the E2 node to: Receives RIC service query messages from the Near-RT RIC intelligent controller of the near-real-time RT radio access network; as well as In response to the RIC service query message, a RIC service update message is sent to the Near-RT RIC. The RIC service query message includes 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 includes the RAN function ID, RAN function revision, and RAN function object identifier (OID) indicating a specific E2 service model (E2SM) for each RAN function.

12. The electronic device according to claim 11, in, The list of RAN functions also includes RAN function definition information for each RAN function. The RAN function definition information is used to provide the information required by the Near-RT RIC to support the corresponding RAN functions at the E2 node. The RAN function OID is used to identify the RAN function definition in the RAN function definition information.

13. The electronic device according to claim 12, wherein, The RAN function OID indicates one of a plurality of service models, wherein the plurality of service models include E2SM-Network Interface NI, E2SM-Critical Performance Monitoring KPM Version 1, E2SM-KPM Version 2, E2SM-Radio Control RC, and E2SM-Cell Configuration and Control CCC.

14. The electronic device according to claim 11, wherein, When the instruction is executed by the at least one processor, the E2 node causes it to: receive a RIC service update confirmation message or a RIC service update failure message from the Near-RT RIC. If the RAN function supported at the E2 node does not match the functions in the list, the RIC service update message includes an add list for RAN functions, a modify list for RAN functions, and / or a delete list for RAN functions. If the RAN function supported at the E2 node matches the function in the list, then the RIC service update message does not include the add list, the modify list, and the delete list.

15. An electronic device for a Near-RT RIC (Radio Access Network) intelligent controller, the electronic device comprising: At least one processor; as well as A memory storing instructions that, when executed by the at least one processor, cause the Near-RT RIC to: Send an RIC service query message to the E2 node; as well as Receive RIC service update messages from the E2 node. The RIC service query message includes 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 includes the RAN function ID, RAN function revision, and RAN function object identifier (OID) indicating a specific E2 service model (E2SM) for each RAN function.

Images