WO2025238873A1 - Ric node, e2 node, method and program - Google Patents

Abstract

According to one aspect of the disclosure, there is provided a RIC (Radio Access Network Intelligent Controller) node that includes: at least one memory configured to store an instruction; at least one processor configured to execute the instruction; and at least one transceiver, wherein the processor, by executing the instruction, sends a first message to an E2 node using the transceiver, the first message including one or more IEs (Information Elements) indicating that the E2 node sends a second message to the RIC node if the following condition is met: an operation result satisfies a predetermined condition, while the operation result includes an operation result for at least a first element related to one or more first RAN parameters and a second element related to one or more second RAN parameters.

Description

RIC NODE, E2 NODE, METHOD AND PROGRAM

　　The present disclosure relates to a RIC (RAN (Radio Access Network) Intelligent Controller) node, an E2 node, a method, and a program.

　　Techniques for wireless communication, i.e. 5G (Fifth Generation), have been advancing. For example, NPL 1 discloses O-RAN (Open Radio Access Network) E2 Application Protocol.

NPL 1: O-RAN E2 Application Protocol (E2AP) 5.0: O-RAN.WG3.E2AP-R003-v05.00

　　In related art, a Near-RT (Realtime) RIC (RAN (Radio Access Network) Intelligent Controller) node sends a RIC Subscription Request to an E2 node. One or more IEs (Information Elements) of the RIC Subscription Request indicate the given conditions for one or more RAN parameters. When the given conditions are met, the E2 node sends a RIC indication to the Near-RT RIC node. However, when the conditions are not met, the E2 node does not send the RIC indication to the Near-RT RIC node. The RIC indication includes an action query about an action to be performed by the E2 node. At this time, the E2 node may have to interrupt its processing.

　　The Near-RT RIC node determines what action should be taken at the E2 node and sends the E2 node a RIC control request indicating the result of the determination. After receiving the RIC control request, the E2 node performs the action indicated in the RIC control request and resume the processing.

　　As shown above, when the given conditions are not met, the E2 node does not have to send the RIC indication to the Near-RT RIC node. However, in the related art, the given conditions that can be specified by the RIC Subscription Request are limited. Therefore, in many cases, the E2 node has to send the RIC indication and interrupt its processing. This may cause unnecessary communication between nodes and eventually communication delay.

　　One example of object of the present disclosure is to provide a RIC node, an E2 node, a method, and a program capable of contributing to reduce unnecessary communication. However, it should be noted that this object is only one of a plurality of objects that a plurality of example embodiments disclosed herein seek to achieve. Other objects or issues and new features are apparent from the description or accompanying drawings herein.

　　According to the first aspect of the disclosure, there is provided a RIC node that includes:
　　at least one memory configured to store an instruction;
　　at least one processor configured to execute the instruction; and
　　at least one transceiver, wherein
　　the processor, by executing the instruction,
　　　　sends a first message to an E2 node using the transceiver, the first message including one or more IEs (Information Elements) indicating that the E2 node sends a second message to the RIC node if the following condition is met:
　　　　　　an operation result satisfies a predetermined condition, while the operation result includes an operation result for at least a first element related to one or more first RAN parameters and a second element related to one or more second RAN parameters.

　　According to the second aspect of the disclosure, there is provided an E2 node that includes:
　　at least one memory configured to store an instruction;
　　at least one processor configured to execute the instruction; and
　　at least one transceiver, wherein
　　the processor, by executing the instruction,
　　　　receives a first message from the RIC node using the transceiver; and
　　　　sends a second message to the RIC node using the transceiver when the following condition indicated in one or more IEs (Information Elements) of the first message is met:
　　　　　　an operation result satisfies a predetermined condition, while the operation result includes an operation result for at least a first element related to one or more first RAN parameters and a second element related to one or more second RAN parameters.

　　According to the third aspect of the disclosure, there is provided a method performed by a RIC node that includes:
　　sending a first message to an E2 node using a transceiver, the first message including one or more IEs (Information Elements) indicating that the E2 node sends a second message to the RIC node if the following condition is met:
　　　　an operation result satisfies a predetermined condition, while the operation result includes an operation result for at least a first element related to one or more first RAN parameters and a second element related to one or more second RAN parameters, and
　　receiving the second message from the E2 node using the transceiver.

　　According to the fourth aspect of the disclosure, there is provided a method performed by an E2 node that includes:
　　receiving a first message from a RIC node using a transceiver; and
　　sending a second message to the RIC node using the transceiver when the following condition indicated in one or more IEs (Information Elements) of the first message is met:
　　　　an operation result satisfies a predetermined condition, while the operation result includes an operation result for at least a first element related to one or more first RAN parameters and a second element related to one or more second RAN parameters.

　　According to the fifth aspect of the disclosure, there is provided a program for causing a RIC node to execute:
　　sending a first message to an E2 node using a transceiver, the first message including one or more IEs (Information Elements) indicating that the E2 node sends a second message to the RIC node if the following condition is met:
　　　　an operation result satisfies a predetermined condition, while the operation result includes an operation result for at least a first element related to one or more first RAN parameters and a second element related to one or more second RAN parameters, and
　　receiving the second message from the E2 node using the transceiver.

　　According to the sixth aspect of the disclosure, there is provided a program for causing an E2 node to execute:
　　receiving a first message from a RIC node using a transceiver; and
　　sending a second message to the RIC node using the transceiver when the following condition indicated in one or more IEs (Information Elements) of the first message is met:
　　　　an operation result satisfies a predetermined condition, while the operation result includes an operation result for at least a first element related to one or more first RAN parameters and a second element related to one or more second RAN parameters.

　　According to the present disclosure, it is possible to provide a RIC node, an E2 node, a method, and a program capable of contributing to reduce unnecessary communication.

Fig. 1 is an example of a block diagram of an O-RAN system according to related art. Fig. 2 is a sequence flow of an event subscription according to the related art. Fig. 3 is a sequence flow of an RIC indication according to the related art. Fig. 4 is a sequence flow of handling the indication according to the related art. Fig. 5 is a sequence flow of RIC control according to the related art. Fig. 6 is a sequence flow of applying decision according to the related art. Fig. 7 is a sequence flow between a RIC node and an E2 Node. Fig. 8 is a block diagram showing a configuration example of a Near-RT RIC. Fig. 9 is a block diagram showing a configuration example of an E2 Node.

　　(Notes)
　　Example embodiments according to the present disclosure will be described hereinafter with reference to the drawings. Note that the following description and the drawings are omitted and simplified as appropriate for clarifying the explanation. Further, the same elements are denoted by the same reference numerals and/or letters throughout the drawings, and redundant descriptions thereof are omitted as required. This repetition is for the purpose of simplicity and clarity and does not in itself dictate a relationship between the various embodiments and/or configurations discussed.

　　Also, in this disclosure, unless otherwise specified, "at least one of A or B (A/B)" may mean any one of A or B, or both A and B. Similarly, when "at least one" is used for three or more elements, it can mean any one of these elements, or any plurality of elements (including all elements). Use of the term "and/or" means that each option is usable individually or in combination with any, or all, of the other options. Further, it should be noted that in the description of this disclosure, elements described using the singular forms such as "a", "an", "the" and "one" may be multiple elements unless explicitly stated.

　　As used herein, "if" may be interpreted as "when", "at or around the time", "after", "upon", "in response to determining", "in accordance with a determination", or "in response to detecting" depending on the context. These expressions may be interpreted to mean the same thing, depending on the context.

　　Each of the drawings or figures is merely an example to illustrate one or more example embodiments. Each figure may not be associated with only one particular example embodiment but may be associated with one or more other example embodiments. As those of ordinary skill in the art will understand, various features or steps described with reference to any one of the figures can be combined with features or steps illustrated in one or more other figures, for example, to produce example embodiments that are not explicitly illustrated or described. Not all of the features or steps illustrated in any one of the figures to describe an example embodiment are necessarily essential, and some features or steps may be omitted. The order of the steps described in any of the figures may be changed as appropriate.

