🥇BLE a mikroszkóp alatt (ATT-k GATT-k…)

BLE mikroszkóp alatt (ATT és GATT…)

1. rész, áttekintés

Már egy elég hosszú idő telt el azóta, hogy megjelent az első Bluetooth 4.0 specifikáció. És bár a BLE téma nagyon érdekes, sok fejlesztőt még mindig elriaszt a bonyolultsága. Korábbi cikkeimben főként a Link Layer és a Physical Layer legalsó szintjét vizsgáltam. Ez lehetővé tette, hogy ne foglalkozzak olyan bonyolult és összetett fogalmakkal, mint az attribútum protokoll (ATT) és a közös attribútum profil (GATT). Azonban nem lehet elkerülni ezeket, hogy kompatibilis eszközöket fejlesszünk. Ma szeretném megosztani veletek ezeket a tudásokat. Cikkem alapját az útmutató alapok kezdőknek a Nordic weboldaláról képezi. Lássuk hát.

Miért olyan bonyolult minden?

Szerintem egyértelmű volt, hogy az eszközök okostelefonokon keresztüli irányítása egy nagyon ígéretes és hosszú távú téma. Ezért úgy döntöttek, hogy azonnal strukturálják, és maximálisan kihasználják. A gyártók ne találjanak ki saját protokollokat, amelyek később nem lesznek kompatibilisek. Innen származik a bonyolultság. Már az első szakaszban a BLE protokollba minden bele akartak préselni, ami csak lehetséges. És nem számít, hogy később szükség lesz-e rá vagy sem. Ezen kívül előrelátták a jövőbeni eszközlisták bővítésének lehetőségét.

Nézzük meg a képet, amely a BLE protokoll sémáját mutatja. Több rétegből áll. A legalacsonyabb, fizikai réteg (PHY) felelős az eszköz rádiócsatornájáért. A Link Layer (LL) tartalmazza a továbbított üzenet összes byte-jának sorrendjét. Korábbi cikkeinkben ezt tanulmányoztuk. A Host Controller Interface (HCI) – a rétegek közötti vagy BLE chip-ek közötti kommunikációs protokoll, ha a vezérlő és a gazda külön chipen valósul meg. A csomagok formálásáért, keretekre osztásáért, hibakontrollért és csomaggyűjtésért a Logical Link Control and Adaptation Protocol (L2CAP) felelős. A csomagok titkosításáért a Security Manager Protocol (SMP) felelős. A közvetlen hozzáférési profil (GAP) felelős az eszközök közötti kezdeti adatcseréért, hogy meghatározzák, „Ki kicsoda”. Ezenkívül a beolvasás és reklámozás is ehhez kapcsolódik. Ebben a cikkben a protokoll két maradék részére szeretnék koncentrálni – GATT és ATT. A GATT az ATT fölötti réteg, ezért szoros kapcsolatban állnak egymással.

A történet egyszerűsítése érdekében egy analógiát szeretnék felhozni. Valahol hallottam, és szeretném támogatni. Képzeljen el egy BLE eszközt, mint egy könyvespolcot, több polccal. Minden polc egy különféle témát képvisel. Például van egy polcunk a fantasztikumnak, a matematikának, az enciklopédiáknak. Minden polcon a megadott téma szerinti könyvek találhatók. Néhány könyvben még papíralapú könyvjelzők is vannak feljegyzésekkel. Emellett van egy kis papíralapú katalógusunk az összes könyvről. Ha emlékszik az iskolai könyvtárakra — ez egy keskeny fiók papíralapú kártyákkal. Ebben az analógiában a szekrény az eszközünk profilját jelenti. A polcok a szolgáltatásokat, a könyvek a jellemzőket, a katalógus pedig az attribútumok táblázatát. A könyvjelzők a könyvekben azok a leírók, amelyeket később részletesebben is bemutatok.

Mindenki, aki eszközöket fejlesztett, tudja, hogy sok projektben vannak hasonló kódok. Az igazság az, hogy sok eszköz hasonló funkciókkal bír. Például ha az eszközök akkumulátorról működnek, akkor a töltés és a szintellenőrzés problémája azonos lesz. Ugyanez vonatkozik az érzékelőkre is. Valójában az objektumorientált programozási megközelítés „lehetővé teszi olyan objektumok létrehozását, amelyek összekapcsolják a tulajdonságokat és viselkedéseket egy önálló szövetségbe, amely ezután többször is felhasználható”. Véleményem szerint a BLE esetében próbálkozás történt hasonló megközelítéssel. A Bluetooth Special Interest Group (SIG) által profilokat dolgoztak ki. Azok az eszközök, amelyek azonos profilokkal rendelkeznek különböző gyártóktól, zökkenőmentesen kell, hogy működjenek egymással. A profilok szolgáltatásokból állnak, a szolgáltatások pedig jellemzőkből, amelyeket leírók egészítenek ki. Általánosságban ez így nézhet ki:

