A field-tested comparison of BLE GATT communication strategies
for ESP32-class devices and mobile apps
Throughput · Data efficiency · Reliability
Revision 1.0 · 18 July 2026 · Grounded in a production case study — the ZeroTrace / AirLeak ESP32 firmware (NimBLE)
| notify or indicate? | what MTU? | DLE? | 1M or 2M PHY? |
| JSON, CBOR, or Protobuf? | one characteristic or several? | how do you make notifications reliable? | how much will the phone let you have? |
"Use GATT" answers none of these. This paper does — with numbers.
There is a hierarchy of leverage, and most engineers spend effort in the wrong place:
| Rank | Lever | Impact | |
|---|---|---|---|
| 1 | Unacknowledged ops (notify / write-without-response) | ~4–12× | nothing else matters without this |
| 2 | Data Length Extension (27 → 251-byte PDU) | ~2.5–3.5× | the biggest near-free win |
| 3 | 2M PHY vs 1M PHY | ~1.8× | strong secondary, opportunistic |
| 4 | ATT MTU matched to DLE (~247) | ~0–15% | fine-tuning, client-initiated |
| 5 | Connection interval | ~1× | a latency/power knob, not throughput |
…and above all of it sits the mobile OS. A real ESP32 → phone link is capped at ~0.3–0.6 Mbps on iOS and up to ~1 Mbps on Android — far below the ~1.4 Mbps the radio can theoretically reach.
The defining skill of BLE engineering for phone links is designing to the phone's connection-parameter policy, not the radio's datasheet.
Figure 1 — the same peripheral, wildly different throughput. Blue = theoretical ceiling · teal = chip-to-chip · orange = real phone link.
Figure 2 — the levers are not equal. Pick unacknowledged transfers and DLE first.
|
Foundations
Core mechanics 4. GATT operations — notify / indicate / read / write / WNR 5. The four throughput levers (MTU · DLE · PHY · interval) 6. L2CAP Connection-Oriented Channels vs GATT 7. Serialization — JSON · CBOR · Protobuf · MessagePack 8. Fragmentation & framing over GATT |
Getting it right 9. Reliability over unacknowledged notifications 10. Head-of-line blocking & channel isolation 11. The mobile ceiling — iOS vs Android 12. Security · 13. Power · 14. BLE vs Wi-Fi / ESP-NOW / SPP 15. ESP32 family matrix · NimBLE vs Bluedroid Applied 16. Case study — the ZeroTrace / AirLeak transport 17. A decision framework · 18–19. Validity & conclusion 📎 Appendix A reference tables + verification results 📎 Appendix B the ESP32→phone tuning checklist |
The eight that overturn common assumptions
- Notifications aren't unreliable at the radio. Every BLE packet, including a notification, is link-layer acknowledged and retransmitted. What they lack is an ATT/application-layer confirmation — which is why the right move is to build reliability at the app layer (sequence numbers + gap detection + backfill), cheaper than paying ATT's per-packet acknowledgement tax.
- DLE gives ~2.5–3.5×, not ~9×. The payload grows 27→251 bytes, but the fixed 150 µs inter-frame space and empty ACK don't scale.
- The useful MTU target is 247, not 517 — the largest ATT payload that fits one DLE link-layer packet without fragmentation.
- "Shorter interval = faster" is backwards for notification streams. Throughput is maximised by packing more packets per connection event; the interval is a latency/power lever.
- CBOR beats JSON by ~15–30% on typical payloads (not the headline 80% — those come from dropping map keys). Its stronger edge is cheap, streaming, malloc-free decoding on MCUs.
- L2CAP CoC doesn't beat GATT by "eliminating ATT overhead" — at a large MTU that overhead is ~1%. CoC wins for bulk transfer via credit-based flow control + native segmentation.
- The classic ESP32 is a BLE 4.2 radio (no 2M/Coded PHY, despite "5.0 certification"); the S3/C3/C6/H2 are true BLE 5.x. NimBLE saves ~100–250 kB flash over Bluedroid with no throughput penalty.
- iOS reserves ~50% of the connection event for other radios and enforces a 15 ms minimum interval — roughly halving throughput vs Android before you even start.
Rather than argue in the abstract, the paper dissects the ZeroTrace / AirLeak firmware — an ESP32 wireless-recon tool that streams live capture data to a phone.
Its NimBLE transport independently converged on the paper's recommendations: a JSON-RPC control channel isolated from a NOTIFY-only CBOR stream, an application-layer sequence / gap / backfill reliability scheme over unacknowledged notifications, DLE 251 + 2M PHY + MTU 517 requested after the phone's handshake, and explicit congestion handling. Its production bugs — notification coalescing, TX backpressure truncation, host-task deadlock, congestion collapse — map one-to-one onto the pitfalls the literature documents.
That convergence is the paper's strongest claim: the recommended design isn't a preference, it's where the evidence points.
🔬 Methodology & honesty
249 sources were gathered by a fan-out of topic researchers, deduplicated by URL, and categorised:
| Peer-reviewed | Specs / standards | Vendor docs | Eng. articles | Forums / Q&A | GitHub issues | Books |
|---|---|---|---|---|---|---|
| 23 | 10 | 69 | 65 | 47 | 33 | 2 |
The fifteen load-bearing comparative claims were then handed to independent fact-checkers instructed to refute them; the verdicts (SUPPORTED / PARTIALLY-SUPPORTED / DISPUTED) are folded into the text and summarised in Appendix A. Section 18 ("Threats to validity") is candid about the limits: vendor bench numbers are ceilings not field values, the phone landscape moves, and cross-hardware experimental rigor in the literature is thin.
Released under CC BY 4.0 — share and adapt with attribution.
NetzSec / ZeroTrace Hardware Division. Bytes Off the Chip: A field-tested comparison of BLE GATT communication strategies for ESP32-class devices and mobile apps. Rev. 1.0, July 2026.
Product names (ESP32, iOS, Android, Nordic, etc.) belong to their respective owners.