WO2021064096A1 - Verfahren zur identifikation von netzwerkdiensten in einem netzwerk mit internet-of-things netzwerkteilnehmern - Google Patents

Verfahren zur identifikation von netzwerkdiensten in einem netzwerk mit internet-of-things netzwerkteilnehmern Download PDF

Info

Publication number
WO2021064096A1
WO2021064096A1 PCT/EP2020/077500 EP2020077500W WO2021064096A1 WO 2021064096 A1 WO2021064096 A1 WO 2021064096A1 EP 2020077500 W EP2020077500 W EP 2020077500W WO 2021064096 A1 WO2021064096 A1 WO 2021064096A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
internet
things
services
service
Prior art date
Application number
PCT/EP2020/077500
Other languages
English (en)
French (fr)
Inventor
Karsten Walther
Original Assignee
Perinet GmbH
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 Perinet GmbH filed Critical Perinet GmbH
Priority to US17/766,016 priority Critical patent/US20220368668A1/en
Priority to CN202080069297.0A priority patent/CN114503532A/zh
Priority to EP20788730.8A priority patent/EP4038863A1/de
Publication of WO2021064096A1 publication Critical patent/WO2021064096A1/de
Priority to IL291796A priority patent/IL291796A/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • 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
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4541—Directories for service discovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services

