BLE pod mikroskopom (ATTy GATty…)
1. dio, pregled
Prošlo je dosta vremena otkako je objavljena prva Bluetooth 4.0 specifikacija. I premda je tema BLE-a vrlo zanimljiva, još uvijek odbija mnoge programere zbog svoje složenosti. U svojim prethodnim člancima prvenstveno sam se usredotočio na najnižu razinu - sloj veze i fizički sloj. To mi je omogućilo da izbjegnem složene i zbunjujuće koncepte poput protokola atributa (ATP) i generičkog profila atributa (GATT). Međutim, bez razumijevanja ovih koncepata nemoguće je razviti kompatibilne uređaje. Danas bih želio podijeliti to znanje s vama. U ovom članku oslonit ću se na Za početnike, s Nordicove web stranice. Dakle, krenimo.
Zašto je sve tako komplicirano?
Po mom mišljenju, odmah je bilo jasno da je upravljanje uređajima putem pametnih telefona vrlo obećavajući i dugoročan koncept. Stoga smo odlučili odmah ga što temeljitije strukturirati. To je bilo kako bismo spriječili proizvođače gadgeta da razvijaju vlastite protokole koji bi kasnije bili nekompatibilni. To objašnjava složenost. Od samog početka pokušali smo sve što je moguće ugurati u BLE protokol. A hoće li to kasnije biti korisno ili ne, bilo je nebitno. Također smo predvidjeli mogućnost proširenja popisa uređaja u budućnosti.
Pogledajmo sliku koja prikazuje dijagram BLE protokola. Sastoji se od nekoliko slojeva. Najniži, fizički sloj (PHY), odgovoran je za radio kanal uređaja. Sloj veze (LL) sadrži cijeli niz bajtova u prenesenoj poruci. Ovaj sloj smo proučavali u prethodnim člancima. Sučelje kontrolera hosta (HCI) je protokol za komunikaciju između BLE slojeva ili čipova ako su kontroler i host implementirani na različitim čipovima. Protokol za kontrolu i prilagodbu logičke veze (L2CAP) odgovoran je za formiranje paketa, uokvirivanje, kontrolu pogrešaka i ponovno sastavljanje paketa. Protokol za upravljanje sigurnošću (SMP) odgovoran je za šifriranje paketa. Generički profil pristupa (GAP) odgovoran je za početnu razmjenu podataka između uređaja kako bi se utvrdilo "tko je tko". Skeniranje i oglašavanje također spadaju pod ovaj profil. U ovom članku usredotočit ću se na preostala dva dijela protokola - GATT i ATT. GATT je nadgradnja na ATT, pa su usko isprepleteni.
Kako bih pojednostavio raspravu, želio bih upotrijebiti analogiju. Negdje sam je čuo i želio bih je ponoviti. Zamislite BLE uređaj kao policu za knjige s nekoliko polica. Svaka polica predstavlja zasebnu temu. Na primjer, imamo police za znanstvenu fantastiku, matematiku i enciklopedije. Svaka polica sadrži knjige na tu temu. Neke knjige čak imaju i papirnate oznake s bilješkama. Također imamo mali papirnati katalog svih knjiga. Ako se sjećate školskih knjižnica, one su poput uskih ladica s papirnatim karticama. U ovoj analogiji, polica za knjige je profil našeg uređaja. Police su usluge, knjige su karakteristike, a katalog je tablica atributa. Oznake u knjigama su deskriptori, o kojima ću kasnije detaljnije raspravljati.
Svatko tko je razvijao uređaje zna da mnogi projekti sadrže slične dijelove koda. To je zato što mnogi uređaji imaju sličnu funkcionalnost. Na primjer, ako su uređaji napajani baterijama, problem punjenja i praćenja njihove razine bit će isti. Isto vrijedi i za senzore. U osnovi, objektno orijentirani pristup programiranju "pruža mogućnost stvaranja objekata koji kombiniraju svojstva i ponašanja u samostalnu zajednicu koja se zatim može ponovno koristiti."Po mom mišljenju, BLE je pokušao sličan pristup. Bluetooth Special Interest Group (SIG) razvila je profile. Uređaji različitih proizvođača s identičnim profilima trebali bi besprijekorno raditi jedni s drugima. Profili se pak sastoje od usluga, a usluge se sastoje od karakteristika dopunjenih deskriptorima. Općenito, to bi moglo izgledati ovako:
Na primjer, pogledajmo dijagram profila za monitor otkucaja srca (fitness narukvica). Sastoji se od dvije usluge i nekoliko značajki. Hijerarhija profila odmah je jasna iz ovog dijagrama. Funkcija kontrolne točke resetira ukupni broj potrošenih kalorija na nulu.
1. Usluga mjerenja otkucaja srca uključuje tri karakteristike (0x180D):
a) Obvezna karakteristika otkucaja srca (0x2A37)
b) Parametar položaja opcionalnog senzora tijela (0x2A38)
c) Uvjetna karakteristika kontrolne točke otkucaja srca (0x2A39)
2. Servis održavanja baterije (0x180F):
a) Obavezna karakteristika razine baterije (0x2A19)
UUID
Kako bi se elementima profila (uslugama, karakteristikama i deskriptorima) mogao jedinstveno pristupiti, svi oni moraju biti numerirani. U tu svrhu uveden je koncept univerzalno jedinstvenog ID-a (UUID). UUID je naveden u zagradama u svakom retku. I ovdje postoji jedna osobitost. Odlučili su koristiti 16- i 128-bitni kod za UUID-ove. Zašto, pitate se? BLE protokol se u potpunosti fokusira na uštedu energije. Stoga je 16-bitni kod sasvim razuman. Malo je vjerojatno da će se u bliskoj budućnosti stvoriti više od 65 000 jedinstvenih usluga i karakteristika. U ovom trenutku, sve što se moglo prebrojati već je prebrojano (sjetite se odakle dolazi izreka "i vas je prebrojalo" :-)) Numerirani elementi , , и Možete pogledati linkove.
Međutim, mislim da se svi sjećaju priče o 4-bajtnoj IP adresi na internetu. Isprva su mislili da će to biti dovoljno, ali sada se još uvijek mučimo s prijelazom na 6-bajtnu adresu. Kako bi izbjegli ponavljanje ove pogreške i dali odriješene ruke nestašnim rukama DIY entuzijasta, SIG je odmah odlučio uvesti 128-bitne UUID-ove. To me podsjeća na nelicencirani pojas od 433 MHz, koji je bio prepušten svim vrstama hakera radio kanala. U našem slučaju, prepušteni smo 128-bitnom identifikatoru usluge i karakteristike. To znači da možemo koristiti gotovo bilo koju 128-bitnu vrijednost za naše usluge i uređaje. Vjerojatnost da će svi smisliti isti UUID je mala ili nikakva.
Zapravo, kratki 16-bitni UUID-ovi imaju vlastito proširenje na 128-bitnu vrijednost. U specifikaciji se ovo proširenje naziva Bluetooth Base UUID i ima vrijednost 00000000-0000-1000-8000-00805F9B34FB. Ako, na primjer, 16-bitni UUID atributa ima vrijednost 0x1234, tada bi ekvivalentni 128-bitni UUID imao vrijednost 00001234-0000-1000-8000-00805F9B34FB. Čak je navedena i odgovarajuća formula:
128_bitna_vrijednost = 16_bitna_vrijednost * 2^96 + Bluetooth_Base_UUID
Ne znam odakle dolazi ovaj magični broj. Ako neki čitatelji znaju, molim vas da napišu u komentarima (korisnik s nadimkom Sinopteek je to već učinio. Pogledajte komentare). Što se tiče stvaranja 128-bitnih UUID-ova, u principu možete koristiti poseban , što će to učiniti umjesto vas.
Sporazumi o trgovini robom (ATT) GATT-ovi…
Sada dolazi zabavni dio. Podsjetit ću vas da se ATT temelji na odnosu klijent-poslužitelj. Sada gledamo poslužiteljski uređaj. Sadrži informacije poput vrijednosti senzora, statusa prekidača za svjetlo, podataka o lokaciji i tako dalje. Sada kada su svi "sudionici naše parade" numerirani, moramo ih nekako pohraniti u memoriju uređaja. Da bismo to učinili, smjestit ćemo ih u tablicu koja se naziva tablica atributa. Pažljivo zapamtite ovo. Ovo je samo srce BLE-a. To ćemo dalje ispitivati. Od sada ćemo svaki redak nazivati atributom. Ova tablica se nalazi duboko u stogu i, u pravilu, nemamo izravan pristup njoj. Inicijaliziramo je i pristupamo joj, ali što se događa unutra je misterij.
Pogledajmo sliku iz specifikacije, ali prije toga, želim istaknuti uobičajenu zbrku u terminima, točnije deskriptorima. Uloga deskriptora je nadopuniti opis karakteristike. Deskriptori se koriste kada je potrebno proširiti njegove mogućnosti. Oni su također atributi i, poput usluga i karakteristika, nalaze se u tablici atributa. Detaljno ćemo ih raspraviti u drugom dijelu članka. Međutim, ponekad se deskriptori koriste za označavanje broja retka u tablici atributa. To treba imati na umu. Kako bismo izbjegli zbrku, za te ćemo svrhe koristiti izraz "pokazivač atributa".
Dakle, atribut je diskretna vrijednost koja ima sljedeća svojstva povezana s njom:
1. Ručka atributa je indeks tablice koji odgovara atributu.
2. Tip atributa je UUID koji opisuje njegov tip
3. Vrijednost atributa su podaci indeksirani pokazivačem atributa.
4. Dozvole atributa su dio atributa koji se ne može čitati ili pisati pomoću protokola atributa.
Kako bismo sve ovo trebali shvatiti? Indeks atributa je, grubo govoreći, njegov broj u našoj tablici.
Omogućuje klijentu referenciranje atributa u zahtjevima za čitanje ili pisanje. Možemo numerirati naše retke (atribute) od 0x0001 do 0xFFFF. U našoj metafori police za knjige, ovo je broj kartice u papirnatom katalogu. Slično kao i u knjižničnom katalogu, kartice su poredane uzlaznim redoslijedom. Broj svakog sljedećeg retka mora biti veći od prethodnog. Baš kao što se u knjižnici kartice ponekad izgube, tako se mogu izgubiti i praznine u brojevima redaka. To je prihvatljivo. Glavno je da su u uzlaznom redoslijedu.
Tip atributa definira što atribut predstavlja. Slično kao u C jeziku,
Tamo gdje postoje logičke vrijednosti, numeričke varijable i nizovi znakova, ovdje je isto. Po tipu atributa znamo
S čime se ovdje suočavamo i kako bismo trebali postupiti s ovim atributom? U nastavku ćemo pogledati neke specifične tipove atributa. Na primjer, "deklaracija usluge" (0x2800), "deklaracija karakteristike" (0x2803) i "deklaracija deskriptora" (0x2902).
Vrijednost atributa je njegova stvarna vrijednost, oprostite na tautologiji. Ako je tip atributa niz znakova, njegova vrijednost može biti, na primjer, slogan "Pozdrav svijete!!!". Ako je tip atributa "deklaracija usluge", njegova vrijednost je sama usluga. Ponekad su to informacije o tome gdje pronaći druge atribute i njihova svojstva.
Dozvole atributa omogućuju poslužitelju da odredi je li dopušten pristup za čitanje ili pisanje.
Imajte na umu da se ova dopuštenja primjenjuju samo na vrijednost atributa, a ne na pokazivač, tip ili samo polje dopuštenja. Dakle, ako se atribut može pisati, možemo promijeniti, na primjer, niz "Pozdrav svijete!!!" u "Dobro jutro". Međutim, ne možemo zabraniti pisanje znaka za novi redak ili promijeniti tip atributa i označiti niz kao "deklaraciju usluge". Kada klijent pristupi poslužitelju, klijent traži njegove atribute. To omogućuje klijentu da odredi što poslužitelj može pružiti, iako čitanje i pisanje vrijednosti nije potrebno.
Kako izgleda
Koncept GATT-a je grupiranje atributa u tablici atributa zajedno vrlo specifičnim i logičnim redoslijedom. Pogledajmo pobliže profil otkucaja srca u nastavku. Krajnji lijevi stupac ove tablice je opcionalan. On jednostavno opisuje što je ovaj redak (atribut). Svi ostali stupci su već poznati.
Na vrhu svake grupe uvijek imamo atribut deklaracije usluge. Njegov tip je uvijek 0x2800, a njegov indeks ovisi o tome koliko se atributa već nalazi u tablici. Njegova dopuštenja su uvijek samo za čitanje, bez ikakve autentifikacije ili autorizacije. O tim ćemo konceptima raspravljati kasnije. Vrijednost je još jedan UUID koji identificira uslugu. U tablici je vrijednost 0x180D, što je Bluetooth SIG definirao kao uslugu mjerenja otkucaja srca.
Nakon deklaracije usluge slijedi deklaracija karakteristike. Sličnog je oblika deklaraciji usluge. Njezin UUID je uvijek 0x2803, a dopuštenja su također uvijek samo za čitanje, bez ikakve autentifikacije ili autorizacije. Pogledajmo polje Vrijednost atributa, koje sadrži neke podatke. Uvijek sadrži pokazivač, UUID i skup svojstava. Ova tri elementa opisuju sljedeću deklaraciju vrijednosti karakteristike. Pokazivač prirodno označava lokaciju deklaracije vrijednosti karakteristike u tablici atributa. UUID opisuje koju vrstu informacija ili vrijednosti možemo očekivati - na primjer, vrijednost temperature, stanje prekidača za svjetlo ili neku drugu proizvoljnu vrijednost. Konačno, svojstva opisuju kako komunicirati s vrijednošću karakteristike.
Ovdje nas čeka još jedna zamka. Ima veze s dopuštenjima atributa i karakterističnim svojstvima. Pogledajmo sliku svojstava bitnog polja iz specifikacije.
Kao što vidite, ovdje postoje i polja koja omogućuju pristup čitanju i pisanju. Možda se pitate zašto imamo dozvole za čitanje/pisanje za atribut i svojstvo.
Dozvole za čitanje/pisanje za karakterističnu vrijednost? Ne bi li uvijek trebale biti iste? Stvar je u tome što su svojstva za karakterističnu vrijednost u biti samo preporuke klijenta koje se koriste u GATT-u i slojevima aplikacije. To su jednostavno nagovještaji o tome što klijent može očekivati od atributa deklaracije karakteristike. Pogledajmo to pobliže. Koje vrste dozvola ima atribut?
1. Dozvole za pristup:
- čitanje
— snimanje
— čitanje i pisanje
2. Dozvola za autentifikaciju:
— potrebna je autentifikacija
- nije potrebna autentifikacija
3. Dozvola za autorizaciju:
- potrebna je autorizacija
- nije potrebna autorizacija
Glavna razlika između dozvola atributa i karakterističnih svojstava je u tome što su prva specifična za poslužitelj, dok su druga specifična za klijenta. Poslužitelj može dopustiti čitanje vrijednosti karakteristike, ali i dalje zahtijevati autentifikaciju ili autorizaciju. Stoga, kada klijent zatraži svojstva karakteristike, vidjet ćemo da je čitanje dopušteno. Međutim, pokušaj čitanja rezultirat će pogreškom. Stoga možemo sa sigurnošću reći da dozvole imaju prednost nad svojstvima. Mi, na strani klijenta, nemamo načina znati koja dopuštenja atribut ima.
Deskriptor
Vratimo se našoj tablici. Nakon deklaracije vrijednosti karakteristike, moguće su sljedeće deklaracije atributa:
1. Objava nove karakteristike (u usluzi može biti više karakteristika)
2. Nova deklaracija usluge (u tablici ih može biti mnogo)
3. Deklaracija deskriptora
U slučaju karakteristike mjerenja otkucaja srca u našoj tablici, deklaracija vrijednosti karakteristike popraćena je deklaracijom deskriptora. Deskriptor je atribut koji sadrži dodatne informacije o karakteristici. Postoji nekoliko vrsta deskriptora, o kojima ćemo detaljno raspravljati u drugom dijelu ovog članka. Za sada ćemo se dotaknuti samo deskriptora konfiguracije karakteristike klijenta (CCCD). Ima UUID 0x2902. Koristeći ovaj deskriptor, klijent može omogućiti ili indikaciju ili obavijest na poslužitelju. Razlika između njih je suptilna, ali ipak postoji. Obavijest ne zahtijeva potvrdu primitka od klijenta. Indikacija zahtijeva, iako se događa na GATT razini, a ne na razini aplikacije. Zašto je to tako, pitate se? Nažalost, ne znam. Reći ću samo da nordijski stručnjaci preporučuju korištenje obavijesti. Štoviše, provjera integriteta paketa (korištenjem CRC-a) događa se u oba slučaja.
Zaključak
Na kraju članka želio bih reći sljedeće. Posljednja tablica je malo zbunjujuća. Međutim, zaustavio sam se na njoj jer je dana u , na koji se oslanjam. U drugom dijelu svog članka namjeravam dublje istražiti specifikaciju Bluetooth 4.0. Tamo nas čekaju točniji dijagrami i ilustracije. U trećem dijelu želio bih analizirati zapisnik dobiven s jednog od uređaja pomoću Wiresharka i vidjeti svu teoriju koju smo proučavali u praksi.
Zaposlenik Grupe tvrtki
Vladimir Pečerski
Izvor: www.habr.com
