The Web of Things

OVER THE PAST two decades, there has been an explosion of standardisation around the Internet Protocol. Email and the Web have been the killer apps, allowing IP to pretty much take over the world as the one and only networking technology. The elegance of IP is that it defines a common interface between application protocols and the heterogeneous networking technologies used to transmit them. This model allows the Internet to be enhanced gracefully. As new networking technologies such as Wi-Fi become available, all our old protocols continue to work. As new protocols are invented, they can be carried over existing networks.

Telemetry applications such as fleet management have been using cellular communications for many years. The value chain required to build cellular solutions is quite complicated, typically involving modem suppliers, carriers, and aggregators just to obtain basic connectivity. But as the industry matures, it is becoming simpler and more cost effective to create cellular enabled devices. This has huge implications for the Internet of Things; manufacturers can ship devices to the field with automatic, built in connectivity.

For example in a residential application, no installer has to help the home owner get a device onto their home network by sending someone out. The cellular-enabled device simply finds the network and reports itself when powered up. In commercial and industrial markets, getting a device onto a network owned by the IT department can be a bureaucratic quagmire. Cellular devices can bypass all this complexity and jump straight onto the Internet over the air.

Equally interesting is the advent of 6LoWPAN which provides an IETF (Internet Engineering Task Force) standard which defines how to run IP over IEEE 802.15.4 wireless, an ideal medium for sensor networks. The ability to manufacture low cost, battery powered 6LoWPAN sensors has the potential to add billions of "lick and stick" devices onto the Internet.

The only real problem today for using IP to network devices is lack of a standard for running IP over lost cost wired media. Most of the hard work done by 6LowPAN for header compression would actually work quite well over alternate media. Tridium is doing this today by running 6LoWPAN over mixed media: 15.4 and MSTP/485.But it is critical that an IETF standard plugs this hole.

Many vertical industries have been networking smart devices for decades. The problem is that each vertical has implemented their own siloed solutions. The diagram above illustrates a small sampling of the vertically oriented solutions in use today.

This illustration just touches the surface of the device networking technologies in use today. Each industry tends to have hundreds of protocols,most of them proprietary to the manufacturers. These networks tend to be run over low cost media such as EIA 485 and are often installed, commissioned, and managed by non IT professionals. So while many things are networked today, very few of them are IP networked.

For the foreseeable future, many categories of smart devices will lack an Ethernet port. Wi-Fi will continue to drop in cost and will see its way into more devices. But the explosive growth in the Internet of Things will likely come from IP over cellular, 6LoWPAN, and wired serial communications. There are many existing multibillion industries which currently use non-IP device networking. Once a clear IP solution emerges which is better, these industries are likely to migrate [along with wireless-based industrial Process applications – Ed].

But the most exciting opportunities will likely arise from markets which don't yet exist. For example Google could not have existed 20 years ago because the Web itself didn't exist 20 years ago. The Internet of Things is still in its infancy – today only a very small percentage of microprocessors are IP-enabled.

The Web drove the Internet

From the 70s until the mid 90s, the Internet was just another network. In fact, in the early 90s there wasn't any strong indication that the 'Information Superhighway' was going to be the Internet. Companies such as CompuServe and AOL ran huge walled garden networks, and many non-TCP/IP protocols were in widespread use. In 1990 there were only 300,000 Internet hosts, but by 2000 there were over 72 million, and today almost 700 million.

The explanation for the Internet's hockey stick growth is undoubtedly the emergence of the World-Wide Web in the mid 90s. It acted as a catalyst to create a global standard for internetworking: the TCP/IP protocol suite.

In 1990 there were only 300,000 Internet hosts, but by 2000 there were over 72 million, and today almost 700 million

But along the way over the last two decades, the Web has turned many technologies which sit above TCP/IP into de facto standards: HTTP, URIs, HTML, MIME encoded data, and JavaScript. IP is a critical enabling technology for the web, but the Web itself is best described by its application layer protocols and formats:

