Method and apparatus for remote attestation in zero trust architecture in wireless communication system

Abstract

The present disclosure relates to a 5G communication system or a 6G communication system for supporting higher data rates beyond a 4G communication system such as long term evolution (LTE). A method (2900) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity, is disclosed. The method (2900) includes establishing, by a trust anchor function (560), a communication between a first RAN entity (520) and the trust anchor function (560) based on a nonce message. The method (2900) includes receiving, by the trust anchor function (560), based on the established communication, the at least one proof of evidence from the first RAN entity (520), where the at least one proof of evidence indicates trustworthiness of the first RAN entity. The method (2900) includes determining, by the trust anchor function, an attestation result based on the received at least one proof of evidence. transmitting, by the trust anchor function (560), the attestation result to the first RAN entity (520) wherein the attestation result enables the first RAN entity (520) to maintain a communication with second RAN entity (540) via a plurality of communication channels.

Description

METHOD AND APPARATUS FOR REMOTE ATTESTATION IN ZERO TRUST ARCHITECTURE IN WIRELESS COMMUNICATION SYSTEM

[0001] The present invention generally relates to a remote attestation framework, and more particularly relates to a system and a method for security and integrity of a Radio Access Network (RAN) in virtualized and untrusted environment deployments.

[0002] Considering the development of wireless communication from generation to generation, the technologies have been developed mainly for services targeting humans, such as voice calls, multimedia services, and data services. Following the commercialization of 5G (5th generation) communication systems, it is expected that the number of connected devices will exponentially grow. Increasingly, these will be connected to communication networks. Examples of connected things may include vehicles, robots, drones, home appliances, displays, smart sensors connected to various infrastructures, construction machines, and factory equipment. Mobile devices are expected to evolve in various form-factors, such as augmented reality glasses, virtual reality headsets, and hologram devices. In order to provide various services by connecting hundreds of billions of devices and things in the 6G (6th generation) era, there have been ongoing efforts to develop improved 6G communication systems. For these reasons, 6G communication systems are referred to as beyond-5G systems.

[0003] 6G communication systems, which are expected to be commercialized around 2030, will have a peak data rate of tera (1,000 giga)-level bit per second (bps) and a radio latency less than 100μsec, and thus will be 50 times as fast as 5G communication systems and have the 1 / 10 radio latency thereof.

[0004] In order to accomplish such a high data rate and an ultra-low latency, it has been considered to implement 6G communication systems in a terahertz (THz) band (for example, 95 gigahertz (GHz) to 3THz bands). It is expected that, due to severer path loss and atmospheric absorption in the terahertz bands than those in mmWave bands introduced in 5G, technologies capable of securing the signal transmission distance (that is, coverage) will become more crucial. It is necessary to develop, as major technologies for securing the coverage, Radio Frequency (RF) elements, antennas, novel waveforms having a better coverage than Orthogonal Frequency Division Multiplexing (OFDM), beamforming and massive Multiple-input Multiple-Output (MIMO), Full Dimensional MIMO (FD-MIMO), array antennas, and multiantenna transmission technologies such as large-scale antennas. In addition, there has been ongoing discussion on new technologies for improving the coverage of terahertz-band signals, such as metamaterial-based lenses and antennas, Orbital Angular Momentum (OAM), and Reconfigurable Intelligent Surface (RIS).

[0005] Moreover, in order to improve the spectral efficiency and the overall network performances, the following technologies have been developed for 6G communication systems: a full-duplex technology for enabling an uplink transmission and a downlink transmission to simultaneously use the same frequency resource at the same time; a network technology for utilizing satellites, High-Altitude Platform Stations (HAPS), and the like in an integrated manner; an improved network structure for supporting mobile base stations and the like and enabling network operation optimization and automation and the like; a dynamic spectrum sharing technology via collision avoidance based on a prediction of spectrum usage; an use of Artificial Intelligence (AI) in wireless communication for improvement of overall network operation by utilizing AI from a designing phase for developing 6G and internalizing end-to-end AI support functions; and a next-generation distributed computing technology for overcoming the limit of UE computing ability through reachable super-high-performance communication and computing resources (such as Mobile Edge Computing (MEC), clouds, and the like) over the network. In addition, through designing new protocols to be used in 6G communication systems, developing mechanisms for implementing a hardware-based security environment and safe use of data, and developing technologies for maintaining privacy, attempts to strengthen the connectivity between devices, optimize the network, promote softwarization of network entities, and increase the openness of wireless communications are continuing.

[0006] It is expected that research and development of 6G communication systems in hyper-connectivity, including person to machine (P2M) as well as machine to machine (M2M), will allow the next hyper-connected experience. Particularly, it is expected that services such as truly immersive eXtended Reality (XR), high-fidelity mobile hologram, and digital replica could be provided through 6G communication systems. In addition, services such as remote surgery for security and reliability enhancement, industrial automation, and emergency response will be provided through the 6G communication system such that the technologies could be applied in various fields such as industry, medical care, automobiles, and home appliances.

[0007] The present disclosure relates to systems and methods for remote attestation in zero trust architecture in radio access network in a wireless communication system.

[0008] According to an aspect of an exemplary embodiment, there is provided a communication method in a wireless communication system.

[0009] Aspects of the present disclosure provide efficient communication methods in a wireless communication system.

[0010] These and other features, aspects, and advantages of the present invention will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:

[0011] Figure 1 illustrates an example scenario 100 depicting an environment for attestation, according to a conventional technique;

[0012] Figure 2 illustrates an example scenario including a plurality of radio access network (RAN) entities within a virtualized and / or untrusted RAN environment, according to a conventional technique;

[0013] Figure 3 illustrates another scenario depicting various attacks due to virtualization and cloudification, according to a conventional technique;

[0014] Figure 3 illustrates an example scenario of a Trusted Execution Environment (TEE), a Trusted Platform Module (TPM), and a Hardware Secure Module (HSM), according to a conventional technique;

[0015] Figure 4 illustrates an exemplary implementation of zero-trust process using trusted hardware-based attestation mechanisms, in accordance with prior art;

[0016] Figure 5 illustrates a wireless communication network for the implementation of remote attestation in a zero-trust architecture in a RAN entity, according to an embodiment of the present disclosure;

[0017] Figure 6 illustrates an exemplary environment including systems for remote attestation in the zero-trust architecture in the RAN entity, in accordance with an embodiment of the present disclosure, according to an embodiment of the present disclosure;

[0018] Figure 7 illustrates a sequence of operations depicting an attestation process among different RAN entities for secure on-boarding, service provisioning, for example, key and certificates provisioning etc, according to an embodiment of the present disclosure;

[0019] Figure 8 illustrates a sequence of operations corresponding to remote attestation between a first entity, i.e., a RU and second RAN entity, i.e., a DU, via the trust anchor function according to an embodiment of the present disclosure;

[0020] Figure 9A illustrates systems depicting zero trust architecture in a first RAN entity and second RAN entity, according to an embodiment of the present disclosure;

[0021] Figure 9B illustrates an architecture depicting zero trust architecture between the first RAN entity and the second RAN entity (mid-haul) via a background check model, according to an embodiment of the present disclosure;

[0022] Figure 9C illustrates an architecture depicting zero trust architecture between the first RAN entity and the second RAN entity (mid-haul) via a passport model, according to an embodiment of the present disclosure;

[0023] Figure 10 illustrates a sequence of operations depicting the attestation process between the first RAN entity and the second RAN entity via the F1 setup request, according to an embodiment of the present disclosure;

[0024] Figure 11 illustrates a sequence of operations depicting the attestation process between the first RAN entity and the second RAN entity via a new message;

[0025] Figure 12 illustrates a sequence of operations depicting the attestation process between the first RAN entity and the second RAN entity via the passport model, according to an embodiment of the present disclosure;

[0026] Figure 13 illustrates a sequence of operations depicting the attestation process between the first RAN entity and the second RAN entity via IP sec / DTLS / TLS, according to an embodiment of the present disclosure;

[0027] Figure 14A illustrates systems depicting zero trust architecture in the first RAN entity and the second RAN entity (backhaul) via the trust anchor function, according to an embodiment of the present disclosure;

[0028] Figure 14B illustrates an architecture depicting zero trust architecture between the first RAN entity and the second RAN entity (backhaul) via the background check model, according to an embodiment of the present disclosure;

[0029] Figure 14C illustrates an architecture depicting zero trust architecture between the first RAN entity and the second RAN entity (backhaul) via the passport model, according to an embodiment of the present disclosure;

[0030] Figure 15 illustrates a sequence of operations depicting the attestation process between the first RAN entity, i.e., the CU and the second RAN entity, i.e., core network via a NG setup request in the background check model;

[0031] Figure 16 illustrates a sequence of operations depicting the attestation process between the first RAN entity, i.e., the CU and the second RAN entity, i.e., the core network via a new message;

[0032] Figure 17 illustrates a sequence of operations depicting the attestation process between the first RAN entity, i.e., the CU and the second RAN entity, i.e., the core network via the passport model, according to an embodiment of the present disclosure;

[0033] Figure 18 illustrates a sequence of operations depicting the attestation process between the first RAN entity and the second RAN entity via IP sec / DTLS / TLS, according to an embodiment of the present disclosure;

[0034] Figure 19A illustrates systems depicting zero trust architecture in the first RAN entity and the second RAN entity (fronthaul) via the trust anchor function, according to an embodiment of the present disclosure;

[0035] Figure 19B illustrates an architecture depicting zero trust architecture between the first RAN entity and the second RAN entity (fronthaul) via the background check model, according to an embodiment of the present disclosure;

[0036] Figure 19C illustrates an architecture depicting zero trust architecture between the first RAN entity and the second RAN entity (fronthaul) via the passport model, according to an embodiment of the present disclosure;

[0037] Figure 20 illustrates a sequence of operations depicting the attestation process between the first RAN entity, i.e., a RU and second RAN entity, i.e., DU via a F2 setup request in the background check model, according to an embodiment of the present disclosure;

[0038] Figure 21 illustrates a sequence of operations depicting the attestation process between the first RAN entity i.e., the RU and the second RAN entity, i.e., the DU via a new message, according to an embodiment of the present disclosure;

[0039] Figure 22 illustrates a sequence of operations depicting the attestation process between the first RAN entity i.e., the RU and the second RAN entity, i.e., the DU via the passport model, according to an embodiment of the present disclosure;

[0040] Figure 23 illustrates a sequence of operations depicting the attestation process between the first RAN entity, i.e., the RU and the second RAN entity, i.e., the DU via IP sec / DTLS / TLS, according to an embodiment of the present disclosure;

[0041] Figure 24A illustrates systems depicting zero trust architecture in the first RAN entity and the second RAN entity via the trust anchor function, according to an embodiment of the present disclosure;

[0042] Figure 24B illustrates an architecture depicting zero trust architecture between the first RAN entity and the second RAN entity via the background check model, according to an embodiment of the present disclosure;

[0043] Figure 24C illustrates an architecture depicting zero trust architecture between the first RAN entity and the second RAN entity via the passport model, according to an embodiment of the present disclosure;

[0044] Figure 25 illustrates a sequence of operations depicting the attestation process between the first RAN entity, i.e., the first NG-RAN node and the second RAN entity, i.e., the second NG-RAN node via the XN setup request in the background check model, according to an embodiment of the present disclosure;

[0045] Figure 26 illustrates a sequence of operations depicting the attestation process between the first RAN entity i.e., a first NG-RAN node and the second RAN entity, i.e., a second NG-RAN node via a new message, according to an embodiment of the present disclosure;

[0046] Figure 27 illustrates a sequence of operations depicting the attestation process between the first RAN entity i.e., the first NG-RAN node and the second RAN entity, i.e., the second NG-RAN node via the passport model, according to an embodiment of the present disclosure;

[0047] Figure 28 illustrates a sequence of operations depicting the attestation process between the first RAN entity i.e., the first NG-RAN node and the second RAN entity, i.e., the second NG-RAN node via IP sec / DTLS / TLS, according to an embodiment of the present disclosure;

[0048] Figure 29 illustrates a flow chart performed by the system corresponding to the trust anchor function as discussed in Figure 6, according to an embodiment of the present disclosure;

[0049] Figure 30 illustrates a flow chart performed by the system corresponding to the first RAN entity as discussed in Figure 6, according to an embodiment of the present disclosure;

[0050] Figure 31 illustrates a flow chart performed by the system corresponding to the trust anchor function as discussed in Figures 9A-9C, 14A-14C, 19A-19C, and 24A-24C, according to an embodiment of the present disclosure;

[0051] Figure 32 illustrates a flow chart performed by the system corresponding to the first RAN entity as discussed in Figures 9A-24C, according to an embodiment of the present disclosure;

[0052] Figure 33 illustrates a flow chart performed by the system corresponding to the first RAN entity as discussed in Figures 9A-9C, according to an embodiment of the present disclosure;

[0053] Figure 34 illustrates a flow chart performed by the system corresponding to the first RAN entity as discussed in Figures 14A-14C, according to an embodiment of the present disclosure;

[0054] Figure 35 illustrates a flow chart performed by the system corresponding to the first RAN entity as discussed in Figures 19A-19C, according to an embodiment of the present disclosure; and

[0055] Figure 36 illustrates a flow chart performed by the system corresponding to the first RAN entity as discussed in Figures 24A-24C, according to an embodiment of the present disclosure.

[0056] Figure 37 illustrates a block diagram of a user equipment, according to embodiments of the present disclosure.

[0057] Figure 38 illustrates a block diagram of a base station, according to embodiments of the present disclosure.

[0058] Figure 39 illustrates a block diagram of a network entity, according to embodiments of the present disclosure.

[0059] Further, skilled artisans will appreciate that elements in the drawings are illustrated for simplicity and may not have necessarily been drawn to scale. For example, the flow charts illustrate the method in terms of the most prominent steps involved to help to improve understanding of aspects of the present invention. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the drawings with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

[0060] This summary is provided to introduce a selection of concepts, in a simplified format, that are further described in the detailed description of the invention. This summary is neither intended to identify key or essential inventive concepts of the invention and nor is it intended for determining the scope of the invention.

[0061] The present disclosure discloses a system for remote attestation in zero-trust architecture in a Radio Access Network (RAN) entity. The system includes a memory and a processor in communication with the memory. The processor is configured to establish a communication between a first RAN entity and the trust anchor function based on a nonce message. The processor is configured to receive, based on the established communication, the at least one proof of evidence from the first RAN entity. The at least one proof of evidence indicates trustworthiness of the first RAN entity. The processor is configured to determine an attestation result based on the received at least one proof of evidence. The processor is configured to transmit the attestation result to the first RAN entity. The attestation result enables the first RAN entity to maintain a communication with second RAN entity via a plurality of communication channels.

[0062] In another embodiment, a system for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is disclosed. The system includes a memory and a processor in communication with the memory. The processor is configured to enable certificate retrieval of a first RAN entity using a User-based Security Model (USM). The processor is configured to receive at least one proof of evidence from an attester. The at least one proof of evidence indicates trustworthiness of the first RAN entity. The processor is configured to transmit, to a trust anchor function, the at least one proof of evidence. In response to the transmitted at least one proof of evidence, the processor is configured to receive an attestation result from the trust anchor function. The attestation result enables the first RAN entity to maintain a communication with second RAN entity based on a provisioning of the certificate.

[0063] In yet another embodiment, a system for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is disclosed. The system includes a memory and a processor in communication with the memory. The processor is configured to establish a communication between the trust anchor function and a first RAN entity based on a nonce request setup message. The processor is configured to receive at least one proof of evidence from the first Radio Access Network (RAN) entity in a request_for_attestation (attestation_quote) message. The at least one proof of evidence indicates trustworthiness of the first RAN entity. The processor is configured to determine an attestation result based on the received at least one proof of evidence. The processor is configured to transmit the attestation result to the first RAN entity in an attestation_response message. The attestation result enables the first RAN entity to maintain a communication with second RAN entity.

[0064] In yet another embodiment, a system for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is disclosed. The system includes a memory and a processor in communication with the memory. The processor is configured to transmit, to a trust anchor function, at least one proof of evidence in one of a F1 setup request message and an attestation_request message. The at least one proof of evidence indicates trustworthiness of the first RAN entity. In response to the transmitted at least one proof of evidence, the processor is configured to receive an attestation result from the trust anchor function in one of a F1 setup response / failure message and an attestation_response message. The attestation result enables the first RAN entity to maintain a communication with second RAN entity.

[0065] In yet another embodiment, a system for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is disclosed. The system includes a memory and a processor in communication with the memory. The processor is configured to transmit, to a trust anchor function, at least one proof of evidence in one of a NG setup request message and an attestation_request message. The at least one proof of evidence indicates trustworthiness of the first RAN entity. In response to the transmitted at least one proof of evidence, the processor is configured to receive an attestation result from the trust anchor function in a NG setup response / failure message. The attestation result enables the first RAN entity to maintain a communication with second RAN entity.

[0066] In yet another embodiment, a system for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is disclosed. The system includes a memory and a processor in communication with the memory. The processor is configured to transmit, to a trust anchor function, at least one proof of evidence in one of a F2 setup request message and an attestation_request message. The at least one proof of evidence indicates trustworthiness of the first RAN entity. In response to the transmitted at least one proof of evidence, the processor is configured to receive, an attestation result from the trust anchor function in a F2 setup response / failure message. The attestation result enables the first RAN entity to maintain a communication with second RAN entity.

[0067] In yet another embodiment, a system for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is disclosed. The system includes a memory and a processor in communication with the memory. The processor is configured to transmit, to a trust anchor function, at least one proof of evidence in one of a XN setup request message and an attestation_request message. The at least one proof of evidence indicates trustworthiness of the first RAN entity. In response to the transmitted at least one proof of evidence, the processor is configured to receive an attestation result from the trust anchor function in a XN setup response / failure message. The attestation result enables the first RAN entity to maintain communication with second RAN entity.

[0068] In yet another embodiment, a method for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity, is disclosed. The method includes establishing, by a trust anchor function, a communication between a first RAN entity and the trust anchor function based on a nonce message. The method includes receiving, by the trust anchor function, based on the established communication, the at least one proof of evidence from the first RAN entity. The at least one proof of evidence indicates trustworthiness of the first RAN entity. The method includes determining, by the trust anchor function, an attestation result based on the received at least one proof of evidence. The method includes transmitting, by the trust anchor function, the attestation result to the first RAN entity wherein the attestation result enables the first RAN entity to maintain a communication with second RAN entity via a plurality of communication channels.

[0069] In yet another embodiment, a method for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity, is disclosed. The method includes enabling certificate retrieval of a first RAN entity using a User-based Security Model (USM). The method includes receiving, by the first RAN entity, at least one proof of evidence from an attester. The at least one proof of evidence indicates trustworthiness of the first RAN entity. The method includes transmitting, to a trust anchor function, the at least one proof of evidence. In response to the transmitted at least one proof of evidence, the method includes receiving, by the first RAN entity, an attestation result from the trust anchor function. The attestation result enables the first RAN entity to maintain a communication with second RAN entity based on a provisioning of the certificate.

[0070] In yet another embodiment, a method for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity, is disclosed. The method includes establishing, by a trust anchor function, a communication between the trust anchor function and a first RAN entity based on a nonce request setup message. The method includes receiving, by the trust anchor function, at least one proof of evidence from the first Radio Access Network (RAN) entity in a request_for_attestation (attestation_quote) message. The at least one proof of evidence indicates trustworthiness of the first RAN entity. The method includes determining, by the trust anchor function, an attestation result based on the received at least one proof of evidence. The method includes transmitting, by the trust anchor function, the attestation result to the first RAN entity in an attestation_response message. The attestation result enables the first RAN entity to maintain a communication with second RAN entity.

[0071] In yet another embodiment, a method for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity, is disclosed. The method includes transmitting, to a trust anchor function, at least one proof of evidence in one of a F1 setup request message and an attestation_request message. The at least one proof of evidence indicates trustworthiness of the first RAN entity. In response to the transmitted at least one proof of evidence, the method includes receiving, by the first RAN entity,, an attestation result from the trust anchor function in one of a F1 setup response / failure message and an attestation_response message. The attestation result enables the first RAN entity to maintain a communication with second RAN entity.

[0072] In yet another embodiment, a method for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity, is disclosed. The method includes transmitting to a trust anchor function, at least one proof of evidence in one of a NG setup request message and an attestation_request message. The at least one proof of evidence indicates trustworthiness of the first RAN entity. In response to the transmitted at least one proof of evidence, the method includes receiving, by the first RAN entity, an attestation result from the trust anchor function, in a NG setup response / failure message. The attestation result enables the first RAN entity to maintain a communication with second RAN entity.

[0073] In yet another embodiment, a method for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity, is disclosed. The method includes transmitting, to a trust anchor function, at least one proof of evidence in one of a F2 setup request message and an attestation_request message. The at least one proof of evidence indicates trustworthiness of the first RAN entity. In response to the transmitted at least one proof of evidence, the method includes receiving, by the first RAN entity, an attestation result from the trust anchor function in a F2 setup response / failure message. The attestation result enables the first RAN entity to maintain a communication with second RAN entity.

[0074] In yet another embodiment, a method for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity, is disclosed. The method includes transmitting to a trust anchor function, at least one proof of evidence in one of a XN setup request message and an attestation_request message. The at least one proof of evidence indicates trustworthiness of the first RAN entity. In response to the transmitted at least one proof of evidence, the method includes receiving, by the first RAN entity, an attestation result from the trust anchor function in a XN setup response / failure message. The attestation result enables the first RAN entity to maintain communication with second RAN entity.

