Advertising Works, Part 2

Introduction

In part 1, we explored Bluetooth^® advertising and the various roles devices may assume. In part 2, we’ll take a closer look at what can be inside advertising packets and consider how developers can receive and process them.

AD Types Used in Bluetooth Low Energy Advertising Packets

The current version of CSS is version 6 and this defines the AD Types which may be used in Bluetooth Low Energy advertising packets or Scan Response PDUs. Data type values are defined in the Assigned Number for GAP document.

Some of the types defined in the CSS which are more commonly used in advertising packets are explained next.

Service UUID

This refers to six distinct data types. The purpose of each of them is to provide a list of the UUIDs of the services supported by the device. The list can either represent the complete set of UUIDs or it can be incomplete and it can contain either 16-bit, 32-bit or 128-bit UUID values. So that’s 2 x 3 = 6. Get it?

Only UUIDs issued by the Bluetooth SIG may appear in the 16- or 32-bit lists.

Service Data

The Service Data AD Type allows arbitrary data associated with a specific UUID to be included in advertising packets or scan response PDUs. There are three variations of this type; one for 16-bit UUIDs, one for 32-bit UUIDs and one for 128-bit UUIDs. Google’s EddyStone beacon frame format uses this field with the 16-bit UUID 0xFEAA followed by service data which may be of one of three sub-types, UID, URL or TLM (telemetry).

Local Name

This is the device’s name or a shortened version of it.

Flags

This is an important AD Type and it is almost always included in advertising packets (It can’t be included in scan response PDUs). It tells you about the advertising state of the device and which of the two transports, Bluetooth^® low energy and Bluetooth BR/EDR it supports.

A device which is discoverable can either be in Limited Discoverable Mode or General Discoverable Mode. Limited Discoverable Mode is used to suggest that the device should have a high priority to scanning devices and often the advertising interval used when in this mode is faster than when in the General Discoverable Mode. A device will be in Limited Discoverable Mode for a limited time only and the core specification recommends this be no more than one minute. A device whose Flags field indicates it is not discoverable just means scanning devices should ignore it.

TX Power Level

The transmitted power of the packet in dBm.

Service Solicitation

This type is not commonly used but it isn’t the easiest to understand so I’ve included it here in the hope that my explanation is useful.

GAP and GATT are not coupled in any way. A device may have any one of the GAP roles and at the same time be either a GATT-client or a GATT-server. Of course, some combinations are more common than others. A GAP Peripheral is very often a GATT server but it doesn’t have to be. It’s just as valid for a GAP Peripheral to be a GATT =Client. When this is the case, the discovery process works as it always does, with the GAP Peripheral advertising and the GAP Central scanning. The Central device will make the connection to the Peripheral but once that’s been achieved, the GAP Peripheral—now acting as a GATT Client—will use the Attribute Protocol (ATT) to exploit the GATT services on the GAP Central/GATT server device. This AD Type allows the GAP Peripheral to effectively say, “I’m interested in devices which have the following GATT services…”

Handling Advertising Packets in Code

How much work is involved in writing code which scans for and extracts information from advertising packets depends on the platform you’re developing on. Some platforms provide APIs to parse advertising packets and give you ready access to at least some of the fields but others may only give you a byte array. Others let you specify sophisticated filtering rules so you only “see” advertising packets relevant to your application whilst others send your application all advertising packets received. Some perform active scanning automatically. Some have explicit APIs that you must use to invoke active scanning.

Understanding what to do with a raw advertising packet in the form of a byte array will stand you in good stead for any platform and it’s really not difficult. To help you get started, I’ve created an Android application called AdvScanner which includes a full advertising packet parser. You can download the source code.

Browse through the code in the advscanner/advertising directory to see how parsing works in the AdvScanner application or run the application on your Android phone to explore the advertising packets being emitted by devices in your environment. You’ll need a device which supports Android 5 at a minimum to use the application.

Conclusion

Advertising is a crucial part of Bluetooth^® low energy and one which developers can exploit in various ways. I hope this guided tour has been useful!