Advertising (publicidad) es un mecanismo en Bluetooth Low Energy mediante el cual un dispositivo Peripheral anuncia su presencia transmitiendo paquetes cortos de datos en tres canales dedicados (37, 38, 39). La Bluetooth Core Specification 5.4 (2023) define dos tipos de publicidad: connectable — el dispositivo está listo para una conexión, y non-connectable — utilizado por balizas (Beacon) que solo transmiten datos sin establecer comunicación bidireccional. Los parámetros de publicidad — intervalo de 20 ms a 10.24 s, potencia del transmisor de -20 a +10 dBm y tipo de paquete — afectan directamente la velocidad de detección del dispositivo y su consumo de energía, lo que es crítico en el desarrollo de dispositivos IoT con alimentación por batería.
Puntos clave
Advertising (publicidad) es el proceso de transmisión periódica de paquetes cortos de datos mediante el cual un dispositivo BLE anuncia su presencia y disponibilidad. A diferencia del Bluetooth clásico, donde la detección de dispositivos toma segundos, el advertising BLE permite detectar un dispositivo en milisegundos consumiendo una energía mínima.
La arquitectura BLE divide los dispositivos en dos roles: Peripheral (anuncia) y Central (escanea). El Peripheral envía paquetes de advertising, mientras que el Central escanea el aire y decide si conectar. Este modelo asimétrico es una ventaja clave de BLE: el dispositivo anunciante gasta energía solo en enviar paquetes cortos, no en escuchar el aire constantemente.
El proceso de advertising consta de tres etapas: advertising event (envío del paquete en los tres canales), scan request/response (intercambio opcional con Central) y connection request (iniciación de conexión por Central). Cada etapa es gestionada por el Bluetooth Controller a nivel de Link Layer.
BLE utiliza 40 canales en la banda de 2.4 GHz, de los cuales 37 (2402 MHz), 38 (2426 MHz) y 39 (2480 MHz) están dedicados exclusivamente al advertising. Tres canales representan un compromiso entre fiabilidad de detección y capacidad de rendimiento: un canal puede estar ocupado por Wi-Fi u otras interferencias, pero el dispositivo será detectado en los otros dos.
El canal 37 está cerca del canal Wi-Fi 1, el canal 39 está cerca del canal Wi-Fi 6, y el canal 38 se encuentra entre ellos, en la zona de mínimas interferencias. La elección de tres canales garantiza que el dispositivo sea detectado incluso en entornos radioeléctricos densos — por ejemplo, en un centro comercial con docenas de puntos de acceso Wi-Fi.
El Peripheral envía el paquete de advertising secuencialmente en los tres canales — esto se denomina advertising event. El dispositivo central escanea un canal a la vez, cambiando entre ellos según un algoritmo implementado en el Bluetooth Controller. La probabilidad de detección dentro de un advertising event en ausencia de colisiones es cercana al 100%.
Bluetooth Core Specification define varios tipos de PDU de advertising (Protocol Data Unit), cada uno con su propósito. Los tipos principales son: ADV_IND (connectable undirected advertising) — publicidad estándar con posibilidad de conexión, ADV_NONCONN_IND (non-connectable undirected advertising) — solo publicidad sin conexión, ADV_SCAN_IND (scannable undirected advertising) — soporta scan request, ADV_DIRECT_IND (directed advertising) — publicidad para un Central específico.
ADV_IND es el tipo más común utilizado en la mayoría de dispositivos BLE. Al recibir ADV_IND, el Central puede enviar un connection request y establecer una conexión. ADV_NONCONN_IND se utiliza en balizas (Beacon): el dispositivo anuncia pero no acepta solicitudes de conexión — solo transmisión unidireccional de datos.
| Tipo PDU | Descripción | Conexión | Scan response |
|---|---|---|---|
| ADV_IND | Publicidad estándar | Sí | Sí |
| ADV_DIRECT_IND | Publicidad a un Central específico | Sí | No |
| ADV_NONCONN_IND | Sin conexión (balizas) | No | No |
| ADV_SCAN_IND | Con soporte de scan | Sí | Sí |
| ADV_EXT_IND | Extended advertising (BLE 5.0) | Sí | Sí |
ADV_DIRECT_IND contiene la dirección del Central objetivo, lo que permite establecer una conexión rápidamente sin esperar el escaneo. Se utiliza cuando los dispositivos ya se “conoce” — por ejemplo, después de reconectar con un teléfono inteligente previamente emparejado. Este tipo reduce el consumo de energía ya que no requiere publicidad en todos los canales.
Advertising interval es el tiempo entre advertising events sucesivos. La especificación permite un intervalo de 20 ms a 10.24 s con un paso de 0.625 ms. El intervalo real se calcula como la suma de un valor fijo y un retardo aleatorio (0–10 ms), lo que reduce la probabilidad de colisiones entre múltiples dispositivos que anuncian.
Elegir el intervalo es un equilibrio entre velocidad de detección y consumo de energía. Con un intervalo de 20 ms, el dispositivo se detectará en 20–30 ms, pero la corriente promedio será de aproximadamente 1–2 mA. Con un intervalo de 1000 ms, la detección tomará hasta 1 segundo, pero la corriente promedio bajará a 50–100 µA. Para la mayoría de dispositivos IoT, el intervalo recomendado es 200–1000 ms.
Según Texas Instruments Application Report SWRA478 (2024), aumentar el intervalo de advertising de 100 ms a 1000 ms reduce el consumo de energía en un 90%. Si el dispositivo no requiere detección instantánea (por ejemplo, un sensor de temperatura que transmite datos una vez por minuto), el intervalo óptimo es 1000–2000 ms.
Un parámetro adicional es advertising timeout — el tiempo máximo durante el cual el dispositivo anuncia. En iOS, el Peripheral desactiva automáticamente la publicidad después de 180 segundos en segundo plano. En Android no existe tal limitación, pero los fabricantes pueden añadir sus propios límites.
Scan Response es un paquete de datos adicional (hasta 31 bytes) que el Peripheral envía en respuesta a una solicitud de scan del Central. La solicitud de scan es enviada por el Central después de recibir el paquete de advertising si necesita más información antes de conectar. Scan Response no requiere advertising adicional — se envía solo bajo petición, ahorrando espacio en el aire.
Distribución típica de datos: el advertising PDU (31 bytes) contiene banderas (3 bytes), UUID de servicios (2–16 bytes) y datos del fabricante (bytes restantes). El scan response transporta el nombre completo del dispositivo (hasta 28 bytes) y UUID adicionales o TX Power Level. Esta separación permite al Central filtrar rápidamente dispositivos por UUID sin leer el scan response.
Al diseñar el paquete de advertising, tenga en cuenta: si los 31 bytes están ocupados en el advertising PDU, el Central no podrá determinar si el dispositivo soporta scan response. Se recomienda dejar al menos 3–5 bytes libres en el advertising PDU para indicar la capacidad de scan response.
Extended Advertising (BLE 5.0) es una extensión del mecanismo de publicidad que aumenta el tamaño del paquete de advertising de 31 a 251 bytes y añade nuevos tipos de paquetes. Extended Advertising también soporta coded PHY para extender el alcance de comunicación hasta 1 km en áreas abiertas y publicidad periódica (Periodic Advertising) para sincronizar múltiples Centrales.
Principales innovaciones: ADV_EXT_IND — PDU de advertising extendido que puede transmitir hasta 251 bytes de datos en un solo paquete. Extended Advertising utiliza los canales primarios (37, 38, 39) solo para indicar en qué canal secundario (0–36) se transmiten los datos completos. Esto reduce la carga en los canales de publicidad y aumenta el rendimiento general del sistema.
Periodic Advertising es un mecanismo adicional en el que el Peripheral envía datos en canales secundarios con un intervalo fijo, y el Central puede sincronizarse con esta secuencia. Se utiliza para servicios que requieren actualizaciones regulares de datos — por ejemplo, transmisión de audio o lecturas de sensores en tiempo real.
| Parámetro | BLE estándar | Extended BLE 5.0 |
|---|---|---|
| Tamaño máx. de paquete | 31 bytes | 251 bytes |
| Canales | Solo 37, 38, 39 | + secundarios 0–36 |
| Alcance | Hasta 100 m | Hasta 1000 m (coded PHY) |
| Velocidad | 1 Mbps | 125 kbps – 2 Mbps |
| Periódico | No | Sí |
iOS (Core Bluetooth) proporciona CBPeripheralManager para gestionar la publicidad. Los parámetros de advertising se establecen mediante el diccionario advertisementData con las claves CBAdvertisementDataLocalNameKey (nombre del dispositivo), CBAdvertisementDataServiceUUIDsKey (UUID de servicios), CBAdvertisementDataTxPowerLevelKey (potencia). iOS gestiona automáticamente el intervalo de advertising y no permite configurarlo manualmente.
import CoreBluetooth
class AdvertiserManager: NSObject, CBPeripheralManagerDelegate {
private var peripheralManager: CBPeripheralManager!
func startBLEAdvertising() {
let data: [String: Any] = [
CBAdvertisementDataLocalNameKey: "BLE Beacon",
CBAdvertisementDataServiceUUIDsKey: [
CBUUID("180F")
],
CBAdvertisementDataIsConnectable: true
]
peripheralManager.startAdvertising(data)
}
}
Android (BluetoothLeAdvertiser) proporciona un control más detallado. Están disponibles: AdvertiseSettings — configuración de modo (LOW_POWER, BALANCED, LOW_LATENCY), potencia del transmisor e intervalo; AdvertiseData — datos del paquete. Android soporta extended advertising (BLE 5.0) en dispositivos compatibles, pero la proporción de estos dispositivos en el mercado es de aproximadamente 30–40%.
BluetoothLeAdvertiser advertiser =
BluetoothAdapter.getDefaultAdapter()
.getBluetoothLeAdvertiser();
AdvertiseSettings settings = new AdvertiseSettings.Builder()
.setAdvertiseMode(
AdvertiseSettings.ADVERTISE_MODE_LOW_POWER
)
.setTxPowerLevel(
AdvertiseSettings.ADVERTISE_TX_POWER_MEDIUM
)
.build();
AdvertiseData data = new AdvertiseData.Builder()
.setIncludeDeviceName(true)
.addServiceUuid(new ParcelUuid(
UUID.fromString(
"0000180F-0000-1000-8000-00805F9B34FB"
)
))
.build();
advertiser.startAdvertising(
settings, data, advertiseCallback
);
Al desarrollar una aplicación BLE multiplataforma, considere las diferencias: iOS no permite controlar el intervalo de advertising directamente pero garantiza un funcionamiento estable en todos los dispositivos; Android proporciona control total, pero la fragmentación de versiones y fabricantes puede provocar incompatibilidad. Se recomienda probar el advertising en dispositivos reales de ambas plataformas.
Preguntas frecuentes
Connectable advertising (ADV_IND) permite al Central establecer una conexión bidireccional con el dispositivo. Non-connectable (ADV_NONCONN_IND) es solo transmisión unidireccional de datos, utilizado por balizas (Beacon) para transmitir un identificador sin posibilidad de conexión.
El paquete publicitario estándar es de 31 bytes, scan response son otros 31 bytes. Extended Advertising (BLE 5.0+) aumenta el límite a 251 bytes mediante el uso de canales secundarios para la transmisión de datos.
Para la mayoría de dispositivos IoT, se recomienda 500–1000 ms. Si se requiere detección rápida (por ejemplo, para conectar auriculares), use 20–50 ms. Para sensores con transmisión de datos poco frecuente, 1000–2000 ms para ahorrar energía.
Tres canales (37, 38, 39) representan un compromiso entre fiabilidad de detección y capacidad de rendimiento. Un canal puede estar ocupado por Wi-Fi, pero el dispositivo será detectado en los otros dos. El canal 38 se encuentra en la zona de mínimas interferencias entre los canales Wi-Fi.
El advertising es el principal consumidor de energía en BLE. Con un intervalo de 1000 ms, la corriente promedio es de 50–100 µA, lo que permite que el dispositivo funcione durante un año con una batería CR2032. Con un intervalo de 20 ms, la corriente aumenta a 1–2 mA, reduciendo el tiempo de funcionamiento a varias semanas.
Resumen
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