The service discovery layer plays a prominent role in an IOT architecture. It is the service discovery or service management layer that differentiates an IOT network from that of a typical Internet network. IOT devices need to connect and communicate with web-based or cloud-based services and applications for IOT implementation. Cloud or web services and applications run on host computers that are identified by unique IP addresses on a network. To take advantage of a cloud-based service, IoT devices must be connected to the computers (servers) that host these services or applications. Therefore, there are some protocols designed to resolve host IP addresses that provide IOT services and applications. These protocols help identify servers that host IoT services by their namespaces and allow an IoT card to connect to one (Unicast) or group of servers (Multicast) over the network.
Some of the popular service discovery protocols are as follows –
1) mDNS
2) DNS Service Discovery (DNS-SD)
3) uPnP
4) Simple Discovery Service Protocol
mDNS – Multicast Domain Name System (mDNS) is a DNS-like service discovery protocol for resolving host names to IP addresses on a local network without using any unicast DNS server. It can be used without any additional infrastructure or DNS server on the network. The protocol operates on IP multicast UDP packets through which a node on the local network queries the names of all other nodes. The client node sends a query message to respond for a node with a specific name. When the node with the corresponding name receives the query, it responds with a multicast response message containing its IP address. Being a multicast response, the IP address and name of the target device are also saved by all devices (nodes) on the network in their local caches.
In this local network, IP addresses may change at some point, but not names. This protocol is very useful because it does not require any additional infrastructure (DNS server on the network) and can be used to manage devices without any manual configuration or administration. The protocol can be implemented despite infrastructure failures. Developed by the IETF, the mDNS protocol is defined in the RFC6762 standard.
DNS Service Discovery (DNS-SD) – This protocol stack uses standard DNS messages to discover services on an IoT network. Based on mDNS, DNS-SD is used to resolve services available on a network. Service discovery is implemented in two steps – in the first step, the hostnames of the service providers are resolved and in the next step, the IP addresses are paired with the hostnames using mDNS. It is important to identify hostnames as IP addresses can change on the network.
As in mDNS, the IP address and hostname of the target device are communicated as a multicast response and each node (IOT device connected in the network) updates the hostname and related IP address upon receiving the response. It is the protocol that keeps host names constant on the network, despite devices or nodes having dynamic IP addresses. Because the hostname always remains constant on the network, it is possible to uniquely and reliably identify devices on the local IoT network.
Just like mDNS, this protocol stack does not require any additional infrastructure (DNS nameserver on the network) or manual configuration or administration of connected IOT devices.
uPnP – Maintained by the Open Connectivity Foundation, Universal Plug and Play (uPnP) is a protocol stack that allows devices on a network to discover each other and each other's capabilities, and to configure network functions such as data sharing and communication.
There are three building blocks of any UPnP network – devices, services and control points. Devices are the basic building blocks of the network where each device provides specific service or services. Services are seen as a set of actions that can be implemented by the device. Control points identify devices by device and service descriptions and respond to the client node by invoking the requested services. In this protocol, the discovery of devices and services happens automatically and autonomously as soon as a node enters the network. Therefore, there is no need to manually configure nodes (IOT devices) to discover devices and services available on the network.
This protocol is based on TCP-IP routing. Devices are identified by their Universal Resource Indicators (URIs) and services are discovered using the Hypertext Transfer Protocol (HTTP). A device connected to the network automatically configures itself by acquiring a TCP-IP address and indicating the services available to it using HTTP. Devices then use XML to communicate with each other and indicate each other's capabilities (services to offer).
UPnP was previously a Microsoft proprietary standard, but is now an open standard. It is quite suitable for small IOT local networks where devices would need to communicate with each other without any additional infrastructure. Like UPnP, it can be used by mobile devices to connect to printers and scanners in an automated office. Likewise, it can be used to transfer photos from a camera to mobile devices or a laptop.
Simple Discovery Service Protocol (SDSP) – The Simple Discovery Service Protocol is used in UPnP networks to discover available services. It is used by control points in the UPnP network to search for devices, services they offer and their availability at a given time. The control point sends a multicast search request to which the device offering the requested service responds. The devices and services offered by them are identified by device and service descriptors respectively. The control point uses device and service descriptions to search for requested services on the network.
There are also many utility discovery platforms that IoT devices can request services to. Some of these platforms are as follows –
HyperCat – an open standard collection of URIs for identifying sensors and publishing sensor data
Physical Web – A service started by Google's Chrome development team, Physical Web allows mobile devices to capture data from sensors using BLE beacons
Wi-Fi Aware – a service that will use Wi-Fi to connect smartphones and mobile devices with surrounding sensors and IOT devices and collect and transmit data to them.
Bluetooth Beacons – a service that will allow smartphones and mobile devices to receive Bluetooth beacons containing sensor data
Shazam – a service for identifying music by recording an audio clip for a few seconds. It is currently available as a mobile app and is often used to identify music tracks.
Open Hybrid – a service for mapping digital interfaces to physical objects
Chirp – a mobile application for encoding, transmitting and decoding data in the form of audible and inaudible tones close to ultrasound
In the next tutorial, various application layer protocols used in IOT systems will be discussed.
To learn about the commonly used physical layer and data link protocols for computer networks and mobile devices, check out the following tutorial –
Physical Layer and Data Link Protocols for Computers and Mobile Devices – Ethernet BLE Wi-Fi Wi-Fi Direct WPA
To learn about the physical layer and data link protocols developed for LPWAN, check out the following tutorial –
Physical Layer and Data Link Protocols for LPWAN
To learn about the physical layer and data link protocols developed for PAN, HAN and LAN, check out the following tutorial –
Physical layer and data link protocols for LAN HAN and PAN
To learn about RFID and mobile standards with IOT applications, check out the following tutorial –
Physical Layer and Data Link Protocols – RFID and Mobile Standards
To learn about various network layer protocols, check out the following tutorial –
Network Layer Protocols
To learn about transport layer protocols, check out the following tutorial –
Transport Layer Protocols