DE112018007463T5 - Flexibler Mehrfachzugriffs-Edge-Computing-Dienstverbrauch (Mec-Dienstverbrauch) durch Hostzoning - Google Patents

Flexibler Mehrfachzugriffs-Edge-Computing-Dienstverbrauch (Mec-Dienstverbrauch) durch Hostzoning Download PDF

Info

Publication number
DE112018007463T5
DE112018007463T5 DE112018007463.3T DE112018007463T DE112018007463T5 DE 112018007463 T5 DE112018007463 T5 DE 112018007463T5 DE 112018007463 T DE112018007463 T DE 112018007463T DE 112018007463 T5 DE112018007463 T5 DE 112018007463T5
Authority
DE
Germany
Prior art keywords
mec
hosts
service
services
application
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE112018007463.3T
Other languages
English (en)
Inventor
Kilian Roth
Miltiadis Filippou
Dario Sabella
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel IP Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel IP Corp filed Critical Intel IP Corp
Publication of DE112018007463T5 publication Critical patent/DE112018007463T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/61—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources taking into account QoS or priority requirements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5009—Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Systeme und Verfahren zum Aufbauen, Konfigurieren und Betreiben von Mehrfachzugriffs-Edge-Computing-Diensten (MEC-Diensten) und Dienstverbrauch durch Zoning von Hosts in Multi-Vendor- oder Multi-System-Umgebungen. Eine Vorrichtung, die als ein MEC-Orchestrator funktioniert, um Dienstverbrauch unter Verwendung von Zonen zu verwalten, ist konfigurierbar, Operationen auszuführen zum: Empfangen einer Anfrage nach einer Liste von Diensten und entsprechenden Nähezonen von einer Anwendung, die auf einem Host ausgeführt wird; in Reaktion auf das Empfangen der Anfrage nach der Liste, Abfragen mehrerer Hosts nach Leistungsmetriken jeweiliger Dienste, die von den mehreren Hosts angeboten werden, wobei die jeweiligen Dienste durch die Anwendung, die auf dem Host ausgeführt wird, verwendet werden; Aufbauen einer Zonenkarte, die eine Zuordnung zwischen der Anwendung und den mehreren Hosts auf Grundlage der Leistungsmetriken unterhält; und Verwalten von Migration der Anwendung oder eines Diensts der jeweiligen Dienste, basierend auf der Zonenkarte, um die QoS der Anwendung sicherzustellen.

