WO2025259334A1 - Key distribution between open fronthaul (ofh) media access control security (macsec) endpoints - Google Patents

Abstract

A method (400) is disclosed. The method includes establishing (402), at an Open Radio Access Network (O-RAN)-Radio Unit Controller (O-RU Controller), a session with an O-RU. In response to establishment of the session, the method includes configuring (404), at the O-RU controller one or more Media Access Control security (MACsec) configuration parameters for the O-RU. The one or more MACsec configuration parameters comprises at least a pre-shared key. The method also includes generating (406), at the O-RU controller, using a random number generator, at least one of a Secure Authentication Key (SAK) and a Key Encryption Key (KEK) based on the pre-shared key. Moreover, the method includes transmitting (408), from the O-RU controller to the O-RU, at least one of the one or more MACsec configuration parameters and the at least one of the SAK and the KEK.

Description

KEY DISTRIBUTION BETWEEN OPEN FRONTHAUL (OFH) MEDIA ACCESS CONTROL SECURITY (MACSEC) ENDPOINTS

CROSS-REFERENCE TO RELATED APPLICATION (S)

[0001] This application claims priority to Indian provisional application 202411044763, filed on June 10, 2024; and Indian non-provisional application 202411044763, filed December 26, 2024; the entire contents of which are incorporated herein by reference.

FIELD

[0002] The present disclosure relates to key distribution between Open Fronthaul (OFH) Media Access Control Security (MACsec) endpoints.

BACKGROUND

[0003] The information disclosed in this background section is only for enhancement of understanding of the general background of the disclosure and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art.

[0004] In Open Radio Access Network (O-RAN) architecture, an Open Fronthaul (OFH) interface connects an O-RAN Distributed Unit (O-DU) of a radio baseband to an O-RAN Radio Unit (O-RU). The OFH interface constitutes a Control plane, a User plane, and a Synchronization plane (collectively referred to as the CUS-Plane) over an evolved Common Public Radio Interface (eCPRI). The OFH interface may also include a Management Plane (M- Plane) over a Transmission Control Protocol (TCP) for message exchange between the O-DU and the O-RU. Fronthaul traffic, between the O-RU and the O-DU, is directly encapsulated over Ethernet, thus exposing the Fronthaul traffic of the O-RAN to Layer 2 threats and vulnerabilities. This significantly threatens the operation of the O-RAN. Accordingly, it is important to have Layer 2 security mechanism(s) in place to protect the Fronthaul traffic.

[0005] Currently, there is no protection of the OFH interface for the CUS-Plane in the Layer 2. Media Access Control Security (MACsec) has been discussed in O-RAN standards for a while as a solution to protect some of the Layer 2 traffic in OFH. The MACsec is a Layer 2 security protocol providing data confidentiality, frame data integrity, and authenticity of data origin. For example, the MACsec ensures that data transmitted over the Ethernet is protected from eavesdropping, denial of service, passive monitoring, and tampering. However, due to implementation and deployment challenges, the MACsec as a security solution for Precision Time Protocol (PTP) messages may not be recommended for the Fronthaul network. For instance, an end-to-end tunnel mode MACsec does not have a standardized key management and distribution scheme defined.

[0006] Therefore, another important security mechanism to be considered is the IEEE 1588- 2019 Authentication Type-Length- Value (TLV) for securing the S-Plane. However, key management and distribution is considered to be an important aspect even for such a security mechanism.

SUMMARY

[0007] 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 invention nor is it intended to determine the scope of the disclosure.

[0008] Disclosed herein is an apparatus. The apparatus is configured to establish, at an Open Radio Access Network (O-RAN)-Radio Unit Controller (0-RU Controller), a session with an 0-RU. In response to the establishment of the session, the apparatus is configured to configure, at the O-RU controller one or more Media Access Control security (MACsec) configuration parameters for the O-RU. The one or more MACsec configuration parameters comprises at least a pre-shared key. The apparatus is also configured to generate, at the O-RU controller, using a random number generator, at least one of a Secure Authentication Key (SAK) and a Key Encryption Key (KEK) based on the pre-shared key. Moreover, the apparatus is configured to transmit, from the O-RU controller to the O-RU, at least one of the one or more MACsec configuration parameters and the at least one of the SAK and the KEK.

[0009] Disclosed herein is a method. The method includes establishing, by an Open Radio Access Network (O-RAN)-Radio Unit Controller (O-RU Controller), a session with an O-RU. In response to establishing the session, the method includes configuring, by the O-RU controller, one or more Media Access Control security (MACsec) configuration parameters for the O-RU. The one or more MACsec configuration parameters comprises at least a pre-shared key. The method also includes generating, by the O-RU controller, using a random number generator, at least one of a Secure Authentication Key (SAK) and a Key Encryption Key (KEK) based on the pre-shared key. Moreover, the method includes transmitting, by the O-RU controller to the O-RU, at least one of the one or more MACsec configuration parameters and the at least one of the SAK and the KEK.

[0010] Disclosed herein is a non-transitory computer-readable medium storing instructions. The instructions comprise one or more instructions that are executed by an Open Radio Access Network (O-RAN)-Radio Unit Controller (O-RU Controller). The O-RU controller comprises one or more processors. The one or more instructions cause the one or more processors to establish a session with an O-RU. In response to the establishment of the session, the one or more instructions cause the one or more processors to configure one or more Media Access Control security (MACsec) configuration parameters for the O-RU. The one or more MACsec configuration parameters comprises at least a pre-shared key. The one or more instructions also cause the one or more processors to generate, using a random number generator, at least one of a Secure Authentication Key (SAK) and a Key Encryption Key (KEK) based on the preshared key. Moreover, the one or more instructions cause the one or more processors to transmit, to the O-RU, at least one of the one or more MACsec configuration parameters and the at least one of the SAK and the KEK.