　　Further, the following disclosure provides many different embodiments, or examples, for implementing different features of the provided subject matter. Specific examples of components, values, operations, materials, arrangements, or the like, are described below to simplify the present disclosure. These are, of course, merely examples and are not intended to be limiting. Other components, values, operations, materials, arrangements, or the like, are contemplated. For example, the formation of a first feature over or on a second feature in the description that follows may include embodiments in which the first and second features are formed in direct contact, and may also include embodiments in which additional features may be formed between the first and second features, such that the first and second features may not be in direct contact.

　　The example embodiments shown below are described primarily for Near-RT RICs and E2 nodes that conform to O-RAN technical specifications. In this disclosure, the E2 node is the node that terminates an E2 interface, including, but not limited to, an O-CU (O-RAN Central Unit), an O-CU-CP (O-RAN Central Unit-Control Plane), an O-CU-UP (O-RAN Central Unit-User Plane), an O-DU (O-RAN Distributed Unit), and an O-eNB (eNodeB). The E2 interface is the interface used by the Near-RT RIC to send control instructions to downstream network functions (For example, the O-DU, the O-CU-CP, the O-CU-UP, or the O-eNB). However, these example embodiments may be applied to other systems that support techniques similar to Near-RT RICs and E2 nodes.

　　(References)
　　References cited in this disclosure are expressed as follows;
[1]: O-RAN E2 Application Protocol (E2AP) 5.0 : O-RAN.WG3.E2AP-R003-v05.00
[2]: O-RAN E2 Service Model (E2SM), RAN Control 5.0 O-RAN.WG3.E2SM-RC-R003-v05.00
[3]: O-RAN E2 Service Model (E2SM), KPM O-RAN.WG3.E2SM-KPM-R003-v04.00
[4]: O-RAN Work Group 1 Use Cases Detailed Specification, O-RAN.WG1.Use-Cases-Detailed-Specification-R003-v13.00.
[5]: 3GPP TS 28.552 v18.0.0: "Management and orchestration 5G performance measurements".

　　(Related Art)
　　Before describing the techniques characteristic of the present disclosure, the related art will be described.

　　Fig. 1 shows example of a block diagram of an O-RAN system according to the related art. The architecture for O-RAN QoS (Quality of Service) -Based Resource Optimization will be discussed below.

　　Referring to Fig. 1, the O-RAN system S01 includes a Non-RT (Realtime) RIC node 110, a Near-RT RIC node 120, an EMS (Element Management System) 130, an O-DU (O-RAN Distributed Unit) 140, a RU (Radio Unit) 150 and an O-CU (O-RAN Central Unit) 160. Hereinafter, the RIC node (the Non-RT/ Near-RT RIC node) may be referred to simply as the RIC. Each component in the O-RAN system S01 is a network node. As an example, at least one of components in the O-RAN system S01 can be installed in a computer as a combination of one or a plurality of memories and one or a plurality of processors.

　　The Non-RT RIC 110 functions as a non-real-time RAN Intelligent Controller and constitutes a part of Service Management and Orchestration Framework. It can perform non-real-time control and optimization of RAN elements and resources. The non-real-time control takes some time (e.g., longer than 1 second). Further, the Non-RT RIC 110 may provide the Near-RT RIC 120 with operational guidance, e.g., policies. The operational guidance can manage an application set, i.e., xAPPs (xApplications) 121. The Non-RT RIC 110 and the Near-RT RIC 120 are connected via an A1 Interface.

　　The Near-RT RIC 120 functions as a near-real-time RAN Intelligent Controller. In other words, the Near-RT RIC 120 is a processing entity that takes decision on RAN network configuration. It can perform near-real-time control and optimization of RAN elements and resources. The near-real-time control takes less time (e.g., shorter than 1 second) compared to the non-real-time control performed by the Non-RT RIC 110. The optimization is based on data collection and actions over an E2 interface. The E2 interface connects the Near-RT RIC 120 and E2 nodes, e.g., O-DU 140 and O-CU 160.

　　Specifically, the Near-RT RIC 120 has the capability to retrieve information from the E2 node and to answer to a request from the E2 node for a configuration update or for an action to take. For instance, the Near-RT RIC 120 can retrieve information about resource usage in O-DU cells, and when the O-DU 160 receives a new UE or a UE modification request, the O-DU 160 pauses the handling and request Near-RT to take the decision of accepting or rejecting an incoming UE request or UE modification. This is a role of the QoS Based Resource Optimization use case introduced by O-RAN WG1. The disclosure in [4] shall apply mutatis mutandis to this description.

　　The xAPPs 121 are deployed on the Near-RT RIC 120 and used for QoS-Based resource optimization. The xAPPs 121 can allow the Near-RT RIC 120 to analyze a variety of information and control other elements. The xAPPs 121 enables the Near-RT RIC 120 to provide Near-RT control commands to the O-DU 140 and/or the O-CU 160.

　　The EMS 130 is provided to monitor and manage network nodes, for instance regarding traffic, performance and security, in the O-RAN system S01. The EMS 130 and other elements, e.g., the Near-RT RIC 120 and the O-DU 140, are connected via an O1 Interface. The EMS 130 can manage other elements via the O1 Interface.

　　The O-DU 140 hosts a set of protocols including RLC (Radio Link Control), MAC (Medium Access Control) and/or PHY (physical interface). The O-DU 140 and the O-CU 160 is connected by an Open F1 Interface (CU-DU higher layer split interface), which ensures inter-operability between both of the nodes.

　　The RU 150 hosts Low-PHY layer and RF (Radio Frequencies) processing based on the physical layer of the O-RAN system S01. The RU 150 can send the O-DU 140 the processed radio frequencies via an Open Fronthaul interface.

　　The C-DU 160 hosts a set of protocols including RRC (Radio Resource Control), SDAP (Service Data Adaptation Protocol) and/or PDCP (Packet Data Convergence Protocol). The C-DU 160 includes an O-CU-CP (O-RAN Central Unit-Control Plane) 161 and an O-CU-UP (O-RAN Central Unit- User Plane) 162. The O-CU-CP 161 hosts the RRC and the O-CU-UP 162 hosts the SDAP. Further, the control plane part of the PDCP is in charge by the O-CU-CP 161 and the user plane part of the PDCP is in charge by the O-CU-UP 162. The O-CU-CP 161 and the O-CU-UP 162 are connected by an E1 Interface within the C-DU 160.

　　The Open Fronthaul, Open F1, and E2 interfaces are standardized by the O-RAN Alliance. The O-RAN Alliance defines the content of the messages that are sent between nodes, and the behavior of the node upon receiving a message.

　　Further, although not shown in Fig. 1, UEs (User Equipments) are connected to the O-RAN through the RU 150. Each UE has one or multiple DRB (Data Radio Bearer) to be connected to the O-RAN system S01. The UE is connected to the RU 150 using 4G (Fourth Generation), or 5G radio technology defined by 3GPP (Third Generation Partnership Project).

　　In this system, there might be a problem that, in multiple cases, the E2 node sends a request to the Near-RT RIC 120 although the request is in fact not required. The consequences are that the E2 node and consequently the UE wait for the answer, and the network has increased traffic load and processing load.

　　A mechanism already exists to avoid cases defined by simple conditions:
　　- the state of a parameter indicating a physical quantity:
　　　　-# presence (memory allocated),
　　　　-# configured (value is not NULL),
　　　　-# was configured as max defined value and value is now 0,
　　　　-# value is different than 0,
　　　　-# length of the value is higher than 0
　　- comparison between a parameter X and a value Y given by the Near-RT RIC 120 through the RIC Subscription Request:
　　　　-# X equal to Y,
　　　　-# X different to Y,
　　　　-# X greater than Y,
　　　　-# X less than Y,
　　　　-# X contains Y,
　　　　-# X starts with Y.
The above notation indicates the hierarchical relationship of the parameters. In the following description, the hierarchical relationship of the parameters is expressed in the same way.

　　In the following, the process in which the traditional issue occurs will be explained.

　　The O-RAN WG1 introduces more than 20 use cases related to a Near-RT RIC. The present issue may occur in multiple of them. However, for the sake of simplicity, hereafter QoS Based Resource Optimization is used as an example. The disclosure in [4] is applied below as appropriate.

