A look into Bluetooth v4.2 for Low Energy Products

The Bluetooth v4.2 Specification was officially adopted in December of 2014 by the Bluetooth Special Interest Group (Bluetooth SIG) and it brings a host of updates to Bluetooth Low Energy (BLE) or Low Energy (LE) for short. Although no Bluetooth chipset vendor is officially supporting it yet, support will make its way into devices in the next few quarters. There are quite a few updates in the v4.2 specification, and we’re going to go over them and how they can affect your product and design decisions.

LE Data Packet Length Extension

One of the most exciting changes in the specifications is the increase in the Packet Data Unit (PDU) size from 27 to 251 bytes. This is the amount of data sent during connection events. To support the increase requires several updates. One difference is a change in the Header of the Data PDU. This header precedes the payload sent. In the header, the packet length field increased from 5 bits to 8 bits. Below is the header for the Data Channel PDU, comparing the v4.2 and v4.1 (v4.0 as well) variants:

Figure 1 - Comparison of Data PDU Header Definition

The extra 3 bits used from the Reserved for Future Use (RFU) field enable the controller to indicate that the packets it is sending are up to 256 bytes.

Although the length field has a range of 0 to 255 bytes (for 8 bits), the MIC at the end of the packet is 4 octets (bytes) long, so that leaves us with 251 bytes which is the maximum payload size.

As part of the connection process, both devices go through a data length update procedure where the LL_LENGTH_REQ_PDU and the LL_LENGTH_RSP PUD are exchanged to negotiate the maximum size used. During this process, any data already queued uses the previous size. If a device sends a LL_LENGTH_REQ to a device that doesn’t support it, it will receive a LL_UNKNOWN_RSP PDU back. This allows backward compatibility with devices that don’t support the longer length packets, such as v4.1 and v4.0 devices.

The extra packet length is extremely important in the emerging IoT applications and for many current products, as we’ll see.

Take, for example, Over-The-Air (OTA) Updates, one of the most important features that products implement aside from their main functionality.

Even after a BLE product is sold, it’s common to continue and update the firmware on devices with both new features and bug fixes. Due to the 27 byte limit of Bluetooth v4.0/v4.1, a full OTA download can end up taking 10 minutes in some cases. This can be very frustrating for customers who expect fast updates. Interference and connection loss may happen during this long period, so it’s not uncommon to have an OTA process fail. With v4.1's byte limitation, the workarounds to this issue are expensive and complicated, so in reality only faster speeds are the solution.

With Bluetooth v4.2, you get a theoretical data rate of 800kb/s (increased from 270kbps for v4.0 & v4.1). In practice, of course, you won’t get 800kb/s because of data overhead, throughput limitations in other devices, interference, etc. but you can expect firmware downloads to go much faster.

OTA isn’t the only case where high data rates are used. Sensor logging applications are also becoming increasingly common, where large amounts of data are transferred. Faster data transfer reduces errors since transmissions are shorter and leave less time for other devices to interfere. It also speeds up the overall system and improves user experience due to lower latency.

Larger packets also prevent the fragmentation needed to transmit data in IPv6 data packets that would otherwise be split into 27 byte packets.

Efficiency is another advantage with large packets. When sending multiple 27 byte packets, there’s significant header overhead since every packet has its own header and needs to be reassembled and processed separately.

As an example, using 27 byte packets, a 160 byte message would require 6 transmissions. In addition to the data, each transmission adds a 2 byte header, plus the optional 4 byte Message Integrity Check (MIC helps detect errors and is required in some cases when encryption is used). So, we would have sent an extra 36 bytes for a total of 196 bytes.

With the increased packet length only one header and one MIC are needed for a total length of 166 bytes, so we reduce the number of bytes sent by 15%. The radio can then stay off for 15% more of the time, reducing power consumption.

What’s worse with small packets is that the extra packets don’t just incur the extra time during transmission, but also waste time in starting up, dead time between transmission, processing, etc.

Less packets sent mean less power is used, which is extremely good for BLE applications. The small payload in BLE data packets is probably one of the biggest issues developers are facing, and it’s good to see the Bluetooth SIG made it a priority.