[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 THE DRAWINGS

[0012] Features, aspects, and advantages of 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 components of an Open Radio Access Network (O-RAN) architecture, in accordance with an embodiment of the present disclosure;

FIGs. 2a, 2b, and 2c depict a signal flow diagram related to the operation of establishing an end-to-end Media Access Control security (MACsec) tunnel between an O-RAN Radio Unit (O-RU) and an O-RAN Distributed Unit (O-DU), in accordance with one or more embodiments of the present disclosure; FIGs. 3a, 3b, and 3c depict a signal flow diagram related to key management and distribution between the O-RU and the O-DU for IEEE 1588-2019 Authentication Type-Length-Value (TLV), in accordance with one or more embodiments of the present disclosure;

FIG. 4 illustrates a flowchart depicting a method for key distribution between Open Fronthaul (OFH) MACsec endpoints, in accordance with an embodiment of the present disclosure; and FIG. 5 illustrates an embodiment of a 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 present disclosure provides illustrations and descriptions, 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 present disclosure or may be acquired from 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, the flowchart and description of operations provided below relate to at least one of the embodiments in the present disclosure. It should be noted that it is possible to make other embodiments that do not exactly match the flowchart and its description. It is understood that in other embodiments 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).

[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 should not limit their implementations. 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 description herein.

[0015] Even though particular combinations of features are recited in the claims and/or disclosed in the specification, the particular combinations are not intended to limit the disclosure of implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification. Even if a dependent claim directly depends on only one claim, the present disclosure may indicate that the dependent claim is dependent on other claims 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” (in other words, nouns not mentioned in the plural) are intended to include one or more items, and may be used interchangeably with “one or more.” 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] An Open Fronthaul (OFH) interface has high requirements for delay, time, latency, and performance. Due to such factors, implementing Media Access Control security (MACsec) for encrypting a Synchronization Plane (S-Plane), which requires hop-by-hop encryption, may be considered unviable in certain scenarios. Instead, in certain scenarios, an IEEE 1588-2019 authentication type, length, and value (TLV) may be recommended for securing S-Plane Precision Time Protocol (PTP) messages. Thus, effective key management and distribution are crucial for a security mechanism used to secure the S-Plane PTP messages. However, one of the main challenges in securing the S-Plane is lack of available key distribution mechanisms for establishing IEEE 1588 Authentication TLV security mechanism(s), which have not yet been made available or discussed in the standards.

[0018] The MACsec was considered as a potential security solution for the OFH interface. However, implementing the MACsec could present at least three challenges, i.e., all OFH network elements would have to be MACsec aware which is not a cost-effective solution, an impact of the MACsec on the performance of different OFH topologies and protocols, and deployment and implementation challenges of using the MACsec to secure the S-Plane.

[0019] As a result, there exists a need for an important security mechanism (either in addition to or as an alternative to the MACsec mechanism) which is the IEEE 1588-2019 Authentication TLV mechanism for securing the S-Plane. Further, key management and distribution are considered to be an important aspect of the security mechanism as well.

[0020] Accordingly, there exists a need to protect Fronthaul traffic transmitted over Ethernet networks from at least: eavesdropping, denial of service, passive monitoring, and tampering, through usage of the MACsec while overcoming the at least two above-mentioned challenges related to the usage of the MACsec. Further, in addition to the above need or as an alternative to the above need, there exists a need to secure the S-Plane through usage of the IEEE 1588- 2019 Authentication TLV while overcoming the challenges (due to delays, time, latency, and performance issues that may be associated with the implementation of the MACsec for encrypting the S-Plane), as stated above.

[0021] The present disclosure relates to key distribution between Open Fronthaul (OFH) MACsec endpoints. Particularly, the present disclosure introduces configuration and enabling of the MACsec, and key management for the OFH network elements of an Open-Random Access Network (0-RAN) Distributed Unit (0-DU) and an 0-RAN Radio Unit (0-RU) using a Management-Plant (M-Plane) Network Configuration (NETCONF) Protocol configuration and pre-shared keys. The present disclosure also provides for generation of a Secure Association Key (SAK) and sharing of the SAK to the OFH network elements by a NETCONF Controller.

[0022] FIG. 1 illustrates components of an 0-RAN architecture 100, in accordance with one or more embodiments of the present disclosure. As shown in FIG. 1, the O-RAN architecture 100 may include a cell site 102 that may in turn include one or more antennas 102-2, and one or more O-RUs 102-4, 102-6, and 102-8. The O-RAN architecture 100 may further include a Core Network (CN) 104 that may in turn include an O-DU 104-2, and one or more Operations and Control Unit Control Planes (O-CU-CPs) 104-4 and one or more Operations and Control Unit User Planes (O-CU-UPs) 104-6. The O-RAN architecture 100 may furthermore include an Open-RAN Intelligent Controller (O-RIC) 106 that may in turn include a Near real-time RAN intelligent controller (RIC) 106-4 (near RT-RIC 106-4), and a Non-near-real-time RIC 106-2 (non RT-RIC 106-2). The O-RAN architecture 100 may additionally include a mobile Backhaul network 108.

[0020] The O-RAN is believed to revolutionize next-generation mobile networks at least by disassembling proprietary components of conventional RAN via hardware-software disaggregation and by further enabling a vendor-neutral interoperable ecosystem through open interfaces. Understanding the O-RAN including its architecture and key techniques is fundamental in the wireless networking area. An overview of the O-RAN is provided below. Further, key enabling techniques in the O-RAN are also discussed below.

