Beyond The Last 0.01 Mile
The proliferation of connected devices is facing designers and OEMs with some basic connectivity problems; local is relatively easy, the remote not so.
Any issues with local connectivity are more or less solved due to Bluetooth® and Wi-Fi™ solutions with accompanying SDKs and protocol stacks. Within the home, security models and connection ranges work. Bluetooth’s pairing and Wi-Fi’s access point credentials are generally established and understood, Bluetooth works within the room and Wi-Fi works throughout the house. The controller of the device is usually a personal handset, and while the Bluetooth experience is comparable to that of the classic remote control – if you can see it, you can control it, the Wi-Fi experience allows longer ranges, but is still limited to the home’s perimeter.
Once outside home, all this breaks down. Even Wi-Fi may fail in the garage or in the yard. It seems that the consumer is stuck with the old-fashioned remote control.
The Server Model
To solve this, OEMs have started to deploy the new third party, servers. In this model, both the device and the controller are clients of a server running some application. The client connects to the server via the local Wi-Fi and ISP; the controller usually connects via the mobile broadband.
Why servers? Why not connect directly?
The short answer is that IPv6 has miserably failed its promises (for dissection see http://tinyurl.com/djwkt.) Presently, both the controller and the device are almost always behind NATs and cannot reliably communicate directly.
The fastest way to deploy the server model has been to use the most widely spread framework, the web. This, in turn, required:
1) Full TCP/IP and SSL/TLS stack on each device
2) Persistent connections to enable fast reaction times
3) Creating identities for each device and each controller on each server/service and onboarding each
4) New staff to program and maintain these servers
Each of these aspects has downsides:
1) Low-cost device hardware can hardly afford to host browser-class stacks
2) Millions of concurrent TLS sessions require thousands of servers to handle them
3) Mapping identities and having yet another dashboard and setup per device to manage is unappealing to consumers (and you thought BT pairing was hard)
4) More engineers, whether directly engaged or outsourced with huge markups on the ‘cloud’, are hardly affordable from revenues on $30-$100 devices
The web model handles these issues because each client has a human behind it, with subscription or advertising-based revenue. When there are 20 or 100 connected devices per consumer, the web model just doesn’t work. The current cost for remote connectivity services stands at about $1 per device, per year.
The IoT/IP Model
Given that connectivity inside the home works, we have focused to develop a framework which extends that connectivity beyond the home perimeter at minimal cost, without introducing new associations, procedures or human interfaces. The goal is to minimize OEM development and deployment costs, while making the remote consumer experience indistinguishable from the local one. The framework is implemented as an extension of the IPv4 stack.
The basic features of the IoT/IP model are:
- Large private 128-bit name space
- Secured connections with forward security
- Transparently and securely extends existing local identities and associations (pairings) to remote connectivity
- Super-low latency comparable to end-to-end ping times
- Reliability behind NATs and firewalls
- Very low session-free load on the infrastructure
- Connects devices to controllers, other devices, and 3rd party servers
- Ephemeral storage for offline log pickup and firmware updates
- Wide range of bitrates, from few bps to real-time video
4) Low cost and ease of deployment
- Small firmware footprint
- Invisible to consumers
- Nearly invisible to developers – the SDK abstracts IoT/IP to familiar interfaces
- Zero onboarding – purchase of the firmware license per device gives lifetime access to controllers and 3rd party servers
The IoT/IP is supported by our switching and storage infrastructure, placed on bare metal at the premium colocations for low latency and for low latency and high availability, connected by multiple bandwidth providers.
The IoT/IP Development Cycle
The idea is to blur the difference between local and remote connectivity while giving OEMs full freedom to design their applications and minimize the effort spent on enabling remote connectivity.
Developers use IoT/IP SDK for devices and handsets (and servers, if appropriate) to extend the local connectivity. This process involves deriving remote credentials from the local ones, adding IoT/IP calls to the communication paths, and shielding the existing applications from the changes by middleware provided with sample applications.
SDKs are available for:
- Firmware (Broadcom, TI and Marvell)
- Handsets (iOS and Android)
- Servers (any Unix-based: Linux, Mac OSX, *BSD, etc.)
SDKs come with all required libraries and sample applications, and provides datagram and reliable connection models, as well as key-value based storage facility. All connections are secured and authenticated.
Two basic services are supported: Conduit for real-time communications and EStorage for ephemeral storage.
The Conduit program flow involves creating virtual connection with the remote device, and then sending and receiving data packets. This can be used to support any existing local communication requirements.
The SDK provides additional features on top of the native IoT/IP functionality:
- Reliable transport
- End-to-end encryption
EStorage service allows for storage and retrieval of key-value pairs. This can be used for storing historical records (periodically picked up by controllers or 3rd party servers for analytics), video streaming and storage, or for providing firmware updates to devices.