Integrity protection of control plane operations

Abstract

Various aspects of the present disclosure relate to a network entity that stores code comprising instructions executable to cause the network entity to: detect a triggering event associated with a wireless communication network; execute a policy to determine, based on the triggering event, a predefined action to perform, the predefined action comprising a control plane operation in the wireless communication network; send, to one or more nodes coupled to a DLT network, transaction information, the transaction information identifying the predefined action; and perform the predefined action in response to the transaction information being committed to a distributed ledger maintained at the network entity and the one or more nodes.

Description

Technical Field

[0001] This disclosure relates to wireless communications, and more specifically to end-to-end integrity protection for virtualized control plane operations. Background Technology

[0002] A wireless communication system may include one or more network communication devices, such as base stations, which can support wireless communication for one or more user communication devices, which may also be referred to as user equipment (UE) or other suitable terms. The wireless communication system can support wireless communication with one or more user communication devices by utilizing the resources of the wireless communication system (e.g., time resources (e.g., symbols, time slots, subframes, frames, etc.) or frequency resources (e.g., subcarriers, carriers, etc.)). Furthermore, the wireless communication system can support wireless communication across a variety of wireless access technologies, including third-generation (3G), fourth-generation (4G), fifth-generation (5G), and other suitable wireless access technologies beyond 5G (e.g., sixth-generation (6G)). Summary of the Invention

[0003] The word “a” preceding an element is unrestricted and is understood to refer to “at least one” or “one or more” of those elements. The terms “a,” “at least one,” “one or more,” and “at least one of one or more” are used interchangeably. As used herein, including in the claims, and as in a list of items (e.g., a list of items ending with phrases such as “at least one of,” “one or more of,” or “one or both”), “or” indicates a list of inclusion, such that, for example, a list of at least one of A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C). Furthermore, as used herein, the phrase “based on” should not be construed as referring to a closed set of conditions. For example, an example step described as “based on condition A” may be based on both condition A and condition B without departing from the scope of this disclosure. In other words, as used herein, the phrase “based on” should be interpreted in the same manner as the phrase “at least partially based on.” Furthermore, as used herein, including in the claims, a “set” may include one or more elements.

[0004] Some embodiments of the methods and apparatus described herein may also include a network entity storing code including instructions executable to cause the network entity to: detect a triggering event associated with a wireless communication network; execute a strategy to determine a predefined action to be performed based on the triggering event, the predefined action including control plane operations in the wireless communication network; send transaction information to one or more nodes coupled to a DLT network, the transaction information identifying the predefined action; and execute the predefined action in response to the transaction information being submitted to a distributed ledger maintained at the network entity and one or more nodes.

[0005] In some embodiments of the methods and apparatus described herein, the instructions may also be executed to cause a network entity to: receive measurement data associated with a wireless communication network; and detect a triggering event based on the measurement data.

[0006] In some embodiments of the methods and apparatus described herein, the instructions may also be executed to cause a network entity to receive measurement data from one or more nodes outside the DLT network via a gateway node.

[0007] In some embodiments of the methods and apparatus described herein, the triggering event includes receiving a request for a service to be provided by a network entity to a wireless communication network.

[0008] Predefined actions may include providing the requested service to one or more nodes outside the DLT network via a gateway node.

[0009] Transaction information may include one or more of the following: (i) a transaction identifier, (ii) a control plane identifier, (iii) an identifier of a predefined action, (iv) the reason for triggering an event, (v) the identifier of each of one or more nodes coupled to the DLT network involved in the control plane operation, (vi) one or more constraints used to fulfill the control plane operation, or (vii) the identifier of each of one or more nodes outside the DLT network involved in the control plane operation.

[0010] In some embodiments of the methods and apparatus described herein, the distributed ledger includes a data structure containing multiple linked data blocks, and instructions are executable to cause network entities to perform predefined actions in response to the addition of a data block including transaction information to the data structure.

[0011] In some implementations of the methods and apparatus described herein, the strategy is a smart contract.

[0012] In some embodiments of the methods and apparatus described herein, the network entity is a near real-time radio access network (RAN) intelligent controller, or a network entity configured to communicate with a near real-time RAN intelligent controller.

[0013] In some embodiments of the methods and apparatus described herein, the network entity is a non-real-time radio access network (RAN) intelligent controller.

[0014] In some embodiments of the methods and apparatus described herein, the network entity is a multi-access edge computing (MEC) host.

[0015] In some embodiments of the methods and apparatus described herein, the network entity is a base station in a wireless communication network.

[0016] Some embodiments of the methods and apparatus described herein may also include a processor for wireless communication, comprising: at least one controller coupled to at least one memory and configured such that the processor: detects a trigger event associated with a wireless communication network; executes a policy to determine a predefined action to be performed based on the trigger event, the predefined action including control plane operations in the wireless communication network; outputs transaction information for transmission to one or more nodes coupled to a DLT network, the transaction information identifying the predefined action; and performs the predefined action in response to the transaction information being submitted to a distributed ledger maintained at network entities and one or more nodes.

[0017] Some embodiments of the methods and apparatus described herein may also include a method performed by a network entity, the method comprising: detecting a triggering event associated with a wireless communication network; executing a strategy to determine a predefined action to be performed based on the triggering event, the predefined action including control plane operations in the wireless communication network; sending transaction information to one or more nodes coupled to a DLT network, the transaction information identifying the predefined action; and performing the predefined action in response to the transaction information being submitted to a distributed ledger maintained at the network entity and one or more nodes.

[0018] In some embodiments of the methods and apparatus described herein, the method includes: receiving measurement data associated with a wireless communication network; and detecting a trigger event based on the measurement data.

[0019] In some embodiments of the methods and apparatus described herein, the method includes receiving measurement data from one or more nodes outside a DLT network via a gateway node.

[0020] In some embodiments of the methods and apparatus described herein, the triggering event includes receiving a request for a service to be provided by a network entity to a wireless communication network.

[0021] Predefined actions may include providing the requested service to one or more nodes outside the DLT network via a gateway node.

[0022] In some embodiments of the methods and apparatus described herein, the transaction information includes one or more of the following: (i) a transaction identifier, (ii) a control plane identifier, (iii) an identifier of a predefined action, (iv) a cause of an event, (v) an identifier of each of one or more nodes coupled to the DLT network involved in the control plane operation, (vi) one or more constraints for fulfilling the control plane operation, or (vii) an identifier of each of one or more nodes outside the DLT network involved in the control plane operation. Attached Figure Description

[0023] Figure 1 Examples of wireless communication systems according to various aspects of this disclosure are shown.

[0024] Figure 2 An example network architecture 200 is shown according to some aspects of this disclosure.

[0025] Figure 3a A base station including a centralized unit (CU), a distributed unit (DU), and a wireless unit (RU) is shown.

[0026] Figure 3b The diagram shows a base station including O-CU-CP (O-RAN Centralized Unit - Control Plane), O-CU-UP (O-RAN Centralized Unit - User Plane), O-DU (O-RAN Distributed Unit), and O-RU (O-RAN Radio Unit).

[0027] Figure 4 The MEC (Multi-Access Edge Computing) host network entity 400 is shown.

[0028] Figure 5 Different types of O-RAN entities that can enable blockchains are shown.

[0029] Figure 6 A process 600 is illustrated for protecting the integrity of control plane operations in a wireless communication network (e.g., a wireless access network) using distributed ledger technology, according to some aspects of this disclosure.

[0030] Figure 7 An example smart contract is shown.

[0031] Figure 8 The first example use case of the runtime phase of process 600 is shown.

[0032] Figure 9The second example use case is shown for the runtime phase of process 600.

[0033] Figure 10 An example of a processor 1000 according to various aspects of this disclosure is shown.

[0034] Figure 11 An example of a network device (NE) 1100 according to various aspects of this disclosure is shown.

[0035] Figure 12 A flowchart of a method 1200 performed by an NE according to various aspects of this disclosure is shown.

[0036] Figure 13 A flowchart of a method 1200 performed by an NE according to various aspects of this disclosure is shown.

[0037] Figure 14 A flowchart of a method 1200 performed by an NE according to various aspects of this disclosure is shown. Detailed Implementation

[0038] O-RAN is an alliance researching the virtualization of the access domain and considering the virtualization of control functions (such as Radio Resource Control (RRC) / Radio Resource Management (RRM)) to a newly defined Radio Access Network (RAN) Intelligent Controller (RIC), which can be co-located with base stations (such as next-generation NodeBs (gNBs)) or deployed against gNB clusters. In this context, considering deployment and functional requirements (real-time (RT), non-real-time, near real-time) and slicing isolation strategies, RRM / RRC functions can be flexibly located in centralized units (CUs), distributed units (DUs), or dedicated RIC controllers (such as Near-RT RICs and Non-RTRICs). RIC platforms can cover E2 node clusters (O-CUs, O-DUs) and allow management of parameters related to radio resources and / or user context information. In such cases, end-to-end trust is crucial to ensuring security is not compromised and maintaining data integrity.

[0039] In network virtualization scenarios (especially for the RAN side), it is important to capture which data requires integrity protection (which can be considered as microtransactions) and between which entities end-to-end protection needs to be maintained. Entities that can play a role in these transactions can include: (i) UE applications; (ii) RRM / network control functions at RAN entities; (iii) RIC platforms (on near-RT RIC or non-RT RIC); and (iv) xApp / rApp, for example, for RRM optimization.

[0040] For specific cases of O-RAN, example transactions (identifying control plane operations) that require integrity protection can be the following: RAN-to-RIC: Monitoring / triggering events from RAN functions, including INDICATION, INSERT, and REPORT messages; RAN-to-xApp via E2T: Monitoring / triggering events, INDICATION, INSERT, and REPORT messages; xApp to RIC: CONTROL, POLICY, Guidelines (for conflict mitigation), Subscription Messaging; From xApp to RAN via E2T: CONTROL and POLICY messages; xApp to UE (via E2T, RAN): Quality of Experience (QoE) strategy, TS strategy, RRM strategy; UE to RIC (via RAN): L2 measurement, UE-driven analysis; UE to xApp (via E2T, RAN): L2 measurement, monitoring / triggering events; xApp to xApp (via RIC): Data regarding dependencies between xApps; RIC functionality to RIC functionality: Currently, this depends on the implementation method of the RIC provider; however, due to the multiple provider service modules, the interaction between services on the same or different RIC platforms may require integrity protection.

[0041] Control plane operations may involve more than one transaction (e.g., monitoring and control operations). That is, control plane operations may involve multiple transactions between two or more entities.

