From your perspective, what are the biggest challenges facing gateways in IoT rollouts?

From the silicon perspective, ARM has a wide variety of processor solutions. This is an important fact as there is a wide variety of gateway types that will be needed, from very inexpensive gateways that could be spread through a broad deployment to very-high-end platforms with sophisticated applications running locally on the gateway. Having the right processor for each of these types will be critical in an increasingly cost-sensitive market.

There will be a variety of radio protocols that will be deployed; none of them will “win.” For instance, a device that might be primarily controlled by a smartphone might want to use Bluetooth Smart given the prevalence of Bluetooth Smart in smartphones, whereas a device that’s part of a home security system might be connected with ZigBee IP, or a white goods device might use Wi-Fi. However, the important thing is that all these device types are able to talk to each other, that they have a common software framework on top of the radios that allows data interoperability. My own home is an example of the problem – I have a dedicated phone line to remotely control my pool/spa, Philips Hue light bulbs that use ZigBee Lightlink, a remotely controllable front door lock using Z-Wave, and a remotely controllable thermostat using Honeywell’s Redlink protocol. The result is a stack of gateways in my dining room, and having to buy an extra Ethernet switch to connect them all – and fortunately I’m an engineer able to get it all working. Bringing Internet Protocol and Web services to even the tiniest of devices will be the key to solving this problem.

Going forward, gateways will be multi-tenant devices. That is, there might be one gateway in the house – which could even be a TV or set top box – but the sensors in the house may be controlled by multiple service providers, home security and home automation, for example. This creates a very strong need for interoperability and even further demonstrates the need for a common software framework based on standard Internet protocols.

How is ARM and its Sensinode business unit approaching these challenges? 

The first thing is to ensure that all communication protocols are developed in one standards body, namely the Internet Engineering Task Force (IETF), where all Internet protocols are developed. Then, as the various alliances develop application- or radio-specific solutions, they can use these standard protocols and focus on the application layer. This ensures every device can communicate in a standardized way.

The next part of the solution is to ensure that every device on the planet, even the tiniest of “things,” has an IP address. 6LoWPAN is a standard from the IETF that is an optimized form of IPv6 for low-power networks. We have driven the development of 6LoWPAN to help with this goal for a variety of radios. For instance, next-generation ZigBee as well as power-line carrier standards are based on 6LoWPAN, and there is also a standard for putting 6LoWPAN on top of Bluetooth Smart to make it an IP-based radio.

Then these tiny devices need an efficient application layer protocol. That’s where the Constrained Application Protocol (CoAP) comes in. CoAP is analogous to HTTP but optimized for IoT devices, allowing lower power, lower processing power, and less bandwidth utilization. And of course, application-layer security is crucial for all IoT applications. In the Web today, TLS is the gold standard for security. DTLS is a sister standard that runs on UDP instead of TCP. ARM is driving a new standards effort in the IETF around eDTLS, which further optimizes the communication mechanisms of DTLS.

Beyond the protocols, the other challenge is that there will be a huge variety of device types in IoT, posing a huge challenge for embedded developers. To address this challenge, ARM has launched the mbed community, an open source solution with a Software Development Kit (SDK) that allows embedded software developers to quickly get their idea from concept to prototype to commercial deployment.

Finally, the data from these devices needs to go somewhere, to a backend. ARM has developed the ARM Sensinode NanoService solution, an end-to-end solution that consists of a very small client on the device and a backend platform called the NanoService Platform that may sit in the cloud or a customer data center. The NanoService solution uses CoAP and eDTLS for communication, but adds sophisticated data management capabilities on top of this. There are a wide variety of applications and markets in the IoT, and the NanoService solution allows each one of these applications to be developed as a simple Web app, allowing customers to leverage the millions of Web developers in the world. It truly brings the power of the Web paradigm to the IoT. 

What do companies looking to participate in the IoT need to consider to best prepare themselves for impending rollouts?

The key things that will allow most companies to differentiate in the IoT is device design (including things like form factor and power consumption) on the device side, and application design in the deployment application. The communication between these should “just work.”

ARM Ltd.

arm.com/markets/embedded/internet-of-things-iot.php

@ARMEmbedded

Google+: plus.google.com/u/0/+arm/posts

YouTube: www.youtube.com/armflix