Most BLE Tag products ship as advertising-only beacons: the phone scans them, reads the payload, and walks away. That model breaks the moment you need to configure the tag, ring it, push a firmware update, or pull buffered sensor data. Then you need a real GATT connection, and connection management becomes the hard part. This article goes past the marketing and into pairing, bonding, LE Secure Connections, GATT layout, connection parameters, and the iOS/Android quirks that actually ship broken.
Pairing vs Bonding
Pairing is the live key-exchange handshake that produces an LTK. Bonding is pairing plus persisting that LTK (and IRK/CSRK) to flash so the next session resumes encrypted without re-pairing. A tag that only pairs but does not bond forces the user to re-pair every time the app is killed, which is unacceptable for a consumer finder.
Legacy Pairing vs LE Secure Connections
Legacy Pairing (Bluetooth 4.0 to 4.1) derives the LTK from a temporary key and is vulnerable to passive eavesdropping: capture the exchange once and you derive the LTK. LE Secure Connections (4.2+) runs an ECDH P-256 handshake first, so the LTK is never exposed on the air. For any tag that carries location or identity, Secure Connections is the only acceptable baseline.
| Feature | Legacy Pairing | LE Secure Connections |
|---|---|---|
| Key agreement | Temporary Key | ECDH P-256 |
| Passive eavesdrop | Recoverable LTK | Safe |
| MITM (Numeric Comparison) | No | Yes |
| Minimum version | 4.0 | 4.2 |
Association Models
The association model decides how the user confirms the link. Just Works is silent but gives no MITM protection, which is fine for a finder yet risky for a door lock. Numeric Comparison (Secure Connections only) shows a 6-digit code on both sides.
| Model | User action | MITM | Typical use |
|---|---|---|---|
| Just Works | None | No | Finders, low-value tags |
| Passkey Entry | Type 6 digits | Yes | Industrial config |
| Numeric Comparison | Confirm code | Yes | Secure tags |
| OOB | Tap/NFC | Yes | Provisioning |
Key Hierarchy
After pairing the stack stores: LTK (128-bit link encryption), IRK (resolvable private address generation), CSRK (authenticated signed writes), plus ER/DHK root seeds. The IRK is what lets a bonded phone recognize a tag after it rotates its address.
GATT Service Layout
A pragmatic finder/tracker GATT:
| UUID | Service / Char | Property |
|---|---|---|
| 0x180F | Battery Service | Read |
| 0x180A | Device Information | Read |
| 0x2A06 | Alert Level (Find Me) | Write |
| Fxxx | Config (interval, TX power) | Read/Write |
| Fxxx | Button / last-press | Notify |
| Fxxx | Firmware revision | Read |
Keep the config characteristic write-gated behind bonding; otherwise anyone in range reflashes TX power and defeats range limits.
Connection Parameters
Three values govern every connection:
- Connection Interval: 7.5 ms to 4000 ms. iOS clamps the negotiated minimum to roughly 20 ms in practice.
- Slave Latency: 0 to 499 events the tag may skip.
- Supervision Timeout: 100 ms to 32000 ms; must exceed (1 + latency) x interval x 2.
Low-power profile: interval 1000 ms, latency 9, timeout 11 s means the tag sleeps through 9 of 10 events, waking about once per second. Average current drops from the mA range (connected, 30 ms interval) to tens of uA.
Reconnection Without Draining the Battery
Advertising-only tags broadcast a static or random address; a bonded phone cannot reliably find them after address rotation. Use a Resolvable Private Address generated from the IRK, advertise with the White List enabled, and let the bonded phone resolve the RPA. White-list size on commodity SoCs is 8 to 32 entries, which is enough for a phone plus a couple of gateways.
iOS / Android Quirks That Break Shipments
- iOS: CoreBluetooth background scanning only matches services whose UUID is present in the advertisement. If your tag hides the service UUID, the app will not wake in background. Connection intervals below about 20 ms are rejected. ANCS requires a bonded connection to deliver alerts.
- Android 12+: BLUETOOTH_CONNECT and BLUETOOTH_SCAN are runtime permissions; scanning without them returns nothing. The “find nearby devices” system prompt must be handled, and background scan is throttled to about one scan per hour for cached apps.
- Both: a tag that holds a connection continuously burns the CR2032 in days. Connect on demand, then disconnect.
Power Trade-off
| Mode | Typical current | CR2032 life |
|---|---|---|
| Advertising only (200 ms) | ~5 to 15 uA | 1 to 3 yr |
| Connected, 30 ms interval | 1 to 3 mA bursts | days to weeks |
| Connected-on-demand | tens of uA avg | 1 to 2 yr |
The rule: stay advertising-only by default; open a connection only for config, alert, or OTA, then close it.
Pitfalls
- Pairing but not bonding leads to a re-pair loop on every app launch.
- Legacy Pairing on a location tag leaks a recoverable LTK.
- Static random address with no IRK means a bonded phone cannot find the tag.
- Holding a connection “just in case” kills the battery.
- Hiding the service UUID on iOS blocks background wake.
Getting connection management right is what separates a demo tag from a product you can actually ship. For reference designs that already implement Secure Connections and a sane GATT, see our Bluetooth module line and the broader BLE Tag family.
