Whether you are monitoring your home while on a vacation, or heating up your weekend house before traveling there – your Internet of Things application uses Internet protocols to communicate between here and there. For this reason, IoT defined as a “global network of computers, sensors and actuators connected through Internet protocols”.
This is a greatly simplified, idealized picture of the emerging IoT. It’s the vision of a beautifully clear technology landscape, where IP packets can travel from a temperature sensor to a cloud data center and back to a heater control. Without unwieldy protocol conversion in between, without complicated gateways that are a hassle to configure or program.
High road or low road?
I’ve observed mainly two ways in which people react to this uncertainty. One way is to shudder, and then to roll up one’s sleeves “let’s do everything we can to approach the ideal; let’s bring IP protocols everywhere – after all, IP have historically won against all competing protocols”. The other way is to shrug “that’s the way the world works; competition is a good thing, and what’s all the fuss about Internet protocols anyway – there are so many other proven technologies out in the field, let’s individually pick the right one for the job”.
Let’s call this the one “high road” versus the many “low roads” perspectives. It’s a fascinating tug of war, with many heated disputes: “you need an optimized wireless protocol for a sensor network, designed from the outset for low power consumption, otherwise you’ll have too much power drain to be practical – forget about IP protocols” versus “we can do IP header compression and other tricks, so we don’t waste much power on the wireless hop from the sensors to the router – IP is the ticket to the future”.
The technical disputes typically focus on some architecture qualities that are especially relevant over the last mile, or rather the last couple of meters, of the Internet of Things. That’s where the IoT “gets physical”: minimal power consumption of a battery-powered plant sensor in your garden, real-time determinism for controlling a conveyor belt, ease of system administration where the sysadmins are technical novices and eighty years old on average (one of our clients produces hearing aids…), ease of key management for machine tool controllers that are set up by minimally trained field technicians, etc.
Are internet protocols “good enough” even for such scenarios? How good is good enough? Even after reading many arguments and research papers, I feel like both sides have good arguments, but it still remains murky to me who will be right in the long term. Is it thus simply a matter of time until Internet protocols push aside all other “legacy” protocols, as their history seems to suggest?
Bluetooth Low Energy
There exist at least two counter-examples. Communication technologies that have succeeded in parallel to the Internet: USB and Bluetooth. They have proven quite immune against Internet protocols, even though tunneling of IP protocols over them is possible. So just maybe, the last meters of the IoT might remain immune as well?
An exotic wireless technology being developed in a Nokia Research Center, called Wibree. It appeared very promising for short-range, low-power scenarios in home automation, for medical applications, and other use cases. A few years later, in a very clever move, Nokia passed control over Wibree to the Bluetooth Special Interest Group. The technology was subsequently modified to better fit the existing Bluetooth standard, and in 2010 became an official part of Bluetooth 4.0. Its current name is Bluetooth Low Energy (BLE), or Bluetooth Smart as a marketing label.
The one feature of BLE that makes it poised for explosive growth – incompatibility to IP protocols notwithstanding – is its minimal extra cost compared to a classic Bluetooth solution: it costs very little to upgrade an existing Bluetooth-enabled product to also support BLE. Starting with the iPhone 4s, Apple has begun to support BLE in all its products. Not just by including newer Bluetooth chips, but also with an API that you can use for developing BLE-enables apps. Such an app, together with a device that it connects to, is sometimes called an “appcessory.” For example, a field technician may use his smartphone to set up a new pump over BLE – the pump doesn’t need its own LCD screen for this purpose, not even a USB plug. When necessary, the app may even act as a temporary gateway from the printing machine to the Internet, e.g. so that the printing machine can fetch new firmware.
Service-oriented architecture for devices
Putting on my hat, I find one aspect of BLE particularly intriguing, and sometimes irritating as well: it folds together very low-level optimizations with very high-level architectural concepts. It is designed to be optimized for low power consumption, trying hard to minimize the number of bits and bytes that need to be transmitted. Yet it also defines a so-called generic attribute profile(GATT), which includes characteristics (e.g. the air temperature in a room or the open/closed state of a valve), sets of related characteristics called services, and sets of related services called profiles. A profile corresponds to a use case, e.g. a blood pressure measurement profile is for, well, measuring blood pressure. A service is a reusable interface, e.g. a device information service that provides information like the device’s manufacturer and model number.
Post A Comment:
0 comments: