Real-time e2 traffic monitoring and control for near-RT RIC platform

Abstract

A method (400) is disclosed. The method (400) includes receiving (402), from an xApp, a data packet at a near Real-Time Radio access network Intelligent Controller (near RT RIC) node. The method (400) also includes comparing (404), by the near RT RIC node, a set of predefined parameters associated with the data packet with a corresponding set of predefined values stored at the near-RT RIC node. The method (400) further includes validating (406), by the near RT RIC node, the data packet based on the comparison.

Description

REAL-TIME E2 TRAFFIC MONITORING AND CONTROL FOR NEAR-RT RICPLATFORMCROSS-REFERENCE TO RELATED APPLICATION (S)

[0001] This application claims priorities to IN provisional application 202411010355, filed on February 14, 2024 and IN non provisional application 202411010355, filed on July 18, 2024 ; the entire contents of which are incorporated herein by reference.FIELD

[0002] The present disclosure relates to a Real-Time (RT) E2 traffic monitoring and control for near-RT Radio Access Network (RAN) Intelligent Controller (RIC) platforms.BACKGROUND

[0003] A Radio Access Network (RAN) is an important component in a telecommunications system and includes multiple network entities or network components that facilitate connections with end-user devices (user equipment). In recent years, Open RAN (O-RAN) architecture has been developed that disaggregates functions of the RAN through various logical nodes such as a Centralized Unit (CU), a Distributed Unit (DU), and a Radio Unit (RU). The O-RAN also provides intelligent management via a RAN Intelligent Controller (RIC) that is configured to control and optimize RAN functions. In particular, the O-RAN architecture includes a near Real-Time RIC (near-RT RIC) and a Non-Real-Time RIC (non-RT RIC). The near-RT RIC is a logical node that enables near-RT control or optimization of RAN elements and resources via fine-grained data collection and actions over an E2 interface. The non-RTRIC is a logical node that enables the non-RT control and optimization of RAN elements and resources, capturing .Artificial Intelligence / Machine Learning (Al / ML) workflow, and policybased guidance of applications or features in the near-RT RIC.

[0004] Moreover, the O-RAN RIC architecture by the WG3 Near-RT RIC group also includes a platform function named “messaging infrastructure”. The messaging infrastructure provides low-latency message delivery services between near-RT RIC platform sendees and xApps (an application designed to run on near-RT RIC). However, the messaging infrastructure that is used for faster delivery of messages between E2 Termination (E2T) (and other RIC Platform Sendees) and xApps deployed on the RIC Platform is subject to Common Vulnerabilities and Exposures (CVE).

[0005] Therefore, there is a need to address the above-mentioned problem(s) of the O-RAN architecture.SUMMARY

[0006] This summary is provided to introduce a selection of concepts, in a simplified format, that are further described in the detailed description of the disclosure. This summary is neither intended to identify key or essential inventive concepts of the present disclosure nor is it intended to determine the scope of the disclosure.

[0007] Disclosed herein are systems and methods for monitoring and preventing the potential attacks related to the O-RzAN near-RT RIC platform and xApps.

[0008] According to one embodiment of the present disclosure, a method is disclosed. The method includes receiving, from an xApp, a data packet at a near Real-Time Radio access network Intelligent Controller (near RT RIC) node. The method also includes comparing, by the near-RT RIC node, a set of predefined parameters associated with the data packet with a corresponding set of predefined values stored at the near-RT RIC node. The method further includes validating, by the near RT RIC node, the data packet based on the comparison.

[0009] According to one embodiment of the present disclosure, an apparatus is disclosed. The apparatus is configured to receive, from an xApp, a data packet at a near Real-Time Radio access network Intelligent Controller (near RT RIC) node. The apparatus is also configured to compare a set of predefined parameters associated with the data packet with a corresponding set of predefined values stored at the near-RT RIC node. The apparatus is further configured to validate the data packet based on the comparison.

[0010] According to one embodiment of the present disclosure, a non-transitory computer- readable medium storing instructions is disclosed. The instructions includes one or more instructions that, when executed by a primary entity of a near Real-Time Radio access network (RAN) Intelligent Controller (near RT RIC) node. The primary entity includes one or more processors. Further, the instructions cause the one or more processors to receive, from an xApp, a data packet at the near RT RIC node. The instructions also cause the one or more processors to compare a set of predefined parameters associated with the data packet with a corresponding set of predefined values stored at the near-RT RIC node. Furthermore, the instructions cause the one or more processors to validate the data packet based on the comparison.

[0011] To further clarify the advantages and features of the present disclosure, a more particular description of the disclosure will be rendered by reference to specific embodiments thereof, which is illustrated in the appended drawing. It is appreciated that these drawings depict only typical embodiments of the disclosure and are therefore not to be considered limiting its scope.The disclosure will be described and explained with additional specificity and detail with the accompanying drawings.BRIEF DESCRIPTION OF DRAWINGS

[0012] Features, aspects, and advantages of certain exemplary embodiments of the disclosure will be described below with reference to the accompanying drawings, in which like reference numerals denote like elements, and wherein:FIG. 1 illustrates an internal architecture of a near-RT RIC with a messaging infrastructure, in accordance with an existing art;FIG. 2 illustrates communication between xApps and a platform within the near-RT RIC, in accordance with a conventional technique;FIG. 3A illustrates an 0-RAN near-RT RIC configuration, in accordance with an embodiment of the present disclosure; andFIG. 3B illustrates an 0-RAN near-RT RIC configuration, in accordance with another embodiment of the present disclosure; FIG. 4 illustrates a flow chart of an example method, in accordance with an embodiment of the present disclosure; andFIG. 5 illustrates an embodiment of an example device, in accordance with an embodiment of the present disclosure.DETAILED DESCRIPTION

[0013] The following detailed description of example embodiments refers to the accompanying drawings. The foregoing disclosure provides illustration and description, but is not intended to, be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from the practice of the implementations. Further, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). Additionally, in the flowcharts and descriptions of operations provided below, it is understood that one or more operations may be omitted, one or more operations may be added, one or more operations may be performed simultaneously (at least in part), and the order of one or more operations may be switched, as long as these modifications may not affect the resulting scope of the present disclosure.

[0014] It will be apparent that systems and / or methods, described herein, may be implemented in different forms of hardware, software, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not limiting the implementations. Thus, the operation and behavior of the systems and / or methods were described herein without reference to specific software code. It is understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0015] Even though particular combinations of features are recited in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of possible implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and / or disclosed in the specification. .Although each dependent claim listed below may directly depend on only one claim, the disclosure of possibleimplementations includes each dependent claim in combination with every other claim in the claim set.

[0016] No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles “a” and “an” are intended to include one or more items, and may be used interchangeably with “one or more.” Where only one item is intended, the term “one” or similar language is used. Also, as used herein, the terms “has,” “have,” “having,” “include,” “including,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise. Furthermore, expressions such as “at least one of [A] and [B]”, “[A] and / or [B]”, or “at least one of [.A] or [B]” are to be understood as including only A, only B, or both A and B.

[0017] The foregoing disclosure provides illustration and description but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from the practice of the implementations.

[0018] The present disclosure provides a Real-Time (RT)E2 traffic monitoring method and control system for a near-RT RIC platform. The present disclosure includes validating any packet data from an xApp to a near RT RIC node based on one or more predefined parameters. Such one or more predefined parameters include an IP address corresponding to a primary entity of the near RT RIC node, a port identifier (ID) corresponding to the primary entity of the near RT RIC node, a transmission protocol, and a message type. This prevents any malicious communication to the primary7entity of the near RT RIC node and thereby enables secure and safe communication among the XzApps and the near-RT RIC platform.

[0019] FIG. 1 illustrates an internal architecture of a near-RT RIC 100 with a messaging infrastructure 102, in accordance with the existing art. The near-RT RIC 100 may reside within an edge cloud or a regional cloud and is responsible for intelligent edge control of RAN nodes and resources. The near-RT RIC 100 may control RAN elements and the corresponding resources with quick optimization actions that typically take 10 milliseconds to one second to complete. The near-RT RIC 100 receives policy guidance from a non-RT RIC 101 and provides policy feedback to the non-RT RIC 101 through specialized applications called xApps 104. In particular, the near-RT RIC 100 is a microservice-based software platform for hosting microservice-based applications, such as the xApps 104. The non-RT RIC 101 may be implemented as an element of an operator’s Service Management and Orchestration (SMO) framework. The non-RT RIC 101 utilizes network data, performance metrics, and subscriber data to provide Al-based recommendations for network optimization and policy guidance to the xApps 104 running on the near-RT RIC 100.

[0020] The xApps 104 correspond to applications that automate and optimize RAN operations while supporting various use cases that reduce mobile operators’ total cost of ownership (TCO) and enhance customers’ quality of experience (QoE). The xApps 104 are used to control a distributed collection of RAN infrastructure (for example, evolved Node B (eNB), gNodeB (gNB), Control Unit (CU), and Distributed Unit (DU)) via E2 protocol. The xApps 104 may be developed / implemented by third-party developers, network operators, RIC platform vendors, and RAN Network equipment vendors.

[0021] The messaging infrastructure 102 is introduced in the O-R AN RIC architecture by the WG3 near-RT RIC group. The messaging infrastructure 102 provides low-latency message delivery services between the near-RT RIC platform services and xApps 104. The near-RT RICplatform services include, conflict mitigation, xApp subscription management, management function, security, AI / ML support, and xApp repository functions and the like.

[0022] In one non-limiting example, the messaging infrastructure 102 uses a RIC Message Router (RMR) library which provides a user application (for example, a near-RT RIC E2 Termination (near-RT RIC E2T)) the ability to send and receive messages from / to other RMR- based applications (for example, xApps). However, embodiments either cover or intend to cover use of any suitable message library by the messaging infrastructure 102 to implement the desired functionality. The xApps 104 uses an E2 interface to collect near RT information (on a UE or cell basis).

[0023] The near-RT RIC 100 provides interfaces for Al and 01 termination to the non-RT RIC 101 for the management and optimization of the RAN and is responsible for necessary optimization-related tasks across different RANs, utilizing available RAN data from all RAN types (macro / small cells, Massive MIMO). The near-RT RIC 100 also provides a Y1 interface for the exposure of analytics information from the near-RT RIC 100 to authorized consumers (e.g., Y1 consumers) via a Y1 termination function. Y1 termination is a function which terminates the Y1 interface from the Y1 consumer. Y1 termination communicates with Y1 consumers via the Y1 interface and exposes RAN analytics information service(s) from the near-RT RIC 100. Specifically, the Y1 interface allows the Y1 consumers to subscribe to or request the RAN analytics information service(s) provided by the near-RT RIC 100.

[0024] The near-RT RIC 100 control over an E2 node 106 is steered via policies and data provided via an Al -interface from the non-RT RIC 101. The E2 node 106 shall be able to function independently of the near-RT RIC 100 when and if the E2 interface and / or the near-RT RIC 100 fails. The E2 node 106 refers to any entity that supports the E2 interface such as, but not limited to, O-CU-CP, O-CU-UP, 0-DU, and O-eNB.

[0025] FIG. 2 illustrates communication between the xApps and a near-RT RIC platform within the near-RT RIC 100, in accordance with a conventional technique. In one non-limiting embodiment, the communication between the near-RT RIC platform and the xApps may use the RMR library’ which provides a user application with the ability to send and receive messages to / from other RMR-based applications without having to understand the underlying messaging transport environment (e.g., SI95) and to know which other endpoint applications are currently available and accepting messages. Further, the xApps are software components that manage E2 nodes (O-CU, O-DU, and O-eNB) in near-real time and provide functions such as RAN resource optimization, radio link monitoring, performance measurements, and policy updates. Though the O-RAN multi-vendor ecosystem enables interoperability, drives innovation, and faster integration, brings a few challenges like secure onboarding, robustness of platform and application services, etc. The near-RT RIC platform and the xApps in the O-RAN system have experienced a list of CVEs based on the potentially exploitable vulnerabilities. Such CVEs have been experienced where the messaging infrastructure 102 with the RMR library is used for faster delivery of messages between E2T (and other RIC Platform Services) and the xApps deployed on the near-RT RIC Platform.

[0026] In the illustrated scenario, an xAppl is implemented with business logic and a Software Development Kit (SDK) library with a network Application Programming Interface (API) client. Further, an xApp2 is implemented with business logic and the SDK library. The business logic may be defined as a part of the xApps that is responsible for implementing business rales that define how data should be created, modified, transformed, communicated, and in otherways managed and controlled. The business logic serves as the backbone, providing the foundation necessary7to drive the application’s core processes, workflows, and other operations. The near-RT RIC platform (also referred to as “the platform”) may provide the Network API support and the SDK support to the implementation of the xAppl and xApp2. The platform may support the implementation of the xApps via one or more servers (for example, sen7! , serv2, and serv3, as illustrated in FIG. 2).

[0027] FIG. 3A illustrates an 0-RAN near-RT RIC configuration, in accordance with an embodiment of the present disclosure. FIG. 3B illustrates an 0-RAN near-RT RIC configuration, in accordance with another embodiment of the present disclosure. The O-RAN near-RT RIC configuration as illustrated in FIGS. 3 A and 3B will address the vulnerabilities and security flaws pertaining to the conventional near-RT RIC Platform in the 0-RAN system.

[0028] Specifically, the configurations illustrated in FIGS. 3 A and 3B disclose the implementation of a real-time RIC E2 traffic monitoring and control service to monitor, validate, and control all incoming (ingress) traffic towards a RIC E2 Termination (E2T) 328.

[0029] In one non-limiting embodiment, two computer nodes 302 and 304 may be implemented on an edge cloud. The computer node 302 (also referred to as the workerl node 302) may implement one or more xApps (for example, an xAppl 306 and an xApp2 308). The xApps 1 306 and the xApp2 308 may communicate with E2 nodes 332 (for example, O-DU, O-CU, and O-eNB).

[0030] The xAppl 306 and xApp2 308 may be responsible for facilitating communication and collaboration between different E2 (E2 interface) nodes 332 within the network. The xAppl 306 and xApp2 308 may enable greater flexibility, scalability, and efficiency in managing the RAN (Radio Access Network) infrastructure. The xAppl 306 and / or xApp2 308 may beconfigured to perform functions such as, but not limited to, network slicing, load balancing, interference coordination, resource allocation, and radio resource management. Though illustrated embodiments only include two xApps 306 and 308, the workerl node 302 may implement any number of xApps, as required to achieve the desired objective.

[0031] The xApps may use ethernet post / connections (for example, ethO, ethl) to communicate with a host Operating System (OS) 310 of the workerl node 302. The host OS 310 may provide a platform for executing the xAppl 306 and xApp2 308, and managing network functions such as scheduling, processing, and control with other entities (such as the computer node 304 and / or the E2 nodes 332). The host OS 310 may include virtual ethernet (veth) interfaces (for example, vethl and veth2) to establish a data connection with the xAppl 306 and / or the xApp2 308. The host OS 310 may also implement a virtual bridge (vBridge) L2 to establish a data connection among the veth interfaces and a Physical Network Interface Card (PHY NIC) 312. The virtual bridge L2 enables communication of the xApps (i.e., the xAppl 306 and the xApp2 308) to communicate with outside entities for example, the computer node 304 and / or the E2 nodes 332. The PHY NIC 312 may be installed on the host OS 310 to provide connectivity to the network 314. The PHY NIC 312 may be responsible for sending and receiving data packets between the host OS 310 and the network 314, ensuring seamless communication and data transfer.

[0032] The computer node 304 (also referred to as the worker2 node 304) may implement near- RT RIC platform sendees 326 (also referred to as the near-RT RIC platform 326) including an E2T 328, service management, a database, an E2 manager. The worker2 node 304 may also include a host OS 318. The host OS 318 may also implement one or more PHY NICs (such as, PHY NIC2316). The PHY NIC2316 may be responsible for sending and receiving data packetsbetween the host OS 318 and the network 314, ensuring seamless communication and data transfer. In an exemplary embodiment, the PHY NIC 312 and the PHY NIC2 316 may enable communication between the workerl node 302, the worker2 node 304, and / or the E2 nodes 332.

