Determining authentication state information for O-RAN radio units

Abstract

Features are provided for determining authentication state information for an open radio access network (O-RAN) radio unit (O-RU). According to an embodiment, an O-RU controller may be configured to: acquire a media access control (MAC) address of an O-RU; determining an authentication state of the O-RU based on the MAC address of the O-RU; establishing a channel binding with the O-RU based on determining that the O-RU has been authenticated; and isolating the O-RU from another communication with the O-RU controller based on a determination that the O-RU has not been authenticated.

Description

Cross Reference to Related Applications

[0001] This application claims priority to, and incorporates by reference the entire disclosure of each of: (a) PCT Patent Application PCT / US2023 / 026301 entitled “SYSTEM AND METHOD FOR ADVERTISING SUPPLICANTS IN A NETWORK” filed on June 27, 2023, and (b) PCT Patent Application PCT / US2023 / 026303 entitled “SYSTEM AND METHOD FOR ESTABLISHING A TOPOLOGY FOR ADVERTISING SUPPLICANTS IN A NETWORK” filed on June 27, 2023. TECHNICAL FIELD

[0002] Systems, apparatuses, methods, and computer programs consistent with example embodiments of the present disclosure relate to telecommunications networks, and more specifically to enabling a network entity to determine authentication status information for open RAN (O-RAN) wireless units (O-RUs) in a telecommunications network. BACKGROUND

[0003] A radio access network (RAN) is an important component in a telecommunications system as it connects end user devices (or user equipment) to other parts of the network. A RAN includes a combination of various network elements (NEs) that connect end users to a core network. Traditionally, the hardware and / or software of a particular RAN is vendor specific. Open RAN (O-RAN) technology has emerged to enable multiple vendors to provide hardware and / or software to a telecommunications system. Due to the involvement of different vendors, the types of hardware and / or software provided can also vary. That is, different types of NEs can be provided by different vendors, and depending on the particular service, the NEs can be virtualized in software form (e.g., virtual machine (VM) based, containerized, or cloud native, etc.) or can be in physical hardware form (e.g., non-VM based).

[0004] An open fronthaul network of a telecommunications system can be based on an O-RAN architecture. The open fronthaul network can include O-RAN radios (O-RUs) and O-RU controllers (e.g., O-RAN distributed units (O-DUs), service management and orchestrators (SMOs), etc.). The O-RU controllers can provide services or controls to the O-RUs, such as establishing secure communication sessions, providing information for network protocol configuration (NETCONF), and so on. Multiple O-RUs can be communicatively coupled to one O-RU controller via one or more transport network elements (TNEs), such as router(s), switch(es), etc. The elements in the open fronthaul network (e.g., O-RUs, TNEs, O-RU controllers, etc.) can be collectively referred to herein as “network entities.”

[0005] Figure 1 A block diagram illustrating an example of a general system architecture 100 of an open fronthaul network in the prior art is shown. As shown, the network entities of the open fronthaul network can include O-RUs 110, TNEs 120, and O-RU controllers 130. The O-RUs 110 can be communicatively coupled to the O-RU controllers 130 via the TNEs 120. The communications between the network entities 110, 120, and 130 can include point-to-point LAN segments / communications. Figure 1

[0006] The network entities can employ an IEEE 802. lx port-based network access control (PNAC) authentication procedure (which can be referred to herein as an “802. lx procedure”) to regulate access to the network and to prevent parties of unknown or unauthorized identity from transmitting and receiving, and the consequent network disruption, service theft, or data loss. In this regard, the network entities can have the roles of supplicant or requestor. Data traffic is only allowed to pass between the network entities when the network entities are authenticated via the 802. lx procedure. In the 802. lx procedure, a first network entity (e.g., an O-RU) can be a requestor that initiates the 802. lx procedure, and a second network entity (e.g., a TNE) can be a supplicant that controls the first network entity’s access to an authentication server that performs the 802. lx procedure on the first network entity. The 802. lx procedure can include one or more Extensible Authentication Protocol (EAP)-based procedures, such as an EAP Transport Layer Security (EAP-TLS) procedure, etc.

[0007] ​In the prior art, the authentication status information of a network entity (e.g., information about whether a network entity has been authenticated, information defining a level of trust between a network entity and another network entity, etc.) is locally kept within the network entities involved in the 802.1x procedure (e.g., O-RU, TNE, etc.) and is not shared with other network entities not involved in the 802.1x procedure (e.g., O-RU controller, etc.). Instead, trust is enforced with the next-hop network entity only, and other network entities are considered trustworthy if they are linked or connected to an authenticated and / or authorized network entity.

[0008] The above-described method for network entity authentication in the related art can have at least the following disadvantages. Information about authenticated network entities is kept locally, and a network entity can simply be assumed to be trustworthy by connecting to an authenticated network entity. However, this does not satisfy the zero trust model, which requires that every network entity trying to access an open fronthaul network be thoroughly authenticated before being granted access, without inherently trusting any network entity. In the related art, there is no mechanism that enables a single network entity in an open fronthaul network to have a comprehensive view of all authenticated network entities within the network.

[0009] Furthermore, in an open fronthaul network, there is no clearly defined technology or network topology for advertising information about authenticated network entities in order to enable a network entity to view the authentication status information of other network entities. There is also no clearly defined implementation of a centralized service in an open fronthaul network, nor is there technology for periodically updating network elements to adapt to changes in the open fronthaul network.

[0010] Furthermore, when one or more TNEs (e.g., Ethernet switches, etc.) are allowed or included between the O-RU controller and the remote site hosting the O-RU, the O-RU controller will inherently or implicitly trust all O-RUs by assuming that all O-RUs are trustworthy, and will allow communication with all O-RUs during startup and installation without needing to know the authentication / authorization status of the O-RUs. This also does not comply with the zero trust model, and the O-RU controller cannot guarantee that the O-RUs will not be spoofed before they start providing service. Thus, the network entities of the open fronthaul network face potential security risks. SUMMARY

[0011] Example embodiments of the present disclosure provide apparatuses, methods, etc. for efficiently and effectively determining authentication status information of an O-RU. Specifically, embodiments of the present disclosure define a security mechanism or method for enabling an O-RU controller to determine authentication status information of an O-RU (e.g., whether the O-RU has been authenticated), and the O-RU controller can base on this to decide whether to establish a channel binding with the O-RU or to isolate the O-RU without implicitly or inherently trusting all O-RUs connected therewith. Ultimately, security of an open fronthaul network can be enhanced, and communication between one or more O-RUs and an O-RU controller can be securely established while complying with principles of a zero trust model.

[0012] According to embodiments, an open radio access network (O-RAN) radio unit (O-RU) controller can be configured to: obtain a media access control (MAC) address of an O-RU; determine an authentication status of the O-RU based on the MAC address of the O-RU; establish a channel binding with the O-RU based on determining that the O-RU has been authenticated; and isolate the O-RU from further communication with the O-RU controller based on determining that the O-RU has not been authenticated.

[0013] According to embodiments of the present disclosure, a method implemented by an open radio access network (O-RAN) radio unit (O-RU) controller can include: obtaining a media access control (MAC) address of an O-RU; determining an authentication status of the O-RU based on the MAC address of the O-RU; establishing a channel binding with the O-RU based on determining that the O-RU has been authenticated; and isolating the O-RU from further communication with the O-RU controller based on determining that the O-RU has not been authenticated.

[0014] According to embodiments, a non-transitory computer-readable recording medium can have instructions recorded thereon, the instructions being executable by an open radio access network (O-RAN) radio unit (O-RU) controller to cause the O-RU controller to perform a method including: obtaining a media access control (MAC) address of an O-RU; determining an authentication status of the O-RU based on the MAC address of the O-RU; establishing a channel binding with the O-RU based on determining that the O-RU has been authenticated; and isolating the O-RU from further communication with the O-RU controller based on determining that the O-RU has not been authenticated.

[0015] Additional aspects will be set forth in part in the description which follows, and, in part, will be apparent from the description, or can be learned by practice of the presented embodiments of the disclosure. BRIEF DESCRIPTION OF DRAWINGS

[0016] Features, advantages, and significance of example embodiments of the present disclosure will be described below with reference to the accompanying drawings, in which the same symbols indicate the same elements, and in which: a) shows a schematic diagram of an open radio access network (O-RAN) architecture;

[0017] Figure 1 FIGURE illustrates a block diagram of an example of a generic system architecture of an open front-haul network in the prior art;

[0018] Figure 2 FIGURE illustrates a block diagram of an example system configuration in a peer-to-peer configuration, according to one or more embodiments;

[0019] Figure 3A FIGURE illustrates a block diagram of an example system configuration of a hub-and-spoke configuration;

[0020] Figure 3B FIGURE illustrates a block diagram of an example configuration of a hub, according to one or more embodiments;

[0021] Figure 4 FIGURE illustrates a block diagram of example components in a network entity (NE), according to one or more embodiments;

[0022] Figure 5 FIGURE illustrates a flow diagram of an example method for enabling multiple network entities to view authenticated network entities in a peer-to-peer configuration, according to one or more embodiments;

[0023] Figure 6 FIGURE illustrates an example use case of a network entity being configured in a peer-to-peer configuration, according to one or more embodiments;

[0024] Figure 7 FIGURE illustrates an example of an authentication list, according to one or more embodiments;

[0025] Figure 8 FIGURE illustrates a flow diagram of an example method for enabling multiple network entities to view information of authenticated network entities in a hub-and-spoke configuration, according to one or more embodiments;

[0026] Figure 9 FIGURE illustrates an example use case of a network entity being configured in a hub-and-spoke configuration, according to one or more embodiments;

[0027] Figure 10 FIGURE illustrates a flow diagram of an example method for managing a trust list, according to one or more embodiments;

[0028] Figure 11A FIGURE illustrates an example of a trust list of a network entity, according to one or more embodiments;

[0029] Figure 11B FIGURE illustrates an example of an updated authentication list of a network entity, according to one or more embodiments;

[0030] Figure 11CFIG. illustrates an example sequence diagram of an example use case for announcing authenticated network entities in a peer-to-peer configuration, according to one or more embodiments;

[0031] Figure 12 FIG. illustrates a flow diagram of an example method for announcing an authentication list in a peer-to-peer configuration, according to one or more embodiments;

[0032] Figure 13 FIG. illustrates a flow diagram of an example method for announcing an authentication list in a peer-to-peer configuration, according to one or more embodiments;

[0033] Figure 14A FIG. illustrates a flow diagram of an example method for updating an authentication list, according to one or more embodiments;

[0034] Figure 14B FIG. illustrates a flow diagram of an example method for updating an authentication list in a peer-to-peer configuration in response to receiving another authentication list from a network entity, according to one or more embodiments;

[0035] Figures 15A-15C FIG. illustrates an example sequence diagram of an example use case for announcing authenticated network entities in a peer-to-peer configuration, according to one or more embodiments;

[0036] Figure 16 FIG. illustrates a flow diagram of an example method for announcing an authentication list in a hub-and-spoke configuration according to a push-pull model, according to one or more embodiments;

[0037] Figure 17 FIG. illustrates a flow diagram of an example method for announcing an authentication list in a hub-and-spoke configuration according to a push-pull model, according to one or more embodiments;

[0038] Figure 18 FIG. illustrates a flow diagram of an example method for announcing an authentication list in a hub-and-spoke configuration according to a subscription notification model, according to one or more embodiments;

[0039] Figures 19A-19C FIG. illustrates an example sequence diagram of an example use case for announcing authenticated network entities in a hub-and-spoke configuration according to a push-pull model, according to one or more embodiments;

[0040] Figure 20 FIG. illustrates a block diagram of an example system architecture of an open front-haul network, according to one or more embodiments;

[0041] Figure 21 FIG. illustrates a block diagram of another example system architecture of an open front-haul network, according to one or more embodiments;

[0042] Figure 22 FIG. illustrates a block diagram of an example system architecture of an open front-haul network, according to one or more embodiments;Figure 21 Examples of trusted data stores associated with network entities in

[0043] Figure 23 illustrates other examples of trusted data stores associated with network entities in Figure 21

[0044] Figure 24 illustrates a flow diagram of an example method for determining authentication status information of an O-RU and for managing communications with the O-RU, in accordance with one or more embodiments;

[0045] Figure 25 illustrates a flow diagram of an example method for determining authentication status of an O-RU, in accordance with one or more embodiments;

[0046] Figure 26 illustrates a flow diagram of an example method for managing communications with an O-RU, in accordance with one or more embodiments;

[0047] Figure 27A illustrates a flow diagram of an example method for obtaining a MAC address of an O-RU, in accordance with one or more embodiments

[0048] Figure 27B illustrates a flow diagram of another example method for obtaining a MAC address of an O-RU, in accordance with one or more embodiments;

[0049] Figure 28A illustrates a flow diagram of an example use case of a boot-up procedure of an O-RU, in accordance with one or more embodiments;

[0050] Figure 28B illustrates a flow diagram of an example use case for determining authentication status information of an O-RU and for managing communications with the O-RU at a TLS session establishment phase, in accordance with one or more embodiments;

[0051] Figure 28C illustrates a flow diagram of an example use case for determining authentication status information of an O-RU and for managing communications with the O-RU at a NETCONF session establishment phase, in accordance with one or more embodiments; and

[0052] Figure 29 FIG. 1 illustrates a diagram of an example environment in which devices, systems, and / or methods described herein can be implemented. DETAILED DESCRIPTION

[0053] The detailed description set forth below refers to the accompanying drawings. Same or similar elements in different drawings can be referenced with the same or similar reference numerals.

[0054] ​The above disclosure provides illustrations and descriptions, but are not intended to be exhaustive or to limit implementation to the precise forms disclosed. Modifications and variations are possible in light of the above disclosure, or can be acquired from practice of the implementations. Additionally, one or more features or components of one embodiment can be incorporated into (or combined with) another embodiment (or one or more features of another embodiment). Furthermore, in the operation descriptions provided below, it can be understood that one or more operations can be omitted, one or more operations can be added, one or more operations can be performed simultaneously (at least in part), and the order of one or more operations can be changed.

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

[0056] Not all of the features and benefits described in the specification can be necessary to implement the disclosed disclosure. Thus, not all of the features and benefits can be required in implementations of the disclosed disclosure. In addition, some features and benefits can be implemented or contributed by different systems and / or methods of the disclosed disclosure.

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

[0058] The systems, methods, devices, etc. provided in example embodiments of the present disclosure enable a network entity to view authenticated network entities (e.g., authenticated requesters) in a network. Specifically, embodiments of the present disclosure enable a network entity to view authenticated network entities (e.g., authenticated requesters) in a network, which in turn enables the development of a data store of information about authenticated network entities, thereby building a comprehensive view of all authenticated network entities (e.g., authenticated requesters) and defining explicit trust levels.

[0059] Further, the systems, methods, devices, etc. provided in example embodiments of the present disclosure advertise authenticated network entities to enable a network entity to view authenticated network entities (e.g., authenticated requesters) in a telecommunications network. Specifically, example embodiments of the present disclosure build a comprehensive topology overview of all trusted authenticated network entities based on data sent by each agent deployed in a network entity. Thus, example embodiments of the present disclosure define a network topology for efficiently and effectively advertising information of authenticated network entities.

[0060] Further, the systems, methods, devices, etc. provided in example embodiments of the present disclosure allow for efficient and effective determination of authentication status information of O-RUs. Specifically, example embodiments of the present disclosure define a security mechanism or method for enabling an O-RU controller to determine authentication status information of O-RUs (e.g., information indicating whether an O-RU has been authenticated via an 802. lx or the like authentication procedure), and the O-RU controller can base this to decide whether to establish a channel binding with the O-RU or to isolate the O-RU, without implicitly or inherently trusting all O-RUs connected therewith. In this way, the security of an open fronthaul network can be enhanced, and the communication between one or more O-RUs and an O-RU controller can be securely established while complying with the principles of a zero trust model.

[0061] It is contemplated that the features, advantages, and significance of the above- described example embodiments are only a portion of the present disclosure and are not intended to be exhaustive or limit the scope of the present disclosure.

[0062] Further description of features, components, configurations, operations, and implementations of the threshold tuning system of the present disclosure in accordance with one or more embodiments is provided below. Example System Architecture

[0063] Figure 2 A block diagram illustrating an example system configuration 200 in a peer-to-peer configuration in accordance with one or more embodiments is shown. As Figure 2As shown, the system configuration 200 can include multiple network entities (e.g., network entity 210, network entity 220, and network entity 230) that are communicatively coupled to each other in a peer-to-peer configuration. One or more of the multiple network entities can be configured to view and / or advertise information of authenticated network entity(s), such as information of authenticated requestor(s), in the peer-to-peer configuration. Further, in the peer-to-peer configuration, one or more of the multiple network entities can be configured to determine authentication status information (e.g., 802. lx authentication status) of at least one O-RU, and manage communication with the O-RU based thereon.

[0064] Each of the multiple network entities 210, 220, and 230 can include an apparatus, system, platform, module, etc. that can be configured to perform one or more operations or actions in a network. According to embodiments, the multiple network entities 210, 220, 230 can include entities such as one or more RAN elements (e.g., O-RU, O-DU, O-RAN centralized unit (O-CU), etc.), one or more TNEs, SMOs, etc.

[0065] According to embodiments, each of the multiple network entities 210, 220, and 230 can deploy an agent. Each agent can include software or an entity with a predefined set of instructions. Each agent can also be autonomous and can operate independently or in collaboration with other agents deployed in other network entities. Each agent can also be set up with information about other agents deployed in the network entities that are directly connected to its respective network entity, either through manual configuration during bootstrapping or through automated techniques. According to embodiments, each agent can be capable of supporting one or more hypertext transfer protocol (HTTP) operations for communicating and exchanging information with each other, such as GET, POST, PUT, DELETE, etc.

[0066] According to embodiments, each agent can be configured to directly communicate with each other in a peer-to-peer configuration. In this case, each agent can be configured to establish mutual authentication with each other. In particular, an agent can be configured to establish its identity to another agent by presenting a valid authentication credential such as a digital certificate and / or by presenting an application programming interface (API) key. Such mutual authentication between agents can improve the security of communication between the multiple network entities, and can allow the above-mentioned agents to communicate via a secure connection. According to embodiments, mutual authentication between agents can be established after the respective network entities authenticate with each other.

[0067] According to embodiments, each agent can be configured to perform functions related to one or more trusted data stores, such as creating, updating, retrieving, viewing, and advertising one or more trusted data stores (e.g., authentication lists, trust lists, etc.).

