BLE under et mikroskop (ATTы GATTы…)
Del 1, oversigt
Der er allerede gået ret lang tid siden den første specifikation for Bluetooth 4.0 blev udgivet. Og selvom BLE-emnet er meget interessant, afskrækker det stadig mange udviklere på grund af dets kompleksitet. I mine tidligere artikler kiggede jeg hovedsageligt på det laveste niveau, Link Layer og Physical Layer. Dette gjorde det muligt for os at undgå at skulle ty til så komplekse og forvirrende begreber som Attribut Protocol (ATT) og General Attribut Profile (GATT). Der er dog ingen steder at gå hen, uden at forstå dem er det umuligt at udvikle kompatible enheder. I dag vil jeg gerne dele denne viden med dig. I min artikel vil jeg stole på for begyndere fra den nordiske hjemmeside. Så lad os komme i gang.
Hvorfor er alt så svært?
Efter min mening stod det umiddelbart klart, at styring af enheder via smartphones er et meget lovende og langtidsholdbart emne. Derfor besluttede de at strukturere det med det samme og maksimalt. Så producenter af diverse gadgets ikke kommer med deres egne protokoller, som så vil være uforenelige. Derfor vanskeligheden. Allerede i første fase forsøgte de at presse alt muligt ind i BLE-protokollen. Og det er lige meget, om det vil være nyttigt senere eller ej. Derudover sørgede de for muligheden for at udvide listen over enheder til fremtiden.
Lad os tage et kig på billedet, hvor BLE-protokoldiagrammet er tegnet. Den består af flere lag. Det laveste fysiske lag (PHY) er ansvarlig for enhedens radiokanal. Link Layer(LL) indeholder hele sekvensen af bytes i den transmitterede meddelelse. I tidligere artikler studerede vi præcis dette. Host Controller Interface (HCI) er en udvekslingsprotokol mellem BLE-lag eller chips, hvis controlleren og værten er implementeret på forskellige chips. Logical Link Control and Adaptation Protocol (L2CAP) er ansvarlig for pakkedannelse, framing, fejlkontrol og pakkesamling. Security Manager Protocol (SMP) er ansvarlig for kryptering af pakker. General Access Profile (GAP) er ansvarlig for den indledende udveksling af data mellem enheder for at bestemme "Hvem er hvem". Det omfatter også scanning og annoncering. I denne artikel vil jeg fokusere på de to resterende dele af protokollen - GATT og ATT. GATT er en overbygning af ATT, så de hænger tæt sammen.
For at forenkle historien vil jeg gerne vende mig til en analogi. Jeg har hørt det et sted og vil gerne støtte det. Tænk på en BLE-enhed som en reol med flere hylder. Hver hylde er et separat tema. For eksempel har vi hylder med science fiction, matematik og encyklopædier. På hver hylde er der bøger med et specificeret emne. Og nogle bøger har endda papirbogmærker med noter. Derudover har vi et lille papirkatalog over alle bøger. Hvis du husker det, er skolebiblioteker en smal kasse med papirkort. Med denne analogi er kabinettet profilen på vores enhed. Hylder er tjenester, bøger er karakteristika, og kataloget er en attributtabel. Bogmærker i bøger er deskriptorer, som jeg også vil fortælle mere om senere.
Enhver, der har udviklet enheder, ved, at mange projekter har lignende stykker kode. Faktum er, at mange enheder har lignende funktionalitet. For eksempel, hvis enheder drives af batterier, vil problemet med opladning og overvågning af deres niveau være det samme. Det samme gælder sensorer. Faktisk en objektorienteret tilgang til programmering "giver muligheden for at skabe objekter, der kombinerer egenskaber og adfærd til en selvstændig forening, som derefter kan genbruges". Efter min mening forsøgte BLE en lignende tilgang. Profiler blev udviklet af Bluetooth Special Interest Group (SIG). Enheder fra forskellige producenter, der har de samme profiler, bør arbejde sammen uden problemer. Profiler består til gengæld af tjenester og tjenester af karakteristika, suppleret med deskriptorer. Generelt kan det se sådan ud:
Overvej for eksempel profildiagrammet for en pulsmåler (fitnessarmbånd). Den består af to tjenester og flere karakteristika. Fra det bliver profilhierarkiet straks klart. Checkpoint-karakteristikken nulstiller det samlede kalorieforbrug.
1. Pulstjenesten omfatter tre egenskaber (0x180D):
a) Obligatorisk pulskarakteristik (0x2A37)
b) Valgfri kropssensorpositionskarakteristik (0x2A38)
c) Betingede karakteristika for pulskontrolpunktet (0x2A39)
2. Batterivedligeholdelsesservice (0x180F):
a) Obligatorisk batteriopladningsniveaukarakteristik (0x2A19)
UUID
For at vi entydigt kan få adgang til profilelementer (tjenester, karakteristika og beskrivelser), er vi nødt til at nummerere dem alle på en eller anden måde. Til dette formål introduceres et koncept som Universally Unique ID (UUID) eller Universally Unique Identifier. UUID er angivet i parentes på hver linje. Og der er en ejendommelighed her. Til UUID besluttede vi at bruge en kode på 16 og 128 bit i længden. Hvorfor spørger du? I BLE-protokollen handler alt om energibesparelse. Derfor er dimensionen på 16 bit ganske rimelig. Det er usandsynligt, at mere end 65 tusind vil blive oprettet i den nærmeste fremtid. unikke tjenester og egenskaber. I øjeblikket er alt, hvad de kunne have været talt allerede (husk, hvor det kom fra - "han talte også dig" :-)) Nummererede elementer , , и du kan se på linkene.
Jeg tror dog, at alle husker historien med 4 bytes IP-adresser på internettet. Først troede vi, at det var nok, men nu kan vi stadig ikke skifte til en 6-byte adresse. For ikke at gentage denne fejl og give frie tøjler til de legende hænder på DIYers, besluttede SIG straks at introducere 128-bit UUID'er. Dette minder mig personligt om det ulicenserede 433 MHz-bånd, som blev givet til alle slags Kulibins fra radiokanalen. I vores tilfælde blev en 128-bit identifikator af tjenester og karakteristika opbrugt. Det betyder, at vi, for vores tjenester og enheder, kan bruge næsten enhver 128-bit værdi. Alligevel er sandsynligheden for at komme op med den samme UUID tendens til nul.
Faktisk har korte 16-bit UUID'er deres udvidelse til en 128-bit værdi. I specifikationen hedder denne udvidelse Bluetooth Base UUID og har værdien 00000000-0000-1000-8000-00805F9B34FB. Hvis f.eks. 16-bit attributten UUID har værdien 0x1234, så vil den tilsvarende 128-bit UUID have værdien 00001234-0000-1000-8000-00805F9B34FB. Og endda den tilsvarende formel er givet:
128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID
Jeg ved ikke, hvor dette magiske tal kom fra. Hvis nogen af læserne ved det, så lad dem skrive i kommentarerne (En bruger med kaldenavnet Sinopteek har allerede gjort dette. Se kommentarerne). Med hensyn til at komme med 128-bit UUID'er, kan du i princippet bruge en speciel hvem vil gøre det for dig.
ATTy GATTy...
Faktisk, så begynder det sjove. Lad mig minde dig om, at ATT er baseret på et klient-server-forhold. Nu kigger vi på serverenheden. Den indeholder information såsom sensorværdier, lyskontaktstatus, lokationsdata osv. Nu hvor alle "deltagerne i vores parade" er nummererede, skal vi på en eller anden måde placere dem i enhedens hukommelse. For at gøre dette sætter vi dem i en tabel kaldet en attributtabel. Husk dette godt. Dette er selve hjertet i BLE. Det er det, vi vil overveje yderligere. Nu vil vi kalde hver linje for en attribut. Dette bord er placeret dybt i stakken, og vi har som regel ikke direkte adgang til det. Vi initialiserer det og får adgang til det, men hvad der sker indeni er skjult for os bag syv segl.
Lad os se på billedet fra specifikationen, men inden da vil jeg straks gøre opmærksom på den hyppige forvirring i termer, nemlig i deskriptorer. Deskriptorens rolle er at supplere beskrivelsen af karakteristikken. Når det er nødvendigt at udvide dets muligheder, bruges deskriptorer. De er også attributter, og ligesom tjenester og karakteristika er de placeret i attributtabellen. Vi vil undersøge dem i detaljer i anden del af artiklen. Nogle gange henviser deskriptorer dog til rækkenummeret i attributtabellen. Dette skal huskes. For at undgå forvirring vil vi bruge udtrykket "attribut pointer" til disse formål.
Så en attribut er en diskret værdi, der har følgende egenskaber tilknyttet:
1. Attribut Handle er det tabelindeks, der svarer til attributten
2. Attribut Type er en UUID, der beskriver dens type
3. Attributværdi er de data, der indekseres af attributmarkøren
4. Attributtilladelser er den del af en attribut, tilladelserne, som ikke kan læses eller skrives ved hjælp af attributprotokollen
Hvordan skal man forstå alt dette? Attributpointeren er relativt set dens nummer i vores tabel.
Det giver en klient mulighed for at referere til en attribut i læse- eller skriveanmodninger. Vi kan nummerere vores linjer (attributter) fra 0x0001 til 0xFFFF. I vores tilknytning til reolen er dette kortnummeret i papirkataloget. Ligesom i bibliotekets katalog er kortene arrangeret i stigende rækkefølge. Antallet af hver efterfølgende linje skal være større end den foregående. Ligesom på biblioteket bliver nogle kort nogle gange væk, så hos os kan der være huller i linjenummereringen. Dette er tilladt. Det vigtigste er, at de går gradvist.
Attributtypen bestemmer, hvad attributten repræsenterer. I analogi med C-sproget,
hvor der er booleske, numeriske variable og strenge, så er det her. Efter attributtype genkender vi
hvad vi har med at gøre, og hvordan vi kan fortsætte med at arbejde med denne egenskab. Nedenfor vil vi se på nogle specifikke typer attributter. For eksempel "serviceerklæring" (0x2800), "karakteristisk erklæring" (0x2803), "deskriptorerklæring" (0x2902).
Værdien af en egenskab er dens faktiske betydning, tilgiv tautologien. Hvis attributtypen er en streng, så kan attributværdien for eksempel være sloganet "Hello World !!!". Hvis attributtypen er en "servicedeklaration", så er dens værdi selve tjenesten. Og nogle gange er dette information om, hvor man kan finde andre attributter og deres egenskaber.
Attributtilladelser giver serveren mulighed for at forstå, om læse- eller skriveadgang er tilladt.
Bemærk, at disse tilladelser kun gælder for attributværdien og ikke for selve markøren, typen eller tilladelsesfeltet. De der. hvis attributregistrering er tilladt, kan vi for eksempel ændre linjen "Hello World !!!" til linjen "Godmorgen". Men vi kan ikke forbyde at skrive en ny linje eller ændre attributtypen og udpege linjen som en "serviceerklæring". Når en klient kontakter en server, anmoder klienten om dens attributter. Dette giver klienten mulighed for at vide, hvad serveren kan levere. Selvom det ikke er nødvendigt at læse og skrive værdierne.
Hvad det ser ud til
Konceptet med GATT er at gruppere attributter i en attributtabel sammen i en meget specifik og logisk rækkefølge. Lad os se nærmere på pulsprofilen nedenfor. Kolonnen længst til venstre i denne tabel er valgfri. Det beskriver ganske enkelt for os, hvad denne linje (attribut) er. Alle andre kolonner er allerede bekendt for os.
Øverst i hver gruppe har vi altid en serviceerklæringsattribut. Dens type er altid 0x2800, og markøren afhænger af, hvor mange attributter, der allerede er til stede i tabellen. Dens tilladelser er altid skrivebeskyttet uden nogen form for godkendelse eller autorisation. Vi vil tale om disse begreber lidt senere. Værdien er en anden UUID, der identificerer, hvad tjenesten er. I tabellen er værdien 0x180D, som er defineret af Bluetooth SIG som en pulstjeneste.
Efter meddelelsen af tjenesten kommer meddelelsen om karakteristikken. Det svarer i form til en serviceerklæring. Dens UUID er altid 0x2803, og dens tilladelser er altid skrivebeskyttet uden nogen form for godkendelse eller autorisation. Lad os se på feltet Attributværdi, som indeholder nogle data. Den indeholder altid en pointer, et UUID og et sæt egenskaber. Disse tre elementer beskriver den efterfølgende erklæring om den karakteristiske værdi. Markøren angiver naturligvis placeringen af den karakteristiske værdideklaration i attributtabellen. UUID beskriver, hvilken type information eller værdi vi kan forvente. For eksempel temperaturværdien, lyskontaktens tilstand eller en anden vilkårlig værdi. Og endelig egenskaber, som beskriver, hvordan den karakteristiske værdi kan interageres med.
Endnu en faldgrube venter os her. Det er forbundet med attributtilladelser og karakteristiske egenskaber. Lad os se på billedet af bitfeltegenskaberne fra specifikationen.
Som du kan se, er der også felter her, der giver læse- og skrivemuligheder. Du undrer dig måske over, hvorfor vi har læse-/skrivetilladelser til attribut og ejendom
læse/skrive for karakteristisk værdi? Burde de ikke altid være ens? Faktum er, at egenskaberne for den karakteristiske værdi faktisk kun er anbefalinger til klienten brugt i GATT og applikationslag. Disse er blot hints om, hvad klienten kan forvente af den karakteristiske erklæringsattribut. Lad os se på dette mere detaljeret. Hvilke typer tilladelser har en attribut?
1. Adgangstilladelser:
- læsning
- optage
- Læs og skriv
2. Godkendelsestilladelse:
- autentificering påkrævet
- ingen godkendelse påkrævet
3. Godkendelsestilladelse:
- Autorisation Påkrævet
- ingen autorisation kræves
Den største forskel mellem attributopløsning og karakteristiske egenskaber er, at førstnævnte gælder for servere, og sidstnævnte for klienter. Serveren kan få lov til at læse den karakteristiske værdi, men kan kræve godkendelse eller autorisation. Derfor, når klienten anmoder om egenskaberne for karakteristikken, vil vi modtage, at læsning er tilladt. Men når vi prøver at læse, får vi en fejl. Derfor kan vi roligt tale om prioriteringen af tilladelser over ejendomme. På klientsiden kan vi ikke få viden om, hvilke tilladelser en attribut har.
Deskriptor
Lad os vende tilbage til vores bord. Efter angivelse af værdien af en egenskab er følgende attributerklæringer mulige:
1. Ny erklæring om egenskaber (en tjeneste kan have mange karakteristika)
2. Ny serviceerklæring (der kan være mange af dem i tabellen)
3. Erklæring af et håndtag
I tilfælde af pulsmålingskarakteristikken, i vores tabel, er erklæringen af den karakteristiske værdi ledsaget af erklæringen fra deskriptoren. En deskriptor er en attribut med yderligere information om en egenskab. Der er flere typer deskriptorer. Vi vil tale om dem i detaljer i anden del af denne artikel. Indtil videre vil vi kun berøre Client Characteristic Configuration Descriptor (CCCD). Den har et UUID svarende til 0x2902. Ved at bruge denne deskriptor har klienten mulighed for at aktivere indikation eller notifikation på serveren. Forskellen mellem dem er lille, men der er stadig. Meddelelse kræver ikke bekræftelse af modtagelse fra klienten. Indikation kræver dette, selv om det forekommer på GATT-niveau, og når ikke anvendelsesniveauet. Hvorfor det, spørger du? Ak, jeg ved det ikke. Lad mig bare sige, at nordiske eksperter anbefaler at bruge notifikationer. Desuden sker kontrol af pakkens integritet (ved hjælp af CRC) i begge tilfælde.
Konklusion
Til sidst i artiklen vil jeg gerne sige dette. Den sidste tabel er lidt forvirrende. Jeg valgte det dog, fordi det er givet efter , som jeg stoler på. I anden del af min artikel har jeg tænkt mig at dykke dybere ned i BlueTooth 4.0-specifikationen. Der venter os mere korrekte diagrammer og tegninger. I den tredje del vil jeg gerne parse loggen opnået ved hjælp af Wireshark-programmet fra en af gadgets og se "live" al den teori, vi studerer.
Medarbejder i koncernen
Pecherskikh Vladimir
Kilde: www.habr.com