The Internet of Things (IoT) has some unique features compared to other types of networks, most notably it is a constrained network. This means that it is lacking in bandwidth to support higher data rates and the requisite overhead burdens that normally accompany traditional broadband networks.

As a result, the standards and protocols that we use everyday in internetworking are not ideal for an IoT network. New standards and protocols are therefore necessary so the IoT can perform in an optimum manner. Since the IoT is still in its infancy as a technology, there are still a lot of close architecture and propriety solutions available that lock in buyers to specific vendors. In some cases, these solutions are very good and capable network solutions. But, it is always in the best interest of all users of IoT to work in an open architecture, standards based environment to permit vendor agnostic equipment selection and to support a long-term solution that can scale and offer elasticity, which are core traits of the IoT.

There needs to be a bridging strategy of sorts to permit the use of existing web based tools, protocols and standards in the new IoT environment. In some cases, this means using web specific protocols only in certain parts of the IoT end to end model, and in other cases it means developing new protocols that dovetails seamlessly with the existing web based standards.

The Web of Things (WoT) is a computing concept that describes a future where everyday objects are fully integrated with the Web. The prerequisite for WoT is for the “things” to have embedded computer systems that enable communication with the Web. Such smart devices would then be able to communicate with each other using existing Web standards. (1)

The Web of Things is essentially about the role of Web technologies to facilitate the development of applications and services for things and their virtual representation. (2)

Considered a subset of the Internet of Things (IoT), WoT focuses on software standards and frameworks such as REST, HTTP and URIs to create applications and services that combine and interact with a variety of network devices. So, you could think of the Web of Things as everyday objects being able to access Web services. The key point is that this doesn’t involve the reinvention of the means of communication because existing standards are used. (1)

Internet of Things is more often used in the context of radiofrequency identification (RFID) and how physical objects are tied to the Internet and can communicate with each other. Both terms are difficult to define precisely, although they are related in their general theme. (1)

Stack

IPv4 – Internet Protocol Version 4 (IPv4) is the fourth revision of the IP and a widely used protocol in data communication over different kinds of networks. IPv4 is a connectionless protocol used in packet-switched layer networks, such as Ethernet. It provides the logical connection between network devices by providing identification for each device. There are many ways to configure IPv4 with all kinds of devices – including manual and automatic configurations – depending on the network type.
IPv4 is based on the best-effort model. This model guarantees neither delivery nor avoidance of duplicate delivery; these aspects are handled by the upper layer transport. (5)

IPv6 – Internet Protocol Version 6 (IPv6) is an Internet Protocol (IP) used for carrying data in packets from a source to a destination over various networks. IPv6 is the enhanced version of IPv4 and can support very large numbers of nodes as compared to IPv4. It allows for 2128 possible node, or address, combinations. (6)

IEEE 802.15.4 – This standard defines a communication layer at level 2 in the OSI (Open System Interconnection) model. Its main purpose is to let the communication between two devices. This layer is called the Data Link. Here the digital information units (bits) are managed and organized to become electromagnetic impulses (waves) on the lower level, the physical one. This layer is similar to others known ones such as the 802.11 (commercially named under Wi-Fi technologies) or the common Ethernet (802.3). The frequencies defined in the standard are spread among 27 different channels divided in three main bands and two new potential bands (8):

  • 868.0 – 868.6 MHz – 1 channel (Europe)
  • 870.0 – 876.0 MHz – 1/6 channel (Europe) [Pending]
  • 915.0 – 921.0 MHz – 1 channel (Europe) [Pending]
  • 902.0-928.0 MHz – 10 channels (EEUU)
  • 2.40-2.48 GHz – 16 channels (Worldwide), 11 channels (North America)

IEEE 802.15.4g – Smart Utility Networks (SUN) Task Group is chartered to create a PHY amendment to 802.15.4 to provide a standard that facilitates very large scale process control applications such as the utility smart grid network capable of supporting large, geographically diverse networks with minimal infrastructure, with potentially millions of fixed endpoints. In April 2012 they released the 802.15.4g radio standard. The Telecommunications Industry Association TR-51 committee develops standards for similar applications. (9)