[0042] Traditional technical solutions may offer fragmented integrity protection for each link / bearer (e.g., AS integrity protection for Uu, SEV for NF virtualization). However, end-to-end coordination is required. Traditional technical solutions suffer from the following problems: Question 1: RIC and xApp functionalities may be AI-based (meaning transactions may be executed automatically). In such a distributed environment where there is no two-way interaction (e.g., between the MNO and the client), there are issues related to ensuring the safety of transactions. Question 2: There is no central authority because we may have multiple stakeholders [e.g., mobile network operators (MNOs), customers, cloud providers, each provider's xApp, third-party xApps, ...]. Question 3: Traditional technologies for each link / bearer in multi-hop transactions spanning cross domains (devices, RAN control, management, applications) will significantly impact e2e latency because multiple layers of integrity protection will be required. Question 4: xApp may be dynamically activated / deactivated and relocated to different platforms. More frequent integrity verification of all involved parties is required. Question 5: Different protocol options (e.g., gRPC-based, SCTP-based) may be deployed for different interfaces along the end-to-end path; therefore, integrity cannot be unified at the API / protocol level for end-to-end control operations.

[0043] Therefore, it is necessary to ensure end-to-end data integrity for virtualized RAN transactions.

[0044] In various aspects of this disclosure, a mechanism is provided to guarantee end-to-end trust when O-RAN / virtualized RAN services [related to the access network, RIC, and UE context] are exposed to entities [e.g., xApp, MEC app, ...] via a distributed network of nodes enabling a blockchain. These O-RAN / virtualized RAN services may be: (i) services provided by the RIC, such as E2-related / control services (conflict mitigation, subscription management, control services, RNIB / UENIB database / SDL services, management services, AI / ML support services, RAN analytics services); (ii) virtualized RRM / SON services in the edge / cloud platform; (iii) services provided by the xApp (e.g., analytics provided by the xApp); (iv) access-related services provided by the MEC platform (e.g., RNIS, VIS); and / or (v) services provided by Y1 (data provided by the Y1 consumer for RAN analytics).

[0045] Mutual authentication is crucial for the security of cellular networks. Ensuring device identity is crucial for networks to charge users for services they consume, and it is also important for ensuring users' legal liability while using various services. Verifying network identity from the device's perspective is crucial for protecting against man-in-the-middle (MitM) attacks. MitM attacks are typically carried out by attackers using maliciously forged cell towers that impersonate the legitimate network to the target device. Network authentication aims to ensure connectivity to the real network. Mutual authentication is also crucial for encrypting mobile communication channels to protect them from eavesdropping. Initiating encryption requires exchanging encryption keys—this can only happen after the identities of all parties have been verified.

[0046] In addition to the AKA protocol, the actual communications exchanged between users and the network are also protected to ensure information privacy and prevent various attacks. This communication protection is implemented at two levels. At the first level, control plane communications not only protect privacy by applying encryption but also use "integrity protection" at the PDCP layer to protect against malicious modifications, ensuring that the data arriving at its destination is indeed generated from a legitimate source and has not been modified during routing. At the second level, user plane information only uses encryption to protect privacy—in 4G, integrity protection is not applied to content data. 5G networks do enable integrity verification of content data, but this is optional, not mandatory.

[0047] This presents several challenges. In particular, integrity protection is very resource-intensive, and not all devices will be able to support it at full data rates. Therefore, 5G systems allow negotiation of which rates are applicable to this feature. For example, if a device indicates 64kbps as its maximum data rate for integrity protection services, the network will only enable integrity protection for UP connections whose expected data rates do not exceed the 64kbps limit.

[0048] Various aspects of this disclosure are described in the context of wireless communication systems.

[0049] Figure 1 Examples of a wireless communication system 100 according to various aspects of this disclosure are shown. The wireless communication system 100 may include one or more NEs 102, one or more UEs 104, and a core network (CN) 106. The wireless communication system 100 may support various wireless access technologies. In some embodiments, the wireless communication system 100 may be a 4G network, such as an LTE network or an LTE-A advanced network. In some other embodiments, the wireless communication system 100 may be an NR network, such as a 5G network, an 5G-A advanced network, or a 5G ultra-wideband (5G-UWB) network. In other embodiments, the wireless communication system 100 may be a combination of 4G and 5G networks, or other suitable wireless access technologies, including IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), and IEEE 802.20. The wireless communication system 100 may support wireless access technologies beyond 5G, such as 6G. In addition, the wireless communication system 100 can support technologies such as Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), or Code Division Multiple Access (CDMA).

[0050] One or more NEs 102 may be distributed throughout a geographic area to form a wireless communication system 100. One or more of the NEs 102 described herein may be, include, or may be referred to as network nodes, base stations, network elements, network functions, network entities, radio access networks (RANs), NodeBs, eNodeBs (eNBs), next-generation NodeBs (gNBs), or other suitable terms. NEs 102 may be O-RAN (or other virtualized RAN) entities. NEs 102 and UEs 104 may communicate via a communication link, which may be a wireless connection or a wired connection. For example, NEs 102 and UEs 104 may communicate wirelessly (e.g., receive signaling, send signaling) via a Uu interface.

[0051] NE 102 can provide a geographic coverage area for which it can support services for one or more UEs 104 within that geographic coverage area. For example, NE 102 and UE 104 can support wireless communication of signals related to services (e.g., voice, video, packet data, messaging, broadcasting, etc.) based on one or more radio access technologies. In some embodiments, NE 102 can be mobile, such as a satellite associated with a non-terrestrial network (NTN). In some embodiments, different geographic coverage areas 112 associated with the same or different radio access technologies can overlap, but different geographic coverage areas can be associated with different NEs 102.

[0052] One or more UEs 104 may be distributed throughout the geographic area of ​​the wireless communication system 100. UE 104 may include or be referred to as a remote unit, mobile device, wireless device, remote device, subscriber device, transmitter device, receiver device, or some other suitable term. In some implementations, UE 104 may be referred to as a unit, station, terminal, or client, etc. Additionally or alternatively, UE 104 may be referred to as an Internet of Things (IoT) device, an Internet of Everything (IoE) device, or a Machine Type Communication (MTC) device, etc.

[0053] UE 104 can support direct wireless communication with other UE 104 via a communication link. For example, UE 104 can support direct wireless communication with another UE 104 via a device-to-device (D2D) communication link. In some implementations, such as vehicle-to-vehicle (V2V) deployments, vehicle-to-everything (V2X) deployments, or cellular V2X deployments, the communication link 114 may be referred to as a side link. For example, UE 104 can support direct wireless communication with another UE 104 via a PC5 interface.

[0054] NE 102 may support communication with CN 106, or with another NE 102, or both. For example, NE 102 may interface with other NE 102 or CN 106 via one or more backhaul links (e.g., S1, N2, N2, or network interfaces). In some implementations, NE 102 may communicate directly with each other. In some other implementations, NE 102 may communicate with each other or indirectly (e.g., via CN 106). In some implementations, one or more NE 102 may include sub-components, such as access network entities, which may be examples of access node controllers (ANCs). The ANC may communicate with one or more UEs 104 via one or more other access network transmission entities, which may be referred to as radio headends, smart radio headends, or transmit-receive points (TRPs).

[0055] CN 106 can support user authentication, access authorization, tracking, connectivity, and other access, routing, or mobility functions. CN 106 can be an evolved packet core (EPC) or a 5G core (5GC), which may include control plane entities that manage access and mobility (e.g., a mobility management entity (MME), access and mobility management functions (AMF)) and user plane entities that route packets or interconnect with external networks (e.g., a serving gateway (S-GW), a packet data network (PDN) gateway (P-GW), or a user plane function (UPF)). In some implementations, the control plane entity may manage non-access stratum (NAS) functions, such as mobility, authentication, and bearer management (e.g., data bearers, signaling bearers, etc.), for one or more UEs 104 served by one or more NEs 102 associated with CN 106.

[0056] CN 106 can communicate with the packet data network via one or more backhaul links (e.g., via S1, N2, N2, or another network interface). The packet data network may include an application server. In some implementations, one or more UEs 104 can communicate with the application server. UE 104 can establish a session (e.g., a Protocol Data Unit (PDU) session, etc.) with CN 106 via NE 102. CN 106 can use the established session (e.g., an established PDU session) to route services (e.g., control information, data, etc.) between UE 104 and the application server. A PDU session may be an example of a logical connection between UE 104 and CN 106 (e.g., one or more network functions of CN 106).

[0057] In the wireless communication system 100, NE 102 and UE 104 can use the resources of the wireless communication system 100 (e.g., time resources (e.g., symbols, time slots, subframes, frames, etc.) or frequency resources (e.g., subcarriers, carriers)) to perform various operations (e.g., wireless communication). In some embodiments, NE 102 and UE 104 can support different resource structures. For example, NE 102 and UE 104 can support different frame structures. In some embodiments, such as in 4G, NE 102 and UE 104 can support a single frame structure. In some other embodiments, such as in 5G and other suitable wireless access technologies, NE 102 and UE 104 can support various frame structures (i.e., multiple frame structures). NE 102 and UE 104 can support various frame structures based on one or more parameter sets.

[0058] The wireless communication system 100 may support one or more parameter sets, and the parameter sets may include subcarrier spacing and cyclic prefix. The first parameter set (e.g., μ =0) can be associated with the first subcarrier spacing (e.g., 15 kHz) and the normal cyclic prefix. In some implementations, the first parameter set (e.g., ) associated with the first subcarrier spacing (e.g., 15 kHz) is... μ =0) allows each subframe to utilize one time slot. The second parameter set (e.g., μ =1) can be associated with the second subcarrier spacing (e.g., 30 kHz) and the normal cyclic prefix. The third parameter set (e.g., μ =2) can be associated with the third subcarrier spacing (e.g., 60 kHz) and the normal cyclic prefix or extended cyclic prefix. The fourth parameter set (e.g., μ =3) can be associated with the fourth subcarrier spacing (e.g., 120 kHz) and the normal cyclic prefix. The fifth parameter set (e.g., μ =4) can be associated with the fifth subcarrier spacing (e.g., 240 kHz) and the normal cyclic prefix.

[0059] The time intervals of resources (e.g., communication resources) can be organized according to frames (also called radio frames). Each frame can have a certain duration, such as 10 milliseconds (ms). In some implementations, each frame can include multiple subframes. For example, each frame can include 10 subframes, and each subframe can have a certain duration, such as 1 ms. In some implementations, each frame can have the same duration. In some implementations, each subframe of a frame can have the same duration.

[0060] Alternatively, the time intervals of resources (e.g., communication resources) can be organized according to time slots. For example, a subframe may include a certain number (e.g., quantity) of time slots. The number of time slots in each subframe may also depend on one or more sets of parameters supported in the wireless communication system 100. For example, the first, second, third, fourth, and fifth sets of parameters associated with the corresponding subcarrier spacings of 15 kHz, 30 kHz, 60 kHz, 120 kHz, and 240 kHz (i.e., μ =0、 μ =1、 μ =2、 μ =3、 μ =4) Each subframe can utilize one time slot, two time slots, four time slots, eight time slots, or 16 time slots, respectively. Each time slot can include a certain number (e.g., quantity) of symbols (e.g., OFDM symbols). In some implementations, the number (e.g., quantity) of time slots in a subframe can depend on the parameter set. For a normal cyclic prefix, a time slot can include 14 symbols. For an extended cyclic prefix (e.g., for a 60 kHz subcarrier spacing), a time slot can include 12 symbols. The relationship between the number of symbols per time slot, the number of time slots per subframe, and the number of time slots per frame for both normal and extended cyclic prefixes can depend on the parameter set. It should be understood that for a first parameter set (e.g., quantity) associated with a first subcarrier spacing (e.g., 15 kHz), μ The reference to =0 can be used interchangeably between subframes and time slots.

