XAPP instance registration in a cloud-native network

Abstract

Methods, systems, and devices are provided for registering xApp instances in a cloud-native network. The method may be implemented by a Near Real-Time (RT) Radio Access Network (RAN) Intelligent Controller (RIC). The method may include receiving a registration message from Service Management and Orchestration (SMO) containing the details and xApp identifier (ID) of the xApp instance; generating a Certificate Signing Request (CSR) containing the xApp ID to be registered in the Near RT-RIC based on the registration message; receiving a certification request message from the xApp instance; verifying the xApp instance based on the certification request message; and sending a certification response message to the xApp instance.

Description

Technical Field

[0001] [Cross - Reference to Related Applications] This application claims priority based on Indian Provisional Patent Application No. 202341041098 filed on June 16, 2023, and the entire disclosure thereof is incorporated herein by reference.

[0002] [Technical Field] Systems and methods consistent with embodiments of the present disclosure relate to xApp instance registration in cloud - native networks such as Open Radio Access Networks (O - RAN).

Background Art

[0003] A Radio Access Network (RAN) is an important component in a communication system that connects end - user devices (or user equipment) to other parts of the network. The RAN includes a combination of various network elements (NEs) that connect end - user devices to the core network. Conventionally, the hardware and / or software of a particular RAN were vendor - specific.

[0004] The emergence of Open RAN (O-RAN) technology has enabled multiple vendors to provide hardware and / or software for communication systems. To this end, O-RAN decomposes RAN functionality into Aggregation Units (CUs), Distributed Units (DUs), and Radio Units (RUs). CUs are logical nodes for hosting the RAN sublayers of Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and / or Packet Data Convergence Protocol (PDCP). DUs are logical nodes for hosting the RAN sublayers of Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY). RUs are physical nodes that convert radio signals from antennas into digital signals that can be transmitted to the DUs on the fronthaul. Because these entities have open protocols and interfaces between them, they can be developed by different vendors.

[0005] Figure 1 illustrates an O-RAN architecture in related technologies. Referring to Figure 1, the RAN functions in the O-RAN architecture are controlled and optimized by a RAN Intelligent Controller (RIC). The RIC is a software-defined component that implements modular applications to achieve the multi-vendor operability required in the O-RAN system and to automate and optimize RAN operations. RICs are divided into two types: non-real-time RICs (Non-RT RICs) and near-real-time RICs (Near-RT RICs).

[0006] Non-RT RICs are the control point of the non-real-time control loop and operate on a timescale longer than one second within the Service Management and Orchestration (SMO) framework. Their functionality is implemented through modular applications called rApps (rApp 1, ..., rApp N) and includes providing policy-based guidance and enrichment across the A1 interface, which is an interface enabling communication between Non-RT RICs and Near-RT RICs; performing data analytics; artificial intelligence / machine learning (AI / ML) training and inference for RAN optimization; and / or recommending configuration management actions on the O1 interface, which is an interface connecting SMO to RAN management elements (e.g., Near-RT RICs, O-RAN Aggregation Units (O-CUs), O-RAN Distributed Units (O-DUs), etc.).

[0007] Near-RT RICs operate on timescales between 10 milliseconds and 1 second and connect to O-DUs, O-CUs (decomposed into O-CU control planes (O-CU-CP) and O-CU user planes (O-CU-UP)), and open evolved NodeBs (O-eNBs) via E2 interfaces. Near-RT RICs use E2 interfaces to control the underlying RAN elements (E2 nodes / network functions (NFs)) on a near real-time control loop. Near-RT RICs monitor, suspend / stop, override, and control E2 nodes (O-CUs, O-DUs, O-eNBs) via policies. For example, Near-RT RICs set policy parameters on the activated functions of E2 nodes. Furthermore, Near-RT RICs host xApps to implement functions such as Quality of Service (QoS) optimization, mobility optimization, slicing optimization, interference mitigation, load balancing, and security. The two types of RICs work together to optimize O-RAN. For example, a Non-RT RIC provides policies, data, and AI / ML models enabled and used by a Near-RT RIC for RAN optimization via the A1 interface, and the Near-RT RIC returns policy feedback (i.e., how the policies set by the Non-RT RIC are working).

[0008] The MO framework on which the Non-RT RIC resides manages and coordinates the RAN elements. Specifically, the SMO includes FOCOM (Federated O-Cloud Orchestration and Management), a Network Function Orchestrator (NFO) that manages virtual network functions (VNFs) or cloud-native network functions (CNFs) based on virtual machines (VMs) and VNFs (CNFs) based on containers (i.e., instances), and Operations and Maintenance (OAM) as part of the SMO that manages and coordinates what is represented as the O-RAN Cloud (O-Cloud). The O-Cloud is a collection of RICs, O-CUs, O-DUs, supporting software components (e.g., operating systems and runtime environments), and physical RAN nodes that host the SMO itself. In other words, the SMO manages the O-Cloud from within. The O2 interface is the interface between the SMO and the O-Cloud on which it resides. Through the O2 interface, the SMO provides Infrastructure Management Services (IMS) and Deployment Management Services (DMS). The O2 interface may transmit O2 telemetry data to the SMO, such as O-Cloud configuration or arbitrary logical function data, energy consumption, node health status, etc.

[0009] In related technologies, an xApp (eXtended Application) instance is a software application deployed on a near-RT RIC. An xApp typically contains one or more cloud-native microservices. An xApp instance may register with a near-RT RIC using an xApp identifier (ID). An xApp solution provider may typically digitally sign the xApp and provide it to an operator. The operator may then verify the digital signature and add its own signature to the package.

[0010] An xApp may communicate with other entities in the O-RAN network using a unique identifier. The unique ID of an xApp instance is a digital certificate signed by the operator, which is used to authenticate itself in the network. The xApp registration procedure may require the xApp instance to send an authentication token (such as OAuth) along with a Certificate Signing Request (CSR) to the Near-RT RIC to generate a digital certificate with the xApp ID. Proof of ownership of a private key is a method that may be used to verify the authenticity of the xApp in the RIC. [Overview of the project] [Problems that the invention aims to solve]

[0011] In related technologies, an xApp instance may generate a CSR and send it to the nearest RT RIC in order to communicate with other entities in the O-RAN network. The RIC may then embed the xApp ID through a policy and send the CSR to the operator for signing. The operator may then send a certificate to the xApp instance, embedding the xApp ID in the Subject Alt Name (SAN) field of the certificate.

[0012] However, this approach carries security risks because the xApp is responsible for managing its own private keys and certificates, thus increasing the attack surface for the xApp instance. Furthermore, in related technologies, the xApp ID typically follows a UUID format, and UUIDs are inherently random. There is no standardized format for xApp IDs.

[0013] Therefore, a more secure method is needed for registering xApp instances, including generating and handling an xApp ID that is independent of the xApp itself. [Means for solving the problem]

