No Blues with Bluetooth! Part 3

Part 3: BLE Advertising

In the first two parts of this article series, Robert described the fascinating history and evolution of Bluetooth, and introduced the protocol stacks of Bluetooth “classic” and Bluetooth low energy. This month, he explains how BLE actually works—the Generic Access Profile and “advertising” mechanism for discovering new devices.

Just a preliminary note: For simplicity, I will start with a presentation of BLE as it was designed back in 2010 (Bluetooth 4.0). This is still applicable, and the majority of BLE devices still use only these mechanisms. However, since then, the Bluetooth Special Interest Group (SIG) has developed plenty of optional improvements that are now available for BLE. You will just have to be patient. I promise you I will explain them in detail, but it will take a couple of months!

A REMINDER ON BLE

Maybe a short reminder on the BLE stack before going further? Invented by Nokia, BLE is, as you know, a variant of Bluetooth that is optimized for low latency and low power consumption applications. The BLE protocol stack (Figure 1) includes physical (PHY) and Link layers, communicating through a standardized Host Control Interface (HCI) with the upper layers. On top of HCI, BLE uses L2CAP for segmentation and multiplexing. L2CAP then supports only one common application protocol (ATT, Attribute Protocol) and a dedicated entity for security (SM, Security Manager). On top of that, there is only one super-flexible application profile (GATT, Generic Attribute Profile) and a specific protocol to discover and connect to new devices, the Generic Access Profile (GAP).

Are you fine with these concepts? If not, don’t hesitate to review the previous two parts of this series. Now, let’s discuss the lowest layer, the PHY layer.

BLE CHANNELS

Do you remember that Bluetooth “classic” uses the 2.4GHz frequency band, with a frequency-hopping protocol based on 79 frequency channels, each 1MHz wide? Well, BLE does the same, but with a different setup: BLE uses the same frequency band, ranging from ranging from 2.400GHz to 2.483,5GHz, but defines 40 channels, each 2MHz wide (Figure 2). I guess that using larger channels has two advantages—first, a receiver can settle more quickly on a wider channel; and second, the crystal driving the radios can be a little less accurate, so a bit cheaper.

Looking again at Figure 2, the 40 BLE channels are split in two groups—37 channels pictured in blue, and three in red. More exactly, the red ones are the 1st, 12th, and 40th channels in increasing frequency. The rule is very simple: the three red channels are used only to discover BLE devices and establish a connection, meaning for the GAP protocol. GAP is based on advertising, so these three channels are called “advertising channels.” The other 37 (blue) channels are dedicated to the actual communications between BLE products when a connection has already been made.

A last thing in Figure 2—look at the channel numbers. The three advertising channels are numbered 37, 38 and 39, and the communication channels are numbered from 0 to 36. Therefore starting from the lowest frequency we found channel 37, then 0, 1, etc. This is not to make life more difficult; it is instead to make it simpler. But this will be clearer when talking about frequency hopping.

Do you wonder why the three advertising channels were set at the two edges of the band and at the 12th frequency channel? This is, in fact, because these channels are usually the ones with the lowest interference with Wi-Fi traffic : The first and last Wi-Fi channels have quite a low power density at the extreme ends of the band, since Wi-Fi needs to limit out-of-the-band spurious transmissions. Similarly, the 12th BLE channel, centered at 2,426MHz, is usually less perturbed than others, because Wi-Fi is typically configured to use Wi-Fi channels 1, 6 and 11, and 2,426MHz falls nicely between the first two.

MODULATION

For those who are RF addicted, you might like to know what kind of modulation is used by BLE. This is a simple frequency-shift keying modulation with Gaussian filtering (GFSK). You may read one of my old columns about digital modulations if you need a refresher [2]. In the case of BLE, this modulation uses a bit rate of 1Mbps and a frequency deviation of ±250kHz. The so-called “modulation index” is therefore 0.5 (2x250k/1M). A zero is coded to negative frequency deviation, a 1 with a positive one. Nothing fancy here. By the way, all the Bluetooth specifications, and in particular its physical layer, are available freely from the Bluetooth SIG. Just download the latest version of the Bluetooth Core Specification, volume 6 [3] and browse through its 3,200 pages. An interesting reading, indeed.

