APPARATUS AND METHOD FOR REMOVING E2 INTERFACE-RELATED INFORMATION IN A RADIO ACCESS NETWORK - Patent application

Abstract

To provide a 5G or 6G communication system for supporting a higher data transmission rate.SOLUTION: A method to be performed by a Near-RT (real time) RIC (RAN (radio access network) intelligent controller) is provided. The method may include the steps of: receiving an E2 removal request message for indicating termination of an E2 node from the E2 node via an E2 interface, the termination of the E2 node being set by an SMO (Service Management and Orchestration); transmitting an E2 removal response message to the E2 node via the E2 interface; and removing the setting for the E2 node in the Near-RT RIC in response to the E2 removal request message.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to an apparatus and method for removing E2 interface-related information in a radio access network, and more particularly, to an apparatus and method for removing E2 node-related configuration, RIC-related configuration, or E2 interface configuration in accordance with an open radio access network (O-RAN) standard in a wireless communication system. [Background technology]

[0002] 5G mobile communication technology defines a wide frequency band to enable faster transmission speeds and new services, and can be implemented not only in the sub-6GHz band (such as 3.5GHz) below 6GHz, but also in the ultra-high frequency band (above 6GHz) known as millimeter wave (mmWave) such as 28GHz and 39GHz. Furthermore, 6G mobile communication technology, also known as the Beyond 5G system, is being considered for implementation in the terahertz (THz) band (e.g., 95GHz to 3THz band) to achieve transmission speeds 50 times faster and ultra-low latency that is one-tenth of that of 5G mobile communication technology.

[0003] In the early stages of 5G mobile communications technology, the goal is to meet the service support and performance requirements for enhanced Mobile Broadband (eMBB), Ultra-Reliable Low-Latency Communications (URLLC), and massive Machine-Type Communications (mMTC). The technologies include beamforming and massive MIMO to mitigate radio wave path loss and increase radio wave transmission distance in ultra-high frequency bands, various numerology support (such as operation of multiple subcarrier spacing) and dynamic operation of slot formats for efficient use of ultra-high frequency resources, initial access technology to support multiple beam transmission and wideband, definition and operation of Band-Width Part (BWP), new channel coding methods such as Low Density Parity Check (LDPC) code for large-volume data transmission and Polar Code for reliable transmission of control information, and L2 pre-processing (L2 Standardization has progressed in areas such as network pre-processing, and network slicing, which provides dedicated networks specialized for specific services.

[0004] Discussions are currently underway to improve and enhance the initial 5G mobile communications technology, taking into account the services that 5G mobile communications technology was intended to support. Physical layer standardization is underway for technologies such as Vehicle-to-Everything (V2X), which will assist autonomous vehicles in making driving decisions based on their own location and status information transmitted by the vehicle, thereby increasing user convenience; New Radio Unlicensed (NR-U), which aims to operate systems in unlicensed spectrum while complying with various regulatory requirements; UE Power Saving, a technology to reduce the power consumption of NR terminals; Non-Terrestrial Networks (NTN), which are direct terminal-satellite communications to ensure coverage in areas where communication with terrestrial networks is not possible; and positioning.

[0005] In addition, standardization is underway in the areas of radio interface architecture / protocol for technologies such as the Industrial Internet of Things (IIoT) to support new services through collaboration and convergence with other industries, Integrated Access and Backhaul (IAB) to provide nodes for expanding network service areas by integrating wireless backhaul links and access links, Mobility Enhancement including Conditional Handover and Dual Active Protocol Stack (DAPS) handover, and Two-Step Random Access (2-step RACH for NR) to simplify random access procedures. Standardization is also underway in the areas of system architecture / service for 5G baseline architecture (e.g., Service-based Architecture, Service-based Interface) to combine Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) to provide services based on the terminal's location.

[0006] Once 5G mobile communication systems are commercialized, an explosive increase in connected devices is expected to be connected to communication networks, necessitating the enhancement of the functions and performance of 5G mobile communication systems and the integrated operation of connected devices.To this end, new research will be conducted on 5G performance improvement and complexity reduction using extended reality (XR) to efficiently support augmented reality (AR), virtual reality (VR), and mixed reality (MR), artificial intelligence (AI) and machine learning (ML), AI service support, metaverse service support, drone communication, etc.

[0007] Furthermore, the development of 5G mobile communication systems will likely lead to the development of new waveforms to ensure coverage in the terahertz band for 6G mobile communication technology, multiple antenna transmission technologies such as full-dimensional MIMO (FD-MIMO), array antennas, and large-scale antennas, metamaterial-based lenses and antennas to improve terahertz band signal coverage, high-dimensional spatial multiplexing technology using orbital angular momentum (OAM), and reconfigurable intelligent surface (RIS) technology, as well as full duplex technology to improve the frequency efficiency and system network of 6G mobile communication technology, AI-based communication technology that utilizes satellites and artificial intelligence (AI) from the design stage and incorporates end-to-end AI support functions to achieve system optimization, and next-generation distributed computing technology that utilizes ultra-high-performance communication and computing resources to enable services of a complexity that exceeds the limits of terminal computing capabilities. Summary of the Invention [Problem to be solved by the invention]

[0008] SUMMARY OF THE INVENTION Embodiments of the present disclosure are directed to addressing at least the problems and / or shortcomings mentioned above and providing at least the advantages described below. One embodiment of the present disclosure provides an apparatus and method for removing E2 interface related information in a wireless communication system. Additional embodiments are set forth in part in the description that follows, and in part will be obvious from the description, or may be learned by practice of the embodiments presented. [Means for solving the problem]

[0009] According to an embodiment of the present disclosure, there is provided a method performed by a Near-RT (real time) RAN (radio access network) intelligent controller (RIC). The method may include receiving an E2 removal request message from an E2 node via an E2 interface to indicate termination of the E2 node, the termination of the E2 node being configured by a Service Management and Orchestration (SMO), transmitting an E2 removal response message to the E2 node via the E2 interface, and removing the configuration for the E2 node in the Near-RT RIC in response to the E2 removal request message.

[0010] According to another embodiment of the present disclosure, a method performed by a Near-RT (real time) RAN (radio access network) intelligent controller (RIC) may include detecting a release of a stream control transmission protocol (SCTP) connection with an E2 node; starting a release timer in response to detecting the release; and removing a configuration for the E2 node in response to expiration of the release timer.

[0011] According to another embodiment of the present disclosure, there is provided a method performed by a Near-RT (real time) RAN (radio access network) intelligent controller (RIC). The method may include detecting a release of a stream control transmission protocol (SCTP) connection with an E2 node, transmitting a message to a Service Management and Orchestration (SMO) via an O1 interface in response to the detection of the release to inquire about a status of the E2 node, receiving a response message regarding the status of the E2 node from the SMO via the O1 interface, and, if the response message indicates completion of termination of the E2 node, removing a configuration for the E2 node in the Near-RT RIC.

[0012] According to another embodiment of the present disclosure, there is provided a method performed by a Near-RT (real time) RAN (radio access network) intelligent controller (RIC), which may include receiving a configuration message for terminating an E2 node connected to the Near-RT RIC from a Service Management and Orchestration (SMO) via an O1 interface, and removing a configuration for the E2 node in the Near-RT RIC in response to the configuration message.

[0013] According to another embodiment of the present disclosure, there is provided an apparatus performed by a Near-RT (real time) RAN (radio access network) intelligent controller (RIC). The apparatus includes at least one transceiver and at least one processor, wherein the at least one processor may be configured to receive an E2 removal request message from an E2 node via an E2 interface to indicate termination of the E2 node, the termination of the E2 node being configured from a Service Management and Orchestration (SMO), transmit an E2 removal response message to the E2 node via the E2 interface, and perform removal of the configuration for the E2 node in the Near-RT RIC in response to the E2 removal request message.

[0014] According to another embodiment of the present disclosure, there is provided an apparatus performed by a Near-RT (real time) RAN (radio access network) intelligent controller (RIC), the apparatus including at least one transceiver and at least one processor, wherein the at least one processor may be configured to detect a release of a stream control transmission protocol (SCTP) connection with an E2 node, start a release timer in response to detecting the release, and remove a configuration for the E2 node in response to expiration of the release timer.

[0015] According to another embodiment of the present disclosure, there is provided an apparatus performed by a Near-RT (real time) RAN (radio access network) intelligent controller (RIC). The apparatus may include at least one transceiver and at least one processor, wherein the at least one processor may be configured to detect a release of a stream control transmission protocol (SCTP) connection with an E2 node, transmit a message to a Service Management and Orchestration (SMO) via an O1 interface to inquire about a status of the E2 node in response to the detection of the release, receive a response message regarding the status of the E2 node from the SMO via the O1 interface, and, if the response message indicates completion of termination of the E2 node, remove a configuration for the E2 node in the Near-RT RIC.

[0016] According to another embodiment of the present disclosure, there is provided an apparatus performed by a Near-RT (real time) RAN (radio access network) intelligent controller (RIC). The apparatus includes at least one transceiver and at least one processor, and the at least one processor may be configured to receive a configuration message for termination of an E2 node connected to the Near-RT RIC from a Service Management and Orchestration (SMO) via an O1 interface, and to remove a configuration for the E2 node in the Near-RT RIC in response to the configuration message. [Effects of the Invention]

