BLE under et mikroskop (ATTы GATTы…)

BLE under et mikroskop (ATTы GATTы…)

Del 1, oversikt

Det har allerede gått ganske lang tid siden den første spesifikasjonen for Bluetooth 4.0 ble utgitt. Og selv om BLE-emnet er veldig interessant, avsetter det fortsatt mange utviklere på grunn av kompleksiteten. I mine tidligere artikler så jeg hovedsakelig på det laveste nivået, Link Layer og Physical Layer. Dette tillot oss å unngå å måtte ty til så komplekse og forvirrende konsepter som Attribut Protocol (ATT) og General Attribute Profile (GATT). Det er imidlertid ingen steder å gå, uten å forstå dem er det umulig å utvikle kompatible enheter. I dag vil jeg dele denne kunnskapen med deg. I artikkelen min vil jeg stole på lærebok for nybegynnere fra den nordiske nettsiden. Så la oss komme i gang.

Hvorfor er alt så vanskelig?

Etter min mening var det umiddelbart klart at administrasjon av enheter via smarttelefoner er et veldig lovende og langvarig tema. Derfor bestemte de seg for å strukturere det umiddelbart og maksimalt. Slik at produsenter av ulike dingser ikke kommer med egne protokoller, som da vil være inkompatible. Derav vanskeligheten. Allerede på første trinn prøvde de å presse alt mulig inn i BLE-protokollen. Og det spiller ingen rolle om det vil være nyttig senere eller ikke. I tillegg sørget de for muligheten for å utvide listen over enheter for fremtiden.

La oss ta en titt på bildet der BLE-protokolldiagrammet er tegnet. Den består av flere lag. Det laveste, fysiske laget (PHY) er ansvarlig for enhetens radiokanal. Link Layer(LL) inneholder hele sekvensen av byte i den overførte meldingen. I tidligere artikler har vi studert akkurat dette. Host Controller Interface (HCI) er en utvekslingsprotokoll mellom BLE-lag eller brikker hvis kontrolleren og verten er implementert på forskjellige brikker. Logical Link Control and Adaptation Protocol (L2CAP) er ansvarlig for pakkedannelse, framing, feilkontroll og pakkemontering. Security Manager Protocol (SMP) er ansvarlig for å kryptere pakker. General Access Profile (GAP) er ansvarlig for den første utvekslingen av data mellom enheter for å bestemme "Hvem er hvem". Det inkluderer også skanning og reklame. I denne artikkelen vil jeg fokusere på de to gjenværende delene av protokollen – GATT og ATT. GATT er en overbygning av ATT, så de er tett sammenvevd.

For å forenkle historien, vil jeg vende meg til en analogi. Jeg hørte det et sted og vil gjerne støtte det. Tenk på en BLE-enhet som en bokhylle med flere hyller. Hver hylle er et eget tema. For eksempel har vi hyller med science fiction, matematikk og leksikon. På hver hylle er det bøker med et spesifisert emne. Og noen bøker har til og med papirbokmerker med notater. I tillegg har vi en liten papirkatalog over alle bøkene. Hvis du husker, er skolebibliotek en smal boks med papirkort. Med denne analogien er kabinettet profilen til enheten vår. Hyller er tjenester, bøker er kjennetegn, og katalogen er en attributttabell. Bokmerker i bøker er beskrivelser, som jeg også skal snakke mer om senere.

Alle som har utviklet enheter vet at mange prosjekter har lignende kodebiter. Faktum er at mange enheter har lignende funksjonalitet. For eksempel, hvis enheter drives av batterier, vil problemet med lading og overvåking av nivået være det samme. Det samme gjelder sensorer. Egentlig en objektorientert tilnærming til programmering "gir muligheten til å lage objekter som kombinerer egenskaper og atferd til en selvstendig forening som deretter kan gjenbrukes". Etter min mening forsøkte BLE en lignende tilnærming. Profiler ble utviklet av Bluetooth Special Interest Group (SIG). Enheter fra forskjellige produsenter som har samme profiler bør fungere med hverandre uten problemer. Profiler består på sin side av tjenester, og tjenester av egenskaper, supplert med beskrivelser. Generelt kan det se slik ut:

Tenk for eksempel på profildiagrammet til en pulsmåler (treningsarmbånd). Den består av to tjenester og flere egenskaper. Fra det blir profilhierarkiet umiddelbart klart. Sjekkpunktkarakteristikken tilbakestiller det totale kaloriforbruket til null.

1. Pulstjenesten inkluderer tre egenskaper (0x180D):
    a) Obligatorisk hjertefrekvenskarakteristikk (0x2A37)
    b) Valgfri kroppssensorposisjonskarakteristikk (0x2A38)
    c) Betingede egenskaper for hjertefrekvenskontrollpunktet (0x2A39)
2. Batterivedlikeholdstjeneste (0x180F):
    a) Obligatorisk batteriladenivåkarakteristikk (0x2A19)

UUID

For at vi skal få unik tilgang til profilelementer (tjenester, egenskaper og beskrivelser), må vi nummerere dem alle på en eller annen måte. For dette formålet introduseres et konsept som Universally Unique ID (UUID) eller Universally Unique Identifier. UUID er angitt i parentes på hver linje. Og det er en særegenhet her. For UUID bestemte vi oss for å bruke en kode på 16 og 128 bits i lengde. Hvorfor spør du? I BLE-protokollen handler alt om energisparing. Derfor er dimensjonen på 16 bits ganske rimelig. Det er usannsynlig at mer enn 65 tusen vil bli opprettet i nær fremtid. unike tjenester og egenskaper. For øyeblikket er alt de kunne ha allerede blitt talt (husk hvor dette kom fra - "han telte deg også" :-)) Nummererte elementer profiler, tjenester, kjennetegn и beskrivelser du kan se på lenkene.

Imidlertid tror jeg alle husker historien med 4 byte med IP-adresser på Internett. Først trodde vi at det var nok, men nå kan vi fortsatt ikke bytte til en 6-byte adresse. For ikke å gjenta denne feilen og gi fritt spillerom til de lekne hendene til DIYers, bestemte SIG seg umiddelbart for å introdusere 128-bit UUID. Dette minner meg personlig om det ulisensierte 433 MHz-båndet, som ble gitt til alle slags kulibiner fra radiokanalen. I vårt tilfelle ble en 128-bits identifikator av tjenester og egenskaper samlet ut. Dette betyr at vi, for våre tjenester og enheter, kan bruke nesten hvilken som helst 128-bits verdi. Likevel, sannsynligheten for å komme opp med samme UUID har en tendens til null.

Faktisk har korte 16-bits UUID-er utvidelsen til en 128-bits verdi. I spesifikasjonen heter denne utvidelsen Bluetooth Base UUID og har verdien 00000000-0000-1000-8000-00805F9B34FB. Hvis for eksempel 16-bits attributtet UUID har verdien 0x1234, vil tilsvarende 128-bits UUID ha verdien 00001234-0000-1000-8000-00805F9B34FB. Og til og med den tilsvarende formelen er gitt:

                                128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID

Jeg vet ikke hvor dette magiske tallet kom fra. Hvis noen av leserne vet, la dem skrive i kommentarfeltet (En bruker med kallenavnet Sinopteek har allerede gjort dette. Se kommentarene). Når det gjelder å komme opp med 128-biters UUID-er, kan du i prinsippet bruke en spesiell generatorhvem vil gjøre det for deg.

ATTy GATTy...

Faktisk, da begynner moroa. La meg minne deg på at ATT er basert på et klient-tjenerforhold. Nå ser vi på serverenheten. Den inneholder informasjon som sensorverdier, lysbryterstatus, plasseringsdata osv. Nå som alle "deltakerne i paraden vår" er nummerert, må vi på en eller annen måte plassere dem i enhetens minne. For å gjøre dette legger vi dem i en tabell kalt en attributttabell. Husk dette godt. Dette er selve hjertet til BLE. Det er dette vi vil vurdere videre. Nå vil vi kalle hver linje et attributt. Dette bordet ligger dypt i stabelen, og vi har som regel ikke direkte tilgang til det. Vi initialiserer den og får tilgang til den, men det som skjer inni er skjult for oss bak syv seler.

