GAP (Advertising and Connections) - Getting Started with Bluetooth Low Energy (2014)

Getting Started with Bluetooth Low Energy (2014)

Chapter 3. GAP (Advertising and Connections)

The Generic Access Profile (GAP) is the cornerstone that allows Bluetooth Low Energy devices to interoperate with each other. It provides a framework that any BLE implementation must follow to allow devices to discover each other, broadcast data, establish secure connections, and perform many other fundamental operations in a standard, universally understood manner. It’s important to understand GAP thoroughly, because many BLE protocol stacks use it as one of the lowest-level entry points when providing a functional API to application developers.

As mentioned previously, the sections of the GAP chapter in the core specification that apply to Bluetooth Low Energy define the following different aspects of device interaction:

Roles

Each device can operate in one or more roles at the same time. Each role imposes restrictions and enforces certain behavioral requirements. Certain combinations of roles allow devices to communicate with each other, and GAP establishes the interactions between those roles precisely. Although not always, roles tend to be associated with specific device types, and for many (though not all) implementations, they are also tightly bound with their use case and do not change at all.

Modes

Further refining the concept of a role, a mode is a state in which the device can switch to for a certain amount of time to achieve a particular goal or, more especifically, to allow a peer to perform a particular procedure. Switching modes can be triggered by user interface actions or automatically when required, and devices tend to switch modes more frequently than roles.

Procedures

A procedure is a sequence of actions (usually Link Layer control sequences or packet exchanges) that allows a device to attain a certain goal. A procedure is typically associated with a mode on the other peer, so they are often tightly coupled together.

Security

GAP builds on top of the Security Manager and the Security Manager Protocol by defining security modes and procedures that specify how peers set the level of security required by a particular data exchange and later how that security level is enforced. GAP further defines additional security features not associated with particular modes or procedures, and implementations are free to use those to increase the level of data protection required by each application.

Additional GAP Data Formats

In addition to all of the above, GAP is also used as a placeholder for certain additional data format definitions that are related to the modes and procedures defined by the GAP sepcification.

The corresponding sections in this chapter will examine these elements in detail.

Roles

GAP specifies four roles that a device can adopt to join a BLE network:

Broadcaster

Optimized for transmit-only applications that distribute data regularly, the broadcaster role periodically sends out advertising packets with data. Theoretically, the broadcaster role could be used with transmitter-only radios, but in practice, this role is usually assigned to a device capable of both transmitting and receiving. A public thermometer that broadcasts temperature readings to any interested devices would be a good example of a broadcaster. Broadcasters send data in advertising packets rather than connection data packets, and the data is accessible to any device that is listening. The broadcaster role uses the Link Layer advertiser role.

Observer

Optimized for receive-only applications that want to collect data from broadcasting devices, the observer role listens for data embedded in advertising packets from broadcasting peers. For example, a device with a display is a typical application of this role, such as a table computer that displays temperature data from a broadcast-only temperature sensor. The observer role uses the Link Layer scanner role.

Central

The central role corresponds to the Link Layer master. A device capable of establishing multiple connections to peers, the central role is always the initiator of connections and essentially allows devices onto the network. The BLE protocol is asymmetric, which means that the computing requirements of the Link Layer master are larger than the ones of a Link Layer slave. The central role is usually played by a smartphone or tablet in the network, because it has access to powerful CPUs and memory resources. This allows it to maintain connections to multiple devices. The central starts by listening for other devices’ advertising packets and then initiates a connection with a selected device. This process can be repeated to include multiple devices in a single network.

Peripheral

The peripheral role corresponds to the Link Layer slave. This role uses advertising packets to allow centrals to find it and, subsequently, to establish a connection with it. The BLE protocol is optimized to require few resources for peripheral implementation, at least in terms of processing power and memory. This paves the way to a large market of inexpensive BLE peripherals.

Each particular device can operate in one or more roles at a time, and the specification imposes no restrictions on this regard.

Many developers mistakenly try to associate the BLE GATT client and server roles with GAP roles. There is no connection between those at all, and any device can be a GATT client, server, or both, depending on the application and situation.

