DE102019103663A1 - Datenfragmentrekombination für Internet-of-Things-Einrichtungen - Google Patents

Datenfragmentrekombination für Internet-of-Things-Einrichtungen Download PDF

Info

Publication number
DE102019103663A1
DE102019103663A1 DE102019103663.1A DE102019103663A DE102019103663A1 DE 102019103663 A1 DE102019103663 A1 DE 102019103663A1 DE 102019103663 A DE102019103663 A DE 102019103663A DE 102019103663 A1 DE102019103663 A1 DE 102019103663A1
Authority
DE
Germany
Prior art keywords
data
payload
received
fragment
iot
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
DE102019103663.1A
Other languages
English (en)
Inventor
Keith Nolan
Mark Kelly
Michael Nolan
Pat Cheevers
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 DE102019103663A1 publication Critical patent/DE102019103663A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • 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/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/34—Flow control; Congestion control ensuring sequence integrity, e.g. using sequence numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps

Landscapes

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

Abstract

In manchen Beispielen eine Internet-of-Things(IoT)-Einrichtung zum Rekombinieren von Datenfragmenten von Nutzdaten. Die IoT-Einrichtung enthält einen Speicher, um Befehle zu speichern, und einen Prozessor. Der Prozessor ist dazu vorgesehen, die gespeicherten Befehle auszuführen, um die Datenfragmente in einer Reihenfolge oder nicht in einer Reihenfolge zu empfangen, um zu ermitteln, ob alle Datenfragmente der Nutzdaten empfangen worden sind, und, wenn alle Datenfragmente der Nutzdaten empfangen worden sind, die Datenfragmente in einer Reihenfolge zu speichern.

