BLE nĂ«n mikroskop (ATT dhe GATTâŠ)
Pjesa 1, përmbledhje
Ka kaluar një kohë e konsiderueshme që nga publikimi i specifikimit të parë për Bluetooth 4.0. Edhe pse tema BLE është shumë interesante, ajo ende pengon shumë zhvillues, për shkak të kompleksitetit të saj. Në artikujt e mi të mëparshëm kam shqyrtuar kryesisht nivelin më të ulët, Link Layer dhe Physical Layer. Kjo më lejonte të shmangja koncepte kaq të komplikuara dhe të ngatërruara si protokolli i atributeve (ATT) dhe profili i përgjithshëm i atributeve (GATT). Megjithatë, nuk ka rrugëdalje; pa i kuptuar ato, është e pamundur të zhvillosh pajisje të pajtueshme. Sot do të doja të ndaja këto njohuri me ju. Në artikullin tim do të mbështetem në për fillestarët nga faqja e Nordic. Le të fillojmë.
Pse është kaq e komplikuar?
Sipas mendimit tim, ishte e qartë menjëherë se menaxhimi i pajisjeve përmes smartphone-ve është një temë shumë premtuese dhe me qëndrueshmëri afatgjatë. Prandaj, vendosëm ta strukturojmë atë menjëherë dhe në maksimum. Që prodhuesit e pajisjeve të ndryshme të mos shpiknin protokolle të veta, të cilat më pas do të ishin të papërputhshme. Këtu lind e gjithë kompleksiteti. Që në fazën e parë, në protokollin BLE u përpoqëm të përfshijmë gjithçka që ishte e mundur. Dhe nuk ka rëndësi nëse do të nevojitet më vonë apo jo. Përveç kësaj, ne parashikuam mundësinë e zgjerimit të listës së pajisjeve për të ardhmen.
Le tĂ« hedhim njĂ« vĂ«shtrim nĂ« imazhin ku Ă«shtĂ« vizatuar njĂ« diagram i protokollit BLE. Ai pĂ«rbĂ«het nga disa nivele. Niveli mĂ« i ulĂ«t, niveli fizikal (PHY) Ă«shtĂ« pĂ«rgjegjĂ«s pĂ«r kanalin radio tĂ« pajisjes. Link Layer (LL) pĂ«rmban tĂ« gjithĂ« radhitjen e byte-ve nĂ« mesazhin e dĂ«rguar. NĂ« artikujt e kaluar, ne e studiojmĂ« atĂ«. Host Controller Interface (HCI) Ă«shtĂ« protokolli i shkĂ«mbimit midis niveleve ose çipeve BLE, nĂ«se Controller dhe Host janĂ« realizuar nĂ« çipa tĂ« ndryshĂ«m. Formimin e pakove, ndarjen nĂ« korniza, kontrollin e gabimeve dhe mbledhjen e pakove e menaxhon Protokolli i Kontrollit tĂ« Lidhjes Logjike dhe Adaptimit (L2CAP). PĂ«r enkriptimin e pakove kujdeset Protokolli i Menaxhimit tĂ« SigurisĂ« (SMP). Profili i qasjes sĂ« pĂ«rgjithshme (GAP) Ă«shtĂ« pĂ«rgjegjĂ«s pĂ«r shkĂ«mbimin fillestar tĂ« tĂ« dhĂ«nave midis pajisjeve, pĂ«r tĂ« pĂ«rcaktuar "Kush Ă«shtĂ« kush". Ai pĂ«rfshin gjithashtu skanimin dhe reklamimin. NĂ« kĂ«tĂ« artikull do tĂ« ndalem nĂ« dy pjesĂ«t e mbetura tĂ« protokollit â GATT dhe ATT. GATT Ă«shtĂ« njĂ« shtresĂ« mbi ATT, ndaj ata janĂ« shumĂ« tĂ« ndĂ«rthurrur.
PĂ«r tĂ« thjeshtuar narrativĂ«n, do tĂ« doja tĂ« pĂ«rdor njĂ« analogji. E kam dĂ«gjuar diku dhe do tĂ« doja ta mbĂ«shtes kĂ«tĂ«. Imagjinoni njĂ« pajisje BLE si njĂ« dollap libri me disa rafte. Ădo raft Ă«shtĂ« njĂ« tematikĂ« e veçantĂ«. PĂ«r shembull, kemi rafte pĂ«r fantastikĂ«n, matematikĂ«n, enciklopeditĂ«. NĂ« çdo raft qĂ«ndrojnĂ« libra me temĂ«n pĂ«rkatĂ«se. NĂ« disa prej librave ka madje edhe shĂ«nime tĂ« printuara. Gjithashtu, kemi njĂ« katalog tĂ« vogĂ«l nĂ« letĂ«r tĂ« tĂ« gjithĂ« librave. NĂ«se e kujtoni bibliotekat shkollore â Ă«shtĂ« njĂ« kuti e ngushtĂ« me karta letre. Duke pĂ«rdorur kĂ«tĂ« analogji, dollapi Ă«shtĂ« profili i pajisjes sonĂ«. Rafte janĂ« shĂ«rbimet, librat janĂ« karakteristikat, dhe katalogu Ă«shtĂ« tabela e atributeve. ShĂ«nimet nĂ« libra janĂ« deskriptuesit, pĂ«r tĂ« cilĂ«t do flas mĂ« vonĂ«, mĂ« nĂ« detaje.
Të gjithë ata që kanë zhvilluar pajisje e dinë se në shumë projekte ka pjesë kodesh të ngjashme. Në fakt, shumë pajisje kanë funksione të ngjashme. Për shembull, nëse pajisjet punojnë nga bateritë, problemi i karikimit dhe kontrollit të nivelit të tyre do të jetë i njëjtë. E njëjta vlen edhe për sensorët. Në thelb, qasja orientuar në objekte në programim ofron mundësinë për të krijuar objekte që lidhin veçoritë dhe sjelljet në një bashkim të pavarur, i cili mund të përdoret shpeshherë. Sipas mendimit tim, në BLE u ndërmor një përpjekje për një qasje të ngjashme. Grupi i Bluetooth Special Interest Group (SIG) ka zhvilluar profile. Pajisjet nga prodhues të ndryshëm, që kanë profile të njëjta, duhet të punojnë pa mundim me njëra-tjetrën. Profilet, nga ana tjetër, përbëhen nga shërbime, dhe shërbimet nga karakteristika, të plotësuara me deskriptorë. Në një rast të përgjithshëm, kjo mund të duket kështu:
Për shembull, le të shqyrtojmë skemën e profilit të monitorit të ritmit të zemrës (pajisja për ndjekjen e aktivitetit fizik). Ai përbëhet nga dy shërbime dhe disa karakteristika. Nga kjo, menjëherë kuptohet hierarkia e profilit. Karakteristika e pikës së kontrollit e reseton numërimin e përgjithshëm të shpenzimeve të kalorive në zero.
1. Shërbimi i ritmit të zemrës përfshin tre karakteristika (0x180D):
    a) Karakteristika obligative e frekuencës së ritmit të zemrës (0x2A37)
    b) Karakteristika opsionale e pozicionit të sensorit të trupit (0x2A38)
    c) Karakteristika kushtore e pikës së kontrollit të ritmit të zemrës (0x2A39)
