System and method for advertising requesters in network

Abstract

A system, method, and apparatus are provided for enabling a network entity to view an authenticated requestor in a network. According to an embodiment, the system may include: a memory storing computer executable instructions; and at least one processor communicatively coupled to the memory, wherein the at least one processor may be configured to execute the instructions to: create a first authentication list for a first network entity; receiving a second authentication list from a second network entity; and creating a trust list for the first network entity based on the first authentication list and the second authentication list, wherein the trust list for the first network entity specifies a trust level between the first network entity and one or more of the first authentication list and the second authentication list.

Description

Technical Field

[0001] Systems, methods, and computer programs consistent with exemplary embodiments of this disclosure relate to telecommunications networks, and more specifically to enabling network entities to view authenticated requesters within a telecommunications network. Background Technology

[0002] The radio access network (RAN) is a crucial component of a telecommunications system because it connects end-user equipment (or user equipment) to other parts of the network. The RAN comprises a combination of various network elements (NEs) that connect end-users to the core network. Traditionally, the hardware and / or software of a particular RAN is vendor-specific.

[0003] Open RAN (O-RAN) technology has emerged that enables multiple vendors to provide hardware and / or software to telecommunications systems. Because different vendors are involved, the types of hardware and / or software provided can also differ. That is, different types of NEs can be provided by different vendors, and depending on the specific service, NEs can be virtualized in software (e.g., virtual machine (VM) based, cloud-native, etc.) or in physical hardware (e.g., non-VM based).

[0004] In open fronthaul networks of telecommunications systems employing the O-RAN architecture, network entities can utilize port-based network access control (IEEE 802.1x) to regulate network access and prevent unauthorized or unidentified parties from transmitting and receiving data, thus avoiding network outages, service theft, or data loss. Network entities can refer to entities such as RAN elements (e.g., O-RAN Centralized Units (O-CUs), O-RAN Distributed Units (O-DUs), O-RAN Radio Units (O-RUs), etc.) and transport network elements, and can act as authenticators or requesters. Under IEEE 802.1x, data services are only permitted to be transmitted between network entities when these entities authenticate each other.

[0005] In the prior art, information about authenticated network entities (e.g., which network entities are authenticated and trustworthy) is stored within the corresponding network entity that participates in such authentication, and this information is not shared with network entities that do not participate in such authentication. Furthermore, in the prior art, if a network entity connects to an authenticated network entity, it can be assumed that such network entity is trustworthy.

[0006] Therefore, the aforementioned network entity authentication methods in the prior art may have at least the following drawbacks. Since information about authenticated network entities is stored locally, and a network entity can be simply assumed to be trustworthy based on its connection to an authenticated network entity, this process violates the Zero Trust Model of the O-RAN architecture, and there is no mechanism to enable a single network entity in an open fronthaul network to have a comprehensive understanding of all authenticated network entities within the network. Summary of the Invention

[0007] The exemplary embodiments of this disclosure enable network entities to view authenticated requesters within the network. Therefore, the exemplary embodiments of this disclosure enable network elements to develop data storage for information about authenticated requesters, thereby constructing a comprehensive view of all authenticated requesters and defining explicit trust levels.

[0008] According to an embodiment, a system is provided. The system may include: a memory storage device storing computer-executable instructions; and at least one processor communicatively coupled to the memory storage device, wherein the at least one processor may be configured to execute the instructions to: create a first authentication list for a first network entity, wherein the first authentication list specifies one or more network entities authenticated with the first network entity; receive a second authentication list from a second network entity, wherein the second authentication list specifies one or more network entities authenticated with the second network entity, and wherein the first network entity and the second network entity authenticate each other; and create a trust list for the first network entity based on the first authentication list and the second authentication list, wherein the trust list for the first network entity specifies a trust level between the first network entity and one or more network entities in the first and second authentication lists.

[0009] According to an embodiment, a system is provided. The system may include: a memory storage device storing computer-executable instructions; and at least one processor communicatively coupled to the memory storage device, wherein the at least one processor may be configured to execute the instructions to: receive a first authentication list from a first network entity, wherein the first authentication list specifies one or more network entities authenticated with the first network entity; receive a second authentication list from a second network entity, wherein the second authentication list specifies one or more network entities authenticated with the second network entity, and wherein the first network entity and the second network entity authenticate each other; and create a trust list for the first network entity based on the first authentication list and the second authentication list, wherein the trust list for the first network entity specifies a trust level between the first network entity and one or more network entities in the first and second authentication lists.

[0010] According to an embodiment, a method is provided. The method may include: creating a first authentication list for a first network entity, wherein the first authentication list specifies one or more network entities authenticated with the first network entity; receiving a second authentication list from a second network entity, wherein the second authentication list specifies one or more network entities authenticated with the second network entity, and wherein the first network entity and the second network entity authenticate each other; and creating a trust list for the first network entity based on the first authentication list and the second authentication list, wherein the trust list for the first network entity specifies a trust level between the first network entity and one or more network entities in the first and second authentication lists.

[0011] According to an embodiment, a method is provided. The method may include: receiving a first authentication list from a first network entity, wherein the first authentication list specifies one or more network entities authenticated with the first network entity; receiving a second authentication list from a second network entity, wherein the second authentication list specifies one or more network entities authenticated with the second network entity, and wherein the first network entity and the second network entity authenticate each other; and creating a trust list for the first network entity based on the first authentication list and the second authentication list, wherein the trust list for the first network entity specifies a trust level between the first network entity and one or more network entities in the first and second authentication lists.

[0012] Additional aspects will be set forth in part in the description which follows, and will be apparent in part from the description, or may be realized by practicing the embodiments presented in this disclosure. Attached Figure Description

[0013] The features, advantages, and significance of exemplary embodiments of the present disclosure will now be described with reference to the accompanying drawings, wherein like symbols denote like elements, and in the drawings:

[0014] Figure 1 The diagram illustrates a sample system configuration according to one or more embodiments for enabling network entities to view authenticated requesters in a peer configuration.

[0015] Figure 2 The diagram illustrates a sample system configuration according to one or more embodiments for enabling network entities to view authenticated requesters in a spoke-shaped configuration.

[0016] Figure 3 The diagram illustrates a block diagram of an example component in an authentication viewing (AV) system according to one or more embodiments.

[0017] Figure 4 The illustration shows a flowchart of an example method according to one or more embodiments for enabling a network entity to view an authenticated requester in a peer configuration.

[0018] Figure 5 The illustration shows an example configuration of network entities in a peer configuration according to one or more embodiments.

[0019] Figure 6 An example of an authentication list according to one or more embodiments is illustrated.