[0061] In the wireless communication system 100, the electromagnetic (EM) spectrum can be divided into various categories, frequency bands, frequency channels, etc., based on frequency or wavelength. For example, the wireless communication system 100 can support one or more operating frequency bands, such as frequency ranges specified as FR1 (410 MHz – 7.125 GHz), FR2 (24.25 GHz – 52.6 GHz), FR3 (7.125 GHz – 24.25 GHz), FR4 (52.6 GHz – 114.25 GHz), FR4a or FR4-1 (52.6 GHz – 71 GHz), and FR5 (114.25 GHz – 300 GHz). In some embodiments, NE 102 and UE 104 can perform wireless communication on one or more of the operating frequency bands. In some embodiments, FR1 can be used by NE 102 and UE 104, as well as other devices or apparatuses, for cellular communication services (e.g., control information, data). In some implementations, FR2 can be used by NE 102 and UE 104, as well as other devices or apparatuses, for short-range, high-data-rate capabilities.

[0062] FR1 can be associated with one or more parameter sets (e.g., at least three parameter sets). For example, FR1 can be associated with the following: the first parameter set (e.g., μ =0), which includes a 15 kHz subcarrier spacing; the second parameter set (e.g., μ =1), which includes a 30 kHz subcarrier spacing; and a third parameter set (e.g., μ =2), which includes a 60 kHz subcarrier spacing. FR2 can be associated with one or more parameter sets (e.g., at least two parameter sets). For example, FR2 can be associated with a third parameter set (e.g., μ =2), which includes a 60 kHz subcarrier spacing; and a fourth parameter set (e.g., μ =3), which includes a 120 kHz subcarrier spacing.

[0063] Figure 2 An example O-RAN network architecture 200 according to some aspects of this disclosure is shown. In some embodiments, network architecture 200 may implement the methods described herein. Figure 1 The described aspects of the wireless communication system 100 or its implementation thereof. For example, network architecture 200 may include UE 104, which may be as referenced herein. Figure 1 An example of UE 104 as described herein. Network architecture 200 may include base station 102, which may be as referenced herein. Figure 1 An example of the described NE 102.

[0064] like Figure 2 As shown, the non-real-time (or non-RT) RIC 202 is a component of the Service Management and Orchestration (SMO) framework. The non-RT RIC 202 is the logical function that implements non-real-time control and optimization of RAN elements and resources, including AI / ML workflows for model training and updates, and policy-based guidance for applications / features in the near-RT RIC 204. The near-RT RIC 204 is the logical function that implements near real-time control and optimization of RAN elements and resources via fine-grained (e.g., UE-based, cell-based) data collection and actions through the E2 interface. The near-RT RIC 204 can be a network entity in the radio access network, or a component of that network entity. For example, the near-RT RIC 204 can be a component of base station 102.

[0065] The near-RT RIC 204 includes multiple framework functions 208, which may include, for example, API enabling function 206, xApp subscription management function 212, conflict mitigation function 214 and / or E2 termination (E2T) function 216, etc.

[0066] The near-RT RIC 204 also includes one or more applications (referred to as xApp 210) supporting custom logic, as well as the services required to support the execution of the xApp. The xApp can provide a microservice that can be used to perform radio resource management through standardized interfaces and service models. Upon loading, the xApp identifies which data it consumes and which data it provides. This application is independent of the near-RT RIC 204 and can be provided by any third party. The E2 interface enables direct association between the xApp and RAN functions. xApp 210 is configured to communicate with framework function 208 via the RIC Application Programming Interface (API). Although... Figure 2 xApp 210 running on the near-RT RIC 204 is shown, but it will be appreciated that one or more of xApp 210 can alternatively run on a network entity configured to communicate with the near-RT RIC 204.

[0067] For RAN analytics exposure and AI / ML support within the RIC, a Y1 interface has been defined for direct interaction between the RIC and external applications (such as Network Data Analysis Function (NWDAF)). Specifically, the Y1 interface allows Y1 consumer 218 to subscribe to or request (multiple) RAN analytics information services provided by the near-RT RIC 204. An A1 interface is provided between the non-RT RIC 202 and the near-RT RIC 204 to enable policy-driven guidance for near-RT RIC applications / functions and to support AI / ML workflows. An E2 interface is provided to connect the near-RT RIC 204 and E2 nodes. An E2 node is a logical node that includes the termination of the E2 interface.

[0068] Figure 3a Base station 102 is shown following the O-RAN Alliance separation architecture, which includes a centralized unit (CU), a distributed unit (DU), and a radio unit (RU). Figure 3a The CU and DU shown are examples of E2 nodes because they include a terminating E2 interface. Although Figure 3a The diagram shows that CU, DU, and RU are located on a single physical base station 102, but this is only an example, and these functions can be distributed across multiple physical network entities. Furthermore, several independent instances of DU and / or CU can share the same physical resources.

[0069] A CU can also be called an O-CU (O-RAN Centralized Unit). The O-CU function is split between O-CU-CP (O-RAN Centralized Unit - Control Plane) and O-CU-UP (O-RAN Centralized Unit - User Plane). A DU can also be called an O-DU (O-RAN Distributed Unit), and an RU can be called an O-RU (O-RAN Radio Unit). Figure 3b Base station 102 is shown, including O-CU-CP, O-CU-UP, O-DU, and O-RU. O-CU-CP, O-CU-UP, and O-DU are examples of E2 nodes because they include a terminating E2 interface. Virtualized eNodeBs can also be E2 nodes. Although... Figure 3b The diagram shows that O-CU-CP, O-CU-UP, O-DU, and O-RU are located on a single physical base station 102, but this is only an example, and these functions can be distributed across multiple physical network entities.

[0070] Figure 4 The diagram illustrates a MEC (Multi-Access Edge Computing) host network entity 400, which can be implemented within the ETSI MEC architecture. (Example:) Figure 4 As shown, the MEC host network entity 400 includes an MEC platform 402, which includes one or more MEC services 404. The MEC platform 402 is a collection of functions required to run MEC applications 406 on a specific MEC host virtualization infrastructure and enable them to provide and consume MEC services 404, and can provide many MEC services 404 to itself. MEC services 404 are services provided via the MEC platform 402, which can be provided either by the MEC platform itself or by the MEC applications 406. One or more MEC applications 406 can run on the MEC host network entity 400. An MEC application 406 is an application that can be instantiated on the MEC host network entity 400 within the MEC system and can potentially provide or consume MEC services 404. Although... Figure 4 MEC application 406 running on MEC host network entity 400 is shown, but it will be appreciated that one or more of MEC applications 406 may alternatively run on a network entity configured to communicate with MEC host network entity 400. Figure 4 One possible deployment is illustrated, in which the MEC platform / edge platform 402 includes O-RAN nodes and core network nodes (5GC, UPF). The MEC application 406 may include an xApp or external app (e.g., application functionality) hosted on the edge / MEC platform 402.

[0071] ETSI MEC allows APIs to be exposed from the RAN to the MEC platform. Exposing APIs from the UE / RAN to service providers may involve UE location information, bandwidth management, and Radio Network Information (RNI). ETSI GS MEC 012 specifies the exposure of RNI APIs from the RAN to the MEC. More specifically, MEC service 404 may include a Radio Network Information Service (RNIS), which provides radio network-related information to MEC application 406 and MEC platform 402. The granularity of the radio network information can be adjusted based on parameters such as information per cell, per user equipment, and per QoS category, or it can be requested within a time period. This radio network information can be used by MEC application 406 and MEC platform 402 to optimize existing services and provide new types of services based on up-to-date information about the radio condition.

[0072] In addition, MEC service 404 may include MEC services related to vehicle-to-everything (V2X) use cases, namely the V2X Information Service (VIS). This service is designed to facilitate V2X interoperability in multi-vendor, multi-network, and multi-access environments. Some functions of the MEC VIS service include: (i) collecting PC5 V2X-related information from the 3GPP network (e.g., a list of authorized UEs, information about UE-based subscription authorizations, and related PC5 configuration parameters); (ii) exposing this information to MEC apps (which may also belong to different MEC systems); (iii) enabling MEC apps to communicate securely with V2X-related 3GPP core network logical functions (e.g., V2X control functions); (iv) enabling MEC apps in different MEC systems to communicate securely with each other; and (v) potentially collecting and processing information available in other MEC APIs.

[0073] Blockchain (and other distributed ledger technologies) is a promising technology for enhancing vertical applications and is an important component of the application layer within wireless communication networks such as 5G networks. Some vertical industries that may benefit from the use of distributed ledgers include: • Finance: such as ID verification, financial management, fraud risk mitigation, payments and P2P transactions, and financing. • Healthcare: Collecting and sharing sensitive healthcare-related data / records in a secure manner. • Commercial / Industrial IoT: Multi-party data exchange, logistics coordination, and automated payments and contracts between IoT devices (such as AGVs / robots). • Cars: Autonomous vehicles will perform a range of tasks (such as toll payment, firmware updates, and parking) without human intervention.

[0074] There are three types of blockchains: public blockchains (i.e., permissionless blockchains), consortium blockchains, and private blockchains (i.e., permissioned blockchains). The key concepts of blockchains are: 1) the use of a shared ledger that is available on all nodes in the blockchain network; 2) smart contracts, which are transaction protocols used to automate the execution of micro-transactions; and 3) consensus on verifying transactions through majority voting among the nodes that enable the blockchain (also referred to in this paper as nodes coupled to the DLT network).

[0075] Currently, blockchain (and other distributed ledger technologies) are access-agnostic, meaning transactions occur at the application layer and are transparent to the underlying network. However, with vertical integration with 5G networks and the need for end-to-end data protection and transaction optimization on 5G systems, there are areas where interoperability between the communication layer and the application layer is crucial to ensuring end-to-end security requirements are met.

[0076] More specifically, for these industries, some key applications that may require joint interoperability between the communication layer and the application layer include: • Data tamper-proofing: Some vertical industries have stringent requirements for data integrity and traceability, such as environmental data (e.g., temperature and wind speed) for agricultural insurance and warehouse data (e.g., quantity and weight of goods) for inventory financing. These services require end-to-end data tamper-proofing and traceability; and when using 5G for communication, this places new demands on transaction processing within the 5G domain (RAN, transport, core network). • (Multiple) Application Credentials: Third-party identity management systems can issue tamper-proof digital credentials that can be verified anywhere without disclosing the actual identity. 5G can provide a component for associating / providing / securely delivering these credentials based on workflows / data / assets. • Decentralized Workflow: Based on blockchain smart contracts, industry applications can leverage the distributed edge of 5G networks to execute decentralized workflows.