Description

  • Gebiet der Technik
  • Die vorliegenden Techniken betreffen allgemein Internet-of-Things(IoT)-Einrichtungen, die zum Beispiel IoT-Einrichtungen, die entfernte Sensor- und Betätigungsfunktionen durchführen können, enthalten. Insbesondere betreffen die vorliegenden Techniken eine Datenrekombination, die für IoT-Einrichtungen implementiert werden kann.
  • Stand der Technik
  • Eine derzeitige Darstellung des Internets ist die Verbindung von Clients wie PCs, Tablets, Smartphones, Servern, digitalen Fotorahmen und Einrichtungen von noch vielen anderen Arten mit öffentlich zugänglichen Rechenzentren, die auf Server-Farmen gehostet werden. Dabei wird aber nur ein kleiner Anteil der gesamten Nutzung des Netzes mit weltweiten Verbindungen dargestellt. Derzeit gibt es sehr viele vernetzte Ressourcen, die jedoch nicht öffentlich zugänglich sind. Beispiele hierfür sind Intranets, private Organisationssteuerungsnetze und weltumspannende Überwachungsnetze, die zur Wahrung der Anonymität oft Peer-to-Peer-Relays nutzen.
  • Schätzungen zufolge wird das Internet der Dinge (Internet of Things, IoT) bis 2020 Internet-Konnektivität möglicherweise für über 15 Milliarden Einrichtungen bereitstellen. Für Organisationen können IoT-Einrichtungen Möglichkeiten zum Überwachen, Kontrollieren oder Steuern von anderen Einrichtungen und Dingen bereitstellen, auch von weiteren IoT-Einrichtungen, anderen zu Hause oder in der Industrie eingesetzten Einrichtungen, Elementen in Fertigungs- und Lebensmittelherstellungsketten und dergleichen. Das Aufkommen von IoT-Netzen hat eine tiefgreifende Veränderung in der Weiterentwicklung des Internets ausgelöst. In Zukunft wird sich das Internet wahrscheinlich von einem vorwiegend an Menschen ausgerichteten Werkzeug zu einer Infrastruktur weiterentwickeln, an der Menschen in einer vernetzten Welt von Einrichtungen letztendlich nur noch unwesentlich beteiligt sein werden.
  • In dieser Darstellung wird das Internet zu einem Kommunikationssystem werden, in dem Einrichtungen sowie Netze von Einrichtungen nicht nur mit Rechenzentren, sondern auch untereinander kommunizieren werden. Die Einrichtungen bilden dabei möglicherweise funktionsabhängige Netze oder virtuelle Einrichtungen zur Durchführung von Funktionen, die sich auflösen können, sobald die Funktion durchgeführt worden ist. Schwierigkeiten zeigen sich im Zusammenhang mit dem Ermöglichen zuverlässiger, sicherer und identifizierbarer Einrichtungen, die Netze, wie zur Ausführung von Aufgaben erforderlich, bilden können.
  • Figurenliste
    • 1 veranschaulicht Zwischenverbindungen, die im Internet vorhanden sein können, gemäß manchen Ausführungsformen.
    • 2 veranschaulicht eine Netztopologie für einige über Backbone-Verbindungen an Gateways gekoppelte Internet-of-Things(IoT)-Netze gemäß manchen Ausführungsformen.
    • 3 veranschaulicht ein Cloud-Computing-Netz bzw. eine Cloud in Kommunikation mit einigen IoT-Einrichtungen gemäß manchen Ausführungsformen.
    • 4 veranschaulicht ein Cloud-Computing-Netz bzw. eine Cloud in Kommunikation mit einem Mesh-Netz von IoT-Einrichtungen, das als Fog-Einrichtung bezeichnet werden kann und am Rand der Cloud betrieben wird, gemäß manchen Ausführungsformen.
    • 5 veranschaulicht ein System gemäß manchen Ausführungsformen.
    • 6 veranschaulicht eine Datenfragmentierung und eine Datenrekombination gemäß manchen Ausführungsformen.
    • 7 veranschaulicht eine Datenfragmentierung und eine Datenrekombination gemäß manchen Ausführungsformen.
    • 8 veranschaulicht eine Datenrekombination gemäß manchen Ausführungsformen.
    • 9 veranschaulicht eine Datenrekombination gemäß manchen Ausführungsformen.
    • 10 veranschaulicht eine Datenrekombination gemäß manchen Ausführungsformen.
    • 11 veranschaulicht eine Datenrekombination gemäß manchen Ausführungsformen.
    • 12 veranschaulicht ein Teilbilddatensequenzdiagramm gemäß manchen Ausführungsformen.
    • 13 ist ein Blockschema von beispielhaften Komponenten, die in einer IoT-Einrichtung zum Implementieren einer Datenfragmentierung und/oder einer Datenrekombination gemäß manchen Ausführungsformen vorhanden sein können.
    • 14 ist ein Blockschema eines Mediums oder von Medien wie eines oder mehrerer nichttransienter, maschinenlesbarer Medien, das/die Code zum Anweisen eines Prozessors zum Implementieren einer Datenfragmentierung und/oder einer Datenrekombination gemäß manchen Ausführungsformen enthält/enthalten.
  • In der Offenbarung und den Figuren werden für Bezugnahmen auf gleiche Komponenten und Merkmale jeweils dieselben Bezugszeichen genutzt. Bezugszeichen, für die 100er-Zahlen gewählt wurden, beziehen sich auf Merkmale, die zuerst in 1 zu sehen sind; Bezugszeichen, für die 200er-Zahlen gewählt wurden, beziehen sich auf Merkmale, die zuerst in 2 zu sehen sind; und so weiter.
  • Beschreibung der Ausführungsformen
  • In manchen Ausführungsformen werden/wird eine Datenfragmentierung und/oder eine Datenrekombination implementiert. Zum Beispiel werden in manchen Ausführungsformen eine Datenfragmentierung und/oder eine Datenrekombination in Internet-of-Things(IoT)-Netzen implementiert (zum Beispiel eine Datenfragmentierung und/oder eine Datenrekombination in IoT-Netzen wie Fog-Netzen oder Edge-Netzen). Manche Ausführungsformen betreffen eine Datenfragmentrekombination.
  • Manche Ausführungsformen betreffen eine Übertragung fragmentierter Dateien über ein komplexes Netz. Manche Netze (zum Beispiel manche IoT-Netze) sind so gestaltet, dass sie große Dateien über weite Entfernungen (zum Beispiel über Einrichtungen für eine drahtlose Übertragung) übertragen. Solche Einrichtungen für eine drahtlose Übertragung können flüchtig sein und eine große Menge von Daten (zum Beispiel Bild- oder Videodateien) unterstützen. In manchen Ausführungsformen können diese großen Datendateien fragmentiert und in Fragmenten über ein komplexes Netz übertragen werden. Zum Beispiel können die Datendateien in manchen Ausführungsformen über ein komplexes Netz, das mehrere Verbindungen enthalten kann, übertragen werden.
  • Manche Ausführungsformen betreffen die Wiederherstellung der fragmentierten Dateien, die zum Beispiel den Umgang mit Fehlern, Wiederholungsversuchen, Wiederholungen und/oder anderen in der realen Welt auftretenden Problemen mit Auswirkungen auf die Qualität des Datenfragmentierungs- und Datenrekombinationsprozesses enthält. In manchen Ausführungsformen kann der Prozess in einer von Funkprotokollen unabhängigen Weise implementiert werden, und er kann über mehrere unterschiedliche Funkprotokolle, die eingeschränkte Funkprotokolle (die zum Beispiel mehrere zehn bis mehrere hundert Bytes pro Sekunde unterstützen und/oder für weite Entfernungen, zum Beispiel 15 Kilometer oder mehr, vorgesehen sind) enthalten, implementiert werden.
  • Manche Ausführungsformen können mit besonders großen Dateien über Verbindungen mit mittlerer oder hoher Bandbreite implementiert werden, zum Beispiel wenn eine große Datei in eine Anzahl von Teilen (oder Fragmenten), die jeweils einzeln über das Netz übertragen werden, aufgeteilt wird. Die Fragmentierung und die Rekombination der Fragmente sind nicht an einen bestimmten Dateityp und nicht an eine bestimmte Dateigröße gebunden und sind mit beliebigen Datendateitypen gemäß manchen Ausführungsformen implementierbar. Zum Beispiel können Ausführungsformen mit großen Datendateien über schnelle Verbindungen implementiert werden. In manchen Ausführungsformen könnten die Datenfragmentierung und die Datenrekombination zum Beispiel über eine schnelle Verbindung (zum Beispiel eine 10-Gigabit-Verbindung) mit großen Dateigrößen (zum Beispiel einer Dateigröße in Terabyte) implementiert werden, und Daten könnten zu großen Blöcken (zum Beispiel mehrere hundert Gigabyte große Fragmente) fragmentiert werden.
  • Manche Ausführungsformen sind systemunabhängig. Manche Ausführungsformen können zum Beispiel auf eine Datenfragmentierung und eine Übertragung über diverse Netze, die IoT-Netze mit IoT-Einrichtungen, Kabelnetze und/oder kabellose Netze enthalten, bezogen sein. Manche Ausführungsformen können zum Beispiel für Fragmente, die über LoRaWAN™ (Long Range Wide Area Network), WiFi, Ethernet, Mobilfunk- oder andere Übertragungsprotokolle, einschließlich beliebiger Kombinationen davon, übertragen werden, implementiert werden. Manche Ausführungsformen sind kabelgebunden und/oder von Funkprotokollen unabhängig.
  • Die 1-5 enthalten beispielhafte Betriebsumgebungen wie Internet-of-Things(IoT)-Umgebungen, in denen die hierin beschriebenen Prinzipien angewendet werden können. In den beispielhaften Betriebsumgebungen gemäß den 1-5 können Prinzipien der Datenfragmentierung und/oder der Datenrekombination, wie hierin beschrieben und in den beiliegenden Zeichnungen veranschaulicht, angewendet werden (zum Beispiel eine Datenfragmentierung und/oder eine Datenrekombination für Fog-Netze, Edge-Netze, Foglets etc.).
  • Das Internet der Dinge (Internet of Things, IoT) ist ein System, in dem sehr viele Computereinrichtungen miteinander sowie mit einem Kommunikationsnetz (z. B. dem Internet) verbunden sind, um eine Funktionalität wie eine Erfassung von Daten und Betätigungen bei sehr geringen Signalstärken in Netzen bereitzustellen. Geringe Signalstärken weisen auf Einrichtungen hin, die sich am Netzrand oder in Netzrandnähe befinden können, etwa die letzten Einrichtungen, bevor die Netze enden. Wie hierin genutzt, kann eine IoT-Einrichtung eine Einrichtung, die eine Funktion wie unter anderem eine Sensor- oder Steuerungsfunktion durchführt, in Kommunikation mit anderen IoT-Einrichtungen und einem Kommunikationsnetz enthalten. Die IoT-Einrichtung enthält möglicherweise eine autonome oder teilautonome Einrichtung, die zum Durchführen einer oder mehrerer Funktionen konfiguriert ist. Oft können IoT-Einrichtungen Speicher-, Größen- oder Funktionalitätseinschränkungen aufweisen, sodass mehr von ihnen eingesetzt werden können, wobei jedoch ähnlich hohe Kosten wie bei einem Einsatz von weniger, dafür größeren Einrichtungen anfallen. Eine IoT-Einrichtung kann jedoch auch ein Smartphone, ein Laptop, ein Tablet, ein PC und/oder eine andere größere Einrichtung sein. Ferner kann eine IoT-Einrichtung eine virtuelle Einrichtung sein, etwa eine App auf einem Smartphone oder einer anderen Computereinrichtung. IoT-Einrichtungen enthalten möglicherweise IoT-Gateways, die dazu genutzt werden, um IoT-Einrichtungen an andere IoT-Einrichtungen und an Cloudanwendungen zur Datenspeicherung, Prozesssteuerung und dergleichen zu koppeln.
  • Netze von IoT-Einrichtungen können kommerziell und privat genutzte Einrichtungen enthalten, etwa unter anderem Wasserverteilungssysteme, Stromverteilungssysteme, Pipelinesteuerungssysteme, Anlagensteuerungssysteme, Lichtschalter, Thermostate, Schließvorrichtungen, Kameras, Alarmanlagen, Bewegungssensoren und dergleichen. Der Zugriff auf die IoT-Einrichtungen kann über einen Controller, etwa Computer, Server und andere Systeme, erfolgen, zum Beispiel um Systeme zu steuern oder um auf Daten zuzugreifen. Der Controller und die IoT-Einrichtungen können sich voneinander entfernt befinden.
  • Das Internet kann zum Bereitstellen von Kommunikationen für eine große Anzahl von IoT-Einrichtungen konfiguriert sein. Daher wird, wie hierin beschrieben, mit etlichen Neuerungen für das Internet der Zukunft darauf eingegangen, dass ein Bedarf daran besteht, dass sich Netzebenen von zentralen Servern über Gateways bis hinunter zu Edge Devices ungehindert weiterentwickeln, dass vernetzte Ressourcen erkannt und zugänglich gemacht werden und dass die Möglichkeit zum Verbergen und Unterteilen vernetzter Ressourcen unterstützt wird. Es können beliebig viele Netzprotokolle und Kommunikationsstandards genutzt werden, wobei jedes Protokoll und jeder Standard jeweils zur Erfüllung eines speziellen Zwecks vorgesehen ist. Ferner sind die Protokolle ein Teil der Fabric, die für Menschen zugängliche sowie orts-, zeit- oder raumunabhängig ausgeführte Dienste unterstützt. Die Neuerungen enthalten eine Dienstübermittlung und eine assoziierte Infrastruktur, etwa Hardware und Software. Die Dienste können gemäß den in Service Level Agreements und Dienstübermittlungsvereinbarungen festgelegten QoS-Bedingungen (QoS = Quality of Service) bereitgestellt werden. In einem heterogenen Konnektivitätsnetz, das eine Kombination von kabelgebundenen und kabellosen Technologien enthält, wie zum Beispiel in 1 und 2 abgebildet, treten bei der Nutzung von IoT-Einrichtungen und IoT-Netzen etliche neue Schwierigkeiten auf.
  • 1 ist eine Darstellung von Zwischenverbindungen, die zwischen dem Internet 100 und IoT-Netzen gemäß manchen Ausführungsformen vorhanden sein können. Die Zwischenverbindungen können kleinere Netze 102, auch etwa nur die einzelne IoT-Einrichtung 104, an das Backbone 106 des Internets 100 koppeln. Zur Vereinfachung der Darstellung ist nicht jede Einrichtung 104 bzw. nicht jedes weitere Objekt mit einem Bezugszeichen versehen.
  • In 1 sind Provider der Hauptschicht, die als Tier-1(„T1“)-Provider 108 bezeichnet werden, über das Backbone 106 des Internets an andere Provider, etwa sekundäre oder Tier-2(„T2“)-Provider 110, gekoppelt. In manchen Ausgestaltungen kann das Backbone 106 Glasfaserverbindungen enthalten. In einem Beispiel kann ein T2-Provider 110 zum Beispiel über weitere Verbindungen, über Mikrowellenkommunikationen 114 oder über andere Kommunikationstechniken an einen Mobilfunkmast 112 eines LTE-Mobilfunknetzes gekoppelt sein. Der Mobilfunkmast 112 kann über eine LTE-Kommunikationsverbindung 116, zum Beispiel über einen zentralen Knoten 118, an ein IoT-Einrichtungen 104 enthaltendes Mesh-Netz gekoppelt sein. Die Kommunikationen zwischen den einzelnen IoT-Einrichtungen 104 können auch auf LTE-Kommunikationsverbindungen 116 basieren.
  • In einem weiteren Beispiel koppelt möglicherweise ein Hochgeschwindigkeits-Uplink 119 einen T2-Provider 110 an ein Gateway 120. Mit dem Gateway 120 kommunizieren möglicherweise etliche IoT-Einrichtungen 104, die über das Gateway 120 auch miteinander kommunizieren, zum Beispiel über Bluetooth-Low-Energy(BLE)-Verbindungen 122.
  • Das Backbone 106 kann Serviceprovider auf unteren Schichten wie Tier-3(„T3“)-Provider 124 an das Internet koppeln. Ein T3-Provider 124 kann als allgemeiner Internet Service Provider (ISP), der zum Beispiel von einem T2-Provider 110 den Zugang zum Backbone 106 erwirbt und den Zugang für ein Unternehmens-Gateway 126 und andere Kunden bereitstellt, angesehen werden.
  • Über das Unternehmens-Gateway 126 kann ein Wireless Local Area Network (WLAN) zum Kommunizieren mit IoT-Einrichtungen 104 über Wi-Fi®-Verbindungen 128 genutzt werden. Eine Wi-Fi-Verbindung 128 kann auch zur Kopplung an ein Low-Power-Wide-Area(LPWA)-Gateway 130 genutzt werden, das über LPWA-Verbindungen 132, die zum Beispiel mit der von der LoRa Alliance veröffentlichten LoRaWAN™-Spezifikation (Long Range Wide Area Network) kompatibel sind, mit IoT-Einrichtungen 104 kommunizieren kann.
  • Der T3-Provider 124 kann auch den Zugang zu einem Mesh-Netz 134 über eine mit dem T3-Provider 124 kommunizierende Koordinatoreinrichtung 136 über beliebig viele Kommunikationsverbindungen wie eine LTE-Mobilfunkverbindung, eine LPWA-Verbindung oder eine auf dem Standard IEEE 802.15.4 basierende Verbindung 138 wie Zigbee® bereitstellen. Noch weitere Koordinatoreinrichtungen 136 können eine Kette von Verbindungen bereitstellen, die einen oder mehrere Clusterbäume aus vernetzten Einrichtungen bildet.
  • In manchen Ausgestaltungen enthalten eine oder mehrere IoT-Einrichtungen 104 den entsprechenden Transceiver für die Kommunikationen mit anderen Einrichtungen. Ferner enthalten eine oder mehrere IoT-Einrichtungen 104 möglicherweise auch Funktransceiver, optische Transceiver oder akustische Transceiver sowie Kabelnetzanschlüsse für Kommunikationen unter Nutzung weiterer Protokolle und Frequenzen. In manchen Ausgestaltungen enthalten eine oder mehrere IoT-Einrichtungen 104 Komponenten, die im Zusammenhang mit 13 beschrieben werden.
  • Die Technologien und Netze können die Erweiterung von Einrichtungen und Netzen ermöglichen. Im Zuge des Ausbaus der Technologien kann das Netz in puncto Selbstverwaltung, funktionale Weiterentwicklung und/oder Zusammenarbeit ohne die Notwendigkeit direkter menschlicher Eingriffe ausgebaut werden. Mithin können die Technologien einen Netzbetrieb ohne zentrale gesteuerte Systeme ermöglichen. Mithilfe der hierin beschriebenen Technologien sind die Netzverwaltungs- und Netzbetriebsfunktionen über die momentanen Möglichkeiten hinaus automatisierbar. Ferner können die Ansätze die Flexibilität einer zentralen Steuerung ohne menschliche Eingriffe, einer zentralen, automatisierten Steuerung oder beliebiger Kombinationen davon bieten.
  • 2 ist eine Darstellung einer Netztopologie 200, die für etliche über Backbone-Verbindungen 202 an Gateways 204 gekoppelte Internetof-Things(IoT)-Netze gemäß manchen Ausführungsformen genutzt werden kann. Elemente, die mit selben Bezugszeichen versehen sind, entsprechen den mit Bezug zu 1 beschriebenen Elementen. Zur Vereinfachung der Darstellung ist außerdem nicht jede Einrichtung 104 bzw. nicht jede Kommunikationsverbindung 116, 122, 128 oder 132 mit einem Bezugszeichen versehen. Die Backbone-Verbindungen 202 können beliebig viele kabelgebundene oder kabellose Technologien enthalten und können Teil eines Local Area Network (LAN), eines Wide Area Network (WAN) oder des Internets sein.
  • Auch wenn in 2 Sterntopologien verwendet werden und in 1 eine Peer-to-Peer-Topologie vorliegt, ist ersichtlich, dass diese nicht im Konflikt sind, sondern dass sich Peer-to-Peer-Knoten wie Knoten in einer Sterntopologie über Gateways verhalten können. In 2 ist auch ersichtlich, dass eine Subnetztopologie mehrere Gateways aufweisen kann, sodass statt einer reinen Sterntopologie (oder vielmehr einer vollständigen Sterntopologie) eine hybride Topologie vorliegt.
  • Die Netztopologie 200 kann IoT-Netze von beliebig vielen Typen enthalten, auch etwa ein Mesh-Netz 206, das Bluetooth-Low-Energy(BLE)-Verbindungen 122 nutzt. Zu weiteren IoT-Netzen, die vorhanden sein können, zählen ein WLAN-Netz 208, ein Mobilfunknetz 210 und ein LPWA-Netz 212. Jedes dieser IoT-Netze kann Möglichkeiten für neue Entwicklungen bereitstellen, wie hierin beschrieben.
  • Kommunikationen zwischen IoT-Einrichtungen 104, etwa über die Backbone-Verbindungen 202, können zum Beispiel durch ein dezentrales AAA-System (AAA = Authentication, Authorization, and Accounting) geschützt werden. In einem dezentralen AAA-System können verteilte Zahlungs-, Kredit-, Auditing-, Autorisierungs-, Vermittlungs-, Arbitrierungs- und Authentifizierungssysteme über eine vernetzte, heterogene Infrastruktur implementiert werden. Hierdurch können in Systemen und Netzen Abläufe zunehmend autonom erfolgen.
  • Bei autonomen Abläufen dieser Art müssen Maschinen möglicherweise eine Zusammenarbeit mit Humanressourcen eingehen sowie Partnerschaften mit anderen Maschinennetzen aushandeln. Dadurch können gemeinsame Ziele erreicht, eine abgestimmte Dienstübermittlung in Abhängigkeit von entworfenen, geplanten Service Level Agreements ermöglicht sowie Lösungen erzielt werden, die Zählungen, Messungen sowie Rückführbarkeit und Nachverfolgbarkeit ermöglichen. Der Aufbau neuer Lieferkettenstrukturen und -verfahren kann ermöglichen, dass zahlreiche Dienste aufgebaut, gewinnbringend ausgewertet und ohne menschlichen Eingriff wieder abgebaut werden.
  • Die IoT-Netze können noch weiter optimiert werden, indem in die autonomen Organisationen Sensortechnologien wie Schallaufnehmer, Lichtsensoren, eine elektronische Verkehrs-, Gesichts- und Mustererkennung oder Geruchs- und Vibrationssensoren integriert werden. Durch die Integration von Sensorsystemen kann eine systematische und autonome Kommunikation und Koordinierung der Dienstübermittlung in Abhängigkeit von Vertragsdienstzielen, der Orchestrierung und auf der Dienstgüte (QoS) basierenden Schwarmbildungen und Ressourcenzusammenlegungen ermöglicht werden.
  • Das Mesh-Netz 206 kann durch Systeme, die Inline-Umwandlungen von Daten in Informationen durchführen, optimiert werden. Sich selbst bildende Ketten von Verarbeitungsressourcen, die ein Netz mit vielen Verbindungen umfassen, können zum Beispiel die Umwandlung von Rohdaten in Informationen effizient weitergeben. Hierdurch kann eine solche Funktionalität in einer ersten Stufe eine erste numerische Operation durchführen, danach wird das Ergebnis an eine andere Stufe übergeben, in der nächsten Stufe wird dann eine weitere numerische Operation durchgeführt und deren Ergebnis wird an wiederum eine andere Stufe übergeben. Das System kann die Möglichkeit zum Unterscheiden zwischen Assets und Ressourcen und zu ihrer jeweiligen assoziierten Verwaltung bereitstellen. Des Weiteren können die passenden Komponenten von infrastruktur- und ressourcenbasierten Vertrauenswürdigkeits- und Dienstindexen eingefügt werden, um die Datenintegrität und die Qualitätssicherung zu verbessern und eine Datenkonfidenzmetrik zu liefern.
  • Wie hierin beschrieben, kann das WLAN-Netz 208 Systeme nutzen, die Umwandlungen von Standards durchführen, um eine Multi-Standard-Konnektivität bereitzustellen, sodass die IoT-Einrichtungen 104 unterschiedliche Protokolle zur Kommunikation nutzen können. Weitere Systeme können eine nahtlose Interkonnektivität in einer sichtbare Internetressourcen sowie verborgene Internetressourcen umfassenden Multi-Standard-Infrastruktur bereitstellen.
  • Die Kommunikationen im Mobilfunknetz 210 lassen sich durch Systeme, die Daten verlagern und/oder Kommunikationen auch mit weiter entfernten Einrichtungen ermöglichen, noch optimieren. Das LPWA-Netz 212 enthält möglicherweise Systeme zum Durchführen von Nicht-Internetprotokoll(IP)-IP-Zusammenschaltungen, Adressierungen und Routings.
  • 3 ist eine Darstellung 300 eines Cloud-Computing-Netzes bzw. einer Cloud 302 in Kommunikation mit einigen Internet-of-Things(IoT)-Einrichtungen gemäß manchen Ausführungsformen. Die Cloud 302 kann für das Internet stehen oder ist möglicherweise ein Local Area Network oder ein Wide Area Network (WAN), etwa ein in sich geschlossenes Netz für ein Unternehmen. Die IoT-Einrichtungen können beliebig viele, unterschiedliche Arten von Einrichtungen enthalten, die in verschiedenen Kombinationen gruppiert sind. Eine Verkehrsmanagementgruppe 306 kann zum Beispiel IoT-Einrichtungen entlang der Straßen in einer Stadt enthalten. Diese IoT-Einrichtungen enthalten möglicherweise Lichtzeichenanlagen, Verkehrsflussüberwachungseinrichtungen, Kameras, Wetterfühler und dergleichen. Die Verkehrsmanagementgruppe 306 oder andere Untergruppen können mit der Cloud 302 über kabellose Verbindungen 308 wie LPWA-Verbindungen und dergleichen kommunizieren. Ferner kann durch ein kabelgebundenes oder kabelloses Subnetz 312 ermöglicht werden, dass die IoT-Einrichtungen etwa über ein Local Area Network, ein Wireless Local Area Network und dergleichen miteinander kommunizieren. Die IoT-Einrichtungen können noch andere Einrichtungen, etwa ein Gateway 310, zum Kommunizieren mit der Cloud 302 nutzen.
  • Weitere Gruppen von IoT-Einrichtungen enthalten möglicherweise entfernte Wetterstationen 314, lokale Infoterminals 316, Alarmanlagen 318, Geldautomaten 320, Alarmtafeln 322 oder fahrende Fahrzeuge wie Einsatzfahrzeuge 324 oder sonstige Fahrzeuge 326 und viele andere mehr. Jede dieser IoT-Einrichtungen kann mit anderen IoT-Einrichtungen und/oder mit Servern 304 kommunizieren.
  • Wie aus 3 hervorgeht, kommunizieren möglicherweise zahlreiche IoT-Einrichtungen über die Cloud 302. Hierbei können unterschiedliche IoT-Einrichtungen Informationen autonom anfordern oder für andere Einrichtungen bereitstellen. Die Verkehrsmanagementgruppe 306 fordert zum Beispiel möglicherweise eine aktuelle Wettervorhersage von einer Gruppe entfernter Wetterstationen 314 an, die die Vorhersage ohne menschlichen Eingriff bereitstellen können. Ferner wird einem Einsatzfahrzeug 324 möglicherweise von einem Geldautomaten 320 mitgeteilt, dass gerade ein Einbruchdiebstahl begangen wird. Während sich das Einsatzfahrzeug 324 auf den Geldautomaten 320 zubewegt, kann es auf die Verkehrsmanagementgruppe 306 zugreifen und den freien Zugang zu der Stelle anfordern, wozu zum Beispiel Verkehrsampeln auf Rot geschaltet werden, um den Querverkehr an einer Kreuzung rechtzeitig zu stoppen, damit das Einsatzfahrzeug 324 ungehinderten Zugang zur Kreuzung hat.
  • Cluster von IoT-Einrichtungen wie die entfernten Wetterstationen 314 oder die Verkehrsmanagementgruppe 306 können so ausgestattet sein, dass sie mit anderen IoT-Einrichtungen sowie mit der Cloud 302 kommunizieren können. Dadurch können die IoT-Einrichtungen ein Ad-hoc-Netz zwischen den Einrichtungen bilden, sodass diese je als einzelne Einrichtung betrieben werden, wofür die Bezeichnung Fog-Einrichtung verwendet werden kann. Auf die Fog-Einrichtung wird mit Bezug zu 4 noch näher eingegangen.
  • 4 ist eine Darstellung 400 eines Cloud-Computing-Netzes bzw. einer Cloud 302 in Kommunikation mit einem Mesh-Netz von IoT-Einrichtungen, das als Fog-Einrichtung 402 bezeichnet werden kann und am Rand der Cloud 302 betrieben wird, gemäß manchen Ausführungsformen. Elemente, die mit selben Bezugszeichen versehen sind, entsprechen den mit Bezug zu 3 beschriebenen Elementen. Wie hierin genutzt, ist eine Fog-Einrichtung 402 ein Cluster von Einrichtungen, die für die Durchführung einer speziellen Funktion, etwa zum Verkehrsmanagement, zur Wetterüberwachung, für eine Anlagensteuerung und dergleichen, gruppiert sein können.
  • In diesem Beispiel enthält die Fog-Einrichtung 402 eine Gruppe von IoT-Einrichtungen an einer Verkehrskreuzung. Die Fog-Einrichtung 402 kann unter anderem gemäß vom OpenFog Consortium (OFC) herausgegebenen Spezifikationen hergestellt werden. Diese Spezifikationen ermöglichen die Bildung einer Hierarchie von Computerelementen zwischen den Gateways 310, die die Fog-Einrichtung 402 an die Cloud 302 und an Endpunkteinrichtungen, in diesem Beispiel Verkehrsampeln 404 und Datenaggregatoren 406, koppeln. Die Fog-Einrichtung 402 kann die von der Gruppierung von IoT-Einrichtungen bereitgestellten, kombinierten Verarbeitungs- und Netzressourcen wirksam einsetzen. Dementsprechend kann eine Fog-Einrichtung 402 für beliebig viele Anwendungen genutzt werden, zum Beispiel für die Erstellung von Finanzmodellen, Wettervorhersagen, seismische Messungen, Verkehrsanalysen, die Sicherheitsüberwachung und dergleichen.
  • Der Verkehrsfluss an der Kreuzung lässt sich zum Beispiel durch eine Vielzahl von Verkehrsampeln 404 (z. B. drei Verkehrsampeln 404) steuern. Eine Analyse des Verkehrsflusses sowie Steuerungsschemata können durch mit den Verkehrsampeln 404 sowie untereinander über ein Mesh-Netz kommunizierende Aggregatoren 406 implementiert werden. In die Cloud 302 können Daten, außerdem aus der Cloud 302 empfangene Befehle, über Gateways 310, die über das Mesh-Netz mit den Verkehrsampeln 404 und den Aggregatoren 406 kommunizieren, hochgeladen werden.
  • In der Fog-Einrichtung 402 können beliebig viele Kommunikationsverbindungen genutzt werden. Kurzstreckenverbindungen 408, die zum Beispiel mit IEEE 802.15.4 kompatibel sind, können lokale Kommunikationen zwischen IoT-Einrichtungen in der Nähe der Kreuzung bereitstellen. Langstreckenverbindungen 410, die zum Beispiel mit LPWA-Standards kompatibel sind, können Kommunikationen zwischen den IoT-Einrichtungen und den Gateways 310 bereitstellen. Zur Vereinfachung der Darstellung ist nicht jede Kommunikationsverbindung 408 bzw. 410 mit einem Bezugszeichen versehen.
  • Die Fog-Einrichtung 402 kann als ein Netz mit hochgradiger Vernetzung angesehen werden, in dem etliche IoT-Einrichtungen zum Beispiel über die Kommunikationsverbindungen 408 und 410 miteinander kommunizieren. Das Netz kann gemäß der von der Open Connectivity Foundation™ (OCF) am 23. Dezember 2015 herausgegebenen Open-Interconnect-Consortium(OIC)-Standard-Spezifikation 1.0 hergestellt werden. Dieser Standard ermöglicht, dass Einrichtungen einander erkennen und Kommunikationen zur Vernetzung aufbauen. Es können auch noch andere Vernetzungs- und Operabilitätsprotokolle genutzt werden, zum Beispiel das 2008 von der OPC Foundation herausgegebene Open-Platform-Communications(OPC)-Unified-Architecture-Protokoll, das AllJoyn-Protokoll der Allseen Alliance, das Optimized-Link-State-Routing(OLSR)-Protokoll oder das Better-Approach-To-Mobile-Ad-Hoc-Networking(B.A.T.M.A.N.)-Protokoll und viele andere mehr.
  • In manchen Ausgestaltungen können Kommunikationen von einer IoT-Einrichtung auf dem Weg, der zum Erreichen der Gateways 310 am zweckmäßigsten ist, weitergereicht werden, zum Beispiel unter anderem auf dem Weg mit den wenigsten dazwischen liegenden Hops oder mit der höchsten Bandbreite. In diesen Netzen entsteht aufgrund der Anzahl der Verbindungen eine erhebliche Redundanz, aufgrund deren Kommunikationen aufrechterhalten werden können, sogar wenn etliche IoT-Einrichtungen ausfallen.
  • In manchen Ausgestaltungen kann die Fog-Einrichtung 402 temporäre IoT-Einrichtungen enthalten. Mit anderen Worten, es sind möglicherweise nicht alle IoT-Einrichtungen ständig in der Fog-Einrichtung 402 beteiligt. In dem beispielhaften System 400 sind zum Beispiel drei vorübergehende IoT-Einrichtungen in der Fog-Einrichtung 402 hinzugekommen, ein erstes Fahrzeug 412, ein zweites Fahrzeug 414 und ein Fußgänger 416. In diesen Fällen ist die IoT-Einrichtung möglicherweise in die Fahrzeuge 412 und 414 integriert oder eine App auf einem Smartphone, das der Fußgänger 416 bei sich führt. Es können auch noch andere IoT-Einrichtungen vorhanden sein, etwa IoT-Einrichtungen in Fahrradcomputern, Motorradcomputern, Drohnen und dergleichen.
  • Die aus den IoT-Einrichtungen gebildete Fog-Einrichtung 402 kann Clients in der Cloud 302, etwa dem Server 304, als einzelne, am Rand der Cloud 302 befindliche Einrichtung präsentiert werden. In diesem Beispiel können die Steuerungskommunikationen mit speziellen Ressourcen in der Fog-Einrichtung 402 erfolgen, ohne dass eine spezielle IoT-Einrichtung innerhalb der Fog-Einrichtung 402 identifiziert wird. Wenn eine IoT-Einrichtung innerhalb der Fog-Einrichtung 402 ausfällt, können dementsprechend andere IoT-Einrichtungen in der Fog-Einrichtung 402 eine Ressource, etwa einen Aktor oder andere Einrichtung, die an einer IoT-Einrichtung angebracht ist, erkennen und steuern. Die Verkehrsampeln 404 sind zum Beispiel möglicherweise so geschaltet, dass jeweils eine beliebige der Verkehrsampeln 404 die Lichtsignale für die anderen Verkehrsampeln 404 steuern kann. Die Aggregatoren 406 können auch eine Redundanz bei der Steuerung der Verkehrsampeln 404 sowie weitere Funktionen der Fog-Einrichtung 402 bereitstellen.
  • In manchen Beispielen sind die IoT-Einrichtungen möglicherweise mittels einer imperativen Programmierung konfiguriert, z. B. hat jede IoT-Einrichtung eine spezielle Funktion und spezielle Kommunikationspartner. Dahingegen sind die IoT-Einrichtungen, die die Fog-Einrichtung 402 bilden, möglicherweise mittels einer deklarativen Programmierung konfiguriert, sodass die IoT-Einrichtungen ihre Abläufe und Kommunikationen so rekonfigurieren können, dass in Ansprechen auf Bedingungen, Abfragen und Einrichtungsausfälle benötigte Ressourcen ermittelt werden. Dies lässt sich durchführen, wenn einstweilige IoT-Einrichtungen, etwa der Fußgänger 416, in der Fog-Einrichtung 402 hinzukommen.
  • Da sich der Fußgänger 416 wahrscheinlich langsamer als die Fahrzeuge 412 und 414 fortbewegt, kann sich die Fog-Einrichtung 402 selbst so rekonfigurieren, dass sichergestellt wird, dass dem Fußgänger 416 genügend Zeit zum Überqueren der Kreuzung bleibt. Dies kann durch Bilden einer temporären Gruppe aus den Fahrzeugen 412 und 414 und dem Fußgänger 416 zur Steuerung der Verkehrsampeln 404 durchgeführt werden. Wenn das Fahrzeug 412 und/oder das Fahrzeug 414 autonom sind/ist, kann die temporäre Gruppe die Fahrzeuge zum Bremsen vor den Verkehrsampeln 404 anweisen. Wenn alle Fahrzeuge an der Kreuzung autonom sind, sind ferner möglicherweise weniger Verkehrslichtzeichen nötig, da Kollisionsvermeidungssysteme autonomer Fahrzeuge für sehr vielschichtige Verkehrssituationen ausgelegt sein können, welche möglicherweise zu komplex sind, als dass Verkehrsampeln damit umgehen könnten. Verkehrsampeln 404 können jedoch dennoch wichtig für den Fußgänger 416, Radfahrer oder nicht autonome Fahrzeuge sein.
  • Sobald sich die einstweiligen Einrichtungen 412, 414 und 416 aus dem Umfeld der Kreuzung der Fog-Einrichtung 402 wegbewegen, kann sich die Fog-Einrichtung 402 selbst so rekonfigurieren, dass diese IoT-Einrichtungen aus dem Netz entfernt werden. Sobald sich andere vorübergehende IoT-Einrichtungen der Kreuzung nähern, kann sich die Fog-Einrichtung 402 selbst so rekonfigurieren, dass diese Einrichtungen in ihm aufgenommen werden.
  • Die Fog-Einrichtung 402 kann die Verkehrsampeln 404 für eine Anzahl von Kreuzungen, etwa entlang einer Straße, sowie alle einstweiligen IoT-Einrichtungen entlang der Straße enthalten. Die Fog-Einrichtung 402 kann sich dann in Funktionseinheiten wie die Verkehrsampeln 404 sowie weitere IoT-Einrichtungen in der Nähe einer einzelnen Kreuzung aufteilen. Eine derartige Kombination kann die Bildung größerer IoT-Konstrukte, z. B. von Gruppen von IoT-Einrichtungen, die eine bestimmte Funktion durchführen, in der Fog-Einrichtung 402 ermöglichen.
  • Wenn zum Beispiel ein Einsatzfahrzeug in der Fog-Einrichtung 402 hinzukommt, kann ein Notfallkonstrukt oder eine virtuelle Einrichtung erzeugt werden, das bzw. die alle Verkehrsampeln 404 für die Straße enthält, sodass sich die Verkehrsflussmuster für die ganze Straße steuern lassen. Das Notfallkonstrukt kann die Verkehrsampeln 404 entlang der Straße dazu anweisen, dass sie für den Gegenverkehr rot und für das Einsatzfahrzeug grün bleiben, sodass die Durchfahrt des Einsatzfahrzeugs schneller erfolgen kann.
  • Wie durch die Fog-Einrichtung 402 veranschaulicht, ist die organische Weiterentwicklung von IoT-Netzen wesentlich für die Verbesserung und Maximierung des Nutzens, der Verfügbarkeit und der Robustheit von IoT-Implementierungen. Ferner verdeutlicht das Beispiel die Zweckmäßigkeit von Strategien zur Verbesserung der Vertrauenswürdigkeit und folglich der Sicherheit. Die lokale Identifizierung von Einrichtungen kann bei Implementierungen wichtig sein, da die Dezentralisierung der Identität sicherstellt, dass keine zentrale Stelle dazu ausgenutzt werden kann, einen Wechsel der Identität von Objekten, die innerhalb der IoT-Netze vorhanden sein können, zu erlauben. Außerdem sind bei einer lokalen Identifizierung der Kommunikations-Overhead und die Kommunikationslatenz geringer.
  • In einer Multi-Access-Edge-Computing(MEC)-Umgebung können Netze von Einrichtungen bereitgestellt werden. Multi-Access Edge Computing (MEC), auch Mobile Edge Computing genannt, kann Anwendungsentwicklern und Contentprovidern Cloud-Computing-Fähigkeiten und eine IT-Service-Umgebung am Rand eines Netzes bieten. Ein MEC-System kann einen MEC-Orchestrator und einen MEC-Plattform-Manager enthalten, die für die Bereitstellung eines Dienstes für ein Benutzerendgerät (UE) durch einen Serviceprovider, einen oder mehrere Zugangspunkte oder einen oder mehrere MEC-Hosts zuständig sind.
  • Die MEC-Umgebung ist möglicherweise Teil eines Funkzugangsnetzes (RAN), das für externe Provider wie Clearing-Häuser für Blockchain-Transaktionen geöffnet worden ist. Das RAN kann ein System mit hoher Bandbreite und geringer Latenz bereitstellen, durch das Fog-Einrichtungen 402 zusammen mit Anwendungen und Diensten in der Cloud 302 effizienter arbeiten können. Dementsprechend kann das MEC 302 als eine Cloud oder ein Fog-Server angesehen werden, die bzw. der am Rand eines Mobilfunknetzes betrieben wird und Aufgaben, die mittels einer herkömmlichen Netzinfrastruktur nicht erfüllt werden können, durchführt. Machine-to-Machine-Gateway- und -Steuerungsfunktionen wie die mit Bezug zu 3 und 4 beschriebenen beispielhaften IoT-Einrichtungen sind nur ein Beispiel. In einem MEC-Netz wird die Rechenleistung, etwa Server, näher zum Netzrand hin verlagert. Zum Beispiel die Aggregatoren 406, die sich innerhalb der Fog-Einrichtung 402 befinden.
  • 5 veranschaulicht ein System 500 gemäß manchen Ausführungsformen. Das System 500 kann in manchen Ausführungsformen zum Beispiel ein IoT-System (zum Beispiel ein IoT-System, etwa ein Fog-Knoten-System) sein. Das System 500 kann eine oder mehrere IoT-Einrichtungen enthalten. Ein beispielhaftes IoT-System 500 kann zum Beispiel eine erste Gruppe variabler Endknoteneinrichtungen 502, eine zweite Gruppe variabler Endknoteneinrichtungen 504 und eine dritte Gruppe variabler Endknoteneinrichtungen 504 enthalten. In manchen Ausführungsformen können eine oder mehrere (oder alle) der Einrichtungen in der ersten Gruppe variabler Endknoteneinrichtungen 502, in der zweiten Gruppe variabler Endknoteneinrichtungen 504 und/oder in der dritten Gruppe variabler Endknoteneinrichtungen 504 IoT-Einrichtungen sein. Das beispielhafte IoT-System 500 kann auch ein erstes Übertragungsmedium 512, ein zweites Übertragungsmedium 514 und ein drittes Übertragungsmedium 516 enthalten. In manchen Ausführungsformen können das erste Übertragungsmedium 512, das zweite Übertragungsmedium 514 und das dritte Übertragungsmedium 516 Informationen zum Beispiel drahtlos übertragen. In manchen Ausführungsformen sind das erste Übertragungsmedium 512, das zweite Übertragungsmedium 514 und das dritte Übertragungsmedium 516 möglicherweise variable Medien mit verlustbehafteten Übertragungen mit variabler Bandbreite und variabler Latenz (oder variable Netze mit verlustbehafteten Übertragungen mit variabler Bandbreite und variabler Latenz). In manchen Ausführungsformen kann das erste Übertragungsmedium 512 ein oder mehrere mobile Ad-hoc-Netze sein. In manchen Ausführungsformen kann das zweite Übertragungsmedium 514 ein oder mehrere Mobilfunknetze sein. In manchen Ausführungsformen kann das dritte Übertragungsmedium 516 ein oder mehrere WiFi-Netze sein. In manchen Ausführungsformen kann das System 500 ein Remote-Radio-Head(RRH)-Netz-Gateway 520 oder ein Gateway von einem beliebigen anderen Typ enthalten. In manchen Ausführungsformen kann das Gateway 520 eine IoT-Einrichtung sein. In manchen Ausführungsformen kann das erste Übertragungsmedium 512 Informationen zwischen der ersten Gruppe variabler Endknoteneinrichtungen 502 und dem Remote-Radio-Head-Netz-Gateway 520 übertragen. In manchen Ausführungsformen kann das zweite Übertragungsmedium 514 Informationen zwischen der zweiten Gruppe variabler Endknoteneinrichtungen 504 und dem Remote-Radio-Head-Netz-Gateway 520 übertragen. In manchen Ausführungsformen kann das dritte Übertragungsmedium 516 Informationen zwischen der dritten Gruppe variabler Endknoteneinrichtungen 506 und dem Remote-Radio-Head-Netz-Gateway 520 übertragen. In manchen Ausführungsformen kann das System 500 einen Fog-Knoten 530 enthalten. In manchen Ausführungsformen kann der Fog-Knoten 530 eine IoT-Einrichtung sein. In manchen Ausführungsformen kann der Fog-Knoten 530 zum Beispiel ein privates, hochverfügbares, für geringe Latenz und hohe Bandbreite ausgelegtes Rechenzentrum in einem Kasten sein. In manchen Ausführungsformen kann das System 500 ein Intranet 540 oder eine Cloud on Demand 550 oder sowohl ein Intranet 540 als auch eine Cloud on Demand 550 enthalten. In manchen Ausführungsformen können das Intranet 540 oder die Cloud on Demand 550 oder sowohl das Intranet 540 als auch die Cloud on Demand 550 eine hybride interne/externe Cloud-Einrichtung sein.
  • In manchen Ausführungsformen empfängt der Fog-Knoten 530 Teilobjektfragmente (zum Beispiel Teilbildfragmente) über ein oder mehrere Kabelnetze, ein oder mehrere kabellose Netze oder eine Kombination von kabellosen Netzen und Kabelnetzen.
  • In manchen Ausführungsformen können Netze von IoT-Einrichtungen (IoT-Netze), etwa Fog-Netze (zum Beispiel das System 500), eine heterogene Mischung aus zusammenarbeitenden Clients und Edge Devices, die kabelgebundene und/oder kabellose Kommunikationen zur Vernetzung nutzen, enthalten. Daraus kann eine dynamische Infrastruktur mit variablen Leistungseigenschaften resultieren. In manchen Ausführungsformen, um den Transport und die Speicherung komplexer Daten (zum Beispiel komplexer Daten wie großer Bilder und/oder sequenziell zusammengefasster Nutzinformationen, die über verlustbehaftete Netze mit variabler Bandbreite und variabler Latenz übertragen werden) und eine Möglichkeit zum Beheben von Fehlern zu unterstützen. In manchen Ausführungsformen kann zum Beispiel eine Datenrekombination (zum Beispiel eine Datenrekombination wie eine Rekombination komplexer Edge-Daten für Fog-Netze) mittels einer Fragmentierung und einer Rekombination von Daten implementiert werden. Dies kann mittels einer Datenfragmentierung und -rekombination von Nutzdaten beliebiger Art, die zum Beispiel eine Bildfragmentierung und -rekombination enthält, implementiert werden. In manchen Ausführungsformen können Daten wie große, zusammengefasste Daten fragmentiert, über IoT-Netze, etwa komplexe Fog-Netze, transportiert und an einem oder mehreren Zielpunkten rekombiniert werden. In manchen Ausführungsformen kann eine Erfassung großer Dateien (zum Beispiel eine Erfassung großer Bilddateien) über dynamische, beschränkte kabellose Netze oder Kabelnetze oder eine Kombination von kabellosen Netzen und Kabelnetzen implementiert werden.
  • Manche Ausführungsformen beziehen sich auf Fog-Netze, die komplexe Systeme sind, zum Beispiel mit vielen Knoten können sich durch das Hinzufügen, Entfernen und/oder Erweitern von Knoten etc. dynamisch ändern, wenn viele Parteien daran mitwirken, dass Daten von der Quelle zum Sync gelangen. Die Datenübertragungswege zwischen der Quelle und dem Sync können gemäß diversen Übertragungsmodi gesendet werden, etwa gemäß Protokollen für die drahtlose Übertragung wie LoRaWAN oder WiFi, über Mobilfunk etc. und/oder gemäß Protokollen für die Kabelübertragung, etwa über Ethernet, etc.
  • In manchen Ausführungsformen können eine Datenfragmentierung und eine Datenrekombination derart implementiert werden, dass dabei eine Echtzeitrückmeldung einer Datenkonstruktion (zum Beispiel einer Bildkonstruktion) bereitgestellt wird. In manchen Ausführungsformen kann die Lebensdauer (Time To Live, TTL) großer Datendateien, etwa von Bilddateien, verwaltet werden, und für Szenarios in der realen Welt, in denen die Datendateien (oder Teile der Datendateien) nie ankommen werden, können konfigurierbare Toleranzen erlaubt werden. In manchen Ausführungsformen kann ein probabilistisches Modell für optimale Endknotenübertragungszeitpunkte und -übertragungsdauern generiert werden. Folglich können genaue Knotenplatzierungsmodelle für den Einsatz in der realen Welt bereitgestellt werden. In manchen Ausführungsformen kann eine adaptive Datenrate implementiert werden, wobei die Datenratenübertragung (zum Beispiel die Bilddatenratenübertragung) basierend auf diversen Umgebungsfaktoren (zum Beispiel Reflektoren, Störern etc.) dynamisch geändert werden kann.
  • In manchen Ausführungsformen kann sowohl für Datenpakete, die in einer Reihenfolge empfangen werden, als auch für Datenpakete, die nicht sequenziell empfangen werden, eine Auto-Sequenzialisierung von Paketen implementiert werden. In manchen Ausführungsformen können fehlende Pakete detektiert und neu angefordert werden. In manchen Ausführungsformen können Datenfragmente in einer Datenspeichereinrichtung gespeichert werden. In manchen Ausführungsformen können Datenpaketfragmente zu einer Rekonstruktion ursprünglicher Nutzdaten rekombiniert werden.
  • Wie hierin erörtert, kann ein System wie das System 500 zur Übertragung fragmentierter Daten genutzt werden, und es können Teilbildfragmente über ein oder mehrere kabellose Netze, ein oder mehrere Kabelnetze oder eine Kombination von Kabelnetzen und kabellosen Netzen (zum Beispiel an einem Fog-Knoten) empfangen werden.
  • In manchen Ausführungsformen ist eine Datenfragmentierungsnutzlasteinbettung implementiert. Zum Beispiel ist in manchen Ausführungsformen eine Bildfragmentierungsnutzlasteinbettung implementiert. In manchen Ausführungsformen enthält eine Bildfragmentierungsnutzlast Elemente oder Felder, die eines oder mehrere der folgenden Elemente enthalten: ein Format, eine Kennung, eine ID, eine ganze Zahl, die einen Teil des Bilds beschreibt, einen Zeitstempel, eine Bildlänge oder einen Anteil des Bilds. Ein derartiges Beispiel für eine Datenfragmenteinbettung, in dem die Daten ein oder mehrere Bilder sind und jedes dieser Felder enthalten ist, ist in Bezug auf Tabelle 1 veranschaulicht. Tabelle 1 veranschaulicht ein Beispiel für eine Teilbildnutzdatennachricht unter Nutzung einer Bildfragmenteinbettung.
  • Tabelle 1:
    {
    „format“: „PNG“,
    „uuid“: „40bac717-196c-11e4-9e9d-984fee001448“,
    „imageid“: „imageid“,
    „sectid“: 1,
    „ts“: 1459706857659,
    „imglen“: 1,
    „imgStr“:“iVBORwOKGgoAAAANSUhEUgAAABAAAAAQAQ
    MAAAAIPWOiAABIBMVEUAAAD///+“
    }
  • In Tabelle 1 enthalten die Felder ein Format (Zeichenfolge) „format“, bei dem es sich um ein Format des Typs der komplexen Daten handelt (zum Beispiel könnte das Format im Fall eines Bilds jpg, bmp, jpeg, wbmp, png, gif, tiff etc. sein). Ein weiteres Feld in Tabelle 1 ist eine uuid (Zeichenfolge) „uuid“, bei der es sich um eine Kennung des Absender-Edge-Knotens handelt, wobei die Kennung für das System eindeutig ist. Ein drittes Feld in Tabelle 1 ist eine ID „imageid“ (Zeichenfolge) des Bilds. Die „imageid“ soll für jedes uuid-Feld eindeutig sein. Aus der uuid und der imageid ergibt sich eine eindeutige Kennung für ein Bild. Das vierte Feld in Tabelle 1 ist „sectid“, eine ganze Zahl (zum Beispiel zwischen 0 und N), die einen Teil des Bilds beschreibt. Jeder der Bildteile kann zum Beispiel ein Fragment des Bildobjekts sein. Das fünfte Feld in Tabelle 1 ist das Feld „ts“, bei dem es sich um einen Zeitstempel (z. B. einen Unix-Epoch-Zeitstempel) der Aufzeichnung des Bildteils handelt. Das sechste Feld in Tabelle 1 ist „imglen“ (image length, Bildlänge), das die Anzahl der das vollständige Bild umfassenden Fragmente identifiziert. Das heißt, imglen (bzw. die Bildlänge) identifiziert, wie viele Teilabschnitte oder Fragmente (oder Ganzzahlen 0 bis N) insgesamt in imageid enthalten sind. Es wird angemerkt, dass sich imglen (die Bildlänge) in manchen Ausführungsformen (zum Beispiel bei kabellosen Netzen) im Verlauf der Übertragung ändern kann. Das sechste Feld in Tabelle 1 ist „imgstr“ (image string), das den Fragmentdatenanteil (zum Beispiel den Teil des Bilds) identifiziert. Dieses Feld kann (zum Beispiel über die Base64-Codierung) codiert sein.
  • Wie hierin beschrieben, kann eine Fragmentrekombination gemäß manchen Ausführungsformen implementiert werden. In manchen Ausführungsformen kann eine leichtgewichtige, zustandslose Architektur mit einer hochparallelen, verteilten, robusten, nachrichtenbasierten und skalierbaren Lösung genutzt werden. Hierdurch lässt sich leichter ein vorhersagbarer Mindestressourcenverbrauch gemäß manchen Ausführungsformen sicherstellen. In manchen Ausführungsformen kann eine nicht blockierende Kommunikation Empfängern den Verbrauch von Ressourcen immer nur dann erlauben, wenn sie aktiv sind, und kann den System-Overhead reduzieren. In manchen der Ausführungsformen hierin geht es zwar um eine Bildfragmentierung und eine Bildrekombination, jedoch gibt es noch andere Ausführungsformen, die sich auf andere Datenfragmentierungs- und Datenrekombinationsimplementierungen beziehen. Manche Ausführungsformen beziehen sich zum Beispiel auf ein beliebiges Datenformat. Manche Ausführungsformen lassen sich zum Beispiel im Zusammenhang mit vielen unterschiedlichen binären und nichtbinären Formaten implementieren.
  • In manchen Ausführungsformen wird eine Datenrekombination implementiert, bei der einem oder mehreren Empfängerknoten ein Anfang in einem empfangenen Strom ein Byte oder eine Gruppe von Bytes (zum Beispiel in einem Datenfragment), das/die einen Anfang darstellt, bekannt ist. Es sind Veröffentlichungen durch mehrere Clients gegenüber dem Empfängerendpunkt (bzw. dem Empfängerknoten) möglich. Durch den Empfängerknoten kann von einem anderen Endpunkt auch ein anderes Objekt (in manchen Ausführungsformen zum Beispiel ein anderes Bild) empfangen werden. Jeder Teil (bzw. jedes Paket mit Informationen) hat eine eindeutige Kennung (zum Beispiel je eine andere imageid). Die eindeutige Kennung kann mit einem bestimmten Datenobjekt (zum Beispiel einem bestimmten Bild) assoziiert sein. Jedes Datenobjekt kann sich aus Datenteilobjekten, die in einer beliebigen Reihenfolge empfangen werden können, zusammensetzen. Ein Objekt ist vollständig, sobald alle Teile empfangen worden sind. In manchen Ausführungsformen (in denen zum Beispiel ein Übertragungsmedium wie LoRaWAN genutzt wird) könnte es lange (zum Beispiel 12 Stunden) dauern, bis das Datenobjekt gesendet und empfangen worden ist.
  • In manchen Ausführungsformen kann eine Verwaltung von nicht in einer Reihenfolge empfangenen Fragmenten implementiert sein. In manchen Ausführungsformen kann eine Lebensdauer (Time To Live, TTL) zur Ressourcenverwaltung genutzt werden. Wenn nicht alle Teilkomponenten innerhalb einer bestimmten Zeit empfangen werden, kann ein Prozess, bei dem auf alle Fragmente gewartet wird, gekillt werden. Unter diesen Gegebenheiten können Teilkomponenten nicht an der Stelle, an der die vollständigen Objekte gespeichert werden, sondern in einer anderen Speichereinrichtung (oder an einem anderen Speicherort innerhalb derselben Einrichtung) gespeichert werden. Wenn alle Teile eines Objekts angekommen sind, können sie sortiert werden, sodass sie in der richtigen Reihenfolge sind. Damit ein Objekt wie ein Bild sichtbar und klar ist, kann für jedes einzelne Bild eine Markierung in der Liste gespeichert werden.
  • In manchen Ausführungsformen können mehrere Knoten (zum Beispiel mehrere Endknoten oder mehrere IoT-Einrichtungen) Bilder (oder andere Daten) übertragen und diese hierfür zum Beispiel unter Nutzung einer eindeutigen uuid und einer eindeutigen imageid in Teile (oder Fragmente) aufteilen. Diese Teile (oder Fragmente) können nicht in einer Reihenfolge ankommen und enthalten möglicherweise Duplikate. Ein Empfängerknoten (zum Beispiel ein Gateway, ein Fog-Knoten oder eine andere IoT-Einrichtung) kann den Empfang der Fragmente bestätigen. Wenn bisher keine imageid vorgelegen hat, kann ein Aktor (oder ein Agent) erzeugt und das Fragment zu einer Liste von Fragmenten für dieses Bild (oder andere Nutzdaten) hinzugefügt werden. Es kann eine Liste von Aktoren (oder Agenten) mit einer eindeutig identifizierbaren (zum Beispiel anhand der uuid-imageid-Kombination eindeutig identifizierbaren) Eins-zu-eins-Beziehung geführt werden. Wenn Fragmente ankommen, können sie zur relevanten Fragmentliste von Aktoren (oder Agenten) hinzugefügt werden, und Duplikate können ignoriert werden (zum Beispiel indem sie nicht zweimal hinzugefügt werden). Jedes Fragment kann beschreiben, wie viele Fragmente insgesamt für die Zusammensetzung der Nutzdaten nötig sind (zum Beispiel wie viele Fragmente insgesamt für die Zusammensetzung des Bilds nötig sind). In manchen Ausführungsformen kann sich diese Gesamtzahl der Fragmente wieder ändern, nachdem das erste Fragment empfangen worden ist und bevor das letzte Fragment für spezielle Nutzdaten empfangen wird (zum Beispiel für ein spezielles Bild). In manchen Ausführungsformen kann eine ständige Prüfung implementiert sein, um festzustellen, ob alle erwarteten Teile (zum Beispiel alle erwarteten Fragmente) angekommen sind.
  • In manchen Ausführungsformen kann eine Zeitreihendatenbank genutzt werden. Die Zeitreihendatenbank kann Daten zur Performance beim Zusammensetzen der Nutzdaten (zum Beispiel beim Zusammensetzen des Bilds) aufzeichnen. In manchen Ausführungsformen können die aufgezeichneten Performance-Daten zum Beispiel zur Platzierung von Knoten, etwa von Endknoten, genutzt werden. Wenn alle Fragmente (Teile) angekommen sind, können sie als Nächstes sortiert und (zum Beispiel in einer Speichereinrichtung wie einer permanenten Datenbank zur Speicherung der gesamten Nutzdaten) abgelegt werden. Wenn nicht alle Fragmente (Teile) innerhalb eines bestimmten Zeitraums angekommen sind, kann der Fehler aufgezeichnet und der empfangene Fragmente enthaltende Nutzdatenteil gespeichert, ein Versuch zum Korrigieren der Nutzdaten (bzw. des Bilds) implementiert und/oder eine erneute Übertragung angefordert werden.
  • In manchen Ausführungsformen können Daten an Endknoten (oder Endpunkteinrichtungen), zum Beispiel an beliebigen der Endpunkteinrichtungen in 4 oder in Gruppen 502, 504 oder 506 gemäß 5, oder an einem Aggregator, zum Beispiel an einem beliebigen der Aggregatoren 406 gemäß 4, fragmentiert werden. Danach können die Fragmente an eine oder mehrere andere Einrichtungen, in denen die Fragmente rekombiniert werden, zum Beispiel an das Gateway 520, den Fog-Knoten 530, das Intranet 540 oder die Cloud on Demand 550 gemäß 5 oder an eine andere Einrichtung innerhalb der Fog-Einrichtung 402 gemäß 4, zum Beispiel an das Gateway 310, die Cloud 302 oder den Server 304 gemäß 3 oder 4, gesendet werden. In manchen Ausführungsformen kann eine Datenrekombination an einem Aggregator, einem Gateway oder einem Fog-Knoten implementiert werden. In manchen Ausführungsformen kann eine Datenrekombination, wie hierin beschrieben und/oder veranschaulicht, an einem beliebigen Knoten in einem Netz (zum Beispiel an einem beliebigen Knoten in einem IoT-Netz) implementiert werden. In manchen Ausführungsformen kann eine Datenrekombination an zwei oder mehr unterschiedlichen Knoten implementiert werden. Zum Beispiel kann eine Datenrekombination in manchen Ausführungsformen zum Teil an einem Knoten und zum Teil an einem anderen Knoten oder mehreren anderen Knoten implementiert werden. In manchen Ausführungsformen kann eine Datenrekombination zum Beispiel an unterschiedlichen Knoten parallel implementiert werden (wenn die Informationen zum Beispiel über unterschiedliche Knoten parallel übertragen werden). In manchen Ausführungsformen ist ein Übertragungsweg in einem Netz zum Beispiel möglicherweise ein im Vergleich zu einem anderen Übertragungsweg schnellerer Übertragungsweg, und auf dem schnelleren Übertragungsweg können Fragmentierungen und Paketübermittlungen möglicherweise viel schneller erfolgen als auf dem anderen Übertragungsweg, bei dem es sich um einen Übertragungsweg handeln kann, der möglicherweise verlustbehafteter ist. In manchen Ausführungsformen können eine Datenfragmentierung und eine Datenrekombination so implementiert werden, dass die Performance hierbei basierend auf den Verbindungseigenschaften höher oder geringer ist. Das heißt, in manchen Ausführungsformen kann das Netz basierend auf den Übertragungseigenschaften der Übertragungswege zwischen den Knoten strategisch ermitteln, wo die Datenfragmente aufzuteilen und wo die Fragmente zu rekombinieren sind.
  • Es wird darauf hingewiesen, dass sich in manchen Ausführungsformen (zum Beispiel in manchen Ausführungsformen mit kabelloser Übertragung) die Objektlänge (bzw. die Anzahl der Fragmente) im Verlauf der Übertragung ändern kann. In manchen Ausführungsformen erfolgt zum Beispiel möglicherweise eine dynamische Anpassung der Nutzdatengröße und der Anzahl der Fragmente (zum Beispiel im Fall von Bilddaten, wenn etwas die Bildaufnahme behindert). Zum Beispiel könnten große Pakete gesendet werden, wenn die Bedingungen gut sind, und es könnten kleinere Pakete gesendet werden, wenn die Bedingungen nicht gut sind. Mit dem Senden der Nutzdaten könnten sich die Bedingungen ändern oder Probleme bei der Übertragung auftreten, die Fragmentgröße könnte dynamisch reduziert und die Anzahl der Fragmente erhöht werden (zum Beispiel indem sectid und/oder imglen in Tabelle 1 für eine bestimmte uuid-imageid-Kombination dynamisch angepasst werden). Dies lässt sich zum Beispiel implementieren, indem Pakete verworfen oder mehrere Wiederholungsversuche erfolgen. Zum Beispiel kann eine Out-of-Band- oder In-Band-Steuernachricht an den Endpunkt zurückgesendet werden, wo die Pakete fragmentiert werden und anzeigen, dass die Bedingungen nicht ideal sind und kleinere Fragmente genutzt werden sollten. Dies lässt sich dynamisch implementieren, ohne erneut von vorne beginnen zu müssen, indem das ganze Objekt fragmentiert wird. Übrige Abschnitte (zum Beispiel nicht empfangene Fragmente) des Objekts können in manchen Ausführungsformen erneut fragmentiert werden. In manchen Ausführungsformen kann die Anzahl der Fragmente erhöht werden (während hingegen die Fragmente verkleinert werden), und in manchen Ausführungsformen kann die Anzahl der Fragmente verringert werden (während hingegen die Fragmente vergrößert werden). In manchen Ausführungsformen kann die dynamische Anpassung der Anzahl der Fragmente und/oder der Größe der Fragmente zum Beispiel zwischen einem Knoten, an dem die Fragmentierung erfolgt, und einer Stelle, an der die Rekombination erfolgt, implementiert werden.
  • In manchen Ausführungsformen hat ein Aktor (oder ein Agent) eine eindeutige Eins-zu-eins-Beziehung zu jeder imageid. Wenn die imageid nach dem Empfang nicht in einer Liste von Aktoren vorhanden ist, wird ein neuer Aktor für die neue imageid erzeugt, um das betreffende Bild (oder in manchen Ausführungsformen andere Nutzdaten anstelle eines Bilds) zu bearbeiten. In manchen Ausführungsformen bleibt der Aktor so lange im Hauptspeicher, bis alle Teile (oder Fragmente) des Bilds empfangen worden sind oder bis eine Lebensdauer (Time To Live, TTL) abgelaufen ist. In manchen Ausführungsformen wird der Aktor vorübergehend gespeichert (zum Beispiel vorübergehend in einem permanenten Speicher, etwa auf einer Platte, gespeichert) und im Hauptspeicher wiederhergestellt, sobald ein neues Fragment ankommt. Daher ist es unerheblich, welches Fragment zu einem bestimmten Zeitpunkt empfangen wird oder wann es empfangen wird. Die Anzahl der Teile (oder Fragmente) ist dynamisch anpassbar, und es kann eine Anpassung bei der Ermittlung, ob alle Teile empfangen worden sind, basierend auf den dynamischen Anpassungen (zum Beispiel über die Teilnummer oder sectid für bestimmte Nutzdaten sowie die Länge oder imglen) ermittelt werden. Sobald ermittelt worden ist, dass alle Fragmente empfangen worden sind, können alle Fragmente zusammengestellt und richtig angeordnet werden. In manchen Ausführungsformen können abwechselnd jeweils mehr oder weniger Pakete (Fragmente) vorhanden sein, und der Empfängerknoten kann entsprechend reagieren. In manchen Ausführungsformen ermittelt der Empfängerknoten mittels der verschiedenen empfangenen Fragmente die endgültige Zahl der notwendigen Pakete und entscheidet, ob alle Pakete empfangen worden sind, basierend auf den empfangenen Fragmenten und der empfangenen Länge, die die nötige Anzahl von Paketen für die jeweiligen Nutzdaten (zum Beispiel basierend auf dem Feld imglen bzw. der Bildlänge) identifiziert.
  • 6 veranschaulicht eine Datenfragmentierung und -rekombination 600 gemäß manchen Ausführungsformen. In manchen Ausführungsformen kann die Datenfragmentierung zum Beispiel in einem Endknoten implementiert werden, wie in 6 veranschaulicht. In manchen Ausführungsformen kann die Datenrekombination zum Beispiel in einem Fog-Knoten implementiert werden, wie in 6 veranschaulicht. In manchen Ausführungsformen kann die Datenfragmentierung hingegen statt in Endknoten auch in anderen Einrichtungen (statt in Endknoten zum Beispiel in anderen IoT-Einrichtungen) implementiert werden. Analog dazu kann die Datenrekombination in manchen Ausführungsformen statt in Fog-Knoten auch in anderen Einrichtungen (statt in Fog-Knoten zum Beispiel in anderen IoT-Einrichtungen) implementiert werden.
  • Die Datenfragmentierung und -rekombination 600 beginnt am Anfang 602. Bei 604 wird ermittelt, ob ein oder mehrere Endknoten (oder statt eines Endknotens irgendeine andere Einrichtung) ein neues Objekt erhalten haben. In manchen Ausführungsformen kann das neue Objekt zum Beispiel ein durch eine Kamera (zum Beispiel an einem Endknoten) aufgenommenes Bild sein. In manchen Ausführungsformen kann das neue Objekt zum Beispiel Daten, Nutzdaten und/oder ein Bild etc. sein. Wenn bei 604 kein neues Objekt erhalten worden ist, wird bei dem Ablauf so lange bei 604 geblieben, bis ein neues Objekt erhalten worden ist. Wenn bei 604 ein neues Objekt erhalten wird, formatiert der Endknoten oder die andere Einrichtung bei 606 das Objekt für die Übertragung. Bei 608 wird der erste Teil des Objekts ausgewählt. Danach wird bei 610 der erste Objektteil übertragen. Bei 612 empfängt ein entfernter Netzknoten den übertragenen Objektteil, und bei 614 wird der formatierte Teil des Objekts (zum Beispiel an einen Fog-Knoten) weitergeleitet. Bei 616 kann eine Bestätigung (ACK oder Ack) erfolgen, dass der Teil des Objekts (zum Beispiel vom Fog-Knoten) empfangen worden ist. Bei 618 wird ermittelt, ob die Bestätigung in Ansprechen auf das Senden des Teils des Objekts empfangen worden ist. Wenn bei 618 ermittelt wird, dass die Bestätigung nicht empfangen worden ist, wird bei dem Ablauf zu 610 zurückgekehrt, um den Objektteil erneut zu übertragen. Wenn bei 618 ermittelt wird, dass die Bestätigung empfangen worden ist, wird bei 620 ermittelt, ob der zuletzt übertragene Teil der letzte Teil des Objekts gewesen ist. Wenn bei 620 ermittelt wird, dass der zuletzt übertragene Teil nicht der letzte Teil des Objekts gewesen ist, wird bei 622 der nächste Teil ausgewählt und dann bei 610 übertragen. Wenn bei 620 ermittelt wird, dass der zuletzt übertragene Teil der letzte Teil des Objekts gewesen ist, wird bei dem Ablauf zu 604 zurückgekehrt, um zu ermitteln, ob ein neues Objekt erhalten worden ist.
  • Wenn der formatierte Teil des Objekts bei 614 weitergeleitet wird, wird der Objektteil bei 624 an einer Empfangseinrichtung (zum Beispiel einem Fog-Knoten) verarbeitet und bei 626 eine Objektzusammensetzung durchgeführt (und/oder wird an einem Teil oder allen der Elemente rechts von 626 implementiert). Bei 628 wird ermittelt, ob der empfangene Objektteil der erste Teil des Objekts ist. Wenn bei 628 ermittelt wird, dass der empfangene Objektteil der erste Teil des Objekts ist, werden bei 630 ein Teilobjektagent und ein TTL-Timer (TTL = Time To Live) erzeugt, und bei 632 wird eine Objektvollständigkeitsprüfung implementiert (und/oder wird an einem Teil oder allen der Elemente rechts von 632 implementiert). Wenn bei 628 ermittelt wird, dass der empfangene Objektteil nicht der erste Teil des Objekts ist, wird der empfangene Objektteil bei 634 zum vorhandenen Teilobjektagenten hinzugefügt, und bei 632 (und in manchen Ausführungsformen an den Elementen rechts von 632) wird eine Objektvollständigkeitsprüfung implementiert. Bei 636 wird ermittelt, ob alle Teile des Objekts empfangen worden sind (zum Beispiel am Fog-Knoten angekommen sind). Wenn bei 636 ermittelt wird, dass nicht alle Teile des Objekts empfangen worden sind, wird bei 638 ermittelt, ob die Zeit des TTL-Timers (TTL = Time To Live) überschritten worden ist. Wenn bei 638 ermittelt wird, dass die Zeit des TTL-Timers noch nicht abgelaufen ist, wird bei dem Ablauf zu 624 zurückgekehrt, um den nächsten empfangenen Objektteil zu verarbeiten. Wenn bei 638 ermittelt wird, dass die Zeit des TTL-Timers abgelaufen ist, wird bei 640 ermittelt, ob eine Objektverwendung in Frage kommt. Wenn eine Objektverwendung bei 640 in Frage kommt oder wenn bei 636 alle Teile angekommen sind, wird das Objekt bei 642 gespeichert (und/oder wird an einem Teil oder allen der Elemente rechts von 642 implementiert). Dies kann in manchen Ausführungsformen zum Beispiel durch Einfügen eines Objektdatensatzes bei 644 in einer permanenten Datenbank 646 oder einer anderen Speichereinrichtung implementiert werden. Wenn eine Objektverwendung bei 640 nicht in Frage kommt, wird bei 648 ein Fehler aufgezeichnet, es kommt zu einer Selbstzerstörung des Teilobjektagenten, und bei 650 wird ein Fehlerdatensatz in der permanenten Datenbank 646 (oder einer anderen Speichereinrichtung) eingefügt.
  • In manchen Ausführungsformen wird eine Datenfragmentierung bei 604, 606, 608, 610, 612, 614, 616, 618, 620 und 622 (zum Beispiel an einem Endknoten) implementiert. In manchen Ausführungsformen können 612 und/oder 614 und/oder 616 je an einem anderen Knoten (zum Beispiel an einem entfernten Netzknoten) implementiert werden. In manchen Ausführungsformen kann eine Datenfragmentierung wie die in 6 veranschaulichte Datenfragmentierung an einem beliebigen der hierin veranschaulichten oder beschriebenen Endknoten (zum Beispiel an einem beliebigen der Endknoteneinrichtungen aus der Gruppe 502, aus der Gruppe 504 oder aus der Gruppe 506, die in 5 veranschaulicht sind) implementiert werden. In manchen Ausführungsformen kann eine Datenfragmentierung wie die in 6 veranschaulichte Datenfragmentierung an einer beliebigen IoT-Einrichtung (zum Beispiel an einer beliebigen der hierin veranschaulichten oder beschriebenen IoT-Einrichtungen, zum Beispiel am Gateway 520 gemäß 5 oder an der IoT-Einrichtung 1300 gemäß 13) implementiert werden.
  • In manchen Ausführungsformen wird eine Datenrekombination bei 624, 626, 628, 630, 632, 634, 636, 638, 640, 642, 644, 646, 648 und 650 (zum Beispiel an einem Fog-Knoten) implementiert. In manchen Ausführungsformen kann eine Datenrekombination wie die in 6 veranschaulichte Datenrekombination an einem beliebigen der hierin veranschaulichten oder beschriebenen Fog-Knoten (zum Beispiel am in 5 veranschaulichten Fog-Knoten 530) implementiert werden. In manchen Ausführungsformen kann eine Datenrekombination wie die in 6 veranschaulichte Datenrekombination an einer beliebigen IoT-Einrichtung (zum Beispiel an einer beliebigen der hierin veranschaulichten oder beschriebenen IoT-Einrichtungen, zum Beispiel am Gateway 520 gemäß 5 oder an der IoT-Einrichtung 1300 gemäß 13) implementiert werden.
  • 7 veranschaulicht eine Datenfragmentierung und -rekombination 700 gemäß manchen Ausführungsformen. In manchen Ausführungsformen kann die Datenfragmentierung und -rekombination 700 der Datenfragmentierung und -rekombination 600 entsprechen oder ähnlich sein. In manchen Ausführungsformen kann die Datenfragmentierung gemäß 7 zum Beispiel in einem Endknoten implementiert werden. In manchen Ausführungsformen kann die Datenrekombination gemäß 7 zum Beispiel in einem Fog-Knoten implementiert werden. In manchen Ausführungsformen kann die Datenfragmentierung gemäß 7 jedoch statt in Endknoten auch in anderen Einrichtungen (statt in Endknoten zum Beispiel in anderen IoT-Einrichtungen) implementiert werden. Analog dazu kann die Datenrekombination gemäß 7 in manchen Ausführungsformen statt in Fog-Knoten auch in anderen Einrichtungen (statt in Fog-Knoten zum Beispiel in anderen IoT-Einrichtungen) implementiert werden.
  • Die Datenfragmentierung und -rekombination 700 beginnt am Anfang 702. Bei 704 wird ermittelt, ob ein Endknoten (oder statt eines Endknotens irgendeine andere Einrichtung) ein neues Objekt erhalten hat. In manchen Ausführungsformen kann das neue Objekt zum Beispiel ein durch eine Kamera (zum Beispiel an einem Endknoten) aufgenommenes Bild sein. In manchen Ausführungsformen kann das neue Objekt zum Beispiel Daten, Nutzdaten und/oder ein Bild etc. sein. Wenn bei 704 kein neues Objekt erhalten worden ist, wird bei dem Ablauf so lange bei 704 geblieben, bis ein neues Objekt erhalten worden ist. Wenn bei 704 ein neues Objekt erhalten wird, werden bei 710 als Nächstes ein oder mehrere Teile des Objekts übertragen. In manchen Ausführungsformen empfängt ein entfernter Netzknoten den übertragenen Objektteil (die übertragenen Objektteile) bei 712, und der formatierte Teil des Objekts wird (zum Beispiel an einen Fog-Knoten) weitergeleitet.
  • Wenn der formatierte Teil des Objekts weitergeleitet wird, wird der Objektteil bei 724 an einer Empfangseinrichtung (zum Beispiel einem Fog-Knoten) verarbeitet, und bei 726 wird eine Objektzusammensetzung durchgeführt. Bei 732 wird eine Objektvollständigkeitsprüfung implementiert. Wenn das Objekt vollständig ist, wird bei 742 das Objekt oder eine Störungsmeldung gespeichert. Wenn das Objekt bei 732 noch nicht vollständig ist, wird bei dem Ablauf zu 724 zurückgekehrt, um den nächsten Objektteil zu verarbeiten.
  • In manchen Ausführungsformen wird eine Datenfragmentierung bei 704 und 710 (zum Beispiel an einem Endknoten) implementiert. In manchen Ausführungsformen kann 712 an einem anderen Knoten (zum Beispiel an einem entfernten Netzknoten) implementiert werden. In manchen Ausführungsformen kann eine Datenfragmentierung wie die in 7 veranschaulichte Datenfragmentierung an einem beliebigen der hierin veranschaulichten oder beschriebenen Endknoten (zum Beispiel an einem beliebigen der Endknoteneinrichtungen aus der Gruppe 502, aus der Gruppe 504 oder aus der Gruppe 506, die in 5 veranschaulicht sind) implementiert werden. In manchen Ausführungsformen kann eine Datenfragmentierung wie die in 7 veranschaulichte Datenfragmentierung an einer beliebigen IoT-Einrichtung (zum Beispiel an einer beliebigen der hierin veranschaulichten oder beschriebenen IoT-Einrichtungen, zum Beispiel am Gateway 520 gemäß 5 oder an der IoT-Einrichtung 1300 gemäß 13) implementiert werden.
  • In manchen Ausführungsformen wird eine Datenrekombination bei 726, 732 und 742 (zum Beispiel an einem Fog-Knoten) implementiert. In manchen Ausführungsformen kann eine Datenrekombination wie die in 7 veranschaulichte Datenrekombination an einem beliebigen der hierin veranschaulichten oder beschriebenen Fog-Knoten (zum Beispiel am in 5 veranschaulichten Fog-Knoten 530) implementiert werden. In manchen Ausführungsformen kann eine Datenrekombination wie die in 7 veranschaulichte Datenrekombination an einer beliebigen IoT-Einrichtung (zum Beispiel an einer beliebigen der hierin veranschaulichten oder beschriebenen IoT-Einrichtungen, zum Beispiel am Gateway 520 gemäß 5 oder an der IoT-Einrichtung 1300 gemäß 13) implementiert werden.
  • 8 veranschaulicht eine Datenrekombination 800 gemäß manchen Ausführungsformen. In manchen Ausführungsformen kann die Datenrekombination 800 zum Beispiel in einem oder mehrere Fog-Knoten implementiert werden. Jedoch kann die Datenrekombination 800 in manchen Ausführungsformen statt in Fog-Knoten auch in einer oder mehreren anderen Einrichtungen (statt in Fog-Knoten zum Beispiel in anderen IoT-Einrichtungen oder in Rechenknoten beliebiger Art) implementiert werden.
  • Die Datenrekombination 800 beginnt am Anfang 802. Bei 804 aktualisieren ein oder mehrere Knoten (zum Beispiel ein oder mehrere Fog-Knoten oder ein oder mehrere IoT-Knoten etc.) laufend einen Objektteil (aktualisieren zum Beispiel ein Datenfragment wie ein Bildfragment oder einen Bildteil) . Danach wird bei 806 das Objekt zusammengesetzt (und/oder wird an einem Teil oder allen der Elemente rechts von 806 implementiert). Bei 808 wird ermittelt, ob der momentane Objektteil der erste Teil des Objekts ist. Wenn bei 808 ermittelt wird, dass er der erste Teil des Objekts ist, werden bei 810 ein Teilobjektagent (oder ein Teilobjektaktor) und ein TTL-Timer (TTL = Time To Live) erzeugt. Danach wird bei 812 (und/oder an einem Teil oder allen der Elemente rechts von 812) eine Objektvollständigkeitsprüfung implementiert. Wenn bei 808 ermittelt wird, dass es sich nicht um den ersten Teil des Objekts handelt, wird der empfangene Objektteil bei 814 zum vorhandenen Teilobjektagenten, der mit diesem Objekt korrespondiert, hinzugefügt, und bei dem Ablauf wird zu 812 (und/oder zu den Blöcken rechts von 812) übergegangen.
  • Bei 816 wird ermittelt, ob alle Teile für das momentane Objekt angekommen sind. Wenn bei 816 ermittelt wird, dass nicht alle Teile angekommen sind, wird bei 818 ermittelt, ob eine Zeit des TTL-Timers überschritten worden ist. Wenn bei 818 ermittelt wird, dass die Zeit des TTL-Timers nicht überschritten worden ist, wird bei dem Ablauf zu 804 zurückgekehrt, um einen nächsten Teil des Objekts zu empfangen. Wenn bei 818 ermittelt wird, dass die Zeit des TTL-Timers überschritten worden ist, wird bei 820 ermittelt, ob das Teilobjekt noch verwendbar ist. Wenn bei 820 ermittelt wird, dass das Teilobjekt nicht mehr verwendbar ist, wird für das Teilobjekt bei 822 ein Fehler markiert. Danach wird bei 824 ein Fehlerdatensatz in einer Speichereinrichtung, etwa einer permanenten Datenbank 826, gespeichert. In manchen Ausführungsformen kann ein Dispatch an den die Fragmente sendenden Knoten zu einer Paketneuanforderung eines oder mehrerer Fragmente erfolgen kann ebenfalls an dieser Stelle erfolgen. Wenn bei 820 ermittelt wird, dass das Teilobjekt nicht mehr verwendbar ist, wird das Objekt bei 828 als ein Teilobjekt markiert, bei 830 eine Nachverarbeitung unvollständiger Objekte implementiert und bei 832 ein Datensatz zu einem unvollständigen Objekt in einer Speichereinrichtung, zum Beispiel in der permanenten Datenbank 826, gespeichert (in ihr eingefügt).
  • Wenn bei 816 ermittelt wird, dass alle Teile angekommen sind, wird bei 834 eine Objektverarbeitung implementiert (und/oder wird an einem Teil oder allen der Elemente rechts von 834 implementiert). Bei 836 wird die Integrität des Objekts anhand des Typs verifiziert. Bei 838 wird ermittelt, ob die Objektintegrität zulässig ist. Wenn bei 838 ermittelt wird, dass die Objektintegrität nicht zulässig ist, kann bei 840 eine Markierung als Integritätsfehlerangabe, die mit dem Objekt korrespondiert, vorgenommen werden. Bei 842 kann dann ein Integritätsfehlerdatensatz in einer Speichereinrichtung, etwa in der permanenten Datenbank 826, eingefügt werden. Wenn bei 838 ermittelt wird, dass die Objektintegrität zulässig ist, wird das Objekt bei 844 gespeichert (und/oder wird an einem Teil oder allen der Elemente rechts von 844 implementiert). Bei 846 wird ein Objektdatensatz in einer Speichereinrichtung, etwa in der permanenten Datenbank 826, eingefügt. Sobald die Speicherung in der Speichereinrichtung (etwa der permanenten Datenbank 826) erfolgt ist, wird bei 848 eine Ressourcenbereinigung angefordert, und bei 850 und/oder 852 wird eine Ressourcenbereinigung implementiert. In manchen Ausführungsformen kann die Ressourcenbereinigung bei 850 vorgenommen und/oder bei 852 eine Selbstzerstörung des Teilobjektagenten (oder des Teilobjektaktors) implementiert werden.
  • In manchen Ausführungsformen kann die Datenrekombination 800 an einem Fog-Knoten implementiert werden. In manchen Ausführungsformen kann die Datenrekombination 800 an einem beliebigen der hierin veranschaulichten oder beschriebenen Fog-Knoten (zum Beispiel am in 5 veranschaulichten Fog-Knoten 530) implementiert werden. In manchen Ausführungsformen kann die Datenrekombination 800 an einer beliebigen IoT-Einrichtung (zum Beispiel an einer beliebigen der hierin veranschaulichten oder beschriebenen IoT-Einrichtungen, zum Beispiel am Gateway 520 gemäß 5 oder an der IoT-Einrichtung 1300 gemäß 13) implementiert werden.
  • 9 veranschaulicht eine Datenrekombination 900 gemäß manchen Ausführungsformen. In manchen Ausführungsformen kann die Datenfragmentierung und -rekombination 900 der Datenfragmentierung und -rekombination 800 entsprechen oder ähnlich sein. In manchen Ausführungsformen kann die Datenrekombination 900 zum Beispiel in einem oder mehrere Fog-Knoten implementiert werden. Jedoch kann die Datenrekombination 900 in manchen Ausführungsformen statt in Fog-Knoten auch in einer oder mehreren anderen Einrichtungen (statt in Fog-Knoten zum Beispiel in anderen IoT-Einrichtungen oder in Rechenknoten beliebiger Art) implementiert werden.
  • Die Datenrekombination 900 beginnt am Anfang 902. Bei 904 aktualisieren ein oder mehrere Knoten (zum Beispiel ein oder mehrere Fog-Knoten oder ein oder mehrere IoT-Knoten etc.) laufend einen oder mehrere Objektteile (aktualisieren zum Beispiel ein oder mehrere Datenfragmente, etwa ein oder mehrere Bildfragmente oder einen oder mehrere Bildteile). Bei 906 wird das Objekt aus dem einen oder den mehreren empfangenen Objektteilen zusammengesetzt. Bei 912 wird ermittelt, ob das Objekt vollständig ist. Wenn bei 912 ermittelt wird, dass das Objekt unvollständig ist, wird bei 918 ermittelt, ob eine vorher festgelegte Zeit abgelaufen ist (zum Beispiel ob eine Time To Live bzw. TTL-Zeit überschritten worden ist).
  • Wenn bei 918 ermittelt wird, dass die vorher festgelegte Zeit nicht abgelaufen ist, wird bei dem Ablauf zu 904 zurückgekehrt, um einen nächsten Teil des Objekts zu empfangen. Wenn bei 918 ermittelt wird, dass die vorher festgelegte Zeit abgelaufen ist, wird bei 920 ermittelt, ob das Teilobjekt noch verwendbar ist. Wenn bei 920 ermittelt wird, dass das Teilobjekt nicht mehr verwendbar ist, wird für das Teilobjekt bei 922 (zum Beispiel in einer Speichereinrichtung, etwa einer permanenten Datenbank) ein Fehler markiert. Wenn bei 920 ermittelt wird, dass das Teilobjekt noch verwendbar ist, wird das Objekt als ein Teilobjekt in einer Speichereinrichtung gespeichert, und bei 930 wird eine Prozedur einer unvollständigen Nachverarbeitung implementiert.
  • Wenn bei 912 ermittelt wird, dass das Objekt vollständig ist, wird bei 934 eine Objektnachverarbeitung implementiert. Bei 938 wird ermittelt, ob die Objektintegrität zulässig ist. Wenn bei 938 ermittelt wird, dass die Objektintegrität nicht zulässig ist, kann bei 940 eine Markierung als Integritätsfehlerangabe, die mit dem Objekt korrespondiert, vorgenommen werden. Dieser Integritätsfehlerdatensatz kann in einer Speichereinrichtung, zum Beispiel einer permanenten Datenbank, eingefügt werden. Wenn bei 938 ermittelt wird, dass die Objektintegrität zulässig ist, wird das Objekt bei 944 in einer Speichereinrichtung (etwa einer permanenten Datenbank) gespeichert. Nach 922, 930, 940 und 944 wird bei 950 eine Ressourcenbereinigung implementiert. Die bei 950 vorgenommene Ressourcenbereinigung kann eine Selbstzerstörung des zum Implementieren eines oder mehrerer der Elemente der Datenrekombination 900 genutzten Teilobjektagenten (oder Teilobjektaktors) enthalten.
  • In manchen Ausführungsformen kann eine Datenrekombination 900 an einem Fog-Knoten implementiert werden. In manchen Ausführungsformen kann die Datenrekombination 900 an einem beliebigen der hierin veranschaulichten oder beschriebenen Fog-Knoten (zum Beispiel am in 5 veranschaulichten Fog-Knoten 530) implementiert werden. In manchen Ausführungsformen kann die Datenrekombination 900 an einer beliebigen IoT-Einrichtung (zum Beispiel an einer beliebigen der hierin veranschaulichten oder beschriebenen IoT-Einrichtungen, zum Beispiel am Gateway 520 gemäß 5 oder an der IoT-Einrichtung 1300 gemäß 13) implementiert werden.
  • 10 veranschaulicht eine Datenrekombination 1000 gemäß manchen Ausführungsformen. In manchen Ausführungsformen können die Datenpakete zum Beispiel Bildpakete sein. In manchen Ausführungsformen kann die Datenrekombination 1000 zum Beispiel in einem Fog-Knoten implementiert werden. Jedoch kann die Datenrekombination 1000 in manchen Ausführungsformen statt in Fog-Knoten auch in anderen Einrichtungen (statt in Fog-Knoten zum Beispiel in anderen IoT-Einrichtungen) implementiert werden. In manchen Ausführungsformen kann die Datenrekombination 1000 einer beliebigen der hierin beschriebenen oder veranschaulichten Datenrekombinationen entsprechen oder ähnlich sein.
  • Die Datenrekombination 1000 beginnt mit einer Auto-Sequenzialisierung eines oder mehrerer Datenpakete (oder Datenfragmente) bei 1002. Die einer Auto-Sequenzialisierung unterzogenen Pakete können in einer Reihenfolge (bzw. in einer Sequenz), nicht in einer Reihenfolge (bzw. nicht in einer Sequenz) oder sowohl in einer Reihenfolge (in einer Sequenz) als auch nicht in einer Reihenfolge (nicht in einer Sequenz) empfangen werden. Bei 1004 werden fehlende Pakete detektiert, und es können Pakete neu angefordert werden. Bei 1006 können Datenfragmente in einem Datenspeicher gespeichert werden. Bei 1008 können Paketfragmente zu einer Rekonstruktion ursprünglicher Nutzdaten rekombiniert werden.
  • In manchen Ausführungsformen kann eine Datenrekombination 1000 an einem Fog-Knoten implementiert werden. In manchen Ausführungsformen kann die Datenrekombination 1000 an einem beliebigen der hierin veranschaulichten oder beschriebenen Fog-Knoten (zum Beispiel am in 5 veranschaulichten Fog-Knoten 530) implementiert werden. In manchen Ausführungsformen kann die Datenrekombination 1000 an einer beliebigen IoT-Einrichtung (zum Beispiel an einer beliebigen der hierin veranschaulichten oder beschriebenen IoT-Einrichtungen, zum Beispiel am Gateway 520 gemäß 5 oder an der IoT-Einrichtung 1300 gemäß 13) implementiert werden.
  • 11 veranschaulicht eine Datenrekombination 1100 gemäß manchen Ausführungsformen. In manchen Ausführungsformen kann die Datenrekombination 1100 zum Beispiel in einem Fog-Knoten implementiert werden. Jedoch kann die Datenrekombination 1100 in manchen Ausführungsformen statt in Fog-Knoten auch in anderen Einrichtungen (statt in Fog-Knoten zum Beispiel in anderen IoT-Einrichtungen) implementiert werden. In manchen Ausführungsformen kann die Datenrekombination 1100 einer beliebigen der hierin beschriebenen oder veranschaulichten Datenrekombinationen entsprechen oder ähnlich sein.
  • In manchen Ausführungsformen kann die Datenrekombination 1100 mit dem Annehmen eines oder mehrerer Datenpakete (oder Datenfragmente) bei 1102 beginnen. In manchen Ausführungsformen können die Datenpakete zum Beispiel Bildpakete sein. In manchen Ausführungsformen können zum Beispiel Fragmente bei 1102 in einer beliebigen Reihenfolge und aus einem einzigen Stapel oder aus mehreren unterschiedlichen Stapeln gleichzeitig angenommen werden. Die Nutzdaten werden bei 1104 zusammengesetzt. In manchen Ausführungsformen kann die Nutzdatenzusammensetzung bei 1104 implementiert werden, indem aus der Teildateneinbettung und der Datenmenge, zu der das Fragment gehört, die Fragmentreihenfolge ermittelt wird. In manchen Ausführungsformen gehört das Fragment möglicherweise zum Beispiel zu einem momentanen, gerade konstruierten Datenobjekt oder kann Teil eines neuen Datenobjekts sein.
  • In manchen Ausführungsformen wird die Nutzdatenfertigstellung bei 1106 implementiert. In manchen Ausführungsformen kann 1106 zum Beispiel eine Nutzdatenfertigstellung sowie Integritätsprüfungen enthalten (zum Beispiel um zu ermitteln, ob alle Komponentendatenfragmente empfangen worden sind). Bei 1108 wird eine Nachverarbeitung implementiert. In manchen Ausführungsformen kann die Nachverarbeitung bei 1108 zum Beispiel eine Datenintegritätsprüfung und Entscheidungen für BESTANDEN/NICHT BESTANDEN einschließen. Bei 1110 werden die Nutzdaten gespeichert. In manchen Ausführungsformen können zum Beispiel die vollständigen Nutzdaten in einer Speichereinrichtung, etwa einer Datenbank, gespeichert werden. Bei 1112 kann eine Behandlung unvollständiger Nutzdaten implementiert werden. In manchen Ausführungsformen kann die Behandlung unvollständiger Nutzdaten bei 1112 eine Restebearbeitung enthalten. In manchen Ausführungsformen kann die Behandlung unvollständiger Nutzdaten bei 1112 Speichern unvollständiger Nutzdaten und/oder Markieren der Nutzdaten als unvollständig (zum Beispiel in der Speichereinrichtung) enthalten. Bei 1114 kann eine Ressourcenbereinigung implementiert werden. Diese kann zum Beispiel einen Vorgang einer Selbstzerstörung eines Teildatenobjektagenten enthalten.
  • In manchen Ausführungsformen kann die Datenrekombination 1100 an einem Fog-Knoten implementiert werden. In manchen Ausführungsformen kann die Datenrekombination 1100 an einem beliebigen der hierin veranschaulichten oder beschriebenen Fog-Knoten (zum Beispiel am in 5 veranschaulichten Fog-Knoten 530) implementiert werden. In manchen Ausführungsformen kann die Datenrekombination 1100 an einer beliebigen IoT-Einrichtung (zum Beispiel an einer beliebigen der hierin veranschaulichten oder beschriebenen IoT-Einrichtungen, zum Beispiel am Gateway 520 gemäß 5 oder an der IoT-Einrichtung 1300 gemäß 13) implementiert werden.
  • 12 veranschaulicht ein Teilbilddatensequenzdiagramm 1200 gemäß manchen Ausführungsformen. Obwohl 12 ein auf eine Bildrekombination bezogenes Sequenzdiagramm 1200 veranschaulicht, können noch andere Ausführungsformen statt mit Bilddaten auch mit Daten von anderen Typen mit Datensequenzdiagrammen mit Ähnlichkeit zum Diagramm 1200 implementiert werden. In manchen Ausführungsformen enthält das Diagramm 1200 einen Datenbankbildstromsenke-Agenten 1202 (DBIMG StreamSink Agent 1202), einen Bilder-Agenten 1204 (IMGS Agent 1204), einen Teilbild-Agenten 1206 (Partial IMG Agent 1206), eine Zeitreihendatenbank 1208 (ts DB 1208), einen Speicherverbinder 1210 und ein Speichersystem 1212. In manchen Ausführungsformen können einer oder mehrere der Agenten 1202, 1204, 1206 und/oder die Datenbank 1208 und/oder der Speicherverbinder 1210 und/oder das Speichersystem 1212 zum Beispiel in einem IoT-Netz, in einer oder mehreren IoT-Einrichtungen, in einem oder mehreren Gateways, in einem oder mehreren Fog-Knoten, in einem oder mehreren anderen IoT-Knoten und/oder in einer beliebigen Kombination von IoT-Knoten unterschiedlicher Art enthalten sein.
  • Am Agenten 1202 werden von dem Knoten, der die Fragmente sendet, eine Bestätigung (ACK) und eine Teilbildnachricht empfangen. Der Agent 1202 kann mehrere Pakete von einem oder mehreren Endpunkten empfangen und teilt die Nutzdaten (zum Beispiel in Fragmente) auf, sendet eine Bestätigung (ACK) zurück, parst die Nutzdaten und sendet eine CPPartialIMG-Klasse an den Agenten 1204. In manchen Ausführungsformen kann die CPPartialIMG-Klasse eine Teilbildfallklasse sein, die ihre Konstruktorparameter exportieren und einen Mechanismus für eine rekursive Zerlegung über einen Musterabgleich bereitstellen kann. In manchen Ausführungsformen enthält die CPPartialIMG-Klasse unter anderem möglicherweise eine eta-Zeichenfolge, eine lifeleft-Zeichenfolge, eine missing-Zeichenfolge, eine starttime-Zeichenfolge, ein Tag (ConfigTag), einen Bildschlüssel (imgkey), einen current-count-Integer (currcount) und/oder einen targetcount-Integer (target count). Bei eta kann es sich um eine voraussichtliche Ankunftszeit handeln, die als Zeichenfolge angezeigt wird. Bei lifelived kann es sich um die Zeit handeln, in der diese Klasse existiert hat und die als Zeichenfolge beschrieben wird, lifeleft kann eine übrige Zeit, etwa eine verbleibende Lebensdauer, sein, missing kann der noch fehlende Prozentanteil sein, der als Zeichenfolge beschrieben wird, starttime kann der Zeitpunkt sein, zu dem das erste Fragment angekommen ist und der als Zeichenfolge beschrieben wird, tag kann ein config-Tag sein, imgkey kann ein Bildschlüssel sein, currcount kann eine momentane Anzahl von für das Bild empfangenen Fragmenten sein, und targetcount kann die Anzahl von Fragmenten sein, die zur Vervollständigung des Bilds empfangen werden müssen. Das config-Tag kann zum Beispiel ein Konfigurationstag sein, das unter anderem eine Endzeichenfolge (zum Beispiel eine Endpunkttyp-Protokollkennung), eine Senkenzeichenfolge (zum Beispiel einen Endpunkt, zu dem hin Daten verschoben werden sollen), eine ktype-Zeichenfolge (zum Beispiel einen Typ einer empfangenen Nachricht), eine pubtopic-Zeichenfolge (zum Beispiel für die Verfolgbarkeit des Endpunkts, zu dem sich hinbewegt werden soll) und/oder eine sinktopic-Zeichenfolge (zum Beispiel einen Endpunkt, auf den gelauscht werden soll) enthält. IMGKey (image key) kann eine case-Klasse sein, die zum Beispiel unter anderem eine uuid-Zeichenfolge (zum Beispiel eine eindeutige Kennung der Einrichtung in dem System, die das Fragment generiert hat) und/oder eine imageid (zum Beispiel eine eindeutige ID des Bilds für die Einrichtung, die das Fragment generiert hat) enthält.
  • Wenn für das momentane Bild kein Teilbild-Agent vorhanden ist, wird ein neuer Teilbild-Agent 1206 erzeugt und zu einer Liste von Teilbildern hinzugefügt. Der Agent 1204 sendet die CPPartialIMG-Klasse an den Teilbild-Agenten 1206 (der entweder bereits vorhanden war oder durch den Agenten 1204 neu erzeugt wurde). Der Agent 1206 fügt dem Agenten die neuen Teilbilder so lange hinzu, bis alle Teile der Nutzdaten angekommen sind oder bis ein Timeout auftritt. Der Agent 1206 sendet eine CASSTOREIMG-Klasse an den Agenten 1204. In manchen Ausführungsformen kann die CASSTOREIMG-Klasse eine format-Zeichenfolge, eine uuid-Zeichenfolge, eine imageid-Zeichenfolge, einen sectid-Integer, einen Zeitstempel (ts), eine Bildlänge (imglen) und/oder Vollbild-Bytes (oder Bildarray-Bytes) enthalten. Das Format kann ein Datenformat wie zum Beispiel PNG, JPEG, BMP oder WBMP sein. Die uuid kann eine eindeutige ID der Einrichtung in dem System sein, die das Fragment generiert hat. Die imageid kann eine eindeutige ID des Bilds für die Einrichtung sein, die das Fragment generiert hat. Die sectid kann die Fragment-ID des ersten Fragments sein, das für das vollständige Bild ankommt. Der Zeitstempel (ts) kann eine Zeit sein, die (zum Beispiel ab der Epoche)dargestellt wird, wenn das erste Fragment angekommen ist. Die Bildlänge (imglen) kann die Anzahl der zum Zusammensetzen des Bilds genutzten Fragmente sein. Vollbild-Bytes (fullimagebytes) oder ein Bildarray-Byte (imgarraybyte) können das vollständige Bild in Form eines Byte-Arrays sein.
  • Der Agent 1206 legt dann ein oder mehrere Wert-Tags der Bildzeitreihe (IMG-ts-Wert-Tags) in der Zeitreihendatenbank 1208 ab. Die Datenbank 1208 kann Informationen zum Beispiel dazu speichern, was erreicht worden ist, wie viele Einzelteile für ein bestimmtes Bild zu einem bestimmten Zeitpunkt wiederhergestellt worden sind etc. Indem Informationen dazu gespeichert werden, wie lange es gedauert hat, die Bilder zu empfangen oder zu speichern, können zum Beispiel Informationen zur Topologie des Netzes und/oder zu Einrichtungen in dem Gebiet erhoben werden. In manchen Ausführungsformen werden Informationen zum Beispiel möglicherweise dazu gespeichert, wenn die Übertragung eines Bilds basierend auf der jeweiligen Jahreszeit (zum Beispiel wenn im Sommer Blätter das Sichtfeld einer Kamera versperren) oder basierend auf dem Wochentag und der Uhrzeit an dem Tag (zum Beispiel wenn ein Lkw das Sichtfeld einer Kamera einer Sender- oder Empfängereinrichtung versperrt, weil er dienstags zwischen 15 und 16 Uhr an einer bestimmten Stelle geparkt ist) länger oder kürzer dauern kann. So kann ermittelt werden, dass eine oder mehrere Einrichtungen vorteilhaft zum Beispiel anders positioniert werden könnten. Die Datenbank 1208 sendet Clusterrechennachricht-Zeitreihe-Datenpunkt-Tabelle-Daten über den Verbinder 1210 an das Speichersystem 1212.
  • Der Agent 1204 entfernt nach dem Empfangen der CASSTOREIMG-Klasse vom Agenten 1206 das Teilbild aus der Teilbild-Agent-Liste und fügt es in einem Vollbildspeichercache hinzu. Danach leert der Agent 1204 den Vollbildspeichercache. Von dem Agenten 1204 wird eine Liste von CASSTOREIMG-Klassen über den Verbinder 1210 an das Speichersystem 1212 gesendet, das eine Clusterrechennachricht-cr.IMG-Tabelle empfängt. Die cr.IMG-Tabelle kann zum Beispiel eine NOSQL-Datenbanktabelle sein und kann unter anderem einen format-Text, einen uuid-Text, einen imageid-Text, einen sectid-Integer, eine ts-Zuordnung (ts = timestamp, Zeitstempel), ein imgarraybyte-Blob und einen imglen-Integer (imglen = image length, Bildlänge) enthalten.
  • 12 veranschaulicht Protokollsequenzen, die bei der Erzeugung eines Vollbilds aus Teilbildern gemäß manchen Ausführungsformen eine Rolle spielen. Jedoch können bei der Vollbilderzeugung gemäß manchen Ausführungsformen auch andere Protokollsequenzen eine Rolle spielen.
  • In manchen Ausführungsformen kann eine grafische Benutzeroberfläche (GUI) genutzt werden, um den Bildverarbeitungsfortschritt (zum Beispiel Metadaten, die mit einem momentan betriebenen System assoziiert sind) zu zeigen. Die grafische Benutzeroberfläche veranschaulicht zum Beispiel möglicherweise unter anderem eine Endpunktkennung, eine Knotenstartzeit, eine UUID, eine Imageid, eine momentane Anzahl, eine Zielanzahl, eine Fertigstellung in Prozent, eine ID vorhandener Teilabschnitte, Informationen zu anderen Teilabschnitten, etwa zu Teilabschnitten, die noch nicht angekommen sind, eine voraussichtliche Ankunftszeit (ETA), eine beendete Lebensdauer, eine verbleibende Lebensdauer, eine Time To Live (TTL) und/oder eine Zeit bis zur erwarteten Fertigstellung.
  • 13 ist ein Blockschema von beispielhaften Komponenten, die in einer IoT-Einrichtung 1300 zum Implementieren einer Datenfragmentierung und/oder einer Datenrekombination vorhanden sein können. In manchen Ausführungsformen kann die IoT-Einrichtung 1300 beliebige der hierin veranschaulichten oder beschriebenen Techniken implementieren. In manchen Ausführungsformen ist die IoT-Einrichtung 1300 zum Beispiel möglicherweise ein oder mehrere Endknoten, etwa ein beliebiger der hierin veranschaulichten oder beschriebenen Endknoten (zum Beispiel eine oder mehrere der in der Gruppe 502, in der Gruppe 504 und/oder in der Gruppe 506 gemäß 5 enthaltenen Einrichtungen). In manchen Ausführungsformen ist die IoT-Einrichtung 1300 zum Beispiel möglicherweise ein oder mehrere Gateways, etwa ein beliebiges der hierin veranschaulichten oder beschriebenen Gateways (zum Beispiel das Gateway 520 gemäß 5). In manchen Ausführungsformen ist die IoT-Einrichtung 1300 zum Beispiel möglicherweise ein oder mehrere Fog-Knoten, etwa ein beliebiger der hierin veranschaulichten oder beschriebenen Fog-Knoten (zum Beispiel der Fog-Knoten 530 gemäß 5). Die IoT-Einrichtung 1300 kann beliebige Kombinationen der in dem Beispiel gezeigten Komponenten enthalten. Die Komponenten können als ICs, Abschnitte davon, diskrete elektronische Bauelemente oder andere Module, Logik, Hardware, Software, Firmware oder eine Kombination davon, die in der IoT-Einrichtung 1300 angepasst ist, oder als sonstige in das Chassis eines größeren Systems eingebaute Komponenten implementiert werden. Das Blockschema in 13 ist eine Überblicksdarstellung von Komponenten der IoT-Einrichtung 1300. Jedoch können in anderen Implementierungen manche der gezeigten Komponenten auch weggelassen werden, noch weitere Komponenten vorhanden und die gezeigten Komponenten anders angeordnet sein.
  • Die IoT-Einrichtung 1300 kann einen Prozessor 1302 enthalten, bei dem es sich um einen Mikroprozessor, einen Mehrkernprozessor, einen multithreadingfähigen Prozessor, einen Ultra-Low-Voltage-Prozessor, einen eingebetteten Prozessor oder ein anderes bekanntes Verarbeitungselement handeln kann. Der Prozessor 1302 kann ein Bestandteil eines System-on-Chip (SoC) sein, in dem der Prozessor 1302 sowie weitere Komponenten in einem einzigen integrierten Schaltkreis oder einem einzigen Package wie den Edison™- oder Galileo™-SoC-Platinen von Intel gebildet sind. Der Prozessor 1302 enthält beispielsweise einen auf der Intel®-Core™-Architektur basierenden Prozessor wie einen Quark™-, einen Atom™-, einen i3-, einen i5-, einen i7-, einen Xeon®-, einen Xeon-Phi™-Koprozessor oder einen Prozessor der MCU-Klasse oder einen anderen der von der Intel® Corporation aus Santa Clara, CA erhältlichen Prozessoren. Jedoch können auch beliebig viele andere Prozessoren genutzt werden, etwa die bei der Advanced Micro Devices, Inc. (AMD) aus Sunnyvale, CA erhältlichen Prozessoren, ein MIPS-basiertes Modell der MIPS Technologies, Inc. aus Sunnyvale, CA oder ein ARMbasiertes Modell, für das von der ARM Holdings, Ltd. oder ihren Kunden, Lizenznehmern oder den jeweiligen Anwendern eine Lizenz erteilt wurde. Die Prozessoren können Einheiten wie einen A5-A9-Prozessor der Apple® Inc., einen Snapdragon™-Prozessor der Qualcomm® Technologies, Inc. oder einen OMAP™-Prozessor der Texas Instruments, Inc. enthalten.
  • Der Prozessor 1302 kann mit einem Systemhauptspeicher 1304 über einen Bus 1306 kommunizieren. Es können beliebig viele Speicherelemente genutzt werden, um eine jeweilige Menge von Systemhauptspeicher zur Verfügung zu stellen. Der Hauptspeicher ist zum Beispiel möglicherweise ein Random Access Memory (RAM) gemäß einem auf Joint Electron Devices Engineering Council (JEDEC) Low Power Double Data Rate (LPDDR) basierenden Modell wie dem aktuellen LPDDR2-Standard gemäß JEDEC JESD 209-2E (im April 2009 veröffentlicht) oder einem LPDDR-Standard der nächsten Generation wie LPDDR3 oder LPDDR4, der LPDDR2-Erweiterungen zur Erhöhung der Bandbreite bieten wird. Die einzelnen Speicherelemente können in verschiedenen Implementierungen beliebig viele unterschiedliche Chipgehäusearten aufweisen, etwa ein Single Die Package (SDP), ein Dual Die Package (DDP) oder ein Quad Die Package (Q17P). Diese Bauelemente sind in manchen Ausführungsformen möglicherweise direkt auf ein Motherboard gelötet, um eine Lösung mit einer flacheren Bauform bereitzustellen, während die Bauelemente in anderen Ausführungsformen als ein oder mehrere Speichermodule konfiguriert sind, die stattdessen über einen gegebenen Verbinder an das Motherboard gekoppelt sind. Es können noch beliebig viele andere Speicherelementimplementierungen genutzt werden, etwa Speichermodule von anderen Arten wie z. B. Dual Inline Memory Modules (DIMMs) in unterschiedlichen Varianten, insbesondere microDIMMs oder MiniDIMMs. Ein Speicherelement ist zum Beispiel möglicherweise zwischen 2GB und 16GB groß und konfiguriert als DDR3LM-Package oder LPDDR2- oder LPDDR3-Speicherelement, das über ein Ball Grid Array (BGA) auf ein Motherboard gelötet ist.
  • Um die Voraussetzungen für eine permanente Speicherung von Informationen wie Daten, Anwendungen, Betriebssystemen und so weiter zu schaffen, kann zudem ein Massenspeicher 1308 über den Bus 1306 an den Prozessor 1302 gekoppelt werden. Um eine dünnere und leichtere Systembauform zu ermöglichen, kann der Massenspeicher 1308 über ein Solid State Drive (SSD) implementiert werden. Zu weiteren Bauelementen, die für den Massenspeicher 1308 genutzt werden können, zählen Flashspeicherkarten wie SD-Karten, microSD-Karten, xD Picture Cards und dergleichen sowie USB-Speichersticks.
  • In Implementierungen, die für geringe Leistung ausgelegt sind, handelt es sich beim Massenspeicher 1308 möglicherweise um einen Speicher auf einem Chip oder um Register, die mit dem Prozessor 1302 assoziiert sind. In manchen Beispielen kann der Massenspeicher 1308 hingegen auch unter Nutzung einer Mikro-Festplatte (HDD) implementiert werden. Ferner können für den Massenspeicher 1308 außer oder auch statt Technologien, die beschrieben werden, beliebig viele neue Technologien wie unter anderem Widerstandsänderungsspeicher, Phasenwechselspeicher, holografische Speicher oder chemische Speicher genutzt werden. In die IoT-Einrichtung 1300 sind zum Beispiel möglicherweise die 3D-XPOINT-Speicherelemente von Intel® und Micron® eingebaut.
  • Die Komponenten können über den Bus 1306 kommunizieren. Der Bus 1306 kann beliebig viele Technologien enthalten, etwa Industry Standard Architecture (ISA), Extended ISA (EISA), Peripheral Component Interconnect (PCI), Peripheral Component Interconnect extended (PCIx), PCI express (PCIe) oder beliebig viele sonstige Technologien. Der Bus 1306 kann ein proprietärer Bus sein, der zum Beispiel in einem SoC-basierten System genutzt wird. Es können auch noch andere Bussysteme wie etwa unter anderem eine I2C-Schnittstelle, eine I3C-Schnittstelle, eine SPI-Schnittstelle, Punkt-zu-Punkt-Schnittstellen und ein Energiebus enthalten sein.
  • Der Bus 1306 kann den Prozessor 1302 an einen Mesh-Transceiver 1310 für Kommunikationen mit anderen Mesh-Einrichtungen 1312 koppeln. Der Mesh-Transceiver 1310 kann beliebig viele Frequenzen und Protokolle nutzen, etwa unter anderem Übertragungen bei 2,4 Gigahertz (GHz) gemäß dem Standard IEEE 802.15.4, gemäß dem Standard Bluetooth® Low Energy (BLE), wie von der Bluetooth® Special Interest Group definiert, oder gemäß dem ZigBee®-Standard. Für die Verbindungen zu den Mesh-Einrichtungen 1312 können beliebig viele Funkelemente, die für ein jeweiliges Funkkommunikationsprotokoll konfiguriert sind, genutzt werden. Zum Beispiel kann eine WLAN-Einheit zum Implementieren von Wi-Fi™-Kommunikationen gemäß dem Standard Institute of Electrical and Electronics Engineers (IEEE) 802.11 genutzt werden. Darüber hinaus können Weitverkehrskommunikationen, z. B. gemäß einem Funk- oder anderen Weitverkehrsprotokoll, über eine WWAN-Einheit erfolgen.
  • Der Mesh-Transceiver 1310 kann unter Nutzung mehrerer Standards oder Funkelemente für Kommunikationen bei unterschiedlichen Reichweiten kommunizieren. Die IoT-Einrichtung 1300 kommuniziert zum Beispiel möglicherweise mit Einrichtungen in geografischer Nähe, die z. B. höchstens etwa 10 Meter entfernt sind, unter Nutzung eines lokalen Transceivers basierend auf BLE oder eines anderen für geringe Leistung ausgelegten Funkelements, um Energie zu sparen. Weiter entfernte Mesh-Einrichtungen 1312, die z. B. höchstens etwa 50 Meter voneinander entfernt sind, können über ZigBee- oder andere für mittlere Leistung ausgelegte Funkgeräte erreicht werden. Die Kommunikation gemäß beiden Techniken kann entweder über nur ein Funkelement bei unterschiedlichen Leistungspegeln oder über separate Transceiver, zum Beispiel über einen lokalen Transceiver, der BLE nutzt, und einen separaten Mesh-Transceiver, der ZigBee nutzt, erfolgen. Der Mesh-Transceiver 1310 kann in eine MCU als eine Adresse, auf die der Chip direkt zugreifen kann, etwa in die bei Intel erhältlichen Curie®-Einheiten, integriert sein.
  • Es kann ein Uplink-Transceiver 1314 für die Kommunikation mit Einrichtungen in der Cloud 302 enthalten sein. Der Uplink-Transceiver 1314 ist möglicherweise ein LPWA-Transceiver gemäß Standards wie unter anderem IEEE 802.15.4, IEEE 802.15.4g, IEEE 802.15.4e, IEEE 802.15.4k oder NB-IoT. Die IoT-Einrichtung 1300 kann gemäß der von Semtech und der LoRa Alliance entwickelten Spezifikation LoRaWAN™ (Long Range Wide Area Network) über weite Entfernungen kommunizieren. Die hierin beschriebenen Techniken sind nicht auf diese Technologien begrenzt, sondern können auch zusammen mit beliebig vielen anderen Cloud-Transceivern, die Kommunikationen über weite Entfernungen und mit niedriger Bandbreite implementieren, etwa gemäß Sigfox, Weightless-P von der Weightless Special Interest Group, Random Phase Multiple Access (RPMA®) von Ingenu sowie anderen Technologien, genutzt werden. Daneben können noch andere Kommunikationstechniken wie Time Slotted Channel Hopping, das in der Spezifikation IEEE 802.15.4e beschrieben ist, genutzt werden.
  • Außer den erwähnten Systemen können noch beliebig viele andere Funkkommunikationen und -protokolle für den Mesh-Transceiver 1310 und den Uplink-Transceiver 1314, wie hierin beschrieben, genutzt werden. Die Funktransceiver 1310 und 1312 enthalten zum Beispiel möglicherweise einen LTE-Transceiver oder einen anderen Mobilfunktransceiver, der Spreizspektrum(SPA/SAS)-Kommunikationen zum Implementieren von Hochgeschwindigkeitskommunikationen, etwa für Videoübertragungen, nutzt. Ferner können noch beliebig viele weitere Protokolle genutzt werden, etwa Wi-Fi®-Netze für mittelschnelle Kommunikationen wie Standbilder, Sensormessungen und die Bereitstellung von Netzkommunikationen.
  • Die Funktransceiver 1310 und 1312 können Funkelemente enthalten, die mit beliebig vielen 3GPP-Spezifikationen (3GPP = Third Generation Partnership Project), vor allem mit Long Term Evolution (LTE), Long Term Evolution-Advanced (LTE-A), Long Term Evolution-Advanced Pro (LTE-A Pro) oder Narrow Band IoT (NB-IoT), oder anderen Spezifikationen kompatibel sind. Es kann festgehalten werden, dass Funkelemente, die mit beliebig vielen sonstigen Technologien und Standards für die Festnetz-, Mobilfunk- oder Satellitenkommunikation kompatibel sind, ausgewählt werden können. Diese enthalten zum Beispiel möglicherweise beliebige Technologien für die Mobilfunkkommunikation über weite Entfernungen, die z. B. möglicherweise Kommunikationssysteme der 5. Generation (5G), eine GSM-Funkkommunikationstechnik (GSM = Global System for Mobile Communications), eine GPRS-Funkkommunikationstechnik (GPRS = General Packet Radio Service) oder eine EDGE-Funkkommunikationstechnik (EDGE = Enhanced Data Rates for GSM Evolution) enthalten. Weitere 3GPP-Funkkommunikationstechniken (3GPP = Third Generation Partnership Project), die genutzt werden können, enthalten 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 (vor der 4. 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 (4. Generation)), cdmaOne (2G), CDMA2000 (3G) (Code Division Multiple Access 2000 (Third Generation)), EV-DO (Evolution-Data Optimized oder Evolution-Data Only), AMPS (1G) (Advanced Mobile Phone System (1. Generation)), TACS/ETACS (Total Access Communication System/Extended Total Access Communication System), D-AMPS (2G) (Digital AMPS (2. Generation)), PTT (Push-to-talk), MTS (Mobile Telephone System), IMTS (Improved Mobile Telephone System), AMTS (Advanced Mobile Telephone System), OLT (Norwegisch für Offentlig Landmobil Telefoni, öffentliche, landgestützte mobile Telefonie), MTD (schwedische Abkürzung für Mobiltelefonisystem D oder Mobiltelefoniesystem 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 and Telephone)), 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 3GPP Generic Access Network oder GAN-Standard genannt), den Standard Wireless Gigabit Alliance (WiGig), die mmWave-Standards im Allgemeinen (Funksysteme, die bei 10-90 GHz und mehr betrieben werden, etwa WiGig, IEEE 802.11ad, IEEE 802.11ay) und dergleichen. Außer den oben aufgeführten Standards können beliebig viele Satelliten-Uplink-Technologien für den Uplink-Transceiver 1314 genutzt werden, auch zum Beispiel unter anderem Funkelemente, die mit von der ITU (International Telecommunication Union) oder dem ETSI (European Telecommunications Standards Institute) veröffentlichten Standards konform sind. Es ist mithin davon auszugehen, dass die hierin angeführten Beispiele auch auf verschiedene andere sowohl bereits bestehende als auch noch nicht formulierte Kommunikationstechniken anwendbar sind.
  • Es kann ein Network Interface Controller (NIC) 1316 zur Bereitstellung einer kabelgebundenen Kommunikation in der Cloud 302 oder anderen Einrichtungen wie den Mesh-Einrichtungen 1312 enthalten sein. Die kabelgebundene Kommunikation kann eine Ethernet-Verbindung bereitstellen oder auf anderen Arten von Netzen wie einem Controller Area Network (CAN), einem Local Interconnect Network (LIN), einem DeviceNet-, einem ControlNet-, einem Data-Highway+-, einem EtherCAT-, einem SERCOS-, einem PROFIBUS-, einem PROFINET-RT- oder einem PROFINET-IRT-Netz und vielen anderen mehr basieren. Es kann noch ein weiterer NIC 1316 enthalten sein, durch den die Verbindung zu einem zweiten Netz hergestellt werden kann, zum Beispiel ein NIC 1316, der Kommunikationen über Ethernet für die Cloud bereitstellt, und ein zweiter NIC 1316, der Kommunikationen über ein Netz einer anderen Art für andere Einrichtungen bereitstellt.
  • Der Bus 1306 kann den Prozessor 1302 an eine zum Verbinden externer Einrichtungen genutzte Schnittstelle 1318 koppeln. Die externen Einrichtungen enthalten möglicherweise Sensoren 1320 wie Beschleunigungsmesser, Füllstandssensoren, Durchflusssensoren, Temperaturfühler, Druckaufnehmer, Luftdruckfühler und dergleichen. Die Schnittstelle 1318 kann dazu genutzt werden, um die IoT-Einrichtung 1300 mit Aktoren 1322 wie Netzschaltern, Ventilstellantrieben, einem Schallerzeuger, einer optischen Warneinrichtung und dergleichen zu verbinden.
  • Auch wenn dies nicht gezeigt wird, können verschiedene Ein-/Ausgabe(E/A)-Einrichtungen, innerhalb der IoT-Einrichtung 1300 vorhanden oder mit ihr verbunden sein. Es kann zum Beispiel ein Display zum Anzeigen von Informationen wie Sensormesswerten oder Aktorstellungen enthalten sein. Es kann ein Eingabegerät wie ein Touchscreen oder ein Tastenfeld zum Annehmen von Eingaben enthalten sein.
  • Eine Batterie 1324 kann die IoT-Einrichtung 1300 mit Strom versorgen, jedoch kann in Beispielen, in denen die IoT-Einrichtung 1300 fest montiert ist, auch eine an ein Stromnetz gekoppelte Stromquelle vorhanden sein. Die Batterie 1324 ist möglicherweise eine Lithium-Ionen-Batterie, eine Metall-Luft-Batterie, etwa eine Zink-Luft-Batterie, eine Aluminium-Luft-Batterie, eine Lithium-Luft-Batterie, ein Hybrid-Superkondensator oder dergleichen.
  • In der IoT-Einrichtung 1300 kann ein Batteriemonitor-/-ladegerät 1326 zum Kontrollieren des Ladezustands (State of Charge, SoCh) der Batterie 1320 enthalten sein. Das Batteriemonitor-/-ladegerät 1326 kann zum Überwachen von noch anderen Parametern der Batterie 1324 genutzt werden, um anhand des Alterungszustands (State of Health, SoH) und der Leistungsfähigkeit (State of Function, SoF) der Batterie 1324 Fehler vorhersagen zu können. Das Batteriemonitor/-ladegerät 1326 kann einen integrierten Batterieüberwachungsschaltkreis wie einen LTC4020 oder einen LTC2990 von Linear Technologies, einen ADT7488A von ON Semiconductor aus Phoenix, Arizona oder einen IC aus der UCD90xxx-Produktfamilie von Texas Instruments aus Dallas, TX enthalten. Das Batteriemonitor-/ -ladegerät 1326 kann die Informationen zur Batterie 1324 über den Bus 1306 an den Prozessor 1302 kommunizieren. Das Batteriemonitor-/-ladegerät 1326 enthält möglicherweise auch einen Analog-DigitalWandler (A/D-Wandler), dank dem der Prozessor 1302 die Spannung der Batterie 1326 oder den Stromfluss aus der Batterie 1324 direkt überwachen kann. Die Batterieparameter wie die Übertragungsfrequenz, der Mesh-Netzbetrieb, die Messfrequenz und dergleichen können zur Festlegung der von der IoT-Einrichtung 1300 durchführbaren Vorgänge dienen.
  • Ein Leistungsblock 1328 oder eine andere an ein Netz gekoppelte Stromquelle kann für Aufladungen der Batterie 1324 mit dem Batteriemonitor-/-ladegerät 1326 gekoppelt sein. In manchen Beispielen kann der Leistungsblock 1328 durch einen drahtlosen Stromempfänger ersetzt sein, sodass der Strom drahtlos, zum Beispiel über eine Rahmenantenne in der IoT-Einrichtung 1300, erhalten wird. Im Batteriemonitor-/ -ladegerät 1326 kann eine Schaltung zum kabellosen Aufladen von Batterien wie unter anderem ein LTC4020-Chip von Linear Technologies aus Milpitas, CA enthalten sein. Welche speziellen Ladeschaltungen gewählt werden, ist abhängig von der Größe der Batterie 1324 und mithin vom benötigten Strom. Die Aufladung kann unter anderem gemäß dem von der Airfuel Alliance veröffentlichten Airfuel-Standard, dem vom Wireless Power Consortium veröffentlichten Qi-Standard für kabellose Aufladung oder dem von der Alliance for Wireless Power veröffentlichten Rezence-Aufladungsstandard durchgeführt werden. In manchen Beispielen ist der Leistungsblock 1328 erweiterbar oder lässt sich durch Solarpaneele, ein Element zur Stromerzeugung aus Wind, ein Element zur Stromerzeugung aus Wasser oder andere Systeme zur ökologischen Stromerzeugung ersetzen.
  • Der Massenspeicher 1308 kann etliche Module zur Implementierung eines oder mehrerer der folgenden Vorgänge enthalten: IoT-Einrichtungsadressierung, Alias/Shortcode-Adressierung, aliasbasierte, zeitlich begrenzte Adressierung, Lease-Adressierung, Zuordnung, Übersetzung oder beliebige andere der hierin beschriebenen Techniken. Auch wenn Module als Codeblöcke im Massenspeicher 1308 gezeigt sind, versteht es sich, dass beliebige dieser Module auch ganz oder teilweise durch festverdrahtete Schaltungen ersetzt und zum Beispiel in einen anwendungsspezifischen integrierten Schaltkreis (ASIC) eingebaut werden können. Der Massenspeicher 1308 kann eine Alias/Shortcode-Adressierung 1330 gemäß manchen Ausführungsformen enthalten. Die Adressierung 1330 kann Code zum Implementieren von beliebigen der hierin beschriebenen Techniken enthalten. In manchen Ausführungsformen kann die IoT-Einrichtung 1300 ein System oder ein Untersystem zum Implementieren von beliebigen der hierin beschriebenen Techniken enthalten. Zum Beispiel kann die IoT-Einrichtung in manchen Ausführungsformen ein System oder ein Untersystem wie das zeitlich begrenzte Alias-Adressierungsuntersystem 580 gemäß 5 sein oder enthalten.
  • Die hierin veranschaulichten und beschriebenen Beispiele und Ausführungsformen der verschiedenen Techniken sind zum Beispiel unter Nutzung eines Prozessors, der gespeicherte Befehle ausführt, implementierbar. Es wird jedoch darauf hingewiesen, dass andere Beispiele und Ausführungsformen von beliebigen dieser Techniken noch weitere Implementierungen enthalten können. Zum Beispiel lassen sich beliebige der hierin veranschaulichten oder beschriebenen Techniken in Hardware, Software, Firmware oder beliebigen Kombinationen davon implementieren. Manche Ausführungsformen lassen sich zum Beispiel unter anderem unter Nutzung eines anwendungsspezifischen integrierten Schaltkreises oder eines Field Programmable Gate Array (FPGA) implementieren.
  • 14 ist ein Blockschema eines beispielhaften nichttransienten Mediums/beispielhafter nichttransienter Medien 1400 (zum Beispiel eines oder mehrerer computerlesbarer Medien 1400 oder eines oder mehrerer maschinenlesbarer Medien 1400), das/die Code zum Anweisen eines oder mehrerer Prozessoren 1402 zum Implementieren einer Datenfragmentierung und/oder einer Datenrekombination gemäß manchen Ausführungsformen enthält/enthalten. Der Prozessor (die Prozessoren) 1402 kann (können) über einen Bus 1404 auf das nichttransiente, maschinenlesbare Medium 1400 zugreifen. Der Prozessor (die Prozessoren) 1402 und der Bus 1404 kann (können) so ausgewählt werden, wie im Zusammenhang mit dem Prozessor 1302 und dem Bus 1306 gemäß 13 beschrieben wurde. Das Medium 1400 bzw. die Medien 1400 kann bzw. können ein oder mehrere der für den Massenspeicher 1308 gemäß 13 beschriebenen Elemente oder optische Speicherplatten, Speichersticks oder beliebig viele andere Hardwareelemente enthalten.
  • Das Medium bzw. die Medien 1400 kann bzw. können Code zum Anweisen des Prozessors (der Prozessoren) 1402 zum Implementieren einer Datenfragmentierung und/oder einer Datenrekombination oder beliebiger sonstiger hierin beschriebener Techniken enthalten. Zum Beispiel enthält bzw. enthalten das Medium bzw. die Medien 1400 in manchen Ausführungsformen möglicherweise Code 1406 zum Anweisen des Prozessors (der Prozessoren) 1402 zum Implementieren einer Datenfragmentierung. In manchen Ausführungsformen enthält bzw. enthalten das Medium bzw. die Medien 1400 möglicherweise Code 1408 zum Anweisen des Prozessors (der Prozessoren) 1402 zum Implementieren einer Datenrekombination.
  • Die Techniken, die hierin beschrieben werden, können zum Implementieren beliebig vieler IoT-Netze für verschiedene Zwecke genutzt werden. Es können noch weitere Anwendungen implementiert werden.
  • Beispiel 1 enthält eine Internet-of-Things (IoT)-Einrichtung, um Datenfragmente von Nutzdaten zu rekombinieren. Die IoT-Einrichtung enthält einen Speicher, um Befehle zu speichern, und einen Prozessor, um die gespeicherten Befehle auszuführen, um die Datenfragmente in einer Reihenfolge oder nicht in einer Reihenfolge zu empfangen, um zu ermitteln, ob alle Datenfragmente der Nutzdaten empfangen worden sind, und, wenn alle Datenfragmente der Nutzdaten empfangen worden sind, die Datenfragmente in einer Reihenfolge zu speichern.
  • Beispiel 2 enthält den Gegenstand des Beispiels 1. Im Beispiel 2 ist der Prozessor dazu vorgesehen, die gespeicherten Befehle auszuführen, um zu ermitteln, ob ein empfangenes Datenfragment das erste empfangene Datenfragment der Nutzdaten ist, um ein Teilobjekt für die Nutzdaten zu erzeugen, wenn das empfangene Datenfragment das erste empfangene Datenfragment der Nutzdaten ist, und das empfangene Datenfragment zum Teilobjekt für die Nutzdaten hinzuzufügen, wenn das empfangene Datenfragment nicht das erste empfangene Datenfragment der Nutzdaten ist.
  • Beispiel 3 enthält den Gegenstand eines der Beispiele 1-2. Im Beispiel 3 ist der Prozessor dazu vorgesehen, die gespeicherten Befehle auszuführen, um zu ermitteln, ob ein empfangenes Datenfragment das erste empfangene Datenfragment der Nutzdaten ist, und einen Time-To-Live-Timer auszuführen, wenn das empfangene Datenfragment das erste empfangene Datenfragment der Nutzdaten ist.
  • Beispiel 4 enthält den Gegenstand eines der Beispiele 1-3. Im Beispiel 4 ist der Prozessor dazu vorgesehen, die gespeicherten Befehle auszuführen, um zu ermitteln, ob eine Zeit des Time-To-Live-Timers abgelaufen ist, um zu ermitteln, ob alle Datenfragmente empfangen worden sind, und zu identifizieren, dass der Empfang der Nutzdaten ein Fehler ist, wenn die Zeit des Time-To-Live-Timers abgelaufen ist und nicht alle Datenfragmente empfangen worden sind.
  • Beispiel 5 enthält den Gegenstand eines der Beispiele 1-4. Im Beispiel 5 ist der Prozessor dazu vorgesehen, die gespeicherten Befehle auszuführen, um eine erneute Übertragung eines oder mehrerer Fragmente der Nutzdaten anzufordern, wenn die Zeit des Time-To-Live-Timers abgelaufen ist.
  • Beispiel 6 enthält den Gegenstand eines der Beispiele 1-5. Im Beispiel 6 ist der Prozessor dazu vorgesehen, die gespeicherten Befehle auszuführen, um zu ermitteln, ob ein empfangenes Datenfragment das erste empfangene Datenfragment der Nutzdaten ist, und das empfangene Datenfragment zu einem vorhandenen Teilagenten hinzuzufügen, wenn das empfangene Datenfragment nicht das erste empfangene Datenfragment der Nutzdaten ist.
  • Beispiel 7 enthält den Gegenstand eines der Beispiele 1-6. Im Beispiel 7 ist der Prozessor dazu vorgesehen, die gespeicherten Befehle auszuführen, um zu ermitteln, ob alle Datenfragmente empfangen worden sind, und eine Integrität der Nutzdaten zu verifizieren, wenn alle Datenfragmente der Nutzdaten empfangen worden sind.
  • Beispiel 8 enthält den Gegenstand eines der Beispiele 1-7. Im Beispiel 8 ist der Prozessor dazu vorgesehen, die gespeicherten Befehle auszuführen, um einen Teilobjektagenten zu zerstören, nachdem die Nutzdaten gespeichert worden sind oder nachdem ein Fehler bei der Übertragung der Nutzdaten ermittelt worden ist.
  • Beispiel 9 enthält ein Verfahren zum Rekombinieren empfangener Datenfragmente von Nutzdaten in einem Internet-of-Things(IoT)-Netz. Das Verfahren enthält Empfangen der Datenfragmente in einer Reihenfolge oder nicht in einer Reihenfolge, Ermitteln, ob alle Datenfragmente der Nutzdaten empfangen worden sind, und, wenn alle Datenfragmente der Nutzdaten empfangen worden sind, Speichern der Datenfragmente in einer Reihenfolge.
  • Beispiel 10 enthält den Gegenstand des Beispiels 9. Im Beispiel 10 enthält das Verfahren Ermitteln, ob ein empfangenes Datenfragment das erste empfangene Datenfragment der Nutzdaten ist, Erzeugen eines Teilobjekts für die Nutzdaten, wenn das empfangene Datenfragment das erste empfangene Datenfragment der Nutzdaten ist, und Hinzufügen des empfangenen Datenfragments zum Teilobjekt für die Nutzdaten, wenn das empfangene Datenfragment nicht das erste empfangene Datenfragment der Nutzdaten ist.
  • Beispiel 11 enthält den Gegenstand eines der Beispiele 9-10. Im Beispiel 11 enthält das Verfahren Ermitteln, ob ein empfangenes Datenfragment das erste empfangene Datenfragment der Nutzdaten ist, und Erzeugen eines Time-To-Live-Timers, wenn das empfangene Datenfragment das erste empfangene Datenfragment der Nutzdaten ist.
  • Beispiel 12 enthält den Gegenstand eines der Beispiele 9-11. Im Beispiel 12 enthält das Verfahren Ermitteln, ob eine Zeit des Time-To-Live-Timers abgelaufen ist, Ermitteln, ob alle Datenfragmente empfangen worden sind, und Identifizieren, dass der Empfang der Nutzdaten ein Fehler ist, wenn die Zeit des Time-To-Live-Timers abgelaufen ist und nicht alle Datenfragmente empfangen worden sind.
  • Beispiel 13 enthält den Gegenstand eines der Beispiele 9-12. Im Beispiel 13 enthält das Verfahren Anfordern einer erneuten Übertragung eines oder mehrerer Fragmente der Nutzdaten, wenn die Zeit des Time-To-Live-Timers abgelaufen ist.
  • Beispiel 14 enthält den Gegenstand eines der Beispiele 9-13. Im Beispiel 14 enthält das Verfahren Ermitteln, ob ein empfangenes Datenfragment das erste empfangene Datenfragment der Nutzdaten ist, und Hinzufügen des empfangenen Datenfragments zu einem vorhandenen Teilagenten, wenn das empfangene Datenfragment nicht das erste empfangene Datenfragment der Nutzdaten ist.
  • Beispiel 15 enthält den Gegenstand eines der Beispiele 9-14. Im Beispiel 15 enthält das Verfahren Verifizieren einer Integrität der Nutzdaten, wenn alle Datenfragmente der Nutzdaten empfangen worden sind.
  • Beispiel 16 enthält den Gegenstand eines der Beispiele 9-15. Im Beispiel 16 enthält das Verfahren Zerstören eines Teilobjektagenten, nachdem die Nutzdaten gespeichert worden sind oder nachdem ein Fehler bei der Übertragung der Nutzdaten ermittelt worden ist.
  • Beispiel 17 enthält ein Internet-of-Things(IoT)-System. Das IoT-System enthält eine erste IoT-Einrichtung, um Nutzdaten zu Datenfragmenten zu fragmentieren und die Datenfragmente zu übertragen, und eine zweite IoT-Einrichtung, um die Datenfragmente zu rekombinieren. Die zweite IoT-Einrichtung enthält einen Speicher, um Befehle zu speichern, und einen Prozessor, um die gespeicherten Befehle auszuführen, um die Datenfragmente in einer Reihenfolge oder nicht in einer Reihenfolge zu empfangen, um zu ermitteln, ob alle Datenfragmente der Nutzdaten empfangen worden sind, und, wenn alle Datenfragmente der Nutzdaten empfangen worden sind, die Datenfragmente in einer Reihenfolge zu speichern.
  • Beispiel 18 enthält den Gegenstand des Beispiels 17. Im Beispiel 18 ist der Prozessor dazu vorgesehen, die gespeicherten Befehle auszuführen, um zu ermitteln, ob ein empfangenes Datenfragment das erste empfangene Datenfragment der Nutzdaten ist, um ein Teilobjekt für die Nutzdaten zu erzeugen, wenn das empfangene Datenfragment das erste empfangene Datenfragment der Nutzdaten ist, und das empfangene Datenfragment zum Teilobjekt für die Nutzdaten hinzuzufügen, wenn das empfangene Datenfragment nicht das erste empfangene Datenfragment der Nutzdaten ist.
  • Beispiel 19 enthält den Gegenstand eines der Beispiele 17-18. Im Beispiel 19 ist der Prozessor dazu vorgesehen, die gespeicherten Befehle auszuführen, um zu ermitteln, ob ein empfangenes Datenfragment das erste empfangene Datenfragment der Nutzdaten ist, und einen Time-To-Live-Timer zu erzeugen, wenn das empfangene Datenfragment das erste empfangene Datenfragment der Nutzdaten ist.
  • Beispiel 20 enthält den Gegenstand eines der Beispiele 17-19. Im Beispiel 20 ist der Prozessor dazu vorgesehen, die gespeicherten Befehle auszuführen, um zu ermitteln, ob eine Zeit des Time-To-Live-Timers abgelaufen ist, und zu identifizieren, dass der Empfang der Nutzdaten ein Fehler ist, wenn die Zeit des Time-To-Live-Timers abgelaufen ist.
  • Beispiel 21 enthält den Gegenstand eines der Beispiele 17-20. Im Beispiel 21 ist der Prozessor dazu vorgesehen, die gespeicherten Befehle auszuführen, um eine erneute Übertragung eines oder mehrerer Fragmente der Nutzdaten anzufordern, wenn die Zeit des Time-To-Live-Timers abgelaufen ist.
  • Beispiel 22 enthält den Gegenstand eines der Beispiele 17-21. Im Beispiel 22 ist der Prozessor dazu vorgesehen, die gespeicherten Befehle auszuführen, um zu ermitteln, ob ein empfangenes Datenfragment das erste empfangene Datenfragment der Nutzdaten ist, und das empfangene Datenfragment zu einem vorhandenen Teilagenten hinzuzufügen, wenn das empfangene Datenfragment nicht das erste empfangene Datenfragment der Nutzdaten ist.
  • Beispiel 23 enthält den Gegenstand eines der Beispiele 17-22. Im Beispiel 23 ist der Prozessor dazu vorgesehen, die gespeicherten Befehle auszuführen, um eine Integrität der Nutzdaten zu verifizieren, wenn alle Datenfragmente der Nutzdaten empfangen worden sind.
  • Beispiel 24 enthält den Gegenstand eines der Beispiele 17-23. Im Beispiel 24 ist der Prozessor dazu vorgesehen, die gespeicherten Befehle auszuführen, um einen Teilobjektagenten zu zerstören, nachdem die Nutzdaten gespeichert worden sind oder nachdem ein Fehler bei der Übertragung der Nutzdaten ermittelt worden ist.
  • Beispiel 25 enthält ein nichttransientes, computerlesbares Medium zum Rekombinieren von Datenfragmenten von Internet-of-Things(IoT)-Nutzdaten. Das computerlesbare Medium enthält Befehle, die, wenn sie ausgeführt werden, einen Prozessor zum Empfangen der Datenfragmente in einer Reihenfolge oder nicht in einer Reihenfolge, zum Ermitteln, ob alle Datenfragmente der Nutzdaten empfangen worden sind, und, wenn alle Datenfragmente der Nutzdaten empfangen worden sind, zum Speichern der Datenfragmente in einer Reihenfolge anweisen.
  • Beispiel 26 enthält den Gegenstand des Beispiels 25. Im Beispiel 26 enthält das computerlesbare Medium Befehle, die, wenn sie ausgeführt werden, einen Prozessor zum Ermitteln, ob ein empfangenes Datenfragment das erste empfangene Datenfragment der Nutzdaten ist, zum Erzeugen eines Teilobjekts für die Nutzdaten, wenn das empfangene Datenfragment das erste empfangene Datenfragment der Nutzdaten ist, und zum Hinzufügen des empfangenen Datenfragments zum Teilobjekt für die Nutzdaten, wenn das empfangene Datenfragment nicht das erste empfangene Datenfragment der Nutzdaten ist, anweisen.
  • Beispiel 27 enthält den Gegenstand eines der Beispiele 25-26. Im Beispiel 27 enthält das computerlesbare Medium Befehle, die, wenn sie ausgeführt werden, einen Prozessor zum Ermitteln, ob ein empfangenes Datenfragment das erste empfangene Datenfragment der Nutzdaten ist, und zum Erzeugen eines Time-To-Live-Timers, wenn das empfangene Datenfragment das erste empfangene Datenfragment der Nutzdaten ist, anweisen.
  • Beispiel 28 enthält den Gegenstand eines der Beispiele 25-27. Im Beispiel 28 enthält das computerlesbare Medium Befehle, die, wenn sie ausgeführt werden, einen Prozessor zum Ermitteln, ob eine Zeit des Time-To-Live-Timers abgelaufen ist, und zum Identifizieren, dass der Empfang der Nutzdaten ein Fehler ist, wenn die Zeit des Time-To-Live-Timers abgelaufen ist, anweisen.
  • Beispiel 29 enthält den Gegenstand eines der Beispiele 25-28. Im Beispiel 29 enthält das computerlesbare Medium Befehle, die, wenn sie ausgeführt werden, einen Prozessor zum Anfordern einer erneuten Übertragung eines oder mehrerer Fragmente der Nutzdaten, wenn die Zeit des Time-To-Live-Timers abgelaufen ist, anweisen.
  • Beispiel 30 enthält den Gegenstand eines der Beispiele 25-29. Im Beispiel 30 enthält das computerlesbare Medium Befehle, die, wenn sie ausgeführt werden, einen Prozessor zum Ermitteln, ob ein empfangenes Datenfragment das erste empfangene Datenfragment der Nutzdaten ist, und zum Hinzufügen des empfangenen Datenfragments zu einem vorhandenen Teilagenten, wenn das empfangene Datenfragment nicht das erste empfangene Datenfragment der Nutzdaten ist, anweisen.
  • Beispiel 31 enthält den Gegenstand eines der Beispiele 25-30. Im Beispiel 31 enthält das computerlesbare Medium Befehle, die, wenn sie ausgeführt werden, einen Prozessor zum Verifizieren einer Integrität der Nutzdaten, wenn alle Datenfragmente der Nutzdaten empfangen worden sind, anweisen.
  • Beispiel 32 enthält den Gegenstand eines der Beispiele 25-31. Im Beispiel 32 enthält das computerlesbare Medium Befehle, die, wenn sie ausgeführt werden, einen Prozessor zum Zerstören eines Teilobjektagenten, nachdem die Nutzdaten gespeichert worden sind oder nachdem ein Fehler bei der Übertragung der Nutzdaten ermittelt worden ist, anweisen.
  • Beispiel 33 enthält den Gegenstand eines der Beispiele 1-8. Im Beispiel 33 enthält jedes Datenfragment eine Angabe des Datentyps der Nutzdaten, eine eindeutige Kennung einer Nutzdatenabsendereinrichtung, eine eindeutige ID der Nutzdaten, eine eindeutige ID des Datenfragments, einen Zeitstempel einer Aufzeichnung der Nutzdaten und eine Anzahl von Datenfragmenten der Nutzdaten.
  • Beispiel 34 enthält den Gegenstand eines der Beispiele 1-8 oder 33. Im Beispiel 34 ist der Prozessor dazu vorgesehen, die gespeicherten Befehle auszuführen, um
    zu ermitteln, ob ein empfangenes Datenfragment ein letztes empfangenes Datenfragment der Nutzdaten ist; und
    ein Teilobjekt für die Nutzdaten zu zerstören, wenn das empfangene Datenfragment das letzte empfangene Datenfragment der Nutzdaten ist.
  • Beispiel 35 enthält den Gegenstand eines der Beispiele 1-8, 33 oder 34. Im Beispiel 35 ist der Prozessor dazu vorgesehen, die gespeicherten Befehle auszuführen, um
    zu ermitteln, ob ein empfangenes Datenfragment ein letztes empfangenes Datenfragment der Nutzdaten ist; und
    einen Time-To-Live-Timer zu zerstören, wenn das empfangene Datenfragment das letzte empfangene Datenfragment der Nutzdaten ist.
  • Beispiel 36 enthält den Gegenstand eines der Beispiele 9-16. Im Beispiel 36 enthält jedes Datenfragment eine Angabe des Datentyps der Nutzdaten, eine eindeutige Kennung einer Nutzdatenabsendereinrichtung, eine eindeutige ID der Nutzdaten, eine eindeutige ID des Datenfragments, einen Zeitstempel einer Aufzeichnung der Nutzdaten und eine Anzahl von Datenfragmenten der Nutzdaten.
  • Beispiel 37 enthält den Gegenstand eines der Beispiele 9-16 oder 36. Im Beispiel 37 enthält das Verfahren Ermitteln, ob ein empfangenes Datenfragment ein letztes empfangenes Datenfragment der Nutzdaten ist, und Zerstören eines Teilobjekts für die Nutzdaten, wenn das empfangene Datenfragment das letzte empfangene Datenfragment der Nutzdaten ist.
  • Beispiel 38 enthält den Gegenstand eines der Beispiele 9-16 oder 36-37. Im Beispiel 38 enthält das Verfahren Ermitteln, ob ein empfangenes Datenfragment ein letztes empfangenes Datenfragment der Nutzdaten ist, und Zerstören eines Time-To-Live-Timers, wenn das empfangene Datenfragment das letzte empfangene Datenfragment der Nutzdaten ist.
  • Beispiel 39 enthält den Gegenstand eines der Beispiele 9-16 oder 36-38. Im Beispiel 39 enthält das Verfahren Ermitteln, ob ein empfangenes Datenfragment das erste empfangene Datenfragment der Nutzdaten ist, und Erzeugen eines Time-To-Live-Timers, wenn das empfangene Datenfragment das erste empfangene Datenfragment der Nutzdaten ist.
  • Beispiel 40 enthält den Gegenstand eines der Beispiele 9-16 oder 36-39. Im Beispiel 40 enthält das Verfahren Anfordern einer erneuten Übertragung eines oder mehrerer Fragmente der Nutzdaten, wenn die Zeit des Time-To-Live-Timers abgelaufen ist.
  • Beispiel 41 enthält den Gegenstand eines der Beispiele 17-24. Im Beispiel 41 enthält jedes Datenfragment eine Angabe des Datentyps der Nutzdaten, eine eindeutige Kennung einer Nutzdatenabsendereinrichtung, eine eindeutige ID der Nutzdaten, eine eindeutige ID des Datenfragments, einen Zeitstempel einer Aufzeichnung der Nutzdaten und eine Anzahl von Datenfragmenten der Nutzdaten.
  • Beispiel 42 enthält den Gegenstand eines der Beispiele 17-24 oder 41. Im Beispiel 42 ist der Prozessor dazu vorgesehen, die gespeicherten Befehle auszuführen, um
    zu ermitteln, ob ein empfangenes Datenfragment ein letztes empfangenes Datenfragment der Nutzdaten ist; und
    ein Teilobjekt für die Nutzdaten zu zerstören, wenn das empfangene Datenfragment das letzte empfangene Datenfragment der Nutzdaten ist.
  • Beispiel 43 enthält den Gegenstand eines der Beispiele 17-24 oder 41-42. Im Beispiel 43 ist der Prozessor dazu vorgesehen, die gespeicherten Befehle auszuführen, um
    zu ermitteln, ob ein empfangenes Datenfragment ein letztes empfangenes Datenfragment der Nutzdaten ist; und
    einen Time-To-Live-Timer zu zerstören, wenn das empfangene Datenfragment das letzte empfangene Datenfragment der Nutzdaten ist.
  • Beispiel 44 enthält den Gegenstand eines der Beispiele 25-32. Im Beispiel 44 enthält jedes Datenfragment eine Angabe des Datentyps der Nutzdaten, eine eindeutige Kennung einer Nutzdatenabsendereinrichtung, eine eindeutige ID der Nutzdaten, eine eindeutige ID des Datenfragments, einen Zeitstempel einer Aufzeichnung der Nutzdaten und eine Anzahl von Datenfragmenten der Nutzdaten.
  • Beispiel 45 enthält den Gegenstand eines der Beispiele 25-32 oder 44. Im Beispiel 45 enthält das Medium Befehle, die, wenn sie ausgeführt werden, einen Prozessor zum Ermitteln, ob ein empfangenes Datenfragment ein letztes empfangenes Datenfragment der Nutzdaten ist, und zum Zerstören eines Teilobjekts für die Nutzdaten, wenn das empfangene Datenfragment das letzte empfangene Datenfragment der Nutzdaten ist, anweisen.
  • Beispiel 46 enthält den Gegenstand eines der Beispiele 25-32 oder 44-45. Im Beispiel 46 enthält das Medium Befehle, die, wenn sie ausgeführt werden, einen Prozessor zum Ermitteln, ob ein empfangenes Datenfragment ein letztes empfangenes Datenfragment der Nutzdaten ist, und zum Zerstören eines Time-To-Live-Timers, wenn das empfangene Datenfragment das letzte empfangene Datenfragment der Nutzdaten ist, anweisen.
  • Beispiel 47 enthält eine Internet-of-Things(IoT)-Einrichtung zum Übertragen von Datenfragmenten von Nutzdaten. Die IoT-Einrichtung enthält einen Speicher, um Befehle zu speichern, und einen Prozessor, um die gespeicherten Befehle auszuführen, um die Datenfragmente zu übertragen, wobei jedes Datenfragment eine Angabe des Datentyps der Nutzdaten, eine eindeutige Kennung einer Nutzdatenabsendereinrichtung, eine eindeutige ID der Nutzdaten, eine eindeutige ID des Datenfragments, einen Zeitstempel einer Aufzeichnung der Nutzdaten und eine Anzahl von Datenfragmenten der Nutzdaten enthält, und eine Angabe, ob alle Datenfragmente durch eine zweite IoT-Einrichtung empfangen worden sind, zu empfangen.
  • Beispiel 48 enthält den Gegenstand des Beispiels 47. Im Beispiel 48 ist der Prozessor dazu vorgesehen, die gespeicherten Befehle auszuführen, um eine Anforderung einer erneuten Übertragung eines oder mehrerer Fragmente der Nutzdaten zu empfangen.
  • Beispiel 49 enthält den Gegenstand eines der Beispiele 47-48. Im Beispiel 49 ist der Prozessor dazu vorgesehen, die gespeicherten Befehle auszuführen, um die Anzahl oder die Größe der Datenfragmente dynamisch anzupassen und übrige Datenfragmente basierend auf der dynamischen Anpassung zu übertragen.
  • Beispiel 50 enthält eine Vorrichtung, die Mittel zum Durchführen eines Verfahrens wie in einem beliebigen anderen Beispiel enthält.
  • Beispiel 51 enthält einen maschinenlesbaren Speicher, der maschinenlesbare Befehle, um, wenn sie ausgeführt werden, ein Verfahren wie in einem beliebigen anderen Beispiel zu implementieren oder eine Vorrichtung wie in einem beliebigen anderen Beispiel zu realisieren, enthält.
  • Manche Ausführungsformen können in Hardware oder Firmware oder Software oder einer Kombination von Hardware, Firmware und Software implementiert sein. Manche Ausführungsformen lassen sich auch als Befehle implementieren, die auf einem maschinenlesbaren Medium gespeichert sind und durch eine Computerplattform gelesen und ausgeführt werden können, um die hierin beschriebenen Vorgänge durchzuführen. Ein maschinenlesbares Medium kann einen beliebigen Mechanismus zum Speichern oder Übertragen von Informationen in einer durch eine Maschine, z. B. einen Computer, lesbaren Form enthalten. Ein maschinenlesbares Medium enthält zum Beispiel möglicherweise unter anderem Folgendes: einen Festwertspeicher (ROM); einen Arbeitsspeicher (RAM); Magnetplattenspeichermedien; optische Speichermedien; Flashspeicherelemente; oder ausgebreitete Signale in elektrischer, optischer, akustischer oder anderer Form, z. B. Trägerwellen, Infrarotsignale, digitale Signale oder die Schnittstellen, die Signale senden und/oder empfangen.
  • Eine Ausführungsform ist eine Implementierung oder ein Beispiel. Wird in der Patentbeschreibung auf „eine Ausführungsform“, „manche Ausführungsformen“, „verschiedene Ausführungsformen“ oder „andere Ausführungsformen“ Bezug genommen, bedeutet dies, dass ein bestimmtes Merkmal, eine bestimmte Struktur oder eine bestimmte Eigenschaft, das/die im Zusammenhang mit den Ausführungsformen beschrieben wird, in mindestens manchen Ausführungsformen der Techniken, jedoch nicht zwangsläufig in allen von ihnen enthalten ist. Wird an verschiedenen Stellen auf „eine Ausführungsform“ oder „manche Ausführungsformen“ eingegangen, wird damit nicht immer zwangsläufig auf dieselbe Ausführungsform Bezug genommen. Die Elemente oder Ausgestaltungen einer Ausführungsform sind mit den Elementen oder Ausgestaltungen anderer Ausführungsformen kombinierbar.
  • Es müssen nicht alle der hierin beschriebenen und veranschaulichten Komponenten, Merkmale, Strukturen, Eigenschaften etc. in einer jeweiligen Ausführungsform bzw. in jeweiligen Ausführungsformen enthalten sein. Wenn in der Patentbeschreibung steht, dass zum Beispiel eine Komponente, ein Merkmal, eine Struktur oder eine Eigenschaft enthalten sein „kann“ oder „könnte“ bzw. „möglicherweise“ oder „eventuell“ enthalten ist, muss jedoch die betreffende Komponente, das betreffende Merkmal, die betreffende Struktur bzw. die betreffende Eigenschaft nicht unbedingt enthalten sein. Wenn in der Patentbeschreibung oder einem Anspruch auf „ein“ Element Bezug genommen wird, bedeutet dies nicht, dass unbedingt nur ein solches Element vorhanden ist. Wenn in der Patentbeschreibung oder Ansprüchen auf „ein weiteres“ Element Bezug genommen wird, wird dadurch nicht ausgeschlossen, dass auch mehr als ein solches weiteres Element vorhanden sein kann.
  • Es sei angemerkt, dass einige Ausführungsformen zwar in Bezug auf konkrete Implementierungen beschrieben wurden, dass aber auch noch andere Implementierungen gemäß manchen Ausführungsformen möglich sind. Außerdem müssen die Anordnung und/oder die Reihenfolge von Schaltungselementen oder anderen Merkmalen, die in den Zeichnungen veranschaulicht und/oder hierin beschrieben sind, nicht genau so sein, wie sie veranschaulicht und beschrieben werden. Es sind noch viele weitere Anordnungen gemäß manchen Ausführungsformen möglich.
  • In jedem System, das in einer Figur gezeigt ist, können die Elemente in manchen Fällen je mit demselben Bezugszeichen oder mit unterschiedlichen Bezugszeichen versehen sein, um darauf hinzuweisen, dass es sich bei den dargestellten Elementen auch um andere und/oder ähnliche Elemente handeln könnte. Jedoch kann ein Element auch derart anpassbar sein, dass es unterschiedlich implementierbar und mit manchen oder allen der hierin gezeigten oder beschriebenen Systeme kompatibel ist. Die verschiedenen Elemente, die in den Figuren gezeigt sind, können gleich oder unterschiedlich sein. Welches von ihnen dabei erstes und welches zweites Element genannt wird, ist willkürlich.
  • Die Techniken sind nicht auf die konkreten, hierin aufgeführten Einzelheiten beschränkt. Der Fachmann erkennt nämlich unter Heranziehung dieser Offenbarung noch viele weitere mögliche Abwandlungen der obigen Beschreibung und der Zeichnungen, die im Schutzbereich der Techniken der vorliegenden Erfindung liegen. Dementsprechend wird der Schutzbereich der Techniken von den folgenden Ansprüchen sowie eventuellen an ihnen vorgenommenen Änderungen definiert.