[0020] Figure 7 The illustration shows a flowchart of an example method according to one or more embodiments for enabling a network entity to view an authenticated requester in a spoke configuration.

[0021] Figure 8 The illustration shows an example configuration of network entities in a spoke-shaped configuration according to one or more embodiments.

[0022] Figure 9 The illustration shows a flowchart of an example method for creating a trust list according to one or more embodiments.

[0023] Figure 10A The illustration shows an example of a trust list for network entity A created based on an authentication list of network entity A according to one or more embodiments.

[0024] Figure 10B An example of an updated authentication list for network entity A according to one or more embodiments is illustrated.

[0025] Figure 10C An example of an updated trust list for network entity A according to one or more embodiments is illustrated.

[0026] Figure 11 The diagram illustrates an example environment in which the systems and / or methods described in this paper can be implemented. Detailed Implementation

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

[0028] The foregoing disclosure provides illustrations and descriptions, but is not intended to be exhaustive or to limit implementations to the precise forms disclosed. Modifications and variations are possible based on the foregoing disclosure, or may be derived from practical implementation. Furthermore, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). Additionally, in the operational description provided below, it will be understood that 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 switched.

[0029] It is evident that the systems and / or methods described herein can be implemented in various 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 does not limit these implementations. Therefore, since the operation and behavior of the systems and / or methods are described herein without reference to specific software code, it should be understood that software and hardware can be designed to implement these systems and / or methods based on the descriptions herein.

[0030] Although specific combinations of features are disclosed in the specification, these combinations are not intended to limit the possible disclosures. In fact, many of these features can be combined in ways not specifically disclosed in the specification.

[0031] Unless explicitly stated otherwise, no element, action, or instruction used herein should be construed as critical or necessary. Furthermore, 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.” Figure 1 For individual items, the term "one" or similar language is used. Furthermore, as used herein, the terms "has," "have," "having," "include," "including," etc., are intended to be open-ended terms. Additionally, unless explicitly stated otherwise, the word "based on" means "at least partially based on." Furthermore, expressions such as "at least one of [A] and [B]" or "at least one of [A] or [B]" should be understood to include only A, only B, or both A and B.

[0032] The systems, methods, devices, etc. provided in the exemplary embodiments of this disclosure enable network entities to view authenticated requesters in the network.

[0033] According to an embodiment, the system can create or receive a first authentication list of a first network entity, the first authentication list specifying one or more network entities authenticated with the first network entity, receive a second authentication list from a second network entity, the second authentication list specifying one or more network entities authenticated with the second network entity, and then create a trust list for the first network entity based on the first authentication list and the second authentication list, wherein the trust list for the first network entity will specify the trust level between the first network entity and one or more network entities in the first authentication list and the second authentication list.

[0034] Ultimately, the exemplary embodiments of this disclosure enable network entities to view authenticated requesters in the network, which in turn enables the development of data storage for network elements regarding authenticated requesters, thereby constructing a comprehensive view of all authenticated requesters and defining explicit trust levels.

[0035] It is to be expected that the features, advantages and significance of the above example embodiments are only a part of this disclosure and are not intended to exhaustively describe or limit the scope of this disclosure.

[0036] The following provides a further description of the features, components, configuration, operation, and implementation of a threshold tuning system according to one or more embodiments of the present disclosure. Example System Architecture

[0037] Figure 1 The diagram illustrates a sample system configuration 100 according to one or more embodiments, enabling network entities to view authenticated requesters in a peer configuration. Figure 1 As shown, system configuration 100 may include multiple network entities (e.g., network entity A 110, network entity B 120, and network entity C 130) that are communicatively coupled to each other in a peer configuration.

[0038] Each of the multiple network entities 110, 120, and 130 may include a system, platform, module, etc., which may be configured to perform one or more operations or actions to enable the network entity to view authenticated requesters in the network. According to embodiments, the multiple network entities 110, 120, and 130 may include entities such as RAN elements (e.g., O-RAN Centralized Unit (O-CU), O-RAN Distributed Unit (O-DU), O-RAN Radio Unit (O-RU), etc.) and transport network elements.

[0039] Figure 2 The diagram illustrates a block diagram of an example system configuration 200 according to one or more embodiments, which is configured to enable network entities to view authenticated requesters in a spoke-wheel configuration. Figure 2 As shown, system configuration 200 may include multiple network entities (e.g., network entity A 210, network entity B 220, and network entity C 230) that are communicatively coupled to each other, and a hub 240 that is communicatively coupled to each of the multiple network entities 210, 220, 230 in a spoke configuration.

[0040] The central hub 240 may include systems, platforms, modules, etc., that can be configured to perform one or more operations or actions that enable network entities to view authenticated requesters in the network.

[0041] According to the embodiments, the plurality of network entities 210, 220, 230 may include entities such as RAN elements (e.g., O-RAN centralized unit (O-CU), O-RAN distributed unit (O-DU), O-RAN radio unit (O-RU) and transmission network elements).

[0042] According to an embodiment, hub 240 may include a centralized service that acts as a communication center for multiple network entities 210, 220, 230. According to an embodiment, hub 240 may be hosted on any element in an open fronthaul network that has communication paths to the multiple network entities 210, 220, 230, such as a Service Management Orchestrator (SMO) or an IEEE 802.1x authentication server.

[0043] Understandable. Figure 1 and Figure 2 The configuration shown is simplified for descriptive purposes and is not intended to limit the scope of this disclosure in any way. For example, in practice, the number of network entities in the system can be any number.

[0044] The following is for reference. Figure 4 This describes example operations that multiple network entities 110, 120, and 130 can perform to enable the network entities to view the authenticated requester. See below for reference. Figure 7 This describes example operations that the central hub 240 can perform to enable network entities to view authenticated requesters. Additionally, see the following references. Figure 3 Describes several example components that may be included in a plurality of network entities 110, 120, 130 and hub 240 according to one or more embodiments.

[0045] Figure 3 The diagram illustrates a block diagram of example components in an authentication viewing (AV) system 300 according to one or more embodiments. The AV system 300 may correspond to... Figure 1 At least one of the network entities 110, 120, and 130, or corresponding to Figure 2 The central hub 240, therefore, unless otherwise explicitly described, the features associated with the multiple network entities 110, 120, 130 and the central hub 240 and AV system 300 can be similarly applied to each other.

[0046] like Figure 3 As shown, the AV 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 device 340. However, it will be understood that, without departing from the scope of this disclosure, the AV system 300 may include more than [other components]. Figure 3 More or fewer components as shown, and / or may be used with Figure 3 The different arrangements shown.