[0017] The apparatus and method according to the embodiments of the present disclosure enable the near-real-time (NRT) radio access network intelligent controller (RAN) RIC to function effectively by removing E2 node-related configurations in the NRT RIC when the E2 node is terminated. The apparatus and method according to the embodiments of the present disclosure allows the E2 node to operate efficiently by removing the NRT RIC-related settings in the E2 node when the NRT RIC is terminated. Other embodiments, advantages and distinctive features of the present disclosure can become apparent to those skilled in the art from the following detailed description, taken in conjunction with the accompanying drawings, which disclose various embodiments of the present disclosure. [Brief explanation of the drawings]

[0018] These and other embodiments, features, and advantages of particular embodiments of the present disclosure will become more apparent from the following description taken in conjunction with the accompanying drawings, in which: [Figure 1] 1 is a diagram illustrating an example of a 4th generation (4G) Long Term Evolution (LTE) core system according to one embodiment of the present disclosure. [Figure 2A] FIG. 1 is a diagram illustrating an example of a 5G (5th generation) NSA (non-standard alone) system according to one embodiment of the present disclosure. [Figure 2B] FIG. 1 illustrates an example architecture for O-RAN according to one embodiment of the present disclosure. [Figure 3] FIG. 2 illustrates a protocol stack of an E2 application protocol message in a radio access network according to one embodiment of the present disclosure. [Figure 4] FIG. 2 illustrates an example of a connection between a base station and a radio access network intelligence controller (RIC) in a radio access network according to one embodiment of the present disclosure. [Figure 5] FIG. 1 is a diagram illustrating a configuration of devices in a radio access network according to an embodiment of the present disclosure. [Figure 6A] FIG. 2 illustrates logical functions associated with E2 messages of an E2 node and a RIC in a radio access network according to one embodiment of the present disclosure. [Figure 6B] FIG. 2 illustrates logical functions associated with E2 messages of an E2 node and a RIC in a radio access network according to one embodiment of the present disclosure. [Figure 7] FIG. 1 illustrates an example of functional separation between an E2 node and a RIC according to one embodiment of the present disclosure. [Figure 8A] FIG. 1 illustrates an example implementation of an E2 node and a RIC according to an embodiment of the present disclosure. [Figure 8B] FIG. 1 illustrates interfaces between O-RAN components according to one embodiment of the present disclosure. [Figure 8C] FIG. 1 illustrates an example SMO framework according to one embodiment of the present disclosure. [Figure 9] FIG. 10 is a diagram for explaining the necessity of removing E2 interface-related information according to an embodiment of the present disclosure. [Figure 10A] FIG. 1 illustrates an embodiment of signaling between O-RAN entities for E2 node removal according to one embodiment of the present disclosure. [Figure 10B] FIG. 10 illustrates another embodiment of signaling between O-RAN entities for E2 node removal according to an embodiment of the present disclosure. [Figure 10C] FIG. 10 illustrates yet another embodiment of signaling between O-RAN entities for E2 node removal according to an embodiment of the present disclosure. [Figure 10D] 1 illustrates yet another embodiment of signaling between O-RAN entities for E2 node removal according to an embodiment of the present disclosure. It should be noted that throughout the drawings, the same reference numerals are used to depict the same or similar elements, features, and structures. DETAILED DESCRIPTION OF THE INVENTION

[0019] The following description, with reference to the accompanying drawings, is provided to facilitate a comprehensive understanding of various embodiments of the present disclosure, as defined by the claims and their equivalents. Although various specific details are included herein to facilitate understanding, these details should be considered merely as examples. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the various embodiments described herein without departing from the scope and spirit of the present disclosure. Furthermore, for the sake of clarity and conciseness, descriptions of well-known functions and configurations may be omitted.

[0020] The terms and phrases used in the following description and claims are not limited to their literary meanings, but are merely used by the inventor to enable a clear and consistent understanding of the present invention. Therefore, it should be apparent to those skilled in the art that the following description of various embodiments of the present invention is provided for illustrative purposes only, and not for the purpose of limiting the present invention as defined by the appended claims and their equivalents.

[0021] The singular forms "a," "an," and "the" should be understood to include plural referents unless the context clearly dictates otherwise. Thus, for example, reference to a "component surface" includes a reference to one or more of such surfaces.

[0022] In the various embodiments of the present disclosure described below, a hardware approach is described as an example, but the various embodiments of the present disclosure include techniques that use both hardware and software, and therefore the various embodiments of the present disclosure do not exclude a software-based approach.

[0023] The present disclosure relates to devices in a radio access network (RAN) in a wireless communication system and to an inter-device control procedure for controlling the RAN. Specifically, the present disclosure relates to a procedure, message, and method for a RIC to transmit a RIC control request message to an E2 node over an E2 interface in a radio access network, and for the E2 node to confirm whether the RIC control request was successful or failed, and if so, the reason for the failure.

[0024] Terms used in the following description, such as terms referring to signals, channels, control information, network entities, and device components, are provided for convenience of explanation. Therefore, the present disclosure is not limited to the terms used below, and other terms having equivalent technical meanings may be used.

[0025] Furthermore, in this disclosure, expressions such as "more than" or "less than" may be used to determine whether a particular condition is satisfied or fulfilled, but this is merely a description to express an example and does not exclude the descriptions "more than" or "less than." A condition described as "more than" may be replaced with "more than," a condition described as "less than," and a condition described as "more than and less than" may be replaced with "more than and less than."

[0026] Although the present disclosure describes various embodiments using terminology used in some communication standards (e.g., 3GPP (3rd Generation Partnership Project) and O-RAN (open radio access network)), this is merely an example for the purpose of explanation. Various embodiments of the present disclosure may be easily modified and applied to other communication systems.

[0027] 4th generation (4 th generation, 4G) / 5th generation (5 thWith the commercialization of 5G (5th generation) communication systems (e.g., new radio (NR)), users are demanding differentiated service support in virtualized networks. 3GPP is a collaborative research project among mobile communications organizations, and its goal is to create globally applicable third-generation mobile communication system standards within the scope of the International Telecommunication Union (ITU) IMT-2000 project. Established in December 1998, 3GPP standards are based on the advanced global system for mobile communications (GSM) standards and include radio, core network, and service architecture within the scope of standardization. Therefore, the open radio access network (O-RAN) newly defines the nodes constituting the 3GPP network entity (NE) and base station, namely the radio unit (RU), digital unit (DU), central unit (CU)-control plane (CP), and user plane (CU-UP), as O (O-RAN)-RU, O-DU, O-CU-CP, and O-CU-UP, respectively, and also standardizes the near-real-time (NRT) radio access network intelligent controller (RIC). This disclosure is intended to support an operator-specific service model over the E2 interface where the RIC requests services from the O-DU, O-CU-CP, or O-CU-UP. Here, the O-RU, O-DU, O-CU-CP, and O-CU-UP can be understood as objects constituting a RAN capable of operating in accordance with the O-RAN standard and can be referred to as E2 nodes. The interface between the RIC and the E2 node and the objects constituting the RAN that can operate according to the O-RAN standard uses E2AP (E2 application protocol (AP)).

[0028] The RIC is a logical node that can collect information at a cell site between a terminal and an O-DU, O-CU-CP, or O-CU-UP. The RIC can be implemented as a server centralized in one physical location. The O-DU and RIC, the O-CU-CP and RIC, and the O-CU-UP and RIC can be connected via Ethernet. Therefore, interface standards for communication between the O-DU and RIC, the O-CU-CP and RIC, and the O-CU-UP and RIC are required. Message standards for E2-DU, E2-CU-CP, and E2-CU-UP, as well as procedures between the O-DU, O-CU-CP, O-CU-UP, and RIC are also required. In particular, differentiated service support is required for users in virtualized networks. Therefore, functional definitions for E2-DU, E2-CU-CP, and E2-CU-UP messages are required to support services over a wide cell coverage area by concentrating call processing messages / functions generated in the O-RAN in the RIC.

[0029] The RIC communicates with the O-DU, O-CU-CP, and O-CU-UP using the E2 interface and can set event conditions by generating and sending subscription messages. Specifically, the RIC can set a call processing event by generating an E2 subscription request message and transmitting it to an E2 node (e.g., O-CU-CP, O-CU-UP, or O-DU). After the event is set, the E2 node transmits a subscription request response message to the RIC.

[0030] An E2 node can transmit its current status to the RIC via an E2 indication / report. The RIC can provide control over the O-DU, O-CU-CP, and O-CU-UP using an E2 control message. Various embodiments of the present disclosure propose an E2 indication message in which measurement information per UE is transmitted at intervals set in a subscription event condition in the O-DU. Various embodiments of the present disclosure also propose a message for controlling resources transmitted from the RIC to the O-DU.

[0031] FIG. 1 illustrates a 4G (4G) network according to one embodiment of the present disclosure. th generation) LTE (Long Term Evolution) core system.

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

[0033] The base station 110 is a network infrastructure that provides wireless connectivity to the terminal 120. For example, the base station 110 is a device that performs scheduling by aggregating status information such as buffer status, available transmission power, and channel status. The base station 110 has coverage defined in a predetermined geographical area based on the distance over which a signal can be transmitted. The base station 110 is connected to the MME 150 via an S1-MME interface. In addition to being called a base station, the base station 110 may also be called an "access point (AP)," "evolved Node B (eNodeB, eNB)," "wireless point," "transmission / reception point (TRP)," or other terms with equivalent technical meanings.