Claims (25)

  1. Internet-of-Things(IoT)-Einrichtung zum Rekombinieren von Datenfragmenten von Nutzdaten, umfassend: einen Speicher, um Befehle zu speichern; und einen Prozessor, um die gespeicherten Befehle auszuführen, um die Datenfragmente in einer Reihenfolge oder nicht in einer Reihenfolge zu empfangen; zu ermitteln, ob alle Datenfragmente der Nutzdaten empfangen worden sind; und, wenn alle Datenfragmente der Nutzdaten empfangen worden sind, die Datenfragmente in einer Reihenfolge zu speichern.
  2. IoT-Einrichtung nach Anspruch 1, wobei der Prozessor dazu vorgesehen ist, die gespeicherten Befehle auszuführen, um zu ermitteln, ob ein empfangenes Datenfragment das erste empfangene Datenfragment der Nutzdaten ist; und einen Time-To-Live-Timer zu erzeugen, wenn das empfangene Datenfragment das erste empfangene Datenfragment der Nutzdaten ist.
  3. IoT-Einrichtung nach Anspruch 2, wobei der Prozessor dazu vorgesehen ist, die gespeicherten Befehle auszuführen, um zu ermitteln, ob eine Zeit des Time-To-Live-Timers abgelaufen ist; und zu identifizieren, dass der Empfang der Nutzdaten ein Fehler ist, wenn die Zeit des Time-To-Live-Timers abgelaufen ist.
  4. IoT-Einrichtung nach Anspruch 3, wobei der Prozessor dazu vorgesehen ist, die gespeicherten Befehle auszuführen, um eine erneute Übertragung eines oder mehrerer Fragmente der Nutzdaten anzufordern, wenn die Zeit des Time-To-Live-Timers abgelaufen ist.
  5. IoT-Einrichtung nach Anspruch 1, wobei der Prozessor dazu vorgesehen ist, die gespeicherten Befehle auszuführen, um zu ermitteln, ob ein empfangenes Datenfragment das erste empfangene Datenfragment der Nutzdaten ist; und das empfangene Datenfragment zu einem vorhandenen Teilbildagenten hinzuzufügen, wenn das empfangene Datenfragment nicht das erste empfangene Datenfragment der Nutzdaten ist.
  6. IoT-Einrichtung nach Anspruch 1, wobei der Prozessor dazu vorgesehen ist, die gespeicherten Befehle auszuführen, um eine Integrität der Nutzdaten zu verifizieren, wenn alle Datenfragmente der Nutzdaten empfangen worden sind.
  7. IoT-Einrichtung nach Anspruch 1, wobei der Prozessor dazu vorgesehen ist, die gespeicherten Befehle auszuführen, um einen Teilobjektagenten zu zerstören, nachdem die Nutzdaten gespeichert worden sind oder nachdem ein Fehler bei der Übertragung der Nutzdaten ermittelt worden ist.
  8. IoT-Einrichtung nach einem der Ansprüche 1-7, wobei der Prozessor dazu vorgesehen ist, die gespeicherten Befehle auszuführen, um zu ermitteln, ob ein empfangenes Datenfragment das erste empfangene Datenfragment der Nutzdaten ist; ein Teilobjekt für die Nutzdaten zu erzeugen, wenn das empfangene Datenfragment das erste empfangene Datenfragment der Nutzdaten ist; und das empfangene Datenfragment zum Teilobjekt für die Nutzdaten hinzuzufügen, wenn das empfangene Datenfragment nicht das erste empfangene Datenfragment der Nutzdaten ist.
  9. Verfahren zum Rekombinieren empfangener Datenfragmente von Nutzdaten in einem Internet-of-Things(IoT)-Netz, umfassend: Empfangen der Datenfragmente in einer Reihenfolge oder nicht in einer Reihenfolge; Ermitteln, ob alle Datenfragmente der Nutzdaten empfangen worden sind; und, wenn alle Datenfragmente der Nutzdaten empfangen worden sind, Speichern der Datenfragmente in einer Reihenfolge.
  10. Verfahren nach Anspruch 9, umfassend: Ermitteln, ob ein empfangenes Datenfragment das erste empfangene Datenfragment der Nutzdaten ist; Erzeugen eines Teilobjekts für die Nutzdaten, wenn das empfangene Datenfragment das erste empfangene Datenfragment der Nutzdaten ist; und Hinzufügen des empfangenen Datenfragments zum Teilobjekt für die Nutzdaten, wenn das empfangene Datenfragment nicht das erste empfangene Datenfragment der Nutzdaten ist.
  11. Internet-of-Things(IoT)-System, umfassend: eine erste IoT-Einrichtung, um Nutzdaten zu Datenfragmenten zu fragmentieren und die Datenfragmente zu übertragen; und eine zweite IoT-Einrichtung, um die Datenfragmente zu rekombinieren, wobei die zweite IoT-Einrichtung Folgendes enthält: einen Speicher, um Befehle zu speichern; und einen Prozessor, um die gespeicherten Befehle auszuführen, um die Datenfragmente in einer Reihenfolge oder nicht in einer Reihenfolge zu empfangen; zu ermitteln, ob alle Datenfragmente der Nutzdaten empfangen worden sind; und, wenn alle Datenfragmente der Nutzdaten empfangen worden sind, die Datenfragmente in einer Reihenfolge zu speichern.
  12. IoT-System nach Anspruch 11, wobei der Prozessor dazu vorgesehen ist, die gespeicherten Befehle auszuführen, um zu ermitteln, ob ein empfangenes Datenfragment das erste empfangene Datenfragment der Nutzdaten ist; und einen Time-To-Live-Timer zu erzeugen, wenn das empfangene Datenfragment das erste empfangene Datenfragment der Nutzdaten ist.
  13. IoT-System nach Anspruch 12, wobei der Prozessor dazu vorgesehen ist, die gespeicherten Befehle auszuführen, um zu ermitteln, ob eine Zeit des Time-To-Live-Timers abgelaufen ist; und zu identifizieren, dass der Empfang der Nutzdaten ein Fehler ist, wenn die Zeit des Time-To-Live-Timers abgelaufen ist.
  14. IoT-System nach Anspruch 13, wobei der Prozessor dazu vorgesehen ist, die gespeicherten Befehle auszuführen, um eine erneute Übertragung eines oder mehrerer Fragmente der Nutzdaten anzufordern, wenn die Zeit des Time-To-Live-Timers abgelaufen ist.
  15. IoT-System nach Anspruch 12, wobei der Prozessor dazu vorgesehen ist, die gespeicherten Befehle auszuführen, um zu ermitteln, ob ein empfangenes Datenfragment das erste empfangene Datenfragment der Nutzdaten ist; und das empfangene Datenfragment zu einem vorhandenen Teilbildagenten hinzuzufügen, wenn das empfangene Datenfragment nicht das erste empfangene Datenfragment der Nutzdaten ist.
  16. IoT-System nach Anspruch 12, wobei der Prozessor dazu vorgesehen ist, die gespeicherten Befehle auszuführen, um eine Integrität der Nutzdaten zu verifizieren, wenn alle Datenfragmente der Nutzdaten empfangen worden sind.
  17. IoT-System nach Anspruch 12, wobei der Prozessor dazu vorgesehen ist, die gespeicherten Befehle auszuführen, um einen Teilobjektagenten zu zerstören, nachdem die Nutzdaten gespeichert worden sind oder nachdem ein Fehler bei der Übertragung der Nutzdaten ermittelt worden ist.
  18. IoT-System nach einem der Ansprüche 12-17, wobei der Prozessor dazu vorgesehen ist, die gespeicherten Befehle auszuführen, um zu ermitteln, ob ein empfangenes Datenfragment das erste empfangene Datenfragment der Nutzdaten ist; ein Teilobjekt für die Nutzdaten zu erzeugen, wenn das empfangene Datenfragment das erste empfangene Datenfragment der Nutzdaten ist; und das empfangene Datenfragment zum Teilobjekt für die Nutzdaten hinzuzufügen, wenn das empfangene Datenfragment nicht das erste empfangene Datenfragment der Nutzdaten ist.
  19. Nichttransientes, computerlesbares Medium zum Rekombinieren von Datenfragmenten von Internet-of-Things(IoT)-Nutzdaten, umfassend Befehle, die, wenn sie ausgeführt werden, einen Prozessor zu Folgendem anweisen: Empfangen der Datenfragmente in einer Reihenfolge oder nicht in einer Reihenfolge; Ermitteln, ob alle Datenfragmente der Nutzdaten empfangen worden sind; und, wenn alle Datenfragmente der Nutzdaten empfangen worden sind, Speichern der Datenfragmente in einer Reihenfolge.
  20. Nichttransientes, computerlesbares Medium nach Anspruch 19, umfassend Befehle, die, wenn sie ausgeführt werden, einen Prozessor zu Folgendem anweisen: Ermitteln, ob ein empfangenes Datenfragment das erste empfangene Datenfragment der Nutzdaten ist; Erzeugen eines Teilobjekts für die Nutzdaten, wenn das empfangene Datenfragment das erste empfangene Datenfragment der Nutzdaten ist; und Hinzufügen des empfangenen Datenfragments zum Teilobjekt für die Nutzdaten, wenn das empfangene Datenfragment nicht das erste empfangene Datenfragment der Nutzdaten ist.
  21. Internet-of-Things(IoT)-Einrichtung zum Rekombinieren von Datenfragmenten von Nutzdaten, umfassend: Mittel zum Empfangen der Datenfragmente in einer Reihenfolge oder nicht in einer Reihenfolge; Mittel zum Ermitteln, ob alle Datenfragmente der Nutzdaten empfangen worden sind; und Mittel zum Speichern der Datenfragmente in einer Reihenfolge, wenn alle Datenfragmente der Nutzdaten empfangen worden sind.
  22. IoT-Einrichtung nach Anspruch 21, umfassend: Mittel zum Ermitteln, ob ein empfangenes Datenfragment das erste empfangene Datenfragment der Nutzdaten ist; und Mittel zum Erzeugen eines Time-To-Live-Timers, wenn das empfangene Datenfragment das erste empfangene Datenfragment der Nutzdaten ist.
  23. IoT-Einrichtung nach Anspruch 21, umfassend: Mittel zum Ermitteln, ob ein empfangenes Datenfragment das erste empfangene Datenfragment der Nutzdaten ist; und Mittel zum Hinzufügen des empfangenen Datenfragments zu einem vorhandenen Teilbildagenten, wenn das empfangene Datenfragment nicht das erste empfangene Datenfragment der Nutzdaten ist.
  24. IoT-Einrichtung nach Anspruch 21, umfassend: Mittel zum Zerstören eines Teilobjektagenten, nachdem die Nutzdaten gespeichert worden sind oder nachdem ein Fehler bei der Übertragung der Nutzdaten ermittelt worden ist.
  25. IoT-Einrichtung nach einem der Ansprüche 21-24, umfassend: Mittel zum Ermitteln, ob ein empfangenes Datenfragment das erste empfangene Datenfragment der Nutzdaten ist; Mittel zum Erzeugen eines Teilobjekts für die Nutzdaten, wenn das empfangene Datenfragment das erste empfangene Datenfragment der Nutzdaten ist; und Mittel zum Hinzufügen des empfangenen Datenfragments zum Teilobjekt für die Nutzdaten, wenn das empfangene Datenfragment nicht das erste empfangene Datenfragment der Nutzdaten ist.