Consider, for example, a fitness tracker paired with a smartphone. The fitness tracker’s GAP role is peripheral, and it acts as a GATT server when the phone requests data from its sensors. It can also sometimes act as a GATT client when it requests accurate time data from the smartphone to update its internal clock for data timestamping. The GATT client/server roles depend exclusively on the direction in which the data requests and responses transactions flow, whereas GAP roles stay constant as peripheral for the fitness tracker and central for the smartphone.

Modes and Procedures

Table 3-1 shows GAP modes and their applicable procedures (modes that do not have a natural counterpart procedure are marked with “N/A”).

Table 3-1. Modes and their applicable procedures

!

Mode

Applicable Role(s)

Applicable Peer Procedure(s)

Broadcast

Broadcaster

Observation

Non-discoverable

Peripheral

N/A

Limited discoverable

Peripheral

Limited and General discovery

General discoverable

Peripheral

General discovery

Non-connectable

Peripheral, broadcaster, observer

N/A

Any connectable

Peripheral

Any connection establishment

Conversely, Table 3-2 shows the modes that the peer needs be in to perform each of the listed GAP procedures.

Table 3-2. Procedures and their required modes

!

Procedure

Applicable Role(s)

Applicable Peer Mode(s)

Observation

Observer

Broadcast

Limited discovery

Central

Limited discoverable

General discovery

Central

Limited and General discoverable

Name discovery

Peripheral, central

N/A

Any connection establishment

Central

Any connectable

Connection parameter update

Peripheral, central

N/A

Terminate connection

Peripheral, central

N/A

Chapter 1 and Chapter 2 introduced the basic concepts of over-the-air data exchange in BLE, but it is worth reviewing them briefly here. Advertising packets are blindly sent unidirectionally at fixed intervals, and they constitute the basis of both broadcasting (and observing) and discovery. A device scanning for advertising packets might receive one if it happens to scan while an advertising packet is being transmitted, and it might simply receive the data contained in it or continue by initiating a connection. Connections, on the other hand, require two peers that synchronously perform data exchanges at regular intervals and provide guarantees on data transmission and throughput.

Broadcast and Observation

The broadcast mode and the observation procedure defined in GAP establish the framework through which devices can send data unidirectionally, as a broadcaster to one or more actively listening peer devices (the observers). It is important to note that the broadcaster has no way of knowing whether the data actually reaches any observers at all, so this combination of mode and procedure remains faithful to its nomenclature: a broadcaster broadcasts data without any confirmation or acknowledgement, and an observer listens (temporarily or indefinitely) for potential broadcasters without any guarantee of ever actually receiving any data.

The advertising packets sent by the broadcaster contain actual valid user data, along with a few items of metadata (such as Bluetooth device address) inserted by the Link Layer. As described in Advertising and Scanning, each advertising packet contains up to 31 bytes of data (the actual available user data length will be lower due to headers and format overheads), but that can be doubled by using the scan request/scan response transaction just after the successful reception of an advertising packet on the part of the observer, yielding up to 62 bytes of data per advertising event. Since a scan response packet is sent only upon request from the observer, the most critical and important data should always be placed in the advertising packet itself, not in the scan response packet. A broadcaster can send ADV_NONCONN_IND or ADV_SCAN_IND advertising packets (see Table 2-1).

By creating a broadcaster-only device, you can simply broadcast data to the outside world, where any device within listening range can pick it up, whether that means one device or one hundred devices. This is in marked contrast to a peripheral, which stops advertising itself after establishing a connection, effectively shutting itself off to any other central devices in listening range until the connection is closed or, in the rare case of devices that support multiple connections as a slave, until an additional connection is created.

For example, Apple’s iBeacon (iBeacon) uses the broadcast mode to constantly send out a specific payload in the Manufacturer Specific Data field of the advertising data, which allows any device that comes within earshot of the node to detect the iBeacon without having to compete for access with other devices in range. The iBeacon node doesn’t have to worry about how many devices are listening; it just keeps telling the world that it’s there and transmitting its limited payload to anyone who cares to listen.