[0075] To further clarify the advantages and features of the present invention, a more particular description of the invention will be rendered by reference to specific embodiments thereof, which is illustrated in the appended drawings. It is appreciated that these drawings depict only typical embodiments of the invention and are therefore not to be considered limiting of its scope. The invention will be described and explained with additional specificity and detail with the accompanying drawings.

[0076] Hereinafter, embodiments of the disclosure will be described in detail with reference to the accompanying drawings.

[0077] In describing the embodiments, descriptions related to technical contents well-known in the art and not associated directly with the disclosure will be omitted. Such an omission of unnecessary descriptions is intended to prevent obscuring of the main idea of the disclosure and more clearly transfer the main idea.

[0078] For the same reason, in the accompanying drawings, some elements may be exaggerated, omitted, or schematically illustrated. Further, the size of each element does not completely reflect the actual size. In the drawings, identical or corresponding elements are provided with identical reference numerals or different reference numerals.

[0079] The advantages and features of the disclosure and ways to achieve them will be apparent by making reference to embodiments as described below in detail in conjunction with the accompanying drawings. However, the disclosure is not limited to the embodiments set forth below, but may be implemented in various different forms. The following embodiments are provided only to completely disclose the disclosure and inform those skilled in the art of the scope of the disclosure, and the disclosure is defined only by the scope of the appended claims. Throughout the specification, the same or like reference numerals designate the same or like elements. Furthermore, in describing the disclosure, a detailed description of known functions or constitution incorporated herein will be omitted in the case that it is determined that the description may make the subject matter of the disclosure unnecessarily unclear. The terms which will be described below are terms defined in consideration of the functions in the disclosure, and may be different according to users, intentions of the operators, or customs. Therefore, the definitions of the terms should be made based on the contents throughout the specification.

[0080] Herein, it will be understood that each block of the flowchart illustrations, and combinations of blocks in the flowchart illustrations, may be performed based on computer program instructions. These computer program instructions may be loaded collectively onto at least one processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which perform through any one of, or in any combination of, the at least one processor of the computer or other programmable data processing apparatus, create means for performing the functions specified in the flowchart block(s). These computer program instructions may also be stored in a non-transitory computer usable or computer-readable memory that may direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer usable or computer-readable memory produce an article of manufacture including instruction means that perform the function specified in the flowchart block(s). The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable data processing apparatus to produce a computer executed process such that the instructions that perform on the computer or other programmable data processing apparatus provide steps for executing the functions specified in the flowchart block(s).

[0081] Further, each block may represent a module, segment, or portion of code, which includes one or more executable instructions for executing the specified logical function(s). It should also be noted that in some alternative implementations, the functions noted in the blocks may occur out of the order. For example, two blocks(or functions) shown in succession may in fact be performed substantially concurrently or the blocks may sometimes be performed in the reverse order, depending upon the functionality involved.

[0082] As used in embodiments of the disclosure, a "~unit" may refer to a software element or a hardware element, such as a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC), which performs a predetermined function. However, the term including the word "~unit" does not always have a meaning limited to software or hardware. The "~unit" may be constructed either to be stored in an addressable storage medium or to execute one or more processors. Therefore, the "~unit" includes, for example, software elements, object-oriented software elements, components such as class elements and task elements, processes, functions, properties, procedures, sub-routines, segments of a program code, drivers, firmware, micro-codes, circuits, data, database, data structures, tables, arrays, and parameters. The components and functions provided by the "~unit" may be either combined into a smaller number of components and a "~unit," or divided into additional components and a "~unit." Moreover, the components and "~units" may be implemented to reproduce one or more central processing units (CPUs) within a device or a security multimedia card. Further, in the embodiments, the "~unit" may include one or more processors.

[0083] It should be appreciated that the blocks in each flowchart and combinations of the flowcharts may be performed by one or more computer programs which include instructions. The entirety of the one or more computer programs may be stored in a single memory device or the one or more computer programs may be divided with different portions stored in different multiple memory devices.

[0084] Any of the functions or operations described herein can be processed by one processor or a combination of processors. The one processor or the combination of processors is circuitry performing processing and includes circuitry like an application processor (AP, e.g. a CPU), a communication processor (CP, e.g., a modem), a graphics processing unit (GPU), a neural processing unit (NPU) (e.g., an artificial intelligence (AI) chip), a Wi-Fi chip, a Bluetooth® chip, a global positioning system (GPS) chip, a near field communication (NFC) chip, connectivity chips, a sensor controller, a touch controller, a finger-print sensor controller, a display driver integrated circuit (IC), an audio CODEC chip, a universal serial bus (USB) controller, a camera controller, an image processing IC, a microprocessor unit (MPU), a system on chip (SoC), an IC, or the like.

[0085] It will be appreciated that various embodiments of the disclosure according to the claims and description in the specification can be realized in the form of hardware, software or a combination of hardware and software.

[0086] Any such software may be stored in non-transitory computer readable storage media. The non-transitory computer readable storage media store one or more computer programs (software modules), the one or more computer programs include computer-executable instructions that, when executed by one or more processors of an electronic device individually or collectively, cause the electronic device to perform a method of the disclosure.

[0087] Any such software may be stored in the form of volatile or non-volatile storage such as, for example, a storage device like read only memory (ROM), whether erasable or rewritable or not, or in the form of memory such as, for example, random access memory (RAM), memory chips, device or integrated circuits or on an optically or magnetically readable medium such as, for example, a compact disk (CD), digital versatile disc (DVD), magnetic disk or magnetic tape or the like. It will be appreciated that the storage devices and storage media are various embodiments of non-transitory machine-readable storage that are suitable for storing a computer program or computer programs comprising instructions that, when executed, implement various embodiments of the disclosure. Accordingly, various embodiments of the present disclosure may provide a program comprising code for implementing apparatus or a method as claimed in any one of the claims of this specification and a non-transitory machine-readable storage storing such a program.

[0088] Hereinafter, the determination of priority between A and B in the present disclosure may refer to various actions such as selecting the one having a higher priority based on a predefined priority rule and performing an operation corresponding thereto, or omitting or dropping an operation corresponding to the one having a lower priority.

[0089] Hereinafter, "A or B" as described in the present disclosure may be understood as "A and / or B," which may include A, or B, or both A and B.

[0090] In addition, "at least one of A, B, and C" as described in the present disclosure may be understood to include A, or B, or C, or any combination of A, B, and C.

[0091] In addition, "at least one of A, B, or C" as described in the present disclosure may be understood to include A, or B, or C, or any combination of A, B, and C.

[0092] Furthermore, "A / B" as described in the present disclosure may be understood as "A and / or B," which may include A, or B, or both A and B.

[0093] Furthermore, "A, B" as described in the present disclosure may be understood as "A and / or B," which may include A, or B, or both A and B.

[0094] Furthermore, "A and B" as described in the present disclosure may be understood as "A and / or B," which may include A, or B, or both A and B.

[0095] Furthermore, "if condition A and condition B are satisfied," as described in the present disclosure, may not be limited to a case where both condition A and condition B are satisfied, but may be understood to include a case where either condition A or condition B is individually satisfied, both condition A and condition B are satisfied, or one or more additional conditions are satisfied in combination.

[0096] Furthermore, throughout this disclosure, ordinal terms such as "first," "second," "third," etc., (and similar qualifiers) are used merely to distinguish between different instances, occurrences, configurations, messages, stages, or aspects of elements, operations, or information as described herein. Unless the context clearly dictates otherwise, the use of such ordinal terms does not itself require that the elements, operations, or information distinguished by these terms be structurally different, numerically distinct, or substantively dissimilar. For example, a "first signal" and a "second signal" may refer to instances of the same signal transmitted at different times or containing the same core information despite minor variations, or they may refer to signals with different content or characteristics, depending on the specific context. Similarly, a "first value" and a "second value" may represent the same magnitude but measured or applied in different circumstances, or they may represent different magnitudes. The interpretation should be guided by the specific technical context, function, and relationship described in the relevant portion of the specification and claims.

[0097] Furthermore, the terms "first ~", "second ~", etc., as described in the present disclosure with respect to various elements (e.g., information, objects, operation, sequences, or the like), should not limit those elements. These terms may only be intended to distinguish one element from another, and may not be intended to indicate a specific order. For example, a first element could be termed a second element, and, similarly, a second element could be termed a first element.

[0098] Furthermore, even if "first ~" and "second ~" are described in the present disclosure, it may be understood that element(s) referred to by "first ~" and "second ~" may be the same or different. For example, in case of element(s) being information, first information and second information may both be same information and, in some cases, are separate and different information.

[0099] In addition, the terms "if ~" and "in case that ~" as used in the disclosure or claims may be interpreted to include the meanings of "when (or upon) ~," "in response to ~," "based on ~," or "according to ~," and may be used interchangeably with these expressions. In addition, expressions other than those exemplified herein may also be used, as long as they have substantially the same meaning and do not impair the technical features of the present disclosure.

[0100] For example, the physical layer signaling may be referred to as Layer 1 (L1) signaling and may include downlink control information (DCI). In addition, the higher layer signaling may include a medium access control (MAC) control message, a radio resource control (RRC) signaling message, a non-access stratum (NAS) signaling message, or an application layer message. The RRC signaling message may be referred to as L3 (layer 3) signaling. It should be noted, however, that the higher layer signaling is not limited to the aforementioned examples.

[0101] In addition, the term "not perform" as used in the present disclosure or claims may, in context, be understood to mean that the corresponding step is omitted or skipped. Such a term may be replaced with other terms having the same or substantially equivalent meaning.

[0102] In addition, "transmitting a message including A and B" as described in the present disclosure, may be understood as encompassing both (i) transmitting A and B in a single message, and (ii) transmitting A and B separately via multiple messages (e.g., transmitting a first message including A and a second message including B). This interpretation may also apply to messages that include two or more items (e.g., A, B, C), transmitted either together or separately.

[0103] In addition, "transmitting a message including A and transmitting a message including B" may also be interpreted as transmitting a message including A and B in a single message.

[0104] In the specific embodiments of the present disclosure described below, terms or components included in the disclosure may be expressed in singular or plural form depending on the specific embodiments presented. However, such singular or plural expressions are selected appropriately for convenience of description, and the present disclosure is not limited to a singular or plural number of components. A component expressed in the plural form may be implemented as a single component, and a component expressed in the singular form may be implemented as multiple components.

[0105] The drawings or flowcharts described below illustrate exemplary methods that may be implemented according to the principles of the present disclosure, and various modifications may be made to the methods illustrated in the flowcharts of the present disclosure. For example, although illustrated as a series of steps, various steps in each drawing or flowchart may overlap, occur in parallel, occur in a different order, or be repeated. In other examples, any step may be omitted or replaced with another step.

[0106] The methods and apparatuses proposed in the embodiments of the present disclosure are not limited to each embodiment individually, but may also be applied in combination of all or some of the embodiments proposed in the disclosure. Therefore, the embodiments of the present disclosure may be modified and applied without significantly departing from the scope of the present disclosure, as would be understood by those skilled in the art.

[0107] In this case, even if certain wordings are described differently across embodiments, they may be used interchangeably or in substitution or in combination if their underlying concepts are equivalent. For example, for the same or equivalent concept, even if one embodiment uses the expression "A" and another embodiment uses the expression "B", such expressions may be understood interchangeably, in substitution, or in combination.

[0108] The terms used in the following description to refer to access nodes, network entities, messages, interfaces between network entities, various types of identification information, and the like, are provided merely for the convenience of explanation by way of example. Therefore, the present disclosure is not limited to the terms described below, and other terms having equivalent technical meanings may also be used. Such terms may also be interchangeable with terms defined in any 3rd generation partnership project (3GPP) technical specifications (TS) where appropriate.

[0109] Hereinafter, a base station is an entity that allocates resources to terminals, and may be at least one of a gNode B, an eNode B, a Node B, a base station (BS), a wireless access unit, a BS controller, or a node on a network.

[0110] Furthermore, the base station of the present disclosure may include a split architecture comprising a central unit (CU) and a distributed unit (DU). In this structure, the CU is configured to process the higher layers of the control and user planes, while the DU is configured to process lower-layer radio resource functions. The embodiments of the present disclosure may be equally applicable to 5G base station architectures in which such CU and DU functional splits are implemented.

[0111] A terminal may include a UE, a mobile station (MS), a cellular phone, a smartphone, a computer, or a multimedia system capable of performing communication functions.

[0112] In the disclosure, a downlink (DL) refers to a radio link through which a BS transmits a signal to a UE, and an uplink (UL) refers to a radio link through which a UE transmits a signal to a BS.

[0113] Furthermore, hereinafter, 5th generation (5G) mobile communication technologies (e.g., 5G new radio (NR)), 6th generation (6G) mobile communication technologies may be described by way of example, but the embodiments of the present disclosure may also be applied to other communication systems having similar technical backgrounds or channel types. For example, newly evolved mobile communication systems developed after 5G and 6G may be included. Furthermore, based on determinations by those skilled in the art, the embodiments of the present disclosure may also be applied to other communication systems (e.g., Wi-Fi systems) through some modifications without significantly departing from the scope of the present disclosure

[0114] In the following description, the terms physical channel and signal may be used interchangeably with data or control signal. For example, the term physical downlink shared channel (PDSCH) refers to a physical channel through which data is transmitted, but the term PDSCH may also be used to refer to the data itself. That is, in the present disclosure, the expression "transmit a physical channel" may be interpreted as being equivalent to the expression "transmit data or a signal via a physical channel."

[0115] Hereinafter, in the context of the present disclosure, higher layer signaling may refer to signaling corresponding to at least one or any combination of the following: master information block (MIB), system information block (SIB) or SIB M (M = 1, 2, ...), radio resource control (RRC), or medium access control (MAC) control element (CE), or a non-access stratum (NAS) signaling message, or an application layer message. The RRC signaling message may be referred to as L3 (layer 3) signaling.

[0116] In addition, L1 signaling may refer to signaling corresponding to at least one or any combination of signaling techniques using the at least one or any combination of the following physical layer channels or signaling: physical downlink control channel (PDCCH), downlink control information (DCI), user equipment (UE)-specific DCI, group-common DCI, common DCI, scheduling DCI (e.g., DCI used for scheduling downlink or uplink data), non-scheduling DCI (e.g., DCI not used for scheduling downlink or uplink data) physical uplink control channel (PUCCH), or uplink control information (UCI). The L1 signaling message may be referred to as a physical layer signaling.

[0117] Hereinafter, the expression that information is configured by the BS, as used in the present disclosure or claims, may, in context, be understood to mean that the terminal receives the corresponding information from the BS via a physical layer signaling or a higher layer signaling. Such an expression may be replaced with other terms having the same or substantially equivalent meaning.

[0118] Hereinafter, the operational principle of the present disclosure will be described in detail with reference to the accompanying drawings.

[0119] For the purpose of promoting an understanding of the principles of the invention, reference will now be made to the various embodiments and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended, such alterations and further modifications in the illustrated system, and such further applications of the principles of the invention as illustrated therein being contemplated as would normally occur to one skilled in the art to which the invention relates.

[0120] It will be understood by those skilled in the art that the foregoing general description and the following detailed description are explanatory of the invention and are not intended to be restrictive thereof.

[0121] Whether or not a certain feature or element was limited to being used only once, it may still be referred to as "one or more features" or "one or more elements" or "at least one feature" or "at least one element." Furthermore, the use of the terms "one or more" or "at least one" feature or element does not preclude there being none of that feature or element, unless otherwise specified by limiting language including, but not limited to, "there needs to be one or more..." or "one or more elements is required."

[0122] Reference is made herein to some "embodiments." It should be understood that an embodiment is an example of a possible implementation of any features and / or elements of the present disclosure. Some embodiments have been described for the purpose of explaining one or more of the potential ways in which the specific features and / or elements of the proposed disclosure fulfill the requirements of uniqueness, utility, and non-obviousness.

[0123] Use of the phrases and / or terms including, but not limited to, "a first embodiment," "a further embodiment," "an alternate embodiment," "one embodiment," "an embodiment," "multiple embodiments," "some embodiments," "other embodiments," "further embodiment", "furthermore embodiment", "additional embodiment" or other variants thereof do not necessarily refer to the same embodiments. Unless otherwise specified, one or more particular features and / or elements described in connection with one or more embodiments may be found in one embodiment, or may be found in more than one embodiment, or may be found in all embodiments, or may be found in no embodiments. Although one or more features and / or elements may be described herein in the context of only a single embodiment, or in the context of more than one embodiment, or in the context of all embodiments, the features and / or elements may instead be provided separately or in any appropriate combination or not at all. Conversely, any features and / or elements described in the context of separate embodiments may alternatively be realized as existing together in the context of a single embodiment.

[0124] Any particular and all details set forth herein are used in the context of some embodiments and therefore should not necessarily be taken as limiting factors to the proposed disclosure.

[0125] The terms "comprises", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process or method that comprises a list of steps does not include only those steps but may include other steps not expressly listed or inherent to such process or method. Similarly, one or more devices or sub-systems or elements or structures or components proceeded by "comprises... a" does not, without more constraints, preclude the existence of other devices or other sub-systems or other elements or other structures or other components or additional devices or additional sub-systems or additional elements or additional structures or additional components.

[0126] The term "couple" and the derivatives thereof refer to any direct or indirect communication between two or more elements, whether or not those elements are in physical contact with each other. The terms "transmit", "receive", and "communicate" as well as the derivatives thereof encompass both direct and indirect communication. The term "or" is an inclusive term meaning "and / or". The phrase "associated with," as well as derivatives thereof, refer to include, be included within, interconnect with, contain, be contained within, connect to or with, couple to or with, be communicable with, cooperate with, interleave, juxtapose, be proximate to, be bound to or with, have, have a property of, have a relationship to or with, or the like. The term "controller" refers to any device, system, or part thereof that controls at least one operation. The functionality associated with any particular controller may be centralized or distributed, whether locally or remotely. The phrase "at least one of," when used with a list of items, means that different combinations of one or more of the listed items may be used, and only one item in the list may be needed. For example, "at least one of A, B, and C" includes any of the following combinations: A, B, C, A and B, A and C, B and C, and A and B and C, and any variations thereof. As an additional example, the expression "at least one of a, b, or c" may indicate only a, only b, only c, both a and b, both a and c, both b and c, all of a, b, and c, or variations thereof. Similarly, the term "set" means one or more. Accordingly, the set of items may be a single item or a collection of two or more items.

[0127] Moreover, multiple functions described below may be implemented or supported by one or more computer programs, each of which is formed from computer readable program code and embodied in a computer readable medium. The terms "application" and "program" refer to one or more computer programs, software components, sets of instructions, procedures, functions, objects, classes, instances, related data, or a portion thereof adapted for implementation in a suitable computer readable program code. The phrase "computer readable program code" includes any type of computer code, including source code, object code, and executable code. The phrase "computer readable medium" includes any type of medium capable of being accessed by a computer, such as Read Only Memory (ROM), Random Access Memory (RAM), a hard disk drive, a Compact Disc (CD), a Digital Video Disc (DVD), or any other type of memory. A "non-transitory" computer readable medium excludes wired, wireless, optical, or other communication links that transport transitory electrical or other signals. A non-transitory computer readable medium includes media where data may be permanently stored and media where data may be stored and later overwritten, such as a rewritable optical disc or an erasable memory device.

[0128] According to one embodiment of the present disclosure, a method and a system for design of remote attestation framework in Radio Access Network (RAN) in 6thgeneration network. The system describes a remote attestation procedure among RAN nodes and between RAN nodes and core network (CN). The RAN nodes include at least one of, Radio Units (RUs), Distributed Units (DUs), and Centralized Units (CUs), deployed in virtualized or cloud environments. The system comprises one or more attestors including a Trusted Execution Environment (TEE), a Trusted Platform Module (TPM), Hardware Secure Module (HSM), and a Trust Anchor Function (TAF). Further, the one or more attestors are configured to collect and prepare attestation evidence for the RAN nodes. The one or more attestors are configured to communicate the prepared attestation evidence to a verifier. The verifier is configured to transmit attestation results in response to the received attestation evidence to the one or more relying party entities. Further, the one or more relying party entities are configured to validate the attestation results and decide whether to allow or deny communication to the RAN nodes based on pre-configured policies. In an embodiment, the attestation process ensures secure onboarding and continuous monitoring of the RAN nodes across various interfaces including mid-haul, backhaul, front-haul and XN-interface scenarios. TAF either can be an independent network function, can be co-located with either Orchestrator or Operations, Administration and Maintenance (OAM) entity, or part of Management plane entity.

[0129] The system and method as disclosed provides secure On-boarding of DU / CU / RU by attestation, an attestation procedure between DU-CU (Mid-haul), an attestation procedure between CU-Core N / W (backhaul), an attestation procedure between RU-DU (Front-haul) and an attestation between NGRAN nodes. (XN-interface) which may be explained in the later paragraphs. The system and method includes TAF placement and impact on RAN architecture, message exchange between TAF and other RAN entities, and certificate management / PKI (algorithms / profiles, PQC profile).

[0130] All the procedures defined here are for 3GPP standard and may impact the standards esp. 3GPP TS 38.413, 38.423, 38.471, and 33.501 for 5G Ultra (advanced) and 6G.

[0131] Embodiments of the present disclosure will be described below in detail with reference to the accompanying drawings.