　　Fig. 2 shows a sequence flow of an event subscription according to the related art. This event subscription is described in figure 8.2.1.2-1 of [1]. In Fig. 2 and the following related figures, for the sake of simplicity, only a Near-RT RIC 2 and an E2 Node 4 are considered. The Near-RT RIC 2 corresponds to the Near-RT RIC 120 and the E2 Node 4 corresponds to the O-DU 140 / the O-CU 160. In the following example, the E2 Node 4 corresponds to the O-DU 140.

　　First, the QoS Based Resource Optimization xApp (hereafter QoS xApp) located within the Near-RT RIC 2 subscribes to the following events at the E2 Node 4 (DU side) using an E2 interface:
- UE Context Setup: a new UE wants to be connected to the network through a RU. The UE may have multiple DRBs to be connected.
- UE Context Modification: the context of the UE is modified.

　　As shown in 9.1.1.1 "RIC SUBSCRIPTION REQUEST" of [1], the content of the RIC Subscription Request is shown in the following table 1. The two characteristic IEs are indicated by the underlines below.

　　The message above is sent by the Near-RT RIC 2 to the E2 Node 4 to create a new RIC Subscription in the E2 Node 4 (step S12 in Fig. 2). After receiving the RIC Subscription request, the E2 Node 4 sends a RIC Subscription response to the Near-RT RIC 2 (step S14 in Fig. 2).

　　As indicated in table 1 above, the RIC Subscription Request includes the following two characteristic IEs:
(1) RIC Event Trigger Definition: Description of the event to which the E2 Node 4 shall react to. Multiple formats can be used here. The content of the format used in QoS Based Resource Optimization may the Format 2 below, whose content is as following:
(1A) Description of the event: call process breakpoint. The event happens when a specific function is called. In the case of QoS Based Resource Optimization, it is the handling of UE Context Setup message, and the handling of UE Context Modification message.
(1B) Additional E2 Node information
(1C) Additional UE information
Additional information is used to filter the events. If the event corresponding to the description (1A) occurs, the information of the UE and the E2 Node 4 for which the event has been triggered must match the "Additional information". If the information does not match, the Action (described in (2) below) is not taken.
(2) RIC Action Definition. The action(s) that the E2 Node 4 shall take upon event triggering, among any combination of the below:
(2A) Send "Report Indication" to Near-RT RIC: E2-Node reports information to Near-RT RIC:
- Message that has been received, value of a parameter…
(2B) Act according to a policy,
(2C) Send "Insert Indication" to Near-RT RIC: Request for Near-RT RIC action.
In the case of QoS Based Resource Optimization, the action is (2C) Request for Near-RT RIC action (see below).

　　Fig. 3 shows a sequence flow of an RIC indication according to the related art. This RIC indication is described in figure 8.2.3.2-1 of [1]. Fig. 3 depicts the case in which when such event happens in the E2 Node, if the RIC Action Definition is (2C), namely "Send Insert Indication to Near-RT RIC", the E2 Node 4 stops the event handling and starts its timer. It generates a request to have the Near-RT RIC 2 make a decision regarding the event by including the new UE Context into a RIC Indication message. Then, it sends the message to the Near-RT RIC 2 using an E2 interface (step S16 in Fig. 3).

　　Fig. 4 shows a sequence flow of handling the indication according to the related art. As depicted in Fig. 4, the QoS xApp in the Near-RT RIC 2 uses the information included in the RIC indication to decide whether the new UE context should be accepted or not (step S18 in Fig. 4).

　　Fig. 5 shows a sequence flow of RIC control according to the related art. This RIC control is described in figure 8.2.4.2-1 of [1]. The QoS xApp 121 enables the Near-RT RIC 2 to send the E2 Node 4 a message as a RIC control request containing the decision of accepting or rejecting the UE Context through the E2 interface (step S20 in Fig. 5). The E2 Node 4 replies with an acknowledgement as a RIC control acknowledge (step S22 in Fig. 5).

　　Fig. 6 shows a sequence flow of applying the decision according to the related art. The E2 Node resumes the handling of the event, stops the timer, and applies the decision of accepting or rejecting the new UE Context (step S24 in Fig. 6).

　　There are multiple instances where the request for control (carried by the Indication message shown in Fig. 3) is not needed. For instance, if the Setup or Modification does not increase the GBR (Guaranteed Bit Rate: in other words, Guaranteed Flow Bit Rate Downlink) required by the UE, the decision from the Near-RT RIC is not required. Further, if the UE Context Modification applies a modification to a parameter unrelated to GBR, there is no change in the GBR requested by the UE, because in UE Context, the QoS xApp does not use any parameter other than the GBR.

　　Even in such cases, the request for control is triggered, and it induces a non-negligible latency to the request because the E2 Node has to wait for the Near-RT RIC Control request message (shown in Fig. 5) in order to resume the event handling. The latency may cause the timer to reach the timeout value. It also induces avoidable processing load in both ends, alongside with avoidable message traffic.

　　Considering the problem of the related art, characteristic nodes of the present disclosure will be discussed to contribute to reduce unnecessary communication shown above.

　　(First Example Embodiment)
　　< Process Description >
　　Referring to Fig. 7, a communication system includes a RIC 12 and an E2 Node 14. Each of the elements shown in Fig. 7 can be implemented, for example, as an element on dedicated hardware, as a running software instance running on dedicated hardware, or as an instantiated virtualization function on an application platform. Each of the elements shown in Fig. 7 may be implemented as a computer system with one or more memories and one or more processors. The computer system may be one computer system or multiple (distributed) computer systems. The computer system may be a stand-alone computer or may include one or more networked computers.

　　The RIC 12 sends a first message to the E2 node 14 (step S102 in Fig. 7). The first message includes one or more IEs (Information Elements) indicating that the E2 node 14 sends a second message to the RIC 12 if the following condition is met: an operation result satisfies a predetermined condition, while the operation result includes an operation result for at least a first element related to one or more first RAN parameters and a second element related to one or more second RAN parameters. Examples of the predetermined condition and the operation result will be described in the Second Example Embodiment. The one or more first RAN parameters may be the same as the one or more second RAN parameters, while the one or more first RAN parameters and the one or more second RAN parameters may belong to different labels (identifiers). For example, the one or more first RAN parameters relate to the Mean DL PRB Used for data traffic of specific 5QI(s) and the one or more second RAN parameters relate to the Mean DL PRB Used for data traffic of (an)other 5QI(s). However, at least one parameter of the one or more first RAN parameters may differ from any one of the second RAN parameters.

　　The E2 node 14 receives the first message from the RIC node 12. After that, the E2 node 14 can send a second message to the RIC node when the conditions above in the one or more IEs of the first message are met (step S104 in Fig. 7). The second message may correspond to the RIC Indication in Fig. 3.

　　<Description of Effects>
　　As shown above, the first message indicates the precise condition for causing the E2 node 14 to decide whether or not to send the message to the RIC node 12. Therefore, unlike the case of the related art, the E2 node 14 does not have to send the message in some cases. This can reduce unnecessary communication between the nodes and eventually communication delay.

　　(Second Example Embodiment)
　　A second example embodiment of this disclosure will be described below referring to the accompanied drawings. This second example embodiment explains one of the specific examples of the first example embodiment, however, specific examples of the first example embodiment are not limited to this example embodiment.

　　<Applying to IEs of Existing Standards>
　　Before explaining specific processes, it will be explained that how set a condition for Event Triggering according to existing standards. Specifically, it will be explained that how the condition can be defined into the RIC Subscription Request according to the related art.

　　Suppose the condition, "DL PRB Usage > threshold value", as an example. With this condition, an E2 Node sends the RIC Indication upon receiving a UE Context Setup / UE Context Modification message only if the DL (Downlink) PRB (Physical Resource Block) Usage of the related cell is above a threshold value.

　　For the QoS Based Resource Optimization, the RIC Event Trigger Definition included in the RIC Subscription Request (shown in Fig. 2) can use the Format 2 below. The format is described in 9.2.1.1.2. "E2SM-RC Event Trigger Definition Format 2: Call Process Breakpoint" of [2].

The underlined IE above, "Associated E2 Node Info", is a characteristic IE. The underlined text in "Semantics Description" column above explains what information can be included as a condition: only RAN Clause 8.1.2 referenced in "Associated E2 Node Info" can be included as an "E2 Node Info".

