Apparatus and method for providing protocol versions

Abstract

The present disclosure relates to a 5th-Generation (5G) or pre-5G communication system for supporting a higher data transmission rate than a 4th-Generation (4G) system such as Long Term Evolution (LTE). According to an embodiment, a method performed by an E2 node may include a step for sending an E2 setup request message to a near real-time (RT) radio access network (RAN) intelligent controller (RIC). The method may include a step for receiving an E2 setup response message from the RIC. The E2 setup request message may include information for identifying an interface type of the E2 node and information for identifying a communication protocol version corresponding to the interface type.

Description

Technical Field

[0001] The present disclosure generally relates to an apparatus and a method for providing a specification version. Background Art

[0002] Since the commercialization of the fourth-generation (4G) communication system, the fifth-generation (5G) communication system or pre-5G communication system has been developed or improved to meet the growing demand for wireless data services. For this reason, the 5G communication system or pre-5G communication system is generally referred to as a super 4G network communication system or a post-LTE (Long-Term Evolution) system.

[0003] To achieve high data rates, the 5G communication system is being considered for implementation in the extremely high frequency (mmWave) band (e.g., 60 gigahertz (GHz) band). In addition, to mitigate the path loss of radio waves and increase the transmission distance of radio waves in the extremely high frequency band, advanced technologies such as beamforming, massive MIMO, and full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and massive antenna technologies are being discussed and developed for the 5G communication system.

[0004] In addition, to improve the network in the 5G communication system, technologies for evolving small cells and advanced small cells are being developed, such as cloud radio access network (cloud RAN), ultra-dense network, device-to-device (D2D) communication, wireless backhaul, mobile network, cooperative communication, coordinated multi-point (CoMP), receive interference cancellation, etc.

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

[0006] To meet the demand for radio data services, the 5G communication system (NR (New Radio or Next Generation Radio)) has been commercialized. The 5G communication system provides high data rate services to users like the 4G communication system. In addition, the 5G communication system provides wireless communication services for various purposes (such as the Internet of Things (IoT) and services that require high reliability for specific purposes, etc.). In a system that mixes the fourth-generation communication system and the fifth-generation system, the Open Radio Access Network (O-RAN) defines the interface specifications with new network elements (NEs) based on the 3GPP specifications and presents the O-RAN architecture. The O-RAN is established by a collection of operators and device providers. Summary of the Invention

[0007] Technical Solution

[0008] According to one or more embodiments, a method performed by a first base station includes: sending an E2 setup request message to a network controller; and receiving an E2 setup response message from the network controller. The E2 setup request message includes: information about an interface type of the first base station, and version information of a 3rd Generation Partnership Project (3GPP) standard corresponding to the interface type.

[0009] According to one or more embodiments, a method performed by a network controller includes: receiving an E2 setup request message from a first base station; and sending an E2 setup response message to the first base station. The E2 setup request message includes: information about an interface type of the first base station, and version information of a 3rd Generation Partnership Project (3GPP) standard corresponding to the interface type.

[0010] According to one or more embodiments, a first base station includes: at least one transceiver; and at least one processor electrically connected to the at least one transceiver. The at least one processor is configured to: send an E2 setup request message to a network controller; and receive an E2 setup response message from the network controller. The E2 setup request message includes: information about an interface type of the first base station, and version information of a 3rd Generation Partnership Project (3GPP) standard corresponding to the interface type.

[0011] According to one or more embodiments, a network controller includes: at least one transceiver; and at least one processor coupled to the at least one transceiver. The at least one processor is configured to: receive an E2 setup request message from a first base station; and send an E2 setup response message to the first base station. The E2 setup request message includes: information about an interface type of the first base station, and version information of a 3rd Generation Partnership Project (3GPP) standard corresponding to the interface type.

[0012] According to one or more embodiments, a method performed by an E2 node includes: sending an E2 setup request message to a near real-time (RT) Radio Access Network (RAN) Intelligent Controller (RIC). The method includes receiving an E2 setup response message from the near RT RIC. The E2 setup request message includes information for identifying an interface type of the E2 node and information for identifying a version of a communication protocol corresponding to the interface type.

[0013] According to one or more embodiments, a method performed by a near real-time (RT) Radio Access Network (RAN) Intelligent Controller (RIC) includes: receiving an E2 setup request message from an E2 node. The method includes sending an E2 setup response message to the E2 node. The E2 setup request message includes information for identifying an interface type of the E2 node and information for identifying a version of a communication protocol corresponding to the interface type.

[0014] According to one or more embodiments, a device of an E2 node includes: at least one transceiver; and at least one processor, coupled to the at least one transceiver. The at least one processor is configured to send an E2 establishment request message to a near real-time (RT) radio access network (RAN) intelligent controller (RIC). The at least one processor is configured to receive an E2 establishment response message from the near RT RIC. The E2 establishment request message includes information for identifying an interface type of the E2 node and information for identifying a version of a communication protocol corresponding to the interface type.

[0015] According to one or more embodiments, a device of a near real-time (RT) radio access network (RAN) intelligent controller (RIC) includes: at least one transceiver; and at least one processor, coupled to the at least one transceiver. The at least one processor is configured to receive an E2 establishment request message from an E2 node. The at least one processor is configured to send an E2 establishment response message to the E2 node. The E2 establishment request message includes information for identifying an interface type of the E2 node and information for identifying a version of a communication protocol corresponding to the interface type. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 Illustrates an example of a fourth generation (4G) long term evolution (LTE) core system;

[0017] Figure 2a Illustrates an example of a fifth generation (5G) non-standalone (NSA) system;

[0018] Figure 2b Illustrates an example of an architecture for an open radio access network (O-RAN);

[0019] Figure 3 Illustrates a protocol stack of E2 application protocol messages in a radio access network according to one or more embodiments;

[0020] Figure 4 Illustrates an example of a connection between a base station and a radio access network (RAN) intelligent controller (RIC) in a radio access network according to one or more embodiments;

[0021] Figure 5 Illustrates a configuration of a device in a radio access network according to one or more embodiments;

[0022] Figure 6 Illustrates a logical function related to E2 messages of a RIC and an E2 node in a radio access network according to one or more embodiments;

[0023] Figure 7 Illustrates an example of a functional separation between an E2 node and a RIC according to one or more embodiments;

[0024] Figure 8 Shows an example of the implementation of an E2 node and a RIC according to one or more embodiments;

[0025] Figure 9 Shows an example of the functional separation between a Centralized Unit (CU) and a RIC according to one or more embodiments;

[0026] Figure 10 Shows an example of the version number of the transmitted E2 Application Protocol (E2AP) specification according to one or more embodiments;

[0027] Figure 11a 、 Figure 11b and Figure 11c Shows an example of an E2 Setup Request message for providing the version number of 3GPP specifications according to one or more embodiments;

[0028] Figures 12a to 12d Shows an example of E2 node configuration information for providing the version number of 3GPP specifications according to one or more embodiments;

[0029] Figure 13 Shows an example of dual connectivity (DC) related functions based on the version number of 3GPP specifications according to one or more embodiments; and

[0030] Figure 14 Shows an example of cross - link interference (CLI) related functions according to the version number of 3GPP specifications according to one or more embodiments.

[0031] Figure 15 Shows an example of a RIC service update process for providing the version number of 3GPP specifications according to one or more embodiments. Detailed Description of the Invention

[0032] The terms used in this disclosure are only for better describing a certain embodiment and are not intended to limit the scope of other embodiments thereto. Unless otherwise clearly specified in the context, singular expressions may include plural expressions. The terms used herein (including technical and scientific terms) may have the same meaning as those commonly understood by those skilled in the art to which this disclosure pertains. Among the terms used in this disclosure, terms defined in a general dictionary may be interpreted as having the same or similar meaning as their meaning in the context of the related art, and they should not be interpreted as ideal or overly formal meanings unless clearly defined in this disclosure. In some cases, even the terms defined in this disclosure should not be interpreted as excluding the embodiments of this disclosure.

[0033] In various examples of the present disclosure described below, hardware methods will be described as examples. However, since one or more embodiments of the present disclosure include techniques that utilize both hardware and software, they are not intended to exclude software-based methods.

[0034] In the following, the present disclosure relates to a control process between a device in a radio access network (RAN) and a device controlling the RAN in a wireless communication system. More specifically, the present disclosure relates to a process, message, and method for enabling an E2 node and a Radio Access Network Intelligent Controller (RIC) to operate properly according to specific criteria by the E2 node providing the version number of 3GPP specifications (e.g., Technical Specification (TS) 38.473, TS 38.423, TS 38.463, TS 38.413, TS 36.423) (e.g., "16.2.0" of TS 38.473v16.2.0) to the RIC on the E2 interface.

