BLE baixo un microscopio (ATTы GATTы...)
Parte 1, visión xeral
Xa pasou moito tempo desde que se publicou a primeira especificación para Bluetooth 4.0. E, aínda que o tema BLE é moi interesante, aínda desanima a moitos desenvolvedores pola súa complexidade. Nos meus artigos anteriores, observei principalmente o nivel máis baixo, a capa de enlace e a capa física. Isto permitiunos evitar ter que recorrer a conceptos tan complexos e confusos como o Protocolo de Atributos (ATT) e o Perfil Xeral de Atributos (GATT). Non obstante, non hai onde ir, sen entendelos, é imposible desenvolver dispositivos compatibles. Hoxe gustaríame compartir este coñecemento contigo. No meu artigo contarei para principiantes do sitio web nórdico. Entón, imos comezar.
Por que todo é tan difícil?
Na miña opinión, inmediatamente quedou claro que a xestión de dispositivos a través de teléfonos intelixentes é un tema moi prometedor e de longa duración. Por iso, decidiron estruturalo de inmediato e ao máximo. Para que os fabricantes de varios aparellos non crean os seus propios protocolos, que logo serán incompatibles. De aí a dificultade. Xa na primeira etapa, intentaron espremer todo o posible no protocolo BLE. E non importa se será útil despois ou non. Ademais, prevén a posibilidade de ampliar a lista de dispositivos para o futuro.
Vexamos a imaxe onde se debuxa o diagrama do protocolo BLE. Consta de varias capas. A capa física máis baixa (PHY) é a responsable da canle de radio do dispositivo. Link Layer (LL) contén toda a secuencia de bytes da mensaxe transmitida. Nos artigos anteriores estudamos exactamente isto. Host Controller Interface (HCI) é un protocolo de intercambio entre capas ou chips BLE se o controlador e o host están implementados en chips diferentes. O protocolo de adaptación e control de enlaces lóxicos (L2CAP) é o responsable da formación, encadramento, control de erros e montaxe de paquetes. O protocolo de xestor de seguridade (SMP) é o responsable de cifrar os paquetes. O Perfil de Acceso Xeral (GAP) é o responsable do intercambio inicial de datos entre dispositivos para determinar "Quen é quen". Tamén inclúe a dixitalización e a publicidade. Neste artigo centrareime nas dúas partes restantes do protocolo: GATT e ATT. GATT é unha superestrutura de ATT, polo que están estreitamente entrelazados.
Para simplificar a historia, gustaríame pasar a unha analoxía. Escoiteino nalgún lugar e gustaríame apoialo. Pense nun dispositivo BLE como unha estantería con varios estantes. Cada estante é un tema separado. Por exemplo, temos estantes con ciencia ficción, matemáticas e enciclopedias. En cada andel hai libros cun tema específico. E algúns libros incluso teñen marcapáxinas de papel con notas. Ademais, temos un pequeno catálogo en papel de todos os libros. Se lembras, as bibliotecas escolares son unha caixa estreita con cartolinas de papel. Con esta analoxía, o armario é o perfil do noso dispositivo. Os andeis son servizos, os libros son características e o catálogo é unha táboa de atributos. Os marcadores dos libros son descritores, dos que tamén falarei máis adiante con máis detalle.
Calquera persoa que desenvolveu dispositivos sabe que moitos proxectos teñen pezas de código similares. O feito é que moitos dispositivos teñen unha funcionalidade similar. Por exemplo, se os dispositivos funcionan con baterías, entón o problema de cargar e controlar o seu nivel será o mesmo. O mesmo ocorre cos sensores. En realidade, un enfoque orientado a obxectos da programación "Ofrece a capacidade de crear obxectos que combinen propiedades e comportamentos nunha unión autónoma que despois se pode reutilizar". Na miña opinión, BLE intentou un enfoque similar. Os perfís foron desenvolvidos polo Bluetooth Special Interest Group (SIG). Os dispositivos de diferentes fabricantes que teñan os mesmos perfís deberían funcionar entre si sen dificultade. Os perfís, á súa vez, consisten en servizos e servizos de características, complementados con descritores. En xeral, pode verse así:
Por exemplo, considere o diagrama de perfil dun monitor de frecuencia cardíaca (pulseira de fitness). Consta de dous servizos e varias características. A partir del a xerarquía do perfil queda inmediatamente clara. A característica do punto de control restablece a conta de gasto total de calorías a cero.
1. O servizo de frecuencia cardíaca inclúe tres características (0x180D):
a) Característica de frecuencia cardíaca obrigatoria (0x2A37)
b) Característica de posición do sensor corporal opcional (0x2A38)
c) Características condicionais do punto de control da frecuencia cardíaca (0x2A39)
2. Servizo de mantemento da batería (0x180F):
a) Característica obrigatoria do nivel de carga da batería (0x2A19)
UUID
Para poder acceder de forma única aos elementos do perfil (servizos, características e descritores), necesitamos numeralos todos dalgún xeito. Para este fin, introdúcese un concepto como Universally Unique ID (UUID) ou Universally Unique Identifier. O UUID indícase entre os corchetes de cada liña. E aquí hai unha peculiaridade. Para UUID, decidimos usar un código de 16 e 128 bits de lonxitude. Por que preguntas? No protocolo BLE, todo é sobre aforro de enerxía. Polo tanto, a dimensión de 16 bits é bastante razoable. É improbable que se creen máis de 65 mil nun futuro próximo. servizos e características únicas. Polo momento, todo o que poderían ter contado xa (lembra de onde veu isto - "el tamén te contou" :-)) Elementos numerados , , и podes mirar as ligazóns.
Non obstante, creo que todos lembran a historia con 4 bytes de enderezos IP en Internet. Ao principio pensamos que era suficiente, pero agora aínda non podemos cambiar a un enderezo de 6 bytes. Para non repetir este erro e dar vía libre ás mans bricolaxes dos bricolaxes, SIG decidiu inmediatamente introducir UUID de 128 bits. Isto persoalmente recórdame á banda de 433 MHz sen licenza, que se lle deu a todo tipo de Kulibins da canle de radio. No noso caso, eliminouse un identificador de servizos e características de 128 bits. Isto significa que nós, para os nosos servizos e dispositivos, podemos usar case calquera valor de 128 bits. De todos os xeitos, a probabilidade de obter o mesmo UUID tende a cero.
De feito, os UUID curtos de 16 bits teñen a súa extensión a un valor de 128 bits. Na especificación, esta extensión chámase UUID Bluetooth Base e ten o valor 00000000-0000-1000-8000-00805F9B34FB. Se, por exemplo, o UUID do atributo de 16 bits ten o valor 0x1234, entón o UUID equivalente de 128 bits terá o valor 00001234-0000-1000-8000-00805F9B34FB. E mesmo dáse a fórmula correspondente:
128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID
Non sei de onde veu este número máxico. Se algún dos lectores o sabe, que escriba nos comentarios (Un usuario co alcume de Sinopteek xa o fixo. Consulta os comentarios). En canto a crear UUID de 128 bits, en principio podes usar un especial quen o fará por ti.
ATTy GATTy...
En realidade, entón comeza a diversión. Permíteme lembrarche que ATT baséase nunha relación cliente-servidor. Agora estamos mirando o dispositivo servidor. Contén información como valores do sensor, estado do interruptor de luz, datos de localización, etc. Agora que todos os "participantes do noso desfile" están numerados, hai que colocalos dalgún xeito na memoria do dispositivo. Para iso, poñémolos nunha táboa chamada táboa de atributos. Lembra ben isto. Este é o corazón de BLE. Isto é o que teremos máis en conta. Agora chamaremos atributo a cada liña. Esta táboa está situada no fondo da pila e, por regra xeral, non temos acceso directo a ela. Iniciámolo e accedemos a el, pero o que ocorre no interior ocúltasenos detrás de sete selos.
Vexamos a imaxe da especificación, pero antes diso, gustaríame chamar inmediatamente a atención sobre a frecuente confusión nos termos, especialmente nos descritores. A función do descritor é complementar a descrición da característica. Cando é necesario ampliar as súas capacidades, utilízanse descritores. Tamén son atributos e, ao igual que os servizos e as características, están situados na táboa de atributos. Examinarémolos en detalle na segunda parte do artigo. Non obstante, ás veces os descritores fan referencia ao número de fila da táboa de atributos. Isto hai que telo presente. Para evitar confusións, utilizaremos o termo "punteiro de atributo" para estes fins.
Polo tanto, un atributo é un valor discreto que ten asociadas as seguintes propiedades:
1. O identificador do atributo é o índice da táboa correspondente ao atributo
2. O tipo de atributo é un UUID que describe o seu tipo
3. O valor do atributo son os datos indexados polo punteiro do atributo
4. Os permisos de atributos son a parte dun atributo, os permisos, que non se poden ler nin escribir mediante o protocolo de atributos
Como entender todo isto? O punteiro de atributo é, relativamente falando, o seu número na nosa táboa.
Permite que un cliente faga referencia a un atributo nas solicitudes de lectura ou escritura. Podemos numerar as nosas liñas (atributos) de 0x0001 a 0xFFFF. Na nosa asociación coa estantería, este é o número de tarxeta no catálogo en papel. Do mesmo xeito, como no catálogo da biblioteca, as fichas están dispostas por orde crecente de número. O número de cada liña posterior debe ser maior que a anterior. Do mesmo xeito que na biblioteca, ás veces pérdense algunhas tarxetas, polo que connosco pode haber ocos na numeración das liñas. Isto está permitido. O principal é que van progresivamente.
O tipo de atributo determina o que representa o atributo. Por analoxía coa linguaxe C,
onde hai variables booleanas, numéricas e cadeas, polo que está aquí. Polo tipo de atributo que recoñecemos
que estamos a tratar e como podemos seguir traballando con este atributo. A continuación veremos algúns tipos específicos de atributos. Por exemplo, "declaración de servizo" (0x2800), "declaración de características" (0x2803), "declaración de descriptor" (0x2902).
O valor dun atributo é o seu significado real, perdoe a tautoloxía. Se o tipo de atributo é unha cadea, entón o valor do atributo pode ser, por exemplo, o slogan "Hello World !!!". Se o tipo de atributo é unha "declaración de servizo", entón o seu valor é o servizo en si. E ás veces esta é información sobre onde atopar outros atributos e as súas propiedades.
Os permisos de atributos permiten ao servidor comprender se se permite o acceso de lectura ou escritura.
Teña en conta que estes permisos só se aplican ao valor do atributo, e non ao propio campo de punteiro, tipo ou permiso. Eses. se se permite a gravación de atributos, podemos cambiar, por exemplo, a liña "Hello World !!!" á liña "Bos días". Pero non podemos prohibir escribir unha nova liña nin cambiar o tipo de atributo e designar a liña como "declaración de servizo". Cando un cliente contacta cun servidor, o cliente solicita os seus atributos. Isto permítelle ao cliente saber o que pode proporcionar o servidor. Aínda que non é necesario ler e escribir os valores.
Como parece
O concepto de GATT é agrupar atributos nunha táboa de atributos nunha orde moi específica e lóxica. Vexamos máis de cerca o perfil da frecuencia cardíaca a continuación. A columna máis á esquerda desta táboa é opcional. Simplemente descríbenos o que é esta liña (atributo). Todas as outras columnas xa son coñecidas para nós.
Na parte superior de cada grupo sempre temos un atributo de declaración de servizo. O seu tipo é sempre 0x2800 e o punteiro depende de cantos atributos xa estean presentes na táboa. Os seus permisos son sempre de só lectura, sen ningunha autenticación ou autorización. Destes conceptos falaremos un pouco máis adiante. O valor é outro UUID que identifica cal é o servizo. Na táboa, o valor é 0x180D, que está definido polo Bluetooth SIG como un servizo de frecuencia cardíaca.
Tras o anuncio do servizo, vén o anuncio da característica. A súa forma é similar a unha declaración de servizo. O seu UUID é sempre 0x2803 e os seus permisos son sempre de só lectura sen ningunha autenticación ou autorización. Vexamos o campo Valor do atributo, que inclúe algúns datos. Sempre contén un punteiro, un UUID e un conxunto de propiedades. Estes tres elementos describen a declaración posterior do valor característico. O punteiro denota naturalmente a localización da declaración de valor da característica na táboa de atributos. O UUID describe que tipo de información ou valor podemos esperar. Por exemplo, o valor da temperatura, o estado do interruptor da luz ou algún outro valor arbitrario. E, finalmente, as propiedades, que describen como se pode interactuar co valor característico.
Aquí nos espera outra trampa. Asóciase con permisos de atributos e propiedades características. Vexamos a imaxe das propiedades do campo de bits da especificación.
Como podes ver, tamén hai campos aquí que proporcionan capacidades de lectura e escritura. Quizais se estea preguntando por que temos permisos de lectura/escritura para atributos e propiedades
ler/escribir para o valor característico? Non deberían ser sempre iguais? O feito é que as propiedades para o valor característico son en realidade só recomendacións para o cliente que se usa no GATT e as capas de aplicación. Estas son simplemente suxestións sobre o que o cliente pode esperar do atributo de declaración característica. Vexamos isto con máis detalle. Que tipos de permisos ten un atributo?
1. Permisos de acceso:
- lectura
- rexistro
- Ler e escribir
2. Permiso de autenticación:
- Requírese autenticación
- non se precisa autenticación
3. Permiso de autorización:
- Requírese autorización
- non se precisa autorización
A principal diferenza entre a resolución de atributos e as propiedades características é que as primeiras aplícanse aos servidores e as segundas aos clientes. É posible que o servidor poida ler o valor da característica, pero pode requirir autenticación ou autorización. Polo tanto, cando o cliente solicite as propiedades da característica, recibiremos que se permite a lectura. Pero cando intentamos ler, aparece un erro. Polo tanto, podemos falar con seguridade da prioridade dos permisos sobre as propiedades. No lado do cliente, non podemos obter coñecemento de que permisos ten un atributo.
Descriptor
Volvemos á nosa mesa. Despois de declarar o valor dunha característica, son posibles as seguintes declaracións de atributos:
1. Nova declaración de características (un servizo pode ter moitas características)
2. Nova declaración de servizo (pode haber moitos deles na táboa)
3. Declaración dun identificador
No caso da característica de medición da frecuencia cardíaca, na nosa táboa, a declaración do valor da característica vai acompañada da declaración do descritor. Un descritor é un atributo con información adicional sobre unha característica. Hai varios tipos de descritores. Falaremos deles en detalle na segunda parte deste artigo. Polo momento, só tocaremos o Descriptor de configuración de características do cliente (CCCD). Ten un UUID igual a 0x2902. Usando este descritor, o cliente ten a capacidade de activar a indicación ou notificación no servidor. A diferenza entre eles é pequena, pero aínda así. A notificación non require a confirmación da recepción por parte do cliente. A indicación así o require, aínda que se produce a nivel do GATT, non chegando ao nivel de aplicación. Por que, pregunta? Ai, isto non o sei. Déixeme dicir que os expertos nórdicos recomendan usar notificacións. Ademais, a comprobación da integridade do paquete (usando CRC) ocorre en ambos os casos.
Conclusión
Ao final do artigo gustaríame dicir isto. A última táboa é un pouco confusa. Sen embargo, escolleino porque está cedido , no que confío. Na segunda parte do meu artigo, pretendo afondar máis na especificación BlueTooth 4.0. Alí espéranos esquemas e debuxos máis correctos. Na terceira parte, gustaríame analizar o rexistro obtido mediante o programa Wireshark dun dos gadgets e ver "en vivo" toda a teoría que estamos estudando.
Empregado do Grupo de Empresas
Pecherskikh Vladimir
Fonte: www.habr.com