[0077] Over the past decade, blockchain technology has been widely applied in various sectors globally. Blockchain is largely known as a shared, immutable ledger for recording transactions, tracking assets, and establishing trust. With the development of blockchain concepts and related technologies, it is foreseeable that mobile communication systems (such as 5G) will benefit from implementing blockchain technology for a growing number of vertical industries. A blockchain is a distributed data structure in which a replica of the blockchain is maintained at each of the many nodes in a distributed peer-to-peer (P2P) network (hereinafter referred to as a "blockchain network") and is widely publicized. A blockchain consists of a chain of blocks of data, where each block includes one or more transactions, where a transaction in this context is a data structure. Maintaining a replica of the blockchain does not necessarily mean storing the entire blockchain. Instead, as long as the block header of each block is stored, the data in the blockchain can be pruned. Nodes in a blockchain network perform a distributed transaction registration and verification process. During this process, nodes in the blockchain network verify transactions and create new blocks according to consensus mechanisms such as Proof-of-Work (PoW), Proof-of-Stake (PoS), etc. The new block is propagated to other nodes in the blockchain network, enabling each node to record the new block on the blockchain.

[0078] This document refers to nodes that enable blockchains as nodes in a blockchain network that participate in verifying transactions and / or creating new blocks (e.g., “miners” in a proof-of-work blockchain network). Nodes enabling blockchains can be network-automated application entities (e.g., xApps) or virtualized wireless functions (e.g., near-RT RIC framework functions or E2 nodes (e.g., CU and / or DU functions)). Nodes enabling blockchains can also be application clients on the UE.

[0079] Nodes enabling a blockchain can be of four types: (i) control plane operation service producers (also referred to herein as "service producers"), (ii) control plane operation service consumers (also referred to herein as "service consumers"), (iii) oracles, and (iv) validating entities. Control plane operation service producers are entities that run or decide on control plane operations (e.g., MAC schedulers at xApp or DU). Control plane operation service consumers are entities that request control plane operations and consume their output (e.g., RICs that consume RRM outputs such as cell reselection commands). Oracles (described in detail below) are entities that handle connectivity between the blockchain network and entities outside the blockchain network. Validating entities are blockchain nodes that participate in validating transactions and creating new blocks.

[0080] In contrast, this article refers to nodes in non-enabled blockchains as nodes that are not part of the blockchain network. Nodes in non-enabled blockchains may participate in control plane operations (e.g., by providing measurement data) but do not have the ability or permission to become part of the blockchain network. Nodes in non-enabled blockchains can be network automation application entities (e.g., xApps), RAN functions (e.g., near-RT RIC framework functions or E2 nodes (e.g., CU, DU, and / or RU functions)), or external functions (outside of the O-RAN or vRAN platform or MNO, such as external app servers or device apps).

[0081] Figure 5 An example is shown where some or all of the O-RAN entities can be blockchain-enabled. For O-CU / O-DU nodes, this may require the E2 agent to be blockchain-enabled. Many use cases can exist that can be defined based on the deployment.

[0082] In the first use case, all types of nodes (running at the application layer, the network layer, the near-RT RIC 204, and the device / UE) can be part of the blockchain network and therefore enable the blockchain. Furthermore, the framework function 208 on the near-RT RIC 204 can act as an oracle for interacting with nodes outside the blockchain network (non-blockchain-enabled nodes) (e.g., network resource registries, API registries, third-party apps). This advantageously provides a maximum level of security, but the xApp needs to already be known to the blockchain network, therefore the xApp cannot be disabled.

[0083] In the second use case, the network layer nodes are blockchain-enabled nodes (e.g., the E2 agent at DU / CU is a blockchain node), the near-RT RIC 204 and / or the framework function 208 on the near-RT RIC 204 run as an oracle, while the xApp resides outside the blockchain network (i.e., a non-blockchain-enabled node). The speed of the blockchain network may be affected, making the second use case intended only for instructions related to semi-static aspects (e.g., activating DU, enabling DC / CA).

[0084] In the third use case, the near-RT RIC 204 and / or the framework function 208 on the near-RT RIC 204 (and possibly some xApps) are the nodes that enable the blockchain. Furthermore, the framework function 208 on the near-RT RIC 204 can act as an oracle for interacting with nodes outside the blockchain network (nodes that are not enabled by the blockchain). RAN nodes (i.e., E2 nodes) and xApps are located outside the blockchain network (i.e., nodes that are not enabled by the blockchain). The third use case is more suitable for dynamic transactions, but operations occurring off-chain have lower security (separate channels), and sidechains may partially address this issue.

[0085] Figure 6 A process 600 is illustrated for securing the integrity of control plane operations in a wireless communication network (e.g., a radio access network) using a distributed ledger technology (e.g., blockchain). While embodiments are described with reference to blockchain, it will be appreciated that the embodiments extend to distributed ledger technologies other than blockchain. That is, although this document mentions submitting data to a blockchain, it will be appreciated that a blockchain is an example of a data structure comprising multiple linked blocks of data, and the embodiments extend to submitting data to other types of distributed ledgers. Process 600 includes a configuration phase 620 and runtime phases 630, 640. Process 600 can be performed in many network architectures. For example, process 600 can be performed in an O-RAN architecture, an MEC architecture, or other network architectures.

[0086] At step S621, SMO / ASP 602 sends a request message indicating a requirement to protect the integrity of control plane operations in the wireless communication network using distributed ledger technology (DLT) (such as blockchain). The request message is received by Blockchain Enablement Function (BEF) 604. In the O-RAN architecture, to name just a few examples, BEF 604 could be deployed as a dedicated framework function 208, part of O1T framework function 208 (which could route this request to the relevant RIC module), xApp 210 running on near-RT RIC 204, a service / API registry at near-RT RIC 204, an xApp running on a network entity communicating with near-RT RIC 204, or could be deployed as an rApp running on non-RT RIC 202. In the MEC architecture, to name just a few examples, BEF 604 could be deployed as a service / API registry at MEC service 404, MEC app 406, or MEC host network entity 400. At step S621, SMO / ASP 602 may request the RIC / MEC platform provider to enable RIC / MEC operations on the blockchain for a specific xApp or specific use case (E2SM).

[0087] The request message received by BEF 604 at step S621 indicates a requirement for control plane operations to ensure end-to-end integrity protection using distributed ledger technology. Such a request may be in the form of a single request or a subscription request to provide such services.

[0088] The request message includes information that enables BEF 604 to identify nodes of multiple enabled blockchains participating in control plane operations.

[0089] The request message may include an identifier for each of the multiple nodes enabling the blockchain (e.g., one or more service producers and one or more service consumers), such as xApp #ID (service producer), RIC platform function #ID (service consumer), and E2 node #ID (service consumer). The request message may also optionally include the network address associated with each of the multiple nodes enabling the blockchain.

[0090] Alternatively or additionally, the request message may include an identifier for a control plane operation. This identifier may include: (i) the name of the control plane operation (e.g., a QoS optimization operation); (ii) the type or configuration of the control plane operation (e.g., SON, inter-cell RRM, or RRC); and (iii) (multiple) the use cases to which the control plane operation applies (e.g., V2X handover optimization).

[0091] The request message may include the validity period and / or region of the request. The region may be a geographic area (e.g., specified by coordinates) or a topology (e.g., a list of one or more cells).

[0092] The request message may include exposure requirements for interacting with node 612 of a non-enabled blockchain, defining what will be exposed (permissions and topology hiding). For example, if the exposure requirement targets an external application owned by a different provider, oracle 610 may need to perform an abstraction or triggering action of the measurement data. For example, the triggering action could be related to a handover (HO) of a set of UEs, and oracle 610 might only provide notification to inform of the expected HO without mentioning all the details related to the RAN topology (based on the exposure requirement).

[0093] The request message may include an indication of the radio access technology to be used for control plane operations (e.g., 4G, 5G, 6G, etc.). The request message may include an identifier of the public land mobile network (PLMN) to be used for control plane operations (e.g., in the case of multi-operator support). The request message may include spectrum considerations to be used for control plane operations. The request message may include one or more performance requirements for control plane operations (e.g., KVI / SLA / KPI for control plane operations). The one or more performance requirements may relate to timing constraints / latency, energy targets, reliability, trust, etc.

[0094] At step S622, the BEF 604 obtains a policy based on the request message. The policy defines predefined actions to be performed when a trigger event associated with the wireless communication network is detected, wherein the predefined actions include control plane operations.

[0095] The policy may be a smart contract. Smart contracts are automated contracts. They are self-executing, with specific instructions written into their code that are executed when certain conditions are met. A smart contract is a sequence of instructions that operates based on IFTTT logic (i.e., IF-THIS-THEN-THAT logic). That is, if a first set of instructions is executed, the next function is executed, and then the next function is executed thereafter, repeating continuously until the end of the smart contract is reached. The policy may translate the service / exposure requirements specified in the request message received by the BEF 604 at step S622 into automated scripts that run on all blockchain-enabled nodes. The policy may be in the form of trigger events and actions, and optionally in the form of penalties when requirements are not met.

[0096] An example of a smart contract may be: IF the load of E2 node #1 > X% and QoE parameter #x < Y, THEN automatically trigger cell reselection to an E2 node closer to the affected UE, THEN trigger HO at that node.

[0097] The BEF 604 may obtain the policy by creating the policy. Alternatively, the BEF 604 may store a plurality of policies (e.g., each policy applicable to certain use cases or control plane operation types / configurations) and obtain the policy by retrieving the policy from a memory. The policy includes a set of trigger events, and for each trigger event, includes one or more automated trigger actions that will be executed in response to the trigger event after network consensus is reached among the blockchain-enabled nodes in the blockchain network.

[0098] The criteria for obtaining a policy for control plane operations (e.g., retrieving or creating a policy) may include the following items: • Necessary actions at the decision-making entity level to prevent performance degradation / failure to meet KPIs in control plane operations. These actions can be proactive (based on predicted / anticipated conditions) or reactive (after identifying problems—such as resource shortages or conflicts). Such necessary actions can be derived using analytics / statistics from previous adaptations based on similar control plane operations. • A series of actions that may depend on the initial triggering action. For example, a change in resource allocation for a specific cell may lead to further changes in other resource allocations determined by different entities. Different RRM / SON mechanisms affecting the same radio resources may have dependencies and potential conflicts. Therefore, it is important to capture all relevant dependencies in the policy. • Triggered actions (or a series of actions) determined based on global target objects (such as energy sustainability / optimization, or user plane / data plane performance corresponding to control plane operations). For example, a control plane operation requesting more resources for a given video session between two or more UEs needs to ensure that the video session meets KPIs (such as throughput, latency). • Exposure requirements / permissions and capabilities (e.g., processing power, energy capacity, availability to receive real-time monitoring, etc.) used to enforce smart contracts at nodes of interest.

