Before two Bluetooth® low energy devices can connect and get it on (technical term meaning “interact and exploit each other’s services”) they need to find each other and decide if one is interested. It’s kind of like online dating for IoT devices.

Bluetooth low energy and its stack include a component called the Generic Access Profile (GAP). GAP is responsible for helping devices find each other and connect. We call this the discovery process.

Me! Me! Pick Me!

The discovery process involves devices wishing to be discovered doing something known as ‘advertising.’

An advertising device emits small packets containing data deemed useful to scanning devices. How often advertising packets are emitted is a parameter which may vary considerably according to the device type or use case.

Devices wishing to find other devices to connect to engage in a process called ‘scanning,’ and receive and process advertising packets from other devices.

In terms of GAP, a device which is advertising is known as a GAP Peripheral if it wants another device to connect to it or a GAP Broadcaster if it is advertising but not willing to accept connections—Bluetooth® beacons are often GAP Broadcasters. For scanning devices, sometimes the content of the advertising packet is the only thing needed, there being no intention to connect at all and again. Beacons are a good example of this. When this is the case, the scanning device is termed a GAP Observer. When the scanning device is interested in connecting to the other device it’s called a GAP Central device.

Advertising packets are quite small, with only 31 octets available for data and it’s into this limited space that advertising devices need to place data with which to entice scanning devices.

Of Transmitters and Receivers

There are three channels which can be used for advertising—one, two or all three may be used. In contrast, data packets are subject to adaptive frequency hopping across the other 37 channels. When advertising is using more than one of the three channels (and using all three is quite typical) then each time an advertising packet is transmitted, the same packet is transmitted on each of those designated channels.

How often advertising packets are transmitted is called the Advertising Interval and can be as often as every 20ms or as infrequently as once every 10 seconds—once a second is probably a more typical value.

It should be noted, however, that the timing of advertising events is not completely deterministic. Small random delays are added to the scheduling of advertising events to avoid persistent collisions from occurring.

It’s All About Me

What can advertising devices put in those advertising packets, and given the limited space, how should developers decide what to include and what to leave out?

The data part of an advertising packet consists of fields called AD Types. The full list of AD Types is defined in a document called the Core Specification Supplement (CSS). Examples of AD Types include Local Name, Service UUID and Manufacturer Specific Data to name but a few of the available types.

Developers choose what to include in advertising packets from the list of AD Types but are constrained by the amount of available space and so they must make choices. If the device is a GAP Broadcaster then the AD types they intend to use to contain the data they want their device to broadcast are chosen. If it’s a GAP Peripheral, they consider how best to indicate to a scanner this is a device it should be interested in connecting to. A common approach is to use the Service UUID AD Type to include a list of the UUIDs of the most important GATT services which the device has. Scanning devices should be able to deduce that the device is of interest from this list.

If there isn’t a defined AD Type for the kind of data the device wishes to advertise, the Manufacturer Specific Data field can be used. This field is designed to contain anything you like. The only rule is that the first two bytes must contain the Company Identifier for the company whose data format is being used within the Manufacturer Specific Data field. For example iBeacon from Apple uses the Manufacturer Specific Data field to hold a number of pieces of data including a UUID, major and minor location codes and a reference TX power value for distance estimation. Since this is Apple’s data format, the first two bytes of the Manufacturer Specific Data field in an iBeacon advertising packet contain 0x004C, Apple Inc.’s company identifier. You’ll find this and a full list of other IDs here.

But I Need More

What if you need more space than is available in the advertising packets? Well, those advertising packets which a device broadcasts are only the start. Scanning devices are allowed to ask the advertising device for more information and here’s how:

There are two possible approaches to scanning—Passive Scanning or Active Scanning.

Passive Scanning is what I’ve described so far. Scanners receive advertising packets and process the contents. In the case of Active Scanning, however, a device may decide it wants to know more about an advertising device and respond to the initial advertising packet by sending a Scan Request GAP protocol data unit (PDU). This basically means ‘Tell me more.’ The device receiving the Scan Request can send back a Scan Response PDU with more information, once again in the form of a collection of AD types.