[0132] For the sake of clarity, the first digit of a reference numeral of each component of the present disclosure is indicative of the Figure number, in which the corresponding component is shown. For example, reference numerals starting with digit "1" are shown at least in Figure 1. Similarly, reference numerals starting with digit "2" are shown at least in Figure 2. Further, similar reference numerals have been used to represent similar components in the Figures.

[0133] It should be noted that the terms "evidence" and "at least one proof of evidence" have been used interchangeably throughout the description and the drawings. Further, the terms "policy" and "one or more policy configurations" have been used interchangeably throughout the description and the drawings.

[0134] In modern telecommunications, operators frequently deploy Radio Access Network (RAN) entities such as virtualized Centralized Units (vCUs) and virtualized Distributed Units (vDUs) in virtualized environments and untrusted zones like shared Commercial Off-The-Shelf (COTS) infrastructure, edge computing, facilities, and cloud environments. The deployments introduce significant security concerns due to limited visibility and control over the virtualized and untrusted environments. Consequently, the RAN entities become highly vulnerable to various types of attacks, necessitating robust security measures.

[0135] The untrusted zones expose the RAN entities including the vCUs, vDUs, radio units (RUs), and open RAN components, to various attacks on different layers, from the virtualization layer to the hardware platform. These attacks / threats include attacks on interfaces, applications, and underlying infrastructure. Currently, there is no comprehensive method for verifying the security of virtualized or cloud environments by a communication network, which exacerbates the potential risks. Additionally, background checks and passport models for attestation provide frameworks for verifying the integrity of the RAN entities.

[0136] Figure 1 illustrates an example scenario 100 depicting an environment for attestation, according to a conventional technique. Referring to Figure 1, the environment includes an attester, a sender, a receiver, and a verifier. Herein, the attester provides an accurate information about itself in the form of an evidence to enable remote peer via the sender. The receiver receives the evidence from the sender and transmits the evidence to the verifier. The verifier verifies the evidence and transmits the attestation result to the receiver. In an example, the verifier sends the attestation result as JSON-encoded payload. This particular verifier has knowledge about a Trusted Execution Environment (TEE) attester to be able to pass claims , for example, debug status directly through to the relying party. The verifier also knows the reference values for the measured software components and is able to check the reference values. The verifier informs the relying party that they were correct in the "measures" claim. "Trustus Verifications" is the name of the services that verify the software component measurements.

[0137] The receiver based on the attestation result, decides to consider the trustworthiness of the sender. This configuration identifies the efficient working of the system and provides the system-level remediation and resiliency. Herein, the evidence provides an attested claims set that describes state and characteristics of an entity, a device, a smartphone, IoT device, network equipment etc. This claims set is used by a relying party, server, or service to determine the type and degree of trust placed in the entity. The evidence is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with attestation-oriented claims.

[0138] A plurality of examples of the evidence is provided as follows: ueid (Universal Entity ID) Claim, sueids (Semi-permanent UEIDs) Claim (SUEIDs), OEM ID (Hardware OEM Identification) Claim- Random Number Based OEM ID, IEEE Based OEM ID, IANA Private Enterprise Number Based OEM ID, hwmodel (Hardware Model) Claim, hwversion (Hardware Version) Claim, swname (Software Name) Claim, swversion (Software Version) Claim, oemboot (OEM Authorized Boot) Claim, dbgstat (Debug Status) Claim- Enabled / Disabled / Disabled Since Boot / Disabled Permanently / Disabled Fully and Permanently, uptime (Uptime) Claim, bootcount (Boot Count) Claim, bootseed (Boot Seed) Claim, dloas (Digital Letters of Approval) Claim, manifests (Software Manifests) Claim, measurements (Measurements) Claim, measres (Software Measurement Results) Claim, submods (Submodules)- Submodule Claims-Set, Detached Submodule Digest, Nested Tokens. Further, the evidence with claims and attestation result is shown below:

[0139]

[0140] The attestation result / attestation provides the following advantages: ensuring that a platform (cloud) is healthy and trustworthy is a fundamental vertical in today's zero trust approach. The attestations are provided at runtime, supporting the zero trust requirement for dynamic authentication and access control. The attestations utilize the hardware root of trust (RoT) as it is immutable with a cryptographic identity bound to the Trusted Platform Module (TPM), TEE.

[0141] However, implementing these models in context of 5thgeneration network or beyond networks introduces challenges related to scalability, interoperability, and the dynamic nature of the virtualized network functions. Also, different attestation mechanisms are provided to address security concerns, such as, a TEE that is adapted to segregate area of memory and CPU that is protected from the rest of the CPU using encryption. Another attestation method includes a TPM that is a server for verifying the platform integrity. Moreover, some attestation mechanism includes a Hardware Secure Module (HSM) including hardened, tamper-resistant hardware devices that secure cryptographic processes by generating, protecting, and managing keys used for encrypting and decrypting data and creating digital signatures and certificates.

[0142] Figure 2 illustrates an example scenario 200 including a plurality of RAN entities within a virtualized and / or untrusted RAN environment, according to a conventional technique. For instance, the virtualized environments and untrusted zones includes shared *COTS, edge, cloud, etc. Further, as shown, RANs are split between an operator-controlled environment 201 and a third-party cloud infrastructure 203. The third-party cloud infrastructure 203 may host vDU 203a.The telecom operators have deployed RAN entities such as, the vDU 203a, in the virtualized environment / cloud infrastructure and / or untrusted zone. In the illustrated scenario, the telecom operators may be worried of the security of the deployed RAN entities in the virtualized and / or the untrusted zone, as the telecom operators have no / limited visibility in the virtualized and / or the untrusted zone. Also, in the untrusted zones, like vCU, vDU, RU, O-RAN, Edge, cloud, the RAN entities are more vulnerable to attack hence proper security is needed in virtualized and cloud environments. On the other hand, functions running within the operator-controlled environment 201 (such as Centralized Unit (CU) and Distributed Unit (DU)) are considered secure, creating a stark trust boundary that is unmanaged and potentially exploitable. Also, zero trust needs to be properly implemented to secure telecom cloud deployments. Accordingly, virtualized and / or untrusted environment deployments are prone to attacks such as, attacks on virtualization layer, attack on interfaces / applications, as no verification of such environment is performed by the communication network.

[0143] Figure 3 illustrates another scenario 300, depicting various attacks due to virtualization and cloudification, according to a conventional technique. Figure 3 illustrates a landscape 100 of threats due to virtualization and cloudification, in accordance with prior art. As shown, the threats may include unauthorized access, data leaks, privilege escalation, and service disruption. The threats may be due to one of an attack on the virtualization layer, an attack on interfaces or applications, and an attack on hardware platforms. Figure 3 further represents the propagation of security risks when various attacks go undetected due to the absence of runtime checks or integrity assessments. One key attack illustrated is the violation of trust boundaries, where malicious or compromised network functions in the cloud can interact with trusted systems within the operator's infrastructure. This leads to a range of cascading threats. For instance, attackers may carry out data integrity attacks, modifying control or user data in transit, thereby undermining the reliability of network services. In addition, the cloud-based NFs could launch configuration poisoning attacks by feeding inaccurate or malicious policy or routing data to orchestrators or other NFs, causing service misbehaviour or outages. Another serious risk is control plane hijacking, where compromised functions manipulate network signaling or orchestration commands to reroute traffic or exhaust resources, effectively taking over key network operations. Current systems do not offer any standardized method or framework for operators or vendors to verify whether their NF instance is secure in a virtualized or containerized setting.

[0144] Further, attestation is performed at runtime, which aligns with the zero-trust requirement for dynamic, ongoing authentication and access control. Attestation relies on a hardware root of trust (RoT), i.e., a secure, immutable foundation used for verifying system integrity. Such an implementation is illustrated in Figure 4. Figure 4 illustrates an exemplary implementation 400 of zero-trust process using trusted hardware-based attestation mechanisms, in accordance with prior art. As shown, the implementation 400 includes a TEE 401 and a TPM 403. The TEE 401 is a segregated area of memory and Central Processing Unit (CPU) that's protected from the rest of the CPU using encryption. The TEE 401 protects sensitive data and code from unauthorized access. The TPM 403 verifies platform integrity and ensures that only trusted devices can connect. Hence, the TEE 401 and the TPM 403 provide cryptographic identities and secure execution environments.

[0145] However, the existing techniques do not provide any security frameworks that support verification, trust establishment, and protection for RANs in virtualized and cloud environments. Further, the existing techniques do not provide concrete security in the virtualized and cloud environments. Also, implementing the existing techniques are complex when the RANs are distributed across diverse environments.

[0146] Thus, there is still a need to address the above-mentioned issues and provide an enhanced method and system for security and integrity of the RAN in virtualized and untrusted environment deployments.

[0147] Figure 5 illustrates a wireless communication network 500 (may be interchangeably referred to as the network 500) for implementation of remote attestation in a zero-trust architecture, in accordance with an embodiment of the present disclosure. As shown, the network 500 includes a first RAN entity 520 connected to an attester 530. The first RAN entity 520 and the attester 530 may be present in a cloud or virtualized environment 510. In an exemplary embodiment, the attester 530 may include, but is not limited to, a TEE, a TPM, and a HSM. The attester 530 may provide a proof of evidence to the first RAN entity 520 for authentication, as described in the following paragraphs. The first RAN entity 520, in the cloud environment 510, may wish to maintain connection with second RAN entity 540 connected to a Base Station (BS) 550 of the wireless communication network 500. In an embodiment, the first RAN entity 520 may be allowed to be connected to the second RAN entity 540 after being remotely authenticated by a TAF 560. In an embodiment, the second RAN entity 540 may communicate with the cloud environment 510 via Service-Based (SBA) interface. In another embodiment, the second RAN entity 540 may communicate with the cloud environment 510 using a pre-defined interface. The TAF 560 may be connected to a verifier 570 to authenticate the first RAN entity 520. In an exemplary embodiment, the verifier 570 may be connected to the cloud environment 510 and / or the TAF 560 via a Public Key Infrastructure (PKI) infra setup or a pre-defined interface. In an embodiment, the first RAN entity 520 may be authenticated in accordance with techniques as explained in the following paragraphs. In an embodiment, the TAF 560 may reside in the cloud environment 510 and the second RAN entity 540, as shown in FIG. 5. In another embodiment, the TAF 560 may reside in a Service Management and Orchestration (SMO) associated with the RAN entity, as explained in the following paragraphs. The TAF 560 may be one of an individual network entity of a network function. Further, in an embodiment, the wireless communication network 500 may correspond to a 6G wireless communication network and any similar wireless communication network supporting a zero-trust architecture.

[0148] Figure 6 illustrates an exemplary environment 600 including systems 610 and 620 for remote attestation in the zero-trust architecture in the RAN entity of the wireless communication network 500, in accordance with an embodiment of the present disclosure. As shown, the environment 600 may include the system 610 implemented in the TAF 560. The system 610 is connected to the system 620 corresponding to the first RAN entity 520. It should be noted that Figures 5 and 6 have been explained in conjunction with each other for the sake of brevity of the disclosure.

[0149] The system 610 may include one or more processors 602 (hereinafter referred to as the processor 602), a memory 604, one or more modules 606 (referred to herein as the modules), and an interface 608. In an exemplary embodiment, the one or more processors 602 may be in communication with the memory 604, the modules 606, and the interface 608.

[0150] In one embodiment, the processor 602 may include at least one data processor for executing processes in Virtual Storage Area Network. The processor 602 may include specialized processing units such as integrated system (bus) controllers, memory management control units, floating point units, graphics processing units, digital signal processing units, etc. In one embodiment, the processor 602 may include a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), or both. The processor 602 may be one or more general processors, Digital Signal Processors (DSPs), application-specific integrated circuits, Field-Programmable Gate Arrays (FPGAs), servers, networks, digital circuits, analog circuits, combinations thereof, or other now known or later developed devices for analyzing and processing data. The processor 602 may execute a software program, such as code generated manually (i.e., programmed) to perform the desired operation. The processor 602 may implement various techniques such as, but not limited to, image processing, data extraction, Artificial Intelligence (AI), Machine Learning (ML), Deep Learning (DL), and so forth to achieve the desired objective.

[0151] In one embodiment, the processor 602 may be configured to perform the functions of the system 610 and / or the TAF 560.

[0152] The processor 602 may be disposed in communication with one or more Input / Output (I / O) devices, such as the system 620, via the interface 608. The interface 608 may employ communication Code-Division Multiple Access (CDMA), High-Speed Packet Access (HSPA+), Global System For Mobile Communications (GSM), Long-Term Evolution (LTE), WiMax, or the like, etc.

[0153] In an embodiment, the processor 602 may be disposed in communication with a communication network via a network interface. In an embodiment, the network interface may be the interface 608. The network interface may connect to the communication network to enable connection of the system 610 with the outside environment and / or device / system. The network interface may employ connection protocols including, without limitation, direct connect, Ethernet (e.g., twisted pair 10 / 100 / 1000 Base T), Transmission Control Protocol / Internet Protocol (TCP / IP), token ring, IEEE 802.11 / b / g / n / x, etc. The communication network may include, without limitation, a direct interconnection, Local Area Network (LAN), Wide Area Network (WAN), wireless network (e.g., using Wireless Application Protocol (WAP)), the Internet, etc. Using the network interface and the communication network, the system 610 may communicate with other devices. The network interface may employ connection protocols including, but not limited to, direct connect, Ethernet (e.g., twisted pair 10 / 100 / 1000 Base T), TCP / IP, token ring, IEEE 802.11 / b / g / n / x, etc.

[0154] The memory 604 may be communicatively coupled to the processor 602. The memory 604 may be configured to store data and instructions executable by the processor 602. In one embodiment, the memory 604 may communicate via a bus within the system 610. The memory 604 may include, but is not limited to, a non-transitory computer-readable storage media, such as various types of volatile and non-volatile storage media including, but not limited to, random access memory, read-only memory, programmable read-only memory, electrically programmable read-only memory, electrically erasable read-only memory, flash memory, magnetic tape or disk, optical media and the like. In one example, the memory 604 may include a cache or random-access memory for the processor 602. In alternative examples, the memory 604 is separate from the processor 602, such as a cache memory of a processor, the system memory, or other memory. The memory 604 may be an external storage device or database for storing data. The memory 604 may be operable to store instructions executable by the processor 602. The functions, acts, or tasks illustrated in the figures or described may be performed by the programmed processor 602 for executing the instructions stored in the memory 604. The functions, acts, or tasks are independent of the particular type of instruction set, storage media, processor, or processing strategy and may be performed by software, hardware, integrated circuits, firmware, micro-code, and the like, operating alone or in combination. Likewise, processing strategies may include multiprocessing, multitasking, parallel processing, and the like. The memory 604 may further include a database to store the data. Further, the memory 604 may include an operating system for performing one or more tasks of the system 610, as performed by a generic operating system in the communications domain.

[0155] For the sake of brevity, the architecture, and standard operations of the processor 602 and the memory 604 are not discussed in detail. In one embodiment, the memory 604 may be configured to store the information as required by the processor 602 to perform the techniques described herein.

[0156] The modules 606, amongst other things, include routines, programs, objects, components, data structures, etc., which perform particular tasks or implement data types. The modules 606 may also be implemented as, signal processor(s), state machine(s), logic circuitries, and / or any other device or component that manipulates signals based on operational instructions. The modules 606 may be configured to one or more operations of the system 610 and / or the processor 602.

[0157] Further, the modules 606 can be implemented in hardware, instructions executed by a processing unit, or by a combination thereof. The processing unit can comprise a computer, the processor 602, a state machine, a logic array, or any other suitable devices capable of processing instructions. The processing unit can be a general-purpose processor which executes instructions to cause the general-purpose processor to perform the required tasks, or the processing unit can be dedicated to performing the required functions. In another embodiment of the present disclosure, the modules 606 may be machine-readable instructions (software) that, when executed by a processor / processing unit, perform any of the described functionalities. Furthermore, the data serves, amongst other things, as a repository for storing data processed, received, and generated by one or more of the modules. The modules 606 may include an establishing module 612, a receiving module 614, a determining module 616, a transmitting module 618, and a triggering module 621.

[0158] Additionally, the system 620 may be implemented within the first RAN entity 520. The system 620 may include a processor 601, a memory 603, one or more modules 605 (referred to herein as the modules), and an interface 607. The processor 601 may be in communication with the memory 603, modules 605, and the interface 607. The constructional and operational features of the processor 601, a memory 603, modules 605, and the interface 607 may be the same as the processor 602, a memory 604, modules 606, and the interface 608. Thus, the same has not been explained for the sake of brevity. Herein, the modules 606 may include an enabling module 609, a receiving module 611, and a transmitting module 613.

[0159] In an embodiment, the enabling module 609 may be configured to enable certificate retrieval of the first RAN entity 520 using a User-based Security Model (USM). In response, the establishing module 612 may be configured to establish a communication between the first RAN entity 520 and the TAF 560 based on a nonce message. In an embodiment, the first RAN entity 520 may be one of a Centralized Unit (CU), a Distributed Unit (DU), and a Radio Unit (RU).

[0160] Further, to establish the communication between the first RAN entity 520 and the TAF 560, the establishing module 612 may be configured to establish the communication between the first RAN entity 520 and the TAF 560 via the second RAN entity 540.

[0161] Further, upon the establishment, the receiving module 611 may be configured to receive at least one proof of evidence from the attester 530. Further, the transmitting module 613 may be configured to transmit the at least one proof of evidence to the TAF 560. In response, the receiving module 614, of the TAF 560, may be configured to receive at least one proof of evidence from the first RAN entity 520 based on the established communication. The at least one proof of evidence may indicate trustworthiness of the first RAN entity 520. For receiving the at least one proof of evidence, the receiving module 614 may be configured to receive the at least one proof of evidence in a request_for_attestation message via the second RAN entity 540. The request_for_attestation message may be a new message.

[0162] The determining module 616 may be configured to determine an attestation result based on the received at least one proof of evidence. In such an embodiment, initially, the transmitting module 618 may be configured to transmit the at least one proof of evidence to the verifier 570 for verification. Thereafter, the receiving module 614 may be configured to receive at least one verification result corresponding to the transmitted at least one proof of evidence from the verifier 570. The determining module 616 may be configured to determine the attestation result by validating the received at least one verification result based on one or more pre-defined policy configurations

[0163] Further, the transmitting module 618 may be configured to transmit the attestation result to the first RAN entity 520. Further, to transmit the attestation result, the transmitting module 618 may be configured to transmit, the attestation result in an attestation response message. The attestation response message may indicate one of pass, fail, and a score associated with the attestation result.

[0164] In response, the receiving module 611 may be configured to receive the attestation result in response to the transmitted at least one proof of evidence from the TAF 560. In an embodiment, to receive the attestation result, the receiving module 611 may be configured to receive the attestation result in one of a one time password (OTP) message, OTP_key message.

[0165] The attestation result enables the first RAN entity to maintain a communication with the second RAN entity 540 via a plurality of communication channels and based on a provisioning of the certificate. Further, the provisioning of the certificate indicates one of pass, fail, and score associated with the attestation result.

[0166] In an embodiment, the triggering module 621 may be configured to trigger one or more events based on the attestation result. The one or more events may be defined in one or more pre-defined policy configuration provided to the TAF 560. In an embodiment, the one or more events may include, but are not limited to, subscribe, notify, publish kind of events.

[0167] Figure 7 illustrates a sequence of operations 700 depicting an attestation process among different RAN entities for secure on-boarding, service provisioning, for example, key and certificates provisioning etc. using a background check model, according to an embodiment of the present disclosure. The sequence of operations may be performed between the attester 530 including, TPM / virtual TPM (vTPM) / TEE / HSM, the first RAN entity 520 (e.g. DU / CU / RU), the second RAN entity 540, and the TAF 560 (or a SMO).

[0168] At operation 702, the first RAN entity 520 may send an attestation setup request to the second RAN entity 540. At operation 704, the second RAN entity 540 may transmit a request challenge / nonce to the TAF 560, in response to the received attestation setup request.

[0169] In response to the received request challenge / nonce, at operation 706, the TAF 560 transmits a challenge response (a nonce message) to the second RAN entity 540. Thus, a communication between the first RAN entity 520 and the TAF 560 may be established based on the nonce message via the second RAN entity 540.

[0170] At operation 708, the second RAN entity 540 transmit a request for evidence to the first RAN entity 520, after establishing the communication. In response to the received request for evidence, at operation 710, the first RAN entity may transmit the nonce to the attester 530. At operation 712, the attester 530 may collect measure / claims based on the nonce and prepare signed evidence. At operation 714, the attester 530 may transmit the evidence including quote(nonce) and signature to the first RAN entity 520. In response the received evidence, the first RAN entity 520 may transmit the evidence to the second RAN entity 540, at operation 715. At operation 716, the second RAN entity 540 transmits the request_for_attestation including the attestation quote to the TAF 560. Thus, the TAF 560 receives the evidence in the request_for_attestation via the second RAN entity 540.

[0171] In response to the received request for attestation, at operation 718, the TAF 560 transmits the attestation response including an indication as one of passed, failed, or score to the second RAN entity 540. At operation 720, the second RAN entity 540 transmits the provisioning of the certificate based on the attestation result (as received from the TAF 560) to the first RAN entity 520. Thus, the TAF 560 transmits the attestation result in the attestation response message via the second RAN entity 540. In one embodiment, the attestation response / result may be a Boolean value indicating a success / failure or an integer-based score. Further, the success and failure may be determined based on preconfigured threshold values. Thus, the sequence of operation enables secure on-boarding of the radio entities.