[0035] As used in the following description, terms referring to configuration (e.g., establish, set, arrange, control), terms referring to signals (e.g., packet, message, signal, information, signaling), terms referring to resources (e.g., section, symbol, time slot, subframe, radio frame, subcarrier, resource element (RE), resource block (RB), bandwidth part (BWP), occasion), terms for indicating an operation state (e.g., step, operation, process), terms referring to data (e.g., packet, message, user flow, information, bit, symbol, codeword), terms referring to channels, terms referring to network entities (Distributed Unit (DU), Radio Unit (RU), Central Unit (CU), Control Plane (CU-CP), O-DU (O-RAN (Open Radio Access Network) DU), O-RU (O-RAN RU), O-CU (O-RAN CU), O-CU-UP (O-RAN CU-CP), O-CU-CP (O-RAN CU-CP)), terms referring to components of a device, etc. are shown for ease of description. Thus, the present disclosure is not limited to the terms described below, and other terms with equivalent technical meanings may be used for their use. In addition, as used herein, terms such as, for example, “… unit”, “… module”, “… group”, “… part” may represent at least one form of structure or unit for processing a certain function.

[0036] In addition, throughout this disclosure, expressions such as "higher than (or exceeding)" or "lower than" may be used to determine whether a specific condition is met or achieved, but they are merely descriptive examples and are not intended to exclude the meanings of "greater than or equal to" or "less than or equal to". A condition described as "greater than or equal to" may be replaced by "above", a condition described as "less than or equal to" may be replaced by "below", and conditions described as "greater than or equal to" and "below" may be replaced by "above" and "less than or equal to", respectively. In addition, unless otherwise explicitly specified, "A" to "B" is intended to mean at least one of the elements from A to (including A) and B (including B). Hereinafter, unless otherwise explicitly specified, "C" and / or "D" is intended to mean at least one of "C" or "D", i.e., {"C", "D", "C and D"}.

[0037] In addition, this disclosure uses terms used in some communication standard specifications (e.g., the Third Generation Partnership Project (3GPP), the Scalable Radio Access Network (xRAN), the Open Radio Access Network (O-RAN)) to describe one or more embodiments, but they are merely descriptive examples. One or more embodiments of this disclosure can even be easily modified and applied in other communication systems.

[0038] Under the existing specifications of 3GPP, non-backward compatibility problems may occur frequently.

[0039] A device and method for controlling an E2 node by a Radio Access Network (RAN) Intelligent Controller (RIC) in a radio access network are provided. A device and method for controlling an E2 node through an E2 message according to the Open Radio Access Network (O-RAN) specifications of a wireless communication system are provided.

[0040] In addition, a device and method for sending the Third Generation Partnership Project (3GPP) specification number of an E2 node to a Radio Access Network (RAN) Intelligent Controller (RIC) in a wireless communication system are provided.

[0041] According to an embodiment of this disclosure, by an E2 node providing the version of the 3GPP specification related to the E2 node (e.g., the Central Unit (CU) or the Control Plane (CU-CP)) to a Radio Access Network (RAN) Intelligent Controller (RIC) in a wireless communication system, the device and method can enable the RIC to perform specific radio communication control functions according to the 3GPP release version. In addition, by enabling the RIC to effectively control the E2 node regardless of the 3GPP specification compatibility of the base station, the device and method can provide a function of enhancing the mutual compatibility of the E2 interface.

[0042] The effects obtained from the present disclosure are not limited to those described above, and based on the following description, those with ordinary knowledge in the art to which the present disclosure pertains will clearly understand any other effects not mentioned herein.

[0043] With the commercialization of 4G communication systems and 5G communication systems (e.g., New Radio (NR)), users in virtualized networks have continuously required differentiated service support. Therefore, 3GPP originated from a joint research project among several mobile communication-related organizations, aiming to create 3G mobile communication system specifications applicable globally within the scope of the IMT-2000 project of the International Telecommunication Union (ITU).

[0044] 3GPP was established in December 1998, and 3GPP specifications are based on the advanced GSM standard, including all radio, core network, and service architectures within the scope of standardization. Therefore, O-RAN has newly defined the RU (Radio Unit), DU (Digital Unit), CU (Central Unit)-CP (Control Plane), and CU-UP (User Plane) of the nodes constituting 3GPP network entities (NEs) and base stations as O (O-RAN)-RU, O-DU, O-CU-CP, and O-CU-UP, respectively, and has additionally standardized the near real-time (near RT) Radio Access Network Intelligent Controller (RIC).

[0045] According to one or more embodiments, the present disclosure relates to an operator-specific service model in 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 according to the O-RAN standard and can be referred to as "E2 nodes". The E2AP is used as an application protocol for the interface between the RIC and the E2 nodes with respect to the objects constituting a RAN capable of operating according to the O-RAN standard.

[0046] The RIC is a logical node that can collect information about the cell sites transmitted and received by the terminal, O-DU, O-CU-CP, or O-CU-UP. The RIC can be implemented in the form of a server centralized in one physical location. Connections can be established between the O-DU and the RIC, between the O-CU-CP and the RIC, and between the O-CU-UP and the RIC via Ethernet. For this purpose, interface standard specifications for communication between the O-DU and the RIC, between the O-CU-CP and the RIC, and between the O-CU-UP and the RIC are required, and also the definition of message specifications for E2-DU, E2-CU-CP, E2-CU-UP, etc. and the procedures between the O-DU, O-CU-CP, O-CU-UP, and the RIC. In particular, since users in a virtualized network require differentiated service support and the call processing messages / functions generated in the O-RAN are centralized on the RIC, it is necessary to define the functions of the E2-DU, E2-CU-CP, and E2-CU-UP messages to support services for a wide range of cell coverage. In an embodiment, the RIC may be referred to as a network controller or a RAN controller, etc.

[0047] The RIC can perform communication with the O-DU, O-CU-CP, and O-CU-UP using the E2 interface and generate and send subscription messages to set event occurrence conditions. More specifically, the RIC can generate an E2 subscription request message and transmit it to an E2 node (e.g., O-CU-CP, O-CU-UP, O-DU) to set call processing events. In addition, after setting the call processing events, the E2 node can send a subscription request response message transmitted to the RIC.

[0048] The E2 node can send the current state to the RIC via E2 indication / reporting. The RIC can use E2 control messages to control the O-DU, O-CU-CP, and O-CU-UP. One or more embodiments of the present disclosure propose an E2 indication message for a UE unit that sends measurement information for each period set in the subscription event conditions in the O-DU. In addition, one or more embodiments of the present disclosure propose a message for controlling resources sent from the RIC to the O-DU.

[0049] Figure 1 An example of a 4G (Fourth Generation) LTE (Long Term Evolution) core system is shown.

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

[0051] The base station 110 is a network infrastructure that provides wireless access to the terminal 120. For example, the base station 110 is a device that collects status information (such as buffer status, available transmission power, or channel status) of the terminal 120 to perform scheduling. The base station 110 has a coverage area defined as a certain geographical region based on the distance at which signals can be transmitted. The base station 110 is connected to the MME 150 through the S1-MME interface. In addition, the base station 110 can also be referred to as an "access point (AP)", "eNodeB (eNB)", "radio point", "transmission / reception point (TRP)", or other terms with equivalent technical meanings.

[0052] The terminal 120, as a device used by a user, communicates with the base station 110 through a radio channel. In some cases, the terminal 120 can be operated without any user participation. For example, the terminal 120 can be a device for performing machine type communication (MTC) and may not be carried by a user. In addition, the terminal 120 can be referred to as a "user equipment (UE)", "mobile station", "subscriber station", "customer premise equipment (CPE)", "remote terminal", "wireless terminal", "user device", or any other term with an equivalent meaning.

[0053] The S-GW 130 provides data bearers and generates or controls data bearers under the control of the MME 150. For example, the S-GW 130 can process packets arriving from the base station 110 or packets to be forwarded to the base station 110. In addition, the S-GW 130 can be used as an anchor during the handover of the terminal 120 between base stations. The P-GW 140 can be used as a connection point to an external network (such as the Internet network). In addition, the P-GW 140 can assign an Internet protocol (IP) address to the terminal 120 and serve as an anchor for the S-GW 130. In addition, the P-GW 140 can apply the quality of service (QoS) policy of the terminal 120 and manage account data.

[0054] The MME 150 manages the mobility of the terminal 120. In addition, the MME 150 can perform authentication, bearer management, etc. on the terminal 120. That is, the MME 150 is responsible for the mobility management and various control functions of the terminal. The MME 150 can be associated with a serving GPRS support node (SGSN).

[0055] The HSS 160 stores key information for the authentication of the terminal 120 and the subscriber profile. When the terminal 120 accesses the network, the key information and the subscriber profile are sent from the HSS 160 to the MME 150.

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

[0057] Carrier aggregation (hereinafter referred to as "CA") can be capable of combining multiple component carriers and simultaneously using such multiple component carriers to transmit / receive signals, thereby increasing the efficiency of frequency use from the perspective of the terminal or the base station. Specifically, according to the CA technology, the terminal and the base station can respectively use a wideband and use multiple component carriers in the uplink (UL) and the downlink (DL) to transmit and receive signals. Each component carrier is located in a different frequency band. Hereinafter, the term "uplink" indicates the communication link through which the terminal sends signals to the base station, and the term "downlink" indicates the communication link through which the base station sends signals to the terminal. In this case, the number of uplink component carriers and downlink component carriers may be different from each other.

