Bluetooth 4.1, 4.2 and 5 Compatible Bluetooth Low Energy SoCs and Tools Meet IoT Challenges (Part 1)

Significant upgrades to the Bluetooth low energy RF protocol software (“stack”) adopted in versions 4.1, 4.2 and 5 of the standard have dramatically improved its practicality for a wide range of applications beyond its consumer roots, particularly those related to the Internet of Things (IoT).

However, the rapid evolution of the technology and lack of clarity about the capability and interoperability of both Bluetooth low energy and conventional (or “classic”) Bluetooth has resulted in some confusion. Designers and developers need to fully understand which form of the technology is best suited to their specific application if they are to optimize their design while ensuring they take full advantage of Bluetooth’s capabilities.

This two-part article addresses that confusion by defining Bluetooth low energy. It then describes the enhancements to the technology – introduced with versions 4.1, 4.2 and 5 of the specification – that have made it suitable for applications not originally targeted. These applications include ultra-low power, longer range, higher throughput and the addition of advertising extensions. The article also includes examples of Bluetooth low energy systems-on-chip (SoCs) that are fully compliant with the latest versions of the specification.  

Part two of this two-part series will explain how designers with little RF experience can design Bluetooth low energy wireless products with SoCs, modules, firmware, and hardware & software development kits (SDKs) from a range of vendors.

Optimized for low power consumption

Bluetooth low energy was introduced as an ultra-low-power-consumption, interoperable form of Bluetooth short-range wireless technology with the adoption of Bluetooth version 4.0 in 2010. The technology extended the Bluetooth ecosystem to applications with small battery capacities such as wearables. Featuring microamp average current in target applications, it complements classic Bluetooth. Key features of the original specification included:

• A lightweight protocol stack.
• Interoperability with Bluetooth from version 4.0 onward.
• A raw data rate of 1 Mbps.
• A range of around 10 meters.
• A high degree of immunity from other 2.4 GHz radio sources.

The technology is suited to the transmission of data from compact wireless sensors or other peripherals where fully asynchronous communication can be used. These devices send low volumes of data (i.e. a few bytes) infrequently. Their duty cycle tends to range from a few times per second to once every minute, or longer.

In the Bluetooth 4.0 Core Specification, the lightweight Bluetooth low energy stack includes the Physical Layer (PHY) (which transmits bits), Link Layer (LL) (which defines packet structure and control) and Host Controller Interface (HCI). Collectively, these three layers are known as the Bluetooth low energy Link Controller (or “Controller”). Above the Controller, the Host layer incorporates the Logical Link Control and Adaptation Protocol (L2CAP) that provides a channel-based abstraction to applications and services. It carries out fragmentation and de-fragmentation of application data and multiplexing and de-multiplexing of multiple channels over a shared logical link.

The Host layer also includes the Security Manager Protocol (SMP) and Attribute protocol (ATT). SMP uses a fixed L2CAP channel to implement the security functions between devices. ATT provides a method to communicate small amounts of data over a fixed L2CAP channel. Devices which determine the services and capabilities of other devices also use ATT. The Generic Attribute (GATT) Profile specifies the structure in which profile data is exchanged. This structure defines basic elements, such as services and characteristics, used in an application. Finally, the Generic Access Profile (GAP) defines the basic requirements of a Bluetooth device. The application software sits at the top of the stack (Figure 1).

Figure 1: Bluetooth low energy protocol stack showing Controller, Host and Application. The Generic Attribute Profile (GATT) defines the basic requirements of a Bluetooth device. (Image source: “Bluetooth Low Energy: The Developer’s Handbook,” Robin Heydon)

Confusion among developers can come from the fact that from version 4.0, the Bluetooth Core Specification defines two types of chip:

• The Bluetooth low energy chip and stack described above.
• A Bluetooth chip with a modified stack and the Basic Rate (BR)/Enhanced Data Rate (EDR) PHY of previous versions combined with a Low Energy (LE) PHY (“BR/EDR + LE”) such that it’s interoperable with all versions and chip variants of the standard.

This article (and Part 2) primarily focuses on the Bluetooth low energy device. In many consumer applications, this device operates in conjunction with a Bluetooth chip, but thanks to enhancements to the standard introduced in versions 4.1, 4.2 and 5, is increasingly being employed as a standalone device for IoT applications.

Bluetooth low energy chips can interoperate with other Bluetooth low energy chips and Bluetooth chips adhering to Bluetooth 4.0 or later. Note that Bluetooth chips are used in applications such as smartphones, tablet computers and PCs where power consumption is less critical than bandwidth. However, they can also interoperate with Bluetooth chips adhering to Bluetooth 3.0 and earlier (Figure 2).