[0172] The attestation procedure between the DU and CU includes, at first, an F1 setup request may be initiated by the DU with attestation evidence.

[0173] Further, attestation verification may be conducted by CU. The CU may also act as a verifier. Further, response / failure, the CU sends back the attestation results indicating success or failure. Therefore, in a mutual attestation, both DU and CU may verify each other's integrity before establishing a secure communication channel.

[0174] Further, the provisioning server may be configured to manage an attestation setup and certificate provisioning. The TAF may be configured to verify evidence and decide on certificate issuance. The verifier may be configured to conduct evidence verification and attestation. The verifier may be configured to generate evidence based on request and responses exchanged among the DU, CU, or RU. Further, the verifier may be configured to verify certificate provisioning based on the attestation results.

[0175] Figure 8 illustrates a sequence of operations 800 corresponding to remote attestation between the first RAN entity 520, i.e., a RU and the second RAN entity 540, i.e., a DU / RAN intelligent controller (RIC), according to an embodiment of the present disclosure.

[0176] At operation 802, the USM 801 may be configured to enable an RU certificate retrieval and / or TLS features provision thereby enabling certificate retrieval of the first RAN entity 520 using the USM 801. The RU may include evidence by TPM / TEE with both quote and signature. At operation 804, the RU may be configured to transmit an authenticated transaction (serial number) and evidence (attestation) to the DU / RAN intelligent controller (RIC) 540.

[0177] Thereafter, at operation 805, the transacted serial number and attestation may be verified by the verifier 570 in the orchestrator and may be transmitted to the DU / RAN intelligent controller (RIC) 540. In an embodiment, only upon attestation verification success case, a OTP may be initiated.

[0178] At operation 806, an operator public key infrastructure (PKI), OTP application programming interface (API) return, OTP, OTP-KEY may be shared between the DU / RIC 540 and an operator PKI infra 813.

[0179] At operation 808, RU capabilities or file indicating Hash-based Message Authentication Code (HMAC) authenticator, certificates and TLS, OTP may be shared between the RU 520 and the DU / RIC 540. Further, at operation 810, Certificate Management Protocol version 2 (CMPv2) initialization may require transaction (OTP, OTP_KEY) and may be shared between the RU 520 and the DU / RIC 540 and between the DU / RIC 540 and the operator PKI infra 813. Successively, at operation 812, the RU 520 may be configured to transmit mTLS connection establishment to the DU / RIC 840.

[0180] The attestation procedure as illustrated above may be implemented without any modification of standards. This may also be applicable for RU / DU / CU certificate provisioning.

[0181] After performing the operation 800, in an embodiment, a system 906, 1406, 1906, 2406 (referring Figures 9A to 28, where each figure is explained in detail in later paragraphs) may include a memory 910, 1410, 1910, 2410 and a processor 908, 1408, 1908, 2408. The processor 908, 1408, 1908, 2408 may be in communication with the memory 910, 1410, 1910, 2410 respectively. The processor 910, 1410, 1910, 2410 may be configured to establish a communication between a trust anchor function 902, 1402, 1902, 2402 and a first RAN entity 904, 1404, 1904, 2404 based on a nonce request setup message. The processor 910, 1410, 1910, 2410 may be configured to receive at least one proof of evidence from the first Radio Access Network (RAN) entity 904, 1404, 1904, 2404 in a request_for_attestation (attestation_quote) message. The at least one proof of evidence indicates trustworthiness of the first RAN entity 904, 1404, 1904, 2404. The processor 910, 1410, 1910, 2410 may be configured to determine an attestation result based on the received at least one proof of evidence. The processor 910, 1410, 1910, 2410 may be configured to transmit the attestation result to the first RAN entity 904, 1404, 1904, 2404 in an attestation_response message. The attestation result enables the first RAN entity 904, 1404, 1904, 2404 to maintain a communication with second RAN entity 942, 1442, 1942, 2442.

[0182] Further, a system 926, 1426, 1926, 2426 (referring Figures 9A to 28, where each figure is explained in detail in later paragraphs) may include a memory 930, 1430, 1930, 2430 and a processor 928, 1428, 1928, 2428. The processor 928, 1428, 1928, 2428 may be in communication with the memory 930, 1430, 1930, 2430, respectively. The processor 928, 1428, 1928 2428 may be configured transmit, at least one proof of evidence in one of a request message to a trust anchor function 902, 1402, 1902, 2402. The at least one proof of evidence indicates trustworthiness of the first RAN entity 904, 1404, 1904, 2404. The processor 928, 1428, 1928, 2428 may be configured to transmit, via the second RAN entity 942, 1442, 1942, 2442 to the trust anchor function 902, 1402, 1902, 2402, the at least one proof of evidence in the one of the request message. The request message is a new message.

[0183] Prior to transmitting the at least one proof of evidence to the trust anchor function 902, 1402, 1902, 2402, the processor 928, 1428, 1928, 2428 may be configured to receive the at least one proof of evidence from an attester 940, 1440, 1940, 2440.

[0184] Further, in response to the transmitted at least one proof of evidence, the processor 928, 1428, 1928 2428 may be configured to receive an attestation result from the trust anchor function 902, 1402, 1902, 2402 in one of a response message. The attestation result enables the first RAN entity 904, 1404, 1904, 2404 to maintain a communication with second RAN entity 942, 1442, 1942, 2442.

[0185] The processor 928, 1428, 1928, 2428 may be configured to receive, via the second RAN entity 942, 1442, 1942, 2442, from the trust anchor function 902, 1402, 1902, 2402, the attestation result in response to the transmitted at least one proof of evidence in the response message. The response message indicates one of a pass, fail, failure: reason='attestation failure', and score of the attestation result.

[0186] In an embodiment, one of the request message may include a F1 setup request message, NG setup request message, a F2 setup request message, XN setup request message, and an attestation_request message.

[0187] In an embodiment, the one of the response message may include F1 setup response / failure message, NG setup response / failure message, F2 setup response / failure message, and XN setup response / failure message.

[0188] In an embodiment, the first RAN entity 904, 1404, 1904, 2404 may include one of a Centralized Unit (CU), a Distributed Unit (DU), and a Radio Unit (RU).

[0189] The detailed operation of each system 926, 1426, 1926, 2426 is explained in conjunction with Figures 9A to 28 in the subsequent paragraphs.

[0190] Similarly, the detailed operation performed by each system 906, 1406, 1906, 2406 is explained in conjunction with Figures 9A to 28 in the subsequent paragraphs.

[0191] Figure 9A illustrates systems 906, 926 depicting zero trust architecture 900 in the first RAN entity and the second RAN entity (mid-haul) via the trust anchor function, according to an embodiment of the present disclosure. Figure 9B illustrates an architecture depicting zero trust architecture 900 between the first RAN entity 904 and the second RAN entity 942 (mid-haul) via a background check model, according to an embodiment of the present disclosure. Figure 9C illustrates an architecture depicting zero trust architecture 900 between the first RAN entity 904 and the second RAN entity 942 (mid-haul) via a passport model, according to an embodiment of the present disclosure.

[0192] Figures 9A to 9C are explained in conjunction for the sake of brevity.

[0193] In an embodiment, the system 906, implemented in the TAF 902, may include a processor 908, a memory 910, an interface 924, one or more modules 912 (referred to herein as the modules). The constructional and operational details of the processor 908, the memory 910, the interface 924, the modules 912 may be same as the constructional and operational details of the processor 602, the memory 604, the modules 606, and the interface 608. Thus, the same has not been explained for the sake of brevity. Herein, the modules 912 may include an establishing module 914, a receiving module 916, a determining module 918, a transmitting module 920, and a triggering module 922.

[0194] In an embodiment, the system 926, implemented in the first RAN entity 904, may include a processor 928, a memory 930, an interface 938, and one or more modules 932 (referred to herein as the modules). The constructional and operational details of the processor 928, the memory 930, the interface 938, and the modules 932 may be the same as the constructional and operational details of the processor 601, the memory 603, the modules 605, and the interface 607. Herein, the modules 932 may include a receiving module 934, and a transmitting module 936.

[0195] In an embodiment, the establishing module 914 may be configured to establish a communication between the TAF 902 and the first RAN entity 904 based on a nonce request setup message.

[0196] In response, the transmitting module 936 may be configured to transmit at least one proof of evidence to the TAF 902. The transmitting module 936 may be configured to transmit the at least one proof of evidence in one of a F1 setup request message and an attestation_request message. The transmitting module 936 may be configured to transmit the at least one proof of evidence in the one of the F1 setup request message and the attestation_request message via the second RAN entity 942. The one of the F1 setup request message and the attestation_request message is a new message. Alternatively, the transmitting module 936 may be configured to transmit the at least one proof of evidence directly to the TAF 902 (as shown in Figure 9C).

[0197] In an embodiment, prior to transmitting the at least one proof of evidence to the TAF 902, the receiving module 934 may be configured to receive the at least one proof of evidence from the attester 940.

[0198] Thereafter, the receiving module 916 may be configured to receive at least one proof of evidence from the first RAN entity 904 in a request_for_attestation (attestation_quote) message. The first RAN entity 904 may be one of a CU, a DU, and a RU. The at least one proof of evidence indicates trustworthiness of the first RAN entity 904. In such an embodiment, the receiving module 916 may be configured to receive the at least one proof of evidence in the request_for_attestation (attestation_quote) message via the second RAN entity 942. The request_for_attestation (attestation_quote) message is a new message. Alternatively, the receiving module 916 may be configured to receive the at least one proof of evidence directly from the first RAN entity 904 (as shown in Figure 9C).

[0199] The determining module 918 may be configured to determine an attestation result based on the received at least one proof of evidence. In such an embodiment, the transmitting module 920 may be configured to transmit the at least one proof of evidence for verification to the verifier 946. In response, the receiving module 916 may be configured to receive at least one verification result corresponding to the transmitted at least one proof of evidence from the verifier 946. Thereafter, the determining module 918 may be configured to determine the attestation result by validating the received at least one verification result based on one or more pre-defined policy configurations.

[0200] The transmitting module 920 may be configured to transmit the attestation result to the first RAN entity 904 in an attestation_response message. In such an embodiment, the transmitting module 920 may be configured to transmit the attestation result in the attestation_response message via the second RAN entity 942. Alternatively, the transmitting module 920 may be configured to transmit the attestation result to the first RAN entity 904 directly (as shown in Figure 9C). The attestation_response message indicates one of a pass, fail, and score associated with the attestation result.

[0201] In response, the receiving module 934 may be configured to receive the attestation result in response to the transmitted at least one proof of evidence in one of a F1 setup response / failure message and an attestation_response message. The attestation result enables the first RAN entity 904 to maintain a communication with second RAN entity 942 based on one or more attestation policy. Additionally, based on the attestation result, the second RAN entity 942 may deny communication with the first RAN entity 904.

[0202] Further, to receive the attestation result, the receiving module 934 may be configured to receive, the attestation result in response to the transmitted at least one proof of evidence in the F1 setup response / failure message via the second RAN entity 942. The F1 setup response / failure message indicates one of a pass, fail, and score of the attestation result. Alternatively, the receiving module 934 may be configured to receive the attestation result from the TAF 902 directly (as shown in Figure 9C).

[0203] When the receiving module 934 receives the attestation result from the TAF 902 directly, then the transmitting module 936 transmits the attestation result to the second RAN entity 942. Thereafter, the second RAN entity 942 verifies the attestation result from the TAF 902. Upon verification, the attestation result enables the first RAN entity 904 to maintain the communication with second RAN entity 942 in the F1 setup response / failure message.

[0204] Further, the triggering module 922 may be configured to trigger one or more events based on the attestation result, where the one or more events are defined in one or more pre-defined policy configurations provided to the TAF 902. The TAF 902 may reside in a cloud environment. The TAF 902 is one of an individual entity or is a network function. The TAF 902 resides in a SMO associated with the RAN entity.

[0205] In an embodiment, the TAF 902 may be collocated with Orchestrator / SMO 944 or may be a separate entity or network function. The communication based on results and evidence between the attester 940 of the first RAN entity 904 and the attester 940 of the second RAN entity 942 is based on the background check model. Further, there may be relying party including the orchestrator or OAM 944 and the TAF 902 sharing evidence and attestation results. Finally, the verifier 946 may receive the attestation results and evidence.

[0206] Figure 10 illustrates a sequence of operations 1000 depicting the attestation process between the first RAN entity 904 and the second RAN entity 942 via the F1 setup request, according to an embodiment of the present disclosure. Herein, the first RAN entity 904 may be DU and the second RAN entity 942 may be CU.

[0207] At operation 1002, the TAF 902 establishes the communication with the first RAN entity 904 based on the nonce request setup message.

[0208] At operation 1004, the first RAN entity 904, may be configured to transmit the at least one proof of evidence in the F1 setup request message or attestation quote to the second RAN entity 942.

[0209] At operation 1006, the second RAN entity 942 may be configured to transmit the at least one proof of evidence in the request_for_attestation message (attestation_quote) to the TAF or SMO 902.

[0210] In response to the request, at operation 1008, the TAF 902 may transmit the attestation result to the first RAN entity 904 in the attestation_response message via the second RAN entity 942. The attestation_response message indicates one of the pass, fail, and score associated with the attestation result.

[0211] Further, in response to the attestation result, at operation 1010, the second RAN entity 942 may transmit the attestation result in response to the transmitted at least one proof of evidence in the F1 setup response / failure message. The F1 setup response / failure message indicates one of a pass, fail, and score of the attestation result.

[0212] The following modifications are to be incorporated in 3rd Generation Partnership Project 3GPP TS 38.473. In one embodiment, the F1 setup request may be as shown in below Table 1:

[0213]

[0214] Further, the attestation request / response may be present in non-3gpp messages (outside the 3GPP defined 5G message) also between the nodes. The attestation request / response / failure handling will be applicable to future 6G messages as well.

[0215] The following modification are to be incorporated in 3rd Generation Partnership Project 3GPP TS 38.473. The attestation request / response may be present in 3GPP messages as follows:

[0216]

[0217] Figure 11 illustrates a sequence of operations 1100 depicting the attestation process between the first RAN entity 904 and the second RAN entity 942 via a new message, according to an embodiment of the present disclosure. Herein, the first RAN entity 904 may be DU and the second RAN entity 942 may be CU.

[0218] At operation 1102, the first RAN entity 904 may transmit the at least one proof of evidence in the F1 setup request message (attestation quote) to the second RAN entity 942. In response, the second RAN entity 942 may request challenge / nonce to the TAF or SMO 902, at operation 1104.

[0219] At operation 1106, the SMO or TAF 902 may respond with a challenge response / nonce. Next, at operation 1108, the second RAN entity 942 may be configured to initiate attestation / nonce to the first RAN entity 904.

[0220] At operation 1110, the first RAN entity 904 may transmit the at least one proof of evidence in the attestation_request message to the second RAN entity 942, where the attestation_request message is the new message.

[0221] At operation 1112, the second RAN entity 942 may transmit the at least one proof of evidence in the request_for_attestation (attestation_quote) message request to the TAF 902.

[0222] At operation 1114, the SMO or TAF 902 may transmit the attestation result to the second RAN entity 942 in the attestation_response message. The attestation_response message indicates one of a pass, fail, and score associated with the attestation result.

[0223] At operation 1116, the second RAN entity 942 may transmit the attestation result in the F1 setup response / failure message to the first RAN entity 904. The F1 setup response / failure message indicates one of a pass, fail, and score of the attestation result.

[0224] The following modification are to be incorporated in 3rd Generation Partnership Project 3GPP TS 38.473. In an embodiment, the attestation request may be shown below in table 2 and initiate attestation for nonce may be shown below in table 3.

[0225]

[0226]

[0227] Attestation request / response may be present in non-3gpp messages (outside the 3GPP defined 5G message) also between the nodes. Attestation request / response / failure handling may be applicable to future 6G messages as well. Attestation request / response may be present in 3GPP messages like F1 Setup request etc.

[0228] Figure 12 illustrates a sequence of operations 1200 depicting the attestation process between the first RAN entity 904 and the second RAN entity 942 via the passport model, according to an embodiment of the present disclosure. Herein, the first RAN entity 904 may be DU and the second RAN entity 942 may be CU.

[0229] At operation 1202, the first RAN entity 904 may transmit attestation requested to the TAF 902. In response, the TAF 902 may request challenge / nonce to the first RAN entity 904, at operation 1204.

[0230] At operation 1206, the first RAN entity 904 may transmit the at least one proof of evidence in the F1 setup request message (attestation quote) to the TAF 902. Thereafter, the TAF 902 may transmit the at least one proof of evidence to the verifier 946. The verifier 946 verifies the at least one proof of evidence and based on the verification transmits the attestation result to the TAF 902. Further, at operation 1208, the TAF 902 may transmit the attestation result to the first RAN entity 904.

[0231] At operation 1210, the first RAN entity 904 may transmit the attestation result to the second RAN entity 942 in the F1 setup request message. Further, at operation 1212, the second RAN entity 942 may transmit verification request associated with the attestation result to the TAF 902.

[0232] At operation 1214, the TAF 902 may verify signature associated with the attestation result. Thereafter, at operation 1218, the TAF 902 may transmit verification_response associated with the attestation result to the second RAN entity 1218.

[0233] At operation 1218, the second RAN entity may validate the attestation result based on the verification_response. Further, at operation 1220, the second RAN entity 942 may transmit the attestation result to the first RAN entity 904 in the F1 setup response / failure (Success / Failure / Score), enabling maintaining communication between the first RAN entity 904 and the second RAN entity 942. Herein, the attestation result may also be part of a new message similar to the background check model.

[0234] The following modifications are to be incorporated in 3rd Generation Partnership Project 3GPP TS 38.473. In an embodiment, the F1 setup request may be shown in table 4 below.

[0235]

[0236] Further, the attestation request / response may be present in non-3gpp messages (outside the 3GPP defined 5G message) also between the nodes. Attestation request / response / failure handling may be applicable to future 6G messages as well. Attestation request / response may be present in 3GPP messages, for example, F1 Setup or in a new message as in background check model.

[0237] The following modification are to be incorporated in 3rd Generation Partnership Project 3GPP TS 38.473. For example, IE in F1AP procedure setup request:

[0238]

[0239] Figure 13 illustrates a sequence of operations 1300 depicting the attestation process between the first RAN entity 904 and the second RAN entity 942 via IP sec / DTLS / TLS, according to an embodiment of the present disclosure.

[0240] At operation 1302, the second RAN entity 942 (i.e. client) may establish a communication with the TAF 902 and subsequently with the verifier 946 in a Hypertext Transfer Protocol (HTTP) post. Herein, the first RAN entity 904 may be CU and the second RAN entity 942 may be DU.

[0241] At operation 1304, the verifier 946 may transmit the attestation policy to the TAF 902 and subsequently to the second RAN entity 942 in the HTTP (nonce, types, supported media types), at operation 1306.

[0242] At operation 1308, the second RAN entity 942 may establish a communication with the first RAN entity 904 (server). Herein, the second RAN entity requests the at least one proof of evidence in an evidence_request message (nonce, types) and also requests for key share, signature and algorithms.

[0243] Thereafter, at operation 1310, the first RAN entity 904 requests the at least one proof of evidence from the attester 940 in the evidence request message, where the at least one proof of evidence may include attest_key (noce, identity key). In response, at operation 1312, the attester 940 may transmit the at least one proof of evidence in the evidence_response message to the first RAN entity 904. The at least one proof of evidence may include signed evidence with claims, CAB (KAT, PAT).

[0244] Further, at operation 1314, the first RAN entity 904 may establish communication with the second RAN entity 942 such that the first RAN entity 904 transmit the at least one proof of evidence containing key share, encrypted extensions evidence_request (type(a)), signed evidence with claims, certificate (KAT, PAT).

[0245] Thereafter, at operation 1316, the first RAN entity 904 may transfer the signature, i.e., identify, key, hash (hs) to the attester 940 and in response, may receive the signature from the attester 940, at operation 1318.

[0246] At operation 1320, the first RAN entity 1320 may transmit the at least one proof of evidence to the second RAN entity 942 in the certificate verification:sig. Further, at operation 1322, the second RAN entity 942 may transmit the at least one proof of evidence to the TAF 902 in the verification request message to verify Signed Evidence with claims, type(a), CAB. The TAF 902 further transmit the at least one proof of evidence to the verifier 946.

[0247] Thereafter, at operation 1324, the TAF 902 may receive the verification policy based on the at least one proof of evidence. Further, at operation 1326, the TAF 902 may transmit the attestation result (AR) in the verification response to the second RAN entity 942.

[0248] Further, at operations 1328, and 1330, the second RAN entity 942 may verify the attestation result and the signature and subsequently, transmit the attestation result to the first RAN entity 904. The attestation result enables to maintain communication between the first RAN entity 904 and the second RAN entity 942. Thereafter, at operation 1330, the application data is performed between the first RAN entity 904 and the second RAN entity 942.

[0249] In an embodiment, the attestation may also be embedded as a part of the IPsec between the second RAN entity 942 and the first RAN entity 904.

[0250] In an embodiment, during TLS connection, the client CU initiates the communication with server DU. For the client to consider the server genuine server needs to present evidence. The client CU (acting as a relying party) challenges the server DU (as the attester) to provide evidence. The server DU provides the at least one proof of evidence to the client CU. Further, the attestation policy may be implementation specific and may be applied at various check points based on the level of security required by the operator. The attestation may also be embedded as a part of IPsec tunnel between the first RAN entity 904 and the second RAN entity 942.