Types of Advertising

There are four different types of advertising which are possible, some more commonly used than others.

General Advertising

This is the most basic type of advertising and one which acts as a general invitation to some other device.

Directed Advertising

This is a special-purpose type of advertising, designed to invite a specific peer device to connect as quickly as possible. It contains the address of both the advertising device and the device being invited to connect. On receipt of this advertising packet, the receiving device (known now as the “initiator”) will immediately and automatically send a connect request. In direct advertising mode, advertising packets are sent very frequently, every 3.75 milliseconds, but for no more than 1.28 seconds. This is so that advertising channels do not get congested.

Non-connectable Advertising

GAP Broadcasters use non-connectable advertising. How this is indicated in advertising packets is explained below in the section on “Flags.” Devices whose sole purpose it to perform non-connectable advertising only need to be equipped with a transmitter. They do not need a receiver in their controller.

Discoverable Advertising

This mode can be used for what might be thought of as “extended broadcasting.” Devices performing discoverable advertising do not accept connections but they can respond to Scan Requests and therefore in contrast to non-connectable advertising, they do need a receiver as well as a transmitter.

In Part 2

Here in part 1, the world of Bluetooth® advertising has been introduced along with some of the key technical concepts. In part 2, we’ll take a closer look inside advertising packets and consider how developers can receive and process them.

Robust Indoor Distance Estimation Algorithms for Bluetooth® Channel Sounding

Bluetooth Channel Sounding is a powerful feature setting a clear and solid foundation for…

What’s New with Bluetooth® Technology: Channel Sounding, Upcoming Features, and Key Technology Trends

With over 5 billion devices shipping each year, Bluetooth technology is the most widely…

Bluetooth 6: What's New In The Latest Bluetooth Release?

Bluetooth technology is constantly growing, not only enhancing existing applications but also enabling entirely…

Bluetooth PAwR in a Large-Scale Test Network

In the ever-evolving, dynamic landscape of Bluetooth-connected smart devices, efficient interconnection and reliable communication…

Bluetooth Channel Sounding: How It Works and What It Means

Bluetooth® Channel Sounding is a new secure, fine-ranging capability that promises to enhance the…

Receiver Blocking Resilience Test Suite

This Test Suite tests the receiver blocking resilience of a Bluetooth implementation. It is…

Now Available: New Version of the Bluetooth Core SpecificationBluetoothコア仕様の新バージョンがリリース

Thanks to the dedication and hard work of the Bluetooth community, Bluetooth® technology is…

Channel Sounding: Technical Overview (Pt 2)

In Part 1 we introduced the new Bluetooth distance measurement innovation known as Channel…

Unlocking Healthcare Potential: SPP and Bluetooth® LE for Medical Devices

The Serial Port Profile (SPP) has long been a well-known standard for wireless serial…

The Bluetooth Roadmap: Bluetooth Specifications in ProgressBluetoothのロードマップ:策定中のBluetooth仕様

Though not commonly known among many consumers, Bluetooth® technology is constantly and consistently advancing to…

Bluetooth® Channel Sounding: A Technical Overview

This paper provides a detailed technical overview of Bluetooth® Channel Sounding, a secure fine ranging…

The Bluetooth® Mesh Primer

An introduction and explanation of important Bluetooth® Mesh concepts.

Enabling the Digital Transformation of Industrial IoT with Bluetooth®

The Industrial IoT is a digital transformation process for enterprises offering them compelling abilities…

Bluetooth® Technology for Linux Developers

Learn how to use the interprocess communication system D-Bus and the BlueZ APIs to create Bluetooth applications for Linux computers.

Designing and Developing Bluetooth® Internet Gateways

Learn about Bluetooth® internet gateways, how to make them secure and scalable, and design and implement your own...

The Bluetooth LE Security Study Guide

Learn about fundamental security concepts, the security features of Bluetooth Low Energy, and gain some hands-on experience using those features in device code.

NOTICE: The Bluetooth SIG updated its Terms of Use on 29 October 2024Learn more
 Get Help