IEEE 802.15.4e – The IEEE 802.15 Task Group 4e is chartered to define a MAC amendment to the existing standard 802.15.4-2006. The intent of this amendment is to enhance and add functionality to the 802.15.4-2006 MAC to: a) better support the industrial markets, and b) permit compatibility with modifications being proposed within the Chinese WPAN. Specific enhancements were made to add channel hopping and a variable time slot option compatible with ISA100.11a. These changes were approved in 2011. (9)

6LowPAN – The 6LoWPAN concept originated from the idea that “the Internet Protocol could and should be applied even to the smallest devices,” and that low-power devices with limited processing capabilities should be able to participate in the Internet of Things. The 6LoWPAN group has defined encapsulation and header compression mechanisms that allow IPv6 packets to be sent to and received from over IEEE 802.15.4 based networks. IPv4 and IPv6 are the work horses for data delivery for local-area networks, metropolitan area networks, and wide-area networks such as the Internet. Likewise, IEEE 802.15.4 devices provide sensing communication-ability in the wireless domain. The inherent natures of the two networks though, are different. The base specification developed by the 6LoWPAN IETF group is RFC 6282. The problem statement document is RFC 4919.

TCP versus UDP – Both TCP and UDP are protocols used for sending bits of data – known as packets – over the Internet. They both build on top of the Internet protocol. In other words, whether you’re sending a packet via TCP or UDP, that packet is sent to an IP address. These packets are treated similarly, as they’re forwarded from your computer to intermediary routers and on to the destination. TCP and UDP aren’t the only protocols that work on top of IP. However, they are the most widely used. The widely used term “TCP/IP” refers to TCP over IP. UDP over IP could just as well be referred to as “UDP/IP”, although this isn’t a common term. (7)

CoRE – Inside the IETF, a working group was formed called the “Constrained RESTful Environments or CoRE”. The CoRE Working Group has done the major standardization work for this protocol. In order to make the protocol suitable to IoT and M2M applications, various new functionalities have been added. The core of the protocol is specified in RFC-7252, important extensions are in various stages of the standardization process. (4)

REST – Representational State Transfer or REST is an architecture style or design pattern used as a set of guidelines for creating web services which allow anything connected to a network (web servers, private intranets, smartphones, fitness bands, banking systems, traffic cameras, televisions etc.) to communicate with one another via a shared common communications protocol known as Hypertext Transfer Protocol (HTTP). (3)

HTTP – The is an IETF (Internet Engineering Task Force) standard that is commonly known and recognized for it universal functionality. It is an application level protocol that is used for web programming on the internet. It uses hyperlinks between nodes that contain text so it is the most popular means to exchange or transfer hypertext. HTTP functions as a request – response protocol in the client – server computing model. While the IoT supports the client – server model, it also supports the peer-to-peer model simultaneously.

CoAP – Constrained Application Protocol is used with devices that are simplistic, small, embedded and used very little power to operate. These devices may be sensors, switches, or any sort of devices that is monitored or controlled remotely. The CoAP is an application layer protocol in the stack. CoAP is intended for use in resource-constrained internet devices, such as WSN nodes. CoAP is designed to easily translate to HTTP for simplified integration with the web, while also meeting specialized requirements such as multicast support, very low overhead, and simplicity. Multicast, low overhead, and simplicity are extremely important for Internet of Things (IoT) and Machine-to-Machine (M2M) devices, which tend to be deeply embedded and have much less memory and power supply than traditional internet devices have. Therefore, efficiency is very important. CoAP can run on most devices that support UDP or a UDP analogue. (4)

MQTT – MQTT stands for MQ Telemetry Transport. It is a publish/subscribe, extremely simple and lightweight messaging protocol, designed for constrained devices and low-bandwidth, high-latency or unreliable networks. The design principles are to minimize network bandwidth and device resource requirements whilst also attempting to ensure reliability and some degree of assurance of delivery. These principles also turn out to make the protocol ideal of the emerging “machine-to-machine” (M2M) or “Internet of Things” world of connected devices, and for mobile applications where bandwidth and battery power are at a premium. (12)

CoAP versus MQTT. Firstly, CoAP is more appropriate to compare to MQTT-SN. It is UDP only, and designed to emulate a RESTful model over UDP. The biggest concern with CoAP is this: most people don’t actually understand REST – they understand HTTP. (11)

MQTT vs CoAP