[0099] Example trigger event-action pairs may include: - Triggering event: The load of cell #1 reaches the upper limit threshold (e.g., 80%). - Trigger Action 1: Begin monitoring the load of neighboring candidate target cells and the location of UEs in the source cell (or the predicted mobility of these UEs). - Trigger Action 2: If one or more neighboring cells have low load, select a target cell to share the load and trigger an HO for UEs located at the edge of high-load UEs. - Trigger Action 3: If possible, increase the power of the target cell / extend the coverage of the target cell to accommodate the target UE.

[0100] Figure 7 An example of a smart contract is shown. For example... Figure 7 As shown, triggering events associated with the radio access network may include: receiving an RRC msg3 message, S1 bearer setup, X2 HO request message, or exceeding a cell load threshold. Figure 7As shown, predefined actions to be performed in the radio access network in response to a triggering event (after network consensus is reached among nodes enabling the blockchain) may include: UE admission, bearer admission, HO initiation, or RRC connection release. Smart contracts can define supported conditions, which define the conditions that trigger the event. For example, the network interface type to which the event applies (E2 interface, X2 / Xn, RIC API).

[0101] Figure 7 An example trigger event-action combination is shown. Using smart contracts, each combination of trigger and action is set as a rule that can be automatically enforced, and no party can interfere with the decision.

[0102] BEF 604 is configured to identify entities (i.e., nodes that enable the blockchain) that need to receive and enforce the policy. As mentioned above, such entities can be RIC framework functions or virtualized wireless access network functions within xApp or (multiple) wireless communication platforms.

[0103] At steps S623a and S623b, BEF 604 sends the policy to the nodes of the enabled blockchain that will participate in the control plane operation (so that the nodes of the enabled blockchain are aware of the actions to be taken when the triggering event occurs). Participation in the control plane operation may include: (i) verifying the transaction that identifies the control plane operation; (ii) creating a new block that includes the transaction that identifies the control plane operation; (iii) performing the control plane operation as a service producer (e.g., sending a message and / or providing a requested service); and / or (iv) performing the control plane operation as a service consumer (e.g., receiving a message and / or receiving a requested service). The nodes of the enabled blockchain that receive the policy may include (multiple) service producers, (multiple) service consumers, (multiple) oracles, and (multiple) further / intermediate nodes (which are only used to maintain this information and verify transactions when needed). Such entities may be RAN functions, xApps, RIC functions, gateway functions, or external app servers.

[0104] Figure 6 A simple example is shown where the first enabled blockchain node 606 and the second enabled blockchain node 608 will participate in the control plane operation and thus receive the policy from BEF 604.

[0105] At step S624, BEF 604 configures oracle 610 to interact with external entities (outside the blockchain network) (i.e., node 612 of the non-enabled blockchain), for example, to send data to and receive data from node 612 of the non-enabled blockchain. For example, BEF 604 configures oracle 610 to receive information such as API status, service availability, and resource availability. Specifically, at step S624, BEF 604 sends at least one configuration message to oracle 610. This configuration message includes: (i) a policy, and (ii) an identifier for each of the plurality of enabled blockchain nodes participating in the control plane operation.

[0106] By knowing the policy and the entities involved in (i.e., participating in) the control plane operation, oracle 610 will be able to detect triggering events and, for a given control plane operation, map the triggering action to the necessary interaction with external entities. For example, a request or measurement may be received by a BC node, and the oracle may generate a notification to an external entity (e.g., a non-enabled blockchain node 612) to inform it of the triggering action or, generally, to interact with it based on the policy. At least one configuration message may also include interaction information defining: (i) information to be sent by a network entity to one or more nodes outside the DLT network in response to the detection of a control plane operation; and (ii) an identifier for each of the one or more nodes outside the DLT network. Therefore, BEF 604 can utilize the interaction information to configure oracle 610, defining which entities outside the blockchain network the oracle needs to send what information when oracle 610 detects that a control plane operation has been performed. This interaction may form part of the exposure requirement received by BEF 604 in the request message at step S621.

[0107] The oracle 610 is not considered a "service producer" or "service consumer," but rather a different type of entity that facilitates interaction between identified blockchain-enabled entities and the external world. In the example smart contract above, the oracle is used as a gateway to receive the predicted / actual UE location within the cell of interest. This UE location can be inferred by the ASP / device application. The oracle 610 will also be referred to as a gateway node in this document.

[0108] Oracle 610 can be configured as a new capability on existing 3GPP-defined gateways (CAPIF AEF, NEF, EGMF, edge or cloud platform gateways) and requires policies to enable interaction with external entities (such as triggering notifications and subscribing to receive monitoring).

[0109] Multiple configuration messages may include identifiers for control plane operations. As noted above, identifiers for control plane operations may include: (i) the name of the control plane operation (e.g., a QoS optimization operation); (ii) the type or configuration of the control plane operation (e.g., SON, inter-cell RRM, or RRC); and (iii) the use case to which the control plane operation applies (e.g., V2X handover optimization).

[0110] Multiple configuration messages may include exposure requirements received in the request message at step S621 of BEF 604 (e.g., if topology hiding is required, Oracle will not expose the actual measurements of the wireless communication network (e.g., RAN), but rather an abstract version thereof). Exposure requirements may include permissions defining what external entities are allowed to do (e.g., which in CRUD operations) based on the information exposed. Exposure requirements may include exposure levels defining what can be exposed, for example, based on: 1) which is the external entity, such as trusted or untrusted, and 2) the criticality and sensitivity of the information to be exposed.

[0111] At step S625, Oracle 610 registers an API with the Application Programming Interface (API) registry. This API enables Oracle 610 to receive data from one or more nodes outside the DLT network (i.e., non-blockchain-enabled node 612) for transmitting data to blockchain-enabled nodes to detect triggering events. The API registry is used when external entities (e.g., xApps, non-blockchain-enabled RIC modules, etc.) need to interact with the blockchain network. Specifically, the API registry ensures that entities outside the blockchain network can discover how to interface with Oracle 610 and thus interact with the blockchain network. The API provides all the information required for interaction (POST, GET, ...). The API registry manages the registration and discovery of APIs (e.g., near-RTRIC APIs). The API registry (e.g., in a local database) stores API information (e.g., name, ID, protocol, version, and / or configuration file, etc.) and publishes this information to entities that will be part of the control plane operation but are not within the blockchain network (i.e., non-blockchain-enabled node 612).

[0112] Oracle 610 can include an API registry, or the network entity on which Oracle 610 resides can also include an API registry. Alternatively, the API registry can reside on a network entity outside of Oracle 610.

[0113] In step S626, the API registry publishes the API to the external entity (i.e., node 612 that does not enable the blockchain). Figure 6The example shown is an Oracle 610 API registry. External entities can query such APIs, and the publication of APIs by the API registry can be a response to such a query, or the publication of APIs by the API registry can occur based on a service agreement (e.g., between a RIC provider and an ASP). For example, once a new API exists, the API registry announces / publishes the API to its subscribers (e.g., apps already loaded into the RIC platform or external apps with a connection to the RIC platform).

[0114] Figure 6 The first example of runtime phase 630 is shown.

[0115] At step S631, the first enabled blockchain node 606 receives measurement data from one or more non-enabled blockchain nodes 612. This measurement data pertains to a wireless communication network (e.g., a wireless access network). The measurement data is transmitted from one or more non-enabled blockchain nodes 612 to the first enabled blockchain node 606 via oracle 610.

[0116] At step S632, the first enabled blockchain node 606 detects a trigger event based on measurement data (e.g., a RAN monitoring event based on measurements received by one or more of the CU / DU / UE via oracle 610). Furthermore, the first enabled blockchain node 606 executes a policy to determine a predefined action to be performed based on the trigger event. This predefined action includes control plane operations in the wireless communication network. For example, the predefined action could be sending a RIC control message to the second enabled blockchain node 608 (e.g., xApp).

[0117] At step S633, the first blockchain-enabled node 606 sends transaction information identifying the predefined action to one or more blockchain-enabled nodes in the blockchain network. The blockchain network verifies the transaction information (e.g., via PoW, PoS, or other consensus mechanisms), and the blockchain-enabled nodes (e.g., miners) propose a new block (including the transaction information) to the blockchain and distribute the block to the remaining blockchain-enabled nodes in the blockchain network.

[0118] The transaction information sent at step S633 may include one or any combination of the following: (i) a transaction identifier, (ii) a control plane identifier, (iii) an identifier of a predefined action, (iv) a reason for triggering an event, (v) an identifier of each of one or more nodes in the enabled blockchain involved in (i.e. participating in) the control plane operation, (vi) one or more constraints for fulfilling the control plane operation, such as time limits and / or applicable regions for the transaction, and (vii) an identifier of each of one or more nodes outside the DLT network involved in (i.e. participating in) the control plane operation.

[0119] At step S634, once consensus has been reached on the new block (and therefore all transactions within that block), all nodes that enable the blockchain update their blockchain database / records based on the new block.

[0120] In response to the submission of transaction information (identifying a predefined action) to the blockchain, the first enabled blockchain node 606 executes the predefined action, for example, by sending a RIC control message to the second enabled blockchain node 608.

[0121] In an embodiment where oracle 610 is part of a blockchain network (i.e., a node enabling the blockchain), oracle 610 will receive a new block after network consensus on transaction information, and will therefore detect that a control plane operation will be performed (the new block includes transaction information identifying the control plane operation). As noted above, this may cause oracle 610 to send a notification to an external entity (such as node 612 that does not enable the blockchain) to inform it of the triggered action (control plane operation).

[0122] exist Figure 6 In the example, node 608 of the second enabled blockchain receives RIC control messages from node 606 of the first enabled blockchain. Receiving RIC control messages can act as a triggering event for a policy to run on node 608 of the second enabled blockchain. Specifically, at step S635, node 608 of the second enabled blockchain decodes the RIC control messages and automatically executes a predefined triggering action based on the policy, such as automatically authorizing a new instruction that forces a HO to initiate. At step S636, node 608 of the second enabled blockchain can receive information about the resource / location from an external source, as well as other information required to identify the predefined action (this can be based on a policy / smart contract). Node 608 of the second enabled blockchain uses oracle 610 to forward the HO initiation request to the service provider (e.g., the RAN function to be adapted).

[0123] Figure 6 A second example of runtime phase 640 is also shown.

[0124] At step S641, BEF 604 receives a request for a service from one or more nodes 612 of the non-enabled blockchain. An example RIC service has been described above. For example, a service could be a CONTROL, POLICY, or guidance service. The term "service" is used here to refer to a function requested by a node 612 of the non-enabled blockchain. As an example, such a service could be a monitoring service or a request for controlling RAN parameters. A service could also be a communication service, an automation service, or an application service coupled to the underlying radio access network. The request for the service is sent to BEF 604 via oracle 610 from one or more nodes 612 of the non-enabled blockchain. For example, a service consumer (e.g., an MEC App, xApp, etc.) can use an API (registered at the API registry mentioned above) to send a request for a specific RIC service.