• URI: are used to name and identify information
• MIME: is used to encode information
• HTTP: is used to retrieve transport information
• HTML: is used to display information

These Web technologies are now the de facto global standard for sharing information.

Web of Things

While the Internet was a key enabler for the web, but it was the Web itself which really transformed information technology wholesale. Likewise, the Internet of Things is just an enabler for what we really want: the Web of Things. The Internet of Things gives everyday devices an IP address and lets them plug into the Internet. But the Web of Things integrates those devices into the fabric of the Web itself and thus into our lives and factories. It is the Web of Things which can truly unlock the potential of device networking. IP enables inter-working, but Web technologies enable information sharing. The goal for the Web of Things is to provide URIs to all the information trapped inside smart devices, encode that information using standard MIME types, and transport that information via HTTP.

Applications and Services

Smart device applications presently tend to follow the model of vertically oriented stovepiped silos. Increasingly the opportunities to create new value lie in horizontal solutions which cross-cut verticals. For example, building out the smart grid requires device networking across many siloed markets: residential, commercial, industrial, metering, and electricity distribution. Even today, many of these opportunities are not viable because it is too complex and expensive to connect the devices. But the Web of Things can change this by making it as easy to query information from a device as it is from a web-site.

Putting it all together

Although the Web of Things is starting to take shape, there are still a couple of missing pieces. Existing networks using Ethernet, Wi-Fi, or cellular can already leverage Web technologies, although many verticals still cling to running fieldbus protocols over IP. But the ability to use Web technology over IEEE 802.15.4 and serial media remains immature, lacking many key standards. The key missing pieces:

IP over Serial. One of the biggest holes today is a standard for running IP over media such as twisted pair. The most obvious solution would
be to extend 6LoWPAN to use another MAC layer. No matter how successful 802.15.4 may be, serial communications will never go away.

Contrast the Internet with the present state of device networking in which networks and protocols are stove-piped silos with no interoperability. Historically it was considered too expensive to build IP devices. Even today there is no standard which defines how to run IP over EIA 485 (the medium most commonly used in device networks). But two wireless technologies are quickly shifting the industry: cellular and 6LoWPAN.

Just as IP became the focal point for gluing networking technology to application protocols, theWeb of Things can become the focal point for gluing devices across vertical domains to emerging applications and services.Making device information available as normalWeb services will have a transformative effect upon the entire value chain by drastically simplifying how applications and services use networked devices.

ROLL. Work is progressing within the IETF on the routing standards for setting up mesh 802.15.4 networks. However it will likely still take a couple years before things are really mature. Most likely ROLL will also be required to deal with the way in which serial links are integrated into the PAN.

HTTP over 6LoWPAN. Although HTTP is the desired application protocol for the Web of Things, it will never successfully run directly over IEEE 802.15.4 or serial links. The memory and packet size requirements for TCP and text headers are an ill fit for the constraints of sensor networks and sleeping devices. This is also the reason that full IPv6 is unsuited to low power device networks. But it doesn't mean we throw out what already exists, rather we figure out how to optimise it for the problem space and still maintain HTTP semantics, URIs, and MIME encoded data for seamless integration with the Web.

Tridium has proposed Chopan to solve this problem. Chopan defines a mechanism for compressing HTTP requests and responses into small, binary UDP packets. The theory is for Chopan to compress HTTP, just like 6LoWPAN compresses IP. The model is exactly the same, we just use a more efficient encoding. (http://tools.ietf.org/html/draft-frank-6lowpan-chopan-00

Information models and oBIX

It seems unlikely that the Web of Things will standardise on a data format to the extent that the Human Web has standardised on HTML. This is why it is so important to separate the transport (HTTP) from the data formats and their encoding using MIME. Even though fragmentation is to be expected in information models, we believe Open Building Information Exchange (oBIX) is the ideal solution. Right now it provides a standard for Web Servicesbased interfaces for building control systems. handling HVAC, security, power management and safety alarms, etc.

Virtually the entire history of standards in the device network industry have attempted to define models for every potential type of known device. After almost two decades, this exercise continues to produce brittle results which don't capture the reality of smart devices; devices are extremely heterogeneous with high variability between manufacturers and product lines, and new devices continue to be introduced at a rapid rate. Compounding the problem is that many devices are programmed from scratch in the field requiring individualised per-device models.

oBIX embraces this reality by using a model based on a simple, flexible type system backed by real computer science. oBIX focuses on a couple of key problems:

• It defines a kernel model based on a few key primitive types such as integers, strings, etc. This isn't much different to the way in which a programming language like Java starts with a few primitive types.
• It defines an open ended type system for both standards organisations and individual vendors or integrators to build up their own custom models. This isn't much different from how a programming language like Java allows people to build up their own class libraries.
• It defines a simple, elegant mechanism to combine the models from different organisations into one system based on prototype inheritance. This is the critical missing piece in most alternatives to oBIX.
• It identifies all information using URIs with a design solidly based on REST, making it ideal for weaving the Web of Things.

The possible shape of a protocol stack: what the full complement might include in theWeb of Things

Encodings

oBIX provides a simple object model for exchanging basic data such as temperature values, as well as building up arbitrary domainspecific type systems. Today oBIX models are encoded using XML, which is the format of choice on the Web today. However, XML suffers from the same verbosity that makes HTTP illsuited for sensor networks. To tackle this problem, the oBIX working group in OASIS is undertaking a new addition to the specification for binary encoding. A binary oBIX encoding will enable encoding of payloads on the order of only a few bytes for simple sensor data. And just as Chopan decompresses to full HTTP outside the sensor network, binary oBIX can be decompressed back into XML. This means that to the world at large, the Web of Things is normal IP, HTTP, and XML; only on the sensor network sees the compression of 6LoWPAN, Chopan, and binary-oBIX.

Security

Security concerns have the potential to stifle the growth of the Web of Things. One of the biggest problems plaguing sensor networks is the lack of TCP. Most smart devices don't have the resources to run TCP, so while they might be IP enabled, they are limited to UDP. But virtually all security techniques and protocols in wide use today are based on TCP. Many techniques for encryption and preventing replay attacks are based on packet ordering so there is much work left to do.

Scripting

The ability to script Web pages is perhaps the most important driver in the continual evolution of the Human Web. Likewise, the ability to create scripts for devices will be a key enabler in the Web of Things. Most likely no de facto standard will emerge for device scripting.

Tridium offers Sedona as a solution for scripting the Web of Things. Sedona solves many of the challenges for scripting devices:

• Extremely small footprint: ability to run Sedona code along with a 6LoWPAN stack in under 100KB;
• Portable Runtime: very easy to port to new devices; doesn't require anything but an ANSI C compiler. It can run on bare metal without an OS;
• Portable Code: Sedona code is portable to any Sedona device: write-once, run-anywhere;
• Graphically Programmed: Sedona applications are designed to be assembled using a graphical programming tool;
• Open Source: Tridium licenses the Sedona source code under a very liberal license, making it freely available to any device manufacturer who wants to Sedona enable their device.

Conclusion

Most of the enabling infrastructure for the Web of Things is snapping into place, but there is still work left to do.

1. Defining an IETF standard for 6LoWPAN over serial networks. We believe the MSTP specification from BACnet is an ideal starting point.
2. Defining an IETF standard for running HTTP over constrained networks such as 6LoWPAN.
3. Potentially defining (or refining existing solutions) for security over UDP protocols.
4. Completing the oBIX 1.1 specification within OASIS.

Once the technology stack is complete, it is critical to start building momentum with many different players. The Web of Things is in its infancy. Getting critical mass around a unified vision early has the potential to accelerate the market and avoid fragmentation between vertical industries.

From the Tridium white paper The Web of Things
http://sedonadev.org
www.tridium.com