Increased flexibility for Bluetooth Smart Ready devices

Bluetooth Core Specification v4.1, which was adopted by the Bluetooth SIG in December 2013, makes important evolutionary changes to the v4.0 core specification that opened a vast new application space for the technology four years ago by adding support for ultra low power (ULP) operation for a host of small, low-power devices such as activity sensors.

Some new v4.1 features simply incorporated improvements into the core specification that had been previously made to the v4.0 specification by addenda. Because the addendum process caused some confusion about what was or was not in the specification, the SIG will discontinue the procedure of using addenda and replace it with ‘dot’ versions of the specification, a development that will be welcomed by many developers, according to the Suke Jawanda, Chief Marketing Officer, Bluetooth SIG.

Taken as a whole, v4.1 more perfectly aligns the quite different use cases presented by Bluetooth technology’s long-standing streaming media mode, the more recent ULP operating mode, and Internet Protocol (IP)-connected operation in the future.

The previous core specification (Bluetooth v4.0) notably added ULP capability that enabled communication with sensors and other devices powered by coin-cell batteries. Known as Bluetooth Smart, the low-energy functionality and the restructured generic attribute (GATT) profile were major aspects of a revolutionary step forward for the technology. But the single-radio, low-energy sensor devices of Bluetooth Smart chips were compatible only with other Bluetooth v4.0 enabled products that have certain software implementations. A technology bridge between the Bluetooth ‘classic’ and Bluetooth Smart implementations was provided in a Bluetooth Smart Ready hub.

Since 2010, product life cycles of mobile phones, PCs, and tablet computers have led to a significant replacement of Bluetooth classic chips with Bluetooth Smart Ready chips. In many instances, the utility of Bluetooth classic chips has also declined due to market evolutions. The media streaming capabilities of smartphones, for example, have eroded the market for single-use Bluetooth-enabled devices such as MP3 players.

New products have also come on the market since 2010 and the new core specification addresses design issues that may have accompanied them. The emerging new challenges for the technology are best exemplified by the smart watch, which can make substantial demands on the mobile phone’s battery. Beyond that development, as the sheer number of small ‘activity devices’ equipped with sensors of one kind or another grows, the number of potential connections will grow with it, which could have become problematic.

Dual mode topology

From a ULP developer’s perspective, the most important single feature of v4.1 is ‘dual mode’ topology that allows a device such as a smartphone to act as a Bluetooth Smart Ready hub and a Bluetooth Smart peripheral at the same time.

The most obvious use scenario will be the ability to pass data from a sensor or smart watch to a mobile phone and then on to a PC if appropriate. Another attribute, which gives developers even greater freedom, is the ability to set up a scatternet.

Smart watch-to-phone connectivity will benefit from the enhanced version of Bluetooth technology (Courtesy: Connectedevice)

In its pre-v4.1 mode of operation, Bluetooth enabled communication by creating piconets. But its three-bit address space limits the maximum size of a piconet to eight devices — one hub and seven peripherals, which could negatively affect usability as the Internet of Things (IoT) expands. Now that the device can assume either identity, it is possible for a hub to communicate with many more than eight devices.

Another important change for developers gives them more flexibility in maintaining communication sessions. With v4.0, the interval between connection ‘advertisements’ from a Bluetooth Smart device to a Bluetooth Smart Ready device was fixed. Unfortunately, this meant that when an activity device such as a fitness monitor was physically separated from the hub, the connection could be quickly abandoned and had to be restored manually. Beginning with v4.1, the developer now sets the interval between connection advertisements.

Bluetooth v4.0 states that advertisers that want to perform connectable directed advertising should transmit a continuous sequence of advertising packets separated no further than 3.75ms for a duration of 1.28 seconds, according to Chris Archey, Senior Product Manager of the Bluetooth SIG. The new variant gives advertisers the option of transmitting a train of advertising packets on each enabled advertising channel, at a configurable advertising interval. Fewer advertisements also reduces power consumption by a modest amount, he said, but the real advantage is improved usability.

More efficient data exchange

Making data exchange as efficient as possible is another design issue that becomes more important with the hub’s ability to connect to multiple Bluetooth Smart devices, each of which might have a significant amount of data to share with the smartphone, tablet or portable computer. In v4.0, data exchange took place across the GATT level that is fairly high up in the protocol stack and each frame contains a sizeable number of header and footer bits.

Prior to L2CAP (Logical Link Control and Adaptation Protocol) being implemented in Bluetooth Smart, the device sending the data required an acknowledgement from the receiver before sending the next packet. This dependency caused more overall overhead in a complete transaction. The efficiency depends on the total number of packets being sent for a complete transaction and the implementation of the Bluetooth stack by the manufacturer.

Bulk data exchange scenarios such as downloading stored sensor data, or updating software on the device, maximises the value of opening a channel lower in the stack to eliminate the constant retransmission of identical header and footer bits. As Bluetooth radios find homes in more and more devices, it will become useful to allocate specific channels to avoid crosstalk. In v4.1, a direct channel is opened in the L2CAP layer. This enables multiple applications to utilise the same lower layer links. L2CAP was already part of Bluetooth classic (BR/EDR), version 4.1 included L2CAP for Bluetooth Smart and Smart Ready.

Before L2CAP was enabled in Bluetooth Smart and Bluetooth Smart Ready, an application request from one device to another would be managed in a serial method. A complete operation would need to be finished before the next operation could start, which is not very efficient. With L2CAP enabled, requests are multiplexed and managed in parallel, which is much more efficient especially as the number of Bluetooth connections between devices grows.

Internet connections

In addition to using L2CAP connection-oriented channels for multiplexing, creating this channel is also a requirement when implementing IPv6 communications — an important foundation-building aspect of Bluetooth v4.1. L2CAP provides a mechanism called Connection-Oriented Channels. Within Connection-Oriented Channels is the capability of Fixed Channels. Fixed Channels are channels that have dedicated numeric values associated with them. The function of Connection-Oriented Channels and Fixed Channels is a requirement in support of implementing IPv6.

John Leonard, Tactical Marketing Manager, Nordic Semiconductor, agrees that building a bridge between IPv6 and Bluetooth Smart traffic will be remembered as a critical functionality that began with Bluetooth v4.1: “Right now, there seems to be a lot of confusion about what can actually be done with IP traffic. The new core specification is not the end of the story and we do not have a complete picture yet – but it’s a fundamental building block.”

L4CAP is actually a pretty simple part of the overall protocol, he said: “Its function will be to disassemble IP packets to make them meaningful for Bluetooth Smart as well as reassemble packets moving in the opposite direction.”

The new specification is clearly looking forward to a time when seamless interactions with 4G/LTE will be critically important to Bluetooth technology. LTE coexistence issues such as overlapping bands in Europe, India, and China are addressed. In addition, Bluetooth High Speed technology is enhanced by adding support for the IEEE 802.11n MAC/PHY through an update in the protocol adaptation layer (PAL).

The Bluetooth v4.1 Features and Technical Descriptions document provides a succinct source of information for all of the changes and improvements implemented in in the newest core specification, including some security.