[0034] Terminal 120 is a device used by a user and communicates with base station 110 via a wireless channel. In some cases, terminal 120 may be operated without user involvement. That is, at least one of terminal 120 and terminal 130 may be a device that performs machine-type communication (MTC) and is not carried by a user. Terminal 120 may also be referred to as a "user equipment (UE)," a "mobile station (MS)," a "subscriber station," a "customer-premises equipment (CPE)," a "remote terminal," a "wireless terminal," or a "user device," or other terms with equivalent technical meanings.

[0035] The S-GW 130 provides a data bearer and generates or controls the data bearer under the control of the MME 150. For example, the S-GW 130 processes packets arriving from the base station 110 or packets to be forwarded to the base station 110. The S-GW 130 can also act as an anchor during inter-base station handover of the terminal 120. The P-GW 140 can function as a connection point with an external network (e.g., the Internet network). The P-GW 140 can also assign an Internet Protocol (IP) address to the terminal 120 and act as an anchor for the S-GW 130. The P-GW 140 can also apply a Quality of Service (QoS) policy to the terminal 120 and manage account data.

[0036] The MME 150 manages the mobility of the terminal 120. The MME 150 can also perform authentication and bearer management for the terminal 120. That is, the MME 150 is responsible for mobility management and various control functions for the terminal. The MME 150 can interface with an SGSN (serving general packet radio service (GPRS) support node).

[0037] The HSS 160 stores key information and a subscriber profile for authentication of the terminal 120. The key information and the subscriber profile are transferred from the HSS 160 to the MME 150 when the terminal 120 connects to the network.

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

[0039] Carrier aggregation (hereinafter referred to as "CA") technology is a technology that increases frequency utilization efficiency from the perspective of a terminal or a base station by combining multiple component carriers and allowing one terminal to transmit and receive signals using these multiple component carriers simultaneously. Specifically, with CA technology, a terminal and a base station can transmit and receive wideband signals using multiple component carriers in the uplink (UL) and downlink (DL), respectively, where each component carrier is located in a different frequency band. Hereinafter, uplink refers to a communication link through which a terminal transmits signals to a base station, and downlink refers to a communication link through which a base station transmits signals to a terminal. Herein, the number of uplink component carriers and downlink component carriers may differ.

[0040] Dual / multi-connectivity technology (dual connectivity or multi-connectivity) is a technology that increases frequency usage efficiency from the perspective of a terminal or base station by connecting a terminal to multiple different base stations and simultaneously transmitting and receiving signals using carriers within each of the multiple base stations located in different frequency bands. A terminal connects a first base station (e.g., a base station that provides services using LTE technology or 4th generation mobile communication technology) and a second base station (e.g., a base station that provides services using NR (new radio) technology or 5G (5G) technology). th It can simultaneously connect to multiple base stations (base stations that provide services using 5G (LTE) generation mobile communication technology) to send and receive traffic. In this case, the frequency resources used by each base station may be located in different bands. This method of operating based on the dual connectivity method of LTE and NR can be called 5G NSA (non-standalone).

[0041] FIG. 2A illustrates an example of a 5G NSA system according to one embodiment of the present disclosure.

[0042] Referring to FIG. 2A, the 5G NSA system includes an NR RAN 210a, an LTE RAN 210b, a terminal 220, and an evolved packet core (EPC) 250. The NR RAN 210a and the LTE RAN 210b are connected to the EPC 250, and the terminal 220 can receive service from either the NR RAN 210a or the LTE RAN 210b simultaneously. The NR RAN 210a includes at least one NR base station, and the LTE RAN 210b includes at least one LTE base station. Here, the NR base station may be referred to as a "5th generation node," a "next generation nodeB (gNB)," or other terms having an equivalent technical meaning. The NR base station may have a structure separated into a central unit (CU) and a digital unit (DU), and the CU may have a structure separated into a CU-control plane (CP) unit and a CU-user plane (UP) unit.

[0043] In the structure shown in FIG. 2A , the terminal 220 performs radio resource control (RRC) connection through a first base station (e.g., a base station belonging to the LTE RAN 210b) and may be served with functions (e.g., connection management, mobility management, etc.) provided by a control plane. The terminal 220 may also be provided with additional radio resources for transmitting and receiving data through a second base station (e.g., a base station belonging to the NR RAN 210a). This dual connectivity technology using LTE and NR may be referred to as EN-DC (evolved universal terrestrial radio access (E-UTRA) - NR dual connectivity). Similarly, a dual connectivity technology in which the first base station uses NR technology and the second base station uses LTE technology is referred to as NE-DC (NR - E-UTRA dual connectivity). Various embodiments may also be applied to various other types of multi-connectivity and carrier aggregation technologies. In addition, various embodiments may also be applied when a first system using a first communication technology and a second system using a second communication technology are implemented in one device, or when a first base station and a second base station are located in the same geographical location.

[0044] 2B illustrates an example architecture for O-RAN according to one embodiment of the present disclosure. For purposes of E2-SM-KPIMON (key performance indicator monitoring) of the E2 service model, the E2 node may be assumed to be in O-RAN Stand Alone mode, while O-RAN Non-Stand Alone mode within multi-connectivity operation using E-UTRA and NR radio access technologies is considered.

[0045] Referring to Figure 2B, in an O-RAN non-standalone mode deployment, the eNB is connected to the EPC via the S1-C / S1-U interface and to the O-CU-CP via the X2 interface. The O-CU-CP for an O-RAN standalone mode deployment can be connected to the 5GC (5G core) via the N2 / N3 interface.

[0046] 3 illustrates a protocol stack for E2 application protocol messages in a radio access network according to one embodiment of the present disclosure. Referring to FIG. 3, the control plane includes a transport network layer and a radio network layer. The transport network layer includes a physical layer 310, a data link layer 320, an internet protocol (IP) 330, and a stream control transmission protocol (SCTP) 340.

[0047] The wireless network layer includes the E2AP 350. The E2AP 350 is used to transmit subscription messages, indication messages, control messages, service update messages, and service query messages, and is transmitted at a higher layer than the SCTP 340 and IP 330.

[0048] FIG. 4 illustrates an example of a connection between a base station and a radio access network intelligence controller (RIC) in a radio access network according to one embodiment of the present disclosure.

[0049] Referring to Figure 4, the RIC 440 is connected to the O-CU-CP 420, O-CU-UP 410, and O-DU 430. The RIC 440 is a device for customizing RAN functionality for new services or regional resource optimization. The RIC 440 can provide functions such as network intelligence (e.g., policy enforcement, handover optimization), resource assurance (e.g., radio-link management, advanced self-organized network (SON)), and resource control (e.g., load balancing, slicing policy). The RIC 440 can communicate with the O-CU-CP 420, O-CU-UP 410, and O-DU 430. The RIC 440 can connect to each node via the E2-CP, E2-UP, and E2-DU interfaces. In addition, the interfaces between the O-CU-CP and the DU, and between the O-CU-UP and the DU can be referred to as F1 interfaces. In the following description, the terms DU and O-DU, CU-CP and O-CU-CP, and CU-UP and O-CU-UP can be used interchangeably.

[0050] 4 illustrates one RIC 440, there may be multiple RICs according to various embodiments, which may be implemented on multiple pieces of hardware located in the same physical location or may be implemented by virtualization using a single piece of hardware.

[0051] Figure 5 shows the configuration of an apparatus according to one embodiment of the present disclosure. The structure illustrated in Figure 5 can be understood as the configuration of an apparatus having at least one function of the Near-RT RIC, non-RT RIC, O-CU-CP, O-CU-UP, and O-DU of Figure 5. Terms such as "module" and "device" used below refer to a unit that processes at least one function or operation, and can be implemented in hardware, software, or a combination of hardware and software.

[0052] Referring to FIG. 5, the core network device includes a communication unit 510, a storage unit 520, and a control unit 530.

[0053] The communication unit 510 provides an interface for communicating with other devices in the network. That is, the communication unit 510 converts bit streams transmitted from the core network device to other devices into physical signals, and converts physical signals received from other devices into bit streams. That is, the communication unit 510 can transmit and receive signals. Therefore, the communication unit 510 can be referred to as a modem, transmitter, receiver, or transceiver. In this regard, the communication unit 510 enables the core network device to communicate with other devices or systems via a backhaul connection (e.g., wired backhaul or wireless backhaul) or via a network.

[0054] The memory unit 520 stores data such as basic programs, application programs, and configuration information for the operation of the core network device. The memory unit 520 may be configured as a volatile memory, a non-volatile memory, or a combination of a volatile memory and a non-volatile memory. The memory unit 520 provides the stored data in response to a request from the control unit 530.

[0055] The controller 530 controls the overall operation of the core network device. For example, the controller 530 transmits and receives signals via the communication unit 510. The controller 530 also stores and reads data in the memory unit 520. To this end, the controller 530 may include at least one processor. According to various embodiments, the controller 530 may control the device to perform operations according to various embodiments described in this disclosure.

[0056] 6A and 6B illustrate logical functions associated with E2 messages of an E2 node and a RIC in a radio access network according to one embodiment of the present disclosure.

[0057] 6A , the RIC 640 and an E2 node 610 can transmit or receive E2 messages to or from each other. For example, the E2 node 610 can be an O-CU-CP, an O-CU-UP, an O-DU, or a base station. The communication interface of the E2 node can be determined by the type of the E2 node 610. For example, the E2 node 610 can communicate with another E2 node 616 via an E1 interface or an F1 interface. Alternatively, for example, the E2 node 610 can communicate with an E2 node 616 via an X2 interface or an XN interface. Alternatively, for example, the E2 node 610 can communicate via an S1 interface or a next generation application protocol (NGAP) interface (i.e., an interface between a next generation (NG) RAN node and an access and mobility function (AMF)).

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

[0059] The E2 termination 642 located in the RIC 640 is the termination of the RIC 640 for the E2 message, and performs the function of analyzing the E2 message transmitted by the E2 node 610 and transmitting it to the xApp 646. A DB (database) 644 located in the RIC 640 can be used for the E2 termination 624 or the xApp 616. The E2 node 610 shown in FIG. 6A is the termination of at least one interface and can be understood as the termination of messages transmitted to a terminal, a neighboring base station, and a core network.

[0060] Referring to FIG. 6B, an xAPP in the RIC 640 can correspond to one or more E2 node functions in the E2 node 610. The E2 node functions in the E2 node 610 can correspond to one or more xAPPs in the RIC 640. The E2 node functions in the E2 node 610 can be managed by an E2 agent. The RIC 640 connected to the E2 node 610 via the E2 interface is referred to as a Near-RT RIC. The Near-RT RIC can control and optimize the functions and resources of the E2 nodes (O-CU-CP, O-CU-UP, O-DU, and O-eNB) in real time, i.e., near-RT, through data collection and control operations via the E2 interface in units of approximately 10 ms (milliseconds) to 1 second. The RIC 640 can host one or more xApps that collect near-RT information (UE-based or cell-based) and provide services using the E2 interface. Near-RT RIC control over the E2 node may be adjusted based on policy and enrichment data provided by the non-RT RIC via A1. The RRM function 614 between the Near-RT RIC 640 and the E2 node 610 is provided by the interaction of the E2 node's functions exposed on the E2 interface via the E2 Service Model (E2SM).

[0061] FIG. 7 illustrates an example of functional separation between an E2 node and a RIC according to one embodiment of the present disclosure. The O-RAN standard provides functional separation between the E2 node and the RIC. For example, the E2 node may be a CU. The RIC may be a Near-RT RIC. The RIC may be connected to an ONAP (open network automation platform), a MANO (management and orchestration), or an NMS (network management system) via an A1 interface. The RIC may be connected to an E2 node via an E2 interface. The E2 interface can transmit commands. Functional separation options include functional separation 700, in which the near-RT RIC manages all of the radio resource management (RRM), and functional separation 750, in which the near-RT RIC manages RRM selectively.

[0062] The Near-RT RIC is intended to support E2 with an open logical interface targeting a multi-vendor environment, regardless of the implementation of specific RRC-RRM algorithms located in the near-RT-RIC. In this disclosure, we propose an E2SM-RIC (E2 Service Model Radio Interface Control) paired with an E2SM-NI that can inject / modify / configure per-UE RRC messages for each I / F and NE (network entity). In other words, the Near-RT RIC can be improved gradually from function separation 750 toward function separation 700. The E2 can evolve into an open logical interface targeting a multi-vendor environment, independent of the implementation of specific RRC-RRM algorithms located in the near-RT-RIC.

[0063] FIG. 8A illustrates an example implementation of an E2 node and a RIC according to one embodiment of the present disclosure. In the example implementation scenario 800, the E2 node (e.g., O-DU, O-CU) and the RIC can be virtualized and configured as devices (e.g., servers) on a cloud platform (e.g., an edge cloud with open chassis and blades). Such a scenario can support distribution in dense urban areas with abundant fronthaul capacity that allows BBU functions to be pooled at a central location with latency low enough to meet O-DU latency requirements. This eliminates the need to centralize RICs closer to the RT than the O-DU functions can be centralized. According to one embodiment, the E2SM-RIC can be optimized for an O-RAN distribution scenario in which the Near-RT RIC, O-CU, and O-DU are implemented on an O-Cloud Platform.

[0064] FIG. 8B illustrates interfaces between O-RAN components according to one embodiment of the present disclosure. FIG. 8 illustrates the logical architecture of the O-RAN. A Service Management and Orchestration (SMO) framework can be connected to an O-RAN network function (NF) and the O-Cloud via major interfaces used in the O-RAN, such as the A1 interface, the O1 interface, and the O2 interface. According to one embodiment, the O-RAN NF can be a virtualized network function (VNF) on the O-Cloud. According to one embodiment, the O-RAN NF can be in the form of a containerized network function (CNF). According to one embodiment, the O-RAN NF can be a physical network function (PNF) utilizing custom hardware.

[0065] The SMO is responsible for RAN domain management and orchestration functions. The main functions of the SMO that provide RAN support in O-RAN include the FCAPS (Fault, Configuration, Alarms, Performance and Security) interface to O-RAN NFs, the Non-RT RIC (Non-Real time RAN Intelligent controller) framework for RAN optimization, and O-Cloud management, orchestration, and workflow management functions.

[0066] The Non-RT RIC is an internal function of the SMO in the O-RAN architecture that provides an A1 interface to the Near-RT RIC (Near-Real Time RAN Intelligent Controller). The main goal of the Non-RT RIC is to support intelligent RAN optimization by providing policy-based guidance, ML model management, and enrichment information to the Near-RT RIC so that the RAN can optimize RRM under specific conditions. The Non-RT RIC can perform RAN optimization work at non-real-time (1 second or more) intervals by using data analysis, AI (Artificial Intelligence) / ML (Machine Learning) training, and inference.

[0067] FIG. 8C illustrates an example of an SMO framework according to one embodiment of the present disclosure.

[0068] 8C and diagram 860, the Non-RT RIC may include a UE IMF (Identity Management Function). In this disclosure, the term UE IMF is used, but other terms referring to the corresponding functional configuration may be used instead. For example, the Non-RT RIC may be understood to perform the functions (or operations) of the UE IMF, such as a UE identifier management unit, UE identifier control unit, UE management unit, UE control unit, UE identity control unit, and UE identity verification unit, which will be described later.

[0069] According to embodiments of the present disclosure, a Non-RT RIC can communicate with an SMO via an SMO internal interface. According to embodiments of the present disclosure, a Non-RT RIC can communicate with an external source via an external interface. According to one embodiment, a Non-RT RIC can communicate with an External EI (enrichment information) source via an External EI interface. According to one embodiment, a Non-RT RIC can communicate with an External AI (artificial intelligence) / ML (machine learning) interface. According to one embodiment, a Non-RT RIC can communicate with a local craft terminal via an External HM (human machine) interface.

[0070] O-RAN brings openness, agility, and scalability to the RAN. For RAN evolution, O-RAN enables support for open and interoperable interfaces, RAN virtualization, big data, and AI-supported RAN intelligence. It also maximizes the use of commercial hardware and silicon and discourages the use of dedicated hardware. Embedded or back-end artificial intelligence (AI) / machine learning (ML) systems provide network intelligence through near real-time (NRT) and non-real-time (NRT) analytics. O-RAN makes it possible to create a virtualized intelligent network with standardized open interfaces.

[0071] In O-RAN, the interface between the Near-RT RIC and the E2 node is defined as the E2 interface. The radio network layer in the E2 interface uses the E2AP protocol. The E2AP procedure consists of the E2AP Near-RT RIC functional procedure and the E2AP Global procedure. The E2AP Near-RT RIC functional procedure can be used to transmit application-specific messages between xApp (Near-RT RIC applications) and the target function of the E2 node. The E2AP Global procedure can be used for E2 interface management, service updates, etc.

[0072] The elementary procedures for E2AP can be divided into Class 1 and Class 2 elementary procedures, which are described below. Table 1 shows the Class 1 elementary procedures, and Table 2 shows the Class 2 elementary procedures.

[0073] [Table 1] [Table 2]

[0074] FIG. 9 is a diagram illustrating the need for removing E2 interface-related information according to one embodiment of the present disclosure. FIG. 9 describes the termination process of an E2 node. The following diagram illustrates the termination process of an E2 node. The E2 termination process can be used to reduce resource waste due to excessive deployment of E2 nodes. Alternatively, the E2 termination process is a procedure required to remove an old version E2 node using a build-and-replace S / W upgrade method. SMO exemplifies the SMO 810 in FIG. 8. O-cloud exemplifies a controller for controlling the O-cloud 815 in FIG. 8. Near-RT RIC exemplifies the Near-RT RIC 640 in FIG. 6. E2 node exemplifies the E2 node 610 in FIG. 6.

[0075] 9, in operation S901, the SMO may decide to remove the E2 node, and may generate a configuration for removing the E2 node.

[0076] In operation S903, the SMO can transmit configuration information for the termination of the E2 node to the E2 node via the O1 interface. When the SMO determines the termination of a specific E2 node, it can transmit the configuration information for the termination to the corresponding E2 node. The E2 node can receive the configuration information for the termination of the E2 node from the SMO via the O1 interface.

