Extended application architecture of near real-time RIC of open ran
The O-RAN architecture's modular structure allows for easy implementation of network security policies through a rule chain format, addressing vendor-specific limitations and enhancing the flexibility of security patch deployment in mobile networks.
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- KOREA ADVANCED INST OF SCI & TECH
- Filing Date
- 2025-12-14
- Publication Date
- 2026-07-09
Smart Images

Figure KR2025021629_09072026_PF_FP_ABST
Abstract
Description
Extended application architecture of near-real-time RICs in Open RAN
[0001] The present invention relates to the structure of an extension application performed in an NRT RIC of an open RAN and a method for implementing said extension application.
[0002]
[0003] The Radio Access Network (RAN) of a mobile communication network can provide wireless connectivity for the provision of wireless data services between the network and wireless users. The RAN oversees the establishment and maintenance of wireless links, wireless hardware resource management, and session control. Traditionally, radio access networks have consisted of hardware deployed globally by a small number of large vendors. While most hardware functions have transitioned to a software-centric approach over time, single-architecture hardware radio access networks persisted into 5G systems due to vendor lock-in.
[0004] As a result, it was not easy to apply new network features and security patches to the wireless access network.
[0005] To address this issue, the Open RAN Alliance, an international coalition of mobile network operators, proposed the Open RAN (O-RAN) architecture. The O-RAN architecture applies Software Defined Networking (SDN) principles to the Radio Access Network (RAN), decomposing it into multiple control and user plane modules that are connected via open interfaces. Consequently, it has become possible to implement a single radio access network by connecting modules developed by various vendors, whereas current mobile access networks are supplied by only a few companies. Furthermore, since current mobile access networks consist of vendor-specific software and hardware systems, network operators face limitations in applying customized network security policies; therefore, there is a growing need to resolve this issue by leveraging the flexibility of the O-RAN architecture.
[0006]
[0007] Current mobile communication networks' wireless access networks consist of vendor-specific software and hardware systems, which limits network operators' ability to apply customized network security policies.
[0008] Accordingly, embodiments of the present invention present a network security policy control extension application structure that provides a simplified configuration by utilizing the flexibility of network control provided by the O-RAN structure and defining the basic packet processing architecture of the data plane as abstracted rule chains.
[0009] In addition, a method for implementing an extended application based on the extended application structure presented in the present invention is proposed.
[0010]
[0011] A method for a Radio Intelligent Controller (RIC) to execute an extended application (xApp) in an Open Radio Access Network (O-RAN) according to an embodiment of the present invention includes an operation of sequentially executing the extended application, which is composed of a rule chain in which a plurality of rules are connected in a chain format, starting from the first rule of the rule chain. The rule may include a rule identifier that can be distinguished from other rules, an event block that defines a condition for starting the execution of the rule, an action block that defines a function that the rule must execute, and an output block that defines an output that the rule must output after execution.
[0012]
[0013] The packet processing structure according to the embodiments of the present invention enables the easy implementation of extension applications residing in the near-real-time RIC of the O-RAN structure. Accordingly, by easily modifying and deploying security policy-related extension applications in response to newly discovered security vulnerabilities, mobile network operators can apply rapid mitigation strategies for security vulnerabilities.
[0014]
[0015] FIG. 1 is a diagram illustrating an open-radio access network (O-RAN) structure according to one embodiment.
[0016] Figure 2 is a diagram illustrating the format of rules for implementing an extension application (xAPP).
[0017] Figure 3 is a diagram illustrating an example of implementing complex functions by chaining rules.
[0018] Figure 4 illustrates an example of a network security policy expressed as a rule chain that periodically sends a "GUTI reallocation command" to a UE and updates the newly assigned GUTI in the internal database according to the method presented in this document.
[0019]
[0020] The advantages and features of the present disclosure and the methods for achieving them will become clear by referring to the embodiments described below in detail together with the accompanying drawings. However, the present disclosure is not limited to the embodiments disclosed below but may be implemented in various different forms. These embodiments are provided merely to ensure that the disclosure of the present disclosure is complete and to fully inform those skilled in the art of the scope of the disclosure, and the present disclosure is defined only by the scope of the claims. Throughout the specification, like reference numerals refer to like components.
[0021] When one component is referred to as being "connected to" or "coupled to" another component, it includes cases where it is directly connected or coupled to the other component, or cases where another component is interposed. Conversely, when one component is referred to as being "directly connected to" or "directly coupled to" another component, it indicates that no other component is interposed. "And / or" includes each of the mentioned items and all combinations of one or more of them.
[0022] The terms used herein are for describing embodiments and are not intended to limit the disclosure. In this specification, the singular form includes the plural form unless specifically stated otherwise in the text. As used herein, "comprises" and / or "comprising" do not exclude the presence or addition of one or more other components, steps, actions, and / or elements to the mentioned components, steps, actions, and / or elements.
[0023] Although terms such as "first," "second," etc., are used to describe various components, it goes without saying that these components are not limited by these terms. These terms are used merely to distinguish one component from another.
[0024] FIG. 1 is a diagram illustrating an open-radio access network (O-RAN) structure according to one embodiment.
[0025] Referring to FIG. 1, the O-RAN structure may include a Non-Real-Time RAN Intelligent Controller (110), a Near-Real-Time RAN Intelligent Controller (120), a Control Plane Central Unit (CU-C) (130), a User Plane Central Unit (CU-U) (140), a Distribution Unit (DU) (150), and a Radio Unit (RU) (160).
[0026] The O-RAN architecture was proposed to create an open and interoperable equipment supply chain ecosystem by supporting 3GPP and other standards based on standardized interfaces.
[0027] In the O-RAN structure, the controller for the wireless access network is defined as a RAN Intelligent Controller (RIC), and the RIC can be divided into a non-real-time RIC (> 1 second) (110) and a near-real-time RIC (0.01 seconds to 1 second) (120) based on control latency. The non-real-time RIC (110) can perform AI-based management through big data analysis and machine learning, such as RAN policy management, network traffic patterns, terminal mobility patterns, service types, and Quality of Service (QoS) prediction patterns, and software modules defined as rAPP (RAN Application) modules can execute each function.
[0028] The near-real-time RIC (120) can provide near-real-time wireless resource management functions. It can handle functions such as terminal-level load balancing, resource block management, as well as quality of service, terminal mobility management, and security policy management. Each function performed by the near-real-time RIC (120) can be implemented by a software module defined as an extended application (xAPP) module.
[0029] The near-real-time RIC (120) can transmit control commands (handover, resource allocation, etc.) to the central unit (CU) (130, 140) and the distributed unit (150) through the E2 interface, and collect measured data and provide it to the non-real-time RIC (110).
[0030] The central unit (CU) can be separated into a control plane central unit (CU-C) (130) that transmits control information and a user plane central unit (CU-U) that transmits traffic, and can execute control commands received from a near-real-time RIC (120). The central unit can manage packet data conversion protocol (PDCP), service data adaptation protocol (SDAP), and radio resource control (RRC) protocol entities.
[0031] The distributed unit (DU) (150) can handle real-time Layer 2 functions and upper physical layer tasks for Radio Link Control and Medium Access Control, and the radio unit (RU) (160) can perform Radio Signal Processing and lower physical layer functions. The distributed unit (DU) (150) and the radio unit (RU) (160) can be connected via an Open Fronthaul Interface.
[0032] In the O-RAN structure illustrated in FIG. 1, the near-real-time RIC (120) can be viewed as a module that controls or manages the network in near real-time, that is, in 10ms to 1 second intervals, and, according to one embodiment, can perform a security policy management function that performs security checks on data. The security policy management function is likely to change whenever a new security issue arises. Therefore, the extension application (xAPP) that performs the security policy management function must be freely modified and added, and the network function must be flexibly reconfigured if necessary.
[0033] To enable such free modification, extension applications (xAPPs) need to be programmed in a way that is as simple and easy as possible. This document proposes an xAPP structure that allows for simple and easy programming.
[0034] FIG. 2 is a diagram illustrating the format of rules for implementing an extension application (xAPP), and FIG. 3 is a diagram illustrating an example of implementing complex functions by chaining rules.
[0035] Referring to FIG. 2, a rule (200) capable of performing a specific function can be programmed to implement an extension application (xAPP). The format for programming the rule can be as shown in FIG. 2. A function of the extension application (xAPP) can be completed with only one rule, but according to another embodiment, it can be completed by performing multiple rules in sequence.
[0036] A rule module (200) may have an identifier (210) set to distinguish between multiple different rules. Referring to FIG. 2, a module representing each rule may start with "Rule x", where x is an identifier (210) to distinguish the rule from other rules. In one embodiment, the identifier (210) may use only numbers, but is not limited thereto and may use a combination of English letters, Korean letters, and numbers.
[0037] The rule module (200) may be composed of an event block (220), an action block (230), and an output block (240). According to one embodiment, the program may be expressed in JSON format, but is not limited thereto.
[0038] The event block (220) describes the trigger conditions under which the rule module (200) can be started and indicates the type of input data provided to the rule module (200).
[0039] The event block (220) may have a type (222) parameter that defines a trigger condition and an input (224) parameter that defines an input data type. Here, the type (222) that defines the trigger condition is a mandatory parameter that must be provided, and the input (224) that defines the input data type is an optional parameter that may or may not be provided.
[0040] According to one embodiment, type (222) can set a trigger condition for a timer, counter, packet_type_match, or chain.
[0041] A timer can be an event that triggers at a preset time. For example, if you want to perform a specific task at a preset interval, you can set the timer to 1000, decrease the timer by 1 at every operation clock, and trigger the execution of the corresponding rule when the timer becomes 0. Then, you can set the timer back to 1000 to check for the next interval.
[0042] A counter can be an event that triggers when the counter reaches a specific value. For example, if you want to trigger whenever the number of received packets reaches 10, you can reset the counter to 0 after the event occurs, increment the counter by 1 whenever a packet is received, and trigger the rule when the counter reaches 10.
[0043] Packet_type_match is an event that causes a trigger to occur when a received packet or a packet to be transmitted is identical to a preset packet type.
[0044] A chain can be an event that can be used in a situation where multiple rules are linked together, and the corresponding rule must be executed when the rule immediately preceding it is completed.
[0045] According to one embodiment, when multiple rules are connected to complete a single function, the first rule among the connected multiple rules can be triggered by "timer," "counter," or "packet_type_match," and the second onwards can be triggered by "chain."
[0046] The "input"224) parameter of the event block (220) can represent the type of input data provided to the rule block.
[0047] According to one embodiment, input (224) may select one of the input data types of "flow_id" and "payload_type". Here, "flow_id" indicates an identifier of a flow set in a mobile communication network, and "payload_type" indicates a type of payload carried in each packet.
[0048] The action block (230) can define an action to be performed when triggered according to the trigger format set in the event block (220) of the rule module (200).
[0049] The action block (230) may be a single if-else block composed of a condition (232), a true condition branch (if-action) (234) that describes an action to be performed when the condition is satisfied, and a false condition branch (else-action) (236) that describes an action to be performed when the condition is not satisfied. The action block (230) may define only one action using only a single if-else, rather than defining a complex action by chaining multiple if-else statements together.
[0050] The conditional statement (232) may have a left operand, an operator, and a right operand parameter. The left operand and the right operand parameter are optional, and the operator may be a required clause.
[0051] The operators may include gt (greater than), ge (greater than or equal to), lt (less than), le (less than or equal to), eq (equal to), neq (different from), true (always true), and in (inclusive), but are not limited to these and may include other operators not defined herein.
[0052] In one embodiment, to implement a condition that is always true, the conditional statement (232) can be described as follows.
[0053] ------------------------
[0054] condition: {op: true}
[0055] ------------------------
[0056] In another embodiment, to implement the condition that A is greater than B, the conditional statement (232) can be described as follows.
[0057] ------------------------
[0058] condition: {
[0059] left: A
[0060] op: gt
[0061] right: B
[0062] }
[0063] ------------------------
[0064] The true condition branch (if-action) (234) of the action block (230) is a mandatory statement, so the true condition branch (if-action) (234) must be written in the action block (230). The false condition branch (Else-action) (236) is an optional statement, so the false condition branch (Else-action) (236) may or may not be written in the action block (230). Therefore, if the condition statement (232) is false, no action may be performed.
[0065] According to one embodiment, the true condition branch (if-action) (234) or false condition branch (Else-action) (236) may be a pre-coded or pre-defined execution function. For example, a pre-coded or pre-defined function, such as packet_gen, which is a function that generates packets, or table_update, which performs a table update, may be written in the true condition branch (if-action) (234) or false condition branch (Else-action) (236).
[0066] The output block (240) may have a value (242) parameter that defines the type of data output from the rule block and a Next_ID (244) parameter that defines the identifier of the next step rule in the rule chain. Here, the Next_ID (244) parameter is a required parameter, and the value (242) parameter may be an optional parameter. That is, the output block (240) must include Next_ID (244), and may or may not include value (242).
[0067] The output value, which is output in the output data format defined by the "value" (242) parameter of the output block (240), can be used as an input for the next rule block of the rule chain or to represent the final result of the rule chain.
[0068] The "Next ID" (244) parameter of the output block (240) indicates the identifier of the next step rule, but if a pre-set special identifier value (e.g., -1) is specified, it may indicate the end of the rule chain. Thus, it may be possible to set up a chain of rule blocks and implement complex functions by using the "Next ID" (244) parameter of the output block (240).
[0069] According to one embodiment, with reference to FIG. 3, it may be possible to configure a chain of rules starting from Rule 1, with Rule 3 and Rule 7 executed sequentially to terminate. For example, the Type parameter of the event block of Rule 1 may be set to "Timer" so that Rule 1 is set at a regular interval, and when the execution of Rule 1 is finished, Rule 3 may be executed according to the rule number set in the Next_ID of the output block. The Type parameter of the event block of Rule 3 may be set to "Chain" to define that the corresponding rule is executed when the execution of the rule located at the front of the corresponding rule in the rule chain is completed. Additionally, the Next_ID of the output block of Rule 3 may be set to 7 so that Rule 7 can be executed after Rule 3 is completed. The Next_ID of the output block of Rule 7 may be set to a specific value (e.g., -1) indicating the termination of the rule chain to indicate that the rule chain has ended.
[0070] Figure 4 illustrates an example of a network security policy expressed as a rule chain that periodically sends a "GUTI reallocation command" to a UE and updates the newly assigned GUTI in the internal database according to the method presented in this document.
[0071] Referring to FIG. 4, the Type parameter of the event block of Rule 1 (410) can be set to Timer to define that it is executed periodically. The Input parameter can be set to flow_id to specify the UE that needs to be reassigned GUTI.
[0072] The condition of the action block of rule 1 (410) can always be set to true so that the function defined in the true condition branch (if-action) is executed. According to one embodiment, the function defined in the true condition branch (if-action) may have a "func" parameter defining the function name and an "input" parameter defining the parameter used as input to the function, as shown in FIG. 4, but is not limited thereto. By rule 1 (410), the packet_gen function may be executed to generate a packet and deliver it to the UE corresponding to the flow_id. The packet generated at this time may be a packet for reassigning GUTI.
[0073] The Next_ID parameter of the output block of rule 1 (410) can be set to 2 so that rule 2 can be executed. The Value parameter of the output block can be passed to rule 2 (420) by writing the flow_id value corresponding to the UE to which GUTI was reassigned.
[0074] Rule 2 (420) can be executed after the execution of the previous rule in the rule chain is completed by setting the Type parameter of the event block to "chain".
[0075] The condition of the action block of rule 2 (420) can be set to always be true so that the function defined in the true condition branch (if-action) is executed. According to one embodiment, the function defined in the true condition branch (if-action) may be table_update, and the inputs of the function may be entry_id and the value output as the "value" parameter from the previous rule module. According to rule 2 (420), the table_update function, which has entry_id and flow_id as inputs, can update the GUTI for the UE corresponding to flow_id.
[0076] The Next_ID parameter of the output block of rule 2 (420) can be set to -1, a specific value that terminates the rule chain, so that the rule chain can be terminated.
[0077] By programming the rule chain of rule 1 (410) and rule 2 (420), a network security policy can be executed to periodically send a “GUTI reallocation command” to the UE and update the newly assigned GUTI in the internal database.
[0078] An extended application for performing specific functions can be defined by each rule and rule chain programmed according to the rule forms shown in FIGS. 2 and 3, and a Radio Intelligent Controller (RIC) in an Open Radio Access Network (O-RAN), more specifically a near-real-time Radio Intelligent Controller, can execute an extended application (xApp) composed of a rule chain in which a plurality of rules are connected in a chain format.
[0079] To summarize, a method for a Radio Intelligent Controller (RIC) in an Open Radio Access Network (O-RAN) to execute an extended application (xApp) may include the operation of sequentially executing the extended application, which is composed of a rule chain in which multiple rules are connected in a chain format, starting from the first rule of the rule chain. In this case, the rule may include a rule identifier that distinguishes it from other rules, an event block that defines conditions for starting the execution of the rule, an action block that defines a function to be executed by the rule, and an output block that defines an output to be produced after the rule is executed.
[0080] The above event block (220) includes a first parameter (Type; 222) that defines the type of condition for starting the execution of a rule and a second parameter (Input; 224) that defines the format of data input to the rule, and the method may further include an operation to start the execution of the first rule based on the first parameter of the first rule.
[0081] Additionally, the first parameter may include one of a timer that causes the execution of the rule to start periodically, a counter that causes the execution of the rule to start when a counter reaches a specific value, a packet type match that causes the execution of the rule to start when the type of packet being processed matches a preset type, and a chain that causes the execution of the rule to start when the immediately preceding rule in the rule chain is completed.
[0082] Additionally, the first parameter of the rule at the very front of the rule chain is set to any one of the timer, the counter, or the packet type match, and the first parameter of the remaining rules, excluding the rule at the very front of the rule chain, can be set to the chain.
[0083] The above action block (230) includes a condition (Condition; 232) for selecting one of up to two execution functions and a true condition branch function (a function defined in If-action (234)) to be executed when the condition is true, and the method may further include an operation to determine whether the condition of the first rule is true and an operation to execute the true condition branch function of the first rule when the condition of the first rule is true.
[0084] The above action block (230) further includes a false condition branch function (a function defined in Else-action (236)) that is to be executed when the above conditional statement is false, and the method may further include an action of executing the false condition branch function of the first rule when the above conditional statement of the first rule is false.
[0085] The output block (240) includes a next ID (next_id; 244) that specifies the rule identifier of the next rule connected in the rule chain, and the method may further include an operation to execute the next rule or terminate the extension application based on the next ID included in the first rule.
[0086] The above rule identifier includes a first value that is pre-set to indicate the termination of an extension application, and the operation of executing a next rule or terminating the extension application based on the next ID included in the first rule may include the operation of terminating the extension application when the next ID of the first rule is the first value, and the operation of starting the execution of a second rule having the second value as a rule identifier when the next ID of the first rule is a second value different from the first value.
[0087] Additionally, the output block further includes a value parameter that defines the type of data output from the rule block, and the method may further include an operation of outputting an output value as the input to the second rule or as the final result of the rule chain with the data type defined by the value parameter.
[0088]
[0089] Although the main features of the present invention have been described above, those skilled in the art may modify and change the present invention in various ways by adding, changing, deleting, or adding components, etc., without departing from the spirit of the invention as described in the claims, and such modifications and changes shall also be deemed to be included within the scope of the rights of the present invention.
Claims
1. A method for a Radio Intelligent Controller (RIC) to execute an extended application (xApp) in an Open Radio Access Network (O-RAN), The above method includes the operation of sequentially executing the extension application, which is composed of a rule chain in which a plurality of rules are connected in a chain format, starting from the first rule of the rule chain. The above rule is, A rule identifier that allows it to be distinguished from other rules; An event block that defines the conditions to start the execution of the rule; An action block defining a function that the rule must execute; and including an output block that defines the output that the rule must output after execution, How to run an extension application.
2. In Paragraph 1, The above event block is, A first parameter defining the type of condition for initiating the execution of a rule; and It includes a second parameter that defines the format of the data input into the rule, and The above method further includes the operation of starting the execution of the first rule based on the first parameter of the first rule, How to run an extension application.
3. In Paragraph 2, The above first parameter is, A timer that periodically starts the execution of the above rule; A counter that causes the execution of the above rule to start when the counter reaches a specific value; Packet_type_match that causes the execution of the above rule to start if the type of the packet being processed matches a preset type; and including one of the chains that causes the execution of the above rule to begin when the immediately preceding rule in the rule chain is completed, How to run an extension application.
4. In Paragraph 3, The first parameter of the rule at the very front of the above rule chain is set to any one of the above timer, the above counter, or the above packet type match, and The first parameter of the remaining rules, excluding the first rule of the above rule chain, is set in the above chain, How to run an extension application.
5. In Paragraph 2, The above action block is, A conditional statement for selecting one of up to two execution functions; and Includes a true conditional branch function that must be executed when the above conditional statement is true, and The above method is, An operation to determine whether the conditional statement of the first rule is true; and A further operation including executing the true condition branch function of the first rule when the conditional statement of the first rule is true. How to run an extension application.
6. In Paragraph 5, The above action block is, It further includes a false condition branch function that must be executed when the above conditional statement is false, and The above method is, A further operation including executing the false condition branch function of the first rule when the conditional statement of the first rule is false, How to run an extension application.
7. In Paragraph 1, The above output block is, It includes a next_id that specifies the rule identifier of the next rule connected in the above rule chain, and The above method is, Further including the operation of executing the next rule or terminating the extension application based on the next ID included in the first rule above, How to run an extension application.
8. In Paragraph 7, The above rule identifier includes a first value pre-set to indicate the termination of the extension application, and The action of executing the next rule or terminating the extension application based on the next ID included in the first rule above is, An operation to terminate the extension application when the next ID of the first rule is the first value; and If the next ID of the first rule is a second value different from the first value, the operation of starting the execution of a second rule having the second value as a rule identifier, How to run an extension application.
9. In Paragraph 8, The above output block is, It further includes a value parameter that defines the type of data output from the rule block, and The above method is, Further including an operation of outputting an output value as a data type defined by the value parameter as the input of the second rule or as the final result of the rule chain, How to run an extension application.