[0021] The O-RAN has a potential to provide multi-vendor interoperability, cost/time-efficient RAN deployment, and big data-enabled intelligence. The conventional RANs, however, are far from open. The conventional RANs comprise proprietary hardware and software supplied by only a few vendors as highly integrated solutions with little interoperability. Such a solution has severely hindered evolution of mobile networks in the following aspects:

• vendor “lock-in” which disables an open, multi-vendor ecosystem and further prevents innovation and new business opportunities,

• inefficient, mostly manual, reconfigurability to accommodate diverse traffic applications which range from band-intensive video gaming to low-rate Internet of Things (loT) communication, and

• limited controllability of different network components which cannot host joint management and optimization.

[0022] To address these issues, transition towards the O-RAN has been seen. The O-RAN architecture disaggregates between hardware and software, hosts virtualized network functions in the cloud, and connects networking components via open interfaces interoperable across various vendors. The O-RAN further makes it possible to incorporate big data and artificial intelligence (AI)/machine learning (ML) for automation and intelligent control of the RAN. Compared to the conventional RANs, the O-RAN significantly improves the scalability of RAN deployment and reduces Capital Expenditure (CAPEX) and Operational Expenditure (OPEX).

[0023] The realization of the O-RAN faces several challenges including standardization, real- world performance validation, and potential threats. However, the rapidly growing volume and variety of mobile traffic have led to technology trends to make the RAN increasingly open and intelligent.

[0024] The O-RAN is proposed based on two essential pillars: further disaggregation and openness. FIG. 1 shows an embodiment of the O-RAN architecture 100, in accordance with one or more embodiments of the present disclosure. Disaggregation between hardware and software enables different functionalities to be designed, extended, and configured via commercial-off-the-shelf (COTS) hardware and software-defined technology. The open interfaces further eliminate the vendor “lock-in” by allowing the multi-vendor RAN deployments.

[0025] Further, the key enabling techniques for the 0-RAN include the disaggregation, the O- RIC 106, and the open interfaces.

[0026] With respect to the disaggregation, the O-RAN architecture 100, as presented in FIG. 1, may disaggregate base stations (BSs) into three major building blocks: the one or more O- RUs 102-4, 102-6, and 102-8, the 0-DU 104-2, and the O-CU-CP 104-4, and the O-CU-CP 104-6 (may also be collectively referred to as the O-CUs 104-4, 104-6). In the conventional RANs, Baseband Units (BBU) functionalities are split into the DU and the CU, while Remote Radio Heads (RRH) functionalities are mostly handled by the RU. In the 0-RAN context, the RU, the DU, and the CU have become the 0-RU, the 0-DU, and the O-CU respectively. The one or more O-RUs 102-4, 102-6, and 102-8, are used for radio frequency (RF) signal transmission and reception, amplification, analog/digital conversion, and beamforming of a physical (PHY) layer. The one or more O-RUs 102-4, 102-6, and 102-8 are deployed near or integrated into the antenna(s) 102-2. The O-DU 104-2 handles the remaining PHY layer, a Medium Access Control (MAC) layer, and a Radio Link Control (RLC) layer, as operations of the remaining PHY layer, the MAC layer, and the RLC layer are tightly synchronized. The O- DU 104-2 is usually physically close to the one or more O-RUs 102-4, 102-6, and 102-8, and the operations of the one or more O-RUs 102-4, 102-6, and 102-8 are controlled by the one or more O-CUs 104-4 and 104-6. The one or more O-CUs 104-4 and 104-6 in the O-RAN are further split into logical elements for a Control Plane (CP) and a User Plane (UP) respectively, enabling separate deployments on different hardware platforms. The one or more O-CUs 104- 4 and 104-6, run higher layers including a Radio Resource Control (RRC) layer, a Service Data Adaptation Protocol (SDAP) layer, and a Packet Data Convergence Protocol (PDCP) layer. The one or more O-CUs 104-4 and 104-6 are located in or near the CN 104.

[0027] Further, the one or more O-RICs 106 are another key element in the O-RAN architecture 100. The O-RICs 106 are software-defined components capable of orchestrating and optimizing functions of the O-RAN with closed-loop control. Functionality of the O-RIC 106 can be realized by Virtualized Network Functions (VNFs) and Software-Defined Networking (SDN), where the former creates a cloud environment and software application infrastructure for the O-RIC 106 and the latter allows applications for network management.

[0028] The O-RIC 106, according to O-RAN vision, can be either the non- RT RIC 106-2, or the near-RT RIC 106-4. The non-RT RIC 106-2 orchestrates events with an operation scale longer than 1 second, whereas the near-RT RIC 106-4 typically takes 10 milliseconds to 1 second to complete optimization actions.

[0029] Furthermore, the open interfaces for the RANs are not new. Third Generation Partnership Project (3 GPP) has standardized two interfaces: an air interface and an SI interface. The 3GPP also defines, in addition to the open interfaces, an X2 Interface as an optional interface to support information exchange between the two or more BSs. However, the X2 interfaces are not open and have not been largely implemented.

[0030] While two open interfaces exist, they are not sufficient to enable the O-RAN. First of all, an interface between the O-RUs 102-4, 102-6, and 102-8, and the O-DU 104-2 (known as Fronthaul) relies heavily on a Common Public Radio Interface (CPRI) protocol. The CPRI protocol is generally vendor-specific and thus not necessarily open. As a result, the open interfaces are required for the Fronthaul for development of the O-RAN. Second, the O-RAN architecture splits the virtualized BBU into the one or more O-CUs 104-4 and 104-6, and the O-DU 104-2. Therefore, a similar demand for the open interfaces applies to O-CU and 0-DU connections.

