IoT Device on-boarding for real people

Did your grandmother walk 5 miles to school?  Uphill?  Both ways?

Each generation has their hardship stories.  I remember telling my kids “When I was your age, I had to walk all the way across the living room to change the TV channel.  Uphill.  Both ways.”  My kids might tell their kids “When I was your age our DVRs didn’t tell time.  We had VCRs and it was always 12:00 Midnight.”

Apparently it really was a hardship because the clocks on virtually all the VCRs ever manufactured have blinked 12:00 midnight continuously since the day the VCR was invented.  Well, not continuously.  Everyone tried to set the time on their first VCR.  Some even succeeded.  But even those Mensa candidates gave up after the first few power outages and let the VCR clocks blink.  Often they blinked hidden behind a strip of black duct tape, but blink they did.

So why are the jokes about blinking VCR clocks anachronistic now?  It isn’t because we got rid of the VCR.  It’s because a time signal is fed to the clocks in DVD and DVR boxes though the cable, from a local radio time server or over the Internet.  We relieved the device owner of ever having to set the clock.  This suggests an answer to something that’s been puzzling me for a while now.  Cisco says that 50 billion devices will be online by 2020 whereas the folks at MAYA Design predict trillions of devices.  Why the big disparity?  Perhaps Cisco anticipates we’ll get a lot of the User Interface wrong and MAYA figures we’ll get it right.  Cisco’s version may account for trillions of devices existing but only 50 billion of them successfully connected to the network.

Though a bit tongue-in-cheek, this scenario is depressingly plausible.  So let’s agree to fix that right from the start because without dead-simple on-boarding we have a bunch of really expensive dumb devices.  On-boarding should be the FIRST thing we solve really well in the Cambrian Explosion of IoT.

Here’s my proposal:

User experience on-boarding a new device

• User signs onto a local web-based dashboard and enters or scans the unique ID of the device.
• User powers up the device and presses the WPS button on the router.  (Don’t worry, I realize WPS is horribly, horribly broken.  This is covered later)
• The device is now provisioned locally.  The dashboard is populated with the device details including version, supported behaviors, etc.
• If there is network connectivity, the dashboard is also populated with vendor information.
• Depending on the device type, the dashboard may also now display options to send data to the vendor and/or receive data from the vendor.  These options could include graduations in the granularity or types of data and even the ability for the vendor to send control commands for some device types.
• Depending on device type, the dashboard may offer options to send data to 3rd parties.  For example, a dimmable bulb might offer to participate in discretionary load control by exchanging data with the power company.
• On the local network, the device publications can be subscribed by any authorized user app or device.

 

Under the covers

Many devices coming to market today require you to first set up a gateway device, then bond the device to the gateway.  Some gateways are severely limited in the number of devices they can host.  Worse, the gateways are proprietary and add considerably to the base cost of a system.  Once you invest $199 for a gateway, you really don’t want to switch to another vendor’s device.  This is not accidental.

In my scenario, the gateway device isn’t vendor specific but just an MQTT app running on the local network.  It can be in a set-top box, game console, NAS drive, PC or whatever. I also require a DHCP server capable of performing port forwarding and a guest network that doesn’t route anywhere.  A standard consumer-grade router like the Linksys WRT-54G is capable of doing most of this today.  It just needs a slight tweak to allow internal port forwarding.

How does the device find the MQTT broker?  There’s a little bit of magic in the provisioning, but not much.  The DHCP server has to be configured to internally route incoming connections on the MQTT port to the IP address of the MQTT broker. This is known as Port Forwarding and is standard on most consumer-grade routers.  Once it is set up, any connection to the router on that port is forwarded to the configured IP address.  For our purposes, the router needs the ability to forward connections on the internal network while blocking those from the external network, or to do both.

From the perspective of the device, it simply acquires a DHCP address in the usual way, then connects to that same address on MQTT port requesting access to the pre-provisioning topic.  The DHCP server is the one local IP address the device will always know so there’s no complex discovery mechanism or exotic protocol required.  The connection is forwarded by the router to the MQTT broker using the port forwarding described earlier.

During the connection, the device provides it’s X.509 certificate as part of the SSL handshake.  The broker matches the identity in the X.509 certificate to the expected identity which the user previously scanned or keyed into the dashboard.  Assuming the two things match, the device is allowed to connect and publish a provisioning request on the pre-provisioning topic.  The message contains a unique random string (nonce).

The dashboard app replies to the request with the SSID and password of the private network, plus the nonce.  This message is signed by the app and encrypted with the public key of the device so it can’t be read if intercepted, and man-in-the-middle, spoofing and replay attacks are prevented.

The device stores the provisioning configuration into memory, disconnects and then reconnects to the private network.  Each time the device connects or powers up, it publishes it’s metadata to the dashboard: device type and ID, vendor, vendor publication and subscription URLs, etc.  These populate the dashboard and activate the options seen by the user.

 

