Distributed autonomic identity for network function virtualization

Abstract

Various systems and methods are disclosed for distributing network service orchestration using blockchain technology. Bids for network service orchestration using NFV delivery are published using a DSFC contract blockchain. Devices, DSFC contracts, and initiators of requests for network services are identified using a self-sovereign identity blockchain. A device determines that it is to orchestrate a network service based on the DSFC contract blockchain and identifies at least one entity to provide the network service from a DWH contract blockchain containing DWH contract bids by entities of the network service. The entities and DWH contracts are identified using a self-sovereign identity blockchain. The device ensures that the at least one entity performs the DWH contract according to the DWH contract and provides remuneration upon fulfillment.

Description

[0001] Priority requirements

[0002] This patent application claims the benefit of priority to U.S. Provisional Patent Application No. 62 / 625,177, filed February 1, 2018, which is incorporated herein by reference in its entirety. Technical Field

[0003] The embodiments described herein generally relate to radio access networks. Some embodiments relate to network function virtualization (NFV) in cellular networks, including 3GPP LTE and LTE-A (LTE-A) networks, as well as 4G and 5G / NG networks. Some embodiments relate to security authentication in networks using NFV. Background Technology

[0004] The use of 3GPP LTE systems (including LTE and Advanced LTE) has increased due to the growing types of user equipment (UEs) using network resources and the increasing data volume and bandwidth consumed by various applications running on these UEs, such as video streaming. Therefore, LTE systems are continuously evolving alongside the next-generation wireless communication system, 5G, to improve access to information and data sharing. 5G systems aim to provide a unified network capable of accommodating the vastly different and sometimes conflicting performance dimensions and services driven by diverse services and applications, while maintaining compatibility with legacy UEs and applications.

[0005] With the significant increase in the number and diversity of communication devices, the corresponding network environment (including routers, switches, bridges, gateways, firewalls, and load balancers) has become increasingly complex, especially with the advent of 5G systems. To further complicate the various services provided by network devices, many physical implementations of these devices are appropriate but may not be able to incorporate new or adapted physical components to compensate for different network conditions. This has led to the development of Network Functions Virtualization (NFV), which provides a virtualized environment capable of delivering any network function or service that can be delivered as a software application (called a Virtual Network Function (VNF)) on general-purpose computing systems in data centers. The use of NFV can provide flexibility in configuring network components, enable dynamic network optimization, and allow for faster adaptation to new technologies.

[0006] Existing service providers have begun adopting NFV as part of their Function as a Service (FaaS) models on general-purpose cloud deployments. Beyond its use by existing service providers, NFV can reduce barriers to entry into the telecommunications market, which previously restricted new entrants to the technology. NFV can potentially open up functions such as supply chain, revenue generation, and procurement. In other words, telecommunications systems evolve using NFV, which can address, manage, and implement revenue generation for the components of the Multi-Source Distributed Service Function Chain (DSFC) that make up the VNF used to deliver NFV services. A unique aspect of NFV services and functions is that, unlike traditional telecommunications services and functions, NFV services and functions can be modified (created and deleted) based on demand.

[0007] The emergence of 5G systems complicates matters, as existing telecommunications system deployments were designed for closed or highly controlled systems. The evolving dynamic and distributed service delivery models of 5G / edge make it impossible for existing deployments to scale, or even function, within the hyper-distributed service delivery models decomposed by NFV. Attached Figure Description

[0008] In the accompanying drawings (which are not necessarily drawn to scale), the same numbers may describe similar components in different views. The same numbers with different letter suffixes may represent different instances of similar components. Some embodiments are shown by way of example, not as a limiting map, in the accompanying drawings, wherein:

[0009] Figure 1 The illustration shows 4G and 5G systems implemented via network function virtualization, based on examples.

[0010] Figure 2 This illustrates an NFV network management architecture according to some embodiments.

[0011] Figure 3 This illustrates a system for implementing network function virtualization, based on an example.

[0012] Figure 4 This illustrates a blockchain model for a distributed system that enables autonomous identity in a network functions virtualization environment, based on an example.

[0013] Figure 5 This illustrates the evolutionary context of a telecommunications approach toward network function virtualization, based on an example.

[0014] Figure 6 The example illustrates various types of descriptors for network function virtualization in a distributed system for autonomous identity.

[0015] Figure 7 This illustrates distributed and automated network service delivery for network function virtualization services, based on an example.

[0016] Figure 8 This illustrates a blockchain-based identity management process based on an example.

[0017] Figure 9 This illustrates how a blockchain system is implemented based on an example;

[0018] Figure 10 It is a block diagram of an example of components that may exist in a processing device, based on the example;

[0019] Figure 11 This is a block diagram illustrating an example of a machine on which one or more embodiments may be implemented; and

[0020] Figure 12 This is a block diagram illustrating an example delivery of a telecommunications service based on an example. Detailed Implementation

[0021] The following description discloses methods, configurations, and related equipment for providing autonomous identity and processing operations in NFV and 5G / edge systems through the use of blockchain technology and similar identity management tools. Securing the use of individual identities through blockchain allows for the secure management of NFV functions throughout their management lifecycle. Embodiments of blockchain-based systems are disclosed, providing an underlying infrastructure on which NFV or other telecommunications services and network functions can be dynamically created, delivered, and managed. The method enables fine-grained management, including supply chain management at each level of the management model. For example, the embodiments disclosed herein include mechanisms for managing identities and components at each level of telecommunications services, infrastructure, and resources, enabling NFV to operate as an open business model where any entity can play any role.

[0022] As described herein, the following technologies are applicable to various implementations and recommendations for NFV management, such as those published by the NFV ETSI Industry Specification Group (ISG) and the NFV Identity and Security Management Specifications published by the ETSI Permitted Distributed Ledger (PDL) ISG. A distributed, dynamic service delivery model is required in 5G systems, and the following disclosures provide technologies for managing components of this new infrastructure. Automated, autonomous contract models can help address many aspects of security, authentication, resource usage, and other technical issues in NFV telecommunications deployments. The applicability of the following technologies to other telecommunications service deployments and systems will also become apparent.

[0023] In this example, the NFV provider community uses blockchain (distributed ledger) technology to become fully distributed, where NFV orchestration, historically centralized by a management and network orchestration (MANO) system, is fairly distributed. As disclosed herein, certain information stored on the blockchain exists as a shared database or ledger. The database or ledger maintains a constantly growing list of data records or transactions (such as those used for NFV). NFV nodes or servers maintain blocks, and each node can see the transaction data stored in the blocks at creation time. Therefore, the database can form immutable and irreversible records. Postings in the ledger may not be modified or tampered with—not even by the database operator. The distributed nature of the network means that computer servers must reach consensus, allowing transactions to occur between unknown parties. Conflicting or duplicate transactions are not written to the dataset, and transactions occur automatically.

[0024] In some embodiments, the NFV module can be implemented through one or more blockchain implementations. In examples, these blockchain implementations may include: a) a sovereign identity blockchain; b) a distributed service function (SF) chain contract blockchain; c) a distributed service function chain (DSFC) workload hosted on a blockchain; and d) a DSFC workload hosted (DWH) operations blockchain. Other uses for such blockchains will also be apparent. The blockchain may be permissionless or permissioned, for example, the latter based on the Hyperledger Framework or variants of Ethereum.

[0025] Self-sovereign identity typically encompasses the following concepts: individuals and businesses can store their identity data on their own devices and provide this data to other devices / systems for verification, without relying on a central repository for identity data. Therefore, a self-sovereign identity blockchain ensures that identifiers used throughout the DSFC contract and operational phases are unique, identity ownership is retained by the requesting entity, and identity disputes can be resolved without the need for a central authority.

[0026] The SF Chain is an ordered sequence of various service functions that provide services, such as packet data network gateways, firewalls, and load balancers. The distributed SF Chain contract blockchain allows any NFV provider to issue DSFC contracts: other NFV groups request (bid) to provide some or all of the contract components. The DSFC blockchain reduces or eliminates the possibility of tampering with the contract bidding process, thus ensuring its fairness.

[0027] In some embodiments, a DSFC Workload Hosting (DWH) contract may be provided in response to a DSFC contract. The DSFC contract may provide details of the DWH contract. The DWH contract may be publicly tendered to infrastructure providers capable of hosting the DSFC contract. Similar to the DSFC blockchain, the DWH blockchain ensures a fair contract tendering process.

[0028] DWH contracts can lead to the execution of various DWH operations. DWH operations can be recorded in the associated blockchain. The DWH operation blockchain can record, for example, custodian chains, regulatory compliance, Service Level Agreement (SLA) compliance, Quality of Service (QoS) compliance, and security compliance.

[0029] Therefore, the disclosed embodiments use one or more blockchains or other ledgers as a distributed mechanism to manage contracts, operations, interactions, and other aspects of network functions and functionality. In the examples, such distributed contracts define the requirements, functions, controls, and parameters for NFV service operations. In contrast, current telecommunications system architectures rely on a central orchestration entity that maintains customer relationships and “subcontracts” portions of the workload in the form of virtualized network functions. The techniques disclosed herein allow for the removal of the central entity, replacing it with service contract orchestrator functionality via a blockchain that is possessable by any participant in the NFV ecosystem. Some of the disclosed blockchain data technologies can also be integrated with existing telecommunications system approaches (e.g., to allow new devices or participants with unique identities to be added and integrated into telecommunications services and functions).

[0030] Figure 1 This illustrates a 4G and 5G system implemented via network function virtualization, based on an example. System 100 includes both 4G and 5G network functions. The 4G core network (also known as the Evolved Packet Core - EPC) contains protocols and reference points defined for each entity, such as the Mobility Management Entity (MME) 122, the Serving Gateway (S-GW) 124, and the Packet Gateway (P-GW) 126, which is divided into control and user plane functions. Figure 1 The 5G architecture shown includes multiple network functions (NFs) and reference points for connecting network functions. Network functions can be implemented as discrete network elements on dedicated hardware, software instances running on dedicated hardware, or virtualized functions instantiated on appropriate platforms (e.g., dedicated hardware or cloud infrastructure).