DE102019103663.1A 2018-03-30 2019-02-13 Datenfragmentrekombination für Internet-of-Things-Einrichtungen Pending DE102019103663A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US15/942,400 2018-03-30
US15/942,400 US20190253477A1 (en) 2018-03-30 2018-03-30 Data Fragment Recombination for Internet of Things Devices

Publications (1)

Publication Number Publication Date
DE102019103663A1 true DE102019103663A1 (de) 2019-10-02

Family

ID=67540318

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102019103663.1A Pending DE102019103663A1 (de) 2018-03-30 2019-02-13 Datenfragmentrekombination für Internet-of-Things-Einrichtungen

Country Status (3)

Country Link
US (1) US20190253477A1 (de)
CN (1) CN110324303A (de)
DE (1) DE102019103663A1 (de)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10803025B2 (en) * 2018-09-06 2020-10-13 At&T Intellectual Property I, L.P. System and process for scalable and secure content delivery
US10841202B2 (en) * 2018-10-08 2020-11-17 Fujitsu Limited Distribution of computing resources of a radio access network
CN111143850B (zh) * 2019-11-22 2022-03-04 航天恒星科技有限公司 一种卫星数据分布式虚拟化存储的安全防护系统和方法
US11146605B2 (en) * 2020-01-21 2021-10-12 Dish Network L.L.C. Distributed data transmission for Internet of Things devices
TWI790424B (zh) * 2020-03-03 2023-01-21 宏碁通信股份有限公司 智能工業自動化數據採集裝置及物聯網架設方法
US11936664B2 (en) * 2020-03-14 2024-03-19 Microsoft Technology Licensing, Llc Identity attack detection and blocking
CN112105008B (zh) * 2020-08-21 2023-02-17 云南瀚哲科技有限公司 一种基于数据单元的LoRaWAN网关节点数据交互方法
CN113053380B (zh) * 2021-03-29 2023-12-01 海信电子科技(武汉)有限公司 服务器及语音识别方法
CN113810951B (zh) * 2021-08-31 2023-08-08 河北大学 一种基于扇形均分的LoRaWAN防碰撞方法
WO2024010764A1 (en) * 2022-07-04 2024-01-11 Morgen Technology Inc. Tunneling of short-range sensor data through long-range wireless technology
CN115835060B (zh) * 2023-02-17 2023-05-05 云南瀚哲科技有限公司 工农业物联网的数据采集方法

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006116195A1 (en) * 2005-04-21 2006-11-02 Sinett Corporation Methods and systems for fragmentation and reassembly for ip tunnels
CN101365128A (zh) * 2007-08-10 2009-02-11 中兴通讯股份有限公司 综合视频业务对等网络系统
US8320372B2 (en) * 2008-06-23 2012-11-27 Alcatel Lucent Processing of packet fragments
US8638796B2 (en) * 2008-08-22 2014-01-28 Cisco Technology, Inc. Re-ordering segments of a large number of segmented service flows
US9160697B2 (en) * 2012-01-01 2015-10-13 Qualcomm Incorporated Data delivery optimization
US9054998B2 (en) * 2013-02-06 2015-06-09 Freescale Semiconductor, Inc. System and method for maintaining packet order in an ordered data stream
US9674297B2 (en) * 2015-02-09 2017-06-06 International Business Machines Corporation Handling packet reordering at a network adapter
GB2541950B (en) * 2015-09-07 2020-01-08 Arm Ip Ltd Methods for verifying data integrity
US9961139B2 (en) * 2016-05-24 2018-05-01 International Business Machines Corporation Cooperative download among low-end devices under resource constrained environment
EP3319252A1 (de) * 2016-11-04 2018-05-09 Panasonic Intellectual Property Corporation of America Effizientes multiplexing von steuerungsinformationen in einem transportblock
CN108282273B (zh) * 2017-01-05 2024-03-08 华为技术有限公司 分段重传的方法和装置
US10602563B2 (en) * 2017-06-09 2020-03-24 Samsung Electronics Co., Ltd. Method and apparatus for supporting RLC UM mode operation in next generation mobile communication system
US20180376326A1 (en) * 2017-06-27 2018-12-27 Qualcomm Incorporated Reliable write command protocol for bluetooth le