Példának okáért vegyük a szívritmus-monitor profiljának sémáját (fitness karkötő). Két szolgáltatásból és több jellemzőből áll. Azonnal világos a profil hierarchiája. A kontrollpont jellemző visszaállítja a kalóriák összesített fogyasztásának számát nullára.

1. A szívritmus szolgáltatás három jellemzőt tartalmaz (0x180D):
    a) Kötelező jellemző a szívverés számáról (0x2A37)
    b) Opciós jellemző a testérzékelő helyzetéről (0x2A38)
    c) Feltételes jellemző a szívritmus kontrollpontról (0x2A39)
2. Az akkumulátor üzemeltetése szolgáltatás (0x180F):
    a) Kötelező akkumulátor töltöttségi szint jellemző (0x2A19)

UUID

Ahhoz, hogy egyértelműen hivatkozhassunk a profil elemeire (szolgáltatások, jellemzők és leírók), számoznunk kell azokat. Erre az Universally Unique ID (UUID) vagyis a Világos egyedi azonosító fogalmát vezették be. Minden sorban a zárójelben pontosan az UUID szerepel. Van egy különlegesség ezzel kapcsolatban. Az UUID-hoz 16 és 128 bites kódot használnak. Miért, kérdezheted? A BLE protokollban minden az energiafogyasztás megőrzéséről szól. Ezért a 16 bites méret teljesen ésszerű. Valószínű, hogy a közeljövőben nem lesz több mint 65 ezer egyedi szolgáltatás és jellemző. Jelenleg mindent, amit lehetett, már kiszámoltunk (emlékszel, honnan van ez – „ő is számlálta Önt” :-)) A számozott elemek profilok, szolgáltatások, jellemzők és leírók megtekinthetők a hivatkozásokon.

Viszont azt hiszem, mindenki emlékszik a négy bájtos IP-címek történetére az interneten. Először azt gondolták, ez elegendő lesz, de még mindig nem tudunk áttérni a hat bájtos címre. Annak érdekében, hogy elkerüljük ezt a hibát, és hogy teret adjunk a barkácsoló kezeknek, a SIG azonnal bevezette a 128 bites UUID-kat. Ez számomra a 433 MHz-es illegális sávra emlékeztet, amelyet a lehetőségek szerint szabadon engedtek a rádiócsatornára. Az esetünkben a 128 bites azonosítók szabadon hirdettek. Ez azt jelenti, hogy a szolgáltatásainkhoz és eszközeinkhez gyakorlatilag bármilyen 128 bites értéket használhatunk. Az esély, hogy azonos UUID-t találjunk, gyakorlatilag nulla.

Valójában a rövid 16 bites UUID-nak van egy kiterjesztése a 128 bites értékhez. A specifikációban ezt a kiterjesztést Bluetooth Base UUID-nak hívják, és értéke 00000000-0000-1000-8000-00805F9B34FB. Például, ha a 16 bites atribútum UUID értéke 0x1234, akkor az ehhez tartozó 128 bites UUID értéke 00001234-0000-1000-8000-00805F9B34FB lesz. A megfelelő képlet is meg van adva:

128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID

Honnan származik ez a mágikus szám, azt nem tudom. Ha valaki a kedves olvasók közül tudja, ne habozzon kommentálni (A Sinopteek nevű felhasználó már meg is tette. Nézd meg a kommenteket). Ami a 128 bites UUID-k kitalálását illeti, alapvetően használhatsz egy speciális generátort, amely ezt elvégzi helyetted.

ATT típusok...

Most jön a legérdekesebb rész. Emlékeztetem, hogy az ATT egy kliens-szerver kapcsolat alapjaira épül. Jelenleg a szerver felépítését vizsgáljuk. Ez olyan információkat tartalmaz, mint a szenzorok értékei, a világító kapcsolók állapota, a helymeghatározási adatok stb. Most, hogy minden 'parádénk résztvevője' fel van numerálva, el kell őket helyeznünk az eszköz memóriájában. Ehhez egy táblázatba helyezzük őket, amit attribútumtáblázatnak nevezünk. Jól jegyezd meg ezt. Ez a BLE szíve. Ezt fogjuk később vizsgálni. Mostantól minden sorunkat attribútumnak nevezünk. Ez a táblázat a verem mélyén található, és általában nincs közvetlen hozzáférésünk. Inicializáljuk és hozzáférünk, de ami belül történik, az hét pecsét mögött rejtőzik előttünk.