[0068] Figure 3A FIGURE 1 illustrates a block diagram of an example system configuration 100 in a hub-and-spoke configuration, according to one or more embodiments. As shown, the system configuration 100 can include a plurality of network entities (e.g., network entity 110, network entity 120, and network entity 130) in a hub-and-spoke configuration that are communicatively coupled to each other and a hub 140 that is communicatively coupled to each of the plurality of network entities 110, 120, and 130. Figure 3A One or more of the network entities 110, 120, and 130 in the system configuration 100 can be similar to one or more of the network entities 210, 220, and 230 in the system configuration 200. Figure 3A The hub 140 can include an apparatus, system, platform, module, etc. that can be configured to perform one or more operations or actions to manage information of authenticated network entities in a network. For example, as described further below, the hub 140 can be configured to advertise information of one or more authenticated network entities. Figure 2 One or more of the network entities in the plurality of network entities can be configured to view and / or advertise information of authenticated network entity(s), such as information of authenticated requesters, in a hub-and-spoke configuration. Further, one or more of the network entities in the plurality of network entities can be configured to determine authentication status information of at least one O-RU in a hub-and-spoke configuration and manage communication with the O-RU based thereon.

[0069]

[0070] FIGURE 2 illustrates a block diagram of an example system configuration 200 in a hub-and-spoke configuration, according to one or more embodiments. As shown, the system configuration 200 can include a plurality of network entities (e.g., network entity 210, network entity 220, and network entity 230) in a hub-and-spoke configuration that are communicatively coupled to each other and a hub 240 that is communicatively coupled to each of the plurality of network entities 210, 220, and 230. Figure 3B One or more of the network entities 210, 220, and 230 in the system configuration 200 can be similar to one or more of the network entities 110, 120, and 130 in the system configuration 100. The hub 240 can include an apparatus, system, platform, module, etc. that can be configured to perform one or more operations or actions to manage information of authenticated network entities in a network. For example, as described further below, the hub 240 can be configured to advertise information of one or more authenticated network entities. Figure 3B

[0071] ​According to embodiments, hub 340 can include a centralized service that acts as a communication hub point for multiple network entities 310, 320, and 330. According to embodiments, hub 340 can be hosted on any element in an open fronthaul network that has a communication path to multiple network entities 310, 320, and 330, such as an O-RU, an O-DU, an SMO, or an IEEE 802. lx authentication server. In some implementations, hub 340 can act as a centralized broker. Alternatively, one or more operations of one or more components in hub 340 can be deployed in the form of a virtual network service. In this case, hub 340 can act as a centralized service.

[0072] According to embodiments, each of brokers 350A-350C can be deployed in one or more of multiple network entities 310, 320, and 330. Brokers 350A-350C can include software or entities with a predefined set of instructions. Each of brokers 350A-350C can also be autonomous and can operate independently or in collaboration with other brokers deployed in other network entities. Each of brokers 350A-350C can also be set up with information about other brokers deployed in network entities that are directly connected to its respective network entity by either manual configuration during bootstrapping or by automated techniques. According to embodiments, each of brokers 350A-350C can be able to support one or more HTTP methods (e.g., GET / POST / PUT / DELETE, etc.) for communicating and exchanging information with each other.

[0073] According to embodiments, each of brokers 350A-350C can be configured to indirectly communicate with each other via hub 340 in a hub-and-spoke configuration, where hub 340 can act as a communication hub point for brokers 350A-350C. According to embodiments, hub 340 and brokers 350A-350C can exchange data (e.g., request and provide services and resources, etc.) according to a push-pull model and / or a subscription-notification model.

[0074] According to embodiments, each of the proxies 350A-350C can be configured to establish mutual authentication with the hub 340. In particular, the proxies can be configured to establish a secure connection with the hub utilizing a two-way TLS (mTLS) procedure, and the above-described model can be protected by encryption in the mTLS environment. The mutual authentication between the proxies and the hub 340 can also improve the security of communications between the plurality of network entities and the hub 340, and can allow the above-described proxies to communicate indirectly via the secure connection. For example, after the connections between the proxies 350A-350C and the hub 340 are established, data sent between the proxies 350A-350C and the hub 340 can be encrypted using one or more TLS procedures, which provides data confidentiality and integrity. Thus, even if an attacker intercepts the sent data, it cannot read or tamper with the data.

[0075] According to embodiments, one or more of the proxies 350A-350C can be configured to perform functions related to one or more trusted data stores, such as creating, updating, obtaining, viewing, and announcing to the hub 340 one or more trusted data stores (e.g., an authentication list, a trust list, etc.).

[0076] According to embodiments, one or more of the plurality of network entities 210, 220, 230, 310, 320, and 330 can be configured to perform the above-described functions related to one or more trusted data stores (e.g., an authentication list, a trust list, etc.) without the proxies 350A-350C. In particular, each of the plurality of network entities can utilize EAP over LAN (EAPoL) notifications to notify an authenticated network entity (i.e., a network entity that is authenticated via an authentication procedure such as 802. lx) about one or more trusted data stores. In this case, such a procedure can involve implementing a change to the IEEE 802. lx specification, such as in the IEEE 802. lx EAP notification method. On the other hand, by deploying the proxies to perform the above-described functions related to one or more trusted data stores, each of the plurality of network entities is allowed to utilize information of an authenticated network entity without changing the IEEE 802. lx specification.

[0077] It can be appreciated that Figure 2 , Figure 3A and Figure 3B the configurations shown are simplified for description purposes and are not intended to limit the scope of the disclosure in any way. For example, in practice, the number of network entities and / or proxies in a system can be any number.

[0078] Reference is made below to Figure 4Several example components that can be included in the plurality of network entities and hubs in accordance with one or more embodiments are described. Figure 4 A block diagram illustrating example components in a network entity (NE) 400 in accordance with one or more embodiments is shown. The NE 400 can correspond to at least one of the plurality of network entities in Figure 2 and Figure 3A or can correspond to the hub 340 in Figure 3A and Figure 3B Thus, features associated with the plurality of network entities / hubs and the NE 400 can be similarly applicable to each other unless explicitly stated otherwise. Moreover, it is contemplated that the description of one or more components of the NE 400 can also apply to the O-RU controller (described below with reference to Figures 20-28C describing example embodiments associated therewith).

[0079] As shown in Figure 4 the NE 400 can include at least one communication interface 410, at least one processor 420, at least one input / output component 430, and at least one storage 440, although it is understood that the NE 400 can include more or less components than those shown and / or arranged in a different manner than those shown without departing from the scope of the present disclosure. Figure 4 Figure 4

[0080] The communication interface 410 can include at least one transceiver-like component (e.g., a transceiver, a separate receiver and transmitter, a bus, etc.) that enables the components of the NE 400 to communicate with each other and / or with one or more components external to the NE 400, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections.

[0081] For example, the communication interface 410 can couple the processor 420 to the storage 440, enabling them to communicate with and / or operate each other in performing one or more operations. As another example, the communication interface 410 can couple the NE 400 (or one or more components included therein) to a separate network entity, enabling them to communicate with and / or operate each other. In accordance with an embodiment, the communication interface 410 can include one or more application programming interfaces (APIs) that allow the NE 400 (or one or more components included therein) to communicate with one or more software applications.

[0082] ​​The input / output components 430 can include at least one component that permits the NE 400 to receive information and / or provide output information. It can be appreciated that, in some embodiments, the input / output components 430 can include at least one input component (e.g., a touchscreen display, buttons, switches, a microphone, sensors, etc.) and at least one output component (e.g., a display, a speaker, one or more light emitting diodes (LEDs), etc.), each of which can be separate from one another.

[0083] The storage 440 can include one or more storage media suitable for storing data, information, and / or computer-executable instructions. According to an embodiment, the storage 440 can include at least one memory storage, such as random access memory (RAM), read only memory (ROM), and / or another type of dynamic or static storage (e.g., flash memory, magnetic or optical memory) that stores information and / or instructions for use by the processor 420. Additionally or alternatively, the storage 440 can include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, and / or a solid state disk), a compact disk (CD), a digital versatile disk (DVD), a floppy disk, a cassette, a magnetic tape, and / or another type of non-transitory computer-readable medium, and a corresponding drive.

[0084] According to an embodiment, the storage 440 can be configured to store information, such as raw data, metadata, etc. Additionally or alternatively, the storage 440 can be configured to store one or more pieces of information associated with one or more operations performed by the processor 420. For example, the storage 440 can store information defining historical operation(s) performed by the processor 420, one or more results of one or more operations performed by the processor 420, one or more pieces of trusted data storage such as one or more authentication lists and / or one or more trust lists, etc.

[0085] In some implementations, the storage 440 can include multiple storage media, and the storage 440 can be configured to store a copy or duplicate of at least a portion of the information in the multiple storage media to provide redundancy and back up the information or related data. Further, the storage 440 can also store computer-readable or computer-executable instructions that, when executed by one or more processors (e.g., the processor 420), cause the one or more processors to perform one or more actions / operations described herein.

[0086] The processor 420 can include at least one processor that can be programmed or configured to perform the function(s) or operation(s) described herein. For example, the processor 420 can be configured to execute computer-executable instructions stored in at least one storage medium or memory storage (e.g., storage 440, etc.) to perform one or more actions or one or more operations described herein.

[0087] According to embodiments, the processor 420 can be configured to receive (e.g., via the communication interface 410, via the input / output components 430, etc.) one or more signals and / or one or more user inputs that define one or more instructions for performing one or more operations. Further, the processor 420 can be implemented in hardware, firmware, or a combination of hardware and software. For example, the processor 420 can include at least one of the following: a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), and / or another type of processing or computation component.

[0088] According to embodiments, the processor 420 can be configured to collect, extract, and / or receive one or more information (in the form of signals or data, etc.) and process the received one or more information to enable a network entity to view authenticated requesters, advertise authenticated network entities, and determine authentication status information of at least one O-RU.

[0089] Reference is made below to Figures 5-28C A description of several example operations that can be performed by the processor 420 is provided. Example Operation: Viewing Information for Authenticated Network Entities

[0090] As described above, according to one or more embodiments, one or more network entities can be configured to view information of authenticated network entities. For example, a network entity can obtain and view information of one or more authenticated network entities (e.g., authenticated requesters, etc.) in a peer-to-peer configuration. Further, in a hub-and-spoke configuration, a network entity can obtain the above information from a hub and can view the above information accordingly. Reference is made below to Figures 5-11C Example operations associated therewith are described.

[0091] Figure 5A flow diagram illustrating an example method 500 for enabling multiple network entities to view authenticated requesters in a peer-to-peer configuration, in accordance with one or more embodiments, is shown. One or more operations in the method 500 can be performed by at least one processor (e.g., the processor 420) of at least one network entity (i.e., a first network entity) of the plurality of network entities in the open fronthaul network. It can be appreciated that the one or more operations described above can also be performed by a system comprising the at least one network entity, a system comprising the at least one processor, and the like, without departing from the scope of the present disclosure.

[0092] As Figure 5 shown, at operation S510, the at least one network entity can be configured to create a first authentication list. According to an embodiment, the first authentication list can specify one or more network entities that are authenticated by the at least one network entity. Specifically, the first authentication list can specify one or more MAC addresses (which can be referred to herein as “one or more first MAC addresses”) of one or more ports (e.g., network interface cards (NICs), etc.) of the at least one network entity, and one or more MAC addresses of one or more ports of one or more network entities that are authenticated with the one or more first MAC addresses. According to an embodiment, the first authentication list can also specify roles of the one or more ports of the at least one network entity, such as authenticator and requester.

[0093] For example, referring to Figure 6 , which illustrates an example use case in which network entities are configured in a peer-to-peer configuration. As Figure 6 shown, the system can include seven network entities, namely: network entity Y, network entity A, network entity M, network entity X, network entity Z, network entity O, and network entity N.

[0094] As Figure 6 shown, for example, network entity A authenticates to network entity Y and network entity M; wherein port AuP4 of network entity A has MAC address M4 and the role of authenticator to port SuP11 of network entity Y, which has MAC address M11 and the role of requester; and wherein port SuP5 of network entity A has MAC address M5 and the role of requester to port AuP3 of network entity M, which has MAC address M3 and the role of authenticator. Similar explanations apply to network entity Y, network entity M, network entity X, network entity Z, network entity O, and network entity N.

[0095] It can be appreciated that authentication between network entities can be performed based on the 802. lx procedure of an IEEE 802. lx authentication server. In particular, as part of the EAPoL procedure, the network entity acting as authenticator requests identity information from the network entity acting as supplicant, and relays the above identity information to the authentication server. The authentication server then verifies the identity information of the network entity acting as supplicant, and determines whether the above network entity is authorized to access the network. If the above network entity acting as supplicant is authorized to access the network, the above network entity acting as supplicant authenticates to the above network entity acting as authenticator. Through the above authentication procedure, the network entities participating in the authentication procedure are able to acquire information such as port identity, port MAC address, port role, authorization status, etc. from each other.

[0096] Figure 7 An example of an authentication list is illustrated in accordance with one or more embodiments. As shown, for example, network entity A can be configured to create its authentication list 730, which can specify the MAC addresses M4 and M5 of its ports AuP4 and SuP5, and the MAC address Ml l of the port SuPl l of network entity Y that authenticates to port AuP4, and the MAC address M3 of the port AuP3 of network entity M that authenticates to port SuP5. In addition, the authentication list of network entity A can also specify that port AuP4 in network entity A has the role of authenticator, and that port SuP5 in network entity A has the role of supplicant. Thus, the authentication list 730 can specify network entities Y and M (with ports SuPl l and AuP3, respectively) that authenticate to network entity A (with ports AuP4 and SuP5). Figure 7

[0097] Similar explanations apply to network entity Y, network entity M, network entity X, network entity Z, network entity O, and network entity N. Since network entity Y, network entity X, and network entity Z have only one port, the authentication lists of the above network entities are omitted in Figure 7 It can be appreciated that the parameters illustrated in the authentication lists of Figure 7 are merely examples of possible use cases, and the scope of the present disclosure should not be limited thereto. In particular, in practice, the authentication lists can include more / less parameters than shown, and / or the parameters can be presented in a different manner than shown, without departing from the scope of the present disclosure.

[0098] ​According to embodiments, the at least one network entity can be configured to create and update the associated authentication list in regular time periods (i.e., regular intervals or cycles). For example, the at least one network entity can be configured to perform a Simple Network Management Protocol version 3 (SNMPv3) query of object identifier (OID) "1.3.111.2.802.1.1.15.2.2.3" at regular time periods. Subsequently, based on the SNMPv3 response (which will show the status of object type "ieee8021XPaeLogonGroup"), the at least one network entity can then create and / or update the authentication list. According to embodiments, the at least one network entity can also be configured to send the first authentication list to one or more network entities that are authenticated to the at least one network entity.

[0099] Referring again to Figure 5 After the first authentication list is created at operation S510, the method 500 can proceed to operation S520 at which the at least one network entity (i.e., the first network entity) can be configured to receive a second authentication list from a second network entity. According to embodiments, the sending of the first authentication list and the receiving of the second authentication list can be performed by the at least one network entity via the advertisement interface.

[0100] According to embodiments, the at least one network entity (i.e., the first network entity) and the second network entity can authenticate each other. According to embodiments, similar to the first authentication list, the second authentication list can specify one or more network entities that are authenticated to the second network entity. In particular, the second authentication list can specify one or more MAC addresses of one or more ports of the second network entity (which can be referred to herein as "one or more second MAC addresses"), and one or more MAC addresses of one or more ports of one or more network entities that are authenticated to the one or more second MAC addresses. According to embodiments, the second authentication list can also specify roles of one or more ports of the second network entity, such as authenticator and requestor. For example, referring to Figure 6 and Figure 7 At operation S520, the network entity A (i.e., the component 620 in Figure 6 ) can receive an authentication list of the network entity M (i.e., the component 610 in Figure 6 ) from the network entity M that is authenticated to the network entity A. Figure 7 ) can receive the authentication list 710 in

[0101] Method 500 then proceeds to operation S530, at which the at least one network entity can be configured to create a trust list based on the first authentication list and the second authentication list. According to embodiments, the trust list can specify a level of trust between the at least one network entity (i.e., the first network entity) and one or more network entities in the first authentication list and the second authentication list. For example, with reference to Figure 6 and Figure 7 Since the authentication list of network entity A specifies network entity Y and network entity M (which respectively authenticate to network entity A via port MAC addresses Ml 1 and M3), and since the authentication list of network entity M specifies network entity X and network entity N (which respectively authenticate to network entity M via port MAC addresses M12 and M6), the trust list of network entity A can specify a level of trust between network entity A and network entity Y, network entity M, network entity X, and network entity N. Examples of operations for creating a trust list will be described below with reference to Figure 10

[0102] After performing operation S530, method 500 can end or terminate. Alternatively, method 500 can return to operation S520 such that the at least one network entity can be configured to repeatedly (e.g., periodically, continuously, etc.) perform receiving the second authentication list (at operation S520) and creating the trust list (at operation S530) for at least a predetermined amount of time. For example, the at least one network entity can continuously or periodically receive a plurality of authentication lists from a plurality of network entities, and can then create or update a trust list based thereon.

[0103] In light of the above, according to one or more embodiments, network entities in an open fronthaul network can communicate in a peer-to-peer configuration to obtain information of authenticated network entities. Thus, example embodiments of the present disclosure can enable network entities to view information of authenticated network entities (e.g., authenticated requesters, etc.) in a network via communicating with each other in a peer-to-peer configuration. More specifically, each network entity in the network can obtain general knowledge of other authenticated network entities by referencing one or more trusted data stores (e.g., authentication lists, trust lists, etc.) that are locally created and timely updated.

[0104] Additionally or alternatively, network entities can be configured to obtain information of authenticated network entities via communicating with a hub (or centralized agent / centralized service). The above provides a description of an example hub, with reference to Figure 3A and Figure 3B The above provides a description of an example hub, with reference to Figures 8-11C The above provides a description of an example hub, with reference to ​

[0105] Figure 8 FIGURE 8 illustrates a flow diagram of an example method 800 for enabling multiple network entities to view information of an authenticated network entity (e.g., an authenticated requestor) in a hub-and-spoke configuration, according to one or more embodiments. One or more operations in the method 800 can be performed by at least one processor (e.g., the processor 420) of a hub communicatively coupled to the multiple network entities in the system. It can be appreciated that the one or more operations described above can also be performed by the system including the hub, the system including the at least one processor, and the like, without departing from the scope of the present disclosure.

