Advertising en BLE: qué es, formatos de paquetes y mecanismos de publicidad

Autor: IT Sectr Publicado: 2026-07-15 Tiempo de lectura: 11 min

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 es el mecanismo principal de detección de dispositivos BLE que opera en tres canales dedicados 37, 38 y 39.
  • El paquete publicitario estándar está limitado a 31 bytes de datos; extended advertising (BLE 5.0) aumenta el límite a 251 bytes.
  • Connectable advertising permite a Central conectarse al dispositivo; non-connectable es solo transmisión unidireccional (balizas).
  • El intervalo de publicidad afecta el consumo de energía: con un intervalo de 1000 ms, la corriente promedio es 10 veces menor que con 100 ms.
  • Scan response permite transmitir 31 bytes adicionales de datos en respuesta a una solicitud de Central.

¿Qué es Advertising en BLE?

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.

Canales publicitarios y su función

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%.

Tipos de paquetes publicitarios

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 PDUDescripciónConexiónScan response
ADV_INDPublicidad estándar
ADV_DIRECT_INDPublicidad a un Central específicoNo
ADV_NONCONN_INDSin conexión (balizas)NoNo
ADV_SCAN_INDCon soporte de scan
ADV_EXT_INDExtended advertising (BLE 5.0)

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.

Intervalo de publicidad y consumo de energía

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: datos adicionales

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 en BLE 5.0

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ámetroBLE estándarExtended BLE 5.0
Tamaño máx. de paquete31 bytes251 bytes
CanalesSolo 37, 38, 39+ secundarios 0–36
AlcanceHasta 100 mHasta 1000 m (coded PHY)
Velocidad1 Mbps125 kbps – 2 Mbps
PeriódicoNo

Configuración de publicidad en iOS y Android

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.

swift
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%.

java
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

¿Cuál es la diferencia entre connectable y non-connectable advertising?

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.

¿Cuántos bytes se pueden transmitir en un paquete publicitario?

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.

¿Qué intervalo de advertising elegir para un dispositivo IoT?

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.

¿Por qué BLE utiliza tres canales publicitarios?

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.

¿Cómo afecta el advertising a la duración de la batería?

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

  • Advertising es un mecanismo de detección de dispositivos BLE que opera en tres canales (37, 38, 39) con un tamaño de paquete de hasta 31 bytes.
  • Existen cinco tipos de PDU de advertising: ADV_IND, ADV_DIRECT_IND, ADV_NONCONN_IND, ADV_SCAN_IND y ADV_EXT_IND para BLE 5.0.
  • El intervalo de advertising varía de 20 ms a 10.24 s y afecta directamente la velocidad de detección y el consumo de energía del dispositivo.
  • Scan Response proporciona 31 bytes adicionales de datos bajo solicitud de Central sin aumentar el consumo de energía del Peripheral.
  • Extended Advertising (BLE 5.0) aumenta el paquete a 251 bytes y soporta un alcance de hasta 1 km mediante coded PHY.
  • En iOS, el advertising se gestiona mediante CBPeripheralManager; en Android, mediante BluetoothLeAdvertiser con configuraciones detalladas.
  • La elección correcta del intervalo de advertising y el tipo de paquete determina la eficiencia energética y la duración de la batería del dispositivo BLE.

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.

Discutir el proyecto

Lea también