Apparatus and method for controlling plurality of terminals in wireless communication system

Abstract

A method performed by a radio access network (RAN) intelligent controller (RIC), according to one embodiment of the present disclosure, may comprise the operations of: transmitting, to an E2 node, an RIC SUBSCRIPTION REQUEST message for subscribing to a service provided by the E2 node, so as to provide access to a related message or measurement value or control the E2 node; receiving, from the E2 node, an RIC SUBSCRIPTION RESPONSE message as a response to the RIC SUBSCRIPTION REQUEST message; and transmitting, to the E2 node, an RIC CONTROL REQUEST message including an RIC Control Header, which includes a terminal list, and an RIC Control Message, which includes control information for controlling a plurality of terminals included in the terminal list.

Description

Device and method for controlling multiple terminals in a wireless communication system

[0001] The present disclosure relates to a device and method for controlling a plurality of user equipment (UEs, or terminals) via a Near-RT (real-time) RIC (radio access network (RAN) intelligent controller) in a wireless communication system. More specifically, the present disclosure relates to a device and method for enabling a Near-RT RIC to perform control over a plurality of UEs via control messages.

[0002] According to the existing O-RAN specifications, in order to control multiple UEs, a Near-RT RIC (hereinafter referred to as "RIC") must transmit multiple RIC CONTROL REQUEST messages for each UE to an E2 node (e.g., O-DU, O-CU-CP, or O-CU-UP). For example, a RIC CONTROL REQUEST message for mobility management uses E2SM-RC Control Header Format 1 as specified in CONTROL Service Style Types 3 of E2SM-RC (E2 service model-RAN control). A RIC CONTROL REQUEST message using E2SM-RC Control Header Format 1 can specify one UE ID, and therefore, one RIC CONTROL REQUEST message can instruct a handover for only one UE. That is, in order to instruct a handover for multiple UEs, the RIC must transmit a corresponding number of RIC CONTROL REQUEST messages to the E2 node.

[0003] If the RIC determines that a specific cell has high physical resource block (PRB) usage based on a report received from the E2 node, the RIC can transmit a RIC CONTROL REQUEST message to the E2 node to handover some of the UEs being serviced in the cell. In this case, if multiple UEs are to be handed over to a common target cell, the RAN parameters included in each RIC CONTROL REQUEST message are the same, but multiple RIC CONTROL REQUEST messages are transmitted according to the provisions of CONTROL Service Style Types 3. Simultaneously transmitting multiple RIC CONTROL REQUEST messages to multiple UEs in this way increases overhead.

[0004] Based on the discussion as described above, the present disclosure provides a device and method for a RIC to control an E2 node in a wireless communication system.

[0005] Additionally, the present disclosure provides a device and method for reducing overhead by performing control requests for multiple UEs through one RIC CONTROL REQUEST message.

[0006] A method performed by a RIC (radio access network (RAN) intelligent controller) according to one embodiment of the present disclosure may include: transmitting, to an E2 node, a RIC SUBSCRIPTION REQUEST message for subscribing to a service provided by an E2 node to provide access to related messages or measurements or to control the E2 node; receiving, from the E2 node, a RIC SUBSCRIPTION RESPONSE message in response to the RIC SUBSCRIPTION REQUEST message; and transmitting, to the E2 node, a RIC CONTROL REQUEST message including an RIC Control Header including a terminal list and an RIC Control Message including control information for controlling a plurality of terminals included in the terminal list.

[0007] A method performed by an E2 node of the present disclosure may include: receiving, from a radio access network (RAN) intelligent controller (RIC), an RIC SUBSCRIPTION REQUEST message for subscribing to a service provided by an E2 node to provide access to messages or measurements related to the E2 node or to control the E2 node; transmitting, to the RIC, an RIC SUBSCRIPTION RESPONSE message in response to the RIC SUBSCRIPTION REQUEST message; and receiving, from the RIC, an RIC CONTROL REQUEST message including an RIC Control Header including a terminal list and an RIC Control Message including control information for controlling a plurality of terminals included in the terminal list.

[0008] According to one embodiment of the present disclosure, a RIC (radio access network (RAN) intelligent controller) includes a transceiver; a controller; and a storage unit for storing commands, wherein when the commands are executed by the controller: a RIC SUBSCRIPTION REQUEST message is transmitted to an E2 node for subscribing to a service provided by an E2 node to provide access to related messages or measurements or to control the E2 node; a RIC SUBSCRIPTION RESPONSE message is received from the E2 node in response to the RIC SUBSCRIPTION REQUEST message; and a RIC CONTROL REQUEST message including a RIC Control Header including a terminal list and a RIC Control Message including control information for controlling a plurality of terminals included in the terminal list may be transmitted to the E2 node.

[0009] According to one embodiment of the present disclosure, an E2 node includes a transceiver; a controller; and a storage unit for storing commands, and when the commands are executed by the controller: an RIC (radio access network (RAN) intelligent controller) may receive a RIC SUBSCRIPTION REQUEST message for subscribing to a service provided by the E2 node to provide access to messages or measurements related to the E2 node or to control the E2 node, and an RIC SUBSCRIPTION RESPONSE message may be transmitted to the RIC in response to the RIC SUBSCRIPTION REQUEST message, and an RIC CONTROL REQUEST message may be received from the RIC, including an RIC Control Header including a terminal list and an RIC Control Message including control information for controlling a plurality of terminals included in the terminal list.

[0010] The RIC according to the present disclosure can enable multiple UEs to perform the same terminal operation through a single control message to the E2 node.

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

[0012] FIG. 1 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.

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

[0014] Figure 3 illustrates an example of an architecture for O-RAN.

[0015] FIG. 4 illustrates a protocol stack of an E2 application protocol message in a wireless access network according to various embodiments of the present disclosure.

[0016] FIG. 5 illustrates a configuration of a device according to various embodiments of the present disclosure.

[0017] FIG. 6 is a diagram for explaining a method for an RIC to control multiple UEs within a cell according to one embodiment of the present disclosure.

[0018] FIG. 7 is a flowchart of a procedure for transmitting and receiving messages between an RIC and an E2 node according to one embodiment of the present disclosure.

[0019] FIG. 8 is a flowchart of a RIC Control procedure according to one embodiment of the present disclosure.

[0020] FIG. 9 is a flowchart of a procedure for transmitting and receiving messages between an RIC and an E2 node according to one embodiment of the present disclosure.

[0021] FIG. 10 is a diagram for explaining a RIC Event Trigger Definition IE style list included in a RIC SUBSCRIPTION REQUEST message according to one embodiment of the present disclosure.

[0022] FIG. 11 is a diagram for explaining E2SM-RC Event Trigger Definition Format 2 according to one embodiment of the present disclosure.

[0023] FIG. 12 is a diagram for explaining information elements included in a RIC CONTROL REQUEST message according to one embodiment of the present disclosure.

[0024] FIG. 13 is a drawing for explaining a RIC Control Header according to one embodiment of the present disclosure.

[0025] Figure 14 is a drawing for explaining the information included in the Control Header in the case of Control Header Format 1.

[0026] Figure 15 is a drawing for explaining the information included in the Control Header in the case of Control Header Format 3.

[0027] FIG. 16 is a drawing for explaining a new format Control Header according to one embodiment of the present disclosure.

[0028] FIG. 17 is a drawing for explaining information included in a Control Message in the case of Control Message Format 1 according to one embodiment of the present disclosure.

[0029] FIG. 18 is a diagram for explaining information included in a RIC Control Request message in the case of CONTROL Service Style 3 for Connected Mode Mobility Control according to one embodiment of the present disclosure.

[0030] FIG. 19 is a diagram for explaining information included in a RIC Control Request message in the case of CONTROL Service Style 6 for Carrier Aggregation Control according to one embodiment of the present disclosure.

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

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

[0033] The present disclosure relates to a device and method for performing a control procedure between a device within a radio access network (RAN) and a device controlling the RAN in a wireless communication system. Specifically, the present disclosure relates to a device and method for performing control for multiple UEs simultaneously over an E2 interface in a radio access network.

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

[0035] Additionally, in the present disclosure, expressions such as "more than" or "less than" may be used to determine whether a specific condition is satisfied or fulfilled. However, this is merely a description for expressing an example and does not exclude descriptions of "more than" or "less than." Conditions described as "more than" may be replaced with "more than," conditions described as "less than" may be replaced with "less than," and conditions described as "more than and less than" may be replaced with "more than and less than."