Enough for the modulation and RF characteristics. In fact, every BLE design will use a chip dedicated for BLE, and this chip will hide all these aspects from you. More on that when I talk about hardware in an upcoming column.

BLE ADVERTISING

Now, how is a BLE device discovered and how is a link established? Imagine that you bought a new BLE-enabled gadget—say, a great connected toothbrush—and you wanted to link it to your smartphone. How would this happen? The toothbrush, like any BLE devices, will initially broadcast “frames” to indicate its presence. These frames are called “Advertising Indicators” (ADV_IND in the BLE specification). That’s why the toothbrush is, at this stage, acting as a so-called “advertiser.” These advertising messages (often inappropriately called “beacons”) are simply broadcast on air, and may be received by any BLE device around. Such a device that listens to advertising frames is called a “scanner” (see Figure 3). And of course, your smartphone can act as a BLE scanner and will detect the toothbrush. It can then connect to it if needed, and I will explain how.

Ok, but how often and on which channels are these advertising messages transmitted? The process is simple (Figure 4): Each advertising device is configured with a fixed advertising period (AdvInterval) ranging from 20ms to 10,485s. At each advertising time, the device wakes up and broadcasts the same advertising frame three times, on each of channels 37, 38 and 39 (the channels in red in Figure 2). To be exact, the device adds a small random delay (up to 10ms) to the pre-programmed advertising period. This mitigates the risk of successive collisions between two devices that had exactly the same advertising interval and start-up time.

After each transmission, the advertiser listen to the same channel for a short duration (500µs), just in case someone wants to talk to it. If not, and after the three transmissions, it goes back to sleep until the next advertising time. The full advertising period is very short, since a BLE message is quickly transmitted (for example, 160µs for 20 bytes at 1Mbps, repeated three times with some listening periods). This helps us to understand why BLE is so battery friendly. For example, assume that a BLE device needs 10mA when it is transmitting or receiving. If the advertising period is 2s and the overall advertising duration is 2ms, then the average RF current consumption is only 1/1,000th of the active current, so 10mA/1,000=10µA.

SCANNER CONFIGURATION

This seems simple doesn’t it? Well, nothing is actually simple with Bluetooth, even for this discovery phase. Think about the scanner. Assume the scanner is a smartphone. What are its potential problems? First, listening continuously to a Bluetooth channel for possible advertising would drain significant energy from the smartphone battery. Second, it would be very expensive to design a smartphone that could listen simultaneously to the three advertising channels. And third, the smartphone might occasionally do other things, such as Wi-Fi transmission, and can’t physically listen to the same frequency band at the same time.

So, a scanner, like the advertiser, is programmed with periodic scanning. As illustrated in Figure 5, the smartphone will execute a BLE scanning operation at a given repetition period (Scan Interval) and for a given time (Scan Window), and on a different advertising channel, one at a time.

Now you understand that the discovery will take some time, since a BLE advertiser will be detected only if the scanner is listening to the good channel when the advertising message is sent on this frequency. Planets must align…. The discovery time could then be very fast (typically, seconds), if either the advertising period is very short (meaning a high energy consumption for the device), or if the scanning is nearly continuous (meaning energy and usage constraints for the scanner). If both nodes must saver power, then the discovery can be very long (minutes or even hours).

From a practical standpoint, how can this discovery be optimized for usual applications? First, advertisers usually have a way to force frequent advertisings for a fast initial discovery. This could be activated through a push button or automatically, when batteries are inserted. The device then switches back to a longer pace to save power. Similarly, scanners could be optimized. For example, Android smartphones have API’s (application programming interfaces) to change the ScanInterval and ScanWindow parameters. Applications developers can then force frequent scanning when the application is in the foreground. IOS, however, does not have such an API, but Apple does provide some rules to optimize the discovery [4].

SCAN REQUEST

For the scanner to decide to connect or not, each advertising frame must contain enough information—what is this device, which services are proposed, and so on. This is specified by the GAP protocol, and I will come back to that later. However, you will understand that this could end up with quite a long frame, and it is not very energy efficient to broadcast long frames continuously, if no scanner is listening. That’s why the BLE specification supports a more clever mechanism—Scan Request. The concept? The advertiser can broadcast a shorter advertising message, typically providing only its MAC address. It will then provide more information only to scanners that explicitly ask for this information. How? See Figure 6 for an illustration. After each advertising message, the sender listens to the channel for a short time. Any scanner can then send a specific Scan Request message (SCAN_REQ) on the same channel, and the advertiser will simply answer with a Scan Response message (SCAN_RESP) that includes more advertised data. Specifically, the SCAN_REQ message must be sent no sooner than 150µs after the ADV_IND message, but less than 500µs after.

BEACON APPLICATIONS

The advertising mechanism allows a scanner to discover new devices before the establishment of a connection. However, there are plenty of use cases where advertising, alone, is enough. An example? Department stores want to help you to find good products, and ideally want to know as much about you as possible. One way to achieve this is to install BLE advertisers on the shelves, and ask you to install the department store’s app on your smartphone (Figure 7). The app acts as a scanner, and knows when you enter a store and in front of which shelf you are. And that’s a good way to send you a commercial to remind you that, by chance, there is a promotion of that particular product. Alternately, there are use cases where it make sense to install fixed scanners, and to have moving advertisers—for example, to detect that a given bus is arriving at a station.

Even if this is not official Bluetooth terminology, a physical device that acts only as a perpetual advertiser is often called a “beacon.” So there is a risk of confusion as beacon is both the nickname of the advertising message, and the usual name of a physical product that only sends beacons.

A last word on beacon applications: Bluetooth, through GAP, specifies how advertisers and scanners work and how to build an advertising message, but not the full semantics of the message. This means that there is no Bluetooth official application layer to use advertisements for something other than establishing a connection. However, other entities have specified such application layers. The most well known is iBeacon from Apple, which is an application layer protocol using advertisements. It transmits a universally unique identifier picked up by compatible applications or cloud-based systems. A similar protocol, Eddystone, was proposed by Google but was phased out [5].

GAP AND CONNECTIONS

Even if plenty of interesting applications only need advertisements, BLE is designed to establish connections between devices. In the next part of this article series, I will explain how this connected mode is established, and why it allows very efficient and ultra-low-power communication. For a preliminary view of the concept, take a look at Figure 8. Basically, this starts with advertisements. Once again, one of the devices regularly sends Advertising Indicator messages, and briefly listens to the channel, whereas the other scans for these messages and may send back a message. Earlier, I showed that this mechanism is used by the Scan Request mechanism.

Connection establishment uses exactly the same process, but here the scanner sends back another message type called Connection Indicator (CONNECT_IND). This message tells the advertiser that a connection is required, and includes all the data needed for the connection to be established. Both devices will then be connected and will regularly exchange packets. I will explain this in detail next month.

A few words on terminology. The Generic Access Protocol (GAP) formally defines fours types of devices. In this article series, they are referred to as the following:

1. Broadcasters, which only send advertisement messages (often called “beacons,”, as explained earlier);
2. Observers, which only scan, but never initiate connections;
3. Remotes, which advertise and then are connectable;
4. Controllers, which scan for advertisements and then are able to initiate connections.

You can safely understand that “smartphone” is meant when you read “Controller” 99 % of the time in this context, even if BLE allows the design of embedded devices acting as Observers or Controllers.

BLE FRAME FORMAT

Now, let’s dig a little deeper into BLE frame format. What is actually included in a BLE radio frame? BLE uses the same format for all messages, illustrated in Figure 9.

At the top of the diagram is the physical radio frame format. It starts with a preamble of alternating “1”s and “0”s. This allows the RF circuits to stabilize. This preamble is followed by a 4-byte access address, then actual data (called Packet Data Unit, or PDU) and a 3-byte cyclic redundancy check code (CRC) to discard erroneous frames. The access address field identifies a given connection. However for the moment we are still in the advertising phase, so there isn’t any connection yet. For simplicity, the BLE specification simply states that in that case, the access address field must be set to a specific value, 0x8E89BED6. This identifies GAP frames. Finally, the PDU is up to 39 bytes. In fact, it is 39 bytes initially, but could be extended to 257 bytes after connection, if both devices support this mode. Since I am currently talking about the GAP phase, it is then limited to 39 bytes for advertising and connection establishment.

Moving one line down, Figure 9 contains a breakdown of the PDU field. It starts with a 2-byte header, which includes frame type (ADV_IND, SCAN_RQ, etc) and the length of the frame, followed by a payload of up to 39-2=37 bytes. For GAP frames, these 37 bytes are then broken into a 6-byte address field (the MAC address of the advertiser), and a variable number of advertisement data structures, up to 37-6=31 bytes.

These data structures contains the actual advertisement information. Each has a length byte, a type, and a value. The type field defines exactly what the data is about. This is specified by the Bluetooth SIG as “AD Types.” The full list of AD Types is defined in a document called the Core Specification Supplement (CSS) [6]. You will find, for example, AD Types to broadcast the name of the device, its transmitting power, flags indicating if it is connectable or not, and so on. Here the designer is free to include any AD type. This applies either to the ADV_IND frame or in the SCAN_RSP frame sent in response to a SCAN_REQ.

Designers can also includes a specific AD type called “Manufacturer Specific Data.” This field is designed to contain anything you like. The only rule is that the first two bytes must be a Company Identifier. For example, iBeacons from Apple uses the Manufacturer Specific Data field to hold custom data, starting with 0x004C, which is the Apple Inc. company identifier. Company identifiers are assigned by the Bluetooth SIG only to its members, and are listed in the document, “Assigned Numbers” [7]. Other examples are 0x0000 for Ericsson, and 0x0001 for Nokia.

LET’S EXPERIMENT

Before closing, you might want to experiment with BLE advertising. You can do it right away, without any complex apparatus. Just get your smartphone or tablet, either Android or IOS, open Google Play Store or Apple App Store, and download any of the free BLE Scanning applications.

Personally, I am used to the “nRF Connect for Mobile” application published by Nordic Semiconductors [8]. Click on the “Scanner” mode icon at the bottom of the screen, and you will get a list of all advertisement messages received from the neighborhood (Figure 10), with their advertising interval and received power. Tap on any of them to discover the content of the advertising message. Just don’t tap yet on the “Connect” button, because it will be my topic for next month!

STAY TUNED!

Here we are. Bluetooth and BLE are not the simplest protocols on Earth, but I hope you have gained a good understanding of the Generic Access Profile and advertising mechanism. Next month I will continue discussing the BLE protocol—with the connected mode and GATT application layer. So get ready to be connected! 

REFERENCES
[1] Robert Lacoste, “No Blues with Bluetooth! Part 2: The Thousand-Foot Picture.”   Circuit Cellar 407, June, 2024.
[2] Robert Lacoste, “The Darker Side – Digital modulations demystified,” Circuit Cellar 233, December, 2009.
[3] – Bluetooth Core Specification V.5.4
https://www.bluetooth.com
[4]- Accessory Design Guidelines for Apple Devices, paragraph 49.5 “Advertising Interval”
https://developer.apple.com/accessories/Accessory-Design-Guidelines.pdf.
[5] Eddystone (Google).
https://en.wikipedia.org/wiki/Eddystone_(Google)
[6]– Bluetooth Core Specification, Supplement 11
https://www.bluetooth.com
[7]– Assigned Numbers
https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Assigned_Numbers/out/en/Assigned_Numbers.pdf
[8] – nRF Connect for Mobiles, Nordic Semiconductors, available on IOS App Store and Google Play Store

PUBLISHED IN CIRCUIT CELLAR MAGAZINE • JULY 2024 #408 – Get a PDF of the issue

Sponsor this Article