La oss se på bildet fra spesifikasjonen, men før det vil jeg umiddelbart trekke oppmerksomheten til den hyppige forvirringen i termer, nemlig i beskrivelser. Deskriptorens rolle er å utfylle beskrivelsen av karakteristikken. Når det er nødvendig å utvide mulighetene, brukes deskriptorer. De er også attributter, og akkurat som tjenester og egenskaper er de plassert i attributttabellen. Vi vil undersøke dem i detalj i den andre delen av artikkelen. Noen ganger refererer imidlertid beskrivelser til radnummeret i attributttabellen. Dette må man huske på. For å unngå forvirring vil vi bruke begrepet "attributtpeker" for disse formålene.


Så et attributt er en diskret verdi som har følgende egenskaper knyttet til seg:
1. Attributthåndtak er tabellindeksen som tilsvarer attributtet
2. Attributttype er en UUID som beskriver typen
3. Attributtverdi er dataene som indekseres av attributtpekeren
4. Attributttillatelser er den delen av et attributt, tillatelsene, som ikke kan leses eller skrives ved hjelp av attributtprotokollen

Hvordan forstå alt dette? Attributtpekeren er relativt sett nummeret i tabellen vår.
Den lar en klient referere til et attributt i lese- eller skriveforespørsler. Vi kan nummerere våre linjer (attributter) fra 0x0001 til 0xFFFF. I vår tilknytning til bokhyllen er dette kortnummeret i papirkatalogen. På samme måte, som i bibliotekskatalogen, er kortene ordnet i stigende rekkefølge etter antall. Antallet på hver påfølgende linje må være større enn den forrige. Akkurat som på biblioteket blir det noen ganger noen kort som blir borte, så hos oss kan det være hull i linjenummereringen. Dette er tillatt. Hovedsaken er at de går gradvis.

Attributttypen bestemmer hva attributtet representerer. I analogi med C-språket,
der det er boolske, numeriske variabler og strenger, så er det her. Etter attributttype kjenner vi igjen
hva vi har å gjøre med og hvordan vi kan fortsette å jobbe med denne egenskapen. Nedenfor skal vi se på noen spesifikke typer attributter. For eksempel «tjenesteerklæring» (0x2800), «karakteristisk erklæring» (0x2803), «deskriptorerklæring» (0x2902).

Verdien av en egenskap er dens faktiske betydning, tilgi tautologien. Hvis attributttypen er en streng, kan attributtverdien for eksempel være slagordet "Hello World !!!". Hvis attributttypen er en "tjenesteerklæring", er verdien selve tjenesten. Og noen ganger er dette informasjon om hvor du finner andre attributter og deres egenskaper.

Attributttillatelser lar serveren forstå om lese- eller skrivetilgang er tillatt.
Merk at disse tillatelsene bare gjelder for attributtverdien, og ikke for pekeren, typen eller selve tillatelsesfeltet. De. hvis attributtopptak er tillatt, kan vi endre for eksempel linjen "Hello World !!!" til linjen "God morgen". Men vi kan ikke forby å skrive en ny linje eller endre attributttypen og angi linjen som en "serviceerklæring". Når en klient kontakter en server, ber klienten om dens attributter. Dette lar klienten vite hva serveren kan tilby. Selv om det ikke er nødvendig å lese og skrive verdiene.

Hvordan ser det ut?

Konseptet med GATT er å gruppere attributter i en attributttabell sammen i en veldig spesifikk og logisk rekkefølge. La oss se nærmere på pulsprofilen nedenfor. Kolonnen lengst til venstre i denne tabellen er valgfri. Den beskriver ganske enkelt for oss hva denne linjen (attributtet) er. Alle andre kolonner er allerede kjent for oss.

På toppen av hver gruppe har vi alltid en tjenesteerklæringsattributt. Dens type er alltid 0x2800, og pekeren avhenger av hvor mange attributter som allerede finnes i tabellen. Dens tillatelser er alltid skrivebeskyttet, uten noen form for autentisering eller autorisasjon. Vi skal snakke om disse konseptene litt senere. Verdien er en annen UUID som identifiserer hva tjenesten er. I tabellen er verdien 0x180D, som er definert av Bluetooth SIG som en pulstjeneste.

