Peripheral — o que é, papel no BLE e como anuncia serviços

O que é um Peripheral em BLE?

Peripheral é um dispositivo BLE que implementa um servidor GATT e anuncia suas capacidades através de canais advertising. Ao contrário de um Central, que busca ativamente dispositivos, um Peripheral aguarda passivamente conexões. Este é um modelo assimétrico otimizado para eficiência energética de dispositivos alimentados por bateria.

Peripheral pode estar em vários modos: advertising (publicidade), connected (conectado a um Central), sleeping (suspenso com publicidade desativada). No modo advertising, o Peripheral envia periodicamente pacotes curtos de dados consumindo energia mínima. Após a conexão, o Peripheral entra no modo connected, onde troca dados com o Central de acordo com o intervalo de conexão acordado.

De acordo com Bluetooth Core Specification 5.4 (2023), um dispositivo pode alternar dinamicamente entre os papéis Peripheral e Central, mas em cada momento o papel é fixo para uma única conexão. Um cenário típico: um sensor IoT funciona constantemente como Peripheral, enquanto um smartphone gerencia a conexão como Central.

É importante que os desenvolvedores entendam: o Peripheral determina quais serviços e características estão disponíveis e gerencia o acesso a eles. A estrutura do servidor GATT no Peripheral determina quais dados o Central pode ler e quais comandos pode escrever.

Processo de publicidade (Advertising)

Advertising é o mecanismo pelo qual um Peripheral anuncia sua presença. O Peripheral envia pacotes advertising em três canais dedicados (37, 38, 39) com um intervalo de 20 ms a 10.24 segundos. Cada pacote advertising contém informações fixas e pode incluir dados opcionais.

Existem dois tipos de pacotes advertising: advertising PDU (pacote principal) e scan response PDU (resposta a uma solicitação do Central). O pacote principal contém campos obrigatórios: tipo de pacote, endereço do remetente, dados. Se um Central enviar uma solicitação de scan, o Peripheral responde com um pacote adicional contendo informações mais completas — por exemplo, o nome completo do dispositivo.

Os parâmetros de advertising afetam a velocidade de descoberta e o consumo de energia. Advertising interval é o tempo entre transmissões de pacotes. Quanto menor o intervalo, mais rápido o Central descobrirá o dispositivo, mas mais energia o Peripheral consumirá. Intervalo recomendado: 100–1000 ms para a maioria dos dispositivos.

Estrutura do pacote advertising

O pacote advertising BLE tem um limite de 31 bytes para advertising PDU e mais 31 bytes para scan response. Dentro do pacote, os dados são organizados no formato AD Structure (Advertising Data Structure): cada campo tem um tipo (1 byte), comprimento (1 byte) e valor.

Os tipos AD mais usados: Flags (0x01) — modos de conexão e descoberta, Local Name (0x08 ou 0x09) — nome do dispositivo, Service UUID List (0x02–0x07) — lista de UUIDs de serviços, Manufacturer Specific Data (0xFF) — dados do fabricante. Empacotar corretamente os dados em um pacote de 31 bytes é uma tarefa importante para desenvolvedores de dispositivos embarcados.

Para dispositivos que precisam transmitir mais dados, extended advertising (BLE 5.0+) aumenta o tamanho do pacote advertising para 251 bytes e adiciona novos tipos de pacotes. Extended advertising também suporta canais PHY codificados para alcance de até 1 km em áreas abertas.

Ao projetar um pacote advertising, lembre-se: quanto mais dados no pacote advertising, maior a probabilidade de colisão com outros dispositivos. Para descoberta rápida, recomenda-se colocar apenas dados críticos (Service UUID) no advertising PDU e dados adicionais no scan response.

Peripheral como servidor GATT

Servidor GATT no Peripheral contém todos os serviços e características que um Central pode descobrir e com os quais pode interagir. Após a conexão, o Central descobre serviços, depois características, e interage com eles através do protocolo GATT.

Peripheral como servidor GATT deve tratar corretamente as solicitações do Central: solicitações de leitura, solicitações de escrita, notificações e indicações. Cada solicitação passa pela tabela GATT, onde cada atributo (serviço, característica, descritor) corresponde a um Handle — um endereço de 16 bits.

O desenvolvedor do Peripheral define permissões de acesso para cada atributo: somente leitura, somente escrita, leitura e escrita, com ou sem criptografia. Para dados confidenciais (informações pessoais, indicadores médicos), recomenda-se habilitar a criptografia através de MITM Protection.

Peripheral em iOS: CBPeripheralManager

CBPeripheralManager é uma classe Core Bluetooth para implementar o papel Peripheral no iOS. Ele gerencia o servidor GATT, publica serviços e características, e trata solicitações de Centrals. Ao contrário do CBCentralManager, o CBPeripheralManager não escaneia — ele apenas anuncia e gerencia conexões.

As principais etapas para implementar um Peripheral no iOS: inicializar CBPeripheralManager, adicionar serviços via add, iniciar publicidade via startAdvertising, tratar solicitações de Centrals através do delegate 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()
        }
    }
}

O iOS permite que o Peripheral funcione em segundo plano com a chave bluetooth-peripheral em Background Modes. Em segundo plano, o iOS pode anunciar com um conjunto limitado de dados e gerenciar conexões. Para publicidade prolongada (mais de 180 segundos), use a opção CBAdvertisementDataWaitForResponseFromCentral para economizar energia.

Peripheral em Android: BluetoothLeAdvertiser

Android fornece BluetoothLeAdvertiser para trabalhar no papel Peripheral (a partir da API 21). A API permite iniciar publicidade com parâmetros configuráveis: potência do transmissor, intervalo de publicidade, dados do pacote. O Android também suporta extended advertising (BLE 5.0) em dispositivos compatíveis.

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
    );
}

No Android, o suporte a Peripheral depende do fabricante e versão do SO. Nem todos os dispositivos suportam BluetoothLeAdvertiser — verifique através de adapter.isMultipleAdvertisementSupported(). A partir do Android 10, é necessária a permissão BLUETOOTH_ADVERTISE para o papel Peripheral, juntamente com uma solicitação em tempo de execução para aplicativos com target SDK 31+.

Eficiência energética do Peripheral

A eficiência energética é uma vantagem chave do BLE, e o Peripheral desempenha um papel principal nisso. Um dispositivo pode funcionar com uma bateria CR2032 (220 mAh) por mais de um ano graças ao consumo otimizado de energia. A maior parte do tempo, o Peripheral permanece em modo de suspensão com publicidade desativada, acordando apenas para enviar um pacote advertising ou processar uma solicitação de um Central.

Consumo de energia do Peripheral em diferentes modos: modo de suspensão (sono profundo) — 1–5 µA, ocioso com temporizador ativado — 10–50 µA, advertising — 5–15 mA (durante a transmissão do pacote), connected — 5–10 mA (durante o evento de conexão). Com intervalo advertising de 1000 ms e duração de pacote de 4 ms, a corrente média é de cerca de 50–100 µA.

De acordo com Texas Instruments Application Report (SWRA478, 2024), otimizar o intervalo advertising de 100 ms para 1000 ms reduz o consumo médio de energia em 90%. Economias adicionais são obtidas através de slave latency (pular eventos de conexão), reduzir Tx Power em distâncias curtas e desativar a publicidade após a conexão (connectable advertising).