BLE pod mikroskopem (ATTы GATTы…)
Část 1, přehled
Od vydání první specifikace pro Bluetooth 4.0 již uplynula poměrně dlouhá doba. A přestože je téma BLE velmi zajímavé, stále mnoho vývojářů odrazuje kvůli své složitosti. Ve svých předchozích článcích jsem se zabýval především nejnižší úrovní, Link Layer a Physical Layer. To nám umožnilo vyhnout se nutnosti uchýlit se k tak složitým a matoucím konceptům, jako je protokol atributů (ATT) a obecný profil atributů (GATT). Není však kam jít, bez jejich pochopení nelze vyvinout kompatibilní zařízení. Dnes bych se s vámi rád o tyto poznatky podělil. Ve svém článku se budu opírat o pro začátečníky ze severského webu. Pojďme tedy začít.
Proč je všechno tak těžké?
Podle mě bylo hned jasné, že správa zařízení přes chytré telefony je velmi perspektivní a dlouhotrvající téma. Proto se rozhodli jej strukturovat okamžitě a na maximum. Aby výrobci různých gadgetů nepřicházeli s vlastními protokoly, které pak budou nekompatibilní. Proto ta obtížnost. Už v první fázi se snažili do protokolu BLE vtěsnat všechno možné. A nezáleží na tom, zda to bude užitečné později nebo ne. Navíc počítaly s možností rozšíření seznamu zařízení do budoucna.
Pojďme se podívat na obrázek, kde je nakreslen diagram protokolu BLE. Skládá se z několika vrstev. Nejnižší fyzická vrstva (PHY) je zodpovědná za rádiový kanál zařízení. Link Layer (LL) obsahuje celou sekvenci bajtů v přenášené zprávě. V předchozích článcích jsme přesně toto studovali. Host Controller Interface (HCI) je protokol výměny mezi vrstvami BLE nebo čipy, pokud jsou řadič a hostitel implementovány na různých čipech. Logical Link Control and Adaptation Protocol (L2CAP) je zodpovědný za tvorbu paketů, rámování, kontrolu chyb a sestavování paketů. Za šifrování paketů je zodpovědný protokol SMP (Security Manager Protocol). Obecný přístupový profil (GAP) je zodpovědný za počáteční výměnu dat mezi zařízeními, aby bylo možné určit „kdo je kdo“. Zahrnuje také skenování a reklamu. V tomto článku se zaměřím na dvě zbývající části protokolu – GATT a ATT. GATT je nadstavbou ATT, takže jsou úzce provázány.
Pro zjednodušení příběhu bych se rád obrátil k přirovnání. Někde jsem to slyšel a rád bych to podpořil. Představte si zařízení BLE jako knihovnu s několika policemi. Každá police je samostatným tématem. Máme například police se sci-fi, matematikou a encyklopediemi. Na každé polici jsou knihy se zadaným tématem. A některé knihy mají dokonce papírové záložky s poznámkami. Navíc máme malý papírový katalog všech knih. Pokud si pamatujete, školní knihovny jsou úzká krabice s papírovými kartičkami. S touto analogií je skříň profilem našeho zařízení. Police jsou služby, knihy jsou charakteristiky a katalog je tabulka atributů. Záložky v knihách jsou deskriptory, o kterých také budu mluvit později podrobněji.
Každý, kdo vyvíjel zařízení, ví, že mnoho projektů má podobné části kódu. Faktem je, že mnoho zařízení má podobnou funkci. Například pokud jsou zařízení napájena bateriemi, pak problém nabíjení a sledování jejich úrovně bude stejný. Totéž platí pro senzory. Vlastně objektově orientovaný přístup k programování „poskytuje schopnost vytvářet objekty, které kombinují vlastnosti a chování do samostatného spojení, které lze poté znovu použít“. Podle mého názoru se BLE pokusil o podobný přístup. Profily byly vyvinuty skupinou Bluetooth Special Interest Group (SIG). Zařízení od různých výrobců, která mají stejné profily, by mezi sebou měla bez problémů spolupracovat. Profily se zase skládají ze služeb a služeb charakteristik, doplněných o deskriptory. Obecně to může vypadat takto:
Vezměme si například profilový diagram monitoru srdečního tepu (fitness náramku). Skládá se ze dvou služeb a několika charakteristik. Z toho se okamžitě vyjasní hierarchie profilu. Charakteristika kontrolního bodu resetuje celkový počet výdejů kalorií na nulu.
1. Služba srdeční frekvence zahrnuje tři charakteristiky (0x180D):
a) Povinná charakteristika srdeční frekvence (0x2A37)
b) Volitelná charakteristika polohy snímače těla (0x2A38)
c) Podmíněné charakteristiky kontrolního bodu srdeční frekvence (0x2A39)
2. Servis baterie (0x180F):
a) Povinná charakteristika úrovně nabití baterie (0x2A19)
UUID
Abychom měli jedinečný přístup k prvkům profilu (službám, charakteristikám a deskriptorům), musíme je všechny nějak očíslovat. Pro tento účel je zaveden koncept jako Universally Unique ID (UUID) nebo Universally Unique Identifier. UUID je uvedeno v závorkách každého řádku. A je tu jedna zvláštnost. Pro UUID jsme se rozhodli použít kód o délce 16 a 128 bitů. Proč se ptáš? V protokolu BLE je vše o úsporách energie. Proto je rozměr 16 bitů celkem rozumný. Je nepravděpodobné, že by jich v nejbližší době vzniklo více než 65 tis. jedinečné služby a vlastnosti. V tuto chvíli již bylo spočítáno vše, co mohli (vzpomeňte si, odkud to pochází - „počítal i vás“ :-)) Očíslované prvky , , и můžete se podívat na odkazy.
Myslím si však, že každý si pamatuje příběh se 4 bajty IP adres na internetu. Nejprve jsme si mysleli, že to stačí, ale nyní stále nemůžeme přejít na 6bajtovou adresu. Aby se tato chyba neopakovala a dala volný průchod hravým rukám kutilů, rozhodla se společnost SIG okamžitě zavést 128bitové UUID. To mi osobně připomíná nelicencované pásmo 433 MHz, které dostali z rádia všemožní Kulibinové. V našem případě byl vychován 128bitový identifikátor služeb a charakteristik. To znamená, že pro naše služby a zařízení můžeme použít téměř jakoukoli 128bitovou hodnotu. Přesto je pravděpodobnost, že přijdete se stejným UUID, nulová.
Ve skutečnosti mají krátké 16bitové UUID rozšíření na 128bitovou hodnotu. Ve specifikaci se toto rozšíření nazývá Bluetooth Base UUID a má hodnotu 00000000-0000-1000-8000-00805F9B34FB. Pokud má například 16bitový atribut UUID hodnotu 0x1234, pak ekvivalentní 128bitový UUID bude mít hodnotu 00001234-0000-1000-8000-00805F9B34FB. A dokonce je dán odpovídající vzorec:
128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID
Nevím, kde se toto magické číslo vzalo. Pokud někdo ze čtenářů ví, ať napíše do komentářů (Už to udělal uživatel s přezdívkou Sinopteek. Viz komentáře). Pokud jde o vymýšlení 128bitových UUID, v zásadě můžete použít speciální kdo to za vás udělá.
ATTy GATTy...
Ve skutečnosti pak začíná zábava. Dovolte mi připomenout, že ATT je založeno na vztahu klient-server. Nyní se podíváme na serverové zařízení. Obsahuje informace, jako jsou hodnoty senzorů, stav spínače světel, údaje o poloze atd. Nyní, když jsou všichni „účastníci našeho průvodu“ očíslováni, musíme je nějak umístit do paměti zařízení. Za tímto účelem jsme je umístili do tabulky zvané atributová tabulka. Tohle si dobře zapamatujte. To je samotné srdce BLE. To je to, co budeme dále zvažovat. Nyní nazveme každý řádek atributem. Tento stůl je umístěn hluboko v zásobníku a zpravidla k němu nemáme přímý přístup. Inicializujeme ho a přistupujeme k němu, ale to, co se děje uvnitř, je před námi skryto za sedmi pečetěmi.
Podívejme se na obrázek ze specifikace, ale ještě předtím bych rád upozornil na častou záměnu pojmů, a to v deskriptorech. Úlohou deskriptoru je doplňovat popis charakteristiky. Když je potřeba rozšířit jeho možnosti, pak se používají deskriptory. Jsou to také atributy a stejně jako služby a charakteristiky se nacházejí v tabulce atributů. Podrobně je prozkoumáme ve druhé části článku. Někdy však deskriptory odkazují na číslo řádku v tabulce atributů. To je třeba mít na paměti. Abychom se vyhnuli nejasnostem, budeme pro tyto účely používat termín „ukazatel na atributy“.
Atribut je tedy diskrétní hodnota, která má následující vlastnosti:
1. Attribute Handle je index tabulky odpovídající atributu
2. Typ atributu je UUID, který popisuje jeho typ
3. Hodnota atributu jsou data indexovaná ukazatelem atributu
4. Oprávnění atributů jsou součástí atributu, oprávnění, které nelze číst ani zapisovat pomocí protokolu atributů
Jak tomu všemu rozumět? Atribut pointer je relativně vzato jeho číslo v naší tabulce.
Umožňuje klientovi odkazovat na atribut v požadavcích na čtení nebo zápis. Naše řádky (atributy) můžeme očíslovat od 0x0001 do 0xFFFF. V našem spojení s knihovnou je to číslo karty v papírovém katalogu. Podobně jako v katalogu knihovny jsou karty uspořádány ve vzrůstajícím pořadí. Číslo každého následujícího řádku musí být větší než číslo předchozího. Stejně jako v knihovně se občas některé kartičky ztratí, takže u nás mohou být mezery v číslování řádků. To je povoleno. Hlavní je, že jdou postupně.
Typ atributu určuje, co atribut představuje. Analogicky s jazykem C,
kde jsou booleovské, číselné proměnné a řetězce, tak je to i zde. Podle typu atributu rozeznáváme
čím se zabýváme a jak můžeme s tímto atributem dále pracovat. Níže se podíváme na některé konkrétní typy atributů. Například „deklarace služby“ (0x2800), „deklarace vlastností“ (0x2803), „deklarace deskriptoru“ (0x2902).
Hodnota atributu je jeho skutečný význam, promiňte tautologii. Pokud je typem atributu řetězec, pak hodnotou atributu může být například slogan „Hello World !!!“. Pokud je typem atributu „deklarace služby“, pak je jeho hodnotou samotná služba. A někdy je to informace o tom, kde najít další atributy a jejich vlastnosti.
Atributová oprávnění umožňují serveru pochopit, zda je povolen přístup pro čtení nebo zápis.
Všimněte si, že tato oprávnění se vztahují pouze na hodnotu atributu a nikoli na samotné pole ukazatele, typu nebo oprávnění. Tito. pokud je povoleno nahrávání atributů, pak můžeme změnit například řádek „Ahoj světe!!!“ na řádek „Dobré ráno“. Nemůžeme však zakázat napsání nového řádku nebo změnit typ atributu a označit řádek jako „deklaraci služby“. Když klient kontaktuje server, klient požaduje jeho atributy. To umožňuje klientovi vědět, co může server poskytnout. I když není nutné hodnoty číst a zapisovat.
Jak to vypadá
Koncept GATT je seskupit atributy v tabulce atributů dohromady ve velmi specifickém a logickém pořadí. Podívejme se blíže na profil tepové frekvence níže. Sloupec zcela vlevo v této tabulce je volitelný. Jednoduše nám popisuje, co je tento řádek (atribut). Všechny ostatní rubriky jsou nám již známé.
V horní části každé skupiny máme vždy atribut deklarace služby. Jeho typ je vždy 0x2800 a ukazatel závisí na tom, kolik atributů je již v tabulce přítomno. Jeho oprávnění jsou vždy pouze pro čtení, bez jakéhokoli ověřování nebo autorizace. O těchto pojmech si povíme trochu později. Hodnota je další UUID, které identifikuje službu. V tabulce je hodnota 0x180D, která je definována Bluetooth SIG jako služba srdeční frekvence.
Po oznámení služby přichází oznámení charakteristiky. Formou se podobá prohlášení o službě. Jeho UUID je vždy 0x2803 a jeho oprávnění jsou vždy pouze pro čtení bez jakéhokoli ověřování nebo autorizace. Podívejme se na pole Hodnota atributu, které obsahuje některá data. Vždy obsahuje ukazatel, UUID a sadu vlastností. Tyto tři prvky popisují následnou deklaraci charakteristické hodnoty. Ukazatel přirozeně označuje umístění deklarace charakteristické hodnoty v tabulce atributů. UUID popisuje, jaký typ informace nebo hodnoty můžeme očekávat. Například hodnota teploty, stav spínače světel nebo nějaká jiná libovolná hodnota. A konečně vlastnosti, které popisují, jak lze s charakteristickou hodnotou interagovat.
Zde nás čeká další úskalí. Je spojena s oprávněními atributů a charakteristickými vlastnostmi. Podívejme se na obrázek vlastností bitového pole ze specifikace.
Jak vidíte, jsou zde také pole, která poskytují možnosti čtení a zápisu. Možná se divíte, proč máme oprávnění ke čtení/zápisu pro atribut a vlastnost
čtení/zápis pro charakteristickou hodnotu? Neměli by být vždy stejní? Faktem je, že vlastnosti pro charakteristickou hodnotu jsou vlastně pouze doporučení pro klienta používaného v GATT a aplikačních vrstvách. Jsou to pouze náznaky toho, co může klient očekávat od atributu charakteristické deklarace. Podívejme se na to podrobněji. Jaké typy oprávnění má atribut?
1. Přístupová oprávnění:
- čtení
— záznam
- číst a psát
2. Povolení k ověření:
- vyžadováno ověření
- není vyžadována autentizace
3. Autorizační oprávnění:
- je potřebná autorizace
- není vyžadováno povolení
Hlavní rozdíl mezi rozlišením atributů a charakteristickými vlastnostmi je v tom, že první se vztahuje na servery a druhé na klienty. Server může mít povoleno číst charakteristickou hodnotu, ale může vyžadovat ověření nebo autorizaci. Když tedy klient požaduje vlastnosti charakteristiky, obdržíme, že čtení je povoleno. Ale když se pokusíme číst, dostaneme chybu. Můžeme tedy s klidem mluvit o prioritě oprávnění před vlastnostmi. Na straně klienta nemůžeme získat informace o tom, jaká oprávnění má atribut.
Deskriptor
Vraťme se k našemu stolu. Po deklaraci hodnoty charakteristiky jsou možné následující deklarace atributů:
1. Nová deklarace vlastností (služba může mít mnoho vlastností)
2. Nové prohlášení o službě (v tabulce jich může být mnoho)
3. Vyhlášení kliky
V případě charakteristiky měření srdeční frekvence je v naší tabulce deklarace charakteristické hodnoty doprovázena deklarací deskriptoru. Deskriptor je atribut s dalšími informacemi o charakteristice. Existuje několik typů deskriptorů. Podrobně si o nich povíme v druhé části tohoto článku. Prozatím se dotkneme pouze popisovače konfigurace vlastností klienta (CCCD). Má UUID rovné 0x2902. Pomocí tohoto deskriptoru má klient možnost povolit indikaci nebo upozornění na serveru. Rozdíl mezi nimi je malý, ale stále existuje. Oznámení nevyžaduje potvrzení přijetí od klienta. Indikace to vyžaduje, ačkoli se vyskytuje na úrovni GATT, ale nedosahuje aplikační úrovně. Proč, ptáte se? Bohuzel, tohle nevim. Řeknu jen, že severští odborníci doporučují používat upozornění. V obou případech navíc probíhá kontrola integrity balíčku (pomocí CRC).
Závěr
Na závěr článku bych chtěl říci toto. Poslední tabulka je trochu matoucí. Vybral jsem si ho však, protože je daný , na kterou spoléhám. Ve druhé části mého článku se hodlám hlouběji ponořit do specifikace BlueTooth 4.0. Tam nás čekají správnější schémata a nákresy. Ve třetí části bych rád analyzoval protokol získaný pomocí programu Wireshark z jednoho z gadgetů a viděl „naživo“ veškerou teorii, kterou studujeme.
Zaměstnanec skupiny společností
Pečerskich Vladimír
Zdroj: www.habr.com