BLE pod mikroskopom (ATT a GATT...)
Časť 1, prehľad
Už uplynulo dosť veľa času od vydania prvej špecifikácie Bluetooth 4.0. A aj keď je téma BLE veľmi zaujímavá, stále odradzuje mnohých vývojárov svojou zložitostí. V predchádzajúcich článkoch som sa venoval najmä najnižšiemu levelu Link Layer a Physical Layer. To umožnilo vyhnúť sa takým zložitým a zamotaným pojmom ako protokol atribútov (ATT) a všeobecný profil atribútov (GATT). Nemáme však na výber, bez pochopenia týchto pojmov nie je možné vyvíjať kompatibilné zariadenia. Dnes by som sa s vami rád podelil o tieto poznatky. V článku sa budem opierať o pre začiatočníkov na stránke Nordic. Tak poďme na to.
Prečo je všetko také zložité?
Podľa môjho názoru bolo hneď jasné, že ovládanie zariadení prostredníctvom smartfónov je veľmi perspektívna a dlhodobá téma. Preto ju rozhodli štruktúrovať hneď od začiatku a maximálne. Aby výrobcovia rôznych gadgetov nevymýšľali svoje protokoly, ktoré by potom neboli kompatibilné. Odtiaľ prichádza zložitosti. Už v prvej fáze sa do protokolu BLE snažili vtesnať všetko, čo len bolo možné. A nezáležalo na tom, či to bude v budúcnosti užitočné alebo nie. Okrem toho bola predpokladaná možnosť rozšírenia zoznamu zariadení do budúcnosti.
Pozrime sa na obrázok, kde je nakreslená schéma protokolu BLE. Skladá sa z niekoľkých vrstiev. Najnižšia, fyzická vrstva (PHY) zodpovedá za rádiový kanál zariadenia. Link Layer (LL) obsahuje celú sekvenciu bytov v prenášanom správe. V predchádzajúcich článkoch sme sa venovali práve jemu. Host Controller Interface (HCI) — je protokol výmeny medzi vrstvami alebo čipmi BLE, ak je Controller a Host implementovaný na rôznych čipoch. Za formovanie paketov, delenie na rámce, kontrolu chýb a zber paketov zodpovedá Logical Link Control and Adaptation Protocol (L2CAP). Za šifrovanie paketov zodpovedá Security Manager Protocol (SMP). Profil všeobecného prístupu (GAP) zodpovedá za počiatočný výmenný dát medzi zariadeniami, aby určil „Kto je kto“. K nemu patrí aj skenovanie a reklama. V tomto článku sa zastavím pri dvoch zvyšných častiach protokolu — GATT a ATT. GATT je nadstavbou nad ATT, preto sú silno prepojené.
Aby som zjednodušil rozprávanie, rád by som uviedol analógiu. Rád som ju niekde počul a chcel by som ju podporiť. Predstavte si BLE zariadenie ako knižnicu s niekoľkými poličkami. Každá polička predstavuje samostatnú tému. Napríklad, máme poličky s fantastikou, matematikou, encyklopédiami. Na každej poličke sú knihy zaoberajúce sa danou témou. A v niektorých knihách sú dokonca papierové záložky so záznamami. Okrem toho máme malý papierový katalóg všetkých kníh. Ak si pamätáte školské knižnice — to je úzky zásuvný box s papierovými kartičkami. Pri takejto analógii je skriňa profilom nášho zariadenia. Poličky sú služby, knihy sú charakteristiky a katalóg je tabuľka atribútov. Záložky v knihách sú deskriptory, o ktorých sa ešte podrobnejšie zmienim neskôr.
Všetci, ktorí vyvíjali zariadenia, vedia, že v mnohých projektoch sa objavujú podobné kusy kódu. Faktom je, že mnohé zariadenia majú podobnú funkcionalitu. Napríklad, ak zariadenia fungujú na batérie, problém nabíjania a kontroly ich úrovne bude rovnaký. To isté platí aj pre senzory. Vlastne, objektovo orientovaný prístup v programovaní "umožňuje vytvárať objekty, ktoré spájajú vlastnosti a správanie do samostatnej jednoty, ktorú možno potom opakovane použiť". Podľa môjho názoru sa v BLE pokúsili o podobný prístup. Skupina Bluetooth Special Interest Group (SIG) vyvinula profily. Zariadenia od rôznych výrobcov, ktoré majú rovnaké profily, by mali bez problémov fungovať spolu. Profily sa zasa skladajú zo služieb a služby z charakteristík, doplnených o deskriptory. Všeobecne to môže vyzerať takto:
Na príklade zvážme schému profilu heart rate monitor (fitness náramok). Skladá sa z dvoch služieb a niekoľkých charakteristík. Z nej je hneď zrejmá hierarchia profilu. Charakteristika kontrolného bodu resetuje celkový počet spálených kalórií na nulu.
1. Služba srdcovej frekvencie obsahuje tri charakteristiky (0x180D):
a) Povinná charakteristika srdcovej frekvencie (0x2A37)
b) Voliteľná charakteristika polohy snímača tela (0x2A38)
c) Podmienená charakteristika kontrolného bodu srdcovej frekvencie (0x2A39)
2. Služba správy batérie (0x180F):
a) Povinná vlastnosť úrovne nabitia batérie (0x2A19)
UUID
Aby sme mohli jednoznačne odkazovať na prvky profilu (služby, vlastnosti a deskriptory), musíme ich nejakým spôsobom očíslovať. Na tento účel sa zavádza pojem Universally Unique ID (UUID) alebo Univerzálny jedinečný identifikátor. V zátvorke každej riadku je uvedený práve UUID. A tu je jedna špeciálnosť. Pre UUID sa rozhodlo použiť kód dlhý 16 a 128 bitov. Prečo, pýtate sa? V protokole BLE je všetko podriadené úspore energie. Preto je veľkosť 16 bitov celkom rozumná. ťažko sa v blízkej budúcnosti vytvorí viac ako 65 tisíc jedinečných služieb a vlastností. V súčasnosti je všetko, čo mohli, už spočítané (pamätajte, odkiaľ to je — „on a vás spočítal“ :-)) Očíslované prvky , , a môžete si pozrieť cez odkazy.
Avšak, myslím, že si všetci pamätajú príbeh so 4 bajtmi IP adresy na internete. Najprv si mysleli, že to stačí, a teraz sa stále nemôžeme prepnúť na 6-bajtovú adresu. Aby sme neopakovali túto chybu a dali priestor šikovným rukám domácich majstrov, SIG sa ihneď rozhodla zaviesť aj 128-bitové UUID. Osobne mi to pripomína nelicencované pásmo 433 MHz, ktoré bolo ponechané voľným rukám rôznych kutilov od rádiového kanála. V našom prípade bol 128-bitový identifikátor služieb a vlastností odovzdaný na voľné použitie. To znamená, že pre svoje služby a zariadenia môžeme použiť prakticky akúkoľvek 128-bitovú hodnotu. Aj tak pravdepodobnosť vymyslieť rovnaké UUID sa blíži nule.
V skutočnosti majú krátke 16-bitové UUID svoje rozšírenie na 128-bitovú hodnotu. V špecifikácii sa toto rozšírenie nazýva Bluetooth Base UUID a má hodnotu 00000000-0000-1000-8000-00805F9B34FB. Ak má napríklad 16-bitové UUID atribútu hodnotu 0x1234, ekvivalentné 128-bitové UUID bude mať hodnotu 00001234-0000-1000-8000-00805F9B34FB. A dokonca je uvedený zodpovedajúci vzorec:
128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID
Odkiaľ sa vzalo toto magické číslo, neviem. Ak niekto z čitateľov vie — nech napíše v komentároch (Používateľ s nickom Sinopteek už to urobil. Pozrite si komentáre). Čo sa týka vymýšľania 128-bitových UUID, v zásade sa dá využiť špeciálny , ktorý to urobí za vás.
ATT a GATT…
Teraz sa začína to najzaujímavejšie. Pripomínam, že ATT je založený na klient-server vzťahu. Teraz sa pozeráme na zariadenie servera. Obsahuje informácie ako hodnoty senzorov, stav svetelného vypínača, údaje o polohe a podobne. Teraz, keď sú všetci „účastníci nášho sprievodu“ očíslovaní, je potrebné ich nejakým spôsobom umiestniť do pamäte zariadenia. Na tento účel ich vložíme do tabuľky, ktorá sa nazýva tabuľka atribútov. Dôkladne si to zapamätajte. To je srdce BLE. Presne to budeme skúmať ďalej. Každý riadok teraz budeme nazývať atribútom. Táto tabuľka sa nachádza hlboko v zásobníku a zvyčajne nemáme priamy prístup k nej. Inicializujeme ju a oslovujeme ju, ale čo sa tam deje vo vnútri, je pred nami skryté.
Pozrime sa na obrázok zo špecifikácie, avšak predtým chcem zdôrazniť časté zmätky v terminológii, najmä vo vzťahu k deskriptorom. Úlohou deskriptoru je doplniť popis charakteristiky. Keď je potrebné rozšíriť jej možnosti, používajú sa deskriptory. Tieto sú tiež atribútmi a rovnako, spolu so službami a charakteristikami, sa nachádzajú v tabuľke atribútov. Podrobne ich preberieme v druhej časti článku. Avšak niekedy sa deskriptory nazývajú aj číslo riadku v tabuľke atribútov. To je dobré mať na pamäti. Aby sme sa nezmýlili, pre tieto účely budeme používať termín „ukazovateľ atribútu“.
Takže atribút je diskrétna hodnota, ktorá má nasledujúce vlastnosti súvisiace s ňou:
1. Ukazovateľ atribútu (Attribute Handle) — to je index tabuľky, ktorý zodpovedá atribútu
2. Typ atribútu (Attribute Type) — to je UUID, ktorý popisuje jeho typ
3. Hodnota atribútu (Attribute Value) — to sú údaje, ktoré sú indexované ukazovateľom atribútu
4. Oprávnenia atribútov (Attribute Permissions) — to je časť atribútu s oprávneniami, ktoré nemôžu byť čítané alebo zapisované pomocou protokolu atribútov
Ako to všetko chápať? Ukazovateľ atribútu — to je, povedzme, jeho číslo v našej tabuľke.
Umožňuje klientovi odkazovať na atribút v dotazoch na čítanie alebo zápis. Môžeme číslovať naše riadky (atribúty) od 0x0001 po 0xFFFF. V našej asociácii s knižnicou — je to číslo kartičky v papierovom katalógu. Podobne ako v knižničnom katalógu, kartičky sú usporiadané podľa rastúceho čísla. Číslo každého nasledujúceho riadku musí byť vyššie ako predchádzajúce. Ako v knižnici, niekedy sa stratí niekoľko kartičiek, tak aj u nás — v číslovaní riadkov môžu byť prázdne miesta. To je povolené. Hlavné je, aby išli vzostupne.
Typ atribútu určuje, čo predstavuje daný atribút. Podobne ako v jazyku C,
kde sú boolovské, číselné premenné a reťazce, tak aj tu. Podľa typu atribútu zistíme,
s čím máme dočinenia a ako s týmto atribútom ďalej pracovať. Nižšie preskúmame niektoré špecifické typy atribútov. Napríklad „servisné vyhlásenie“ (0x2800), „vyhlásenie charakteristiky“ (0x2803), „vyhlásenie popisovača“ (0x2902).
Hodnota atribútu — to je samotná jeho hodnota, prepáčte za tautológiu. Ak je typ atribútu reťazec, tak hodnotou atribútu môže byť napríklad slogan „Hello World !!!“. Ak je typ atribútu „servisné vyhlásenie“, tak jeho hodnotou je samotný servis. A niekedy je to informácia o tom, kde nájsť ďalšie atribúty a ich vlastnosti.
Povolenia atribútov umožňujú serveru pochopiť, či je povolený prístup na čítanie alebo zápis.
Všimnite si, že tieto povolenia sa uplatňujú iba na hodnotu atribútu, nie na ukazovateľ, typ a samotné pole povolení. T.j. ak je povolený zápis atribútu, môžeme napríklad zmeniť vetu „Hello World !!!“ na „Good morning“. Nemôžeme však zakázať zápis novej vety, ani zmeniť typ atribútu a definovať vetu ako „servisné vyhlásenie“. Pri prístupe klienta k serveru, klient žiada jeho atribúty. To umožňuje klientovi zistiť, čo môže server poskytnúť. Hoci nie je nevyhnutné čítať a zapisovať hodnoty.
Ako to vyzerá
Koncept GATT spočíva v tom, aby skupinoval atribúty v tabuľke atribútov spolu v veľmi špecifickom a logickom poriadku. Pozrime sa bližšie na profil srdcovej frekvencie uvedený nižšie. Najľavší stĺpec tejto tabuľky nie je povinný. Iba nám opisuje, čím je tento riadok (atribút). Všetky ostatné stĺpce sú nám už známe.
V hornej časti každej skupiny máme vždy atribút oznámenia služby. Jeho typ je vždy rovný 0x2800 a ukazovateľ závisí od toho, koľko atribútov už je prítomných v tabuľke. Jeho oprávnenia sú vždy dostupné len na čítanie, bez akejkoľvek autentifikácie alebo autorizácie. O týchto pojmoch sa porozprávame neskôr. Hodnota je ďalší UUID, ktorý určuje, čo je táto služba. V tabuľke je hodnota rovná 0x180D, čo definoval Bluetooth SIG ako službu srdcovej frekvencie.
Nasledujúcim je oznámenie charakteristiky. Po forme je podobné oznámeniu služby. Jeho UUID má vždy hodnotu 0x2803 a oprávnenia sú taktiež vždy dostupné len na čítanie bez akejkoľvek autentifikácie alebo autorizácie. Pozrime sa na pole hodnota atribútu, ktoré obsahuje niektoré dáta. Vždy obsahuje ukazovateľ, UUID a sadu vlastností. Tieto tri prvky opisujú nasledovné oznámenie hodnoty charakteristiky. Ukazovateľ prirodzene označuje miesto oznámenia hodnoty charakteristiky v tabuľke atribútov. UUID popisuje, aký typ informácií alebo hodnoty môžeme očakávať. Napríklad hodnota teploty, stav vypínača svetla alebo nejaká iná náhodná hodnota. A nakoniec vlastnosti, ktoré opisujú, ako môžeme interagovať s charakteristickou hodnotou.
Tu nás čaká ďalší skrytý problém. Ten súvisí s oprávneniami atribútov a vlastnosťami charakteristík. Pozrime sa na obrázok vlastností bitového poľa zo špecifikácie.
Ako vidíte, sú tu aj polia, ktoré umožňujú čítanie a zápis. Môžete sa pýtať, prečo máme oprávnenia na čítanie/zápis pre atribút a vlastnosť.
Čítanie/zápis hodnoty atribútu? Nemali by byť vždy rovnaké? V skutočnosti sú atribúty hodnoty len odporúčaniami pre klienta, ktoré sa používajú v GATT a aplikačných vrstvách. Ide len o náznaky toho, čo môže klient očakávať od atribútu deklarácie charakteristiky. Poďme sa na to pozrieť podrobnejšie. Aké typy oprávnení má atribút?
1. Oprávnenia prístupu:
— čítanie
— zápis
— čítanie a zápis
2. Oprávnenie autentifikácie:
— autentifikácia je potrebná
— autentifikácia nie je potrebná
3. Oprávnenie autorizácie:
— autorizácia je potrebná
— autorizácia nie je potrebná
Hlavný rozdiel medzi oprávneniami atribútov a vlastnosťami charakteristík spočíva v tom, že prvé sa týkajú serverov, zatiaľ čo druhé klientov. Server môže mať oprávnenie čítať hodnotu charakteristiky, ale môže byť požiadavka na autentifikáciu alebo autorizáciu. Preto pri žiadosti klienta o vlastnosti charakteristiky zistíme, že čítanie je povolené. Ale pri pokuse o čítanie dostaneme chybu. Preto môžeme smelo povedať, že oprávnenia majú prednosť pred vlastnosťami. Oprávnenia atribútu z pohľadu klienta nezískame.
Deškriptory
Vrátime sa k našej tabuľke. Po deklarácii hodnoty charakteristiky sú možné nasledujúce deklarácie atribútov:
1. Nová deklarácia charakteristiky (v službe môže byť mnoho charakteristík)
2. Nové vyhlásenie služby (v tabuľke ich môže byť viac)
3. Deklarácia deškriptora
V prípade popisu charakteristiky merania frekvencie srdcových kontrakcií, v našej tabuľke, je vyhlásenie hodnoty charakteristiky sprevádzané vyhlásením deskriptora. Deskriptor je atribút s dodatočnými informáciami o charakteristike. Existuje niekoľko druhov deskriptorov. O nich podrobne hovoríme v druhej časti tohto článku. Teraz sa však dotkneme len deskriptora konfigurácie charakteristík zákazníka (Client Characteristic Configuration Descriptor – CCCD). Má UUID rovné 0x2902. Pomocou tohto deskriptora má zákazník možnosť zapnúť na serveri indikáciu alebo notifikáciu. Rozdiel medzi nimi je malý, ale predsa je tu. Notifikácia nevyžaduje potvrdenie prijatia zo strany zákazníka. Indikácia to však vyžaduje, hoci sa deje na úrovni GATT, nedosahujúc úroveň aplikácie. Prečo je to tak, pýtate sa? Nuž, to mi nie je známe. Môžem iba povedať, že odborníci z Nordic odporúčajú používať notifikáciu. O to viac, že kontrola integrity paketu (pomocou CRC) prebieha v oboch prípadoch.
Záver
Na konci článku by som chcel povedať niečo o tom. Posledná tabuľka je trochu mätúca. Avšak zastavil som sa pri nej, pretože sa uvádza v , na ktorú sa opieram. V druhej časti svojho článku mám v úmysle hĺbkovo sa venovať špecifikácii Bluetooth 4.0. Tam nás čakajú presnejšie schémy a obrázky. V tretej časti by som chcel preskúmať log získaný pomocou programu Wireshark z jedného z zariadení a vidieť „naživo“ celú tú teóriu, ktorú spolu študujeme.
Zamestnanec Skupiny Spoločností
Pečerských Vladimír
Zdroj: habr.com
