One reason Linux — and by extension Android — have grown so quickly in embedded is that from very early on Linux was imbued with strong wireless support. Although ARM and others are working hard to improve wireless support on microcontrollers with efforts such as ARM’s Mbed OS, for the most part if your gizmo needs WiFi, you need to set aside MCUs and RTOSes and move to Linux or Android running on a faster processor.
Last week, we saw three major developments in the wireless world that embedded Linux and Android developers will need to pay attention to. First, the Wi-Fi Alliance announced a Wi-Fi Aware technology that gives Bluetooth-like proximity awareness and service discovery to WiFi users. Second, Google rolled out an open source “Eddystone” Bluetooth LE beacon format as an alternative to Apple’s iBeacon. Finally, the Thread Group consortium released the first version of its 6LoWPAN-based Thread short-range wireless protocol.
All of these technologies are designed to solve parts of the Internet of Things puzzle. The first two in particular bring us closer to proximity-based services, such as location-based marketing.
Wi-Fi Aware
The Wi-Fi Alliance’s new certification program for Wi-Fi Aware devices has already approved WiFi chips from Broadcom, Intel, Marvell, and Realtek, and should appear in products and apps by the end of the year. Wi-Fi Aware essentially makes WiFi more like Bluetooth technologies such as iBeacon, but with greater bandwidth and range.
The technology implements a constant, low-power, heartbeat-like detection pulse at both 2.4GHz and 5GHz in order to discover other Wi-Fi Aware devices. After discovering each other, the Wi-Fi Aware devices synchronize and can form clusters of devices which share and pass along information, thereby notifying the user about nearby services or people of interest. This discovery mode can easily transition into a high-bandwidth, peer-to-peer WiFi Direct transfer.
Wi-Fi Aware works in regular WiFi range, and can operate indoors or in crowds, providing GPS-like contextual awareness services when GPS does not work. The technology makes no use of cellular connections, and is said to pose no “undue burden” on one’s battery.
As with most always-on technologies, there are privacy concerns. The Wi-Fi Alliance, which is run by industry giants including Apple, Intel, and Microsoft, promises that users will have privacy controls and can opt out of notifications. The idea is that you can set preferences to discover devices with certain services or at particular locations while blocking others.
The Alliance notes applications including finding nearby game opponents or LinkedIn contacts, but proximity marketing seems to be the main pitch. For example, a beacon could send you a message about sale items of interest, or you could enter the name of a particular product in a Wi-Fi Aware ready app such as a Facebook app due by year’s end, and Facebook will notify you when you are a near a store selling the product. A GigaOM Research study is cited claiming that proximity-based mobile social networking will triple in size to be a $1.9 billion business by 2016.
The first certified products include the Broadcom BCM4358, Intel Dual Band Wireless-AC 7260, Marvell Avastar 88W8897 802.11ac, and Realtek RTL8812AE 2×2 a/b/g/n/ac MiniCard chipsets. According to the Wi-Fi Alliance, some mobile device users may be able to update existing chipsets via software.
Google’s Eddystone
Google announced an open-source, cross-platform beacon format for Bluetooth Low Energy (BLE, or Bluetooth LE) called Eddystone, which in turn works with a new Proximity Beacon API. Eddystone and the API are billed as an alternative to the closed-source, iOS-specific Apple iBeacon technology. Eddystone is available in sample apps released this week for Android and iOS.
Unlike Wi-Fi Aware, iBeacon and Eddystone are one-way protocols. For example, Eddystone beacons can be set up in places like airports, museums, and bus stops to send brief messages about available services and/or invitations to establish a more robust, two-way Bluetooth or WiFi session. The beacons can also operate while mobile, and Google imagines them being used in fleet management.
Eddystone is one of three beacon formats supported by the Proximity Beacon API, which also supports iBeacon and the open source AltBeacon. iBeacon supports only the Universally Unique Identifier (UUID), which requires a special app for each set of UUIDs. By contrast, Eddystone also supports several other broadcast frame types. These include URLs, which are supported by any web browser and does not require a special app. Similar URL technology is found in Google’s experimental, Bluetooth based Physical Web project for device interaction, which is switching over to the Eddystone URL frame type.
Eddystone also supports a more secure format called Ephemeral Identifiers (EIDs). EIDs can also identify how far you are from your beacon, which could be attached to luggage or a set of keys. Finally, there’s a Telemetry Data frame type designed for battery-powered applications like fleet management. This format sends diagnostic information, including remaining battery power, to enable timely maintenance.
Eddystone-ready BLE beacon hardware is available from BKON, Bluevision, Estimote, Kontakt.io, Radius Networks, and Signal360. According to ArsTechnica, which posted an in-depth overview of Eddystone. Radius Networks attempted to replicate iBeacon technology in one of its beacons, but Apple temporarily shut it down.
Like Wi-Fi Aware, Eddystone will only be useful if it’s widely implemented. With iBeacon already available, we imagine Eddystone will spread more slowly than the more widely supported Wi-Fi Aware. However, it has the advantage of cross-platform support, allowing it to run on many more devices than iBeacon.
Thread protocol released
While Wi-Fi Aware and Eddystone build on other established wireless protocols, Thread is a wireless protocol of its own. The Thread Group announced its formation a year ago, along with plans to develop a 6LoWPAN-based, open source wireless standard for home automation called Thread. Now, the consortium has released version 1.0 of the low-power, short-range protocol to members, who can start working on Thread products.
A Thread product certification program will launch in September, at which point Thread compliant chips and software stacks should be available from ARM, Freescale, and Silicon Labs. End-user products such as routers and home automation equipment should arrive by year’s end. Presumably, there will be early compliance from Nest’s thermostat and smoke/CO2 detector products, as well as Yale Security smart locks, among other member products.
There are now more than 160 Thread members. Original core members included ARM, Big Ass Fans, Google’s Nest Labs, Samsung, Silicon Labs, and Yale Security. These have since been joined by Somfy, Tyco, and this week’s big addition, Qualcomm, which oversees the IoT-oriented AllJoyn standard, supported by The Linux Foundation’s AllSeen Alliance. AllJoyn/AllSeen has been one of the more successful of the many IoT interoperability frameworks that have emerged in recent years. The several dozen contributing members to Thread include Analog Devices, Atmel, Imagination Technologies, Insteon, Intel, Kwikset, LG, Marvell, MediaTek, Microsoft, NXP, Philips, SmartThings, and Whirlpool.
The Thread protocol aims to solve problems with out-of-date, short-range mesh networking standards like ZigBee and Z-Wave. Because it’s based on the same IEEE 802.15.4 standard, most existing devices should be able to be updated via software, says the Thread Group. Thread is specifically based on 6LoWPAN, which was born with IPv6 in mind. In addition to offering better IPv6 support, Thread uses less power, and is more interoperable, robust, secure, scalable, and easier to set up and control than other 802.15.4 protocols, says the group. It is also said to more easily support self-healing mesh networking.
