Determination of authentication status information for O-RAN wireless unit

Abstract

Features are provided for determining authentication status information of an Open Radio Access Network (O-RAN) radio unit (O-RU). According to an embodiment, an O-RU controller may be configured to obtain the O-RU's media access control (MAC) address, determine the O-RU's authentication status based on the O-RU's MAC address, establish a channel binding with the O-RU based on the determination that the O-RU is authenticated, and isolate the O-RU from further communication with the O-RU controller based on the determination that the O-RU is not authenticated.

Description

Technical Field

[0001] Cross-reference to Related Applications This application claims priority to each of the following applications: (a) PCT Patent Application No. PCT / US2023 / 026301, filed on June 27, 2023, entitled "SYSTEM AND METHOD FOR ADVERTISING SUPPLICANTS IN A NETWORK", and (b) PCT Patent Application No. PCT / US2023 / 026303, filed on June 27, 2023, entitled "SYSTEM AND METHOD FOR ESTABLISHING A TOPOLOGY FOR ADVERTISING SUPPLICANTS IN A NETWORK", and incorporates the entire disclosure thereof by reference.

[0002] Systems, devices, methods, and computer programs consistent with exemplary embodiments of the present disclosure relate to a telecommunications network, and more particularly to enabling a network entity to determine (ascertain) the authentication status information of an Open RAN (O-RAN) radio unit (O-RU) within a telecommunications network.

Background Art

[0003] A Radio Access Network (RAN) is a critical component of telecommunications systems, connecting 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 the core network. Traditionally, the hardware and / or software of a particular RAN has been vendor-specific. Open RAN (O-RAN) technology has emerged to allow multiple vendors to provide hardware and / or software to telecommunications systems. Because different vendors are involved, the types of hardware and / or software provided may also differ. That is, different types of NEs may be provided by different vendors, and depending on the specific service, NEs may be virtualized in software form (e.g., virtual machine (VM) based, containerized, or cloud-native) or in physical hardware form (e.g., non-VM based).

[0004] An open fronthaul network of a telecommunications system may be based on an O-RAN architecture. An open fronthaul network may include O-RAN radio units (O-RUs) and O-RU controllers (such as O-RAN distributed units (O-DUs), service management and orchestrators (SMOs)). An O-RU controller can provide services or control to the O-RUs, such as establishing secure communication sessions and providing information for network protocol configuration (NETCONF). Multiple O-RUs may be communicably coupled to a single O-RU controller via one or more transport network elements (TNEs), such as routers and switches. Elements within an open fronthaul network (e.g., O-RUs, TNEs, O-RU controllers, etc.) may be collectively referred to as “network entities” in this specification.

[0005] Figure 1 shows a block diagram of an example of a generalized system architecture 100 for an open fronthaul network in related technologies. As shown in Figure 1, the network entities of the open fronthaul network may include an O-RU 110, a TNE 120, and an O-RU controller 130. The O-RU 110 can be communicatively coupled to the O-RU controller 130 via the TNE 120. Communication between the network entities 110, 120, and 130 may include point-to-point LAN segments / communications.

[0006] Network entities may employ an IEEE 802.1x port-based network access control (PNAC) authentication process (sometimes referred to herein as the "802.1x process") to regulate access to the network and prevent transmission and reception by unidentified or unauthorized parties, and the resulting network disruption, theft of service, or data loss. In this regard, a network entity may play the role of either an authenticator or a supplicant. Data traffic is permitted to pass between network entities only if the network entity has been authenticated through the 802.1x process. During the 802.1x process, a first network entity (e.g., O-RU) may be the supplicant that initiates the 802.1x process, and a second network entity (e.g., TNE) may be the authenticator that controls the first network entity's access to the authentication server running the 802.1x process on the first network entity. An 802.1x process may include one or more Extensible Authentication Protocol (EAP)-based processes, such as the EAP-Transport Layer Security (EAP-TLS) process.

[0007] In related technologies, authentication status information for network entities (e.g., information about whether a network entity is authenticated, information defining the level of trust between one network entity and another) is maintained locally within the network entities involved in the 802.1x process (e.g., O-RU, TNE, etc.) and is not shared with other network entities not involved in the 802.1x process (e.g., O-RU controllers). Instead, trust is enforced only by the next-hop network entity, and other network entities are assumed to be trustworthy if they are chained or connected to the authenticated and / or authorized network entities.

[0008] The above methods for authenticating network entities in related technologies may have at least the following drawbacks: Information about authenticated network entities is kept locally, and it can be assumed that network entities are trusted simply by being connected to authenticated network entities. However, this does not satisfy the zero-trust model, which requires that any network entity attempting to access an open fronthaul network must be fully authenticated before being granted access, without inherently trusting any network entity. In related technologies, there is no mechanism for a single network entity in an open fronthaul network to have a comprehensive view of all authenticated network entities in the network.

[0009] Furthermore, there is no clearly defined technology or network topology for advertising information about authenticated network entities within an open fronthaul network, enabling network entities to view the authentication status information of other network entities. There is also no clearly defined implementation of centralized services in an open fronthaul network, nor any 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) are permitted or included between the O-RU controller and the remote site hosting the O-RUs, the O-RU controller inherently or implicitly trusts all O-RUs by assuming that all O-RUs are trustworthy, enabling communication to all O-RUs during startup and installation without knowledge of the O-RUs' authentication / authorization status. This again fails to satisfy the zero-trust model, and the O-RU controller cannot guarantee that the O-RUs are not spoofed before they begin providing services on them. As a result, network entities in an open-hole network are exposed to potential security risks. [Overview of the project] [Means for solving the problem]

[0011] Embodiments of this disclosure provide apparatus and methods for effectively and efficiently determining (determining) the authentication status information of an O-RU. Specifically, exemplary embodiments of this disclosure define a security mechanism or approach that enables an O-RU controller to determine the authentication status information of an O-RU (e.g., whether the O-RU is authenticated or not), and the O-RU controller can determine whether to establish a channel binding with an O-RU or isolate the O-RU based on that, without implicitly or intrinsically trusting all O-RUs connected to it. Ultimately, the 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 adhering to the principles of a zero-trust model.

[0012] According to one embodiment, an Open Radio Access Network (O-RAN) radio unit (O-RU) controller may be configured to obtain the Media Access Control (MAC) address of the O-RU, determine the 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 the determination that the O-RU is authenticated, and isolate the O-RU from further communication with the O-RU controller based on the determination that the O-RU is not authenticated.

[0013] According to one embodiment, a method implemented by an Open Radio Access Network (O-RAN) radio unit (O-RU) controller includes obtaining the media access control (MAC) address of the O-RU, determining the 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 the determination that the O-RU is authenticated, and isolating the O-RU from further communication with the O-RU controller based on the determination that the O-RU is not authenticated.

[0014] According to one embodiment, a non-temporary computer-readable recording medium may record instructions that can be executed 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 the O-RU's media access control (MAC) address, determining the O-RU's authentication status based on the O-RU's MAC address, establishing a channel binding with the O-RU based on the determination that the O-RU is authenticated, and isolating the O-RU from further communication with the O-RU controller based on the determination that the O-RU is not authenticated.

[0015] Additional embodiments are partially described in the following description, partially revealed therein, or may be implemented by implementing the embodiments presented in this disclosure.

[0016] Features, advantages, and importance of exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, where similar reference numerals indicate similar elements. [Brief explanation of the drawing]

[0017] [Figure 1] This block diagram shows an example of a generalized system architecture for open fronthaul networks in related technologies. [Figure 2] A block diagram of an exemplary system configuration in a peer-to-peer configuration is shown, according to one or more embodiments. [Figure 3A] A block diagram of an exemplary system configuration in a hub-and-spoke setup is shown. [Figure 3B] A block diagram of an exemplary configuration of the hub according to one or more embodiments is shown. [Figure 4] The following shows a block diagram of exemplary components in a network entity (NE) according to one or more embodiments. [Figure 5]A flowchart of an example of a method by which one or more embodiments enable a plurality of network entities to view an authenticated network entity in a peer-to-peer configuration is shown. [Figure 6] An exemplary use case in which a network entity is configured in a peer-to-peer configuration according to one or more embodiments is shown. [Figure 7] An example of an authentication list according to one or more embodiments is shown. [Figure 8] A flowchart of an exemplary method for enabling a plurality of network entities to view information of an authenticated network entity in a hub-and-spoke configuration according to one or more embodiments is shown. [Figure 9] An exemplary use case in which a network entity is configured in a hub-and-spoke configuration according to one or more embodiments is shown. [Figure 10] A flowchart of an exemplary method for managing a trust list according to one or more embodiments is shown. [Figure 11A] An example of a trust list for a network entity according to one or more embodiments is shown. [Figure 11B] An example of an updated authentication list for a network entity according to one or more embodiments is shown. [Figure 11C] An example of an updated trust list for a network entity according to one or more embodiments is shown. [Figure 12] A flowchart of an exemplary method for advertising an authenticated network entity in a peer-to-peer configuration according to one or more embodiments is shown. [Figure 13] A flowchart of an exemplary method for advertising an authentication list in a peer-to-peer configuration according to one or more embodiments is shown. [Figure 14A] A flowchart of an exemplary method for updating an authentication list according to one or more embodiments is shown. [Figure 14B]A flowchart of an exemplary method for updating an authentication list in response to receiving a different authentication list from a network entity in a peer-to-peer configuration according to one or more embodiments is shown. [Figure 15A] An exemplary flow sequence of an exemplary use case for advertising an authenticated network entity in a peer-to-peer configuration according to one or more embodiments is shown. [Figure 15B] An exemplary flow sequence of an exemplary use case for advertising an authenticated network entity in a peer-to-peer configuration according to one or more embodiments is shown. [Figure 15C] An exemplary flow sequence of an exemplary use case for advertising an authenticated network entity in a peer-to-peer configuration according to one or more embodiments is shown. [Figure 16] A flowchart of an exemplary method for advertising an authenticated network entity in a hub-and-spoke configuration according to one or more embodiments is shown. [Figure 17] A flowchart of an exemplary method for advertising an authentication list according to a push-and-pull model in a hub-and-spoke configuration according to one or more embodiments is shown. [Figure 18] A flowchart of an exemplary method for advertising an authentication list according to a subscription notification model in a hub-and-spoke configuration according to one or more embodiments is shown. [Figure 19A] An exemplary flow sequence of an exemplary use case for advertising an authenticated network entity according to a push-and-pull model in a hub-and-spoke configuration according to one or more embodiments is shown. <00性情> [Figure 19B] An exemplary flow sequence of an exemplary use case for advertising an authenticated network entity according to a push-and-pull model in a hub-and-spoke configuration according to one or more embodiments is shown. [Figure 19C]This document illustrates an exemplary flow sequence of an exemplary use case for advertising authenticated network entities according to a push-and-pull model in a hub-and-spoke configuration, based on one or more embodiments. [Figure 20] A block diagram of an exemplary system architecture of an open fronthaul network, according to one or more embodiments, is shown. [Figure 21] A block diagram of another exemplary system architecture of an open fronthaul network, according to one or more embodiments, is shown. [Figure 22] Examples of trusted data stores associated with the network entity in Figure 21, according to one or more embodiments, are shown. [Figure 23] Another example of a trusted data store associated with a network entity in Figure 21 is shown, according to one or more embodiments. [Figure 24] A flowchart shows an exemplary method for determining the authentication status information of an O-RU and managing communication with the O-RU, according to one or more embodiments. [Figure 25] A flowchart illustrating an exemplary method for determining the authentication status of an O-RU, according to one or more embodiments, is shown. [Figure 26] A flowchart shows an exemplary method for managing communication with an O-RU according to one or more embodiments. [Figure 27A] This shows a flowchart illustrating an exemplary method for obtaining the MAC address of an O-RU according to one or more embodiments. [Figure 27B] Flowcharts illustrating other exemplary methods for obtaining the MAC address of an O-RU, according to one or more embodiments, are shown. [Figure 28A] The flow sequence of an exemplary use case of the O-RU bring-up process is shown according to one or more embodiments. [Figure 28B] This document presents an exemplary use case flow sequence for determining O-RU authentication status information and managing communication with the O-RU during the TLS session establishment phase, using one or more embodiments. [Figure 28C] This document presents an exemplary use case flow sequence for determining O-RU authentication status information and managing communication with the O-RU during the NETCONF session establishment phase, using one or more embodiments. [Figure 29] This document shows a diagram illustrating an exemplary environment in which the apparatus, systems, and / or methods described herein may be implemented. [Modes for carrying out the invention]

[0018] A detailed description of exemplary embodiments follows with reference to the accompanying drawings. The same reference numerals in different drawings may identify the same or similar elements.

[0019] The foregoing disclosures provide examples and explanations, but are not intended to be exhaustive or to limit implementations to the exact forms disclosed. Modifications and variations are possible in light of the foregoing disclosures or can be derived from implementations. Furthermore, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). In addition, it should be understood that in the descriptions of operation provided below, one or more operations may be omitted, one or more operations may be added, one or more operations may be performed (at least partially) simultaneously, and the order of one or more operations may be changed.

[0020] It will be apparent that the systems and / or methods described herein may be implemented in different forms of hardware, firmware, or combinations of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not limited to any specific implementation. Therefore, the operation and behavior of the systems and / or methods are described herein without reference to any specific software code. It should be understood that software and hardware may be designed to implement the systems and / or methods based on the descriptions herein.

[0021] While certain combinations of features are disclosed herein, these combinations are not intended to limit the disclosure of possible implementations. In fact, many of these features can be combined in ways not specifically disclosed herein.

[0022] Any elements, actions, or instructions used herein should not be construed as important or essential unless expressly stated otherwise. Furthermore, where used herein, the articles “a” and “an” are intended to include one or more items and may be used interchangeably with “one or more.” When only one item is intended, the term “one” or similar language should be used. Also, where used herein, terms such as “has,” “have,” “having,” “include,” and “including” are intended to be open-ended terms. Furthermore, the phrase “based on” should mean “at least partially based on” unless otherwise specified. Additionally, expressions such as “at least one of [A] and [B],” “[A] and / or [B],” or “at least one of [A] or [B]” should be understood as including only A, only B, or both A and B.

[0023] The systems, methods, devices, etc., provided in the exemplary embodiments of this disclosure enable a network entity to view authenticated network entities (e.g., authenticated supplicants) within the network. Specifically, the exemplary embodiments of this disclosure enable a network entity to view authenticated network entities (e.g., authenticated supplicants) within the network, thereby enabling the development of a data store of information about authenticated network entities, and thus constructing a comprehensive view of all authenticated network entities (e.g., authenticated supplicants) and defining explicit trust levels.

[0024] Furthermore, the systems, methods, devices, etc., provided in the exemplary embodiments of this disclosure advertise authenticated network entities in order to enable network entities to see authenticated network entities (e.g., authenticated supplicants) within a telecommunications network. Specifically, the exemplary embodiments of this disclosure construct a comprehensive topology overview of all trusted authenticated network entities based on data transmitted by each agent deployed within the network entities. Thus, the exemplary embodiments of this disclosure define a network topology for effectively and efficiently advertising information about authenticated network entities.

[0025] Furthermore, the systems, methods, devices, etc., provided in embodiments of this disclosure enable the effective and efficient determination of O-RU authentication status information. Specifically, exemplary embodiments of this disclosure define security mechanisms or approaches to enable an O-RU controller to determine O-RU authentication status information (e.g., information indicating whether an O-RU has been authenticated through an authentication process such as an 802.1x process), and the O-RU controller can determine whether to establish a channel binding with an O-RU or isolate the O-RU based on that, without implicitly or inherently trusting all O-RUs connected to it. In this way, the 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 in accordance with the principles of a zero-trust model.

[0026] The features, advantages, and significance of the exemplary embodiments described above are only a part of this disclosure and are not intended to be exhaustive or to limit the scope of this disclosure.

[0027] Further descriptions of the features, components, configuration, operation, and implementations of the threshold adjustment system of this disclosure, according to one or more embodiments, are provided below.