[0036] Additionally, although the present disclosure describes various embodiments using terms used in some communication standards (e.g., 3rd Generation Partnership Project (3GPP), O-RAN (open radio access network)), these are merely examples for illustrative purposes. The various embodiments of the present disclosure can be easily modified and applied to other communication systems.

[0037] In the present disclosure, a base station is a network infrastructure that provides wireless access to a terminal. For example, a base station is a device that performs scheduling by collecting status information such as the terminal's buffer status, available transmission power, and channel status. A base station has coverage defined as a certain geographical area based on the distance at which a signal can be transmitted. In addition to a base station, a base station may be referred to as an "access point (AP)", an "eNodeB (eNB)", a "wireless point", a "transmission / reception point (TRP)", or other terms having equivalent technical meanings.

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

[0039] In the present disclosure, a 5G NSA system may include an NR RAN, an LTE RAN, a terminal, and an EPC, and the NR RAN and the LTE RAN are connected to the EPC, and the terminal may receive services from either or both of the NR RAN and the LTE RAN simultaneously. The NR RAN includes at least one NR base station, and the LTE RAN includes at least one LTE base station. Here, the NR base station is referred to as a '5G node (5 th It may be referred to as 'generation node', 'next generation nodeB (gNB)' or other terms having 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 further, the CU may have a structure separated into a CU-CP (control plane) unit and a CU-UP (user plane) unit.

[0040] The terminal can perform RRC (radio resource control) connection through a first base station (e.g., a base station belonging to an LTE RAN) and can receive services such as functions provided in the control plane (e.g., connection management, mobility management, etc.). In addition, the terminal can be provided with additional radio resources for transmitting and receiving data through a second base station (e.g., a base station belonging to an NR RAN). This dual connectivity technology using LTE and NR can 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). In addition, various embodiments can be applied to various other forms of multiple connectivity and carrier aggregation technologies. In addition, various embodiments can be applied when a first system using a first communication technology and a second system using a second communication technology are implemented in one device, or when the first base station and the second base station are located in the same geographical location.

[0041] 4th generation (4 th generation, 4G) / 5th generation (5 thAs 5G (5th generation) communication systems (e.g., NR (new radio)) are commercialized, differentiated service support for users in virtualized networks is required. 3GPP was established in December 1998, and the 3GPP standards are based on the advanced GSM standards, and include radio, core network, and service architecture in the scope of standardization. Accordingly, O-RAN (open radio access network) newly defines the nodes that make up the 3GPP NE (network entity) and base station, namely 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 Near-RT (near-real-time) RIC (radio access network intelligent controller). The present disclosure is to support an operator-specific service model in an E2 interface where a RIC requests a service from an 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 that can operate according to the O-RAN standard, and can be referred to as E2 nodes. The interface between the RIC and the E2 nodes and the objects constituting the RAN that can operate according to the O-RAN standard uses the E2AP (application protocol).

[0042] The RIC is a logical node that can collect information at a cell site where a terminal and an O-DU, O-CU-CP, or O-CU-UP transmit and receive information. The RIC can be implemented as a server centrally located in one physical location. Connections can be made 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 specifications for communication between the O-DU and the RIC, between the O-CU-CP and the RIC, and between the O-CU-UP and the RIC are required, and message specifications such as E2-DU, E2-CU-CP, and E2-CU-UP and definition of procedures between the O-DU, O-CU-CP, O-CU-UP, and the RIC are required. In particular, differentiated service support is required for users in virtualized networks, and by concentrating call processing messages / functions generated in O-RAN in RIC, it is necessary to define the functions of E2-DU, E2-CU-CP, and E2-CU-UP messages to support services for wide cell coverage.

[0043] 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 sending subscription messages. Specifically, the RIC can set a call processing EVENT by generating an E2 Subscription Request message and sending it to an E2 node (e.g., O-CU-CP, O-CU-UP, O-DU). In addition, after setting the EVENT, the E2 node sends the Subscription Request Response message sent to the RIC.

[0044] An E2 node can transmit its current status to the RIC via an E2 indication / report. The RIC can provide control over the O-DU, O-CU-CP, and O-CU-UP using E2 control messages. Various embodiments of the present disclosure propose an E2 indication message that transmits UE-level measurement information at a periodic rate set by a subscription event condition in the O-DU. In addition, various embodiments of the present disclosure propose a message for controlling resources transmitted from the RIC to the O-DU.

[0045] FIG. 1 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.

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

[0047] Although FIG. 1 illustrates a single RIC (140), multiple RICs may exist according to various embodiments. The multiple RICs may be implemented with multiple hardware located at the same physical location or through virtualization using a single piece of hardware.

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

[0049] Referring to FIG. 2, the RIC (240) and the E2 node (210) can transmit or receive E2 messages to each other. For example, the E2 node (210) can be an O-CU-CP, an O-CU-UP, an O-DU, or a base station. The communication interface of the E2 node can be determined according to the type of the E2 node (210). For example, the E2 node (210) can communicate with another E2 node (216) through an E1 interface or an F1 interface. Or, for example, the E2 node (210) can communicate with the E2 node (216) through an X2 interface or an Xn interface. Or, for example, the E2 node (210) can communicate through an S1 interface or an NGAP (next generation application protocol) interface (i.e., an interface between a NG (next generation) RAN node and an AMF).

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

[0051] The E2 terminal (242) located in the RIC (240) is the terminal of the RIC (240) for the E2 message, and performs the function of interpreting the E2 message transmitted by the E2 node (210) and then transmitting it to the xApp (246). The DB (database) (244) located in the RIC (240) can be used for the E2 terminal (224) or the xApp (246). The E2 node (210) illustrated in FIG. 2 can be understood as the terminal of at least one interface, and as the terminal of messages transmitted to a terminal, a surrounding base station, and a core network.

[0052] Figure 3 illustrates an example architecture for O-RAN. For the purpose of E2-SM-KPIMON (key performance indicator monitoring) of the E2 service model, O-RAN non-standalone mode within multi-connectivity operation using E-UTRA and NR radio access technology is considered, while the E2 node can be assumed to be in O-RAN standalone mode.

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

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

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

[0056] FIG. 4 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 (410), a data link layer (420), an Internet Protocol (IP) (330), and a stream control transmission protocol (SCTP) (440).

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

[0058] FIG. 5 illustrates a configuration of a device according to various embodiments of the present disclosure. The structure illustrated in FIG. 5 can be understood as a configuration of a device having at least one function among the RIC, O-CU-CP, O-CU-UP, and O-DU of FIG. 4. Terms such as “… unit”, “… unit”, etc. used hereinafter mean a unit that processes at least one function or operation, and this can be implemented by hardware, software, or a combination of hardware and software.

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

[0060] The communication unit (510) provides an interface for communicating with other devices within the network. That is, the communication unit (510) converts a bit string transmitted from a 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 transmit and receive signals. Accordingly, the communication unit (510) may be referred to as a modem, a transmitter, a receiver, or a transceiver. In this case, the communication unit (510) enables the core network device to communicate with other devices or systems via a backhaul connection (e.g., wired backhaul or wireless backhaul) or via a network.

[0061] The storage unit (520) stores data such as basic programs, application programs, and setting 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 and non-volatile memory. In addition, the storage unit (520) provides the stored data upon request from the control unit (530).

[0062] 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) records and reads data from the storage unit (520). For this purpose, 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 various embodiments described in the present disclosure.

[0063] FIG. 6 is a diagram for explaining a method for an RIC to control multiple UEs within a cell according to one embodiment of the present disclosure.

[0064] The E2 node (610) of FIG. 6 is a base station of the O-CU-CP, O-CU, or gNB type, and has an E2 interface for RIC, and can support one or more RIC services. The UEs of FIG. 6 are in an RRC connected state and are configured to transmit RRC Measurement Reports, and the RRC Measurement Reports can include one or more neighboring cell Measurements applicable to an inter-cell connected mode mobility event. The E2 node can complete a handover decision and perform a handover using one or more RIC Services, or it can receive a measurement report and not perform a specific action. For example, if the handover conditions are not met, the E2 node can continue to provide services to the UE in the current cell.

[0065] Referring to FIG. 6, when the PRB usage of the cell site of the source base station (630) exceeds a threshold or when it is determined to be necessary based on a measurement report received from a terminal, the E2 node (610) may make a handover decision. According to the handover decision of the E2 node (610), the RIC (640) may transmit a RIC CONTROL REQUEST message including handover information to the E2 node (610). The handover information included in the RIC CONTROL REQUEST message may include information indicating handover to a target base station for specific terminals among the terminals (UE1 to UE12) within the cell of the source base station (630). At this time, the terminals to be handed over to the target base station may include, for example, terminals located at the cell edge (UE1 to UE3, UE6 to UE7, UE10 to UE12).

