Budapesti Műszaki és Gazdaságtudományi Egyetem Hálózati Rendszerek és Szolgáltatások Tanszék Mobil Kommunikáció és Kvantumtechnológiák Laboratórium
Bevezetés a Bluetoth Low Energy alapú fejlesztésbe Mérési segédlet
Mérés helye:
1117 Budapest, Budafoki út 111. (Buda Plaza irodaház) Infokom-Innovátor Nonprofit Kft.
Összeállította:
Balogh András, PhD hallgató
Utolsó módosítás:
2017.02.23.
Bevezetés A napjainkban uralkodó IoT-hez (Internet of Things), azaz a “dolgok internetéhez” kapcsolódó paradigmaváltás olyan szempontokat hozott előtérbe, melyekre a korábban domináns szerepet betöltő vezeték nélküli kommunikációs technológiák nem helyeztek elegendően nagy hangsúlyt. Ilyen sarkalatos igények közé sorolható az egyszerű fejleszthetőség, a mindennapok során egyre fontosabb szerepet betöltő “okos” készülékekkel való kompatibilitás, a kontextusfüggő alkalmazások és így beltéri helymeghatározás lehetősége, a relatíve alacsony késleltetés, a szenzorhálózati alkalmazások támogatása, valamint az alkalmasint jól skálázható energiaigény. Jóllehet a Bluetooth Low Energy (BLE) technológiát a Bluetooth SIG (Special Interest Group) 2010-ben vezette át a Bluetooth “Core” specifikációjába (v4.0), annak fejlesztési előzményei egészen 2006-ig nyúlnak vissza, amikor is a Nokia bejelentette a Wibree nevű technológiát [2], melyet a BLE előfutáraként is emlegetnek. Az alapkoncepciót megtartva, ám bizonyos mechanizmusok átdolgozásával került később átvezetésre ezen megoldás a Bluetooth szabványba a hagyományos technológia kiegészítéseként [1], ami egyfajta válaszként is szolgált az előbbiekben felsorolt igényekre. A laborgyakorlat célja a hallgatók megismertetése az aktuálisan egyre nagyobb fejlesztői közönségnek örvendő Bluetooth Low Energy (bizonyos körökben “Bluetooth Smart” néven is emlegetett) technológia működésével, valamint a BLE alapú alkalmazások fejlesztésének mikéntjével beágyazott környezetekben. A laborgyakorlat alapvetően vezetett és kooperatív jellegű, így célszerű a segédletben leírtakból minél alaposabban felkészülni annak érdekében, hogy a hallgatókból minél kevésbé akadályozzák egymás munkáját. A gyakorlat elején egy 10 perces beugró keretein belül szükséges írásban számot adni a segédletben leírtakból. Amennyiben a hallgató nem bizonyul elegendően felkészültnek, nem kezdheti meg a gyakorlatot.
A Bluetooth Low Energy technológia áttekintése A hagyományos Bluetooth (v3.0-ig) technológiával szemben a BLE célja nem a “burst” jellegű (pl. fájlok, objektumok), valamint a késleltetésre érzékeny adatok (pl. hang, videó) átvitele, hanem a kisebb adatcsomagok (pl. státuszüzenetek, szenzoradatok) minél hatékonyabb továbbítása, ami egyben ki is jelöli azon lehetséges alkalmazásokat, melyek képesek megfelelőképpen foganatosítani e technológia működését. Az alábbiakban néhány aktuális alkalmazási terület került felsorolásra (a teljesség igénye nélkül): ● ● ● ●
Egészségügyi- és sporteszközök (pl. lázmérők, szívritmusmérők, okoslabdák, stb.) Otthonautomatizálás (pl. termosztátok, hőmérők, aktuátorok, zárak, stb.) Okos “kütyük” (pl. okostárca, okosóra, okoskulcstartók, stb.) Beltéri helymeghatározás (pl. iBeacon, Eddystone, stb.)
A 2010-es bejelentést követően a BLE több revízión is átesett [1], így például a 2013-ban bevezetett 4.1-es verzióban a hagyományos technológiából is ismert Piconet topológia kiegészült a Scatternet (több összekapcsolt Piconet) formációk lehetőségével, aminek segítségével multihop kommunikációt is megvalósíthatunk. Ezt követően a 2014-ben bejelentett v4.2-es változatban pedig - többek között - az alkalmazható csomagok nagyságát növelték meg hozzávetőlegesen (20 byte-ról) 250 byte-ra, amivel nagyobb throughput érhető el. Bár az aktuálisan elérhető legfrissebb specifikáció (v5.0) a 4.0-hoz képest lényegesen bővült, jelen mérés keretein belül kizárólag a v4.2-ig elérhetővé tett funkciók kerülnek ismertetésre. Mind az évszámokból, mind pedig a revíziós ciklusidőkből látható, hogy igencsak kurrens és dinamikusan fejlődő technológiáról van szó, mely aktivitásban igen nagy szerepet játszik, hogy az Apple mobil készülékei már 2011-től (iPhone 4S), míg az Android operációs rendszeren alapuló eszközök 2013-tól támogatják a BLE alapú alkalmazások fejlesztését a rendelkezésre álló publikus API-k segítségével [3] [4]. A BLE protokollarchitektúrája (1. ábra) ugyanakkor - jelen állás szerint - nem változott az utóbbi évek során, s a könnyebb integrálhatóság, valamint a megfelelő szinteken való egyszerűbb átjárhatóság végett több ponton is közösnek tekinthető a hagyományos technológiával.
1. ábra - A Bluetooth technológia architektúrája
Vertikálisan az architektúra (stack) több szempont mentén is csoportosítható. A Host illetve a Controller rétegcsoportok, valamint a kettő között kapcsolatot teremtő HCI interfész a megvalósíthatóság szerint rendezi az egyes rétegeket, ugyanis számos esetben a BLE IC-k, csak az adatkapcsolati, valamint a fizikai réteg funkcióit tartalmazzák (Controller), s a Host vezérli azok működését. Jellemző példa erre a PC-k esetében alkalmazott USB csatlakozóval ellátott Bluetooth “dongle” eszközök, melyek USB transzport felett valósítják meg a HCI parancsok kezelését.
Ugyanakkor ellenpéldaként említhetők az egyre inkább terjedő SoC (System-on-Chip) megoldások, ahol egyetlen IC-n belül található egy programozható MCU (Microcontroller Unit), valamint egy BLE rádiós frontend, amit a megfelelő regiszterek segítségével vezérelnek. Mindennek megfelelően az ilyen szempontból való felosztás tulajdonképpen csak lehetőséget teremt az egyes funkciók elkülönítésére, s ebből fakadóan korántsem tekinthető szigorúan követendőnek minden esetben (ez utóbbi esetben a HCI interfészt például nem is feltétlenül implementálják). Egy másik lehetőség a rádió és közeghozzáférés vezérlése, az ezen funkciókat vezérlő eljárások (protokollok) együttese, valamint az eljárásokra épülő alkalmazások (úm. profilok) szerinti csoportosítás, mely sokkal inkább az egyes rétegek feladatainak megértését segíti, s ebből fakadóan csak informatív jelleggel bír. A sötétebb egységek a “Core” specifikációban részletesen definiált, míg a világosabb színnel jelölt egységek csak kiegészítő (opcionális) specifikációval (Bluetooth SIG által kezelt profilok) rendelkeznek, vagy a felhasználó által szabadon határozhatók meg, s ebből fakadóan a különböző gyártók BLE stack-jei ezen funkciók biztosítására nem feltétlenül terjednek ki. Az 1. ábrán található együttes stack megfelel az ún. dual-mode Bluetooth (avagy Bluetooth Smart Ready) eszközökben található képességeknek, melyek együttesen támogatják a BLE, valamint a hagyományos technológiát (pl. okostelefonok, tabletek, laptopok). A függőlegesen húzódó szaggatott vonal különíti el a hagyományos rétegeket (balra), a BLE specifikus rétegektől (jobbra). Ez utóbbi mechanizmusok működése kerül a következő alpontokban kifejtésre.
Fizikai és adatkapcsolati rétegcsoport (MAC/PHY) A Bluetooth LE, a hagyományos változathoz hasonlóan a 2,4 GHz-es ISM frekvenciasávban operál, ám 79 db csatorna helyett a rendelkezésre álló 80 MHz-es sávszélességet 40 db csatornára osztja, melyek egytől-egyig 2 MHz sávszélességgel rendelkeznek. Az így meghatározott sávokon GFSK (Gaussian Freqency Shift Keying) modulációval történik az információ átvitele, összesen 1 Mbps szimbólumsebesség mellett. A GFSK a hagyományos FSK modulációtól annyiban tér el, hogy a moduláló elemi jel alakja nem négyszög, hanem annak egy megfelelő Gauss-szűrőn átvezetett változata, ami így a moduláció és a demoduláció megvalósítása során egyszerűbben kezelhető frekvenciamenetet eredményez.
2. ábra - BLE Advertising és Data csatornák a 2,4 GHz-es ISM sávban [5]
A BLE adatkapcsolati rétege (MAC), a Link Layer a rendelkezésre álló 40 csatornát két csoportra osztja (2. ábra), nevezetesen, Advertising csatornákra (3 db) és Data csatornákra (37 db), melyeken, bár más és más mechanizmusok és megkötések érvényesek, a csatornahozzáférés alapelve mindegyik mögött az FDMA (Frequency Division Multiple Access) és TDMA (Time Division Multiple Access) együttese, úgynevezett Eventek segítségével, melyek típusai és időzítései a BLE Link Layer aktuális állapotaitól (3. ábra) függenek.
3. ábra - A Bluetooth LE Link Layer állapotgép
Az Advertising, valamint a Scanning állapotokban az Advertising csatornákon való forgalmazás történik Advertising Eventek segítségével, melyek során az Advertising állapotban található eszközök kvázi periodikus jelleggel sugároznak Advertising PDU-kat (Protocol Data Unit) az egyes Advertising csatornákon (4. ábra). Két egymást követő Advertising Event között az időbeli megkötések: ● ●
advInterval ≧ 20 ms advDelay ∈ (0, 10) ms
Az időbeli megkötések közül míg az advInterval értékét szabadon megválaszthatjuk, addig az advDelay értékét a stack egyenletes eloszlás szerint sorsolja az ütközések elkerülése végett. Egy Advertising PDU általánosságban a következő mezőket tartalmazza: ● ● ● ●
A PDU típusa Forrás MAC cím (a címzésről később) Cél MAC cím (ha szükséges) Adatok (max. 31 oktett) - {hossz, típus, érték} struktúrák szerint rendezve
4. ábra - A Bluetooth LE Advertising Eventek időzítései [6]
Ugyan a korábban leírtaknak megfelelően minden Advertising Event során Advertising PDU-k sugárzása történik az egyes Advertising csatornákon (5. ábra), az, hogy az egyes Advertising Eventeken belül mely Advertising csatornákon, és milyen típusú Advertising PDU-kat alkalmazunk szintén alkalmazásfüggő.
5. ábra - Advertising Eventekhez köthető rádiós aktivitások [6]
Az Advertising csatornákon alkalmazható PDU-k fontosabb típusai az alábbiak: ● ● ● ●
ADV_IND ADV_DIRECT_IND ADV_NONCONN_IND ADV_SCAN_IND
Az általános Advertising PDU az ADV_IND típusú, mely bármely Scanning állapotban levő állomás által vételezhető, s ennek vételekor lehetséges a kapcsolódási folyamat kezdeményezése is. Az ADV_DIRECT_IND PDU-t akkor célszerű alkalmazni, amikor ismert azon céleszköz, amelynek az adott PDU tartalmát szánjuk. Az ADV_NONCONN_IND jellemző alkalmazási területe a kapcsolatmentes kommunikáció, ahol is egyszerű szórásos jelleggel sugárzunk bárki számára hasznosítható információkat (ilyen pl. a beltéri pozicionálás), ugyanakkor fontos különbség, hogy a kapcsolódási folyamat ezen egy típus esetében nem kezdeményezhető. Az ADV_SCAN_IND pedig egy, a Scanning állapothoz köthető PDU típus, s függően a szkennelési módszer típusától lehetőséget teremt további aktivitásokra.
6. ábra - Scanning állapothoz köthető aktivitások aktív módban [6]
A Scanning állapotot illetően ugyanis megkülönböztethetünk aktív, valamint passzív üzemmódot, melyek pusztán annyiban térnek el, hogy míg passzív esetben egyszerűen a vételezett Advertising PDU-k tartalmát továbbítja a Link Layer a felsőbb rétegek irányába, addig aktív esetben egy ADV_SCAN_IND PDU vételezése esetén mód van további adatok kinyerésére egy SCAN_REQ, valamint az arra válaszként adott SCAN_RSP PDU segítségével (6. ábra) a forrástól. A Scanning állapotban kétfajta időzítést határozhatunk meg: ● ●
scanWindow: Az RX időablak hossza (egyetlen csatornán) scanInterval: A csatornaváltás periodicitása (scanInterval ≧ scanWindow)
A korábban említett kapcsolatfelépítési folyamat is az aktív Scanning állapothoz hasonló folyamatot követ, azonban Initiating állapotban mindig egy, vagy több kitüntetett eszköz Advertising PDU-jára vár az az egység, amely a kapcsolatfelépítést kezdeményezi. Amennyiben a megfelelő PDU vételezésre kerül, a kezdeményező fél egy CONNECT_REQ PDU sugároz ki, majd Connection állapotba lép M aster szerepben (7. ábra).
7. ábra - Kapcsolatfelépítési folyamat a BLE technológiában [6]
Azon egység, amely Advertising állapotban CONNECT_REQ PDU-t vételezett, adott időn belül (~transmitWindowOffset) szintén Connection állapotba kell lépjen, azonban Slave szerepben, s a kommunikációt ezt követően a Data csatornákon szükséges folytatnia Data PDU-k segítségével (max. 250 oktett), a Master egység által meghatározott időzítések szerint: ● ● ●
connInterval ≧ 7.5 ms connSlaveLatency ≧ 0 connSupervisionTimeout ≧ (connSlaveLatency+1)*connInterval
Az alkalmazott Data csatornák kiválasztása a hagyományos technológiához hasonlóan a BLE esetében is pszeudorandom módon történik, azonban itt egyetlen Master esetében is Slave eszközönként eltérhet az alkalmazott szekvencia, valamint nem fix gyakorisággal történik a frekvenciák váltogatása, hanem a connInterval értéke (két egymást követő Connection Event között eltelt idő) szabja meg, hogy egyetlen Slave mennyi időt is tölt egyetlen csatornán.
8. ábra - BLE Csatornatípusok és a kapcsolódó topológiák [6]
Ebből fakad az, hogy Slave eszközönként (8. ábra - “B” és “C”) eltérő Piconet csatornát (frekvenciaugratási-szekvencia + időzítések) alkalmazhat egy Master (“A” egység), nemúgy, mint a hagyományos technológia esetében, ahol minden Master alá betagozódó Slave egység azonos frekvenciaugratási mintát követ, fix gyakorisággal. Minthogy mind az időzítések, mind a frekvenciák tekintetében a Master egység a kapacitásainak megfelelően szabadon rendelkezhet, a Piconetben résztvevő eszközök maximális számára tulajdonképpen nincs explicit megkötés. A connSlaveLatency érték szabja meg, hogy egyetlen Slave egység hány Connection Eventet hagyhat ki maximálisan, míg a connSupervisionTimeout azt mondja meg, hogy mennyi idő után bontja a Master a kapcsolatot, ha nem kap választ a Slave egységtől. A BLE esetében ugyanis a Connection Eventek során folyamatosan kommunikál a Master és a Slave egység egymással (minden időrésben legalább egy-egy Data PDU segítségével), függetlenül attól, hogy volt-e ténylegesen átviendő adat, vagy sem. Megjegyzés: A BLE specifikációja nem tér ki arra, hogy egyetlen Connection Eventen belül, hány Master-Slave üzenetváltás történhet meg, azaz implementációfüggő, hogy egy vagy több ilyen időrés nyílik egy connInterval idő alatt. A leírtak alapján belátható, hogy amennyiben 20 ms advInterval érték mellett történik az Advertising Eventek időzítése (pl. 8. ábra - “D” eszköz), úgy ideális esetben maximum 30 ms (advInterval + advDelay) elegendő lehet, ahhoz, hogy az Iniating állapotban található eszköz (“A”) tudomást szerezzen az eszköz jelenlétéről, s amennyiben a transmitWindowOffset mérete nem túl nagy (pl. 50 ms), úgy hozzávetőlegesen 100 ms idő alatt fel tud épülni egy BLE kapcsolat. Ez igen komoly előrelépés a hagyományos Bluetooth technológia 5-10 másodperces kapcsolatfelépítési idejéhez képest.
Egy már felépült kapcsolat bontása tetszés szerint történhet a Master, vagy a Slave egység által egy alkalmas időrésben küldött LL_TERMINATE_IND Data PDU segítségével. Ekkor azon állapotgép, amely az adott Piconet csatornáért felelt Standby állapotba kerül.
Multihop BLE hálózatok A BLE Scatternetek (összekapcsolt Piconetek) abból az alapgondolatból indulnak ki, hogy egyetlen eszközön több Link Layer állapotgép is működhet párhuzamosan, s ebből fakadóan maga a BLE eszköz ezen állapotgépek szuperpozíciójában is működhet a kapacitásaihoz mérten (9. ábra).
9. ábra - BLE Scatternetek [7]
Így például mód van arra is, hogy a 9. ábrán látható “M” eszköz Mastere legyen a “K” eszköznek, ami így Slave eszközként vesz részt az “M-K” Piconetben, míg a “K-L” Piconetben ezzel “egyidejűleg” Masterként ütemezi az “L” egység vonatkozó rádiós aktivitását. Mindazonáltal egyetlen egyég lehet egyidejűleg Slave több Piconetben is (9. ábra “O” egysége). Az összetettebb BLE Scatternetek megvalósítása ugyanakkor meglehetősen komplex ütemezési mechanizmusokat igényelhet, hiszen a rendelkezésre álló idő- és frekvenciabeli erőforrásokat szükséges úgy allokálni, hogy az minimális öninterferenciát eredményezzen a hálózat egészében (pl. a párhuzamos Scanning, Advertising és Initiating állapotokból fakadóan).
Címzés a Bluetooth LE technológiában A Link Layerben hajtódnak végre a címzéssel kapcsolatos mechanizmusok is. Változás a hagyományos technológiához képest, hogy a címzést immáron sokkal szabadabban végezhetjük. A Bluetooth LE-ben ugyanis a publikus (IEEE 802 szabványnak megfelelő) 48 bites MAC címek mellett bevezetésre kerültek a random és privát MAC címek, melyek közül az előbbi egyszerű pszeudo-véletlen algoritmusokkal szabadon generálható, addig az utóbbi biztonsági célokat szolgál, nevezetesen, ha párosítottuk (erről később) magunkat egy eszközhöz, úgy annak címét teljesen elrejthetjük mások elől, hiszen a stack véletlenszerűen fogja adott időközönként változtatni azt és a csak a közös titok birtokában lehetünk képesek olyan címet előállítani a kapcsolódás során, melyre az adott modul válaszolni fog.
L2CAP réteg A Link Layer felett helyezkedik el az L2CAP (Logical Link Control Adaptation Protocol), amely csatorna alapú absztrakciót végez a szolgáltatások és alkalmazások számára. Így magukat az eszközöket, azaz a hozzájuk tartozó BLE Piconet csatornát (kizárólag a Connection állapot) gyakorlatilag egy Connection Handle (16 bit) segítségével érhetjük el, melynek segítségével így megvalósulhat az egyes üzenetek küldése és fogadása. Az adatok szegmentációjára és összeállítására, valamint a kapcsolódó torlódásvezérlő mechanizmusokra a felette elhelyezkedő Attribute protokoll és a Generic Attribute Profile jellegéből fakadóan nincs szükség.
Generic Access Profile (GAP) A Generic Access Profile a Link layer egyes állapotait és átmeneteit fogja össze úgy, hogy az olyan folyamatok, mint a kapcsolatfelépítés, eszközfelderítés, Advertising PDU-k sugárzása, valamint egyéb képességek “atomi” jelleggel értelmezhetők legyenek. A GAP által definiált szerepek a következők: ● ● ● ●
Broadcaster Observer Peripheral Central
Egy Broadcaster szerepben működő eszköz gyakorlatilag nem csinál mást csak Advertising PDU-kat sugároz az Advertising Event-ek során, míg Observer szerepben egy eszköz az Advertising PDU-kat “monitorozza” az Advertising csatornákon. Bármely olyan eszköz, amely elfogadhatja egy LE kapcsolat létrehozását Peripheral szerepet tölt be, s egy ilyen eszköz a Link Layer Connection állapotában Slave szerepet fog betölteni. Azon eszközök pedig, amelyek támogatják a Central szerepet, kezdeményezhetik egy LE fizikai kapcsolat létrejöttét, s ebből fakadóan Master szerepben fognak fellépni a Link Layer Connection állapotában. Bár a GAP számos procedúrát és működési módot definiál az egyes szerepek függvényében, azok gyakorlatlag a Link Layer különböző képességeinek kombinációiban merülnek ki, s ebből fakadóan a technológia lényegi működését tekintve nem hordoznak különösebb újdonságot. Az egyes GAP szerepek ugyanakkor gyakran megjelennek a különböző BLE IC-k és stackek képességeinek jegyzékében, így legalább az egyes szerepek által lefedett Link Layer állapotkombinációk ismerete mindenképpen fontos. A Generic Access Profile további részletezésétől jelen dokumentumban eltekintünk, s a laborgyakorlat során is csak marginálisan érintjük.
Generic Attribute Profile (GATT) A Generic Attribute Profile tulajdonképpen egy általános keretrendszert definiál a BLE alapú alkalmazások és szolgáltatások fejlesztéséhez. A kapcsolódó szerepek és folyamatok egytől-egyig az Attribute (ATT) protokoll segítségével valósulnak meg, azonban ennek működésére jelen leírásban szintén nem térünk ki. Ennek oka egyrészről az, hogy az alkalmazások fejlesztése, és így a foganatosítható GATT mechanizmusok szempontjából tulajdonképpen transzparens az ATT réteg működése, másrészről pedig nincs olyan paramétere a protokollnak, amelyet direkt, vagy indirekt módon befolyásolni lehetne.
10. ábra - A GATT keretrendszer által definiált objektumok típusai [6]
A keretrendszer segítségével alapvetően a kliens-szerver modellre képezhetjük le az egyes szolgáltatásokat és alkalmazásokat, ahol a szerveren úgynevezett Attribute objektumokat hozhatunk létre (10. ábra), ezzel egyfajta kisebb adatbázist megvalósítva a BLE eszközön. Az Attribute objektumok (adatbázis bejegyzések) alaptípusai az alábbi hierarchia szerint szervezhetők: ●
Primary Service ○ Secondary (Included) Service ○ Characteristic ■ Descriptor
A Primary Service bejegyzések azonosítják magát a szolgáltatást, melyen belül definiálhatunk további (Secondary) Service-eket.. A Characteristic elemek, melyek a ténylegesen elérendő adatot azonosítják, szintén csak egy Primary Service kontextusában értelmezhetők. A Descriptor bejegyzések pedig jellemzően a Characteristic értékekhez csatolódnak, s definiálják az ott elérhető adatok értelmezési lehetőségeit, valamint a kapcsolódó Characteristic bejegyzések egyéb tulajdonságait. Az egyszerűbb alkalmazások a Bluetooth SIG kontextusában a legnagyobb szervezési egységként, azaz profilként jelennek meg, melyeken belül több Service-t is definiálhatunk, ezen entitás ugyanakkor csak a szervezést segítő célzattal jött létre, s a “Core” specifikációban a két generikus profil (GAP és GATT) kivételével sehol sem jelenik meg. A Generic Attribute Profile keretein belül a Service bejegyzések állnak a legmagasabb hierarchiaszinten.
11. ábra - A kliens és a szerver közötti interakciók a GATT kontextusában [8]
Az egyes objektumok létrehozását (bejegyzését) követően a kliens szerepében működő BLE eszköz a szerverrel amolyan egyszerűbb adatbázis interakciók (kérés-válasz jelleg) segítségével kommunikálhat (11. ábra), azaz módja van a bejegyzések felderítésére, illetőleg azok írására és olvasására (függően a bejegyzés konfigurációjától), ami lényegesen leegyszerűsíti a különböző alkalmazások adatokhoz való hozzáférésének mikéntjét, jóllehet magát a szerveren található GATT struktúrát a kliens sosem módosíthatja. Mindezen felül van két további funkciója GATT keretrendszernek, ami egyfajta feliratkozáskezelésként is felfogható. A GATT jelzési képességek ugyanis lehetővé teszik, hogy egy adott kliens, a szerveren található Characteristic bejegyzésekhez opcionálisan létrehozható CCCD (Client Characteristic Configuration Descriptor) értékét módosítva “feliratkozzon” bizonyos adatokra, s a folyamatos “polling” helyett, az adatbázis jelezhesse a számára - az alkalmazási logika függvényében - az adott bejegyzés aktuális tartalmát. A jelzésnek két típusát különböztethetjük meg, a Notification a nyugtázatlan jelzésnek, míg az Indication a nyugtázott jelzésnek felel meg. A GATT kliens, illetőleg szerver képességei tetszés szerint alkalmazhatók, GAP Central (Master) és Peripheral (Slave) szerepben is.
GATT jogosultságkezelés (SMP) A Bluetooth Low Energy architektúráját illetően azért nem került szóba eddig a Security Manager Protocol (SMP), mert a gyakorlat során szintén csak érintőlegesen kerül elő a feladatok megvalósítása kapcsán. A teljesség ugyanakkor megkívánja a kapcsolódó mechanizmusok rövid tárgyalását, ami jelen esetben a GATT vonatkozásában történik meg. A GATT keretrendszerben ugyanis az egyes Attribute bejegyzéseket különböző módokon konfigurálhatjuk, függően az általuk elérhető adatok/funkciók jellegétől (pl. a Notification és Indication funkciók elérhetősége is ezen konfigurációtól függ). Előfordulhat ugyanis, hogy míg bizonyos bejegyzéseket publikusan elérhetővé teszünk (pl. egy áthaladást jelző lámpa esetében az áthaladási igény jelzését, illetve az állapot lekérdezését), addig másokat (pl. aktuális állapot felülírása) csak megfelelő hozzáférési szint mellett szeretnénk megjeleníteni, illetőleg az azzal kapcsolatos műveleteket adott esetben titkosítani. Erre szolgál a GATT Authorization opciója, ami kapcsolódhat az írási, valamint az olvasási funkciókhoz egyaránt. Az állomások hitelesítésére, valamint a kapcsolatok titkosítására a BLE technológiában léteznek különböző eljárások, melyekért az SMP réteg felel. Ezek együttes elnevezése a “párosítás” (Pairing, Bonding), mely folyamat során, függően a lehetséges interakcióktól (pl. gombnyomás, szövegbevitel, megjelenítés, NFC) az egyes eszközökön, lehetőség van akár a legmagasabb biztonsági szint elérésére (hitelesítés és titkosítás). Ezen folyamatot követően, függően attól, hogy milyen szintet ér el az adott eszköz, lehetőség nyílik a bejegyzésekhez való hozzáféréshez az alkalmazási logika függvényében. További konfigurációs lehetőségként jelenik meg, a “best-effort” jellegű (nyugtázatlan) írás (minthogy önmagában minden interakció nyugtázott), a megbízható írás, ami a beírandó érték bevitelét követően visszaküldi a beírt értéket, valamint a broadcast opció, ami lehetővé teszi, hogy az adott bejegyzés tartalmát az eszköz Advertising PDU formájában, a megfelelő típus segítségével kisugározza.
Alkalmazási réteg Jelen pontban egy példajellegű alkalmazás segítségével illusztráljuk az egyes rétegekben szükséges szerepeket, valamint folyamatokat. Tegyük fel, hogy a feladatunk egy gombelemről működő háztartási hőmérséklet szenzorhoz tartozó BLE specifikus funkcióknak a megvalósítása. A Bluetooth SIG honlapján az alkalmazásunk számára két, már definiált GATT Service struktúra is rendelkezésre áll: ● ●
Battery Service (BAS) [9] Environmental Sensing Service (ESS) [10]
A Battery Service-en (UUID: 0x180F) belül egyetlen Battery Level Characteristic (UUID: 0x2A19) bejegyzésen keresztül érhetjük el az elem aktuális állapotát, mely az előírtaknak megfelelően egy olyan 8 bites, előjel nélküli integer, ami [0, 100] értékek között értelmezett
(%-ban). Aemennyiben a GATT jelzési funkcióit is kihasználjuk, úgy egy CCCD deszkriptor bejegyzés (UUID: 0x2902) is tartozik ezen Characteristic-hez. Az ESS (UUID: 0x181A) számos szenzorértéket tartalmazhat opcionálisan, ám számunkra csak a Temperature Characteristic (UUID: 0x2A6E) szükséges. A leírtaknak megfelelően ezen bejegyzés segítségével egy olyan 16 bites, előjeles integert érhetünk el, amely az aktuális hőmérsékletet 0.01 Celsius lépték szerint mutatja. Mindennek megfelelően az alábbi struktúrát és konfigurációkat szükséges bejegyeznünk a GATT szerverünkün, azaz a fejlesztendő szenzoregységen: ●
●
Battery Service ○ Battery Level (read only) ■ Client Characteristic Configuration Descriptor (read, write) Environmental Sensing Service ○ Temperature (read only)
Ezzel a GATT specifikus funkciók meghatározása véget is ért. A GAP tekintetében, minthogy nem jellemző, hogy egy hőmérsékletszenzor maga kezdeményezzen kapcsolatot, elegendő a Peripheral szerep az egység számára. Az időzítések tekintetében, minthogy gombelemről működik az eszköz, és a rádió adási üzemmódban hozzávetőlegesen 10 mA áramot vesz fel, célszerű nagyobb advInterval értékeket alkalmazni, hiszen nem kritikus, ha egy szenzoregység csak 1 mp múlva válik képessé a kommunikációra, ugyanakkor annál fontosabb, hogy a rendelkezésre álló gombelem kapacitását minél hatékonyabb módon használjuk ki. A kapcsolat folyamatos fenntartása nem célszerű az eszközzel, hiszen a háttérben folytatott folyamatos üzenetküldések viszonylag rövid idő alatt felemésztenék a kapacitást, ráadásul a connInterval tekintetében nem is feltétlenül nyilatkozhatunk, hiszen a Master egység ütemezi a kommunikációt, s amennyiben az egy mobil készülék, nincs is mód a publikus API-k szintjén ennek szabályozására. Mindebből fakadóan, ha egyszerű fejszámolással, ha azt feltételezzük, hogy a rendelkezésre álló kapacitás 30%-a felett rendelkezhetünk az egy CR2032-es gombelem esetében kb. 80 mAh-t jelent, ami mindösszesen 8 óra folyamatos működést tenne elérhetővé, ha az egység folyamatosan adna, vagy éppen venne. Ellenben mivel az Advertising PDU kb. 400 bit hosszú, annak kiküldése (1 Mbps) éppen 0,4 ms időt igényel, advInterval időnként háromszor. A kitöltési tényező éppen ezért kb. 0,0025-re adódik, ami összesen kb. 133 napra, azaz hozzávetőlegesen 4 hónapra elegendő. Minthogy az összefüggések lineárisak, az optimalizáció az igényelt kapacitás, illetőleg a késleltetés függvényében, viszonylag könnyen elvégezhető. Ezzel gyakorlatilag meg is határoztuk egy olyan hőmérsékletszenzor BLE specifikus képességeit, amely tetszőleges erre a feladatra fejlesztett alkalmazással kompatibilis, hiszen az alkalmazásunkat kizárólag szabványos elemekből építettük fel.
A mérési környezet ismertetése A hallgatók a mérés során három csoportra tagozódnak. Minden csoport számára biztosítunk egy lapotopot (Linux), valamint egy BLE fejlesztőpanelt. A laborgyakorlat nagyrészt a Bluetooth Low Energy beágyazott fejlesztési kérdéseire fókuszál, így az elvégzendő feladatok zőme a fejlesztőpanelen található SoC architektúrát követő BLE chipre fejlesztett alkalmazások programozásában (C nyelven), valamint a lekódolt feladatok verifikációjában merül ki. A hallgatócsoportok számára biztosított laptopokon egyszerű Linux (Ubuntu) operációs rendszer fut, s a fejlesztés mindenfajta integrált fejlesztőkörnyezet (IDE) nélkül történik, egyszerű szövegszerkesztő, a gyártói SDK, valamint alkalmas fordításra és programozásra készült szkriptek segítségével.
12. ábra - A Nordic Semiconductors nRF52 fejlesztőpanel [11]
A laborban alkalmazott panel (12. ábra) egy, a Nordic Semiconductors által az nRF52-es IC szériához gyártott, integrált fejlesztőkészlet [12], mely tartalmazza a megfelelő programozó MCU-t, valamint a különböző perifériákat (gombok, LED-ek) és GPIO (General Purpose Input Output) kivezetéseket. A panelen található nRF52832 egység programozása így egyszerűen egy USB kábel csatlakoztatását követően megvalósítható. Az egyes feladategységek elkészültét verifikálandó, lehetőség nyílik a Linux operációs rendszereken elérhető BlueZ stack [13] és a kapcsolódó programcsomag (hcittool, hcidump, gatttool) képességeinek kihasználására. Bár a gyakorlat során okostelefont nem biztosítunk, amennyiben a hallgató a mérésre hoz magával egy legalább 4.3-as verziószámú (hivatalos) Android operációs rendszert futtató készüléket, úgy opcionális feladatként mód van az Android Bluetooth LE képességeivel való megismerkedésre is a panel gyártója által közzétett nRF Master Control Panel applikáció [14] használatával.
A mérés során külön jegyzőkönyv nem készül, a megvalósított programkódok megjegyzéseiben (kommentek) szükséges a fejlesztéssel kapcsolatban felmerült kérdéseket, problémákat, és azok megoldásait, illetve a kapcsolódó gondolatokat ismertetni.
1. Egyszerű GATT Service megvalósítása Az első feladat során az egyes csoportok a mérésvezető útmutatása alapján egy olyan egységes GATT Service struktúra kell kidolgozzanak, melynek segítségével a fejlesztőpanelen található LED-ek vezérlése (bekapcsolása, kikapcsolása, villogtatása) megvalósulhat. Az egységesség kritériuma jelen esetben azért fontos, hogy egy csoport egy tetszés szerint választott másik csoport tesztpaneljén is képes legyen ugyanezen akciók végrehajtására. A feladathoz kapcsolódó alfeladatok: 1. Tervezzék meg és programozzák le a kidolgozott struktúrát az előírásoknak megfelelően. 2. Verifikálják megoldásuk működését a BlueZ programcsomag, valamint opcionálisan a mobil készülékek segítségével. 3. Teszteljék a többi csoport megoldását ugyanezen eszközök alkalmazásával. Csak akkor lehet érdemben belekezdeni a második feladatba, ha minden csoport sikeresen végrehajtotta az előbbiekben felsorolt alfeladatokat.
2. Vezérlési funkciók implementációja A második feladat során az alapvető cél, hogy az előbbi feladatban megvalósított verifikációs feladatokat az egyes fejlesztőpaneleken található BLE egységek önműködően is meg tudják valósítani, azaz képesek legyenek az összes eszközön a saját csoportjuknak megfelelő LED-et gombnyomásra bekapcsolni. Amennyiben az egyik csoport előbb elkészült a többieknél, célszerű elgondolkodnia azon, hogyan is valósítaná meg a következő feladatot (önállóan nekikezdeni továbbra sem érdemes).
3. BLE Scatternetek létrehozása A harmadik feladat során a kitűzött cél egy 3 Piconetből álló BLE Scatternet létrehozása, ahol az egyes eszközök között gyűrű topológia valósul meg. Az egyes felépítendő kapcsolatokat a mérésvezető jelöli ki. A kijelölt Scatternet felett egy önműködő, vezérjeles gyűrűhöz hasonló hálózati protokollnak szükséges működnie, ahol egy, a mérésvezető által kijelölt csoport eszköze kezdeményezi a topológia kialakítását. A topológia kialakulását követően ugyanezen eszköz elindít egy Tokent (vezérjelet) a hálózatban, melyet minden soron következő eszköz a megfelelő feladatok végrehajtását követően tovább ad a másik szomszédjának a topológiában. Végeredményében egy folyamatosan cirkuláló vezérjelnek kell létrejönnie a hálózatban.
Megoldást szemléltetendő és verifikálandó, a protokoll (mérésvezető segítségével való) kidolgozásán felül, úgy szükséges módosítani a korábbiakban megvalósított GATT struktúrát és a kapcsolódó logikát, hogy az egységes maradjon, illetőleg, hogy képes legyen az összes eszközön azonos képet mutatnia (a LED-ek segítségével) arról, hogy melyik eszközön is van éppen a vezérjel.
Útmutató a felkészüléshez Kezdésképpen célszerű a hagyományos Bluetooth technológiával kapcsolatos ismereteket feleleveníteni annak érdekében, hogy a Bluetooth Low Energy variánsának ahhoz képesti előnyeit és hátrányait kellőképpen megértse hallgató. Ez ugyanakkor opcionális feladat, s nem is lesz semmilyen módon számonkérve. A Bluetooth Low Energy technológia áttekintését tartalmazó leírásának tanulmányozása, és az ott leírtakból való minél alaposabb felkészülés ugyanakkor célszerű, ugyanis a beugróban számon lesz kérve. Fontos ismerni mind a Link Layer állapotait, mind az azok közötti átmenetek mögött húzódó folyamatokat, a kapcsolódó időzítési mechanizmusokat, a GATT keretrendszer képességeit és objektumait, valamint GAP által definiált szerepeket is ahhoz, hogy a megvalósítandó feladatok tervezése, a beágyazott környezetben való fejlesztés, illetőleg a megoldások verifikációja is minél zökkenőmentesebben történjen meg. A legtöbb feladatban ugyanis a technológia különböző alkalmazási lehetőségei képezik a vizsgálat alapját, nem pedig magának a technológiának a működése. A technológiai leírásból való felkészülést követően célszerű elgondolkodnia a hallgatónak azon, hogy milyen struktúrákat, folyamatokat és beállításokat alkalmazna a mérési feladatok megoldása során, s azokat milyen gondolatok mentén tudná megindokolni. Mindezen felül a felsorolt eszközök (pl. mobil alkalmazás, BlueZ programcsomag, stb.) dokumentációit is javasolt átfutni, jóllehet ezek szintén nem lesznek számonkérve.
Forrásjegyzék [1] Bluetooth SIG, “Adopted Specifications", B luetooth Technology Website, 2016. [Online]. Available: https://www.bluetooth.com/specifications/adopted-specifications. [Accessed: 26Apr- 2016]. [2] Nokia, "Nokia introduces Wibree technology as open industry initiative", Press Releases, 2006. [Online]. Available: http://company.nokia.com/en/news/press-releases/2006/10/03/nokia-introduces-wibree-tech nology-as-open-industry-initiative. [Accessed: 26- Apr- 2016]. [3] Apple, "About Core Bluetooth", iOS Developer Library, 2016. [Online]. Available: https://developer.apple.com/library/ios/documentation/NetworkingInternetWeb/Conceptual/C oreBluetooth_concepts/AboutCoreBluetooth/Introduction.html. [Accessed: 02- May- 2016].
[4] Android, "Bluetooth Low Energy", Developer Portal, 2016. [Online]. Available: http://developer.android.com/intl/zh-cn/guide/topics/connectivity/bluetooth-le.html. [Accessed: 02- May- 2016]. [5] Joe Decuir, "Bluetooth 4.0: Low Energy", http://chapters.comsoc.org/vancouver/BTLER3.pdf, 2010. [6] Bluetooth SIG, “Core Specification v4.0", B luetooth Technology Website, 2016. [Online]. Available: https://www.bluetooth.com/specifications/adopted-specifications. [Accessed: 26- Apr- 2016]. [7] Bluetooth SIG, “Core Specification v4.1", B luetooth Technology Website, 2016. [Online]. Available: https://www.bluetooth.com/specifications/adopted-specifications. [Accessed: 26- Apr- 2016]. [8] Future Connectivity Solutions, BLE GATT Client-Server model, http://fcs.futureelectronics.com/wp-content/uploads/2014/04/FCS_Image4.jpg, 2014. [9] "Battery Service", Bluetooth Developer Portal, 2016. [Online]. Available: https://developer.bluetooth.org/gatt/services/Pages/ServiceViewer.aspx?u=org.bluetooth.ser vice.battery_service.xml. [Accessed: 02- May- 2016]. [10] "Environmental Sensing Service", Bluetooth Developer Portal, 2016. [Online]. Available: https://developer.bluetooth.org/gatt/services/Pages/ServiceViewer.aspx?u=org.bluetooth.ser vice.environmental_sensing.xml. [Accessed: 02- May- 2016]. [11] Nordic Semiconductors, “nRF52 Series”, Nordic Semiconductors Infocenter, 2016. [Online]. Available: http://infocenter.nordicsemi.com/index.jsp. [Accessed: 02- May- 2016] [12] Nordic Semiconductors, “nRF52 Development Kit”, 2016. [Online]. Available: https://www.nordicsemi.com/eng/Products/Bluetooth-Smart-Bluetooth-low-energy/nRF52-DK . [Accessed: 02- May- 2016] [13] BlueZ, 2016. [Online]. Available: http://www.bluez.org/. [Accessed: 02- May- 2016] [14] Nordic Semiconductors, “nRF52 Development Kit”, 2016. [Online]. Available: https://www.nordicsemi.com/eng/Products/Nordic-mobile-Apps/nRF-Master-Control-Panel-a pplication. [Accessed: 02- May- 2016]