Discovery

A device’s discoverability refers to how the peripheral advertises its presence to other devices and what those devices can or should do with that information. The differences between the different discoverable modes and discovery procedures concern whether advertising and scanning are actually being performed but also take into account the nature of the data included in advertising packets. More specifically, a SIG-defined optional field within the advertising data named Flags AD governs a device’s discoverable mode (see Table 3-3).

Used only by peripherals, these modes allow central devices to discover peripherals within their listening range. Discovery commonly refers to detecting the presence and the basic information of another device nearby. That does not necessarily imply an intention to create a connection or exchange data, although that is naturally often the case. In some instances, and especially with central devices equipped with user-visible displays, discovery is simply used to populate a list with nearby devices from which the user can then select one.

Discoverability modes

The following discoverability modes allow a certain amount of flexibility to peripheral designers, depending on design priorities (battery life, fast connection times, etc.):

Non-discoverable mode

Not being discoverable means other devices cannot learn about the presence of the peripheral or perform any inquiries about its nature. This mode is typically used when a device does not want to be found by central peers at all, either to establish a connection or even to be detected (listed). A device in this mode can still send advertising packets, but in that case, the device must clear the General and Limited Discoverable bits in the Flags AD field within its advertising data. If it does choose to send advertising packets, they must be of the ADV_NONCONN_IND orADV_SCAN_IND types (see Table 2-1).

Limited discoverable mode

This mode allows a device to be discoverable for a limited period of time and with a lowered priority. A device in this mode sends advertising packets with the Limited Discoverable flag in the Flags AD field set (see Table 3-3). Central devices performing the limited discovery procedure will be able to detect only devices in this mode. The popularity of this mode has been dwindling with time, and today the tendency is to use the general discoverable mode with additional filters when required.

General discoverable mode

This mode makes a device discoverable for as long as it is required or deemed necessary. A device switching to this mode expresses its desire to be discovered by central peers, generally with the intention of establishing a connection. To be in this mode, a device must set the General Discoverable flag in the Flags AD field of the advertising data while sending advertising packets (see Table 3-3). Only central devices performing the general discovery procedure will find peripherals in this mode.

Peripheral devices often come up from the factory in a discoverable mode before bonding with a central device, but then go into non-discoverable mode after the initial bonding procedure, allowing it to connect exclusively with that central device in the future. In this case, a reset to factory defaults usually brings it back into a discoverable mode.

Discovery procedures

The specification provides two discovery procedures:

Limited discovery procedure

A central performing this procedure starts active scanning with no white list filtering (see White Lists) for advertisers and analyzes each advertising packet that it receives. If the Limited Discoverable flag is set, the peer device is reported to the application for further action.

General discovery procedure

A central performing this procedure starts active scanning with no white list filtering (see White Lists) for advertisers and analyzes each advertising packet that it receives. If either the Limited Discoverable or General Discoverable flags are set, the peer device is reported to the application for further action.

In practical terms, devices looking for all possible discoverable peers should opt for the general discovery procedure. Use the limited discovery procedure to find only devices in limited discovery mode.

Connection Establishment

For a central to initiate a connection establishment with a peripheral, the latter must be in a connectable mode. Similar to discovery, several modes and procedures control the selection of devices with which to interact, in an organized and standardized fashion.

Connection establishment modes

The differences between the following connection establishment modes reflect a peripheral’s use of different types of advertising packets (detailed in Advertising and Scanning):

Non-connectable mode

A device in this mode either does not send advertising packets at all or it sends ADV_NONCONN_IND or ADV_SCAN_IND advertising packets (see Table 2-1). In both cases, the device is, as the mode name implies, not connectable, meaning that no centrals may establish a connection with it.

Directed connectable mode

A device in this mode sends ADV_DIRECT_IND advertising packets (see Table 2-1). When performing directed advertising, a device sends advertising packets at a high frequency and for a short time, with no user data payload and with a target central Bluetooth Address. This is provided as a “fast reconnect” mode typically used when the peripheral has a strong suspicion that the target central is already trying to initate a connection and wants to establish it as fast as possible. Only the central whose Bluetooth address matches the one in the advertising packets sent by the peripheral will receive them.