[0066] Specifically, the handover information included in the RIC CONTROL REQUEST message may include information on a terminal subject to handover control through the RIC CONTROL service and information on a target base station.

[0067] Referring to FIG. 6, the RIC CONTROL REQUEST message may include handover information instructing terminals UE1 to UE3 to handover to a target cell (631), terminals UE6 to UE7 to handover to a target cell (632), and terminals UE10 to UE12 to handover to a target cell (633).

[0068] In connected mode mobility control, the RIC CONTROL REQUEST message can include the UE ID of one terminal to be controlled in the header, and the RIC can perform connected mode mobility control for one terminal by transmitting the RIC CONTROL REQUEST message once to the E2 node.

[0069] When RIC decides to perform a handover for multiple terminals, for example, when RIC decides to perform a handover for all terminals (UE1 to UE3, UE6 to UE7, UE10 to UE12) located at the cell boundary in FIG. 6, three RIC CONTROL REQUEST messages to be transmitted to the E2 node for handover of UE1 to UE3 may include UE IDs of different terminals in their respective headers and may include information on the same target base station.

[0070] For example, the RIC CONTROL REQUEST message sent by the RIC (640) for handover control of terminal UE1 may include ID information of UE1, the RIC CONTROL REQUEST message sent for handover control of terminal UE2 may include ID information of UE2, and the RIC CONTROL REQUEST message sent for handover control of terminal UE3 may include ID information of UE3. In addition, the three RIC CONTROL REQUEST messages for UE1 to UE3 may commonly include identification information of the target cell (631). In this way, when the RIC performs handover control of multiple terminals, the overhead may increase because the RIC transmits several RIC CONTROL REQUEST messages that have common information for identifying target base stations.

[0071] Likewise, the RIC CONTROL REQUEST messages sent to handover each of terminals UE6 to UE7 may commonly include information about the target cell (632), and the RIC CONTROL REQUEST messages sent to handover UE10 to UE12 may commonly include information about the target cell (633). As the number of terminals managed by the RIC increases, the problem of increased overhead mentioned above may become more severe.

[0072] The present disclosure provides a method and apparatus for supporting RIC control services for multiple terminals through a single RIC CONTROL REQUEST message without redundantly transmitting RIC CONTROL REQUEST messages containing common control information. Although FIG. 6 is about connected mode mobility control, FIG. 6 is merely an example for explaining the method and apparatus for supporting RIC control services for multiple terminals of the present disclosure, and does not limit the present disclosure to an embodiment of connected mode mobility control.

[0073] To this end, the header of the RIC CONTROL REQUEST message transmitted by the RIC to the E2 node according to one embodiment may include the UE IDs of target terminals that will implement the RIC control service, configured as a List of UE IDs. In an embodiment of connected mode mobility control, the header of one RIC CONTROL REQUEST message transmitted by the RIC (640) to the E2 node (610) may include a List of UE IDs configured with the UE IDs of terminals of the same target base station. Referring to FIG. 6, instead of transmitting a RIC CONTROL REQUEST message including a UE1 ID, a RIC CONTROL REQUEST message including a UE2 ID, and a RIC CONTROL REQUEST message including a UE3 ID, the RIC (640) may transmit one RIC CONTROL REQUEST message including a List of UE IDs configured with a UE1 ID, a UE2 ID, and a UE3 ID.

[0074] In this way, when the header of the control request message includes a List of UE IDs composed of UE IDs of terminals to be controlled, there is no need for the RIC to transmit multiple RIC CONTROL REQUEST messages to the E2 node to control each terminal, and the RIC can provide RIC control service for multiple terminals included in the List of UE IDs by transmitting one RIC CONTROL REQUEST message, thereby reducing overhead due to transmission of the RIC CONTROL REQUEST message and increasing network efficiency.

[0075] FIG. 7 is a flowchart of a procedure for transmitting and receiving messages between an RIC and an E2 node according to one embodiment of the present disclosure.

[0076] Referring to FIG. 7, in operation 703, the RIC (740) may transmit a RIC SUBSCRIPTION REQUEST message to the E2 node (710), and in operation 706, the E2 node (710) may transmit a RIC SUBSCRIPTION RESPONSE message to the RIC (740). Operations 703 and 706 may be included in the RIC Subscription procedure defined in the O-RAN standard.

[0077] The RIC subscription procedure is used to establish a RIC subscription for an E2 node, which includes an event trigger and a series of RIC Service Actions. A Near-RT RIC (hereinafter referred to as "RIC") can report information about a specific UE or a specific cell by performing the RIC subscription procedure with an E2 node (e.g., O-DU, O-CU-CP, or O-CU-UP). The RIC subscription procedure is initiated by the RIC sending a RIC SUBSCRIPTION REQUEST message, as in operation 703, which may include a unique RIC Request ID IE assigned by the RIC.

[0078] The RIC SUBSCRIPTION REQUEST message includes a RIC Subscription Details IE, and the RIC Subscription Details IE includes a sequence of RIC Service Actions. The sequence of RIC Service Actions included in the RIC SUBSCRIPTION REQUEST message includes the RIC Service Actions that the RIC requests from the E2 node. The RIC Service Actions may include at least one of the following RIC Service Actions: Insert, Report, Policy, or Control.

[0079] The E2 node can accept specific RIC Service Actions among the requested RIC Service Actions and reserve the necessary resources for the approved RIC Service Action. The E2 node distinguishes between RIC Service Actions for which resources are prepared and those for which resources are not prepared, and includes them in the RIC SUBSCRIPTION RESPONSE message and transmits them to the RIC.

[0080] The RIC SUBSCRIPTION REQUEST message also includes an event trigger, and the E2 node that receives the RIC SUBSCRIPTION REQUEST message can configure the requested event trigger. Specifically, the E2 node validates the requested event trigger, and if it accepts it, it stores the RIC Event Trigger Definition IE.

[0081] Specifically, in operation 703, the E2 node (710) may receive a RIC SUBSCRIPTION REQUEST message and operate as follows. The E2 node (710) may determine which RAN Function the subscription procedure targets based on information in the RAN Function ID IE included in the RIC SUBSCRIPTION REQUEST message, and may set the requested event trigger based on information in the RIC Subscription Details IE included in the RIC SUBSCRIPTION REQUEST message. Alternatively, if the RIC Subscription Details IE includes one or more Report, Insert, and / or Policy RIC Service Actions, the target RAN Function may validate the event trigger and the action sequence, and if one or more RIC Service Actions are accepted by the E2 node (710), may store the requested RIC Request ID, the RIC Event Trigger Definition IE, and the sequence of RIC Service Actions.

[0082] If the E2 node (710) accepts the requested trigger and at least one requested RIC Service Action in operation 703, the E2 node (710) may reserve necessary resources for each approved RIC Service Action and transmit a RIC SUBSCRIPTION RESPONSE message in operation 706. The RIC SUBSCRIPTION RESPONSE message may include a RIC Actions Admitted List IE and a RIC Actions Not Admitted List IE, and the E2 node (710) may include information about RIC Service Actions for which resources are prepared in the E2 node in the RIC Actions Admitted List IE in the RIC SUBSCRIPTION RESPONSE message. The E2 node (710) may include unapproved RIC Service Actions in the RIC Actions Not Admitted List IE.

[0083] When RIC receives a RIC SUBSCRIPTION RESPONSE message from E2 node (710) at operation 706, the RIC Subscription procedure may be terminated.

[0084] An E2 node can execute a RIC Service Action whenever an event trigger occurs. Here, the event trigger refers to an accepted event trigger, and the RIC Service Action refers to an accepted RIC Service Action among a sequence of RIC Service Actions.

[0085] If at least one of the Report RIC Service Action or Insert RIC Service Action is accepted and an event trigger occurs, the E2 node can initiate the RIC Indication procedure by sending a RIC INDICATION message to the RIC. The RIC Indication procedure is a procedure that aims to convey the Report and / or Insert RIC Service Action accepted in the RIC Subscription procedure. The RIC INDICATION message can include a unique RIC Request ID IE assigned in the RIC Subscription procedure, and the RIC Request ID is an identifier used to identify a specific procedure among procedures that are running in parallel. Messages belonging to the same procedure use the same RIC Request ID.