[0031] In 5G networks, the control plane and user plane can be separate, allowing for independent scaling and distribution of resources for each plane. UE 102 can connect to the access network or random access network (RAN) 110 and / or can connect to 5G-RAN 130 (gNB) or Access and Mobility Functions (AMF) 142. The RAN can be an eNB or a general non-3GPP access point (such as a Wi-Fi access point). In addition to AMF 142, the 5G core network may also include multiple network functions. These network functions may include User Plane Functions (UPF) 146, Session Management Functions (SMF) 144, Policy Control Functions (PCF) 132, Application Functions (AF) 148, Authentication Server Functions (AUSF) 152, and User Data Management (UDM) 128. Each component communicates via... Figure 1 The 5G reference point connection is shown.

[0032] AMF 142 can provide UE-based authentication, authorization, mobility management, etc. AMF 142 can be independent of the access technology. SMF 144 is responsible for session management and IP address allocation to UE 102. SMF 144 can also select and control UPF 146 for data transmission. SMF 144 can be associated with a single session of UE 102 or multiple sessions of UE 102. That is, UE 102 can have multiple 5G sessions. Different SMFs can be assigned to each session. Using different SMFs allows for individual management of each session. As a result, the functionality of each session can be independent of each other. UPF 126 can connect to a data network with which UE 102 can communicate, allowing UE 102 to send uplink data to the data network or receive downlink data from the data network.

[0033] AF 148 can provide information about packet flows to PCF 132, which is responsible for policy control to support desired QoS. PCF 132 can set mobility and session management policies for UE 102. To this end, PCF 132 can use packet flow information to determine the appropriate policies for the correct operation of AMF 142 and SMF 144. AUSF 152 can store data used for UE authentication. UDM 128 can similarly store UE subscription data.

[0034] gNB 130 can be a standalone gNB or a non-standalone gNB, for example, operating in dual connectivity (DC) mode as a booster controlled by eNB 110 via the X2 interface. At least some functions of the EPC and 5G CN can be shared (or, separate components can be used for each of the combined components shown). eNB 110 can connect to the EPC's MME 122 via the S1 interface and to the EPC 120's SGW 124 via the S1-U interface. MME 122 can connect to HSS 128 via the S6a interface, while UDM connects to AMF 142 via the N8 interface. SGW 124 can connect to PGW 126 via the S5 interface (connected to the control plane PGW-C via S5-C and to the user plane PGW-U via S5-U). PGW 126 can be used as an IP anchor point for data over the Internet.

[0035] As described above, the 5G CN may include AMF 142, SMF 144, and UPF 146, etc. eNB 110 and gNB 130 can transmit data with the SGW 124 of EPC 120 and the UPF 146 of the 5G CN. If the N26 interface is supported by EPC 120, MME 122 and AMF 142 can be connected via the N26 interface to provide control information between them. In some embodiments, when gNB 130 is a standalone gNB, the 5G CN and EPC 120 can be connected via the N26 interface.

[0036] Figure 2 An NFV network management architecture according to some embodiments is illustrated. As shown, the NFV network management architecture 200 may include several elements (each element may contain physical and / or virtualized components), including NFV infrastructure (NFVI) 210, network element (NE) 290, virtual network function (VNF) 220, domain manager (DM) 230, element manager (EM) 232, network manager (NM) 242, and NFV management and orchestration (NFV-MANO) 280. The NFV-MANO 280, which may be replaced by multiple NFV-MANOs as indicated herein, may include a virtualization infrastructure manager (VIM) 270, a VNF manager (VNFM) 250, and a network function virtualization orchestrator (NFVO) 260. NM 242 may be included in an operations support system / service support system (OSS / BSS) 240, wherein DM 230 and NM 242 form a 3GPP management system 214.

[0037] The NFV network management architecture 200 can be implemented by, for example, a data center including one or more servers in the cloud. In some embodiments, the NFV network management architecture 200 may include one or more physical devices and / or one or more applications hosted on a distributed computing platform, cloud computing platform, centralized hardware system, servers, computing devices, and / or external network-to-network interface devices. In some cases, virtualized resource performance measurements may include, for example, latency, jitter, bandwidth, packet loss, node connectivity, computing, network and / or storage resources, billing, fault and / or security measurements. Specifically, the NE 290 may include physical network functions (PNFs), which include hardware such as processors, antennas, amplifiers, transmit and receive chains, and software. The VNF 220 may be instantiated in one or more servers. Each of the VNF 220, DM230, and NE 290 may include EM 222, 232, and 292.

[0038] The NFV Management and Orchestration (NFV-MANO) 280 can manage NFVI 210. NFV-MANO 280 can orchestrate the instantiation of network services and the allocation of resources used by VNFs 220. NFV-MANO 280, together with OSS / BSS 240, can be used by external entities to deliver various NFV service benefits. OSS / BSS 240 may include a collection of systems and management applications used by service providers to operate their businesses: management of customers, orders, products and revenue (e.g., payment or accounting transactions) and telecommunications network components and support processes (including network component configuration, network service provisioning, and fault handling). NFV-MANO 280 can create or terminate VNFs 220, increase or decrease VNF capacity, or update or upgrade VNF software and / or configuration. NFV-MANO 280 may include a Virtualization Infrastructure Manager (VIM) 270, a VNF Manager (VNFM) 250, and an NFV Orchestrator (NFVO) 260. The NFV-MANO 280 can access various data repositories, including network services, available VNFs, NFV instances used to determine resource allocation, and NFVI resources.

[0039] VIM 270 can control and manage NFVI resources via an NF-Vi reference point within the infrastructure subdomain. VIM 270 can further collect performance measurements and events, forwarding them to VNFM 250 via Vi-VNFM and to NFVO 260 via Or-Vi reference point. NFVO 260 can manage new VNFs and other network services, including lifecycle management of various network services, such as VNF instance management, global resource management, authentication and authorization of NFVI resource requests, and policy management for various network services. NFVO 260 can orchestrate VNFs 220 as part of network services, enabling more complex functions, including federated instantiation and configuration, configuring required connections between different VNFs 220, and managing dynamic configuration changes. NFVO 260 can provide this orchestration to NM 242 via the OS-Ma-NFVO reference point. VNFM 250 can orchestrate NFVI resources via VIM 270 and provide overall coordination and adaptation for configuration and event reporting between VIM 270 and EM and NM. The former may involve discovering available services, managing virtualization resource availability / allocation / release, and providing virtualization resource failure / performance management. The latter may involve lifecycle management, which may include instantiating VNFs, scaling and updating VNF instances, terminating network services, and releasing service NFVI resources to the NFVI resource pool for use by other services.

[0040] The VNFM 250 can manage the lifecycle of VNF 220s via the Ve-VNFM-VNF reference point and can interface with EM 222 and 232 via the Ve-VNFM-EM reference point. Management of a single VNF 220 can be assigned to the VNFM 250, or management of multiple VNF 220s of the same or different types. Therefore, although in Figure 2 Only one VNFM 250 is shown here. Different VNFM 250s can be associated with different VNF ​​220s for performance measurement and other responsibilities. VNFM 250 can provide several VNF functions, including instantiation (and configuration—if required by the VNF deployment template), software updates / upgrades, modifications, scaling out / in and up / down, collection of NFVI performance measurement results and fault / event information, and association of events / faults, repairs, termination, lifecycle management change notifications, integrity management, and event reporting related to the VNF instance.

[0041] The VIM 270 is responsible for controlling and managing NFVI compute, storage, and networking resources, typically within an operator's infrastructure domain. The VIM 270 may be dedicated to handling a specific type of NFVI resource (e.g., compute-only, storage-only, networking-only), or may be able to manage multiple types of NFVI resources. Among other things, the VIM 270 can coordinate the allocation / upgrade / release / reclaim of NFVI resources (including optimization of such resource usage), manage the association between virtualized resources and physical compute, storage, and networking resources, and manage repository inventory information related to NFVI hardware resources (compute, storage, networking) and software resources (e.g., hypervisors), as well as the discovery of the functionality and characteristics of such resources (e.g., related to usage optimization).

[0042] NFVI 210 itself may contain a variety of virtualized and non-virtualized resources. These may include multiple virtual machines (VMs) that can provide computing power (CPU), one or more storage devices that can provide storage at the block or file system level, and one or more networking elements that may include networks, subnets, ports, addresses, links, and forwarding rules to ensure connectivity within VNFs and between VNFs.

[0043] Each VNF 220 can provide network functionality decoupled from the infrastructure resources (computing resources, networking resources, memory) used to provide network functions. Although not shown, a VNF 220 can be linked with other VNF 220s and / or other physical network functions to provide network services. Virtualized resources can provide desired resources to a VNF 220. Resource allocation in NFVI 210 can simultaneously meet many requirements and constraints, such as low-latency or high-bandwidth links to other communication endpoints.

[0044] Similar to the NE 290, the VNF 220 can be managed by one or more EMs 222, 232, and 292. Depending on the instance, the EM can provide management functions for virtual or physical network elements. The EM can manage individual network elements and subnet network elements, and can include relationships between network elements. For example, the EM 222 of the VNF 220 can be responsible for configuring the network functions provided by the VNF 220, managing faults in the network functions provided by the VNF 220, resolving the use of VNF functions, and collecting performance measurement results of the functions provided by the VNF 220.

[0045] The NM 242 of the OSS / BSS 240 can manage EM 222, 232, and 292 (whether in VNF 220 or NE 290) via the Itf-N reference point. The NM 242 can provide network management functions primarily supported by the EM 232, but can also involve direct access to network elements. The NM 242 can connect and disconnect the VNF external interface from the physical network function interface upon request from the NFVO 260.

[0046] As described above, the system components can be connected through different reference points. Reference points between NFV-MANO 280 and system function blocks may include Os-Ma-NFVO between NM 242 and NFVO 260, Ve-VNFM-EM between EM 222 and EM 232 and VNFM 250, Ve-VNFM-VNF between VNF 220 and VNFM 250, Nf-Vi between NFVI 210 and VIM 270, Or-VNFM between NFVO 260 and VNFM 250, Or-Vi between NFVO 260 and VIM 270, and Vi-VNFM between VIM 270 and VNFM 250. The Or-Vi interface implements the VNF software image management interface, as well as interfaces for managing virtualization resources, their directories, performance, and faults at the Or-Vi reference point. The Or-Vnfm interface implements the virtualization resource management interface at the Or-Vnfm reference point. The Ve-Vnfm interface enables virtualization resource performance / fault management at the Ve-Vnfm reference point.

[0047] Figure 3 An example of a system for implementing network function virtualization is shown. System 300 provides... Figure 2 The system shown is an alternative view. In some embodiments, only software mechanisms are used. It will be understood that system 300 is provided as an example illustration of the capabilities and forms that NFV deployment can take, and that this disclosure can be used with many variations on the structure and functionality of NFV systems.