[0033] In one embodiment, the host OS 318 may also include an eXpress Data Path (referred to as XDP 320) integrated with extended Berkeley Packet Filter (eBPF) programs. The XDP 320 may act as a bridge between the PHY NIC2 316 and a vBridge L2 322 of the host OS 318. The XDP 320 may be configured to validate each data packet received at the worker2 node 304 before forwarding the received data packet to the E2T 328 (also referred to as a primary entity of the near RT R1C platform 326). The worker2 node 304 may add a primary hook in a reception path of a kernel (not shown) of the host OS 318 via the XDP 320 and allow the eBPF program to decide whether to allow the data packet, block / drop the data packet, or edit the data packet. The XDP 320 may be implemented prior to any memory allocation at the worker2 node 304 to prevent resource wastage. Particularly, the XDP 320 may be defined as a high-performance data path in the kernel that enables efficient packet processing at the network layers associated with the worker2 node 304. The eBPF programs may be referred to as programs executed in the kernel to analyze and filter network packets, among other tasks. The eBPF program enables efficient packet filtering and forwarding by allowing packet processing early in the host OS 318. The eBPF programs may be configured by a user or the E2T 328 with one or more predefined parameters. The predefined parameters may include one or more of an IP address corresponding to a primary entity (i.e., the E2T 328) of the near RT RIC node (i.e., the worker2 node 304), a port identifier (ID) corresponding to the primary entity of the near RT RIC node, a transmission protocol, and an E2AP message type.

[0034] In one or more embodiments, the one or more predefined parameters may be stored in a map 324 (also referred to as eBPF map 324), as shown in below Table 1 :Table 1

[0035] In one embodiment, Table 1 may disclose a relationship between IPs, Port IDs, and protocols associated with the data packets, and / or one or more communication nodes (for example, the workerl node 302, the worker? node 304, and the E2 nodes 332). The port information as shown in Table 1 may be preconfigured during the initial deployment of the primary entity of the near RT-RIC platform 326.

[0036] The eBPF map 324 may be defined as a component of the eBPF program that is allowed to store and share data between the kernel and user-space applications. The eBPF map 324 may correspond to a database including the Table 1 with one or more predefined parameters for packet filtering. The XDP 320 integrated with the eBPF programs may prevent any malicious packet from being forwarded to the E2T 328.

[0037] The one or more predefined parameters play a critical role in filtering of the data packet. For instance, any data packet directed to the E2T 328 may have a predefined IP address, theport ID, and a data transmission protocol. In case, the received packet fails to match the predefined or more parameters, the XDP 320 may drop the packet.

[0038] In one embodiment, a real-time RIC E2 traffic controller 330 implemented at the E2T 328 may be configured to monitor and control below traffic paths to secure the near-RT RIC platform and / or services 326 from unwanted attacks.Path 1 : E2 nodes (O-DU, O-CU and O-eNB) <--> Near-RT RIC Platform(E2T) through SCTP connection with E2AP messagesPath 2: xApps <?->Near-RT RIC Platform(E2T) through TCP connection (internal RIC Message Router (RMR) library) with E2AP messages.

[0039] As per O-RAN WG3 Near-RT RIC E2AP technical specification, a set of procedures are defined to exchange the message between the near-RT RIC and the E2 nodes 332. Further, a set of procedures (messages) are used to communicate and exchange data between the E2 nodes 332 and xApps (for example, the xAppl 306 and the xApp2 308). Such exchange of the data may be performed via the E2T 328 once the xApps are onboarded on the near-RT RIC Platform. The real-time RIC E2 traffic controller 330 may consider the set of procedures and / or messages to validate the received data packets at the E2T 328. The real-time E2 traffic controller 330 may be configured to optimize traffic flow, reduce congestion, and improve the overall efficiency and security of data transmission at the E2T 328.

[0040] In the illustrated embodiment of FIG. 3 A, once the RIC E2 Termination(E2T) 328 is deployed on the RIC platform (i.e., the near-RT RIC Platform 326) in the edge cloud, the RIC E2 traffic controller 330 gets initial configurable IPs, ports, and the protocol types of E2T instance and planned / known E2 nodes 332. The RIC E2 traffic controller 330 updates a sharedmap (i.e., the map 324) based on assessed details. In one embodiment, the RIC E2 traffic controller 330 may also update IP addresses associated with one or more xApps onboarded on the edge cloud in the shared map 324. The RIC E2 traffic controller 330 may also update internal messaging ports associated with the onboarded xApps to the shared map 324. Moreover, the RIC E2 traffic controller 330 may update IP addresses associated with the E2 nodes 332 and Stream Control Transmission Protocol (SCTP) port in the shared map 324 whenever the E2 nodes 332 establish SCTP communication and integrate with the near-RT RIC platform 326. The updated field of the shared map 324 may correspond to the one or more predefined parameters. Then the RIC E2 traffic controller 330 may load the pre-configured eBPF hooks to the corresponding host kernel for the XDP 320. The pre-configured eBPF hooks are based on the updated shared map 324.

[0041] Once the eBPF hooks are loaded and attached to the XDP 320, the RIC E2 traffic controller 330 may validate the ingress traffic based on the one or more pre-configured parameters stored in the map 324. In some embodiment, the RIC E2 traffic controller 330 may also determine whether the packet has a valid length and is not corrupted using the eBPF hooks implemented at the XDP 320. The validation of the received data packet based on the valid length and data corruption may be performed either prior to validating the data packets based on the one or more preconfigured parameters or after successful validation of the data packets based on the one or more preconfigured parameters stored in the map 324. If the packet is successfully validated based on one or more of the above-mentioned procedures, then the XDP 320 may allow the packet to move further towards the destination (i.e., the near-RT RIC E2T 328), otherwise the XDP 320 may drop the packet.

[0042] In some embodiments, the eBPF hooks deployed by the RIC E2 traffic controller 330 may hold a logic to maintain a packet count based on a specific port and an IP address. The packet count may be validated with a threshold limit at every 500ms to detect any Denial of Service (DoS) attack towards RIC Platform (E2T) 328 that may be possible by modifying packet size, huge raw data packets, and triggering wrong E2 messages continuously from compromised, untrusted, or malicious xApps.

