BLE pod mikroskopom (ATTы GATTы…)
Časť 1, prehľad
Od vydania prvej špecifikácie pre Bluetooth 4.0 už uplynula pomerne dlhá doba. A hoci je téma BLE veľmi zaujímavá, stále odrádza mnohých vývojárov kvôli svojej zložitosti. Vo svojich predchádzajúcich článkoch som sa venoval najmä najnižšej úrovni, Link Layer a Physical Layer. To nám umožnilo vyhnúť sa tomu, aby sme sa museli uchýliť k takým zložitým a mätúcim konceptom, ako je Attribute Protocol (ATT) a General Attribute Profile (GATT). Nie je však kam ísť, bez ich pochopenia je nemožné vyvinúť kompatibilné zariadenia. Dnes by som sa s vami rád podelil o tieto poznatky. Vo svojom článku sa budem spoliehať na pre začiatočníkov zo severského webu. Tak poďme na to.
Prečo je všetko také ťažké?
Podľa mňa bolo hneď jasné, že správa zariadení cez smartfóny je veľmi perspektívna a dlhotrvajúca téma. Preto sa ho rozhodli okamžite a na maximum štruktúrovať. Aby výrobcovia rôznych gadgetov neprišli s vlastnými protokolmi, ktoré potom budú nekompatibilné. Preto tá náročnosť. Už v prvej fáze sa snažili do protokolu BLE vtesnať všetko možné. A nezáleží na tom, či to bude užitočné neskôr alebo nie. Okrem toho počítali s možnosťou rozšírenia zoznamu zariadení do budúcnosti.
Pozrime sa na obrázok, kde je nakreslený diagram protokolu BLE. Skladá sa z niekoľkých vrstiev. Najnižšia fyzická vrstva (PHY) je zodpovedná za rádiový kanál zariadenia. Link Layer (LL) obsahuje celú sekvenciu bajtov v prenášanej správe. V predchádzajúcich článkoch sme študovali presne toto. Host Controller Interface (HCI) je výmenný protokol medzi vrstvami BLE alebo čipmi, ak sú radič a hostiteľ implementované na rôznych čipoch. Logical Link Control and Adaptation Protocol (L2CAP) je zodpovedný za tvorbu paketov, rámcovanie, kontrolu chýb a zostavovanie paketov. Za šifrovanie paketov je zodpovedný protokol SMP (Security Manager Protocol). General Access Profile (GAP) je zodpovedný za počiatočnú výmenu údajov medzi zariadeniami na určenie „kto je kto“. Zahŕňa aj skenovanie a inzerciu. V tomto článku sa zameriam na dve zostávajúce časti protokolu – GATT a ATT. GATT je nadstavbou ATT, takže sú úzko prepojené.
Pre zjednodušenie príbehu by som sa chcel obrátiť na prirovnanie. Niekde som to počul a rád by som to podporil. Predstavte si zariadenie BLE ako knižnicu s niekoľkými policami. Každá polica je samostatná téma. Napríklad máme police so sci-fi, matematikou a encyklopédiami. Na každej poličke sú knihy s určenou témou. A niektoré knihy majú dokonca papierové záložky s poznámkami. Okrem toho máme malý papierový katalóg všetkých kníh. Ak si pamätáte, školské knižnice sú úzka krabica s papierovými kartami. S touto analógiou je skriňa profilom nášho zariadenia. Police 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 tiež budem hovoriť podrobnejšie neskôr.
Každý, kto vyvíja zariadenia, vie, že mnoho projektov má podobné časti kódu. Faktom je, že mnohé zariadenia majú podobnú funkčnosť. Napríklad, ak sú zariadenia napájané batériami, problém nabíjania a monitorovania ich úrovne bude rovnaký. To isté platí pre senzory. Vlastne objektovo orientovaný prístup k programovaniu „Poskytuje schopnosť vytvárať objekty, ktoré kombinujú vlastnosti a správanie do samostatného spojenia, ktoré je potom možné znova použiť“. Podľa môjho názoru sa BLE pokúsil o podobný prístup. Profily vyvinula Bluetooth Special Interest Group (SIG). Zariadenia od rôznych výrobcov, ktoré majú rovnaké profily, by mali medzi sebou spolupracovať bez problémov. Profily zase pozostávajú zo služieb a služieb charakteristík doplnených o deskriptory. Vo všeobecnosti to môže vyzerať takto:
Zoberme si napríklad profilovú schému monitora srdcového tepu (fitness náramku). Pozostáva z dvoch služieb a niekoľkých charakteristík. Hierarchia profilu je z neho okamžite jasná. Charakteristika kontrolného bodu vynuluje celkový výdaj kalórií.
1. Služba srdcového tepu zahŕňa tri charakteristiky (0x180D):
a) Povinná charakteristika srdcovej frekvencie (0x2A37)
b) Voliteľná charakteristika polohy telesného snímača (0x2A38)
c) Podmienené charakteristiky kontrolného bodu srdcového tepu (0x2A39)
2. Údržba batérie (0x180F):
a) Povinná charakteristika úrovne nabitia batérie (0x2A19)
UUID
Aby sme mali jedinečný prístup k prvkom profilu (službám, charakteristikám a deskriptorom), musíme ich všetky nejako očíslovať. Na tento účel sa zavádza pojem, ako je univerzálne jedinečné ID (UUID) alebo univerzálny jedinečný identifikátor. UUID je uvedené v zátvorkách každého riadku. A je tu jedna zvláštnosť. Pre UUID sme sa rozhodli použiť kód s dĺžkou 16 a 128 bitov. Prečo sa pýtaš? V protokole BLE je všetko o šetrení energie. Preto je rozmer 16 bitov celkom rozumný. Je nepravdepodobné, že v blízkej budúcnosti ich vznikne viac ako 65 tis. jedinečné služby a vlastnosti. Momentálne už bolo spočítané všetko, čo mohli (nezabudnite, odkiaľ sa to vzalo - „aj vás počítal“ :-)) Očíslované prvky , , и môžete si pozrieť odkazy.
Myslím si však, že každý si pamätá príbeh so 4 bajtmi IP adries na internete. Najprv sme si mysleli, že to stačí, ale teraz stále nemôžeme prejsť na 6-bajtovú adresu. Aby sa táto chyba nezopakovala a dala voľný priechod hravým rukám domácich majstrov, SIG sa okamžite rozhodol zaviesť 128-bitové UUID. Mne osobne to pripomína nelicencované pásmo 433 MHz, ktoré dostali z rádia všelijakí Kulibinovci. V našom prípade bol vychovaný 128-bitový identifikátor služieb a charakteristík. To znamená, že pre naše služby a zariadenia môžeme použiť takmer akúkoľvek 128-bitovú hodnotu. Napriek tomu je pravdepodobnosť, že prídete s rovnakým UUID, nulová.
Krátke 16-bitové UUID majú v skutočnosti 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ý atribút UUID hodnotu 0x1234, potom ekvivalentný 128-bitový UUID bude mať hodnotu 00001234-0000-1000-8000-00805F9B34FB. A dokonca aj zodpovedajúci vzorec je daný:
128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID
Neviem, odkiaľ sa vzalo toto magické číslo. Ak niekto z čitateľov vie, nech napíše do komentárov (Už to urobil používateľ s nickom Sinopteek. Pozri komentáre). Pokiaľ ide o vymýšľanie 128-bitových UUID, v zásade môžete použiť špeciálne kto to urobí za vás.
ATTy GATTy...
V skutočnosti potom začína zábava. Pripomínam, že ATT je založené na vzťahu klient-server. Teraz sa pozeráme na serverové zariadenie. Obsahuje informácie, ako sú hodnoty senzorov, stav spínača svetiel, údaje o polohe atď. Teraz, keď sú všetci „účastníci nášho sprievodu“ očíslovaní, musíme ich nejako umiestniť do pamäte zariadenia. Aby sme to dosiahli, umiestnime ich do tabuľky s názvom tabuľka atribútov. Toto si dobre zapamätajte. Toto je samotné srdce BLE. Toto budeme ďalej uvažovať. Teraz nazveme každý riadok atribútom. Tento stôl sa nachádza hlboko v stohu a spravidla k nemu nemáme priamy prístup. Inicializujeme ho a pristupujeme k nemu, ale to, čo sa deje vo vnútri, je pred nami skryté za siedmimi pečaťami.
Pozrime sa na obrázok zo špecifikácie, ale ešte predtým by som chcel hneď upozorniť na častú zámenu pojmov, a to v deskriptoroch. Úlohou deskriptora je doplniť popis charakteristiky. Ak je potrebné rozšíriť jeho možnosti, potom sa používajú deskriptory. Sú to tiež atribúty a rovnako ako služby a charakteristiky sa nachádzajú v tabuľke atribútov. Podrobne ich preskúmame v druhej časti článku. Niekedy sa však deskriptory odvolávajú na číslo riadku v tabuľke atribútov. Toto treba mať na pamäti. Aby sme sa vyhli nejasnostiam, budeme na tieto účely používať výraz „ukazovateľ na atribúty“.
Atribút je teda diskrétna hodnota, ktorá má nasledujúce vlastnosti:
1. Atribút Handle je index tabuľky zodpovedajúci atribútu
2. Typ atribútu je UUID, ktorý popisuje jeho typ
3. Hodnota atribútu sú údaje indexované ukazovateľom atribútu
4. Atribútové oprávnenia sú súčasťou atribútu, oprávnenia, ktoré nemožno čítať ani zapisovať pomocou protokolu atribútov
Ako tomu všetkému rozumieť? Atribút pointer je relatívne vzaté jeho číslo v našej tabuľke.
Umožňuje klientovi odkazovať na atribút v požiadavkách na čítanie alebo zápis. Naše riadky (atribúty) môžeme očíslovať od 0x0001 do 0xFFFF. V našom spojení s knižnicou je to číslo karty v papierovom katalógu. Podobne ako v katalógu knižnice sú karty usporiadané v rastúcom poradí podľa počtu. Číslo každého nasledujúceho riadku musí byť väčšie ako číslo predchádzajúceho. Podobne ako v knižnici sa občas niektoré kartičky stratia, takže u nás môžu byť medzery v číslovaní riadkov. Toto je povolené. Hlavná vec je, že idú postupne.
Typ atribútu určuje, čo atribút predstavuje. Analogicky s jazykom C,
kde sú booleovské, číselné premenné a reťazce, tak je to aj tu. Podľa typu atribútu rozoznávame
čím sa zaoberáme a ako môžeme s týmto atribútom ďalej pracovať. Nižšie sa pozrieme na niektoré špecifické typy atribútov. Napríklad „deklarácia služby“ (0x2800), „deklarácia charakteristických vlastností“ (0x2803), „deklarácia deskriptora“ (0x2902).
Hodnota atribútu je jeho skutočný význam, prepáčte tautológiu. Ak je typ atribútu reťazec, potom hodnotou atribútu môže byť napríklad slogan „Hello World !!!“. Ak je typ atribútu „deklarácia služby“, potom jeho hodnotou je samotná služba. A niekedy sú to informácie 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 vzťahujú iba na hodnotu atribútu a nie na samotné pole ukazovateľa, typu alebo povolenia. Tie. ak je povolené zaznamenávanie atribútov, môžeme zmeniť napríklad riadok „Ahoj svet!!!“ do riadku „Dobré ráno“. Nemôžeme však zakázať napísanie nového riadku alebo zmeniť typ atribútu a označiť riadok ako „deklaráciu služby“. Keď klient kontaktuje server, klient si vyžiada jeho atribúty. To umožňuje klientovi vedieť, čo môže server poskytnúť. Aj keď nie je potrebné čítať a zapisovať hodnoty.
Ako to vyzerá
Koncept GATT je zoskupiť atribúty v tabuľke atribútov vo veľmi špecifickom a logickom poradí. Pozrime sa bližšie na profil tepovej frekvencie nižšie. Stĺpec úplne vľavo v tejto tabuľke je voliteľný. Jednoducho nám popisuje, čo je tento riadok (atribút). Všetky ostatné rubriky sú nám už známe.
V hornej časti každej skupiny máme vždy atribút deklarácie služby. Jeho typ je vždy 0x2800 a ukazovateľ závisí od toho, koľko atribútov sa už nachádza v tabuľke. Jeho oprávnenia sú vždy len na čítanie, bez akejkoľvek autentifikácie alebo autorizácie. O týchto pojmoch si povieme trochu neskôr. Hodnota je ďalšie UUID, ktoré identifikuje službu. V tabuľke je hodnota 0x180D, ktorá je definovaná spoločnosťou Bluetooth SIG ako služba srdcového tepu.
Po oznámení služby prichádza oznámenie charakteristiky. Formou je to podobné ako vyhlásenie o službe. Jeho UUID je vždy 0x2803 a jeho povolenia sú vždy len na čítanie bez akejkoľvek autentifikácie alebo autorizácie. Pozrime sa na pole Hodnota atribútu, ktoré obsahuje niektoré údaje. Vždy obsahuje ukazovateľ, UUID a množinu vlastností. Tieto tri prvky opisujú následné vyhlásenie charakteristickej hodnoty. Ukazovateľ prirodzene označuje umiestnenie deklarácie charakteristickej hodnoty 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 iná ľubovoľná hodnota. A nakoniec vlastnosti, ktoré popisujú, ako je možné interagovať s charakteristickou hodnotou.
Tu nás čaká ďalšia nástraha. Je spojená s oprávneniami atribútov a charakteristickými vlastnosťami. Pozrime sa na obrázok vlastností bitového poľa zo špecifikácie.
Ako vidíte, sú tu aj polia, ktoré poskytujú možnosti čítania a zápisu. Možno sa čudujete, prečo máme oprávnenia na čítanie/zápis pre atribút a vlastnosť
čítať/zapisovať charakteristickú hodnotu? Nemali by byť vždy rovnakí? Faktom je, že vlastnosti pre charakteristickú hodnotu sú vlastne len odporúčania pre klienta používaného v GATT a aplikačných vrstvách. Toto sú len náznaky toho, čo môže klient očakávať od charakteristického atribútu deklarácie. Pozrime sa na to podrobnejšie. Aké typy povolení má atribút?
1. Prístupové práva:
- čítanie
— záznam
- čítaj a píš
2. Povolenie na overenie:
- potrebná autentifikácia
- nevyžaduje sa žiadna autentifikácia
3. Autorizačné povolenie:
- Je potrebná autorizácia
- nevyžaduje sa žiadne oprávnenie
Hlavný rozdiel medzi rozlíšením atribútov a charakteristickými vlastnosťami je v tom, že prvé sa vzťahujú na servery a druhé na klientov. Server môže mať povolené čítať charakteristickú hodnotu, ale môže vyžadovať autentifikáciu alebo autorizáciu. Preto, keď klient požaduje vlastnosti charakteristiky, dostaneme, že čítanie je povolené. Ale keď sa pokúsime čítať, dostaneme chybu. Preto môžeme pokojne hovoriť o priorite povolení pred vlastnosťami. Na strane klienta nemôžeme získať informácie o tom, aké povolenia má atribút.
Deskriptor
Vráťme sa k nášmu stolu. Po deklarovaní hodnoty charakteristiky sú možné nasledujúce deklarácie atribútov:
1. Nová deklarácia vlastností (služba môže mať mnoho charakteristík)
2. Nové vyhlásenie o službe (v tabuľke ich môže byť veľa)
3. Vyhlásenie kľučky
V prípade charakteristiky merania srdcovej frekvencie je v našej tabuľke deklarácia charakteristickej hodnoty sprevádzaná deklaráciou deskriptora. Deskriptor je atribút s dodatočnými informáciami o charakteristike. Existuje niekoľko typov deskriptorov. Podrobne si o nich povieme v druhej časti tohto článku. Zatiaľ sa dotkneme iba deskriptora konfigurácie charakteristických vlastností klienta (CCCD). Má UUID rovné 0x2902. Pomocou tohto deskriptora má klient možnosť povoliť indikáciu alebo upozornenie na serveri. Rozdiel medzi nimi je malý, ale stále existuje. Oznámenie nevyžaduje potvrdenie prijatia od klienta. Indikácia si to vyžaduje, hoci sa vyskytuje na úrovni GATT, ale nedosahuje aplikačnú úroveň. Prečo, pýtate sa? bohuzial, toto neviem. Len poviem, že severskí experti odporúčajú používať notifikácie. Okrem toho v oboch prípadoch prebieha kontrola integrity balíka (pomocou CRC).
Záver
Na záver článku by som chcel povedať toto. Posledná tabuľka je trochu neprehľadná. Vybral som si ho však, pretože je daný , na ktorú sa spolieham. V druhej časti môjho článku mám v úmysle preniknúť hlbšie do špecifikácie BlueTooth 4.0. Čakajú nás tam správnejšie schémy a kresby. V tretej časti by som rád analyzoval protokol získaný pomocou programu Wireshark z jedného z gadgetov a videl „naživo“ celú teóriu, ktorú študujeme.
Zamestnanec skupiny spoločností
Pečerskich Vladimír
Zdroj: hab.com