[0125] At step S642, BEF 604 broadcasts the request to one or more blockchain-enabled nodes in the blockchain network. For example, the request could be broadcast to all blockchain-enabled nodes (or a permissioned set of those nodes).

[0126] The policy stored by node 606 of the first enabled blockchain can define receiving a request for a service as a triggering event. At step S642, node 606 of the first enabled blockchain detects this triggering event based on the receipt of the request for the service. Furthermore, node 606 of the first enabled blockchain executes the policy to determine a predefined action to be performed based on the triggering event. This predefined action includes control plane operations in a wireless communication network. As an example only, this predefined action could be providing the requested service to node 612 of a non-enabled blockchain outside the blockchain network.

[0127] At step S642, the first enabled blockchain node 606 sends transaction information identifying the predefined action to one or more enabled blockchain nodes in the blockchain network. The blockchain network verifies the transaction information (e.g., via PoW, PoS, or other consensus mechanisms), and the enabled blockchain nodes (e.g., miners) propose a new block (including the transaction information) to the blockchain and distribute the block to the remaining enabled blockchain nodes in the blockchain network.

[0128] The transaction information sent at step S642 may include one or any combination of the following: (i) a transaction identifier, (ii) a control plane identifier, (iii) an identifier of a predefined action, (iv) a reason for triggering an event, (v) an identifier of each of one or more nodes in the enabled blockchain involved in (i.e. participating in) the control plane operation, (vi) one or more constraints for fulfilling the control plane operation, such as time limits and / or applicable regions for the transaction, and (vii) an identifier of each of one or more nodes outside the DLT network involved in (i.e. participating in) the control plane operation.

[0129] At step S643, once consensus has been reached on the new block (and therefore all transactions within that block), all nodes that enable the blockchain update their blockchain database / records based on the new block.

[0130] In response to a transaction message (identifying a predefined action) being submitted to the blockchain, the first enabled blockchain node 606 executes the predefined action, for example, by providing the requested service to a non-enabled blockchain node 612 outside the blockchain network via oracle 610.

[0131] At step S644, after receiving a message from BEF 604 that includes a request for a service (e.g., a CONTROL service for RAN resources), the target node (the first enabled blockchain node 606) decodes the message and automatically executes a predefined triggering action based on the smart contract (e.g., automatically authorizing a new instruction that forces a HO to initiate).

[0132] At step S645, the target node (node ​​608 of the second enabled blockchain) operates in the same manner. Specifically, after receiving a message from BEF 604 that includes a request for the service, node 608 of the second enabled blockchain decodes the message and automatically executes a predefined triggering action based on the smart contract (e.g., automatically authorizing a new instruction initiated by a forced HO).

[0133] As shown in step S646, the target node can also receive information about the resource / location and other information required to identify the action from an external source (i.e., node 612 without enabling the blockchain) (this can be based on a smart contract). The target node uses oracle 610 to forward the request to the service provider (e.g., the RAN function that will be adapted).

[0134] The functionality of one or more of BEF 604, the first blockchain-enabled node 606, the second blockchain-enabled node 608, and Oracle 610 can be implemented on the same or different physical devices. Specifically, the functionality of one or more of BEF 604, the first blockchain-enabled node 606, the second blockchain-enabled node 608, and Oracle 610 can be implemented using software that executes on the same or different processors.

[0135] Process 600 can be executed within network architecture 200. Specifically, BEF 604 can be deployed as a new framework function 208 on near-RT RIC 204, or as xApp 210, or as an SMO / rApp function on the management side. BEF 604 can be configured with APIs for interacting with external entities (non-blockchain-enabled nodes 612) and will create / store policies. In this implementation, the blockchain-enabled nodes can correspond to existing framework functions 208, xApp, and / or E2 nodes, depending on the implementation. Such blockchain-enabled nodes are already known to BEF 604 (and can be pre-configured), or the list can be maintained and retrieved by a repository storing the identities and capabilities of all blockchain-enabled nodes (e.g., this can be performed by API-enabled RIC function 206). In this implementation, oracle 610 can correspond to API-enabled function 206 or exposed gateways / functions (such as NEF, AEF (as in TS 23.222), EGMF). Node 612, which is not enabled by the blockchain, can be another O-RAN entity outside the blockchain network (without the ability and permission to access the blockchain network).

