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.

Bluetooth Mesh 1.1 Performance

In this blog, we explore different performance capabilities of the Bluetooth Mesh 1.1 network…

Bluetooth® Channel Sounding: A Technical Overview

The forthcoming update to the Bluetooth® core specification adds a new feature called Channel…

The Bluetooth® Mesh Primer

An introduction and explanation of important Bluetooth® Mesh concepts.

Low Energy Audio – Basic One-Way Unicast Audio

This document gives an introduction to Bluetooth LE Audio by explaining the basics of…

Low Energy Audio – Using UCIs, URIs, and URI Schemes

This document describes how implementers can use the UCIs, URIs, and URI schemes in…

Using a Bluetooth LE Wireless Module to Accelerate Time-to-market

Wireless connectivity makes dumb products intelligent. Smart devices can transmit information about their surroundings…

Now Available: Auracast™ Developer Best Practice Guides公開中:Auracast™開発者向けベストプラクティスガイド

When Bluetooth® LE Audio was released, it introduced broadcast audio to Bluetooth technology. This…

Automated Emergency Light Testing Through Bluetooth Mesh

During a summer internship at Nordic, I took on a project that focused on…

Coded PHYs + Advertising Coding Selection = Superior Bluetooth® Range

Bluetooth® v5.0 introduced LE Coded PHYs to extend the original range of the 1M…

Bluetooth Low Energy Fundamentals

The Bluetooth Low Energy (LE) Fundamentals Course is designed to give you the knowledge…

The Latest in HADM with Bluetooth LE

HADM, or high accuracy distance measurement using Bluetooth does exactly what it says –…

Mr. Beacon Podcast: Snapdragon Sound with Mike Canevaro

This episode of the Mr. Beacon Podcast explores the revolutionary world of Bluetooth audio.…

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.

 Get Help