Definitions

  • the present invention relates to a method for identifying network services in a network with Internet of Things network users.
  • loT Internet of Things
  • network participants e.g. sensors and / or actuators
  • Communication between the network participants (e.g. sensors and / or actuators) and the services in the network can be based on an IP protocol, for example.
  • the search for a service in the network can take place, for example, using a Domain Name System DNS-Based Service Discovery in accordance with the IETF RFC6763 standard.
  • the loT network participants e.g. sensors / actuators
  • This object is achieved by a method for identifying services in a network with Internet-of-Things sensors / actuators according to claim 1.
  • a method for identifying network services in a network with at least one host, which provides network services with a network service identifier, is at least one Internet-of-Things sensor / actuator based on a domain Name System-Service Discovery DNS-SD according to Multicast Domain Name System mDNS provided.
  • a Domain Name System Service Discovery DNS-SD compliant request for a network service or a network service type is sent by a network participant (e.g. Internet of Things sensors / actuators) to a network with at least one host that provides network services.
  • the host itself can represent a loT device.
  • At least one Domain Name System Service Discovery DNS-SD compliant response from one of the hosts to the request is received by the sensor / actuator.
  • the reply from the hosts has a text field with a network service identifier of the network service that corresponds to the requested network service type at the application level.
  • a connection request is sent from the Internet of Things sensor / actuator to the host that offers the desired network service and whose network service identifier matches the application of the sensor / actuator. This enables a standard-compliant, simple and efficient option for the decentralized search for network services. By specifying the network service identifier in the text field, it is possible to filter according to the relevant services.
  • the network service identifier represents an identifier, an identifier of the Internet-of-Things network subscriber and / or the associated network service at the application level.
  • the identifier can be freely or essentially freely selected by the user when setting up a system become. The user thus determines the name of the network service identifier and / or the associated loT network subscriber at the application level. This allows improved addressing of the respective network service identifiers and / or the respective loT network subscribers.
  • the Domain Name System Service Discovery DNS-SD-compliant response in addition to the address information of the host, consisting of the host URL and a port number, has a service identifier at the application level in the TXT field, which is only optional according to the standard.
  • the loT sensor / actuator can automatically identify its associated service dynamically and differentiate it from other similar services in the local network.
  • the identification can take place on a static identifier at the application level without a mapping table having to be used or maintained. This enables the loT network participants, e.g.
  • loT sensors / actuators to independently identify those hosts that offer the network service required by the loT sensors / actuators and connect to them via the IP protocol so that the loT sensors send their data to the network service via the network can transmit.
  • TXT in a reply in a DNS-SD over mDNS it is indicated to which loT application a network service belongs. With this information, a remote station can dynamically find out how the network service sought, which is assigned to a loT application, can be addressed in order to enable communication.
  • the multicast domain name system mDNS optionally represents a wide-area mDNS.
  • the network services can thus also be identified in distributed local networks.
  • FIG. 2 shows a schematic representation of DNS-SD information when searching for services in a network.
  • the mDNS-SD request by means of an available mDNS user program.
  • the request is made which hosts offer the type 11 service, then the program displays a list (lines 2 and 3) with information about hosts that have responded with an announcement, including the server name ( 13a) and the domain (13b).
  • the mDNS user program is requested to display further information known from the announcement about the host found. These include the network name 13, the port number 14 and the service identifier at application level 12 (i.e. separate identifier for the respective loT network subscriber). The latter was transmitted in the TXT text field of the mDNS-SD announcement.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Medical Informatics (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • General Business, Economics & Management (AREA)

Abstract

Es wird ein Verfahren zur Identifikation von Netzwerkdiensten (210 - 230) in einem Netzwerk (300) mit mindestens einem Internet-of-Things Netzwerkteilnehmer, insbesondere Internet-of-Things Sensoren/Aktoren (100) basierend auf Domain Name System-Service Discovery DNS-SD über ein Multicast Domain Name System mDNS vorgesehen. Eine Domain Name System-Service Discovery DNS-SD konforme Anforderung (1) nach einem Netzwerkdiensttyp (11) wird von einem Internet-of-Things Netzwerkteilnehmer (100, 210, 220, 230) an ein Netzwerk (300) mit mindestens einem Host gesendet, welcher Netzwerkdienste bereitstellt. Mindestens eine Domain Name System-Service Discovery DNS-SD konforme Rückantwort (2, 3) von einem der Hosts (210 - 230) wird auf die Anforderung (1) empfangen. Die Rückantwort (2, 3) weist ein Textfeld mit einer Netzwerkdienstkennung (12) auf. Eine Verbindungsanforderung (4) wird von dem Internet-of-Things Netzwerkteilnehmer (100) an denjenigen Host (210 - 230) gesendet, dem die Netzwerkdienstkennung (12) zugeordnet ist und der den gewünschten Netzwerkdienst bereitstellt.

Description

Verfahren zur Identifikation von Netzwerkdiensten in einem Netzwerk mit Internet-of- Things Netzwerkteilnehmern
Die vorliegende Erfindung betrifft ein Verfahren zur Identifikation von Netzwerkdiensten in einem Netzwerk mit Internet-of-Things Netzwerkteilnehmern.
Im Bereich Internet-of-Things loT (Internet der Dinge) sind typischerweise Netzwerkteilnehmer (z. B. Sensoren und/oder Aktoren) über Kabel oder drahtlos mit einem Netzwerk verbunden, um eine Kommunikation mit Diensten in dem Netzwerkzu erlauben. Eine Kommunikation der Netzwerkteilnehmer (z. B. Sensoren und/oder Aktoren) und den Diensten in dem Netzwerk kann beispielsweise auf einem IP-Protokoll basieren. Die Suche nach einem Dienst in dem Netzwerk kann beispielsweise durch ein Domain Name System DNS- Based Service Discovery gemäß dem Standard IETF RFC6763 erfolgen. Die loT Netz- Werkteilnehmer (z. B. Sensoren/Aktoren) werden typischerweise derart konfiguriert, dass sie mit einem festen Netzwerkdienst kommunizieren können. Bei einer Adressänderung des Netzwerkdienstes müssen alle damit verbundenen loT Sensoren/Aktoren neu konfiguriert werden, was einen erheblichen Aufwand bei jeder Adressänderung des Netzwerkdienstes zur Folge hat. In der prioritätsbegründenden deutschen Patentanmeldung hat das Deutsche Patent- und Markenamt die folgenden Dokumente recherchiert: US 2015/0341446 A1,
US 2016/0127305 A1 und US 2015/0142968 A1.
Es ist eine Aufgabe der vorliegenden Erfindung, ein Verfahren zur Identifikation von Diensten in einem Netzwerk mit Internet-of-Things Sensoren/Aktoren vorzusehen, welches eine verbesserte und effektivere Identifikation ermöglicht.
Diese Aufgabe wird durch ein Verfahren zu Identifikation von Diensten in einem Netzwerk mit Internet-of-Things Sensoren/Aktoren gemäß Anspruch 1 gelöst.
Somit wird ein Verfahren zur Identifikation von Netzwerkdiensten in einem Netzwerk mit mindestens einem Host, welcher Netzwerkdienste jeweils mit einer Netzwerkdienstken- nung bereitstellt, mindestens einem Internet-of-Things Sensor/Aktor basierend auf Domain Name System-Service Discovery DNS-SD überein Multicast Domain Name System mDNS vorgesehen. Eine Domain Name System-Service Discovery DNS-SD konforme Anforderung nach einem Netzwerkdienst odereinem Netzwerkdiensttyp wird von einem Netzwerkteilnehmer (z.B. Internet-of-Things Sensoren/Aktoren) an ein Netzwerk mit mindestens ei- nem Host gesendet, welcher Netzwerkdienste bereitstellt. Der Host kann hierbei selbst ein loT Gerät darstellen. Mindestens eine Domain Name System-Service Discovery DNS-SD konforme Rückantwort von einem der Hosts auf die Anforderung wird von dem Sensor/Aktor empfangen. Die Rückantwort der Hosts weist ein Textfeld mit einer Netzwerkdienstkennung des Netzwerkdienstes, das dem angeforderten Netzwerkdiensttyp entspricht, auf An- wendungsebene auf. Eine Verbindungsanforderung wird von dem Internet-of-Things Sen- sor/Aktoran denjenigen Host gesendet, derden gewünschten Netzwerkdienst anbietet und dessen Netzwerkdienstkennung zu der Anwendung des Sensors/Aktors passt. Damit kann eine standardkonforme einfache und effiziente Möglichkeit der dezentralen Suche nach Netzwerkdiensten ermöglicht werden. Durch die Angabe der Netzwerkdienstkennung in dem Textfeld wird eine Filtermöglichkeit nach den relevanten Diensten ermöglicht.
Gemäß einem Aspekt der vorliegenden Erfindung stellt die Netzwerkdienstkennung einen Bezeichner, einen Bezeichner des lnternet-of-things Netzwerkteilnehmers und/oder des dazugehörigen Netzwerkdiensts auf Anwendungsebene dar. Optional kann der Bezeichner von dem Anwender beim Set-up eines Systems frei oder im Wesentlichen frei gewählt wer- den. Der Anwender bestimmt somit den Namen der Netzwerkdienstkennung und/oder des dazugehörigen loT-Netzwerkteilnehmers auf Anwendungsebene. Damit kann eine verbesserte Adressierung der jeweiligen Netzwerkdienstkennungen und/oder der jeweiligen loT- Netzwerkteilnehmer erfolgen.
Gemäß einem Aspekt der Erfindung weist die Domain Name System-Service Discovery DNS-SD konforme Rückantwort zusätzlich zu den Adressinformationen des Hosts, bestehend aus Host URL und einer Portnummer, eine Dienstkennung auf Anwendungsebene im gemäß Standard lediglich optionalen TXT Feld auf. Mit Hilfe derer kann der loT Sensor/Aktor selbstinitiiert den ihm zugehörigen Dienst dynamisch identifizieren und von anderen gleichartigen Diensten im lokalen Netz unterscheiden. Mit anderen Worten, statt ei- nersich änderbaren rein strukturellen Adresse (IP Adresse oderHostname), kann die Identifikation auf einer statischen Kennung auf Anwendungsebene erfolgen, ohne dass eine Abbildungstabelle benutzt oder gepflegt werden muss. Damit können die loT Netzwerkteilnehmer, z.B. loT Sensoren/Aktoren, eigenständig diejenigen Hosts identifizieren, die den von den loT Sensoren/Aktoren benötigten Netzwerkdienst anbieten und sich mit ihnen über das IP Protokoll verbinden, so dass die loT Sensoren ihre Daten überdas Netzwerk an den Netzwerkdienst übermitteln können. Dies führt zu einem erheblich reduzierten Konfigurationsaufwand und die loT Sensoren/Aktoren führen die Suche, die Identifikation und die Verbindung zu den Netzwerkdiensten selbstständig durch. Ermöglicht wird das durch die geeignete Anreicherung der Rückantwort des Hosts mit loT applikationsspezifischen Informationen. In dem Textfeld TXT in einer Rückantwort in einem DNS-SD over mDNS wird angegeben, zu welcher loT Applikation ein Netzwerkdienst gehört. Mit diesen Informationen kann eine Gegenstelle dynamisch in Erfahrung bringen, wie der gesuchte Netzwerkdienst, der einer loT Applikation zugeordnet ist, angesprochen werden kann, um eine Kommunikation zu ermöglichen.
Gemäß einem Aspekt der Erfindung kann eine verteilte Identifikation von zentralen Netzwerkdiensten einer verteilten loT Applikation im lokalen Netzwerk erfolgen. Hierbei erfolgt die Identifizierung des Netzwerkdienstes über einen Eintrag in einem Textfeld TXT einer mDNS-SD konformen Rückantwort. Der Eintrag in dem Textfeld kann einen Bezeichner auf Anwendungsebene aufweisen.
Gemäß einem weiteren Aspekt der Erfindung stellt das Multicast Domain Name System mDNS optional ein wide-area mDNS dar. Somit können die Netzwerkdienste auch in ver- teilten lokalen Netzwerken identifiziert werden.
Gemäß einem weiteren Aspekt der Erfindung erfolgt optional eine Adressierung der Inter- net-of-Things Sensoren/Aktoren und/oder der Hosts basierend auf IPv6 Link local Adressen. Dies führt zu einerweiteren Reduzierung des Aufwands bei der Konfiguration der loT Sensoren/Aktoren. Gemäß einem Aspekt der Erfindung können die loT Sensoren/Aktoren selbst Dienstanbieter in einer loT Anwendung sein, z.B. kann ein loT Temperatursensor einen Thermometerdienst anbieten. Somit sind loT Sensoren/Aktoren gleichzeitig Hosts. Weiterhin gibt es viele verschiedene weitere vorstellbare Dienste auf Hosts im Netzwerk, z.B. eine webbasierte Zustandsanzeige (Dashboard), welche die Daten von den loT Sensoren/Aktoren anzeigt. Das Verfahren ist dazu geeignet, jegliche lokalen loT Dienste zu identifizieren und erlaubt somit alle Kombinationen der optional auch wechselseitigen Identifikation von loT Sensoren/Aktoren und Hosts. Gemäß einem Aspekt der Erfindung können verteilte loT Netzwerkteilnehmer mittels der Anwendungskennung der Komponenten in dem Textfeld TXT der annoncierten mDNS-SD Einträge identifizieren. Hierbei können dann weitere Aktionen wie z.B. ein Software-Update oder ein Firmware-Update durchgeführt werden. Weitere Ausgestaltungen der Erfindung sind Gegenstand der Unteransprüche.
Vorteile und Ausführungsbeispiele der Erfindung werden nachstehend unter Bezugnahme auf die Zeichnung näher erläutert.
Fig. 1 zeigt eine schematische Darstellung eines Verfahrensablaufs einer Suche nach Diensten in einem Netzwerk gemäß einem ersten Ausfüh- rungsbeispiel der Erfindung, und
Fig. 2 zeigt eine schematische Darstellung von DNS-SD Informationen bei einer Suche nach Diensten in einem Netzwerk.
Die Erfindung betrifft eine Internet-of-Things (Internet der Dinge) loT Infrastruktur, in der eine Mehrzahl von loT Netzwerkteilnehmern (z.B. loT Sensoren, Aktoren, Drahtlos-Sen- der/Empfänger etc.) über ein Netzwerk (z.B. Internet oder ein lokales Netzwerk) mit anderen Komponenten wie z. B. Hosts, welche Netzwerkdienste bereitstellen, kommunizieren kann. Die Kommunikation der Sensoren, Aktoren und/oder der Drahtlos-Sender/Empfän- ger mit einem Netzwerk sowie mit Hosts in dem Netzwerk basiert auf einem IP Protokoll. Optional können loT Netzwerkteilnehmer (loT Sensoren/Aktoren und/oder Drahtlos-Sen- der/Empfänger) als Hosts fungieren. Die Suche z.B. durch den loT Netzwerkteilnehmer nach einem dazugehörigen Netzwerkdienst erfolgt mittels DNS-SD over mDNS (Domain Name System-Service Discovery über Multicast Domain Name System, siehe Standard: IETF RFC 6762). Der loT Netzwerkteilnehmer benötigt einen Netzwerkdienst, um kommunizieren zu können und Daten oder Messwerte an den Netzwerkdienst übertragen zu kön- nen. Der Netzwerkdienst wiederum dient dazu, dies zu empfangen und optional den loT- Netzwerkteilnehmer zu steuern oder ihm Befehle zu übermitteln.
Gemäß einem Aspekt der vorliegenden Erfindung können den jeweiligen loT-Netzwerkteil- nehmern bzw den dazugehörigen Netzwerkdiensten spezifische Namen bzw. eigene Bezeichner zugeordnet werden. Die Bezeichner können beispielsweise TI211-Temperatur- Kollektoreingang darstellen. Optional können die Bezeichner bzw. die Bezeichnungen oder Namen der jeweiligen loT-Netzwerkteilnehmer durch den Anwender festgelegt werden. Fig. 1 zeigt eine schematische Darstellung eines Verfahrensablaufs einer Suche nach Diensten gemäß einem ersten Ausführungsbeispiel der Erfindung. Gemäß dem ersten Ausführungsbeispiel erfolgt eine Service Discovery, d.h. eine Suche nach einem Netzwerkdienst, basierend auf mDNS. Ein loT Netzwerkteilnehmer 100 (z.B. Sensor/Aktor) sendet eine Anfrage 1 (mdns request) nach einem Netzwerkdienst eines speziellen Typs 11 in das verbundene Netzwerk 300. Mit den Netzwerk 300 sind eine Mehrzahl Hosts 210, 220, 230 verbunden, die Netzwerkdienste bereitstellen. Falls einer der Hosts 210, 220, 230 den Netzwerkdienst vom angefragten Typ 11 bereitstellt, antwortet der Host 210, 220 mit einer mDNS-SD Bekanntgabe 2, 3 (mDNS-SD announcement). Die Anfrage 1 und die Antworten 2, 3 erfolgen in einer Service Discovery Phase SDP. Jede Antwort 2, 3 (mDNS announcement) weist die Adressinformation bestehend aus Netzwerkname 13 (bestehend aus Host- name 13a und Domäne 13b) und Port 14 sowie die Dienstkennung auf Anwendungsebene 12, letztere ist in einem Text Feld TXT der Antwort 2, 3 enthalten. Anhand der Applikationskennung 12 lässt sich der gesuchte zugehörige Netzwerkdienst identifizieren. Wenn der loT Netzwerkteilnehmer (z.B. Sensor/Aktor 100) anhand der Applikationskennung 12 den richtigen Netzwerkdienst identifiziert hat, erfolgt in einer Service Using Phase SUP eine Verbindungsanfrage 4 von dem loT Sender/Aktor 100 an den entsprechenden Host 210, der den benötigten Netzwerkdienst zur Verfügung stellt. Hierbei verwendet der loT Sensor 100 die Adressinformation aus der mDNS-SD Bekanntgabe bestehend aus Netz- werkname 13 und Port Nummer 14.
Damit kann ein loT Sensor/Aktor 100 eine eigenständige und dynamische Verbindung mit einem gewünschten Netzwerkdienst erreichen. Vorteilhafterweise ist eine Konfiguration z.B. von IP Adressen nicht mehr notwendig.
Gemäß einem Aspekt der vorliegenden Erfindung kann ein Anwender die loT-Netzwerk- teilnehmer 100 und/oder den dazugehörigen Netzwerkdiensten in seinem System mit eigenen Bezeichnern bezeichnen. Diese spezifischen Bezeichner können in dem Textfeld TXT stehen, so dass ein Anwender direkt loT-Netzwerkteilnehmer und/oder die dazugehörigen Netzwerkdienste in seiner Bezeichnerstruktur (Benennung der loT-Netzwerkteilneh- mer und/oder der dazugehörigen Netzwerkdienste) erkennen kann. Dies ist vorteilhaft, weil der Anwender somit keine Abbildungstabelle (Anwendungsbezeichner auf die IP-Adresse; Infrastrukturadresse oder strukturelle Adresse) benötigt. Ferner ist somit eine Abbildungstabelle einer Bus-Adresse in nicht IP-basierten Systemen vonnöten. Beispielsweise kann ein Bezeichner für einen loT-Temperatursensor und/oder den dazugehörigen Netzwerkdienst Tlxxx darstellen. Der Bezeichner für ein Ventil kann beispielsweise Vxxx darstellen. Optional kann der Anwender den jeweiligen Bezeichner für die loT- Netzwerkteilnehmer/Netzwerkdienst anhand eines Anlagendiagramms oder einer Anla- genstruktur, die mittels deren Steuerung durch die loT-Netzwerkteilnehmer ermöglicht werden soll, selber vornehmen.
Gemäß einem Aspekt der Erfindung werden IPv6 Link Local Adressen bei der Zuteilung der IP Adressen verwendet. Damit können die Hosts 210 - 230 und der Netzwerkteilnehmer 100 sich die IP Adressen selber zuteilen oder zuordnen. Dies wiederum ist vorteilhaft, da hierzu keine zentrale Administration mehr benötigt wird.
Fig. 2 zeigt symbolisch die mDNS-SD Anfrage mittels eines verfügbaren mDNS-Nutzer- programms. In Zeile (1) wird die Anfrage gestellt, welche Hosts den Dienst vom Typ 11 anbieten, daraufhin zeigt das Programm eine Liste (Zeilen 2 und 3) mit Informationen zu Hosts an, die darauf mit einer Bekanntmachung geantwortet haben, unter anderem den Servernamen (13a) und die Domäne (13b). In Zeile 5 wird das mDNS Nutzerprogramm aufgefordert, weitere aus der Bekanntmachung bekannte Informationen zu dem gefundenen Host anzuzeigen. Darunter sind der Netzwerkname 13, die Portnummer 14 und die Dienstkennung auf Anwendungsebene 12 (d. h. eigener Bezeichner für den jeweiligen loT Netzwerkteilnehmer). Letztere wurde im Textfeld TXT der mDNS-SD Bekanntmachung übertragen.
Gemäß einem Aspekt der vorliegenden Erfindung kann der loT-Netzwerkteilnehmerals ein Drahtlos-Sender/Empfänger bzw. ein Drahtlos Client ausgestaltet sein.
Der Drahtlos-Sender/Empfänger kann basierend auf einem WiFi-Protokoll, einem LTE- Protokoll, einem 5G-Protokoll oder einem Bluetooth-Protokoll IP-basiert mit dem Netzwerk kommunizieren.

Claims

Ansprüche
1 . Verfahren zur Identifikation von Netzwerkdiensten (210 - 230) in einem Netzwerk (300) mit mindestens einem Host, welcher Netzwerkdienste jeweils mit einer Netzwerkdienstkennung (12) bereitstellt und mindestens einem Internet-of-Things Netzwerkteilnehmer in Form von mindestens einem Internet-of-Things Sensoren/Aktoren und/oder Drahtlos-Sender/Empfänger (100) basierend auf Domain Name System-Service Discovery DNS-SD über ein Multicast Domain Name System mDNS, mit den Schritten:
Senden einer Domain Name System-Service Discovery DNS-SD konformen Anforderung (1) nach einem Netzwerkdiensttyp (11) von einem lnternet-of-things Netzwerkteilnehmer (100, 210, 220, 230) an das Netzwerk (300) mit dem mindestens einen Host, welcher Netzwerkdienste bereitstellt;
Empfangen mindestens einer Domain Name System-Service Discovery DNS-SD konformen Rückantwort (2, 3) von einem der Hosts (210 - 230) auf die Anforderung (1), wobei die Rückantwort (2, 3) ein Textfeld (TXT) mit einer Netzwerkdienstkennung (12) des Netzwerkdienstes, das dem angeforderten Netzwerkdiensttyp entspricht, aufweist, und
Senden einer Verbindungsanforderung (4) von dem Internet-of-Things Netzwerkteilnehmer (100) an denjenigen Host (210 - 230), dem die Netzwerkdienstkennung (12) in der Rückantwort zugeordnet ist und der den gewünschten Netzwerkdienst bereitstellt.
2. Verfahren zur Identifikation von Netzwerkdiensten in einem Netzwerk nach Anspruch 1 , wobei die Netzwerkdienstkennung in dem Textfeld (TXT) einem Bezeichner des In- ternet-of-things Netzwerkteilnehmer (100, 210, 220, 230) und/oder dem dazugehörigen Netzwerkdienst auf Anwendungsebene entspricht.
3. Verfahren zur Identifikation von Netzwerkdiensten (210 - 230) in einem Netzwerk (300) nach Anspruch 1 oder 2, wobei
Adressinformationen des gesuchten Host, welche einen Netzwerknamen (13) und eine Portnummer (14) des Hosts (210 - 230) aufweisen, dem anfragenden Netzwerkteilnehmer im Vorhinein nicht bekannt sind.
4. Verfahren zur Identifikation von Netzwerkdiensten (210 - 230) in einem Netzwerk (300) nach Anspruch 1 , 2 oder 3, wobei das Multicast Domain Name System mDNS ein wide-area mDNS darstellt.
5. Verfahren zur Identifikation von Netzwerkdiensten (210 - 230) in einem Netzwerk (300) nach einem der Ansprüche 1 bis 4, wobei eine Adressierung der Internet-of-Things Netzwerkteilnehmer (100) und/oder der Hosts (210 - 230) basierend auf IPv6 Link local Adressen erfolgt.
6. Verfahren zur Identifikation von Netzwerkdiensten (210 - 230) in einem Netzwerk (300) nach einem der Ansprüche 1 bis 5, wobei der Host (210, 220, 230) einen der Internet-of-Things Netzwerkteilnehmer (100) darstellen kann.
PCT/EP2020/077500 2019-10-01 2020-10-01 Verfahren zur identifikation von netzwerkdiensten in einem netzwerk mit internet-of-things netzwerkteilnehmern WO2021064096A1 (de)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US17/766,016 US20220368668A1 (en) 2019-10-01 2020-10-01 Method for identifying network services in a network having internet-of-things network subscribers
CN202080069297.0A CN114503532A (zh) 2019-10-01 2020-10-01 用于识别在具有物联网网络用户的网络中的网络服务的方法
EP20788730.8A EP4038863A1 (de) 2019-10-01 2020-10-01 Verfahren zur identifikation von netzwerkdiensten in einem netzwerk mit internet-of-things netzwerkteilnehmern
IL291796A IL291796A (en) 2019-10-01 2022-03-29 A method for identifying network services in an Internet of Things network with network subscribers

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102019126486.3A DE102019126486A1 (de) 2019-10-01 2019-10-01 Verfahren zur Identifikation von Diensten in einem Netzwerk mit Internet-of-Things Sensoren/Aktoren
DE102019126486.3 2019-10-01

Publications (1)

Publication Number Publication Date
WO2021064096A1 true WO2021064096A1 (de) 2021-04-08

Family

ID=72801464

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2020/077500 WO2021064096A1 (de) 2019-10-01 2020-10-01 Verfahren zur identifikation von netzwerkdiensten in einem netzwerk mit internet-of-things netzwerkteilnehmern

Country Status (6)

Country Link
US (1) US20220368668A1 (de)
EP (1) EP4038863A1 (de)
CN (1) CN114503532A (de)
DE (1) DE102019126486A1 (de)
IL (1) IL291796A (de)
WO (1) WO2021064096A1 (de)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150142968A1 (en) 2013-11-18 2015-05-21 Cable Television Laboratories, Inc. Service Discovery
US20150341446A1 (en) 2014-05-23 2015-11-26 Qualcomm Connected Experiences, Inc. ENHANCED DNS-BASED SERVICE DISCOVERY IN AN INTERNET OF THINGS (IoT) ENVIRONMENT
US20160127305A1 (en) 2014-10-31 2016-05-05 Cisco Technology, Inc. Visibility control for domain name system service discovery
US20190182300A1 (en) * 2017-12-07 2019-06-13 Mcom Media Communications Dmcc Managing content casting

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103503487B (zh) * 2011-03-03 2017-05-03 交互数字专利控股公司 用于接入隶属于所发现的服务供应商的服务的方法和装置
US9407567B2 (en) * 2012-12-24 2016-08-02 Telefonaktiebolaget Lm Ericsson (Publ) Enabling external access to multiple services on a local server
US10284659B2 (en) * 2013-01-25 2019-05-07 Apple Inc. Hybrid unicast/multicast DNS-based service discovery
WO2014200691A1 (en) * 2013-06-10 2014-12-18 Apple Inc. Configuring wireless accessory devices
US9712485B2 (en) * 2014-07-30 2017-07-18 Cisco Technology, Inc. Dynamic DNS-based service discovery
US9479572B1 (en) * 2014-08-29 2016-10-25 Juniper Networks, Inc. Dynamically identifying and associating control packets to an application layer
CN107852430B (zh) * 2015-07-06 2021-08-03 康维达无线有限责任公司 用于在局域网中形成网关的设备以及计算机可读存储介质
CN107835149B (zh) * 2017-09-13 2020-06-05 杭州安恒信息技术股份有限公司 基于dns流量分析的网络窃密行为检测方法以及装置
US10904749B2 (en) * 2018-01-25 2021-01-26 Apple Inc. Protocol for establishing a secure communications session with an anonymous host over a wireless network
CN109246024B (zh) * 2018-09-29 2022-06-10 新华三技术有限公司 一种组网中负载分担方法、装置、终端设备及存储介质

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150142968A1 (en) 2013-11-18 2015-05-21 Cable Television Laboratories, Inc. Service Discovery
US20150341446A1 (en) 2014-05-23 2015-11-26 Qualcomm Connected Experiences, Inc. ENHANCED DNS-BASED SERVICE DISCOVERY IN AN INTERNET OF THINGS (IoT) ENVIRONMENT
US20160127305A1 (en) 2014-10-31 2016-05-05 Cisco Technology, Inc. Visibility control for domain name system service discovery
US20190182300A1 (en) * 2017-12-07 2019-06-13 Mcom Media Communications Dmcc Managing content casting

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
CHESHIRE M KROCHMAL APPLE INC S: "DNS-Based Service Discovery; rfc6763.txt", DNS-BASED SERVICE DISCOVERY; RFC6763.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARD, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, 20 February 2013 (2013-02-20), pages 1 - 49, XP015090290 *

Also Published As

Publication number Publication date
IL291796A (en) 2022-06-01
EP4038863A1 (de) 2022-08-10
US20220368668A1 (en) 2022-11-17
CN114503532A (zh) 2022-05-13
DE102019126486A1 (de) 2021-04-01

Similar Documents

Publication Publication Date Title
DE10084639B4 (de) Automatische Festellung von Knoten, die einem virtuellen Unternetz zugeordnet sind
DE602005003189T2 (de) Verfahren und System zum Aufbau eines bidirektionalen Tunnels
DE602005000017T2 (de) Kommunikationsvorrichtung, Verfahren und Programm zur Namenauflösung
DE102014201188A1 (de) Hybride Unicast-/Multicast-DNS-basierte Dienstermittlung
DE112005003194B4 (de) Verteilter Domain Name Service
EP1994723A1 (de) Verfahren zur datenkommunikation mit einem bei einem kraftfahrzeug angeordneten kommunikationsteilnehmer mit dynamischer adressvergabe
DE112015006397T5 (de) DNS Optimierung für Multi-Source Download bei Hybridzugriff
DE60211270T2 (de) Vorrichtung und Verfahren zur Erbringung von Rechnernetzwerken
DE102015004668A1 (de) Aufgeteilte netzwerkadressenübersetzung
DE102015216284A1 (de) Verfahren zum Betreiben eines Gateways
EP2201724B1 (de) Identifikation und/oder adressierung einer datenendeinrichtung eines lokalen netzwerkes
DE102011055403A1 (de) Entferntes Informations- und Kommunikationssystem und dessen VerbindungmverfahrenRemote information communication system and linking method thereof
EP1631042B1 (de) Verfahren zum Zuweisen einer Geräteadresse an eine Nebenstation in einem Netzwerk sowie eine derartige Nebenstation und Hauptstation für das Netzwerk
EP1494434B1 (de) Verfahren zur Konfiguration einer Einrichtung in einem Datennetz
EP1897340A1 (de) Vorrichtung und verfahren zum adress-mapping
WO2021064096A1 (de) Verfahren zur identifikation von netzwerkdiensten in einem netzwerk mit internet-of-things netzwerkteilnehmern
EP2171943B1 (de) Verfahren zum routen von dienstnachrichten
DE60320567T2 (de) Adressenverwaltungsverfahren
DE102008039427B4 (de) Parametrisierbare Auswahl eines Kommunikationssystems auf Basis von Namenauflösungsmechanismen
DE102017205786B4 (de) Verfahren zum Konfigurieren zumindest eines Geräts in einem Netzwerk, Computerprogramm und computerlesbares Speichermedium
DE10251906B4 (de) Verfahren und Anordnung zur Inventarisierung von an einem Netzwerk angeschlossenen Netzkomponenten
EP1623559A1 (de) Verfahren zum datenaustausch zwischen netzelementen in netzwerken mit verschiedenen adressbereichen
DE102015209361A1 (de) Paketbasiertes Kommunikationsnetz mit Autokonfigurierung lokaler Netzwerk-Adressen
DE10339051B3 (de) Verfahren zum Zuordnen von über mehrere Subnetze verteilten Clients zu einen Server und Client zur Ankopplung an einen Server
DE602004005667T2 (de) System und Verfahren zur Zuordnung einer Netzwerkadresse an ein mobiles Endgerät

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20788730

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2020788730

Country of ref document: EP

Effective date: 20220502