Path: EDN Asia >> Design Centre >> Communications/Network >> The lowdown on Bluetooth v4.2 for Low Energy products
Communications/Network Share print

The lowdown on Bluetooth v4.2 for Low Energy products

21 May 2015  | Gustavo Litovsky

Share this page with your friends

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: 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.

1 • 2 • 3 Next Page Last Page


Want to more of this to be delivered to you for FREE?

Subscribe to EDN Asia alerts and receive the latest design ideas and product news in your inbox.

Got to make sure you're not a robot. Please enter the code displayed on the right.

Time to activate your subscription - it's easy!

We have sent an activate request to your registerd e-email. Simply click on the link to activate your subscription.

We're doing this to protect your privacy and ensure you successfully receive your e-mail alerts.


Add New Comment
Visitor (To avoid code verification, simply login or register with us. It is fast and free!)
*Verify code:
Tech Impact

Regional Roundup
Control this smart glass with the blink of an eye
K-Glass 2 detects users' eye movements to point the cursor to recognise computer icons or objects in the Internet, and uses winks for commands. The researchers call this interface the "i-Mouse."

GlobalFoundries extends grants to Singapore students
ARM, Tencent Games team up to improve mobile gaming


News | Products | Design Features | Regional Roundup | Tech Impact