　　Further, the reference 9.3.29 in "IE type and reference" column in table 2 explains how the condition should be described. In the following description, three cases of I) to III) will be discussed.
- In I), it is explained that DL PRB Usage can be used as a condition.
- In II), it is explained how to include DL PRB Usage as a condition.
- In III), information of I) and II) is used to describe the Event Trigger that is a part of RIC Subscription Request message.

　　I) Proof that DL PRB Usage can be used as condition
The content of the Clause 8.1.2, "RAN Parameters for Call Process Breakpoint", especially the Clause 8.1.2.0, "Call process type IDs", shown in [2], is as following:

The RAN Parameters for the Event Trigger style 2 are defined based on the call process type above.

　　In the QoS Based Resource Optimization, the UE Context is focused, so the Clause 8.1.2.1, "UE Context Management", in [2] is discussed here. "UE Context Management" is the underlined IE in table 3. In this Clause, the RAN Parameters for the call process type of "UE Context Management" are defined in accordance with the Clause 8.1.2.1.1, "UE Context Setup", as follows:

　　The RAN Parameter ID 25063 "E-UTRA Pcell", underlined in table 4 above, refers to the subsection 8.1.1.2, "E-UTRA Cell", in [2]. In the subsection, the following RAN Parameters are associated with the E-UTRA cell.










By examining the reference [2] with "Associated E2 Node Info" contained in "E2SM-RC Event Trigger Definition Format 2: Call Process Breakpoint" as the starting point, it can be found that the RAN Parameter ID 12031 underlined in table 5 above contains the DL PRB Usage. This parameter is limited to E-UTRA (Evolved Universal Terrestrial Radio Access) cells (i.e. 4G cells). This parameter cannot be obtained for NR (New Radio) cells (i.e. 5G cells). As explained above, it is possible to include the DL PRB Usage as a condition.

　　II) How to include DL PRB Usage as condition
　　Now it is explained how to include the DL PRB Usage and the threshold as a condition. As explained above, this is described in Clause 9.3.29, "RAN Parameter Conditional Criteria Definition", in [2]. The Clause shows the IE underlined in table 6 below defines the generic test conditions based on RAN parameters.

　　Further, Clause 9.3.30, "RAN Parameter Test", in [2] is described here. The IEs underlined in table 7 below define a test condition for a RAN Parameter. Only "ELEMENT" type of a RAN parameter with Key Flag set to "False" is tested.

　　Further, Clause 9.3.31, "RAN Parameter Test Condition", in [2] is described here. The IE underlined in table 8 compares the value X of a given RAN parameter with the target value Y. X is the value of the RAN parameter within the E2 node, Y is the target value given by the Near-RT RIC included in the first message.

　　III) Content of RIC Subscription Request message
　　According to I) and II), the content of the Event Trigger Definition that is a part of RIC Subscription message is as following:
- Call Process Type ID: 1 for UE Context Management
- Call Breakpoint ID: 1 for UE Context Setup, 2 for UE Context Management
- Associated E2 Node Info:
　　-# RAN Parameter Testing:
　　--* RAN Parameter ID: 12031 (refers to DL PRB Usage of an E-UTRA Cell)
　　--* RAN Parameter Test Condition:
　　　　---+ Comparison: "greaterthan"
　　--* RAN Parameter Value: threshold value
The above is an example for the QoS Based Resource Optimization, but the problem happens whenever the Near-RT RIC subscribes to an event occurrence upon which the E2 node has to stop the handling.

　　< Process Description >
　　Now the characteristic processes in the second example embodiment are discussed. The communication system shown in Fig. 1 and its description above shall be applied mutatis mutandis to the communication system described in the second example embodiment; therefore, the explanation of the system is omitted here.

　　The idea disclosed in the second example embodiment aims at improving the subscription to events (shown in Fig. 2), because the current subscription definition includes a major drawback: there is no enough possibility for including conditions to control whether or not an event should trigger a request to the Near-RT RIC. Thus, even the report message unnecessary to be processed by the Near-RT RIC is sent. It creates unnecessary processing in both endpoints, unnecessary traffic in the E2 interface, and latency for completing the initial task.

　　The idea disclosed here is to improve the Event Trigger definition of the RIC Subscription Request in order to expand the possibility for the conditions in the subscription.

　　(Applying an arithmetic operator)
　　An operation between X and Y is defined as follows, where X and Y can be either a value or another RAN Parameter or the result of an operation:
- Addition: X + Y
　　-# Terms X and Y may be different RAN Parameters, values and the result of another operation
- Subtraction: X - Y,
　　-# Terms X and Y may be different RAN Parameters, values and the result of another operation
- Multiplication: X * Y,
- Division: X / Y.
　　-# Terms X and Y may be different RAN Parameters, values and the result of another operation
- Summation:
,
where S is a Sequence (i.e., a list).
　　-# Term X is the same RAN Parameter
　　-# Filter: apply a filter on the RAN Parameters of items of S to reduce the size of S

　　(Applying a comparison operator)
　　A comparison between X and Y where X and Y can be either a value or another RAN Parameter or the result of an operation:
- X equal to Y,
- X different to Y,
- X greater than Y,
- X less than Y,
- X contains Y,
- X starts with Y.

　　These operators above allow an E2 node to send an Indication only when the following conditions are met (examples). The specific conditions will be explained in detail.

　　(Condition 1)
　　Condition 1: Send an indication only if X / Y is lower than a given percentage, while X is the ratio of the Mean DL PRB used for data traffic by DRBs of specific 5QI(s) during a certain period, and Y is the DL Total available PRB during the same period. Using the condition 1, when the UE Context Setup or UE Context Modification is received, if

then an event is triggered.

　　This condition is useful when it is required that the Near-RT RIC control requests only when the ratio of used (i.e. available for allocation) PRBs for given 5QI(s) is over a threshold. In limited cases, the Near-RT RIC does this to prevent the situation from reaching a resource-limited scenario where a corresponding cell cannot have the resources required for the GBR of all UEs.

　　The 5QIs are linked to a specific kind of service. For instance, there are 5QIs for services that require high throughput (i.e. require a lot of PRBs). It is useful to restrict the indication to the Near-RT RIC so that it is indicated only to the cases where the incoming request contains such 5QIs and only when such 5QIs use resource above a threshold in the following scenario:
- The Near-RT RIC is required to make sure that some 5QIs do not use up all the resources, giving no resource for other 5QIs.

　　For this condition, the Event Trigger Definition content would be as follows:
- Call Process Type ID: 1 for UE Context Management
- Call Breakpoint ID: 1 for UE Context Setup, 2 for UE Context Modification
- Condition:
　　-# Number of RAN Parameter: 2
　　-# Number of values: 1
　　-# Number of operations: 2
　　-# RAN Parameter 1:
　　　　--* Type: E2SM-KPM (RAN Parameter is available through E2SM-KPM shown in [3])
　　　　--* Name: "Mean DL PRB Used for data traffic"
　　　　--* Granularity: period T
　　　　--* Label: specific 5QI
　　-# RAN Parameter 2:
　　　　--* ID: 10123 (refers to "Available DL PRBs in the cell" in "NR Cell")
　　-# Value 1:
　　　　--* Value: threshold value
　　-# Operation 1:
　　　　--* Operation type: "summation of X"
　　　　--* RAN Parameter number or value number or Operation number for X: RAN Parameter 1
　　　　--* Order: 1
　　-# Operation 2:
　　　　--* Operation type: "X divided by Y"
　　　　--* RAN Parameter number or value number or Operation number for X: Operation 1
　　　　--* RAN Parameter number or value number or Operation number for Y: RAN Parameter 2
　　　　--* Order: 2
　　-# Comparison:
　　　　--* Comparison type: "X greater than Y"
　　　　--* RAN Parameter number or value number or Operation number for X: Operation 2
　　　　--* RAN Parameter number or value number or Operation number for Y: Value 1

　　(Condition 2)
　　Condition 2: Send an indication only if X - Y is lower than a given threshold, while X is the DL Total available PRB over a certain period and Y is the Mean DL PRB used for data traffic by DRBs of specific 5QI(s) over the same period. Using the condition 2, when the UE Context Setup or UE Context Modification is received, if