[0077] In operation S905, the E2 node can suspend ongoing traffic (or service). That is, the E2 node can suspend the traffic currently being served or suspend the service. The E2 node can suspend traffic or service based on the configuration information received in operation S903. For example, the E2 node can suspend transmission of data traffic. The E2 node can suspend transmission of traffic when it receives configuration information for terminating the E2 node.

[0078] In operation S907, the E2 node may transmit a message confirming (or notifying) the termination (hereinafter, a termination confirmation message) to the SMO. The E2 node may transmit the termination confirmation message to the SMO via the O1 interface. The SMO may receive the termination confirmation message from the E2 node. Although FIG. 9 describes the confirmation message being sent after operation S905, in some embodiments, the confirmation message may be sent immediately after operation S903.

[0079] In operation S909, the SMO can transmit a message for terminating the E2 node to the O-Cloud. The SMO can transmit a message for terminating the E2 node to the O-Cloud via the O2 interface. The message for terminating the E2 node can mean a message for releasing the resources of the E2 node. When the SMO receives a service or traffic interruption confirmation message from the E2 node, the SMO can transmit a message for releasing the resources of the E2 node to the O-Cloud. The O-Cloud can receive a message for releasing the resources of the E2 node from the SMO.

[0080] In operation S911, the O-Cloud may transmit a message to the E2 node to deallocate resources. According to one embodiment, the O-Cloud may notify the E2 node of the resource deallocation via an application.

[0081] In operation S913, O-Cloud can transmit a message to SMO notifying that the termination of E2 node is complete. Completion of the termination of E2 node means that all resources allocated to E2 node are released. In other words, O-Cloud can release all resources of E2 node and transmit a completion message to SMO.

[0082] In operation S915, the E2 node can release all resources. The E2 node can release all resources based on the resource deallocation of the O-Cloud. Since the E2 node can identify the termination of the E2 node via the SMO and the O-Cloud, the E2 node can perform procedures due to the termination of the E2 node (e.g., deleting the E2 interface-related settings).

[0083] In operation S917, the Near-RT RIC can maintain related information and E2 interface instances. The Near-RT RIC cannot know whether the E2 node has terminated. Therefore, even if the E2 node is terminated, the Near-RT RIC continues to maintain deleted E2 node related information (e.g., Global E2 node ID, RAN Function info, E2 node component configuration, and soon) and E2 interfaces (e.g., SCTP connections). Although not shown in Figure 9, the E2 node also continues to maintain Near-RT RIC related information and E2 interfaces in the reverse case (e.g., when the Near-RT RIC is removed).

[0084] Maintaining E2 interface-related settings (e.g., E2 node-related information, Near-RT RIC-related information, or E2 interface settings) not only wastes resources but also may cause the continued collection of incorrect information, which may disrupt the functionality of each node. For example, topology information may provide incorrect results because it reflects data about a terminated E2 node. Also, for example, if a terminated E2 node later reconnects, an error may occur because the settings for that E2 node are duplicated in the Near-RT RIC.

[0085] To solve the above-mentioned problems, an embodiment of the present disclosure proposes a method for deleting (or releasing) relevant information, an E2 interface, etc. stored in a Near-RT RIC and an E2 node when the E2 interface between the Near-RT RIC and the E2 node is disconnected in an O-RAN (Open RAN)-based mobile communication system. According to one embodiment, the present disclosure proposes a method for properly deleting relevant information, an E2 interface instance (e.g., SCTP), etc. of the E2 node in the Near-RT RIC when the E2 node is terminated. Also, according to one embodiment, the present disclosure proposes a method for properly deleting relevant information, an E2 interface instance (e.g., SCTP), etc. of the Near-RT RIC in the E2 node when the Near-RT RIC is terminated, similarly in the reverse case.

[0086] Hereinafter, the removed information may be referred to as E2 interface related information. According to one embodiment, the E2 interface related information may include related settings of the E2 node. According to one embodiment, the E2 interface related information may include related settings of the Near-RT RIC. According to one embodiment, the E2 interface related information may include related settings of the E2 interface (e.g., SCTP).

[0087] As a first proposal of the present disclosure, an explicit E2AP message exchange procedure (e.g., E2 Removal Request message and E2 Removal response message) may be defined between the E2 node and the Near-RT RIC. According to the E2AP message exchange procedure, E2 interface-related information may be removed. Specific operations according to the first proposal will be described later with reference to FIG. 10A.

[0088] In a second aspect of the present disclosure, a release timer may be defined after the SCTP connection between the E2 node and the Near-RT RIC is released. When the release timer expires, the E2 interface-related information may be removed. Specific operations according to the second aspect will be described later with reference to FIG. 10B.

[0089] As a third alternative of the present disclosure, an SMO inquiry procedure may be defined after the SCTP connection between the E2 node and the Near-RT RIC is released. The SMO inquiry procedure may include sending an inquiry and receiving a response by the E2 node or the Near-RT RIC. E2 interface-related information may be removed based on the response to the SMO inquiry procedure. Specific operations according to the third alternative will be described below with reference to FIG. 10C.

[0090] As a third option of the present disclosure, explicit configuration by the SMO can be defined. Based on the configuration information transmitted via the O1 interface of the SMO, information related to the E2 interface can be removed. Specific operations according to the fourth option will be described later with reference to FIG. 10D.

[0091] 10A illustrates an embodiment of signaling between O-RAN entities for E2 node removal according to one embodiment of the present disclosure, in which an associated information removal method is illustrated by an explicit E2AP message exchange method (E2 Removal Request / response) between the E2 node and the Near-RT RIC.

[0092] 10A, in operation S1001, the SMO may determine to remove the E2 node, and may generate a configuration for removing the E2 node.

[0093] In operation S1003, the SMO can transmit configuration information for the termination of the E2 node to the E2 node via the O1 interface. When the SMO determines the termination of a specific E2 node, it can transmit the configuration information for the termination to the corresponding E2 node. The E2 node can receive the configuration information for the termination of the E2 node from the SMO via the O1 interface.

[0094] In operation S1005, the E2 node can transmit an E2 Removal Request message to the Near-RT RIC. The E2 node can transmit the E2 Removal Request to the Near-RT RIC via the E2 interface. According to one embodiment, an E2AP message for an E2 node removal request can be defined on the E2 interface (e.g., as additionally defined in Table 1 or Table 2). When the E2 node receives configuration information for termination from the SMO, the E2 node can explicitly convey an E2 Removal Request message to the Near-RT RIC via the E2 interface. The Near-RT RIC can receive the E2 Removal Request message from the E2 node.

[0095] According to one embodiment, the E2 removal request message may include an E2 node ID (identifier). The E2 node may notify the Near-RT RIC of the E2 node ID to be terminated. Also, according to one embodiment, the E2 removal request message may include settings related to E2 node termination. The E2 node may additionally generate the E2 removal request message based on the setting information received in operation S1003. According to one embodiment, the E2 removal response message may include a RIC node ID. Also, according to one embodiment, the E2 removal response message may indicate confirmation of the removal result.

[0096] In operation S1007, the Near-RT RIC can transmit an E2 Removal Response message to the E2 node. According to one embodiment, an E2AP message for E2 node removal request can be defined on the E2 interface. The E2 node can receive the E2 Removal Response message from the Near-RT RIC. After receiving the E2 Removal Request message, the Near-RT RIC can respond with an E2 Removal Response message and then delete information associated with the E2 node. In addition, the Near-RT RIC can remove the E2 interface instance (e.g., SCTP connection) to the E2 node in operation S1009. The E2 node can receive the E2 Removal Request message from the Near-RT RIC.

[0097] In operation S1011, the E2 node can delete E2 interface-related information. The E2 interface-related information can include Near-RT-related settings and E2 interface instance settings connected via the E2 interface. After receiving the E2 Removal Response message, the E2 node can delete the E2 interface instance. The E2 node can also suspend ongoing traffic (or service). That is, the E2 node can suspend the traffic currently being served or suspend the service. For example, the E2 node can suspend transmission of data traffic. The E2 node can suspend transmission of traffic when it receives configuration information for terminating the E2 node.

[0098] Thereafter, in operation S1013, the E2 node can transmit a message confirming (or notifying) the termination (hereinafter, a termination confirmation message) to the SMO. The E2 node can transmit the termination confirmation message to the SMO via the O1 interface. The SMO can receive the termination confirmation message from the E2 node.

[0099] In operation S1015, the SMO can transmit a message for terminating the E2 node to the O-Cloud. The SMO can transmit a message for terminating the E2 node to the O-Cloud via the O2 interface. The message for terminating the E2 node can mean a message for releasing the resources of the E2 node. When the SMO receives a service or traffic interruption confirmation message from the E2 node, the SMO can transmit a message for releasing the resources of the E2 node to the O-Cloud. The O-Cloud can receive a message for releasing the resources of the E2 node from the SMO.

[0100] In operation S1017, the O-Cloud may transmit a message to the E2 node to deallocate resources. According to one embodiment, the O-Cloud may notify the E2 node of the resource deallocation via an application.

[0101] In operation S1019, O-Cloud can transmit a message to SMO notifying that the termination of E2 node is complete. Completion of the termination of E2 node means that all resources allocated to E2 node are released. In other words, O-Cloud can release all resources of E2 node and transmit a completion message to SMO.

[0102] In operation S1021, the E2 node can release all resources. The E2 node can release all resources based on the resource deallocation of the O-Cloud. Since the E2 node can identify the termination of the E2 node via the SMO and the O-Cloud, the E2 node can perform procedures due to the termination of the E2 node (e.g., deleting the E2 interface-related settings).