Figure 2: Bluetooth 4.0 is based on two devices, Bluetooth chips (with BR/EDR + LE PHY) and Bluetooth low energy chips (LE PHY) (center and right of image). These devices are interoperable. Bluetooth chips can also interoperate with classic Bluetooth chips adhering to Bluetooth 3.0 and earlier (left). (Image source: Nordic Semiconductor.)

Bluetooth low energy saves power by maximizing standby time and by using fast connections and low peak transmit/receive power. Key to its ultra-low power consumption is the fact that while classic Bluetooth is a “connection oriented” radio with a fixed connection interval, Bluetooth low energy is typically in a power-saving “not connected” state where the two ends of a link are aware of each other, but only connect when necessary, and only then as briefly as possible.

Bluetooth low energy uses three advertising channels to search for other devices or promote its own presence, compared to 32 for Bluetooth. Bluetooth low energy activates for 0.6 to 1.2 ms to scan for other devices, while Bluetooth requires 22.5 ms to scan 32 channels, consuming up to 20x more energy.

Once connected, Bluetooth low energy switches to one of its 37 data channels and then flips between channels to avoid interference in a pseudo-random pattern using the Adaptive Frequency Hopping (AFH) technology pioneered by the original Bluetooth specification, which uses 79 channels. Bluetooth low energy completes its connection – scan, link, send data, authenticate and terminate – in 3 ms compared with some hundreds of milliseconds for Bluetooth, again saving energy.

The technology also saves power by using more “relaxed” RF parameters than Bluetooth. Both technologies use Gaussian Frequency Shift Keying (GFSK) modulation; however, Bluetooth Smart uses a modulation index of 0.5 instead of classic Bluetooth’s 0.35, thereby lowering power requirements. The lower modulation index also helps to increase range and enhance robustness.

Finally, Bluetooth low energy uses shorter packets than Bluetooth. This helps avoid overheating the chip. It also circumvents the need for a power-consuming recalibration procedure and the use of a closed-loop architecture.

Preparing for the IoT

In consumer applications, a smartphone typically operates as a “gateway” for the Bluetooth low energy device’s data to reach the cloud. This works well for human-centric applications such as fitness bands, but is less than perfect for applications such as home or industrial automation where a smartphone is unlikely to be permanently available. Bluetooth 4.1 was introduced (in part) to address this weakness when the technology is implemented for IoT applications.

Bluetooth 4.1 added the ability for a device to act as a Bluetooth low energy “peripheral” and a “hub” at the same time. For example, a smartwatch could now act as a hub gathering information from a Bluetooth low energy heart-rate monitor while simultaneously acting as a peripheral to a smartphone by displaying new message notifications from the handset. Second, Bluetooth 4.1 added a standard means to create a dedicated channel, which could be used for IPv6 (the latest version of the Internet communications protocol).

Other enhancements introduced with this software upgrade included: Improved coexistence between Bluetooth low energy and cellular LTE; better connections due to allowing the developer to vary the reconnection time interval; and bulk data transfer.

Meanwhile, the Internet Engineering Task Force (IETF) added the Low Power Wireless Personal Area Networks (6LoWPAN) specification to IPv6. Moving beyond IPv4’s 32-bit addressing IPv6’s 128-bit addressing ensures that the billons of tiny sensors that are being added to the IoT would all have a unique IP address. This allows them to directly connect to other devices on the network. In the case of Bluetooth low energy, this would allow a sensor to dispense with the services of a gateway to make the IP connection and translation. Smartphones are a good example of a widely used gateway.

The IETF’s development, together with the dedicated channel introduced in Bluetooth 4.1, enabled Bluetooth 4.2 to include the Internet Protocol Support Profile (IPSP) in the Bluetooth low energy stack. IPSP allows devices to discover and communicate with other devices that support IPSP using IPv6 packets over the Bluetooth low energy transport layer. Most of the major Bluetooth low energy chip vendors now include such a transport layer in their stacks.

Thanks to the addition of IPSP, Bluetooth low energy devices can now communicate with any other IPv6 enabled device through simple and inexpensive routers or gateways (Figure 3). Because such routers act as neutral devices, relaying IPv6 packets without performing any analysis or manipulation, millions of devices already in service but previously incompatible with Bluetooth low energy (such as set top boxes (STBs) or Wi-Fi routers) can now also be inexpensively adapted to act as routers.

Figure 3: Bluetooth 4.2 introduced the Internet Protocol Support Profile (IPSP) to Bluetooth low energy (previously called “Bluetooth Smart”) allowing devices to connect with any other IPv6-enabled device via connection to the Internet using simple and inexpensive routers. Internet access via a smartphone gateway is also possible if such a device is present. (Image source: Nordic Semiconductor)

Bluetooth 4.2 combats hackers