Undirected connectable mode

A device in this mode sends ADV_IND advertising packets (see Table 2-1). This is the standard connectable mode, through which a peripheral makes itself connectable for a longer period of time and may be trying to connect to a new central or to one that is already previously known by it.

Both connectable modes implicity require the device to send the advertising packets with the intent to connect to a central.

Connection establishment procedures

Because a central device has no means to select which advertising packet types it will receive when scanning with the intent to connect (they will always be of type ADV_IND or ADV_DIRECT_IND), the distinctions between connection establishment procedures do not depend on types of advertising packets. Instead, the type of connection establishment procedure used depends on the kind of filtering the central imposes on those incoming packets:

Auto connection establishment procedure

With this single-step procedure, the host populates a white list (see White Lists) with an array of known peripheral devices and then instructs the controller to connect to the first one detected. Generally speaking, this procedure is useful when the central already knows a limited set of devices and does not have a preference for which one to connect to.

General connection establishment procedure

This two-step procedure is commonly used to connect to a new, unknown peripheral. The central starts by scanning without a white list, accepting all incoming advertising packets. For each peripheral detected, the application then needs to decide whether to connect to it or to continue to the next one. To do so, the application can prompt the user or parse advertising data included in the received advertising packet. Once a peripheral is chosen, the central connects to it using the direct connection establishment procedure.

Selective connection establishment procedure

This procedure is identical to the general connection establishment procedure, with the exception that the host uses a white list of previously known devices to filter incoming advertising packets. This can be useful in certain cases in which the user should choose which of several known peripherals to connect to.

Direct connection establishment procedure

This standard single-step connection establishment procedure connects the central to one particular peripheral. The host uses the Link Layer to initiate a connection to one single device, identified by its Bluetooth Address, without previous knowledge of its presence. The procedure can fail if the targeted peripheral is not available or is not in a connectable mode.

It is worth reiterating that a central host has two different ways to initiate a connection. The first method requires two steps: first scanning and then connecting directly to a device (by specifying its Bluetooth Address) detected during the scanning phase. The second method skips the explicit scanning step and instead uses the controller to select one or more devices to connect to, without previous knowledge of whether they are actually nearby.

Additional GAP Procedures

GAP defines a few other procedures that are relevant only to already established connections, and which are commonly used:

Name discovery procedure

Advertising packets can carry many different types of user data, including the Device Name: a UTF-8 string containing a human-readable description of the device (similar to a network hostname). But space in the advertising packet is at a premium, so sometimes devices might not choose to include the Device Name. For such cases, the name discovery procedure allows a peripheral or central to retrieve the Device Name over an established connection by using a GATT transaction.

Connection parameter update procedure

Each connection establishment requires a set of connection parameters that are set unilaterally by the central. These parameters are the key factors in the balance between throughput and power consumption for a connection (as described in Connections) and can be modified later in a connection to adapt to changing balance requirements. The central is always responsible for physically modifying the connection parameters and can do so at any time without warning, but the peripheral also has the ability to request the central for a change to a specific desired set of connection parameters. After doing so, the central can opt to deny the request or to honor it. However, even if it does decide to change the connection parameters, they might not be the exact ones requested by the peripheral, but rather whatever the central considers reasonable and closest to the requested set.

Terminate connection procedure

This procedure is self explanatory and completely symmetrical: both the peripheral and the central can terminate the connection at any time, while providing a reason code that the peer application will receive along with the disconnection event.

Although this concludes the general GAP modes and procedures portion of this chapter, introduces specific modes and procedures exclusive to the subject of security.

Security

Security is built into the core of the Bluetooth Low Energy wireless technology. Since the introduction of BLE in the Bluetooth 4.0 core specification, the secure transmission of user data has been a primary design goal, and version 4.1 builds upon the strong foundations of its predecessor and tightens those principles even further.

As introduced in Security Manager (SM), the enforcement of security and privacy in BLE is based on two pillars:

Security Manager (and its protocol)

The Security Manager implements the actual cryptographic algorithms and protocol exchanges that allow two devices to securely exchange data and privately detect each other. This is typically implemented inside the protocol stack and uses the available hardware acceleration modules to perform the required operations, such as generating random numbers, encrypting data using the Advanced Encryption Standard (AES), and generating and exchanging security keys with the peer.

GAP security aspects

GAP defines a set of modes and procedures related to security that allow the implementation to trust the connection to carry sensitive data and to confidently accept the identity of a peer device. Security procedures are mostly asymmetrical, with the central and the peripheral assuming different roles during the generation and exchange of keys and the subsequent use of them to establish a secure connection. Additionally, GAP further expands and specifies the usage of the tools defined in Security Manager (SM) in a standard and interoperable manner.

The following sections further detail the GAP security aspects that, although at times complex and even convoluted, are fundamental to the operation of a majority of BLE devices.

Address Types

As discussed in Bluetooth Device Address, at its lowest level, the BLE protocol stack differentiates between public and random device addresses. GAP extends the concept of random device addresses by classifying them into three different categories:

Static address

Static addresses are typically used as a replacement for public ones whenever the manufacturer does not want or need the overhead of IEEE registration. A static address is simply a random number that can either be generated every time the device boots up or can stay the same for the lifetime of the device. However, it cannot be changed during a power cycle of the device.

Non-resolvable private address

This type of address is not commonly used. Also a randomly generated number, it represents a temporary address used for a certain amount of time.

Resolvable private address

Resolvable private addresses form the basis of the privacy feature. They are generated from an identity resolving key (IRK) and a random number, and they can be changed often (even during the lifetime of a connection) to avoid the device being identified and tracked by an unknown scanning device. Only devices that possess the IRK distributed by the device using a private resolvable address can actually resolve that address, allowing them to identify the device.

GAP also defines an encoding scheme to obtain the category from the two highest bits of the BD_ADDR 48-bit value, which can be useful in certain situations. But to ascertain the nature of a BLE address, you need one extra bit on top of the 48-bit, because otherwise it would be impossible to know whether the BD_ADDR corresponds to a public or a random device address (public device addresses make no guarantees regarding the contents of its most significant bits).

Authentication

The usage of the word authentication and its derivatives in the BLE specification (and in GAP in particular) is rather convoluted and can lead to confusion, so this section attempts to clarify the two different meanings it might convey:

Authentication as a procedure

In GAP, the authentication procedure refers to enforcing security on the current connection. This can refer to pairing (with or without bonding) or re-establishing security using a stored encryption key, as described in Security Procedures. The verb to authenticate is used in the same way (i.e., to perform the authentication procedure).

Authenticated as a qualifier

As a qualifier for a pairing procedure or an existing key, authenticated means using an algorithm other than Just Works (see Pairing Algorithms). In this sense, it implies that MITM protection was available during the pairing procedure and key exchange, adding an additional level of trust. Both passkey display and out-of-band (OOB) are algorithms that produce authenticated keys. Conversely, an unauthenticated pairing procedure (using Just Works) can produce only unauthenticated keys. When applied to encryption or data signing, authenticated refers to the keys used to perform those procedures.

GAP APIs and documentation use both meanings extensively, so it is important to keep the differences in mind for the next few sections.

Security Modes

A connection is said to operate in a (single) security mode. The use of mode in this context differs sharply from the one in previous sections. This defines the current security level of the connection, which at some point in time might differ from the requirements that the peers at each end want to enforce, leading to procedures to increase that security level.

GAP defines two security modes, along with several security levels per mode:

Security mode 1

This mode enforces security by means of encryption, and it contains three levels:

Level 1

No security (the link is not encrypted).

Level 2

Unauthenticated encryption.

Level 3

Authenticated encryption.

Security mode 2

This mode enforces security by means of data signing (see Security Manager (SM)), and it contains two levels:

Level 1

Unauthenticated data signing.

Level 2

Authenticated data signing.