2. Shërbimi i menaxhimit të batterisë (0x180F):
    a) Karakteristika obligative e nivelit të ngarkesës së baterisë (0x2A19)
UUID
PĂ«r tĂ« qenĂ« nĂ« gjendje tĂ« referohemi qartĂ« ndaj elementeve tĂ« profilit (shĂ«rbimeve, karakteristikave dhe descriptorĂ«ve), Ă«shtĂ« e nevojshme t'i numĂ«rojmĂ« ato. PĂ«r kĂ«tĂ« qĂ«llim, Ă«shtĂ« futur koncepti i Identifikuesit Unik Universal (UUID) ose Identifikuesi Unik Universal. NĂ« kllapin e çdo rreshti Ă«shtĂ« pikĂ«risht UUID. Dhe kĂ«tu ka njĂ« veçanti. PĂ«r UUID Ă«shtĂ« vendosur tĂ« pĂ«rdoret njĂ« kod me gjatĂ«si 16 dhe 128 bit. Pse, mund tĂ« pyesni? NĂ« protokollin BLE gjithçka Ă«shtĂ« nĂ«nshtruar ruajtjes sĂ« energjisĂ«. Prandaj, dimensioni prej 16 bit Ă«shtĂ« mjaft i arsyeshĂ«m. ĂshtĂ« e vĂ«shtirĂ« qĂ« nĂ« tĂ« ardhmen e afĂ«rt tĂ« krijohen mĂ« shumĂ« se 65 mijĂ« shĂ«rbime dhe karakteristika unike. NĂ« kĂ«tĂ« moment, gjithçka qĂ« mundĂ«m, e kemi llogaritur (kujtoni nga e kuptoni kĂ«tĂ« â "ai e llogariti edhe juve" :-)) Elementet e numĂ«ruara , , dhe mund t'i shihni pĂ«rmes lidhjeve.
Megjithatë, mendoj se të gjithë e kujtojnë historinë me 4 byte të adresës IP në internet. Fillimisht menduam se do të mjaftonte, por tani asnjëherë nuk kalojmë në adresën me 6 byte. Që të mos e përsërisim këtë gabim dhe të japim mundësi për duar të prishura të amatorëve, SIG vendosi që menjëherë të prezantojë edhe UUID 128-bit. Kjo më sjell në mendje bandën e paautorizuar 433MHz, e cila iu besua çdo lloj Kuli bÄ njësh nga kanali radio. Në rastin tonë, u besua identifikuesi 128-bit të shërbimeve dhe karakteristikave. Kjo do të thotë se për shërbimet dhe pajisjet tona, mund të përdorim praktikiisht çdo vlerë 128-bit. Ndoshta probabiliteti për të ndërtuar një UUID identik është afërsisht zero.
Në të vërtetë, UUID të shkurtër 16-bit kanë një zgjerim në një vlerë 128-bit. Në specifikim, ky zgjerim quhet Bluetooth Base UUID dhe ka vlerën 00000000-0000-1000-8000-00805F9B34FB. Nëse, për shembull, UUID i atributit 16-bit ka vlerën 0x1234, UUID i barabartë 128-bit do të ketë vlerën 00001234-0000-1000-8000-00805F9B34FB. Dhe madje jepet formula përkatëse:
                                128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID
Nga erdhi ky numër magjik, nuk e di. Nëse ndonjë nga lexuesit e di - le të na shkruajë në komentet (Përdoruesi me emrin Sinopteek e ka bërë këtë. Shikoni komentet). Sa i përket krijimit të UUID-ve 128-bitësh, mund të përdorni një , i cili do ta bëjë këtë për ju.
ATT-tĂ« GATT-tĂ«âŠ
Tani më në fund fillon gjëja më interesante. Ju rikujtoj se ATT është i bazuar në marrëdhënien klient-server. Tani po shqyrtojmë pajisjen e serverit. Ajo përmban informacione të tilla si vlerat e sensorëve, statusin e çelësit të ndriçimit, të dhëna mbi lokacionin etj. Tani, kur të gjithë "pjesëmarrësit e paradës sonë" janë numëruar, duhet t'i vendosim ndryshe në memorien e pajisjes. Për këtë, i vendosim në një tabelë, e cila quhet tabela e atributeve. Mbani mend mirë këtë. Kjo është zemra e BLE. Këtë ne do ta shqyrtojmë më tej. Tani çdo rresht ne do ta quajmë atribut. Kjo tabelë ndodhet thellë në stack dhe, në përgjithësi, ne nuk kemi qasje direkte në të. Ne e inicizojmë dhe i drejtohemi, por çfarë ndodh brenda saj, është e fshehtë për ne.
Lehtojmë një pamje nga specifikimi, por para se të fillojmë, dua të theksoj një confuzion të zakonshëm në terma, veçanërisht në lidhje me descriptorët. Loja e descriptorit është të plotësojë përshkrimin e karakteristikave. Kur është e nevojshme të zgjeroni mundësitë e saj, përdoren descriptorët. Ata janë gjithashtu atribute dhe, njësoj si shërbimet dhe karakteristikat, shfaqen në tabelën e atributeve. Ne do t'i shqyrtojmë ato me detaje në pjesën e dytë të artikullit. Megjithatë, ndonjëherë descriptorët quhen numri i rreshtit në tabelën e atributeve. Këtë duhet ta kemi parasysh. Ne, për të mos u ngatërruar, do të përdorim termin 'tregues atribute' për këto qëllime.
Pra, atributes është një vlerë discrete, e cila ka këtij pronarëve të lidhura me të:
1. Treguesi i atributit (Attribute Handle) - Ky është indeksi i tabelës, që i përket atributit
2. Tipi i atributit (Attribute Type) - Ky është UUID i cili përshkruan tipin e tij
3. Vlera e atributit (Attribute Value) - Këto janë të dhëna, të indekshuara nga treguesi i atributit
4. Lejet e atributeve (Attribute Permissions) - Kjo është pjesa e atributit, lejet që nuk mund të lexohen ose shkruhen duke përdorur protokollin e atributeve
Si e gjithë kjo kuptohet? Referenca e atributit është, në kuptimin e zakonshëm, numri i tij në tabelën tonë.
Ajo i lejon klientit tĂ« referohet nĂ« atribut nĂ« kĂ«rkesat e leximit ose shkruarjes. Ne mund tĂ« numĂ«rojmĂ« rreshtat tanĂ« (atributet) nga 0x0001 deri nĂ« 0xFFFF. NĂ« asociacionin tonĂ« me njĂ« raft librash â ky Ă«shtĂ« numri i kartelĂ«s nĂ« katalogun çek. Po ashtu, si nĂ« katalogun e bibliotekĂ«s, kartelat vendosen nĂ« rendin nĂ« rritje tĂ« numrit. Numri i çdo rreshti tĂ« ardhshĂ«m duhet tĂ« jetĂ« mĂ« i madh se ai i mĂ«parshmi. Ashtu si nĂ« bibliotekĂ«, ndonjĂ«herĂ« humbasin disa kartela, kĂ«shtu qĂ« edhe ne â nĂ« numĂ«rimin e rreshtave mund tĂ« ketĂ« boshllĂ«qe. Kjo pranohet. E rĂ«ndĂ«sishme Ă«shtĂ« qĂ« ata tĂ« shkojnĂ« nĂ« mĂ«nyrĂ« rritĂ«se.
Lloji i atributit përcakton se çfarë paraqet ky atribut. Në analogji me gjuhën C,
ku ka variabla boolean, numerik dhe fjalë, ashtu është edhe këtu. Nëpërmjet llojit të atributit ne kuptojmë
me çfarë kemi të bëjmë dhe si duhet të punojmë mëtej me këtë atribut. Më poshtë do të shqyrtojmë disa lloje specifike të atributit. Për shembull, "deklarata e shërbimit" (0x2800), "deklarata e karakteristikës" (0x2803), "deklarata e përshkruesit" (0x2902).
Zbënë një atribut është vetë vlera e tij, falni për tautologjinë. Nëse tipi i atributit është një varg, atëherë vlera e atributit mund të jetë për shembull slogani «Hello World !!!». Nëse tipi i atributit është «deklarata e shërbimit», atëherë vlera e tij është vetë shërbimi. Disa herë, kjo është informacion mbi vendin ku mund të gjenden atributet e tjera dhe pronat e tyre.
Lejet e atributit i lejojnë serverit të kuptojë nëse lejohet akses për lexim ose shkruarje.
Kujdesi, këto leje zbatohen vetëm në vlerën e atributit, e jo në treguesin, tipin dhe fushën e lejeve. Pra, nëse lejohet shkruarja e atributit, ne mund ta ndryshojmë për shembull vargun «Hello World !!!» në vargun «Good morning». Por nuk mund ta ndalim shkruarjen e vargut të ri, ose të ndryshojmë tipin e atributit dhe ta shënojmë vargun si «deklaratë shërbimi». Kur klienti i drejtohet serverit, ai kërkon atributet e tij. Kjo i lejon klientit të kuptojë çfarë mund të ofrojë serveri. Megjithatë, nuk është e nevojshme të lexosh dhe shkruash vlerat.
Si duket kjo
Koncepcioni i GATT-i ka të bëjë me grupimin e atributeve në tabelën e atributeve në një rend të shumë specifik dhe të arsyeshëm. Le të shqyrtojmë më me kujdes profilin e frekuencës së rrahjeve të zemrës të dhënë më poshtë. Kolona më e majtë e kësaj tabele nuk është e obligueshme. Ajo thjesht na tregon se çfarë përfaqëson kjo rresht (atribut). Të gjitha kolonat e tjera na janë tashmë të njohura.
Në pjesën e sipërme të çdo grupi, ne gjithmonë kemi atributin e shpalljes së shërbimit. Lloji i tij gjithmonë është 0x2800, ndërsa treguesi varet nga sa atribute janë tashmë të pranishme në tabelë. Këto janë gjithmonë të disponueshme vetëm për lexim, pa ndonjë verifikim apo autorizim. Për këto koncepte do të flasim më vonë. Vlera është një UUID tjetër, që përcakton se çfarë shërbimi është. Në Tabelë, vlera është 0x180D, e cila është e përcaktuar nga Bluetooth SIG si shërbimi i frekuencës së rrahjeve të zemrës.
Pas njoftimit të shërbimit, vjen njoftimi i karakteristikave. Forma e tij është e ngjashme me njoftimin e shërbimit. UUID-i i tij gjithmonë ka vlerën 0x2803, dhe lejet gjithashtu janë gjithmonë të disponueshme vetëm për lexim pa ndonjë verifikim ose autorizim. Le të shohim në fushën e Vlerës së Atributit, e cila përfshin disa të dhëna. Ajo gjithmonë përmban një tregues, UUID dhe një grup pronash. Këto tre elemente përshkruajnë njoftimin e vlerës së karakteristikës më pas. Treguesi natyrshëm tregon vendin e njoftimit të vlerës së karakteristikës në tabelën e atributeve. UUID përshkruan se çfarë lloj informacioni ose vlerash mund të presim. Për shembull, vlera e temperaturës, gjendja e ndërprerësit të dritës ose ndonjë vlerë tjetër të rastësishme. Dhe përfundimisht, pronat që përshkruajnë se si mund të ndërveprojmë me vlerën e karakteristikës.
Këtu na pret një tjetër pengesë. Ajo lidhet me lejet e atributeve dhe pronat e karakteristikave. Le të shohim një imazh të pronave të fushës së bitit nga specifikimi.
Si e shihni, këtu gjithashtu ka fusha që ofrojnë mundësi për lexim dhe shkrim. Mund të pyesni veten, përse kemi lejet për lexim/shkrim për atributin dhe pronën
lexim/shkrim pĂ«r vlerĂ«n e karakteristikĂ«s? Mos mendoni se ato duhet tĂ« jenĂ« gjithmonĂ« tĂ« njĂ«jta? E vĂ«rteta Ă«shtĂ« se pronat pĂ«r vlerĂ«n e karakteristikĂ«s, nĂ« fakt, janĂ« vetĂ«m rekomandime pĂ«r klientin, tĂ« pĂ«rdorura nĂ« GATT dhe katet aplikative. KĂ«to janĂ« thjesht sugjerime se çfarĂ« klienti mund tĂ« pret nga atributi i shpalljes sĂ« karakteristikĂ«s. Le tĂ« e shqyrtojmĂ« kĂ«tĂ« mĂ« nĂ« hollĂ«si. ĂfarĂ« lloj lejesh ekzistojnĂ« pĂ«r atributin?
1. Lejet e aksesit:
    â lexim
    â shkrim
    â lexim dhe shkrim
