Advertising Data en BLE: qué es, estructura y tipos de datos
Advertising Data son datos estructurados que un dispositivo BLE transmite en paquetes publicitarios para identificarse a sí mismo y sus servicios. La Bluetooth Core Specification 5.4 (2023) define el formato AD Structure: cada elemento contiene una longitud (1 byte), un tipo (1 byte) y un valor (hasta 29 bytes). La especificación describe más de 30 tipos AD, desde Flags y Local Name hasta Service UUID y Manufacturer Specific Data. El empaquetado correcto de advertising data es crítico para la compatibilidad del dispositivo con iOS, Android y otras plataformas, y también determina la velocidad de descubrimiento y la eficiencia energética de la publicidad.
Puntos Clave
- AD Structure es el formato de datos en un paquete publicitario BLE: longitud (1 byte), tipo (1 byte), valor (hasta 29 bytes).
- El paquete publicitario está limitado a 31 bytes; scan response proporciona otros 31 bytes para datos adicionales.
- Flags (0x01) es un tipo AD obligatorio que define los modos LE Limited Discoverable y BR/EDR Not Supported.
- Service UUID se transmite en formato abreviado (2 bytes) o completo (16 bytes).
- Manufacturer Specific Data (0xFF) es un tipo flexible para cualquier dato personalizado del fabricante.
¿Qué es Advertising Data?
Advertising Data es un conjunto estructurado de campos que un dispositivo BLE transmite en paquetes publicitarios para identificarse y describir sus capacidades. El Central, escaneando el aire, lee estos datos y decide si conectarse al dispositivo, ignorarlo o solicitar información adicional a través de Scan Response.
Los datos se organizan según el principio TLV (Type-Length-Value): cada elemento AD consta de tres campos. Length (1 byte) es la longitud de Value + Type (es decir, la longitud total del elemento menos 1 byte de Length). Type (1 byte) es el identificador del tipo de datos de Bluetooth Assigned Numbers. Value (N bytes) es el contenido según el tipo.
Un paquete publicitario estándar puede contener hasta 31 bytes de datos AD. Si esto no es suficiente, se utiliza Scan Response (otros 31 bytes) o Extended Advertising (BLE 5.0, hasta 251 bytes). Los primeros bytes del paquete publicitario están reservados para el encabezado PDU y la dirección del dispositivo; la carga útil AD comienza en un desplazamiento.
Formato AD Structure
Cada elemento AD en el paquete publicitario comienza con el campo Length (1 byte). El valor Length indica la cantidad de bytes que siguen después de Length, es decir, Type + Value. Por ejemplo, un elemento con Length=3 significa que después de Length hay 1 byte de Type y 2 bytes de Value. El paquete finaliza cuando la suma de las longitudes de todos los elementos alcanza el tamaño de los datos publicitarios.
| Campo | Tamaño | Descripción |
|---|---|---|
| Length | 1 byte | Longitud de Type + Value (excluyendo Length) |
| Type (AD Type) | 1 byte | Identificador del tipo de datos de Bluetooth SIG |
| Value | 0–29 bytes | Datos del tipo especificado |
El analizador Central lee la secuencia de elementos AD comenzando desde el primer byte después del encabezado. Si Length=0, el elemento se ignora y el analizador pasa al siguiente byte. Tipos AD duplicados (múltiples elementos con el mismo Type en un paquete) están permitidos, pero el Central puede procesar solo el primero o el último según la implementación de la pila.
Una regla importante: la suma de todos los Length(+1) en el paquete no debe exceder el tamaño de los datos publicitarios (31 bytes para advertising PDU). Si los datos no caben, se deben establecer prioridades: qué tipos AD son críticos para el descubrimiento inicial y cuáles se pueden mover a Scan Response.
Flags (0x01): Tipo AD Obligatorio
Flags (AD Type 0x01) es un elemento obligatorio en el paquete publicitario de cualquier dispositivo BLE. Ocupa 3 bytes: Length (0x02), Type (0x01), Value (1 byte de banderas de bits). Las banderas definen los modos de descubrimiento y las capacidades del dispositivo. La Core Specification recomienda incluir Flags en cada paquete publicitario.
Principales banderas: LE Limited Discoverable Mode (bit 0) — el dispositivo es detectable por tiempo limitado, LE General Discoverable Mode (bit 1) — el dispositivo siempre es detectable, BR/EDR Not Supported (bit 2) — el dispositivo solo soporta LE, Simultaneous LE and BR/EDR (bit 3) — soporta ambos modos. Para dispositivos puramente BLE, la combinación LE General Discoverable + BR/EDR Not Supported es obligatoria.
Un valor incorrecto de Flags es una de las causas comunes por las que un dispositivo no se detecta en iOS o Android. Por ejemplo, si la bandera BR/EDR Not Supported no está establecida, iOS puede intentar conectarse a través de Bluetooth clásico en lugar de BLE. Verifique el valor de Flags al depurar el paquete publicitario con un analizador Bluetooth (nRF Connect, Wireshark).
Local Name: Nombre del Dispositivo
Local Name (AD Type 0x08 o 0x09) es el nombre visible del dispositivo BLE. El tipo 0x08 (Shortened Local Name) es un nombre abreviado, utilizado cuando el nombre completo no cabe en el paquete publicitario. El tipo 0x09 (Complete Local Name) es el nombre completo del dispositivo. La longitud máxima del nombre es de 248 bytes, pero en un paquete publicitario estándar no hay disponibles más de 28 bytes.
Si el nombre del dispositivo excede el espacio disponible en el paquete publicitario, se recomienda: colocar el nombre abreviado en el advertising PDU (tipo 0x08) y el nombre completo en el Scan Response (tipo 0x09). iOS muestra el nombre del paquete publicitario durante el escaneo, mientras que el nombre completo está disponible después de la conexión o Scan Response.
Al elegir un nombre de dispositivo, tenga en cuenta: un nombre demasiado largo ocupa espacio que podría usarse para Service UUID u otros datos importantes. La longitud de nombre recomendada es de 8 a 16 caracteres. Evite caracteres no estándar y espacios: algunas pilas BLE pueden manejarlos incorrectamente.
Service UUID: Identificación de Servicios
Service UUID (AD Type 0x02–0x07) es uno de los tipos AD más importantes, ya que permite al Central determinar qué servicios proporciona el dispositivo sin conectarse a él. Bluetooth SIG define varios formatos de transmisión de UUID según el tamaño: 0x02 (Incomplete 16-bit), 0x03 (Complete 16-bit), 0x04 (Incomplete 32-bit), 0x05 (Complete 32-bit), 0x06 (Incomplete 128-bit), 0x07 (Complete 128-bit).
UUID de 16 bits (2 bytes) para servicios estándar de Bluetooth SIG, por ejemplo 0x180F (Battery Service), 0x180A (Device Information). UUID de 128 bits (16 bytes) para servicios personalizados definidos por el desarrollador. Un UUID de 16 bits ocupa solo 4 bytes en AD (Length + Type + 2 bytes UUID), mientras que uno de 128 bits ocupa 18 bytes. Si se deben transmitir varios UUID personalizados en un solo paquete, es posible que no quepan en 31 bytes.
Se recomienda usar el tipo Incomplete (0x02/0x04/0x06) si no se transmiten todos los UUID del dispositivo, solo los más importantes para el filtrado. La lista completa de UUID se transmite a través de Scan Response o GATT Discovery después de la conexión. Esto ahorra espacio en el paquete publicitario para otros tipos AD.
Manufacturer Specific Data
Manufacturer Specific Data (AD Type 0xFF) es el tipo AD más flexible, diseñado para transmitir datos personalizados del fabricante. Los primeros 2 bytes de Value son el Company Identifier Code asignado por Bluetooth SIG (por ejemplo, 0x004C para Apple, 0x0075 para Samsung). Los bytes restantes son datos arbitrarios en un formato definido por el fabricante.
Apple utiliza Manufacturer Data para iBeacon: Company ID (0x004C), tipo Beacon (0x0215), UUID (16 bytes), Major (2 bytes), Minor (2 bytes), TX Power (1 byte). Google usa un formato similar para Eddystone. Los fabricantes de dispositivos IoT suelen colocar lecturas de sensores o estado del dispositivo en Manufacturer Data.
js
// Parse Manufacturer Specific Data on Central
function parseManufacturerData(data) {
const view = new DataView(data.buffer);
// Company Identifier Code (first 2 bytes)
const companyId = view.getUint16(0, true);
// Check for Apple iBeacon
if (companyId === 0x004C) {
return parseIBeacon(view);
}
return null;
}Al usar Manufacturer Data, es importante respetar la limitación de tamaño: 31 bytes para todo el paquete publicitario menos los tipos AD obligatorios. Para Apple iBeacon, todo el paquete ocupa 30 bytes, dejando espacio solo para Flags (3 bytes). Para Eddystone, hasta 31 bytes. Los formatos personalizados compactos pueden incluir temperatura, humedad o presión en 4 a 8 bytes.
Estrategia de Empaquetado de Datos
El empaquetado correcto de advertising data es el arte de colocar la máxima información útil en el espacio limitado de 31 bytes. La estrategia depende del propósito del dispositivo: un beacon necesita un identificador, un sensor IoT necesita lecturas, un rastreador de fitness necesita un nombre y UUID de servicios. El principio general: cuanto más rápido deba tomar una decisión el Central, más críticos deben ser los datos en el advertising PDU.
Estrategia recomendada: advertising PDU (primeros 31 bytes) — Flags (3 bytes) + un Service UUID de 16 bits (4 bytes) + nombre abreviado (hasta 12 caracteres = 14 bytes) + Manufacturer Data (hasta 10 bytes). Scan Response (segundos 31 bytes) — nombre completo (resto) + UUID de servicio adicionales + TX Power Level (3 bytes). Esta distribución permite al Central filtrar rápidamente los dispositivos por UUID.
| Prioridad | Tipo AD | Tamaño | Colocar en |
|---|---|---|---|
| 1 (obligatorio) | Flags (0x01) | 3 bytes | Advertising PDU |
| 2 (filtrado) | Service UUID (0x02–0x03) | 4+ bytes | Advertising PDU |
| 3 (identificación) | Local Name (0x08–0x09) | 2+ bytes | Advertising PDU (abreviado) |
| 4 (adicional) | TX Power Level (0x0A) | 3 bytes | Scan Response |
| 5 (personalizado) | Manufacturer Data (0xFF) | 4+ bytes | Advertising PDU / Scan Response |
| 6 (datos completos) | UUID restantes | Según tamaño | Scan Response |
La depuración de advertising data es una etapa obligatoria en el desarrollo de dispositivos BLE. Use nRF Connect (Nordic Semiconductor) o Wireshark con un analizador Bluetooth para ver los datos sin procesar del paquete. Verifique que todos los tipos AD tengan un Length correcto, que la suma de longitudes no exceda 31 bytes y que Flags estén configurados correctamente para su caso de uso.
Preguntas Frecuentes
¿Qué sucede si la suma de elementos AD supera los 31 bytes?
La pila del Bluetooth Controller descartará los datos que excedan el límite o no enviará el paquete. Verifique la longitud total de los elementos AD al ensamblar el paquete publicitario. Si los datos no caben, traslade una parte a Scan Response o use Extended Advertising (BLE 5.0) con un límite de 251 bytes.
¿Se pueden transmitir lecturas de sensores en un paquete publicitario?
Sí, a través de Manufacturer Specific Data (0xFF). Empaquete las lecturas en 4–8 bytes: por ejemplo, temperatura (2 bytes en formato de punto fijo), humedad (2 bytes), voltaje de batería (2 bytes). Este enfoque permite al Central leer datos sin conectarse, ahorrando energía.
¿Qué tipo AD debo usar para servicios personalizados?
Para servicios personalizados, use UUID de 128 bits (AD Type 0x06–0x07). Si el UUID no cabe en el advertising PDU (16 bytes por UUID), muévalo a Scan Response o use el formato abreviado Incomplete (0x06) para especificar solo el primero o los dos primeros UUID.
¿Cuál es la diferencia entre los tipos Complete e Incomplete de Service UUID?
Complete — en el paquete se enumeran todos los UUID de servicio del dispositivo. Incomplete — solo una parte de los UUID (generalmente los más importantes). El Central no puede confiar en Incomplete como una lista completa, pero lo usa para un filtrado rápido. La lista completa está disponible después de GATT Discovery.
¿Por qué iOS no ve mi dispositivo BLE?
Una causa común es un Flags (0x01) incorrecto. Asegúrese de que el bit BR/EDR Not Supported esté establecido. La segunda causa es la ausencia de Service UUID en el paquete publicitario (iOS filtra por UUID). La tercera es que el dispositivo anuncie con muy poca frecuencia (iOS espera un intervalo de no más de 1000 ms).
Resumen
- Advertising Data son datos estructurados en formato AD Structure (Length-Type-Value), transmitidos en paquetes publicitarios BLE.
- Un paquete publicitario estándar contiene hasta 31 bytes de datos; Scan Response proporciona otros 31 bytes para información adicional.
- Flags (0x01) es un tipo AD obligatorio que define los modos de descubrimiento. BR/EDR Not Supported es obligatorio para dispositivos BLE.
- Service UUID se transmite en formato de 16 bits (2 bytes) o 128 bits (16 bytes), Complete o Incomplete según el espacio disponible.
- Manufacturer Specific Data (0xFF) es un tipo flexible para datos personalizados, utilizado en balizas iBeacon, Eddystone y dispositivos IoT.
- Estrategia de empaquetado: tipos AD obligatorios (Flags, Service UUID, nombre abreviado) en advertising PDU; los adicionales en Scan Response.
- Depure advertising data usando nRF Connect o Wireshark, una etapa obligatoria de desarrollo para verificar la estructura AD correcta.
Desarrollaremos una aplicación móvil llave en mano
IT Sectr crea aplicaciones para iOS y Android para startups y empresas desde 2017. Le asesoraremos y le propondremos la mejor solución.
Lea también