[0086] In particular, when the Insert RIC Service Action is accepted and an event trigger occurs, the E2 node may include a RIC Call Process ID IE in the RIC Indication message, save the current call state, start a timer, and suspend further processing of the RAN function. The RIC Call Process ID IE is an identifier used to identify the call process that the E2 node suspended while performing the Insert RIC Service Action, and can be used by the RIC in subsequent RIC Control procedures.

[0087] In some cases, the RIC SUBSCRIPTION REQUEST message may further include a RIC Subsequent Action IE, which may define a subsequent RIC Service Action to be performed after the Insert RIC Service Action is completed. For example, if the RIC SUBSCRIPTION REQUEST message includes Insert and Control RIC Service Actions and further includes a RIC Subsequent Action IE, the RIC Subsequent Action IE may indicate that the Control RIC Service Action should be performed after the Insert RIC Service Action is completed.

[0088] If the RIC SUBSCRIPTION REQUEST message further includes a RIC Subsequent Action IE, the E2 node can act as follows after successfully transmitting the RIC INDICATION message.

[0089] If the RIC Subsequent Action Type is set to Continue or Halt, the timer has not expired, and a RIC CONTROL REQUEST message is received with the same RIC Call Process ID IE, the E2 node can use the RIC CONTROL REQUEST information according to the stored call status and continue executing the remaining actions in the sequence of RIC Actions defined in the RIC Subscription procedure before resuming the normal functionality of the RAN function.

[0090] If the RIC Subsequent Action Type is set to Continue and the timer expires, the E2 node can use the saved call state and continue executing the remaining RIC Service Actions among the sequence of RIC Actions defined in the RIC Subscription procedure.

[0091] If the RIC Subsequent Action Type is set to Halt and the timer expires, the E2 node may abort further processing of the RAN function. In this case, the remaining RIC Service Actions in the sequence of RIC Actions defined in the RIC Subscription procedure may also be aborted.

[0092] Based on the RIC INDICATION message received from the E2 node, the RIC can generate a control request message (RIC Control Request message) and transmit it to the E2 node.

[0093] Specifically, in operation 721, the RIC may transmit a RIC CONTROL REQUEST message to the E2 node (710). The RIC may initiate a RIC Control procedure by transmitting the RIC CONTROL REQUEST message. The RIC Control procedure is a procedure aimed at initiating or resuming a specific functionality in the E2 node. When the RIC transmits the RIC CONTROL REQUEST message and the optional RIC Control Ack Request IE is set to "Ack" or does not exist, the RIC may start a control timer.

[0094] Upon receiving a RIC CONTROL REQUEST message, the E2 node can: Use the information in the RAN Function ID IE to determine the target RAN Function, and use the information in the RIC Control Message IE to initiate the requested RIC Control procedure action. If the RIC Call Process ID IE is included in the RIC CONTROL REQUEST message, the E2 node can use the RIC Call Process ID IE to identify the specific call process indicated in the RIC INDICATION message.

[0095] At this time, the RIC Control Request message may include a RIC Control Header IE and a RIC Control Message IE. The RIC Control Header IE and the RIC Control Message IE may include information for identifying the UE to be controlled and control information to be applied to the identified UE. One RIC Control Request message may be used to control one UE or multiple UEs that satisfy specific conditions.

[0096] According to one embodiment, the RIC Control Header IE of the RIC CONTROL REQUEST message may include a list of UE IDs. Accordingly, the RIC can perform RIC Control service for multiple UEs by transmitting only one RIC CONTROL REQUEST message to the E2 node (710). Specifically, when the instructions to be given to multiple terminals for performing the RIC Control procedure are the same, the RIC CONTROL REQUEST message may include a list of UE IDs in the RIC Control Header IE, which is a list of UE IDs of multiple UEs.

[0097] In operation 721, the E2 node (710) may receive a RIC CONTROL REQUEST message from the RIC and may operate as follows. The E2 node (710) may determine a target RAN Function based on information in the RAN Function ID IE and initiate a requested RIC Control procedure action based on information in the RIC Control Message IE. Alternatively, the E2 node (710) may use the RIC Call Process ID IE, if included in the RIC CONTROL REQUEST message, to identify a specific call process indicated in the RIC INDICATION message. Alternatively, if the optional RIC Control Ack Request IE included in the RIC CONTROL REQUEST message is set to "Ack" or the optional RIC Control Ack Request IE does not exist in the RIC CONTROL REQUEST message and the E2 node (710) successfully performs the requested RIC Control procedure action, the E2 node (710) may respond with a RIC CONTROL ACKNOWLEDGE message. Alternatively, if the optional RIC Control Ack Request IE included in the RIC CONTROL REQUEST message is set to "NoAck" and the E2 node (710) successfully performs the requested RIC Control procedure action, the E2 node (710) may not transmit the RIC CONTROL ACKNOWLEDGE message. When the RIC receives the RIC CONTROL ACKNOWLEDGE message from the E2 node (710), the RIC may terminate the RIC Control procedure.

[0098] In operation 721, when the E2 node (710) receives a RIC CONTROL REQUEST message from the RIC, the E2 node (710) may invoke a procedure related to the requested RIC Control procedure action. According to one embodiment, when the E2 node (710) receives the RIC CONTROL REQUEST message, it may invoke a procedure related to the RIC Control procedure action for UEs that constitute the list of UE IDs included in the header.

[0099] Taking Handover Control as an example among Connected Mode Mobility Control, in operation 721, when the E2 node (710) receives a RIC CONTROL REQUEST message from the RIC, in case of Xn / X2, NG, or inter-RAT handover, the E2 node (710) may invoke procedures related to UE Mobility Management, such as Handover Preparation, Bearer Context Modification, UE Context Modification, and RRC Message Transfer. Or, in case of intra-gNB or F1 handover, the E2 node (710) may invoke procedures, such as UE Context Modification and RRC Message Transfer.

[0100] The E2 node may include information contained in the RIC CONTROL REQUEST message received from the RIC in the relevant interface message. In the case of Handover Control, IEs corresponding to one or more of the RAN parameters (i.e., the RAN parameters of FIG. 18) contained in the RIC Control Message IE of the RIC CONTROL REQUEST message may be included in the interface message used when invoking the handover-related procedures mentioned above. For example, the RIC Control Request message for Handover Control may include information on a target cell to which the controlled UE will be handed over. The E2 node may modify a handover decision for the controlled UEs based on the information on the target cell contained in the RIC Control Request message. The information on the target cell may include a Target Primary Cell ID IE, as described in FIG. 18. Note that if the Target Primary Cell ID IE is missing in the RIC Control Request message for Handover Control, the E2 node may transmit a RIC Control Failure message to the RIC.

[0101] Taking Carrier Aggregation Control as an example, in operation 721, when the E2 node (710) receives a RIC CONTROL REQUEST message from the RIC, the E2 node (710) may invoke a procedure associated with Secondary cell Addition Control (e.g., UE Context Management, RRC Message Transfer, etc.). In addition, the E2 node (710) may include IEs corresponding to one or more of the parameters described in FIG. 19 in the related interface message.

[0102] FIG. 8 is a flowchart of a RIC Control procedure according to one embodiment of the present disclosure.

[0103] In operation 803, the RIC (840) may receive a RIC CONTROL REQUEST message from the E2 node, and in operation 806, may transmit a RIC SUBSCRIPTION RESPONSE message to the E2 node. Some descriptions of operations 803 and 806 will be briefly described to avoid duplication with the descriptions of operations 703 and 706.

[0104] At operation 803, the RIC (840) may transmit a RIC SUBSCRIPTION REQUEST message to the E2 node (810), and at operation 806, the E2 node (810) may transmit a RIC SUBSCRIPTION RESPONSE message to the RIC (840).

[0105] If the E2 node sends a RIC SUBSCRIPTION RESPONSE message to the RIC, as in operation 806, the RIC Subscription procedure is considered successful. If the RIC Subscription procedure is successful, the RIC can assign a RIC Request ID IE. In the RIC Subscription procedure of operations 803 to 806, the RIC can assign a RIC Request ID IE.

[0106] At step 815, the RIC (840) may receive a RIC INDICATION message from the E2 node. The RIC INDICATION message is a message including the RIC Request ID IE assigned by the RIC during a successful RIC Subscription procedure. The E2 node may initiate the RIC Indication procedure by sending the RIC INDICATION message to the RIC.