[0048] The system 300 shown includes NFV infrastructure 302, orchestrator (NFVO) 304, OSS / Business Support System (BSS) 306, VNFM 308, VIM 310, and network analysis tools 312. Fewer or other components may be integrated into system 300.

[0049] NFV infrastructure 302 virtualizations can be linked together to create network node functions such as communication services. As shown in the figure, NFV infrastructure 302 includes VNFs 316A, 316B, 316C and 316D, switches / routers 318 and carrier infrastructure 320.

[0050] The VNF 316A-316D performs virtualization tasks that were previously performed by dedicated hardware. The VNF 316A-316D moves these operations, previously performed by dedicated hardware, to software instantiation. The VNF 316A-316D operates with the help of hardware and / or software programming of the host 322.

[0051] The switch / router 318 provides communication capabilities between platforms 326A-326B and / or VNFs 316A-316D. Switches can be used to connect computers or other network devices. Routers can be used to connect networks together, such as by connecting the network to the Internet. Routers typically manage data paths (e.g., requests, messages, or responses) provided to another network or between devices within a network.

[0052] Carrier infrastructure 320 may host other carriers’ VNFs and includes hosts 322 (e.g., operating system (OS), cloud OS and / or hypervisor), firmware interfaces 324 (e.g., Unified Scalable Firmware Interface (UEFI) or Basic Input / Output System (BIOS), multiple platforms 326A and 326B (e.g.), and interconnect circuit systems 328 (e.g., input / output (I / O) ports, network interface controllers (NICs), switches, host fabric interfaces (HFI), etc.).

[0053] Host 322 may include hardware or software for providing resources used by VNF 316A-316D to perform its operations. Host 322 may include an OS, cloud OS, hypervisor, etc., on which VNF 316A-316D can operate. Firmware interface 324 may include Unified Extensible Firmware Interface (UEFI), Basic Input / Output System (BIOS), etc. Firmware interface 324 defines the software interface between host 322 and firmware (e.g., VNF 316A-316D).

[0054] Platforms 326A-326B provide communication functions for devices connected to a communication network. Examples of user functions provided by platforms 326A-326B include voice sessions (such as Voice over Internet Protocol (VoIP), PTT sessions, and group communication sessions) and data services (such as internet access and social networking services), as well as operations to support voice and internet access. Platform 326A includes a memory 330 (same as platform 326B, but not shown to avoid obscuring the view of system 300). Platforms 326A-326B can be communicatively coupled via interconnect circuitry 328.

[0055] NFVO 304 performs resource and / or network service orchestration. NFVO 304 binds to functions provided by VNFs 316A-316D, such as for creating services in a previously distributed NFV environment. NFVO 304 helps ensure sufficient compute, storage, and / or other network resources are available for providing network services. NFVO 304 can authorize, coordinate, release, and manage the resources of VNFs 316A-316D within shared infrastructure 302.

[0056] In the example, OSS / BSS 306 is a computer system used by a telecommunications service provider to manage its network. OSS / BSS 306 can support network inventory, configuration, fault management, and / or service provisioning.

[0057] VNFM 308 works with NFVO 304 and VIM 310 to provide VNF functionality. VNFM 308 can instantiate, scale, update, and / or upgrade VNFs 316A-316D, and / or terminate VNFs 316A-316D. VNFM 308 can manage a single VNF or multiple VNFs. VNFM 308 maintains the virtualization resources supporting VNFs 316A-316D.

[0058] As shown in the figure, VIM 310 includes a software-defined networking (SDN) controller 314. VIM 310 controls and manages the compute, storage, and other network resources of infrastructure 302. VIM 310 can handle infrastructures within one or more infrastructures, such as infrastructure 302. VIM 310 can maintain a list of which virtual resources are allocated to which physical resources, manage security group policies (for access control), and manage repositories of NFV hardware and software resources, such as those used to help improve and optimize the use of system resources.

[0059] The SDN Controller 314 is used to manage applications such as flow control within a network. The SDN Controller 314 allows servers or other network resources to select the destination of switched packets, thus instructing the switches where to send packets. The SDN Controller 314 can take the control plane of network hardware and run it as software. The SDN Controller 314 can distribute monitoring policies.

[0060] Network analysis tool 312 can provide functions for analyzing telemetry data, such as NSM functionality. Network analysis tool 312 may include virtual EPC (vEPC), virtual customer premises equipment (vCPE) NFV analysis, data storage, network anomaly detection, and / or malware detection.

[0061] Network security surveillance (NSM) traffic is indicated by arrows 332, 334, 336, and 338. The embodiments discussed herein can “accelerate” the flow of this NSM traffic. As indicated by the combination of arrows 338 and 332, the SDN controller 314 of the VIM 310 can provide policies (e.g., security surveillance (SecMon) VNF) to the VNF 316D. Traffic provided to the VNF 316D can be securely terminated. The VNF 316D can monitor traffic (e.g., all traffic) on the switch / router 318 (as shown by arrow 332). The VNF 316D can apply the provided surveillance policies to the traffic. The VNF 316D provides the monitored traffic to the interconnect circuit system 328 based on the surveillance policies (as shown by arrow 334 or arrows 340 and 338). The interconnect circuit system 328 provides the monitored traffic to the network analysis tool 312, as shown by arrow 336. Network analysis tools 312 may include security and networking analysis systems, metadata collectors, network profile analysis, per-tenant monitoring systems and / or flow monitoring systems and / or on tenant monitoring systems.

[0062] Through functional virtualization and NFV operations management, the following technologies can be used to decentralize NFV infrastructure for providing network services. In the example, four blockchains (or at least one blockchain with four different operational functions) can be used to facilitate secure, fair, and reliable interaction among ecosystem participants.

[0063] Figure 4 A blockchain model for a distributed system used to implement autonomous identity in a network functions virtualization environment is illustrated. As described above, the DSFC (Distributed System Identity Controller) is used to capture details of the service type and quality of service desired by the DSFC contract initiator, and these details then associate the DSFC with a blockchain identity. The blockchain identity can be the DSFC contract blockchain. The DSFC contract may have a unique ID provided to the autonomous identity blockchain. In some embodiments, the DSFC may be captured in the form of an electronic contract.

[0064] DSFC contracts can be broadcast to vendors (or service provider entities), sent directly only to vendors who have opted to receive notifications of new DSFCs or DSFCs with a certain type / QoS, or published to allow any vendor to determine whether they wish to participate in a particular DSFC contract.

[0065] In some embodiments, any supplier maintaining an end-user customer base can initiate a bid for a DSFC contract by posting a bid to the DSFC blockchain. The bid may include a bidder ID, which is also provided to the sovereign identity blockchain and, if accepted, is ultimately associated with a DSFC contract ID. A DSFC contract can be bid on by a service provider entity capable of fulfilling at least some (or all) of the contract.

[0066] The DSFC contract initiator selects suppliers to fulfill the DSFC contract using the DSFC contract blockchain. This selection can be based on a pure reward measure for the suppliers, random selection among suppliers, selection based on the minimum number of suppliers fulfilling the DSFC contract, or selection according to a predetermined priority among suppliers, etc.

[0067] As shown, in some embodiments, DSFC electronic contracts, initiators, and bidders use a sovereign identity blockchain to issue identifiers to selected participants in a manner that allows for the establishment of a clear priority (in time) and a secure (non-deceptive) chain of evidence for potential disputes regarding service definitions, terms, conditions, providers, and anything requiring disambiguation identity.

[0068] The second phase of Distributed NFV is the DWH contract negotiation. During DWH contract negotiation, the previous phase contract (defining the services to be delivered) is matched with service delivery infrastructure that can meet the hosting requirements. The second round of DWH contracts is again open to all bidders, including those who may have participated in winning the DSFC contract. The contract initiator selects the team that meets the DWH contract as the final step in the blockchain electronic contract execution plan.

[0069] The third phase is DWH execution, where the DWH and DSFC contracts begin operation. During operation, telemetry data is collected, reporting actual service delivery experiences (e.g., discrepancies in SLA compliance). The service contract orchestrator verifies that the DWH contracts are being executed according to the contracts and verifies that participants receive corresponding payments from the customer's e-wallet.

[0070] Figure 5 This illustrates the evolving environment for telecommunications approaches, progressing towards Network Functions Virtualization (NFV). The NFV ecosystem is complex, comprising numerous components and subsystems. This ecosystem is on the path to a more open market, which for many years has been dominated by a few telecommunications companies.

[0071] Figure 5The diagram illustrates the three stages of NFV evolution. The first stage is essentially a closed system. The second stage allows a portion of the Network Functions Virtualization stack to be opened to VNF providers, who compete with each other to offer better "functions," but these "functions" are typically centrally orchestrated by the telecom provider.

[0072] Phase 3 also enables orchestration distribution. With this change, any NFV ecosystem participant can compete to offer any or all components and services.

[0073] Figure 6 This illustrates various types of descriptors used for network function virtualization in a distributed system with autonomous identity. In the example, a new NFV descriptor (added to the existing set of network service descriptors) is used to extend the contracts (e.g., NFV descriptors) of a fully distributed blockchain.

[0074] This list of descriptors illustrates example contract structures that can be implemented at each layer of the process. Current ETSI NFV standards (e.g., the ETSI NFV MANO001 specification) describe various existing descriptors (data structures containing parameters) for existing services. At least some of these descriptors can be delivered within the protocols defined in ETSI NFV and the extensions indicated herein.

[0075] Using the current configuration, additional contracts and extensions can be added to existing descriptors. These contracts can be published by the corresponding ecosystem partners, and these transactions will be added to various blockchains for sovereign identity issuance and full supply chain management (accounting, lifecycle management, horizontal scaling / horizontal scaling, etc.). New descriptors and extensions are related to orchestrators and resources. Specifically, as shown in the figure, an orchestrator descriptor may contain information on basic elements such as ID, supplier, service contract ID, financial terms, etc., a list of network services (NS1, NS2…NSn), SLA information (e.g., performance requirements, security requirements, bandwidth and latency requirements, transactions, etc.). Network service descriptors may include extensions to the orchestrator descriptor, including the orchestrator descriptor ID, SLA parameters, financial terms, etc. The new resource descriptor can indicate resource type (e.g., platform, rack, CPU, memory networking, storage), basic element information (e.g., ID, vendor, resource parameters (e.g., IA, ISA, SGX, QAT, RDT, KPT, MK-TME), monitoring / telemetry details, component ID, etc.), resource details (e.g., ID, parameters), network service ID, SLA parameters, financial terms, etc.

[0076] Figure 7This diagram illustrates the distributed and automated delivery of network services for Network Functions Virtualization (NFV) services. Specifically, it depicts the automated delivery of NFV / SDN / 5G services operating as all autonomous and independent subsystems within a fully distributed architecture comprising multiple layers.

[0077] In the example, service contracts can be initiated by the service provider, thus extending functionality to traditional telecommunications providers and newer internet service provider entities engaged in content and service delivery. These contracts are published to the blockchain and orchestrated by one or more distributed, autonomous orchestrators, which issue contracts that are subsequently served by the Network Service Orchestrator (NS-Orch). Similarly, network service contracts are also served by the resource orchestrator. At each level, contracts and delivery at the next level are handled by multiple blockchains (e.g., on...). Figure 4 (Management is done in the configuration of the identifier).

[0078] Figure 8 The diagram illustrates an example blockchain-based identity management process for identity creation, blockchain-based verification, and recording in the identity blockchain (e.g., for reference). Figure 4 (Identity blockchain as shown and discussed). In the example, the method may include:

[0079] 1. Create instances of services, service function chains, VNFs, FaaS, resources, hardware enclaves or virtual partitions, containers, or any other component instances.

[0080] 2. These instances create a self-generated identifier (e.g., a globally unique ID (GUID) or a random number), which, along with the instance's cryptographic hash, the initial configuration's cryptographic hash, and the identifier's cryptographic hash, is cryptographically hashed and submitted to the blockchain processing operation.

[0081] 3. Blockchain miners verify each operation, and in the case of an identifier, check if the same identity has not been previously submitted and accepted into the blockchain. In the event of a conflict, the operation will be restarted.

[0082] 4. Once accepted into the blockchain, the identity can be used for public purposes, including accounting, monitoring, performance tracking, SLA enforcement, and regulatory purposes such as lawful interception and data protection. Many more applications are also possible.

[0083] In the example, Figure 8This process can be applied to managing or tracking the entire lifecycle of an instance, including its creation, destruction, and usage. This is useful for scaling down and scaling up services based on dynamic demand. Instance configuration management includes tracking instance image updates and configuration updates (e.g., network hash tables, network policies, packet network routing updates, etc.). This configuration is bound to the instance's identity.

[0084] In the example, Figure 8 The process can also be applied to track resource utilization and loading, including platform and hardware / silicon components such as CPUs, virtual CPUs, memory (DIMMs, Intel 3DXP, etc.), storage, programmable and ASIC accelerators (deep learning, artificial intelligence (AI), field-programmable gate arrays (FPGAs), etc.), network accelerators (Intel Fast Auxiliary Encryption Accelerator, compression), and key protection and security (Intel Key Protection Technology, Software Protection Extensions, Multi-Key Total Memory Encryption). The process manages specific uses and time of use according to the methodological flow.

[0085] Figure 9 The diagram illustrates an example blockchain system implementation that can be used with currently disclosed technologies or similar methods. As understood, a blockchain is a distributed database (e.g., a distributed ledger) that maintains a constantly growing list of data records, which are hardened to resist tampering and modification. A blockchain consists of “blocks” that store data or data and programs. Each block stores individual “transactions” in batches between blockchain participants. Each block includes a timestamp and link information (typically a hash value) that links the current block to the previous block; this link information allows traversal of the blockchain (in either direction).

[0086] Blockchain transactions use a distributed hashing algorithm for integrity protection, which requires each transaction processor (e.g., a "miner") to accept the next block in the blockchain. Integrity is achieved through consensus among multiple miners, each with access to their own copy of the ledger. If a majority of miners agree on the contents of the ledger, those agreed-upon contents become the "truth" of the ledger; dissenting miners will accept the truth of the majority (otherwise, they would not function). Integrity is provable because an attacker would have to compromise with a majority of miners and modify their copy of the ledger, which is extremely difficult (if not impossible).

[0087] In the example, the blockchain implementation may involve use transactions performed between participants to implement zero-knowledge commitments and zero-knowledge proofs to verify knowledge using information written to the blockchain. Such techniques can allow for enhanced privacy of data written to the blockchain in relation to NFV operations (e.g., confidentiality of contract or network participant details). In the example, the zero-knowledge proof applied in this case includes the following steps: (1) committing secret data to the blockchain, and (2) using a cryptographic protocol to prove knowledge of the secret data.

[0088] As a specific example of a cryptographic protocol, in order to create proof of certain information (such as a known identifier of a new device) m New equipment can create The form of Pedersen's commitment, in which r It is a random value selected by the user. and This is a public parameter for the registrant. The commitment has been registered on the blockchain. At the time of registration, the blockchain signs the commitment. M Output As a signature, χ is the secret key (such as a chain anchor) of the blockchain (such as a semi-permissioned blockchain), which adds a layer of identity and privacy protection on top of the blockchain.

[0089] In the example, the zero-knowledge proof operation for knowledge or verification is as follows. Let... , ... This is a signature corresponding to the identifier that the device needs to prove to the new device owner. During registration, the device aggregates these signatures into a single signature. ,in It is the commitment value The signature. (Note—this can be just a signature if only a secret identifier needs to be proven. However, for registration that requires not only identity but also other attributes, this can be generalized to a set of attributes). These attributes are included as part of a zero-knowledge proof to prevent information leakage while satisfying registration requirements.

[0090] Then the new equipment calculates Users will The information is sent to the validator. Next, the new device and the validator will execute the following ZKPK protocol (where the Greek letters represent the amount of knowledge being proven, and all other parameters are sent to the validator):

[0091] After the validator accepts the promised zero-knowledge proof, it checks whether the authentication is successful: as well as

[0092] in These are common parameters. v It is the registrant's public key. e It is a bilinear mapping. If the previous step is successful, the validator will accept the ZKPK with the signed commitment.

[0093] As described above, each entity in an NFV and 5G system uses an identity. Entities themselves can be dynamic—instantiated, paused, and shut down on demand—or less dynamic, such as platforms, firmware, OS, storage, or networks. Entities can be software, firmware, hardware, or a combination thereof. Entities can be services: networks, orchestrations, enterprises, or sub-services. Entities can be procured from multiple suppliers using complex supply chains. Entities can be consumed by multiple consumers and accounted for in various ways. To adopt blockchain, in the first phase, the DSFC can capture the type and quality of services in electronic contracts. Service contracts can be created and published to the blockchain. In the second phase, DWH contracts, including those for VNFs, can be automatically bid on and matched based on demand. Contracts can be further processed by one or more distributed network service orchestrators and published to the blockchain. In the third phase, the DSFC and DWH contracts begin operation and can be authenticated via system telemetry. Contracts can be further processed by one or more distributed network service orchestrators and resource orchestrators and published to the blockchain. Contracts can be delivered, operated, managed, SLA-fulfilled, and accounted for via the blockchain. At least four separate blockchains, or one blockchain with four different operational functions, can be used to facilitate secure, fair, and reliable interactions among ecosystem partners.

[0094] In the various examples, the operations and functions described herein may be embodied by an electronic device machine, within which a set or sequence of instructions can be executed to cause an electronic processing system to perform any of the methods discussed herein according to the example embodiments. This machine may be embodied by multiple aspects of: a personal computer (PC), a tablet PC, a personal digital assistant (PDA), a mobile phone or smartphone, an Internet of Things (IoT) device, a network gateway, a switch or bridge, a server or cluster-based system, or any machine capable of executing instructions (sequentially or otherwise) specifying actions to be taken by the machine. Furthermore, although only a single machine may be depicted and referenced in the examples above, it should be understood that such a machine includes any collection of machines that individually or jointly execute a set (or more sets) of instructions to perform any or more of the methods discussed herein. Additionally, these examples and similar examples of processor-based systems should be considered to include any collection of one or more machines controlled or operated by a processor (e.g., a computer) to individually or jointly execute instructions to perform any or more of the methods discussed herein.

[0095] Figure 10 This is a block diagram illustrating examples of components that may exist in processing device 1050 for implementing the techniques described herein. Device 1050 may include any combination of components shown in the examples in the foregoing disclosure or referenced in the foregoing disclosure. These components may be implemented as ICs, portions of ICs, discrete electronics, or other modules, logic, hardware, software, firmware, or combinations thereof suitable for use in device 1050, or as components otherwise incorporated within the rack of a larger system. Furthermore, Figure 10 The block diagram is intended to depict a high-level view of the components of device 1050. However, some of the components shown may be omitted, additional components may be present, and different arrangements of the components shown may occur in other implementations.

[0096] Device 1050 may include processor 1052, which may be a microprocessor, multi-core processor, multi-threaded processor, ultra-low voltage processor, embedded processor, or other known processing element. Processor 1052 may be part of a system-on-a-chip (SoC), in which processor 1052 and other components are formed into a single integrated circuit or single package, such as an Edison™ or Galileo™ SoC board from Intel. As an example, processor 1052 may include Intel-based... ® Processors with Core™ architecture (such as Quark™, ​​Atom™, i3, i5, i7, or MCU-class processors), or those available from Intel in Santa Clara, California.® The company may also acquire another processor of this kind. However, any number of other processors may be used, such as processors available from Advanced Micro Devices (AMD) of Sunnyvale, California; MIPS-based designs from MIPS Technologies of Sunnyvale, California; ARM-based designs licensed from ARM Holdings, Inc.; or processors available from customers, licensees, or adopters of the aforementioned companies. Processors may include units such as those from Apple. ® The company's A5-A12 processors, from Qualcomm® Technologies' Snapdragon... TM (Snapdragon) TM The processor is either from Texas Instruments' OMAP. TM processor.

[0097] Processor 1052 can communicate with system memory 1054 via interconnect 1056 (e.g., a bus). Any number of memory devices can be used to provide a fixed amount of system memory. As an example, the memory can be random access memory (RAM) designed according to the Joint Electronic Devices Engineering Committee (JEDEC) (such as DDR or mobile DDR standards (e.g., LPDDR, LPDDR2, LPDDR3, or LPDDR4)). In various implementations, individual memory devices can be any number of different package types, such as single-die package (SDP), dual-die package (DDP), or quad-die package (QDP). In some examples, these devices can be directly soldered to the motherboard to provide a low-profile solution, while in other examples, the devices are configured as one or more memory modules that are then coupled to the motherboard via a given connector. Any number of other memory implementations can be used, such as other types of memory modules, for example, different kinds of dual in-line memory modules (DIMMs), including but not limited to microDIMMs or miniDIMMs.

[0098] To provide persistent storage for information such as data, applications, operating systems, etc., storage 1058 may also be coupled to processor 1052 via interconnect 1056. In the example, storage 1058 may be implemented via a solid-state drive (SSDD). Other devices that can be used for storage 1058 include flash memory cards (such as SD cards, microSD cards, xD picture cards, etc.) and USB flash drives. In a low-power implementation, storage 1058 may be on-die memory or registers associated with processor 1052. However, in some examples, storage 1058 may be implemented using a micro hard disk drive (HDD). Furthermore, as a complement to or alternative to the described techniques, any number of new technologies may be used for storage 1058, such as resistive random access memory, phase-change memory, holographic memory, or chemical memory, etc.

[0099] Components can communicate via Interconnect 1056. Interconnect 1056 can include any number of technologies, including Industry Standard Architecture (ISA), Extended ISA (EISA), Peripheral Component Interconnect (PCI), Peripheral Component Interconnect Extended (PCIx), PCI Fast (PCIe), or any other technologies. Interconnect 1056 can be a proprietary bus, for example, used in a SoC-based system. Other bus systems may include, such as I2C interfaces, SPI interfaces, point-to-point interfaces, power buses, and so on.

[0100] Interconnect 1056 couples processor 1052 to transceiver 1062 for communication with cloud, fog, or mesh network devices 1064. Transceiver 1062 can use any number of frequencies and protocols, such as 2.4 GHz transmission under the IEEE 802.15.4 standard, using methods such as Bluetooth. ® Bluetooth as defined by a special interest group ® Low Energy (BLE) standard, or ZigBee ® Standards, etc. Any number of radios configured for a specific wireless communication protocol can be used for connectivity to device 1064. For example, a WLAN unit can be used to implement Wi-Fi™ communication according to the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard. Additionally, wireless wide area communication, such as according to cellular or other wireless wide area protocols, can occur via a WWAN unit.

[0101] Transceiver 1062 can communicate using various standards or radios for different ranges. For example, device 1050 can use a BLE-based or other low-power radio local transceiver to communicate with nearby devices (e.g., within about 10 meters) to save power. Device 1064 at a greater distance (e.g., within about 50 meters) can be contacted via ZigBee or other intermediate-power radios. These two communication technologies can occur at different power levels via a single radio, or via separate transceivers, such as a BLE-based local transceiver and a separate ZigBee transceiver.

[0102] Wireless transceiver 1066 may be included to communicate with devices or services in cloud 1000 via LAN or WAN protocols. Wireless transceiver 1066 may be an LPWA transceiver conforming to standards such as IEEE 802.15.4 or IEEE 802.15.4g. Device 1050 may communicate over a wide area using LoRaWAN™ (Long Range Wide Area Network) developed by Semtech and the LoRa Alliance. The technologies described herein are not limited to these technologies but can be used with any number of other cloud transceivers enabling long-range, low-bandwidth communication, such as Sigfox and other technologies. Furthermore, other communication technologies may be used, such as time-division channel hopping as described in the IEEE 802.15.4e specification.

[0103] In addition to the systems mentioned for transceiver 1062 and wireless network transceiver 1066 as described herein, any number of other radio communications and protocols may be used. For example, radio transceivers 1062 and 1066 may include LTE or other cellular transceivers that use spread spectrum (SPA / SAS) communication to enable high-speed communication. Furthermore, any number of other protocols may be used, such as Wi-Fi® networks for medium-speed communication and provisioning network communication.

[0104] Radio transceivers 1062 and 1066 may include radios compatible with any number of 3GPP (Third Generation Partnership Project) specifications, particularly Long Term Evolution (LTE), Long Term Evolution-Advanced (LTE-A), and Long Term Evolution-Advanced Enhanced (LTE-A Pro)). It can be noted that radios compatible with any number of other fixed, mobile, or satellite communication technologies and standards may also be used. These may include, for example, any cellular wide-area wireless communication technology, which may include, for example, 5G communication systems, Global System for Mobile Communications (GSM) radio communication systems, General Packet Radio Service (GPRS) radio communication technology, or GSM Evolution (EDGE) Enhanced Data Rate radio communication technology, UMTS (Universal Mobile Telecommunications System) communication technology, and, in addition to the standards listed above, any number of satellite uplink technologies may be used for wireless network transceiver 1066, including, for example, radios conforming to standards published by the ITU (International Telecommunication Union) or ETSI (European Telecommunication Standards Institute). The examples provided herein should therefore be understood to be applicable to a wide variety of other existing and undeveloped communication technologies.

