In December 2014, the Bluetooth Special Interest Group (SIG) officially adopted the latest version of the Bluetooth core specification – Bluetooth 4.2. The new version includes a number of important updates for the developer, including such features as lower power consumption, faster data transfer, improved security measures and a new mechanism to improve user privacy.
However, perhaps the most important feature included in the Bluetooth 4.2 announcement, especially for IoT device developers, is the introduction of Internet connectivity. A key point to note is that there are different ways that this can be done: IPSP, HPS and RESTful APIs, all of which are essential mechanisms for the cloud to touch Bluetooth Smart devices and vice versa.
A newly created profile (a formal specification that defines Bluetooth-based wireless communication between devices) known as the Internet Protocol Support Profile (IPSP) is designed to enable IPv6 for Bluetooth, meaning IoT devices that are based on Bluetooth Smart no longer need to be paired with a smartphone or a tablet to connect to the cloud. It's estimated that, in 2020, about 28billion devices will be connected to the Internet; from your car and windows to your toaster and oven. With Bluetooth 4.2, these 'things' will be able to connect to the Internet using Bluetooth via a router or an access point that supports 6LoWPAN over Bluetooth Low Energy.
The HTTP Proxy Service (HPS) allows for Bluetooth Smart devices to communicate with remote web servers on the public internet. For example, Bluetooth Smart temperature sensors installed all over your smart home could post temperature readings to a cloud based home energy efficiency advice service. This requires a Bluetooth gateway that supports HPS, such as your smartphone, PC, laptop or tablet. It's a simple and commonly supported protocol, but not all applications work best with HTTP. Message oriented applications such as telemetry from cars may be better suited to, for example, the MQTT protocol.
RESTful APIs, which were also introduced alongside 4.2, allow the secure discovery, access and control of any Bluetooth Smart device using HTTP or HTTPS. An example of this is the ability to monitor the status of doors and windows equipped with Bluetooth Smart sensors in your smart home from anywhere in the world. As with HPS, RESTful APIs require a Bluetooth gateway that supports them. Additionally, use of HTTPS results in secure Bluetooth Low Energy connections on the other side of the gateway.
A key point regarding the RESTful APIs is that with a device such as a broadband router or smart TV implementing them, every Bluetooth Smart device in range then becomes securely discoverable and accessible from outside the home, and they do not even need to be 4.2 devices – they could be any device that supports Bluetooth 4.0 or later. This is a very exciting IoT feature because an entire home can be controlled by one 4.2 enabled router (providing the other devices use Bluetooth Smart, of course). So much can be achieved with relatively little investment.
IPSP differs in that it offers device manufacturers a way of implementing support for non-HTTP protocols in their products. IPSP proposes the support of exchanging low power IPv6 packets between devices over Bluetooth Low Energy (LE) transport. The actual transmission of packets will be specified by an IETF RFC, which will be confirmed later this year. It will also require a router that implements support for 6LoWPAN over Bluetooth.
Considering the potential for the exponential growth in the number of sensors and connected devices that the IoT will bring to the fore, IPv6 is suitable as a protocol because of the large address space it provides. In addition, IPv6 provides tools which are particularly well designed for sensor network applications and nodes which have very limited processing power or lack a fully-fledged operating system.
Figure 1 illustrates IPv6 over Bluetooth LE stack including IPSP. UDP and TCP are provided as examples of transport protocols, but the stack can be used by any other upper layer protocol capable of running atop of IPv6. The 6LoWPAN layer runs on top of the Bluetooth LE L2CAP layer (which is responsible for the segmentation and reassembly of packets which are larger than the underlying radio can handle). IPv6 is dependent on the L2CAP dedicated channels feature, which means that it requires Bluetooth 4.1 or later to function.
IPv6 could become very useful for large-scale industrial and commercial deployments where management of every end node could be implemented remotely via IPv6. End-to-end IPv6 connectivity could grant a boost to asset tracking and management. For example, it could support remote management of an industrial complex's heat pumps and control valves via a cloud platform.
Such services add value above and beyond the immediate benefits IPv6 connectivity offers developers. The ability to give access to and control of data provides a disruptive opportunity for service providers, who can use such data to offer exciting new cloud offerings in both the consumer and enterprise space, enabling them to experience the complete set of benefits the IoT can offer.
With HPS, IPSP and RESTful APIs, Bluetooth is firmly establishing itself as an internet-compatible technology. IPv6, is enabling interoperability in what will be a heterogeneous IoT world, in which networked devices utilise technologies that are most fit for their purpose and position in their given IoT architecture.
IPv6 simply makes it possible for Bluetooth devices to take part in a broader ecosystem of smart devices. Users can access Bluetooth Smart devices from the cloud via both the RESTful APIs and the HTTP Proxy Services that have been prescribed by our membership – IPv6 is just an additional option for SIG members. It allows developers to create solutions that can not only span their personal area network, but reach into the wider IoT.
Author profile:
Martin Woolley is technical programme manager at Bluetooth SIG