[0043] In alternative embodiments, the RIC E2 traffic controller 330 may also be configured to verify message types (for example, E2 setup, subscription request and response, etc.) by parsing the incoming (ingress) packet towards RIC E2T 328 via the deployed eBPF hooks at the XDP 320. The RIC E2 traffic controller 330 may utilize an E2AP-specific ASN decoder or encoder library to get the message type.

[0044] Thus, the present disclosure ensures the availability of the secure near-RT RIC platform sendee and the messaging infrastructure for internal communication between the RIC components and the xApps.

[0045] In the illustrated embodiment of FIG. 3 A, the xAppl 306 is compromised, therefore when the xAppl 306 transmits a data packet to the E2T 328 and / or the E2 node 332, the XDP .320 may validate and drop the packet based on the one or more preconfigured parameters.

[0046] For instance, the compromised xAppl 306 may fail to identify a correct IP address, a port ID, or a protocol type for the E2T 328. Accordingly, if any of such matches fail, the XDP 320 may block the data packet. In case, the data packet is successfully validated based on the one or more preconfigured parameters, the XDP 320 may further validate the data packet based on characteristics of the data packet that include, but are not limited to, a number of counts, a size of data packet, a type of data packet.

[0047] In the illustrated embodiment of FIG. 3B, the compromised xAppl 306 is deployed at the worker2 node 304 where the E2T 328 is implemented. Therefore, in such a case, a Traffic Controller (TC) 321 may be deployed with the preconfigured eBPF programs, as explained above to filter the data packet. The TC 321 may monitor the data traffic from the xAppl 306 to the E2T 328 and prevent any malicious data packet from being forwarded to the E2T 328 via the vBridge L2 322.

[0048] As reported, CVEs are publicly disclosed security flaws, proactively preventing and protecting the target system from these kind of attacks is very crucial for minimizing the risk of cyber-attacks and data breaches which can result in significant cost savings.

[0049] The near-RT RIC platform service is an open-source software created and managed by the 0-RAN Software community. The community is focused on aligning with the O-RAN Alliance’s open architecture and specifications to achieve a solution. So, enabling the security controls along with prevention mechanisms from these security attacks or vulnerabilities, provides several value adds (Enhanced security, reduced risk, compliance, and competitive advantage) for the product.

[0050] FIG. 4 illustrates a flow chart of an example method 400, in accordance with an embodiment of the present disclosure.

[0051] At step 402, a data packet from an xApp (for example, the xAppl 306) may be received at the near-RT RIC node (for example, the worker2 node 304). In an embodiment, the data packet is received via the E2 interface and is addressed to the primary entity (i.e., the E2T 328) of the near RT RIC node 304. In an alternative embodiment, the data packet is addressed to any one of the E2 nodes 332.

[0052] At step 404, a set of predefined parameters associated with the data packet is compared with a corresponding set of predefined values stored at the near-RT RIC node (for example, at the map 324). In some embodiment, the XDP 320 or the TC 321, based on the implementation, may extract the set of predefined parameters associated with the received data packet. Thereafter, the XDP 320 or the TC 321 may compare the extracted set of predefined parameters with the set of corresponding predefined values as configured by the near RT E2 traffic controller 330 via the map 324. In some embodiment, the E2T 328 and / or the RIC E2 traffic controller 330 deployed at the E2T 328 may generate the set of predefined parameters and a corresponding set of predefined values, as shown in Table 1, above. The E2T 328 and / or the RIC E2 traffic controller 330 may store the generated set of predefined parameters and the corresponding set of predefined values in the database (referred to as the map 324) at the near RI RIC node 304. Moreover, to compare the set of predefined parameters associated with the data packet with the corresponding set of predefined values, the method 400 may include identifying a value corresponding to each of the set of predefined parameters corresponding to the data packet based on metadata information associated with the data packet. The value corresponding to each of the set of predefined parameters may be identified by the XDP 320 or the TC 321 based on the implementation . Further, the set of predefined values corresponding to the set of predefined parameters is extracted from the database as implemented at the near RT RIC node 304. Thereafter, the XDP 320 or TC 321 may compare the identified values of the set of predefined parameters corresponding to the data packet with the extracted set of predefined values for validating the data packet.

[0053] At step 406, the data packet is validated based on said comparison. In one embodiment, the data packet is forwarded / transmitted to the primary entity upon successful validation of thedata packet. Alternatively, the data packet is discarded upon unsuccessful validation of the data packet. In some embodiment, prior to deciding on whether to forward or discard the data packet, the one or more data-related characteristics associated with the data packet are identified. Examples of the one or more data-related characteristics include, but are not limited to, a length of the data packet, a length of an IP header, and a checksum. Further, the identified one or more data-related characteristics associated with the data packet are compared with corresponding one or more predefined threshold values for further validating the data packet.

[0054] In some embodiments, the method 400 may also include validating the data packet from the xApps to the primary entity for a predefined time period based on the characteristics / predefined parameters of the data packets. Such characteristics include, but are not limited to, a number of data packets and a rate of data packets. Moreover, a security event is detected based on the validation of the data packet over the predefined time period.

[0055] FIG. 5 illustrates an embodiment of an example device / apparatus 500, in accordance with an embodiment of the present disclosure. In one embodiment, the device / apparatus 500 may be implemented within the E2T 328 and / or the near RT RIC node 304 (i.e., the worker2 node 304).