[0136] In network architecture 200, an example of operation using the O-RAN RIC paradigm is as follows. The Shared Data Layer (SDL) service (framework function 208 of near-RT RIC 204, which provides database services (R-NIB, UE-NIB)) can be registered with BEF 604 as a node enabling the blockchain (requiring storage and smart contract deployment). The SDL database is available to all nodes enabling the blockchain (permissions are granted by BEF 604). Transactions are initiated by the SDL service to distribute data; and each transaction may become a new block on the blockchain. When a new request for SDL database data (network or UE data) arrives from the Conflict Mitigation (CM) function (framework function 208 of near-RT RIC 204), the transaction is verified (via network consensus), and based on the smart contract, the SDL service automatically publishes the data to the requesting CM function. Depending on the specific deployment, the CM function can be a node enabling the blockchain or a node not enabling the blockchain. When the trigger condition (load of cell #1 > X%) is met, a transaction is initiated at the CM function based on a smart contract to automatically extract the analysis of cell #1. This is verified by all nodes and then sent to the CM function. The CM function uses this data without knowing who provided the data or whether the data is reliable.

[0137] Process 600 can also be performed in MEC implementations, for example, in the context of providing VIS / RNIS MEC services. Specifically, BEF 604 can be a new MEC service 404. In this implementation, the nodes enabling the blockchain can correspond to existing MEC services 404 and / or MEC apps 406. Oracle 610 can be an API-enabled service. If the MEC is utilizing CAPIF, such an API-enabled service can be a CAPIF Core Functionality (CCF) or an API Exposure Functionality (AEF). Nodes not enabling the blockchain 612 can be other MEC services 404, MEC apps 406, and / or RAN functions outside the blockchain network. An example operation using the ETSI MEC paradigm is as follows: The RNI service provider registers RNIS with BEF 604 as a node enabling the blockchain (requiring the deployment of storage and smart contracts). RNIS is available to all nodes enabling the blockchain (permitted by BEF 604). Transactions are initiated by the RNI service producer to distribute data; and each transaction on it can potentially become a new block on the blockchain. RNIS acquires measurements (e.g., radio bearer status) from the RAN side via Oracle 610. When a trigger condition (DRB load #1 > X%) is met, a transaction is then initiated at the RNIS producer or BEF based on a smart contract to automatically trigger notifications and automated actions to all involved nodes in the blockchain network (the intended RNIS consumers). This is verified by all nodes enabling the blockchain and then sent to the RNIS producer / BEF. For example, RNIS consumers could be MEC apps or abstract RRM / SON functions that receive notifications about automated actions, which may trigger further actions on the consumer side.

[0138] Reference Figure 8We describe a first example use case of the runtime phase in embodiments of this disclosure. Roles in this first example use case include: an application (e.g., xApp) requesting / receiving services, i.e., a service consumer (SC) 802; a network function (NF) providing the service (which may be a RAN entity), i.e., a service provider (SP) 804; and an oracle 610 (which may be a new framework function on near-RT RIC 204) that handles connectivity between the blockchain network and external APIs (which can be considered middleware / API gateways) and verifies smart contract actions. The service is verified on the blockchain network (all nodes enabling the blockchain receive requests and verify them via consensus). A smart contract 806 running on a node enabling the blockchain provides rules for service provision. The smart contract can define trigger event-action combinations, such as: IF trigger event (load > X, number of users in cell #X > Y), THEN automatically trigger a smart contract event (e.g., expose to xApp 802).

[0139] In the first example use case, the following steps can be performed: (1) Near-RT RIC 204 creates a smart contract (which can be considered an SLA) with MNO and publishes it to the blockchain network; (2) xApp 802 registers with the blockchain network (permissioned blockchain); (3) xApp 802 makes a payment to a smart contract for a specific service (such as business guidance (TS) optimization) - funds are reserved, but the service provider has not yet received them; (4) The smart contract verifies the identity and available resources of xApp 802 (using Oracle 610) and adds the transaction to the blockchain; (5) Once the rules are met, the smart contract pays funds to MNO; (6) xApp 802 can start using services from MNO (TS optimization); (7) When an external event occurs (such as a resource failure), the smart contract attempts to resolve it or automatically pays a penalty to xApp802;

[0140] More specifically, for step (7), the following steps can be performed: (a) Capture the event (expected resource depletion) at RAN and broadcast it to the blockchain network; (b) The smart contract will match the monitoring event service provider with the service consumer (e.g., xApp #1, RIC function #2); (c) Smart contracts automatically trigger actions based on rules and request information from external sources about other aspects (e.g., from the UE / RAN database). This is done via Oracle 610; (d) The smart contract receives additional data and automatically determines the action to be performed, such as cell reselection for some users, more bandwidth for cell #A, and DC for cell #A; (e) If the smart contract fails to meet the requirements, it pays a penalty to xApp 802. If the smart contract successfully resolves the issue, it charges xApp 802.

[0141] Reference Figure 9 We describe a second example use case of the runtime phase in embodiments of this disclosure. Roles in this second example use case include: an application (e.g., xApp) 902 that requests / receives services as an external entity (outside the blockchain network) (e.g., as node 612 of a non-enabled blockchain); and an oracle 610 that handles connectivity between the blockchain network and an external API toward xApp 902 for input / output relative to services provided by a service provider. The service is validated on the blockchain network within the near-RT RIC 204 and RAN (all nodes receive requests for the service and validate them via consensus). A smart contract 906 provides the rules for service provision and is not visible at xApp 902.

[0142] In the second example use case, the following steps can be performed: (1) Near-RT RIC 204 creates a smart contract (which can be considered an SLA) with MNO and publishes it to the blockchain network; (2) xApp 902 registers with RIC Oracle Function 610 (via xApp registration, Oracle 610 can be considered a new security management service). (3) xApp 902 makes a request for a specific service (e.g., by sending an API call request), which corresponds to step S641; (4) Oracle 610 interacts with the RIC functions that enable the blockchain (e.g., the functions that will provide the service) and broadcasts the service request as a new transaction to the blockchain network (RIC, RAN, ...). (5) The smart contract verifies the identity and available resources of the transaction (using Oracle 610) and adds the transaction to the blockchain; (6) Smart contracts verify transactions through network consensus; (7) The smart contract provides the requested service via the API provided by Oracle, via Oracle 610; (8) When a triggering event occurs (e.g., a resource failure), the smart contract either attempts to resolve it by interacting with the nodes that enable the blockchain, or by interacting with external nodes (e.g., resources, API registry, ...), or by interacting with xApp via oracle610 to pay the penalty.

[0143] although Figure 8 and Figure 9 The examples illustrate a single service provider and a single service consumer, but policies (such as smart contracts) can also target end-to-end control plane operations involving multiple service producers and / or consumers (e.g., dependent load balancing RRM functions and disturbance management RRM functions may be part of the same or different control plane operations). In the use cases below, we describe single SP and SC scenarios. References Figure 8 and Figure 9 The described use case does not show the configuration phase, but only the runtime phase. As described above, the configuration phase involves configuring smart contracts for each service provider, service consumer, and oracle. Furthermore, some parts of the control plane operations can occur off-chain or on the sidechain to improve time efficiency, etc. (e.g., allowing faster interaction between (multiple) service providers and (multiple) service consumers).

[0144] While current technical solutions are based on point-to-point integrity protection for control operations in virtualized RAN deployments and do not cover distributed consensus-based methods that can be implemented using DLT / blockchain networks, embodiments of this disclosure provide a mechanism for ensuring end-to-end trust when exposing O-RAN / virtualized RAN services (which may be related to the access network, RIC, and UE context) to entities (e.g., xApp, MEC app, etc.) via a distributed network of nodes with enabled blockchains.

[0145] Figure 10 An example of a processor 1000 according to various aspects of this disclosure is shown. The processor 1000 may be an example of a processor configured to perform various operations according to the examples described herein. The processor 1000 may include a controller 1002 configured to perform various operations according to the examples described herein. The processor 1000 may optionally include at least one memory 1004, which may be, for example, an L1 / L2 / L3 cache. Additionally or alternatively, the processor 1000 may optionally include one or more arithmetic logic units (ALUs) 1006. One or more of these components may be electronically communicated or otherwise coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces (e.g., buses).

[0146] Processor 1000 may be a processor chipset and may include a protocol stack (e.g., a software stack) executed by the processor chipset to perform various operations (e.g., receive, acquire, retrieve, send, output, forward, store, determine, identify, access, write, read) according to examples as described herein. The processor chipset may include one or more cores, one or more caches (e.g., memory located locally in or included in the processor chipset (e.g., processor 1000)) or other memory (e.g., random access memory (RAM), read-only memory (ROM), dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), static RAM (SRAM), ferroelectric RAM (FeRAM), magnetic RAM (MRAM), resistive RAM (RRAM), flash memory, phase-change memory (PCM), and others).

[0147] Controller 1002 can be configured to manage and coordinate various operations of processor 1000 (e.g., sending, receiving, acquiring, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, and reading via signaling) to enable processor 1000 to support various operations according to the examples described herein. For example, controller 1002 can operate as a control unit of processor 1000, generating control signals that manage the operations of various components of processor 1000. These control signals include enabling or disabling functional units, selecting data paths, initiating memory accesses, and coordinating the timing of operations.

[0148] Controller 1002 may be configured to fetch (e.g., obtain, retrieve, receive) instructions from memory 1004 and determine the instructions to be subsequently executed, such that processor 1000 supports various operations according to the examples described herein. Controller 1002 may be configured to track the memory addresses of instructions associated with memory 1004. Controller 1002 may be configured to decode instructions to determine the operations to be performed and the operands involved. For example, controller 1002 may be configured to interpret instructions and determine control signals to be output to other components of processor 1000, such that processor 1000 supports various operations according to the examples described herein. Additionally or alternatively, controller 1002 may be configured to manage data flow within processor 1000. Controller 1002 may be configured to control data transfers between registers, arithmetic logic unit (ALU), and other functional units of processor 1000.

[0149] Memory 1004 may include one or more caches (e.g., memory located locally in or included therein in processor 1000, or other memory such as RAM, ROM, DRAM, SDRAM, SRAM, MRAM, flash memory, etc.). In some embodiments, memory 1004 may reside within or on the processor chipset (e.g., locally in processor 1000). In some other embodiments, memory 1004 may reside outside the processor chipset (e.g., remotely from processor 1000).

[0150] Memory 1004 may store computer-readable, computer-executable code, including instructions that, when executed by processor 1000, cause processor 1000 to perform the various functions described herein. This code may be stored in a non-transitory computer-readable medium such as system memory or another type of memory. Controller 1002 and / or processor 1000 may be configured to execute the computer-readable instructions stored in memory 1004 to cause processor 1000 to perform various functions. For example, processor 1000 and / or controller 1002 may be coupled to or coupled to memory 1004, and processor 1000, controller 1002, and memory 1004 may be configured to perform the various functions described herein. In some examples, processor 1000 may include multiple processors, and memory 1004 may include multiple memories. One or more of the multiple processors may be coupled to one or more of the multiple memories, and they may be configured individually or collectively to perform the various functions described herein.

[0151] One or more ALUs 1006 may be configured to support various operations according to the examples described herein. In some implementations, one or more ALUs 1006 may reside within or on a processor chipset (e.g., processor 1000). In some other implementations, one or more ALUs 1006 may reside outside the processor chipset (e.g., processor 1000). One or more ALUs 1006 may perform one or more computations on data, such as addition, subtraction, multiplication, and division. For example, one or more ALUs 1006 may receive input operands and an opcode, the opcode determining the operation to be performed. One or more ALUs 1006 may be configured with various logic and arithmetic circuitry, including adders, subtractors, shifters, and logic gates, to process and manipulate data according to the operation. Alternatively, one or more ALU 1006 may support logical operations such as AND, OR, XOR, NOR, and NAND, thereby enabling one or more ALU 1006 to handle conditional operations, comparisons, and bitwise operations.

[0152] Processor 1000 can support wireless communication according to the examples disclosed herein. Processor 1000 can perform the functions of BEF 604 described herein. That is, processor 1000 can be configured or operable to support components for: obtaining a request message indicating a requirement to protect the integrity of control plane operations in a wireless communication network using distributed ledger technology (DLT); obtaining a policy based on the request message, the policy defining a predefined action to be performed when a triggering event associated with the wireless communication network is detected, the predefined action including the control plane operation; identifying multiple nodes participating in the control plane operation based on the request message, the multiple nodes being coupled to the DLT network; and outputting a policy for transmission to the multiple nodes.

[0153] Processor 1000 can perform the functions of Oracle 610 described herein. Specifically, processor 1000 can be configured or operable to support components for: obtaining at least one configuration message including: (i) a policy defining predefined actions to be performed by nodes coupled to a distributed ledger technology (DLT) network when a triggering event is detected in a wireless communication network, the predefined actions including control plane operations in the wireless communication network; and (ii) an identifier for each of a plurality of nodes participating in control plane operations in the wireless communication network, the plurality of nodes coupled to the DLT network; and registering an API at an application programming interface (API) registry that enables network entities to receive data from one or more nodes outside the DLT network for transmitting data to nodes coupled to the DLT network to detect triggering events.

[0154] Processor 1000 can perform the functions of a blockchain-enabled node as described herein. Specifically, processor 1000 can be configured or operable to support components for: detecting triggering events associated with a wireless communication network; executing a policy to determine a predefined action to be performed based on the triggering event, the predefined action including control plane operations in the wireless communication network; outputting transaction information for transmission to one or more nodes coupled to the DLT network, the transaction information identifying the predefined action; and performing the predefined action in response to the transaction information being submitted to a distributed ledger maintained at the network entity and the one or more nodes.

[0155] Figure 11An example of an NE 1100 according to various aspects of this disclosure is shown. The NE 1100 may include a processor 1102, a memory 1104, a controller 1106, and a transceiver 1108. The processor 1102, memory 1104, controller 1106, or transceiver 1108, various combinations thereof, or various components thereof may be examples of means for performing various aspects of this disclosure as described herein. These components may be coupled via one or more interfaces (e.g., operatively, communicatively, functionally, electronically, electrically).

[0156] Processor 1102, memory 1104, controller 1106, or transceiver 1108, or various combinations thereof, may be implemented in hardware (e.g., circuitry). The hardware may include processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), or other programmable logic devices, or any combination thereof, configured or otherwise supporting means for performing the functions described in this disclosure.

[0157] Processor 1102 may include intelligent hardware devices (e.g., a general-purpose processor, DSP, CPU, ASIC, FPGA, or any combination thereof). In some embodiments, processor 1102 may be configured to operate memory 1104. In some other embodiments, memory 1104 may be integrated into processor 1102. Processor 1102 may be configured to execute computer-readable instructions stored in memory 1104 to cause NE 1100 to perform various functions of this disclosure.

[0158] Memory 1104 may include volatile or non-volatile memory. Memory 1104 may store computer-readable, computer-executable code, including instructions that, when executed by processor 1102, cause NE 1100 to perform the various functions described herein. This code may be stored in a non-transitory computer-readable medium such as memory 1104 or another type of memory. Computer-readable media include both non-transitory computer storage media and communication media, including any medium that facilitates the transfer of a computer program from one place to another. Non-transitory storage media may be any available medium that can be accessed by a general-purpose computer or a special-purpose computer.

[0159] In some implementations, processor 1102 and memory 1104 coupled to processor 1102 may be configured such that NE 1100 performs one or more of the functions described herein (e.g., processor 1102 executes instructions stored in memory 1104). For example, processor 1102 may support wireless communication at NE 1100 according to examples disclosed herein. NE 1100 may perform the functions of BEF 604 disclosed herein. That is, NE 1100 may be configured to support components for: receiving a request message indicating a requirement to protect the integrity of control plane operations in a wireless communication network using distributed ledger technology (DLT); obtaining a policy based on the request message that defines a predefined action to be performed upon detection of a triggering event associated with the wireless communication network, the predefined action including the control plane operation; identifying multiple nodes participating in the control plane operation, the multiple nodes coupled to the DLT network, based on the request message; and outputting a policy for transmission to the multiple nodes.

[0160] The NE 1100 can perform the functions of Oracle 610 described herein. Specifically, the NE 1100 can be configured to support components for: obtaining at least one configuration message including: (i) a policy defining predefined actions to be performed by nodes coupled to a distributed ledger technology (DLT) network when a triggering event is detected in a wireless communication network, the predefined actions including control plane operations in the wireless communication network; and (ii) an identifier for each of a plurality of nodes participating in control plane operations in the wireless communication network, the plurality of nodes coupled to the DLT network; and registering an API at an application programming interface (API) registry that enables network entities to receive data from one or more nodes outside the DLT network for transmitting data to nodes coupled to the DLT network to detect triggering events.

[0161] The NE 1100 can perform the functions of a blockchain-enabled node as described herein. Specifically, the NE 1100 can be configured to support components for: detecting triggering events associated with a wireless communication network; executing a policy to determine a predefined action to be performed based on the triggering event, the predefined action including control plane operations within the wireless communication network; sending transaction information to one or more nodes coupled to the DLT network, the transaction information identifying the predefined action; and executing the predefined action in response to the transaction information being committed to a distributed ledger maintained at network entities and one or more nodes.

[0162] In some implementations, NE 1100 may correspond to near-RT RIC 204. In some implementations, NE 1100 may correspond to MEC host network entity 400.

[0163] Controller 1106 can manage the input and output signals of NE 1100. Controller 1106 can also manage peripheral devices not integrated into NE 1100. In some embodiments, controller 1106 can utilize an operating system such as iOS®, ANDROID®, WINDOWS®, or other operating systems. In some embodiments, controller 1106 can be implemented as part of processor 1102.

[0164] In some embodiments, NE 1100 may include at least one transceiver 1108. In other embodiments, NE 1100 may have more than one transceiver 1108. Transceiver 1108 may represent a wireless transceiver. Transceiver 1108 may include one or more receiver chains 1110, one or more transmitter chains 1112, or a combination thereof.

[0165] Receiver chain 1110 can be configured to receive signals (e.g., control information, data, packets) via a wireless medium. For example, receiver chain 1110 may include one or more antennas for receiving signals over the air or via a wireless medium. Receiver chain 1110 may include at least one amplifier (e.g., a low-noise amplifier (LNA)) configured to amplify the received signal. Receiver chain 1110 may include at least one demodulator configured to demodulate the received signal and obtain the transmitted data by reversing the modulation technique applied during signal transmission. Receiver chain 1110 may include at least one decoder for decoding the demodulated signal to receive the transmitted data.

[0166] Transmitter chain 1112 can be configured to generate and transmit signals (e.g., control information, data, packets). Transmitter chain 1112 may include at least one modulator for modulating data onto a carrier signal in preparation for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques, such as amplitude modulation (AM), frequency modulation (FM), or digital modulation schemes like phase shift keying (PSK) or quadrature amplitude modulation (QAM). Transmitter chain 1112 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over a wireless medium. Transmitter chain 1112 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0167] Figure 12 A flowchart of method 1200 according to various aspects of this disclosure is shown. The operation of this method can be implemented by an NE as described herein. In some embodiments, the NE can execute a set of instructions to control the functional elements of the NE to perform the described functions. The operation of method 1200 can be implemented by an NE performing the functions of BEF 604 described herein.

[0168] At step 1202, the method may include receiving a request message indicating a requirement to protect the operational integrity of the control plane in a wireless communication network using distributed ledger technology (DLT). The operation of step 1202 may be performed according to examples as described herein. In some embodiments, aspects of the operation of step 1202 may be derived from references... Figure 11 The NE described is used to execute.

[0169] At step 1204, the method may include obtaining a strategy based on the request message, the strategy defining a predefined action to be performed upon detection of a triggering event associated with the wireless communication network, the predefined action including control plane operations. The operation of step 1204 may be performed according to examples as described herein. In some embodiments, aspects of the operation of step 1204 may be derived from references... Figure 11 The NE described is used to execute.

[0170] At step 1206, the method may include multiple nodes participating in control plane operations based on the request message identifier, these multiple nodes being coupled to the DLT network. The operation of step 1206 may be performed according to the examples described herein. In some embodiments, aspects of the operation of step 1206 may be derived from references... Figure 11 The NE described is used to execute.

[0171] At step 1208, the method may include sending a policy to the plurality of nodes. The operation of step 1208 may be performed according to the examples described herein. In some implementations, aspects of the operation of step 1208 may be derived from references... Figure 11 The NE described is used to execute.

[0172] It should be noted that the method 1200 described herein describes one possible implementation, and the operations and steps may be rearranged or otherwise modified, and other implementations are possible.

[0173] Figure 13A flowchart of method 1300 according to various aspects of this disclosure is shown. The operation of this method can be implemented by a NE as described herein. In some embodiments, the NE can execute a set of instructions to control the functional elements of the NE to perform the described functions. The operation of method 1300 can be implemented by an NE performing the functions of Oracle 610 described herein.

[0174] At step 1302, the method may include receiving at least one configuration message, the at least one configuration message including: (i) a policy that defines a predefined action to be performed by a node coupled to a distributed ledger technology (DLT) network when a triggering event is detected in the wireless communication network, the predefined action including control plane operations in the wireless communication network; and (ii) an identifier for each of a plurality of nodes participating in control plane operations in the wireless communication network, the plurality of nodes being coupled to the DLT network. The operation of step 1302 may be performed according to examples as described herein. In some embodiments, aspects of the operation of step 1302 may be provided by reference to [reference needed]. Figure 11 The NE described is used to execute.

[0175] At step 1304, the method may include registering an API at an application programming interface (API) registry that enables the network entity to receive data from one or more nodes outside the DLT network for transmitting the data to nodes coupled to the DLT network to detect triggering events. The operation of step 1304 may be performed according to examples as described herein. In some implementations, aspects of the operation of step 1304 may be derived from references... Figure 11 The NE described is used to execute.

[0176] It should be noted that the method 1300 described herein describes one possible implementation, and the operations and steps may be rearranged or otherwise modified, and other implementations are possible.

[0177] Figure 14 A flowchart of method 1400 according to various aspects of this disclosure is shown. The operation of this method can be implemented by an NE as described herein. In some embodiments, the NE can execute a set of instructions to control the functional elements of the NE to perform the described functions. The operation of method 1400 can be implemented by an NE performing the functions of a node enabling a blockchain as described herein.

[0178] In step 1402, the method may include detecting a triggering event associated with a wireless communication network. Step 1402 may be performed according to examples as described herein. In some embodiments, aspects of the operation of step 1402 may be derived from references... Figure 11 The NE described is used to execute.

[0179] At step 1404, the method may include an execution strategy to determine a predefined action to be performed based on the triggering event, the predefined action including control plane operation in a wireless communication network. The operation of step 1404 may be performed according to examples as described herein. In some embodiments, aspects of the operation of step 1404 may be determined by reference to... Figure 11 The NE described is used to execute.

[0180] At step 1406, the method may include sending transaction information to one or more nodes coupled to the DLT network, the transaction information identifying the predefined action. Step 1406 can be performed according to examples as described herein. In some implementations, aspects of the operation of step 1406 may be derived from references... Figure 11 The NE described is used to execute.

[0181] At step 1408, the method may include performing the predefined action in response to the transaction information being committed to a distributed ledger maintained at the network entity and one or more nodes. The operation of step 1408 can be performed according to the examples described herein. In some implementations, aspects of the operation of step 1408 may be as described in the references... Figure 11 The NE described is used to execute.

[0182] It should be noted that the method 1400 described herein describes one possible implementation, and the operations and steps may be rearranged or otherwise modified, and other implementations are possible.

[0183] The description provided herein is intended to enable those skilled in the art to implement or use this disclosure. Various modifications to this disclosure will be apparent to those skilled in the art, and the general principles defined herein can be applied to other variations without departing from the scope of this disclosure. Therefore, this disclosure is not limited to the examples and designs described herein, but should be given the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A network entity storing code including instructions that are executable to cause the network entity to: Detect triggering events associated with wireless communication networks; An execution strategy is adopted to determine a predefined action to be performed based on the triggering event, the predefined action including control plane operations in the wireless communication network; Send transaction information to one or more nodes coupled to the DLT network, the transaction information identifying the predefined action; as well as The predefined action is performed in response to the transaction information being submitted to the distributed ledger maintained at the network entity and the one or more nodes.

2. The network entity of claim 1, wherein the instructions are further executable to cause the network entity to: Receive measurement data associated with the wireless communication network; and The triggering event is detected based on the measurement data.

3. The network entity of claim 2, wherein the instructions are further executable to cause the network entity to receive the measurement data from one or more nodes outside the DLT network via a gateway node.

4. The network entity of claim 1, wherein the triggering event includes receiving a request for a service to be provided by the network entity to the wireless communication network.

5. The network entity of claim 3, wherein the predefined action includes providing the requested service to one or more nodes outside the DLT network via a gateway node.

6. The network entity according to any one of the preceding claims, wherein the transaction information includes one or more of the following: (i) a transaction identifier, (ii) a control plane identifier, (iii) an identifier of the predefined action, (iv) the cause of the triggering event, (v) an identifier of each of one or more nodes coupled to the DLT network involved in the control plane operation, (vi) one or more constraints for fulfilling the control plane operation, or (vii) an identifier of each of one or more nodes outside the DLT network involved in the control plane operation.

7. The network entity according to any one of the preceding claims, wherein the distributed ledger includes a data structure comprising a plurality of linked data blocks, and the instructions are also executable to cause the network entity to perform the predefined action in response to a data block including the transaction information being added to the data structure.

8. The network entity according to any one of the preceding claims, wherein the strategy is a smart contract.

9. The network entity according to any one of the preceding claims, wherein the network entity is a near real-time radio access network (RAN) intelligent controller, or a network entity configured to communicate with a near real-time RAN intelligent controller.

10. The network entity according to any one of claims 1 to 8, wherein the network entity is a non-real-time radio access network (RAN) intelligent controller.

11. The network entity according to any one of claims 1 to 8, wherein the network entity is a multi-access edge computing (MEC) host.

12. The network entity according to any one of claims 1 to 8, wherein the network entity is a base station in the wireless communication network.

13. A processor for wireless communication, comprising: At least one controller, coupled to at least one memory, and configured to cause the processor to: Detect triggering events associated with wireless communication networks; An execution strategy is adopted to determine a predefined action to be performed based on the triggering event, the predefined action including control plane operations in the wireless communication network; Output transaction information for transmission to one or more nodes coupled to the DLT network, the transaction information identifying the predefined action; as well as The predefined action is performed in response to the transaction information being submitted to the distributed ledger maintained at the network entity and the one or more nodes.

14. A method performed by a network entity, the method comprising: Detect triggering events associated with wireless communication networks; An execution strategy is adopted to determine a predefined action to be performed based on the triggering event, the predefined action including control plane operations in the wireless communication network; Send transaction information to one or more nodes coupled to the DLT network, the transaction information identifying the predefined action; as well as The predefined action is performed in response to the transaction information being submitted to the distributed ledger maintained at the network entity and the one or more nodes.

15. The method of claim 14, wherein the method comprises: Receive measurement data associated with the wireless communication network; as well as The measured data is used to detect the triggered event.

16. The method of claim 15, wherein the method includes receiving the measurement data from one or more nodes outside the DLT network via a gateway node.

17. The method of claim 14, wherein the triggering event includes receiving a request for a service to be provided by the network entity to the wireless communication network.

18. The method of claim 17, wherein the predefined action includes providing the requested service to one or more nodes outside the DLT network via a gateway node.

19. The method according to any one of claims 14 to 18, wherein the transaction information includes one or more of the following: (i) a transaction identifier, (ii) a control plane identifier, (iii) an identifier of the predefined action, (iv) the cause of the triggering event, (v) an identifier of each of one or more nodes coupled to the DLT network involved in the control plane operation, (vi) one or more constraints for fulfilling the control plane operation, or (vii) an identifier of each of one or more nodes outside the DLT network involved in the control plane operation.

Images