BLE v4.2: Creating Faster, More Secure, Power-Efficient Designs—Part 5
This file type includes high-resolution graphics and schematics when applicable.
As discussed in previous parts of this series, from the Bluetooth Low Energy Specification point of view, Bluetooth 4.2 supports new features that make BLE-based wireless systems faster, more secure, and more power efficient. These features—Data Length Extension (DLE), Low Energy (LE) Secure Connections, and Link Layer (LL) Privacy—require an upgrade to either the LL controller or the BLE host stack, or both. Thus, to add these features to an application, system designers require BLE silicon that supports the Bluetooth 4.2 Low Energy specification.
Let’s looks at some of the changes implemented by silicon vendors to support the new features. For instance, two major changes were made to the link-layer controller:
• Support for 251-byte protocol data unit (PDU): To support DLE, the LL shall be able to support a maximum of 251 bytes of a PDU, against the max PDU size of 27 bytes in BLE 4.1. This requires a change in the LL, which mostly triggers a change in the hardware.
• Address resolution: As the Resolving List is stored in the LL controller and address is resolved at the LL, it requires an update to the LL controller. Again, it influences most of the devices that have LL in hardware or a mix of hardware and firmware.
Any BLE device that has the LL controller implemented in hardware would need silicon updates to be Bluetooth 4.2-compliant. An implementation based on both hardware and firmware would likely need updates to both.
When it comes to the host controller, the biggest changes are the additional cryptographic functions required for security, updates to the pairing process, and addition of the Numeric Comparison association model. In most devices, the host controller is implemented in the CPU, and hence requires an update to the firmware whenever new features are introduced. The BLE protocol stack is complex and generally provided by the BLE silicon vendor. However, the way the stack can be used in an application varies according to the vendor.
Keeping Pace with Applications
Regarding applications, BLE is being used in remote controls, wearables, consumer appliances, etc. These fast-paced markets have short product life cycles. Thus, it’s critical that products reach the market on time or else they will miss their window. So, to maintain commercial viability of a system using BLE 4.2-compliant silicon, it’s important that the required ecosystem is available and can help develop systems quickly.
As an example, consider the BLE Component that’s available as part of PSoC Creator. An integrated design environment (IDE) for Cypress’s BLE SoC products, PSoC Creator permits concurrent hardware and firmware design of BLE-based systems. System can also be designed with PSoC Creator by first designing the hardware; i.e., placing various peripherals like ADCs, op amps, comparators, timers, etc., and then interconnecting and exporting them to popular IDEs like Eclipse or Keil. Various peripherals are available in PSoC Creator in the form of icons, known as components, and can be dragged and dropped based on the requirement.
The BLE Component in PSoC Creator allows new features to be added to applications using a graphics-based interface. It incorporates the features defined in Bluetooth 4.2 and can be added to systems easily. BLE Component abstracts the complexity of the BLE stack and helps system designers to leverage all new features without having to make low-level implementation changes.
As shown in Figure 1, the BLE Component lets developers select up to 251 bytes of payload. Later, if needed, the application programming interface (API) can be used to change RX and TX payload size.
Figure 2 illustrates how the BLE Component allows various pairing parameters and privacy options to be selected. Based on these selections, the required APIs are generated—these can be used to add security features in the application.
Dealing with Compliancy
However, to be able to use these features in the overall communication system, it’s required that both communicating devices support these capabilities. Some devices may not yet have Bluetooth 4.2 Low Energy capabilities. In such cases, backward compatibility allows a BLE 4.2-compliant device to work with a device that’s not BLE 4.2-compliant. One typical example would involve any of the latest smartphones. Phones tend to follow the latest protocol specification and must work with devices that are still running a stack compliant to an older version of the specification.
In BLE 4.2, the only exception is the LE Secure Connection strict pairing feature. If the LE Secure Connection strict pairing method is used, it won’t pair with devices based on BLE 4.1 or older. A small piece of code should be added in the BLE 4.2 device to check if the other device supports LE Secure Connection strict pairing before attempting to pair devices. If not, then the BLE 4.2 device should pair without LE Secure Connection strict pairing. In this way, as other devices upgrade to BLE 4.2, this device can use LE Secure Connection strict pairing (if supported by the other device) without any modifications. Moreover, new devices are likely to move to BLE 4.2 or later to keep them up to date with the BLE specification and leverage the advantages offered by the latest version of the specification.
During the initial phase of product design lifecycle, when system designers have the opportunity to pick either BLE 4.1 (or older) or BLE 4.2 silicon, understanding the future upgradability potential of a product is a must to ensure a quick and seamless switch to the newer version of the specification. To avoid board re-spins in the future as well as accommodate Bluetooth 4.2 features, Bluetooth 4.2-compliant BLE silicon should be used while designing the system. This ensures lower development cost, because hardware needs to be developed only once. It also reduces firmware development and testing costs.
Most vendors offer BLE 4.2-compliant devices that are pin-to-pin compatible with their older counterparts. In many cases, the same application firmware that’s written for an older version of silicon will work with BLE 4.2 because vendors try to keep the high-level API unchanged. Thus, even in the production stage, hardware can be upgraded with silicon that supports the newer version of the BLE specification without any delays. Firmware is able to be upgraded later to accommodate new features. If an over-the-air bootloader is implemented, it makes it easier to upgrade firmware even after the product is deployed.
To conclude, the ecosystem plays an important role when designing a system with a component that’s compliant to the latest version of a protocol. This becomes more vital when product lifecycles are small and the challenge is to strive for differentiation via new features before your competition. BLE 4.2-compliant silicon should be considered for systems needing to support a future upgrade potential to keep end-applications up to date with the BLE specification without requiring a hardware revision. Easy-to-use GUI-based development tools can make it easy and cost-effective to develop such Bluetooth 4.2-compliant wireless systems.
Refer to application note AN99209 or the Bluetooth Core Specification (this link is a large-sized PDF download) for more details on Bluetooth 4.2 features.