then an event is triggered.

　　In this Condition 2, available Event Trigger Definition content is similar to the Condition 1; however, the description of ratio can be replaced with the description of a value.

　　(Condition 3a)
　　Condition 3a: Send an indication only if X is greater than Y, while X is the GBR summed with respect to new DRBs after admission and Y is the GBR summed with respect to the old DRBs before the admission. In other words, in this condition if the requested Context has higher GBR than before, the indication is sent in order to control only when the GBR increases (case of UE Context Setup). Using the condition 3a, when the UE Context Setup or UE Context Modification is received, if

then an event is triggered.

　　This condition is useful when it is required that the Near-RT RIC control any request that has any little increase in the GBR. This is useful because if there is no GBR increase, then the amount of resources required to satisfy the GBR does not increase. An objective of the Near-RT RIC is to make sure that there is enough resource to satisfy the GBR by considering the same parameters for different time periods (types). If the amount of resources required to satisfy the GBR does not increase, then the Near-RT RIC does not need to decide. As such, when there is no GBR increase, there is no need to send an indication to the Near-RT RIC.

　　(Condition 3b)
　　Condition 3b: Send an indication only if X is greater than Y, while X is a value obtained by adding the GBR summed with respect to modified DRBs after admission to the GBR summed with respect to new DRBs after admission and subtracting the GBR summed with respect to removed DRBs, and Y is the GBR summed with respect to the old DRBs before admission. In other words, in this condition if the requested Context has higher GBR, the indication is sent in order to control only when the GBR increases (case of UE Context Modification). Using the condition 3b, when the UE Context Setup or UE Context Modification is received, if

then an event is triggered.

　　For this condition, the Event Trigger Definition content would be as follows:
- Call Process Type ID: 1 for UE Context Management
- Call Breakpoint ID: 2 for UE Context Modification
- Condition:
　　-# Number of RAN Parameter: 4
　　-# Number of values: 0
　　-# Number of operations: 6
　　-# RAN Parameter 1:
　　　　--* Type: E2SM-RC
　　　　--* ID: 15011 (refers to "Guaranteed Flow Bit Rate Downlink" in "QoS Flow")
　　　　--* Parent structure: 21524 (refers to "List of DRBs" in "UE Context Information")
　　-# RAN Parameter 2:
　　　　--* Type: E2SM-RC
　　　　--* ID: 15011 (refers to "Guaranteed Flow Bit Rate Downlink" in "QoS Flow")
　　　　--* Parent structure: 25119 (refers to "List of DRBs for setup" in "UE Context Modification")
　　-# RAN Parameter 3:
　　　　--* Type: E2SM-RC
　　　　--* ID: 15011 (refers to "Guaranteed Flow Bit Rate Downlink" in "QoS Flow")
　　　　--* Parent structure: 25127 (refers to "List of DRBs to be modified" in "UE Context Modification")
　　-# RAN Parameter 4:
　　　　--* Type: E2SM-RC
　　　　--* ID: 15011 (refers to "Guaranteed Flow Bit Rate Downlink" in "QoS Flow")
　　　　--* Parent structure: 25136 (refers to "List of DRBs to be released" in "UE Context Modification")
　　-# Operation 1:
　　　　--* Operation type: "summation of X"
　　　　--* RAN Parameter number or value number or Operation number for X: RAN Parameter 1
　　　　--* Order: 1
　　-# Operation 2:
　　　　--* Operation type: "summation of X"
　　　　--* RAN Parameter number or value number or Operation number for X: RAN Parameter 2
　　　　--* Order: 2
　　-# Operation 3:
　　　　--* Operation type: "summation of X"
　　　　--* RAN Parameter number or value number or Operation number for X: RAN Parameter 3
　　　　--* Order: 3
　　-# Operation 4:
　　　　--* Operation type: "add X to Y"
　　　　--* RAN Parameter number or value number or Operation number for X: Operation 2
　　　　--* RAN Parameter number or value number or Operation number for Y: Operation 3
　　　　--* Order: 5
　　-# Operation 5: 　　
　　　　--* Operation type: "summation of X"
　　　　--* RAN Parameter number or value number or Operation number for X: RAN Parameter 4
　　　　--* Order: 4
　　-# Operation 6:
　　　　--* Operation type: "subtract Y from X"
　　　　--* RAN Parameter number or value number or Operation number for X: Operation 4
　　　　--* RAN Parameter number or value number or Operation number for Y: Operation 5
　　　　--* Order: 6
　　-# Comparison:
　　　　--* Comparison type: "X smaller than Y"
　　　　--* RAN Parameter number or value number or Operation number for X: Operation 1
　　　　--* RAN Parameter number or value number or Operation number for Y: Operation 6

　　In addition, to ease the writing,

is shortend to (simplified as)

in the following conditions.

　　(Condition 4)
　　Condition 4: Send an indication only if X-Y is greater than a threshold, while Y is a value obtained by summing the GBR summed with respect to DRBs before admission, and X is a value obtained by adding the GBR summed with respect to modified DRBs after admission to the GBR summed with respect to new DRBs after admission and subtracting the GBR summed with respect to removed DRBs. In other words, in this condition the increase of GBR is above a threshold, the indication is sent in order to control only requests with significant increase of GBR. Using the condition 4, when the UE Context Setup or UE Context Modification is received, if

then an event is triggered.

　　This condition is useful when it is required that the Near-RT RIC control only requests for GRB that would increase the total GBR above a given threshold. This is to control requests that would potentially lead to resource shortage.

　　(Condition 5)
　　Condition 5: Send an indication only if X-Y is greater than a threshold, while Y is a value obtained by summing the GBR summed with respect to DRBs before admission, and X is a value obtained by adding the GBR summed with respect to modified DRBs after admission to the GBR summed with respect to new DRBs after admission and subtracting the GBR summed with respect to removed DRBs, and the 5QI(s) are specific. In other words, the condition 5 is the condition 4 for the specific 5QI(s). Using the condition 5, when the UE Context Setup or UE Context Modification is received, if

then an event is triggered.