[0105] Network interface controller (NIC) 1068 may be included to provide wired communication to cloud 1000 or to other devices, such as device 1064. Wired communication may provide Ethernet connectivity or may be based on other types of networks, such as Controller Area Network (CAN), Local Area Network (LIN), DeviceNet, ControlNet, Data Highway+, Fieldbus (PROFIBUS), or Industrial Ethernet (PROFINET), etc. Additional NIC 1068 may be included to allow connectivity to a second network; for example, NIC 1068 provides communication to the cloud via Ethernet, and a second NIC 1068 provides communication to other devices via another type of network.

[0106] Interconnect 1056 couples processor 1052 to external interface 1070, which is used to connect external devices or subsystems. External devices may include sensors 1072, such as accelerometers, level sensors, flow sensors, optical sensors, camera sensors, temperature sensors, GPS sensors, pressure sensors, barometric pressure sensors, and so on. External interface 1070 may further be used to connect device 1050 to actuator 1074 (such as power switches, valve actuators, audible sound generators, visual warning devices, etc.).

[0107] In some optional examples, various input / output (I / O) devices may be present within or connected to device 1050. For example, a display or other output device 1084 may be included to display information such as sensor readings or actuator positions. Input devices 1086 (such as touchscreens or keypads) may be included to accept input. Output devices 1084 may include any number of audio or visual display forms, including: simple visual outputs such as binary status indicators (e.g., LEDs); multi-character visual outputs; or more complex outputs such as displays (e.g., LCD screens) that have outputs of characters, graphics, multimedia objects, etc., generated or produced from the operation of device 1050.

