BLE sob um microscópio (ATTы GATTы…)
Parte 1, visão geral
Já se passou muito tempo desde que a primeira especificação do Bluetooth 4.0 foi lançada. E, embora o tema BLE seja muito interessante, ainda desanima muitos desenvolvedores devido à sua complexidade. Em meus artigos anteriores, observei principalmente o nível mais baixo, Camada de Link e Camada Física. Isto permitiu-nos evitar o recurso a conceitos tão complexos e confusos como o Protocolo de Atributos (ATT) e o Perfil Geral de Atributos (GATT). Porém, não há para onde ir, sem entendê-los é impossível desenvolver dispositivos compatíveis. Hoje gostaria de compartilhar esse conhecimento com você. No meu artigo vou contar com para iniciantes no site nórdico. Então vamos começar.
Por que tudo é tão difícil?
Na minha opinião, ficou imediatamente claro que a gestão de dispositivos através de smartphones é um tema muito promissor e duradouro. Por isso, decidiram estruturá-lo de imediato e ao máximo. Para que fabricantes de diversos gadgets não criem protocolos próprios, que então serão incompatíveis. Daí a dificuldade. Já na primeira fase, eles tentaram inserir todo o possível no protocolo BLE. E não importa se será útil mais tarde ou não. Além disso, previram a possibilidade de ampliar a lista de dispositivos para o futuro.
Vamos dar uma olhada na imagem onde o diagrama do protocolo BLE está desenhado. Consiste em várias camadas. A camada física mais baixa (PHY) é responsável pelo canal de rádio do dispositivo. Link Layer (LL) contém toda a sequência de bytes da mensagem transmitida. Em artigos anteriores estudamos exatamente isso. Host Controller Interface (HCI) é um protocolo de troca entre camadas ou chips BLE se o controlador e o host forem implementados em chips diferentes. O Protocolo de Controle e Adaptação de Link Lógico (L2CAP) é responsável pela formação de pacotes, enquadramento, controle de erros e montagem de pacotes. O Security Manager Protocol (SMP) é responsável por criptografar pacotes. O Perfil de Acesso Geral (GAP) é responsável pela troca inicial de dados entre dispositivos para determinar “Quem é quem”. Também inclui digitalização e publicidade. Neste artigo vou me concentrar nas duas partes restantes do protocolo – GATT e ATT. O GATT é uma superestrutura do ATT, pelo que estão intimamente interligados.
Para simplificar a história, gostaria de recorrer a uma analogia. Eu ouvi isso em algum lugar e gostaria de apoiá-lo. Pense em um dispositivo BLE como uma estante com diversas prateleiras. Cada prateleira é um tema separado. Por exemplo, temos estantes com ficção científica, matemática e enciclopédias. Em cada estante há livros com um tema específico. E alguns livros têm até marcadores de papel com anotações. Além disso, temos um pequeno catálogo em papel de todos os livros. Se você se lembra, as bibliotecas escolares são uma caixa estreita com cartões de papel. Com esta analogia, o gabinete é o perfil do nosso dispositivo. As estantes são serviços, os livros são características e o catálogo é uma tabela de atributos. Marcadores em livros são descritores, sobre os quais falarei mais tarde com mais detalhes.
Qualquer pessoa que tenha desenvolvido dispositivos sabe que muitos projetos possuem códigos semelhantes. O fato é que muitos dispositivos possuem funcionalidades semelhantes. Por exemplo, se os dispositivos forem alimentados por baterias, o problema de carregar e monitorar seu nível será o mesmo. O mesmo vale para sensores. Na verdade, uma abordagem orientada a objetos para programação “fornece a capacidade de criar objetos que combinam propriedades e comportamentos em uma união independente que pode então ser reutilizada”. Na minha opinião, o BLE tentou uma abordagem semelhante. Os perfis foram desenvolvidos pelo Bluetooth Special Interest Group (SIG). Dispositivos de fabricantes diferentes que possuem os mesmos perfis devem funcionar entre si sem dificuldade. Os perfis, por sua vez, são compostos por serviços, e serviços por características, complementados por descritores. Em geral, pode ser assim:
Por exemplo, considere o diagrama do perfil de um monitor de frequência cardíaca (pulseira de fitness). É composto por dois serviços e diversas características. A partir dele, a hierarquia de perfis fica imediatamente clara. A característica do ponto de verificação redefine a contagem total do gasto calórico para zero.
1. O serviço de frequência cardíaca inclui três características (0x180D):
a) Característica obrigatória da frequência cardíaca (0x2A37)
b) Característica de posição do sensor corporal opcional (0x2A38)
c) Características condicionais do ponto de controle da frequência cardíaca (0x2A39)
2. Serviço de manutenção de bateria (0x180F):
a) Característica obrigatória do nível de carga da bateria (0x2A19)
UUID
Para que possamos acessar de forma única os elementos do perfil (serviços, características e descritores), precisamos numerá-los de alguma forma. Para este propósito, é introduzido um conceito como ID Universalmente Único (UUID) ou Identificador Universalmente Único. O UUID é indicado entre colchetes de cada linha. E há uma peculiaridade aqui. Para UUID, decidimos usar um código de 16 e 128 bits de comprimento. Porque você pergunta? No protocolo BLE, tudo gira em torno da conservação de energia. Portanto, a dimensão de 16 bits é bastante razoável. É improvável que mais de 65 mil sejam criados num futuro próximo. serviços e características únicas. No momento, tudo o que poderiam já foi contado (lembre-se de onde veio isso - “ele contou você também” :-)) Elementos numerados , , и você pode olhar os links.
No entanto, acho que todos se lembram da história dos 4 bytes de endereços IP na Internet. No início pensamos que era o suficiente, mas agora ainda não podemos mudar para um endereço de 6 bytes. Para não repetir esse erro e dar liberdade às mãos brincalhonas dos DIYers, a SIG decidiu imediatamente introduzir UUIDs de 128 bits. Pessoalmente, isso me lembra a banda não licenciada de 433 MHz, que foi dada a todos os tipos de Kulibins do canal de rádio. No nosso caso, um identificador de serviços e características de 128 bits foi distribuído. Isso significa que nós, para nossos serviços e dispositivos, podemos usar quase qualquer valor de 128 bits. Mesmo assim, a probabilidade de obter o mesmo UUID tende a zero.
Na verdade, UUIDs curtos de 16 bits têm sua extensão para um valor de 128 bits. Na especificação, esta extensão é chamada Bluetooth Base UUID e tem o valor 00000000-0000-1000-8000-00805F9B34FB. Se, por exemplo, o UUID do atributo de 16 bits tiver o valor 0x1234, então o UUID equivalente de 128 bits terá o valor 00001234-0000-1000-8000-00805F9B34FB. E até mesmo a fórmula correspondente é dada:
128_bit_value = 16_bit_value * 2 ^ 96 + Bluetooth_Base_UUID
Não sei de onde veio esse número mágico. Se algum dos leitores souber, deixe-o escrever nos comentários (um usuário com o apelido Sinopteek já fez isso. Veja os comentários). Quanto a criar UUIDs de 128 bits, em princípio você pode usar um especial quem fará isso por você.
ATty GATTy...
Na verdade, então a diversão começa. Deixe-me lembrá-lo de que a ATT é baseada em um relacionamento cliente-servidor. Agora estamos olhando para o dispositivo do servidor. Ele contém informações como valores do sensor, status do interruptor de luz, dados de localização, etc. Agora que todos os “participantes do nosso desfile” estão numerados, precisamos colocá-los de alguma forma na memória do aparelho. Para fazer isso, nós os colocamos em uma tabela chamada tabela de atributos. Lembre-se bem disso. Este é o coração do BLE. Isto é o que consideraremos mais adiante. Agora chamaremos cada linha de atributo. Esta tabela está localizada no fundo da pilha e, via de regra, não temos acesso direto a ela. Nós o inicializamos e acessamos, mas o que acontece dentro dele fica escondido atrás de sete selos.
Vejamos a imagem da especificação, mas antes gostaria de chamar imediatamente a atenção para a frequente confusão de termos, nomeadamente nos descritores. A função do descritor é complementar a descrição da característica. Quando é necessário expandir suas capacidades, são utilizados descritores. Eles também são atributos e, assim como os serviços e as características, estão localizados na tabela de atributos. Iremos examiná-los em detalhes na segunda parte do artigo. No entanto, às vezes os descritores referem-se ao número da linha na tabela de atributos. Isto deve ser mantido em mente. Para evitar confusão, usaremos o termo “ponteiro de atributo” para esses fins.
Portanto, um atributo é um valor discreto que possui as seguintes propriedades associadas a ele:
1. Attribute Handle é o índice da tabela correspondente ao atributo
2. Tipo de atributo é um UUID que descreve seu tipo
3. Valor do atributo são os dados indexados pelo ponteiro do atributo
4. Permissões de Atributo são a parte de um atributo, as permissões, que não podem ser lidas ou escritas usando o protocolo de atributos
Como entender tudo isso? O ponteiro de atributo é, relativamente falando, o seu número em nossa tabela.
Ele permite que um cliente faça referência a um atributo em solicitações de leitura ou gravação. Podemos numerar nossas linhas (atributos) de 0x0001 a 0xFFFF. Na nossa associação com a estante, este é o número do cartão do catálogo em papel. Da mesma forma, como no catálogo da biblioteca, os cartões são organizados em ordem crescente de número. O número de cada linha subsequente deve ser maior que o anterior. Assim como na biblioteca, às vezes alguns cartões se perdem, então conosco pode haver lacunas na numeração das linhas. Isso é permitido. O principal é que vão progressivamente.
O tipo de atributo determina o que o atributo representa. Por analogia com a linguagem C,
onde existem variáveis booleanas e numéricas e strings, então está aqui. Por tipo de atributo reconhecemos
com o que estamos lidando e como podemos continuar trabalhando com esse atributo. Abaixo veremos alguns tipos específicos de atributos. Por exemplo, “declaração de serviço” (0x2800), “declaração de característica” (0x2803), “declaração de descritor” (0x2902).
O valor de um atributo é o seu significado real, perdoe a tautologia. Se o tipo do atributo for uma string, então o valor do atributo pode ser, por exemplo, o slogan “Hello World !!!”. Se o tipo de atributo for uma “declaração de serviço”, então seu valor será o próprio serviço. E às vezes são informações sobre onde encontrar outros atributos e suas propriedades.
As permissões de atributos permitem que o servidor entenda se o acesso de leitura ou gravação é permitido.
Observe que essas permissões se aplicam apenas ao valor do atributo e não ao ponteiro, tipo ou campo de permissão em si. Aqueles. se a gravação de atributos for permitida, então podemos alterar, por exemplo, a linha “Hello World !!!” para a linha “Bom dia”. Mas não podemos proibir a escrita de uma nova linha ou alterar o tipo de atributo e designar a linha como uma “declaração de serviço”. Quando um cliente contata um servidor, o cliente solicita seus atributos. Isso permite que o cliente saiba o que o servidor pode fornecer. Embora não seja necessário ler e escrever os valores.
O que parece
O conceito do GATT é agrupar atributos em uma tabela de atributos em uma ordem muito específica e lógica. Vamos dar uma olhada mais de perto no perfil de frequência cardíaca abaixo. A coluna mais à esquerda desta tabela é opcional. Simplesmente nos descreve o que é esta linha (atributo). Todas as outras colunas já nos são familiares.
No topo de cada grupo sempre temos um atributo de declaração de serviço. Seu tipo é sempre 0x2800, e o ponteiro depende de quantos atributos já estão presentes na tabela. Suas permissões são sempre somente leitura, sem qualquer autenticação ou autorização. Falaremos sobre esses conceitos um pouco mais tarde. O valor é outro UUID que identifica qual é o serviço. Na Tabela o valor é 0x180D, que é definido pelo Bluetooth SIG como serviço de frequência cardíaca.
Após o anúncio do serviço, vem o anúncio da característica. É semelhante em forma a uma declaração de serviço. Seu UUID é sempre 0x2803 e suas permissões são sempre somente leitura, sem qualquer autenticação ou autorização. Vejamos o campo Valor do Atributo, que inclui alguns dados. Ele sempre contém um ponteiro, um UUID e um conjunto de propriedades. Esses três elementos descrevem a declaração subsequente do valor da característica. O ponteiro denota naturalmente a localização da declaração do valor da característica na tabela de atributos. O UUID descreve que tipo de informação ou valor podemos esperar. Por exemplo, o valor da temperatura, o estado do interruptor de luz ou algum outro valor arbitrário. E, finalmente, propriedades, que descrevem como o valor da característica pode interagir.
Outra armadilha nos espera aqui. Está associado a permissões de atributos e propriedades características. Vejamos a imagem das propriedades do campo de bits da especificação.
Como você pode ver, também existem campos aqui que fornecem recursos de leitura e gravação. Você pode estar se perguntando por que temos permissões de leitura/gravação para atributos e propriedades
leitura/gravação para valor característico? Eles não deveriam ser sempre os mesmos? O fato é que as propriedades do valor da característica são, na verdade, apenas recomendações para o cliente utilizadas no GATT e nas camadas de aplicação. Estas são simplesmente dicas sobre o que o cliente pode esperar do atributo de declaração de característica. Vejamos isso com mais detalhes. Que tipos de permissões um atributo possui?
1. Permissões de acesso:
- lendo
- registro
- Leia e escreva
2. Permissão de autenticação:
- autentificação requerida
- nenhuma autenticação necessária
3. Permissão de autorização:
- autorização necessária
- nenhuma autorização necessária
A principal diferença entre resolução de atributos e propriedades características é que as primeiras se aplicam a servidores e as últimas a clientes. O servidor pode ter permissão para ler o valor da característica, mas pode exigir autenticação ou autorização. Portanto, quando o cliente solicitar as propriedades da característica, receberemos que a leitura é permitida. Mas quando tentamos ler, recebemos um erro. Portanto, podemos falar com segurança sobre a prioridade das permissões sobre as propriedades. Do lado do cliente, não podemos obter conhecimento de quais permissões um atributo possui.
Descritor
Voltemos à nossa mesa. Após declarar o valor de uma característica, são possíveis as seguintes declarações de atributos:
1. Nova declaração de características (um serviço pode ter muitas características)
2. Nova declaração de serviço (pode haver muitos deles na tabela)
3. Declarando um identificador
No caso da característica de medição da frequência cardíaca, na nossa tabela, a declaração do valor da característica é acompanhada da declaração do descritor. Um descritor é um atributo com informações adicionais sobre uma característica. Existem vários tipos de descritores. Falaremos sobre eles em detalhes na segunda parte deste artigo. Por enquanto, abordaremos apenas o Client Characteristic Configuration Descriptor (CCCD). Possui um UUID igual a 0x2902. Utilizando este descritor, o cliente tem a capacidade de habilitar indicação ou notificação no servidor. A diferença entre eles é pequena, mas ainda existe. A notificação não requer confirmação de recebimento por parte do cliente. A indicação exige isso, embora ocorra no nível do GATT, não atingindo o nível da aplicação. Por que isso, você pergunta? Infelizmente, eu não sei disso. Deixe-me apenas dizer que os especialistas nórdicos recomendam o uso de notificações. Além disso, a verificação da integridade do pacote (usando CRC) ocorre em ambos os casos.
Conclusão
No final do artigo gostaria de dizer isso. A última tabela é um pouco confusa. No entanto, eu o escolhi porque é dado em , em que confio. Na segunda parte do meu artigo pretendo me aprofundar na especificação do BlueTooth 4.0. Diagramas e desenhos mais corretos nos aguardam lá. Na terceira parte, gostaria de analisar o log obtido com o programa Wireshark de um dos gadgets e ver “ao vivo” toda a teoria que estamos estudando.
Colaborador do Grupo de Empresas
Pechersky Vladimir
Fonte: habr.com