However, as you can see, MQTT has quickly overtaken CoAP. In terms of traffic, it is a clear winner: every Facebook mobile app uses MQTT to communicate with the Facebook servers. (11)

As of March 2013, MQTT is in the process of undergoing standardisation at OASIS. The protocol specification has been openly published with a royalty-free license for many years, and companies such as Eurotech (formerly known as Arcom) have implemented the protocol in their products. In November 2011 IBM and Eurotech announced their joint participation in the Eclipse M2M Industry Working Group and donation of MQTT code to the proposed Eclipse Paho project. (12)

URI – A Uniform Resource Identifier is the generic label for a variety of names and addresses for devices found on the web and in IoT. (13)

Datagram – 127 versus 1280 bytes – In IPv6 requires a maximum transmission unit (or MTU) of 1280 bytes. However, this is far to large for the IoT world, so the IEEE 802.15.4 standard uses just 127 bytes for the MTU. This causes a disconnect between the internet and IoT packet size that adds to latency for the message due to disassembly and assembly. With the small 127 bytes, 25 bytes are used for overhead and an optional 21 octets are available for security. This just leave 81 bytes for the content. Therefore, maintaining very small datagrams is critical to performance.

LLN – Low-Power and Lossy Networks – LLNs are made up of many embedded devices with limited power, memory, and processing resources. They are interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low power PLC (Powerline Communication) links. LLNs are transitioning to an end-to-end IP-based solution to avoid the problem of non-interoperable networks interconnected by protocol translation gateways and proxies.(16)

TLS – Transport Layer Security – TLS and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols designed to provide communication security over a computer network including IoT. They use X.509 certificates and hence asymmetric cryptography to authenticate the counterparty with whom they are communicating, and to exchange a symmetric key. This session key is then used to encrypt data flowing between the parties. This allows for data/message confidentiality and message authentication codes for message integrity and as a by-product, message authentication. (14)

DTLS – Datagram Transport Layer Security – DTLS is a protocol based on TLS that is capable of securing datagram transport (UDP for instance). DTLS is well suited for securing applications that are delay sensitive (and hence use datagram transport), tunnelling applications (VPN), and applications that tend to run out of file descriptors or socket buffers. (15)

References:

(1) Cory Janssen, http://www.techopedia.com/definition/26834/web-of-things-wot

(2) W3C, http://www.w3.org/community/wot/wiki/Main_Page

(3) Wikipedia, http://en.wikipedia.org/wiki/Representational_state_transfer

(4) Cory Janssen, http://en.wikipedia.org/wiki/Constrained_Application_Protocol

(5) Cory Janssen, http://www.techopedia.com/definition/5367/internet-protocol-version-4-ipv4

(6) Cory Janssen, http://www.techopedia.com/definition/5368/internet-protocol-version-6-ipv6

(7) How-to-geek, http://www.howtogeek.com/190014/htg-explains-what-is-the-difference-between-tcp-and-udp/

(8) Wireless Sensor Networks Working Group, http://sensor-networks.org/index.php?page=0823123150

(9) Wikipedia, http://en.wikipedia.org/wiki/IEEE_802.15

(10) Wikipedia,

(11) Paul fremantle’s Blog, http://pzf.fremantle.org/2014/03/internet-of-things-protocols-and-access.html

(12) MQTT.ORG, http://mqtt.org/faq

(13) Webopedia, http://www.webopedia.com/TERM/U/URI.html

(14) Wikipedia, http://en.wikipedia.org/wiki/Transport_Layer_Security

(15) Stanford University, http://crypto.stanford.edu/~nagendra/projects/dtls/dtls.html

(16) IETF, https://datatracker.ietf.org/wg/roll/charter/

——————MJM——————

Michael Martin has more than 35 years of experience in broadband networks, optical fibre, wireless and digital communications technologies. He is a Senior Executive Consultant with IBM’s Global Center of Excellence for Energy and Utilities. He was previously a founding partner and President of MICAN Communications and earlier was President of Comlink Systems Limited and Ensat Broadcast Services, Inc., both divisions of Cygnal Technologies Corporation. He holds three Masters level degrees, in business (MBA), communication (MA), and education (MEd). As well, he has diplomas and certifications in business, computer programming, internetworking, project management, media, photography, and communication technology.