Tom
22nd March 2016

Introduction

The Internet Protocol (IP) which runs our everyday Internet has not in the past been able to reach right out to the edge of the Internet of Things. The “last hop” – often over a short-range wireless link to a battery-powered edge device – was usually made using one of many non-IP standards.
In the diagram below:

  • Client is e.g. a SmartPhone App or a Web Client which always uses IP.
  • Server is e.g. a Google or Amazon cloud-based service at the heart of the Internet. It also uses IP for all its communications.
  • Gateway is a box at the edge of the IP network. Previous gateways have typically translated IP to some non-IP standard for the “last hop”.
  • Edge Device is e.g. machine in a factory, or a temperature sensor in a home, or a level sensor in a river. It talks to the Gateway on some non-IP Local Area Network LAN.

 

 

What’s so good about IP anyway?

A 1-minute primer

A key attribute that has made the Internet so pervasive is that it follows a layered abstraction approach to communication: At each end of a communication link there is a “stack” of software layers. Each layer only has to provide a limited piece of functionality, using only the layer immediately below it, and doesn’t have to concern itself with anything else. The lower layers take care of the grubby realities of the real world, such as sending bits of information over the actual medium (physical wires or wireless spectrum). Above that are layers which form the bits into packets, then form packets into reliable, persistent, error-corrected streams. Right at the top sits the Application. Conceptually, each layer corresponds directly with its matching layer at the other end, creating a virtual, logical link at that layer which doesn’t have to worry about anything else.

The advantage of this approach – indeed, it’s really a necessity – is that any layer can be swapped-out for alternatives without disrupting the rest of the stack. So for example if the bottom transport layers (MAC/PHY) were a Cellular link and we changed them to a WiFi link instead, then the other layers, including the Application, would remain blissfully unaware of this. The email application on your SmartPhone doesn’t have to know whether your phone’s currently connected via WiFi or Cellular– it’s all IP, so it all just works.
Internet Protocoltherefore creates a “narrow waist”.Above it are standard layers which applications can rely on, and below it are transports for carrying data, and everything above the waits is made independent of everything below by IP.

So why hasn’t IP been used for the last hop?

By definition the Internet of Things won’t exist until Things use the Internet, so given the above clear advantages why isn’t IP already used all the way to the edge?
Edge devices (typically, historically) have had rather a simple job to do, for example occasionally measuring a slowly-varying single quantity such as temperature. And they have had to do this within very constrained budgets – typically of power, of cost and of physical size. For example, if they are battery-powered they must make the most of every erg of energy and this has driven compromises in the choice of radio and processor. It also means that the device must spend most of its time asleep, to save energy. Often other important qualities (security, latency, reliability) were sacrificed in order to make an application fit within its various budgets. Partly as a consequence of this extreme need to optimise to fit a budget, engineers have tended to create proprietary solutions, with the parameters tailored to the exact constraints and acceptable trade-offs. Proprietary solutions are often inefficient in engineering time (lots of re-inventing the wheel), therefore expensive, and as they have not been tested by a large estate of users can often be of low quality too.

The need is growing

As the world increasingly wants to connect all its products, the Internet of Things is moving from a world of high-cost niche one-offs into a world of generic applications, where each piece of engineering can and must be amortised across billions of devices shipped, holding the promise of a high-quality yet low-cost generic solutions.

Capability is increasing

Meanwhile the computational ability of battery-powered processors has been steadily increasing, driven by overall “MIPS per watt” improvements and by the addition of power control which allows cores to consume ultra-low power whilst asleep (which often dominates consumption).

New standards close the gap

The standards for the internet layers above IP (including the Web) evolved in a server-based environment which is less-constrained, making them not ideally-suited to low-power edge devices for a couple of reasons:

  • Verbosity: A typical Web transaction such as an HTML request from a Web browser to a server requires thousands of bytes. But last-hop radios may only fit about 80 bytes in each radio packet.
  • Always-on: The Internet layer which is responsible for providing a reliable connection – TCP – requires that both ends be always listening-out for incoming packets, to maintain the connection. But a typical edge device sleeps most of the time to conserve power, so will miss these packets, so cannot maintain the connection.

New edge standards such as 6LoWPAN and CoAP have now helped to solve these remaining problems in a universal fashion, and thus finally offer us a way to get IP all the way to the edge. Together they are able to compress large packets down to 10’s of bytes, and provide a store-and-forward facility in the gateway to cope with sleepy edge devices: A message send whilst the device is asleep is forwarded the next time it awakes.

