DE112018007007T5

DE112018007007T5 - Verteilte selbstsouveräne identitäten zur virtualisierung von netzwerkfunktionen

Info

Publication number: DE112018007007T5
Application number: DE112018007007.7T
Authority: DE
Inventors: Kapil Sood; Ned M. Smith
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2018-02-01
Filing date: 2018-12-28
Publication date: 2020-11-12
Also published as: CN111543029A; WO2019152119A1; US20200366493A1; US11757650B2

Abstract

Verschiedene Systeme und Verfahren zum Verteilen einer Orchestrierung von Netzwerkdiensten unter Verwendung einer Blockchain-Technologie sind offenbart. Ein Gebot zur Orchestrierung eines Netzwerkdienstes, der unter Verwendung von NFV mit Hilfe einer Blockchain für DSFC-Verträge bereitgestellt werden soll, wird abgegeben. Das Gerät, der DSFC-Vertrag und der Initiator einer Anfrage für den Netzwerkdienst werden mit Hilfe einer Blockchain für selbstsouveräne Identitäten identifiziert. Das Gerät bestimmt, dass es den Netzwerkdienst basierend auf der Blockchain für DSFC-Verträge orchestrieren soll und identifiziert mindestens eine Entität zum Bereitstellen des Netzwerkdienstes aus einer Blockchain für DWH-Verträge, welche DWH-Vertragsgebote von Entitäten für den Netzwerkdienst enthält. Die Entitäten und der DWH-Vertrag werden mit Hilfe der Blockchain für selbstsouveräne Identitäten identifiziert. Das Gerät stellt sicher, dass der DWH-Vertrag durch die mindestens eine Entität gemäß dem DWH-Vertrag ausgeführt wird und stellt nach Erfüllung eine Vergütung zur Verfügung.

Description

PRIORITÄTSANSPRUCH
Diese Patentanmeldung beansprucht den Prioritätsvorteil der vorläufigen US-Patentanmeldung mit der Seriennummer 62/625,177 , eingereicht am 1. Februar 2018, welche hiermit durch Verweis in ihrer Gesamtheit hierin eingeschlossen ist.
TECHNISCHES GEBIET
Hierin beschriebene Ausführungsformen betreffen im Allgemeinen Funkzugangsnetze. Einige Ausführungsformen betreffen eine Virtualisierung von Netzwerkfunktionen (NFV - Network Function Virtualization) in Mobilfunknetzen, einschließlich 3GPP LTE (Third Generation Partnership Project Long Term Evolution) -Netzen und LTE-A (LTE Advanced) -Netzen sowie 4G (4^th Generation) - Netzen und 5G/NG (5^th/Next Generation) -Netzen. Einige Ausführungsformen betreffen eine Sicherheitsauthentifizierung für Netzwerke mittels NFV.
ALLGEMEINER STAND DER TECHNIK
Die Verwendung von 3GPP LTE-Systemen (einschließlich LTE- und LTE-Advanced-Systemen) hat sowohl aufgrund eines Anstiegs in den Gerätearten von Benutzergeräten (UEs - User Equipment), die Netzwerkressourcen nutzen, als auch der Datenmenge und Bandbreite, die durch verschiedene Anwendungen, wie z.B. Videostreaming, genutzt werden, die auf diesen UEs arbeiten, zugenommen. Aufgrund dessen werden LTE-Systeme mit dem drahtlosen Kommunikationssystem der nächsten Generation, 5G, weiterentwickelt, um den Zugriff auf Informationen und den Datenaustausch zu verbessern. Das 5G-System versucht, ein einheitliches Netzwerk bereitzustellen, das in der Lage ist, sehr unterschiedliche und gelegentlich einander widersprechende Leistungsdimensionen und Dienste angetrieben durch disparate Dienste und Anwendungen zu erfüllen, während die Kompatibilität mit älteren UEs und Anwendungen aufrechterhalten wird.
Durch den gewaltigen Anstieg in der Zahl und Diversität von Kommunikationsgeräten ist die entsprechende Netzwerkumgebung, einschließlich Routern, Schaltern, Brücken, Gateways, Firewalls und Lastverteilern, zunehmend kompliziert geworden, besonders mit der Einführung von 5G-Systemen. Um die Komplexität der Vielzahl von Diensten, die durch die Netzwerkgeräte bereitgestellt werden, noch zu erhöhen, sind viele physische Implementierungen der Netzwerkgeräte proprietär und sind möglicherweise nicht in der Lage, neue oder angepasste physische Komponenten aufzunehmen, um unterschiedliche Netzwerkbedingungen auszugleichen. Dies hat zur Entwicklung einer Virtualisierung von Netzwerkfunktionen (NFV - Network Function Virtualization) geführt, welche eine virtualisierte Umgebung bereitstellen kann, die in der Lage ist, jegliche Netzwerkfunktion oder jeglichen Dienst, die/der auf universellen Rechnersystemen in einem Datenzentrum bereitgestellt werden kann, als Softwareanwendungen, virtuelle Netzwerkfunktionen (VNF - Virtual Network Functions) genannt, bereitzustellen. Die Verwendung einer NFV kann Flexibilität beim Konfigurieren von Netzwerkelementen bereitstellen, wodurch dynamische Netzwerkoptimierung und eine schnellere Anpassung neuer Technologien ermöglicht werden.
Bestehende Dienstanbieter haben damit begonnen, NFV als Teil eines FaaS (Function As A Service) -Modells auf Universal-Cloud-Implementierungen zu übernehmen. NFV kann, zusätzlich zu ihrer Verwendung durch bestehende Dienstanbieter, auch die Barrieren in den Telekommunikationsmarkt verringern, welche bislang den Eintritt neuer Akteure in die Technologie begrenzt haben. NFV kann Merkmale eröffnen, wie z.B., u.a., die Lieferkette, die Generierung von Einnahmen und die Beschaffung. Mit anderen Worten, mittels NFV entwickeln sich Telekommunikationssysteme weiter, welche eine Generierung von Einnahmen für die DSFC (Distributed Service Function Chaining) -Komponenten aus verschiedenen Quellen, aus denen sich die VNFs zusammensetzen, um NFV-Dienste bereitzustellen, berücksichtigen, managen und ermöglichen können. Die Besonderheit von NFV-Diensten und -Funktionen ist, dass, im Gegensatz zu herkömmlichen Telekommunikationsdiensten und -funktionen, NFV-Dienste und -Funktionen basierend auf der Nachfrage modifiziert (erstellt und eliminiert) werden können.
Die Einführung der 5G-Systeme erschwert die Angelegenheit, da bestehende Telekommunikationssystem-Implementierungen zur Verwendung mit geschlossenen oder streng kontrollierten Telekommunikationssystemen ausgelegt wurden. Das dynamische und verteilte 5G/Edge-Dienstbereitstellungsmodell befindet sich in Entwicklung, durch welches bestehende Implementierungen nicht in der Lage sein werden, sich in dem zerlegten, hyperverteilten NFV-Dienstbereitstellungsmodell zu skalieren oder schlimmer, nicht darin zu funktionieren.
Figurenliste
In den Zeichnungen, welche nicht notwendigerweise maßstabsgetreu gezeichnet sind, können gleiche Ziffern ähnliche Komponenten in unterschiedlichen Ansichten beschreiben. Gleiche Ziffern mit unterschiedlichen Buchstabensuffixen können unterschiedliche Instanzen ähnlicher Komponenten darstellen. Einige Ausführungsformen sind in den Figuren der beigefügten Zeichnungen beispielhaft und nicht einschränkend veranschaulicht, wobei:

1 ein 4G- und 5G-System implementiert durch eine Virtualisierung von Netzwerkfunktionen gemäß einem Beispiel veranschaulicht;
2 eine NFV-Netzwerkmanagementarchitektur in Übereinstimmung mit einigen Ausführungsformen veranschaulicht;
3 ein System zum Implementieren einer Virtualisierung von Netzwerkfunktionen gemäß einem Beispiel veranschaulicht;
4 ein Blockchain-Modell zum Ermöglichen eines verteilten Systems von selbstsouveränen Identitäten in einer Netzwerkfunktion-Virtualisierungsumgebung gemäß einem Beispiel veranschaulicht;
5 einen Evolutionskontext für Telekommunikationsansätze, die zu einer Virtualisierung von Netzwerkfunktionen voranschreiten, gemäß einem Beispiel veranschaulicht;
6 verschiedene Arten von Deskriptoren, die zur Virtualisierung von Netzwerkfunktionen in einem verteilten System von selbstsouveränen Identitäten verwendet werden, gemäß einem Beispiel veranschaulicht;
7 eine verteilte und automatisierte Netzwerkdienstbereitstellung für Netzwerkfunktion-Virtualisierungsdienste gemäß einem Beispiel veranschaulicht;
8 einen Blockchain-basierten Identitätsmanagementfluss gemäß einem Beispiel veranschaulicht;
9 eine Blockchain-Systemimplementierung gemäß einem Beispiel veranschaulicht;
10 ein Blockdiagramm eines Beispiels von Komponenten, die in einem Verarbeitungsgerät vorliegen können, gemäß einem Beispiel ist;
11 ein Blockdiagramm ist, welches ein Beispiel einer Maschine, auf welcher eine oder mehrere Ausführungsformen implementiert sein können, veranschaulicht; und
12 ein Blockdiagramm ist, welches ein Beispiel der Bereitstellung eines Telekommunikationsdienstes gemäß einem Beispiel veranschaulicht.

