BLE mikroskoobi all (ATT-d ja GATT-id…)

BLE mikroskoobi all (ATT-d ja GATT-id…)

Osa 1, ülevaade

On möödunud juba üsna kaua aega, sellest ajast, kui ilmus esimene spetsifikatsioon Bluetooth 4.0. Ja kuigi BLE teema on väga huvitav, tõukab see paljusid arendajaid siiski tagasi, oma keerukuse tõttu. Oma varasemates artiklites olen peamiselt vaadanud kõige madalamat taset Link Layer ja Physical Layer. See võimaldas mitte tegeleda selliste keeruliste ja segaste mõistetega nagu atribuudi protokoll (ATT) ja üldine atribuutide profiil (GATT). Kuid ilma nendeta ei ole võimalik arendada ühilduvaid seadmeid. Täna soovin jagada teiega neid teadmisi. Oma artiklis tuginen õpikule algajatele Nordic-i veebisaidilt. Nii et liikume edasi.

Miks on kõik nii keeruline?

Minu arvates oli kohe selge, et seadmete juhtimine nutitelefonide kaudu on väga perspektiivikas ja kestlik teema. Seetõttu otsustati see kohe maksimaalselt struktureerida. Et tootjad ei leiutaks erinevaid protokolle, mis hiljem ei ole ühilduvad. Sealt ka keerukus. Juba esimesel etapil püüti BLE protokolli mahutada kõik, mis võimalik. Ja pole tähtis, kas see osutub hiljem vajalikuks või mitte. Lisaks kaaluti tulevikus seadmete nimekirja laiendamise võimalust.

Vaadakem pilti, kus on kujutatud BLE protokolli skeemi. See koosneb mitmest kihist. Alumine, füüsiline kiht (PHY) vastutab seadme raadiosignaali eest. Link Layer (LL) sisaldab kõiki edastatava sõnumi baitide järjestusi. Eelnevates artiklites uurisime just seda. Host Controller Interface (HCI) on protokoll kihtide või BLE kiipide vahelise suhtluse jaoks, kui Controller ja Host on erinevatel kiipidel. Pakkide vormimise, kaadrite jagamise, vigade kontrollimise ja pakkide kogumise eest vastutab Logical Link Control and Adaptation Protocol (L2CAP). Pakkide krüpteerimise eest vastutab Security Manager Protocol (SMP). Üldkasutatava profiili (GAP) ülesanne on algne andmevahetus seadmete vahel, et määrata „Kes on kes“. Selle alla kuuluvad ka skaneerimine ja reklaamimine. Selles artiklis peatuge kahes ülejäänud protokolli osas — GATT ja ATT. GATT on ATT-i kohal, seega on nad omavahel tihedalt seotud.

Kuna jutustamist lihtsustada, tahaksin kasutada analoogiat. Olen seda kuskil kuulnud ja sooviksin toetada. Kujutage ette BLE seadet kui raamaturiiulit, kus on mitu riiulit. Iga riiul on eraldi teema. Näiteks, meil on riiulid ulmekirjanduse, matemaatika, entsüklopeediate jaoks. Igal riiulil on raamatud, mis käsitlevad selle eraldi teema. Mõnes raamatus on isegi paberist järjehoidjad märkmete tegemiseks. Lisaks on meil väike paberite kataloog, kus on kirja pandud kõik raamatud. Kui mäletate kooli raamatukogusid — see on kitsas sahtel paberist kaardiendanitega. Selles analoogias on kapp meie seadme profiil. Riiulid on teenused, raamatud on omadused ja kataloog on atribuutide tabel. Järjehoidjad raamatutes on deskriptorid, millest räägin hiljem, põhjalikumalt.

Keenud, kes on seadmeid arendanud, teavad, et paljudes projektides on sarnased koodilõigud. Asi on selles, et paljud seadmed omavad sarnast funktsionaalsust. Näiteks, kui seadmed töötavad akude pealt, siis laadimise ja nende taseme kontrollimise probleem on üks ja sama. Sama kehtib ka andurite kohta. Tegelikult on objektorienteeritud lähenemine programmeerimisel „pakub võimaluse luua objekte, mis ühendavad omadused ja käitumise iseseisvaks liiduks, mida saab seejärel korduvkasutada“. Minu arvates on BLE-s püüdnud sarnast lähenemist. Bluetooth Special Interest Group (SIG) on välja töötanud profiilid. Erinevate tootjate seadmed, mis omavad sama profiili, peavad üksteisega hõlpsasti töötama. Profiilid koosnevad omakorda teenustest, teenused omadustest, mida täiustatakse deskriptoritega. Üldiselt võib see välja näha nii:

Näiteks vaatame südame löögisageduse monitori profiili diagrammi (fitness randmevara). See koosneb kahest teenusest ja mitmest omadusest. Selgub koheselt profiili hierarhia. Kontrollpunkti omadus nullib kalorikulu koguarv.

1. Südame löögisageduse teenus sisaldab kolme omadust (0x180D):
    a) Kohustuslik südame löögisageduse omadus (0х2A37)
    b) Valikuline kehaanduri positsiooni omadus (0x2A38)
    c) Tingimuslik südame löögisageduse kontrollpunkti omadus (0x2A39)
2. Aku teenus (0x180F):
    a) Kohustuslik aku taseme omadus (0x2A19)

UUID

Kuna me peame ühemõtteliselt viitama profiilielementidele (teenused, omadused ja descriptorid), tuleb need kuidagi nummerdada. Selleks tutvustatakse mõistet Universally Unique ID (UUID) ehk Üksikasjalik Unikaalne Identifikaator. Iga rea sulgudes ongi märgitud UUID. Siin on üks eripära. UUID-de jaoks otsustati kasutada 16- ja 128-bitiseid koode. Miks, küsite? BLE protokollis allub kõik energiakokkuhoiule. Seetõttu on 16-bitine mõõt tõenäoliselt mõistlik. Väga tõenäoliselt ei tule tulevikus üle 65 tuhande erilise teenuse ja omaduse loomist. Praegu on kõik, mis suudeti, juba arvesse võetud (mäletate kust see tuleb — „ta on ka teid arvesse võtnud“ :-)) Nummerdatud elemendid. profiilidest, teenustest, omadustest ja descriptoritest võite vaadata linkide kaudu.

Kuid ma arvan, et kõik mäletavad lugu 4-byte IP aadressidest internetis. Alguses arvasime, et see on piisav, aga nüüd ei suuda me kuidagi 6-byte aadressile üle minna. Et vältida selle vea kordamist ja anda ruumi nokitsejatele, otsustas SIG kohe tutvustada ka 128-bitiseid UUID-sid. See meenutab mulle litsentseerimata 433MHz sagedust, mis anti erinevate Kuliibinite suva kasutada. Meie puhul anti 128-bitine teenuste ja omaduste identifikaator samuti kellegi kätesse. See tähendab, et võime oma teenuste ja seadmete jaoks kasutada praktiliselt mis tahes 128-bitist väärtust. Samas on tõenäosus sarnase UUID genereerimiseks olematu.

Tegelikult on lühikestel 16-bitistel UUID-del oma laiendus 128-bitistele väärtustele. Spetsifikatsioonis nimetatakse seda laiendust Bluetooth Base UUID-ks ja selle väärtus on 00000000-0000-1000-8000-00805F9B34FB. Näiteks kui 16-bitise atribuutide UUID väärtus on 0x1234, siis vastav 128-bitine UUID on 00001234-0000-1000-8000-00805F9B34FB. Ja toimetatakse ka vastav valem:

                                128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID

Kust see maagiline number pärineb, ei ole mulle teada. Kui mõni lugejatest teab — kirjutage kommentaaridesse (kasutaja nimega Sinopteek on juba seda teinud. Vaata kommentaare). Mis puutub 128-bitiste UUID-de genereerimisse, siis põhimõtteliselt saab kasutada spetsiaalset generaatorit, mis see teie eest teeb.

ATT-d GATT-d…

Kuna edasi algab kõige huvitavam osa. Meenutan, et ATT põhineb kliendi-serveri suhtlemisel. Praegu vaatame serveri seadmeid. See sisaldab teavet, nagu anduri väärtused, valguse lüliti olek, asukohateave jne. Nüüd, kui kõik meie „paraadi osalised“ on nummerdatud, tuleb need sättida seadme mällu. Selleks paigutame nad tabelisse, mida nimetatakse atribuutide tabeliks. Pidage seda meeles. See on BLE südameasukoht. Just seda me edaspidi uurime. Nüüd nimetame iga rida atribuudiks. See tabel asub protokolli sügavustes ja tavaliselt pole meil sellele otsest ligipääsu. Me algatame selle ja pöördume selle poole, kuid mis seal sees toimub, on meie silmade eest seitsme pitseri taga.