[0047] The communication interface 310 may include at least one transceiver-like component (e.g., transceiver, separate receiver and transmitter, bus, etc.) that enables the components of the AV system 300 to communicate with each other and / or with one or more components outside the AV system 300, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections.

[0048] For example, communication interface 310 can couple processor 320 to storage device 340, enabling them to communicate and interoperate with each other while performing one or more operations. As another example, communication interface 310 can couple AV system 300 (or one or more components thereof) to separate network entities, enabling them to communicate and interoperate with each other.

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

[0050] The input / output component 330 may include at least one component that allows the AV system 300 to receive information and / or provide output information. It will be understood that in some embodiments, the input / output component 330 may include at least one input component (e.g., a touchscreen display, button, switch, microphone, sensor, etc.) and at least one output component (e.g., a display, speaker, one or more light-emitting diodes (LEDs), etc.), each component being separate from the others.

[0051] Storage device 340 may include one or more storage media suitable for storing data, information, and / or computer-executable instructions therein. According to embodiments, storage device 340 may include at least one memory storage device, such as random access memory (RAM), read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic storage, and / or optical storage) for storing information and / or instructions for use by processor 320. Additionally or alternatively, storage device 340 may include a hard disk (e.g., magnetic disk, optical disk, magneto-optical disk, and / or solid-state disk), an optical disk (CD), a digital versatile disk (DVD), a floppy disk, magnetic tape, magnetic tape, and / or another type of non-transitory computer-readable medium, and a corresponding drive.

[0052] According to an embodiment, storage device 340 can be configured to store information such as raw data, metadata, etc. Alternatively or additionally, storage device 340 can be configured to store one or more pieces of information associated with one or more operations performed by processor 320. For example, storage device 340 can store information defining: historical operations(s) performed by processor 320 to enable a network entity to view an authenticated requester, one or more results of operations performed by processor 320, etc. Furthermore, storage device 340 can store data or information required to enable a network entity to view an authenticated requester. For example, storage device 340 can store authentication lists and / or trust lists (see below). Figure 6 (As described in Figure 10).

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

[0054] Processor 320 may include at least one processor capable of being programmed or configured to perform the functions or operations described herein. For example, processor 320 may be configured to execute computer-executable instructions stored in at least one storage medium or memory storage device (e.g., storage device 340, etc.) to perform one or more actions or operations described herein.

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

[0056] According to an embodiment, 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 process the received one or more pieces of information, thereby enabling network entities to view the authenticated requester.

[0057] The following is for reference. Figures 4 to 1 0 provides descriptions of several example operations that can be performed by processor 320. The example operations in this disclosure that enable network entities to view authenticated requesters in a peering configuration.

[0058] In the following text, see references Figures 4 to 6 Several example operations that can be performed by the AV system disclosed herein are described.

[0059] Figure 4 A flowchart illustrating an example method 400 according to one or more embodiments for enabling a network entity to view an authenticated requester in a peer configuration is shown. One or more operations in method 400 may be performed by at least one processor of an AV system (e.g., processor 320), which may correspond to at least one network entity (i.e., a first network entity) among a plurality of network entities in the system.

[0060] like Figure 4 As shown, at operation S410, at least one processor can be configured to create a first authentication list for a first network entity. According to an embodiment, the first authentication list may specify one or more network entities authenticated with the first network entity. Specifically, according to an embodiment, the first authentication list may specify one or more MAC addresses (hereinafter referred to as "one or more first MAC addresses") of one or more ports of the first network entity, and one or more MAC addresses of one or more ports of one or more network entities authenticated with the one or more first MAC addresses. According to an embodiment, the first authentication list may also specify the roles of one or more ports of the first network entity, such as authenticator and requester.

[0061] For example, refer to Figure 5 The illustration depicts an example configuration of network entities in a peer-to-peer configuration according to one or more embodiments. Figure 5 As shown, the system can include 7 network entities: network entity Y, network entity A, network entity M, network entity X, network entity Z, network entity O and network entity N.

[0062] like Figure 5As shown, for example, network entity A authenticates with network entity Y and network entity M; wherein network entity A's port AuP4 has MAC address M4 and acts as an authenticator authenticating with network entity Y's port SuP11, which has MAC address M11 and acts as a requester; and wherein network entity A's port SuP5 has MAC address M5 and acts as a requester authenticating with network entity M's port AuP3, which has MAC address M3 and acts as an authenticator. A similar interpretation applies to network entities Y, M, X, Z, O, and N.

[0063] It is understood that authentication between network entities can be performed based on port-based network access control IEEE 802.1x and an IEEE 802.1x authentication server. Specifically, as part of the Extensible Authentication Protocol (EAP) (EAPoL) process on a local area network, the network entity acting as the authenticator requests identity information from the network entity acting as the requester and relays this identity information to the authentication server. The authentication server then verifies the identity information of the network entity acting as the requester and determines whether the network entity is authorized to access the network. If the network entity acting as the requester is authorized to access the network, it authenticates with the network entity acting as the authenticator. Through this authentication process, the network entities participating in the authentication process can obtain information such as port identity, port MAC address, port role, and authorization status from each other.

[0064] Figure 6 An example of an authentication list according to one or more embodiments is illustrated. Figure 6 As shown, for example, network entity A can be configured to create its authentication list, where such an authentication list can specify the MAC addresses M4 and M5 of network entity A's ports AuP4 and SuP5, the MAC address M11 of network entity Y's port SuP11 (authenticated with port AuP4), and the MAC address M3 of network entity M's port AuP3 (authenticated with port SuP5). Furthermore, network entity A's authentication list can also specify that network entity A's port AuP4 has the role of authenticator, and network entity A's port SuP5 has the role of requester. Therefore, the authentication list can specify network entity Y (authenticated with ports AuP4 and SuP5) and network entity M (authenticated with ports SuP11 and AuP3). A similar explanation applies to network entities Y, M, X, Z, O, and N. Since network entities Y, X, and Z have only one port, therefore... Figure 6 The authentication list of the aforementioned network entities is omitted. Then, the method proceeds to operation S420.

[0065] According to an embodiment, at least one processor can be configured to perform SNMPv3 queries for OID “1.3.111.2.802.1.1.15.2.2.3” at regular time intervals. Subsequently, based on the SNMPv3 response (which will show the status of object type “ieee8021XPaeLogonGroup”), at least one processor can then create an authentication list.

[0066] According to an embodiment, at least one processor may also be configured to transmit a first authentication list to one or more network entities that have authenticated with the first network entity.