[0031] As discussed above, opening the RAN introduces simultaneously flexibility and complexity. However, potential attacks on different components of the O-RAN (e.g., open software and interfaces) at multiple layers need to be taken into consideration. For example, there could be threats against an open cloud, an open-source code, and an overall system and physical infrastructure. Accordingly, there is a need to consider key security objectives at each layer (especially at Layer 2) and standardize corresponding security policies to possible threats. The present disclosure provides a mechanism to standardize security policies to possible threats for the Layer 2.

[0032] FIGs. 2a, 2b, and 2c depict a signal flow diagram 200 related to an operation of establishing an end-to-end MACsec tunnel between the one or more O-RUs 102-4, 102-6, and 102-8, and the 0-DU 104-2, in accordance with one or more embodiments of the present disclosure. In particular, FIGs. 2a, 2b, and 2c relate to an introduction of configuration and enabling of the MACsec, and the key management for the OFH network elements of the 0-DU 104-2, and the one or more O-RUs 102-4, 102-6, and 102-8, the M-Plane Network Configuration (NETCONF), and the pre-shared keys. Also, the O-RIC (e.g., the NETCONF Controller) 106 may generate the SAK and share the SAK with the OFH network elements. In this approach, the following paragraphs will describe the signal flow diagram 200 related to the operation of establishing the end-to-end MACsec tunnel among the one or more O-RUs 102-4, 102-6, and 102-8, and the O-DU 104-2. The sequence flow diagram 200 may illustrate a sequence of operations between an O-RU 202, an O-RU Controller 204, and an operator Public Key Infrastructure (PKI) Certificate Authority (CA) 206. The O-RU 202 may correspond to the one or more O-RUs 102-4, 102-6, and 102-8, and the O-RU Controller 204 may correspond to the O-DU 104-2 and/or the O-RIC 106 including the non— RT RIC 106-2 and the near-RT RIC 106-4.

[0033] At step S208, in one or more embodiments, the O-RU 202 searches for factory preprovisioned Vendor X.509 certificates with MAC address and stores the same in extensions.

[0034] At step S210, the O-RU 202 may be powered “ON” using one or more techniques known in the art. Next, at step S212, the O-RU 202 may successfully authenticate using an IEEE 802. lx standard. For example, on powering “ON”, the O-RU 202 (that supports the IEEE 802. lx) may perform an Extensible Authentication Protocol -Transport Layer Security (EAP- TLS) authentication with a valid operator-signed certificate. The O-RU 202 that does not have the valid operator-signed certificate may use a manufacturer installed certificate for the EAP- TLS authentication.

[0035] In case the EAP-TLS authentication fails, the O-RU 202 may block traffic for unsuccessful IEEE 802. lx operation at step S214. Optionally, at step S216, the O-RU 202 may enroll at the operator PKI CA 206 and install the operator certificates. Then, at step S218, the O-RU 202 may reinitialize and perform the restart procedure (by jumping to step S210).

[0036] Further, through steps S220-S230, the O-RU 202 may call home and begin registering to the O-RU Controller 204 (e.g., the NETCONF controller). Specifically, at step S220, a Transmission Control Protocol (TCP) session may be established as a NETCONF CALL HOME REGISTER procedure. Furthermore, at step S222, TLS sessions may be established with the operator certificates (e.g., the operator signed X.509 certificates). In addition, at step S224, one or more NETCONF sessions may be established. Additionally, at step S226, configuration and software management of the O-RU 202 may be realized by the O-RU Controller (e.g., a NETCONF/TLS SERVER) 204. For example, as a part of the configuration and software management procedure, the O-RU Controller (e.g., NETCONF controller) 204 may enable the MACsec on the O-RU 202, configure a pre-shared key (e.g., a pre-shared root key) that includes a Connectivity Association Key Name (CKN) and its own Connectivity Association Key (CAK). This is the first step to establish a secure MACsec link between the two OFH network elements. Next, at step S228, configuration of the MACsec may require one or more parameters such as a MACSec Key Agreement (MKA) + MACsec, the O-RU MAC- Address, the pre-shared key, a key priority, the CKN, a Key Server Priority [configured as 0], a Secure Channel Identifier (SCI) (e.g., a SCI-Association Number), a Member Identifier (MI), and a Key Number. The one or more MACsec configuration parameters are generated or obtained by the O-RU Controller 204. Further, the MKA+MACsec is enabled using IEEE 802.1x-types yang configuration with peer MAC -address defined to ensure that packets are tunneled through a network environment to reach a destined peer which in this case is the O- RU 202.

[0037] Further, at step S230, the O-RU Controller 204 may provision the O-RU 202, with the one or more MACsec configuration parameters.

[0038] In addition, through steps S232-S240, the generation of the SAK may be performed at the O-DU 104-2 (i.e., the O-RU Controller 204) using an Internet Engineering Task Force (lETF)-NETCONF -KEYSTORE model. Further, for the generation and configuration of the key, the IETF -NETCONF -KEYS TORE model may be used as a centralized key store mechanism. The lETF-NETCONF-KEYSTORE model supports various types of keys (e.g., Rivest-Shamir-Adleman (RSA), Digital Signature Algorithm (DSA), and Elliptic Curve Digital Signature Algorithm (ECDSA)); and certificates (e.g., X.509). The centralized keystore mechanism allows for the import and export of the keys and the certificates, facilitating interoperability and secure key distribution. For example, at step S232, the O-RU Controller 204 may use a keystore container for configuring symmetric keys or asymmetric keys for the SAK generation. In one embodiment, an additional Key Encryption Key (KEK) is also derived from the existing CAK. Further, at step S234, the O-RU Controller 204 may generate the SAK using a strong Random Number Generation (RNG) and store the generated SAK in the keystore container encrypted using the KEK. Encrypting Keys in Configuration (clause 4) in NETCONF key store allows for generation of the encryption key (e.g., the KEK) that can be used to secure the SAK. Root key(s) configured through the O-RU Controller 204 and the keystore container enables other security mechanism(s) to use the root key(s) either for a new key derivation or use that for encryption.

