A system and method for establishing a topology for notifying supplicants in a network.

Abstract

A system and method are provided for establishing a topology for notifying supplicants in a network. According to an embodiment, the system may include a memory storage that stores computer executable instructions, and at least one processor communicatively coupled to the memory storage, which may be configured to execute instructions to: generate a first authentication list for a first network entity that defines one or more network entities authenticated together with the first network entity; and notify a second agent deployed in a second network entity authenticated together with the first network entity of the first authentication list.

Description

Technical Field

[0001] Embodiments consistent with the present disclosure, systems, methods, and computer programs relate to communication networks, and more specifically, to notifying an authenticated network entity so that a network entity can recognize an authenticated supplicant in a communication network.

Background Art

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

[0003] With the advent of open RAN (O-RAN) technology, multiple vendors can provide hardware and / or software to a communication system. Since different vendors are involved, the types of hardware and / or software provided may also be different. That is, different types of NEs may be provided by different vendors, and depending on the specific service, the NEs can be virtualized in the form of software (e.g., virtual machine (VM)-based) or can take the form of physical hardware (e.g., non-VM-based).

[0004] In open fronthaul networks of communication systems utilizing the O-RAN architecture, network entities may use port-based network access control (IEEE 802.1x) to regulate access to the network and protect against transmission and reception by unspecified or unauthorized parties, and resulting network failures, theft of services, or data loss. Network entities may represent entities such as RAN elements (e.g., O-RAN aggregation units (O-CUs), O-RAN distributed units (O-DUs), O-RAN radio units (O-RUs), etc.) and transport network elements, and may have the role of an authentication unit or supplicant. Under IEEE 802.1x, data traffic is permitted to pass between network entities only if the network entities are authenticated by each other.

[0005] In related technologies, information about authenticated network entities (e.g., which network entities are authenticated and trustworthy) is maintained locally within the corresponding network entity involved in such authentication, and this information is not shared with network entities not involved in such authentication. Furthermore, in related technologies, a network entity may be assumed to be trustworthy if it is connected to an authenticated network entity. [Overview of the Initiative] [Problems that the invention aims to solve]

[0006] Thus, the above approaches in related technologies for authenticating network entities have at least the following drawbacks: Because information about authenticated network entities is held locally and a network entity may be assumed to be trustworthy simply because it is connected to an authenticated network entity, such a process contradicts the zero-trust model of O-RAN architectures and lacks a mechanism for a single network entity in an open fronthaul network to have a comprehensive view of all authenticated network entities in the network.

[0007] Furthermore, there is no clearly defined technology for notifying authenticated network entities in peer-to-peer or hub-and-spoke configurations of information about authenticated network entities in order to enable network entities to recognize authenticated supplicants in the communication network. There is also no clearly defined implementation of centralized services in hub-and-spoke configurations, nor is there any technology for periodically updating network elements to adapt to changes in the network. [Means for solving the problem]

[0008] Embodiments of this disclosure notify authenticated network entities so that network entities can recognize authenticated supplicants in a communication network. To this end, embodiments of this disclosure enable the development of a data store of information about authenticated supplicants for network elements, enabling the construction of a comprehensive view of all authenticated supplicants and the definition of explicit trust levels. Furthermore, in a hub-and-spoke configuration, the hub stores a repository of information for all authenticated supplicants in an open fronthaul network. A network mapping application may be developed on the hub to construct a comprehensive topology overview of all trusted and authenticated supplicant nodes based on data sent by each agent.

[0009] According to the embodiment, a system is provided. The system may include a memory storage that stores computer executable instructions, and at least one processor communicatively coupled to the memory storage, which may be configured to execute instructions in order to generate a first authentication list for a first network entity that defines one or more network entities that are authenticated together with the first network entity, and to notify a second agent deployed in a second network entity that is authenticated together with the first network entity of the first authentication list.

[0010] According to the embodiment, a system is provided. The system may include a memory storage that stores computer executable instructions, and at least one processor communicatively coupled to the memory storage, which may be configured to execute instructions in order to receive a first authentication list from a first agent deployed in a first network entity, which defines one or more network entities that are authenticated together with the first network entity, and to notify a second agent deployed in a second network entity that is authenticated together with the first network entity of the first authentication list.

[0011] According to the embodiment, a method is provided. The method may include generating a first authentication list for a first network entity that defines one or more network entities that are authenticated together with the first network entity, and notifying a second agent deployed in a second network entity that is authenticated together with the first network entity of the first authentication list.

[0012] According to the embodiment, a method is provided. The method may include receiving a first authentication list from a first agent deployed in a first network entity, which defines one or more network entities that are authenticated together with the first network entity, and notifying a second agent deployed in a second network entity that is authenticated together with the first network entity of the first authentication list.

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

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

[0015] Figure 1 illustrates a block diagram of an example of a system configuration for notifying authenticated network entities in a peer-to-peer configuration, according to one or more embodiments.

[0016] Figure 2A illustrates a block diagram of an example of a system configuration for notifying authenticated network entities in a hub-and-spoke configuration, according to one or more embodiments.

[0017] Figure 2B illustrates an example of a hub architecture according to one or more embodiments.

[0018] Figure 3 illustrates a block diagram of an example of components in a network entity notification (NEA) system according to one or more embodiments.

[0019] Figure 4 illustrates a flowchart of an example of a method for notifying authenticated network entities in a peer-to-peer configuration, according to one or more embodiments.

[0020] FIG. 5 illustrates an example of the configuration of network entities in a peer-to-peer configuration according to one or more embodiments.

[0021] FIG. 6 illustrates an example of an authentication list according to one or more embodiments.

[0022] FIG. 7 illustrates a flowchart of an example of a method for notifying an authentication list in a peer-to-peer configuration according to one or more embodiments.

[0023] FIG. 8A illustrates a flowchart of an example of a method for updating an authentication list according to a newly authenticated network entity in a peer-to-peer configuration according to one or more embodiments.

[0024] FIG. 8B illustrates a flowchart of an example of a method for updating an authentication list according to another authentication list received from a network entity in a peer-to-peer configuration according to one or more embodiments.

[0025] FIGS. 9A-9C illustrate an example of a flow sequence for notifying an authenticated network entity in a peer-to-peer configuration according to one or more embodiments.

[0026] FIG. 10 illustrates a flowchart of an example of a method for notifying an authenticated network entity in a hub-and-spoke configuration according to one or more embodiments.

[0027] FIG. 11 illustrates an example of the configuration of network entities in a hub-and-spoke configuration according to one or more embodiments.

[0028] FIG. 12 illustrates a flowchart of an example of a method for notifying an authentication list according to a push-and-pull model in a hub-and-spoke configuration according to one or more embodiments.

[0029] Figure 13 illustrates a flowchart of an example of a method for notifying an authentication list according to a subscription notification model in a hub-and-spoke configuration, according to one or more embodiments.

[0030] Figures 14A to 14C illustrate an example of a flow sequence for notifying a network entity authenticated according to a push-and-pull model in a hub-and-spoke configuration, according to one or more embodiments.

[0031] Figure 15 illustrates an example of an environment in which the system and / or methods described herein may be implemented. [Modes for carrying out the invention]

[0032] The following detailed descriptions of embodiments refer to the accompanying drawings. The same reference numerals in different drawings may identify the same or similar elements.

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

[0034] It will become clear that the systems and / or methods described herein may be implemented in different forms of hardware, firmware, or combinations of hardware and software. The specific control hardware or software code used to implement these systems and / or methods is not limiting to the implementation. For this reason, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It is understood that software and hardware may be designed to implement the systems and / or methods based on the descriptions herein.