[0107] The RIC Indication procedure is performed to convey a Report and / or Insert RIC Service Action related to the RIC Subscription procedure. If the RIC Indication message is a response to an Insert RIC Service Action, the E2 Node provides a RIC Call Process ID IE in the RIC INDICATION message, stores the current call state, and may suspend further processing by the associated RAN function (e.g., ongoing call processing for the UE).

[0108] The RIC (840) that received the RIC INDICATION message from the E2 node in operation 815 can use the RIC Call Process ID IE included in the RIC INDICATION message in the subsequent RIC Control procedure.

[0109] In operation 819, the RIC (840) can determine the list of UE IDs to be included in the RIC CONTROL REQUEST message. Based on the report received through the RIC Indication procedure, the RIC (840) can generate the RIC CONTROL REQUEST message. Since the RIC CONTROL REQUEST message of the present disclosure includes the list of UE IDs in the header, the RIC (840) can determine the information included in the RIC Control Header IE in operation 819.

[0110] In operation 821, the RIC (840) may transmit an RIC Control Request message including a list of UE IDs to the E2 node. The RIC (840) may transmit a single RIC Control Request message to the E2 node to convey control information for multiple terminals constituting the list of UE IDs.

[0111] FIG. 9 is a flowchart of a procedure for transmitting and receiving messages between an RIC and an E2 node according to one embodiment of the present disclosure.

[0112] According to one embodiment, the RIC (940) can control at least one of connected mode mobility, dual connectivity (DC), CA, radio bearer, radio resource allocation, radio access, idle mode mobility, and measurement report (MR) configuration. For example, in the case of connected mode mobility, the RIC can generate and transmit an RIC join request message and a control request message to the E2 node to modify the operation of a call process related to handover, conditional handover, dual active protocol stack (DAPS) handover, etc. for both the serving RAN node and the target RAN node.

[0113] Referring to FIG. 9, the RIC (940) and the E2 node (910) can perform a RIC Subscription procedure. In operation 903, the RIC (940) can transmit a RIC SUBSCRIPTION REQUEST message to the E2 node (910), and in operation 906, the RIC (940) can receive a RIC SUBSCRIPTION RESPONSE message from the E2 node (910). In order for the RIC (940) to obtain information about a specific UE or a specific cell from the E2 node (910), a procedure for subscribing to a service for reporting such information is required.

[0114] The RIC SUBSCRIPTION REQUEST message of Action 903 may include a RIC Event Trigger Definition IE and a RIC ACTION DEFINITION IE.

[0115] The RIC Event Trigger Definition IE is information required for an event trigger used to initiate REPORT, INSERT, and POLICY actions. As shown in the RIC Event Trigger Definition IE style list of FIG. 10, the RIC Event Trigger Definition IE can be used for at least one event trigger among Message Event, Call Process Breakpoint, E2 Node Information Change, and UE Information Change. FIG. 10 is a diagram illustrating a RIC Event Trigger Definition IE style list included in a RIC SUBSCRIPTION REQUEST message according to an embodiment of the present disclosure.

[0116] For example, the “Message Event” Event Trigger can initiate the “Message copy” REPORT Styles, and when the Event Trigger condition is met, the “Message copy” REPORT Styles can be used to report an RRC message along with UE-related information. The Event Trigger condition can include receiving or sending a Message.

[0117] As another example, E2SM-RC Event Trigger Definition Format 2 can be used for Event Trigger Style 2 related to Call Process Breakpoint. As shown in FIG. 11, E2SM-RC Event Trigger Definition Format 2 can include Call Process Type ID, Call Breakpoint ID, related E2 node information, and related UE information. FIG. 11 is a diagram illustrating E2SM-RC Event Trigger Definition Format 2 according to an embodiment of the present disclosure.

[0118] The RIC ACTION DEFINITION IE can provide additional information about a specified RIC action. The specified RIC action can include, for example, a REPORT, INSERT, or POLICY action related to a RIC Event Trigger Definition IE.

[0119] For example, if the specified RIC action is a REPORT action, the RIC ACTION DEFINITION IE can be used to request the E2 node to report a copy of the RRC message, call process outcome information, RAN control related E2 node configuration information, E2 Node related information, terminal related information, or a set of parameters to be reported when an event trigger is met, depending on the REPORT Service Style.

[0120] As another example, if the specified RIC action is an INSERT action, the RIC ACTION DEFINITION IE may include information about the RIC Indication message that the E2 node transmits to the RIC. At this time, the RIC Indication message may initiate a request to control the function of the radio bearer, allocation of radio resources, handover and mobility management, wireless connection of the terminal, dual connectivity (DC) or CA, etc., depending on the INSERT Service Style. The E2 node may transmit the RIC Indication message to the RIC and suspend the ongoing call processing for the terminal until it hears a response from the RIC.

[0121] In operation 909, the E2 node (910) may perform a call processing decision. The E2 node (910) may perform a call processing decision for at least one of the REPORT service, the INSERT service, or the POLICY service.

[0122] According to one embodiment, in operation 903, the RIC (940) can transmit the RIC Event Trigger Definition IE style 2 to the E2 node (910) through a Subscription Request message, and this RIC Event Trigger Definition IE style 2 can be used to detect call processing in the E2 node. If the RIC (940) transmits the RIC Event Trigger Definition IE style 2 to the E2 node (910) through the Subscription Request message in operation 903, the E2 node (910) can detect the call process based on the call process ID (identifier) ​​and the breakpoint ID in operation 909. For example, in case of Call Process Type ID 3 (Mobility Management) and Call Breakpoint ID 1 (Handover Preparation), INSERT Service, POLICY Service, and REPORT Service can be supported. That is, the E2 node (910) can perform INSERT Service, POLICY Service, and REPORT Service. Additionally, the E2 node (910) can perform at least one of the INSERT Service, POLICY Service, or REPORT Service based on a RAN parameter for an E2 node-related condition for event triggering.

[0123] In operation 912, the terminal (920) may transmit a UE KPI Report to the E2 node (910). For example, the terminal (920) may transmit KPIs required for handover and mobility management control to the E2 node (910). For example, the KPIs may include a throughput value of the terminal within the source base station.

[0124] In another example, at operation 912, the terminal (920) may transmit a UE Measurement Report to the E2 node (910). For example, the terminal (920) may transmit an RRC Measurement Report to the E2 node (910).

[0125] At operation 915, the E2 node (910) can transmit an Indication message to the RIC (940) including terminal-related information that the E2 node (910) received from the terminal at operation 912.

[0126] In operation 918, the E2 node (910) may suspend ongoing call processing for the terminal. If the E2 node determines the INSERT service or POLICY service in operation 909, the E2 node may suspend call processing for the terminal as in operation 918 after transmitting an Indication message in operation 915 and wait for a response from the RIC.

[0127] In operation 921, the RIC (940) may transmit a RIC Control Request message to the E2 node (910). The RIC Control Request message may include a list of UE IDs.

[0128] As an example of operation 912 to operation 921, when an RRC measurement report arrives at the E2 node (910), the E2 node (910) may transmit a message to the RIC using the connected mode mobility insert service style and the handover control request INSERT indication together with the target cell ID parameter. At this time, the RIC may accept / reject the handover control request, and if accepted, may set the target cell ID parameter value and transmit the control action back to the E2 node. Until then, the E2 node may temporarily suspend the ongoing call processing for the terminal.

[0129] FIG. 12 is a diagram illustrating information elements included in a RIC CONTROL REQUEST message according to one embodiment of the present disclosure. The RIC CONTROL REQUEST message is transmitted by the RIC to the E2 node and can initiate or resume a control function.

[0130] As shown in Fig. 12, the RIC CONTROL REQUEST message may include a Message Type IE, a RIC Request ID IE, a RAN Function ID IE, a RIC Control Header IE, and a RIC Control Message IE. In addition, the RIC CONTROL REQUEST message may further include at least one of a RIC Call Process ID IE or a RIC Control Ack Request IE.

[0131] The Message Type IE is information to uniquely identify a message. The RIC Request ID IE indicates the RIC Request ID, which is unique information about the E2 Node assigned by the RIC. The RIC Request ID is an identifier used to identify the RIC Functional procedure, and messages belonging to the same procedure use the same RIC Request ID. The RAN Function ID IE indicates the RAN Function ID, which is unique information about the E2 Node. The RAN Function ID is an identifier of a specific RAN Function within the E2 Node that supports one or more RIC Services using a specific E2 Service Model (E2SM).