Each connection starts its lifetime in security mode 1, level 1, and can later be upgraded to any of the security modes by means of encryption or data signing. It is important to know that a link can be downgraded from mode 1, level 3, to mode 1, level 2 by switching encryption keys, but encryption can never be disabled in the lower layers, making it impossible to go down from security mode 1, level 2.

Security Modes and Procedures

Along with all the modes and procedures detailed in previous sections, GAP also defines additional ones related to security establishment and enforcement.

NOTE

In this section, the term mode refers back to the temporary state to which a device can switch in order to perform a procedure or to allow a procedure to be performed.

This section briefly describes the security modes and procedures, which complement and build upon the basis set in Security Manager (SM).

Non-bondable mode

A device in this mode does not allow a bonding procedure to take place, although it can freely permit pairing procedures to execute. In this mode, a device cannot distribute, accept, or store keys, limiting all security level upgrades to the lifetime of the connection.

Bondable mode

This mode enables the device to create a bond with a peer, permanently storing security keys.

Bonding procedure

The central can initiate the bonding procedure described in Security Procedures at any time (even if the devices are already bonded, in which cases new keys would be generated and the old ones would be replaced). However, it is relatively common practice to hold off until a GATT data access actually requires a higher security mode than the one currently in force.

Authentication procedure

As mentioned in Authentication, the authentication procedure enforces the transition to a security mode on a connection currently in a lower security mode. This enforcement can come in the form of a pairing or bonding procedure or, if encryption keys are already available and sufficiently authenticated on both sides, in the form of an encryption procedure.

Authorization procedure

Authorization in BLE and GAP refers to giving the application and, ultimately, the user the opportunity to accept or reject a particular transaction. This might take the shape of an internal application check if the device does not have a user interface, or if it does, it can ask the user for permission directly.

Encryption procedure

This procedure uses the Link Layer’s built-in encryption capabilities to start the encryption of all traffic over the current connection, as described in Connections and Security Procedures. Although the central is the only one able to initiate an encryption procedure, the peripheral can request the central to do so by means of the security request mentioned in Security Manager (SM).

Although not strictly a mode or procedure, the privacy feature deserves a few words in the section on GAP security. Privacy was one of the aspects of the BLE specification that underwent a substantial modification between versions 4.0 and 4.1. The feature was simplified and the specification text was adapted to reflect what implementations had been using in practice for years, acommodating itself to the established status quo among currently shipping devices.

This revision was named Privacy 1.1 and was actually listed as a new feature in the 4.1 release, replacing the old privacy section. When using the privacy feature, a device periodically generates a new resolvable private address (see Address Types) and sets it as its own. The only way for a peer to identify it is to resolve the address using an IRK, because all resolvable private addresses are temporary in nature and it makes no sense to store them permanently.

Instead, an IRK (see Security Keys) previously shared and stored by both devices is used to generate the address in the device, protecting its identity and resolving it on the device trying to identify it. This feature can be used in all GAP roles concurrently and prevents malicious devices deprived of the shared IRK from identifying and tracking a particular device using its Bluetooth device address.

Additional GAP Definitions

On top of all the roles, modes, and procedures, GAP also introduces two additional items that are relevant to the interests of application developers.

Advertising Data Format

So far, we have been talking about the user data that can be carried by advertising (and scan response) packets, but we have not mentioned the format in which this data must be populated. The generic container is defined in the core specification in GAP, and it simply consists of a sequence of data structures, each of which is made of length (1 byte), AD Type (Advertising Data Type, 1 byte), and the actual data (variable length). Each structure contains a separate item of user data.

The complete list of allowed AD Types is available in the Core Specification Supplement (CSS, currently at version 4) at the Bluetooth SIG’s Specification Adopted Documents page. Table 3-3 describes the most commonly used AD Types in typical application development. This list isn’t exhaustive, though, so you might want to explore AD Types further for more detailed information.

Table 3-3. AD Types

!

Name

Actual data length in bytes

Description

Flags

1 (extendable)

Used to set limited or general discovery mode, as described in Discovery

Local Name

variable

