The last blog entry was a link to a GigaOM article about a speech made by Sebastian Marineau-Mes from RIM (link to article). The topic is how the Internet of Things (IoT) will not succeed if it is implemented as a non-confederated system of individual networks that use proprietary data — islands in the river. In other words, IoT implementations that expect to use internet/cloud lookup and “big data” technologies for information categorization can be OK for personal applications (home automation, health/fitness, toys/gizmos), but they are not going to work for the sorts of large-scale applications that actually make our world a better place.
Hopefully I am thinking the same thing as RIM when I try to define “curated openness,” and I am confident that I am. The three examples below show the importance of open standardization at increasing amounts: data layer, link layer, and data+link. In order to achieve all three, full-stack standardization must exist, there must be open source software available, and there must be some standards body that is able to certify that a given device meets the standard. DASH7 is one IoT technology that meets all of these requirements. There may be others, but I’m not confident there are yet.
1. When bridging IoT data to the regular internet, an explicit data exchange language is required.
If I have a device that sends me a small, encoded packet — as is common for IoT devices — I may be able to receive the data packet and have no idea what to do with it. Without explicit data exchange standards, I need a-priori knowledge about the ownership of the device, which internet service I should send the data, how to get the response back from that internet service, etc. Web services APIs are not particularly standardized. I could try to convert the packet data into some sort of XML or JSON, which might provide a bit of application-layer data standardization, but, still, there is a big a-priori requirement at the client. The data I received from the device hasn’t told me how to use it or where to send it.
Open standardization of the IoT packet data formatting can provide the a-priori requirement in a way that any application can utilize. One of the draft standards I like, here, is CoAP. With CoAP, I can include explicit instructions in my packet that help the client figure out how the data is formatted, what website it should forward it to, and quite a bit more. DASH7 works nicely with CoAP, and DASH7 additionally has an openly specified/standardized filesystem design that sits below the CoAP layer, allowing even greater flexibility for the application designer. Technologies like Bluetooth Low Energy (BLE) have design limitations that prevent things like CoAP from being used, so I don’t see them playing a big role in large-scale, open systems for IoT. These types of systems are more ideal for personalized products, where there can be an implicit, proprietary path between the device data and the user interface.
2. IoT data May never touch the internet. Full stack standardization is required for these applications.
Here is an example of tire-pressure monitoring, and it is happening now: assume every car tire has a tiny pressure sensor embedded in the rubber, and each one communicates its information via wireless to some client (e.g. a central unit in the car, an external reader at a service garage, or the owner’s smartphone), there needs to be an easy, open, standardized way for all the tire and automotive manufacturers to communicate. It isn’t practical that these systems should access the internet just to get tire pressure information. They need to have a common, peer-to-peer language for data exchange as well as a common system for communication itself.
DASH7 is not the only IoT system standard in the world that allows encapsulation of flexible application data (such as CoAP data), but it is the only one that openly standardizes every layer of the communications stack. Interoperability between the tire sensor and the car ECU, the garage’s reader, etc, requires open standardization of the full stack, not just the data exchange element. The radio waves need to have standardized same modulation, the channel access timing needs to be standardized, the packet framing needs to be standardized, the configuration datasets need to be standardized, and on-and-on. DASH7 is a fully standardized stack.
3. Without a way for application/API data to affect the link-layer, large-scale deployment is impractical.
This is the most esoteric of the three reasons, but let me try to explain. You most likely have a cellular phone: how many wireless interfaces are on your phone? The answer: at least four. There are usually at least 3 cellular interfaces alone. Often, there is bluetooth and WiFi as well. The simple fact is there is no holy-grail wireless technology that can do everything.
Back in the 70’s when modern internet and telecom systems were being devised, there was not very much system integration. Open an old cellular phone and see how many chips there are inside. Now, there is usually just one chip to do all of the communications. The 7-layer OSI model of the 70’s is really a 2-layer model now: “baseband” + application.
IoT devices benefit from even more integration. In cellular systems, the network is managed by a single entity, and they are able to manage the baseband of the network in a way that is pleasantly transparent to the application. There is enough standardization to allow any phone to connect to any network of the same standard, but this is something that happens rarely, like when you get off a plane going from one country to another. In IoT systems, device will get handed-off from one network to another all the time. Networks can be very small. Networks can also be very large, but not contiguous. So, it’s important for IoT devices to be able to switch networks just like cellphones do — except they have to do it faster and more often — and it’s important for IoT network managers to be able to manage their networks remotely over the internet.
DASH7 accomplishes this by standardizing a way for an exchange of application data to affect the actual link-layer behavior of the device. For example, one network might be a warehouse, where there is not a lot of movement or utilization of device data. It can configure its devices to behave in the most optimal way for this situation. One day a device might leave the warehouse and get attached to a network that wants to know its location every 5 seconds, and then another day it might end up in a network where it is expected take sensor readings each minute but only upload a sensor log only when requested. With DASH7, there is an open, interoperable method for telling any device to change the way it behaves, and application layer data can efficiently deliver these directives.