EP-4736486-A1 - DETERMINING AUTHENTICATION STATUS INFORMATION OF AN O-RAN RADIO UNIT

Abstract

Provided are features for determining authentication status information of an Open Radio Access Network (O-RAN) Radio Unit (O-RU). According to embodiments, an O-RU controller may be configured to: obtain a Media Access Control (MAC) address of an O-RU; determine, based on the MAC address of the O-RU, an authentication status of the O-RU; based on determining that the O-RU has been authenticated, establish a channel binding with the O-RU; and based on determining that the O-RU has not been authenticated, isolate the O-RU from further communications with the O-RU controller.

Inventors

• CHINTAN SHAH, Paromita
• BYKAMPADI, Nagendra Shridhar
• ADHARAPURAPU, Krishna Pramod

Assignees

• Rakuten Symphony, Inc.

Dates

Publication Date

20260506

Application Date

20231031

Claims (20)

1. 1. An Open Radio Access Network (O-RAN) Radio Unit (O-RU) controller, configured to: obtain a Media Access Control (MAC) address of an O-RU; determine, based on the MAC address of the O-RU, an authentication status of the O-RU; based on determining that the O-RU has been authenticated, establish a channel binding with the O-RU; and based on determining that the O-RU has not been authenticated, isolate the O-RU from further communications with the O-RU controller.
2. 2. The O-RU controller according to claim 1, wherein the authentication status of the O-RU corresponds to an Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) authentication process for the O-RU.
3. 3. The O-RU controller according to claim 1, wherein the O-RU controller is configured to obtain the MAC address of the O-RU by: receiving a vendor certificate from the O-RU, wherein the vendor certificate comprises the MAC address of the O-RU; and extracting the MAC address of the O-RU from the vendor certificate.
4. 4. The O-RU controller according to claim 3, wherein the O-RU controller is configured to receive, from the O-RU during a Transport Layer Security (TLS) Session Establishment Phase, the vendor certificate and a first request for a TLS Client certificate.
5. 5. The O-RU controller according to claim 4, wherein the O-RU controller is further configured to send the TLS Client certificate to the O-RU after the channel binding with the O-RU is established.
6. 6. The O-RU controller according to claim 1, wherein the O-RU controller is configured to obtain the MAC address of the O-RU by: sending a second request for O-RU information to the O-RU, wherein the O-RU information comprises the MAC address of the O-RU; receiving the O-RU information from the O-RU; and extracting the MAC address from the O-RU information.
7. 7. The O-RU controller according to claim 6, wherein O-RU controller is configured to send, to the O-RU during a Network Configuration Protocol (NETCONF) Session Establishment Phase, the second request for the O-RU information.
8. 8. The O-RU controller according to claim 7, wherein the O-RU controller is further configured to: generate, based on the O-RU information, one or more NETCONF configuration information; and I l l send the one or more NETCONF configuration information to the O-RU after the channel binding with the O-RU is established.
9. 9. The O-RU controller according to claim 1, wherein the O-RU controller is configured to determine the authentication status of the O-RU by: obtaining a trusted datastore associated with the O-RU; cross-referencing the MAC address of the O-RU with a plurality of MAC addresses included in the trusted datastore to determine whether or not the MAC address of the 0- RU is included in the plurality of MAC addresses; based on determining that the MAC address of the O-RU is included in the plurality of MAC addresses, determining that the O-RU has been authenticated; and based on determining that the MAC address of the O-RU is not included in the plurality of MAC addresses, determining that the O-RU has not been authenticated.
10. 10. The O-RU controller according to claim 9, wherein the trusted datastore comprises at least one of an authentication list associated with the O-RU and a trust list associated with the O-RU.
11. 11. The O-RU controller according to claim 1, wherein the O-RU controller comprises at least one of an 0-RAN Distributed Unit (0-DU) and a Service Management and Orchestrator (SMO).
12. 12. A method implemented by an Open Radio Access Network (O-RAN) Radio Unit (O-RU) controller, wherein the method comprises: obtaining a Media Access Control (MAC) address of an O-RU; determining, based on the MAC address of the O-RU, an authentication status of the O-RU; based on determining that the O-RU has been authenticated, establishing a channel binding with the O-RU; and based on determining that the O-RU has not been authenticated, isolating the 0- RU from further communications with the O-RU controller.
13. 13. The method according to claim 12, wherein the authentication status of the O-RU corresponds to an Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) authentication process for the O-RU.
14. 14. The method according to claim 12, wherein the obtaining the MAC address of the O-RU comprises: receiving a vendor certificate from the O-RU, wherein the vendor certificate comprises the MAC address of the O-RU; and extracting the MAC address of the O-RU from the vendor certificate.
15. 15. The method according to claim 14, wherein the receiving the vendor certificate comprises: receiving, from the O-RU during a Transport Layer Security (TLS) Session Establishment Phase, the vendor certificate and a first request for a TLS Client certificate.
16. 16. The method according to claim 15, wherein the method further comprises: sending the TLS Client certificate to the O-RU after the channel binding with the O-RU is established.
17. 17. The method according to claim 12, wherein the obtaining the MAC address of the O-RU comprises: sending a second request for O-RU information to the O-RU, wherein the O-RU information comprises a Serial Number of the O-RU and the MAC address of the O-RU; receiving the O-RU information from the O-RU; and extracting the MAC address from the O-RU information.
18. 18. The method according to claim 17, wherein the sending the second request for the O-RU information comprises: sending, to the O-RU during a Network Configuration Protocol (NETCONF) Session Establishment Phase, the second request for the O-RU information.
19. 19. The method according to claim 18, wherein the method further comprises: generating, based on the O-RU information, one or more NETCONF configuration information; and sending the one or more NETCONF configuration information to the O-RU after the channel binding with the O-RU is established.
20. 20. A non-transitory computer-readable recording medium having recorded thereon instructions executable by an Open Radio Access Network (O-RAN) Radio Unit (O-RU) controller to cause the O-RU controller to perform a method comprising: obtaining a Media Access Control (MAC) address of an O-RU; determining, based on the MAC address of the O-RU, an authentication status of the O-RU; based on determining that the O-RU has been authenticated, establishing a channel binding with the O-RU; and based on determining that the O-RU has not been authenticated, isolating the 0- RU from further communications with the O-RU controller.