[0035] Even if specific combinations of features are disclosed in the specification, these combinations are not intended to limit the possible implementations disclosed herein. In fact, many of these features may be combined in ways not specifically disclosed in the specification.

[0036] None of the elements, actions, or commands used herein should be interpreted as important or essential unless explicitly stated otherwise. Also, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more." When only one item is intended, the term "one" or similar is used. Also, as used herein, the terms "has," "have," "having," "include," "including," etc., are intended to be open-ended terms. Furthermore, the phrase "based on" means "at least partially based on" unless explicitly stated otherwise. Furthermore, expressions such as "at least one of A and B" or "at least one of A or B" are understood to include only A, only B, or both A and B.

[0037] The systems, methods, devices, etc., provided in embodiments of this disclosure notify a network entity of an authenticated network entity so that the network entity can recognize an authenticated supplicant in a communication network.

[0038] According to one embodiment, the system may generate or receive a first authentication list that defines one or more network entities authenticated together with a first network entity, and notify a second agent deployed in a second network entity authenticated together with the first network entity of such first authentication list.

[0039] Ultimately, embodiments of this disclosure enable network entities to recognize authenticated supplicants in the network, enable the development of a data store of information about authenticated supplicants for network elements, enable the construction of a comprehensive view of all authenticated supplicants, and enable the definition of explicit levels of trust. Furthermore, in a hub-and-spoke configuration, the hub stores a repository of information for all authenticated supplicants in an open fronthaul network. A network mapping application may be developed on the hub to construct a comprehensive topology overview of all trusted and authenticated supplicant nodes based on the data sent by each agent.

[0040] The features, advantages, and importance of the embodiments described herein are only a part of this disclosure and are not intended to be exhaustive or to limit the scope of this disclosure.

[0041] Further description of the features, components, configuration, operation, and implementation of the threshold adjustment system of this disclosure, according to one or more embodiments, is provided below.

[0042] [Example of a system architecture] Figure 1 illustrates a block diagram of an example of a system configuration 100 for notifying authenticated network entities in a peer-to-peer configuration, according to one or more embodiments. As illustrated in Figure 1, the system configuration 100 may include multiple network entities (e.g., network entity A110, network entity B120, network entity C130) that are connected to each other in a communicateable manner in a peer-to-peer configuration.

[0043] Each of the multiple network entities 110, 120, and 130 may include a system, platform, module, etc., configured to perform one or more operations or actions to notify an authenticated network entity in the network. According to the embodiment, the multiple network entities 110, 120, and 130 may include entities such as RAN elements (e.g., O-RAN aggregation units (O-CUs), O-RAN distribution units (O-DUs), O-RAN radio units (O-RUs), etc.) and transport network elements.

[0044] According to the embodiment, each of the multiple network entities 110, 120, and 130 may deploy an agent. Each agent may include software or an entity having a predetermined set of instructions. Each agent may be autonomous, operate independently, or work in cooperation with other agents deployed in other network entities. Each agent may 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 agent may be capable of supporting GET / POST / PUT / DELETE HTTP methods to communicate and exchange information with each other.

[0045] In one embodiment, each agent may be configured to communicate directly with one another in a peer-to-peer configuration. Here, each agent may be configured to establish mutual authentication with one another. In particular, an agent may be configured to establish its identity with other agents 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 enhances the security of communication between multiple network entities and enables the agents to communicate over a secure connection. In another embodiment, mutual authentication between agents may be established after each network entity has authenticated one another.

[0046] According to one embodiment, each agent may be configured to perform functions related to the authentication list (described later with reference to Figures 4 and 14), such as generating, updating, and notifying the hub of the authentication list.

[0047] Figure 2A illustrates a block diagram of an example of a system configuration 200 for notifying authenticated network entities in a hub-and-spoke configuration according to one or more embodiments. As illustrated in Figure 2A, the system configuration 200 may include a plurality of network entities (e.g., network entity A210, network entity B220, network entity C230) that are communicatively coupled to one another, and a hub 240 that is communicatively coupled to each of the plurality of network entities 210, 220, and 230 in a hub-and-spoke configuration.

[0048] Hub 240 may include a system, platform, module, etc., which may be configured to perform one or more operations or actions to notify the network of authenticated network entities.

[0049] Figure 2B illustrates an example of the architecture of Hub 240 according to one or more embodiments. As shown in Figure 2B, Hub 240 may include components such as: a subscription management function 241 with integration functions configured to perform operations according to a push-and-pull model and a subscription notification model; a data store 242 configured to handle a database of authenticated supplicants in an open fronthaul network; a notification function 243 configured to inform subscribers of updates in real-time network traffic; an event tracker 244 configured to monitor new subscriptions and requests made by Hub 240 or agents 250A-250C; a network (application) topology mapper 245 configured to provide a comprehensive map of all authenticated supplicants in the network; and a web interface 246 configured to access and view the comprehensive map of all authenticated supplicants in the network.

[0050] According to one embodiment, the hub 240 may include a centralized service that functions as a central point for communication between multiple network entities 210, 220, and 230. According to another embodiment, the hub 240 may be hosted on any element in an open fronthaul network, such as a service management orchestrator (SMO) or an IEEE 802.1x authentication server, which has communication paths to the multiple network entities 210, 220, and 230.

[0051] According to the embodiment, the multiple network entities 210, 220, 230 may include entities such as RAN elements (e.g., O-RAN aggregation units (O-CUs), O-RAN distribution units (O-DUs), O-RAN wireless units (O-RUs), etc.) and transport network elements.

[0052] According to the embodiment, each of the multiple network entities 210, 220, and 230 may deploy an agent. Each of the agents 250A to 250C may include software or an entity having a predetermined set of instructions. Each of the agents 250A to 250C may be autonomous, operate independently, or operate in cooperation with other agents deployed in other network entities. Each of the agents 250A to 250C may 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 the agents 250A to 250C may support GET / POST / PUT / DELETE HTTP methods to communicate and exchange information with each other.

[0053] According to one embodiment, each of agents 250A to 250C may be configured to communicate indirectly with one another via a hub in a hub-and-spoke configuration. Here, hub 240 may function as a central point for communication between agents 250A to 250C. According to another embodiment, hub 240 and agents 250A to 250C may exchange data according to a push-and-pull model and a subscription notification model (e.g., requests for and provision of services and resources).

[0054] In one embodiment, each of agents 250A to 250C may be configured to establish mutual authentication with the hub. In particular, the agents may be configured to utilize mutual TLS (mTLS) to establish a secure connection with the hub, and the above model may be ensured in an mTLS environment through encryption. Such mutual authentication between the agents and the hub 240 enhances the security of communication between multiple network entities and the hub 240, and enables the agents to communicate indirectly through a secure connection. In particular, once a connection is established between agents 250A to 250C and the hub 240, all data transmitted between agents 250A to 250C and the hub 240 is encrypted using TLS, providing data confidentiality and integrity. Therefore, even if an attacker intercepts the transmitted data, it is impossible to read or tamper with it.

[0055] According to one embodiment, each of agents 250A to 250C may be configured to perform functions related to the authentication list (described later with reference to Figures 4 and 14), such as generating the authentication list, updating it, and notifying the hub 240.