[0058] By connecting one terminal to multiple base stations to simultaneously transmit and receive signals using the carriers in multiple base stations located in different frequency bands, from the perspective of the terminal or the base station, dual connectivity or multi-connectivity can improve the efficiency of frequency use. The terminal can be simultaneously connected to the first base station (e.g., the base station providing services using LTE technology or 4G mobile communication technology) and the second base station (e.g., the base station providing services using NR technology or 5G mobile communication technology) to transmit and receive traffic. In this case, the frequency resources used by each base station may be located in different frequency bands. Thus, the scheme operating based on the dual connectivity with LTE and NR can be referred to as 5G non-standalone (NSA).

[0059] Figure 2a An example of a 5G NSA system is shown.

[0060] Reference Figure 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 services from either the NR RAN 210a or the LTE RAN 210b or from both 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 can be referred to as a "5th generation (5G) node", a "next-generation nodeB (gNB)", or other terms with equivalent technical meanings. In addition, the NR base station can have a structure separated by a central unit (CU) and a digital unit (DU), and the CU can also have a structure separated by a control plane (CU-CP) unit and a user plane (CU-UP) unit.

[0061] In Figure 2a In the structure shown, the terminal 220 can perform a radio resource control (RRC) connection through a first base station (e.g., a base station belonging to the LTE RAN 210b) and can be provided with services by utilizing the functions provided in the control plane (e.g., connection management, mobility management, etc.). In addition, additional radio resources for transmitting and receiving data can be provided to the terminal 220 through a second base station (e.g., a base station belonging to the NR RAN 210a). This dual-connection technology using LTE and NR can be referred to as EN-DC (Evolved Universal Terrestrial Radio Access (E-UTRA)-NR Dual Connectivity). Similarly, the dual-connection technology where the first base station uses NR technology and the second base station uses LTE technology can be referred to as NR-DC (NR-E-UTRA Dual Connectivity). In addition, one or more embodiments can be applied to various other forms of multi-connection and carrier aggregation technologies. In addition, one or more embodiments can also be applied when the first system (using the first communication technology) and the second system (using the second communication technology) are implemented in one device, or when the first base station and the second base station are located in the same geographical location.

[0062] Figure 2b An example of an architecture for O-RAN is shown. For the purpose of E2-SM-KPIMON (Key Performance Indicator (KPI) Monitoring) of the E2 service model, an O-RAN NSA mode in multi-connection operation using E-UTRA and NR radio access technologies can be considered, while it can be assumed that the E2 node is in the O-RAN Standalone (SA) mode.

[0063] Refer to Figure 2b, in the deployment of the O-RAN NSA mode, the eNB can be connected to the EPC via the S1-C / S1-U interface and can be connected to the O-CU-CP via the X2 interface. The O-CU-CP for deploying the O-RAN SA mode can be connected to the 5GC (5G Core) via the N2 / N3 interface.

[0064] Figure 3 Shows an example of a protocol stack of E2 application protocol messages in a radio access network according to one or more embodiments. Refer to Figure 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.

[0065] The radio network layer includes E2AP 350. E2AP 350 can be used to deliver subscription messages, indication messages, control messages, service update messages, and service query messages, and can be sent from the upper layers of SCTP 340 and IP 330.

[0066] Figure 4 Shows an example of the connection between a base station and a RIC in a radio access network according to one or more embodiments of the present disclosure.

[0067] Refer to Figure 4 , the RIC 440 is connected to the O-CU-UP 410, the O-CU-CP 420, and the O-DU 430. The RIC 440 can customize RAN functions for new services or regional resource optimization. The RIC 440 can provide network intelligence (e.g., policy enforcement, handover optimization), resource assurance (e.g., radio link management, advanced self-organizing network (SON), resource control (e.g., load balancing, slicing strategy), etc.). The RIC 440 can communicate with the O-CU-CP 420, the O-CU-UP 410, and the O-DU 430. The RIC 440 can be connected to each node through the E2-CP, E2-UP, and E2-DU interfaces. In addition, the interface between the O-CU-CP and the DU and / or between the O-CU-UP and the DU can be referred to as the F1 interface. In the following description, the DU and the O-DU, the CU-CP and the O-CU-CP, and the CU-UP and the O-CU-UP can be used interchangeably with each other respectively.

[0068] Although Figure 4 shows one RIC 440, there can be multiple RICs according to one or more embodiments. The multiple RICs can be implemented with multiple hardwares located at the same physical location, or can be implemented by virtualizing one hardware.

[0069] Figure 5Shows an example of the configuration of a device according to an embodiment of the present disclosure. Figure 5 The configuration shown can be understood as having Figure 4 a configuration of a device having at least one function among a near RT RIC, a non-RT RIC, an O-CU-CP, an O-CU-UP, and an O-DU. As used below, terms such as "~module", "~unit", "~group", "~component", etc. may indicate a unit that processes at least one function or operation, which may be implemented as hardware, software, or a combination of hardware and software.

[0070] Referring to Figure 5 , the core network device includes a communication unit 510, a storage unit 520, and a controller 530.

[0071] The communication unit 510 provides an interface for performing communication with other devices in the network. In other words, the communication unit 510 converts a bit string sent from the core network device to another device into a physical signal and converts a physical signal received from another device into a bit string. That is, the communication unit 510 can send and receive signals. Therefore, the communication unit 510 may be referred to as a modem, a transmission unit, a reception unit, or a transmission / reception unit. In this case, the communication unit 510 enables the core network device to communicate with other devices or systems through a backhaul connection (e.g., a wired backhaul or a wireless backhaul) or through the network. The communication unit 510 may include one or more transceivers.

[0072] The storage unit 520 stores data such as basic programs, application programs, and setting information for the overall operation of the core network device. The storage device 520 may include a volatile memory, a non-volatile memory, or a combination of a volatile memory and a non-volatile memory. In addition, the storage unit 520 provides the stored data according to a request from the controller 530.

[0073] The controller 530 controls the overall operation of the core network device. For example, the controller 530 sends and receives signals through the communication unit 510. In addition, the controller 530 records data in the storage unit 520 / reads data from the storage unit 520. For this reason, the controller 530 may include at least one processor. According to one or more embodiments, the controller 530 may control the device to perform operations according to one or more embodiments described in the present disclosure.

[0074] Figure 6 Shows the logical functions related to E2 messages and RIC of an E2 node in a radio access network according to an embodiment of the present disclosure.

[0075] Referring to Figure 6, the RIC 640 and the E2 node 610 can send E2 messages to each other or receive E2 messages from each other. For example, the E2 node 610 can be an O-CU-CP, O-CU-UP, O-DU, or a base station. The communication interface of the E2 node can be determined depending on the type of the E2 node 610. For example, the E2 node 610 can communicate with another E2 node 616 through an E1 interface or an F1 interface. Alternatively, for example, the E2 node 610 can communicate with the E2 node 616 via an X2 interface or an XN interface. Alternatively, for example, the E2 node 610 can perform communication through an S1 interface or a Next Generation Application Protocol (NGAP) interface (i.e., the interface between a Next Generation (NG) RAN node and the AMF).

[0076] The E2 node 610 can include an E2 node function 612. The E2 node function 612 corresponds to a specific xApp (application S / W) 646 installed in the RIC 640. For example, in the case of a KPI monitor, a set of KPI monitor S / W can be installed in the RIC 640, and the E2 node 610 can include an E2 node function 612 that generates KPI parameters and then delivers an E2 message including the KPI parameters to the E2 termination 642 located in the RIC 640. The E2 node 610 can include Radio Resource Management (RRM) 614. The E2 node 610 can manage the resources of the radio network provided to the terminal. The xApp 646 is an application designed to run on a near RT RIC. The application can consist of one or more microservices and identify what data it consumes and what data it provides when on boarding. The application is independent of the near RT RIC and can be provided by any third party. The E2 interface realizes a direct association between the xApp 646 and the RAN function.

[0077] The E2 termination 642 (located in the RIC 640) is the termination of the RIC 640 for E2 messages and performs the function of interpreting the E2 messages delivered (or sent) by the E2 node 610 and then delivering the E2 messages to the xApp 646. The database 644 (located in the RIC 640) can be used for the E2 termination 642 and the xApp 646. The E2 node 610 ( Figure 6 shown in) is the terminal of at least one interface and can be understood as the termination of messages sent to the terminal, the neighboring base station, and the core network.

[0078] Figure 7An example of the functional separation between an E2 node and a RIC according to one or more embodiments of the present disclosure is shown. The O-RAN specification provides for the functional separation between an E2 node and a RIC. For example, the E2 node can be a CU, and the RIC can be a near-RT RIC. The RIC can be connected to an Open Network Automation Platform (ONAP) / Management and Orchestration (MANO) / Network Management System (NMS) through an A1 interface. The RIC can be connected to the E2 node through an E2 interface. The E2 interface can deliver commands. The functional separation options can include a functional separation 700 that manages the entire Radio Resource Management (RRM) in the near-RT RIC, and optionally a functional separation 750 that manages the RRM in the near-RT RIC.