Nézzük meg a specifikációból készült képet, viszont előtte szeretném felhívni a figyelmet egy gyakori terminológiai félreértésre, nevezetesen a leírókra. A leíró szerepe az, hogy kiegészítse a jellemzők leírását. Amikor bővíteni kell a lehetőségeit, akkor használják a leírókat. Ezek is attribútumok, és a szolgáltatásokkal és jellemzőkkel egyenrangúan az attribútumtáblázatban helyezkednek el. Részletesen megvizsgáljuk őket a cikk második részében. Azonban néha a leírókat az attribútumtáblázat sorának számaként emlegetik. Ezt érdemes észben tartani. Mi elkerüljük a félreértéseket, ezért ezekre a célokra az 'attribútum mutató' kifejezést használjuk.

Tehát az attribútum egy diszkrét érték, amelynek a következő, hozzá kapcsolódó tulajdonságai vannak:
1. Attribútum mutató (Attribute Handle) — a táblázat indexe, amely megfelel az attribútumnak
2. Attribútum típusa (Attribute Type) — az UUID, amely leírja a típusát
3. Attribútum értéke (Attribute Value) — az attribútum mutatójával indexelt adatok
4. Attribútum engedélyek (Attribute Permissions) — az attribútum része, az engedélyek, amelyeket nem lehet olvasni vagy írni az attribútumok protokollján keresztül

Hogyan értelmezzük mindezt? Az attribútum mutató, mondjuk, a szám a táblázatunkban.
Ez lehetővé teszi a kliens számára, hogy hivatkozzon egy attribútumra olvasási vagy írási kérésekben. Mi a sorainkat (attribútumainkat) 0x0001-től 0xFFFF-ig számozhatjuk. A könyvespolcunkkal való analógiában ez a kártya száma a papíralapú katalógusban. Hasonlóan, mint a könyvtári katalógusban, a kártyák a szám növekvő sorrendjében helyezkednek el. Minden következő sor száma nagyobbnak kell lennie az előzőnél. Mint a könyvtárban, néha el lehet veszíteni néhány kártyát, így nálunk is lehetnek hiányzó sorok a számozásban. Ez megengedett. A legfontosabb, hogy a számozás növekvő legyen.

Az attribútum típusa határozza meg, hogy az adott attribútum mit jelöl. A C nyelvvel való analógiát követve,
ahol vannak logikai, numerikus változók és karakterláncok, itt is így van. Az attribútum típusa alapján megtudjuk,
mivel állunk szemben, és hogyan dolgozzunk tovább azzal az attribútummal. Az alábbiakban áttekintünk néhány specifikus attribútumtípust. Például a „szolgáltatás deklaráció” (0x2800), a „jellemző deklaráció” (0x2803), a „leíró deklaráció” (0x2902).

Az attribútum értéke önmagában az érték, elnézést a tautológia miatt. Ha az attribútum típusa karakterlánc, akkor az attribútum értéke lehet például a „Hello World !!!” szlogen. Ha az attribútum típusa „szolgáltatás deklaráció”, akkor az értéke magát a szolgáltatást jelenti. Néha pedig arra vonatkozó információt tartalmaz, hogy hol találhatók más attribútumok és azok tulajdonságai.

Az attribútumok engedélyei lehetővé teszik a szerver számára, hogy megértse, engedélyezett-e az olvasás vagy írás.
Ne feledje, hogy ezek az engedélyek csak az attribútum értékére vonatkoznak, nem pedig az mutatóra, típusra és az engedélymezőre magára. Azaz, ha az attribútum írása engedélyezett, akkor például megváltoztathatjuk a „Hello World !!!” szöveget „Jó reggelt” szövegre. De nem tilthatjuk meg új sor írását, vagy nem változtathatjuk meg az attribútum típusát, és jelölhetjük a sort „szolgáltatás deklaráció”-ként. Amikor a kliens kapcsolódik a szerverhez, a kliens lekéri annak attribútumait. Ez lehetővé teszi a kliens számára, hogy megtudja, mit tud a szerver biztosítani. Bár nem kötelező az értékek olvasása és írása.

Hogyan néz ki ez

A GATT koncepciója az attribútumok csoportosítására összpontosít az attribútumtáblázatban, nagyon specifikus és logikai sorrendben. Nézzük meg közelebbről a szívverésprofil példáját az alábbiakban. A táblázat legbaloldali oszlopa nem kötelező. Csak azt írja le, hogy mi ez a sor (attribútum). Minden egyéb oszlop számunkra már ismerős.