Also Published As

Publication number Publication date
CN110324303A (zh) 2019-10-11
US20190253477A1 (en) 2019-08-15

Similar Documents

Publication Publication Date Title
DE102019103663A1 (de) Datenfragmentrekombination für Internet-of-Things-Einrichtungen
US20240205080A1 (en) DATA PACKAGING PROTOCOLS FOR COMMUNICATIONS BETWEEN IoT DEVICES
DE112017004996T5 (de) Gatewaykoordination für das Internet der Dinge
US10965537B2 (en) Self-adjusting data processing system
US11252786B2 (en) IoT networking extension with bi-directional packet relay
DE112020001183T5 (de) Multi-slice-unterstützung für mec-fähige 5g-implementierungen
US11349753B2 (en) Converged routing for distributed computing systems
DE102022211605A1 (de) Zuverlässigkeitsverbesserungen für mehrfachzugangsverkehrsverwaltung
DE112017006515T5 (de) Adaptive netztopologie
DE102020129306A1 (de) Übermittlung von paging-unterstützungsinformationen zur benachrichtigung über die anruferidentifikation (cid)
US10735346B2 (en) Data block prioritization for internet of things payloads
DE112019005933T5 (de) Verfahren zum senden/empfangen von pdb-bezogenen signalen in einem drahtlosen kommunikationssystem und vorrichtung dafür
DE112017006994T5 (de) Bereitstellung und verwaltung von microservices
DE102020122330A1 (de) Verfahren, Computerprogramme und Vorrichtungen zur Konfiguration eines Funkträgers eines Fahrzeugs um eine Car2x Kommunikation zu ermöglichen
DE112012003840T5 (de) Kommunikation von Datenframes über Kommunikationsnetzwerke hinweg, die inkompatible Netzwerk-Routingprotokolle verwenden
US11064386B2 (en) Uplink congestion mitigation
DE102022211529A1 (de) Methoden zum einreihen und neuordnen für mehrfachzugangsverwaltungsdienste
DE102015106778A1 (de) Ein Verfahren und Technisches Gerät für die Nahbereichsdatenübertragung
DE112017004201T5 (de) Vorrichtung zur prüfung der erfüllung für dienstleistungsvereinbarung
DE112020001628T5 (de) Benutzerausrüstung (ue) messfähigkeit in hochgeschwindigkeitsszenarien
CN104993979A (zh) 网络连接监测方法、终端设备及通信系统
Azzara et al. The icsi m2m middleware for iot-based intelligent transportation systems
DE102020135159A1 (de) Linkspezifische blockbestätigung für multilink-kommunikation
DE112021004175T5 (de) Datenebene für big data und daten als dienst in mobilfunknetzen der nächsten generation
dela Cruz et al. Design of a disaster information system using mobile cloud wireless mesh with delay tolerant network

Legal Events

Date Code Title Description
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0029080000

Ipc: H04L0065000000