Etter kunngjøringen av tjenesten, kommer kunngjøringen av karakteristikken. Den ligner i form på en serviceerklæring. Dens UUID er alltid 0x2803, og dens tillatelser er alltid skrivebeskyttet uten autentisering eller autorisasjon. La oss se på Attributtverdi-feltet, som inneholder noen data. Den inneholder alltid en peker, en UUID og et sett med egenskaper. Disse tre elementene beskriver den påfølgende erklæringen av den karakteristiske verdien. Pekeren angir naturligvis plasseringen av den karakteristiske verdideklarasjonen i attributttabellen. UUID beskriver hvilken type informasjon eller verdi vi kan forvente. For eksempel temperaturverdien, lysbryterens tilstand eller en annen vilkårlig verdi. Og til slutt egenskaper, som beskriver hvordan den karakteristiske verdien kan samhandles med.

En annen fallgruve venter oss her. Det er assosiert med attributttillatelser og karakteristiske egenskaper. La oss se på bildet av bitfeltegenskapene fra spesifikasjonen.

Som du kan se, er det også felt her som gir lese- og skrivefunksjoner. Du lurer kanskje på hvorfor vi har lese-/skrivetillatelser for attributt og eiendom
lese/skrive for karakteristisk verdi? Burde de ikke alltid være like? Faktum er at egenskapene for den karakteristiske verdien faktisk kun er anbefalinger for klienten brukt i GATT og applikasjonslag. Dette er rett og slett hint om hva klienten kan forvente av det karakteristiske deklarasjonsattributtet. La oss se på dette mer detaljert. Hvilke typer tillatelser har et attributt?

1. Tilgangstillatelser:
     - lesing
     - ta opp
     - lese og skrive
2. Autentiseringstillatelse:
     - autentisering kreves
     - Ingen autentisering kreves
3. Autorisasjonstillatelse:
     — autorisasjon kreves
     - ingen autorisasjon kreves

Hovedforskjellen mellom attributtoppløsning og karakteristiske egenskaper er at førstnevnte gjelder for servere, og sistnevnte for klienter. Serveren kan få lov til å lese den karakteristiske verdien, men kan kreve autentisering eller autorisasjon. Derfor, når klienten ber om egenskapene til karakteristikken, vil vi motta at lesing er tillatt. Men når vi prøver å lese, får vi en feilmelding. Derfor kan vi trygt snakke om prioriteringen av tillatelser over eiendommer. På klientsiden kan vi ikke få kunnskap om hvilke tillatelser et attributt har.

Beskrivelse

La oss gå tilbake til bordet vårt. Etter å ha deklarert verdien av en egenskap, er følgende attributterklæringer mulige:
1. Ny erklæring om egenskaper (en tjeneste kan ha mange egenskaper)
2. Ny serviceerklæring (det kan være mange av dem i tabellen)
3. Erklære et håndtak

Når det gjelder hjertefrekvensmålingskarakteristikken, i tabellen vår, er erklæringen om den karakteristiske verdien ledsaget av erklæringen fra beskrivelsen. En deskriptor er et attributt med tilleggsinformasjon om en egenskap. Det finnes flere typer deskriptorer. Vi vil snakke om dem i detalj i den andre delen av denne artikkelen. Foreløpig vil vi bare berøre klientkarakteristisk konfigurasjonsbeskrivelse (CCCD). Den har en UUID lik 0x2902. Ved å bruke denne beskrivelsen har klienten muligheten til å aktivere indikasjon eller varsling på serveren. Forskjellen mellom dem er liten, men fortsatt der. Melding krever ikke bekreftelse på mottak fra oppdragsgiver. Indikasjon krever dette, selv om det forekommer på GATT-nivå, og når ikke anvendelsesnivået. Hvorfor det, spør du? Akk, jeg vet ikke dette. La meg bare si at nordiske eksperter anbefaler å bruke varsler. I tillegg skjer kontroll av integriteten til pakken (ved hjelp av CRC) i begge tilfeller.

Konklusjon

På slutten av artikkelen vil jeg gjerne si dette. Den siste tabellen er litt forvirrende. Men jeg valgte det fordi det er gitt etter artikkelsom jeg stoler på. I den andre delen av artikkelen min har jeg tenkt å gå dypere inn i BlueTooth 4.0-spesifikasjonen. Der venter oss flere korrekte diagrammer og tegninger. I den tredje delen vil jeg analysere loggen oppnådd ved hjelp av Wireshark-programmet fra en av gadgetene og se "live" all teorien vi studerer.

Ansatt i konsernet "Caesar Satellite"
Pecherskikh Vladimir

Kilde: www.habr.com