[0132] The RIC Control Header IE is an information element that transmits the RIC Control Header, and the RIC Control Header IE may include a UE ID IE or a UE Group ID IE depending on the Control Header Format or the CONTROL Service Style. As an example of Fig. 7, the header of the RIC CONTROL REQUEST message that the RIC (740) transmits to the E2 node (710) may include a UE ID that can identify the UE to be controlled.

[0133] Depending on the type of CONTROL Service Style, the RIC can modify the configuration of the E2 node for a specific UE or a specific UE group, or the configuration of a specific UE or a specific UE group, or initiate a designated procedure. For example, type 1 of the CONTROL Service Style can be used to modify the configuration of Radio Bearer Control (RBC) related parameters in the E2 node for a specific UE or a specific UE group. As another example, type 2 of the CONTROL Service Style can be used to modify the configuration of Radio Resource Allocation control related parameters of the E2 node for at least one of a specific E2 node, cell, slice, UE, or QoS. As another example, type 3 of the CONTROL Service Style can be used to initiate a handover, a conditional handover, or a Dual Active Protocol Stack (DAPS) for a specific UE that is to move to a target cell or candidate cells. As another example, type 4 of the CONTROL Service Style can be used to modify radio access related functions used to control cell access of the UE. As another example, type 5 of the CONTROL Service Style can be used to initiate Dual Connectivity (DC). As another example, type 6 of the CONTROL Service Style can be used to initiate Carrier Aggregation (CA). As another example, type 7 of the CONTROL Service Style can be used to modify Idle mode mobility-related functions used to control cell reselection by the UE.As another example, type 8 of the CONTROL Service Style can be used to support other RIC services, and can be used to complete Explicit UE list allocation, UE information report generation, and UE identification. As another example, type 9 of the CONTROL Service Style can be used to control the measurement report configuration for a given UE or group of UEs. As another example, type 10 of the CONTROL Service Style can be used to control the beamforming configuration for a specific UE. As another example, type 255 of the CONTROL Service Style can be used for multiple actions of multiple CONTROL Service Styles.

[0134] FIG. 13 is a diagram illustrating a RIC Control Header according to one embodiment of the present disclosure. The information included in the RIC Control Header may vary depending on the Control Header Format. Currently, Control Header Format 1 to Control Header Format 4 may be supported as shown in FIG. 13. The present disclosure provides a new Control Header format, Control Header Format X.

[0135] Figure 14 is a diagram illustrating information included in the Control Header in the case of Control Header Format 1. In the case of Control Header Format 1, the Control Header may include a UE ID IE, a RIC Style Type IE, and a Control Action ID IE. Optionally, the Control Header may further include a RIC Control decision IE.

[0136] The UE ID IE is included in the Control Header to indicate to the E2 node the specific UE that is the target of the control request. The RIC Style Type IE is used to indicate the RIC Control Service Style type, and the Control Action ID IE is used to indicate the control action given by the RIC Control Service Style type.

[0137] The RIC Control Decision IE can be used when a CONTROL action is sent in response to an Insert Indication, or when a RIC Control Request message is sent in response to an INSERT indication message from an E2 node. The RIC Control Decision IE can indicate whether the RIC accepts or rejects an INDICATION request received from an E2 node.

[0138] Figure 15 is a diagram for explaining the information included in the Control Header in the case of Control Header Format 3. In the case of Control Header Format 3, the Control Header may include a UE Group ID IE, a UE Group Definition IE, a RIC Style Type IE, and a Control Action ID IE. In this case, unlike Figure 14, there is no option for the Control Header to include a RIC Control decision IE.

[0139] The UE Group ID IE is included in the Control Header to identify the UE group that is the target of the control request. The UE Group Definition IE may refer to RAN parameters defined to define the UE group. The RIC Style Type IE is identifier information for the RIC Control Service Style. The Control Action ID IE is identifier information for the RIC Control Action.

[0140] Control Header Format 3 is used for group-based CONTROL actions. For example, Control Header Format 3 can be used to initiate or resume Radio Bearer Control-related procedures for a UE group. As another example, Control Header Format 3 can be used to add, modify, or delete Measurement Reporting Configurations for a UE group.

[0141] When indicating a UE group using Control Header Format 3, the corresponding CONTROL action applies to all UEs that constitute the UE group, and Control Header Format 3 can define how to logically group UEs based on a list of RAN parameters.

[0142] FIG. 16 is a diagram for explaining a Control Header of a new format according to an embodiment of the present disclosure. The Control Header of the new format may be referred to as Control Header Format X. In the case of Control Header Format X, the Control Header may include a List of UE IDs IE, a RIC Style Type IE, and a Control Action ID IE. Optionally, the Control Header may further include a RIC Control decision IE.

[0143] Some descriptions of the UE ID IE, RIC Style Type IE, Control Action ID IE, and RIC Control decision IE are briefly explained to avoid duplication with the parts described in Fig. 14.

[0144] The UE ID IE can indicate to the E2 node a specific UE that is the target of the control request, the RIC Style Type IE can be used to refer to the RIC Control Service Style type, and the Control Action ID IE can be used to refer to the control action given the RIC Control Service Style type. The RIC Control Decision IE can be used when a CONTROL action is sent in response to an Insert Indication or when a RIC Control Request message is sent in response to an INSERT indication message from the E2 Node.

[0145] The List of UE IDs IE may mean a list of UE IDs of controlled target terminals. The header of the RIC CONTROL REQUEST message according to one embodiment of the present disclosure may include a list IE of UE IDs of controlled target terminals. The list IE of UE IDs included in the header of the RIC CONTROL REQUEST message may indicate that the CONTROL action is to be applied to all UEs that can be identified through the list. Alternatively, if the list is included in the header, the E2 node may be configured to apply the CONTROL action to all UEs included in the list.

[0146] Referring to FIG. 6, in order to handover terminals UE1 to UE3 to a target cell (631), the RIC (640) can compose a list of UE IDs of UE1 to UE3 and include it in the header of the RIC CONTROL REQUEST message transmitted to the E2 node (610). At this time, the header can use the new format Control Header Format X. Referring to FIG. 8, the RIC can determine a list including the UE IDs of the terminals to be controlled at operation 819 and include it in the header of the RIC CONTROL REQUEST message at operation 821 and transmit it to the E2 node. At this time, the header can use the new format Control Header Format X.

[0147] Comparing the new header of FIG. 16 with the existing header of FIG. 14, the existing header of FIG. 14 has the following disadvantages. According to the existing O-RAN standard, control messages for mobility management such as handover, conditional handover, and DAPS use E2SM-RC Control Header Format 1 as specified in CONTROL Service Style Types 3 of E2SM-RC (service model-RAN control). As described in FIG. 14, in the case of Control Header Format 1, the Control Header includes the UE ID IE for one controlled target terminal. Therefore, when it is necessary to control handover to the same target base station for multiple terminals as in FIG. 6, even if the control messages to be transmitted to the multiple terminals include the same content of information (i.e., target base station information), according to the existing O-RAN standard, a separate RIC CONTROL REQUEST message must be transmitted for each of the multiple terminals. In other words, the RIC transmits multiple RIC CONTROL REQUEST messages to the E2 node, each containing the same message body but with different UE IDs in the header. As a result, the more RIC CONTROL REQUEST messages the RIC transmits to the E2 node, the more overhead there is and the lower the network efficiency may be.

[0148] When performing handover control using the new header of Fig. 16, a list of UE IDs can be configured to prevent duplication of RIC CONTROL REQUEST message transmission, and network efficiency and processing speed can be increased.

[0149] Comparing the new header of FIG. 16 with the existing header of FIG. 15, the existing header of FIG. 15 can be used for UE group-based control in which a control action is applied to all multiple UEs constituting a UE group. The existing header of FIG. 15 is different from the new header of FIG. 16 in that a UE group is formed based on a pre-specified filtering condition. Specifically, the existing header of FIG. 15 includes a UE group ID IE and a UE group definition IE for identifying a UE group. The UE group definition IE may mean a list of identifiers defining a UE group. The RIC Control Request Message including the existing header of FIG. 15 sets in advance the conditions for becoming a controlled target terminal, and therefore is different from the new header of FIG. 16, which specifies a list of controlled target terminals determined by the RIC. An E2 node receiving the existing header of FIG. 15 can identify controlled target terminals based on the UE group ID IE and the UE group definition IE.

