DE112018005810T5 - Plugin-management für internet of things- (iot) netzwerkoptimierung - Google Patents

Plugin-management für internet of things- (iot) netzwerkoptimierung Download PDF

Info

Publication number
DE112018005810T5
DE112018005810T5 DE112018005810.7T DE112018005810T DE112018005810T5 DE 112018005810 T5 DE112018005810 T5 DE 112018005810T5 DE 112018005810 T DE112018005810 T DE 112018005810T DE 112018005810 T5 DE112018005810 T5 DE 112018005810T5
Authority
DE
Germany
Prior art keywords
ocf
network
communication
plug
protocol
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
DE112018005810.7T
Other languages
English (en)
Inventor
Mats Gustav Agerstam
Vijay Sarathi Kesavan
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 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 Corp filed Critical Intel Corp
Publication of DE112018005810T5 publication Critical patent/DE112018005810T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08—Protocols for interworking; Protocol conversion
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • 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/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • 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/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • 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/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • 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/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y04—INFORMATION OR COMMUNICATION TECHNOLOGIES HAVING AN IMPACT ON OTHER TECHNOLOGY AREAS
    • Y04S—SYSTEMS INTEGRATING TECHNOLOGIES RELATED TO POWER NETWORK OPERATION, COMMUNICATION OR INFORMATION TECHNOLOGIES FOR IMPROVING THE ELECTRICAL POWER GENERATION, TRANSMISSION, DISTRIBUTION, MANAGEMENT OR USAGE, i.e. SMART GRIDS
    • Y04S40/00—Systems for electrical power generation, transmission, distribution or end-user application management characterised by the use of communication or information technologies, or communication or information technology specific aspects supporting them
    • Y04S40/18—Network protocols supporting networked applications, e.g. including control of end-device applications over a network

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Verschiedene System und Verfahren für die Netzwerkoptimierung oder den Bandbreitenerhalt können Open-Connectivity-Foundation- (OCF) Pluginmigration oder Mirroring verwenden, um auf ein OCF-Plugin in der Cloud zuzugreifen. Ein cloudbasiertes OCF-Plugin erlaubt die Routingoptimierung zum Einsetzen eines OCF-Ressourcenverzeichnisses zum Bereitstellen der Erkennung oder des Zugriffs auf das OCF Plugin. Das OCF Plugin kann verwendet werden, wenn eine OCF-Vorrichtung mit einer Nicht-OCF-Vorrichtung kommuniziert.