[0079] In the related art, the near-RT RIC can support E2 using open logical interfaces targeted at a multi-vendor environment, regardless of the implementation of a specific RRC-RRM algorithm or operation located in the near-RT RIC. In one embodiment, an E2SM-RIC (E2 Service Model Radio Interface Control) can be paired with an E2SM-NI capable of performing injection / modification / configuration of per-UE RRC messages for each I / F and network entity. In other words, the near-RT RIC can gradually improve from the functional separation 750 towards the functional separation 700. The E2 interface can evolve into an open logical interface that can be independent of the implementation of a certain RRC-RRM algorithm or operation in the near-RT RIC and can be targeted at a multi-vendor environment.

[0080] Figure 8 An example of the implementation of an E2 node and a RIC 810 according to one or more embodiments of the present disclosure is shown. In example 800, the E2 node (e.g., O-DU 820, O-CU 830) and the RIC 810 can be virtualized on a cloud platform 840 (e.g., an open chassis and blade specification edge cloud) and configured in a device (e.g., a server). Such a scenario can support deployment in a dense urban area with rich fronthaul capacity, enabling the baseband unit (BBU) function to be pooled at a central location with a low enough latency to meet the O-DU latency requirements. In one embodiment, it may not be necessary to attempt to centralize the RIC near the RT beyond the limit that can centralize the O-DU function. According to an embodiment, the E2SM-RIC can be optimized for an O-RAN deployment scenario in which the near-RT RIC, O-CU, and O-DU are implemented in an O-cloud platform.

[0081] Figure 9 An example of the functional separation between a Centralized Unit (CU) 910 and a RIC 920 according to one or more embodiments of the present disclosure is shown. Refer to Figure 9, the function separation can be performed according to deployment scenario #1 (Example 900) or functional deployment scenario #2 (Example 950).

[0082] Deployment scenario #1 (900): The RIC is located at a separate site or exists only as a different network element (NE), and replaces or recommends several features required for intelligence.

[0083] Deployment scenario #2 (950): In addition to 3GPP I / F management, the RIC can replace almost all functions of the CU.

[0084] Although Figure 9 Two scenarios are shown, but other scenarios can be applied. For example, in deployment scenario #1 (900), the mobility function can be performed by the RIC 920 instead of the CU 910. In addition, for example, in deployment scenario #1 (900), the UE context function can be performed by the RIC 920 instead of the CU 910. In addition, for example, in deployment scenario #1 (900), the session setup function can be performed by the RIC 920 instead of the CU 910.

[0085] The E2 establishment procedure can be used to establish an E2 interface between the near-RT RIC and the E2 node. The E2 node can send an E2 establishment request message to the near-RT RIC. The E2 establishment request message can include RIC services and E2 node configuration information. The near-RT RIC can send an E2 establishment response message to the E2 node. The E2 establishment response message can include RIC service and E2 node configuration confirmation.

[0086] Through the E2 establishment procedure, the E2 node can provide a list of near-RT RIC services and functions supported in the E2 node, and provide a mapping of services to functions. The information provided can be specific to each RAN function in the E2 node and can be defined by a specific E2 service model. The near-RT RIC can extract a list of the mapping of services to the supported near-RT RIC services and functions and store the information.

[0087] Through the E2 establishment procedure, the E2 node can provide E2 node configuration information. The information provided can be defined by the E2 node type and the E2 node system specification. The near-RT RIC can extract a list of E2 node configuration information and store the information.

[0088] Figure 10 An example of the transmission of the version number of the 3rd Generation Partnership Project (3GPP) specification according to one or more embodiments of the present disclosure is shown.

[0089] Reference Figure 10, the E2 node 1000 can provide the 3GPP specification number to the RIC 1100 (e.g., the near RT RIC). The 3GPP specification number can indicate the version number (e.g., 16.7.0 or 16.8.0) of the 3GPP specification (e.g., TS 38.423, TS 38.413).

[0090] The E2 node 1000 can support various interfaces depending on the node type. For example, the E2 node 1000 can be a gNB. The E2 node can support the NG interface and the XN interface. In addition, for example, the E2 node 1000 can be an O-CU. The E2 node 1000 can support the NG interface, the XN interface, and the F1 interface. Additionally, the E2 node 1000 can be an O-CU-CP or an O-CU-UP and can support the E1 interface. In addition, for example, the E2 node 1000 can be an O-DU. The E2 node 1000 can support the F1 interface. In addition, for example, the E2 node 1000 can be an eNB. The E2 node 1000 can support the S1 interface and the X2 interface. In addition, for example, the E2 node 1000 can be an eNB-CU. The E2 node 1000 can support the S1 interface, the X2 interface, and the W1 interface. In addition, for example, the E2 node 1000 can be an eNB-DU. The E2 node 1000 can support the W1 interface.

[0091] The specifications and the versions of the specifications distinguished from the perspective of the interface (I / F) of the E2 node 1000 according to the embodiments of the present disclosure can vary. To control the E2 node 1000, the RIC 1100 needs to identify the 3GPP specification information of the E2 node 1000 for each I / F. The RIC 1100 can identify the version number (i.e., the release number) of the 3GPP specification for each I / F of the node. For example, the E2 node 1000 can be a non-virtualized 4G LTE eNB base station. In this case, the E2 node 1000 can support the S1 I / F and / or the X2 I / F. Even if the I / F is the same as the S1 I / F or the X2 I / F, their supported standard functions can be different depending on each release version. For example, the X2 I / F has different supported functions for each release version of the 3GPP specification TS 36.342. In addition, for example, the S1 I / F has different supported functions for each release version of the specification TS 36.413. For example, Table 1 below shows the differences in the release versions based on the month when the specifications of each I / F were released in 3GPP version 16.

[0092]

Table 1

[0093] Standard interface Standard specification Publication date Release version Publication date Release version X2 36.423 Rel.16 2021-12 V16.8.0 Rel.16 2022-04 V16.9.0 X11 38.423 Rel.16 2021-12 V16.8.0 Rel.16 2022-04 V16.9.0 F1 38.473 Rel.16 2021-12 V16.8.0 Rel.16 2022-04 V16.9.0 S1 36.413 Rel.16 2021-12 V16.8.0 Rel.16 2022-04 V16.9.0 E1 38.463 Rel.16 2021-12 V16.8.0 Rel.16 2022-04 V16.9.0 NG 38.413 Rel.16 2021-12 V16.8.0 Rel.16 2022-04 V16.9.0 W1 37.473 Rel.16 2021-12 V16.7.0 Rel.16 2022-04 V16.8.0

[0094] In the following, embodiments of the present disclosure describe the E2 establishment process as an example, but the present disclosure is not limited thereto. The method of providing a version of a technical specification described in the embodiments of the present disclosure can also be applied to at least one of a reset process, an error indication, an RIC service update process, an E2 node configuration update process, and an E2 connection update process.

[0095] Figures 11a to 11c An example of an E2 establishment request message for providing a version number of a 3GPP specification according to an embodiment is shown. The E2 establishment process according to the currently defined process may have a problem that the RIC 1100 (e.g., near RT RIC) does not know the 3GPP specification version of the interface supported by the E2 node 1000. Therefore, the method for notifying the RIC 1100 (e.g., near RT RIC) of the 3GPP specification version of the interface supported in the E2 node 1000 is described below with reference to Figures 11a to 11c to describe a method for notifying the RIC 1100 (e.g., near RT RIC) of the 3GPP specification version of the interface supported in the E2 node 1000.

[0096] With reference to Figure 11a , the E2 node 1000 may send an E2 establishment request message to the RIC 1100 (e.g., near RT RIC). The RIC 1100 (e.g., near RT RIC) may send an E2 establishment response message to the E2 node 1000. Although O-RAN designates a base station as an E2 node, depending on its implementation scheme (e.g., virtualization) based on the 3GPP specification, it may have an integrated deployment or a distributed deployment. For example, a base station as a gNB may have an integrated deployment in which a CU and a DU are configured together. In another example, a base station as a gNB may have a two-segment deployment in which the CU and the DU are separated. In another example, a base station as a gNB may have a three-segment deployment in which each of the CU-CP, CU-UP, and DU is separated.

[0097] The E2 establishment request message sent to the RIC 1100 (e.g., near RT RIC) may include a structure defined in the E2 application protocol (E2AP) specification (e.g., O-RAN specification E2AP 2.0). For example, the E2 establishment request message may include information according to the following structure.

[0098]

Table 2

[0099] IE / Group name Message type Service ID Global E2 node ID RAN function addition list >RAN function item >>RAN function ID >>RAN function definition >>RAN function revision >>RAN function OID E2 node component configuration addition list >E2 node component configuration addition item >>E2 node component interface type >>E2 node component ID >>E2 node component configuration

