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:
The corresponding sections in this chapter will examine these elements in detail.
GAP specifies four roles that a device can adopt to join a BLE network:
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.
Table 3-1 shows GAP modes and their applicable procedures (modes that do not have a natural counterpart procedure are marked with “N/A”).
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.
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.
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.
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.
The following discoverability modes allow a certain amount of flexibility to peripheral designers, depending on design priorities (battery life, fast connection times, etc.):
ADV_NONCONN_IND
or ADV_SCAN_IND
types (see Table 2-1).
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.
The specification provides two discovery procedures:
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.
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.
The differences between the following connection establishment modes reflect a peripheral’s use of different types of advertising packets (detailed in Advertising and Scanning):
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.
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.
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.
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:
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.
GAP defines a few other procedures that are relevant only to already established connections, and which are commonly used:
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 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:
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.
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:
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).
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:
GAP APIs and documentation use both meanings extensively, so it is important to keep the differences in mind for the next few sections.
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:
This mode enforces security by means of encryption, and it contains three levels:
This mode enforces security by means of data signing (see Security Manager (SM)), and it contains two levels:
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.
Along with all the modes and procedures detailed in previous sections, GAP also defines additional ones related to security establishment and enforcement.
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).
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.
On top of all the roles, modes, and procedures, GAP also introduces two additional items that are relevant to the interests of application developers.
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.
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.
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:
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.