Advertising Data em BLE: o que é, estrutura e tipos de dados
Advertising Data são dados estruturados que um dispositivo BLE transmite em pacotes de publicidade para se identificar e identificar seus serviços. A Bluetooth Core Specification 5.4 (2023) define o formato AD Structure: cada elemento contém um comprimento (1 byte), tipo (1 byte) e valor (até 29 bytes). A especificação descreve mais de 30 tipos AD — desde Flags e Local Name até Service UUID e Manufacturer Specific Data. A embalagem correta dos advertising data é crítica para a compatibilidade do dispositivo com iOS, Android e outras plataformas, e também determina a velocidade de descoberta e a eficiência energética da publicidade.
Pontos Principais
- AD Structure é o formato de dados em um pacote de publicidade BLE: comprimento (1 byte), tipo (1 byte), valor (até 29 bytes).
- O pacote de publicidade é limitado a 31 bytes; scan response fornece mais 31 bytes para dados adicionais.
- Flags (0x01) é um tipo AD obrigatório que define os modos LE Limited Discoverable e BR/EDR Not Supported.
- Service UUID é transmitido em formato abreviado (2 bytes) ou completo (16 bytes).
- Manufacturer Specific Data (0xFF) é um tipo flexível para quaisquer dados personalizados do fabricante.
O que é Advertising Data?
Advertising Data é um conjunto estruturado de campos que um dispositivo BLE transmite em pacotes de publicidade para se identificar e descrever suas capacidades. O Central, escaneando o ar, lê esses dados e decide se conecta ao dispositivo, o ignora ou solicita informações adicionais através de Scan Response.
Os dados são organizados de acordo com o princípio TLV (Type-Length-Value): cada elemento AD consiste em três campos. Length (1 byte) é o comprimento de Value + Type (ou seja, o comprimento total do elemento menos 1 byte para Length). Type (1 byte) é o identificador do tipo de dados de Bluetooth Assigned Numbers. Value (N bytes) é o conteúdo dependendo do tipo.
Um pacote de publicidade padrão pode conter até 31 bytes de dados AD. Se isso não for suficiente, usa-se Scan Response (mais 31 bytes) ou Extended Advertising (BLE 5.0, até 251 bytes). Os primeiros bytes do pacote de publicidade são reservados para o cabeçalho PDU e o endereço do dispositivo — a carga útil AD começa em um deslocamento.
Formato AD Structure
Cada elemento AD no pacote de publicidade começa com o campo Length (1 byte). O valor Length indica o número de bytes que seguem após Length — ou seja, Type + Value. Por exemplo, um elemento com Length=3 significa que após Length há 1 byte de Type e 2 bytes de Value. O pacote termina quando a soma dos comprimentos de todos os elementos atinge o tamanho dos dados de publicidade.
| Campo | Tamanho | Descrição |
|---|---|---|
| Length | 1 byte | Comprimento de Type + Value (excluindo Length) |
| Type (AD Type) | 1 byte | Identificador do tipo de dados da Bluetooth SIG |
| Value | 0–29 bytes | Dados do tipo especificado |
O analisador Central lê a sequência de elementos AD começando pelo primeiro byte após o cabeçalho. Se Length=0, o elemento é ignorado e o analisador passa para o próximo byte. Tipos AD duplicados — múltiplos elementos com o mesmo Type em um pacote — são permitidos, mas o Central pode processar apenas o primeiro ou o último dependendo da implementação da pilha.
Uma regra importante: a soma de todos os Length(+1) no pacote não deve exceder o tamanho dos dados de publicidade (31 bytes para advertising PDU). Se os dados não couberem, as prioridades devem ser definidas — quais tipos AD são críticos para a descoberta inicial e quais podem ser movidos para Scan Response.
Flags (0x01): Tipo AD Obrigatório
Flags (AD Type 0x01) é um elemento obrigatório no pacote de publicidade de qualquer dispositivo BLE. Ocupa 3 bytes: Length (0x02), Type (0x01), Value (1 byte de flags de bits). As flags definem os modos de descoberta e as capacidades do dispositivo. A Core Specification recomenda incluir Flags em cada pacote de publicidade.
Principais flags: LE Limited Discoverable Mode (bit 0) — o dispositivo é detectável por tempo limitado, LE General Discoverable Mode (bit 1) — o dispositivo é sempre detectável, BR/EDR Not Supported (bit 2) — o dispositivo suporta apenas LE, Simultaneous LE and BR/EDR (bit 3) — suporta ambos os modos. Para dispositivos puramente BLE, a combinação LE General Discoverable + BR/EDR Not Supported é obrigatória.
Um valor incorreto de Flags é uma das causas comuns pelas quais um dispositivo não é detectado no iOS ou Android. Por exemplo, se a flag BR/EDR Not Supported não estiver definida, o iOS pode tentar conectar via Bluetooth clássico em vez de BLE. Verifique o valor de Flags ao depurar o pacote de publicidade com um analisador Bluetooth (nRF Connect, Wireshark).
Local Name: Nome do Dispositivo
Local Name (AD Type 0x08 ou 0x09) é o nome visível do dispositivo BLE. O tipo 0x08 (Shortened Local Name) é um nome abreviado, usado quando o nome completo não cabe no pacote de publicidade. O tipo 0x09 (Complete Local Name) é o nome completo do dispositivo. O comprimento máximo do nome é 248 bytes, mas em um pacote de publicidade padrão não estão disponíveis mais de 28 bytes.
Se o nome do dispositivo exceder o espaço disponível no pacote de publicidade, recomenda-se: colocar o nome abreviado no advertising PDU (tipo 0x08) e o nome completo no Scan Response (tipo 0x09). O iOS exibe o nome do pacote de publicidade durante a digitalização, enquanto o nome completo fica disponível após a conexão ou Scan Response.
Ao escolher um nome de dispositivo, lembre-se: um nome muito longo ocupa espaço que poderia ser usado para Service UUID ou outros dados importantes. O comprimento de nome recomendado é de 8 a 16 caracteres. Evite caracteres não padrão e espaços — algumas pilhas BLE podem processá-los incorretamente.
Service UUID: Identificação de Serviços
Service UUID (AD Type 0x02–0x07) é um dos tipos AD mais importantes, permitindo ao Central determinar quais serviços o dispositivo fornece sem se conectar a ele. A Bluetooth SIG define vários formatos de transmissão de UUID dependendo do tamanho: 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 serviços padrão Bluetooth SIG, por exemplo 0x180F (Battery Service), 0x180A (Device Information). UUID de 128 bits (16 bytes) para serviços personalizados definidos pelo desenvolvedor. Um UUID de 16 bits ocupa apenas 4 bytes em AD (Length + Type + 2 bytes UUID), enquanto um de 128 bits ocupa 18 bytes. Se vários UUIDs personalizados precisarem ser transmitidos em um pacote, eles podem não caber em 31 bytes.
Recomenda-se usar o tipo Incomplete (0x02/0x04/0x06) se nem todos os UUIDs do dispositivo forem transmitidos, apenas os mais importantes para filtragem. A lista completa de UUIDs é transmitida via Scan Response ou GATT Discovery após a conexão. Isso economiza espaço no pacote de publicidade para outros tipos AD.
Manufacturer Specific Data
Manufacturer Specific Data (AD Type 0xFF) é o tipo AD mais flexível, projetado para transmitir dados personalizados do fabricante. Os primeiros 2 bytes de Value são o Company Identifier Code atribuído pela Bluetooth SIG (por exemplo, 0x004C para Apple, 0x0075 para Samsung). Os bytes restantes são dados arbitrários em um formato definido pelo fabricante.
A Apple usa Manufacturer Data para iBeacon: Company ID (0x004C), tipo Beacon (0x0215), UUID (16 bytes), Major (2 bytes), Minor (2 bytes), TX Power (1 byte). O Google usa um formato semelhante para Eddystone. Fabricantes de dispositivos IoT frequentemente colocam leituras de sensores ou status do dispositivo em 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;
}Ao usar Manufacturer Data, é importante respeitar a limitação de tamanho: 31 bytes para todo o pacote de publicidade menos os tipos AD obrigatórios. Para Apple iBeacon, todo o pacote ocupa 30 bytes, deixando espaço apenas para Flags (3 bytes). Para Eddystone — até 31 bytes. Formatos personalizados compactos podem incluir temperatura, umidade ou pressão em 4 a 8 bytes.
Estratégia de Empacotamento de Dados
O empacotamento correto de advertising data é a arte de colocar o máximo de informações úteis no espaço limitado de 31 bytes. A estratégia depende do propósito do dispositivo: um farol precisa de um identificador, um sensor IoT precisa de leituras, um rastreador de fitness precisa de um nome e UUIDs de serviços. O princípio geral: quanto mais rápido o Central precisar tomar uma decisão, mais críticos devem ser os dados no advertising PDU.
Estratégia recomendada: advertising PDU (primeiros 31 bytes) — Flags (3 bytes) + um Service UUID de 16 bits (4 bytes) + nome abreviado (até 12 caracteres = 14 bytes) + Manufacturer Data (até 10 bytes). Scan Response (segundos 31 bytes) — nome completo (restante) + Service UUIDs adicionais + TX Power Level (3 bytes). Esta distribuição permite ao Central filtrar rapidamente os dispositivos por UUID.
| Prioridade | Tipo AD | Tamanho | Colocar em |
|---|---|---|---|
| 1 (obrigatório) | Flags (0x01) | 3 bytes | Advertising PDU |
| 2 (filtragem) | Service UUID (0x02–0x03) | 4+ bytes | Advertising PDU |
| 3 (identificação) | 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 (dados completos) | UUIDs restantes | Por tamanho | Scan Response |
A depuração de advertising data é uma etapa obrigatória no desenvolvimento de dispositivos BLE. Use nRF Connect (Nordic Semiconductor) ou Wireshark com um analisador Bluetooth para visualizar os dados brutos do pacote. Verifique se todos os tipos AD têm Length correto, se a soma dos comprimentos não excede 31 bytes e se as Flags estão configuradas corretamente para o seu caso de uso.
Perguntas Frequentes
O que acontece se a soma dos elementos AD ultrapassar 31 bytes?
A pilha do Bluetooth Controller descartará os dados que excederem o limite ou não enviará o pacote. Verifique o comprimento total dos elementos AD ao montar o pacote de publicidade. Se os dados não couberem, mova parte para Scan Response ou use Extended Advertising (BLE 5.0) com um limite de 251 bytes.
É possível transmitir leituras de sensores em um pacote de publicidade?
Sim, através de Manufacturer Specific Data (0xFF). Empacote as leituras em 4–8 bytes: por exemplo, temperatura (2 bytes em formato de ponto fixo), umidade (2 bytes), voltagem da bateria (2 bytes). Esta abordagem permite ao Central ler dados sem conectar, economizando energia.
Qual tipo AD devo usar para serviços personalizados?
Para serviços personalizados, use UUID de 128 bits (AD Type 0x06–0x07). Se o UUID não couber no advertising PDU (16 bytes por UUID), mova-o para Scan Response ou use o formato abreviado Incomplete (0x06) para especificar apenas o primeiro ou os dois primeiros UUIDs.
Qual é a diferença entre os tipos Complete e Incomplete de Service UUID?
Complete — no pacote estão listados todos os UUIDs de serviço do dispositivo. Incomplete — apenas uma parte dos UUIDs (geralmente os mais importantes). O Central não pode confiar no Incomplete como uma lista completa, mas o usa para filtragem rápida. A lista completa está disponível após GATT Discovery.
Por que o iOS não vê meu dispositivo BLE?
Uma causa comum é um Flags (0x01) incorreto. Certifique-se de que o bit BR/EDR Not Supported esteja definido. A segunda causa é a ausência de Service UUID no pacote de publicidade (iOS filtra por UUID). A terceira é que o dispositivo anuncia com pouca frequência (iOS espera um intervalo não superior a 1000 ms).
Resumo
- Advertising Data são dados estruturados no formato AD Structure (Length-Type-Value), transmitidos em pacotes de publicidade BLE.
- Um pacote de publicidade padrão contém até 31 bytes de dados; Scan Response fornece mais 31 bytes para informações adicionais.
- Flags (0x01) é um tipo AD obrigatório que define os modos de descoberta. BR/EDR Not Supported é obrigatório para dispositivos BLE.
- Service UUID é transmitido em formato de 16 bits (2 bytes) ou 128 bits (16 bytes), Complete ou Incomplete dependendo do espaço disponível.
- Manufacturer Specific Data (0xFF) é um tipo flexível para dados personalizados, usado em faróis iBeacon, Eddystone e dispositivos IoT.
- Estratégia de empacotamento: tipos AD obrigatórios (Flags, Service UUID, nome abreviado) no advertising PDU; os adicionais no Scan Response.
- Depure advertising data usando nRF Connect ou Wireshark — uma etapa obrigatória de desenvolvimento para verificar a estrutura AD correta.
Vamos desenvolver um aplicativo móvel chave na mão
A IT Sectr cria aplicativos para iOS e Android para startups e empresas desde 2017. Nós vamos aconselhá-lo e propor a melhor solução.
Leia também