[0108] Battery 1076 can power device 1050, but in an example where device 1050 is mounted in a fixed location, device 1050 may have a power source coupled to the power grid. Battery 1076 can be a lithium-ion battery or a metal-air battery (such as a zinc-air battery, an aluminum-air battery, a lithium-air battery), etc.

[0109] A battery monitor / charger 1078 may be included in device 1050 to track the state of charge (SoCh) of battery 1076. The battery monitor / charger 1078 may be used to monitor other parameters of battery 1076 to provide failure prediction, such as the state of health (SoH) and state of function (SoF) of battery 1076. The battery monitor / charger 1078 may include a battery monitoring integrated circuit, such as the LTC4020 or LTC2990 from Linear Technologies, the ADT7488A from ON Semiconductor in Phoenix, Arizona, or an IC from the UCD90xxx family from Texas Instruments in Dallas, Texas. The battery monitor / charger 1078 may pass information from battery 1076 to processor 1052 via interconnect 1056. The battery monitor / charger 1078 may also include an analog-to-digital converter (ADC) that allows processor 1052 to directly monitor the voltage of battery 1076 or the current from battery 1076. Battery parameters can be used to determine the actions that the device 1050 can perform, such as transmission frequency, mesh network operation, sensing frequency, and so on.

[0110] Power block 1080 or other power sources coupled to the grid can be coupled to battery monitor / charger 1078 to charge battery 1076. In some examples, power block 1080 can be replaced by a wireless power receiver to obtain power wirelessly, for example, via a loop antenna in device 1050. Wireless battery charging circuitry, such as the LTC4020 chip from Linear Technologies, Inc., Milpitas, California, etc., can be included in battery monitor / charger 1078. The specific charging circuitry selected depends on the size of battery 1076 and therefore on the required current. Charging can be performed using the Airfuel standard issued by the Airfuel Alliance, the Qi wireless charging standard issued by the Wireless Power Consortium, or the Rezence charging standard issued by the Alliance for Wireless Power, etc.

[0111] Storage 1058 may include instructions 1082 in the form of software, firmware, or hardware commands for implementing the techniques disclosed herein. Although such instructions 1082 are shown as blocks of code included in memory 1054 and storage 1058, it will be understood that any of the blocks of code may be replaced by hard-wired circuitry, for example, built into an application-specific integrated circuit (ASIC).

[0112] In the example, instructions 1082 provided via memory 1054, memory 1058, or processor 1052 can be embodied in a non-transitory machine-readable medium 1060, which includes code for instructing processor 1052 to perform electronic operations in device 1050. Processor 1052 can access non-transitory machine-readable medium 1060 via interconnect 1056. For example, non-transitory machine-readable medium 1060 can be configured for... Figure 10 The storage 1058 may be embodied in the device described, or may include specific storage units such as optical discs, flash drives, or any number of other hardware devices. The non-transitory machine-readable medium 1060 may further include, provide, or invoke instructions 1088 for instructing the processor 1052 to perform specific sequences or flows of actions, such as those described in the flowcharts and block diagrams(s) of the operations and functions depicted above.

[0113] In the example, instructions 1088 on processor 1052 (either alone or in combination with instructions 1088 on machine-readable medium 1060) can configure the execution or operation of trusted execution environment (TEE) 1090. In the example, TEE 1090 operates as a protected area accessible to processor 1052 for secure access to data and secure execution of instructions. Various implementations of TEE 1090, along with the accompanying secure area in processor 1052 or memory 1054, can be provided, for example, using Intel® Software Protection Extensions (SGX) or ARM® TrustZone® Hardware Security Extensions, Intel® Management Engine (ME) or Intel® Converged Security Manageability Engine (CSME). Security hardening, hardware root of trust, and other aspects of trusted or protected operation can be implemented in device 1050 via TEE 1090 and processor 1052.