　　This condition is useful when it is required that the Near-RT RIC control only specific 5QIs, for instance 5QIs that might be prone to high resource usage (5QIs dedicated to video streaming for instance). For this condition, the Event Trigger Definition content would be as follows:
- Call Process Type ID: 1 for UE Context Management
- Call Breakpoint ID: 2 for UE Context Modification
- Condition:
　　-# Number of RAN Parameter: 1
　　-# Number of values: 1
　　-# Number of operations: 4
　　-# RAN Parameter 1:
　　　　--* Type: E2SM-RC
　　　　--* ID: 15011 (refers to "Guaranteed Flow Bit Rate Downlink" in "QoS Flow")
　　　　--* Parent structure: 25119 (refers to "List of DRBs for setup" in "UE Context Modification")
　　-# RAN Parameter 2:
　　　　--* Type: E2SM-RC
　　　　--* ID: 15011 (refers to "Guaranteed Flow Bit Rate Downlink" in "QoS Flow")
　　　　--* Parent structure: 25127 (refers to "List of DRBs to be modified" in "UE Context Modification")
　　-# RAN Parameter 3:
　　　　--* Type: E2SM-RC
　　　　--* ID: 15011 (refers to "Guaranteed Flow Bit Rate Downlink" in "QoS Flow")
　　　　--* Parent structure: 25136 (refers to "List of DRBs to be released" in "UE Context Modification")
　　-# RAN Parameter 4:
　　　　--* Type: E2SM-RC
　　　　--* ID: 15011 (refers to "Guaranteed Flow Bit Rate Downlink" in "QoS Flow")
　　　　--* Parent structure: 21524 (refers to "List of DRBs" in "UE Context Information")
　　-# Operation 1:
　　　　--* Operation type: "summation of X"
　　　　--* RAN Parameter number or value number or Operation number for X: RAN Parameter 1
　　　　--* Filter:
　　　　　　---+ RAN Parameter:
　　　　　　----> ID: 15001 (refers to "5QI"in "QoS Flow")
---+ Filter values: List of values of 5QI that it is required to include the corresponding GBR in the summation
　　　　--* Order: 1
　　-# Operation 2:
　　　　--* Operation type: "summation of X"
　　　　--* RAN Parameter number or value number or Operation number for X: RAN Parameter 2
　　　　--* Filter:
　　　　　　---+ RAN Parameter:
　　　　　　----> ID: 15001 (refers to "5QI"in "QoS Flow")
　　　　　　---+ Filter values: List of values of 5QI that it is required to include the corresponding GBR in the summation
　　　　--* Order: 2
　　-# Operation 3:
　　　　--* Operation type: "summation of X"
　　　　--* RAN Parameter number or value number or Operation number for X: RAN Parameter 3
　　　　--* Filter:
　　　　　　---+ RAN Parameter:
　　　　　　----> ID: 15001 (refers to "5QI"in "QoS Flow")
　　　　　　---+ Filter values: List of values of 5QI that it is required to include the corresponding GBR in the summation
　　　　--* Order: 3
　　-# Operation 4:
　　　　--* Operation type: "summation of X"
　　　　--* RAN Parameter number or value number or Operation number for X: RAN Parameter 4
　　　　--* Filter:
　　　　　　---+ RAN Parameter:
　　　　　　----> ID: 15001 (refers to "5QI"in "QoS Flow")
　　　　　　---+ Filter values: List of values of 5QI that it is required to include the corresponding GBR in the summation
　　　　--* Order: 4
　　-# Operation 5:
　　　　--* Operation type: "add X to Y"
　　　　--* RAN Parameter number or value number or Operation number for X: Operation 1
　　　　--* RAN Parameter number or value number or Operation number for Y: Operation 2
　　　　--* Order: 5
　　-# Operation 6:
　　　　--* Operation type: "subtract Y from X"
　　　　--* RAN Parameter number or value number or Operation number for X: Operation 5
　　　　--* RAN Parameter number or value number or Operation number for Y: Operation 3
　　　　--* Order: 6
　　-# Operation 7:
　　　　--* Operation type: "subtract Y from X"
　　　　--* RAN Parameter number or value number or Operation number for X: Operation 6
　　　　--* RAN Parameter number or value number or Operation number for Y: Operation 4
　　　　--* Order: 7
　　-# Value 1:
　　　　--* Value: threshold
　　-# Comparison:
　　　　--* Comparison type: "X greater than Y"
　　　　--* RAN Parameter number or value number or Operation number for X: Operation 7
　　　　--* RAN Parameter number or value number or Operation number for Y: Value 1

　　(Condition 6)
　　A Condition 6 is a set of the Conditions 1 and 4. Specifically, using the condition 6, when the UE Context Setup or UE Context Modification is received, if

and if

then an event is triggered.

　　This condition is useful when the mean resource usage for a given 5QI(s) is high, and when the incoming request may use up more than the unused resources.

　　(Condition 7)
　　A Condition 7 is a set of the Conditions 1 and 3. Specifically, using the condition 7, when the UE Context Setup or UE Context Modification is received, if

and if

then an event is triggered.

　　The Condition 7 allows control over any increase in GBR.

　　(Condition 8)
　　A Condition 8 is a set of the Conditions 1 and 6. Specifically, using the condition 8, when the UE Context Setup or UE Context Modification is received, if

and

then an event is triggered.

　　This condition is useful when it is required that the Near-RT RIC control only specific 5QIs, for instance 5QIs that might be prone to high resource usage (5QIs dedicated to video streaming for instance), when the ratio of unused resources is below a given threshold.

　　As mentioned, the idea in the disclosure is useful for other use cases introduced by O-RAN. One example of the cases is as follows:
- Traffic Steering: it is a use case where the Near-RT RIC gathers information of UE throughput and cell load (PRB usage), selects a UE to move from a congested cell to a less congested cell. The E2 node sends the information of all the UEs, and the Near-RT RIC selects one among them. It is possible to reduce the amount of traffic and processing by applying the following condition to prevent the E2 node from sending UE information that is not useful:
- Condition Traffic Steering: when the UE Context Setup or UE Context Modification is received, if

then an event is triggered.

　　In such case, the E2 node sends the UE information only if the GBR of a given 5QI is above a given threshold. It is here considered that the Traffic Steering algorithm is likely to select a UE with high GBR, and that UE with low GBR are not likely to be selected.

　　To be able to define the above conditions, the following change is suggested in the Clause 9.2.1.1.2, "E2SM-RC Event Trigger Definition Format 2: Call Process Breakpoint", in [2]:

　　　　The IEs in bold in table 9 are characteristic that enable the above conditions.

　　(Explanation of Label and Filter)
　　The above the Label and the Filter will be described further below.

　　(Label)
　　The Label above is strictly "Measurement Label". It is defined and used in O-RAN E2SM-KPM 8.3.11 Measurement Label (see below table 10). It is not used in E2SM-RC.

　　The underlined IEs define values of necessary subcounters applicable to an associated measurement type. The definition of "subcounter" will be described below.

　　A Measurement is information that is measured and saved in an E2 node. O-RAN supports all the measurements specified in [5]. The same Measurement can be configured to measure the information of only a specific group of elements. This is called a "subcounter". For instance, "5QI subcounter" of a Measurement is the per 5QI value of the measurement. In a cell, there may be multiple 5QIs being in use. The 5QI subcounter of a Measurement gathers the measured values for the same 5QIs. If there are 3 5QIs in the cell, the Measurement has 3 values, one per 5QI.

　　O-RAN defined "Measurement Label" is a parameter that specifies, among the items of the same subcounter, which specific items to use. In the traditional technique, for instance in the above example of 3 different 5QIs (for simplicity: 5QI 1, 5QI 2 and 5QI 3), if the Near-RT RIC only needs a Measurement for 5QIs 1 and 2, it will do as following:
- Include the definition of the Measurement in the "Measurement Information List" of the E2SM-KPM Action Definition that is being configured (for instance, E2SM-KPM Action Definition Format 1),
- Create an IE "Measurement Label" with "5QI" set to 1,
- Create an IE "Measurement Label" with "5QI" set to 2,
- Include those IEs into the IE "List of Labels" of the E2SM-KPM Action Definition that is being configured.
In this idea, those definitions are included into the E2SM-RC Subscription Request, which is not supported by the related art.

　　O-RAN E2SM-KPM 8.2.1.2.1, "E2SM-KPM Action Definition Format 1", is described in table 11, and an additional table is shown as table 12 below.

　　The underlined IEs in table 11 are characteristic that enable the above conditions.

　　(Filter)
　　A Filter is a parameter to specify what values of the RAN Parameter are to be included in a summation when multiple values of the RAN Parameter can be included. It can be applied to RAN Parameters. If there is no filter, then all of the existing values may be included.

　　For instance, in the condition 5 above, there are two summations. One of the summations is:

As shown in the condition 3 for the simplification, the summation is a simplified writing of

　　Let us focus on the first summation from above:

It means that the summation is on the GBR of the DRB to be added, and those DRBs must have a 5QI that belongs to a list of 5QIs.

　　The list of DRBs to be added is information held by the RAN Parameter ID 25119: "List of DRBs for setup" that is present in the Clause 8.1.2.1.2 (see below), and the list of QoS Flows to each of those DRBs is a linked list of QoS Flow (RAN Parameter 25167) that is defined in the Clause 8.1.1.6. According to the Clause 8.1.1.6 that defines a QoS flow, the QoS flow has a 5QI (RAN Parameter ID 15001) and a GBR, that is Guaranteed Flow Bit Rate Downlink (RAN Parameter ID 15011).

　　It means that within the "List of DRB for setup", there may be DRBs with different 5QI values. For instance, the "List of DRB for setup" can contain a DRB with 5QI 1, a DRB with 5QI 2 and a DRB with 5QI 3. Without defining a filter, a summation of the GBR includes the GBR of the DRB with 5QI 1, the GBR of the DRB with 5QI 2 and the GBR of the DRB with 5QI 3.

　　With a filter it is possible to set a list so that the GBR of a DRB is included in the summation only if the 5QI of the DRB is defined in the filter. With the idea, the filter is set as following:
- Set the RAN Parameter to which the filter should be applied. Here, 15001 that refers to 5QI.
- Set the list of values that the RAN Parameter should have to be accepted by the filter.