[0150] Additionally, the existing header of FIG. 15 is only allowed for UE group-based control for the specified control action in a limited manner. For example, the existing header of FIG. 15 can be used in a limited manner for Radio Bearer Control defined by CONTROL Service Style 1 (e.g., DRB QoS Configuration, QoS flow mapping configuration, Logical channel configuration, Radio admission control, DRB termination control, DRB split ratio control, PDCP Duplication control) and for Measurement Reporting Configuration Control defined by CONTROL Service Style 9 (e.g., addition, modification, deletion of MR Configuration).

[0151] In Fig. 12, the RIC Control Message IE is an information element that conveys a RIC CONTROL MESSAGE. The RIC CONTROL MESSAGE may include a sequence or list of RAN parameters depending on the Control Message Format or the CONTROL Service Style.

[0152] As detailed in Fig. 12, RIC can modify the settings of the E2 node for a specific UE or a specific UE group, or the settings of a specific UE or a specific UE group, or initiate a specified procedure, depending on the type of CONTROL Service Style.

[0153] As an example, the case of CONTROL Service Style 1 for supporting Radio Bearer Control will be described. First, the RIC Control Header IE may include a UE ID IE, a Control Service Style ID, a Control Action ID IE, and a RIC Control Decision IE. At this time, the RIC Control Decision IE may indicate whether the RIC accepts or rejects an INDICATION request from the E2 node. At this time, the Control Header Format 1 IE may be used as the Control Header Format. In addition, the RIC CONTROL MESSAGE IE may include a RAN parameters sequence, and at this time, the Control Message Format 1 IE may be used. Alternatively, in the case of CONTROL Service Style 1, when attempting to control a UE group, the Control Message Format 3 IE may be used.

[0154] As another example, the case of CONTROL Service Style 2 for supporting Radio Resource Allocation Control is described. First, the RIC Control Header IE may include a UE ID IE, a Control Service Style ID, a Control Action ID IE, and a RIC Control Decision IE. At this time, the RIC Control Decision IE may indicate whether the RIC accepts or rejects an INDICATION request from the E2 node. At this time, the Control Header Format 1 IE may be used as the Control Header Format. And, the RIC Control Message IE may include a sequence of RAN parameters. At this time, the Control Message Format 1 IE may be used as the Control Message Format.

[0155] As another example, the case of CONTROL Service Style 3 to support Connected Mode Mobility is described. First, the RIC Control Header IE may include the UE ID IE, Control Service Style ID, Control Action ID IE, and the RIC Control Decision IE. At this time, the RIC Control Decision IE may indicate whether the RIC accepts or rejects the INDICATION request from the E2 node. At this time, the Control Header Format 1 IE may be used as the Control Header Format. And, the RIC Control Message IE may include a sequence of RAN parameters. At this time, the Control Message Format 1 IE may be used as the Control Message Format.

[0156] As another example, for CONTROL Service Style 6 to support Carrier Aggregation Control, the RIC Control Header IE may include UE ID IE, Control Service Style ID, Control Action ID IE, and RIC Control Decision IE. At this time, the RIC Control Decision IE may indicate whether the RIC accepts or rejects the INDICATION request received from the E2 node. At this time, the Control Header Format 1 IE may be used as the Control Header Format. And, the RIC Control Message IE may include a sequence of RAN parameters. At this time, the Control Message Format 1 IE may be used as the Control Message Format.

[0157] Hereinafter, the cases of CONTROL Service Style 3 for supporting Connected Mode Mobility Control among CONTROL Service Styles and CONTROL Service Style 6 for supporting Carrier Aggregation Control are described. These are merely examples and do not limit the present disclosure. In the present disclosure, including the UE IDs of controlled target terminals in a list in the RIC control header IE can be applied to all embodiments that perform CONTROL Service for terminals identified based on the IDs of the terminals included in the RIC control header IE.

[0158] As described above, for CONTROL Service Style 3 to support Connected Mode Mobility Control and CONTROL Service Style 6 to support Carrier Aggregation Control, the Control Message uses Control Message Format 1 IE.

[0159] FIG. 17 is a diagram for explaining information included in a Control Message in the case of Control Message Format 1 according to one embodiment of the present disclosure. When the Control Message uses the Control Message Format 1 IE, the Control Message may include a List of RAN parameters IE, a RAN Parameter ID IE, and a RAN Parameter Value Type IE.

[0160] The List of RAN parameters IE is information included in the RIC Control Message IE to support the list of information for control actions, and RAN parameters may include RAN Parameter ID and RAN Parameter Value Type. The RAN Parameter ID IE can uniquely identify a specific RAN parameter of a given RIC Control style. The RAN Parameter Value Type IE can specify the RAN parameters controlled by the RIC.

[0161] FIG. 18 is a diagram for explaining information included in a RIC Control Request message in the case of CONTROL Service Style 3 for Connected Mode Mobility Control according to one embodiment of the present disclosure.

[0162] FIG. 19 is a diagram for explaining information included in a RIC Control Request message in the case of CONTROL Service Style 6 for Carrier Aggregation Control according to one embodiment of the present disclosure.

[0163] A method performed by a RIC (radio access network (RAN) intelligent controller) according to one embodiment of the present disclosure may include: transmitting, to an E2 node, a RIC SUBSCRIPTION REQUEST message for subscribing to a service provided by an E2 node to provide access to related messages or measurements or to control the E2 node; receiving, from the E2 node, a RIC SUBSCRIPTION RESPONSE message in response to the RIC SUBSCRIPTION REQUEST message; and transmitting, to the E2 node, a RIC CONTROL REQUEST message including an RIC Control Header including a terminal list and an RIC Control Message including control information for controlling a plurality of terminals included in the terminal list.

[0164] The method further includes an operation of receiving, from the E2 node, an RIC Indication message including a message or measurement value related to the E2 node when an event trigger occurs; and an operation of determining the terminal list based on the message or measurement value related to the E2 node, wherein the RIC SUBSCRIPTION REQUEST message may include information about the event trigger.

[0165] The above measurement value may include the throughput value of terminals being served in the cell of the E2 node.

[0166] The RIC CONTROL REQUEST message may further include information for resuming or initiating call processes for each terminal included in the terminal list; and information for modifying at least one of RAN settings or UE context information.

[0167] The RIC Control Header includes the terminal list, RIC Style Type information, and Control Action ID information, and the RIC Style Type information can indicate at least one of connected mode mobility, dual connectivity (DC), carrier aggregation (CA), radio bearer, radio resource allocation, radio access, idle mode mobility, measurement report (MR), terminal information and allocation, beamforming configuration, and multiple actions.

[0168] A method performed by an E2 node of the present disclosure may include: receiving, from a radio access network (RAN) intelligent controller (RIC), an RIC SUBSCRIPTION REQUEST message for subscribing to a service provided by an E2 node to provide access to messages or measurements related to the E2 node or to control the E2 node; transmitting, to the RIC, an RIC SUBSCRIPTION RESPONSE message in response to the RIC SUBSCRIPTION REQUEST message; and receiving, from the RIC, an RIC CONTROL REQUEST message including an RIC Control Header including a terminal list and an RIC Control Message including control information for controlling a plurality of terminals included in the terminal list.

[0169] The method further includes an operation of transmitting, to the RIC, a RIC Indication message including a message or measurement value related to the E2 node when an event trigger occurs, wherein the RIC SUBSCRIPTION REQUEST message includes information about the event trigger, and the terminal list can be determined based on the message or measurement value related to the E2 node.

[0170] The above measurement value may include the throughput value of terminals being served in the cell of the E2 node.

[0171] For each terminal included in the terminal list, the operation may further include an operation of resuming or initiating call processes; and an operation of modifying at least one of RAN settings or UE context information.

[0172] The RIC Control Header includes the terminal list, RIC Style Type information, and Control Action ID information, and the RIC Style Type information can indicate at least one of connected mode mobility, dual connectivity (DC), carrier aggregation (CA), radio bearer, radio resource allocation, radio access, idle mode mobility, measurement report (MR), terminal information and allocation, beamforming configuration, and multiple actions.

[0173] According to one embodiment of the present disclosure, a RIC (radio access network (RAN) intelligent controller) includes a transceiver; a controller; and a storage unit for storing commands, wherein when the commands are executed by the controller: a RIC SUBSCRIPTION REQUEST message is transmitted to an E2 node for subscribing to a service provided by an E2 node to provide access to related messages or measurements or to control the E2 node; a RIC SUBSCRIPTION RESPONSE message is received from the E2 node in response to the RIC SUBSCRIPTION REQUEST message; and a RIC CONTROL REQUEST message including a RIC Control Header including a terminal list and a RIC Control Message including control information for controlling a plurality of terminals included in the terminal list may be transmitted to the E2 node.