Vaatame pilti spetsifikatsioonist, kuid enne seda tahan kohe tähelepanu juhtida terminite sagedasele segadusele, nimelt descriptors. Deskriptorite roll on täiendada omaduse kirjeldust. Kui on vaja laiendada selle võimalusi, siis kasutatakse deskriptorit. Need on samuti atribuudid ja koos teenuste ja omadustega asuvad need atribuutide tabelis. Me käsitleme neid üksikasjalikult artikli teises osas. Kuid mõnikord kutsutakse deskriptoriteks atribuutide tabelis rida number. Seda tuleb silmas pidada. Et mitte segadusse minna, kasutame nende eesmärkide jaoks mõistet „atribuutide näidik“.


Nii et atribuut on diskreetne väärtus, millel on järgmised omadused, millega see on seotud:
1. Atribuudi näidik (Attribute Handle) — see on tabeli indeks, mis vastab atribuudile.
2. Atribuudi tüüp (Attribute Type) — see on UUID, mis kirjeldab selle tüüpi.
3. Atribuudi väärtus (Attribute Value) — need on andmed, mida indekseeritakse atribuudi näidiku järgi.
4. Atribuutide õigused (Attribute Permissions) — see on osa atribuudist, õigused, mida ei saa lugeda ega kirjutada atribuutide protokolli kaudu.

Kuidas seda mõista? Atribuudi näidik on, tinglikult öeldes, selle number meie tabelis.
See lubab kliendil viidata atribuudile lugemis- või kirjutamissoovides. Me saame numereerida oma read (atribuudid) vahemikus 0x0001 kuni 0xFFFF. Meie seoses raamaturiidaga on see kaardi number paberkatkestustes. Sarnaselt raamatukogu kataloogiga on kaardid paigutatud numbrite kasvava järjestuse järgi. Iga järgmise rea number peab olema suurem kui eelmine. Nagu raamatukogus, võivad mõned kaardid vahel kaduma minna, nii et ka meie ridade numeraatsioonis võivad olla vahed. See on lubatud. Peamine on, et need läheksid kasvavas järjekorras.

Atribuudi tüüp määrab, mis see atribuut endast kujutab. Sarnaselt C-keelele,
kus on boolean, numbrilised muutujad ja stringid, nii ka siin. Atribuudi tüübi põhjal saame teada,
millega on tegu ja kuidas me selle atribuudiga edasi töötame. Allpool vaatleme mõnda spetsiifilist atribuudi tüüpi. Näiteks "teenuse deklaratsioon" (0x2800), "omaduste deklaratsioon" (0x2803), "deskriptorite deklaratsioon" (0x2902).

Atribuudi väärtus on tegelikult tema väärtus, vabandust tautoloogia pärast. Kui atribuudi tüüp on string, siis võib atribuudi väärtus olla näiteks lause "Tere maailm!!!". Kui atribuudi tüüp on "teenuse deklaratsioon", siis on tema väärtuseks teenus ise. Ja vahel on see teave selle kohta, kust leida teisi atribuute ja nende omadusi.

Atribuutide õigused võimaldavad serveril mõista, kas lugemine või kirjutamine on lubatud.
Pange tähele, et need õigused kehtivad ainult atribuudi väärtusele, mitte viitamisele, tüübile ja iseendale õiguste väljal. See tähendab, et kui atribuudi kirjutamine on lubatud, võime näiteks muuta rida "Tere maailm!!!" read "Tere hommikust". Kuid me ei saa keelata uue rea kirjutamist ega muuta atribuudi tüüpi ja tähistada rida kui "teenuse deklaratsioon". Kui klient pöördub serveri poole, küsib klient tema atribuute. See võimaldab kliendil teada saada, mida server saab pakkuda. Kuigi pole tingimata vajalik lugeda ja kirjutada väärtusi.

Kuidas see välja näeb

GATTi kontseptsioon seisneb attribuutide rühmitamises atribuutide tabelis väga spetsiifilisel ja loogilisel viisil. Vaatame lähemalt südame löögisageduse profiili, mis on toodud allpool. Selle tabeli kõige vasakpoolne veerg on valikuline. See lihtsalt kirjeldab, millega see rida (attribuut) on. Kõik ülejäänud veerud on meile juba tuttavad.

Iga grupi ülaosas on meil alati teenuse deklareerimise atribuut. Selle tüüp on alati 0x2800 ja viide sõltub sellest, kui palju atribuute tabelis juba on. Selle lubamise õigused on alati ainult lugemiseks, ilma igasuguse autentimise või volituse kontrollita. Nendest mõistetest räägime natuke hiljem. Väärtus on veel üks UUID, mis määratleb, mis teenus see on. Tabelis on väärtus 0x180D, mida Bluetooth SIG määratleb kui südame löögisageduse teenust.