[0028] Exemplary system architecture Figure 2 shows a block diagram of an exemplary system configuration 200 in a peer-to-peer configuration according to one or more embodiments. As shown in Figure 2, the system configuration 200 may include a plurality of network entities (e.g., network entity 210, network entity 220, and network entity 230) that are coupled together to communicate with each other in a peer-to-peer configuration. One or more of the plurality of network entities may be configured in a peer-to-peer configuration to view and / or advertise information of authenticated network entities (multiple), such as information of authenticated supplicants. Furthermore, one or more of the plurality of network entities may be configured in a peer-to-peer configuration to determine authentication status information (e.g., 802.1x authentication status) of at least one O-RU and manage communication with the O-RU based on that.

[0029] Each of the multiple network entities 210, 220, and 230 may include devices, systems, platforms, modules, etc., which can be configured to perform one or more operations or actions in the network. According to the embodiment, the multiple network entities 210, 220, and 230 may include one or more RAN elements (e.g., O-RU, O-DU, O-RAN Centralized Unit (O-CU)), one or more TNE, SMO, and other entities.

[0030] According to the embodiment, each of the multiple network entities 210, 220, and 230 may deploy an agent. Each agent may include software or entities having a predetermined set of instructions. Each agent may also be autonomous and may operate independently or in cooperation with other agents deployed in other network entities. Each agent may also be set up using information about other agents deployed in network entities directly connected to their respective network entities, either through manual configuration during bootstrapping or through automated techniques. According to the embodiment, each agent may be capable of supporting one or more hypertext transfer protocol (HTTP) operations, such as GET, POST, PUT, and DELETE, in order to communicate and exchange information with each other.

[0031] In one embodiment, each agent may be configured to communicate directly with one another in a peer-to-peer configuration. In this case, each agent may be configured to establish mutual authentication with one another. In particular, an agent may be configured to establish its identity with another agent by presenting valid authentication credentials, 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 multiple network entities and enable the agents to communicate over a secure connection. In one embodiment, mutual authentication between agents may be established after each network entity has authenticated one another.

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

[0033] Figure 3A shows a block diagram of an exemplary system configuration 300 in a hub-and-spoke configuration according to one or more embodiments. As shown in Figure 3A, the system configuration 300 may include a plurality of network entities (e.g., network entity 310, network entity 320, and network entity 330) that are communicatively coupled to one another, and a hub 340 that is communicatively coupled to each of the plurality of network entities 310, 320, and 330 in a hub-and-spoke configuration. One or more of the network entities 310, 320, and 330 in Figure 3A may be the same as one or more of the network entities 210, 220, and 230 in Figure 2. The hub 340 may include a device, system, platform, module, etc., that can be configured to perform one or more operations or actions for managing information of authenticated network entities in the network. For example, as further described below, the hub 340 may be configured to advertise information of one or more authenticated network entities.

[0034] One or more of the multiple network entities may be configured in a hub-and-spoke configuration to view and / or advertise information of authenticated network entities, such as information about authenticated supplicants. Furthermore, one or more of the multiple network entities may be configured in a hub-and-spoke configuration to determine the authentication status information of at least one O-RU and manage communication with the O-RU based on that information.

[0035] Figure 3B shows a block diagram of an exemplary configuration of the hub 340 according to one or more embodiments. As shown in Figure 3B, the hub 340 may include components such as a subscription management function 341, which includes integration functions configured to operate according to a push-and-pull model and a subscription notification model; a data store 342, which is configured to handle a database of authenticated network entities (e.g., authenticated supplicants) in an open fronthaul network; a notification function 343, which is configured to notify subscribers about updates to real-time network traffic; an event tracker 344, which is configured to monitor new subscriptions and any requests made by the hub 340 or agents 350A, 350B, and 350C; a network (application) topology mapper 345, which is configured to provide a comprehensive map of all authenticated network entities (e.g., authenticated supplicants) in the network; and a web interface 346, which is configured to access and browse the comprehensive map of all authenticated network entities (e.g., authenticated supplicants) in the network.

[0036] According to the embodiment, the hub 340 may include a centralized service that functions as a communication hub for multiple network entities 310, 320, and 330. According to the embodiment, the hub 340 may be hosted on any element in an open fronthaul network having communication paths to multiple network entities 310, 320, and 330, such as an O-RU, O-DU, SMO, or IEEE802.1x authentication server. In some implementations, the hub 340 can function as a centralized agent. Alternatively, one or more operations of one or more components within the hub 340 may be deployed in the form of a virtual network service. In this case, the hub 340 can function as a centralized service.

[0037] According to the embodiment, each of agents 350A to 350C may be deployed in one or more of the multiple network entities 310, 320, and 330. Agents 350A to 350C may include software or entities having a predetermined set of instructions. Each of agents 350A to 350C may also be autonomous and may operate independently or in cooperation with other agents deployed in other network entities. Each of agents 350A to 350C may also be set up with information about other agents deployed in network entities directly connected to their respective network entities, either through manual configuration during bootstrapping or through automated techniques. According to the embodiment, each of agents 350A to 350C may be capable of supporting one or more HTTP methods (e.g., GET / POST / PUT / DELETE, etc.) for communicating and exchanging information with each other.

[0038] According to the embodiment, each of agents 350A to 350C may be configured to communicate indirectly with one another via a hub 340 in a hub-and-spoke configuration, where the hub 340 may act as a central point of communication for agents 350A to 350C. According to the embodiment, the hub 340 and agents 350A to 350C may exchange data according to a push-and-pull model and / or a subscription notification model (e.g., requesting and providing services and resources).

[0039] According to the embodiment, each of agents 350A to 350C may be configured to establish mutual authentication with hub 340. Specifically, the agents may be configured to establish a secure connection with the hub using a mutual TLS (mTLS) process, and the above model may be secured within the mTLS environment through encryption. Mutual authentication between the agents and hub 340 may also improve the security of communication between multiple network entities and hub 340, and may allow the agents to communicate indirectly through a secure connection. For example, once a connection is established between agents 350A to 350C and hub 340, data transmitted between agents 350A to 350C and hub 340 may be encrypted using one or more TLS processes, which provides data confidentiality and integrity. Therefore, even if an attacker intercepts the transmitted data, they will not be able to read or tamper with it.

[0040] According to one embodiment, one or more agents 350A to 350C may be configured to perform functions related to one or more trust data stores (e.g., authentication lists, trust lists, etc.), such as creating, updating, retrieving, viewing, and advertising to hub 340.

[0041] According to the embodiment, one or more of the multiple network entities 210, 220, 230, 310, 320, and 330 may be configured to perform the above functions related to one or more trusted data stores (e.g., authentication lists, trust lists, etc.) without agents 350A-350C. In particular, each of the multiple network entities can use EAP over LAN (EAPoL) notifications to inform authenticated network entities (i.e., network entities authenticated through an authentication process such as an 802.1x process) with respect to one or more trusted data stores. In this case, such a process may involve implementing changes to the IEEE 802.1x specification, such as in the IEEE 802.1x EAP notification method. On the other hand, by deploying agents to perform the above functions related to one or more trusted data stores, each of the multiple network entities can utilize information of authenticated network entities without changing the IEEE 802.1x specification.

[0042] The configurations shown in Figures 2, 3A, and 3B are simplified for illustrative purposes and should be understood as not intended to limit the scope of this disclosure. For example, in practice, the number of network entities and / or agents in the system can be any number.

[0043] Several exemplary components that may be included in multiple network entities and hubs according to one or more embodiments are described below with reference to Figure 4. Figure 4 shows a block diagram of exemplary components within a network entity (NE) 400 according to one or more embodiments. NE400 may correspond to at least one of the multiple network entities in Figures 2 and 3A, or to the hub 340 in Figures 3A and 3B. Thus, the features associated with multiple network entities / hubs and NE400 may be similarly applicable to each other unless otherwise specified. Furthermore, the description of one or more components of NE400 is intended to also apply to O-RU controllers (exemplary embodiments related thereto are described below with reference to Figures 20 to 28C).

[0044] As shown in Figure 4, the NE400 may 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, but it can be understood that the NE400 may include more or fewer components than those shown in Figure 4 and / or be arranged in a manner different from that shown in Figure 4, without departing from the scope of this disclosure.

[0045] The communication interface 410 may include at least one transceiver-like component (e.g., a transceiver, separate receivers and transmitters, a bus, etc.) that enables the components of the NE400 to communicate with each other via wired connections, wireless connections, or a combination of wired and wireless connections, and / or with one or more components outside the NE400.

[0046] For example, the communication interface 410 may connect the processor 420 to the storage 440, thereby enabling them to communicate and interact with each other when performing one or more operations. As another example, the communication interface 410 may connect the NE400 (or one or more components contained therein) to separate network entities, thereby enabling them to communicate and interact with each other. According to an embodiment, the communication interface 410 may include one or more application programming interfaces (APIs) that enable the NE400 (or one or more components contained therein) to communicate with one or more software applications.

[0047] The input / output component 430 may include at least one component that enables the NE400 to receive information and / or provide output information. In some embodiments, the input / output component 430 may include at least one input component (e.g., a touchscreen display, a button, a switch, a microphone, a sensor, etc.) and at least one output component (e.g., a display, a speaker, one or more light-emitting diodes (LEDs), etc.), each of which may be separated from one another.

[0048] The storage 440 may include one or more storage media suitable for storing data, information, and / or computer executable instructions. According to embodiments, the storage 440 may 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 device (e.g., flash memory, magnetic memory, and / or optical memory), for storing information and / or instructions for use by the processor 420. Additionally or alternatively, the storage 440 may include, together with a corresponding drive, a hard disk (e.g., magnetic disk, optical disk, magneto-optical disk, and / or solid-state disk), a compact disk (CD), a digital multipurpose disk (DVD), a floppy disk, a cartridge, a magnetic tape, and / or another type of non-temporary computer-readable media.

[0049] According to the embodiment, the storage 440 may be configured to store information such as raw data and metadata. Additionally or alternatively, the storage 440 may 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 may store information defining past operations(s) performed by the processor 420, one or more results of one or more operations performed by the processor 420, one or more authentication lists and / or one or more trust lists, and one or more trust data stores.

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

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

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

[0053] According to one embodiment, the processor 420 is configured to collect, extract, and / or receive one or more pieces of information (in the form of signals or data, etc.), process the received pieces of information so that a network entity can see an authenticated supplicant, advertise the authenticated network entity, and determine the authentication status information of at least one O-RU.

[0054] A description of some exemplary operations that can be performed by the processor 420 is provided below with reference to Figures 5 to 28C.

[0055] Example operation: Viewing information of an authenticated network entity. As described above, according to one or more embodiments, one or more network entities may be configured to view information of authenticated network entities. For example, a network entity can retrieve and view information of one or more authenticated network entities (e.g., authenticated supplicants) in a peer-to-peer configuration. Furthermore, in a hub-and-spoke configuration, a network entity may retrieve such information from a hub and view it accordingly. Illustrative operations related to this will be described later with reference to Figures 5 to 11C.

[0056] Figure 5 shows a flowchart of an exemplary method 500, in one or more embodiments, for enabling multiple network entities to view an authenticated supplicant in a peer-to-peer configuration. One or more operations in method 500 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 multiple network entities in an open fronthaul network. It can also be understood that such one or more operations may 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.

[0057] As shown in Figure 5, in operation S510, at least one network entity may be configured to create a first authentication list. According to one embodiment, the first authentication list can specify one or more network entities to be authenticated with at least one network entity. Specifically, the first authentication list can specify one or more MAC addresses (which may be referred to herein as "one or more first MAC addresses") of one or more ports (e.g., network interface cards (NICs)) of at least one network entity, and one or more MAC addresses of one or more ports of one or more network entities authenticated with one or more first MAC addresses. According to one embodiment, the first authentication list can also specify roles of one or more ports of at least one network entity, such as authenticators and supplicants.

[0058] For example, see Figure 6, which illustrates an exemplary use case in which network entities are configured in a peer-to-peer configuration. As shown in Figure 6, the system may comprise seven network entities: network entity Y, network entity A, network entity M, network entity X, network entity Z, network entity O, and network entity N.

[0059] As shown in Figure 6, for example, network entity A is authenticated with network entities Y and M, and network entity A's port AuP4 has the role of an authenticator, authenticated with MAC address M4 and MAC address M11 and network entity Y's port SuP11, which has the role of a supplicant, and network entity A's port SuP5 has the role of a supplicant, authenticated with MAC address M5 and MAC address M3 and network entity M's port AuP3, which has the role of an authenticator. A similar explanation applies to network entities Y, M, X, Z, O, and N.

[0060] Authentication between network entities can be performed based on an 802.1x process with an IEEE 802.1x authentication server. In particular, as part of the EAPoL process, a network entity acting as an authenticator requests identification information from a network entity acting as a supplicant and relays this information to the authentication server. The authentication server then verifies the identification information of the network entity acting as a supplicant and determines whether that network entity is permitted to access the network. If the network entity acting as a supplicant is permitted to access the network, that network entity acting as a supplicant is authenticated with the network entity acting as an authenticator. Through the above authentication process, the network entities involved in the authentication process can obtain information from each other, such as port identity, port MAC address, port role, and authentication status.

[0061] Figure 7 shows an example of an authentication list according to one or more embodiments. As shown in Figure 7, for example, network entity A may be configured to create its authentication list 730 which may specify MAC addresses M4 and M5 of ports AuP4 and SuP5 of network entity A, as well as MAC address M11 of port SuP11 of network entity Y which is authenticated with port AuP4, and MAC address M3 of port AuP3 of network entity M which is authenticated with port SuP5. Furthermore, the authentication list for network entity A may also specify that port AuP4 of network entity A acts as an authenticator and port SuP5 of network entity A acts as a supplicant. Thus, the authentication list 730 may specify network entities Y and M (having ports SuP11 and AuP3, respectively) which are authenticated with network entity A (having ports AuP4 and SuP5).

[0062] A similar explanation applies to network entities Y, M, X, Z, O, and N. Since network entities Y, X, and Z have only one port, the authentication lists for these network entities are omitted from Figure 7. It should be understood that the parameters shown in the authentication list in Figure 7 are merely examples of possible use cases, and the scope of this disclosure should not be limited thereto. Specifically, in practice, the authentication list may include more / fewer parameters than those illustrated, and / or the parameters may be presented in a different manner than illustrated, without departing from the scope of this disclosure.

[0063] According to the embodiment, at least one network entity may be configured to create and update an associated authentication list at regular intervals (i.e., regular intervals or periods). For example, at least one network entity may be configured to perform a Simple Network Management Protocol version 3 (SNMPv3) query for object identifier (OID) "1.3.111.2.802.1.1.15.2.2.3" at regular intervals. Based on the SNMPv3 response (indicating the status of object type "ieee8021XPaeLogonGroup"), at least one network entity may create and / or update an authentication list. According to the embodiment, at least one network entity may also be configured to send the first authentication list to at least one network entity and one or more network entities that have been authenticated.

[0064] Referring back to Figure 5, once the first authentication list is created in operation S510, method 500 can proceed to operation S520, where at least one network entity (i.e., the first network entity) may be configured to receive the second authentication list from the second network entity. According to the embodiment, the transmission of the first authentication list and the reception of the second authentication list may be performed by at least one network entity via an advertising interface.