[0103] Unlike Figure 9, the Near-RT RIC knows when the E2 node is terminated, so the Near-RT RIC no longer needs to maintain E2 node-related information (e.g., Global E2 node ID, RAN Function info, E2 node component configuration, etc.) even after the E2 node is terminated. Also, the Near-RT RIC does not maintain E2 interface settings (e.g., SCTP connections), which reduces unnecessary resource consumption.

[0104] Although FIG. 10A describes a method for deleting E2 node-related settings and E2 interface settings in a Near-RT RIC when it is determined that the E2 node is to be terminated, the embodiments of the present disclosure may also be applied to the reverse case. That is, an operation in which Near-RT RIC-related settings and E2 interface settings are deleted in an E2 node when it is determined that the Near-RT RIC is to be terminated may also be understood as an embodiment of the present disclosure. According to one embodiment, when a Near-RT RIC is terminated, the Near-RT RIC may transmit a RIC removal request to the E2 node. The E2 node may transmit a RIC removal response to the Near-RT RIC in response to the RIC removal request. The Near-RT RIC and the E2 node may share each other's termination settings, thereby allowing the E2 interface-related settings to be removed in each node.

[0105] 10A, two steps, a request and a response, are described, but in some embodiments, the last step may be omitted. According to one embodiment, the E2 node can instruct the Near-RT RIC to terminate the E2 node. The Near-RT RIC can delete the E2 node-related settings according to the E2 node's instruction message without a separate response process.

[0106] 10A illustrates that the transmission of the confirmation message by operation S1013 occurs after operation S1011, but the embodiments of the present disclosure are not limited thereto. According to one embodiment, the transmission of the confirmation message by operation S1013 may occur after operation S1007 and before operation S1011. According to one embodiment, the transmission of the confirmation message by operation S1013 may occur after operation S1003.

[0107] 10B illustrates another embodiment of signaling between O-RAN entities for E2 node removal according to one embodiment of the present disclosure, in which a method for removing associated information after the release timer expires after the SCTP connection between the E2 node and the Near-RT RIC is released.

[0108] 10B, in operation S1031, the SMO may determine to remove the E2 node, and may generate a configuration for removing the E2 node.

[0109] In operation S1033, the SMO can transmit configuration information for the termination of the E2 node to the E2 node via the O1 interface. When the SMO determines the termination of a specific E2 node, it can transmit the configuration information for the termination to the corresponding E2 node. The E2 node can receive the configuration information for the termination of the E2 node from the SMO via the O1 interface.

[0110] In operation S1035, the SCTP connection may be terminated. The SCTP connection refers to a transport layer located below the E2AP layer, which is a layer of the wireless network, at the E2 interface. According to one embodiment, when the E2 node receives configuration information for terminating the E2 node from the SMO, the E2 node may perform a procedure (3-way handshake (SHUTDOWN / SHUTDOWN-ACK / SHUTDOWN-COMPLETE)) to terminate the SCTP connection normally with the Near-RT RIC. Alternatively, the SCTP connection may be terminated abnormally.

[0111] In operation S1037, the Near-RT RIC can delete information related to the E2 interface. When the Near-RT RIC detects that the SCTP connection has been normally released or has terminated abnormally, it triggers a release timer. When the release timer expires, i.e., after the release timer has expired, the Near-RT RIC can delete the related information for the corresponding E2 node and the E2 interface instance information. According to one embodiment, the release timer can be predefined in the standard. Also, according to one embodiment, the release timer can be set via the O1 interface or the A1 interface.

[0112] In operation S1039, the E2 node can delete E2 interface-related information. The E2 interface-related information can include Near-RT-related settings and E2 interface instance settings connected via the E2 interface. The E2 node can also suspend ongoing traffic (or service). That is, the E2 node can suspend the traffic currently being served or suspend the service.

[0113] Thereafter, in operation S1041, the E2 node can transmit a message confirming (or notifying) the termination (hereinafter, a termination confirmation message) to the SMO. The E2 node can transmit the termination confirmation message to the SMO via the O1 interface. The SMO can receive the termination confirmation message from the E2 node.

[0114] In operation S1043, the SMO can transmit a message for terminating the E2 node to the O-Cloud. The SMO can transmit a message for terminating the E2 node to the O-Cloud via the O2 interface. The message for terminating the E2 node can mean a message for releasing the resources of the E2 node. When the SMO receives a service or traffic interruption confirmation message from the E2 node, the SMO can transmit a message for releasing the resources of the E2 node to the O-Cloud. The O-Cloud can receive a message for releasing the resources of the E2 node from the SMO.

[0115] In operation S1045, the O-Cloud may transmit a message to the E2 node to deallocate resources. According to one embodiment, the O-Cloud may notify the E2 node of the resource deallocation via an application.

[0116] In operation S1047, O-Cloud can transmit a message to SMO notifying that the termination of the E2 node is complete. Completion of the termination of the E2 node means that all resources allocated to the E2 node have been released. In other words, O-Cloud can release all resources of the E2 node and transmit a completion message to SMO.

[0117] In operation S1049, the E2 node can release all resources. The E2 node can release all resources based on the resource deallocation of the O-Cloud. Since the E2 node can identify the termination of the E2 node via the SMO and the O-Cloud, the E2 node can perform procedures due to the termination of the E2 node (e.g., deleting the E2 interface-related settings).

[0118] Unlike Figure 9, the Near-RT RIC operates a release timer so that once the SCTP connection is released, the Near-RT RIC no longer needs to maintain E2 node-related information (e.g., Global E2 node ID, RAN Function info, E2 node component configuration, etc.). The Near-RT RIC also does not maintain E2 interface settings (e.g., SCTP connections). The release timer ensures that information about one or more E2 nodes associated with the Near-RT RIC is correctly collected, reducing unnecessary resource waste.

[0119] Although FIG. 10B describes a method for deleting E2 node-related settings and E2 interface settings in a Near-RT RIC when a determination is made to terminate the E2 node, embodiments of the present disclosure may also be applied to the reverse case. That is, an operation in which a Near-RT RIC-related setting and E2 interface setting are deleted in an E2 node when a determination is made to terminate the Near-RT RIC may also be understood as an embodiment of the present disclosure. According to one embodiment, the E2 node may start a release timer when the SCTP connection is released. When the release timer expires, the E2 node may remove the Near-RT RIC-related settings and E2 interface instance settings.

[0120] 10B shows that the transmission of the confirmation message by operation S1041 is performed after operation S1039, but the embodiment of the present disclosure is not limited to this. According to one embodiment, the transmission of the confirmation message by operation S1041 may be performed after operation S1037 and before operation S1039. Alternatively, according to one embodiment, the transmission of the confirmation message by operation S1041 may be performed after a predetermined time period of a timer has elapsed after the SCTP connection is released by operation S1033 or operation S1035.

[0121] 10C illustrates yet another embodiment of signaling between O-RAN entities for E2 node removal according to an embodiment of the present disclosure, in which after the SCTP connection between the E2 node and the Near-RT RIC is released, the SMO is queried for the peer node status, and then related information is deleted in response.

[0122] 10C, in operation S1051, the SMO may decide to remove the E2 node, and may generate a configuration for removing the E2 node.

[0123] In operation S1053, the SMO can transmit configuration information for the termination of the E2 node to the E2 node via the O1 interface. When the SMO determines the termination of a specific E2 node, it can transmit the configuration information for the termination to the corresponding E2 node. The E2 node can receive the configuration information for the termination of the E2 node from the SMO via the O1 interface.

[0124] In operation S1055, the SCTP connection may be terminated. The SCTP connection refers to a transport layer located below the E2AP layer, which is a wireless network layer, at the E2 interface. According to one embodiment, when the E2 node receives configuration information for terminating the E2 node from the SMO, the E2 node may perform a procedure (3-way handshake (SHUTDOWN / SHUTDOWN-ACK / SHUTDOWN-COMPLETE)) to normally terminate the SCTP connection with the Near-RT RIC. Alternatively, the SCTP connection may be terminated abnormally.

[0125] In operation S1057, the Near-RT RIC can transmit a message to the SMO to inquire about the status of the E2 node. When the Near-RT RIC detects whether the SCTP connection has been normally terminated or an abnormal termination, it transmits a status query to the SMO indicating whether the corresponding E2 node is proceeding with termination. The query message can be transmitted in response to detecting the termination of the SCTP connection. The Near-RT RIC can transmit the query message to the SMO via the O1 interface. The SMO can receive a message to inquire about the status of the E2 node from the Near-RT RIC.

[0126] In operation S1059, the SMO may transmit a response message including the status of the E2 node to the Near-RT RIC. The Near-RT RIC may receive a response from the SMO that the E2 node is proceeding with termination.

[0127] In operation S1061, the Near-RT RIC can delete E2 interface related information. After the Near-RT RIC receives the response message, the Near-RT RIC can delete related information and E2 interface instance information for the corresponding E2 node.

[0128] In operation S1063, the E2 node can delete E2 interface-related information. The E2 interface-related information can include Near-RT-related settings and E2 interface instance settings connected via the E2 interface. The E2 node can also suspend ongoing traffic (or service). That is, the E2 node can suspend the traffic currently being served or suspend the service.