[0100] Figure 11bShows an example of an E2 setup request message according to an embodiment, the E2 setup request message including an IE for indicating the version number of the 3GPP specification of the interface supported by the E2 node 1000. During the E2 setup request procedure with the RIC 1100 (e.g., near RT RIC), the E2 node 1000 (e.g., gNB, gNB-CU, gNB-DU, eNB-CU, eNB-DU) can add an IE indicating the version number of the 3GPP specification of the interface supported in the E2 node 1000 to the structure of the E2 setup request message defined in the O-RAN E2AP specification. For example, the E2 node 1000 can add the IE specified in Table 3 below to the end of the E2 setup request message.

[0101]

Table 3

[0102]

[0103] The E2 setup request message including the IE can be used to encode and send the 3GPP specification number of each 3GPPI / F (up to 7) in three octet strings. Note that three octet strings are just an example, and the 3GPP specification number of each 3GPP I / F can be represented by a different number of octet strings or any other string (such as two (2)).

[0104] According to an embodiment, the E2 setup request message can include an IE indicating the interface type. For example, "E2 node component interface type" can refer to the interface type. For example, the interface type can be indicated as shown in Table 4 below.

[0105]

Table 4

[0106]

[0107] According to an embodiment, the E2 setup request message can include an IE indicating the version number of the 3GPP specification. For example, "E2 node component interface version" can indicate the version number. The version number can be indicated in the form of "x,y,z". In 3GPP, "x" indicates the release of the standard specification, and "y" and "z" indicate the versions in the corresponding release. In addition, "x" indicates the release submitted to or approved by the Technical Specification Group (TSG), "y" represents the improvement, correction, or update of the corresponding technology, and "z" represents the version changed by editorial changes. Three octet strings are described in Table 3 to indicate the version number in the form of "x,y,z", but the embodiments of the present disclosure are not limited thereto. According to another embodiment, the E2 node 1000 can indicate the standard version of the interface based on the form of "x,y" in order to reduce the size of the field. The E2 node 1000 can indicate the standard version of the interface with two octet strings.

[0108] The following is a list of all I / Fs supported by the E2 node 1000.

[0109]

Table 5

[0110] I / F type Semantic description ng v16.9.0 xn v16.9.0 e1 v16.9.0 F1 v16.9.0 W1 v16.9.0 S1 v16.9.0 X2 v16.9.0 …

[0111] The E2 node 1000 can provide the version number supported in each interface to the RIC 1100 (e.g., the near RT RIC). Thus, the RIC 1100 (e.g., the near RT RIC) can select the functions of each version of the standard and provide the selected functions to the E2 node 1000.

[0112] Figure 11c An example showing the overall structure of the E2 setup request message including the IE for indicating the version number of the 3GPP specification is as Figure 11c shown. In the present embodiment, the IE for indicating the version number of the 3GPP specification (e.g., Table 3) is included at the bottom of the E2 setup request message, so that backward compatibility can be supported.

[0113] Figures 12a to 12d Each shows an example of the E2 node configuration information for providing the version number of the 3GPP specification according to an embodiment. In Figures 12a to 12d an example is shown of a scheme for adding an IE for indicating the version number of the 3GPP specification to the E2 node configuration information (e.g., the E2 node component configuration addition IE of Table 3) in the existing E2 setup request message (e.g., the E2 setup request message having the structure of Table 2) further proposed in the present disclosure. The E2 node configuration information can include the configuration information for each type of E2 node. In the E2 node 1000, the information for indicating the version number of the 3GPP specification (e.g., the "E2 node component interface version" IE of Table 3) can be added to the area related to the information indicating the interface type of the E2 node 1000. In other words, the information for indicating the version number of the 3GPP specification according to the embodiment can be added to the configuration information for each interface type included in the existing E2 setup request message.

[0114] Refer to Figures 12a to 12b, information indicating the version number of the 3GPP specification (e.g., "interface protocol version" IE) can be added immediately after the information indicating the interface type of the E2 node 1000. The version number of the 3GPP specification can be related to the previous interface type. For example, in the case where the "E2 node component interface type" IE in the E2 establishment request message indicates "xn", the version number of the 3GPP specification can indicate the specification version of TS 38.423 (e.g., 16.8.0). In addition, for example, in the case where the "E2 node component interface type" IE in the E2 establishment request message indicates "f1", the version number of the 3GPP specification can indicate the specification version of TS 38.473 (e.g., 16.8.0). The specification numbers according to the E2 node component types can be defined as follows:

[0115] (1) NG interface: TS 38.413;

[0116] (2) XN interface: TS 38.423;

[0117] (3) E1 interface: TS 38.413;

[0118] (4) F1 interface: TS 38.463;

[0119] (5) W1 interface: TS 37.473;

[0120] (6) S1 interface: TS 36.413; and

[0121] (7) X2 interface: TS 36.423.

[0122] Hereinafter, the present disclosure describes seven interfaces and seven specifications by way of example, but as additional specifications are in progress, 3GPP specifications for each interface type can be added thereto.

[0123] Reference Figure 12c , information indicating the version number of the 3GPP specification can be arranged at the end of the configuration information of each type of E2 node. For example, information indicating the version number of the 3GPP specification (e.g., "interface protocol version" IE) can be added immediately after the "E2 node component configuration" IE of the configuration information. For backward compatibility, the information indicating the version number of the 3GPP specification can be optionally included (e.g., optional, O).

[0124] Reference Figure 12d , information indicating the version number of the 3GPP specification (e.g., "interface protocol version" IE) can be arranged in the "E2 node component interface type" IE. For example, the "E2 node component interface type" IE can be configured as shown in Table 6 below.

[0125]

Table 6

[0126]

[0127]

[0128] Although Figures 11a to 12d Examples indicating each of the interface type and the interface protocol version are described, but embodiments of the present disclosure are not limited thereto. According to an embodiment, the E2 setup request message may include an IE indicating a 3GPP specification number common to at least two interface types. Each 3GPP specification may be updated at the same or adjacent timing. As shown in Table 10, the specifications for different interfaces may be updated in the same year and month. Therefore, instead of indicating the version of the specification for each interface, the common version of the specification may be indicated. For example, the following IE may be added to the end of the E2 setup request message.

[0129]

Table 7

[0130]

[0131] In the present disclosure, the information for identifying the interface type may be used to identify the interface type from the information in the node receiving the information. For example, the information for identifying the interface type may indicate a specific value among candidate values of the interface type (e.g., ng, xn, e1, f1, w1, s1, and x2). The node receiving the information may identify the interface type corresponding to the specific value. In addition, for example, the information for identifying the interface type may include data representing the interface type. The node receiving the information may identify the interface type associated with the data. In the present disclosure, the information for identifying the version of the communication protocol may be used to identify the version of the communication protocol from the information in the node receiving the information. For example, the information for identifying the version of the communication protocol may include a bit sequence. The node receiving the information may identify the version corresponding to the value indicated by the bit string. The node receiving the information may determine that the version is associated with the functions supported by the application protocol of the identified interface type. The version may indicate the range of capabilities including the functions supported by the corresponding protocol.

[0132] According to an embodiment, the information for identifying the version of a communication protocol may include a bit sequence. For example, the information for identifying the version of a communication protocol may include one or more octet strings. Each octet string represents a sequence of bytes or octets for representing binary data. An octet string may be composed of 8-bit integers. Octet strings can be used to represent binary data in network protocols and network device management. A node that receives the information for identifying the version of a communication protocol can identify the version of the communication protocol based on the decoding of the information. For example, the information for identifying the version of a communication protocol can be decoded to obtain a plurality of octet strings (e.g., 3 octet strings). The node may obtain the value corresponding to each octet string. The node can identify (or determine) the version of the communication protocol based on the obtained values.

[0133] Figure 13 FIG. shows an example of functions related to dual connectivity (DC) based on the version number of 3GPP specifications according to an embodiment. DC is a technology for a UE to connect to two different radio resource entities and use the radio resources allocated by each radio resource entity. In MR-DC, a UE in the radio resource control (RRC) connected state (i.e., RRC_CONNECTED) can be configured to utilize radio resources provided by two independent schedulers. Each scheduler may be located at an NG-RAN node (e.g., a first E2 node and a second E2 node). Here, one node may be a master node (MN), and the other node may be a secondary node (SN). The MN and the SN may be connected through a network interface, and the MN may be connected to the core network. The SN may or may not be connected to the core network. The possible types of DC may be defined as follows.

[0134] EN-DC: Dual connectivity where the eNB is connected to the evolved packet core (EPC), and the terminal is connected to the eNB acting as the MN and the gNB acting as the SN, where the gNB may be referred to as an en-gNB, and the en-gNB may or may not be connected to the EPC. EN-DC can be supported from version 15.

[0135] NGEN-DC: Dual connectivity where the eNB is connected to the 5GC (5G core), and the terminal is connected to the eNB acting as the MN and the gNB acting as the SN, where the eNB may be referred to as an ng-eNB.

