Bluetooth Low Energy (BLE or sometimes LE) is a wireless network technology that uses the same frequency bandwidth as Bluetooth Basic Rate/Enhanced Data Rate (BR/EDR, the “classic”-style connection) but with a different modulation strategy, allowing both technologies to coexist and share hardware, including the antenna.
The BLE standard was specifically designed for data exchange at low power and low cost for low-bandwidth applications. Although it has a potential data rate of 1Mbps and 30-meter line-of-sight range, in practice, applications are tuned down to 40-80Kbps at 2-5 meters to maximize power saving. Theoretically, a device could transmit from months to years with existing battery technology.
The original target market for BLE technology was lower-rate data transfer for the personal smart device, smart home and fitness sensor markets. It is also used for negotiating the connection details and control data for the faster-rate classic Bluetooth audio streaming. Because of the power savings potential, BLE was expanded in the 5.2 spec (January 2020) to send actual audio data (called LE audio), although LE codecs did not come available until late 2020.
The Bluetooth Special Interest Group (SIG) specifies many BLE data transfer protocols that devices might implement, such as MESH for data network applications, BLP for blood pressure monitoring, HID/HOGP for keyboard and mice, etc. However, these services are implemented on top of the core BLE data connection profiles: GAP and GATT. GAP is essential to defining a device as BLE-capable; GATT is optional but extremely common.
How are GAP and GATT protocols different?
GAP and GATT are complementary connection protocols that perform in parallel on BLE devices.
GAP, the Generic Access Profile, defines the framework for allowing device discovery, security, connectivity and the related network topology, and it is thus mandatory for a BLE device. It defines four roles a connection may implement:
|Active||Broadcaster ||Peripheral |
|Passive||Observer ||Central |
|Data|| || |
|Diagram||Figure 1. Connectionless ||Figure 2. Connection-oriented |
Note that a device is not limited to performing only one of these roles — the specification allows for multiple communication policies simultaneously.
GATT, the Generic Attribute Profile, focuses on the format of the data exchanged by devices; specifically, an exchange of ordered attribute/value declarations. Building on the more generic ATT, the Attribute Profile, which defines a protocol for exchanging Attribute Handle, Type/UUID and value data, GATT adds a layer of hierarchy/nesting to specify these attributes as characteristics of services within profiles (the hierarchy is implemented by declaring some of these attributes in the ordered list as start-of-profile and start-of-service markers). The network relationship between the exchanging devices is a standard client/server model, independent of the GAP relationship.
Figure 3. GATT, the Generic Attribute Profile, groups conceptually related attributes into a common parent container.
What kind of information can you convey over GAP advertising?
The primary data exchange method of GAP is a small broadcast advertising packet (optionally followed by a similar format scan response packet if requested by an observing peer). This packet conveys two types of information: the GAP role the device is advertising (important for peripheral devices in allowing a follow-on connection from a central device) and a formatted payload used for beaconing and to supplement device discovery/selection (such as delivering the cosmetic username).
After subtracting for the required header information (message type, device role, the sender’s MAC address, etc.), 31 bytes remain for a payload. This is partitioned into N number of records, each prefixed by one byte of record length, with the sequence being terminated by a “0”-byte value, illustrated as follows:
Figure 4. GAP Advertising and Scan Response Data Format
For each record, following the 1-byte record length is an Advertising Data (AD) Type field of variable length (typically 1-byte) and its associated AD data. The GAP spec defines the AD Types available: for example, Type “0x01” is an 8-bit list of capability flags, type “0x0A” is the Tx transmit power level of the device and type “0x10” is the registered Device ID. Also of interest is type “0xFF”, the Manufacturer Specific Data — this is where application-specific data can be embedded without requiring a public spec. (For example, TWE earbuds reporting their in-case/out-of-case status to an aware smartphone app.)
Table 1. Example GAP Advertising Data (AD) Types
|0x01||8-bit list of capability flags|
|0x0A||Tx transmit power level of the device|
|0x10||Registered Device ID|
|0xFF||Manufacturer Specific Data, where application-specific data can be embedded without requiring a public spec|
A common requirement is to advertise a BLE device’s cosmetic username (AD Type 0x09, “Roxane’s Headphones,” for example) in the advertising payload to aid in its discovery and user selection by an observing device. However, this long string can quickly consume the available 31 bytes in a payload, limiting other desired information to broadcast. The GATT profile allows for a name-discovery procedure once a connection has been made, but how can a broadcaster-only transmit its name plus other significant data? The solution lies in the scan response packet. This packet has the same payload format as the advertising packet but is only transmitted once an observer broadcasts a scan request packet at a specific time interval after scanning the first advertising packet. This procedure effectively doubles the available payload of a GAP broadcaster, and it is common to deliver the cosmetic name in the scan response.
Part two of this post details how GAP is being used as a Broadcast/Observer beacon by Google/Apple’s Covid-19 Exposure Notification System protocol.
What kind of information can you convey over a connection with GATT?
Once a central-to-peripheral connection has been made over GAP, devices are able to negotiate a GATT client/server data exchange. The GATT profile specifies the data transfer procedures and formats used to exchange an ordered list of Attribute Protocol (ATT) handles, types/UUIDs and related values, and it also defines a short hierarchy of service/characteristic organization to the list by defining some of the attribute types as markers — the attributes following a service marker are assumed to be subelements of that service.
A GATT service groups conceptually related attributes into a common parent container. These attributes form the Service Definition of the service, comprising the following characteristics and their descriptors. A GATT characteristic is a container for data, involving an attribute to declare that characteristic, one to hold its data value and optionally further descriptor attributes, cumulatively known as the Characteristic Definition. Conceptually, one can think of a service as an object-oriented class and its characteristics as members of that class.
The Bluetooth SIG manages publicly specified GATT services that devices may need for communication. For example, phone alert status, running speed and cadence and blood pressure are all industry-standard service profiles a Bluetooth device may want to support. Further, the SIG defines a way to register new open or proprietary services.
For example, the BLP blood pressure-monitoring protocol mentioned above defines a blood pressure sensor device as the GATT server, and the collector device as the GATT client. The BLP service is defined within the GATT profile and specifies characteristics such as blood pressure measurement and intermediate cuff pressure. Optionally, the GATT client collector may also implement the device information service. Were a blood pressure sensor connected to a smartphone to use the current time service to update its internal state, it would, for this operation, become the GATT client and the phone the GATT server.
Part two of this post details how GATT is being used as an exchange mechanism of JSON structures by Singapore’s BlueTrace Covid-19 notification protocol.
If you enjoyed this blog, subscribe to our quarterly newsletter below.