[0114] In further examples, machine-readable media also includes any tangible medium capable of storing, encoding, or carrying instructions executable by a machine and causing the machine to perform any one or more methods of this disclosure, or data structures utilized by or associated with such instructions. "Machine-readable media" can therefore include, but is not limited to, solid-state memory, optical media, and magnetic media. Specific examples of machine-readable media include non-volatile memory, including, but not limited to: semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory devices); magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. Instructions embodied in the machine-readable medium can be transmitted or received via a communication network using a transmission medium, via a network interface device, utilizing any of several transmission protocols (e.g., HTTP).

[0115] It should be understood that the functional units or capabilities described in this specification may be referred to or labeled as components or modules, thereby emphasizing the independence of their implementation. Such components may be embodied in any number of software or hardware forms. For example, a component or module may be implemented as a hardware circuit comprising: custom-designed very large-scale integrated circuits (VLSI) or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. Components or modules may also be implemented in programmable hardware devices such as field-programmable gate arrays, programmable array logic, programmable logic devices, etc. Components or modules may also be implemented in software for execution by various types of processors. The identified component or module of executable code may, for example, comprise one or more physical or logical blocks of computer instructions, which may be organized, for example, into objects, procedures, or functions. However, the executable elements of the identified component or module need not be physically together, but may comprise different instructions stored in different locations that, when logically combined, comprise the component or module and achieve the claimed purpose for that component or module.

[0116] In practice, executable code components or modules can be single instructions or numerous instructions, and can even be distributed across several different code segments, across different programs, and across several memory devices or processing systems. Specifically, some aspects of the described process (such as code rewriting and code analysis) can occur on a different processing system (e.g., a computer in a data center) than the processing system in which the code is deployed (e.g., a computer embedded in a sensor or robot). Similarly, operational data can be identified and illustrated within a component or module, and can be materialized in any suitable form and organized within any suitable type of data structure. Operational data can be collected as a single dataset or distributed across different locations (including across different storage devices), and can exist at least partially as electronic signals within a system or network. Components or modules can be passive or active, including agents for performing the desired functions.

[0117] Figure 11The diagram illustrates a block diagram of an example machine on which any one or more of the techniques (e.g., methods) discussed herein may be performed. Examples as described herein may include, or be operable by, logic or components or mechanisms in machine 1100. A circuit system (e.g., a processing circuit system) is a collection of circuits that include hardware (e.g., simple circuits, gates, logic, etc.) implemented in a tangible entity of machine 1100. The membership of a circuit system can be flexible over time. A circuit system includes members that can perform a specified operation individually or in combination during operation. In the example, the hardware of the circuit system may be immutably designed to perform a specific operation (e.g., hardwired). In the example, the hardware of the circuit system may include dynamically connected physical components (e.g., execution units, transistors, simple circuits, etc.) that include machine-readable media that are physically modified (e.g., magnetically, electrically, movably arranged, etc., for invariant aggregate particles) to encode instructions for a specific operation. When connecting physical components, the underlying electrical properties of the hardware components change, for example, from insulator to conductor, or vice versa. These instructions enable embedded hardware (e.g., an execution unit or loading mechanism) to create members of a circuit system within the hardware via variable connections to perform multiple parts of a specific operation during operation. Accordingly, in the example, a machine-readable medium element is part of the circuit system, or another component communicatively coupled to the circuit system while the device is running. In the example, any of the physical components can be used in more than one member of more than one circuit system. For example, under operation, an execution unit can be used at one moment in a first circuit of a first circuit system and reused at a different time by a second circuit of the first circuit system, or by a third circuit of the second circuit system. Additional examples of these components of machine 1100 are provided below.

[0118] In alternative embodiments, machine 1100 may operate as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, machine 1100 may operate as a server machine, a client machine, or both in a server-client network environment. In the example, machine 1100 may act as a peer-to-peer (P2P) (or other distributed) network environment. Machine 1100 may be a personal computer (PC), tablet PC, set-top box (STB), personal digital assistant (PDA), mobile phone, web device, network router, switch, or bridge, or any machine capable of executing instructions (sequentially or otherwise) specifying actions to be taken by the machine. Further, although only a single machine is illustrated, the term "machine" should also be considered to include any collection of machines that individually or jointly execute a set (or more) of instructions to perform any or more of the methods discussed herein, such as cloud computing, Software as a Service (SaaS), and other computer cluster configurations.

[0119] Machine (e.g., computer system) 1100 may include hardware processor 1102 (e.g., central processing unit (CPU), graphics processing unit (GPU), hardware processor core, or any combination thereof), main memory 1104, static memory (e.g., memory or storage for firmware, microcode, basic input / output (BIOS), unified extensible firmware interface (UEFI), etc.) 1106, and mass storage 1108 (e.g., hard drive, tape drive, flash storage, or other block device), some or all of which may communicate with each other via interconnect links (e.g., bus) 1130. Machine 1100 may further include display unit 1110, alphanumeric input device 1112 (e.g., keyboard), and user interface (UI) navigation device 1114 (e.g., mouse). In the example, display unit 1110, input device 1112, and UI navigation device 1114 may be a touchscreen display. Machine 1100 may additionally include a storage device (e.g., a drive unit) 1108, a signal generation device 1118 (e.g., a speaker), a network interface device 1120, and one or more sensors 1116 (such as a Global Positioning System (GPS) sensor, compass, accelerometer, or other sensor). Machine 1100 may include an output controller 1128 for communicating with or controlling one or more peripheral devices (e.g., a printer, card reader, etc.), such as serial (e.g., Universal Serial Bus (USB)), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connections.

[0120] The registers, main memory 1104, static memory 1106, or mass storage 1108 of processor 1102 may be or may include machine-readable medium 1122 on which one or more sets of data structures or instructions 1124 (e.g., software) are stored, which embody or are utilized by any one or more of the techniques or functions described herein. Instructions 1124 may also reside wholly or at least partially within the registers, main memory 1104, static memory 1106, or mass storage 1108 of processor 1102 during execution by machine 1100. In this example, one or any combination of hardware processor 1102, main memory 1104, static memory 1106, or mass storage 1108 may constitute machine-readable medium 1122. Although machine-readable medium 1122 is illustrated as a single medium, the term "machine-readable medium" can include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) configured to store one or more instructions 1124.

[0121] The term "machine-readable medium" can include any medium capable of storing, encoding, or carrying instructions for execution by machine 1100 and causing machine 1100 to perform any one or more of the technologies disclosed herein, or capable of storing, encoding, or carrying data structures used by or associated with such instructions. Examples of non-limiting machine-readable media can include solid-state memory, optical media, magnetic media, and signals (e.g., radio frequency signals, other photon-based signals, sound signals, etc.). In examples, non-transitory machine-readable media includes machine-readable media having a plurality of particles having invariant (e.g., rest) mass and thus being a composition of matter. Accordingly, a non-transitory machine-readable medium is a machine-readable medium that does not include transiently propagating signals. Specific examples of non-transitory machine-readable media can include: non-volatile memory, such as semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)) and flash memory devices; disks, such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

[0122] Commands 1124 can be further sent or received via network interface device 1120 using a transmission medium through communication network 1126, utilizing any of a variety of transport protocols (e.g., Frame Relay, Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), etc.). Example communication networks may include local area networks (LANs), wide area networks (WANs), packet data networks (e.g., the Internet), mobile phone networks (e.g., cellular networks), conventional telephone (POTS) networks, and wireless data networks (e.g., IEEE 802.11 family of standards known as Wi-Fi®, IEEE 802.15.4 family of standards, peer-to-peer (P2P) networks), etc. In the example, network interface device 1120 may include one or more physical jacks (e.g., Ethernet jacks, coaxial jacks, or telephone jacks) or one or more antennas for connection to communication network 1126. In the example, network interface device 1120 may include multiple antennas that communicate wirelessly using at least one of single-input multiple-output (SIMO), multiple-input multiple-output (MIMO), or multiple-input single-output (MISO) technologies. The term "transmission medium" should be understood to include any intangible medium capable of storing, encoding, or carrying instructions for execution by machine 1100, and "transmission medium" includes digital or analog communication signals or other intangible media used to facilitate communication of such software. The transmission medium is a machine-readable medium.

[0123] Machine-readable media can be provided by storage devices or other devices capable of hosting data in a non-transitory format. In the example, information stored on or otherwise provided on a machine-readable medium can represent instructions, such as the instructions themselves or formats from which instructions can be derived. Such formats from which instructions can be derived may include source code, encoded instructions (e.g., in compressed or encrypted form), packaged instructions (e.g., divided into multiple packages), etc. Information representing instructions in a machine-readable medium can be processed by a processing circuitry system into instructions for performing any of the operations discussed herein. For example, deriving instructions from information (e.g., processed by a processing circuitry system) may include: compiling (e.g., from source code, object code, etc.), interpreting, loading, organizing (e.g., dynamic or static linking), encoding, decoding, encrypting, deencrypting, packaging, unpacking, or otherwise manipulating the information into instructions.

[0124] In the example, deriving instructions may include assembling, compiling, or interpreting information (e.g., by processing a circuit system) to create instructions according to some intermediate or preprocessed format provided by a machine-readable medium. When information is provided in multiple parts, it can be combined, unpacked, and modified to create instructions. For example, the information may reside in multiple compressed source code packages (or object code or binary executable code, etc.) on one or more remote servers. The source code packages may be encrypted during transmission over a network and, if necessary, decrypted, decompressed, assembled (e.g., linked), compiled or interpreted on the local machine (e.g., compiled or interpreted into a library, a standalone executable, etc.), and executed by the local machine.

[0125] Therefore, as Figure 12 As shown, blockchain technology can be used to support network functions. Figure 12 This is a block diagram illustrating an example delivery of a telecommunications service. An entity (customer) wishing to launch a new service (such as a voice service) uses a descriptor record to describe the desired service. The customer signs the descriptor and provides it to the blockchain. The descriptor can be provided to a registry provider (registrant) via a descriptor message. The provider group may wish to provide all or part of the service. The blockchain user group ensures that the descriptor message has indeed been submitted and that the registrant has received it. The user group can copy the registrant's content, making the descriptor message ubiquitous and available to anyone with access to a copy of the blockchain block. In some embodiments, the registrant may send payment (e.g., electronic coins) to the customer, or may receive a portion of the payment (e.g., a portion of electronic coins) to confirm receipt of the descriptor. For example, the contract is the descriptor for orchestration as a service, the customer is the user, and the service provider is the orchestrator group.

[0126] Service providers seeking to offer services defined by descriptors can continuously monitor the transactions of registrants. For example, a service provider can inspect the list of blockchain transactions for any miner. Essentially, blockchain can be used to implement a publish-subscribe mechanism.