[0136] NE-DC: Dual connectivity where the gNB is connected to the 5GC, and the terminal is connected to the gNB acting as the MN and the eNB acting as the SN, where the eNB may be referred to as an ng-eNB.

[0137] NR-DC: Dual connectivity where a gNB is connected to 5GC and a UE is connected to a gNB acting as the MN and a gNB acting as the SN. NR-DC can also be used when the UE is connected to a single gNB acting as both the MN and SN and is configured with both a Master Cell Group (MCG) and a Secondary Cell Group (SCG).

[0138] Reference Figure 13 , two base stations can be implemented as E2 nodes for DC. In Figure 13 , MR-DC for NR-NR DC is described as an example. Each of the two E2 nodes (E2 node 1 1000A and E2 node 2 1000B) configured with DC can be connected to the RIC 1100 (e.g., near RT RIC). To configure DC, the RIC 1100 (e.g., near RT RIC) can perform an establishment procedure with each E2 node.

[0139] For example, E2 node 1 1000A can be an O-CU of version 16.1.0 supporting Rel.16 XNI / F. E2 node 2 1000B can be an O-CU of version 15.3.0 supporting Rel.15 XNI / F. The RIC 1100 (e.g., near RT RIC) can identify whether E2 node 2 1000B supports the message procedures related to MR-DC and IE. Contrary to EN-DC supported in version 15, MR-DC may require the 3GPP specifications of version 16. The RIC 1100 (e.g., near RT RIC) can identify that E2 node 2 1000B does not support NR-NR DC. Then, the RIC 1100 (e.g., near RT RIC) can either not send control messages related to NR-NR DC for E2 node 2 1000B or can explicitly send a response message notifying E2 node 2 1000B of the difficulty in supporting NR-NR DC. The RIC 1100 (e.g., near RT RIC) can perform RAN control operations based on the version number (e.g., 15.3.0) of the 3GPP specifications (e.g., TS 38.423) received from the E2 node (E2 node 1 1000A or E2 node 2 1000B).

[0140] Figure 14 Shows an example of cross-link interference (CLI)-related functions according to the version number of 3GPP specifications according to an embodiment. CLI can refer to interference in the case where UL transmission of one cell blocks DL reception of another cell when different TDD DL / UL modes are used between adjacent cells. In Release 16 of the 3GPP specifications, to mitigate CLI, the gNB can adjust the TDD DL-UL configuration via the XN or F1 interface. Additionally, the victim UE can perform CLI measurements.

[0141] Reference Figure 14 , the library of the F1AP ASN.1 of the RIC 1100 (e.g., near RT RIC) can support TS 38.473 v15.16.0. ASN.1 is a standardized notation for data structures that describe messages exchanged between communication entities. ASN.1 is a notation with a long history of reliability and interoperability, capable of supporting the exchange of information in any form (e.g., audio, video, data). The xAPP of the RIC 1100 (e.g., near RT RIC) can support CLI-related features based on TS38.473 g10 (i.e., version 16.1.0). The O-DU can support TS 38.473 g10 (i.e., version 16.1.0).

[0142] The xApp of the RIC 1100 (e.g., near RT RIC) can support CLI-related features based on TS 38.473 g10 (i.e., version 16.1.0) (e.g., providing the expected TDD DL-UL configuration IE (optional)).

[0143] The DU can support TS 38.473g10 (i.e., version 16.1.0). For example, the O-DU 820 can send an E2 establishment request message including F1 establishment to the RIC 1100. Here, the information about F1 establishment can be generated based on the F1AP version of the ASN.1 library in the O-DU 820. The F1AP version of the ASN.1 library in the O-DU 820 is different from the F1AP version of the ASN.1 library on the RIC 1100. Since the RIC 1100 supports a lower F1AP version (e.g., v15.16.0) than the F1AP version (e.g., v16.1.0) supported by the O-DU 820, the RIC 1100 may not be able to decode the information received from the O-DU 820. Therefore, although the corresponding information can be delivered to the RIC 1100 in the O-DU 820, the ASN.1 decoding may fail in the E2AP. In this case, when the F1 version can be identified in the RIC 1100 (e.g., the near RT RIC) according to an additional embodiment, the RIC 1100 (e.g., the near RT RIC) can perform additional operations based on the identified 3GPP version information. For example, the RIC 1100 (e.g., the near RT RIC) can refer to other functions (e.g., xAPP) within the RIC 1100 (e.g., the near RT RIC) to perform additional operations. If the RIC 1100 (e.g., the near RT RIC) can identify the information for F1 establishment from other services via the xAPP, the RIC 1100 (e.g., the near RT RIC) can request higher version information (e.g., v16.1.0) from the O-DU 820. For example, the RIC 1100 (e.g., the near RT RIC) can request the information for RAN control of the E2 node 1000 from the O-DU 820 and receive the information for RAN control from the E2 node 1000 or another E2 node through the CLI xAPP. In addition, for example, the compatibility of the 3GPP version can be identified during the interoperability test.

[0144] Figure 15 Shows an example of a RIC service update process for providing the version number of 3GPP specifications. The RIC service update process is used to update the application-level configuration data required for the E2 node and the near RT RIC to interoperate correctly through the E2 interface.

[0145] Refer to Figure 15, in operation (1501), the E2 node 1000 may send a RIC service update message to the RIC 1000 (e.g., the near RT RIC). The RIC service update message includes a set of appropriate up-to-date near RT RIC service-related configuration data, including but not limited to a complete list of supported near RT RIC service functions added, modified, and deleted. For example, the RIC service update message may be configured as shown in the following table.

[0146]

Table 8

[0147]

[0148]

[0149]

[0150] According to an embodiment, optionally, in operation 1505, the RIC 1100 (e.g., the near RT RIC) may send a RIC service query message to the E2 node 1000 to request a service update. The near RT RIC may send a RIC service update message in response to the RIC service query message. For example, the RIC service query message may be configured as shown in the following table.

[0151]

Table 9

[0152]

[0153] In operation 1503, the RIC 1100 (e.g., the near RT RIC) may send a RIC service update confirmation message to the E2 node 1000. If at least one RAN function update request present in the RIC service update message is successful, the RIC 1100 (e.g., the near RT RIC) may send a RIC service update confirmation message to the E2 node 1000. The RAN function information may be modified and / or deleted, and if needed, a RAN function rejection list IE indicating the rejected requests to add, modify, and / or delete the corresponding RAN function information may be included in the RIC service update confirmation message. For example, the RIC service update confirmation message may be configured as shown in the following table.

[0154]

Table 10

[0155]

[0156] RAN functions to be accepted or rejected by the messages described above can be determined based on RAN function definition information (e.g., RAN function definition IE). The RAN function definition information can define the RAN function name and indicate the RIC service that a particular RAN function is currently configured to provide via the E2 interface. The RAN function definition information can be provided via the E2 setup request procedure (e.g., Figures 11a to 12d ) or the RIC service update procedure (e.g., Figure 15 ). The RAN function definition information can be used to provide various information about the near-RT RIC in order to determine the solution that is configured to support a particular E2 service model (E2SM) of the RAN function in the E2 node.

[0157] According to an embodiment, the version of the communication protocol (i.e., standard) is related to the RAN function, and the RAN function definition information can include information for identifying the version.

[0158] The RAN function definition information can depend on the service model. For example, in the service model for RAN control (e.g., E2SM-RC), the RAN function definition information can be configured as shown in the following table.

[0159]

Table 11

[0160]

[0161] For another example, in the service model for the RAN function network interface (NI) (e.g., E2SM-NI), the RAN function definition information can be configured as shown in the following table.

[0162]

Table 12

[0163]

[0164]

[0165]

[0166]

[0167]

[0168] In Tables 11 and 12 described above, the "3GPP version number" IE can be replaced with another name. For example, an IE called "version", "communication protocol version", and / or "protocol" can be used to indicate the version of the communication protocol.

[0169] Different version information of 3GPP specifications between two network entities (e.g., E2 node 1000 and RIC 1100) may cause compatibility issues. For example, the RIC 1100 (e.g., near RT RIC) may receive IEs from the E2 node 1000. In this case, for IEs only supported in higher versions, the RIC 1100 (e.g., near RT RIC) may skip their decoding. Except for cases of decoding failure, as Figure 14 shown, decoding can even be skipped. Therefore, if the RIC 1100 (e.g., near RT RIC) does not receive specific information, it will not be able to know whether the specific information did not arrive due to its lower version or was not sent from the E2 node 1000. As described above, the recognition level among RIC 1100s regarding a specific message can be different from the information of the E2 node 1000 regarding the specific message. This difference may lead to errors in the control of the RIC 1100 (e.g., near RT RIC). Therefore, due to the shared interface type and the version information of the 3GPP specification regarding the interface type, the E2 node 1000 and the RIC 1100 (e.g., near RT RIC) according to embodiments of the present disclosure can reduce the above errors and increase the communication performance of the E2 interface.