What’s outstanding?

First, we need the routers to perform internal port forwarding.  For proof-of-concept implementations the Tomato or DD-WRT firmware could be modified with this functionality.  If a market emerges, I’d expect Linksys, Netgear and others would add this support.

The other router modification is that WPS is required on the guest network but not the private network.  The guest network is configured so that all traffic addressed to anything but the router goes to the bit bucket.  The only connection the router accepts on the guest network is forwarded to the MQTT broker and that is authenticated with a certificate and Client ID.  So WPS on the guest network is OK because we don’t depend on it for security.  We just like the button that allows a device to connect.  But since WPS is broken, we need it disabled on the private network where we can’t afford for it to be hacked.  The tricky part here is that Tomato and DD-WRT undoubtedly have WPS disabled and may in fact not even have code for it.  I haven’t checked yet but I will.

Obviously, the dashboard is required.  For a POC, this could be as simple as shell scripts.  For the real-world Average Joe user a nice GUI would be expected.  Since all this runs on MQTT, the dashboard could run on anything including Raspberry Pi, Arduino, Roku, X-Box, NAS drive, Plug PC, desktop PC, whatever.

Other than that, it’s mainly a matter of defining the topic schema so devices know how to query for provisioning details.

 

Flexibility

I can hear some of the objections already.  “The user has to set up port forwarding?  An MQTT broker?  Guest and Private networks?”  Not necessarily.  It makes sense that the device vendor would provide basic, free implementations of the dashboard and MQTT broker on their own web site.  If the user can just get the device connected, it can by default publish and subscribe at the vendor’s broker.  Now the question is how does the user connect the device?  Well, there’s no reason the guest network has to be hosted in the user’s router.  It would be simple and easy to sell a cheap consumer router, customized and pre-configured to provide the guest network and WPS.  The user plugs the dedicated router into their existing network and it tells any devices that connect to route all traffic back to its vendor’s web site.

Since you can buy a cheap WI-Fi router for about $50, I’m guessing that would be the price point for the customized version, assuming the vendor didn’t just give it away as a loss leader.  The Philips Hue Bridge adds $20 to the price of 3 LED bulbs but it interacts only with Hue devices and supports no more than 50 of them.  Our customized $50 Wi-Fi router would work with any device using this protocol and support thousands of them.  So, yeah, it’s as much as $50 but then it’s far more functional and you can build on it.

 

User-friendly tiers of functionality

My design goals for the on-boarding were to support unlimited local functionality and 3rd party participation, full user control of the data and who gets what, dead-simple setup, but that all this would degrade gracefully all the way down to a disconnected smart device that still manages to work as you’d expect.

So the degrees of functionality are:

1. No network:  Device behaves like dumb version of same category device.  Requires nothing of the user.  Plug-and-go.  I didn’t talk about this earlier but it s an assumed requirement.  My house must not blue-screen if the network goes down.  (Although if I had LED bulbs like Hue or LIFX, I’d program them to glow the same shade of blue on fatal errors.  I know, I’m sentimental.)
2. Custom gateway or Current technology WPS router, no local NAT, no local MQTT broker: Gateway or WPS router connects the device to the network.  Device connects to the vendor who provides additional functionality, web app, phone app, dashboard, etc.
3. Device finds local MQTT broker, attempts to register, registration fails: Falls back to #2 if device is registered at the vendor’s web site.  The owner receives an exception notice.  If the device is not registered and the vendor does not have an anonymous service (some devices are report-only and would support anonymous publication to the vendor) then the device falls back to #1.
4. Device finds local MQTT broker, successfully provisions: Bob’s your uncle.

Note that the most the user must do is to run a local MQTT broker and dashboard, then configure their router with port forwarding and activate the guest network feature.  That’s worst case.  It’s comparable to setting up a multi-function printer today and it can only get better because consumer-grade routers will need to change if we are to provision 50 billion devices.  In fact, we should expect to see competing premium versions of the dashboard that provide advanced features.  These could be drop-in replacements for your router or delivered as installable software for your PC, NAS drive, plug computer or whatever.  At some point the anonymous WPS network and port forwarding will be built into the router right out of and enabled the box.

Between these price points will be the customized routers that implement a turnkey guest network with WPS enabled.

The absolute worst-case here is far better than the best case for proprietary gateways that lock you in the vendor’s walled garden.  It is even better than the Philips Hue where the bridge has an open API but supports only 50 devices and uses REST instead of pub/sub.  We have a use case that demands a bit more of the user today but comprised of tasks that can be easily automated so the user’s experience is on par with the clock on their DVR.  Plug and go.

Future generations

We have a 6 year-old in the house.  I don’t know hat hardship story his mom will tell him in a few years.  But if I have my way,  I know what it wont be:  “When I was your age we had to type 50 commands before our devices attached to the network and became smart.  And the keyboard was tilted uphill.  Both ways.”