Description

  • PRIORITÄTSANSPRUCH
  • Diese Anmeldung beansprucht die Priorität der US-Anmeldung mit Seriennr. 62/656,138, eingereicht am 11. April 2018, deren Offenbarung hierin durch Verweis vollumfänglich eingeschlossen ist.
  • TECHNISCHES GEBIET
  • Hierin beschriebene Ausführungsformen beziehen sich allgemein auf Datenverarbeitungs- und Kommunikationssystemumsetzungen, und insbesondere auf Techniken zum Aufbauen und Umsetzen von Diensten in Vorrichtungsnetzwerken mit Mehrfachzugriffs-Edge-Computing (MEC) und Internet der Dinge (IoT).
  • HINTERGRUND
  • IoT-Vorrichtungen sind physische oder virtualisierte Objekte, die in einem Netzwerk kommunizieren können, und die Sensoren, Stellelemente und andere Ein-/Ausgabekomponenten umfassen können, wie etwa zum Erfassen von Daten oder zum Durchführen von Aktionen aus einer Umgebung in der echten Welt. Beispielsweise können IoT-Vorrichtungen Niederenergievorrichtungen umfassen, die in Alltagsgegenstände eingebettet oder daran angebracht sind, wie etwa an Gebäuden, Fahrzeugen, Verpackungen usw., um eine zusätzliche Ebene künstlicher sensorischer Wahrnehmung dieser Dinge bereitzustellen. In letzter Zeit wurden nahm die Beliebtheit von IoT-Vorrichtungen zu, und Anwendungen, die diese Vorrichtungen verwenden, haben sich daher stark verbreitet.
  • Mehrfachzugriffs-Edge-Computing (MEC) bietet Anwendungsentwicklern und Inhaltsanbietern Cloudrechenfähigkeiten und eine IT-Dienstumgebung am Rand des Netzwerks. Diese Umgebung ist durch eine ultraniedrige Latenz und hohe Bandbreite sowie durch Echtzeitzugriff auf die Funknetzwerkinformationen, die durch Anwendungen eingesetzt werden können, gekennzeichnet. MEC-Technologie erlaubt flexible und schnelle Einsätze innovativer Anwendungen und Dienste für mobile Teilnehmer, Unternehmen und vertikale Segmente.
  • Der Einsatz von IoT-Vorrichtungen und MEC-Diensten hat eine Anzahl von fortgeschnittenen Nutzungsfällen und Szenarios eingeführt, die am Rand des Netzwerks auftreten. Diese fortgeschnittenen Nutzungsfälle haben jedoch auch eine Reihe entsprechender technischer Herausforderungen eingeführt, die sich auf Sicherheit, Verarbeitung und Netzwerkressourcen, Dienstverfügbarkeit und Effizienz und viele andere Probleme beziehen.
  • Figurenliste
  • In den Zeichnungen, die nicht notwendigerweise maßstabsgetreu gezeichnet sind, können gleiche Ziffern in unterschiedlichen Ansichten ähnliche Bauteile bezeichnen. Gleiche Ziffern, die verschiedene Buchstabensuffixe aufweisen, können verschiedene Instanzen von ähnlichen Bauteilen darstellen. Hierin sind einige Ausführungsformen in den Figuren der beiliegenden Zeichnungen beispielhaft und nicht einschränkend illustriert, wobei gilt:
    • 1 illustriert eine Domaintopologie für jeweilige Internet-of-Things-Netzwerke (IoT-Netzwerke) nach einem Beispiel;
    • 2 illustriert ein Cloud-Computing-Netzwerk in Kommunikation mit einem Mesh-Netzwerk von IoT-Vorrichtungen, die als eine Fogvorrichtung am Rand des Cloud-Computing-Netzwerks laufen, nach einem Beispiel;
    • 3 illustriert eine Zeichnung eines Cloud-Rechennetzwerks oder einer Cloud, in Kommunikation mit einer Anzahl von Vorrichtungen aus dem Internet of Things (IoT) nach einem Beispiel;
    • 4 illustriert ein Blockdiagramm für eine beispielhafte IoT-Verarbeitungssystemarchitektur, bei der eine oder mehrere der Techniken (z. B. Operationen, Prozesse, Verfahren und Methodologien), die hierin besprochen werden, nach einem Beispiel ausgeführt werden können;
    • 5 illustriert ein MEC und Fog-Netzwerk nach einem Beispiel;
    • 6 illustriert Verarbeitungs- und Speicherschichten in einem MEC und Fog-Netzwerk nach einem Beispiel;
    • 7 zeigt ein Blockdiagramm für eine beispielhafte Mehrfachzugriffs-Edge-Computing-Systemarchitektur (MEC-Systemarchitektur), bei der eine oder mehrere der Techniken (z. B. Operationen, Prozesse, Verfahren und Methodologien), die hierin besprochen werden, nach einem Beispiel ausgeführt werden können;
    • 8 illustriert ein Referenzkommunikationssystem mit MEC-Hosts nach einem Beispiel;
    • 9 illustriert Vorrichtungen und Netzwerkentitäten in einer Mehrfachzugriffskommunikationsumgebung;
    • 10 illustriert eine operative Anordnung von Netzwerk- und Fahrzeugbenutzerausrüstung, wobei verschiedene Ausführungsformen ausgeführt werden können;
    • 11 illustriert Nähezonen von MEC-Apps, die unter MEC-Hosts gehostet werden, nach einem Beispiel;
    • 12 illustriert eine Topologie eines MEC-Systems, das vier MEC-Hosts umfasst, nach einem Beispiel;
    • 13 illustriert MEC-Hostnähezonen, die nach einer utilitybasierten Klassifizierung nach einem Beispiel;
    • 14 illustriert eine Nähezonenvisualisierung unter MEC-Hosts nach einem Beispiel;
    • 15 illustriert eine Quality-of-Service-Zonenvisualisierung (QoS-Zonenvisualisierung) unter MEC-Hosts, nach einem Beispiel;
    • 16 illustriert eine App-Migration innerhalb einer Quality-of-Service-Zonenvisualisierung (QoS-Zonenvisualisierung) unter MEC-Hosts, nach einem Beispiel;
    • 17 illustriert den Betrieb einer MEC-Anwendung und Diensten unter verschiedenen MEC-Hosts nach einem Beispiel; und
    • 18 ist ein Ablaufdiagramm, das ein Verfahren zum Verwalten von Dienstverbrauch unter Verwendung von Zonen nach einem Beispiel illustriert.
  • AUSFÜHRLICHE BESCHREIBUNG
  • In der folgenden Beschreibung werden Verfahren, Konfigurationen und verbundene Vorrichtungen für die Konfiguration und Nutzung von Mehrfachzugriffs-Edge-Computing-Diensten (MEC-Diensten) in cloud-edgebasierten Szenarios offenbart. In verschiedenen Beispielen stellen die hier offenbarten Techniken MEC-Verbesserungen bereit, die eine flexible Verwendung des MEC-Plattformdienstverbrauchs örtlich, in externen MEC-Hosts des MEC-Systems oder über verschiedene MEC-Systeme hinweg ermöglichen. Ferner führen die hier offenbarten Techniken eine Definition von QoS/kostenbewussten Nähezonen um MEC-Server und serviceerzeugende MEC-Anwendungsinstanzen ein. Weiterhin führen die hier offenbarten Techniken ein Signalisierungsprotokoll unter den beteiligten MEC-Entitäten für QoS/kostengünstigen MEC-Dienstverbrauch durch eine MEC-App ein, wobei die definierten Nähezonen in Betracht gezogen werden.
  • In dieser Offenbarung können Nähezonen unter Verwendung des MEC-Hosts, der eine MEC-Anwendungsinstanz als eine Referenz hostet, durch den MEC-Orchestrator des Referenz-MEC-Systems durch Ausnutzen eines statistischen Modells des Zoning-Utility-Kriteriums, z. B. der Zeit, die zwischen einer Dienstverbrauchsanfrage und dem Verbrauch des benötigten Diensts, der an demselben oder einem anderen MEC-Host instanziiert wird, verstrichen ist (Latenz), der Zuverlässigkeit des Dienstverbrauchsverfahrens (d. h. das Fehlen der von Ausfällen/Steuerpaketverlusten) oder einer anderen Analyse aufgebaut werden.
  • Zum Verifizieren der Gültigkeit und Rechtzeitigkeit statistisch aufgebauter Nähezonen können Messungen und Zahlen aus der echten Welt durch den MEC-Orchestrator verwendet werden, um den statistisch geformten Aufbau von Zonen zu verifizieren oder zu widerlegen. Bei der Verifizierung muss das verwendete statistische Modell für den Nähezonenaufbau nicht aktualisiert werden, weil es mit Blick auf die aktuellen Systembedingungen ausreichend genau ist. Wenn dies nicht der Fall ist, muss etwa das statistische Modell (z. B. die komplementären kumulativen Verteilungsfunktionen (CCDFs) der MEC-Host-to-MEC-Host-Verzögerung, die durch den MEC-Orchestrator verwendet wird) verfeinert oder aktualisiert werden, sodass aktuellere Messungen in Betracht gezogen werden.
  • Die aktuellen Techniken und Konfigurationen können wesentliche Vorteile für MEC-Architekturen und andere Vorrichtungsnetzwerkarchitekturen aus dem Internet-of-Things (IoT) bereitstellen, die eine beliebige Anzahl von Edge-Computing-Vorrichtungen oder Fog-Computing-Plattformen umfassen. Diese Techniken und Konfigurationen ermöglichen eine Definition von QoS/kostenbewussten Nähezonen um einen MEC-Server herum, der eine MEC-App hostet, um der MEC-App bei der Entscheidung zu helfen, ob ein Kandidaten-MEC-Dienst direkt verbraucht werden kann oder nicht. Konventionelle Einsätze von MEC-Systemen und Diensten stellen nicht die Fähigkeit bereit, flexiblen MEC-Dienstverbrauch in der echten Welt in Umgebungen mit mehreren Anbietern in Betracht zu ziehen (z. B. über verschiedene MEC-Systeme hinweg).
  • Folgende Offenbarung stellt Verbesserungen vor, die in dem ETSI-MEC-Standard umgesetzt werden können, um eine flexible Verwendung in unterschiedlichen Netzwerkeinsätzen und Szenarios zu ermöglichen. Diese Verbesserungen umfassen eine Anzahl von Definitionen von QoS/kostenbewussten Nähezonen oder anderen logischen Sammlungen von MEC-Servern und diensterzeugenden MEC-Anwendungsinstanzen. In einem Beispiel umfassen diese Techniken das Erfassen von Nähemessungen von MEC-Hosts, das Klassifizieren der Messungen nach einem Leistungs-/Kostenkriterium und das Speichern der Messungen in asynchroner Weise am MEC-Orchestrator (MEO). Diese Information ermöglicht einem Umsetzer das Erreichen eines QoS/kostengünstigen MEC-Dienstverbrauchs durch eine MEC-Anwendung, da die definierten Nähezonen mittels eines Signalisierungsprotokolls unter den beteiligten MEC-Entitäten in Betracht gezogen werden.
  • Dementsprechend können die folgenden vorgeschlagenen Techniken Vorteile bereitstellen, um Mobilnetzwerkbetreibern (MNOs) bei der Planung der Umsetzung von MEC-Hosts sowie beim Bilden von MEC-Dienstbeauftragungsrichtlinien nach einem Kostenmodell zu helfen, das mit Hilfe des vorgeschlagenen nähebewussten Dienstverbrauchsrahmenwerks strukturiert wird. Außerdem sind die Definitionen von QoS/kostenbewussten Nähezonen für Dienstverbrauch für MEC-Appentwickler (z. B. vertikale Unternehmen) nützlich, weil solche Definitionen Entwickler in die Lage versetzen, die Beliebtheit ihrer Anwendungen bei Endkunden unter QoS-Bestimmungen zu bewerten. Eine solche Entwicklung kann ausgeweitet werden, um Skalierungseffekte zu schaffen, um eine Anzahl technischer Vorteile und Nutzen innerhalb des Betriebs von Kommunikationsnetzwerken und Rechenhardware zu erlangen.
  • Folgendes stellt eine ausführliche Erklärung dieser Techniken innerhalb von MEC-Systemen und Diensten dar, die auf den größeren Zusammenhang des Internet der Dinge (IoT) und der Fog-Netzwerkeinsätze anwendbar sind. Es versteht sich, dass das offenbarte MEC-System und die Diensteinsatzbeispiele ein illustratives Beispiel einer Fogvorrichtung oder eines Fog-Systems bereitstellen, die als ein Satz eines oder mehrerer verbundener Dienste und Systeme dienen, die auf Vorrichtungen erstreckt sind, die sich am Rand eines Netzwerks befinden. Die hierin offenbarten Techniken können sich jedoch auf andere IoT-Standards und Konfigurationen sowie auf andere Zwischenverarbeitungsentitäten und -architekturen beziehen.
  • 1 illustriert eine beispielhafte Domaintopologie für jeweilige IoT-Netzwerke, die durch Verbindungen mit den jeweiligen Gateways gekoppelt sind. Das IoT ist ein Konzept, in dem eine große Anzahl von Rechenvorrichtungen miteinander und mit dem Internet verbunden sind, um eine Funktion und Datenerfassung auf sehr niedrigen Ebenen bereitzustellen. So kann eine IoT-Vorrichtung wie hierin verwendet eine halbautonome Vorrichtung sein, die eine Funktion, wie etwa unter anderem das Erkennen oder die Steuerung, in Kommunikation mit anderen IoT-Vorrichtungen und einem weiteren Netzwerk wie dem Internet ausführt.
  • Oft weisen IoT-Vorrichtungen Einschränkungen in Speicher, Größe oder Funktion auf, die für ähnliche Kosten in einer kleineren Anzahl größerer Vorrichtungen eingesetzt werden können. Eine IoT-Vorrichtung kann jedoch ein Smartphone, ein Laptop, ein Tablet oder ein PC oder eine andere größere Vorrichtung sein. Ferner kann eine IoT-Vorrichtung eine virtuelle Vorrichtung sein, wie etwa eine Anwendung auf einem Smartphone oder eine andere Rechenvorrichtung. IoT-Vorrichtungen können IoT-Gateways umfassen, die verwendet werden, IoT-Vorrichtungen für Datenspeicher, Prozesssteuerung und dergleichen mit anderen IoT-Vorrichtungen und mit Cloud-Anwendungen zu koppeln.
  • Netzwerke von IoT-Vorrichtungen können kommerzielle und Heimautomatisierungsvorrichtungen umfassen, wie etwa Wasserverteilungssysteme, elektrische Stromverteilungssysteme, Pipeline-Steuerungssysteme, Anlagensteuerungssysteme, Lichtschalter, Thermostate, Schlösser, Kameras, Wecker, Bewegungssensoren und dergleichen. Auf die IoT-Vorrichtungen kann durch externe Computer, Server und andere Systeme zugegriffen werden, etwa zum Steuern von Systemen oder Zugreifen auf Daten.
  • Das künftige Wachstum des Internets und ähnlicher Netzwerke kann sehr hohe Anzahlen von IoT-Vorrichtungen umfassen. Dementsprechend befasst sich in dem Zusammenhang der hierin besprochenen Techniken eine Anzahl der Innovationen für solche künftigen Netzwerke mit der Notwendigkeit, dass all diese Schichten ungehindert wachsen können, um verbundene Ressourcen zu finden und zugänglich zu machen, und die Fähigkeit zu unterstützen, verbundene Ressourcen zu verbergen und zu kompartmentalisieren. Eine beliebige Anzahl von Netzwerkprotokollen und Kommunikationsstandards kann verwendet werden, wobei jedes Protokoll und jeder Standard vorgesehen ist, bestimmte Ziele zu behandeln. Ferner sind die Protokolle ein Teil des Gewebes, das von für Menschen zugängliche Dienste unterstützt, die unabhängig von Ort, Zeit oder Raum laufen. Die Innovationen umfassen Diensterbringung und assoziierte Infrastruktur, wie etwa Hardware und Software; Sicherheitsverbesserungen; und die Bereitstellung von Diensten basierend auf Quality-of-Service-Bedingungen (QoS-Bedingungen), die in Dienstgüte- und Diensterbringungsvereinbarungen festgelegt sind. Wie zu verstehen ist, stellt die Verwendung von IoT-Vorrichtungen und Netzwerken, wie etwa denen, die in 1 und 2 eingeführt sind, eine Anzahl neuer Herausforderungen in einem heterogenen Netzwerk der Konnektivität dar, die eine Kombination verkabelter und drahtloser Technologien umfassen.
  • 1 stellt speziell eine vereinfachte Zeichnung einer Domaintopologie bereit, die für eine Anzahl von Internet-of-Things-Netzwerken (IoT-Netzwerken) verwendet werden kann, die IoT-Vorrichtungen 104 umfassen, wobei die IoT-Netzwerke 156, 158, 160, 162, durch Backbone-Links 102 mit jeweiligen Gateways 154 gekoppelt sind. Beispielsweise kann eine Anzahl von IoT-Vorrichtungen 104 mit einem Gateway 154, und durch das Gateway 154 miteinander kommunizieren. Um die Zeichnung zu vereinfachen, wurde nicht jede IoT-Vorrichtung 104 oder Kommunikationsverbindung (z. B. Verbindung 116, 122, 128, oder 132) beschriftet. Die Backbone-Verbindungen 102 können jede beliebige Anzahl von verkabelten oder drahtlosen Technologien umfassen, einschließlich optischer Netzwerke, und können Teil eines Local Area Network (LAN), eines Wide Area Network (WAN) oder des Internets sein. Weiterhin können solche Kommunikationsverbindungen optische Signalpfade unter IoT-Vorrichtungen 104 und Gateways 154 ermöglichen, einschließlich der Verwendung von MUXing/DeMUXing-Komponenten, die die Verbindung zwischen den verschiedenen Vorrichtungen ermöglichen.
  • Die Netzwerktopologie kann jede beliebige Anzahl von Arten von IoT-Netzwerken umfassen, wie etwa ein Mesh-Netzwerk, das mit dem Netzwerk 156 unter Verwendung von Bluetooth-Low-Energy-(BLE) Verbindungen 122 bereitgestellt wurde. Andere Arten von IoT-Netzwerken, die vorhanden sein können, umfassen ein Wireless-Local-Area-Network-Netzwerk (WLAN-Netzwerk) 158, das verwendet wird, um mit IoT-Vorrichtungen 104 durch IEEE 802.11-Verbindungen (Wi-Fi®-Verbindungen) 128 zu kommunizieren, ein zelluläres Netzwerk 160, das verwendet wird, mit IoT-Vorrichtungen 104 durch ein LTE/LTE-A- (4G) oder 5G-zelluläres Netzwerk zu kommunizieren, und ein Low-Power-Wide-Area-Netzwerk (LPWA-Netzwerk) 162, wie etwa ein LPWA-Netzwerk, das mit der LoRaWan-Vorgabe kompatibel ist, die durch die LoRa-Alliance verbreitet wird, oder ein IPv6-over-Low-Power-Wide-Area-Network-Netzwerk (LPWAN-Netzwerk), das mit einer Vorgabe kompatibel ist, die durch die Internet Engineering Task Force (IETF) verbreitet wird. Weiterhin können die jeweiligen IoT-Netzwerke mit einem externen Netzwerkanbieter (z. B. einem Tier-2- oder Tier-3-Anbieter) unter Verwendung einer beliebigen Anzahl von Kommunikationsverbindungen kommunizieren, wie etwa einer LTE-zellulären Verbindung, einer LPWA-Verbindung oder einer Verbindung basierend auf dem IEEE 802.15.4-Standard, wie etwa Zigbee®. Die jeweiligen IoT-Netzwerke können auch unter Verwendung einer Vielzahl von Netzwerk- und Internetanwendungsprotokollen wie dem Constrained Application Protocol (CoAP) funktionieren. Die jeweiligen IoT-Netzwerke können auch mit Koordinatorvorrichtungen integriert sein, die eine Kette von Verbindungen bereitstellen, die einen Clusterbaum von verbundenen Vorrichtungen und Netzwerken bildet.
  • Jedes dieser IoT-Netzwerke kann Gelegenheiten für neue technische Merkmale bereitstellen, wie etwa die hierin beschriebenen. Die verbesserten Technologien und Netzwerke können das exponentielle Wachstum von Vorrichtungen und Netzwerken ermöglichen, einschließlich der Verwendung von IoT-Netzwerken als Fogvorrichtungen oder -Systemen. Während die Nutzung solcher verbesserten Technologien zunimmt, können die IoT-Netzwerke für Selbstmanagement, funktionale Evolution und Kollaboration entwickelt werden, ohne einen direkten menschlichen Eingriff zu benötigen. Die verbesserten Technologien können sogar IoT-Netzwerke in die Lage versetzen, ohne zentralisiert gesteuerte Systeme zu funktionieren. Dementsprechend können die hierin beschriebenen verbesserten Technologien verwendet werden, um das Netzwerkmanagement und die Operationsfunktion weit über aktuelle Umsetzungen hinaus zu automatisieren und zu verbessern.
  • In einem Beispiel kann die Kommunikation zwischen IoT-Vorrichtungen 104, wie etwa über die Backbone-Verbindungen 102, durch ein dezentralisiertes „Authentication, Authorization and Accounting“-System (AAA-System) geschützt sein. In einem dezentralisierten AAA-System können verteilte Zahlungs-, Gutschrifts-, Prüf-, Autorisierungs- und Authentifizierungssysteme über verbundene heterogene Netzwerkinfrastruktur hinweg umgesetzt sein. Dies erlaubt es Systemen und Netzwerken, sich auf autonomeren Betrieb hin zu bewegen. Bei diesen Arten von autonomem Betrieb können Maschinen sogar für Personal Verträge abschließen und Partnerschaften mit anderen Maschinennetzwerken eingehen. Dies kann das Erreichen von gemeinsamen Zielen und ausgeglichene Diensterbringung im Vergleich mit beschriebenen und geplanten Dienstgütevereinbarungen erlauben und Lösungen erreichen, die Messen, Messungen, Verfolgbarkeit und Überwachbarkeit ermöglichen. Der Aufbau neuer Lieferkettenstrukturen und -verfahren kann das Erstellen einer Vielzahl von Diensten ermöglichen, deren Werte ohne menschliche Beteiligung genutzt werden und die dann eingestellt werden.
  • Solche IoT-Netzwerke können durch die Integration von Sensortechnologien, wie etwa Ton, Licht, elektronischer Traffic, Gesichts- und Mustererkennung, Geruch, Schwingungen, in die autonomen Organisationen unter den IoT-Vorrichtungen weiter verbessert werden. Die Integration sensorischer Systeme kann systematische und anonyme Kommunikation und Koordination der Dienstbereitstellung im Vergleich mit den vertraglichen Dienstzielen, Orchestrierung und quality-of-service-basiertes (QoS-basiertes) Swarming und Fusion von Ressourcen ermöglichen. Einige der einzelnen Beispiele der netzwerkbasierten Ressourcenverarbeitung umfassen folgendes.
  • Das Mesh-Netzwerk 156 kann beispielsweise durch Systeme verbessert werden, die Inline-Daten-an-Informations-Transformationen ausführen. Beispielsweise können selbstbildende Ketten von Verarbeitungsressourcen, die ein Mehrfachverbindungsnetzwerk umfassen, die effiziente Transformation von Rohdaten in Informationen, und die Fähigkeit, zwischen Vermögenswerten und Ressourcen und dem assoziierten Management jedes davon zu unterscheiden, verteilen. Weiter können die korrekten Komponenten der infrastruktur- und ressourcenbasierten Vertrauens- und Dienstindizes eingesetzt werden, um die Datenintegrität, Qualität und Sicherung zu verbessern und eine Metrik der Datenzuverlässigkeit bereitzustellen.
  • Das WLAN-Netzwerk 158 kann etwa Systeme verwenden, die Standardkonvertierung ausführen, um eine Mehrfachstandardkonnektivität bereitzustellen und IoT-Vorrichtungen 104 in die Lage zu versetzen, verschiedene Protokolle für die Kommunikation zu verwenden. Weitere Systeme können nahtlose Konnektivität über Mehrfachstandardinfrastruktur hinweg bereitstellen, die sichtbare Internetressourcen und versteckte Internetressourcen umfassen.
  • Die Kommunikation in dem zellulären Netzwerk 160 kann beispielsweise durch Systeme verbessert werden, die Daten abladen, die Kommunikation an entferntere Vorrichtungen erstrecken, oder beides. Das LPWA-Netzwerk 162 kann Systeme umfassen, die Nicht-Internet-Protocol-zu-Internet-Protocol-Verbindungen (Nicht-IP-zu-IP-Verbindungen), Adressierung und Routing ausführen. Ferner kann jede der IoT-Vorrichtungen 104 den passenden Transceiver für Wide-Area-Kommunikation mit der Vorrichtung umfassen. Ferner kann jede IoT-Vorrichtung 104 andere Transceiver umfassen, um unter Verwendung weiterer Protokolle und Frequenzen zu kommunizieren. Dies wird ferner bezüglich der Kommunikationsumgebung und Hardware einer IoT-Verarbeitungsvorrichtung erklärt, wie sie in 3 und 4 dargestellt ist.
  • Schließlicht können Cluster von IoT-Vorrichtungen ausgerüstet sein, mit anderen IoT-Vorrichtungen sowie mit einem Cloud-Netzwerk zu kommunizieren. Dies kann den IoT-Vorrichtungen erlauben, ein Ad-hoc-Netzwerk zwischen den Vorrichtungen zu bilden, sodass diese als eine einzige Vorrichtung wirken können, die als Fogvorrichtung bezeichnet werden kann. Diese Konfiguration wird mit Bezug auf 2 unten weiter beschrieben.
  • 2 illustriert ein Cloud-Computing-Netzwerk in Kommunikation mit einem Mesh-Netzwerk von IoT-Vorrichtungen (Vorrichtungen 202), die als eine Fogvorrichtung am Rand des Cloud-Computing-Netzwerks laufen. Das Mesh-Netzwerk der IoT-Vorrichtungen kann als Fog 220 bezeichnet werden, der am Rand der Cloud 200 läuft. Um das Diagramm zu vereinfachen, ist nicht jede IoT-Vorrichtung 202 beschriftet.
  • Der Fog 220 kann als ein massiv verbundenes Netzwerk betrachtet werden, wobei eine Anzahl von IoT-Vorrichtungen 202 miteinander etwa über Funkverbindungen 222 in Kommunikation stehen. Beispielsweise kann dieses verbundene Netzwerk unter Verwendung einer Verbindungsvorgabe ermöglicht werden, die durch die Open Connectivity Foundation™ (OCF) herausgegeben wurde. Dieser Standard erlaubt es Vorrichtungen, sich gegenseitig zu finden und eine Kommunikation für Verbindungen aufzubauen. Andere Verbindungsprotokolle können verwendet werden, einschließlich beispielsweise unter anderem das Optimized-Link-State-Routing-Protokoll (OLSR-Protokoll), das Better-Approach-to-Mobile-Ad-hoc-Networking-Routingprotokoll (B.A.T.M.A.N.-Routingprotokoll) oder das OMA-Lightweight-M2M-Protokoll (LWM2M-Protokoll).
  • Drei Arten von IoT-Vorrichtungen 202 sind in diesem Beispiel gezeigt: Gateways 204, Datenaggregatoren 226 und Sensoren 228, wobei jedoch Kombinationen aus IoT-Vorrichtungen 202 und Funktionen verwendet werden können. Die Gateways 204 können Edge-Vorrichtungen sein, die Kommunikationen zwischen der Cloud 200 und dem Fog 220 bereitstellen, und können auch die Backend-Prozessfunktion für Daten bereitstellen, die von Sensoren 228 erhalten wurden, wie etwa Bewegungsdaten, Ablaufdaten, Temperaturdaten und dergleichen. Die Datenaggregatoren 226 können Daten von einer beliebigen Anzahl der Sensoren 228 sammeln und die Backendverarbeitungsfunktion für die Analyse ausführen. Die Ergebnisse, Rohdaten oder beides können durch die Gateways 204 in die Cloud 200 weitergegeben werden. Die Sensoren 228 können vollständige IoT-Vorrichtungen 202 sein, die etwa in der Lage sind, Daten zu sammeln und die Daten zu verarbeiten. In einigen Fällen können die Sensoren 228 stärker in ihrer Funktion eingeschränkt sein, etwa durch Sammeln der Daten und Zulassen der Verarbeitung der Daten durch die Datenaggregatoren 226 oder Gateways 204.
  • Die Kommunikation von einer IoT-Vorrichtung 202 kann entlang eines praktischen Pfads (z. B. eines praktischsten Pfads) zwischen beliebigen der IoT-Vorrichtungen 202 weitergegeben werden, um die Gateways 204 zu erreichen. In diesen Netzwerken stellt die Anzahl der Verbindungen eine wesentliche Redundanz zur Verfügung und erlaubt den Erhalt der Kommunikation auch bei Verlust einer Anzahl von IoT-Vorrichtungen 202. Ferner kann die Verwendung eines Mesh-Netzwerks IoT-Vorrichtungen 202 erlauben, die eine sehr geringe Energie benötigen oder sich in einem Abstand von der zu verwendenden Infrastruktur befinden, da die Reichweite zum Verbinden mit einer anderen IoT-Vorrichtung 202 viel geringer sein kann als die Reichweite zum Verbinden mit den Gateways 204.
  • Der Fog 220, der von diesen IoT-Vorrichtungen 202 bereitgestellt wird, kann den Vorrichtungen in der Cloud 200, wie etwa einem Server 206, als eine einzige Vorrichtung gezeigt werden, die sich am Rand der Cloud 200 befindet, z. B. eine Fogvorrichtung. In diesem Beispiel können die Mitteilungen, die von der Fogvorrichtung gesendet werden, gesendet werden, ohne als von einer spezifischen IoT-Vorrichtung 202 in dem Fog 220 kommend identifiziert zu werden. In dieser Weise kann der Fog 220 als eine verteilte Plattform betrachtet werden, die Rechen- und Speicherressourcen bereitstellt, um Verarbeitung oder datenintensive Aufgaben bereitzustellen, wie etwa unter anderem Datenanalyse, Datenaggregation und Maschinenlernen.
  • In einigen Beispielen können die IoT-Vorrichtungen 202 unter Verwendung eines imperativen Programmierstils konfiguriert sein, wobei z. B. jede IoT-Vorrichtung 202 eine spezifische Funktion und Kommunikationspartner aufweist. Die IoT-Vorrichtungen 202, die die Fogvorrichtung bilden, können in einem deklarativen Programmierstil konfiguriert sein, was es den IoT-Vorrichtungen 202 ermöglicht, ihre Operationen und Kommunikation zu rekonfigurieren, um etwa erforderliche Ressourcen in Reaktion auf Bedingungen, Abfragen und Vorrichtungsausfälle zu bestimmen. Als ein Beispiel kann eine Abfrage von einem Benutzer, der sich an einem Server 206 befindet, über die Operationen eines Untersatzes von Ausrüstung, die durch die IoT-Vorrichtungen 202 überwacht wird, dazu führen, dass die Fogvorrichtung 220 die IoT-Vorrichtungen 202, wie etwa Partikelsensoren 228, wählt, die zum Beantworten der Abfrage notwendig sind. Die Daten von diesen 228 Sensoren können dann durch eine beliebige Kombination der Sensoren 228, Datenaggregatoren 226 oder Gateways 204 aggregiert und analysiert werden, bevor sie durch die Fogvorrichtung 220 an den Server 206 geschickt werden, um die Abfrage zu beantworten. In diesem Beispiel können IoT-Vorrichtungen 202 indem der Fog 220 die verwendeten Sensoren 228 basierend auf der Abfrage wählen, wie etwa die Addition von Daten von Durchflusssensoren oder Temperatursensoren. Ferner können, wenn ein Teil der IoT-Vorrichtungen 202 nicht betriebsfähig ist, andere IoT-Vorrichtungen 202 in der Fogvorrichtung 220 analoge Daten bereitstellen, wenn diese verfügbar sind.
  • 3 illustriert eine Zeichnung eines Cloud-Rechennetzwerks oder einer Cloud 300 in Kommunikation mit einer Anzahl von Vorrichtungen aus dem Internet of Things (IoT). Die Cloud 300 kann das Internet darstellen oder kann ein Local Area Network (LAN), oder ein Wide Area Network (WAN) sein, wie etwa ein proprietäres Netzwerk für ein Unternehmen. Die IoT-Vorrichtungen können jede beliebige Anzahl verschiedener Arten von Vorrichtungen, gruppiert in verschiedenen Kombinationen, umfassen. Beispielsweise kann eine Traffic-Steuergruppe 306 IoT-Vorrichtungen entlang von Straßen einer Stadt umfassen. Diese IoT-Vorrichtungen können Ampeln, Verkehrsflussüberwachungen, Kameras, Wettersensoren und dergleichen umfassen. Die Traffic-Steuergruppe 306 oder andere Untergruppen können mit der Cloud 300 durch verkabelte oder drahtlose Verbindungen 308 in Kommunikation stehen, wie etwa LPWA-Verbindungen, optische Verbindungen und dergleichen. Ferner kann ein verkabeltes oder drahtloses Unternetzwerk 312 den IoT-Vorrichtungen erlauben, miteinander zu kommunizieren, wie etwa durch ein Local Area Network, ein Wireless Local Area Network und dergleichen. Die IoT-Vorrichtungen können eine andere Vorrichtung, wie etwa ein Gateway 310 oder 328 verwenden, um mit externen Orten wie etwa der Cloud 300 zu kommunizieren; die IoT-Vorrichtungen können auch einen oder mehrere Server 330 verwenden, um die Kommunikation mit der Cloud 300 oder mit dem Gateway 310 zu ermöglichen. Beispielsweise können der eine oder die mehreren Server 330 als ein Zwischennetzwerkknoten dienen, um örtliche Edge-Cloud- oder Fog-Umsetzungen unter einem Local Area Network zu unterstützen. Ferner kann das Gateway 328, das dargestellt ist, in einer Cloud-to-Gateway-to-Many-Edge-Devices-Konfiguration laufen, wie indem die verschiedenen IoT-Vorrichtungen 314, 320, 324 eingeschränkt oder dynamisch für die Zuweisung und Verwendung von Ressourcen in der Cloud 300 sind.
  • Andere beispielhafte Gruppen von IoT-Vorrichtungen können unter anderem externe Wetterstationen 314, lokale Informationsterminals 316, Wecksysteme 318, Geldautomaten 320, Alarmtafeln 322 oder bewegliche Fahrzeuge umfassen, wie etwa Notfallfahrzeuge 324 oder andere Fahrzeuge 326. Jede dieser IoT-Vorrichtungen kann in Kommunikation mit anderen IoT-Vorrichtungen, mit Servern 304, mit einer anderen IoT-Fogvorrichtung oder einem -System oder einer Kombination daraus dargestellt sein. Die Gruppen der IoT-Vorrichtungen können in verschiedenen Wohnungs-, kommerziellen und industriellen Umgebungen eingesetzt werden (einschließlich in privaten und öffentlichen Umgebungen).
  • Wie in 3 zu sehen ist, kann eine große Anzahl von IoT-Vorrichtungen durch die Cloud 300 kommunizieren. Dies kann es IoT-Vorrichtungen erlauben, Informationen von anderen Vorrichtungen autonom anzufordern oder bereitzustellen. Beispielsweise kann eine Gruppe von IoT-Vorrichtungen (z. B. die Verkehrssteuerungsgruppe 306) einen aktuellen Wetterbericht von einer Gruppe externer Wetterstationen 314 anfragen, die den Wetterbericht ohne menschliche Eingriffe schicken können. Weiterhin kann ein Notfallfahrzeug 324 durch einen Geldautomaten 320 informiert werden, dass ein Raub stattfindet. Während das Notfallfahrzeug 324 zu dem Geldautomaten 320 fährt, kann es auf die Verkehrssteuerungsgruppe 306 zugreifen und freie Bahn zum Zielort anfragen, etwa indem die Ampeln auf Rot geschaltet werden, um den Verkehr an einer Kreuzung rechtzeitig zu stoppen, damit das Notfallfahrzeug 324 ungehindert Zugang zu der Kreuzung erhält.
  • Cluster von IoT-Vorrichtungen, wie etwa die externen Wetterstationen 314 oder die Verkehrssteuerungsgruppe 306, können ausgerüstet sein, um mit anderen IoT-Vorrichtungen sowie mit der Cloud 300 zu kommunizieren. Dies kann den IoT-Vorrichtungen erlauben, ein Ad-hoc-Netzwerk zwischen den Vorrichtungen zu bilden, sodass diese als eine einzige Vorrichtung wirken können, die als Fogvorrichtung oder-System (z. B. wie oben beschrieben) bezeichnet werden kann.
  • 4 ist ein Blockdiagramm eines Beispiels von Komponenten, die in einer IoT-Vorrichtung 450 vorhanden sein können, um die hierin beschriebenen Techniken umzusetzen. Die IoT-Vorrichtung 450 kann beliebige Kombinationen aus den Komponenten umfassen, die in dem Beispiel gezeigt oder in der obigen Offenbarung genannt sind. Die Komponenten können als ICs, Abschnitte davon, diskrete elektronische Vorrichtungen oder andere Module, Logik, Hardware, Software, Firmware oder eine Kombination umgesetzt sein, die in der IoT-Vorrichtung 450 angepasst sind, oder als Komponenten, die anderweitig in eine Chassis eines größeren Systems eingebaut sind. Weiterhin soll ein Blockdiagramm aus 4 eine Ansicht von Komponenten der IoT-Vorrichtung 450 auf hoher Ebene darstellen. Einige der dargestellten Komponenten können weggelassen sein, weitere Komponenten können vorhanden sein und verschiedene Anordnungen der dargestellten Komponenten können in anderen Umsetzungen auftreten.
  • Die IoT-Vorrichtung 450 kann einen Prozessor 452 umfassen, der ein Mikroprozessor, ein Mehrkernprozessor, ein Multithreaded-Prozessor, ein Ultraniedrigspannungsprozessor, ein eingebetteter Prozessor oder anderes bekanntes Prozessorelement sein kann. Der Prozessor 452 kann ein Abschnitt des Systems auf einem Chip (SoC) sein, in dem der Prozessor 452 und andere Komponenten in eine einzige integrierte Schaltung oder ein einziges Paket gebildet sind, wie etwa die Edison™- oder Galileo™-SoC-Platinen von Intel. Als ein Beispiel kann der Prozessor 452 einen auf dem Intel® Architecture Core™ basierenden Prozessor umfassen, wie etwa einen Quark™, einen Atom™, einen i3, einen i5, einen i7 oder einen MCU-Klassen-Prozessor oder einen anderen solchen Prozessor, der von der Intel® Corporation, Santa Clara, Kalifornien erhältlich ist. Eine beliebige Anzahl von anderen Prozessoren kann verwendet werden, wie sie etwa von Advanced Micro Devices, Inc. (AMD) von Sunnyvale, Kalifornien, zur Verfügung stehen, einem MIPS-basierten Design von MIPS Technologies, Inc. von Sunnyvale, Kalifornien, einem ARM-basierten Design, das von ARM Holdings, Ltd. oder einem Kunden davon lizenziert ist, oder deren Lizenznehmer oder Übernehmer. Die Prozessoren können Einheiten wie einen A5-A11-Prozessor von Apple® Inc., einen Snapdragon™-Prozessor von Qualcomm® Technologies, Inc. oder einen OMAP™-Prozessor von Texas Instruments, Inc. umfassen.
  • Der Prozessor 452 kann mit einem Systemspeicher 454 über eine Verbindung 456 (z. B. einen Bus) kommunizieren. Jede beliebige Anzahl von Speichervorrichtungen kann verwendet werden, um eine bestimmte Menge an Systemspeicher vorzusehen. Beispielsweise kann der Speicher ein Direktzugriffspeicher (RAM) nach einem Joint Electron Devices Engineering Council (JEDEC) Design sein, wie etwa die DDR- oder mobilen DDR-Standards (z. B. LPDDR, LPDDR2, LPDDR3 oder LPDDR4). In verschiedenen Umsetzungen können die einzelnen Speichervorrichtungen eine aus einer beliebigen Anzahl verschiedener Package-Typen sein, wie etwa ein Einzeldiepackage (SDP), Dualdiepackage (DDP) oder Quaddiepackage (Q17P). Diese Vorrichtungen können in einigen Beispielen direkt auf ein Motherboard gelötet werden, um eine Lösung mit einem niedrigeren Profil bereitzustellen, während die Vorrichtungen in anderen Beispielen als ein oder mehrere Speichermodule konfiguriert sind, die sich wiederum über einen bestimmten Verbinder mit dem Motherboard koppeln. Jede beliebige Anzahl anderer Speicherumsetzungen kann verwendet werden, wie etwa andere Arten von Speichermodulen, z. B. Dual Inline Memory Modules (DIMMs) anderer Varietäten, einschließlich unter anderem microDIMMs oder MiniDIMMs.
  • Um persistenten Speicher von Informationen wie Daten, Anwendungen, Betriebssysteme und so weiter bereitzustellen, kann sich ein Speicher 458 auch mit dem Prozessor 452 über die Verbindung 456 koppeln. In dem Beispiel kann der Speicher 458 über ein Solid State Disk Drive (SSDD) umgesetzt sein. Andere Vorrichtungen, die für den Speicher 458 verwendet werden, umfassen Flash-Speicherkarten wie SD-Karten, microSD-Karten, xD-Bildkarten und dergleichen sowie USB-Sticks. In Niederleistungsumsetzungen kann der Speicher 458 ein On-Die-Speicher oder Register sein, der/die mit dem Prozessor 452 assoziiert sind. In einigen Beispielen kann jedoch der Speicher 458 unter Verwendung eines Mikro-Festplattenlaufwerks (HDD) umgesetzt sein. Ferner kann eine beliebige Anzahl von neuen Technologien für den Speicher 458 neben oder statt der beschriebenen Techniken verwendet werden, wie etwa unter anderem Widerstandsänderungsspeicher, Phasenänderungsspeicher, holografische Speicher oder chemische Speicher.
  • Die Komponenten können über die Verbindung 456 kommunizieren. Die Verbindung 456 kann jede beliebige Anzahl von Technologien umfassen, einschließlich die Industriestandardarchitektur (ISA), erweiterte ISA (EISA), periphere Komponentenverbindung (PCI), periphere Komponentenverbindung erweitert (PCIx), PCI express (PCIe) oder eine beliebige Anzahl anderer Technologien. Die Verbindung 456 kann ein proprietärer Bus sein, wie er etwa in einem SoC-basierten System verwendet wird. Andere Bussysteme können umfasst sein, wie etwa unter anderem eine I2C-Schnittstelle, eine SPI-Schnittstelle, Punkt-zu-Punkt-Schnittstellen und ein Leistungsbus.
  • Die Verbindung 456 kann den Prozessor 452 mit einem Mesh-Transceiver 462 koppeln, um mit anderen Mesh-Vorrichtungen 464 zu kommunizieren. Der Mesh-Transceiver 462 kann jede beliebige Anzahl von Frequenzen und Protokollen verwenden, wie etwa 2,4-Gigahertz-Übertragungen (GHz-Übertragungen) unter dem IEEE 802.15.4-Standard, unter Verwendung des Bluetooth®-Low-Energy-Standards (BLE-Standards), der durch die Bluetooth® Special Interest Group definiert ist, oder des ZigBee®-Standards. Eine beliebige Anzahl von Funkgeräten, konfiguriert für ein bestimmtes drahtloses Kommunikationsprotokoll, können für die Verbindungen mit den Mesh-Vorrichtungen 464 verwendet werden. Beispielsweise kann eine WLAN-Einheit verwendet werden, um Wi-Fi™-Kommunikationen nach dem Standard des Institute of Electrical and Electronics Engineers (IEEE) 802.11 umzusetzen. Weiterhin können drahtlose Wide-Area-Kommunikationen, z. B. nach einem zellulären oder anderen drahtlosen Wide-Area-Protokoll über eine WWAN-Einheit auftreten.
  • Der Mesh-Transceiver 462 kann unter Verwendung mehrerer Standards oder Funkgeräte für die Kommunikation mit einer anderen Reichweite kommunizieren. Beispielsweise kann die IoT-Vorrichtung 450 mit Vorrichtungen in der Nähe, z. B. innerhalb eines Umkreises von ca. 2 Meter, unter Verwendung eines örtlichen Transceivers basierend auf BLE oder einem anderen Niedrigenergiefunkgerät kommunizieren, um Energie zu sparen. Entferntere Mesh-Vorrichtungen 464, z. B. innerhalb von ca. 50 Metern, können über ZigBee oder andere Zwischenleistungsfunkgeräte erreicht werden. Beide Kommunikationstechniken können über ein einzelnes Funkgerät bei verschiedenen Leistungsstufen stattfinden, oder sie können über separate Transceiver stattfinden, beispielsweise einen lokalen Transceiver unter Verwendung von BLE und einem separaten Mesh-Transceiver unter Verwendung von ZigBee.
  • Ein drahtloser Netzwerk-Transceiver 466 kann eingeschlossen sein, um mit Vorrichtungen oder Services in der Cloud 400 über Local- oder Wide-Area-Netzwerkprotokolle zu kommunizieren. Der drahtlose Netzwerktransceiver 466 kann ein LPWA-Transceiver sein, der unter anderem dem IEEE 802.15.4- oder IEEE 802.15.4g-Standards folgt. Die IoT-Vorrichtung 450 kann über einen großen Bereich unter Verwendung von LoRaWAN™ (Long Range Wide Area Network) kommunizieren, das von Semtech und der LoRa Alliance entwickelt wurde. Die hierin beschriebenen Techniken sind nicht auf diese Technologien beschränkt, sondern können mit jeder Anzahl anderer Cloudtransceiver verwendet werden, die Kommunikation mit großer Reichweite und geringer Bandbreite umsetzen, wie etwa Sigfox und andere Technologien. Ferner können andere Kommunikationstechniken wie Timeslotted-Kanalhopping, die in der Vorgabe IEEE 802.15.4e beschrieben sind, verwendet werden.
  • Jede Anzahl anderer Funkkommunikationen und Protokolle kann neben den Systemen verwendet werden, die für Meshtransceiver 462 und Drahtlosnetztransceiver 466 erwähnt sind, wie hierin beschrieben. Beispielsweise können die Funktransceiver 462 und 466 einen LTE- oder anderen zellulären Transceiver umfassen, der Spread-Spectrum-Kommunikation (SPA/SAS-Kommunikation) verwendet, um Hochgeschwindigkeitskommunikation umzusetzen. Ferner kann jede Anzahl anderer Protokolle verwendet werden, wie etwa Wi-Fi®-Netzwerke für Mittelgeschwindigkeitskommunikationen und Bereitstellung von Netzwerkkommunikationen.
  • Die Funktransceiver 462 und 466 können Funkgeräte umfassen, die mit jeder beliebigen Anzahl von 3GPP-Vorgaben (Third-Generation- Partnership-Project-Vorgaben) kompatibel sind, insbesondere Long Term Evolution (LTE), Long Term Evolution-Advanced (LTE-A) und Long Term Evolution-Advanced Pro (LTE-A Pro). Es kann angemerkt werden, dass Funkgeräte, die mit einer beliebigen Anzahl anderer feststehender, mobiler oder Satellitenkommunikationstechnologien und -standards kompatibel sind, gewählt werden können. Diese können beispielsweise jede Cellular-Wide-Area-Funkkommunikationstechnologie umfassen, die etwa z. B. 5th-Generation-Kommunikationssysteme (5G-Kommunikationssysteme), eine Global System for Mobile Communications-Funkkommunikationstechnologie (GSM-Funkkommunikationstechnologie), eine General Packet Radio Service-Funkkommunikationstechnologie (GPRS-Funkkommunikationstechnologie) oder eine Enhanced-Data-Rates-for-GSM-Evolution-Funkkommunikationstechnologie (EDGE-Funkkommunikationstechnologie), oder eine UMTS-Kommunikationstechnologie (Universal-Mobile-Telecommunications-System-Kommunikatonstechnologie) umfassen kann. Neben den oben aufgeführten Standards kann jede beliebige Anzahl von Satellitenuplinktechnologien für den drahtlosen Netzwerktransceiver 466 verwendet werden, einschließlich beispielsweise Funkgeräte, die Standards entsprechen, die von der ITU (International Telecommunication Union), oder dem ETSI (European Telecommunications Standards Institute) ausgegeben werden, und anderen. Die hierin bereitgestellten Beispiele sind als für verschieden andere Kommunikationstechnologien zutreffend zu verstehen, sowohl existierende und noch nicht formulierte.
  • Ein Netzwerkschnittstellencontroller (NIC) 468 kann umfasst sein, um eine verkabelte Kommunikation mit der Cloud 400 oder mit anderen Vorrichtungen bereitzustellen, wie etwa mit den Mesh-Vorrichtungen 464. Die verkabelte Kommunikation kann eine Ethernet-Verbindung darstellen oder kann auf anderen Arten von Netzwerken basieren, wie etwa einem Controller Area Network (CAN), Local Interconnect Network (LIN), DeviceNet, ControlNet, Data Highway+, PROFIBUS oder PROFINET, und vielen anderen. Ein weiterer NIC 468 kann umfasst sein, um eine Verbindung mit einem zweiten Netzwerk zu erlauben, etwa einem NIC 468, der Kommunikation mit der Cloud über Ethernet bereitstellt, und einen zweiten NIC 468, der Kommunikation mit anderen Vorrichtungen über eine andere Art von Netzwerk bereitstellt.
  • Die Verbindung 456 kann den Prozessor 452 mit einer externen Schnittstelle 470 koppeln, die verwendet wird, externe Vorrichtungen oder Untersysteme zu verbinden. Die externen Vorrichtungen können Sensoren 472, wie etwa Beschleunigungsmesser, Pegelsensoren, Durchflusssensoren, optische Lichtsensoren, Kamerasensoren, Temperatursensoren, Global Positioning System (GPS) Sensoren, Drucksensoren, barometrische Drucksensoren und dergleichen umfassen. Die externe Schnittstelle 470 kann ferner verwendet werden, um die IoT-Vorrichtung 450 mit Stellelementen 474 zu verbinden, wie Lichtschaltern, Ventilstellelementen, einen hörbaren Tongenerator, eine visuelle Warnvorrichtung und dergleichen.
  • In einigen optionalen Beispielen können verschiedene Ein-/Ausgabevorrichtungen (E/A-Vorrichtungen) in der IoT-Vorrichtung 450 vorhanden oder damit verbunden sein. Beispielsweise kann eine Anzeige oder andere Ausgabevorrichtung 484 umfasst sein, um Informationen anzuzeigen, wie etwa Sensoranzeigen oder die Stellelementposition. Eine Eingabevorrichtung 486, wie etwa ein Touchscreen oder ein Keypad, kann umfasst sein, um Eingaben anzunehmen. Eine Ausgabevorrichtung 484 kann jede Anzahl von Formen von akustischer oder optischer Anzeige umfassen, einschließlich einfache optische Ausgaben wie binäre Statusanzeigen (z. B. LEDs) und optische Multizeichenausgaben, oder komplexere Ausgaben wie etwa Anzeigebildschirme (z. B. LCD-Bildschirme), mit der Ausgabe von Zeichen, Grafiken, Multimediaobjekten und dergleichen, die aus der Operation der IoT-Vorrichtung 450 erzeugt werden.
  • Eine Batterie 476 kann die IoT-Vorrichtung 450 betreiben, wobei jedoch in Beispielen, in denen die IoT-Vorrichtung 450 an einem festen Ort montiert ist, ein Netzteil vorhanden sein kann, mit dem sie an ein Stromnetz gekoppelt ist. Die Batterie 476 kann eine Lithiumionenbatterie oder eine Metall-Luft-Batterie sein, wie etwa eine Zink-Luft-Batterie eine Aluminium-Luft-Batterie, eine Lithium-Luft-Batterie und dergleichen.
  • Ein Batteriemonitor/Ladegerät 478 kann in der IoT-Vorrichtung 450 umfasst sein, um den Ladezustand (SoCh) der Batterie 476 zu verfolgen. Der Batteriemonitor/das Ladegerät 478 kann verwendet werden, um andere Parameter der Batterie 476 zu überwachen, um Ausfallvorhersagen bereitzustellen, wie etwa zum Gesundheitszustand (SoH) und dem Funktionszustand (SoF) der Batterie 476. Der Batteriemonitor/das Ladegerät 478 kann eine integrierte Batterieüberwachungsschaltung umfassen, wie etwa eine LTC4020 oder eine LTC2990 von Linear Technologies, ein ADT7488A von ON Semiconductor aus Phoenix Arizona, oder eine IC aus der UCD90xxx-Familie des Texas Instruments aus Dallas, TX. Der Batteriemonitor/das Ladegerät 478 kann die Informationen zu der Batterie 476 über die Verbindung 456 an den Prozessor 452 kommunizieren. Der Batteriemonitor/das Ladegerät 478 kann auch einen Analog-Digital-Wandler (ADC-Wandler) umfassen, der dem Prozessor 452 erlaubt, die Spannung der Batterie 476 oder den aktuellen Fluss von der Batterie 476 direkt zu überwachen. Die Batterieparameter können verwendet werden, die Aktionen zu bestimmen, die die IoT-Vorrichtung 450 ausführen kann, wie etwa die Übertragungsfrequenz, Mesh-Netzwerkbetrieb, Sensorfrequenz und dergleichen.
  • Ein Leistungsblock 480 oder ein anderes Netzteil, das mit einem Netz gekoppelt ist, kann mit dem Batteriemonitor/Ladegerät 478 gekoppelt sein, um die Batterie 476 zu laden. In einigen Beispielen kann der Leistungsblock 480 durch einen drahtlosen Leistungsempfänger ersetzt werden, um die Leistung drahtlos zu empfangen, beispielsweise durch eine Schleifenantenne in der IoT-Vorrichtung 450. Eine drahtlose Batterieladeschaltung, wie etwa ein LTC4020-Chip von Linear Technologies aus Milpitas, Kalifornien, kann unter anderem in dem Batteriemonitor/Ladegerät 478 umfasst sein. Die spezifischen gewählten Ladeschaltungen hängen von der Größe der Batterie 476 und damit dem erforderlichen Strom ab. Das Laden kann unter anderem unter Verwendung des Airfuel-Standards ausgeführt werden, der durch die Airfuel Alliance verbreitet wird, dem Qi Wireless Charging Standard, der durch das Wireless Power Consortium verbreitet wird, oder dem Rezence Charging Standard, der durch die Alliance for Wireless Power verbreitet wird.
  • Der Speicher 458 kann Anweisungen 482 in der Form von Software, Firmware oder Hardwarebefehlen umfassen, um die hierin beschriebenen Technologien umzusetzen. Wenn auch solche Anweisungen 482 als Codeblocks gezeigt sind, die in dem Speicherplatz 454 und dem Speicher 458 umfasst sind, ist zu verstehen, dass jeder der Codeblocks beispielsweise mit fest verkabelten Schaltungen ersetzte werden kann, die in eine anwendungsspezifische integrierte Schaltung (ASIC) eingebaut sind.
  • In einem Beispiel können die Anweisungen 482, die über den Speicherlatz 454, den Speicher 458 oder den Prozessor 452 bereitgestellt sind, als nichttransitorisches, maschinenlesbares Medium 460 verkörpert sein, einschließlich Code zum Anweisen des Prozessors 452, elektronische Funktionen in der IoT-Vorrichtung 450 auszuführen. Der Prozessor 452 kann auf das nichttransitorische, maschinenlesbare Medium 460 über die Verbindung 456 zugreifen. Beispielsweise kann das nichttransitorische maschinenlesbare Medium 460 durch Vorrichtungen verkörpert sein, die für den Speicher 458 in 4 beschrieben sind, oder kann spezifische Speichereinheiten umfassen, wie etwa optische Scheiben, Flashlaufwerke oder jede beliebige Anzahl anderer Hardwarevorrichtungen. Das nichttransitorische maschinenlesbare Medium 460 kann ferner Anweisungen 488 umfassen, bereitstellen oder aufrufen den Prozessor 452 anzuweisen, eine spezifische Sequenz oder einen Ablauf von Aktionen auszuführen, beispielsweise wie bezüglich des Ablaufdiagramms/der Ablaufdiagramme und des Blockdiagramms/der Blockdiagramme der oben dargestellten Operationen und Funktionen beschrieben.
  • In einem Beispiel können die Anweisungen 488 auf dem Prozessor 452 (getrennt oder in Kombination mit den Anweisungen 488 auf dem maschinenlesbaren Medium 460) die Ausführung oder Operation einer Trusted Execution Environment (TEE) 490 konfigurieren. In einem Beispiel läuft die TEE 490 als ein geschützter Bereich, der für den Prozessor 452 zum Ermöglichen von sicherem Zugriff auf Daten und zur sicheren Ausführung von Anweisungen zugänglich ist. Verschiedene Umsetzungen der TEE 490, und ein damit verbundener sicherer Bereich in dem Prozessor 452 oder dem Speicherplatz 454 kann beispielsweise durch 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 der Sicherheitshärtung, Hardware-Wurzeln des Vertrauens und vertrauenswürdiger oder geschützter Operationen können in der Vorrichtung 450 durch die TEE 490 und den Prozessor 452 umgesetzt sein.
  • In weiteren Beispielen umfasst ein maschinenlesbares Medium auch jedes greifbare Medium, auf dem Anweisungen gespeichert, codiert oder getragen werden können, um durch eine Maschine ausgeführt zu werden, und eine Maschine veranlasst, eine oder mehrere der Methodologien dieser Offenbarung auszuführen, oder in der Lage ist, Datenstrukturen, die durch solche Anweisungen verwendet oder damit assoziiert sind, zu speichern, zu codieren oder zu tragen. Ein „maschinenlesbares Medium“ kann daher unter anderem Solid-State-Speicher und optische und magnetische Medien umfassen. Spezifische Beispiele für maschinenlesbare Medium umfassen nichtflüchtigen Speicher, einschließlich unter anderem beispielhaft Halbleiterspeichervorrichtungen (z. B. elektrisch programmierbarer Festwertspeicher (EPROM), elektrisch löschbarer programmierbarer Festwertspeicher (EEPROM)) und Flashspeichervorrichtungen; Magnetscheiben wie interne Festplatten oder Wechseldatenträger; magnetoptische Disketten; und CD-ROMs und DVD-ROMs. Die Anweisungen, die durch ein maschinenlesbares Medium verkörpert werden, können ferner über ein Kommunikationsnetzwerk unter Verwendung eines Übertragungsmediums über eine Netzwerkschnittstellenvorrichtung übertragen werden, die eines aus einer Anzahl von Übertragungsprotokollen (z. B. HTTP) verwendet.
  • Ein maschinenlesbares Medium kann durch eine Speichervorrichtung oder eine andere Vorrichtung bereitgestellt sein, die in der Lage ist, Daten in einem nichttransitorischen Format zu hosten. In einem Beispiel können Informationen, die auf dem maschinenlesbaren Medium gespeichert oder anderweitig bereitgestellt sind, Anweisungen darstellen, wie etwa Anweisungen selbst oder ein Format, aus dem die Anweisungen abgeleitet werden können. Dieses Format, von dem die Anweisungen abgeleitet werden können, kann Quellcode, codierte Anweisungen (z. B. in komprimierter oder verschlüsselter Form), gepackte Anweisungen (z. B. in mehrere Pakete aufgeteilt) oder dergleichen umfassen. Die Informationen, die die Anweisungen in dem maschinenlesbaren Medium darstellen, können durch eine Verarbeitungsschaltungsanordnung in die Anweisungen verarbeitet werden, um eine der hierin besprochenen Operationen umzusetzen. Beispielsweise kann das Ableiten der Anwendungen von der Information (z. B. Verarbeiten durch die Verarbeitungsschaltungsanordnung) umfassen: Kompilieren (z. B. von Quellcode, Objektcode usw.), Interpretieren, Laden, Organisieren (z. B. dynamisches oder statistisches Verbinden), Codieren, Decodieren, Verschlüsseln, Entschlüsseln, Packen, Entpacken oder anderweitig Manipulieren der Informationen in die Anweisungen.
  • In einem Beispiel kann die Ableitung der Anweisungen Assemblierung, Kompilierung oder Interpretation der Informationen umfassen (z. B. durch die Verarbeitungsschaltungsanordnung), um die Anweisung von einem Zwischen- oder vorverarbeiteten Format zu erstellen, das durch das maschinenlesbare Medium bereitgestellt ist. Die Informationen können bei Bereitstellung in mehreren Abschnitten kombiniert, entpackt und modifiziert werden, um die Anweisungen zu erzeugen. Beispielsweise können die Informationen in mehreren komprimierten Quellcodepaketen (oder Objektcode oder binär ausführbarem Code usw.) auf einem oder mehreren externen Servern vorliegen. Die Quellcodepakete können bei Übertragung über ein Netzwerk verschlüsselt und bei Bedarf entschlüsselt, entkomprimiert, assembliert (z. B. verbunden), wenn notwendig, und an einer örtlichen Maschine kompiliert oder interpretiert (z. B. in eine Bibliothek, eine eigenständige ausführbare Datei usw.) und durch die örtliche Maschine ausgeführt werden.
  • In verschiedenen Beispielen können die hierin beschriebenen Operationen und Funktonen durch eine Maschine oder einen Satz von Maschinen in der beispielhaften Form eines elektronischen Verarbeitungssystems verkörpert sein, innerhalb welchem ein Satz oder eine Sequenz von Anweisungen ausgeführt werden kann, um das elektronische Verarbeitungssystem zu veranlassen, jede der hierin besprochenen Methodologien nach einer beispielhaften Ausführungsform umzusetzen. Die Maschine kann eine IoT-Vorrichtung oder ein IoT-Gateway sein, einschließlich einer Maschine, die durch Aspekte eines Personal Computer (PC), eines Tablet-PC, eines Personal Digital Assistant (PDA), eines Mobiltelefons oder Smartphones verkörpert ist, oder jede Maschine, die in der Lage ist, Anweisungen (sequenziell oder anderweitig) auszuführen, die Aktionen vorgeben, die durch diese Maschine ergriffen werden. Ferner kann zwar in den obigen Beispielen nur eine einzige Maschine dargestellt und bezeichnet sein, aber eine solche Maschine umfasst auch jede Sammlung von Maschinen, die einzeln oder gemeinsam einen Satz (oder mehrere Sätze) von Anweisungen ausführen, um eine oder mehrere der hierin besprochenen Methodologien auszuführen. Ferner sollen diese und ähnliche Beispiele für ein prozessorbasiertes System jeden Satz aus einer oder mehreren Maschinen umfassen, die durch einen Prozessor (z. B. einen Computer) gesteuert oder bedient werden, um einzeln oder gemeinsam Anweisungen auszuführen, um eine oder mehrere der hierin besprochenen Methodologien auszuführen.
  • 5 illustriert ein MEC und Fog-Netzwerk nach einem. Diese Netzwerktopologie. die eine Anzahl konventioneller Netzwerkschichten umfasst, kann durch die Verwendung der hierin erklärten Tags und Objekte erweitert werden. Speziell können die Beziehungen zwischen Endpunkten (bei Endpunkt-/Dingnetzwerkschicht 550), Gateways (bei Gatewayschicht 540), Zugriffs- oder Edge-Computing-Knoten (z. B. bei Nachbarschaftsknotenschicht 530), Kernnetzwerk oder Routern (z. B. bei der regionalen oder zentralen Büroschicht 520), durch die Verwendung verbundener Objekte und Tageigenschaften dargestellt sein.
  • Ein Fog-Netzwerk (z. B. an Gateway-Schicht 540 aufgebaut) kann eine dichte geographische Verteilung von benutzernahen Edge-Vorrichtungen (z. B. Fogknoten) darstellen, die mit Speicherfähigkeiten (z. B. um die Notwendigkeit zu verringern, Daten in Clouddatenzentren zu speichern), Kommunikationsfähigkeiten (z. B. statt über das Internet-Backbone geroutet), Steuerfähigkeiten, Konfigurationsfähigkeiten, Messungs- und Managementfähigkeiten (statt vornehmlich durch Netzwerkgateways gesteuert wie denen des LTE-Kernnetzwerks), ausgerüstet sind. In diesem Zusammenhang illustriert 5 eine allgemeine Architektur, die eine Anzahl von MEC- und FOG-Knoten integriert - kategorisiert in verschiedene Schichten (basierend auf ihrer Position, Konnektivität und Verarbeitungsfähigkeiten usw.). Es versteht sich jedoch, dass solche Fog-Knoten durch Edge-Computingverarbeitungsknoten ersetzt oder augmentiert werden können.
  • Fog-Knoten können abhängig von der Topologie und der Schicht, in der sie sich befinden, kategorisiert werden. Im Gegensatz dazu kann aus Sicht des MEC-Standards jeder Fog-Knoten als ein Mobile-Edge-Host (ME-Host) oder eine einfache Entität bezeichnet werden, die eine ME-App und eine leicht gewichtete ME-Plattform hostet. In einem Beispiel kann ein MEC oder Fog-Knoten als eine Anwendungsinstanz definiert sein, die mit einer Vorrichtung (ME-Host) verbunden ist oder darauf läuft, die eine ME-Plattform hostet. Hier verbraucht die Anwendung MEC-Dienste und ist mit einem ME-Host in dem System assoziiert. Die Knoten können migriert, mit unterschiedlichen ME-Hosts assoziiert werden oder MEC-Dienste von anderen (z. B. örtlichen oder externen) ME-Plattformen verbrauchen.
  • Im Gegensatz zu diesem Ansatz sind traditionelle Client-, V2V- und andere Netzwerkanwendungen abhängig von externem Cloud-Datenspeicher und -Verarbeitung zum Austauschen und Koordinieren von Informationen. Eine Cloud-Datenanordnung erlaubt langfristige Datenerfassung und Speicherung, ist jedoch nicht optimale für stark zeitvariierende Daten, wie etwa eine Kollision, Ampeländerung usw. und kann bei dem Versuch versagen, Latenzherausforderungen zu erfüllen, wie etwa beim Anhalten eines Fahrzeugs, wenn ein Kind in die Straße läuft. Die Datenmeldungsübersetzungstechniken, die hierin besprochen werden, ermöglichen direkte Kommunikation unter Vorrichtungen (z. B. Fahrzeugen) in einer Niedriglatenzweise unter Verwendung von Merkmalen in bestehenden MEC-Diensten, die minimalen Overhead bereitstellen.
  • Abhängig von den Echtzeitanforderungen in dem anwendbaren Kommunikationszusammenhang kann eine hierarchische Struktur von Datenverarbeitungs- und Speicherknoten definiert sein. Beispielsweise betrifft dies das Einschließen örtlicher Verarbeitung mit ultraniedriger Latenz, regionaler Speicherung und Verarbeitung sowie externer cloudrechenzentrumsbasierter Speicherung und Verarbeitung. SLAs und KPIs und andere Maßnahmen, die hierin besprochen wurden, können verwendet werden, um zu identifizieren, wo Daten am besten übertragen werden und wo sie verarbeitet oder gespeichert werden. Dies ist üblicherweise abhängig von der Open-Systems-Interconnection-Schichtabhängigkeit (OSI-Schichtabhängigkeit) der Daten. Beispielsweise ändern sich Daten der unteren Schicht (PHY, MAC, Routing usw.) typischerweise schnell und werden besser lokal gehandhabt, um Latenzanforderungen zu erfüllen. Höhere Schichtdaten wie Anwendungsschichtdaten sind üblicherweise weniger zeitkritisch und werden in einem externen Cloud-Rechenzentrum verarbeitet.
  • 6 illustriert Verarbeitungs- und Speicherschichten in einem MEC und Fog-Netzwerk nach einem. Der illustrierte Datenspeicher oder die Verarbeitungshierarchie 610 relativ zu den Cloud- und Fog-/Edge-Netzwerken erlaubt eine dynamische Rekonfiguration von Elementen zum Erfüllen von Latenz- und Datenverarbeitungsparametern.
  • Die niedrigste Hierarchieebene befindet sich auf Vorrichtungsebene (z. B. am Fahrzeug). Diese Ebene speichert Daten zu vergangenen Beobachtungen, die von anderen Vorrichtungen (z. B. Fahrzeugen) empfangen wurden. Die zweite Hierarchieebene ist verteilter Speicher über mehrere Vorrichtungen (z. B. Fahrzeuge). Dieser verteilte Speicher kann sich kurzfristig abhängig von der Nähe zueinander oder zu einem Zielort (z. B. in der Nähe eines Unfalls) ändern. Die dritte Hierarchieebene befindet sich an einem örtlichen Ankerpunkt, wie etwa einer MEC-Komponente, die z. B. durch ein Fahrzeug getragen wird, um Fahrzeuge in einer Fahrzeugflotte zu koordinieren. Die vierte Ebene ist Speicher, der über MEC-Komponente hinweg geteilt wird. Beispielsweise werden Daten zwischen verschiedenen Fahrzeugflotten geteilt, die sich gegenseitig in Reichweite befinden.
  • Die fünfte Ebene der Hierarchie ist ein Speicher mit fester Infrastruktur, wie etwa in RSUs. Diese Ebene kann Daten von Entitäten auf den Hierarchieebenen 1 bis 4 aggregieren. Die sechste Ebene ist Speicher über eine feste Infrastruktur. Diese Ebene kann sich beispielsweise in dem Kernnetzwerk eines Telekommunikationsnetzwerks oder einer Unternehmenscloud befinden. Andere Typen von Schichten und Schichtverarbeitung können aus diesem Beispiel folgen.
  • 7 zeigt ein Blockdiagramm für eine beispielhafte Mehrfachzugriffs-Edge-Computing-Systemarchitektur (MEC-Systemarchitektur) 700. In einem Beispiel kann die MEC-Systemarchitektur nach einer Vorgabe, einem Standard oder einer anderen Definition definiert sein (z. B. nach der ETSI ISG MEC-003-Vorgabe). In der Referenzarchitektur, die in 7 dargestellt ist, geben die markierten Blocks betriebliche Komponenten an, die Aspekte der hier offenbarten Techniken umsetzen können.
  • Speziell zeigt 7 ein Blockdiagramm für eine beispielhafte MEC-Systemarchitektur 700, bei der eine oder mehrere der Techniken (z. B. Operationen, Prozesse, Verfahren und Methodologien), die hierin besprochen werden ausgeführt werden können. In einem Beispiel kann die MEC-Systemarchitektur nach einer Vorgabe, einem Standard oder einer anderen Definition definiert sein (z. B. nach der ETSI ISG MEC-003-Vorgabe). In diesem Diagramm beziehen sich die Referenzpunkte Mp auf die MEC-Plattformfunktion; Referenzpunkte Mm beziehen sich auf das Management; und Referenzpunkte Mx beziehen sich auf Verbindungen mit externen Entitäten. Die Dienste, Anwendungen, Orchestratoren und anderen Entitäten, die hierin besprochen werden (z. B. Merkmale von Edge-Diensten, QoS/kostenbewusste Nähezonen, MEO-Operation usw., die in 11 bis 19 erklärt sind), können in einer beliebigen Anzahl von Entitäten der MEC-Systemarchitektur umgesetzt sein, die in 7 dargestellt ist, und die Kommunikation zum Durchführen von Netzwerkoperationen kann in einer beliebigen Anzahl der Schnittstellen der MEC-Systemarchitektur durchgeführt werden, die in 7 dargestellt ist.
  • Jede der Funkverbindungen, die hierin beschrieben sind, kann nach einer oder mehreren der folgenden Funkkommunikationstechnologien und/oder Standards funktionieren, einschließlich unter anderem: eine „Global System for Mobile Communications“-Funkkommunikationstechnologie (GSM - Funkkommunikationstechnologie), eine „General Packet Radio Service“-Funkkommunikationstechnologie (GPRS-Funkkommunikationstechnologie), eine „Enhanced Data Rates for GSM Evolution“-Funkkommunikationstechnologie (EDGE-Funkkommunikationstechnologie) und/oder eine „Third Generation Partnership Project“-Funkkommunikationstechnologie (3 GPP-Funkkommunikationstechnologie), beispielsweise „Universal Mobile Telecommunications System“ (UMTS), „Freedom of Multimedia Access“ (FOMA), 3GPP „Long Term Evolution“ (LTE), 3GPP „Long Term Evolution Advanced“ (LTE Advanced), „Code Division Multiple Access 2000“ (CDMA2000), „Cellular Digital Packet Data“ (CDPD), Mobitex, „Third Generation“ (3G), „Circuit Switched Data“ (CSD), „High-Speed Circuit-Switched Data“ (HSCSD), „Universal Mobile Telecommunications System (Third Generation)“ (UMTS(3G)) „Wideband Code Division Multiple Access (Universal Mobile Telecommunications System)“ (W-CDMA (UMTS)), „High Speed Packet Access“ (HSPA), „High-Speed Downlink Packet Access“ (HSDPA), „High-Speed Uplink Packet Access“ (HSUPA), „High Speed Packet Access Plus“ (HSPA+), „Universal Mobile Telecommunications System-Time-Division Duplex“ (UMTS-TDD), „Time Division-Code Division Multiple Access“ (TD-CDMA), „Time Division-Synchronous Code Division Multiple Access“ (TD-CDMA), „3rd Generation Partnership Project Release 8 (Pre-4th Generation)“ (3GPP. Rel. 8 (Pre-4G)), 3GPP Rel. 9 (3rd Generation Partnership Project Release 9), 3GPP Rel. 10 (3rd Generation Partnership Project Release 10), 3GPP Rel. 11 (3rd Generation Partnership Project Release 11), 3GPP Rel. 12 (3rd Generation Partnership Project Release 12), 3GPP Rel. 13 (3rd Generation Partnership Project Release 13), 3GPP Rel. 14 (3rd Generation Partnership Project Release 14), 3GPP Rel. 15 (3rd Generation Partnership Project Release 15), 3GPP Rel. 16 (3rd Generation Partnership Project Release 16), 3GPP Rel. 17 (3rd Generation Partnership Project Release 17) und nachfolgende Releases (wie etwa Rel. 18, Rel. 19 usw.), 3GPP 5G, 3GPP LTE Extra, LTE-Advanced Pro, LTE „Licensed-Assisted Access“ (LAA), MuLTEfire, „UMTS Terrestrial Radio Access“ (UTRA), „Evolved UMTS Terrestrial Radio Access“ (E-UTRA), „Long Term Evolution Advanced (4th Generation)“ (LTE Advanced (4G)), cdmaOne (2G), „Code Division Multiple Access 2000 (Third Generation)“ (CDMA2000 (3G)), „Evolution-Data Optimized“ oder „Evolution-Data Only“ (EV-DO), „Advanced Mobile Phone System (Ist Generation)“ (AMPS (1G)), „Total Access Communication System/Extended Total Access Communication System“ (TACS/ETACS), „Digital AMPS (2nd Generation)“ (D-AMPS(2G)), „Push-to-Talk“ (PTT), „Mobile Telephone System“ (MTS), „Improved Mobile Telephone System“ (IMTS), „Advanced Mobile Telephone System“ (AMTS), OLT (Norwegisch für Offentlig Landmobil Telefoni, öffentliche landbasierte Mobiltechnologie), MTD (schwedische Abkürzung für Mobiltelefonisystem D oder Mobiltelephoniesystem D), „Public Automated Land Mobile“ (Autotel/PALM), ARP (Finnisch für Autoradiopuhelin, „Autoradiotelefon“), NMT (Nordic Mobile Telephony), die hochkapazitive Version von NTT (Nippon Telegraph and Telephone) (Hicap), „Cellular Digital Packet Data“ (CDPD), Mobitex, DataTAC, „Integrated Digital Enhanced Network“ (iDEN), „Personal Digital Cellular“ (PDC), „Circuit Switched Data“ (CSD), „Personal Handy-phone System“ (PHS), „Wideband Integrated Digital Enhanced Network“ (WiDEN), iBurst, „Unlizenzierte Mobile Access“ (UMA), (auch bezeichnet als 3GPP Generic Access Network oder der GAN-Standard), Zigbee, Bluetooth(r), „Wireless Gigabit Alliance“-Standard (WiGig-Standard), mmWave-Standards im Allgemeinen (Drahtlossysteme, die bei 10-300 GHz und darüber laufen, wie etwa WiGig IEEE 802.11ad, IEEE 802.11ay usw.), Technologien, die über den 300 GHz und THz-Bändern funktionieren, (3GPP/LTE-basierte oder IEEE 802.11p und andere) „Vehicle-to-Vehicle“- (V2V) und „Vehicle-to-X“- (V2X) und „Vehicle-to-Infrastructure“- (V2I) und „Infrastructure-to-Vehicle“-Kommunikationstechnologien (I2V-Kommunikationstechnologien), 3GPP zelluläre V2X, DSRC-Kommunikationssysteme (Dedicated-Short-Range-Communications-Kommunikationssysteme) wie etwa „Intelligent-TransportSystems“ und andere (die typischerweise in 5850 MHz bis 5925 Mhz laufen), das Europäische ITS-G5-System (d.h. die europäische Variante von IEEE 802.11p-basiertes DSRC, einschließlich ITS-G5A (d. h Betrieb von ITS-G5 in europäischen ITS-Frequenzbändern, die für sicherheitsbezogene Anwendungen im Frequenzbereich 5.875 GHz bis 5.905 GHz speziell für ITS vorgesehen sind), ITS-G5B (d. h. Betrieb in europäischen ITS-Frequenzbändern speziell für ITS-Nichtsicherheitsanwendungen in dem Frequenzbereich 5.855 GHz bis 5.875 GHz), ITS-G5C (d. h. Betrieb von ITS-Anwendungen im Frequenzbereich von 5.470 GHz bis 5.725 GHz)), DSRC in Japan in dem 700-MHz-Band (einschließlich 715 MHz bis 725 MHz) usw.
  • Die hier beschriebenen Techniken können auch in dem Zusammenhang eines beliebigen Spektrumverwaltungsschemas verwendet werden, einschließlich eines dedizierten lizenzierten Spektrums, eines nichtlizenzierten Spektrums, eines (lizenzierten) geteilten Spektrums (wie etwa LSA = Licensed Shared Access; lizenzierter geteilter Zugang bei 2,3-2,4 GHz, 3,4-3,6 GHz, 3,6-3,8 GHz und weiteren Frequenzen und SAS = Spectrum Access System; Spektrumszugangssystem/CBRS = Citizen Broadband Radio System bei 3,55-3,7 GHz und weiteren Frequenzen). Anwendbare Spektrumsbänder umfassen das IMT-Spektrum (International Mobile Telecommunications) sowie andere Arten von Spektren/Bändern, wie etwa Bändern mit nationaler Zuordnung (einschließlich 450 - 470 MHz, 902-928 MHz (Hinweis: Zuordnung beispielsweise in den USA (FCC Part 15)), 863-868.6 MHz (Hinweis: Zuordnung beispielsweise in der europäischen Union (ETSI EN 300 220)), 915.9-929.7 MHz (Hinweis: Zuordnung beispielsweise in Japan), 917-923.5 MHz (Hinweis: Zuordnung beispielsweise in South Korea), 755-779 MHz und 779-787 MHz (Hinweis: Zuordnung beispielsweise in China), 790 - 960 MHz, 1710 - 2025 MHz, 2110 - 2200 MHz, 2300 - 2400 MHz, 2,4-2,4835 GHz (Hinweis: dies ist ein ISM-Band mit globaler Verfügbarkeit, und wird durch die Wi-Fi-Technologiefamilie (11b/g/n/ax) und auch durch Bluetooth verwendet), 2500 - 2690 MHz, 698-790 MHz, 610 - 790 MHz, 3400 - 3600 MHz, 3400 - 3800 MHz, 3,55-3,7 GHz (Hinweis: Zuordnung beispielsweise in den USA für Citizen Broadband Radio Service), 5,15-5,25 GHz und 5,25-5,35 GHz und 5,47-5,725 GHz und 5,725-5,85 GHz-Bändern (Hinweis: Zuordnung beispielsweise in den USA (FCC Part 15), umfasst vier U-NII-Bänder in dem gesamten 500-MHz-Spektrum), 5,725-5,875 GHz (Hinweis: Zuordnung beispielsweise in der EU (ETSI EN 301 893)), 5,47-5,65 GHz (Hinweis: Zuordnung beispielsweise in South Korea, im 5925-7125 MHz- und 5925-6425-MHz-Band (Hinweis: in den USA und in der EU jeweils im Prüfstadium), IMT-Advanced Spectrum, IMT-2020-Spektrum (erwartungsgemäß die 3600-3800-MHz-, 3,5-GHz-Bänder, 700 MHz-Bänder, Bänder innerhalb des Bereichs 24,25-86 GHz usw. umfassend), ein Spektrum, das unter FCCs „Spectrum Frontier“ 5G-Initiative zur Verfügung gestellt wird (einschließlich 27,5 - 28,35 GHz, 29,1 - 29,25 GHz, 31 - 31,3 GHz, 37 - 38,6 GHz, 38,6 - 40 GHz, 42 - 42,5 GHz, 57 - 64 GHz, 71 - 76 GHz, 81 - 86 GHz und 92 - 94 GHz usw.), das ITS-Band (Intelligent Transport Systems) von 5,9 GHz (typischerweise 5,85-5,925 GHz) und 63-64 GHz, Bänder, die aktuell WiGig zugewiesen sind, wie etwa WiGig-Band 1 (57,24-59,40 GHz), WiGig-Band 2 (59,40-61,56 GHz) und WiGig Band 3 (61.56-63.72 GHz) und WiGig Band 4 (63.72-65,88 GHz), 57-64/66 GHz (z. B. mit Near-Global-Designation für Multi-Gigabit Wireless Systems (MGWS)/WiGig; in den USA (FCC Part 15) zugewiesen als vollständiges 14 GHz-Spektrum, während es in der EU (ETSI EN 302 567 und ETSI EN 301 217-2 für feste P2P) als vollständiges 9-GHz-Spektrum zugewiesen ist), das 70,2 GHz - 71 GHz-Band, jedes Band zwischen 65,88 GHz und 71 GHz, Bänder, die aktuell Automobilradaranwendungen zugewiesen sind, wie 76-81 GHz, und künftige Bänder, einschließlich 94-300 GHz und darüber. Weiterhin kann der Plan auf sekundärer Basis auf Bändern wie den TV White Space-Bändern (typischerweise unter 790 MHz) verwendet werden, wo insbesondere die 400 MHz- und 700 MHz-Bänder vielversprechende Kandidaten sind. Neben zellulären Anwendungen können spezielle Anwendungen für vertikale Märkte adressiert werden, wie etwa PMSE (Program Making and Special Events), Medizin-, Gesundheits-, Operations-, Kraftfahrzeugs-, Niederlatenz-, Drohnenanwendungen usw.
  • Hierin beschriebene Aspekte können auch eine hierarchische Anwendung des Schemas umsetzen ist möglich, z. B. durch Einführen einer hierarchischen Priorisierung der Verwendung für verschiedene Benutzertypen (z. B. niedrige/mittlere/hohe Priorität usw.), basierend auf einem priorisierten Zugriff auf das Spektrum, z. B. mit der höchsten Priorität für Benutzer auf Tier 1, gefolgt von Tier 2, dann Tier 3 usw., usw.
  • Hierin beschriebene Aspekte können auch auf unterschiedliche Single Carrier oder OFDM-Flavors (CP-OFDM, SC-FDMA, SC-OFDM, filterbankbasierte Multicarrier (FBMC), OFDMA, usw.) und insbesondere 3GPP NR (New Radio) angewendet werden, indem die OFDM-Trägerdatenbitvektoren den entsprechenden Symbolressourcen zugewiesen werden.]. Einige der Merkmale in diesem Dokument sind für die Netzwerkseite definiert, wie etwa Access Points, eNodeBs, New Radio (NR) oder Next-Generation-Node Bs (gNodeB oder gNB), wie sie etwa in dem Kontext eines 3GPP-Fifth-Generation-Kommunikationssystems (5G-Kommunikationssystem) usw. verwendet werden. Ein Benutzergerät (UE) kann jedoch diese Rolle ebenso verwenden und als ein Access Points, eNodeBs, gNodeBs usw. dienen. Dementsprechend können einige oder alle Merkmale, die für Netzwerkgeräte definiert sind, durch ein UE oder eine mobile Rechenvorrichtung umgesetzt sein.
  • In weiteren Beispielen können die vorstehenden Beispiele von Netzwerkkommunikation und Operationen (z. B. mit Edge-Geräteeinsätzen) mit IoT und ähnlichen vorrichtungsbasierten Netzwerkarchitekturen integriert sein. 17 illustriert eine beispielhafte Domaintopologie für jeweilige IoT-Netzwerke, die durch Verbindungen mit den jeweiligen Gateways gekoppelt sind. Das IoT ist ein Konzept, in dem eine große Anzahl von Rechenvorrichtungen miteinander und mit dem Internet verbunden sind, um eine Funktion und Datenerfassung auf sehr geringen Ebenen bereitzustellen. So kann eine IoT-Vorrichtung wie hierin verwendet, eine halbautonome Vorrichtung sein, die eine Funktion, wie etwa unter anderem das Erkennen oder die Steuerung, in Kommunikation mit anderen IoT-Vorrichtungen und einem weiteren Netzwerk wie dem Internet ausführt.
  • MEC und andere Edge-Computing-Nutzungsfälle wurden vorgesehen, um sich in eine Anzahl von Netzwerk- und Anwendungsumgebungen zu integrieren, einschließlich solcher, um Netzwerkanordnungen von IoT-Einsätzen zu unterstützen. IoT-Vorrichtungen sind physische oder virtualisierte Objekte, die in einem Netzwerk (typischerweise am Rand oder Endpunkt eines Netzwerks) kommunizieren können, und die Sensoren, Stellelemente und andere Ein-/Ausgabekomponenten umfassen können, wie etwa zum Erfassen von Daten oder zum Durchführen von Aktionen aus einer Umgebung in der echten Welt. Beispielsweise können IoT-Vorrichtungen Niederenergievorrichtungen umfassen, die in Alltagsgegenstände eingebettet oder daran angebracht sind, wie etwa an Gebäuden, Fahrzeugen, Verpackungen usw., um einen Sensor, Daten oder eine Verarbeitungsfunktion bereitzustellen. In letzter Zeit nahm die Beliebtheit von IoT-Vorrichtungen zu, und Anwendungen und Anwendungsfälle, die diese Vorrichtungen verwenden, haben sich daher stark verbreitet.
  • Es wurden verschiedene Standards vorgeschlagen, um IoT-Vorrichtungen und IoT-Netzwerkanwendungsfälle effektiver zu verbinden und zu betreiben, einschließlich solcher mit MEC und mobilen Netzwerkarchitekturen. Einige der relevanten Kommunikations- und Netzwerkarchitekturstandards umfassen solche, die durch Gruppen wie ETSI, 3rd Generation Partnership Project (3GPP), Institute of Electrical and Electronics Engineers (IEEE) vertrieben werden, neben spezialisierter IoT-Anwendungsinteraktionsarchitektur und Konfigurationsstandards, die durch Arbeitsgruppen wie die Open Connectivity Foundation (OCF) vertrieben werden.
  • Oft weisen IoT-Vorrichtungen Einschränkungen in Speicher, Größe oder Funktion auf, die für ähnliche Kosten in einer kleineren Anzahl größerer Vorrichtungen eingesetzt werden können. Eine IoT-Vorrichtung kann jedoch ein Smartphone, ein Laptop, ein Tablet oder ein PC oder eine andere größere Vorrichtung sein. Ferner kann eine IoT-Vorrichtung eine virtuelle Vorrichtung sein, wie etwa eine Anwendung auf einem Smartphone oder eine andere Rechenvorrichtung. IoT-Vorrichtungen können IoT-Gateways umfassen, die verwendet werden, IoT-Vorrichtungen für Datenspeicher, Prozesssteuerung und dergleichen mit anderen IoT-Vorrichtungen und mit Cloud-Anwendungen zu koppeln.
  • Netzwerke von IoT-Vorrichtungen können kommerzielle und Heimautomatisierungsvorrichtungen umfassen, wie etwa Wasserverteilungssysteme, elektrische Stromverteilungssysteme, Pipeline-Steuerungssysteme, Anlagensteuerungssysteme, Lichtschalter, Thermostate, Schlösser, Kameras, Wecker, Bewegungssensoren und dergleichen. Auf die IoT-Vorrichtungen kann durch externe Computer, Server und andere Systeme zugegriffen werden, etwa zum Steuern von Systemen oder Zugreifen auf Daten.
  • Das künftige Wachstum des Internets und ähnlicher Netzwerke kann sehr hohe Anzahlen von IoT-Vorrichtungen umfassen. Dementsprechend befasst sich in dem Zusammenhang der hierin besprochenen Techniken eine Anzahl der Innovationen für solche künftigen Netzwerke mit der Notwendigkeit, dass all diese Schichten ungehindert wachsen können, um verbundene Ressourcen zu finden und zugänglich zu machen, und die Fähigkeit zu unterstützen, verbundene Ressourcen zu verbergen und zu kompartmentalisieren. Eine beliebige Anzahl von Netzwerkprotokollen und Kommunikationsstandards kann verwendet werden, wobei jedes Protokoll und jeder Standard vorgesehen ist, bestimmte Ziele zu behandeln. Ferner sind die Protokolle ein Teil des Gewebes, das von für Menschen zugängliche Dienste unterstützt, die unabhängig von Ort, Zeit oder Raum laufen. Die Innovationen umfassen Diensterbringung und assoziierte Infrastruktur, wie etwa Hardware und Software; Sicherheitsverbesserungen; und die Bereitstellung von Diensten basierend auf QoS-Bedingungen, die in SLA- und Diensterbringungsvereinbarungen festgelegt sind. Wie zu verstehen ist, stellt die Verwendung von IoT-Vorrichtungen und Netzwerken eine Anzahl neuer Herausforderungen in einem heterogenen Netzwerk der Konnektivität dar, die eine Kombination verkabelter und drahtloser Technologien umfassen.
  • 8 illustriert ein Referenzkommunikationssystem mit MEC-Hosts. Beispielsweise ist ein 5G-Kommunikationssystem zu betrachten, das in den Elementen von 8 umgesetzt ist, mit Mehrfachzugriffs-Edge-Computing-Hosts (MEC-Hosts), die über ein geografisches Gebiet eingesetzt sind. Um der Einfachheit Willen ist zu beachten, dass 8 ein MEC-System umfasst, das aus verschiedenen MEC-Hosts zusammengesetzt ist, wobei jeder MEC-Host mit mindestens einer Basisstation (BS) (z. B. LTE eNB, 5G NB oder einem Radio Access Point (RAP)) in dem Netzwerk assoziiert ist.
  • 9 illustriert Vorrichtungen und Netzwerkentitäten in einer Mehrfachzugriffskommunikationsumgebung. 9 illustriert speziell Schichten der Kommunikation, die innerhalb der Umgebung auftreten, beginnend mit Endpunktsensoren oder Dingen 910 (z. B. Betrieb in einer IoT-Netzwerktopologie); Erhöhen der Ausreifung von Gateways (z. B. Fahrzeugen) oder Zwischenknoten 920, die die Sammlung und Verarbeitung von Daten von Endpunkten 910 ermöglichen; Erhöhen der Verarbeitungs- und Konnektivitätsausreifung für Zugriffs- oder Edge-Knoten 930 (z. B. Einheiten am Straßenrand, die als Edge-Computing-Knoten funktionieren), die durch Basisstationen (eNBs) verkörpert sein können, Roadside Access Points (RAPs) oder Roadside Units (RSUs), Knoten oder Server, und eine Erhöhung der Konnektivitäts- und Verarbeitungsausreifung mit einem Kernnetzwerk oder einer Cloudumgebung 940. In der Tat kann die Verarbeitung an dem Kernnetzwerk oder der Cloudumgebung 940 durch Netzwerkdienste verbessert werden, die durch einen externen Anwendungsserver 950 oder andere Clouddienste ausgeführt werden.
  • Wie dargestellt, kommunizieren die Endpunkte 910 in dem Szenario aus 9 verschiedene Arten von Informationen an die Gateways oder Zwischenknoten 920; durch die Mobilität der Gateways oder Zwischenknoten 920 (wie etwa in einem Fahrzeug oder einer mobilen Rechenvorrichtung) führt dies jedoch zur Verwendung von mehreren Zugriffspunkten oder Arten von Zugriffspunkten für Netzwerkzugriff, zur Verwendung mehrerer einzelner Dienste und Server für Rechenoperationen, die Verfügbarkeit mehrerer einzelner Anwendungen und Daten für die Verarbeitung, und das Anbieten mehrerer einzelner Netzwerkoperationen, wenn sich die Eigenschaften und Fähigkeiten der verfügbaren Netzwerkdienste und Netzwerkpfade ändern. Insbesondere kann die Umgebung Aspekte von Vehicle-to-Infrastructure-Diensten (V2X-Dienste), Vehicle-to-Vehicle-Diensten (V2V-Dienste) und Vehicle-to-Infrastructure-Diensten (V2I-Dienste) eines Fahrzeugbenutzergeräts (UE) oder von Menschen bedienten tragbaren UEs (z. B. mobile Smartphones und Rechenvorrichtungen), umfassen, die eine wesentliche Komplexität für Rechendienste und Netzwerkverwendung einführen.
  • 10 illustriert eine operative Anordnung 1000 von Netzwerk- und Fahrzeugbenutzerausrüstung, wobei verschiedene Ausführungsformen ausgeführt werden können. In der Anordnung 1000 kann das Fahrzeugbenutzergerät (vUE) 1010, 1020 mit einem definierten Kommunikationssystem laufen (z. B. unter Verwendung eines LTE C-V2X WWAN 1012 oder eines SRC/ETSI ITS-G5-Kommunikationsnetzwerks (WLAN) 1022 usw.). In Ausführungsformen kann eine Road Side Unit (RSU) 1032 Verarbeitungsdienste 1040 bereitstellen, durch die die vUEs 1010 und 1020 miteinander (oder mit anderen Diensten), kommunizieren, Dienste einzeln und gemeinsam ausführen oder auf ähnliche Aspekte von koordinierten oder vorrichtungsspezifischen Edge-Computing-Diensten zugreifen können. In Ausführungsformen können die Verarbeitungsdienste 1040 durch einen MEC-Host (z. B. einen ETSI-MEC-Host), eine MEC-Plattform oder eine andere MEC-Entität bereitgestellt sein, die in oder durch Hardware der RSU 1032 umgesetzt ist. In diesem Beispiel kann die RSU 1032 eine stationäre RSU sein, wie etwa eine RSU vom Typ eNB oder eine ähnliche Infrastruktur. In anderen Ausführungsformen kann die RSU 1032 eine mobile RSU oder eine RSU vom Typ UE sein, die durch ein Fahrzeug (z. B. einen LKW), einen Fußgänger oder eine andere Vorrichtung mit solchen Fähigkeiten umgesetzt sein kann. In diesen Fällen können Mobilitätsprobleme behandelt werden, um eine angemessene Funkabdeckung der jeweiligen Dienste sicherzustellen. Beispielsweise kann die Mobilität einfach als die jeweiligen vUEs 1010, 1020 Übergang von und an den Betrieb bei anderen RSUs, wie etwa RSUs 1034, 1036, und andere Netzwerkknoten, die nicht dargestellt sind, gemanagt werden.
  • Ein typischer Anwendungsfall entspricht einer MEC-Anwendung (in den folgenden Absätzen als ‚MEC-App‘ bezeichnet), die auf einem MEC-Host läuft, der MEC-Dienste verbrauchen muss, die in dem (selben) MEC-System instanziiert sind. Die abgefragten Dienste werden als im MEC-System verfügbar angenommen, aber nicht notwendigerweise als auf demselben MEC-Host laufend (in den folgenden Absätzen als ein ‚MEC-Server‘ bezeichnet).
  • Bei bestehenden Ansätzen betrachtet der ETSI-MEC-Standard (z. B. die aktuelle Version von ETSI GS MEC 011, „Mobile Edge Computing (MEC); MEC Platform Application Enablement“, Tabelle 6.2.2-1) einen Satz von Attributen des Typs ServiceInfo (d. h. der Typ, der die allgemeinen Informationen eines MEC-Diensts bereitstellt), um anzuzeigen, ob der MEC-Dienst und eine MEC-App, die sie möglicherweise verbrauchen müssen, in derselben Lokalität platziert sind oder nicht. Die relevanten Attribute (d. h. scopeOfLocality, consumedLocalOnly, isLocal) sind fett gedruckt und in TABELLE 1 unten beschrieben. Wie jedoch im nächsten Abschnitt erklärt ist, ist weder der Aufbau von Nähezonen (z. B. Werte ‚ZONE‘ oder ‚ZONE GROUP‘ des Attributs consumedLocalOnly) in dem Standard erklärt, noch sind Lösungen für eine MEC-App bereitgestellt, um eine leistungs-/kostengünstige Entscheidung dazu zu treffen, ob der MEC-Dienst verbraucht werden soll oder nicht. TABELLE 1
    Attributname Datenty p Kardinalitä t Beschreibung
    serlnstanceld String 0..1 Kennung der Dienstinstanz, die durch die MEPM/MEC-Plattform zugewiesen ist. Für die Eindeutigkeit der Kennung über das MEC-System hinweg wird das UUID-Format [i.7] empfohlen. Fehlt in POST-Anfragen und ist anderweitig vorhanden.
    serName String 1 Name des Diensts. So identifiziert der Dienst, der die MEC-Anwendung erzeugt, die von ihm produzierte Dienstinstanz.
    serCategory Category Ref 0..1 Eine Kategoriereferenz. (Die Kategorieressource wird verwendet, um Produktangebote, Dienst- und Ressourcenkandidaten in logischen Containern zu gruppieren. Kategorien können andere Kategorien und/oder Produktangebote, Ressourcen- oder Dienstkandidaten umfassen.) (siehe Hinweis 1) Für die serCategory umfassen die Beispielwerte: 1. „RNI“ 2. „Location“ 3. „Bandwidth Management“
    Version String 1 Die Version des Diensts.
    state Enum (inlined) 1 Enthält den Dienstzustand: ACTIVE, INACTIVE.
    transportId String 0..1 Kennung des durch die Plattform bereitgestellten Transports, der durch den Dienst verwendet werden soll. Gültige Kennungen können unter Verwendung des „Transportinformationsabfrage“-Verfahrens beschafft werden. Kann in POST-Anfragen verfügbar sein, um die Verwendung eines von einer Plattform bereitgestellten Transports für den Dienst bereitzustellen, und fehlt andernfalls. Siehe Hinweis 2.
    transportinfo Transpor tInfo 0..1 Informationen zu dem durch den Dienst verwendeten Transport. Kann in POST-Anfragen verfügbar sein, um die Verwendung eines von einer Anwendung bereitgestellten Transports für den Dienst bereitzustellen, und ist andernfalls vorhanden. Siehe Hinweis 2.
    Serializer Serializer Types 1 Angeben des unterstützen Serialisierungsformats des Diensts.
    scopeOfLocality Enum (inlined) 0..1 Der Umfang der Lokalität wir durch „consumedLocalOnly“ und „isLocal“ ausgedrückt. Erlaubte Werte: - MEC HOST - NFVI_POP - ZONE - ZONE_GROUP - NFVI_NODE Bei Fehlen standardmäßig MEC_ HOST. Siehe Hinweis 3.
    consumedLocalOnly Boolean 0..1 Zeigt an, ob der Dienst nur durch die MEC-Anwendungen an derselben Lokalität (wie durch scopeOfLocality) definiert, als diese Dienstinstanz verbraucht werden kann (TRUE) oder nicht (FALSE). Bei Fehlen standardmäßig TRUE.
    isLocal Boolean 0..1 Zeigt an, ob sich der Dienst an derselben Lokalität (wie durch scopeOfLocality) befindet, wie die verbrauchende MEC-Anwendung (TRUE) oder nicht (FALSE). Bei Fehlen standardmäßig TRUE. Siehe Hinweis 4.
    ANMERKUNG 1: Die Dienstkategorie kann in dem Anwendungsdeskriptor umfasst sein. Sie kann durch den Bediener oder durch den Anwendungsentwickler zugeordnet sein.
    ANMERKUNG 2: Entweder transportId oder transportInfo aber nicht beide sind in POST-Anfragen verfügbar.
    ANMERKUNG 3: Werte NFVI_POP, ZONE, ZONE _GROUP und NFVI_NODE werden verwendet, wenn die Dienstinstanz als eine VNF eingesetzt wird.
    ANMERKUNG 4: Die isLocal wird nur bei Dienstverfügbarkeitsabfrageantworten und Dienstverfügbarkeitsteilnahme-/Mitteilungsmeldungen verwendet.
  • Der Typ Serviceinfo, der im aktuellen ETSI-MEC-Standard beschrieben ist, stellt keine Details zu den Kriterien bereit, wenn MEC-App-Nähezonen aufgebaut werden. Außerdem stellt der aktuelle ETSI-MEC-Standard keine Alternativen für die MEC-App-Instanz bereit, wenn sie einen MEC-Dienst benötigt, der außerhalb seiner Lokalität instanziiert wird (d. h. ‚MEC_HOST‘, ‚NFVI_POP‘, ‚ZONE‘, ‚ZONE_GROUP‘, ‚NFVI_NODE‘).
  • 11 illustriert Nähezonen von MEC-Apps, die unter MEC-Hosts gehostet werden. Als ein Beispiel zeigt 11 einen MEC-System-Einsatz mit vier MEC-Hosts. Eine MEC-App (die MEC-Dienst 1 & MEC-Dienst 2 verbrauchen muss) wird durch den MEC-Host 1 gehostet.
  • 11 illustriert ferner eine Nähezone (äquivalent, Lokalitätsumfang) einer MEC-App, die durch MEC-Host 1 gehostet wird. Beispielsweise ist für einen MEC-Dienst 1: scopeOfLocality = ZONE 1, consumedLocalOnly = TRUE und isLocal = TRUE. Für MEC-Dienst 2: scopeOfLocality = ZONE 2, consumedLocalOnly = TRUE und isLocal = TRUE). Die Zahlen neben den Rändern der Kurve entsprechen Kosteneinheiten, die durch die MEC-App betrachtet werden, wenn sie sich entscheidet, MEC-Dienste zu verbrauchen, die die an MEC-Hosts instanziiert sind, die sich von MEC-Host 1 unterscheiden.
  • Bei konventionellen Ansätzen kann der MEC-Service 1 durch die MEC-App verbraucht werden, weil der Dienst örtlich an der MEC-App stattfindet. Auch wenn jedoch der Preis, der durch die MEC-App bezahlt wird (beispielsweise ausgedrückt in Kosten oder Latenzleistung) für den Verbrauch von MEC-Dienst 1 nur 3 Kosteneinheiten beträgt, verlangt der Verbrauch von MEC-Dienst 2 an MEC-Host 4 10 Kosteneinheiten. Unter der Annahme, dass beispielsweise die MEC-App sich nur bis zu 5 Kosteneinheiten pro MEC-Dienst ‚leistet‘, erweist sich der Verbrauch von MEC-Dienst 2 als problematisch (d. h. übermäßig teuer oder entsprechend Leistungsverringern).
  • Eine solche Situation verlangt die Notwendigkeit, mögliche MEC-App-Instanzenmigration zu betrachten, um gemeinsam die Leistung/Kostenanforderungen zu erfüllen, die durch die MEC-App den Verbrauch aller erforderlichen Dienste betreffend gestellt werden. Da sich ‚MEC-Mobilität‘ dieser Art jedoch wesentlich auf die Qualität der Erfahrung (QoE) der UE (z. B. MEC-Host 1) auswirken kann, die auf der MEC-App läuft - beispielsweise auf die Latenz zwischen dem UE und dem neuen MEC-Server, der die MEC-App-Instanz hostet - muss die Lösung sorgfältig entworfen sein, um beide Aspekte in Betracht zu ziehen, namentlich: (a) QoS mit Verweis auf die UE-to-MEC-App-Konnektivität; und (b) QoS (und Kosten), die sich auf die (logische/physische) Distanz zwischen der instanziierten MEC-App und dem benötigten MEC-Dienst beziehen. Diese Aspekte wurden durch konventionelle MEC-Umsetzungen nicht vollständig behandelt. Weiterhin gibt es in bestehenden MEC-Standards keinen Verweis auf die Möglichkeit, Dienste zu verbrauchen, die auf unterschiedlichen MEC-Systemen laufen, was grundsätzlich durch die Mp3-Schnittstelle von 5 ermöglicht wird. Zu diesem Zweck muss eine MEC-Anwendungsinstanz möglicherweise die Verfügbarkeit einer Liste von MEC-Dienstinstanzen in dem örtlichen MEC-Host oder in den örtlichen und externen MEC-Hosts (auch potenziell in unterschiedlichen MEC-Systemen) abfragen.
  • In einem ersten Aspekt können MEC-Verbesserungen verwendet werden, um eine flexible Verwendung des MEC-Plattformdienstverbrauchs örtlich oder in externen MEC-Hosts des MEC-Systems oder über verschiedene MEC-Systeme hinweg ermöglicht. In der aktuellen ETSI-MEC-011-Vorgabe (z. B. dargestellt in TABELLE 1 oben) werden viele Werte des Attributs scopeOfLocality nur verwendet, wenn die Dienstinstanz als eine VNF eingesetzt wird. Die Werte ZONE und ZONE_GROUP definieren Zonen von MEC-Hosts und können grundsätzlich auch allgemein gelten. Weiterhin gibt es in ETSI-MEC-011-Vorgabe keinen Verweis auf die Möglichkeit, Dienste zu verbrauchen, die auf unterschiedlichen MEC-Systemen laufen, was grundsätzlich durch die Mp3-Schnittstelle.
  • Auf Grundlage dieser Anordnung können Änderungen in die MEC-Vorgabe einbezogen werden, die den Umfang der Lokalität betreffen. In einem Beispiel können diese Vorgabenänderungen umfassen, den Umfang der „ZONE“ und „ZONE_GROUP“ allgemeiner zu machen, und einen Wert (MEC_SYSTEM) hinzuzufügen, der eine Kennung eines anderen MEC-Systems anzeigt. Die folgende Tabelle 2 umfasst Änderungen in Fettdruck, die angepasst werden können, solche Werte anzuzeigen: TABELLE 2
    scopeOfLocalit y Enum (inlined) 0..1 Der Umfang der Lokalität wir durch „consumedLocalOnly“ und „isLocal“ ausgedrückt.
    Erlaubte Werte:
    - MEC_SYSTEM
    - MEC_HOST
    - NFVI POP
    - ZONE
    - ZONE GROUP
    - NFVI_NODE
    Bei Fehlen standardmäßig MEC HOST.
    Siehe Hinweis 3.
    ANMERKUNG 1: Die Dienstkategorie kann in dem Anwendungsdeskriptor umfasst sein. Sie kann durch den Bediener oder durch den Anwendungsentwickler zugeordnet sein.
    ANMERKUNG 2: Entweder transportId oder transportInfo aber nicht beide sind in POST-Anfragen verfügbar.
    ANMERKUNG 3: Werte NFVI_POP und NFVI_NODE werden verwendet, wenn die Dienstinstanz als eine VNF eingesetzt wird.
    ANMERKUNG 4: Die isLocal wird nur bei Dienstverfügbarkeitsabfrageantworten und Dienstverfügbarkeitsteilnahme-/Mitteilungsmeldungen.
    ANMERKUNG 5: Der Wert MEC_SYSTEM zeigt die Kennung des MEC-Systems an, in dem der Dienst eingesetzt ist. Wenn der Dienst auf demselben MEC-System läuft wie die MEC-App, so hat er dieselbe Kennung.
  • Weiterhin muss eine MEC-Anwendungsinstanz möglicherweise die Verfügbarkeit einer Liste MEC-Serviceinstanzen in dem örtlichen MEC-Host oder in örtlichen und externen MEC-Hosts (auch potenziell in anderen MEC-Systemen) abfragen, und dazu sollten auch die verbundenen Attribute in Tabelle 6.2.2-1 des MEC 011 GS kohärent in dem GET-Verfahren (Tabelle 7.4.3.1-1 des MEC 011 GS) definiert sein. Die folgende Tabelle, TABELLE 3, umfasst fetten Text, der die Ergänzung der Werte „scope_of_locality“, „consumed_local_only“ und „is_local“ zu dieser Vorgabe anzeigt: TABELLE 3
    Name Datentyp Kardinalit ät Anmerkungen
    ser_instance_id String 0..N Eine MEC-Anwendungsinstanz kann mehrere ser_instance_ids als einen Eingabeparameter verwenden, um die Verfügbarkeit einer Liste von MEC-Dienstinstanzen abzufragen. Siehe Hinweis.
    ser_name String 0..N Eine MEC-Anwendungsinstanz kann mehrere ser_name als einen Eingabeparameter verwenden, um die Verfügbarkeit einer Liste von MEC-Dienstinstanzen abzufragen. Siehe Hinweis.
    ser_category_id String 0..1 Eine MEC-Anwendungsinstanz kann mehrere ser_category_id als einen Eingabeparameter verwenden, um die Verfügbarkeit einer Liste von MEC-Dienstinstanzen abzufragen serCategory. Siehe Hinweis.
    scope_of_locality Enum (inlined) 0..1 Eine MEC-Anwendungsinstanz kann mehrere scope_of_locality als einen Eingabeparameter verwenden, um die Verfügbarkeit einer Liste von MEC-Dienstinstanzen mit einem bestimmten Lokalitätsumfang abzufragen.
    consumed_local_only Boolean 0..1 Eine MEC-Anwendungsinstanz kann mehrere consumed_local_only als einen Eingabeparameter verwenden, um die Verfügbarkeit einer Liste von MEC-Dienstinstanzen abzufragen, die nur lokal verbraucht werden können.
    is_local Boolean 0..1 Eine MEC-Anwendungsinstanz kann mehrere is_local als einen Eingabeparameter verwenden, um die Verfügbarkeit einer Liste von MEC-Dienstinstanzen in dem örtlichen MEC-Host oder in örtlichen und externen MEC-Hosts abzufragen.
    HINWEIS: Entweder „ser_instance_id“ oder „ser_name“ oder „ser_category_id“ oder keines davon sind vorhanden.
  • Diese Werte erlauben der MEC-App-Instanz kohärent das Erfassen der benötigten Informationen und den angemessenen Verbrauch von Instanzen der MEC-Dienste in dem örtlichen MEC-Host oder sowohl in örtlichen als auch externen MEC-Hosts (auch potenziell in anderen MEC-Systemen).
  • Weiterhin umfasst der Kontext der MEC-Services implizit nicht nur MEC APIs, die in der MEC-Plattform umfasst sind, sondern auch diensterzeugende MEC-Anwendungsinstanzen. In der Tat können nach der ETSI-MEC-Architektur, MEC-Anwendungsinstanzen Diensterzeuger sein. In dem Fall können die MEC 011 GS-Vorgaben den Mechanismus der Dienstverfügbarkeitsaktualisierung und neuen Dienstregistrierung definieren, durch den autorisierte relevante Anwendungen über diese Dienstverfügbarkeiten informiert werden.
  • Als nächstes behandeln die folgenden Techniken ein Verfahren zum Definieren von QoS/kostenbewussten Nähezonen um MEC-Server herum, die MEC-Anwendungen hosten. Dies erlaubt dem MEC-System die korrekte Definition von Nähezonen basierend auf Leistungskriterien und/oder Kostenmetriken.
  • 12 illustriert eine Topologie eines MEC-Systems, das vier MEC-Hosts umfasst, nach einem Beispiel. 12 zeigt speziell eine beispielhafte Topologie eines MEC-Systems, das aus vier MEC-Hosts, innerhalb derer MEC-Plattformen unterschiedliche MEC-Dienste betreiben, einem MEC Platform Manager (MEPM), einem MEC Orchestrator (MEO), sowie den verschiedenen Schnittstellen/Verbindungen zwischen diesen Entitäten (z. B. Schnittstelle Mm3, die den MEO mit dem MEPM verbindet, Schnittstelle Mm5, die den MEPM mit der MEC-Plattform verbindet, sowie Schnittstelle Mp3, die die MEC-Hosts des Systems verbindet, zusammen mit Schnittstellen Mp1 und Mp2 innerhalb jedes MEC-Hosts) besteht.
  • Es wird angenommen, dass eine MEC-App auf dem MEC-Host # 1 läuft, der potenziell einige der MEC-Dienste 1, 2, 3 und 4 verbrauchen muss. Um den erforderlichen Aufwand zu bewerten, damit die MEC-App einen spezifischen MEC-Dienst verbrauchen kann, müssen die Nähen der MEC-Hosts # 2, 3 und 4 gemessen (unter Verwendung von MEC-Host # 1 als Referenz), nach einer Leistungs- oder Kostenmetrik berechnet und asynchron in dem MEC-System gespeichert werden.
  • Um das Verfahren fertigzustellen, kann der MEC Orchestrator (MEO) eine Tabelle aufbauen, die Zonen (d. h. Cluster von MEC-Hosts) definiert, basierend auf der akkumulierten Latenz (oder jede anderen leistungs-/kostenbasierten Utility), um den Referenz-MEC-Host zu erreichen, der die MEC-App (d. h. MEC-Host # 1 in einem Beispiel) betreibt. In der Tat ist der MEC-Orchestrator (MEO) die Entität, die für die Erfassung, Klassifizierung und Speicherung der Nähemessungen zuständig ist, da er einen allgemeinen Blick auf die MEC-Systemtopologie, die verfügbaren Ressource und die verfügbaren MEC-Dienste hat.
  • Beispielsweise stellt Tabelle 4 unten zusammen mit 13 ein Beispiel einer solchen nähenbasierten Klassifizierung bereit, die am MEO erhalten wird. Es sollte angemerkt werden, dass die Kostenwerte nur indikativ sind, sowie dass eine Nähezone, die eine Enklave (z. B. ein Untersatz) einer anderen Nähezone ist, Teil des letzteren ist. TABELLE 4
    Nähezone Mindestkosten Maximalkosten (Einheiten) MEC-Hosts der Zone
    1 0 5 1
    2 0 10 1,2,4
    3 0 Unendlich 1,2,3,4
  • Tabelle 4 definiert speziell eine beispielhafte Datenstruktur, in der MEC-Hosts eines MEC-Systems nach einem Utilitykriterium in Nähezonen klassifiziert werden. In der Referenz ist der MEC-Host # 1 dort, wo die MEC-App instanziiert ist.
  • Nähezonen können in einer Datenstruktur definiert und gespeichert sein, wie etwa mit Einträgen in einer Datenbank. Beispielsweise kann jede Nähezone unter Verwendung des Tuple Zone: {zone_id, cost_range, app_id, host_id} definiert sein, wobei zone_id eine eindeutige Kennung ist, um eine Zone zu identifizieren, cost range ein numerischer Wert ist, der die maximalen Kosten angibt, die für die Zone zulässig sind, app_id eine eindeutige Kennung für die Anwendung ist, für die die Zone gilt, und host_id die Kennung für den Host ist, auf dem der Dienst für die Anwendung von app id ausgeführt wird. Es versteht sich, dass Mindestkosten in dieser Ausführungsform immer 0 sind. In anderen Umsetzungen kann ein Wert cost_min und cost_max verwendet werden, um untere und obere Grenzwertkosten für die Zone zu definieren. Kosten können eine Abbildung der Netzwerklatenz, des Verarbeitungsoverhead, der Verarbeitungszeit, des Netzwerkdurchsatzes oder anderer Leistungsmetriken sein. Ferner verwendete dieses Beispiel eine anwendungszentrische Zone - Zonen sind spezifisch für eine Anwendung auf einem Host. In anderen Umsetzungen können Zonen als hostzentrisch ausgelegt werden, in welchem Fall das Zonentuple {zone_id, cost_range, loca_host_id, remote_host_id} sein kann, wobei local_host_id der Host ist, der die App ausführt, und remote host_id der Host ist, der den Dienst bereitstellt.
  • Um zu identifizieren, welche Dienste zu einer bestimmten Zone gehören, was eine Referenzanwendung betrifft, kann der MEO die Hosts in einem MEC-System bewerten, den Kostenwert für jeden Dienst bezüglich der Anwendung zu bestimmen. Ein Tupel Kosten: {app id, service id, cost value} kann aufgebaut werden, um die Anwendungskennung und service_id des bewerteten Diensts zu erfassen, und den cost_value für die Anwendung, die mit der app id assoziiert ist, um den Dienst mit der service id zu verbrauchen. Die app id ist die eindeutige Kennung für die Anwendung und kann mit einem bestimmten MEC-Host unter Verwendung des Tupel Host: {host_id, app_id} assoziiert sein. Die service id ist eine eindeutige Kennung für den Dienst und kann mit einem bestimmten MEC-Host unter Verwendung des Tupel Service: { service_id, host_id} assoziiert sein.
  • Die app id, service id, host id und andere Kennungen können global eindeutig (z. B. eindeutig unter allen MEC-Systemen) oder lokal eindeutig (z. B. eindeutig für das MEC-System, in dem die Hosts laufen) sein. Wenn die Kennungen nur örtliche eindeutig sind, kann ein anderer Wert sys id in dem Serviceeintrag und dem Hosteintrag erfasst sein.
  • Wenn die Kostenmetriken in den Kosteneinträgen für Dienste erfasst sind, die eine Anwendung schließlich verbrauchen kann, können die Kosteneinträge gefiltert, sortiert und gruppiert werden, um Kosteneinträge zu identifizieren, die bestimmten Grenzwerte für cost value basierend auf dem Wert cost_range des Zoneneintrags aufweisen. Die Diensteinträge werden verwendet, um den Host nachzuschlagen, der die Dienste in einem bestimmten Kostenbereich der Anwendung ausführt. Die identifizierten Kosten werden dann als Zoneneinträge hinzugefügt.
  • Zonenkarten, wie sie unter Verwendung von Zoneneinträgen und anderen Datenstrukturen dargestellt sind, können in einem MEO, MEC-Host oder anderswo in einem MEC-System gespeichert sein. MEC-Systeme können die gegenseitigen Zonenkarten speichern, um Zwischen-MEC-Systemdienstteilen zu ermöglichen.
  • 13 illustriert beispielhafte MEC-Hostnähezonen, die nach einer utilitybasierten Klassifizierung. Speziell wird in 13 die Visualisierung von MEC-Host Nähezonen (wie durch die MEC-App dargestellt) der utilitybasierten Klassifizierung von Tabelle 4 entsprechend angepasst. Wie in 13 dargestellt, gehört nur MEC-Host #1 zu Nähezone 1, wobei Nähezonen 2 und 3 andere MEC-Hosts #2, 3 und 4, deren gehostete MEC-Dienste zu höheren Kosten erreicht werden können (oder, schlimmer, etwa MEC-App-zu-Service-Latenzleistung).
  • 14 illustriert eine andere beispielhafte Nähezonenvisualisierung unter MEC-Hosts, erneut in einem Szenario, in dem MEC-Host # 1, der eine MEC-App aufweist, die Referenz ist. In 14 ermöglicht dieser Satz utilitybasierte Nähezonen, die um MEC-Host # 1 herum definiert sind, einem MEO, zu entscheiden, ob eine MEC-App-Instanz verschoben werden soll oder nicht, gemeinsam basierend auf End-to-End-QoS/Kostenanforderungen und der Notwendigkeit, spezifische MEC-Dienste zu verbrauchen.
  • In dem Beispiel aus 14 sollte der Aufbau der MEC-Nähezonen jedes Mal aktualisiert werden, wenn der MEC-Systemeinsatz (Topologie) verändert wird, beispielsweise wenn mehr MEC-Hosts über einen bestimmten Bereich eingesetzt sind (Einsatzdichte erhöht) oder außer Betrieb genommen werden und/oder wenn die physischen Schnittstellen, die die MEC-Server verbinden, aktualisiert werden. Nach der Definition von MEC Nähezonen nach QoS/kostenbasierten Kriterien stellt dieses Beispiel ein Signalisierungsprotokoll unter den verschiedenen MEC-Systementitäten vor, mit dem Ziel des Erreichens von QoS-bewussten/kostengünstigen Dienstverbrauch durch eine gegebene MEC-Anwendung, die an einem Host des fokussierten MEC-Systems instanziiert sind.
  • Die vorhandenen Techniken ermöglichen ein Signalisierungsprotokoll unter den beteiligten MEC-Entitäten für QoS/kostengünstigen MEC-Dienstverbrauch durch eine MEC-Anwendung ein, wobei die definierten Nähezonen in Betracht gezogen werden. 15 illustriert speziell eine Quality-of-Service-Zonenvirtualisierung (QoS-Zonenvirtualisierung) unter MEC-Hosts in einem Beispiel, in dem der MEC-Dienst 1 örtlich für MEC-App 1 und MEC-App 2 ist, die sie verbrauchen müssen. In diesem Beispiel können mehrere MEC-Apps denselben dienst verwenden, der sich an einem anderen MEC-Host befindet.
  • Anfangs läuft nur MEC-App 1 auf MEC-Host 3, wobei MEC-Dienst 1, verbraucht wird, der auf MEC-Host 2 instanziiert wird. Anschließend muss jedoch auch MEC-App 2, die an MEC-Host 1 instanziiert wird, MEC-Dienst 1 verbrauchen. Da dies im Rahmen der Latenz-/Kostenzone liegt, die für MEC-App 2, definiert ist, kann sie den Dienst direkt verbrauchen, ohne, dass MEC-App 2 für eine bessere Nähe verschoben werden muss.
  • 16 illustriert eine App-Migration innerhalb einer Quality-of-Service-Zonenvisualisierung (QoS-Zonenvisualisierung) unter MEC-Hosts. In dem Beispiel, das in 16 gezeigt ist, unterscheidet sich mit einer Variation der Systemtopologie die Situation von dem Szenario aus 15. Anfangs verbraucht nur MEC-App 1, die auf Host 3 läuft, MEC-Dienst 1 auf MEC-Host 4. Wenn MEC-App 2 auf MEC-Host 1 Anfragen ausführt, um MEC-Dienst 1 zu verbrauchen, muss der MEC-Orchestrator, da der Dienst für sie nicht örtlich ist (z. B. der Dienst außerhalb der Nähezone liegt) bewerten, ob eine Instanzmigration an MEC-Host 2 die Leistungs- oder Kostenanforderungen für den Verbrauch des Service zusammen mit der Leistung (z. B. Latenz) erfüllt, die durch das UE erfahren werden, wenn die MEC-Anwendungsinstanzmigration ausgeführt wird. Wenn die letztere Anforderung erfüllt ist, kann die MEC-App-Instanz an MEC-Host 2 um, und der erforderliche Dienst befindet sich daher innerhalb der Nähezone der MEC-App 2. Alternativ dazu kann Dienst 1 auf MEC-Host 2 migriert werden, wenn eine solche Verschiebung von Dienst 1 die Nähezonenanforderungen von MEC-App 1 und MEC-App 2 erfüllen würde.
  • 17 illustriert den Betrieb einer MEC-Anwendung und Diensten unter verschiedenen MEC-Hosts. Neben dem Beispiel, das in 16 gezeigt ist, und mit Konzentration auf MEC-App 2 zeigt die Meldungsablaufkurve von 17 ein Signalisierungsprotokoll unter den beteiligten MEC-Entitäten, um MEC-Dienstverbrauch basierend auf den beschriebenen QoS/kostenrelevanten Zonenkriterien zu beschreiben. Die interne Entscheidung, die durch den MEO getroffen wird, ist nicht im Standard vorgegeben, sondern basiert auf den Informationen, die von den verschiedenen MEC-Hosts in dem System beschafft werden, mit einem Ziel eines QoS/kostengünstigen MEC-Dienstverbrauchs durch MEC-App 2, unter Beachtung der definierten Nähezonen. Die letzte Meldung der Kurve ist eine MEC-Anwendungsmigrationsanzeige, wobei jedoch auch möglich ist, dass keine Migration benötigt wird. In diesem Fall ist die einfache Antwort leer (200=OK).
  • MEC-Anwendung oder Servicemigration kann auch über MEC-Systeme hinweg auftreten. Beispielsweise können MEC-Systeme, die mit verschiedenen Netzwerkbetreibern assoziiert sind, Informationen des MEC-Orchestrators, MEC-Hosts und MEC-Diensts an andere MEC-Systeme übermitteln. Diese Teilung wird verwendet, um die Effizienz der MEC-Anwendung und Diensterfahrungsqualität und QoS zu erhöhen. In diesem Fall wird der Grundsatz von MEC-as-a-service auf die Kommunikation unter allen beteiligten Entitäten angewendet.
  • Beispielsweise kann MEC-System 1 Informationen durch seinen MEO-1 offenbaren und eine MEC-Anwendung, die in MEC-System 1 läuft, kann Dienste auch in einem anderen MEC-System 2 verbrauchen, das Informationen an den MEO-1 durch seinen MEO-2 offenbart. Am Ende kann MEO-1 basierend auf dem allgemeinen Wissen über MEC-Systeme 1 und 2 bestimmen, ob eine Anwendung oder ein Dienst migriert werden soll. Die MEC-Anwendung und der MEC-Host im MEC-System 1 können eine Meldung von dem MEO-1 zum Migrieren empfangen.
  • 18 ist ein Ablaufdiagramm, das ein Verfahren zum Verwalten von Dienstverbrauch unter Verwendung von Zonen nach einem Beispiel illustriert. In 1802 wird eine Anfrage nach einer Liste von Diensten und entsprechenden Nähezonen von einer Anwendung empfangen, die auf einem Host ausgeführt wird.
  • In 1804 werden in Reaktion auf den Empfang der Anfrage nach der Liste von Diensten mehrere Hosts nach Leistungsmetriken jeweiliger Dienste abgefragt, die von den mehreren Hosts angeboten werden, wobei die jeweiligen Dienste durch die Anwendung verwendet werden, die auf dem Host ausgeführt wird.
  • In 1806 wird eine Zonenkarte aufgebaut, wobei die Zonenkarte eine Zuordnung zwischen der Anwendung und den mehreren Hosts basierend auf den Leistungsmetriken unterhält.
  • In 1808 wird die Migration der Anwendung oder eines Diensts der jeweiligen Dienste basierend auf der Zonenkarte verwaltet, um eine Quality-of-Service (QoS) der Anwendung sicherzustellen.
  • In einer Ausführungsform wird eine Zone der Zonenkarte basierend auf einer oberen Kostengrenze und einer unteren Kostengrenze erzeugt, wobei die obere Kostengrenze maximale Kosten für die Verwendung der jeweiligen Dienste durch die Anwendung darstellt. In einer weiteren Ausführungsform wird die obere Kostengrenze durch eine Grenznetzwerklatenz dargestellt. In einer verbundenen Ausführungsform wird die obere Kostengrenze durch einen Grenznetzwerkdurchsatz dargestellt. In einer anderen Ausführungsform wird die obere Kostengrenze durch eine Grenzverarbeitungsabschlusszeit dargestellt.
  • In einer Ausführungsform umfasst die Anfrage einen Eingabeparameter, um die Verfügbarkeit einer Liste von Dienstinstanzen mit einem Lokalitätsumfang abzufragen. In einer Ausführungsform umfasst die Anfrage einen Eingabeparameter, um die Verfügbarkeit einer Liste von Dienstinstanzen abzufragen, die nur lokal verbraucht werden können. In einer Ausführungsform umfasst die Anfrage einen Eingabeparameter, um die Verfügbarkeit einer Liste von Dienstinstanzen abzufragen, die auf dem Host ausgeführt werden.
  • In einer Ausführungsform umfasst die Abfrage der mehreren Hosts nach Leistungsmetriken jeweiliger Dienste, die von den mehreren Hosts angeboten werden, eine Schnittstelle mit einem zweiten MEC-System. In einer weiteren Ausführungsform umfasst das Errichten der Schnittstelle mit dem zweiten MEC-System das Übermitteln der Abfrage an einen MEC-Orchestrator des zweiten MEC-Systems, wobei der MEC-Orchestrator konfiguriert ist, Hosts in dem zweiten MEC-System nach Leistungsmetriken von Diensten abzufragen, die von den Hosts des zweiten MEC-Systems zur Verfügung stehen.
  • Die Umsetzung der vorhergehenden Techniken kann durch eine beliebige Anzahl von Vorgaben, Konfigurationen oder beispielhaften Einsätzen von Hardware und Software erreicht werden. Es sollte verstanden werden, dass die funktionalen Einheiten oder Fähigkeiten, die in dieser Spezifikation beschrieben sind, möglicherweise als Komponenten oder Module bezeichnet oder beschriftet sind, um ihre Umsetzungsunabhängigkeit genauer zu betonen. Solche Komponenten können durch jede Anzahl von Software- oder Hardwareformen umgesetzt werden. Beispielsweise kann ein Modul als Hardwareschaltung umgesetzt werden, der angepasste „Very - Large - Scale Integration“-Schaltungen (VLSI-Schaltungen) oder Gatearrays, oder Off-the-Shelf-Halbleiter wie Logikchips, Transistoren oder andere diskrete Bestandteile umfasst. Eine Komponente oder ein Modul können auch in programmierbaren Hardwarevorrichtungen umgesetzt werden, wie etwa im Feld programmierbaren Gatearrays, programmierbarer Arraylogik, programmierbaren Logikvorrichtungen oder dergleichen. Komponenten oder Module können auch in Software umgesetzt werden, um durch verschiedene Typen von Prozessoren ausgeführt zu werden. Ein identifiziertes Bauteil oder Modul von ausführbarem Code kann beispielsweise einen oder mehrere physische oder logische Blocks von Computeranweisungen umfassen, die beispielsweise als Objekt, Verfahren oder Funktion organisiert sein können. Dennoch müssen die ausführbaren Elemente eines identifizierten Bauteils oder Moduls sich nicht physisch zusammen befinden, sondern können getrennte Anweisungen umfassen, die an unterschiedlichen Orten gespeichert sind, die, wenn sie logisch verbunden werden, das Bauteile oder Modul umfassen und den angegebenen Zweck für das Bauteil oder Modul erreichen.
  • Eine Komponente oder ein Modul mit ausführbarem Code kann eine einzige Anweisung sein oder kann Anweisungen umfassen und kann sogar über mehrere verschiedene Codesegmente, unter verschiedenen Programmen und über mehrere Speichervorrichtungen und Verarbeitungssystem hinweg verteilt sein. Insbesondere können einige der beschriebenen Prozesse (wie etwa das Neuschreiben von Code und die Codeanalyse) auf einem anderen Verarbeitungssystem stattfinden (z. B. in einem Computer in einem Rechenzentrum), als auf dem, auf dem der Code eingesetzt wird (z. B. in einem Computer, der in einen Sensor oder Roboter eingebettet ist). Ähnlich können betriebliche Daten hierin innerhalb von Bestandteilen oder Modulen identifiziert und illustriert sein und können in jeder geeigneten Form verkörpert und in allen gezeigten Arten von Datenstrukturen organisiert sein. Die betrieblichen Daten können als ein einzelner Datensatz gesammelt werden oder über verschiedene Orte verteilt werden, einschließlich über verschiedene Speichervorrichtungen, und können zumindest teilweise nur als elektronische Signale oder ein System oder Netzwerk existieren. Die Komponenten oder Module können passiv oder aktiv sein, einschließlich Agenten, die bedienbar sind, gewünschte Funktonen auszuführen.
  • Weitere Beispiel der hier beschriebenen Verfahrens-, System- und Vorrichtungsausführungsformen umfassen die folgenden, nichteinschränkenden, Konfigurationen. Jedes der nichteinschränkenden Beispiele kann für sich genommen werden oder kann in jeder Permutation oder Kombination mit jedem einen oder mehreren der anderen Beispiele kombiniert werden, die nachfolgend oder anderswo in dieser Offenbarung genannt sind.
  • Weitere Beispiel der hier beschriebenen Verfahrens-, System- und Vorrichtungsausführungsformen umfassen die folgenden, nichteinschränkenden, Konfigurationen. Jedes der folgenden nichteinschränkenden Beispiele kann für sich genommen werden oder kann in jeder Permutation oder Kombination mit jedem einen oder mehreren der anderen Beispiele kombiniert werden, die nachfolgend oder anderswo in dieser Offenbarung genannt sind.
  • Beispiel 1 ist eine Vorrichtung, die als Mehrfachzugriffs-Edge-Computing-Orchestrator (MEC-Orchestrator) läuft, um den Dienstverbrauch unter Verwendung von Zonen zu verwalten, umfassend: eine Verarbeitungsschaltungsanordnung; und eine Speichervorrichtung, umfassend Anweisungen, die darin verkörpert sind, wobei die Anweisungen, die bei Ausführung durch die Verarbeitungsschaltungsanordnung die Verarbeitungsschaltungsanordnung konfigurieren, Operationen auszuführen zum: Empfangen einer Anfrage nach einer Liste von Diensten und entsprechenden Nähezonen von einer Anwendung, die auf einem Host ausgeführt wird; in Reaktion auf das Empfangen der Anfrage nach der Liste, Abfragen mehrerer Hosts nach Leistungsmetriken jeweiliger Dienste, die von den mehreren Hosts angeboten werden, wobei die jeweiligen Dienste durch die Anwendung, die auf dem Host ausgeführt wird, verwendet werden; Aufbauen einer Zonenkarte, die eine Zuordnung zwischen der Anwendung und den mehreren Hosts auf Grundlage der Leistungsmetriken unterhält; und Verwalten von Migration der Anwendung oder eines Diensts der jeweiligen Dienste basierend auf der Zonenkarte, um eine Quality-of-Service (QoS) der Anwendung sicherzustellen.
  • Beispiel 2 umfasst den Inhalt von Beispiel 1, wobei eine Zone der Zonenkarte basierend auf einer oberen Kostengrenze und einer unteren Kostengrenze erzeugt wird, wobei die obere Kostengrenze maximale Kosten für die Verwendung der jeweiligen Dienste durch die Anwendung darstellt.
  • Beispiel 3 umfasst den Inhalt von Beispiel 2, wobei die obere Kostengrenze durch eine Grenznetzwerklatenz dargestellt wird.
  • Beispiel 4 umfasst den Inhalt von Beispiel 2 bis 3, wobei die obere Kostengrenze durch einen Grenznetzwerkdurchsatz dargestellt wird.
  • Beispiel 5 umfasst den Inhalt von Beispiel 2 bis 4, wobei die obere Kostengrenze durch eine Grenzverarbeitungsabschlusszeit dargestellt wird.
  • Beispiel 6 umfasst den Inhalt von Beispiel 1 bis 5, wobei die Anfrage einen Eingabeparameter umfasst, um die Verfügbarkeit einer Liste von Dienstinstanzen mit einem Lokalitätsumfang abzufragen.
  • Beispiel 7 umfasst den Inhalt von Beispiel 1 bis 6, wobei die Anfrage einen Eingabeparameter umfasst, um die Verfügbarkeit einer Liste von Dienstinstanzen abzufragen, die nur lokal verbraucht werden können.
  • Beispiel 8 umfasst den Inhalt von Beispiel 1 bis 7, wobei die Anfrage einen Eingabeparameter umfasst, um die Verfügbarkeit einer Liste von Dienstinstanzen abzufragen, die auf dem Host ausgeführt werden.
  • Beispiel 9 umfasst den Inhalt von Beispiel 1 bis 8, wobei die Vorrichtung zur Abfrage der mehreren Hosts nach Leistungsmetriken jeweiliger Dienste, die von den mehreren Hosts angeboten werden, Operationen ausführt, um eine Schnittstelle mit einem zweiten MEC-System zu bilden.
  • Beispiel 10 umfasst den Inhalt von Beispiel 9, wobei die Vorrichtung für die Schnittstelle mit dem zweiten MEC-System Operationen zum Übertragen der Abfrage an einen MEC-Orchestrator des zweiten MEC-Systems ausführt, wobei der MEC-Orchestrator konfiguriert ist, Hosts in dem zweiten MEC-System nach Leistungsmetriken von Diensten abzufragen, die von den Hosts des zweiten MEC-Systems zur Verfügung stehen.
  • Beispiel 11 umfasst den Inhalt von Beispiel 1 bis 10, wobei die mehreren Hosts Mehrfachzugriffs-Edge-Computing-Hosts (MEC-Hosts) umfassen, die einem Standard von einer MEC-Standardfamilie des ETSI (European Telecommunications Standards Institute) entsprechend funktionieren.
  • Beispiel 12 ist ein Verfahren zum Verwalten von Dienstverbrauch unter Verwendung von Zonen, umfassend: Empfangen einer Anfrage nach einer Liste von Diensten und entsprechenden Nähezonen von einer Anwendung, die auf einem Host ausgeführt wird; in Reaktion auf das Empfangen der Anfrage nach der Liste, Abfragen mehrerer Hosts nach Leistungsmetriken jeweiliger Dienste, die von den mehreren Hosts angeboten werden, wobei die jeweiligen Dienste durch die Anwendung, die auf dem Host ausgeführt wird, verwendet werden; Aufbauen einer Zonenkarte, die eine Zuordnung zwischen der Anwendung und den mehreren Hosts auf Grundlage der Leistungsmetriken unterhält; und Verwalten von Migration der Anwendung oder eines Diensts der jeweiligen Dienste, um eine Quality-of-Service (QoS) der Anwendung sicherzustellen.
  • Beispiel 13 umfasst den Inhalt von Beispiel 12, wobei eine Zone der Zonenkarte basierend auf einer oberen Kostengrenze und einer unteren Kostengrenze erzeugt wird, wobei die obere Kostengrenze maximale Kosten für die Verwendung der jeweiligen Dienste durch die Anwendung darstellt.
  • Beispiel 14 umfasst den Inhalt von Beispiel 13, wobei die obere Kostengrenze durch eine Grenznetzwerklatenz dargestellt wird.
  • Beispiel 15 umfasst den Inhalt von Beispiel 13 bis 14, wobei die obere Kostengrenze durch einen Grenznetzwerkdurchsatz dargestellt wird.
  • Beispiel 16 umfasst den Inhalt von Beispiel 13 bis 15, wobei die obere Kostengrenze durch eine Grenzverarbeitungsabschlusszeit dargestellt wird.
  • Beispiel 17 umfasst den Inhalt von Beispiel 12 bis 16, wobei die Anfrage einen Eingabeparameter umfasst, um die Verfügbarkeit einer Liste von Dienstinstanzen mit einem bestimmten Lokalitätsumfang abzufragen.
  • Beispiel 18 umfasst den Inhalt von Beispiel 12 bis 17, wobei die Anfrage einen Eingabeparameter umfasst, um die Verfügbarkeit einer Liste von Dienstinstanzen abzufragen, die nur lokal verbraucht werden können.
  • Beispiel 19 umfasst den Inhalt von Beispiel 12 bis 18, wobei die Anfrage einen Eingabeparameter umfasst, um die Verfügbarkeit einer Liste von Dienstinstanzen abzufragen, die auf dem Host ausgeführt werden.
  • Beispiel 20 umfasst den Inhalt von Beispiel 12 bis 19, wobei das Abfragen der mehreren Hosts nach Leistungsmetriken jeweiliger Dienste, die von den mehreren Hosts angeboten werden, eine Schnittstelle mit einem zweiten MEC-System umfasst.
  • Beispiel 21 umfasst den Inhalt von Beispiel 20, wobei das Errichten der Schnittstelle mit dem zweiten MEC-System das Übertragen der Abfrage an einen MEC-Orchestrator des zweiten MEC-Systems umfasst, wobei der MEC-Orchestrator konfiguriert ist, Hosts in dem zweiten MEC-System nach Leistungsmetriken von Diensten abzufragen, die von den Hosts des zweiten MEC-Systems zur Verfügung stehen.
  • Beispiel 22 umfasst den Inhalt von Beispiel 12 bis 21, wobei die mehreren Hosts Mehrfachzugriffs-Edge-Computing-Hosts (MEC-Hosts) umfassen, die einem Standard von einer MEC-Standardfamilie des ETSI (European Telecommunications Standards Institute) entsprechend funktionieren.
  • Beispiel 23 ist mindestens ein maschinenlesbares Medium, das Anweisungen umfasst, die bei Ausführung durch eine Maschine die Maschine veranlassen, Operationen eines der Verfahren aus den Beispielen 12 bis 22 auszuführen.
  • Beispiel 24 ist eine Vorrichtung, die Mittel umfasst, um eines der Verfahren aus Beispiel 12 bis 22 auszuführen.
  • Beispiel 25 ist eine Vorrichtung zum Verwalten von Dienstverbrauch unter Verwendung von Zonen, umfassend: Mittel zum Empfangen einer Anfrage nach einer Liste von Diensten und entsprechenden Nähezonen von einer Anwendung, die auf einem Host ausgeführt wird; in Reaktion auf das Empfangen der Anfrage nach der Liste, Abfragen mehrerer Hosts nach Leistungsmetriken jeweiliger Dienste, die von den mehreren Hosts angeboten werden, wobei die jeweiligen Dienste durch die Anwendung, die auf dem Host ausgeführt wird, verwendet werden; Mittel zum Aufbauen einer Zonenkarte, die eine Zuordnung zwischen der Anwendung und den mehreren Hosts auf Grundlage der Leistungsmetriken unterhält; und Mittel zum Verwalten von Migration der Anwendung oder eines Diensts der jeweiligen Dienste, um eine Quality-of-Service (QoS) der Anwendung sicherzustellen.
  • Beispiel 26 umfasst den Inhalt von Beispiel 25, wobei eine Zone der Zonenkarte basierend auf einer oberen Kostengrenze und einer unteren Kostengrenze erzeugt wird, wobei die obere Kostengrenze maximale Kosten für die Verwendung der jeweiligen Dienste durch die Anwendung darstellt.
  • Beispiel 27 umfasst den Inhalt von Beispiel 26, wobei die obere Kostengrenze durch eine Grenznetzwerklatenz dargestellt wird.
  • Beispiel 28 umfasst den Inhalt von Beispiel 26 bis 27, wobei die obere Kostengrenze durch einen Grenznetzwerkdurchsatz dargestellt wird.
  • Beispiel 29 umfasst den Inhalt von Beispiel 26 bis 28, wobei die obere Kostengrenze durch eine Grenzverarbeitungsabschlusszeit dargestellt wird.
  • Beispiel 30 umfasst den Inhalt von Beispiel 25 bis 29, wobei die Anfrage einen Eingabeparameter umfasst, um die Verfügbarkeit einer Liste von Dienstinstanzen mit einem bestimmten Lokalitätsumfang abzufragen.
  • Beispiel 31 umfasst den Inhalt von Beispiel 25 bis 30, wobei die Anfrage einen Eingabeparameter umfasst, um die Verfügbarkeit einer Liste von Dienstinstanzen abzufragen, die nur lokal verbraucht werden können.
  • Beispiel 32 umfasst den Inhalt von Beispiel 25 bis 31, wobei die Anfrage einen Eingabeparameter umfasst, um die Verfügbarkeit einer Liste von Dienstinstanzen abzufragen, die auf dem Host ausgeführt werden.
  • Beispiel 33 umfasst den Inhalt von Beispiel 25 bis 32, wobei das Mittel zum Abfragen der mehreren Hosts nach Leistungsmetriken jeweiliger Dienste, die von den mehreren Hosts angeboten werden, Mittel für eine Schnittstelle mit einem zweiten MEC-System umfasst.
  • Beispiel 34 umfasst den Inhalt von Beispiel 33, wobei das Mittel für die Schnittstelle mit dem zweiten MEC-System ein Mittel zum Übertragen der Abfrage an einen MEC-Orchestrator des zweiten MEC-Systems umfasst, wobei der MEC-Orchestrator konfiguriert ist, Hosts in dem zweiten MEC-System nach Leistungsmetriken von Diensten abzufragen, die von den Hosts des zweiten MEC-Systems zur Verfügung stehen.
  • Beispiel 35 umfasst den Inhalt von Beispiel 25 bis 34, wobei die mehreren Hosts Mehrfachzugriffs-Edge-Computing-Hosts (MEC-Hosts) umfassen, die einem Standard von einer MEC-Standardfamilie des ETSI (European Telecommunications Standards Institute) entsprechend funktionieren.
  • Beispiel 36 ist mindestens ein maschinenlesbares Medium, umfassend Anweisungen zum Verwalten von Dienstverbrauch unter Verwendung von Zonen, wobei die Anweisungen bei Ausführung durch eine Maschine die Maschine veranlassen, die Operationen auszuführen, umfassend: Empfangen einer Anfrage nach einer Liste von Diensten und entsprechenden Nähezonen von einer Anwendung, die auf einem Host ausgeführt wird; in Reaktion auf das Empfangen der Anfrage nach der Liste, Abfragen mehrerer Hosts nach Leistungsmetriken jeweiliger Dienste, die von den mehreren Hosts angeboten werden, wobei die jeweiligen Dienste durch die Anwendung, die auf dem Host ausgeführt wird, verwendet werden; Aufbauen einer Zonenkarte, die eine Zuordnung zwischen der Anwendung und den mehreren Hosts auf Grundlage der Leistungsmetriken unterhält; und Verwalten von Migration der Anwendung oder eines Diensts der jeweiligen Dienste, um eine Quality-of-Service (QoS) der Anwendung sicherzustellen.
  • Beispiel 37 umfasst den Inhalt von Beispiel 36, wobei eine Zone der Zonenkarte basierend auf einer oberen Kostengrenze und einer unteren Kostengrenze erzeugt wird, wobei die obere Kostengrenze maximale Kosten für die Verwendung der jeweiligen Dienste durch die Anwendung darstellt.
  • Beispiel 38 umfasst den Inhalt von Beispiel 37, wobei die obere Kostengrenze durch eine Grenznetzwerklatenz dargestellt wird.
  • Beispiel 39 umfasst den Inhalt von Beispiel 37 bis 38, wobei die obere Kostengrenze durch einen Grenznetzwerkdurchsatz dargestellt wird.
  • Beispiel 40 umfasst den Inhalt von Beispiel 37 bis 39, wobei die obere Kostengrenze durch eine Grenzverarbeitungsabschlusszeit dargestellt wird.
  • Beispiel 41 umfasst den Inhalt von Beispiel 36 bis 40, wobei die Anfrage einen Eingabeparameter umfasst, um die Verfügbarkeit einer Liste von Dienstinstanzen mit einem bestimmten Lokalitätsumfang abzufragen.
  • Beispiel 42 umfasst den Inhalt von Beispiel 36 bis 41, wobei die Anfrage einen Eingabeparameter umfasst, um die Verfügbarkeit einer Liste von Dienstinstanzen abzufragen, die nur lokal verbraucht werden können.
  • Beispiel 43 umfasst den Inhalt von Beispiel 36 bis 42, wobei die Anfrage einen Eingabeparameter umfasst, um die Verfügbarkeit einer Liste von Dienstinstanzen abzufragen, die auf dem Host ausgeführt werden.
  • Beispiel 44 umfasst den Inhalt von Beispiel 36 bis 43, wobei das Abfragen der mehreren Hosts nach Leistungsmetriken jeweiliger Dienste, die von den mehreren Hosts angeboten werden, eine Schnittstelle mit einem zweiten MEC-System umfasst.
  • Beispiel 45 umfasst den Inhalt von Beispiel 44, wobei das Errichten der Schnittstelle mit dem zweiten MEC-System das Übertragen der Abfrage an einen MEC-Orchestrator des zweiten MEC-Systems umfasst, wobei der MEC-Orchestrator konfiguriert ist, Hosts in dem zweiten MEC-System nach Leistungsmetriken von Diensten abzufragen, die von den Hosts des zweiten MEC-Systems zur Verfügung stehen.
  • Beispiel 46 umfasst den Inhalt von Beispiel 36 bis 45, wobei die mehreren Hosts Mehrfachzugriffs-Edge-Computing-Hosts (MEC-Hosts) umfassen, die einem Standard von einer MEC-Standardfamilie des ETSI (European Telecommunications Standards Institute) entsprechend funktionieren.
  • Beispiel 47 ist mindestens ein maschinenlesbares Medium umfassend Anweisungen, die bei Ausführung durch einen Verarbeitungsschaltkreis veranlassen, dass der Verarbeitungsschaltkreis Operationen zum Implementieren eines beliebigen der Beispiele 1 bis 46 durchführt.
  • Beispiel 48 ist eine Vorrichtung, die Mittel zum Implementieren eines beliebigen der Beispiele 1 bis 46 umfasst.
  • Beispiel 49 ist ein System zum Umsetzen eines der Beispiele 1 bis 46.
  • Beispiel 50 ist ein Verfahren zum Umsetzen eines der Beispiele 1 bis 46.
  • Beispiel 47 kann ein oder mehrere nichttransitorische computerlesbare Medium umfassen, die Anweisungen umfassen, die eine elektronische Vorrichtung veranlassen, bei Ausführung der Anweisungen durch einen oder mehrere Prozessoren der elektronischen Vorrichtung ein oder mehrere Elemente eines Verfahrens auszuführen, das in einem der Beispiele 1 bis 46 beschrieben oder damit verbunden ist, oder ein anderes Verfahren oder ein Prozess, der hierin beschrieben ist.
  • Beispiel 48 kann eine Vorrichtung umfassen, die Logik, Module oder eine Schaltungsanordnung umfasst, um ein oder mehrere Elemente eines Verfahrens auszuführen, das in einem der Beispiele 1 bis 46 beschrieben oder damit verbunden ist, oder ein anderes Verfahren oder ein Prozess, das/der hierin beschrieben ist.
  • Beispiel 49 kann ein Verfahren, eine Technik oder einen Prozess umfassen, wie in einem der Beispiele 1 bis 46 beschrieben oder damit verbunden, oder Abschnitte oder Teile davon.
  • Beispiel 50 kann eine Vorrichtung umfassen, die umfasst: einen oder mehrere Prozessoren und ein oder mehrere computerlesbare Medien, die Anweisungen umfassen, die bei Ausführung durch den einen oder die mehreren Prozessoren den einen oder die mehreren Prozessoren veranlassen, das Verfahren, die Techniken oder den Prozess wie in einem der Beispiele 1 bis 46 beschrieben oder damit verbunden auszuführen.
  • Beispiel 51 kann ein Signal wie in einem der Beispiele 1 bis 46 beschrieben oder damit verbunden, oder Abschnitte oder Teile davon umfassen.
  • Beispiel 52 kann ein Signal in einem Drahtlosnetzwerk wie in einem der Beispiele 1 bis 46 beschrieben oder damit verbunden, oder wie anderweitig hierin dargestellt und beschrieben umfassen.
  • Beispiel 53 kann ein Verfahren der Kommunikation in einem Drahtlosnetzwerk umfassen, wie in einem der Beispiele 1 bis 46 beschrieben oder damit verbunden oder wie anderweitig hierin dargestellt oder beschrieben.
  • Beispiel 54 kann ein System zum Bereitstellen von drahtloser Kommunikation wie in einem der Beispiele 1 bis 46 beschrieben oder damit verbunden, oder wie anderweitig hierin dargestellt oder beschrieben umfassen.
  • Beispiel 55 kann eine Vorrichtung zum Bereitstellen von drahtloser Kommunikation wie in einem der Beispiele 1 bis 46 beschrieben oder damit verbunden, oder wie anderweitig hierin dargestellt und beschrieben umfassen.
  • Beispiel 56 ist ein Netzwerk, das jeweilige Vorrichtungen und Vorrichtungskommunikationsmedien umfasst, um eine der Operationen aus Beispielen 1 bis 46 oder wie anderweitig hierin dargestellt und beschrieben auszuführen.
  • Beispiel 57 ist eine 4G/5G-Kommunikationsnetzwerktopologie, wobei die Netzwerktopologie jeweilige Kommunikationsverbindungen umfasst, die angepasst sind, Kommunikationen für die Operationen eines der Beispiele 1 bis 46, oder wie anderweitig hierin dargestellt oder beschrieben auszuführen.
  • Beispiel 58 ist eine Edge-Cloud-Rechenvorrichtungsumsetzung, umfassend Prozessorknoten und Recheneinheiten, die zum Ausführen der Operationen aus Beispielen 1 bis 46 oder wie anderweitig hierin dargestellt und beschrieben angepasst sind.
  • Beispiel 59 ist eine ETSI-MEC-Systemumsetzung, die Vorrichtungen, Verarbeitungskosten und Recheneinheiten umfasst, die angepasst sind, eine der Operationen aus Beispielen 1 bis 46 oder wie anderweitig hierin dargestellt oder beschrieben auszuführen.
  • Beispiel 60 ist eine MEC-Systemumsetzung, umfassend jeweilige MEC-Entitäten, umfassend MEC-Hosts, MEC-Plattformen, Orchestrator, angepasst zum Ausführen eine der Operationen aus Beispielen 1 bis 46, oder wie anderweitig hierin dargestellt oder beschrieben.
  • Beispiel 61 ist eine Edge-Cloud-Netzwerkplattform, umfassend physische und logische Rechenressourcen, Angepasst zum Ausführen der Operationen aus Beispielen 1 bis 46 oder wie anderweitig hierin dargestellt und beschrieben.
  • Beispiel 62 ist eine Vorrichtung, umfassend jeweilige Mittel zum Ausführen einer der Operationen aus Beispielen 1 bis 46, oder wie anderweitig hierin dargestellt oder beschrieben.
  • Beispiel 63 ist ein System zum Ausführen der Operationen aus einem der Beispiele 1 bis 46, oder wie anderweitig hierin dargestellt oder beschrieben.
  • Beispiel 64 ist mindestens ein maschinenlesbares Speichermedium, umfassend Informationen, die Anweisungen darstellen, die bei Ausführung durch einen Verarbeitungsschaltkreis veranlassen, dass der Verarbeitungsschaltkreis die Operationen aus einem der Beispiele 1 bis 46 durchführt.
  • In der obigen detaillierten Beschreibung können verschiedene Merkmale gruppiert sein, um die Offenbarung zu verschlanken. Ansprüche sind jedoch möglicherweise nicht für jedes hierin offenbarte Merkmal dargelegt, da Ausführungsformen einen Untersatz der Merkmale aufweisen können. Ferner können Ausführungsformen weniger Merkmale umfassen als in einem bestimmten Beispiel offenbart sind. So werden die folgenden Ansprüche hiermit in die ausführliche Beschreibung einbezogen, wobei ein Anspruch als eigene Ausführungsform für sich steht.

Claims (25)

  1. Vorrichtung, die als ein Mehrfachzugriffs-Edge-Computing-Orchestrator (MEC-Orchestrator) läuft, um Dienstverbrauch unter Verwendung von Zonen zu verwalten, umfassend: eine Verarbeitungsschaltungsanordnung; und eine Speichervorrichtung, umfassend Anweisungen, die darauf verkörpert sind, wobei die Anweisungen, die bei Ausführung durch die Verarbeitungsschaltungsanordnung die Verarbeitungsschaltungsanordnung konfigurieren, Operationen auszuführen zum: Empfangen einer Anfrage von einer Anwendung, die auf einem Host ausgeführt wird, nach einer Liste von Diensten und entsprechenden Nähezonen; in Reaktion auf den Empfang der Anfrage nach der Liste von Diensten, Abfragen mehrerer Hosts nach Leistungsmetriken jeweiliger Dienste, die von den mehreren Hosts angeboten werden, wobei die jeweiligen Dienste durch die Anwendung verwendet werden, die auf dem Host ausgeführt wird; Aufbauen einer Zonenkarte, wobei die Zonenkarte eine Zuordnung zwischen der Anwendung und den mehreren Hosts basierend auf den Leistungsmetriken unterhält; und Verwalten der Migration der Anwendung oder eines Diensts der jeweiligen Dienste basierend auf der Zonenkarte, um eine Quality-of-Service (QoS) der Anwendung sicherzustellen.
  2. Vorrichtung nach Anspruch 1, wobei eine Zone der Zonenkarte basierend auf einer oberen Kostengrenze und einer unteren Kostengrenze erzeugt wird, wobei die obere Kostengrenze maximale Kosten für die Verwendung der jeweiligen Dienste durch die Anwendung darstellt.
  3. Vorrichtung nach Anspruch 2, wobei die obere Kostengrenze durch eine Grenznetzwerklatenz dargestellt wird.
  4. Vorrichtung nach Anspruch 2, wobei die obere Kostengrenze durch einen Grenznetzwerkdurchsatz dargestellt wird.
  5. Vorrichtung nach Anspruch 2, wobei die obere Kostengrenze durch eine Grenzverarbeitungsabschlusszeit dargestellt wird.
  6. Vorrichtung nach Anspruch 1, wobei die Anfrage einen Eingabeparameter umfasst, um die Verfügbarkeit einer Liste von Dienstinstanzen mit einem Lokalitätsumfang abzufragen.
  7. Vorrichtung nach Anspruch 1, wobei die Anfrage einen Eingabeparameter umfasst, um die Verfügbarkeit einer Liste von Dienstinstanzen abzufragen, die nur lokal verbraucht werden können.
  8. Vorrichtung nach Anspruch 1, wobei die Anfrage einen Eingabeparameter umfasst, um die Verfügbarkeit einer Liste von Dienstinstanzen abzufragen, die auf dem Host ausgeführt werden.
  9. Vorrichtung nach Anspruch 1, wobei die Vorrichtung zur Abfrage der mehreren Hosts nach Leistungsmetriken jeweiliger Dienste, die von den mehreren Hosts angeboten werden, Operationen ausführt, um eine Schnittstelle mit einem zweiten MEC-System zu bilden.
  10. Vorrichtung nach Anspruch 9, wobei die Vorrichtung für die Schnittstelle mit dem zweiten MEC-System Operationen zum Übertragen der Abfrage an einen MEC-Orchestrator des zweiten MEC-Systems ausführt, wobei der MEC-Orchestrator konfiguriert ist, Hosts in dem zweiten MEC-System nach Leistungsmetriken von Diensten abzufragen, die von den Hosts des zweiten MEC-Systems zur Verfügung stehen.
  11. Vorrichtung nach Anspruch 1, wobei die mehreren Hosts Mehrfachzugriffs-Edge-Computing-Hosts (MEC-Hosts) umfassen, die einem Standard von einer MEC-Standardfamilie des ETSI (European Telecommunications Standards Institute) entsprechend funktionieren.
  12. Verfahren zum Verwalten von Dienstverbrauch unter Verwendung von Zonen, umfassend: Empfangen einer Anfrage von einer Anwendung, die auf einem Host ausgeführt wird, nach einer Liste von Diensten und entsprechenden Nähezonen; in Reaktion auf den Empfang der Anfrage nach der Liste von Diensten, Abfragen mehrerer Hosts nach Leistungsmetriken jeweiliger Dienste, die von den mehreren Hosts angeboten werden, wobei die jeweiligen Dienste durch die Anwendung verwendet werden, die auf dem Host ausgeführt wird; Aufbauen einer Zonenkarte, wobei die Zonenkarte eine Zuordnung zwischen der Anwendung und den mehreren Hosts basierend auf den Leistungsmetriken unterhält; und Verwalten der Migration der Anwendung oder eines Diensts der jeweiligen Dienste, um eine Quality-of-Service (QoS) der Anwendung sicherzustellen.
  13. Verfahren nach Anspruch 12, wobei eine Zone der Zonenkarte basierend auf einer oberen Kostengrenze und einer unteren Kostengrenze erzeugt wird, wobei die obere Kostengrenze maximale Kosten für die Verwendung der jeweiligen Dienste durch die Anwendung darstellt.
  14. Verfahren nach Anspruch 13, wobei die obere Kostengrenze durch eine Grenznetzwerklatenz dargestellt wird.
  15. Verfahren nach Anspruch 13, wobei die obere Kostengrenze durch einen Grenznetzwerkdurchsatz dargestellt wird.
  16. Verfahren nach Anspruch 13, wobei die obere Kostengrenze durch eine Grenzverarbeitungsabschlusszeit dargestellt wird.
  17. Verfahren nach Anspruch 12, wobei die Anfrage einen Eingabeparameter umfasst, um die Verfügbarkeit einer Liste von Dienstinstanzen mit einem bestimmten Lokalitätsumfang abzufragen.
  18. Verfahren nach Anspruch 12, wobei die Anfrage einen Eingabeparameter umfasst, um die Verfügbarkeit einer Liste von Dienstinstanzen abzufragen, die nur lokal verbraucht werden können.
  19. Verfahren nach Anspruch 12, wobei die Anfrage einen Eingabeparameter umfasst, um die Verfügbarkeit einer Liste von Dienstinstanzen abzufragen, die auf dem Host ausgeführt werden.
  20. Verfahren nach Anspruch 12, wobei die Abfrage der mehreren Hosts nach Leistungsmetriken jeweiliger Dienste, die von den mehreren Hosts angeboten werden, eine Schnittstelle mit einem zweiten MEC-System umfasst.
  21. Verfahren nach Anspruch 20, wobei das Errichten der Schnittstelle mit dem zweiten MEC-System das Übertragen der Abfrage an einen MEC-Orchestrator des zweiten MEC-Systems umfasst, wobei der MEC-Orchestrator konfiguriert ist, Hosts in dem zweiten MEC-System nach Leistungsmetriken von Diensten abzufragen, die von den Hosts des zweiten MEC-Systems zur Verfügung stehen.
  22. Verfahren nach Anspruch 12, wobei die mehreren Hosts Mehrfachzugriffs-Edge-Computing-Hosts (MEC-Hosts) umfassen, die einem Standard von einer MEC-Standardfamilie des ETSI (European Telecommunications Standards Institute) entsprechend funktionieren.
  23. Nichttransitorisches maschinenlesbares Medium bzw. nichttransitorische maschinenlesbare Medien, umfassend Anweisungen zum Verwalten von Dienstverbrauch unter Verwendung von Zonen, wobei die Anweisungen bei Ausführung durch eine Maschine die Maschine veranlassen, die Operationen auszuführen, umfassend: Empfangen einer Anfrage von einer Anwendung, die auf einem Host ausgeführt wird, nach einer Liste von Diensten und entsprechenden Nähezonen; in Reaktion auf den Empfang der Anfrage nach der Liste von Diensten, Abfragen mehrerer Hosts nach Leistungsmetriken jeweiliger Dienste, die von den mehreren Hosts angeboten werden, wobei die jeweiligen Dienste durch die Anwendung verwendet werden, die auf dem Host ausgeführt wird; Aufbauen einer Zonenkarte, wobei die Zonenkarte eine Zuordnung zwischen der Anwendung und den mehreren Hosts basierend auf den Leistungsmetriken unterhält; und Verwalten der Migration der Anwendung oder eines Diensts der jeweiligen Dienste, um eine Quality-of-Service (QoS) der Anwendung sicherzustellen.
  24. Nichttransitorisches maschinenlesbares Medium bzw. nichttransitorische maschinenlesbare Medien nach Anspruch 23, wobei eine Zone der Zonenkarte basierend auf einer oberen Kostengrenze und einer unteren Kostengrenze erzeugt wird, wobei die obere Kostengrenze maximale Kosten für die Verwendung der jeweiligen Dienste durch die Anwendung darstellt.
  25. Nichttransitorisches maschinenlesbares Medium bzw. nichttransitorische maschinenlesbare Medien nach Anspruch 24, wobei die obere Kostengrenze durch eine Grenznetzwerklatenz dargestellt wird.
DE112018007463.3T 2018-04-11 2018-12-28 Flexibler Mehrfachzugriffs-Edge-Computing-Dienstverbrauch (Mec-Dienstverbrauch) durch Hostzoning Pending DE112018007463T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201862656138P 2018-04-11 2018-04-11
US62/656,138 2018-04-11
PCT/US2018/067898 WO2019199362A1 (en) 2018-04-11 2018-12-28 Flexible multi-access edge computing (mec) services consumption through hosts zoning

Publications (1)

Publication Number Publication Date
DE112018007463T5 true DE112018007463T5 (de) 2020-12-24

Family

ID=65199589

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112018007463.3T Pending DE112018007463T5 (de) 2018-04-11 2018-12-28 Flexibler Mehrfachzugriffs-Edge-Computing-Dienstverbrauch (Mec-Dienstverbrauch) durch Hostzoning

Country Status (3)

Country Link
US (2) US11689640B2 (de)
DE (1) DE112018007463T5 (de)
WO (1) WO2019199362A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11689640B2 (en) 2018-04-11 2023-06-27 Intel Corporation Flexible multi-access edge computing (MEC) services consumption through hosts zoning

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10841766B2 (en) * 2018-11-28 2020-11-17 Verizon Patent And Licensing Inc. Method and system for service provisioning based on multi-tiered networks and resource utilization
US11290561B2 (en) * 2019-02-07 2022-03-29 Verizon Patent And Licensing Inc. Methods and systems for managing applications of a multi-access edge computing environment
US11057495B2 (en) * 2019-05-01 2021-07-06 Ciena Corporation Selecting where to process data associated with Internet of Things (IoT) devices
CN112367605A (zh) * 2019-07-25 2021-02-12 中兴通讯股份有限公司 基于边缘计算的应用重定位方法及装置
US11503121B2 (en) * 2019-11-08 2022-11-15 Johnson Controls Tyco IP Holdings LLP Universal gateway devices, systems and methods for integrating proprietary protocols with BMS system
US11550636B2 (en) * 2019-11-14 2023-01-10 Vmware, Inc. Internet of things solution deployment in hybrid environment
CN110958170B (zh) * 2019-11-25 2021-09-14 中国联合网络通信集团有限公司 一种网络互联方法和装置
US11330511B2 (en) * 2020-06-22 2022-05-10 Verizon Patent And Licensing Inc. Method and system for multi-access edge computing (MEC) selection and load balancing
CN113949705B (zh) * 2020-06-29 2023-07-11 华为技术有限公司 通信方法和通信装置
KR20220001630A (ko) * 2020-06-30 2022-01-06 삼성에스디에스 주식회사 엣지 컴퓨팅 장치를 위한 애플리케이션 배포 방법 및 시스템
US11159449B1 (en) 2020-07-09 2021-10-26 International Business Machines Corporation Dispatching tasks and data using multi-access edge computing
US11212344B1 (en) * 2020-08-31 2021-12-28 Verizon Patent And Licensing Inc. Systems and methods for utilities-based workload management in a communication network
KR102640785B1 (ko) * 2020-09-10 2024-02-23 에스케이텔레콤 주식회사 엣지서비스지원서버 및 엣지서비스지원서버의 동작 방법
CN112601232B (zh) * 2020-12-10 2022-04-26 中国科学院深圳先进技术研究院 基于最小费用最大流的负载均衡的多服务迁移方法及系统
CN112600827B (zh) * 2020-12-10 2021-10-29 中国科学院深圳先进技术研究院 基于增量式最小费用最大流的虚拟服务迁移方法及系统
CN113347016B (zh) * 2021-03-10 2022-10-04 福州大学 基于资源占用和时延敏感的虚拟化网络功能迁移方法
CN115442751A (zh) * 2021-06-03 2022-12-06 中国移动通信有限公司研究院 信息处理方法、装置、设备及存储介质
US20230060164A1 (en) * 2021-08-26 2023-03-02 Toyota Motor Engineering & Manufacturing North America, Inc. Systems and methods for maintaining a service session in an automotive edge computing environment
US11936736B2 (en) * 2021-11-10 2024-03-19 Electronics And Telecommunications Research Institute Interworking method between different 5G multi-access edge computing (MEC) platforms using common application programing interface framework (CAPIF)
CN114449486B (zh) * 2021-12-23 2023-09-19 之江实验室 一种边缘计算服务漫游的方法及装置

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8959139B2 (en) * 2010-05-28 2015-02-17 Juniper Networks, Inc. Application-layer traffic optimization service endpoint type attribute
WO2017100640A1 (en) * 2015-12-11 2017-06-15 Interdigital Patent Holdings, Inc. Method and apparatus for enabling third party edge clouds at the mobile edge
CN112087495B (zh) * 2016-02-04 2021-09-21 华为技术有限公司 服务迁移方法、装置及系统
CN110476402B (zh) * 2017-05-22 2021-03-30 华为技术有限公司 网络切片创建的方法、装置以及通信系统
US10326766B2 (en) * 2017-07-13 2019-06-18 Dell Products, Lp Method and apparatus for optimizing mobile edge computing for nomadic computing capabilities as a service
US11606421B2 (en) * 2017-12-12 2023-03-14 Sony Group Corporation Edge computing relocation
DE112018007463T5 (de) 2018-04-11 2020-12-24 Intel IP Corporation Flexibler Mehrfachzugriffs-Edge-Computing-Dienstverbrauch (Mec-Dienstverbrauch) durch Hostzoning

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11689640B2 (en) 2018-04-11 2023-06-27 Intel Corporation Flexible multi-access edge computing (MEC) services consumption through hosts zoning

Also Published As

Publication number Publication date
US20210067605A1 (en) 2021-03-04
US20230291812A1 (en) 2023-09-14
WO2019199362A1 (en) 2019-10-17
US11689640B2 (en) 2023-06-27

Similar Documents

Publication Publication Date Title
DE112018007463T5 (de) Flexibler Mehrfachzugriffs-Edge-Computing-Dienstverbrauch (Mec-Dienstverbrauch) durch Hostzoning
DE102019105398A1 (de) Inter-mec-systemkommunikation für v2x-services
US11736942B2 (en) Multi-domain trust establishment in edge cloud architectures
DE102019217367A1 (de) VERWALTUNG DER DIENSTQUALITÄT (QoS) IN EDGE-COMPUTING-UMGEBUNGEN
US11540355B2 (en) MEC-based distributed computing environment with multiple edge hosts and user devices
DE112018005693T5 (de) Multi-access edge computing (mec)-basierte mehrbetreiberunterstützung für cellular vehicle-to-everything (c-v2x) systeme
DE112020001183T5 (de) Multi-slice-unterstützung für mec-fähige 5g-implementierungen
DE112020004736T5 (de) Edge-computing-technologien für transportschichtüberlastregelung und point-of-presence-optimierungen auf grundlage erweiterter vorab-dienstgüte-benachrichtigungen
US11412033B2 (en) 5G network edge and core service dimensioning
DE112018005810T5 (de) Plugin-management für internet of things- (iot) netzwerkoptimierung
DE102022200847A1 (de) Bestärkendes lernen für mehrfachzugriffsverkehrsverwaltung
DE102021211176A1 (de) Interoperables framework für sicheren verbrauch von dual-modus-edge-anwendungsprogrammierungsschnittstellen in hybriden edge-computing-plattformen
DE112020002310T5 (de) V2x-dienste zur bereitstellung fahrtspezifischer qos-vorhersagen
DE112017006994T5 (de) Bereitstellung und verwaltung von microservices
DE102020201015A1 (de) Technologien zum verteilen iterativer berechnungen in heterogenen computerumgebungen
DE112020003766T5 (de) Linkleistungsprognose und Medienstreaming-Technologien
DE102019123244A1 (de) Verbesserungen der verfolgung von multi-access-edgecomputing (mec)-gebührenerfassung und -abrechnung
DE112017004996T5 (de) Gatewaykoordination für das Internet der Dinge
DE102020202398A1 (de) Edge-server-cpu mit dynamischer deterministischer skalierung
DE112019002913T5 (de) Verwaltung von zuweisungen bevorzugter kanäle zwischendrahtloskommunikationsbändern
DE112019003316T5 (de) Verteiltes berechnungsverfahren, vorrichtung und system
DE112017008033T5 (de) Gemeinsames Schnittstellensystem für Maschennetzwerke und Fog-Computersysteme
DE112018007007T5 (de) Verteilte selbstsouveräne identitäten zur virtualisierung von netzwerkfunktionen
DE112020007003T5 (de) Multi-funkzugangstechnologie-verkehrsverwaltung
DE102022202963A1 (de) Verkehrsaufteilungs- und neuübertragungsmechanismen mit schichtübergreifender und zugangsübergreifender technologie

Legal Events

Date Code Title Description
R081 Change of applicant/patentee

Owner name: INTEL CORPORATION, SANTA CLARA, US

Free format text: FORMER OWNER: INTEL IP CORPORATION, SANTA CLARA, CALIF., US

R082 Change of representative

Representative=s name: MAIWALD PATENTANWALTS- UND RECHTSANWALTSGESELL, DE

R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0029080000

Ipc: H04L0065000000

R012 Request for examination validly filed