BLE nĂ«n mikroskop (ATT-tĂ« GATTâŠ)
Pjesa 1, shqyrtim
Ka kaluar një kohë e konsiderueshme që kur doli specifikimi i parë për Bluetooth 4.0. Edhe pse tema BLE është shumë interesante, ajo vazhdon të largojë shumë zhvillues për shkak të kompleksitetit të saj. Në artikujt e mi të mëparshëm kam trajtuar kryesisht nivelin më të ulët, Link Layer dhe Physical Layer. Kjo më lejon të shmang konceptet e ndërlikuara si protokolli i atributeve (ATT) dhe profili i përbashkët të atributeve (GATT). Megjithatë, nuk ka ku të iket; pa i kuptuar ata, është e pamundur të zhvillohen pajisje të kompatibilshme. Sot do të doja të ndaja me ju këto njohuri. Në artikullin tim do të mbështetem në për fillestarët nga sajtit Nordic. Prandaj, le të fillojmë.
Pse gjithçka është kaq e ndërlikuar?
Në mendimin tim, ishte e qartë që menaxhimi i pajisjeve përmes smartphone-ve është një temë me perspektivë dhe afatgjatë. Prandaj, ata vendosën ta strukturojnë atë menjëherë dhe deri në maksimum. Në mënyrë që prodhuesit e pajisjeve të mos shpikin protokolle të ndryshme që më pas do të ishin jo të kompatibël. Këtu qëndron kompleksiteti. Që në fazën e parë, protokolli BLE u përpoq të përfshijë gjithçka që mund të ishte e mundur. Dhe nuk ka rëndësi nëse do të nevojitet më vonë apo jo. Për më tepër, u parashikua mundësia e zgjerimit të listës së pajisjeve për të ardhmen.
Le tĂ« shohim njĂ« imazh ku Ă«shtĂ« paraqitur skema e protokollit BLE. Ai pĂ«rbĂ«het nga disa nivele. Niveli mĂ« i ulĂ«t, niveli fizik (PHY), pĂ«rgjigjet pĂ«r kanalin radio tĂ« pajisjes. Link Layer (LL) pĂ«rmban tĂ« gjithĂ« sekuencat e byte nĂ« mesazhin e dĂ«rguar. NĂ« artikujt e mĂ«parshĂ«m e kemi studiuar pikĂ«risht atĂ«. Host Controller Interface (HCI) Ă«shtĂ« protokolli i komunikimit midis niveleve ose çipave BLE, nĂ«se Controller dhe Host janĂ« tĂ« realizuar nĂ« çipa tĂ« ndryshĂ«m. PĂ«r formimin e pakove, ndarjen nĂ« kadra, kontrollin e gabimeve dhe grumbullimin e pakove pĂ«rgjigjet Logical Link Control and Adaptation Protocol (L2CAP). PĂ«r enkriptimin e pakove Ă«shtĂ« pĂ«rgjegjĂ«s Security Manager Protocol (SMP). Profili i aksesit tĂ« pĂ«rgjithshĂ«m (GAP) pĂ«rgjigjet pĂ«r shkĂ«mbimin fillestar tĂ« tĂ« dhĂ«nave midis pajisjeve, pĂ«r tĂ« pĂ«rcaktuar "Kush Ă«shtĂ« kush". Ai gjithashtu pĂ«rfshin shqyrtimin 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, prandaj ato janĂ« shumĂ« tĂ« ndĂ«rthurura.
PĂ«r ta thjeshtuar rrĂ«fimin, do tĂ« doja tĂ« pĂ«rdorja njĂ« analogji. E kam dĂ«gjuar diku dhe do tĂ« doja ta mbĂ«shtes. Imagjinoni njĂ« pajisje BLE si njĂ« bibliotekĂ« me disa rafte. Ădo rafte Ă«shtĂ« njĂ« temĂ« e veçantĂ«. PĂ«r shembull, kemi rafte me fantazi, matematikĂ«, enciklopedi. NĂ« çdo rafte ka libra qĂ« tregojnĂ« temĂ«n pĂ«rkatĂ«se. Disa libra madje kanĂ« edhe shĂ«nime me copĂ«za letre. Gjithashtu, kemi njĂ« katalog tĂ« vogĂ«l tĂ« gjitha librave. NĂ«se e kujtoni bibliotekat e shkollĂ«s â Ă«shtĂ« njĂ« kuti e ngushtĂ« me karta letre. NĂ« kĂ«tĂ« analogji, biblioteka Ă«shtĂ« profili i pajisjes sonĂ«. Rafte janĂ« shĂ«rbimet, librat janĂ« karakteristikat, dhe katalogu Ă«shtĂ« tabela e atributeve. ShĂ«nimet nĂ« libra janĂ« deskriptoret, pĂ«r tĂ« cilat do tĂ« flas mĂ« vonĂ« mĂ« nĂ« detaje.
TĂ« gjithĂ« ata qĂ« kanĂ« zhvilluar pajisje e dinĂ« se nĂ« shumĂ« projekte ka pjesĂ« kodesh tĂ« ngjashme. Arsyeja Ă«shtĂ« se shumĂ« pajisje kanĂ« funksionalitete tĂ« ngjashme. PĂ«r shembull, nĂ«se pajisjet punojnĂ« me bateri, problemi i karikimit dhe kontrollit tĂ« nivelit tĂ« tyre do tĂ« jetĂ« i njĂ«jtĂ«. E njĂ«jta gjĂ« vlen edhe pĂ«r sensorĂ«t. NĂ« fakt, qasja objekt-orientuese nĂ« programim âsiguron mundĂ«sinĂ« pĂ«r tĂ« krijuar objekte qĂ« lidhin pronĂ«si dhe sjellje nĂ« njĂ« aleancĂ« tĂ« pavarur, e cila pastaj mund tĂ« pĂ«rdoret shumĂ« herĂ«â. NĂ« mendimin tim, nĂ« BLE Ă«shtĂ« bĂ«rĂ« njĂ« pĂ«rpjekje pĂ«r njĂ« qasje tĂ« ngjashme. Grupi Bluetooth Special Interest Group (SIG) ka zhvilluar profile. Pajisjet nga prodhues tĂ« ndryshĂ«m, qĂ« kanĂ« profile tĂ« njĂ«jta, duhet tĂ« punojnĂ« pa vĂ«shtirĂ«si me njĂ«ra-tjetrĂ«n. Profilet pĂ«rbĂ«hen nga shĂ«rbime, dhe shĂ«rbimet nga karakteristika, tĂ« shtuar me deskriptoret. NĂ« raste tĂ« pĂ«rgjithshme, kjo mund tĂ« duket kĂ«shtu:
Për shembull, le të shqyrtojmë skemën e profilit të monitorit të pulsit (banda e fitnessit). Ai përbëhet nga dy shërbime dhe disa karakteristika. Nga ky skemë menjëherë kuptohet hierarkia e profilit. Karakteristika e pikës së kontrollit 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 e detyrueshme e rrahjeve 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 mirëmbajtjes së baterisë (0x180F):
    a) Karakteristika e detyrueshme e nivelit të ngarkesës së baterisë (0x2A19)
