Bluetooth & BLE · Study deck
BLE Protocol Stack and GATT
Picture a phone beside a heart-rate sensor.
Radio Remi is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: 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.
- Explain: 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.
- Explain: 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.
Major section
Start With the Story
Finding the device proves that it is nearby.
- The product still needs a shared data plan.
- Reads, changes, and commands each need clear rules.
- A service is a named collection for one job.
- A characteristic is one value or action inside that service.
Major section
Start With the Story (continued)
Under the Hood explains attribute handles, update behavior, message limits, and the state that a simple value list does not show.
- A descriptor adds facts about that value.
- One side advertises and accepts a connection.
- The other finds it and connects.
- Security checks must match each action.
Major section
Start With the Story (continued)
A visible value is not always a permitted value.
- Real products reconnect, share several services, and change over time.
- 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.
Major section
GATT Turns BLE Links Into Product Data
Bluetooth Low Energy separates the radio link from the data model.
- 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.
- A sensor, lock, beacon, gateway, and maintenance tool can all use BLE while needing different GATT evidence.
Major section
GATT Turns BLE Links Into Product Data (continued)
That one device is still "a BLE device," but its product contract lives in the GATT table, not in the radio label.
- 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.
- Worked example: a greenhouse node may expose three separate service areas.
- That same example also shows why profiles matter.
Major section
GATT Turns BLE Links Into Product Data (continued)
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 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.
- A room sensor can expose an environmental service with temperature and humidity characteristics, plus a battery service.
- If a standard service matches the meaning, a generic client can recognize it without private documentation.
Major section
Design a Reviewable GATT Record
A practical BLE protocol review records the data contract before implementation details take over.
- 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 client connects and discovers the characteristic, but no updates arrive.
Major section
The Stack Boundary Shapes the Data Contract
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.
Major section
The Stack Boundary Shapes the Data Contract (continued)
Payload size is a design boundary, not an afterthought.
- 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.
- BLE advertising can broadcast small discovery or beacon payloads without a connection.
Major section
The Stack Boundary Shapes the Data Contract (continued)
GATT requires a connection and service discovery.
- 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.
- The same separation helps with security evidence.
- GATT gives that handle a product meaning.
Major section
The Stack Boundary Shapes the Data Contract (continued)
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.
- 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.
Major section
The Stack Boundary Shapes the Data Contract (continued)
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.
- A reviewable design states which boundary is being approved instead of mixing beacon, GATT, and Classic-profile claims.
- 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.
- A smart lock can pass discovery, pairing, and service discovery while still failing because the unlock write accepts a malformed payload.
Deck summary
Key takeaways
Finding the device proves that it is nearby.
- Under the Hood explains attribute handles, update behavior, message limits, and the state that a simple value list does not show.
- A visible value is not always a permitted value.
- Bluetooth Low Energy separates the radio link from the data model.
- That one device is still "a BLE device," but its product contract lives in the GATT table, not in the radio label.
Retrieval practice
Recall check 1 of 3
Radio Remi says: answer from memory, then check your reasoning.
Q1What is the strongest beginner description of a BLE GATT characteristic?
Show answer
Answer: B A characteristic is the product-facing value or control inside a GATT service.
Retrieval practice
Recall check 2 of 3
Radio Remi says: answer from memory, then check your reasoning.
Q2A BLE peripheral exposes a temperature characteristic with the Notify property, but the phone receives no updates after connecting. What should the review check first?
Show answer
Answer: A The Notify property announces capability; the client still has to opt in through the CCCD.
Retrieval practice
Recall check 3 of 3
Radio Remi says: answer from memory, then check your reasoning.
Q3Why should a BLE protocol review separate GAP, ATT, GATT, security, and application evidence?
Show answer
Answer: C BLE readiness depends on several layered behaviors, not only a connection event.
Print reference
Answers
Answer key.
- B · A characteristic is the product-facing value or control inside a GATT service.
- A · The Notify property announces capability; the client still has to opt in through the CCCD.
- C · BLE readiness depends on several layered behaviors, not only a connection event.