Not surprisingly, embedded devices and people use the Internet very differently.
People make use of the Internet through the Web, e-mail, and texting. In the Internet of Things, embedded devices exchange information with each other. But these devices don't have the machine equivalent of Web browsers and social media. Not yet, at least.
When designing your IoT device, you have to think about how your local network connects to the Internet. You can do it with a gateway. Or you can build this capability into the device itself.
At the heart of the Internet is TCP/IP, the Internet protocol suite. It can be represented using the OSI seven-layer reference model.
TCP is used for most of our human interactions with the Internet: e-mail, Web browsing, and so on. And so many people think that TCP should be the only protocol used at the Transport layer. It provides the concept of a logical connection, acknowledgement of transmitted packets, error checking, and flow control. But for an embedded system, TCP can be overkill.
UDP is a simpler protocol than TCP. It's commonly used for the domain name system and for DHCP. But it's now finding a new home in sensor data acquisition and remote control. And it's better suited for real-time data applications such as voice and video.
If you're familiar with Web technologies, all this may be old news for you. The question is: can you build an IoT system using familiar Web technologies? Yes, you can. Although the result won't be as efficient as with the newer protocols.
Let's walk through some of the options you have for choosing your network connection.
Each of these options has its own advantages.
WebSocket is a protocol that provides a full-duplex link between client and server.
It's part of the HTML 5 specification. WebSocket simplifies much of the complexity around bi-directional Web communication.
XMPP is a good example of an existing technology finding new use in the IoT space.
It's commonly used for instant messaging and presence information. But it's now expanded into signaling for Voice over IP, collaboration, content syndication, and generalized routing of XML data.
The downside of these Web protocols is that they're often too data heavy for IoT applications. By contrast, CoAP was designed especially for use in devices operating on battery or energy harvesting. It uses UDP. Some important functions of TCP are reproduced in CoAP. CoAP handles both synchronous and asynchronous transactions. It has a low overhead, which makes it well suited for machine-to-machine communication. And it work a lot like HTTP. So if you have a Web background, using CoAP is relatively easy.
Another popular protocol for IoT devices, and networks with low bandwidth, is MQTT. This is a publish-and-subscribe transport that is extremely lightweight. It helps minimize the resource requirements for your IoT device, and can handle unreliable networks. MQTT runs on large networks of small devices that need to be monitored from a back-end server. Unlike CoAP, it's not designed for device-to-device transfer, or multicast.
This is a lot to take in, so let's sum it up this way:
The protocol stack for Web applications can easily produce a data overhead of hundreds or thousands of bytes. By comparison, IoT protocols are optimized for constrained devices and networks, and produce a much smaller data overhead of tens of bytes. And so your choice of network protocols will be determined by the constraints of your network connection. You may want to take a visit to http://micrium.com/iot where all this is spelled out in more detail.
Our next video will tackle the other end of the Internet of Things: the cloud.