Description

DETERMINING AUTHENTICATION STATUS INFORMATION OF AN O-RAN RADIO UNIT CROSS REFERENCE TO RELATED APPLICATIONS [0001] This application claims priority to, and incorporates by reference the entirety of the disclosures of, each of the following applications: (a) PCT patent application PCT/US2023/026301, entitled “SYSTEM AND METHOD FOR ADVERTISING SUPPLICANTS IN A NETWORK”, filed on June 27, 2023, and (b) PCT patent application PCT/US2023/026303, entitled “SYSTEM AND METHOD FOR ESTABLISHING A TOPOLOGY FOR ADVERTISING SUPPLICANTS IN A NETWORK”, filed on June 27, 2023. TECHNICAL FIELD [0002] Systems, devices, methods, and computer programs consistent with example embodiments of the present disclosure relate to a telecommunication network, and more specifically, relate to enabling a network entity to determine authentication status information of an Open RAN (O-RAN) Radio Unit (O-RU) in a telecommunication network. BACKGROUND [0003] A Radio Access Network (RAN) is an important component in a telecommunications system, as it connects end-user devices (or user equipment) to other parts of the network. The RAN includes a combination of various network elements (NEs) that connect end-users to a core network. Traditionally, hardware and/or software of a particular RAN is vendor-specific. Open RAN (O-RAN) technology has emerged to enable multiple vendors to provide hardware and/or software to a telecommunications system. Since different vendors are involved, the type 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 NE could be virtualized in software form (e.g., virtual machine (VM)-based, containerized or cloudnative, etc.), or could be in physical hardware form (e.g., non-VM based). [0004] An open fronthaul network of a telecommunications system may be based on the O-RAN architecture. The open fronthaul network may include an O-RAN Radio Unit (O-RU) and an O-RU controller (e.g., an O-RAN Distributed Unit (O-DU), a Service Management and Orchestrator (SMO), etc ). The O-RU controller may provide services or controls to the O-RU, such as establishing a secured communication session, providing information for Network Protocol Configuration (NETCONF), and the like. Multiple O-RUs may be communicatively coupled to one O-RU controller via one or more transport network elements (TNEs), such as router(s), switch(es), and the like. The elements in the open fronthaul network (e.g., O-RUs, TNEs, O-RU controller, etc.) may be collectively referred to as “network entities” herein. [0005] FIG. 1 illustrates a block diagram of an example of a generalized system architecture 100 of an open fronthaul network in the related art. As illustrated in FIG. 1, network entities of the open fronthaul network may include an O-RU 110, a TNE 120, and an O-RU controller 130. The O-RU 110 may be communicatively coupled to the O-RU controller 130 via the TNE 120. The communication among the network entities 110, 120, and 130 may include point-to-point LAN segments/communications. [0006] The network entities may employ an IEEE 802. lx Port-based Network Access Control (PNAC) authentication process (may be referred to as “802. lx process” herein) in order to regulate access to the network, as well as guard against transmission and reception by unidentified or unauthorized parties, and consequent network disruption, theft of service, or data loss. In this regard, the network entities may have a role of either an authenticator or a supplicant. Data traffic is allowed to pass between network entities only if said network entities are authenticated via the 802. lx process. During the 802. lx process, a first network entity (e.g., an 0- RU) may be a supplicant which initiates the 802. lx process and a second network entity (e.g., a TNE) may be an authenticator which controls access of the first network entity to an authentication server that performs the 802. lx process on the first network entity. The 802. lx process may include one or more Extensible Authentication Protocol (EAP)-based processes, such as EAP-Transport Layer Security (EAP-TLS) processes, and the like. [0007] In the related art, authentication status information of a network entity (e.g., information on whether or not the network entity has been authenticated, information defining a trust level between the network entity and another network entity, etc.) is kept locally within the network entities involved in the 802. lx process (e.g., the 0-RU, the TNE, etc.) and is not shared with other network entities (e.g., the 0-RU controller, etc.) that are not involved in the 802. lx process. Instead, the trust is enforced only with the next hop network entity, and other network entities are assumed to be trustworthy if they are chained to or connected to the authenticated and/or authorized network entity. [0008] The above approach for authentication of network entities in