By Chris

At its most basic level, the Internet of Things is all about connecting various devices and sensors to the Internet, but it’s not always obvious how to connect them.

In March 2015, the Internet Architecture Board – a group within the Internet Society that oversees the technical evolution of the Internet – released a guide to IoT networking (PDF). This outlined four common communication models used by IoT “smart objects”: Device-to-Device, Device-to-Cloud, Device-to-Gateway, and Back-End Data-Sharing.

With the help of Hannes Tschofenig, a member of the IAB and the Senior Principal Engineer at ARM Limited, this post will provide some background on how things connect to the Internet.

1. Device-to-Device

Device-to-device communication represents two or more devices that directly connect and communicate between one another. They can communicate over many types of networks, including IP networks or the Internet, but most often use protocols like Bluetooth, Z-Wave, and ZigBee.

This model is commonly used in home automation systems to transfer small data packets of information between devices at a relatively low data rate. This could be light bulbs, thermostats, and door locks sending small amounts of information to each other.

Each connectivity model has different characteristics, Tschofenig said. With Device-to-Device, he said “security is specifically simplified because you have these short-range radio technology [and a] one-to-one relationship between these two devices.”

Device-to-device is popular among wearable IoT devices like a heart monitor paired to a smartwatch where data doesn’t necessarily have be to shared with multiple people.

There are several standards being developed around Device-to-Device including Bluetooth Low Energy (also known as Bluetooth Smart or Bluetooth Version 4.0+) which is popular among portable and wearable devices because its low power requirements could mean devices could operate for months or years on one battery. Its lower complexity can also reduce its size and cost.

2. Device-to-Cloud

Device-to-cloud communication involves an IoT device connecting directly to an Internet cloud service like an application service provider to exchange data and control message traffic. It often uses traditional wired Ethernet or Wi-Fi connections, but can also use cellular technology.

Cloud connectivity lets the user (and an application) to obtain remote access to a device. It also potentially supports pushing software updates to the device.

A use case for cellular-based Device-to-Cloud would be a smart tag that tracks your dog while you’re not around, which would need wide-area cellular communication because you wouldn’t know where the dog might be.

Another scenario, Tschofenig said, would be remote monitoring with a product like the Dropcam, where you need the bandwidth provided by Wifi or Ethernet. But it also makes sense to push data into the cloud in this scenario because makes sense because it provides access to the user if they’re away. “Specifically, if you’re away and you want to see what’s on your webcam at home. You contact the cloud infrastructure and then the cloud infrastructure relays to your IoT device.”

From a security perspective, this gets more complicated than Device-to-Device because it involves two different types of credentials – the network access credentials (such as the mobile device’s SIM card) and then the credentials for cloud access.

The IAB’s report also mentioned that interoperability is also a factor with Device-to-Cloud when attempting to integrate devices made by different manufacturers given that the device and cloud service are typically from the same vendor. An example would be the Nest Labs Learning Thermostat, where the Learning Thermostat can only work with Nest’s cloud service.

Tschofenig said there’s work going into making Wifi devices that make cloud connections while consuming less power with standards such as LoRa, Sigfox, and Narrowband.

3. Device-to-Gateway

In the Device-to-Gateway model, IoT devices basically connect to an intermediary device to access a cloud service. This model often involves application software operating on a local gateway device (like a smartphone or a “hub”) that acts as an intermediary between an IoT device and a cloud service.

This gateway could provide security and other functionality such as data or protocol translation. If the application-layer gateway is a smartphone, this application software might take the form of an app that pairs with the IoT device and communicates with a cloud service.

This might be a fitness device that connects to the cloud through a smartphone app like Nike+, or home automation applications that involve devices that connect to a hub like Samsung’s SmartThings ecosystem.

“Today, you more or less have to more or less buy a gateway from a dedicated vendor or use one of these mulit-purpose gateways,” Tschofenig said. “You connect all your devices up to that gateway and it does something like data aggregation or transcoding, and it either hands [off the data] locally to the home or shuffles it off to the cloud, depending on the use case.”

Gateway devices can also potentially bridge the interoperability gap between devices that communicate on different standards. For instance, SmartThings’ Z-Wave and Zigbee transceivers can communicate with both families of devices.

4. Backend Data Sharing

Back-End Data-Sharing essentially extends the single device-to-cloud communication model so that IoT devices and sensor data can be accessed by authorized third parties. Under this model, users can export and analyze smart object data from a cloud service in combination with data from other sources, and send it to other services for aggregation and analysis.

Tschofenig said the app Map My Fitness is a good example of this because it compiles fitness data from various devices ranging from the Fitbit to the Adidas miCoach to the Wahoo Bike Cadence Sensor. “They provide hooks, REST APIs to allow security and privacy-friendly data sharing to Map My Fitness.” This means an exercise can be analyzed from the viewpoint of various sensors.

“This [model] runs contrary to the concern that everything just ends up in a silo,” he said.

There’s No Clear IoT Deployment Model; It All Depends on the Use Case

Tschofenig said that the decision process for IoT developers is quite complicated when considering how it will be integrated and how it will get connectivity to the internet working.

To further complicate things, newer technologies with lower power consumption, size and cost are often lacking in maturity compared to traditional Ethernet or Wi-Fi.

“The equation is not just what is most convenient for me, but what are the limitations of those radio technologies and how do I deal with factors like the size limitations, energy consumption, the cost – these aspects play a big role.”