Bluetooth 4.2 was released over a year ago. That’s the good news. But it’s still making its way very slowly to devices. Have you seen any real device using it?
Earlier last year I wrote an article on what Bluetooth v4.2 means for you. Since then, most BLE chipset vendors have announced support for Bluetooth v4.2, even if support is preliminary. Any vendor without v4.2 will soon start running into trouble.
For developers, if your chipset supports v4.2, you can take two devices (usually from the same manufacturers) and use the features that it supports. But Bluetooth is a Smartphone and Tablet centric protocol, and whether or not you can actually the features connected to a phone is what really matters. Most customers will connect to a BLE product using a tablet.
Bluetooth v4.2 is actually a combination of multiple features and enhancements:
LE Secure connection, privacy and filtering are the features with the most support in handsets. But LE Packet Length Extension, arguably one of the most critical ones, isn’t. It’s not that security isn’t critical, but functionality and power consumption need to be take care of. Take a look at the pages announcing Bluetooth v4.2 and Packet Length Extension is usually at the top.
Bluetooth Low Energy packet sizes are pretty small – around 20 or bytes of actual data that you can send. This comes from the original specification where the intention was to allow small amounts of data to be sent. But the inherent simplicity and low cost in BLE cause many companies to switch to BLE instead of Classic Bluetooth, despite the lower throughput.
Packet Length Extensions introduces a few changes that allows packets to have up to 251 bytes of data, vs 27 in Bluetooth v4.0 and v4.1. This means a lot higher throughput (about 2.5x) and much better efficiency that means better battery lifetime. After all, you can put a lot more data with a lot less overhead.
But for this to work, both sides need to support and negotiate the larger packet sizes. The reality is that we’re more than a year after the release of the specification and this feature isn’t supported by iOS.
Let’s actually take a look at what’s happening in the air. To look at what support iPhones and similar devices have we ran several tests in our lab.
As the peripheral device we used Cypress Semiconductor’s PSoC 4 BLE chipset, one of the few (if not the only one we could find) with actual BLE 4.2 Support. We enabled v4.2 and Packet Length Extensions, but disabled any security to reduce the number of packets and to make it easier to follow.
The Central device is Apple’s iPhone 6 Plus which support the v4.2 specification and is running iOS 9.3 with all the latest updates. It’s Apple’s latest version at the time of this writing.
We used a Bluetooth sniffer to catch the packets off of the air. The sniffer sees the advertisements of the peripheral device and can follow a connection once the central device begins the connection.
You can see the connection process between the iPhone and the Peripheral device. Both devices exchange their version numbers (not shown in detail above) using LL_VERSION_IND. Both actually report 8 which is the value that indicates they’re supporting Bluetooth v4.2. But when the peripheral device actually sends the LL_LENGTH_REQUEST to the iPhone, the iPhone actually doesn’t know what it is.
Vol 6, Part B of the Bluetooth v4.2 Specification states:
“The [Packet Length Negotiation] procedure is completed when the initiating Controller receives either an LL_LENGTH_RSP PDU or, in the case the remote device does not support the LE Data Packet Length Extension feature, an LL_UNKNOWN_RSP PDU with the Unknown type set to LL_LENGTH_REQ.”
What we see is the not supported scenario. If you look on the bottom packet, you’ll see Unknown Type set to 20 (0x14). This means the LL_UNKNOWN_RSP packet is referring to the LL_LENGTH_REQ packet previously sent by the peripheral device. The iPhone is saying it doesn’t know what that packet is, and won’t negotiate for larger packets.
The situation is somewhat worse in iOS than Android because iOS places a limit of about 30ms on the connection interval – as opposed to the 7.5ms in Android. This means that not only are packets still small, they’re slower.
We’ve sent a few e-mails to Apple to try and find out any timeline, but haven’t received a response yet. We’ll update when we know more.
More Information
Apple adds Bluetooth 4.2 to iPhone 6, iPhone 6 Plus and iPad Air 2
Bluetooth v4.2 Specification
Enter your email address to subscribe to this blog and receive notifications of new posts by email.