UUID
Për të qenë në gjendje të referohemi qartë në elementet e profilit (shërbimeve, karakteristikave dhe descriptorëve), ne duhet t'i numërojmë ato somehow. Për këtë qëllim, është futur koncepti i Universally Unique ID (UUID) ose Identifikuesi Universalis Unik. Në kllapa të secilës rresht është pikërisht UUID. Ka një veçori këtu. Për UUID është vendosur të përdoret një kod me gjatësi 16 dhe 128 bit. Pse, do të pyesni? Në protokollin BLE, gjithçka është nën kontrollin e ruajtjes së energjisë. Prandaj, dimensioni prej 16 bit është mjaft i arsyeshëm. Ka pak shanse që në të ardhmen e afërt të krijohen më shumë se 65 mijë shërbime dhe karakteristika unike. Aktualisht, gjithçka që mundën, tashmë e kanë llogaritur (kini parasysh se nga erdhi kjo - "ai ju numeronte edhe ju" :-)) Elementët e numëruar , , dhe mund t'i shihni në lidhjet e mësipërme.
Megjithatë, mendoj se të gjithë e mbajnë mend historinë me 4 bajtët e adresës IP në internet. Fillimisht mendohej se mjaftonte, por tani nuk kalojmë në adresën 6-bajtëshe. Që të mos përsërisim këtë gabim dhe t'u japim hapësirë duarve të renë t'ua japin, SIG vendosi të futë edhe UUID me 128 bit. Më kujton këtë një bandë të paligjshme prej 433MHz, e cila iu dha dorë disa Kuli bëjsh nga kanali radio. Në rastin tonë, u dha në dorë identifikuesi 128 bit të shërbimeve dhe karakteristikave. Kjo do të thotë që për shërbimet dhe pajisjet tona, mund të përdorim çfarëdo vlerë 128 bit. Sërish, probabiliteti i shpikjes së UUID identike është pranë zeros.
Në të vërtetë, UUID të shkurtër 16 bit kanë një zgjerim në vlerën 128 bit. Në spesifikim, ky zgjerim quhet Bluetooth Base UUID dhe ka vlerën 00000000-0000-1000-8000-00805F9B34FB. Nëse, për shembull, UUID 16 bit i atributit ka vlerën 0x1234, UUID 128 bit ekuivalente do të ketë vlerën 00001234-0000-1000-8000-00805F9B34FB. Dhe madje ka një formulë përkatëse:
                                128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID
Nga ka ardhur ky numĂ«r magjik, nuk e di. NĂ«se ndonjĂ« prej lexuesve e di â le tĂ« shkruajĂ« nĂ« komentet (PĂ«rdoruesi me pseudonimin Sinopteek e ka bĂ«rĂ« kĂ«tĂ«. Shihni komentet). Sa i pĂ«rket shpikjes sĂ« UUID 128 bit, nĂ« parim mund tĂ« pĂ«rdorim njĂ« , i cili do ta bĂ«jĂ« kĂ«tĂ« pĂ«r ju.
ATT-tĂ« GATTâŠ
Në fakt, aty fillon e gjitha që është interesante. Dua të kujtoj se ATT bazohet në një marrëdhënie klient-server. Tani po shqyrtojmë pajisjen e serverit. Ai përmban informacione të tilla si vlerat e sensorëve, gjendjen e ndriçuesve, të dhënat për vendndodhjen, etj. Tani, kur të gjithë "pjesëmarrësit e paradës sonë" janë numëruar, duhet t'i vendosim ata ndonjëherë në memorien e pajisjes. Për këtë, i vendosim në një tabelë, e quajtur tabela e atributeve. Mbani mend këtë mirë. Ky është zemra e BLE. Këtë do ta shqyrtojmë më tutje. Tani çdo rresht do ta quajmë atribut. Kjo tabelë është në thellësi të stack-ut dhe, si rregull, nuk kemi qasje të drejtpërdrejtë tek ajo. Ne e inicializojmë dhe i referohemi asaj, por çfarë ndodh brenda saj është e fshehur nga ne pas shtatë vulave.
Le të shqyrtojmë imazhin nga specifikimi, por para kësaj, dua të tërheq vëmendjen mbi ngathtësinë e zakonshme në terma, sidomos në deskriptorë. Rohla e deskriptorit është të plotësojë përshkrimin e karakteristikave. Kur është e nevojshme të zgjeroni mundësitë e saj, atëherë përdoren deskriptorë. Ata gjithashtu janë atribute, dhe ashtu si shërbimet dhe karakteristikat, janë të pozicionuar në tabelën e atributeve. Do t'i shqyrtojmë ato në pjesën e dytë të artikullit. Megjithatë, ndonjëherë deskriptorët quhen numri i rreshtit në tabelën e atributeve. Kjo duhet të mbahet mend. Ne, për të mos u ngatërruar, do të përdorim termin "tregues atribute" për këto qëllime.
Pra, atributi është një vlerë diskrete, e cila ka këto pronësi të lidhura me të:
1. Treguesi i atributit (Attribute Handle) â Ă«shtĂ« indeksi nĂ« tabelĂ«, qĂ« i pĂ«rshtatet atributit
2. Lloji i atributit (Attribute Type) â Ă«shtĂ« UUID qĂ« pĂ«rshkruan llojin e tij
3. Vlera e atributit (Attribute Value) â janĂ« tĂ« dhĂ«nat e indeksuara nga treguesi i atributit
4. Lejet e atributeve (Attribute Permissions) â janĂ« njĂ« pjesĂ« e atributit, lejet qĂ« nuk mund tĂ« lexohen ose shkruhen duke pĂ«rdorur protokollin e atributeve
Si ta kuptojmë të gjithë këtë? Treguesi i atributit është, për të thënë, numri i tij në tabelën tonë.
Ai lejon klienti të referohet në atribut në kërkesat e leximit ose shkruajtjes. Ne mund të numërojmë rreshtat tanë (atributet) nga 0x0001 në 0xFFFF. Në asociacionin tonë me një bibliotekë, kjo është numri i kartelës në katalogun e letë. Po ashtu, si në katalogun e bibliotekës, kartelat vendosen sipas rritjes së numrit. Numri i çdo rreshti të ardhshëm duhet të jetë më i madh se i mëparshmi. Si në bibliotekë, ndonjëherë humbin disa kartela, ashtu edhe tek ne - në numërimin e rreshtave mund të ketë boshllëqe. Kjo është e pranueshme. E rëndësishme është që ato të shkojnë në mënyrë rritëse.
Lloji i atributit përcakton se çfarë përfaqëson ky atribut. Në analogji me gjuhën C,
ku ka variabla boolean, numërues dhe vargje, ashtu ndodhi edhe këtu. Nga lloji i atributit ne mësojmë
se me çfarë kemi të bëjmë dhe si të vazhdojmë më tej me këtë atribut. Më poshtë do të shqyrtojmë disa lloje specifike atributesh. Për shembull "deklarata e shërbimit" (0x2800), "deklarata e karakteristikave" (0x2803), "deklarata e deskriptorit" (0x2902).
Vlera e atributit është vetë vlera e tij, falni për tautologji. Nëse lloji i atributit është varg, atëherë vlera e atributit mund të jetë për shembull slogan "Hello World !!!". Nëse lloji i atributit është "deklarata e shërbimit", atëherë vlera e tij është vetë shërbimi. Dhe ndonjëherë kjo është informata se ku të gjejmë atributet e tjera dhe pronësitë e tyre.
Lejet e atributëve i lejojnë serverit të kuptojë nëse lejohet akses për lexim ose shkruajtje.
Vini re se këto leje zbatohen vetëm mbi vlerën e atributit, dhe jo mbi treguesin, llojin dhe vetë fushën e lejeve. Pra, nëse lejohet shkruajtja e atributit, atëherë ne mund ta ndryshojmë, për shembull, rreshtin "Hello World !!!" në rreshtin "Good morning". Por nuk mund të ndalojmë shkruajtjen e një rreshti të ri ose, të ndryshojmë llojin e atributit dhe të shënojmë rreshtin si "deklaratë shërbimi". Kur klienti i drejtohet serverit, ai kërkon atributet e tij. Kjo i lejon klientit të kuptojë se çfarë mund të ofrojë serveri. Megjithatë, nuk është e detyrueshme të lexoni dhe shkruani vlerat.
Si duket kjo
Koncepcioni GATT është grumbullimi i atributeve në një tabelë atribute në një rend shumë specifik dhe logjik. Le të shqyrtojmë më afër profilin e frekuencës së rrahjeve të zemrës, të dhënë më poshtë. Kolona më e majtë e kësaj tabele është jo e detyrueshme. Ajo thjesht na përshkruan se çfarë është ky rresht (atribut). Të gjitha kolonat e tjera na janë tashmë të njohura.
NĂ« krye tĂ« çdo grupi, gjithmonĂ« kemi atributin e shpalljes sĂ« shĂ«rbimit. Lloji i tij gjithmonĂ« Ă«shtĂ« 0x2800 dhe treguesi varet nga sa atribute tashmĂ« janĂ« tĂ« pranishme nĂ« tabelĂ«. Rregullat e tij gjithmonĂ« janĂ« tĂ« disponueshme vetĂ«m pĂ«r lexim, pa verifikim autenticiteti ose autorizimi. pĂ«r kĂ«to koncepte do tĂ« flasim mĂ« vonĂ«. Vlera â Ă«shtĂ« njĂ« UUID tjetĂ«r, qĂ« pĂ«rcakton se çfarĂ« lloj shĂ«rbimi Ă«shtĂ«. NĂ« TabelĂ«, vlera Ă«shtĂ« 0x180D, e cila pĂ«rcaktohet nga Bluetooth SIG si shĂ«rbimi i frekuencĂ«s sĂ« rrahjeve tĂ« zemrĂ«s.
Pas shpalljes së shërbimit, ndjek shpallja e karakteristikës. Nga forma, ajo është e ngjashme me shpalljen e shërbimit. UUID i saj gjithmonë ka vlerën 0x2803, dhe rregullat gjithashtu janë gjithmonë të disponueshme vetëm për lexim, pa verifikim autenticiteti ose autorizimi. Le ta shohim 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ë shpalljen e vlerës së karakteristikës që do të vijë. Treguesi natyrisht tregon vendin e shpalljes së vlerës së karakteristikës në tabelën e atributeve. UUID përshkruan se çfarë lloj informacioni ose vlere mund të presim. Për shembull, vlera e temperaturës, gjendja e ndriçuesit të dritës ose ndonjë vlerë tjetër rastësore. Dhe së fundi, pronat që përshkruajnë si mund të ndërveprojmë me vlerën karakteristike.
Këtu na pret një tjetër pengesë. Ajo është e lidhur me rregullat e atributeve dhe pronat e karakteristikave. Le ta shohim imazhin e pronave të fushës bit nga specifikimi.
Siç e shihni, këtu gjithashtu ka fusha që ofrojnë mundësi leximi dhe shkrimi. Mund të pyesni veten, pse kemi rregulla për lexim/shkrim për atributin dhe pronën.
lexh/fiksimi për vlerën e karakteristikës? A nuk duhet të jenë ato gjithmonë të njëjta? E vërteta është se vlerat për karakteristikën, në fakt janë vetëm rekomandime për klientin, që përdoren në GATT dhe shtresat aplikative. Këto janë vetëm sugjerime për atë që klienti mund të presë nga atributi i shpalljes së karakteristikës. Le të zbërthejmë këtë më në detaje. Cilat janë llojet e lejeve që ka atributi?
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 të atribueteve dhe pronave të karakteristikave është se të parat i përkasin serverëve, ndërsa të dyjat i përkasin 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 autentifikim ose autorizim. Prandaj, kur klienti kërkon pronat e karakteristikës, ne do të marrim që leximi është i lejuar. Por kur përpiqemi të lexojmë, do të marrim një gabim. Prandaj, mund të themi me siguri se lejet kanë prioritet mbi pronat. Të dhënat në lidhje me lejet e atributit, ne si klientë, nuk mund t'i marrim.
Dskritor
Le të kthehemi në tabelën tonë. Pas shpalljes së vlerës së karakteristikës, janë të mundshme shpallje të tjera të atributeve:
1. Një shpallje e re e karakteristikës (në shërbim mund të ketë shumë karakteristika)
2. Një shpallje e re e shërbimit (në tabelë mund të ketë shumë prej tyre)
3. Shpallja e dskritorit
Në rastin e karakteristikës së masës së frekuencës së ritmit të zemrës, në tabelën tonë, shpallja e vlerës së karakteristikës shoqërohet me shpalljen e deskriptorit. Deskriptorja është një atribut me informacion shtesë rreth karakteristikës. Ka disa lloje deskriptorësh. Ne do të flasim për to në pjesën e dytë të këtij artikulli. Tani, do të trajtojmë vetëm deskriptorin e konfiguracionit të karakteristikave të klientit (Client Characteristic Configuration Descriptor - CCCD). Ai ka një UUID të barabartë me 0x2902. Me anë të këtij deskriptorit, klienti ka mundësinë të aktivizojë në server njoftimin ose indikimin. Diferenca mes tyre është e vogël, por gjithsesi ekziston. Njoftimi nuk kërkon konfirmimin e marrjes nga ana e klientit. Ndërsa, indikimi e kërkon këtë, megjithëse ndodh në nivelin GATT, pa arritur në nivelin e aplikacionit. Pse kështu, mund të pyesni? Më vjen keq, kjo nuk më është e njohur. Thjesht do të them se specialistët e Nordic rekomandojnë përdorimin e njoftimit. Aq më tepër që kontrolli i integritetit të paketës (me anë të CRC) ndodh në të dy rastet.
PĂ«rfundim
NĂ« fund tĂ« artikullit, do tĂ« doja tĂ« thoja kĂ«tĂ«. Tabela e fundit Ă«shtĂ« pak e komplikuar. MegjithatĂ«, unĂ« u ndala te ajo pĂ«r shkak se ajo jepet nĂ« , nĂ« tĂ« cilĂ«n mbĂ«shtetem. NĂ« pjesĂ«n e dytĂ« tĂ« artikullit tim, kam ndĂ«rmend tĂ« thellohem nĂ« specifikimin BlueTooth 4.0. Aty na presin skemat dhe ilustrimet mĂ« tĂ« sakta. NĂ« pjesĂ«n e tretĂ«, do tĂ« doja tĂ« shqyrtoj logun e marrĂ« me anĂ« tĂ« programit Wireshark nga njĂ« nga pajisjet dhe tĂ« shoh ânĂ« tĂ« drejtpĂ«rdrejtĂ«â tĂ« gjithĂ« atĂ« teori qĂ« po studiojmĂ« bashkĂ«.
Punonjësi i Grupit të Kompanive
Pecherskiy Vladimir
Burimi: habr.com
