Lázár Zoltán Dr. Eged Bertalan BME Mikrohullámú Híradástechnika Tanszék http://www.mht.bme.hu Vezetéknélküli Inofrmáció Technológia Laboratórium http://wit.mht.bme.hu hu 1
1. BEVEZETÉS...5 2. BLUETOOTH FIZIKAI RÉTEG...7 2.1 FREKVENCIA SÁVOK ÉS CSATORNA ELRENDEZÉS EZÉS...7 2.2 TELJESÍTMÉNYSZABÁLYOZÁS...7 2.3 MODULÁCIÓ...8 3. BLUETOOTH ALAPSÁVI I EGYSÉG...9 3.1 BLUETOOTH CSATORNA NA...9 3.2 FIZIKAI ÖSSZEKÖTTETÉSEK TETÉSEK...10 3.2.1 SZINKRON (SCO) ÖSSZEKÖTTETÉS...10 3.2.2 ASZINKRON (ACL) ÖSSZEKÖTTETÉS...10 3.3 CSOMAGOK ÁLTALÁNOS FELÉPÍTÉSE...11 3.3.1 HOZZÁFÉRÉSI (ACCESS) KÓD...11 3.3.1.1 Preamble...12 3.3.1.2 Szinkron szó...12 3.3.1.3 Trailer...12 3.3.2 CSOMAG FEJLÉCE...13 3.3.3 HASZNOS INFORMÁCIÓT TARTALMAZÓ RÉSZ...14 3.3.3.1 Hang információ esetén...14 3.3.3.2 Adat információ esetén...14 3.4 CSOMAG TÍPUSOK...16 3.4.1 SZINKRON CSOMAGTÍPUSOK...16 3.4.1.1 HV1 csomag...16 3.4.1.2 HV2 csomag...16 3.4.1.3 HV3 csomag...16 3.4.1.4 DV csomag...16 3.4.2 ASZINKRON CSOMAGTÍPUSOK...17 3.4.2.1 DM csomag...17 3.4.2.2 DH csomag...17 3.4.2.3 AUX1 csomag...17 3.4.3 ÖSSZEKÖTTETÉST VEZÉRLŐ CSOMAGTÍPUSOK...17 3.4.3.1 ID csomag...18 3.4.3.2 NULL csomag...18 3.4.3.3 POLL csomag...18 3.4.3.4 FHS csomag...18 3.5 HIBAJAVÍTÁS...19 3.5.1 FEC 1/3...20 3.5.2 FEC 2/3...20 3.5.3 ARQ VÉDELEM...21 3.5.3.1 Számozatlan ARQ...21 3.5.3.2 Újraküldött csomagok kiszűrése...22 3.5.3.3 Hasznos információ kiürítése...22 3.5.3.4 Több slave egység figyelembevétele...23 3.5.3.5 Broadcast csomagok...23 2
3.6 HIBAELLENŐRZÉS...23 3.7 LOGIKAI CSATORNÁK...25 3.7.1 LC LOGIKAI CSATORNA...25 3.7.2 LM LOGIKAI CSATORNA...26 3.7.3 UA/UI LOGIKAI CSATORNA...26 3.7.4 US LOGIKAI CSATORNA...26 3.8 ADAT FEHÉRÍTÉS (DATA ( WHITENING)...26 3.9 ADATFOLYAM VEZÉRLÉSE LÉSE...27 3.9.1 VEVŐ OLDALI VEZÉRLÉS...27 3.9.2 FORRÁS OLDALI VEZÉRLÉS...27 3.10 BITFOLYAM FELDOLGOZÁSA LGOZÁSA...27 3.10.1 A FEJLÉC FELDOLGOZÁSA...27 3.10.2 A HASZNOS INFORMÁCIÓS RÉSZ FELDOLGOZÁSA...28 3.11 BLUETOOTH ESZKÖZÖK MŰKÖDÉSI ÁLLAPOTAI...28 3.11.1 MASTER/SLAVE IDŐSZINKRONIZÁLÁS...28 3.11.2 CONNECTION ÁLLAPOT...29 3.11.3 STANDBY ÁLLAPOT...30 3.11.4 VISSZATÉRÉS HOLD ÁLLAPOTBÓL...30 3.11.5 FELÉBREDÉS PARK MÓDBÓL...30 3.11.6 PAGE ÁLLAPOT...30 3.11.7 AZ FHS CSOMAG...31 3.11.8 MULTI-SLAVE MŰKÖDÉS...32 3.12 CSATORNA VEZÉRLÉSE ÉSE...33 3.12.1 MASTER-SLAVE DEFINICIÓ...33 3.12.2 BLUETOOTH RENDSZERÓRÁJA...34 3.12.3 CSATORNA HOZZÁFÉRÉSI ELJÁRÁS...34 3.12.3.1 Page scan folyamat...35 3.12.3.2 Page folyamat...35 3.12.3.3 Page response folyamat...36 3.12.4 INQUIRY FOLYAMAT...37 3.12.4.1 Inquiry scan...37 3.12.4.2 Inquiry...38 3.12.4.3 Inquiry válasz...38 3.12.5 CONNECTION ÁLLAPOT...39 3.12.5.1 Aktív mód...40 3.12.5.2 HOLD mód...40 3.12.5.3 Sniff mód...41 3.12.5.4 PARK mód...41 3.12.5.5 Jelző csatorna...42 3.12.5.6 A parkolási folyamat...43 3.12.5.7 Master által kezdeményezett unpark folyamat...44 3.12.5.8 Slave által kezdeményezett unpark folyamat...44 3.12.6 BLUETOOTH ESZKÖZÖK ÁLLAPOTAINAK ÁTTEKINTÉSE...44 3.12.7 SCATTERNET...45 3.12.7.1 Inter-piconet kommunikáció...46 3.12.7.2 Master-slave szerepváltás...46 3.13 FREKVENCIAUGRATÁSI SOROZAT...46 3
3.14 BLUETOOTH AUDIO...47 3.15 BLUETOOTH ESZKÖZ CÍM...48 3.16 BLUETOOTH ADATBIZTONSÁG...48 3.16.1 TITKOSÍTÁS FOLYAMATA...49 3.16.2 HITELESÍTÉS...50 4. AZ ÖSSZEKÖTTETÉS MENEDZSELÉSÉT VÉGZŐ PROTOKOLL...52 4.1 AZ ÖSSZEKÖTTETÉS MENEDZSELÉSÉT VÉGZŐ PROTOKOLL ÉS TULAJDONSÁGAI...52 4.2 HITELESÍTÉS...53 4.3 TITKOSÍTÁS...53 4.4 A RENDSZERÓRÁHOZ KÉPESTI OFSZET KÉRÉSE SE...54 4.5 IDŐRÉS OFSZET INFORMÁCIÓ FORMÁCIÓ...55 4.6 LMP VERZIÓSZÁM LEKÉRDEZÉSE L...55 4.7 MASTER-SLAVE SLAVE SZEREPCSERE...55 4.8 NÉV LEKÉRDEZÉSE...56 4.9 KAPCSOLAT MEGSZAKÍTÁSA...56 4.10 CONNECTION ÁLLAPOTBAN LÉVŐ EGYSÉGEK...57 4.11 TELJESÍTMÉNYSZABÁLYOZÁS...57 4.12 CSATORNA MINŐSÉGÉTŐL FÜGGŐ CSOMAGTÍPUS BEÁLLÍTÁSOK SOK...58 4.13 SZOLGÁLTATÁS MINŐSÉGE (QUALITY OF SERVICE, S QOS)...58 4.14 SCO ÉS ACL ÖSSZEKÖTTETÉSEK LÉTESÍTÉSE SE...59 4.15 ÖSSZEKÖTTETÉSEK FELÜGYELETE...59 5. LOGIKAI ÖSSZEKÖTTETÉST ETÉST VEZÉRLŐ ÉS ALKALMAZÓ ALMAZÓ PROTOKOLL...60 5.1 LOGIKAI ÖSSZEKÖTTETÉST TETÉST VEZÉRLŐ ÉS ALKALMAZÓ PROTOKOLL TULAJDONSÁGAI...60 5.2 AZ L2CAP PROTOKOLL ÉS FELADATAI...61 5.2.1 PROTOKOLL MULTIPLEXÁLÁS...61 5.2.2 SZÉTVÁLASZTÁS ÉS ÖSSZERAKÁS...62 5.2.3 QUALITY OF SERVICE (QOS)...62 5.2.4 CSOPORTOK...62 5.3 L2CAP CSOMAG FELÉPÍTÉSE...63 5.3.1 ÖSSZEKÖTTETÉS ORIENTÁLT PONT-PONT ADATÁTVITELI CSATORNA...63 Hossz mező...63 Csatorna azonosító...63 Hasznos információt tartalmazó rész...63 5.3.2 ÖSSZEKÖTTETÉS NÉLKÜLI PONT-MULTIPONT ADATÁTVITELI CSATORNA...63 Hossz mező...64 Csatorna azonosító...64 PSM...64 Hasznos információt tartalmazó rész...64 4
1. Bevezetés 1998 tavaszán az Ericsson, IBM, Intel, Nokia és a Toshiba megalapította a Bluetooth csoportot, amelynek feladata a számítógép és perifériái valamint más mobil eszközök közötti összeköttetések rádiós megoldásának szabványosítása. Az elsődleges szempont a kis méret, az alacsony fogyasztás és az olcsó előállítási költség volt, ami lehetővé teszi a termék széles körű alkalmazását a különböző hordozható berendezésekben. A Bluetooth egy rövid hatótávolságú a 2.4 GHz es ISM sávban működő rádió összeköttetés, melynek célja az egységeket manapság összekötő kábelek helyettesítése és az eszközök hálózatba szervezése. A rendszer által megvalósított frekvenciaugratást alkalmazó szórt spektrumú adás illetve vétel lehetővé teszi a biztonságos adatátvitelt a vezeték-nélküli hálózatokban, megfelelő mértékűre csökkentve az interferencia valamint fading okozta zavarokat. A rendszer által alkalmazott szimbólumsebesség 1Mbaud. A full duplex adatátvitel megvalósításához az egységek közötti kommunikáció TDD (Time Division Duplex) elv alapján történik. A csatornán az információ csomagok formájában jut el a megcímzett egységhez. Minden csomag különböző frekvencián kerül adásra, és hosszúságuk maximálisan 5 időrés (1 időrés 625 µs) ideig tarthat. A Bluetooth protokoll adat - illetve csomagkapcsolt adatátvitelt valósít meg az időréseket szinkron illetve aszinkron adatcsomagok számára fenntartva. A információ cserében résztvevő egységek egyszerre egy aszinkron adatcsatornát, 3 szinkron hang átvitelére alkalmas csatornát, vagy vegyesen aszinkron adat és szinkron hang átvitelére alkalmas csatornát alkalmazhatnak. A szinkron összeköttetések kétirányú 64kb/s átviteli sebességűek. Az aszinkron összeköttetések esetén a maximális adatátviteli sebesség 723,2 kb/s aszimmetrikusan (ebben az esetben a visszafelé irányuló forgalom 57,6 kb/s), míg szimmetrikus átvitelnél ez 433,9 kb/s. A Bluetooth rendszer egy rádió, egy összeköttetéseket vezérlő és egy összeköttetések menedzselését megvalósító egységből áll, ahogy azt a következő ábra 2.4 GHz Bluetooth rádió Bluetooth összeköttetés vezérlő 5 Bluetooth összeköttetés menedzser & Kiszolgáló I/O
mutatja. 1.1 ábra: Bluetooth rendszeren belül elhelyezkedő funkcionális egységek A Bluetooth lehetővé tesz pont-pont valamint pont-multipont összeköttetéseket egyaránt. Pont-multipont összeköttetések esetén a csatornán több egység osztozik egyszerre. Két vagy több azonos csatornán osztozó egység (maximálisan 8 aktív, illetve több parkolt állapotban lévő Bluetooth eszköz) piconetet alkot. A csatorna hozzáférést a piconeten belül a master egység vezérli. A rendszer lehetőséget biztosít a piconetek hálózatba szervezésére is, így a különböző piconetekbe lévő egységek is képesek egymással kommunikálni. Az így kialakított hálózatot nevezzük scatternetnek. A lehetséges hálózatszervezéseket a 1.2. ábra mutatja. 1.2 ábra: pont-pon t (a), pont-multipont (b) összeköttetés piconet szervezésű hlózatokban egy scatternet felépítése (c) 6
2. Bluetooth fizikai réteg 2.1 Frekvencia sávok és csatorna elrendezés A Bluetooth rendszer a 2,4 GHz-es ISM sávban működik, melynek sávszélessége a világ legtöbb országában 83,5 MHz. Azonban vannak olyan országok, ahol ezt a sávszélességet a rendszer nem tudja teljes egészében felhasználni a frekvenciasáv nemzeti korlátozása miatt. Ezekben az országokban a Bluetooth speciális frekvenciaugratási algoritmusokat alkalmaz, így azon eszközök amelyek ezen speciális algoritmusokat alkalmazzák nem képesek együtt működni a más országokban megvalósított rendszerekkel. Az országonkénti csatornakiosztást a 2.1. táblázat mutatja. 2.1. táblázat: BT csatornakiosztása Földrajzi terület Kijelölt frekvenciasáv RF csatornák USA, Európa és más országok 2,4000 2,4835 GHz f = 2402 + k MHz, k = 0,,78 Spanyolország 2,4450 2,4750 GHz f = 2449 + k MHz, k = 0,,22 Franciaország 2,4465 2,4835 GHz f = 2454 + k MHz, k = 0,,22 A csatornák közötti szeparáció 1 MHz, a különbség a csatornák számában valamint a Bluetooth és az ISM sávon kívüli más alkalmazások frekvenciái közötti biztonsági sávok távolságában van. Ezek a biztonsági sávok, amelyek a szomszédos alkalmazások interferenciái miatt elég fontosak lehetnek, azokban az országokban nagyobbak, ahol a rendszer 23 csatornát alkalmaz. 2.2 Teljesítményszabályozás A Bluetooth a rendszerben található berendezéseket teljesítmény szerint 3 7
osztályba sorolja. Ezen teljesítmény-osztályokat a 2.2. táblázat tartalmazza. Teljesítményszabályozás csak az első osztályba sorolt eszközök számára szükségesek, ahol a kisugárzott teljesítmény 1-100mW. A többi két osztály számára a szabályozás nem szükséges, de alkalmazható lehetővé téve a energia fogyasztás optimalizálását valamint az interferencia szint csökkentését. A teljesítmény 2-8dB -es lépésközönként csökkenthető vagy növelhető. A vevő egység az RSSI mérésével jelezheti a forrásnak, ha az adó teljesítményt csökkenteni vagy növelni szeretné a megfelelő vétel érdekében. Ezzel a szabályozási mechanizmussal a berendezés optimalizálhatja az összeköttetésben lévő egységek kimeneti teljesítményét. A teljesítményszabályozást a Bluetooth az összeköttetés menedzselését magvalósító (Link Manager Protocol, LMP) parancsok segítségével végzi (4. fejezet). 2.2. Táblázat: BT teljesítmény osztályok Teljesítmény osztály Max. kimeneti teljesítmény Min. kimeneti teljesítmény 1 100 mw (20 dbm) 1 mw (0 dbm) 2 2,5 mw (4 dbm) 0,25 mw (-6 dbm) 3 1 mw (0 dbm) N/A 2.3 Moduláció A rendszer GFSK modulációt alkalmaz, ahol BT=0,5 valamint a modulációs index 0,28 és 0,35 közötti érték. A bináris 1 a pozitív frekvencia eltéréssel, míg a bináris 0 a negatív frekvencia eltéréssel valósítják meg a vivőfrekvenciához képest. Ebben a fejezetben nem foglalkoztunk a sávon belüli illetve sávon kívüli kisugárzott intermodulációs termékekre vonatkozó előírásokkal valamint az adóval és vevővel szemben támasztott egyéb követelményekkel sem. Az egységek ezen tulajdonságaira vonatkozólag Európában az ETSI 300.328, Amerikában az FCC 15.247, 15.249, 15.205, 15.209 és Japánban RCR STD-33 hivatkozásai érvényesek. 8
3. Bluetooth alapsávi egység 3.1 Bluetooth csatorna A Bluetooth csatornát a 79 illetve 23 fizikai csatornán megvalósított álvéletlen ugratási sorozat határozza meg. A frekvenciaugratási sorozatot a master egység Bluetooth eszköz címe, fázisát pedig a master egység rendszerórája határozza meg. Mivel minden piconetet vezérlő master eszköz címe és rendszerórája más, így a különböző piconetek frekvenciaugratási sorozata és annak fázisa is más lesz. A Bluetooth csatorna időrésekre van osztva, ahol minden egyes időrésben az egység egy RF frekvencián ad vagy vesz. Az időrések 625 µs hosszúságúak és a master egység által meg vannak számozva. Ez 1600 csatornaváltást jelent másodpercenként. A master valamint slave(k) közötti kommunikáció TDD (Time Division Duplex) elv szerint történik. A master és a slave időrésenként felváltva kommunikál egymással, a master a páros és a slave(k) a páratlan számozású időréseket használva, a 3.1. ábra szerint. 3.1 ábra: TDD (Time Division Duplex) A nagyobb átviteli sebesség elérése érdekében azonban az LMP (az összeköttetés menedzseléséért felelős protokoll) lehetővé teszi a Bluetooth egységek számára három illetve öt időrés egymás utáni használatát is, ahogy azt a 3.2. ábra mutatja. Több időrés felhasználása esetén az aktuális csomag adása egy frekvencián történik, azonban mégis megmarad az eredeti csatornaváltási szekvencia. 9
3.2 ábra: több időrés használata 3.2 Fizikai összeköttetések A master valamint slave közötti összeköttetés típusát tekintve két féle lehet: Szinkron összeköttetés (SCO) Aszinkron összeköttetés (ACL) 3.2.1 Szinkron (SCO) összeköttetés A szinkron összekötetés egy szimmetrikus áramkörkapcsolt pont-pont összeköttetés a piconeten belül a master és egy meghatározott slave egység között, amely az erre a célra előre lefoglalt időrésekben valósul meg. A szinkron összeköttetéseket a master hozza létre az LMP protokoll parancsainak segítségével. A szinkron csomagokat általában hang jellegű információ átvitelére használják. A master egység az általa vezérelt piconeten belül maximálisan 3 darab szinkron összeköttetést létesíthet. A slave egységek ugyanazzal a masterrel maximálisan 3 darab, míg különböző master egységekkel 2 darab szinkron összeköttetést létesíthetnek. A szinkron csomagok hibás átvitel esetén nem kerülnek újraküldésre. Szinkron átvitelnél a master valamint a slave egységek közötti kommunikáció az erre a célra előre lefoglalt időrésekben valósul meg. Ha a slave egy neki címzett szinkron csomagot vesz, akkor a vételt követő időrésben egy szinkron csomaggal válaszol. Ha a megcímzett slave nem tudja dekódolni a saját címét a csomag fejlécében, akkor az előre meghatározott időrésekben jogosult adni. 3.2.2 Aszinkron (ACL) összeköttetés Az aszinkron összeköttetés egy csomagkapcsolt pont-multipont, pont-pont összeköttetés a piconetben résztvevő master és az összes vagy egy meghatározott slave egység között. Az aszinkron kommunikáció azokban az üres időrésekben valósulhat meg, amelyek nincsenek lefoglalva szinkron adatátvitel céljából. 10
Egy master valamint egy slave között csak egy darab ACL összeköttetés valósulhat meg. Ezekben az aszinkron csomagokban az adatintegritás biztosítása végett a hibás csomagok újraadásra kerülnek. A slave azonban csak akkor válaszolhat egy aszinkron csomaggal, ha az azt megelőző időrésben egy neki címzett csomagot vett. Abban az esetben, ha a slave rosszul dekódolta a neki szóló csomag címét, akkor a következő időrésben nem kezdeményezhet adást. Aszinkron összeköttetés esetén lehetőség van a piconetben résztvevő összes egység csoportos címzésére is. Ez az úgynevezett broadcast csomagok segítségével történik, amelyet minden slave egység vesz és dekódol. 3.3 Csomagok általános felépítése A Bluetooth csatornára az adatok csomagokba szervezve kerülnek. A csomagok felépítését a 3.3 ábra mutatja. Minden csomag három részből tevődik össze: access kód, fejléc, hasznos információs rész. LSB 72 54 0-2745 MSB ACCESS kód Fejléc Hasznos információ 3.3 ábra: szabványos csomag formátuma Az access kód valamint a fejléc fix hosszúságú, a hasznos információ maximálisan 2745 bit lehet. 3.3.1 Hozzáférési (access) kód Minden egyes csomag az access kóddal kezdődik (felépítését a 3.4. ábra mutatja). A csomag típusától függően, ha a csomag nem tartalmaz fejlécet és hasznos információt, akkor 68 bit, ellenkező esetben 72 bit hosszúságú. A rendszer az access kódot szinkronizációra, DC ofszet kompenzációra valamint azonosításra használja. Egy piconeten belül minden csomag azonos access kódot alkalmaz. Access kódot használ a rendszer a page illetve az inquiry eljárásoknál is. Ezekben az esetekben a csomagok nem tartalmaznak fejlécet és hasznos információt. LSB 4 64 4 MSB Preamble Szinkron szó Trailer 3.4 ábra: access kód felépítése A rendszer az eszköz állapotától függően 3 különböző típusú access kódot definiál: csatorna acces kód (CAC - Channel Access Code) eszköz access kód (DAC - Device Access Code) inquiry access kód (IAC - Inquiry Access Code) 11
A Bluetooth egységek ezeket az azonosítókat különböző működési módokban használják. DAC illetve IAC használatakor trailer bitekre abban az esetekben nincs szükség, amikor a csomag csak az access kódot tartalmazza. 3.3.1.1 Preamble A preamble a szinkron szó LSB bitjétől függően két fajta lehet. A két lehetséges kombinációt a 3.5. ábra mutatja. LSB MSB LSB 1 0 1 0 1 x x PREAMBLE SZINKRON SZÓ LSB MSB LSB 0 1 0 1 0 x x PREAMBLE SZINKRON SZÓ 3.5 ábra: Preamble 3.3.1.2 Szinkron szó A szinkron szó egy 64 bites kódszó, amely a 24 bites LAP címből származik. CAC használatakor ez a 24 bites LAP a master egységtől, IAC esetén a 24 bites LAP cím előre definiált illetve dedikált, DAC esetén a slave egységtől származik. Az így kapott szinkron szavak minden Bluetooth eszközhöz tartozó különböző LAP címekhez más értékeket adnak. Közös tulajdonságuk továbbá, hogy a szinkron szavak közötti hamming távolság dmin min=14 =14. A szinkron szavak előállításához használt algoritmusokkal jó autokorrelációs tulajdonságok érhetők el. Ez növeli a rendszer időszinkronizációs folyamának hatékonyságát. A szinkron szavak származtatásának folyamatát részletesen a Bluetooth specifikáció tartalmazza [1]. 3.3.1.3 Trailer A trailer felépítése hasonló a preamble felépítéséhez, ahogy azt a 3.6. ábra mutatja. A trailer valamint a szinkron szó utolsó 3 bitje, összesen 7 bit felváltott egyeseket illetve nullákat tartalmaz, amelyek további DC kompenzációt tesznek lehetővé. MSB LSB MSB x x 0 1 0 1 0 SZINKRON SZÓ MSB LSB TRAILER MSB 12
x x 1 0 1 0 1 SZINKRON SZÓ TRAILER 3.6 ábra: a trailer kétféle felépítése CAC használatakor 3.3.2 Csomag fejléce A fejléc az összeköttetés vezérléséhez szükséges (Link Control, LC) információkat tartalmaz, és hat részből tevődik össze. A fejléc formátuma a 3.7. ábrán látható. LSB 3 4 1 1 1 8 MSB AM_ADDR TÍPUS FLOW ARQN SEQN HEC 3.7 ábra: a fejléc felépítése AM_ADDR mező Az AM_ADDR a piconetben résztvevő aktív egységek megkülönböztetésére szolgáló cím. Egy piconeten belül egy vagy több egység kapcsolódik a masterhez. Az egységek megkülönböztetése céljából így minden aktív slave egy 3 bites ideiglenes azonosító címet kap. Ezen ideiglenes azonosító segítségével hivatkozhatnak egymásra a piconeten belüli kommunikációban résztvevő eszközök. Ezen mező a slave címét tartalmazza mind a master slave (master az AM_ADDR használatával címzi meg azt a slave egységet akinek az üzenet szól), mind a slave-master (az adott címmel rendelkező slave üzenete a master egység felé) időrésekben. A csupa nullát tartalmazó AM_ADDR a broadcast csomagok számára van fenntartva jelezve, hogy a megcímzett egység a masterhez tartozó összes slave. Ez alól egyetlen kivétel az FHS csomag (lásd 3.4 fejezet), amely használhatja a csupa nullás címet. Azok a slave egységek, amelyek kiválnak vagy parkolt állapotba kerülnek, a piconeten belüli AM_ADDR címeik érvénytelenné válnak. Visszalépésük alkalmával azonban új azonosítót kell szerezniük. A 3 bites címmel (a csupa nullás cím elhasználása miatt) egyszerre 7 darab aktív slave egység vehet részt a piconeten belüli kommunikációban. TÍPUS mező A 4 bites típus mezővel 16 fajta csomagot különböztethetünk meg. Ezzel a mezővel tehetünk különbséget az 1 valamint több időrés ideig tartó csomagok, illetve a szinkron és aszinkron csomagok között. A lehetséges csomag típusokat részletesebben lásd a csomag típusok fejezetben. FLOW mező Aszinkron adatátvitel esetén a FLOW bit az adatfolyam vezérlésére szolgál. 13
Amikor a vevő oldali puffer megtelt és nem lett kiürítve, akkor az adatátvitel ideiglenes megszakítása a FLOW=0 ba állításával lehetséges. Amikor a vevő puffer üres, akkor az adatátvitel folyamatos működését a FLOW=1 biztosítja. Ha a nem vettük a csomagot, vagy a vett fejléc hibás, akkor FLOW=1. ARQN mező Az ARQN bit a forrást informálja a küldött információ sikeres vagy sikertelen átviteléről, így pozitív illetve negatív nyugtaként használható. Ha az átvitel sikeres volt, akkor a válaszban az ARQN értéke 1, ellenkező esetben nulla. Ha az adatot nem követi nyugtázás, akkor alapértelmezésben hibás átvitelt feltételezünk. SEQN mező A SEQN (Sequential Numbering, SEQN) az adatcsomagok rendezésére szolgál. Minden egyes újonnan elküldött adatcsomagban, amelyet CRC véd a meghibásodás ellen, ez a bit invertálva szerepel. A SEQN lehetővé teszi a vevő oldalon az újraküldött és már helyesen megérkezett csomagok kiszűrését. Ha egy rossz nyugtázás következtében a forrás újraküldi a csomagot, akkor a vevő kétszer ugyanazt a csomagot kapja meg, így két azonos csomag a SEQN bit vizsgálatával kiszűrhető. HEC mező A fejléc hibaellenőrzésére szolgáló mező (lásd 3.6 fejezet). 3.3.3 Hasznos információt tartalmazó rész 3.3.3.1 Hang információ esetén Hang információ továbbításra fix hosszúságú mező szolgál. HV csomagok esetén ez 240 bit, DV csomagok esetén ez 80 bit. Ezekben az esetekben a csomagok hasznos információt tartalmazó része nem tartalmaz fejlécet. 3.3.3.2 Adat információ esetén Adat információ esetén az adat mező három részből tevődik össze: fejléc, törzs és az opcionális hibajavító kód. 3.3.3.2.1 Fejléc Az adatcsomag hasznos információt tartalmazó részében szereplő fejléc 1 vagy 2 bájt hosszúságú a csomag típusától függően. A fejléc felépítése a 3.8. ábrán látható. LSB 2 1 5 MSB L_CH FLOW Hossz a.) Az 1 időrés hosszúságú csomagok fejléce 14
LSB 2 1 9 4 MSB L_CH FLOW Hossz Meghatározatlan b.) A több időrés hosszúságú csomagok fejléce 3.8 ábra A fejléc logikai csatorna azonosítót, a logikai csatorna vezérléséhez szükséges mezőt valamint a hasznos információ hosszát jelző mezőt tartalmaz. A több időrést használó csomagok fejlécében szerepel továbbá egy 4 bites eddig még definiálatlan mezőt a jövőbeni esetlegesen megvalósítandó funkciók számára. L_CH mező A logikai csatornák feladata, hogy megkülönböztesse a logikai összeköttetést vezérlő és alkalmazó protokoll (Logical Link Controler and Adaptation Protocol, L2CAP) csomagjait az összeköttetés menedzselését végző protokoll (Link Manager Protocol, LMP) csomagjaitól. Egy L2CAP üzenetet több csomagra lehet bontani. Az 10 kódú logikai csatorna jelzi, hogy a csomag egy L2CAP csomag és annak első része. Az elsőt követő további részek a 01 kódú logikai csatornán kerülnek továbbításra. Amennyiben nincs szükség az üzenet több csomagra bontására, akkor minden csomag a 10 kódú logikai csatornán kerül továbbításra (bővebben lásd L2CAP fejezet). Az LMP üzenetek továbbítására az 11 kódú logikai csatorna szolgál. A 00 logikai csatorna a jövőbeni bővítés céljából le van foglalva. FLOW mező A FLOW mező az adatfolyam vezérlésére szolgál az L2CAP számára. Ez az adatfolyam logikai csatornánkénti vezérlését jelenti (FLOW=1 adásra kész, FLOW=0 stop ). A FLOW bit tartalmát az utoljára vett hasznos információ fejrésze határozza meg, valamint vezérléséért a link menedzser (LM) felelős. Ezen lehetőséggel a távoli végről tudjuk a forgalmat irányítani. Az adatfolyam vezérlése csak az L2CAP csomagok vezérlését jelenti, ez a bit LM logikai csatorna esetén mindig 1 értéket vesz fel. Hossz mező A hossz mező a CRC valamint hasznos információ fejléce nélküli azaz a hasznos információ test bájtjainak a számát mutatja meg. 3.3.3.2.2 Hasznos információ test A hasznos információ test tartalmazza a felhasználó által küldött információkat, így ebből illetve ennek a hosszából számítható az effektív bitsebesség is. 3.3.3.2.3 CRC kód generálása Az átvitt csomag hibaellenőrzése 16 bites ciklikus redundancia kóddal történik (lásd 3.6. fejezet). A CRC kód meghatározása előtt a CRC generátort egy 8 bites kezdőértékkel kell feltölteni. Ezen kezdőérték az FHS csomagok esetén a master page válasz állapotban lévő slave UAP címe, illetve az inquiry válasz módban a 15
DCI és minden más csomag esetén a slave egység UAP címe. Ezen inicializálás a vevő oldalon is hasonló képen történik. 3.4 Csomag típusok 3.4.1 Szinkron csomagtípusok A Bluetooth által alkalmazott szinkron csomagtípusokat és azok tulajdonságait a 3.1. táblázat tartalmazza. 3.1. táblázat: szinkron csomag típusok és tulajdonságaik Típus Időtartam tam (időrés) Hasznos információ (byte) FEC CRC Szimmetrikus átviteli sebesség (kb/s) HV1 1 10 1/3 Nincs 64.0 HV2 1 20 2/3 Nincs 64.0 HV3 1 30 Nincs Nincs 64.0 DV 1 10 + (0-9) adat 2/3 D Igen, adat 64.0+57.6 adat 3.4.1.1 HV1 csomag A HV1 csomagokat tipikusan hangátvitelre használják. A csomag 1.25ms beszéd átvitelére alkalmas, minden második időrés felhasználásával. 3.4.1.2 HV2 csomag A csomag 2.5ms beszéd átvitelére alkalmas, minden negyedik időrés felhasználásával. 3.4.1.3 HV3 csomag A csomag 3.75ms beszéd átvitelére alkalmas, minden hatodik időrés felhasználásával. 3.4.1.4 DV csomag A DV típusú csomagok adat és hang információt egyaránt tartalmaznak. A DV csomag felépítését a 3.9. ábra mutatja. A hang valamint adat információk a csomagban elkülönülve helyezkednek el. A hang információ szinkron módon történik, így azon információk hibás átvitel esetén nem kerülnek újraküldésre. Az adat mező bitjei természetesen hibás átvitel esetén újraküldésre kerülnek. LSB 72 54 80 32-150 MSB Access kód Fejléc Hang mező Adat mező 3.9 ábra: a DV csomag felépítése 16
3.4.2 Aszinkron csomagtípusok A Bluetooth által alkalmazott aszinkron csomagtípusokat és azok tulajdonságait a 3.2. táblázat tartalmazza. 3.2. táblázat: aszinkron csomag típusok és tulajdonságaik Típus Időtartam (időrés) Hasznos információ (byte) FEC CRC Szimmetrikus átvite- li sebesség (kb/s) Aszimmetrikus átviteli sebesség ség (kb/s) AUX1 1 0 29 Nincs Nem 185.6 185.6/185.6 DM1 1 0 17 2/3 Igen 108.8 108.8/108.8 DH1 1 0 27 Nincs Igen 172.8 172.8/172.8 DM3 3 0-121 2/3 Igen 258.1 387.2/54.4 DH3 3 0-183 Nincs Igen 390.4 585.6/86.4 DM5 5 0-224 2/3 Igen 286.7 477.8/36.3 DH5 5 0-339 Nincs Igen 433.9 723.2/57.6 3.4.2.1 DM csomag Bármely típusú összeköttetésen belül elsősorban a vezérlő üzenetek továbbítására szolgáló DM csomagtípus felhasználói adatokat is továbbíthat. 3.4.2.2 DH csomag A DH típusú csomagokat nagysebességű adatátvitelre használjuk. 3.4.2.3 AUX1 csomag Ez a csomag hibaellenőrzés nélküli DH1 csomagnak felel meg. 3.4.3 Összeköttetést vezérlő csomagtípusok A Bluetooth által alkalmazott összeköttetéseket vezérlő csomagtípusokat és azok tulajdonságait a 3.3. táblázat tartalmazza. 3.3. táblázat: összeköttetés vezérlő LC csomagtípusok és tulajdonságaik Típus Időtartam (időrés) Access kód Fejléc Hasznos in- formáció (byte) Csomag hossz (bit) FEC CRC ID 1 Igen Nincs - 68 - - NULL 1 Igen Igen - 126 POLL 1 Igen Igen - 126 - - FHS 1 Igen Igen 18 270 2/3 Igen 17
3.4.3.1 ID csomag Ezen csomag tartalma DAC vagy IAC. Ezt a csomag fajtát használják paging, inquiry és a válasz folyamatoknál. 3.4.3.2 NULL csomag NULL csomagot használnak abban az esetben, amikor informálni kell a forrást az előzőleg átvitt csomag nyugtázásáról (ARQN), vagy a vevő puffer állapotáról (FLOW). 3.4.3.3 POLL csomag POLL csomag vétele esetén a slave egységnek egy tetszőleges fajtájú csomaggal kell válaszolnia. Ez a válaszcsomag a POLL csomag nyugtázását jelenti. Ezt a csomagfajtát a master egységek a piconeten belül a többi slave egység lekérdezésére használhatják, amelyeknek válaszcsomagot kell küldenie ha van közölnie való információja. 3.4.3.4 FHS csomag Az FHS csomag felépítését illetve tartalmát a 3.10. ábra mutatja. Ezt a fajta csomagot használják page master válasz, inquiry válasz módban és master-slave szerepcsere esetén. Page master válasz valamint master-slave szerepcsere esetén a csomagok addig kerülnek újraküldésre, amíg nem nyugtázzák őket vagy a nyugtázás egy időkorlátot túl nem lép. Inquiry válasz módban az FHS csomagot nem kell nyugtázni a vételi oldalon. Az FHS csomag valós idejű rendszeróra információkat tartalmaz, amely információk minden újraküldés előtt frissítésre kerülnek. Ezt a fajta csomagot az egységek a frekvencia ugratási sorozathoz való szinkronizációra használjak, mielőtt a piconet csatorna kiosztása megvalósulna vagy amikor egy piconet egy másik piconetté alakulna át. Az utóbbi esetben az AM_ADDR mező a fejlécben csupa nullát tartalmaz, mert a megcímzettnek nem kell érvényes címmel rendelkeznie, annak ellenére hogy az FHS csomag nem broadcast csomag. Az első esetben viszont a slave egységnek már rendelkeznie kell egy AM_ADDR címmel a piconeten belül. LSB 34 24 2 2 2 8 16 24 3 26 3 MSB Paritás bit LAP Határozatlan mező SR SP UAP NAP Class of device 3.10 ábra: az FHS csomag felépítése AM_ADDR CLK27-2 Page Scan mód Paritás bit mező Azon egység access kódjában lévő szinkron szó első része, amely az FHS csomagot küldte. LAP mező Azon egység LAP címe, amely az FHS csomagot küldte. Határozatlan mező 18
tani. SR mező SP mező Ezen két bit a jövőbeni funkciók bővítésére szolgál, célszerű nullának válasz- Scan Repetition mező a scan folyamat ismétlődési periódusát mondja meg. Scan Period mező, amely egy időtartamot határoz meg egy inquiry válasz üzenet adása után a kötelező page scan mód alkalmazásáig. UAP mező NAP mező Azon egység UAP címe, amely az FHS csomagot küldte. Azon egység NAP címe, amely az FHS csomagot küldte. Class of device mező Az FHS csomagot küldő egység Class of device bitjei, még nem definiált. AM_ADDR mező A megcímzett egység AM_ADDR címét tartalmazza összeköttetés kezdeményezés vagy master-slave szerepváltás esetén. Természetesen slave válasza a master egységnek vagy az egység válasza egy inquiry kérésre módokban csak nullát tartalmaz. CLK 27-2 mező Azon egység eredeti rendszer órája, amely az FHS csomagot küldte. Page scan mód mező A page scan mód határozza meg az FHS csomagot küldő egység által alapban értelmezett scan módot. A LAP, UAP és NAP címek együttesen az FHS csomagot küldő egység 48 bites IEEE címét adják. A paritás bit valamint a LAP címből a címzett egység közvetlenül meg tudja határozni az FHS csomagot küldő access kódját. 3.5 Hibajavítás A Bluetooth rendszer 3 darab hibajavítási eljárást használ, melyek a következők: FEC 1/3 FEC 2/3 19
ARQ védelem A FEC hibavédelem célja az újraküldött csomagok számának csökkentése. Ezt a fajta védelmet a Bluetooth csak a csomagok adatinformációit tartalmazó részein használja, a fejlécre külön védelmet biztosít. Egy viszonylag hibamentes környezetben azonban a FEC szükségtelen információtöbblet átvitelét eredményezi, csökkentve ezzel az effektív bitsebességet. A FEC alkalmazását a különböző típusú csomagokban a 3.3. 3.5. táblázatok tartalmazzák. A csomagok fejléce mindig 1/3 FEC hibajavító eljárással kódoltak, mert a fejléc tartalmazza az összeköttetésre vonatkozó összes fontosabb információt valamint vezérlő biteket. Ennek köszönhetően a hibavédelem rendkívüli fontosságú, mert a csomag ezen része nem szenvedhet el hibás biteket az adatátvitel folyamán. 3.5.1 FEC 1/3 Ezt a hibajavító eljárást a Bluetooth a fejlécek valamint a HV1 csomagok hasznos információs részének védelmére használja. Az 1/3 FEC megvalósítását a 3.11. ábra mutatja. A kódolni kívánt bitek háromszor kerülnek ismétlésre, ezáltal az átvitelre kerülő információ háromszorosára nő. b0 b0 b0 b1 b1 b1 b2 b2 b2 3.11 ábra: bit ismétléses eljárás 3.5.2 FEC 2/3 Egy másik hibajavító eljárás a 2/3 FEC, amely (15,10) szisztematikus hamming kódot állít elő. Ezt a kódot a 3.12. ábra shift regiszterekből álló felépítése generálja a következő képen: a) a regiszterek kezdő értékei mind 0 értékűek b) 10 információs bitet az s1 illetve s2 kapcsoló 1 állásában beléptetünk a shift regiszterekbe. Ezzel egyidejűleg a szisztematikus kódnak megfelelően az első 10 karakter kódolás nélkül kerül a kimenetre c) a 10 információs bit kiléptetése után az s1 illetve s2 2 állásba kerül kiléptetve a regiszterekben lévő 5 bites paritást. Ez hozzáfűződik a 10 információs bithez, amely együttesen biztosítja az egyes kódszavak között előírt hamming távolságot (H=5, amely két bit hibajavítását teszi lehetővé) 20
3.12 ábra: 2/3 FEC F előállításához szükséges shift regiszteres elrendezés a 2/3 FEC alkalmazásával 10 információs bitből 15 bites kódszavakat hozunk létre. Ezen kódolást alkalmazva a vevő oldalon képesek vagyunk minden egyszeres valamint minden dupla bithibák hibajavítására, amely a 15 bites kódszóban lép fel. Ez a kódolási eljárás 10 bitenként végzi a kódolást, így a kódolandó információnak is 10 egész számú többszörösének kell lennie. Emiatt előfordulhat, hogy a CRC bitek után nullákkal kell feltölteni az utolsó biteket. A feltöltött biteket a hosszúság mező nem jelzi, így dekódolás után csak el kell hagyni őket. 3.5.3 ARQ védelem A DM, DH valamint a DV csomagok adat mezői addig kerülnek adásra illetve újraadásra ameddig a vevő oldal nem nyugtázza a csomag helyes átvitelét vagy egy bizonyos időkorláton túl nem érkezik nyugtázás. A pozitív illetve negztív nyugtázást a válasz csomag fejléce tartalmazza. Ez mutatja meg, hogy a vevő oldalon a CRC hibaellenőrzés után a csomag vétele sikeres volt vagy nem. Az ARQ védelem csak azon csomagok fejlécében található meg, amelyek tartalmaznak CRC hibaellenőrzést. A csomag fejléce valamint a hangot hordozó információs részek nincsenek ARQ védelemmel ellátva. 3.5.3.1 Számozatlan ARQ A Bluetooth ezt a rendkívül gyors nyugtázási módszert alkalmazza, a megérkezett csomagok negatív illetve pozitív nyugtázására. A csomag helyes vételének jelzése az vételt követő időrésben elküldött válasz csomag ARQN=1 beállításával, míg helytelen vétele az ARQN=0 beállításával történik. A csomag helyes vagy helytelen állapotának megállapításához szükség van a HEC valamint ha a csomag tartalmaz CRC hibaellenőrzést a CRC ellenőrzéséhez. A page, page scan, master-slave szerepváltás illetve park folyamatok következtében létrejött új kapcsolatnál a master egy POLL lekérdező csomagot küld a kapcsolat inicializálására. Ebben a csomagban állítja be a master az ARQN bitet NAK (ARQN=0) állapotba. Ezt a bitet a slave egység változatlanul hagyja. Az ez után következő csomagokra érvényes szabályok a következőkben kerülnek részletezésre. Az ARQ használata csak azon adatcsomagokban fordul elő, amelyek tartalmaznak CRC ellenőrzést vagy hasznos információrész nélküli üres csomagok. CRC helyes vételekor az ARQN bit ACK (pozitív nyugta) állapotba kerül. Bármely időrés amelyben a megcímzett egység nem észlel hozzáférési kódot és a HEC valamint CRC ellenőrzése hibás, akkor ARQN bitet NAK állapotba teszi. Azon vett csomagok, amelyeknek helyes a HEC részük, de más slave egységnek szólnak, vagy a csomagok amelyek nem DH, DM vagy DV típusú csomagok, az ARQN bit állapotát érintetlenül hagyják. Amennyiben egy CRC védett csomagnak 21
helyes a fejléce és ugyanazt a SEQN tartalmazza mint az előzőleg vett ugyanilyen típusú csomag (egy már helyesen megérkezett csomag ismételt vétele), akkor ezen csomagot pozitívan nyugtázzuk (ACK), de a hasznos információs részt eldobjuk a CRC ellenőrzése nélkül. Az FHS csomagoknál az ARQN bitnek nincs jelentősége. Az ARQN bitet az FHS csomagokban nem kötelező ellenőrizni. A Broadcast csomagok csak CRC védelmet alkalmaznak hibaellenőrzés céljából, így ebben az esetben sem kell a csomagot nyugtázni. A HOLD és SNIFF módban lévő inaktív összeköttetéseknél nincs ARQN védelem. Az ezen módból visszatért egységek működésüket ugyanúgy folytatják mintha az előző aktív állapotot folytatnák. 3.5.3.2 Újraküldött csomagok kiszűrése A csomagok hasznos információt tartalmazó része addig kerül újraküldésre, amíg pozitívan nem nyugtázzák. Akkor kerül sor az újraküldésre, ha maga a küldési folyamat meghiúsul vagy ha a nyugtázás nem történik meg. Ekkor a vevő sorra ugyanazon hasznos információt tartalmazó csomagokat kap. Az újraküldések kiszűrését a megcímzett egységben a fejlécben szereplő SEQN bit végzi. Normális esetben az SEQN bit értéke minden egyes új hasznos információt tartalmazó csomagnál invertálódik. Újraküldött csomagok esetén ezen bit értéke érintetlenül marad. Ha a bit értéke az egymást követő csomagokban különbözik, akkor új hasznos információs részt tartalmazó csomag érkezett, ellenkező esetben a csomag már egy előzőleg elküldött csomag megismétlése. Egy page, page scan, master-slave szerepváltás valamint park módból való visszatérés eredményeképpen létrejött új kapcsolat kezdetén a master egy POLL lekérdező csomagot küld a kapcsolat inicializálására. A slave erre egy válasz csomaggal válaszol. Az első CRC hibaellenőrzést tartalmazó adat csomag SEQN bitje mind a master mind a slave oldalon 1 értéket vesz fel. Az ezt követő csomagok SEQN bitjeinek a változása a következő szabályokat követik. Az SEQN bit használata csak azon adatcsomagokban fordul elő, amelyek tartalmaznak CRC hibaellenőrzést. Minden új elküldött csomagban a bit értéke invertálódik. Az újraküldött csomagoknál azonban a bit értéke változatlan marad (az újraküldés addig ismétlődik, amíg a vételi oldalról pozitív nyugta nem érkezett). Minden más csomag amelyben nem alkalmazzuk az újraküldések szűrését, a SEQN bit értéke változatlan marad. Az FHS csomagoknál a SEQN bit értéke nem jelentős, így azok bármely értéket felvehetnek. Az SEQN bitet az FHS csomagokban nem kötelező ellenőrizni. A HOLD és SNIFF módban lévő inaktív összeköttetéseknél az újraküldéseket nem szűrjük. Az ezen módból visszatért egységek működésüket ugyanúgy folytatják mintha az előző aktív állapotba lennének. 3.5.3.3 Hasznos információ kiürítése Az ARQ védelem használata különböző késleltetési időket okozhat az adatfolyamban, mivel a hibamentes átvitelt a csomagok újraküldésével valósítja meg. Bizonyos kommunikációs összeköttetések meghatározott késleltetést engednek csak meg. Ilyen esetekben az újraküldést csak egy meghatározott ideig lehet engedélyezni. Ha nem érkezik pozitív nyugta egy bizonyos idő eltelte után az újrakül- 22
dést abba kell hagyni és az adatátvitelt a következő csomaggal kell folytatni. Ezt izoszinkron forgalomnak nevezzük. Az újraküldött információ elvesztésének eredményeképpen az L2CAP üzenet maradék része elveszik. Ezért a soron következő csomag egy új L2CAP üzenet eleje lesz (L_CH=10). Ez informálja a vevő oldalt az információ kiürítéséről. 3.5.3.4 Több slave egység figyelembevétele Több slave egységből felépülő piconetben az ARQ védelem minden slave számára függetlenül történik. 3.5.3.5 Broadcast csomagok A broadcast csomagokat a master egység küldi, és minden slave veszi. Ezen csomagok megkülönböztetésére a Bluetooth a csupa nullás AM_ADDR címet használja (ezenkívül csak az FHS csomag használhatja ezt a címet). A broadcast üzenetek több csomagból állnak és nem kerülnek nyugtázásra (legalábbis nem LC szinten), ezért minden egyes broadcast csomag NBC-szer ismétlődik (lásd 3.13. ábra), így a piconetben szereplő összes slave biztosan megkapja azokat. 3.13 ábra: broadcast csomagok ismétlése A CRC hibaellenőrzést tartalmazó broadcast csomagok saját ARQ védelmet használnak. Az ilyen csomagban az SEQN bit kezdőértéke 1 és az üzeneten belül minden egyes új CRC hibaellenőrzést tartalmazó csomagnál értéke invertálódik. A CRC nélküli csomagokat ez a folyamat nem érinti. A slave veszi a broadcast üzenet első csomagjának SEQN bitjét és a következő csomagot számára a SEQN bit értékének változása jelzi, így az Nbc-szer ismételt azonos broadcast csomagok könnyedén kiszűrhetők. Mivel a broadcast üzenetek nem kerülnek nyugtázásra valamint az üzenet utolsó csomagját sem jelzi semmi, ezért rendkívül fontos az üzenet első csomagjának helyes vétele. Ekkor a hasznos információ szűrését nem célszerű használni. 3.6 Hibaellenőrzés A vett csomagokban fellépő hibákat az access kód, a fejlécben lévő HEC valamint a hasznos információt tartalmazó rész CRC hibaellenőrző összeg segítségével ellenőrizhetjük. A csomag vételekor először az access kód kerül ellenőrzésre. Mivel az ebben szereplő 64 bites szinkron szó a 24 bites master LAP címéből származik, így a más piconetek által küldött csomagok ebben a fázisban kerülnek kiszűrésre. 23
A HEC és a CRC a hibák valamint a rossz cím ellenőrzésére szolgál. Az cím mező 8 bittel való megnövelésével a UAP ellenőrzése is megtörténik a HEC és CRC ellenőrzésékor. Előfordulhat ugyanis, hogy különböző csomagok ugyanazzal az access kóddal rendelkeznek ez akkor fordulhat elő, amikor két egységnek megegyezik a LAP címe, de az UAP címe már különböző- amit az access kód tesztelése nem tud kimutatni. A HEC és CRC generálását valamint ellenőrzését a 3.14-3.17. ábra mutatja be. Természetesen a HEC és CRC kiszámításánál az azt előállító shift regiszteres elrendezést egy előre meghatározott kezdőértékkel kell ellátni. Ez a kezdőérték az inquiry válasz módban lévő egységek esetén a DCI (DCI értéke 0x00 hexadecimal), ellenkező esetben a 8 bites UAP értéke. 3.14 ábra: a HEC generálása (a generátor polinom: g(d)=d8+ D7+ D D5+ D D2+ D D+1 ) A HEC generálásánál az adatot az S kapcsoló 1 állásában beléptetjük, majd az utolsó bit beléptetése után az S kapcsoló 2 állásában a HEC értékét a regiszterből kiolvassuk. A vevő oldalon ugyanezen polinom és kezdőérték segítségével történik az ellenőrizés. Adó egység 8 bit UAP HEC generátor 10 bit fejléc 8 bit HEC 8 bit UAP Vevő egység HEC generátor 3.15 ábra: HEC ellenőrzése és generálása helyes vétel esetén a maradék 0 A 16 bites CRC generálása is hasonló képen történik, azonban az itt alkalmazott generátor polinom és a regiszterek kezdőértéke más. A regiszter kezdőértékének első nyolc bitje az UAP, míg a többi bit nulla értékű. 3.16 ábra: a CRC generálása (a generátor polinom: g(d)=d16 16+ + D + D12 12+ D + D5+ D 1 ) 24
Adó egység 8 bit UAP, 8 bit bővítés CRC generátor Ez a logikai csatorna alacsony szintű vezérlő információkat tartalmaz a csomag fejlécében. Itt valósul meg az ARQ védelem, az adatfolyam vezérlés és a hasznos információs rész tulajdonságainak definiálása. Az LC logikai csatorna minden csomagban jelen van, kivéve az ID csomagot, mert az nem tartalmaz fejlé- adat 16 bit CRC 8 bit UAP, 8 bit bővítés Vevő egység CRC generátor helyes vétel esetén a maradék 0 3.17 ábra: CRC ellenőrzése és generálása 3.7 Logikai csatornák A Bluetooth rendszer 5 logikai csatornát definiál: Összeköttetés vezérlő (LC) csatorna Összeköttetés menedzselését végző (LM) csatorna Felhasználói aszinkron (UA) csatorna Felhasználói isochronous (UI) csatorna Felhasználói szinkron (US) csatorna Az LC és LM logikai csatornákat az összeköttetés vezérléséért (LC) valamint az összeköttetés menedzseléséért (LM) felelős hálózati szint használja. A felhasználói UA, UI és US logikai csatornákat az aszinkron, izoszinkron valamint szinkron adatátvitelnél alkalmazzuk. Az LC logikai csatorna a csomagok fejlécében, míg a többi logikai csatorna a csomagok hasznos információt hordozó részében valósul meg. A hasznos információ fejlécének L_CH mezőjében az LM, UA és UI logikai csatornákat különböztetünk meg. Az US logikai csatorna csak a szinkron, az UA és UI logikai csatorna az aszinkron összeköttetéseknél valósulhat meg. Az LM logikai csatorna szinkron és aszinkron összeköttetéseknél egyaránt alkalmazható. 3.7.1 LC logikai csatorna 25
cet. 3.7.2 LM logikai csatorna Az összeköttetés működéséhez szükséges vezérlő információkat hordoz a master valamint slave egységek között. Az LM logikai csatorna védett DM csomagokat használ, és a csatorna L_CH azonosítója 11. 3.7.3 UA/UI logikai csatorna Az UA csatorna L2CAP aszinkron felhasználói adatokat tartalmaz. Ezek az alapsávi csomagok méretét meghaladhatják. Ilyen esetekben az adatot alapsávi csomagok méretére kell szétválasztani. Az így szétválasztott információ első csomagját az 10 kódú L_CH csatornán (lásd hasznos információs rész fejléce) küldjük el. A fennmaradó többi csomag, ha van ilyen, a 01 kódú L_CH csatornát használják. Az UI csatorna megvalósításához szükséges időzítések vezérlését a felsőbb rétegek protokolljai végzik. Működése megegyezik az UA csatornánál leírtakkal. 3.7.4 US logikai csatorna Ez a logikai csatorna átlátszó felhasználói adatokat tartalmaz, a szinkron összeköttetésekben. A magasabb prioritású információt hordozó LM, UA és UI logikai csatornák megszakíthatják az US logikai csatornát. 3.8 Adat fehérítés (data whitening) A csomag adása előtt a fejlécen valamint a hasznos információs részen adat fehérítést végzünk. Ennek a műveletnek a célja a redundáns információk véletlenszerű adattá tétele és a direkt komponens csökkentése a csomagon belül. A folyamat a FEC megvalósítása után történik. A vételi oldalon az érkezett adatokat azonos kódszóval dekódolhatjuk a FEC dekódolása után. Az adatfehérítés folyamatát a 3.18. ábra mutatja. 3.18 ábra: az adat fehérítés folyamata A folyamat megvalósítása shift regiszterek segítségével történik. A fehérítést a g(d)=d7+d4+1 polinommal előállított bináris kódszó és a fejléc majd az azt követő hasznos információs rész kizáró vagy kapcsolatával végezzük el. Minden egyes adásnál a shift regiszterek kezdőértékét a master egység rend- 26
szerórájának alsó bitjei adják. Ez alól azonban vannak kivételek. A rendszer más kezdőértékeket használ az inquiry vagy page válasz módban lévő egységek esetén. A regiszterek kezdőértékének újabb beállítása a csomag fejléce és az információs rész kódolása után történik. 3.9 Adatfolyam vezérlése Mivel a vevő oldali aszinkron adatátvitelnél használt puffer új csomag érkezésekor megtelhet, az adatfolyam vezérlésére van szükség. Új csomag adásának engedélyezését illetve tiltását a fejlécben lévő FLOW mező segítségével szabályozhatjuk. 3.9.1 Vevő oldali vezérlés Amíg a vevő nem képes új csomag fogadására, azt a FLOW mező stop állapota jelzi a forrás számára. Ilyen esetekben az összeköttetés vezérlő (LC) automatikusan a válasz csomag fejlécében jelzi azt a csomagot feladó egységnek. A vevő oldali puffer kiürítését az összeköttetés menedzser végzi. Kiürítés után a vevő újra képes csomagot fogadni, amit a FLOW mezőben elhelyezett mehet üzenettel jelez. Alapértelmezésben a FLOW mező mehet értéket vesz fel. 3.9.2 Forrás oldali vezérlés A vevő oldalon stop üzenet érkezésekor az összeköttetés vezérlő alapértelmezett csomagokat küld a vevő számára. Ezzel egyidejűleg a következőnek elküldendő adatot az adó pufferbe tartja mindaddig, amíg a vételi oldal nem képes azt fogadni. A vevőtől érkező mehet üzenet hatására az adatátvitel a megszakított csomag adásával folytatódik. A stop üzenetekre adott alapértelmezett csomagok az összeköttetésre vonatkozó vezérlő információkat és esetlegesen HV csomagokat tartalmaznak. Multi-slave konfiguráció esetén csak a stop jelzést küldő slave felé irányuló forgalom áll le, így az előzőleg leírt rutin csak az adott slave egységhez tartozó adó puffert érinti. 3.10 Bitfolyam feldolgozása Mielőtt a felhasználói információ a fizikai csatornára kerülne, az adó az átvitelre szánt biteken néhány módosítást végez az adatátvitel megbízhatóságának és védelemének növelése érdekében. 3.10.1 A fejléc feldolgozása A csomag fejléce a fizikai csatornára kerülés előtt előfeldolgozáson megy keresztül, ahogy azt a 3.19. ábra mutatja. A csupasz fejléc hibaellenőrző összeget kap, adatfehérítésen megy keresztül majd hibajavító kódolást teszünk rá. A vevő oldal az érkezett adatokat dekódolja és elvégzi rajtuk a hibaellenőrzést. Az így visszanyert információ kerül feldolgozásra. 27
Fejléc HEC generálása adat fehérítés FEC kódolás RF interfész Fejléc HEC ellenőrzés adat dekódolás FEC dekódolás 3.19 ábra a fejléc feldolgozásának folyamata f az adó illetve vevő oldalon 3.10.2 A hasznos információs rész feldolgozása A hasznos információ is hasonló feldolgozáson megy keresztül, ahogy azt a 3.20. ábra mutatja. A szaggatott vonallal jelzett adatfeldolgozási folyamatok a csomag típusától függően szerepelnek vagy nem szerepelnek a feldolgozási folyamat során. Hasznos CRC ellenőrzés informá- Hasznos informáó CRC generálása titkosítás titkosítás dekódolás adat fehérítés adat dekódolás 3.20 ábra: a hasznos információ feldolgozásának folyamata az adó illetve vevő oldalon Ezek e folyamatok a CRC hibaellenőrző összeg generálása és ellenőrzése valamint a titkosítás és kódolás dekódolás. Egyedül az adat fehérítési folyamat kötelező minden hasznos információt tartalmazó rész számára. 3.11 Bluetooth eszközök működési állapotai kódolás dekódolás RF interfész Ezen fejezet a master és slave időzítési tulajdonságait és az egységek lehetséges működési állapotait mutatja be. Az időzítések tulajdonságai szorosan összefüggenek a Bluetooth egység működési állapotától, így ezek együtt kerülnek bemutatásra. 3.11.1 Master/Slave időszinkronizálás A piconeten belül a szinkronizáció a master rendszerórájához képest történik, ami a piconet létezése alatt 1 másodperc alatt 1600 -szor változik. A slave egységek rendszerórája egy idő ofszetet eltekintve a master órájával azonos. Erre az ofszet időzítésre azért van szükség, hogy a master egységtől bizonyos távolságra lévő egységek a master rendszerórájához képest azonos időzítéssel végezzék el az adást. Ezt az ofszet időzítést az egységek a master időrésekben kapott minden egyes csomag vételekor frissítik. A frissítéshez nem szükséges az adott slave egységet megcímezni, mert a csatorna access kód elegendő az új ofszet megállapítására. 28
ACL összeköttetések esetén az ofszet megállapítására az adás előtti masterslave időrésben érkező csomag szolgál. SCO összeköttetések esetén az ofszet magállapítására a néhány időréssel az adás előtti master időrésben küldött csomag szolgál, mert szinkron adatátvitelnél az adás előtti időrésben a master nem biztos, hogy küld csomagot. 3.11.2 CONNECTION állapot Az összeköttetés állapotában az Bluetooth adó-vevő egység időrésenként felváltva végzi a csomagok adását illetve vételét, ahogy azt a 3.21. ábra mutatja. 3.21 ábra: master egység RX/TX ciklusa normál módban, 1 időrést használó csomagok esee- tén A hasznos információ rész hosszúságától függően a csomagok mérete maximálisan 366µs lehet. A vétel valamint az adás különböző frekvenciákon történik. Multi-slot csomagok esetén a csomagok terjedelme több időrés lehet, de ezen esetben a csomag teljes átvitelének ideje alatt az egység azonos frekvencián ad illetve vesz. 3.22 ábra: slave egység adó-vevő RX/TX ciklusa normál módban, 1 időrést használó csoma- gok esetén Az ábrákon az időrések egymás utáni soron következő frekvenciáit a g(m) függvény határozza meg. Normál működési módban az időrések kezdete nem kötött kivétel a master adás üzemmódját, tehát a venni kívánt adat ±10 µs -al az időrés kezdete előtt vagy után is érkezhet. A vevőben lévő korrelátornak ebben a biztonsági sávban is működnie kell a megfelelő csatorna access kódot keresve. Ha a 29
vevő egység nem érzékel neki szóló csatorna access kódot az érkezett csomagban, akkor a következő RX időrésig pihen. 3.11.3 STANDBY állapot A STANDBY állapot a Bluetooth egység alapértelmezett állapota. Ebben az állapotban az egység kis fogyasztású módban van, csak a rendszeróra működik. 3.11.4 Visszatérés HOLD állapotból CONNECTION állapoton belül a Bluetooth egység HOLD állapotban lehet. Ebben a módban az adó-vevő nem ad és nem is vesz információt. Amikor a slave egység ezen állapotából normál működési módba tér vissza, az információ küldés előtt a master adás időrésében küldött információt kell figyelnie. Ennek következtében a már említett biztonsági sáv 20µs -ról nagyobb értékre változhat, ahogy azt a 3.23. ábra mutatja. Master TX időrésének becsült kezdete 3.23 ábra: HOLD módból visszatérő slave egység vételi időzítése Természetesen a HOLD módból visszatérő egységeknek csak az RX időrésekhez használt frekvencián kell a biztonsági sávot kiterjeszteni, mert a master csak ezen a frekvencián ad. 3.11.5 Felébredés PARK módból A PARK mód a HOLD állapothoz hasonló. A lényegi különbség abból adódik, hogy periódikus időközönként a PARK állapotban lévő egységnek fel kell kelnie és a master rendszerórájához kell szinkronizálnia. A felébredésnél a biztonsági sáv kiszélesedik (lásd 3.23. ábra) a gyorsabb szinkronizáció elősegítése érdekében. 3.11.6 PAGE állapot PAGE állapotban, a master ID csomagokat küld ami csak a készülék access kódját tartalmazza annak a slave egységnek, amelyikkel kapcsolatot akar létesíteni. Ezeket a csomagokat a master több frekvencián is elküldi egymás után. Mivel az ID típusú csomagok rendkívül rövidek, így azok 3200 ID csomag/másodperc sebességgel továbbíthatók. 30
3.24 ábra: Bluetooth adó-vevő RX/TX ciklusa PAGE módban Ennek következtében a PAGE állapotban lévő master egy TX időrésében 2 különböző frekvencián küld ID csomagot, míg az RX időrésben két különböző frekvencián várja a megszólított egység válaszát (lásd 3.24. ábra). Természetesen a válasz csomag fogadásánál is figyelembe kell venni egy biztonsági sávot, ahogy azt a 3.24. ábra is mutatja. Az ábrán szereplő f(k) a page folyamat, míg az f (k) a page folyamatra adott válasz frekvencia ugratási sorozatát meghatározó függvény. 3.11.7 Az FHS csomag A kapcsolat felépítéséhez és a master-slave szerepváltáshoz a master egységek FHS csomagot alkalmaznak. Ez a csomagfajta az időzítéseket és a frekvencia szinkronitást állítja be. A teljes folyamatot a 3.25. ábrán kísérhetjük figyelemmel. Miután a slave egység vette a master-to-slave időrésben elsőnek küldött page üzenetet az f(k) frekvencián, egy ID csomaggal válaszol 625 µs elteltével az f (k) frekvencián. Két időréssel a slave által elsőként vett paging üzenet után (1250 µs) a master egy FHS csomagot küld a f(k)-t követő f(k+1) frekvencián. Az f(k+1) frekvencián a másodikként vett page üzenetre a slave 625µs eltelte után szintén egy ID csomaggal válaszol az f (k+1) frekvencián, és ezt ismét a választ követő master-to-slave időrésben egy FHS csomag követi az f(k+1) frekvencián. A slave egység az FHS csomag vétele után beállítja a szükséges időzítéseket. Az FHS csomagot követő időrésben a slave egy ID csomaggal nyugtázza a master felé annak vételét, valamint a szinkronizáció sikerességét. 31
3.25 ábra: FHS csomag időzítése sikeres page folyamat esetén 3.11.8 Multi-slave működés A piconeten belül a master és a slave időrésenként felváltva kommunikál, a master a páros illetve a slave a páratlan számozású időrésekben, ahogy azt az 1.ábra mutatja. Multi-slave működés esetén az a slave adhat, amelyet előzőleg a master egység az AM_ADDR címe alapján megcímzett. Abban az esetben ha a vett AM_ADDR cím nem érvényes, a slave csak akkor adhat, amennyiben az egy számára fenntartott szinkron (SCO) időrés volt. Broadcast üzenetek esetén, a slave egységek közül egy sem küldhet csomagot. Ilyen esetben azonban egy kivétel a park módban lévő egységek csatorna hozzáférési kérelme. A multi-slave működés a 32
3.26. ábrán látható. 3.26 ábra: RX/TX R időzítés multi-slave működés esetén 3.12 Csatorna vezérlése Ezen fejezetben kerül bemutatásra a piconet csatorna létrehozásának, új egység piconetbe való felvételének és elbocsátásának folyamata. Ismertetésre kerül továbbá ezen funkciókat megvalósító néhány működési mód, a scatternetek felépítése és működése, valamint a Bluetooth belső órája, ami döntő szerepet játszik az FH szinkronizációban. 3.12.1 Master-slave definició A piconethez tartozó fizikai csatornát a piconet master egysége által lehet jellemezni. A master Bluetooth eszköz címe (BD_ADDR) a csatorna hozzáféréshez szükséges access kódot valamint az FH frekvencia ugratási sorozatot, és a rendszerórája az ugratási frekvencia fázisát és időzítését határozza meg. A master egység vezérli továbbá a csatorna forgalmát is a lekérdezéses (pollling) módszer alapján (lásd 3.11. fejezet). Definíció szerint a master az a Bluetooth egység amely az összeköttetést kezdeményez egy vagy több slave egységgel. A master valamint slave elnevezés csak az egység csatorna hozzáférési protokolljára utal, bármely egység a piconetet vezérlő master egységgé válhat. 33
3.12.2 Bluetooth rendszerórája Minden Bluetooth egységnek van egy belső rendszerórája, ami meghatározza az időzítéseket valamint az adó-vevő frekvenciaugratási sorozatot. Ez nem más mint egy szabadon futó órajel, amely megállás nélkül működik. Más egységekkel való szinkronizáció esetén, az összes egységnek a master rendszerórájához kell állítania az időzítéseit. Ezt úgy történik, hogy a saját órájukhoz képesti mindig frissített ofszettel adnak illetve vesznek mert a master órajele szabadonfutó, illetve meghatározott pontosságú, ahogy azt a 3.27. ábra mutatja. CLK(master) + CLK CLK(slave) + CLK 0 offset (a) (b) 3.27 ábra: időzítés származtatása a master valamint slave egységekben A Bluetooth rendszeróráját egy 28 bites számlálóval jellemezhetjük, melynek felbontása egy időrésnek a fele azaz 312,5 µs (3,2kHz). A számláló kezdőértéke bármely értéket felvehet. 3.28 ábra: Bluetooth rendszerórája A Bluetooth vevő fontosabb időzítéseit valamint a rendszer órát a 3.28. ábra mutatja. A master-to-slave időrés kezdetét a CLK0=0 és CLK1=0, a slave-to-master időrés kezdetét a CLK0=0 és CLK1=1 értéke jelzi. 3.12.3 Csatorna hozzáférési eljárás Egy újkapcsolat felépítéséhez az inquiry és paging folyamatok szükségesek. Az inquiry folyamat lehetővé teszi az egységek számára, hogy felderítse a hatótávolságán belül elhelyezkedő más Bluetooth egység eszköz címeit és rendszerórájukat. A paging eljárással egy konkrét összeköttetés hozható létre. Egy kapcsolat létesítéséhez csak a Bluetooth eszköz címére (BD_ADDR) van 34
szükség. A rendszer óra ismerete csak a beállítási folyamatokat gyorsítja meg. A kapcsolatot létesítő egység válik a kapcsolatot irányító master egységgé. A paging valamint inquiry folyamatokban az eszköz access kódját (DAC) illetve a inquiry access kódot (IAC) használja a rendszer. Ebben a fejezetben a kötelező paging séma kerül bemutatásra. Létezik néhány opcionális paging séma is [1], de ezeket a megoldásokat a különböző gyártmányú Bluetooth egységeknek nem kötelező támogatni. 3.12.3.1 Page scan folyamat Page scan állapotban a egységek a saját eszköz azonosító kódjukat figyelik egy előre definiált időintervallumon belül (Tw page scan). Ezen időtartam alatt a page scan állapotban lévő egység csak egy csatornán figyeli az esetlegesen neki szóló azonosító kódot. Ennek az időintervallumnak legalább 16 page üzenetnek megfelelő hosszúnak kell lennie. Mikor a Bluetooth egység page scan állapotba lép, egy scan frekvenciát választ, ahol az esetlegesen neki érkező page üzenetet figyeli. Ezt a frekvenciát a már előzőekben említett f(k) sorozat valamelyik tagja közül választja ki, amely f(k) függvényt az egység BD_ADDR címe határozz meg. Ez az f(k) függvény a 79 (23) csatornát használó rendszerekben 32 (16)különböző frekvenciát használ a page üzenetek valamint válaszüzenetek küldésére. Az ugratási sorozat fázisát az egység rendszerórájának CLK16-12 bitjei határozzák meg 23 csatornát alkalmazó rendszerekben a CLK15-12 bitek -, ami 1,28 másodpercenként változtatja meg a scan figyelés frekvenciáját. A page scan állapotban page üzenetet vevő egység slave response állapotba kerül. A scan intervallum Tpagescan két egymást követő page scan kezdetei között eltelt idő. Ez megegyezhet a Twpagescan (folyamatos scan) idővel, vagy 1,28 illetve 2,56 másodpercben lehet maximálva. a scan időtartamra vonatkozó információkat az FHS csomagok SR mezője határozza meg. 3.12.3.2 Page folyamat A PAGE állapotot a master egységek arra a célra használják, hogy kapcsolatot hozzanak létre egy page scan állapotban lévő (slave) egységgel. A master a slave eszköz access kódját (DAC) különböző frekvencián kisugározva próbálja fel- 35
építeni vele a kapcsolatot. Erre azért van szükség, mert a master valamint slave egység rendszerórája a page folyamat elején még nem szinkronban működik, így a master nem tudja, hogy a megszólított egység (slave) melyik frekvencián küldött csomagra fog válaszolni. A page folyamatot kezdeményező master addig folytatja a DAC adását, amíg a megcímzet egységtől válasz nem érkezik. A master egységben lezajló page folyamat lépések sorozatából áll. Elsőként a master meghatározza a slave eszköz címét. Erre azért van szükség, hogy a master megismerje a slave page frekvencia ugratási sorozatát, így a már ismert frekvenciákat használva bármikor el tudja érni azt. A master ekkor ismeri a slave frekvenciaugratási sorozatát, de ez nem jelenti azt, hogy egy fázisban is van vele. Ezért a master rövid page üzeneteket küld a slave egységnek azon frekvenciákon ahol azokat a slave fogadni tudja. Minden TX időrésben a page üzenetek egymás után két különböző frekvencián kerülnek adásra, ahogy az FHS csomagnál megismertük (lásd 3.25. ábra). Ez azért lehetséges, mert a page üzenetet hordozó ID csomagok 68 bit hosszúságúak, így az adó szintézerének 224,5µs elegendő a második frekvencia befogására és még egy ID csomag elküldésére egy időrésen belül. Az ezt követő RX időrésben a master két meghatározott frekvencián amit a page válasz ugratási sorozat határoz meg és szoros összefüggésben van a page frekvencia ugratási sorozattal - a slave egységtől érkező válasz ID csomagot várja. Tehát a Bluetooth minden egyes page frekvencián küldött üzenethez meghatározza a page response üzenet frekvenciáját is. A válasz üzenet megérkezése után a master master válasz állapotba kerül, és a következő TX időrésben a FHS csomagot küld 2 különböző frekvencián (3.25. ábra). A page állapotból történő lehetséges állapotátmeneteket a 3.28. ábra mutatja. 3.12.3.3 Page response folyamat Miután a slave egység sikeresen vette a neki szoló page üzenetet, megtörténik a két egység közötti FH szinkronizáció. Mindketten válasz állapotba kerülnek, és az összeköttetés létrehozása céljából információkat cserélnek egymással. A piconet kialakításánál nagyon fontos, hogy minden egység ugyanazt a csatorna hozzáférési kódot és ugyanazt a frekvencia ugratási sorozatot használja a csatorna elérésénél, és természetesen a rendszerórájuknak is szinkronban kell működniük egymáshoz képest. Ezek a paraméterek a master egységtől a master indítja a page folyamatot származnak és a piconet létezéséig meg is maradnak. A csatorna 36
hozzáférési kódot valamint a csatorna frekvencia ugratási sorozatát a rendszer a master Bluetooth eszköz címéből származtatja. További időzítéseket is a master határozza meg. 3.12.4 Inquiry folyamat A Bluetooth az inquiry (feltérképezési) eljárást az eszköz hatótávolságán belül elhelyezkedő általa ismeretlen eszköz-címmel rendelkező más egységek felderítésére használja. Az inquiry módban lévő Bluetooth egységek információt gyűjtenek az inquiry üzenetre válaszoló egységekről. Ezen információk a Bluetooth eszköz címe és rendszerórája. Ezt követően, ha szükséges a felderített egységekkel a feltérképezést végző kapcsolatot teremthet egy page folyamat eredménye képen. A forrás által küldött inquiry üzenet semmiféle információt nem tartalmaz magáról a forrásról. A rendszer egy általános inquiry access kódot (GIAC) és egy dedikált access kódot (DIAC) használ az inquiry folyamatok során. A DIAC egy meghatározott típusú eszköz felderítésére szolgál. Az inquiry access kód is mint minden fontosabb jellemző az eszköz Bluetooth címéből származik. Azok az egységek amelyek fel akarnak deríteni más Bluetooth egységeket, inquiry állapotba kerülnek, majd itt folyamatosan ID csomagokat küldenek különböző frekvenciákon. Az inquiry állapotban lévő egységek frekvencia ugratási sorozatát a GIAC vagy DIAC LAP címe határozza meg. Természetesen csak az inquiry scan módban lévő egységeket lehet feltérképezni az inquiry eljárás folyamán. 3.12.4.1 Inquiry scan Az Inquiry scan állapot nagyon hasonló a page scan állapothoz. Természetesen ebben az állapotban az eszköz access kód csatornán való megjelenésének figyelése helyett az inquiry access kódot figyeli. Az inquiry scan időtartamának (Tw inquiry scan) legalább 16 inquiry üzenetnek megfelelő hosszúságúnak kell lennie. Ezen időtartam alatt az inquiry scan állapotban lévő egységek csak egy csatornán figyelik az esetlegesen nekik szóló azonosító kódot. Ugyanúgy mint a page eljárás folyamán, az inquiry eljárás is 32 dedikált frekvenciát használ (23 frekvenciát használó rendszerek esetén ez 16). Ezen frekvenciák közötti frekvencia ugratási sorozatát az általános inquiry cím, fázisát az inquiry scan módban lévő egység rendszer órája határozza meg. A fázis 1,28 má- 37
sodpercenként változik (lásd 3.28. ábra). Ezen állapotban lévő egységek képesek egyszerre egy vagy több dedikált inquiry access kód figyelésére is. Inquiry üzenet vétele esetén a Bluetooth egység inquiry válasz állapotba kerül. Szinkron összeköttetést nem célszerű az inquiry scan állapottal megszakítani, de az inquiry scan állapotnál magasabb prioritású szinkron időrések megszakíthatják az inquiry scan folyamatot. A scan intervallum Tinquiry scan két egymást követő inquiry scan kezdete között eltelt idő. Ez az inquiry scan intervallum legfeljebb 2,56 másodperc ideig tarthat. 3.12.4.2 Inquiry Inquiry állapotba azok az egységek kerülnek, amelyek új eszközöket akarnak felderíteni a hatótávolságukon belül. Ez az állapot nagyon hasonlít a page állapothoz. Mindkét állapot ugyanazt az RX/TX időzítést alkalmazza, ahogy azt a 26.ábra is mutatja. Az inquiry állapot RX illetve TX frekvenciáit az inquiry valamint az inquiry válasz frekvenciaugratási sorozatot szabályozza. Ezt a sorozatot a felfedezést végző egység rendszerórája és access kódja határozza meg. Az inquiry üzenetek között az eszköz válasz üzenetet vár a hatótávolságon belül elhelyezkedő egységektől. A válasz üzenet nem más mint egy FHS csomag. A lényegi különbség a page valamint inquiry folyamatok között, hogy az inquiry állapotban kiadott üzenetekre nem történik inquiry váálasz üzenet. Az inquiry üzenetek küldése illetve a válaszok figyelése az ezen állapotban lévő eszközök teljes ideje alatt folytatódik. Ebben az állapotban lévő egységek célja, hogy az összes hatótávolságon belül elhelyezkedő egységről információt szerezzen. Ehhez legalább 10,24 másodperc ideig kell tartania a felderítési folyamatnak. Természetesen a folyamat elegendő válasz üzenet vétele esetén a felderítést végző egység által megszakítható. Megszakítható továbbá a folyamat egy magasabb prioritású szinkron adatátvitel esetén is. Lehetőség van a felderítési idő meghosszabítására is abból a célból, hogy a lehető legtöbb egység létezéséről szerezzünk információt. A folyamat meghosszabítását illetve megszakítását az összeköttetés menedzser dönti el az érkezett válaszüzenetek számának függvényében. Az inquiry állapotból történő lehetséges állapotátmeneteket a 3.30. ábra mutatja. 3.12.4.3 Inquiry válasz A master egység az inquiry üzenetek között válaszra várva figyeli a csator- 38
nát. Válasz érkezése után újabb inquiry üzenetekkel folyatatja az adást. Amikor az inquiry scan állapotban lévő egységek inquiry üzenetet vesznek, egy hagyományos FHS csomaggal válaszolnak rá. Ezen FHS csomag tartalmazza az egység paramétereit. Előfordulhat, hogy a feltérképezést végző egység közvetlen közelében lévő összes eszköz egyidőben válaszol az inquiry üzenetre. Ennek az esélye azonban rendkívül csekély, mivel minden egységnek az inquiry frekvenciaugratási sorozat ugyanazon fázisában kell lennie. Az inquiry válasz módban lévő egységek közötti ütközések elkerülésére a következő protokollt használják: ha a slave egy inquiry üzenetet vesz, akkor egy véletlen számot sorsol 0 és 1023 között ezután véletlen számnyi időrés elteltéig az inquiry frekvenciaugratási sorozat megáll a sorsolás előtti fázisban. Ezen időtartam alatt a slave visszatér CONNECTION vagy STANDBY állapotba. a kisorsolt idő letelte előtt az egység visszatér inquiry response módba, majd az azt követő első slave-to-master időrésben egy FHS csomagot küld az őt megszólító master számára és frekvencia ugratási sorozat fázisát megnöveli (a sorozat fázisa alap állapotban 1,28 másodpercenként változik) az egység unquiry scan állapotba lép be Egy nagyobb prioritású szinkron adatátvitel esetén az FHS csomag küldése megszakítható. 3.12.5 CONNECTION állapot CONNECTION állapotban az összeköttetés már megvalósult, és a csatornán a már említett szabályok alapján folyik a forgalom. A CONNECTION állapot kezdetén a master egy POLL csomagot küld, hogy hitelesítse az időzítést és a frekvenciaugratási sorozatot. A slave egység erre az üzenetre bármilyen csomaggal válaszolhat. Amennyiben a slave nem veszi a POLL vagy a master a válaszcsomagot, mindkét egység PAGE, pagescan állapotba kerül. A CONNECTION állapotban küldött első információs csomagok vezérlő üze- 39
neteket tartalmaznak, amely az összeköttetést jellemzi és a Bluetooth egységekre vonatkozó információkat tartalmazza. Például ezen csomagokban definiálják a szinkron összeköttetést és a sniff paramétereket (lásd 4.fejezet). Ezután történik a felhasználói információ átvitele a TDD elv szerint. A CONNECTION állapotból a detach vagy reset parancs segítségével lehet kilépni. Detach parancsot a kapcsolat normális leépítésénél használjuk. Ilyenkor az összes konfigurációs adat a Bluetooth összeköttetés vezérlő egységében még érvényes marad. A reset parancs az összes vezérlő folyamat törlését jelenti. Reset parancs után a vezérlőt újra kell konfigurálni. A CONNECTION állapotban lévő Bluetooth egységek a következő módokban működhetnek: aktív, sniff, hold és park mód. 3.12.5.1 Aktív mód Aktív módban lévő Bluetooth egységek vesznek részt a csatornán lévő forgalom lebonyolításában. A forgalom nagyságának a függvényében a master egység végzi annak irányítását és ütemezését. A master végzi továbbá a közös csatornán osztozó slave egységek szinkronizációját is. Az aktív slave figyeli a csatornán zajló forgalmat és a master-to-slave időrésekben neki címzett csomagokat. A meg nem címzett többi slave ez idő alatt a következő master-to-slave időrés kezdetéig pihen. A master által küldött minden egyes csomag az egységek szinkronizálását is elvégzi (lásd 3.3. fejezet). 3.12.5.2 HOLD mód A HOLD módban lévő slave egységek ideiglenesen nem fogadnak aszinkron csomagokat (elképzelhető, hogy szinkron adatátvitelt valósítanak meg ezen idő alatt). Ezzel viszonylag nagyobb kapacitás válik elérhetővé az egység számára, amit más dolgok elvégzésére használhat (mint például a scanning, page, inquiry vagy más piconetekben való részvétel). Természetesen az ezen módban lévő egységek megtartják az aktív eszköz címüket (AM_ADDR). A HOLD módban tartózkodás idejét a master valamint slave egység egyezteti egymással, és annak lejártakor a slave egységnek a csatornán zajló forgalomhoz kell szinkronizálnia majd várni a master további utasításaira. 40
3.12.5.3 Sniff mód A sniff módban lévő egységek minimálisra csökkentik a csatornafigyelési aktivitásukat. Például az aszinkron összeköttetést létesítő slave csak az átvitelre előre lefoglalt időrésekben figyeli a csatorna forgalmát. Ebben a módban csak az előre meghatározott időrésekben kommunikálhat a master a piconet egy slave egységével, és a slave egységnek is csak a kijelölt időrésekben kell a csatornát figyelnie. Amennyiben a slave ezen meghatározott időrésben csomagot vesz, akkor addig kell figyelnie a csatornát, amíg az ő címével ellátott csomagok kerülnek a csatornára. A sniff módba való belépés a LM protokoll egy parancsával történik, amit a sniff módhoz szükséges paraméterek meghatározása követ. 3.12.5.4 PARK mód A PARK módba azok az egységek kerülnek, amelyek nem osztoznak a piconet csatorna forgalmán, de meg akarják tartani szinkronitásukat. Ezen egységek alacsony fogyasztási állapotba lépnek, és az aktív eszköz címüket is elvesztik. Ezen cím helyett két új címet használnak az egységek megkülönböztetése céljából: PM_ADDR: 8 bites Parked Member Address AR_ADDR: 8 bites Access Request Address PM_ADDR a park állapotban lévő slave egységek megkülönböztetésére szolgál. Ezt a címet a master használja az unpark eljárásnál. Ha a parkolt egységnek csupa nullát tartalmazó PM_ADDR e van, akkor ebből az állapotból csak az ő BD_ADDR címe által lehet kiváltani. Ebben az esetben a PM_ADDR címnek nincs jelentősége. Az AR_ADDR címet a slave egységek használják, az unpark eljárás lebonyolítására. A park állapotban lévő slave egységeket broadcast csomagokon keresztül informálhatjuk, mivel ezen csomagoknak csupa nullát tartalmazó AM_ADDR címük van. A park módban lévő slave egységek rendszeres időközönként belehallgatnak a csatornába, hogy újra szinkronizálódjanak valamint a nekik szóló broadcast üzeneteket fogadják. A parkolt slave egységek szinkronizációja valamint a csatorna hozzáférése az un jelző csatorna alkalmazásával lehetséges. Ez teszi 41
lehetővé a parkolt slave informálását. A park mód segítségével több mint 7 slave egységet csatlakoztathatunk egy masterhez, azonban egyidejűleg csak 7 egység lehet aktív állapotban. A park állapotban lévő egységek számát gyakorlatilag nem korlátozza semmi. A slave egységek park módba juttatását valamint aktív módba állítását park módból dedikált LMP parancsok segítségével a master végzi. 3.12.5.5 Jelző csatorna A jelző csatorna egy jelző időrésből vagy azonos távolságra lévő ( B) több időrésből áll, amelyeket periódikus időközönként (TB) továbbít a master. A jelző csatornát illusztrációját a 3.29. ábra mutatja. 3.29 ábra: általános jelző csatorna formátum A jelző csatorna első időrése a Tb intervallum időzítésének meghatározására szolgál. A jelző csatorna paramétereit (Nb illetve Tb) úgy választjuk meg, hogy elegendő jelző időrés legyen a park állapotban lévő slave egységek szinkronizációjára. Ezekről a paraméterekről a park állapotban lévő slave egységek egy LMP parancs segítségével értesülnek. A jelző csatorna első időrése egy meghatározott master-toslave időrés egyikére esik, melynek meghatározását a Bluetooth specifikáció tartalmazza. A jelző csatornának célja a következő négy feladat megvalósítása a parkolt állapotban lévő slave egységek számára: masterhez történő szinkronizáció jelzőcsatorna paramétereinek továbbítása általános broadcast üzenetek továbbítása aktív állapotba állítás 42
Mivel a slave egységek bármely csomagra képesek szinkronizálni, amely tartalmazza a csatorna access kódját, így a szinkronizációra használt broadcast csomagoknak nem kell más információt tartalmazniuk. Amennyiben nincs továbbítandó információ, úgy a jelző időrésben NULL típusú csomagokat küld a master. A szinkron adatforgalmat a jelzőcsatorna átvitele megszakíthatja. A jelző csatorna időrései mellett a rendszer olyan időréseket is definiál, ahol a parkolt állapotban lévő slave egységek az AR_ADDR címüket használva kérhetik az aktív állapotba való visszatérésüket. 3.12.5.6 A parkolási folyamat A master egy LMP parancs segítségével az aktív állapotban lévő slave egységeket park módba küldheti. Azonban mielőtt ezt megtenné, egy PM_ADDR és egy AR_ADDR címet jelöl ki számukra. A PM_ADDR minden park állapotban lévő slave egység esetén más, azonban az AR_ADDR nem szükségszerűen különböző. Amikor a slave park módba kerül a master a jelző csatorna paramétereit is átadja számára. Ezután a slave AM_ADDR címe megszűnik és park állapotba kerül. A master egyszerre csak egy slave parkoltatására képes. 43
3.12.5.7 Master által kezdeményezett unpark folyamat A master egység kezdeményezheti a parkolt állapotban lévő slave aktívvá tételét egy dedikált LMP unpark parancs segítségével. Ezt a parancsot a master a jelzőcsatorna egy időrésében küldi el a slave egységnek a slave PM_ADDR vagy a teljes BD_ADDR címének felhasználásával. Természetesen ez az üzenet tartalmazza azt az AM_ADDR címet, amit a slave a visszatérte után használ a piconeten belül. Az unpark parancs vétele után a slave egyezteti a PM_ADDR vagy a BD_ADDR címet, és egyezés esetén aktív módba lép. A már aktív állapotban lévő slave a master által küldött első POLL csomagot nyugtázza, ezzel jelezve a parkolt állapotból való visszatérését. Amennyiben a nyugtázás elmarad, a master újra unpark parancsot küld a slave egység számára. 3.12.5.8 Slave által kezdeményezett unpark folyamat A park állapotban lévő slave egységek az AR_ADDR címüket használva kezdeményezhetik az aktív állapotba való visszatérésüket meghatározott időközönként (lsd jelző csatorna) egy csatorna hozzáférés kérelem parancs segítségével. A hozzáférés kérelmet tartalmazó üzenet egy ID csomag, amely a jelző csatornán érkező broadcast üzenet előtti időrésben kerülhet a csatornára és a master eszköz hozzáférési címét (DAC) tartalmazza. A hozzáférési kérelem elküldése után a slave unpark üzenetet vár a mastertől. Amíg az meg nem érkezik tovább folytatja a hozzáférési kérelmek küldését a meghatározott időrésekben. Az ezt követő folyamatokat az előző fejezet írja le. 3.12.6 Bluetooth eszközök állapotainak áttekintése A 3.28. ábrán a Bluetooth összeköttetés vezérlő által használt állapotok átmeneteit figyelhetjük meg. Két fő állapot a STANDBY valamint CONNECTION állapot. Ezen kívül hét alállapot van, amelyek átmeneti állapotok a slave piconetbe vételéhez. Az állapotokba való átmenetek a Bluetooth az LMP parancsaival illetve az összeköttetés vezérlőben lévő külső jelek segítségével történnek. 44
3.30 ábra: Bluetooth összeköttetés vezérlő állapot diagramja 3.12.7 Scatternet Több piconet átlapolt ellátottsági területtel alkotja a scatternetet. Minden piconetnek különböző master egysége van, így azok frekvenciaugratási sorozatuk és fázisuk függetlenek egymásétól. A piconeten forgalmát a csomagokban lévő master eszköz címéből származtatott access kód azonosítja. Minél több piconet működik egymás mellett, annál nagyobb lesz a csomagok ütközésének valószínűsége, ami a teljes rendszer teljesítmény csökkenéséhez vezet a közös csatorna használata miatt. Abban az esetben amikor több piconet fedi le ugyanazon földrajzi területet, akkor előfordulhat, hogy egy Bluetooth egység több picone tagja is lehet. Ezek az egységek a forgalom figyelését valamint generálását a különböző piconeteken belül időosztásos multiplex elven végzik. Így lehetséges az, hogy egy slave egy másik piconet tagja is lehet slave valamint master szerepben egyaránt. A piconeten belül lévő master egységek azonban más piconeten belül csak slave szerepben lehetnek jelen. 45