Closing the gap

Summarising all of the above in a picture, there is an increasing need to connect devices and a falling cost to do so.The time when the two cross over has now been brought further forward by the arrival of new standards:

 

Previous edge standards

First generation edge standards such as ZigBee, Bluetooth, Wireless Hart etc. were not designed with IP in mind. The principle reason is that they are all complete stacks, with tightly-bound layers: They specify everything from the radio up to the application profiles, which creates a complete solution but means that the layers can’t easily be replaced, e.g. by IP-compatible layers.
The secondary reason is that there is no standard way to “translate” between the IP world and each of these old standards. So every manufacturer’s gateway does this translation differently, meaning that a new gateway is required for every new device manufacturer – so the gateways become proprietary, even if they use standards on all interfaces.
There is work under way in several of these standards to try to make them IP-compatible (ZigBee IP, Bluetooth IP) at which point they can join the band of swappable layers at the bottom of the stack, though this may take radical surgery.

IP everywhere?

The above implies that there is no longer any place where IP cannot go, but this is not quite the case. There are still useful parts of the design space where the tradeoffs are sufficiently severe, yet the benefits sufficiently valuable, that the “right” solution may still not be truly IP-to-the-edge.
For example, the up-and-coming field of low-power WANs – epitomised by SigFox, Weightless, Neul and NWave – promise ubiquitous connectivity for small, low-power, low-cost, low-bandwidth devices, using a small number of  national Access Points.But they achieve this by using techniques which are not IP-friendly, such as abandoning 2-way communication, or using very large packets (which creates turnaround times too long for TCP).
However, even in these cases, standards such as CoAP now make it possible to create an Internet-friendly proxy for each edge device within the gateway (the AP), so that the edge devices can appear to be IP-enabled, even though the last hop is still not IP.  Thus we still get many of the benefits of IP.

User benefits of IP

IP also brings everyday benefits to customers and end-users.

“It just works”

As with WiFi, a single IP-to-the-edge gateway can serve all your IoT needs, and do so in a familiar way, plugging into your existing backhaul, be it corporate Ethernet or a consumer broadband router. One infrastructure can support everything and be future proof. IoT Mobility (BYOD) should just work, as your device moves from one standard environment to another. In 2014, DevicePilot worked with ARM plc to develop a proof-of-concept of just such a universal IP-to-the-edge gateway, which we called HyperWeave.

Easy to manage

In commercial environments such as enterprise or industry, a uniform IP infrastructure brings familiarity and therefore easy visibility, control and automation. Standard IT practices such as VPNs and firewalls can be used to secure the network. Problems can be diagnosed with familiar, commodity tools to sniff, capture, analyse, debugetc.
In consumer environments, standard mechanisms built around IP have made day-to-day management largely automatic, for service discovery, address allocation, name resolution etc.

Easy to design for “web–to-the-edge”

Embedded engineering – writing low-level code for edge processors – is fast joining analog, power and RF engineering as something of a “black art”. Many of today’s recent graduates know how to write Web apps using HTTP-based RESTful APIs, but they don’t know how to code for embedded devices. Running on top of IP, CoAP now allows embedded devices to be treated like any other Web server – read and written with GET and POST – allowing a large pool of web developers to easily create IoT clients and apps.

Supports everything

IP unlocks the entire power of today’s Web and Cloud in building products. IP allows applications and devices complete freedom of choice for messaging protocols – use TCP or HTTP, or DDS, XMPP, MQTT, CoAP … you choose.

Conclusion

We’ve explained the significant technical benefits that IP-to-the-edge brings not only to system architects and software engineers, but also to customers and users. These benefits make it an inevitability, held back in the past only by lack of processing budget and standards. These problems have now been solved by a suite of proven open, global standards, now supported by consortia such as the Thread Group. IP-to-the-edge won’t become universally deployed overnight, so companies may have to support legacy standards for many years to come. But IP-to-the-edge for IoT has become a clear and realisable vision now that all the required technologies and standards are in place.

About DevicePilot

DevicePilot is the software of choice for locating, monitoring and managing connected devices at scale. DevicePilot is completely agnostic, allowing the user to connect any device across any platform, with simple and easy integration. The company draws on the significant experience of its founders who successfully scaled their previous connected-device businesses to 1 million+ end-customers in areas as diverse as mobile phones, IPTV set-top-boxes and the connected home. Contact us for further information