[0129] Then, in operation S1065, the E2 node can transmit a message confirming (or notifying) the termination (hereinafter, a termination confirmation message) to the SMO. The E2 node can transmit the termination confirmation message to the SMO via the O1 interface. The SMO can receive the termination confirmation message from the E2 node.

[0130] In operation S1067, the SMO can transmit a message for terminating the E2 node to the O-Cloud. The SMO can transmit a message for terminating the E2 node to the O-Cloud via the O2 interface. The message for terminating the E2 node can mean a message for releasing the resources of the E2 node. When the SMO receives a service or traffic interruption confirmation message from the E2 node, the SMO can transmit a message for releasing the resources of the E2 node to the O-Cloud. The O-Cloud can receive a message for releasing the resources of the E2 node from the SMO.

[0131] In operation S1069, the O-Cloud may transmit a message to the E2 node to deallocate resources. According to one embodiment, the O-Cloud may notify the E2 node of the resource deallocation via an application.

[0132] In operation S1071, O-Cloud can transmit a message to SMO notifying that the termination of the E2 node is complete. Completion of the termination of the E2 node means that all resources allocated to the E2 node have been released. In other words, O-Cloud can release all resources of the E2 node and transmit a completion message to SMO.

[0133] In operation S1073, the E2 node can release all resources. The E2 node can release all resources based on the resource deallocation of the O-Cloud. Since the E2 node can identify the termination of the E2 node via SMO and O-Cloud, the E2 node can perform procedures due to the termination of the E2 node (e.g., deleting E2 interface-related settings).

[0134] Unlike Figure 9, the Near-RT RIC directly queries the SMO, so once the SCTP connection is released, the Near-RT RIC no longer needs to maintain E2 node-related information (e.g., Global E2 node ID, RAN Function info, E2 node component configuration, etc.). Also, the Near-RT RIC does not maintain E2 interface settings (e.g., SCTP connection). Through the E2 node termination status query procedure via the O1 interface, information about one or more E2 nodes associated with the Near-RT RIC is correctly collected, reducing unnecessary resource waste.

[0135] Although FIG. 10C describes a method for deleting E2 node-related settings and E2 interface settings in a Near-RT RIC upon determining that the E2 node is to be terminated, embodiments of the present disclosure may also be applied in the reverse case. That is, an operation in which Near-RT RIC-related settings and E2 interface settings are deleted in an E2 node upon determining that the Near-RT RIC is to be terminated may also be understood as an embodiment of the present disclosure. According to one embodiment, when the SCTP connection is released, the E2 node can inquire about the status of the Near-RT RIC from the SMO via the O1 interface. The E2 node can receive a response message from the SMO indicating that the Near-RT RIC is proceeding with termination. In response to the response message, the E2 node can remove Near-RT RIC-related settings and E2 interface instance settings.

[0136] 10C shows that the transmission of the confirmation message by operation S1065 is performed after operation S1063, but the embodiments of the present disclosure are not limited to this. According to one embodiment, the transmission of the confirmation message by operation S1065 may be performed after operation S1061 and before operation S1063. Alternatively, according to one embodiment, the transmission of the confirmation message by operation S1041 may be performed a predetermined time or later after the SCTP connection is released by operation S1053 or operation S1055.

[0137] 10D illustrates yet another embodiment of signaling between O-RAN entities for E2 node removal according to an embodiment of the present disclosure, in which the SMO explicitly communicates information to the E2 node and the Near-RT RIC to delete associated information.

[0138] In operation S1081, the SMO may decide to remove the E2 node, and may generate a configuration for removing the E2 node.

[0139] In operation S1083, the SMO can transmit configuration information for the termination of the E2 node to the E2 node via the O1 interface. When the SMO determines the termination of a specific E2 node, it can transmit the configuration information for the termination to the corresponding E2 node. The E2 node can receive the configuration information for the termination of the E2 node from the SMO via the O1 interface.

[0140] In operation S1085, the SMO may transmit a configuration message regarding the termination of the E2 node to the Near-RT RIC via the O1 interface. According to one embodiment, the SMO may transmit a configuration message to the Near-RT RIC notifying the Near-RT RIC that the E2 node is scheduled to terminate. According to one embodiment, the SMO may transmit a configuration message to the Near-RT RIC including relevant setting information for the E2 node to be terminated. According to one embodiment, the SMO may transmit a configuration message to the Near-RT RIC to indicate the E2 node to be terminated. The SMO may identify the Near-RT RIC connected to the E2 node to be terminated. Because there may be one or more E2 nodes connected to the Near-RT RIC, the transmitted configuration message may include E2 node identification information (e.g., E2 node ID) to indicate the E2 node to be terminated.

[0141] When the SMO transmits configuration information to terminate an E2 node, the SMO can transmit a message to the Near-RT RIC connected to the E2 node to remove the E2 node's related information and E2 interface.

[0142] In operation S1087, the Near-RT RIC can delete information related to the E2 interface. Upon receiving the message, the Near-RT RIC proceeds with the operation of deleting information related to the corresponding E2 node.

[0143] In operation S1089, the E2 node can delete E2 interface-related information. The E2 interface-related information can include Near-RT-related settings and E2 interface instance settings connected via the E2 interface. The E2 node can also suspend ongoing traffic (or service). That is, the E2 node can suspend the traffic currently being served or suspend the service.

[0144] In operation S1091, the E2 node can transmit a message confirming (or notifying) the termination (hereinafter referred to as a termination confirmation message) to the SMO. The E2 node can transmit the termination confirmation message to the SMO via the O1 interface. The SMO can receive the termination confirmation message from the E2 node.

[0145] In operation S1092, the Near-RT RIC can transmit a message to the SMO notifying confirmation of the E2 node's termination. The Near-RT RIC can transmit a confirmation message as a response message to the SMO's operation S1085. The Near-RT RIC can transmit a termination confirmation message to the SMO via the O1 interface notifying confirmation of the E2 node's termination. The SMO can receive the termination confirmation message from the Near-RT RIC. Although not shown in FIG. 10D, the Near-RT RIC can transmit a response message to operation S1085. According to one embodiment, the Near-RT RIC transmits the response message to operation S1085 to the E2 node immediately after operation S1083, or according to another embodiment, the Near-RT RIC can transmit the response message to operation S1085 to the E2 node after operation S1087. In operation S1093, the SMO can transmit a message for terminating the E2 node to the O-Cloud. The SMO can transmit a message for terminating the E2 node to the O-Cloud via the O2 interface. The message for terminating the E2 node can mean a message for releasing the resources of the E2 node. When the SMO receives a service or traffic interruption confirmation message from the E2 node, the SMO can transmit a message for releasing the resources of the E2 node to the O-Cloud. The O-Cloud can receive a message for releasing the resources of the E2 node from the SMO.

[0146] In operation S1095, the O-Cloud may transmit a message to the E2 node to deallocate resources. According to one embodiment, the O-Cloud may notify the E2 node of the resource deallocation via an application.

[0147] In operation S1097, O-Cloud can transmit a message to SMO notifying that the termination of the E2 node is complete. Completion of the termination of the E2 node means that all resources allocated to the E2 node have been released. In other words, O-Cloud can release all resources of the E2 node and transmit a completion message to SMO.

[0148] In operation S1099, the E2 node can release all resources. The E2 node can release all resources based on the resource deallocation of the O-Cloud. Since the E2 node can identify the termination of the E2 node via SMO and O-Cloud, the E2 node can perform procedures due to the termination of the E2 node (e.g., deleting E2 interface-related settings).

[0149] Unlike Figure 9, the SMO transmits termination-related settings not only to the E2 node but also to the Near-RT RIC. Therefore, when the SCTP connection is released, the Near-RT RIC no longer needs to maintain E2 node-related information (e.g., Global E2 node ID, RAN Function info, E2 node component configuration, etc.). Also, the Near-RT RIC does not maintain E2 interface settings (e.g., SCTP connections). By transmitting the E2 node termination settings via the O1 interface to all nodes on the E2 interface, ongoing information about the E2 node is correctly collected, reducing unnecessary resource waste.

[0150] 10D describes a method for deleting E2 node-related settings and E2 interface settings in a Near-RT RIC when it is determined that an E2 node is to be terminated, but the embodiments of the present disclosure may also be applied to the reverse case. That is, an operation in which Near-RT RIC-related settings and E2 interface settings are deleted in an E2 node when it is determined that an E2 node is to be terminated may also be understood as an embodiment of the present disclosure. According to one embodiment, when it is determined that a Near-RT RIC is to be terminated, the SMO may not only transmit a configuration message regarding the termination to the corresponding Near-RT RIC, but may also transmit a configuration message regarding the termination of the Near-RT RIC to one or more E2 nodes connected to the Near-RT RIC.

[0151] 10D shows that the confirmation message transmission by operation S1091 occurs after operation S1089, but the embodiments of the present disclosure are not limited thereto. According to one embodiment, the confirmation message transmission by operation S1091 may occur after operation S1087 and before operation S1089. Alternatively, according to one embodiment, the confirmation message transmission by operation S1091 may occur after operation S1083.