[0039] Further, step S236 relates to security consideration. In particular, the SAK may be securely distributed by the 0-DU 104-2 to the O-RU 202, which have been successfully authenticated using the IEEE 802. lx, and a NETCONF active session is established. Further, the keys in the keystore container are encrypted during transit of the Fronthaul traffic. Furthermore, at step S238, the 0-DU 104-2 may provision the SAK at the O-RU 202 using a NETCONF secured channel. In addition, at step S240, the end-to-end MACsec tunnel is established, between the 0-DU 104-2 and the O-RU 202, with the keys provisioned through the O-RU Controller (NETCONF controller) 204 providing encryption of messages between the 0-DU 104-2 and the O-RU 202, as per IEEE 802.1 AE.

[0040] In one or more embodiments, the MKA may use Extensible Authentication Protocol over Local Area Network (EAPoL) as a transport protocol to transmit MKA messages. By default, the EAPoL uses a destination multicast MAC address of 01 :80:c2:00:00:03 to multicast packets to multiple destinations. The EAPoL is a standards-based protocol and other authentication mechanisms such as the IEEE 802. IX also use the same protocol. Devices in a service provider cloud might consume this packet (based on the destination multicast MAC address) try to process the EAPoL packet and eventually drop the packet. This causes MKA session to fail. Also, this methodology is not applicable for the end-to-end tunnel mode concept. Using the EAPoL destination-address command to change the destination MAC address of the EAPoL packet that is transmitted on an interface towards the service provider, ensures that the service provider tunnels the packet like any other data packet instead of consuming them. This ensures that the packets are not dropped.

[0041] Some of the technical advantages provided by the present disclosure are:

• The transport network elements need not be MACsec capable and aware, and the CUS- and M-Plane messages are encrypted.

• Further, the key management solution in this case is secure and does not rely on the MACsec Key Agreement protocol defined in the IEEE 802. lx for enabling the MACsec in a point-to-point scenario.

• Furthermore, using the same key management procedure, the root key(s) can be used for deriving the keys for other security mechanism(s).

[0042] One of the variations of the present disclosure that may work in different scenarios or use cases is that the O-RIC 106 which can be either a Service Management Operation (SMO) or the 0-DU 104-2 could act as an entity to provision the MACsec configuration parameters for the 0-DU 104-2, and the one or more O-RUs 102-4, 102-6, and 102-8. In hybrid mode of operation, one of the SMO or the 0-DU 104-2 (or both) can provide different MACsec configuration parameters.

[0043] FIGs. 3a, 3b, and 3c depict a signal flow diagram 300 related to key management and distribution between the one or more O-RUs 102-4, 102-6, and 102-8, and the 0-DU 104-2 for the IEEE 1588-2019 Authentication TLV, in accordance with one or more embodiments of the present disclosure. In particular, the key management and distribution between the one or more

O-RUs 102-4, 102-6, and 102-8, and the O-DU 104-2 described by means of FIGs. 3a, 3b, and 3c illustrate another variation to the key management and distribution between the one or more O-RUs 102-4, 102-6, and 102-8, and the O-DU 104-2, as described by means of FIGs. 2a, 2b, and 2c. FIGs. 3a, 3b, and 3c are directed towards configuring the root key through the IETF- NETCONF key store and allowing the one or more O-RUs 102-4, 102-6, and 102-8, and the O-DU 104-2 to derive the SAK through a key derivation function (KDF). In this scenario, the KDF functionality may reside at the one or more O-RUs 102-4, 102-6, and 102-8, and/or at the O-DU 104-2.

[0044] Further, the root key or the pre-shared key transferred through this mechanism may be used for the key management and distribution for solutions like the IEEE 1588-2019 Authentication TLV. FIGs. 3a, 3b, and 3c relate to the introduction of configuration and enabling of the IEEE 1588-2019 Authentication TLV, and the key management for the OFH network elements of the O-DU 104-2, and the one or more O-RUs 102-4, 102-6, and 102-8, the M-Plane Network Configuration (Netconf) configuration, and the pre-shared keys. Also, the O-RIC (e.g., NETCONF Controller) 106 may generate the SAK and may share the SAK with the OFH network elements. In this approach, the following paragraphs will describe the signal flow diagram 300 related to the operation of the key management and distribution among the one or more O-RUs 102-4, 102-6, and 102-8, and the O-DU 104-2 for the IEEE 1588-2019 Authentication TLV. The sequence flow diagram 300 may illustrate a sequence of operations between the O-RU 202, the O-RU Controller 204, and the operator PKI CA 206. The O-RU 202 may correspond to the one or more O-RUs 102-4, 102-6, and 102-8, and the O-RU Controller 204 may correspond to the O-DU 104-2 and/or the O-RIC 106 including the non-

RT RIC 106-2 and the near-RT RIC 106-4. [0045] Steps S302-S320 of FIGs. 3a and 3b are similar to steps S208-S226 of FIGs. 2a and 2b, and therefore, the description of steps S302-S320 of FIGs. 3a and 3b are not described here again for the sake of brevity of the disclosure.