[0127] Interested service providers can respond to submitted descriptors by creating a bid record signed by the service provider and sent to the client as a blockchain transaction. The client confirms receipt of a bid by sending a portion of the reward (e.g., a portion of electronic coins) to each bidder (of the considered bids). The client may include a timeframe for making a decision, and / or bidders may include a timeframe for receiving bids. These timeframes can be different. If a timeframe expires before a bid is accepted, the blockchain records the passage of time, ensuring that the auditor clearly understands what the timeframe was and whether it has expired.

[0128] The client accepts a bid by signing a contract and sending the signed contract to the initiator. The blockchain records the acceptance message being sent. The bidder confirms acceptance by sending electronic coins as payment for winning the contract, or a portion of electronic coins (if other payment terms are defined). At this point, the blockchain knows that the contract and its terms have been accepted.

[0129] Therefore, as Figure 12 As shown, blockchain technology can be applied at each step. Once a new network service (e.g., voice service) is requested, an orchestration provider is selected based on the descriptor used for service orchestration. For DSFC, the orchestrator creates a chain of service functions for the voice service and processes the descriptor, SLA, security, QoS, and other parameters of the voice service. The orchestrator selects the voice service and links the SLA of the voice service based on the distributed service function chain. Then, the orchestrator publishes service hosting contracts and networking service contracts based on the descriptors. In this case, the contract is a descriptor of a distributed service consisting of a sequence / graph of function-as-a-service functions. Now, the customer can be the orchestrator, and the service provider is the edge service solution provider.

[0130] Each distributed entity bids for hosting and network service contracts. The orchestrator selects a set of providers hosting discrete functions identified by DSFC. For DWH, contracts are for discrete network functions (VNF, COTS, etc.), customers are edge service solution providers, and service providers are a group of FaaS hosting providers.

