From what I see today, there are four main components of systems that support the Internet of Things, as depicted in Figure 1.
As you see, there are four separate areas:
– The Thing itself (the device)
– The Local Network, which moves data in and out of the device. This may include a gateway to translate proprietary communication protocols to the IP family of protocols.
– The Internet itself
– End user devices (desktop, laptop, smartphones) or enterprise data systems that receive and manipulate data (backend data analytics)
IoT is not complicated in conception, but it is complex in its execution. Each individual component is simple, but there are many required components for IoT. What is important to understand is that even if new hardware and software are still under development, we already have all the tools we need now to start making IoT a reality.
This article will look at the end devices in an IoT system from the embedded developer point of view. This article has four parts, divided along the same grouping found in Figure 1. I would like to start with the “Thing”. But to understand well the “Thing” challenges, we need to understand the communication technologies in play with the IoT devices.
What are the Local Networks?
As mentioned above, the value in IoT is in interconnected devices, and the data and metadata they will generate. The choice of communication technology affects the amount of software required, which in turn affects hardware requirements and cost. Furthermore, IoT devices are deployed in such a huge number of different ways—in clothing, houses, buildings, campuses, factories, and even in your body—that no single networking technology can fit all bills.
Wireless Sensor Networks (WSN)
For an installation of IoT devices in a specific location (say, a factory), a large number of sensors and actuators may be scattered over a wide area. A wireless technology is the best fit for such devices. There are as many types of edge/sensing node as there are system types, and some of these systems already have associated standards. This is why there are so many machine-to-machine (M2M) communication technologies in use. Some of these technologies pre-date the concepts of IoT and M2M, and they all have their particularities in terms of radio frequency, power consumption or protocol complexity. So, choosing a local networking technology can be a serious problem for embedded developers. There is often no single best choice. The technologies currently available are narrowly specialised for specific vertical markets (smart healthcare, smart grid, and so on).
Figure 2 shows the position of the nodes and edge nodes in a Wireless Sensor Network. A description of these devices follows below.
This type of embedded system will likely represent the largest product volume. A WSN node is an embedded system performing one, or a very few, functions (reading an environmental variable like temperature or pressure, turning on a light or a motor). WSN Nodes are very low cost, so they can be deployed in very high volume. They are also very low power so that they can run on battery or even use energy harvesting.
Energy harvesting derives energy from external sources (e.g. solar power, thermal energy, wind energy, electromagnetic radiation, kinetic energy and more), captures and stores it for small, low power wireless autonomous devices, like the nodes on a WSN.
WSN Edge Node
A WSN edge node is a WSN node with IP connectivity. It acts as a gateway between the WSN and the IP network. It can also perform additional local processing, local storage, and can have a user interface.
The battle for the position of preferred networking protocol is far from over. There are multiple candidates. Initially, there were proprietary mesh networking stacks such as EmberZNet and TinyOS from Berkeley. But market growth required the use of standards-based solutions to allow for interoperability, and multiple sourcing for suppliers. The application protocols are the last element developed for mesh networking and wireless sensor networks (WSN). These efforts lead to emerging standards such as Zigbee, Z-Wave and Ant.
The first networking technology candidate for an IoT device is Wi-Fi, because it is so ubiquitous. Certainly, Wi-Fi can be a good solution for many applications. Almost every house that has Internet connectivity has a WiFi router. Any other device in the house can use this Wi-Fi access point, and it is IP capable. A good example is the thermostat by NEST Labs, (now part of Google) or garage door openers by Craftsman, Inc.
However, Wi-Fi needs a fair amount of power. In the “Thing” category, there are myriad devices that can’t afford that level of power—battery operated devices, for example, or sensors positioned in locations that are difficult to power from the grid.
Newer networking technologies for wireless sensor networks are pushing the development of low-cost, low-power solutions. These technologies support the creation of very large networks of very small intelligent devices for sensing and collecting data. Currently, major R&D efforts are concentrated on:
– Low-power and efficient radios, allowing several years of battery life
– Energy harvesting as a power source for IoT devices, especially considering the new low power radios
– New reliable mesh networking and protocols for unattended long-term operation without human intervention (e.g., M2M networks)
– New standard application protocols and data formats, enabling autonomous operation
One of the major IoT enablers is the IEEE 802.15.4 radio standard, which was released in 2003. Commercial radios meeting this standard provide the basis for low-power systems. This IEEE standard was extended and improved in 2006 and in 2011 with the 15.4e and 15.4g amendments. Power consumption of commercial RF devices is now cut in half compared to only a few years ago, and we are expecting another 50% reduction with the next generation of devices.
EnOcean, for example, is one of the companies that have patented energy-harvesting wireless technology to meet the power consumption challenge. EnOcean’s technology works in the frequencies of 868 MHz for Europe and 315 MHz for North America. The transmit range is up to 30 metres in buildings and up to 300 metres outdoors.
For a device to take advantage of energy-harvesting technology, the processor and the software running on the device must be able to perform their tasks in the shortest time possible, which means that the transmitted messages must be as short as possible. This requirement has implications for protocol design. And it is one of the reasons why 6LoWPAN (short for IPv6 over Low power Wireless Personal Area Networks) has been adopted by ARM (Sensinode acquisition) and Cisco (ArchRock acquisition), as its encapsulation and header compression mechanisms allow for briefer transmission times.
There are many wireless networks available that are specialised for various industries. The following is a brief list:
– ZigBee and ZigBee IP
– Wireless HART
– Wireless M-Bus
The connectivity requirements for IoT devices are so diverse that a wide range of different technologies are needed. One technology cannot meet all the range, power, size and cost requirements. It is my belief, however, that any protocol that can carry IP packets has an advantage over all others. These technologies will, in my humble opinion, be the winners. I believe that 6LoWPAN will be the choice for WSNs and light IP based protocols in the Internet back-end services.
IPv6—a major IoT enabler
If the system envisioned is local and M2M only, the wireless protocols discussed above are all good candidates. But if the goal is to remotely control a device over the Internet, or take the device’s sensor data and store it on a remote server, the Internet Protocol (IP) must be involved. If the M2M network does not handle IP natively (or uses IP in a modified form), this can still be done using an intermediate gateway that translates the local protocol into an Internet-capable one.
Kaivan Karimi from Freescale, and Gary Atkinson from ARM, in a white paper titled, What the Internet of Things (IoT) Needs to Become a Reality, say that they believe that some communications technologies, such as Bluetooth Low Energy (BLE), are becoming de facto standards in certain vertical segments, such as the health care industry. But in the fields of industrial control and automation, the battle for the preferred standard – between ZigBee, low-power Wi-Fi technologies, and 6LowPAN – has just begun.
If at all possible, it is crucial that local area networks (LANs), personal area networks (PANs) or body area networks (BANs) all make use of the suite of Internet Protocols (IP, UDP, TCP, SSL, HTTP, and so on).
The usefulness of IoT devices resides not only in local communication, but also in global communication. This means using the Internet, but not necessarily the Internet as we understand it today, with HTTP and browsers. Other protocols are being developed to better address the IoT needs. Furthermore, these networks must support IP version 6, as the current IP version 4 standard faces a global addressing limitation, as well as limited multicast support and poor global mobility.
IPv6’s addressing scheme provides more addresses than there are grains of sand on earth — some have calculated that it could be as high as 1030 addresses per person (Compare that number to the fact that there are 1028 atoms in a human body!) IPv6 was designed to never run out of IP addresses. With IPv6, it is much simpler for an IoT device to obtain a global IP address, which enables efficient peer-to-peer communication.
The importance of IP to the Internet of Things does not automatically mean that non-IP networks are useless. It just means that where such networking technologies are used, a gateway is required to reach the Internet. The gateway does the translation between the IP realm and the specific networking technology used by the IoT device. An example is the ZigBee IP gateway; ZigBee is a communications protocol for low-power devices, and cannot carry IP packets. However, in March 2013, the situation as changed when the ZigBee Alliance released ZigBee IP, which is an open standard for transmitting IPv6 over low power wireless personal area networks (6LoWPAN).
Referring to Figure 1, IoT from an embedded point of view, we can see that the network that links devices together is only one part of the IoT. 6LowPAN, because it carries an IPv6 address with a compressed header, can at least offer the possibility to connect to the Internet. 6LoWPAN has also an advantage over other personal area networks, since peer-to-peer communication is simpler when each device has a global address. However, even though 6LoWPAN carries a special form of IPv6 packet, another software layer is still required to make the translation between the compressed IPv6 header and the regular IPv4 or IPv6 headers that are understood by your Internet service provider. This is where gateways or routers come into play.
The requirements for IoT device communication dictate the requirements for the device’s software. Any one of the above-mentioned communication stacks, together with the application implemented in the device, represents a significant amount of software. The IoT device hardware design is greatly impacted by these choices.
The industry would prefer to build WSN nodes at the lowest possible cost, and to that end, a lot of work has been done to integrate the microcontroller and its peripherals onto a single chip. The software requirements put heavy demands on the microcontroller’s flash memory and RAM. For the next few years, the cost of WSN nodes may still be slightly too high to allow for wide market penetration of these devices.
Improvements in chip design, including the move to lower transistor geometry, in conjunction with really small core design, are all factors that will eventually make low-cost IoT devices a reality.
I strongly believe that the Internet Protocol is mandatory for any IoT device. This is why I think that 6LoWPAN is the best WSN technology to use.
In the next segment, I will discuss IoT device hardware and software architectures. I will also provide suggestions for the processor architectures for each type of IoT devices.
Of course, any discussion of IoT would not be complete without looking into the Internet and Cloud services. Once we have an IoT device transmitting or receiving data encapsulated in an IP packet, we now have to see how this data can be stored, analysed and used to create more value. The last two segments in this series will touch these topics.
Useful resources: Postscapes
About the author
Christian Legare is Executive Vice-President with Micrium, home of uC/OS-II, the real-time kernel.
Christian has a Master’s degree in Electrical Engineering from the University of Sherbrooke, Quebec, Canada. 22 years in the telecom industry, he has been involved in large scale organisations as well as start-ups, mainly in Engineering and R&D, and was in charge of an IP (Internet Protocol) certification program at the International Institute of Telecom (IIT) in Montreal, Canada as their IP systems expert.