[0065] According to the embodiment, at least one network entity (i.e., a first network entity) and a second network entity can authenticate each other. According to the embodiment, similar to the first authentication list, the second authentication list can specify one or more network entities that are authenticated with 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 (sometimes 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 authenticated with one or more second MAC addresses. According to the embodiment, the second authentication list can also specify roles of one or more ports of the second network entity, such as authenticator and supplicant. For example, referring to Figures 6 and 7, in operation S520, network entity A (i.e., component 620 in Figure 6) may receive an authentication list of network entity M (i.e., authentication list 710 in Figure 7) from network entity M (i.e., component 610 in Figure 6) that has been authenticated with network entity A.

[0066] Method 500 then proceeds to operation S530, in which at least one network entity may be configured to create a trust list based on a first authentication list and a second authentication list. According to the embodiment, the trust list can specify the level of trust between at least one network entity (i.e., the first network entity) and one or more network entities in the first and second authentication lists. For example, referring to Figures 6 and 7, the authentication list for network entity A specifies network entities Y and M (which are authenticated with network entity A via port MAC addresses M11 and M3, respectively), and the authentication list for network entity M specifies network entities X and N (which are authenticated with network entity M via port MAC addresses M12 and M6, respectively). Therefore, the trust list for network entity A can specify the level of trust between network entity A and network entities Y, M, X, and N. An example of an operation for creating a trust list is described below with reference to Figure 10.

[0067] When operation S530 is performed, method 500 may terminate or be terminated. Alternatively, method 500 may return to operation S520 so that at least one network entity may repeatedly (e.g., periodically, continuously, etc.) perform the actions of receiving a second authentication list (in operation S520) and creating a trust list (in operation S530) for at least a predetermined amount of time. For example, at least one network entity may continuously or periodically receive multiple authentication lists from multiple network entities and then create or update a trust list based on them.

[0068] In view of the foregoing, according to one or more embodiments, network entities in an open fronthaul network may communicate in a peer-to-peer configuration to obtain information about authenticated network entities. Thus, exemplary embodiments of the present disclosure may enable network entities to browse information about authenticated network entities in the network (e.g., authenticated supplicants) by communicating with each other in a peer-to-peer configuration. More specifically, each network entity in the network may obtain overall knowledge of other authenticated network entities by referring to one or more trust data stores (e.g., authentication lists, trust lists) that are created locally and updated in a timely manner.

[0069] Additionally or alternatively, a network entity may be configured to obtain information about authenticated network entities by communicating with a hub (or centralized agent / centralized service). An exemplary description of a hub is provided above with reference to hub 340 in Figures 3A and 3B, and a further description of some exemplary operations associated with it when viewing information about authenticated network entities is provided below with reference to Figures 8–11C.

[0070] Figure 8 shows a flowchart of an exemplary method 800, in one or more embodiments, for enabling multiple network entities to view information of an authenticated network entity (e.g., an authenticated supplicant) in a hub-and-spoke configuration. One or more operations in method 800 may be performed by at least one processor (e.g., processor 420) of a hub communicably coupled to multiple network entities in a system. It can be understood that such one or more operations may also be performed by a system including a hub, a system including at least one processor, etc., without departing from the scope of this disclosure.

[0071] As shown in Figure 8, in operation S810, the hub may be configured to receive a first authentication list from a first network entity. The first authentication list may be similar to the first authentication list described above with respect to method 500 in Figure 5.

[0072] Figure 9 shows an exemplary use case in which network entities are configured in a hub-and-spoke configuration according to one or more embodiments. The example of network entities in the hub-and-spoke configuration shown in Figure 9 is similar to the example of network entities in the peer-to-peer configuration shown in Figure 6, except that each network entity has an additional hub 990 that is communicably coupled to it.

[0073] In this regard, referring to Figures 7 and 9, in operation S810, the hub 990 may be configured to receive, for example, an authentication list for network element A (i.e., the authentication list 730 shown in Figure 7) from network element A (i.e., component 920 in Figure 9).

[0074] After performing operation S810, method 800 may then proceed to operation S820, where the hub may be configured to receive a second authentication list from a second network entity. The second authentication list may be the same as the second authentication list described above with respect to method 500. For example, referring to Figures 7 and 9, in operation S820, the hub 990 may receive an authentication list of network entity M (i.e., the authentication list 710 shown in Figure 7) from network entity M (i.e., component 910 in Figure 9) that has been authenticated with network entity A.

[0075] According to the embodiment, receiving the first and second authentication lists may be performed by the hub via an advertising interface. Upon receiving the first and second authentication lists, method 800 can proceed to operation S830, in which the hub may be configured to create a trust list of first network entities based on the first and second authentication lists. The trust list may be similar to the trust list described above with respect to method 500. A further description of an example of a trust list is provided below with reference to Figures 11A and 11C.

[0076] When operation S830 is executed, method 800 may terminate or be terminated. Alternatively, method 800 may return to operation S820, and as a result, the hub may be configured to repeatedly (e.g., periodically, continuously, etc.) perform the actions of receiving a second authentication list (in operation S820) and creating a trust list (in operation S830) for at least a predetermined period of time. For example, the hub may receive multiple authentication lists continuously (or periodically) from multiple network entities and then create or update a trust list based on them.

[0077] In view of the foregoing, 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 network entities communicably coupled to it with information from one or more trust data stores associated with authenticated network entities (e.g., authentication lists, trust lists, etc.). For example, one or more trust data stores (e.g., authentication lists, trust lists, etc.) may be created locally in each network entity and sent to the hub, and / or created in the hub, and the hub may then be configured to send or advertise one or more trust data stores to the network entities associated with it. Furthermore, the hub may be configured to update at least a portion of the trust data stores (e.g., trust lists, etc.) at regular intervals or periodically. Thus, exemplary embodiments of the present disclosure may enable network entities to view information about authenticated network entities in the network (e.g., authenticated supplicants, etc.) by communicating with a hub in a hub-and-spoke configuration. More specifically, each network entity within the network can gain a comprehensive understanding of other authenticated network entities by referencing one or more trust data stores (e.g., authentication lists, trust lists, etc.) that are created and updated in a timely manner.

[0078] The following describes examples of actions for managing trust lists (e.g., creating, updating, etc.). Figure 10 shows a flowchart of an exemplary method 1000 for managing a trust list according to one or more embodiments. A trust list may include information collected and integrated from multiple authenticated network entities within an open fronthaul network.

[0079] For example, in some implementations, trust lists may be presented in the form of entity-level trust tables and / or network-level (e.g., direct or indirect) trust tables. Entity-level trust tables may be generated based on authentication lists associated with network entities. Network-level trust tables, on the other hand, may be generated based on information aggregated from multiple authentication lists, each of which is associated with one of several authenticated network entities (e.g., authenticated supplicants) within the network. An example of an entity-level trust list (i.e., a trust list presented in the form of an entity-level trust table) is described below with reference to Figure 11A, and an example of a network-level trust list (i.e., a trust list presented in the form of a network-level trust table) is described below with reference to Figure 11C.

[0080] In some implementations, it is considered that the authentication list may also be presented in the form of an entity-level authentication table and / or a network-level authentication table. For example, the authentication list 730 described above is an example of an entity-level authentication list associated with network entity A (i.e., an authentication list presented in the form of an entity-level authentication table), and an example of a network-level authentication list associated with network entity A (i.e., an authentication list presented in the form of a network-level authentication table) is described later with reference to Figure 11B.

[0081] Referring again to Figure 10, one or more operations in Method 1000 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, or by at least one processor (e.g., processor 420) of a hub communicably coupled to a plurality of network entities in the system. It can also be understood that such one or more operations may be performed by a system including at least one network entity, by a system including a hub, by a system including at least one processor, etc., without departing from the scope of this disclosure. Furthermore, it is conceivable that one or more operations of Method 1000 may be performed in a peer-to-peer and / or hub-and-spoke configuration, and may be part of operation S530 of Method 500, or part of operation S830 of Method 800.

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

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

[0084] According to the embodiments, a trust list created based on a first authentication list may include one or more MAC addresses of one or more ports of at least one network entity (i.e., a first network entity) and one or more MAC addresses of one or more ports of one or more network entities in the first authentication list that act as supplicants. For example, Figure 11A shows an example of a trust list for network entity A according to one or more embodiments, where the trust list is created based on an authentication list for network entity A (e.g., authentication list 730 in Figure 7) (e.g., created by at least one network entity, created by a hub, etc.).

[0085] As shown in Figure 11A, the trust list of network entity A specifies MAC addresses M5 and M4 (i.e., the MAC addresses of network entity A's ports SuP5 and AuP4, respectively). Furthermore, since the port of network entity Y, which has the role of supplicant (i.e., SuP11) (and is in network entity A's authentication list), is authenticated with network entity A's port AuP4, the trust list of network entity A specifies MAC address M11 of that port SuP11 of network entity Y, and specifies that the trust level between port SuP11 and network entity A's port AuP4 is direct trust. On the other hand, since the port of network entity M, which has the role of supplicant (i.e., SuP2) (and is in network entity A's authentication list), is authenticated with network entity A's port SuP5 via network entity M's port AuP3, the trust list of network entity A specifies MAC address M2 of that port SuP2, and specifies that the trust level between network entity M's port SuP2 and network entity A's port SuP5 is indirect trust. In this regard, the trust list in Figure 11A is created based on the authentication list of network entity A, and therefore, this trust list may be referred to herein as the "entity-level trust list," and the tables included in the trust list may be referred to herein as the "entity-level trust tables."

[0086] When an authentication list and / or trust list is created, that authentication list / trust list can be shared or advertised to one or more network entities within the network. For example, the created authentication list and / or trust list can be shared by at least one network entity to another network entity in a peer-to-peer configuration, or by a hub to one or more network entities in a hub-and-spoke configuration.

[0087] According to one embodiment, once a trust list is created, at least one network entity / hub may be configured to periodically (or continuously) update the trust list. For example, after performing operation S1010, method 1000 may proceed to operation S1020, where at least one network entity / hub may be configured to update the first authentication list to include the second authentication list in response to receiving the second authentication list.

[0088] For example, Figure 11B shows an example of an updated authentication list for network entity A according to one or more embodiments. As shown in Figure 11B, the authentication list for network entity A is updated (from authentication list 730 in Figure 7) to include information from the authentication list for network entity M (i.e., authentication list 710 in Figure 7). In this regard, the authentication list in Figure 11B is an authentication list that includes information integrated from multiple authentication lists, each of which is associated with one of several network entities in the network, and therefore the authentication list may be referred to herein as a “network-level authentication list,” and the tables included in the authentication list may be referred to herein as “network-level authentication tables.”

[0089] Upon updating the authentication list, method 1000 may proceed further to operation S1030, where at least one network entity / hub may be configured to update the trust list of network entities associated with the updated authentication list based on the updated authentication list. For example, at least one network entity / hub may update its trust list based on the updated first authentication list to further specify the level of trust between at least one network entity (i.e., the first network entity) and one or more network entities in the second authentication list. According to embodiments, the level of trust may 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 in the second authentication list that have the role of supplicant (now included in the updated first authentication list). According to one embodiment, the updated trust list may include one or more MAC addresses of one or more ports of at least one network entity (i.e., a first network entity) and one or more MAC addresses of one or more ports of one or more network entities in a second authentication list that act as supplicants.

[0090] For example, referring to Figure 11C, an example of an updated trust list for network entity A according to one or more embodiments is shown. Specifically, a port of network entity X having the role of a supplicant (i.e., SuP12) (which is in the authentication list of network entity M, which is now included in the updated authentication list of network entity A) authenticates with port SuP5 of network entity A via ports AuP1 and AuP3 of network entity M. Therefore, the updated trust list of network entity A further specifies the MAC address M12 of the port SuP12 and specifies that the trust level between port SuP12 of network entity X and port SuP5 of network entity A is indirect trust. Similarly, a port of network entity N acting as a supplicant (i.e., SuP7) (which is in the authentication list of network entity M, currently included in the updated authentication list of network entity A) authenticates with port SuP5 of network entity A via port AuP6 of network entity N and ports SuP2 and AuP3 of network entity M. Therefore, the updated trust list of network entity A further specifies the MAC address M7 of port SuP7 and specifies that the trust level between port SuP7 of network entity N and port SuP5 of network entity A is indirect trust. In this regard, the trust list in Figure 11C is created based on the updated authentication list of network entity A (i.e., an authentication list containing information integrated from multiple authentication lists, each of which is associated with one of several network entities in the network). Therefore, the trust list may be referred to herein as a “network-level trust list,” and the tables included in the trust list may be referred to herein as “network-level trust tables.”

[0091] In some implementations, it should be understood that one or more ports of network entity A that are in the authentication list of network entity M (which is currently included in the updated authentication list of network entity A) may be included in / excluded from one or more of the processes described above.

[0092] When an authentication list and / or trust list is updated, the updated authentication list and / or trust list can be shared or advertised to one or more network entities in the network. For example, the updated authentication list and / or trust list can be shared by at least one network entity with another network entity in a peer-to-peer configuration, or by a hub with one or more network entities in a hub-and-spoke configuration. For example, in a peer-to-peer configuration, the updated first authentication list may be sent to one or more network entities authenticated using at least one network entity (i.e., the first network entity), and therefore the received second authentication list can also further specify one or more network entities authenticated using a third network entity authenticated using the second network entity.

[0093] According to the embodiment, the method 1000 can be terminated by executing operation S1030. Alternatively, the method 1000 can return to operation S1020, so that at least one network entity / hub can return to operation S1020, which repeatedly (e.g., periodically, continuously, etc.) updates the first authentication list (in operation S1020) and the trust list (in operation S1030) for at least a predetermined amount of time, until each of the multiple network entities has a comprehensive view of all authenticated network entities in the network.

[0094] For example, in a peer-to-peer configuration, as described above, the authentication list of network entity A is updated to include the authentication list of network entity M, and after the trust list of network entity A is updated based on the updated authentication list, network entity M may receive the authentication list of network entity N from network entity N (specifying network entity O to be authenticated with network entity N). Then, the authentication list for network entity M may be updated to include the authentication list for network entity N (therefore, the authentication list for network entity M now specifies network entity O), and the trust list for network entity M is updated based on the updated authentication list in the same manner as described above. Subsequently, network entity M can send its updated authentication list back to network entity A, and the process is repeated, updating the authentication list and trust list of network entity A, this time also specifying network entity O. The above process may be repeated until each of the multiple network entities has an up-to-date, comprehensive view of all authenticated network entities in the network.

[0095] Similarly, exemplary embodiments enable O-RU controllers (e.g., O-DU, SMO, etc.) and O-RUs to establish a level of trust with each other. For example, an O-RU controller and an O-RU can establish indirect trust with each other, and then channel binding can be established even if the O-RU controller and the O-RU are not directly authenticated with each other. An example of this operation will be described below with reference to Figures 20 to 28C.

[0096] Referring to Figures 5 to 11C, the descriptions provided above are merely illustrative of possible embodiments and should not be seen as limiting the scope of this disclosure. Specifically, the authentication lists and / or trust lists shown in Figures 7 and 11A to 11C may contain more or less information than shown, and / or the information may be presented in any other suitable format other than tabular form, without departing from the scope of this disclosure. Similarly, the number of network entities in a system may be any number, the number of ports in each of the network entities may be any number, and each of the network entities may be authenticated with any other network entity, and so on.

[0097] Exemplary behavior: Advertising information of an authenticated network entity As described above, according to one or more embodiments, one or more network entities may be configured to share or advertise information of authenticated network entities. For example, a network entity may advertise information of one or more authenticated network entities (e.g., authenticated supplicants) together with another(or more) network entities in a peer-to-peer configuration. Furthermore, in a hub-and-spoke configuration, a network entity may advertise such information to a hub, which may be configured to advertise such information to another(or more) network entities accordingly. Illustrative operations related to this will be discussed later with reference to Figures 12 to 19C.

[0098] Figure 12 shows a flowchart of an exemplary method 1200 for advertising a peer-to-peer authenticated network entity according to one or more embodiments. One or more operations in method 1200 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 a system. It can also be understood that such one or more operations may 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.

[0099] As shown in Figure 12, in operation S1210, at least one network entity may be configured to create a first authentication list. This operation may be similar to operation S510 of method 500, and therefore, any redundant explanation related thereto may be omitted below for brevity.

[0100] If a first authentication list is created in operation S1210, method 1200 can proceed to operation S1220, where at least one network entity (i.e., the first network entity) may be configured to advertise the first authentication list to a second network entity. For example, at least one network entity may advertise the first authentication list to a second agent (e.g., agent 350B) deployed in the second network entity. According to the embodiment, at least one network entity and the second network entity may authenticate each other. For example, referring to Figures 6 and 7, in operation S1220, network entity A (i.e., component 620 in Figure 6) may be configured to advertise authentication list 730 (i.e., the authentication list for network entity A) to an agent deployed in network entity M (i.e., component 610 in Figure 6) that has been authenticated with network entity A.

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

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

[0103] Figure 13 shows a flowchart of an exemplary method 1300 for advertising an authentication list in a peer-to-peer configuration, according to one or more embodiments. 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 may also be understood that such one or more operations may 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.

[0104] As shown in Figure 13, in operation S1310, at least one network entity may be configured to create a first authentication list in the same manner as described above with respect to operation S510 of method 500.

[0105] Upon performing operation S1310, method 1300 then proceeds to operation S1320, in which at least one network entity may be configured to send a first authentication list to a second network entity. According to the embodiment, at least one network entity may send a 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 may authenticate each other.

[0106] For example, referring to Figures 6 and 7, in operation S1320, network entity A (i.e., component 620 in Figure 6) may be configured to send the relevant authentication list (i.e., authentication list 730 in Figure 7) to the agent deployed in network entity M (i.e., component 610 in Figure 6) that has been authenticated with network entity A.

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

[0108] According to one embodiment, creating a first authentication list may be performed by a first agent deployed in at least one network entity, and sending the first authentication list may be performed by the first agent via an advertising interface. According to one embodiment, the advertising interface may include an interface such as a REST API. According to one embodiment, the first agent can mutually authenticate with a second agent.

[0109] When operation S1320 is performed, method 1300 may terminate or be terminated. Alternatively, at least one network entity may be configured to repeatedly (e.g., periodically, continuously, etc.) transmit the first authentication list for at least a predetermined amount of time. For example, at least one network entity may update the first authentication list in response to a change in the network and then resume transmitting the first authentication list.

[0110] An example of how to update an authentication list in a peer-to-peer configuration and advertise the updated authentication list is described below with reference to Figures 14A and 14B.

[0111] Figure 14A shows a flowchart of an exemplary method 1400 for updating an authentication list according to one or more embodiments. One or more operations in method 1400 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 in response to newly authenticated network entities in a peer-to-peer configuration after the first authentication list has been created. It can also be understood that such one or more operations may 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.

[0112] As shown in Figure 14A, in operation S1410, at least one network entity may be configured to authenticate with one or more new network entities. According to one embodiment, the one or more newly authenticated network entities may include one or more network entities that have authenticated with at least one network entity after the first authentication list has been created and are not shown in the first authentication list.

[0113] For example, referring to Figures 6 and 7, after network entity A (i.e., component 620 in Figure 6) has created an associated authentication list (i.e., authentication list 730 in Figure 7) specifying port SuP11 (having the MAC address of M11) of network entity Y, network entity A may, in operation S1410, newly authenticate with network entity M (which is not yet shown or specified in authentication list 730).

[0114] In this case, method 1400 can proceed to operation S1420, in which at least one network entity can be configured to update the first authentication list to further specify one or more newly authenticated network entities. For example, referring to Figures 6 and 7, after network entity A has been newly authenticated with network entity M, network entity A may be configured to update the relevant authentication list (i.e., authentication list 730 in Figure 7) to further specify network entity M. As an example, network entity A may update the relevant authentication list by adding a new line to the authentication list 730 to specify port AuP3 of network entity M (with MAC address M3) along with the corresponding port SuP5 of network entity A (with MAC address M5).

[0115] Therefore, method 1400 can proceed to operation S1430, where at least one network entity may be configured to send an updated first authentication list to one or more agents deployed in one or more authenticated network entities (i.e., one or more network entities authenticated with at least one network entity). For example, when network entity A updates its authentication list, it may be configured to send its updated authentication list to agents deployed in network entity Y (i.e., a network entity previously authenticated with network entity A) and to agents deployed in network entity M (i.e., a network entity newly authenticated with network entity A).

[0116] When operation S1430 is performed, method 1400 may terminate or be terminated. Alternatively, method 1400 may return to operation S1410 so that at least one network entity repeatedly (e.g., periodically, continuously, etc.) authenticates one or more network entities (in operation S1410), updates the first authentication list (in operation S1420), and sends the updated first authentication list (in operation S1430) for at least a predetermined amount of time. For example, at least one network entity may continue to find more network entities to authenticate and then resume S1430 from operation S1410.

[0117] Figure 14B shows a flowchart of an exemplary method 1405 for updating an authentication list in response to receiving another authentication list from a network entity in a peer-to-peer configuration, according to one or more embodiments. One or more operations in method 1405 may be performed after the first authentication list has been created 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 may also be understood that such one or more operations may 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.

[0118] As shown in Figure 14B, in operation S1415, at least one network entity may 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 authenticated using at least one network entity). It can be understood that the one or more authentication lists may be created by each of the one or more agents in the same manner as described above. For example, in operation S1415, at least one network entity may be configured to receive a second authentication list from a second agent deployed in a second network entity, and the second network entity is authenticated with at least one network entity (i.e., the first network entity). According to the embodiment, the second authentication list may specify one or more network entities authenticated with the second network entity in the same manner as the first authentication list. For example, referring to Figures 6 and 7, network entity A (i.e., component 620 in Figure 6) may be configured to receive an authentication list for network entity M (i.e., authentication list 710 in Figure 7) from an agent deployed in network entity M (i.e., component 610 in Figure 6).

[0119] After performing operation S1415, method 1405 can then proceed to operation S1425, where at least one network entity may be configured to update the first authentication list to include one or more authentication lists. For example, referring to Figures 6 and 7, in operation S1415, network entity A (i.e., component 620 in Figure 6) may be configured to update its authentication list (i.e., authentication list 730 in Figure 7) to include rows specifying ports AuP1, AuP3, and SuP2 in the authentication list of network entity M (e.g., authentication list 710 in Figure 7).

[0120] When operation S1425 is performed, method 1405 may then proceed to operation S1435, where at least one network entity may be configured to send an updated first authentication list to one or more agents deployed in one or more authenticated network entities (i.e., at least one network entity and one or more network entities authenticated). For example, network entity A may be configured to send its updated authentication list (further including information on ports AuP1, AuP3, and SuP2 of network entity M) to agents deployed in network entity Y and agents deployed in network entity M, and network entity Y and network entity M are authenticated with network entity A.

[0121] When operation S1435 is executed, method 1405 may terminate or be terminated. Alternatively, method 1405 may return to operation S1415 so that at least one network entity repeatedly (e.g., periodically, continuously, etc.) for at least a predetermined amount of time the following actions are performed: receiving one or more authentication lists (in operation S1415), updating a first authentication list (in operation S1425), and sending the updated first authentication list (in operation S1435). For example, at least one network entity may continue to receive more authentication lists and then resume operations S1415-S1435.

[0122] According to the embodiment, at least one network entity may be configured to send notifications to one or more agents to indicate changes in the network. For example, at least one network entity may be configured to send notifications such as that at least one network entity has been newly authenticated with the network entity, or that the first authentication list has been updated. According to the embodiment, at least one network entity may be configured to send an updated first authentication list to one or more agents in response to receiving a request from one or more agents to send the updated first authentication list. Similarly, at least one network entity may be configured to receive notifications from one or more agents and send a request from one or more agents to receive an updated authentication list.

[0123] According to the embodiment, receiving one or more authentication lists, updating a first authentication list, and transmitting an updated first authentication list may be performed by a first agent deployed in at least one network entity. According to the embodiment, transmitting an updated first authentication list and transmitting and receiving notifications and requests may be performed via an advertising interface. According to the embodiment, the advertising interface may include an interface such as a REST API. According to the embodiment, the first agent may be mutually authenticated with one or more agents deployed in one or more network entities authenticated with the first network entity.

[0124] In view of the foregoing, exemplary embodiments enable an agent of a network entity to be easily informed of any changes to the network and to ensure that the agent always has up-to-date information on the authenticated network entity (for example, always receiving the latest version of the authentication list).

[0125] The following provides a description of exemplary use cases for advertising peer-to-peer authenticated network entities using one or more embodiments.

[0126] Figures 15A to 15C illustrate exemplary flow sequences of exemplary use cases for advertising peer-to-peer authenticated network entities in one or more embodiments. The exemplary flow sequences illustrated in Figures 15A to 15C involve the processes described above in relation to methods 1200, 1300, 1400, and 1405, and are divided into three parts for clarity.

[0127] As shown in Figures 15A to 15C, the network includes four network entities deploying four agents (i.e., Agent 1, Agent 2, Agent 3, and Agent 4) and an authentication server.

[0128] Between steps 1 and 3, network entity 1 (where agent 1 is deployed) can perform authentication with network entity 2 (where agent 2 is deployed). According to the embodiment, network entity 1 can perform authentication with network entity 2 via an 802.1x process (i.e., an authentication process using the IEEE 802.1x RFC5216 EAP-TLS authentication protocol). If authentication is successful, the sequence proceeds to step 4. On the other hand, if authentication is unsuccessful, network entity 2 can issue a security alert and block data traffic to and from network entity 1.

[0129] Between steps 4 and 5, network entity 2 can create / update the authentication list and advertise the authentication list to network entity 1 via a secure connection.

[0130] During step 6, network entity 2 can establish a direct trust with network entity 1. For example, when network entity 1 receives an authentication list from network entity 2, network entity 1 may be configured to create / update a trust list specifying that the trust level between network entity 2 and network entity 1 is direct trust.

[0131] Between steps 7 and 12, network entity 3 (where agent 3 is deployed) may perform authentication with network entity 2, create / update authentication lists, advertise authentication lists to network entity 2, and establish direct trust with network entity 2, in the same manner as described above for steps 1 through 6.

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

[0133] Between steps 14 and 16, network entity 3 can perform authentication with network entity 4 (where agent 4 is deployed) in the same manner as described above in relation to steps 1 to 3.

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

[0135] Between steps 18 and 19, network entity 3 may advertise its updated list of authentications to network entities 2 and 4.

[0136] During step 20, network entity 4 may form an indirect trust with network entity 1. For example, network entity 1 is specified in network entity 2's authentication list, which is advertised to network entity 3 (in step 13), and network entity 3 updates its authentication list to include network entity 2's authentication list and advertises it to network entity 4 (in step 19), so network entity 4 may update its authentication list to include network entity 3's authentication list (specifying network entity 1). Thus, network entity 4 may be configured to create / update a trust list specifying that the level of trust between network entity 4 and network entity 1 is indirect trust, based on network entity 4's updated authentication list.

[0137] During step 21, network entity 4 can form a direct trust with network entity 3 in the same manner as described above in relation to step 6.

[0138] For this purpose, exemplary embodiments of the present disclosure enable network entities to advertise information about authenticated network entities in a peer-to-peer configuration. In this way, each network entity in an open fronthaul network can obtain comprehensive information about other authenticated network entities in the network and receive real-time updates.

[0139] In addition to, or as an alternative to, a peer-to-peer configuration, network entities may also advertise information about authenticated network entities in a hub-and-spoke configuration. Below, several exemplary operations for advertising information about one or more authenticated network entities in a hub-and-spoke configuration, according to one or more embodiments, are described with reference to Figures 16–19C.

[0140] Figure 16 shows a flowchart of an exemplary method 1600 for advertising authenticated network entities in a hub-and-spoke configuration, according to one or more embodiments. One or more operations in method 1600 may be performed by at least one processor (e.g., processor 420) of a hub communicably coupled to multiple network entities in a system. It can be understood that such one or more operations may also be performed by a system including a hub, a system including at least one processor, etc., without departing from the scope of this disclosure.

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

[0142] Upon receiving the first authentication list, method 1600 can then proceed to operation S1620, in which case the hub can be configured to advertise the first authentication list to the second network entity. According to the embodiment, the hub may be configured to advertise the first authentication list to the second agent deployed in the second network entity according to a subscription model such as a push-and-pull model and a subscription notification model. An example of operation for advertising the authentication list according to a push-and-pull model in a hub-and-spoke configuration is described below with reference to Figure 17, and an example of operation for advertising the authentication list according to a subscription notification model in a hub-and-spoke configuration is described below with reference to Figure 18. According to the embodiment, the first network entity and the second network entity may authenticate each other.

[0143] For example, referring to Figures 7 and 9, upon receiving an authentication list 730 from network entity A (i.e., component 920 in Figure 9), hub 990 may be configured to advertise the authentication list 730 to network entity M (i.e., component 910 in Figure 9) that has been authenticated with network entity A. In some implementations, hub 990 may be configured to advertise the authentication list 730 to agents deployed within network entity M.

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

[0145] When operation S1620 is performed, method 1600 may terminate or be terminated. Alternatively, the hub may be configured to repeatedly (e.g., periodically, continuously, etc.) advertise the first authentication list (in operation S1620) for at least a predetermined period of time. For example, the hub may update the first authentication list in response to network changes and then resume advertising the first authentication list.

[0146] Figure 17 shows a flowchart of an exemplary method 1700 for advertising an authentication list according to a push-and-pull model in a hub-and-spoke configuration, according to one or more embodiments. One or more operations of method 1700 may be part of operations S1610 and S1620 in method 1600 and may be performed by at least one processor (e.g., processor 420) of a hub communicably coupled to multiple network entities in a system. It may also be understood that such one or more operations may be performed by a system including a hub, a system including at least one processor, etc., without departing from the scope of this disclosure.

[0147] As shown in Figure 17, in operation S1710, the hub may 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 one embodiment, the hub may be configured to register the first agent and the second agent under a push-and-pull model.

[0148] For example, the first and second agents may be configured to register with an API function for a push-and-pull model during bootstrapping, and their accounts and API keys will be verified by the API function and used for all API requests. The first and second agents can then initiate a REST API POST request to subscribe to the push-and-pull model, providing information such as the API key, the channel name for the subscription, and any additional parameters required for the function.

[0149] After performing operation S1710, method 1700 can then proceed to operation S1720, where the hub may be configured to receive a first authentication list from a first agent in a manner similar to that described above with respect to operation S1610. For example, referring to Figure 9, the hub 990 may be configured to receive an authentication list for network entity A (e.g., component 920 in Figure 9) from an agent deployed in network entity A.

[0150] Method 1700 may then proceed to operation S1730, where the hub may be configured to receive a second authentication list from the second agent. For example, referring to Figure 9, the hub 990 may be configured to receive an authentication list for network entity M (e.g., component 910 in Figure 9) from an agent deployed in network entity M. According to the embodiment, the first network entity and the second network entity (in which the first agent and the second agent are deployed, respectively) can authenticate each other. It can be understood that the second authentication list may be created by the second agent in a manner similar to that described above for the first agent in a peer-to-peer configuration.

[0151] Next, method 1700 can proceed to operation S1740, where the hub may be configured to update the second authentication list to include the first authentication list. For example, referring to Figure 9, hub 990 may be configured to update the authentication list of network entity M to include the authentication list of network entity A in a manner similar to that described above with respect to operation S1425 in method 1405.

[0152] Method 1700 can then proceed to operation S1750, where the hub can be configured to send a notification to a second agent. According to one embodiment, the notification may inform the second agent of changes in the network. For example, the notification may specify that a first network entity has been newly deployed to the network, that a first authentication list has been received, or that a second authentication list has been updated.

[0153] According to the embodiment, the hub's event tracker (e.g., component 344 in Figure 3B) may be configured to monitor data stored in the hub (e.g., data stored in the hub's datastore), track data received from and sent to agents, and detect changes in the stored data (e.g., detecting that a first authentication list has been received from a first agent, that an updated first authentication list has been received from the first agent, that a second authentication list has been updated, etc.). The event tracker may then notify the hub's datastore of the changes and send notifications to agents using the hub's notification mechanism / function (e.g., component 343 in Figure 3B).

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

[0155] Upon receiving the request in operation S1760, method 1700 can then proceed to operation S1770, where the hub may be configured to send an updated second authentication list to the second agent in response to the receipt of the request. For example, referring to Figure 9, the hub 990 may be configured to send an updated authentication list to agents deployed within network entity M in the same manner as described above in operation S1435 of method 1405.

[0156] According to one embodiment, the hub may be configured to store received and updated authentication lists so that it can function as a central agent or information repository for all authenticated network entities (e.g., authenticated supplicants) in an open fronthaul network. In particular, the hub's network topology mapper (e.g., component 345 in Figure 3B) can use the stored authentication lists to form an integrated data store of authenticated network entities (e.g., authenticated network supplicants) and create a topology map of all authenticated network entities in an open fronthaul network. Thus, the hub may be configured to develop a live network mapping application that can build a comprehensive topology overview of all authenticated network entities based on the stored authentication lists.

[0157] According to one embodiment, the transmission of the updated second authentication list may be performed via an advertising interface. According to one embodiment, the advertising interface may include an interface such as a REST API. According to one embodiment, the first agent and the second agent can mutually authenticate with the hub.

[0158] When operation S1770 is performed, method 1700 may terminate or be terminated. Alternatively, method 1700 may return to operation S1720, and as a result the hub may be configured to repeatedly (e.g., periodically, continuously, etc.) perform receiving a first authentication list (operation S1720), receiving a second authentication list (operation S1730), updating the second authentication list (operation S1740), sending a notification (operation S1750), receiving a request (operation S1760), and sending the updated second authentication list (operation S1770) for at least a predetermined time.