[0152] The embodiments of the present disclosure propose a method for deleting information stored in a peer node when either an E2 node or a Near-RT RIC providing an E2 interface is terminated. According to the method according to the embodiments of the present disclosure, when an E2 node is terminated, the Near-RT RIC can delete information related to the terminated E2 node stored in the Near-RT RIC (e.g., Global E2 Node ID, RAN Function info, E2 Node component configuration, RICs service REPORT / INSERT information received during the RIC Indication procedure, etc.) and E2 I / F instance information (i.e., Transport Layer information of the E2 node). In addition, according to a method according to an embodiment of the present disclosure, when a Near-RT RIC is terminated, related information of the terminating Near-RT RIC stored in the E2 node (e.g., Global RIC ID, RIC Subscription information (RIC services REPORT, INSERT and / or POLICY) received during the Subscription procedure, RIC service CONTROL information received during the Control procedure, etc.) and E2 I / F instance information (i.e., Transport Layer information of the Near-RT RIC) can be deleted.

[0153] An embodiment of the present disclosure proposes a method for deleting related information, such as the E2 I / F, stored in the Near-RT RIC and the E2 node when the E2 interface connection between the Near-RT RIC and the E2 node is terminated in an O-RAN (Open RAN)-based mobile communication system. The E2 interface-related settings referred to in FIGS. 10A to 10D above may be defined as follows: When the E2 node is terminated, the Near-RT RIC can remove the settings for the E2 node. The termination of the E2 node means that the SCTP connection from the E2 node is terminated. When the Near-RT RIC is terminated, the E2 node can remove the settings for the Near-RT RIC. That is, the E2 interface-related settings referred to in the present disclosure may include settings for the E2 node or settings for the Near-RT RIC.

[0154] The E2 node-related settings refer to information obtained by a Near-RT RIC performing elementary procedures (e.g., Table 1, Table 2) with the corresponding E2 node. According to one embodiment, the E2 interface-related settings to be removed may include information obtained through a RIC Subscription procedure. For example, the removed information may include a RIC request ID. For example, the removed information may include a RAN function ID. For example, the removed information may include a RIC Event Trigger Definition.

[0155] According to one embodiment, the removed E2 interface-related settings may include information obtained via a RIC indication procedure. For example, the removed information may include a RIC request ID. For example, the removed information may include a RAN function ID. For example, the removed information may include a RIC action ID. For example, the removed information may include a RIC call process ID. For example, the removed information may include a RIC indication message, type, header, and SN.

[0156] According to one embodiment, the removed E2 interface-related settings may include information obtained via a RIC indication procedure. For example, the removed information may include a RIC request ID. For example, the removed information may include a RAN function ID. For example, the removed information may include a RIC call process ID. For example, the removed information may include a RIC control message.

[0157] According to one embodiment, the removed E2 interface-related settings may include information obtained through the E2 SETUP procedure. For example, the removed information may include a Global E2 Node ID. For example, the removed information may include information (item, ID, definition) for the RAN function. For example, the removed information may include an E2 Node Component Configuration.

[0158] According to one embodiment, the E2 interface-related settings to be removed may include information obtained via an E2 CONFIGURATION UPDATE procedure. For example, the information to be removed may include a Global E2 Node ID. For example, the information to be removed may include information (item, ID, definition) for a RAN function. For example, the information to be removed may include an E2 Node Component Configuration. For example, the information to be removed may include an E2 Node TNL (transport network layer)-related information (E2 Node TNL Association To Remove List).

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

[0160] In the case of a software implementation, a computer-readable storage medium may be provided that stores one or more programs (software modules). The one or more programs stored on the computer-readable storage medium are configured for execution by one or more processors in an electronic device. The one or more programs include instructions that cause the electronic device to perform a method according to the embodiments described in the claims or specification of the present disclosure.

[0161] Such programs (software modules, software) may be stored in random access memory, non-volatile memory including flash memory, read only memory (ROM), electrically erasable programmable read only memory (EEPROM), magnetic disc storage device, compact disc-ROM (CD-ROM), digital versatile discs (DVDs) or other forms of optical storage, magnetic cassette, or in memory configured as a combination of some or all of these. Also, each of these memory components may include multiple instances.

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

[0163] In the specific embodiments of the present disclosure described above, elements included in the disclosure are expressed in the singular or plural form according to the specific embodiments presented. However, the expressions "singular" or "plural" are selected to suit the presented circumstances for the convenience of explanation, and the present disclosure is not limited to singular or plural elements, and elements expressed in the plural form may also be composed in the singular, and elements expressed in the singular may also be composed in the plural.

[0164] Meanwhile, while the detailed description of the present disclosure has been illustrated and described with reference to various embodiments, it will be understood by those skilled in the art that various modifications are possible within the scope of the present disclosure as set forth in the appended claims and their equivalents.

Claims

1. A method performed by a Near-RT (real time) RIC (RAN (radio access network) intelligent controller) in a wireless communication system, comprising: sending a removal request message to an E2 node via an E2 interface to remove the connection between the Near-RT RIC and the E2 node; and receiving a removal response message from an E2 node over the E2 interface; The E2 node includes an O-RAN distributed unit (O-DU), an O-RAN central unit-control plane (O-CU-CP), an O-RAN central unit-user plane (O-CU-UP), or a base station that communicates with the Near-RT RIC via the E2 interface; The E2 interface provided for communication between the Near-RT RIC and the E2 node supports E2AP (E2 Application Protocol) for communication over the E2 interface.

2. 2. The method of claim 1, wherein at least one resource associated with a connection between the Near-RT RIC and the E2 node is released from the E2 node.

3. The method comprises: After receiving the removal response message, releasing at least one resource associated with the removal of the connection between the Near-RT RIC and the node; and The method of claim 1 , further comprising the step of suspending data transmission of the E2 node to the Near-RT RIC after receiving the removal response message.

4. 2. The method of claim 1, wherein after the remove request message is transmitted, an ongoing RIC service is suspended on the E2 interface.

5. A Near-RT (real time) RIC (RAN (radio access network) intelligent controller) of a wireless communication system, at least one transceiver; at least one processor; The at least one processor sending a remove request message to an E2 node via an E2 interface to remove the connection between the Near-RT RIC and the E2 node; configured to receive a removal response message from an E2 node via the E2 interface; The E2 node includes an O-RAN distributed unit (O-DU), an O-RAN central unit-control plane (O-CU-CP), an O-RAN central unit-user plane (O-CU-UP), or a base station that communicates with the Near-RT RIC via the E2 interface; A Near-RT RIC, wherein the E2 interface provided for communication between the Near-RT RIC and the E2 node supports E2AP (E2 Application Protocol) for communication over the E2 interface.

6. 6. The Near-RT RIC of claim 5, wherein at least one resource associated with a connection between the Near-RT RIC and the E2 node is released from the E2 node.

7. The at least one processor After receiving the removal response message, release at least one resource associated with the removal of the connection between the Near-RT RIC and the E2 node; The Near-RT RIC of claim 5, further configured to suspend data transmission of the E2 node to the Near-RT RIC after receiving the removal response message.

8. 6. The Near-RT RIC of claim 5, wherein after the remove request message is transmitted, an ongoing RIC service is suspended on the E2 interface.

9. 1. A method performed by an E2 node of a wireless communication system, comprising: receiving a removal request message from a Near-RT (real time) RIC (RAN (radio access network) intelligent controller) via an E2 interface to remove a connection between the Near-RT RIC and the E2 node; and transmitting a removal response message to the Near-RT RIC via the E2 interface; The E2 node includes an O-RAN distributed unit (O-DU), an O-RAN central unit-control plane (O-CU-CP), an O-RAN central unit-user plane (O-CU-UP), or a base station that communicates with the Near-RT RIC via the E2 interface; The E2 interface provided for communication between the Near-RT RIC and the E2 node supports E2AP (E2 Application Protocol) for communication over the E2 interface.

10. The method comprises:

10. The method of claim 9, further comprising the step of releasing from the E2 node at least one resource associated with the removal of the connection between the Near-RT RIC and the E2 node.

11. The method comprises: After sending the removal response message, at least one resource associated with the removal of the connection between the Near-RT RIC and the E2 node is released; 10. The method of claim 9, wherein after sending the removal response message, the E2 node's data transmission to the Near-RT RIC is suspended.

12. 10. The method of claim 9, wherein after the remove request message is received, an ongoing RIC service is suspended on the E2 interface.

13. An E2 node of a wireless communication system, comprising: at least one transceiver; at least one processor; The at least one processor receiving a removal request message from a Near-RT (real time) RIC (RAN (radio access network) intelligent controller) via an E2 interface to remove a connection between the Near-RT RIC and the E2 node; configured to send a removal response message to the Near-RT RIC via the E2 interface; The E2 node includes an O-RAN distributed unit (O-DU), an O-RAN central unit-control plane (O-CU-CP), an O-RAN central unit-user plane (O-CU-UP), or a base station that communicates with the Near-RT RIC via the E2 interface; An E2 node, wherein the E2 interface provided for communication between the Near-RT RIC and the E2 node supports E2AP (E2 Application Protocol) for communication over the E2 interface.

14. The at least one processor 14. The E2 node of claim 13, further configured to release at least one resource associated with removal of a connection between the Near-RT RIC and the E2 node.

15. After sending the removal response message, at least one resource associated with the removal of the connection between the Near-RT RIC and the E2 node is released; 14. The E2 node of claim 13, wherein after sending the removal response message, the E2 node's data transmission to the Near-RT RIC is suspended.

Images