[0251] In an embodiment, the attestation between the first RAN entity 904 and the second RAN entity 942 may be also performed mutually, i.e., the first RAN entity 904 and the second RAN entity 942 may be attest each other. In the procedures and models described above, each entity on either side of a secure interaction may require remote attestation of its peer. This process is known as mutual-attestation. Further, to support mutual-attestation, the interaction entities mentioned above may operate independently on either side of the connection.

[0252] Figure 14A illustrates systems 1402, 1426 depicting zero trust architecture 1400 in the first RAN entity and the second RAN entity (backhaul) via the trust anchor function, according to an embodiment of the present disclosure. Figure 14B illustrates an architecture depicting zero trust architecture 1400 between the first RAN entity 1404 and the second RAN entity 1442 (backhaul) via the background check model, according to an embodiment of the present disclosure. Figure 14C illustrates an architecture depicting zero trust architecture 1400 between the first RAN entity 1404 and the second RAN entity 1442 (backhaul) via the passport model, according to an embodiment of the present disclosure. Herein, the first RAN entity 1404 may be CU and the second RAN entity 1442 may be Core network (N / W).

[0253] Figures 14A to 14C are explained in conjunction for the sake of brevity.

[0254] In an embodiment, the system 1406, implemented in the TAF 1402, may include a processor 1408, a memory 1410, an interface 1424, and one or more modules 1412 (referred to herein as the modules). The constructional and operational details of the processor 1408, the memory 1410, the interface 1424, the modules 1412 may be same as the constructional and operational details of the processor 602, the memory 604, the modules 606, and the interface 608 as mentioned in Figure 6. Thus, the same has not been explained for the sake of brevity. Herein, the modules 1412 may include an establishing module 1414, a receiving module 1416, a determining module 1418, a transmitting module 1420, and a triggering module 1422.

[0255] In an embodiment, the system 1426, implemented in the first RAN entity 1404, may include a processor 1428, a memory 1430, an interface 1438, and one or more modules (referred to herein as the modules)1432. The constructional and operational details of the processor 1428, the memory 1430, the interface 1438, and the modules 1432 may be the same as the constructional and operational details of the processor 601, the memory 603, the modules 605, and the interface 607 as mentioned in Figure 6. Herein, the modules 932 may include a receiving module 1434, and a transmitting module 1436.

[0256] In an embodiment, the establishing module 1414 may be configured to establish a communication between the TAF 1402 and the first RAN entity 1404 based on the nonce request setup message.

[0257] Upon establishment, the transmitting module 1436 may be configured to transmit at least one proof of evidence to the TAF 1402. The transmitting module 1436 may be configured to transmit the at least one proof of evidence in one of a new generation (NG) setup request message and an attestation_request message. The transmitting module 1436 may be configured to transmit the at least one proof of evidence in the one of the NG setup request message and the attestation_request message via the second RAN entity 1442. The one of the NG setup request message and the attestation_request message is a new message. Alternatively, the transmitting module 1436 may be configured to transmit the at least one proof of evidence directly to the TAF 1402 (as shown in Figure 14C).

[0258] In an embodiment, prior to transmitting the at least one proof of evidence to the TAF 1402, the receiving module 1434 may be configured to receive the at least one proof of evidence from the attester 1442.

[0259] Thereafter, the receiving module 1416 may be configured to receive at least one proof of evidence from the first RAN entity 1404 in a request_for_attestation (attestation_quote) message. The first RAN entity 1404 may be one of the CU, the DU, and the RU. The at least one proof of evidence indicates trustworthiness of the first RAN entity 1404. In such an embodiment, the receiving module 1416 may be configured to receive the at least one proof of evidence in the request_for_attestation (attestation_quote) message via the second RAN entity 1442. The request_for_attestation (attestation_quote) message is a new message. Alternatively, the receiving module 1416 may be configured to receive the at least one proof of evidence directly from the first RAN entity 1404 (as shown in Figure 14C).

[0260] The determining module 1418 may be configured to determine an attestation result based on the received at least one proof of evidence. In such an embodiment, the transmitting module 1420 may be configured to transmit the at least one proof of evidence for verification to the verifier 1446. In response, the receiving module 1416 may be configured to receive at least one verification result corresponding to the transmitted at least one proof of evidence from the verifier 1446. Thereafter, the determining module 1418 may be configured to determine the attestation result by validating the received at least one verification result based on one or more pre-defined policy configurations.

[0261] The transmitting module 1420 may be configured to transmit the attestation result to the first RAN entity 1404 in an attestation_response message. In such an embodiment, the transmitting module 1420 may be configured to transmit the attestation result in the attestation_response message via the second RAN entity 1442. Alternatively, the transmitting module 1420 may be configured to transmit the attestation result to the first RAN entity 1404 directly (as shown in Figure 14C). The attestation_response message indicates one of a pass, fail, and score associated with the attestation result.

[0262] In response, the receiving module 1434 may be configured to receive the attestation result in response to the transmitted at least one proof of evidence in a NG setup response / failure message. The attestation result enables the first RAN entity 1404 to maintain a communication with second RAN entity 1442 based on one or more attestation policy. Additionally, based on the attestation result, the second RAN entity 1442 may deny communication with the first RAN entity 1404.

[0263] Further, to receive the attestation result, the receiving module 1434 may be configured to receive, the attestation result in response to the transmitted at least one proof of evidence in the NG setup response / failure message via the second RAN entity 1442. The NG setup response / failure message indicates one of a pass, failure: reason='attestation failure' of the attestation result. Alternatively, the receiving module 1434 may be configured to receive the attestation result from the TAF 1402 directly (as shown in Figure 14C).

[0264] When the receiving module 1434 receives the attestation result from the TAF 1402 directly, then the transmitting module 1436 transmits the attestation result to the second RAN entity 1442. Thereafter, the second RAN entity 1442 verifies the attestation result from the TAF 1402. Upon verification, the attestation result enables the first RAN entity 1404 to maintain the communication with second RAN entity 1442 in the NG setup response / failure message (as shown in Figure 14C).

[0265] Further, the triggering module 1422 may be configured to trigger one or more events based on the attestation result, where the one or more events are defined in one or more pre-defined policy configurations provided to the TAF 1402. The TAF 1402 may reside in a cloud environment. The TAF 1402 is one of an individual entity or is a network function. The TAF 1402 resides in a SMO associated with the RAN entity.

[0266] Figure 15 illustrates a sequence of operations depicting the attestation process between the first RAN entity 1404, i.e., the CU and the second RAN entity 1442, i.e., the core network via the NG setup request in the background check model, according to an embodiment of the present disclosure.

[0267] Herein, the sequence of operations (1502 to 1510) as mentioned in the Figure 15 is same as the sequence of operation explained in Figure 10 (1002 to 1010). Hence, the same has not been explained for the sake of brevity.

[0268] Herein, the first RAN entity 1404 may transmit the at least one proof of evidence in one of the new generation (NG) setup request message and the attestation_request message to the TAF 1402 via the second RAN entity 1442. Additionally, the first RAN entity 1404 may receive the attestation result in response to the transmitted at least one proof of evidence in the NG setup response / failure message via the second RAN entity 1442.

[0269] In an embodiment, attestation may be part of NG Setup for connection between CU and Security Edge Protection Proxy (SEG) / Access and Mobility Management Function (AMF), (N2 Connection) (core n / w) and GPRS Tunneling Protocol - Control Plane (GTP-C) / GPRS Tunneling Protocol - User Plane (GTP-U) connection between CU and SEG / User Plane Function (UPF), (N3 connection). Further, SEG: Security Gateway may be used to terminate the IPSec tunnel before AMF / UPF

[0270] The following modifications are to be incorporated in 3rd Generation Partnership Project 3GPP TS 38.413. Further, 8.7.1.2 NG SETUP REQUEST (Successful Operation) may be performed as follows:

[0271] The NG-RAN node initiates the procedure by sending the NG SETUP REQUEST message, including the appropriate data to the AMF. The AMF responds with an NG SETUP RESPONSE message including the appropriate data only upon attestation evidence is successfully verified.

[0272] id-gnb-Attestation_quote is included to indicate the attestation evidence.

[0273]

[0274] In an embodiment, the 9.3.X.X id-gnb-Attestation_quote may be shown in table 5 below.

[0275]

[0276] Further, the attestation request / response may be present in non-3gpp messages (outside the 3GPP defined 5G message) also between the nodes. Attestation request / response / failure handling may be applicable to future 6G messages as well. Attestation request / response may be present in 3GPP messages like NG SETUP REQUEST etc.

[0277] Figure 16 illustrates a sequence of operations 1600 depicting the attestation process between the first RAN entity 1404, i.e., the CU and the second RAN entity 1442, i.e., the core network via a new message, according to an embodiment of the present disclosure.

[0278] Herein, the sequence of operations (1602 to 1616) as mentioned in the Figure 16 is same as the sequence of operation explained in Figure 11 (1102 to 1116). Hence, the same has not been explained for the sake of brevity.

[0279] Herein, the first RAN entity 1404 may transmit the at least one proof of evidence in one of the new generation (NG) setup request message and the attestation_request message to the TAF 1402 via the second RAN entity 1442. Additionally, the first RAN entity 1404 may receive the attestation result in response to the transmitted at least one proof of evidence in the NG setup response / failure message via the second RAN entity 1442.

[0280] In an embodiment, attestation may be part of NG Setup for connection between CU and Security Edge Protection Proxy (SEG) / Access and Mobility Management Function (AMF), (N2 Connection) (core n / w) and GPRS Tunneling Protocol - Control Plane (GTP-C) / GPRS Tunneling Protocol - User Plane (GTP-U) connection between CU and SEG / User Plane Function (UPF), (N3 connection). Further, SEG: Security Gateway may be used to terminate the IPSec tunnel before AMF / UPF.

[0281] The following modifications are to be incorporated in 3rd Generation Partnership Project 3GPP TS 38.413. In an embodiment, 8.7.1.2 NG SETUP REQUEST (Successful Operation) may be done as follows.

[0282] The NG-RAN node initiates the procedure by sending the NG SETUP REQUEST message including the appropriate data to the AMF. The AMF responds with an NG SETUP RESPONSE message including the appropriate data only upon attestation evidence is successfully verified.

[0283] In an embodiment, the nonce is sent as a challenge to TPM / TEE / HSM present in CU over N2 / N3 connection.

[0284] id-gnb-Attestation_quote is included in a new message to indicate the attestation evidence by CU.

[0285] In an embodiment, 9.3.X.X id-gnb-Attestation_quote and 9.3.X.X nonce may be shown in following tables 6-7.

[0286]

[0287] Further, the attestation request / response may be present in non-3gpp messages (outside the 3GPP defined 5G message) also between the nodes. Attestation request / response / failure handling may be applicable to future 6G messages as well. Attestation request / response may be present in 3GPP messages like a new message between in N2 / N3 connection etc.

[0288] Further, the 9.3.X.X nonce may be shown in table 7 below.

[0289]

[0290] Figure 17 illustrates a sequence of operations 1700 depicting the attestation process between the first RAN entity 1404, i.e., the CU and the second RAN entity 1442, i.e., the core network via the passport model, according to an embodiment of the present disclosure.

[0291] Herein, the sequence of operations (1702 to 1720) as mentioned in the Figure 17 is same as the sequence of operations explained in Figure 12 (1202 to 1220). Hence, the same has not been explained for the sake of brevity.

[0292] Herein, the first RAN entity 1404 may perform the verification and then share the attestation result with the core network (SEG / AMF / UPF).

[0293] In an embodiment, attestation may be part of NG Setup for connection between CU and Security Edge Protection Proxy (SEG) / Access and Mobility Management Function (AMF), (N2 Connection), and GPRS Tunneling Protocol - Control Plane (GTP-C) / GPRS Tunneling Protocol - User Plane (GTP-U) connection between CU and SEG / User Plane Function (UPF), (N3 connection).

[0294] The following modification are to be incorporated in 3rd Generation Partnership Project 3GPP TS 38.413. In an embodiment, 8.7.1.2 NG SETUP REQUEST (Successful Operation) may be performed as follows.

[0295] The NG-RAN node initiates the procedure by sending the NG setup request message including the appropriate data to the AMF. The AMF responds with an NG setup response message including the appropriate data only upon attestation evidence is successfully verified.

[0296] id-gnb-Attestation_result is included to indicate the attestation evidence.

[0297]

[0298] In an embodiment, 9.3.X.X id-gnb-Attestation_result may be shown in the following table 8.

[0299]

[0300] Further, the attestation request / response can be present in non-3gpp messages (outside the 3GPP defined 5G message) also between the nodes. Attestation request / response / failure handling may be applicable to future 6G messages as well. Attestation request / response may be present in 3GPP messages, for example, NG setup request or a new message as in background check model etc.

[0301] Figure 18 illustrates a sequence of operations 1800 depicting the attestation process between the first RAN entity 1404 and the second RAN entity 1442 via IP sec / DTLS / TLS, according to an embodiment of the present disclosure.

[0302] Herein, the sequence of operations (1802 to 1834) as mentioned in the Figure 18 is same as the sequence of operations explained in Figure 13 (1302 to 1334). Hence, the same has not been explained for the sake of brevity.

[0303] In an embodiment, during TLS connection, the core n / w initiates the communication with server CU. For the client to consider the server genuine server needs to present evidence. The core n / w (acting as a relying party) challenges the server CU (as the attester) to provide the evidence. The server CU provides the at least one proof of evidence to the core n / w. Further, the attestation policy may be implementation specific and may be applied at various check points based on level of security required by operator. Attestation can also be embedded as part of IPsec tunnel between the core n / w and the CU.

[0304] Further, in an embodiment, the attestation between the first RAN entity 1404 and the second RAN entity 1442 may be also performed mutually, i.e., the first RAN entity 1404 and the second RAN entity 1442 may be attest each other. In the procedures and models described above, each entity on either side of a secure interaction may require remote attestation of its peer. This process is known as mutual-attestation. Further, to support mutual-attestation, the interaction entities mentioned above may operate independently on either side of the connection.

[0305] Figure 19A illustrates systems 1902, 1926 depicting zero trust architecture 1900 in the first RAN entity and the second RAN entity (fronthaul) via the trust anchor function, according to an embodiment of the present disclosure. Figure 19B illustrates an architecture depicting zero trust architecture 1900 between the first RAN entity 1904 and the second RAN entity 1942 (fronthaul) via the background check model, according to an embodiment of the present disclosure. Figure 19C illustrates an architecture depicting zero trust architecture 1900 between the first RAN entity 1904 and the second RAN entity 1942 (fronthaul) via the passport model, according to an embodiment of the present disclosure. Herein, the first RAN entity 1904 may be RU and the second RAN entity 1942 may be DU.

[0306] Figures 19A to 19C are explained in conjunction for the sake of brevity.

[0307] In an embodiment, the system 1906, implemented in the TAF 1902, may include a processor 1908, a memory 1910, an interface 1924, and one or more modules 1912 (referred to herein as the modules). The constructional and operational details of the processor 1908, the memory 1910, the interface 1924, and the modules 1912 may be same as the constructional and operational details of the processor 602, the memory 604, the modules 606, and the interface 608 as mentioned in Figure 6. Thus, the same has not been explained for the sake of brevity. Herein, the modules 1912 may include an establishing module 1914, a receiving module 1916, a determining module 1918, a transmitting module 1920, and a triggering module 1922.

[0308] In an embodiment, the system 1926, implemented in the first RAN entity 1904, may include a processor 1928, a memory 1930, an interface 1938, and one or more modules 1932 (referred to herein as the modules). The constructional and operational details of the processor 1928, the memory 1930, the interface 1938, and the modules 1932 may be same as the constructional and operational details of the processor 601, the memory 603, the modules 605, and the interface 607 as mentioned in Figure 6. Herein, the modules 1932 may include a receiving module 1934, and a transmitting module 1936.

[0309] In an embodiment, the establishing module 1914 may be configured to establish a communication between the TAF 1902 and the first RAN entity 1904 based on the nonce request setup message.

[0310] Upon establishing communication, the transmitting module 1936 may be configured to transmit at least one proof of evidence to the TAF 1902. The transmitting module 1936 may be configured to transmit the at least one proof of evidence in one of a F2 setup request message and an attestation_request message. The transmitting module 1936 may be configured to transmit the at least one proof of evidence in the one of the F2 setup request message and the attestation_request message via the second RAN entity 1942. The one of the F2 setup request message and the attestation_request message is a new message. Alternatively, the transmitting module 1936 may be configured to transmit the at least one proof of evidence directly to the TAF 1902 (as shown in Figure 19C).

[0311] In an embodiment, prior to transmitting the at least one proof of evidence to the TAF 1902, the receiving module 1934 may be configured to receive the at least one proof of evidence from the attester 1942.

[0312] Thereafter, the receiving module 1916 may be configured to receive the at least one proof of evidence from the first RAN entity 1904 in a request_for_attestation (attestation_quote) message. The first RAN entity 1904 may be one of the CU, the DU, and the RU. The at least one proof of evidence indicates trustworthiness of the first RAN entity 1904. In such an embodiment, the receiving module 1916 may be configured to receive the at least one proof of evidence in the request_for_attestation (attestation_quote) message via the second RAN entity 1942. The request_for_attestation (attestation_quote) message is a new message. Alternatively, the receiving module 1916 may be configured to receive the at least one proof of evidence directly from the first RAN entity 1904 (as shown in Figure 19C).

[0313] The determining module 1918 may be configured to determine an attestation result based on the received at least one proof of evidence. In such an embodiment, the transmitting module 1920 may be configured to transmit the at least one proof of evidence for verification to the verifier 1946. In response, the receiving module 1916 may be configured to receive at least one verification result corresponding to the transmitted at least one proof of evidence from the verifier 1946. Thereafter, the determining module 1918 may be configured to determine the attestation result by validating the received at least one verification result based on one or more pre-defined policy configurations.

[0314] The transmitting module 1920 may be configured to transmit the attestation result to the first RAN entity 1904 in an attestation_response message. In such an embodiment, the transmitting module 1920 may be configured to transmit the attestation result in the attestation_response message via the second RAN entity 1942. Alternatively, the transmitting module 1920 may be configured to transmit the attestation result to the first RAN entity 1904 directly (as shown in Figure 19C). The attestation_response message indicates one of a pass, fail, and score associated with the attestation result.

[0315] In response, the receiving module 1934 may be configured to receive the attestation result in response to the transmitted at least one proof of evidence in a F2 setup response / failure message. The attestation result enables the first RAN entity 1904 to maintain a communication with second RAN entity 1942 based on one or more attestation policy. Additionally, based on the attestation result, the second RAN entity 1942 may deny communication with the first RAN entity 1904.

[0316] Further, to receive the attestation result, the receiving module 1934 may be configured to receive, the attestation result in response to the transmitted at least one proof of evidence in the F2 setup response / failure message via the second RAN entity 1942. The F2 setup response / failure message indicates pass, failure: reason='attestation failure' of the attestation result. Alternatively, the receiving module 1934 may be configured to receive the attestation result from the TAF 1902 directly (as shown in Figure 19C).

[0317] When the receiving module 1934 receives the attestation result from the TAF 1902 directly, then the transmitting module 1936 transmits the attestation result to the second RAN entity 1942. Thereafter, the second RAN entity 1942 verifies the attestation result from the TAF 1902. Upon verification, the attestation result enables the first RAN entity 1904 to maintain the communication with second RAN entity 1942 in the F2 setup response / failure message (as shown in Figure 19C).

[0318] Further, the triggering module 1922 may be configured to trigger one or more events based on the attestation result, where the one or more events are defined in one or more pre-defined policy configurations provided to the TAF 1902. The TAF 1902 may reside in a cloud environment. The TAF 1902 is one of an individual entity or is a network function. The TAF 1902 resides in a SMO associated with the RAN entity.

[0319] Figure 20 illustrates a sequence of operations 2000 depicting the attestation process between the first RAN entity 1904, i.e., the RU and the second RAN entity 1942, i.e., the DU via the F2 setup request in the background check model, according to an embodiment of the present disclosure.

[0320] Herein, the sequence of operations (2002 to 2010) as mentioned in the Figure 20 is same as the sequence of operation explained in Figure 10 (1002 to 1010). Hence, the same has not been explained for the sake of brevity.

[0321] Herein, the first RAN entity 1904 may transmit the at least one proof of evidence in one of the F2 Setup request (attestation_quote) (F2-C / F2-U: eCPRI / SNMP / PTP Setup) and the attestation_request message to the TAF 1902 via the second RAN entity 1942. Additionally, the first RAN entity 1904 may receive the attestation result in response to the transmitted at least one proof of evidence in the F2 setup response / failure message via the second RAN entity 1942.

[0322] Figure 21 illustrates a sequence of operations 2100 depicting the attestation process between the first RAN entity 1904 i.e., the RU and the second RAN entity 1942, i.e., the DU via a new message, according to an embodiment of the present disclosure.

[0323] Herein, the sequence of operations (2102 to 2116) as mentioned in the Figure 21 is same as the sequence of operation explained in Figure 11 (1102 to 1116). Hence, the same has not been explained for the sake of brevity.

[0324] Herein, the first RAN entity 1904 may transmit the at least one proof of evidence in one of the F2 Setup request (attestation_quote) (F2-C / F2-U: eCPRI / SNMP / PTP Setup) and the attestation_request message to the TAF 1902 via the second RAN entity 1942. Additionally, the first RAN entity 1904 may receive the attestation result in response to the transmitted at least one proof of evidence in the F2 setup response / failure message via the second RAN entity 1942.