[0046] At step S322, the 0-RU Controller 204 (e.g., the 0-DU 104-2) may configure the root key to be shared with the 0-RU 202. Then, at step S324, the 0-RU Controller 204 may provision the root key at the 0-RU 202 using the NETCONF secured channel.

[0047] Further, through steps S326-S334, the key configuration at the 0-RU 202 and the O- RU Controller 204 (i.e., the 0-DU 104-2) using the IETF -NEFCONF -KEYS TORE model may be performed. In particular, step S326 includes configuring, by at least the 0-RU Controller 204, the symmetric keys or asymmetric keys as per the steps S322 and S324 using the keystore. Further, step S328 includes provisioning, by 0-RU Controller 204, the root key at the 0-RU 202 using the NETCONF Secured channel. As a part of the key configuration management procedure, the 0-RU Controller 204 may configure the root key on the 0-RU 202. In one or more embodiments, the root key may then be used to derive the encryption keys for the other security mechanism(s). In one or more embodiments, the root key may be used as the preshared key for the encryption of the messages.

[0048] Then, at step S330, the 0-RU 202 may derive the keys for the encryption. Further, step S332 may be related to the security consideration. At step S332, the keys may be distributed to the 0-RU 202 which has been successfully authenticated using 802. lx, and the NETCONF active session is established. Further, the keys in the keystore container are encrypted during the transit. Further, step S334 includes using the keys derived at the 0-RU 202 for the security mechanism procedure using the IEEE 1588-2019 Authentication TLV.

[0049] FIG. 4 illustrates a flowchart depicting a method 400 for the key distribution between the OFH MACsec endpoints, in accordance with one or more embodiments of the present disclosure. The method 400 may be performed by the 0-RU Controller 204. The 0-RU Controller 204 may correspond to one or more of the 0-DU 104-2 and the O-RIC 106 including the non-RT RIC 106-2 and the near-RT RIC 106-4.

[0050] At step 402, the O-RU Controller 204 may establish a session with the 0-RU 202. At step 404, in response to establishing the session, the 0-RU Controller 204 may configure the one or more MACsec configuration parameters for the 0-RU 202. In an embodiment, the one or more MACsec configuration parameters may comprise at least the pre-shared key. In one embodiment, the one or more MACsec configuration parameters may comprise one or more of an MKA-MACsec indication, the O-RU MAC-address, the key priority, the CKN, and the key number. The MKA-MACsec indication may indicate support of the MACsec for the O-RU 202. The O-RU MAC-address may correspond to an address for the O-RU 202 to implement the MACsec. The key priority may indicate an entity to generate the at least one of the SAK and KEK. The CKN may correspond to a name for the CAK. The key number may indicate a number associated with the pre-shared key to be used for generation of the at least one of the SAK and KEK.

[0051] At step 406, the O-RU Controller 204 may generate, using a random number generator, at least one of the SAK and the KEK based on the pre-shared key. At step 408, the O-RU Controller 204 may transmit, to the O-RU 202, at least one of the one or more MACsec configuration parameters and the at least one of the SAK and the KEK.

[0052] In one embodiment, prior to establishing the session with the O-RU 202, the O-RU Controller 204 may receive a session establishment request. In an embodiment, the session establishment request corresponds to a NETCONF call home register request.

[0053] In one embodiment, in response to establishing the session with the O-RU 202, the O- RU Controller 204 may transmit, to the O-RU 202, one or more configuration commands to instruct the O-RU 202 to perform one or more configuration changes at the O-RU 202. In an embodiment, the one or more configuration corresponds to at least one a configuration and an application corresponding to the MACsec configuration.

[0054] In one embodiment, for generating the at least one of the SAK and the KEK, the O-RU Controller 204 may configure at least one of the one or more symmetric keys and the one or more asymmetric keys using the keystore container, generate the at least one of the SAK and the KEK based on configured at least one of the one or more symmetric keys and the one or more asymmetric keys.

[0055] While the above-discussed steps in FIG. 4 are shown and described in a particular sequence, the steps may occur in variations to the sequence in accordance with various embodiments. Further, a detailed description related to the various steps of FIG. 4 is already covered in the description related to FIG. 2a-FIG.3c and is omitted herein for the sake of brevity.

[0056] FIG. 5 illustrates an embodiment of a wireless communication device 500, in accordance with one or more embodiments of the present disclosure. In an embodiment, the wireless communication device 500 may correspond to one or more of the one or more O-RU 102-4, 102-6, and 102-8, the O-DU 104-2, and the O-RIC 106. As shown in FIG. 5, the wireless communication 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.

[0057] The processor 510, as used herein, means any type of computational circuit that may comprise hardware elements and software elements. Processor 510 may be embodied as a multi-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. 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.

[0058] Memory 520 may include a non-transitory computer readable medium. Memory 520 may include a random-access memory (RAM), 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. Memory 520 may include machine-readable instructions which are executable by processor 510. These machine-readable instructions when executed by processor 510 may cause processor 510 to perform one or more method steps of an embodiment described above.

[0059] Storage component 530 may store information and/or software related to the operation and use of the wireless communication device 500. For example, 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] Input component 540 may be configured to receive information, such as user input. For example, 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, or alternatively, 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] Output component 550 may be configured to provide output information from the wireless communication device 500. For example, output component 550 may be, but not limited to, a display, a speaker, an instruction device to an external device, and/or one or more light-emitting diodes (LEDs).