[0174] In the RIC, when the commands are executed by the control unit: when an event trigger occurs, an RIC Indication message including a message or measurement value related to the E2 node is received from the E2 node, and the terminal list is determined based on the message or measurement value related to the E2 node, and the RIC SUBSCRIPTION REQUEST message may include information about the event trigger.

[0175] The above measurement value may include the throughput value of terminals being served in the cell of the E2 node.

[0176] The RIC CONTROL REQUEST message may further include information for resuming or initiating call processes for each terminal included in the terminal list; and information for modifying at least one of RAN settings or UE context information.

[0177] The RIC Control Header includes the terminal list, RIC Style Type information, and Control Action ID information, and the RIC Style Type information can indicate at least one of connected mode mobility, dual connectivity (DC), carrier aggregation (CA), radio bearer, radio resource allocation, radio access, idle mode mobility, measurement report (MR), terminal information and allocation, beamforming configuration, and multiple actions.

[0178] According to one embodiment of the present disclosure, an E2 node includes a transceiver; a controller; and a storage unit for storing commands, and when the commands are executed by the controller: an RIC (radio access network (RAN) intelligent controller) may receive a RIC SUBSCRIPTION REQUEST message for subscribing to a service provided by the E2 node to provide access to messages or measurements related to the E2 node or to control the E2 node, and an RIC SUBSCRIPTION RESPONSE message may be transmitted to the RIC in response to the RIC SUBSCRIPTION REQUEST message, and an RIC CONTROL REQUEST message may be received from the RIC, including an RIC Control Header including a terminal list and an RIC Control Message including control information for controlling a plurality of terminals included in the terminal list.

[0179] The E2 node, when the commands are executed by the control unit: when an event trigger occurs, transmits to the RIC an RIC Indication message including a message or measurement value related to the E2 node, the RIC SUBSCRIPTION REQUEST message includes information about the event trigger, and the terminal list can be determined based on the message or measurement value related to the E2 node.

[0180] The above measurement value may include the throughput value of terminals being served in the cell of the E2 node.

[0181] The E2 node, when the commands are executed by the control unit: for each terminal included in the terminal list, call processes may be resumed or initiated, and at least one of RAN configuration or UE context information may be modified.

[0182] The RIC Control Header includes the terminal list, RIC Style Type information, and Control Action ID information, and the RIC Style Type information can indicate at least one of connected mode mobility, dual connectivity (DC), carrier aggregation (CA), radio bearer, radio resource allocation, radio access, idle mode mobility, measurement report (MR), terminal information and allocation, beamforming configuration, and multiple actions.

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

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

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

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

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

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

Claims

1. In a method performed by RIC (RAN (radio access network) intelligent controller), An action of transmitting a RIC SUBSCRIPTION REQUEST message to an E2 node to subscribe to a service provided by the E2 node to provide access to messages or measurements related to the E2 node or to control the E2 node; An operation of receiving a RIC SUBSCRIPTION RESPONSE message from the E2 node in response to the RIC SUBSCRIPTION REQUEST message; and A method comprising an action of transmitting, to the E2 node, a RIC CONTROL REQUEST message including a RIC Control Header including a terminal list and a RIC Control Message including control information for controlling a plurality of terminals included in the terminal list.

2. In claim 1, An operation of receiving, from the E2 node, a RIC Indication message including a message or measurement value related to the E2 node based on the occurrence of an event trigger; and Further comprising an operation of determining the terminal list based on a message or measurement value related to the E2 node; A method in which the RIC SUBSCRIPTION REQUEST message includes information about the event trigger.

3. A method according to claim 2, wherein the measured value includes the throughput value of terminals being served in the cell of the E2 node.

4. In claim 1, The above RIC CONTROL REQUEST message is, for each terminal included in the terminal list, Information to resume or initiate call processes; and A method further comprising information for modifying at least one of RAN configuration or UE context information.

5. In claim 1, The above RIC Control Header includes the terminal list, RIC Style Type information, and Control Action ID information. The above RIC Style Type information is a method for indicating at least one of Connected Mode Mobility, Dual Connectivity (DC), Carrier Aggregation (CA), Radio Bearer, Radio Resource Allocation, Radio Access, Idle Mode Mobility, Measurement Report (MR), Terminal Information and Allocation, Beamforming Configuration, or Multi-Action.

6. In the method performed by the E2 node, An action of receiving a RIC SUBSCRIPTION REQUEST message from a RAN (radio access network) intelligent controller to subscribe to a service provided by an E2 node to provide access to messages or measurements related to the E2 node or to control the E2 node; An action of transmitting a RIC SUBSCRIPTION RESPONSE message to the RIC in response to the RIC SUBSCRIPTION REQUEST message; and A method comprising receiving, from the RIC, an RIC CONTROL REQUEST message including an RIC Control Header including a terminal list and an RIC Control Message including control information for controlling a plurality of terminals included in the terminal list.

7. In claim 6, Further comprising an action of transmitting, to the RIC, a RIC Indication message including a message or measurement value related to the E2 node based on the occurrence of an event trigger, The above RIC SUBSCRIPTION REQUEST message includes information about the above event trigger, A method in which the above terminal list is determined based on a message or measurement value related to the E2 node.

8. A method according to claim 7, wherein the measured value includes a throughput value of terminals being served in the cell of the E2 node.

9. In claim 6, For each terminal included in the above terminal list, The action of resuming or initiating call processes; and A method further comprising an action of modifying at least one of RAN configuration or UE context information.

10. In claim 6, The above RIC Control Header includes the terminal list, RIC Style Type information, and Control Action ID information. The above RIC Style Type information is a method for indicating at least one of Connected Mode Mobility, Dual Connectivity (DC), Carrier Aggregation (CA), Radio Bearer, Radio Resource Allocation, Radio Access, Idle Mode Mobility, Measurement Report (MR), Terminal Information and Allocation, Beamforming Configuration, or Multi-Action.

11. In RIC (RAN (radio access network) intelligent controller), a transceiver; controller; and A storage unit for storing commands, wherein when the commands are executed by the control unit: A RIC SUBSCRIPTION REQUEST message is transmitted to the E2 node to subscribe to a service provided by the E2 node to provide access to messages or measurements related to the E2 node or to control the E2 node. From the E2 node, a RIC SUBSCRIPTION RESPONSE message is received in response to the RIC SUBSCRIPTION REQUEST message, An RIC that transmits a RIC CONTROL REQUEST message including a RIC Control Header including a terminal list and a RIC Control Message including control information for controlling a plurality of terminals included in the terminal list to the E2 node.

12. In claim 11, When the above commands are executed by the above control unit: Based on the occurrence of an event trigger, a RIC Indication message containing a message or measurement value related to the E2 node is received from the E2 node, The terminal list is determined based on the message or measurement value related to the E2 node, The above RIC SUBSCRIPTION REQUEST message includes information about the event trigger, The above measurement value is an RIC including the throughput value of terminals being served in the cell of the E2 node.

13. In claim 11, When the above commands are executed by the above control unit: The above RIC CONTROL REQUEST message is, for each terminal included in the terminal list, Information to resume or initiate call processes; and A RIC further including information to modify at least one of RAN configuration or UE context information. In node 14.E2, a transceiver; controller; and A storage unit for storing commands, wherein when the commands are executed by the control unit: From the RIC (RAN (radio access network) intelligent controller), a RIC SUBSCRIPTION REQUEST message is received to subscribe to a service provided by the E2 node to provide access to messages or measurements related to the E2 node or to control the E2 node, To the above RIC, a RIC SUBSCRIPTION RESPONSE message is transmitted in response to the above RIC SUBSCRIPTION REQUEST message, An E2 node that receives a RIC CONTROL REQUEST message from the RIC, which includes a RIC Control Header including a terminal list and a RIC Control Message including control information for controlling a plurality of terminals included in the terminal list.

15. In claim 14, When the above commands are executed by the above control unit: Based on the occurrence of an event trigger, an RIC Indication message containing a message or measurement value related to the E2 node is transmitted to the RIC, The above RIC SUBSCRIPTION REQUEST message includes information about the above event trigger, The above terminal list is determined based on messages or measurements related to the E2 node, The above measurement value is an E2 node including the throughput value of terminals being serviced in the cell of the E2 node.

Images