BLE pod mikroskopom (ATTy GATTy…)
Dio 1, pregled
Već je prošlo dosta vremena od objavljivanja prve specifikacije za Bluetooth 4.0. I, iako je BLE tema vrlo interesantna, ona i dalje odbija mnoge programere zbog svoje složenosti. U svojim prethodnim člancima, uglavnom sam gledao na najniži nivo, sloj linkova i fizički sloj. To nam je omogućilo da izbjegnemo pribjegavanje tako složenim i zbunjujućim konceptima kao što su Protokol atributa (ATT) i Generalni profil atributa (GATT). Međutim, nema kuda ići, bez njihovog razumijevanja nemoguće je razviti kompatibilne uređaje. Danas bih želio podijeliti ovo znanje sa vama. U svom članku ću se osloniti za početnike sa nordijske web stranice. Pa počnimo.
Zašto je sve tako teško?
Po mom mišljenju, odmah je bilo jasno da je upravljanje uređajima putem pametnih telefona vrlo obećavajuća i dugotrajna tema. Stoga su odlučili da ga odmah i maksimalno strukturiraju. Tako da proizvođači raznih naprava ne osmisle svoje protokole, koji će onda biti nekompatibilni. Otuda i poteškoća. Već u prvoj fazi pokušali su sve moguće ugurati u BLE protokol. I nije bitno da li će kasnije biti od koristi ili ne. Osim toga, predviđena je mogućnost proširenja liste uređaja za budućnost.
Pogledajmo sliku na kojoj je nacrtan dijagram BLE protokola. Sastoji se od nekoliko slojeva. Najniži, fizički sloj (PHY) je odgovoran za radio kanal uređaja. Sloj veze (LL) sadrži čitav niz bajtova u poslanoj poruci. U prethodnim člancima proučavali smo upravo to. Host Controller Interface (HCI) je protokol za razmjenu između BLE slojeva ili čipova ako su kontroler i host implementirani na različitim čipovima. Logical Link Control and Adaptation Protocol (L2CAP) je odgovoran za formiranje paketa, uokvirivanje, kontrolu grešaka i sastavljanje paketa. Security Manager Protocol (SMP) je odgovoran za šifriranje paketa. General Access Profile (GAP) je odgovoran za početnu razmjenu podataka između uređaja kako bi se utvrdilo „Ko je ko“. Također uključuje skeniranje i oglašavanje. U ovom članku ću se fokusirati na dva preostala dijela protokola - GATT i ATT. GATT je nadgradnja ATT-a, tako da su oni usko isprepleteni.
Da pojednostavim priču, želio bih se okrenuti analogiji. Negdje sam to čuo i želio bih to podržati. Zamislite BLE uređaj kao policu za knjige sa nekoliko polica. Svaka polica je posebna tema. Na primjer, imamo police sa naučnom fantastikom, matematikom i enciklopedijama. Na svakoj polici nalaze se knjige sa određenom temom. A neke knjige čak imaju i papirne oznake sa bilješkama. Osim toga, imamo i mali papirni katalog svih knjiga. Ako se sećate, školske biblioteke su uska kutija sa papirnim karticama. Uz ovu analogiju, ormar je profil našeg uređaja. Police su usluge, knjige su karakteristike, a katalog je tablica atributa. Oznake u knjigama su deskriptori, o čemu ću kasnije detaljnije govoriti.
Svako ko je razvijao uređaje zna da mnogi projekti imaju slične dijelove koda. Činjenica je da mnogi uređaji imaju sličnu funkcionalnost. Na primjer, ako se uređaji napajaju baterijama, onda će problem punjenja i praćenja njihovog nivoa biti isti. Isto važi i za senzore. Zapravo, objektno orijentisani pristup programiranju “pruža mogućnost stvaranja objekata koji kombinuju svojstva i ponašanja u samostalnu zajednicu koja se zatim može ponovo koristiti”. Po mom mišljenju, BLE je pokušao sličan pristup. Profile je razvila Bluetooth posebna interesna grupa (SIG). Uređaji različitih proizvođača koji imaju iste profile trebali bi raditi jedni s drugima bez poteškoća. Profili se, pak, sastoje od usluga, i usluga karakteristika, dopunjenih deskriptorima. Generalno to bi moglo izgledati ovako:
Na primjer, razmotrite dijagram profila monitora otkucaja srca (fitnes narukvica). Sastoji se od dvije usluge i nekoliko karakteristika. Iz njega hijerarhija profila odmah postaje jasna. Karakteristika kontrolne tačke resetuje ukupni broj utrošenih kalorija na nulu.
1. Usluga otkucaja srca uključuje tri karakteristike (0x180D):
a) Obavezna karakteristika otkucaja srca (0x2A37)
b) Opciona karakteristika položaja senzora tela (0x2A38)
c) Uslovne karakteristike kontrolne tačke otkucaja srca (0x2A39)
2. Servis održavanja baterije (0x180F):
a) Obavezna karakteristika nivoa napunjenosti baterije (0x2A19)
UUID
Da bismo jedinstveno pristupili elementima profila (uslugama, karakteristikama i deskriptorima), moramo ih sve nekako numerirati. U tu svrhu uvodi se koncept kao što je Univerzalno jedinstveni ID (UUID) ili Univerzalno jedinstveni identifikator. UUID je naznačen u zagradama svakog reda. I tu postoji jedna posebnost. Za UUID smo odlučili da koristimo kod od 16 i 128 bita. Zašto pitate? U BLE protokolu sve se odnosi na očuvanje energije. Stoga je dimenzija od 16 bita sasvim razumna. Malo je vjerovatno da će u bliskoj budućnosti biti stvoreno više od 65 hiljada. jedinstvene usluge i karakteristike. Trenutno je sve što su mogli već izbrojati (zapamtite otkud ovo - "i on vas je brojao" :-)) Numerirani elementi , , и možete pogledati na linkovima.
Međutim, mislim da se svi sjećaju priče sa 4 bajta IP adresa na internetu. U početku smo mislili da je to dovoljno, ali sada još uvijek ne možemo preći na 6-bajtnu adresu. Kako ne bi ponovio ovu grešku i dao slobodu razigranim rukama DIYers-a, SIG je odmah odlučio uvesti 128-bitne UUID-ove. Ovo me lično podseća na nelicencirani opseg od 433 MHz, koji su davali svakakvim Kulibinama sa radio kanala. U našem slučaju, 128-bitni identifikator usluga i karakteristika je izdvojen. To znači da mi, za naše usluge i uređaje, možemo koristiti gotovo bilo koju 128-bitnu vrijednost. Svejedno, vjerovatnoća da se dođe do istog UUID-a teži nuli.
U stvari, kratki 16-bitni UUID-ovi imaju proširenje na 128-bitnu vrijednost. U specifikaciji, ovo proširenje se zove Bluetooth Base UUID i ima vrijednost 00000000-0000-1000-8000-00805F9B34FB. Ako, na primjer, 16-bitni atribut UUID ima vrijednost 0x1234, tada će ekvivalentni 128-bitni UUID imati vrijednost 00001234-0000-1000-8000-00805F9B34FB. Čak je data i odgovarajuća formula:
128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID
Ne znam odakle je došao ovaj magični broj. Ako neko od čitalaca zna, neka napiše u komentarima (korisnik sa nadimkom Sinopteek je to već uradio. Pogledajte komentare). Što se tiče osmišljavanja 128-bitnih UUID-ova, u principu možete koristiti poseban ko će to uraditi za tebe.
ATTy GATTy...
Zapravo, tada počinje zabava. Da vas podsjetim da je ATT zasnovan na odnosu klijent-server. Sada gledamo na serverski uređaj. Sadrži informacije kao što su vrijednosti senzora, status prekidača svjetla, podaci o lokaciji, itd. Sada kada su svi "učesnici naše parade" pobrojani, moramo ih nekako smjestiti u memoriju uređaja. Da bismo to uradili, stavljamo ih u tabelu koja se zove tabela atributa. Zapamtite ovo dobro. Ovo je samo srce BLE-a. To je ono što ćemo dalje razmotriti. Sada ćemo svaki red nazvati atributom. Ova tabela se nalazi duboko u steku i, po pravilu, nemamo direktan pristup njoj. Inicijaliziramo ga i pristupamo mu, ali ono što se događa unutra je skriveno od nas iza sedam pečata.
Pogledajmo sliku iz specifikacije, ali prije toga bih odmah skrenuo pažnju na čestu zabunu u terminima, odnosno u deskriptorima. Uloga deskriptora je da dopuni opis karakteristike. Kada je potrebno proširiti njegove mogućnosti, onda se koriste deskriptori. Oni su također atributi, i baš kao i usluge i karakteristike, nalaze se u tabeli atributa. Detaljnije ćemo ih ispitati u drugom dijelu članka. Međutim, ponekad se deskriptori odnose na broj reda u tablici atributa. Ovo se mora imati na umu. Da bismo izbjegli zabunu, koristit ćemo termin „pokazivač atributa“ u ove svrhe.
Dakle, atribut je diskretna vrijednost koja ima sljedeća svojstva povezana s njim:
1. Ručica atributa je indeks tabele koji odgovara atributu
2. Tip atributa je UUID koji opisuje njegov tip
3. Vrijednost atributa je podatak indeksiran pokazivačem atributa
4. Atribut Dozvole su dio atributa, dozvole, koje se ne mogu čitati ili pisati korištenjem atributnog protokola
Kako sve ovo razumjeti? Pokazivač atributa je, relativno govoreći, njegov broj u našoj tabeli.
Omogućava klijentu da referencira atribut u zahtjevima za čitanje ili pisanje. Možemo numerisati naše redove (atribute) od 0x0001 do 0xFFFF. U našoj asocijaciji na ormar za knjige, ovo je broj kartice u katalogu papira. Slično, kao iu bibliotečkom katalogu, kartice su raspoređene po rastućem redoslijedu broja. Broj svakog sljedećeg reda mora biti veći od prethodnog. Kao i u biblioteci, ponekad se neke kartice izgube, tako da kod nas mogu biti praznine u numeraciji redova. Ovo je dozvoljeno. Glavna stvar je da idu progresivno.
Tip atributa određuje šta atribut predstavlja. Po analogiji sa jezikom C,
gdje postoje logičke, numeričke varijable i stringovi, tako je i ovdje. Po tipu atributa prepoznajemo
sa čime imamo posla i kako možemo nastaviti da radimo sa ovim atributom. U nastavku ćemo pogledati neke specifične vrste atributa. Na primjer, “deklaracija usluge” (0x2800), “deklaracija karakteristika” (0x2803), “deklaracija deskriptora” (0x2902).
Vrijednost atributa je njegovo stvarno značenje, oprostite na tautologiji. Ako je tip atributa string, tada vrijednost atributa može biti, na primjer, slogan “Hello World !!!”. Ako je tip atributa “deklaracija usluge”, tada je njegova vrijednost sama usluga. A ponekad je to informacija o tome gdje pronaći druge atribute i njihova svojstva.
Dozvole za atribute omogućavaju serveru da shvati da li je dozvoljen pristup za čitanje ili pisanje.
Imajte na umu da se ove dozvole primjenjuju samo na vrijednost atributa, a ne na samo polje pokazivača, tipa ili dozvole. One. ako je snimanje atributa dozvoljeno, tada možemo promijeniti, na primjer, red "Hello World !!!" na red “Dobro jutro”. Ali ne možemo zabraniti pisanje novog reda ili promijeniti tip atributa i označiti red kao „deklaraciju usluge“. Kada klijent kontaktira server, klijent traži njegove atribute. Ovo omogućava klijentu da zna šta server može pružiti. Iako nije potrebno čitati i pisati vrijednosti.
Kako izgleda
Koncept GATT-a je da grupiše atribute u tabeli atributa zajedno u vrlo specifičnom i logičnom redosledu. Pogledajmo bliže profil otkucaja srca u nastavku. Krajnja lijeva kolona ove tabele nije obavezna. Jednostavno nam opisuje šta je ova linija (atribut). Sve ostale rubrike su nam već poznate.
Na vrhu svake grupe uvijek imamo atribut deklaracije usluge. Njegov tip je uvijek 0x2800, a pokazivač ovisi o tome koliko je atributa već prisutno u tabeli. Njegove dozvole su uvijek samo za čitanje, bez ikakve autentifikacije ili autorizacije. O ovim konceptima ćemo govoriti malo kasnije. Vrijednost je drugi UUID koji identificira što je usluga. U tabeli, vrijednost je 0x180D, koju Bluetooth SIG definira kao uslugu otkucaja srca.
Nakon objave usluge slijedi objava karakteristike. Po obliku je sličan deklaraciji usluge. Njegov UUID je uvijek 0x2803, a njegove dozvole su uvijek samo za čitanje bez ikakve autentifikacije ili autorizacije. Pogledajmo polje Vrijednost atributa, koje uključuje neke podatke. Uvijek sadrži pokazivač, UUID i skup svojstava. Ova tri elementa opisuju naknadnu deklaraciju karakteristične vrijednosti. 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 svjetla ili neka druga proizvoljna vrijednost. I na kraju svojstva, koja opisuju kako se karakteristična vrijednost može ostvariti u interakciji.
Ovdje nas čeka još jedna zamka. Povezana je s dozvolama atributa i svojstvima karakteristika. Pogledajmo sliku svojstava bitnog polja iz specifikacije.
Kao što vidite, ovdje postoje i polja koja pružaju mogućnosti čitanja i pisanja. Možda se pitate zašto imamo dozvole za čitanje/pisanje za atribute i svojstva
čitati/pisati za karakterističnu vrijednost? Zar ne bi trebalo da uvek budu isti? Činjenica je da su svojstva za karakterističnu vrijednost zapravo samo preporuke za klijenta koji se koristi u GATT i aplikacijskim slojevima. Ovo su samo nagoveštaji o tome šta klijent može očekivati od atributa deklaracije karakteristike. Pogledajmo ovo detaljnije. Koje vrste dozvola ima atribut?
1. Pristupne dozvole:
- čitanje
— zapis
- citaj i pisi
2. Dozvola za autentifikaciju:
- potrebna je autentikacija
- nije potrebna autentifikacija
3. Dozvola za autorizaciju:
— potrebno je ovlaštenje
- nije potrebno odobrenje
Glavna razlika između rezolucije atributa i karakterističnih svojstava je u tome što se prva primjenjuju na servere, a druga na klijente. Serveru može biti dozvoljeno da pročita vrijednost karakteristike, ali može zahtijevati autentifikaciju ili autorizaciju. Stoga, kada klijent zatraži svojstva karakteristike, dobićemo da je čitanje dozvoljeno. Ali kada pokušamo da pročitamo, dobijamo grešku. Stoga možemo sa sigurnošću govoriti o prioritetu dozvola nad svojstvima. Na strani klijenta, ne možemo dobiti znanje o tome koje dozvole ima atribut.
Deskriptor
Vratimo se našem stolu. Nakon deklariranja vrijednosti karakteristike, moguće su sljedeće deklaracije atributa:
1. Nova deklaracija karakteristika (usluga može imati mnogo karakteristika)
2. Nova deklaracija usluge (možda ih ima mnogo u tabeli)
3. Deklarisanje ručke
U slučaju karakteristike mjerenja otkucaja srca, u našoj tabeli, deklaracija vrijednosti karakteristike prati i deklaracija deskriptora. Deskriptor je atribut s dodatnim informacijama o karakteristici. Postoji nekoliko tipova deskriptora. O njima ćemo detaljno govoriti u drugom dijelu ovog članka. Za sada ćemo se dotaknuti samo Deskriptora konfiguracije karakteristika klijenta (CCCD). Ima UUID jednak 0x2902. Koristeći ovaj deskriptor, klijent ima mogućnost da omogući indikaciju ili obavijest na serveru. Razlika između njih je mala, ali ipak postoji. Obavijest ne zahtijeva potvrdu prijema od strane klijenta. Indikacija to zahtijeva, iako se javlja na GATT nivou, ne dostižući nivo aplikacije. Zašto, pitate se? Jao, ja ovo ne znam. Samo da kažem da nordijski stručnjaci preporučuju korištenje obavijesti. Štaviše, provera integriteta paketa (pomoću CRC) se dešava u oba slučaja.
zaključak
Na kraju članka želio bih ovo reći. Poslednja tabela je malo zbunjujuća. Međutim, odabrao sam ga jer je popušta , na koju se oslanjam. U drugom dijelu mog članka namjeravam dublje proći u specifikaciju BlueTooth 4.0. Tamo nas očekuju ispravniji dijagrami i crteži. U trećem dijelu, želio bih raščlaniti zapisnik dobiven korištenjem programa Wireshark iz jednog od gadžeta i vidjeti "uživo" svu teoriju koju proučavamo.
Zaposlenik Grupe kompanija
Pecherskikh Vladimir
izvor: www.habr.com
