Cumulations Logo

In dealing with different IoT solutions and helping the clients for Mobile applications, we are seeing a trend when it comes to device discovery. The trend is to suggest ARP protocol for device discovery. This article covers why it is not the feasible thing to do for a scalable IoT product.

Typically in an IoT solution, we will have one or more hardware devices (with or without a GUI ) connected to user's router. Each device would have acquired an IP address and these IP addresses are dynamic in nature, meaning these devices may get new IP address every time they switch off and switch on or even in a case of a power outage.

Now the requirement for the mobile app developer is to discover these devices and list them for user interactions. However, as the devices get dynamic IP, for the mobile apps this is quite a challenge. So mobile application developers are often advised to make use of ARP protocol suggesting as given below.

"Every WiFi device will be having a MAC address which is static. So dynamic IP address of the devices in a network can be retrieved by using the “Reverse ARP” function [finding IP address from known MAC address]."

First of all, knowing mac addresses for different kind of devices that users across geographies can buy, is itself a challenge. After this in the app, the developer would need to get the list of connected devices in the WiFi using ARP. This process of finding all the devices in the WiFi is not possible in the mobile ecosystem. In Android, you can try executing the ARP command to get the list of devices, but it will not really be the complete list of devices in the WiFi. See here (http://stackoverflow.com/questions/10548351/android-runtime-execarp-does-not-work).

In iOS you can't even try executing this command easily using a public API, If you want to try non-public API, you would run a risk of App being rejected from the app store listing. Mobile ecosystem regards this as potential security threat and will not allow using the protocol.
Hence, it is important for the firmware developers (who often are not aware of mobile app’s restrictions) to follow standard device discovery protocols.

What are the Standard device discovery protocols?

This problem of device discovery is a well-known challenge in IoT domain and is addressed by protocols like Bonjour, UPnP device discovery protocols etc. The fundamental principle underlying these protocols is in understanding the Multicast. We have used the UPnP device discovery in our mobile applications like Gear4
https://play.google.com/store/apps/details?id=gear4.stream a Multi-Room Audio app.

What happens in a Multicast?

Once hardware device gets connected to the router they will obviously get the IP address. After getting the IP address, these devices define and join a group. For example, they can join group 255.255.255.251.

If there are 2 lights in a network they will join to this virtual Multicast group.
When Mobile App opens, it simply asks the router for all the devices in the Multicast group
(255.255.255.251). This group 255.255.255.251, can be hard coded in the app as it is a virtual IP.

                     Multicast

Note:
The technical implementation of Multicast for device discovery is little different from the above explanation. Implementation could involve a TCP Server socket creation in the mobile app and define proper response headers for hardware devices. However, this explanation should help all the audience to understand the underlying mechanism in a nutshell. Also, please note this approach may not be suitable if you are planning to control the devices from outside the connected WiFi zone.