Americas

  • United States
Contributor

The future of IoT device management

Opinion
Feb 28, 20186 mins
Internet of Things

Protecting consumer IoT hardware investments.

The Internet of Things (IoT) continues to expand its reach into homes, businesses, social settings, and other environments, as more and more devices are connected with the purpose of gathering and sharing data.

Clearly, there are several potential benefits of IoT from a consumer standpoint. Apart from the convenience aspect, smart connected products can lead to increased energy efficiency, improved safety and security, higher product quality, etc.

But unfortunately, the current consumer IoT device landscape is still immature. For consumer IoT devices to thrive, device management capabilities need to evolve in a few ways.

IoT device management is the process of authenticating, provisioning, configuring, monitoring and maintaining the device firmware and software that provides its functional capabilities. Effective device management is critical to establishing and maintaining the health, connectivity, and security of IoT devices. IoT application vendors typically provide comprehensive device management with their solutions. But all bets are off if that application vendor goes out of business and you would like to use your devices with a similar application from a different vendor. Consumers are increasingly faced with unexpected device obsolescence and landfills are starting to fill up with expensive IoT bricks. What consumer IoT needs is a truly open IoT device management ecosystem.

Closed device enablement

Today, many connected consumer IoT devices are still sold as a part of a completely closed, vertically-integrated solution stack. The solution provides the IoT devices, network access (either LAN or cellular), perhaps an IoT gateway, and a cloud service.

All these components are knitted together by a single vendor to work together seamlessly as a part of a closed application-layer solution. For example, a smart luggage tag device might work perfectly well with the vendor’s luggage tracking application. But that luggage tag is unlikely to be compatible with any other vendor’s luggage tracking application. If you decide to switch to a different application vendor, you will need to get new luggage tags from that vendor.

It’s easy to see why IoT application providers like this approach for device management. It creates high consumer inertia that, while being in the best interest of the company, may not be in the best interest of the consumer.

App-specific device ecosystems

Another IoT device management model is to create a more loosely-coupled, semi-closed, “device vendor ecosystem” for an application. Examples of this are Samsung’s SmartThings home automation service or Comcast’s Works with Xfinity. With these services, a multi-vendor ecosystem of devices is certified for compatibility by Samsung or Comcast with their IoT gateways.

This means a consumer can buy devices from a heterogeneous mix of vendors and easily onboard those devices to enable an application.

While this approach provides significant advantages over the closed model, it also has flaws. For example, if you decide to switch application vendors (say moving from Samsung home automation to Xfinity), it doesn’t mean you can make another home automation gateway and cloud provider work with your installed IoT devices. It depends on whether the devices are certified as being compatible with the new application provider’s device ecosystem.

Even when the consumer can use an IoT device with a different provider’s service, the on-boarding process is often more complicated than it should be. That’s because the new device management process might be very different from the old one and those differences introduce an added element of complexity for consumers who are already familiar with another process.

Both approaches to device management can lead to device obsolescence and consumer frustration. If a consumer gets frustrated with the application provider (or the provider goes out of business as many startups do), the device investment is lost.

The future: standards-based device management

One potential vision for the future of consumer IoT – one which might be a lot more appealing to consumers – involves IoT devices whose identity and firmware are managed using a standardized process and entirely independently from the application layer service.

When you buy a connected consumer IoT device, you should be able to securely associate that device’s identity with your personal identity and securely manage its software and firmware using a familiar, standardized workflow supported by all device vendors. This means that any consumer IoT device should be easily associated with any consumer IoT gateway that supports its protocols and be able to get to the device vendor’s management service.

You then need a way to associate that device with any provider of application layer services that you choose. When you sign up for an application layer service (say for home automation), you should be able to easily allow the application to discover relevant IoT devices associated with this identity and provision them for use.

This approach would result in the creation of a truly open consumer device management ecosystem, where device ownership and management are always under the consumer’s control, independent of the status of the application provider. With this model, the consumer could try one home automation service provider today and a totally different one tomorrow, without replacing a single device.

For such a model to work, the IoT industry needs an open device management standardization effort. Thankfully, such efforts are currently well underway. They include the Open Mobile Alliance’s Device Management (OMA DM) and Lightweight Machine-to-Machine (OMA LWM2M) protocols. While these efforts are establishing standard communication protocols for IoT device management, they will also need to focus on shaping a standardized user experience to eliminate friction for consumers.

There are many standard, de-facto standard, and proprietary protocols in use, such as UPnP and the Apple Bonjour protocol (used for Apple’s HomeKit solutions). The Allseen Alliance AllJoyn protocol, now under the Open Connectivity Foundation (OCF) alongside Iotivity, is intended to run across the spectrum of devices from tiniest IoT device to a home hub or relatively powerful headless edge-computer and has a very large footprint of deployed devices. Some cross-device standards are yet to gain a foothold in the market, and for some established approaches, there is a move to other approaches as the market continues to evolve and consolidate.

When all IoT device and gateway vendors support a plug-and-play, open and secure, standards-based, device management capability (one that is independent of any vendor applications) and application vendors provide a mechanism to easily and securely discover and onboard those devices, then consumer IoT will achieve a new level of maturity and consumers will be able to fully embrace connected devices without the fear of losing their hardware investment.

Contributor

Dean Hamilton is an engineer, serial entrepreneur and technology executive with over 30 years of innovation experience. As Director of Engineering for NetExpress, Dean pioneered packet switching and routing hardware and software technologies (such as x.25, Frame Relay and ATM). As co-founder and CEO of CoSine Communications, a first-of-its-kind virtual network computing platform, Dean led the company through its successful IPO. At Cosine, Dean pioneered the technologies and business strategies associated with network-based computing services (now known as Cloud Computing) and network virtualization. Dean has also led successful technology innovation efforts in the areas of next-generation networking, cloud orchestration, machine-to-machine communications, internet of things and enterprise network security, in both large public companies and venture-backed startups.

Dean is currently General Manager of the Service Enablement Business Unit of Accelerite.

The opinions expressed in this blog are those of Dean Hamilton and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.

More from this author