[0159] For example, a first network entity may be newly authenticated with another network entity (network change), where the first authentication list is updated in the same manner as described above with respect to method 1400 and sent to the hub. Thus, the hub may receive the updated first authentication list (S1720), resume receiving the second authentication list (S1730), updating the second authentication list (S1740), sending notifications (S1750), receiving requests (S1760), and sending the updated second authentication list (S1770).

[0160] Figure 18 shows a flowchart of an exemplary method 1800 for advertising an authentication list in accordance with a subscription notification model in a hub-and-spoke configuration, according to one or more embodiments. One or more operations of method 1800 may be part of operations S1610 and S1620 in method 1600 and may be performed by at least one processor (e.g., processor 420) of a hub communicably coupled to multiple network entities in a system. It may also be understood that such one or more operations may be performed by a system including a hub, a system including at least one processor, etc., without departing from the scope of this disclosure.

[0161] As shown in Figure 18, in operation S1810, the hub may 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 one embodiment, the hub may be configured to register the first and second agents under a subscription notification model. Specifically, the first and second agents may be configured to subscribe to the hub's central endpoint URL using a REST API, and the hub's subscription management API manages the subscription, publishing, and notification processes. The hub may then respond to the first and second agents with a success status code indicating that the subscription was successful, and may keep the connection between the hub and the first and second agents open.

[0162] Method 1800 may then proceed to operation S1820, where the hub may be configured to receive a first authentication list from the first agent in the same manner as described above with respect to operation S1610. According to one embodiment, the first agent may be configured to periodically send the first authentication list. Method 1800 may then proceed to operation S1830, where the hub may be configured to receive a second authentication list from a second agent. According to one embodiment, the second agent may be configured to periodically send the second authentication list. According to one embodiment, the first network entity and the second network entity may authenticate each other.

[0163] After performing operation S1830, method 1800 can then proceed to operation S1840, where the hub can be configured to update the second authentication list to include the first authentication list in the same manner as described above in operation S1425 of method 1405.

[0164] Therefore, method 1800 can then proceed to operation S1850, where the hub may be configured to send the updated second authentication list to the second agent. According to the embodiment, the hub may be configured to send the updated second authentication list periodically. Referring to Figure 9, for example, in operation S1850, the hub 990 may be configured to send the updated authentication list of network entity M (including the authentication list of network entity A) to agents deployed in network entity M in the same manner as described above in operation S1435 of method 1405.

[0165] When operation S1850 is performed, method 1800 may terminate or be terminated. Alternatively, method 1800 may return to operation S1820, and as a result the hub may be configured to repeatedly (e.g., periodically, continuously, etc.) perform receiving the first authentication list (operation S1820), receiving the second authentication list (operation S1830), updating the second authentication list (operation S1840), and sending the updated second authentication list (operation S1850) for at least a predetermined time.

[0166] For example, the first network entity and the second network entity (or agents deployed therein) may periodically (or continuously) send the first authentication list and the second authentication list to the hub. Thus, the hub may periodically (or continuously) receive the first authentication list and the second authentication list, and then resume operations S1820 to S1850. Additionally, the first network entity may authenticate a new network entity (network change), and the first authentication list may be updated during the above-mentioned periodic transmission in the same manner as described above with respect to method 1400 and sent to the hub.

[0167] According to one embodiment, the hub may be further configured to send a notification to the second agent, receive a request from the second agent, and send an updated second authentication list to the second agent, in a manner similar to that described above in operations S1750 to S1770 of method 1700.

[0168] Figures 19A to 19C show exemplary flow sequences of exemplary use cases for advertising authenticated network entities according to a push-and-pull model in a hub-and-spoke configuration, according to one or more embodiments. The exemplary flow sequences in Figures 19A to 19C may involve the processes described above in relation to Methods 1600 and 1700.

[0169] As shown in Figures 19A to 19C, the network includes three network entities that deploy three agents (Agent 1, Agent 2, and Agent 3) and a centralized service (hub) located at the authentication server.

[0170] Prior to Step 1, Network Entity 1, Network Entity 2, and Network Entity 3 (with Agent 1, Agent 2, and Agent 3 deployed respectively) can subscribe to the hub under a push-and-pull model.

[0171] Between steps 1 and 3, network entity 1 may perform authentication with network entity 2 via the 802.1x process (i.e., the authentication process using the IEEE 802.1x RFC 5216 EAP-TLS authentication protocol). If authentication is successful, the sequence proceeds to step 4. On the other hand, if authentication fails, network entity 2 may issue a security alert and block data traffic to and from network entity 1.

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

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

[0174] During steps 7-11, network entity 3 may perform authentication with network entity 2 in the same manner as described above for steps 1-5, create / update its authentication list, and advertise its authentication list to the hub.

[0175] After step 11, the hub may send notifications about changes in the network to network entity 1, network entity 2, and network entity 3.

[0176] Between steps 12 and 14, network entity 1, network entity 2, and network entity 3 can send requests to the hub for updated authentication lists, and the hub can then send the updated authentication lists to network entities 1, 2, and 3, respectively.

[0177] 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 based on the authentication list of network entity 3 specifying network entity 2, it can create / update a trust list specifying that the trust level between network entity 2 and network entity 3 is direct trust.

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

[0179] It should be understood that the features and configuration described above are simplified for illustrative purposes and are not intended to limit the scope of this disclosure. For example, the number of network entities in the system may be any number, the number of ports on each of the network entities may be any number, each of the network entities may be authenticated with any other network entity, the sequence of steps may be in any different order, and additional steps may be included. Similarly, the authentication list and trust list may be in any other form and may include any additional information depending on the application.

[0180] In view of the above, the exemplary embodiment enables the hub and agent to advertise information about authenticated network entities in a hub-and-spoke configuration. Thus, the hub and agent can be easily notified of any changes to the network, and the agent can always have the latest version of the authentication list for each network entity in the network. Periodically or in response to a request, the hub can advertise the latest authentication list of network entities across the network so that all network entities in the network can update their local authentication lists. In this way, information about direct or indirect trusted connections between network entities and any other network entities can be made available to each network entity in the network. Furthermore, the exemplary embodiment also ensures that the hub is promptly notified whenever new data becomes available for transmission and responds to errors and retries in any failure scenario based on an "id" field to uniquely identify each message.

[0181] Example of operation: Determining the authentication status information of O-RU According to the embodiment, the network entity of the open fronthaul network may include an O-RU controller, at least one TNE, and at least one O-RU, the O-RU controller may be communicatively coupled to at least one O-RU via at least one TNE. The O-RU controller may include at least one of O-DU and SMO.

[0182] In this regard, the O-RU controller, TNE, and O-RU may include one or more of the components described above and / or be configured to perform one or more of the operations described above. For example, the O-RU controller and / or O-RU may include at least one processor and be configured to perform one or more operations for viewing and advertising information of authenticated network entities, etc. According to embodiments, the O-RU controller described herein may refer to a network entity, system, device, etc., including at least one processor configured to perform one or more of the operations described herein and one or more of the operations of the O-DU and / or SMO. Alternatively, the O-RU controller may refer to at least one processor itself.

[0183] In addition to the operations described above, an O-RU may be authenticated through an authentication process (e.g., an 802.1x process), and the O-RU controller may be configured to perform one or more operations to determine the authentication status information of the O-RU (e.g., whether the O-RU is authenticated or not) and to perform one or more operations based on that.

[0184] Specifically, the O-RU controller (or at least one processor associated with it) may be configured to obtain data link layer (also referred to herein as "Layer 2") information of the O-RU, such as the O-RU's MAC address, and may use this information to determine the authentication status of the O-RU. Thus, the O-RU controller may establish a channel binding (e.g., a channel binding from the data link layer to the application layer) and a chain of trust between the authenticated O-RU and the O-RU controller, and may isolate the unauthenticated O-RU from any further communication with the O-RU controller.

[0185] Figure 20 shows a block diagram of an exemplary system architecture 2000 of an open fronthaul network according to one or more embodiments. As shown in Figure 20, the system architecture 2000 may include at least one O-RU 2010, at least one TNE 2020, and at least one O-RU controller 2030. In practice, it can be understood that the system architecture 2000 may include two or more O-RUs, two or more TNEs, and / or two or more O-RU controllers without departing from the scope of this disclosure.

[0186] The O-RU controller 2030 may include an O-DU or SMO. The O-RU2010, TNE2020, and O-RU controller 2030 can authenticate each other through an authentication process (e.g., an 802.1x process). The O-RU controller 2030 can obtain (or be provided with) data link layer information of the O-RU2010 (e.g., the MAC address of the O-RU2010) and determine the authentication status of the O-RU2010 based on this information. For example, the O-RU controller 2030 can determine whether the O-RU2010 is authenticated or not based on the MAC address of the O-RU2010. Thus, based on the determination that the O-RU2010 is successfully authenticated (or has a certain level of trust with the O-RU controller 2030 after the authentication process), the O-RU controller 2030 can establish a channel binding and / or trust chain between the O-RU controller 2030 and the O-RU2010. Channel binding and / or trust chains may be established during one or more bring-up processes of O-RU2010.

[0187] Figure 21 shows a block diagram of another exemplary system architecture 2100 of an open fronthaul network according to one or more embodiments. The system architecture 2100 may 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 may be communicatively coupled to the first O-RU 2110 via TNEs 2140 and 2150, and may be communicatively coupled to the second O-RU 2120 via TNE 2160. According to the embodiment, the O-RU controller 2130 may act as a central controller or hub (e.g., hub 340) for controlling the O-RU 2110 and O-RU 2120. Alternatively, the hub may be a component independent of the O-RU controller 2130, and the O-RU controller 2130 may be communicatively coupled to the hub to obtain information necessary to control the O-RU 2110 and O-RU 2120.

[0188] The first O-RU2110 may have MAC address M20 and port SuP20 which has MAC address M21 and port AuP21 of TNE2140 which has the role of a supplicant and is authenticated (e.g., via an 802.1x process). Similarly, O-RU2120, TNE2140, TNE2150, TNE2160, and O-RU controller 2130 may be authenticated (e.g., via an 802.1x process) using other network entities.

[0189] Each network entity within the system architecture 2100 may have an authentication list, a trust list, or a combination of an authentication list and a trust list (including their respective authentication status information) constructed for it. These authentication lists and trust lists may collectively be referred to herein as a “trust data store.” An example of a trust data store for the network entity in Figure 21 is provided below with reference to Figures 22 and 23.

[0190] Figure 22 shows an example of a trust data store associated with the network entity in Figure 21, according to one or more embodiments. The trust data store contains 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 trust data store associated with the network entity may include parameters (e.g., ID, description, tag, etc.) that define the port(s) authenticated via the 802.1x process, the role of the authenticated port, the MAC address of the authenticated port(s) (shown as “source MAC”), and the MAC address of the port(s) from which the authenticated port(s) are authenticated via the 802.1x process.

[0191] For example, trust datastore 2210, built for O-RU2110, may contain information such as port SuP20 (i.e., the authenticated port of O-RU2110), 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 TNE2140, to which port SuP20 is authenticated (e.g., authenticated via an 802.1x process). A similar description applies to trust datastores 2220-2260, each associated with O-RU2120, TNE2140, TNE2150, TNE2160, and O-RU controller 2130.

[0192] According to the embodiment, the trust data store may contain information about the level of trust between network entities. For example, Figure 23 shows another example of a trust data store associated with the network entities in Figure 21, according to one or more embodiments.

[0193] As shown in Figure 23, a trust datastore 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 act as supplicants. Trust levels can include either direct trust or indirect trust. For example, a trust datastore 2330 associated with TNE2140 indicates that a port with MAC address M21 (i.e., port AuP21 of TNE2140) has a “direct trust” trust level with a port with MAC address M20 (i.e., port SuP20 of O-RU2110), and a port with MAC address M23 (i.e., port SuP23 of TNE2140) has an “indirect trust” trust level with a port with MAC address M26 (i.e., port SuP26 of O-RU controller 2130). A similar explanation applies to the trusted data stores 2310-2320 and 2340-2360, each associated with O-RU2110, O-RU2120, TNE2150, TNE2160, and O-RU controller 2130, respectively.

[0194] In some implementations, trust data stores built for each network entity may be advertised across an open fronthaul network, and a unified network-level trust data store (such as a network-level authentication list and a network-level trust list) may be built (e.g., built by a hub, built by one or more network entities). Trust data stores may be advertised or shared among network entities in the same manner as described above, for example, in peer-to-peer and / or hub-and-spoke configurations. Additionally or alternatively, the trust data stores of all network entities may be managed by a centralized agent (e.g., a hub, a centralized service, etc.).

[0195] For this purpose, whenever the O-RU controller is initially communicating with the O-RU (for example, during the O-RU startup process), the O-RU controller can determine the O-RU's authentication status information to ensure that the O-RU is 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 store(s) available in the open fronthaul network (or trusted data store(s) associated with the O-RU), and determine the authentication status information based on that.

[0196] It should be understood that the block diagrams in Figures 20 and 21, and the trust data stores in Figures 22 and 23, are merely examples of possible embodiments and the scope of this disclosure should not be limited thereto. Specifically, the open fronthaul network in Figure 20 and / or Figure 21 may include more / fewer components than those shown and / or be arranged in a different manner than those shown. For example, according to embodiments, without departing from the scope of this disclosure, O-RUs may be communicatively coupled to an authentication server (i.e., a server that performs the authentication process for the O-RUs) via one or more TNEs, and the O-RU controller may be communicatively coupled to a hub / centralized agent, etc. Furthermore, the trust data stores in Figures 22 and 23 may include more / fewer pieces of information than those shown, without departing from the scope of this disclosure.

[0197] Figure 24 shows a flowchart of an exemplary method 2400 for determining O-RU authentication status information and managing communication with the O-RU, according to one or more embodiments. One or more operations of method 2400 may be performed by an O-RU controller (or at least one processor associated therewith).

[0198] As shown in Figure 24, in operation S2410, the O-RU controller can be configured to obtain the MAC address of the O-RU. An exemplary operation for obtaining the MAC address of the O-RU will be described later with reference to Figures 27A and 27B.

[0199] Upon executing operation S2410, method 2400 may proceed to operation 2420, in which the O-RU controller may be configured to determine the authentication status of the O-RU. Specifically, the O-RU controller may determine the authentication status of the O-RU based on the MAC address of the O-RU. The authentication status of the O-RU may correspond to an Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) authentication process for the O-RU. For example, the O-RU controller may determine (determine) based on the MAC address of the O-RU whether the O-RU is authenticated via an 802.1x process (e.g., an EAP-TLS authentication process). An exemplary operation for determining the authentication status of the O-RU is described below with reference to Figure 25.

[0200] When operation S2420 is performed, method 2400 may proceed to operation 2430, in which the O-RU controller may be configured to manage communication with the O-RU. Specifically, the O-RU controller may be configured to manage communication with the O-RU based on determining whether or not the O-RU is authenticated. An exemplary operation for managing communication with the O-RU is described below with reference to Figure 26.

[0201] To this end, the O-RU controller can effectively and efficiently determine the authentication status information of one or more O-RUs, thereby enabling proper management of communication with one or more O-RUs.

[0202] Figure 25 shows a flowchart of an exemplary method 2500 for determining the authentication status of an O-RU according to one or more embodiments. One or more operations of method 2500 may be part of operation S2420 of method 2400 and may be performed by an O-RU controller (or at least one processor associated therewith).

[0203] As shown in Figure 25, in operation S2510, the O-RU controller may be configured to retrieve at least one trust data store. The trust data store may include at least one of the authentication list and trust list described above. According to the embodiment, the O-RU controller can retrieve all available trust data stores. Alternatively, the O-RU controller can retrieve the trust data store associated with the O-RU. For example, the O-RU controller can search for one or more trust data stores associated with the O-RU from among several trust data stores available in the network, based on the O-RU's ID (or any other appropriate parameter defining the O-RU's identity).