[0056] As shown in FIG. 5, the device 500 includes a processor 510, a memory 520, a storage component 530, an input component 540, an output component 550, a communication interface 560, and a bus 570. The one or more components device 500 may be configured to perform one or more functionalities associated with the workerl node 302, the worker2 node 304, and the E2 nodes 332.

[0057] The processor 510, as used herein, means any type of computational circuit that may comprise hardware elements and software elements. The processor 510 may be embodied as amulti-core processor, a single core processor, or a combination of one or more multi-core processors and / or one or more single core processors, a distributed processing system, or the like. The processor 510 may be a Central Processing Unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), an application-specific integrated circuit (ASIC), or another type of processing component. In one non-limiting example, the processor 510 may be configured to perform the one or more functions associated with the E2T 328 and / or the worker2 node 304.

[0058] The memory 520 includes a non-transitory computer readable medium. Memory 520 includes a random-access memory (R AM), a read only memory (ROM), and / or another type of dynamic or static storage device (e.g., a flash memory, a magnetic memory, and / or an optical memory) that stores information and / or instructions for use by processor 510. The memory 520 comprises machine-readable instructions which are executable by the processor 510. These machine-readable instructions when executed by the processor 510 cause the processor 510 to perform one or more method steps of an embodiment described above.

[0059] The storage component 530 stores information and / or software related to the operation and use of the device 500. For example, the storage component 530 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, and / or a solid-state disk), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, a magnetic tape, and / or another type of non-transitory computer-readable medium, along with a corresponding drive.

[0060] The input component 540 is configured to receive information, such as user input. For example, the input component 540 may include, but not be limited to, a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, and / or a microphone. .Additionally, oralternatively, the input component 540 may include a sensor for sensing information (e.g., a global positioning system (GPS), an accelerometer, a gyroscope, and / or an actuator).

[0061] The output component 550 is configured to provide output information from the device 500. For example, the output component 550 maybe, but is not limited to, a display, a speaker, an instruction device to an external device, and / or one or more light-emitting diodes (LEDs).

[0062] The communication interface 560 is an interface that provides a communication connection to other devices, such as external devices and internal devices. The connection by the communication interface 560 can be a wired connection, a wireless connection, or a combination of wired and wireless connections, and can be a direct connection or an indirect connection via a communication network that exists between the device 500 and other devices. In other words, the standard of the communication interface 560 is not limited.

[0063] The bus 570 acts as an interconnect between the processor 510, the memory 520, the storage component 530, the input component 540, the output component 550, and the communication interface 560 of the device 500. The bus 570 may include a wired interconnection or a wireless interconnection.

[0064] The number and arrangement of components shown in FIG. 5 are provided as an example. In practice, the device 500 may include additional components, fewer components, different components, or differently arranged components than those shown in FIG. 5. Additionally, or alternatively, a set of components (e.g., one or more components) of the device 500 may perform one or more functions described as being performed by another set of components of the device 500. Further, one or more method steps described in any of the embodiments may be performed utilizing a plurality of devices 500 in communication with one another.[1] A method is described. The method includes receiving, from an xApp, a data packet at a near Real-Time Radio access network Intelligent Controller (near RT RIC) node. The method also includes comparing, by the near-RT RIC node, a set of predefined parameters associated with the data packet with a corresponding set of predefined values stored at the near-RT RIC node. Moreover, the method includes validating, by the near RT RIC node, the data packet based on the comparison.[2] The method as described in [1], the method includes receiving, from the xApp, the data packet at the near RT RIC node via an E2 interface. The data packet is addressed for the primary entity of the near RT RIC node.[3] The method as described in any of

[0001] -[2], the method includes performing one of: transmitting the data packet to the primary entity upon successful validation of the data packet; or discarding the data packet upon unsuccessful validation of the data packet.[4] The method as described in any of [l]-[3], wherein prior to receiving the data packet, the method comprising: generating, by the primary entity, the set of predefined parameters and corresponding set of predefined values; and storing, the generated set of predefined parameters and the corresponding set of predefined values in a database at the near RT RIC node.[5] The method as described in any of [l]-[4], wherein comparing the set of predefined parameters associated with the data packet comprises:identifying, by one of an express Data Path (XDP) or a Traffic Controller (TC) of the near RT RIC node, a value corresponding to each of the set of predefined parameters corresponding to the data packet based on metadata information associated with the data packet; extracting, by one of the XDP or the TC, the set of predefined values corresponding to the set of predefin ed parameters, from the database implemented at the near RT RIC node; and comparing, by one of the XDP or the TC, the identified values of the set of predefined parameters corresponding to the data packet with the extracted set of predefined values for validating the data packet.[6] The method as described in any of [l]-[5], wherein validating the data packet further comprises: identifying one or more data-related characteristics associated with the data packet, wherein the one or more data-related characteristics comprise at least a length of the data packet, a length of an IP header, and a checksum; and comparing the identified one or more data-related characteristics associated with the data packet with corresponding one or more predefined threshold values for further validating the data packet.[7] The method as described in any of [l]-[6], further comprising: validating each of a plurality of data packets, from the xApp to the primary entity of the near RT RIC node over a predefined time period based at least on the set of predefined characteristics corresponding to the plurality of data packets, wherein the set of predefined characteristics comprises at least a number of data packets, and a rate of data packets; andwhen the validation of the plurality of data packets is failed, logging a security event.[8] The method as described in any of [l]-[7], wherein the set of predefined parameters comprises one or more of an IP address corresponding to a primary entity of the near RT RIC node, a port identifier (ID) corresponding to the primary entity of the near RT RIC node, a transmission protocol, and a message type.[9] The method as described in any of

[0001] -[8], wherein the primary entity of the near RT RIC node corresponds to one of an E2 Termination (E2T) or an E2 node.

[0010] An apparatus is described. The apparatus is configured to receive, from an xApp, a data packet at a near Real-Time Radio access network Intelligent Controller (near RT RIC) node. The apparatus is also configured to compare a set of predefined parameters associated with the data packet with a corresponding set of predefined values stored at the near-RT RIC node. The apparatus is also configured to validate the data packet based on the comparison.

[0011] The apparatus as described in

[0010] , wherein the apparatus is configured to receive, from the xApp, the data packet at the near RT RIC node via an E2 interface, wherein the data packet is addressed for the primary entity of the near RT RIC node.

[0012] The apparatus as described in any of

[0010] -[l l], is further configured to: perform one of: transmitting the data packet to the primary entity upon successful validation of the data packet; or discarding the data packet upon unsuccessful validation of the data packet.

[0013] The apparatus as described in any of

[0010] -

[0012] , wherein prior to receiving the data packet, the apparatus is configured to:generate the set of predefined parameters and corresponding set of predefined values; and store the generated set of predefined parameters and the corresponding set of predefined values in a database at the near RT RIC node.

[0014] The apparatus as described in any of

[0010] -

[0013] , wherein to compare the set of predefined parameters associated with the data packet, the apparatus is configured to: identify, via one of an eXpress Data Path (XDP) or a Traffic Controller (TC) of the near RT RIC node, a value corresponding to each of the set of predefined parameters corresponding to the data packet based on metadata information associated with the data packet; extract, via one of the XDP or the TC, the set of predefined values corresponding to the set of predefined parameters, from the database implemented at the near RT RIC node; and compare, via one of the XDP or the TC, the identified values of the set of predefined parameters corresponding to the data packet with the extracted set of predefined values for validating the data packet.

[0015] The apparatus as described in

[0010] -

[0014] , wherein to validate the data packet, the apparatus is further configured to: identify one or more data-related characteristics associated with the data packet, wherein the one or more data-related characteristics comprising at least a length of the data packet, a length of an IP header, and a checksum; and compare the identified one or more data-related characteristics associated with the data packet with corresponding one or more predefined threshold values for further validating the data packet.

[0016] The apparatus as described in any of

[0010] -

[0015] , further configured to: validate each of a plurality of data packets, from the xApp to the primary entity of the near RT RIC node over a predefined time period based at least on the set of predefined characteristics corresponding to the plurality of data packets, wherein the set of predefined characteristics comprises at least a number of data packets, and a rate of data packets; and when the validation of the plurality of data packets is failed, log a security event.

[0017] The apparatus as described in any of

[0010] -

[0016] , wherein the set of predefined parameters comprises one or more of an IP address corresponding to a primary entity of the near RT RIC node, a port identifier (ID) corresponding to the primary entity of the near RT RIC node, a transmission protocol, and a message type.

[0018] The apparatus as described in any of

[0010] -

[0017] , wherein the primary entity of the near RT RIC node corresponds to one of an E2 Termination (E2T) or an E2 node.

[0019] A non-transitory computer-readable medium storing instructions is disclosed. The instructions comprising: one or more instructions that, when executed by a primary entity of a near Real-Time Radio access network Intelligent Controller (near RT RIC) node, the primary entity comprising one or more processors, cause the one or more processors to receive, from an xApp, a data packet at the near RT RIC node. The one or more instractions further cause the one or more processors to compare a set of predefined parameters associated with the data packet with a corresponding set of predefined values stored at the near-RT RIC node. The set of predefined parameters comprises one or more of an IP address corresponding to a primary entity of the near RT RIC node, a port identifier (ID) corresponding to the primary’ entity of thenear RT RIC node, a transmission protocol, and a message type. The one or more instructions also cause the one or more processors to validate the data packet based on the comparison.

[0065] The embodiments disclosed herein can be implemented through at least one software program running on at least one hardware device and performing network management functions to control the elements. The elements can be at least one of a hardware device or a combination of hardware devices and software modules.

[0066] While specific language has been used to describe the disclosure, any limitations arising on account of the same are not intended. As would be apparent to a person in the art, various working modifications may be made to the method in order to implement the inventive concept as taught herein.

[0067] The drawings and the forgoing description give examples of embodiments. Those skilled in the art will appreciate that one or more of the described elements may well be combined into a single functional element. Alternatively, certain elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment. For example, orders of processes described herein may be changed and are not limited to the manner described herein.

[0068] Moreover, the actions of any flow diagram need not be implemented in the order shown; nor do all of the acts necessarily need to be performed. .Also, those acts that are not dependent on other acts may be performed in parallel with the other acts. The scope of embodiments is by no means limited by these specific examples. Numerous variations, whether explicitly given in the specification or not, such as differences in structure, dimension, and use of material, are possible. The scope of embodiments is at least as broad as given by the following claims.

