DE102022203249A1

DE102022203249A1 - Mehrfachzugriff-edge-computing- (mec-) fahrzeug-zu-alles-(v2x-) interoperabilitätsunterstützung für mehrere v2x-nachrichtenbroker

Info

Publication number: DE102022203249A1
Application number: DE102022203249.7A
Authority: DE
Inventors: Miltiadis Filippou; Dario Sabella
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2021-06-07
Filing date: 2022-04-01
Publication date: 2022-12-08
Also published as: US20250317720A1; US12309673B2; US20220116755A1

Abstract

Ein maschinenlesbares Speichermedium beinhaltet darauf gespeicherte Anweisungen, die bei Ausführung durch eine Verarbeitungsschaltungsanordnung eines Rechenknotens, der betreibbar ist, um einen V2X-Informationsdienst (VIS) in einem MEC-Netzwerk zu implementieren, bewirken, dass die Verarbeitungsschaltungsanordnung Operationen durchführt, die Erkennen einer Subskriptionsanfrage an einen Informationsdienst umfassen. Die Subskriptionsanfrage stammt von einer MEC-Anwendung, die auf einem MEC-Host instanziiert ist, und beinhaltet mindestens ein Filterkriterium, das eine Informationsverarbeitungskonfiguration der MEC-Anwendung angibt. Die Subskriptionsanfrage mit dem mindestens einen Filterkriterium wird an eine Vielzahl von Anbietern des Informationsdienstes weitergeleitet. Eine von mindestens einem der Anbieter empfangene Antwortnachricht wird decodiert. Die Antwortnachricht gibt eine Annahme der Subskriptionsanfrage durch den mindestens einen Anbieter an. Eine Bestätigungsnachricht wird zur Übertragung an die MEC-Anwendung codiert, die die Annahme der Subskriptionsanfrage durch den mindestens einen Anbieter angibt.

Description

PRIORITÄTSANSPRUCH
Diese Anmeldung beansprucht den Nutzen der Priorität der vorläufigen US-Patentanmeldung mit der Seriennummer 63/197,608 , eingereicht am 7. Juni 2021, mit dem Titel „MEC V2X API INTEROPERABILITY SUPPORT FOR MULTIPLE V2X MESSAGE BROKERS,“ (MEC-V2X-API-Interoperabilitätsunterstützung für mehrere V2X-Nachrichtenbroker), wobei die vorläufige Patentanmeldung hiermit durch Bezugnahme in ihrer Gesamtheit aufgenommen wird.
TECHNISCHES GEBIET
Einige Aspekte betreffen drahtlose Kommunikation, einschließlich Edge-Computing- und Next-Generation- (NG-) Kommunikation. Einige Aspekte betreffen Mehrfachzugriff-Edge-Computing- (MEC-) Fahrzeug-zu-Alles- (V2X-) Anwendungsprogrammierschnittstellen- (API-) Interoperabilitätsunterstützung für mehrere V2X-Nachrichtenbroker.
HINTERGRUND
Edge Computing bezieht sich auf allgemeiner Ebene auf den Übergang von Rechen- und Speicherressourcen näher zu Endpunktvorrichtungen (z.B. Verbraucher-Rechenvorrichtungen, Benutzergeräten usw.), um Gesamtbetriebskosten zu optimieren, Anwendungslatenz zu reduzieren, Dienstfähigkeiten zu verbessern und die Einhaltung von Sicherheits- oder Datenschutzanforderungen zu verbessern. Edge-Computing kann in manchen Szenarien einen Cloud-artigen verteilten Dienst bereitstellen, der Orchestrierung und Verwaltung für Anwendungen zwischen vielen Arten von Speicherungs- und Rechenressourcen bietet. Infolgedessen wurden manche Implementierungen von Edge Computing als „Edge-Cloud“ (Rand-Cloud) oder „Fog“ (Nebel) bezeichnet, da leistungsstarke Rechenressourcen, die zuvor nur in großen entfernten Datenzentren verfügbar waren, näher an Endpunkte verlagert und zur Verwendung durch Verbraucher am „Rand“ des Netzwerks verfügbar gemacht werden.
Edge-Computing-Anwendungsfälle in mobilen Netzwerkszenarien wurden zur Integration mit MEC-Ansätzen entwickelt, die auch als „Mehrfachzugriff-Edge-Computing“ bezeichnet werden. MEC-Ansätze sind dafür ausgelegt, Anwendungsentwicklern und Inhaltsanbietern den Zugriff auf Rechenkapazitäten und eine Informationstechnologie- (IT-) Dienstumgebung in dynamischen Mobilnetzumgebungen am Rand des Netzwerks zu ermöglichen. Von der Industrienormungsgruppe (Industry Specification Group, ISG) des Europäischen Instituts für Telekommunikationsnormen (ETSI) wurden eingeschränkte Standards in dem Versuch entwickelt, gemeinsame Schnittstellen zum Betrieb von MEC-Systemen, Plattformen, Hosts, Diensten und Anwendungen zu definieren.
Edge-Computing, MEC und verwandte Technologien versuchen, reduzierte Latenz, erhöhte Ansprechempfindlichkeit und mehr verfügbare Rechenleistung bereitzustellen, als sie in herkömmlichen Cloud-Netzwerkdiensten und Weitverkehrsnetzwerkverbindungen angeboten werden. Die Integration von Mobilität und dynamisch gestarteten Diensten für eine mobile Verwendung und Vorrichtungsverarbeitungs-Anwendungsfälle hat jedoch zu Einschränkungen und Bedenken bei Orchestrierung, Funktionskoordinierung und Ressourcenverwaltung geführt, insbesondere in komplexen Mobilitätsszenarien, in die viele Teilnehmer (Vorrichtungen, Hosts, Mandanten, Dienstanbieter, Betreiber) einbezogen sind.
Gleichermaßen sind Netzwerke und Vorrichtungen des Internets der Dinge (Internet of Things, IoT) dazu ausgelegt, eine verteilte Rechenanordnung aus einer Vielzahl von Endpunkten anzubieten. IoT-Vorrichtungen sind physische oder virtualisierte Objekte, die in einem Netzwerk kommunizieren können und Sensoren, Aktuatoren und andere Eingabe/Ausgabe-Komponenten beinhalten können, die verwendet werden können, um Daten zu sammeln oder Aktionen in einer realen Umgebung durchzuführen. IoT-Einrichtungen können zum Beispiel Endpunktvorrichtungen mit geringem Leistungsverbrauch umfassen, die in alltägliche Dinge, wie Gebäude, Fahrzeuge, Pakete usw. eingebettet oder daran angebracht sind, um eine zusätzliche Ebene der künstlichen sensorischen Wahrnehmung dieser Dinge bereitzustellen. In letzter Zeit sind IoT-Vorrichtungen immer beliebter geworden, und daher haben sich Anwendungen, die diese Vorrichtungen verwenden, stark verbreitet.
Der Einsatz von verschiedenen Edge-, Fog-, MEC-, Privatunternehmens-Netzwerken (z.B. softwaredefinierte Weitverkehrsnetzwerke oder SD-WANs) und IoT-Netzwerken, -Vorrichtungen und -Diensten hat mehrere fortgeschrittene Anwendungsfälle und Szenarien eingeführt, die am und zum Rand des Netzwerks hin auftreten. Diese fortgeschrittenen Anwendungsfälle haben jedoch unter vielen anderen Problemen auch einige entsprechende technische Herausforderungen in Bezug auf Sicherheits-, Verarbeitungs- und Netzwerkressourcen, Dienstverfügbarkeit und Effizienz eingebracht. Eine solche Herausforderung ist MEC-V2X-API-Interoperabilitätsunterstützung für mehrere V2X-Nachrichtenbroker in einer MEC-Infrastruktur.
Figurenliste
In den Zeichnungen, die nicht unbedingt maßstabsgetreu gezeichnet sind, können gleiche Bezugszeichen ähnliche Komponenten in unterschiedlichen Ansichten beschreiben. Gleiche Ziffern mit unterschiedlichen Buchstabensuffixen können unterschiedliche Instanzen ähnlicher Komponenten repräsentieren. Einige Ausführungsformen sind beispielhaft und nicht einschränkend in den Figuren der zugehörigen Zeichnungen veranschaulicht, wobei gilt:

1 veranschaulicht einen Überblick über eine Edge-Cloud-Konfiguration für Edge-Computing unter Verwendung von Slice-Konfigurationsfunktionen (SCF);
2 veranschaulicht Betriebsschichten zwischen Endpunkten, einer Edge-Cloud und Cloud-Rechenumgebungen;
3 veranschaulicht einen beispielhaften Ansatz für Vernetzung und Dienste in einem Edge-Computing-System unter Verwendung der SCF;
4 veranschaulicht den Einsatz einer virtuellen Edge-Konfiguration in einem Edge-Computing-System, wobei SCF zwischen mehreren Edge-Knoten und mehreren Mandanten betrieben wird;
5 veranschaulicht verschiedene Rechenanordnungen, die Container in einem Edge-Computing-System einsetzen;
6 veranschaulicht einen Rechen- und Kommunikationsanwendungsfall, der Mobilzugriff auf Anwendungen in einem Edge-Computing-System unter Verwendung der SCF beinhaltet;
7 veranschaulicht eine MEC-Dienstarchitektur 800 gemäß einigen Ausführungsformen;
8A stellt einen Überblick über Beispielkomponenten zur Berechnung bereit, die in einem Rechenknoten in einem Edge-Computing-System eingesetzt werden;
8B stellt einen weiteren Überblick über Beispielkomponenten innerhalb einer Rechenvorrichtung in einem Edge-Computing-System bereit;
8C veranschaulicht ein Softwareverteilungsplattform gemäß einigen Ausführungsformen;
9A veranschaulicht eine MEC-Netzwerkarchitektur mit MEC-V2X-API-Interoperabilitätsunterstützung für mehrere V2X-Nachrichtenbroker gemäß einer beispielhaften Ausführungsform;
9B veranschaulicht eine MEC-Referenzarchitektur in einer Netzwerkfunktionsvirtualisierungs (Network Function Virtualization, NFV)-Umgebung gemäß einer beispielhaften Ausführungsform;
9C veranschaulicht eine Variante der MEC-Netzwerkarchitektur von 9A, die mit dem MEC-Verbund konfiguriert ist, gemäß einer beispielhaften Ausführungsform;
10 veranschaulicht die Rolle von Nachrichtenbrokern als Teil einer Umgebung, die mehrere Datenquellen mehrerer Mobilnetzbetreiber (mobile network operators, MNOs) in einer MEC-Infrastruktur beinhaltet, gemäß einer beispielhaften Ausführungsform;
11 veranschaulicht mehrere Nachrichtenbroker und ihre Signalisierungsinteraktionen (direkt oder indirekt) mit einer MEC-Anwendung (App), die V2X-Nachrichten beansprucht, sowie mit einer MEC-Plattform mit einem V2X-Informationsdienst (V2X information service, VIS) gemäß einer beispielhaften Ausführungsform;
12 veranschaulicht einen beispielhaften Signalisierungsfluss, der ausgeführt werden kann, wenn mindestens einer der verfügbaren Nachrichtenbroker dasselbe Anwendungsschichtprotokoll (und seine Version) unterstützt wie die MEC-App, die eine Anfrage zum Abonnieren von V2X-Nachrichten sendet, gemäß einer beispielhaften Ausführungsform;
13 veranschaulicht einen beispielhaften Signalisierungsfluss, der ausgeführt werden kann, wenn keiner der verfügbaren Nachrichtenbroker dasselbe Anwendungsschichtprotokoll (und seine Version) unterstützt wie die MEC-App, die eine Anfrage zum Abonnieren von V2X-Nachrichten sendet, gemäß einer beispielhaften Ausführungsform; und
14 veranschaulicht ein Flussdiagramm eines Verfahrens zum Durchführen einer VIS-Konfiguration in einem MEC-Netzwerk gemäß einer beispielhaften Ausführungsform.