[0106] As Figure 8 illustrated, at operation S810, the hub can be configured to receive a first authentication list from a first network entity. The first authentication list can be similar to the first authentication list described above with respect to the method 500. Figure 5

[0107] Figure 9 FIGURE 9 illustrates an example use case of network entities configured in a hub-and-spoke configuration, according to one or more embodiments. Figure 9 The example of network entities in the hub-and-spoke configuration illustrated in FIGURE 9 is similar to the example of network entities in the peer-to-peer configuration illustrated in FIGURE 8, but with the addition of a hub 990 communicatively coupled to each network entity. Figure 6

[0108] In this regard, with reference to Figure 7 and Figure 9 at operation S810, the hub 990 can be configured to receive an authentication list of network element A (i.e., the component 920 in Figure 9 ) from network element A, for example. The authentication list of network element A can be similar to the authentication list 730 illustrated in Figure 7 .

[0109] After performing operation S810, the method 800 can then proceed to operation S820, at which the hub can be configured to receive a second authentication list from a second network entity. The second authentication list can be similar to the second authentication list described above with respect to the method 500. For example, with reference to Figure 7 and Figure 9 at operation S820, the hub 990 can receive an authentication list of network entity M (i.e., the component 910 in Figure 9 ) from network entity M that is authenticating to network entity A. The authentication list of network entity M can be similar to the authentication list 710 illustrated in Figure 7 .

[0110] ​​According to embodiments, the receiving of the first and second authentication lists can be performed by the hub via the announcement interface. After receiving the first and second authentication lists, the method 800 can proceed to operation S830, at which the hub can be configured to create a trust list for the first network entity based on the first authentication list and the second authentication list. The trust list can be similar to the trust list described above with respect to method 500. Further description of examples of trust lists is provided below with respect to Figure 11A and Figure 11C Further description of examples of trust lists is provided below with respect to

[0111] After performing operation S830, the method 800 can end or terminate. Alternatively, the method 800 can return to operation S820 such that the hub can be configured to repeatedly (e.g., periodically, continuously, etc.) perform the receiving of the second authentication list (at operation S820) and the creating of the trust list (at operation S830) for at least a predetermined amount of time. For example, the hub can continuously (or periodically) receive a plurality of authentication lists from a plurality of network entities, and can then create or update a trust list based thereon.

[0112] In view of the above, according to one or more embodiments, network entities in an open fronthaul network can communicate with a hub in a hub-and-spoke configuration, and the hub can provide information of one or more trusted data stores (e.g., authentication lists, trust lists, etc.) associated with authenticated network entities to network entities communicatively coupled thereto. For example, the one or more trusted data stores (e.g., authentication lists, trust lists, etc.) can be created locally at each network entity and transmitted to the hub and / or can be created at the hub, and then the hub can be configured to transmit or announce the one or more trusted data stores to network entities associated therewith. Further, the hub can be configured to update at least a portion of the trusted data stores (e.g., trust lists, etc.) at regular intervals or periodically. Thus, example embodiments of the present disclosure can enable network entities to view information of authenticated network entities (e.g., authenticated requesters, etc.) in a network via communication with a hub in a hub-and-spoke configuration. More specifically, each network entity in the network can acquire overall knowledge of other authenticated network entities by referring to one or more trusted data stores (e.g., authentication lists, trust lists, etc.) that are created and updated in a timely manner.

[0113] In the following, an example of operations for managing (e.g., creating, updating, etc.) a trust list is described. Figure 10 A flowchart of an example method 1000 for managing a trust list according to one or more embodiments is illustrated. The trust list can include information collected and integrated from a plurality of authenticated network entities in an open fronthaul network.

[0114] For example, in some implementations, the trust list can be presented in the form of an entity-level trust table and / or a network-level (e.g., direct or indirect) trust table. The entity-level trust table can be generated based on an authentication list associated with a network entity. On the other hand, the network-level trust table can be generated based on information integrated from a plurality of authentication lists, each of which is associated with one of a plurality of authenticated network entities (e.g., authenticated requesters) in the network. Examples of the entity-level trust list (i.e., the trust list presented in the form of the entity-level trust table) are described below with reference to Figure 11A Examples of the network-level trust list (i.e., the trust list presented in the form of the network-level trust table) are described below with reference to Figure 11C Examples of the network-level trust list (i.e., the trust list presented in the form of the network-level trust table) are described below with reference to

[0115] It is contemplated that, in some implementations, the authentication list can also be presented in the form of an entity-level authentication table and / or a network-level authentication table in a similar manner. For example, the authentication list 730 described above is an example of an entity-level authentication list (i.e., the authentication list presented in the form of the entity-level authentication table) associated with the network entity A, and is described below with reference to Figure 11B Examples of the network-level authentication list (i.e., the authentication list presented in the form of the network-level authentication table) associated with the network entity A are described below with reference to

[0116] Referring back to Figure 10 , one or more operations in the method 1000 can be performed by at least one processor (e.g., the processor 420) of at least one network entity (i.e., a first network entity) in the system, or can be performed by at least one processor (e.g., the processor 420) of a hub communicatively coupled to the plurality of network entities in the system. It can be appreciated that the one or more operations described above can also be performed by a system including the at least one network entity, a system including the hub, a system including the at least one processor, etc., without departing from the scope of the present disclosure. Furthermore, it is contemplated that one or more operations of the method 1000 can be performed in a peer-to-peer configuration and / or a hub-and-spoke configuration, and can be part of the operation S530 in the method 500 or can be part of the operation S830 in the method 800.

[0117] Referring back to Figure 10 At operation S1010, the at least one network entity / hub can be configured to create a trust list based on a first authentication list. The first authentication list can be created by the at least one network entity (at operation S510) or can be received by the hub from the first network entity (at operation S810).

[0118] According to an embodiment, a trust list created based on a first authentication list can specify a trust level between at least one network entity (i.e., the first network entity) and one or more network entities in the first authentication list. Specifically, in some embodiments, the trust level can be one of direct trust and indirect trust between one or more ports of at least one network entity (i.e., the first network entity) and one or more ports of one or more network entities with the requester role in the first authentication list.

