Generic Access Profile (GAP)
Chapter 14 · Part 1 of 3 · GATT Security Wrap-Up · GAP Introduction · Four Roles · Bluetooth Parameters · Advertising Data Format
SEO Keywords
13.9 — GATT Security Considerations
Authentication and Authorization in GATT
Every attribute in a GATT profile carries its own permissions — defined either by the GATT profile specification, a higher-layer profile, or the application itself. The general rule is simple but important: service and characteristic declarations are public. Any connecting device can read what services and characteristics a server exposes, without any authentication or authorization.
If a client tries to read a write-only attribute — for example, the Alert Level control point — it gets an Error Response with code “Read Not Permitted”. The existence of that attribute was public information, but its value cannot be read. This separation between discoverability and access is intentional: it allows any device to understand what a server offers before deciding whether to initiate pairing.
13.10 — GATT Chapter Summary
GATT wraps ATT attributes into a structured hierarchy — profiles hold services, services hold characteristics — and provides the complete set of tools to discover, read, write, and subscribe to those characteristics. The hierarchy groups related attributes together so that discovering a Heart Rate Service automatically brings with it all the information needed to read heart rate measurements.
The BR/EDR world had SDP for service discovery. In BLE, GATT plays that role and goes further — it not only announces services but provides the full read/write/notify interface for them. Because GATT encapsulates all the complexity, the profiles built on top of it are intentionally thin: they only need to define what data to expose, not how to expose it.
14.1 — What is the Generic Access Profile?
The Foundation Every BLE Device Must Build On
The Generic Access Profile is the mandatory baseline for every Bluetooth device. While GATT defines how data is structured and accessed, GAP defines how devices find each other, connect to each other, and establish trust. Without GAP, there is no discovery, no connection setup, and no security negotiation. Every BLE profile sits on top of GAP and GATT together.
GAP also standardises the terminology used in device UI. When a user’s phone asks for a “Bluetooth Passkey”, the word Passkey comes from GAP. When a device shows its “Bluetooth Device Name”, that naming convention is GAP. This prevents a confusing situation where one manufacturer calls it a PIN, another calls it a Passkey, and a third calls it a Security Code — GAP locks in the vocabulary.
Minimum LE Device Requirements
GAP defines what every LE device must implement as a baseline before any application profile can be added:
14.2 — Four GAP Roles
How Devices Identify Their Purpose in a BLE Network
GAP defines four distinct roles for LE devices. A device can run multiple roles simultaneously if the Link Layer can support it. The role a device takes determines what packets it sends and receives and whether it can establish connections.
Transmit-only role. Sends advertising events continuously. The device may have no receiver at all — saving hardware cost and power. Used for one-way data broadcast: beacon tags, location transmitters, environmental sensors that push readings with no need for a connection.
Receive-only role. Listens for advertising events. The device may have no transmitter — reducing footprint and power. Used for scanning gateways, location receivers, and analytics devices that consume broadcasted data without ever connecting or responding.
Accepts connection requests from a Central. Supports a single connection and acts as Slave in the piconet. Needs both transmitter and receiver. Typical examples: heart rate monitors, thermometers, fitness trackers, BLE headphones. Simple, low-power, often battery-operated.
Initiates connections to Peripherals. Supports multiple simultaneous connections and acts as Master in each piconet. Typical examples: smartphones, tablets, PC dongles, BLE gateways. Higher power budget and more processing capability than peripherals.
Broadcaster
Observer
Central
Master
Peripheral
Slave
14.3 — Bluetooth Parameters at the UI Level
Why Standardised Names Matter for Interoperability
GAP goes beyond the protocol level and specifies the exact strings that should appear on user interfaces, in user manuals, and in advertising material. This means a user’s experience is consistent whether they are pairing a Sony headset to an Apple phone or connecting a Fitbit to a Samsung tablet. The terminology is unified.
14.3.1 — Bluetooth Device Address
A 48-bit value that uniquely identifies a Bluetooth device. LE devices use either a public address (registered with IEEE) or a random address (self-generated, possibly changing for privacy). The UI term is “Bluetooth Device Address”. It is shown as 12 hex digits, optionally separated by colons:
Dual-mode (BR/EDR + LE) devices use the same BD_ADDR on both transports
14.3.2 — Bluetooth Device Name
A human-readable string (up to 248 octets, UTF-8 encoded, null-terminated if shorter than 248). For LE devices the name lives in the Device Name Characteristic (UUID 0x2A00) and is read via GATT. This is a deliberate simplification vs BR/EDR where the name was fetched at the link manager level. UI term: “Bluetooth Device Name”.
14.3.3 — Bluetooth Passkey
A 6-digit number used during the Passkey Entry pairing method. Range: 000000 to 999999. Devices without a keypad use a fixed passkey. UI term: “Bluetooth Passkey” (not PIN, not Security Code).
14.3.4 — Class of Device
BR/EDR concept only. LE-only devices do not use Class of Device. The equivalent in LE is the Appearance Characteristic in GAP service.
14.3.5 — Pairing, Authentication, and Bonding
Pairing is performed by the Security Manager (Chapter 11). When the user creates a persistent trusted relationship between two devices, it is called Bonding. When the user enters a Passkey as part of the connection procedure to prove identity, it is called Authentication. These three terms have precise meanings and should not be used interchangeably.
14.4 — Advertising and Scan Response Data Format
How Data Is Packed Into the 31-Byte Advertising Payload
The advertising payload (AdvData in ADV_IND / ADV_NONCONN_IND / ADV_SCAN_IND) and the scan response payload (ScanRspData in SCAN_RSP) are each up to 31 octets. Both use the same internal structure: a sequence of AD (Advertising Data) structures packed back-to-back, with any unused space filled with zeros.
The scanner can request additional data from an advertiser by sending a SCAN_REQ packet. The advertiser responds with a SCAN_RSP packet containing up to 31 more bytes of data. This effectively doubles the available advertising payload for scannable advertising events.
1 octet
number of bytes that follow
1 octet
specifies meaning
Length − 1 octets
actual content
14.4.1 — Local Name (AD Type 0x08 / 0x09)
Carries the device name inside the advertising packet itself so scanners can display it without connecting. AD Type 0x08 means the name has been shortened to fit the 31-byte limit. AD Type 0x09 is the complete name. If AD Type is 0x08, the full name can always be read from the Device Name Characteristic via GATT after connecting.
14.4.2 — Flags (AD Type 0x01)
A single byte bitmask that announces discoverable state and transport capabilities. Multiple flags can be combined by OR-ing the values together:
| Value | Meaning |
|---|---|
| 0x01 | LE Limited Discoverable Mode — temporary discoverability |
| 0x02 | LE General Discoverable Mode — indefinitely discoverable |
| 0x04 | BR/EDR Not Supported — LE only device |
| 0x08 | Simultaneous LE + BR/EDR capable (controller) |
| 0x10 | Simultaneous LE + BR/EDR capable (host) |
14.4.3 — Manufacturer Specific Data (AD Type 0xFF)
A company ID (assigned by Bluetooth SIG) followed by any proprietary payload. Used for custom beacon formats, proximity detection, Apple’s iBeacon, Eddystone beacons, and any vendor-specific data a device wants to broadcast before a connection.
Figure 14.6 — Decoding a Real AdvData Payload
The captured ADV_IND packet has a 23-byte payload: 6 bytes for the advertiser address and 17 bytes of AdvData. The AdvData contains two AD structures packed back-to-back:
/* Scan for advertising data with BlueZ: */
sudo hcitool lescan --passive
/* See full AdvData hex: */
sudo btmon 2>&1 | grep -A 20 "ADV_IND"
/* LE Meta Event: LE Advertising Report */
/* Type: ADV_IND (0x00) */
/* Address: AA:BB:CC:DD:EE:FF (random) */
/* RSSI: -65 dBm */
/* Data length: 17 */
/* Flags: 0x06 [LE general discoverable, BR/EDR not supported] */
/* Complete Local Name: Battery V1.0 */
/* Parse advertising data with bluetoothctl: */
bluetoothctl
[bluetooth]# scan on
/* [NEW] Device AA:BB:CC:DD:EE:FF Battery V1.0 */
[bluetooth]# info AA:BB:CC:DD:EE:FF
/* Name: Battery V1.0 */
/* ManufacturerData Key 0x004c: 02 15 ... (if present) */