Bluetooth 4.0: An introduction to Bluetooth Low Energy—Part II

Single Mode vs. Dual Mode

As the name implies, Bluetooth LE has a direct relation with known Bluetooth technology. BLE may be considered as an extension of Bluetooth focused on low energy, battery operated sensor types of applications. While  Bluetooth 2.0 EDR or Bluetooth 3.0 HS introduced a higher data rate functionality, Bluetooth 4.0 targets effective communication with devices that do not need streaming data or high data throughput. Low-energy requirements stipulate noticeable differences in Bluetooth and Bluetooth LE protocols, but at the same time take great advantage in reuse of the RF part, leaving most of the changes to the protocol stack. The Bluetooth 4.0 specification effectively imposes 2 types of devices:  a dual mode device which is able to support Bluetooth LE in addition to the regular Bluetooth BR/EDR and a single mode device, which supports only Bluetooth LE protocol. Such a separation allows for asymmetrical network nodes and helps to take advantage of the simplicity of a single mode stack for sensor-like devices in combination with the versatility of a dual mode stack for more complex multifunction devices such as mobile phones.

Devices that support only Bluetooth BR/EDR will still be available considering the near 2 billion user customer base. With the 4.0 release, they become legacy devices since a change to dual mode Bluetooth will be incremental. All major Bluetooth chip providers such as TI and CSR have already announced Bluetooth LE support in the next generation platform. Figure 3 outlines the main blocks of Bluetooth BR/EDR, dual mode and single mode stacks. The dual mode stack has two independent protocol paths which share common RF blocks.  Indeed, dual mode devices can be used as Bluetooth LE only devices and since the scope of this article is limited to Bluetooth LE, the regular Bluetooth stack will not be covered here.

Figure 3: A simplified structure of a communication stack for various types of Bluetooth devices. The dual mode device introduced in Bluetooth 4.0 supports both Low Energy and legacy Bluetooth BR/EDR specifications. Single mode devices, typically budget and resource constrained, will support only the BLE specification. 

Bluetooth LE Stack Partition

Historically, a Bluetooth stack is partitioned into two (2) independent pieces: Controller and Host. The controller part runs the low layers of the stack that are required for handling physical layer packets and all associated timing. The controller part of the stack is usually implemented in the form of a small SoC with an integrated Bluetooth radio.

The host portion of the stack contains the upper layer of the stack including profiles and application API.  The host is abstracted from the hardware and has a much more relaxed timing restriction compared to the controller. This part of the stack usually runs on the application processor along with the user’s application. Communication between the controller and host is standardized as Hardware Controller Interface (HCI) over UART, USB or SDIO physical layer interface. It makes the controller and host vendor agnostic and allows you to mix and match controller and host implementations from different vendors. Alternatively, controller and host parts may be collocated and not need HCI implementation in that case. In this approach, a complete Bluetooth SoC often runs customer applications as well, and the chip provides required peripherals. Interestingly enough, the combination of just the RF chip and host running a complete Bluetooth stack is now very rare, mainly due to high timing demands on the low part of the Bluetooth stack.

In comparison, other ISM wireless protocols, once matured, often only offer a SoC approach, running custom applications on top of the stack. But sooner or later the customer’s applications become so big that they do not fit into a SoC and it creates additional challenges of how to move or partition the stack in a new, more powerful MCU.

Figure 4: Bluetooth LE stack for Single Mode devices. The lower part of the stack, a controller, handles time consuming functionality and it’s often combined together with a physical radio.  HCI provides a standardized interface between the Bluetooth LE controller and an arbitrary MCU which is hosting the application and the upper part of the stack.  If both parts of the stack are collocated on the same MCU, e.g. sensor SoC, HCI is not used. 

Since Bluetooth as a technology has been around for a while, a number of publications describing stack functionality are available [4]. Therefore, discussion of the stack will be limited to the Bluetooth LE portion of the stack. Figure 4 shows partitions and interaction between components in the stack for single mode devices. 

The link layer (LL) controller is responsible for low level communication over a PHY interface. It manages the sequence and timing of transmitted and received frames, and using link layer protocol, communicates with other nodes regarding connection parameters and data flow control. It also handles frames received and transmitted while the device is in advertising or scanner modes. The LL controller also provides gate keeping functionality to limit exposure and data exchange with other devices. If filtering is configured, the LL controller maintains a “white list” of allowed devices and will ignore all requests for data exchange or advertising information from others. It not only helps with a security aspect but also reduces power consumption. The LL Controller uses HCI to communicate with upper layers of the stack if they are not collocated.

The logical link control and adaptation layer protocol (L2CAP) component provides data services to upper layer protocols like security manager protocol and attribute protocol, described a few paragraphs later. It is responsible for protocol multiplexing and data segmentation into smaller packets for the LL controller, and de-multiplexing and reassembly operation on the other end.

The L2CAP is a backend interface for the generic access profile (GAP) that defines the generic procedures related to the discovery of BLE devices and link management aspects of connecting to other LE devices.  The GAP provides an interface for the application to configure and enables different modes of operation, e.g. advertising or scanning, and also to initiate, establish, and manage connection with other devices.

The security manager (SM) is responsible for device pairing and key distribution. The security manager protocol (SMP) is defined as how the device’s SM communicates with its counterpart on the other device.  The SM provides additional cryptographic functions that may be used by other components of the stack.