[0056] According to one embodiment, each of the multiple network entities 110, 120, 130, 210, 220, and 230 may be configured to perform the above-described functions related to the authentication list without agents 250A to 250C. In particular, each of the multiple network entities 110, 120, 130, 210, 220, and 230 may utilize LAN Extensible Authentication Protocol (EAP) (EAPoL) notification to inform authenticated (i.e., authenticated under IEEE 802.1x) network entities about the authentication list. However, such a process would involve implementing changes to the IEEE 802.1x specification, such as the IEEE 802.1x EAP notification method. On the other hand, deploying agents to perform the above-described functions related to the authentication list allows each of the multiple network entities 110, 120, 130, 210, 220, and 230 to notify authenticated network entities without changing the IEEE 802.1x specification.

[0057] The configurations illustrated in Figures 1, 2A, and 2B are simplified for illustrative purposes and should not be understood as being intended to limit the scope of this disclosure in any way. For example, the number of network entities in the system can actually be any number.

[0058] Examples of operations that can be performed by multiple network entities 110, 120, and 130 to notify authenticated network entities are described later with reference to Figure 4, and examples of operations that can be performed by hub 240 to notify authenticated network entities are described later with reference to Figure 10. Furthermore, some examples of components that may be included in multiple network entities 110, 120, 130 and hub 240 in one or more embodiments are described later with reference to Figure 3.

[0059] Figure 3 illustrates a block diagram of an example of components in a Network Entity Notification (NEA) system 300 according to one or more embodiments. The NEA system 300 may correspond to at least one of the multiple network entities 110, 120, and 130 in Figure 1, or to the hub 240 in Figure 2A, and the features relating to the multiple network entities 110, 120, and 130, the hub 240, and the NEA system 300 may be equally applicable to each other unless expressly stated otherwise.

[0060] As illustrated in Figure 3, the NEA system 300 may include at least one communication interface 310, at least one processor 320, at least one input / output component 330, and at least one storage 340, but it can be understood that the NEA system 300 may include more or fewer components than those illustrated in Figure 3, and / or may be configured in a manner different from that illustrated in Figure 3, without departing from the scope of this disclosure.

[0061] The communication interface 310 may include at least one transceiver-like component (e.g., transceivers, other receivers and transmitters, buses, etc.) that enables the components of the NEA system 300 to communicate with each other and / or with one or more components outside the NEA system 300 via wired connections, wireless connections, or a combination of wired and wireless connections.

[0062] For example, the communication interface 310 may connect the processor 320 to the storage 340, enabling them to communicate and interact with each other when performing one or more operations. In another example, the communication interface 310 may connect the NEA system 300 (or one or more components contained therein) to another network entity, enabling them to communicate and interact with each other.

[0063] According to one or more embodiments, the communication interface 310 may include one or more application programming interfaces (APIs) that enable the NEA system 300 (or one or more components contained therein) to communicate with one or more software applications.

[0064] The input / output component 330 may include at least one component that allows the NEA system 300 to receive information and / or provide output information. In some embodiments, the input / output component 330 may be understood to 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 separate from the others.

[0065] The storage 340 may include one or more storage media suitable for storing data, information, and / or computer executable instructions. According to embodiments, the storage 340 may include at least one memory storage such as random access memory (RAM), read-only memory (ROM), and / or other types of dynamic or static storage devices (e.g., flash memory, magnetic memory, and / or optical memory) for storing information and / or instructions for use by the processor 320. In addition or alternatively, the storage 340 may include hard disks (e.g., magnetic disks, optical disks, magneto-optical disks, and / or solid-state disks), compact discs (CDs), digital multipurpose discs (DVDs), floppy disks, cartridges, magnetic tapes, and / or other types of non-temporary computer-readable media, accompanied by corresponding drives.

[0066] In some embodiments, the storage 340 may be configured to store information such as raw data and metadata. In addition or alternatively, the storage 340 may be configured to store one or more pieces of information related to one or more operations performed by the processor 320. For example, the storage 340 may store information that defines past operations performed by the processor 320 to notify an authenticated network entity, the results of one or more operations performed by the processor 320, and so on. Furthermore, the storage 340 may store data or information necessary when notifying an authenticated network entity. For example, the storage 340 may store an authentication list and / or a trust list (described later with reference to Figures 6, 9, and 14).

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

[0068] The processor 320 may include at least one processor that can be programmed or configured to perform the functions or operations described herein. For example, the processor 320 may be configured to execute computer executable instructions stored in at least one storage medium or memory storage (e.g., storage 340, etc.) to perform one or more actions or one or more operations described herein.

[0069] According to the embodiment, the processor 320 may be configured to receive one or more signals and / or one or more user inputs that define one or more instructions for performing one or more operations (e.g., via the communication interface 310, via the input / output component 330, etc.). Furthermore, the processor 320 may be implemented in hardware, firmware, or a combination of hardware and software. For example, the processor 320 may include at least one of a central processing unit (CPU), graphics processing unit (GPU), acceleration 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 arithmetic components.

[0070] According to one embodiment, the processor 320 may be configured to collect, extract, and / or receive one or more pieces of information (in the form of signals or data, etc.), and may be configured to process the received pieces of information to notify an authenticated network entity.

[0071] A description of some examples of operations that may be performed by processor 320 is provided below with reference to Figures 4 to 14.

[0072] [Examples of operations for notifying authenticated network entities in the peer-to-peer configuration described in this disclosure] Some examples of operations that can be performed by the NEA system of this disclosure are described below with reference to Figures 4 to 8.

[0073] Figure 4 illustrates a flowchart of an example of a method 400 for notifying authenticated network entities in a peer-to-peer configuration, according to one or more embodiments. One or more operations in method 400 may be performed by at least one processor (e.g., processor 320) of the NEA system, which may correspond to at least one network entity (i.e., the first network entity) of a plurality of network entities in the system.

[0074] As illustrated in Figure 4, in operation S410, at least one processor may be configured to generate a first authentication list for the first network entity. According to one embodiment, the first authentication list may specify one or more network entities that are authenticated together with the first network entity. In particular, according to one embodiment, the first authentication list may specify one or more MAC addresses of one or more ports of the first network entity (hereinafter referred to as "one or more first MAC addresses") and one or more MAC addresses of one or more ports of one or more network entities that are authenticated together with the one or more first MAC addresses. According to one embodiment, the first authentication list may specify the roles of one or more ports of the first network entity (e.g., authentication unit and supplicant).

[0075] For example, see Figure 5, which illustrates an example of the configuration of network entities in a peer-to-peer configuration according to one or more embodiments. As shown in Figure 5, the system may comprise seven network entities (network entity Y500Y, network entity A500A, network entity M500M, network entity X500X, network entity Z500Z, network entity O500O, network entity N500N).

[0076] As shown in Figure 5, for example, network entity A500A is authenticated together with network entities Y500Y and M500M. Here, port AuP4 of network entity A500A has MAC address M4 and acts as the authentication unit, and is authenticated together with port SuP11 of network entity Y500Y, which has MAC address M11 and acts as the supplicant. Similarly, port SuP5 of network entity A500A has MAC address M5 and acts as the supplicant, and is authenticated together with port AuP3 of network entity M500M, which has MAC address M3 and acts as the authentication unit. A similar explanation applies to network entities Y500Y, M500M, X500X, Z500Z, O500O, and N500N.

[0077] Authentication between network entities may be understood to be performed based on port-based network access control IEEE 802.1x with an IEEE 802.1x authentication server. In particular, as part of the LAN Extensible Authentication Protocol (EAP) (EAPoL) process, a network entity acting as the authentication unit requests identity information from a network entity acting as the supplicant and relays said identity information to the authentication server. Subsequently, the authentication server verifies the identity information of the network entity acting as the supplicant and determines whether the network entity is authorized to access the network. If the network entity acting as the supplicant is authorized to access the network, the network entity acting as the supplicant is authenticated together with the network entity acting as the authentication unit. Through the above authentication process, the network entities involved in the authentication process can obtain information such as port identity, port MAC address, port role, and authorization status from each other.