[0067] In operation S420, at least one processor can be configured to receive a second authentication list from a second network entity. According to an embodiment, the first and second network entities can authenticate each other. According to an embodiment, similar to the first authentication list, the second authentication list can specify one or more network entities authenticated with the second network entity. Specifically, according to an embodiment, the second authentication list can specify one or more MAC addresses (hereinafter referred to as "one or more second MAC addresses") of one or more ports of the second network entity, and one or more MAC addresses of one or more ports of the one or more network entities authenticated with the one or more second MAC addresses. According to an embodiment, the second authentication list can also specify the role of one or more ports of the second network entity, such as authenticator and requester.

[0068] For example, return to Figure 5 and Figure 6 Network entity A can receive data from network entity M (which is authenticated by network entity A). Figure 6 The method then proceeds to operation S430, which shows the authentication list of network entity M.

[0069] According to an embodiment, the transmission of the first authentication list and the reception of the second authentication list can be performed via an announcement interface.

[0070] At operation S430, at least one processor can be configured to create a trust list for a first network entity based on a first authentication list and a second authentication list. According to an embodiment, the trust list for the first network entity specifies the level of trust between the first network entity and one or more network entities in the first and second authentication lists.

[0071] For example, return Figure 5 and Figure 6Since the authentication list of network entity A specifies network entity Y and network entity M (which are authenticated with network entity A), and since the authentication list of network entity M specifies network entity X and network entity N (which are authenticated with network entity M via port MAC addresses M12 and M6), the trust list of network entity A can specify the trust level between network entity A and network entities Y, M, X, and N.

[0072] The following is for reference. Figure 9 Describe an example of the operations used to create a trust list.

[0073] After performing operation S430, method 400 may end or terminate. Alternatively, method 400 may return to operation S420, such that at least one processor can be configured to repeatedly perform receiving the second authentication list (at operation S420) and creating the trust list (at operation S430) for at least a predetermined amount of time. For example, at least one processor may continuously (or periodically) receive multiple authentication lists from multiple network entities and then restart receiving the second authentication list (at operation S420) and creating the trust list (at operation S430).

[0074] Therefore, the system disclosed herein enables network entities to view authenticated requesters within the network. The example operations in this disclosure for enabling network entities to view authenticated requesters in a spoke-shaped configuration.

[0075] In the following text, see references Figure 7 , Figure 6 and Figure 8 This document describes several example operations that the AV system disclosed herein can perform.

[0076] Figure 7 A flowchart illustrating an example method 700 according to one or more embodiments for enabling network entities to view an authenticated requester in a spoke configuration is shown. One or more operations in method 700 may be performed by at least one processor of an AV system (e.g., processor 320), which may correspond to a hub communicatively coupled to a plurality of network entities in the system.

[0077] like Figure 7 As shown, at operation S710, at least one processor can be configured to receive a first authentication list from a first network entity. The first authentication list may be similar to the first authentication list described above with respect to method 400.

[0078] For example, refer to Figure 8 The illustration shows an example configuration of network entities in a spoke-shaped configuration according to one or more embodiments. Figure 8The example configuration of network entities in the spoke-shaped configuration shown is similar to Figure 5 The example configuration shown in the peer configuration adds a central hub that is communicatively coupled to each of the network entities Y, A, M, X, Z, O, and N.

[0079] like Figure 8 As shown, for example, the central hub can be configured to receive a list of authentication credentials for network element A (e.g., ...). Figure 6 (The authentication list of network element A is shown). Then, the method proceeds to operation S720.

[0080] At operation S720, at least one processor may be configured to receive a second authentication list from a second network entity. According to an embodiment, the first and second network entities may authenticate each other. The second authentication list may be similar to the second authentication list described above with respect to method 400.

[0081] For example, return to Figure 6 and Figure 8 The central hub can receive data from network entity M (which is authenticated with network entity A). Figure 6 The method then proceeds to operation S730, which shows the authentication list of network entity M.

[0082] According to an embodiment, the first authentication list and the second authentication list can be received via an announcement interface.

[0083] At operation S730, at least one processor can be configured to create a trust list for the first network entity based on a first authentication list and a second authentication list. The trust list can be similar to the trust list described above with respect to method 400.

[0084] For example, return Figure 6 and Figure 8 Since the authentication list of network entity A specifies network entity Y and network entity M (which are authenticated with network entity A), and since the authentication list of network entity M specifies network entity X and network entity N (which are authenticated with network entity M via port MAC addresses M12 and M6), the trust list of network entity A can specify the trust level between network entity A and network entities Y, M, X, and N.

[0085] The following is for reference. Figure 9 Describe an example of the operations used to create a trust list.

[0086] After performing operation S730, method 700 may end or terminate. Alternatively, method 700 may return to operation S720, such that at least one processor can be configured to repeatedly perform receiving the second authentication list (at operation S720) and creating the trust list (at operation S730) for at least a predetermined amount of time. For example, at least one processor may continuously (or periodically) receive multiple authentication lists from multiple network entities and then restart receiving the second authentication list (at operation S720) and creating the trust list (at operation S730).

[0087] Therefore, the system disclosed herein enables network entities to view authenticated requesters within the network. The example operations for creating a trust list in this disclosure

[0088] In the following reference Figure 9 Figure 10 illustrates several example operations for creating a trust list, which can be executed by at least one processor.

[0089] Figure 9 A flowchart of an example method 900 for creating a trust list according to one or more embodiments is illustrated. One or more operations in method 900 may be performed by at least one processor of an AV system (e.g., processor 320), which may correspond to at least one of a plurality of network entities in the system (i.e., a first network entity), or may correspond to a hub communicatively coupled to a plurality of network entities in the system.

[0090] According to an embodiment, the trust list can form a network-level authentication requester table.

[0091] like Figure 9 As shown, at operation S910, at least one processor can be configured to create a trust list for a first network entity based on a first authentication list. According to an embodiment, the trust list created for the first network entity based on the first authentication list can specify the trust level between the first network entity and one or more network entities in the first authentication list.

[0092] Specifically, according to an embodiment, the trust level can be either direct trust or indirect trust, and can be between one or more ports of the first network entity and one or more ports of one or more network entities that have the requester role in the first authentication list. According to an embodiment, the trust list for the first network entity may include one or more MAC addresses of one or more ports of the first network entity, and one or more MAC addresses of one or more ports of one or more network entities that have the requester role in the first authentication list.

[0093] For example, refer to Figure 10AThe illustration shows an example of a trust list for network entity A created based on an authentication list of network entity A according to one or more embodiments. Figure 10A As shown, the trust list of network entity A specifies the MAC addresses M5 and M4 of ports SuP5 and AuP4 of network entity A.

