graph TD
P["Profile"] --> S1["Service: Heart Rate"]
S1 --> C1["Characteristic: Measurement"]
S1 --> C2["Characteristic: Body Location"]
C1 --> D1["Descriptor: CCCD (enable notify)"]
4 BLE Protocol Stack and GATT
Generic Attribute Profile and Service Architecture
networking
wireless
bluetooth
ble
gatt
protocol
Keywords
ble, gatt, bluetooth, services, characteristics, profiles, att, gap
4.1 Start With the Story
A phone connects to a sensor, but the product is not useful until the data has a name, a type, a permission, and a change rule. GATT is the place where a radio link becomes a product data contract.
Read this chapter as a service design story. Start with one measurement or command, then trace how GAP, ATT, services, characteristics, descriptors, reads, writes, and notifications make that value discoverable and reviewable.
4.2 GATT Turns BLE Links Into Product Data
Bluetooth Low Energy separates the radio link from the data model. The lower layers advertise, scan, connect, schedule packets, and secure the link. GATT gives the application a structured way to expose product data as services, characteristics, properties, descriptors, and permissions.
Classic Bluetooth uses a different discovery boundary. The Service Discovery Protocol (SDP) lets a device ask another device which services and profile features it offers, using a request/response model over a reliable packet transfer path. In BLE, GAP handles advertising, discovery, roles, and connection timing, while ATT and GATT describe the service database. Keep those names separate in reviews: SDP proves Classic service discovery, but a BLE product still needs GAP reachability plus GATT service and characteristic evidence.
For IoT, the review question is not “does the device use BLE?” It is whether the chosen services, characteristics, notification behavior, security boundary, payload size, and retest trigger match the product job. A sensor, lock, beacon, gateway, and maintenance tool can all use BLE while needing different GATT evidence.
Worked example: a greenhouse node may expose three separate service areas. A device-information service identifies firmware and model, a battery service exposes remaining charge as a readable value, and a custom growing-zone service exposes temperature, humidity, and irrigation commands. The temperature characteristic may support Read for setup and Notify for live updates; the irrigation command should support Write only with the right permission; and the sampling interval may be a configuration characteristic with a documented unit and valid range. That one device is still “a BLE device,” but its product contract lives in the GATT table, not in the radio label.
If you only need the intuition, this layer is enough: a GATT service is the category of data, a characteristic is one value or control, and the properties say how clients may interact with it.
4.2.1 Beginner GATT Pieces
Service
A group of related characteristics, such as battery state, environmental readings, device information, or a custom product feature.
Characteristic
A typed value with access behavior: read, write, notify, indicate, or a combination that fits the product requirement.
Descriptor
Metadata attached to a characteristic. The CCCD is the descriptor clients write to when they opt in to notifications or indications.
Profile
A reusable behavior pattern that combines services and expectations so clients can interoperate without guessing the data model.
4.2.2 Beginner Example
A room sensor can expose an environmental service with temperature and humidity characteristics, plus a battery service. The mobile app may read the current values during setup, write a sampling interval if the product allows configuration, and subscribe to notifications when live updates are required.
That same example also shows why profiles matter. If a standard service matches the meaning, a generic client can recognize it without private documentation. If the team invents a custom UUID for a standard-looking value, every client must learn that private meaning and every future app version must preserve it. The assessment habit is to ask what the service means, how each characteristic is used, and which client behavior proves it.
4.2.3 Overview Knowledge Check
4.3 Design a Reviewable GATT Record
A practical BLE protocol review records the data contract before implementation details take over. For every service and characteristic, the record should say what product behavior it supports, whether the UUID is standard or custom, what the value format means, which properties are allowed, what security is required, and what client behavior is expected after reconnect.
4.3.1 How It Works: GATT Design Route
- Name the product behavior. Separate live telemetry, configuration, control, identity, battery state, diagnostics, and beacon behavior.
- Choose standard or custom UUIDs. Prefer standard services when the data meaning fits; use custom UUIDs when the product meaning is proprietary.
- Set properties deliberately. Use read for inspection, write for configuration or control, notify for pushed updates, and indicate when acknowledgment is part of the requirement.
- Record descriptors and permissions. Include CCCD behavior, presentation metadata if needed, authentication requirements, and what is stored after bonding or reconnect.
- Test payload and timing boundaries. Verify MTU behavior, segmentation, update interval, missed-sample handling, and what happens when the client reconnects.
4.3.2 Intermediate Example
A battery sensor publishes a reading every minute. A read-only battery characteristic supports setup checks, while notification support lets the app receive changes without polling. The review record should say whether the client must resubscribe after reconnect, whether stale readings are visible, whether missed notifications are acceptable, and whether security is required before reading the value.
4.3.3 GATT Review Ledger
Decision Area
Review Question
Evidence To Record
Common Failure
Service boundary
What product behavior does this service group?
Service name, UUID choice, standard or custom meaning, client discovery path, and owner.
Using a custom UUID when a standard service fits, or using a standard label for nonstandard semantics.
Characteristic contract
What value or command is exposed?
Type, units, scale, byte order, valid range, update rule, stale-state behavior, and versioning expectation.
Shipping a byte array that only one app version can interpret.
Notification behavior
How does the client opt in to pushed updates?
Notify or indicate choice, CCCD write behavior, reconnect handling, missed-update policy, and client callback evidence.
Assuming the Notify property automatically starts updates.
Payload boundary
Can the value fit the negotiated exchange?
Observed MTU, segmentation rule, maximum sample size, timestamp or sequence field, and failure behavior.
Testing only with one phone and one payload size.
4.3.4 Worked Review: Notification Subscription
A peripheral exposes a temperature characteristic with Notify. The client connects and discovers the characteristic, but no updates arrive. A reviewable diagnosis checks whether the client wrote the correct CCCD value, whether the server actually sent notifications after that write, whether the client callback handled them, and whether reconnect requires a fresh subscription.
4.3.5 Practitioner Knowledge Check
4.4 The Stack Boundary Shapes the Data Contract
Under the hood, BLE data moves through multiple boundaries. The controller handles radio timing and link behavior. The host stack handles L2CAP, ATT, GATT, GAP, and security behavior. The application decides what each value means and whether stale, duplicated, delayed, or missing data is acceptable.
The review should not collapse those layers into one success flag. A successful connection does not prove that the GATT table is discoverable. A readable characteristic does not prove notifications are enabled. A notification event does not prove the app interpreted the value correctly or stored it safely.
The packet boundary is just as important as the service boundary. A BLE link-layer data packet starts with a preamble, a 4-byte access address, a protocol data unit, and a CRC; encrypted data may also carry a message integrity check. Above that, L2CAP frames ATT operations, ATT exposes attribute handles, GATT gives those handles service and characteristic meaning, GAP manages discovery and role behavior, and SMP handles pairing and key setup. That stack is why a blood-pressure profile, a battery profile, and a custom sensor service can share the same radio while needing different evidence.
4.4.1 Layer Boundaries To Preserve
ATT boundary
Attribute handles, operations, permissions, and payload size determine what the client can read, write, or subscribe to.
GATT boundary
Services, characteristics, descriptors, UUIDs, and profiles define the product data model and interoperability claim.
GAP boundary
Advertising, discovery, connection role, and connection timing determine how the client reaches the GATT model.
Security boundary
Pairing, bonding, encryption, authorization, and key custody determine who may read, write, or retain state after reconnect.
4.4.2 Payload and MTU Review
Payload size is a design boundary, not an afterthought. The record should say what the minimum supported client can handle, whether larger MTU negotiation is optional or required, how values are split when needed, and whether sequence numbers or timestamps are present when missed updates matter.
Work the failure case. A client connects to a vibration sensor and subscribes to a characteristic that sometimes emits a 64-byte sample. On a link using the common 23-byte ATT MTU, a notification value has only about 20 bytes available after the ATT opcode and handle overhead. The protocol review therefore needs one of three answers before release: negotiate a larger MTU and prove the fallback, split the sample into sequenced chunks, or reduce the characteristic value to a smaller summary. Without that evidence, “the phone connected” tells you almost nothing about whether the product data contract survives real payloads.
4.4.3 Beacon and Profile Boundaries
BLE advertising can broadcast small discovery or beacon payloads without a connection. GATT requires a connection and service discovery. Classic Bluetooth profiles and BLE GATT profiles solve different problems. A reviewable design states which boundary is being approved instead of mixing beacon, GATT, and Classic-profile claims.
The same separation helps with security evidence. GAP may show that the phone found and connected to the peripheral. ATT permissions decide whether a handle can be read or written on the current link. GATT gives that handle a product meaning. The application then checks ranges, stale values, and authorization rules before acting. A smart lock can pass discovery, pairing, and service discovery while still failing because the unlock write accepts a malformed payload. Preserving the layers lets the reviewer name the failing boundary instead of issuing a vague “BLE works” or “BLE fails” verdict.
4.4.4 Under-the-Hood Knowledge Check
4.5 BLE GATT Profile Workbench
4.6 Summary
BLE protocol review turns a working radio link into a product data contract. GATT services, characteristics, properties, descriptors, permissions, notification setup, payload sizing, and profile choices should all be tied to the actual product behavior and client evidence.
The strongest designs preserve layer boundaries. They distinguish discovery from connection, ATT operations from GATT meaning, notification capability from CCCD opt-in, security requirements from convenience, and application interpretation from raw bytes.
4.7 Key Takeaway
Approve a BLE GATT design only when the service model, characteristic contract, notification behavior, payload boundary, security rule, and client evidence match the IoT use case.
4.8 See Also
Review Classic, BLE, advertising, connection, GATT, security, power, and recovery fundamentals.
Choose the Bluetooth topology and role boundary before finalizing the GATT data model.
Use this when standard profile fit, custom UUID design, and interoperability evidence need more detail.
Review advertising, scanning, connection setup, pairing, bonding, parameters, and reconnect behavior.