Description

  • PRIORITÄTSANSPRUCH
  • Dieser Anmeldung beansprucht die Priorität der US-Anmeldung mit Seriennummer 16/110,011, eingereicht am 23. August 2018, die die Priorität der provisorischen US-Anmeldungen Nr. 62/595,324 , eingereicht am 6. Dezember 2017, mit dem Titel „Plugin Management For IOT Network Optimization“ beansprucht, die alle hierin durch Verweis in ihrer Gesamtheit einbezogen sind.
  • TECHNISCHER BEREICH
  • Hierin beschriebene Ausführungsformen beziehen sich allgemein auf Datenkommunikation und Netzwerke verbundener Vorrichtungen, und insbesondere auf Techniken zum Aufbauen von Verbindungen und Umsetzen von Funktionen unter Vorrichtungen aus dem Internet of Things (IoT) und Vorrichtungsnetzwerken.
  • HINTERGRUND
  • IoT-Vorrichtungen sind physische 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 IoT-Vorrichtungen beliebter, und Anwendungen, 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. Dies umfasst die Spezialisierung von Kommunikationsstandards, die durch Gruppen wie das Institute of Electrical and Electronics Engineers (IEEE) verbreitet werden, und die Spezialisierung der Anwendungsinteraktionsarchitektur und Konfigurationsstandards, die durch Gruppen wie die Open Connectivity Foundation (OCF) verbreitet werden.
  • Figurenliste
  • In den Zeichnungen, die nicht notwendigerweise maßstabsgetreu 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. Einige Ausführungsformen sind in den Figuren der beiliegenden Zeichnungen beispielhaft und nicht einschränkend illustriert. Dabei gilt:
    • 1 illustriert eine Domaintopologie für jeweilige Internet-of-Things- (IoT) Netzwerke, die nach einem Beispiel durch Verbindungen mit den jeweiligen Gateways gekoppelt sind;
    • 2 illustriert ein Cloud-Computing-Netzwerk in Kommunikation mit einem Mesh-Netzwerk von IoT-Vorrichtungen, die als eine Fog-Plattform in einem Netzwerkszenario laufen, nach einem Beispiel;
    • 3 illustriert ein schematisches Diagramm eines OCF-Systems mit einem Plugin auf einer Gatewayvorrichtung nach einem Beispiel;
    • 4 illustriert ein schematisches Diagramm eines OCF-Systems mit einem Plugin in der Cloud nach einem Beispiel;
    • 5 illustriert ein schematisches Diagramm eines OCF-Systems mit einem Routeroptimierungsdienst nach einem Beispiel;
    • 6 illustriert ein Ablaufdiagramm, das eine Technik zum Vereinfachen der Kommunikation zwischen einer OCF-Vorrichtung und einer Nicht-OCF-Vorrichtung nach einem Beispiel ermöglicht;
    • 7 illustriert ein Blockdiagramm eines Netzwerks, das die Kommunikation entlang einer Reihe von IoT-Vorrichtungen nach einem Beispiel illustriert; und
    • 8 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.
    • 9 illustriert ein System von Netzwerkkomponenten nach einem Beispiel.
  • AUSFÜHRLICHE BESCHREIBUNG
  • In der folgenden Beschreibung sind Verfahren, Konfigurationen und damit verbundene Vorrichtungen für die Verarbeitung von Sicherheitskontexten in einem IoT-Vorrichtungsverbindungssetting durch Verwendung eines in der Cloud gehosteten Plugins illustriert.
  • OCF stellt einen Standard für IoT-Kommunikation für eine Vielzahl von Anwendungsfällen bereit, wie etwa in dem verbundenen Heim. Einige Instanziierungen des OCF, wie etwa die IoTivity, stellen verschiedene Erweiterungen für die OCF-Vorgaben bereit, die eine Interoperabilität mit anderen Nicht-OCF-Ökosystemen erlauben. Dies erfolgt mittels eines Plugin-Managers, der es Nicht-OCF-Vorrichtungen ermöglicht, auf einer Domain als OCF-Vorrichtungen zu erscheinen, die eine homogene Vorrichtungsansicht und Interoperabilität über Ökosysteme hinweg bereitstellen. Offene Lösungen hosten heute ihre Dienste häufig in der Cloud, und infolgedessen müssen Sicherheits- und Zugriffsflüsse einen in der Cloud gehosteten Dienst durchlaufen. Die Verwendung einer Pluginlösung führt jedoch einen Satz weiterer Trafficabläufe ein, und fügt eine wesentliche Latenzmenge hinzu, die verhindern kann, dass der Dienst die vorgegebene Stufe der Quality-of-Service (QoS) für den Endbenutzer bereitstellt. Die hierin besprochenen Techniken umfassen eine Lösung für diese und für andere technische Probleme über ein Plugin und die Autorisierungsmigration in die Cloud.
  • Die heutigen Umsetzungen der OCF-Erweiterungen bieten aktuell keine Lösung für dieses Problem. Einige Techniken, die den Protokollmanager für OCF einsetzen, machen dies durch Hosten aller Plugins auf einer lokalen Gatewayvorrichtung, was zu der Latenz durch alle unnötigen Netzwerkübergaben zwischen der privaten und der öffentlichen Domain führt.
  • Die hierin beschriebenen Lösungen, die einen Routingoptimierer verwenden können, setzen ein Resource Directory (z. B. ein OCF-Resource-Directory) ein, um eine Erkennung und Zugriff auf eine korrekte Plugin-Instanz (z. B. private Domain vs. öffentliche Domain bereitstellt) und außerdem das Mirroring oder die Migration einer Plugin-Instanz in die öffentliche Domain unter Aufrechterhaltung der vom Benutzer eingerichteten Autorisationsbindungen zu detaillieren. Die Lösung stellt einen automatischen Mechanismus bereit, mit dem Dritt-Nicht-OCF-Plugins oder nicht-native Plugins automatisch in anbieteragnostischer Weise auf eine in der Cloud gehostete Umgebung gespiegelt oder migriert werden können, wobei Sicherheitsassoziationen erhalten bleiben und ein netzwerkoptimalerer Zugriffspfad auf den Dienst mittels Verringern des Gesamtnetzwerktraffics, der Sprünge und der Round-Trip-Zeit bereitgestellt wird.
  • 1 illustriert eine beispielhafte Domaintopologie für jeweilige Internet-of-Things- (IoT) Netzwerke, die durch Verbindungen mit den jeweiligen Gateways gekoppelt sind. Das IoT unterstützt Einsätze, in denen eine große Anzahl von Rechnervorrichtungen 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 halb autonome 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 Rechnervorrichtung. 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 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 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 kann 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- (WLAN) Netzwerk 158, das verwendet wird, um mit IoT-Vorrichtungen 104 durch IEEE 802.11- (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- (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-Netzwerks- (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 Fog-Vorrichtungen oder -Systemen. Während die Nutzung von solchen 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“- (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 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 Transformation von Rohdaten in Informationen auf effiziente Weise, 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- (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 7 und 8 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 Fog-Vorrichtung, Fog-Plattform oder Fog-Netzwerk bezeichnet werden kann. Diese Konfiguration wird ferner mit Bezug auf 2 unten erklärt.
  • 2 illustriert ein Cloud-Computing-Netzwerk in Kommunikation mit einem Mesh-Netzwerk von IoT-Vorrichtungen (Vorrichtungen 202), die als eine Fog-Plattform in einem Netzwerkszenario laufen.
  • Das Mesh-Netzwerk der IoT-Vorrichtungen kann als Fog-Netzwerk 220 bezeichnet werden, das von einem Netzwerk von Vorrichtungen aufgebaut wird, die an dem Rand der Cloud 200 laufen. Um das Diagramm zu vereinfachen, ist nicht jede IoT-Vorrichtung 202 beschriftet.
  • Das Fog-Netzwerk 220 kann als ein massiv verbundenes Netzwerk betrachtet werden, wobei eine Anzahl von IoT-Vorrichtungen 202 miteinander etwa über Funkverbindungen 222 in Kommunikation stehen. Das Fog-Netzwerk 220 kann eine horizontale, physische oder virtuelle Ressourcenplattform aufbauen, von der angenommen werden kann, dass sie zwischen IoT-Edge-Vorrichtungen und der Cloud oder Rechenzentren sitzt. Ein Fog-Netzwerk kann in einigen Beispiele vertikal isolierte latenzempfindliche Anwendungen durch geschichtete, föderierte oder verteilte Rechner-, Speicher- und Netzwerkkonnektivitätsoperationen unterstützen. Ein Fog-Netzwerk kann jedoch ebenfalls verwendet werden, um Ressourcen und Dienste an und unter dem Rand und der Cloud zu verteilen. So sind Verweise in diesem Dokument auf die „Edge“, „Fog“ und „Cloud“ nicht notwendigerweise diskret oder sich gegenseitig ausschließend.
  • Beispielsweise kann das Fog-Netzwerk 220 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 die das Optimized-Link-State-Routing- (OLSR) Protokoll, das Better-Approach-to-Mobile-Ad-hoc-Networking- (B.A.T.M.A.N.) Routingprotokoll, das OMA-Lightweight-M2M-(LWM2M) Protokoll, Protokolle nach einer onem2m-Vorgabe, ein QPC-Unified-Architecture-Protokoll oder unter anderem ein Protokoll nach einem Open-Process-Automation-Forum- (OPAF) Vorgabe.
  • 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-Netzwerk 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 Datenaggregatoren 226 oder Gateways 204 zum Verarbeiten der Daten.
  • 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.
  • Das Fog-Netzwerk 220, das 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. ein Fog-Netzwerk, das als eine Vorrichtung oder Plattform funktioniert. In diesem Beispiel können die Mitteilungen, die von der Fog-Plattform gesendet werden, gesendet werden, ohne als von einer spezifischen IoT-Vorrichtung 202 in dem Fog-Netzwerk 220 kommend identifiziert zu werden. In dieser Weise kann das Fog-Netzwerk 220 als eine verteilte Plattform betrachtet werden, die Rechner- 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 Fog-Plattform 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, Anfragen und Vorrichtungsausfälle zu bestimmen. Als ein Beispiel kann eine Anfrage 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 das Fog-Netzwerk 220 die IoT-Vorrichtungen 202, wie etwa Partikelsensoren 228, wählt, die zum Beantworten der Anfrage 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 das Fog-Netzwerk 220 an den Server 206 geschickt werden, um die Anfrage zu beantworten. In diesem Beispiel können IoT-Vorrichtungen 202 indem Fog-Netzwerk 220 die verwendeten Sensoren 228 basierend auf der Anfrage 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 dem Fog-Netzwerk 220 analoge Daten bereitstellen, wenn diese verfügbar sind.
  • 3 illustriert ein schematisches Diagramm eines OCF-Systems mit eine Plugin 302 auf einer Gatewayvorrichtung 304 nach einem Beispiel; Das Plugin 302 kann eines von mehreren Plugins (z. B. PP1, PP2, ..., PPN) sein, die auf der Gatewayvorrichtung 304 laufen oder laufen können. Die Gatewayvorrichtung 304 kann einen OCF-Übersetzungs-/Pluginmanager umfassen, um das korrekte zu aktivierende Plugin zu wählen. In einem Beispiel kann die Gatewayvorrichtung 304 mit dem Router 312 oder der Nicht-OCF-Vorrichtung 308 verkabelt sein. In einem anderen Beispiel kann die OCF-Vorrichtung 306 in dem Cloud-Dienst 310 verkabelt sein. Verbindungen zwischen Vorrichtungen oder Diensten in 3 bis 5 können verkabelte oder drahtlose Kommunikation umfassen.
  • Einige aktuelle IoTivity-Techniken verwenden ein Plugin an einer Gatewayvorrichtung. In dieser Konfiguration (3) stellt die Gatewayvorrichtung 304 (z. B. eine Smart-Home-Vorrichtung) eine Zugriffsfunktion für OCF-Vorrichtungen (z. B. OCF-Vorrichtung 306) sowie eine Protokoll-Plugin-Funktion für ein Nicht-OCF-Ökosystem (z. B. für eine Nicht-OCF-Vorrichtung 308) bereit. Die externe OCF-Vorrichtung 306 versucht, auf die autorisierten Nicht-OCF-Vorrichtungen 308 (z. B. eine, die bereits durch einen Mechanismus wurde, der definiert, geliefert und von einem Drittverifizierer (TPV), wie etwa OAuth 2.0 oder etwas Ähnlichem verifiziert wurde). Das Plugin 302 „PP1“ dient einerseits als der Client der Nicht-OCF-Vorrichtung 308, und andererseits als ein OCF-Server auf der Gatewayvorrichtung 304.
  • Weil die OCF-Vorrichtung 306 und die Nicht-OCF-Vorrichtung 308 verschiedene Kommunikationskanäle, Protokolle oder Dateitypen verwenden können, übersetzt das Plugin 302 auf der Gatewayvorrichtung 304 zwischen den beiden Vorrichtungen 306 und 308.
  • In einem Beispiel kann die externe OCF-Vorrichtung 306 Zugriff auf die Nicht-OCF-Vorrichtung 308 auf der örtlichen Heimdomain erhalten, unter Verwendung einer Technik aus 3. Die OCF-Vorrichtung 306 kann eine tragbare Vorrichtung sein, wie etwa ein Smartphone oder eine andere mobile Vorrichtung (z. B. jede Vorrichtung, die in der Lage ist, das OCF-Kommunikationsprotokoll zu verwenden),
  • 3 bis 5 zeigen eine Heimdomain oder ein lokales Netzwerk, einschließlich eins Gateways und einer Nicht-OCF-Vorrichtung. Die Heimdomain oder das lokale Netzwerk können ein lokal geroutetes Kommunikationsnetzwerk (z. B. ein Wi-Fi-Netzwerk) umfassen. So wird die Heimdomain oder das lokale Netzwerk hierin getrennt von einem Wide Area Network (z. B. der Cloud), das das Internet umfassen kann, besprochen. Die Heimdomain oder das lokale Netzwerk kann von dem Internet oder einem Clouddienst durch einen Router oder eine andere Netzwerkkomponente getrennt sein. In einem Beispiel kann ein Clouddienst oder eine OCF-Cloud eine logische Entität umfassen, die autorisiert ist, mit einer OCF-Vorrichtung (oder einer anderen Vorrichtung) zu kommunizieren. Die OCF-Cloud kann ein Resource-Directory umfassen, um Ressourceninformationen offenzulegen, die durch eine Vorrichtung veröffentlicht werden, wie etwa zum Bereitstellen einer Ressource, Aktualisieren einer Ressource oder Registrieren einer Ressource. In einem Beispiel kann eine Cloud wie hierin beschrieben eine Edge-Rechnervorrichtung oder eine Edge-Cloud-Vorrichtung oder einen Dienst umfassen.
  • Beispielsweise ist ein Anfrageablauf (von der OCF-Vorrichtung 306 zur Nicht-OCF-Vorrichtung 308, die eine IoT-Vorrichtung sein kann) den Operationen entsprechend beschrieben, die in 3 mit A beschriftet sind. Während die Operationen in 3 bis 5 als Operationen in einer Reihenfolge dargestellt sind, können Kommunikationen manchmal in anderen Reihenfolgen ausgeführt oder ausgelassen werden, ohne vom Umfang der Systeme und Verfahren, die hierin beschrieben sind, abzuweichen.
  • In dem Anfrageablauf wendet sich die OCF-Vorrichtung 306 an einen Router 312 (oder einen Rendezvous- Dienst), um den reflexiven Endpunkt der Heimdomain (z. B. die Nicht-OCF-Vorrichtung 308) zu finden. In einem anderen Beispiel kann ein DDNS-Dienst oder etwas ähnliches verwendet werden. In jedem dieser Beispiele kann das anfängliche Nachschlagen der Adresse der Heimdomain notwendig sein.
  • Die OCF-Vorrichtung 306 verbindet sich mit dem OCF-Server (z. B. über den Router 312) auf der Gatewayvorrichtung 304, beispielsweise durch einen IPv4-Mechanismus der Portweiterleitungszuordnung über der Network-Address-Translation-Port-Mapping-Protocol (NAT-PNP) Universal-Plug-and-Play (UPnP), Firewall-Hole-Punching oder NAT-Traversal-with-Session-Traversal-Utilities-for-NAT (STUN), Traversal-Using-Relay-around-NAT (TURN), Interactive-Connectivity-Establishment (ICE) usw. (A1). Der genaue Ablauf davon, wie die externe Vorrichtung sich mit der Heimdomain verbindet, kann sich von dem Aufbau aus 3 unterscheiden oder kann ein anderes Routing umfassen als in 3 gezeigt.
  • Die OCF-Vorrichtung 306 kann eine Operation auf der verfügbaren Gatewayvorrichtung 304 (A2) finden, inspizieren und ausführen, um auf die Nicht-OCF-Vorrichtung 308 zuzugreifen. Der OCF-Stapel entdeckt die örtlich laufende Instanz des Plugin-Managers, der den OCF-Pluginserver für die Nicht-OCF-Vorrichtung 308 kostet, der als Plugin 302 „PP1“ bezeichnet ist. PP1 wiederum verwendet eine Verbindung (z. B. über das Internet Protocol (IP)) auf die Nicht-OCF-Netzwerkbridge 314, die mit der Vorrichtung 308 (A3) verbunden ist. In einem Beispiel kann eine Bridge, muss aber nicht, auf Grundalge der lokalen Netzwerkkommunikationstechnologien notwendig sein, die auf der Gatewayvorrichtung 304 aktiviert sind.
  • Die Anfrage von der OCF-Vorrichtung 306 kann an einen Clouddienst 310 übertragen werden, der die Autorisierung, Zugriffssteuerung und Steuerebene (A4, A5) handhaben kann. Der Clouddienst 310 kann die Anfrage von der Nicht-OCF-Netzwerkbridge 314 empfangen, nachdem die Bridge die Anfrage von dem Plugin 302 empfängt. Der Clouddienst 310 kann als IoT-Dienst für die Verarbeitung der Anfrage bezeichnet werden.
  • Der Clouddienst 310 kommuniziert zurück nach unten zu der Nicht-OCF-Netzwerkbridge 314 (z. B. einem Gateway oder Hub) mit Anweisungen an die Nicht-OCF-Vorrichtung 308. Die Bridge 314 kann die Übersetzung von JPv4/IPv6 in ihr eigenes Netzwerkprotokoll (z. B. 6Lo/IPv6, 802.15.4, Bluetooth Low Energy (BLE), ZigBee, ZWave, ...) handhaben (A6). Die Nicht-OCF-Vorrichtung 308 empfängt die Anfrage (A7) und führt die angeforderte Operation aus.
  • In einem Beispiel wird der Rückkehrablauf (Nicht-OCF-Vorrichtung 308 an OCF-Vorrichtung 306 den Operationen entsprechend beschrieben, die in 3 mit „B“ beschriftet sind. In einem Beispiel wird die Reaktion von der Nicht-OCF-Vorrichtung 308 über den Homerouter (B1, B2, B3) an den Clouddienst 310 gesendet, beispielsweise über die Bridge 314, den Router 312, und dann an den Clouddienst 310. Der Clouddienst 310 gibt den Reaktionscode über den Router 312 zurück nach unten an den OCF-Server, der auf der Gatewayvorrichtung 304 (B4, B5) läuft, über die Bridge 314 und den Router 312. Die Gatewayvorrichtung 304 leitet die Reaktion wieder durch den Router, bevor sie an der OCF-Vorrichtung 306 (B6, B7) empfangen werden. Das Plugin 302 kann verwendet werden, um die Reaktion an der Gatewayvorrichtung 304 zu verarbeiten.
  • Die OCF-Netzwerke, die hierin beschrieben sind, umfassen eine Netzwerk-„Domain“ oder einen „Kontext“. Beispielsweise kann in einem OCF-Netzwerk eine OCF-Anwendung auf Ressourcen zugreifen und RESTful-Operationen innerhalb eines gemeinsamen Anwendungskontext oder einer Domain, in anderen Arten von Netzwerken (z. B. wie hierin als „Nicht-OCF-Netzwerk“ bezeichnet) zugreifen, eine OCF-Anwendung kann jedoch nicht in der Lage sein, direkt auf solche Ressourcen oder Operationen zuzugreifen. Die hierin besprochenen Techniken behandeln dies durch Verwendung eines Plugins zum Umwandeln zwischen einem Nicht-OCF-Protokoll oder einem Netzwerk und einem OCF-Rahmenwerk (z. B. Netzwerk, Domain, Kontext oder Anwendung).
  • 4 illustriert ein schematisches Diagramm eines OCF-Systems mit einem Plugin in der Cloud nach einem Beispiel.
  • Das OCF-System aus 4 umfasst ein OCF-Plugin 402, das (z. B. auf Grundlage einer Umsetzungswahl) gespiegelt oder migriert werden soll, um extern in einer Cloudumgebung 410 gehostet oder optional mit dem Rendezvousserver 411 gemeinsam platziert zu werden. Das OCF-Plugin 402 ist in 4 als gespiegelt dargestellt, da es auf dem Gateway 404 und in der Cloud 410 existiert. In einem anderen Beispiel kann das OCF-Plugin 402 in die Cloud 410 migriert werden und erscheint nicht auf dem Gateway 404, oder kann auf dem Gateway 404 ausgeschaltet oder deaktiviert werden.
  • In einem Beispiel kann das OCF-Plugin 402 einen OCF-Rendezvous-Server 411 verwenden, um eine bedingte Rückkehr einer Lookup-Reaktion eines Diensts oder einer Ressource auf eine Heimdomain oder das in der Cloud gehostete Plugin 402 zu unterstützen, wie etwa basierend auf der reflexiven Adresse der anrufenden Vorrichtung.
  • Das Plugin kann zuerst entweder migriert oder gespiegelt werden, um in der Cloud 410 zu sitzen und gehostet zu werden. Hosting kann durch gemeinsames Platzieren des Plugins 402 mit dem Rendezvous-Dienst 411 erfolgen, oder das Plugin 402 kann anderswo in der Cloud 410 gehostet sein.
  • Ein Benutzer (z. B. der OCF-Vorrichtung 406 oder optional der Nicht-OCF-Vorrichtung 408) kann mit einer Option versehen werden, das Spiegeln oder Migrieren des Plugins 402 an eine externe Quelle zu autorisieren (z. B. an die Cloud 410). Wenn beispielsweise die OCF-Vorrichtung 406 sich in der Heimdomain befindet, kann der Benutzer die Migration über die OCF-Vorrichtung 406 autorisieren. Der Rendezvousserver 411 kann die Quelladresse der OCF-Vorrichtung 406 betrachten, um eine informierte Routing-Entscheidung dahingehend zu treffen, welche Instanz des Plugins 402 die Anfrage verwalten soll, wie etwa zum Verringern der Latenz oder des Netzwerktraffic. Wenn die angeforderte Anfrage von außerhalb des Netzwerks kommt (z. B. befindet sich die OCF-Vorrichtung 406 außerhalb der Heimdomain), kann die Anfrage an die externe Plugin- 402 Instanz geroutet werden (z. B. durch den Rendezvousserver 411 oder eine andere öffentliche Entität gehostet). Weitere Details dieses Beispiels sind nachfolgend beschrieben.
  • Ein Anfrageablauf von der OCF-Vorrichtung 406 an eine Nicht-OCF-Vorrichtung (z. B. eine IoT-Vorrichtung) kann folgende Operationen umfassen. Die OCF-Vorrichtung 406 kann eine Anzeige an den Rendezvous-Dienst 411 senden, was die Notwendigkeit eliminieren kann, zu dem reflexiven Endpunkt (z. B. der Nicht-OCF-Vorrichtung 408) der Heimdomain hinunter zu reichen. Die OCF-Vorrichtung 406 kann basierend auf Informationen, die von dem Rendezvousdienst 411 empfangen wurden, stattdessen die Anfrage direkt an den in der Cloud gehosteten Plugindienst 416 senden (auch als gehosteter Container bezeichnet), was das Plugin 402 umfasst.
  • Der Plugindienst 416 autorisiert die Anfrage und aktiviert den IoT-Clouddienst 413, mit seinem eigenen Authentifizierungs- und Autorisierungsschema. Der Clouddienst 413 kommuniziert zurück nach unten zu einem Nicht-OCF-Gateway/einer Hubvorrichtung/Netzwerkbridge 414 über einen Router 412 mit Anweisungen an die Nicht-OCF-Vorrichtung 408. Die Bridge 414 handhabt die Übersetzung von IPv4/IPv6 in ein lokales Netzwerkprotokoll (z. B. 6Lo/IPv6 802.15.4, BLE, ZigBee, ZWave usw.).
  • Die IoT-Vorrichtung (Nicht-OCF-Vorrichtung 408) führt die angeforderte Operation durch, nachdem die Anweisungen von der Bridge empfangen wurden.
  • Ein Antwortablauf von der Nicht-OCF-Vorrichtung 408 an die OCF-Vorrichtung 406 wird nun beschrieben.
  • Die Antwort wird direkt von der Nicht-OCF-Vorrichtung 408 über den Gateway 414 und optional den Router 412 in dem Clouddienst 410 zurückgesendet. Die Antwort kann dann an den IoT-Dienst 413 gesendet werden, um an das Plugin 402 in der Cloud 410 weitergeleitet zu werden. Der Clouddienst 411 leitet die Antwort wieder zurück an das in der Cloud gehostete Plugin 402, das die Antwort an die OCF-Vorrichtung 406 weiterleitet. In einem Beispiel können die Anforderungs-/Antwortabläufe getrennt ausgeführt werden (z. B. kann die OCF-Vorrichtung 406 eine Anfrage senden, ohne eine Antwort zu benötigen oder zu empfangen, oder die Nicht-OCF-Vorrichtung 408 kann eine Nachricht, wie etwa einen Status, ein Update oder eine Mitteilung, an die OCF-Vorrichtung 406 senden, ohne eine Anfrage von der OCF-Vorrichtung 406 zu empfangen). In einem anderen Beispiel können die Anforderungs-/Anfrageabläufe umgekehrt sein, wobei die Nicht-OCF-Vorrichtung 408 zuerst eine Nachricht sendet und die OCF-Vorrichtung 406 antwortet.
  • Die obige Beschreibung zeigt, wie die Migration oder das Spiegeln des Plugins in der Cloud die Round-Trip-Latenz für den Endbenutzer optimiert (z. B. an der OCF-Vorrichtung 406). In einem Beispiel wird das Gateway 404 möglicherweise nicht in den Anfrage-/Antwortabläufen verwendet, die oben beschrieben sind. In einem anderen Beispiel kann das Plugin 402 an dem Gateway 404 auf Grundlage der Informationen, die in einem Empfangs- oder Anfrageablauf empfangen wurden, wie etwa von dem Plugin 402, das in der Cloud 410 gehostet ist, aktualisiert werden. Nachfolgend ist in 5 eine Routingoptimiererkomponente beschrieben, die den Migrations-/Mirroringprozess ermöglicht.
  • 5 illustriert ein schematisches Diagramm eines OCF-Systems mit einem Routeroptimierungsdienst nach einem Beispiel. Das OCF-System aus 5 umfasst ein Plugin 502, das von einem Gateway 504 migriert oder daran gespiegelt werden kann. Das OCF-System auf 5 kann zum Onboarding einer Nicht-OCF-Vorrichtung 508 verwendet werden. Onboarding kann Registrierung, Authentifizierung oder Zuordnung von Ressourcen umfassen.
  • Der Nicht-GCF-Vorrichtungs- 508 Onboardingprozess umfasst die Kommunikation der Vorrichtung 508 mit ihrem Cloud- 510 IoT-Dienst beispielsweise durch eine Nicht-OCF-Netzwerkbridge 514 oder einen Heimrouter 512.
  • Nach dem Onboarding der Vorrichtung 508 wird das Plugin 502 (z. B. an dem Gateway 504) für die Vorrichtung durch den Plugin-Manager 517 auf dem Gateway 504 gestartet, und das Plugin 502 findet die Vorrichtung 508.
  • Das Plugin 502 führt die Protokollzuordnung aus, um Nicht-OCF-Eigenschaften an OCF-Ressourcen zu übertragen, die in dem Ressourcenmanager des OCF-Servers 518 erstellt werden. Der Ressourcenmanager ruft den Routingoptimierer auf dem OCF-Server 518 auf, der eine Fernzugriffsrichtlinie (von einer von der Ressource getrennten Zugriffsrichtliniendatenbank oder einem -dienst 520) für eine angeforderte Ressource erhält. Das Erhalten des externen Zugriffsrichtlinie kann durch vorkonfigurierte Richtlinien oder über einen Benutzer erfolgen.
  • Die Routingoptimiererschnittstellen zu dem Pluginmanager 517 zum Erhalten der erforderlichen Plugininformationen (Plugin 502, Konfiguration, Richtlinie, Schlüssel usw.). Die Plugininformationen können in die Cloud 510 migriert oder gespiegelt werden. Der Routingoptimierer kann die Ressource in dem OCF-Rendezvousdienst in der Cloud 510 instanziieren, wie etwa durch Verwendung eines Ressourcenverzeichnisses oder eines anderen Mechanismus.
  • Nachdem das Plugin 502 in die Cloud 510 migriert oder gespiegelt ist, kann die Nicht-OCF-Vorrichtung 508 mit einer OCF-Vorrichtung kommunizieren, darauf reagieren oder anderweitig damit interagieren, wie etwa in der obigen Diskussion bezüglich 4 beschrieben.
  • 6 illustriert ein Ablaufdiagramm, das eine Technik 600 zum Vereinfachen der Kommunikation zwischen einer OCF-Vorrichtung und einer Nicht-OCF-Vorrichtung nach einem Beispiel ermöglicht.
  • Die Technik 600 umfasst eine Operation 602 zum Empfangen einer Anzeige von einer OCF-Vorrichtung, die eine Nicht-OCF-Vorrichtung für die Kommunikation identifiziert.
  • Die Technik 600 umfasst eine Operation 604 zum Identifizieren eines Netzwerkprotokolls der Nicht-OCF-Vorrichtung (z. B. Auswahl eines Plugins), wie etwa an einem Clouddienst (z. B. unter Verwendung eines OCF-Rendezvousdiensts).
  • Die Technik 600 kann eine Operation umfassen, ein Plugin dem Netzwerkprotokoll entsprechend zu wählen. Das Plugin kann von dem lokalen Netzwerk, das die Nicht-OCF-Vorrichtung umfasst, auf der Clouddienstvorrichtung gespiegelt oder darauf migriert werden.
  • Die Technik 600 umfasst eine Operation 606 zum Empfangen einer Kommunikation von einer OCF-Vorrichtung (z. B. an dem Plugin eines Clouddiensts). Die Kommunikation kann unter Verwendung eines OCF-Netzwerkprotokolls oder eines Nicht-OCF-Netzwerkprotokolls gesendet werden.
  • Die Technik 600 umfasst eine Operation 608 zum Konvertieren der Kommunikation in das Netzwerkprotokoll unter Verwendung des Plugins. Das Plugin kann gespiegelt oder migriert werden, um auf einem Clouddienst gespeichert zu werden (z. B. von einem OCF-Gateway wie etwa von einem OCF-Übersetzungs-/Pluginmanager gespiegelt oder migriert).
  • Die Technik 600 umfasst eine Operation 610 zum Senden der umgewandelten Kommunikation an die Nicht-OCF-Vorrichtung (z. B. unter Verwendung eines IoT-Diensts eines Clouddiensts). Die Kommunikation kann an seinen Router eines OCF-Systems gesendet werden, der die Kommunikation an eine Nicht-OCF-Netzwerkbridge senden kann. Die Nicht-OCF-Netzwerkbridge kann mit der Nicht-OCF-Vorrichtung kommunizieren. In einem Beispiel kann die Nicht-OCF-Vorrichtung einem Onboarding unterzogen werden, bevor die konvertierte Kommunikation an die Nicht-OCF-Vorrichtung gesendet wird.
  • Die Technik 600 schließt mit einer optionalen Operation 612 zum Umwandeln einer Reaktion von der Nicht-OCF-Vorrichtung auf ein OCF Standardnetzwerkprotokoll.
  • Die Technik 600 kann eine Operation umfassen, die konvertierte Kommunikation an einen IoT-Dienst des Plugins zu leiten. Der IoT-Dienst kann die konvertierte Kommunikation an einen Router oder eine Nicht-OCF-Netzwerkbridge auf einem mit der Nicht-OCF-Vorrichtung geteilten Netzwerk senden. Der Router oder die Bridge können die konvertierte Kommunikation an die OCF-Vorrichtung senden.
  • Die Technik 600 kann eine Operation umfassen, eine Reaktion auf die konvertierte Kommunikation von der Nicht-OCF-Vorrichtung über eine Nicht-OCF-Netzwerkbridge, einen Router oder einen IoT-Dienst (z. B. in der Cloud) zu empfangen. Das Plugin kann verwendet werden, die Reaktion von dem Netzwerkprotokoll in ein OCF-Netzwerkprotokoll zu konvertieren. Die konvertierte Reaktion kann an die OCF-Vorrichtung gesendet werden.
  • Die Technik 600 kann eine Operation umfassen, um eine Protokollzuordnung auszuführen, das Plugin zu verwenden, die Nicht-OCF-Eigenschaften in OCF-Ressourcen zu übersetzen. Beispielsweise können Plugininformationen, die sich auf das Netzwerkprotokoll beziehen, an einen Routingoptimierer gesendet werden.
  • In anderen Beispielen können die oben mit Verweis auf 3 bis 6 beschriebenen Operationen und Funktionen durch eine IoT-Vorrichtungsmaschine 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, einen Satz von Prozessoren oder Prozessorschaltungen (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. Dementsprechend können in verschiedenen Beispielen geltende Mittel für die Verarbeitung (z. B. Verarbeitung, Steuerung, Erzeugung, Bewertung usw.) durch eine solche Verarbeitungsschaltung verkörpert werden.
  • 7 illustriert eine Zeichnung eines Cloud-Rechennetzwerks oder einer Cloud 700, in Kommunikation mit einer Anzahl von Vorrichtungen aus dem Internet of Things (IoT). Die Cloud 700 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 706 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 706 oder andere Untergruppen können mit der Cloud 700 durch verkabelte oder drahtlose Verbindungen 708 in Kommunikation stehen, wie etwa LPWA-Verbindungen, optische Verbindungen und dergleichen. Ferner kann ein verkabeltes oder drahtloses Unternetzwerk 712 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 710 oder 728 verwenden, um mit externen Orten wie etwa der Cloud 700 zu kommunizieren; die IoT-Vorrichtungen können auch einen oder mehrere Server 730 verwenden, um die Kommunikation mit der Cloud 700 oder mit dem Gateway 710 zu ermöglichen. Beispielsweise kann der eine oder die mehreren Server 730 als ein Zwischennetzwerkknoten dienen, um örtliche Edge-Cloud- oder Fog-Umsetzungen unter einem Local Area Network zu unterstützen. Ferner kann der Gateway 728, der dargestellt ist, in einer Cloud-to-Gateway-to-Many-Edge-Devices-Konfiguration laufen, wie indem die verschiedenen IoT-Vorrichtungen 714, 720, 724 eingeschränkt oder dynamisch für die Zuweisung und Verwendung von Ressourcen in der Cloud 700 sind.
  • Andere beispielhafte Gruppen von IoT-Vorrichtungen können unter anderem externe Wetterstationen 714, lokale Informationsterminals 716, Wecksysteme 718, Geldautomaten 720, Alarmtafeln 722 oder bewegliche Fahrzeuge umfassen, wie etwa Notfallfahrzeuge 724 oder andere Fahrzeuge 726. Jede dieser IoT-Vorrichtungen kann in Kommunikation mit anderen IoT-Vorrichtungen, mit Servern 704, mit einer anderen IoT-Fog-Plattform oder einem -System (nicht dargestellt, aber in 2 gezeigt) oder einer Kombination darin stehen. 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 7 zu sehen ist, kann eine große Anzahl von IoT-Vorrichtungen durch die Cloud 700 kommunizieren. Dies kann es IoT-Vorrichtungen erlauben, Informationen von anderen Vorrichtungen autonom anzufordern, oder sie bereitzustellen. Beispielsweise kann eine Gruppe von IoT-Vorrichtungen (z. B. die Verkehrssteuerungsgruppe 706) einen aktuellen Wetterbericht von einer Gruppe externer Wetterstationen 714 anfordern, die den Wetterbericht ohne menschliche Eingriffe schicken können. Weiterhin kann ein Notfallfahrzeug 724 durch einen Geldautomaten 720 informiert werden, dass ein Raub stattfindet. Während das Notfallfahrzeug 724 zu dem Geldautomaten 720 fährt, kann es auf die Verkehrssteuerungsgruppe 706 zugreifen und freie Bahn zum Zielort anfordern, etwa indem die Ampeln auf Rot geschaltet werden, um den Verkehr an einer Kreuzung rechtzeitig zu stoppen, damit das Notfallfahrzeug 724 ungehindert Zugang zu der Kreuzung erhält.
  • Cluster von IoT-Vorrichtungen, wie etwa die externen Wetterstationen 714 oder die Verkehrssteuerungsgruppe 706, können ausgerüstet sein, um mit anderen IoT-Vorrichtungen sowie mit der Cloud 700 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 Fog-Plattform oder System bezeichnet werden (z. B. wie oben mit Verweis auf 2 beschrieben).
  • 8 ist ein Blockdiagramm eines Beispiels von Komponenten, die in einer IoT-Vorrichtung 850 vorhanden sein können, um die hierin beschriebenen Techniken umzusetzen. Die IoT-Vorrichtung 850 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 850 angepasst sind, oder als Komponenten, die anderweitig in eine Chassis eines größeren Systems eingebaut sind. Weiterhin soll ein Blockdiagramm aus 8 eine Ansicht von Komponenten der IoT-Vorrichtung 850 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 850 kann Verarbeitungsschaltkreise in der Form eines Prozessors 852 umfassen, der ein Mikroprozessor, ein Mehrkernprozessor, ein Multithreaded-Prozessor, ein Ultraniedrigspannungsprozessor, ein eingebetteter Prozessor oder andere bekannte Prozessorelemente sein kann. Der Prozessor 852 kann ein Teil eines Systems auf einem Chip (SoC) sein, in dem der Prozessor und andere Komponenten in einer einzigen integrierten Schaltung gebildet werden, oder in einem einzigen Package, wie etwa die Edison™- oder Galileo™-SoC-Platinen von Intel. Beispielsweise kann der Prozessor 852 einen Intel® Architecture-Core™-basierten Prozessor 852 umfassen, wie etwa einen Quark™, einen Atom™, einen i3, einen i5, einen i7 oder einen MCU-Klasseprozessor, oder einen anderen solchen Prozessor, der von der Intel® Corporation, Santa Clara, Kalifornien, erhältlich ist, es kann jedoch eine beliebige Anzahl anderer Prozessoren verwendet werden, wie sie etwa von Advanced Micro Devices, Inc. (AMD) aus Sunnyvale, Kalifornien, einem MIPS-basierten Design von MIPS Technologies, Inc. aus Sunnyvale, Kalifornien, einem ARM-basierten Design, das von ARM Holdings, Ltd. oder einem Kunden davon lizenziert ist, oder deren Lizenznehmer oder Übernehmer, verfügbar sind. Die Prozessoren können Einheiten wie einen A5-A7-Prozessor von Apple® Inc., einen Snapdragon™-Prozessor von Qualcomm® Technologies, Inc., oder einen OMAP™-Prozessor von Texas Instruments, Inc. umfassen.
  • Der Prozessor 852 kann mit einem Systemspeicher 854 über eine Verbindung 856 (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 IJPDDR4). 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 ein Speicher 858 sich auch mit dem Prozessor 852 über die Verbindung 856 koppeln. In dem Beispiel kann der Speicher 858 über ein Solid State Disk Drive (SSDD) umgesetzt sein. Andere Vorrichtungen, die für den Speicher 858 verwendet werden Flash-Speicherkarten wie SD-Karten, microSD-Karten, xD-Bildkarten und dergleichen sowie USB-Sticks umfassen. In Umsetzungen mit niedriger Energie kann der Speicher 858 ein On-Die-Speicher oder Register sein, die mit dem Prozessor 852 assoziiert sind. In einigen Beispielen kann jedoch der Speicher 858 unter Verwendung einer Mikro-Hard-Disk-Drive (HDD) umgesetzt sein. Ferner kann eine beliebige Anzahl von neuen Technologien für den Speicher 858 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 856 kommunizieren. Die Verbindung 856 kann jede beliebige Anzahl von Technologien umfassen, einschließlich die Industriestandardarchitektur (ISA), erweiterte ISA (EISA), periphere Komponentenverbindung (PCI), periphere Komponentenverbindung erweitert (PCTx), PCI express (PCIe), oder eine beliebige Anzahl anderer Technologien. Die Verbindung 856 kann ein proprietärer Bus sein, wie er etwa in einem SoC-basierten System verwendet wird. Andere Bussysteme können enthalten sein, wie etwa unter anderem eine I2C-Schnittstelle, eine SPI-Schnittstelle, Punkt-zu-Punkt-Schnittstellen und ein Leistungsbus.
  • Die Verbindung 856 kann den Prozessor 852 mit einem Mesh-Transceiver 862 koppeln, um mit anderen Mesh-Vorrichtungen 864 zu kommunizieren. Der Mesh-Transceiver 862 kann jede beliebige Anzahl von Frequenzen und Protokollen verwenden, wie etwa 2,4-Gigahertz- (GHz) Übertragungen unter dem IEEE 802.15.4-Standard, unter Verwendung des Bluetooth®-Low-Energy- (BLE) Standards, durch die Bluetooth® Special Interest Group definiert, oder den ZigBee®-Standard. Eine beliebige Anzahl von Funkgeräten, konfiguriert für ein bestimmtes drahtloses Kommunikationsprotokoll, können für die Verbindungen mit den Mesh-Vorrichtungen 864 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 862 kann unter Verwendung mehrerer Standards und Funkgeräte für die Kommunikation in mit einer anderen Reichweite kommunizieren. Beispielsweise kann die IoT-Vorrichtung 850 mit Vorrichtungen in der Nähe, z. B. innerhalb eines Umkreises von ca. 10 Meter, unter Verwendung eines örtlichen Transceivers basierend auf BLE oder einem anderen Niedrigenergiefunkgerät kommunizieren, um Energie zu sparen. Entfernter Mesh-Vorrichtungen 864, 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 866 kann eingeschlossen sein, um mit Vorrichtungen oder Services in der Cloud 800 über Local- oder Wide-Area-Netzwerkprotokolle zu kommunizieren. Der drahtlose Netzwerktransceiver 866 kann ein LPWA-Transceiver sein, der unter anderem dem IEEE 802.15.4- oder IEEE 802.15.4g-Standards folgt. Die IoT-Vorrichtung 850 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 862 und Drahtlosnetztransceiver 866 erwähnt sind, wie hierin beschrieben. Beispielsweise können die Funktransceiver 862 und 866 einen LTE- oder anderen zellulären Transceiver umfassen, der Spread-Spectrum- (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 862 und 866 können Funkgeräte umfassen, die mit jeder beliebigen Anzahl von 3GPP- (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-(5G) Kommunikationssysteme, eine Global System for Mobile Communications- (GSM) Funkkommunikationstechnologie, eine General Packet Radio Service- (GPRS) Funkkommunikationstechnologie oder eine Enhanced Data Rates for GSM Evolution-(EDGE) Funkkommunikationstechnologie, oder eine UMTS- (Universal Mobile Telecommunications System) Kommunikationstechnologie umfassen kann. Neben den oben aufgeführten Standards kann jede beliebige Anzahl von Satellitenuplinktechnologien für den drahtlosen Netzwerktransceiver 866 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) 868 kann enthalten sein, um eine verkabelte Kommunikation mit der Cloud 800 oder mit anderen Vorrichtungen bereitzustellen, wie etwa mit den Mesh-Vorrichtungen 864. 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+, PRQFIBUS oder PROFINET, und vielen anderen. Ein weiterer NIC 868 kann enthalten sein, um eine Verbindung mit einem zweiten Netzwerk zu erlauben, etwa einem NIC 868, der Kommunikation mit der Cloud über Ethernet bereitstellt, und einen zweiten NIC 868, der Kommunikation mit anderen Vorrichtungen über eine andere Art von Netzwerk bereitstellt.
  • Aufgrund der Vielzahl von Arten anwendbarer Kommunikation von der Vorrichtung mit einer anderen Komponente oder einem Netzwerk können anwendbare Kommunikationsschaltkreise, die durch die Vorrichtung verwendet werden, eine oder mehrere der Komponenten 862, 866, 868 oder 870 umfassen oder davon verkörpert sein. Dementsprechend können in verschiedenen Beispielen geltende Mittel für die Kommunikation (z. B. Empfangen, Senden usw.) durch eine solche Kommunikationsschaltung verkörpert werden.
  • Die Verbindung 856 kann den Prozessor 852 mit einer externen Schnittstelle 870 koppeln, die verwendet wird, externe Vorrichtungen oder Untersysteme zu verbinden. Die externen Vorrichtungen können Sensoren 872, wie etwa Beschleunigungsmesser, Pegelsensoren, Durchflusssensoren, optische Lichtsensoren, Kamerasensoren, Temperatursensoren, Global Positioning System (GPS) Sensoren, Drucksensoren, barometrische Drucksensoren und dergleichen umfassen. Die externe Schnittstelle 870 kann ferner verwendet werden, um die IoT-Vorrichtung 850 mit Stellelementen 874 zu verbinden, wie Lichtschaltern, Ventilstellelementen, einen hörbaren Tongenerator, eine visuelle Warnvorrichtung und dergleichen.
  • In einigen optionalen Beispielen können verschiedene Ein-/Ausgabe- (I/O) Vorrichtungen in der IoT-Vorrichtung 850 vorhanden oder damit verbunden sein. Beispielsweise kann eine Anzeige oder andere Ausgabevorrichtung 884 enthalten sein, um Informationen anzuzeigen, wie etwa Sensoranzeigen oder die Stellelementposition. Eine Eingabevorrichtung 886, wie etwa ein Touchscreen oder ein Keypad, kann enthalten sein, um Eingaben anzunehmen. Eine Ausgabevorrichtung 884 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 850 erzeugt werden.
  • Eine Batterie 876 kann die IoT-Vorrichtung 850 betreiben, wobei jedoch in Beispielen, in denen die IoT-Vorrichtung 850 an einem festen Ort montiert ist, ein Netzteil vorhanden sein kann, mit dem sie an ein Stromnetz gekoppelt ist. Die Batterie 876 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 878 kann in der IoT-Vorrichtung 850 enthalten sein, um den Ladezustand (SoCh) der Batterie 876 zu verfolgen. Der Batteriemonitor / das Ladegerät 878 kann verwendet werden, um andere Parameter der Batterie 876 zu überwachen, um Ausfallvorhersagen bereitzustellen, wie etwa zum Gesundheitszustand (SoH) und dem Funktionszustand (SoF) der Batterie 876. Der Batteriemonitor / das Ladegerät 878 kann eine integrierte Batterieüberwachungsschaltung umfassen, wie etwa eine LTC4020 oder eine LTC299Q von Linear Technologies, ein ADT7488A von ON Semiconductor aus Phoenix Arizona, oder eine IC aus der UCD9Gxxx-Familie des Texas Instruments aus Dallas, TX. Der Batteriemonitor / das Ladegerät 878 kann die Informationen zu der Batterie 876 über die Verbindung 856 an den Prozessor 852 kommunizieren. Der Batteriemonitor / das Ladegerät 878 kann auch einen Analog-Digital- (ADC) Wandler umfassen, der dem Prozessor 852 erlaubt, die Spannung der Batterie 876 oder den aktuellen Fluss von der Batterie 876 direkt zu überwachen. Die Batterieparameter können verwendet werden, die Aktionen zu bestimmen, die die IoT-Vorrichtung 850 ausführen kann, wie etwa die Übertragungsfrequenz, Mesh-Netzwerkbetrieb, Sensorfrequenz und dergleichen.
  • Ein Leistungsblock 880, oder ein anderes Netzteil, das mit einem Netz gekoppelt ist, kann mit dem Batteriemonitor / Ladegerät 878 gekoppelt sein, um die Batterie 876 zu laden. In einigen Beispielen kann der Leistungsblock 880 durch einen drahtlosen Leistungsempfänger ersetzt werden, um die Leistung drahtlos zu empfangen, beispielsweise durch eine Schleifenantenne in der IoT-Vorrichtung 850. Eine drahtlose Batterieladeschaltung, wie etwa ein LTC4020-Chip von Linear Technologies aus Milpitas, Kalifornien, kann unter anderem in dem Batteriemonitor / Ladegerät 878 enthalten sein. Die spezifischen gewählten Ladeschaltungen hängen von der Größe der Batterie 876 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 858 kann Anweisungen 882 in der Form von Software, Firmware oder Hardwarebefehlen umfassen, um die hierin beschriebenen Technologien umzusetzen. Wenn auch solche Anweisungen 882 als Codeblocks gezeigt sind, die in dem Speicherplatz 854 und dem Speicher 858 enthalten 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 882, die über den Speicherlatz 854, den Speicher 858 oder den Prozessor 852 bereitgestellt sind, als nichttransitorisches, maschinenlesbares Medium 860 verkörpert sein, einschließlich Code zum Anweisen des Prozessors 852, elektronische Funktionen in der IoT-Vorrichtung 850 auszuführen. Der Prozessor 852 kann auf das nichttransitorische, maschinenlesbare Medium 860 über die Verbindung 856 zugreifen. Beispielsweise kann das nichttransitorische maschinenlesbare Medium 860 durch Vorrichtungen verkörpert sein, die für den Speicher 858 in 8 beschrieben sind, oder kann spezifische Speichereinheiten umfassen, wie etwa optische Scheiben, Flashlaufwerke oder jede beliebige Anzahl anderer Hardwarevorrichtungen. Das nichttransitorische maschinenlesbare Medium 860 kann Anweisungen umfassen, den Prozessor 852 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 weiteren spezifischen Beispiel können die Anweisungen 888 auf dem Prozessor 852 (getrennt oder in Kombination mit den Anweisungen 888 auf dem maschinenlesbaren Medium 860) die Ausführung oder Operation einer Trusted Execution Environment (TEE) 890 konfigurieren. In einem Beispiel läuft die TEE 890 als ein geschützter Bereich, der für den Prozessor 852 zur sicheren Ausführung von Anweisungen und sicherem Zugriff auf Daten zugänglich ist. Verschiedene Umsetzungen der TEE 890, und ein damit verbundener sicherer Bereich in dem Prozessor 852 oder dem Speicherplatz 854 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, Hardwarewurzeln des Vertrauens und vertrauenswürdiger oder geschützter Operationen können in der Vorrichtung 850 durch die TEE 890 und den Prozessor 852 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 Lesezugriffspeicher (EPROM), elektrisch löschbarer programmierbarer Lesezugriffspeicher (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.
  • 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“- (VLSI) Schaltungen oder Gatearrays, oder Off-the-Shelf-Halbleiter wie Logikchips, Transistoren oder andere diskrete Bestandteile umfasst. Ein Bauteil oder Modul kann auch in programmierbaren Hardwarevorrichtungen umgesetzt werden, wie etwa feldprogrammierbaren Gatearrays, programmierbaren Arraylogikvorrichtungen oder ähnlichem. Bauteile oder Module können außerdem in Software zur Ausführung durch verschiedene Arten vorn Prozessoren umgesetzt 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 einzelner Datensatz gesammelt sein oder über verschiedene Orte verteilt sein, auch über verschiedene Speichervorrichtungen hinweg, und können zumindest teilweise nur als elektronische Signale auf einem System oder Netzwerk existieren. Die Bestandteile oder Module können passiv oder aktiv sein, einschließlich Agenten, die bedient werden können, die gewünschte Funktion auszuführen.
  • 9 illustriert ein System 900 von vernetzten Komponenten in verschiedenen IoT- und Infrastruktureinstellungen nach einem Beispiel. Das System 900 kann Vorrichtungen, Dienste oder Netzwerke umfassen, die konfiguriert sind, unter Verwendung von OCF/IEEE-Kommunikationsstandards (z. B. wie oben definiert), ETSI Mobile Edge Computing- oder Multi-Access Edge Computing- (MEC) Kommunikationsstandards oder ETSI-3GPP- (z. B. LTE, 5G) Kommunikationsstandards zu kommunizieren. Die vernetzten Komponenten des Systems 900 kommunizieren über verschiedene Stufen von Netzwerktopologien hinweg, wie etwa das Internet 910, Cloudvorrichtungen 920, Routingvorrichtungen 930, Stations-/Zugriffspunkt-/Serververbindungsvorrichtungen 940 und Endvorrichtungen 950.
  • Als weitere Beispiele der in 1, 2, 7, und 8 oben erklärten Konzepten können die verschiedenen Schichten und vernetzten Komponenten allgemein als Cloud (Internet 910, Cloudvorrichtungen 920), Fog (Routingvorrichtungen 930, Stations-/Zugriffspunkt-/Serververbindungsvorrichtungen 940) und Edge-Vorrichtungen (Stations-/Zugriffspunkt-/Serververbindungsvorrichtungen 940, Endvorrichtungen 950) kategorisiert werden, auch, wenn jede der vernetzten Komponenten aufgebaut werden kann, um in jeder der Schichten zu funktionieren. Ein Fog-Netzwerk 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.
  • Die Endvorrichtungen 950 können IoT-Vorrichtungen oder Hosts umfassen, einschließlich Fahrzeugen, mobiler Vorrichtungen, Sensoren oder dergleichen. Die Stations-/Zugriffspunkt-/Serververbindungsvorrichtungen 940 können einen Drahtloszugriffspunkt umfassen (z. B. für Wi-Fi), einen Server oder eine andere Verbindungsvorrichtung (die eine mobile Vorrichtung umfassen kann, wie etwa ein Telefon oder ein Tablet), oder eine Station (z. B. eine Basisstation oder Knoten-B, wie etwa einen erweiterten Knoten B (eNB), nach einer 3GPP-Vorgabe). Die Routingvorrichtungen 930 können einen Schalter, einen Server, einen Router oder dergleichen umfassen, die physisch oder virtuell sein können. Die Cloudvorrichtungen 920 können aktive Vorrichtungen oder andere Vorrichtungen sein. Das Internet 910 kann andere Vorrichtungen oder Server darstellen, die nicht in dem System 900 waren.
  • MEC kann eine Architektur umfassen, die Cloud-Computing-Funktionen oder Informationstechnologie- (IT) Dienste an den Netzwerk- (z. B. zelluläres Netzwerk) Rändern ermöglicht. MEC kann die Netzwerkverstopfung durch bewegen von Anwendungen, Daten, Erkennung usw. näher an den Benutzer (z. B. mobile Vorrichtung, Benutzergerät (UE), Station (STA), usw.) verringern. Einige MEC-Details, die sich mit der Sicherheit befassen (z. B. sowohl Benutzersicherheit als auch Anwendungsintegrität), Funkverwendung usw. wurden durch das ETSI verbreitet, wie etwa in dem „Mobile Edge Computing Introductory Technical White Paper“, veröffentlicht am 1. September 2014.
  • Bei MEC-Umsetzungen des Systems 900 kann eine Vorrichtung (z. B. ein Server) als ein mobiler Edge-Host verwendet werden, wie etwa ein lokalisierter Server (z. B. ein Straßenserver, der in eine Verkehrssignalvorrichtung oder ein System eingebettet ist, usw.). Eine andere Vorrichtung in dem System 900 kann als eine Endvorrichtung verwendet werden (z. B. eine mobile Vorrichtung wie ein Telefon, ein Laptop, ein Tablet, eine IoT-Vorrichtung, ein Fahrzeug usw.). Die Endvorrichtung kann mit dem lokalisierten Server kommunizieren, um rechenintensive Anwendungen oder Aktionen abzuladen, wie etwa Grafikrendering (z. B. Hochgeschwindigkeitsbrowsing künstlicher oder virtueller Realität, 3D-Gaminganwendungen, Videoverarbeitung usw.), Zwischendatenverarbeitung (z. B. Sensordatenbereinigung, Videoanalyse usw.), oder Mehrwertdienste (z. B. Übersetzung, Loganalysen usw.).
  • Eine Endvorrichtung kann einen MEC-Dienst für eine spezifische Anwendung oder Aktion initiieren, die auf einem geeigneten MEC-Host gestartet werden kann (z. B. dem lokalisierten Server). Die Anwendung kann einen Satz Anforderungen aufweisen (z. B. Latenz, Rechenressourcen, Speicherressourcen, Ort, Netzwerkfähigkeit, Sicherheitsbedingungen usw.), die durch den MEC-Host (z. B. Server) erfüllt sind. Das System 900 kann einen Host wählen, der die Anforderungen erfüllt (z. B. durch Verwendung der Stations-/Zugriffspunkt-/Serververbindungsvorrichtungen 940).
  • Die MEC-Umsetzung des Systems 900 kann verwendet werden, die Anwendungs- und Dienstmobilität und die Dienstfortsetzung unter mehreren Edge-Rechenhosts und Gruppen zu verbessern (wie etwa für Automobile oder Benutzerbewegung innerhalb und innerhalb/außerhalb von Dienstbereichen). Anwendungs- und Dienstanpassung an dem MEC-Host für netzwerkbetreibervertraute mobile Edge-Anwendungen (z. B. für gezielte Werbung, Unternehmensdienste, gruppenbasierte Inhalte, Teilnehmerinhalte) können unter Verwendung des Systems 900 umgesetzt werden.
  • MEC bietet Anwendungsentwicklern und Inhaltsanbietern Cloudrechenfähigkeiten und eine IT-Dienstumgebung am Rand des Netzwerks. Diese Umgebung bietet eine ultraniedrige Latenz und hohe Bandbreite für den Durchsatz, sowie Echtzeitzugriff auf die Funknetzwerkinformation, die durch Anwendungen eingesetzt werden kann. MEC-Technologie erlaubt flexible und schnelle Einsetzungen innovativer Anwendungen und Dienste für mobile Teilnehmer, Unternehmen und vertikale Segmente. Es wird offensichtlich, dass die Verwendung von Vorrichtungen, Diensten, Anwendungen und Ressourcen auf diese Weise zahlreiche Aspekte der Zugangssteuerung und des -managements impliziert. Dementsprechend kann eine dynamische Zugangsrichtlinienbereitstellung wie oben bezüglich 3 bis 6 erklärt in einer MEC-Umsetzung erfolgen oder koordiniert sein. Weiterhin können auch die vorhergehenden Techniken, wenn sie auch mit Verweis auf OCF-Beispiele beschrieben sind, ebenso in einer Vielzahl anderer IoT-Standardumsetzungen umgesetzt werden.
  • Weitere Beispiele 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 Clouddienst-Vorrichtung, umfassend: einen Open Connectivity Foundation- (QCF) Routingdienst zum: Empfangen einer Angabe von einer OCF-Vorrichtung, die eine Nicht-OCF-Vorrichtung identifiziert, um zu kommunizieren; und Identifizieren eines Netzwerkprotokolls der Nicht-OCF-Vorrichtung; und einen Prozessor zum Ausführen eines Plugins, das dem Netzwerkprotokoll entsprechend gewählt wurde, wobei das Plugin: eine Kommunikation von der OCF-Vorrichtung empfängt; die Kommunikation in das Netzwerkprotokoll konvertiert; und die konvertierte Kommunikation an die Nicht-OCF-Vorrichtung sendet.
  • In Beispiel 2 umfasst der Inhalt aus Beispiel 1, dass die Kommunikation einer OCF-Netzwerkvorgabe entsprechend empfangen wird.
  • In Beispiel 3 umfasst der Inhalt aus den Beispielen 1 bis 2, dass das Netzwerkprotokoll ein Netzwerkprotokoll ist, das nach einer anderen Netzwerkvorgabe als einer OCF-Netzwerkvorgabe aufgebaut ist.
  • In Beispiel 4 umfasst der Inhalt aus den Beispielen 1 bis 3, dass der Prozessor ferner die konvertierte Kommunikation an einen IoT-Dienst routen soll, wobei der IoT-Dienst die konvertierte Kommunikation an einen Router senden soll, der mit der Nicht-OCF-Vorrichtung über eine Nicht-OCF-Netzwerkbridge auf einem mit der Nicht-OCF-Vorrichtung geteilten Netzwerk verbunden ist.
  • In Beispiel 5 umfasst der Inhalt aus Beispiel 4, dass die Prozessor ferner: eine Reaktion auf die konvertierte Kommunikation von der Nicht-OCF-Vorrichtung über die Nicht-OCF-Netzwerkbridge, den Router und den IoT-Dienst empfängt; die Reaktion von dem Netzwerkprotokoll in ein OCF-Netzwerkprotokoll konvertiert; und die konvertierte Reaktion an die OCF-Vorrichtung sendet.
  • In Beispiel 6 umfasst der Inhalt aus den Beispielen 1 bis 5, dass das Plugin in der Clouddienstvorrichtung aus einem lokalen Netzwerk gespiegelt ist, das die Nicht-OCF-Vorrichtung umfasst.
  • In Beispiel 7 umfasst der Inhalt aus den Beispielen 1 bis 6, dass der Prozessor ferner das Onboarding der Nicht-OCF-Vorrichtung durchführen soll, bevor die konvertierte Kommunikation an die Nicht-OCF-Vorrichtung gesendet wird.
  • In Beispiel 8 umfasst der Inhalt aus den Beispielen 1 bis 7, dass der Prozessor ferner eine Protokollzuordnung durchführen soll, um die Nicht-OCF-Eigenschaften in OCF-Ressourcen zu übersetzen.
  • In Beispiel 9 umfasst der Inhalt aus Beispiel 8, dass der Prozessor ferner Plugininformationen bezüglich des Netzwerkprotokolls an einen Routingoptimierer senden soll, um eine externe Zugangsrichtlinie zu erhalten, die mit der Nicht-OCF-Vorrichtung verbunden ist.
  • In Beispiel 10 umfasst der Inhalt aus den Beispielen 1 bis 9, dass das Netzwerkprotokoll der Nicht-OCF-Vorrichtung ein OMA-Lightweight-M2M (LWM2M) Protokoll, ein Protokoll nach einer onem2m-Vorgabe, ein OPC-Unified-Architecture-Protokoll, oder ein Protokoll nach einer Open-Process-Automation-Forum- (OPAF) Vorgabe umfasst.
  • Beispiel 11 ist mindestens ein nichttransitorisches maschinenlesbares Medium, das Anweisungen umfasst, um Open-Connectivity-Foundation- (OCF) und Nicht-OCF-Kommunikationsvorrichtungen zu verbinden, die bei Ausführung durch einen Prozessor den Prozessor veranlassen, Operationen auszuführen, zum: Empfangen einer Angabe von einer OCF-Vorrichtung, die eine Nicht-OCF-Vorrichtung identifiziert, um zu kommunizieren; Identifizieren eines Netzwerkprotokolls der Nicht-OCF-Vorrichtung; Auswählen eines Plugins dem Netzwerkprotokoll entsprechend; Empfangen einer Kommunikation von der OCF-Vorrichtung; Umwandeln der Kommunikation in das Netzwerkprotokoll unter Verwendung des Plugins; und Senden der konvertierten Kommunikation an die Nicht-OCF-Vorrichtung.
  • In Beispiel 12 umfasst der Inhalt aus Beispiel 11, dass die Kommunikation einer OCF-Netzwerkvorgabe entsprechend empfangen wird.
  • In Beispiel 13 umfasst der Inhalt aus den Beispielen 11 bis 12, dass das Netzwerkprotokoll ein Netzwerkprotokoll ist, das nach einer anderen Netzwerkvorgabe als einer OCF-Netzwerkvorgabe aufgebaut ist.
  • In Beispiel 14 umfasst der Inhalt aus Beispielen 11 bis 13, dass die Anweisungen ferner den Prozessor veranlassen, die konvertierte Kommunikation von dem Plugin an einen IoT-Dienst zu routen, wobei der IoT-Dienst die konvertierte Kommunikation an einen Router senden soll, der mit der Nicht-OCF-Vorrichtung über eine Nicht-OCF-Netzwerkbridge auf einem mit der Nicht-OCF-Vorrichtung geteilten Netzwerk verbunden ist.
  • In Beispiel 15 umfasst der Inhalt aus Beispiel 14, dass die Anweisungen ferner den Prozessor veranlassen: eine Reaktion auf die konvertierte Kommunikation von der Nicht-OCF-Vorrichtung über die Nicht-OCF-Netzwerkbridge, den Router, und den IoT-Dienst zu empfangen; die Reaktion von dem Netzwerkprotokoll unter Verwendung des Plugins in ein OCF-Netzwerkprotokoll zu konvertieren; und die konvertierte Reaktion an die OCF-Vorrichtung zu senden.
  • In Beispiel 16 umfasst der Inhalt aus den Beispielen 11 bis 15, dass das Plugin in der Clouddienstvorrichtung aus einem lokalen Netzwerk gespiegelt ist, das die Nicht-OCF-Vorrichtung umfasst.
  • In Beispiel 17 umfasst der Inhalt aus den Beispielen 11 bis 16, dass die Anweisungen ferner den Prozessor veranlassen, das Onboarding der Nicht-OCF-Vorrichtung durchzuführen, bevor die konvertierte Kommunikation an die Nicht-OCF-Vorrichtung gesendet wird.
  • In Beispiel 18 umfasst der Inhalt aus den Beispielen 11 bis 17, dass die Anweisungen ferner den Prozessor veranlassen, eine Protokollzuordnung unter Verwendung des Plugins durchzuführen, um die Nicht-OCF-Eigenschaften in OCF-Ressourcen zu übersetzen.
  • In Beispiel 19 umfasst der Inhalt aus Beispiel 18, dass die Anweisungen ferner den Prozessor veranlassen, Plugininformationen bezüglich des Netzwerkprotokolls an einen Routingoptimierer zu senden, um eine externe Zugangsrichtlinie zu erhalten, die mit der Nicht-OCF-Vorrichtung verbunden ist.
  • Beispiel 20 ist ein Verfahren für die Verbindung von Open-Connectivity-Foundation- (OCF) und Nicht-OCF-Kommunikationsvorrichtungen, das Verfahren umfassend: Empfangen einer Angabe von einer OCF-Vorrichtung, die eine Nicht-OCF-Vorrichtung identifiziert, um zu kommunizieren; Identifizieren eines Netzwerkprotokolls der Nicht-OCF-Vorrichtung; Auswählen eines Plugins dem Netzwerkprotokoll entsprechend; Empfangen einer Kommunikation von der OCF-Vorrichtung; Umwandeln der Kommunikation in das Netzwerkprotokoll unter Verwendung des Plugins; und Senden der konvertierten Kommunikation an die Nicht-OCF-Vorrichtung.
  • In Beispiel 21 umfasst der Inhalt aus Beispiel 20, dass die Kommunikation einer OCF-Netzwerkvorgabe entsprechend empfangen wird.
  • In Beispiel 22 umfasst der Inhalt aus den Beispielen 20 bis 21, dass das Netzwerkprotokoll ein Netzwerkprotokoll ist, das nach einer anderen Netzwerkvorgabe als einer OCF-Netzwerkvorgabe aufgebaut ist.
  • In Beispiel 23 umfasst der Inhalt aus Beispielen 20 bis 22, dass die konvertierte Kommunikation von dem Plugin an einen IoT-Dienst geroutet wird, wobei der IoT-Dienst die konvertierte Kommunikation an einen Router senden soll, der mit der Nicht-OCF-Vorrichtung über eine Nicht-OCF-Netzwerkbridge auf einem mit der Nicht-OCF-Vorrichtung geteilten Netzwerk verbunden ist.
  • In Beispiel 24 umfasst der Inhalt aus Beispiel 23, dass eine Reaktion auf die konvertierte Kommunikation von der Nicht-OCF-Vorrichtung über die Nicht-OCF-Netzwerkbridge, den Router und den IoT-Dienst empfangen wird; die Reaktion von dem Netzwerkprotokoll in ein OCF-Netzwerkprotokoll konvertiert wird; und die konvertierte Reaktion an die OCF-Vorrichtung gesendet wird.
  • In Beispiel 25 umfasst der Inhalt aus den Beispielen 20 bis 24, dass das Plugin in der Clouddienstvorrichtung aus einem lokalen Netzwerk gespiegelt ist, das die Nicht-OCF-Vorrichtung umfasst.
  • In Beispiel 26 umfasst der Inhalt aus den Beispielen 20 bis 25, dass das Onboarding der Nicht-OCF-Vorrichtung durchgeführt wird, bevor die konvertierte Kommunikation an die Nicht-OCF-Vorrichtung gesendet wird.
  • In Beispiel 27 umfasst der Inhalt aus den Beispielen 20 bis 26, dass eine Protokollzuordnung unter Verwendung des Plugins durchgeführt wird, um die Nicht-OCF-Eigenschaften in OCF-Ressourcen zu übersetzen.
  • In Beispiel 28 umfasst der Inhalt aus Beispiel 27, dass Plugininformationen bezüglich des Netzwerkprotokolls an einen Routingoptimierer gesendet werden, um eine externe Zugangsrichtlinie zu erhalten, die mit der Nicht-OCF-Vorrichtung verbunden ist.
  • Beispiel 29 ist eine Vorrichtung für die Verbindung von Open-Connectivity-Foundation- (OCF) und Nicht-OCF-Kommunikationsvorrichtungen, die Vorrichtung umfassend: Mittel zum Empfangen einer Angabe von einer OCF-Vorrichtung, die eine Nicht-OCF-Vorrichtung identifiziert, um zu kommunizieren; Mittel zum Identifizieren eines Netzwerkprotokolls der Nicht-OCF-Vorrichtung; Mittel zum Auswählen eines Plugins dem Netzwerkprotokoll entsprechend; Mittel zum Empfangen einer Kommunikation von der OCF-Vorrichtung; Mittel zum Umwandeln der Kommunikation in das Netzwerkprotokoll unter Verwendung des Plugins; und Mittel zum Senden der konvertierten Kommunikation an die Nicht-OCF-Vorrichtung. In einem spezifischen Beispiel kann das Mittel zum Empfangen und Übertragen durch die Vorrichtung 850 durch die Beispiele der Verarbeitungsschaltungen und Kommunikationsschaltungen wie oben erklärt umgesetzt werden.
  • In Beispiel 30 umfasst der Inhalt aus Beispiel 29 Mittel zum Routen der konvertierten Kommunikation von dem Plugin an einen IoT-Dienst, wobei der IoT-Dienst die konvertierte Kommunikation an einen Router senden soll, der mit der Nicht-OCF-Vorrichtung über eine Nicht-OCF-Netzwerkbridge auf einem mit der Nicht-OCF-Vorrichtung geteilten Netzwerk verbunden ist. In einem spezifischen Beispiel kann das Mittel zum Empfangen und Übertragen durch die Vorrichtung 850 durch die Beispiele der Verarbeitungsschaltungen und Kommunikationsschaltungen wie oben erklärt umgesetzt werden.
  • In Beispiel 31 umfasst der Inhalt aus Beispiel 30 Mittel zum Empfangen einer Reaktion auf die konvertierte Kommunikation von der Nicht-OCF-Vorrichtung über die Nicht-OCF-Netzwerkbridge, den Router und den IoT-Dienst; Mittel zum Konvertieren der Reaktion von dem Netzwerkprotokoll in ein OCF-Netzwerkprotokoll; und Mittel zum Senden der konvertierten Reaktion an die OCF-Vorrichtung. In einem spezifischen Beispiel kann das Mittel zum Empfangen und Übertragen durch die Vorrichtung 850 durch die Beispiele der Verarbeitungsschaltungen und Kommunikationsschaltungen wie oben erklärt umgesetzt werden.
  • In Beispiel 32 umfasst der Inhalt aus den Beispielen 29 bis 31 Mittel zum Onboarding der Nicht-OCF-Vorrichtung, bevor die konvertierte Kommunikation an die Nicht-OCF-Vorrichtung gesendet wird. In einem spezifischen Beispiel kann das Mittel zum Empfangen und Übertragen durch die Vorrichtung 850 durch die Beispiele der Verarbeitungsschaltungen und Kommunikationsschaltungen wie oben erklärt umgesetzt werden.
  • In Beispiel 33 umfasst der Inhalt aus den Beispielen 29 bis 32 Mittel zum Durchführen der Protokollzuordnung unter Verwendung des Plugins, um die Nicht-OCF-Eigenschaften in OCF-Ressourcen zu übersetzen. In einem spezifischen Beispiel kann das Mittel zum Empfangen und Übertragen durch die Vorrichtung 850 durch die Beispiele der Verarbeitungsschaltungen und Kommunikationsschaltungen wie oben erklärt umgesetzt werden.
  • In Beispiel 34 umfasst der Inhalt aus Beispiel 33 Mittel zum Senden von Plugininformationen bezüglich des Netzwerkprotokolls an einen Routingoptimierer, um eine externe Zugangsrichtlinie zu erhalten, die mit der Nicht-OCF-Vorrichtung verbunden ist. In einem spezifischen Beispiel kann das Mittel zum Empfangen und Übertragen durch die Vorrichtung 850 durch die Beispiele der Verarbeitungsschaltungen und Kommunikationsschaltungen wie oben erklärt umgesetzt werden.
  • In Beispiel 35 umfasst der Inhalt aus den Beispielen 29 bis 34, dass die Kommunikation unter Verwendung eines OCF-Kommunikationstyps gesendet wird.
  • In Beispiel 36 umfasst der Inhalt aus den Beispielen 29 bis 35, dass der Kommunikationstyp ein Nicht-OCF-Kommunikationstyp ist.
  • In Beispiel 37 umfasst der Inhalt aus den Beispielen 29 bis 36, dass das Plugin in der Clouddienstvorrichtung aus einem lokalen Netzwerk gespiegelt ist, das die Nicht-OCF-Vorrichtung umfasst.
  • Beispiel 38 ist mindestens ein maschinenlesbares Medium, dass bei Ausführung durch Prozessorschaltkreise die Prozessorschaltkreise veranlasst, Operationen auszuführen, um eines der Beispiele 29 bis 37 umzusetzen.
  • Beispiel 39 ist eine Vorrichtung, umfassend Mittel aus einem der Beispiele 28 bis 36.
  • Beispiel 40 ist ein System zum Umsetzen eines der Beispiele 29 bis 37.
  • Beispiel 41 ist ein Verfahren zum Umsetzen eines der Beispiele 29 bis 37.
  • Beispiel 42 ist ein Vorrichtungsfog, der angepasst ist, die Operationen aus einem der Beispiele 1 bis 37 auszuführen.
  • Beispiel 43 ist ein Vorrichtungseigentümertransferdienst, der angepasst ist, die Operationen des Onboardings auszuführen, die in einem der Beispiele 1 bis 37 aufgerufen wurden.
  • Beispiel 44 ist eine Open-Connectivity-Foundation- (OCF) Vorrichtung, konfiguriert als Server, Client oder Vermittler nach einer OCF-Vorgabe, umfassend Mittel zum Umsetzen der Operationen eines der Beispiele 1 bis 37.
  • Beispiel 45 ist eine Internet of Things (IoT) Netzwerktopologie, wobei die IoT-Netzwerktopologie jeweilige Kommunikationsverbindungen umfasst, die angepasst sind, Kommunikationen für die Operationen eines der Beispiele 1 bis 37 auszuführen.
  • Beispiel 46 ist ein Netzwerk, das jeweilige Vorrichtungen und Vorrichtungskommunikationsmedien umfasst, um eine der Operationen der Beispiele 1 bis 37 auszuführen.
  • Beispiel 47 ist eine Vorrichtung, die Mittel umfasst, um eine der Operationen aus Beispielen 1 bis 37 auszuführen.
  • Beispiel 48 ist ein System, um die Operationen aus einem der Beispiele 1 bis 37 auszuführen.
  • Die oben in diesen Beispielen und in den Ausführungen mit Verweis auf 3 bis 6 beschriebenen Operationen und Funktionen können in einer Vielzahl von Netzwerkeinstellungen wie IoT-Networking, Edge-Networking, Fog-Networking, Cloud-Networking und allen Hybriden davon zutreffen. Die Operationen und Funktionen dieser Beispiele und Konfigurationen können in verteilter Weise auftreten, einschließlich in verteilten Netzwerksettings, in denen ein Aspekt der Funktion durch eine erste IoT-Edge-Vorrichtung oder ein Edge-Netzwerk ausgeführt wird, ein anderer Aspekt der Funktion durch ein Fog-Netzwerk oder eine -Plattform ausgeführt wird, und noch ein anderer Aspekt der Funktion durch eine Cloudvorrichtung oder ein -System ausgeführt wird. Weitere Kombinationen, die diesen geteilten, verteilten oder Gruppierungsgrundsätzen folgen, wie in den obigen Beispielen und Konfigurationen vorgeschlagen, können eingesetzt werden. Dementsprechend ist es offensichtlich, dass die hierin beschriebene Funktion innerhalb vieler Permutationen der obigen Beispiele und Konfigurationen sowie ähnlicher Variationen funktionieren kann.
  • In der obigen detaillierten Beschreibung können verschiedene Merkmale gruppiert sein, um die Offenbarung zu verschlanken. Die 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.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • US 62595324 [0001]

Claims (25)

  1. Clouddienst-Vorrichtung, umfassend: einen Open-Connectivity-Foundation- (OCF) Routingdienst zum: Empfangen einer Angabe von einer OCF-Vorrichtung, die eine Nicht-OCF-Vorrichtung identifiziert, um zu kommunizieren; und Identifizieren eines Netzwerkprotokolls der Nicht-OCF-Vorrichtung; und einen Prozessor zum Ausführen eines Plugins, das dem Netzwerkprotokoll entsprechend gewählt wurde, wobei das Plugin: eine Kommunikation von der OCF-Vorrichtung empfängt; die Kommunikation in das Netzwerkprotokoll konvertiert; und die konvertierte Kommunikation an die Nicht-OCF-Vorrichtung sendet.
  2. Clouddienstvorrichtung nach Anspruch 1, wobei die Kommunikation einer OCF-Netzwerkvorgabe entsprechend empfangen wird.
  3. Clouddienstvorrichtung nach Anspruch 1, wobei das Netzwerkprotokoll ein Netzwerkprotokoll ist, das nach einer anderen Netzwerkvorgabe als einer OCF-Netzwerkvorgabe aufgebaut ist.
  4. Clouddienstvorrichtung nach Anspruch 1, wobei der Prozessor ferner die konvertierte Kommunikation an einen IoT-Dienst routen soll, wobei der IoT-Dienst die konvertierte Kommunikation an einen Router senden soll, der mit der Nicht-OCF-Vorrichtung über eine Nicht-OCF-Netzwerkbridge auf einem mit der Nicht-OCF-Vorrichtung geteilten Netzwerk verbunden ist.
  5. Clouddienstvorrichtung nach Anspruch 4, wobei der Prozessor ferner: eine Reaktion auf die konvertierte Kommunikation von der Nicht-OCF-Vorrichtung über die Nicht-OCF-Netzwerkbridge, den Router und den IoT-Dienst empfangen soll; die Reaktion von dem Netzwerkprotokoll in ein OCF-Netzwerkprotokoll konvertieren soll, und die konvertierte Reaktion an die OCF-Vorrichtung senden soll.
  6. Clouddienstvorrichtung nach Anspruch 1, wobei das Plugin in der Clouddienstvorrichtung aus einem lokalen Netzwerk gespiegelt ist, das die Nicht-OCF-Vorrichtung umfasst.
  7. Clouddienstvorrichtung nach Anspruch 1, wobei der Prozessor ferner das Onboarding der Nicht-OCF-Vorrichtung durchführen soll, bevor die konvertierte Kommunikation an die Nicht-OCF-Vorrichtung gesendet wird.
  8. Clouddienstvorrichtung nach Anspruch 1, wobei der Prozessor ferner eine Protokollzuordnung durchführen soll, um die Nicht-OCF-Eigenschaften in OCF-Ressourcen zu übersetzen.
  9. Clouddienstvorrichtung nach Anspruch 8, wobei der Prozessor ferner Plugininformationen bezüglich des Netzwerkprotokolls an einen Routingoptimierer senden soll, um eine externe Zugangsrichtlinie zu erhalten, die mit der Nicht-OCF-Vorrichtung verbunden ist.
  10. Clouddienstvorrichtung nach Anspruch 1, wobei das Netzwerkprotokoll der Nicht-OCF-Vorrichtung ein OMA-Lightweight-M2M (LWM2M) Protokoll, ein Protokoll nach einer onem2m-Vorgabe, ein OPC-Unified-Architecture-Protokoll, oder ein Protokoll nach einer Open-Process-Automation-Forum- (OPAF) Vorgabe umfasst.
  11. Mindestens ein nichttransitorisches maschinenlesbares Medium, das Anweisungen umfasst, Open-Connectivity-Foundation- (OCF) und Nicht-OCF Kommunikationsvorrichtungen zu verbinden, die bei Ausführung durch einen Prozessor den Prozessor veranlassen, Operationen auszuführen, zum: Empfangen einer Angabe von einer OCF-Vorrichtung, die eine Nicht-OCF-Vorrichtung identifiziert, um zu kommunizieren; Identifizieren eines Netzwerkprotokolls der Nicht-OCF-Vorrichtung; Auswählen eines Plugins dem Netzwerkprotokoll entsprechend; Empfangen einer Kommunikation von der OCF-Vorrichtung; Konvertieren der Kommunikation unter Verwendung des Plugins in das Netzwerkprotokoll; und Senden der konvertierten Kommunikation an die Nicht-OCF-Vorrichtung.
  12. Mindestens ein maschinenlesbares Medium nach Anspruch 11, wobei die Kommunikation einer OCF-Netzwerkvorgabe entsprechend empfangen wird.
  13. Mindestens ein maschinenlesbares Medium nach Anspruch 11, wobei das Netzwerkprotokoll ein Netzwerkprotokoll ist, das nach einer anderen Netzwerkvorgabe als einer OCF-Netzwerkvorgabe aufgebaut ist.
  14. Mindestens ein maschinenlesbares Medium nach Anspruch 11, wobei die Anweisungen ferner den Prozessor veranlassen, die konvertierte Kommunikation von dem Plugin an einen IoT-Dienst zu leiten, wobei der IoT-Dienst die konvertierte Kommunikation an einen Router senden soll, der mit der Nicht-OCF-Vorrichtung über eine Nicht-OCF-Netzwerkbridge auf einem mit der Nicht-OCF-Vorrichtung geteilten Netzwerk verbunden ist.
  15. Mindestens ein maschinenlesbares Medium nach Anspruch 14, wobei die Anweisungen ferner den Prozessor veranlassen: eine Reaktion auf die konvertierte Kommunikation von der Nicht-OCF-Vorrichtung über die Nicht-OCF-Netzwerkbridge, den Router und den IoT-Dienst zu empfangen; die Reaktion unter Verwendung des Plugins von dem Netzwerkprotokoll in ein OCF-Netzwerkprotokoll zu konvertieren; und die konvertierte Reaktion an die OCF-Vorrichtung zu senden.
  16. Mindestens ein maschinenlesbares Medium nach Anspruch 11, wobei das Plugin in einer Clouddienstvorrichtung aus einem lokalen Netzwerk gespiegelt ist, das die Nicht-OCF-Vorrichtung umfasst.
  17. Mindestens ein maschinenlesbares Medium nach Anspruch 11, wobei die Anweisungen ferner den Prozessor veranlassen, das Onboarding der Nicht-OCF-Vorrichtung durchzuführen, bevor die konvertierte Kommunikation an die Nicht-OCF-Vorrichtung gesendet wird.
  18. Mindestens ein maschinenlesbares Medium nach Anspruch 11, wobei die Anweisungen ferner den Prozessor veranlassen, eine Protokollzuordnung unter Verwendung des Plugins durchzuführen, um die Nicht-OCF-Eigenschaften in OCF-Ressourcen zu übersetzen.
  19. Mindestens ein maschinenlesbares Medium nach Anspruch 18, wobei die Anweisungen ferner den Prozessor veranlassen, Plugininformationen bezüglich des Netzwerkprotokolls an einen Routingoptimierer zu senden, um eine externe Zugangsrichtlinie zu erhalten, die mit der Nicht-OCF-Vorrichtung verbunden ist.
  20. Verfahren zum Verbinden von Open-Connectivity-Foundation- (OCF) und Nicht-OCF Kommunikationsvorrichtungen, das Verfahren umfassend: Empfangen einer Angabe von einer OCF-Vorrichtung, die eine Nicht-OCF-Vorrichtung identifiziert, um zu kommunizieren; Identifizieren eines Netzwerkprotokolls der Nicht-OCF-Vorrichtung; Auswählen eines Plugins dem Netzwerkprotokoll entsprechend; Empfangen einer Kommunikation von der OCF-Vorrichtung; Konvertieren der Kommunikation unter Verwendung des Plugins in das Netzwerkprotokoll; und Senden der konvertierten Kommunikation an die Nicht-OCF-Vorrichtung.
  21. Verfahren nach Anspruch 20, ferner umfassend das Routen der konvertierten Kommunikation von dem Plugin an einen IoT-Dienst, wobei der IoT-Dienst die konvertierte Kommunikation an einen Router senden soll, der mit der Nicht-OCF-Vorrichtung über eine Nicht-OCF-Netzwerkbridge auf einem mit der Nicht-OCF-Vorrichtung geteilten Netzwerk verbunden ist.
  22. Verfahren nach Anspruch 21, ferner umfassend: Empfangen einer Reaktion auf die konvertierte Kommunikation von der Nicht-OCF-Vorrichtung über die Nicht-OCF-Netzwerkbridge, den Router und den IoT-Dienst; Konvertieren der Reaktion unter Verwendung des Plugins von dem Netzwerkprotokoll in ein OCF-Netzwerkprotokoll; und Senden der konvertierten Reaktion an die OCF-Vorrichtung.
  23. Verfahren nach Anspruch 20, ferner umfassend das Onboarden der Nicht-OCF-Vorrichtung, bevor die konvertierte Kommunikation an die Nicht-OCF-Vorrichtung gesendet wird.
  24. Verfahren nach Anspruch 20, ferner umfassend das Ausführen einer Protokollzuordnung unter Verwendung des Plugins, um die Nicht-OCF-Eigenschaften in OCF-Ressourcen zu übersetzen.
  25. Verfahren nach Anspruch 24, ferner umfassend das Senden der Plugininformationen bezüglich des Netzwerkprotokolls an einen Routingoptimierer, um eine externe Zugangsrichtlinie zu erhalten, die mit der Nicht-OCF-Vorrichtung verbunden ist.
DE112018005810.7T 2017-12-06 2018-11-06 Plugin-management für internet of things- (iot) netzwerkoptimierung Pending DE112018005810T5 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201762595324P 2017-12-06 2017-12-06
US62/595,324 2017-12-06
US16/110,011 US11483418B2 (en) 2017-12-06 2018-08-23 Plugin management for internet of things (IoT) network optimization
US16/110,011 2018-08-23
PCT/US2018/059416 WO2019112734A1 (en) 2017-12-06 2018-11-06 Plugin management for internet of things (iot) network optimization

Publications (1)

Publication Number Publication Date
DE112018005810T5 true DE112018005810T5 (de) 2020-09-03

Family

ID=65230619

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112018005810.7T Pending DE112018005810T5 (de) 2017-12-06 2018-11-06 Plugin-management für internet of things- (iot) netzwerkoptimierung

Country Status (4)

Country Link
US (1) US11483418B2 (de)
KR (1) KR20200085754A (de)
DE (1) DE112018005810T5 (de)
WO (1) WO2019112734A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11483418B2 (en) 2017-12-06 2022-10-25 Intel Corporation Plugin management for internet of things (IoT) network optimization

Families Citing this family (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3437300A4 (de) 2016-03-29 2020-03-04 Resolution Products, Inc. Universeller protokollumsetzer
US11076024B2 (en) * 2016-12-27 2021-07-27 Intel Corporation Framework for IoT protocol identification and management
US10771463B2 (en) 2017-10-30 2020-09-08 International Business Machines Corporation Third-party authorization of access tokens
US11616781B2 (en) * 2017-12-05 2023-03-28 Goldilock Secure s.r.o. Air gap-based network isolation device
US10687390B2 (en) * 2018-03-09 2020-06-16 Mueller International, Llc Node bridge
JP7059916B2 (ja) * 2018-12-18 2022-04-26 日本電信電話株式会社 情報処理システム、方法およびプログラム
US10764072B2 (en) * 2019-01-23 2020-09-01 Verizon Patent And Licensing Inc. Systems and methods for configuring a private multi-access edge computing environment
US11635990B2 (en) 2019-07-01 2023-04-25 Nutanix, Inc. Scalable centralized manager including examples of data pipeline deployment to an edge system
US11501881B2 (en) 2019-07-03 2022-11-15 Nutanix, Inc. Apparatus and method for deploying a mobile device as a data source in an IoT system
US10893116B1 (en) 2019-07-03 2021-01-12 Nutanix, Inc. Apparatuses and methods for edge computing application deployment in an IoT system
US11321101B2 (en) * 2019-07-10 2022-05-03 Vmware, Inc. Deployment and isolation of plugins in a virtualized computing environment
US11520594B2 (en) * 2019-07-11 2022-12-06 T-Mobile Usa, Inc. Multiple client support on device-based LwM2M
CN113439427B (zh) * 2019-07-24 2023-10-27 Oppo广东移动通信有限公司 一种资源发布方法和设备
CN110798505B (zh) * 2019-09-27 2022-11-22 深圳市火乐科技发展有限公司 插件式物联网设备的管理方法及相关装置
US11102630B2 (en) * 2019-10-25 2021-08-24 Telefonaktiebolaget Lm Ericsson (Publ) Method for service placement in a multi-access/mobile edge computing (MEC) system
US11172440B2 (en) * 2019-11-21 2021-11-09 Motorola Solutions, Inc. System and method for virtual low power wide area network nodes in a low power wide area network gateway
WO2021138899A1 (zh) * 2020-01-10 2021-07-15 Oppo广东移动通信有限公司 信息处理方法、装置及设备
CN114846901B (zh) * 2020-02-18 2024-05-31 Oppo广东移动通信有限公司 通信方法、装置、设备及存储介质
US11436117B2 (en) 2020-05-08 2022-09-06 International Business Machines Corporation Context aware dynamic relative positioning of fog nodes in a fog computing ecosystem
WO2022011563A1 (zh) * 2020-07-14 2022-01-20 Oppo广东移动通信有限公司 物联网配置方法、装置、计算机设备及存储介质
CN115968543A (zh) * 2020-10-26 2023-04-14 Oppo广东移动通信有限公司 资源映射方法、装置、设备及存储介质
US11726764B2 (en) 2020-11-11 2023-08-15 Nutanix, Inc. Upgrade systems for service domains
US11665221B2 (en) 2020-11-13 2023-05-30 Nutanix, Inc. Common services model for multi-cloud platform
CN116547997A (zh) * 2020-12-07 2023-08-04 Oppo广东移动通信有限公司 设备桥接映射的方法和桥接设备
KR102565468B1 (ko) * 2020-12-31 2023-08-11 ㈜에셈블 oneM2M 사물인터넷 플랫폼을 이용한 LoRaWAN 네트워크의 로밍 방법
US11736585B2 (en) 2021-02-26 2023-08-22 Nutanix, Inc. Generic proxy endpoints using protocol tunnels including life cycle management and examples for distributed cloud native services and applications
CN112996071B (zh) * 2021-03-11 2021-12-31 北京交通大学 一种基于用户业务感知的车辆垂直切换方法及***
CN113726579A (zh) * 2021-09-02 2021-11-30 国网信息通信产业集团有限公司 一种电力物联网通信协议插件的实现方法及装置
KR102519701B1 (ko) * 2022-08-31 2023-04-13 주식회사 융창 다양한 프로토콜을 갖는 IoT 디바이스와의 호환성을 제공하는 IoT 게이트웨이 및 그 제어 방법

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3086733A1 (de) 2013-12-20 2016-11-02 Brainlab AG Halter für die befestigung einer referenzmarkiervorrichtung an einem körperteil
US9900382B2 (en) 2015-02-18 2018-02-20 Anna Mazor Promotion of internet-of-things (IOT) connectivity
US9210534B1 (en) 2015-02-19 2015-12-08 Citrix Systems, Inc. Location assistance in a machine to machine instant messaging system
US9977415B2 (en) * 2015-07-03 2018-05-22 Afero, Inc. System and method for virtual internet of things (IOT) devices and hubs
US20170187835A1 (en) 2015-12-26 2017-06-29 Lee Booi Lim Technologies for unified and modular gateway abstraction
US20170279894A1 (en) * 2016-03-22 2017-09-28 Esmart Tech, Inc. Universal internet of things (iot) smart translator
CN107370782B (zh) * 2016-05-13 2021-08-31 京东方科技集团股份有限公司 对设备进行操作的方法、控制装置和代理装置
US10880411B2 (en) 2016-05-23 2020-12-29 Intel Corporation Interdevice communications
US20180084085A1 (en) * 2016-09-20 2018-03-22 Arrayent, Inc. Cross platform device virtualization for an iot system
EP3523724B1 (de) * 2016-10-07 2023-12-06 Convida Wireless, LLC Dienstschichtressourcenverwaltung für generische zusammenarbeit und erweiterbarkeit
US10938926B2 (en) * 2016-12-30 2021-03-02 Fortinet, Inc. User and IoT (internet of things) apparatus tracking in a log management system
US20190089747A1 (en) * 2017-09-19 2019-03-21 Cisco Technology, Inc. Protecting secure session from iot gateways
US10819794B2 (en) * 2017-09-26 2020-10-27 Verizon Patent And Licensing Inc. Distribution hub for internet-of-things data
US10833926B2 (en) * 2017-11-17 2020-11-10 T-Mobile Usa, Inc. Touchless secure bootstrapping of IoT devices
US11483418B2 (en) 2017-12-06 2022-10-25 Intel Corporation Plugin management for internet of things (IoT) network optimization

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11483418B2 (en) 2017-12-06 2022-10-25 Intel Corporation Plugin management for internet of things (IoT) network optimization

Also Published As

Publication number Publication date
US20190045033A1 (en) 2019-02-07
US11483418B2 (en) 2022-10-25
WO2019112734A1 (en) 2019-06-13
KR20200085754A (ko) 2020-07-15

Similar Documents

Publication Publication Date Title
DE112018005810T5 (de) Plugin-management für internet of things- (iot) netzwerkoptimierung
DE112018007463T5 (de) Flexibler Mehrfachzugriffs-Edge-Computing-Dienstverbrauch (Mec-Dienstverbrauch) durch Hostzoning
DE112020004736T5 (de) Edge-computing-technologien für transportschichtüberlastregelung und point-of-presence-optimierungen auf grundlage erweiterter vorab-dienstgüte-benachrichtigungen
DE112018005693T5 (de) Multi-access edge computing (mec)-basierte mehrbetreiberunterstützung für cellular vehicle-to-everything (c-v2x) systeme
US11770383B2 (en) Cloud-to-device mediator service from services definition
DE102019105398A1 (de) Inter-mec-systemkommunikation für v2x-services
DE112020002310T5 (de) V2x-dienste zur bereitstellung fahrtspezifischer qos-vorhersagen
DE112020001183T5 (de) Multi-slice-unterstützung für mec-fähige 5g-implementierungen
DE102022200847A1 (de) Bestärkendes lernen für mehrfachzugriffsverkehrsverwaltung
DE102019217367A1 (de) VERWALTUNG DER DIENSTQUALITÄT (QoS) IN EDGE-COMPUTING-UMGEBUNGEN
DE102019123244A1 (de) Verbesserungen der verfolgung von multi-access-edgecomputing (mec)-gebührenerfassung und -abrechnung
DE102021211176A1 (de) Interoperables framework für sicheren verbrauch von dual-modus-edge-anwendungsprogrammierungsschnittstellen in hybriden edge-computing-plattformen
DE102021209988A1 (de) Techniken zur klassifizierung und priorisierung von mehrfachzugangsverwaltungsdienstpaketen
DE102020202398A1 (de) Edge-server-cpu mit dynamischer deterministischer skalierung
DE112017004996T5 (de) Gatewaykoordination für das Internet der Dinge
US20220248226A1 (en) Dynamic access policy provisioning in a device fog
CN112740181A (zh) 具有多个边缘主机和用户设备的基于mec的分布式计算环境
DE112018006701T5 (de) Multihardware-beschleunigte inferenz auf der basis von dienstgütevereinbarungen
US11388217B2 (en) Edge or fog gateway assisted out-of-band remote management for managed client devices
US20200067938A1 (en) Internet of things (iot) network domain resource model
DE112019003316T5 (de) Verteiltes berechnungsverfahren, vorrichtung und system
DE112018006935T5 (de) Sicherheitsprofile für OCF-Vorrichtungen und vertrauenswürdige Plattformen
DE102021210882A1 (de) Erweitertes peer-to-peer (p2p) mit edge-vernetzung
DE102022203249A1 (de) Mehrfachzugriff-edge-computing- (mec-) fahrzeug-zu-alles-(v2x-) interoperabilitätsunterstützung für mehrere v2x-nachrichtenbroker
DE102022212395A1 (de) Ende-zu-ende-netzwerk-slicing (ens) vom ran- zum kernnetz für kommunikationen der nächsten generation (ng)

Legal Events

Date Code Title Description
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0029080000

Ipc: H04L0065000000