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.
• a distributed identification of central network services of a distributed loT application can take place in the local network.
• the identification of the network service takes place via an entry in a text field TXT of an mDNS-SD compliant response.
• the entry in the text box can have an application-level identifier.
• the multicast domain name system mDNS optionally represents a wide-area mDNS.
• the network services can thus also be identified in distributed local networks.
• the Internet of Things sensors / actuators and / or the hosts are optionally addressed based on IPv6 link local addresses.
• the loT sensors / actuators can themselves be service providers in a loT application, for example a loT temperature sensor can offer a thermometer service.
• loT sensors / actuators are hosts at the same time.
• the method is suitable for identifying any local loT services and thus allows all combinations of the optional mutual identification of loT sensors / actuators and hosts.
• distributed loT network subscribers can identify the advertised mDNS-SD entries by means of the application identifier of the components in the TXT text field. Further actions such as a software update or a firmware update can then be carried out. Further refinements of the invention are the subject of the subclaims.
• FIG. 1 shows a schematic representation of a method sequence of a search for services in a network according to a first exemplary embodiment of the invention
• FIG. 2 shows a schematic representation of DNS-SD information when searching for services in a network.
• the invention relates to an Internet of Things (Internet of Things) loT infrastructure in which a plurality of loT network participants (eg loT sensors, actuators, wireless transmitters / receivers, etc.) via a network (eg Internet or a local one Network) with other components such as B. hosts, which provide network services, can communicate.
• a network eg Internet or a local one Network
• hosts which provide network services, can communicate.
• the communication of the sensors, actuators and / or the wireless transmitters / receivers with a network and with hosts in the network is based on an IP protocol.
• LoT network participants can optionally act as hosts.
• the search for an associated network service e.g.
• the loT network participant needs a network service in order to be able to communicate and to be able to transmit data or measured values to the network service.
• the network service in turn serves to receive this and optionally to control the loT network participant or to transmit commands to it.
• the respective loT network subscribers or the associated network services can be assigned specific names or their own identifiers.
• the identifiers can represent, for example, TI211 temperature collector input.
• the identifiers or the designations or names of the respective loT network participants can be specified by the user.
• 1 shows a schematic representation of a method sequence for a search for services according to a first exemplary embodiment of the invention.
• there is a service discovery ie a search for a network service, based on mDNS.
• a loT network participant 100 eg sensor / actuator
• a plurality of hosts 210, 220, 230 are connected to the network 300 and provide network services. If one of the hosts 210, 220, 230 provides the network service of the requested type 11, the host 210, 220 replies with an mDNS-SD announcement 2, 3 (mDNS-SD announcement). Inquiry 1 and responses 2, 3 take place in a service discovery phase SDP. Each response 2, 3 (mDNS announcement) has the address information consisting of network name 13 (consisting of host name 13a and domain 13b) and port 14 as well as the service identifier at application level 12; the latter is contained in a text field TXT of response 2, 3 . The associated network service sought can be identified on the basis of the application identifier 12. If the loT network participant (e.g.
• the loT sensor 100 uses the address information from the mDNS-SD announcement consisting of network name 13 and port number 14.
• a loT sensor / actuator 100 can thus achieve an independent and dynamic connection with a desired network service.
• a configuration of e.g. IP addresses is advantageously no longer necessary.
• a user can designate the loT network subscribers 100 and / or the associated network services in his system with his own identifiers.
• These specific identifiers can be in the text field TXT so that a user can directly identify loT network subscribers and / or the associated network services in his identifier structure (naming the loT network subscribers and / or the associated network services).
• This is advantageous because the user does not need a mapping table (application identifier on the IP address; infrastructure address or structural address).
• a mapping table of a bus address is therefore required in non-IP-based systems.
• an identifier for a loT temperature sensor and / or the associated network service can represent Tlxxx.
• the identifier for a valve can represent Vxxx, for example.
• the user can set the respective identifier for the loT network subscriber / network service himself using a system diagram or a system structure that is to be made possible by the loT network subscribers by means of their control.
• IPv6 link local addresses are used when assigning the IP addresses.
• the hosts 210-230 and the network subscriber 100 can thus assign or assign the IP addresses to themselves. This, in turn, is advantageous because central administration is no longer required for this.
• 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.
• the loT network subscriber can be configured as a wireless transmitter / receiver or a wireless client.
• the wireless transmitter / receiver can communicate IP-based with the network based on a WiFi protocol, an LTE protocol, a 5G protocol or a Bluetooth protocol.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Computing Systems (AREA)
• General Health & Medical Sciences (AREA)
• Medical Informatics (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)

Applications Claiming Priority (2)

Publications (1)

Family

ID=72801464

Family Applications (1)

Country Status (6)

Family Cites Families (14)

• 2019
  • 2019-10-01 DE DE102019126486.3A patent/DE102019126486A1/de active Pending
• 2020
  • 2020-10-01 EP EP20788730.8A patent/EP4038863A1/de active Pending
  • 2020-10-01 WO PCT/EP2020/077500 patent/WO2021064096A1/de unknown
  • 2020-10-01 CN CN202080069297.0A patent/CN114503532A/zh active Pending
  • 2020-10-01 US US17/766,016 patent/US20220368668A1/en active Pending
• 2022
  • 2022-03-29 IL IL291796A patent/IL291796A/en unknown

Also Published As

Similar Documents

Legal Events