Apparatus and method for supporting operator specific service in radio access network

Abstract

The present disclosure relates to a 5G (5th generation) or pre-5G communication system for supporting higher data transmission rates than a 4G (4th generation) communication system such as LTE (Long Term Evolution). A method of operation of a device using an interface between a node constituting a RIC (radio access network intelligent controller) and a base station in a radio access network includes the steps of generating first information related to an RIC service, generating second information indicating the type of message to be used to transmit the first information, and transmitting the message including the first information and the second information.

Description

Technology Field

[0001] The present disclosure generally relates to wireless access networks, and more specifically to an apparatus and method for supporting operator-specific services in a wireless access network included in a wireless communication system. Background Technology

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

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

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

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

[0006] With the commercialization of 5G systems and NR (new radio or next radio) to meet the demand for wireless data traffic, it is expected that high data transmission rate services will be provided to users through 5G systems, similar to 4G, and that wireless communication services for various purposes, such as the Internet of Things and services requiring high reliability for specific purposes, can be provided. The O-RAN (open radio access network), established by operators and equipment providers in a system currently mixed with 4th and 5th generation communication systems, defines new NE (network element) and interface specifications based on existing 3GPP standards and presents the O-RAN structure. The problem to be solved

[0007] Based on the discussion above, the present disclosure provides an apparatus and method for supporting operator-specific services in a radio access network (RAN).

[0008] In addition, the present disclosure provides an apparatus and method for generating and interpreting messages related to a service model (SM) in a wireless access network. means of solving the problem

[0009] According to various embodiments of the present disclosure, a method of operation of a device using an interface between a node constituting a radio access network intelligent controller (RIC) and a base station in a wireless access network may include a process of generating first information related to an RIC service, a process of generating second information indicating a type of message to be used to transmit the first information, and a process of transmitting the message including the first information and the second information.

[0010] According to various embodiments of the present disclosure, a method of operation of a device using an interface between a node constituting a radio access network intelligent controller (RIC) and a base station in a wireless access network may include the process of receiving a message containing first information related to an RIC service, the process of determining the type of the message based on second information indicating the type of the message included in the message, and the process of obtaining the first information based on the second information.

[0011] According to various embodiments of the present disclosure, a device using an interface between a node constituting a radio access network intelligent controller (RIC) and a base station in a wireless access network comprises a transceiver and at least one processor connected to the transceiver. The at least one processor can generate first information related to an RIC service, generate second information indicating the type of message to be used to transmit the first information, and control the transmission of the message including the first information and the second information.

[0012] According to various embodiments of the present disclosure, a device using an interface between a node constituting a radio access network intelligent controller (RIC) and a base station in a wireless access network includes a transceiver and at least one processor connected to the transceiver. The at least one processor can receive a message containing first information related to an IC service, identify the type of the message based on second information indicating the type of the message included in the message, and control the acquisition of the first information based on the second information. Effects of the invention

[0013] The apparatus and method according to various embodiments of the present disclosure can support a radio access network intelligent controller (RIC) service model defined specifically by the operator.

[0014] The effects obtainable from the present disclosure are not limited to those mentioned above, and other unmentioned effects will be clearly understood by those skilled in the art to which the present disclosure belongs from the description below. Brief explanation of the drawing

