Make the most of Bluetooth LE advertising mode

The BLE software stack has been described in great details in a number of publications, e.g., [2], [3] and it is touched upon in this article only in generic terms to compare with the SW requirements for implementation in reduced or limited functionality devices, e.g., using advertising only or scanner only modes.

Figure 1: A simplified structure of BLE stack for Single Mode devices. HCIx provides a standardized interface between BLE controller and an arbitrary MCU that is hosting the application and the upper part of the stack.

Figure 1 shows a typical partition of a BLE stack for single mode devices. BLE Radio implementation supports the Physical (PHY) layer of the protocol stack while the Link Layer (LL) controller is responsible for low level communication over a PHY interface. The LL manages the sequence and timing of transmitted and received frames, and it handles a state machine for advertising, scanning and the connection state. Collectively, this part of the BLE stack (PHY and LL) is called the controller and is tightly integrated with the BLE radio. The controller part runs lower layers of the stack which are required for handling physical layer packets and all associated timing.

The upper part of the BLE stack has much more relaxed timing constrains and may be implemented on the same MCU or use a separate hosting MCU. Communication between the BLE controller and host is standardized using the Hardware Controller Interface (HCI) which allows to completely decouple the BLE controller from the Host part of the stack.

The Logical Link Control and Adaptation layer Protocol (L2CAP) component is a multiplexor responsible for aggregation and directing data streams between the BLE controller and different components in the Host part of the stack: Security Manger (SM), the generic attribute profile (GATT) and generic access profile (GAP).

The SM provides a mechanism to encrypt and authenticate data and is responsible for device pairing and key distribution.

GATT describes a service framework used for discovering services, reading and writing characteristic values on a peer device using attribute protocol (ATT) optimized for small packet sizes used in BLE. GATT-based profiles used in BLE minimize the size of the data exchange between the devices and therefore reduces the time the device is in active RF mode.

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 the connection with other devices.

Combined all components together, the BLE host part of the stack requires on average 32K of memory (a little less or more depending on supported optional functionality). It considerably smaller than the memory requirements for regular Bluetooth devices, nevertheless it requires the Host device to have a double digit size of Flash memory just for the BLE stack.

For many devices with simple functions, it is unrealistic to fit a full BLE stack on the host -- often such devices utilize low cost MCUs with just a few Kbytes of flash. But such simple devices may not need bi-directional communication with the full scale of features like security, encryption or quality of service. If the device just needs to communicate the status of a few parameters or alarms and does not absolutely require acknowledgement from other side, the BLE advertising mode may do the job with just a few commands sent to the BLE controller.

Many times in my long carrier I encountered the phrase "... oh, just one way transmission should be enough!" only to find that one also needs to pause, to put to sleep, to wake up, to query, to change modes, etc., the "transmit only" device.
I don't believe there is such thing as a one-direction communication only!
I'll be glad to hear about such devices.