BLE under ett mikroskop (ATTы GATTы…)
Del 1, översikt
Det har redan gått ganska lång tid sedan den första specifikationen för Bluetooth 4.0 släpptes. Och även om BLE-ämnet är mycket intressant, avskräcker det fortfarande många utvecklare på grund av dess komplexitet. I mina tidigare artiklar har jag främst tittat på den lägsta nivån, Link Layer och Physical Layer. Detta gjorde det möjligt för oss att undvika att behöva ta till så komplexa och förvirrande begrepp som Attribut Protocol (ATT) och General Attribute Profile (GATT). Det finns dock ingenstans att ta vägen, utan att förstå dem är det omöjligt att utveckla kompatibla enheter. Idag skulle jag vilja dela denna kunskap med dig. I min artikel kommer jag att förlita mig på för nybörjare från den nordiska webbplatsen. Så låt oss börja.
Varför är allt så svårt?
Enligt min mening stod det direkt klart att hantering av enheter via smartphones är ett mycket lovande och långvarigt ämne. Därför bestämde de sig för att strukturera det omedelbart och maximalt. Så att tillverkare av olika prylar inte kommer med egna protokoll, som då blir inkompatibla. Därav svårigheten. Redan i första skedet försökte man klämma in allt möjligt i BLE-protokollet. Och det spelar ingen roll om det kommer att vara användbart senare eller inte. Dessutom gav de möjligheten att utöka listan över enheter för framtiden.
Låt oss ta en titt på bilden där BLE-protokolldiagrammet är ritat. Den består av flera lager. Det lägsta, fysiska lagret (PHY) ansvarar för enhetens radiokanal. Link Layer(LL) innehåller hela sekvensen av byte i det överförda meddelandet. I tidigare artiklar har vi studerat exakt detta. Host Controller Interface (HCI) är ett utbytesprotokoll mellan BLE-lager eller chips om Controller och Host är implementerade på olika chips. Logical Link Control and Adaptation Protocol (L2CAP) ansvarar för paketbildning, inramning, felkontroll och paketmontering. Security Manager Protocol (SMP) ansvarar för kryptering av paket. General Access Profile (GAP) är ansvarig för det initiala utbytet av data mellan enheter för att avgöra "vem är vem". Det inkluderar även skanning och reklam. I denna artikel kommer jag att fokusera på de två återstående delarna av protokollet - GATT och ATT. GATT är en överbyggnad av ATT, så de är tätt sammanflätade.
För att förenkla berättelsen skulle jag vilja övergå till en analogi. Jag hörde det någonstans och skulle vilja stödja det. Tänk på en BLE-enhet som en bokhylla med flera hyllor. Varje hylla är ett separat tema. Till exempel har vi hyllor med science fiction, matematik och uppslagsverk. På varje hylla finns böcker med ett specifikt ämne. Och vissa böcker har till och med pappersbokmärken med anteckningar. Dessutom har vi en liten papperskatalog med alla böcker. Om du kommer ihåg är skolbibliotek en smal låda med papperskort. Med denna analogi är skåpet profilen för vår enhet. Hyllor är tjänster, böcker är egenskaper och katalogen är en attributtabell. Bokmärken i böcker är deskriptorer, som jag också kommer att prata mer om senare.
Alla som har utvecklat enheter vet att många projekt har liknande kodbitar. Faktum är att många enheter har liknande funktionalitet. Till exempel, om enheter drivs av batterier, kommer problemet med laddning och övervakning av deras nivå att vara detsamma. Detsamma gäller sensorer. Egentligen ett objektorienterat förhållningssätt till programmering "ger möjligheten att skapa objekt som kombinerar egenskaper och beteenden till en fristående förening som sedan kan återanvändas". Enligt min åsikt försökte BLE ett liknande tillvägagångssätt. Profiler utvecklades av Bluetooth Special Interest Group (SIG). Enheter från olika tillverkare som har samma profiler ska fungera med varandra utan svårighet. Profiler består i sin tur av tjänster och tjänster av egenskaper, kompletterade med deskriptorer. Generellt sett kan det se ut så här:
Tänk till exempel på profildiagrammet för en pulsmätare (träningsarmband). Den består av två tjänster och flera egenskaper. Av den blir profilhierarkin omedelbart tydlig. Kontrollpunktskarakteristiken återställer den totala kaloriförbrukningen till noll.
1. Pulstjänsten inkluderar tre egenskaper (0x180D):
a) Obligatorisk pulskarakteristik (0x2A37)
b) Valfri kroppssensorpositionskarakteristik (0x2A38)
c) Villkorliga egenskaper för hjärtfrekvenskontrollpunkten (0x2A39)
2. Batteriunderhållsservice (0x180F):
a) Obligatorisk batteriladdningsnivåkarakteristik (0x2A19)
UUID
För att vi ska få unik tillgång till profilelement (tjänster, egenskaper och beskrivningar) måste vi numrera dem alla på något sätt. För detta ändamål introduceras ett koncept som Universally Unique ID (UUID) eller Universally Unique Identifier. UUID anges inom parentes på varje rad. Och det finns en egenhet här. För UUID bestämde vi oss för att använda en kod på 16 och 128 bitar långa. Varför frågar du? I BLE-protokollet handlar allt om energibesparing. Därför är dimensionen på 16 bitar ganska rimlig. Det är osannolikt att mer än 65 tusen kommer att skapas inom en snar framtid. unika tjänster och egenskaper. För tillfället har allt de kunde redan räknats (kom ihåg var detta kom ifrån - "han räknade dig också" :-)) Numrerade element , , и du kan titta på länkarna.
Jag tror dock att alla minns historien med 4 byte IP-adresser på Internet. Först trodde vi att det var tillräckligt, men nu kan vi fortfarande inte byta till en 6-byte adress. För att inte upprepa detta misstag och ge fritt spelrum åt gör-det-själv-ares lekfulla händer, bestämde sig SIG omedelbart för att introducera 128-bitars UUID. Detta påminner mig personligen om det olicensierade 433 MHz-bandet, som gavs till alla möjliga kulibiner från radiokanalen. I vårt fall odlades en 128-bitars identifierare av tjänster och egenskaper. Det betyder att vi, för våra tjänster och enheter, kan använda nästan vilket 128-bitars värde som helst. Trots det tenderar sannolikheten att komma med samma UUID till noll.
Faktum är att korta 16-bitars UUID har sin förlängning till ett 128-bitars värde. I specifikationen kallas detta tillägg för Bluetooth Base UUID och har värdet 00000000-0000-1000-8000-00805F9B34FB. Om till exempel 16-bitars attributet UUID har värdet 0x1234, kommer motsvarande 128-bitars UUID att ha värdet 00001234-0000-1000-8000-00805F9B34FB. Och till och med motsvarande formel ges:
128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID
Jag vet inte var detta magiska nummer kom ifrån. Om någon av läsarna vet, låt dem skriva i kommentarerna (En användare med smeknamnet Sinopteek har redan gjort detta. Se kommentarerna). När det gäller att komma med 128-bitars UUID kan du i princip använda en speciell vem ska göra det åt dig.
ATTy GATTy...
Faktiskt, då börjar det roliga. Låt mig påminna dig om att ATT är baserat på en klient-server-relation. Nu tittar vi på serverenheten. Den innehåller information som sensorvärden, ljusbrytarstatus, platsdata, etc. Nu när alla "deltagare i vår parad" är numrerade måste vi på något sätt placera dem i enhetens minne. För att göra detta lägger vi dem i en tabell som kallas en attributtabell. Kom ihåg detta väl. Detta är själva hjärtat av BLE. Detta är vad vi kommer att överväga vidare. Nu kallar vi varje rad ett attribut. Detta bord ligger djupt i stapeln och som regel har vi inte direkt tillgång till det. Vi initierar det och kommer åt det, men det som händer inuti är dolt för oss bakom sju tätningar.
Låt oss titta på bilden från specifikationen, men innan dess vill jag omedelbart uppmärksamma den frekventa förvirringen i termer, nämligen i deskriptorer. Deskriptorns roll är att komplettera beskrivningen av egenskapen. När det är nödvändigt att utöka dess kapacitet, används deskriptorer. De är också attribut, och precis som tjänster och egenskaper finns de i attributtabellen. Vi kommer att undersöka dem i detalj i den andra delen av artikeln. Men ibland hänvisar deskriptorer till radnumret i attributtabellen. Detta måste man ha i åtanke. För att undvika förvirring kommer vi att använda termen "attributpekare" för dessa ändamål.
Så ett attribut är ett diskret värde som har följande egenskaper associerade med sig:
1. Attribut Handle är tabellindexet som motsvarar attributet
2. Attribut Type är ett UUID som beskriver dess typ
3. Attributvärde är data som indexeras av attributpekaren
4. Attributbehörigheter är delen av ett attribut, behörigheter som inte kan läses eller skrivas med hjälp av attributprotokollet
Hur ska man förstå allt detta? Attributpekaren är relativt sett dess nummer i vår tabell.
Det tillåter en klient att referera till ett attribut i läs- eller skrivförfrågningar. Vi kan numrera våra linjer (attribut) från 0x0001 till 0xFFFF. I vår förening med bokhyllan är detta kortnumret i papperskatalogen. På samma sätt, som i bibliotekskatalogen, ordnas korten i ökande antal. Antalet på varje efterföljande rad måste vara större än den föregående. Precis som i biblioteket så försvinner ibland några kort, så hos oss kan det finnas luckor i radnumreringen. Detta är tillåtet. Huvudsaken är att de går progressivt.
Attributtypen avgör vad attributet representerar. I analogi med C-språket,
där det finns booleska, numeriska variabler och strängar, så är det här. Efter attributtyp känner vi igen
vad vi sysslar med och hur vi kan fortsätta arbeta med detta attribut. Nedan kommer vi att titta på några specifika typer av attribut. Till exempel "servicedeklaration" (0x2800), "karakteristisk deklaration" (0x2803), "deskriptordeklaration" (0x2902).
Värdet av ett attribut är dess faktiska betydelse, förlåt tautologin. Om attributtypen är en sträng kan attributvärdet till exempel vara sloganen "Hello World !!!". Om attributtypen är en "tjänstdeklaration" är dess värde själva tjänsten. Och ibland är detta information om var man kan hitta andra attribut och deras egenskaper.
Attributbehörigheter tillåter servern att förstå om läs- eller skrivåtkomst är tillåten.
Observera att dessa behörigheter endast gäller för attributvärdet och inte för själva pekaren, typen eller behörighetsfältet. De där. om attributinspelning är tillåten kan vi ändra till exempel raden "Hello World !!!" till raden "God morgon". Men vi kan inte förbjuda att skriva en ny rad eller ändra attributtypen och beteckna raden som en "servicedeklaration". När en klient kontaktar en server begär klienten dess attribut. Detta gör att klienten kan veta vad servern kan tillhandahålla. Även om det inte är nödvändigt att läsa och skriva värdena.
Hur ser det ut
Konceptet med GATT är att gruppera attribut i en attributtabell i en mycket specifik och logisk ordning. Låt oss ta en närmare titt på pulsprofilen nedan. Kolumnen längst till vänster i denna tabell är valfri. Det beskriver helt enkelt för oss vad denna linje (attribut) är. Alla andra kolumner är redan bekanta för oss.
Överst i varje grupp har vi alltid ett servicedeklarationsattribut. Dess typ är alltid 0x2800, och pekaren beror på hur många attribut som redan finns i tabellen. Dess behörigheter är alltid skrivskyddade, utan autentisering eller auktorisering. Vi kommer att prata om dessa begrepp lite senare. Värdet är ett annat UUID som identifierar vad tjänsten är. I tabellen är värdet 0x180D, vilket definieras av Bluetooth SIG som en pulstjänst.
Efter tillkännagivandet av tjänsten kommer tillkännagivandet av egenskapen. Den liknar till sin form en servicedeklaration. Dess UUID är alltid 0x2803, och dess behörigheter är alltid skrivskyddade utan någon autentisering eller auktorisering. Låt oss titta på fältet Attributvärde, som innehåller en del data. Den innehåller alltid en pekare, ett UUID och en uppsättning egenskaper. Dessa tre element beskriver den efterföljande deklarationen av det karakteristiska värdet. Pekaren anger naturligtvis platsen för den karakteristiska värdedeklarationen i attributtabellen. UUID beskriver vilken typ av information eller värde vi kan förvänta oss. Till exempel temperaturvärdet, ljusströmbrytarens tillstånd eller något annat godtyckligt värde. Och slutligen egenskaper, som beskriver hur det karakteristiska värdet kan interageras med.
En annan fallgrop väntar oss här. Det är associerat med attributbehörigheter och karakteristiska egenskaper. Låt oss titta på bilden av bitfältsegenskaperna från specifikationen.
Som du kan se finns det också fält här som ger läs- och skrivmöjligheter. Du kanske undrar varför vi har läs-/skrivbehörigheter för attribut och egendom
läsa/skriva för karakteristiskt värde? Borde de inte alltid vara likadana? Faktum är att egenskaperna för det karakteristiska värdet faktiskt bara är rekommendationer för klienten som används i GATT och applikationsskikt. Dessa är helt enkelt tips om vad kunden kan förvänta sig av det karakteristiska deklarationsattributet. Låt oss titta på detta mer i detalj. Vilka typer av behörigheter har ett attribut?
1. Åtkomstbehörigheter:
- läsning
- spela in
- Läsa och skriva
2. Autentiseringsbehörighet:
- Autentisering krävs
- ingen autentisering krävs
3. Auktoriseringstillstånd:
— Tillstånd krävs
- inget tillstånd krävs
Huvudskillnaden mellan attributupplösning och karakteristiska egenskaper är att de förra gäller servrar och de senare för klienter. Servern kan tillåtas läsa det karakteristiska värdet, men kan kräva autentisering eller auktorisering. Därför, när klienten efterfrågar egenskaperna för egenskapen, kommer vi att få att läsning är tillåten. Men när vi försöker läsa får vi ett felmeddelande. Därför kan vi lugnt prata om prioritet för behörigheter framför fastigheter. På klientsidan kan vi inte få kunskap om vilka behörigheter ett attribut har.
Beskrivare
Låt oss återvända till vårt bord. Efter att ha deklarerat värdet på en egenskap är följande attributdeklarationer möjliga:
1. Ny deklaration av egenskaper (en tjänst kan ha många egenskaper)
2. Ny servicedeklaration (det kan finnas många av dem i tabellen)
3. Deklarera ett handtag
När det gäller pulsmätningskarakteristiken, i vår tabell, åtföljs deklarationen av det karakteristiska värdet av deskriptorns deklaration. En deskriptor är ett attribut med ytterligare information om en egenskap. Det finns flera typer av deskriptorer. Vi kommer att prata om dem i detalj i den andra delen av denna artikel. För närvarande kommer vi bara att beröra Client Characteristic Configuration Descriptor (CCCD). Den har ett UUID lika med 0x2902. Genom att använda denna deskriptor har klienten möjlighet att aktivera indikering eller meddelande på servern. Skillnaden mellan dem är liten, men fortfarande kvar. Avisering kräver ingen bekräftelse på mottagande från klienten. Indikering kräver detta, även om det sker på GATT-nivå, men når inte tillämpningsnivån. Varför så, frågar du? Ack, jag vet inte detta. Låt mig bara säga att nordiska experter rekommenderar att du använder aviseringar. Dessutom sker kontroll av paketets integritet (med CRC) i båda fallen.
Slutsats
I slutet av artikeln skulle jag vilja säga detta. Den sista tabellen är lite förvirrande. Jag valde det dock för att det är givet efter , som jag litar på. I den andra delen av min artikel tänker jag fördjupa mig i BlueTooth 4.0-specifikationen. Där väntar oss mer korrekta diagram och ritningar. I den tredje delen skulle jag vilja analysera loggen som erhållits med Wireshark-programmet från en av prylarna och se "live" all teori som vi studerar.
Anställd i företagsgruppen
Pecherskikh Vladimir
Källa: will.com