Bluetooth 4.2 also introduced some security elements that addressed fears of hacking when Bluetooth low energy devices such as smart lights routinely connect to the Internet without human intervention.

The first of these is Low Energy (LE) Secure Connections. Until Bluetooth 4.2, the fundamental building block of Bluetooth security had been Secure Simple Pairing, where device connections were made only after the generation and distribution of several encryption keys: one short-term key (STK) and three long-term keys for link layer encryption and authentication (LTK), connection signature resolution (CSRK), and identity resolution (IRK).

Bluetooth 4.2 introduced much higher strength security. For key management, the specification added asymmetric Elliptic Curve Cryptography (ECC) with Federal Information Processing Standards (FIPS) recommended elliptic curves. It also used FIPS’s approved Advanced Encryption Standard-Counter with CBC-MAC (AES-CCM) cryptography for message encryption. The result is strengthened link layer security between neighboring devices that protects wireless links against things like passive eavesdropping and man-in-the-middle (MITM) attacks.

The second security addition to Bluetooth 4.2 is LE Privacy, which manages private address resolution in controller devices as well as host devices, while supporting whitelisting of private addresses at the controller level.

In addition, Bluetooth 4.2 features an increase in maximum transmit power modes for Power Class 1 from +10 to +20 dB, allowing designers to eliminate an external power adapter, thereby saving space and cost. The packet capacity was also increased from 27 to 251 bytes compared to Bluetooth 4.1, and data range was increased up to 2.5x. These improvements make device-to-device communications and connections over the internet more efficient and enable faster uploads and more frequent over-the-air (OTA) firmware updates.

Solutions quickly follow upgrades

Bluetooth low energy’s open standard and market success has led to a slew of vendors and products flooding the market shortly after the adoption of Bluetooth 4.0, 4.1 and 4.2. Generally, these have taken the SoC route. A good example is Nordic Semiconductor’s nRF51 Series, launched in 2012. This is based on an ARM Cortex-M0 processor and includes a Bluetooth low energy transceiver, Flash and RAM memory, onboard power management, and a smattering of I/O.

Dialog Semiconductor’s DA14680 SoC follows a similar formula. The chip is a Bluetooth 4.2-compliant device that includes an ARM Cortex-M0 processor, Bluetooth low energy radio, 8 Mb Flash, 64-kB OTP ROM, 128 kB data SRAM, 128 kB ROM, on-chip power management, and several other peripherals (Figure 4).

Figure 4: Dialog Semiconductor’s DA14680 is a typical example of a Bluetooth 4.2-compliant BLE SoC based around an embedded ARM processor, sensitive 2.4 GHz radio, Flash, RAM and ROM. (Image source: Dialog Semiconductor)

In addition to Nordic and Dialog, many other Bluetooth 4.1 and 4.2 IC vendors are offering solutions for developers. Notable among these are Texas Instruments (TI) and Cypress Semiconductor.

Bluetooth 5 adds range and bandwidth

The latest version of the Bluetooth technology, Bluetooth 5 (not “5.0” as might be expected), introduced in December 2016, moves Bluetooth low energy a step closer to becoming a foundation technology for the IoT. The enhancements are significant, increasing range and bandwidth.

The bandwidth increase comes courtesy of a 2 Mbps PHY, compared to the 1 Mbps PHY used in previous versions of Bluetooth low energy. A doubling of PHY bandwidth doesn’t directly translate to a doubling of data transmission because of fixed overheads in the packet structure of Bluetooth 5, but a developer could reasonably expect to achieve a data transmission rate of around 1.4 Mbps, compared with 800 kbps from Bluetooth 4.2’s 1 Mbps PHY (Figure 5).

Figure 5: Bluetooth 5 retains the 251 byte payload of Bluetooth 4.2, but a 2 Mbps PHY reduces the transmission time and boosts bandwidth. Where Bluetooth 4.2 could achieve 800 kbps using its 1 Mbps PHY, Bluetooth 5 can reach 1.4 Mbps using its 2 Mbps PHY. Bandwidth advantages are lost when employing Bluetooth 5’s range-boosting features. (Image source: Bluetooth.com)

Faster throughput is a benefit for many applications, but a key advantage for the IoT is more rapid OTA updates, an important consideration for IoT sensors that are likely to require regular enhancements to provide more functionality and higher security. In addition, using a 2 Mbps PHY saves energy because the radio is active for less time than a 1 Mbps device to send a given amount of data. The radio can also spend more time in a deep sleep mode, further reducing power consumption.

Bluetooth 5 offers up to 4x the range of 4.2, which is an advantage in many IoT applications. For example, such range could allow all the smart lights in a house to communicate with a central hub via a star topology, rather than using the more complex mesh networking often implemented to boost the range of low-power wireless technologies. Improved range comes from the use of Forward Error Correction (FEC), which detects and fixes errors in communication at the receiver. Crucially, bearing in mind the technology’s ultra-low-power heritage, range is increased without resorting to increasing the transmit power.