[0325] Figure 22 illustrates a sequence of operations 2200 depicting the attestation process between the first RAN entity 1904 i.e., the RU and the second RAN entity 1942, i.e., the DU via the passport model, according to an embodiment of the present disclosure.

[0326] Herein, the sequence of operations (2202 to 2220) as mentioned in the Figure 22 is same as the sequence of operations explained in Figure 12 (1202 to 1220). Hence, the same has not been explained for the sake of brevity.

[0327] Herein, the first RAN entity 1904 transmits the attestation result to the second RAN entity in the F2 set-up. Further, the first RAN entity received the validated attestation result in the F2 setup response / failure from the second RAN entity 1942.

[0328] Figure 23 illustrates a sequence of operations 2300 depicting the attestation process between the first RAN entity 1904 i.e., the RU and the second RAN entity 1942, i.e., the DU via IP sec / DTLS / TLS, according to an embodiment of the present disclosure.

[0329] Herein, the sequence of operations (2302 to 2334) as mentioned in the Figure 23 is same as the sequence of operations explained in Figure 13 (1302 to 1334). Hence, the same has not been explained for the sake of brevity.

[0330] In an embodiment, during TLS connection, the core n / w initiates the communication with server RU. For the client to consider the server genuine server needs to present evidence. The core n / w (acting as a relying party) challenges the server RU (as the attester) to provide the evidence. The server RU provides the at least one proof of evidence to the core n / w. Further, the attestation policy may be implementation specific and may be applied at various check points based on level of security required by operator. Attestation can also be embedded as part of IPsec tunnel between the core n / w and the RU.

[0331] Further, in an embodiment, the attestation between the first RAN entity 1904 and the second RAN entity 1942 may be also performed mutually, i.e., the first RAN entity 1904 and the second RAN entity 1942 may be attest each other. In the procedures and models described above, each entity on either side of a secure interaction may require remote attestation of its peer. This process is known as mutual-attestation. Further, to support mutual-attestation, the interaction entities mentioned above may operate independently on either side of the connection.

[0332] Figure 24A illustrates systems 1902, 1926 depicting zero trust architecture 2400 in the first RAN entity and the second RAN entity (Xn interface) via the trust anchor function, according to an embodiment of the present disclosure. Figure 24B illustrates an architecture depicting zero trust architecture 2400 between the first RAN entity 2404 and the second RAN entity 2442 (Xn interface) via the background check model, according to an embodiment of the present disclosure. Figure 24C illustrates an architecture depicting zero trust architecture 2400 between the first RAN entity 2404 and the second RAN entity 2442 (Xn interface) via the passport model, according to an embodiment of the present disclosure. Herein, the first RAN entity 1904 may be a first NG-RAN node and the second RAN entity 1942 may be a second NG-RAN node.

[0333] Figures 24A to 24C are explained in conjunction for the sake of brevity.

[0334] In an embodiment, the system 2406, implemented in the TAF 2402, may include a processor 2408, a memory 2410, an interface 2424, and one or more modules 2412 (referred to herein as the modules). The constructional and operational details of the processor 2408, the memory 2410, the interface 2424, the modules 2412 may be same as the constructional and operational details of the processor 602, the memory 604, the modules 606, and the interface 608 as mentioned in Figure 6. Thus, the same has not been explained for the sake of brevity. Herein, the modules 2412 may include an establishing module 2414, a receiving module 2416, a determining module 2418, a transmitting module 2420, and a triggering module 2422.

[0335] In an embodiment, the system 2426, implemented in the first RAN entity 2404, may include a processor 2428, a memory 2430, an interface 2438, and one or more modules 2432 (referred to herein as the modules). The constructional and operational details of the processor 2428, the memory 2430, the interface 2438, and the modules 2432 may be same as the constructional and operational details of the processor 601, the memory 603, the modules 605, and the interface 607 as mentioned in Figure 6. Herein, the modules 2432 may include a receiving module 2434, and a transmitting module 2436.

[0336] In an embodiment, the establishing module 2414 may be configured to establish a communication between the TAF 2402 and the first RAN entity 2404 based on the nonce request setup message.

[0337] Upon establishment, the transmitting module 2436 may be configured to transmit at least one proof of evidence to the TAF 2402. The transmitting module 2436 may be configured to transmit the at least one proof of evidence in one of a XN setup request message and an attestation_request message. The transmitting module 2436 may be configured to transmit the at least one proof of evidence in the one of the XN setup request message and the attestation_request message via the second RAN entity 2442. The one of the XN setup request message and the attestation_request message is a new message. Alternatively, the transmitting module 2436 may be configured to transmit the at least one proof of evidence directly to the TAF 2402 (as shown in Figure 24C).

[0338] In an embodiment, prior to transmitting the at least one proof of evidence to the TAF 2402, the receiving module 2434 may be configured to receive the at least one proof of evidence from the attester 2442.

[0339] Thereafter, the receiving module 2416 may be configured to receive the at least one proof of evidence from the first RAN entity 2404 in a request_for_attestation (attestation_quote) message. The first RAN entity 2404 may be one of the CU, the DU, and the RU. The at least one proof of evidence indicates trustworthiness of the first RAN entity 2404. In such an embodiment, the receiving module 2416 may be configured to receive the at least one proof of evidence in the request_for_attestation (attestation_quote) message via the second RAN entity 2442. The request_for_attestation (attestation_quote) message is a new message. Alternatively, the receiving module 2416 may be configured to receive the at least one proof of evidence directly from the first RAN entity 2404 (as shown in Figure 24C).

[0340] The determining module 2418 may be configured to determine an attestation result based on the received at least one proof of evidence. In such an embodiment, the transmitting module 2420 may be configured to transmit the at least one proof of evidence for verification to the verifier 2446. In response, the receiving module 2416 may be configured to receive at least one verification result corresponding to the transmitted at least one proof of evidence from the verifier 2446. Thereafter, the determining module 2418 may be configured to determine the attestation result by validating the received at least one verification result based on one or more pre-defined policy configurations.

[0341] Further, after determining the attestation result, the transmitting module 2420 may be configured to transmit the attestation result to the first RAN entity 2404 in an attestation_response message. In such an embodiment, the transmitting module 2420 may be configured to transmit the attestation result in the attestation_response message via the second RAN entity 2442. Alternatively, the transmitting module 2420 may be configured to transmit the attestation result to the first RAN entity 2404 directly (as shown in Figure 24C). The attestation_response message indicates one of a pass, fail, and score associated with the attestation result.

[0342] In response, the receiving module 2434 may be configured to receive the attestation result in response to the transmitted at least one proof of evidence in a XN setup response / failure message. The attestation result enables the first RAN entity 2404 to maintain a communication with the second RAN entity 2442 based on one or more attestation policy. Additionally, based on the attestation result, the second RAN entity 2442 may deny communication with the first RAN entity 2404.

[0343] In such an embodiment, the receiving module 2434 may be configured to receive, the attestation result in response to the transmitted at least one proof of evidence in the XN setup response / failure message via the second RAN entity 2442. The XN setup response / failure message indicates one of a pass, failure: reason='attestation failure' of the attestation result. Alternatively, the receiving module 2434 may be configured to receive the attestation result from the TAF 2402 directly (as shown in Figure 24C).

[0344] When the receiving module 2434 receives the attestation result from the TAF 2402 directly, then the transmitting module 2436 transmits the attestation result to the second RAN entity 2442. Thereafter, the second RAN entity 2442 verifies the attestation result from the TAF 2402. Upon verification, the attestation result enables the first RAN entity 2404 to maintain the communication with second RAN entity 2442 in the XN setup response / failure message (as shown in Figure 24C).

[0345] Further, the triggering module 2422 may be configured to trigger one or more events based on the attestation result, where the one or more events are defined in one or more pre-defined policy configurations provided to the TAF 2402. The TAF 2402 may reside in a cloud environment. The TAF 2402 is one of an individual entity or is a network function. The TAF 2402 resides in a SMO associated with the associated with the RAN entity.

[0346] Figure 25 illustrates a sequence of operations 2500 depicting the attestation process between the first RAN entity 2404, i.e., the first NG-RAN node and the second RAN entity 1942, i.e., the second NG-RAN node via the XN setup request in the background check model, according to an embodiment of the present disclosure.

[0347] Herein, the sequence of operations (2502 to 2510) as mentioned in the Figure 25 is same as the sequence of operation explained in Figure 10 (1002 to 1010). Hence, the same has not been explained for the sake of brevity.

[0348] Herein, the first RAN entity 2404 may transmit the at least one proof of evidence in one of the XN Setup request and the attestation_request message to the TAF 2402 via the second RAN entity 2442. Additionally, the first RAN entity 2404 may receive the attestation result in response to the transmitted at least one proof of evidence in the XN setup response / failure message via the second RAN entity 2542.

[0349] The following modifications are to be incorporated in 3rd Generation Partnership Project 3GPP TS 38.423. In an embodiment, 8.4.1 XN SETUP may be performed as follows.

[0350] The NG-RAN node1 (the first NG-RAN node) initiates the procedure by sending the XN SETUP REQUEST message to the candidate NG-RAN node2 (the second NG-RAN node). The candidate NG-RAN node2 replies with the XN SETUP RESPONSE message only upon attestation evidence is successfully verified.

[0351] nonce message is sent as a challenge to TPM / TEE / HSM present in gNB over XN connection.

[0352] id-gnb-Attestation_quote is included to indicate the attestation evidence.

[0353]

[0354] In an embodiment, 9.3.X.X id-gnb-Attestation_quote may be shown in following table 9 and 9.3.X.X nonce may be shown in table 10.

[0355]

[0356] Further, the attestation request / response may be present in non-3gpp messages (outside the 3GPP defined 5G message) also between the nodes. Attestation request / response / failure handling may be applicable to future 6G messages as well. Attestation request / response may be present in 3GPP messages like XN SETUP REQUEST or a new message etc.

[0357] The 9.3.X.X nonce may be shown in table 10 below.

[0358]

[0359] Figure 26 illustrates a sequence of operations 2600 depicting the attestation process between the first RAN entity 2404 i.e., the first NG-RAN node and the second RAN entity 2442, i.e., the second NG-RAN node via a new message, according to an embodiment of the present disclosure.

[0360] Herein, the sequence of operations (2602 to 2616) as mentioned in the Figure 26 is same as the sequence of operation explained in Figure 11 (1102 to 1116). Hence, the same has not been explained for the sake of brevity.