[0014] Embodiments of this disclosure provide a method and system for registering xApp instances in a cloud-native network such as O-RAN. In particular, the method may be implemented by a Near Real-Time (RT) Radio Access Network (RAN) Intelligent Controller (RIC). The method may include receiving a registration message from Service Management and Orchestration (SMO) containing the details of the xApp instance and the xApp identifier (ID); generating a Certificate Signing Request (CSR) containing the xApp ID to be registered in the Near RT-RIC based on the registration message; receiving a certification request message from the xApp instance; verifying the xApp instance based on the certification request message; and sending a certification response message to the xApp. In this way, the registration module can handle the private key and certificate management for the xApp, reducing the overall attack surface because the private key is not exposed. In addition, the burden on the xApp instance is reduced because the xApp instance itself does not generate a CSR (for example, the private key and certificate are stored in the registration module's memory and do not require external secure storage), and the xApp does not need to be aware of the underlying security management procedures. Thus, a more secure and efficient method for registering xApp instances may be realized.

[0015] According to one embodiment, a method implemented by a Near Real-Time (RT) Radio Access Network (RAN) Intelligent Controller (RIC) includes: a server receiving a Certificate Signing Request (CSR) containing an xApp identifier (ID) for an xApp instance originating from an agent; the server submitting the CSR to an Operator Certificate Authority (CA) for signing; the server receiving an xApp SPIFFE (Secure Production Identity Framework for Everyone) verifiable identity document (SVID) from the Operator CA; and the server submitting the xApp SVID to the agent. Upon receiving the xApp SVID, the agent provides the xApp SVID and a trust bundle to the xApp instance.

[0016] According to the embodiment, a Near Real-Time (RT) Radio Access Network (RAN) Intelligent Controller (RIC) may be provided and configured to receive a registration message from Service Management and Orchestration (SMO) containing the details and xApp identifier (ID) of an xApp instance; generate a Certificate Signing Request (CSR) containing the xApp ID to be registered in the Near RT-RIC based on the registration message; receive a certification request message from the xApp instance; verify the xApp instance based on the certification request message; and send a certification response message to the xApp instance.

[0017] According to one embodiment, a Near Real-Time (RT) Radio Access Network (RAN) Intelligent Controller (RIC) may be provided and configured to receive a Certificate Signing Request (CSR) containing an xApp identifier (ID) for an xApp instance originating from an agent, send the CSR to an Operator Certificate Authority (CA) for signing, receive an xApp SPIFFE (Secure Production Identity Framework for Everyone) verifiable identity document (SVID) from the Operator CA, and send the xApp SVID to the agent. Upon receiving the xApp SVID, the agent provides the xApp SVID and a trust bundle to the xApp instance.

[0018] Additional aspects may be partially presented in the following description, partially revealed from the description, or realized by implementing the embodiments presented in this disclosure. [Brief explanation of the drawing]

[0019] Features, aspects, and advantages of certain exemplary embodiments of the disclosure are described below with reference to the accompanying drawings, where similar reference numerals represent similar elements.

[0020] Figure 1 illustrates an O-RAN architecture related to the relevant technologies.

[0021] Figure 2 shows an example of a system architecture diagram for an xApp instance registration interface according to one embodiment.

[0022] Figures 3A to 3B show an example of a call flow diagram for xApp instance registration using a certificate sidecar according to one embodiment.

[0023] Figs. 4A to 4C show an example of a call flow diagram for xApp instance registration using an agent and a server according to an embodiment.

[0024] Fig. 5 shows an example of a flowchart of a method for handling xApp instance registration according to an embodiment.

[0025] Fig. 6 shows an example of a flowchart of a method for handling xApp instance registration using a near RT-RIC or a server according to an embodiment.

[0026] Fig. 7 illustrates an example diagram of an environment in which the systems and / or methods described herein may be implemented.

[0027] Fig. 8 illustrates an example diagram of components of a device according to an embodiment.

[0028] Fig. 9 shows an example of a system architecture diagram according to an embodiment.

[0029] Figs. 10A to 10F show an example of xApp registration procedures using the SPIFFE framework according to an embodiment.

Mode for Carrying Out the Invention

[0030] The following detailed description of the embodiments refers to the accompanying drawings. The same reference numerals in different figures may identify the same or similar elements.

[0031] The prior disclosures provide examples and descriptions, but are not intended to be exhaustive or to limit implementations to the exact forms disclosed. Modifications and alterations are possible in light of the prior disclosures or may be obtained from the implementation. Furthermore, one or more features or components of one embodiment may be integrated with or combined with other embodiments (or one or more features of other embodiments). In addition, in the flowcharts and operation descriptions provided below, one or more operations may be omitted, one or more operations may be added, one or more operations may be performed simultaneously (at least partially), and the order of one or more operations may be changed.

[0032] It will become clear that the systems and / or methods described herein may be implemented in different forms of hardware, firmware, or combinations of hardware and software. The specific control hardware or software code used to implement these systems and / or methods is not limiting to the implementation. For this reason, the operation and behavior of the systems and / or methods are 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 descriptions herein.

[0033] Even if certain combinations of features are described 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 different from those specifically described in the claims and / or disclosed in the specification. Each of the dependent claims listed below may depend directly on only one claim, but the disclosure of possible implementations includes each dependent claim in combination with all other claims in the group of claims.

[0034] None of the elements, actions, or commands used herein should be interpreted as important or essential unless explicitly stated otherwise. 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." When only one item is intended, the term "one" or similar is used. Also, as used herein, the terms "has," "have," "having," "include," "including," etc., are intended to be open-ended terms. Furthermore, the phrase "based on" means "at least partially based on" unless explicitly stated otherwise. Furthermore, expressions such as "at least one of A and B" or "at least one of A or B" are understood to include only A, only B, or both A and B.

[0035] Embodiments of this disclosure provide a method and system for registering xApp instances in a cloud-native network such as O-RAN. In particular, the method may be implemented by a Near Real-Time (RT) Radio Access Network (RAN) Intelligent Controller (RIC). The method may include receiving a registration message from Service Management and Orchestration (SMO) containing the details of the xApp instance and the xApp identifier (ID); generating a Certificate Signing Request (CSR) containing the xApp ID to be registered in the Near RT-RIC based on the registration message; receiving a certification request message from the xApp instance; verifying the xApp instance based on the certification request message; and sending a certification response message to the xApp. In this way, the registration module can handle the private key and certificate management for the xApp, reducing the overall attack surface because the private key is not exposed. In addition, the burden on the xApp instance is reduced because the xApp instance itself does not generate a CSR (for example, the private key and certificate are stored in the registration module's memory and do not require external secure storage), and the xApp does not need to be aware of the underlying security management procedures. Thus, a more secure and efficient method for registering xApp instances may be realized.

[0036] Figure 2 shows an example of a system architecture diagram for an xApp instance registration interface 200 according to one embodiment. xApp instances may have a standardized, specific format, such as one using SPIFFE (Secure Production Identity Framework for Everyone). xApp instances may be identified using pods / containers in a cloud network. SPIFFE modules (which may be referred to here as "registration modules") and SPIFFE helper modules (which may be referred to here as "helper modules") may be provided in some embodiments.

[0037] According to one embodiment, a certificate sidecar may be used as an alternative to or improvement over a helper module for SPIFFE. The certificate sidecar may be a lightweight container running in parallel with the xApp container and may help provide pod and cluster identities to the registration module (SPIFFE module).

[0038] Referring to Figure 2, an SMO210, a near real-time RIC220, and an xApp pod 230 may be provided.

[0039] The registration module 221 operates within the near-real-time RIC 220 and, according to the embodiment, may be a SPIFFE module. During the initial registration procedure, the registration module 221 may issue certificates to the xApp instance, including but not limited to X.509 certificates. The registration module 221 may be configured to interact with the Operator Certificate Authority (CA) 240. The registration module 221 may first be instantiated on the near-real-time RIC 220 (for example, during the initialization phase).

[0040] xApp pod 230 (where the xApp instance runs) includes an xApp container 231 and a certificate sidecar 232. The certificate sidecar 232 may run within the xApp pod 230 in parallel with the xApp container 231. The certificate sidecar 232 may provide support to the registration module 221 by providing the registration module 221 with xApp instance and cluster details.

[0041] In Operation 1 (as illustrated in Figure 2), SMO210 may register the details of the xApp instance in the registration module 221.

[0042] In Operation 2 (as illustrated in Figure 2), the registration module 221 may interact with operator CA240 to generate a certificate (such as an X.509 certificate) for the xApp instance. The combination of Operations 1 and 2 may be interpreted as the registration phase (i.e., registration of the xApp instance).

[0043] In Operation 3 (as illustrated in Figure 2), SMO210 may provide the xApp module details to the xApp instance (xApp pod 230).

[0044] In Operation 4 (as illustrated in Figure 2), the certificate sidecar 232 may send an ID request to the registration module 221, which includes the pod ID and cluster details. In this way, the registration module 221 may obtain the runtime details of the xApp instance and compare them with the registered information (of the xApp instance).

[0045] In Operation 5 (as illustrated in Figure 2), if verification is successful (based on the ID request sent in Operation 4), the registration module 221 may provide the xApp instance with a certificate, private key, and trust bundle. The combination of Operations 4 and 5 may be interpreted as a verification phase.

[0046] Figures 3A to 3B show an example of a call flow diagram for xApp instance registration using a certificate sidecar according to one embodiment. An xApp instance (certificate sidecar) 300, SMO 310, registration module 320, and operator CA 330 may be provided, and may be the same as the xApp pod 230, SMO 210, registration module 221, and operator CA 240 described above, referring to Figure 2.

[0047] The operations in Figures 3A to 3B may be classified into initialization, registration, and verification operations as follows:

[0048] Initialization

[0049] Referring to Figure 3A, in Operation 1, registration module 320 (or SPIFFE module) is installed on a cloud-native (i.e., O-RAN) architecture. The workload API, registration API, and verification API may be exposed in a secure mode using Transport Layer Security (TLS).

[0050] Registration

[0051] As a prerequisite for the registration operation, the details of the xApp instance and the registration module ID (SPIFFE ID) may exist in SMO310. The details of the xApp instance may include, but are not limited to, pod information such as pod labels, image names, and image digests.

[0052] In Operation 2, SMO310 may use TLS (Server-Side Certificate Authentication) to establish a secure connection with the registration API of registration module 320.

[0053] In Operation 3, SMO310 may send instructions to registration module 320 to configure xApp instance / workload registration information in registration module 320. This may take the form of a registration message which may include xApp instance details and SPIFFE ID. Registration module 320 should be understood to operate in near-RT RIC.

[0054] In Operation 4, if the registration of the xApp instance is successful, the registration module 320 may generate a CSR on behalf of the xApp (which may include an xApp ID that identifies the xApp instance).

[0055] In Operation 5, registration module 320 may forward the CSR to operator CA330 for signing (for example, this may be done using CMPv2).

[0056] In Operation 6, Operator CA330 generates a certificate with the xApp ID in the Subject Alt Name (SAN) and issues it to Registration Module 320.

[0057] In Operation 7, the private key, certificate, and trust bundle may be stored in the registration module 320. This may, for example, use internal memory.

[0058] verification

[0059] Operation 8 may require the certificate sidecar to act as a sidecar container for xApp instance 300. This could be, for example, certificate sidecar 232 as shown in Figure 2 above.

[0060] In Operation 9, SMO310 may provide xApp instance information regarding the registered module 320 (IP address, root certificate, etc.).

[0061] As a prerequisite for the xApp instance verification operation, it may be required that a service token be generated on the cluster where the xApp instance resides. Operation 10 may, depending on the embodiment, require that a service account exists on the cluster. In this example, the scope of the service account may be limited to viewing pod and container details only, using Role-Based Access Control (RBAC) rules.

[0062] Referring now to Figure 3B, in Operation 11, the certificate sidecar of the xApp instance 300 may initiate a secure connection to the workload API of the registration module 320 (server-side authentication using certificates). This may use TLS, according to the embodiment.

[0063] In Operation 12, the certificate sidecar of xApp instance 300 may send its pod ID in an ID request message to registration module 320, as well as the cluster IP, the root certificate of the cluster where the xApp instance resides, and the service account token generated as a prerequisite in verification operation 10.

[0064] In Operation 13, registration module 320 may use the verification API to initiate a secure connection to the cluster of xApp instances 300.

[0065] In Operation 14, the registration module 320 may contact / query the cluster of xApp instances 300 to verify the pod characteristics using the verification API. This may be done based on the service account token and pod ID of xApp instances 300 received in the ID request message in verification operation 11.

[0066] In Operation 15, the registration module 320 may receive a response from the xApp instance 300 cluster based on the contact / inquiry sent in Operation 14.

[0067] In Operation 16, if the xApp instance details match the registered information (for example, those registered in Operation 4), the registration module 320 may complete the validation. For this reason, in Operation 17, the registration module 320 may send the private key, the X.509 certificate with the XApp ID (which may follow the SVID (SPIFFE verifiable identity document) format), and the trust bundle to the certificate sidecar of the xApp instance 300 in an identity response message using the workload API.

[0068] xApp instance 300 may be identified by the xApp ID present in the SAN field of the X.509 certificate. Validation criteria for identifying an xApp instance may include, but are not limited to, pod labels, pod names, image names, image IDs, container names, etc. The validation criteria for identifying an xApp instance are left to the operator depending on the specific implementation and should be understood as not being limited to these.

[0069] Secure xApp connection to near-RT RIC

[0070] According to one embodiment, the xApp instance 300 may establish a TLS connection to the Near RT RIC platform using the SVID obtained in Operation 17. The Near RT RIC can further use the xApp ID in the certificate for identification and further communication with the xApp instance 300. The xApp instance 300 may send a registration request to the Near RT RIC platform over the secured TLS connection. The Near RT RIC platform may respond with an xApp registration response message if the xApp ID matches a registration entry.

[0071] Figures 4A to 4C show an example of a call flow diagram for xApp instance registration using an agent and a server according to one embodiment. An xApp instance 400, agent 410, server 420, operator CA430, and SMO440 may be involved. The xApp instance 400, operator CA430, and SMO440 may be the same as those described with reference to Figures 2 and 3 above, and it should be understood that such descriptions may be omitted for readability.

[0072] The examples shown in Figures 4A-4C may be implemented using SPIRE, a runtime environment that is a production-ready implementation of the SPIFFE API, which utilizes node and workload certificates to securely issue SVIDs (X.509 certificates with SPIFFE IDs) to applications.

[0073] Therefore, agent 410 may specifically be a SPIRE agent, and server 420 may specifically be a SPIRE server.

[0074] Initialization

[0075] Referring to Figure 4A, in Operation 1, Server 420 (which may be a SPIRE server) may be started on the nearby RT RIC, and Agent 410 (which may be a SPIRE agent) may be started on the xApp node.

[0076] Node proof

[0077] As a prerequisite for node certification, it may be required that a set of trusted CAs be configured on Node-1 and Node-2 to establish trust during mTLS operations. In addition, it may be required that node X.509 certificates be provisioned through an out-of-band mechanism. Server 420 may be required to start and utilize the upstream authority plugin to enable integration with the existing public key infrastructure (PKI). The registration API may be required to be initialized for workload registration.

[0078] In Operation 2.i, Agent 410 may initiate an mTLS connection to Server 420 using the node certificate. In Operation 2.ii, Server 420 may respond to Agent 410 with its own certificate and chain as part of the TLS handshake.

[0079] In Operation 2.iii, Agent 410 verifies the server certificate and responds with its own node certificate.

[0080] In Operation 2.iv, the X.509 pop node attester plugin on server 420 verifies that the node certificate is rooted in the CA's trusted set and issues a signature-based proof of ownership challenge to the agent plugin to verify that the node possesses the private key. Once verified, Operation 2.v establishes a mutual TLS (mTLS) connection.

[0081] In this embodiment illustrated in Figures 4A to 4C, the node certificate may be expected to have an X.509 certificate signed by a trusted CA in the operator domain.

[0082] As an alternative embodiment to operations 2.i to 2.v, the node certificate may be self-signed or issued by the cloud network platform (i.e., Kubernetes), and the server 420 may, on behalf of the agent 410, send a CSR with the SPIFFE ID embedded in the SAN field to the operator CA 430, and the operator CA 430 may sign the CSR and return the certificate to the server 420. The server 420 may then send the certificate to the agent 410, and the agent 410 may use the certificate obtained from the server 420 to initiate an mTLS connection (operations 2.vi to 2.ix, as illustrated in Figure 4A).

[0083] Workload proof

[0084] Referring to Figure 4B, in Operation 3, the xApp instance details of xApp instance 400 may be registered from SMO440 to server 420 on the existing O1 interface.

[0085] In Operation 4, Server 420 may send the registered details to Agent 410 over the established mTLS connection.

[0086] In Operation 5.i, the xApp instance 400 on the instantiation may be initialized by a helper module to run as a sidecar container to xApp instance 400, and the workload API may be called (e.g., a UNIX domain socket). This is so that xApp instance 400 can request an SVID from agent 410. Agent 410 may then be used to perform workload certification.

[0087] In Operation 5.ii, Agent 410 queries the node's kernel and userspace cells to obtain details about xApp instance 400. Specifically, Agent 410 triggers the configured workload attester plug-in to provide them with the workload's process ID.

[0088] In Operation 5.iii, Agent 410 examines the workload to determine properties based on a relevant set of selectors. For example, if the cloud platform is Kubernetes, a k8s plugin that generates Kubernetes-based selectors (k8 selectors) may be used from the workload calling the agent. This may be done by obtaining the workload's pod ID from its cgroup membership and querying kubelet for information about the pod. It should be understood that this operation may be performed using other cloud platforms as well.

[0089] In Operation 5.iv, Agent 410 verifies the identity of the workload by cross-referencing the discovered workload selector with the registration entry.

[0090] In Operation 6, if validation in Operation 5 is successful, the SPIRE agent may generate a CSR and a private key for each workload (400 xApp instances). The CSR may have a SPIFFE ID in the SAN field.

[0091] In Operation 7, Agent 410 may send an xApp CSR to Server 420.

[0092] In Operation 8, Server 420 may send an xApp CSR to Operator CA430 for signing.

[0093] In Operation 9, Operator CA430 may provide or return the xApp instance SVID to Server 420. Again, the SVID is an X.509 certificate with a SPIFFE ID in the SAN field.

[0094] In Operation 10, Server 420 may send the workload SVID and trust bundle to Agent 410. Agent 410 may temporarily store the same information.

[0095] In Operation 11, Agent 410 may provide the xApp instance 400 with the xApp SVID and trust bundle. The xApp instance may use the SVID for further communication, such as xApp registration to the nearby RT RIC platform.

[0096] xApp registration

[0097] Referring to Figure 4C, in Operation 12, xApp instance 400 may establish a secure session with the nearby RT RIC using the SVID.

[0098] In Operation 13, a registration request message containing the xApp instance ID (which is directed from x-App instance 400 to server 420) may be sent to the RIC.

[0099] In Operation 14, after the Near RT Platform identifies the xApp in the xApp registration entry, a success registration response message may be sent back from Server 420 to the xApp instance. The RIC may also notify SMO440 of the successful deployment of the xApp.

[0100] Figure 5 shows an example flowchart of a method 500 for handling xApp instance registration according to one embodiment, particularly from the perspective of the registration module. The registration module may be the same as the registration modules 221, 320, or server 420 described above with reference to Figures 2, 3A-3B, or 4A-4C.

[0101] In Operation 501, a registration message containing the details of the xApp instance and the xApp ID may be received from the SMO (for example, SMO210, 310, 440 as described above, see Figures 2, 3A-3B, or 4A-4C). This may be similar to Operation 3 as described above, referring to Figure 3A and Operation 3 as described above, referring to Figure 4B.

[0102] In Operation 502, the CSR may be generated by the registration module. Once the CSR is generated, the registration module may forward the CSR to the operator CA for signing, and then receive a certificate containing the xApp ID from the operator CA. This may be similar to Operations 4-6, which refer to Figure 3A above, and Operations 8-9, which refer to Figure 4B above.

[0103] In Operation 503, the registration module may receive a certification request message from the xApp instance. The certification request message may be sent from a helper module of the xApp instance (for example, sidecar 232 as described with reference to Figure 2 above), and the message may include a service account token and pod ID for the xApp instance. This may be similar to Operations 11-12 as described in Figure 3B above, and Operation 13 as described in Figure 4C above.

[0104] In Operation 504, the registration module may verify the xApp instance based on the proof request message. This may be done using TLS via the validation API. This may further include querying the pod details and characteristics from the xApp instance using the service account token and pod ID in the proof request message received in Operation 503 above. This may be similar to Operations 13-16, which refer to Figure 3B above.

[0105] In Operation 505, the registration module may send a certificate response message to the xApp instance. The response message may include a private key, a certificate with an xApp ID, and a trust bundle. Specifically, the certificate may be an X.509 certificate, and the xApp ID may be an SVID. This may be the same as Operation 17, which refers to Figure 3B above, and Operation 14, which refers to Figure 4C above.

[0106] Figure 6 shows an example flowchart of a method 600 for handling xApp instance registration according to one embodiment, particularly from the perspective of the near RT-RIC or server. This may be similar to the server 420 described above with reference to Figures 4A-4C.

[0107] In Operation 601, the server may receive a CSR from an xApp instance originating from an agent (for example, agent 410, as shown in Figures 4A-4C above). The agent may be initialized on the xApp node. This may be similar to Operation 7, as shown in Figure 4B above.

[0108] In Operation 602, the server may send the CSR received in Operation 601 to the Operator CA (for example, Operator CA430, see Figures 4A-4C above) for signing. This may be the same as Operation 8, see Figure 4B above.

[0109] In Operation 603, the server may receive the xApp SVID from the Operator CA. This may be similar to Operation 9, which refers to Figure 4B above.

[0110] In Operation 604, the server may send the xApp SVID received in Operation 603 to the agent. This may be the same as Operation 10, which refers to Figure 4B above.

[0111] After receiving the xApp SVID in Operation 604, according to some embodiments, the xApp instance may establish a secure session with the nearest RT-RIC, receive a registration request message containing the xApp ID, and after the nearest RT-RIC identifies the xApp instance using the xApp registration entry, send a registration response message based on the registration request message and send a notification to the SMO that the deployment of the xApp instance was successful. These steps may correspond to Operations 11-14, which refer to Figures 4B-4C above.

[0112] Based on the above, it can be understood that the overall attack surface is reduced because the registration module can handle private key and certificate management for the xApp, thus preventing the private key from being exposed. In addition, the burden on the xApp instance is reduced because the xApp instance itself does not generate a CSR (for example, the private key and certificate are stored in the registration module's memory and do not require external secure storage), and the xApp does not need to be aware of the underlying security management procedures. Thus, a more secure and efficient method of registering xApp instances may be realized.

[0113] Figure 7 is a diagram of an example environment 700 in which the system and / or method described herein may be implemented. As shown in Figure 7, the environment 700 may include a user device 710, a platform 720, and a network 730. The devices in environment 700 may be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections. In embodiments, any functions and operations described with reference to Figures 2-6 and 9-10 may be performed by any combination of the elements illustrated in Figure 7.

[0114] User device 710 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information related to platform 720. For example, user device 710 may include computing devices (e.g., desktop computers, laptop computers, tablet computers, handheld computers, smart speakers, servers, etc.), mobile phones (e.g., smartphones, wireless phones), wearable devices (e.g., smart glasses or smartwatches), or similar devices. In some implementations, user device 710 may receive information from and / or transmit information to platform 720.

[0115] Platform 720 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information. In some implementations, Platform 720 may include a cloud server or a group of cloud servers. In some implementations, Platform 720 may be designed to be modular so that certain software components can be swapped (in or out) depending on specific needs. Thus, Platform 720 may be easily and / or quickly reconfigured for different applications.

[0116] In some implementations, as shown, platform 720 may be hosted in a cloud computing environment 722. Although the implementations described herein describe platform 720 as being hosted in a cloud computing environment 722, in some implementations, platform 720 may not be cloud-based (i.e., it may be implemented outside a cloud computing environment) or may be partially cloud-based.

[0117] The cloud computing environment 722 includes an environment that hosts platform 720. The cloud computing environment 722 may provide services that do not require end-user (e.g., user device 710) knowledge of the physical location and configuration of the systems and / or devices that host platform 720, such as computation, software, data access, and storage. As shown, the cloud computing environment 722 may also include a group of computing resources 724 (collectively referred to as “computing resources 724” and individually as “computing resources 724”).

[0118] Computing resource 724 includes one or more personal computers, a cluster of computing devices, a workstation computer, a server device, or other types of computing and / or communication devices. In some implementations, computing resource 724 may host platform 720. Cloud resources may include compute instances running in computing resource 724, storage devices provided in computing resource 724, data transfer devices provided by computing resource 724, etc. In some implementations, computing resource 724 may communicate with other computing resources 724 via wired connections, wireless connections, or a combination of wired and wireless connections.

[0119] As further shown in Figure 7, the computing resource 724 includes a group of cloud resources such as one or more applications ("APP") 724-1, one or more virtual machines ("VM") 724-2, virtualized storage ("VS") 724-3, and one or more hypervisors ("HYP") 724-4. While this embodiment refers to virtualized network functionality, one or more other embodiments are understood to be implemented in at least one of the following: containers, cloud-native services, one or more container platforms, etc. For example, in one or more other embodiments, any of the aforementioned components (e.g., nodes, E2 nodes, SMO functionality, RIC, systems, devices, etc.) may be software-based components deployed or hosted in a server cluster, such as a hybrid cloud server or data center server. The software-based components may be containerized and deployed and controlled by one or more machines called "nodes" that run containerized network elements and are addressable. In this regard, the server cluster may include at least one master node and several worker nodes. Here, the master node controls and manages the associated set of worker nodes.

[0120] Application 724-1 includes one or more software applications that may be provided to or accessed by the user device 710. Application 724-1 may eliminate the need to install and run software applications on the user device 710. For example, Application 724-1 may include any other software that can be provided via the platform 720 and its associated software and / or the cloud computing environment 722. In some implementations, one application 724-1 may send and receive information to and from one or more other applications 724-1 via a virtual machine 724-2.

[0121] The virtual machine 724-2 includes a software implementation of a device (e.g., a computer) that runs programs like a physical device. Depending on the degree to which the virtual machine 724-2 is used and its correspondence to any real-world device, the virtual machine 724-2 may be a system virtual machine or a process virtual machine. A system virtual machine may provide a complete system platform that supports the execution of a complete operating system ("OS"). A process virtual machine may run a single program or support a single process. In some implementations, the virtual machine 724-2 may run on behalf of a user (e.g., a user device 710) and manage the infrastructure of a cloud computing environment 722, such as data management, synchronization, or long-duration data transfer.

[0122] Virtualized storage 724-3 includes one or more storage systems and / or one or more devices or computing resources 724 that use virtualization technology within the storage systems. In some implementations, within the context of the storage system, the types of virtualization may include block virtualization and file virtualization. Block virtualization may represent an abstraction (or isolation) of logical storage from physical storage so that the storage system may be accessed without considering the physical storage or heterogeneous structure. Isolation can provide administrators of the storage system with flexibility in managing storage for end users. File virtualization may remove the dependency between data accessed at the file level and the location where the files are physically stored. This may enable optimized storage usage, server consolidation, and / or performance of non-destructive file migration.

[0123] The hypervisor 724-4 may provide hardware virtualization technology that enables multiple operating systems (e.g., "guest operating systems") to run simultaneously on a host computer such as computing resource 724. The hypervisor 724-4 may present a virtual operating platform to the guest operating systems and may manage the execution of the guest operating systems. Multiple instances of various operating systems may share virtualized hardware resources.

[0124] Network 730 includes one or more wired and / or wireless networks. For example, Network 730 may include cellular networks (e.g., 5G networks, LTE (long-term evolution) networks, 3G networks, CDMA (code division multiple access) networks, etc.), PLMN (public land mobile network), local area networks (LANs), wide area networks (WANs), MAN (metropolitan area networks), telephone networks (e.g., PSTN (Public Switched Telephone Network), private networks, ad hoc networks, intranets, the Internet, fiber optic networks, etc.), and / or combinations of these or other types of networks.

[0125] The number and arrangement of devices and networks shown in Figure 7 are provided as an example. In practice, there may be additional devices and / or networks, fewer devices and / or networks, different devices and / or networks, or devices and / or networks in different arrangements than those shown in Figure 7. Furthermore, two or more devices shown in Figure 7 may be implemented within a single device, and a single device shown in Figure 7 may be implemented as multiple distributed devices. In addition or alternatively, a set of devices in environment 700 (e.g., one or more devices) may perform one or more functions that are described as being performed by other sets of devices in environment 700.

[0126] Figure 8 shows an example of the components of device 800. Device 800 may correspond to user device 710 and / or platform 720. As shown in Figure 8, device 800 may include a bus 810, a processor 820, memory 830, a storage component 840, an input component 870, an output component 860, and a communication interface 870.

[0127] Bus 810 includes components that enable communication between components of device 800. Processor 820 may be implemented in hardware, firmware, or a combination of hardware and software. Processor 820 may be a central processing unit (CPU), graphics processing unit (GPU), acceleration unit (APU), microprocessor, microcontroller, digital signal processor (DSP), FPGA (field-programmable gate array), ASIC (application-specific integrated circuit), or other types of processing components. In some implementations, processor 820 includes one or more processors that are programmable to perform functions. Memory 830 includes random access memory (RAM), read-only memory (ROM), and / or other types of dynamic or static storage devices (e.g., flash memory, magnetic memory, and / or optical memory) that store information and / or instructions for use by processor 820.

[0128] The storage component 840 stores information and / or software related to the operation and use of device 800. For example, the storage component 840 may include, along with a corresponding drive, a hard disk (e.g., magnetic disk, optical disk, magneto-optical disk, and / or solid-state disk), a compact disk (CD), a digital versatile disk (DVD), a floppy disk, a cartridge, magnetic tape, and / or other types of non-temporary computer-readable media. The input component 870 includes components that enable device 800 to receive information via user input (e.g., a touchscreen display, keyboard, keypad, mouse, buttons, switches, and / or a microphone). In addition or alternatively, the input component 870 may include sensors for measuring information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, and / or actuators). The output component 860 includes components that provide output information from device 800 (e.g., a display, a speaker, and / or one or more light-emitting diodes (LEDs)).

[0129] The communication interface 870 includes transceiver-like components (e.g., a transceiver and / or separate receiver and transmitter) that enable device 800 to communicate with other devices via wired connections, wireless connections, or a combination of wired and wireless connections. The communication interface 870 enables device 800 to receive information from and / or provide information to other devices. For example, the communication interface 870 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a Universal Serial Bus (USB) interface, a Wi-Fi interface, a cellular network interface, and the like.

[0130] Device 800 may execute one or more processes described herein. Device 800 may execute these processes depending on a processor 820 that executes software instructions stored in a non-temporary computer-readable medium such as memory 830 and / or storage component 840. The computer-readable medium is defined herein as a non-temporary memory device. A memory device includes a memory space within a single physical storage device or a memory space distributed across multiple physical storage devices.

[0131] Software instructions may be read into memory 830 and / or storage component 840 from other computer-readable media or other devices via the communication interface 870. When executed, the software instructions stored in memory 830 and / or storage component 840 may cause the processor 820 to execute one or more processes described herein.

[0132] In addition, or instead of, wired circuits may be used to execute one or more of the processes described herein, either in place of or in combination with software instructions. Thus, the implementations described herein are not limited to any particular combination of hardware circuits and software.

[0133] The number and arrangement of components shown in Figure 8 are provided as an example. In practice, device 800 may include additional components, fewer components, different components, or components in different arrangements than those shown in Figure 8. In addition or alternatively, a set of components of device 800 (e.g., one or more components) may perform one or more functions that are described as being performed by other sets of components of device 800.

[0134] In the embodiments, any operation or process in Figures 2-6 and 9-10 may be implemented by or using any elements illustrated in Figures 7 and 8. Other embodiments are understood to be, but are not limited thereto, and may be implemented in a variety of different architectures (e.g., bare metal architecture, any cloud-based architecture, or deployment architectures such as Kubernetes, Docker, or OpenStack).

[0135] The foregoing disclosures are illustrative and descriptive, but are not intended to be exhaustive or to limit implementations to the exact forms disclosed. Modifications and variations are possible in light of the foregoing disclosures or may be derived from the execution of implementations.

[0136] Some embodiments may also relate to systems, methods, and / or computer-readable media at a technical level of any possible integration. Furthermore, one or more of the above components may be implemented as instructions that are stored on a computer-readable medium and are executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include a computer-readable non-temporary storage medium (or medium) that stores computer-readable program instructions for causing a processor to perform an operation.

[0137] A computer-readable storage medium may be a tangible device capable of holding and storing instructions for use by an instruction execution device. A computer-readable storage medium may, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital multipurpose disks (DVDs), memory sticks, floppy disks, mechanically encoded devices such as punch cards or grooves on which instructions are recorded, or any suitable combination thereof. The computer-readable storage medium used herein is not to be interpreted as a transient signal itself, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmitting media (e.g., light pulses passing through fiber optic cables), or electrical signals transmitted through wires.

[0138] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computing / processing device, or downloaded to an external computer or external storage device via a network such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and transfers them to storage in the computer-readable storage medium within each computing / processing device.

[0139] The computer-readable program code / instructions for performing the operation may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk and C++, procedural programming languages ​​such as the C programming language, or similar programming languages. The computer-readable program instructions may be executed as a standalone software package, either entirely on the user's computer, partially on the user's computer, partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or wide area network (WAN), and the connection may be to an external computer (for example, via the Internet using an Internet Service Provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, an FPGA (field-programmable gate array), or a programmable logic array (PLA) may execute computer-readable program instructions by utilizing state information of computer-readable program instructions to personalize the electronic circuit in order to perform a side or operation.

[0140] These computer-readable program instructions may be provided to a general-purpose computer, a dedicated computer, or a processor of another programmable data processing device to generate a device such that instructions executed via the processor of a computer or other programmable data processing device generate means for implementing functions / actions described in flowcharts and / or block diagrams (one or more blocks). These computer-readable program instructions may be stored on a computer-readable storage medium on which the instructions are stored, which can be instructed to make a computer, a programmable data processing device, and / or other device function in a particular manner such that the storage medium containing the instructions has a creation containing instructions that implement aspects of functions / actions described in flowcharts and / or block diagrams (one or more blocks).

[0141] These computer-readable program instructions may be loaded onto a computer, other programmable device, or other device so that a series of operational operations are executed on the computer, other programmable device, or other device to generate a computer-implemented process in which instructions executed on the computer, other programmable device, or other device implement the functions / actions described in the flowchart and / or block diagram (one or more blocks).

[0142] The illustrated flowcharts and block diagrams illustrate the architecture, functions, and operations of possible implementations of systems, methods, and computer-readable media according to various embodiments. Here, each block in the flowchart or block diagram may represent a microservice, module, segment, or portion of instructions comprising one or more executable instructions to implement a particular logical function. The methods, computer systems, and computer-readable media may include additional blocks, fewer blocks, different blocks, or different arrangements of blocks than those shown in the diagrams. In some alternative implementations, the functions shown in the blocks may occur outside the order shown in the diagrams. For example, two blocks shown consecutively may actually be executed simultaneously or substantially simultaneously, depending on the functions involved, or the blocks may be executed in reverse order. Note that each block in the illustrated block diagrams and / or flowcharts, and combinations of blocks in the illustrated block diagrams and / or flowcharts, may be implemented by a system based on dedicated hardware that performs a particular function or action, or by executing a combination of dedicated hardware and computer instructions.

[0143] It is evident that the systems and / or methods described herein may be implemented in different forms of hardware, firmware, or combinations of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not limited to the implementation. Thus, the operation and behavior of the systems and / or methods are 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 descriptions herein.

[0144] Further embodiments may be discussed below.

[0145] xApp standard identity management during the xApp registration process

[0146] Introduction

[0147] The RT RIC platform identifies and assigns xApp IDs to xApps deployed on that platform. However, for applications in cloud-native environments, there is no universally established identity that is programmatically interpretable and better suited to identifying workloads in cloud-native environments.

[0148] The solution proposes using SPIFFE (Secure Production Identity Framework), a universal service identity control plane for distributed systems. This identity is designed for cloud-native and zero-trust architectures.

[0149] This also complies with NIST SP 800-207A, which states that service identities should not be exposed to impersonation and should be continuously verifiable. An example of a workload identity is a SPIFFE ID, which is encoded as a Uniform Resource Identifier (URI) and carried in a cryptographically verifiable document called a SPIFFE Verifiable Identity Document (SVID).

[0150] SPIRE is a production-ready implementation of the SPIFFE API that uses node and workload certifications to securely issue SVIDs [X.509 certificate with SPIFFE ID] to applications that may be used for service-to-service communication.

[0151] The main SPIFFE specification modules used in the solution are as follows: 1. SPIFFE ID: A standard URI format based on RFC 3986 with specific conditions. [EXAMPLE: spiffe: / / domain-name / clusterName / namespace / xAppName] 2. SVID (SPIFFE Verifiable Identity Document): A cryptographically verifiable document used to prove the identity of a service to its peers. It uses existing formats such as X509 certificates and JWT tokens. 3. Trust Bundle: The CA certificate chain (root certificate and intermediate certificates) that entities use to verify SVIDs. 4. SPIRE Agent and Server: The SPIRE agent is deployed on the node where the xApp is deployed. The SPIRE server module is deployed on the near-RT RIC platform. 5. An optional certificate sidecar / [SPIFFE Helper] container with an xApp instance pod for handling key and certificate management.

[0152] As part of the xApp registration process within the Near-RT RIC platform, the xApp instance uses a SPIFFE ID to register within the platform, allowing the platform to interpret the xApp instance's identity via the structured SPIFFE ID format.

[0153] Figure 9 shows an example of a system architecture used in a solution according to this embodiment.

[0154] Solution details

[0155] The steps outlining the solution are detailed below.

[0156] Step 1: Define the stakeholders, roles, and prerequisites for the xApp registration process. • xApp instance pod: xApp application, certificate sidecar originator for certificate and key management (optional). • SPIRE Agent: Oversees identity management and performs workload validation within the system. • SPIRE Server in the Near-RT RIC Platform: Handles registration-related messages from / to xApp. A central component responsible for identity management and identity credential issuance.

[0157] Prerequisites: As a prerequisite, the xApp instance node should have the IP address of the nearest RT RIC platform and the trust anchor information details from the provisioning system.

[0158] Step 2: Node Verification: Establishing a channel to secure the SPIRE agent and SPIRE server. 2.i The SPIRE agent initiates mTLS with the server for verification. In this step, the SPIRE agent uses a node certificate, which may be a certificate issued by Kubernetes or signed by the operator. Steps 2.ii to 2.iv detail the procedure for a node certificate signed by the operator CA. 2.ii The SPIRE server responds to the SPIRE agent with its own certificate and chain. 2.iii The agent verifies the server certificate and responds with its own node certificate. 2.iv The x509 pop node attester plugin on the SPIRE server verifies that the certificate is rooted to the CA's trusted set and that the node possesses the private key. The TLS connection is established successfully. 2.v For Kubernetes issuance certificates, the additional steps in 2.vi to 2.ix should be taken. 2. The SPIRE server generates the CSR on behalf of the SPIRE agent and sends it to the operator CA for signing. 2.vii The operator CA signs the CSR and sends the SVID [X.509 certificate with SPIFFE ID in the SAN field] to the SPIRE server. 2.viii The SPIRE server sends a trust bundle to the SPIRE agent over the existing mTLS connection. 2.ix The SPIRE agent re-establishes the mTLS connection with the newly received SVID.

[0159] Step 3: Workload registration entry on the SPIRE server: As previously mentioned, the SMO maps the RIC variables, instructs the O-Cloud DMS to generate the xApp deployment, and allocates the necessary resources on the nearby RT RIC. As part of this procedure, the SMO sends an xApp registration entry to the nearby RT RIC via its O1 interface. It maps a structured SPIFFE ID to each xApp instance, allowing the nearby RT RIC to identify the deployed xApp and manage its lifecycle.

[0160] Example: Registration entries for two xApp instances [Table 1]

[0161] Step 4: Registration entry in the agent for SVID issuance: The SPIRE server sends the workload (xApp) registration entry details to the SPIRE agents registered on it.

[0162] Step 5: Workload Certification: The workload XApp instance is instantiated. Additionally, an optional component of the sidecar container is instantiated to handle the certificate and key management of the xApp instance, potentially reducing the load on the xApp instance for security-related functions. 5.i The xApp instance pod communicates with the SPIRE agent over a Unix domain socket. 5.ii The SPIRE agent utilizes a combination of kernel and userspace calls to gather supplemental information about the workload. The agent queries the node's kernel to identify the caller's process ID. It then invokes configured workload attester plugins and provides them with the workload's process ID. This process, through its cgroup associations, identifies the workload's pod ID and subsequently retrieves information about the pod. 5.iii The agent examines the workload to determine its properties based on the set of selectors associated with it. 5.iv The SPIRE agent verifies the identity of the workload by cross-referencing the discovered workload selector with the registration entry.

[0163] Step 6: Generate CSR: If the validation in Step 5 is successful, the SPIRE agent generates a CSR and a private key for each workload (xApp). The CSR has a SPIFFE ID in the SAN field. The SPIFFE agent obtains a SPIFFE ID that uniquely identifies each xApp instance from the registration entry in Step 4.

[0164] Step 7: The SPIRE agent sends the xApp CSR to the SPIRE server.

[0165] Step 8: CSR Signing: Now the SPIRE server sends the xApp CSR to the operator CA for signing.

[0166] Step 9: Operator PKI: The operator CA provides the SPIRE server with an xApp SVID. The SVID is an X.509 certificate with a SPIFFE ID in the SAN field.

[0167] Step 10: The SPIRE server sends the xApp SVID [X.509 Certificates with SPIFFE ID] and trust bundle, which will be stored in memory for a short period of time.

[0168] Step 11: SVID Issuance: Next, the SPIRE agent provides the xApp SVID and trust bundle to the certificate sidecar. The xApp instance then uses the SVID for further communication, such as xApp registration to the near real-time RIC platform.

[0169] Note: The xApp instance establishes a secure session with the nearest RT RIC, in accordance with the prerequisites mentioned in Step 1.

[0170] Step 12: The xApp instance sends a registration request to the nearby RT RIC platform over the secured TLS connection. The xApp instance should be able to extract the xApp ID from the X.509 certificate and include it in its registration message.

[0171] Step 13: When the xApp ID matches the registration entry, the Near RT RIC platform responds with an xApp registration response message.

[0172] Step 14: Optional: Near-RT RIC notifies SMO of the successful deployment of xApp.

[0173] The solution proposes that the xApp ID use a structured ID format for SPIFFE IDs that can be interpreted programmatically. The mechanism introduced does not rely on information from the xApp to determine the xApp ID. Unix socket-based communication is used for process-to-process communication within the node. An optional sidecar container for key and certificate management reduces the attack surface on the application.

[0174] Figures 10A to 10F show an example of an xApp registration procedure using the SPIFFE framework according to the embodiment.

[0175] evaluation

[0176] The following proposal uses a cloud-native solution for service identity management of applications in a cloud-native environment, which is compliant with NIST 800-207A

[41] . SPIRE is a production-ready implementation of the SPIFFE API that uses node and workload certifications to securely issue SVIDs [X.509 certificate with SPIFFE ID] to applications that may be used for service-to-service communication. Standardized identity can be provided to applications such as xApps using SPIRE agents and servers in an O-RAN environment. The SVID issued to the xApp can be used to establish a secure connection with the near-RT RIC platform. The xApp ID can be obtained from the SAN field of the X.509 certificate.

[0177] Various aspects of the embodiment

[0178] Various further aspects and features of the embodiments of this disclosure may be defined by the following items. Item 1: A method implemented by a near real-time (RT) radio access network (RAN) intelligent controller (RIC), Receiving a registration message from Service Management and Orchestration (SMO) that includes the details of the xApp instance and the xApp identifier (ID), Based on the registration message, a certificate signing request (CSR) including the xApp ID to be registered in the nearby RT-RIC is generated, The xApp instance receives a certificate request message, Based on the aforementioned certification request message, the xApp instance is verified, Sending a proof response message to the aforementioned xApp instance, A method that includes this. Item 2: The operator transfers the aforementioned CSR to the Certificate Authority (CA) for signing, Receiving a certificate with the xApp ID from the aforementioned operator CA, The method described in item 1, which further includes the following. Item 3: Validating the xApp instance is performed via the validation API using Transport Layer Security (TLS) as described in item 1 or 2. Item 4: The aforementioned certification request message includes a service account token and a pod identifier (ID) for the xApp instance, as described in any of items 1 to 3. Item 5: Verifying the xApp instance based on the aforementioned proof request message is: Using the aforementioned service account token and pod ID, query the pod details and characteristics from the xApp instance, The pod details and characteristics of the xApp instance are compared with the registered information of the xApp instance. The method described in item 4, which further includes the following. Item 6: The certificate response message includes a private key, a certificate with the xApp ID, and a trust bundle, as described in any of items 1 to 5. Item 7: The aforementioned certificate is an X.509 certificate, The aforementioned xApp ID is a SPIFFE (Secure Production Identity Framework for Everyone) verifiable identity document (SVID). The method described in item 6. Item 8: A method implemented by a near real-time (RT) radio access network (RAN) intelligent controller (RIC), The server receives a Certificate Signing Request (CSR) containing the xApp identifier (ID) for the xApp instance originating from the agent, The server sends the CSR to the Operator Certificate Authority (CA) for signing, The server receives an xApp SPIFFE (Secure Production Identity Framework for Everyone) verifiable identity document (SVID) from the operator CA, The server sends the xApp SVID to the agent, Includes, A method by which, upon receiving the xApp SVID, the agent provides the xApp instance with the xApp SVID and a trust bundle. Item 9: The server is initialized on the nearby RT-RIC, The agent is initialized on the xApp node. The method described in item 8. Item 10: The xApp instance uses the xApp SVID to establish a secure session with the nearby RT-RIC. The server receives a registration request message including the xApp ID, After the aforementioned RT-RIC identifies the xApp instance using the xApp registration entry, the server sends a registration response message based on the registration request message. The server sends a notification to the Service Management and Orchestration (SMO) that the deployment of the xApp instance was successful. The method described in item 9, which further includes the following. Item 11: Near Real-Time (RT) Wireless Access Network (RAN) Intelligent Controller (RIC), Receiving a registration message from Service Management and Orchestration (SMO) that includes the details of the xApp instance and the xApp identifier (ID), Based on the registration message, a certificate signing request (CSR) including the xApp ID to be registered in the nearby RT-RIC is generated, The xApp instance receives a certificate request message, Based on the aforementioned certification request message, the xApp instance is verified, Sending a proof response message to the aforementioned xApp instance, A near-RT-RIC configured to perform the following actions. Item 12: The operator transfers the aforementioned CSR to the Certificate Authority (CA) for signing, Receiving a certificate with the xApp ID from the aforementioned operator CA, The near-RT-RIC described in item 11 is further configured to perform the following: Item 13: Validating the aforementioned xApp instance is performed via the validation API using Transport Layer Security (TLS), as described in item 11 or 12, for the Near RT-RIC. Item 14: The aforementioned certification request message includes a service account token and pod identifier (ID) for the xApp instance, as specified in any of items 11 to 13 of the Near RT-RIC. Item 15: Using the aforementioned service account token and pod ID, query the pod details and characteristics from the xApp instance, The pod details and characteristics of the xApp instance are compared with the registered information of the xApp instance. The Near RT-RIC described in item 14 is further configured to verify the xApp instance based on the aforementioned proof request message. Item 16: The aforementioned certificate response message includes the private key, the certificate with the xApp ID, and the trust bundle, as described in any of items 11 to 15 of the Near-RT-RIC. Item 17: The aforementioned certificate is an X.509 certificate, The aforementioned xApp ID is a SPIFFE (Secure Production Identity Framework for Everyone) verifiable identity document (SVID). Near-RT-RIC as described in item 16. Item 18: Near Real-Time (RT) Wireless Access Network (RAN) Intelligent Controller (RIC), Receiving a Certificate Signing Request (CSR) containing the xApp identifier (ID) for an xApp instance originating from the agent, Sending the aforementioned CSR to the Operator Certificate Authority (CA) for signing, The operator CA receives an xApp SPIFFE (Secure Production Identity Framework for Everyone) verifiable identity document (SVID), To the agent, the xApp SVID is sent, It is configured to perform, Upon receiving the xApp SVID, the agent provides the xApp instance with the xApp SVID and a trust bundle via the Near RT-RIC. Item 19: The server is initialized on the aforementioned near RT-RIC, The agent is initialized on the xApp node. Near-RT-RIC as described in item 18. Item 20: The xApp instance uses the xApp SVID to establish a secure session with the nearby RT-RIC. Receiving a registration request message containing the aforementioned xApp ID, The aforementioned RT-RIC, after identifying the xApp instance using the xApp registration entry, sends a registration response message based on the registration request message. To send a notification to the Service Management and Orchestration (SMO) that successfully deployed the aforementioned xApp instance, The near-RT-RIC described in item 19 is further configured to perform the following:

[0179] In light of the above teachings, it can be understood that many modifications and variations of this disclosure are possible. It is clear that this disclosure may be implemented in a manner different from those specifically described herein, within the scope of the attached items.

Claims

1. A method implemented by a near real-time (RT) radio access network (RAN) intelligent controller (RIC), Receiving a registration message from Service Management and Orchestration (SMO) that includes xApp instance details and xApp identifier (ID), Based on the registration message, a certificate signing request (CSR) including the xApp ID to be registered in the nearby RT-RIC is generated, The xApp instance receives a certificate request message, Based on the aforementioned certification request message, the xApp instance is verified, Sending a proof response message to the aforementioned xApp instance, A method for providing this.

2. The operator transfers the aforementioned CSR to the Certificate Authority (CA) for signing, Receiving a certificate with the xApp ID from the aforementioned operator CA, The method according to claim 1, further comprising:

3. The method according to claim 1, wherein the validation of the xApp instance is performed via a validation API using transport layer security (TLS).

4. The method according to claim 1, wherein the certification request message includes a service account token and a pod identifier (ID) for the xApp instance.

5. Verifying the xApp instance based on the aforementioned proof request message is: Using the aforementioned service account token and pod ID, query the pod details and characteristics from the xApp instance, The pod details and characteristics of the xApp instance are compared with the registered information of the xApp instance. The method according to claim 4, comprising:

6. The method according to claim 1, wherein the certificate response message includes a private key, a certificate with the xApp ID, and a trust bundle.

7. The aforementioned certificate is an X.509 certificate, The aforementioned xApp ID is a SPIFFE (Secure Production Identity Framework for Everyone) verifiable identity document (SVID). The method according to claim 6.

8. A method implemented by a near real-time (RT) radio access network (RAN) intelligent controller (RIC), The server receives a Certificate Signing Request (CSR) containing the xApp identifier (ID) for the xApp instance originating from the agent, The server transmits the CSR to the Operator Certificate Authority (CA) for signing, The server receives the xApp SPIFFE (Secure Production Identity Framework for Everyone) verifiable identity document (SVID) from the operator CA, The server sends the xApp SVID to the agent, Equipped with, A method by which, upon receiving the xApp SVID, the agent provides the xApp instance with the xApp SVID and a trust bundle.

9. The server is initialized on the nearby RT-RIC, The agent is initialized on the xApp node. The method according to claim 8.

10. The xApp instance uses the xApp SVID to establish a secure session with the nearby RT-RIC. The server receives a registration request message including the xApp ID, After the aforementioned RT-RIC identifies the xApp instance using the xApp registration entry, the server sends a registration response message based on the registration request message. The server sends a notification to the Service Management and Orchestration (SMO) that the deployment of the xApp instance was successful. The method according to claim 9, further comprising:

11. Near Real-Time (RT) Wireless Access Network (RAN) Intelligent Controller (RIC), Receiving a registration message from Service Management and Orchestration (SMO) that includes xApp instance details and xApp identifier (ID), Based on the registration message, a certificate signing request (CSR) including the xApp ID to be registered in the nearby RT-RIC is generated, The xApp instance receives a certificate request message, Based on the aforementioned certification request message, the xApp instance is verified, Sending a proof response message to the aforementioned xApp instance, A near-RT-RIC configured to perform the following actions.

12. The operator transfers the aforementioned CSR to the Certificate Authority (CA) for signing, Receiving a certificate with the xApp ID from the aforementioned operator CA, The near-RT-RIC according to claim 11, further configured to perform the following:

13. The near-RT-RIC according to claim 11, wherein the verification of the xApp instance is performed via a validation API using Transport Layer Security (TLS).

14. The near-RT-RIC according to claim 11, wherein the certification request message includes a service account token and a pod identifier (ID) for the xApp instance.

15. Using the aforementioned service account token and pod ID, query the pod details and characteristics from the xApp instance, The pod details and characteristics of the xApp instance are compared with the registered information of the xApp instance. The near-RT-RIC according to claim 14, further configured to verify the xApp instance based on the certificate request message.

16. The near-RT-RIC according to claim 11, wherein the certificate response message includes a private key, a certificate with the xApp ID, and a trust bundle.

17. The aforementioned certificate is an X.509 certificate, The aforementioned xApp ID is a SPIFFE (Secure Production Identity Framework for Everyone) verifiable identity document (SVID). The near-RT-RIC according to claim 16.

18. Near Real-Time (RT) Wireless Access Network (RAN) Intelligent Controller (RIC), Receiving a Certificate Signing Request (CSR) containing the xApp identifier (ID) for an xApp instance originating from the agent, Sending the aforementioned CSR to the Operator Certificate Authority (CA) for signing, The operator CA receives an xApp SPIFFE (Secure Production Identity Framework for Everyone) verifiable identity document (SVID), To the agent, the xApp SVID is sent, It is configured to perform, Upon receiving the xApp SVID, the agent provides the xApp instance with the xApp SVID and a trust bundle via the Near RT-RIC.

19. The server is initialized on the aforementioned near RT-RIC, The agent is initialized on the xApp node. The near-RT-RIC according to claim 18.

20. The xApp instance uses the xApp SVID to establish a secure session with the nearby RT-RIC. Receiving a registration request message containing the aforementioned xApp ID, The aforementioned RT-RIC, after identifying the xApp instance using the xApp registration entry, sends a registration response message based on the registration request message. To send a notification to the Service Management and Orchestration (SMO) that successfully deployed the aforementioned xApp instance, The near-RT-RIC according to claim 19, further configured to perform the following:

Images