[0094] Furthermore, since the port of network entity Y (i.e., SuP11) (located in the authentication list of network entity A) is authenticated with the port AuP4 of network entity A, the trust list of network entity A specifies the MAC address M11 of the aforementioned port SuP11, and specifies the trust level between the port SuP11 of network entity Y and the port AuP4 of network entity A as direct trust.

[0095] On the other hand, since the port (i.e., SuP2) of network entity M, which plays the role of the requester, is authenticated via port AuP3 of network entity M and port SuP5 of network entity A, the trust list of network entity A specifies the MAC address M2 of the aforementioned port SuP2, and specifies the trust level between port SuP2 of network entity M and port SuP5 of network entity A as indirect trust. Then, the method can proceed to operation S920.

[0096] In operation of S920, at least one processor can be configured to update the first authentication list to include the second authentication list in response to receiving the second authentication list.

[0097] For example, refer to Figure 10B The illustration shows an example of an updated authentication list for network entity A according to one or more embodiments. Figure 10B As shown, the authentication list of network entity A has been updated to include Figure 6 The method then proceeds to operation S930, which involves authenticating the network entity M.

[0098] According to an embodiment, in a peer-to-peer configuration, at least one processor may also be configured to transmit an updated first authentication list to one or more network entities that are authenticated with the first network entity. Therefore, the received second authentication list may further specify one or more network entities that are authenticated with a third network entity, which is also authenticated with the second network entity.

[0099] At operation S930, at least one processor can be configured to update the trust list based on the updated first authentication list. According to an embodiment, the updated trust list can also specify a trust level between the first network entity and one or more network entities in the second authentication list.

[0100] Specifically, according to an embodiment, the trust level can be either direct trust or indirect trust, and can also be between one or more ports of a first network entity and one or more ports of one or more network entities that have the requester role in a second authentication list (now included in the first authentication list). According to an embodiment, the trust list for the first network entity may include one or more MAC addresses of one or more ports of the first network entity, and one or more MAC addresses of one or more ports of one or more network entities that have the requester role in the second authentication list.

[0101] For example, refer to Figure 10C The illustration shows an example of an updated trust list for network entity A according to one or more embodiments. Specifically, since the port (i.e., SuP12) of network entity X, which has the role of requester (located in the authentication list of network entity M, which is now included in the authentication list of network entity A), is authenticated with port SuP5 of network entity A via ports AuP1 and AuP3 of network entity M, the trust list of network entity A further specifies the MAC address M12 of the aforementioned port SuP12, and specifies the trust level between port SuP12 of network entity X and port SuP5 of network entity A as indirect trust. Similarly, since the port of network entity N (i.e., SuP7) which has the role of requester (located in the authentication list of network entity M, which is now included in the authentication list of network entity A), is authenticated with port SuP5 of network entity A via port AuP6 of network entity N and ports SuP2 and AuP3 of network entity M, the trust list of network entity A also specifies the MAC address M7 of the aforementioned port SuP7, and specifies the trust level between port SuP7 of network entity N and port SuP5 of network entity A as indirect trust.

[0102] It is understandable that, in the above process, the port of network entity A itself, which is currently included in the authentication list of network entity M in the authentication list of network entity A, can be ignored.

[0103] After performing operation S930, method 900 may end or terminate. Alternatively, method 900 may return to operation S920, such that at least one processor may be configured to repeatedly perform updating the first authentication list (at operation S920) and updating the trust list (at operation S930) until each of the plurality of network entities has a full view of all authenticated network entities within the network.