[0361] Herein, the first RAN entity 2404 may transmit the at least one proof of evidence in one of the XN Setup request (and the attestation_request message to the TAF 2602 via the second RAN entity 2642. Additionally, the first RAN entity 2604 may receive the attestation result in response to the transmitted at least one proof of evidence in the XN setup response / failure (SUCCESS / FAILURE: Reason = "attestation failure") via the second RAN entity 1942.

[0362] Figure 27 illustrates a sequence of operations 2700 depicting the attestation process between the first RAN entity 2404 i.e., the first NG-RAN node and the second RAN entity 2442, i.e., the second NG-RAN node via the passport model, according to an embodiment of the present disclosure.

[0363] Herein, the sequence of operations (2702 to 2720) as mentioned in the Figure 22 is same as the sequence of operations explained in Figure 12 (1202 to 1220). Hence, the same has not been explained for the sake of brevity.

[0364] Herein, the first RAN entity 2402 transmits the attestation result to the second RAN entity in the XN set-up. Further, the first RAN entity received the validated attestation result in the XN setup response / failure from the second RAN entity 2442.

[0365] Figure 28 illustrates a sequence of operations 2800 depicting the attestation process between the first RAN entity 2404 i.e., the first NG-RAN node and the second RAN entity 2442, i.e., the second NG-RAN node via IP sec / DTLS / TLS, according to an embodiment of the present disclosure.

[0366] Herein, the sequence of operations (2802 to 2834) as mentioned in the Figure 28 is same as the sequence of operations explained in Figure 13 (1302 to 1334). Hence, the same has not been explained for the sake of brevity.

[0367] In an embodiment, during TLS connection, the second NG-RAN node initiates the communication with the first NG-RAN node. For the client to consider the server genuine server needs to present evidence. The second NG-RAN node (acting as a relying party) challenges the first NG-RAN node (as the attester) to provide the evidence. The first NG-RAN node provides the at least one proof of evidence to the second NG-RAN node. Further, the attestation policy may be implementation specific and may be applied at various check points based on level of security required by operator. Attestation can also be embedded as part of IPsec tunnel between the second NG-RAN node and first NG-RAN node.

[0368] Further, in an embodiment, the attestation between the first RAN entity 2404 and the second RAN entity 2442 may be also performed mutually, i.e., the first RAN entity 2404 and the second RAN entity 2442 may attest each other. In the procedures and models described above, each entity on either side of a secure interaction may require remote attestation of its peer. This process is known as mutual-attestation. Further, to support mutual-attestation, the interaction entities mentioned above may operate independently on either side of the connection.

[0369] The method 2900 includes a series of operations shown at step 2902 through step 2908 of Figure 29. The method 2900 may be performed by the system 610 in conjunction with modules 606, the details of which are explained in conjunction with Figures 6 to 8, and the same are not repeated here for the sake of brevity in the present disclosure. The method 2900 begins at step 2902.

[0370] At step 2902, the method 2900 includes establishing, by the TAF 560, the communication between a first RAN entity 520 and the TAF 560 based on the nonce message. The first RAN entity 520 may include one of the CU, the DU, and the RU. The method 2900 includes establishing, via the second RAN entity 540, the communication between the first RAN entity 520 and the TAF 560.

[0371] At step 2904, the method 2900 includes receiving, by the TAF 560, based on the established communication, the at least one proof of evidence from the first RAN entity 520. The at least one proof of evidence indicates trustworthiness of the first RAN entity 520.

[0372] The method 2900 includes receiving, via the second RAN entity 540, the at least one proof of evidence in the request_for_attestation message. The request_for_attestation message is the new message.

[0373] At step 2906, the method 2900 includes determining, by the TAF 560, the attestation result based on the received at least one proof of evidence.

[0374] The method 2900 includes transmitting, to the verifier 570, the at least one proof of evidence for verification. The method 3100 includes receiving, from the verifier 570, at least one verification result corresponding to the transmitted at least one proof of evidence. The method 2900 includes determining the attestation result by validating the received at least one verification result based on one or more pre-defined policy configurations.

[0375] At step 2908, the method 2900 includes transmitting, by the TAF 560, the attestation result to the first RAN entity 520. The attestation result enables the first RAN entity to maintain the communication with second RAN entity 540 via the plurality of communication channels.

[0376] The method 2900 includes transmitting, via the second RAN entity 540, the attestation result in an attestation response message. The attestation response message indicates one of pass, fail, and a score associated with the attestation result.

[0377] The method 2900 includes triggering the one or more events based on the attestation result. The one or more events are defined in one or more pre-defined policy configurations provided to the TAF 560.

[0378] The TAF 560 resides in the cloud environment. The TAF 560 is one of the individual network entity or the network function. resides in a SMO associated with the RAN entity.

[0379] The method 3000 includes a series of operations shown at step 3002 through step 3008 of Figure 30. The method 3000 may be performed by the system 620 in conjunction with modules 605, the details of which are explained in conjunction with Figures 6 to 8, and the same are not repeated here for the sake of brevity in the present disclosure. The method 3000 begins at step 3002.

[0380] At step 3002, the method 3000 includes enabling certificate retrieval of the first RAN entity 520 using the User-based Security Model (USM) 801.

[0381] At step 3004, the method 3000 includes receiving, by the first RAN entity 520, at least one proof of evidence from the attester 530. The at least one proof of evidence indicates trustworthiness of the first RAN entity 520.

[0382] At step 3006, the method 3000 includes transmitting, to the TAF 560, the at least one proof of evidence.

[0383] At step 3008, in response to the transmitted at least one proof of evidence, the method 3000 includes receiving, by the first RAN entity 520, , the attestation result from the TAF 560. The attestation result enables the first RAN entity 520 to maintain the communication with the second RAN entity 540 based on the provisioning of the certificate.

[0384] The method 3000 includes receiving, via the second RAN entity 540, the attestation result in one of the OTP message, OTP_Key message. Further, the provisioning of the certificate indicates one of the pass, fail, and score associated with the attestation result. The first RAN entity 520 may include one of the CU, the DU, and the RU.

[0385] The method 3100 includes a series of operations shown at step 3102 through step 3108 of Figure 31. The method 3100 may be performed by the system 906, 1406, 1906, 2406 in conjunction with modules 912, 1412, 1912, 2412, the details of which are explained in conjunction with Figures 9B to 28, and the same are not repeated here for the sake of brevity in the present disclosure. The method 3100 begins at step 3102.

[0386] At step 3102, the method 3100 includes establishing, by the TAF 902, 1402, 1902, 2402, a communication between the TAF 902, 1402, 1902, 2402 and the first RAN entity 904, 1404, 1904, 2404 based on the nonce request setup message.

[0387] At step 3104, the method 3100 includes receiving, by the TAF 902, 1402, 1902, 2402, the at least one proof of evidence from the first RAN entity 904, 1404, 1904, 2404 in the request_for_attestation (attestation_quote) message. The at least one proof of evidence indicates trustworthiness of the first RAN entity 904.

[0388] The method 3100 includes receiving, via the second RAN entity 942, 1442, 1942, 2442, the at least one proof of evidence in the request_for_attestation (attestation_quote) message. The request_for_attestation (attestation_quote) message is the new message.

[0389] At step 3106, the method 3100 includes determining, by the TAF 902, 1402, 1902, 2402, the attestation result based on the received at least one proof of evidence.

[0390] The method 3100 includes transmitting, to the verifier 946, 1446, 1946, 2446, the at least one proof of evidence for verification. The method 3100 includes receiving, from the verifier 946, 1446, 1946, 2446, at least one verification result corresponding to the transmitted at least one proof of evidence. The method 3100 includes determining the attestation result by validating the received at least one verification result based on one or more pre-defined policy configurations.

[0391] At step 3108, the method 3100 includes transmitting, by the TAF 902, 1402, 1902, 2402, the attestation result to the first RAN entity 904, 1404, 1904, 2404 in the attestation_response message. The attestation result enables the first RAN entity 904, 1404, 1904, 2404 to maintain the communication with the second RAN entity 942, 1442, 1942, 2442.

[0392] The method 3100 includes transmitting, via the second RAN entity 942, 1442, 1942, 2442, the attestation result in the attestation_response message. The attestation_response message indicates one of the pass, fail, and score associated with the attestation result.

[0393] The method 3100 includes triggering the one or more events based on the attestation result, where the one or more events are defined in one or more pre-defined policy configurations provided to the TAF 902, 1402, 1902, 2402. The TAF 902, 1402, 1902, 2402 resides in the cloud environment. The TAF 902, 1402, 1902, 2402 is one of the individual entity or is the network function. The TAF 902, 1402, 1902, 2402 resides in the SMO associated with the RAN entity.

[0394] The method 3200 includes a series of operations shown at step 3202 through step 3204 of Figure 32. The method 3200 may be performed by the system 926, 1426, 1926, 2426 in conjunction with modules 932, 1432, 1932, 2432, the details of which are explained in conjunction with Figures 9B to 24C, and the same are not repeated here for the sake of brevity in the present disclosure. The method 3200 begins at step 3202.

[0395] At step 3202, the method 3200 includes transmitting, to the TAF 902, 1402, 1902, 2402, the at least one proof of evidence in one of the request message. The at least one proof of evidence indicates trustworthiness of the first RAN entity 904, 1404, 1904, 2404.

[0396] The one of the request message may include the F1 setup request message, the NG setup request message, the F2 setup request message, the XN setup request message, and the attestation_request message.

[0397] The one of the response message may include the F1 setup response / failure message, the NG setup response / failure message, the F2 setup response / failure message, and the XN setup response / failure message.

[0398] The method 3200 includes transmitting, via the second RAN entity 942, 1442, 1942, 2442 to the TAF 902, 1402, 1902, 2402, the at least one proof of evidence in the one of the request message. The one of the request message is the new message.

[0399] Prior to transmitting the at least one proof of evidence to the TAF 902, 1402, 1902, 2402, the method 3200 includes receiving the at least one proof of evidence from the attester 940, 1440, 1940, 2440.

[0400] At step 3204, in response to the transmitted at least one proof of evidence, the method 3200 includes receiving, by the first RAN entity 904, 1404, 1904, 2404, the attestation result from the TAF 902, 1402, 1902, 2402 in one of the response message. The attestation result enables the first RAN entity 904, 1404, 1904, 2404 to maintain the communication with second RAN entity 942, 1442, 1942, 2442.

[0401] The method 3200 includes receiving, via the second RAN entity 942, 1442, 1942, 2442 from the TAF 902, 1402, 1902, 2402, the attestation result in response to the transmitted at least one proof of evidence in the response message. The response message indicates one of the pass, fail, failure: reason='attestation failure', and score of the attestation result. The first RAN entity 904, 1404, 1904, 2404 may include one of the CU, the DU, and the RU.

[0402] Further, the detailed explanation of the method as performed by each system 926, 1426, 1926, 2426 may be explained in detail in the subsequent paragraphs.

[0403] The method 3300 includes a series of operations shown at step 3302 through step 3304 of Figure 33. The method 3300 may be performed by the system 926 in conjunction with modules 932, the details of which are explained in conjunction with Figures 9B to 13, and the same are not repeated here for the sake of brevity in the present disclosure. The method 3300 begins at step 3302.

[0404] At step 3302, the method 3300 includes transmitting, to the TAF 902, the at least one proof of evidence in one of the F1 setup request message and the attestation_request message. The at least one proof of evidence indicates trustworthiness of the first RAN entity 904.

[0405] The method 3300 includes transmitting, via the second RAN entity 942 to the TAF 902, the at least one proof of evidence in the one of the F1 setup request message and the attestation_request message, The one of the F1 setup request message and the attestation_request message is the new message.

[0406] Prior to transmitting the at least one proof of evidence to the TAF 902, the method 3200 includes receiving the at least one proof of evidence from the attester 940.

[0407] At step 3304, in response to the transmitted at least one proof of evidence, the method 3200 includes receiving, by the first RAN entity 904, the attestation result from the TAF 902 in the F1 setup response / failure message. The attestation result enables the first RAN entity 904 to maintain the communication with second RAN entity 942.

[0408] The method 3300 includes receiving, via the second RAN entity 942 from the TAF 902, the attestation result in response to the transmitted at least one proof of evidence in the F1 setup response / failure message. The F1 setup response / failure message indicates one of the pass, fail, and score of the attestation result. The first RAN entity 904 may include one of the CU, the DU, and the RU.

[0409] The method 3400 includes a series of operations shown at step 3402 through step 3404 of Figure 34. The method 3400 may be performed by the system 1426 in conjunction with modules 1432, the details of which are explained in conjunction with Figures 14B to 18, and the same are not repeated here for the sake of brevity in the present disclosure. The method 3400 begins at step 3402.

[0410] At step 3402, the method 3400 includes transmitting, to the TAF 1402, at least one proof of evidence in one of the NG setup request message and the attestation_request message. The at least one proof of evidence indicates trustworthiness of the first RAN entity 1404.

[0411] The method 3400 includes transmitting, via the second RAN entity 1442 to the TAF 1402, the at least one proof of evidence in the one of the NG setup request message and the attestation_request message. The one of the NG setup request message and the attestation_request message is the new message.

[0412] Prior to transmitting the at least one proof of evidence to the TAF 1402, the method 3400 includes receiving the at least one proof of evidence from the attester 1440.

[0413] At step 3404, in response to the transmitted at least one proof of evidence, the method 3400 includes receiving, by the first RAN entity 1404, the attestation result from the TAF 1402 in the NG setup response / failure message. The attestation result enables the first RAN 1404 entity to maintain the communication with second RAN entity 1442.

[0414] The method 3400 includes receiving, via the second RAN entity 1442 from the TAF 1402, the attestation result in response to the transmitted at least one proof of evidence in the NG setup response / failure message. The NG setup response / failure message indicates one of the pass, failure: reason='attestation failure' of the attestation result. The first RAN entity may include one of the CU, the DU, and the RU.

[0415] The method 3500 includes a series of operations shown at step 3502 through step 3504 of Figure 35. The method 3500 may be performed by the system 1926 in conjunction with modules 1932, the details of which are explained in conjunction with Figures 19B to 23, and the same are not repeated here for the sake of brevity in the present disclosure. The method 3500 begins at step 3502.

[0416] At step 3502, the method 3500 includes transmitting, to the TAF 1902, at least one proof of evidence in one of the F2 setup request message and the attestation_request message. The at least one proof of evidence indicates trustworthiness of the first RAN entity 1904.

[0417] The method 3500 includes transmitting, via the second RAN entity 1942 to the TAF 1902, the at least one proof of evidence in the one of the F2 setup request message and the attestation_request message. The one of the F2 setup request message and the attestation_request message is the new message.

[0418] Prior to transmitting the at least one proof of evidence to the TAF 1902, the method 3500 includes receiving the at least one proof of evidence from the attester 1940.

[0419] At step 3504, in response to the transmitted at least one proof of evidence, the method 3500 includes receiving, by the first RAN entity 1904, the attestation result from the TAF 1902 in the F2 setup response / failure message. The attestation result enables the first RAN entity 1904 to maintain the communication with second RAN entity 1942.

[0420] The method 3500 includes receiving, via the second RAN entity 1942 from the TAF 1902, the attestation result in response to the transmitted at least one proof of evidence in the F2 setup response / failure message. The F2 setup response / failure message indicates one of the pass, failure: reason='attestation failure' of the attestation result. The first RAN entity 1904 may include one of the CU, the DU, and the RU.

[0421] The method 3600 includes a series of operations shown at step 3602 through step 3604 of Figure 36. The method 3600 may be performed by the system 2426 in conjunction with modules 2432, the details of which are explained in conjunction with Figures 24B to 28, and the same are not repeated here for the sake of brevity in the present disclosure. The method 3600 begins at step 3602.

[0422] At step 3602, the method 3600 includes transmitting, to the TAF 2402, at least one proof of evidence in one of the XN setup request message and the attestation_request message. The at least one proof of evidence indicates trustworthiness of the first RAN entity 2404.

[0423] The method 3600 includes transmitting, via the second RAN entity 2442 to the TAF 2402, the at least one proof of evidence in the one of the XN setup request message and the attestation_request message. The one of the XN setup request message and the attestation_request message is the new message.

[0424] Prior to transmitting the at least one proof of evidence to the TAF 2402, the method 3600 includes receiving the at least one proof of evidence from the attester 2440.

[0425] At step 3604, in response to the transmitted at least one proof of evidence, the method 3600 includes receiving, by the first RAN entity 2404, the attestation result from the TAF 2402 in the XN setup response / failure message. The attestation result enables the first RAN entity 2402 to maintain communication with second RAN entity 2442.

[0426] The method 3600 includes receiving, via the second RAN entity 2442 from the TAF 2402, the attestation result in response to the transmitted at least one proof of evidence in the XN setup response / failure message. The XN setup response / failure message indicates one of the pass, failure: reason='attestation failure' of the attestation result. The first RAN entity may include one of the CU, the DU, and the RU.

[0427] As would be gathered, the systems 610, 620, 906, 926, 1406, 1426, 1906, 1926, 2406, 2426 and the methods 2900, 3000, 3100, 3200, 3300, 3400, 3500, and 3600 as disclosed are for 3GPP standard and may impact the standards especially, 3GPP TS 38.413, 38.423, 38.471, and 33.501 for 5G Ultra (advanced) and 6G. The systems and the methods as disclosed provides a secures cloud based communication between the first RAN entity and the second RAN entity.

[0428] Figure 37 is a block diagram of a terminal or user equipment (UE) 3700 according to an embodiment of the disclosure.

[0429] The terminal is an electronic device capable of wireless communication, may include a User Equipment (UE), a portable phone, a smartphone, a tablet, an Internet of things (IoT) device, etc., having various form factors, and may perform wireless communication with a base station (BS) through a wireless channel.

[0430] Referring to Figure 37, the UE 3700 may include at least one transceiver (hereinafter, referred to as simply "transceiver") 3701, at least one processor (hereinafter, referred to as simply "processor") 3702, and at least one memory (hereinafter, referred to as simply "memory") 3703. According to at least one or a combination of methods corresponding to the embodiments described in the present disclosure, the transceiver 3701, the processor 3702, and the memory 3703 of the UE 3700 may operate. However, components of the UE 3700 are not limited to the exemplary components illustrated in Figure 37. In another embodiment, the UE 3700 may further include additional components in addition to the above-mentioned components, or some components may be omitted. Further, in some embodiments, any combination of the transceiver 3701, the processor 3702, or the memory 3703 may be integrated in the form of one component.

[0431] The transceiver 3701 may be a communication circuit or communication circuitry that enables the UE 3700 to perform wireless communication with a node or an entity of a network. For example, the transceiver 3701 may enable the UE 3700 to transmit or receive a signal to or from a BS through cellular communication, or to transmit or receive a signal to or from another UE through cellular communication. For example, the transceiver 3701 may support at least one of various cellular communication technologies including 3rd generation (3G), 4th generation (4G), long term evolution (LTE), 5th generation (5G) NR, 6th generation (6G), and various cellular wireless communication technologies supported by the transceiver (3701) may include all subsequent generations of evolved wireless communications.

[0432] According to an embodiment, the UE 3700 may include a plurality of transceivers. For example, in the case of supporting evolved-universal terrestrial radio access-new radio (E-UTRA-NR) sual connectivity (EN-DC), the UE 3700 may include a first transceiver supporting the 4G LTE wireless communication and a second transceiver supporting the 5G NR wireless communication. According to another embodiment, in the case of supporting NR-dual connectivity (NR-DC), the UE 3700 may include a plurality of transceivers supporting the 5G NR wireless communication. According to still another embodiment, in the case of supporting near field wireless communication, the UE 3700 may separately include a transceiver supporting at least one standard in the group of wireless communication protocol standards as defined in the protocol standards for Bluetooth®, wireless local area network (WLAN) network (including institute of electrical and electronics engineers (IEEE) 802.11-2016 standard or its amendments, e.g., 802.11ah, 802.11ad, 802.11ay, 802.11ax, 802.11az, 802.11ba, and 802.11be, without being limited thereto).

[0433] According to an embodiment, the transceiver 3701 may include various circuit structures used to transmit or receive signals to or from a BS through a wireless channel. The signals may include control information and data. For example, the transceiver 3701 may include a radio frequency (RF) transmitter for up-converting and amplifying the frequency of a transmitted signal and an RF receiver for low-noise-amplifying a received signal and down-converting the frequency thereof. The transceiver 3701 may output a signal received through a wireless channel to the processor 3702 and may transmit, through a wireless channel, a signal output from the processor 3702.

[0434] The processor 3702 may control general operations of the UE 3700 according to embodiments of the disclosure. The processor 3702 may be implemented by one or more integrated circuit (or circuitry) (IC) chips and may execute various data processings. The processor 3702 may include at least one electric circuit, and may execute instructions (or a program, codes, data, etc.) stored in the memory 3703, individually, collectively or in any combination thereof. Further, the processor 3702 may include a single-core processor or multi-core processor, and may include a processor assembly including a plurality of processing circuits (circuitry) according to a specific implementation scheme.

[0435] The processor 3702 may be electrically, operatively, or communicatively coupled to the transceiver 3701 to control the transceiver 3701.

[0436] The processor 3702 may include at least one processor (or processing circuitry), and the at least one processor may perform the following operations individually, collectively or in any combination thereof. For example, the processor 3702 may include a communication processor (CP) configured to control communication operations and an application processor (AP) configured to control execution of an upper layer (for example, an application layer) . In a specific embodiment, at least a part of the processor 3702 may be included in one chip and the other part of the processor 3702 may be included in another chip. Otherwise, at least one processor may be included in another component, for example, the transceiver 3701 or the memory 3703.

[0437] The processor 3702 may perform or control or cause an operation of the UE 3700 for executing at least one or a combination of methods according to embodiments of the disclosure. For example, the processor 3702 may control operations of the UE 3700 for processing a downlink signal received from a BS or generating and transmitting an uplink signal to a BS. To this end, the processor 3702 may execute a computer program, codes, or instructions stored in the memory 3703, so as to control other components of the UE 3700 to enable execution of various operations.

[0438] The memory 3703 corresponds to a hardware storage device capable of temporarily or permanently storing information and may include one or more storage media. For example, the memory 3703 may include a memory assembly including one or more storage media. For example, the one or more storage media may include permanent memory, such as a hard drive, flash memory, or read-only memory (ROM), semipermanent memory, such as random access memory (RAM), cache memory, or a combination thereof.

[0439] The memory 3703 may be electrically, operatively, or communicatively coupled to the processor 3702 and may be accessed by the processor 3702.

[0440] The memory 3703 may store a computer program, codes, or instructions executable by the processor 3702. According to an embodiment, a computer program, codes, or instructions executable by the processor 3702 may be either stored in a single memory device or separated and distributedly stored in two or more memory devices. By executing the instructions stored in the memory 3703, the processor 3702 may perform various functions according to an embodiment of the disclosure.

[0441] According to an embodiment of the disclosure, operations of the UE 3700 may be caused to be performed based on execution of instructions (or a computer program or codes) stored in the memory 3703 by at least one processor (or processing circuitry) configured to execute the same individually, collectively, or in any combination thereof, based on processing circuitry that is not configured to execute instructions, and / or based on components of processing circuitry that is not configured to execute instructions.

[0442] FIG. 38 is a block diagram of a base station (BS) 3800 according to an embodiment of the disclosure. Furthermore, the base station of FIG. 38 may correspond to the first RAN entity of FIG. 9A, FIG. 9B, FIG. 9C, FIG. 14A, FIG. 14B, FIG. 14C, FIG. 19A, FIG. 19B, FIG. 19C, FIG. 24A, FIG. 24B, FIG. 24C.

[0443] The BS 3800 may perform wireless communication with at least one user equipment (UE) located within the area of the BS 3800 through a wireless channel.

[0444] Referring to Figure 38, the BS 3800 may include at least one transceiver (hereinafter, referred to as simply "transceiver") 3801, at least one processor (hereinafter, referred to as simply "processor") 3802, and at least one memory (hereinafter, referred to as simply "memory") 3803. According to at least one or a combination of methods corresponding to the embodiments described in the present disclosure, the transceiver 3801, the processor 3802, and the memory 3803 of the BS 3800 may operate. However, components of the BS 3800 are not limited to the exemplary components illustrated in Figure 38. In another embodiment, the BS 3800 may further include additional components in addition to the above-mentioned components, or some components may be omitted. Further, in some embodiments, any combination of the transceiver 3801, the processor 3802, or the memory 3803 may be integrated in the form of one component.

[0445] The transceiver 3801 may be a communication circuit or communication circuitry that enables the BS 3800 to perform wireless communication with a node or an entity of a network. For example, the transceiver 3801 may enable the BS 3800 to transmit or receive a signal to or from the UE 3700 through cellular communication, or to transmit or receive a signal to or from another network entity through wireless communication. For example, the transceiver 3801 may support various cellular communication technologies including 3rd generation (3G), 4th generation (4G), long term evolution (LTE), 5th generation (5G) NR, 6th generation (6G), and various cellular wireless communication technologies supported by the transceiver (3801) may include all subsequent generations of evolved wireless communications. According to an embodiment, the transceiver 3801 may include various circuit structures used to transmit or receive signals to or from a UE through a wireless channel. The signals may include control information and data. For example, the transceiver 3801 may include a radio frequency (RF) transmitter for up-converting and amplifying the frequency of a transmitted signal and an RF receiver for low-noise-amplifying a received signal and down-converting the frequency thereof. The transceiver 3801 may output a signal received through a wireless channel to the processor 3802 and may transmit, through a wireless channel, a signal output from the processor 3802.

[0446] Meanwhile, according to an embodiment of the present disclosure, the BS 3800 may perform communication with a node or an entity of a network through wired or wireless communication. For example, the BS 3800 may perform wired or wireless communication with an adjacent BS, or a node or an entity of a core network through a backhaul network. Although not illustrated in Figure 38, when the BS 3800 performs wired communication, the BS 3800 may further include a separate network interface for wired communication in addition to the transceiver 3801. The network interface may be referred to as network interface circuitry or communication interface circuitry.

[0447] The processor 3802 may control general operations of the BS 3800 according to embodiments of the disclosure. The processor 3802 may be implemented by one or more integrated circuit (or circuitry) (IC) chips and may execute various data processings. The processor 3802 may include at least one electric circuit, and may execute instructions (or a program, codes, data, etc.) stored in the memory 3803, individually, collectively or in any combination thereof. Further, the processor 3802 may include a single-core processor or multi-core processor, and may include a processor assembly including a plurality of processing circuits (circuitry) according to a specific implementation scheme.

[0448] The processor 3802 may be electrically, operatively, or communicatively coupled to the transceiver 3801 to control the transceiver 3801.

[0449] The processor 3802 may include at least one processor (or processing circuitry), and the at least one processor may perform the following operations individually, collectively or in any combination thereof. In a specific embodiment, at least a part of the processor 3802 may be included in one chip and the other part of the processor 3802 may be included in another chip. Otherwise, at least one processor may be included in another component, for example, the transceiver 3801 or the memory 3803.

[0450] The processor 3802 may perform or control or cause an operation of the BS 3800 for executing at least one or a combination of methods according to embodiments of the disclosure. For example, the processor 3802 may control operations of the BS 3800 for generating and transmitting a downlink signal to a UE or processing an uplink signal received from a UE. Otherwise, the BS 3800 may transmit or receive a signal to or from a neighboring BS, transfer a signal received from a UE to an upper node of the network, or transmit a signal transferred from an upper node of the network to a UE. To this end, the processor 3802 may execute a computer program, codes, or instructions stored in the memory 3803, so as to control other components of the BS 3800 to enable execution of various operations.

[0451] The memory 3803 corresponds to a hardware storage device capable of temporarily or permanently storing information and may include one or more storage media. For example, the memory 3803 may include a memory assembly including one or more storage media. For example, the one or more storage media may include permanent memory, such as a hard drive, flash memory, or read-only memory (ROM), semipermanent memory, such as random access memory (RAM), cache memory, or a combination thereof.

[0452] The memory 3803 may be electrically, operatively, or communicatively coupled to the processor 3802 and may be accessed by the processor 3802.

[0453] The memory 3803 may store a computer program, codes, or instructions executable by the processor 3802. According to an embodiment, a computer program, codes, or instructions executable by the processor 3802 may be either stored in a single memory device or separated and distributedly stored in two or more memory devices. By executing the instructions stored in the memory 3803, the processor 3802 may perform various functions according to an embodiment of the disclosure.

[0454] According to an embodiment of the disclosure, operations of the BS 3800 may be caused to be performed based on execution of instructions (or a computer program or codes) stored in the memory 3803 by at least one processor (or processing circuitry) configured to execute the same individually, collectively, or in any combination thereof, based on processing circuitry that is not configured to execute instructions, and / or based on components of processing circuitry that is not configured to execute instructions.

[0455] The UE or the base station may perform various communication procedures related to the control plane or the user plane by cooperating with one or more network entities based on wireless communication. For example, the UE may communicate with network entity such as an Access and Mobility Management Function (AMF) or a Session Management Function (SMF) via the base station, or the base station may perform at least one communication procedure by directly transmitting and receiving signals to / from, or relaying signals between, the network entities.

[0456] The structure of the above-described network entity will be described in more detail with reference to the drawings.

[0457] Figure 39 is a block diagram of a network entity 3900 according to an embodiment of the disclosure. Furthermore, the network entity of Figure 39 may correspond to the trust anchor function of FIG. 9A, FIG. 9B, FIG. 9C, FIG. 14A, FIG. 14B, FIG. 14C, FIG. 19A, FIG. 19B, FIG. 19C, FIG. 24A, FIG. 24B, FIG. 24C.

[0458] The network entity 3900 may include an entity (apparatus, device, or server, etc.) that performs one or more network functions (NFs) or a part of a network function constituting a core network (e.g., a 5th generation (5G) core (5GC)) in a communication system. In this case, multiple NFs may be implemented within a single network entity, or a single NF may be distributed and implemented across a plurality of network entities. In addition, when an NF is implemented within the network entity, the NF may be implemented in the form of software, and in such a case, a program for operating the NF may be stored in memory of the network entity 3900.

[0459] A single NF may be implemented by one or more instances, which may be deployed on the same network entity or distributed across multiple network entities to operate. The instance may be a software unit that logically executes a specific network function, and may be implemented in a form that is decoupled from physical hardware resources. Further, one or more NFs may be implemented in the form of one network slice to operate to satisfy specifications required by a particular service.

[0460] The NF may include at least one of an access and mobility management function (AMF), a session management function (SMF), a local session management function (L-SMF), a user plane function (UPF), a local user plane function (L-UPF), a policy control function (PCF), a unified data management (UDM), a unified data repository (UDR), a network exposure function (NEF), a network repository function (NRF), an application function (AF), a network slice selection function (NSSF), a network data analytics function (NWDAF), a network slice admission control function (NSACF), an authentication server function (AUSF), or a data network (DN).

[0461] Referring to Figure 39, the network entity 3900 may include at least one network interface 3901, at least one processor 3902 (hereinafter, "processor"), and at least one memory 3903 (hereinafter, "memory"). As described above, a NF may be implemented in the form of a physical device such as the network entity 3900, or may be virtualized and executed in the form of an instance. When implemented as an instance, the NF need not necessarily include physical components as illustrated in Figure 39. In such a case, the instance may be logically represented as comprising one or more logical functional elements.

[0462] According to at least one or a combination of methods corresponding to the embodiments described in the present disclosure, the network interface 3901, the processor 3902, and the memory 3903 of the network entity 3900 may operate. However, components of the network entity 3900 are not limited to the exemplary components illustrated in Figure 39. In another embodiment, the network entity 3900 may further include additional components in addition to the above-mentioned components, or some components may be omitted. Further, in an embodiment, the network interface 3901, the processor 3902, or the memory 3903 may be integrated in the form of one component.

[0463] The network interface 3901 is a collective term for a transmitter part of the network entity 3900 and a receiver part of the network entity 3900, and may be a communication circuit for transmitting or receiving a signal to or from a user equipment (UE), a base station (BS), or another network entity. Here, the communication circuit may include both a communication circuit for wireless communication and a communication circuit for a wired communication. For example, the network interface 3901 may include a circuit, logic, hardware, etc., configured to exchange a control plane message or a user plane message with a UE, a BS, or other core network entities through wireless communication or wired communication. The network interface 3901 may operate using various protocols (e.g., non-access stratum (NAS) protocol). The network interface 3901 may also be referred to, for convenience of description or depending on implementation, as communication circuitry, network interface circuitry, or a communication interface circuitry.

[0464] The processor 3902 may control general operations of the network entity 3900 according to embodiments of the disclosure. The processor 3902 may be implemented by one or more integrated circuit (or circuitry) (IC) chips and may execute various data processings. The processor 3902 may include at least one electric circuit, and may execute instructions (or a program, codes, data, etc.) stored in the memory 3903, individually, collectively or in any combination thereof. Further, the processor 3902 may include a single-core processor or multi-core processor, and may include a processor assembly including a plurality of processing circuits (circuitry) according to a specific implementation scheme. Further, it should be noted that, according to another embodiment, in a case where NF is implemented in the form of an instance, the network function may be not necessarily configured by physical hardware.

[0465] According to an embodiment, the processor 3902 may be electrically, operatively, or communicatively coupled to the network interface 3901 to control the network interface 3901.

[0466] The processor 3902 may include at least one processor (or processing circuitry), and the at least one processor may perform the following operations individually, collectively or in any combination thereof. In a specific embodiment, at least a part of the processor 3902 may be included in one chip and the other part of the processor 3902 may be included in another chip. Otherwise, at least one processor may be included in another component, for example, the network interface 3901 or the memory 3903.

[0467] The processor 3902 may perform or control or cause an operation of the network entity 3900 for executing at least one or a combination of methods according to embodiments of the disclosure. For example, the processor 3902 may control operations of the network entity 3900 for exchanging a control plane message or a user plane message with a UE, a BS, or other core network entities through wireless or wired communication, using various protocols (e.g., NAS protocol). To this end, the processor 3902 may execute a computer program, codes, or instructions stored in the memory 3903, so as to control other components of the network entity 3900 to enable execution of various operations.

[0468] The memory 3903 corresponds to a hardware storage device capable of temporarily or permanently storing information and may include one or more storage media. For example, the memory 3903 may include a memory assembly including one or more storage media. For example, the one or more storage media may include permanent memory, such as a hard drive, flash memory, or read-only memory (ROM), semipermanent memory, such as random access memory (RAM), cache memory, or a combination thereof.

[0469] The memory 3903 may be electrically, operatively, or communicatively coupled to the processor 3902 and may be accessed by the processor 3902.

[0470] The memory 3903 may store a computer program, codes, or instructions executable by the processor 3902. According to an embodiment, a computer program, codes, or instructions executable by the processor 3902 may be either stored in a single memory device or separated and distributedly stored in two or more memory devices. By executing the instructions stored in the memory 3903, the processor 3902 may perform various functions according to an embodiment of the disclosure.

[0471] According to an embodiment of the disclosure, operations of the network entity 3900 may be caused to be performed based on execution of instructions (or a computer program or codes) stored in the memory 3903 by at least one processor (or processing circuitry) configured to execute the same individually, collectively, or in any combination thereof, based on processing circuitry that is not configured to execute instructions, and / or based on components of processing circuitry that is not configured to execute instructions.

[0472] In one embodiment, a method (2900) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, which comprises:establishing (2902), by a trust anchor function (560), a communication between a first RAN entity (520) and the trust anchor function (560) based on a nonce message; receiving (2904), by the trust anchor function (560), based on the established communication, the at least one proof of evidence from the first RAN entity (520), wherein the at least one proof of evidence indicates trustworthiness of the first RAN entity (520); determining (2906), by the trust anchor function (560), an attestation result based on the received at least one proof of evidence; and transmitting (2908), by the trust anchor function (560), the attestation result to the first RAN entity (520) wherein the attestation result enables the first RAN entity (520) to maintain a communication with second RAN entity (540) via a plurality of communication channels.

[0473] In another embodiment, a method (2900) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, wherein determining the attestation result comprises: transmitting, to a verifier (570), the at least one proof of evidence for verification; receiving, from the verifier (570), at least one verification result corresponding to the transmitted at least one proof of evidence; and determining the attestation result by validating the received at least one verification result based on one or more pre-defined policy configurations.

[0474] In another embodiment, a method (2900) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, wherein the first RAN entity (520) comprises one of a Centralized Unit (CU), a Distributed Unit (DU), and a Radio Unit (RU).

[0475] In another embodiment, a method (2900) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, wherein establishing the communication between the first RAN entity (520) and the trust anchor function (560) comprises: establishing, via the second RAN entity (540), the communication between the first RAN entity (520) and the trust anchor function (560).

[0476] In another embodiment, a method (2900) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, wherein receiving the at least one proof of evidence comprises: receiving, via the second RAN entity (540), the at least one proof of evidence in a request_for_attestation message, wherein the request_for_attestation message is a new message.

[0477] In another embodiment, a method (2900) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, wherein transmitting the attestation result comprises: transmitting, via the second RAN entity (540), the attestation result in an attestation response message, wherein the attestation response message indicates one of pass, fail, and a score associated with the attestation result.

[0478] In another embodiment, a method (2900) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, which further comprises: triggering one or more events based on the attestation result, wherein the one or more events are defined in one or more pre-defined policy configurations provided to the trust anchor function (560).

[0479] In another embodiment, a method (2900) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, wherein the trust anchor function (560) resides in a cloud environment.

[0480] In another embodiment, a method (2900) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, wherein the trust anchor function (560) is one of an individual network entity or a network function.

[0481] In another embodiment, a method (2900) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, wherein the trust anchor function (560) resides in a Service Management and Orchestration (SMO) associated with the RAN entity.

[0482] In one embodiment, a method (3000) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, which comprises: enabling (3002) certificate retrieval of a first RAN entity (520) using a User-based Security Model (USM) (801); receiving (3004), by the first RAN entity (520), at least one proof of evidence from an attester (530), wherein the at least one proof of evidence indicates trustworthiness of the first RAN entity (520); transmitting (3006), to a trust anchor function (560), the at least one proof of evidence; and in response to the transmitted at least one proof of evidence, receiving (3008), by the first RAN entity (520), an attestation result from the trust anchor function (560), wherein the attestation result enables the first RAN entity (520) to maintain a communication with second RAN entity (540) based on a provisioning of the certificate.

[0483] In another embodiment, a method (3000) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, wherein receiving the attestation result comprises: receiving, via the second RAN entity (540), the attestation result in one of an One Time Password (OTP) message, OTP_Key message.

[0484] In another embodiment, a method (3000) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, wherein the first RAN entity (520) comprises one of a Centralized Unit (CU), a Distributed Unit (DU), and a Radio Unit (RU).

[0485] In one embodiment, a method (3100) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, which comprises: establishing (3102), by a trust anchor function (902, 1402, 1902, 2402), a communication between the trust anchor function (902, 1402, 1902, 2402) and a first RAN entity (904, 1404, 1904, 2404) based on a nonce request setup message; receiving, by the trust anchor function (902, 1402, 1902, 2402), at least one proof of evidence from the first Radio Access Network (RAN) entity (904, 1404, 1904, 2404) in a request_for_attestation (attestation_quote) message, wherein the at least one proof of evidence indicates trustworthiness of the first RAN entity (904, 1404, 1904, 2404); determining, by the trust anchor function (902, 1402, 1902, 2402), an attestation result based on the received at least one proof of evidence; and transmitting, by the trust anchor function (902, 1402, 1902, 2402), the attestation result to the first RAN entity in an attestation_response message, wherein the attestation result enables the first RAN entity (904, 1404, 1904, 2404) to maintain a communication with another RAN entity (942, 1442, 1942, 2442).

[0486] In another embodiment, a method (3100) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, wherein determining the attestation result comprises: transmitting, to a verifier (946, 1446, 1946, 2446), the at least one proof of evidence for verification; receiving, from the verifier (946, 1446, 1946, 2446), at least one verification result corresponding to the transmitted at least one proof of evidence; and determining the attestation result by validating the received at least one verification result based on one or more pre-defined policy configurations.

[0487] In another embodiment, a method (3100) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, wherein receiving the at least one proof of evidence comprises: receiving, via the another RAN entity (942, 1442, 1942, 2442), the at least one proof of evidence in the request_for_attestation (attestation_quote) message, wherein the request_for_attestation (attestation_quote) message is a new message.

[0488] In another embodiment, a method (3100) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, wherein transmitting the attestation result comprises: transmitting, via the another RAN entity (942, 1442, 1942, 2442), the attestation result in the attestation_response message, wherein the attestation_response message indicates one of a pass, fail, and score associated with the attestation result.

[0489] In another embodiment, a method (3100) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, which further comprises: triggering one or more events based on the attestation result, wherein the one or more events are defined in one or more pre-defined policy configurations provided to the trust anchor function (902, 1402, 1902, 2402).

[0490] In another embodiment, a method (3100) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, wherein the trust anchor function (902, 1402, 1902, 2402) resides in a cloud environment.

[0491] In another embodiment, a method (3100) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, wherein the trust anchor function (902, 1402, 1902, 2402) is one of an individual entity or is a network function.

[0492] In another embodiment, a method (3100) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, wherein the trust anchor function (902, 1402, 1902, 2402) resides in a Service Management and Orchestration (SMO) associated with the RAN entity.

[0493] In one embodiment, a method (3200) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, which comprises: transmitting (3202), to a trust anchor function (902, 1402, 1902, 2402), at least one proof of evidence in one of a request message, wherein the at least one proof of evidence indicates trustworthiness of the first RAN entity (904, 1404, 1904, 2404); and in response to the transmitted at least one proof of evidence, receiving (3204), by the first RAN entity (904, 1404, 1904, 2404), an attestation result from the trust anchor function (902, 1402, 1902, 2402) in one of a response message, wherein the attestation result enables the first RAN entity (904, 1404, 1904, 2404) to maintain a communication with second RAN entity (942, 1442, 1942, 2442).

[0494] In another embodiment, a method (3200) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, wherein one of the request message comprises a F1 setup request message, a NG setup request message, a F2 setup request message, XN setup request message, and an attestation_request message.

[0495] In another embodiment, a method (3200) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, wherein one of the response message comprises F1 setup response / failure message, NG setup response / failure message, F2 setup response / failure message, and XN setup response / failure message.

[0496] In another embodiment, a method (3200) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, wherein prior to transmitting the at least one proof of evidence to the trust anchor function (902, 1402, 1902, 2402), the method (3200) comprises: receiving the at least one proof of evidence from an attester (940, 1440, 1940, 2440).

[0497] In another embodiment, a method (3200) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, wherein transmitting the at least one proof of evidence to the trust anchor function (902, 1402, 1902, 2402) comprises: transmitting, via the second RAN entity (942, 1442, 1942, 2442) to the trust anchor function (902, 1402, 1902, 2402), the at least one proof of evidence in the one of the request message, wherein the request message is a new message.

[0498] In another embodiment, a method (3200) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, wherein receiving the attestation result from the trust anchor function (902, 1402, 1902, 2402) comprises: receiving, via the second RAN entity (942, 1442, 1942, 2442), from the trust anchor function (902, 1402, 1902, 2402), the attestation result in response to the transmitted at least one proof of evidence in the response message, wherein the response message indicates one of a pass, fail, failure: reason='attestation failure', and score of the attestation result.

[0499] In another embodiment, a method (3200) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, wherein the first RAN entity (902, 1402, 1902, 2402) comprises one of a Centralized Unit (CU), a Distributed Unit (DU), and a Radio Unit (RU).

[0500] In one embodiment, a system (610) for remote attestation in zero-trust architecture in a Radio Access Network (RAN) entity is provided, which comprises: a memory (604); and a processor (602) in communication with the memory (604) and configured to: establish a communication between a first RAN entity (520) and a trust anchor function (560) based on a nonce message; receive based on the established communication, at least one proof of evidence from the first RAN entity (520), wherein the at least one proof of evidence indicates trustworthiness of the first RAN entity (520); determine an attestation result based on the received at least one proof of evidence; and transmit the attestation result to the first RAN entity (520) wherein the attestation result enables the first RAN entity (520) to maintain a communication with second RAN entity (540) via a plurality of communication channels.

[0501] In another embodiment, a system (610) for remote attestation in zero-trust architecture in a Radio Access Network (RAN) entity is provided, wherein the first RAN entity (520) comprises one of a Centralized Unit (CU), a Distributed Unit (DU), and a Radio Unit (RU).

[0502] In another embodiment, a system (610) for remote attestation in zero-trust architecture in a Radio Access Network (RAN) entity is provided, wherein to receive the at least one proof of evidence, the processor (602) is configured to: receive, via the second RAN entity (540), the at least one proof of evidence in a request_for_attestation message, wherein the request_for_attestation message is a new message.

[0503] In another embodiment, a system (610) for remote attestation in zero-trust architecture in a Radio Access Network (RAN) entity is provided, wherein the trust anchor function (560) is one of an individual network entity or a network function.

[0504] In one embodiment, a system (620) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, which comprises: a memory (603); and a processor (601) in communication with the memory (603) and configured to: enable certificate retrieval of a first RAN entity (520) using a User-based Security Model (USM) (801); receive at least one proof of evidence from an attester (530), wherein the at least one proof of evidence indicates trustworthiness of the first RAN entity (520); transmit, to a trust anchor function (560), the at least one proof of evidence; and in response to the transmitted at least one proof of evidence, receive an attestation result from the trust anchor function (560), wherein the attestation result enables the first RAN entity (520) to maintain a communication with second RAN entity (540) based on a provisioning of the certificate.

[0505] In one embodiment, a system (906, 1406, 1906, 2406) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, which comprises: a memory (910, 1410, 1910, 2410); and a processor (908, 1408, 1908, 2408) in communication with the memory (910, 1410, 1910, 2410) and configured to: establish a communication between a trust anchor function (902, 1402, 1902, 2402) and a first RAN entity (904, 1404, 1904, 2404) based on a nonce request setup message; receive at least one proof of evidence from the first Radio Access Network (RAN) entity (904, 1404, 1904, 2404) in a request_for_attestation (attestation_quote) message, wherein the at least one proof of evidence indicates trustworthiness of the first RAN entity (904, 1404, 1904, 2404); determine an attestation result based on the received at least one proof of evidence; and transmit the attestation result to the first RAN entity (904, 1404, 1904, 2404) in an attestation_response message, wherein the attestation result enables the first RAN entity (904, 1404, 1904, 2404) to maintain a communication with second RAN entity (942, 1442, 1942, 2442).

[0506] In one embodiment, a system (926, 1426, 1926, 2426) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, which comprises: a memory (930, 1430, 1930, 2430); and a processor (928, 1428, 1928, 2428) in communication with the memory (930, 1430, 1930, 2430) and configured to: transmit, to a trust anchor function (902, 1402, 1902, 2402), at least one proof of evidence in one of a request message, wherein the at least one proof of evidence indicates trustworthiness of the first RAN entity (904, 1404, 1904, 2404); and in response to the transmitted at least one proof of evidence, receive an attestation result from the trust anchor function (902, 1402, 1902, 2402) in one of a response message, wherein the attestation result enables the first RAN entity (902, 1402, 1902, 2402) to maintain a communication with second RAN entity (942, 1442, 1942, 2442).

[0507] In another embodiment, a system (926, 1426, 1926, 2426) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, wherein one of the request message comprises a F1 setup request message, NG setup request message, a F2 setup request message, XN setup request message, and an attestation_request message.

[0508] In another embodiment, a system (926, 1426, 1926, 2426) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, wherein one of the response message comprises F1 setup response / failure message, NG setup response / failure message, F2 setup response / failure message, and XN setup response / failure message.

[0509] In another embodiment, a system (926, 1426, 1926, 2426) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, wherein prior to transmitting the at least one proof of evidence to the trust anchor function (902, 1402, 1902, 2402), the processor (928, 1428, 1928, 2428) is configured to: receive the at least one proof of evidence from an attester (940, 1440, 1940, 2440).

[0510] In another embodiment, a system (926, 1426, 1926, 2426) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, wherein to transmit the at least one proof of evidence to the trust anchor function (902, 1402, 1902, 2402), the processor (928, 1428, 1928, 2428) is configured to: transmit, via the second RAN entity (942, 1442, 1942, 2442) to the trust anchor function (902, 1402, 1902, 2402), the at least one proof of evidence in the one of the request message, wherein the request message is a new message.

[0511] In another embodiment, a system (926, 1426, 1926, 2426) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, wherein to receive the attestation result from the trust anchor function (902, 1402, 1902, 2402), the processor (928, 1428, 1928, 2428) is configured to: receive, via the second RAN entity (942, 1442, 1942, 2442), from the trust anchor function (902, 1402, 1902, 2402), the attestation result in response to the transmitted at least one proof of evidence in the response message, wherein the response message indicates one of a pass, fail, failure: reason='attestation failure', and score of the attestation result.

[0512] In another embodiment, a system (926, 1426, 1926, 2426) for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity is provided, wherein the first RAN entity (902, 1402, 1902, 2402) comprises one of a Centralized Unit (CU), a Distributed Unit (DU), and a Radio Unit (RU).

[0513] The system and method as disclosed are applicable to physical nodes to meet zero trust requirements of 5G ultra and 6G.

[0514] Meanwhile, although specific embodiments of the present disclosure have been described in detail, various modifications may be made without departing from the scope of the present disclosure. Therefore, the scope of the present disclosure should not be limited to the described embodiments, but should be defined by the claims and equivalents thereof.

Claims

1.A method for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity, comprising:establishing, by a trust anchor function, a communication between a first RAN entity and the trust anchor function based on a nonce message;receiving, by the trust anchor function, based on the established communication, the at least one proof of evidence from the first RAN entity, wherein the at least one proof of evidence indicates trustworthiness of the first RAN entity;determining, by the trust anchor function, an attestation result based on the received at least one proof of evidence; andtransmitting, by the trust anchor function, the attestation result to the first RAN entity wherein the attestation result enables the first RAN entity to maintain a communication with second RAN entity via a plurality of communication channels.2.The method as claimed in claim 1, wherein determining the attestation result comprises:transmitting, to a verifier, the at least one proof of evidence for verification;receiving, from the verifier, at least one verification result corresponding to the transmitted at least one proof of evidence; anddetermining the attestation result by validating the received at least one verification result based on one or more pre-defined policy configurations.3.The method as claimed in claim 1, wherein the first RAN entity comprises one of a Centralized Unit (CU), a Distributed Unit (DU), and a Radio Unit (RU).4.The method as claimed in claim 1, wherein establishing the communication between the first RAN entity and the trust anchor function comprises:establishing, via the second RAN entity, the communication between the first RAN entity and the trust anchor function.5.The method as claimed in claim 1, wherein receiving the at least one proof of evidence comprises:receiving, via the second RAN entity, the at least one proof of evidence in a request_for_attestation message, wherein the request_for_attestation message is a new message.6.The method as claimed in claim 1, wherein transmitting the attestation result comprises:transmitting, via the second RAN entity, the attestation result in an attestation response message, wherein the attestation response message indicates one of pass, fail, and a score associated with the attestation result.7.The method as claimed in claim 1, further comprising:triggering one or more events based on the attestation result, wherein the one or more events are defined in one or more pre-defined policy configurations provided to the trust anchor function.8.The method as claimed in claim 1, wherein the trust anchor function resides in a cloud environment.9.The method as claimed in claim 1, wherein the trust anchor function is one of an individual network entity or a network function.10.The method as claimed in claim 1, wherein the trust anchor function resides in a Service Management and Orchestration (SMO) associated with the RAN entity.11.A method for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity, comprising:enabling certificate retrieval of a first RAN entity using a User-based Security Model (USM);receiving, by the first RAN entity, at least one proof of evidence from an attester, wherein the at least one proof of evidence indicates trustworthiness of the first RAN entity;transmitting, to a trust anchor function, the at least one proof of evidence; andin response to the transmitted at least one proof of evidence, receiving, by the first RAN entity, an attestation result from the trust anchor function, wherein the attestation result enables the first RAN entity to maintain a communication with second RAN entity based on a provisioning of the certificate.12.The method as claimed in claim 11, wherein receiving the attestation result comprises:receiving, via the second RAN entity, the attestation result in one of an One Time Password (OTP) message, OTP_Key message.13.The method as claimed in claim 11, wherein the first RAN entity comprises one of a Centralized Unit (CU), a Distributed Unit (DU), and a Radio Unit (RU).14.A method for remote attestation in zero trust architecture in a Radio Access Network (RAN) entity, comprising:transmitting, to a trust anchor function, at least one proof of evidence in one of a request message, wherein the at least one proof of evidence indicates trustworthiness of the first RAN entity; andin response to the transmitted at least one proof of evidence, receiving, by the first RAN entity, an attestation result from the trust anchor function in one of a response message, wherein the attestation result enables the first RAN entity to maintain a communication with second RAN entity.15.A system (610) for remote attestation in zero-trust architecture in a Radio Access Network (RAN) entity, comprising:at least one processor; andat least one memory, communicatively coupled to the at least one processor, storing instructions executable by the at least one processor individually or in any combination to cause the network entity to:establish a communication between a first RAN entity (520) and a trust anchor function (560) based on a nonce message;receive based on the established communication, at least one proof of evidence from the first RAN entity (520), wherein the at least one proof of evidence indicates trustworthiness of the first RAN entity (520);determine an attestation result based on the received at least one proof of evidence; andtransmit the attestation result to the first RAN entity (520) wherein the attestation result enables the first RAN entity (520) to maintain a communication with second RAN entity (540) via a plurality of communication channels.

Images