[0015] Fig. 1 is 4G(4 th An example of a generation) LTE (Long Term Evolution) core system is illustrated. Figure 2 shows 5G (5 th Illustrates an example of a generational NSA (non-standard alone) system. FIG. 3 illustrates a protocol stack of an E2 application protocol message in a wireless access network according to various embodiments of the present disclosure. FIG. 4 illustrates an example of a connection between a base station and a radio access network intelligence controller (RIC) in a wireless access network according to various embodiments of the present disclosure. FIG. 5 illustrates the configuration of a device in a wireless access network according to various embodiments of the present disclosure. FIG. 6 illustrates the logical functions related to E2 messages of an E2 node and an RIC in a wireless access network according to various embodiments of the present disclosure. FIG. 7 illustrates the setup, subscription, and provision of information of an E2 I / F between an E2 node and a RIC in a wireless access network according to various embodiments of the present disclosure. FIG. 8 illustrates a procedure for E2 RIC control between an E2 node and an RIC in a wireless access network according to various embodiments of the present disclosure. FIG. 9 illustrates a flowchart for generating and transmitting an E2 message in a wireless access network according to various embodiments of the present disclosure. FIG. 10 illustrates a flowchart for receiving and interpreting an E2 message in a wireless access network according to various embodiments of the present disclosure. Specific details for implementing the invention

[0016] The terms used in this disclosure are used merely to describe specific embodiments and are not intended to limit the scope of other embodiments. A singular expression may include a plural expression unless the context clearly indicates otherwise. Terms used herein, including technical or scientific terms, may have the same meaning as generally understood by those skilled in the art described in this disclosure. Terms used in this disclosure that are defined in a general dictionary may be interpreted as having the same or similar meaning as they have in the context of the relevant technology, and are not to be interpreted in an ideal or overly formal sense unless explicitly defined in this disclosure. In some cases, even terms defined in this disclosure are not to be interpreted to exclude the embodiments of this disclosure.

[0017] In the various embodiments of the present disclosure described below, a hardware-based approach is described as an example. However, since the various embodiments of the present disclosure include techniques using both hardware and software, the various embodiments of the present disclosure do not exclude a software-based approach.

[0020] The present disclosure describes a technology for providing a service owned by an operator through an E2 interface (I / F) when performing operations such as subscription, indication, and control between a device within a radio access network (RAN) of a wireless communication system and a device controlling the RAN.

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

[0022] Additionally, the present disclosure describes various embodiments using terms used in some communication standards (e.g., 3GPP (3rd Generation Partnership Project)), but this is merely illustrative. Various embodiments of the present disclosure can be easily modified and applied to other communication systems.

[0024] 4th generation (4 th generation, 4G) / 5th generation(5 thWith the commercialization of generation, 5G) communication systems (e.g., NR (new radio)), there is a demand for differentiated service support for users in virtualized networks. Accordingly, the O-RAN (open radio access network) has newly defined the nodes constituting the 3GPP NE (network entity) and base stations—namely the RU (radio unit), DU (digital unit), CU (central unit)-CP (control plane), and CU-UP (user plane)—as O(O-RAN)-RU, O-DU, O-CU-CP, and O-CU-UP, respectively, and additionally standardized the NRT (near-real-time) RIC (radio access network intelligent controller). This disclosure is intended to support an operator-specific service model at the E2 interface where the RIC requests services from the O-DU, O-CU-CP, or O-CU-UP. Here, O-RU, O-DU, O-CU-CP, and O-CU-UP can be understood as objects constituting a RAN capable of operating according to O-RAN specifications and can be referred to as E2 nodes. The interface between the RIC and E2 nodes and the objects constituting a RAN capable of operating according to O-RAN specifications uses E2AP (application protocol).

[0025] An RIC is a logical node capable of collecting information from cell sites where terminals, O-DUs, O-CU-CPs, or O-CU-UPs transmit and receive data. RICs can be implemented in the form of servers centrally deployed in a single physical location. Connections can be established between the O-DU and RICs, between the O-CU-CP and RICs, and between the O-CU-UP and RICs via Ethernet. To this end, interface specifications for communication between the O-DU and RICs, between the O-CU-CP and RICs, and between the O-CU-UP and RICs have become necessary, and the definition of message specifications for E2-DU, E2-CU-CP, and E2-CU-UP, as well as procedures between the O-DU, O-CU-CP, O-CU-UP, and RICs, is required. In particular, as differentiated service support is required for users in virtualized networks, it is necessary to define the functions of E2-DU, E2-CU-CP, and E2-CU-UP messages to support services for extensive cell coverage by centralizing call processing messages / functions generated in O-RAN into the RIC.

[0026] Specifically, the RIC communicates with the O-DU, O-CU-CP, and O-CU-UP using the E2 interface and can set event occurrence conditions by generating and transmitting subscription messages, or transmit via E2 indication / report. Control over the O-DU, O-CU-CP, and O-CU-UP is provided using E2 control messages.

[0028] Fig. 1 is 4G(4 th An example of a generation) LTE (Long Term Evolution) core system is illustrated.

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

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

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

[0032] The S-GW (130) provides data bearers and creates or controls data bearers under the control of the MME (150). For example, the S-GW (130) processes packets received from the base station (110) or packets to be forwarded to the base station (110). Additionally, the S-GW (130) can act as an anchor during handover between base stations of the terminal (120). The P-GW (140) can function as a connection point with an external network (e.g., the Internet network). Additionally, the P-GW (140) assigns an IP (Internet Protocol) address to the terminal (120) and acts as an anchor for the S-GW (130). Furthermore, the P-GW (140) applies the QoS (Quality of Service) policy of the terminal (120) and can manage account data.

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

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

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

[0036] Carrier aggregation (hereinafter 'CA') technology is a technology that increases frequency usage efficiency from the perspective of a terminal or a base station by combining multiple component carriers and enabling a single terminal to transmit and receive signals using these multiple component carriers simultaneously. Specifically, according to CA technology, a terminal and a base station can transmit and receive signals using broadband by utilizing multiple component carriers in the uplink (UL) and downlink (DL), respectively, and each component carrier is located in a different frequency band. Hereinafter, the uplink refers to the communication link through which a terminal transmits a signal to a base station, and the downlink refers to the communication link through which a base station transmits a signal to a terminal. In this case, the number of uplink component carriers and downlink component carriers may differ.

[0037] Dual connectivity or multi-connectivity is a technology that increases frequency usage efficiency from the perspective of the terminal or base station by connecting a single terminal to multiple different base stations and simultaneously transmitting and receiving signals using carrier waves within each base station located in different frequency bands. The terminal connects to a first base station (e.g., a base station providing services using LTE technology or 4th generation mobile communication technology) and a second base station (e.g., NR (new radio) technology or 5G (5 th It can simultaneously connect to base stations that provide services using mobile communication technology (generation) and transmit and receive traffic. At this time, the frequency resources used by each base station may be located in different bands. A method that operates based on the dual connection method of LTE and NR in this way can be called 5G NSA (non-standalone).

[0039] Figure 2 illustrates an example of a 5G NSA system.

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

[0041] In a structure like that of FIG. 2, the terminal (220) can perform radio resource control (RRC) access through a first base station (e.g., a base station belonging to the LTE RAN (210b)) and receive services for functions provided by the control plane (e.g., connection management, mobility management, etc.). Additionally, the terminal (220) can receive additional radio resources for transmitting and receiving data through a second base station (e.g., a base station belonging to the NR RAN (210a)). This dual connectivity technology using LTE and NR may be referred to as EN-DC (E-UTRA (evolved universal terrestrial radio access) - NR dual connectivity). Similarly, a dual connectivity technology in which the first base station uses NR technology and the second base station uses LTE technology is referred to as NE-DC (NR - E-UTRA dual connectivity). Furthermore, various embodiments may be applied to various other forms of multiple connectivity and carrier aggregation technologies. In addition, various embodiments may be applied in cases where a first system using a first communication technology and a second system using a second communication technology are implemented in a single device, or where a first base station and a second base station are located in the same geographical location.

[0043] FIG. 3 illustrates a protocol stack of an E2 application protocol message in a wireless access network according to various embodiments of the present disclosure. Referring to FIG. 4, 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).

[0044] The wireless network layer includes an E2AP (350). The E2AP (350) is used to transmit subscription messages, indication messages, control messages, service update messages, and service query messages, and is transmitted above the SCTP (3400) and IP (330).

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

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

[0048] FIG. 4 illustrates a single RIC (440), but according to various embodiments, multiple RICs may exist. Multiple RICs may be implemented as multiple hardware located at the same physical location or through virtualization using a single hardware.

[0050] FIG. 5 illustrates the configuration of a device according to various embodiments of the present disclosure. The structure exemplified in FIG. 5 can be understood as the configuration of a device having at least one of the functions of the RIC, O-CU-CP, O-CU-UP, and O-DU of FIG. 5. Terms such as ‘… unit’, ‘… unit’ used below refer to a unit that processes at least one function or operation, and this may be implemented in hardware or software, or a combination of hardware and software.

[0051] Referring to FIG. 5 above, the core network device is configured to include a communication unit (510), a storage unit (520), and a control unit (530).

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

[0053] The storage unit (520) stores data such as basic programs, application programs, and configuration information for the operation of the core network device. The storage unit (520) may be composed of volatile memory, non-volatile memory, or a combination of volatile memory and non-volatile memory. Additionally, the storage unit (520) provides the stored data upon the request of the control unit (530).

[0054] The control unit (530) controls the overall operations of the core network device. For example, the control unit (530) transmits and receives signals through the communication unit (510). Additionally, the control unit (530) writes and reads data to and from the storage unit (520). To this end, the control unit (530) may include at least one processor. According to various embodiments, the control unit (530) may control the device to perform operations according to the various embodiments described in this disclosure.

[0056] FIG. 6 illustrates the logical functions related to E2 messages of an E2 node and an RIC in a wireless access network according to various embodiments of the present disclosure.

[0057] Referring to FIG. 6, the RIC (640) and the E2 node (610) can transmit or receive E2 messages to or from each other. For example, the E2 node (610) may be an O-CU-CP, O-CU-UP, O-DU, or base station. The E2 node (610) includes an E2 node function (612). The E2 node function (612) is a function corresponding to a specific xApp (application S / W) (646) installed in the RIC (640). For example, in the case of a KPI monitor, the KPI monitor collection S / W is installed in the RIC (540), and the E2 node (610) may include an E2 node function (612) that generates KPI parameters and then transmits an E2 message containing the KPI parameters to an E2 termination function (642) located in the RIC (640). The E2 termination function (642) located in the RIC (640) is the termination of the RIC (640) for the E2 message, and performs the function of interpreting the E2 message transmitted by the E2 node (610) and then transmitting it to the xApp (646). The E2 node (610) shown in FIG. 6 is the termination of at least one interface and can be understood as the termination of messages transmitted to the terminal, surrounding base station, and core network.

[0059] FIG. 7 illustrates the setup, subscription, and provision of information of an E2 I / F between an E2 node and a RIC in a wireless access network according to various embodiments of the present disclosure.

[0060] Referring to FIG. 7, in step 701, the E2 node (610) sends an E2 setup request message to the RIC (640). That is, the E2 node function located at the E2 node (610) searches for the RIC (640) using the IP address of the RIC (640) configured as OAM (operation-administration-maintenance) and sends the E2 setup request message. The E2 setup request message may include an information element (IE) (e.g., RAN FUNCTION DEFINITION) of the RAN function capability supported by the E2 node (610), an E2 node ID, etc. The value of the RAN FUNCTION DEFINITION is a value configured as OAM and may include the RIC STYLE ID value. RIC (640) receives the RAN FUNCTION DEFINITION value through an E2 configuration message or an E2 SERVICE UPDATE message, and can determine which call processing function the E2 node (610) supports based on the RAN FUNCTION DEFINITION value.

[0061] In step 703, the RIC (640) sends an E2 setup response message to the E2 node (610). That is, if the E2 setup request message sent by the E2 node (610) can be accepted, the RIC (640) sends an E2 setup response message.

[0062] In step 705, the RIC (640) sends a RIC subscription request message to the E2 node (610). In other words, a specific xApp located in the RIC (640) requests a subscription from the RIC E2 endpoint function for a specific E2 RAN FUNCTION DEFINITION function supported by E2. Here, the E2 RAN FUNCTION DEFINITION may be an operator-specific service model (SM), and operator specificity may be indicated using a RIC STYLE ID. Operator specificity may be indicated by an IE other than the RIC STYLE ID. According to another embodiment, the RIC subscription request message may be included in the E2 configuration response message sent in step 703.

[0063] In step 707, the E2 node (610) sends a RIC subscription response message to the RIC (640). That is, the E2 node function of the E2 node (610) decodes the RIC subscription request message and configures the event condition requested by the RIC (640) to the E2 node function. Here, the event condition may be a service model specifically defined by the RAN FUNCTION DEFINITION, and whether it is specific to the operator may be specified by the RIC STYLE ID. After successfully configuring the event condition, the E2 node (610) can notify the RIC (640) that the event trigger condition has been successfully configured by sending a RIC subscription response message.

[0064] In step 709, the E2 node (610) sends an RIC indicator to the RIC (640). For example, if a specific event condition is satisfied, the E2 node (610) sends an E2 RIC indicator message to the RIC (640). The RIC indicator may be a message container. The RIC indicator message may be an operator-specific service model, and whether it is user-specific may be specified by the RIC STYLE ID.

[0065] In step 711, the E2 node (610) sends an E2 service update message to the RIC (640). For example, as a change occurs in the IE value of the RAN FUNCTION DEFINITION, the E2 node (610) sends the changed RAN FUNCTION DEFINITION using the E2 service update message.

[0067] FIG. 8 illustrates a procedure for E2 RIC control between an E2 node and an RIC in a wireless access network according to various embodiments of the present disclosure.

[0068] Referring to FIG. 8, in step 801, the E2 node (610) and the RIC (640) perform an E2 configuration procedure. The E2 node function located at the E2 node (610) can identify the RIC (640) using the IP address of the RIC (640) configured as OAM, and then notify the E2 node (610) of which call processing function it supports by sending an E2 configuration request message. In response, the RIC (640) can send an E2 configuration response message to the E2 node (610).

[0069] In step 803, the RIC (640) sends a RIC subscription request message to the E2 node (610). In other words, a specific xApp located in the RIC (640) requests a subscription from the RIC E2 endpoint function for a specific E2 RAN FUNCTION DEFINITION function supported by E2. Here, the E2 RAN FUNCTION DEFINITION may be an operator-specific service model (SM), and operator specificity may be indicated using a RIC STYLE ID. Operator specificity may be indicated by an IE other than the RIC STYLE ID. According to another embodiment, the RIC subscription request message may be included in the E2 configuration response message sent in step 703. When the E2 node (640) supports an operator-specific service model, the operator-specific subscription may be configured using a RIC event trigger definition.

[0070] In step 805, the E2 node (610) sends an E2 subscription response message to the RIC (640). That is, by sending the subscription response message, the E2 node (610) can notify the RIC (640) of the success or failure of the operator-specific subscription.

[0071] In step 807, the E2 node (610) transmits an RIC INDICATION to the RIC (640). For example, when an event occurs that satisfies the operator-specific event trigger condition configured by a subscription request message, the E2 node function of the E2 node (610) transmits an E2 RIC INDICATION message to the RIC (640). The RIC INDICATION may be a message container. In this case, the E2 INDICATION message may be transmitted as an operator-specific message type. According to one embodiment, whether it is an operator-specific message may be indicated by the RIC INDICATION HEADER TYPE, RIC INDICATION MESSAGE TYPE, or RIC STYLE ID.

[0072] In step 809, the RIC (640) sends an E2 control request message to the E2 node (610). By sending the E2 control request message to the E2 node function, the RIC (640) can control the event that occurred in step 807. At this time, the E2 control message may be transmitted as an operator-specific message type. According to one embodiment, whether it is an operator-specific message may be indicated by the RIC CONTROL HEADER TYPE, RIC CONTROL MESSAGE TYPE, or RIC STYLE ID.

[0074] FIG. 9 illustrates a flowchart (900) for generating and transmitting an E2 message in a wireless access network according to various embodiments of the present disclosure. FIG. 9 illustrates a method of operation of an E2 node or RIC. Since the E2 message can be transmitted by an E2 node or RIC, the entity operating in the flowchart (900) of FIG. 9 below may be understood as an E2 node or RIC. For convenience of explanation, the entity operating in the flowchart (900) of FIG. 9 is referred to as a 'device'.

[0075] Referring to FIG. 9, in step 901, the device generates information related to RIC services. Here, the services may be related to operations to support wireless access performed at the E2 node. For example, the services may be related to operations such as call processing, call connection, call acceptance determination, handover, carrier aggregation, and duplexing. In this case, depending on the related operations, the information related to RIC services may follow a format defined in the standard or a format specific to the operator.

[0076] In step 903, the device generates information indicating a message type. The message type corresponds to the RIC service corresponding to the information generated in step 901. At this time, the value of the information indicating the message type falls within the first range if the information related to the RIC service follows the format defined in the standard, and may fall within the second range if the information related to the RIC service does not follow the format defined in the standard. Here, the second range is a range that includes values ​​allocated for services specifically defined by the operator.

[0077] In step 905, the device transmits an E2 message. The device generates an E2 message containing the information generated in step 901 and the information generated in step 903, and transmits the generated E2 message.

[0079] FIG. 10 illustrates a flowchart (1000) for receiving and interpreting an E2 message in a wireless access network according to various embodiments of the present disclosure. FIG. 10 illustrates a method of operation of an E2 node or RIC. Since the E2 message can be transmitted by an E2 node or RIC, the entity operating in the flowchart (1000) of FIG. 10 can be understood as an E2 node or RIC. For convenience of explanation, the entity operating in the flowchart (1000) of FIG. 10 is referred to as a 'device'.

[0080] Referring to FIG. 10, in step 1001, the device receives an E2 message. The E2 message may include information related to the RIC service and information indicating the type of message.

[0081] In step 1003, the device checks the type of the message. That is, the message contains information indicating the type. Information indicating the type may be included in a fixed location regardless of whether the format of the message is carrier-specifically defined. For example, if the value of the information indicating the message type falls within a first range, the device can determine that the received E2 message conforms to one of the formats defined in the standard. As another example, if the value of the information indicating the message type falls within a second range, the device can determine that the received E2 message does not conform to one of the formats defined in the standard but conforms to a carrier-specifically defined format. The second range is a range that includes values ​​assigned for carrier-specifically defined services.

[0082] In step 1005, the device obtains information from the message according to the type. If the value of the information indicating the message type falls within the first range, the device can analyze the received E2 message based on one of the formats defined in the standard and obtain information related to the RIC service. If the value of the information indicating the message type falls within the second range, the device can analyze the E2 message based on the received operator-specific format and obtain information related to the RIC service.

[0084] As described above, various E2 messages may be used for procedures performed between E2 nodes and RICs. In this case, a service model specifically defined by an operator, rather than a service model defined in the standard, may be used. When a service model specifically defined by an operator is used, messages related to said service model follow a structure or format defined by said operator. In this case, information or indicators to indicate that the structure or format of the message is defined by the operator may be included in the message. For example, various messages including information or indicators to indicate that the structure or format of the message is defined by the operator may be defined as shown in [Table 1] through [Table 9] below.

[0086] IE / Group Name Presence Range IE type and reference Semantics description RIC EVENT TRIGGER DEFINITION TYPE M 1.. <maxoftype>< / maxoftype> x.x.x Type number 129~256 is reserved for the operator-specific use. RIC Style ID M 　 8.3.3 　 E2SM-xxx-IE2 M 　 8.3.12 　 E2SM-xxx-IE3 M 　 8.3.13 　 RIC Parameter Type M 8.3.5 　 Sequence of E2SM-xxx-IE4 　 0.. <maxofie>< / maxofie> 　 　 > RIC Parameter ID M 　 8.3.6 　 > RIC Parameter Test Condition O 　 8.3.7 　 > RIC Parameter Value O 　 8.3.8

[0087] [Table 1] shows the RIC EVENT TRIGGER DEFINITION included in the E2 sign-up request message This is an example of IE. According to one embodiment, the RIC EVENT TRIGGER DEFINITION TYPE field is defined, thereby allowing up to 256 RIC EVENT TRIGGERS to be defined, and among the 256 types, values ​​in the range from 129 to 256 can be used as a non-standard method by being defined by the business operator. For example, if the RIC EVENT TRIGGER DEFINITION TYPE field is defined as one of the values ​​from 129 to 256, the RIC EVENT TRIGGER DEFINITION The remaining fields included in IE may be configured specifically for the carrier. In other words, at least one of the remaining fields, excluding the RIC EVENT TRIGGER DEFINITION TYPE field exemplified in [Table 1], may be omitted, and at least one other field may be added. The newly added field may be a field not defined in the standard, and the setting and interpretation of its value may follow carrier-specific rules.

[0089] IE / Group Name Presence Range IE type and reference Semantics description RIC ACITION DEFINITION TYPE M 0.. <maxoftype>< / maxoftype> Type number 129~256 is reserved for the operator-specific use. RIC Style ID M 　 8.3.3 　 Sequence of RIC Parameters 　 0.. <maxofparameters>< / maxofparameters> 　 　 >RIC Parameter ID M 　 8.3.6 　 >RIC Parameter Value M 　 8.3.8

[0090] [Table 2] is an example of a RIC ACTION DEFINITION IE included in an E2 subscription request message. According to one embodiment, a RIC ACTION DEFINITION TYPE field is defined, thereby allowing up to 256 RIC ACTION DEFINITIONS to be defined. Among the 256 types, values ​​in the range of 129 to 256 may be used as non-standard methods by being defined by the operator. For example, if the RIC ACTION DEFINITION TYPE field is defined as one of the values ​​from 129 to 256, the remaining fields included in the RIC ACTION DEFINITION IE may be configured specifically by the operator. In other words, at least one of the remaining fields other than the RIC ACTION DEFINITION TYPE field exemplified in [Table 2] may be omitted, and at least one other field may be added. The newly added field may be a field not defined in the standard, and the setting and interpretation of its value may follow operator-specific rules.

[0092] IE / Group Name Presence Range IE type and reference Semantics description RIC INDICATION HEADER TYPE M 0.. <maxoftype>< / maxoftype> Type number 129~256 is reserved for the operator-specific use. RIC Style ID M 　 8.3.3 　 E2SM-xxx-IE2 M 　 8.3.12 　 E2SM-xxx-IE3 M 　 8.3.13 　 E2SM-xxx-IE4 O 　 8.3.14

[0093] [Table 3] is an example of a RIC INDICATION HEADER IE included in an E2 instruction message. According to one embodiment, a RIC INDICATION HEADER TYPE field is defined, thereby allowing up to 256 RIC INDICATION HEADERs to be defined, and among the 256 types, values ​​in the range of 129 to 256 may be used as non-standard methods by being defined by the operator. For example, if the RIC INDICATION HEADER TYPE field is defined as one of the values ​​from 129 to 256, the remaining fields included in the RIC INDICATION HEADER IE may be configured specifically by the operator. In other words, at least one of the remaining fields other than the RIC INDICATION HEADER TYPE field exemplified in [Table 3] may be omitted, and at least one other field may be added. The newly added field may be a field not defined in the standard, and the setting and interpretation of its value may follow operator-specific rules.

[0095] IE / Group Name Presence Range IE type and reference Semantics description RIC INDICATION MESSAGE TYPE M 0.. <maxoftype>< / maxoftype> Type number 129~256 is reserved for the operator-specific use. RAN Container M 　 8.3.11

[0096] [Table 4] is an example of a RIC INDICATION MESSAGE IE included in an E2 instruction message. According to one embodiment, a RIC INDICATION MESSAGE TYPE field is defined, thereby allowing up to 256 RIC INDICATION MESSAGES to be defined, and among the 256 types, values ​​in the range of 129 to 256 may be used as an alternative to the standard by being defined by the operator. For example, if the RIC INDICATION MESSAGE TYPE field is defined as one of the values ​​from 129 to 256, the remaining fields included in the RIC INDICATION MESSAGE IE may be configured specifically by the operator. In other words, at least one of the remaining fields other than the RIC INDICATION MESSAGE TYPE field exemplified in [Table 4] may be omitted, and at least one other field may be added. The newly added field may be a field not defined in the standard, and the setting and interpretation of its value may follow operator-specific rules.

[0098] IE / Group Name Presence Range IE type and reference Semantics description RIC CONTROL HEADER TYPE M 0.. <maxoftype>< / maxoftype> Type number 129~256 is reserved for the operator-specific use. RIC Style ID M 　 8.3.3 　 E2SM-xxx-IE M 　 8.3.12

[0099] [Table 5] is an example of a RIC CONTROL HEADER IE included in an E2 control message. According to one embodiment, a RIC CONTROL HEADER TYPE field is defined, thereby allowing up to 256 RIC CONTROL HEADERs to be defined, and among the 256 types, values ​​in the range of 129 to 256 may be used as non-standard methods by being defined by the operator. For example, if the RIC CONTROL HEADER TYPE field is defined as one of the values ​​from 129 to 256, the remaining fields included in the RIC CONTROL HEADER IE may be configured specifically by the operator. In other words, at least one of the remaining fields other than the RIC CONTROL HEADER TYPE field exemplified in [Table 5] may be omitted, and at least one other field may be added. The newly added field may be a field not defined in the standard, and the setting and interpretation of its value may follow operator-specific rules.

[0101] IE / Group Name Presence Range IE type and reference Semantics description RIC CONTROL MESSAGE TYPE M 0.. <maxoftype>< / maxoftype> Type number 129~256 is reserved for the operator-specific use. RAN Container M 　 8.3.11

[0102] [Table 6] is an example of a RIC CONTROL MESSAGE IE included in an E2 control message. According to one embodiment, a RIC CONTROL MESSAGE TYPE field is defined, thereby allowing up to 256 RIC CONTROL MESSAGES to be defined. Among the 256 types, values ​​in the range of 129 to 256 may be used as non-standard methods by being defined by the operator. For example, if the RIC CONTROL MESSAGE TYPE field is defined as one of the values ​​from 129 to 256, the remaining fields included in the RIC CONTROL MESSAGE IE may be configured specifically by the operator. In other words, at least one of the remaining fields other than the RIC CONTROL MESSAGE TYPE field exemplified in [Table 6] may be omitted, and at least one other field may be added. The newly added field may be a field not defined in the standard, and the setting and interpretation of its value may follow operator-specific rules.

[0104] IE / Group Name Presence Range IE type and reference Semantics description RIC CALL PROCESS ID TYPE M 0.. <maxoftype>< / maxoftype> Type number 129~256 is reserved for the operator-specific use. RAN Call process ID type 1 M 　 8.3.10

[0105] [Table 7] is an example of a RIC CALL PROCESS ID IE included in an E2 control message. According to one embodiment, a RIC CALL PROCESS ID TYPE field is defined, thereby allowing up to 256 RIC CALL PROCESS IDs to be defined. Among the 256 types, values ​​in the range of 129 to 256 may be used as non-standard methods by being defined by the operator. For example, if the RIC CALL PROCESS ID TYPE field is defined as one of the values ​​from 129 to 256, the remaining fields included in the RIC CALL PROCESS ID IE may be configured specifically by the operator. In other words, at least one of the remaining fields other than the RIC CALL PROCESS ID TYPE field exemplified in [Table 7] may be omitted, and at least one other field may be added. The newly added field may be a field not defined in the standard, and the setting and interpretation of its value may follow operator-specific rules.

[0107] IE / Group Name Presence Range IE type and reference Semantics description RAN FUNCTION DEFINITION TYPE M 0.. <maxoftype>< / maxoftype> Type number 129~256 is reserved for the operator-specific use. RAN Function Name M 　 8.3.2 　 Sequence of Event trigger styles 　 0.. <maxofstyle>< / maxofstyle> 　 　 >RIC Style ID M 　 8.3.3 　 >RIC Style Name M 　 8.3.4 　 >Sequence of paramters >>RIC Parameter ID M >>RIC Parameter Name M >>RIC Parameter Type M Sequence of Report styles 　 0.. <maxofstyle>< / maxofstyle> 　 　 >RIC Style ID M 　 8.3.3 　 >RIC Style Name M 　 8.3.4 　 >Sequence of parameters 　 0.. <maxofactionparameters>< / maxofactionparameters> 　 　 >>RIC Parameter ID M 　 8.3.6 　 >>RIC Parameter Name M 　 8.3.9 　 >>RIC Parameter Type M 　 8.3.5 　 Sequence of Insert styles 　 0.. <maxofstyle>< / maxofstyle> 　 　 >RIC Style ID M 　 8.3.3 　 >RIC Style Name M 　 8.3.4 　 >Sequence of parameters 　 0.. <maxofactionparameters>< / maxofactionparameters> 　 　 >>RIC Parameter ID M 　 8.3.6 　 >>RIC Parameter Name M 　 8.3.9 　 >>RIC Parameter Type M 　 8.3.5 　 Sequence of Control styles 　 0.. <maxofstyle>< / maxofstyle> 　 　 >RIC Style ID M 　 8.3.3 　 >RIC Style Name M 　 8.3.4 　 >Sequence of parameters 　 0.. <maxofactionparameters>< / maxofactionparameters> 　 　 >>RIC Parameter ID M 　 8.3.6 　 >>RIC Parameter Name M 　 8.3.9 　 >>RIC Parameter Type M 　 8.3.5 　 Sequence of Policy styles 　 0.. <maxofstyle>< / maxofstyle> 　 　 >RIC Style ID M 　 8.3.3 　 >RIC Style Name M 　 8.3.4 　 >Sequence of parameters 　 0.. <maxofactionparameters>< / maxofactionparameters> 　 　 >>RIC Parameter ID M 　 8.3.6 　 >>RIC Parameter Name M 　 8.3.9 　 >>RIC Parameter Type M 　 8.3.5

[0108] [Table 8] is an example of a RAN FUNCTION DEFINITION IE included in an E2 service update message. According to one embodiment, a RAN FUNCTION DEFINITION TYPE field is defined, thereby allowing up to 256 RAN FUNCTION DEFINITION TYPES to be defined, and among the 256 types, values ​​in the range of 129 to 256 may be used as an out-of-specification method by being defined by the operator. For example, if the RAN FUNCTION DEFINITION TYPE field is defined as one of the values ​​from 129 to 256, the remaining fields included in the RAN FUNCTION DEFINITION IE may be configured specifically by the operator. In other words, at least one of the remaining fields other than the RAN FUNCTION DEFINITION TYPE field exemplified in [Table 8] may be omitted, and at least one other field may be added. Newly added fields may be fields not defined in the standard, and the setting and interpretation of their values ​​may follow business-specific rules.

[0110] IE / Group Name Presence Range IE type and reference Semantics description RIC style ID M INTEGER (1~256) 129~256 is reserved for the operator-specific style ID.

[0111] [Table 9] is an example of a RIC STYLE ID. The RIC STYLE IDs defined in conventional O-RAN could only be used for E2 service models defined in the standard. The RIC STYLE IDs in [Table 9] define a range of 128 to 256 for operator-specific use, enabling the definition and use of specific operators or their unique functions. That is, the RIC STYLE IDs in [Table 9] can indicate operator-specific service models by replacing or using them in parallel with the various TYPE fields in [Table 1] through [Table 8] mentioned above.

[0112] In the examples of [Table 1] through [Table 9] above, values ​​129 through 256 of the values ​​of the type field or style ID field were assigned for carrier-specific messages. However, according to other embodiments, the range of values ​​of the type field or style ID field for carrier-specific messages may vary. Additionally, according to yet another embodiment, values ​​for carrier-specific messages may be defined as discrete values ​​rather than continuous values. For example, values ​​corresponding to multiples of a specific number may be assigned as values ​​for carrier-specific messages, or values ​​having the least significant bit (LSB) or most significant bit (MBS) of a specific value when expressed in binary or hexadecimal may be assigned as values ​​for carrier-specific messages.

[0114] As mentioned above, information regarding services defined in the standard, as well as information regarding services defined specifically by the operator, can be transmitted and received via E2 messages. Examples of operator-specific E2SMs are as follows. In order for an operator to support network slice ID-based RAN resource control in O-RAN that is not specified in the 3GPP standard, the operator may request a vendor to develop an E2 node xApp based on an operator-specific E2SM. To develop non-standard functions, the vendor may set the types of the E2SM functions exemplified below as operator-specific types. The correspondence relationship between each E2SM function and message is as shown in [Table 10] below.

[0115] RAN Function specific E2SM Information Elements RIC Event Trigger Definition (표1) RIC Action Definition (표 2) RIC Indication Header (표 3) RIC Indication Message (표 4) RIC Call Process ID (표 7) RIC Control Header (표 5) RIC Control Message (표 6) RAN Function Description (표8)

[0117] For network slice ID-based RAN resource control, the E2 node may use POLICY, CONTROL, and REPORT among the POLICY, CONTROL, REPORT, and INSERT services specified in the O-RAN specification. During the E2 interface configuration phase, the E2 node may transmit the operator-specific E2SM functions supported by the E2 node to the RIC using the RAN FUNCTION DESCRIPTION defined in [Table 8]. For example, the E2 node may set the RAN Function Definition Type defined in [Table 11] below to a value assigned as an operator-specific type (e.g., 129).

[0118] IE / Group Name RAN Function Name RAN Function Definition Type Sequence of Event trigger styles >RIC Style ID >RIC Style Name Sequence of Report styles >RIC Style ID >RIC Style Name >Sequence of parameters >>RIC Parameter ID >>RIC Parameter Name >>RIC Parameter Type Sequence of Insert styles >RIC Style ID >RIC Style Name >Sequence of parameters >>RIC Parameter ID >>RIC Parameter Name >>RIC Parameter Type Sequence of Control styles >RIC Style ID >RIC Style Name >Sequence of parameters >>RIC Parameter ID >>RIC Parameter Name >>RIC Parameter Type Sequence of Policy styles >RIC Style ID >RIC Style Name >Sequence of parameters >>RIC Parameter ID >>RIC Parameter Name >>RIC Parameter Type

[0120] By using messages defined according to various embodiments, an E2 node or RIC can set the RIC parameter value of the actual E2SM to a parameter desired by the operator. For example, in the case of network slice ID-based RAN resource control not provided in the standard, the E2 node or RIC can set the desired RIC parameter value to a value desired by the operator and set the RAN function name.

[0122] The POLICY SERVICE is transmitted from the RIC to the E2 node via the E2AP subscription message. The E2AP subscription message transmits the RIC Event Trigger Definition shown in [Table 1]. At this time, the RIC Event Trigger Definition is set to a value representing a specific subscriber type; for example, in [Table 12] below, the RIC EVENT TRIGGER DEFINITION TYPE value can be set to 129, the RIC Style ID value to 1, the RIC Parameter Type to Integer, and the Sequence of Trigger Conditions to RIC Parameter ID (NSSAI) is equal to '100'. E2-SM-IE is a value provided by the E2 node required by the operator, and it is possible to set any value, including standardized values ​​or non-standardized values.

[0123] IE / Group Name Presence Range IE type and reference Semantics description RIC EVENT TRIGGER DEFINITION TYPE M 1.. <maxoftype>< / maxoftype> Type number 129~256 is reserved for the operator-specific use. RIC Style ID M 8.3.3 RIC Parameter Type M 8.3.5 Sequence of Trigger Conditions 0.. <maxoftgc>< / maxoftgc> > RIC Parameter ID M 8.3.6 > RIC Parameter Test Condition O 8.3.7 > RIC Parameter Value O 8.3.8 E2-SM-IE

[0125] In the examples in [Table 13] below, the CommonRadioResourceUsage value is a value that is not currently compliant with 3GPP standards.

[0126] IE / Group Name Presence Range IE type and reference Semantics description Criticality Assigned Criticality Message Type M 　 　 　 YES reject DU ID M 　 　 DU ID to distinguish DU YES reject CellResourceReportList 　 1 　 　 YES reject >CellResourceReportItem 　 1 .. <maxCellingNBDU(=512)> 　 　 - 　 >>Cell Global ID M 　 Refer to Cell Global ID definition in NGAP / XnAP NR CGI YES reject >>>>CommonRadioResourceUsage O 　 0..100 Radio Usage for non-slice specific operation, (i.e., common control channel, paging, etc.) % -

[0128] An E2 node that has performed a non-standard operation desired by the operator can report the results of the non-standard function to the RIC using an RIC INDICATION message (e.g., [Table 4]) and a RIC INDICATION header (e.g., [Table 3]). In this case, the value of RIC INDICATION HEADER TYPE is set to the value assigned for operator-specific information (e.g., 129), and the updated value of [Table 13] is transmitted. The value of RIC INDICATION MESSAGE TYPE is set to the value assigned for operator-specific information (e.g., 129), and the E2 node transmits the non-standard message to the RIC using a RAN container.

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

[0131] When implemented in software, a computer-readable storage medium may be provided for storing one or more programs (software modules). One or more programs stored in the computer-readable storage medium are configured for execution by one or more processors within an electronic device. One or more programs include instructions that cause the electronic device to execute methods according to the embodiments described in the claims or specification of this disclosure.

[0132] Such programs (software modules, software) may be stored in random access memory, non-volatile memory including flash memory, read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic disc storage devices, compact disc-ROM (CD-ROM), digital versatile discs (DVDs), or other forms of optical storage devices, magnetic cassettes. Alternatively, they may be stored in memory composed of some or all of these. Additionally, each constituent memory may include multiple units.

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

[0134] In the specific embodiments of the present disclosure described above, the components included in the disclosure are expressed in a singular or plural form according to the specific embodiments presented. However, the singular or plural expression is selected to suit the situation presented for convenience of explanation, and the present disclosure is not limited to singular or plural components; even if a component is expressed in the plural form, it may be composed of a singular form, and even if a component is expressed in the singular form, it may be composed of a plural form.

[0135] Meanwhile, although specific embodiments have been described in the detailed description of the present disclosure, it is understood that various modifications are possible within the scope of the present disclosure. Therefore, the scope of the present disclosure should not be limited to the described embodiments, but should be defined by the claims set forth below as well as equivalents thereof.

Claims

Claim 1 A method of operation of a device using an interface between E2 nodes, including a radio access network intelligent controller (RIC) and a base station, in a wireless access network, comprising: a process of generating information related to a RIC service; a process of generating a value indicating a type of message to be used to transmit said information; and a process of transmitting an E2 message including said information and said value, wherein said value belongs to one of a first range or a second range, and when said value is included in said first range, said E2 message corresponds to a first type including predetermined information element fields included in a predefined message format, and when said value is included in said second range, said E2 message corresponds to a second type including at least some of the predetermined information element fields included in said predefined message format and at least one additional field included in a message format defined by an operator. Claim 2 A method according to claim 1, wherein the type of the message is determined according to the RIC service related to the information. Claim 3 In claim 1, the type of the message corresponds to the format of the information. Claim 4 A method according to claim 1, wherein the predefined message format is a format defined in a standard. Claim 5 A method according to claim 1, wherein the E2 node including the base station is one of a DU (digital unit), a CU (central unit)-CP (control plane), or a CU-UP (user plane). Claim 6 A method of operation of a device using an interface between E2 nodes, including a radio access network intelligent controller (RIC) and a base station, in a wireless access network, comprising: receiving an E2 message containing information related to a RIC service; identifying the type of message based on a value indicating the type of message included in the E2 message; and obtaining the information based on the value, wherein the value belongs to one of a first range or a second range, and when the value is included in the first range, the E2 message corresponds to a first type including predetermined information element fields included in a predefined message format, and when the value is included in the second range, the E2 message corresponds to a second type including at least some of the predetermined information element fields included in the predefined message format and at least one additional field included in a message format defined by an operator. Claim 7 In claim 6, the type of the message is determined according to the RIC service related to the information. Claim 8 In claim 6, the type of the message corresponds to the format of the information. Claim 9 In claim 6, the method wherein the predefined message format is a format defined in a standard. Claim 10 A method according to claim 6, wherein the E2 node including the base station is one of a DU (digital unit), a CU (central unit)-CP (control plane), or a CU-UP (user plane). Claim 11 A device using a node-to-node interface including a radio access network intelligent controller (RIC) and a base station in a wireless access network, comprising a transceiver and at least one processor including a processor circuit connected to the transceiver, wherein the at least one processor generates information related to a RIC service, generates a value indicating a type of message to be used to transmit the information, and controls the transmission of an E2 message including the information and the value, wherein the value falls within one of a first range or a second range, and when the value falls within the first range, the E2 message corresponds to a first type including predetermined information element fields included in a predefined message format, and when the value falls within the second range, the E2 message corresponds to a second type including at least some of the predetermined information element fields included in the predefined message format and at least one additional field included in a message format defined by an operator. Claim 12 A device according to claim 11, wherein the type of the message is determined according to the RIC service related to the information. Claim 13 In claim 11, the type of the message is a device corresponding to the format of the information. Claim 14 A device according to claim 11, wherein the predefined message format is a format defined in a standard. Claim 15 In claim 11, the node including the base station is a device that is one of a DU (digital unit), a CU (central unit)-CP (control plane), or a CU-UP (user plane). Claim 16 A device that uses an interface between a node constituting a radio access network intelligent controller (RIC) and a base station in a wireless access network, comprising a transceiver and at least one processor connected to the transceiver, wherein the at least one processor receives an E2 message containing information related to a RIC service, identifies the type of message based on a value indicating the type of message included in the E2 message, and controls the acquisition of the information based on the value, wherein the value belongs to one of a first range or a second range, and when the value is included in the first range, the E2 message corresponds to a first type including predetermined information element fields included in a predefined message format, and when the value is included in the second range, the E2 message corresponds to a second type including at least some of the predetermined information element fields included in the predefined message format and at least one additional field included in a message format defined by an operator. Claim 17 In claim 16, the type of the message is determined according to the RIC service related to the information. Claim 18 In claim 16, the type of the message is a device corresponding to the format of the information. Claim 19 In claim 16, the device wherein the predefined message format is a format defined in a standard. Claim 20 In claim 16, the E2 node including the base station is a device that is one of a DU (digital unit), a CU (central unit)-CP (control plane), or a CU-UP (user plane).

Images