[0078] Figure 6 illustrates examples of authentication lists 600A, 600M, 600N, and 600O according to one or more embodiments. As shown in Figure 6, for example, network entity A may be configured to generate its authentication list 600A. Here, such authentication list 600A may specify MAC addresses M4 and M5 of ports AuP4 and SuP5 of network entity A, MAC address M11 of port SuP11 of network entity Y authenticated together with port AuP4, and MAC address M3 of port AuP3 of network entity M authenticated together with port SuP5. Furthermore, the authentication list 600A for network entity A may specify that port AuP4 of network entity A acts as the authentication unit and port SuP5 of network entity A acts as the supplicant. Thus, the authentication list may specify network entities Y and network entities M (having ports SuP11 and AuP3) that are authenticated together with network entity A (having ports AuP4 and SuP5). The same explanation applies to network entities Y, M, X, Z, O, and N. Since network entities Y, X, and Z have only one port, their authentication lists are omitted from Figure 6. Next, the procedure proceeds to operation S420.

[0079] According to one embodiment, at least one processor may be configured to execute an SNMPv3 query for OID "1.3.111.2.802.1.1.15.2.2.3" at regular intervals. Subsequently, based on the SNMPv3 response (indicating the status of object type "ieee8021XpaeLogonGroup"), at least one processor may generate an authentication list.

[0080] If a network entity is not authenticated with the first network entity (for example, if authentication for such a network entity fails), the first network entity may block traffic to and from such network entity and may not be required to generate or update the first authentication list to include such network entity.

[0081] In operation S420, at least one processor may be configured to notify a second agent deployed in the second network entity of the first authentication list. According to the embodiment, the first network entity and the second network entity may authenticate each other.

[0082] For example, returning to Figures 5 and 6, network entity A500A may be configured to notify agent 500M (which is authenticated along with network entity A500A) deployed in network entity M of the authentication list 600A for network entity A500A shown in Figure 6.

[0083] According to one embodiment, the generation of the first authentication list may be performed by a first agent deployed in a first network entity, and the notification of the first authentication list may be performed by the first agent via a notification interface. According to another embodiment, the first agent may authenticate each other together with a second agent. According to another embodiment, the notification interface may include an interface such as a REST API.

[0084] An example of an operation for notifying an authentication list in a peer-to-peer configuration will be described later with reference to Figure 7.

[0085] Method 400 may terminate after performing operation S420. Alternatively, Method 400 may return to operation S420, such that at least one processor is configured to repeatedly perform the notification of the first authentication list (operation S420) for at least a predetermined amount of time. For example, at least one processor may update the first authentication list in response to changes in the network and resume notifying the first authentication list (operation S420).

[0086] Examples of operations for updating the authentication list in a peer-to-peer configuration are described later with reference to Figures 8A and 8B.

[0087] For this purpose, the system of this disclosure may notify authenticated network entities on the network.

[0088] [Example of an operation for notifying the authentication list in a peer-to-peer configuration as described in this disclosure] Below, several examples of operations for notifying the authentication list, which can be performed by at least one processor, are described with reference to Figure 7.

[0089] Figure 7 illustrates a flowchart of an example of a method 700 for notifying an authentication list in a peer-to-peer configuration according to one or more embodiments. One or more operations of method 700 may be part of operations S410 and S420 in method 400 and may be performed by at least one processor (e.g., processor 320) of the NEA system, which may correspond to at least one network entity (i.e., the first network entity) of a plurality of network entities in the system.

[0090] As illustrated in Figure 7, in operation S710, at least one processor may be configured to generate a first authentication list for the first network entity in a manner similar to that described above with respect to operation S410. The method may then proceed to operation S720.

[0091] In operation S720, at least one processor may be configured to send a first authentication list to a second agent deployed in the second network entity. According to the embodiment, the first network entity and the second network entity may authenticate each other.

[0092] For example, returning to Figures 5 and 6, network entity A may be configured to send an authentication list for network entity A, as shown in Figure 6, to agents deployed in network entity M (which are authenticated along with network entity A).

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

[0094] According to one embodiment, the generation of the first authentication list may be performed by a first agent deployed in a first network entity, and the transmission of the first authentication list may be performed by the first agent via a notification interface. According to another embodiment, the first agent may authenticate each other together with a second agent. According to another embodiment, the notification interface may include an interface such as a REST API.

[0095] Method 700 may terminate after performing operation S720. Alternatively, method 700 may return to operation S720, such that at least one processor repeatedly performs sending the first authentication list (operation S720) for at least a predetermined amount of time. For example, at least one processor may update the first authentication list in response to changes in the network and resume sending the first authentication list (operation S720).

[0096] Examples of operations for updating the authentication list in a peer-to-peer configuration are described later with reference to Figures 8A and 8B.

[0097] For this purpose, the system of this disclosure may notify the authentication list on the network.

[0098] [Example of an operation to update the authentication list in the peer-to-peer configuration described in this disclosure] Below, several examples of operations for updating the authentication list, which can be performed by at least one processor, are described with reference to Figures 8A and 8B.

[0099] Figure 8A illustrates a flowchart of an example of a method 800 for updating an authentication list in response to a newly authenticated network entity in a peer-to-peer configuration, according to one or more embodiments. One or more operations in method 800 may be performed after the first authentication list has been generated, and may be performed by at least one processor (e.g., processor 320) of the NEA system, which may correspond to at least one network entity of a plurality of network entities in the system (i.e., the first network entity).

[0100] As illustrated in Figure 8A, in operation S810, at least one processor may be configured to newly authenticate one or more network entities together with the first network entity. According to the embodiment, the one or more network entities to be newly authenticated may include, but are not shown in, one or more network entities authenticated together with the first network entity after the first authentication list has been generated.