[0204] In some embodiments, the O-RU controller may be configured to retrieve a trusted datastore from storage associated with the O-RU controller (e.g., storage 440). Alternatively, the trusted datastore may be stored in another network entity (e.g., a hub), and the O-RU controller may be configured to communicate with and retrieve the trusted datastore from that network entity. For example, if the O-RU controller is an O-DU, the O-RU controller can retrieve a trusted datastore from an SMO, a hub, or another network entity in the network. In some implementations, the O-RU controller may be configured to retrieve a first trusted datastore from storage associated with the O-RU controller and a second trusted datastore from another network entity.

[0205] When operation S2510 is performed, method 2500 may proceed to operation S2520, in which the O-RU controller may be configured to cross-reference the MAC address of the O-RU with multiple MAC addresses contained in the trusted data store. By cross-referencing the MAC address of the O-RU with multiple MAC addresses in the trusted data store, the O-RU controller may determine whether the MAC address of the O-RU is included in the multiple MAC addresses in the trusted data store.

[0206] Based on the determination that the O-RU's MAC address is included in multiple MAC addresses in the trusted data store, method 2500 may proceed to operation S2530, in which the O-RU controller may be configured to determine that the O-RU is authenticated. Specifically, by determining that the O-RU's MAC address is included in the trusted data store, the O-RU controller can determine that the O-RU's information is included in the trusted data store, indicating that the O-RU is authenticated through an authentication process (e.g., an 802.1x process), that the O-RU is verified, and that it is trustworthy.

[0207] Instead, based on the determination that the O-RU's MAC address is not included in multiple MAC addresses in the trusted data store, method 2500 may proceed to operation S2540, and the O-RU controller may be configured to determine that the O-RU is not authenticated. Specifically, by determining that the O-RU's MAC address is not included in the trusted data store, the O-RU controller can determine that the O-RU's information is not included in the trusted data store, indicating that the O-RU has not been authenticated through an authentication process (e.g., an 802.1x process), that the O-RU is not verified, and that it is not trusted.

[0208] According to one embodiment, based on the determination that an O-RU (and / or associated MAC address) is included in a trusted data store, the O-RU controller can determine the trust level of the O-RU (e.g., direct trust, indirect trust, etc.), and based on that, the O-RU can be verified and determined to be trustworthy or not.

[0209] Figure 26 shows a flowchart of an exemplary method 2600 for managing communication with an O-RU according to one or more embodiments. One or more operations of method 2600 may be part of operations S2420 and S2430 in method 2400 and may be performed by an O-RU controller (or at least one associated processor).

[0210] As shown in Figure 26, in operation S2610, the O-RU controller can be configured to determine whether or not the O-RU is authenticated. Operation S2610 may be similar to one or more operations described above with reference to method 2500, or it may be part of operation S2420 of method 2400.

[0211] Based on the determination that the O-RU is authenticated, method 2600 may proceed to operation S2620, in which case the O-RU controller may be configured to establish a channel binding with the O-RU. The term “channel binding” as used herein may refer to a feature that binds authentication information to a communication channel (e.g., a TLS channel) between the O-RU controller and the O-RU, as defined in one or more specifications (e.g., Request for Comment (RFC) specifications) of one or more standards bodies (e.g., the Internet Engineering Task Force (IETF)). For example, channel binding may bind information from an authenticated channel (e.g., a TLS channel) to an authenticated event (e.g., access from an authenticated O-RU, a communication session with an authenticated O-RU). By establishing a channel binding, communication between the O-RU controller and the O-RU can be made secure, and potential security risks (e.g., session hijacking) can be prevented.

[0212] Instead, based on the determination that the O-RU is unauthenticated, method 2600 may proceed to operation S2630, in which case the O-RU controller may be configured to isolate the O-RU from further communication with the O-RU controller. In this way, further communication between the unauthenticated O-RU and the O-RU controller can be avoided, thereby preventing potential security issues that the unauthenticated O-RU may have (e.g., O-RU identity spoofing).

[0213] According to the embodiment, establishing a channel binding with an authenticated O-RU (S2620) or separating an unauthenticated O-RU (S2630) may be performed during the TLS session establishment phase (an exemplary use case related thereto is described below with reference to Figures 28A and 28B). Additionally or alternatively, establishing a channel binding with an authenticated O-RU or separating an unauthenticated O-RU may be performed during the Network Configuration Protocol (NETCONF) session establishment phase (an exemplary use case related thereto is described below with reference to Figures 28A and 28C).

[0214] Exemplary operations for obtaining the MAC address of an O-RU are described below with reference to Figures 27A and 27B. Figure 27A shows a flowchart of an exemplary method 2700 for obtaining the MAC address of an O-RU according to one or more embodiments. One or more operations of method 2700 may be part of operation S2510 in method 2500 and may be performed by the O-RU controller (or at least one associated processor) during the TLS session establishment phase.

[0215] As shown in Figure 27A, in operation S2710, the O-RU controller may be configured to receive a vendor certificate from the O-RU. The vendor certificate may be pre-provisioned on the O-RU and may 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 in an extension area of ​​the x.509 certificate (e.g., the Subject Alternative Name (SAN) field) (e.g., by the O-RU's vendor). The vendor certificate may be received by the O-RU controller during the mutual authentication procedure in the TLS session establishment phase. The mutual authentication procedure may include the mTLS process.

[0216] When operation S2710 is performed, method 2700 may proceed to operation S2720, in which the O-RU controller may be configured to extract the O-RU's MAC address from the vendor certificate. For this purpose, the O-RU controller can obtain the O-RU's MAC address during the TLS session establishment phase.

[0217] Figure 27B shows a flowchart of another exemplary method 2705 for obtaining the MAC address of an O-RU according to one or more embodiments. 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 associated processor) during the NETCONF session establishment phase.

[0218] As shown in Figure 27B, in operation S2715, the O-RU controller may 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 the O-RU's inventory information (e.g., serial number). The O-RU's inventory information may also be requested by the O-RU controller when providing NETCONF configuration information to the O-RU. The O-RU controller may send a request to the O-RU during the NETCONF session establishment phase.

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

[0220] Upon receiving O-RU information in operation S2725, method 2705 may proceed to operation S2735, in which the O-RU controller may be configured to extract the MAC address of the O-RU from the O-RU information. For this purpose, the O-RU controller may obtain the MAC address of the O-RU during the NETCONF session establishment phase.

[0221] Exemplary use cases associated with the operation of methods 2400, 2500, 2600, 2700, and 2705 are provided below with reference to Figures 28A to 28C. Specifically, Figure 28A shows an exemplary use case flow sequence for the O-RU bring-up process, Figure 28B shows an exemplary use case flow sequence for determining the O-RU's authentication status information and managing communication with the O-RU during the TLS session establishment phase, and Figure 28C shows an exemplary use case flow sequence for determining the O-RU's authentication status information and managing communication with the O-RU during the NETCONF session establishment phase, according to one or more embodiments.

[0222] Referring to Figure 28A, an O-RU can function as a TLS server / NETCONF server, an O-RU controller can function 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 may or may not contain the MAC address of the O-RU embedded within it.

[0223] During Step 1, the O-RU is powered on in its initial state. For example, the O-RU may be powered on during the O-RU bring-up process.

[0224] During Step 2, the O-RU can perform an authentication process. For example, the O-RU can perform an 802.1x process using the TNE. The TNE can connect the O-RU to the O-RU controller and / or the operator's public key infrastructure (PKI), such as the operator's Certificate Authority (CA). The 802.1x process may include one or more EAP-TLS authentication processes, each of which may include one or more authentication processes compliant with the IEEE 802.1x RFC5216 EAP-TLS authentication protocol. Furthermore, the EAP-TLS authentication operation may be based on the O-RU's vendor certificate and / or on an operator signing certificate provided by the operator CA.

[0225] If authentication is successful, the flow sequence may proceed to further steps. For example, upon successful authentication with the TNE, the O-RU may be permitted to communicate further with the O-RU controller and / or the operator CA. For instance, once it is determined that the O-RU has been successfully authenticated via the 802.1x process, the port of the TNE that is communicably coupled to the O-RU may allow further traffic to and from the O-RU so that the O-RU can communicate with the O-RU controller and / or the operator CA.

[0226] On the other hand, if authentication fails, the O-RU can be isolated from the network. For example, if authentication is determined to have failed (e.g., an 802.1x process has failed), the TNE can block the O-RU's traffic and therefore terminate the flow sequence, isolating the O-RU, and preventing communication between the O-RU and the O-RU controller and / or operator CA.

[0227] During step 3, the O-RU (which successfully authenticated in step 2) can communicate with the operator CA for 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 the embodiment, in addition to operator-signed certificates, the O-RU can also obtain one or more trust anchors from the operator CA. In this regard, the trust anchors may include information that can be used by the O-RU to verify the identity of the operator CA. For example, the trust anchors may include a root certificate, a public key, and the identity information of the operator CA (e.g., a domain name).

[0228] Subsequently, during step 4, the O-RU may be reinitialized / reset, and the flow sequence may return to step 1. In this regard, the O-RU may be re-authenticated based on the operator signature certificate(s) via an authentication process (e.g., an 802.1x process). Steps 3 and 4 described herein are intended to be optional. For example, steps 3 and 4 may 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 may be omitted.

