OpenIoT Summit 2016



Below are some rough notes and thoughts from Linux Foundation’s OpenIoT Summit April 4 - 6 in San Diego.

Event web site: http://events.linuxfoundation.org/events/openiot-summit

Summary
IoT is all about communication (between devices and to the cloud) and its impact on revenue (where value-added services (compute/control) are located). Most IoT devices today operate in silos, independent of each other (e.g. Nest, Fitbit). This “island of devices” model can help companies capture brand “loyalty” and potential continuous revenue streams at a cost of bad user experience and freedom (e.g. iOS and Apple app store). In a way, this is similar to how the Internet operated before the advent of HTTP and HTML (silos of information separated by incompatible protocols, networks and data formats).

Interestingly, the situation above did not result from a lack of available IoT standards (protocols and frameworks). In fact, it is the very opposite – there are actually too many IoT standards that claim to be the only open and interoperable solution! This results in confusion and wasted efforts in the IoT ecosystem as companies spend more time and resources working on supporting various IoT standards rather than their value differentiator. It does not help the situation when Qualcomm - the founding member of Alljoyn (Allseen alliance) decided to support the competing framework (IoTivity (OIC/OCF)) as well.

Most of the companies at the conference prefer proximal rather than cloud control of IoT devices under the guise of privacy and security concerns. However, this maybe a biased view as none of the companies that presented owns any significant IoT cloud market share (like Google or Fitbit). There is a mistrust of IoT cloud companies by device manufactures - as the former could potentially create a walled garden that can exclude vendors and reap most of the revenues from value-added services.

Finally, there was a lot of concern about security. Linus Torvalds and others spoke frequently on the “unpatchable” nature of IoT which presents a significant security risk, as IoT devices are “real physical devices” rather than just software applications.

Obligatory xkcd

Notes
IOT transports and frameworks
  • Transports
    • Wifi
      • Ubiquitous
      • Good range & BW
      • High cost and power
    • Bluetooth smart (low energy)
      • Standard on most mobile devices
      • Low BW
      • Medium range
      • Low cost and power
      • Mesh network is coming
    • Zigbee
      • 802.15.4
      • Low range & BW
      • Low power
      • Very low cost
      • Mesh network
      • Known to have interoperability and interference problems
    • Zwave
      • Proprietary
      • Low BW
      • Medium range
      • Low power
      • Very low cost
      • Mesh network
    • Thread
      • 802.15.4 + 6LoWPAN (IP addressable)
      • Low BW
      • Medium range
      • Low power
      • Low cost
      • Mesh network
    • EnOcean
      • Ultra low BW
      • Energy harvesting - no power consumption!
      • Medium range
      • Low cost
      • Requires special antenna
  • Frameworks
    • IoTivity (OIC/OCF)
      • CoAP (REST model)
    • AllJoyn (AllSeen Alliance)
      • Started as Qualcomm project - now a Linux foundation project
      • D-BUS with RPC/RMI model
    • HomeKit (Apple)
      • Walled garden - requires MFi chip
      • Not widely adopted
      • No killer app from Apple
    • Google Weave
      • Heavy coupled with Google cloud
      • REST model
      • WiFi and BLE
      • Different from Nest Weave… aren’t they the same company?
MQTT
  • Lightweight pub/sub protocol (store and forward) with reliable bidirectional message delivery
  • Runs on top of TCP/IP (some variant can run on non-TCP/IP network)
  • QoS includes:
    • 0 - at most once
    • 1 - at least once
    • 2 - exactly once
  • Used by FB Messenger
IoT programming model
  • Local/proximal control/orchestration
    • Lower latency
    • Data stays local (privacy + security)
    • Fog model (where data collection and preprocessing is done by border gateway devices)
  • IoT frameworks (from lower level to higher)
    • Zephyr (RTOS for IoT) - for devices too small to run Linux (e.g. no MMU)
      Ostro - IoT Linux (built using Yocto)
    • Soletta - yet another IoT API framework
    • MRAA library
    • Intel IoT services orchestration layer
Comments

Comments