[0062] Communication interface 560 may be an interface that provides a communication connection to other devices, such as external devices and internal devices. The connection by 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 wireless communication device 500 and other devices. In other words, the standard of communication interface 560 is not limited.

[0063] Bus 570 may act as an interconnect between processor 510, memory 520, storage component 530, input component 540, output component 550, and communication interface 560 of the wireless communication device 500. 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, 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 device 500 may perform one or more functions described as being performed by another set of components of 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.

[0065] An apparatus is described. The apparatus is configured to establish, at an Open Radio Access Network (O-RAN)-Radio Unit Controller (O-RU Controller), a session with an O-RU. In response to the establishment of the session, the apparatus is configured to configure, at the O-RU controller, one or more Media Access Control security (MACsec) configuration parameters for the O-RU. The one or more MACsec configuration parameters comprises at least a pre-shared key. The apparatus is also configured to generate, at the O-RU controller, using a random number generator, at least one of a Secure Authentication Key (SAK) and a Key Encryption Key (KEK) based on the pre-shared key. Moreover, the apparatus is configured to transmit, from the O-RU controller to the O-RU, at least one of the one or more MACsec configuration parameters and the at least one of the SAK and the KEK.

[0066] The apparatus as described in [0065], wherein prior to establishing the session with the O-RU, the apparatus is configured to: receive, at the O-RU-controller, a session establishment request from the O-RU, wherein the session establishment request corresponds to a Network Configuration (NetConf) call home register request.

[0067] The apparatus as described in any of [0065]-[0066], wherein to generate the at least one of the SAK and the KEK, the apparatus is configured to: configure, using a keystore container, at least one of one or more symmetric keys and one or more asymmetric keys; and generate the at least one of the SAK and the KEK based on configured at least one of the one or more symmetric keys and the one or more asymmetric keys.

[0068] The apparatus as described in any of [0065]-[0067], wherein in response to establishment of the session with the O-RU, the apparatus is configured to: transmit, to the O-RU, one or more configuration commands to instruct the O-RU to perform one or more configuration changes at the O-RU. [0069] The apparatus as described in any of [0065]-[ 0068], wherein the one or more configuration changes correspond to at least one a configuration and an application associated with one or more MACsec configuration parameters.

[0070] The apparatus as described in any of [0065]-[ 0069], wherein: the one or more MACsec configuration parameters comprises one or more of a MASsec Key agreement-MACsec (MKA-MACsec) indication, an O-RU MAC-address, a key priority, a Connectivity Association Key Name (CKN), and a key number, the MKA-MACsec indication indicates support of MACsec for the O-RU, the O-RU MAC-address corresponds to an address for O-RU to implement MACsec, the key priority indicates an entity to generate the at least one of the SAK and KEK, the CKN corresponds to a name for the CAK, and the key number indicates a number associated with the pre-shared key to be used for generation of the at least one of the SAK and KEK.

[0071] A method is described. The method includes establishing, by an Open Radio Access Network (O-RAN)-Radio Unit Controller (O-RU Controller), a session with an O-RU. In response to establishing the session, the method includes configuring, by the O-RU controller, one or more Media Access Control security (MACsec) configuration parameters for the O-RU. The one or more MACsec configuration parameters comprises at least a pre-shared key. The method also includes generating, by the O-RU controller, using a random number generator, at least one of a Secure Authentication Key (SAK) and a Key Encryption Key (KEK) based on the pre-shared key. Moreover, the method includes transmitting, by the O-RU controller to the O-RU, at least one of the one or more MACsec configuration parameters and the at least one of the SAK and the KEK. [0072] The method as described in [0071], wherein prior to establishing the session with the

0-RU, the method comprises: receiving, by the O-RU-controller, a session establishment request, wherein the session establishment request corresponds to a Network Configuration (NetConf) call home register request.

[0073] The method as described in any of [0071]-[0072], wherein generating the at least one of the SAK and the KEK comprises: configuring, by the 0-RU controller, at least one of one or more symmetric keys and one or more asymmetric keys using a keystore container; and generating the at least one of the SAK and the KEK based on configured at least one of the one or more symmetric keys and the one or more asymmetric keys.

[0074] The method as described in any of [0071]-[0073], wherein in response to establishing the session with the O-RU, the method comprises: transmitting, to the O-RU, one or more configuration commands to instruct the O-RU to perform one or more configuration changes at the O-RU.

[0075] The method as described in any of [0071]-[0074], wherein the one or more configuration corresponds to at least one a configuration and an application corresponding to MACsec configuration.

[0076] The method as described in any of [0071]-[0075], wherein: the one or more MACsec configuration parameters comprises one or more of a MASsec Key agreement-MACsec (MKA-MACsec) indication, an O-RU MAC-address, a key priority, a Connectivity Association Key Name (CKN), and a key number, the MKA-MACsec indication indicates support of MACsec for the O-RU, the O-RU MAC-address corresponds to an address for O-RU to implement MACsec, the key priority indicates an entity to generate the at least one of the SAK and KEK, the CKN corresponds to a name for the CAK, and the key number indicates a number associated with the pre-shared key to be used for generation of the at least one of the SAK and KEK.

[0077] A non-transitory computer-readable medium storing instructions is described. The instructions comprises one or more instructions that are executed by an Open Radio Access Network (O-RAN)-Radio Unit Controller (O-RU Controller). The O-RU controller comprises one or more processors. The one or more instructions cause the one or more processors to establish a session with an O-RU. In response to establishment of the session, the one or more instructions cause the one or more processors to configure one or more Media Access Control security (MACsec) configuration parameters for the O-RU. The one or more MACsec configuration parameters comprises at least a pre-shared key. The one or more instructions also cause the one or more processors to generate, using a random number generator, at least one of a Secure Authentication Key (SAK) and a Key Encryption Key (KEK) based on the preshared key. Moreover, the one or more instructions cause the one or more processors to transmit, to the O-RU, at least one of the one or more MACsec configuration parameters and the at least one of the SAK and the KEK.