For engineers and developers, “range” is defined as the maximum distance at which data can be correctly extracted from the received signal. As range increases, the signal-to-noise ratio (SNR) increases, and decoding errors begin to occur. A Bluetooth receiver can tolerate a maximum bit error rate (BER) of 0.1% before communication breakdown. Instead of increasing the transmitter power, the receiver’s sensitivity was boosted such that the maximum BER occurred at a much greater range.

Bluetooth 4.2 uses Cyclic Redundancy Check (CRC) to check for packet errors. The receiver recalculates the CRC and compares the value with the value appended to the packet by the transmitter. A difference between the CRC values indicates an error has occurred. However, 4.2 included no mechanism for error correction at the receiver. Instead, the receiver typically requested a packet be resent, thereby slowing the overall throughput.

Bluetooth 5’s FEC improves the receiver’s sensitivity with no changes to the hardware. The downside is that the technique adds redundant bits to the packet to facilitate error correction. This reduces the effective data rate to 500 kbps, or 125 kbps, depending on which of the two available coding schemes is applied. Unfortunately, the 2 Mbps PHY doesn’t support FEC so it can’t be used to compensate for the lower effective throughput caused by the redundant bits.

Because FEC decreases the effective throughput, the Bluetooth radio must be in a high-power state for much longer when using (4x) long-range operation for a given amount of data. Depending on the coding scheme, it can take up to 13x as long to transmit the standard Bluetooth low energy packet’s payload compared to an uncoded transmission. While peak power consumption is not affected, average power consumption leaps, thereby consuming a battery’s charge faster.

Among other improvements, Bluetooth 5 also introduces advertising extensions. Advertising extensions increase the payload size from 27 bytes to 251 bytes for more efficient data transfer. The most likely application of this feature is for beacon applications which allow retailers to send more information in the advertising packet to consumers’ smartphones. A further feature of the latest version is the ability to use data channels for broadcasting.

Commercial Bluetooth 5-compliant BLE chips are just starting to emerge. One solution is TI’s CC2640R2F SimpleLink Bluetooth low energy SoC.  This Bluetooth 5 chip integrates an ARM Cortex-M3 processor, Bluetooth 4.2- and 5-compliant 2.4 GHz radio with -97 dBm sensitivity, on-chip DC/DC converter, and a decent selection of I/O and peripherals. The SoC is also supported by TI’s extensive range of SDKs, reference designs and other software tools.

Bluetooth 5 doesn’t currently support the mesh networking capability of competing technologies such as ZigBee and ANT+. Several manufacturers have implemented proprietary mesh technologies based on Bluetooth low energy, notably CSR, which is now part of Qualcomm. As mesh is likely to be a key requirement for IoT applications, it’s not surprising that the Bluetooth SIG is working on implementing it. Expect to see the next update of the Bluetooth standard (due late 2017) supporting mesh networking.

Conclusion

The many significant upgrades to the Bluetooth low energy RF protocol software (“stack”) adopted in versions 4.1, 4.2 and 5 of the standard have made the interface more useful in applications requiring lower power consumption, greater range, and higher throughput. However, the changes have also created some confusion. A comprehensive understanding of the updates and their implication is required before developers can take full advantage of the most appropriate version of Bluetooth for their application.

As shown, product solutions for earlier versions of Bluetooth are widely available, while Bluetooth 5 is ramping up quickly. These solutions allow any sensor, product or appliance to be connected to the IoT via a simple and inexpensive router, rather than a complex gateway such as a smartphone. Such connectivity will endow even the most mundane of contemporary products with significantly enhanced functionality that can be updated frequently during the device’s life.

Introduction to Part 2: Bearing this in mind, Part 2 of this two-part series will explain how to design products using a wide range of Bluetooth 4.2 and 5 compliant SoCs and modules.

Combined with proven stacks, open-source application software, reference designs and factory supplied developments tools, these components have eliminated much of the black art of RF engineering.  The article will explain that while Bluetooth low energy wireless product development is still not trivial, an engineer can avoid the pitfalls and come up with a design that meets regulatory approval, Bluetooth compliance, and keeps customers happy.

References:

1. “Getting Started with Bluetooth Low Energy,” Kevin Townsend, Carles Cufí, Akiba, and Robert Davidson, O’Reilly.
2. “Bluetooth Low Energy: The Developer’s Handbook,” Robin Heydon.
3. “Exploring Bluetooth 5 - Going the Distance,” Martin Woolley, Bluetooth.com.
4. “A look in to Bluetooth v4.2 for Low Energy Products”