Peripheral — qué es, rol en BLE y cómo anuncia servicios

¿Qué es un Peripheral en BLE?

Peripheral es un dispositivo BLE que implementa un servidor GATT y anuncia sus capacidades a través de canales advertising. A diferencia de un Central, que busca activamente dispositivos, un Peripheral espera pasivamente las conexiones. Este es un modelo asimétrico optimizado para la eficiencia energética de dispositivos alimentados por batería.

Peripheral puede estar en varios modos: advertising (publicidad), connected (conectado a un Central), sleeping (suspensión con publicidad desactivada). En modo advertising, el Peripheral envía periódicamente paquetes cortos de datos consumiendo energía mínima. Después de la conexión, el Peripheral pasa al modo connected, donde intercambia datos con el Central según el intervalo de conexión acordado.

Según Bluetooth Core Specification 5.4 (2023), un dispositivo puede cambiar dinámicamente entre los roles Peripheral y Central, pero en cada momento el rol es fijo para una sola conexión. Un escenario típico: un sensor IoT funciona constantemente como Peripheral, mientras que un teléfono inteligente gestiona la conexión como Central.

Es importante que los desarrolladores entiendan: el Peripheral determina qué servicios y características están disponibles y gestiona el acceso a ellos. La estructura del servidor GATT en el Peripheral determina qué datos puede leer el Central y qué comandos puede escribir.

Proceso de publicidad (Advertising)

Advertising es el mecanismo mediante el cual un Peripheral anuncia su presencia. El Peripheral envía paquetes advertising en tres canales dedicados (37, 38, 39) con un intervalo de 20 ms a 10.24 segundos. Cada paquete advertising contiene información fija y puede incluir datos opcionales.

Hay dos tipos de paquetes advertising: advertising PDU (paquete principal) y scan response PDU (respuesta a una solicitud del Central). El paquete principal contiene campos obligatorios: tipo de paquete, dirección del remitente, datos. Si un Central envía una solicitud de escaneo, el Peripheral responde con un paquete adicional que contiene información más completa, por ejemplo, el nombre completo del dispositivo.

Los parámetros de advertising afectan la velocidad de detección y el consumo de energía. Advertising interval es el tiempo entre transmisiones de paquetes. Cuanto más corto es el intervalo, más rápido el Central descubrirá el dispositivo, pero más energía consumirá el Peripheral. Intervalo recomendado: 100–1000 ms para la mayoría de dispositivos.

Estructura del paquete advertising

El paquete advertising BLE tiene un límite de 31 bytes para advertising PDU y 31 bytes adicionales para scan response. Dentro del paquete, los datos se organizan en formato AD Structure (Advertising Data Structure): cada campo tiene un tipo (1 byte), longitud (1 byte) y valor.

Los tipos AD más utilizados: Flags (0x01) — modos de conexión y detección, Local Name (0x08 o 0x09) — nombre del dispositivo, Service UUID List (0x02–0x07) — lista de UUIDs de servicios, Manufacturer Specific Data (0xFF) — datos del fabricante. Empaquetar correctamente los datos en un paquete de 31 bytes es una tarea importante para los desarrolladores de dispositivos integrados.

Para dispositivos que necesitan transmitir más datos, extended advertising (BLE 5.0+) aumenta el tamaño del paquete advertising a 251 bytes y agrega nuevos tipos de paquetes. Extended advertising también admite canales con PHY codificado para un alcance de hasta 1 km en áreas abiertas.

Al diseñar un paquete advertising, tenga en cuenta: cuantos más datos haya en el paquete, mayor será la probabilidad de colisión con otros dispositivos. Para una detección rápida, se recomienda colocar solo datos críticos (Service UUID) en el advertising PDU, y los datos adicionales en el scan response.

Peripheral como servidor GATT

Servidor GATT en el Peripheral contiene todos los servicios y características que un Central puede descubrir e interactuar. Después de la conexión, el Central descubre servicios, luego características, e interactúa con ellos a través del protocolo GATT.

Peripheral como servidor GATT debe manejar correctamente las solicitudes del Central: solicitudes de lectura, solicitudes de escritura, notificaciones e indicaciones. Cada solicitud pasa a través de la tabla GATT, donde cada atributo (servicio, característica, descriptor) corresponde a un Handle, una dirección de 16 bits.

El desarrollador de Peripheral define permisos de acceso para cada atributo: solo lectura, solo escritura, lectura y escritura, con o sin cifrado. Para datos confidenciales (información personal, indicadores médicos), se recomienda habilitar el cifrado a través de MITM Protection.

