Improving IoT interoperability with Decentralized Ambient Synchronization over mDNS

At Moddable we believe IoT products should be open and customizable by the end user. The current lack of standards for interoperability means that there are too many IoT products that connect to only one cloud service or interoperate only with other products from the same company.

The Web of Things community is working to find solutions to this problem based on existing and well-known web standards. A few groups involved in the Web of Things community have proposed standards for communication between IoT products, including the networking protocols to use and the format of the data being exchanged.

We are excited to see other groups actively looking for solutions, though we recognize that more discussion and experimentation is needed before anyone settles on a solution. Building on web standards is a good place to start but the high-powered servers that drive web applications and the devices that make up the Internet of Things are radically different. It is important to consider the challenges of embedded development, especially limited performance and memory, when creating IoT standards.

This post explains some of the issues with current proposals that arise from using HTTP, and introduces a compatible solution that uses mDNS.

Proposals from the Web of Things community

The W3C Web Thing Model and the Mozilla Web Thing API are both draft specifications for a common data model and API for the IoT products that are part of the Internet of Things. They call these products Web Things.

Both specifications use HTTP as the primary form of communication between Web Things and both have similar models for the data exchanged between devices.

We found that in practice, the APIs defined by these specifications need a gateway device in the home network to mediate communication between Web Thing products. This document elaborates on this point below. Mozilla provides an implementation of one such gateway. Over the past few months, we have explored the Mozilla Web Thing API and Things Gateway. You can read more about these and how to use them with the Moddable SDK in the Working with Mozilla’s Project Things blog post.

Both the Web Thing API and Things Gateway are still in an experimental phase and not ready to be used in production. Still, using them in their current form taught us some valuable lessons about making interoperable IoT products.

Lessons from the Mozilla Things Gateway

Working with the Things Gateway is easy and the Rules engine is a powerful feature. However, there are user experience issues that stem from its use of HTTP requests as the main form of communication between the gateway and Web Things.

User experience issues

One issue is that the gateway and devices often become temporarily out of sync. This happens because the gateway polls devices every five seconds to monitor their state. As a result, when you turn a light off, it takes up to five seconds for the change to appear in the gateway.

Five seconds of latency may be acceptable if you simply want to monitor the state of a device, but imagine it taking up to five seconds to actually change the state of the light. This is exactly what happens if you use the Rules engine. For example, if you create a rule that turns your light on when you turn a switch on, it can take up to five seconds for the gateway to realize the switch is on and sends a command to turn the light on. This is unacceptable to users who are accustomed to nearly immediate response from traditional physical switches.

Engineering issues

Polling more frequently might seem like a solution. Unfortunately, five seconds is perhaps already too frequent. That's because each HTTP request consumes some network bandwidth, and with a large collection of IoT products on a network that bandwidth can become significant. That's even more true for areas where many Wi-Fi networks are operating simultaneously, like apartments in a city.

Many IoT products are powered by embedded microcontrollers with limited bandwidth. Responding to an HTTP request is among the heaviest operations these devices must perform. Hitting these devices with frequent HTTP requests can start to look like a denial of service attack to the device. It has the potential to degrade its performance for other tasks it must perform.

Ideological issues