[0069] B enefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any component(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature or component of any or all the claims.

[0070] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and / or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments.It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of at least one embodiment, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the embodiments as described herein.

Claims

We Claim:

1. A method (400) comprising: receiving (402), from an xApp, a data packet at a near Real-Time Radio access network Intelligent Controller (near RT RIC) node; comparing (404), by the near RT RIC node, a set of predefined parameters associated with the data packet with a corresponding set of predefined values stored at the near-RT RIC node; and validating (406), by the near RT RIC node, the data packet based on the comparison.

2. The method (400) as claimed in claim 1, wherein receiving the data packet comprises: receiving, from the xApp, the data packet at the near RT RIC node via an E2 interface, wherein the data packet is addressed for the primary entity of the near RT RIC node.

3. The method (400) as claimed in claim 1, further comprising: performing one of: transmitting the data packet to the primary entity upon successful validation of the data packet; or discarding the data packet upon unsuccessful validation of the data packet.

4. The method (400) as claimed in claim 1 , wherein prior to receiving the data packet, the method comprising:generating, by the primary entity, the set of predefined parameters and corresponding set of predefined values; and storing the generated set of predefined parameters and the corresponding set of predefined values in a database at the near RT RIC node.

5. The method (400) as claimed in claim 1, wherein comparing the set of predefined parameters associated with the data packet comprises: identifying, by one of an eXpress Data Path (XDP) or a Traffic Controller (TC) of the near RT RIC node, a value corresponding to each of the set of predefined parameters corresponding to the data packet based on metadata information associated with the data packet; extracting, by one of the XDP or the TC, the set of predefined values corresponding to the set of predefined parameters, from the database implemented at the near RT RIC node; and comparing, by one of the X DP or the TC, the identified values of the set of predefined parameters corresponding to the data packet with the extracted set of predefined values for validating the data packet.

6. The method (400) as claimed in claim 1, wherein validating the data packet further comprises: identifying one or more data-related characteristics associated with the data packet, wherein the one or more data-related characteristics comprise at least a length of the data packet, a length of an IP header, and a checksum; andcomparing the identified one or more data-related characteristics associated with the data packet with corresponding one or more predefined threshold values for further validating the data packet.

7. The method (400) as claimed in claim 1 , further comprising: validating each of a plurality of data packets, from the xApp to the primary entity of the near RT RIC node over a predefined time period based at least on the set of predefined characteristics corresponding to the plurality of data packets, wherein the set of predefined characteristics comprises at least a number of data packets, and a rate of data packets; and when the validation of the plurality of data packets is failed, logging a security event.

8. The method (400) as claimed in claim 1, wherein the set of predefined parameters comprises one or more of an IP address corresponding to a primary' entity of the near RT RIC node, a port identifier (ID) corresponding to the primary entity of the near RT RIC node, a transmission protocol, and a message type.

9. The method (400) as claimed in claim 1 , wherein the primary' entity of the near RT RIC node corresponds to one of an E2 Termination (E2T) or an E2 node.

10. An apparatus (500) configured to:receive, from an xApp (306, 308), a data packet at a near Real-Time Radio Access Network Intelligent Controller (near RT RIC) node (304); compare a set of predefined parameters associated with the data packet with a corresponding set of predefined values stored at the near-RT RIC node (304); and validate the data packet based on the comparison.

11. The apparatus (500) as claimed in claim 10, wherein the apparatus (500) is configured to receive, from the xApp (306, 308), the data packet at the near RT RIC node (304) via an E2 interface, wherein the data packet is addressed for the primary entity (328) of the near RT RIC node (304).

12. The apparatus (500) as claimed in claim 10, is further configured to: perform one of: transmitting the data packet to the primary’ entity upon successful validation of the data packet; or discarding the data packet upon unsuccessful validation of the data packet.

13. The apparatus (500) as claimed in claim 10, wherein prior to receiving the data packet, the apparatus (500) is configured to: generate the set of predefined parameters and corresponding set of predefined values; and store the generated set of predefined parameters and the corresponding set of predefined values in a database at the near RT RIC node (304).

14. The apparatus (500) as claimed in claim 10, wherein to compare the set of predefined parameters associated with the data packet, the apparatus (500) is configured to: identify, via one of an eXpress Data Path (XDP) (320) or a Traffic Controller (TC) (321) of the near RT RIC node (304), a value corresponding to each of the set of predefined parameters corresponding to the data packet based on metadata information associated with the data packet: extract, via one of the XDP (320) or the TC (320), the set of predefined values corresponding to the set of predefined parameters, from the database implemented at the near RT RIC node; and compare, via one of the XDP (320) or the TC (321), the identified values of the set of predefined parameters corresponding to the data packet with the extracted set of predefined values for validating the data packet.

15. The apparatus (500) as claimed in claim 10, wherein to validate the data packet, the apparatus (500) is further configured to: identify one or more data-related characteristics associated with the data packet, wherein the one or more data-related characteristics comprising at least a length of the data packet, a length of an IP header, and a checksum: and compare the identified one or more data-related characteristics associated with the data packet with corresponding one or more predefined threshold values for further validating the data packet.

16. The apparatus (500) as claimed in claim 10, further configured to: validate each of a plurality of data packets, from the xApp (306, 308) to the primary entity (328) of the near RT RIC node (304) over a predefined time period based at least on the set of predefined characteristics corresponding to the plurality of data packets, wherein the set of predefined characteristics comprises at least a number of data packets, and a rate of data packets; and when the validation of the plurality of data packets is failed, log a security event.

17. The apparatus (500) as claimed in claim 10, wherein the set of predefined parameters comprises one or more of an IP address corresponding to a primary7entity of the near RT RIC node, a port identifier (ID) corresponding to the primary entity of the near RT RIC node, a transmission protocol, and a message type.

18. The apparatus (500) as claimed in claim 10, wherein the primary entity of the near RT RIC node corresponds to one of an E2 Termination (E2T) or an E2 node.

19. A non-transitory computer-readable medium storing instructions, the instructions comprising: one or more instructions that, when executed by a primary entity (328) of a near Real-Time Radio access network (RAN) Intelligent Controller (near RT RIC) node (304), the primary7entity (328) comprising one or more processors (510), cause the one or more processors (510) to: receive, from an xApp (306, 308), a data packet at the near RT RIC node (304);compare a set of predefined parameters associated with the data packet with a corresponding set of predefined values stored at the near-RT R1C node (304); and validate the data packet based on the comparison.

Images