La mayoría de los productos BLE Tag se envían como beacons solo-publicitarios: el teléfono los escanea, lee la carga útil y se aleja. Ese modelo falla en cuanto necesitas configurar la etiqueta, hacerla sonar, enviar firmware o leer sensores en búfer. Entonces necesitas una conexión GATT real, y la gestión de la conexión se vuelve lo difícil. Este artículo va más allá del marketing: emparejamiento, bonding, LE Secure Connections, diseño GATT, parámetros de conexión y los detalles de iOS/Android que realmente rompen los envíos.
Emparejamiento vs Bonding
El emparejamiento es el apretón de manos en vivo que genera la LTK. El bonding es emparejamiento más persistir esa LTK (e IRK/CSRK) en flash para reanudar cifrado sin reemparejar. Una etiqueta que empareja pero no hace bonding obliga a reemparejar cada vez que se cierra la app, lo cual es inaceptable para un localizador de consumo.
Legacy Pairing vs LE Secure Connections
Legacy Pairing (4.0 a 4.1) deriva la LTK de una clave temporal y es vulnerable a escucha pasiva: captura el intercambio una vez y obtienes la LTK. LE Secure Connections (4.2+) negocia primero ECDH P-256, así la LTK nunca sale al aire. Para cualquier etiqueta que transporte ubicación o identidad, Secure Connections es la única base aceptable.
| Característica | Legacy Pairing | LE Secure Connections |
|---|---|---|
| Acuerdo de clave | Temporary Key | ECDH P-256 |
| Escucha pasiva | LTK recuperable | Seguro |
| MITM (Numeric Comparison) | No | Sí |
| Versión mínima | 4.0 | 4.2 |
Modelos de asociación
El modelo de asociación decide cómo confirma el usuario el vínculo. Just Works es silencioso pero sin protección MITM, lo cual está bien para localizadores pero es arriesgado para cerraduras. Numeric Comparison (solo Secure Connections) muestra un código de 6 dígitos en ambos lados.
| Modelo | Acción usuario | MITM | Uso típico |
|---|---|---|---|
| Just Works | Ninguna | No | Localizadores, bajo valor |
| Passkey Entry | 6 dígitos | Sí | Config industrial |
| Numeric Comparison | Confirmar código | Sí | Etiquetas seguras |
| OOB | Tap/NFC | Sí | Aprovisionamiento |
Jerarquía de claves
Tras el emparejamiento la pila guarda: LTK (cifrado de enlace 128-bit), IRK (dirección privada resolvable), CSRK (escrituras firmadas autenticadas) y semillas ER/DHK. La IRK es lo que permite que un teléfono vinculado reconozca la etiqueta tras rotar su dirección.
Diseño del servicio GATT
Un GATT pragmático para localizador/rastreador:
| UUID | Servicio / Caract. | Propiedad |
|---|---|---|
| 0x180F | Battery Service | Read |
| 0x180A | Device Information | Read |
| 0x2A06 | Alert Level (Find Me) | Write |
| Fxxx | Config (intervalo, TX power) | Read/Write |
| Fxxx | Botón / último pulsado | Notify |
| Fxxx | Firmware revision | Read |
Deja la característica de configuración protegida tras bonding; si no, cualquiera en rango reescribe el TX power y anula los límites de alcance.
Parámetros de conexión
Tres valores gobiernan toda conexión:
- Connection Interval: 7.5 ms a 4000 ms. iOS limita el mínimo negociado a ~20 ms en la práctica.
- Slave Latency: 0 a 499 eventos que la etiqueta puede omitir.
- Supervision Timeout: 100 ms a 32000 ms; debe superar (1 + latency) x interval x 2.
Perfil de bajo consumo: interval 1000 ms, latency 9, timeout 11 s significa que la etiqueta omite 9 de cada 10 eventos, despertando cerca de una vez por segundo. La corriente media baja del rango mA (conectado, 30 ms) a decenas de uA.
Reconexión sin agotar la batería
Las etiquetas solo-publicitarias emiten una dirección estática o aleatoria; un teléfono vinculado no las encuentra fiablemente tras rotar la dirección. Usa una Resolvable Private Address generada desde la IRK, anuncia con White List habilitada y deja que el teléfono vinculado resuelva la RPA. El tamaño de White List en SoCs comunes es 8 a 32 entradas, suficiente para un teléfono y un par de gateways.
Detalles de iOS / Android que rompen envíos
- iOS: el escaneo en segundo plano de CoreBluetooth solo coincide con servicios cuyo UUID está en el anuncio. Si la etiqueta oculta el UUID, la app no despierta en segundo plano. Intervalos < ~20 ms se rechazan. ANCS requiere conexión vinculada para entregar alertas.
- Android 12+: BLUETOOTH_CONNECT y BLUETOOTH_SCAN son permisos en tiempo de ejecución; sin ellos el escaneo devuelve vacío. Hay que manejar el aviso «encontrar dispositivos cercanos» y la limitación de escaneo en segundo plano (~1/hora para apps en caché).
- Ambos: mantener la conexión continua quema el CR2032 en días. Conecta bajo demanda y desconecta.
Compensación de potencia
| Modo | Corriente típica | Vida CR2032 |
|---|---|---|
| Solo publicidad (200 ms) | ~5 a 15 uA | 1 a 3 años |
| Conectado, 30 ms | ráfagas 1 a 3 mA | días a semanas |
| Conectado bajo demanda | decenas de uA | 1 a 2 años |
Regla: por defecto solo publicidad; abre conexión solo para config, alerta u OTA, luego ciérrala.
Errores frecuentes
- Emparejar sin bonding conduce a un bucle de reemparejado en cada arranque.
- Legacy Pairing en etiqueta de ubicación filtra una LTK recuperable.
- Dirección aleatoria estática sin IRK implica que el teléfono vinculado no encuentra la etiqueta.
- Mantener la conexión «por si acaso» mata la batería.
- Ocultar el UUID del servicio en iOS bloquea el despertar en segundo plano.
Hacer bien la gestión de conexión es lo que separa una etiqueta de demostración de un producto que realmente puedes enviar. Para diseños de referencia que ya implementan Secure Connections y un GATT sensato, consulta nuestra línea de módulo Bluetooth y la más amplia familia BLE Tag.