　　Here, the Clause 8.1.2.1.2, "UE Context Modification", of [2] is described below.

　　The underlined IEs in table 13 are characteristic that enable the filtering.

　　Further, the Clause 8.1.1.6, "QoS Flow", of [2] is described. The following RAN Parameters are associated with the NG-RAN QoS flow.

　　The underlined IEs in table 14 are characteristic that enable the filtering.

　　<Description of Effects>
　　As shown above, the disclosure of the second example embodiment can avoid the creation, transmission, and process of an unnecessary Indication message in an O-RAN system. Specifically, as the disclosure can widen the area of conditions indicated in the RIC Subscription Request, it is possible to reduce the number of control traffic. This induces lower latency, because the event trigger shown in [2] is not triggered anymore when it should not be triggered.

　　It should be noted that the RAN parameters shown in the conditions above are examples only and the conditions can be applied to RAN parameters other than the ones already shown.

　　Further, the person skilled in art would easily understand that the conditions above can be described as the upper or middle concepts listed in Supplementary Notes below.

　　　　<Hardware Configuration>
　　Next, a hardware configuration example of the RIC and the E2 node according to the plurality of embodiments described above will be described.

　　Fig. 8 is a block diagram showing a configuration example of a RIC. In the example of Fig. 8, the RIC 1100 is implemented as a computer system. The computer system includes one or more processors 1110, a memory 1120, and a mass storage 1130, which communicate with each other via bus 1170. One or more of the processors 1110 may include, for example, a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), or both. The computer system may include one or more output devices 1140, one or more input devices 1150, and a network interface 1160. The network interface 1160 is used, for example, to communicate with a network element (an E2 node or the like). The network interface 1160 may include, for example, a Network Interface Card (NIC) conforming to the IEEE (Institute of Electrical and Electronics Engineers) 802.3 series. The network interface 1160 may be one or more transceivers.

　　One or both of the memory 1120 and the mass storage 1130 may include a computer readable medium containing one or more instruction sets. These instructions may be partially or completely located in memory within one or more of the processors 1110. These instructions, when executed in one or more of the processors 1110, cause one or more of the processors 1110 to provide the functions of the RIC 1100 or the platform functions of the RIC 1100 described in the embodiments described above.

　　Fig. 9 illustrates an example configuration of an E2 node 1200. Referring to Fig. 9, the E2 node 1200 includes a network interface 1201, a processor 1202, and a memory 1203.

　　The network interface 1201 is used, for example, to communicate with a network element (the RIC 1100, other RAN nodes or the like). The network interface 1201 may include, for example, a NIC conforming to the IEEE 802.3 series. The network interface 1201 may be one or more transceivers.

　　The processor 1202 may be, for example, a microprocessor, a Micro Processing Unit (MPU), or a CPU. The processor 1202 may include a plurality of processors.

　　The memory 1203 include a volatile memory and a non-volatile memory. The memory 1203 may include a plurality of physically independent memory devices. The volatile memory may be, for example, a Static Random Access Memory (SRAM) or a Dynamic RAM (DRAM) or a combination thereof. The nonvolatile memory may be a Mask Read Only Memory (MROM), an Electrically Erasable Programmable ROM (EEPROM), a flash memory, or a hard disk drive, or any combination thereof. The memory 1203 may include a storage located away from the processor 1202. In this case, the processor 1202 may access the memory 1203 via the network interface 1201 or an I/O interface.

　　The memory 1203 may store one or more software modules (computer programs) 1204 including instructions and data for performing processing by the E2 node 1200 described in the embodiments described above. In some implementations, the processor 1202 may be configured to perform processing of the E2 node 1200 described in the embodiments described above by reading and executing the software module 1204 from the memory 1203.

　　The whole or part of the example embodiments disclosed above can be described as, but not limited to, the following supplementary notes.
　　(Supplementary Note 1)
　　A RIC (Radio Access Network Intelligent Controller) node comprising:
　　at least one memory configured to store an instruction;
　　at least one processor configured to execute the instruction; and
　　at least one transceiver, wherein
　　the processor, by executing the instruction,
　　　　sends a first message to an E2 node using the transceiver, the first message including one or more IEs (Information Elements) indicating that the E2 node sends a second message to the RIC node if the following condition is met:
　　　　　　an operation result satisfies a predetermined condition, while the operation result includes an operation result for at least a first element related to one or more first RAN parameters and a second element related to one or more second RAN parameters.
　　(Supplementary Note 2)
　　The RIC node according to Supplementary Note 1, wherein
　　the first element related to the plurality of first RAN parameters and the second element related to the plurality of second RAN parameters.
　　(Supplementary Note 3)
　　The RIC node according to Supplementary Note 1 or 2, wherein
　　at least one parameter of the one or more first RAN parameters differs from any one of the second RAN parameters.
　　(Supplementary Note 4)
　　The RIC node according to Supplementary Note 3, wherein
　　a first parameter of the one or more first RAN parameters is a parameter indicating the same physical quantity as a second parameter of the second RAN parameters and a different type of the same physical quantity than the second parameter.
　　(Supplementary Note 5)
　　The RIC node according to Supplementary Note 4, wherein
　　the first parameter and the second parameter are defined in the one or more IEs indicating, among different types of the same physical quantity, which specific type to use.
　　(Supplementary Note 6)
　　The RIC node according to any one of Supplementary Notes 1 to 5, wherein
　　the operation result includes at least:
　　　　either a result of applying an arithmetic operator at least between the first element and the second element, or
　　　　a result of applying a comparison operator at least between the first element and the second element.
　　(Supplementary Note 7)
　　The RIC node according to Supplementary Note 6, wherein
　　the operation result includes at least:
　　　　a result of applying a comparison operator at least between a first predetermined threshold and a result of applying an arithmetic operator at least between the first element and the second element.
　　(Supplementary Note 8)
　　The RIC node according to Supplementary Note 6, wherein
　　the operation result includes at least:
　　　　either a result of applying one or more arithmetic operators at least between the first element, the second element and a third element, or
　　　　a result of applying one or more comparison operators at least between the first element, the second element and the third element,
　　　　while the third element is related to one or more third RAN parameters.
　　(Supplementary Note 9)
　　The RIC node according to Supplementary Note 8, wherein
　　the operation result includes at least:
　　　　a result of applying a first comparison operator at least between a first predetermined threshold and a result of applying a first arithmetic operator at least between the first element and the second element; and
　　　　a result of applying a second comparison operator at least between the third element and a fourth element;
　　　　while the fourth element is related to one or more fourth RAN parameters.
　　(Supplementary Note 10)
　　The RIC node according to Supplementary Note 8, wherein
　　the operation result includes at least:
　　　　a result of applying a first comparison operator at least between a first predetermined threshold and a result of applying a first arithmetic operator at least between the first element and the second element; and
　　　　a result of applying a second comparison operator at least between a second predetermined threshold and a result of applying a second arithmetic operator at least between the third element and a fourth element;
　　　　while the fourth element is related to one or more fourth RAN parameters.
　　(Supplementary Note 11)
　　An E2 node comprising:
　　at least one memory configured to store an instruction;
　　at least one processor configured to execute the instruction; and
　　at least one transceiver, wherein
　　the processor, by executing the instruction,
　　　　receives a first message from the RIC node using the transceiver; and
　　　　sends a second message to the RIC node using the transceiver when the following condition indicated in one or more IEs (Information Elements) of the first message is met:
　　　　　　an operation result satisfies a predetermined condition, while the operation result includes an operation result for at least a first element related to one or more first RAN parameters and a second element related to one or more second RAN parameters.
　　(Supplementary Note 12)
　　A method performed by a RIC node comprising:
　　sending a first message to an E2 node using a transceiver, the first message including one or more IEs (Information Elements) indicating that the E2 node sends a second message to the RIC node if the following condition is met:
　　　　an operation result satisfies a predetermined condition, while the operation result includes an operation result for at least a first element related to one or more first RAN parameters and a second element related to one or more second RAN parameters, and
　　receiving the second message from the E2 node using the transceiver.
　　(Supplementary Note 13)
　　A method performed by an E2 node comprising:
　　receiving a first message from a RIC node using a transceiver; and
　　sending a second message to the RIC node using the transceiver when the following condition indicated in one or more IEs (Information Elements) of the first message is met:
　　　　an operation result satisfies a predetermined condition, while the operation result includes an operation result for at least a first element related to one or more first RAN parameters and a second element related to one or more second RAN parameters.
　　(Supplementary Note 14)
　　A program for causing a RIC node to execute:
　　sending a first message to an E2 node using a transceiver, the first message including one or more IEs (Information Elements) indicating that the E2 node sends a second message to the RIC node if the following condition is met:
　　　　an operation result satisfies a predetermined condition, while the operation result includes an operation result for at least a first element related to one or more first RAN parameters and a second element related to one or more second RAN parameters, and
　　receiving the second message from the E2 node using the transceiver.
　　(Supplementary Note 15)
　　A program for causing an E2 node to execute:
　　receiving a first message from a RIC node using a transceiver; and
　　sending a second message to the RIC node using the transceiver when the following condition indicated in one or more IEs (Information Elements) of the first message is met:
　　　　an operation result satisfies a predetermined condition, while the operation result includes an operation result for at least a first element related to one or more first RAN parameters and a second element related to one or more second RAN parameters.