Teenuse deklareerimist järgib omaduse deklareerimine. Selle vorm on sarnane teenuse deklareerimisele. Selle UUID on alati 0x2803 ja lubamise õigused on samuti alati ainult lugemiseks, ilma igasuguse autentimise või volituse kontrollita. Vaatame atribuudi väärtuse välja, mis sisaldab teatud andmeid. See sisaldab alati viidet, UUID-d ja omaduste kogumit. Need kolm elementi kirjeldavad järgmise omaduse väärtuse deklareerimist. Viide tähistab loomulikult omaduse väärtuse deklareerimise asukohta atribuutide tabelis. UUID kirjeldab, millist tüüpi teavet või väärtust me oodata võime. Näiteks temperatuuri väärtus, valguslüliti olek või muu suvaline väärtus. Ja lõpuks omadused, mis kirjeldavad, kuidas saab omaduse väärtusega suhelda.

Siin ootab meid veel üks konks. See on seotud atributide õiguste ja omaduste omadustega. Vaatame pilti bitivälja omadustest spetsifikatsioonist.

Nagu näete, on siin olemas ka väljadel lugemise ja kirjutamise võimalused. Te võite küsida, miks meil on atribuudile ja omadusele lugemise/kirjutamise õigused.
Kas on omaduse väärtuse lugemise / kirjutamise reeglid? Kas need ei peaks alati olema ühesugused? Asi on selles, et omaduste väärtuse omadused on tegelikult lihtsalt soovitused kliendile, mida kasutatakse GATT-is ja rakendustasandil. Need on lihtsalt vihjed, mida klient võib omaduse kuulutamisest oodata. Uurime seda lähemalt. Milliseid õigusi atribuudi juures on?

1. Access rights:
     — lugemine
     — kirjutamine
     — lugemine ja kirjutamine
2. Authentication rights:
     — autentimine vajalik
     — autentimine ei ole vajalik
3. Authorization rights:
     — autoriseerimine vajalik
     — autoriseerimine ei ole vajalik

Peamine erinevus atribuudi õiguste ja omaduste vahel on see, et esimesed käivad serverite kohta, teised aga klientide kohta. Serveril võib olla lubatud lugeda omaduse väärtust, kuid samas võib olla nõue autentimise või autoriseerimise osas. Seetõttu, kui klient küsib omaduste kohta, saame teada, et lugemine on lubatud. Kuid lugemise katse korral saame vea. Seega võib julgelt öelda, et õigused on omadustest prioriteetsed. Me ei saa teada, millised õigused atribuudi juures on, kliendi poolt.

Deskriptor

Naaseme meie tabelisse. Pärast omaduse väärtuse kuulutamist võivad järgneda järgmised atribuudi kuulutused:
1. Uus omaduse kuulutamine (teenuses võib olla palju omadusi)
2. Uue teenuse deklaratsioon (tabelis võib neid olla palju)
3. Deskriptorite kuulutamine

Juhul, kui räägime südame löögisageduse mõõtmisest, kaasneb meie tabelis parameetri väärtuse väljakuulutamisega ka kirjelduse väljakuulutamine. Kirjeldus on atribuuti, mis sisaldab täiendavat teavet parameetri kohta. On olemas mitu tüüpi kirjeldusi. Nendest räägime lähemalt artikli teises osas. Praegu keskendume vaid kliendi parameetri konfiguratsiooni kirjeldusele (Client Characteristic Configuration Descriptor — CCCD), mille UUID on 0x2902. Selle kirjelduse abil saab klient serveris aktiveerida näitamise või teavitamise. Nende kahe vahel on väike, kuid siiski oluline erinevus. Teavitamine ei nõua kliendi poolt vastuvõtmise kinnitust. Näitamine nõuab seda küll, kuid toimub GATT tasemel, jõudmata rakenduse tasemele. Miks nii, võite te küsida? Kahjuks ei tea ma sellele vastust. Ütlen vaid, et Nordic'i spetsialistid soovitavad kasutada teavitamist. Eriti, et paketi terviklikkuse kontroll (CRC abil) toimub mõlemas juhtumis.

Kokkuvõte

Artikli lõpus tahaksin rääkida ühest asjast. Viimane tabel on natuke segane. Kuid ma peatun sellel, kuna see on toodud artiklis, millele põhinen. Artikli teises osas kavatsema süveneda BlueTooth 4.0 spetsifikatsiooni. Seal ootavad meid täpsemad skeemid ja joonised. Artikli kolmandas osas tahaksin analüüsida logi, mis on saadud Wireshark programmi abil ühelt seadmel ja näha „otse“ kogu seda teooriat, mida koos uurime.

Rühma ettevõtte töötaja „Caesar Satellite“
Vladimir Pecherski

Allikas: habr.com