Peripheral en iOS: CBPeripheralManager

CBPeripheralManager es una clase de Core Bluetooth para implementar el rol Peripheral en iOS. Gestiona el servidor GATT, publica servicios y características, y maneja solicitudes de Centrals. A diferencia de CBCentralManager, CBPeripheralManager no escanea — solo anuncia y gestiona conexiones.

Los pasos principales para implementar un Peripheral en iOS: inicializar CBPeripheralManager, agregar servicios mediante add, iniciar publicidad mediante startAdvertising, manejar solicitudes de Centrals a través del delegado CBPeripheralManagerDelegate.

import CoreBluetooth

class BLEPeripheralManager: NSObject, CBPeripheralManagerDelegate {

    private var peripheralManager: CBPeripheralManager!

    func startAdvertising() {
        let advertisementData: [String: Any] = [
            CBAdvertisementDataLocalNameKey: "BLE Sensor",
            CBAdvertisementDataServiceUUIDsKey: [
                CBUUID("180F")
            ]
        ]
        peripheralManager.startAdvertising(advertisementData)
    }

    func peripheralManagerDidUpdateState(
        _ peripheral: CBPeripheralManager
    ) {
        if peripheral.state == .poweredOn {
            startAdvertising()
        }
    }
}

iOS permite que el Peripheral funcione en segundo plano con la clave bluetooth-peripheral en Background Modes. En segundo plano, iOS puede anunciarse con un conjunto limitado de datos y gestionar conexiones. Para publicidad prolongada (más de 180 segundos), use la opción CBAdvertisementDataWaitForResponseFromCentral para ahorrar energía.

Peripheral en Android: BluetoothLeAdvertiser

Android proporciona BluetoothLeAdvertiser para trabajar en el rol Peripheral (desde API 21). La API permite iniciar publicidad con parámetros configurables: potencia del transmisor, intervalo de publicidad, datos del paquete. Android también admite extended advertising (BLE 5.0) en dispositivos compatibles.

import android.bluetooth.le.*;

private BluetoothLeAdvertiser advertiser;

public void startPeripheral() {
    BluetoothAdapter adapter =
        BluetoothAdapter.getDefaultAdapter();
    advertiser = adapter.getBluetoothLeAdvertiser();

    AdvertiseData data = new AdvertiseData.Builder()
        .setIncludeDeviceName(true)
        .addServiceUuid(
            new ParcelUuid(
                UUID.fromString("0000180F-0000-1000-8000-00805F9B34FB")
            )
        )
        .build();

    AdvertiseSettings settings = new AdvertiseSettings.Builder()
        .setAdvertiseMode(AdvertiseSettings.ADVERTISE_MODE_LOW_POWER)
        .setTxPowerLevel(AdvertiseSettings.ADVERTISE_TX_POWER_MEDIUM)
        .build();

    advertiser.startAdvertising(
        settings, data, advertiseCallback
    );
}

En Android, la compatibilidad con Peripheral depende del fabricante y la versión del SO. No todos los dispositivos admiten BluetoothLeAdvertiser — verifique mediante adapter.isMultipleAdvertisementSupported(). A partir de Android 10, se requiere el permiso BLUETOOTH_ADVERTISE para el rol Peripheral, junto con una solicitud en tiempo de ejecución para aplicaciones con target SDK 31+.

Eficiencia energética de Peripheral

La eficiencia energética es una ventaja clave de BLE, y el Peripheral juega un papel principal en esto. Un dispositivo puede funcionar con una batería CR2032 (220 mAh) durante más de un año gracias al consumo de energía optimizado. La mayor parte del tiempo, el Peripheral permanece en modo de suspensión con la publicidad desactivada, despertándose solo para enviar un paquete advertising o procesar una solicitud de un Central.

Consumo de energía de Peripheral en diferentes modos: modo de suspensión (sueño profundo) — 1–5 µA, inactivo con temporizador activado — 10–50 µA, advertising — 5–15 mA (durante la transmisión del paquete), connected — 5–10 mA (durante el evento de conexión). Con un intervalo advertising de 1000 ms y una duración de paquete de 4 ms, la corriente promedio es de aproximadamente 50–100 µA.

Según Texas Instruments Application Report (SWRA478, 2024), optimizar el intervalo advertising de 100 ms a 1000 ms reduce el consumo promedio de energía en un 90%. Se logran ahorros adicionales mediante slave latency (saltar eventos de conexión), reducir Tx Power en distancias cortas y desactivar la publicidad después de la conexión (connectable advertising).