[0078] 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.

[0079] 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.

[0080] 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.

[0081] Benefits, 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.

[0082] 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 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. An apparatus configured to: establish, at an Open Radio Access Network (O-RAN)-Radio Unit Controller (O-RU Controller), a session with an O-RU; in response to establishment of the session, configure, at the O-RU controller one or more Media Access Control security (MACsec) configuration parameters for the O-RU, wherein the one or more MACsec configuration parameters comprises at least a pre-shared key; generate, at the O-RU controller, using a random number generator, at least one of a Secure Authentication Key (SAK) and a Key Encryption Key (KEK) based on the pre-shared key; and transmit, from the O-RU controller to the O-RU, at least one of the one or more MACsec configuration parameters and the at least one of the SAK and the KEK.

2. The apparatus as claimed in claim 1, wherein prior to establishing the session with the O-RU, the apparatus is configured to: receive, at the O-RU-controller, a session establishment request from the O-RU, wherein the session establishment request corresponds to a Network Configuration (NetConf) call home register request.

3. The apparatus as claimed in claim 1, wherein to generate the at least one of the SAK and the KEK, the apparatus is configured to: configure, using a keystore container, at least one of one or more symmetric keys and one or more asymmetric keys; and generate the at least one of the SAK and the KEK based on configured at least one of the one or more symmetric keys and the one or more asymmetric keys.

4. The apparatus as claimed in claim 1, wherein in response to establishment of the session with the O-RU, the apparatus is configured to: transmit, to the O-RU, one or more configuration commands to instruct the O-RU to perform one or more configuration changes at the O-RU.

5. The apparatus as claimed in claim 4, wherein the one or more configuration changes corresponds to at least one a configuration and an application associated with one or more MACsec configuration parameters.

6. The apparatus as claimed in claim 1, wherein: the one or more MACsec configuration parameters comprises one or more of a MASsec Key agreement-MACsec (MKA-MACsec) indication, an O-RU MAC-address, a key priority, a Connectivity Association Key Name (CKN), and a key number, the MKA-MACsec indication indicates support of MACsec for the O-RU, the O-RU MAC-address corresponds to an address for O-RU to implement MACsec, the key priority indicates an entity to generate the at least one of the SAK and KEK, the CKN corresponds to a name for the CAK, and the key number indicates a number associated with the pre-shared key to be used for generation of the at least one of the SAK and KEK.

7. A method comprising: establishing, by an Open Radio Access Network (O-RAN)-Radio Unit Controller (O-

RU Controller), a session with an O-RU; in response to establishing the session, configuring, by the O-RU controller, one or more Media Access Control security (MACsec) configuration parameters for the O-RU, wherein the one or more MACsec configuration parameters comprises at least a pre-shared key; generating, by the O-RU controller, using a random number generator, at least one of a Secure Authentication Key (SAK) and a Key Encryption Key (KEK) based on the pre-shared key; and transmitting, by the O-RU controller to the O-RU, at least one of the one or more MACsec configuration parameters and the at least one of the SAK and the KEK.

8. The method as claimed in claim 7, wherein prior to establishing the session with the O- RU, the method comprises: receiving, by the O-RU-controller, a session establishment request, wherein the session establishment request corresponds to a Network Configuration (NetConf) call home register request.

9. The method as claimed in claim 7, wherein generating the at least one of the SAK and the KEK comprises: configuring, by the O-RU controller, at least one of one or more symmetric keys and one or more asymmetric keys using a keystore container; and generating the at least one of the SAK and the KEK based on configured at least one of the one or more symmetric keys and the one or more asymmetric keys.

10. The method as claimed in claim 7, wherein in response to establishing the session with the 0-RU, the method comprises: transmitting, to the 0-RU, one or more configuration commands to instruct the O-RU to perform one or more configuration change at the O-RU.

11. The method as claimed in claim 10, wherein the one or more configuration corresponds to at least one a configuration and an application corresponding to MACsec configuration.

12. The method as claimed in claim 7, wherein: the one or more MACsec configuration parameters comprises one or more of a MASsec Key agreement-MACsec (MKA-MACsec) indication, an O-RU MAC-address, a key priority, a Connectivity Association Key Name (CKN), and a key number, the MKA-MACsec indication indicates support of MACsec for the O-RU, the O-RU MAC-address corresponds to an address for O-RU to implement MACsec, the key priority indicates an entity to generate the at least one of the SAK and KEK, the CKN corresponds to a name for the CAK, and the key number indicates a number associated with the pre-shared key to be used for generation of the at least one of the SAK and KEK.

13. A non-transitory computer-readable medium storing instructions, the instructions comprising: one or more instructions that, when executed by an Open Radio Access Network (O-RAN)-Radio Unit Controller (O-RU Controller), the O-RU controller comprising one or more processors, cause the one or more processors to: establish a session with an O-RU; in response to establishment of the session, configure one or more Media Access Control security (MACsec) configuration parameters for the O-RU, wherein the one or more MACsec configuration parameters comprises at least a pre-shared key; generate, using a random number generator, at least one of a Secure Authentication Key (SAK) and a Key Encryption Key (KEK) based on the pre- shared key; and transmit, to the O-RU, at least one of the one or more MACsec configuration parameters and the at least one of the SAK and the KEK.