Minden csoport tetején mindig az értesítési attribútum található. A típusa mindig 0x2800, és a mutató attól függ, hogy hány attribútum van már a táblázatban. A jogosultságai mindig csak olvashatók, anélkül, hogy bármilyen hitelesítési vagy engedélyezési ellenőrzés lenne. Ezekkel a fogalmakkal később fogunk foglalkozni. Az érték egy másik UUID, amely meghatározza, hogy mi ez a szolgáltatás. A táblázatban az érték 0x180D, amelyet a Bluetooth SIG a szívverés szolgáltatásaként határoz meg.

A szolgáltatás bejelentése után a jellemző bejelentése következik. Alakja hasonló a szolgáltatás bejelentéséhez. Az UUID mindig 0x2803, és a jogosultságok is mindig csak olvashatók, anélkül, hogy bármilyen hitelesítési vagy engedélyezési ellenőrzés lenne. Nézzük meg az Attribute Value mezőt, amely néhány adatot tartalmaz. Mindig tartalmaz egy mutatót, egy UUID-t és egy tulajdonságkészletet. Ezek a három elem leírja a jellemző érték bejelentését. A mutató természeténél fogva azt jelöli, hogy hol található a jellemző érték bejelentése az attribútumtáblázatban. Az UUID leírja, hogy milyen típusú információt vagy értéket várhatunk. Például hőmérséklet, világító kapcsoló állapota, vagy bármilyen más tetszőleges érték. Végül pedig a tulajdonságok leírják, hogyan lehet interakcióba lépni a jellemző értékével.

Itt még egy csapda vár ránk. Ez a jogosultságokkal és a jellemzők tulajdonságaival kapcsolatos. Nézzük meg a tulajdonságok bitmezőjének ábráját a specifikációból.

Ahogy látható, itt is vannak mezők, amelyek olvasási és írási lehetőségeket biztosítanak. Felmerülhet a kérdés, miért van olvasási/írási jogosultságunk az attribútumra és a tulajdonságra.
Jellemző értékek esetén a felolvasás/írás miért nem lehet mindig azonos? A tulajdonságok a jellemző értékhez valójában csak ajánlások az ügyfél számára, amelyeket a GATT és az alkalmazási rétegek használnak. Ezek csupán útmutatások arról, hogy mit várhat el az ügyfél a jellemző nyilatkozatának attribútumától. Nézzük meg ezt részletesebben. Milyen típusú engedélyezések vannak az attribútumnál?

1. Hozzáférési engedélyek:
     — olvasás
     — írás
     — olvasás és írás
2. Hitelesítési engedély:
     — hitelesítés szükséges
     — hitelesítés nem szükséges
3. Jogosultsági engedély:
     — jogosultság szükséges
     — jogosultság nem szükséges

A tulajdonsági engedélyek és a jellemzők közötti legfontosabb különbség az, hogy az előbbiek a kiszolgálókra vonatkoznak, míg az utóbbiak az ügyfelekre. Lehet, hogy a kiszolgálón engedélyezett a jellemző értékének olvasása, de van hitelesítési vagy jogosultsági követelmény. Ezért amikor az ügyfél a jellemzők tulajdonságait kérdezi, az olvasás engedélyezettnek tűnik. De a tényleges olvasási kísérletnél hiba lép fel. Ezért bátran kijelenthetjük, hogy az engedélyek prioritást élveznek a tulajdonságokkal szemben. Az, hogy milyen engedélyek vannak az attribútumnál, az ügyfél oldaláról nem érhető el.

Leíró

Térjünk vissza a táblázatunkhoz. A jellemző érték bejelentése után a következő attribútumok bejelentése lehetséges:
1. Új jellemző bejelentés (a szolgáltatásban sok jellemző lehet)
2. Új szolgáltatásbejelentés (a táblázatban sok lehet belőlük)
3. Leíró bejelentés

A pulzusmérés jellemzői esetében a táblázatunkban a jellemző értékének bejelentését egy leíró bejelentése kíséri. A leíró egy olyan attribútum, amely további információt nyújt a jellemzőről. Számos leíró létezik, amelyekről részletesen beszélünk a cikk második részében. Jelenleg csak a kliens jellemzők konfigurációs leírójáról (Client Characteristic Configuration Descriptor – CCCD) fogunk szólni. Ennek UUID-ja 0x2902. E leíró segítségével a kliens lehetőséget kap arra, hogy aktiválja a szerveren az indikációt vagy a notifikációt. Közöttük a különbség kicsi, de mégis létezik. A notifikáció nem igényel megerősítést a kliens részéről, míg az indikáció ezt megköveteli, még ha ez a GATT szinten is történik, elkerülve az alkalmazás szintet. Miért van ez így, kérdezhetné? Sajnos, ezt nem tudom. Csak annyit mondhatok, hogy a Nordic szakértői a notifikáció használatát ajánlják, különösen azért, mert a csomag integritásának ellenőrzése (CRC segítségével) mindkét esetben megtörténik.