2. Leja e autentifikimit:
    â autentifikimi kĂ«rkohet
    â autentifikimi nuk kĂ«rkohet
3. Leja e autorizimit:
    â autorizimi kĂ«rkohet
    â autorizimi nuk kĂ«rkohet
Dallimi kryesor midis lejeve dhe pronave të karakteristikave është se të parat i përkasin serverëve, ndërsa të dytat klientëve. Një server mund të ketë leje për të lexuar vlerën e karakteristikës, por mund të ketë kërkesë për autentikim ose autorizim. Prandaj, kur klienti bën një kërkesë për pronat e karakteristikës, ne do të gjejmë se leximin e ka të lejuar. Por, kur përpiqemi të lexojmë, do të marrim një gabim. Prandaj, mund të themi me siguri se lejet kanë prioritet mbi pronat. Njohuria për lejet që ka një atribut nuk mund të merret nga ana e klientit.
DĂ«shkrimi
Kthehemi në tabelën tonë. Pas shpalljes së vlerës së karakteristikës, mund të ketë shpallje të tjera për lejet:
1. Shpallje e re e karakteristikës (në shërbim mund të ketë shumë karakteristika)
2. Shpallje e re shërbimi (në tabelë mund të ketë shumë të tilla)
3. Shpallje e dëshkruesit
NĂ« rastin e karakteristikĂ«s sĂ« matjes sĂ« frekuencĂ«s sĂ« rrahjeve tĂ« zemrĂ«s, nĂ« tabelĂ«n tonĂ«, shpallja e vlerĂ«s sĂ« karakteristikĂ«s shoqĂ«rohet me shpalljen e deskriptorit. Deskriptor Ă«shtĂ« njĂ« atribut me informacion shtesĂ« rreth karakteristikĂ«s. EkzistojnĂ« disa lloje deskriptorĂ«sh. PĂ«r ta, do tĂ« flasim nĂ« detaje nĂ« pjesĂ«n e dytĂ« tĂ« kĂ«tij artikulli. Tani, do tĂ« prekim vetĂ«m deskriptorin e konfigurimit tĂ« karakteristikave tĂ« klientit (Client Characteristic Configuration Descriptor â CCCD). Ai ka UUID tĂ« barabartĂ« me 0x2902. Me anĂ« tĂ« kĂ«tij deskriptorit, klienti ka mundĂ«sinĂ« tĂ« aktivizojĂ« nĂ« server indikimin ose njoftimin. Dallimi mes tyre Ă«shtĂ« i vogĂ«l, por gjithsesi ekziston. Njoftimi nuk kĂ«rkon konfirmimin e marrjes nga ana e klientit. Indikimi, nga ana tjetĂ«r, e kĂ«rkon kĂ«tĂ« konfirmim, megjithĂ«se ndodh nĂ« nivelin GATT, pa arritur nĂ« nivelin e aplikacionit. Pse kĂ«shtu, do tĂ« pyesni? FatkeqĂ«sisht, kjo nuk mĂ« Ă«shtĂ« e njohur. Thjesht do tĂ« them qĂ« specialistĂ«t e Nordic rekomandojnĂ« pĂ«rdorimin e njoftimit. MĂ« shumĂ« se kaq, kontrolli i integritetit tĂ« paketĂ«s (nĂ«pĂ«rmjet CRC) ndodh nĂ« tĂ« dy rastet.
PĂ«rfundimi
Në fund të artikullit, do të doja të theksoja diçka. Tabela e fundit është disi e ngatërruar. Sidoqoftë, u ndala tek ajo për shkak se ajo përmendet në , në të cilën mbështetem. Në pjesën e dytë të artikullit tim kam për qëllim të thellohem në specifikimin e BlueTooth 4.0. Atje na presin skemat dhe vizatimet më të sakta. Në pjesën e tretë, do të doja të analizoj log-un e marrë me programin Wireshark nga një nga pajisjet dhe të shoh "në gjallë" të gjithë atë teori që ne po studiojmë.
Përfaqësuesi i Grupit të Kompanive
Pecherski Vladimir
Burimi: habr.com