Partial or complete user-readable local name in UTF-8

Appearance

2

A 16-bit value describing the type of device sending the advertising packet

TX Power Level

1

The power level in dBm used to transmit the advertising packet, useful to calculate path loss at the observer or central end

Service UUID

variable

A complete or partial list of GATT services offered by the device sending the packet (as a GATT server)

Slave Connection Interval Range

4

A suggestion to the central about the connection interval range that best fits this peripheral

Service Solicitation

variable

A list of GATT services supported by the device sending the packet (as a GATT client)

Service Data

variable

A UUID representing a GATT service and its associated data

Manufacturer Specific Data

variable

Freely formattable data, to be used at the discretion of the implementation

Not all AD Types are useful in every situation, and the 31-byte advertising packet and scan reponse size limits how many AD Types you can include, but it’s important to understand what types of information are available and which fields are relevant in different situations. This section briefly describes how the service-related AD Types can be useful for a wide range of applications.

Services and service UUIDs are used to encapsulate data into logic groups in BLE (see Chapter 4 for more details). The Bluetooth SIG defines a number of official services, all of which have a unique UUID associated with them, and you are free to create your own custom services with their own dedicated UUID. Services are what make device interoperability possible. For example, any device that implements the Battery Service must do so based on the same data contract defined by the Bluetooth SIG, using the same UUIDs and data format.

An advertising packet can include complete or incomplete lists of service UUIDs under the Service UUID AD Type to let other devices know which services are exposed by the peripheral without having to establish a connection with it. Connections are expensive, and limiting the occasions where connections are necessary can help extend battery life. By letting the world know that the device exposes a certain set of services as a GATT server, you can more quickly determine if that device is relevant to you without connecting to every device that comes within range.

Conversely, service solicitation allows the central receiving the advertising packets to find out which services the peripheral can access when it is acting as a GATT client. In certain cases, if the central is not exposing any of these services at all as a GATT server, it might not even bother to connect to it, knowing that interaction would be extremely limited.

While services are normally used only after a connection is established, the advertising packet includes a mechanism to offer service data right in the advertising payload: the Service Data. The key benefit of using the Service Data field is that it allows you to broadcast the data contained inside your GATT services to any number of listening devices, bypassing the need to a dedicated connection between two devices to read service data.

Finally, the Manufacturer Specific Data AD Type is a generic catch-all field that can include an arbitrary chunk of data in your advertising payload. For example, Apple’s iBeacon (iBeacon) uses this AD type to push data out to other devices, inserting a 128-bit UUID that identifies the location and two 16-bit values to distinguish individual nodes in the same family. This field provides a lot of flexibility to product designers who want to broadcast short chunks of custom data, and you’re generally free to change to contents of the field from one advertising event to the next.

Please note that the Bluetooth SIG might release further updates to the Core Specification Supplement at the Specification Adopted Documents page whenever new AD Types are available for public consumption.

GAP Service

The final item that GAP includes as part of its section in the core specification is the GAP Service, a mandatory GATT service that every device must include among its attributes (see Attribute Protocol (ATT)). The service is freely accessible (read-only) to all connected devices with no security requirements whatsoever, and it contains the following three characteristics:

Device Name characteristic

This contains the same user-readable UTF-8 string that can also be included in the Device Name AD Type described in Table 3-3. This is the characteristic read to perform the name discovery procedure in Additional GAP Procedures.

Appearance characteristic

This 16-bit value associates the device in which it is included with a certain generic category (phone, computer, watch, sensor, etc.) and is typically used by the GATT client to display an icon that represents the given category. This characteristic can also be made available in the advertising packet with the Appearance AD Type.

Peripheral Preferred Connection Parameters (PPCP) characteristic

Once the central has established a connection with the peripheral, it can (although it has no obligation to) then read the value of this characteristic and perform a connection parameter update procedure (described in Additional GAP Procedures) to change the connection’s parameters to values that are agreeable to the peripheral.

Chapter 4 explores GATT services and characteristics in more detail, along with all of the procedures that allow BLE devices to exchange user data over an established connection.