AUSFÜHRLICHE BESCHREIBUNG
Die folgenden Ausführungsformen betreffen allgemein Verfahren, Konfigurationen und Einrichtungen zum Bereitstellen einer MEC-API-Interoperabilitätsunterstützung für mehrere V2X-Nachrichtenbroker in einer MEC-Infrastruktur. Die folgenden Beispiele führen spezifische Konfigurationen und Verwendung der V2X-Informationsdienst- (VIS-) Maschen-Steuerebene zum Bereitstellen von MEC-V2X-API-Interoperabilitätsunterstützung ein. Beispielhafte Ausführungsformen können in Systemen implementiert werden, die jenen ähnlich sind, die in einem beliebigen der nachstehend unter Bezugnahme auf 1 - 8C beschriebenen Systeme gezeigt sind. Eine zusätzliche Beschreibung verschiedener Netzwerkentitäten, die VIS-Funktionen verwenden, konfigurieren oder durchführen, wird hierin nachstehend in Verbindung zumindest mit 9A - 14 bereitgestellt.
1 ist ein Blockdiagramm 100, das einen Überblick über eine Konfiguration für Edge-Computing zeigt, die eine Verarbeitungsschicht beinhaltet, die in vielen der folgenden Beispiele als „Edge-Cloud“ bezeichnet wird. Wie gezeigt, befindet sich die Edge-Cloud 110 gemeinsam an einem Randort, wie etwa einem Zugangspunkt oder einer Basisstation 140, einem lokalen Verarbeitungs-Hub 150 oder einer Zentrale 120, und kann somit mehrere Entitäten, Vorrichtungen und Geräteinstanzen beinhalten. Die Edge-Cloud 110 befindet sich viel näher an den Endpunkt- (Verbraucher und Erzeuger) Datenquellen 160 (z.B. autonome Fahrzeuge 161, Benutzergerät 162, Geschäfts- und Industriegerät 163, Videoaufnahmevorrichtungen 164, Drohnen 165, intelligente Städte und Gebäudevorrichtungen 166, Sensoren und IoT-Vorrichtungen 167 usw.) als das Cloud-Datenzentrum 130. Rechen-, Speicher- und Speicherungsressourcen, die an den Rändern in der Edge-Cloud 110 angeboten werden, sind kritisch für das Bereitstellen von Reaktionszeiten mit ultraniedriger Latenz für Dienste und Funktionen, die durch die Endpunktdatenquellen 160 verwendet werden, sowie für das Reduzieren von Netzwerk-Backhaul-Verkehr von der Edge-Cloud 110 zu dem Cloud-Datenzentrum 130, wodurch neben anderen Vorteilen Energieverbrauch und Gesamtnetzwerknutzungen verbessert werden.
Berechnung, Speicher und Speicherung sind knappe Ressourcen und nehmen im Allgemeinen in Abhängigkeit vom Edge-Standort ab (wobei z.B. weniger Verarbeitungsressourcen an Verbraucherendpunktvorrichtungen verfügbar sind als an einer Basisstation, als an einer Zentrale). Je näher sich der Edge-Ort jedoch am Endpunkt (z.B. Benutzergerät (UE)) befindet, desto mehr sind Raum und Leistung häufig eingeschränkt. Somit versucht Edge-Computing, die Anzahl von Ressourcen, die für Netzwerkdienste benötigt werden, durch die Verteilung von mehr Ressourcen, die sich sowohl geografisch als auch in der netzwerkinternen Zugriffszeit näher befinden, zu reduzieren. Auf diese Weise versucht Edge-Computing, die Rechenressourcen gegebenenfalls zu den Arbeitslastdaten zu bringen oder die Arbeitslastdaten zu den Rechenressourcen zu bringen.
Im Folgenden werden Aspekte einer Edge-Cloud-Architektur beschrieben, die mehrere potentielle Einsätze abdeckt und Einschränkungen behandelt, die einige Netzwerkbetreiber oder Dienstanbieter möglicherweise in ihren Infrastrukturen haben. Diese beinhalten die Variation von Konfigurationen basierend auf dem Edge-Ort (weil Edges auf einer Basisstationsebene zum Beispiel eine stärker eingeschränkte Leistungsfähigkeit und stärker eingeschränkte Fähigkeiten in einem mandantenfähigen Szenario aufweisen können); Konfigurationen basierend auf der Art der Berechnung, des Speichers, der Speicherung, der Fabric, der Beschleunigung oder ähnlichen Ressourcen, die für Edge-Orte, Ebenen von Orten oder Gruppen von Orten verfügbar sind; die Dienst-, Sicherheits- und Verwaltungs- und Orchestrierungsfähigkeiten; und verwandte Ziele, um Nutzbarkeit und Leistungsfähigkeit von Enddiensten zu erreichen. Diese Bereitstellungen können ein Verarbeiten in Netzwerkschichten bewerkstelligen, die in Abhängigkeit von Latenz-, Entfernungs- und Zeitgebungsmerkmalen als „Near Edge“-, „Close Edge“-, „Local Edge“-, „Middle Edge“- oder „Far Edge“-Schichten betrachtet werden können.
Edge-Computing ist ein sich entwickelndes Paradigma, bei dem die Berechnung am oder näher am Rand („Edge“) eines Netzwerks durchgeführt wird, typischerweise durch die Verwendung einer Rechenplattform (z.B. x86- oder ARM-Rechenhardwarearchitektur), die an Basisstationen, Gateways, Netzwerkroutern oder anderen Vorrichtungen implementiert ist, die sich viel näher an Endpunktvorrichtungen befinden, die Daten erzeugen und verbrauchen. Edge-Gateway-Server können zum Beispiel mit Pools von Speicher- und Speicherungsressourcen ausgestattet sein, um eine Berechnung in Echtzeit für Anwendungsfälle mit niedriger Latenz (z.B. autonomes Fahren oder Videoüberwachung) für verbundene Client-Vorrichtungen durchzuführen. Als ein Beispiel können Basisstationen mit Rechen- und Beschleunigungsressourcen erweitert werden, um Dienstarbeitslasten für verbundene Benutzergeräte direkt zu verarbeiten, ohne weiter Daten über Backhaul-Netzwerke zu kommunizieren. Als ein anderes Beispiel kann Zentralnetzwerkverwaltungshardware durch standardisierte Rechenhardware ersetzt werden, die virtualisierte Netzwerkfunktionen durchführt und Rechenressourcen für die Ausführung von Diensten und Verbraucherfunktionen für verbundene Vorrichtungen bietet. Innerhalb von Edge-Computing-Netzen kann es Szenarien in Diensten geben, in denen die Rechenressource zu den Daten „verschoben“ wird, sowie Szenarien, in denen die Daten zu der Rechenressource „verschoben“ werden. Als ein Beispiel können Rechen-, Beschleunigungs- und Netzwerkressourcen der Basisstation Dienste bereitstellen, um die Arbeitslastanforderungen nach Bedarf durch Aktivieren ruhender Kapazität (Subskription, Kapazität nach Bedarf) anzupassen, um Ausnahme- und Notfälle zu verwalten oder um Langlebigkeit für eingesetzte Ressourcen über einen wesentlich längeren implementierten Lebenszyklus bereitzustellen.
In einigen Aspekten können die Edge-Cloud 110 und das Cloud-Datenzentrum 130 mit V2X-Informationsdienst- (VIS-) Funktionen 111 konfiguriert sein. Beispielhafte VIS-Funktionen beinhalten eine Konfiguration eines V2X-Nachrichtensubskriptionsdienstes für V2X-Nachrichtenbroker, die eine Subskription durch V2X-Nachrichtenkonsumenten bei V2X-Nachrichtenbrokern und Protokollkonvertierung für Subskriptionsdaten ermöglicht, die zwischen V2X-Nachrichtenkonsumenten und V2X-Nachrichtenbrokern kommuniziert werden, wobei die Funktionalitäten in Verbindung mit 9A - 14 ausführlicher erörtert werden.
2 veranschaulicht Betriebsschichten zwischen Endpunkten, einer Edge-Cloud und Cloud-Computing-Umgebungen. Insbesondere stellt 2 Beispiele für Rechenverwendungsfälle 205 dar, die die Edge-Cloud 110 unter mehreren veranschaulichenden Schichten des Netzwerk-Computing nutzen. Die Schichten beginnen bei einer Endpunkt- (Vorrichtungen und Dinge) Schicht 200, die auf die Edge-Cloud 110 zugreift, um Datenerzeugungs-, Analyse- und Datenverbrauchsaktivitäten durchzuführen. Die Edge-Cloud 110 kann mehrere Netzwerkschichten umspannen, wie etwa eine Edge-Vorrichtungsschicht 210 mit Gateways, Servern vor Ort oder Netzwerkgeräten (Knoten 215), die sich in physisch nahen Edge-Systemen befinden; eine Netzwerkzugangsschicht 220, umfassend Basisstationen, Funkverarbeitungseinheiten, Netzwerk-Hubs, regionale Rechenzentren (DC) oder lokale Netzwerkgeräte (Geräte 225); und beliebige Geräte, Vorrichtungen oder Knoten, die sich dazwischen befinden (in Schicht 212, nicht ausführlich veranschaulicht). Die Netzwerkkommunikationen innerhalb der Edge-Cloud 110 und zwischen den verschiedenen Schichten können über eine beliebige Anzahl von drahtgebundenen oder drahtlosen Medien stattfinden, einschließlich über Konnektivitätsarchitekturen und Technologien, die nicht dargestellt sind. Jeder der Kommunikationsanwendungsfälle 205 kann mit SMCP-Funktionen 111 konfiguriert sein, die durch einen Kommunikationsknoten, der als eine Orchestrierungsverwaltungsentität konfiguriert ist, oder einen MEC-Host innerhalb eines MEC-Netzwerks durchgeführt werden können oder (2) durch eine Platinenverwaltungssteuerung (Board Management Controller, BMC) eines Rechenknotens durchgeführt werden können. Beispielhafte VIS-Funktionen werden in Verbindung mit 9A - 14 ausführlicher erläutert.
Beispiele für Latenz, die aus Netzwerkkommunikationsentfernungs- und Verarbeitungszeitbeschränkungen resultieren, können von weniger als einer Millisekunde (ms), wenn inmitten der Endpunktschicht 200, unter 5 ms an der Edge-Vorrichtungsschicht 210, bis sogar zwischen 10 und 40 ms, wenn mit Knoten an der Netzwerkzugangsschicht 220 kommuniziert, reichen. Jenseits der Edge-Cloud 110 befinden sich die Kernnetzschicht 230 und die Cloud-Datenzentrumschicht 240, jeweils mit zunehmender Latenz (z.B. zwischen 50 - 60 ms auf der Kernnetzschicht 230 bis 100 oder mehr ms auf der Cloud-Datenzentrumschicht). Infolgedessen werden Operationen in einem Kernnetz-Datenzentrum 235 oder einem Cloud-Datenzentrum 245 mit Latenzen von mindestens 50 bis 100 ms oder mehr nicht in der Lage sein, viele zeitkritische Funktionen der Anwendungsfälle 205 zu erfüllen. Jeder dieser Latenzwerte wird zu Veranschaulichungs- und Kontrastzwecken bereitgestellt; es versteht sich, dass die Verwendung anderer Zugangsnetzwerkmedien und -technologien die Latenzen weiter reduzieren kann. In einigen Beispielen können jeweilige Abschnitte des Netzwerks relativ zu einer Netzwerkquelle und einem Netzwerkziel als „Close Edge“-, „Local Edge“-, „Near Edge“-, „Middle Edge“- oder „Far Edge“-Schichten kategorisiert sein. Beispielsweise kann aus der Perspektive des Kernnetz-Datenzentrums 235 oder eines Cloud-Datenzentrums 245 ein Zentralamt- oder Inhaltsdatennetzwerk als innerhalb einer „nahen Rand“-Schicht („nahe“ an der Cloud, mit hohen Latenzwerten, wenn mit den Vorrichtungen und Endpunkten der Nutzungsfälle 205 kommuniziert) befindlich betrachtet werden, wohingegen ein Zugangspunkt, eine Basisstation, ein Vor-Ort-Server oder ein Netzwerk-Gateway als innerhalb einer „fernen Rand“-Schicht („fern“ von der Cloud entfernt, mit niedrigen Latenzwerten, wenn mit den Vorrichtungen und Endpunkten der Nutzungsfälle 205 kommuniziert) befindlich betrachtet werden können. Es versteht sich, dass andere Kategorisierungen einer bestimmten Netzwerkschicht als eine „Close“-, „Local“-, „Near“-, „Middle“- oder „Far“-Edge bildend auf Latenz, Entfernung, einer Anzahl von Netzwerk-Hops oder anderen messbaren Eigenschaften, wie von einer Quelle in einer beliebigen der Netzwerkschichten 200-240 gemessen, basieren können.
Die diversen Anwendungsfälle 205 können auf Ressourcen unter Nutzungsdruck von eingehenden Strömen aufgrund mehrerer Dienste, die die Edge-Cloud nutzen, zugreifen. Um Ergebnisse mit niedriger Latenz zu erzielen, gleichen die Dienste, die innerhalb der Edge-Cloud 110 ausgeführt werden, variierende Anforderungen aus hinsichtlich (a) Priorität (Durchsatz oder Latenz; auch als Dienstgüteziel oder SLO bezeichnet) und Dienstqualität (QoS) (z. B. kann Verkehr für ein autonomes Auto eine höhere Priorität als ein Temperatursensor hinsichtlich der Reaktionszeitanforderung aufweisen; oder eine Leistungsfähigkeitsempfindlichkeit bzw. ein Leistungsfähigkeitsengpass kann je nach Anwendung an einer Rechen-/Beschleuniger-, Speicher-, Speicherungs- oder Netzwerkressource existieren); (b) Zuverlässigkeit und Ausfallsicherheit (z. B. muss auf einige Eingangsströme reagiert werden und der Verkehr mit missionskritischer Zuverlässigkeit geroutet werden, wohingegen einige andere Eingangsströme je nach Anwendung eine gelegentliche Störung tolerieren können); und (c) physikalischer Beschränkungen (z. B. Leistung, Kühlung und Formfaktor).
Die Ende-zu-Ende-Dienstansicht für diese Anwendungsfälle beinhaltet das Konzept eines Dienstflusses und ist mit einer Transaktion assoziiert. Die Transaktion gibt die Gesamtdienstanforderung für die Entität an, die den Dienst verbraucht, sowie die zugehörigen Dienste für die Ressourcen, Arbeitslasten, Workflows und Geschäftsfunktions- und Geschäftsebenenanforderungen. Die Dienste, die mit den beschriebenen „Begriffen“ ausgeführt werden, können in jeder Schicht auf eine Weise verwaltet werden, dass Echtzeit- und Laufzeitvertragskonformität für die Transaktion während des Lebenszyklus des Dienstes sichergestellt wird. Wenn eine Komponente in der Transaktion ihre vereinbarte Dienstgütevereinbarung (SLA, Service Level Agreement) verfehlt, kann das System als Ganzes (Komponenten in der Transaktion) die Fähigkeit bereitstellen, (1) die Auswirkung der SLA-Verletzung zu verstehen und (2) andere Komponenten in dem System zu erweitern, um die gesamte Transaktions-SLA wiederaufzunehmen, und (3) Schritte zu implementieren, um Abhilfe zu schaffen.
Dementsprechend kann unter Berücksichtigung dieser Variationen und Dienstleistungsmerkmale Edge-Computing innerhalb der Edge-Cloud 110 die Fähigkeit bereitstellen, mehrere Anwendungen der Anwendungsfälle 205 (z. B. Objektverfolgung, Videoüberwachung, verbundene Autos usw.) in Echtzeit oder nahezu Echtzeit zu bedienen und auf diese zu reagieren und Anforderungen ultraniedriger Latenz für diese mehreren Anwendungen zu erfüllen. Diese Vorteile ermöglichen eine ganz neue Klasse von Anwendungen (virtuelle Netzwerkfunktionen (VNFs), Function as a Service (FaaS), Edge as a Service (EaaS), Standardprozesse usw.), die herkömmliches Cloud-Computing aufgrund von Latenz- oder anderen Einschränkungen nicht nutzen können.
Mit den Vorteilen des Edge-Computing ergeben sich jedoch die folgenden Vorbehalte. Die an der Edge befindlichen Vorrichtungen sind häufig ressourcenbeschränkt, und deshalb besteht Druck auf die Nutzung von Edge-Ressourcen. Typischerweise wird dies durch das Pooling von Speicher- und Speicherungsressourcen zur Verwendung durch mehrere Benutzer (Mandanten) und Vorrichtungen behandelt. Die Edge kann in Leistung und Kühlung eingeschränkt sein, und daher muss der Leistungsverbrauch durch die Anwendungen berücksichtigt werden, die die meiste Leistung verbrauchen. Es kann inhärente Leistungs-Leistungsfähigkeits-Kompromisse in diesen gepoolten Speicherressourcen geben, da viele von ihnen wahrscheinlich neu entwickelte Speichertechnologien verwenden, bei denen bei mehr Leistung eine größere Speicherbandbreite notwendig ist. Gleichermaßen sind verbesserte Sicherheit von Hardware und vertrauenswürdigen Root-of-Trust-Funktionen ebenfalls erforderlich, da Edge-Orte unbemannt sein können und sogar zugelassenen Zugriff benötigen können (z.B. wenn sie an einem Standort eines Dritten untergebracht sind). Solche Probleme vergrößern sich in der Edge-Cloud 110 in einem Multi-Mandanten-, Multi-Eigentümer- oder Multi-Zugriffs-Umfeld, in dem Dienste und Anwendungen von vielen Benutzern angefordert werden, insbesondere da die Netzwerkverwendung dynamisch schwankt und sich die Zusammensetzung der mehreren Stakeholder, Anwendungsfälle und Dienste ändert.
Auf einem mehr generischen Level kann ein Edge-Computing-System so beschrieben werden, dass es eine beliebige Anzahl von Einsätzen auf den zuvor erörterten Schichten umfasst, die in der Edge-Cloud 110 arbeiten (Netzwerkschichten 200 - 240) und die eine Koordination der Client- und verteilten Rechenvorrichtungen bereitstellen. Ein oder mehrere Edge-Gateway-Knoten, ein oder mehrere Edge-Aggregationsknoten und ein oder mehrere Kernrechenzentren können über Schichten des Netzwerks verteilt sein, um eine Implementierung des Edge-Rechensystems durch oder im Auftrag eines Telekommunikationsdienstanbieters („Telco“ oder „TSP“), eines Internet-der-Dinge-Dienstanbieters, des Cloud-Dienstanbieters (CSP), einer Unternehmensentität oder einer beliebigen anderen Anzahl von Entitäten bereitzustellen. Verschiedene Implementierungen und Konfigurationen des Edge-Computing-Systems können dynamisch bereitgestellt werden, wie etwa bei Orchestrierung, um Dienstziele zu erfüllen.
Im Einklang mit den vorliegend bereitgestellten Beispielen kann ein Client-Rechenknoten als eine beliebige Art von Endpunktkomponente, -vorrichtung, -gerät oder anderem Ding realisiert sein, das fähig ist, als ein Erzeuger oder Verbraucher von Daten zu kommunizieren. Ferner bedeutet die Kennzeichnung „Knoten“ oder „Vorrichtung“, wie sie im Edge-Computing-System verwendet wird, nicht notwendigerweise, dass ein derartiger Knoten oder eine derartige Vorrichtung in einer Client- oder Agent-/Minion-/Followerrolle betrieben wird; vielmehr bezeichnen beliebige der Knoten oder Vorrichtungen im Edge-Computing-System einzelne Entitäten, Knoten oder Subsysteme, die diskrete oder verbundene Hardware- oder Softwarekonfigurationen aufweisen, um die Edge-Cloud 110 zu ermöglichen oder zu verwenden.
Als solche ist die Edge-Cloud 110 aus Netzwerkkomponenten und funktionalen Merkmalen gebildet, die durch und innerhalb von Edge-Gatewayknoten, Edge-Aggregationsknoten oder anderen Edge-Rechenknoten unter den Netzwerkschichten 210-230 betrieben werden. Die Edge-Cloud 110 kann somit als eine beliebige Art von Netzwerk realisiert sein, die Edge-Computing- und/oder Speicherressourcen bereitstellt, die sich in der Nähe von Funkzugangsnetzwerk (RAN)-fähigen Endpunktvorrichtungen (z. B. mobilen Rechenvorrichtungen, IoT-Vorrichtungen, Smart-Vorrichtungen usw.) befinden, die hierin erörtert werden. Mit anderen Worten, kann die Edge-Cloud 110 als ein „Edge“ betrachtet werden, der die Endpunktvorrichtungen und herkömmliche Netzwerkzugangspunkte verbindet, die als Eintrittspunkt in Kernnetzwerke von Dienstanbietern dienen, einschließlich mobilen Trägernetzerkwerken (z. B. Global System for Mobile Communication (GSM)-Netzwerke, Long-Term Evolution (LTE)-Netzwerke, 5G/6G-Netzwerke usw.), während sie auch Speicher- und/oder Rechenkapazitäten bereitstellen. Andere Arten und Formen von Netzwerkzugang (z. B. WiFi, Long-Range-Wireless, drahtgebundene Netzwerke einschließlich optischer Netzwerke) können auch anstelle von oder in Kombination mit solchen 3GPP-Trägernetzen genutzt werden.
Die Netzwerkkomponenten der Edge-Cloud 110 können Server, mandantenfähige Server, Geräterechenvorrichtungen und/oder eine beliebige andere Art von Rechenvorrichtungen sein. Zum Beispiel kann die Edge-Cloud 110 eine Geräterechenvorrichtung beinhalten, die eine eigenständige elektronische Vorrichtung einschließlich eines Gehäuses, eines Chassis, einer Hülle oder einer Schale ist. Unter Umständen kann die Einhausung für Portabilität dimensioniert sein, sodass sie von einem Menschen getragen und/oder versandt werden kann. Beispielhafte Gehäuse können Materialien beinhalten, die eine oder mehrere Außenflächen bilden, die die Inhalte des Geräts teilweise oder vollständig schützen, wobei der Schutz Wetterschutz, Schutz in gefährlichen Umgebungen (z.B. EMI, Vibration, extreme Temperaturen) beinhalten und/oder Tauchfähigkeit ermöglichen kann. Beispielhafte Gehäuse können Leistungsschaltungsanordnungen beinhalten, um Leistung für stationäre und/oder portable Implementierungen bereitzustellen, wie etwa Wechselstromeingänge, Gleichstromeingänge, AC/DC- oder DC/AC-Wandler, Leistungsregler, Transformatoren, Ladeschaltungsanordnungen, Batterien, drahtgebundene Eingänge und/oder drahtlose Leistungseingänge. Beispielhafte Gehäuse und/oder Oberflächen davon können Montagehardware beinhalten oder damit verbunden sein, um Befestigung an Strukturen, wie etwa Gebäuden, Telekommunikationsstrukturen (z.B. Masten, Antennenstrukturen usw.) und/oder Racks (z.B. Server-Racks, Blade-Halterungen usw.), zu ermöglichen. Beispielhafte Gehäuse und/oder Oberflächen davon können einen oder mehrere Sensoren (z.B. Temperatursensoren, Vibrationssensoren, Lichtsensoren, Akustiksensoren, kapazitive Sensoren, Näherungssensoren usw.) unterstützen. Ein oder mehrere solcher Sensoren können in der Oberfläche enthalten, von dieser getragen oder anderweitig darin eingebettet und/oder an der Oberfläche des Geräts befestigt sein. Beispielhafte Einhausungen und/oder Oberflächen davon können mechanische Konnektivität unterstützen, wie etwa Antriebshardware (z.B. Räder, Propeller usw.) und/oder Gelenkhardware (z.B. Roboterarme, schwenkbare Anhänge usw.). Unter manchen Umständen können die Sensoren eine beliebige Art von Eingabevorrichtungen beinhalten, wie Benutzerschnittstellenhardware (z.B. Tasten, Schalter, Wählscheiben, Schieber usw.). Unter Umständen umfassen beispielhafte Gehäuse Ausgabevorrichtungen, die darin enthalten sind, dadurch getragen werden, darin eingebettet und/oder daran angebracht sind. Ausgabevorrichtungen können Anzeigen, Touchscreens, Leuchten, LEDs, Lautsprecher, E/A-Anschlüsse (z.B. USB) usw. beinhalten. Unter Umständen sind Edge-Vorrichtungen Vorrichtungen, die im Netzwerk für einen spezifischen Zweck (z.B. eine Verkehrsampel) vorhanden sind, können aber Verarbeitungs- und/oder andere Kapazitäten aufweisen, die für andere Zwecke genutzt werden können. Solche Edge-Vorrichtungen können unabhängig von anderen vernetzten Vorrichtungen sein und können mit einem Gehäuse bereitgestellt sein, das einen Formfaktor aufweist, der für ihren primären Zweck geeignet ist; aber dennoch für andere Rechenaufgaben verfügbar sein, die ihre primäre Aufgabe nicht stören. Edge-Vorrichtungen beinhalten Vorrichtungen des Internets der Dinge. Die Geräterechenvorrichtung kann Hardware-und Softwarekomponenten beinhalten, um lokale Probleme, wie etwa Vorrichtungstemperatur, Vibration, Ressourcennutzung, Aktualisierungen, Leistungsversorgungsprobleme, physische und Netzwerksicherheit usw., zu verwalten. Beispielhafte Hardware zum Implementieren einer Geräterechenvorrichtung ist in Verbindung mit 8A - 8C beschrieben. Die Edge-Cloud 110 kann auch einen oder mehrere Server und/oder einen oder mehrere mandantenfähige Server beinhalten. Ein solcher Server kann ein Betriebssystem und eine virtuelle Rechenumgebung beinhalten. Eine virtuelle Rechenumgebung kann einen Hypervisor beinhalten, der eine oder mehrere virtuelle Maschinen, einen oder mehrere Container usw. verwaltet (z.B. erzeugt, einsetzt, zerstört usw.). Solche virtuellen Rechenumgebungen stellen eine Ausführungsumgebung bereit, in der eine oder mehrere Anwendungen und/oder andere Software, anderer Code oder andere Skripte ausgeführt werden können, während sie von einer oder mehreren anderen Anwendungen, Software, Code oder Skripten isoliert sind.
In 3 tauschen verschiedene Client-Endpunkte 310 (in der Form von Mobilvorrichtungen, Computern, autonomen Fahrzeugen, Unternehmensrechenanlagen, industriellen Verarbeitungsanlagen) Anfragen und Antworten aus, die für die Art der Endpunktnetzwerkaggregation spezifisch sind. Beispielsweise können Client-Endpunkte 310 Netzwerkzugang über ein drahtgebundenes Breitbandnetzwerk erhalten, indem Anfragen und Antworten 322 durch ein Vor-Ort-Netzwerksystem 332 ausgetauscht werden. Einige Client-Endpunkte 310, wie etwa mobile Rechenvorrichtungen, können Netzwerkzugang über ein drahtloses Breitbandnetzwerk erhalten, indem Anfragen und Antworten 324 durch einen Zugangspunkt (z.B. Mobilfunknetzturm) 334 ausgetauscht werden. Einige Client-Endpunkte 310, wie etwa autonome Fahrzeuge, können Netzwerkzugang für Anfragen und Antworten 326 über ein drahtloses Fahrzeugnetzwerk durch ein auf Straßen angeordnetes Netzwerksystem 336 erhalten. Unabhängig von der Art des Netzwerkzugangs kann der TSP jedoch Aggregationspunkte 342, 344 innerhalb der Edge-Cloud 110 einsetzen, um Verkehr und Anfragen zu aggregieren. Somit kann der TSP innerhalb der Edge-Cloud 110 verschiedene Rechen- und Speicherressourcen bereitstellen, wie etwa an Edge-Aggregationsknoten 340, um angeforderten Inhalt bereitzustellen. Die Edge-Aggregationsknoten 340 und andere Systeme der Edge-Cloud 110 sind mit einer Cloud oder einem Rechenzentrum 360 verbunden, das ein Backhaul-Netzwerk 350 verwendet, um Anfragen mit höherer Latenz von einer Cloud/einem Rechenzentrum für Websites, Anwendungen, Datenbankserver usw. zu erfüllen. Zusätzliche oder konsolidierte Instanzen der Edge-Aggregationsknoten 340 und der Aggregationspunkte 342, 344, einschließlich jener, die auf einem einzigen Server-Framework eingesetzt werden, können auch innerhalb der Edge-Cloud 110 oder anderer Bereiche der TSP-Infrastruktur vorhanden sein.
In einer beispielhaften Ausführungsform nutzen die Edge-Cloud 110 und die Cloud oder das Datenzentrum 360 VIS-Funktionen 111 in Verbindung mit offenbarten Techniken. Die VIS-Funktionen 111 können durch einen Kommunikationsknoten durchgeführt werden, der als eine Orchestrierungsverwaltungsentität oder ein MEC-Host innerhalb eines MEC-Netzwerks konfiguriert ist, oder (2) durch eine Platinenverwaltungssteuerung (BMC) eines Rechenknotens durchgeführt werden. Beispielhafte VIS-Funktionen werden in Verbindung mit 9A - 14 ausführlicher erläutert.
4 veranschaulicht Einsatz und Orchestrierung für virtuelle Edge-Konfigurationen quer durch ein Edge-Rechensystem, das zwischen mehreren Edge-Knoten und mehreren Mandanten betrieben wird. Insbesondere stellt 4 die Koordination eines ersten Edge-Knotens 422 und eines zweiten Edge-Knotens 424 in einem Edge-Computing-System 400 dar, um Anfragen und Antworten für verschiedene Client-Endpunkte 410 (z.B. Systeme intelligenter Städte/Gebäude, Mobilvorrichtungen, Rechenvorrichtungen, Unternehmens-/Logistiksysteme, Industriesysteme usw.) zu erfüllen, die auf verschiedene virtuelle Edge-Instanzen zugreifen. Hierbei stellen die virtuellen Edge-Instanzen 432, 434 (oder virtuellen Edges) Edge-Rechenfähigkeiten und Verarbeitung in einer Edge-Cloud mit Zugang zu einem Cloud-/Datenzentrum 440 für Anfragen mit höherer Latenz für Websites, Anwendungen, Datenbankserver usw. bereit. Die Edge-Cloud ermöglicht jedoch die Koordination der Verarbeitung zwischen mehreren Edge-Knoten für mehrere Mandanten oder Entitäten.
In dem Beispiel von 4 beinhalten diese virtuellen Edge-Instanzen: eine erste virtuelle Edge-Instanz 432, die einem ersten Mandanten (Mandant 1) angeboten wird und die erste Kombination von Edge-Speicherung, -Computing und -Diensten anbietet; und eine zweite virtuelle Edge 434, die eine zweite Kombination von Edge-Speicherung, -Computing und -Diensten anbietet. Die virtuellen Edge-Instanzen 432, 434 sind unter den Edge-Knoten 422, 424 verteilt und können Szenarien beinhalten, in denen eine Anfrage und Antwort von demselben oder verschiedenen Edge-Knoten erfüllt werden. Die Konfiguration der Edge-Knoten 422, 424 zum Arbeiten auf eine verteilte, aber koordinierte Weise erfolgt basierend auf Edge-Bereitstellungsfunktionen 450. Die Funktionalität der Edge-Knoten 422, 424 zum Bereitstellen eines koordinierten Betriebs für Anwendungen und Dienste unter mehreren Mandanten basiert auf Orchestrierungsfunktionen 460.
In einer beispielhaften Ausführungsform können die Edge-Bereitstellungsfunktionen 450 und die Orchestrierungsfunktionen 460 VIS-Funktionen 111 in Verbindung mit offenbarten Techniken nutzen. Die VIS-Funktionen 111 können durch einen Kommunikationsknoten durchgeführt werden, der als eine Orchestrierungsverwaltungsentität oder ein MEC-Host innerhalb eines MEC-Netzwerks konfiguriert ist, oder (2) durch eine Platinenverwaltungssteuerung (BMC) eines Rechenknotens durchgeführt werden. Beispielhafte VIS-Funktionen werden in Verbindung mit 9A - 14 ausführlicher erläutert.
Es versteht sich, dass einige der Vorrichtungen in den verschiedenen Client-Endpunkten 410 mandantenfähige Vorrichtungen sind, wobei Mandant 1 innerhalb eines Mandant-1-,Slice' funktionieren kann, während Mandant 2 innerhalb eines Mandant-2-Slice funktionieren kann (und in weiteren Beispielen können zusätzliche oder Untermandanten existieren; und jeder Mandant kann sogar spezifisch zu einem spezifischen Satz von Merkmalen bis hin zu spezifischen Hardwaremerkmalen berechtigt und transaktionell daran gebunden sein). Eine vertrauenswürdige mandantenfähige Vorrichtung kann ferner einen mandantenspezifischen kryptografischen Schlüssel enthalten, so dass die Kombination aus Schlüssel und Slice als „Root of Trust“ (RoT, Vertrauensbasis) oder mandantenspezifische RoT angesehen werden kann. Eine RoT kann ferner dynamisch unter Verwendung einer DICE- (Device Identity Composition Engine, Vorrichtungsidentitätszusammensetzungs-Engine) Architektur berechnet werden, so dass ein einzelner DICE-Hardware-Baustein verwendet werden kann, um geschichtete vertrauenswürdige Rechenbasiskontexte zum Schichten von Vorrichtungsfähigkeiten (wie etwa ein frei programmierbares Gate-Array (FPGA)) zu konstruieren. Der RoT kann ferner für einen vertrauenswürdigen Rechenkontext verwendet werden, um eine „Ausfächerung“ zu ermöglichen, die zum Unterstützen einer Multi-Mandantenfähigkeit nützlich ist. Innerhalb einer Multi-Mandanten-Umgebung können die jeweiligen Edge-Knoten 422, 424 als Durchsetzungspunkte für Sicherheitsmerkmale für lokale Ressourcen arbeiten, die mehreren Mandanten pro Knoten zugeteilt sind. Zusätzlich können Mandantenlaufzeit- und Anwendungsausführung (z.B. in den virtuellen Edge-Instanzen 432, 434) als ein Durchsetzungspunkt für ein Sicherheitsmerkmal dienen, das eine virtuelle Edge-Abstraktion von Ressourcen erzeugt, die potenziell mehrere physische Hosting-Plattformen überspannen. Schließlich können die Orchestrierungsfunktionen 460 an einer Orchestrierungsentität als ein Sicherheitsmerkmal-Durchsetzungspunkt zum Anordnen von Ressourcen entlang Mandantengrenzen arbeiten.
Randrechenknoten können Ressourcen (Speicher, Zentralverarbeitungseinheit (CPU), Grafikverarbeitungseinheit (GPU), Interruptsteuerung, Eingabe/Ausgabe (E/A) - Steuerung, Speichersteuerung, Bussteuerung usw.) partitionieren, wobei jeweilige Partitionen eine RoT-Fähigkeit enthalten können und wobei Fan-Out und Schichtbildung gemäß einem DICE-Modell ferner auf Randknoten angewendet werden können. Cloud-Rechenknoten, die aus Containern, FaaS-Engines, Servlets, Servern oder einer anderen Berechnungsabstraktion bestehen, können gemäß einer DICE-Schichtungs- und Fan-Out-Struktur partitioniert werden, um jeweils einen RoT-Kontext zu unterstützen. Dementsprechend können die jeweiligen RoTs überspannenden Vorrichtungen in 410, 422 und 440 die Einrichtung einer verteilten vertrauenswürdigen Rechenbasis (DTCB) koordinieren, so dass ein mandantenspezifischer virtueller vertrauenswürdiger sicherer Kanal, der alle Elemente Ende an Ende verbindet, eingerichtet werden kann.
Ferner versteht es sich, dass ein Container Daten oder arbeitslastspezifische Schlüssel aufweisen kann, die seinen Inhalt vor einem vorherigen Randknoten schützen. Als Teil der Migration eines Containers kann eine POD-Steuerung an einem Quellrandknoten einen Migrationsschlüssel von einer Zielrandknoten-POD-Steuerung erhalten, wobei der Migrationsschlüssel zum Umhüllen der containerspezifischen Schlüssel verwendet wird. Wenn der Container/Pod zum Ziel-Edge-Knoten migriert wird, wird der Entpackungsschlüssel der Pod-Steuerung offenbart, die dann die verpackten Schlüssel entschlüsselt. Die Schlüssel können nun verwendet werden, um Operationen an containerspezifischen Daten durchzuführen. Die Migrationsfunktionen können durch korrekt attestierte Edge-Knoten und Pod-Manager (wie oben beschrieben) angesteuert werden.
In weiteren Beispielen wird ein Edge-Rechensystem erweitert, um Orchestrierung mehrerer Anwendungen durch die Verwendung von Containern (einer enthaltenen einsetzbaren Softwareeinheit, die Code und benötigte Abhängigkeiten bereitstellt) in einer Multi-Eigentümer-, Multi-Mandanten-Umgebung bereitzustellen. Ein Multi-Mandanten-Orchestrator kann verwendet werden, um Schlüsselverwaltung, Vertrauensanker-Verwaltung und andere Sicherheitsfunktionen in Bezug auf die Bereitstellung und den Lebenszyklus des vertrauenswürdigen „Slice“-Konzepts in 4 durchzuführen. Beispielsweise kann ein Edge-Computing-System ausgelegt sein, Anfragen und Antworten für verschiedene Client-Endpunkte von mehreren virtuellen Edge-Instanzen (und von einer Cloud oder einem entfernten Rechenzentrum) zu erfüllen. Die Verwendung dieser virtuellen Edge-Instanzen kann mehrere Mandanten und mehrere Anwendungen (z.B. erweiterte Realität (AR)/virtuelle Realität (VR), Unternehmens anwendungen, Inhaltsbereitstellung, Gaming, Auslagerung von Rechenoperationen) gleichzeitig unterstützen. Ferner kann es mehrere Arten von Anwendungen innerhalb der virtuellen Edge-Instanzen geben (z.B. normale Anwendungen; latenzsensitive Anwendungen; latenzkritische Anwendungen; Anwendungen auf Benutzerebene; Vernetzungsanwendungen usw.). Die virtuellen Edge-Instanzen können sich auch über Systeme mehrerer Eigentümer an unterschiedlichen geographischen Standorten (oder jeweilige Rechensysteme und Ressourcen, die von mehreren Eigentümern gemeinsam besessen oder verwaltet werden) spannen.
Beispielsweise kann jeder Edge-Knoten 422, 424 die Verwendung von Containern implementieren, wie etwa durch die Verwendung eines Container-„Pods“ 426, 428, der eine Gruppe von einem oder mehreren Containern bereitstellt. In einer Einstellung, die eine oder mehrere Container-Pods verwendet, ist eine Pod-Steuerung oder ein Orchestrator für die lokale Steuerung und Orchestrierung der Container im Pod verantwortlich. Verschiedene Edge-Knotenressourcen (z.B. Speicherung, Berechnung, Dienste, dargestellt mit Hexagonen), die für die jeweiligen Edge-Slices der virtuellen Edges 432, 434 bereitgestellt werden, werden gemäß den Bedürfnissen jedes Containers partitioniert.
Bei der Verwendung von Container-Pods beaufsichtigt eine Pod-Steuerung die Partitionierung und Zuordnung von Containern und Ressourcen. Die Pod-Steuerung empfängt Anweisungen von einem Orchestrator (der z.B. die Orchestrierungsfunktionen 460 durchführt), der die Steuerung anweist, wie physische Ressourcen am besten und für welche Dauer zu partitionieren sind, wie etwa durch Empfangen von Leistungskennzahl- (Key Performance Indicator, KPI) Zielen basierend auf SLA-Verträgen. Die Pod-Steuerung bestimmt, welcher Container welche Ressourcen und wie lange benötigt, um die Arbeitslast abzuschließen und die SLA zu erfüllen. Die Pod-Steuerung verwaltet auch Containerlebenszyklusoperationen, wie etwa: Erzeugen des Containers, Ausstatten desselben mit Ressourcen und Anwendungen, Koordinieren von Zwischenergebnissen zwischen mehreren Containern, die gemeinsam an einer verteilten Anwendung arbeiten, Abbauen von Containern, wenn die Arbeitslast abgeschlossen ist, und dergleichen. Zusätzlich dazu kann eine Pod-Steuerung eine Sicherheitsrolle bedienen, die die Zuordnung von Ressourcen verhindert, bis sich der richtige Mandant authentifiziert, oder eine Bereitstellung von Daten oder einer Arbeitslast an einen Container verhindert, bis ein Attestierungsergebnis erfüllt ist.
Auch bei der Verwendung von Container-Pods können dennoch Mandantengrenzen existieren, aber im Kontext jedes Pods von Containern. Falls jeder mandantenspezifische Pod eine mandantenspezifische Pod-Steuerung aufweist, gibt es eine gemeinsam genutzte Pod-Steuerung, die Ressourcenzuweisungsanforderungen konsolidiert, um typische Ressourcenmangelsituationen zu vermeiden. Weitere Steuerungen können bereitgestellt werden, um die Bestätigung und Vertrauenswürdigkeit des Pods und der Pod-Steuerung zu gewährleisten. Beispielsweise können die Orchestrierungsfunktionen 460 lokalen Pod-Steuerungen, die die Attestierungsverifikation durchführen, eine Attestierungsverifikationsleitlinie bereitstellen. Falls eine Attestierung eine Richtlinie für eine erste Mandanten-Pod-Steuerung, aber nicht für eine zweite Mandanten-Pod-Steuerung erfüllt, dann könnte der zweite Pod zu einem anderen Edge-Knoten migriert werden, der sie erfüllt. Alternativ kann die Ausführung des ersten Pods zugelassen werden, und eine andere gemeinsam genutzte Pod-Steuerung wird installiert und aufgerufen, bevor der zweite Pod ausgeführt wird.
5 veranschaulicht zusätzliche Rechenanordnungen, die Container in einem Edge-Rechensystem einsetzen. Als ein vereinfachtes Beispiel stellen die Systemanordnungen 510, 520 Szenarien dar, in denen eine Pod-Steuerung (z.B. die Containermanager 511, 521 und der Container-Orchestrator 531) dazu ausgelegt ist, containerisierte Pods, Funktionen und Functions-as-a-Service-Instanzen durch Ausführung über Rechenknoten (z.B. die Rechenknoten 515 in der Anordnung 510) auszuführen oder separat containerisierte virtualisierte Netzwerkfunktionen durch Ausführung über Rechenknoten (z.B. die Rechenknoten 523 in der Anordnung 520) auszuführen. Diese Anordnung ist zur Verwendung mehrerer Mandanten in der Systemanordnung 530 (unter Verwendung der Rechenknoten 537) angepasst, wobei containerisierte Pods (z.B. die Pods 512), Funktionen (z.B. die Funktionen 513, VNFs 522, 536) und Functions-as-a-Service-Instanzen (z.B. die FaaS-Instanz 514) innerhalb virtueller Maschinen (z.B. der VMs 534, 535 für die Mandanten 532, 533) gestartet werden, die spezifisch für jeweilige Mandanten sind (abgesehen von der Ausführung virtualisierter Netzwerkfunktionen). Diese Anordnung ist ferner zur Verwendung in der Systemanordnung 540 angepasst, die die Container 542, 543 oder die Ausführung der verschiedenen Funktionen, Anwendungen und Funktionen auf den Rechenknoten 544 bereitstellt, wie durch ein containerbasiertes Orchestrierungssystem 541 koordiniert.
Die in 5 dargestellten Systemanordnungen stellen eine Architektur bereit, die VMs, Container und Funktionen hinsichtlich der Anwendungszusammensetzung gleich behandelt (und resultierende Anwendungen sind Kombinationen dieser drei Bestandteile). Jeder Bestandteil kann die Verwendung einer oder mehrerer Beschleuniger- (FPGA, ASIC) Komponenten als ein lokales Backend einbeziehen. Auf diese Weise können Anwendungen über mehrere Edge-Eigentümer aufgeteilt werden, koordiniert durch einen Orchestrator.
Im Kontext von 5 können die Pod-Steuerung/der Containermanager, der Containerorchestrator und einzelne Knoten einen Sicherheitsdurchsetzungspunkt bereitstellen. Die Mandantentrennung kann jedoch orchestriert werden, wo sich die Ressourcen, die einem Mandanten zugewiesen sind, von Ressourcen unterscheiden, die einem zweiten Mandanten zugewiesen sind, aber Edge-Eigentümer kooperieren, um sicherzustellen, dass Ressourcenzuweisungen nicht über Mandantengrenzen hinweg gemeinsam genutzt werden. Oder Ressourcenzuteilungen könnten über Mandantengrenzen hinweg isoliert werden, da Mandanten eine „Verwendung“ auf Subskriptions- oder Transaktions-/Vertragsbasis ermöglichen könnten. In diesen Zusammenhängen können Virtualisierungs-, Containerisierungs-, Enklaven- und Hardwarepartitionierungsschemata von Edge-Eigentümern verwendet werden, um eine Mandantschaft durchzusetzen. Andere Trennungsumgebungen können Bare-Metal (dedizierte)-Geräte, virtuelle Maschinen, Container, virtuelle Maschinen auf Containern oder Kombinationen davon beinhalten.
In weiteren Beispielen können Aspekte von softwaredefinierter oder -gesteuerter Siliziumhardware und anderer konfigurierbarer Hardware in Anwendungen, Funktionen und Dienste eines Edge-Rechensystems integriert werden. Softwaredefiniertes Silizium kann verwendet werden, um sicherzustellen, dass gewisse Ressourcen- oder Hardwarebestandteile einen Vertrag oder eine Dienstgütevereinbarung erfüllen können, basierend auf der Fähigkeit des Bestandteils, einen Abschnitt von sich selbst oder der Arbeitslast zu korrigieren (z.B. durch ein Upgrade, eine Neukonfiguration oder eine Bereitstellung neuer Merkmale innerhalb der Hardwarekonfiguration selbst).
Es versteht sich, dass die hierin besprochenen Edge-Rechensysteme und -Anordnungen in verschiedenen Lösungen, Diensten und/oder Anwendungsfällen anwendbar sein können, die Mobilität einbeziehen. Als ein Beispiel zeigt 6 einen vereinfachten Fahrzeugberechnungs- und Kommunikationsanwendungsfall, der Mobilzugriff auf Anwendungen in einem Edge-Computing-System 600 einbezieht, das eine Edge-Cloud 110 implementiert. In diesem Anwendungsfall können jeweilige Client-Rechenknoten (oder -vorrichtungen) 610 als fahrzeuginterne Rechensysteme (z.B. fahrzeuginterne Navigations- und/oder Infotainmentsysteme) realisiert sein, die sich in entsprechenden Fahrzeugen befinden, die mit den Edge-Gateway-Knoten (oder -vorrichtungen) 620 während des Befahrens einer Straße kommunizieren. Beispielsweise können sich die Edge-Gateway-Knoten 620 in einem Schrank am Straßenrand oder einer anderen Einhausung befinden, die in eine Struktur mit einem anderen, separaten, mechanischen Versorger eingebaut ist, die entlang der Straße, an Kreuzungen der Straße oder anderen Standorten nahe der Straße platziert sein kann. Wenn jeweilige Fahrzeuge die Straße entlang fahren, kann sich die Verbindung zwischen ihrem Client-Rechenknoten 610 und einem spezifischen Edge-Gateway-Knoten 620 ausbreiten, um eine konsistente Verbindung und einen konsistenten Kontext für den Client-Rechenknoten 610 aufrechtzuerhalten. Gleichermaßen können MEC-Knoten an den Diensten mit hoher Priorität oder gemäß den Durchsatz- oder Latenzauflösungsanforderungen für den/die zugrundeliegenden Dienst(e) aggregieren (z.B. im Fall von Drohnen). Die jeweiligen Edge-Gateway-Knoten 620 beinhalten eine Reihe von Verarbeitungs- und Speicherungsfähigkeiten, und daher kann ein Teil der Verarbeitung und/oder der Speicherung von Daten für die Client-Rechenknoten 610 auf einem oder mehreren der Edge-Gateway-Knoten 620 ausgeführt werden.
Die Edge-Gateway-Knoten 620 können mit einem oder mehreren Edge-Ressourcenknoten 640 kommunizieren, die veranschaulichend als Rechenserver, Geräte oder Komponenten umgesetzt sind, die sich an oder in einer Kommunikationsbasisstation 642 (z.B. einer Basisstation eines Mobilfunknetzes) befinden. Wie oben besprochen, beinhalten die jeweiligen Edge-Ressourcenknoten 640 eine Reihe von Verarbeitungs- und Speicherungsfähigkeiten, und von daher kann ein Teil der Verarbeitung und/oder der Speicherung von Daten für die Client-Rechenknoten 610 an dem Edge-Ressourcenknoten 640 durchgeführt werden. Zum Beispiel kann die Verarbeitung von Daten, die weniger dringend oder wichtig sind, durch den Edge-Ressourcenknoten 640 durchgeführt werden, während die Verarbeitung von Daten, die eine höhere Dringlichkeit oder Wichtigkeit aufweisen, durch die Edge-Gateway-Knoten 620 durchgeführt werden kann (zum Beispiel in Abhängigkeit von den Fähigkeiten jeder Komponente oder den Informationen in der Anfrage, die Dringlichkeit oder Wichtigkeit angeben). Basierend auf Datenzugriff, Datenposition oder Latenz kann die Arbeit auf Edge-Ressourcenknoten fortgesetzt werden, wenn sich die Verarbeitungsprioritäten während der Verarbeitungsaktivität ändern. Gleichermaßen können konfigurierbare Systeme oder Hardwareressourcen selbst aktiviert werden (z.B. durch einen lokalen Orchestrator), um zusätzliche Ressourcen bereitzustellen, um den neuen Bedarf zu erfüllen (z.B. Anpassen der Rechenressourcen an die Arbeitslastdaten).
Der/die Edge-Ressourcenknoten 640 kommunizieren auch mit dem Kerndatenzentrum 650, das Rechenserver, Geräte und/oder andere Komponenten beinhalten kann, die sich an einem zentralen Ort befinden (z.B. einer Zentrale eines Mobilfunkkommunikationsnetzes). Das Kerndatenzentrum 650 kann ein Gateway zur globalen Netzwerk-Cloud 660 (z.B. dem Internet) für die Operationen der Edge-Cloud 110 bereitstellen, das durch den/die Edge-Ressourcenknoten 640 und die Edge-Gateway-Knoten 620 gebildet wird. Zusätzlich kann das Kerndatenzentrum 650 in einigen Beispielen eine Reihe von Verarbeitungs- und Speicherungsfähigkeiten beinhalten, und somit kann ein Teil der Verarbeitung und/oder der Speicherung von Daten für die Client-Rechenvorrichtungen auf dem Kerndatenzentrum 650 durchgeführt werden (z.B. Verarbeitung mit niedriger Dringlichkeit oder Wichtigkeit oder hoher Komplexität).
Die Edge-Gateway-Knoten 620 oder die Edge-Ressourcenknoten 640 können die Verwendung zustandsorientierter Anwendungen 632 und einer geografisch verteilten Datenbank 634 anbieten. Auch wenn die zustandsorientierten Anwendungen 632 und die Datenbank 634 als horizontal auf einer Schicht der Edge-Cloud 110 verteilt veranschaulicht sind, versteht es sich, dass Ressourcen, Dienste oder andere Komponenten der Anwendung vertikal in der gesamten Edge-Cloud verteilt sein können (was beinhaltet, dass ein Teil der Anwendung auf dem Client-Rechenknoten 610 ausgeführt wird, andere Teile auf den Edge-Gateway-Knoten 620 oder dem oder den Edge-Ressourcenknoten 640 usw.). Zusätzlich dazu kann es, wie zuvor angegeben, Peer-Beziehungen auf einer beliebigen Ebene geben, um Dienstziele und Verpflichtungen zu erfüllen. Ferner können sich die Daten für einen spezifischen Client oder eine spezifische Anwendung basierend auf sich ändernden Bedingungen (z.B. basierend auf Beschleunigungsressourcenverfügbarkeit, der Autobewegung folgend usw.) von Edge zu Edge bewegen. Beispielsweise kann basierend auf der „Abklingrate“ des Zugangs eine Vorhersage getroffen werden, um den nächsten Eigentümer zum Fortsetzen zu identifizieren oder um zu identifizieren, wann die Daten oder der Rechenzugang nicht mehr brauchbar sein werden. Diese und andere Dienste können genutzt werden, um die Arbeit abzuschließen, die notwendig ist, um die Transaktion konform und verlustfrei zu halten.
In weiteren Szenarien kann ein Container 636 (oder ein Pod von Containern) flexibel von einem Edge-Gateway-Knoten 620 zu anderen Edge-Knoten (z. B. 620, 640 usw.) migriert werden, so dass der Container mit einer Anwendung und Arbeitslast nicht neu gebildet, kompiliert, interpretiert werden muss, damit er migriert werden kann. In derartigen Szenarien können jedoch einige abhelfende oder „Swizzling“-Übersetzungsoperationen angewendet werden. Zum Beispiel kann sich die physische Hardware am Knoten 640 vom Edge-Gateway-Knoten 620 unterscheiden, und daher wird die Hardware-Abstraktionsschicht (HAL), die die untere Edge des Containers bildet, erneut auf die physische Schicht des Ziel-Edge-Knotens abgebildet. Dies kann irgendeine Form einer Spätbindungstechnik einbeziehen, wie etwa binäre Übersetzung der HAL aus dem containernativen Format in das physische Hardwareformat, oder es kann das Mapping von Schnittstellen und Operationen einbeziehen. Eine Pod-Steuerung kann verwendet werden, um das Schnittstellen-Mapping als Teil des Containerlebenszyklus anzusteuern, was Migration zu/von unterschiedlichen Hardwareumgebungen beinhaltet.
Die Szenarien, die 6 umfasst, können verschiedene Arten von MEC-Knoten, wie etwa einen Edge-Knoten, der in einem Fahrzeug (Auto/Lastkraftwagen/Straßenbahn/Eisenbahn) gehostet ist, oder andere mobile Einheiten nutzen, da sich der Edge-Knoten zu anderen geografischen Standorten entlang der Plattform, die ihn hostet, bewegen wird. Bei Fahrzeug-zu-Fahrzeug-Kommunikationen können einzelne Fahrzeuge sogar als Netzwerk-Edge-Knoten für andere Autos fungieren (um z. B. Caching, Berichterstellung, Datenaggregation usw. durchzuführen). Somit versteht es sich, dass die Anwendungskomponenten, die in verschiedenen Edge-Knoten bereitgestellt sind, in statischen oder mobilen Szenarien verteilt sein können, einschließlich Koordination zwischen einigen Funktionen oder Operationen an einzelnen Endpunktvorrichtungen oder den Edge-Gateway-Knoten 620, einigen anderen an dem Edge-Ressourcenknoten 640 und anderen in dem Kerndatenzentrum 650 oder der globalen Netzwerk-Cloud 660.
In einer beispielhaften Ausführungsform nutzt die Edge-Cloud 110 in 6 VIS-Funktionen 111 in Verbindung mit offenbarten Techniken. Die VIS-Funktionen 111 können durch einen Kommunikationsknoten durchgeführt werden, der als eine Orchestrierungsverwaltungsentität oder ein MEC-Host innerhalb eines MEC-Netzwerks konfiguriert ist, oder (2) durch eine Platinenverwaltungssteuerung (BMC) eines Rechenknotens durchgeführt werden. Beispielhafte VIS-Funktionen werden in Verbindung mit 9A - 14 ausführlicher erläutert.
In weiteren Konfigurationen kann das Edge-Rechensystem FaaS-Rechenfähigkeiten durch die Verwendung jeweiliger ausführbarer Anwendungen und Funktionen implementieren. Bei einem Beispiel schreibt ein Entwickler Funktionscode (hierin z. B. „Computercode“), der eine oder mehrere Computerfunktionen repräsentiert, und der Funktionscode wird auf eine FaaS-Plattform hochgeladen, die zum Beispiel durch einen Edge-Knoten oder ein Rechenzentrum bereitgestellt wird. Ein Auslöser, wie beispielsweise ein Dienstanwendungsfall oder ein Edge-Verarbeitungsereignis, initiiert die Ausführung des Funktionscodes mit der FaaS-Plattform.
In einem Beispiel für FaaS wird ein Container verwendet, um eine Umgebung bereitzustellen, in der Funktionscode (z. B. eine Anwendung, die durch einen Dritten bereitgestellt werden kann) ausgeführt wird. Der Container kann eine beliebige Entität mit isolierter Ausführung sein, wie etwa ein Prozess, ein Docker- oder Kubernetes-Container, eine virtuelle Maschine usw. Innerhalb des Edge-Computing-Systems werden verschiedene Datenzentrums-, Edge- und Endpunkt (einschließlich mobiler)-Vorrichtungen verwendet, um Funktionen „hochzufahren“ (z.B. Funktionsaktionen zu aktivieren und/oder zuzuweisen), die bei Bedarf skaliert werden. Der Funktionscode wird auf der physischen Infrastruktur- (z.B. Edge-Rechenknoten-) Vorrichtung und darunterliegenden virtualisierten Containern ausgeführt. Schließlich wird der Container in Reaktion darauf, dass die Ausführung abgeschlossen ist, auf der Infrastruktur „heruntergefahren“ (z.B. deaktiviert und/oder freigegeben).
Weitere Aspekte von FaaS können eine Bereitstellung von Edge-Funktionen als Dienst ermöglichen, einschließlich Unterstützung jeweiliger Funktionen, die Edge-Computing als Dienst unterstützen (Edge-as-a-Service oder „EaaS“). Zusätzliche Merkmale von FaaS können beinhalten: eine granuläre Abrechnungskomponente, die Kunden (z.B. Computercodeentwicklern) ermöglicht, nur zu bezahlen, wenn ihr Code ausgeführt wird; gemeinsame Datenspeicherung zum Speichern von Daten zur Wiederverwendung durch eine oder mehrere Funktionen; Orchestrierung und Verwaltung zwischen einzelnen Funktionen; Funktionsausführungsverwaltung, Parallelität und Konsolidierung; Verwaltung von Container- und Funktionsspeicherplätzen; Koordination von Beschleunigungsressourcen, die für Funktionen verfügbar sind; und Verteilung von Funktionen zwischen Containern (einschließlich „warmer“ Container, die bereits eingesetzt oder betrieben werden, versus „kalter“ Container, die eine Initialisierung, Bereitstellung oder Konfiguration erfordern).
Das Edge-Rechensystem 600 kann einen Edge-Bereitstellungsknoten 644 beinhalten oder mit diesem in Kommunikation stehen. Der Edge-Bereitstellungsknoten 644 kann Software, wie etwa die beispielhaften computerlesbaren (auch als maschinenlesbar bezeichneten) Anweisungen 882 von 8B, an verschiedene Empfangsteilnehmer zum Implementieren eines beliebigen der vorliegend beschriebenen Verfahren verteilen. Der beispielhafte Edge-Bereitstellungsknoten 644 kann durch einen beliebigen Computerserver, einen beliebigen Heimserver, ein beliebiges Inhaltslieferungsnetzwerk, einen beliebigen virtuellen Server, ein beliebiges Softwareverteilungssystem, eine beliebige zentrale Einrichtung, eine beliebige Speicherungsvorrichtung, eine beliebige Speicherungsplatte, einen beliebigen Speicherungsknoten, eine beliebige Dateneinrichtung, einen beliebigen Cloud-Dienst usw. implementiert werden, der bzw. das bzw. die in der Lage ist, Softwareanweisungen (z.B. Code, Skripte, ausführbare Binärdateien, Container, Pakete, komprimierte Dateien und/oder Ableitungen davon) zu speichern und/oder an andere Rechenvorrichtungen zu übertragen. Eine oder mehrere Komponenten des beispielhaften Edge-Bereitstellungsknotens 644 können sich in einer Cloud, in einem lokalen Netzwerk, in einem Edge-Netzwerk, in einem Weitverkehrsnetzwerk, im Internet und/oder an einem beliebigen anderen Standort befinden, der kommunikativ mit der einen oder den mehreren Empfangsparteien gekoppelt ist. Die Empfangsteilnehmer können Konsumenten, Kunden, Kollegen, Benutzer usw. der Entität sein, die den Edge-Bereitstellungsknoten 644 besitzt und/oder betreibt. Zum Beispiel kann die Entität, die den Edge-Bereitstellungsknoten 644 besitzt und/oder betreibt, ein Entwickler, ein Verkäufer und/oder ein Lizenzgeber (oder ein Kunde und/oder Verbraucher davon) von Softwareanweisungen sein, wie etwa der beispielhaften computerlesbaren Anweisungen 882 von 8B (auch als maschinenlesbare Anweisungen 882 bezeichnet). Die Empfangsteilnehmer können Verbraucher, Dienstanbieter, Benutzer, Einzelhändler, OEMs usw. sein, die die Softwareanweisungen zur Verwendung und/oder zum Weiterverkauf und/oder zum Sublizenzieren erwerben und/oder lizenzieren.
In einem Beispiel beinhaltet der Edge-Bereitstellungsknoten 644 einen oder mehrere Server und eine oder mehrere Speichervorrichtungen/-platten. Die Speichervorrichtungen und/oder Speicherplatten hosten computerlesbare Anweisungen, wie etwa die beispielhaften computerlesbaren Anweisungen 882 von 8B, wie nachstehend beschrieben. Ähnlich den vorstehend beschriebenen Edge-Gateway-Knoten 620 stehen der eine oder die mehreren Server des Edge-Bereitstellungsknotens 644 in Kommunikation mit einer Basisstation 642 oder einer anderen Netzwerkkommunikationsentität. In einigen Beispielen reagieren der eine oder die mehreren Server auf Anfragen, die Softwareanweisungen als Teil einer kommerziellen Transaktion an einen anfragenden Teilnehmer zu übertragen. Die Zahlung für die Lieferung, den Verkauf und/oder die Lizenz der Softwareanweisungen kann durch den einen oder die mehreren Server der Softwareverteilungsplattform und/oder über eine Drittanbieter-Zahlungsentität gehandhabt werden. Die Server ermöglichen Käufern und/oder Lizenzgebern, die computerlesbaren Anweisungen 882 von dem Edge-Bereitstellungsknoten 644 herunterzuladen. Zum Beispiel können die Softwareanweisungen, die den beispielhaften computerlesbaren Anweisungen 882 von 8B entsprechen können, auf die beispielhafte(n) Prozessorplattform(en) heruntergeladen werden, die die computerlesbaren Anweisungen 882 ausführen sollen, um die hier beschriebenen Verfahren zu implementieren.
In einigen Beispielen können sich die Prozessorplattform(en), die die computerlesbaren Anweisungen 882 ausführen, physisch an verschiedenen geografischen Standorten, Gerichtsbarkeiten usw. befinden. In einigen Beispielen bieten ein oder mehrere Server des Edge-Bereitstellungsknotens 644 periodisch Aktualisierungen an den Softwareanweisungen (z.B. den beispielhaften computerlesbaren Anweisungen 882 von 8B) an, übertragen und/oder erzwingen diese, um sicherzustellen, dass Verbesserungen, Patches, Aktualisierungen usw. verteilt und auf die an den Endbenutzervorrichtungen implementierten Softwareanweisungen angewendet werden. In einigen Beispielen können unterschiedliche Komponenten der computerlesbaren Anweisungen 882 aus unterschiedlichen Quellen und/oder an unterschiedliche Prozessorplattformen verteilt werden; zum Beispiel können unterschiedliche Bibliotheken, Plug-ins, Komponenten und andere Typen von Rechenmodulen, ob kompiliert oder interpretiert, aus unterschiedlichen Quellen und/oder an unterschiedliche Prozessorplattformen verteilt werden. Zum Beispiel kann ein Teil der Softwareanweisungen (z.B. ein Skript, das für sich nicht ausführbar ist) aus einer ersten Quelle verteilt werden, während ein Interpreter (der in der Lage ist, das Skript auszuführen) aus einer zweiten Quelle verteilt werden kann.
7 veranschaulicht eine MEC-Dienstarchitektur 700 gemäß einigen Ausführungsformen. Die MEC-Dienstarchitektur 700 beinhaltet den MEC-Dienst 705, die Mehrfachzugriffs-Edge (ME)-Plattform 710 (die z.B. der MEC-Plattform 932 in 9A entspricht) und die Anwendungen (Apps) 1 bis N (wobei N eine Zahl ist). Als ein Beispiel kann die App 1 eine Inhaltslieferungsnetzwerk- (Content Delivery Network, CDN) App/Dienst sein, die 1, ..., n Sitzungen hostet (wobei n eine Zahl ist, die gleich oder anders als N ist), App 2 kann eine Gaming-App/Dienst sein, die als zwei Sitzungen hostend gezeigt ist, und App N kann irgendeine andere App/Dienst sein, die als eine einzelne Instanz gezeigt ist (z.B. keine Sitzungen hostend). Jede App kann eine verteilte Anwendung sein, die Aufgaben und/oder Arbeitslasten zwischen Ressourcenanbietern (z.B. Servern, wie etwa der MEC-Plattform 710) und Verbrauchern (z.B. UEs, Benutzerapps, die von einzelnen UEs instanziiert werden, anderen Servern/Diensten, Netzwerkfunktionen, Anwendungsfunktionen usw.) partitioniert. Jede Sitzung repräsentiert einen interaktiven Informationsaustausch zwischen zwei oder mehr Elementen, wie etwa einer clientseitigen App und ihrer entsprechenden serverseitigen App, einer Benutzerapp, die durch ein UE instanziiert wird, und einer MEC-App, die durch die MEC-Plattform 710 instanziiert wird, und/oder dergleichen. Eine Sitzung kann beginnen, wenn die App-Ausführung gestartet oder initiiert wird, und endet, wenn die App die Ausführung verlässt oder beendet. Zusätzlich oder alternativ kann eine Sitzung beginnen, wenn eine Verbindung aufgebaut ist, und enden, wenn die Verbindung beendet wird. Jede App-Sitzung kann einer aktuell laufenden App-Instanz entsprechen. Zusätzlich oder alternativ kann jede Sitzung einer Protokolldateneinheiten- (PDU-) Sitzung oder einer Mehrfachzugriff- (MA-) PDU-Sitzung entsprechen. Eine PDU-Sitzung ist eine Assoziierung zwischen einem UE und einem Datennetzwerk, das einen PDU-Konnektivitätsdienst bereitstellt, der ein Dienst ist, der den Austausch von PDUs zwischen einem UE und einem Datennetzwerk bereitstellt. Eine MA-PDU-Sitzung ist eine PDU-Sitzung, die einen PDU-Konnektivitätsdienst bereitstellt, der jeweils ein Zugangsnetzwerk zur Zeit oder ein 3GPP-Zugangsnetzwerk und ein Nicht-3GPP-Zugangsnetzwerk gleichzeitig verwenden kann. Ferner kann jede Sitzung mit einer Sitzungskennung (ID) assoziiert sein, was Daten sind, die eine Sitzung eindeutig identifizieren, und jede App (oder App-Instanz) kann mit einer App-ID (oder APP-Instanz-ID) assoziiert sein, was Daten sind, die eine App (oder App-Instanz) eindeutig identifizieren.
Der MEC-Dienst 705 stellt MEC-Dienstverbrauchern (z.B. den Apps 1 bis N) einen oder mehrere MEC-Dienste 936 (z.B. die MEC-Dienste in 9A) bereit. Der MEC-Dienst 705 kann optional als Teil der Plattform (z.B. der MEC-Plattform 710) oder als eine Anwendung (z. B. ME-App) laufen. Unterschiedliche Apps 1 bis N, unabhängig davon, ob sie eine einzelne Instanz oder mehrere Sitzungen (z.B. ein CDN) verwalten, können spezifische Dienstinfo gemäß ihren Anforderungen für die gesamte Anwendungsinstanz oder unterschiedliche Anforderungen pro Sitzung anfordern. Der MEC-Dienst 705 kann alle Anfragen aggregieren und auf eine Weise agieren, die helfen wird, die BW-Nutzung zu optimieren und Erlebnisqualität (Quality of Experience, QoE) für Anwendungen zu verbessern.
Der MEC-Dienst 705 stellt eine MEC-Dienst-API bereit, die sowohl Anfragen als auch Subskriptionen (z.B. Pub/Sub-Mechanismus) unterstützt, die über eine Representational-State-Transfer- („REST“ oder „RESTful“) API oder über alternative Transporte, wie etwa einen Nachrichtenbus, verwendet werden. Für den RESTful-Architekturstil enthalten die MEC-APIs die HTTP-Protokollbindungen für Verkehrsverwaltungsfunktionalität.
Jede Hypertext-Transfer-Protocol- (HTTP-) Nachricht ist entweder eine Anfrage oder eine Antwort. Ein Server hört eine Verbindung auf eine Anfrage hin ab, parst jede empfangene Nachricht, interpretiert die Nachrichtensemantik bezüglich des identifizierten Anfrageziels und antwortet auf diese Anfrage mit einer oder mehreren Antwortnachrichten. Ein Client konstruiert Anfragenachrichten, um spezifische Absichten zu kommunizieren, untersucht empfangene Antworten, um zu sehen, ob die Absichten ausgeführt wurden, und bestimmt, wie die Ergebnisse zu interpretieren sind. Das Ziel einer HTTP-Anfrage wird als „Ressource“ bezeichnet. Zusätzlich oder alternativ ist eine „Ressource“ ein Objekt mit einem Typ, assoziierten Daten, einem Satz von Verfahren, die darauf arbeiten, und Beziehungen zu anderen Ressourcen, falls anwendbar. Jede Ressource wird von mindestens einem Uniform Ressource Identifier (URI) identifiziert, und ein Ressourcen-URI identifiziert maximal eine Ressource. Ressourcen werden von der RESTful-API mit HTTP-Verfahren (zum Beispiel POST, GET, PUT, DELETE usw.) bearbeitet. Bei jedem HTTP-Verfahren wird ein Ressourcen-URI in der Anfrage zur Adressierung einer bestimmten Ressource übermittelt. Operationen an Ressourcen beeinflussen den Zustand der entsprechenden verwalteten Entitäten.
In Anbetracht der Tatsache, dass eine Ressource alles Mögliche sein kann und dass die von HTTP bereitgestellte einheitliche Schnittstelle einem Fenster ähnelt, durch das man eine solche Sache nur durch die Übermittlung von Nachrichten an einen unabhängigen Akteur auf der anderen Seite beobachten und auf sie einwirken kann, ist eine Abstraktion erforderlich, um den aktuellen oder gewünschten Zustand dieser Sache in der Kommunikation darzustellen („an dessen Stelle zu treten“). Diese Abstraktion wird als Repräsentation bezeichnet. Für HTTP handelt es sich bei einer „Repräsentation“ um Informationen, die einen vergangenen, aktuellen oder gewünschten Zustand einer gegebenen Ressource in einem Format widerspiegeln sollen, das leicht über das Protokoll kommuniziert werden kann. Eine Repräsentation umfasst einen Satz von Repräsentationsmetadaten und einen potentiell unbegrenzten Strom von Repräsentationsdaten. Zusätzlich oder alternativ ist eine Ressourcenrepräsentation eine Serialisierung eines Ressourcenzustands in einem bestimmten Inhaltsformat.
Einem Ursprungsserver könnten mehrere Repräsentationen bereitgestellt werden oder er könnte in der Lage sein, mehrere Repräsentationen zu erzeugen, die jeweils den aktuellen Zustand einer Zielressource widerspiegeln sollen. In solchen Fällen wird irgendein Algorithmus vom Ursprungsserver verwendet, um eine dieser Repräsentationen als für eine gegebene Anfrage am besten anwendbar auszuwählen, üblicherweise basierend auf Inhaltsverhandlung. Diese „ausgewählte Repräsentation“ wird verwendet, um die Daten und Metadaten zum Bewerten bedingter Anfragen bereitzustellen, die Nutzlast für Antwortnachrichten konstruieren (zum Beispiel 200 OK, 304 Nicht Modifizierte Antworten auf GET, und dergleichen). Eine Ressourcenrepräsentation ist im Nutzdatenrumpf einer HTTP-Anfrage- oder Antwortnachricht enthalten. Ob eine Repräsentation in einer Anfrage erforderlich ist oder nicht erlaubt ist, hängt vom verwendeten HTTP-Verfahren ab (siehe z.B. Fielding et al., „Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content“, IETF RFC 7231 (Juni 2014)).
Die Universal Resource Indicators (URIs) für MEC-API-Ressourcen sind in verschiedenen ETSI-MEC-Standards erörtert, wie etwa den hierin erwähnten. Die MTS-API unterstützt zusätzliche anwendungsbezogene Fehlerinformationen, die in der HTTP-Antwort bereitgestellt werden sollen, wenn ein Fehler auftritt (siehe z.B. Klausel 6.15 von ETSI GS MEC 009 V2.1.1 (2019-01) („[MEC009]“)). Die Syntax jeder Ressourcen-URI folgt [MEC009] sowie Berners-Lee et al., „Uniform Resource Identifier (URI): Generic Syntax“, IETF Network Working Group, RFC 3986 (Januar 2005), und/oder Nottingham, „URI Design and Ownership“, IETF RFC 8820 (Juni 2020). In den RESTful-MEC-Dienst-APIs, einschließlich der VIS-API, weist die Ressourcen-URI-Struktur für jede API die folgende Struktur auf:
{apiRoot}/{apiName}/{apiVersion}/{apiSpecificSuffixes}
Hier beinhaltet „apiRoot“ das Schema („https“), den Host und den optionalen Port sowie eine optionale Präfixzeichenfolge. Der „apiName“ definiert den Namen der API (zum Beispiel MTS-API, RNI-API usw.). „apiVersion“ stellt die Version der API dar, und die „apiSpecificSuffixes“ definieren den Baum von Ressourcen-URIs in einer bestimmten API. Die Kombination von „apiRoot“, „apiName“ und „apiVersion“ wird als Stamm-URI bezeichnet. „apiRoot“ steht unter der Kontrolle des Einsatzes, während die übrigen Teile des URI unter der Kontrolle der API-Spezifikation stehen. In der oben genannten Root werden „apiRoot“ und „apiName“ unter Verwendung der Dienstregistrierungsdatenbank (siehe z.B. Dienstregistrierungsdatenbank 738 in 9A) entdeckt. Es umfasst das Schema („http“ oder „https“), den Host und den optionalen Port und eine optionale Präfixzeichenfolge. Für eine gegebene MEC-API kann der „apiName“ auf „mec“ gesetzt werden, und „apiVersion“ kann auf eine geeignete Versionsnummer gesetzt werden (z.B. „v1“ für Version 1). Die MEC-APIs unterstützen HTTP über TLS (auch als HTTPS bekannt). Alle Ressourcen-URIs in den MEC-API-Prozeduren werden relativ zum oben genannten Root-URI definiert.
Das JSON-Inhaltsformat kann auch unterstützt werden. Das JSON-Format wird durch den Inhaltstyp „application/json“ signalisiert. Die MTS-API kann den OAuth-2.0-Client-Berechtigungsnachweiserteilungstyp mit Träger-Tokens verwenden (siehe z. B. [MEC009]). Der Token-Endpunkt kann als Teil der in [MEC009] definierten Dienstverfügbarkeitsabfrageprozedur entdeckt werden. Die Client-Berechtigungsnachweise können unter Verwendung bekannter Bereitstellungsmechanismen in der MEC-App bereitgestellt werden.
In weiteren Beispielen können beliebige der Rechenknoten oder Vorrichtungen, die unter Bezugnahme auf die vorliegenden Edge-Computing-Systeme und -umgebung erörtert wurden, basierend auf den Komponenten, die in 8A und 8B gezeigt sind, erfüllt werden. Jeweilige Edge-Rechenknoten können als ein Typ von Vorrichtung, Appliance, Computer oder anderem „Ding“ realisiert sein, das in der Lage ist, mit anderen Edge-, Netzwerk- oder Endpunktkomponenten zu kommunizieren. Zum Beispiel kann eine Edge-Rechenvorrichtung als ein Personalcomputer, ein Server, ein Smartphone, eine mobile Rechenvorrichtung, ein Smartgerät, ein fahrzeuginternes Rechensystem (z.B. ein Navigationssystem), eine eigenständige Vorrichtung mit einem Außengehäuse, einer Hülle usw. oder eine andere Vorrichtung oder ein anderes System, die/das in der Lage ist, die beschriebenen Funktionen durchzuführen, realisiert sein.
Im in 8A gezeigten vereinfachten Beispiel beinhaltet ein Edge-Rechenknoten 800 eine Rechen-Engine (vorliegend auch als „Rechenschaltungsanordnung“ bezeichnet) 802, ein Eingabe/Ausgabe (E/A)-Subsystem 808, eine oder mehrere Datenspeichervorrichtungen 810, ein Kommunikationsschaltungsanordnungssubsystem 812 und optional eine oder mehrere Peripherievorrichtungen 814. In anderen Beispielen können jeweilige Recheneinrichtungen andere oder zusätzliche Komponenten umfassen, wie diejenigen, die üblicherweise in einem Computer zu finden sind (z.B. eine Anzeige, periphere Einrichtungen usw.). Zusätzlich können bei einigen Beispielen eine oder mehrere der veranschaulichenden Komponenten in eine andere Komponente integriert sein oder anderswie einen Teil davon bilden.
Der Rechenknoten 800 kann als eine beliebige Art von Engine, Vorrichtung oder Sammlung von Vorrichtungen ausgebildet sein, die in der Lage sind, verschiedene Rechenfunktionen durchzuführen. In einigen Beispielen kann der Rechenknoten 800 als eine einzelne Vorrichtung, wie etwa eine integrierte Schaltung, ein eingebettetes System, ein Field Programmable Gate Array (FPGA), ein System-on-a-Chip (SOC) oder ein anderes integriertes System oder eine andere integrierte Vorrichtung ausgebildet sein. In dem veranschaulichten Beispiel beinhaltet der Rechenknoten 800 einen Prozessor 804 und einen Speicher 806 oder ist als diese realisiert. Der Prozessor 804 kann als eine beliebige Art eines Prozessors realisiert sein, der in der Lage ist, die hierin beschriebenen Funktionen (z.B. ein Ausführen einer Anwendung) durchzuführen. Der Prozessor 804 kann zum Beispiel als ein oder mehrere Mehrkernprozessor(en), ein Microcontroller, eine Verarbeitungseinheit, eine spezialisierte oder spezielle Verarbeitungseinheit oder ein anderer Prozessor oder eine andere Verarbeitungs-/Steuerschaltung ausgebildet sein.
In manchen Beispielen kann der Prozessor 804 als ein FPGA, eine anwendungsspezifische integrierte Schaltung (ASIC), eine rekonfigurierbare Hardware oder Hardwareschaltungsanordnung oder andere spezialisierte Hardware realisiert sein, diese umfassen oder mit diesen gekoppelt sein, um die Durchführung der hier beschriebenen Funktionen zu ermöglichen. In manchen Beispielen kann der Prozessor 804 auch als eine spezialisierte x-Verarbeitungseinheit (xPU) ausgebildet sein, die auch als eine Datenverarbeitungseinheit (DPU), eine Infrastrukturverarbeitungseinheit (IPU) oder eine Netzwerkverarbeitungseinheit (NPU) bekannt ist. Solch eine xPU kann als eine eigenständige Schaltung oder ein eigenständiges Schaltungspaket ausgebildet, in einen SoC integriert oder mit einer Vernetzungsschaltungsanordnung (z. B. in einer SmartNIC oder einer erweiterten SmartNIC), einer Beschleunigungsschaltungsanordnung, Speichervorrichtungen oder einer KI-Hardware (z. B. GPUs, programmierten FPGAs, Netzwerkverarbeitungseinheiten (NPUs), Infrastrukturverarbeitungseinheiten (IPUs), Speicherverarbeitungseinheiten (SPUs), KI-Prozessoren (APUs), einer Datenverarbeitungseinheit (DPUs) oder anderen spezialisierten Beschleunigern, wie etwa einer kryptographischen Verarbeitungseinheit/einem kryptographischen Beschleuniger) integriert sein. Solch eine xPU kann dazu konzipiert sein, Programmierung zu empfangen, um außerhalb der CPU oder Universalverarbeitungshardware einen oder mehrere Datenströme zu verarbeiten und spezifische Aufgaben und Aktionen für die Datenströme durchzuführen (wie etwa Hosten von Mikrodiensten, Durchführen von Dienstverwaltung oder -orchestrierung, Organisieren oder Verwalten von Server- oder Datenzentrumshardware, Verwalten von Service-Meshes oder Sammeln und Verteilen von Telemetrie). Es versteht sich jedoch, dass eine xPU, ein SoC, eine CPU und andere Varianten des Prozessors 804 koordiniert miteinander arbeiten können, um viele Arten von Operationen und Anweisungen innerhalb des Rechenknotens 800 oder für diesen auszuführen.
Der Arbeitsspeicher 806 kann als ein beliebiger Typ von flüchtigem (z. B. dynamischem Direktzugriffsspeichers (DRAM) usw.) oder nichtflüchtigem Speicher oder Datenspeicher ausgebildet sein, der fähig ist, die hier beschriebenen Funktionen durchzuführen. Flüchtiger Speicher kann ein Speicherungsmedium sein, das Energie erfordert, um den Zustand von vom Medium gespeicherten Daten zu bewahren. Nicht einschränkende Beispiele von flüchtigem Speicher können verschiedene Arten von Direktzugriffsspeicher (RAM) wie DRAM oder statischen Direktzugriffsspeicher (SRAM) umfassen. Eine bestimmte Art von DRAM, die in einem Speichermodul verwendet werden kann, ist synchroner dynamischer Direktzugriffsspeicher (SDRAM).
In einem Beispiel ist die Speichervorrichtung eine blockadressierbare Speichervorrichtung, wie etwa jene, die auf NAND- oder NOR-Technologien basieren. Eine Speichervorrichtung kann auch eine 3D-Koppelpunkt-Speichervorrichtung (z.B. Intel® 3D XPoint™-Speicher) oder andere byteadressierbare nichtflüchtige Write-in-Place-Speichervorrichtungen beinhalten. Die Speichervorrichtung kann den Die selbst und/oder ein gehäustes Speicherprodukt bezeichnen. In einigen Beispielen kann der 3D-Koppelpunkt-Speicher (z.B. Intel® 3D XPoint™-Speicher) eine transistorlose stapelbare Koppelpunkt-Architektur umfassen, bei der Speicherzellen am Schnittpunkt von Wortleitungen und Bitleitungen sitzen und individuell adressierbar sind, und bei der eine Bitspeicherung auf einer Änderung des Bulkwiderstands basiert. In einigen Beispielen kann der gesamte oder ein Teil des Speichers 806 in den Prozessor 804 integriert sein. Der Speicher 806 kann verschiedene Software und Daten speichern, die während des Betriebs verwendet werden, wie etwa eine oder mehrere Anwendungen, Daten, die durch die Anwendung(en) bearbeitet werden, Bibliotheken und Treiber.
In einem Beispiel ist die Speichervorrichtung (z.B. die Speicherschaltungsanordnung) eine beliebige Anzahl von blockadressierbaren Speichervorrichtungen, wie etwa jene, die auf NAND- oder NOR-Technologien basieren (zum Beispiel XXX-Pegel-Zellen, wie etwa Single-Level-Cell („SLC“), Multi-Level-Cell („MLC“), Quad-Level-Cell („QLC““), Tri-Level-Cell („TLC“) oder irgendein anderes NAND). In einigen Beispielen beinhaltet/beinhalten die Speichervorrichtung(en) eine byteadressierbare dreidimensionale Write-in-Place-Crosspoint-Speichervorrichtung oder andere byteadressierbare nichtflüchtige Write-in-Place-Speichervorrichtungen (NVM), wie etwa Ein- oder Mehrpegelphasenwechselspeicher (PCM) oder Phasenwechselspeicher mit einem Switch (PCMS), NVM-Vorrichtungen, die Chalkogenid-Phasenwechselmaterial (zum Beispiel Chalkogenidglas) verwenden, resistiven Speicher einschließlich Metalloxidbasis-, Sauerstoffleerstellenbasis- und Conductive Bridge-Direktzugriffsspeicher (CB-RAM), Nanodrahtspeicher, ferroelektrischen Transistor-Direktzugriffsspeicher (FeTRAM), magnetoresistiven Direktzugriffsspeicher (MRAM) mit Memristortechnologie, Spin Transfer Torque (STT)-MRAM, eine auf spintronischem Magnetübergangsspeicher basierende Vorrichtung, eine auf Magnettunnelkontakt (MTJ) basierende Vorrichtung, eine auf Domänenwand (DW) und SOT (Spin-Orbit-Übertragung) basierende Vorrichtung, eine auf Thyristoren basierende Speichervorrichtung, eine Kombination aus beliebigen der vorstehenden oder einen anderen geeigneten Speicher. Eine Speichervorrichtung kann auch eine 3D-Koppelpunkt-Speichervorrichtung (z.B. Intel® 3D XPoint™-Speicher) oder andere byteadressierbare nichtflüchtige Write-in-Place-Speichervorrichtungen beinhalten. Die Speichervorrichtung kann den Die selbst und/oder ein gehäustes Speicherprodukt bezeichnen. In einigen Beispielen kann der 3D-Koppelpunkt-Speicher (z.B. Intel® 3D XPoint™-Speicher) eine transistorlose stapelbare Crosspoint-Architektur beinhalten, bei der Speicherzellen am Schnittpunkt von Wortleitungen und Bitleitungen sitzen und einzeln adressierbar sind und bei der die Bitspeicherung auf einer Änderung des Bahnwiderstands basiert. In einigen Beispielen kann der gesamte oder ein Teil des Speichers 806 in den Prozessor 804 integriert sein. Der Speicher 806 kann verschiedene Software und Daten speichern, die während des Betriebs verwendet werden, wie etwa eine oder mehrere Anwendungen, Daten, die durch die Anwendung(en) bearbeitet werden, Bibliotheken und Treiber.
In manchen Beispielen beinhalten widerstandsbasierte und/oder transistorlose Speicherarchitekturen Phasenwechselspeicher- (PCM)-Vorrichtungen im Nanometermaßstab, in denen sich ein Volumen an Phasenwechselmaterial zwischen mindestens zwei Elektroden befindet. Teile des beispielhaften Phasenwechselmaterials zeigen variierende Grade von kristallinen Phasen und amorphen Phasen, wobei variierende Widerstandsgrade zwischen wenigstens zwei Elektroden gemessen werden können. In einigen Beispielen ist das Phasenwechselmaterial ein Chalkogenid-basiertes Glasmaterial. Solche resistiven Speichervorrichtungen werden manchmal als memristive Vorrichtungen bezeichnet, die sich an die Vorgeschichte des Stroms erinnern, der zuvor durch sie geflossen ist. Gespeicherte Daten werden von beispielhaften PCM-Vorrichtungen abgerufen, indem der elektrische Widerstand gemessen wird, wobei die kristallinen Phasen einen oder mehrere relativ niedrigere Widerstandswerte (z.B. logisch „0“) im Vergleich zu den amorphen Phasen mit einem oder mehreren relativ höheren Widerstandswerten (z.B. logisch „1“) aufweisen.
Beispielhafte PCM-Vorrichtungen speichern Daten für lange Zeiträume (z.B. etwa 10 Jahre bei Raumtemperatur). Schreiboperationen in beispielhafte PCM-Vorrichtungen (z.B. Setzen auf logisch „0“, Setzen auf logisch „1“, Setzen auf einen Zwischenwiderstandswert) werden durch Anlegen eines oder mehrerer Strompulse an die mindestens zwei Elektroden erreicht, wobei die Impulse eine bestimmte Stromstärke und -dauer aufweisen. Beispielsweise bewirkt ein langer niedriger Stromimpuls (SET), der an die wenigstens zwei Elektroden angelegt wird, dass sich die beispielhafte PCM-Vorrichtung in einem kristallinen Zustand mit niedrigem Widerstand befindet, während ein vergleichsweise kurzer hoher Stromimpuls (RESET), der an die wenigstens zwei Elektroden angelegt wird, bewirkt, dass sich die beispielhafte PCM-Vorrichtung in einem amorphen Zustand mit hohem Widerstand befindet.
In manchen Beispielen ermöglicht die Implementierung von PCM-Vorrichtungen Nicht-von-Neumann-Computing-Architekturen, die In-Memory-Rechenfähigkeiten ermöglichen. Allgemein gesprochen beinhalten herkömmliche Rechenarchitekturen eine Zentralverarbeitungseinheit (CPU), die über einen Bus kommunikativ mit einer oder mehreren Speichervorrichtungen verbunden ist. Von daher wird eine endliche Energiemenge und Zeit verbraucht, um Daten zwischen der CPU und dem Speicher zu übertragen, was ein bekannter Engpass von von-Neumann-Rechenarchitekturen ist. PCM-Vorrichtungen minimieren und eliminieren jedoch in manchen Fällen Datentransfers zwischen der CPU und dem Speicher, indem manche Rechenoperationen speicherintern durchgeführt werden. Anders ausgedrückt speichern PCM-Vorrichtungen nicht nur Informationen, sondern führen auch Rechenaufgaben aus. Solche Nicht-von-Neumann-Rechenarchitekturen können Vektoren mit einer relativ hohen Dimensionalität implementieren, um hyperdimensionales Berechnen zu ermöglichen, wie etwa Vektoren mit 10000 Bits. Vektoren mit relativ großer Bitbreite ermöglichen Berechnungsparadigmen, die nach dem menschlichen Gehirn modelliert sind, das auch zu breiten Bitvektoren analoge Informationen verarbeitet.
Die Rechenschaltungsanordnung 802 ist über das E/A-Subsystem 808 kommunikativ an andere Komponenten des Rechenknotens 800 gekoppelt, das als Schaltungsanordnung und/oder Komponenten umgesetzt sein kann, um Eingabe/Ausgabe-Operationen mit der Rechenschaltungsanordnung 802 (z.B. mit dem Prozessor 804 und/oder dem Hauptspeicher 806) und anderen Komponenten der Rechenschaltungsanordnung 802 zu ermöglichen. Das E/A-Subsystem 808 kann zum Beispiel als Speichersteuerungs-Hubs, Eingabe/Ausgabe-Steuerungs-Hubs, integrierte Sensor-Hubs, Firmwarevorrichtungen, Kommunikationslinks (z.B. Punkt-zu-Punkt-Links, Bus-Links, Drähte, Kabel, Lichtleiter, Leiterbahnen usw.) und/oder andere Komponenten und Subsysteme umgesetzt sein oder diese anderweitig beinhalten, um die Eingabe/Ausgabe-Operationen zu ermöglichen. In einigen Beispielen kann das E/A-Subsystem 808 einen Teil eines System-on-a-Chip (SoC) bilden und zusammen mit dem Prozessor 804 und/oder dem Speicher 806 und/oder anderen Komponenten der Rechenschaltungsanordnung 802 in die Rechenschaltungsanordnung 802 integriert sein.
Eine oder mehrere veranschaulichenden Datenspeichervorrichtungen 810 können als eine beliebige Art von Vorrichtungen ausgebildet sein, die zur Kurzzeit- oder Langzeitspeicherung von Daten konfiguriert sind, wie etwa zum Beispiel Speichervorrichtungen und -schaltungen, Speicherkarten, Festplattenlaufwerke, Festkörperlaufwerke oder andere Datenspeichervorrichtungen. Einzelne Datenspeicherungsvorrichtungen können eine Systempartition beinhalten, die Daten und Firmwarecode für die eine oder die mehreren Datenspeichervorrichtungen 810 speichert. Einzelne Datenspeichervorrichtungen der einen oder der mehreren Datenspeichervorrichtungen 810 können auch eine oder mehrere Betriebssystempartitionen beinhalten, die Datendateien und ausführbare Dateien für Betriebssysteme zum Beispiel je nach dem Typ des Rechenknotens 800 speichern.
Das Kommunikationsschaltungsanordnungs-Subsystem 812 kann als eine beliebige Kommunikationsschaltung, -vorrichtung oder -sammlung davon umgesetzt sein, die in der Lage ist, Kommunikationen über ein Netzwerk zwischen der Rechenschaltungsanordnung 802 und einer anderen Rechenvorrichtung (z.B. einem Edge-Gateway eines implementierenden Edge-Rechensystems) zu ermöglichen. Das Kommunikationsschaltungsanordnungs-Subsystem 812 kann dazu konfiguriert sein, eine oder mehrere beliebige Kommunikationstechnologien (z.B. drahtgebundene oder drahtlose Kommunikationen) und assoziierte Protokolle (z.B. ein zellulares Vernetzungsprotokoll, wie etwa den 3GPP-, 4G- oder 5G-Standard, ein drahtloses lokales Netzwerkprotokoll, wie etwa IEEE 802.11/Wi-Fi®, ein drahtloses Weitverkehrsnetzprotokoll, Ethernet, Bluetooth®, Bluetooth Low Energy, ein IoT-Protokoll, wie etwa IEEE 802.15.4 oder ZigBee®, Low-Power Wide Area Network (LPWAN)- oder Low-Power Wide Area (LPWA)-Protokolle usw.) zu verwenden, um eine solche Kommunikation zu bewirken.
Das veranschaulichende Kommunikationsschaltungsanordnungs-Subsystem 812 beinhaltet eine Netzwerkschnittstellensteuerung (NIC) 820, die auch als Host-Fabric-Schnittstelle (HFI) bezeichnet werden kann. Die NIC 820 kann als eine oder mehrere Zusatzplatinen, untergeordnete Karten, Netzwerkschnittstellenkarten, Steuerchips, Chipsätze oder andere Vorrichtungen ausgebildet sein, die vom Rechenknoten 800 verwendet werden können, um sich mit einer anderen Rechenvorrichtung (z.B. einen Edge-Gateway-Knoten) zu verbinden. In manchen Beispielen kann die NIC 820 als Teil eines System-on-a-Chip (SoC) umgesetzt sein, das einen oder mehrere Prozessoren beinhaltet, oder auf einem Mehrchipgehäuse enthalten sein, das auch einen oder mehrere Prozessoren enthält. In einigen Beispielen kann die NIC 820 einen lokalen Prozessor (nicht gezeigt) und/oder einen lokalen Speicher (nicht gezeigt) beinhalten, die beide lokal zur NIC 820 sind. In solchen Beispielen kann der lokale Prozessor der NIC 820 dazu in der Lage sein, eine oder mehrere der Funktionen der hier beschriebenen Berechnungsschaltungsanordnung 802 durchzuführen. Zusätzlich oder in solchen Beispielen kann der lokale Speicher der NIC 820 in eine oder mehrere Komponenten des Client-Rechenknotens auf Platinenebene, Socket-Ebene, Chip-Ebene und/oder anderen Ebenen integriert sein.
Zusätzlich kann in einigen Beispielen ein jeweiliger Rechenknoten 800 eine oder mehrere Peripherievorrichtungen 814 beinhalten. Solche Peripherievorrichtungen 814 können eine beliebige Art von Peripherievorrichtung beinhalten, die in einer Rechenvorrichtung oder einem Server zu finden ist, wie etwa Audioeingabevorrichtungen, eine Anzeige, andere Eingabe/Ausgabevorrichtungen, Schnittstellenvorrichtungen und/oder andere Peripherievorrichtungen, je nach der bestimmten Art des Rechenknotens 800. In weiteren Beispielen kann der Rechenknoten 800 durch einen jeweiligen Edge-Rechenknoten (egal, ob ein Client, Gateway oder Aggregationsknoten) in einem Edge-Computing-System oder ähnlichen Formen von Geräten, Computern, Subsystemen, Schaltungsanordnungen oder anderen Komponenten realisiert sein.
In einem ausführlicheren Beispiel veranschaulicht 8B ein Blockdiagramm eines Beispiels für Komponenten, die in einem Edge-Rechenknoten 850 zum Implementieren der hierin beschriebenen Techniken (z. B. Operationen, Prozesse, Verfahren und Methodiken) vorhanden sein können. Dieser Edge-Computing-Knoten 850 stellt eine nähere Ansicht der jeweiligen Komponenten des Knotens 800 bereit, wenn er als oder als Teil einer Rechenvorrichtung (z.B. als eine Mobilvorrichtung, eine Basisstation, ein Server, ein Gateway usw.) implementiert ist. Der Edge-Rechenknoten 850 kann beliebige Kombinationen der hier referenzierten Hardware oder logischen Komponenten beinhalten und er kann eine beliebige Einrichtung umfassen oder an eine solche koppeln, die mit einem Edge-Kommunikationsnetzwerk oder einer Kombination derartiger Netzwerke verwendbar ist. Die Komponenten können als integrierte Schaltungen (ICs), Teile davon, diskrete elektronische Vorrichtungen oder andere Module, Befehlssätze, programmierbare Logik oder Algorithmen, Hardware, Hardwarebeschleuniger, Software, Firmware oder eine Kombination davon, die in dem Edge-Computing-Knoten 850 ausgelegt sind, oder als Komponenten, die anders in einem Chassis eines größeren Systems integriert sind, implementiert sein.
Der Edge-Computing-Knoten 850 kann eine Verarbeitungsschaltungsanordnung in der Form eines Prozessors 852 beinhalten, der ein Mikroprozessor, ein Mehrkernprozessor, ein Multi-Thread-Prozessor, ein Kleinstspannungsprozessor, ein eingebetteter Prozessor, eine xPU/DPU/IPU/NPU, eine Spezialverarbeitungseinheit, eine spezialisierte Verarbeitungseinheit oder andere bekannte Verarbeitungselemente sein kann. Der Prozessor 852 kann ein Teil eines System on a Chip (SoC) sein, in dem der Prozessor 852 und andere Komponenten in einer einzigen integrierten Schaltung oder einem einzigen Package gebildet sind, wie etwa die Edison™- oder Galileo™-SoC-Platinen von Intel Corporation, Santa Clara, Kalifornien. Als ein Beispiel kann der Prozessor 852 einen auf der Intel® Architecture Core™ basierenden CPU-Prozessor beinhalten, wie etwa einen Quark™-, einen Atom™-, einen i3-, einen i5-, einen i7-, einen i9- oder einen Prozessor der MCU-Klasse oder einen anderen solchen, von Intel® erhältlichen Prozessor. Es kann jedoch eine beliebige Anzahl anderer Prozessoren verwendet werden, wie etwa von Advanced Micro Devices, Inc., (AMD®) in Sunnyvale, Kalifornien, ein auf MIPS® basierendes Design von MIPS Technologies, Inc., in Sunnyvale, Kalifornien, ein auf ARM® basierendes Design, lizenziert von ARM Holdings, Ltd., oder eines ihrer Kunden davon oder deren Lizenznehmern oder Anwendern. Die Prozessoren können Einheiten, wie etwa einen A5-A13-Prozessor von Apple® Inc., einen Snapdragon™-Prozessor von Qualcomm® Technologies, Inc., oder einen OMAP™-Prozessor von Texas Instruments, Inc., beinhalten. Der Prozessor 852 und die begleitende Schaltungsanordnung können in einem Einzelsockel-Formfaktor, Mehrsockel-Formfaktoren oder einer Vielfalt anderer Formate bereitgestellt sein, einschließlich in beschränkten Hardwarekonfigurationen oder Konfigurationen, die weniger als alle der in 8B gezeigten Elemente beinhalten.
Der Prozessor 852 kann über eine Zwischenverbindung 856 (z.B. einen Bus) mit einem Systemspeicher 854 kommunizieren. Eine beliebige Anzahl von Speichervorrichtungen kann verwendet werden, um eine gegebene Menge an Systemspeicher bereitzustellen. Als ein Beispiel kann der Speicher 854 ein Direktzugriffsspeicher (Random Access Memory, RAM) gemäß einem Design des Joint Electron Devices Engineering Council (JEDEC) sein, wie etwa die DDR- oder Mobile-DDR-Standards (z. B. LPDDR, LPDDR2, LPDDR3 oder LPDDR4). In bestimmten Beispielen kann eine Speicherkomponente einen von JEDEC veröffentlichten DRAM-Standard erfüllen, wie etwa JESD79F für DDR-SDRAM, JESD79-2F für DDR2-SDRAM, JESD79-3F für DDR3-SDRAM, JESD79-4A für DDR4-SDRAM, JESD209 für Low-Power-DDR (LPDDR), JESD209-2 für LPDDR2, JESD209-3 für LPDDR3 und JESD209-4 für LPDDR4. Solche Standards (und ähnliche Standards) können als DDR-basierte Standards bezeichnet werden, und Kommunikationsschnittstellen der Speichervorrichtungen, die solche Standards implementieren, können als DDR-basierte Schnittstellen bezeichnet werden. In verschiedenen Implementierungen können die einzelnen Speichervorrichtungen von einer beliebigen Anzahl von unterschiedlichen Packagetypen sein, wie etwa Single Die Package (SDP), Dual Die Package (DDP) oder Quad Die Package (Q17P). Diese Vorrichtungen können in manchen Beispielen direkt auf eine Hauptplatine gelötet sein, um eine Lösung mit niedrigerem Profil bereitzustellen, während die Vorrichtungen in anderen Beispielen als ein oder mehrere Speichermodule ausgelegt sind, die wiederum durch einen gegebenen Verbinder mit der Hauptplatine gekoppelt sind. Eine beliebige Anzahl anderer Speicherimplementierungen kann verwendet werden, wie etwa andere Typen von Speichermodulen, z.B. Dual-Inline-Speichermodule (DIMMs) verschiedener Varianten, einschließlich unter anderem microDIMMs oder MiniDIMMs.
Um eine dauerhafte Speicherung von Informationen, wie etwa Daten, Anwendungen, Betriebssystemen und so weiter, bereitzustellen, kann ein Speicher 858 auch über die Zwischenverbindung 856 mit dem Prozessor 852 gekoppelt sein. In einem Beispiel kann der Speicher 858 über ein Festkörperplattenlaufwerk (SSDD) implementiert sein. Andere Vorrichtungen, die für den Speicher 858 verwendet werden können, beinhalten Flashspeicherkarten, wie etwa Secure Digital (SD)-Karten, microSD-Karten, eXtreme Digital (XD)-Bildkarten und dergleichen und Universal Serial Bus (USB)-Flash-Laufwerke. In einem Beispiel kann die Speichervorrichtung Speichervorrichtungen sein oder umfassen, die Chalkogenidglas, NAND-Flash-Speicher mit mehreren Schwellenwertpegeln, NOR-Flash-Speicher, Phasenwechselspeicher (PCM) mit einem oder mehreren Pegeln, einen resistiven Speicher, Nanodrahtspeicher, ferroelektrischen Transistor-Direktzugriffsspeicher (FeTRAM), antiferroelektrischen Speicher, magnetoresistiven Direktzugriffsspeicher (MRAM), der Memristor-Technologie umfasst, resistiven Speicher einschließlich des Metalloxidbasis-, Sauerstoffleerstellenbasiss und Conductive-Bridge-Direktzugriffsspeichers (CB-RAM) oder des Spin Transfer Torque (STT)-MRAMs, eine Vorrichtung auf der Basis eines Spintronik-Speichers mit magnetischem Übergang, eine Vorrichtung auf der Basis eines Magnetotunnelungsübergang (MTJ), eine Vorrichtung auf Basis von DW (Domain Wall) und SOT (Spin Orbit Transfer), eine Speichervorrichtung auf Thyristorbasis oder eine Kombination beliebiger der obigen oder anderen Speicher verwenden.
Bei Niederleistungsimplementierungen kann der Speicher 858 On-Die-Speicher oder -Register sein, der/das mit dem Prozessor 852 assoziiert ist. In einigen Beispielen kann der Speicher 858 jedoch unter Verwendung eines Mikrofestplattenlaufwerks (HDD) implementiert sein. Ferner kann eine beliebige Anzahl neuer Technologien für den Speicher 858 zusätzlich zu oder anstelle der beschriebenen Technologien verwendet werden, wie etwa unter anderem Widerstandswechselspeicher, Phasenwechselspeicher, holografische Speicher oder chemische Speicher.
Die Komponenten können über die Zwischenverbindung 856 kommunizieren. Die Zwischenverbindung 856 kann eine beliebige Anzahl von Technologien beinhalten, einschließlich Industriestandardarchitektur (ISA), erweiterte ISA (EISA), Peripheral Component Interconnect (PCI), Peripheral Component Interconnect Extended (PCIx), PCI Express (PCIe) oder eine beliebige Anzahl anderer Technologien. Die Zwischenverbindung 856 kann ein proprietärer Bus sein, der zum Beispiel in einem SoC-basierten System verwendet wird. Andere Bussysteme können beinhaltet sein, wie etwa unter anderem eine Inter-Integrated-Circuit- (I2C-) Schnittstelle, eine Serial-Peripheral-Interface- (SPI-) Schnittstelle, Punkt-zu-Punkt-Schnittstellen und ein Leistungsbus.
Die Zwischenverbindung 856 kann den Prozessor 852 mit einem Transceiver 866 (z.B. einem Drahtlosnetzwerk-Transceiver) zur Kommunikation mit den verbundenen Edge-Vorrichtungen 862 koppeln. Der Mesh-Transceiver 866 kann eine beliebige Anzahl von Frequenzen und Protokollen verwenden, wie etwa unter anderem zum Beispiel 2,4-Gigahertz (GHz)-Übertragungen nach dem IEEE-802.15.4-Standard unter Verwendung des Bluetooth®-Low-Energy-Standards (BLE-Standards), wie von der Bluetooth® Special Interest Group definiert, oder des ZigBee®-Standards. Eine beliebige Anzahl von Funkgeräten, die für ein bestimmtes Drahtloskommunikationsprotokoll konfiguriert sind, kann für die Verbindungen mit den verbundenen Edge-Vorrichtungen 862 verwendet werden. Zum Beispiel kann eine Wireless Local Area Network (WLAN)-Einheit verwendet werden, um Wi-Fi®-Kommunikationen gemäß dem Standard des Institute of Electrical and Electronics Engineers (IEEE) 802.11 zu implementieren. Außerdem können drahtlose Weitverkehrskommunikationen, z.B. gemäß einem zellularen oder anderen Drahtlos-Weitverkehrsprotokoll, über eine drahtlose Weitverkehrsnetzwerk- (WWAN-) Einheit erfolgen.
Der Drahtlosnetzwerk-Transceiver 866 (oder mehrere Transceiver) kann unter Verwendung mehrerer Standards oder Funkgeräte für Kommunikationen mit einer anderen Reichweite kommunizieren. Zum Beispiel kann der Edge-Rechenknoten 850 mit nahen Vorrichtungen, z.B. innerhalb von etwa 10 Metern, unter Verwendung eines lokalen Transceivers basierend auf Bluetooth Low Energy (BLE) oder einem anderen Niedrigleistungsfunkgerät kommunizieren, um Leistung zu sparen. Weiter entfernte verbundene Edge-Vorrichtungen 862, 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 mit unterschiedlichen Leistungspegeln stattfinden oder können über separate Transceiver stattfinden, zum Beispiel einen lokalen Transceiver, der BLE verwendet, und einen separaten Mesh-Transceiver, der ZigBee® verwendet.
Ein Drahtlosnetzwerk-Transceiver 866 (z.B. ein Funktransceiver) kann beinhaltet sein, um mit Vorrichtungen oder Diensten in der Edge-Cloud 895 über Lokal- oder Weitverkehrsnetzwerkprotokolle zu kommunizieren. Der Drahtlosnetzwerktransceiver 866 kann unter anderem ein Low-Power-Wide-Area- (LPWA-) Transceiver sein, der den Standards IEEE 802.15.4 oder IEEE 802.15.4g folgt. Der Edge-Computing-Knoten 850 kann über einen weiten Bereich unter Verwendung von LoRaWAN™ (Long Range Wide Area Network, Weitbereichs-Weitverkehrsnetz) kommunizieren, das von Semtech und der LoRa Alliance entwickelt wurde. Die hier beschriebenen Techniken sind nicht auf diese Technologien beschränkt, sondern können mit einer beliebigen Anzahl von anderen Cloud-Transceivern verwendet werden, die Kommunikationen mit großer Reichweite und niedriger Bandbreite implementieren, wie etwa Sigfox und andere Technologien. Ferner können andere Kommunikationstechniken verwendet werden, wie etwa Kanalspringen mit Zeitschlitzen (Time Slotted Channel Hopping), das in der IEEE 802.15.4e-Spezifikation beschrieben ist.
Eine beliebige Anzahl anderer Funkkommunikationen und Protokolle kann zusätzlich zu den für den Drahtlosnetzwerktransceiver 866 erwähnten Systemen verwendet werden, wie hierin beschrieben. Der Transceiver 866 kann zum Beispiel einen Mobilfunk-Sendeempfänger beinhalten, der Frequenzspreiz- (SPA/SAS-) Kommunikationen zum Implementieren von Hochgeschwindigkeitskommunikationen verwendet. Ferner kann eine beliebige Anzahl anderer Protokolle verwendet werden, wie etwa WiFi®-Netzwerke für Kommunikationen mittlerer Geschwindigkeit und Bereitstellung von Netzwerkkommunikationen. Der Transceiver 866 kann Funkgeräte umfassen, die mit einer beliebigen Anzahl von 3GPP (Third Generation Partnership Project)-Spezifikationen kompatibel sind, wie etwa Long Term Evolution (LTE) und Kommunikationssysteme der 5. Generation (5G), die am Ende der vorliegenden Offenbarung ausführlicher erörtert werden. Eine Netzwerkschnittstellensteuerung (NIC) 868 kann enthalten sein, um drahtgebundene Kommunikation zu Knoten der Edge-Cloud 895 oder zu anderen Vorrichtungen, wie etwa den verbundenen Edge-Vorrichtungen 862 (die z. B. vermascht sind), bereitzustellen. Die drahtgebundene Kommunikation kann eine Ethernet-Verbindung bereitstellen oder kann auf anderen Arten von Netzwerken basieren, wie etwa Controller Area Network (CAN), Local Interconnect Network (LIN), DeviceNet, ControlNet, Data Highway+, PROFIBUS oder PROFINET unter vielen anderen. Eine zusätzliche NIC 868 kann enthalten sein, um das Verbinden mit einem zweiten Netzwerk zu ermöglichen, wobei zum Beispiel eine erste NIC 868 Kommunikationen mit der Cloud über Ethernet bereitstellt und eine zweite NIC 868 Kommunikationen mit anderen Vorrichtungen über einen anderen Typ von Netzwerk bereitstellt.
Angesichts der Vielfalt von Typen anwendbarer Kommunikationen von der Vorrichtung zu einer anderen Komponente oder einem anderen Netzwerk können anwendbare Kommunikationsschaltungsanordnungen, die von der Vorrichtung verwendet werden, eine beliebige oder mehrere beliebige der Komponenten 864, 866, 868 oder 870 beinhalten oder durch diese realisiert sein. Dementsprechend können bei verschiedenen Beispielen anwendbare Mittel zum Kommunizieren (z.B. Empfangen, Senden usw.) durch eine solche Kommunikationsschaltungsanordnung verkörpert werden.
Der Edge-Computing-Knoten 850 kann eine Beschleunigungsschaltungsanordnung 864 beinhalten oder an eine solche gekoppelt sein, die durch einen oder mehrere Beschleuniger für künstliche Intelligenz (KI), einen neuronalen Rechenstick, neuromorphe Hardware, ein FPGA, eine Anordnung von GPUs, eine Anordnung von xPUs/DPUs/IPU/NPUs, eines oder mehrere SoCs, eine oder mehrere CPUs, einen oder mehrere digitale Signalprozessoren, dedizierte ASICs oder andere Formen spezialisierter Prozessoren oder Schaltungsanordnungen realisiert sein kann, die zum Erfüllen einer oder mehrerer spezialisierter Aufgaben konzipiert sind. Diese Aufgaben können KI-Verarbeitung (einschließlich Maschinenlern-, Trainings-, Inferenz- und Klassifizierungsoperationen), visuelle Datenverarbeitung, Netzdatenverarbeitung, Objektdetektion, Regelanalyse oder dergleichen beinhalten. Zu diesen Aufgaben können auch die an anderer Stelle in diesem Dokument besprochenen spezifischen Edge-Computing-Aufgaben für Dienstverwaltung und Dienstoperationen gehören.
Die Zwischenverbindung 856 kann den Prozessor 852 an einen Sensor-Hub oder eine externe Schnittstelle 870 koppeln, die zum Verbinden zusätzlicher Vorrichtungen oder Subsysteme verwendet wird. Die Vorrichtungen können Sensoren 872, wie etwa Beschleunigungsmesser, Pegelsensoren, Strömungssensoren, optische Lichtsensoren, Kamerasensoren, Temperatursensoren, Sensoren eines globalen Navigationssystems (z.B. GPS), Drucksensoren, Atmosphärendrucksensoren und dergleichen beinhalten. Der Sensor-Hub oder die externe Schnittstelle 870 kann ferner verwendet werden, um den Edge-Rechenknoten 850 mit Aktuatoren 874, wie etwa Leistungsschaltern, Ventilaktuatoren, einem Generator für hörbaren Ton, einer visuellen Warnvorrichtung und dergleichen, zu verbinden.
In manchen optionalen Beispielen können verschiedene Eingabe/Ausgabe (E/A)-Vorrichtungen innerhalb des Edge-Rechenknotens 850 vorhanden oder mit diesem verbunden sein. Zum Beispiel kann eine Anzeige oder eine anderen Ausgabevorrichtung 884 enthalten sein, um Informationen, wie etwa Sensormesswerte oder Aktuatorstellung, anzuzeigen. Eine Eingabevorrichtung 886, wie etwa ein Touchscreen oder eine Tastatur, kann enthalten sein, um Eingaben anzunehmen. Eine Ausgabevorrichtung 884 kann eine beliebige Anzahl von Formen einer Audio- oder visuellen Anzeige beinhalten, einschließlich einfacher visueller Ausgaben, wie etwa binärer Statusindikatoren (z. B. Leuchtdioden (LEDs)) und visueller Mehrzeichenausgaben, oder komplexere Ausgaben, wie etwa Anzeigebildschirme (z. B. Flüssigkristallanzeige (LCD)-Bildschirme), wobei die Ausgabe von Zeichen, Grafiken, Multimediaobjekten und dergleichen aus dem Betrieb des Edge-Computing-Knotens 850 generiert oder erzeugt wird. Eine Anzeige- oder Konsolenhardware kann im Kontext des vorliegenden Systems verwendet werden, um eine Ausgabe bereitzustellen und eine Eingabe eines Edge-Rechensystems zu empfangen; Komponenten oder Dienste eines Edge-Computing-Systems zu verwalten; einen Zustand einer Edge-Rechenkomponente oder eines Edge-Rechendienstes zu identifizieren oder eine beliebige andere Anzahl von Verwaltungs- oder Administrationsfunktionen oder Dienstanwendungsfällen durchzuführen.
Eine Batterie 876 kann den Edge-Rechenknoten 850 mit Strom versorgen, obwohl sie in Beispielen, in denen der Edge-Rechenknoten 850 an einem festen Standort montiert ist, eine Stromversorgung aufweisen kann, die mit einem Stromnetz gekoppelt ist, oder die Batterie als Ausfallsicherheit oder für temporäre Funktionen verwendet werden kann. Die Batterie 876 kann eine Lithium-Ionen-Batterie oder eine Metall-Luft-Batterie, wie etwa eine Zink-Luft-Batterie, eine Aluminium-Luft-Batterie, eine Lithium-Luft-Batterie und dergleichen, sein.
Ein Batterieüberwachungs-/-ladegerät 878 kann in dem Edge-Rechenknoten 850 beinhaltet sein, um den Ladezustand (SoCh) der Batterie 876, falls enthalten, zu verfolgen. Das Batterieüberwachungs-/-ladegerät 878 kann verwendet werden, um andere Parameter der Batterie 876 zu überwachen, um Störungsvorhersagen bereitzustellen, wie etwa den Gesundheitszustand (State of Health, SoH) und den Funktionszustand (State of Function, SoF) der Batterie 876. Das Batterieüberwachungs-/-ladegerät 878 kann eine integrierte Batterieüberwachungsschaltung beinhalten, wie etwa einen LTC4020 oder einen LTC2990 von Linear Technologies, einen ADT7488A von ON Semiconductor in Phoenix, Arizona, oder ein IC aus der UCD90xxx-Familie von Texas Instruments in Dallas, TX. Das Batterieüberwachungs-/-ladegerät 878 kann die Informationen über die Batterie 876 über die Zwischenverbindung 856 an den Prozessor 852 kommunizieren. Das Batterieüberwachungs-/-ladegerät 878 kann auch einen Analog-Digital-Wandler (ADC) beinhalten, der es dem Prozessor 852 ermöglicht, die Spannung der Batterie 876 oder den Stromfluss aus der Batterie 876 direkt zu überwachen. Die Batterieparameter können verwendet werden, um Aktionen zu bestimmen, die der Edge-Rechenknoten 850 durchführen kann, wie etwa Übertragungsfrequenz, Mesh-Netzwerkbetrieb, Abtastfrequenz und dergleichen.
Ein Leistungsblock 880 oder eine andere Leistungsversorgung, die an ein Stromnetz gekoppelt ist, kann mit dem Batterieüberwachungs-/-ladegerät 878 gekoppelt werden, um die Batterie 876 zu laden. In einigen Beispielen kann der Leistungsblock 880 durch einen Drahtlosleistungsempfänger ersetzt werden, um die Leistung drahtlos, zum Beispiel über eine Schleifenantenne im Edge-Computing-Knoten 850, zu beziehen. Eine Drahtlosbatterieladeschaltung, wie unter anderem ein LTC4020-Chip von Linear Technologies aus Milpitas, Kalifornien, kann in der Batterieüberwachungs-/-ladeeinrichtung 878 umfasst sein. Die spezifischen Ladeschaltungen können basierend auf der Größe der Batterie 876 und somit dem erforderlichen Strom ausgewählt werden. Das Laden kann unter anderem unter Verwendung des von der Airfuel Alliance veröffentlichten Standards Airfuel, des vom Wireless Power Consortium veröffentlichten Drahtlosladestandards Qi oder des von der Alliance for Wireless Power veröffentlichten Ladestandards Rezence durchgeführt werden.
Der Speicher 858 kann Anweisungen 882 in Form von Software, Firmware oder Hardwarebefehlen zum Implementieren der hierin beschriebenen Techniken beinhalten. Obwohl solche Anweisungen 882 als Codeblöcke gezeigt sind, die in dem Speicher 854 und dem Speicher 858 beinhaltet sind, versteht es sich, dass beliebige der Codeblöcke durch festverdrahtete Schaltungen ersetzt werden können, die zum Beispiel in eine anwendungsspezifische integrierte Schaltung (ASIC) eingebaut sind.
In einem Beispiel können die Anweisungen 882, die über den Speicher 854, den Speicher 858 oder den Prozessor 852 bereitgestellt werden, als ein nichtflüchtiges maschinenlesbares Medium 860 umgesetzt sein, das Code umfasst, um den Prozessor 852 anzuweisen, elektronische Operationen in dem Edge-Rechenknoten 850 durchzuführen. Der Prozessor 852 kann über die Zwischenverbindung 856 auf das nichtflüchtige maschinenlesbare Medium 860 zugreifen. Beispielsweise kann das nichflüchtige maschinenlesbare Medium 860 durch Vorrichtungen ausgebildet sein, die für den Speicher 858 beschrieben sind, oder kann spezifische Speichereinheiten beinhalten, wie etwa Speichervorrichtungen und/oder Speicherplatten, die optische Platten (z. B. Digital Versatile Disk (DVD), Compact Disk (CD), CD-ROM, Blu-ray-Disk), Flash-Laufwerke, Disketten, Festplatten (z. B. SSDs) enthalten, oder eine beliebige Anzahl anderer Hardwarevorrichtungen, in denen Informationen für eine beliebige Dauer (z. B. für längere Zeiträume, permanent, für kurze Momente, zum temporären Puffern und/oder Cachen) gespeichert werden. Das nichtflüchtige maschinenlesbare Medium 860 kann Anweisungen beinhalten, um den Prozessor 852 anzuweisen, eine spezifische Sequenz oder einen spezifischen Aktionsablauf durchzuführen, wie zum Beispiel in Bezug auf das eine oder die mehreren oben gezeigten Flussdiagramme und Blockdiagramme von Operationen und Funktionalität beschrieben. Wie hierin verwendet, sind die Ausdrücke „maschinenlesbares Medium“, „computerlesbares Medium“, „maschinenlesbarer Speicher“ und „computerlesbarer Speicher“ austauschbar. Wie hierin verwendet, ist der Begriff „nicht-transientes computerlesbares Medium“ ausdrücklich definiert, alle Typen von computerlesbarer Speichervorrichtung und/oder Speicherplatte zu beinhalten und sich ausbreitende Signale und Übertragungsmedien auszuschließen.
Auch in einem spezifischen Beispiel können die Anweisungen 882 auf dem Prozessor 852 (separat oder in Kombination mit den Anweisungen 882 des maschinenlesbaren Mediums 860) die Ausführung oder den Betrieb einer vertrauenswürdigen Ausführungsumgebung (Trusted Execution Environment, TEE) 890 konfigurieren. In einem Beispiel arbeitet die TEE 890 als ein geschützter Bereich, der für den Prozessor 852 zur sicheren Ausführung von Anweisungen und zum sicheren Zugriff auf Daten zugänglich ist. Verschiedene Implementierungen der TEE 890 und eines zugehörigen sicheren Bereichs im Prozessor 852 oder dem Speicher 854 können beispielsweise durch die Verwendung von Intel® Software Guard Extensions (SGX) oder ARM® TrustZone® Hardwaresicherheitserweiterungen, Intel® Management Engine (ME) oder Intel® Converged Security Manageability Engine (CSME) bereitgestellt werden. Andere Aspekte von Sicherheitshärtung, Hardware-Roots-of-Trust und vertrauenswürdigen oder geschützten Operationen können im Edge-Rechenknoten 850 durch die TEE 890 und den Prozessor 852 implementiert sein.
Obwohl die veranschaulichten Beispiele von 8A und 8B Beispielkomponenten für einen Rechenknoten bzw. eine Rechenvorrichtung beinhalten, sind hier offenbarte Beispiele nicht darauf beschränkt. Wie hier verwendet, kann ein „Computer“ manche oder alle der Beispielkomponenten der 8A und/oder 8B in verschiedenen Arten von Computing-Umgebungen beinhalten. Beispielhafte Rechenumgebungen beinhalten Edge-Rechenvorrichtungen (z. B. Edge-Computer) in einer verteilten Vernetzungsanordnung, so dass bestimmte teilnehmende Edge-Rechenvorrichtungen heterogene oder homogene Vorrichtungen sind. Wie hier verwendet, kann ein „Computer“ einen Personalcomputer, einen Server, ein Benutzergerät, einen Beschleuniger usw. beinhalten, einschließlich beliebiger Kombinationen davon. In einigen Beispielen beinhaltet verteilte Vernetzung und/oder verteiltes Rechnen eine beliebige Anzahl solcher Edge-Computing-Vorrichtungen, wie in 8A und/oder 8B veranschaulicht ist, die jeweils unterschiedliche Subkomponenten, unterschiedliche Speicherkapazitäten, E/A-Fähigkeiten usw. beinhalten können. Weil zum Beispiel einige Implementierungen von verteilter Vernetzung und/oder verteiltem Rechnen mit der bestimmten gewünschten Funktionalität assoziiert sind, beinhalten hier offenbarte Beispiele unterschiedliche Kombinationen von Komponenten, die in 8A und/oder 8B veranschaulicht sind, um Funktionsziele verteilter Rechenaufgaben zu erfüllen. In einigen Beispielen beinhaltet der Begriff „Rechenknoten“ oder „Computer“ nur den beispielhaften Prozessor 804, den Speicher 806 und das E/A-Subsystem 808 von 8A. In einigen Beispielen hängen eine oder mehrere Zielfunktionen von verteilten Rechenaufgabe(en) von einer oder mehreren alternativen Vorrichtungen/Strukturen ab, die sich in unterschiedlichen Teilen einer Edge-Vernetzungsumgebung befinden, wie etwa Vorrichtungen zum Aufnehmen von Datenspeicher (z.B. die eine oder die mehreren Datenspeichervorrichtungen 810), Eingabe/Ausgabe-Fähigkeiten (z.B. die beispielhafte(n) Peripherievorrichtung(en) 814) und/oder Netzwerkkommunikationsfähigkeiten (z.B. die beispielhafte NIC 820).
In einigen Beispielen sind Computer, die in einer verteilten Rechen- und/oder verteilten Vernetzungsumgebung (z.B. einem Edge-Netzwerk) arbeiten, dafür strukturiert, bestimmte Zielfunktionalität auf eine Weise unterzubringen, die Rechenverschwendung reduziert. Weil beispielsweise ein Computer eine Teilmenge der in 8A und 8B offenbarten Komponenten beinhaltet, erfüllen solche Computer die Ausführung von verteilten Rechenzielfunktionen, ohne eine Rechenstruktur zu beinhalten, die ansonsten ungenutzt und/oder unternutzt wäre. Somit schließt der Begriff „Computer“, wie hier verwendet, eine beliebige Kombination der Struktur von 8A und/oder 8B ein, die in der Lage ist, Zielfunktionen von verteilten Rechenaufgaben zu erfüllen und/oder anderweitig auszuführen. In einigen Beispielen sind Computer auf eine Weise strukturiert, die entsprechenden Zielfunktionen des verteilten Rechnens entspricht, auf eine Weise, die in Verbindung mit dynamischem Bedarf runterskaliert oder hochskaliert. In einigen Beispielen werden unterschiedliche Computer aufgrund ihrer Fähigkeit, eine oder mehrere Aufgaben der Anfrage(n) für verteiltes Rechnen zu verarbeiten, aufgerufen und/oder anderweitig instanziiert, so dass jeder Computer, der in der Lage ist, die Aufgaben zu erfüllen, mit einer solchen Rechenaktivität fortfährt.
In den veranschaulichten Beispielen von 8A und 8B beinhalten Rechenvorrichtungen Betriebssysteme. Wie hier verwendet, ist ein „Betriebssystem“ Software zum Steuern beispielhafter Computing-Vorrichtungen, wie etwa des beispielhaften Edge-Rechenknotens 800 von 8A und/oder des beispielhaften Edge-Rechenknotens 850 von 8B. Beispielhafte Betriebssysteme beinhalten unter anderem verbraucherbasierte Betriebssysteme (z.B. Microsoft® Windows® 10, Google® Android® OS, Apple® Mac® OS usw.). Beispielhafte Betriebssysteme beinhalten unter anderem auch industriefokussierte Betriebssysteme, wie etwa Echtzeitbetriebssysteme, Hypervisoren usw. Ein beispielhaftes Betriebssystem auf einem ersten Edge-Rechenknoten kann das gleiche oder ein anderes als ein beispielhaftes Betriebssystem auf einem zweiten Edge-Rechenknoten sein. In einigen Beispielen ruft das Betriebssystem alternative Software auf, um eine oder mehrere Funktionen und/oder Operationen zu ermöglichen, die nicht nativ für das Betriebssystem sind, wie etwa bestimmte Kommunikationsprotokolle und/oder -interpreter. In einigen Beispielen instanziiert das Betriebssystem verschiedene Funktionalitäten, die für das Betriebssystem nicht nativ sind. In einigen Beispielen beinhalten Betriebssysteme variierende Komplexitäts- und/oder Fähigkeitsgrade. Beispielsweise beinhaltet ein erstes Betriebssystem, das einem ersten Edge-Rechenknoten entspricht, ein Echtzeitbetriebssystem, das bestimmte Leistungsfähigkeitserwartungen des Ansprechens auf dynamische Eingabebedingungen aufweist, und ein zweites Betriebssystem, das einem zweiten Edge-Rechenknoten entspricht, beinhaltet grafische Benutzeroberflächenfähigkeiten, um Endbenutzer-E/A zu ermöglichen.
In weiteren Beispielen beinhaltet ein nicht-transientes maschinenlesbares Medium (z.B. ein computerlesbares Medium) auch ein beliebiges Medium (z.B. Speichervorrichtung, Speicherplatte usw.), das in der Lage ist, Befehle zur Ausführung durch eine Maschine zu speichern, zu codieren oder zu transportieren, und das bewirkt, dass die Maschine eine oder mehrere beliebige der Methoden der vorliegenden Offenbarung durchführt, oder das in der Lage ist, Datenstrukturen zu speichern, zu codieren oder zu transportieren, die von solchen Befehlen genutzt werden oder mit diesen assoziiert sind. Ein „nicht-transientes maschinenlesbares Medium“ kann somit unter anderem Festkörperspeicher und optische und magnetische Medien beinhalten. Konkrete Beispiele für maschinenlesbare Medien beinhalten nichtflüchtigen Speicher, einschließlich beispielsweise unter anderem Halbleiterspeichervorrichtungen (z.B. elektrisch programmierbaren Nur-Lese-Speicher (EPROM), elektrisch löschbaren programmierbaren Nur-Lese-Speicher (EEPROM)) und Flash-Speichervorrichtungen; Magnetplatten, wie etwa interne Festplatten und austauschbare Platten (z.B. SSDs); magnetooptische Platten; und CD-ROM- und DVD-ROM-Platten. Die Anweisungen, die durch ein maschinenlesbares Medium ausgebildet sind, können ferner über ein Kommunikationsnetzwerk unter Verwendung eines Übertragungsmediums über eine Netzwerkschnittstellenvorrichtung übertragen oder empfangen werden, die ein beliebiges einer Anzahl von Übertragungsprotokollen (z.B. Hypertext Transfer Protocol (HTTP)) nutzt.
Ein maschinenlesbares Medium kann durch eine Speichervorrichtung oder eine andere Einrichtung bereitgestellt sein, die in der Lage ist, Daten in einem nichtflüchtigen Format zu hosten. Wie hierin verwendet, ist der Begriff „nicht-transientes computerlesbares Medium“ ausdrücklich definiert, alle Typen von computerlesbarer Speichervorrichtung und/oder Speicherplatte zu beinhalten und sich ausbreitende Signale und Übertragungsmedien auszuschließen. In einem Beispiel können auf einem maschinenlesbaren Medium gespeicherte oder anderweitig bereitgestellte Informationen Anweisungen repräsentieren, wie etwa Anweisungen selbst oder ein Format, aus dem die Anweisungen abgeleitet werden können. Dieses Format, aus dem die Anweisungen abgeleitet werden können, kann Quellcode, codierte Anweisungen (z.B. in komprimierter oder verschlüsselter Form), verpackte Anweisungen (z.B. aufgeteilt in mehrere Packages) oder dergleichen beinhalten. Die Informationen, die die Anweisungen in dem maschinenlesbaren Medium repräsentieren, können von einer Verarbeitungsschaltungsanordnung in die Anweisungen zum Implementieren beliebiger der hier erörterten Operationen verarbeitet werden. Das Ableiten der Anweisungen aus den Informationen (z.B. ein Verarbeiten durch die Verarbeitungsschaltungsanordnung) kann zum Beispiel beinhalten: Kompilieren (z.B. aus Quellcode, Objektcode usw.), Interpretieren, Laden, Organisieren (z.B. dynamisches oder statisches Verlinken), Codieren, Decodieren, Verschlüsseln, Entschlüsseln, Verpacken, Entpacken oder anderweitiges Manipulieren der Informationen in die Anweisungen.
In einem Beispiel kann das Ableiten der Anweisungen Assemblieren, Kompilieren oder Interpretieren der Informationen (z.B. durch die Verarbeitungsschaltungsanordnung) beinhalten, um die Anweisungen aus einem Zwischenformat oder einem vorverarbeiteten Format zu erzeugen, das durch das maschinenlesbare Medium bereitgestellt wird. Die Informationen können, wenn sie in mehreren Teilen bereitgestellt werden, kombiniert, entpackt und modifiziert werden, um die Anweisungen zu erzeugen. Zum Beispiel können die Informationen in mehreren komprimierten Quellcodepaketen (oder Objektcode oder binärem ausführbaren Code usw.) auf einem oder mehreren entfernten Servern vorliegen. Die Quellcodepakete können verschlüsselt sein, wenn sie über ein Netzwerk bewegt werden, und bei Bedarf entschlüsselt, entkomprimiert, zusammengesetzt (z.B. verlinkt) werden und in einer lokalen Maschine kompiliert oder interpretiert werden (z.B. in eine Bibliothek, eigenständige ausführbare Datei usw.) und von der lokalen Maschine ausgeführt werden.
8C veranschaulicht eine beispielhafte Softwareverteilungsplattform 896 zum Verteilen von Software, wie etwa der beispielhaften computerlesbaren Anweisungen 899, zu einer oder mehreren Vorrichtungen, wie etwa der/den Prozessorplattform(en) 898 und/oder den beispielhaften verbundenen Edge-Vorrichtungen 862 von 8B. Die beispielhafte Softwareverteilungsplattform 896 kann von einem beliebigen Computerserver, einer beliebigen Dateneinrichtung, einem beliebigen Cloud-Dienst usw. umgesetzt werden, der in der Lage ist, Software zu speichern und zu anderen Rechenvorrichtungen zu übertragen (z.B. Dritten, den beispielhaften verbundenen Edge-Vorrichtungen 862 von 8B). Beispielhafte verbundene Edge-Vorrichtungen können Kunden, Clients, Verwaltungsvorrichtungen (z.B. Server), Dritte (z.B. Kunden einer Entität, die die Softwareverteilungsplattform 896 besitzt und/oder betreibt) sein. Beispielhafte verbundene Edge-Vorrichtungen können in kommerziellen und/oder Heimautomatisierungsumgebungen arbeiten. In einigen Beispielen ist ein Dritter ein Entwickler, ein Verkäufer und/oder ein Lizenzgeber von Software, wie etwa der beispielhaften computerlesbaren Anweisungen 899. Die Dritten können Verbraucher, Benutzer, Einzelhändler, OEMs usw. sein, die die Software zur Verwendung und/oder zum Weiterverkauf und/oder zum Sublizenzieren erwerben und/oder lizenzieren. In einigen Beispielen bewirkt verteilte Software, dass die Anzeige einer oder mehrerer Benutzeroberflächen (UIs) und/oder grafischer Benutzeroberflächen (GUIs) die eine oder die mehreren Vorrichtungen (z.B. verbundene Edge-Vorrichtungen) geographisch und/oder logisch voneinander getrennt identifiziert (z.B. physisch getrennte IoT-Vorrichtungen, die mit der Verantwortung für Wasserverteilungssteuerung (z.B. Pumpen), Stromverteilungssteuerung (z.B. Relais) usw. betraut sind).
In dem veranschaulichten Beispiel von 8C beinhaltet die Softwareverteilungsplattform 896 einen oder mehrere Server und eine oder mehrere Speichervorrichtungen. Die Speichervorrichtungen speichern die computerlesbaren Anweisungen 899, die den beispielhaften computerlesbaren Anweisungen 882 von 8B entsprechen können, wie oben beschrieben. Der eine oder die mehreren Server der beispielhaften Softwareverteilungsplattform 896 stehen in Kommunikation mit einem Netzwerk 897, das unter anderem dem Internet und/oder einem der hierin beschriebenen beispielhaften Netzwerke entsprechen kann. In einigen Beispielen reagieren der eine oder die mehreren Server auf Anfragen, die Software als Teil einer kommerziellen Transaktion an eine anfragende Partei zu übertragen. Die Zahlung für die Lieferung, den Verkauf und/oder die Lizenz der Software kann durch den einen oder die mehreren Server der Softwareverteilungsplattform und/oder über eine Zahlungsentität eines Dritten gehandhabt werden. Die Server ermöglichen Käufern und/oder Lizenzgebern, die computerlesbaren Anweisungen 899 von der Softwareverteilungsplattform 896 herunterzuladen. Zum Beispiel kann die Software, die den beispielhaften computerlesbaren Anweisungen 882 von 8B entsprechen kann, auf die beispielhafte (n) Prozessorplattform(en) 898 (z.B. beispielhafte verbundene Edge-Vorrichtungen) heruntergeladen werden, die die computerlesbaren Anweisungen 899 ausführen sollen/soll, um die hier erörterten Techniken zu implementieren. In einigen Beispielen sind ein oder mehrere Server der Softwareverteilungsplattform 896 kommunikativ mit einer oder mehreren Sicherheitsdomänen und/oder Sicherheitsvorrichtungen verbunden, durch die Anfragen und Übertragungen der beispielhaften computerlesbaren Anweisungen 899 laufen müssen. In einigen Beispielen bieten ein oder mehrere Server der Softwareverteilungsplattform 896 periodisch Aktualisierungen für die Software an (z.B. die beispielhaften computerlesbaren Anweisungen 882 von 8B, die die gleichen wie die computerlesbaren Anweisungen 899 sein können), übertragen und/oder erzwingen diese, um sicherzustellen, dass Verbesserungen, Patches, Aktualisierungen usw. an die Software auf den Endbenutzervorrichtungen verteilt und angewendet werden.
In dem veranschaulichten Beispiel von 8C sind die computerlesbaren Anweisungen 899 auf Speichervorrichtungen der Softwareverteilungsplattform 896 in einem speziellen Format gespeichert. Ein Format computerlesbarer Anweisungen beinhaltet unter anderem eine bestimmte Codesprache (z.B. Java, JavaScript, Python, C, C#, SQL, HTML usw.) und/oder einen bestimmten Codezustand (z.B. unkompilierten Code (z.B. ASCII), interpretierten Code, verlinkten Code, ausführbaren Code (z.B. eine Binärdatei) usw.). In einigen Beispielen befinden sich die computerlesbaren Anweisungen 899, die in der Softwareverteilungsplattform 896 gespeichert sind, in einem ersten Format, wenn sie an die beispielhafte(n) Prozessorplattform(en) 896 übertragen werden. In einigen Beispielen ist das erste Format eine ausführbare Binärdatei, in der bestimmte Arten der Prozessorplattform(en) 898 arbeiten können. In einigen Beispielen ist das erste Format jedoch unkompilierter Code, der eine oder mehrere Vorbereitungsaufgaben erfordert, um das erste Format in ein zweites Format umzuwandeln, um eine Ausführung auf der/den beispielhaften Prozessorplattform(en) 898 zu ermöglichen. Beispielsweise müssen die empfangende(n) Prozessorplattform(en) 898 möglicherweise die computerlesbaren Anweisungen 899 im ersten Format kompilieren, um ausführbaren Code in einem zweiten Format zu erzeugen, der auf der/den Prozessorplattform(en) 898 ausgeführt werden kann. In noch anderen Beispielen ist das erste Format interpretierter Code, der beim Erreichen der Prozessorplattform(en) 898 von einem Interpretierer interpretiert wird, um die Ausführung von Anweisungen zu ermöglichen.
9A veranschaulicht eine MEC-Netzwerkarchitektur mit MEC-V2X-API-Interoperabilitätsunterstützung für mehrere V2X-Nachrichtenbroker gemäß einer beispielhaften Ausführungsform. 9A veranschaulicht insbesondere eine MEC-Architektur 900A mit den MEC-Hosts 902 und 904, die Funktionalitäten gemäß einer oder mehreren ETSI-MEC-Spezifikationen (z.B. ETSI GS MEC 003, ETSI GS MEC 011 und ETSI GS MEC 030 Spezifikationen) bereitstellen. Insbesondere können Verbesserungen an der MEC-Plattform 932 (wie z.B. in Verbindung mit 10 - 14 erörtert) sowie V2X-Nachrichtensignalisierung (z.B. V2X-Nachrichtensubskriptionssignalisierung und V2X-Nachrichtenveröffentlichungssignalisierung) verwendet werden, um die MEC-V2X-API-Interoperabilitätsunterstützung innerhalb der MEC-Architektur 900A bereitzustellen.
Mit Bezug auf 9A beinhaltet die MEC-Architektur 900A die MEC-Hosts 902 und 904, einen Virtualisierungsinfrastrukturmanager (VIM) 908, einen MEC-Plattformmanager 906 (auch als Mobile-Edge-Plattformmanager oder MEPM bezeichnet), einen Mobile Edge Application Orchestrator (MEAO) (auch als ein MEC-Orchestrator oder MEO bezeichnet) 910, ein Operationsunterstützungssystem (OSS) 912, einen Benutzer-App-Proxy 914, eine UE-App 918, die auf dem UE 920 läuft, und ein CFS-Portal 916. Der MEC-Host 902 kann eine MEC-Plattform 932 mit einem Filterregelsteuermodul 940, einem DNS-Handhabungsmodul 942, einer Dienstregistrierungsdatenbank 938 und MEC-Diensten 936 beinhalten. Der MEC-Host 904 kann Ressourcen beinhalten, die zum Instanziieren der MEC-Apps 905 verwendet werden. Die MEC-Dienste 936 können mindestens einen Scheduler (Planer) 937 beinhalten, der verwendet werden kann, um Ressourcen zum Instanziieren der MEC-Apps (oder NFVs) 926 und 928 auf der Virtualisierungsinfrastruktur 922 auszuwählen, die eine Datenebene 924 beinhaltet. Die MEC-Dienste 936 beinhalten ferner einen VIS 934, der vorliegend in Verbindung mit 2 - 5 ausführlicher erläutert wird. In einigen Ausführungsformen ist der VIS 934 dazu ausgelegt, Protokollkonvertierungsfunktionen und Datenweiterleitungsfunktionen durchzuführen, die zum Bereitstellen von MEC-V2X-API-Interoperabilitätsunterstützung für mehrere V2X-Nachrichtenbroker in der MEC-Architektur 900A verwendet werden.
Die MEC-Apps 926 und 928 können dazu konfiguriert sein, die Dienste 930/931 bereitzustellen, die Verarbeiten von Netzwerkkommunikationsverkehr unterschiedlicher Arten beinhalten können, der mit einer oder mehreren Drahtlosverbindungen assoziiert ist. In einigen Ausführungsformen beinhalten die Dienste 930/931 Nachrichtenbroker-Dienste, die dazu ausgelegt sind, mehrere Anwendungsschichtprotokolle zu unterstützen, die bei der Sammlung/Verteilung von Daten von/an mehrere Datenquellen über verschiedene MNOs hinweg verwendet werden. In dieser Hinsicht können die Dienste 930/931, die von MEC-Apps bereitgestellt werden, auch als V2X-Nachrichtenbroker bezeichnet werden. In anderen Ausführungsformen werden die MEC-Apps 926 und 928 für V2X-Nachrichtensubskription (z.B. um V2X-Nachrichten zu abonnieren, die von V2X-Nachrichtenbrokern verteilt werden) und V2X-Nachrichtenveröffentlichung (z.B. um Daten an V2X-Nachrichtenbroker zu veröffentlichen, die an V2X-Nachrichtenabonnenten verteilt werden können) verwendet.
In einigen Ausführungsformen kann eine erste MEC-App (z.B. die MEC-App 905 im MEC-Host 904) als ein V2X-Nachrichtenbroker konfiguriert sein, während eine zweite MEC-App (z.B. die MEC-App 926 im MEC-Host 902) als ein MEC-V2X-Nachrichtendienstabonnent/-verbraucher konfiguriert sein kann. In diesem Fall kann ein Kommunikationslink (z.B. eine direkte Datenverbindung) 990 zwischen zwei separaten MEC-Apps (z.B. MEC-Apps , die in zwei oder mehr unterschiedlichen MEC-Hosts instanziiert sind, oder MEC-Apps, die in demselben MEC-Host instanziiert sind) eingerichtet werden. In dieser Hinsicht kann der V2X-Nachrichtenbroker auch als dienstproduzierende MEC-App bezeichnet werden.
Gemäß anderen Aspekten kann der V2X-Nachrichtenbroker als ein registrierter Dienst der MEC-Plattform 932 als Erzeuger von V2X-Nachrichten konfiguriert sein. Mit anderen Worten ist der Nachrichtenbroker Teil einer Dienstregistrierungsdatenbank einer MEC-Plattform. In diesem Fall wird Kommunikation mit einer MEC-App, die eine Subskription für einen V2X-Nachrichtenübermittlungsdienst anfragt, innerhalb desselben MEC-Hosts über die Mp1-Schnittstelle und die Verbindung mit einer gemeinsamen MEC-Plattform erreicht. Wenn der Nachrichtenbrokerdienst und die Anfrage-MEC-App an unterschiedlichen MEC-Hosts desselben MEC-Systems instanziiert sind, wird Kommunikation mit einer MEC-App in einem anderen MEC-Host (in demselben oder einem anderen MNO) über die Mp3-Schnittstelle (z.B. unter Verwendung einer Verbindung zwischen MEC-Plattformen in unterschiedlichen MEC-Hosts) erreicht. Falls diese unterschiedlichen MEC-Hosts zu unterschiedlichen MEC-Systemen eines MEC-Verbunds gehören, dann sind anstelle von Mp3 MEC-Verbund-Referenzpunkte an dieser Kommunikation beteiligt.
Gemäß einigen Aspekten ist der Nachrichtenbroker eine dienstproduzierende MEC-Anwendung, die entweder an demselben MEC-Host instanziiert ist wie die MEC-App, die ein Abonnement von V2X-Nachrichten anfragt, oder an einem anderen MEC-Host desselben oder eines anderen MEC-Systems. Im Fall unterschiedlicher Lokalität (z.B. unterschiedliche MEC-Hosts) sind die Mp1- und Mp3-/MEC-Verbund-Schnittstellen an der Kommunikation beteiligt. Im Fall der gleichen Lokalität (z.B. der gleiche MEC-Host) ist nur die Mp1-Schnittstelle involviert.
Der MEC-Plattformmanager 906 kann ein MEC-Plattformelementverwaltungsmodul 944, ein MEC-App-Regel-und-Anforderungsverwaltungsmodul 946 und ein MEC-App-Lebenszyklusverwaltungsmodul 948 beinhalten.
Gemäß einigen Aspekten kann das UE 920 dazu konfiguriert sein, über eine oder mehrere der Netzwerk-Slice-Instanzen (NSIs) 980 mit einem oder mehreren der Kernnetze 982 zu kommunizieren. Gemäß einigen Aspekten können die Kernnetze 982 Slice-Verwaltungsfunktionen verwenden, um NSIs 980 dynamisch zu konfigurieren, einschließlich dynamischer Zuweisung eines Slice zu einem UE, Konfigurieren von mit dem Slice assoziierten Netzwerkfunktionen, Konfigurieren einer MEC-App zum Kommunizieren von Daten unter Verwendung des Slice, Neuzuordnen eines Slice zu einem UE, dynamisches Zuweisen oder Neuzuweisen von Ressourcen, die von einem oder mehreren der NSIs 980 verwendet werden, oder anderer Slice-bezogener Verwaltungsfunktionen. Eine oder mehrere der im Zusammenhang mit der Slice-Verwaltung ausgeführten Funktionen können basierend auf Benutzeranfragen (z.B. über ein UE), basierend auf einer Anfrage durch einen Dienstanbieter initiiert werden oder können automatisch in Verbindung mit einem bestehenden Service Level Agreement (SLA), der Slice-bezogene Leistungsfähigkeitsziele spezifiziert, ausgelöst werden.
9B veranschaulicht eine MEC-Referenzarchitektur 900B in einer Netzwerkfunktionsvirtualisierungs- (NFV-) Umgebung gemäß einem Beispiel. Die MEC-Architektur 900B kann dazu ausgelegt sein, Funktionalitäten gemäß einer ETSI-MEC-Spezifikation, wie etwa der ETSI GR MEC 017-Spezifikation, bereitzustellen.
Gemäß einigen Aspekten kann ETSI MEC in einer NFV-Umgebung eingesetzt werden, wie in 9B veranschaulicht, die auch MEC-V2X-API-Interoperabilitätsunterstützung für mehrere V2X-Nachrichtenbroker in einer MEC-Infrastruktur nutzen kann. Gemäß einigen Aspekten wird die MEC-Plattform als eine virtuelle Netzwerkfunktion (VNF) bereitgestellt. Die MEC-Anwendungen können wie VNFs gegenüber den ETSI-NFV-Verwaltungs- und -Orchestrierungs- (Management and Orchestration, MANO-) Komponenten erscheinen (z.B. dem VIM 908, dem MEAO 910 und dem Netzwerkfunktionsvirtualisierungsorchestrator oder NFVO 935). Dies ermöglicht die Wiederverwendung der ETSI-NFV-MANO-Funktionalität. Gemäß einigen Aspekten kann der vollständige Satz der MANO-Funktionalität ungenutzt sein, und es kann bestimmte zusätzliche Funktionalität erforderlich sein. Eine solche spezifische MEC-Anwendung wird mit dem Namen „MEC-App-VNF“ (oder ME-App-VNF) bezeichnet, wie hierin erörtert. Gemäß einigen Aspekten wird die Virtualisierungsinfrastruktur als eine NFVI eingesetzt, und ihre virtualisierten Ressourcen werden vom Virtualisierungsinfrastrukturmanager (VIM) verwaltet. Dazu können eine oder mehrere der durch die ETSI-NFV-Infrastrukturspezifikationen (z. B. ETSI GS NFV-INF 003, ETSI GS NFV-INF 004 und ETSI GS NFV-INF 005) definierten Prozeduren verwendet werden.
Gemäß einigen Aspekten werden die MEC-App-VNFs wie einzelne VNFs verwaltet, was gestattet, dass ein MEC-in-NFV-Einsatz gewisse Orchestrierungs- und Lebenszyklusverwaltungs- (LCM-) Aufgaben an die NFVO- und VNFM-Funktionsblöcke delegieren kann, wie durch ETSI NFV MANO definiert. In einigen Ausführungsformen kann die MEC-App-VNF als ein V2X-Nachrichtenbroker oder als eine V2X-App konfiguriert sein, die V2X-Dienste in einer MEC-Architektur beansprucht (z.B. V2X-Nachrichtensubskriptionsdienste, die durch V2X-Nachrichtenbroker von verschiedenen MNOs bereitgestellt werden).
Gemäß einigen Aspekten kann der Mobil-Edge-Plattformmanager (MEPM) 906 in einen „Mobil-Edge-Plattformmanager - NFV“ (MEPM-V) transformiert werden, der den LCM-Teil an einen oder mehrere VNF- (virtuelle Netzwerkfunktion) Manager (VNFM(s)) delegiert. Der Mobile Edge Orchestrator (MEO), wie in der MEC-Referenzarchitektur ETSI GS MEC-003 definiert, kann in einen „Mobile Edge Application Orchestrator“ (MEAO) 910 transformiert werden, der die NFVO 935 für die Ressourcenorchestrierung und die Orchestrierung der Sätze von MEC-App-VNFs als einen oder mehrere NFV-Netzdienste (NSs) verwendet. In einigen Ausführungsformen können der MEAO 910 und der MEPM 906 dazu konfiguriert sein, Verbundverwaltungsfunktionen durchzuführen, einschließlich Kommunikation zwischen MEC-Systemen in einem Verbund-MEC-Netzwerk.
Gemäß einigen Aspekten können die Mobil-Edge-Plattform-VNF, die MEPM-V und der VNFM (MEC-Plattform-LCM) als einziges Paket gemäß dem Ensemblekonzept in 3GPP TR 32.842 bereitgestellt werden, oder der VNFM ist ein generischer VNFM gemäß ETSI GS NFV-IFA 009, und die Mobil-Edge-Plattform-VNF und die MEPM-V werden von einem einzigen Anbieter bereitgestellt.
Gemäß einigen Aspekten kann der Mp1-Referenzpunkt zwischen einer MEC-Anwendung und der MEC-Plattform für die MEC-Anwendung optional sein, es sei denn, es handelt sich um eine Anwendung, die einen MEC-Dienst bereitstellt und/oder beansprucht. Verschiedene hier diskutierte MEC-bezogene Schnittstellen und Referenzpunkte werden in den folgenden ETSI-bezogenen technischen Spezifikationen näher definiert: Spezifikationen ETSI GS MEC-003 und ETSI GR MEC-024.
Der Mp1-Referenzpunkt ist ein Referenzpunkt zwischen der MEC-Plattform und den MEC-Anwendungen. Der Mp1-Referenzpunkt stellt eine Dienstregistrierung, Dienstauffindung und Kommunikationsunterstützung für Dienste bereit. Er stellt auch andere Funktionalität bereit, wie etwa Anwendungsverfügbarkeit, Sitzungszustandsverlagerungsunterstützungsprozeduren, Verkehrsregeln und DNS-Regelaktivierung, Zugang zu dauerhaftem Speicher und Tageszeitinformationen usw. Dieser Referenzpunkt kann zum Beanspruchen und Bereitstellen von dienstspezifischer Funktionalität verwendet werden.
Der Mp2-Referenzpunkt ist ein Referenzpunkt zwischen der MEC-Plattform und der Datenebene der Virtualisierungsinfrastruktur. Der Mp2-Referenzpunkt wird verwendet, um die Datenebene in Bezug darauf anzuweisen, wie Verkehr zwischen Anwendungen, Netzen, Diensten usw. zu routen ist.
Der Mp3-Referenzpunkt ist ein Referenzpunkt zwischen MEC-Plattformen und wird zur Steuerkommunikation zwischen MEC-Plattformen verwendet.
Gemäß einigen Aspekten basiert der Mm3-Referenzpunkt zwischen dem MEAO 910 und der MEPM-V 906 auf dem Mm3-Referenzpunkt, wie durch ETSI GS MEC 003 definiert. Änderungen können an diesem Referenzpunkt konfiguriert werden, um die Aufteilung zwischen MEPM-V und VNFM (MEC-Anwendungen LCM) zu berücksichtigen.
Gemäß einigen Aspekten werden die folgenden neuen Referenzpunkte (Mv1, Mv2 und Mv3) zwischen Elementen der ETSI-MEC-Architektur und der ETSI-NFV-Architektur eingeführt, um die Verwaltung von MEC-App-VNFs zu unterstützen. Die folgenden Referenzpunkte beziehen sich auf bestehende NFV-Referenzpunkte, jedoch kann nur eine Teilmenge der Funktionalität für ETSI MEC verwendet werden, und es können Erweiterungen erforderlich sein: Mv1 (dieser Referenzpunkt verbindet den MEAO und den NFVO; er bezieht sich auf den Os-Ma-nfvo-Referenzpunkt, wie in ETSI NFV definiert); Mv2 (dieser Referenzpunkt verbindet den VNF-Manager, der den LCM der MEC-App-VNFS durchführt, mit dem MEPM-V, um zu ermöglichen, dass LCM-bezogene Benachrichtigungen zwischen diesen Entitäten ausgetauscht werden; er bezieht sich auf den Ve-Vnfm-em-Referenzpunkt, wie in ETSI NFV definiert, kann aber Hinzufügungen beinhalten, und verwendet möglicherweise nicht die gesamte Funktionalität, die von Ve-Vnfm-em angeboten wird); Mv3 (dieser Referenzpunkt verbindet den VNF-Manager mit der MEC-App-VNF-Instanz, um den Austausch von Nachrichten zu ermöglichen, die z.B. MEC-Anwendungs-LCM oder anfängliche einsatzspezifische Konfiguration betreffen; sie bezieht sich auf den Ve-Vnfm-vnf-Referenzpunkt, wie in ETSI NFV definiert, kann aber Hinzufügungen beinhalten und verwendet möglicherweise nicht die gesamte Funktionalität, die von Ve-Vnfm-vnf angeboten wird).
Gemäß einigen Aspekten werden die folgenden Referenzpunkte verwendet, wie sie durch ETSI NFV definiert sind: Nf-Vn (dieser Referenzpunkt verbindet jede MEC-App-VNF mit der NFVI); Nf-Vi (dieser Referenzpunkt verbindet die NFVI und den VIM); Os-Ma-nfvo (dieser Referenzpunkt verbindet das OSS und den NFVO. Es wird hauptsächlich verwendet, um NSs zu verwalten, d.h. einige VNFs, die verbunden und orchestriert werden, um einen Dienst bereitzustellen); Or-Vnfm (dieser Referenzpunkt verbindet den NFVO und den VNFM; er wird hauptsächlich für den NFVO verwendet, um VNF-LCM-Operationen aufzurufen); Vi-Vnfm (dieser Referenzpunkt verbindet den VIM und den VNFM; er wird hauptsächlich vom VNFM verwendet, um Ressourcenverwaltungsoperationen aufzurufen, um die von der VNF benötigten Cloud-Ressourcen zu verwalten; es wird in einer NFV-basierten MEC-Bereitstellung angenommen, dass dieser Referenzpunkt Mm6 1:1 entspricht); und Or-Vi (dieser Referenzpunkt verbindet den NFVO und den VIM; er wird hauptsächlich von dem NFVO verwendet, um Kapazität von Cloud-Ressourcen zu verwalten).
9C veranschaulicht eine MEC-Architektur 900C, die eine Variante der MEC-Netzwerkarchitektur von 9A ist, die mit dem MEC-Verbund konfiguriert ist, gemäß einer beispielhaften Ausführungsform. Mit Bezug auf 9C sind die MEC-Host-Ebene 960 und die MEC-Systemebenen 962 der MEC-Architektur 900C die gleichen wie die entsprechenden MEC-Host- und Systemebenen der MEC-Architektur 900A in 9A. Die MEC-Architektur 900C beinhaltet ferner eine MEC-Verbundebene 964 mit einem MEC-Verbundmanager 966, der dazu konfiguriert ist, mehrere MEC-Architekturen (oder MEC-Systeme) zu verwalten. In dieser Hinsicht verwaltet der MEC-Verbundmanager 966 in 9C die MEC-Architektur (oder das System) 900C und ein oder mehrere zusätzliche MEC-Systeme 968 (in 9C als „andere MEC-Systeme“ bezeichnet). Das eine oder die mehreren zusätzlichen MEC-Systeme 968 können von dem anderen MEC-Verbundmanager 970 verwaltet werden, der über einen Mff-fed-Referenzpunkt kommunikativ mit dem MEC-Verbundmanager 966 gekoppelt ist. Der MEC-Verbundmanager 966 der MEC-Verbundebene 964 ist ferner kommunikativ über einen Mff-fed-Referenzpunkt mit einem Cloud-System (oder Edge-Cloud) 972 gekoppelt. Der MEC-Verbundmanager 966 und der andere MEC-Verbundmanager 970 können über entsprechende Mfb-fed-Referenzpunkte kommunikativ mit einem MEC-Verbundbroker 974 gekoppelt sein.
10 veranschaulicht die Rolle von Nachrichtenbrokern als Teil einer Kommunikationsumgebung, die mehrere Datenquellen mehrerer Mobilnetzbetreiber (mobile network operators, MNOs) in einer MEC-Infrastruktur 1000 beinhaltet, gemäß einer beispielhaften Ausführungsform. Unter Bezugnahme auf 10 beinhaltet die MEC-Infrastruktur 1000 mehrere MEC-Apps 1006, 1012 in Kommunikation mit entsprechenden Nachrichtenbrokern 1004, 1010. Gemäß einigen Aspekten sind die MEC-Apps 1006 und 1012 unterschiedlichen MNOs zugeordnet und können konfiguriert sein, um dieselben oder unterschiedliche Anwendungsschichtprotokolle zu verwenden.
In beispielhaften Kommunikationsszenarien, wie etwa Kommunikationen im Zusammenhang mit einer intelligenten Stadt (smart city), können mehrere Nachrichtenbroker 1004, 1010 existieren und können konfiguriert sein, um mehrere Anwendungsschichtprotokolle zu unterstützen. In einigen Ausführungsformen wird ein Nachrichtenbroker verwendet, um Daten aus mehreren Datenquellen 1002, 1008 über verschiedene MNOs hinweg in der MEC-Infrastruktur 1000 zu sammeln.
Im Kontext von V2X-Kommunikationen, die durch eine MEC-Infrastruktur unterstützt werden, können die offenbarten Techniken in Verbindung mit einem V2X-Informationsdienst (VIS) und seiner begleitenden MEC-V2X-API verwendet werden, um mehrere Nachrichtenbroker (z.B. wie in 11-13 veranschaulicht) zu unterstützen. Genauer gesagt kann der VIS verwendet werden, um V2X-Nachrichteninteroperabilität über MNO-Bereitstellungen hinweg sicherzustellen, indem mehrere Nachrichtenbroker unterschiedlicher Fähigkeiten unterstützt werden und unterschiedliche Anwendungsschichtprotokolle (und Versionen davon) unterstützt werden, während optimaler Datenverbrauch und minimaler Signalisierungsaufwand sichergestellt werden.
11 veranschaulicht mehrere Nachrichtenbroker und ihre Signalisierungsinteraktionen (direkt oder indirekt) mit einer MEC-Anwendung (App), die V2X-Nachrichten beansprucht, sowie mit einer MEC-Plattform mit einem V2X-Informationsdienst (VIS) gemäß einer beispielhaften Ausführungsform. Unter Bezugnahme auf 11 beinhaltet die MEC-Infrastruktur 1100 einen VIS 1108 (der Teil einer MEC-Plattform sein kann) in Kommunikation mit einer MEC-App 1106 und Nachrichtenbrokern 1102, 1104.
Durch Verwenden der offenbarten Techniken können in Abhängigkeit von den Fähigkeiten der MEC-Anwendung 1106, die V2X-Nachrichten beanspruchen muss, und der verfügbaren Nachrichtenbroker mindestens zwei Kommunikationsszenarien auftreten:

(a) In einigen Ausführungsformen kann eine direkte Verbindung zwischen einem Nachrichtenbroker (z.B. Nachrichtenbroker 1102) und einer MEC-App (z.B. MEC-App 1106) zum Datenverbrauch verwendet werden, wenn sowohl der Nachrichtenbroker als auch die MEC-App dasselbe Anwendungsschichtprotokoll unterstützen (wie z.B. ausführlicher in 12 veranschaulicht).
(b) In anderen Ausführungsformen (z.B. wenn direkte V2X-Nachrichtenbenachrichtigungen zwischen der MEC-App und dem Nachrichtenbroker nicht möglich sind, wie etwa wenn jeweils ein anderes Anwendungsschichtprotokoll verwendet wird) kann auch eine Verbindung zwischen der MEC-App (z.B. MEC-App 1106) und dem Nachrichtenbroker (z.B. Nachrichtenbroker 1104) über die MEC-Plattform (z.B. den VIS 1108 in einer MEC-Plattform) verwendet werden (z.B. wie in 13 veranschaulicht). In diesem Fall agiert der VIS 1108 für jede eingehende V2X-Nachricht als Zwischenentität zwischen dem Dienstkonsumenten (z.B. der MEC-App) und den verfügbaren Nachrichtenbrokern. Gemäß einigen Aspekten werden die V2X-Nachrichten zuerst durch den VIS von den Protokollen, die die Nachrichtenbroker unterstützen, in das Protokoll umgewandelt, das von der subskribierten MEC-App unterstützt wird, und dann an die subskribierte MEC-App weitergeleitet.

Das Ermöglichen von V2X-Nachrichteninteroperabilität unter Verwendung der offenbarten Techniken über MNOs, Automobil-Originalausrüstungshersteller (OEMs) und MEC-Systeme ist von Wert für die Sicherheit von Fahrern, Mitfahrern, Fußgängern und allen Entitäten, die in einer Automobil-/Straßenrand-Umgebung involviert sind. Die offenbarten Techniken können auch zum Verbessern des Fahrerlebnisses und des Komforts auf der Straße verwendet werden.
12 veranschaulicht einen beispielhaften Signalisierungsfluss, der ausgeführt werden kann, wenn mindestens einer der verfügbaren Nachrichtenbroker dasselbe Anwendungsschichtprotokoll (und seine Version) unterstützt wie die MEC-App, die eine Anfrage zum Abonnieren von V2X-Nachrichten sendet, gemäß einer beispielhaften Ausführungsform. Unter Bezugnahme auf 12 beinhaltet die MEC-Infrastruktur 1200 einen VIS 1206 (der als Teil einer MEC-Plattform eines MEC-Hosts ausgeführt wird), eine MEC-App 1204 und einen Nachrichtenbroker 1202. Zusätzlich können die MEC-App 1204 und/oder der Nachrichtenbroker 1202 und/oder der VIS 1206 Teil desselben MEC-Hosts sein oder können jeweils Teil unterschiedlicher MEC-Hosts sein. Des Weiteren können der Nachrichtenbroker 1202 und die MEC-App 1204 demselben MNO zugeordnet sein oder können jeweils unterschiedlichen MNOs zugeordnet sein.
In einer beispielhaften Ausführungsform kann der Nachrichtenbroker 1202 als ein registrierter Dienst in einer MEC-Plattform (z.B. dieselbe MEC-Plattform, die den VIS 1206 enthält, oder eine andere MEC-Plattform in einem anderen MEC-Host) konfiguriert sein. Mit anderen Worten kann der Nachrichtenbroker Teil einer Dienstregistrierungsdatenbank einer MEC-Plattform sein. Kommunikation mit der MEC-App, die eine Subskription für einen V2X-Nachrichtenübermittlungsdienst anfragt, findet über die Mp1-Schnittstelle statt (in Aspekten, bei denen die MEC-App an demselben MEC-Host wie die MEC-Plattform instanziiert ist) und beinhaltet auch die Mp3-Schnittstelle in Aspekten, bei denen der Nachrichtenbrokerdienst und die anfragende MEC-App an unterschiedlichen MEC-Hosts desselben MEC-Systems instanziiert sind. Falls diese unterschiedlichen MEC-Hosts zu unterschiedlichen MEC-Systemen eines MEC-Verbunds gehören, dann sind anstelle von Mp3 MEC-Verbund-Referenzpunkte an dieser Kommunikation beteiligt.
In einer beispielhaften Ausführungsform kann der Nachrichtenbroker 1202 als eine dienstproduzierende MEC-App konfiguriert sein, die entweder an demselben MEC-Host instanziiert ist wie die MEC-App, die eine Subskription für V2X-Nachrichten anfragt, oder an einem anderen MEC-Host desselben oder eines anderen MEC-Systems. Im Fall unterschiedlicher Lokalität (MEC-Host) sind die Mp1- und Mp3-/MEC-Verbund-Schnittstellen an der Kommunikation beteiligt. Bei Aspekten, bei denen derselbe MEC-Host involviert ist, wird primär die Mp1-Schnittstelle verwendet.
Beim Kommunikationsaustausch in 12 ist die MEC-App 1204 mit einem Anwendungsschichtprotokoll konfiguriert (z.B. bevor sie einen V2X-Nachrichtenübermittlungsdienst abonniert, um V2X-Nachrichten über einen Nachrichtenbroker zu empfangen oder zu senden), um in der Lage zu sein, direkte V2X-Nachrichtenbenachrichtigungen von einem (oder mehreren) der verfügbaren Nachrichtenbroker, die dasselbe Protokoll (und seine Version) unterstützen, zu empfangen. Infolgedessen sind direkte V2X-Nachrichtenbenachrichtigungen möglich, nachdem der Dienstkonsument (z.B. die MEC-App 1204) mit dem Nachrichtenbroker assoziiert ist, der dasselbe Protokoll unterstützt (z.B. dem Nachrichtenbroker 1202). Gemäß einigen Aspekten können die folgenden Operationen durchgeführt werden, wie mit entsprechenden Bezugsziffern in 12 veranschaulicht.
Bei Operation 1208 sendet der VIS-Dienst/ V2X-Nachrichtenkonsument (z.B. MEC-App 1204) eine Subskriptionsanfrage über die MEC-API 1207 an den VIS 1206. Die MEC-V2X-API 1207 kann eine V2X-Informationsdienst-API sein, die Funktionalitäten ausführt, die in der Spezifikation ETSI GS MEC 030 (z.B. v2.1.1, April 2020) umrissen sind. Gemäß einigen Aspekten enthält die Anfrage ein oder mehrere Filterkriterien, wie etwa ein oder mehrere Anwendungsschichtprotokolle (und ihre Versionen), die von der MEC-App 1204 unterstützt werden.
Bei Operation 1210 kündigt der VIS 1206 unter der Annahme, dass sich mehrere Nachrichtenbroker bei der MEC-Plattform, die den VIS 1206 hostet, als dienstbeanspruchende MEC-Apps registriert haben (z.B. einen „V2X-Nachrichten“-Dienst anbieten), die Subskriptionsanfrage der MEC-App 1204 allen verfügbaren Nachrichtenbrokern (die mit demselben oder anderen MNOs assoziiert sind) unter Verwendung der MEC-V2X-API 1207 an.
Bei Operation 1212 bestätigt der Nachrichtenbroker (z.B. der Nachrichtenbroker 1202), der alle Filterkriterien erfüllt, die durch den V2X-Nachrichtenkonsument (z.B. die MEC-App 1204) in seiner Subskriptionsanfrage angegeben werden, die Subskriptionsanfrage dem VIS 1206 über die MEC-V2X-API 1207.
Bei Operation 1214 meldet der VIS 1206 dem VIS-Dienst/V2X-Nachrichtenkonsumenten (z.B. der MEC-App 1204) über die MEC-V2X-API 1207 die erfolgreiche Erzeugung der Subskription an.
Bei Operation 1216 werden V2X-Nachrichtenbenachrichtigungen direkt durch den Nachrichtenbroker 1202 an den V2X-Nachrichtenkonsument (z.B. die MEC-App 1204) geliefert.
13 veranschaulicht einen beispielhaften Signalisierungsfluss, der ausgeführt werden kann, wenn keiner der verfügbaren Nachrichtenbroker dasselbe Anwendungsschichtprotokoll (und seine Version) unterstützt wie die MEC-App, die eine Anfrage zum Abonnieren von V2X-Nachrichten sendet, gemäß einer beispielhaften Ausführungsform. Unter Bezugnahme auf 13 beinhaltet die MEC-Infrastruktur 1300 einen VIS 1306 (der als Teil einer MEC-Plattform eines MEC-Hosts ausgeführt wird), eine MEC-App 1304 und einen Nachrichtenbroker 1302. Zusätzlich können die MEC-App 1304 und/oder der Nachrichtenbroker 1302 und/oder der VIS 1306 Teil desselben MEC-Hosts sein oder können jeweils Teil unterschiedlicher MEC-Hosts sein. Des Weiteren können der Nachrichtenbroker 1302 und die MEC-App 1304 demselben MNO zugeordnet sein oder können jeweils unterschiedlichen MNOs zugeordnet sein.
In einer beispielhaften Ausführungsform kann der Nachrichtenbroker 1302 als ein registrierter Dienst in einer MEC-Plattform (z.B. dieselbe MEC-Plattform, die den VIS 1306 enthält, oder eine andere MEC-Plattform in einem anderen MEC-Host) konfiguriert sein. Mit anderen Worten kann der Nachrichtenbroker Teil einer Dienstregistrierungsdatenbank einer MEC-Plattform sein. Kommunikation mit der MEC-App, die eine Subskription für einen V2X-Nachrichtenübermittlungsdienst anfragt, findet über die Mp1-Schnittstelle statt (in Aspekten, bei denen die MEC-App an demselben MEC-Host wie die MEC-Plattform instanziiert ist) und beinhaltet auch die Mp3-Schnittstelle in Aspekten, bei denen der Nachrichtenbrokerdienst und die anfragende MEC-App an unterschiedlichen MEC-Hosts desselben MEC-Systems instanziiert sind. Falls diese unterschiedlichen MEC-Hosts zu unterschiedlichen MEC-Systemen eines MEC-Verbunds gehören, dann sind anstelle von Mp3 MEC-Verbund-Referenzpunkte an dieser Kommunikation beteiligt.
In einer beispielhaften Ausführungsform kann der Nachrichtenbroker 1302 als eine dienstproduzierende MEC-App konfiguriert sein, die entweder an demselben MEC-Host instanziiert ist wie die MEC-App 1304, die eine Subskription für V2X-Nachrichten anfragt, oder an einem anderen MEC-Host desselben oder eines anderen MEC-Systems. Im Fall unterschiedlicher Lokalität (MEC-Host) sind die Mp1- und Mp3-/MEC-Verbund-Schnittstellen an der Kommunikation beteiligt. Bei Aspekten, bei denen derselbe MEC-Host involviert ist, wird primär die Mp1-Schnittstelle verwendet.
Beim Kommunikationsaustausch in 13 hat die MEC-App 1304 zuvor keines der Protokolle eingebettet, die von den aktuell verfügbaren Nachrichtenbrokern unterstützt werden, und die benötigt werden, um direkte V2X-Nachrichtenbenachrichtigungen von diesen Nachrichtenbrokern zu empfangen. Folglich sind direkte V2X-Nachrichtenbenachrichtigungen zwischen dem Nachrichtenbroker und der MEC-App unmöglich. Bei diesem Aspekt kann der VIS 1306 für jede eingehende V2X-Nachricht als eine Zwischenentität zwischen dem Dienstkonsumenten (z.B. der MEC-App 1304) und den verfügbaren Nachrichtenbrokern (z.B. dem Nachrichtenbroker 1302) fungieren. V2X-Nachrichten werden vom VIS 1306 zuerst von dem einen oder den mehreren Protokollen, die die Nachrichtenbroker unterstützen, in das von der subskribierten MEC-App unterstützte Protokoll konvertiert und dann an die subskribierte MEC-App weitergeleitet. Gemäß einigen Aspekten können die folgenden Operationen durchgeführt werden, wie mit entsprechenden Bezugsziffern in 13 veranschaulicht.
Bei Operation 1310 sendet der VIS-Dienst/ V2X-Nachrichtenkonsument (z.B. MEC-App 1304) eine Subskriptionsanfrage über die MEC-API 1308 an den VIS 1306. Die Anfrage kann Filterkriterien, wie etwa ein oder mehrere Anwendungsschichtprotokolle (und ihre Versionen), die von der MEC-App 1304 unterstützt werden, beinhalten.
Bei Operation 1312 kündigt der VIS 1306 die empfangene Subskriptionsanfrage allen verfügbaren Nachrichtenbrokern (z.B. instanziiert als dienstproduzierende MEC-Apps, auch registriert bei der MEC-Plattform, die mit dem VIS 1306 assoziiert ist) über die MEC-V2X-API 1308 an.
Bei Operation 1314 bestätigt kein Nachrichtenbroker die Erfüllung aller Filterkriterien der Subskriptionsanfrage innerhalb eines vordefinierten Zeitintervalls. Der VIS 1306 sendet die Subskriptionsanfrage ohne das Filterkriterium des unterstützten Protokolls erneut. Ein oder mehrere Nachrichtenbroker (z.B. der Nachrichtenbroker 1302) bestätigen dem VIS 1306 die Subskriptionsanfrage über die MEC-V2X-API 1308.
Bei Operation 1316 meldet der VIS 1306 dem VIS-Dienst/V2X-Nachrichtenkonsumenten (z.B. der MEC-App 1304) über die MEC-V2X-API 1308 eine erfolgreiche Subskription.
Bei Operation 1318 werden V2X-Nachrichtenbenachrichtigungen an den VIS 1306 für die benötigte Protokollkonvertierung gesendet.
Bei Operation 1320 findet eine Protokollkonvertierung innerhalb des VIS 1306 statt.
Bei Operation 1322 erfolgt eine Nachrichtenbenachrichtigung. Genauer gesagt wird die konvertierte V2X-Nachricht über die MEC-V2X-API 1308 unter Verwendung ihres erfassten Protokolls an den VIS-Dienst/ V2X-Nachrichtenkonsumenten (z.B. die MEC-App 1304) gesendet.
In einigen Ausführungsformen kann der VIS (z.B. der VIS 1108, der VIS 1206 und der VIS 1306) in einem Rechenknoten konfiguriert sein, der als eine Straßenrandeinheit (RSU) implementiert ist. Die MEC-App (z.B. die MEC-App 1106, die MEC-App 1204 und die MEC-App 1304) kann als eine Benutzergerät- (UE-) Anwendung konfiguriert sein, die an einem mobilen Rechenknoten (z.B. V2X-fähiges sich bewegendes Fahrzeug oder einem anderen Typ von mobiler Rechenvorrichtung) ausgeführt wird. Gleichermaßen können die offenbarten Nachrichtenbroker auch MEC-Apps sein, die auf einem MEC-Host ausgeführt werden, der entweder als ein stationärer Knoten (z.B. eine RSU) oder als ein mobiler Knoten (z.B. ein sich bewegendes Fahrzeug oder eine andere Art von sich bewegender Rechenvorrichtung) konfiguriert ist.
14 veranschaulicht ein Flussdiagramm eines Verfahrens 1400 zum Durchführen einer VIS-Konfiguration in einem MEC-Netzwerk gemäß einer beispielhaften Ausführungsform. Das Verfahren 1400 kann Operationen 1402, 1404, 1406 und 1408 beinhalten, die durch einen Rechenknoten durchgeführt werden, der mit VIS (z.B. dem VIS 1108 oder dem VIS 1206) konfiguriert ist.
Bei Operation 1402 wird eine Subskriptionsanfrage an einen Informationsdienst erkannt (z.B. als Ergebnis der Operation 1208). Die Subskriptionsanfrage stammt von einer MEC-Anwendung (z.B. der MEC-App 1204), die auf einem MEC-Host des MEC-Netzwerks instanziiert ist. Die Subskriptionsanfrage beinhaltet mindestens ein Filterkriterium, das eine Informationsverarbeitungskonfiguration der MEC-Anwendung angibt. Die Filteranfrage beinhaltet zum Beispiel ein oder mehrere Anwendungsschichtprotokolle und Protokollversion(en), die von der MEC-App 1204 unterstützt werden.
In einigen Ausführungsformen kann das mindestens eine Filterkriterium in der Subskriptionsanfrage eine Beschreibung oder Konfiguration des Typs von Informationen eines Nachrichtenbrokers (oder Informationsdienstanbieters), der durch die MEC-App (oder den Informationsdienstkonsumenten) unterstützt wird, zur Inanspruchnahme/zur Verwendung beinhalten. In einigen Ausführungsformen beinhaltet das mindestens eine Filterkriterium in der Subskriptionsanfrage Standortinformationen der MEC-App (z.B. aktuelle oder zukünftige Standortinformationen eines stationären oder mobilen Rechenknotens, der als MEC-Host konfiguriert ist, der die MEC-App ausführt, die die Subskriptionsanfrage sendet). In einigen Ausführungsformen beinhaltet das mindestens eine Filterkriterium in der Subskriptionsanfrage eine Angabe eines oder mehrerer Kommunikationsprotokolle, die von der MEC-App verwendet werden können, einen Nachrichtentyp (z.B. eine Nachricht, die einem spezifischen Telekommunikationsstandard zugeordnet ist), der von der MEC-App beansprucht werden kann, und kompatible Protokolle, die zum Konsumieren/Lesen/Zugreifen auf die Nachricht verwendet werden können, einschließlich der Protokollversion der Informationsdienstnachricht (z.B. V2X-Nachricht), die die MEC-App empfangen/konsumieren/abrufen oder anderweitig verarbeiten kann.
Gemäß einigen Aspekten können Kommunikationen (z.B. Informationsdienstnachrichten oder andere Arten von Nachrichten), die von den Nachrichtenbrokern an den VIS zur Veröffentlichung/Kommunikation an Nachrichtenkonsumenten (z.B. MEC-Apps) gesendet werden, Informationen beinhalten, die Nachrichteneigenschaften der in der Nachricht enthaltenen Informationen (z.B. Darstellungsformat, kompatible Protokolle, die zum Konsumieren/Lesen/Zugreifen auf die Nachricht verwendet werden können, einschließlich Protokollversion, Anwendungsschichtprotokoll, das zum Erzeugen der Nachricht verwendet wird, anwendbarer Kommunikationsstandard, Geostandortinformationen eines Rechenknotens, der den Nachrichtenbroker implementiert, usw.) sowie Nachrichteninhalt/-daten angeben.
Bei Operation 1404 wird die Subskriptionsanfrage mit dem mindestens einen Filterkriterium an mehrere Anbieter des Informationsdienstes innerhalb des MEC-Netzwerks weitergeleitet (z.B. Weiterleiten oder Ankündigen der Subskriptionsanfrage an den Nachrichtenbroker 1202 bei Operation 1210).
Bei Operation 1406 wird eine Antwortnachricht, die (z.B. bei Operation 1212) von mindestens einem Anbieter (z.B. dem Nachrichtenbroker 1202) der mehreren Anbieter empfangen wird, decodiert. Die Antwortnachricht gibt eine Annahme der Subskriptionsanfrage durch den mindestens einen Anbieter an.
Bei Operation 1408 wird eine Bestätigungsnachricht zur Übertragung an die MEC-Anwendung über die Netzwerkschnittstellenschaltungsanordnung codiert (z.B. bei Operation 1214). Die Bestätigungsnachricht gibt die Annahme der Subskriptionsanfrage durch den mindestens einen Anbieter an.
Betroffene Datentypen
In beiden Kommunikationsszenarien, die in 12 und 13 veranschaulicht sind, besteht die erste Operation (zwischen der MEC-App und dem VIS in der MEC-Plattform) im Abonnieren von V2X-Nachrichten (i) einer spezifischen Standardisierungsorganisation (z.B. ETSI-ITS-Nachrichten) und (ii) eines spezifischen Nachrichtentyps (z.B. Cooperative Awareness Message oder CAM, Decentralized Environmental Notification Message oder DENM usw.). Solche V2X-Nachrichten können durch Nachrichtenbroker unter Verwendung eines Anwendungsschichtprotokolls bereitgestellt werden, das für die MEC-App verständlich ist. Im Fall einer Nichtverfügbarkeit der vorstehend bevorzugten Nachrichtenbroker gemäß den Filterkriterien der Subskriptionsanfrage oder um den vollen V2X-Nachrichten-Footprint über einen Betreiberübergreifenden Bereich hinweg auszunutzen, der Nachrichtenbroker unterschiedlicher Fähigkeit und unterstützter Protokolle beinhaltet, kann der VIS verwendet werden, um V2X-Nachrichten, die einem Anwendungsschichtprotokoll folgen, das von dem VIS-Konsumenten (z.B. der MEC-App) nicht unterstützt wird, in Nachrichten zu konvertieren, die einem Anwendungsschichtprotokoll folgen, das vom VIS- (V2X-Nachrichten-) Konsumenten unterstützt wird.

In einigen Ausführungsformen kann der V2xMsgSubscription-Datentyp (in Tabelle 1 unten veranschaulicht und in ETSI GS MEC 030, v2.1.1 spezifiziert) hinsichtlich Filterkriterien, die an der Subskriptionsanfrage beteiligt sind, mit weiteren Attributen (z.B. infoProtocol, msgProtocol und protImplementation) verbessert werden, wie durch den fett gedruckten Text in Tabelle 1 unten angegeben. TABELLE 1 (V2XMsgSubscription-Datentyp)

Attributbezeichnung	Datentyp	Kardinalität	Beschreibung
subscriptionType	Zeichenkette	1	Soll auf „V2xMsgSubscription“ gesetzt werden.
callbackReference	URI	1	URI, der durch den Dienstkonsumenten ausgewählt wird, um Benachrichtigungen über die subskribierte V2X-Nachricht zu empfangen. Soll sowohl in der Anfrage als auch in der Antwort enthalten sein.
_links	Struktur (inline)	0..1	Hyperlink in Bezug auf die Ressource. Soll nur in die HTTP-Antworten und in HTTP-PUT-Anfragen einbezogen werden.
>self	LinkType	1	Auf sich selbst Bezug nehmende URI. Die URI soll innerhalb der VIS-API eindeutig sein, da sie als ID für die Subskription agiert.
filterCriteria	Struktur (inline)	1	Liste von Filterkriterien für die Subskription. Jegliche Filterkriterien von unten, die in der Anfrage enthalten sind, sollen auch in der Antwort enthalten sein.
>stdOrganization	Enum	1	Standardisierungsorganisation, die den subskribierten V2X-Nachrichtentyp definiert:
			• ETSI: European Telecommunications Standards Institute.
			Siehe Anmerkung 1.
>msgType	Enum	0..N	Subskribierter V2X-Nachrichtentyp. Sein Wert wird durch die durch das Attribut stdOrganization angegebene Standardisierungsorganisation definiert. Siehe Anmerkung 2.
>infoProtocol	Struktur (inline)	1	Spezifika des Anwendungsschichtprotokolls, das vom Dienstkonsumenten unterstützt wird.
>>msgProtocol	Enum	1.N	Numerischer Wert, der dem Anwendungsschichtprotokoll entspricht, das von dem Dienstkonsumenten unterstützt wird. Für msgProtocol werden gegenwärtig die folgenden Werte definiert (siehe Anmerkung 3):

			0 = MQTT v3.1.0
			1 = MQTT v3.1.1
			2 = MQTT v5
			3 = MQTT-SN
			4 = AMQP 1.0
>>protImplementation	Zeichenkette	1	Implementierungsspezifika des Anwendungsschichtprotokolls, z.B. Programmiersprache.
expiryDeadline	TimeStamp	0..1	Zeitstempel.
ANMERKUNG 1: Andere Standardisierungsorganisationen könnten je nach Bedarf
	hinzugefü gt werden.
ANMERKUNG 2: Die V2X-Nachrichtentypen von ETSI sollen wie in ETSI TS 102 894-2
	[6], Klaus el A.114 spezifiziert verwendet werden.
ANMERKUNG 3: Andere Anwendungstransportprotokolle (und Versionen davon) könnten
	nach Beda rf hinzugefügt werden.

Genauer gesagt beinhalten die Filterkriterien, die in der V2X-Subskriptionsanfrage (z.B. V2XMsgSubscription in Tabelle 1) spezifiziert sind, das Anwendungsschichtprotokoll, das durch den Dienstkonsumenten (z.B. die MEC-App) unterstützt wird, wie durch das msgProtocol-Feld angegeben. Beispielhafte Werte des Felds sind in Tabelle 1 angegeben und können bei einigen Aspekten von 0-4 variieren, was einer anderen Version des MQTT-(Message Queuing Telemetry Transport) Protokolls und des AMQP (Advanced Message Queuing Protocol) entspricht. Andere Feldwerte, die anderen Protokollen entsprechen, können ebenfalls verwendet werden.

Wenn ferner eine V2X-Nachricht über den V2XMsgPublication-Datentyp veröffentlicht wird (z.B. durch eine MEC-App an einen Nachrichtenbroker oder den VIS in der MEC-Plattform), muss neben dem V2X-Nachrichtentyp und Codierungsformat auch das verwendete Anwendungsschichtprotokoll angegeben werden, damit der VIS entweder die V2X-Nachricht zu dem verfügbaren (und erreichbaren) Nachrichtenbroker umleitet, der dasselbe Anwendungsschichtprotokoll (und seine gleiche Version) unterstützt, oder damit der VIS eine Protokollkonvertierung durchführt, bevor er die veröffentlichte V2X-Nachricht zu einem Nachrichtenbroker umleitet, der das Anwendungsschichtprotokoll, das durch die veröffentlichte V2X-Nachricht angegeben wird, nicht unterstützt. Infolgedessen kann der V2xMsgPublication-Datentyp (z.B. in Tabelle 2 unten veranschaulicht und in ETSI GS MEC 030, v2.1.1 spezifiziert) mit weiteren Attributen (z.B. msgProtocol und protImplementation) verbessert werden, wie durch den fett gedruckten Text in Tabelle 2 unten angegeben. TABELLE 2 (V2XMsgPublication-Datentyp)

Attributbezeichnung	Datentyp	Kardinalität	Beschreibung
stdOrganization	Enum	1	Standardisierungsorganisation, die den veröffentlichten V2X-Nachrichtentyp definiert:
			• ETSI: European Telecommunications Standards Institute.
			Siehe Anmerkung 1.
msgType	Enum	1	Veröffentlichter V2X-Nachrichtentyp. Sein Wert wird durch die durch das Attribut stdOrganization angegebene Standardisierungsorganisation definiert. Siehe Anmerkung 2.
msgEncodeFormat	Zeichenkette	1	Das Codierungsformat der V2X-Nachricht, zum Beispiel base64.
msgContent	Zeichenkette	1	Veröffentlichter V2X-Nachrichteninhalt. Sein Format wird durch die durch das Attribut stdOrganization angegebene Standardisierungsorganisation definiert.
msgProtocol	Enum	1	Numerischer Wert, der dem Anwendungsschichtprotokoll entspricht, das von dem Dienstkonsumenten unterstützt wird. Für msgProtocol werden gegenwärtig die folgenden Werte definiert (siehe Anmerkung 3):

			0 = MQTT v3.1.0
			1 = MQTT v3.1.1
			2 = MQTT v5
			3 = MQTT-SN
			4 = AMQP 1.0
protImplementation	Zeichenkette	1	Implementierungsspezifika des Anwendungsschichtprotokolls, z.B. Programmiersprache.
ANMERKUNG 1: Andere Standardisierungsorganisationen könnten je nach Bedarf hinzugefügt werden.
ANMERKUNG 2: Die V2X-Nachrichtentypen von ETSI sollen wie in ETSI TS 102 894-2 [6], Klausel A.114 spezifiziert verwendet werden.
ANMERKUNG 3: Andere Anwendungstransportprotokolle (und Versionen davon) könnten nach Bedarf hinzugefügt werden.

Ähnlich der Tabelle 1 beinhalten die Filterkriterien, die in der V2X-Nachrichtenveröffentlichungsanfrage (z.B. V2XMsgPublication in Tabelle 2) spezifiziert sind, das Anwendungsschichtprotokoll, das durch den Dienstkonsumenten (z.B. die MEC-App) unterstützt und für die Nachrichtenveröffentlichung verwendet wird, wie durch das msgProtocol-Feld angegeben. Beispielhafte Werte des Felds sind in Tabelle 1 angegeben und können bei einigen Aspekten von 0-4 variieren, was einer anderen Version des MQTT-(Message Queuing Telemetry Transport) Protokolls und des AMQP (Advanced Message Queuing Protocol) entspricht. Andere Feldwerte, die anderen Protokollen entsprechen, können ebenfalls verwendet werden.
Subskription von V2X-Nachrichtenkonsumenten bei Nachrichtenbrokern
Gemäß einigen Aspekten kann als Voraussetzung angenommen werden, dass ein Nachrichtenbroker eine dienstproduzierende MEC-App ist. Dieser Dienst kann bei der MEC-Plattform als ein Erzeuger von V2X-Nachrichten registriert sein. Für beide Kommunikationsszenarien von 12 (z.B. Operation 1208) und 13 (z.B. Operation 1310) gilt, dass, sobald die MEC-App (z.B. ein VIS-Konsument) eine Subskription für V2X-Nachrichten in Betracht zieht, die Aufgabe des VIS darin besteht, diese (zusammen mit anderen) eingehenden Subskriptionsanfragen den verfügbaren Nachrichtenbrokern anzukündigen. Eine solche Ankündigung, möglicherweise um Standortinformationen der Fahrzeuge erweitert, wird dann durch den VIS (basierend auf Rückmeldung/Bestätigung der Nachrichtenbroker) verwendet, um die anfragende VIS-Konsumenten-MEC-App dem besten Nachrichtenbroker (in Bezug auf z.B. unterstütztes Anwendungsschichtprotokoll, Latenz, Lastausgleich usw.) zuzuordnen. Gemäß einigen Aspekten gilt diese Prozedur für die Spezifikation ETSI GS MEC 030 (v2.1.1) oder als eine generische Prozedur in GS MEC 011 (v2.2.1). Gemäß einigen Aspekten kann die obige Voraussetzung beliebigen existierenden Vorgehensweisen für „MEC-Dienst-produzierende MEC-Anwendungen“ folgen, wie in GS MEC 011 spezifiziert.
Es versteht sich, dass die vorliegenden Techniken, die mit MEC-V2X-API-Interoperabilitätsunterstützung für mehrere V2X-Nachrichtenbroker zusammenhängen, mit vielen Aspekten von Edge-Computing-Strategien und -Bereitstellungen integriert werden können, einschließlich Edge-Netzwerken, die in Verbindung mit 1-8C veranschaulicht und erörtert werden. Edge Computing bezieht sich auf allgemeiner Ebene auf den Übergang von Rechen- und Speicherressourcen näher zu Endpunktvorrichtungen (z. B. Verbraucher-Rechenvorrichtungen, Benutzergeräten usw.), um Gesamtbetriebskosten zu optimieren, Anwendungslatenz zu reduzieren, Dienstfähigkeiten zu verbessern und die Einhaltung von Sicherheits- oder Datenschutzanforderungen zu verbessern. Edge-Computing kann in manchen Szenarien einen Cloud-artigen verteilten Dienst bereitstellen, der Orchestrierung und Verwaltung für Anwendungen zwischen vielen Arten von Speicherungs- und Rechenressourcen bietet. Infolgedessen wurden manche Implementierungen von Edge Computing als „Edge-Cloud“ (Rand-Cloud) oder „Fog“ (Nebel) bezeichnet, da leistungsstarke Rechenressourcen, die zuvor nur in großen entfernten Datenzentren verfügbar waren, näher an Endpunkte verlagert und zur Verwendung durch Verbraucher am „Rand“ des Netzwerks verfügbar gemacht werden.
Im Kontext von Satellitenkommunikationsnetzwerken können Edge-Computing-Operationen stattfinden, wie oben erörtert, indem Arbeitslasten auf Rechengeräte an Satellitenfahrzeugen bewegt werden; Satellitenverbindungen verwendet werden, um Backup- oder (redundante) Links und Verbindungen zu Diensten mit niedrigerer Latenz anzubieten; Arbeitslastverarbeitungsoperationen an terrestrischen Zugangspunkten oder Basisstationen zu koordinieren; Daten und Inhalt über Satellitennetzwerke bereitzustellen; und dergleichen. Somit sind viele der gleichen Edge-Computing-Szenarien, die unten für Mobilnetzwerke und Mobilclientvorrichtungen beschrieben sind, gleichermaßen anwendbar, wenn ein nichtterrestrisches Netzwerk verwendet wird.
Es versteht sich, dass die in dieser Spezifikation beschriebenen Funktionseinheiten oder Fähigkeiten als Komponenten, Schaltungen oder Module bezeichnet oder beschriftet worden sein können, um insbesondere ihre Implementierungsunabhängigkeit hervorzuheben. Solche Komponenten können durch eine beliebige Anzahl von Software- oder Hardwareformen realisiert sein. Zum Beispiel kann eine Komponente oder ein Modul als eine Hardwareschaltung umgesetzt sein, die angepasste VLSI-Schaltungen (Very-Large-Scale-Integration - VLSI) oder Gate-Arrays, handelsübliche Halbleiter, wie etwa Logikchips, Transistoren oder andere diskrete Komponenten, umfasst. Eine Komponente oder ein Modul kann auch in programmierbaren Hardwarevorrichtungen implementiert sein, wie etwa Field Programmable Gate Arrays, Programmable Array Logic, programmierbaren Logikvorrichtungen oder dergleichen. Die Komponenten oder Module können auch in Software zur Ausführung durch verschiedene Arten von Prozessoren implementiert sein. Eine identifizierte Komponente oder ein identifiziertes Modul von ausführbaren Codes kann beispielsweise einen oder mehrere physische oder logische Blöcke von Computeranweisungen umfassen, die beispielsweise als ein Objekt, eine Prozedur oder eine Funktion organisiert sein können. Dennoch müssen die ausführbaren Dateien einer identifizierten Komponente oder eines identifizierten Moduls nicht physisch zusammen angeordnet sein, sondern können grundverschiedene Anweisungen umfassen, die an verschiedenen Orten gespeichert sind, die, wenn sie logisch miteinander verbunden sind, die Komponente oder das Modul umfassen und den angegebenen Zweck für die Komponente oder das Modul erreichen.
Tatsächlich kann eine Komponente oder ein Modul mit ausführbarem Code eine einzige Anweisung oder viele Anweisungen sein und kann sogar über mehrere verschiedene Codesegmente, unter verschiedenen Programmen und über mehrere Arbeitsspeichereinrichtungen oder Verarbeitungssysteme hinweg verteilt sein. Insbesondere können einige Aspekte des beschriebenen Prozesses (wie etwa ein Codeumschreiben und eine Codeanalyse) auf einem anderen Verarbeitungssystem (z. B. in einem Computer in einem Rechenzentrum) als dem stattfinden, in dem der Code eingesetzt wird (z. B. in einem Computer, der in einen Sensor oder Roboter eingebettet ist). Gleichermaßen können Betriebsdaten vorliegend innerhalb von Komponenten oder Modulen identifiziert und veranschaulicht werden und können in einer beliebigen geeigneten Form umgesetzt und innerhalb einer beliebigen geeigneten Art von Datenstruktur organisiert sein. Die Betriebsdaten können als ein einziger Datensatz erfasst werden oder können über verschiedene Orte, einschließlich über verschiedene Speicherungsvorrichtungen, verteilt werden und können zumindest teilweise lediglich als elektronische Signale in einem System oder Netzwerk existieren. Die Komponenten oder Module können passiv oder aktiv sein und Agenten umfassen, die betrieben werden können, um gewünschte Funktionen auszuführen.
Zusätzliche Beispiele der vorliegend beschriebenen Verfahrens-, System- und Vorrichtungsausführungsformen beinhalten die folgenden, nicht einschränkenden Implementierungen. Jedes der folgenden nicht einschränkenden Beispiele kann alleine stehen oder kann in einer beliebigen Permutation oder Kombination mit einem oder mehreren der anderen unten oder in der gesamten vorliegenden Offenbarung bereitgestellten Beispiele kombiniert werden.
Beispiel 1 ist ein Rechenknoten zum Implementieren eines Fahrzeug-zu-Alles-(V2X-) Informationsdienstes (VIS) in einem Mehrfachzugriff-Edge-Computing- (MEC-) Netzwerk, wobei der Rechenknoten Folgendes umfasst: eine Netzwerkschnittstellenschaltungsanordnung; und eine Verarbeitungsschaltungsanordnung, die mit der Netzwerkschnittstellenschaltungsanordnung gekoppelt ist, wobei die Verarbeitungsschaltungsanordnung konfiguriert ist zum: Erkennen einer Subskriptionsanfrage an einen Informationsdienst, wobei die Subskriptionsanfrage von einer MEC-Anwendung stammt, die auf einem MEC-Host des MEC-Netzwerks instanziiert ist, und die Subskriptionsanfrage mindestens ein Filterkriterium beinhaltet, das eine Informationsverarbeitungskonfiguration der MEC-Anwendung angibt; über die Netzwerkschnittstellenschaltungsanordnung erfolgendes Weiterleiten der Subskriptionsanfrage mit dem mindestens einen Filterkriterium an eine Vielzahl von Rechenressourcen, wobei die Vielzahl von Rechenressourcen als entsprechende Vielzahl von Anbietern des Informationsdienstes innerhalb des MEC-Netzwerks konfiguriert ist; Decodieren einer Antwortnachricht, die von mindestens einem Anbieter der Vielzahl von Anbietern empfangen wird, wobei die Antwortnachricht eine Annahme der Subskriptionsanfrage durch den mindestens einen Anbieter angibt; und Codieren einer Bestätigungsnachricht zur Übertragung an die MEC-Anwendung über die Netzwerkschnittstellenschaltungsanordnung, wobei die Bestätigungsnachricht die Annahme der Subskriptionsanfrage durch den mindestens einen Anbieter angibt.
In Beispiel 2 beinhaltet der Gegenstand des Beispiels 1 einen Gegenstand, wonach die Verarbeitungsschaltungsanordnung ferner dazu konfiguriert ist, eine Registrierungsanfrage von jedem Anbieter der Vielzahl von Anbietern zu decodieren, wobei die Registrierungsanfrage angibt, dass der Anbieter einen V2X-Nachrichtendienst innerhalb des MEC-Netzwerks anbietet.
In Beispiel 3 beinhaltet der Gegenstand des Beispiels 2 einen Gegenstand, wonach der MEC-Host eine Mobilvorrichtung ist und wobei die Vielzahl von Anbietern als entsprechende Vielzahl von MEC-Anwendungen auf zumindest einem zweiten MEC-Host des MEC-Netzwerks instanziiert sind.
In Beispiel 4 beinhaltet der Gegenstand des Beispiels 3 einen Gegenstand, wonach die Verarbeitungsschaltungsanordnung ferner dazu konfiguriert ist, die Vielzahl von MEC-Anwendungen als dienstproduzierende MEC-Anwendungen zu registrieren, die den V2X-Nachrichtendienst innerhalb des MEC-Netzwerks konfigurieren.
In Beispiel 5 beinhaltet der Gegenstand der Beispiele 1-4 einen Gegenstand, wonach einer oder mehrere der Vielzahl von Anbietern als dienstproduzierende Anwendung konfiguriert sind, die auf dem MEC-Host instanziiert ist.
In Beispiel 6 beinhaltet der Gegenstand der Beispiele 1-5 einen Gegenstand, wonach die Subskriptionsanfrage von einer MEC-V2X-Anwendungsprogrammierschnittstelle (API) des VIS empfangen wird, wobei die MEC-V2X-API an dem MEC-Host konfiguriert ist.
In Beispiel 7 beinhaltet der Gegenstand der Beispiele 1-6 einen Gegenstand, wonach die Antwortnachricht ferner Kompatibilität einer Informationsverarbeitungskonfiguration des mindestens einen Anbieters mit der Informationsverarbeitungskonfiguration der MEC-Anwendung angibt.
In Beispiel 8 beinhaltet der Gegenstand des Beispiels 7 einen Gegenstand, wonach die Informationsverarbeitungskonfiguration des mindestens einen Anbieters und die Informationsverarbeitungskonfiguration der MEC-Anwendung die Verwendung eines gemeinsamen Anwendungsschichtprotokolls beinhalten.
In Beispiel 9 beinhaltet der Gegenstand der Beispiele 1-8 einen Gegenstand, wonach die Bestätigungsnachricht ferner angibt, dass der mindestens eine Anbieter für die MEC-Anwendung geeignet ist, um eine Kommunikationssitzung zu dem Informationsdienst über direkte Kommunikation mit dem mindestens einen Anbieter zu initiieren.
In Beispiel 10 beinhaltet der Gegenstand der Beispiele 1-9 einen Gegenstand, wonach die Verarbeitungsschaltungsanordnung ferner dazu konfiguriert ist, eine zweite Subskriptionsanfrage an einen zweiten Informationsdienst zu erkennen, wobei die zweite Subskriptionsanfrage von der MEC-Anwendung stammt, wobei die zweite Subskriptionsanfrage zumindest ein zweites Filterkriterium beinhaltet, das ein Anwendungsschichtprotokoll angibt, das von der MEC-Anwendung unterstützt wird.
In Beispiel 11 beinhaltet der Gegenstand des Beispiels 10 einen Gegenstand, wonach die Verarbeitungsschaltungsanordnung ferner dazu konfiguriert ist, über die Netzwerkschnittstellenschaltungsanordnung die zweite Subskriptionsanfrage mit zumindest dem zweiten Filterkriterium an die Vielzahl von Anbietern weiterzuleiten, wobei die Vielzahl von Anbietern als eine entsprechende Vielzahl von MEC-Anwendungen instanziiert ist, die den zweiten Informationsdienst bereitstellen.
In Beispiel 12 beinhaltet der Gegenstand des Beispiels 11 einen Gegenstand, wonach die Verarbeitungsschaltungsanordnung ferner dazu konfiguriert ist, eine Bestätigungsnachricht zur Übertragung an die MEC-Anwendung über die Netzwerkschnittstellenschaltungsanordnung zu codieren, wobei die Bestätigungsnachricht eine Annahme der zweiten Subskriptionsanfrage durch den Rechenknoten angibt.
In Beispiel 13 beinhaltet der Gegenstand des Beispiels 12 einen Gegenstand, wonach die Verarbeitungsschaltungsanordnung ferner dazu konfiguriert ist, eine Informationsnachricht von zumindest einem zweiten Anbieter der Vielzahl von Anbietern zu decodieren, wobei die Informationsnachricht der zweiten Subskriptionsanfrage zugeordnet ist und basierend auf einem Anwendungsschichtprotokoll konfiguriert ist, das von dem zumindest zweiten Anbieter unterstützt wird, wobei das Anwendungsschichtprotokoll, das von dem zumindest zweiten Anbieter unterstützt wird, mit dem Anwendungsschichtprotokoll, das von der MEC-Anwendung unterstützt wird, inkompatibel ist; eine Protokollkonvertierung der Informationsnachricht in das Anwendungsschichtprotokoll durchzuführen, das von der MEC-Anwendung unterstützt wird, um eine konvertierte Informationsnachricht zu erzeugen; und die konvertierte Informationsnachricht zur Übertragung an die MEC-Anwendung in Reaktion auf die zweite Subskriptionsanfrage zu codieren.
Beispiel 14 ist mindestens ein nicht-transientes maschinenlesbares Speichermedium, das darauf gespeicherte Anweisungen umfasst, die bei Ausführung durch eine Verarbeitungsschaltungsanordnung eines Rechenknotens, der betreibbar ist, um einen Fahrzeug-zu-Alles- (V2X-) Informationsdienst (VIS) in einem Mehrfachzugriff-Edge-Computing- (MEC-) Netzwerk zu implementieren, bewirken, dass die Verarbeitungsschaltungsanordnung Operationen durchführt, die Folgendes umfassen: Erkennen einer Subskriptionsanfrage an einen Informationsdienst, wobei die Subskriptionsanfrage von einer MEC-Anwendung stammt, die auf einem MEC-Host des MEC-Netzwerks instanziiert ist, und die Subskriptionsanfrage mindestens ein Filterkriterium beinhaltet, das eine Informationsverarbeitungskonfiguration der MEC-Anwendung angibt; Weiterleiten der Subskriptionsanfrage mit dem mindestens einen Filterkriterium an eine Vielzahl von Rechenressourcen, wobei die Vielzahl von Rechenressourcen als eine entsprechende Vielzahl von Anbietern des Informationsdienstes innerhalb des MEC-Netzwerks konfiguriert ist; Decodieren einer Antwortnachricht, die von mindestens einem Anbieter der Vielzahl von Anbietern empfangen wird, wobei die Antwortnachricht eine Annahme der Subskriptionsanfrage durch den mindestens einen Anbieter angibt; und Codieren einer Bestätigungsnachricht zur Übertragung an die MEC-Anwendung, wobei die Bestätigungsnachricht die Annahme der Subskriptionsanfrage durch den mindestens einen Anbieter angibt.
In Beispiel 15 beinhaltet der Gegenstand des Beispiels 14, dass die Operationen Folgendes beinhalten: Decodieren einer Registrierungsanfrage von jedem Anbieter der Vielzahl von Anbietern, wobei die Registrierungsanfrage angibt, dass der Anbieter einen V2X-Nachrichtendienst innerhalb des MEC-Netzwerks anbietet.
In Beispiel 16 beinhaltet der Gegenstand des Beispiels 15 einen Gegenstand, wonach die Vielzahl von Anbietern als entsprechende Vielzahl von MEC-Anwendungen auf zumindest einem zweiten MEC-Host des MEC-Netzwerks instanziiert ist.
In Beispiel 17 beinhaltet der Gegenstand des Beispiels 16, dass die Operationen Folgendes beinhalten: Registrieren der Vielzahl von MEC-Anwendungen als dienstproduzierende MEC-Anwendungen, die den V2X-Nachrichtendienst innerhalb des MEC-Netzwerks konfigurieren.
Bei Beispiel 18 beinhaltet der Gegenstand der Beispiele 14 bis 17, dass die Operationen Folgendes beinhalten: Erkennen einer zweiten Subskriptionsanfrage an einen zweiten Informationsdienst, wobei die zweite Subskriptionsanfrage von der MEC-Anwendung stammt, wobei die zweite Subskriptionsanfrage zumindest ein zweites Filterkriterium beinhaltet, das ein Anwendungsschichtprotokoll angibt, das von der MEC-Anwendung unterstützt wird; und Weiterleiten der zweiten Subskriptionsanfrage mit zumindest dem zweiten Filterkriterium an die Vielzahl von Anbietern, wobei die Vielzahl von Anbietern als entsprechende Vielzahl von MEC-Anwendungen instanziiert ist, die den zweiten Informationsdienst bereitstellen.
In Beispiel 19 beinhaltet der Gegenstand des Beispiels 18, dass die Operationen Folgendes beinhalten: Codieren einer Bestätigungsnachricht zur Übertragung an die MEC-Anwendung, wobei die Bestätigungsnachricht eine Annahme der zweiten Subskriptionsanfrage durch den Rechenknoten angibt; Decodieren einer Informationsnachricht von zumindest einem zweiten Anbieter der Vielzahl von Anbietern, wobei die Informationsnachricht der zweiten Subskriptionsanfrage zugeordnet ist und basierend auf einem Anwendungsschichtprotokoll konfiguriert ist, das von dem zumindest zweiten Anbieter unterstützt wird, wobei das Anwendungsschichtprotokoll, das von dem zumindest zweiten Anbieter unterstützt wird, mit dem Anwendungsschichtprotokoll, das von der MEC-Anwendung unterstützt wird, inkompatibel ist; Durchführen einer Protokollkonvertierung der Informationsnachricht in das Anwendungsschichtprotokoll, das von der MEC-Anwendung unterstützt wird, um eine konvertierte Informationsnachricht zu erzeugen; und Codieren der konvertierten Informationsnachricht zur Übertragung an die MEC-Anwendung in Reaktion auf die zweite Subskriptionsanfrage.
Beispiel 20 ist ein Verfahren zum Durchführen einer Fahrzeug-zu-Alles- (V2X-) Informationsdienst- (VIS-) Konfiguration in einem Mehrfachzugriff-Edge-Computing-(MEC-) Netzwerk, wobei das Verfahren Folgendes umfasst: durch eine Verarbeitungsschaltungsanordnung eines Rechenknotens erfolgendes Erkennen einer Subskriptionsanfrage an einen Informationsdienst, wobei die Subskriptionsanfrage von einer MEC-Anwendung stammt, die auf einem MEC-Host des MEC-Netzwerks instanziiert ist, und die Subskriptionsanfrage mindestens ein Filterkriterium beinhaltet, das eine Informationsverarbeitungskonfiguration der MEC-Anwendung angibt; Weiterleiten der Subskriptionsanfrage mit dem mindestens einen Filterkriterium an eine Vielzahl von Rechenressourcen, wobei die Vielzahl von Rechenressourcen als eine entsprechende Vielzahl von Anbietern des Informationsdienstes innerhalb des MEC-Netzwerks konfiguriert ist; Decodieren einer Antwortnachricht, die von mindestens einem Anbieter der Vielzahl von Anbietern empfangen wird, wobei die Antwortnachricht eine Annahme der Subskriptionsanfrage durch den mindestens einen Anbieter angibt; und Codieren einer Bestätigungsnachricht zur Übertragung an die MEC-Anwendung, wobei die Bestätigungsnachricht die Annahme der Subskriptionsanfrage durch den mindestens einen Anbieter angibt.
In Beispiel 21 beinhaltet der Gegenstand des Beispiels 20 Decodieren einer Registrierungsanfrage von jedem Anbieter der Vielzahl von Anbietern, wobei die Registrierungsanfrage angibt, dass der Anbieter einen V2X-Nachrichtendienst innerhalb des MEC-Netzwerks anbietet.
In Beispiel 22 beinhaltet der Gegenstand der Beispiele 20 bis 21 Erkennen einer zweiten Subskriptionsanfrage an einen zweiten Informationsdienst, wobei die zweite Subskriptionsanfrage von der MEC-Anwendung stammt, wobei die zweite Subskriptionsanfrage zumindest ein zweites Filterkriterium beinhaltet, das ein Anwendungsschichtprotokoll angibt, das von der MEC-Anwendung unterstützt wird; und Weiterleiten der zweiten Subskriptionsanfrage mit zumindest dem zweiten Filterkriterium an die Vielzahl von Anbietern, wobei die Vielzahl von Anbietern als entsprechende Vielzahl von MEC-Anwendungen instanziiert ist, die den zweiten Informationsdienst bereitstellen.
In Beispiel 23 beinhaltet der Gegenstand des Beispiels 22 Codieren einer Bestätigungsnachricht zur Übertragung an die MEC-Anwendung, wobei die Bestätigungsnachricht eine Annahme der zweiten Subskriptionsanfrage durch den Rechenknoten angibt; Decodieren einer Informationsnachricht von zumindest einem zweiten Anbieter der Vielzahl von Anbietern, wobei die Informationsnachricht der zweiten Subskriptionsanfrage zugeordnet ist und basierend auf einem Anwendungsschichtprotokoll konfiguriert ist, das von dem zumindest zweiten Anbieter unterstützt wird, wobei das Anwendungsschichtprotokoll, das von dem zumindest zweiten Anbieter unterstützt wird, mit dem Anwendungsschichtprotokoll, das von der MEC-Anwendung unterstützt wird, inkompatibel ist; Durchführen einer Protokollkonvertierung der Informationsnachricht in das Anwendungsschichtprotokoll, das von der MEC-Anwendung unterstützt wird, um eine konvertierte Informationsnachricht zu erzeugen; und Codieren der konvertierten Informationsnachricht zur Übertragung an die MEC-Anwendung in Reaktion auf die zweite Subskriptionsanfrage.
Beispiel 24 ist eine Einrichtung, die Folgendes umfasst: Mittel zum Erkennen einer Subskriptionsanfrage an einen Informationsdienst, wobei die Subskriptionsanfrage von einer MEC-Anwendung stammt, die auf einem MEC-Host des MEC-Netzwerks instanziiert ist, und wobei die Subskriptionsanfrage mindestens ein Filterkriterium beinhaltet, das eine Informationsverarbeitungskonfiguration der MEC-Anwendung angibt; Mittel zum Weiterleiten der Subskriptionsanfrage mit dem mindestens einen Filterkriterium an eine Vielzahl von Anbietern des Informationsdienstes innerhalb des MEC-Netzwerks; Mittel zum Decodieren einer Antwortnachricht, die von mindestens einem Anbieter der Vielzahl von Anbietern empfangen wird, wobei die Antwortnachricht eine Annahme der Subskriptionsanfrage durch den mindestens einen Anbieter angibt; und Mittel zum Codieren einer Bestätigungsnachricht zur Übertragung an die MEC-Anwendung, wobei die Bestätigungsnachricht die Annahme der Subskriptionsanfrage durch den mindestens einen Anbieter angibt.
In Beispiel 25 beinhaltet der Gegenstand des Beispiels 24 Mittel zum Erkennen einer zweiten Subskriptionsanfrage an einen zweiten Informationsdienst, wobei die zweite Subskriptionsanfrage von der MEC-Anwendung stammt, wobei die zweite Subskriptionsanfrage zumindest ein zweites Filterkriterium beinhaltet, das ein Anwendungsschichtprotokoll angibt, das von der MEC-Anwendung unterstützt wird; Mittel zum Weiterleiten der zweiten Subskriptionsanfrage mit dem zumindest zweiten Filterkriterium an die Vielzahl von Anbietern, wobei die Vielzahl von Anbietern als eine entsprechende Vielzahl von MEC-Anwendungen instanziiert ist, die den zweiten Informationsdienst bereitstellen; Mittel zum Codieren einer Bestätigungsnachricht zur Übertragung an die MEC-Anwendung, wobei die Bestätigungsnachricht eine Annahme der zweiten Subskriptionsanfrage durch die Einrichtung angibt; Mittel zum Decodieren einer Informationsnachricht von zumindest einem zweiten Anbieter der Vielzahl von Anbietern, wobei die Informationsnachricht der zweiten Subskriptionsanfrage zugeordnet und basierend auf einem Anwendungsschichtprotokoll konfiguriert ist, das von dem zumindest zweiten Anbieter unterstützt wird, wobei das Anwendungsschichtprotokoll, das von dem zumindest zweiten Anbieter unterstützt wird, mit dem Anwendungsschichtprotokoll, das von der MEC-Anwendung unterstützt wird, inkompatibel ist; Mittel zum Durchführen einer Protokollkonvertierung der Informationsnachricht in das Anwendungsschichtprotokoll, das von der MEC-Anwendung unterstützt wird, um eine konvertierte Informationsnachricht zu erzeugen; und Mittel zum Codieren der konvertierten Informationsnachricht zur Übertragung an die MEC-Anwendung in Reaktion auf die zweite Subskriptionsanfrage.
Beispiel 26 ist ein Edge-Rechenknoten, der in einem Edge-Computing-System betreibbar ist und eine Verarbeitungsschaltungsanordnung umfasst, die dazu konfiguriert ist, eines der Beispiele 1-25 zu implementieren.
Beispiel 27 ist ein Edge-Rechenknoten, der als Server in einem Edge-Computing-System betreibbar ist und dazu konfiguriert ist, eines der Beispiele 1-25 durchzuführen.
Beispiel 28 ist ein Edge-Rechenknoten, der als Client in einem Edge-Computing-System betreibbar ist und dazu konfiguriert ist, eines der Beispiele 1-25 durchzuführen.
Beispiel 29 ist ein Edge-Rechenknoten, der in einer Schicht eines Edge-Computing-Netzwerks als ein Aggregationsknoten, Netzwerk-Hub-Knoten, Gateway-Knoten oder Kerndatenverarbeitungsknoten betreibbar und dazu konfiguriert ist, eines der Beispiele 1-25 durchzuführen.
Beispiel 30 ist ein Edge-Computing-Netzwerk, der Netzwerk- und Verarbeitungskomponenten umfasst, die konfiguriert sind, um ein Kommunikationsnetzwerk bereitzustellen oder zu betreiben, um es einem Edge-Computing-System zu ermöglichen, eines der Beispiele 1-25 zu implementieren.
Beispiel 31 ist ein Zugangspunkt, der Netzwerk- und Verarbeitungskomponenten umfasst, die konfiguriert sind, um ein Kommunikationsnetzwerk bereitzustellen oder zu betreiben, um einem Edge-Computing-System zu ermöglichen, eines der Beispiele 1-25 zu implementieren.
Beispiel 32 ist eine Basisstation, die Netzwerk- und Verarbeitungskomponenten umfasst, die konfiguriert sind, um ein Kommunikationsnetzwerk bereitzustellen oder zu betreiben, um es einem Edge-Computing-System zu ermöglichen, eines der Beispiele 1-25 zu implementieren.
Beispiel 33 ist eine Straßenrandeinheit (roadside unit, RSU), die Netzwerkkomponenten umfasst, die dazu konfiguriert sind, ein Kommunikationsnetzwerk bereitzustellen oder zu betreiben, um es einem Edge-Computing-System zu ermöglichen, eines der Beispiele 1-25 zu implementieren.
Beispiel 34 ist ein Vor-Ort-Server, der in einem privaten Kommunikationsnetzwerk betreibbar ist, das sich von einem öffentlichen Edge-Computing-Netzwerk unterscheidet, wobei der Server konfiguriert ist, um einem Edge-Computing-System zu ermöglichen, eines der Beispiele 1-25 zu implementieren.
Beispiel 35 ist ein 3GPP-4G/LTE-Mobil-Drahtlos-Kommunikationssystem, das Vernetzungs- und Verarbeitungskomponenten umfasst, die mit den biometrischen Sicherheitsverfahren nach einem der Beispiele 1-25 konfiguriert sind.
Beispiel 36 ist ein 5G-Netzwerk-Mobildrahtloskommunikationssystem, das Vernetzungs- und Verarbeitungskomponenten umfasst, die mit den biometrischen Sicherheitsverfahren nach einem der Beispiele 1-25 konfiguriert sind.
Beispiel 37 ist eine Benutzergerät-Vorrichtung, die eine Netzwerk- und Verarbeitungsschaltungsanordnung umfasst, die dazu konfiguriert ist, sich mit einem Edge-Computing-System zu verbinden, das dazu konfiguriert ist, eines der Beispiele 1-25 zu implementieren.
Beispiel 38 ist eine Client-Rechenvorrichtung, die eine Verarbeitungsschaltungsanordnung umfasst, die dazu konfiguriert ist, Rechenoperationen mit einem Edge-Computing-System zu koordinieren, wobei das Edge-Computing-System dazu konfiguriert ist, eines der Beispiele 1-25 zu implementieren.
Beispiel 39 ist ein Edge-Bereitstellungsknoten, der in einem Edge-Computing-System betreibbar und konfiguriert ist, um eines der Beispiele 1-25 zu implementieren.
Beispiel 40 ist ein Dienstorchestrierungsknoten, der in einem Edge-Computing-System betreibbar und konfiguriert ist, um eines der Beispiele 1-25 zu implementieren.
Beispiel 41 ist ein Anwendungsorchestrierungsknoten, der in einem Edge-Computing-System betreibbar und konfiguriert ist, um eines der Beispiele 1-25 zu implementieren.
Beispiel 42 ist ein mandantenfähiger Verwaltungsknoten, der in einem Edge-Computing-System betreibbar und konfiguriert ist, um eines der Beispiele 1-25 zu implementieren.
Beispiel 43 ist ein Edge-Computing-System, das eine Verarbeitungsschaltungsanordnung umfasst, wobei das Edge-Computing-System dazu konfiguriert ist, eine oder mehrere Funktionen und Dienste zum Implementieren eines beliebigen der Beispiele 1-25 zu betreiben.
Beispiel 44 ist ein Edge-Computing-System, das eine Vielzahl von Edge-Rechenknoten umfasst, wobei die Vielzahl von Edge-Rechenknoten mit den biometrischen Sicherheitsverfahren nach einem der Beispiele 1-25 konfiguriert sind.
Beispiel 45 ist Vernetzungshardware mit darauf implementierten Netzwerkfunktionen, die innerhalb eines Edge-Computing-Systems betreibbar ist, das mit den biometrischen Sicherheitsverfahren nach einem der Beispiele 1-25 konfiguriert ist.
Beispiel 46 ist Beschleunigungshardware mit darauf implementierten Beschleunigungsfunktionen, die in einem Edge-Computing-System betreibbar ist, wobei die Beschleunigungsfunktionen konfiguriert sind, um eines der Beispiele 1-25 zu implementieren.
Beispiel 47 ist Speicherhardware mit darauf implementierten Speicherfähigkeiten, die in einem Edge-Computing-System betreibbar ist, wobei die Speicherhardware konfiguriert ist, um eines der Beispiele 1-25 zu implementieren.
Beispiel 48 ist Rechenhardware mit darauf implementierten Rechenfähigkeiten, die in einem Edge-Computing-System betreibbar ist, wobei die Rechenhardware konfiguriert ist, um eines der Beispiele 1-25 zu implementieren.
Beispiel 49 ist ein Edge-Computing-System, das zum Unterstützen von Fahrzeug-zu-Fahrzeug- (V2V-), Fahrzeug-zu-Alles- (V2X-) oder Fahrzeug-zu-Infrastruktur- (V2I-) Szenarien ausgelegt und dazu konfiguriert ist, eines der Beispiele 1-25 zu implementieren.
Beispiel 50 ist ein Edge-Computing-System, das zum Betreiben gemäß einer oder mehreren ETSI- (European Telecommunications Standards Institute) Mehrfachzugriff-Edge-Computing- (MEC-) Spezifikationen ausgelegt ist, wobei das Edge-Computing-System konfiguriert ist, um eines der Beispiele 1-25 zu implementieren.
Beispiel 51 ist ein Edge-Computing-System, das zum Betreiben einer oder mehrerer Mehrfachzugriff-Edge-Computing- (MEC-) Komponenten ausgelegt ist, wobei die MEC-Komponenten von einem oder mehreren der Folgenden bereitgestellt werden: einem MEC-Proxy, einem MEC-Anwendungsorchestrator, einer MEC-Anwendung, einer MEC-Plattform oder einem MEC-Dienst gemäß einer ETSI- (European Telecommunications Standards Institute) Mehrfachzugriff-Edge-Computing- (MEC-) Konfiguration, wobei die MEC-Komponenten konfiguriert sind, um eines der Beispiele 1-25 zu implementieren.
Beispiel 52 ist ein Edge-Computing-System, das als ein Edge-Mesh konfiguriert ist, das mit einem Mikrodienst-Cluster, einem Mikrodienst-Cluster mit Sidecars oder verknüpften Mikrodienst-Clustern mit Sidecars versehen ist, und das konfiguriert ist, um eines der Beispiele 1-25 zu implementieren.
Beispiel 53 ist ein Edge-Computing-System, das eine Schaltungsanordnung umfasst, die dazu konfiguriert ist, eine oder mehrere Isolationsumgebungen zu implementieren, die unter dedizierter Hardware, virtuellen Maschinen, Containern, virtuellen Maschinen auf Containern bereitgestellt werden, und das dazu konfiguriert ist, eines der Beispiele 1-25 zu implementieren.
Beispiel 54 ist ein Edge-Computing-Server, der zum Betrieb als ein Unternehmens server, Straßenrandserver, Straßenschrankserver oder Telekommunikationsserver konfiguriert ist und zum Implementieren eines der Beispiele 1-25 konfiguriert ist.
Beispiel 55 ist ein Edge-Computing-System, das konfiguriert ist, um eines der Beispiele 1-25 mit Verwendungsfällen umzusetzen, die von einem oder mehreren der Folgenden bereitgestellt werden: Rechenauslagerung, Daten-Caching, Videoverarbeitung, Netzwerkfunktionsvirtualisierung, Funkzugangsnetzverwaltung, erweiterte Realität, virtuelle Realität, autonomes Fahren, Fahrzeugassistenz, Fahrzeugkommunikation, industrielle Automatisierung, Einzelhandeldienste, Herstellungsoperationen, intelligente Gebäude, Energiemanagement, Internet-der-Dinge-Operationen, Objekterkennung, Spracherkennung, Gesundheitswesen-Anwendungen, Spielanwendungen oder beschleunigte Inhaltsverarbeitung.
Beispiel 56 ist ein Edge-Computing-System, das Rechenknoten umfasst, die von mehreren Eigentümern an unterschiedlichen geografischen Standorten betrieben werden, und das dazu konfiguriert ist, eines der Beispiele 1-25 zu implementieren.
Beispiel 57 ist ein Cloud-Computing-System, das Datenserver umfasst, die jeweilige Cloud-Dienste betreiben, wobei die jeweiligen Cloud-Dienste konfiguriert sind, um sich mit einem Edge-Computing-System zu koordinieren, um eines der Beispiele 1-25 zu implementieren.
Beispiel 58 ist ein Server, der Hardware zum Betreiben von Cloudlet-, Edgelet- oder Applet-Diensten umfasst, wobei die Dienste konfiguriert sind, um sich mit einem Edge-Computing-System zu koordinieren, um eines der Beispiele 1-25 zu implementieren.
Beispiel 59 ist ein Edge-Knoten in einem Edge-Computing-System, der eine oder mehrere Vorrichtungen mit mindestens einem Prozessor und Speicher zum Implementieren eines der Beispiele 1-25 umfasst.
Beispiel 60 ist ein Edge-Knoten in einem Edge-Computing-System, wobei der Edge-Knoten einen oder mehrere Dienste betreibt, die unter einem Verwaltungskonsolendienst, einem Telemetriedienst, einem Bereitstellungsdienst, einem Anwendungs- oder einem Dienstorchestrierungsdienst, einem Virtual-Machine-Dienst, einem Container-Dienst, einem Funktionsbereitstellungdienst oder einem Rechenbereitstellungsdienst oder einem Beschleunigungsverwaltungsdienst bereitgestellt werden, wobei der eine oder die mehreren Dienste konfiguriert sind, um eines der Beispiele 1-25 zu implementieren.
Beispiel 61 ist ein Satz verteilter Edge-Knoten, die in einer Netzwerkschicht eines Edge-Computing-System verteilt sind, wobei die Netzwerkschicht eine Close-Edge-, Local-Edge-, Unternehmens-Edge-, Vor-Ort-Edge-, Near-Edge-, Middle-Edge- oder Far-Edge-Netzwerkschicht umfasst, die konfiguriert ist, um eines der Beispiele 1-25 zu implementieren.
Beispiel 62 ist eine Einrichtung eines Edge-Computing-Systems, umfassend: einen oder mehrere Prozessoren und ein oder mehrere computerlesbare Medien, die Anweisungen umfassen, die bei Ausführung durch den einen oder die mehreren Prozessoren bewirken, dass der eine oder die mehreren Prozessoren eines der Beispiele 1-25 durchführen.
Beispiel 63 ist ein oder mehrere computerlesbare Speichermedien, die Anweisungen umfassen, um zu bewirken, dass eine elektronische Vorrichtung eines Edge-Computing-Systems bei Ausführung der Anweisungen durch einen oder mehrere Prozessoren der elektronischen Vorrichtung eines der Beispiele 1-25 durchführt.
Beispiel 64 ist ein Kommunikationssignal, das in einem Edge-Computing-System kommuniziert wird, um eines der Beispiele 1-25 durchzuführen.
Beispiel 65 ist eine Datenstruktur, die in einem Edge-Computing-System kommuniziert wird, wobei die Datenstruktur ein Datagramm, ein Paket, einen Rahmen, ein Segment, eine Protokolldateneinheit (PDU) oder eine Nachricht umfasst, um eines der Beispiele 1 bis 25 durchzuführen.
Beispiel 66 ist ein Signal, das in einem Edge-Computing-System kommuniziert wird, wobei das Signal mit einem Datagramm, Paket, Rahmen, Segment, einer Protokolldateneinheit (PDU), einer Nachricht oder Daten codiert ist, um eines der Beispiele 1-25 durchzuführen.
Beispiel 67 ist ein elektromagnetisches Signal, das in einem Edge-Computing-System kommuniziert wird, wobei das elektromagnetische Signal computerlesbare Anweisungen trägt, wobei die Ausführung der computerlesbaren Anweisungen durch einen oder mehrere Prozessoren bewirkt, dass der eine oder die mehreren Prozessoren eines der Beispiele 1-25 durchführen.
Beispiel 68 ist ein Computerprogramm, das in einem Edge-Computing-System verwendet wird, wobei das Computerprogramm Anweisungen umfasst, wobei eine Ausführung des Programms durch ein Verarbeitungselement in dem Edge-Computing-System bewirken soll, dass das Verarbeitungselement eines der Beispiele 1-25 durchführt.
Beispiel 69 ist eine Einrichtung eines Edge-Computing-Systems, die Mittel zum Durchführen eines der Beispiele 1-25 umfasst.
Beispiel 70 ist eine Einrichtung eines Edge-Computing-Systems, die Logik, Module oder Schaltungsanordnungen zum Durchführen eines der Beispiele 1-25 umfasst.
Beispiel 71 ist mindestens ein maschinenlesbares Medium, das Anweisungen beinhaltet, die bei Ausführung durch eine Verarbeitungsschaltungsanordnung die Verarbeitungsschaltungsanordnung veranlassen, Operationen durchzuführen, um eines der Beispiele 1-70 zu implementieren.
Beispiel 72 ist eine Einrichtung, die Mittel zum Implementieren eines beliebigen der Beispiele 1 - 70 umfasst.
Beispiel 73 ist ein System zum Implementieren eines beliebigen der Beispiele 1 - 70.
Beispiel 74 ist ein Verfahren zum Implementieren eines beliebigen der Beispiele 1 - 70.
Obwohl diese Implementierungen unter Bezugnahme auf spezifische beispielhafte Aspekte beschrieben wurden, versteht es sich, dass zahlreiche Modifikationen und Änderungen an diesen Aspekten vorgenommen werden können, ohne von dem breiteren Schutzbereich der vorliegenden Offenbarung abzuweichen. Viele der hierin beschriebenen Anordnungen und Prozesse können in Kombination oder in parallelen Implementierungen verwendet werden, um eine größere Bandbreite/einen größeren Durchsatz bereitzustellen und Edge-Dienst-Auswahlmöglichkeiten zu unterstützen, die den zu bedienenden Edge-Systemen zur Verfügung gestellt werden können. Dementsprechend sind die Spezifikation und die Zeichnungen eher in einem veranschaulichenden statt in einem einschränkenden Sinne aufzufassen. Die begleitenden Zeichnungen, die einen Teil hiervon bilden, zeigen zur Veranschaulichung, aber nicht zur Einschränkung, spezifische Aspekte, in denen der Gegenstand der Erfindung in die Praxis umgesetzt werden kann. Die veranschaulichten Aspekte sind hinreichend detailliert beschrieben, um einen Fachmann zu befähigen, die hier offenbarten Lehren in die Praxis umzusetzen. Andere Aspekte können genutzt und daraus abgeleitet werden, so dass strukturelle und logische Substitutionen und Änderungen vorgenommen werden können, ohne vom Schutzumfang dieser Offenbarung abzuweichen. Diese ausführliche Beschreibung ist daher nicht in einem beschränkenden Sinn aufzufassen, und der Schutzumfang verschiedener Aspekte ist nur durch die angehängten Ansprüche zusammen mit dem vollen Umfang von Äquivalenten, zu denen solche Ansprüche berechtigt sind, definiert.
Auf solche Aspekte des erfinderischen Gegenstands kann hierin einzeln und/oder kollektiv Bezug genommen werden, lediglich der Einfachheit halber und ohne die Absicht, den Schutzumfang dieser Anmeldung willentlich auf irgendeinen einzelnen Aspekt oder ein erfinderisches Konzept zu beschränken, falls mehr als einer/eines offenbart ist. Auch wenn vorliegend konkrete Aspekte veranschaulicht und beschrieben wurden, versteht es sich daher, dass jegliche Anordnung, die dafür berechnet ist, denselben Zweck zu erfüllen, die gezeigten konkreten Aspekte ersetzen kann. Diese Offenbarung soll jegliche Anpassungen oder Varianten verschiedener Aspekte abdecken. Kombinationen der vorstehenden Aspekte und anderer, hierin nicht spezifisch beschriebener Aspekte werden für den Fachmann aus der Durchsicht der vorstehenden Beschreibung ersichtlich.
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 63/197608 [0001]

Claims

Rechenknoten zum Implementieren eines Fahrzeug-zu-Alles- (V2X-) Informationsdienstes (VIS) in einem Mehrfachzugriff-Edge-Computing- (MEC-) Netzwerk, wobei der Rechenknoten Folgendes umfasst: eine Netzwerkschnittstellenschaltungsanordnung; und eine Verarbeitungsschaltungsanordnung, die mit der Netzwerkschnittstellenschaltungsanordnung gekoppelt ist, wobei die Verarbeitungsschaltungsanordnung für Folgendes konfiguriert ist: Erkennen einer Subskriptionsanfrage an einen Informationsdienst, wobei die Subskriptionsanfrage von einer MEC-Anwendung stammt, die auf einem MEC-Host des MEC-Netzwerks instanziiert ist, und die Subskriptionsanfrage mindestens ein Filterkriterium beinhaltet, das eine Informationsverarbeitungskonfiguration der MEC-Anwendung angibt; über die Netzwerkschnittstellenschaltungsanordnung erfolgendes Weiterleiten der Subskriptionsanfrage mit dem mindestens einen Filterkriterium an eine Vielzahl von Rechenressourcen, wobei die Vielzahl von Rechenressourcen als entsprechende Vielzahl von Anbietern des Informationsdienstes innerhalb des MEC-Netzwerks konfiguriert ist; Decodieren einer Antwortnachricht, die von mindestens einem Anbieter der Vielzahl von Anbietern empfangen wird, wobei die Antwortnachricht eine Annahme der Subskriptionsanfrage durch den mindestens einen Anbieter angibt; und Codieren einer Bestätigungsnachricht zur Übertragung an die MEC-Anwendung über die Netzwerkschnittstellenschaltungsanordnung, wobei die Bestätigungsnachricht die Annahme der Subskriptionsanfrage durch den mindestens einen Anbieter angibt.
Rechenknoten nach Anspruch 1, wobei die Verarbeitungsschaltungsanordnung ferner konfiguriert ist zum: Decodieren einer Registrierungsanfrage von jedem Anbieter der Vielzahl von Anbietern, wobei die Registrierungsanfrage angibt, dass der Anbieter einen V2X-Nachrichtendienst innerhalb des MEC-Netzwerks anbietet.
Rechenknoten nach Anspruch 2, wobei der MEC-Host eine Mobilvorrichtung ist und wobei die Vielzahl von Anbietern als entsprechende Vielzahl von MEC-Anwendungen auf zumindest einem zweiten MEC-Host des MEC-Netzwerks instanziiert sind.
Rechenknoten nach Anspruch 3, wobei die Verarbeitungsschaltungsanordnung ferner zu Folgendem konfiguriert ist: Registrieren der Vielzahl von MEC-Anwendungen als dienstproduzierende MEC-Anwendungen, die den V2X-Nachrichtendienst innerhalb des MEC-Netzwerks konfigurieren.
Rechenknoten nach Anspruch 1, wobei einer oder mehrere der Vielzahl von Anbietern als dienstproduzierende Anwendung konfiguriert sind, die auf dem MEC-Host instanziiert ist.
Rechenknoten nach Anspruch 1, wobei die Subskriptionsanfrage von einer MEC-V2X-Anwendungsprogrammierschnittstelle (API) des VIS empfangen wird, wobei die MEC-V2X-API an dem MEC-Host konfiguriert ist.
Rechenknoten nach Anspruch 1, wobei die Antwortnachricht ferner Kompatibilität einer Informationsverarbeitungskonfiguration des mindestens einen Anbieters mit der Informationsverarbeitungskonfiguration der MEC-Anwendung angibt.
Rechenknoten nach Anspruch 7, wobei die Informationsverarbeitungskonfiguration des mindestens einen Anbieters und die Informationsverarbeitungskonfiguration der MEC-Anwendung die Verwendung eines gemeinsamen Anwendungsschichtprotokolls beinhalten.
Rechenknoten nach Anspruch 1, wobei die Bestätigungsnachricht ferner angibt, dass der mindestens eine Anbieter für die MEC-Anwendung geeignet ist, um eine Kommunikationssitzung zu dem Informationsdienst über direkte Kommunikation mit dem mindestens einen Anbieter zu initiieren.
Rechenknoten nach Anspruch 1, wobei die Verarbeitungsschaltungsanordnung ferner für Folgendes konfiguriert ist: Erkennen einer zweiten Subskriptionsanfrage an einen zweiten Informationsdienst, wobei die zweite Subskriptionsanfrage von der MEC-Anwendung stammt, wobei die zweite Subskriptionsanfrage zumindest ein zweites Filterkriterium beinhaltet, das ein Anwendungsschichtprotokoll angibt, das von der MEC-Anwendung unterstützt wird.
Rechenknoten nach Anspruch 10, wobei die Verarbeitungsschaltungsanordnung ferner für Folgendes konfiguriert ist: über die Netzwerkschnittstellenschaltungsanordnung erfolgendes Weiterleiten der zweiten Subskriptionsanfrage mit dem zumindest zweiten Filterkriterium an die Vielzahl von Anbietern, wobei die Vielzahl von Anbietern als eine entsprechende Vielzahl von MEC-Anwendungen instanziiert ist, die den zweiten Informationsdienst bereitstellen.
Rechenknoten nach Anspruch 11, wobei die Verarbeitungsschaltungsanordnung ferner für Folgendes konfiguriert ist: Codieren einer Bestätigungsnachricht zur Übertragung an die MEC-Anwendung über die Netzwerkschnittstellenschaltungsanordnung, wobei die Bestätigungsnachricht eine Annahme der zweiten Subskriptionsanfrage durch den Rechenknoten angibt.
Rechenknoten nach Anspruch 12, wobei die Verarbeitungsschaltungsanordnung ferner für Folgendes konfiguriert ist: Decodieren einer Informationsnachricht von zumindest einem zweiten Anbieter der Vielzahl von Anbietern, wobei die Informationsnachricht der zweiten Subskriptionsanfrage zugeordnet ist und basierend auf einem Anwendungsschichtprotokoll konfiguriert ist, das von dem zumindest zweiten Anbieter unterstützt wird, wobei das Anwendungsschichtprotokoll, das von dem zumindest zweiten Anbieter unterstützt wird, mit dem Anwendungsschichtprotokoll, das von der MEC-Anwendung unterstützt wird, inkompatibel ist; Durchführen einer Protokollkonvertierung der Informationsnachricht in das Anwendungsschichtprotokoll, das von der MEC-Anwendung unterstützt wird, um eine konvertierte Informationsnachricht zu erzeugen; und Codieren der konvertierten Informationsnachricht zur Übertragung an die MEC-Anwendung in Reaktion auf die zweite Subskriptionsanfrage.
Mindestens ein nicht-transientes maschinenlesbares Speichermedium, das darauf gespeicherte Anweisungen umfasst, die bei Ausführung durch eine Verarbeitungsschaltungsanordnung eines Rechenknotens, der betreibbar ist, um einen Fahrzeug-zu-Alles- (V2X-) Informationsdienst (VIS) in einem Mehrfachzugriff-Edge-Computing- (MEC-) Netzwerk zu implementieren, bewirken, dass die Verarbeitungsschaltungsanordnung Operationen durchführt, die Folgendes umfassen: Erkennen einer Subskriptionsanfrage an einen Informationsdienst, wobei die Subskriptionsanfrage von einer MEC-Anwendung stammt, die auf einem MEC-Host des MEC-Netzwerks instanziiert ist, und die Subskriptionsanfrage mindestens ein Filterkriterium beinhaltet, das eine Informationsverarbeitungskonfiguration der MEC-Anwendung angibt; Weiterleiten der Subskriptionsanfrage mit dem mindestens einen Filterkriterium an eine Vielzahl von Rechenressourcen, wobei die Vielzahl von Rechenressourcen als eine entsprechende Vielzahl von Anbietern des Informationsdienstes innerhalb des MEC-Netzwerks konfiguriert ist; Decodieren einer Antwortnachricht, die von mindestens einem Anbieter der Vielzahl von Anbietern empfangen wird, wobei die Antwortnachricht eine Annahme der Subskriptionsanfrage durch den mindestens einen Anbieter angibt; und Codieren einer Bestätigungsnachricht zur Übertragung an die MEC-Anwendung, wobei die Bestätigungsnachricht die Annahme der Subskriptionsanfrage durch den mindestens einen Anbieter angibt.
Mindestens ein nicht-transientes maschinenlesbares Speichermedium nach Anspruch 14, wobei die Operationen ferner Folgendes umfassen: Decodieren einer Registrierungsanfrage von jedem Anbieter der Vielzahl von Anbietern, wobei die Registrierungsanfrage angibt, dass der Anbieter einen V2X-Nachrichtendienst innerhalb des MEC-Netzwerks anbietet.
Mindestens ein nicht-transientes maschinenlesbares Speichermedium nach Anspruch 15, wobei die Vielzahl von Anbietern als entsprechende Vielzahl von MEC-Anwendungen auf zumindest einem zweiten MEC-Host des MEC-Netzwerks instanziiert sind.
Mindestens ein nicht-transientes maschinenlesbares Speichermedium nach Anspruch 16, wobei die Operationen ferner Folgendes umfassen: Registrieren der Vielzahl von MEC-Anwendungen als dienstproduzierende MEC-Anwendungen, die den V2X-Nachrichtendienst innerhalb des MEC-Netzwerks konfigurieren.
Mindestens ein nicht-transientes maschinenlesbares Speichermedium nach Anspruch 14, wobei die Operationen ferner Folgendes umfassen: Erkennen einer zweiten Subskriptionsanfrage an einen zweiten Informationsdienst, wobei die zweite Subskriptionsanfrage von der MEC-Anwendung stammt, wobei die zweite Subskriptionsanfrage zumindest ein zweites Filterkriterium beinhaltet, das ein Anwendungsschichtprotokoll angibt, das von der MEC-Anwendung unterstützt wird; und Weiterleiten der zweiten Subskriptionsanfrage mit dem zumindest zweiten Filterkriterium an die Vielzahl von Anbietern, wobei die Vielzahl von Anbietern als eine entsprechende Vielzahl von MEC-Anwendungen instanziiert ist, die den zweiten Informationsdienst bereitstellen.
Mindestens ein nicht-transientes maschinenlesbares Speichermedium nach Anspruch 18, wobei die Operationen ferner Folgendes umfassen: Codieren einer Bestätigungsnachricht zur Übertragung an die MEC-Anwendung, wobei die Bestätigungsnachricht eine Annahme der zweiten Subskriptionsanfrage durch den Rechenknoten angibt; Decodieren einer Informationsnachricht von zumindest einem zweiten Anbieter der Vielzahl von Anbietern, wobei die Informationsnachricht der zweiten Subskriptionsanfrage zugeordnet ist und basierend auf einem Anwendungsschichtprotokoll konfiguriert ist, das von dem zumindest zweiten Anbieter unterstützt wird, wobei das Anwendungsschichtprotokoll, das von dem zumindest zweiten Anbieter unterstützt wird, mit dem Anwendungsschichtprotokoll, das von der MEC-Anwendung unterstützt wird, inkompatibel ist; Durchführen einer Protokollkonvertierung der Informationsnachricht in das Anwendungsschichtprotokoll, das von der MEC-Anwendung unterstützt wird, um eine konvertierte Informationsnachricht zu erzeugen; und Codieren der konvertierten Informationsnachricht zur Übertragung an die MEC-Anwendung in Reaktion auf die zweite Subskriptionsanfrage.
Einrichtung, umfassend: Mittel zum Erkennen einer Subskriptionsanfrage an einen Informationsdienst, wobei die Subskriptionsanfrage von einer MEC-Anwendung stammt, die auf einem MEC-Host des MEC-Netzwerks instanziiert ist, und die Subskriptionsanfrage mindestens ein Filterkriterium beinhaltet, das eine Informationsverarbeitungskonfiguration der MEC-Anwendung angibt; Mittel zum Weiterleiten der Subskriptionsanfrage mit dem mindestens einen Filterkriterium an eine Vielzahl von Anbietern des Informationsdienstes innerhalb des MEC-Netzwerks; Mittel zum Decodieren einer Antwortnachricht, die von mindestens einem Anbieter der Vielzahl von Anbietern empfangen wird, wobei die Antwortnachricht eine Annahme der Subskriptionsanfrage durch den mindestens einen Anbieter angibt; und Mittel zum Codieren einer Bestätigungsnachricht zur Übertragung an die MEC-Anwendung, wobei die Bestätigungsnachricht die Annahme der Subskriptionsanfrage durch den mindestens einen Anbieter angibt.
Einrichtung nach Anspruch 20, ferner umfassend: Mittel zum Erkennen einer zweiten Subskriptionsanfrage an einen zweiten Informationsdienst, wobei die zweite Subskriptionsanfrage von der MEC-Anwendung stammt, wobei die zweite Subskriptionsanfrage zumindest ein zweites Filterkriterium beinhaltet, das ein Anwendungsschichtprotokoll angibt, das von der MEC-Anwendung unterstützt wird; Mittel zum Weiterleiten der zweiten Subskriptionsanfrage mit dem zumindest zweiten Filterkriterium an die Vielzahl von Anbietern, wobei die Vielzahl von Anbietern als eine entsprechende Vielzahl von MEC-Anwendungen instanziiert ist, die den zweiten Informationsdienst bereitstellen; Mittel zum Codieren einer Bestätigungsnachricht zur Übertragung an die MEC-Anwendung, wobei die Bestätigungsnachricht eine Annahme der zweiten Subskriptionsanfrage durch die Einrichtung angibt; Mittel zum Decodieren einer Informationsnachricht von zumindest einem zweiten Anbieter der Vielzahl von Anbietern, wobei die Informationsnachricht der zweiten Subskriptionsanfrage zugeordnet ist und basierend auf einem Anwendungsschichtprotokoll konfiguriert ist, das von dem zumindest zweiten Anbieter unterstützt wird, wobei das Anwendungsschichtprotokoll, das von dem zumindest zweiten Anbieter unterstützt wird, mit dem Anwendungsschichtprotokoll, das von der MEC-Anwendung unterstützt wird, inkompatibel ist; Mittel zum Durchführen einer Protokollkonvertierung der Informationsnachricht in das Anwendungsschichtprotokoll, das von der MEC-Anwendung unterstützt wird, um eine konvertierte Informationsnachricht zu erzeugen; und Mittel zum Codieren der konvertierten Informationsnachricht zur Übertragung an die MEC-Anwendung in Reaktion auf die zweite Subskriptionsanfrage.