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.

What's new in Bluetooth v5.4: An overview

The recent adoption of version 5.4 of the Bluetooth® core specification brings a new…

Low Energy Audio – Incoming Call Over Media (Multi-Device)

This document uses a Message Sequence Chart (MSC) to explain the Bluetooth® LE Audio…

Bluetooth ESL – The Global Standard for the Electronic Shelf Label Market

Electronic shelf label (ESL) systems have historically relied on proprietary protocols for wireless communication,…

Bluetooth® Core Specification Version 5.4 - Technical Overview

This feature overview summarizes and explains the updates introduced in Bluetooth®️ Core Specification Version…

Integrating Memfault with Blecon Bluetooth Devices

In this post, I’ll go through how we evaluated Memfault at Blecon and talk…

Best Practices for Using a Standalone Auracast™ Transmitter

The recently released Auracast™ Simple Transmitter Best Practices Guide describes a typical, qualified implementation…

Auracast™ Broadcast Audio Introduces New Opportunities for Product Developers & Public Locations

Bluetooth® technology recently introduced a new Bluetooth capability, Auracast™ broadcast audio, that will deliver life-changing…

How To Design A Bluetooth LE GATT Server For Your Application

If you want to learn how to create a GATT server and load it…

Introducing: The Bluetooth Low Energy Primer

Bluetooth® technology has been around for more than 20 years. Initially created to allow…

The Bluetooth® Low Energy Primer

Are you new to Bluetooth Low Energy? Learn about its constituent parts, features, and how it works.

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.

How to Do Stuff with Bluetooth® Technology

Got a robot dog you want to remote control? You came to the right…

Bluetooth® Core Specification Version 5.3 Feature Enhancements

Bluetooth® Core Specification version 5.3 includes several feature enhancements with the potential to improve…

Designing and Developing Bluetooth® Internet Gateways

Learn about Bluetooth internet gateways, how to make them secure and scalable, and design and implement your own working prototype gateway and web application for use with either Bluetooth LE Peripherals or with Bluetooth mesh networks.

An Introduction to Bluetooth Low Energy for Swift Developers

All smartphones support Bluetooth® Low Energy (LE) and it is used in all manner…

 Get Help