[0104] For example, in a peer-to-peer configuration, after updating network entity A's authentication list to include network entity M's authentication list and updating network entity A's trust list based on the updated authentication list, network entity M can receive network entity N's authentication list (which specifies network entity O authenticated by network entity N) from network entity N. Then, in a similar manner to the above, network entity M's authentication list can be updated to include network entity N's authentication list (so that network entity N's authentication list now specifies network entity O), and network entity M's trust list can be updated based on the updated authentication list. Subsequently, network entity M can again transmit its updated authentication list to network entity A, where the process is repeated, and network entity A's authentication list and trust list are updated so that network entity O is now also specified. The above process can be repeated until each of the multiple network entities has a comprehensive view of all authenticated network entities within the network.

[0105] Therefore, for example, if network entity Z acts as O-DU and network entity X acts as O-RU, the above method allows O-DU and O-RU to form indirect trust with each other, even if O-DU and O-RU are not authenticated to each other.

[0106] Understandable. Figure 5 , Figure 6 , Figure 8 and Figures 10A to 10C The configurations shown are simplified for descriptive purposes and are not intended to limit the scope of this disclosure in any way. For example, in practice, the number of network entities in the system can be any number, the number of ports in each of the multiple network entities can be any number, each of the multiple network entities can authenticate with any other network entity, and so on. Similarly, the authentication list and trust list can be any other form and may include any additional information depending on the use case. Example Implementation Environment

[0107] Figure 11 A schematic diagram of an example environment 1100 in which the systems and / or methods described herein can be implemented is illustrated. Figure 11 As shown, environment 1100 may include device 1110, platform 1120, and network 1130. Devices in environment 1100 may be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections. In some embodiments, the above references... Figures 1 to 1 Any of the functions and operations described in 0 can be provided by Figure 11 Any combination of the elements shown can be used to perform this action.

[0108] According to embodiments, the AV system described herein can be stored, hosted, or deployed in a cloud computing platform 1120. In this regard, device 1110 may include apparatus, systems, devices, etc., used by users (e.g., users of a marketing team, users of a network planning team, etc.) to access the AV system. In this case, device 1110 may include one or more devices capable of receiving, generating, storing, processing, and / or providing information associated with platform 1120.

[0109] Platform 1120 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information. In some implementations, platform 1120 may include a cloud server or a group of cloud servers. In some implementations, platform 1120 may be designed to be modular, allowing certain software components to be swapped in or out as needed. Therefore, platform 1120 can be easily and / or quickly reconfigured for different purposes.

[0110] In some implementations, as shown in the figure, platform 1120 may be hosted in a cloud computing environment 1122. It is worth noting that although the implementations described herein depict platform 1120 as being hosted in a cloud computing environment 1122, in some implementations, platform 1120 may not be cloud-based (i.e., it may be implemented outside of a cloud computing environment), or may be partially cloud-based.

[0111] The cloud computing environment 1122 includes the environment of the hosting platform 1120. The cloud computing environment 1122 can provide services such as computing, software, data access, and storage, without requiring the end user (e.g., user device 1110) to know the physical location and configuration of the (multiple) systems and / or (multiple) devices of the hosting platform 1120. As shown in the figure, the cloud computing environment 1122 may include a set of computing resources 1124 (collectively referred to as computing resources 1124, and individually referred to as computing resources 1124).

[0112] Computing resource 1124 includes one or more personal computers, computing device clusters, workstation computers, server devices, or other types of computing and / or communication devices. In some implementations, computing resource 1124 may host platform 1120. Cloud resources may include computing instances executing in computing resource 1124, storage devices provided in computing resource 1124, data transmission devices provided by computing resource 1124, etc. In some implementations, computing resource 1124 may communicate with other computing resources 1124 via wired connections, wireless connections, or a combination of wired and wireless connections.

[0113] like Figure 11As further shown, computing resources 1124 include a set of cloud resources, such as one or more applications (APP) 1124-1, one or more virtual machines (VM) 1124-2, virtualized storage (VS) 1124-3, one or more hypervisors (HYP) 1124-4, etc.

[0114] Application 1124-1 includes one or more software applications that can be provided to or accessed by user device 1110. Application 1124-1 can eliminate the need to install and execute software applications on user device 1110. For example, application 1124-1 may include software associated with platform 1120, and / or any other software that can be provided via cloud computing environment 1122. In some implementations, an application 1124-1 may send / receive information to or from one or more other applications 1124-1 via virtual machine 1124-2.

[0115] Virtual machine 1124-2 includes a software implementation of a machine (e.g., a computer) (such as a physical machine) that executes programs. Virtual machine 1124-2 can be a system virtual machine or a process virtual machine, depending on the extent to which virtual machine 1124-2 is used and corresponds to any real machine. A system virtual machine can provide a complete system platform supporting the execution of a full operating system (OS). A process virtual machine can execute a single program and can support a single process. In some implementations, virtual machine 1124-2 can execute on behalf of a user (e.g., user device 1110) and can manage the infrastructure of the cloud computing environment 1122, such as data management, synchronization, or long-duration data transfer.

[0116] Virtualized storage 1124-3 includes one or more storage systems and / or one or more devices that utilize virtualization technologies within a storage system or device of computing resource 1124. In some implementations, the type of virtualization, within the context of the storage system, may include block virtualization and file virtualization. Block virtualization can refer to the abstraction (or separation) of logical storage from physical storage, enabling access to the storage system regardless of physical storage or heterogeneous architecture. This separation allows storage system administrators flexibility in how they manage storage for end users. File virtualization eliminates the dependency between data accessed at the file level and the location where the files are physically stored. This can optimize storage usage, server consolidation, and / or performance for non-disruptive file migration.

[0117] Hypervisor 1124-4 can provide hardware virtualization technology that allows multiple operating systems (e.g., "guest operating systems") to run simultaneously on a host computer (such as computing resource 1124). Hypervisor 1124-4 can present a virtual operating platform to the guest operating system and manage the execution of the guest operating system. Multiple instances of various operating systems can share virtualized hardware resources.

[0118] Network 1130 may include one or more wired and / or wireless networks. For example, network 1130 may include cellular networks (e.g., fifth-generation (5G) networks, long-term evolution (LTE) networks, third-generation (3G) networks, code division multiple access (CDMA) networks, etc.), public land mobile networks (PLMN), local area networks (LAN), wide area networks (WAN), metropolitan area networks (MAN), telephone networks (e.g., public switched telephone network (PSTN)), private networks, self-organizing networks, intranets, the Internet, fiber-optic networks, etc., and / or combinations of these or other types of networks.

[0119] Figure 11 The number and arrangement of devices and networks shown are provided as examples. In practice, similar arrangements may exist. Figure 11 The comparison shown is between more devices and / or networks, fewer devices and / or networks, different devices and / or networks, or devices and / or networks arranged differently. Furthermore, Figure 11 The two or more devices shown can be implemented within a single device, or Figure 11 The single device shown can be implemented as multiple distributed devices. Alternatively or additionally, a group of devices in environment 1100 (e.g., one or more devices) can perform one or more functions described as being performed by another group of devices in environment 1100. Various aspects of the embodiments

[0120] The foregoing disclosure provides illustrations and descriptions, but is not intended to be exhaustive or to limit implementations to the precise forms disclosed. Modifications and variations are possible in light of the foregoing disclosure, or may be derived from the practice of implementation.

[0121] Some embodiments may relate to systems, methods, and / or computer-readable media at any possible level of integration technical detail. Furthermore, one or more of the above components may be implemented as instructions stored on a computer-readable medium and executable by at least one processor (and / or may include at least one processor). A computer-readable medium may include (multiple) computer-readable non-transitory storage media having computer-readable program instructions thereon for causing a processor to perform operations.

[0122] Computer-readable storage media can be tangible devices that can retain and store instructions for use by instruction execution devices. Computer-readable storage media can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes: portable computer floppy disks, 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 optical disc read-only memory (CD-ROM), digital universal disc (DVD), memory sticks, floppy disks, mechanical encoding devices on which instructions are recorded (such as punched cards or raised structures in recesses), and any suitable combination of the foregoing. As used herein, computer-readable storage media should not be construed as transient signals, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

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

[0124] Computer-readable program code / instructions used to perform operations can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​(such as Smalltalk, C++, etc.) and procedural programming languages ​​(such as the "C" programming language or similar programming languages). Computer-readable program instructions can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or wide area network (WAN), or a connection to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, an electronic circuit system (including, for example, a programmable logic circuit system, a field-programmable gate array (FPGA), or a programmable logic array (PLA)) can execute computer-readable program instructions by utilizing the status information of the computer-readable program instructions to personalize the electronic circuit system, thereby performing aspects or operations.

[0125] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create parts for implementing the functions / actions specified in the flowcharts and / or block diagram blocks. These computer-readable program instructions may also be stored in a computer-readable storage medium that can instruct a computer, programmable data processing apparatus, and / or other device to operate in a particular manner, such that the computer-readable storage medium in which the instructions are stored includes an article of writing comprising instructions that implement aspects of the functions / actions specified in the flowcharts and / or block diagram blocks.

[0126] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus or other device to cause a series of operational steps to be executed on the computer, other programmable apparatus or other device, thereby producing a computer-implemented process, such that the instructions executed on the computer, other programmable apparatus or other device perform the functions / actions specified in the flowchart and / or block diagram blocks.

[0127] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media according to various embodiments. In this regard, each block in a flowchart or block diagram may represent one or more microservice modules, instruction segments, or portions, including one or more executable instructions for implementing one or more specified logical functions. The method, computer system, and computer-readable medium may include more blocks, fewer blocks, different blocks, or blocks arranged differently compared to those shown in the figures. In some alternative implementations, the functions described in a block may not appear in the order shown in the figures. For example, in fact, two blocks shown consecutively may be executed simultaneously or substantially simultaneously, or these blocks may sometimes be executed in reverse order, depending on the functions involved. It will also be noted that each block illustrated in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a system based on dedicated hardware that performs the specified functions or actions or executes a combination of dedicated hardware and computer instructions.

[0128] It is evident that the systems and / or methods described herein can be implemented in various 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 does not limit these implementations. Therefore, the operation and behavior of these systems and / or methods are described herein without reference to any specific software code. It should be understood that software and hardware can be designed to implement these systems and / or methods based on the descriptions herein.

[0129] Various other corresponding aspects and features of the embodiments of this disclosure can be defined by the following items: Item [1]: A system may include: a memory storage device storing computer-executable instructions; and at least one processor communicatively coupled to the memory storage device, wherein the at least one processor may be configured to execute instructions to: create a first authentication list for a first network entity, wherein the first authentication list specifies one or more network entities authenticated with the first network entity; receive a second authentication list from a second network entity, wherein the second authentication list specifies one or more network entities authenticated with the second network entity, and wherein the first network entity and the second network entity authenticate each other; and create a trust list for the first network entity based on the first authentication list and the second authentication list, wherein the trust list for the first network entity specifies: a level of trust between the first network entity and one or more network entities in the first authentication list and the second authentication list. Project [2]: According to the system of Project [1], wherein: the trust level may include one of direct trust and indirect trust; and the trust level may be between one or more ports of a first network entity and one or more ports of one or more network entities having the role of requester in a first authentication list and a second authentication list. Project [3]: According to the system of Project [2], the trust list for the first network entity may include: one or more MAC addresses of one or more ports of the first network entity and one or more MAC addresses of one or more ports of one or more network entities with the requester role in the first authentication list and the second authentication list. Item [4]: ​​A system according to any one of Items [1] to [3], wherein at least one processor may be configured to execute instructions to create a trust list for a first network entity based on a first authentication list and a second authentication list in such a way as: creating a trust list based on the first authentication list such that the trust list specifies a trust level between the first network entity and one or more network entities in the first authentication list; updating the first authentication list to include the second authentication list in response to receiving the second authentication list; and updating the trust list based on the updated first authentication list such that the trust list also specifies a trust level between the first network entity and one or more network entities in the second authentication list. Project [5]: According to Project [4], at least one processor may also be configured to execute instructions to send an updated first authentication list to one or more network entities that are authenticated with the first network entity. Item [6]: A system based on any one of Items [1] to [5], wherein: the second authentication list may also specify one or more network entities that are authenticated with the third network entity; and the third network entity may be authenticated with the second network entity. Item [7]: A system according to any one of Items [1] to [6], wherein: a first authentication list may specify one or more first MAC addresses of one or more ports of a first network entity, one or more third MAC addresses of one or more ports of one or more network entities authenticated with one or more first MAC addresses, and roles of one or more ports of the first network entity; a second authentication list may specify one or more second MAC addresses of one or more ports of a second network entity, one or more fourth MAC addresses of one or more ports of one or more network entities authenticated with one or more second MAC addresses, and roles of one or more ports of the second network entity; and roles may include one of an authenticator and a requester. Item [8]: A system according to any one of Items [1] to [7], wherein authentication between a first network entity, a second network entity, and one or more network entities may be based on: port-based network access control IEEE 802.1x. Item [9]: A system according to any one of Items [1] to [8], wherein the first network entity, the second network entity, and one or more network entities may include at least one of the following: O-CU, O-DU, O-RU, and transport network element. Item

[10] : A system may include: a memory storage device storing computer-executable instructions; and at least one processor communicatively coupled to the memory storage device, wherein the at least one processor may be configured to execute instructions to: receive a first authentication list from a first network entity, wherein the first authentication list specifies one or more network entities authenticated with the first network entity; receive a second authentication list from a second network entity, wherein the second authentication list specifies one or more network entities authenticated with the second network entity, and wherein the first network entity and the second network entity authenticate each other; and create a trust list for the first network entity based on the first authentication list and the second authentication list, wherein the trust list for the first network entity specifies: a level of trust between the first network entity and one or more network entities in the first authentication list and the second authentication list. Project

[11] : A method may include: creating a first authentication list for a first network entity, wherein the first authentication list specifies one or more network entities that are authenticated with the first network entity; receiving a second authentication list from a second network entity, wherein the second authentication list specifies one or more network entities that are authenticated with the second network entity, and wherein the first network entity and the second network entity authenticate each other; and creating a trust list for the first network entity based on the first authentication list and the second authentication list, wherein the trust list for the first network entity specifies: a level of trust between the first network entity and one or more network entities in the first authentication list and the second authentication list. Project

[12] : According to the method of Project

[11] , wherein: the trust level may include one of direct trust and indirect trust; and the trust level may be between one or more ports of the first network entity and one or more ports of one or more network entities having the role of requester in the first authentication list and the second authentication list. Project

[13] : According to the method of Project

[12] , the trust list for the first network entity may include: one or more MAC addresses of one or more ports of the first network entity and one or more MAC addresses of one or more ports of one or more network entities with the requester role in the first authentication list and the second authentication list. Item

[14] : The method of any one of Items

[11] to

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

[15] : According to the method of Project

[14] , it may also include: sending the updated first authentication list to one or more network entities that are authenticated with the first network entity. Item

[16] : A system according to any one of Items

[11] to

[15] , wherein: the second authentication list may also specify one or more network entities that are authenticated with the third network entity; and the third network entity may be authenticated with the second network entity. Item

[17] : The method according to any one of Items

[11] to

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

[18] : According to any one of Items

[11] to

[17] , the authentication between the first network entity, the second network entity, and one or more network entities may be based on: port-based network access control IEEE 802.1x. Item

[19] : The method according to any one of Items

[11] to

[18] , wherein the first network entity, the second network entity, and one or more network entities may include at least one of the following: O-CU, O-DU, O-RU, and transport network element. Project

[20] : A method may include: receiving a first authentication list from a first network entity, wherein the first authentication list specifies one or more network entities that are authenticated with the first network entity; receiving a second authentication list from a second network entity, wherein the second authentication list specifies one or more network entities that are authenticated with the second network entity, and wherein the first network entity and the second network entity authenticate each other; and creating a trust list for the first network entity based on the first authentication list and the second authentication list, wherein the trust list for the first network entity specifies: a level of trust between the first network entity and one or more network entities in the first authentication list and the second authentication list.

[0130] It is understandable that many modifications and variations of this disclosure are possible in accordance with the foregoing teachings. It is evident that, within the scope of the appended sections, this disclosure may be practiced in ways other than those specifically described herein.

Claims

1. A system comprising: At least one memory storage device for storing computer-executable instructions; as well as At least one processor is communicatively coupled to the at least one memory storage device, wherein the at least one processor is configured to execute the instructions to: A first authentication list is created for a first network entity, wherein the first authentication list specifies one or more network entities that are authenticated with the first network entity; Receive a second authentication list from a second network entity, wherein the second authentication list specifies one or more network entities that are authenticated with the second network entity, and wherein the first network entity and the second network entity authenticate each other; as well as A trust list is created for the first network entity based on the first authentication list and the second authentication list, wherein the trust list for the first network entity specifies the trust level between the first network entity and one or more network entities in the first authentication list and the second authentication list.

2. The system according to claim 1, wherein: The trust level includes either direct trust or indirect trust; and The trust level is between one or more ports of the first network entity and one or more ports of the one or more network entities that have the role of requester in the first authentication list and the second authentication list.

3. The system of claim 2, wherein the trust list for the first network entity comprises: One or more MAC addresses of one or more ports of the first network entity, and one or more MAC addresses of one or more ports of the one or more network entities that have the role of the requester in the first authentication list and the second authentication list.

4. The system of claim 1, wherein the at least one processor is configured to execute the instructions to create the trust list for the first network entity based on the first authentication list and the second authentication list in the following manner: The trust list is created based on the first authentication list, such that the trust list specifies the trust level between the first network entity and one or more network entities in the first authentication list; In response to receiving the second authentication list, the first authentication list is updated to include the second authentication list; as well as The trust list is updated based on the updated first authentication list, such that the trust list also specifies the trust level between the first network entity and one or more network entities in the second authentication list.

5. The system of claim 4, wherein the at least one processor is further configured to execute the instructions to send the updated first authentication list to the one or more network entities that have authenticated with the first network entity.

6. The system according to claim 1, wherein: The second authentication list also specifies one or more network entities that are authenticated with the third network entity; and The third network entity authenticates with the second network entity.

7. The system according to claim 1, wherein: The first authentication list specifies one or more first MAC addresses of one or more ports of the first network entity, one or more third MAC addresses of one or more ports of one or more network entities authenticated with the one or more first MAC addresses, and the role of the one or more ports of the first network entity; The second authentication list specifies one or more second MAC addresses of one or more ports of the second network entity, one or more fourth MAC addresses of one or more ports of one or more network entities authenticated with the one or more second MAC addresses, and the role of the one or more ports of the second network entity; and The role includes either the certifier or the requester.

8. The system of claim 1, wherein the authentication between the first network entity, the second network entity, and the one or more network entities is based on: port-based network access control IEEE 802.1x.

9. The system of claim 1, wherein the first network entity, the second network entity, and the one or more network entities comprise at least one of the following: O-CU, O-DU, O-RU, and a transport network element.

10. A system comprising: At least one memory storage device for storing computer-executable instructions; as well as At least one processor is communicatively coupled to the at least one memory storage device, wherein the at least one processor is configured to execute the instructions to: Receive a first authentication list from a first network entity, wherein the first authentication list specifies one or more network entities that are authenticated with the first network entity; Receive a second authentication list from the second network entity, wherein the second authentication list specifies one or more network entities that are authenticated with the second network entity, and wherein the first network entity and the second network entity authenticate each other; as well as A trust list is created for the first network entity based on the first authentication list and the second authentication list, wherein the trust list for the first network entity specifies the trust level between the first network entity and one or more network entities in the first authentication list and the second authentication list.

11. A method comprising: A first authentication list is created for a first network entity, wherein the first authentication list specifies one or more network entities that are authenticated with the first network entity; Receive a second authentication list from a second network entity, wherein the second authentication list specifies one or more network entities that are authenticated with the second network entity, and wherein the first network entity and the second network entity authenticate each other; as well as A trust list is created for the first network entity based on the first authentication list and the second authentication list, wherein the trust list for the first network entity specifies the trust level between the first network entity and one or more network entities in the first authentication list and the second authentication list.

12. The method of claim 11, wherein: The trust level includes either direct trust or indirect trust; and The trust level is between one or more ports of the first network entity and one or more ports of the one or more network entities that have the role of requester in the first authentication list and the second authentication list.

13. The method of claim 12, wherein the trust list for the first network entity comprises: One or more MAC addresses of one or more ports of the first network entity, and one or more MAC addresses of one or more ports of the one or more network entities that have the role of the requester in the first authentication list and the second authentication list.

14. The method of claim 11, wherein creating the trust list for the first network entity based on the first authentication list and the second authentication list comprises: The trust list is created based on the first authentication list, such that the trust list specifies the trust level between the first network entity and one or more network entities in the first authentication list; In response to receiving the second authentication list, the first authentication list is updated to include the second authentication list; as well as The trust list is updated based on the updated first authentication list, such that the trust list also specifies the trust level between the first network entity and one or more network entities in the second authentication list.

15. The method of claim 14, further comprising: The updated first authentication list is sent to the one or more network entities that have authenticated with the first network entity.

16. The method of claim 11, wherein: The second authentication list also specifies one or more network entities that are authenticated with the third network entity; and The third network entity authenticates with the second network entity.

17. The method of claim 11, wherein: The first authentication list specifies one or more first MAC addresses of one or more ports of the first network entity, one or more third MAC addresses of one or more ports of one or more network entities authenticated with the one or more first MAC addresses, and the role of the one or more ports of the first network entity; The second authentication list specifies one or more second MAC addresses of one or more ports of the second network entity, one or more fourth MAC addresses of one or more ports of one or more network entities authenticated with the one or more second MAC addresses, and the role of the one or more ports of the second network entity; and The role includes either the certifier or the requester.

18. The method of claim 11, wherein the authentication between the first network entity, the second network entity, and the one or more network entities is based on: port-based network access control IEEE 802.1x.

19. The method of claim 11, wherein the first network entity, the second network entity, and the one or more network entities comprise at least one of the following: O-CU, O-DU, O-RU, and a transport network element.

20. A method comprising: Receive a first authentication list from a first network entity, wherein the first authentication list specifies one or more network entities that are authenticated with the first network entity; Receive a second authentication list from the second network entity, wherein the second authentication list specifies one or more network entities that are authenticated with the second network entity, and wherein the first network entity and the second network entity authenticate each other; as well as A trust list is created for the first network entity based on the first authentication list and the second authentication list, wherein the trust list for the first network entity specifies the trust level between the first network entity and one or more network entities in the first authentication list and the second authentication list.

Images