[0119] According to an embodiment, the trust list created based on the first authentication list may include one or more MAC addresses of one or more ports of at least one network entity (i.e., the first network entity) and one or more MAC addresses of one or more ports of one or more network entities having the requester role in the first authentication list. For example, Figure 11A The illustration shows an example of a trust list for network entity A according to one or more embodiments, wherein the trust list is based on the authentication list of network entity A (e.g., Figure 7 The authentication list 730 in the database is used to create (e.g., created by at least one network entity, created by a hub, etc.).

[0120] like Figure 11A As shown, the trust list of network entity A specifies MAC addresses M5 and M4 (i.e., the MAC addresses of ports SuP5 and AuP4 of network entity A, respectively). Furthermore, since the port of network entity Y (which has the requester role, i.e., SuP11) authenticates to port AuP4 of network entity A, the trust list of network entity A specifies the MAC address M11 of the aforementioned port SuP11 of network entity Y, and specifies the trust level between port SuP11 and port AuP4 of network entity A as direct trust. On the other hand, since the port of network entity M (which has the requester role, i.e., SuP2) authenticates to port SuP5 of network entity A via port AuP3 of network entity M, the trust list of network entity A specifies the MAC address M2 of the aforementioned port SuP2, and specifies the trust level between the aforementioned port SuP2 of network entity M and port SuP5 of network entity A as indirect trust. In this respect, since... Figure 11A The trust list in this document is created based on the authentication list of network entity A. Therefore, the trust list mentioned above can be referred to as an "entity-level trust list" in this document, and the table included in the trust list can also be referred to as an "entity-level trust table" in this document.

[0121] After the creation of the authentication list and / or the trust list, the above authentication list / trust list can be shared or announced to one or more network entities in the network. For example, the created authentication list and / or the trust list can be shared by at least one network entity to another network entity(s) in a peer-to-peer configuration, or can be shared by a hub to one or more network entities in a hub-and-spoke configuration.

[0122] According to embodiments, after the creation of the trust list, the at least one network entity / hub can be configured to periodically (or continuously) update the trust list. For example, after performing operation S1010, the method 1000 can further proceed to operation S1020 at which the at least one network entity / hub can be configured to update the first authentication list to include a second authentication list in response to receiving the second authentication list.

[0123] For example, Figure 11B FIG. 13 illustrates an example of an updated authentication list of network entity A according to one or more embodiments. As shown, the authentication list of network entity A is updated (from the authentication list 730 in FIG. 11) to include the information of the authentication list of network entity M (i.e., the authentication list 710 in FIG. 10). In this regard, since the authentication list in FIG. 11 is an authentication list including information integrated from multiple authentication lists, and each of the multiple authentication lists is associated with one of the multiple network entities in the network, the above authentication list can be referred to herein as a “network-level authentication list”, and the table included in the authentication list can be referred to herein as a “network-level authentication table”. Figure 11B Figure 7 Figure 7 Figure 11B

[0124] ​​​​After updating the authentication list, the method 1000 can further proceed to operation S1030, at which the at least one network entity / hub can be configured to update a trust list of the network entities associated with the updated authentication list based on the updated authentication list. For example, the at least one network entity / hub can update the trust list based on the updated first authentication list to further specify a trust level between the at least one network entity (i.e., the first network entity) and the one or more network entities in the second authentication list. According to an embodiment, the trust level can be one of a direct trust and an indirect trust between the one or more ports of the at least one network entity (i.e., the first network entity) and the one or more ports of the one or more network entities in the second authentication list (which is now included in the updated first authentication list) having the requester role. According to an embodiment, the updated trust list can include one or more MAC addresses of the one or more ports of the at least one network entity (i.e., the first network entity) and one or more MAC addresses of the one or more ports of the one or more network entities in the second authentication list having the requester role.

[0125] For example, referring to Figure 11C which illustrates an example of an updated trust list of network entity A according to one or more embodiments. Specifically, since the port of network entity X (which is in the authentication list of network entity M, which is now included in the updated authentication list of network entity A) having the requester role (i.e., SuP12) authenticates to the port SuP5 of network entity A via the ports AuPl and AuP3 of network entity M, the updated trust list of network entity A further specifies the MAC address M12 of the above-mentioned port SuP12, and specifies that the trust level between the port SuP12 of network entity X and the port SuP5 of network entity A is an indirect trust. Likewise, since the port of network entity N (which is in the authentication list of network entity M, which is now included in the updated authentication list of network entity A) having the requester role (i.e., SuP7) authenticates to the port SuP5 of network entity A via the port AuP6 of network entity N and the ports SuP2 and AuP3 of network entity M, the updated trust list of network entity A further specifies the MAC address M7 of the above-mentioned port SuP7, and specifies that the trust level between the port SuP7 of network entity N and the port SuP5 of network entity A is an indirect trust. In this regard, since Figure 11CThe trust list in the network entity A is created based on the updated authentication list of the network entity A (i.e., an authentication list that includes information integrated from a plurality of authentication lists, and each of the plurality of authentication lists is associated with one of a plurality of network entities in the network), thus the above-mentioned trust list can be referred to herein as a "network-level trust list", and the table included in the trust list can also be referred to herein as a "network-level trust table".

[0126] It can be appreciated that in some implementations, one or more ports of the network entity A in the authentication list of the network entity M (which is now included in the updated authentication list of the network entity A) can be included / excluded from the above-mentioned process.

[0127] After updating the authentication list and / or the trust list, the updated authentication list and / or the updated trust list can be shared or advertised to one or more network entities in the network. For example, the updated authentication list and / or the updated trust list can be shared by at least one network entity to another network entity(s) in a peer-to-peer configuration, or can be shared by a hub to one or more network entities in a hub-and-spoke configuration. For example, in a peer-to-peer configuration, the updated first authentication list can be sent to one or more network entities that authenticate to at least one network entity (i.e., a first network entity), and thus, the received second authentication list can further specify one or more network entities that authenticate to a third network entity that authenticates to a second network entity.

[0128] According to embodiments, after performing operation S1030, the method 1000 can end or terminate. Alternatively, the method 1000 can return to operation S1020, such that the at least one network entity / hub can be configured to repeatedly (e.g., periodically, continuously, etc.) perform updating the first authentication list (at operation S1020) and updating the trust list (at operation S1030) for at least a predetermined amount of time, until each of the plurality of network entities has a comprehensive view of all authenticated network entities within the network.

[0129] For example, in a peer-to-peer configuration, after network entity A's authentication list is updated to include network entity M's authentication list as described above and network entity A's trust list is updated based on the updated authentication list, network entity M can receive network entity N's authentication list from network entity N (which specifies network entity O as being authenticated to network entity N). Network entity M's authentication list can then be updated to include network entity N's authentication list (such that network entity M's authentication list now specifies network entity O), and network entity M's trust list is updated based on the updated authentication list in a similar manner as described above. Subsequently, network entity M can again send its updated authentication list to network entity A, where the process repeats and network entity A's authentication list and trust list are updated so as to now also specify network entity O. The above process can repeat until each of the plurality of network entities has a latest comprehensive view of all authenticated network entities within the network.

[0130] In a similar manner, example embodiments allow O-RU controllers (e.g., O-DUs, SMOs, etc.) and O-RUs to establish a level of trust between each other. For example, O-RU controllers and O-RUs can establish indirect trust between each other, and thereafter channel bonding can be established even though the O-RU controllers and O-RUs are not directly authenticated to each other. Reference is made below to Figures 20-28C Example operations associated therewith are described.

[0131] It can be appreciated that the above description with reference to Figures 5-11C The description provided is merely an example of the example embodiments, and the scope of the disclosure should not be limited thereto. Specifically, without departing from the scope of the disclosure, Figure 7 and Figures 11A-11C The authentication lists and / or trust lists shown can include more / less information than shown, and / or the information can be presented in any other suitable form other than table form. Similarly, the number of network entities in the system can be any number, the number of ports for each of the plurality of network entities can be any number, each of the plurality of network entities can be authenticated to any other network entity, and so on. Example Operation: Announcing Information for Authenticated Network Entities

[0132] As described above, according to one or more embodiments, one or more network entities can be configured to share or advertise information of authenticated network entities. For example, in a peer-to-peer configuration, a network entity can advertise information of one or more authenticated network entities (e.g., authenticated requesters, etc.) to another network entity(s). Further, in a hub-and-spoke configuration, a network entity can advertise the above information to a hub, and the hub can be configured to advertise the above information to another network entity(s) accordingly. Reference is made below.Figures 12-19C Example operations associated therewith are described.

[0133] Figure 12 A flow diagram illustrating an example method 1200 for announcing an authenticated network entity in a peer-to-peer configuration, in accordance with one or more embodiments, is shown. One or more operations in the method 1200 can be performed by at least one processor (e.g., the processor 420) of at least one network entity (i.e., a first network entity) of a system. It can be appreciated that the one or more operations described above can also be performed by the system comprising the at least one network entity, the system comprising the at least one processor, and the like, without departing from the scope of the present disclosure.

[0134] As Figure 12 shown, at operation S1210, the at least one network entity can be configured to create a first authentication list. This operation can be similar to the operation S510 in the method 500, and thus, for the sake of brevity, redundant descriptions associated therewith can be omitted below.

[0135] After creating the first authentication list at operation S1210, the method 1200 can proceed to operation S1220, at which the at least one network entity (i.e., the first network entity) can be configured to announce the first authentication list to a second network entity. For example, the at least one network entity can announce the first authentication list to a second agent (e.g., the agent 350B) deployed in the second network entity. According to an embodiment, the at least one network entity and the second network entity can authenticate each other. For example, with reference to Figure 6 and Figure 7 , at operation S1220, the network entity A (i.e., the component 620 in the Figure 6 ) can be configured to announce the authentication list 730 (i.e., the authentication list of the network entity A) to an agent deployed in the network entity M (i.e., the component 610 in the Figure 6 ).

[0136] According to an embodiment, the creation of the first authentication list can be performed by a first agent (e.g., the agent 350A) deployed in the at least one network entity, and the announcement of the first authentication list can be performed by the first agent via an announcement interface. According to an embodiment, the announcement interface can comprise an interface such as a Representational State Transfer (REST) API, and the like. According to an embodiment, the first agent can mutually authenticate with the second agent.

[0137] After performing operation S1220, method 1200 may end or terminate. Alternatively, at least one network entity may be configured to repeatedly (e.g., periodically, continuously, etc.) advertise the first authentication list for at least a predetermined amount of time (at operation S1220). For example, at least one network entity may update the first authentication list in response to changes in the network and may then restart advertising the first authentication list.

[0138] Figure 13 A flowchart illustrating an example method 1300 for announcing an authentication list in a peer configuration, according to one or more embodiments, is shown. One or more operations of method 1300 may be similar to operations S1210 and S1220 in method 1200, and may be performed by at least one processor (e.g., processor 420) of at least one network entity (i.e., the first network entity) among a plurality of network entities in the system. It will be understood that the above-described one or more operations may also be performed by a system including at least one network entity, a system including at least one processor, etc., without departing from the scope of this disclosure.

[0139] like Figure 13 As shown, at operation S1310, at least one network entity can be configured to create a first authentication list in a manner similar to that described above with respect to operation S510 in method 500.

[0140] After performing operation S1310, method 1300 can then proceed to operation S1320, where at least one network entity can be configured to send a first authentication list to a second network entity. According to an embodiment, at least one network entity can send the first authentication list to a second agent deployed in the second network entity. At least one network entity (i.e., the first network entity) and the second network entity can authenticate each other.

[0141] For example, refer to Figure 6 and Figure 7 At operation S1320, network entity A (i.e., Figure 6 Component 620 in the document can be configured to associate a list of authentications (i.e., Figure 7 The authentication list 730 in the document is sent to network entity M (i.e., to authenticate network entity A) Figure 6 The agent deployed in component 610.

[0142] According to an embodiment, at least one network entity can be configured to send a first authentication list to a second proxy in response to receiving a request from a second proxy to send a first authentication list. Similarly, at least one network entity can be configured to send a request to receive an authentication list from a second proxy.

[0143] According to an embodiment, the creation of the first authentication list can be performed by a first agent deployed in the at least one network entity, and the sending of the first authentication list can be performed by the first agent via an advertisement interface. According to an embodiment, the advertisement interface can comprise an interface such as a REST API. According to an embodiment, the first agent can mutually authenticate with the second agent.

[0144] After performing operation S1320, method 1300 can end or terminate. Alternatively, the at least one network entity can be configured to repeatedly (e.g., periodically, continuously, etc.) perform sending the first authentication list for at least a predetermined amount of time. For example, the at least one network entity can update the first authentication list in response to changes in the network, and can then resume sending the first authentication list.

[0145] Reference is made below to Figure 14A and Figure 14B Examples of operations for updating an authentication list and advertising the updated authentication list in a peer-to-peer configuration are described.

[0146] Figure 14A A flowchart illustrating an example method 1400 for updating an authentication list according to one or more embodiments is shown. One or more operations in method 1400 can be performed by at least one processor (e.g., processor 420) of at least one network entity (i.e., a first network entity) in a system in response to a new authenticated network entity in a peer-to-peer configuration after a first authentication list is created. It can be appreciated that one or more operations described above can also be performed by the system including the at least one network entity, the system including the at least one processor, etc. without departing from the scope of the present disclosure.

[0147] As shown in Figure 14A , at operation S1410, the at least one network entity can be configured to authenticate one or more new network entities. According to an embodiment, the one or more newly authenticated network entities can comprise one or more network entities that are authenticated to the at least one network entity after the first authentication list is created and are not indicated in the first authentication list.

[0148] For example, with reference to Figure 6 and Figure 7 , after network entity A (i.e., component 620 in Figure 6 creates an associated authentication list (i.e., authentication list 730 in Figure 7 ) specifying a port SuP11 (MAC address M11) of network entity Y, at operation S1410, network entity A can newly authenticate network entity M (which is not yet indicated or specified in authentication list 730).

[0149] In this case, the method 1400 can proceed to operation S1420, at which the at least one network entity can be configured to update the first authentication list to further specify the one or more network entities that are newly authenticated. For example, with reference to Figure 6 and Figure 7 After network entity A newly authenticates network entity M, network entity A can be configured to update the relevant authentication list (i.e., the authentication list 730 in Figure 7 ) to further specify network entity M. For example, network entity A can be configured to update the relevant authentication list by adding a new row to specify the port AuP3 (MAC address M3) of network entity M and the corresponding port SuP5 (MAC address M5) of network entity A in the authentication list 730.

[0150] Accordingly, the method 1400 can proceed to operation S1430, at which the at least one network entity can be configured to send the updated first authentication list to one or more agents deployed in the one or more authenticated network entities (i.e., the one or more network entities that are authenticated to the at least one network entity). For example, after updating its authentication list, network entity A can be configured to send its updated authentication list to the agent deployed in network entity Y (i.e., the network entity that has previously been authenticated to network entity A) and the agent deployed in network entity M (i.e., the network entity that is newly authenticated to network entity A).

[0151] After performing operation S1430, the method 1400 can end or terminate. Alternatively, the method 1400 can return to operation S1410, such that the at least one network entity can be configured to repeatedly (e.g., periodically, continuously, etc.) perform authenticating the one or more network entities (at operation S1410), updating the first authentication list (at operation S1420), and sending the updated first authentication list (at operation S1430) for at least a predetermined amount of time. For example, the at least one network entity can continue to find more network entities to authenticate to, and then can restart operations S1410-S1430.

[0152] Figure 14BA flow chart illustrating an example method 1405 for updating an authentication list in response to receiving another authentication list from a network entity in a peer-to-peer configuration, in accordance with one or more embodiments, is shown. One or more operations in the method 1405 can be performed after the first authentication list is created, and can be performed by at least one processor (e.g., the processor 420) of at least one network entity (i.e., the first network entity) of a system. It can be appreciated that the one or more operations described above can also be performed by the system including the at least one network entity, the system including the at least one processor, and the like, without departing from the scope of the present disclosure.

[0153] As shown in Figure 14B , at operation S1415, the at least one network entity can be configured to receive one or more authentication lists from one or more agents deployed in one or more authenticated network entities (i.e., one or more network entities that are authenticated to the at least one network entity described above). It can be appreciated that the one or more authentication lists can be created by the respective one or more agents in a similar manner as described above. For example, at operation S1415, the at least one network entity can be configured to receive a second authentication list from a second agent deployed in a second network entity, where the second network entity is authenticated to the at least one network entity (i.e., the first network entity). According to an embodiment, the second authentication list can specify one or more network entities that are authenticated to the second network entity in a similar manner as the first authentication list. For example, with reference to Figure 6 and Figure 7 , the network entity A (i.e., the component 620 in Figure 6 ) can be configured to receive an authentication list of the network entity M (i.e., the authentication list 710 in Figure 6 ) from an agent deployed in the network entity M (i.e., the component 610 in Figure 7 ).

[0154] After performing operation S1415, the method 1405 can then proceed to operation S1425, at which the at least one network entity can be configured to update the first authentication list to include the one or more authentication lists. For example, with reference to Figure 6 and Figure 7 , at operation S1415, the network entity A (i.e., the component 620 in Figure 6 ) can be configured to update its authentication list (i.e., the authentication list 730 in Figure 7 ) to include the rows for the ports AuPl, AuP3, and SuP2 specified in the authentication list of the network entity M (e.g., the authentication list 710 in Figure 7 ).

[0155] After performing operation S1425, the method 1405 can then proceed to operation S1435, at which the at least one network entity can be configured to send the updated first authentication list to one or more agents deployed in one or more authenticated network entities (i.e., one or more network entities that are authenticated to the at least one network entity). For example, network entity A can be configured to send its updated authentication list (which also includes information for ports AuPl, AuP3, and SuP2 of network entity M) to an agent deployed in network entity Y and an agent deployed in network entity M, where network entity Y and network entity M are authenticated to network entity A.

[0156] After performing operation S1435, the method 1405 can end or terminate. Alternatively, the method 1405 can return to operation S1415, such that the at least one network entity can be configured to repeatedly (e.g., periodically, continuously, etc.) perform receiving one or more authentication lists (at operation S1415), updating the first authentication list (at operation S1425), and sending the updated first authentication list (at operation S1435) for at least a predetermined amount of time. For example, the at least one network entity can continue to receive more authentication lists, and then can restart operations S1415-S1435.

[0157] According to embodiments, the at least one network entity can be configured to send a notification to the one or more agents to indicate a change in the network. For example, the at least one network entity can be configured to send a notification that the at least one network entity is newly authenticated to a network entity, that the first authentication list has been updated, and the like. According to embodiments, the at least one network entity can be configured to send the updated first authentication list to the one or more agents in response to receiving a request from the one or more agents to send the updated first authentication list. Similarly, the at least one network entity can be configured to receive a notification from the one or more agents, and send a request for the updated authentication list from the one or more agents.

[0158] According to embodiments, the receiving of the one or more authentication lists, the updating of the first authentication list, and the sending of the updated first authentication list can be performed by a first agent deployed in the at least one network entity. According to embodiments, the sending of the updated first authentication list, as well as the sending and receiving of the notification and the request can be performed via an advertisement interface. According to embodiments, the advertisement interface can comprise an interface such as a REST API. According to embodiments, the first agent can be mutually authenticated with one or more agents deployed in one or more network entities that are authenticated to the first network entity.

[0159] In view of the above, the example embodiments allow the proxies of the network entities to be easily informed of any changes in the network and allow the proxies to always have the latest information authenticating the network entities (e.g., always receive the latest version of the authentication list, etc.).

[0160] In the following, a description of an example use case for announcing authenticated network entities in a peer-to-peer configuration according to one or more embodiments is provided.

[0161] Figures 15A-15C An example flow diagram illustrating an example use case for announcing authenticated network entities in a peer-to-peer configuration according to one or more embodiments is shown. Figures 15A-15C The shown example flow diagram relates to the processes explained above with respect to the methods 1200, 1300, 1400, and 1405 and is split into 3 parts for the sake of clarity.

[0162] As Figures 15A-15C is shown, the network comprises 4 network entities (i.e., network entity 1, network entity 2, network entity 3, and network entity 4) having 4 proxies (i.e., proxy 1, proxy 2, proxy 3, and proxy 4) deployed and an authentication server.

[0163] During steps 1 to 3, network entity 1 (in which proxy 1 is deployed) can perform an authentication to network entity 2 (in which proxy 2 is deployed). According to an embodiment, network entity 1 can perform the authentication to network entity 2 via an 802.1x procedure (i.e., an authentication procedure according to the EAP-TLS authentication protocol of the RFC5216 of IEEE 802.1x). If the authentication is successful, the sequence proceeds to step 4. On the other hand, if the authentication is not successful, network entity 2 can issue a security alert and can block data traffic to and from network entity 1.

[0164] During steps 4 to 5, network entity 2 can create / update an authentication list and can announce the authentication list to network entity 1 over a secure connection.

[0165] During step 6, network entity 2 can form a direct trust with network entity 1. For example, after network entity 1 receives the authentication list of network entity 2, network entity 1 can be configured to create / update a trust list specifying that the level of trust between network entity 2 and network entity 1 is a direct trust.

[0166] During steps 7 to 12, in a similar manner as described above with respect to steps 1 to 6, network entity 3 (in which proxy 3 is deployed) can perform an authentication to network entity 2, can create / update an authentication list, can announce the authentication list to network entity 2, and can form a direct trust with network entity 2.

[0167] During step 13, network entity 2 can advertise its authentication list to network entity 3. In particular, since network entity 2 is newly authenticated to network entity 3, and has received an authentication list from network entity 3, network entity 2 can update its authentication list to include the received authentication list from network entity 3, and can advertise its updated authentication list to network entity 3. Similarly, network entity 3 can update its authentication list to include the received authentication list from network entity 2.

[0168] During steps 14-16, network entity 3 can perform authentication to network entity 4 (wherein proxy 4 is deployed) in a similar manner as described above with respect to steps 1-3.

[0169] During step 17, network entity 3 can update its authentication list to further specify newly authenticated network entity 4.

[0170] During steps 18-19, network entity 3 can advertise its updated authentication list to network entity 2 and network entity 4.

[0171] During step 20, network entity 4 can form indirect trust with network entity 1. For example, since network entity 1 is specified in the authentication list of network entity 2 advertised to network entity 3 (at step 13), and since network entity 3 updated its authentication list to include the authentication list of network entity 2 and advertised the authentication list to network entity 4 (at step 19), network entity 4 can update its authentication list to include the authentication list of network entity 3 (which specifies network entity 1). Thus, network entity 4 can be configured to create / update a trust list based on the updated authentication list of network entity 4, the trust list specifying that the level of trust between network entity 4 and network entity 1 is indirect trust.

[0172] During step 21, network entity 4 can form direct trust with network entity 3 in a similar manner as described above with respect to step 6.

[0173] To this end, example embodiments of the present disclosure enable network entities to advertise information of authenticated network entities in a peer-to-peer configuration. In this way, each network entity in an open fronthaul network can acquire comprehensive information of other authenticated network entities in the network, and can receive real-time updates.

[0174] In addition to or as an alternative to the peer-to-peer configuration, network entities can also advertise information of authenticated network entities in a hub-and-spoke configuration. In the following, reference is made to Figures 16-19C Several example operations for advertising information of one or more authenticated network entities in a hub-and-spoke configuration are described in accordance with one or more embodiments.

[0175] Figure 16 FIG. 16 illustrates a flowchart of an example method 1600 for announcing an authenticated network entity in a hub-and-spoke configuration, according to one or more embodiments. One or more operations in the method 1600 can be performed by at least one processor (e.g., the processor 420) of a hub communicatively coupled to a plurality of network entities in a system. It can be appreciated that the one or more operations described above can also be performed by the system including the hub, the system including the at least one processor, and the like, without departing from the scope of the present disclosure.

[0176] As Figure 16 illustrated, at operation S1610, the hub can be configured to receive a first authentication list from a first network entity. According to an embodiment, the hub can be configured to receive the first authentication from a first agent deployed in the first network entity. The first authentication list can be similar to the first authentication list described above, and can be created by the first agent in a similar manner as described above with respect to the peer-to-peer configuration. For example, with reference to Figure 7 and Figure 9 at operation S1610, the hub 990 can be configured to receive the authentication list 730 (i.e., the authentication of the network entity A) from the network entity A (i.e., the component 920 in Figure 9 In some implementations, the hub 990 can be configured to receive the authentication list 730 from an agent deployed in the network entity A.

[0177] After receiving the first authentication list, the method 1600 can then proceed to operation S1620, at which the hub can be configured to announce the first authentication list to a second network entity. According to an embodiment, the hub can be configured to announce the first authentication list to a second agent deployed in the second network entity according to a subscription model, such as a push-pull model and a subscription notification model. Operation examples for announcing an authentication list according to the push-pull model in a hub-and-spoke configuration are described below with reference to Figure 17 Operation examples for announcing an authentication list according to the subscription notification model in a hub-and-spoke configuration are described below with reference to Figure 18 According to an embodiment, the first network entity and the second network entity can authenticate each other.

[0178] For example, with reference to Figure 7 and Figure 9 After receiving the authentication list 730 from the network entity A (i.e., the component 920 in Figure 9 the hub 990 can be configured to announce the authentication list 730 to a network entity M (i.e., the component 910 in Figure 9 In some implementations, the hub 990 can be configured to announce the authentication list 730 to an agent deployed in the network entity M.

[0179] According to an embodiment, the advertising of the first authentication list can be performed via an advertising interface. According to an embodiment, the advertising interface can comprise an interface such as a REST API. According to an embodiment, the first agent and the second agent can mutually authenticate with the hub.

[0180] After performing operation S1620, method 1600 can end or terminate. Alternatively, the hub can be configured to repeatedly (e.g., periodically, continuously, etc.) perform advertising the first authentication list (at operation S1620) for at least a predetermined amount of time. For example, the hub can update the first authentication list in response to changes in the network, and can then restart advertising the first authentication list.

[0181] Figure 17 FIG. 17 illustrates a flowchart of an example method 1700 for advertising an authentication list according to a push-pull model in a hub-and-spoke configuration, according to one or more embodiments. One or more operations of method 1700 can be part of operations S1610 and S1620 of method 1600, and can be performed by at least one processor (e.g., processor 420) of a hub communicatively coupled to a plurality of network entities in a system. It can be appreciated that one or more of the above operations can also be performed by the system including the hub, the system including the at least one processor, etc., without departing from the scope of the present disclosure.

[0182] As shown in FIG. 17, at operation S1710, the hub can be configured to register a first agent deployed in a first network entity and a second agent deployed in a second network entity. According to an embodiment, the hub can be configured to register the first agent and the second agent under a push-pull model. Figure 17 For example, the first agent and the second agent can be configured to register to an API function for the push-pull model during onboarding, where an account and API key will be confirmed by the API function and will be used for all API requests. The first agent and the second agent can then initiate a REST API POST request to subscribe to the push-pull model, and provide information such as an API key, a channel name for the subscription, and any additional parameters required by the function.

[0183] After performing operation S1710, method 1700 can then proceed to operation S1720, at which the hub can be configured to receive the first authentication list from the first agent in a similar manner as described above with respect to operation S1610. For example, with reference to FIG. 9,

[0184] Figure 9 for example, the hub 990 can be configured to receive an authentication list of components 920 in network entity A (e.g., network entity A 910) from an agent deployed in network entity A. Figure 9 for example, the hub 990 can be configured to receive an authentication list of components 920 in network entity A (e.g., network entity A 910) from an agent deployed in network entity A.​

[0185] Subsequently, the method 1700 can proceed to operation S1730, at which the hub can be configured to receive a second authentication list from the second agent. For example, with reference to Figure 9 , the hub 990 can be configured to receive an authentication list of the network entity M (e.g., the component 910 in the network entity M) from the agent deployed in the network entity M. According to an embodiment, the first network entity and the second network entity (with the first agent and the second agent deployed therein, respectively) can authenticate each other. It can be appreciated that the second authentication list can be created by the second agent in a similar manner as described above for the first agent in the peer-to-peer configuration. Figure 9

[0186] The method 1700 can then proceed to operation S1740, at which the hub can be configured to update the second authentication list to include the first authentication list. For example, with reference to Figure 9 , the hub 990 can be configured to update the authentication list of the network entity M to include the authentication list of the network entity A in a similar manner as described above with respect to operation S1425 in the method 1405.

[0187] Subsequently, the method 1700 can proceed to operation S1750, at which the hub can be configured to send a notification to the second agent. According to an embodiment, the notification can inform the second agent of the change in the network. For example, the notification can specify that the first network entity is newly deployed in the network, the first authentication list is received, the second authentication list has been updated, and so on.

[0188] According to an embodiment, an event tracker (e.g., the component 344 in Figure 3B ) of the hub can be configured to monitor data stored in the hub (e.g., data stored in a data store of the hub), track data received from and sent to the agent(s), and detect a change in the stored data (e.g., detect that the first authentication list is received from the first agent, the updated first authentication list is received from the first agent, the second authentication list has been updated, and so on). Subsequently, the event tracker can notify the data store of the hub of the change, and send the notification to the agent(s) with a notification mechanism / functionality (e.g., the component 343 in Figure 3B ) of the hub.

[0189] Accordingly, the method 1700 can then proceed to operation S1760, at which the hub can be configured to receive a request from the second agent to send the updated second authentication list. According to an embodiment, the second agent can be configured to send the request in response to receiving the notification and / or periodically.

[0190] ​After receiving the request at operation S1760, the method 1700 can then proceed to operation S1770, at which the hub can be configured to send the updated second authentication list to the second agent in response to receiving the request. For example, with reference to Figure 9 the hub 990 can be configured to send the updated authentication list of the network entity M to the agent deployed in the network entity M in a similar manner as described in operation S1435 in the method 1405 described above.

[0191] According to embodiments, the hub can be configured to store the received authentication lists as well as the updated authentication lists, such that the hub can act as a central agent or repository of all authenticated network entities (e.g., authenticated requesters) in the open front-haul network. In particular, the network topology mapper (e.g., component 345 in Figure 3B ) of the hub can use the stored authentication lists to form an integrated data store of authenticated network entities (e.g., authenticated network requesters) and create a topology map of all authenticated network entities in the open front-haul network. Thus, the hub can be configured to develop a real-time network mapping application that can build a comprehensive topology overview of all authenticated network entities based on the stored authentication lists.

[0192] According to embodiments, the sending of the updated second authentication list can be performed via an advertisement interface. According to embodiments, the advertisement interface can comprise an interface such as a REST API. According to embodiments, the first agent and the second agent can mutually authenticate with the hub.

[0193] After performing operation S1770, the method 1700 can end or terminate. Alternatively, the method 1700 can return to operation S1720, such that the hub can be configured to repeatedly perform receiving the first authentication list (at operation S1720), receiving the second authentication list (at operation S1730), updating the second authentication list (at operation S1740), sending the notification (at operation S1750), receiving the request (at operation S1760), and sending the updated second authentication list (at operation S1770) for at least a predetermined amount of time.

[0194] For example, the first network entity can perform a new authentication to the network entity (change in network), where the first authentication list is updated and sent to the hub in a similar manner as described above with respect to method 1400. Thus, the hub can receive the updated first authentication list (at operation S1720), and can then restart receiving the second authentication list (at operation S1730), updating the second authentication list (at operation S1740), sending the notification (at operation S1750), receiving the request (at operation S1760), and sending the updated second authentication list (at operation S1770).

[0195] Figure 18 FIG. 13 illustrates a flow diagram of an example method 1300 for announcing authentication lists according to a subscription notification model in a hub-and-spoke configuration, according to one or more embodiments. One or more operations of method 1300 can be part of operations S1310 and S1320 of method 1200, and can be performed by at least one processor (e.g., processor 420) of a hub communicatively coupled to a plurality of network entities in a system. It can be appreciated that the one or more operations described above can also be performed by the system including the hub, the system including the at least one processor, etc., without departing from the scope of the present disclosure.

[0196] As shown in operation S1310, the hub can be configured to register a first agent deployed in a first network entity and a second agent deployed in a second network entity. According to an embodiment, the hub can be configured to register the first agent and the second agent under a subscription notification model. Specifically, the first agent and the second agent can be configured to subscribe to a centralized endpoint URL of the hub using a REST API, where a subscription management function API of the hub manages the subscription, publication, and notification processes. Subsequently, the hub can respond to the first agent and the second agent with a success status code to indicate that the subscription is successful, and can keep the connection between the hub and the first agent and the second agent open. Figure 18

[0197] Subsequently, method 1300 can proceed to operation S1320, where the hub can be configured to receive the first authentication list from the first agent in a similar manner as described above with respect to operation S1310. According to an embodiment, the first agent can be configured to periodically send the first authentication list. Method 1300 can then proceed to operation S1330, where the hub can be configured to receive the second authentication list from the second agent. According to an embodiment, the second agent can be configured to periodically send the second authentication list. According to an embodiment, the first network entity and the second network entity can authenticate each other.

[0198] ​After performing operation S1830, the method 1800 can then proceed to operation S1840, at which the hub can be configured to update the second authentication list to include the first authentication list in a similar manner as described in operation S1425 in the above-described method 1405.

[0199] Accordingly, the method 1800 can then proceed to operation S1850, at which the hub can be configured to send the updated second authentication list to the second agent. According to an embodiment, the hub can be configured to periodically send the updated second authentication list. For example, with reference to Figure 9 At operation S1850, the hub 990 can be configured to send the updated authentication list of the network entity M (which includes the authentication list of the network entity A) to the agent deployed in the network entity M in a similar manner as described in operation S1435 in the above-described method 1405.

[0200] After performing operation S1850, the method 1800 can end or terminate. Alternatively, the method 1800 can return to operation S1820 such that the hub can be configured to repeatedly (e.g., periodically, continuously, etc.) perform receiving the first authentication list (at operation S1820), receiving the second authentication list (at operation S1830), updating the second authentication list (at operation S1840), and sending the updated second authentication list (at operation S1850) for at least a predetermined amount of time.

[0201] For example, the first and second network entities (or agent(s) deployed therein) can periodically (or continuously) send the first and second authentication lists to the hub. Accordingly, the hub can periodically (or continuously) receive the first and second authentication lists and can then restart operations S1820-S1850. Further, during the above-described periodic transmission, the first network entity can newly authenticate to the network entity (change in the network), where the first authentication list is updated and sent to the hub in a similar manner as described above with respect to the method 1400.

[0202] According to an embodiment, in a similar manner as described in operations S1750-S1770 in the above-described method 1700, the hub can be configured to additionally send the notification to the second agent, receive the request from the second agent, and send the updated second authentication list to the second agent.

[0203] Figures 19A-19C FIGURE 13 illustrates an example flow diagram of an example use case for announcing authenticated network entities according to a push-pull model in a hub-and-spoke configuration, according to one or more embodiments. Figures 19A-19CThe example flow sequence in FIG. 6 can involve the processes explained above with respect to method 1600 and method 1700.

[0204] As shown in FIG. 7, the network includes 3 network entities (network entity 1, network entity 2, and network entity 3) with respective deployed proxies (proxy 1, proxy 2, and proxy 3) and a central service (hub) located at an authentication server. Figures 19A-19C

[0205] Prior to step 1, network entity 1, network entity 2, and network entity 3 (with respective deployed proxies 1, 2, and 3) can subscribe (register) to the hub under a push-pull model.

[0206] During steps 1-3, network entity 1 can perform authentication to network entity 2 via an 802.1x process (i.e., an authentication process according to the EAP-TLS authentication protocol of RFC 5216 of IEEE 802.1x). If the authentication is successful, the sequence proceeds to step 4. On the other hand, if the authentication is not successful, network entity 2 can issue a security alert and can block data traffic to and from network entity 1.

[0207] During steps 4-5, network entity 2 can create / update its authentication list and can advertise its authentication list to the hub through a secure connection.

[0208] During step 6, network entity 2 can form a direct trust with network entity 1. For example, after the hub receives the authentication list of network entity 2, the hub can be configured to create / update a trust list based on the authentication list of network entity 2 that specifies network entity 1, the trust list specifying that the level of trust between network entity 2 and network entity 1 is a direct trust.

[0209] During steps 7-11, network entity 3 can perform authentication to network entity 2 in a similar manner as described above with respect to steps 1-5, can create / update its authentication list, and can advertise its authentication list to the hub.

[0210] After step 11, the hub can send a notification about network changes to network entity 1, network entity 2, and network entity 3.

[0211] During steps 12-14, network entity 1, network entity 2, and network entity 3 can send a request for an updated authentication list to the hub, and then the hub can send the updated authentication list to network entities 1, 2, and 3 accordingly.

[0212] ​During step 15, network entity 2 can form a direct trust with network entity 3. For example, the hub can update the authentication list of network entity 3 to include network entity 2, and can create / update a trust list based on the authentication list of network entity 3 specifying network entity 2 that specifies a level of trust between network entity 2 and network entity 3 is a direct trust.

[0213] During step 16, network entity 1 can form an indirect trust with network entity 3. For example, the hub can update the authentication list of network entity 3 to include the authentication list of network entity 2 that specifies network entity 1, and can create / update a trust list based on the authentication list of network entity 3 specifying network entity 1 that specifies a level of trust between network entity 3 and network entity 1 is an indirect trust.

[0214] It can be appreciated that the above features and configurations are simplified for purposes of description and are not intended to limit the scope of the present disclosure in any way. For example, in practice, the number of network entities in the system can be any number, the number of ports in each of the plurality of network entities can be any number, each of the plurality of network entities can authenticate to any other network entity, the order of the steps can be any different order, additional steps can be included, etc. Similarly, the authentication lists and trust lists can be any other form and can include any additional information as appropriate for the use case.

[0215] In view of the above, the example embodiments allow the hub and the agents to advertise the information of the authenticated network entities in a hub-and-spoke configuration. Thus, the hub and the agents can be easily notified of any changes in the network, and the agents can always have the latest version of the authentication list of each network entity in the network. Periodically or in response to a request, the hub can advertise the latest authentication list of the network entities across the network so that all network entities in the network can update their local authentication lists. In this way, the information of the direct or indirect trust connections between a network entity and any other network entity can become available to each network entity in the network. Furthermore, the example embodiments also guarantee that the hub is timely notified whenever there is new data available for transmission, and that the errors and retries are accommodated based on the "id" field to uniquely identify each message in case of any failure scenario. Example Operation: Determining Authentication Status Information for O-RUs

[0216] According to embodiments, a network entity of an open fronthaul network can include an O-RU controller, at least one TNE, and at least one O-RU, and the O-RU controller can be communicatively coupled to the at least one O-RU via the at least one TNE. The O-RU controller can include at least one of an O-DU and an SMO.

[0217] In this regard, the O-RU controller, TNE, and O-RU described above can include one or more of the components described above and / or can be configured to perform one or more of the operations described above. For example, the O-RU controller and / or O-RU can include at least one processor and can be configured to perform one or more operations to view and advertise information of authenticated network entities, etc. According to embodiments, the O-RU controller described herein can refer to a network entity, system, apparatus, etc. that includes at least one processor that can be configured to perform one or more operations described herein as well as one or more operations of the O-DU and / or SMO. Alternatively, the O-RU controller can refer to the at least one processor itself.

[0218] In addition to the operations described above, the O-RU can be authenticated via an authentication procedure (e.g., an 802. lx procedure), and the O-RU controller can be configured to perform one or more operations to determine authentication status information of the O-RU (e.g., whether the O-RU has been authenticated) and perform one or more operations based thereon.

[0219] In particular, the O-RU controller (or at least one processor associated therewith) can be configured to obtain information of a data link layer (also referred to herein as “Layer 2”) of the O-RU, such as a MAC address of the O-RU, and can utilize the information described above to determine the authentication status of the O-RU. Accordingly, the O-RU controller can establish a channel binding (e.g., a data link layer to application layer channel binding) and a chain of trust between the authenticated O-RU and the O-RU controller, and can isolate unauthenticated O-RUs from any further communication with the O-RU controller.

[0220] Figure 20 A block diagram illustrating an example system architecture 2000 of an open fronthaul network is shown in FIG. 2, according to one or more embodiments. As shown, the system architecture 2000 can include at least one O-RU 2010, at least one TNE 2020, and at least one O-RU controller 2030. It can be appreciated that in practice, the system architecture 2000 can include more than one O-RU, more than one TNE, and / or more than one O-RU controller without departing from the scope of the present disclosure. Figure 20

[0221] ​The O-RU controller 2030 can include an O-DU or an SMO. The O-RU 2010, the TNE 2020, and the O-RU controller 2030 can authenticate with each other via an authentication procedure (e.g., an 802. lx procedure). The O-RU controller 2030 can obtain (or can be provided with) information of a data link layer of the O-RU 2010 (e.g., a MAC address in the O-RU 2010), and can determine an authentication status of the O-RU 2010 based thereon. For example, the O-RU controller 2030 can determine whether the O-RU 2010 has been authenticated based on the MAC address of the O-RU 2010. Thus, based on determining that the O-RU 2010 is successfully authenticated (or has a certain level of trust with the O-RU controller 2030 after the authentication procedure), the O-RU controller 2030 can establish a channel binding and / or a trust chain between the O-RU controller 2030 and the O-RU 2010. The channel binding and / or the trust chain can be established in one or more commissioning procedures of the O-RU 2010.

[0222] Figure 21 A block diagram illustrating another example system architecture 2100 of an open fronthaul network is shown, in accordance with one or more embodiments. The system architecture 2100 can include a first O-RU 2110, a second O-RU 2120, an O-RU controller 2130, and a plurality of TNEs 2140-2160. The O-RU controller 2130 can be communicatively coupled to the first O-RU 2110 via the TNE 2140 and the TNE 2150, and can be communicatively coupled to the second O-RU 2120 via the TNE 2160. According to an embodiment, the O-RU controller 2130 can act as a centralized controller or a hub (e.g., the hub 340) for controlling the O-RU 2110 and the O-RU 2120. Alternatively, the hub can be a component independent of the O-RU controller 2130, and the O-RU controller 2130 can be communicatively coupled to the hub to obtain information needed to control the O-RU 2110 and the O-RU 2120.

[0223] The first O-RU 2110 can include a port SuP20 with a MAC address M20 and a supplicant role that authenticates (e.g., via an 802. lx procedure) to a port AuP21 of the TNE 2140 with a MAC address M21 and an authenticator role. Similarly, the O-RU 2120, the TNE 2140, the TNE 2150, the TNE 2160, and the O-RU controller 2130 can authenticate to other network entity(ies) (e.g., via an 802. lx procedure).

[0224] Each network entity in system architecture 2100 can have an authentication list, a trust list, or a combination of authentication and trust lists (including corresponding authentication status information) built for it. The aforementioned authentication and trust lists can be collectively referred to as "trusted data storage" in this document. See below for reference. Figure 22 and Figure 23 supply Figure 21 A description of an example of trusted data storage for network entities.

[0225] Figure 22 The illustration shows a diagram of a pair of devices according to one or more embodiments. Figure 21 This is an example of trusted data storage associated with a network entity. Trusted data storage includes information associated with the authentication status of the network entity. For example, a network entity may be authenticated via an 802.1x process, and the trusted data storage associated with the network entity may include parameters (e.g., ID, description, tag, etc.) for defining the following: the port(s) authenticated via the 802.1x process, the role of the authenticated port, the MAC address of the authenticated port (illustrated as "source MAC"), and the MAC address of the port to which the authenticated port authenticated itself via the 802.1x process.

[0226] For example, trusted data store 2210 is constructed for O-RU 2110 and may include information about port SuP20 (i.e., the authenticated port of O-RU 2110), the role of port SuP20, the MAC address of port SuP20 (i.e., M20), and the MAC address (i.e., M21) of port AuP21 of TNE 2140 to which port SuP20 authenticates (e.g., via an 802.1x process). A similar description applies to trusted data stores 2220 through 2260, each trusted data store being correspondingly associated with O-RU 2120, TNE 2140, TNE 2150, TNE 2160, and O-RU controller 2130.

[0227] According to an embodiment, trusted data storage may include information about the trust level between network entities. For example, Figure 23 The illustration shows a diagram of a pair of devices according to one or more embodiments. Figure 21 Other examples of trusted data storage associated with network entities.

[0228] like Figure 23As shown, trusted data storage can include trust levels between one or more ports of a network entity and one or more ports of one or more other network entities that have a requester role. Trust levels can include either direct trust or indirect trust. For example, trusted data storage 2330 associated with TNE 2140 shows that a port with MAC address M21 (i.e., port AuP21 of TNE 2140) has a "direct trust" level with a port with MAC address M20 (e.g., port SuP20 of O-RU 2110), and a port with MAC address M23 (i.e., port SuP23 of TNE 2140) has an "indirect trust" level with a port with MAC address M26 (e.g., port SuP26 of O-RU controller 2130). Similar descriptions apply to trusted data stores 2310-2320 and 2340-2360, each of which is correspondingly associated with O-RU 2110, O-RU 2120, TNE 2150, TNE 2160 and O-RU controller 2130.

[0229] In some implementations, a trusted data store built for each network entity can be advertised across the open fronthaul network, and an integrated network-level trusted data store (such as a network-level authentication list and a network-level trust list) can be built (e.g., built by a hub, built by one or more network entities, etc.). The trusted data store can be advertised or shared among network entities in a similar manner to that described above, for example, in peer-to-peer and / or hub-and-spoke configurations. Alternatively or concurrently, the trusted data store for all network entities can be managed by a centralized agent (e.g., a hub, a centralized service, etc.).

[0230] Therefore, whenever the O-RU controller communicates with the O-RU for the first time (e.g., during the O-RU's initial startup process), the O-RU controller can determine the O-RU's authentication status information to ensure that the O-RU has been authenticated before further communication with the O-RU. Specifically, the O-RU controller can obtain the O-RU's data link layer information (e.g., MAC address), obtain the trusted data stores available in the open fronthaul network (or the trusted data stores associated with the O-RU), and determine the authentication status information based on this.

[0231] Understandable. Figure 20 and Figure 21 The block diagram and Figure 22 and Figure 23 The trusted data storage described herein is merely an example of a possible implementation, and the scope of this disclosure should not be limited thereto. Specifically, Figure 20 and / or Figure 21The open fronthaul network in FIG. 1 can include more / fewer components than shown and / or can be arranged in a different manner than shown. For example, according to embodiments, the O-RU(s) can be communicatively coupled to an authentication server (i.e., a server that performs an authentication procedure for the O-RU) via one or more TNEs, the O-RU controller can be communicatively coupled to a hub / centralized agent, and / or the like, without departing from the scope of the present disclosure. Figure 22 and Figure 23 The trusted data store in FIG. 1 can include more / fewer pieces of information than shown.

[0232] Figure 24 FIG. 13 illustrates a flow diagram of an example method 1300 for determining authentication status information for an O-RU and for managing communications with the O-RU, according to one or more embodiments. One or more operations of the method 1300 can be performed by an O-RU controller (or at least one processor associated therewith).

[0233] As shown in FIG. 13, at operation S1310, the O-RU controller can be configured to obtain a MAC address of the O-RU. Example operations for obtaining the MAC address of the O-RU are described below with reference to Figure 24 Figure 27A and Figure 27B FIG. 14 illustrates a flow diagram of an example method 1400 for obtaining a MAC address of an O-RU, according to one or more embodiments. One or more operations of the method 1400 can be performed by an O-RU controller (or at least one processor associated therewith).

[0234] After performing operation S1310, the method 1300 can proceed to operation S1320, at which the O-RU controller can be configured to determine an authentication status of the O-RU. Specifically, the O-RU controller can determine its authentication status based on the MAC address of the O-RU. The authentication status of the O-RU can correspond to an Extensible Authentication Protocol Transport Layer Security (EAP-TLS) authentication procedure for the O-RU. For example, the O-RU controller can determine, based on the MAC address of the O-RU, whether the O-RU has been authenticated via an 802. lx procedure (e.g., an EAP-TLS authentication procedure, and / or the like). Example operations for determining the authentication status of the O-RU are described below with reference to Figure 25

[0235] After performing operation S1320, the method 1300 can proceed to operation S1330, at which the O-RU controller can be configured to manage communications with the O-RU. Specifically, the O-RU controller can be configured to manage communications with the O-RU based on determining whether the O-RU has been authenticated. Example operations for managing communications with the O-RU are described below with reference to Figure 26

[0236] ​​​To this end, the O-RU controller can efficiently and effectively determine the authentication status information of one or more O-RUs and can accordingly appropriately manage the communication with the one or more O-RUs.

[0237] Figure 25 FIGURE 21 illustrates a flow diagram of an example method 2100 for determining an authentication status of an O-RU, according to one or more embodiments. One or more operations of the method 2100 can be part of the operation S2200 of the method 2100 and can be performed by an O-RU controller (or at least one processor associated therewith).

[0238] As Figure 25 indicated at operation S2110, the O-RU controller can be configured to obtain at least one trusted data store. The trusted data store can include at least one of the authentication list and the trust list described above. According to an embodiment, the O-RU controller can obtain all available trusted data store(s). Alternatively, the O-RU controller can obtain the trusted data store(s) associated with the O-RU. For example, the O-RU control can search for one or more trusted data stores associated with the O-RU from a plurality of trusted data stores available in the network based on the ID of the O-RU (or any other suitable parameter defining the identity of the O-RU).

[0239] According to an embodiment, the O-RU controller can be configured to obtain the trusted data store from a memory (e.g., the storage 440) associated with the O-RU controller. Alternatively, the trusted data store can be stored in another network entity (e.g., a hub or the like) and the O-RU controller can be configured to communicate with the above-mentioned network entity and obtain the trusted data store therefrom. For example, when the O-RU controller is an O-DU, the O-RU controller can obtain the trusted data store from an SMO, a hub, or other network entity in the network. In some implementations, the O-RU controller can be configured to obtain a first trusted data store from a storage device associated with the O-RU controller and a second trusted data store from another network entity.

[0240] After performing operation S2110, the method 2100 can proceed to operation S2120 at which the O-RU controller can be configured to cross-reference the MAC address of the O-RU with a plurality of MAC addresses included in the trusted data store. By cross-referencing the MAC address of the O-RU with the plurality of MAC addresses in the trusted data store, the O-RU controller can determine whether the MAC address of the O-RU is included in the plurality of MAC addresses of the trusted data store.

[0241] Based on determining that the MAC address of the O-RU is included in the plurality of MAC addresses in the trusted data store, the method 2500 can proceed to operation S2530 at which the O-RU controller can be configured to determine that the O-RU has been authenticated. Specifically, by determining that the MAC address of the O-RU is included in the trusted data store, the O-RU controller can determine that the information of the O-RU is included in the trusted data store, which indicates that the O-RU has been authenticated via an authentication process (e.g., an 802. lx process) and that the O-RU is valid and trustworthy.

[0242] Otherwise, based on determining that the MAC address of the O-RU is not included in the plurality of MAC addresses in the trusted data store, the method 2500 can proceed to operation S2540 at which the O-RU controller can be configured to determine that the O-RU has not been authenticated. Specifically, by determining that the MAC address of the O-RU is not included in the trusted data store, the O-RU controller can determine that the information of the O-RU is not included in the trusted data store. This indicates that the O-RU has not been authenticated via an authentication process (e.g., an 802. lx process) and that the O-RU is not verified and trustworthy.

[0243] According to embodiments, based on determining that the O-RU (and / or the associated MAC address) is included in the trusted data store, the O-RU controller can determine a trust level of the O-RU (e.g., direct trust, indirect trust, etc.) and can determine whether the O-RU is verified and trustworthy based thereon.

[0244] Figure 26 FIG. illustrates a flow diagram of an example method 2600 for managing communications with an O-RU, according to one or more embodiments. One or more operations of the method 2600 can be part of the operations S2420 and S2430 in the method 2400 and can be performed by the O-RU controller (or at least one processor associated therewith).

[0245] As Figure 26 indicated, at operation S2610, the O-RU controller can be configured to determine whether the O-RU is authenticated. The operation S2610 can be similar to one or more operations described above with reference to the method 2500 and can be part of the operation S2420 in the method 2400.

[0246] Based on determining that the O-RU has been authenticated, the method 2600 can proceed to operation S2620 at which the O-RU controller can be configured to establish a channel binding with the O-RU. As defined in one or more specifications (e.g., Request for Comments (RFC) specifications, etc.) of one or more standards organizations (e.g., Internet Engineering Task Force (IETF), etc.), the term “channel binding” described herein can refer to a feature of binding authentication information to a communication channel (e.g., a TLS channel, etc.) between the O-RU controller and the O-RU. For example, the channel binding can bind information of an authenticated channel (e.g., a TLS channel) to an authenticated event (e.g., an access from an authenticated O-RU, a communication session with an authenticated O-RU, etc.). By establishing the channel binding, the communication between the O-RU controller and the O-RU can be protected, and potential security risks (e.g., session hijacking, etc.) can be prevented.

[0247] Otherwise, based on determining that the O-RU has not been authenticated, the method 2600 can proceed to operation S2630 at which the O-RU controller can be configured to isolate the O-RU from further communication with the O-RU controller. In this way, any further communication between the unauthenticated O-RU and the O-RU controller can be avoided, thereby preventing any potential security issues (e.g., O-RU identity spoofing, etc.) that the unauthenticated O-RU has.

[0248] According to embodiments, the establishment of the channel binding with the authenticated O-RU (at operation S2620) or the isolation of the unauthenticated O-RU (at operation S2630) can be performed during a TLS session establishment phase (described below with reference to Figure 28A and Figure 28B to example use cases associated therewith). Additionally or alternatively, the establishment of the channel binding with the authenticated O-RU or the isolation of the unauthenticated O-RU can be performed during a Network Configuration Protocol (NETCONF) session establishment phase (described below with reference to Figure 28A and Figure 28C to example use cases associated therewith).

[0249] Example operations for obtaining a MAC address of an O-RU are described below with reference to Figure 27A and Figure 27B . Figure 27A FIG. 13 illustrates a flowchart of an example method 1300 for obtaining a MAC address of an O-RU, according to one or more embodiments. One or more operations of the method 1300 can be part of the operation S2510 in the method 2500, and can be performed by the O-RU controller (or at least one processor associated therewith) during a TLS session establishment phase.

[0250] AsFigure 27A As shown, at operation S2710, the O-RU controller can be configured to receive a vendor certificate from the O-RU. The vendor certificate can be pre-provisioned to the O-RU and can have the O-RU's MAC address embedded therein. For example, the vendor certificate may include a factory-pre-provisioned x.509 certificate, and the O-RU's MAC address may be embedded (e.g., by the O-RU's vendor, etc.) in an extension of the x.509 certificate (e.g., a Subject Alternate Name (SAN) field, etc.). The vendor certificate can be received by the O-RU controller during the mutual authentication process in the TLS session establishment phase. The mutual authentication process may include an mTLS process.

[0251] After performing operation S2710, method 2700 can proceed to operation S2720, where the O-RU controller can be configured to extract the MAC address of the O-RU from the vendor certificate. To this end, the O-RU controller can obtain the MAC address of the O-RU during the TLS session establishment phase.

[0252] Figure 27B A flowchart of another example method 2705 for obtaining the MAC address of an O-RU according to one or more embodiments is illustrated. One or more operations of method 2705 may be part of operation S2510 in method 2500 and may be performed by the O-RU controller (or at least one processor associated therewith) during the NETCONF session establishment phase.

[0253] like Figure 27B As shown, at operation S2715, the O-RU controller can be configured to send a request for O-RU information to the O-RU. Specifically, the requested O-RU information may include the O-RU's MAC address and O-RU inventory information (e.g., serial number, etc.). The O-RU controller may require the O-RU's inventory information when providing NETCONF configuration information to the O-RU. The O-RU controller may send the request to the O-RU during the NETCONF session establishment phase.

[0254] Subsequently, at operation S2725, the O-RU controller can be configured to receive O-RU information from the O-RU (as requested at operation S2715). The received O-RU information may include the O-RU's MAC address and the O-RU's inventory information (e.g., serial number, etc.).

[0255] After receiving the O-RU information at operation S2725, the method 2705 can proceed to operation S2735 at which the O-RU controller can be configured to extract the MAC address of the O-RU from the O-RU information. To this end, the O-RU controller can obtain the MAC address of the O-RU during the NETCONF session establishment phase.

[0256] Reference is made below to Figures 28A-28C Example use cases associated with the operations of the methods 2400, 2500, 2600, 2700, and 2705 are provided. Specifically, according to one or more embodiments, Figure 28A a flow diagram illustrating an example use case of an initial boot procedure of an O-RU, Figure 28B a flow diagram illustrating an example use case for determining authentication status information of an O-RU and for managing communications with the O-RU during a TLS session establishment phase, Figure 28C a flow diagram illustrating an example use case for determining authentication status information of an O-RU and for managing communications with the O-RU during a NETCONF session establishment phase.

[0257] Reference is made below to Figure 28A , the O-RU can act as a TLS server / NETCONF server, the O-RU controller can act as a TLS client / NETCONF client, and a vendor certificate (e.g., an x.509 certificate) can be pre-provisioned to the O-RU. The vendor certificate can or can not have the MAC address of the O-RU embedded therein.

[0258] During step 1, the O-RU is powered on in an initial state. For example, the O-RU can be powered on during an O-RU initial boot procedure.

[0259] During step 2, the O-RU can perform an authentication procedure. For example, the O-RU can perform an 802. lx procedure with a TNE. The TNE can communicatively couple the O-RU to an O-RU controller and / or to a public key infrastructure (PKI) of an operator, such as an operator certificate authority (CA). The 802. lx procedure can include one or more EAP-TLS authentication procedures, and the one or more EAP-TLS authentication procedures can include one or more authentication procedures that comply with the IEEE 802. lx compliant RFC 5216 EAP-TLS authentication protocol. Further, the EAP-TLS authentication operations can be performed based on a vendor certificate of the O-RU and / or based on an operator signed certificate provided by the operator CA.

[0260] If the authentication is successful, the flow sequence can proceed to a further step. For example, after successful authentication with the TNE, the O-RU can be allowed to further communicate with the O-RU controller and / or the operator CA. For example, after determining that the O-RU has successfully authenticated via the 802. lx process, the TNE port communicatively coupled to the O-RU can allow further traffic to and from the O-RU such that the O-RU can communicate with the O-RU controller and / or the operator CA.

[0261] On the other hand, if the authentication is not successful, the O-RU can be isolated from the network. For example, after determining that the authentication has failed (e.g., the 802. lx process was not successful, etc.), the TNE can block traffic for the O-RU and, thus, the flow sequence can end and the O-RU can be isolated and communication between the O-RU and the O-RU controller and / or the operator CA is not allowed.

[0262] During step 3, the O-RU (which has successfully authenticated in step 2) can communicate with the operator CA to perform certificate registration. For example, the O-RU can obtain one or more operator signed certificates (e.g., one or more x.509 certificates) from the operator CA. According to embodiments, in addition to the operator signed certificate(s), the O-RU can obtain one or more trust anchors from the operator CA. In this regard, the trust anchors can include information that the O-RU can use to verify the identity of the operator CA. For example, the trust anchors can include a root certificate, a public key, and identity information (e.g., a domain name, etc.) of the operator CA.

[0263] Subsequently, during step 4, the O-RU can be reinitialized / reset and the flow sequence can return to step 1. In this regard, the O-RU can be reauthenticated via an authentication process (e.g., the 802. lx process) based on the operator signed certificate(s). It is contemplated that steps 3 and 4 described herein can be optional. For example, steps 3 and 4 can be performed when an operator CA is available in the open fronthaul network. On the other hand, if no operator CA is available in the network, steps 3 and 4 can be omitted.

[0264] To this end, the initial authentication of the O-RU is complete and the O-RU can communicate with the O-RU controller to perform further operations. For example, after successfully authenticating based on the vendor certificate (and the operator signed certificate, if available), the TNE can allow traffic to and from the O-RU and the O-RU can communicate with the O-RU controller to establish a TLS session / connection.

[0265] In this regard, communication between the O-RU and its controller is conducted via a Transmission Control Protocol (TCP) session. A TLS session is established during the NETCONF call home registration process within the TCP session, thereby enabling reliable and secure communication between the O-RU and its controller. For example, after establishing the TCP session, the O-RU and its controller can exchange information for establishing the TLS session via a secure channel.

[0266] The TLS session establishment phase involves a series of processes in which both the TLS client (i.e., the O-RU controller) and the TLS server (i.e., the O-RU) participate to establish a secure communication channel between them. Mutual authentication is one process within the TLS session establishment phase, where the TLS client and TLS server verify each other's identity by exchanging one or more security certificates (e.g., one or more x.509 certificates, etc.). The mutual authentication process may include the mTLS process.

[0267] In this regard, after receiving a security certificate (e.g., a vendor certificate) from the O-RU during the mutual authentication process, if the O-RU controller determines that the O-RU's MAC address is available in the security certificate (e.g., the O-RU's MAC address is embedded in the vendor certificate), the O-RU controller can initiate operations to determine the O-RU's authentication status information and, based on this, manage communication with the O-RU (see below). Figure 28B Provide a description of example use cases.

[0268] According to an embodiment, if the O-RU controller determines that the O-RU's MAC address is not available in the security certificate (e.g., the MAC address is not embedded in the vendor certificate), the O-RU controller can complete the TLS session establishment phase and can obtain the O-RU's MAC address in a later phase. For example, after a successful TLS connection is established between the O-RU controller and the O-RU, the O-RU controller can request the MAC address during the NETCONF session establishment phase (see below). Figure 28C (A description of example use cases is provided). Therefore, in the following description, Figure 28B and Figure 28C The process sequence can begin from step 5, indicating that the above process sequence is... Figure 28A The continuation of the process sequence.

[0269] refer to Figure 28BDuring step 5, a TCP session can be established between the O-RU and the O-RU controller. During step 6, the O-RU controller (i.e., TLS client) can send a client hello message to the O-RU (i.e., TLS server) to initiate a TLS handshake procedure. The client hello message can include information associated with the O-RU controller, such as supported encryption algorithms, supported TLS versions, and any other suitable information. Subsequently, during step 7, the O-RU can send a server hello message to the O-RU controller in response to receipt of the client hello message.

[0270] Further, during step 8, the O-RU can send a vendor certificate (i.e., x.509 certificate with the MAC address of the O-RU embedded therein) and a request for a TLS client certificate (e.g., operator signed certificate) to the O-RU controller. As part of the mutual authentication procedure, the vendor certificate can act as a TLS server certificate and can be used by the O-RU controller to authenticate the O-RU, and the TLS client certificate can be used by the O-RU to authenticate the O-RU controller. In light of the foregoing, the O-RU controller can receive the vendor certificate and the request for the TLS client certificate from the O-RU during the TLS session establishment phase.

[0271] During step 9, the O-RU controller can extract the MAC address of the O-RU from the vendor certificate in a similar manner as described above with reference to method 2700 in FIG. 27. Figure 27A

[0272] During step 10, the O-RU controller can verify the MAC address of the O-RU prior to providing the requested TLS client certificate to the O-RU. For example, as part of the mutual authentication procedure using the vendor certificate (e.g., x.509 certificate), the O-RU controller can verify the certificate file validation path of the O-RU and / or match the contents of the vendor certificate with a previously trusted value.

[0273] According to embodiments, the O-RU controller can obtain a trusted data store and can determine an authentication status of the O-RU (based on the MAC address of the O-RU and information in the trusted data store) in a similar manner as described above with reference to method 2400 and method 2500. The authentication status of the O-RU can correspond to an 802. lx procedure (e.g., EAP-TLS authentication procedure) of the O-RU. According to embodiments, the O-RU controller can obtain the trusted data store from a hub or centralized service / proxy. Alternatively, the O-RU controller can obtain the trusted data store from a storage device (e.g., storage device 440) associated with the O-RU controller.

[0274] ​Accordingly, based on determining that the O-RU has been authenticated, the O-RU controller can establish a channel binding with the O-RU. Subsequently, after the channel binding is successful, during step 11, the O-RU controller can send the TLS client certificate (e.g., the operator signed certificate requested by the O-RU at step 8) to the O-RU and can continue the TLS session establishment procedure.

[0275] Otherwise, based on determining that the O-RU has not been authenticated, or based on determining that the channel binding is not successful, during step 12, the O-RU controller can isolate the O-RU from further communication with the O-RU controller (e.g., interrupt communication with the O-RU, perform network isolation on the O-RU, etc.). In this case, the session teardown occurs at the TLS session establishment phase, disallowing the unauthenticated O-RU to further communicate with the O-RU controller.

[0276] In addition to or as an alternative to providing the MAC address of the O-RU to the O-RU controller by embedding the MAC address in the vendor certificate, the O-RU can also provide the MAC address to the O-RU controller in response to a request or query from the O-RU controller.

[0277] Reference is made to Figure 28C During step 5, a TCP session can be established between the O-RU and the O-RU controller in a similar manner as described above with respect to step 5 in Figure 28B In this regard, it is contemplated that one or more operations in Figure 28C may be similar to one or more operations in Figure 28B For example, step 5, step 10, and step 12 of Figure 28C may be respectively similar to step 5, step 10, and step 12 of Figure 28B Figure 28C The example use case of Figure 28B differs from the example use case of Figure 28B in that, unlike the example use case in Figure 28C does not require embedding the MAC address of the O-RU in the vendor certificate. Rather, after the TLS connection is established, the O-RU controller can obtain the MAC address of the O-RU at the NETCONF session establishment phase. When the vendor of the O-RU does not embed the MAC address of the O-RU in the vendor certificate (e.g., x.509 certificate), Figure 28C the example use case of

[0278] ​During step 6, the TLS connection is successfully established, and the NETCONF session establishment phase can be initiated. During step 7, the O-RU controller (i.e., the NETCONF client) can query or send a request to the O-RU (i.e., the NETCONF server) to retrieve O-RU information. The requested O-RU information can include inventory information of the O-RU (e.g., serial number of the O-RU, etc.) and the MAC address of the O-RU that are needed for the NETCONF session establishment phase. Thus, during step 8, the O-RU can provide the requested O-RU information (including the MAC address of the O-RU and the O-RU inventory information) to the O-RU controller, and the O-RU controller can receive the O-RU information from the O-RU.

[0279] During step 9, the O-RU controller can extract the MAC address of the O-RU from the O-RU information. Figure 28C Steps 7, 8, and 9 in FIG. 7 can be performed in a similar manner as described above with reference to steps 7, 8, and 9 of the method 2705 in FIG. 27. Figure 27B

[0280] Subsequently, during step 10, in a similar manner as described above with reference to step 10 of the method 2705 in FIG. 27, the O-RU controller can verify the MAC address of the O-RU and can determine the authentication status of the O-RU (based on the MAC address of the O-RU and the information in the trusted data store). Figure 28B Figure 28B Thus, during step 11, in a similar manner as described above with reference to steps 10 to 12 of the method 2705 in FIG. 27, the O-RU can establish a channel binding with the O-RU (based on determining that the O-RU has been authenticated), or can isolate the O-RU from any further communication with the O-RU controller (based on determining that the O-RU is not authenticated).

[0281] In this case, the session teardown occurs during the NETCONF session establishment phase, disallowing the unauthenticated O-RU to further communicate with the O-RU controller. On the other hand, based on determining that the O-RU has been authenticated and the channel binding is successful, during step 11, the O-RU controller can generate (based on the O-RU information) one or more NETCONF configuration information and can send the one or more NETCONF configuration information to the O-RU. The NETCONF session establishment process can then continue.

[0282] ​​In this regard, the one or more NETCONF configuration information can define one or more NETCONF configurations. According to embodiments, the one or more NETCONF configuration information can comprise information associated with configuration management, such as information for managing one or more configurations associated with the O-RU. For example, the one or more NETCONF configuration information can comprise information for managing frequency configurations of the O-RU (e.g., carrier frequency, channel bandwidth, etc.), information for managing power configurations of the O-RU (e.g., transmission power level to meet signal quality requirements, power control parameters to achieve power efficiency, etc.), information for managing cell configurations of a cell in which the O-RU is located (e.g., cell identity, cell type, supported handover and mobility mechanisms, etc.), and any other suitable information for managing the configuration(s) of the O-RU to bring the O-RU to be on-line and operable.

[0283] It can be appreciated that Figures 28A-28C The steps shown in the flow sequence of Figures 28A-28C one or more steps shown in the flow sequence of

[0284] In view of the above, example embodiments of the present disclosure provide apparatuses, methods, etc. that enable the O-RU controller to effectively and efficiently determine the authentication status information of the O-RU. Specifically, example embodiments define a security mechanism or method for providing the O-RU controller with the data link layer information of the O-RU (e.g., the MAC address of the O-RU) and enabling the O-RU controller to determine the authentication status of the O-RU based on the data link layer information. Thus, the O-RU controller can decide based on this whether to establish a channel binding with the O-RU or to isolate the O-RU. In this way, the O-RU controller can effectively and efficiently manage the communication with one or more O-RUs connected thereto without implicitly or inherently trusting the one or more O-RUs described above. Ultimately, the security of the open fronthaul network can be enhanced and the communication between the one or more O-RUs and the O-RU controller can be securely established while meeting the zero trust model.

[0285] In the prior art, the SMO (service management and orchestration) or O-DU (O-RAN distributed unit) implicitly trusts the O-RU (O-RAN radio unit) to allow communication during startup and installation. No channel binding method is defined to verify the 802.1X authorization status of the O-RU in the open fronthaul network during the registration of the O-RU to the SMO and / or O-DU (collectively referred to as “O-RU controller”) before considering the O-RU as a trusted entity.

[0286] According to example embodiments of the present disclosure, the O-RU controller can establish a channel binding between the Ethernet layer and the application layer, thereby establishing a trust relationship with the O-RU in an open fronthaul network environment. According to example embodiments of the present disclosure, the O-RU controller can acquire knowledge of the IEEE 802. IX authorization port state of the O-RAN radio unit (O-RU). Thus, according to example embodiments of the present disclosure, a trust model and channel binding become available for open fronthaul networks. Thereby, enhanced security of communication between entities in the fronthaul network is ensured.

[0287] A description is provided below of some example embodiments according to the present disclosure. A. Channel binding during the TLS connection establishment phase. The O-RU shall include the MAC address of its NIC in the "extensions" section of its x.509 certificate. This MAC address will be used to verify the identity of the O-RU in the trusted data store during the mTLS communication that occurs between the O-RU & SMO and / or O-RU & O-DU during the TLS session establishment process. i. In the initial state, the O-RU shall be powered on. ii. The O-RU performs a successful 802. IX authentication to the switch using the pre-supplied factory (vendor) certificate, and the switch port now allows additional traffic to the O-RU controller (O-DU or SMO) using the open front-haul network. iii. The O-RU shall then communicate with the operator CA for certificate registration. iv. The O-RU re-initializes / reset and authenticates itself according to 802. IX using the operator signed x509 certificate. v. The communication between the O-RU and the O-RU controller (O-DU or SMO) occurs over the NETCONF protocol on Transport Layer Security (TLS) with mutual X.509 authentication. vi. The O-RU controller, acting as a TLS client, sends a client hello message to initiate the TLS handshake. vii. The TLS and NETCONF server, as the O-RU in the O-RAN network, sends a server hello message, a server certificate chain, and a CertificateRequest message to request a certificate from the client. viii. As part of the mutual authentication process using x.509 certificates, the client shall verify the server's certificate file validation path, or match the contents of the certificate against a previously trusted value. ix. The NETCONF and TLS client (i.e. O-RU controller) shall query the centralized agent of the trusted open fronthaul framework to compare the trust relationship of the MAC address of the O-RU in the trust table database. x. After the verification of the trust relationship is successfully completed, the SMO (Service Management Orchestrator) / O-DU can establish the channel binding. xi. After successfully binding the channel, the O-RU controller (TLS client) sends its own client certificate for establishing the TLS connection xii. If the trust relationship is not determined or not satisfied, the SMO or O-DU will perform network isolation on the O-RU and not allow any further communication between the O-RU and the SMO or between the O-RU and the O-DU, thus the TLS connection establishment phase occurs connection / session interruption. B. Channel binding during the NETCONF configuration phase. i. In the initial state, the O-RU shall be powered on. ii. The O-RU performs a successful 802.1X authentication to the switch using the pre-supplied factory (vendor) certificate and the switch port now allows further traffic to the O-RU controller (O-DU or SMO) using the open front-haul network. iii. Then, the O-RU shall communicate with the operator CA for certificate registration. iv. The O-RU re-initializes / reset itself using 802.1x using the operator signed x509 certificate and authenticates itself. v. According to the current M-PLANE specification of the O-RAN WG4 MP document, the communication between the O-RU and the O-RU controller [O-DU and / or SMO] occurs on the NETCONF protocol over Transport Layer Security (TLS) with mutual X.509 authentication. vi. The TLS connection is successfully established. vii. The NETCONF client [O-RU controller] queries to retrieve O-RU information such as serial number and MAC address from the O-RU (NETCONF server). viii. The O-RU sends the required details to the O-RU controller. ix. The NETCONF and TLS client (i.e. O-RU controller) shall query the centralized agent of the trusted open fronthaul framework to compare the trust relationship of the MAC address of the O-RU in the trust table database. x. Subsequently, the O-RU verifies the MAC address by cross-referencing it with the trusted data store stored in the centralized agent. xi. If the MAC address is deemed to be trustworthy, then additional NETCONF communication is allowed to proceed under which software and configuration management is performed on the O-RU. xii. If the trust relationship is not determined or satisfied, then the O-RU controller will perform network isolation on the O-RU and no additional communication between the O-RU and the SMO or O-DU is allowed. Example Implementation Environment

[0288] Figure 29 An illustration of an example environment 2900 in which systems and / or methods described herein can be implemented is illustrated. As shown, environment 2900 can include device(s) 2910, platform(s) 2920, and network(s) 2930. Devices of environment 2900 can interconnect via wired connections, wireless connections, or a combination of wired and wireless connections. Figure 29 Any of the functions and operations described above with reference to Figures 2-28C may be performed by any combination of elements as shown. Figure 29

[0289] According to embodiments, network entities described herein (e.g., O-RU controllers, etc.) can be stored, hosted, or deployed in cloud computing platform 2920. In this regard, device(s) 2910 can include devices, systems, equipment, etc. used by users (e.g., users of a marketing team, users of a network planning team, etc.) to access network entities and / or platform 2920. In this case, device(s) 2910 can include one or more devices capable of receiving, generating, storing, processing, and / or providing information associated with platform 2920.

[0290] Platform 2920 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information. In some implementations, platform 2920 can include a cloud server or a group of cloud servers. In some implementations, platform 2920 can be designed to be modular such that certain software components can be swapped in or out depending on particular needs. Thus, platform 2920 can be easily and / or quickly reconfigured for different uses.

[0291] In some implementations, as shown, platform 2920 can be hosted in cloud computing environment 2922. Notably, although implementations described herein describe platform 2920 as being hosted in cloud computing environment 2922, in some implementations, platform 2920 can not be cloud-based (i.e., can be implemented outside of a cloud computing environment), or can be partially cloud-based.

[0292] ​The cloud computing environment 2922 can host the environment of the platform 2920. The cloud computing environment 2922 can provide computing, software, data access, storage, etc. services that do not require end users (e.g., user devices 2910) to know the physical location and configuration of the system(s) and / or device(s) hosting the platform 2920. As shown, the cloud computing environment 2922 can include a set of computing resources 2924 (collectively, computing resources 2924, and individually, computing resource 2924).

[0293] The computing resources 2924 can include one or more personal computers, clusters of computing devices, workstation computers, server devices, or other types of computation and / or communication devices. In some implementations, the computing resources 2924 can host the platform 2920. Cloud resources can include compute instances executing in the computing resources 2924, storage devices provided in the computing resources 2924, data transfer devices provided by the computing resources 2924, etc. In some implementations, the computing resources 2924 can communicate with other computing resources 2924 via wired connections, wireless connections, or a combination of wired and wireless connections.

[0294] As Figure 29 Further shown, the computing resources 2924 can include a set of cloud resources, such as one or more applications (APPs) 2924-1, one or more virtual machines (VMs) 2924-2, one or more virtualized storage (VS) 2924-3, one or more hypervisors (HYPs) 2924-4, etc. While the current example embodiments reference virtualized network functions, it should be understood that one or more other embodiments are not so limited and can be implemented in at least one of containers, cloud-native services, one or more container platforms, etc. For example, in one or more other example embodiments, any of the above components can be software-based components deployed or hosted in, for example, a cluster of servers such as a hybrid cloud server, a data center server, etc. The software-based components can be containerized and can be deployed and controlled by one or more machines (referred to as “nodes”) that run or execute the containerized network elements. In this regard, the cluster of servers can contain at least one master node and a plurality of worker nodes, where the master node(s) control and manage the associated set of worker nodes.

[0295] The applications 2924-1 can include one or more software applications that can be provided to or accessed by the device 2910. The applications 2924-1 can eliminate the need to install and execute software applications on the device 2910. For example, the applications 2924-1 can include software associated with the platform 2920, and / or any other software that can be provided via the cloud computing environment 2922. In some implementations, one application 2924-1 can issue / receive information to / from one or more other applications 2924-1 via the virtual machines 2924-2.

[0296] The virtual machines 2924-2 can include a software implementation of a machine (e.g., a computer) that executes programs like a physical machine. The virtual machines 2924-2 can be a system virtual machine or a process virtual machine, depending on the extent to which the virtual machines 2924-2 use and correspond to any real machine. A system virtual machine can provide a complete system platform that supports execution of a complete operating system (OS). A process virtual machine can execute a single program, and can support a single process. In some implementations, the virtual machines 2924-2 can execute on behalf of a user (e.g., the user device 2910), and can manage infrastructure of the cloud computing environment 2922, such as data management, synchronization, or long-duration data transfers.

[0297] The virtualized storage 2924-3 can include one or more storage systems and / or one or more devices that use virtualization techniques within the storage systems or devices of the computing resource 2924. In some implementations, in the context of a storage system, types of virtualization can include block virtualization and file virtualization. Block virtualization can refer to abstraction (or separation) of logical storage from physical storage such that a storage system can be accessed without considering the physical storage or heterogeneous structure. This separation can allow an administrator of the storage system flexibility in how the administrator manages storage for end users. File virtualization can eliminate dependency on where data is physically stored for data accessed at a file level. This can enable optimization of storage usage, server consolidation, and / or performance of non-disruptive file migrations.

[0298] The hypervisor 2924-4 can provide hardware virtualization techniques that allow multiple operating systems (e.g., “guest operating systems”) to execute concurrently on a host (such as the computing resource 2924). The hypervisor 2924-4 can present a virtual operating platform to the guest operating systems, and can manage execution of the guest operating systems. Multiple instances of various operating systems can share virtualized hardware resources.

[0299] The network 2930 can comprise one or more wired and / or wireless networks. For example, the network 2930 can comprise a cellular network (e.g., a fifth generation (5G) network, a long-term evolution (LTE) network, a third generation (3G) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., the Public Switched Telephone Network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, a fiber optic-based network, and / or the like, and / or a combination of networks. For example, the network 2930 can establish

[0300] Figure 29 The number and arrangement of devices and networks shown are provided as examples. In practice, there can be additional devices and / or networks, fewer devices and / or networks, different devices and / or networks, or differently arranged devices and / or networks than those shown. Figure 29 More, fewer, or different devices and / or networks than those shown can be provided. Furthermore, Figure 29 Two or more devices shown can be implemented within a single device, or FIG. 29 A single device shown can be implemented as multiple, distributed devices. Additionally, or alternatively, a set of devices (e.g., one or more devices) of environment 2900 can perform one or more functions described as being performed by another set of devices of environment 2900.

[0301] According to embodiments, one or more operations of the example embodiments described above can be implemented or deployed in the server platforms 2920 in the form of virtualized network functions (VNFs), containerized and / or cloud-native functions (CNFs), and / or the like. In this regard, it is contemplated that the terms “virtual,” “virtualization,” and the like described above are intended to designate the nature of the machine (and elements and resources associated therewith) to be provided in virtual or software form. The terms “virtual machine,” “virtualized storage,” and the like described above are not to be limited to any particular type of virtual machine or virtual element. Thus, it will be appreciated that one or more operations of the example embodiments described above can be defined or presented in the form of containerized network functions, one or more operations of which can be provided in the form of containers. Various aspects of the embodiments

[0302] The above 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 above disclosure or can be acquired from practice of the implementations.

[0303] Some embodiments can relate to systems, methods, and / or computer-readable media at any possible level of integration. Also, one or more of the above-described components can be implemented as instructions stored on a computer-readable medium and executable by at least one processor (and / or can include at least one processor). A computer-readable medium can include computer-readable non-transitory storage media that has computer-readable program instructions thereon for use by or in connection with an instruction-execution device.

[0304] A computer-readable storage medium can be a tangible device that can retain and store instructions for use by an instruction-execution device. The computer-readable storage medium can be, for example, 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 of the foregoing. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch cards or

[0305] The computer-readable program instructions described herein can be downloaded to respective computing / processing devices from a computer-readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network can comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing device.

[0306] Computer readable program code / instructions for carrying out operations can be assembly instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like and procedural programming languages such as the "C" programming language or similar programming languages. The computer readable program instructions can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate array (FPGA), or programmable logic array (PLA) can execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects or operations.

[0307] These computer readable program instructions can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer readable program instructions can also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including

[0308] The computer readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0309] The diagrams in the figures illustrated the architectural, functional and operational concepts of possible implementations of systems, methods, and computer-readable media according to various embodiments. In this regard, each block in the flowcharts or block diagrams can represent a (one or more) microservice, instruction module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). The methods, computer systems, and computer-readable media can include more, fewer, or different blocks from those shown in the figures. In some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession can in fact be executed concurrently or in the reverse order, depending on the functionality involved. It will also be noted that each block of the block diagrams and / or flowcharts, and combinations thereof, can be implemented by special purpose hardware-based systems that perform the specified functions or actions, or combinations of special purpose hardware and computer instructions.

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

[0311] Various additional corresponding aspects and features of embodiments of the present disclosure can be defined by the following clauses: Clause [1]: An open radio access network (O-RAN) radio unit (O-RU) controller. The O-RU controller can be configured to: obtain a media access control (MAC) address of an O-RU; determine an authentication status of the O-RU based on the MAC address of the O-RU; establish a channel binding with the O-RU based on determining that the O-RU has been authenticated; and isolate the O-RU from further communication with the O-RU controller based on determining that the O-RU has not been authenticated. Clause [2]: The O-RU controller of Clause [1], wherein the authentication status of the O-RU can correspond to an extensible authentication protocol transport layer security (EAP-TLS) authentication procedure for the O-RU. Clause [3]: The O-RU controller of any of clauses [1] to [2], wherein the O-RU controller can be configured to obtain the MAC address of the O-RU by: receiving a vendor certificate from the O-RU, wherein the vendor certificate can include the MAC address of the O-RU; and extracting the MAC address of the O-RU from the vendor certificate. Clause [4]: The O-RU controller of clause [3], wherein the O-RU controller can be configured to: receive the vendor certificate and a first request for a TLS client certificate from the O-RU during a Transport Layer Security (TLS) session establishment phase. Clause [5]: The O-RU controller of clause [4], wherein the O-RU controller can be further configured to: send the TLS client certificate to the O-RU after the channel binding with the O-RU is established. Clause [6]: The O-RU controller of any of clauses [1] to [2], wherein the O-RU controller can be configured to obtain the MAC address of the O-RU by: sending a second request for O-RU information to the O-RU, wherein the O-RU information can include the MAC address of the O-RU; receiving the O-RU information from the O-RU; and extracting the MAC address from the O-RU information. Clause [7]: The O-RU controller of clause [6], wherein the O-RU controller can be configured to: send the second request for the O-RU information to the O-RU during a Network Configuration Protocol (NETCONF) session establishment phase. Clause [8]: The O-RU controller of clause [7], wherein the O-RU controller can be further configured to: generate one or more NETCONF configuration information based on the O-RU information; and send the one or more NETCONF configuration information to the O-RU after the channel binding with the O-RU is established. Clause [9]: The O-RU controller of any of clauses [1] to [8], wherein the O-RU controller can be configured to determine the authentication status of the O-RU by: obtaining a trusted data store associated with the O-RU; cross-referencing the MAC address of the O-RU with a plurality of MAC addresses included in the trusted data store to determine whether the MAC address of the O-RU is included in the plurality of MAC addresses; determining that the O-RU has been authenticated based on a determination that the MAC address of the O-RU is included in the plurality of MAC addresses; and determining that the O-RU has not been authenticated based on a determination that the MAC address of the O-RU is not included in the plurality of MAC addresses. Clause

[10] : The O-RU controller of clause [9], wherein the trusted data store can include at least one of an authentication list associated with the O-RU and a trust list associated with the O-RU. Clause

[11] : The O-RU controller of any of clauses [1] to

[10] , wherein the O-RU controller can include at least one of an O-RAN distributed unit (O-DU) and a service management and orchestrator (SMO). Clause

[12] : A method implemented by an open radio access network (O-RAN) radio unit (O-RU) controller. The method can include: obtaining a media access control (MAC) address of an O-RU; determining an authentication status of the O-RU based on the MAC address of the O-RU; establishing a channel binding with the O-RU based on a determination that the O-RU has been authenticated; and isolating the O-RU from further communication with the O-RU controller based on a determination that the O-RU has not been authenticated. Clause

[13] : The method of clause

[12] , wherein the authentication status of the O-RU can correspond to an extensible authentication protocol transport layer security (EAP-TLS) authentication procedure for the O-RU. Clause

[14] : The method of any of clauses

[12] to

[13] , wherein the obtaining the MAC address of the O-RU can include: receiving a vendor certificate from the O-RU, wherein the vendor certificate can include the MAC address of the O-RU; and extracting the MAC address of the O-RU from the vendor certificate. Clause

[15] : The method of clause

[14] , wherein the receiving the vendor certificate can include: receiving the vendor certificate and a first request for a TLS client certificate from the O-RU during a transport layer security (TLS) session establishment phase. Clause

[16] : The method of clause

[15] , wherein the method can further comprise: sending, to the O-RU, the TLS client certificate after the channel binding with the O-RU is established. Clause

[17] : The method of any of clauses

[12] to

[13] , wherein the obtaining the MAC address of the O-RU can comprise: sending, to the O-RU, a second request for O-RU information, wherein the O-RU information can comprise a serial number of the O-RU and the MAC address of the O-RU; receiving, from the O-RU, the O-RU information; and extracting the MAC address from the O-RU information. Clause

[18] : The method of clause

[17] , wherein the sending the second request for the O-RU information can comprise: sending, to the O-RU, the second request for the O-RU information during a network configuration protocol (NETCONF) session establishment phase. Clause

[19] : The method of clause

[18] , wherein the method can further comprise: generating one or more NETCONF configuration information based on the O-RU information; and sending, to the O-RU, the one or more NETCONF configuration information after the channel binding with the O-RU is established. Clause

[20] : A non-transitory computer-readable recording medium. The non-transitory computer-readable recording medium can have recorded thereon instructions executable by an open radio access network (O-RAN) radio unit (O-RU) controller to cause the O-RU controller to perform a method comprising: obtaining a media access control (MAC) address of an O-RU; determining an authentication status of the O-RU based on the MAC address of the O-RU; establishing a channel binding with the O-RU based on determining that the O-RU has been authenticated; and isolating the O-RU from further communication with the O-RU controller based on determining that the O-RU has not been authenticated. Clause

[21] : A network entity can be configured to: create a first authentication list, wherein the first authentication list can specify one or more network entities that are authenticated to the network entity; receive a second authentication list from a second network entity, wherein the second authentication list can specify one or more network entities that are authenticated to the second network entity, and wherein the network entity and the second network entity can authenticate each other; and create a trust list based on the first authentication list and the second authentication list, wherein the trust list can specify a level of trust between the network entity and one or more network entities in the first authentication list and the second authentication list. Clause

[22] : The network entity of clause

[21] , wherein: the trust level can comprise one of a direct trust and an indirect trust; and the trust level can be between one or more ports of the network entity and one or more ports of the one or more network entities of the first authentication list and the second authentication list having a requester role. Clause

[23] : The network entity of clause

[22] , wherein the trust list can comprise one or more MAC addresses of the one or more ports of the network entity and one or more MAC addresses of the one or more ports of the one or more network entities of the first authentication list and the second authentication list having the requester role. Clause

[24] : The network entity of any one of clauses

[21] to

[23] , wherein the network entity can be configured to create the trust list based on the first authentication list and the second authentication list by: creating the trust list based on the first authentication list such that the trust list specifies a trust level between the network entity and the one or more network entities of the first authentication list; updating the first authentication list to include the second authentication list in response to receiving the second authentication list; and updating the trust list based on the updated first authentication list such that the trust list also specifies a trust level between the network entity and the one or more network entities of the second authentication list. Clause

[25] : The network entity of clause

[24] , wherein the network entity can be further configured to send the updated first authentication list to the one or more network entities that authenticate to the network entity. Clause

[26] : The network entity of any one of clauses

[21] to

[25] , wherein: the second authentication list can also specify one or more network entities that authenticate to a third network entity; and the third network entity can authenticate to the second network entity. Clause

[27] : The network entity of any of clauses

[21] to

[26] , wherein: the first authentication list can specify one or more first MAC addresses of one or more ports of the network entity, one or more third MAC addresses of one or more ports of one or more network entities that are authenticated to the one or more first MAC addresses, and roles of the one or more ports of the network entity; the second authentication list can specify one or more second MAC addresses of one or more ports of the second network entity, one or more fourth MAC addresses of one or more ports of one or more network entities that are authenticated to the one or more second MAC addresses, and roles of the one or more ports of the second network entity; and the roles can include one of authenticator and supplicant. Clause

[28] : The network entity of any of clauses

[21] to

[27] , wherein authentication between the network entity, the second network entity, and the one or more network entities can be based on an 802. lx process. Clause

[29] : The network entity of any of clauses

[21] to

[28] , wherein the network entity, the second network entity, and the one or more network entities can include at least one of an O-RAN Centralized Unit (O-CU), an O-RAN Distributed Unit (O-DU), an O-RAN Radio Unit (O-RU), and a Transport Network Element (TNE). Clause

[30] : A hub can be configured to: receive a first authentication list from a first network entity, wherein the first authentication list can specify one or more network entities that are authenticated to the first network entity; receive a second authentication list from a second network entity, wherein the second authentication list can specify one or more network entities that are authenticated to the second network entity, and wherein the first network entity and the second network entity can authenticate to each other; and create a trust list for the first network entity based on the first authentication list and the second authentication list, wherein the trust list for the first network entity can specify a level of trust between the first network entity and one or more network entities in the first authentication list and the second authentication list. Clause

[31] : A method can comprise: creating a first authentication list for a first network entity, wherein the first authentication list can specify one or more network entities that are authenticated to the first network entity; receiving a second authentication list from a second network entity, wherein the second authentication list can specify one or more network entities that are authenticated to the second network entity, and wherein the first network entity and the second network entity can authenticate each other; and creating a trust list for the first network entity based on the first authentication list and the second authentication list, wherein the trust list for the first network entity can specify a level of trust between the first network entity and one or more network entities in the first authentication list and the second authentication list. Clause

[32] : The method of clause

[31] , wherein: the level of trust can comprise one of a direct trust and an indirect trust; and the level of trust can be between one or more ports of the first network entity and one or more ports of the one or more network entities in the first authentication list and the second authentication list that have a requestor role. Clause

[33] : The method of clause

[32] , wherein the trust list for the first network entity can comprise one or more MAC addresses of the one or more ports of the first network entity and one or more MAC addresses of the one or more ports of the one or more network entities in the first authentication list and the second authentication list that have the requestor role. Clause

[34] : The method of any one of clauses

[31] to

[33] , wherein creating the trust list for the first network entity based on the first authentication list and the second authentication list can comprise: creating the trust list based on the first authentication list such that the trust list specifies a level of trust between the first network entity and the one or more network entities in the first authentication list; updating the first authentication list to include the second authentication list in response to receiving the second authentication list; and updating the trust list based on the updated first authentication list such that the trust list also specifies a level of trust between the first network entity and the one or more network entities in the second authentication list. Clause

[35] : The method of clause

[34] , the method can further comprise: sending the updated first authentication list to the one or more network entities that are authenticated to the first network entity. Clause

[36] : The method of any one of clauses

[31] to

[35] , wherein: the second authentication list can also specify one or more network entities that are authenticated to a third network entity; and the third network entity can authenticate to the second network entity. Clause

[37] : The method of any of clauses

[31] to

[36] , wherein: the first authentication list can specify one or more first MAC addresses of one or more ports of the first network entity, one or more third MAC addresses of one or more ports of one or more network entities that authenticate to the one or more first MAC addresses, and roles of the one or more ports of the first network entity; the second authentication list can specify one or more second MAC addresses of one or more ports of the second network entity, one or more fourth MAC addresses of one or more ports of one or more network entities that authenticate to the one or more second MAC addresses, and roles of the one or more ports of the second network entity; and the roles can include one of authenticator and supplicant. Clause

[38] : The method of any of clauses

[31] to

[37] , wherein authentication between the first network entity, the second network entity, and the one or more network entities can be based on an 802. lx process. Clause

[39] : The method of any of clauses

[31] to

[38] , wherein the first network entity, the second network entity, and the one or more network entities can include at least one of the following: an O-RAN centralized unit (O-CU), an O-RAN distributed unit (O-DU), an O-RAN radio unit (O-RU), and a transport network element (TNE). Clause

[40] : A method can include receiving a first authentication list from a first network entity, wherein the first authentication list can specify one or more network entities that authenticate to the first network entity; receiving a second authentication list from a second network entity, wherein the second authentication list can specify one or more network entities that authenticate to the second network entity, and wherein the first network entity and the second network entity authenticate to each other; and creating a trust list for the first network entity based on the first authentication list and the second authentication list, wherein the trust list of the first network entity can specify a level of trust between the first network entity and one or more network entities in the first authentication list and the second authentication list. Clause

[41] : A network entity can be configured to: create a first authentication list, wherein the first authentication list can specify one or more network entities that authenticate to the network entity; and advertise the first authentication list to a second agent deployed in a second network entity, wherein the second network entity can authenticate to the network entity. Clause

[42] : The network entity of clause

[41] , wherein the network entity can be configured to advertise the first authentication list by sending the first authentication list to the second agent. Clause

[43] : The network entity of clause

[42] , wherein the network entity can be configured to: update the first authentication list to include one or more authentication lists received from one or more agents deployed in one or more network entities that are authenticated to the network entity; update the first authentication list to further specify one or more network entities that are newly authenticated to the network entity; and send the updated first authentication list to the one or more agents deployed in the one or more network entities that are authenticated to the network entity. Clause

[44] : The network entity of clause

[43] , wherein the network entity can include a first agent; and the first agent can be configured to: create the first authentication list, send the first authentication list, update the first authentication list, and send the updated first authentication list. Clause

[45] : The network entity of clause

[44] , wherein the first agent and the second agent can mutually authenticate each other via at least one of a digital certificate and an application programming interface (API) key. Clause

[46] : A hub can be configured to: receive a first authentication list from a first agent deployed in a first network entity, wherein the first authentication list can specify one or more network entities that are authenticated to the first network entity; and advertise the first authentication list to a second agent deployed in a second network entity, wherein the second network entity can be authenticated to the first network entity. Clause

[47] : The hub of clause

[46] , wherein the hub can be configured to receive a second authentication list from the second agent; and wherein the hub can be configured to advertise the first authentication list by: updating the second authentication list to include the first authentication list; and sending the updated second authentication list to the second agent. Clause

[48] : The hub of clause

[47] , wherein the hub can be configured to: send a notification to the second agent regarding the updated second authentication list; receive a request from the second agent to send the updated second authentication list; and send the updated second authentication list in response to receiving the request. Clause

[49] : The hub of any of clauses

[47] to

[48] , wherein: the first agent can be configured to periodically send the first authentication list; and the hub can be configured to execute the instructions to periodically send the updated second authentication list to the second agent. Clause

[50] : The hub of any of clauses

[46] to

[49] , wherein the hub can be communicatively coupled to the first agent and the second agent; and the first agent and the second agent can mutually authenticate to the hub via a two-way TLS (mTLS) procedure. Clause

[51] : A method can comprise: creating a first authentication list for a first network entity, wherein the first authentication list can specify one or more network entities that are authenticated to the first network entity; and advertising the first authentication list to a second agent deployed in a second network entity, wherein the second network entity can be authenticated to the first network entity. Clause

[52] : The method of clause

[51] , wherein the advertising the first authentication list can comprise sending the first authentication list to the second agent. Clause

[53] : The method of clause

[52] , the method can further comprise: updating the first authentication list to include one or more authentication lists received from one or more agents deployed in one or more network entities that are authenticated to the first network entity; updating the first authentication list to further specify one or more network entities that are newly authenticated to the first network entity; and sending an updated first authentication list to the one or more agents deployed in the one or more network entities that are authenticated to the first network entity. Clause

[54] : The method of clause

[53] , wherein: the first network entity comprises a first agent; and the first agent can be configured to: create the first authentication list, send the first authentication list, update the first authentication list, and send an updated first authentication list. Clause

[55] : The method of clause

[54] , wherein the first agent and the second agent can mutually authenticate to each other via at least one of a digital certificate and an application programming interface (API) key. Clause

[56] : A method can comprise: receiving a first authentication list from a first agent deployed in a first network entity, wherein the first authentication list can specify one or more network entities that are authenticated to the first network entity; and advertising the first authentication list to a second agent deployed in a second network entity, wherein the second network entity can be authenticated to the first network entity. Clause

[57] : The method of clause

[56] , the method can further include: receiving a second authentication list from the second agent; wherein the advertising the first authentication list can include: updating the second authentication list to include the first authentication list; and sending the updated second authentication list to the second agent. Clause

[58] : The method of clause

[57] , the method can further include: sending a notification to the second agent regarding the updated second authentication list; sending a notification to the second agent regarding the updated second authentication list; and sending the updated second authentication list in response to receiving the request. Clause

[59] : The method of any of clauses

[57] to

[58] , wherein: the first agent can be configured to periodically send the first authentication list; and the updated second authentication list can be periodically sent to the second agent. Clause

[60] : The method of any of clauses

[56] to

[59] , wherein: the receiving the first authentication list and the advertising the first authentication list can be performed by a hub communicatively coupled to the first agent and the second agent; and the first agent and the second agent can mutually authenticate to the hub via a bidirectional TLS (mTLS) procedure.

[0312] It is understood that many modifications and changes can be made to the present disclosure, which are intended to be subsumed within the scope of the present disclosure. It is obvious that the present disclosure can be practiced, without resort to the details of the theory thereof, as exemplified herein before.

Claims

1. An open radio access network (O-RAN) radio unit (O-RU) controller configured to: obtain a media access control (MAC) address of an O-RU; determine an authentication status of the O-RU based on the MAC address of the O-RU; establish a channel binding with the O-RU based on a determination that the O-RU has been authenticated; and isolate the O-RU from further communication with the O-RU controller based on a determination that the O-RU has not been authenticated.

2. The O-RU controller of claim 1, wherein the authentication status of the O-RU corresponds to an extensible authentication protocol transport layer security (EAP-TLS) authentication procedure for the O-RU.

3. The O-RU controller of claim 1, wherein the O-RU controller is configured to obtain the MAC address of the O-RU by: receiving a vendor certificate from the O-RU, wherein the vendor certificate includes the MAC address of the O-RU; and extracting the MAC address of the O-RU from the vendor certificate.

4. The O-RU controller of claim 3, wherein the O-RU controller is configured to receive the vendor certificate and a first request for a TLS client certificate from the O-RU during a transport layer security (TLS) session establishment phase.

5. The O-RU controller of claim 4, wherein the O-RU controller is further configured to send the TLS client certificate to the O-RU after the channel binding with the O-RU is established.

6. The O-RU controller of claim 1, wherein the O-RU controller is configured to obtain the MAC address of the O-RU by: sending a second request for O-RU information to the O-RU, wherein the O-RU information includes the MAC address of the O-RU; receiving the O-RU information from the O-RU; and extracting the MAC address from the O-RU information.

7. The O-RU controller of claim 6, wherein the O-RU controller is configured to send the second request for the O-RU information to the O-RU during a network configuration protocol (NETCONF) session establishment phase.

8. The O-RU controller of claim 7, wherein the O-RU controller is further configured to: generate one or more NETCONF configuration information based on the O-RU information; and send the one or more NETCONF configuration information to the O-RU after the channel binding with the O-RU is established.

9. The O-RU controller of claim 1, wherein the O-RU controller is configured to determine the authentication status of the O-RU by: obtaining a trusted data store associated with the O-RU; cross-referencing the MAC address of the O-RU with a plurality of MAC addresses included in the trusted data store to determine whether the MAC address of the O-RU is included in the plurality of MAC addresses; based on determining that the MAC address of the O-RU is included in the plurality of MAC addresses, determining that the O-RU has been authenticated; and based on determining that the MAC address of the O-RU is not included in the plurality of MAC addresses, determining that the O-RU has not been authenticated.

10. The O-RU controller of claim 9, wherein the trusted data store includes at least one of an authentication list associated with the O-RU and a trust list associated with the O-RU.

11. The O-RU controller of claim 1, wherein the O-RU controller includes at least one of an O-RAN distributed unit (O-DU) and a service management and orchestrator (SMO).

12. A method implemented by an open radio access network (O-RAN) radio unit (O-RU) controller, wherein the method comprises: obtaining a media access control (MAC) address of an O-RU; based on the MAC address of the O-RU, determining an authentication status of the O-RU; based on determining that the O-RU has been authenticated, establishing a channel binding with the O-RU; and based on determining that the O-RU has not been authenticated, isolating the O-RU from further communication with the O-RU controller.

13. The method of claim 12, wherein the authentication status of the O-RU corresponds to an extensible authentication protocol transport layer security (EAP-TLS) authentication procedure for the O-RU.

14. The method of claim 12, wherein the obtaining the MAC address of the O-RU comprises: receiving a vendor certificate from the O-RU, wherein the vendor certificate includes the MAC address of the O-RU; and extracting the MAC address of the O-RU from the vendor certificate.

15. The method of claim 14, wherein the receiving the vendor certificate comprises: receiving, from the O-RU, the vendor certificate and a first request for a TLS client certificate at a transport layer security (TLS) session establishment phase.

16. The method of claim 15, wherein the method further comprises: after the channel binding with the O-RU is established, sending the TLS client certificate to the O-RU.

17. The method of claim 12, wherein the obtaining the MAC address of the O-RU comprises: sending a second request for O-RU information to the O-RU, wherein the O-RU information includes a serial number of the O-RU and the MAC address of the O-RU; receiving the O-RU information from the O-RU; and extracting the MAC address from the O-RU information.

18. The method of claim 17, wherein the sending the second request for the O-RU information comprises: sending the second request for the O-RU information to the O-RU at a network configuration protocol (NETCONF) session establishment phase.

19. The method of claim 18, wherein the method further comprises: generating one or more NETCONF configuration information based on the O-RU information; and sending the one or more NETCONF configuration information to the O-RU after the channel binding with the O-RU is established.

20. A non-transitory computer-readable recording medium having recorded thereon instructions executable by an open radio access network (O-RAN) radio unit (O-RU) controller to cause the O-RU controller to perform a method comprising: obtaining a media access control (MAC) address of an O-RU; determining an authentication status of the O-RU based on the MAC address of the O-RU; establishing a channel binding with the O-RU based on determining that the O-RU has been authenticated; and isolating the O-RU from further communication with the O-RU controller based on determining that the O-RU has not been authenticated.

Images