[0229] For this purpose, once the initial authentication of the O-RU is complete, the O-RU can communicate with the O-RU controller to perform further operations. For example, upon successful authentication based on vendor certificates (and operator-signed certificates, 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.

[0230] In this regard, communication between the O-RU and the O-RU controller takes place via a Transmission Control Protocol (TCP) session. A TLS session is established during the NETCONF call home register procedure within the TCP session, thereby achieving reliable and secure communication between the O-RU and the O-RU controller. For example, once a TCP session is established, the O-RU and the O-RU controller can exchange information over a secure channel to establish a TLS session.

[0231] The TLS session establishment phase involves a series of steps in which both the TLS client (i.e., the O-RU controller) and the TLS server (i.e., the O-RU) participate in establishing a secure communication channel between them. In particular, mutual authentication is a step in the TLS session establishment phase in which both the TLS client and the TLS server verify each other's identity by exchanging one or more security certificates (e.g., one or more x.509 certificates). The mutual authentication procedure may include the mTLS process.

[0232] In this regard, if the O-RU controller receives a security certificate (e.g., a vendor certificate) from the O-RU during the mutual authentication procedure and 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 may determine (determine) the O-RU's authentication status information and, based on that, initiate operations to manage communication with the O-RU (an illustrative use case is provided below with reference to Figure 28B).

[0233] According to one embodiment, if the O-RU controller determines that the O-RU's MAC address is not available in the security certificate (for example, the MAC address is not embedded in the vendor certificate), the O-RU controller may complete the TLS session establishment phase and obtain the O-RU's MAC address in a later phase. For example, the O-RU controller may request the MAC address during the NETCONF session establishment phase after the TLS connection between the O-RU controller and the O-RU has been successfully established (an illustrative use case is provided below with reference to Figure 28C). Thus, in the following description, the flow sequences in Figures 28B and 28C may begin from step 5, indicating that the flow sequence is a continuation of the flow sequence in Figure 28A.

[0234] Referring to Figure 28B, during step 5, a TCP session may be established between the O-RU and the O-RU controller. During step 6, the O-RU controller (i.e., the TLS client) may send a client Hello message to the O-RU (i.e., the TLS server) to initiate the TLS handshake procedure. The client Hello message may include information relevant to the O-RU controller, such as supported cryptographic algorithms, supported TLS versions, and any other appropriate information. Then, in step 7, the O-RU may send a server Hello message to the O-RU controller in response to receiving the client Hello message.

[0235] Furthermore, during step 8, the O-RU may send requests to the O-RU controller for a vendor certificate (i.e., an x.509 certificate with the O-RU's MAC address embedded) and a TLS client certificate (e.g., an operator-signed certificate). As part of the mutual authentication procedure, the vendor certificate can act as a TLS server certificate and be used by the O-RU controller to authenticate the O-RU, while the TLS client certificate can be used by the O-RU to authenticate the O-RU controller. In view of the above, the O-RU controller may receive requests from the O-RU for both the vendor certificate and the TLS client certificate during the TLS session establishment phase.

[0236] During step 9, the O-RU controller can extract the O-RU's MAC address from the vendor certificate in a similar manner to that described above with respect to method 2700 in Figure 27A.

[0237] During step 10, the O-RU controller may verify the O-RU's MAC address before providing the requested TLS client certificate to the O-RU. For example, as part of a mutual authentication procedure using a vendor certificate (e.g., an x.509 certificate), the O-RU controller may verify the O-RU's certificate file verification path and / or compare the contents of the vendor certificate with previously trusted values.

[0238] According to the embodiment, the O-RU controller can obtain a trusted datastore, as previously described with reference to Methods 2400 and 2500, and can determine the authentication status of the O-RU (based on the O-RU's MAC address and information in the trusted datastore). The authentication status of the O-RU can correspond to an 802.1x process for the O-RU (e.g., an EAP-TLS authentication process). According to the embodiment, the O-RU controller can obtain a trusted datastore from a hub or a centralized service / agent. Alternatively, the O-RU controller obtains a trusted datastore from storage associated with the O-RU controller (e.g., storage 440).

[0239] Therefore, based on the determination that the O-RU is authenticated, the O-RU controller may establish a channel binding with the O-RU. If the channel binding is successful, during step 11 the O-RU controller may send the TLS client certificate (e.g., the operator-signed certificate requested by the O-RU in step 8) to the O-RU and continue with the TLS session establishment procedure.

[0240] Otherwise, during step 12, based on the determination that the O-RU is not authenticated, or based on the determination that channel binding is unsuccessful, the O-RU controller may 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, session teardown occurs in the TLS session establishment phase without allowing the unauthenticated O-RU to communicate further with the O-RU controller.

[0241] In addition to providing the O-RU's MAC address to the O-RU controller by embedding the MAC address in the vendor certificate, or alternatively, the MAC address may be provided to the O-RU controller by the O-RU in response to a request or query from the O-RU controller.

[0242] Referring to Figure 28C, during step 5, a TCP session between the O-RU and the O-RU controller may be established in a manner similar to that described above with reference to step 5 in Figure 28B. In this regard, it is intended that one or more operations in Figure 28C may be similar to one or more operations in Figure 28B. For example, steps 5, 10, and 12 in Figure 28C may be similar to steps 5, 10, and 12 in Figure 28B, respectively. The exemplary use case in Figure 28C differs from the exemplary use case in Figure 28B in that the exemplary use case in Figure 28C does not require the O-RU's MAC address to be embedded in the vendor certificate (e.g., an x.509 certificate) and provided to the O-RU controller during the TLS session establishment phase. Rather, the O-RU controller may obtain the O-RU's MAC address during the NETCONF session establishment phase after the TLS connection has been established. The exemplary use case in Figure 28C may be useful when the O-RU vendor does not embed the O-RU's MAC address in the vendor certificate (e.g., an x.509 certificate).

[0243] In step 6, a successful TLS connection can be established, and the NETCONF session establishment phase can begin. During step 7, the O-RU controller (i.e., the NETCONF client) may send queries or requests to the O-RU (i.e., the NETCONF server) to obtain O-RU information. The requested O-RU information may include the O-RU inventory information required in the NETCONF session establishment phase (e.g., the O-RU's serial number) and the O-RU's MAC address. Thus, during step 8, the O-RU can provide the O-RU controller with the requested O-RU information (including the O-RU's MAC address and O-RU inventory information), and the O-RU controller can receive the O-RU information from the O-RU.

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

[0245] Next, during step 10, the O-RU controller may verify the MAC address of the O-RU and determine the authentication status of the O-RU (based on the MAC address of the O-RU and the information in the trusted datastore) in a manner similar to that described above in relation to step 10 in Figure 28B. Thus, during step 11, the O-RU may establish a channel binding with the O-RU (based on the determination that the O-RU is authenticated), or the O-RU may be isolated from any additional communication with the O-RU controller (based on the determination that the O-RU is not authenticated) in a manner similar to that described above with reference to steps 10 to 12 in Figure 28B.

[0246] In this case, session termination occurs during the NETCONF session establishment phase without allowing the unauthenticated O-RU to communicate further with the O-RU controller. On the other hand, if the O-RU is determined to be authenticated and channel binding is successful, during step 11, the O-RU controller may generate one or more NETCONF configuration pieces (based on the O-RU information) and send one or more NETCONF configuration pieces to the O-RU. The NETCONF session establishment procedure can then continue.

[0247] In this regard, one or more NETCONF configuration information may define one or more NETCONF configurations. According to the embodiment, one or more NETCONF configuration information may include information associated with configuration management, such as information for managing one or more configurations associated with the O-RU. For example, one or more NETCONF configuration information may include information for managing the frequency configuration of the O-RU (e.g., carrier frequency, channel bandwidth, etc.), information for managing the power configuration of the O-RU (e.g., transmit power level to meet signal quality requirements, power control parameters to achieve power efficiency, etc.), information for managing the cell configuration of the cell in which the O-RU is located (e.g., cell identity, cell type, supported handover and mobility mechanisms, etc.), and any other appropriate information for managing the O-RU configuration(s) for wirelessly acquiring the O-RU and making the O-RU operational.

[0248] It should be understood that the steps shown in the flow sequences of Figures 28A to 28C are merely examples of possible embodiments, and the scope of this disclosure is not limited thereto. Specifically, without departing from the scope of this disclosure, one or more steps shown in Figures 28A to 28C may be omitted, one step may be combined with another, or one or more steps may be added.

[0249] In consideration of the foregoing, exemplary embodiments of this disclosure provide apparatus, methods, etc., that enable an O-RU controller to effectively and efficiently determine the authentication status information of an O-RU. Specifically, exemplary embodiments provide the O-RU controller with data link layer information of the O-RU (e.g., the MAC address of the O-RU) and define a security mechanism or approach to enable the O-RU controller to determine the authentication status information of the O-RU based on the data link layer information. Thus, the O-RU controller can determine whether to establish a channel binding with the O-RU or to isolate the O-RU based on that. In this way, the O-RU controller can effectively and efficiently manage communication with one or more O-RUs connected to it without implicitly or inherently trusting the one or more O-RUs. Ultimately, the security of the open fronthaul network can be enhanced, and communication between one or more O-RUs and O-RU controllers can be securely established while satisfying a zero-trust model.

[0250] In conventional technology, the SMO (Service Management and Orchestration) or O-DU (O-RAN Distributed Unit) implicitly trusts the O-RU (O-RAN Radio Unit) to authorize communication at startup and installation. Before treating the O-RU as a trusted entity, there is no defined channel binding method to verify the authorization status of the O-RU 802.1X in the open fronthaul network during the registration of the O-RU with the SMO and / or O-DU (collectively, the "O-RU Controller").

[0251] According to exemplary embodiments of this disclosure, an O-RU controller can establish channel binding between the Ethernet layer and the application layer, and thus establish a trust relationship with the O-RU in an open fronthaul network environment. According to exemplary embodiments of this disclosure, the O-RU controller can obtain knowledge of the IEEE 802.1X authorized port status of the O-RAN radio unit (O-RU). Thus, the trust model and channel binding can be made available to the open fronthaul network according to exemplary embodiments of this disclosure. This ensures enhanced security for communication between entities in the fronthaul network.

[0252] The embodiments of this disclosure will be described below. A. Channel binding during the TLS connection establishment phase O-RU has the MAC address of its NIC, which is included in the "extension" portion of its x.509 certificate. This MAC address is used to verify the identity of O-RU in the trusted datastore during mTLS communication between O-RU & SMO and / or O-RU & O-DU during the TLS session establishment process. i. In the initial state, the O-RU must be powered on. ii. The O-RU successfully performs 802.1X authentication with the switch using a pre-provisioned factory (vendor) certificate, and the switch port then allows further traffic to the O-RU controller (O-DU or SMO) using the open fronthaul network. iii. Next, the O-RU must communicate with the operator CA for certificate registration. iv.O-RU reinitializes / resets itself and authenticates using an operator-signed x509 certificate in accordance with 802.1x. Communication between the vO-RU and the O-RU controller (O-DU or SMO) is conducted via the NETCONF protocol over Transport Layer Security (TLS) with mutual X.509 authentication. The O-RU controller, acting as a vi.TLS client, sends a client Hello message to initiate the TLS handshake. vii. The TLS and NETCONF servers, which are ORUs in the O-RAN network, request certificates from clients by sending a Server Hello message, a Server Certificate Chain, and a CertificateRequest message. As part of the mutual authentication procedure using viii.x.509 certificates, the client shall verify the server's certificate file validation path or compare the contents of the certificate with previously trusted values. ix. The NETCONF and TLS clients, which are O-RU controllers, query a centralized agent of the trusted open fronthaul framework to compare the trust relationships of the O-RU MAC addresses in the trust table database. Once the trust relationship verification is successfully completed, the SMO (Service Management Orchestrator) / O-DU can establish channel binding. xi. Upon successful channel binding, the O-RU controller (TLS client) sends its own client certificate for the TLS connection being established. xii. If a trust relationship is not established or satisfied, the SMO or O-DU will perform network isolation with respect to the O-RU and will not allow any further communication between the O-RU and the SMO or between the O-RU and the O-DU, thus resulting in a connection / session teardown during the TLS connection establishment phase. Channel binding during the B.NETCONF configuration phase i. In the initial state, the O-RU is powered on. ii. The O-RU successfully performs 802.1X authentication with the switch using a pre-provisioned factory (vendor) certificate, and the switch port then allows further traffic to the O-RU controller (O-DU or SMO) using the open fronthaul network. iii. Next, the O-RU must communicate with the operator CA for certificate registration. iv.O-RU reinitializes / resets itself and authenticates using 802.1x with an x509 certificate signed by the operator. Communication between the vO-RU and the O-RU controller [O-DU and / or SMO] is conducted via the NETCONF protocol over Transport Layer Security (TLS) using mutual X.509 authentication, in accordance with the current M-PLANE specification in the O-RAN WG4 MP document. Successfully established a vi.TLS connection. The vii.NETCONF client [O-RU controller] queries the O-RU (NETCONF server) to obtain O-RU information such as the serial number and MAC address. viii.O-RU sends the necessary details to the O-RU controller. ix. The NETCONF and TLS clients, which are O-RU controllers, query a centralized agent of the trusted open fronthaul framework to compare the trust relationships of the O-RU MAC addresses in the trust table database. x. Next, the O-RU verifies the received MAC address by cross-referencing it with the trusted data store stored in the centralized agent. If the xi.MAC address is deemed trustworthy, it allows further NETCONF communication to proceed, which is performed on the O-RU by software and configuration management. xii. If a trust relationship is not established or satisfied, the O-RU controller shall perform network isolation for the O-RU and shall not allow any further communication between the O-RU and the SMO or O-DU.

[0253] Example of an implementation environment Figure 29 shows a diagram of an exemplary environment 2900 in which the system and / or method described herein may be implemented. As shown in Figure 29, the environment 2900 may include a device 2910, a platform 2920, and a network 2930. The devices in environment 2900 can be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections. In some embodiments, any of the functions and operations described above with reference to Figures 2 to 28C may be performed by any combination of the elements shown in Figure 29.

[0254] In some embodiments, the network entities described herein (e.g., O-RU controllers) may be stored, hosted, or deployed on the cloud computing platform 2920. In this regard, device 2910 may include devices, systems, equipment, etc., used by users (e.g., users of the marketing team, users of the network planning team, etc.) to access the network entities and / or platform 2920. In this case, device 2910 may include one or more devices that can receive, generate, store, process, and / or provide information related to platform 2920.

[0255] Platform 2920 may include one or more devices capable of receiving, generating, storing, processing, and / or providing information. In some implementations, Platform 2920 may include a cloud server or a group of cloud servers. In some implementations, Platform 2920 may be designed to be modular so that certain software components can be swapped in or out as needed. Thus, Platform 2920 can be easily and / or quickly reconfigured for different applications.

[0256] In some implementations, as shown, platform 2920 can be hosted in a cloud computing environment 2922. In particular, while the implementations described herein are described with platform 2920 being hosted in cloud computing environment 2922, in some implementations, platform 2920 may not be cloud-based (i.e., may be implemented outside of a cloud computing environment) or may be partially cloud-based.

[0257] Cloud computing environment 2922 can include an environment for hosting platform 2920. Cloud computing environment 2922 can provide services such as computing, software, data access, storage, etc., without the knowledge of the physical location and configuration of the system(s) and / or device(s) (if any) hosting platform 2920 and the end user (e.g., user device 2910). As shown, cloud computing environment 2922 may include a group of computing resources 2924 (collectively referred to as "computing resources 2924" and individually as "a computing resource 2924").

[0258] Computing resources 2924 can include one or more personal computers, clusters of computing devices, workstation computers, server devices, or other types of computing and / or communication devices. In some implementations, computing resources 2924 can host platform 2920. Cloud resources can include computing instances running on computing resources 2924, storage devices provided on computing resources 2924, data transfer devices provided by computing resources 2924, and the like. In some implementations, computing resources 2924 may communicate with other computing resources 2924 via a wired connection, a wireless connection, or a combination of a wired connection and a wireless connection.

[0259] As further shown in FIG. 29, the computing resource 2924 can include a group of cloud resources such as one or more applications (“APP”) 2924-1, one or more virtual machines (“VM”) 2924-2, one or more virtualized storages (“VS”) 2924-3, one or more hypervisors (“HYP”) 2924-4, etc. The current exemplary embodiment refers to virtualized network functions, but one or more other embodiments are not limited thereto 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 exemplary embodiments, any of the above components can be software-based components deployed or hosted on a server cluster such as a hybrid cloud server, a data center server, etc. The software-based components may be containerized and may be deployed and controlled by one or more machines referred to as “nodes” that operate or execute containerized network elements. In this regard, the server cluster may contain at least one master node and a plurality of worker nodes, and the master node(s) controls and manages a set of associated worker nodes.

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

[0261] A virtual machine 2924-2 may include a software implementation of a machine (e.g., a computer) that runs programs like a physical machine. Depending on its application and the degree to which the virtual machine 2924-2 corresponds to any physical machine, it may be either a system virtual machine or a process virtual machine. A system virtual machine can provide a complete system platform that supports the execution of a complete operating system ("OS"). A process virtual machine can run a single program and support a single process. In some implementations, the virtual machine 2924-2 can run on behalf of a user (e.g., a user device 2910) and manage the infrastructure of a cloud computing environment 2922, such as data management, synchronization, or long-term data transfer.

[0262] Virtualized storage 2924-3 may include one or more storage systems and / or one or more devices that use virtualization technology within the storage system or device of the computing resource 2924. In some implementations, within the context of the storage system, the types of virtualization may include block virtualization and file virtualization. Block virtualization may refer to the abstraction (or separation) of logical storage from physical storage so that the storage system can be accessed regardless of whether it is physical storage or heterogeneous. This separation gives the storage system administrator flexibility in how the administrator manages the storage for end users. File virtualization may eliminate the dependency between data accessed at the file level and where the file is physically stored. This may enable optimized storage usage, server consolidation, and / or performance of non-disruptive file migration.

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

[0264] Network 2930 may include one or more wired and / or wireless networks. For example, Network 2930 may include cellular networks (e.g., fifth-generation (5G) networks, long-term evolution (LTE) networks, third-generation (3G) networks, code division multiple access (CDMA) networks, etc.), public land mobile networks (PLMN), local area networks (LANs), wide area networks (WANs), metropolitan area networks (MANs), telephone networks (e.g., public switched telephone networks (PSTNs)), private networks, ad hoc networks, intranets, the Internet, fiber optic-based networks, etc., and / or combinations of these or other types of networks.

[0265] The number and arrangement of devices and networks shown in Figure 29 are provided as examples. In practice, there may be additional devices and / or networks, fewer devices and / or networks, different devices and / or networks, or differently configured devices and / or networks compared to those shown in Figure 29. Furthermore, two or more devices shown in Figure 29 may be implemented within a single device, or a single device shown in Figure 29 may be implemented as multiple distributed devices. Additionally or alternatively, a set of devices in environment 2900 (e.g., one or more devices) may perform one or more functions described as being performed by another set of devices in environment 2900.

[0266] According to the embodiments, one or more operations of the exemplary embodiments described above can be implemented or deployed on the server platform 2920 described above in the form of virtualized network functions (VNFs), containerized and / or cloud-native functions (CNFs), etc. In this regard, the terms “virtual” and “virtualized” as used herein are merely intended to specify the nature of machines (and associated elements and resources) provided in virtual or software form. The terms “virtual machine,” “virtualized storage,” etc., as used above should not be limited to a specific type of virtual machine or virtual element. Accordingly, it can be understood that one or more operations of the exemplary embodiments described above may be defined or presented in the form of containerized network functions, and one or more such operations may be provided in the form of containers.

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

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

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

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

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

[0272] These computer-readable program instructions may be provided to a general-purpose computer, a dedicated computer, or a processor of another programmable data processing device to create a machine, so as to create means for instructions executed via the processor of a computer or other programmable data processing device to implement functions / operations specified in one or more blocks of a flowchart and / or block diagram or both. These computer-readable program instructions may also be stored on a computer-readable storage medium so as to provide a product containing instructions that implement modes of functions / operations specified in one or more blocks of a flowchart and / or block diagram or both, and can instruct a computer, a programmable data processing device, and / or other device, or a combination thereof, to function in a particular manner.

[0273] Computer-readable program instructions may also be loaded into a computer, another programmable data processing device, or another device to create a computer implementation process that causes the instructions executed on the computer, another programmable data processing device, or another device to implement a function / operation specified in one or more blocks of a flowchart and / or block diagram, or both, and to cause the computer, another programmable data processing device, or other device to execute a series of operational steps.

[0274] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media in various embodiments. In this regard, each block in a flowchart or block diagram may represent a microservice(s) module, segment, or part of an instruction set containing one or more executable instructions for implementing a specified logical function(s). Methods, computer systems, and computer-readable media may include additional blocks, fewer blocks, different blocks, or blocks arranged differently from those shown in the figures. In some alternative implementations, the functions described in the blocks may be performed in an order different from that shown in the figures. For example, two consecutively shown blocks may actually be executed simultaneously or substantially simultaneously, or blocks may sometimes be executed in reverse order depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, or both, and any combination of blocks in a block diagram and / or flowchart, or both, may be implemented by a dedicated hardware-based system that performs a specified function or operation, or a combination of dedicated hardware and computer instructions.

[0275] It will be apparent that the systems and / or methods described herein may be implemented in different forms of hardware, firmware, or combinations of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not limited to any specific implementation. Therefore, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It should be understood that software and hardware may be designed to implement the systems and / or methods based on the descriptions herein.

[0276] Various further embodiments and features of the embodiments of this disclosure may be defined by the following items. Item [1]: Open Radio Access Network (O-RAN) Radio Unit (O-RU) Controller. The O-RU controller may be configured to obtain the O-RU's Medium Access Control (MAC) address, determine the O-RU's authentication status based on the O-RU's MAC address, establish a channel binding with the O-RU based on the determination that the O-RU is authenticated, and isolate the O-RU from further communication with the O-RU controller based on the determination that the O-RU is not authenticated. Item [2]: The authentication status of the O-RU can correspond to the Extended Authentication Protocol - Transport Layer Security (EAP-TLS) authentication process for the O-RU, as described in Item [1] of the O-RU controller. Item [3]: The O-RU controller described in Item [1] or [2] may be configured to receive a vendor certificate from the O-RU, the vendor certificate containing the MAC address of the O-RU, and to obtain the MAC address of the O-RU by extracting the MAC address of the O-RU from the vendor certificate. Item [4]: ​​The O-RU controller may be configured to receive a vendor certificate and a first request for a TLS client certificate from the O-RU during the transport layer security (TLS) session establishment phase, as described in Item [3]. Item [5]: The O-RU controller described in Item [4] may be further configured to send a TLS client certificate to the O-RU after a channel binding with the O-RU has been established. Item [6]: The O-RU controller described in Item [1] or [2] may be configured to obtain the MAC address of an O-RU by sending a second request for O-RU information to an O-RU, the O-RU information may include the MAC address of the O-RU, receiving O-RU information from the O-RU, and extracting the MAC address from the O-RU information. Item [7]: The O-RU controller according to item [6] may be configured to send a second request for O-RU information to the O-RU during the network configuration protocol (NETCONF) session establishment phase. Item [8]: The O-RU controller according to item [7] may 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. Item [9]: The O-RU controller according to any one of items [1] to [8] may be configured to determine the authentication status of the O-RU by obtaining a trust data store related to the O-RU, cross-referencing the MAC address of the O-RU with a plurality of MAC addresses included in the trust 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 is authenticated based on determining that the MAC address of the O-RU is included in the plurality of MAC addresses, and determining that the O-RU is not authenticated based on determining that the MAC address of the O-RU is not included in the plurality of MAC addresses. Item

[10] : The O-RU controller according to item [9] may include at least one of an authentication list related to the O-RU and a trust list related to the O-RU in the trust data store. Item

[11] : The O-RU controller according to any one of items [1] to

[10] may include at least one of an O-RAN distributed unit (O-DU) and a service management and orchestrator (SMO). Item

[12] : A method implemented by an Open Radio Access Network (O-RAN) Radio Unit (O-RU) controller. The method includes obtaining the Media Access Control (MAC) address of the O-RU, determining the 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 the determination that the O-RU is authenticated, and isolating the O-RU from further communication with the O-RU controller based on the determination that the O-RU is not authenticated. Item

[13] : The authentication status of the O-RU may correspond to the Extended Authentication Protocol-Transport Layer Security (EAP-TLS) authentication process for the O-RU, as described in Item

[12] . Item

[14] : The method of Item

[12] or

[13] , wherein obtaining the MAC address of O-RU is to receive a vendor certificate from O-RU, the vendor certificate may contain the MAC address of O-RU, and to extract the MAC address of O-RU from the vendor certificate. Item

[15] : The method described in Item

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

[16] : The method as described in Item

[15] , which may further include sending a TLS client certificate to the O-RU after a channel binding with the O-RU has been established. Item

[17] : The method of Item

[12] or

[13] , wherein obtaining the MAC address of an O-RU means sending a second request to the O-RU for O-RU information, which may include the serial number of the O-RU and the MAC address of the O-RU; receiving O-RU information from the O-RU; and extracting the MAC address from the O-RU information. Item

[18] : The method of Item

[17] , which may include sending a second request for O-RU information to the O-RU during the Network Configuration Protocol (NETCONF) session establishment phase. Item

[19] : The method according to Item

[18] , which may further include generating one or more NETCONF configuration pieces based on O-RU information, and sending one or more NETCONF configuration pieces to the O-RU after a channel binding with the O-RU has been established. Item

[20] : Non-temporary computer-readable recording medium. The non-temporary computer-readable recording medium may record instructions that can be executed 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 the O-RU's media access control (MAC) address; determining the O-RU's authentication status based on the O-RU's MAC address; establishing a channel binding with the O-RU based on the determination that the O-RU is authenticated; and isolating the O-RU from further communication with the O-RU controller based on the determination that the O-RU is not authenticated. Item

[21] : Network entity, wherein it creates a first authentication list, the first authentication list may specify one or more network entities to be authenticated with the network entity; receives a second authentication list from a second network entity, the second authentication list may specify one or more network entities to be authenticated with the second network entity, the network entity and the second network entity may be authenticated with each other; and is configured to create a trust list, based on the first and second authentication lists, the trust list may be configured to specify a level of trust between the network entity and one or more network entities in the first and second authentication lists. Item

[22] : The network entities described in Item

[21] , where the trust level may include one of direct trust and indirect trust, and the trust level may be between one or more ports of a network entity and one or more ports of one or more network entities in the first and second authentication lists having the role of supplicant. Item

[23] : A trust list may include one or more MAC addresses of one or more ports of a network entity and one or more MAC addresses of one or more ports of one or more network entities in the first and second authentication lists that have the role of supplicant, as described in Item

[22] . Item

[24] : A network entity as described in any one of items

[21] to

[23] , which may be configured to create a trust list based on a first authentication list and a second authentication list by creating a trust list based on a first authentication list such that the trust list specifies the level of trust between the network entity and 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 further specifies the level of trust between the network entity and one or more network entities in the second authentication list. Item

[25] : The network entity described in Item

[24] may be further configured to send the updated first authentication list to one or more network entities authenticated by the network entity. Item

[26] : The second authentication list may further specify one or more network entities to be authenticated by the third network entity, the third network entity being one of the network entities listed in any one of items

[21] to

[25] that can be authenticated by the second network entity. Item

[27] : A network entity as described in any one of items

[21] to

[26] , wherein the first authentication list may specify one or more first MAC addresses of one or more ports of a network entity, one or more third MAC addresses of one or more ports of one or more network entities authenticated with one or more first MAC addresses, and one or more roles of one or more ports of a network entity; the second authentication list may specify one or more second MAC addresses of one or more ports of a second network entity, one or more fourth MAC addresses of one or more ports of one or more network entities authenticated with one or more second MAC addresses, and one or more roles of one or more ports of a second network entity, the roles of which may include one of authenticator and supplicant. Item

[28] : Authentication between a network entity, a second network entity, and one or more network entities may be based on an 802.1x process, as described in any one of items

[21] to

[27] . Item

[29] : A network entity, a second network entity, and one or more network entities, which may 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), as described in any one of items

[21] to

[28] . Item

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

[31] : A method which may include creating a first authentication list for a first network entity, the first authentication list may specify one or more network entities that are authenticated using the first network entity; receiving a second authentication list from a second network entity, the second authentication list may specify one or more network entities that are authenticated using the second network entity, 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 and second authentication lists, the trust list for the first network entity may specify a level of trust between the first network entity and one or more network entities in the first and second authentication lists. Item

[32] : The method according to Item

[31] , wherein the trust level may include one of direct trust and indirect trust, and the trust level may be between one or more ports of a first network entity and one or more ports of one or more network entities in first and second authentication lists having the role of supplicant. Item

[33] : The method according to Item

[32] , wherein the trust list for the first network entity may include one or more MAC addresses of one or more ports of the first network entity and one or more MAC addresses of one or more ports of one or more network entities in the first and second authentication lists having the role of supplicant. Item

[34] : The method described in any one of items

[31] to

[33] , wherein creating a trust list for a first network entity based on a first authentication list and a second authentication list may include: creating a trust list based on the first authentication list such that the trust list specifies a level of trust between the first network entity and 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 further specifies a level of trust between the first network entity and one or more network entities in the second authentication list. Item

[35] : The method according to Item

[34] , which may further include sending the updated first authentication list to one or more network entities authenticated by the first network entity. Item

[36] : The method described in any one of items

[31] to

[35] , wherein the second authentication list may further specify one or more network entities to be authenticated using the third network entity, and the third network entity may be authenticated using the second network entity. Item

[37] : The method described in any one of items

[31] to

[36] , wherein the first authentication list may specify one or more first MAC addresses of one or more ports of a first network entity, one or more third MAC addresses of one or more ports of one or more network entities authenticated using one or more first MAC addresses, and the roles of one or more ports of the first network entity; the second authentication list may specify one or more second MAC addresses of one or more ports of a second network entity, one or more fourth MAC addresses of one or more ports of one or more network entities authenticated using one or more second MAC addresses, and the roles of one or more ports of the second network entity, the roles of which may include one of authenticator and supplicant. Item

[38] : Authentication between a first network entity, a second network entity, and one or more network entities may be based on an 802.1x process, as described in any one of items

[31] to

[37] . Item

[39] : The method described in any one of items

[31] to

[38] , wherein the first network entity, the second network entity, and one or more network entities may 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). Item

[40] : A method which may include: receiving a first authentication list from a first network entity, the first authentication list may specify one or more network entities that are authenticated using the first network entity; receiving a second authentication list from a second network entity, the second authentication list may specify one or more network entities that are authenticated using the second network entity, 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 and second authentication lists, the trust list for the first network entity may specify a level of trust between the first network entity and one or more network entities in the first and second authentication lists. Item

[41] : A network entity that can be configured to create a first authentication list, the first authentication list may specify one or more network entities to be authenticated using the network entity, and to advertise the first authentication list to a second agent deployed in a second network entity, the second network entity may be authenticated using the network entity. Item

[42] : The network entity described in Item

[41] may be configured to advertise a first authentication list by sending the first authentication list to a second agent. Item

[43] : The network entity described in Item

[42] may be configured to update a first authentication list to include one or more authentication lists received from one or more agents deployed in one or more network entities authenticated by the network entity, to further specify one or more network entities newly authenticated by the network entity, and to send the updated first authentication list to one or more agents deployed in one or more network entities authenticated by the network entity. Item

[44] : The network entity described in Item

[43] , which may include a first agent, the first agent may be configured to create a first authentication list, send a first authentication list, update a first authentication list, and send an updated first authentication list. Item

[45] : The network entities described in Item

[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. Item

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

[47] : The hub may be configured to receive a second authentication list from a second agent, and may 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, as described in Item

[46] . Item

[48] : The hub described in Item

[47] may be configured to send a notification to a second agent regarding an updated second authentication list, receive a request from the second agent to send an updated second authentication list, and send an updated second authentication list in response to receiving the request. Item

[49] : The hub described in Item

[47] or

[48] , wherein the first agent may be configured to periodically send a first authentication list, and the hub may be configured to execute commands to periodically send an updated second authentication list to the second agent. Item

[50] : The hub may be communicably coupled to a first agent and a second agent, the first agent and the second agent may mutually authenticate with the hub via a mutual TLS (mTLS) process, as described in any one of items

[46] to

[49] . Item

[51] : A method which may include creating a first authentication list for a first network entity, the first authentication list may specify one or more network entities that are authenticated using the first network entity, and advertising the first authentication list to a second agent deployed in a second network entity, the second network entity being able to be authenticated using the first network entity. Item

[52] : The method described in Item

[51] , wherein advertising the first list of certifiers may include sending the first list of certifiers to a second agent. Item

[53] : The method described in Item

[52] , further comprising: 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 authenticated with the first network entity; updating the first authentication list to further specify one or more network entities newly authenticated with the first network entity; and sending the updated first authentication list to one or more agents deployed in one or more network entities authenticated with the first network entity. Item

[54] : The method described in Item

[53] , wherein the first network entity may include a first agent, the first agent may be configured to create a first authentication list, send a first authentication list, update a first authentication list, and send an updated first authentication list. Item

[55] : The method according to Item

[54] , 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. Item

[56] : A method which may include receiving a first authentication list from a first agent deployed in a first network entity, the first authentication list may specify one or more network entities that are authenticated using the first network entity, and advertising the first authentication list to a second agent deployed in a second network entity, the second network entity may be authenticated using the first network entity. Item

[57] : The method according to Item

[56] , the method which may further include receiving a second authentication list from a second agent, and advertising a first authentication list may include updating the second authentication list to include the first authentication list, and sending the updated second authentication list to the second agent. Item

[58] : The method according to Item

[57] , which may further include sending a notification to a second agent regarding an updated second authentication list, sending a notification to a second agent regarding an updated second authentication list, and sending the updated second authentication list in response to the receipt of a request. Item

[59] : The method according to Item

[57] or

[58] , wherein the first agent may be configured to periodically send a first authentication list, and an updated second authentication list may be periodically sent to the second agent. Item

[60] : The method according to any one of items

[56] to

[59] , wherein receiving and advertising the first authentication list may be performed by a hub communicably coupled to the first and second agents, and the first and second agents may mutually authenticate with the hub via a mutual TLS (mTLS) process.

[0277] In light of the above teachings, it can be seen that numerous modifications and variations of this disclosure are possible. Within the scope of the appended claims, it will be apparent that this disclosure may be carried out in ways other than those specifically described herein.

Claims

1. An open radio access network (O-RAN) radio unit (O-RU) controller, Obtaining the Media Access Control (MAC) address of the O-RU, Based on the MAC address of the O-RU, the authentication status of the O-RU is determined, Based on the determination that the O-RU is authenticated, a channel binding with the O-RU is established, An O-RU controller configured to isolate the O-RU from further communication with the O-RU controller based on the determination that the O-RU is not authenticated.

2. The O-RU controller according to claim 1, wherein the authentication status of the O-RU corresponds to an Extended Authentication Protocol-Transport Layer Security (EAP-TLS) authentication process for the O-RU.

3. The O-RU controller is, Receiving a vendor certificate from the O-RU, wherein the vendor certificate includes the MAC address of the O-RU. Extracting the MAC address of the O-RU from the vendor certificate, The O-RU controller according to claim 1, configured to acquire the MAC address of the O-RU by means of the above.

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

5. The O-RU controller according to claim 4, further configured to send the TLS client certificate to the O-RU after the channel binding with the O-RU has been established.

6. The O-RU controller is, 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 O-RU information from the O-RU, Extracting the MAC address from the O-RU information, The O-RU controller according to claim 1, configured to acquire the MAC address of the O-RU by means of the above.

7. The O-RU controller according to claim 6, wherein the O-RU controller is configured to send the second request for the O-RU information to the O-RU during the Network Configuration Protocol (NETCONF) session establishment phase.

8. The O-RU controller is, Based on the aforementioned O-RU information, one or more NETCONF configuration information entries are generated, The O-RU controller according to claim 7, further configured to transmit one or more NETCONF configuration pieces to the O-RU after the channel binding with the O-RU has been established.

9. The O-RU controller is, To obtain the trusted data store associated with the aforementioned ORU, The MAC address of the O-RU is cross-referenced with a plurality of MAC addresses included in the trust data store to determine whether the MAC address of the O-RU is included in the plurality of MAC addresses, Based on the determination that the MAC address of the O-RU is included in the plurality of MAC addresses, it is determined that the O-RU is authenticated. Based on the determination that the MAC address of the O-RU is not included in the plurality of MAC addresses, it is determined that the O-RU is not authenticated. The O-RU controller according to claim 1, configured to determine the authentication status of the O-RU by means of the O-RU.

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

11. The O-RU controller according to 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 is Obtaining the Media Access Control (MAC) address of the O-RU, Based on the MAC address of the O-RU, the authentication status of the O-RU is determined, Based on the determination that the O-RU is authenticated, a channel binding with the O-RU is established, A method comprising: determining that the O-RU is not authenticated, and then isolating the O-RU from further communication with the O-RU controller.

13. The method according to claim 12, wherein the authentication status of the O-RU corresponds to an Extended Authentication Protocol-Transport Layer Security (EAP-TLS) authentication process for the O-RU.

14. Obtaining the MAC address of the O-RU is Receiving a vendor certificate from the O-RU, wherein the vendor certificate includes the MAC address of the O-RU. The method according to claim 12, comprising extracting the MAC address of the O-RU from the vendor certificate.

15. Receiving the aforementioned vendor certificate means The method according to claim 14, comprising receiving from the O-RU during the transport layer security (TLS) session establishment phase the vendor certificate and a first request for a TLS client certificate.

16. The aforementioned method, The method according to claim 15, further comprising sending the TLS client certificate to the O-RU after the channel binding with the O-RU has been established.

17. Obtaining the MAC address of the O-RU is Sending a second request for O-RU information to the O-RU, wherein the O-RU information includes the serial number and MAC address of the O-RU. The method according to claim 12, comprising receiving O-RU information from the O-RU and extracting the MAC address from the O-RU information.

18. The transmission of the second request for the O-RU information is: The method according to claim 17, comprising sending the second request for the O-RU information to the O-RU during the Network Configuration Protocol (NETCONF) session establishment phase.

19. The aforementioned method, The method according to claim 18, further comprising generating one or more NETCONF configuration information based on the O-RU information, and transmitting the one or more NETCONF configuration information to the O-RU after the channel binding with the O-RU has been established.

20. A non-temporary computer-readable recording medium that records instructions executable by an Open Radio Access Network (O-RAN) Radio Unit (O-RU) controller, wherein the O-RU controller Obtaining the Media Access Control (MAC) address of the O-RU, Based on the MAC address of the O-RU, the authentication status of the O-RU is determined. Based on the determination that the O-RU is authenticated, a channel binding with the O-RU is established, A non-temporary computer-readable recording medium that causes a method to be performed that includes, based on the determination that the O-RU is not authenticated, isolate the O-RU from further communication with the O-RU controller.

Images