[0170] According to an embodiment, a method performed by an E2 node may include sending an E2 setup request message to a near real-time (RIC) radio access network (RAN) intelligent controller (near RT RIC). The method may include receiving an E2 setup response message from the near RT RIC. The E2 setup request message may include information for identifying the interface type of the E2 node and information for identifying the version of the communication protocol corresponding to the interface type.

[0171] According to an embodiment, the information for identifying the interface type of the E2 node may include any one of an X2 interface, an Xn interface, an F1 interface, an S2 interface, an E2 interface, an NG interface, or a W1 interface. The 3GPP specification may include an application protocol according to any one of Technical Specification (TS) 36.423, TS 38.423, TS 38.473, TS 36.413, TS 38.463, TS 38.413, or TS 37.473.

[0172] According to an embodiment, the E2 setup request message may include an information element (IE) regarding an E2 node component configuration addition list. The IE may include information for identifying the interface type of the E2 node and information for identifying the version of the communication protocol.

[0173] According to an embodiment, the E2 setup request message may include an information element (IE) regarding the E2 node component interface type of the E2 node component configuration. The IE may include information for identifying the interface type of the E2 node and information for identifying the version of the communication protocol.

[0174] According to an embodiment, the version may be indicated based on three octet strings of information for identifying the version of the communication protocol. The three octet strings may include a first octet string indicating release information, a second octet string indicating update information of the release information, and a third octet string indicating edit information.

[0175] According to an embodiment, a method performed by a near-real-time (RT) radio access network (RAN) intelligent controller (near-RT RIC) may include receiving an E2 setup request message from an E2 node. The method may include sending an E2 setup response message to the E2 node. The E2 setup request message may include information for identifying the interface type of the E2 node and information for identifying the version of the communication protocol corresponding to the interface type.

[0176] According to an embodiment, the information for identifying the interface type of the E2 node may include one of an X2 interface, an Xn interface, an F1 interface, an S2 interface, an E2 interface, an NG interface, or a W1 interface. The communication protocol may include an application protocol according to one of Technical Specification (TS) 36.423, TS 38.423, TS 38.473, TS 36.413, TS 38.463, TS 38.413, or TS 37.473.

[0177] According to an embodiment, the E2 setup request message may include an information element (IE) regarding the E2 node component configuration addition list. The IE may include information for identifying the interface type of the E2 node and information for identifying the version of the communication protocol.

[0178] According to an embodiment, the E2 setup request message may include an information element (IE) regarding the E2 node component interface type of the E2 node component configuration. The IE may include information for identifying the interface type of the E2 node and information for identifying the version of the communication protocol.

[0179] According to an embodiment, the version may be indicated based on three octet strings of information for identifying the version of the communication protocol. The three octet strings may include a first octet string indicating release information, a second octet string indicating update information of the release information, and a third octet string indicating edit information.

[0180] According to an embodiment, the method includes identifying whether an Abstract Syntax Notation One (ASN1) library supports the version. The method includes: in a case where the ASN1 library does not support the version, identifying, based on a near RT RIC xApp, whether a function according to the version is supported in the near RT RIC. The method includes: in a case where the function is supported in the near RT RIC, sending, via the xApp, a request message for an ASN1 library that supports the version to an E2 node.

[0181] According to an embodiment, a device of an E2 node may include at least one transceiver and at least one processor coupled to the at least one transceiver. The at least one processor may be configured to send an E2 establishment request message to a near real-time (RT) radio access network (RAN) intelligent controller (near RT RIC). The at least one processor may be configured to receive an E2 establishment response message from the near RT RIC. The E2 establishment request message may include information for identifying an interface type of the E2 node and information for identifying a version of a communication protocol corresponding to the interface type.

[0182] According to an embodiment, the information for identifying an interface type of the E2 node may include one of an X2 interface, an Xn interface, an F1 interface, an S2 interface, an E2 interface, an NG interface, or a W1 interface. The communication protocol may include an application protocol according to one of Technical Specification (TS) 36.423, TS 38.423, TS 38.473, TS 36.413, TS 38.463, TS 38.413, or TS 37.473.

[0183] According to an embodiment, the E2 establishment request message may include an information element (IE) regarding an E2 node component configuration addition list. The IE may include information for identifying an interface type of the E2 node and information for identifying a version of a communication protocol.

[0184] According to an embodiment, the E2 establishment request message may include an information element (IE) of an E2 node component interface type regarding an E2 node component configuration. The IE may include information for identifying an interface type of the E2 node and information for identifying a version of a communication protocol.

[0185] According to an embodiment, the version may be indicated based on three octet strings of information for identifying a version of a communication protocol. The three octet strings may include a first octet string indicating release information, a second octet string indicating update information of the release information, and a third octet string indicating editorial information.

[0186] According to an embodiment, an apparatus of a near real-time (RT) radio access network (RAN) intelligent controller (near RT RIC) may include at least one transceiver and at least one processor coupled to the at least one transceiver. The at least one processor may be configured to receive an E2 establishment request message from an E2 node. The at least one processor may be configured to send an E2 establishment response message to the E2 node. The E2 establishment request message may include information for identifying an interface type of the E2 node and information for identifying a version of a communication protocol corresponding to the interface type.

[0187] According to an embodiment, the information for identifying the interface type of the E2 node may include one of an X2 interface, an Xn interface, an F1 interface, an S2 interface, an E2 interface, an NG interface, or a W1 interface. The communication protocol may include an application protocol according to one of technical specifications (TS) 36.423, TS 38.423, TS 38.473, TS 36.413, TS 38.463, TS 38.413, or TS 37.473.

[0188] According to an embodiment, the E2 establishment request message may include an information element (IE) regarding an E2 node component configuration addition list. The IE may include information for identifying the interface type of the E2 node and information for identifying the version of the communication protocol.

[0189] According to an embodiment, the E2 establishment request message may include an information element (IE) of an E2 node component interface type regarding the E2 node component configuration. The IE may include information for identifying the interface type of the E2 node and information for identifying the version of the communication protocol.

[0190] According to an embodiment, the version may be indicated based on three octet strings of the information for identifying the version of the communication protocol. The three octet strings may include a first octet string indicating release information, a second octet string indicating update information of the release information, and a third octet string indicating edit information.

[0191] According to an embodiment, the at least one processor is configured to identify whether an Abstract Syntax Notation One (ASN1) library supports the version. The at least one processor is configured to, in a case where the ASN1 library does not support the version, identify whether a function according to the version is supported in the near RT RIC based on an xApp of the near RT RIC. The at least one processor is configured to, in a case where the function is supported in the near RT RIC, control the at least one transceiver to send a request message for an ASN1 library supporting the version to the E2 node through the xApp.

[0192] According to an embodiment, a non-transitory computer-readable medium is provided. The non-transitory computer-readable medium includes a memory storing a program including instructions. When the instructions are executed by a processor of an E2 node, the instructions cause the E2 node to send an E2 setup request message to a near real-time (RT) radio access network (RAN) intelligent controller (near RT RIC) and receive an E2 setup response message from the near RT RIC. The E2 setup request message may include information for identifying an interface type of the E2 node and information for identifying a version of a communication protocol corresponding to the interface type.

[0193] According to an embodiment, a non-transitory computer-readable medium is provided. The non-transitory computer-readable medium includes a memory storing a program including instructions. When the instructions are executed by a processor of a near real-time (RT) radio access network (RAN) intelligent controller (near RT RIC), the instructions cause the near RT RIC to receive an E2 setup request message from an E2 node and send an E2 setup response message to the E2 node. The E2 setup request message may include information for identifying an interface type of the E2 node and information for identifying a version of a communication protocol corresponding to the interface type.

[0194] According to an embodiment, a method performed by an E2 node includes sending an E2 setup request message to a near real-time (RT) radio access network (RAN) intelligent controller (RIC). The method includes receiving an E2 setup response message from the near RT RIC. The E2 setup request message includes a message type of the E2 setup request message, a transaction ID of the E2 setup request message, a global ID of the E2 node, a RAN function addition list including a RAN function ID, RAN function definition information, RAN revision information, and a RAN object ID (OID), information for identifying an interface type of the E2 node, and information for identifying a version of a communication protocol corresponding to the interface type.

[0195] According to an embodiment, a method performed by a near real-time (RT) radio access network (RAN) intelligent controller (RIC) includes receiving an E2 setup request message from an E2 node. The method includes sending an E2 setup response message to the E2 node. The E2 setup request message includes a message type of the E2 setup request message, a transaction ID of the E2 setup request message, a global ID of the E2 node, a RAN function addition list including a RAN function ID, RAN function definition information, RAN revision information, and a RAN object ID (OID), information for identifying an interface type of the E2 node, and information for identifying a version of a communication protocol corresponding to the interface type.