[0131] Then, the service is executed according to the SLA. Specifically, DWH is implemented by orchestrating the resources to be used (e.g., the base station's CPU, NIC, VF, L1-L3 functions). Network services are implemented by orchestrating network services for the voice service (e.g., vEPC VNF). The user then executes the service level agreement and receives the results of the distributed execution. The execution steps can be monitored by the blockchain because FaaS nodes can record (audit) the execution, provide telemetry data, and / or accept / return electronic coins in the confirmation of the executed service. The customer can then begin using the service provided by the service provider. This may depend on the service provider providing access, exposing service interfaces, etc. This may happen on or off the blockchain. The voice service can be cancelled after the contract is fulfilled and the voice service is delivered.

[0132] Additional examples of the embodiments of the methods, systems, and devices described herein include the following non-limiting configurations. Each of the following non-limiting examples may exist independently or may be combined with any or more examples provided below or throughout this disclosure in any permutation or combination.

[0133] Example

[0134] Example 1 is an apparatus comprising: a processing circuitry system configured to: issue a request for orchestration of a network service to be delivered using Network Functions Virtualization (NFV), the bid being issued using a Distributed Service Functions Chain (DSFC) contract blockchain, wherein the apparatus, the DSFC contract, and the initiator of the request for the network service are identified using a sovereign identity blockchain; determine, based on the DSFC contract blockchain, that the apparatus orchestrates the network service from among entities that have been instructed to orchestrate the network service; in response to determining that the apparatus orchestrates the network service, identify, from a DSFC Workload Hosting (DWH) contract blockchain for providing the network service, the DSFC Workload Hosting (DWH) contract blockchain containing DWH contract bids from the entities providing the network service, wherein the entities and the DWH contracts are identified using a sovereign identity blockchain; verify that at least one entity is executing a DWH contract according to the DWH contract; and a memory configured to store the DWH contracts.

[0135] In Example 2, the subject of Example 1 includes: wherein the processing circuit system is further arranged to verify that at least one entity is provided with remuneration for fulfilling the DWH contract.

[0136] In Example 3, the subject of Examples 1-2 includes a processing circuit system that is further arranged to create a chain of service functions for network services.

[0137] In Example 4, the subject of Example 3 includes a processing circuit system further arranged to verify, based on the service function chain, that the DWH contract is being executed by at least one entity in accordance with the DWH contract by collecting telemetry data that reports one or more of the following: regulatory chain compliance, regulatory compliance, service level agreement (SLA) compliance, quality of service (QoS) compliance, and security compliance.

[0138] In Example 5, the subject of Examples 1-4 includes a processing circuit system that is further arranged to select at least one entity from the DWH contract blockchain for providing network services.

[0139] In Example 6, the topics of Examples 1-5 include network services including Virtual Network Functions (VNFs).

[0140] In Example 7, the subject of Example 6 includes a processing circuit system that is further arranged to orchestrate multiple providers hosting discrete functions for providing VNFs.

[0141] In Example 8, the topics of Examples 1-7 include entry descriptors for at least one of the Sovereign Identity Blockchain, DSFC Contract Blockchain, or DWH Contract Blockchain, which are defined in the European Telecommunications Standards Institute (ETSI) NFV standard.

[0142] In Example 9, the subject of Examples 1-8 includes a processing circuit system further arranged to generate random, self-generated identifiers, hash the identifiers using a cryptographic hash to form cryptographically hashed identifiers, and submit the cryptographically hashed identifiers to a sovereign identity blockchain as a blockchain identifier for the device.

[0143] In Example 10, the subject of Examples 1-9 includes, where the DSFC contract contains the time range in which the DSFC contract is valid.

[0144] In Example 11, the subject of Examples 1-10 includes a network service that is a distributed network service, and a processing circuit system that is further configured to use a blockchain to issue DWH contracts and network service contracts for the distributed network service.

[0145] In Example 12, the topics of Examples 1-11 include the integration of the Sovereign Identity Blockchain, the DSFC Blockchain, and the DWH Blockchain via a single distributed digital ledger.

[0146] Example 13 is a storage device that includes instructions, wherein when the instructions are executed by the processing circuitry of a computing device, the processing circuitry performs the following actions: publishing a request for network service orchestration using a Distributed Service Function Chain (DSFC) contract blockchain, wherein the computing device, the DSFC contract, and the initiator of the request for the network service are identified using a sovereign identity blockchain; in response to determining that the computing device is used to orchestrate the network service using the DSFC contract blockchain, creating a service function chain for the network service for at least one entity using a DSFC Workload Hosting (DWH) contract blockchain, the DSFC Workload Hosting (DWH) contract blockchain containing DWH contract bids for the entities using the network service, wherein the entities and the DWH contracts are identified using a sovereign identity blockchain; and verifying that at least one entity is executing a DWH contract according to the DWH.

[0147] In Example 14, the subject of Example 13 includes instructions that further enable the processing circuitry system to verify, based on the service function chain, that the DWH contract is being executed by at least one entity in accordance with the DWH contract by collecting telemetry data that reports the following: chain of supervision compliance, regulatory compliance, service level agreement (SLA) compliance, quality of service (QoS) compliance, and security compliance.

[0148] In the subject of Example 15, the subjects of Examples 13-14 include instructions that further cause the processing circuit system to select at least one entity from the DWH contract blockchain for providing network services.

[0149] In Example 16, the subject of Examples 13-15 includes network services that include Virtual Network Functions (VNFs).

[0150] In Example 17, the subject of Example 16 includes instructions that further enable the processing circuitry system to orchestrate multiple providers hosting discrete functions for providing VNFs.

[0151] In Example 18, the subject of Examples 13-17 includes instructions that further cause the processing circuitry system to generate random, self-generated identifiers, hash the identifiers using a cryptographic hash to form cryptographically hashed identifiers, and submit the cryptographically hashed identifiers to the sovereign identity blockchain as blockchain identifiers for the computing device.

[0152] In Example 19, the subject of Examples 13-18 includes the following: the network service is a distributed network service, and the instructions further enable the processing circuit system to use a blockchain to issue DWH contracts and network service contracts for the distributed network service.

[0153] In Example 20, the topics of Examples 13-19 include the integration of the Sovereign Identity Blockchain, the DSFC Blockchain, and the DWH Blockchain via a single distributed digital ledger.

[0154] Example 21 is a method for orchestrating network services, comprising: selecting a network service to be delivered; selecting an orchestration provider for the network service using an autonomous identity blockchain for identifying the orchestration provider and a Distributed Service Function Chain (DSFC) contract blockchain for linking the orchestration provider to the network service; creating a service function chain for the network service for at least one provider to host discrete functions identified by the DSFC based on a DSFC Workload Hosting (DWH) contract blockchain containing DWH contract bids from network service providers, the DWH contract blockchain being used to link providers and functions; and executing the network service according to a Service Level Agreement (SLA) identified by the service function chain.

[0155] In Example 22, the subject of Example 21 includes that network function virtualization (NFV) will be used to deliver network services, and at least one of the functions is a virtual network function (VNF).

[0156] In Example 23, the subject of Example 22 includes orchestrating hosting multiple providers for providing discrete functionality for VNFs.

[0157] In Example 24, the subject of Examples 21-23 includes collecting telemetry data and verifying, based on the Service Function Chain and the telemetry data, that the DWH contract is being executed by at least one entity in accordance with the DWH contract, the telemetry data reporting regulatory chain compliance, regulatory compliance, Service Level Agreement (SLA) compliance, Quality of Service (QoS) compliance, and security compliance.

[0158] In Example 25, the topics of Examples 21-24 include generating random, self-generated identifiers for orchestration providers and each of the providers, hashing the identifiers with a cryptographic hash to form a cryptographically hashed identifier, and submitting the cryptographically hashed identifier to the sovereign identity blockchain as a blockchain identifier.

[0159] Example 26 is an apparatus comprising: means for selecting a network service to be delivered; means for selecting an orchestration provider for the network service using an autonomous identity blockchain for identifying an orchestration provider and a Distributed Service Function Chain (DSFC) contract blockchain for linking the orchestration provider to the network service; means for creating a service function chain for the network service for at least one provider to host discrete functions identified by the DSFC based on a DSFC Workload Hosting (DWH) contract blockchain containing DWH contract bids from network service providers, the DWH contract blockchain being used to link providers and functions; and means for executing the network service according to a Service Level Agreement (SLA) identified by the service function chain.

[0160] In Example 27, the subject of Example 26 includes a network service that will be delivered using network function virtualization (NFV), and at least one of the functions is a virtual network function (VNF).

[0161] In Example 28, the subject of Example 27 includes apparatus for orchestrating and hosting multiple providers of discrete functionality for providing VNFs.

[0162] In Example 29, the subject matter of Examples 26-28 includes: apparatus for collecting telemetry data, and apparatus for verifying, based on the service function chain and telemetry data, that the DWH contract is being executed by at least one entity in accordance with the DWH contract, with the telemetry data reporting compliance with the regulatory chain, regulatory compliance, service level agreement (SLA) compliance, quality of service (QoS) compliance, and security compliance.

[0163] In Example 30, the subject of Examples 26-29 includes apparatus for generating random, self-generated identifiers for an orchestration provider and each of the providers, hashing the identifiers with a cryptographic hash to form a cryptographically hashed identifier, and submitting the cryptographically hashed identifier to a sovereign identity blockchain as a blockchain identifier.

[0164] In Example 31, the topics of Examples 26-30 include the integration of a sovereign identity blockchain, a DSFC blockchain, and a DWH blockchain via a single distributed digital ledger.

[0165] Example 32 may include an apparatus comprising means for performing one or more elements of any of the methods described or associated with any of Examples 1-31 or any other methods or processes described herein.

[0166] Example 33 may include one or more non-transitory computer-readable media comprising instructions to cause the electronic device to perform one or more elements of any of the methods described or associated with Examples 1-31, or any other methods or processes described herein, after execution of the instructions by one or more processors of the electronic device.

[0167] Example 34 may include a device comprising logic, modules, or circuitry to perform one or more elements of any of the methods described or associated with any of Examples 1-31 or any other methods or processes described herein.

[0168] Example 35 may include, or part of, any of the methods, techniques or processes described or associated with any of Examples 1-31.

[0169] Example 36 may include an apparatus comprising: one or more processors and one or more computer-readable media including instructions that, when executed by the one or more processors, cause the one or more processors to perform, or a portion thereof, any of the methods, techniques, or processes described or associated with any of Examples 1-31.

[0170] Example 37 may include a signal or part or portion thereof as described or associated with any of Examples 1-31.

[0171] Example 38 may include signals in a wireless network as described or associated with any of Examples 1-31, or otherwise shown and described herein.

[0172] Example 39 may include methods of communication in a wireless network as described or associated with any of Examples 1-31, or otherwise shown and described herein.

[0173] Example 40 may include a system for providing wireless communication as described or associated with any of Examples 1-31, or otherwise shown and described herein.

[0174] Example 41 may include any of or related to Examples 1-31, or devices for providing wireless communication as otherwise shown and described herein.

[0175] Example 42 is a network including various devices and device communication media for performing the operations of Examples 1-31 or any other operations shown and described herein.

[0176] Example 43 is a 4G / 5G communication network topology that includes corresponding communication links suitable for performing communications for the operation of any of Examples 1-31 or for operations otherwise shown and described herein.

[0177] Example 44 is an edge computing device implementation that includes processing nodes and computing units suitable for performing the operations of Examples 1-31 or any other operations shown and described herein.

[0178] Example 45 is an ETSI NFV system implementation that includes devices, processing nodes, and computing units adapted to perform the operations of Examples 1-31 or any other operations shown and described herein.

[0179] Example 46 is an edge cloud network platform that includes physical and logical computing resources suitable for performing Examples 1-31 or any other operations shown and described herein.

[0180] Example 47 is an apparatus that includes various means for performing the operations of Examples 1-31 or any other operations shown and described herein.

[0181] Example 48 is a system for performing any of the operations in Examples 1-31 or as otherwise shown and described herein.

[0182] Example 49 is at least one machine-readable storage medium including information representing instructions that, when executed by a processing circuitry system, cause the processing circuitry system to perform operations for implementing any of Examples 1-48.

[0183] In the above specific embodiments, features may be combined to make this disclosure flow smoothly. However, claims applicable to these features may not state every feature disclosed herein, as embodiments may characterize a subset of said features. Furthermore, embodiments may include fewer features than those disclosed in particular examples.

Claims

1. A computing device, comprising: Processing circuitry system, the processing circuitry system being arranged for: The request for orchestration of network services to be delivered is issued using Network Functions Virtualization (NFV), and the request is issued using a Distributed Service Functions Chain (DSFC) contract blockchain, wherein the device, the DSFC contract, and the initiator of the request for the network services are identified using an autonomous identity blockchain. The DSFC contract blockchain is used to determine the network services that the device is used to orchestrate from among entities that have been instructed to orchestrate the network services; In response to determining that the device is used to orchestrate the network service, at least one entity for providing the network service is identified from the DSFC Workload Hosting (DWH) contract blockchain, the DSFC Workload Hosting (DWH) contract blockchain containing DWH contract bids of the entities providing the network service, wherein the entities and DWH contracts are identified using the sovereign identity blockchain; and Verify that at least one entity is executing the DWH contract according to the DWH contract; and A memory configured to store the DWH contract.

2. The computing device of claim 1, wherein the processing circuitry is further arranged to verify that the at least one entity is provided with payment for fulfilling the DWH contract.

3. The computing device of claim 1 or 2, wherein the processing circuitry is further arranged to create a service function chain for the network service.

4. The computing device of claim 3, wherein the processing circuitry is further arranged to verify, based on the service function chain, that the DWH contract is being executed by the at least one entity in accordance with the DWH contract by collecting telemetry data that reports one or more of the following: chain of supervision compliance, regulatory compliance, service level agreement (SLA) compliance, quality of service (QoS) compliance, and security compliance.

5. The computing device of claim 1 or 2, wherein the processing circuitry is further arranged to select at least one entity from the DWH contract blockchain for providing the network service.

6. The computing device of claim 1 or 2, wherein the network service includes a Virtual Network Function (VNF).

7. The computing device of claim 6, wherein the processing circuitry is further arranged to orchestrate multiple providers hosting discrete functions for providing VNFs.

8. The computing device of claim 1 or 2, wherein the entry descriptor of at least one of the sovereign identity blockchain, the DSFC contract blockchain, or the DWH contract blockchain is defined in the European Telecommunications Standards Institute (ETSI) NFV standard.

9. The computing device of claim 8, wherein the descriptor includes an orchestrator descriptor, a resource descriptor, and a network service descriptor, and the network service descriptor includes an orchestrator descriptor identity, service level agreement (SLA) parameters, and financial terms.

10. The computing device of claim 1 or 2, wherein the processing circuitry is further arranged to generate a random, self-generated identifier, hash the identifier using a cryptographic hash to form a cryptographically hashed identifier, and submit the cryptographically hashed identifier to the sovereign identity blockchain as a blockchain identifier of the device.

11. The computing device of claim 1 or 2, wherein the DSFC contract includes a time range in which the DSFC contract is valid.

12. The computing device of claim 1 or 2, wherein the network service is a distributed network service, and the processing circuitry is further configured to issue a DWH contract and a network service contract for the distributed network service using a blockchain.

13. The computing device of claim 1 or 2, wherein the sovereign identity blockchain, the DSFC blockchain, and the DWH blockchain are incorporated via a single distributed digital ledger.

14. A computing device, comprising: A means for issuing a request for orchestration of a network service using a Distributed Service Function Chain (DSFC) contract blockchain, wherein the computing device, the DSFC contract, and the initiator of the request for the network service are identified using a sovereign identity blockchain. A means for creating a service function chain for at least one entity providing a network service based on a DSFC Workload Hosting (DWH) contract blockchain in response to determining that the computing device is used to orchestrate the network service using a DSFC contract blockchain, the DSFC Workload Hosting (DWH) contract blockchain containing DWH contract bids for entities providing the network service, wherein the entities and DWH contracts are identified using the sovereign identity blockchain; and A means for verifying that the at least one entity is executing the DWH contract according to the DWH.

15. The computing device of claim 14, further comprising means for verifying, based on the service function chain, that the DWH contract is being performed by the at least one entity in accordance with the DWH contract by collecting telemetry data reporting the following: chain of supervision compliance, regulatory compliance, service level agreement (SLA) compliance, quality of service (QoS) compliance, and security compliance.

16. The computing device of claim 14 or 15, further comprising means for selecting at least one entity from the DWH contract blockchain for providing the network service.

17. The computing device of claim 14 or 15, wherein the network service includes a Virtual Network Function (VNF) and the device further includes means for orchestrating and hosting multiple providers of discrete functions for providing VNFs.

18. The computing device of claim 14 or 15, further comprising means for generating a random, self-generated identifier, means for hashing the identifier using a cryptographic hash to form a cryptographically hashed identifier, and means for submitting the cryptographically hashed identifier to the sovereign identity blockchain as a blockchain identifier of the computing device.

19. The computing device of claim 14 or 15, wherein the network service is a distributed network service, and the device further includes means for issuing DWH contracts and network service contracts for the distributed network service using a blockchain.

20. The computing device of claim 14 or 15, wherein the sovereign identity blockchain, the DSFC blockchain, and the DWH blockchain are incorporated via a single distributed digital ledger.

21. A method for orchestrating network services, comprising: Select the network service to be delivered; The orchestration provider for the network service is selected using an autonomous identity blockchain for identifying the orchestration provider and a distributed service function chain (DSFC) contract blockchain for linking the orchestration provider to the network service. A service function chain is created for at least one provider of the network service to host discrete functions identified by DSFC based on the DSFC Workload Hosting (DWH) contract blockchain, which contains DWH contract bids from the providers of the network service and is used to link the providers and the functions. as well as The network services are performed according to the Service Level Agreement (SLA) identified by the Service Function Chain.

22. The method of claim 21, wherein network function virtualization (NFV) is used to deliver the network service, and at least one of the functions is a virtual network function (VNF).

23. The method of claim 22, further comprising orchestrating and hosting multiple providers for providing discrete functionality of the VNF.

24. The method of any one or more of claims 21-23, further comprising: Collect telemetry data and verify, based on the service function chain and the telemetry data, that the DWH contract is being executed by the at least one entity in accordance with the DWH contract. The telemetry data reports regulatory chain compliance, regulatory compliance, service level agreement (SLA) compliance, quality of service (QoS) compliance, and security compliance.

25. The method of any one or more of claims 21-23, further comprising: generating a random, self-generated identifier for the orchestration provider and each of the providers; hashing the identifier using a cryptographic hash to form a cryptographically hashed identifier; and submitting the cryptographically hashed identifier to the sovereign identity blockchain as a blockchain identifier.

Images