The SM architecture used in BLE is designed to minimize recourse requirements for slave type devices by shifting work to an assumingly more powerful master-type device. BLE utilizes the standard AES-128 bit crypto engine and uses a pairing mechanism for key distribution. The SM provides a mechanism to not only encrypt the data but also to provide data authentication.

Bluetooth 4.0 introduces a new communication method, called the attribute protocol (ATT) which is optimized for small packet sizes used in Bluetooth low energy.

The ATT allows an attribute server to expose a set of attributes and their associated values to an attribute client. These attributes can be discovered, read, and written by peer devices.

The generic attribute profile (GATT) describes a service framework using the attribute protocol for discovering services, and for reading and writing characteristic values on a peer device.  It interfaces with the application through the application’s profiles. The application profile itself defines the collection of attributes and any permission needed for these attributes to be used in the communication. 

Attribute-based Profiles

One of the main benefits of Bluetooth technology is device interoperability. A Bluetooth logo on a device guaranties that products from different suppliers having the same profile will understand each other. To assure this, it’s not enough to use a standardized wireless protocol to transfer bytes of information, but data representation levels must be shared as well. In other words, both devices will have to send or receive data in the same format using the same data interpretation based on indented device functionality. The profile is a bridge between the wireless protocol stack and the application and functionality of the device (at least from a wireless connection point of view) and is defined by the profile. Since Bluetooth 4.0 has introduced an attribute protocol supported in regular Bluetooth BR/EDR and BLE, a separate cluster of profile based GATT was defined.

BLE is utilizing the efficiency of GATT based profiles to minimize the size of the data exchange between the devices and therefore keeps down power to average consumption rates. Also, GATT-based profiles are intended to be rather simple and supported with minimal code development. This is particularly important for single mode BLE where resources are rather scattered.

According to Bluetooth Special Interest Group (SIG), the body that oversees the development of Bluetooth standards and licensing, a number of GATT-based profiles are in the final development stage and the adopted specifications should be available later this year. Upcoming profiles are targeted to cover use cases that are the most suitable for Bluetooth LE applications: proximity profiles, find me profiles, etc.

In Conclusion

This article intentionally omits a discussion of BLE applications for two reasons: first, it is a subject worthy of an article itself since BLE brings the possibility to connect new types of devices that can be smaller, cheaper and do not require rechargeable batteries, to virtually every cell phone; second, it was demonstrated that a good amount of new application ideas are generated while people explore new technology. 

From a development point of view, few Bluetooth LE chips are available now.  TI introduced the CC2540 which is a complete SoC with a Bluetooth LE compatible radio and 8051 processor architecture.  It has an extended list of peripherals and ample memory space: 8Kbytes of SRAM and 128/256Kbytes of in-circuit-programmable flash. It also includes an AES hardware accelerator to offload computation intensive encryption functions. TI’s chip comes with a royalty free Bluetooth LE protocol stack and can support master and slave modes of operation. In order to take advantage of a free stack, software development should be done using an IAR Embedded Workbench™[5]. To start exploring BLE, TI offers a development kit that could be purchased on their web site for $99.

Nordic Semiconductor is offering nRF8001 IC, a BLE SoC solution with a fully integrated stack but it is designed to be used in conjunction with an external microcontroller running the application. The nRF8001 provides an API for applications to enable BLE connectivity as a slave device [6]. The development kit is available as well, and it includes a master device emulator to compliment slave devices in a BLE connection.

EM Microelectronic demonstrated the EM9301, a single-cell battery BLE controller for single mode applications. It supports operation down to 0.8V and is suitable for extremely low power applications. The EM9301 integrates a RF and a BLE controller and supports both master and slave types of devices but the host part of the stack has to be executed on a separate microcontroller [7].

With more BLE enabled chips on the way from CSR (www.csr.com) and Energy Micro (www.energymicro.com ), it is the perfect time to roll up the sleeves and try to find a new killer app for Bluetooth Low Energy.

About the Author

Mikhail Galeev is a recognized expert in the area of wireless communication. With a primary interest in research and implementation of wireless protocols, he has over twelve years of experience and has authored multiple publications and patents related to applications of Bluetooth, ZigBee, Z-Wave and other wireless sensor networks. Mikhail holds a Master of Engineering Management degree from Northwestern University in addition to a MS EE degree from the University of South Alabama. Mr. Galeev is the founder of Z-Focus Consulting, a company that develops software to enable BLE applications.  You may reach him at mgaleev@z-focus.com.

References

[1] Ultra Low Power 802.11n Wi-Fi – Wireless Connectivity for “The Internet of Things” By N. Venkatesh,

[2] Wikipedia

[3] Specification of The Bluetooth System ver. 4.0 June 30 2010, www.bluetooth.org

[4] Bluetooth Demystified by Nathan J. Muller McGraw-Hill Professional Publishing; 1st edition (September 8, 2000)

[5] CC2540F128/256 2.4-GHz Bluetooth low energy System-on-Chip October 2010, www.ti.com

[6] nRF8001 Product Brief r version 1.0 www.nordicsemi.com

[7] EM9301 Fact Sheet, Sub 1v Bluetooth Low Energy Controller

www.emmicroelectronic.com