As mentioned above, we found that in practice the proposals from W3C and Mozilla assume a gateway. That minimizes the problem with HTTP polling somewhat, as only the gateway polls the devices on the network. At Moddable, we recognize that gateways can be useful. However, we do not believe that a gateway should be required for simple operations. A Raspberry Pi should not be needed for a switch to tell a light to turn on and off (and surely there's no need to check with a cloud server either).

We believe IoT products should be able to communicate directly with each other. The use of HTTP in these proposals makes that impractical, as now multiple devices may be actively polling a single light switch.

To be clear, we are not opposed to gateways. They are an appropriate tool for some situations. But the user should choose whether a gateway is right for them, not the network protocol designer.

WebSockets isn't enough

The W3C and Mozilla proposals allow for optional support of WebSockets to allow two-way communication between a device and the gateway. This helps in situations where there is a single gateway. Still, it requires a socket always be open. Sockets are a memory intensive resource on a microcontroller. Because WebSockets is optional, the HTTP server must still operate, making WebSockets an additional socket rather than a replacement for HTTP.

The proposals do not limit the devices to a single WebSocket connection. In theory, they could therefore be used for device-to-device communication. However, because many embedded devices only support a handful of simultaneous sockets, this solution does not scale. At least with HTTP, the sockets can be shared between requests.

Characteristics of a solution

Using HTTP for all communication does not deliver an optimal result for either the user or the product creator. Adding WebSockets to the mix doesn't make a significant improvement.

We believe that an ideal protocol for IoT products would have the following properties:

Lightweight, so that it can run well on inexpensive hardware
Low latency, because no one likes to wait for devices to respond
Scalable, so that it works well in future homes with dozens of connected devices
Open, so that any product manufacturer can opt-in to supporting it
Standard, because network protocols are difficult to get right

Introducing "Decentralized Ambient Synchronization"

Our work on WebThings led us to create a new way for IoT products to communicate. We call it Decentralized Ambient Synchronization (DAS). DAS is built on mDNS, which is already used by Mozilla to ease discovery of devices by their gateway. DAS operates with or without a gateway. It is not a replacement for the W3C and Mozilla proposals, but rather an option which both improves the user experience and reduces the load on the embedded hardware powering IoT products.

Monitoring properties with mDNS instead of HTTP polling

Multicast DNS, or mDNS, is a network protocol to announce and discover services on a local network. It is commonly used to discover IoT products like printers and media servers. mDNS has been in use for nearly fifteen years and is well supported in home networks.

While mDNS is not part of the Web Thing API, the Things Gateway uses mDNS to discover Web Things. You can manually discover Web Things using HTTP, but using mDNS greatly simplifies configuration of devices by the user as it replaces opaque IP addresses like 10.0.1.15 with meaningful names like lightswitch.local. The Moddable Web Things module supports mDNS. That required us to implement mDNS support in the Moddable SDK.

Implementing mDNS required careful study of the relevant RFCs, which reminded us that mDNS includes far more functionality than simply providing a device a friendly name on the local network. We recognized that mDNS has the potential solve the shortcomings we observed in the current proposals.

The "m" in mDNS stands for "multicast". One implication of that is that when a device announces itself on the local network, all interested devices on the network receive the announcement. The efficient use of multicast is a key characteristic of mDNS as it allows it to scale to support a large number of devices.

When a device announces itself, in addition to fundamental information that includes name, IP address, network protocol, and port number, the announcement may include a TXT record which is a collection of property names and values. The Things Gateway already requires that Web Things include two items in the TXT record to state that they are a Web Thing and provide the URL to request the JSON description of their properties:

webthing=true
url=http://thermostat1.local/thng/desc/thermostat/

The TXT record may be used to broadcast even more information, such as the state of the device's properties.

webthing=true
url=http://thermostat1.local/thng/desc/thermostat/
target=70
current=75

The contents of the TXT record are not required to remain the same for the lifetime of the device; the mDNS specification allows a device to update its TXT record at any time. The device simply broadcasts a TXT record with the new values. The IoT product sends only one packet, and thanks to multicast broadcast, all devices on the local network receive it. The specification requires these updates be throttled to avoid overwhelming the local network.

This video shows a side-by-side comparison of the Things Gateway and a Moddable Zero monitoring a Web Thing that has a single count property.

Because mDNS uses UDP packets for transport, there is a limited amount of room for properties in the resource record. For many IoT products, this is not a concern as they have a small number of properties. To help manage this, our Web Things module allows a device to designate which properties to include in the TXT record. For example, the device's firmware version does not need to be broadcast to all devices on the local network as it can be retrieved using HTTP. Often property names are truncated or abbreviated in the TXT record to save space, so "temperature" becomes "tmp". Our Web Things module allows the device to define short names for properties.

The mDNS specification suggests a space saving optimization for Boolean properties. If the property is true, only its name is included in the TXT record with its presence indicating a value of true. Here, the presence of the on property tells us the light is on.

webthing=true
url=http://light1.local/thng/desc/light/
on=
color=blue

If a property is false, it is excluded from the TXT record with its absence indicating a value of false. Here, the absence of the on property tells us the light is off.

webthing=true
url=http://light1.local/thng/desc/light/
color=blue

This saves a few bytes for each Boolean property. The Web Things module in the Moddable SDK implements this optimization automatically for all Boolean properties.

Synchronizing properties with mDNS

The natural next step in our work was to create a way to control properties with mDNS. We wanted to be able to have the on/off property of a light, for example, be automatically changed to match the on/off property of a switch. The solution for this was not immediately obvious. mDNS broadcasts the current state of one device to all other devices on the local network. It is not designed to send a property change command to another device.

Web Things that follow Mozilla's Web Thing API provide URLs to read and write each property. Any HTTP client that retrieves the Web Thing's description can parse its description to find these URLs and send HTTP requests to read/write the device's properties. Because we wanted to maintain compatibility with the Things Gateway, we left this as is.

We found a solution by inverting the problem. Instead of having the switch tell the light to change its property, we tell the light to listen for changes to the switch's on property and synchronize its own property to that. This change in perspective allows the switch to simply broadcast its property change values. Any other devices configured to synchronize with the switch listen for changes and update themselves. This solution scales well. Several lights can synchronize with a single switch, for example, without generating any additional network traffic.

Configuring synchronization

To configure a device to synchronize with one or more remote devices, we added a controller property to each Web Thing. The controller property is a property map that maps one or more properties of the local device to corresponding properties of remote devices. For a colored light bulb, it might look something like this:

[
{
"property": "on",
"txt": "power",
"remote": "switch"
},
{
"property": "color",
"txt": "rgb",
"remote": "colorRemote"
},
]

Implementation

The controller property is set like any other property: by sending the Web Thing an HTTP request. Individual applications do not need to define getter and setter functions for the controller property; they are defined in the WebThing class in the Web Things module.

The WebThings class discovers other Web Things on the local network and parses mDNS packets to determine if an item in their TXT record necessitates an update to the property of one or more local Web Things. This method is intended as an alternative, not a replacement, to the existing method of sending an HTTP request to write properties, and acts the same from the application's perspective (i.e. properties are updated by calling the corresponding setter).

Advantages

Using the listener model for synchronizing properties has several benefits:

The device broadcasting values does not need to keep track of which devices are using its properties.
No gateway is required because devices communicate directly with each other.
Latency is low because a single multicast packet can be delivered more quickly than an embedded device can make an HTTP request. This leads to a user experience that is often nearly indistinguishable from traditional analog physical switches.
Scalability is great because a single mDNS TXT record change will update all listeners.
Configuration is simple because it is only necessary to tell the device which properties to synchronize.

Visual comparison

The following image represents the current polling method used by the Things Gateway. In this image, a Rule is set to turn the light on when the switch turns on, and turn the light off when the switch turns off. The gray dotted lines represent an HTTP request; the yellow dotted lines represent an HTTP response.

The following image represents our mDNS-based model that uses the controller property described above. The gray dotted lines represent an mDNS packet being broadcast to the local network.

Benefits

Using DAS greatly reduces the number of HTTP messages. HTTP becomes the protocol for managing devices — retrieving the device description, getting/setting infrequently modified properties or properties with large data payloads, and configuring the synchronization between devices. mDNS is used for device discovery and to broadcast property changes.

Using a gateway to set up Rules is useful because it is possible to create an easy-to-use user interface like the one in the Things Gateway. If DAS was the standard, the Things Gateway would still be able to easily implement the Rules engine. Instead of storing Rules and sending HTTP requests to write properties whenever a triggering event happens, it simply has to send a single HTTP request to update the controller property of one device.

This video shows a side-by-side comparison of the Rules engine and the controller property.

Conclusion

Our experiments with device-to-device communication using mDNS have yielded surprisingly good results without sacrificing compatibility with the current Web Thing API. DAS is consistent with many of the goals of the Web Things initiatives that inspired it, in particular, a commitment to open interoperability. DAS improves both performance and scalability while reducing overall hardware resources needed, delivering a better user experience on less costly hardware.

The key characteristics of DAS are:

Decentralized. Using DAS, devices communicate directly without the need for a central authority, whether that is a local gateway or a remote cloud service. The user can choose to connect their devices to a gateway or the cloud, but they are not required to.
Ambient. DAS compatible devices broadcast their state into the local network. Interested devices are free to make use of it or ignore it. This greatly simplifies the management of devices for users.
Synchronization. The traditional model of commanding a device to change a property is replaced with the idea of synchronizing to remote properties. This makes a device responsible for updating itself, rather than waiting to be told what to do. This model simplifies interoperability by minimizing the communication between devices.

We look forward to experimenting more with mDNS and hope to see more proposals from the Web of Things community for data models and APIs for interoperable IoT products.