[0196] In the above-described embodiments, an example in which the E2 setup request message includes information indicating the version information of the 3GPP specification has been described, but embodiments of the present disclosure are not limited thereto. According to an embodiment, the information indicating the version information of the 3GPP specification may be included in the E2 setup response message. By receiving the version information of the 3GPP specification of the E2 setup response message, the E2 node can identify the version information of the interface of the E2 node identified by the near RT RIC. According to another embodiment, the information indicating the version information of the 3GPP specification may be included in the E2 node configuration update message. In the case where the version information of the 3GPP specification has not been delivered during the E2 setup process, the E2 node can provide the version information of the 3GPP specification of the interface to the near RT RIC through the E2 node configuration update process.

[0197] Various embodiments of the present disclosure may be implemented as software including one or more instructions stored in a machine-readable storage medium (e.g., a device that executes the functions of the E2 node 1000, a device that executes the functions of the near RT RIC 1100). It can be that, for example, a processor (e.g., the controller 530) of a machine (e.g., the E2 node 1000, the near RT RIC 1100) calls at least one command among one or more instructions stored from the storage medium and enables the machine to be operated to execute at least one function according to the at least one called instruction. The one or more instructions include code generated by a compiler or code executable by an interpreter. The machine-readable storage medium may be provided in the form of a non-transitory storage medium. The term "non-transitory" indicates that the storage medium is tangible and does not include signals (e.g., electromagnetic waves), and this term does not distinguish between the case where data is stored semi-permanently in the storage medium and the case where data is stored temporarily in the storage medium. O-RAN makes it possible to configure a virtualized intelligent network with standardized open interfaces. For network virtualization, operations according to embodiments may be implemented in the form of a recording medium (e.g., a memory).

[0198] According to an embodiment, a method according to various embodiments of the present disclosure may be included and provided in a computer program product. The computer program product may be traded as a commodity between a seller and a buyer. The computer program product is distributed in the form of a device-readable storage medium (e.g., a compact disc read-only memory (CD-ROM)), or is distributed online (e.g., downloaded or uploaded) through an application store (e.g., PlayStore TM ) or directly between two user devices (e.g., smart phones). In the case of online distribution, at least a part of the computer program product may be temporarily stored or temporarily created in a device-readable storage medium such as a memory of a server of a manufacturer, an application store server, or a relay server.

[0199] According to various embodiments, each of the components described above (e.g., a module or a program) may include a single entity or multiple entities, and some of the multiple entities may be separately provided in other components. According to various embodiments, one or more of the foregoing corresponding components or operations may be omitted, or one or more other components or operations may be added. Alternatively or additionally, multiple components (e.g., modules or programs) may be integrated into a single component. In this case, the integrated component may perform one or more functions of each of the multiple components in the same or similar manner as the corresponding components among the multiple components performed before integration. According to various embodiments, the operations performed by a module, a program, or other components are performed sequentially, in parallel, iteratively, or heuristically, or one or more operations are performed in a different order or omitted, or one or more other actions may be added.

[0200] The method according to one or more embodiments described in the claims and / or the specification of the present disclosure may be implemented in hardware, software, or a combination of hardware and software.

[0201] When implemented in software, a computer-readable storage medium storing one or more programs (software modules) may be provided. One or more programs stored in such a computer-readable storage medium are configured to be executed by one or more processors in an electronic device. One or more programs may include instructions for causing the electronic device to perform the method according to the embodiments described in the claims or the specification of the present disclosure.

[0202] Such a program (e.g., a software module, software) may be stored in a random access memory, a non-volatile memory including a flash memory, a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic disk storage device, a compact disk-ROM (CD-ROM), a digital versatile disk (DVD), other types of optical storage devices, or a magnetic tape cartridge. Alternatively, it may be stored in a memory configured with a combination of some or all of the above. In addition, memories with corresponding configurations may be provided in a plurality of numbers.

[0203] In addition, the program may 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 communication network configured with a combination thereof. Such a storage device may access the device performing the embodiments of the present disclosure through an external port. In addition, a separate storage device on the communication network may access the device performing the embodiments of the present disclosure.

[0204] In the specific embodiments of the present disclosure described so far, the components included therein have been expressed in singular or plural forms according to the embodiments presented. However, for the sake of convenience in description, such singular or plural expressions may be appropriately selected for the presented context, and the present disclosure is not limited to the singular or plural components. Therefore, it should be noted that even if any component is expressed in the plural, it may be configured by a single element, or even if any component is expressed in the singular, it may be configured by plural elements.

[0205] Meanwhile, although specific embodiments have been described in the above detailed description of the present disclosure, it will be apparent to those skilled in the art that various modifications can be made without departing from the scope of the present disclosure.

Claims

1. A method performed by an E2 node, the method comprises: sending an E2 setup request message to a near real-time (RT) radio access network (RAN) intelligent controller (RIC); and receiving an E2 setup response message from the near RT RIC, wherein the E2 setup request message comprises: information for identifying the interface type of the E2 node, and information for identifying the version of the communication protocol corresponding to the interface type.

2. The method according to claim 1, wherein the information for identifying the interface type of the E2 node comprises one of an X2 interface, an Xn interface, an F1 interface, an S2 interface, an E2 interface, an NG interface, and a W1 interface, wherein the communication protocol comprises an application protocol according to Technical Specification (TS) 36.423, TS 38.423, TS 38.473, TS 36.413, TS38.463, TS 38.413, or TS 37.

473.

3. The method according to claim 1, wherein the E2 setup request message comprises an information element (IE) regarding an E2 node component configuration addition list, and wherein the IE comprises information for identifying the interface type of the E2 node and information for identifying the version of the communication protocol.

4. The method according to claim 1, wherein the E2 setup request message comprises an information element (IE) of the E2 node component interface type regarding an E2 node component configuration addition item, and, wherein the IE comprises information for identifying the interface type of the E2 node and information for identifying the version of the communication protocol.

5. The method according to claim 1, wherein the version is indicated based on three octet strings of information for identifying the version of the communication protocol, and wherein the three octet strings comprise a first octet string indicating release information, a second octet string indicating update information of the release information, and a third octet string indicating edit information.

6. A method performed by a near real-time (RT) radio access network (RAN) intelligent controller (RIC), the method comprises: receiving an E2 setup request message from an E2 node; and sending an E2 setup response message to the E2 node, wherein the E2 setup request message comprises: information for identifying the interface type of the E2 node, and information for identifying the version of the communication protocol corresponding to the interface type.

7. The method according to claim 6, wherein the information for identifying the interface type of the E2 node comprises one of an X2 interface, an Xn interface, an F1 interface, an S2 interface, an E2 interface, an NG interface, and a W1 interface, wherein the communication protocol comprises an application protocol according to Technical Specification (TS) 36.423, TS 38.423, TS 38.473, TS 36.413, TS38.463, TS 38.413, or TS 37.

473.

8. The method according to claim 6, wherein the E2 setup request message comprises an information element (IE) regarding an E2 node component configuration addition list, and Wherein, the IE includes information for identifying the interface type of the E2 node and information for identifying the version of the communication protocol.

9. The method according to claim 6, wherein, the E2 establishment request message includes an information element (IE) of the E2 node component interface type regarding the E2 node component configuration addition item, and wherein, the IE includes information for identifying the interface type of the E2 node and information for identifying the version of the communication protocol.

10. The method according to claim 6, wherein, the version is indicated based on three octet strings of information for identifying the version of the communication protocol, and wherein, the three octet strings include a first octet string indicating release information, a second octet string indicating update information of the version information, and a third octet string indicating edit information.

11. The method according to claim 6, further comprising: identifying whether the Abstract Syntax Notation One (ASN1) library supports the version; in the case where the ASN1 library does not support the version, identifying whether the function according to the version is supported in the near real-time (RT) Radio Access Network (RAN) Intelligent Controller (RIC) based on the xApp of the near RT RIC; and in the case where the function is supported in the near RT RIC, sending a request message for an ASN1 library that supports the version to the E2 node through the xApp.

12. A device of an E2 node, the device comprising: at least one transceiver; and at least one processor, coupled to the at least one transceiver, wherein, the at least one processor is configured to: send an E2 establishment request message to a near real-time (RT) Radio Access Network (RAN) Intelligent Controller (RIC), and receive an E2 establishment response message from the near RT RIC, wherein, the E2 establishment request message includes: information for identifying the interface type of the E2 node, and information for identifying the version of the communication protocol corresponding to the interface type.

13. The device according to claim 12, wherein, the at least one processor is configured according to one of the methods of claims 2 to 5.

14. A device of a near real-time (RT) Radio Access Network (RAN) Intelligent Controller (RIC), the device comprising: at least one transceiver; and at least one processor, coupled to the at least one transceiver, wherein, the at least one processor is configured to: receive an E2 establishment request message from the E2 node, and send an E2 establishment response message to the E2 node, wherein, the E2 establishment request message includes: information for identifying the interface type of the E2 node, and information for identifying the version of the communication protocol corresponding to the interface type.

15. The device according to claim 14, wherein, the at least one processor is configured according to one of the methods of claims 7 to 11.

Images