DE112017004996T5 - Gatewaykoordination für das Internet der Dinge - Google Patents

Gatewaykoordination für das Internet der Dinge Download PDF

Info

Publication number
DE112017004996T5
DE112017004996T5 DE112017004996.2T DE112017004996T DE112017004996T5 DE 112017004996 T5 DE112017004996 T5 DE 112017004996T5 DE 112017004996 T DE112017004996 T DE 112017004996T DE 112017004996 T5 DE112017004996 T5 DE 112017004996T5
Authority
DE
Germany
Prior art keywords
iot
gateway devices
ownership
coordination
devices
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
DE112017004996.2T
Other languages
English (en)
Inventor
Mats Agerstam
Robert A. Colby
Vijay Sarathi Kesavan
Douglas K. Hudson
Joseph L. Morrow
Shilpa Sodani
Sashi Kumar Penta
Thuyen Tran
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 DE112017004996T5 publication Critical patent/DE112017004996T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • 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/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/18—Self-organising networks, e.g. ad-hoc networks or sensor networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/16—Gateway arrangements

Landscapes

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

Abstract

Ein Internet der Dinge (IoT)-System und -verfahren mit IoT-Sensoren zum Messen von Daten und zum Weiterleiten der Daten an Gateway-Vorrichtungen, wobei die Gateway-Vorrichtungen die Daten empfangen und die Daten an eine Cloud-Infrastruktur liefern, und mit einem Koordinator, um den Gateway-Vorrichtungen Besitz an den IoT-Sensoren zuzuweisen.

Description

  • Querverweis auf verwandte Anmeldung
  • Die vorliegende Anmeldung beansprucht den Nutzen des Einreichungsdatums der US-Patentanmeldung Nr. 15/282 276 von Mats Agerstam, et al. mit dem Titel „INTERNET-OF-THINGS GATEWAY COORDINATION“, eingereicht am 30. September 2016, die hierin durch Bezugnahme aufgenommen ist.
  • Technisches Gebiet
  • Die vorliegenden Techniken betreffen im Allgemeinen das Internet der Dinge (IoT) und insbesondere eine Gateway/Gateway-Koordination in einem IoT-System.
  • Allgemeiner Stand der Technik
  • Ein Gesichtspunkt des Internets ist die Verbindung von Clients, wie PCs, Tablets, Smartphones, Servern, digitalen Fotorahmen und vielen anderen Arten von Vorrichtungen mit öffentlich zugänglichen Datenzentren, die in Serverfarmen gehostet werden. Dieses Bild stellt jedoch nur einen kleinen Teil der Gesamtnutzung des global verbundenen Netzes dar. Es existiert derzeit eine sehr große Anzahl von verbundenen Ressourcen, die jedoch nicht öffentlich zugänglich sind. Beispiele dafür sind Unternehmensnetzwerke, private organisatorische Steuerungs- und Überwachungsnetzwerke rund um den Globus und Peer-to-Peer-Relais, die auf Anonymität ausgelegt sind.
  • Das Internet der Dinge (IoT) könnte bis 2020 mehr als 50 Milliarden Geräte mit Internet-Konnektivität versorgen. Für Organisationen können IoT-Vorrichtungen Möglichkeiten zum Überwachen, Verfolgen oder Steuern anderer Vorrichtungen und Objekte vorsehen, darunter weitere IoT-Vorrichtungen, andere Heim- und Industrievorrichtungen, Objekte in Herstellungs- und Lebensmittelproduktionsketten und dergleichen. Weiter hat die Entstehung von IoT-Netzwerken als Katalysator für einen tiefgreifenden Wandel in der Entwicklung des Internets gedient. In Zukunft dürfte sich das Internet von einer primär menschenorientierten Versorgungseinrichtung zu einer Infrastruktur entwickeln, in der Menschen letztendlich eine Minderheit von Akteuren in einer vernetzten Welt von Vorrichtungen sein könnten.
  • Figurenliste
    • 1 zeigt eine Zeichnung eines Cloud-Computernetzwerks oder einer Cloud in Kommunikation mit einer Anzahl von Internet der Dinge (Internet of Things, IoT)-Vorrichtungen gemäß Ausführungsformen der vorliegenden Techniken.
    • 2 zeigt eine Zeichnung eines Cloud-Computernetzwerks oder einer Cloud in Kommunikation mit einem Maschennetzwerk von IoT-Vorrichtungen, die als „Fog“-Vorrichtung bezeichnet werden können und am Rande der Cloud arbeiten, gemäß Ausführungsformen der vorliegenden Techniken.
    • 3 zeigt ein Diagramm eines IoT-Systems mit einem IoT-Netzwerk von Sensoren und Gateway-Vorrichtungen gemäß Ausführungsformen der vorliegenden Techniken.
    • 4 zeigt ein Diagramm des IoT-Netzwerks, das eine zentralisierte Koordination für Gateway-Besitz an Sensoren gemäß Ausführungsformen der vorliegenden Techniken verwendet.
    • 5 zeigt ein Diagramm des IoT-Netzwerks, das eine kooperative Koordination für Gateway-Besitz an Sensoren gemäß Ausführungsformen der vorliegenden Techniken verwendet.
    • 6 zeigt ein Diagramm des IoT-Netzwerks, das eine dezentralisierte Koordination für Gateway-Besitz an Sensoren gemäß Ausführungsformen der vorliegenden Techniken verwendet.
    • 7 zeigt ein Blockflussdiagramm eines Verfahrens zum Betreiben eines IoT-Systems gemäß Ausführungsformen der vorliegenden Techniken.
    • 7A zeigt ein Blockflussdiagramm eines Verfahrens zum Betreiben eines IoT-Systems gemäß Ausführungsformen der vorliegenden Techniken.
    • 8 zeigt ein Diagramm einer Computervorrichtung für ein IoT-System gemäß Ausführungsformen der vorliegenden Techniken.
    • 9 zeigt ein Diagramm einer Computervorrichtung für ein IoT-System gemäß Ausführungsformen der vorliegenden Techniken.
    • 10 zeigt ein Blockdiagramm, das ein computerlesbares Medium zum Ermöglichen von Gateway-Besitz an IoT-Sensoren darstellt, gemäß Ausführungsformen der vorliegenden Techniken.
  • In der Offenbarung und in den Figuren werden zum Verweisen auf gleiche Komponenten und Merkmale durchwegs dieselben Bezugszeichen verwendet. Bezugszeichen in den 100er-Reihen beziehen sich auf Merkmale, die ursprünglich in 1 zu finden sind; Bezugszeichen in den 200er-Reihen beziehen sich auf Merkmale, die ursprünglich in 2 zu finden sind; usw.
  • Beschreibung der Ausführungsformen
  • Die vorliegenden Techniken betreffen ein IoT-System, das IoT-Sensoren zum Messen von Daten und zum Weiterleiten der Daten an Gateway-Vorrichtungen enthält. Die Gateway-Vorrichtungen empfangen die Daten und können die Daten z.B. einer Cloud-Infrastruktur zuführen. Im Betrieb entscheiden die Gateway-Vorrichtungen und/oder die IoT-Sensoren über Besitz an den IoT-Sensoren und weisen diesen den Gateway-Vorrichtungen zu. In einem Beispiel weist das IoT-System einen Kommunikationskanal zwischen den Gateway-Vorrichtungen auf, wobei die Gateway-Vorrichtungen eine zentralisierte Koordination zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen implementieren. Diese zentralisierte Koordination kann auf ein Koordinationsprotokoll zwischen den Gateway-Vorrichtungen zurückgreifen. In einem weiteren Beispiel weist das IoT-System den Kommunikationskanal zwischen den Gateway-Vorrichtungen auf, wobei jedoch sowohl die Gateway-Vorrichtung als auch die IoT-Sensoren eine kooperative Koordination zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen implementieren. Die kooperative Koordination kann auf ein Koordinationsprotokoll zwischen den Gateway-Vorrichtungen und auf Beacon-Signale der IoT-Sensoren zurückgreifen. In noch einem weiteren Beispiel implementieren die IoT-Sensoren eine dezentralisierte Koordination zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen, und bei der die Gateway-Vorrichtungen möglicherweise nicht unmittelbar an der Entscheidung über den Besitz beteiligt sind. Mit dieser dezentralisierten Option können die IoT-Sensoren auf ein Beacon-Signal der Gateway-Vorrichtungen in den IoT-Vorrichtungen zurückgreifen, das über den Besitz entscheidet.
  • Darüber hinaus können die Gateways in bestimmten Ausführungsformen im Allgemeinen mehrere drahtlose Technologien einschließlich eines heterogenen Netzwerks unterstützen. Das heißt, wenn eine Gateway-Vorrichtung mehrere Schnittstellen hat, kann die Gateway-Vorrichtung Sensor-Nodes verwalten bzw. mit diesen interagieren, die Bluetooth® Low Energy (BLE), IEEE-Standard 802.15.4 und dergleichen verwenden. Somit kann ein Übergabe („Handoff“) von Gateway-Vorrichtung zu Gateway-Vorrichtung die Fähigkeiten anderer Gateway-Vorrichtungen berücksichtigen. Darüber hinaus kann ein Gateway-Besitz an einem Sensor oder eines Satzes von Sensoren bedeuten, dass das Gateway eine Zuständigkeit zum Vermitteln und Melden von Daten von dem Sensor oder dem Satz von Sensoren besitzt. Möglicherweise wird der Besitz jedoch nicht immer vollständig durch das System verstanden, und es können Mehrdeutigkeiten entstehen, da mehrere Gateways Daten von denselben Sensoren, eine unnötige erhöhte Verkehrsbelastung des Systems und dergleichen melden. Weiter ist ein Besitz einer Gateway-Vorrichtung an einem Sensors, wie im Folgenden erläutert, möglicherweise nicht konstant. Hierin implementierte Besitzsmechanismen können die Verwaltung und Effizienz des Systems steigern und können orthogonale Sensorfunktionen sein. Darüber hinaus kann eine Gateway-Vorrichtung zusätzlich zur Aufwärtsmeldung von Sensor- an Gateway-Vorrichtungen mit einem Sensor kommunizieren, wobei ein Besitz den „Over-the-Air“-Verkehr reduzieren kann. Schlussendlich können verschiedene Faktoren, wie etwa Qualitätskennzahlen, Signalstärke, Lastausgleich und dergleichen, beim Treffen von Besitzentscheidungen berücksichtigt werden.
  • Herkömmliche Implementierungen von IoTähnlichen Lösungen in industriellen Bereichen verwenden typischerweise einen drahtgebundene Schnittstellenverbinder für Gateway/Sensor-Verbindungen, um drahtlose Beschränkungen zu umgehen. Im Gegensatz dazu können, während Ausführungsformen hierin drahtgebundene Verbindungen verwenden können, die Techniken eine Methodik für eine Koordinationsfunktion zugunsten einer größeren IoT-Infrastruktur vorsehen, die ein drahtloses Sensornetzwerk (Wireless Sensor Network, WSN) in einem öffentlichen, kommerziellen oder industriellen Umfeld verwendet. Dies kann für industrielle Umgebungen von Vorteil sein, in denen die Anzahl der Sensoren und Gateways im Vergleich zu beispielsweise einer Wohnumgebung typischerweise groß sein kann. Tatsächlich kann die Skalierbarkeit in industriellen oder kommerziellen IoT-Systemen üblicherweise eine Herausforderung darstellen. Darüber hinaus kann die vorliegende Koordination vorteilhafterweise durch die Gateways und/oder Sensoren unabhängig von der Cloud oder der zentralen Verwaltungsinfrastruktur implementiert werden.
  • Wie angegeben, können die Techniken Verfahrensweisen und Architekturen beinhalten, die es ermöglichen, dass Sensorvorrichtungen zu einem beliebigen vorgegebenen Zeitpunkt von einem Gateway (GW), z.B. zu einem vorgegebenen Zeitpunkt von genau einem GW, verwaltet oder „besessen“ werden. Der Besitz an einer Sensorvorrichtung kann eine vorübergehende Eigenschaft sein und kann basierend auf einer Vielzahl von Kriterien, wie Nähe, Lastausgleich, GW-Fehlererkennung und anderen Bedingungen, von einem GW auf ein anderes GW übertragen werden.
  • Die Anzahl der drahtlosen IoT-Sensornetzwerke (Wireless Sensor Networks, WSNs) in der Welt kann weiter explosionsartig wachsen, da immer mehr Wert aus WSNs abgeleitet wird. Mit der zunehmenden Anzahl von an einem WSN teilnehmenden Nodes und Gateways wird der Vorteil einer Koordinationsfunktion zwischen diesen Gateways, wie sie mit den vorliegenden Techniken vorgesehen wird, zunehmend nutzbringend. Die Techniken können einen Rahmen für die Gateway/Gateway-Koordination in industriellen IoT-Systemen beinhalten. Die Koordination kann ein Verfolgen bezüglich Anlagen wie Nodes beinhalten, die Sensoren und Aktoren enthalten.
  • Tatsächlich können die Techniken eine Gateway/Gateway-Koordination von Sensorverfolgungs- und Kantenanalysefunktionen ermöglichen. Somit kann das Gateway oder die Gateway-Vorrichtung in dem IoT-System einzigartig als mehr als ein Datenaggregator und - weiterleiter eingesetzt werden. Das Gateway kann zusätzlich die Koordinationsfunktionalität vereinfachen, was eine Bandbreite, die für die Kommunikation mit einer Cloud oder einem zentralen Standort genutzt wird, verringern kann. Weiter kann das IoT-System selbstorganisierend sein. Obwohl die Techniken nicht auf einen Industriestandard beschränkt sind, können bestimmte Ausführungsformen darüber hinaus den Open Connectivity Foundation ™ (OCF)-Standard oder andere Standards, beispielsweise in einem öffentlichen, kommerziellen oder industriellen IoT-Umfeld, implementieren.
  • Eine Funktion des IoT-Gateways (GW) ist, Daten von den Sensorvorrichtungen zu empfangen, mit cloudbasierten Servern zu kommunizieren, um einzelne oder aggregierte Sensordaten hochzuladen, Sicherheitsschlüssel zu empfangen, und dergleichen. GWs kommunizieren auch mit anderen GWs, um einen Lastausgleich von Sensorplattformen, eine Übergabe einer Sensorplattform, eine Datenaggregation und - filterung sowie einen Austausch von Verschlüsselungsschlüsseln einer Sensorplattform und dergleichen vorzusehen. Jedes IoT-Gateway kann an einem Cluster von drahtlosen Sensor-Nodes teilnehmen und ist in der Regel insofern von Vorteil, als das Gesamtsystem effektiv arbeitet. Darüber hinaus können GWs ressourcenreiche Vorrichtungen sein, die in der Lage sind, Techniken des maschinellen Lernens (ML) auf die von den Sensorplattformen empfangenen Daten anzuwenden, um analytische Fähigkeiten zu bieten. Diese Anwendung von GWs kann erwünscht sein, damit die Analyse der Sensorrohdaten anstelle einer Weitergabe der Sensordaten an einen zentralen Server in einer Cloud an der „Schrankengrenze“ durchgeführt werden kann.
  • Die Fähigkeit von GWs zur Koordination untereinander hilft, selbstorganisierende IoT-Netzwerke an der Netzwerkperipherie mit dezentralisierter Intelligenz (d.h. nicht Cloud-zentrisch) zu verwirklichen. Daher können eine für eine Cloud erforderliche Kommunikationsbandbreite sowie der Stromverbrauch eines Systems, ein verteiltes Rechnen und dergleichen im Allgemeinen vermindert werden. Zusammenfassend lässt sich sagen, dass bestimmte Ausführungsformen hierin Lösungen für Koordinationsfunktionen sind. Mindestens drei verschiedene Beispiele für Koordinationslösungen werden besprochen. Es kommen weitere beispielhafte Implementierungen in Betracht und können angewendet werden. Wie im Folgenden näher erläutert, beinhalten beispielhafte Implementierungen eine zentralisierte (oder node-agnostische) Koordination, eine kooperative Koordination, eine dezentralisierte (oder nodeverwaltete) Koordination und dergleichen.
  • Die zentralisierte Koordination (oder sensoragnostische Koordination) kann ein Inter-GW-Protokoll (Kommunikation zwischen GWs) für die GWs gemeinsam verwenden, um Besitz an den verfügbaren Nodes (Sensoren, Aktoren, etc.) zu bestimmen. Das Signalisierungsprotokoll zwischen den GWs kann ein bestehender IoT-Standard (z.B. OCF) oder anwendereigen sein. In einer zentralisierten Koordinationsimplementierung (z.B. 4) kennen die Sensorvorrichtungen ihr GW möglicherweise nicht. Mit anderen Worten, weiß ein vorgegebener Sensor möglicherweise nicht, welches GW ihr Besitzer ist (oder welches GW den Sensor verfolgt).
  • Was die kooperative Koordination betrifft (z.B. 5), können die IoT-Sensoren an der Bestimmung der GWs eines GW-Besitzes an Sensoren beteiligt sein. In Bezug auf die Besitzbestimmung können die GWs die Nutzdaten im Betrieb in einem periodischen, unaufgeforderten Steuerverkehr, z.B. Beacon-Signale, die die Sensorvorrichtungen zur Datenmeldung aussenden, wirksam nutzen. Die drahtlose Technologie zur Übertragung der periodischen Beacon-Signale kann beispielsweise Bluetooth® Low Energy oder eine andere leistungsarme, drahtlose Nahbereichstechnologie sein, die Beacon-Signal-Fähigkeit bietet. Die GWs können die reservierten Nutzdaten in den Beacon-Signalen nutzen, um ihren GW-Besitz und die Verfolgung eines Sensors gemeinsam mit den Besitzübertragungskriterien zuzuweisen. Wenn ein besser geeignetes GW verfügbar wird, kann das besser geeignete GW den Sensorbesitz beanspruchen, indem es sich mit dem Sensor verbindet und seine GW-Besitz- und Besitzübertragungskriterien an den Sensor schreibt.
  • Für die dezentralisierte oder verteilte Koordination (z.B. 6) verwalten die Sensorvorrichtungen in der verteilten verwalteten Koordination ihren Besitzzugehörigkeit zu einem GW unabhängig von dem zentralen GW-Netzwerk. Die Sensoren treffen ihre Entscheidungen darüber, welches GW einen Sensor verfolgen/besitzen soll, beispielsweise anhand ähnlicher Besitzkriterien wie in den zuvor beschriebenen Modellen.
  • 1 und 2 zeigen beispielhaft die Gesamttopologie und -architektur von IoT-Systemen und eine umfassende Koordination von GW-Besitz an IoT-Sensoren. 4 bis 6 stellen Beispiele für eine solche Koordination des GW-Besitzes an IoT-Sensoren dar.
  • Im Allgemeinen weist das Internet der Dinge (IoT) ein Muster auf, bei dem eine große Anzahl von Computervorrichtungen untereinander und mit dem Internet verbunden sind, um Funktionalität und Datenerfassung auf sehr niedrigen Ebenen vorzusehen. In dem hier verwendeten Sinne kann eine IoT-Vorrichtung eine teilautonome Vorrichtung beinhalten, die eine Funktion, wie z.B. unter anderem ein Erfassen oder Steuern, in Kommunikation mit anderen IoT-Vorrichtungen und einem breiteren Netzwerk, wie z.B. dem Internet, ausführt. Häufig sind IoT-Vorrichtungen hinsichtlich ihres Speicher, ihrer Größe oder ihrer Funktionalität begrenzt, so dass größere Anzahlen zu ähnlichen Kosten eingesetzt werden können wie kleinere Anzahlen größerer Vorrichtungen. Eine IoT-Vorrichtung kann allerdings ein Smartphone, ein Laptop, ein Tablet, ein PC oder auch eine größere Vorrichtung sein. Darüber hinaus kann eine IoT-Vorrichtung eine virtuelle Vorrichtung sein, wie beispielsweise eine Anwendung auf einem Smartphone oder auf einer sonstigen Computervorrichtung. IoT-Vorrichtungen können IoT-Gateways enthalten, die zum Koppeln von IoT-Vorrichtungen an andere IoT-Vorrichtungen und an Cloud-Anwendungen, zur Datenspeicherung, Prozesskontrolle und dergleichen verwendet werden.
  • Netzwerke von IoT-Vorrichtungen können kommerzielle und haustechnische Vorrichtungen beinhalten, wie z.B. Wasserverteilungssysteme, elektrische Energieverteilungssysteme, Rohrleitungssteuersysteme, Anlagensteuersysteme, Lichtschalter, Thermostate, Schlösser, Kameras, Alarmvorrichtungen, Bewegungsmelder, Fabrikautomatisierung, Smart Building, Anlagenverfolgung/-logistik, Betriebstechnik (Operation Technology, OT) mit Industrie-/Fabriknetzwerken und dergleichen. Die IoT-Vorrichtungen können über entfernte Computer, Server und andere Systeme zugänglich sein, z.B. zum Steuern von Systemen oder zum Zugreifen auf Daten.
  • Das zukünftige Wachstum des Internets kann eine sehr hohe Anzahl von IoT-Vorrichtungen beinhalten. Dementsprechend, wie hierin beschrieben, betreffen eine Reihe von Innovationen für das zukünftige Internet die Notwendigkeit, dass alle diese Schichten ungehindert wachsen, um verbundene Ressourcen zu entdecken und zugänglich zu machen und die Fähigkeit zu unterstützen, verbundene Ressourcen zu verbergen und aufzuteilen. Es können beliebig viele Netzwerkprotokolle und Kommunikationsstandards verwendet werden, wobei jedes Protokoll und jeder Standard dazu ausgelegt ist, spezifische Zielsetzungen anzusprechen. Darüber hinaus sind die Protokolle Teil der Struktur, die für Menschen zugängliche Dienste unterstützt, die unabhängig von Standort, Zeit und Raum arbeiten. Zu den Innovationen gehören die Bereitstellung von Diensten und die dazugehörige Infrastruktur, wie Hard- und Software. Die Dienstleistungen können in Übereinstimmung mit den Dienstgüte(Quality of Service, QoS)-Bedingungen erbracht werden, die in Dienstebenen- und Dienstübermittlungsvereinbarungen festgelegt sind. Der Einsatz von IoT-Vorrichtungen und -Netzwerken stellt eine Reihe neuer Herausforderungen in einem heterogenen Netzwerk von Konnektivität dar, das eine Kombination aus drahtgebundenen und drahtlosen Technologien umfasst, wie in 1 und 2 veranschaulicht.
  • 1 zeigt eine Zeichnung eines Cloud-Computernetzwerks oder einer Cloud 102, in Kommunikation mit einer Anzahl von Internet der Dinge (Internet of Things, IoT)-Vorrichtungen. Die Cloud 102 kann das Internet darstellen oder ein lokales Netzwerk (Local Area Network, LAN) oder ein Großraumnetzwerk (Wide Area Network, WAN) sein, wie beispielsweise ein firmeneigenes Netzwerk für ein Unternehmen. Die Cloud 102 kann mit einem oder mehreren Servern 104 in Verbindung stehen, die Befehls- und Steuerfunktionen vorsehen oder Daten von den IoT-Vorrichtungen beziehen können. Die IoT-Vorrichtungen können eine beliebige Anzahl unterschiedlicher Arten von Vorrichtungen beinhalten, die in verschiedenen Kombinationen gruppiert sind. So kann beispielsweise eine Verkehrssteuerungsgruppe 106 IoT-Vorrichtungen entlang von Straßen in einer Stadt beinhalten. Diese IoT-Vorrichtungen können Verkehrsampeln, Verkehrsflussmonitore, Kameras, Wettersensoren und dergleichen beinhalten. Die Verkehrssteuerungsgruppe 106 oder andere Untergruppen können über drahtlose Verbindungen 108, wie beispielsweise leistungsarme Weitbereichs(Low Power Wide Area, LPWA)-Verbindungen und dergleichen, mit der Cloud 102 in Kommunikation stehen. Darüber hinaus kann ein verdrahtetes oder drahtloses Teilnetzwerk 112, wie beispielsweise ein lokales Netzwerk, ein drahtloses lokales Netzwerk und dergleichen, den IoT-Vorrichtungen ermöglichen, miteinander zu kommunizieren. Die IoT-Vorrichtungen können eine andere Vorrichtung, wie beispielsweise ein Gateway 110, das als Aggregator oder Aggregationsvorrichtung arbeiten kann, verwenden, um mit der Cloud 102 zu kommunizieren.
  • Andere Gruppen von IoT-Vorrichtungen können Temperatursensoren 114, entfernte Wetterstationen 116, Alarmsysteme 118, Geldautomaten 120, Warntafeln 122 oder bewegliche Fahrzeuge, wie z.B. Noteinsatzfahrzeuge 124 oder Drohnen 126, und vieles mehr beinhalten. Jede dieser IoT-Vorrichtungen kann mit anderen IoT-Vorrichtungen, mit Servern 104 oder beidem in Kommunikation stehen.
  • Wie aus 1 ersichtlich, kann eine große Anzahl von IoT-Vorrichtungen über die Cloud 102 kommunizieren. Dies kann ermöglichen, dass verschiedene IoT-Vorrichtungen autonom Information anfordern oder anderen Vorrichtungen zuführen. So kann beispielsweise die Verkehrssteuerungsgruppe 106 eine aktuelle Wettervorhersage von einer Gruppe von entfernten Wetterstationen 116 anfordern, die die Vorhersage ohne ein menschliches Zutun abgeben kann. Darüber hinaus kann ein Noteinsatzfahrzeug 124 durch einen Geldautomaten 120 gewarnt werden, dass ein Einbruchsdiebstahl im Gange ist. Während das Noteinsatzfahrzeug 124 zu dem Geldautomaten 120 fährt, kann es auf die Verkehrssteuerungsgruppe 106 zugreifen, um eine freie Anfahrt zu dem Standort anzufordern, z.B. indem die Verkehrsampel auf Rot schaltet, um den Querverkehr an einer Kreuzung rechtzeitig zu blockieren, so dass das Noteinsatzfahrzeug 124 ungehindert in die Kreuzung einfahren kann.
  • Cluster von IoT-Vorrichtungen, wie z.B. die entfernten Wetterstationen 116 oder die Verkehrssteuerungsgruppe 106, können für die Kommunikation mit anderen IoT-Vorrichtungen sowie mit der Cloud 102 ausgestattet sein. Dies kann den IoT-Vorrichtungen ermöglichen, ein Ad-hoc-Netzwerk zwischen den Vorrichtungen zu bilden, das ihnen ermöglicht, als eine einzige Vorrichtung zu arbeiten, die als eine Fog-Vorrichtung bezeichnet werden kann, die mit Bezug auf 2 weiter erläutert wird.
  • 2 zeigt eine Zeichnung 200 eines Cloud-Computernetzwerks oder einer Cloud 102 in Kommunikation mit einem Maschennetzwerk von IoT-Vorrichtungen, das als eine Fog-Vorrichtung 202 bezeichnet werden kann und am Rande der Cloud 102 arbeitet. Gleich bezeichnete Objekte sind wie bezüglich 1 beschrieben. In diesem Beispiel stellt die Fog-Vorrichtung 202 eine Gruppe von IoT-Vorrichtungen an einer Straßenkreuzung dar. Die Fog-Vorrichtung 202 kann in Übereinstimmung mit den Spezifikationen errichtet werden, die unter anderem durch das OpenFog Consortium (OFC) veröffentlicht wurden. Diese Spezifikationen ermöglichen die Bildung einer Hierarchie von Rechenelementen zwischen den Gateways 110, die die Fog-Vorrichtung 202 mit der Cloud 102 und Endpunktvorrichtungen, wie in diesem Beispiel die Verkehrsampeln 204 und die Datenaggregatoren 206, koppeln.
  • Der Verkehrsfluss über die Kreuzung kann in diesem Beispiel durch drei Verkehrsampeln 204 gesteuert werden. Die Analyse der Verkehrsfluss- und Steuerungsschemata kann durch Aggregatoren 206 durchgeführt werden, die mit den Verkehrsampeln 204 und untereinander über ein Maschennetzwerk in Kommunikation stehen. Über Gateways 110, die über das Maschennetzwerk mit den Verkehrsampeln 204 und den Aggregatoren 206 in Kommunikation stehen, können Daten zur Cloud 102 hochgeladen werden und Befehle von der Cloud 102 empfangen werden.
  • In der Fog-Vorrichtung 202 können beliebig viele Kommunikationsverbindungen verwendet werden. Nahbereichsverbindungen 208, die beispielsweise mit IEEE 802.15.4 kompatibel sind, können zwischen IoT-Vorrichtungen, die sich in der Nähe der Kreuzung befinden, eine lokale Kommunikation ermöglichen. Weitbereichsverbindungen 210, die beispielsweise mit den LPWA-Standards kompatibel sind, können Kommunikationen zwischen den IoT-Vorrichtungen und den Gateways 110 vorsehen. Zur Vereinfachung des Diagramms ist nicht jede Kommunikationsverbindung 208 oder 210 mit einem Bezugszeichen bezeichnet.
  • Die Fog-Vorrichtung 202 kann als ein massiv vernetztes Netzwerk betrachtet werden, wobei eine Anzahl von IoT-Vorrichtungen, zum Beispiel über die Kommunikationsverbindungen 208 und 210, miteinander kommunizieren. Das Netzwerk kann unter Nutzung der Standardspezifikation 1.0 des Open Interconnect Consortium (OIC) eingerichtet sein, die am 23. Dezember 2015 von der Open Connectivity Foundation ™ (OCF) veröffentlicht wurde. Diese Norm ermöglicht es Vorrichtungen, sich gegenseitig zu entdecken und Kommunikationen für Verbindungen herzustellen. Es können auch andere Verbindungsprotokolle verwendet werden, wie beispielsweise das Routing-Protokoll für Low-Power (RPL), das Optimized Link State Routing (OLSR)-Protokoll oder das Better Approach To Mobile Ad-hoc Networking (B.A.T.M.A.N.), unter vielen anderen.
  • Die Kommunikation von jeder IoT-Vorrichtung kann zwischen jeder der IoT-Vorrichtungen auf dem zweckmäßigsten Weg weitergeleitet werden, um die Gateways 110 zu erreichen. In diesen Netzen bietet die Anzahl der Verbindungen eine erhebliche Redundanz, die es ermöglicht, Kommunikationen selbst bei Verlust mehrerer IoT-Vorrichtungen aufrechtzuerhalten.
  • Möglicherweise sind nicht sämtliche IoT-Vorrichtungen dauerhafte Mitglieder der Fog-Vorrichtung 202. Im Beispiel in der Zeichnung 200 sind drei vorübergehende IoT-Vorrichtungen, nämlich ein erstes Fahrzeug 212, ein zweites Fahrzeug 214 und ein Fußgänger 216, der Fog-Vorrichtung 202 beigetreten. In diesen Fällen kann die IoT-Vorrichtung in den Fahrzeugen 212 und 214 eingebaut sein, oder sie kann eine App auf einem Mobiltelefon sein, das der Fußgänger 216 mit sich führt.
  • Die Fog-Vorrichtung 202 der Vorrichtungen kann den Clients in der Cloud 102, wie beispielsweise dem Server 104, als eine einzige Vorrichtung präsentiert werden, die sich am Rande der Cloud 102 befindet. In diesem Beispiel können die Steuerkommunikationen zu bestimmten Ressourcen in der Fog-Vorrichtung 202 erfolgen, ohne eine bestimmte IoT-Vorrichtung innerhalb der Fog-Vorrichtung 202 zu identifizieren. Falls eine IoT-Vorrichtung ausfällt sind daher andere IoT-Vorrichtungen in der Lage, eine Ressource zu erkennen und zu steuern. Beispielsweise können die Verkehrsampeln 204 derart verdrahtet sein, dass jede der Verkehrsampeln 204 die Lampen für die anderen Verkehrsampeln 204 steuern kann.
  • In einigen Beispielen können die IoT-Vorrichtungen mit einem imperativen Programmierstil ausgelegt sein, wobei z.B. jede IoT-Vorrichtung eine bestimmte Funktion und Kommunikationspartner aufweist. Die IoT-Vorrichtungen, die die Fog-Vorrichtung 202 bilden, können jedoch in einem deklarativen Programmierstil ausgelegt sein, der es den IoT-Vorrichtungen ermöglicht, ihre Operationen und Kommunikationen neu zu konfigurieren, um beispielsweise in Reaktion auf Bedingungen, Abfragen und Ausfälle von Vorrichtungen benötigte Ressourcen zu bestimmen. Dies kann durchgeführt werden, wenn vorübergehende IoT-Vorrichtungen, wie etwa der Fußgänger 216, der Fog-Vorrichtung 202 beitreten. Da sich der Fußgänger 216 wahrscheinlich langsamer fortbewegt als die Fahrzeuge 212 und 214, kann sich die Fog-Vorrichtung 202 neu konfigurieren, um sicherzustellen, dass der Fußgänger 216 genügend Zeit hat, um die Kreuzung zu überqueren. Dies kann durch Bilden einer temporären Gruppe der Fahrzeuge 212 und 214 und des Fußgängers 216 zur Steuerung der Verkehrsampel 204 erfolgen. Wenn eines oder beide der Fahrzeuge 212 oder 214 autonom sind, kann die temporäre Gruppe die Fahrzeuge anweisen, die Geschwindigkeit vor den Verkehrsampeln 204 zu verringern.
  • Wenn die vorübergehenden Vorrichtungen 212, 214 und 216 die Nachbarschaft der Kreuzung mit der Fog-Vorrichtung 202 verlassen, kann sie sich selbst neu konfigurieren, um die betreffenden IoT-Vorrichtungen aus dem Netzwerk zu entfernen. Wenn sich andere vorübergehende IoT-Vorrichtungen der Kreuzung nähern, kann sich die Fog-Vorrichtung 202 neu konfigurieren, um diese Vorrichtungen aufzunehmen.
  • Die Fog-Vorrichtung 202 kann die Verkehrsampel 204 für eine Reihe von Kreuzungen, z.B. entlang einer Straße, sowie alle vorübergehenden IoT-Vorrichtungen entlang der Straße aufnehmen. Die Fog-Vorrichtung 202 kann sich dann in Funktionseinheiten, wie die Verkehrsampeln 204 und sonstige IoT-Vorrichtungen aufteilen, die sich in der Nähe einer einzelnen Kreuzung befinden. Diese Art Kombination kann die Bildung größerer IoT-Konstrukte in der Fog-Vorrichtung 202 ermöglichen. Wenn beispielsweise ein Noteinsatzfahrzeug der Fog-Vorrichtung 202 beitritt, kann ein Notfallkonstrukt oder eine virtuelle Vorrichtung erstellt werden, die sämtliche Verkehrsampeln 204 für die Straße einschließt, wodurch eine Steuerung der Verkehrsflussmuster für die gesamte Straße ermöglicht ist. Das Notfallkonstrukt kann die Verkehrsampel 204 entlang der Straße anweisen, für den übrigen Verkehr auf Rot und für das Notfallfahrzeug auf Grün geschaltet zu bleiben, um die Durchfahrt des Noteinsatzfahrzeugs zu beschleunigen. Schlussendlich sind auch viele andere ähnliche und unterschiedliche Konfigurationen und Anwendungen, die nichts mit Fahrzeugverkehr zu tun haben, relevant und anwendbar.
  • 3 stellt eine Ontologie eines GW- und Sensorsystems dar, das drahtlose Sensornetzwerke beinhaltet. Die GW- und Sensornetzwerk kann ein leistungsarmes Netzwerk mit niedriger Bandbreite und hoher Latenz sein. Für Beispiele mit einem Intra-GW-Protokoll kann das Protokoll anwendereigen oder einem veröffentlichten Standard, wie dem OCF-Standard, folgen. In anderen Beispielen sind die GWs möglicherweise nicht miteinander verbunden.
  • Mehrere GWs können in einem GW/Sensornetzwerk in einem IoT-System in einem öffentlichen, kommerziellen, staatlichen oder industriellen Umfeld eingesetzt werden. Daher kann eine Koordination zwischen den GWs nützlich sein. Wie im Folgenden in Bezug auf 4-7 erläutert, können verschiedene Techniken für die GW-Koordination ausgelegt und implementiert sein, um die von einem bestimmten IoT-Einsatz geforderten Leistungskennzahlen zu erfüllen. Jede Technik oder Lösung kann Kompromisse (z.B. Tafel 1 unten) in Bezug auf Skalierbarkeit, Leistung, Speicherbedarf und Zuverlässigkeit aufweisen. Die verschiedenen hierin beschriebenen Koordinationsbeispiele können in verschiedenen Phasen der Einsatz- oder Laufzeitphase basierend auf externen Auslösern und Signalen verwendet werden, um fehlerlose Betriebsvorgänge des Systems zu vereinfachen. Ein Systemintegrator kann basierend auf den Systemanforderungen und anderen Faktoren eine oder mehrere dieser Lösungen/Techniken aussuchen und auswählen.
  • In der Koordination (oder vor der Koordination) zwischen GWs und Sensorvorrichtungen kann das System nach verfügbaren Vorrichtungen suchen. GWs können verschiedene Mechanismen nutzen, um nicht nur Sensorplattformen, sondern auch andere GWs zu entdecken. Entdeckungstechniken für Sensorplattformen können Empfangssignalstärkeindikator (Received Signal Strength Indicator, RSSI), Time of Flight (TOF), Globales Positionsbestimmungssystem (Global Positioning System, GPS) oder andere Ortungsdienste sowie Ultraschall oder Kombinationen von mehreren Techniken beinhalten. Mit jeder der Techniken können Herausforderungen verbunden sein. So kann beispielsweise RSSI aufgrund von Hindernissen und einer lokalen HF-Umgebung abweichen. GPS kann den Standort zwar genau bestimmen, ist allerdings für einige Implementierungen möglicherweise zu kostspielig. Die Koordinierungstechniken können jedoch im Allgemeinen mit einer beliebigen der oben genannten Entdeckungstechniken durchgeführt werden.
  • 3 zeigt speziell ein IoT-System 300 mit einem IoT-Netzwerk 302, das Gateway-Vorrichtungen (GW) 304 und IoT-Sensorvorrichtungen (Sensoren) 306 enthält. Es sollte beachtet werden, dass, während die Anzahl der Sensoren 306 aus Gründen der Übersichtlichkeit willkürlich als neun dargestellt ist, die Anzahl der Sensoren 306 als X verallgemeinert ist, und wobei jedes Gatewaygerät 304 Yi Anzahlen von Sensoren betreut, so dass die Summe von Yi über die N Anzahlen von Gateway-Vorrichtungen 304 insgesamt gleich X Anzahlen von Sensoren 306 ist.
  • Sowohl die Gateway-Vorrichtungen 304 als auch die Sensoren 306 können Computervorrichtungen sein. Das IoT-Netzwerk 302 kann außerdem IoT-Aktoren oder Aktorvorrichtungen beinhalten. Die Anzahl der Gateway-Vorrichtungen 304 ist N. Auch hier ist die Anzahl der IoT-Sensoren 306 X und wird zur Vereinfachung willkürlich als neun (S1 bis S9) dargestellt. Im Allgemeinen können die neun oder X Sensoren 306 untereinander und mit jedem Gateway 304 (GW1 bis GWN) kommunizieren. In dem dargestellten Beispiel sind die Sensoren S1-S4 zu dem gegebenen Zeitpunkt dem Gateway GW1 zugeordnet (z.B. zugewiesen oder davon besessen), die Sensoren S5-S7 dem Gateway GW2 zugeordnet und die Sensoren S8 und S9 dem Gateway GWn zugeordnet.
  • Die Sensorvorrichtungen 306 (S1 bis S9 oder Sx) können Blatt-Nodes sein. In einem bestimmten Beispiel verwenden die Sensorvorrichtungen 306 eine leistungsarme Nahbereichsfunkfrequenz(HF)-Technologie, um mit dem Gateway 304 GW zu kommunizieren, das aktuell den jeweiligen Sx-Node besitzt. Die Gateways 304 GW1 bis GWn können eine zweite Ebene der Konnektivität oder ein GW-Netzwerk bilden und die Verbindung von den Sensoren 306 zu einer Infrastruktur einer Cloud 308 und zu Cloud-Diensten überbrücken. Tatsächlich sind die Gateway-Vorrichtungen 304 mit der Cloud 308 gekoppelt. Die Cloud 308 kann vor Ort oder extern sein. Die Infrastruktur der Cloud 308 kann zahlreiche Dienste für das Netzwerk 302 und für externe Clients 310 vorsehen. Die Anzahl der Clients 308 ist 1 bis M. Die Clients 308 können Bezieher der Daten sein, die über die IoT-Sensoren, Gateway-Vorrichtungen 304 und jede Cloud-Infrastruktur gesammelt werden. Die Clients 308 können Computervorrichtungen von Kunden, Administratoren, Endbenutzern und dergleichen sein. In bestimmten Ausführungsformen verbinden sich die Gateways 306 und die Clients 310 über eine Anwendungsprogrammierschnittstelle (Application Programming Interface, API) mit der Infrastruktur der Cloud 308. Die API kann eine Representational State Transfer(REST oder RESTful)-API wie Hypertext Transfer Protocol (HTTP), HTTP Secured (HTTPS) oder dergleichen sein.
  • 3 stellt dar, wie die verfügbaren Sensor-Nodes zu einem bestimmten Zeitpunkt einem vorgegebenen GW zugeordnet sind oder davon besessen sind. 4-7 zeigen die drei Koordinierungsfunktionen, die obenstehend hinsichtlich der Möglichkeit einer Übertragung eines Sensorbesitzes von einem GW auf ein anderes und der Kompromisse in Zusammenhang mit jedem Beispielmechanismus näher beschrieben wurden. Es gibt zahlreiche Gründe dafür, warum eine Koordinationsfunktion zum Verfolgen von Sensorvorrichtungen wertvoll ist. Ein Gesamtziel dieser Koordinationsfunktionen kann sein, Anforderungen der Systemebene in Bezug auf Zuverlässigkeit, Skalierung (Sensor/GW-Dichte), Lastausgleich, Mobilitäts/Handoff- und Defekt/Fehlererkennung (entweder von GWs oder Sensorvorrichtungen) und dergleichen zu erfüllen.
  • Umgekehrt fällt bei einem Fehlen einer Koordinationsfunktion unter den GWs die Last der Zuweisung von Besitz eines GW an Sensoren an die Cloud, die im Allgemeinen eine Kommunikation zusätzlicher Zustandsinformationen (von GW und Sensoren) erfordert, was somit zu einem gesteigerten Kommunikationsaufwand und zu Systemlatenz führt. Dies kann insbesondere dann der Fall sein, wenn das Melden verbindungslos ist, z.B. weil mehrere GW einen vorgegebenen Node verfolgen, was zu Unvereinbarkeiten, redundanten und erhöhten Verkehrslasten und dergleichen führen kann. Alternativ kann das Vorhaben von Besitz an Sensoren fallengelassen werden, was zu redundanten Daten in der Cloud führt, da mehrere GWs die gleichen Informationen über Sensoren senden. Diese Probleme werden bei dichten Sensoreinsätzen oder einem Einsatz, bei dem die GWs und/oder der Sensor mobil sind (z.B. Logistik, Drohnen) schwerwiegend, was zu Instabilität, Ineffizienz oder Unterauslastung des Gesamtsystems führt.
  • 4 zeigt ein IoT-Netzwerk 400, das eine zentralisierte Koordination für den Gateway-Besitz an Sensoren verwendet. Das Netzwerk 400 verfügt über ein Koordinationsprotokoll 402 zwischen den Gateways 404. Die Gateways 404 bestimmen einen Gateway-Besitz an den Sensoren 406. Somit stellt 4 die zentralisierte Koordinationsfunktion dar. In diesem Szenario bilden die GWs 404, beispielsweise über das Internetprotokoll oder IP, ihren eigenen Intra-GW-Kommunikationskanal. Ein GW 404, das ein spezifisches Sensorgerät 406 verwaltet, wird als diese Sensorvorrichtung 406 „besitzend“ bezeichnet. In der veranschaulichten Ausführungsform besitzt jedes GW 404 einen Satz von Sensorvorrichtungen 406 und sucht zusätzlich nach weiteren geeigneten Sensorvorrichtungen 406 in der Nähe.
  • Tatsächlich kann ein GW 404 Sensoren 406, die er nicht besitzt, suchen, indem es das leistungsarme drahtlose Nahbereichsprotokoll, das zwischen Sensorvorrichtungen und Gateways verwendet wird, abtastet. Das Protokoll kann ein Bluetooth® Low Energy oder Institute of Electrical and Electronics Engineers (IEEE) 802.15.4 Stack sein, beispielsweise mit ZigBee-, WirelessHART-, MiWi- und Thread-Spezifikationen. Der IEEE-Standard 802.15.4 beabsichtigt im Allgemeinen, die unteren Netzwerkebenen vom Typ eines Wireless Personal Area Network (WPAN) anzubieten, das sich auf eine kostengünstige, langsame und allgegenwärtige Kommunikation zwischen Vorrichtungen konzentriert. Es kann mit anderen Ansätzen, wie beispielsweise Wi-Fi, kontrastiert werden, die mehr Bandbreite bieten und mehr Leistung erfordern. Der Schwerpunkt liegt auf einer sehr kostengünstigen Kommunikation von nahegelegenen Vorrichtungen mit wenig bis gar keiner zugrunde liegenden Infrastruktur. Der Standard 802.15.4 ist zum Beispiel für den Betrieb auf einer Hardware mit sehr niedriger Spannung ausgelegt, wie sie möglicherweise in einer eingebetteten Vorrichtung zu finden ist, die monatelang oder sogar jahrelang mit einer Batterie betrieben wird. Dies kann auch für LE zutreffen. Die Skalierung des Standards 802.15.4 kann jedoch aufgrund von 6TiSCH und den Vermaschungsfähigkeiten und Planungsfähigkeiten für einen Datenverkehr, die eine bessere Spektraleffizienz bieten könnten, besser sein.
  • Ein besonderes Beispiel für ein WPAN ist für den Betrieb mit einer Antennenreichweite von etwa 10 Metern und verschiedenen Übertragungsgeschwindigkeiten von 20 kbit/s bis zu 250 kbit/s ausgelegt. Neben der Arbeit mit leistungsarmer Hardware ist der Standard so geschrieben, dass er einfach herzustellende und kostengünstige Vorrichtungen unterstützt.
  • Darüber hinaus können mindestens zwei Klassen von Nodes definiert werden: Vollfunktionscomputervorrichtungen und Vorrichtungen reduzierter Funktion (Reduced-Function Devices, RFDs), wie beispielsweise eingebettete Sensorvorrichtungen. RFDs können im Allgemeinen direkt mit Vollfunktionsvorrichtungen kommunizieren, so dass die leistungsfähigere Hardware der Vollfunktionsvorrichtungen (Server, PCs, einige Gateway-Vorrichtungen und dergleichen) die Last der Verwaltung des Netzwerks, des Verzweigen von Nachrichten und anderer Overheads tragen kann. Ein solcher Netzwerk-Node kann auch einen Synchronisationsplan definieren, der hilft, die RFDs vor Kollisionen zu bewahren, indem er feste, vorhersehbare Zeitfenster für die Übertragung von Datenpaketen definiert. Dieser Netzwerk-Node kann regelmäßige Beacon-Meldungen aussenden, um den RFDs zu helfen, den Takt zu halten, indem sie einfach auf das Beacon-Signal warten, wann immer die RFDs übertragen müssen.
  • Auf jeden Fall erlaubt das in Bezug auf 4 diskutierte Koordinationsprotokoll jedem GW 404 im Allgemeinen einen ganzheitlichen Überblick aller Sensorvorrichtungen 406, einschließlich dahingehend, welches GW derzeit eine spezielle Sensorvorrichtung besitzt, sowie einer Qualitätsmetrik, die verwendet werden kann, um eine Entscheidung über die Übertragung („Handoff“) von Besitz von einem GW an einen anderen zu treffen. Beispiele für eine Qualitätsmetrik sind die Empfangssignalstärke, die Bitrate, die Paketidentifikation, ein gewünschter Lastausgleich zwischen den Sensoren und andere Parameter.
  • Das Koordinationsprotokoll kann es einem GW 404 ermöglichen, Besitz an einer bestimmten Sensorvorrichtung 406 anzufordern, wenn dieses GW 404 anscheinend effizienter und zuverlässiger in der Lage ist, die Sensorvorrichtung 406 zu verfolgen. Ein GW 404 kann außerdem anfordern, dass ein anderes GW 404 in dem GW-Netzwerk den Besitz eines spezifischen oder eines Satzes von Sensorvorrichtungen 406 übernimmt, wenn das GW feststellt, dass sich die Qualitäts- oder Spektraleffizienz, mit der diese Sensorvorrichtung 406 verfolgt wird, verschlechtert. Die Spektraleffizienz kann darauf bezogen sein, wie ein Sendezeit für die drahtlose Kommunikation genutzt wird.
  • GWs 406 können auch einen Lastausgleich von Sensorvorrichtungen 406 anfordern, um die Ressourcen, die zum Verwalten sämtlicher Sensoren in dem WSN erforderlich sind, gleichmäßiger zu verteilen. Die GWs verfügen im Allgemeinen über einen Prozessor und einen Speicher, der Code (z.B. Anweisungen, Logik) speichert, der durch Prozessor ausgeführt werden kann, um die oben genannten Schritte durchzuführen.
  • 5 zeigt ein IoT-Netzwerk 500, das dafür ausgelegt ist, eine kooperative Koordination für den Gateway-Besitz an Sensoren einzusetzen. Das Netzwerk 500 nutzt ein Koordinationsprotokoll 502 zwischen den Gateway-Vorrichtungen 506, wie vorstehend mit Bezug auf 4 erläutert, greift jedoch außerdem auf ein Beacon-Signal 504 zurück, das durch die Sensorvorrichtungen 508 ausgesendet wird. In diesem kooperativen Modus helfen verfügbare Bandbreitenbeaconsignalisierungs(Broadcast/Multicast)-Daten von den Sensorvorrichtungen 508 mittels der Koordinationsfunktion für die GWs 506, über einen anfänglichen Besitz und Besitzübergaben zu entscheiden. Andererseits sind die Beacon-Daten von den Sensorvorrichtungen 508 typischerweise begrenzt und dienen dazu, eine Sensormeldung an das GW 506 zu melden. Im Gegensatz dazu ermöglichen die Sensoren 508 bei dieser Koordinationslösung, dass ein kleiner Teil der zugeteilten Nutzdaten in dem Beacon-Signal 504 dem GW 506 für Buchhaltungs- und Verfolgungszwecke zugeordnet wird.
  • Dieses kooperative System hilft, einen Teil des Managementverkehrs zwischen den einzelnen GWs 506 abzuladen. Die kooperative Umsetzung kann auch dazu beitragen, Situationen zu bewältigen, in denen es nicht möglich ist, auf eine dauerhafte Verbindung zwischen allen GWs 506 in dem System zurückzugreifen, entweder aus einer drahtlosen Perspektive oder allein dadurch, dass sich die GWs 506 in isolierten Gebieten befinden und einander nicht erreichen können. Darüber hinaus ist eine Relay-Route über eine Vor-Ort-Cloud oder eine externe Cloud (z.B. das Internet) möglicherweise kostspielig.
  • In jedem Fall ermöglicht es der Verwaltungsanteil der Beacon-Nutzdaten GWs 506 im Allgemeinen, Besitz an einem „Tag“ (Kennzeichen) eines Sensors 508 zum Verbinden und Anfordern von Besitz zu beanspruchen. Während dieses Schritts können die Sensorvorrichtungen 508 optionale Authentifizierungs- und Autorisierungsschritte des anfordernden GW 506 einsetzen.
  • Typischerweise beinhaltet das GW 506 seinen GW-Identifikator zusammen mit einer aktuell wahrgenommenen Qualitätsmetrik dieses Nodes. Darüber hinaus kann ein erstes GW 506 auch andere Parameter beinhalten, die bei einer Besitzübergabe an ein anderes GW 506 helfen, indem sie Daten über die erste GW 506 Last (Anzahl der Sensor-Tags), einen aktuellen Stand der Ressourcenverfügbarkeit und dergleichen angeben. Darüber hinaus können neue Kandidaten-GWs 506 Anspruch auf Besitz durch eine Inspektion der Daten des Beacon-Signals 504 anfordern, um zu beurteilen, ob das neue Kandidaten-GW 506 ein besserer Kandidat zum Verwalten und Verfolgen der speziellen Sensorvorrichtung als das GW 506 ist, das der aktuelle Besitzer ist.
  • In bestimmten Ausführungsformen kann ein Besitzsanspruchsprozess beinhalten, dass ein GW 506 Folgendes ausführt: (1) die Sensorvorrichtung 508 verbindungslos (über ein Beacon-Signal/Werbungsrahmen) entdecken; (2) die Beacon-Daten 504 analysieren und Details des aktuellen GW 506-Besitzers für diese Sensorvorrichtung extrahieren; (3) sich mit dem Sensor-Tag verbinden, was eine optionale Authentifizierungs- und Autorisierungsaktion (GW zu dem Sensor und umgekehrt - d.h. eine gegenseitige Authentifizierung) beinhalten kann; und (4) Besitzübernahme der Sensorvorrichtung 508 anfordern, durch Senden eines Befehls, der die eigene GW-ID und andere Hilfsdaten enthält (beispielsweise Qualitätsmetrik, Last, Besitzübergabekriterien und dergleichen.
  • Jedes GW 506 kann sich periodisch wieder mit seinen eigenen Tags oder Nodes (z.B. Sensoren oder Aktoren) verbinden, um die Hilfsdaten zu aktualisieren, die anderen GWs 506 helfen, eine Entscheidung dahingehend zu treffen, ob sie ein besserer Kandidat für den Besitzer der spezifischen Sensorvorrichtung 508 sind. In einigen Beispielen kann sich ein GW 506 periodisch mit dem Node (z.B. Sensor) verbinden, um einen „Herzschlag“ oder eine „Lebenserhaltung“ zu ermitteln. Wenn sich das GW in einem bestimmten Zeitraum nicht wieder mit dem Node verbindet, kann der Node davon ausgehen, dass das GW außerhalb des Bereichs liegt oder offline gegangen ist. Wenn dies geschieht, kann der Node sein Beacon-Signal so ändern, dass es „nicht besessen“ ist, so dass es von einem anderen GW übernommen werden kann. Dies sollte ein robusteres Netzwerk ermöglichen.
  • Darüber hinaus verfügen die GWs und Sensoren im Allgemeinen über einen Prozessor und Speicher, der Code speichert, der von dem Prozessor ausgeführt werden kann, um die oben genannten Schritte in Bezug auf die Koordination des GW-Besitzes der Sensoren durchzuführen. Schlussendlich kann der Beacon-Modus ein nicht verbundener Zustand sein. Die Sensorvorrichtungen 508 können die vorgenannten Koordinationsdaten jedoch über eine direkte Verbindung (oder einen verbundenen Zustand) mit dem GW 506 anstelle oder zusätzlich zu dem Beacon-Signal 504 für das GW 506 vorsehen.
  • 6 zeigt ein IoT-Netzwerk 600, das dafür ausgelegt ist, eine dezentralisierte Koordination für den Gateway-Besitz an Sensoren zu nutzen. In dem dezentralisierten Koordinationsmodus wird ein neues Beacon-Signal 604 anhand der GWs 606 selbst eingeführt. Dieses Beacon-Signal 604 hilft den Sensorvorrichtungen 608, unabhängig von der Infrastruktur zu entscheiden, welcher Node oder welches GW 606 sie besitzen soll. Die Beacon-Signale 604 eines GW 606 können die Informationen enthalten, die von den Sensorvorrichtungen benötigt werden, um eine fundierte Entscheidung darüber zu treffen, ob eine Besitzübertragung an ein anderes, geeigneteres GW 606 erfolgen sollte. Jede Sensorvorrichtung 608 kann die Nähe zu dem nächstgelegenen GW 606 durch einen Pfadverlust (z.B. RSSI) messen, benötigt aber möglicherweise zusätzliche Last-/Hilfsinformationen von den Beacon-Signalen, um eine bessere oder fundierte Entscheidung über den Besitzübergang zu treffen. Während zwischen den GWs 606 Linien 610 dargestellt sind, müssen die GWs 606 in bestimmten Ausführungsformen nicht dafür angeschlossen werden, damit das Netzwerk 600 die dezentralisierten Koordination des GW-Besitzes der Sensoren 608 implementieren kann.
  • Die Schritte, die bei diesem dezentralisierten Modell mit dem Übergang von Besitz verbunden sind, können sein: (1) ein GW 606 meldet periodische Informationen über das Beacon-Signal 604, die seine GW-ID und anderer Daten enthalten, die zu einer Entscheidung über seine GW-Last, verfügbare Ressourcen, Gesundheitszustand und dergleichen beitragen; (2) Sensorvorrichtungen 608 senden ihre eigenen Informationen über das Beacon-Signal 602, die Informationen über ihren derzeitigen Besitzer GW 606 beinhalten; und (3) Sensorvorrichtungen 608 lauscht regelmäßig und zu gegebener Zeit auf Beacon-Signale 604 von GWs 606, um ein besser geeignetes GW 606 für den Besitz zu finden. Daten von dem Frame des Beacon-Signals 604 selbst sowie Daten, die in dem Beacon-Signal 604 eingeschlossen sind, können von dem Sensor 608 genutzt werden. Zu den Schritten können ferner gehören: (4) eine Sensorvorrichtung 608 führt den Übergang zu einem GW 606 als Besitzer durch, indem sie die Informationen über ihr eigenes Beacon-Signal 602, die den neuen Besitzer anzeigen, aktualisiert. Zusätzlich oder optional kann sich die Sensorvorrichtung 608 wieder mit den GWs verbinden, falls ein höherer Grad an Servicequalität (QoS) erforderlich ist und eine Bestätigung über die Besitzübertragung von der Infrastruktur her erforderlich ist.
  • Weiter verfügen die Sensoren 608 im Allgemeinen über einen Prozessor und einen Speicher, der Code speichert, der von dem Prozessor ausführbar ist, um die oben genannten Schritte in Bezug auf die Koordination des GW-Besitzes der Sensoren durchzuführen. Letzendlich können anstelle oder zusätzlich zu den Beacon-Signalen 602 und 604 unmittelbare Verbindungen eingesetzt werden, um die oben genannten Informationen zur Durchführung der dezentralisierten Koordination vorzusehen und auszutauschen.
  • Untenstehende Tafel 1 zeigt zusammenfassend eine Momentaufnahme einiger der Kompromisse zwischen den einzelnen Ansätzen, die vor einer Entscheidung über das Koordinationsmodell berücksichtigt werden können. Die Kommentare in der Tafel sind Verallgemeinerungen. Tafel 1. Vergleich von Koordinierungstechniken
    Zentralisiert Kooperativ Dezentralisiert
    Leistungsverbrauch* Niedriger, da in der Regel keine zusätzliche Logik für Sensoren erforderlich ist Mittel. Zusätzliche Verarbeitung an Sensorvorrichtung implementiert Höher. Sensorvorrichtungen führen ein Abtasten und Verarbeiten von Beacon-Signalen durch.
    Spektraleffizienz Höher, da geringer OTA-Overhead. Beacon-Signal kann am besten für die Sensormeldung genutzt werden. Mittel. Etwas Overhead mit Beacon-Signalen, aber ansonsten Nutzung eines Intra-GW-Kanals Niedriger. Zusätzliche Beacon-Signale auf dem GW, die Sendezeit verbrauchen.
    Skalierung Gut, verwendet aber einen intakten Intra-GW-Kanal, der eine höhere Ressource ist, die auf dem GW in hochdichten Einsätzen mit einer großen Anzahl von Sensoren implementiert wird. Gut, geringere Abhängigkeit von intaktem Intra-GW-Kanal für Mobilität, Lastausgleichsströme. Besser hinsichtlich der Auslagerung benötigter Ressourcen und Berechnung von GWzu-Sensor-Vorrichtungen, aber im Allgemeinen nachteilig im Stromverbrauch.
    Verbundene Infrastruktur Ja Ja Nicht erforderlich zwischen GWs
    Sensor Ja Nein Nein
    Agnostik
    Infrastruktur-Agnostik Nein Nein Möglich
    *In bestimmten Beispielen kann die Leistungsaufnahme aus der Sensor-/Knotenperspektive erfolgen. Der Stromverbrauch an dem GW ist möglicher höher.
  • Im Hinblick auf zusätzliche Vorteile kann die GW-Koordination, wie angezeigt, die Abhängigkeit von der Cloud verringern und den gesamten Kommunikationsaufwand in dem System verringern. Zusätzlich zu einem monetären Kostenvorteil kann die GW-Koordination die Akkulebenszeit in beschränkten Vorrichtungen verbessern. Außerdem können GW-Koordinationsmechanismen, wie zentralisierte und kooperative Modi, genutzt werden, um einen Teil der wiederholten Signalisierung zwischen Sensor und GW zu entlasten. Wenn beispielsweise ein Sensor von einem GW authentifiziert und als gültig verifiziert ist (in Abhängigkeit dem verwendeten Mechanismus kann diese Operation rechenintensiv sein), muss der Sensor den Prozess nicht mit nachfolgenden GWs wiederholen. Als Teil der Koordinationsfunktion kann das GW, dem der Sensor gehört, dem nächsten GW signalisieren, dass das GW den Besitz übernimmt, dass der Sensor authentifiziert und verifiziert wurde, wodurch die Notwendigkeit einer Wiederholung des Verfahrens vermieden oder reduziert wird. Darüber hinaus können einige Ausführungsformen der Techniken gut positioniert sein, um in die industrielle Arbeitsgruppe der Open Connectivity Foundation (OCF) aufgenommen zu werden. Weitere relevante Organisationen sind OpenFog und das Industrial Internet Consortium (IIC).
  • Letzendlich kann das IoT-System, z.B. bei der Konstruktion oder bei dem Einsatz des IoT-Systems, für ein bestimmtes Koordinationsmodell konfiguriert werden. Andererseits kann das IoT-System konfiguriert werden, um verschiedene Koordinationsmodelle zu implementieren, und mit einer Auswahlfunktion konfiguriert werden, um dem System oder einem Administrator eine Auswahl des jeweiligen Koordinationsmodells zu ermöglichen, das zu einem vorgegebenen Zeitpunkt verwendet werden soll.
  • 7 zeigt ein Verfahren 700 zum Betreiben eines IoT-Systems, das ein Netzwerk von Gateway-Vorrichtungen und IoT-Sensorvorrichtungen aufweist. In Block 702 umfasst das Verfahren ein Erfassen oder Messen von Daten mittels der IoT-Sensoren. In Block 704 umfasst das Verfahren ein Empfangen der Daten von den IoT-Sensoren an den Gateway-Vorrichtungen. Das Verfahren kann auch ein Liefern der Daten durch die Gateway-Vorrichtungen an eine Cloud umfassen, wie beispielsweise an einen Server in einer Cloud. Die Cloud kann mit dem IoT-System vor Ort sein. Alternativ kann die Cloud gegenüber dem IoT-System auch extern oder entfernt sein, wie z.B. das Internet oder ein Remote-Intranet, und dergleichen. In Block 706 beinhaltet das Verfahren die Koordination von Besitz der Gateway-Vorrichtung an den IoT-Sensoren. Das Koordinieren von Besitz der Gateway-Vorrichtungen an den IoT-Sensoren kann ein Implementieren einer zentralisierten Koordination durch die Gateway-Vorrichtungen zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen beinhalten, wobei die zentralisierte Koordination auf ein Koordinationsprotokoll zwischen den Gateway-Vorrichtungen zurückgreift. Alternativ kann die Koordination von Besitz der Gateway-Vorrichtung an den IoT-Sensoren, wie in Block 706 erwähnt, ein Implementieren einer kooperativen Koordination durch die Gateway-Vorrichtungen und durch die IoT-Sensoren zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen beinhalten, wobei die kooperative Koordination auf ein Koordinationsprotokoll zwischen den Gateway-Vorrichtungen und auf ein Beacon-Signal von den IoT-Sensoren zurückgreift. Eine weitere Option zur Koordination von Besitz der Gateway-Vorrichtungen an den IoT-Sensoren, wie in Block 706 erwähnt, besteht darin, dass die IoT-Sensoren eine dezentralisierte Koordination zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen implementieren. In Beispielen entscheiden die Gateway-Vorrichtungen nicht über den Besitz. Das Implementieren der dezentralisierten Koordination durch die IoT-Sensoren kann ein Zurückgreifen auf ein Beacon-Signal von den Gateway-Vorrichtungen durch die IoT-Sensoren umfassen, um über den Besitz zu entscheiden.
  • Zusammenfassend lässt sich sagen, dass ein Verfahren zum Betreiben eines IoT-Systems ein Erfassen von Daten mittels IoT-Sensoren, ein Empfangen der Daten von den IoT-Sensoren an Gateway-Vorrichtungen und ein Koordinieren von Besitz von Gateway-Vorrichtungen an den IoT-Sensoren umfassen kann. Das Koordinieren von Besitz der Gateway-Vorrichtungen an den IoT-Sensoren kann ein Implementieren einer zentralisierten Koordination durch die Gateway-Vorrichtungen zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen umfassen, wobei die zentralisierte Koordination auf ein Koordinationsprotokoll zwischen den Gateway-Vorrichtungen zurückgreift. Das Koordinieren von Besitz der Gateway-Vorrichtungen an den IoT-Sensoren kann ein Implementieren einer kooperativen Koordination durch die Gateway-Vorrichtungen und durch die IoT-Sensoren zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen umfassen, wobei die kooperative Koordination auf ein Koordinationsprotokoll zwischen den Gateway-Vorrichtungen und auf ein Beacon-Signal von den IoT-Sensoren zurückgreift. Das Koordinieren von Besitz der Gateway-Vorrichtung an den IoT-Sensoren kann ein Implementieren einer dezentralisierten Koordination durch die IoT-Sensoren zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen umfassen, und wobei die Gateway-Vorrichtungen in bestimmten Beispielen nicht über den Besitz entscheiden. Das Implementieren der dezentralisierten Koordination durch die IoT-Sensoren kann ein Zurückgreifen auf ein Beacon-Signal von den Gateway-Vorrichtungen durch die IoT-Sensoren umfassen, um über den Besitz zu entscheiden. Letzendlich kann das Verfahren auch die Auswahl eines Koordinationsmodus zum Koordinieren von Besitz der Gateway-Vorrichtung an den IoT-Sensoren umfassen.
  • 7A zeigt ein Verfahren 710 zum Betreiben eines IoT-Systems, das ein Netzwerk von Gateway-Vorrichtungen und IoT-Sensorvorrichtungen aufweist. In Block 712 umfasst das Verfahren ein Auswählen einer Koordinationsoption zum Koordinieren von Besitz der Gateway-Vorrichtung an den IoT-Sensoren. Die restlichen dargestellten Schritte des Verfahrens 710 ähneln den Schritten, die in Bezug auf das Verfahren 700 von 7 diskutiert wurden. In Block 714 erfassen oder messen die IoT-Sensoren Daten. In Block 716 empfangen die Gateway-Vorrichtungen die Daten von den IoT-Sensoren. Das Verfahren kann auch ein Liefern der Daten durch die Gateway-Vorrichtungen an eine Cloud umfassen. In Block 718 umfasst das Verfahren ein Koordinieren von Besitz der Gateway-Vorrichtung an den IoT-Sensoren gemäß der in Block 712 ausgewählten Koordinationsoption.
  • 8 zeigt eine Computervorrichtung 800, wie beispielsweise ein Computersystem, eine Gateway-Vorrichtung, eine Sensorvorrichtung, ein Server, eine Aggregationsvorrichtung, ein entfernter Computer und dergleichen. Während 8 eine einzelne Computervorrichtung 800 darstellt, können Ausführungsformen mehrere Computervorrichtungen 800 einsetzen. Die Datenverarbeitung 800 beinhaltet einen Prozessor oder Hardware-Prozessor 802, wie beispielsweise einen Mikroprozessor, eine zentrale Verarbeitungseinheit oder CPU, und dergleichen. Der Prozessor 802 kann auf mehreren Prozessoren basieren oder jeder Prozessor 202 kann mehrere Kerne aufweisen. Die Computervorrichtung 800 verfügt über einen Speicher 804, wie beispielsweise einen nichtflüchtigen Speicher, einen flüchtigen Speicher und andere Arten eines Speichers. Der nichtflüchtige Speicher kann eine Festplatte, ein Nur-Lese-Speicher, ein ROM oder dergleichen sein. Der flüchtige Speicher kann ein Direktzugriffsspeicher oder RAM, ein Cache oder dergleichen sein.
  • In dem veranschaulichten Beispiel speichert der Speicher 804 den Code 806, z.B. Anweisungen, Logik und dergleichen, der von einem oder mehreren Prozessoren 802 ausführbar ist. Der Code 804 kann von dem Prozessor 804 ausgeführt werden, um die hierin beschriebenen Gateway-Koordinierungstechniken zu implementieren. Darüber hinaus können entsprechende Schritte von verschiedenen Computervorrichtungen 800 durchgeführt werden. Außerdem kann die Computervorrichtung eine anwendungsspezifische integrierte Schaltung (ASIC) enthalten, die für die beschriebenen Techniken angepasst ist.
  • 9 zeigt ein Blockdiagramm eines Beispiels von Komponenten, die in einer IoT-Vorrichtung 900 zur Profilerstellung oder Diagnose eines IoT-Systems vorhanden sein können. Die IoT-Vorrichtung 900 kann beliebige Kombinationen der in dem Beispiel gezeigten Komponenten enthalten. Die Komponenten können als ICs, Teile davon, diskrete elektronische Vorrichtungen oder sonstige Module, eine Logik, Hardware, Software, Firmware oder eine Kombination davon, die in der IoT-Vorrichtung 900 angepasst sind, oder als Komponenten implementiert werden, die anderweitig in ein Gehäuse eines größeren Systems integriert sind. Das Blockdiagramm von 9 soll eine Übersichtsansicht der Komponenten der IoT-Vorrichtung 900 darstellen. Einige der dargestellten Komponenten können jedoch weggelassen werden, es können zusätzliche Komponenten vorhanden sein, und in anderen Implementierungen können unterschiedliche Anordnungen der dargestellten Komponenten auftreten.
  • Die IoT-Vorrichtung 900 kann einen Prozessor 902 beinhalten, der ein Mikroprozessor, ein Multicore-Prozessor, ein Multithread-Prozessor, ein Ultra-Niederspannungs-Prozessor, ein Embedded-Prozessor oder ein anderes bekanntes Verarbeitungselement sein kann. Der Prozessor 902 kann Teil eines Systems auf einem Chip (SoC) sein, bei dem der Prozessor 902 und andere Komponenten zu einer einzigen integrierten Schaltung oder einer einzigen Packung, wie beispielsweise den SoC-Karten Edison™ oder Galileo™ von Intel, geformt sind. Als Beispiel kann der Prozessor 902 einen Intel® Architecture Core™-basierten Prozessor beinhalten, wie beispielsweise einen Quark™, einen Atom™, einen Prozessor der Klasse i3, i5, i7 oder MCU, oder einen anderen Prozessor, der von Intel® Corporation, Santa Clara, CA, erhältlich ist. Es kann jedoch auch eine beliebige Anzahl anderer Prozessoren verwendet werden, wie beispielsweise die von Advanced Micro Devices, Inc. (AMD) von Sunnyvale, CA, erhältlichen, ein MIPS-basiertes Design von MIPS Technologies, Inc. von Sunnyvale, CA, ein ARM-basiertes Design, das von ARM Holdings, Ltd. oder einem Clientn davon, oder deren Lizenznehmern oder Anwendern lizenziert wurde. Die Prozessoren können Einheiten wie einen A5-A9-Prozessor von Apple® Inc., einen Snapdragon™- Prozessor von Qualcomm® Technologies, Inc. oder einen OMAP™- Prozessor von Texas Instruments, Inc. beinhalten.
  • Der Prozessor 902 kann über einen Bus 906 mit einem Systemspeicher 904 kommunizieren. Eine beliebige Anzahl von Speichervorrichtungen kann verwendet werden, um eine vorgegebene Menge an Systemspeicher bereitzustellen. Als Beispiele kann der Speicher ein Direktzugriffsspeicher (RAM) gemäß einem Joint Electron Devices Engineering Council (JEDEC) Low-Power Double Data Rate (LPDDR)-basierten Design wie dem aktuellen LPDDR2-Standard gemäß JEDEC JESD 209-2E (veröffentlicht im April 2009) oder einem LPDDR-Standard der nächsten Generation, wie LPDDR3 oder LPDDR4, sein, der Erweiterungen für LPDDR2 zur Erhöhung der Bandbreite bietet. In verschiedenen Implementierungen können die einzelnen Speichervorrichtungen von beliebig vielen verschiedenen Packungstypen sein, wie z.B. Single Die Package (SDP), Dual Die Package (DDP) oder Quad Die Package (Q17P). Diese Vorrichtungen können in einigen Ausführungsformen direkt auf eine Hauptplatine gelötet werden, um eine Lösung mit niedrigerem Profil zu bieten, während in anderen Ausführungsformen die Vorrichtungen als ein oder mehrere Speichermodule ausgelegt sind, die wiederum über einen vorgegebenen Verbinder mit der Hauptplatine gekoppelt sind. Es kann eine beliebige Anzahl anderer Speicherimplementierungen verwendet werden, wie beispielsweise andere Arten von Speichermodulen, z.B. Dual-Inline-Speichermodule (DIMMs) verschiedener Varianten, einschließlich, aber nicht beschränkt auf microDIMMs oder MiniDIMMs. So kann beispielsweise ein Speicher zwischen 2 GB und 16 GB groß sein und als DDR3LM-Gehäuse oder als LPDDR2- oder LPDDR3-Speicher ausgelegt sein, der über ein Ball Grid Array (BGA) auf ein Motherboard gelötet wird.
  • Um eine dauerhafte Speicherung von Informationen wie Daten, Anwendungen, Betriebssystemen und dergleichen sicherzustellen, kann auch ein Massenspeicher 908 über den Bus 906 mit dem Prozessor 902 verbunden werden. Um ein schlankeres und leichteres Systemdesign zu ermöglichen, kann der Massenspeicher 908 über ein Solid State Disk Drive (SSDD) implementiert werden. Andere Vorrichtungen, die für den Massenspeicher 908 verwendet werden können, sind Flash-Speicherkarten, wie SD-Karten, microSD-Karten, xD-Bildkarten und dergleichen, sowie USB-Sticks. Bei Implementierungen mit geringer Leistung kann der Massenspeicher 908 ein Die-Speicher oder Register sein, die dem Prozessor 902 zugeordnet sind. In einigen Beispielen kann der Massenspeicher 908 jedoch mit einer Mikrofestplatte (Hard Disk Drive, HDD) implementiert werden. Darüber hinaus können für den Massenspeicher 908 zusätzlich zu oder anstelle der beschriebenen Technologien beliebig viele neue Technologien eingesetzt werden, wie beispielsweise Widerstandsänderungsspeicher, Phasenänderungsspeicher, holographische Speicher oder chemische Speicher. So kann beispielsweise die IoT-Vorrichtung 900 die 3D-XPOINT-Speicher von Intel® und Micron® integrieren.
  • Die Komponenten können über den Bus 906 kommunizieren. Der Bus 906 kann eine beliebige Anzahl von Technologien beinhalten, einschließlich Industriestandardarchitektur (ISA), erweiterte ISA (EISA), Peripheriekomponentenverbindung (PCI), Peripheriekomponentenverbindung (PCIx), PCI Express (PCIe) oder eine beliebige Anzahl anderer Technologien. Der Bus 906 kann ein anwendereigener Bus sein, der beispielsweise in einem SoC-basierten System verwendet wird. Andere Bussysteme können integriert werden, wie beispielsweise eine 12C-Schnittstelle, eine SPI-Schnittstelle, Punkt-zu-Punkt-Schnittstellen und ein Stromversorgungsbus.
  • Der Bus 906 kann den Prozessor 902 mit einem Mesh-Transceiver 710 koppeln, um mit anderen Mesh-Vorrichtungen 912 zu kommunizieren. Der Mesh-Transceiver 910 kann eine beliebige Anzahl von Frequenzen und Protokollen verwenden, wie z.B. 2,4 Gigahertz (GHz) Übertragungen nach dem IEEE 802.15.4 Standard, wobei unter anderem der Bluetooth® Low Energy (BLE) Standard, wie von der Bluetooth® Special Interest Group definiert, oder der ZigBee® Standard verwendet wird. Eine beliebige Anzahl von Funkvorrichtungen, die für ein bestimmtes drahtloses Kommunikationsprotokoll ausgelegt sind, können für die Verbindungen zu den Mesh-Vorrichtungen 912 verwendet werden. So kann beispielsweise eine WLAN-Einheit verwendet werden, die Wi-FiTM-Kommunikationen gemäß dem Standard des Institute of Electrical and Electronics Engineers (IEEE) 802.11 implementiert. Zusätzlich kann die drahtlose Weitbereichskommunikation, z.B. nach einem zellularen oder einem anderen drahtlosen Weitbereichsprotokoll, über eine WWAN-Einheit erfolgen.
  • Der Mesh-Transceiver 910 kann unter Verwendung mehrerer Standards oder Funkvorrichtungen für Kommunikation unterschiedlicher Reichweite kommunizieren. So kann beispielsweise die IoT-Vorrichtung 900 mit nahen Vorrichtungen kommunizieren, z.B. innerhalb von etwa 10 Metern, indem sie einen lokalen Transceiver auf Basis von BLE oder eine andere Funkvorrichtung mit niedriger Leistung verwendet, um Strom zu sparen. Weiter entfernte Mesh-Vorrichtungen 912 können, z.B. innerhalb von ca. 50 Metern, über ZigBee oder andere Funkvorrichtungen mittlerer Leistung erreicht werden. Beide Kommunikationstechniken können über eine einzelne Funkvorrichtung mit unterschiedlichen Leistungsstufen oder über getrennte Transceiver, z.B. einen lokalen Transceiver mittels BLE und einen separaten Mesh-Transceiver mittels ZigBee stattfinden. Der Mesh-Transceiver 910 kann als direkt auf dem Chip zugängliche Adresse in eine MCU integriert werden, wie beispielsweise in die von Intel erhältlichen Curie®-Einheiten.
  • Ein Uplink-Transceiver 914 kann zur Kommunikation mit Vorrichtungen in der Cloud 102 integriert werden. Der Uplink-Transceiver 914 kann ein LPWA-Transceiver sein, der unter anderem den Standards IEEE 802.15.4 oder IEEE 802.15.4g folgt. Die IoT-Vorrichtung 900 kann über ein großes Gebiet kommunizieren, indem sie das von Semtech und der LoRa Alliance entwickelte LoRaWAN™ (Long Range Wide Area Network) verwendet. Die hierin beschriebenen Techniken sind nicht auf diese Technologien beschränkt, sondern können mit einer beliebigen Anzahl anderer Cloud-Transceiver verwendet werden, die Kommunikationen mit großer Reichweite und geringer Bandbreite implementieren, wie beispielsweise Sigfox und andere Technologien. Darüber hinaus können andere Kommunikationstechniken, wie z.B. zeitgesteuertes „Channel Hopping“, wie in IEEE 802.15.4e beschrieben, verwendet werden.
  • Neben den für den Mesh-Transceiver 910 und den Uplink-Transceiver 914 genannten Systemen können, wie hierin beschrieben, beliebig viele andere Funkkommunikationen und Protokolle verwendet werden. So können beispielsweise die Funk-Transceiver 910 und 912 ein LTE oder einen anderen zellularen Transceiver beinhalten, der Spread Spectrum (SPA/SAS)-Kommunikationen zur Implementierung von Hochgeschwindigkeitskommunikationen, wie beispielsweise für Videoübertragungen, verwendet. Darüber hinaus kann eine beliebige Anzahl anderer Protokolle verwendet werden, wie z.B. Wi-Fi-Netzwerke für die Kommunikation mit mittlerer Geschwindigkeit, wie Standbilder, Sensormesswerte und das Vorsehen von Netzwerkkommunikationen.
  • Die Funk-Transceiver 910 und 914 können Funkvorrichtungen beinhalten, die mit einer beliebigen Anzahl von 3GPP (Third Generation Partnership Project) Spezifikationen kompatibel sind, insbesondere Long Term Evolution (LTE), Long Term Evolution-Advanced (LTE-A) und Long Term Evolution-Advanced Pro (LTE-A Pro). Zelluläre Standards wie LTE-Machine-Type-Communication (LTE-M), LTE-Schmalband (LTE-Narrowband, LTE-NB) oder Variationen davon können anwendbar sein. Es sei darauf hingewiesen, dass Funkvorrichtungen ausgewählt werden können, die mit einer beliebigen Anzahl anderer fester, mobiler oder satellitengestützter Kommunikationstechnologien und -standards kompatibel sind. Dazu kann beispielsweise jede zellulare Breitbandfunktechnologie gehören, die z.B. ein Kommunikationssystem der 5. Generation (5G), ein Global System for Mobile Communications (GSM)-Funkkommunikationstechnologie, eine General Packet Radio Service (GPRS)-Funkkommunikationstechnologie oder eine Enhanced Data Rates for GSM Evolution (EDGE)-Funkkommunikationstechnologie beinhalten kann. Weitere Funktechnologien des Third Generation Partnership Project (3GPP), die eingesetzt werden können, beinhalten UMTS (Universal Mobile Telecommunications System), FOMA (Freedom of Multimedia Access), 3GPP LTE (Long Term Evolution), 3GPP LTE Advanced (Long Term Evolution Advanced), 3GPP LTE Advanced Pro (Long Term Evolution Advanced Pro), CDMA2000 (Code Division Multiple Access 2000), CDPD (Cellular Digital Packet Data), Mobitex, 3G (Third Generation), CSD (Circuit Switched Data), HSCSD (High-Speed Circuit-Switched Data), UMTS (3G) (Universal Mobile Telecommunications System (Third Generation)), W-CDMA (UMTS) (Wideband Code Division Multiple Access (Universal Mobile Telecommunications System)), HSPA (High Speed Packet Access), HSDPA (High-Speed Downlink Packet Access), HSUPA (High-Speed Uplink Packet Access), HSPA+ (High Speed Packet Access Plus), UMTS-TDD (Universal Mobile Telecommunications System - Time-Division Duplex), TD-CDMA (Time Division - Code Division Multiple Access), TD-SCDMA (Time Division - Synchronous Code Division Multiple Access), 3GPP Rel. 8 (Pre-4G) (3rd Generation Partnership Project Release 8 (Pre-4th Generation)), 3GPP Rel. 9 (3rd Generation Partnership Project Release 9), 3GPP Rel. 10 (3rd Generation Partnership Project Release 10), 3GPP Rel. 11 (3rd Generation Partnership Project Release 11), 3GPP Rel. 12 (3rd Generation Partnership Project Release 12), 3GPP Rel. 13 (3rd Generation Partnership Project Release 13), 3GPP Rel. 14 (3rd Generation Partnership Project Release 14), 3GPP LTE Extra, LTE Licensed-Assisted Access (LAA), UTRA (UMTS Terrestrial Radio Access), E-UTRA (Evolved UMTS Terrestrial Radio Access), LTE Advanced (4G) (Long Term Evolution Advanced (4th Generation)), cdmaOne (2G), CDMA2000 (3G) (Code Division Multiple Access 2000 (Third Generation)), EV-DO (Evolution-Data Optimized or Evolution-Data Only), AMPS (1 G) (Advanced Mobile Phone System (Ist Generation)), TACS/ETACS (Total Access Communication System/Extended Total Access Communication System), D-AMPS (2G) (Digital AMPS (2nd Generation)), PTT (Push-to-talk), MTS (Mobile Telephone System), IMTS (Improved Mobile Telephone System), AMTS (Advanced Mobile Telephone System), OLT (Norwegian for Offentlig Landmobili, Public Land Mobile Telephony), MTD (Schwedische Abkürzung für „Mobiltelefonisystem D“ oder Mobile Telephony System D), Autotel/PALM (Public Automated Land Mobile), ARP (Finnisch für „Autoradiopuhelin“ Autofunktelefon), NMT (Nordic Mobile Telephony), Hicap (High Capacity Version von NTT (Nippon Telegraph und Telefon)), CDPD (Cellular Digital Packet Data), Mobitex, DataTAC, iDEN (Integrated Digital Enhanced Network), PDC (Personal Digital Cellular), CSD (Circuit Switched Data), PHS (Personal Handy-phone System), WiDEN (Wideband Integrated Digital Enhanced Network), iBurst, Unlicensed Mobile Access (UMA, auch bekannt als 3GPP Generic Access Network oder GAN-Standard), Wireless Gigabit Alliance (WiGig) Standard, mmWave Standards im Allgemeinen (drahtlose Systeme, die mit 10-90 GHz und mehr arbeiten, wie WiGig, IEEE 802.11 ad, IEEE 802.11 ay und dergleichen. Zusätzlich zu den oben aufgeführten Normen können für den Uplink-Transceiver 914 beliebig viele Satelliten-Uplink-Technologien verwendet werden, darunter beispielsweise Funkvorrichtungen, die den Normen der ITU (International Telecommunication Union) oder des ETSI (European Telecommunications Standards Institute) entsprechen. Die hierin enthaltenen Beispiele werden daher als auf verschiedene andere sowohl bestehende als auch noch nicht formulierte Kommunikationstechnologien anwendbar verstanden.
  • Ein Netzwerkschnittstellen-Controller (Network Interface Controller, NIC) 916 kann integriert werden, um eine drahtgebundene Kommunikation mit der Cloud 102 vorzusehen. Die kabelgebundene Kommunikation kann eine Ethernet-Verbindung vorsehen oder auf anderen Arten von Netzwerken basieren, wie z.B. auf Controller Area Network (CAN), Local Interconnect Network (LIN), DeviceNet, ControlNet, Data Highway+, PROFIBUS oder PROFINET, unter vielen anderen. Ein zusätzlicher NIC 916 kann integriert werden, um eine Verbindung zu einem zweiten Netzwerk zu ermöglichen, beispielsweise ein NIC 916, der Kommunikationen zur Cloud über Ethernet vorsieht, und ein zweiter NIC 916, der Kommunikationen zu anderen Vorrichtungen über eine andere Art eines Netzwerks vorsieht.
  • In Bezug auf die Darstellung eines NIC-, Uplink- und Mesh-Transceivers können im allgemeinen Fall für QW-Node mindestens zwei physikalische Schnittstellen vorhanden sein. Eine Schnittstelle für das (leistungsarme) Low-Power-Mesh (z.B. IEEE 802.15.4), die Mesh- und Routingfähigkeiten als Teil des Stacks aufweisen kann. Eine zweite physikalische Schnittstelle kann über eine Internet-Protokoll-(IP)-Konnektivität verfügen, die das „Uplink“-Melden von Daten an eine Cloud-Instanz durchführt.
  • Der Bus 906 kann den Prozessor 902 mit einer Schnittstelle 918 koppeln, die zum Anschluss externer Vorrichtungen verwendet werden kann. Die externen Vorrichtungen können Sensoren 920 beinhalten, wie beispielsweise Beschleunigungssensoren, Niveausensoren, Strömungssensoren, Temperatursensoren, Drucksensoren, barometrische Drucksensoren und dergleichen. Die Schnittstelle 918 kann genutzt werden, um die IoT-Vorrichtung 900 mit Aktoren 922 zu verbinden, wie beispielsweise Netzschaltern, Ventilstellgliedern, einem akustischen Klangerzeuger, einer optischen Warnvorrichtung und dergleichen.
  • Wenn nicht angezeigt, können verschiedene Ein-/Ausgabe(Input/Output, I/O)-Vorrichtungen innerhalb der IoT-Vorrichtung 900 vorhanden oder mit ihr verbunden sein. So kann beispielsweise eine Anzeige integriert werden, um Informationen wie Sensorwerte oder die Position eines Aktors anzuzeigen. Eine Eingabevorrichtung, wie beispielsweise ein Touchscreen oder eine Tastatur, kann zur Aufnahme von Eingaben integriert werden.
  • Eine Batterie 924 kann die IoT-Vorrichtung 900 mit Strom versorgen, obwohl sie in Beispielen, in denen die IoT-Vorrichtung 900 an einem festen Ort montiert ist, eine mit einem Stromnetz gekoppelte Stromversorgung aufweisen kann. Die Batterie 924 kann eine Lithium-Ionen-Batterie, eine Metall-Luft-Batterie, wie eine Zink-Luft-Batterie, eine Aluminium-Luft-Batterie, eine Lithium-Luft-Batterie und dergleichen sein.
  • Eine Batterieüberwachungs-/Ladevorrichtung 926 kann in die IoT-Vorrichtung 900 integriert werden, um den Ladezustand (State of Charge, SoCh) der Batterie 924 zu verfolgen. Die Batterieüberwachungs-/Ladevorrichtung 926 kann verwendet werden, um andere Parameter der Batterie 924 zu überwachen, um Ausfallvorhersagen zu treffen, wie beispielsweise den Gesundheitszustand (State of Health, SoH) und den Funktionszustand (State of Function, SoF) der Batterie 924. Die Batterieüberwachungs-/Ladevorrichtung 926 kann eine integrierte Batterieüberwachungsschaltung beinhalten, wie beispielsweise einen LTC4020 oder einen LTC2990 von Linear Technologies, einen ADT7488A von ON Semiconductor von Phoenix Arizona oder einen IC aus der UCD90xxx-Familie von Texas Instruments aus Dallas, TX. Über den Bus 906 kann die Batterieüberwachungs-/Ladevorrichtung 926 die Informationen über die Batterie 924 an den Prozessor 902 übermitteln. Die Batterieüberwachungs-/Ladevorrichtung 926 kann auch einen Analog/Digital(Analog-to-Digital, ADC)-Wandler beinhalten, der es dem Prozessor 902 ermöglicht, die Spannung der Batterie 924 oder den Stromfluss der Batterie 924 direkt zu überwachen. Die Batterieparameter, wie beispielsweise Übertragungsfrequenz, Netzwerkbetrieb, Abtastfrequenz und dergleichen, können verwendet werden, um Schritte zu bestimmen, die die IoT-Vorrichtung 900 ausführen kann. Dies kann auf den oben beschriebenen Fehleroperationen begründet sein.
  • Ein Leistungsblock 928 oder eine andere an ein Netz angeschlossene Stromversorgung kann mit der Batterieüberwachungs-/Ladevorrichtung 926 gekoppelt werden, um die Batterie 924 aufzuladen. In einigen Beispielen kann der Leistungsblock 928 durch einen drahtlosen Leistungsempfänger ersetzt werden, um die Leistung, z.B. über eine Schleifenantenne in der IoT-Vorrichtung 900, drahtlos zu beziehen. Eine drahtlose Batterieladeschaltung, wie beispielsweise ein LTC4020-Chip von Linear Technologies, Milpitas, CA, kann in die Batterieüberwachungs-/Ladevorrichtung 926 integriert werden. Die Wahl der spezifischen Ladeschaltungen hängt von der Größe der Batterie 924 und damit von dem benötigten Strom ab. Die Aufladung kann unter Verwendung des von der Airfuel Alliance veröffentlichten Airfuel-Standards, des von dem Wireless Power Consortium veröffentlichten Qi-Drahtlosladestandards, des von der Alliance for Wireless Power veröffentlichten Rezence-Ladestandards und anderer durchgeführt werden.
  • Der Massenspeicher 908 kann eine Anzahl von Modulen zur Durchführung der hierin beschriebenen Gateway-Koordination enthalten, wie mit den Bezugszeichen 930 und 932 angegeben. Block 930 kann ausführbarer Code sein, um die Gateway-Koordination, einschließlich verschiedener Modi oder Arten der Gateway-Koordination, zu implementieren. Block 932 kann eine Auswahl eines Modus der Gateway-Konfiguration darstellen, dem das IoT-System folgen soll.
  • Obwohl in dem Massenspeicher 908 als Codeblöcke dargestellt, kann davon ausgegangen werden, dass jedes der Module durch fest verdrahtete Schaltungen ersetzt werden kann, die beispielsweise in eine anwendungsspezifische integrierte Schaltung (ASIC) eingebaut sind. Der Massenspeicher 908 kann ferner andere Funktionsblöcke beinhalten und speichern, wie beispielsweise eine Steueroberfläche für den Zugriff auf Konfigurationsparameter und ein Automatisierungsframework, das Anwendungsprogrammschnittstellen (APIs) für das Zusammenspiel von Canned-Trigger-Skripten vorsehen kann. Weitere möglicherweise vorhandene Funktionsblöcke sind Accelerated Processing Units (APUs) in dem Automatisierungsframework, die einen Standardsatz von Timing-Informationen austauschen, der es Trigger-Skripten ermöglicht, synchrone und versetzte Starts zu identifizieren. Eine IoT-Datenbank kann sein enthält, um Workflow-Konfigurationsinformationen, beobachtete Systemleistung und resultierende Lösungsmerkmale zu speichern. Interaktionen mit der IoT-Datenbank können über die Steueroberfläche erfolgen.
  • 10 zeigt ein Blockdiagramm, das ein materielles, nichtflüchtiges, computerlesbares Medium zur Vereinfachung einer Profilerstellung und Diagnose darstellt. Auf das computerlesbare Medium 1000 kann von einem Prozessor 1002 über eine Computerverbindung 1004 zugegriffen werden. Der Prozessor 1002 kann ein Aggregationsvorrichtungsprozessor, ein Sensorprozessor, ein Serverprozessor, ein Remote-Computervorrichtungsprozessor oder ein sonstiger Prozessor sein. Das materielle, nicht flüchtige, computerlesbare Medium 100 kann ausführbare Anweisungen oder einen Code beinhalten, um den 1002 zu veranlassen, die Vorgänge der hierin beschriebenen Techniken durchzuführen, wie beispielsweise eine Gateway-Koordination.
  • Die verschiedenen hierin behandelten Softwarekomponenten können auf dem materiellen, nicht flüchtigen, computerlesbaren Medium 1000 gespeichert werden, wie in 10 angegeben. So kann beispielsweise ein Gateway-Koordinationsmodul 1006 (ausführbarer Code/Anweisungen) den Prozessor 1002 veranlassen, die Koordination eines Gateway-Besitzes an Sensorvorrichtungen in einem IoT-Netzwerk zu implementieren. Ein Auswahlmodul 1008 kann den Prozessor 1002 veranlassen, einen Modus oder eine Art einer solchen Gateway-Koordination für das zu implementierende IoT-Netzwerk auszuwählen. Es ist zu verstehen, dass je nach Anwendung eine beliebige Anzahl von zusätzlichen Softwarekomponenten, die nicht in 10 dargestellt sind, in das materielle, nicht flüchtige, computerlesbare Medium 1000 aufgenommen werden können.
  • In der Beschreibung und in den Ansprüchen können die Begriffe „gekoppelt“ und „verbunden“ sowie deren Derivate verwendet sein. Es ist zu verstehen, dass diese Begriffe nicht als Synonyme füreinander gedacht sind. Vielmehr kann in speziellen Ausführungsformen der Begriff „verbunden/angeschlossen“ verwendet werden, um anzuzeigen, dass zwei oder mehr Elemente in einem unmittelbaren physischen oder elektrischen Kontakt miteinander stehen. „Gekoppelt“ kann bedeuten, dass zwei oder mehr Elemente in einem unmittelbaren physischen oder elektrischen Kontakt stehen. „Gekoppelt“ kann allerdings auch bedeuten, dass zwei oder mehr Elemente zwar nicht in einem unmittelbaren Kontakt miteinander stehen, aber dennoch zusammenwirken oder miteinander interagieren.
  • Einige Ausführungsformen können in Hardware, Firmware und Software oder in einer Kombination davon implementiert werden. Einige Ausführungsformen können auch als Anweisungen implementiert werden, die auf einem maschinenlesbaren Medium gespeichert sind, das von einer Computerplattform gelesen und ausgeführt werden kann, um die hierin beschriebenen Vorgänge auszuführen. Ein maschinenlesbares Medium kann einen beliebigen Mechanismus zum Speichern oder Übertragen von Informationen in einer von einer Maschine, z.B. einem Computer, lesbaren Form beinhalten. So kann beispielsweise ein maschinenlesbares Medium einen Nur-Lese-Speicher (ROM), einen Direktzugriffsspeicher (RAM), Magnetplattenspeichermedien, optische Speichermedien, Flash-Speicher-Vorrichtungen oder elektrische, optische, akustische oder andere Formen von sich ausbreitenden Signalen, z.B. Trägerwellen, Infrarotsignale, digitale Signale, oder die Schnittstellen, die Signale senden oder empfangen, und dergleichen beinhalten.
  • Eine Ausführungsform bedeutet eine Implementierung oder ein Beispiel. Eine Bezugnahme in der Spezifikation auf „eine Ausführungsform“, „eine (1) Ausführungsform“, „einige Ausführungsformen“, „verschiedene Ausführungsformen“ oder „andere/sonstige Ausführungsformen“ bedeutet, dass ein bestimmtes Merkmal, eine bestimmte Struktur oder eine bestimmte Eigenschaft, das bzw. die im Zusammenhang mit den Ausführungsformen beschrieben wird, in mindestens einigen Ausführungsformen, aber nicht unbedingt in allen Ausführungsformen, der vorliegenden Techniken enthalten ist. Die verschiedenen Erscheinungsformen von „einer Ausführungsform“, „einer (1) Ausführungsform“ oder „einigen Ausführungsformen“ beziehen sich nicht unbedingt alle auf dieselben Ausführungsformen. Elemente oder Aspekte von einer Ausführungsform können mit Elementen oder Aspekten einer anderen Ausführungsform kombiniert werden.
  • In einer oder mehreren speziellen Ausführungsformen müssen nicht unbedingt sämtliche hierin beschriebenen und veranschaulichten Komponenten, Merkmale, Strukturen, Eigenschaften und dergleichen enthalten sein. Wenn die Spezifikation feststellt, dass eine Komponente, ein Merkmal, eine Struktur oder eine Eigenschaft beispielsweise enthalten sein „kann“ oder „könnte“, muss diese spezielle Komponente, dieses Merkmal, diese Struktur oder diese Eigenschaft nicht unbedingt enthalten sein. Wenn sich die Spezifikation oder der Anspruch auf „ein“ Element bezieht, bedeutet dies nicht, dass es nur ein einziges Element gibt. Wenn sich die Spezifikation oder Ansprüche auf „ein zusätzliches“ Element beziehen, schließt dies nicht aus, dass mehr als ein zusätzliches Element vorhanden ist.
  • Es ist zu beachten, dass, obwohl einige Ausführungsformen mit Bezug auf spezielle Implementierungen beschrieben wurden, gemäß einigen Ausführungsformen auch andere Implementierungen möglich sind. Darüber hinaus muss die Anordnung oder Reihenfolge von Schaltelementen oder anderen Merkmalen, die in den Zeichnungen oder hierin beschrieben sind, nicht in der speziellen dargestellten und beschriebenen Weise angeordnet werden. Je nach Ausführungsform sind viele andere Anordnungen möglich.
  • In jedem in einer Figur dargestellten System können die Elemente in einigen Fällen jeweils ein gleiches Bezugszeichen oder ein anderes Bezugszeichen aufweisen, um anzudeuten, dass die dargestellten Elemente unterschiedlich oder ähnlich sein könnten. Ein Element kann jedoch ausreichend flexibel sein, um verschiedene Implementierungen zu haben und mit einigen oder sämtlichen der hierin dargestellten oder beschriebenen Systeme zu arbeiten. Die verschiedenen in den Figuren dargestellten Elemente können gleich oder unterschiedlich sein. Welches als erstes Element bezeichnet wird und welches als zweites Element bezeichnet wird, ist beliebig.
  • Es werden Beispiele unterbreitet. Beispiel 1 ist ein Internet der Dinge (Internet of Things, IoT)-System. Das System enthält: IoT-Sensoren, um Daten zu messen und die Daten an Gateway-Vorrichtungen weiterzuleiten; die Gateway-Vorrichtungen zum Empfangen der Daten und zum Liefern der Daten an eine Cloud-Infrastruktur; und einen Koordinator, um den Gateway-Vorrichtungen Besitz an den IoT-Sensoren zuzuweisen.
  • Beispiel 2 beinhaltet das System von Beispiel 1, unter Einschluss oder Ausschluss optionaler Merkmale. In diesem Beispiel enthält das System einen Kommunikationskanal zwischen den Gateway-Vorrichtungen, wobei der Koordinator die Gateway-Vorrichtungen aufweist, um eine zentralisierte Koordination zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen zu implementieren, wobei die zentralisierte Koordination auf ein Koordinationsprotokoll zwischen den Gateway-Vorrichtungen zurückgreift.
  • Beispiel 3 beinhaltet das System eines der Beispiele 1 bis 2, unter Einschluss oder Ausschluss optionaler Merkmale. In diesem Beispiel enthält das System einen Kommunikationskanal zwischen den Gateway-Vorrichtungen, wobei der Koordinator die Gateway-Vorrichtungen und die IoT-Sensoren aufweist, um eine kooperative Koordination zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen zu implementieren. Optional kann die kooperative Koordination auf ein Koordinationsprotokoll zwischen den Gateway-Vorrichtungen und auf ein Beacon-Signal der IoT-Sensoren zurückgreifen.
  • Beispiel 4 beinhaltet das System eines der Beispiele 1 bis 3, unter Einschluss oder Ausschluss optionaler Merkmale. In diesem Beispiel weist der Koordinator die IoT-Sensoren auf, um eine dezentralisierte Koordination zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen zu implementieren. Optional weist der Koordinator die Gateway-Vorrichtungen nicht auf. Optional entscheiden die Gateway-Vorrichtungen nicht über den Besitz. Optional greifen die IoT-Sensoren auf ein Signal von den Gateway-Vorrichtungen zurück, um über den Besitz zu entscheiden.
  • Beispiel 5 beinhaltet das System eines der Beispiele 1 bis 4, unter Einschluss oder Ausschluss optionaler Merkmale. In diesem Beispiel enthält das System einen Selektor, um die Auswahl eines Koordinationsmodus für den Koordinator zum Zuweisen von Besitz zu vereinfachen.
  • Beispiel 6 stellt ein Verfahren zum Betreiben eines Internet der Dinge (IoT)-Systems dar. Das Verfahren umfasst ein Erfassen von Daten mittels IoT-Sensoren, ein Empfangen der Daten von den IoT-Sensoren an Gateway-Vorrichtungen und ein Koordinieren von Besitz der Gateway-Vorrichtung an den IoT-Sensoren.
  • Beispiel 7 beinhaltet das Verfahren von Beispiel 6, unter Einschluss oder Ausschluss optionaler Merkmale. In diesem Beispiel umfasst das Verfahren ein Liefern der Daten von den Gateway-Vorrichtungen an einen Server in einer Cloud.
  • Beispiel 8 beinhaltet das Verfahren eines der Beispiele 6 bis 7, unter Einschluss oder Ausschluss optionaler Merkmale. In diesem Beispiel umfasst das Koordinieren von Besitz der Gateway-Vorrichtungen an den IoT-Sensoren ein Implementieren einer zentralisierten Koordination durch die Gateway-Vorrichtungen zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen, wobei die zentralisierte Koordination auf ein Koordinationsprotokoll zwischen den Gateway-Vorrichtungen zurückgreift.
  • Beispiel 9 beinhaltet das Verfahren eines der Beispiele 6 bis 8, unter Einschluss oder Ausschluss optionaler Merkmale. In diesem Beispiel umfasst das Koordinieren von Besitz von Gateway-Vorrichtungen an den IoT-Sensoren ein Implementieren einer kooperativen Koordination durch die Gateway-Vorrichtungen und durch die IoT-Sensoren zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen, wobei die kooperative Koordination auf ein Koordinationsprotokoll zwischen den Gateway-Vorrichtungen und auf ein Beacon-Signal von den IoT-Sensoren zurückgreift.
  • Beispiel 10 beinhaltet das Verfahren eines der Beispiele 6 bis 9, unter Einschluss oder Ausschluss optionaler Merkmale. In diesem Beispiel umfasst das Koordinieren von Besitz der Gateway-Vorrichtungen an den IoT-Sensoren ein Implementieren einer dezentralisierten Koordination durch die IoT-Sensoren zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen. Optional entscheiden die Gateway-Vorrichtungen nicht über den Besitz. Optional umfasst das Implementieren der dezentralisierten Koordination durch die IoT-Sensoren ein Zurückgreifen auf eine Kommunikation von den Gateway-Vorrichtungen durch die IoT-Sensoren, um über den Besitz zu entscheiden. Optional ist die Kommunikation von den Gateway-Vorrichtungen ein Beacon-Signal von den Gateway-Vorrichtungen.
  • Beispiel 11 beinhaltet das Verfahren eines der Beispiele 6 bis 10, unter Einschluss oder Ausschluss optionaler Merkmale. In diesem Beispiel umfasst das Verfahren ein Auswählen eines Koordinationsmodus zum Koordinieren von Besitz der Gateway-Vorrichtung an den IoT-Sensoren.
  • Beispiel 12 ist ein materielles, nichtflüchtiges, computerlesbares Medium, das Code aufweist, der von einem Prozessor einer IoT-Vorrichtung ausgeführt werden kann, um den Prozessor zu veranlassen, den Besitz der Gateway-Vorrichtung an den IoT-Sensoren zu koordinieren und die IoT-Sensoren zu veranlassen, Daten zu messen und die Daten für Gateway-Vorrichtungen vorzusehen.
  • Beispiel 13 beinhaltet das computerlesbare Medium von Beispiel 12, unter Einschluss oder Ausschluss optionaler Merkmale. In diesem Beispiel umfasst das Koordinieren von Besitz von Gateway-Vorrichtungen an den IoT-Sensoren ein Implementieren einer zentralisierten Koordination durch die Gateway-Vorrichtungen zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen, wobei die zentralisierte Koordination auf ein Koordinationsprotokoll zwischen den Gateway-Vorrichtungen zurückgreift.
  • Beispiel 14 beinhaltet das computerlesbare Medium eines der Beispiele 12 bis 13, unter Einschluss oder Ausschluss optionaler Merkmale. In diesem Beispiel umfasst das Koordinieren von Besitz einer Gateway-Vorrichtung an den IoT-Sensoren ein Implementieren einer kooperativen Koordination durch die die Gateway-Vorrichtungen und die IoT-Sensoren zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen, wobei die kooperative Koordination auf ein Koordinationsprotokoll zwischen den Gateway-Vorrichtungen und auf ein Beacon-Signal von den IoT-Sensoren zurückgreift.
  • Beispiel 15 beinhaltet das computerlesbare Medium eines der Beispiele 12 bis 14, unter Einschluss oder Ausschluss optionaler Merkmale. In diesem Beispiel umfasst das Koordinieren von Besitz der Gateway-Vorrichtungen an den IoT-Sensoren ein Implementieren einer dezentralisierten Koordination durch die IoT-Sensoren zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen.
  • Beispiel 16 beinhaltet das computerlesbare Medium eines der Beispiele 12 bis 15, unter Einschluss oder Ausschluss optionaler Merkmale. In diesem Beispiel entscheiden die Gateway-Vorrichtungen nicht über den Besitz.
  • Beispiel 17 beinhaltet das computerlesbare Medium eines der Beispiele 12 bis 16, unter Einschluss oder Ausschluss optionaler Merkmale. In diesem Beispiel umfasst das Implementieren der dezentralisierten Koordination durch die IoT-Sensoren ein Zurückgreifen auf ein Beacon-Signal von den Gateway-Vorrichtungen durch die IoT-Sensoren, um über den Besitz zu entscheiden.
  • Beispiel 18 beinhaltet das computerlesbare Medium eines der Beispiele 12 bis 17, unter Einschluss oder Ausschluss optionaler Merkmale. In diesem Beispiel einen Code, um den Prozessor zu veranlassen, die Auswahl eines Koordinationsmodus zu vereinfachen, um den Besitz der Gateway-Vorrichtungen an den IoT-Sensoren zu koordinieren.
  • Beispiel 19 zeigt ein Internet der Dinge (IoT)-System. Das System beinhaltet IoT-Sensoren zum Messen von Daten und zum Weiterleiten der Daten an Gateway-Vorrichtungen; die Gateway-Vorrichtungen zum Empfangen der Daten und zum Liefern der Daten an eine Cloud-Infrastruktur; und einen Koordinator zum Zuweisen von Besitz an den IoT-Sensoren an die Gateway-Vorrichtungen.
  • Beispiel 20 beinhaltet das System von Beispiel 19, unter Einschluss oder Ausschluss optionaler Merkmale. In diesem Beispiel enthält das System einen Kommunikationskanal zwischen den Gateway-Vorrichtungen, wobei der Koordinator die Gateway-Vorrichtungen aufweist, um eine zentralisierte Koordination zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen zu implementieren, wobei die zentralisierte Koordination auf ein Koordinationsprotokoll zwischen den Gateway-Vorrichtungen zurückgreift.
  • Beispiel 21 beinhaltet das System eines der Beispiele 19 bis 20, unter Einschluss oder Ausschluss optionaler Merkmale. In diesem Beispiel enthält das System einen Kommunikationskanal zwischen den Gateway-Vorrichtungen, wobei der Koordinator die Gateway-Vorrichtungen und die IoT-Sensoren aufweist, um eine kooperative Koordination zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen zu implementieren, und wobei die kooperative Koordination auf ein Koordinationsprotokoll zwischen den Gateway-Vorrichtungen und auf eine Kommunikation von den IoT-Sensoren zurückgreift. Optional ist die Kommunikation von den IoT-Sensoren ein Beacon-Signal von den IoT-Sensoren.
  • Beispiel 22 beinhaltet das System eines der Beispiele 19 bis 21, unter Einschluss oder Ausschluss optionaler Merkmale. In diesem Beispiel weist der Koordinator die IoT-Sensoren auf, um eine dezentralisierte Koordination zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen zu implementieren, wobei der Koordinator die Gateway-Vorrichtungen nicht aufweist, wobei die Gateway-Vorrichtungen den Besitz nicht entscheiden, und wobei die IoT-Sensoren auf die Kommunikation von den Gateway-Vorrichtungen zurückgreifen, um über den Besitz zu entscheiden. Optional ist die Kommunikation von den Gateway-Vorrichtungen ein Beacon-Signal von den Gateway-Vorrichtungen.
  • Beispiel 23 zeigt ein Verfahren zum Betreiben eines Internet der Dinge (IoT)-Systems. Das Verfahren umfasst ein Erfassen von Daten mittels IoT-Sensoren, ein Empfangen der Daten von den IoT-Sensoren an Gateway-Vorrichtungen, ein Koordinieren von Besitz der Gateway-Vorrichtungen an den IoT-Sensoren und ein Liefern der Daten von den Gateway-Vorrichtungen an einen Server in einer Cloud.
  • Beispiel 24 beinhaltet das Verfahren von Beispiel 23, unter Einschluss oder Ausschluss optionaler Merkmale. In diesem Beispiel umfasst das Koordinieren von Besitz der Gateway-Vorrichtungen an den IoT-Sensoren ein Implementieren einer zentralisierten Koordination durch die Gateway-Vorrichtungen zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen, wobei die zentralisierte Koordination auf ein Koordinationsprotokoll zwischen den Gateway-Vorrichtungen zurückgreift.
  • Beispiel 25 beinhaltet das Verfahren eines der Beispiele 23 bis 24, unter Einschluss oder Ausschluss optionaler Merkmale. In diesem Beispiel umfasst das Koordinieren von Besitz von Gateway-Vorrichtungen an den IoT-Sensoren ein Implementieren einer kooperativen Koordination durch die Gateway-Vorrichtungen und durch die IoT-Sensoren zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen, wobei die kooperative Koordination auf ein Koordinationsprotokoll zwischen den Gateway-Vorrichtungen und auf ein Beacon-Signal von den IoT-Sensoren zurückgreift.
  • Beispiel 26 beinhaltet das Verfahren eines der Beispiele 23 bis 25, unter Einschluss oder Ausschluss optionaler Merkmale. In diesem Beispiel umfasst das Koordinieren von Besitz der Gateway-Vorrichtung an den IoT-Sensoren ein Implementieren einer dezentralisierten Koordination durch die IoT-Sensoren zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen, wobei die Gateway-Vorrichtungen den Besitz nicht bestimmen. Optional umfasst das Implementieren der dezentralisierten Koordination durch die IoT-Sensoren ein Zurückgreifen auf ein Beacon-Signal von den Gateway-Vorrichtungen durch die IoT-Sensoren, um über den Besitz zu entscheiden.
  • Beispiel 27 ist ein materielles, nichtflüchtiges, computerlesbares Medium, das Code aufweist, der von einem Prozessor einer IoT-Vorrichtung ausgeführt werden kann, um den Prozessor zu veranlassen, den Besitz der Gateway-Vorrichtung an den IoT-Sensoren zu koordinieren und die IoT-Sensoren zu veranlassen, Daten zu messen und die Daten für Gateway-Vorrichtungen vorzusehen.
  • Beispiel 28 beinhaltet das computerlesbare Medium von Beispiel 27, unter Einschluss oder Ausschluss optionaler Merkmale. In diesem Beispiel umfasst das Koordinieren von Besitz von Gateway-Vorrichtungen an den IoT-Sensoren ein Implementieren einer zentralisierten Koordination durch die Gateway-Vorrichtungen zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen, wobei die zentralisierte Koordination auf ein Koordinationsprotokoll zwischen den Gateway-Vorrichtungen zurückgreift.
  • Beispiel 29 beinhaltet das computerlesbare Medium eines der Beispiele 27 bis 28, unter Einschluss oder Ausschluss optionaler Merkmale. In diesem Beispiel umfasst das Koordinieren von Besitz von Gateway-Vorrichtungen an den IoT-Sensoren ein Implementieren einer kooperativen Koordination durch die Gateway-Vorrichtungen und durch die IoT-Sensoren zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen, wobei die kooperative Koordination auf ein Koordinationsprotokoll zwischen den Gateway-Vorrichtungen und auf ein Beacon-Signal von den IoT-Sensoren zurückgreift.
  • Beispiel 30 beinhaltet das computerlesbare Medium eines der Beispiele 27 bis 29, unter Einschluss oder Ausschluss optionaler Merkmale. In diesem Beispiel umfasst das Koordinieren von Besitz der Gateway-Vorrichtungen an den IoT-Sensoren ein Implementieren einer dezentralisierten Koordination durch die IoT-Sensoren zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen, wobei die Gateway-Vorrichtungen nicht über den Besitz entscheiden, und wobei das Implementieren der dezentralisierten Koordination durch die IoT-Sensoren ein Zurückgreifen auf eine Kommunikation von den Gateway-Vorrichtungen durch die IoT-Sensoren umfasst, um über den Besitz zu entscheiden.
  • Beispiel 31 ist ein Internet-der-Dinge (IoT)-System. Das System enthält Mittel zum Erfassen von Daten mittels IoT-Sensoren; Mittel zum Empfangen der von den IoT-Sensoren stammenden Daten bei Gateway-Vorrichtungen; und Mittel zum Koordinieren von Besitz einer Gateway-Vorrichtung an den IoT-Sensoren.
  • Beispiel 32 beinhaltet das System von Beispiel 31, unter Einschluss oder Ausschluss optionaler Merkmale. In diesem Beispiel enthält das System Mittel zum Liefern der Daten von den Gateway-Vorrichtungen an einen Server in einer Cloud.
  • Beispiel 33 beinhaltet das System eines der Beispiele 31 bis 32, unter Einschluss oder Ausschluss optionaler Merkmale. In diesem Beispiel beinhalten Mittel zum Koordinieren von Besitz der Gateway-Vorrichtung an den IoT-Sensoren Mittel zum Implementieren einer zentralisierten Koordination durch die Gateway-Vorrichtungen zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen, wobei die zentralisierte Koordination auf ein Koordinationsprotokoll zwischen den Gateway-Vorrichtungen zurückgreift.
  • Beispiel 34 beinhaltet das System eines der Beispiele 31 bis 33, unter Einschluss oder Ausschluss optionaler Merkmale. In diesem Beispiel umfassen Mittel zum Koordinieren von Besitz der Gateway-Vorrichtung an den IoT-Sensoren ein Implementieren einer kooperativen Koordination durch die Gateway-Vorrichtungen und durch die IoT-Sensoren zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen, wobei die kooperative Koordination auf ein Koordinationsprotokoll zwischen den Gateway-Vorrichtungen und auf ein Beacon-Signal von den IoT-Sensoren zurückgreift.
  • Beispiel 35 beinhaltet das System eines der Beispiele 31 bis 34, unter Einschluss oder Ausschluss optionaler Merkmale. In diesem Beispiel umfassen Mittel zum Koordinieren von Besitz der Gateway-Vorrichtungen an den IoT-Sensoren Mittel zum Implementieren einer dezentralisierten Koordination durch die IoT-Sensoren zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen. Optional entscheiden die Gateway-Vorrichtungen nicht über den Besitz. Optional umfassen die Mittel für die IoT-Sensoren, die die dezentralisierte Koordination implementieren, Mittel zum Zurückgreifen auf eine Kommunikation von den Gateway-Vorrichtungen durch die IoT-Sensoren, um über den Besitz zu entscheiden. Optional ist die Kommunikation von den Gateway-Vorrichtungen ein Beacon-Signal von den Gateway-Vorrichtungen.
  • Beispiel 36 beinhaltet das System eines der Beispiele 31 bis 35, unter Einschluss oder Ausschluss optionaler Merkmale. In diesem Beispiel enthält das System Mittel zum Auswählen eines Koordinationsmodus für die Mittel zum Koordinieren von Besitz der Gateway-Vorrichtungen an den IoT-Sensoren.
  • Es versteht sich, dass die speziellen Angaben in den vorgenannten Beispielen überall in einer oder mehreren Ausführungsformen verwendet werden können. So können beispielsweise alle optionalen Merkmale der oben beschriebenen Computervorrichtung auch in Bezug auf eines der hierin beschriebenen Verfahren oder ein computerlesbares Medium implementiert werden. Obwohl zur Beschreibung von Ausführungsformen hierin Fluss- oder Zustandsdiagramme verwendet wurden, sind die vorliegenden Techniken nicht auf diese Diagramme oder entsprechende Beschreibungen hierin beschränkt. So muss beispielsweise der Fluss nicht durch jeden dargestellten Block oder Zustand oder in genau derselben Reihenfolge verlaufen, wie hierin dargestellt und beschrieben.
  • Die vorliegenden Techniken sind nicht auf die hierin aufgeführten besonderen Details beschränkt. Tatsächlich wird der Fachmann, der über den Vorteil dieser Offenbarung verfügt, zu schätzen wissen, dass viele weitere Abweichungen von der vorausgehenden Beschreibung und den Zeichnungen im Rahmen des Schutzumfangs der vorliegenden Techniken vorgenommen werden können. Dementsprechend sind es die folgenden Ansprüche einschließlich ihrer Änderungen, die den Schutzumfang der vorliegenden Techniken definieren.
  • 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 15282276 [0001]

Claims (25)

  1. Internet der Dinge (Internet of Things, IoT)-System, aufweisend: IoT-Sensoren zum Messen von Daten und Weiterleiten der Daten an Gateway-Vorrichtungen; die Gateway-Vorrichtungen zum Empfangen der Daten und zum Liefern der Daten an eine Cloud-Infrastruktur; und einen Koordinator, um den Gateway-Vorrichtungen Besitz an den IoT-Sensoren zuzuweisen.
  2. IoT-System nach Anspruch 1, aufweisend einen Kommunikationskanal zwischen den Gateway-Vorrichtungen, wobei der Koordinator die Gateway-Vorrichtungen zum Implementieren einer zentralisierten Koordination zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen aufweist, wobei die zentralisierte Koordination auf ein Koordinationsprotokoll zwischen den Gateway-Vorrichtungen zurückgreift.
  3. IoT-System nach Anspruch 1, aufweisend einen Kommunikationskanal zwischen den Gateway-Vorrichtungen, wobei der Koordinator die Gateway-Vorrichtungen und die IoT-Sensoren zum Implementieren einer kooperativen Koordination zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen aufweist.
  4. IoT-System nach Anspruch 3, wobei die kooperative Koordination auf ein Koordinationsprotokoll zwischen den Gateway-Vorrichtungen und auf ein Beacon-Signal von den IoT-Sensoren zurückgreift.
  5. IoT-System nach Anspruch 1, wobei der Koordinator die IoT-Sensoren zum Implementieren einer dezentralisierten Koordination zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen aufweist.
  6. IoT-System nach Anspruch 5, wobei der Koordinator die Gateway-Vorrichtungen nicht aufweist.
  7. IoT-System nach Anspruch 5, wobei die Gateway-Vorrichtungen nicht über den Besitz entscheiden.
  8. IoT-System nach Anspruch 5, wobei die IoT-Sensoren auf ein Beacon-Signal der Gateway-Vorrichtungen zurückgreifen, um über den Besitz zu entscheiden.
  9. IoT-System nach Anspruch 1 bis 3, mit einem Selektor, um die Auswahl eines Koordinationsmodus für den Koordinator zum Zuweisen von Besitz zu vereinfachen.
  10. Verfahren zum Betrieb eines Internet der Dinge (IoT)-Systems, umfassend: Erfassen von Daten mittels IoT-Sensoren; Empfangen der Daten von den IoT-Sensoren an Gateway-Vorrichtungen; und Koordinieren von Besitz der Gateway-Vorrichtung an den IoT-Sensoren.
  11. Verfahren nach Anspruch 10, umfassend: Liefern der Daten von den Gateway-Vorrichtungen an einen Server in einer Cloud.
  12. Verfahren nach Anspruch 10 oder 11, wobei das Koordinieren von Besitz der Gateway-Vorrichtung an den IoT-Sensoren ein Implementieren einer zentralisierten Koordination durch die Gateway-Vorrichtungen zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen umfasst, wobei die zentralisierte Koordination auf ein Koordinationsprotokoll zwischen den Gateway-Vorrichtungen zurückgreift.
  13. Verfahren nach Anspruch 10 oder 11, wobei das Koordinieren von Besitz der Gateway-Vorrichtung an den IoT-Sensoren ein Implementieren einer kooperativen Koordination durch die Gateway-Vorrichtungen und durch die IoT-Sensoren zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen umfasst, wobei die kooperative Koordination auf ein Koordinationsprotokoll zwischen den Gateway-Vorrichtungen und auf ein Beacon-Signal von den IoT-Sensoren zurückgreift.
  14. Verfahren nach Anspruch 10, wobei das Koordinieren von Besitz der Gateway-Vorrichtung an den IoT-Sensoren ein Implementieren einer dezentralisierten Koordination durch die IoT-Sensoren zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen umfasst.
  15. Verfahren nach Anspruch 14, wobei die Gateway-Vorrichtungen nicht über den Besitz entscheiden.
  16. Verfahren nach Anspruch 14, wobei das Implementieren der dezentralisierten Koordination durch die IoT-Sensoren ein Zurückgreifen auf eine Kommunikation von den Gateway-Vorrichtungen durch die IoT-Sensoren umfasst, um über den Besitz zu entscheiden.
  17. Verfahren nach Anspruch 16, wobei die Kommunikation von den Gateway-Vorrichtungen ein Beacon-Signal von den Gateway-Vorrichtungen ist.
  18. Verfahren nach Anspruch 10 oder 11, umfassend ein Auswählen eines Koordinationsmodus zum Koordinieren von Besitz einer Gateway-Vorrichtung an den IoT-Sensoren.
  19. Materielles, nichtflüchtiges, computerlesbares Medium, das einen Code aufweist, der von einem Prozessor einer IoT-Vorrichtung ausführbar ist, um den Prozessor zu veranlassen, Besitz der Gateway-Vorrichtung an den IoT-Sensoren zu koordinieren und die IoT-Sensoren zu veranlassen, Daten zu messen und die Daten für Gateway-Vorrichtungen vorzusehen.
  20. Materielles, nichtflüchtiges, computerlesbares Medium nach Anspruch 19, wobei das Koordinieren von Besitz der Gateway-Vorrichtung an den IoT-Sensoren ein Implementieren einer zentralisierten Koordination durch die Gateway-Vorrichtungen zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen umfasst, wobei die zentralisierte Koordination auf ein Koordinationsprotokoll zwischen den Gateway-Vorrichtungen zurückgreift.
  21. Materielles, nicht flüchtiges, computerlesbares Medium nach Anspruch 19, wobei das Koordinieren von Besitz der Gateway-Vorrichtungen an den IoT-Sensoren ein Implementieren einer kooperativen Koordination durch die Gateway-Vorrichtungen und durch die IoT-Sensoren zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen umfasst, wobei die kooperative Koordination auf ein Koordinationsprotokoll zwischen den Gateway-Vorrichtungen und auf ein Beacon-Signal von den IoT-Sensoren zurückgreift.
  22. Materielles, nichtflüchtiges, computerlesbares Medium nach Anspruch 19, wobei das Koordinieren von Besitz der Gateway-Vorrichtungen an den IoT-Sensoren ein Implementieren einer dezentralisierten Koordination durch die IoT-Sensoren zum Entscheiden über und Zuweisen von Besitz an den IoT-Sensoren zu den Gateway-Vorrichtungen umfasst.
  23. Materielles, nicht flüchtiges, computerlesbares Medium nach Anspruch 19, wobei die Gateway-Vorrichtungen nicht über den Besitz entscheiden.
  24. Materielles, nichtflüchtiges, computerlesbares Medium nach Anspruch 19, wobei das Implementieren der dezentralisierten Koordination durch die IoT-Sensoren ein Zurückgreifen auf ein Beacon-Signal von den Gateway-Vorrichtungen durch die IoT-Sensoren umfasst, um über den Besitz zu entscheiden.
  25. Materielles, nichtflüchtiges, computerlesbares Medium nach Anspruch 19, wobei der Code den Prozessor veranlasst, eine Auswahl eines Koordinationsmodus zu vereinfachen, um den Besitz der Gateway-Vorrichtung an den IoT-Sensoren zu koordinieren.
DE112017004996.2T 2016-09-30 2017-08-24 Gatewaykoordination für das Internet der Dinge Pending DE112017004996T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US15/282,276 US9860677B1 (en) 2016-09-30 2016-09-30 Internet-of-things gateway coordination
US15/282,276 2016-09-30
PCT/US2017/048342 WO2018063603A1 (en) 2016-09-30 2017-08-24 Internet-of-things gateway coordination

Publications (1)

Publication Number Publication Date
DE112017004996T5 true DE112017004996T5 (de) 2019-06-27

Family

ID=60788845

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112017004996.2T Pending DE112017004996T5 (de) 2016-09-30 2017-08-24 Gatewaykoordination für das Internet der Dinge

Country Status (3)

Country Link
US (1) US9860677B1 (de)
DE (1) DE112017004996T5 (de)
WO (1) WO2018063603A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102022125428A1 (de) 2022-09-30 2024-04-04 LVX Global (Deutschland) GmbH System zum Ubertragen eines Signals mit einem Datenpaket zu und von einem aus einer Mehrzahl von Controllern

Families Citing this family (88)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9786997B2 (en) 2013-08-01 2017-10-10 Centurylink Intellectual Property Llc Wireless access point in pedestal or hand hole
US9780433B2 (en) 2013-09-06 2017-10-03 Centurylink Intellectual Property Llc Wireless distribution using cabinets, pedestals, and hand holes
US10276921B2 (en) 2013-09-06 2019-04-30 Centurylink Intellectual Property Llc Radiating closures
US10154325B2 (en) 2014-02-12 2018-12-11 Centurylink Intellectual Property Llc Point-to-point fiber insertion
US10623162B2 (en) 2015-07-23 2020-04-14 Centurylink Intellectual Property Llc Customer based internet of things (IoT)
US10375172B2 (en) 2015-07-23 2019-08-06 Centurylink Intellectual Property Llc Customer based internet of things (IOT)—transparent privacy functionality
KR20180051583A (ko) * 2015-10-07 2018-05-16 삼성전자주식회사 RESTful 서버와 oneM2M 시스템 간의 자원 매핑 방법
US10210753B2 (en) * 2015-11-01 2019-02-19 Eberle Design, Inc. Traffic monitor and method
US10033706B2 (en) * 2015-12-04 2018-07-24 Samsara Networks Inc. Secure offline data offload in a sensor network
US10412064B2 (en) 2016-01-11 2019-09-10 Centurylink Intellectual Property Llc System and method for implementing secure communications for internet of things (IOT) devices
US10832665B2 (en) 2016-05-27 2020-11-10 Centurylink Intellectual Property Llc Internet of things (IoT) human interface apparatus, system, and method
US10249103B2 (en) 2016-08-02 2019-04-02 Centurylink Intellectual Property Llc System and method for implementing added services for OBD2 smart vehicle connection
US10110272B2 (en) 2016-08-24 2018-10-23 Centurylink Intellectual Property Llc Wearable gesture control device and method
US10687377B2 (en) 2016-09-20 2020-06-16 Centurylink Intellectual Property Llc Universal wireless station for multiple simultaneous wireless services
US10750560B2 (en) 2016-09-27 2020-08-18 Extreme Networks, Inc. IoT device management using multi-protocol infrastructure network devices
US9867112B1 (en) 2016-11-23 2018-01-09 Centurylink Intellectual Property Llc System and method for implementing combined broadband and wireless self-organizing network (SON)
US10608973B2 (en) 2016-11-28 2020-03-31 Amazon Technologies, Inc. Embedded codes in messaging protocol communications
US10783016B2 (en) 2016-11-28 2020-09-22 Amazon Technologies, Inc. Remote invocation of code execution in a localized device coordinator
US10637817B2 (en) 2016-11-28 2020-04-28 Amazon Technologies, Inc. Managing messaging protocol communications
US10426358B2 (en) 2016-12-20 2019-10-01 Centurylink Intellectual Property Llc Internet of things (IoT) personal tracking apparatus, system, and method
US10735220B2 (en) 2016-12-23 2020-08-04 Centurylink Intellectual Property Llc Shared devices with private and public instances
US10637683B2 (en) 2016-12-23 2020-04-28 Centurylink Intellectual Property Llc Smart city apparatus, system, and method
US10150471B2 (en) 2016-12-23 2018-12-11 Centurylink Intellectual Property Llc Smart vehicle apparatus, system, and method
US10193981B2 (en) 2016-12-23 2019-01-29 Centurylink Intellectual Property Llc Internet of things (IoT) self-organizing network
US10222773B2 (en) 2016-12-23 2019-03-05 Centurylink Intellectual Property Llc System, apparatus, and method for implementing one or more internet of things (IoT) capable devices embedded within a roadway structure for performing various tasks
US10146024B2 (en) 2017-01-10 2018-12-04 Centurylink Intellectual Property Llc Apical conduit method and system
US20180198544A1 (en) * 2017-01-11 2018-07-12 Qualcomm Incorporated Content provider network interface
WO2018145056A1 (en) * 2017-02-06 2018-08-09 Pcms Holdings, Inc. Securing communication of devices in the internet of things
US10530864B2 (en) * 2017-02-15 2020-01-07 Dell Products, L.P. Load balancing internet-of-things (IOT) gateways
US20180316555A1 (en) * 2017-04-29 2018-11-01 Cisco Technology, Inc. Cognitive profiling and sharing of sensor data across iot networks
US10362547B2 (en) * 2017-05-17 2019-07-23 Intel Corporation Seamless and reliable chain of custody transfer over low power wireless protocol
US11025627B2 (en) * 2017-07-10 2021-06-01 Intel Corporation Scalable and secure resource isolation and sharing for IoT networks
US10383060B2 (en) * 2017-08-29 2019-08-13 Comcast Cable Communications, Llc Systems and methods for using a mobile gateway in a low power wide area network
EP3451708A1 (de) * 2017-09-01 2019-03-06 BlackBerry Limited Verfahren und system zum lastausgleich von sensoren
US10285048B2 (en) * 2017-09-06 2019-05-07 Verizon Patent And Licensing Inc. Mobility management node selection to support cloud-centric environments
US10587482B2 (en) * 2017-09-18 2020-03-10 International Business Machines Corporation Discovery of IoT devices
US10833923B2 (en) 2017-10-26 2020-11-10 Skylo Technologies Inc. Dynamic multiple access for distributed device communication networks with scheduled and unscheduled transmissions
US11095502B2 (en) * 2017-11-03 2021-08-17 Otis Elevator Company Adhoc protocol for commissioning connected devices in the field
EP3718373A4 (de) * 2017-11-27 2021-10-27 Willowmore Pte. Ltd. Gateway-einrichtung für iot sensoren oder -aktoren
CN109936547A (zh) 2017-12-18 2019-06-25 阿里巴巴集团控股有限公司 身份认证方法、系统及计算设备
US10587477B2 (en) * 2018-01-08 2020-03-10 Electronics And Telecommunications Research Institute Self-organizing network method of internet of things and apparatus performing the method
US10306442B1 (en) * 2018-01-16 2019-05-28 Skylo Technologies Inc. Devices and methods for specialized machine-to-machine communication transmission network modes via edge node capabilities
US10818117B2 (en) 2018-01-19 2020-10-27 Konnex Enterprises Inc. Systems and methods for controlling access to a secured space
TWI656446B (zh) * 2018-02-08 2019-04-11 瑞軒科技股份有限公司 物連網裝置管理裝置、通訊系統及通訊方法
US10567269B2 (en) * 2018-03-14 2020-02-18 International Business Machines Corporation Dynamically redirecting affiliated data to an edge computing device
US10303147B1 (en) 2018-03-29 2019-05-28 Saudi Arabian Oil Company Distributed industrial facility safety system modular remote sensing devices
US10311705B1 (en) * 2018-03-29 2019-06-04 Saudi Arabian Oil Company Distributed industrial facility safety system
US10613505B2 (en) 2018-03-29 2020-04-07 Saudi Arabian Oil Company Intelligent distributed industrial facility safety system
KR102178880B1 (ko) * 2018-03-30 2020-11-16 대구가톨릭대학교산학협력단 디바이스 클러스터링에 기반한 로라 통신 네트워크 시스템 및 데이터 전송 방법
US10609573B2 (en) 2018-05-08 2020-03-31 Landis+Gyr Innovations, Inc. Switching PANs while maintaining parent/child relationships
US20190349277A1 (en) * 2018-05-08 2019-11-14 Landis+Gyr Innovations, Inc. Information element to indicate loss of backhaul connection
US10530638B2 (en) 2018-05-08 2020-01-07 Landis+ Gyr Innovations, Inc. Managing connectivity for critical path nodes
TWI674779B (zh) * 2018-05-09 2019-10-11 奇邑科技股份有限公司 無線通訊系統、通訊方法與隨身收發裝置
DE102018113082A1 (de) * 2018-05-31 2019-12-05 Atos Information Technology GmbH System von dynamisch verwalteten / selbstorganisierenden Objektnetzwerken
CN109104732B (zh) * 2018-06-13 2021-06-01 珠海格力电器股份有限公司 数据发送方法、装置及智能电器
CN108924806A (zh) * 2018-07-19 2018-11-30 廊坊新奥燃气设备有限公司 一种采用ble技术的家庭物联网数据通信方法及系统
US11195066B2 (en) 2018-09-11 2021-12-07 International Business Machines Corporation Automatic protocol discovery using text analytics
DE102018008721A1 (de) 2018-11-06 2020-01-23 Giesecke+Devrient Mobile Security Gmbh Anbindung eines Endgeräts an einen Datendienst
US10666724B1 (en) * 2018-11-20 2020-05-26 Microsoft Technology Licensing, Llc Geo-replicated IoT hub
US11200331B1 (en) 2018-11-21 2021-12-14 Amazon Technologies, Inc. Management of protected data in a localized device coordinator
CN109788605A (zh) * 2018-11-28 2019-05-21 赛尔富电子有限公司 基于物联网的智能照明控制系统
US11108849B2 (en) * 2018-12-03 2021-08-31 At&T Intellectual Property I, L.P. Global internet of things (IOT) quality of service (QOS) realization through collaborative edge gateways
US10785125B2 (en) 2018-12-03 2020-09-22 At&T Intellectual Property I, L.P. Method and procedure for generating reputation scores for IoT devices based on distributed analysis
US10796548B2 (en) 2018-12-28 2020-10-06 Intel Corporation Management of guardianship of an entity including via elastic boundaries
US11004316B2 (en) * 2019-01-14 2021-05-11 Ademco Inc. Systems and methods for responding to an abnormal event in a region monitored by a security system
CN111435950B (zh) * 2019-01-15 2022-05-27 阿里巴巴集团控股有限公司 一种终端的地址配置方法和装置
US10659144B1 (en) * 2019-01-31 2020-05-19 At&T Intellectual Property I, L.P. Management of massively distributed internet of things (IOT) gateways based on software-defined networking (SDN) via fly-by master drones
CN111669418B (zh) * 2019-03-07 2022-09-27 阿里巴巴集团控股有限公司 数据通信方法、数据同步方法、系统、装置、网关设备、服务器及基站设备
US11372654B1 (en) 2019-03-25 2022-06-28 Amazon Technologies, Inc. Remote filesystem permissions management for on-demand code execution
CN110213733B (zh) * 2019-05-23 2022-07-19 武汉金牛经济发展有限公司 一种电磁热熔焊机物联网络系统
US11582027B1 (en) * 2019-06-28 2023-02-14 Amazon Technologies, Inc. Secure communication with individual edge devices of remote networks that use local security credentials
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
CN110417782B (zh) * 2019-07-30 2022-04-12 三体云智能科技有限公司 一种用于智能硬件消息传输的系统、方法及可读介质
US11445572B2 (en) * 2019-11-14 2022-09-13 FW Murphy Production Controls, LLC IoT gateway for remote natural gas compression systems
KR102293374B1 (ko) * 2019-11-19 2021-08-24 주식회사 리퓨터 IoT 디바이스 게이트웨이
WO2021119463A1 (en) * 2019-12-12 2021-06-17 Biometric Associates, Lp Prioritized wireless presence access control system
TWI795619B (zh) * 2019-12-23 2023-03-11 奇邑科技股份有限公司 內建伺服模組的閘道裝置與通信系統
CN114788393B (zh) * 2019-12-30 2024-08-20 Oppo广东移动通信有限公司 设备间通信方法、装置、和存储介质
US11369006B2 (en) 2020-06-19 2022-06-21 Urbit Group LLC IoT gateway device, system, and computer program product
US11568693B2 (en) 2020-07-24 2023-01-31 Konnex Enterprises Inc. Systems, devices, and methods for controlling access to a secure space
CN112350925A (zh) * 2020-11-06 2021-02-09 北京小米移动软件有限公司 网关控制方法、装置、系统、电子设备及存储介质
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
US11412436B2 (en) 2021-01-08 2022-08-09 Charter Communications Operating, Llc Optimized multicast messaging in LPWA networks
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
US11659627B2 (en) * 2021-08-09 2023-05-23 Corning Research & Development Corporation Systems and methods for splitting cells in a network for internet of things (IoT)
CN114500605A (zh) * 2022-02-18 2022-05-13 百斯特（广州）信息技术有限公司 一种基于5g的工业物联网数据传输方法及智能网关

Family Cites Families (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7414982B2 (en) 2003-06-24 2008-08-19 Raytheon Company Distributed dynamic channel selection in a communication network
US7443833B2 (en) 2004-08-06 2008-10-28 Sharp Laboratories Of America, Inc. Ad hoc network topology discovery
US7653465B1 (en) * 2004-11-01 2010-01-26 Microwave Data Systems, Inc. System and method for remote control of locomotives
WO2012150608A1 (en) * 2011-04-30 2012-11-08 Ineda Systems Pvt. Ltd Peripheral device sharing in multi host computing systems
US20130097317A1 (en) 2011-10-18 2013-04-18 Daniel Sheleheda Method and apparatus for remote trust management for machine to machine communications in a network
US9513648B2 (en) * 2012-07-31 2016-12-06 Causam Energy, Inc. System, method, and apparatus for electric power grid and network management of grid elements
KR102046287B1 (ko) * 2013-05-06 2019-11-18 콘비다 와이어리스, 엘엘씨 사물 인터넷 적응화 서비스들
JP6232126B2 (ja) * 2013-05-08 2017-11-15 コンヴィーダ ワイヤレス， エルエルシー 仮想化ブローカおよびコンテキスト情報を使用するリソースの仮想化のための方法および装置
EP3005659B1 (de) * 2013-05-28 2019-07-10 Convida Wireless, LLC Lastausgleich im internet der dinge
US20150026044A1 (en) 2013-07-07 2015-01-22 Gaonic Ltd. Method, protocol and system for universal sensor communication
US20150134954A1 (en) * 2013-11-14 2015-05-14 Broadcom Corporation Sensor management system in an iot network
US20150134801A1 (en) * 2013-11-14 2015-05-14 Broadcom Corporation Making policy-based decisions in a network
US10237717B2 (en) * 2014-04-13 2019-03-19 Lg Electronics Inc. Method for proximity-based notification in wireless communication system, and device for same
US9774410B2 (en) * 2014-06-10 2017-09-26 PB, Inc. Radiobeacon data sharing by forwarding low energy transmissions to a cloud host
KR102210670B1 (ko) * 2014-06-20 2021-02-02 삼성전자 주식회사 게이트웨이에 장치를 등록하는 방법 및 장치
US20150381737A1 (en) * 2014-06-30 2015-12-31 Davra Networks Limited Gateway device and a gateway system for an internet-of-things environment
US10063439B2 (en) * 2014-09-09 2018-08-28 Belkin International Inc. Coordinated and device-distributed detection of abnormal network device operation
US10230431B2 (en) * 2014-09-12 2019-03-12 Parallel Wireless, Inc. Low-latency inter-eNodeB coordinated multi-point transmission
US10382294B2 (en) * 2014-09-25 2019-08-13 Oracle International Corporation Platform for capturing, processing, storing, and presentation of generic sensor data from remote arbitrary locations
US20160127460A1 (en) * 2014-11-03 2016-05-05 Qualcomm Technologies Inc. Multi-hop wireless peer-to-peer discovery protocol
US9762556B2 (en) * 2015-01-09 2017-09-12 Verisign, Inc. Registering, managing, and communicating with IOT devices using domain name system processes
US20160205106A1 (en) * 2015-01-12 2016-07-14 Verisign, Inc. Systems and methods for providing iot services
US10282484B2 (en) * 2015-01-12 2019-05-07 Verisign, Inc. Systems and methods for ontological searching in an IOT environment
US9935950B2 (en) * 2015-01-12 2018-04-03 Verisign, Inc. Systems and methods for establishing ownership and delegation ownership of IOT devices using domain name system services
US20160241999A1 (en) * 2015-02-16 2016-08-18 Polaris Tech Global Limited Cross-platform automated perimeter access control system and method adopting selective adapter
WO2016134267A1 (en) * 2015-02-20 2016-08-25 Convida Wireless, Llc Message bus service directory
US9633197B2 (en) * 2015-03-06 2017-04-25 Verisign, Inc. Systems and methods for device detection and authorization in a IOT framework
US10129813B2 (en) * 2015-03-11 2018-11-13 Cisco Technology, Inc. Minimizing link layer discovery based on advertising access technology parameters in a multimode mesh network
EP3281386B1 (de) * 2015-04-07 2020-01-01 Tyco Fire & Security GmbH End-zu-end-authentifizierung und sicherheit zwischen maschine und maschine sowie maschine und cloud
US10178533B2 (en) * 2015-05-29 2019-01-08 Resolution Products, Inc. Security systems
US11062255B2 (en) * 2015-06-24 2021-07-13 Intel Corporation Technologies for managing the security and custody of assets in transit
US11019149B2 (en) * 2015-07-10 2021-05-25 Samsung Electronics Co., Ltd Hub apparatus and method for providing service thereof

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102022125428A1 (de) 2022-09-30 2024-04-04 LVX Global (Deutschland) GmbH System zum Ubertragen eines Signals mit einem Datenpaket zu und von einem aus einer Mehrzahl von Controllern

Also Published As

Publication number Publication date
WO2018063603A1 (en) 2018-04-05
US9860677B1 (en) 2018-01-02

Similar Documents

Publication Publication Date Title
DE112017004996T5 (de) Gatewaykoordination für das Internet der Dinge
DE112018005693T5 (de) Multi-access edge computing (mec)-basierte mehrbetreiberunterstützung für cellular vehicle-to-everything (c-v2x) systeme
DE112020001183T5 (de) Multi-slice-unterstützung für mec-fähige 5g-implementierungen
DE112018007463T5 (de) Flexibler Mehrfachzugriffs-Edge-Computing-Dienstverbrauch (Mec-Dienstverbrauch) durch Hostzoning
DE102019105398A1 (de) Inter-mec-systemkommunikation für v2x-services
DE102020201015A1 (de) Technologien zum verteilen iterativer berechnungen in heterogenen computerumgebungen
DE112020003766T5 (de) Linkleistungsprognose und Medienstreaming-Technologien
DE102019217367A1 (de) VERWALTUNG DER DIENSTQUALITÄT (QoS) IN EDGE-COMPUTING-UMGEBUNGEN
DE102021211176A1 (de) Interoperables framework für sicheren verbrauch von dual-modus-edge-anwendungsprogrammierungsschnittstellen in hybriden edge-computing-plattformen
DE112018005810T5 (de) Plugin-management für internet of things- (iot) netzwerkoptimierung
DE112018006098T5 (de) Übergabebezogene technologie, vorrichtungen und verfahren
DE102020202398A1 (de) Edge-server-cpu mit dynamischer deterministischer skalierung
DE102021209988A1 (de) Techniken zur klassifizierung und priorisierung von mehrfachzugangsverwaltungsdienstpaketen
DE112018007704T5 (de) Modulares System für das Internet der Dinge
DE112017006994T5 (de) Bereitstellung und verwaltung von microservices
DE102022211605A1 (de) Zuverlässigkeitsverbesserungen für mehrfachzugangsverkehrsverwaltung
DE112020007003T5 (de) Multi-funkzugangstechnologie-verkehrsverwaltung
DE112017008033T5 (de) Gemeinsames Schnittstellensystem für Maschennetzwerke und Fog-Computersysteme
DE112017006715T5 (de) Sensorverwaltung und -zuverlässigkeit
DE112019003316T5 (de) Verteiltes berechnungsverfahren, vorrichtung und system
DE112017004201T5 (de) Vorrichtung zur prüfung der erfüllung für dienstleistungsvereinbarung
DE102020129306A1 (de) Übermittlung von paging-unterstützungsinformationen zur benachrichtigung über die anruferidentifikation (cid)
DE102019103663A1 (de) Datenfragmentrekombination für Internet-of-Things-Einrichtungen
DE112020001628T5 (de) Benutzerausrüstung (ue) messfähigkeit in hochgeschwindigkeitsszenarien
DE112017007355T5 (de) Drahtlose vorrichtungsinformationssysteme und verfahren

Legal Events

Date Code Title Description
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0029080000

Ipc: H04L0065000000

R012 Request for examination validly filed