BLE pod mikroskopom (ATTы GATTы…)
1. del, pregled
Precej časa je že minilo od objave prve specifikacije za Bluetooth 4.0. In čeprav je tema BLE zelo zanimiva, še vedno odvrne številne razvijalce zaradi svoje kompleksnosti. V prejšnjih člankih sem si ogledal predvsem najnižjo raven, povezovalni sloj in fizični sloj. To nam je omogočilo, da se izognemo uporabi tako zapletenih in zmedenih konceptov, kot sta protokol atributov (ATT) in splošni profil atributov (GATT). Vendar pa ni kam iti, brez njihovega razumevanja je nemogoče razviti združljive naprave. Danes bi rad to znanje delil z vami. V svojem članku se bom zanašal na za začetnike s spletne strani Nordic. Pa začnimo.
Zakaj je vse tako težko?
Po mojem mnenju je bilo takoj jasno, da je upravljanje naprav preko pametnih telefonov zelo perspektivna in dolgotrajna tema. Zato so se odločili, da ga takoj in maksimalno strukturirajo. Da si proizvajalci različnih pripomočkov ne izmislijo lastnih protokolov, ki bodo potem nezdružljivi. Od tod težave. Že na prvi stopnji so poskušali v protokol BLE stlačiti vse mogoče. In ni pomembno, ali bo pozneje uporabno ali ne. Poleg tega so predvideli možnost razširitve seznama naprav za prihodnost.
Poglejmo si sliko, kjer je narisan diagram protokola BLE. Sestavljen je iz več plasti. Najnižja, fizična plast (PHY) je odgovorna za radijski kanal naprave. Link Layer (LL) vsebuje celotno zaporedje bajtov v poslanem sporočilu. V prejšnjih člankih smo preučevali točno to. Host Controller Interface (HCI) je protokol za izmenjavo med plastmi ali čipi BLE, če sta krmilnik in gostitelj implementirana na različnih čipih. Logical Link Control and Adaptation Protocol (L2CAP) je odgovoren za oblikovanje paketov, okvirjanje, nadzor napak in sestavljanje paketov. Protokol varnostnega upravitelja (SMP) je odgovoren za šifriranje paketov. Profil splošnega dostopa (GAP) je odgovoren za začetno izmenjavo podatkov med napravami za določitev »kdo je kdo«. Vključuje tudi skeniranje in oglaševanje. V tem članku se bom osredotočil na dva preostala dela protokola - GATT in ATT. GATT je nadgradnja ATT, zato sta tesno prepletena.
Za poenostavitev zgodbe bi se rad obrnil na analogijo. Nekje sem slišal in bi ga rad podprl. Napravo BLE si predstavljajte kot knjižno omaro z več policami. Vsaka polica je posebna tema. Imamo na primer police z znanstveno fantastiko, matematiko in enciklopedijami. Na vsaki polici so knjige z določeno tematiko. In nekatere knjige imajo celo papirnate zaznamke z opombami. Poleg tega imamo majhen papirni katalog vseh knjig. Če se spomnite, so šolske knjižnice ozke škatle s papirnatimi kartami. S to analogijo je omarica profil naše naprave. Police so storitve, knjige so karakteristike, katalog pa atributna tabela. Zaznamki v knjigah so deskriptorji, o katerih bom kasneje tudi podrobneje govoril.
Vsakdo, ki je razvijal naprave, ve, da ima veliko projektov podobne dele kode. Dejstvo je, da ima veliko naprav podobno funkcionalnost. Na primer, če naprave napajajo baterije, bo problem polnjenja in spremljanja njihove ravni enak. Enako velja za senzorje. Pravzaprav objektno usmerjen pristop k programiranju »zagotavlja možnost ustvarjanja objektov, ki združujejo lastnosti in vedenja v samostojno zvezo, ki jo je mogoče nato ponovno uporabiti«. Po mojem mnenju je BLE poskušal podoben pristop. Profile je razvila Bluetooth Special Interest Group (SIG). Naprave različnih proizvajalcev, ki imajo enake profile, bi morale brez težav delovati med seboj. Profile pa sestavljajo storitve in storitve značilnosti, dopolnjene z deskriptorji. Na splošno bi lahko izgledalo takole:
Na primer, razmislite o diagramu profila merilnika srčnega utripa (fitnes zapestnica). Sestavljen je iz dveh storitev in več značilnosti. Iz tega takoj postane jasna hierarhija profilov. Značilnost kontrolne točke ponastavi skupno število porabljenih kalorij na nič.
1. Storitev srčnega utripa vključuje tri značilnosti (0x180D):
a) Obvezna karakteristika srčnega utripa (0x2A37)
b) Opcijska karakteristika položaja senzorja telesa (0x2A38)
c) Pogojne značilnosti kontrolne točke srčnega utripa (0x2A39)
2. Storitev vzdrževanja baterije (0x180F):
a) Obvezna karakteristika stopnje napolnjenosti baterije (0x2A19)
UUID
Da lahko enolično dostopamo do elementov profila (storitev, karakteristik in deskriptorjev), jih moramo vse nekako oštevilčiti. V ta namen je uveden koncept, kot je univerzalni enolični ID (UUID) ali univerzalni enolični identifikator. UUID je naveden v oklepajih vsake vrstice. In tu je ena posebnost. Za UUID smo se odločili za uporabo kode dolžine 16 in 128 bitov. Zakaj vprašaš? V protokolu BLE je vse o varčevanju z energijo. Zato je dimenzija 16 bitov povsem razumna. Malo verjetno je, da jih bo v bližnji prihodnosti ustvarjenih več kot 65 tisoč. edinstvene storitve in lastnosti. Trenutno so vse, kar so lahko že prešteli (se spomnite, od kod je to prišlo - "tebe je tudi preštel" :-)) Oštevilčeni elementi , , и si lahko ogledate na povezavah.
Mislim pa, da se vsi spomnijo zgodbe s 4 bajti IP naslovov na internetu. Sprva smo mislili, da je to dovolj, zdaj pa še vedno ne moremo preklopiti na 6-bajtni naslov. Da ne bi ponovili te napake in dali prosto pot igrivim rokam DIYerjev, se je SIG takoj odločil uvesti 128-bitne UUID-je. To me osebno spominja na nelicencirani pas 433 MHz, ki so ga dali vsem vrstam Kulibinov iz radijskega kanala. V našem primeru je bil izločen 128-bitni identifikator storitev in značilnosti. To pomeni, da lahko za naše storitve in naprave uporabimo skoraj vsako 128-bitno vrednost. Kljub temu se verjetnost, da boste dobili enak UUID, nagiba k ničli.
Pravzaprav imajo kratki 16-bitni UUID-ji razširitev na 128-bitno vrednost. V specifikaciji se ta razširitev imenuje Bluetooth Base UUID in ima vrednost 00000000-0000-1000-8000-00805F9B34FB. Če ima na primer 16-bitni atribut UUID vrednost 0x1234, bo enakovredni 128-bitni UUID imel vrednost 00001234-0000-1000-8000-00805F9B34FB. In podana je celo ustrezna formula:
128_bitna_vrednost = 16_bitna_vrednost * 2^96 + Bluetooth_Base_UUID
Ne vem, od kod ta čarobna številka. Če kdo od bralcev ve, naj napiše v komentar (To je že naredil uporabnik z vzdevkom Sinopteek. Glej komentarje). Kar zadeva pripravo 128-bitnih UUID-jev, načeloma lahko uporabite poseben kdo bo to naredil namesto vas.
ATTy GATTy ...
Pravzaprav se zabava začne. Naj vas spomnim, da ATT temelji na razmerju odjemalec-strežnik. Zdaj gledamo strežniško napravo. Vsebuje informacije, kot so vrednosti senzorjev, stanje stikala za luči, podatki o lokaciji itd. Zdaj, ko so vsi »udeleženci naše parade« oštevilčeni, jih moramo nekako spraviti v pomnilnik naprave. Da bi to naredili, jih postavimo v tabelo, imenovano tabela atributov. To si dobro zapomnite. To je srce BLE. To bomo obravnavali naprej. Zdaj bomo vsako vrstico imenovali atribut. Ta tabela se nahaja globoko v skladu in do nje praviloma nimamo neposrednega dostopa. Inicializiramo ga in dostopamo do njega, toda dogajanje v notranjosti je pred nami skrito za sedmimi pečati.
Poglejmo sliko iz specifikacije, pred tem pa bi rad takoj opozoril na pogosto zmedo v terminih, in sicer v deskriptorjih. Vloga deskriptorja je dopolnjevanje opisa značilnosti. Ko je treba razširiti njegove zmogljivosti, se uporabljajo deskriptorji. So tudi atributi in tako kot storitve in karakteristike se nahajajo v tabeli atributov. Podrobneje jih bomo preučili v drugem delu članka. Vendar se deskriptorji včasih nanašajo na številko vrstice v tabeli atributov. To je treba upoštevati. Da bi se izognili zmedi, bomo za te namene uporabili izraz "kazalec atributov".
Atribut je torej diskretna vrednost, ki ima z njo povezane naslednje lastnosti:
1. Ročaj atributa je indeks tabele, ki ustreza atributu
2. Tip atributa je UUID, ki opisuje njegovo vrsto
3. Vrednost atributa je podatek, indeksiran s kazalcem atributa
4. Dovoljenja atributa so del atributa, dovoljenja, ki jih ni mogoče prebrati ali zapisati z uporabo protokola atributa
Kako vse to razumeti? Kazalec atributa je, relativno gledano, njegova številka v naši tabeli.
Odjemalcu omogoča sklicevanje na atribut v zahtevah za branje ali pisanje. Naše vrstice (atribute) lahko oštevilčimo od 0x0001 do 0xFFFF. V naši povezavi s knjižno omaro je to številka kartice v papirnatem katalogu. Podobno, kot v knjižničnem katalogu, so kartice razvrščene po naraščajočem vrstnem redu števila. Število vsake naslednje vrstice mora biti večje od prejšnje. Tako kot se v knjižnici včasih kakšna karta izgubi, tudi pri nas lahko pride do vrzeli v številčenju vrstic. To je dovoljeno. Glavna stvar je, da gredo postopoma.
Vrsta atributa določa, kaj atribut predstavlja. Po analogiji z jezikom C,
kjer so logične vrednosti, številske spremenljivke in nizi, tako je tudi tukaj. Po vrsti atributa prepoznamo
s čim imamo opravka in kako lahko nadaljujemo delo s tem atributom. Spodaj si bomo ogledali nekatere posebne vrste atributov. Na primer, "izjava storitve" (0x2800), "deklaracija značilnosti" (0x2803), "deklaracija deskriptorja" (0x2902).
Vrednost atributa je njegov dejanski pomen, oprostite tavtologiji. Če je vrsta atributa niz, je lahko vrednost atributa na primer slogan »Hello World !!!«. Če je tip atributa "storitvena deklaracija", potem je njegova vrednost sama storitev. In včasih so to informacije o tem, kje najti druge atribute in njihove lastnosti.
Dovoljenja atributov omogočajo strežniku, da razume, ali je dovoljen dostop za branje ali pisanje.
Upoštevajte, da ta dovoljenja veljajo samo za vrednost atributa in ne za samo polje kazalca, vrste ali dovoljenja. Tisti. če je snemanje atributa dovoljeno, potem lahko spremenimo na primer vrstico "Hello World !!!" na vrstico "Dobro jutro". Ne moremo pa prepovedati pisanja nove vrstice ali spremeniti vrste atributa in vrstice označiti kot »storitveno deklaracijo«. Ko odjemalec vzpostavi stik s strežnikom, odjemalec zahteva njegove atribute. To odjemalcu omogoča, da ve, kaj lahko zagotovi strežnik. Čeprav ni potrebno brati in pisati vrednosti.
Kako izgleda?
Koncept GATT je združevanje atributov v tabeli atributov v zelo specifičnem in logičnem vrstnem redu. Oglejmo si podrobneje spodnji profil srčnega utripa. Skrajni levi stolpec te tabele ni obvezen. Preprosto nam opiše, kaj je ta vrstica (atribut). Vsi ostali stolpci so nam že znani.
Na vrhu vsake skupine imamo vedno atribut storitvene deklaracije. Njegov tip je vedno 0x2800, kazalec pa je odvisen od tega, koliko atributov je že prisotnih v tabeli. Njegova dovoljenja so vedno samo za branje, brez kakršnega koli preverjanja pristnosti ali avtorizacije. O teh konceptih bomo govorili malo kasneje. Vrednost je drug UUID, ki identificira storitev. V tabeli je vrednost 0x180D, ki jo Bluetooth SIG definira kot storitev srčnega utripa.
Po objavi storitve sledi najava karakteristike. Po obliki je podobna izjavi o storitvi. Njegov UUID je vedno 0x2803, njegova dovoljenja pa so vedno samo za branje brez kakršnega koli preverjanja pristnosti ali avtorizacije. Poglejmo polje Vrednost atributa, ki vključuje nekaj podatkov. Vedno vsebuje kazalec, UUID in nabor lastnosti. Ti trije elementi opisujejo kasnejšo deklaracijo karakteristične vrednosti. Kazalec seveda označuje lokacijo deklaracije karakteristične vrednosti v tabeli atributov. UUID opisuje, kakšno vrsto informacij ali vrednosti lahko pričakujemo. Na primer vrednost temperature, stanje stikala za luč ali kakšno drugo poljubno vrednost. In končno lastnosti, ki opisujejo, kako je mogoče interakcijo z značilno vrednostjo.
Tu nas čaka še ena past. Povezan je z dovoljenji atributov in značilnimi lastnostmi. Poglejmo sliko lastnosti bitnega polja iz specifikacije.
Kot lahko vidite, so tukaj tudi polja, ki omogočajo zmožnosti branja in pisanja. Morda se sprašujete, zakaj imamo dovoljenja za branje/pisanje za atribut in lastnost
brati/pisati za karakteristično vrednost? Ali ne bi morali biti vedno enaki? Dejstvo je, da so lastnosti za karakteristično vrednost pravzaprav le priporočila za odjemalca, ki se uporablja v GATT in aplikacijskih slojih. To so le namigi o tem, kaj lahko odjemalec pričakuje od atributa karakteristične deklaracije. Oglejmo si to podrobneje. Katere vrste dovoljenj ima atribut?
1. Dovoljenja za dostop:
- branje
— zapis
- beri in piši
2. Dovoljenje za preverjanje pristnosti:
- potrebna je avtentikacija
- ni potrebna avtentikacija
3. Dovoljenje za avtorizacijo:
— potrebno je dovoljenje
- avtorizacija ni potrebna
Glavna razlika med ločljivostjo atributov in značilnimi lastnostmi je, da prve veljajo za strežnike, druge pa za odjemalce. Strežniku je morda dovoljeno prebrati karakteristično vrednost, vendar lahko zahteva avtentikacijo ali avtorizacijo. Torej, ko stranka zahteva lastnosti lastnosti, bomo prejeli, da je branje dovoljeno. Toda ko poskušamo brati, dobimo napako. Zato lahko mirno govorimo o prednosti dovoljenj pred lastnostmi. Na strani odjemalca ne moremo pridobiti znanja o tem, katera dovoljenja ima atribut.
Deskriptor
Vrnimo se k naši mizi. Po deklaraciji vrednosti karakteristike so možne naslednje deklaracije atributov:
1. Nova izjava o lastnostih (storitev ima lahko veliko lastnosti)
2. Nova izjava o storitvi (v tabeli jih je lahko veliko)
3. Deklaracija ročaja
Pri karakteristiki merjenja srčnega utripa je v naši tabeli deklaraciji karakteristične vrednosti priložena deklaracija deskriptorja. Deskriptor je atribut z dodatnimi informacijami o lastnosti. Obstaja več vrst deskriptorjev. O njih bomo podrobneje govorili v drugem delu tega članka. Za zdaj se bomo dotaknili samo konfiguracijskega deskriptorja lastnosti odjemalca (CCCD). Ima UUID enak 0x2902. Z uporabo tega deskriptorja ima odjemalec možnost omogočiti indikacijo ali obvestilo na strežniku. Razlika med njima je majhna, a še vedno obstaja. Obvestilo ne zahteva potrdila o prejemu od naročnika. Indikacija to zahteva, čeprav se pojavlja na ravni GATT in ne doseže ravni uporabe. Zakaj tako, se sprašujete? Žal, tega ne poznam. Naj povem le, da nordijski strokovnjaki priporočajo uporabo obvestil. Poleg tega se preverjanje celovitosti paketa (z uporabo CRC) pojavi v obeh primerih.
Zaključek
Na koncu članka bi rad povedal tole. Zadnja tabela je nekoliko zmedena. Vendar sem jo izbral, ker se vda , na katerega se zanašam. V drugem delu svojega članka se nameravam poglobiti v specifikacijo BlueTooth 4.0. Tam nas čakajo pravilnejši diagrami in risbe. V tretjem delu bi rad razčlenil dnevnik, pridobljen s programom Wireshark iz enega od pripomočkov, in videl "v živo" vso teorijo, ki jo preučujemo.
Zaposleni v skupini podjetij
Pecherskikh Vladimir
Vir: www.habr.com