　　Some or all of elements (e.g., structures and functions) specified in Supplementary Notes 2 to 10 dependent on Supplementary Note 1 may also be dependent on Supplementary Note 11 in dependency similar to that of Supplementary Notes 2 to 10 on Supplementary Note 1. Similarly, some or all of elements specified in Supplementary Notes 2 to 10 dependent on Supplementary Note 1 may also be dependent on Supplementary Notes 12 to 15 in dependency similar to that of Supplementary Notes 2 to 10 on Supplementary Note 1. Some or all of elements specified in any of Supplementary Notes may be applied to various types of hardware, software, and recording means for recording software, systems, and methods.

　　While each example embodiment of the present disclosure has been described, it is to be noted that it is possible to modify or adjust the example embodiments or examples within the whole disclosure of the present disclosure (including the Claims) and based on the basic technical concept thereof. Further, it is possible to variously combine or select (or at least partially remove) a wide variety of the disclosed elements (including the individual elements of the individual claims, the individual elements of the individual example embodiments or examples, and the individual elements of the individual figures) within the scope of the whole disclosure of the present disclosure. That is, it is self-explanatory that the present disclosure includes any types of variations and modifications to be done by a skilled person according to the whole disclosure including the Claims and the technical concept of the present disclosure. Particularly, any numerical ranges disclosed herein should be interpreted that any intermediate values or subranges falling within the disclosed ranges are also concretely disclosed even without specific recital thereof. Each example embodiment can be appropriately combined with at least one of example embodiments.

S01　　O-RAN SYSTEM
110　　NON-RT RIC
120　　NEAR-RT RIC
130　　EMS
140　　O-DU
150　　RU
160　　O-CU
12　　RIC
14　　E2 NODE

Claims (15)

1. 　　A RIC (Radio Access Network Intelligent Controller) node comprising:
   　　at least one memory configured to store an instruction;
   　　at least one processor configured to execute the instruction; and
   　　at least one transceiver, wherein
   　　the processor, by executing the instruction,
   　　　　sends a first message to an E2 node using the transceiver, the first message including one or more IEs (Information Elements) indicating that the E2 node sends a second message to the RIC node if the following condition is met:
   　　　　　　an operation result satisfies a predetermined condition, while the operation result includes an operation result for at least a first element related to one or more first RAN parameters and a second element related to one or more second RAN parameters.
   
2. 　　The RIC node according to claim 1, wherein
   　　the first element related to the plurality of first RAN parameters and the second element related to the plurality of second RAN parameters.
   
3. 　　The RIC node according to claim 1 or 2, wherein
   　　at least one parameter of the one or more first RAN parameters differs from any one of the second RAN parameters.
   
4. 　　The RIC node according to claim 3, wherein
   　　a first parameter of the one or more first RAN parameters is a parameter indicating the same physical quantity as a second parameter of the second RAN parameters and a different type of the same physical quantity than the second parameter.
   
5. 　　The RIC node according to claim 4, wherein
   　　the first parameter and the second parameter are defined in the one or more IEs indicating, among different types of the same physical quantity, which specific type to use.
   
6. 　　The RIC node according to any one of claims 1 to 5, wherein
   　　the operation result includes at least:
   　　　　either a result of applying an arithmetic operator at least between the first element and the second element, or
   　　　　a result of applying a comparison operator at least between the first element and the second element.
   
7. 　　The RIC node according to claim 6, wherein
   　　the operation result includes at least:
   　　　　a result of applying a comparison operator at least between a first predetermined threshold and a result of applying an arithmetic operator at least between the first element and the second element.
   
8. 　　The RIC node according to claim 6, wherein
   　　the operation result includes at least:
   　　　　either a result of applying one or more arithmetic operators at least between the first element, the second element and a third element, or
   　　　　a result of applying one or more comparison operators at least between the first element, the second element and the third element,
   　　　　while the third element is related to one or more third RAN parameters.
   
9. 　　The RIC node according to claim 8, wherein
   　　the operation result includes at least:
   　　　　a result of applying a first comparison operator at least between a first predetermined threshold and a result of applying a first arithmetic operator at least between the first element and the second element; and
   　　　　a result of applying a second comparison operator at least between the third element and a fourth element;
   　　　　while the fourth element is related to one or more fourth RAN parameters.
   
10. 　　The RIC node according to claim 8, wherein
    　　the operation result includes at least:
    　　　　a result of applying a first comparison operator at least between a first predetermined threshold and a result of applying a first arithmetic operator at least between the first element and the second element; and
    　　　　a result of applying a second comparison operator at least between a second predetermined threshold and a result of applying a second arithmetic operator at least between the third element and a fourth element;
    　　　　while the fourth element is related to one or more fourth RAN parameters.
    
11. 　　An E2 node comprising:
    　　at least one memory configured to store an instruction;
    　　at least one processor configured to execute the instruction; and
    　　at least one transceiver, wherein
    　　the processor, by executing the instruction,
    　　　　receives a first message from the RIC node using the transceiver; and
    　　　　sends a second message to the RIC node using the transceiver when the following condition indicated in one or more IEs (Information Elements) of the first message is met:
    　　　　　　an operation result satisfies a predetermined condition, while the operation result includes an operation result for at least a first element related to one or more first RAN parameters and a second element related to one or more second RAN parameters.
    
12. 　　A method performed by a RIC node comprising:
    　　sending a first message to an E2 node using a transceiver, the first message including one or more IEs (Information Elements) indicating that the E2 node sends a second message to the RIC node if the following condition is met:
    　　　　an operation result satisfies a predetermined condition, while the operation result includes an operation result for at least a first element related to one or more first RAN parameters and a second element related to one or more second RAN parameters, and
    　　receiving the second message from the E2 node using the transceiver.
    
13. 　　A method performed by an E2 node comprising:
    　　receiving a first message from a RIC node using a transceiver; and
    　　sending a second message to the RIC node using the transceiver when the following condition indicated in one or more IEs (Information Elements) of the first message is met:
    　　　　an operation result satisfies a predetermined condition, while the operation result includes an operation result for at least a first element related to one or more first RAN parameters and a second element related to one or more second RAN parameters.
    
14. 　　A program for causing a RIC node to execute:
    　　sending a first message to an E2 node using a transceiver, the first message including one or more IEs (Information Elements) indicating that the E2 node sends a second message to the RIC node if the following condition is met:
    　　　　an operation result satisfies a predetermined condition, while the operation result includes an operation result for at least a first element related to one or more first RAN parameters and a second element related to one or more second RAN parameters, and
    　　receiving the second message from the E2 node using the transceiver.
    
15. 　　A program for causing an E2 node to execute:
    　　receiving a first message from a RIC node using a transceiver; and
    　　sending a second message to the RIC node using the transceiver when the following condition indicated in one or more IEs (Information Elements) of the first message is met:
    　　　　an operation result satisfies a predetermined condition, while the operation result includes an operation result for at least a first element related to one or more first RAN parameters and a second element related to one or more second RAN parameters.