[0101] For example, returning to Figures 5 and 6, after network entity A generates an authentication list indicating network entity Y (by specifying network entity Y's port SuP11(M11) in the authentication list), network entity A is newly authenticated together with network entity M (which is not yet indicated in the authentication list). The method may then proceed to operation S820.

[0102] In operation S820, at least one processor may be configured to update the first authentication list to further specify one or more newly authenticated network entities. For example, returning to Figures 5 and 6, after network entity A has been newly authenticated along with network entity M, network entity A may be configured to further specify network entity M, as shown in the authentication list for network entity A in Figure 6 (for example, by adding a new line to the authentication list to specify port AuP3(M3) of network entity M along with the corresponding port SuP5(M5) of network entity A). The method may then proceed to operation S830.

[0103] In operation S830, at least one processor may be configured to send an updated first authentication list to one or more agents deployed in one or more network entities that are authenticated together with the first network entity. For example, returning to Figures 5 and 6, network entity A may be configured to send its updated authentication list (i.e., the authentication list for network entity A shown in Figure 6) to agents deployed in network entity Y and agents deployed in network entity M.

[0104] Method 800 may terminate after executing Operation S830. Alternatively, Method 800 may return to Operation S810, so that at least one processor may be configured to repeatedly authenticate one or more network entities (Operation S810), update the first authentication list (Operation S820), and send the updated first authentication list (Operation S830) for at least a predetermined amount of time. For example, at least one processor may continue to find more network entities to authenticate with the first network entity and resume authenticating one or more network entities (Operation S810), updating the first authentication list (Operation S820), and sending the updated first authentication list (Operation S830).

[0105] Figure 8B illustrates a flowchart of an example of method 805 for updating an authentication list in response to other authentication lists received from network entities in a peer-to-peer configuration, according to one or more embodiments. One or more operations in method 805 may be performed after the first authentication list has been generated and may be performed by at least one processor (e.g., processor 320) of the NEA system, which may correspond to at least one network entity of a plurality of network entities in the system (i.e., the first network entity).

[0106] As illustrated in Figure 8B, in operation S815, at least one processor may be configured to receive one or more authentication lists from one or more agents deployed in one or more network entities authenticated together with the first network entity. According to one embodiment, at least one processor may be configured to receive a second authentication list from a second agent deployed in a second network entity authenticated together with the first network entity. According to another embodiment, the second authentication list may define one or more network entities authenticated together with the second network entity in a manner similar to that of the first authentication list.

[0107] For example, returning to Figures 5 and 6, network entity A may be configured to receive an authentication list for network entity M (i.e., the authentication list for network entity M shown in Figure 6) from an agent deployed in network entity M. The method may then proceed to operation S825.

[0108] It may be understood that one or more authentication lists may be generated by each of the one or more agents in a manner similar to that described above for the first agent.

[0109] In operation S825, at least one processor may be configured to update the first authentication list to include one or more authentication lists. For example, returning to Figures 5 and 6, network entity A may be configured to update its authentication list to include the rows for ports AuP1, AuP3, and SuP2 in the authentication list for network entity M. The method may then proceed to operation S835.

[0110] In operation S835, at least one processor may be configured to send an updated first authentication list to one or more agents deployed in one or more network entities that are authenticated together with the first network entity. For example, returning to Figures 5 and 6, network entity A may be configured to send its updated authentication list (i.e., the authentication list for network entity A shown in Figure 6, further including rows for ports AuP1, AuP3, and SuP2 in the authentication list for network entity M) to agents deployed in network entity Y and agents deployed in network entity M.

[0111] Method 805 may terminate after executing operation S835. Alternatively, method 805 may return to operation S815, so that at least one processor is configured to repeatedly perform receiving one or more authentication lists (operation S815), updating the first authentication list (operation S825), and transmitting the updated first authentication list (operation S835) for at least a predetermined amount of time. For example, at least one processor may continue receiving more authentication lists and resume receiving one or more authentication lists (operation S815), updating the first authentication list (operation S825), and transmitting the updated first authentication list (operation S835).

[0112] According to the embodiment, at least one processor may be configured to send notifications to one or more agents indicating changes in the network. For example, at least one processor may be configured to send notifications such as when a first network entity is newly authenticated with a network entity, or when the first authentication list is updated. According to the embodiment, at least one processor 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 processor may be configured to receive notifications from one or more agents and send requests from one or more agents to receive the updated authentication list.

[0113] In one embodiment, receiving one or more authentication lists, updating the first authentication list, and sending the updated first authentication list may be performed by a first agent deployed in the first network entity. In another embodiment, sending the updated first authentication list, and sending and receiving notifications and requests may be performed via a notification interface. In another embodiment, the notification interface may include an interface such as a REST API. In yet another embodiment, the first agent may be mutually authenticated with one or more agents deployed in one or more network entities that are authenticated together with the first network entity.

[0114] The above process allows agents to be easily notified of any changes to the network and ensures that agents always have the latest version of their authentication list.

[0115] [Example of a sequence for notifying authenticated network entities in a peer-to-peer configuration as described in this disclosure] Figures 9A-9C illustrate an example of a flow sequence for notifying an authenticated network entity in a peer-to-peer configuration according to one or more embodiments. The example flow sequence shown in Figures 9A-9C involves the processes previously described with respect to methods 400, 700, 800, and 805, and is divided into three parts for clarity.

[0116] As shown in Figures 9A-9C, the network includes four network entities that deploy four agents (Agent 1, Agent 2, Agent 3, and Agent 4), and an authentication server.

[0117] During steps 1-3, network entity 1 performs authentication with network entity 2 in accordance with 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 is unsuccessful, network entity 2 may issue a security alert and block data traffic to and from network entity 1.

[0118] Between steps 4 and 5, network entity 2 generates its authentication list and notifies network entity 1 of that authentication list over the secure connection.

[0119] During step 6, network entity 2 forms a direct trust with network entity 1. For example, when network entity 1 receives the authentication list of network entity 2, network entity 1 may be configured to generate a trust list that defines the trust level between network entity 2 and network entity 1 as direct trust, based on the authentication list of network entity 2 that defines network entity 1.

[0120] Between steps 7 and 12, network entity 3 performs authentication with network entity 2 in the same manner as described for network entities 1 and 2 in steps 1 to 6, generates an authentication list, notifies network entity 2 of the authentication list, and establishes a direct trust with network entity 2.

[0121] During step 13, network entity 2 notifies network entity 3 of its authentication list. In particular, since network entity 2 has been newly authenticated together with 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 notify network entity 3 of the updated authentication list. Similarly, network entity 3 may update its authentication list to include the authentication list received from network entity 2.

[0122] Between steps 14 and 16, network entity 3 performs authentication with network entity 4 in the same manner as described for network entities 1 and 2 in steps 1 to 3.

[0123] During step 17, network entity 3 updates its authentication list to further define the newly authenticated network entity 4.

[0124] Between steps 18 and 19, network entity 3 notifies network entities 2 and 4 of its updated authentication list.

[0125] During step 20, network entity 4 forms an indirect trust with network entity 1. For example, since network entity 1 is specified in the authentication list of network entity 2 that has been notified to network entity 3 (step 13), and network entity 3 has updated its authentication list to include network entity 2's authentication list and notified network entity 4 of this update (step 19), network entity 4 may update its authentication list to include network entity 3's authentication list, and network entity 4's authentication list may specify network entity 1. Thus, network entity 4 may be configured to generate a trust list that specifies the trust level between network entity 4 and network entity 1 as an indirect trust, based on network entity 4's authentication list that specifies network entity 1.

[0126] During step 21, network entity 4 forms a direct trust with network entity 3 in a manner similar to that described for network entities 1 and 2 in step 6.

[0127] [Examples of operations for notifying authenticated network entities in the hub-and-spoke configuration described in this disclosure] Some examples of operations that can be performed by the NEA system of this disclosure are described below with reference to Figures 10 to 14.

[0128] Figure 10 illustrates a flowchart of an example of method 1000 for notifying authenticated network entities in a hub-and-spoke configuration, according to one or more embodiments. One or more operations of method 1000 may be performed by at least one processor (e.g., processor 320) of the NEA system, which may correspond to a hub that is communicably coupled to multiple network entities in the system.

[0129] As illustrated in Figure 10, in operation S1010, at least one processor may be configured to receive a first authentication list from a first agent deployed in the first network entity. The first authentication list may be the same as the first authentication list in the peer-to-peer configuration described above, and may be generated by the first agent.

[0130] For example, see Figure 11, which illustrates an example of the configuration of network entities in a hub-and-spoke configuration according to one or more embodiments. The example of the configuration of network entities in a hub-and-spoke configuration shown in Figure 11 is similar to the example of the configuration of network entities in a peer-to-peer configuration shown in Figure 5, with the addition of hubs 1140 that are communicatively coupled to each of the network entities Y1100Y, A1100A, M1100M, X1100X, Z1100Z, O1100O, and N1100N.

[0131] As shown in Figure 11, for example, hub 1140 may be configured to receive an authentication list for network entity A1100A (for example, the authentication list 600A for network entity A shown in Figure 6) from an agent deployed in network entity A1100A. The method then proceeds to operation S1020.

[0132] In operation S1020, at least one processor may be configured to notify a second agent deployed in the second network entity of the first authentication list. According to one embodiment, at least one processor may be configured to notify a second agent of the first authentication list according to a subscription model including a push-and-pull model and a subscription notification model. According to one embodiment, the first network entity and the second network entity may authenticate each other.

[0133] For example, returning to Figures 11 and 6, the hub 1140 may be configured to notify agents deployed in network entity M1100M (which is authenticated together with network entity A1100A) of the authentication list 600A for network entity A shown in Figure 6.

[0134] According to one embodiment, notification of the first authentication list may be made via a notification interface. According to another embodiment, the first agent and the second agent may authenticate each other together with the hub. According to another embodiment, the notification interface may include an interface such as a REST API.

[0135] An example of an operation for notifying an authentication list according to the push-and-pull model in a hub-and-spoke configuration is described later with reference to Figure 12, and an example of an operation for notifying an authentication list according to the subscription notification model in a hub-and-spoke configuration is described later with reference to Figure 13.

[0136] Method 1000 may terminate after executing operation S1020. Alternatively, method 1000 may return to operation S1020, such that at least one processor is configured to repeatedly perform the notification of the first authentication list (operation S1020) for at least a predetermined amount of time. For example, at least one processor may update the first authentication list in response to changes in the network and resume notifying the first authentication list (operation S1020).

[0137] For this purpose, the system of this disclosure may notify authenticated network entities on the network.

[0138] [Example of an operation for notifying the authentication list according to the push-and-pull model in the hub-and-spoke configuration described in this disclosure] Below, several examples of operations for notifying the authentication list, which can be performed by at least one processor, are described with reference to Figure 12.

[0139] Figure 12 illustrates a flowchart of an example of Method 1200 for notifying 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 1200 may be part of operations S1010 and S1020 in Method 1000, and may be performed by at least one processor (e.g., processor 320) of the NEA system, which may correspond to a hub that is communicably coupled to multiple network entities in the system.

[0140] As illustrated in Figure 12, in operation S1210, at least one processor 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, at least one processor may be configured to register the first agent and the second agent under a push-and-pull model.

[0141] For example, the first and second agents may be configured to register with an API function for a push-and-pull model during bootstrapping. Here, the account and API key are verified by the API function and used for all API requests. Subsequently, the first and second agents may 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 by the function. The method then proceeds to operation S1220.

[0142] In operation S1220, at least one processor may be configured to receive the first authentication list from the first agent in a manner similar to that described above for operation S1010. The method may then proceed to operation S1230.

[0143] In operation S1230, at least one processor may be configured to receive a second authentication list from the second agent. According to the embodiment, the first network entity and the second network entity may authenticate each other. The second authentication list may be understood to be generated by the second agent in a manner similar to that described above for the first agent in a peer-to-peer configuration.

[0144] For example, returning to Figure 11, the hub 1140 may be configured to receive an authentication list for network entity M1100M (for example, the authentication list 600M for network entity M1100M shown in Figure 6) from an agent deployed in network entity M. The method then proceeds to operation S1240.

[0145] In operation S1240, at least one processor may be configured to update the second authentication list to include the first authentication list. For example, hub 1140 may be configured to update the authentication list of network entity M1100M to include the authentication list of network entity A1100A in a manner similar to that described above in operation S825 of method 805. The method then proceeds to operation S1250.

[0146] In operation S1250, at least one processor may be configured to send a notification to the 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 in the network, that a first authentication list has been received, or that a second authentication list has been updated.

[0147] In one embodiment, the hub's event tracker may be configured to monitor data stored in the hub, track data sent to and from agents, and detect changes in the stored data (for example, detecting that the first authentication list has been received from the first agent, that an updated first authentication list has been received from the first agent, that the second authentication list has been updated, etc.). The event tracker may then notify the hub's data store of the changes and may utilize the hub's notification mechanism to send notifications to agents. The method then proceeds to operation S1260.

[0148] In operation S1260, at least one processor may be configured to receive a request from the second agent to send an updated second authentication list. According to one embodiment, the second agent may be configured to send the request in response to receiving the notification and / or periodically. The method then proceeds to operation S1270.

[0149] In operation S1270, at least one processor may be configured to send an updated second authentication list to the second agent in response to receiving a request. For example, referring to Figure 11, the hub 1140 may be configured to send an updated authentication list for network entity M1100M (including the authentication list for network entity A1100A) to an agent deployed in network entity M1100M in a manner similar to that described above in operation S835 in method 805.

[0150] According to one embodiment, at least one processor may be configured to store received and updated authentication lists so that the hub can function as a repository of information for all authenticated supplicants in an open fronthaul network. In particular, the hub's network topology mapper may use the stored authentication lists to form an integrated data store for authenticated supplicants and generate a topology map of all authenticated supplicants in an open fronthaul network. Thus, the hub may be configured to develop a live network mapping application that can construct a comprehensive topology overview of all authenticated supplicants based on the stored authentication lists.

[0151] In one embodiment, the updated second authentication list may be sent via a notification interface. In another embodiment, the first agent and the second agent may authenticate each other together with the hub. In another embodiment, the notification interface may include an interface such as a REST API.

[0152] Method 1200 may terminate after executing operation S1270. Alternatively, method 1200 may return to operation S1220, so that at least one processor is configured to repeatedly perform the following actions for at least a predetermined amount of time: receiving a first authentication list (operation S1220), receiving a second authentication list (operation S1230), updating the second authentication list (operation S1240), sending a notification (operation S1250), receiving a request (operation S1260), and sending the updated second authentication list (operation S1270).

[0153] For example, the first network entity may authenticate with the network entity anew (change in the network). Here, the first authentication list is updated and sent to the hub in the same manner as described above with respect to method 800. Thus, at least one processor may receive the updated first authentication list and resume receiving the first authentication list (operation S1220), receiving the second authentication list (operation S1230), updating the second authentication list (operation S1240), sending notifications (operation S1250), receiving requests (operation S1260), and sending the updated second authentication list (operation S1270).

[0154] The above process allows the hub and agents to be easily notified of any changes to the network, and ensures that agents always have the latest version of the authentication list.

[0155] For this purpose, the system of this disclosure may notify the authentication list on the network.

[0156] [Example of an operation for notifying the authentication list according to the subscription notification model in the hub-and-spoke configuration described in this disclosure] Below, several examples of operations for notifying the authentication list, which can be performed by at least one processor, are described with reference to Figure 13.

[0157] Figure 13 illustrates a flowchart of an example of Method 1300 for notifying an authentication list according to a subscription notification model in a hub-and-spoke configuration, according to one or more embodiments. One or more operations of Method 1300 may be part of operations S1010 and S1020 in Method 1000, and may be performed by at least one processor (e.g., processor 320) of the NEA system, which may correspond to a hub that is communicably connected to multiple network entities in the system.

[0158] As illustrated in Figure 13, in operation S1310, at least one processor 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, at least one processor may be configured to register the first agent and the second agent under a subscription notification model.

[0159] In particular, the first and second agents may be configured to subscribe to the hub's centralized endpoint URL using a REST API, where the hub's subscription management API manages the processing of subscriptions, publications, and notifications. The hub then responds to the first and second agents with a success status code indicating that the subscription was successful, and keeps the connection between the hub and the first and second agents open. The method then proceeds to operation S1320.

[0160] In operation S1320, at least one processor may be configured to receive the first authentication list from the first agent in a manner similar to that described above with respect to operation S1010. According to one embodiment, the first agent may be configured to periodically send the first authentication list. The method may then proceed to operation S1330.

[0161] In operation S1330, at least one processor may be configured to receive the second authentication list from the second agent. According to one embodiment, the second agent may be configured to periodically send the second authentication list. According to another embodiment, the first network entity and the second network entity may authenticate each other.

[0162] For example, returning to Figure 11, the hub may be configured to receive an authentication list for network entity M (for example, the authentication list for network entity M shown in Figure 6) from an agent deployed in network entity M. The method then proceeds to operation S1234. The method then proceeds to operation S1340.

[0163] In operation S1340, at least one processor may be configured to update the second authentication list to include the first authentication list. For example, a hub 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 in operation S825 of method 805. The method then proceeds to operation S1350.

[0164] In operation S1350, at least one processor may be configured to send the updated second authentication list to the second agent. According to one embodiment, at least one processor may be configured to periodically send the updated second authentication list. For example, the hub 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 a manner similar to that described above in operation S835 in method 805.

[0165] After executing operation S1350, method 1300 may return to operation S1320, so that at least one processor may be configured to repeatedly perform the following actions for at least a predetermined amount of time: receiving a first authentication list (operation S1320), receiving a second authentication list (operation S1330), updating the second authentication list (operation S1340), and sending the updated second authentication list (operation S1350).

[0166] For example, the first network entity and the second network entity may periodically send the first authentication list and the second authentication list. Thus, at least one processor may periodically receive the first authentication list and the second authentication list, and may resume receiving the first authentication list (operation S1320), receiving the second authentication list (operation S1330), updating the second authentication list (operation S1340), and periodically sending the updated second authentication list (operation S1350).

[0167] In addition, the first network entity may authenticate with the network entity again (change in the network). Here, the first authentication list is updated in the same manner as described above with respect to method 800 and sent to the hub during the periodic transmission described above.

[0168] The above process ensures that the hub and agents are easily notified of any changes to the network, and that agents always have the latest version of the authentication list. The above process also ensures that the hub is quickly notified when new data becomes available for transmission, and that errors and retries for any failure scenarios are handled based on the "id" field to uniquely identify each message.

[0169] According to one embodiment, at least one processor may be configured to additionally 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 S1250 to S1270 of method 1200.

[0170] For this purpose, the system of this disclosure may notify the authentication list on the network.

[0171] [Example of a sequence for notifying an authenticated network entity in a hub-and-spoke configuration as described in this disclosure] Figures 14A to 14C illustrate an example of a flow sequence for notifying an authenticated network entity in a hub-and-spoke configuration according to a push-and-pull model, according to one or more embodiments. The example flow sequences shown in Figures 14A to 14C involve the processes previously described with respect to methods 1000 and 1200.

[0172] As shown in Figures 14A-14C, the network consists of three network entities deploying three agents (Agent 1, Agent 2, and Agent 3) and a central service (hub) located on the authentication server.

[0173] Before Step 1, Network Entity 1, Network Entity 2, and Network Entity 3 subscribe to the hub under a push-and-pull model.

[0174] During steps 1-3, network entity 1 performs authentication with network entity 2 in accordance with 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 is unsuccessful, network entity 2 may issue a security alert and block data traffic to and from network entity 1.

[0175] Between steps 4 and 5, network entity 2 generates its authentication list and notifies the hub of that authentication list over the secure connection.

[0176] During step 6, network entity 2 forms a direct trust with network entity 1. For example, when the authentication list of network entity 2 is received by the hub, the hub may be configured to generate a trust list that defines the trust level between network entity 2 and network entity 1 as direct trust, based on the authentication list of network entity 2 that defines network entity 1.

[0177] Between steps 7 and 11, network entity 3 performs authentication with network entity 2 in the same manner as described for network entities 1 and 2 in steps 1 to 5, generates an authentication list, and notifies the hub of the authentication list.

[0178] After step 11, the hub sends notifications to network entity 1, network entity 2, and network entity 3 regarding changes in the network.

[0179] Between steps 12 and 14, network entity 1, network entity 2, and network entity 3 send requests to the hub to send the updated authentication list, and the hub sends the updated authentication list to the corresponding network entities.

[0180] During step 15, network entity 2 forms a direct trust with network entity 3. For example, the hub may update the authentication list of network entity 3 to include network entity 2, and may generate a trust list that defines the trust level between network entity 2 and network entity 3 as direct trust, based on the authentication list of network entity 3 that defines network entity 2.

[0181] During step 16, network entity 1 forms 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 (which defines network entity 1), and may generate a trust list that defines the level of trust between network entity 3 and network entity 1 as an indirect trust, based on the authentication list of network entity 3 that defines network entity 1.

[0182] The configurations illustrated in Figures 5, 6, 9A-9C, 11, and 14A-14C are simplified for descriptive purposes and should not be understood as being intended to limit the scope of this disclosure in any way. For example, in practice, the number of network entities in the system may be any number, the number of ports in each of the network entities may be any number, each of the network entities may be authenticated together with any other network entities, the sequence of steps may be in any different order, and additional steps may be included. Similarly, the authentication list and trust list may take any other form and may include any additional information as used.

[0183] [Example of an implementation environment] Figure 15 illustrates an example of an environment 1500 in which the system and / or method described herein may be implemented. As shown in Figure 15, the environment 1500 may include a device 1510, a platform 1520, and a network 1530. The devices in environment 1500 may 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 1 to 14 may be performed by any combination of the elements illustrated in Figure 15.

[0184] In some embodiments, the NEA system described herein may be stored, hosted, or deployed on the cloud computing platform 1520. In this regard, device 1510 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 NEA system. In this case, device 1510 may include one or more devices that can receive, generate, store, process, and / or provide information related to the platform 1520.

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

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

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

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

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

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

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

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

[0193] The hypervisor 1524-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 1524. The hypervisor 1524-4 may present a virtual operating platform to the guest operating systems and may manage the execution of the guest operating systems. Multiple instances of various operating systems may share virtualized hardware resources.

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

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

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

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

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

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

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

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

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

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

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

[0205] Various further aspects and features of the embodiments of this disclosure may be defined by the following items: Item 1: Memory storage that stores computer executable instructions, At least one processor that is communicatively coupled to the aforementioned memory storage, With respect to the first network entity, a first authentication list is generated that defines one or more network entities that are authenticated together with the first network entity, To notify the second agent deployed in the second network entity, which is authenticated together with the first network entity, of the first authentication list, To perform the above, at least one processor which may be configured to execute the above instructions, A system that may include this. Item 2: The system according to item 1, wherein at least one processor may be configured to execute the instruction to notify the second agent of the first authentication list by sending the first authentication list to the second agent. Item 3: The at least one processor is 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 together with the first network entity, The first authentication list is updated to further specify one or more network entities that will be newly authenticated along with the first network entity, Sending the updated first authentication list to the one or more agents deployed in the one or more network entities that are authenticated together with the first network entity, It may be configured to execute the aforementioned instructions in order to perform the following: The system described in item 2. Item 4: The first network entity may include a first agent, The first agent may be configured to generate the first authentication list, send the first authentication list, update the first authentication list, and send the updated first authentication list. The system described in item 3. Item 5: The system described in item 4, wherein the first agent and the second agent may authenticate each other via at least one of a digital certificate and an application programming interface (API) key. Item 6: Memory storage that stores computer executable instructions, At least one processor that is communicatively coupled to the aforementioned memory storage, Receiving a first authentication list from a first agent deployed in a first network entity, which defines one or more network entities that are authenticated together with the first network entity, To notify the second agent deployed in the second network entity, which is authenticated together with the first network entity, of the first authentication list, To perform the above, at least one processor which may be configured to execute the above instructions, A system that may include this. Item 7: The at least one processor may be configured to execute the instruction in order to receive the second authentication list from the second agent. The at least one processor is To include the aforementioned first authentication list, update the aforementioned second authentication list, Send the updated list of authentications to the aforementioned second agent, The system may be configured to execute the instruction in order to notify the first authentication list. The system described in item 6. Item 8: The at least one processor is Send a notification to the second agent regarding the updated second authentication list, Receiving a request from the aforementioned second agent to send the updated aforementioned second authentication list, Upon receiving the aforementioned request, the updated second authentication list is sent, It may be configured to execute the aforementioned instructions in order to perform the following: The system described in item 7. Item 9: The aforementioned first agent may be configured to periodically send the aforementioned first authentication list. The at least one processor may be configured to execute the instruction to periodically send the updated second authentication list to the second agent. The system described in item 7 or 8. Item 10: The hub may be connected to the first agent and the second agent in a communication manner. The first agent and the second agent may be mutually authenticated with the hub via mutual TLS (mTLS). A system described in any of items 6 through 9. Item 11: With respect to the first network entity, a first authentication list is generated that defines one or more network entities that are authenticated together with the first network entity, To notify the second agent deployed in the second network entity, which is authenticated together with the first network entity, of the first authentication list, A method that may include this. Item 12: The method according to item 11, wherein notifying the first authentication list may include sending the first authentication list to the second agent. Item 13: 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 together with the first network entity, The first authentication list is updated to further specify one or more network entities that will be newly authenticated along with the first network entity, Sending the updated first authentication list to the one or more agents deployed in the one or more network entities that are authenticated together with the first network entity, The method described in item 12, which may further include the following. Item 14: The first network entity may include a first agent. The first agent may be configured to generate the first authentication list, send the first authentication list, update the first authentication list, and send the updated first authentication list. The method described in item 13. Item 15: The method according to item 14, wherein the first agent and the second agent may authenticate each other via at least one of a digital certificate and an application programming interface (API) key. Item 16: Receiving a first authentication list from a first agent deployed in a first network entity, which defines one or more network entities that are authenticated together with the first network entity, To notify the second agent deployed in the second network entity, which is authenticated together with the first network entity, of the first authentication list, A method that may include this. Item 17: This may further include receiving a second authentication list from the second agent, Notifying the aforementioned first authentication list means To include the aforementioned first authentication list, update the aforementioned second authentication list, Send the updated list of authentications to the aforementioned second agent, It may include, The method described in item 16. Item 18: Send a notification to the second agent regarding the updated second authentication list, Receiving a request from the aforementioned second agent to send the updated aforementioned second authentication list, Upon receiving the aforementioned request, the updated second authentication list is sent, The method described in item 17, which may further include the following. Item 19: The aforementioned first agent may be configured to periodically send the aforementioned first authentication list. The updated list of previous2 authentications may be sent to the previous2 agent periodically. The method described in item 17 or 18. Item 20: Receiving the first authentication list and notifying the first authentication list may be performed by a hub that is communicatively coupled to the first agent and the second agent. The first agent and the second agent may be mutually authenticated with the hub via mutual TLS (mTLS). The method described in any of items 16 to 19.

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

Claims

1. A memory storage device that stores computer executable instructions, At least one processor that is communicably coupled to the at least one memory storage, With respect to the first network entity, a first authentication list is generated that defines one or more network entities that are authenticated together with the first network entity, To notify the second agent deployed in the second network entity, which is authenticated together with the first network entity, of the first authentication list, To perform the above, at least one processor configured to execute the above instructions, A system equipped with these features.

2. The system according to claim 1, wherein the at least one processor is configured to execute the instruction to notify the second agent of the first authentication list by transmitting the first authentication list to the second agent.

3. The at least one processor is 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 together with the first network entity, The first authentication list is updated to further specify one or more network entities that will be newly authenticated along with the first network entity, To send the updated first authentication list to the one or more agents deployed in the one or more network entities that are authenticated together with the first network entity, To perform the above, it is configured to execute the above instruction, The system according to claim 2.

4. The first network entity comprises a first agent, The first agent is configured to generate the first authentication list, send the first authentication list, update the first authentication list, and send the updated first authentication list. The system according to claim 3.

5. The system according to claim 4, wherein the first agent and the second agent are mutually authenticated via at least one of a digital certificate and an application programming interface (API) key.

6. A memory storage device that stores computer executable instructions, At least one processor that is communicably coupled to the at least one memory storage, Receiving a first authentication list from a first agent deployed in a first network entity, which defines one or more network entities that are authenticated together with the first network entity, To notify the second agent deployed in the second network entity, which is authenticated together with the first network entity, of the first authentication list, To perform the above, at least one processor configured to execute the above instructions, A system equipped with these features.

7. The at least one processor is configured to execute the instruction in order to receive the second authentication list from the second agent. The at least one processor is To include the aforementioned first authentication list, update the aforementioned second authentication list, To send the updated second authentication list to the second agent, The system is configured to execute the command in order to notify the first authentication list. The system according to claim 6.

8. The at least one processor is Send a notification to the second agent regarding the updated second authentication list, Receiving a request from the aforementioned second agent to send the updated aforementioned second authentication list, Upon receiving the aforementioned request, the updated second authentication list is sent, To perform the above, it is configured to execute the above instruction, The system according to claim 7.

9. The first agent is configured to periodically send the first authentication list. The at least one processor is configured to execute the instruction to periodically send the updated second authentication list to the second agent. The system according to claim 7.

10. The hub is connected to the first agent and the second agent in a communication manner, The first agent and the second agent are mutually authenticated together with the hub via mutual TLS (mTLS). The system according to claim 6.

11. With respect to the first network entity, a first authentication list is generated that defines one or more network entities that are authenticated together with the first network entity, To notify the second agent deployed in the second network entity, which is authenticated together with the first network entity, of the first authentication list, A method for providing this.

12. The method according to claim 11, wherein notifying the first authentication list comprises transmitting the first authentication list to the second agent.

13. 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 together with the first network entity, The first authentication list is updated to further specify one or more network entities that will be newly authenticated along with the first network entity, To send the updated first authentication list to the one or more agents deployed in the one or more network entities that are authenticated together with the first network entity, The method according to claim 12, further comprising:

14. The first network entity comprises a first agent, The first agent is configured to generate the first authentication list, send the first authentication list, update the first authentication list, and send the updated first authentication list. The method according to claim 13.

15. The method according to claim 14, wherein the first agent and the second agent are mutually authenticated via at least one of a digital certificate and an application programming interface (API) key.

16. Receiving a first authentication list from a first agent deployed in a first network entity, which defines one or more network entities that are authenticated together with the first network entity, To notify the second agent deployed in the second network entity, which is authenticated together with the first network entity, of the first authentication list, A method for providing this.

17. The system further comprises receiving a second authentication list from the second agent, Notifying the aforementioned first authentication list means To include the aforementioned first authentication list, update the aforementioned second authentication list, To send the updated second authentication list to the second agent, Equipped with, The method according to claim 16.

18. Send a notification to the second agent regarding the updated second authentication list, Receiving a request from the aforementioned second agent to send the updated aforementioned second authentication list, Upon receiving the aforementioned request, the updated second authentication list is sent, The method according to claim 17, further comprising:

19. The first agent is configured to periodically send the first authentication list. The updated second authentication list is periodically sent to the second agent. The method according to claim 17.

20. Receiving the first authentication list and notifying the first authentication list are performed by a hub that is communicatively coupled to the first agent and the second agent. The first agent and the second agent are mutually authenticated together with the hub via mutual TLS (mTLS). The method according to claim 16.

Images