DETAILLIERTE BESCHREIBUNG
In der folgenden Beschreibung werden Verfahren, Konfigurationen und zugehörige Vorrichtungen zum Bereitstellen von selbstsouveränen Identitäten und Verarbeitungsoperationen innerhalb von NFV- und 5G/Edge-Systemen durch die Verwendung einer Blockchain-Technologie und ähnlicher Identitätsmanagement-Werkzeuge offenbart. Die Verwendung einer einzelnen Identität, die durch die Verwendung einer Blockchain gesichert wird, gestattet das sichere Managen einer NFV-Funktionalität über den gesamten Managementlebenszyklus hinweg. Es werden Ausführungsformen eines Blockchain-Technologie-basierten Systems offenbart, welches die zugrundeliegende Struktur bereitstellen kann, auf welcher NFV oder andere Telekommunikationsdienste und Netzwerkfunktionen dynamisch erstellt, bereitgestellt und gemanagt werden können. Dieser Ansatz ermöglicht eine feine Managementgranularität, einschließlich Lieferkettenmanagement auf jeder Ebene des Managementmodells. Zu den hierin offenbarten Ausführungsformen zählen zum Beispiel Mechanismen zum Managen von Identitäten auf jeder Ebene und in jeder Komponente der Telekommunikationsdienste, Infrastruktur und Ressourcen, wodurch es der NFV ermöglicht wird, als ein offenes Geschäftsmodell zu arbeiten, bei welchem jegliche Entität jegliche Rolle spielen kann.
Wie hierin diskutiert, können die folgenden Techniken auf verschiedene Implementierungen und Vorschläge des NFV-Managements anwendbar sein, wie z.B. die NFV-Identitäts- und Sicherheitsmanagement-Spezifikation veröffentlicht durch die NFV ETSI-ISG (Industry Specification Group) und durch die ETSI-PDL (Permissioned Distributed Ledgers) -ISG. Ein verteiltes, dynamisches Modell der Dienstbereitstellung ist in 5G-Systemen wünschenswert, und die folgende Offenbarung sieht Techniken zum Managen dieser neuen Infrastrukturkomponenten vor. Ein automatisiertes, selbstsouveränes Vertragsmodell kann viele Aspekte von Sicherheit, Authentifizierung, Ressourcennutzung und anderen technischen Problemen innerhalb von NFV-Telekommunikationsimplementierungen unterstützen. Die Anwendbarkeit der folgenden Techniken auf andere Telekommunikationsdienst-Implementierungen und -Systeme wird auch offensichtlich sein.
In einem Beispiel wird die Gemeinschaft der NFV-Anbieter unter Verwendung einer Blockchain (verteiltes Ledger) -Technologie komplett verteilt, bei welcher eine NFV-Orchestrierung, historisch zentralisiert durch Systeme für Management und Netzwerkorchestrierung (MANO - Management and Network Orchestration), gerecht verteilt wird. Wie hierin offenbart, existieren bestimmte Informationen, die in einer Blockchain enthalten sind, als ein/e gemeinsam genutzte/s Datenbank oder Ledger. Die Datenbank oder das Ledger pflegt eine kontinuierlich wachsende Liste von Datensätzen oder Transaktionen, wie z.B. diejenigen, die für NFV verwendet werden. Die NFV-Knoten oder -Server erhalten die Blöcke aufrecht, und jeder Knoten ist in der Lage, die Transaktionsdaten, die in den Blöcken gespeichert werden, zu sehen, wenn sie erstellt werden. Die Datenbank kann somit eine unveränderliche und irreversible Aufzeichnung bilden. Buchungen in das Ledger können möglicherweise nicht überarbeitet oder manipuliert werden - nicht einmal durch die Datenbankbetreiber. Die verteilte Natur des Netzwerks bedeutet, dass Computerserver zu einem Konsens gelangen sollen, welcher es gestattet, dass Transaktionen zwischen unbekannten Parteien stattfinden. Sich widersprechende oder doppelte Transaktionen werden nicht im Datensatz geschrieben und Transaktionen finden automatisch statt.
In einigen Ausführungsformen können NFV-Module durch eine oder mehrere Blockchain-Implementierungen implementiert sein. In einem Beispiel können zu diesen Blockchain-Implementierungen Folgende zählen: a) eine Blockchain für selbstsouveräne Identitäten; b) eine Blockchain für verteilte SF (Service Function) -Kettenverträge; c) eine Blockchain für DSFC (Distributed Service Function Chain) -Workload-Hosting; und d) eine Blockchain für DWH (DSFC Workload Hosting) -Operationen. Andere Verwendungen für derartige Blockchains werden auch offensichtlich sein. Die Blockchain kann ohne oder mit Zugangsbeschränkung arbeiten, in letzterem Fall basiert sie zum Beispiel auf Hyperledger-Frameworks oder Varianten von Ethereum.
Eine selbstsouveräne Identität umschließt im Allgemeinen das Konzept, dass Menschen und Unternehmen ihre eigenen Identitätsdaten auf ihren eigenen Geräten speichern können und die Identitätsdaten an andere Geräte/Systeme bereitstellen können, um die Identitätsdaten zu validieren, ohne einen Zentralspeicher von Identitätsdaten in Anspruch zu nehmen. So stellt die Blockchain für selbstsouveräne Identitäten sicher, dass Identifikatoren, die während der gesamten DSFC-Vergabe- und -Betriebsphase verwendet werden, einmalig sind, das Identitätseigentum bei der anfragenden Entität verbleibt und Identitätsstreitigkeiten ohne das Hinzuziehen einer Zentralbehörde gelöst werden können.
Eine SF-Kette ist eine geordnete Abfolge einzelner Dienstfunktionen, wie z.B. Paketdatennetzwerk-Gateways, Firewalls und Lastverteiler, die einen Dienst bereitstellen. Eine Blockchain für verteilte SF-Kettenverträge kann es jedem NFV-Anbieter ermöglichen, DSFC-Verträge auszustellen, die der Rest der NFV-Gemeinschaft anfragt (darauf bietet), um einige oder alle der in Auftrag gegebenen Komponenten zu liefern. Die DSFC-Blockchain verringert oder eliminiert die Möglichkeit einer Manipulation des Vertragsausschreibungsverfahrens und stellt somit sicher, dass das Vertragsausschreibungsverfahren fair ist.
In einigen Ausführungsformen kann ein DWH (DSFC Workload Hosting) -Vertrag als Reaktion auf einen DSFC-Vertrag bereitgestellt werden. Der DSFC-Vertrag kann Spezifika für den DWH-Vertrag bereitstellen. Der DWH-Vertrag kann das Abgeben von Geboten für Infrastruktur-Anbieter öffnen, die den DSFC-Vertrag hosten können. Ähnlich der DSFC-Blockchain stellt die DWH-Blockchain sicher, dass das Vertragsausschreibungsverfahren fair ist.
Der DWH-Vertrag kann in der Ausführung einer Vielzahl von DWH-Operationen resultieren. Die DWH-Operationen können in einer assoziierten Blockchain aufgezeichnet werden. Die Blockchain für DWH-Operationen kann zum Beispiel die Produktkette, die Regelüberwachung, die Einhaltung der Dienstgütevereinbarung (SLA - Service Level Agreement), die Einhaltung der Dienstgüte (QoS - Quality of Service) und die Einhaltung von Sicherheitsrichtlinien aufzeichnen.
Somit verwenden offenbarte Ausführungsformen eine oder mehrere Blockchains oder andere Ledger als einen verteilten Mechanismus zum Managen von Verträgen, Operationen, Interaktionen und anderen Aspekten von Netzwerkfunktionen und Funktionalität. In einem Beispiel definieren derartige verteilte Verträge die Anforderungen, Funktionalität, Kontrollen und Parameter für die Operation von NFV-Diensten. Im Gegensatz dazu beruht die aktuelle Telekommunikationssystemarchitektur auf einer zentralen Orchestrierungsentität, welche die Kundenbeziehung pflegt und einen Teil der Arbeitslast in Form virtualisierter Netzwerkfunktionen „untervergibt“. Die hierin offenbarten Techniken gestatten das Entfernen der zentralen Entität, indem die zentrale Entität durch eine Dienstvertrag-Orchestrator-Rolle über eine Blockchain, die jeder Teilnehmer am NFV-Ökosystem einnehmen kann, ersetzt wird. Einige der offenbarten Blockchain-Datentechniken können auch in bestehende Telekommunikationssystemansätze integriert werden (z.B. um zuzulassen, dass neue Geräte oder Teilnehmer mit einmaligen Identitäten hinzugefügt und in Telekommunikationsdienste und -funktionen integriert werden).
1 veranschaulicht ein 4G- und 5G-System, das durch eine Virtualisierung von Netzwerkfunktionen implementiert wird, gemäß einem Beispiel. Das System 100 beinhaltet sowohl 4G- als auch 5G-Netzwerkfunktionen. Im 4G-Kernnetzwerk (auch bezeichnet als evolvierter Paketkern (EPC - Evolved Packet Core)) sind Protokoll- und Referenzpunkte für jede Entität definiert, wie z.B. eine Mobilitätsmanagement-Entität (MME - Mobility Management Entity) 122, ein bedienendes Gateway (SGW - Serving Gateway) 124 und ein Paket-Gateway (PGW - Packet Gateway) 126, wobei letzteres in Steuer- und Benutzerebenenfunktionalität aufgeteilt ist. Die 5G-Architektur, wie in 1 gezeigt, beinhaltet mehrere Netzwerkfunktionen (NFs) und Referenzpunkte, welche die Netzwerkfunktionen verbinden. Eine Netzwerkfunktion kann als ein diskretes Netzwerkelement auf einer dedizierten Hardware, als eine Software-Instanz, die auf dedizierter Hardware läuft, oder als eine virtualisierte Funktion, die auf einer geeigneten Plattform, z.B. dedizierte Hardware oder eine Cloud-Infrastruktur, instanziiert ist, implementiert werden.
Im 5G-Netz können die Steuerebene und die Benutzerebene getrennt sein, was eine unabhängige Skalierung und Verteilung der Ressourcen jeder Ebene gestatten kann. Das UE 102 kann entweder mit einem Zugangsnetz oder einem wahlfreien Zugangsnetz (RAN - Random Access Network) 110 verbunden sein und/oder kann mit dem 5G-RAN 130 (gNB) oder einer Zugangs- und Mobilitätsfunktion (AMF - Access and Mobility Function) 142 verbunden sein. Das RAN kann ein eNB oder ein allgemeiner Nicht-3GPP-Zugangspunkt sein, wie z.B. der für Wi-Fi. Das 5G-Kernnetzwerk kann neben der AMF 112 mehrere Netzwerkfunktionen enthalten. Zu den Netzwerkfunktionen können eine Benutzerebenenfunktion (UPF - User Plane Function) 146, eine Sitzungsmanagementfunktion (SMF - Session Management Function) 144, eine Richtlinienkontrollfunktion (PCF - Policy Control Function) 132, eine Anwendungsfunktion (AF - Application Function) 148, eine Authentifizierungsserverfunktion (AUSF - Authentication Server Function) 152 und Benutzerdatenmanagement (UDM - User Data Management) 128 zählen. Die verschiedenen Elemente sind durch die in 1 gezeigten 5G-Referenzpunkte verbunden.
Die AMF 142 kann UE-basierte/s Authentifizierung, Autorisierung, Mobilitätsmanagement usw. bereitstellen. Die AMF 142 kann unabhängig von den Zugangstechnologien sein. Die SMF 144 kann für das Sitzungsmanagement und die Zuweisung von IP-Adressen zu dem UE 102 verantwortlich sein. Die SMF 144 kann auch die UPF 146 für den Datentransfer auswählen und steuern. Die SMF 144 kann mit einer einzelnen Sitzung des UE 102 oder mehreren Sitzungen des UE 102 assoziiert sein. Das heißt, dass das UE 102 mehrere 5G-Sitzungen aufweisen kann. Jeder Sitzung können unterschiedliche SMFs zugewiesen sein. Die Verwendung unterschiedlicher SMFs kann das individuelle Managen jeder Sitzung gestatten. Infolgedessen können die Funktionalitäten jeder Sitzung unabhängig voneinander sein. Die UPF 126 kann mit einem Datennetzwerk verbunden sein, mit welchem das UE 102 kommunizieren kann, indem das UE 102 Uplink-Daten an das Datennetzwerk sendet oder Downlink-Daten von diesem empfängt.
Die AF 148 kann Informationen zum Paketfluss an die PCF 132 bereitstellen, die für die Richtlinienkontrolle verantwortlich ist, um eine gewünschte QoS zu unterstützen. Die PCF 132 kann Mobilitäts- und Sitzungsmanagementrichtlinien für das UE 102 einstellen. Dazu kann die PCF 132 die Paketflussinformationen verwenden, um die geeigneten Richtlinien für einen ordnungsgemäßen Betrieb der AMF 142 und SMF 144 zu bestimmen. Die AUSF 152 kann Daten für die UE-Authentifizierung speichern. Das UDM 128 kann ähnlich die UE-Teilnehmerdaten speichern.
Der gNB 130 kann ein eigenständiger gNB oder ein nicht-eigenständiger gNB sein, der z.B. im DC (Dual Connectivity) -Modus als ein Booster arbeitet, der durch den eNB 110 über eine X2-Schnittstelle gesteuert wird. Zumindest ein Teil der Funktionalität des EPC und des 5G-CN kann gemeinsam genutzt werden (alternativ dazu können separate Komponenten für jede der gezeigten kombinierten Komponenten verwendet werden). Der eNB 110 kann über eine S1-Schnittstelle mit einer MME 122 des EPC verbunden sein und über eine S1-U-Schnittstelle mit einem SGW 124 des EPC 120. Die MME 122 kann über eine S6a-Schnittstelle mit einem HSS 128 verbunden sein, während das UDM über die N8-Schnittstelle mit der AMF 142 verbunden ist. Das SGW 124 kann über eine S5-Schnittstelle mit dem PGW 126 verbunden sein (Steuerebenen-PGW-C über S5-C und Benutzerebenen-PGW-U über S5-U). Das PGW 126 kann als ein IP-Anker für Daten über das Internet dienen.
Das 5G-CN kann wie oben unter anderem eine AMF 142, eine SMF 144 und eine UPF 146 enthalten. Der eNB 110 und der gNB 130 können Daten mit dem SGW 124 des EPC 120 und der UPF 146 des 5G-CN kommunizieren. Die MME 122 und die AMF 142 können über die N26-Schnittstelle verbunden sein, um Steuerinformationen dazwischen bereitzustellen, wenn die N26-Schnittstelle durch den EPC 120 unterstützt wird. In einigen Ausführungsformen können, wenn der gNB 130 ein eigenständiger gNB ist, das 5G-CN und der EPC 120 über die N26-Schnittstelle verbunden sein.
2 veranschaulicht eine NFV-Netzwerkmanagementarchitektur in Übereinstimmung mit einigen Ausführungsformen. Wie veranschaulicht, kann die NFV-Netzwerkmanagementarchitektur 200 eine Reihe von Elementen (von denen jedes physische und/oder virtualisierte Komponenten enthalten kann) beinhalten, einschließlich einer NFV-Infrastruktur (NFVI) 210, Netzwerkelementen (NEs) 290, virtuellen Netzwerkfunktionen (VNFs) 220, einem Domainmanager (DM) 230, einem Elementmanager (EM) 232, einem Netzwerkmanager (NM) 242 und eines/r NFV-Managements und -Orchestrierung (NFV-MANO) 280. Das/die NFV-MANO 280, welche, wie hierin angegeben, durch mehrere NFV-MANO ersetzt sein kann, kann einen virtualisierten Infrastrukturmanager (VIM) 270, einen VNF-Manager (VNFM) 250 und einen Netzwerkfunktion-Virtualisierungsorchestrator (NFVO) 260 umfassen. Der NM 242 kann in einem Betriebsunterstützungssystem/Unternehmensunterstützungssystem (OSS/BSS - Operations Support System/Business Support System) 240 enthalten sein, wobei der DM 230 und der NM 242 das 3GPP-Managementsystem 214 bilden.
Die NFV-Netzwerkmanagementarchitektur 200 kann zum Beispiel durch ein Datenzentrum implementiert werden, welches einen oder mehrere Server in der Cloud umfasst. In einigen Ausführungsformen kann die NFV-Netzwerkmanagementarchitektur 200 ein oder mehrere physische Geräte und/oder eine oder mehrere Anwendungen beinhalten, die, unter anderem, auf einer verteilten Rechnerplattform, einer Cloud-Rechnerplattform, einem zentralisierten Hardwaresystem, einem Server, einem Rechengerät und/oder einem externen Netzwerk-zu-NetzwerkSchnittstellengerät untergebracht sind. In einigen Fällen kann die virtualisierte Ressourcenleistungsmessung zum Beispiel Messungen für Latenz, Jitter, Bandbreite, Paketverlust, Knotenkonnektivität, Berechnung, Netzwerk- und/oder Speicherressourcen, Bilanzierung, Fehler- und/oder Sicherheit beinhalten. Insbesondere können die NEs 290 physische Netzwerkfunktionen (PNF) umfassen, die sowohl Hardware, wie z.B. Prozessoren, Antennen, Verstärker, Sende- und Empfangsketten, als auch Software beinhalten. Die VNFs 220 können in einem oder mehreren Servern instanziiert sein. Jede/r/s aus den VNFs 220, dem DM 230 und den NEs 290 kann einen EM 222, 232, 292 enthalten.
Das/die NFV-Management und -Orchestrierung (NFV-MANO) 280 kann die NFVI 210 managen. Das/die NFV-MANO 280 kann die Instanziierung von Netzwerkdiensten und die Zuweisung von Ressourcen, die durch die VNFs 220 verwendet werden, orchestrieren. Das/die NFV-MANO 280 kann, zusammen mit dem OSS/BSS 240, durch externe Entitäten genutzt werden, um verschiedene NFV-Unternehmensvorteile bereitzustellen. Das OSS/BSS 240 kann die Sammlung von Systemen und Managementanwendungen beinhalten, die ein Dienstanbieter für seine Geschäftstätigkeit verwendet: Kundenmanagement, Bestellungen, Produkte und Einnahmen - zum Beispiel Zahlungs- oder Kontentransaktionen, sowie Telekommunikationsnetzwerkkomponenten und unterstützende Prozesse, einschließlich Netzwerkkomponentenkonfiguration, Netzwerkdienstbereitstellung und Fehlerbehandlung. Das/die NFV-MANO 280 kann eine VNF 220 erstellen oder beenden, die VNF-Kapazität erhöhen oder verringern oder die Software und/oder Konfiguration einer VNF aktualisieren oder erweitern. Das/die NFV-MANO 280 kann einen virtualisierten Infrastrukturmanager (VIM) 270, einen VNF-Manager (VNFM) 250 und einen NFV-Orchestrator (NFVO) 260 beinhalten. Das/die NFV-MANO 280 kann Zugriff auf verschiedene Datenbestände haben, einschließlich Netzwerkdiensten, verfügbaren VNFs, NFV-Instanzen und NFVI-Ressourcen, mit welchen die Ressourcenzuweisung bestimmt werden soll.
Der VIM 270 kann die NFVI-Ressourcen über Nf-Vi-Referenzpunkte innerhalb der Infrastruktur-Subdomäne steuern und managen. Der VIM 270 kann ferner Leistungsmessungen und -ereignisse sammeln und diese über den Vi-VNFM an den VNFM 250 und über Or-Vi-Referenzpunkte an den NFVO 260 weiterleiten. Der NFVO 260 kann für das Managen neuer VNFs und anderer Netzwerkdienste verantwortlich sein, einschließlich dem Lebenszyklusmanagement unterschiedlicher Netzwerkdienste, zu welchen VNF-Instanzen, globales Ressourcenmanagement, Validierung und Autorisierung von NFVI-Ressourcenanfragen und Richtlinienmanagement für verschiedene Netzwerkdienste zählen können. Der NFVO 260 kann die VNFs 220 als Teil von Netzwerkdiensten koordinieren, die gemeinsam eine komplexere Funktion realisieren, einschließlich der gemeinsamen Instanziierung und Konfiguration, des Konfigurierens erforderlicher Verbindungen zwischen unterschiedlichen VNFs 220 und des Managens dynamischer Veränderungen der Konfiguration. Der NFVO 260 kann Orchestrierung über einen OS-Ma-NFVO-Referenzpunkt mit dem NM 242 bereitstellen. Der VNFM 250 kann NFVI-Ressourcen über den VIM 270 orchestrieren und eine Gesamtkoordination und -anpassung von Konfiguration und Ereignisberichterstattung zwischen dem VIM 270 und den EMs und NMs bereitstellen. Ersteres kann das Auffinden zur Verfügung stehender Dienste, das Managen der Verfügbarkeit/Zuweisung/Freigabe virtualisierter Ressourcen und das Bereitstellen des Fehler-/Leistungsmanagements virtualisierter Ressourcen beinhalten. Letzteres kann das Lebenszyklusmanagement beinhalten, welches das Instanziieren einer VNF, das Skalieren und Aktualisieren der VNF-Instanzen und das Beenden des Netzwerkdienstes, das Freigeben der NFVI-Ressourcen für den Dienst an den NFVI-Ressourcenpool, der durch andere Dienste genutzt werden soll, beinhalten kann.
Der VNFM 250 kann für das Lebenszyklusmanagement der VNFs 220 über den Ve-VNFM-VNF-Referenzpunkt verantwortlich sein und kann über den Ve-VNFM-EM-Referenzpunkt eine Schnittstelle zu den EMs 222, 232 bilden. Dem VNFM 250 kann das Management einer einzelnen VNF 220 oder das Management mehrerer VNFs 220 des gleichen Typs oder unterschiedlicher Typen zugewiesen sein. Somit können, obwohl in 2 nur ein VNFM 250 gezeigt ist, unterschiedliche VNFMs 250 mit den unterschiedlichen VNFs 220 für Leistungsmessung und andere Verantwortlichkeiten assoziiert sein. Der VNFM 250 kann eine Reihe von VNF-Funktionalitäten bereitstellen, einschließlich Instanziierung (und Konfiguration, falls erforderlich, durch die VNF-Bereitstellungsvorlage), Software-Update/- Upgrade, Modifikation, horizontaler und vertikaler Skalierung, Sammlung von NFVI-Leistungsmessungsergebnissen und Fehler-/Ereignisinformationen und Korrelation zu VNF-Instanz-bezogenen Ereignissen/Fehlern, Heilung, Beendigung, Lebenszyklusmanagement-Änderungsbenachrichtigung, Integritätsmanagement und Ereignisberichterstattung.
Der VIM 270 kann für die Steuerung und das Management der NFVI-Berechnung, -Speicherung und -Netzwerkressourcen, üblicherweise innerhalb der Infrastrukturdomäne eines Betreibers, verantwortlich sein. Der VIM 270 kann auf die Handhabung einer bestimmten Art von NFVI-Ressource (z.B. nur Berechnung, nur Speicherung, nur Vernetzung) spezialisiert sein oder kann in der Lage sein, mehrere Arten von NFVI-Ressourcen zu managen. Der VIM 270 kann unter anderem die/das Zuweisung/Upgrade/Freigabe/Rückforderung von NFVI-Ressourcen orchestrieren (einschließlich der Optimierung einer derartigen Ressourcennutzung), die Assoziierung der virtualisierten Ressourcen mit den physischen Rechen-, Speicher- und Vernetzungsressourcen managen und die Speicherbestand-bezogenen Informationen von NFVI-Hardware-Ressourcen (Berechnung, Speicherung, Vernetzung) und -Software-Ressourcen (z.B. Hypervisoren) und das Auffinden der Fähigkeiten und Merkmale (z.B. in Bezug auf eine Nutzungsoptimierung) derartiger Ressourcen managen.
Die NFVI 210 selbst kann verschiedene virtualisierte und nicht-virtualisierte Ressourcen enthalten. Dazu können mehrere virtuelle Maschinen (VMs) 212, die Rechenfähigkeiten (CPU) bereitstellen können, ein oder mehrere Arbeitsspeicher 214, die Speicherung entweder auf der Block- oder Dateisystemebene bereitstellen können, und ein oder mehrere Vernetzungselemente 216 zählen, zu welchen Netzwerke, Teilnetze, Anschlüsse, Adressen, Verknüpfungen und Weiterleitungsregeln zum Sicherstellen einer Intra- und Inter-VNF-Konnektivität zählen können.
Jede VNF 220 kann eine Netzwerkfunktion bereitstellen, die von Infrastrukturressourcen (Rechenressourcen, Vernetzungsressourcen, Arbeitsspeicher) entkoppelt ist, welche zum Bereitstellen der Netzwerkfunktion verwendet werden. Obwohl nicht gezeigt, können die VNFs 220 mit anderen VNFs 220 und/oder einer anderen physischen Netzwerkfunktion verkettet sein, um einen Netzwerkdienst zu realisieren. Die virtualisierten Ressourcen können die VNFs 220 mit gewünschten Ressourcen versehen. Die Ressourcenzuweisung in der NFVI 210 kann gleichzeitig zahlreiche Anforderungen und Einschränkungen erfüllen, wie z.B. Verknüpfungen mit niedriger Latenz oder hoher Bandbreite zu anderen Kommunikationsendpunkten.
Die VNFs 220, wie die NEs 290, können durch einen oder mehrere EMs 222, 232, 292 gemanagt werden. Der EM kann Funktionen für das Management virtueller oder physischer Netzwerkelemente bereitstellen, in Abhängigkeit von der Instanziierung. Der EM kann individuelle Netzwerkelemente und Netzwerkelemente eines Teilnetzes managen, zu welchen Beziehungen zwischen den Netzwerkelementen zählen können. Zum Beispiel kann der EM 222 einer VNF 220 für die Konfiguration für die Netzwerkfunktionen, die durch eine VNF 220 bereitgestellt werden, das Fehlermanagement für die Netzwerkfunktionen, die durch die VNF 220 bereitgestellt werden, die Abrechnung für die Nutzung von VNF-Funktionen und das Sammeln von Leistungsmessungsergebnissen für die Funktionen, die durch die VNF 220 bereitgestellt werden, verantwortlich sein.
Die EMs 222, 232, 292 (egal ob in einer VNF 220 oder einem NE 290) können durch den NM 242 des OSS/BSS 240 über Itf-N-Referenzpunkte gemanagt werden. Der NM 242 kann Funktionen mit der Verantwortung für das Management eines Netzwerks bereitstellen, hauptsächlich wie durch den EM 232 unterstützt, kann jedoch auch direkten Zugriff auf die Netzwerkelemente beinhalten. Auf Anforderung des NFVO 260 kann der NM 242 externe VNF-Schnittstellen mit physischen Netzwerkfunktionsschnittstellen verbinden und davon trennen.
Wie oben können die verschiedenen Komponenten des Systems über unterschiedliche Referenzpunkte verbunden werden. Zu den Referenzpunkten zwischen dem/der NFV-MANO 280 und den Funktionsblöcken des Systems können ein Os-Ma-NFVO zwischen dem NM 242 und dem NFVO 260, ein Ve-VNFM-EM zwischen dem EM 222, 232 und dem VNFM 250, ein Ve-VNFM-VNF zwischen einer VNF 220 und dem VNFM 250, ein Nf-Vi zwischen der NFVI 210 und dem VIM 270, ein Or-VNFM zwischen dem NFVO 260 und dem VNFM 250, ein Or-Vi zwischen dem NFVO 260 und dem VIM 270 und ein Vi-VNFM zwischen dem VIM 270 und dem VNFM 250 zählen. Eine Or-Vi-Schnittstelle kann die VNF-Software-Bildmanagement-Schnittstelle und Schnittstellen für das Management virtualisierter Ressourcen, deren Katalog, Leistung und Ausfall auf dem Or-Vi-Referenzpunkt implementieren. Eine Or-Vnfm-Schnittstelle kann eine Management-Schnittstelle für virtualisierte Ressourcen auf dem Or-Vnfm-Referenzpunkt implementieren. Eine Ve-Vnfm-Schnittstelle kann Leistungs-/Fehlermanagement für virtualisierte Ressourcen auf dem Ve-Vnfm-Referenzpunkt implementieren.
3 veranschaulicht ein Beispiel eines Systems zum Implementieren einer Virtualisierung von Netzwerkfunktionen. Das System 300 stellt eine alternative Ansicht des in 2 gezeigten Systems bereit. In einigen Ausführungsformen werden nur Software-Mechanismen verwendet. Es wird verstanden werden, dass das System 300 zur beispielhaften Veranschaulichung der Fähigkeiten und Formen, die eine NFV-Implementierung annehmen kann, bereitgestellt ist, und dass bei der vorliegenden Offenbarung viele Variationen der Struktur und Funktion von NFV-Systemen zum Einsatz kommen können.
Das System 300, wie veranschaulicht, beinhaltet eine NFV-Infrastruktur 302, einen Orchestrator (NFVO) 304, ein OSS/Unternehmensunterstützungssystem (BSS - Business Support System) 306, einen VNFM 308, einen VIM 310 und Netzwerkanalysewerkzeuge 312. Es können auch weniger oder zusätzliche Komponenten in das System 300 integriert sein.
Die NFV-Infrastruktur 302 virtualisiert Netzwerkknotenfunktionen, die miteinander verkettet werden können, um zum Beispiel Kommunikationsdienste zu erstellen. Die NFV-Infrastruktur 302, wie veranschaulicht, beinhaltet die VNFs 316A, 316B, 316C und 316D, einen Schalter/Router 318 und eine Betreiberinfrastruktur 320.
Die VNFs 316A-316D sind virtualisierte Aufgaben, die früher durch dedizierte Hardware ausgeführt wurden. Die VNFs 316A-316D bewegen diese Operationen, die zuvor durch die dedizierte Hardware durchgeführt wurden, zu Software-Instanziierungen. Die VNFs 316A-316D arbeiten auf der Grundlage der Hardware- und/oder Software-Programmierung des Hosts 322.
Der Schalter/Router 318 stellt die Kommunikationsfähigkeit zwischen den Plattformen 326A-326B und/oder den VNFs 316A-316D zur Verfügung. Ein Schalter kann zum Verbinden von Computern oder anderen Netzwerkgeräten verwendet werden. Ein Router kann zum Miteinanderverbinden von Netzwerken verwendet werden, wie z.B. durch das Verbinden eines Netzwerks mit dem Internet. Der Router kann im Allgemeinen einen Datenpfad (z.B., u.a., eine Anfrage, eine Nachricht oder eine Antwort), der an ein anderes Netzwerk bereitgestellt wird, oder zwischen Geräten innerhalb eines Netzwerks managen.
Die Betreiberinfrastruktur 320 kann zum Beispiel die VNFs anderer Betreiber hosten und beinhaltet den Host 322 (z.B. ein Betriebssystem (OS - Operating System), ein Cloud-OS und/oder einen Hypervisor), eine Firmware-Schnittstelle 324 (z.B. eine vereinheitlichte erweiterbare Firmware-Schnittstelle (UEFI - Unified Extensible Firmware Interface) oder ein Basisdatenaustauschsystem (BIOS -Basic Input/Output System)), mehrere Plattformen 326A und 326B (zum Beispiel) und die Zwischenverbindungsschaltungen 328 (z.B. Eingangs-/Ausgangs- (E/A) Anschlüsse, einen Netzwerkschnittstellen-Controller (NIC - Network Interface Controller), einen Schalter, eine Host-Fabric-Schnittstelle (HFI - Host Fabric Interface) oder dergleichen).
Der Host 322 kann Hardware oder Software zum Bereitstellen von Ressourcen beinhalten, die durch die VNFs 316A-316D zum Durchführen ihrer Operationen verwendet werden. Der Host 322 kann ein OS, ein Cloud-OS, einen Hypervisor oder dergleichen beinhalten, auf welchen die VNFs 316A-316D arbeiten können. Die Firmware-Schnittstelle 324 kann eine UEFI (Unified Extensible Firmware Interface), ein BIOS (Basic Input/Output System) oder dergleichen beinhalten. Die Firmware-Schnittstelle 324 definiert eine Software-Schnittstelle zwischen dem Host 322 und der Firmware (z.B. die VNF 316A-316D).
Die Plattform 326A-326B stellt die Kommunikationsfunktionalität für Geräte zur Verfügung, die mit einem Kommunikationsnetzwerk verbunden sind. Zu Beispielen der Benutzerfunktionalität, die durch die Plattform 326A-326B bereitgestellt wird, zählen, u.a., Sprachsitzungen (wie z.B. Internet-Protokoll-Telefonie (VoIP - Voice over Internet Protocol), PTT-Sitzungen, Gruppenkommunikationssitzungen) und Datendienste, wie z.B. Internetzugang und soziale Netzwerkdienste, und Operationen zur Unterstützung des Sprach- und Internetzugangs. Die Plattform 326A beinhaltet einen Arbeitsspeicher 330 (wie auch die Plattform 326B, jedoch ist der Speicher nicht gezeigt, um die Ansicht des Systems 300 nicht zu verdecken). Die Plattformen 326A-326B können durch die Zwischenverbindungsschaltungen 328 kommunikativ gekoppelt sein.
Der NFVO 304 führt eine Ressourcen- und/oder Netzwerkdienst-Orchestrierung durch. Der NFVO 304 bindet Funktionen, die durch die VNFs 316A-316D bereitgestellt werden, um so einen Dienst in einer ansonsten verteilten NFV-Umgebung zu erstellen. Der NFVO 304 kann bei der Sicherstellung helfen, dass angemessene Rechen-, Speicher- und/oder andere Netzwerkressourcen verfügbar sind, um einen Netzwerkdienst bereitzustellen. Der NFVO 304 kann die VNFs 316A-316D, welche die Ressourcen der Infrastruktur 302 gemeinsam nutzen, autorisieren, koordinieren, freigegeben und verwalten.
In einem Beispiel sind das OSS/BSS 306 Computersysteme, die durch Telekommunikationsdienstanbieter zum Managen ihrer Netzwerke verwendet werden. Das OSS/BSS 306 kann Netzwerkinventarisierung, Konfiguration, Fehlermanagement und/oder Dienstbereitstellung unterstützen.
Der VNFM 308 arbeitet mit dem NFVO 304 und dem VIM 310 zum Bereitstellen von VNF-Fähigkeit. Der VNFM 308 kann die VNFs 316A-316D instanziieren, die VNFs 316A-316D skalieren, die VNFs 316A-316D aktualisieren und/oder erweitern und/oder die VNFs 316A-316D beenden. Der VNFM 308 kann eine einzelne VNF oder mehrere VNFs managen. Der VNFM 308 pflegt die virtualisierten Ressourcen, welche die VNF 316A-316D unterstützen.
Der VIM 310, wie veranschaulicht, beinhaltet einen Controller für die Software-definierte Vernetzung (SDN - Software-Defined Networking) 314. Der VIM 310 steuert und managt Rechen-, Speicher- und andere Netzwerkressourcen der Infrastruktur 302. Der VIM 310 kann Infrastruktur in einer oder mehreren Infrastrukturen handhaben, und kann z.B. die Infrastruktur 302 beinhalten. Der VIM 310 kann eine Liste pflegen, welche virtuellen Ressourcen welchen physischen Ressourcen zugewiesen sind, Sicherheitsgruppenrichtlinien (für die Zugangskontrolle) managen, einen Bestand von NFV-Hardware-Ressourcen und -Software-Ressourcen managen, um so beim Verbessern und Optimieren der Verwendung von Systemressourcen zu helfen.
Der SDN-Controller 314 ist eine Anwendung, welche die Flussteuerung, wie z.B. innerhalb von Netzwerken, managt. Der SDN-Controller 314 gestattet einem Server oder einer anderen Netzwerkressource das Auswählen eines Paketvermittlungsziels, welches einem Schalter anzeigt, wohin ein Paket gesendet werden soll. Der SDN-Controller 314 kann eine Steuerebene von Netzwerk-Hardware verwenden und sie als Software laufen lassen. Der SDN-Controller 314 kann Überwachungsrichtlinien verteilen.
Die Netzwerkanalysewerkzeuge 312 können Funktionalität zum Analysieren von Telemetriedaten bereitstellen, wie z.B. NSM-Funktionalität. Zu den Netzwerkanalysewerkzeugen 312 können die virtuelle EPC (vEPC), vCPE (virtual Customer-Premises Equipment - virtuelle Teilnehmernetzgeräte) -NFV-Analytik, Datenspeicherung, Netzwerkanomalie-Erkennung und/oder Malware-Erkennung oder dergleichen zählen.
Der Verkehr der Netzwerksicherheitsüberwachung (NSM - Network Security Monitoring) wird durch die Pfeile 332, 334, 336 und 338 angegeben. Der Fluss dieses NSM-Verkehrs kann durch hierin diskutierte Ausführungsformen „beschleunigt“ werden. Der SDN-Controller 314 des VIM 310 kann eine Richtlinie an die VNF 316D bereitstellen (z.B. eine Sicherheitsüberwachungs- (SecMon - Security Monitoring) VNF), wie durch eine Kombination der Pfeile 338 und 332 angegeben. Der Verkehr, der an die VNF 316D bereitgestellt wird, kann sicher beendet werden. Die VNF 316D kann Verkehr (z.B. den gesamten Verkehr) am Schalter/Router 318 überwachen (wie durch den Pfeil 332 angegeben). Die VNF 316D kann eine bereitgestellte Überwachungsrichtlinie auf den Verkehr anwenden. Die VNF 316D stellt, basierend auf der Überwachungsrichtlinie, überwachten Verkehr an die Zwischenverbindungsschaltungen 328 bereit (wie durch den Pfeil 334 oder die Pfeile 340 und 338 angegeben). Die Zwischenverbindungsschaltungen 328 stellen den überwachten Verkehr an die Netzwerkanalysewerkzeuge 312 bereit, wie durch den Pfeil 336 angegeben. Zu den Netzwerkanalysewerkzeugen 312 können Sicherheits- und Vernetzungsanalysesysteme, Metadatensammler, Netzwerkprofilerstellungs-, Pro-Mandant- und/oder Pro-Fluss-Überwachungssysteme und/oder andere Mandantenüberwachungssysteme zählen.
Die folgenden Techniken können zum Dezentralisieren der NFV-Infrastruktur zum Bereitstellen von Netzwerkdiensten über Funktionsvirtualisierung und über das Management der NFV-Operationen verwendet werden. In einem Beispiel können vier Blockchains (oder mindestens eine einzelne Blockchain mit vier unterschiedlichen Betriebsfunktionen) verwendet werden, um sichere, faire und zuverlässige Interaktionen zwischen Teilnehmern des Ökosystems zu ermöglichen.
4 veranschaulicht ein Blockchain-Modell zum Ermöglichen eines verteilten Systems selbstsouveräner Identitäten in einer Netzwerkfunktion-Virtualisierungsumgebung. Wie oben wird eine DSFC zum Erfassen der Besonderheiten der Dienstart und der Dienstgüte, die durch den DSFC-Vertragsinitiator gewünscht werden, verwendet, welcher dann die DSFC mit einer Blockchain-Identität assoziiert. Die Blockchain-Identität kann eine Blockchain für DSFC-Verträge sein. Der DSFC-Vertrag kann eine einmalige ID aufweisen, die einer Blockchain für selbstsouveräne Identitäten zur Verfügung gestellt wird. In einigen Ausführungsformen kann die DSFC in Form eines elektronischen Vertrages (E-Vertrag) erfasst werden.
Der DSFC-Vertrag kann über eine Broadcast-Benachrichtigung an Verkäufer (oder Dienstanbieter-Entitäten) verbreitet werden, kann direkt nur an diejenigen Verkäufer übertragen werden, die sich für das Empfangen von Benachrichtigungen über eine neue DSFC oder eine DSFC mit einer bestimmten Art/QoS angemeldet haben, oder kann gepostet werden, damit jeder Verkäufer entscheiden kann, ob er/sie einen bestimmten DSFC-Vertrag eingehen möchte oder nicht.
In einigen Ausführungsformen kann jeder Verkäufer, der einen Endnutzer-Kundenstamm aufrechterhält, Gebote für einen DSFC-Vertrag initiieren, indem er/sie Gebote an die DSFC-Blockchain abgibt. Die Gebote können eine Bieter-ID beinhalten, welche auch an die Blockchain für selbstsouveräne Identitäten bereitgestellt wird und schließlich, im Falle einer Annahme, mit der DSFC-Vertrags-ID assoziiert wird. Auf DSFC-Verträge kann durch Dienstanbieter-Entitäten geboten werden, welche zumindest einen Teil des Vertrages (oder den gesamten Vertrag) erfüllen können.
Der DSFC-Vertragsinitiator wählt den/die Verkäufer, der/die den DSFC-Vertrag erfüllen wird/werden, unter Verwendung der Blockchain für DSFC-Verträge aus. Die Auswahl kann unter anderem basierend auf rein rentablen Maßnahmen durch den/die Verkäufer, zufällig unter den Verkäufern, basierend auf der geringsten Anzahl von Verkäufern zum Erfüllen des DSFC-Vertrages oder durch eine vorbestimmte Priorisierung unter den Verkäufern erfolgen.
Wie gezeigt verwenden die DSFC-E-Verträge, -Initiatoren und -Bieter in einigen Ausführungsformen die Blockchain für selbstsouveräne Identitäten zum Ausstellen von Identifikatoren an die ausgewählten Teilnehmer, derart, dass eine potentielle Disputation hinsichtlich Dienstdefinition, Laufzeiten, Bedingungen, Anbietern und allem, was eine eindeutig zugeordnete Identität erfordert, mit eindeutigem Vorrang (in der Zeit) und mit sicherem (manipulationsgeschütztem) Produktkettennachweis etabliert werden kann.
Die zweite Phase der verteilten NFV ist die DWH-Vertragsverhandlung. Während der DWH-Vertragsverhandlung wird der Vertrag der vorherigen Phase (der den bereitzustellenden Dienst definiert) mit einer Dienstbereitstellungsinfrastruktur abgeglichen, welche die Hosting-Anforderungen erfüllen kann. Die zweite Runde von DWH-Verträgen ist wieder offen für alle Bieter, einschließlich denjenigen, die möglicherweise am Erhalt des DSFC-Vertrages beteiligt waren. Als letzten Schritt zu einem Blockchain-E-Vertrag-Ausführungsplan wählt der Vertragsinitiator das Team aus, das den DWH-Vertrag zu seiner Zufriedenheit erfüllen wird.
Die dritte Phase ist die DWH-Ausführung, bei welcher der DWH- und der DSFC-Vertrag umgesetzt werden. Während des Betriebs werden Telemetriedaten gesammelt, welche über eine tatsächliche Dienstbereitstellungserfahrung berichten (zum Beispiel die Varianz, mit welcher SLAs erfüllt werden). Der Dienstvertrags-Orchestrator verifiziert, dass der DWH-Vertrag vertragsgemäß ausgeführt wird und dass Teilnehmer entsprechend aus den elektronischen Geldbörsen (E-Wallets) der Kunden bezahlt werden.
5 veranschaulicht einen Evolutionskontext für Telekommunikationsansätze, welche zu einer Virtualisierung von Netzwerkfunktionen voranschreiten. Das NFV-Ökosystem ist komplex und weist viele Komponenten und Teilsysteme auf. Es handelt es sich dabei um ein Ökosystem, das sich bereits auf dem Weg in Richtung eines offeneren Marktplatzes befindet, der für viele Jahre durch ein paar wenige Telekommunikationsakteure dominiert wurde.
Die drei Phasen der NFV-Evolution sind in 5 gezeigt. Die erste Phase ist im Wesentlichen ein geschlossenes System. Die zweite Phase gestattet, dass Teile des Netzwerkfunktion-Virtualisierungsstapels für VNF-Anbieter geöffnet werden, die miteinander konkurrieren, um eine bessere „Funktion“ bereitzustellen, wobei jedoch „Funktionen“ zentral orchestriert werden - üblicherweise durch einen Telekommunikationsanbieter.
Die dritte Phase verteilt auch die Orchestrierung. Mit dieser Änderung kann sich jeder Akteur des NFV-Ökosystems am Wettbewerb um die Bereitstellung jeglicher oder sämtlicher Komponenten und Dienste beteiligen.
6 veranschaulicht verschiedene Arten von Deskriptoren, die für die Virtualisierung von Netzwerkfunktionen in einem verteilten System von selbstsouveränen Identitäten verwendet werden. In einem Beispiel werden neue NFV-Deskriptoren (hinzugefügt zu dem vorhandenen Satz von Netzwerkdienst-Deskriptoren) zum Erweitern von Verträgen (z.B. NFV-Deskriptoren) für die vollständig verteilte Blockchain verwendet.
Diese Auflistung von Deskriptoren zeigt die Mustervertragsstrukturen, die auf jeder der Ebenen in dem Prozess implementiert werden können. Aktuelle ETSI-NFV-Standards (z.B. die ETSI-NFV-MAN0001-Spez.) beschreiben die verschiedenen vorhandenen Deskriptoren (wobei es sich um Datenstrukturen handelt, die Parameter enthalten) für bestehende Dienste. Zumindest einige der Deskriptoren können innerhalb von ETSI-NFV-definierten Protokollen sowie den hierin angegebenen Erweiterungen bereitgestellt werden.
Mit der vorliegenden Konfiguration können zusätzliche Verträge und Erweiterungen zu den vorhandenen Deskriptoren hinzugefügt werden. Diese Verträge können durch entsprechende Partner des Ökosystems veröffentlicht werden, und diese Transaktionen werden in die verschiedenen Blockchains hinzugefügt und für die Veröffentlichung von selbstsouveränen Identitäten und das vollständige Lieferkettenmanagement (Rechnungslegung, Lebenszyklusmanagement, horizontale Skalierung usw.) verwendet. Die neuen Deskriptoren und Erweiterungen beziehen sich auf den Orchestrator und die Ressource. Insbesondere kann der Orchestrator-Deskriptor wie gezeigt unter anderem Informationen des Basiselements, wie z.B. die ID, den Verkäufer, die Dienstvertrags-ID, finanzielle Bedingungen usw., eine Netzwerkdienstliste (NS1, NS2, ... NSn), SLA-Informationen (z.B. Leistungsanforderungen, Sicherheitsanforderungen, Bandbreiten- und Latenzanforderungen, Transaktionen usw.) enthalten. Der Netzwerkdienst-Deskriptor kann eine Erweiterung für den Orchestrator-Deskriptor beinhalten, die unter anderem die Orchestrator-Deskriptor-ID, SLA-Parameter, finanzielle Bedingungen usw. beinhaltet. Der neue Ressourcen-Deskriptor kann die Art der Ressource (z.B. Plattform, Rahmen, CPU, Arbeitsspeicher, Vernetzung, Speicher), Basiselementinformationen (z.B. ID, Verkäufer, Ressourcenparameter (z.B. IA, ISA, SGX, QAT, RDT, KPT, MKTME), Überwachungs-/Telemetriedetails, IDs der Komponenten usw., Ressourcendetails (z.B. ID, Parameter), Netzwerkdienst-ID, SLA-Parameter, finanzielle Bedingungen usw. angeben.
7 veranschaulicht eine verteilte und automatisierte Netzwerkdienstbereitstellung für Netzwerkfunktion-Virtualisierungsdienste. Spezifisch veranschaulicht diese Figur die automatisierte Bereitstellung von NFV/SDN/5G-Diensten in einer vollständig verteilten Architektur, die mehrere Schichten beinhaltet - welche als komplett autonome und unabhängige Teilsysteme arbeiten.
In einem Beispiel können Dienstverträge durch den Dienstanbieter erzeugt werden, wodurch die Funktionalität auf traditionelle Telekommunikationsanbieter erweitert wird und neuere Internetdienstanbieter-Entitäten in die Inhalts- und Dienstbereitstellung einsteigen können. Diese Verträge werden in die Blockchains veröffentlicht und durch einen oder mehrere der verteilten, autonomen Orchestratoren orchestriert, welche Verträge ausstellen, die durch die Netzwerkdienst-Orchestratoren (NS-Orch - Network Services Orchestrators) weiter bedient werden. Ebenso werden die Netzwerkdienstverträge durch die Ressourcen-Orchestratoren betreut. Auf jeder Ebene werden der Vertrag und die Bereitstellung der nächsten Ebene durch die mehreren Blockchains gemanagt (z.B. in der in 4 angegebenen Konfiguration).
8 veranschaulicht einen beispielhaften Blockchain-basierten Identitätsmanagementfluss, der zur Identitätserstellung und Blockchain-basierten Verifizierung und Aufzeichnung in die Identitäts-Blockchain verwendet wird (z.B. für eine Identitäts-Blockchain wie unter Bezug auf 4 veranschaulicht und diskutiert). In einem Beispiel kann das Verfahren Folgendes beinhalten:
1. Erstellung der Instanz eines Dienstes, einer Dienstfunktionskette, einer VNF, einer FaaS, einer Ressource, einer Hardware-Enklave oder virtualisierten Partition, eines Containers oder jeglicher anderen Komponenteninstanz.
2. Diese Instanzen erstellen einen selbsterzeugten Identifikator (z.B. eine global eindeutige ID (GUID - Globally Unique ID) oder eine Zufallszahl), der zusammen mit dem kryptografischen Hash der Instanz, dem Krypto-Hash der Anfangskonfiguration und dem Krypto-Hash des Identifikators zusammen krypto-gehasht und für eine Blockchain-Verarbeitungsoperation übermittelt wird.
3. Die Blockchain-Miner verifizieren jede Operation und prüfen im Fall des Identifikators, ob die gleiche Identität nicht schon zuvor übermittelt und in die Blockchain aufgenommen wurde. Im Fall eines Konflikts wird die Operation neu gestartet.
4. Nach Aufnahme in die Blockchain steht die Identität für öffentliche Nutzungen zur Verfügung, einschließlich Rechnungslegung, Überwachung, Leistungsverfolgung, SLA-Durchsetzungen, regulatorischer Zwecke, wie rechtmäßiges Abfangen und Datenschutz, usw. Es können auch viele weitere Nutzungen zur Anwendung kommen.
In einem Beispiel kann der Fluss von 8 für das Management oder die Verfolgung des vollen Lebenszyklus von Instanzen angepasst werden, einschließlich des Zeitpunkts ihrer Erstellung und Destruktion und ihrer Verwendung. Dies ist von Nutzen für die horizontale Skalierung von Diensten basierend auf einer dynamischen Nachfrage und das Konfigurationsmanagement der Instanzen - einschließlich der Verfolgung von Instanzbild-Aktualisierungen, Aktualisierungen der Konfiguration (z.B. Netzwerk-Hash-Tabellen, Netzwerkrichtlinien, Paketnetzrouten-Aktualisierungen usw.). Diese Konfiguration ist an die Identität der Instanz gebunden.
In einem Beispiel kann der Fluss von 8 auch zum Verfolgen der Ressourcennutzung und -ladung anwendbar sein, einschließlich Plattform- und Hardware-/Siliziumkomponenten, wie z.B. CPUs, virtueller CPUs, Arbeitsspeicher (DIMMS, Intel 3DXP usw.), Speicher, programmierbarer und ASIC-Beschleuniger (Deep-Learning, künstliche Intelligenz (KI), feldprogrammierbarer Gate-Arrays (FPGAs - Field Programmable Gate Arrays) usw.), Netzwerkbeschleuniger (Intel QuickAssist Crypto-Beschleuniger, Komprimierung) und Schlüsselschutz und Sicherheit (Intel KPT (Key Protection Technology), SGXs (Software Guard Extensions), MKTME (Multi-Key Total Memory Encryption)). Die spezifischen Nutzungen und Verwendungszeiten werden gemäß dem Verfahrensfluss gemanagt.
9 veranschaulicht eine beispielhafte Blockchain-Systemimplementierung, die mit den gegenwärtig offenbarten Techniken oder mit ähnlichen Ansätzen einsetzbar ist. Wie verstanden wird, ist eine Blockchain eine verteilte Datenbank (z.B. ein verteiltes Ledger), die eine wachsende Liste von Datensätzen pflegt, die gegen Manipulation und Überarbeitung geschützt sind. Eine Blockchain beinhaltet „Blöcke“, welche Daten oder sowohl Daten als auch Programme enthalten. Jeder Block enthält Posten einzelner „Transaktionen“ zwischen Blockchain-Teilnehmern. Jeder Block beinhaltet einen Zeitstempel und Verknüpfungsinformationen (üblicherweise einen Hash-Wert), welche den aktuellen Block mit dem vorhergehenden Block verknüpfen; die Verknüpfungsinformationen gestatten eine Durchquerung der Blockchain (in jeder Richtung).
Blockchain-Transaktionen sind mit Hilfe eines verteilten Hashing-Algorithmus, der erfordert, dass jeder Transaktionsprozessor (z.B. ein „Miner“) dem nächsten Block in der Blockchain zustimmt, integritätsgeschützt. Integrität wird durch einen Konsens mehrerer Miner erreicht, wobei jeder Miner Zugriff auf seine eigene Kopie des Ledgers hat. Wenn sich eine Mehrheit der Miner über den Inhalt des Ledgers einig ist, dann wird dieser vereinbarte Inhalt zur „Wahrheit“ für das Ledger; die Miner, die nicht zustimmen, akzeptieren die Wahrheit der Mehrheit (ansonsten wären sie nicht in der Lage zu funktionieren). Die Integrität kann belegt werden, weil ein Angreifer eine Mehrheit von Minern beeinträchtigen und deren Kopien des Ledgers modifizieren müsste; dies ist extrem schwierig (wenn nicht gar unmöglich).
In einem Beispiel kann die Blockchain-Implementierung Verwendungstransaktionen, die unter Teilnehmern durchgeführt werden, beinhalten, um, unter Verwendung von Informationen, die in die Blockchain geschrieben werden, Zero-Knowledge-Commitments und einen Zero-Knowledge-Beweis der Kenntnis oder der Verifizierung zu ermöglichen. Derartige Techniken können erweiterten Datenschutz von Daten gestatten, die in Verbindung mit NFV-Operationen in die Blockchain geschrieben werden (um z.B. Details von Verträgen oder Netzwerkteilnehmern geheim zu halten). In einem Beispiel beinhaltet ein in diesem Szenarium angewandter Zero-Knowledge-Beweis die Schritte - (1) Übergeben geheimer Daten an die Blockchain und (2) Kenntnisbeweis der geheimen Daten mit Hilfe eines kryptografischen Protokolls.
Als ein spezifisches Beispiel eines kryptografischen Protokolls kann zum Erstellen eines Beweises einer Information (wie z.B. ein Identifikator m, den ein neues Gerät kennt) ein neues Gerät ein Pedersen-Commitment in der Form $M = g_{1}^{m} h_{m}^{r}$
erstellen, wobei r ein Zufallswert ausgewählt durch den Benutzer ist und g₁ und h₁ öffentliche Parameter des Registrators sind. Dieses Commitment wird in der Blockchain registriert. Bei der Registrierung signiert die Blockchain das Commitment mit M, um σ=M^χ als die Signatur auszugeben, wobei χ der geheime Schlüssel der Blockchain ist (wie z.B. eine halb-zugangsbeschränkte Blockchain, wie z.B. ChainAnchor, welche eine Identitäts- und Datenschutz-erhaltende Schicht über der Blockchain hinzufügt.
In einem Beispiel funktioniert ein Zero-Knowledge-Beweis der Kenntnis oder der Verifizierung wie Folgt. Dabei sollen σ₁,σ₂,...,σ_r die Signaturen sein, welche den Identifikatoren entsprechen, die dem Besitzer des neuen Gerätes durch das Gerät bewiesen werden müssen. Zum Zeitpunkt der Registrierung aggregiert das Gerät die Signaturen zu $σ \prod_{i = 1}^{l} σ_{i},$
wobei σ_i die Signatur des übergebenen Wertes $M_{i} = g_{l}^{m_{i}} h_{I}^{r_{i}}$
ist. (Hinweis - dies kann nur eine Signatur sein, wenn nur ein geheimer Identifikator bewiesen werden muss. In Fällen, in welchen die Registrierung nicht nur eine Identität, sondern auch andere Attribute erfordert, kann dies jedoch auf einen Satz von Attributen verallgemeinert werden). Diese Attribute sind als Teil des Zero-Knowledge-Beweises enthalten, um Informationslecks zu vermeiden, während die Registrierungsprüfung erfüllt wird.
Das neue Gerät berechnet dann $M = \prod_{i = 1}^{l} M_{i} = g_{1}^{m_{1} + \dots + m_{l}} h_{1}^{r_{1} + \dots + r_{l}}$
Der Benutzer sendet σ,M,M_i, 1≤i≤t an den Verifizierer. Als einen nächsten Schritt führen das neue Gerät und der Verifizierer das folgende ZKPK-Protokoll aus (wobei griechische Buchstaben Quantitäten bezeichnen, deren Kenntnis bewiesen wird, wohingegen sämtliche anderen Parameter an den Verifizierer gesendet werden): $P K {(α,β) : M = g_{1}^{α} h_{1}^{β}, α,β \in Ζ_{q}}$
Nachdem der Verifizierer den Zero-Knowledge-Beweis der Commitments akzeptiert hat, prüft er, ob die folgenden Verifizierungen erfolgreich sind: $M = \prod_{i = 1}^{l} M_{i} und e (σ, g_{2}) e = (M, v),$
wobei g₂ ein öffentlicher Parameter ist, v der öffentliche Schlüssel des Registrators ist und e eine bilineare Abbildung ist. Wenn der letzte Schritt erfolgreich ist, akzeptiert der Verifizierer den ZKPK der unterzeichneten Commitments.
Wie oben verwendet jede Entität in einem NFV- und 5G-System eine Identität. Die Entitäten selbst können dynamisch sein, d.h. nach Bedarf instanziiert, angehalten und geschlossen werden, oder weniger dynamisch sein, wie z.B. Plattformen, Firmware, OSs, Speicher, Netzwerke. Die Entitäten können Software, Firmware, Hardware oder Kombinationen davon sein. Die Entitäten können auch Dienste sein: Netzwerk-, Orchestrierungs-, Unternehmens- oder Teildienste. Die Entitäten können mittels einer komplexen Lieferkette durch mehrere Verkäufer bezogen werden. Die Entitäten können durch mehrere Konsumenten konsumiert werden und über mehrere Möglichkeiten abgerechnet werden. Zum Implementieren der Blockchain kann die DSFC in einer ersten Phase die Dienstart und -qualität in einem E-Vertrag erfassen. Der Dienstvertrag kann erstellt und an die Blockchain veröffentlicht werden. In einer zweiten Phase kann auf DWH-Verträge, die VNFs beinhalten, automatisch geboten werden und diese nach den Anforderungen abgeglichen werden. Die Verträge können durch einen oder mehrere von verteilten Netzwerkdienst-Orchestratoren weiterverarbeitet und in die Blockchain veröffentlicht werden. In einer dritten Phase werden die DSFC- und DWH-Verträge umgesetzt und können durch Systemtelemetrie verifiziert werden. Die Verträge können durch einen oder mehrere verteilte Netzwerkdienst-Orchestratoren und Ressourcen-Orchestratoren weiterverarbeitet und in Blockchains veröffentlicht werden. Die Verträge können durch die Blockchains bereitgestellt, umgesetzt, gemanagt, anhand der SLA geprüft und abgerechnet werden. Mindestens vier separate Blockchains, oder eine mit vier unterschiedlichen Betriebsfunktionen, können verwendet werden, um sichere, faire und zuverlässige Interaktionen zwischen Partnern des Ökosystems zu ermöglichen.
In verschiedenen Beispielen können die hierin beschriebene/n Operationen und Funktionalität durch ein elektronisches Gerät verkörpert sein, innerhalb welchem ein Satz oder eine Abfolge von Anweisungen ausgeführt werden kann, um das elektronische Verarbeitungssystem zum Durchführen einer beliebigen der hierin diskutierten Vorgehensweisen gemäß einer Beispielausführungsform zu veranlassen. Die Maschine kann eine Maschine sein, die durch Aspekte eines PCs, eines Tablet-PCs, eines PDAs (Personal Digital Assistant), eines Mobiltelefons oder Smartphones, eines IoT (Internet of Things) -Gerätes, eines Netzwerk-Gateways, eines Schalters oder einer Brücke, eines Servers oder eines Cluster-basierten Systems oder jeglicher Maschine, die zum Ausführen von Anweisungen (sequentiell oder anderweitig) in der Lage ist, die Aktionen spezifizieren, die durch diese Maschine vorgenommen werden sollen, verkörpert ist. Ferner soll, während nur eine einzelne Maschine dargestellt sein kann und in dem Beispiel oben nur auf eine einzelne Maschine Bezug genommen sein kann, eine derartige Maschine auch jegliche Sammlung von Maschinen beinhalten, die einzeln oder gemeinsam einen Satz (oder mehrere Sätze) von Anweisungen zum Durchführen jeglicher einen oder mehreren der hierin diskutierten Vorgehensweisen ausführen. Ferner sollen diese und ähnliche Beispiele eines Prozessor-basierten Systems jeglichen Satz von einer oder mehreren Maschinen beinhalten, der durch einen Prozessor (z.B. einen Computer) zum einzelnen oder gemeinsamen Ausführen von Anweisungen zum Durchführen jeglicher einen oder mehreren der hierin diskutierten Vorgehensweisen gesteuert oder betrieben wird.
10 ist ein Blockdiagramm eines Beispiels von Komponenten, die in einem Verarbeitungsgerät 1050 zum Implementieren der hierin beschriebenen Techniken vorliegen können. Das Gerät 1050 kann jegliche Kombinationen der Komponenten beinhalten, die in dem Beispiel gezeigt sind oder auf die in der Offenbarung oben Bezug genommen wird. Die Komponenten können als integrierte Schaltungen (ICs), Abschnitte davon, diskrete elektronische Geräte oder andere Module, Logik, Hardware, Software, Firmware oder eine Kombination davon, die in dem Gerät 1050 angepasst ist, oder als Komponenten, die anderweitig innerhalb eines Chassis eines größeren Systems eingeschlossen sind, implementiert sein. Außerdem soll das Blockdiagramm von 10 einen allgemeinen Überblick über Komponenten des Gerätes 1050 zeigen. Jedoch können in anderen Implementierungen einige der gezeigten Komponenten weggelassen sein, zusätzliche Komponenten können vorliegen und es kann eine unterschiedliche Anordnung der gezeigten Komponenten vorgenommen werden.
Das Gerät 1050 kann einen Prozessor 1052 beinhalten, bei welchem es sich um einen Mikroprozessor, einen Mehrkernprozessor, einen Multithread-Prozessor, einen ULV (Ultra-Low Voltage) -Prozessor, einen eingebetteten Prozessor oder ein anderes bekanntes Verarbeitungselement handeln kann. Der Prozessor 1052 kann ein Teil eines Ein-Chip-Systems (SoC - System on a Chip) sein, in welchem der Prozessor 1052 und andere Komponenten in eine einzelne integrierte Schaltung oder ein einzelnes Paket, wie z.B. die Edison™ oder Galileo™ SoC-Boards von Intel, geformt werden. Als ein Beispiel kann der Prozessor 1052 einen Intel® Architecture Core™-basierten Prozessor, wie z.B. einen Quark™-, einen Atom™-, einen i3-, einen i5-, einen i7-Prozessor oder einen Prozessor der MCU-Klasse, oder einen anderen derartigen Prozessor, der von der Intel® Corporation, Santa Clara, Kalifornien erhältlich ist, beinhalten. Jedoch kann auch eine ganze Reihe anderer Prozessoren verwendet werden, wie sie z.B. von der Advanced Micro Devices, Inc. (AMD) in Sunnyvale, Kalifornien verfügbar sind, ein MIPS-basiertes Design von der MIPS Technologies, Inc. in Sunnyvale, Kalifornien, ein ARM-basiertes Design lizenziert von der ARM Holdings, Ltd. oder deren Kunden oder deren Lizenznehmern oder Anwendern. Die Prozessoren können Einheiten wie z.B. einen A5-A12-Prozessor von der Apple® Inc., einen Snapdragon™-Prozessor von der Qualcomm® Technologies, Inc. oder einen OMAP™-Prozessor von der Texas Instruments, Inc. beinhalten.
Der Prozessor 1052 kann über eine Zwischenverbindung 1056 (z.B. einen Bus) mit einem Systemspeicher 1054 kommunizieren. Es kann jegliche Zahl von Speichergeräten zum Einsatz kommen, um für eine gegebene Menge von Systemspeicher zu sorgen. Als Beispiele kann der Speicher Direktzugriffspeicher (RAM - Random Access Memory) in Übereinstimmung mit einem JEDEC (Joint Electron Devices Engineering Council) -Design sein, wie z.B. die DDR- oder Mobile-DDR-Standards (z.B. LPDDR, LPDDR2, LPDDR3 oder LPDDR4). In verschiedenen Implementierungen können die einzelnen Speichergeräte jegliche unterschiedlichen Pakettypen aufweisen, wie z.B. SDP (Single Die Package), DDP (Dual Die Package) oder Q17P (Quad Die Package). Diese Geräte können in einigen Beispielen direkt auf eine Hauptplatine gelötet sein, um eine Lösung mit einem niedrigeren Profil bereitzustellen, während die Geräte in anderen Beispielen als ein oder mehrere Speichermodule konfiguriert sind, die wiederum durch ein gegebenes Verbindungselement mit der Hauptplatine gekoppelt sind. Es können auch jegliche anderen Speicherimplementierungen zum Einsatz kommen, wie z.B. andere Arten von Speichermodulen, z.B. DIMMs (Dual Inline Memory Modules) unterschiedlicher Varietäten, einschließlich, jedoch nicht darauf beschränkt, Mikro-DIMMs oder Mini-DIMMs.
Um für eine dauerhafte Speicherung von Informationen, wie z.B. Daten, Anwendungen, Betriebssystemen und so weiter, zu sorgen, kann über die Zwischenverbindung 1056 auch ein Speicher 1058 an den Prozessor 1052 gekoppelt sein. In einem Beispiel kann der Speicher 1058 über ein Festkörper-Festplattenlaufwerk (SSDD - Solid State Disk Drive) implementiert sein. Zu anderen Geräten, die für den Speicher 1058 verwendet werden können, zählen Flash-Speicherkarten, wie z.B. SD-Karten, Mikro-SD-Karten, xD-Bildkarten und dergleichen, und USB-Flash-Laufwerke. Bei energiesparenden Implementierungen kann der Speicher 1058 ein auf dem Chip integrierter Arbeitsspeicher oder Register im Zusammenhang mit dem Prozessor 1052 sein. Jedoch kann der Speicher 1058 in einigen Beispielen auch mit Hilfe eines Mikro-Festplattenlaufwerks (HDD - Hard Disk Drive) implementiert sein. Ferner können beliebig viele neue Technologien zusätzlich zu den oder anstelle der beschriebenen Technologien für den Speicher 1058 verwendet werden, wie z.B., u.a., Widerstandsänderungsspeicher, Phasenwechselspeicher, holografische Speicher oder chemische Speicher.
Die Komponenten können über die Zwischenverbindung 1056 kommunizieren. Die Zwischenverbindung 1056 kann beliebig viele Technologien beinhalten, einschließlich ISA (Industry Standard Architecture), EISA (Extended ISA), PCI (Peripheral Component Interconnect), PCIx (Peripheral Component Interconnect Extended), PCIe (PCI Express) oder beliebig viele andere Technologien. Die Zwischenverbindung 1056 kann ein proprietärer Bus sein, wie er zum Beispiel in einem SoC-basierten System zum Einsatz kommt. Andere Bussysteme können enthalten sein, wie z.B., u.a., eine I2C-Schnittstelle, eine SPI-Schnittstelle, Punktzu-Punkt-Schnittstellen und eine Stromschiene.
Die Zwischenverbindung 1056 kann den Prozessor 1052 an einen Sendeempfänger 1062 koppeln, zur Kommunikation mit einem Cloud-, Fog- oder Mesh-Netzwerkgerät 1064. Der Sendeempfänger 1062 kann beliebig viele Frequenzen und Protokolle verwenden, wie z.B., u.a., 2,4 Gigahertz (GHz) Übertragungen gemäß dem IEEE 802.15.4-Standard, unter Verwendung des BLE (Bluetooth® Low Energy) -Standards, wie durch die Bluetooth® Special Interest Group definiert, oder des ZigBee®-Standards. Es können beliebig viele Funkgeräte, die für ein bestimmtes drahtloses Kommunikationsprotokoll konfiguriert sind, für die Verbindungen mit den Geräten 1064 verwendet werden. Zum Beispiel kann eine WLAN-Einheit zum Implementieren von Wi-Fi™-Kommunikation in Übereinstimmung mit dem IEEE (Institute of Electrical and Electronics Engineers) -Standard 802.11 eingesetzt werden. Außerdem kann WWA (Wireless Wide Area) -Kommunikation, z.B. gemäß einem Mobilfunk- oder einem anderen drahtlosen Weitbereichsprotokoll, über eine WWAN-Einheit stattfinden.
Der Sendeempfänger 1062 kann mit Hilfe mehrerer Standards oder Funkgeräte zur Kommunikation in unterschiedlichen Bereichen kommunizieren. Zum Beispiel kann das Gerät 1050 mit nahen Geräten, z.B. innerhalb von etwa 10 Metern, unter Verwendung eines lokalen Sendeempfängers basierend auf BLE oder eines anderen energiesparenden Funkgerätes kommunizieren, um Energie zu sparen. Weiter entfernte Geräte 1064, z.B. innerhalb von etwa 50 Metern, können über ZigBee oder andere Funkgeräte mit mittlerer Leistung erreicht werden. Beide Kommunikationstechniken können über ein einzelnes Funkgerät auf unterschiedlichen Leistungsebenen stattfinden oder können über separate Sendeempfänger stattfinden, zum Beispiel über einen lokalen Sendeempfänger mittels BLE und einen separaten Sendeempfänger mittels ZigBee.
Ein drahtloser Netzwerk-Sendeempfänger 1066 kann enthalten sein, um über lokale oder Weitbereichsnetzwerkprotokolle mit Geräten oder Diensten in der Cloud 1000 zu kommunizieren. Der drahtlose Netzwerk-Sendeempfänger 1066 kann ein LPWA-Sendeempfänger sein, der unter anderem dem Standard IEEE 802.15.4 oder IEEE 802.15.4g folgt. Das Gerät 1050 kann mit Hilfe eines LoRaWAN™ (Long Range Wide Area Network), entwickelt von Semtech und der LoRa Alliance, über einen weiten Bereich kommunizieren. Die hierin beschriebenen Techniken sind nicht auf diese Technologien beschränkt, sondern können mit beliebig vielen anderen Cloud-Sendeempfängern verwendet werden, die Kommunikation mit großer Reichweite und geringer Bandbreite, wie z.B. Sigfox, und andere Technologien implementieren. Ferner können auch andere Kommunikationstechniken, wie z.B. Zeitschlitz-Kanalsprünge, beschrieben in der Spezifikation IEEE 802.15.4e, verwendet werden.
Beliebig viele andere Funkkommunikation und -protokolle können zusätzlich zu den genannten Systemen für den Sendeempfänger 1062 und den drahtlosen Netzwerk-Sendeempfänger 1066, wie hierin beschrieben, verwendet werden. Zum Beispiel können die Funksendeempfänger 1062 und 1066 einen LTE- oder einen anderen Mobilfunk-Sendeempfänger beinhalten, der Frequenzspreizungs-(SPA/SAS) Kommunikation zum Implementieren von Hochgeschwindigkeitskommunikation verwendet. Ferner können beliebig viele andere Protokolle, wie z.B. Wi-Fi®-Netze, für Kommunikation mit mittlerer Geschwindigkeit und die Bereitstellung von Netzwerkkommunikation eingesetzt werden.
Die Funksendeempfänger 1062 und 1066 können Funkgeräte beinhalten, die mit beliebig vielen 3GPP (Third Generation Partnership Project) -Spezifikationen, insbesondere LTE (Long Term Evolution), LTE-A (Long Term Evolution-Advanced) und LTE-A Pro (Long Term Evolution-Advanced Pro), kompatibel sind. Es sei darauf hingewiesen, dass Funkgeräte, die mit beliebig vielen anderen feststehenden, mobilen oder Satelliten-Kommunikationstechnologien und -standards kompatibel sind, ausgewählt werden können. Dazu können zum Beispiel jegliche Mobilfunk-Weitbereichs-Funkkommunikationstechnologie, zu welchen z.B. ein 5G (5th Generation) -Kommunikationssystem zählen kann, eine GSM (Global System for Mobile Communications) -Funkkommunikationstechnologie, eine GPRS (General Packet Radio Service) -Funkkommunikationstechnologie, eine EDGE (Enhanced Data Rates for GSM Evolution) -Funkkommunikationstechnologie oder eine UMTS (Universal Mobile Telecommunications System) -Kommunikationstechnologie zählen. Zusätzlich zu den oben aufgeführten Standards können beliebig viele Satelliten-Uplink-Technologien für den drahtlosen Netzwerk-Sendeempfänger 1066 verwendet werden, einschließlich zum Beispiel Funkgeräte, die mit Standards konform sind, die unter anderem durch die ITU (International Telecommunication Union) oder das ETSI (European Telecommunications Standards Institute) herausgegeben wurden. Die hierin bereitgestellten Beispiele werden somit als für verschiedene andere Kommunikationstechnologien, sowohl vorhanden als auch noch nicht formuliert, geltend verstanden.
Ein Netzwerkschnittstellen-Controller (NIC - Network Interface Controller) 1068 kann enthalten sein, um verdrahtete Kommunikation zur Cloud 1000 oder zu anderen Geräten, wie z.B. den Geräten 1064, bereitzustellen. Die verdrahtete Kommunikation kann eine Ethernet-Verbindung bereitstellen oder kann auf anderen Arten von Netzwerken basieren, wie z.B., u.v.a., CAN (Controller Area Network), LIN (Local Interconnect Network), DeviceNet, ControlNet, Data Highway+, PROFIBUS oder PROFINET. Ein zusätzlicher NIC 1068 kann enthalten sein, um eine Verbindung zu einem zweiten Netzwerk zu gestatten, zum Beispiel ein NIC 1068, der Kommunikation zur Cloud über ein Ethernet bereitstellt, und ein zweiter NIC 1068, der Kommunikation zu anderen Geräten über eine andere Art von Netzwerk bereitstellt.
Die Zwischenverbindung 1056 kann den Prozessor 1052 an eine externe Schnittstelle 1070 koppeln, die zum Verbinden externer Geräte oder Teilsysteme verwendet wird. Zu den externen Geräten können Sensoren 1072 zählen, wie z.B. Beschleunigungsmesser, Füllstandsensoren, Flusssensoren, optische Lichtsensoren, Kamerasensoren, Temperatursensoren, GPS (Global Positioning System) -Sensoren, Drucksensoren, Atmosphärendrucksensoren und dergleichen. Die externe Schnittstelle 1070 kann ferner zum Verbinden des Gerätes 1050 mit Stellgliedern 1074 verwendet werden, wie z.B. Leistungsschaltern, Ventilantrieben, einem Erzeuger hörbarer Töne, einem visuellen Warngerät und dergleichen.
In einigen optionalen Beispielen können verschiedene Eingabe/Ausgabe (E/A) -Geräte innerhalb des Gerätes 1050 enthalten oder damit verbunden sein. Zum Beispiel kann eine Anzeige oder ein anderes Ausgabegerät 1084 enthalten sein, um Informationen anzuzeigen, wie z.B. Sensorablesungen oder eine Stellgliedposition. Ein Eingabegerät 1086, wie z.B. ein Touchscreen oder ein Tastenfeld, können zum Annehmen einer Eingabe enthalten sein. Ein Ausgabegerät 1084 kann beliebig viele Formen einer Audioausgabe oder visuellen Anzeige beinhalten, einschließlich einfacher visueller Ausgaben, wie z.B. Binärstatusindikatoren (z.B. LEDs) und visuelle Mehrzeichenausgaben, oder komplexere Ausgaben, wie z.B. Anzeigebildschirme (z.B. LCD-Bildschirme), wobei die Ausgabe von Zeichen, Grafiken, Multimedia-Objekten und dergleichen aus dem Betrieb des Gerätes 1050 erzeugt oder produziert wird.
Eine Batterie 1076 kann das Gerät 1050 mit Strom versorgen, obwohl das Gerät 1050 in Beispielen, in welchen es an einem festen Ort installiert ist, auch eine Stromversorgung gekoppelt an ein Stromnetz aufweisen kann. Die Batterie 1076 kann eine Lithiumionen-Batterie oder eine Metall-Luft-Batterie, wie z.B. eine Zink-Luft-Batterie, eine Aluminium-Luft-Batterie, eine Lithium-Luft-Batterie und dergleichen, sein.
Ein Batteriemonitor/-ladegerät 1078 kann in dem Gerät 1050 enthalten sein, um den Ladezustand (SoCh - State of Charge) der Batterie 1076 zu verfolgen. Das Batteriemonitor/-ladegerät 1078 kann auch zum Überwachen anderer Parameter der Batterie 1076 verwendet werden, um Versagensvorhersagen bereitzustellen, wie z.B. den Alterungszustand (SoH - State ofHealth) und den Funktionszustand (SoF - State ofFunction) der Batterie 1076. Das Batteriemonitor/-ladegerät 1078 kann eine integrierte Batterieüberwachungsschaltung beinhalten, wie z.B. LTC4020 oder LTC2990 von Linear Technologies, ADT7488A von ON Semiconductor aus Phoenix, Arizona oder eine IC aus der UCD90xxx-Familie von Texas Instruments aus Dallas, TX. Das Batteriemonitor/-ladegerät 1078 kann die Informationen zur Batterie 1076 über die Zwischenverbindung 1056 an den Prozessor 1052 kommunizieren. Das Batteriemonitor/-ladegerät 1078 kann auch einen Analog/Digital-Wandler (ADC - Analog-to-Digital Converter) beinhalten, welcher es dem Prozessor 1052 gestattet, die Spannung der Batterie 1076 oder den Stromfluss von der Batterie 1076 direkt zu überwachen. Die Batterieparameter können zum Bestimmen von Aktionen verwendet werden, die das Gerät 1050 durchführen kann, wie z.B. Übertragungshäufigkeit, Mesh-Netzwerk-Operation, Abtasthäufigkeit und dergleichen.
Ein Leistungsblock 1080 oder eine andere an ein Stromnetz gekoppelte Stromversorgung kann mit dem Batteriemonitor/-ladegerät 1078 gekoppelt sein, um die Batterie 1076 zu laden. In einigen Beispielen kann der Leistungsblock 1080 durch einen drahtlosen Stromempfänger ersetzt sein, um den Strom drahtlos zu erhalten, zum Beispiel über eine Schleifenantenne im Gerät 1050. Eine drahtlose Batterieladeschaltung, wie z.B., u.a., ein LTC4020-Chip von Linear Technologies aus Milpitas, Kalifornien, kann in dem Batteriemonitor/-ladegerät 1078 enthalten sein. Die spezifischen ausgewählten Ladeschaltungen hängen von der Größe der Batterie 1076 und somit vom erforderlichen Strom ab. Das Laden kann unter anderem mit Hilfe des Airfuel-Standards veröffentlicht durch die Airfuel Alliance, des drahtlosen Ladestandards Qi veröffentlicht durch das Wireless Power Consortium oder des Ladestandards Rezence veröffentlicht durch die Alliance for Wireless Power durchgeführt werden.
Der Speicher 1058 kann die Anweisungen 1082 in Form von Software-, Firmware- oder Hardware-Befehlen zum Implementieren der hierin beschriebenen Techniken beinhalten. Obwohl derartige Anweisungen 1082 als Codeblöcke gezeigt sind, die in dem Arbeitsspeicher 1054 und dem Speicher 1058 enthalten sind, kann verstanden werden, dass jeglicher der Codeblöcke auch durch festverdrahtete Schaltungen ersetzt sein kann, zum Beispiel eingebaut in eine anwendungsspezifische integrierte Schaltung (ASIC - Application Specific Integrated Circuit).
In einem Beispiel können die Anweisungen 1082, die über den Arbeitsspeicher 1054, den Speicher 1058 oder den Prozessor 1052 bereitgestellt werden, als ein nicht-transitorisches, maschinenlesbares Medium 1060 verkörpert sein, welches Code zum Steuern des Prozessors 1052 zum Durchführen elektronischer Operationen in dem Gerät 1050 beinhaltet. Der Prozessor 1052 kann über die Zwischenverbindung 1056 auf das nicht-transitorische, maschinenlesbare Medium 1060 zugreifen. Zum Beispiel kann das nicht-transitorische, maschinenlesbare Medium 1060 durch Geräte verkörpert sein, die für den Speicher 1058 von 10 beschrieben sind, oder kann spezifische Speichereinheiten beinhalten, wie z.B. optische Platten, Flash-Laufwerke oder beliebig viele andere Hardware-Geräte. Das nicht-transitorische, maschinenlesbare Medium 1060 kann ferner die Anweisungen 1088 beinhalten, bereitstellen oder aufrufen, um den Prozessor 1052 zum Durchführen einer/s spezifischen Abfolge oder Flusses von Aktionen zu steuern, wie zum Beispiel in Bezug auf das/die oben dargestellte/n Flussdiagramm(e) und Blockdiagramm(e) von Operationen und Funktionalität beschrieben.
In einem Beispiel können die Anweisungen 1088 auf dem Prozessor 1052 (separat oder in Kombination mit den Anweisungen 1088 des maschinenlesbaren Mediums 1060) die Ausführung oder Operation einer vertrauenswürdigen Ausführungsumgebung (TTE - Trusted Execution Environment) 1090 konfigurieren. In einem Beispiel arbeitet die TEE 1090 als ein geschützter Bereich, der für den Prozessor 1052 zugänglich ist, um einen sicheren Zugriff auf Daten und eine sichere Ausführung der Anweisungen zu ermöglichen. Verschiedene Implementierungen der TEE 1090 und ein dazugehöriger sicherer Bereich in dem Prozessor 1052 oder dem Arbeitsspeicher 1054 können zum Beispiel durch Verwendung von Intel® SGX (Software Guard Extensions) oder ARM® TrustZone®-Hardware-Sicherheitserweiterungen, Intel® ME (Management Engine) oder Intel® CSME (Converged Security Manageability Engine) vorgesehen sein. Andere Aspekte von Sicherheitshärtung, Hardware-Vertrauensankern und vertrauenswürdigen oder geschützten Operationen können über die TEE 1090 und den Prozessor 1052 in dem Gerät 1050 implementiert sein.
In weiteren Beispielen beinhaltet ein maschinenlesbares Medium auch jegliches greifbares Medium, das zum Speichern, Codieren oder Tragen von Anweisungen zur Ausführung durch eine Maschine, welche die Maschine zum Durchführen jeglicher einen oder mehreren der Vorgehensweisen der vorliegenden Offenbarung veranlassen, in der Lage ist oder das zum Speichern, Codieren oder Tragen von Datenstrukturen, die durch derartige Anweisungen genutzt werden oder damit assoziiert sind, in der Lage ist. Ein „maschinenlesbares Medium“ kann somit Festkörperspeicher und optische und magnetische Medien beinhalten, jedoch nicht darauf beschränkt. Zu spezifischen Beispielen maschinenlesbarer Medien zählen nichtflüchtiger Speicher, einschließlich zum Beispiel Halbleiterspeichergeräte (z.B. elektrisch programmierbarer Nur-Lese-Speicher (EPROM - Electrically Programmable Read-Only Memory), elektrisch löschbarer programmierbarer Nur-Lese-Speicher (EEPROM - Electrically Erasable Programmable Read-Only Memory)) und Flash-Speichergeräte; magnetische Platten, wie z.B. interne Festplatten und entfernbare Platten; magnetoptische Platten; und CD-ROMs und DVD-ROMs, jedoch nicht darauf beschränkt. Die durch ein maschinenlesbares Medium verkörperten Anweisungen können ferner über ein Kommunikationsnetzwerk gesendet oder empfangen werden, mit Hilfe eines Übertragungsmediums über ein Netzwerkschnittstellengerät unter Ausnutzung von jeglichem einer Reihe von Transferprotokollen (z.B. HTTP).
Es sollte verstanden werden, dass die in dieser Spezifikation beschriebenen Funktionseinheiten oder Fähigkeiten möglicherweise als Komponenten oder Module bezeichnet oder gekennzeichnet wurden, um insbesondere ihre Implementierungsunabhängigkeit zu betonen. Derartige Komponenten können durch beliebig viele Software- oder Hardware-Formen verkörpert sein. Zum Beispiel kann eine Komponente oder ein Modul als eine Hardware-Schaltung implementiert sein, die kundenspezifische hochintegrierte (VLSI - Very-Large-Scale Integration) Schaltungen oder Gate-Arrays, serienmäßig produzierte Halbleiter, wie z.B. Logikchips, Transistoren oder andere diskrete Komponenten, umfasst. Eine Komponente oder ein Modul kann auch in programmierbaren Hardware-Geräten, wie z.B. feldprogrammierbaren Gate-Arrays, programmierbarer Array-Logik, programmierbaren Logikgeräten oder dergleichen, implementiert sein. Komponenten oder Module können auch in Software implementiert sein, zur Ausführung durch verschiedene Arten von Prozessoren. Ein/e identifizierte/s Komponente oder Modul von ausführbarem Code kann zum Beispiel einen oder mehrere physische oder logische Blöcke von Computeranweisungen umfassen, welche zum Beispiel als ein Objekt, eine Prozedur oder eine Funktion organisiert sein können. Nichtsdestotrotz müssen sich die ausführbaren Dateien einer/s identifizierten Komponente oder Moduls nicht physisch beieinander befinden, sondern können disparate Anweisungen umfassen, die an unterschiedlichen Stellen gespeichert sind, welche, wenn sie logisch miteinander verbunden werden, die Komponente oder das Modul umfassen und den angegebenen Zweck für die Komponente oder das Modul erzielen.
Tatsächlich kann eine Komponente oder ein Modul von ausführbarem Code eine einzelne Anweisung oder viele Anweisungen sein und kann sogar über mehrere unterschiedliche Codesegment, auf unterschiedliche Programme und über mehrere Speichergeräte oder Verarbeitungssysteme hinweg verteilt sein. Insbesondere können einige Aspekte des beschriebenen Prozesses (wie z.B. Codeumschreibung und Codeanalyse) auf einem unterschiedlichen Verarbeitungssystem (z.B. in einem Computer in einem Datenzentrum) als dem, in welchem der Code implementiert ist (z.B. in einem Computer, der in einem Sensor oder Roboter eingebettet ist), stattfinden. Ähnlich können Betriebsdaten hierin innerhalb von Komponenten oder Modulen identifiziert und veranschaulicht sein und können in jeglicher geeigneten Form verkörpert und innerhalb jeglicher geeigneten Art von Datenstruktur organisiert sein. Die Betriebsdaten können als ein einzelner Datensatz gesammelt sein oder können über unterschiedliche Orte verteilt sein, einschließlich über unterschiedliche Speichergeräte hinweg, und können, zumindest teilweise, lediglich als elektronische Signale auf einem System oder Netzwerk vorliegen. Die Komponenten oder Module können passiv oder aktiv sein, einschließlich Agenten, die zum Durchführen gewünschter Funktionen betriebsfähig sind.
11 veranschaulicht ein Blockdiagramm eines Beispiels einer Maschine, auf welcher jegliche eine oder mehrere der hierin diskutierten Techniken (z.B. Vorgehensweisen) durchgeführt werden können. Beispiele, wie hierin beschrieben, können Logik oder eine Reihe von Komponenten oder Mechanismen in der Maschine Fehler! Verweisquelle konnte nicht gefunden werden.00 beinhalten oder damit arbeiten. Schaltungen (z.B. Verarbeitungsschaltungen) sind eine Sammlung von Schaltkreisen, die in greifbaren Entitäten der Maschine 1100, die Hardware beinhalten (z.B. einfache Schaltkreise, Gates, Logik usw.), implementiert sind. Eine Schaltungszugehörigkeit kann im Laufe der Zeit flexibel sein. Schaltungen beinhalten Elemente, die im Betrieb, allein oder in Kombination, spezifizierte Operationen durchführen können. In einem Beispiel kann die Hardware der Schaltungen unabänderlich ausgelegt sein, um eine spezifische Operation auszuführen (z.B. festverdrahtet). In einem Beispiel kann die Hardware der Schaltungen variabel verbundene physische Komponenten beinhalten (z.B. Ausführungseinheiten, Transistoren, einfache Schaltkreise usw.), einschließlich eines maschinenlesbaren Mediums, das physisch modifiziert wird (z.B. eine magnetische, elektrische, bewegliche Platzierung invarianter Masseteilchen usw.), um Anweisungen der spezifischen Operation zu codieren. Beim Verbinden der physischen Komponenten werden die zugrundeliegenden elektrischen Eigenschaften eines Hardware-Bestandteils verändert, zum Beispiel von einem Isolator zu einem Leiter oder umgekehrt. Die Anweisungen ermöglichen eingebetteter Hardware (z.B. die Ausführungseinheiten oder ein Lademechanismus) das Erstellen von Elementen der Schaltungen in der Hardware über die variablen Verbindungen zum Ausführen von Abschnitten der spezifischen Operation während des Betriebs. Dementsprechend sind in einem Beispiel die Elemente des maschinenlesbaren Mediums Teil der Schaltungen oder sind kommunikativ an die anderen Komponenten der Schaltungen gekoppelt, wenn das Gerät in Betrieb ist. In einem Beispiel können jegliche der physischen Komponenten in mehr als einem Element von mehr als einer Schaltung verwendet werden. Zum Beispiel können während des Betriebs zu einem Zeitpunkt Ausführungseinheiten in einem ersten Schaltkreis einer ersten Schaltung verwendet werden und durch einen zweiten Schaltkreis in der ersten Schaltung wiederverwendet werden, oder zu einem unterschiedlichen Zeitpunkt durch einen dritten Schaltkreis in einer zweiten Schaltung. Es folgen zusätzliche Beispiele dieser Komponenten in Bezug auf die Maschine Fehler! Verweisquelle konnte nicht gefunden werden.00.
In alternativen Ausführungsformen kann die Maschine Fehler! Verweisquelle konnte nicht gefunden werden.00 als ein eigenständiges Gerät arbeiten oder kann mit anderen Maschinen verbunden (z.B. vernetzt) sein. In einer vernetzten Implementierung kann die Maschine Fehler! Verweisquelle konnte nicht gefunden werden.00 in der Eigenschaft als eine Server-Maschine, eine Client-Maschine oder beiden in Server-Client-Netzwerkumgebungen arbeiten. In einem Beispiel kann die Maschine Fehler! Verweisquelle konnte nicht gefunden werden.00 als eine Peer-Maschine in einer P2P- (Peer-to-Peer) (oder einer anderen verteilten) Netzwerkumgebung agieren. Die Maschine Fehler! Verweisquelle konnte nicht gefunden werden.00 kann ein PC, ein Tablet-PC, eine Set-Top-Box (STB), ein PDA (Personal Digital Assistant), ein Mobiltelefon, eine Web-Appliance, ein Netzwerk-Router, ein Schalter oder eine Brücke oder jegliche Maschine, die zum Ausführen von Anweisungen (sequentiell oder anderweitig) in der Lage ist), die Aktionen spezifizieren, die durch diese Maschine auszuführen sind, sein. Ferner soll, während nur eine einzelne Maschine veranschaulicht ist, der Begriff „Maschine“ auch jegliche Sammlung von Maschinen beinhalten, die einzeln oder gemeinsam einen Satz (oder mehrere Sätze) von Anweisungen zum Durchführen jeglicher einen oder mehreren der hierin diskutierten Vorgehensweisen ausführen, wie z.B. Cloud-Computing, SaaS (Software as a Service) oder andere Computercluster-Konfigurationen.
Die Maschine (z.B. ein Computersystem) Fehler! Verweisquelle konnte nicht gefunden werden.00 kann einen Hardware-Prozessor Fehler! Verweisquelle konnte nicht gefunden werden.02 (z.B. eine zentrale Verarbeitungseinheit (CPU - Central Processing Unit), eine Grafikverarbeitungseinheit (GPU - Graphics Processing Unit), einen Hardware-Prozessorkern oder jegliche Kombination davon), einen Hauptspeicher Fehler! Verweisquelle konnte nicht gefunden werden.04, einen statischen Speicher (z.B. Arbeitsspeicher oder Speicher für Firmware, Mikrocode, ein Basisdatenaustauschsystem (BIOS - Basic Input-Output System), eine vereinheitlichte erweiterbare Firmware-Schnittstelle (UEFI - Unified Extensible Firmware Interface) usw.) Fehler! Verweisquelle konnte nicht gefunden werden.06 und Massenspeicher Fehler! Verweisquelle konnte nicht gefunden werden.08 (z.B. ein Festplattenlaufwerk, ein Bandlaufwerk, einen Flash-Speicher oder andere Blockgeräte) beinhalten, von welchen einige oder alle über eine Zwischenverbindung (z.B. einen Bus) Fehler! Verweisquelle konnte nicht gefunden werden.30 miteinander kommunizieren können. Die Maschine Fehler! Verweisquelle konnte nicht gefunden werden.00 kann ferner eine Anzeigeeinheit Fehler! Verweisquelle konnte nicht gefunden werden. 10, ein alphanumerisches Eingabegerät Fehler! Verweisquelle konnte nicht gefunden werden. 12 (z.B. eine Tastatur) und ein Benutzerschnittstellen (UI - User Interface) -Navigationsgerät Fehler! Verweisquelle konnte nicht gefunden werden. 14 (z.B. eine Maus) beinhalten. In einem Beispiel können die Anzeigeeinheit Fehler! Verweisquelle konnte nicht gefunden werden.10, das Eingabegerät Fehler! Verweisquelle konnte nicht gefunden werden. 12 und das UI-Navigationsgerät Fehler! Verweisquelle konnte nicht gefunden werden. 14 ein Touchscreen-Display sein. Die Maschine Fehler! Verweisquelle konnte nicht gefunden werden.00 kann außerdem ein Speichergerät Fehler! Verweisquelle konnte nicht gefunden werden.08 (z.B. eine Laufwerkseinheit), ein Signalerzeugungsgerät Fehler! Verweisquelle konnte nicht gefunden werden. 18 (z.B. einen Lautsprecher), ein Netzwerkschnittstellengerät Fehler! Verweisquelle konnte nicht gefunden werden.20 und einen oder mehrere Sensoren Fehler! Verweisquelle konnte nicht gefunden werden. 16, wie z.B. einen GPS (Global Positioning System) -Sensor, einen Kompass, einen Beschleunigungsmesser oder einen anderen Sensor, beinhalten. Die Maschine Fehler! Verweisquelle konnte nicht gefunden werden.00 kann einen Ausgabe-Controller Fehler! Verweisquelle konnte nicht gefunden werden.28, wie z.B. eine serielle (z.B. eine USB- (Universal Serial Bus)), eine parallele oder eine andere verdrahtete oder drahtlose (z.B. Infrarot-(IR), NFC- (Near Field Communication) usw.) Verbindung, zum Kommunizieren mit oder Steuern von einem oder mehreren peripheren Geräten (z.B. ein Drucker, ein Kartenlesegerät usw.) beinhalten.
Register des Prozessors Fehler! Verweisquelle konnte nicht gefunden werden.02, des Hauptspeichers Fehler! Verweisquelle konnte nicht gefunden werden.04, des statischen Speichers Fehler! Verweisquelle konnte nicht gefunden werden.06 oder des Massenspeichers Fehler! Verweisquelle konnte nicht gefunden werden.08 können ein maschinenlesbares Medium Fehler! Verweisquelle konnte nicht gefunden werden.22 sein oder dieses beinhalten, auf welchem ein oder mehrere Sätze von Datenstrukturen oder Anweisungen Fehler! Verweisquelle konnte nicht gefunden werden.24 (z.B. Software) gespeichert sind, welche jegliche eine oder mehrere der hierin beschriebenen Techniken oder Funktionen verkörpern oder durch diese genutzt werden. Die Anweisungen Fehler! Verweisquelle konnte nicht gefunden werden.24 können sich während ihrer Ausführung durch die Maschine Fehler! Verweisquelle konnte nicht gefunden werden.00 auch, komplett oder zumindest teilweise, innerhalb eines beliebigen der Register des Prozessors Fehler! Verweisquelle konnte nicht gefunden werden.02, des Hauptspeichers Fehler! Verweisquelle konnte nicht gefunden werden.04, des statischen Speichers Fehler! Verweisquelle konnte nicht gefunden werden.06 oder des Massenspeichers Fehler! Verweisquelle konnte nicht gefunden werden.08 befinden. In einem Beispiel kann einer oder jegliche Kombination aus dem Hardware-Prozessor Fehler! Verweisquelle konnte nicht gefunden werden.02, dem Hauptspeicher Fehler! Verweisquelle konnte nicht gefunden werden.04, dem statischen Speicher Fehler! Verweisquelle konnte nicht gefunden werden.06 oder dem Massenspeicher Fehler! Verweisquelle konnte nicht gefunden werden.08 das maschinenlesbare Medien Fehler! Verweisquelle konnte nicht gefunden werden.22 darstellen. Während das maschinenlesbare Medium Fehler! Verweisquelle konnte nicht gefunden werden.22 als ein einzelnes Medium veranschaulicht ist, kann der Begriff „maschinenlesbares Medium“ ein einzelnes Medium oder mehrere Medien (z.B. eine zentralisierte oder verteilte Datenbank und/oder assoziierte Caches und Server) beinhalten, die zum Speichern der einen oder mehreren Anweisungen Fehler! Verweisquelle konnte nicht gefunden werden.24 konfiguriert sind.
Der Begriff „maschinenlesbares Medium“ kann jegliches Medium beinhalten, welches zum Speichern, Codieren oder Tragen von Anweisungen zur Ausführung durch die Maschine Fehler! Verweisquelle konnte nicht gefunden werden.00, welche die Maschine Fehler! Verweisquelle konnte nicht gefunden werden.00 zum Durchführen jeglicher einen oder mehreren der Techniken der vorliegenden Offenbarung veranlassen, in der Lage ist oder welches zum Speichern, Codieren oder Tragen von Datenstrukturen, die durch derartige Anweisungen verwendet werden oder damit assoziiert sind, in der Lage ist. Zu nichteinschränkenden Beispielen eines maschinenlesbaren Mediums können Festkörperspeicher, optische Medien, magnetische Medien und Signale (z.B. Funkfrequenzsignale, andere Photonen-basierte Signale, Tonsignale usw.) zählen. In einem Beispiel umfasst ein nicht-transitorisches maschinenlesbares Medium ein maschinenlesbares Medium mit mehreren Partikeln, die eine invariante Masse (z.B. Ruhemasse) aufweisen, und bei welchen es sich somit um Stoffzusammensetzungen handelt. Dementsprechend sind nicht-transitorische maschinenlesbare Medien maschinenlesbare Medien, die keine sich transitorisch ausbreitenden Signale beinhalten. Zu spezifischen Beispielen von nicht-transitorischen maschinenlesbaren Medien können Folgende zählen: nichtflüchtiger Speicher, wie z.B. Halbleiterspeichergeräte (z.B. elektrisch programmierbarer Nur-Lese-Speicher (EPROM), elektrisch löschbarer programmierbarer Nur-Lese-Speicher (EEPROM)) und Flash-Speichergeräte; magnetische Platten, wie z.B. interne Festplatten und entfernbare Platten; magnetoptische Platten; und CD-ROMs und DVD-ROMs.
Die Anweisungen Fehler! Verweisquelle konnte nicht gefunden werden.24 können ferner mit Hilfe eines Übertragungsmediums über das Netzwerkschnittstellengerät Fehler! Verweisquelle konnte nicht gefunden werden.20 unter Ausnutzung eines beliebigen einer Reihe von Transferprotokollen (z.B. Frame-Relay, Internetprotokoll (IP), TCP (Transmission Control Protocol), UDP (User Datagram Protocol), HTTP (Hypertext Transfer Protocol) usw.) über ein Kommunikationsnetzwerk Fehler! Verweisquelle konnte nicht gefunden werden.26 gesendet oder empfangen werden. Zu Beispielkommunikationsnetzwerken können unter anderem ein LAN (Local Area Network), ein WAN (Wide Area Network), ein Paketdatennetzwerk (z.B. das Internet), Mobiltelefonnetzwerke (z.B. Mobilfunknetze), POTS (Plain Old Telephone) -Netzwerke und drahtlose Datennetzwerke (z.B. die IEEE (Institute of Electrical and Electronics Engineers) -Standardfamilie 802.11 bekannt als Wi-Fi®, die IEEE-Standardfamilie 802.15.4 oder P2P (Peer-to-Peer) -Netzwerke) zählen. In einem Beispiel kann das Netzwerkschnittstellengerät Fehler! Verweisquelle konnte nicht gefunden werden.20 eine oder mehrere physische Buchsen (z.B. Ethernet, Koaxial- oder Telefonbuchsen) oder eine oder mehrere Antennen zum Verbinden mit dem Kommunikationsnetzwerk Fehler! Verweisquelle konnte nicht gefunden werden.26 beinhalten. In einem Beispiel kann das Netzwerkschnittstellengerät Fehler! Verweisquelle konnte nicht gefunden werden.20 mehrere Antennen zum drahtlosen Kommunizieren mit Hilfe von mindestens einer aus der SIMO (Single-Input Multiple-Output), der MIMO (Multiple-Input Multiple-Output) oder der MISO (Multiple-Input Single-Output) - Technik beinhalten. Der Begriff „Übertragungsmedium“ soll jegliches greifbares Medium beinhalten, welches zum Speichern, Codieren oder Tragen von Anweisungen zur Ausführung durch die Maschine Fehler! Verweisquelle konnte nicht gefunden werden.00 in der Lage ist, und beinhaltet digitale oder analoge Kommunikationssignale oder ein anderes greifbares Medium zum Ermöglichen von Kommunikation einer derartigen Software. Ein Übertragungsmedium ist ein maschinenlesbares Medium.
Ein maschinenlesbares Medium kann durch ein Speichergerät oder eine andere Vorrichtung, welche zum Hosten von Daten in einem nicht-transitorischen Format in der Lage ist, bereitgestellt werden. In einem Beispiel können Informationen, die auf einem maschinenlesbaren Medium gespeichert sind oder anderweitig darauf bereitgestellt werden, repräsentativ für Anweisungen sein, wie z.B. Anweisungen selbst oder ein Format, aus welchem die Anweisungen abgeleitet werden können. Dieses Format, aus welchem die Anweisungen abgeleitet werden können, kann Quellcode, codierte Anweisungen (z.B. in komprimierter oder verschlüsselter Form), gepackte Anweisungen (z.B. aufgeteilt in mehrere Pakete) oder dergleichen beinhalten. Die Informationen, die repräsentativ für die Anweisungen in dem maschinenlesbaren Medium sind, können durch Verarbeitungsschaltungen zu den Anweisungen verarbeitet werden, um jegliche der hierin diskutierten Operationen zu implementieren. Zum Beispiel kann das Ableiten der Anweisungen aus den Informationen (z.B. Verarbeitung durch die Verarbeitungsschaltungen) Folgendes beinhalten: Kompilieren (z.B. aus Quellcode, Objektcode usw.), Interpretieren, Laden, Organisieren (z.B. dynamisches oder statisches Verknüpfen), Codieren, Decodieren, Verschlüsseln, Entschlüsseln, Verpacken, Entpacken oder anderweitiges Manipulieren der Informationen in die Anweisungen.
In einem Beispiel kann die Ableitung der Anweisungen das Assemblieren, Kompilieren oder Interpretieren der Informationen (z.B. durch die Verarbeitungsschaltungen) zum Erstellen der Anweisungen aus einem Zwischen- oder vorverarbeiteten Format, das durch das maschinenlesbare Medium bereitgestellt wird, beinhalten. Die Informationen können, wenn sie in mehreren Teilen bereitgestellt werden, kombiniert, entpackt und modifiziert werden, um die Anweisungen zu erstellen. Zum Beispiel können die Informationen in mehreren komprimierten Quellcodepaketen (oder Objektcode oder binärem ausführbarem Code usw.) auf einem oder mehreren entfernten Servern vorliegen. Die Quellcodepakete können verschlüsselt sein, wenn sie sich im Transit über ein Netzwerk befinden, und an einer lokalen Maschine entschlüsselt, dekomprimiert, falls nötig assembliert (z.B. verknüpft) und kompiliert oder interpretiert (z.B. in eine Bibliothek, eigenständige ausführbare Datei usw.) und durch die lokale Maschine ausgeführt werden.
Somit kann eine Blockchain-Technologie zum Unterstützen einer Netzwerkfunktionalität wie in 12 gezeigt verwendet werden. 12 ist ein Blockdiagramm, welches ein Beispiel der Bereitstellung eines Telekommunikationsdienstes gemäß einem Beispiel veranschaulicht. Eine Entität (Kunde), die einen neuen Dienst initiieren möchte, wie z.B. einen Sprachdienst, beschreibt den gewünschten Dienst mit Hilfe eines Deskriptor-Datensatzes. Der Kunde unterzeichnet den Deskriptor und übermittelt den Deskriptor an die Blockchain. Der Deskriptor kann über eine Deskriptor-Nachricht an einen Registrierungsanbieter (Registrator) bereitgestellt werden. Eine Gemeinschaft von Anbietern kann darum konkurrieren, den gesamten oder einen Teil des Dienstes bereitzustellen. Die Blockchain-Mining-Community stellt sicher, dass die Deskriptor-Nachricht tatsächlich übermittelt wurde und dass der Registrator die Deskriptor-Nachricht erhalten hat. Die Mining-Community kann den Registrator-Inhalt replizieren, wodurch die Deskriptor-Nachricht ubiquitär für jeden zugänglich gemacht wird, der Zugriff auf eine Kopie der Blockchain-Blöcke hat. In einigen Ausführungsformen kann der Registrator eine Vergütung (z.B. eine E-Coin) an den Kunden senden oder kann einen Teil einer derartigen Vergütung (z.B. eine partielle E-Coin) unterstützen, um den Empfang des Deskriptors zu bestätigen. Zum Beispiel ist der Vertrag der Deskriptor zur Orchestrierung als ein Dienst, der Kunde ist ein Benutzer und die Dienstanbieter sind die Orchestrator-Gemeinschaft.
Dienstanbieter, die einen Dienst, wie durch den Deskriptor definiert, bereitstellen möchten, können fortwährend Transaktionen zum Registrator überwachen. Zum Beispiel können die Dienstanbieter die Blockchain-Transaktionsliste jedes beliebigen Miners prüfen. Im Wesentlichen kann die Blockchain zum Implementieren eines Veröffentlichung-Übermittlung-Mechanismus verwendet werden.
Interessierte Dienstanbieter können auf den übermittelten Deskriptor reagieren, indem sie einen Gebotsdatensatz erstellen, der durch den Dienstanbieter unterzeichnet und als eine Blockchain-Transaktion an den Kunden gesendet wird. Der Kunde bestätigt den Empfang der Gebote durch das Senden eines Teils der Vergütung (z.B. eine partielle E-Coin) an jeden Bieter (für Gebote, die in Betracht gezogen werden). Der Kunde kann einen Zeitrahmen für das Treffen einer Entscheidung einschließen und/oder die Bieter können einen Zeitrahmen für das Akzeptieren eines Gebotes einschließen. Die Zeitrahmen können unterschiedlich sein. Wenn die Zeitrahmen ablaufen, bevor ein Gebot angenommen wird, zeichnet die Blockchain das Verstreichen der Zeit auf und stellt Klarheit für einen Auditor darüber sicher, welches die Zeitrahmen waren und ob die Zeitrahmen abgelaufen sind.
Der Kunde akzeptiert ein Gebot durch das Unterzeichnen des Vertrages und das Senden des unterzeichneten Vertrages an den Urheber. Die Blockchain zeichnet auf, dass die Annahmenachricht gesendet wurde. Der Bieter bestätigt den Empfang der Annahme durch das Senden einer E-Coin-Bezahlung für den Erhalt des Vertrages oder eine partielle E-Coin, wenn andere Zahlungsbedingungen definiert sind. An dieser Stelle weiß die Blockchain, dass der Vertrag angenommen wurde und kennt die Bedingungen des Vertrages.
Somit kann die Blockchain-Technologie, wie in 12 gezeigt, bei jedem Schritt angewandt werden. Nachdem der neue Netzwerkdienst (z.B. ein Sprachdienst) angefordert wurde, wird der Orchestrierungsanbieter basierend auf dem Deskriptor zur Orchestrierung eines Dienstes ausgewählt. Für die DSFC erstellt der Orchestrator eine Dienstfunktionskette für den Sprachdienst und verarbeitet einen Deskriptor, SLAs, Sicherheit, QoS und andere Parameter für den Sprachdienst. Der Orchestrator wählt einen Sprachdienst aus und stimmt einer SLA für den Sprachdienst basierend auf verteilter Dienstfunktionskettenbildung zu. Der Orchestrator stellt dann einen Dienst-Hosting-Vertrag und einen Netzwerkdienstvertrag basierend auf dem Deskriptor aus. In diesem Fall ist der Vertrag der Deskriptor für einen verteilten Dienst zusammengesetzt aus einer/m Abfolge/Graph von FaaS-Funktionen. Der Kunde kann nun der Orchestrator sein und die Dienstanbieter sind Anbieter von Edge-Dienst-Lösungen.
Die verschiedenen verteilten Entitäten bieten auf den Dienst-Hosting-Vertrag und den Netzwerkdienstvertrag. Der Orchestrator wählt einen Satz von Anbietern aus, die diskrete Funktionen hosten, die durch die DSFC identifiziert werden. Für das DWH ist der Vertrag für eine diskrete Netzwerkfunktion (VNF, COTS usw.) gedacht, der Kunde ist der Anbieter von Edge-Dienst-Lösungen und die Dienstanbieter sind die Gemeinschaft von FaaS-Hosting-Anbietern.
Der Dienst wird dann in Übereinstimmung mit der SLA ausgeführt. Insbesondere wird das DWH durch eine Orchestrierung der zu verwendenden Ressourcen, z.B. CPU, NIC, VFs, L1-L3-Funktionalität einer Basisstation, erfüllt. Die Netzwerkdienste werden durch eine Orchestrierung der Netzwerkdienste für die Sprachdienste, z.B. vEPC VNFs, erfüllt. Der Benutzer führt dann die Dienstgütevereinbarung aus und empfängt die Ergebnisse der verteilten Ausführung. Der Ausführungsschritt kann durch eine Blockchain überwacht werden, da FaaS-Knoten die Ausführung aufzeichnen (auditieren), Telemetriedaten bereitstellen und/oder eine E-Coin als Bestätigung für das Durchführen des Dienstes akzeptieren/zurücksenden können. Der Kunde kann somit damit beginnen, den Dienst zu nutzen, der durch den Dienstanbieter bereitgestellt wird. Dies kann davon abhängen, dass der Dienstanbieter Zugriffsrechte bereitstellt, Dienstschnittstellen freigibt usw. Dies kann innerhalb oder außerhalb der Blockchain stattfinden. Nachdem der Vertrag erfüllt wurde und die Sprachdienste bereitgestellt wurden, kann der Sprachdienst eliminiert werden.
Zu zusätzlichen Beispielen der gegenwärtig beschriebenen Verfahrens-, System- und Geräteausführungsformen zählen die folgenden, nichteinschränkenden Konfigurationen. Jedes der folgenden nichteinschränkenden Beispiele kann für sich allein stehen oder kann in jeglicher Permutation oder Kombination mit jeglichem einen oder mehreren der anderen Beispiele, die unten oder in der gesamten vorliegenden Offenbarung bereitgestellt sind, kombiniert werden.
Beispiele
Beispiel 1 ist ein Gerät, welches Folgendes umfasst: Verarbeitungsschaltungen, die zu Folgendem geeignet sind: Posten einer Anfrage zur Orchestrierung eines Netzwerkdienstes, der mit Hilfe einer Virtualisierung von Netzwerkfunktionen (NFV - Network Function Virtualization) bereitgestellt werden soll, wobei das Gebot mit Hilfe einer Blockchain für DSFC (Distributed Service Function Chain - verteilte Dienstfunktionskette) -Verträge abgegeben wird, wobei das Gerät, der DSFC-Vertrag und der Initiator einer Anfrage für den Netzwerkdienst mit Hilfe einer Blockchain für selbstsouveräne Identitäten identifiziert werden; Bestimmen, basierend auf der Blockchain für DSFC-Verträge, dass das Gerät den Netzwerkdienst aus Entitäten orchestrieren soll, die eine Fähigkeit zum Orchestrieren des Netzwerkdienstes angezeigt haben; Identifizieren, als Reaktion auf eine Bestimmung, dass das Gerät den Netzwerkdienst orchestrieren soll, mindestens einer Entität zum Bereitstellen des Netzwerkdienstes aus einer Blockchain für DWH (DSFC Workload Hosting) -Verträge, die DWH-Vertragsgebote von Entitäten für den Netzwerkdienst enthält, wobei die Entitäten und der DWH-Vertrag mit Hilfe der Blockchain für selbstsouveräne Identitäten identifiziert werden; und Verifizieren, dass der DWH-Vertrag durch die mindestens eine Entität gemäß dem DWH-Vertrag ausgeführt wird; und einen Arbeitsspeicher, der zum Speichern des DWH-Vertrages konfiguriert ist.
Beispiel 2 beinhaltet den Gegenstand von Beispiel 1, wobei die Verarbeitungsschaltungen ferner zum Verifizieren, dass der mindestens einen Entität eine Vergütung für die Erfüllung des DWH-Vertrages bereitgestellt wird, geeignet sind.
Beispiel 3 beinhaltet den Gegenstand von Beispiel 1-2, wobei die Verarbeitungsschaltungen ferner zum Erstellen einer Dienstfunktionskette für den Netzwerkdienst geeignet sind.
Beispiel 4 beinhaltet den Gegenstand von Beispiel 3, wobei die Verarbeitungsschaltungen ferner zum Verifizieren, basierend auf der Dienstfunktionskette, dass der DWH-Vertrag durch die mindestens eine Entität gemäß dem DWH-Vertrag ausgeführt wird, durch Sammlung von Telemetriedaten, die über eines oder mehrere der Folgenden berichten: Produktkettenüberwachung, Regelüberwachung, Einhaltung der Dienstgütevereinbarung (SLA - Service Level Agreement), Einhaltung der Dienstgüte (QoS - Quality of Service) und Einhaltung von Sicherheitsrichtlinien, geeignet sind.
Beispiel 5 beinhaltet den Gegenstand von Beispiel 1-4, wobei die Verarbeitungsschaltungen ferner zum Auswählen der mindestens einen Entität zum Bereitstellen des Netzwerkdienstes aus der Blockchain für DWH-Verträge geeignet sind.
Beispiel 6 beinhaltet den Gegenstand von Beispiel 1-5, wobei der Netzwerkdienst eine virtuelle Netzwerkfunktion (VNF - Virtual Network Function) umfasst.
Beispiel 7 beinhaltet den Gegenstand von Beispiel 6, wobei die Verarbeitungsschaltungen ferner zum Orchestrieren mehrerer Anbieter, die diskrete Funktionen zum Bereitstellen der VNF hosten, geeignet sind.
Beispiel 8 beinhaltet den Gegenstand von Beispiel 1-7, wobei Deskriptoren von Einträgen in mindestens einer der Blockchain für selbstsouveräne Identitäten, der Blockchain für DSFC-Verträge oder der Blockchain für DWH-Verträge in NFV-Standards des ETSI (European Telecommunications Standards Institute) definiert sind.
Beispiel 9 beinhaltet den Gegenstand von Beispiel 1-8, wobei die Verarbeitungsschaltungen ferner zum Erzeugen eines zufälligen selbsterzeugten Identifikators, zum Hashen des Identifikators mit einem kryptografischen Hash zum Bilden eines krypto-gehashten Identifikators und zum Übermitteln des krypto-gehashten Identifikators an die Blockchain für selbstsouveräne Identitäten als ein Blockchain-Identifikator des Gerätes geeignet sind.
Beispiel 10 beinhaltet den Gegenstand von Beispiel 1-9, wobei der DSFC-Vertrag einen Zeitrahmen enthält, für welchen der DSFC-Vertrag gültig ist.
Beispiel 11 beinhaltet den Gegenstand von Beispiel 1-10, wobei der Netzwerkdienst ein verteilter Netzwerkdienst ist und die Verarbeitungsschaltungen ferner zum Ausstellen, mit Hilfe der Blockchain, des DWH-Vertrages und eines Netzwerkdienstvertrages für den verteilten Netzwerkdienst geeignet sind.
Beispiel 12 beinhaltet den Gegenstand von Beispiel 1-11, wobei die Blockchain für selbstsouveräne Identitäten, die DSFC-Blockchain und die DWH-Blockchain über ein einzelnes verteiltes digitales Ledger eingebunden sind.
Beispiel 13 ist ein Speichergerät, welches Anweisungen enthält, wobei die Anweisungen, wenn sie durch Verarbeitungsschaltungen eines Rechengerätes ausgeführt werden, die Verarbeitungsschaltungen zu Folgendem veranlassen: Posten einer Anfrage zur Orchestrierung eines Netzwerkdienstes mit Hilfe einer Blockchain für DSFC (Distributed Service Function Chain - verteilte Dienstfunktionskette) -Verträge, wobei das Rechengerät, der DSFC-Vertrag und der Initiator einer Anfrage für den Netzwerkdienst mit Hilfe einer Blockchain für selbstsouveräne Identitäten identifiziert werden; als Reaktion auf eine Bestimmung mit Hilfe der Blockchain für DSFC-Verträge, dass das Rechengerät den Netzwerkdienst orchestrieren soll, Erstellen einer Dienstfunktionskette für den Netzwerkdienst für mindestens eine Entität zum Bereitstellen des Netzwerkdienstes basierend auf einer Blockchain für DWH (DSFC Workload Hosting) -Verträge, die DWH-Vertragsgebote von Entitäten für den Netzwerkdienst enthält, wobei die Entitäten und der DWH-Vertrag mit Hilfe der Blockchain für selbstsouveräne Identitäten identifiziert werden; und Verifizieren, dass der DWH-Vertrag durch die mindestens eine Entität gemäß dem DWH ausgeführt wird.
Beispiel 14 beinhaltet den Gegenstand von Beispiel 13, wobei die Anweisungen die Verarbeitungsschaltungen ferner zum Verifizieren, basierend auf der Dienstfunktionskette, dass der DWH-Vertrag durch die mindestens eine Entität gemäß dem DWH-Vertrag ausgeführt wird, durch Sammlung von Telemetriedaten, die über Produktkettenüberwachung, Regelüberwachung, Einhaltung der Dienstgütevereinbarung (SLA - Service Level Agreement), Einhaltung der Dienstgüte (QoS - Quality of Service) und Einhaltung von Sicherheitsrichtlinien berichten, veranlassen.
Beispiel 15 beinhaltet den Gegenstand von Beispiel 13-14, wobei die Anweisungen die Verarbeitungsschaltungen ferner zum Auswählen der mindestens einen Entität zum Bereitstellen des Netzwerkdienstes aus der Blockchain für DWH-Verträge veranlassen.
Beispiel 16 beinhaltet den Gegenstand von Beispiel 13-15, wobei der Netzwerkdienst eine virtuelle Netzwerkfunktion (VNF - Virtual Network Function) umfasst.
Beispiel 17 beinhaltet den Gegenstand von Beispiel 16, wobei die Anweisungen die Verarbeitungsschaltungen ferner zum Orchestrieren mehrerer Anbieter, die diskrete Funktionen zum Bereitstellen der VNF hosten, veranlassen.
Beispiel 18 beinhaltet den Gegenstand von Beispiel 13-17, wobei die Anweisungen die Verarbeitungsschaltungen ferner zum Erzeugen eines zufälligen selbsterzeugten Identifikators, zum Hashen des Identifikators mit einem kryptografischen Hash zum Bilden eines krypto-gehashten Identifikators und zum Übermitteln des krypto-gehashten Identifikators an die Blockchain für selbstsouveräne Identitäten als ein Blockchain-Identifikator des Rechengerätes veranlassen.
Beispiel 19 beinhaltet den Gegenstand von Beispiel 13-18, wobei der Netzwerkdienst ein verteilter Netzwerkdienst ist und die Anweisungen die Verarbeitungsschaltungen ferner zum Ausstellen, mit Hilfe der Blockchain, des DWH-Vertrages und eines Netzwerkdienstvertrages für den verteilten Netzwerkdienst veranlassen.
Beispiel 20 beinhaltet den Gegenstand von Beispiel 13-19, wobei die Blockchain für selbstsouveräne Identitäten, die DSFC-Blockchain und die DWH-Blockchain über ein einzelnes verteiltes digitales Ledger eingebunden sind.
Beispiel 21 ist ein Verfahren zum Orchestrieren eines Netzwerkdienstes, welches Folgendes umfasst: Auswählen eines Netzwerkdienstes, der bereitgestellt werden soll; Auswählen eines Orchestrierungsanbieters für den Netzwerkdienst mit Hilfe einer Blockchain für selbstsouveräne Identitäten zum Identifizieren des Orchestrierungsanbieters und einer Blockchain für DSFC (Distributed Service Function Chain - verteilte Dienstfunktionskette) -Verträge zum Verknüpfen des Orchestrierungsanbieters und des Netzwerkdienstes; Erstellen einer Dienstfunktionskette für den Netzwerkdienst für mindestens einen Anbieter zum Hosten diskreter Funktionen, die durch die DSFC identifiziert werden, basierend auf einer Blockchain für DWH (DSFC Workload Hosting) -Verträge, die DWH-Vertragsgebote von Anbietern für den Netzwerkdienst enthält, wobei die Blockchain für DWH-Verträge die Anbieter und die Funktionen verknüpfen soll; und Ausführen des Netzwerkdienstes in Übereinstimmung mit einer Dienstgütevereinbarung (SLA - Service Level Agreement), die durch die Dienstfunktionskette identifiziert wird.
Beispiel 22 beinhaltet den Gegenstand von Beispiel 21, wobei der Netzwerkdienst mit Hilfe einer Virtualisierung von Netzwerkfunktionen (NFV - Network Function Virtualization) bereitgestellt werden soll und mindestens eine der Funktionen eine virtuelle Netzwerkfunktion (VNF - Virtual Network Function) ist.
Beispiel 23 beinhaltet den Gegenstand von Beispiel 22, welcher ferner das Orchestrieren mehrerer Anbieter, die diskrete Funktionen zum Bereitstellen der VNF hosten, umfasst.
Beispiel 24 beinhaltet den Gegenstand von Beispiel 21-23, welcher ferner das Sammeln von Telemetriedaten und Verifizieren, basierend auf der Dienstfunktionskette und den Telemetriedaten, dass der DWH-Vertrag durch die mindestens eine Entität gemäß dem DWH-Vertrag ausgeführt wird, umfasst, wobei die Telemetriedaten über Produktkettenüberwachung, Regelüberwachung, Einhaltung der Dienstgütevereinbarung (SLA - Service Level Agreement), Einhaltung der Dienstgüte (QoS - Quality of Service) und Einhaltung von Sicherheitsrichtlinien berichten.
Beispiel 25 beinhaltet den Gegenstand von Beispiel 21-24, welcher ferner, für jeden aus dem Orchestrierungsanbieter und den Anbietern, das Erzeugen eines zufälligen selbsterzeugten Identifikators, das Hashen des Identifikators mit einem kryptografischen Hash zum Bilden eines krypto-gehashten Identifikators und das Übermitteln des krypto-gehashten Identifikators an die Blockchain für selbstsouveräne Identitäten als ein Blockchain-Identifikator umfasst.
Beispiel 26 ist ein Gerät, welches Folgendes umfasst: Mittel zum Auswählen eines Netzwerkdienstes, der bereitgestellt werden soll; Mittel zum Auswählen eines Orchestrierungsanbieters für den Netzwerkdienst mit Hilfe einer Blockchain für selbstsouveräne Identitäten zum Identifizieren des Orchestrierungsanbieters und einer Blockchain für DSFC (Distributed Service Function Chain - verteilte Dienstfunktionskette) -Verträge zum Verknüpfen des Orchestrierungsanbieters und des Netzwerkdienstes; Mittel zum Erstellen einer Dienstfunktionskette für den Netzwerkdienst für mindestens einen Anbieter zum Hosten diskreter Funktionen, die durch die DSFC identifiziert werden, basierend auf einer Blockchain für DWH (DSFC Workload Hosting) -Verträge, die DWH-Vertragsgebote von Anbietern für den Netzwerkdienst enthält, wobei die Blockchain für DWH-Verträge die Anbieter und die Funktionen verknüpfen soll; und Mittel zum Ausführen des Netzwerkdienstes in Übereinstimmung mit einer Dienstgütevereinbarung (SLA - Service Level Agreement), die durch die Dienstfunktionskette identifiziert wird.
Beispiel 27 beinhaltet den Gegenstand von Beispiel 26, wobei der Netzwerkdienst mit Hilfe einer Virtualisierung von Netzwerkfunktionen (NFV - Network Function Virtualization) bereitgestellt werden soll und mindestens eine der Funktionen eine virtuelle Netzwerkfunktion (VNF - Virtual Network Function) ist.
Beispiel 28 beinhaltet den Gegenstand von Beispiel 27, welcher ferner Mittel zum Orchestrieren mehrerer Anbieter, die diskrete Funktionen zum Bereitstellen der VNF hosten, umfasst.
Beispiel 29 beinhaltet den Gegenstand von Beispiel 26-28, welcher ferner Mittel zum Sammeln von Telemetriedaten und Mittel zum Verifizieren, basierend auf der Dienstfunktionskette und den Telemetriedaten, dass der DWH-Vertrag durch die mindestens eine Entität gemäß dem DWH-Vertrag ausgeführt wird, umfasst, wobei die Telemetriedaten über Produktkettenüberwachung, Regelüberwachung, Einhaltung der Dienstgütevereinbarung (SLA - Service Level Agreement), Einhaltung der Dienstgüte (QoS - Quality of Service) und Einhaltung von Sicherheitsrichtlinien berichten.
Beispiel 30 beinhaltet den Gegenstand von Beispiel 26-29, welcher ferner, für jeden aus dem Orchestrierungsanbieter und den Anbietern, Mittel zum Erzeugen eines zufälligen selbsterzeugten Identifikators, zum Hashen des Identifikators mit einem kryptografischen Hash zum Bilden eines krypto-gehashten Identifikators und zum Übermitteln des krypto-gehashten Identifikators an die Blockchain für selbstsouveräne Identitäten als ein Blockchain-Identifikator umfasst.
Beispiel 31 beinhaltet den Gegenstand von Beispiel 26-30, wobei die Blockchain für selbstsouveräne Identitäten, die DSFC-Blockchain und die DWH-Blockchain über ein einzelnes verteiltes digitales Ledger eingebunden sind.
Beispiel 32 kann eine Vorrichtung beinhalten, die Mittel zum Durchführen eines oder mehrerer Elemente eines Verfahrens, das in einem beliebigen der Beispiele 1-31 beschrieben wurde oder darauf bezogen ist, oder eines beliebigen anderen hierin beschriebenen Verfahrens oder Prozesses umfasst.
Beispiel 33 kann ein oder mehrere nicht-transitorische computerlesbare Medien beinhalten, die Anweisungen umfassen, um ein elektronisches Gerät, bei Ausführung der Anweisungen durch einen oder mehrere Prozessoren des elektronischen Gerätes, zum Durchführen eines oder mehrerer Elemente eines Verfahrens, das in einem beliebigen der Beispiele 1-31 beschrieben wurde oder darauf bezogen ist, oder eines beliebigen anderen hierin beschriebenen Verfahrens oder Prozesses veranlassen.
Beispiel 34 kann eine Vorrichtung beinhalten, die Logik, Module oder Schaltungen zum Durchführen eines oder mehrerer Elemente eines Verfahrens, das in einem beliebigen der Beispiele 1-31 beschrieben wurde oder darauf bezogen ist, oder eines beliebigen anderen hierin beschriebenen Verfahrens oder Prozesses umfasst.
Beispiel 35 kann ein Verfahren, eine Technik oder einen Prozess, wie in einem beliebigen der Beispiele 1-31 beschrieben oder darauf bezogen, oder Abschnitte oder Teile davon beinhalten.
Beispiel 36 kann eine Vorrichtung beinhalten, die Folgendes umfasst: einen oder mehrere Prozessoren und ein oder mehrere computerlesbare Medien, die Anweisungen umfassen, die, wenn sie durch den einen oder die mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren zum Durchführen des Verfahrens, der Techniken oder des Prozesses, wie in einem beliebigen der Beispiele 1-31 beschrieben oder darauf bezogen, oder Abschnitten davon veranlassen.
Beispiel 37 kann ein Signal, wie in einem beliebigen der Beispiele 1-31 beschrieben oder darauf bezogen, oder Abschnitte oder Teile davon beinhalten.
Beispiel 38 kann ein Signal in einem drahtlosen Netzwerk, wie in einem beliebigen der Beispiele 1-31 beschrieben oder darauf bezogen, oder wie anderweitig hierin gezeigt und beschrieben beinhalten.
Beispiel 39 kann ein Verfahren des Kommunizierens in einem drahtlosen Netzwerk, wie in einem beliebigen der Beispiele 1-31 beschrieben oder darauf bezogen, oder wie anderweitig hierin gezeigt und beschrieben beinhalten.
Beispiel 40 kann ein System zum Bereitstellen drahtloser Kommunikation, wie in einem beliebigen der Beispiele 1-31 beschrieben oder darauf bezogen, oder wie anderweitig hierin gezeigt und beschrieben beinhalten.
Beispiel 41 kann ein Gerät zum Bereitstellen drahtloser Kommunikation, wie in einem beliebigen der Beispiele 1-31 beschrieben oder darauf bezogen, oder wie anderweitig hierin gezeigt und beschrieben beinhalten.
Beispiel 42 ist ein Netzwerk, welches entsprechende Geräte und Gerätekommunikationsmedien zum Durchführen einer beliebigen der Operationen der Beispiele 1-31, oder wie anderweitig hierin gezeigt und beschrieben, umfasst.
Beispiel 43 ist eine 4G/5G-Kommunikationsnetzwerktopologie, wobei die Netzwerktopologie entsprechende Kommunikationsverknüpfungen umfasst, die zum Durchführen von Kommunikation für die Operationen von einem beliebigen der Beispiele 1-31, oder wie anderweitig hierin gezeigt und beschrieben, geeignet sind.
Beispiel 44 ist eine Edge-Cloud-Rechengerät-Implementierung, welche Verarbeitungsknoten und Recheneinheiten umfasst, die zum Durchführen jeglicher der Operationen von Beispiel 1-31, oder wie anderweitig hierin gezeigt und beschrieben, geeignet sind.
Beispiel 45 ist eine ETSI NFV-Systemimplementierung, welche Geräte, Verarbeitungsknoten und Recheneinheiten umfasst, die zum Durchführen jeglicher der Operationen von Beispiel 1-31, oder wie anderweitig hierin gezeigt und beschrieben, geeignet sind.
Beispiel 46 ist eine Edge-Cloud-Netzwerkplattform, welche physische und logische Rechenressourcen umfasst, die zum Durchführen jeglicher der Operationen von Beispiel 1-31, oder wie anderweitig hierin gezeigt und beschrieben, geeignet sind.
Beispiel 47 ist eine Vorrichtung, welche entsprechende Mittel zum Durchführen jeglicher der Operationen von Beispiel 1-31, oder wie anderweitig hierin gezeigt und beschrieben, umfasst.
Beispiel 48 ist ein System zum Durchführen der Operationen von einem beliebigen der Beispiele 1-31, oder wie anderweitig hierin gezeigt und beschrieben.
Beispiel 49 ist mindestens ein maschinenlesbares Speichermedium, welches Informationen, die repräsentativ für Anweisungen sind, umfasst, die, wenn sie durch Verarbeitungsschaltungen ausgeführt werden, die Verarbeitungsschaltungen zum Durchführen der Operationen von einem beliebigen der Beispiele 1-48 veranlassen.
In der obigen detaillierten Beschreibung können verschiedene Merkmale zusammen gruppiert sein, um die Offenbarung zu straffen. Jedoch legen die diese Merkmale betreffenden Ansprüche möglicherweise nicht jedes hierin offenbarte Merkmal dar, da Ausführungsformen möglicherweise nur über eine Teilmenge der Merkmale verfügen. Ferner können Ausführungsformen weniger Merkmale als die in einem bestimmten Beispiel offenbarten beinhalten.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 62/625177 [0001]

Claims

Gerät, welches Folgendes umfasst: Verarbeitungsschaltungen, die zu Folgendem geeignet sind: Posten einer Anfrage zur Orchestrierung eines Netzwerkdienstes, der mit Hilfe einer Virtualisierung von Netzwerkfunktionen (NFV - Network Function Virtualization) bereitgestellt werden soll, wobei das Gebot mit Hilfe einer Blockchain für DSFC (Distributed Service Function Chain - verteilte Dienstfunktionskette) -Verträge abgegeben wird, wobei das Gerät, der DSFC-Vertrag und der Initiator einer Anfrage für den Netzwerkdienst mit Hilfe einer Blockchain für selbstsouveräne Identitäten identifiziert werden; Bestimmen, basierend auf der Blockchain für DSFC-Verträge, dass das Gerät den Netzwerkdienst aus Entitäten orchestrieren soll, die eine Fähigkeit zum Orchestrieren des Netzwerkdienstes angezeigt haben; Identifizieren, als Reaktion auf eine Bestimmung, dass das Gerät den Netzwerkdienst orchestrieren soll, mindestens einer Entität zum Bereitstellen des Netzwerkdienstes aus einer Blockchain für DWH (DSFC Workload Hosting) -Verträge, die DWH-Vertragsgebote von Entitäten für den Netzwerkdienst enthält, wobei die Entitäten und der DWH-Vertrag mit Hilfe der Blockchain für selbstsouveräne Identitäten identifiziert werden; und Verifizieren, dass der DWH-Vertrag durch die mindestens eine Entität gemäß dem DWH-Vertrag ausgeführt wird; und einen Arbeitsspeicher, der zum Speichern des DWH-Vertrages konfiguriert ist.
Gerät nach Anspruch 1, wobei die Verarbeitungsschaltungen ferner zum Verifizieren, dass der mindestens einen Entität eine Vergütung für die Erfüllung des DWH-Vertrages bereitgestellt wird, geeignet sind.
Gerät nach Anspruch 1 oder 2, wobei die Verarbeitungsschaltungen ferner zum Erstellen einer Dienstfunktionskette für den Netzwerkdienst geeignet sind.
Gerät nach Anspruch 3, wobei die Verarbeitungsschaltungen ferner zum Verifizieren, basierend auf der Dienstfunktionskette, dass der DWH-Vertrag durch die mindestens eine Entität gemäß dem DWH-Vertrag ausgeführt wird, durch Sammlung von Telemetriedaten, die über eines oder mehrere der Folgenden berichten: Produktkettenüberwachung, Regelüberwachung, Einhaltung der Dienstgütevereinbarung (SLA - Service Level Agreement), Einhaltung der Dienstgüte (QoS - Quality ofService) und Einhaltung von Sicherheitsrichtlinien, geeignet sind.
Gerät nach einem oder mehreren der Ansprüche 1-4, wobei die Verarbeitungsschaltungen ferner zum Auswählen der mindestens einen Entität zum Bereitstellen des Netzwerkdienstes aus der Blockchain für DWH-Verträge geeignet sind.
Gerät nach einem oder mehreren der Ansprüche 1-5, wobei der Netzwerkdienst eine virtuelle Netzwerkfunktion (VNF - Virtual Network Function) umfasst.
Gerät nach Anspruch 6, wobei die Verarbeitungsschaltungen ferner zum Orchestrieren mehrerer Anbieter, die diskrete Funktionen zum Bereitstellen der VNF hosten, geeignet sind.
Gerät nach einem oder mehreren der Ansprüche 1-7, wobei Deskriptoren von Einträgen in mindestens einer der Blockchain für selbstsouveräne Identitäten, der Blockchain für DSFC-Verträge oder der Blockchain für DWH-Verträge in NFV-Standards des ETSI (European Telecommunications Standards Institute) definiert sind.
Gerät nach Anspruch 8, wobei zu den Deskriptoren ein Orchestrator-Deskriptor, ein Ressourcen-Deskriptor und ein Netzwerkdienst-Deskriptor zählen und der Netzwerkdienst-Deskriptor eine Orchestrator-Deskriptor-Identität, SLA (Service Level Agreement) -Parameter und finanzielle Bedingungen umfasst.
Gerät nach einem oder mehreren der Ansprüche 1-9, wobei die Verarbeitungsschaltungen ferner zum Erzeugen eines zufälligen selbsterzeugten Identifikators, zum Hashen des Identifikators mit einem kryptografischen Hash zum Bilden eines krypto-gehashten Identifikators und zum Übermitteln des krypto-gehashten Identifikators an die Blockchain für selbstsouveräne Identitäten als ein Blockchain - Identifikator des Gerätes geeignet sind.
Gerät nach einem oder mehreren der Ansprüche 1-10, wobei der DSFC-Vertrag einen Zeitrahmen enthält, für welchen der DSFC-Vertrag gültig ist.
Gerät nach einem oder mehreren der Ansprüche 1-11, wobei der Netzwerkdienst ein verteilter Netzwerkdienst ist und die Verarbeitungsschaltungen ferner zum Ausstellen, mit Hilfe der Blockchain, des DWH-Vertrages und eines Netzwerkdienstvertrages für den verteilten Netzwerkdienst geeignet sind.
Gerät nach einem oder mehreren der Ansprüche 1-12, wobei die Blockchain für selbstsouveräne Identitäten, die DSFC-Blockchain und die DWH-Blockchain über ein einzelnes verteiltes digitales Ledger eingebunden sind.
Speichergerät, welches Anweisungen enthält, wobei die Anweisungen, wenn sie durch Verarbeitungsschaltungen eines Rechengerätes ausgeführt werden, die Verarbeitungsschaltungen zu Folgendem veranlassen: Posten einer Anfrage zur Orchestrierung eines Netzwerkdienstes mit Hilfe einer Blockchain für DSFC (Distributed Service Function Chain - verteilte Dienstfunktionskette) -Verträge, wobei das Rechengerät, der DSFC-Vertrag und der Initiator einer Anfrage für den Netzwerkdienst mit Hilfe einer Blockchain für selbstsouveräne Identitäten identifiziert werden; als Reaktion auf eine Bestimmung mit Hilfe der Blockchain für DSFC-Verträge, dass das Rechengerät den Netzwerkdienst orchestrieren soll, Erstellen einer Dienstfunktionskette für den Netzwerkdienst für mindestens eine Entität zum Bereitstellen des Netzwerkdienstes basierend auf einer Blockchain für DWH (DSFC Workload Hosting) -Verträge, die DWH-Vertragsgebote von Entitäten für den Netzwerkdienst enthält, wobei die Entitäten und der DWH-Vertrag mit Hilfe der Blockchain für selbstsouveräne Identitäten identifiziert werden; und Verifizieren, dass der DWH-Vertrag durch die mindestens eine Entität gemäß dem DWH ausgeführt wird.
Speichergerät nach Anspruch 14, wobei die Anweisungen die Verarbeitungsschaltungen ferner zum Verifizieren, basierend auf der Dienstfunktionskette, dass der DWH-Vertrag durch die mindestens eine Entität gemäß dem DWH-Vertrag ausgeführt wird, durch Sammlung von Telemetriedaten, die über Produktkettenüberwachung, Regelüberwachung, Einhaltung der Dienstgütevereinbarung (SLA - Service Level Agreement), Einhaltung der Dienstgüte (QoS - Quality of Service) und Einhaltung von Sicherheitsrichtlinien berichten, veranlassen.
Speichergerät nach Anspruch 14 oder 15, wobei die Anweisungen die Verarbeitungsschaltungen ferner zum Auswählen der mindestens einen Entität zum Bereitstellen des Netzwerkdienstes aus der Blockchain für DWH-Verträge veranlassen.
Speichergerät nach einem oder mehreren der Ansprüche 14-16, wobei der Netzwerkdienst eine virtuelle Netzwerkfunktion (VNF - Virtual Network Function) umfasst und die Anweisungen die Verarbeitungsschaltungen ferner zum Orchestrieren mehrerer Anbieter, die diskrete Funktionen zum Bereitstellen der VNF hosten, veranlassen.
Speichergerät nach einem oder mehreren der Ansprüche 14-17, wobei die Anweisungen die Verarbeitungsschaltungen ferner zum Erzeugen eines zufälligen selbsterzeugten Identifikators, zum Hashen des Identifikators mit einem kryptografischen Hash zum Bilden eines krypto-gehashten Identifikators und zum Übermitteln des krypto-gehashten Identifikators an die Blockchain für selbstsouveräne Identitäten als ein Blockchain-Identifikator des Rechengerätes veranlassen.
Speichergerät nach einem oder mehreren der Ansprüche 14-18, wobei der Netzwerkdienst ein verteilter Netzwerkdienst ist und die Anweisungen die Verarbeitungsschaltungen ferner zum Ausstellen, mit Hilfe der Blockchain, des DWH-Vertrages und eines Netzwerkdienstvertrages für den verteilten Netzwerkdienst veranlassen.
Speichergerät nach einem oder mehreren der Ansprüche 14-19, wobei die Blockchain für selbstsouveräne Identitäten, die DSFC-Blockchain und die DWH-Blockchain über ein einzelnes verteiltes digitales Ledger eingebunden sind.
Verfahren zum Orchestrieren eines Netzwerkdienstes, welches Folgendes umfasst: Auswählen eines Netzwerkdienstes, der bereitgestellt werden soll; Auswählen eines Orchestrierungsanbieters für den Netzwerkdienst mit Hilfe einer Blockchain für selbstsouveräne Identitäten zum Identifizieren des Orchestrierungsanbieters und einer Blockchain für DSFC (Distributed Service Function Chain - verteilte Dienstfunktionskette) -Verträge zum Verknüpfen des Orchestrierungsanbieters und des Netzwerkdienstes; Erstellen einer Dienstfunktionskette für den Netzwerkdienst für mindestens einen Anbieter zum Hosten diskreter Funktionen, die durch die DSFC identifiziert werden, basierend auf einer Blockchain für DWH (DSFC Workload Hosting) -Verträge, die DWH-Vertragsgebote von Anbietern für den Netzwerkdienst enthält, wobei die Blockchain für DWH-Verträge die Anbieter und die Funktionen verknüpfen soll; und Ausführen des Netzwerkdienstes in Übereinstimmung mit einer Dienstgütevereinbarung (SLA - Service Level Agreement), die durch die Dienstfunktionskette identifiziert wird.
Verfahren nach Anspruch 21, wobei der Netzwerkdienst mit Hilfe einer Virtualisierung von Netzwerkfunktionen (NFV - Network Function Virtualization) bereitgestellt werden soll und mindestens eine der Funktionen eine virtuelle Netzwerkfunktion (VNF - Virtual Network Function) ist.
Verfahren nach Anspruch 22, welches ferner das Orchestrieren mehrerer Anbieter, die diskrete Funktionen zum Bereitstellen der VNF hosten, umfasst.
Verfahren nach einem oder mehreren der Ansprüche 21-23, welches ferner das Sammeln von Telemetriedaten und Verifizieren, basierend auf der Dienstfunktionskette und den Telemetriedaten, dass der DWH-Vertrag durch die mindestens eine Entität gemäß dem DWH-Vertrag ausgeführt wird, umfasst, wobei die Telemetriedaten über Produktkettenüberwachung, Regelüberwachung, Einhaltung der Dienstgütevereinbarung (SLA - Service Level Agreement), Einhaltung der Dienstgüte (QoS - Quality ofService) und Einhaltung von Sicherheitsrichtlinien berichten.
Verfahren nach einem oder mehreren der Ansprüche 21-24, welches ferner, für jeden aus dem Orchestrierungsanbieter und den Anbietern, das Erzeugen eines zufälligen selbsterzeugten Identifikators, das Hashen des Identifikators mit einem kryptografischen Hash zum Bilden eines krypto-gehashten Identifikators und das Übermitteln des krypto-gehashten Identifikators an die Blockchain für selbstsouveräne Identitäten als ein Blockchain-Identifikator umfasst.