Informatika | Hálózatok » Lázár Zoltán - Bluetooth

Lázár Zoltán Dr. Eged Bertalan BME Mikrohullámú Híradástechnika Tanszék http://www.mhtbmehu Vezetéknélküli Inofrmáció Technológia Laboratórium http://wit.mhtbmehu http://wit.mhtbmehu 1 1. BEVEZETÉS 5 BEVEZETÉS 2. BLUETOOTH FIZIKAI RÉTEG 7 2.1 FREKVENCIA SÁVOK ELRENDEZÉS EZÉS. 7 SÁVOK ÉS CSATORNA ELREND EZÉS 2.2 TELJESÍTMÉNYSZABÁLYOZÁS TELJESÍTMÉNYSZABÁLYOZÁS . 7 2.3 MODULÁCIÓ 8 MODULÁCIÓ 3. BLUETOOTH ALAPSÁVI ALAPSÁVI EGYSÉG . 9 3.1 BLUETOOTH CSATOR CSATORNA NA. 9 NA 3.2 FIZIKAI ÖSSZEKÖTTETÉSEK ÖSSZEKÖTTETÉSEK . 10 3.21 SZINKRON (SCO) ÖSSZEKÖTTETÉS 10 3.22 ASZINKRON (ACL) ÖSSZEKÖTTETÉS 10 3.3 CSOMAGOK ÁLTALÁ ÁLTALÁNOS NOS FELÉPÍTÉSE. 11 FELÉPÍTÉSE 3.31 HOZZÁFÉRÉSI (ACCESS) KÓD 11 3.311 Preamble 12 3.312 Szinkron szó 12 3.313 Trailer 12 3.32 CSOMAG FEJLÉCE 13 3.33 HASZNOS INFORMÁCIÓT TARTALMAZÓ RÉSZ 14 3.331 Hang információ esetén 14 3.332 Adat információ esetén 14 3.4 CSOMAG TÍPUSOK 16 3.41

SZINKRON CSOMAGTÍPUSOK 16 3.411 HV1 csomag 16 3.412 HV2 csomag 16 3.413 HV3 csomag 16 3.414 DV csomag 16 3.42 ASZINKRON CSOMAGTÍPUSOK 17 3.421 DM csomag 17 3.422 DH csomag 17 3.423 AUX1 csomag 17 3.43 ÖSSZEKÖTTETÉST VEZÉRLŐ CSOMAGTÍPUSOK 17 3.431 ID csomag 18 3.432 NULL csomag 18 3.433 POLL csomag 18 3.434 FHS csomag 18 3.5 HIBAJAVÍTÁS 19 HIBAJAVÍTÁS 3.51 FEC 1/3 20 3.52 FEC 2/3 20 3.53 ARQ VÉDELEM 21 3.531 Számozatlan ARQ 21 3.532 Újraküldött csomagok kiszűrése 22 3.533 Hasznos információ kiürítése 22 3.534 Több slave egység figyelembevétele 23 3.535 Broadcast csomagok 23 2 3.6 HIBAELLENŐRZÉS 23 3.7 LOGIKAI CSATORNÁK CSATORNÁK . 25 3.71 LC LOGIKAI CSATORNA 25 3.72 LM LOGIKAI CSATORNA 26 3.73 UA/UI LOGIKAI CSATORNA 26 3.74 US LOGIKAI CSATORNA 26 3.8 ADAT FEHÉRÍTÉS (DATA (DATA WHITENING) . 26 3.9 ADATFOLYAM VEZÉRLÉSE 27 VEZÉRLÉSE. LÉSE 3.91 VEVŐ OLDALI VEZÉRLÉS 27 3.92 FORRÁS OLDALI VEZÉRLÉS 27 3.10 BITFOLYAM FELDO

FELDOLGOZÁSA LGOZÁSA. 27 LGOZÁSA 3.101 A FEJLÉC FELDOLGOZÁSA 27 3.102 A HASZNOS INFORMÁCIÓS RÉSZ FELDOLGOZÁSA 28 3.11 BLUETOOTH ESZKÖZÖK ÁLLAPOTAI POTAI . 28 ESZKÖZÖK MŰKÖDÉSI ÁLLA 3.111 MASTER/SLAVE IDŐSZINKRONIZÁLÁS 28 3.112 CONNECTION ÁLLAPOT 29 3.113 STANDBY ÁLLAPOT 30 3.114 VISSZATÉRÉS HOLD ÁLLAPOTBÓL 30 3.115 FELÉBREDÉS PARK MÓDBÓL 30 3.116 PAGE ÁLLAPOT 30 3.117 AZ FHS CSOMAG 31 3.118 MULTI-SLAVE MŰKÖDÉS 32 3.12 CSATORNA VEZÉRLÉSE VEZÉRLÉSE . 33 3.121 MASTER-SLAVE DEFINICIÓ 33 3.122 BLUETOOTH RENDSZERÓRÁJA 34 3.123 CSATORNA HOZZÁFÉRÉSI ELJÁRÁS 34 3.1231 Page scan folyamat 35 3.1232 Page folyamat 35 3.1233 Page response folyamat 36 3.124 INQUIRY FOLYAMAT 37 3.1241 Inquiry scan 37 3.1242 Inquiry 38 3.1243 Inquiry válasz 38 3.125 CONNECTION ÁLLAPOT 39 3.1251 Aktív mód 40 3.1252 HOLD mód 40 3.1253 Sniff mód 41 3.1254 PARK mód 41 3.1255 Jelző csatorna 42 3.1256 A parkolási folyamat 43 3.1257 Master által

kezdeményezett unpark folyamat 44 3.1258 Slave által kezdeményezett unpark folyamat 44 3.126 BLUETOOTH ESZKÖZÖK ÁLLAPOTAINAK ÁTTEKINTÉSE 44 3.127 SCATTERNET 45 3.1271 Inter-piconet kommunikáció 46 3.1272 Master-slave szerepváltás 46 3.13 FREKVENCIAUGRATÁSI 46 FREKVENCIAUGRATÁSI SOROZAT. SOROZAT 3 3.14 BLUETOOTH AUDIO 47 3.15 BLUETOOTH ESZKÖZ CÍM 48 CÍM 3.16 BLUETOOTH ADATBIZTONSÁG ADATBIZTONSÁG . 48 3.161 TITKOSÍTÁS FOLYAMATA 49 3.162 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 MENEDZSELÉSÉT VÉGZŐ PROTOKOLL PROTOKOLL ÉS TULAJDONSÁGAI. 52 TULAJDONSÁGAI 4.2 HITELESÍTÉS 53 4.3 TITKOSÍTÁS 53 TITKOSÍTÁS 4.4 A RENDSZERÓRÁHOZ KÉPESTI OFSZET KÉRÉSE 54 KÉRÉSE. SE INFORMÁCIÓ FORMÁCIÓ. 55 4.5 IDŐRÉS OFSZET IN FORMÁCIÓ 4.6 LMP VERZIÓSZÁM LEKÉRDEZÉSE LEKÉRDEZÉSE . 55 4.7 MASTERSZEREPCSERE REPCSERE . 55 MASTER-SLAVE SZE 4.8 NÉV LEKÉRDEZÉSE 56 4.9 KAPCSOLAT

56 KAPCSOLAT MEGSZAKÍTÁSA. MEGSZAKÍTÁSA 4.10 CONNECTION ÁLLAPOTBAN 57 ÁLLAPOTBAN LÉVŐ EGYSÉGEK. EGYSÉGEK 4.11 TELJESÍTMÉNYSZABÁLYOZÁS TELJESÍTMÉNYSZABÁLYOZÁS . 57 4.12 CSATORNA MINŐSÉGÉTŐL MINŐSÉGÉTŐL FÜGGŐ CSOMAGTÍPUS CSOMAGTÍPUS BEÁLLÍTÁSOK BEÁLLÍTÁSOK . 58 4.13 SZOLGÁLTATÁS MINŐSÉGE 58 MINŐSÉGE (QUALITY OF SERVICE, SERVICE, QOS). QOS) 4.14 SCO ÉS ACL ÖSSZ ÖSSZEKÖTTETÉSEK EKÖTTETÉSEK LÉTESÍTÉ LÉTESÍTÉSE SE . 59 4.15 ÖSSZEKÖTTETÉSEK FELÜGYELETE 59 FELÜGYELETE 5. LOGIKAI ÖSSZEKÖTT ÖSSZEKÖTTETÉST ALKALMAZÓ ALMAZÓ PROTOKOLL. ETÉST VEZÉRLŐ ÉS ALK PROTOKOLL 60 5.1 LOGIKAI ÖSSZEKÖTTETÉST ÖSSZEKÖTTETÉST VEZÉRLŐ ÉS ALKALMAZÓ ALKALMAZÓ PROTOKOLL TULAJDONSÁGAI. 60 TULAJDONSÁGAI 5.2 AZ L2CAP PROTOKOLL 61 PROTOKOLL ÉS FELADATAI. FELADATAI 5.21 PROTOKOLL MULTIPLEXÁLÁS 61 5.22 SZÉTVÁLASZTÁS ÉS ÖSSZERAKÁS 62 5.23 QUALITY OF SERVICE (QOS) 62 5.24 CSOPORTOK 62 5.3 L2CAP CSOMAG FELÉPÍTÉSE FELÉPÍTÉSE .

63 5.31 Ö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.32 Ö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 Bluetooth 2.4 GHz Bluetooth rádió Bluetooth összeköttetés vezérlő 5 összeköttetés menedzser & I/O Kiszolgáló 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 12 ábra mutatja 1.2 ábra: pontpont-pont pont (a), pontpont-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 21 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 22 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áb Táblázat: lá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) 2 2,5 mW (4 dBm) 3 1 mW (0 dBm) 1 mW (0 dBm) 0,25 mW (-6 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 300328, Amerikában az FCC 15.247, 15249, 15205, 15209 é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.21 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.22 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 33 á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 ACCESS kód MSB 0-2745 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.31 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 Preamble Szinkron szó 4 MSB 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.311 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 35 ábra mutatja LSB 1 MSB LSB 0 1 0 1 x x PREAMBLE LSB 0 SZINKRON SZÓ MSB LSB 1 0 1 0 x x PREAMBLE SZINKRON SZÓ

3.5 ábra: Preamble 3.312 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=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.313 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 x x 0 1 SZINKRON SZÓ MSB LSB 12 MSB 0 1 0 TRAILER MSB x x 1 SZINKRON SZÓ 0 1 0 1 TRAILER 3.6 ábra: a trailer kétféle felépítése CAC használatakor 3.32 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 37 ábrán látható LSB 3 AM ADDR 4 TÍPUS 1 FLOW 1 ARQN 1 SEQN 8 MSB 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.33 Hasznos információt tartalmazó rész 3.331 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.332 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.3321 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 38 ábrán látható. LSB 2 1 L CH FLOW 5 MSB Hossz a.) Az 1 időrés hosszúságú csomagok fejléce 14 LSB 2 1 9 L CH FLOW Hossz 4 MSB 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.3322 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.3323 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.41 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őtar Időtartam (idő (id őrés) informá 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+576 adat 3.411 HV1 csomag A HV1 csomagokat tipikusan hangátvitelre használják. A csomag 125ms beszéd átvitelére alkalmas, minden második időrés felhasználásával. 3.412 HV2 csomag A csomag 2.5ms beszéd átvitelére alkalmas, minden negyedik időrés felhasználásával 3.413 HV3 csomag A csomag 3.75ms beszéd átvitelére alkalmas, minden hatodik időrés

felhasználásával 3.414 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 Access kód 54 Fejléc 80 Hang mező 3.9 ábra: a DV csomag felépítése 16 32-150 Adat mező MSB 3.42 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 infor-Típus Időtartam Hasznos infor (időrés) máció (byte) FEC CRC átviteSzimmetrikus átvit eli sse ebesség (kb/s) Aszimmetrikus átviteli sebessség (kb/s) sebe AUX1 1 0 – 29 Nincs Nem 185.6 185.6/1856

DM1 1 0 – 17 2/3 Igen 108.8 108.8/1088 DH1 1 0 – 27 Nincs Igen 172.8 172.8/1728 DM3 3 0-121 2/3 Igen 258.1 387.2/544 DH3 3 0-183 Nincs Igen 390.4 585.6/864 DM5 5 0-224 2/3 Igen 286.7 477.8/363 DH5 5 0-339 Nincs Igen 433.9 723.2/576 3.421 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.422 DH csomag A DH típusú csomagokat nagysebességű adatátvitelre használjuk. 3.423 AUX1 csomag Ez a csomag hibaellenőrzés nélküli DH1 csomagnak felel meg. 3.43 Ö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 iinnCsomag hossz formá form áció (byte)

(byte) (bit) ID 1 Igen Nincs - 68 NULL 1 Igen Igen - 126 POLL 1 Igen Igen - FHS 1 Igen Igen 18 17 FEC CRC - - 126 - - 270 2/3 Igen 3.431 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.432 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.433 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.434 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 Paritás bit 24 2 LAP Határozatlan mező 2 SR 2 SP 8 16 UAP NAP 24 Class of device 3 26 AM ADDR CLK27-2 3 MSB Page Scan mód 3.10 ábra: az FHS csomag felépítése 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. Ezen két bit a jövőbeni funkciók bővítésére szolgál, célszerű nullának válasz- SR mező Scan Repetition mező a scan folyamat ismétlődési periódusát mondja meg. SP mező 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ő Azon egység UAP címe, amely az FHS csomagot küldte. NAP mező 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. CLK27-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 – 35 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.51 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.52 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 312 á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 F FEC EC 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.53 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.531 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.532 Ú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.533 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ül22 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.534 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.535 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 313 á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-317 á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+ D5+ D2+ 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á generátor 10 bit fejléc 8 bit HEC 8 bit UAP HEC generá átor gener Vevő egység helyes vétel esetén a maradék 0 3.15

ábra: HEC ellenőrzése és generálása 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+ D12+ D5+ 1 ) 24 Adó egység 8 bit UAP, 8 bit bővítés CRC generá átor gener adat 16 bit CRC 8 bit UAP, 8 bit bővítés CRC generrátor gene Vevő egység 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.71 LC logikai csatorna 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é25 cet. 3.72 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.73 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.74 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 318 ábra mutatja 3.18 ábra: az adat fehérítés 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 rend26 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.91 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.92 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.101 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 folyamata az adó illetve vevő oldalon 3.102 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 informá- CRC generálása titkosítás adat fehérítés kódolás RF interfész Hasznos informáó CRC ellenőrzés titkosítás dekódolás adat dekódolás 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 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.111 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.112 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 eseeseté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óciklusa klusa normál módban, 1 időrést használó csomaadó-vevő RX/TX ci csomagok 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.113 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.114 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.115 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.116 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ó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.117 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 325 á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.118 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 RX/TX időzítés multimulti-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.121 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 311 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.122 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(slave) CLK 0 + CLK 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.123 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.1231 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.1232 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 328 ábra mutatja 3.1233 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.124 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.1241 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.1242 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 330 ábra mutatja 3.1243 Inquiry válasz A master egység az inquiry üzenetek között válaszra várva figyeli a csator38 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.125 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.1251 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.1252 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.1253 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.1254 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.1255 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 329 á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.1256 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.1257 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.1258 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.126 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.127 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 piconet 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 A piconetek azon csoportját nevezzük scatternetnek, ahol a különböző piconetekben résztvevő egységek között kommunikációs összeköttetés valósul meg. A scatternetben résztvevő piconetek egymással nem idő illetve frekvencia szinkronizáltak. Minden egyes piconeten belül a szinkronizáció a hozzá tartozó masterhez rendszerórájához képest történik. 3.1271 Inter-piconet kommunikáció Ha egy egység több piconetben vesz részt, akkor idő multiplexálást kell használni a piconetek közötti váltáshoz. Így aszinkron összeköttetés esetén az egységeknek hold illetve park módba kell magukat kérniük az aktuális piconeten

belül, és ezen idő alatt csatlakoznak egy másik piconethez. A sniff’ módban lévő egységeknek elegendő idejük van az un. sniff időrések között más piconetekkel kommunikálni. Szinkron összeköttetés esetén a többi piconet csak a nem foglalt időrésekben tud egymással kommunikálni. Mivel a piconetek egymáshoz képest nem szinkronizáltak, így egy un. biztonsági időt kell hagyni a szinkronizációra is Ha egy slave egység két piconetben vesz részt, azok természetesen nem szinkronizáltak, így két különböző ofszettel kell adnia a két piconetben. Ahhoz, hogy a slave szinkronban maradhasson a két masterrel rendszeresen frissítenie kell az ofszet értékeket. 3.1272 Master-slave szerepváltás Amelyik egység megszervezi a piconetet az lesz a master. Bár előfordulhat olyan szituáció, amikor egy slave akar master lenni. Annak a két egységnek amelyik a szerepváltásban részt vesz, először fel kell cserélnie az adási illetve vételi

időréseket (TDD váltás). Mivel a piconet paraméterei az eszköz címéből valamint a master rendszerórájából származik, így a master-slave szerepváltás a piconet újraértelmezését jelenti, azaz piconet váltás. Ezek alapján az újjászervezett piconet paraméterei a slave címétől valamint órájától fognak függeni. A váltás következtében a többi slave egységnek át kell szerveződnie az új piconetbe megváltoztatva az időztésüket és frekvenciaugratási sorozatukat. 3.13 Frekvenciaugratási sorozat A különböző állapotban lévő Bluetooth egységek minden állapotban más frekvenciaugratási sorozatot alkalmaznak. Ez 5-5 különböző sorozatot jelent a 79 46 valamint 23 csatornát alkalmazó rendszerekben, melyek a következők:
Page frekvenciaugratási sorozat
Page válasz frekvenciaugratási sorozat
Inquiry frekvenciaugratási sorozat
Inquiry válasz frekvenciaugratási sorozat
Csatorna frekvenciaugratási sorozat A 3.31 ábra

mutatja a frekvencia ugratási sorozat pillanatnyi frekvenciájának meghatározásához szükséges paramétereket. Ezek a rendszeróra, 79 vagy 23 frekvenciát használó rendszerazonosító és az UAP cím felső 4 bitje valamint a 24 bites LAP együttesen. Az inquiry és inquiry válasz állapotban lévő egységek a 24 bites GIAC LAP címet használják a LAP cím és DCI azonosítót az UAP felső 4 bitje helyett. CONNECTION állapotban ez természetesen a master egység, PAGE állapotban a page egység címe. Ezen bemeneti paraméterek függvényében a kimenet egy álvéletlen frekvencia sorozat 23/79 mód UAP/LAP (28 bit) CLK (27 bit) aktuális frekvencia kiválasztása Frekvencia ugratási sorozat 3.31 ábra: frekvencia kiválasztás folyamatának blokkdiagramja 3.14 Bluetooth audio A Bluetooth az audio adatok átvitelére 64kb/s logaritmikus PCM (A-law, ulaw ITU-T G.711 ajánlása) illetve CVSD (Continuous Variable Slope Delta Modulation, amely adaptív delta

modulációs algoritmus) modulációkat alkalmazza. 47 3.4 táblázat: Bluetooth által támogatott audio kódolási eljárások Hang kóder, dekóder Lineáris CVSD 8 bites logaritmikus logaritmikus A-law u-law DV illetve HV3 csomagtípusok esetén a hang információt nem látják el FEC védelemmel, így az átvitt hang minősége az alkalmazott moduláció robusztusságának a függvénye. A CVSD érzéketlenebb véletlen bithibákra, amelyet az additív fehér zaj jellegű zavarok okozhatnak. Azonban amikor a hang információt tartalmazó csomag megsérül, a kimaradt hang részletet a kapott hangminták alapján köztes értékkel kell helyettesíteni. Ha a hang információt tartalmazó védett csomagok úgy sérülnek meg, hogy azt a hibajavító kódolás nem képes kijavítani, akkor a hibásan vett csomagot kell dekódolni. Természetesen a HV1 csomagok vannak a legjobban védve a meghibásodás ellen, így ezen csomagok alkalmazása esetén a hibákat általában

a hibajavító kód javítani képes. 3.15 Bluetooth eszköz cím Minden Bluetooth adó-vevő egységnek egy egyedülálló 48 bites eszköz címe (BD ADDR) van, amelyet az IEEE802 szabványból származik. Ezen 48 bites cím három részből tevődik össze, ahogy azt a 3.32 ábra mutatja LSB 24 8 16 LAP UAP NAP MSB 3.32 ábra: BD ADDR felépítése A BD ADDR legfontosabb része a LAP valamint UAP. Ezen bitekből származtatja a rendszer a frekvencia ugratási sorozatokat 3.16 Bluetooth adatbiztonság A Bluetooth rendszer lehetővé teszi a felhasználói információ védelmét valamint titkosított kezelését is. Ez azt jelenti, hogy minden Bluetooth egységben azonosító és titkosító algoritmusokat implementáltak Az ezen eljárásokhoz használt kulcsokat, azonosítókat illetve azok méreteit a következő táblázat mutatja. 48 3.5 táblázat: Azonosító és titkosító algoritmusokhoz használt kulcsok Azonosító Mérete BD ADDR BD ADDR 48 bit Privát

felhasználói kulcs azonosításra 128 bit Privát felhasználói kulcs titkosításra 8-128 bit RANDOM véletlen szám 128 bit A rendszer négy fajta összeköttetést titkosító kulcsot használ az azonosítási folyamatban:
Kab kombinációs kulcs
Ka az egységhez tartozó kulcs (az egység az inicializálása után kapja meg)
Kmaster ideiglenes kulcs
Kinit inicializálásnál használt kulcs A titkosításnál használt Kc kulcsot a rendszer az éppen aktuális kulcs értékéből származtatja. Funkcionalitását tekintve a Kab, Ka kulcsok nem különböznek, különbség csak ezen kulcsok generálásánál van. Mivel Ka az egység inicializálásánál keletkezik, így az nagyon ritkán cserélődik A Kab kulcsot a kommunikáló két egység határozza meg, és minden egyes kapcsolatfelvételnél más értéket vesz fel. A Kmaster nagyon ritkán ideiglenesen helyettesítheti az aktuális kulcsot. Ez olyan esetekben történik meg, amikor a master azonos

titkosító kulccsal akar több egységnek üzenetet küldeni 3.161 Titkosítás folyamata Az access kódon valamint a csomag fejlécén nem alkalmazunk titkosítást, csak a csomag hasznos információs részén. A titkosításhoz az E0 algoritmust használjuk, ami minden csomag esetén más bitsorozatot használ a titkosításra Az algoritmus három részből áll, ahogy azt a 333 ábra mutatja Az első a hasznos információs rész titkosításához szükséges kulcs generálása (ehhez szükséges paraméterek a Kc, az eszköz cím, a rendszeróra és a RAND véletlen szám), a második rész előállítja az adott kulcsból azt a bitfolyamot, amivel kizáró vagyolni kell az 49 információt és a harmadik rész feladata a titkosítás megvalósítása és a titkos információból az eredeti visszanyerése. Titkosítandó/titkosít ott Kc cím rendszeróra RAND Titkosító kulcs generálása Titkosító bitfolyam generátor Titkosító kulcs Z +

Titkosított/titkosítotandó információ 3.33 ábra: A titkosításhoz használt E0 algoritmus A teljes titkosítási folyamatot a 3.34 ábra mutatja Mivel a rendszer a titkosításhoz alkalmazott Kc kulcsot az aktuális összeköttetéshez tartozó kulcsból valamint egy véletlen számból származtatja, így a titkosított információ küldése előtt a vevő oldalt a master egységnek értesítenie kell ezen EN RANDA értékéről. Mivel az E0 algoritmus bemenő paramétere a rendszeróra, így a folyamat minden új küldött csomag esetén új titkosítási kulcsot használ. UNIT B UNIT A (master) EN RANDA BD ADDRA RendszeróraA BD ADDRA RendszeróraA E0 E0 KC KC adatA
B + adatB
A + + ADAT + 3.34 ábra: a titkosítási folyamat 3.162 Hitelesítés A hitelesítési folyamat során a hitelesítést kezdeményező arról győződik meg, hogy a másik oldalnak birtokában van-e a hitelesítéshez szükséges titkos kulcs. A hitelesítés akkor történik meg, ha

hitelesítő ugyanazon kulcs birtokában van, mint a hitelesített. A folyamatot a 335 ábra mutatja 50 Hitelesített (UNIT B) Hitelesítő (UNIT A) AU RANDA AU RANDA BD ADDRB BD ADDRB E1 SRES összeköttetés kulcs AU RANDA E1 összeköttetés kulcs SRES SRES’ ? SRES == SRES’ 3.35 ábra: a hitelesítés folyamata A hitelesítést végző egység egy AU RANDA véletlen számmal, a hitelesíteni kívánt egység BD ADDR címével valamint az összeköttetéshez tartozó kulccsal generál egy SRES számot. Ezután a hitelesítést végző elküldi a hitelesítéshez szükséges véletlen számot. A másik oldal ugyanazon E1 algoritmus segítségével is előállítja az SRES értéket, amit visszaküld a hitelesítőnek. A hitelesítő ellenőrzi az általa generált valamint érkezett SRES értékeket. Egyezés esetén a hitelesítés sikerrel járt Kölcsönös hitelesítés esetén a folyamat a másik egység hitelesítésével folytatódik, megcserélve az A

illetve B egység szerepeit. A Bluetooth rendszerben a hitelesítést nem feltétlenül a master egység végzi, az alkalmazás határozza meg, hogy ki hitelesíti a másik egységet. Ha egy hitelesítési folyamat meghiúsul, újabb hitelesítés kezdeményezése csak egy előre meghatározott idő eltelte után történhet meg 51 4. Az összeköttetés menedzselését végző protokoll 4.1 Az összeköttetés menedzselését végző protokoll és tulajdonságai A LMP üzenetei összeköttetés beállítási, biztonsági valamint vezérlő funkciókat látnak el. Ezeket az üzenetek a csomagok hasznos információs részében kerülnek átvitelre és megkülönböztetésükre a logikai csatornák (L CH = 11 jelzi az LMP csomagokat) szolgálnak. Ezen típusú üzenetek a vevő oldali LMP által kerülnek feldolgozásra, így a felsőbb rétegek ezeket nem látják LM LMP LM LC LC RF RF Fizikai réteg 4.1 ábra: LMP elhelyezkedése a réteg struktúrában Az LMP

üzeneteknek magasabb prioritása van mint a felhasználói adatoknak. Amennyiben az összeköttetés menedzser üzenetet akar küldeni, akkor ez az üzenet nem szenvedhet késleltetést az L2CAP által lebonyolított forgalom által, bár a hibásan megérkezett csomagok újraküldése nagyobb prioritást élvez. A következőkben ismertetésre kerülnek azok a fontosabb parancsok, amelyeket az LMP használ az összeköttetések menedzselésére. 52 4.2 Hitelesítés A hitelesítési folyamat során a hitelesítő egység arról szerez információt, hogy a hitelesítendő egységnek birtokában van-e az összeköttetés hitelesítéséhez szükséges kulcs. Az ehhez szükséges parancsokat, illetve a hitelesítés folyamatát LMP szinten a 4.2 ábra mutatja Hitelesítő Hitelesítő Hitelesített Hitelesített LMP au rand LMP au rand LMP sres LMP not accepted a.) b.) 4.2 ábra: a) sikeres illetve b) sikertelen hitelesítési folyamat 4.3 Titkosítás A titkosítási

folyamat több lépésből tevődik össze. Először a master és slave meghatározza, hogy alkalmazzanak-e titkosítást vagy sem, illetve a titkosítás csak a mater és slave közötti pont-pont csomagokat érintik vagy a broadcast csomagokat is vagy egyszerre mindkettőt. Ha a két fél megegyezett a titkosítás paramétereit illetően, akkor a master részletes információkat ad a titkosításra vonatkozólag (a titkosításnál használt kulcs mérete), amelyek elfogadásuk után válnak érvényessé. Külön utasítás jelzi az egységeknek a titkosítás kezdetét valamint végét is. A teljes folyamatot a 4.3 ábra mutatja 53 Slave LM Master LM LMP encryption mode req LMP accepted or LMP not accepted LMP encryption key size req LMP accepted or LMP not accepted LMP start encryption req LMP accepted LMP stop encryption req LMP accepted 4.3 ábra: ábra: titkosítási folyamat 4.4 A rendszerórához képesti ofszet kérése A slave amikor egy FHS csomagot vesz, akkor

meghatározza a saját valamint a rendszeróra közötti időeltérést. Ezt az eltérést minden master egységtől vett csomag vételekor frissíti. A master ennek az értékét bármikor lekérdezheti a kapcsolat fennállása alatt Miután a slave elhagyta a piconetet, ezen információ birtokában a master tudja melyik csatornán fog a slave legközelebb page scan állapotba lépni. Ez a módszer meggyorsítja a már egyszer a piconetet elhagyó egység visszavételét egy page folyamat során Slave LM Master LM LMP clkoffset req LMP clkoffset res 4.4 ábra: rendszerórához képesti ofszet kérelem folyamata 54 4.5 Időrés ofszet információ Az időrés ofszet információ egy ofszet időt és egy BD ADDR címet tartalmaz. Az ofszet idő egy időkülönbség az információt küldő piconetében a master TX időrésének kezdete és azon master TX időrésének kezdete között, ahol a BD ADDR címmel rendelkező egység a master. Ez az információ master-slave

szerepváltás esetén lehet hasznos. Ebben az esetben a master egységgé alakuló eszköz mielőtt átvenné a csatorna vezérlését küld egy LMP slot offset üzenetet. Így amikor a csatorna vezérlését már átvette, akkor pontosan tudja a régi valamint az ő rendszerórája közötti idő ofszetet Kezdeményező LM LM LMP slot offset 4.5 ábra: időrés ofszet információ küldése LMP parancs segítségével 4.6 LMP verziószám lekérdezése Az LMP segítségével lehetőség nyílik az LM protokoll verziószámának lekérdezésére. A megszólított egység a lekérdező üzenetre elküldi az általa támogatott LMP verzió és alverzió számát. Ez azért lehet fontos, mert a verziószám megmondja, hogy az eszköz mely LMP parancsokat támogatja és melyiket nem Egy régebbi verziójú LMP nem biztos, hogy támogatja például az időzítési pontosság információkat lekérdező kérelmeket, így ezeket a parancsokat elutasítja. LM Kezd é LMP version req

LMP version res 4.6 ábra: LMP verziószám lekérdezése 4.7 Master-slave szerepcsere 55 Master-slave szerepváltás esetén a slave egység az L2CAP üzenetének befejezése után, egy LMP switch req paranccsal kérheti a master-slave váltást. Ha a jelenlegi master engedélyezi a váltást, akkor még befejezi az aktuális L2CAP üzenetének átvitelét, majd ezután egy LMP accepted paranccsal válaszol. Amennyiben a szerepváltást nem engedélyezi, a kérelemre adott válasz egy LMP not accepted parancs. A folyamatot a 47 ábra mutatja LM Kezd é LMP switch req LMP accepted or LMP not accepted 4.7 ábra: MaterMater-slave szerepcsere LMP segítségével 4.8 Név lekérdezése Minden egységnek lehet egy az egységhez társított felhasználóbarát neve is. Ez a név maximálisan 248 byte hosszúságú. Az eszköz nevének lekérdezését a 48 ábra mutatja. LM Kezd é LMP name req LMP name res 4.8 ábra: eszköz névének lekérdezése LMP segítségével 4.9

Kapcsolat megszakítása A két egység közötti összeköttetés bármikor és bármelyik egység által megszakítható. A kapcsolat megszakításának okáról azonban a túloldalt tájékoztatni kell (4.9 ábra) 56 Kezdeményező LM LM LMP detach 4.9 ábra: kapcsolat megszakítása LMP detach üzenet küldésével 4.10 CONNECTION állapotban lévő egységek A CONNECTION állapotban lévő egységek hold, sniff és park módba állítását is az LMP végzi, a következő utasításokkal:
HOLD mód: a master hold módba küldheti a slave egységet egy LMP hold üzenet segítségével. A HOLD módba való belépés kérését minden egység számára az LMP hold req parancs végzi, ami csak engedélyezés után realizálódhat.
SNIFF mód: a master SNIFF módba küldhet egy slave egységet az LMP sniff üzenet segítségével. Minden egység kérheti saját maga SNIFF módba való belépését illetve kilépését az LMP sniff req és LMP unsniff req üzenetekkel,

azonban ezeket a parancsokat csak jóváhagyás után hajthatják végre.
PARK mód: a master PARK módba küldhet egy slave egységet az LMP park parancs segítségével. Az egységek saját maguk is kérhetik a PARK módba állításukat az LMP park req parancs használatával. Ezen két parancs végrehajtása csak a túloldal nyugtázása után hajthatóak végre. 4.11 Teljesítményszabályozás A megfelelő vétel érdekében a vevő oldal kérheti az adó teljesítmény növelését vagy csökkentését. Amennyiben az adó a teljesítményét már nem képes növelni vagy csökkenteni, arról a vevő oldalt értesíti (lásd 410 ábra) Teljesítményszabályozással az adók által kibocsátott teljesítmények optimalizálása érhető el, így az interferencia szint is minimálisra csökkenthető. 57 Kezd Kez- LM é d LMP incr power req or LMP decr power req LM é LMP incr power req or LMP decr power req LMP max power or LMP min power a.) a.) b.) 4.10 ábra a)

kezdeményező az adó teljesítmény növelését vagy csökkentését kéri, b) kérés ellenére az adó tel teljesítmény már nem növelhető vagy csökkenthető tovább 4.12 Csatorna minőségétől függő csomagtípus beállítások Az aszinkron összeköttetések DM (kódolt) illetve DH (kódolatlan) csomagokat használnak. A DM csomagok a kódolásuk miatt kevesebb hasznos információt tartalmaznak, mint a DH csomagok Ezért egy jó minőségű csatornán elképzelhető, hogy a DM típusú csomagokat feleslegesen alkalmazzuk. A Bluetooth ezt rugalmasan kezeli, és az összeköttetésre jellemző előre definiált csomagtípusokat működés közben is megváltoztathatja. A csatorna minőségét a LC figyeli, és jelez, ha egy másik csomagtípus használata kedvezőbb. LM LM LM LM LMP auto rate LMP preferred rate a.) b.) 4.11 ábra: a) bal oldal kéri a csomagtípusok automatikus használatát, b) jobb oldal jelzi, a csomagtípus változ változtatását 4.13

Szolgáltatás minősége (Quality of Service, QoS) Az összeköttetés menedzser QoS szolgáltatásokat is lehetővé tesz, egy összeköttetés számára a kért sávszélesség megvalósításával és a kapcsolat ideje alatt ennek megvalósításához szükséges vezérléssel. Természetesen a másik oldal a QoS kérelmeket visszautasíthatja, ha nem tud a kérésnek megfelelő sávszélességet biz58 tosítani. LM Kezd é LMP quality of service req LMP accepted or LMP not accepted 4.12 ábra: QoS szolgáltatás kérése 4.14 SCO és ACL összeköttetések létesítése A Bluetooth egységek szinkron összeköttetéseket az LMP SCO link req paranccsal létesíthetnek és az LMP remove SCO link req paranccsal szüntethetnek meg. Kapcsolat létesítése és bontása a kétoldali nyugtázást követően történhet csak meg. Aszinkron összeköttetéseknél is az LMP végzi az aszinkron csomagok által elfoglalt időrések hosszának meghatározását a kétoldali LM

egyeztetésével. Kétoldali nyugtázásra itt is szükség van, mint szinkron esetben 4.15 Összeköttetések felügyelete Az LMP felelős az összeköttetések felügyeletéért is. Ez azt jelenti, hogy az LM rétegnek fel kell ismernie az összeköttetések megszakadását, és a megszakadt összeköttetéseket meg kell szűntetniük. Ezt az összeköttetésekhez tartozó beépített belső órák időzítéseivel valósítják meg 59 5. Logikai összeköttetést vezérlő és alkalmazó protokoll 5.1 Logikai összeköttetést vezérlő és alkalmazó protokoll tulajdonságai Az L2CAP protokoll az adatkapcsolati réteg egyik protokollja (5.1 ábra) Ezen protokoll az aszinkron adatok kezelését végzi a felsőbb rétegek felé (az adatinformáció csomagokra tagolása az adó illetve összerakása a vevő oldalon). Az L2CAP a felsőbb rétegek protokolljai és alkalmazásai számra az adatcsomagok adását és vételét maximum 64 kilobyte hosszúságú csomagokban teszi

lehetővé. Magasabb szintű protokoll vagy alkalmazás Magasabb szintű protokoll vagy alkalmazás Hálózati réteg Hálózati réteg LMP L2CAP Alapsávi egység L2CAP Adatkapcsolati réteg LMP Alapsávi egység Fizikai réteg Bluetooth egység #1 Bluetooth egység #2 5.1 ábra: L2CAP elhelyezkedése a protokoll rétegek között Az L2CAP protokoll az adatok védelmére hibaellenőrzést használ, így AUX1 típusú csomagok átvitelére nem alkalmas, mert az AUX1 típusú csomagok nem tartalmaznak a meghibásodást ellenőrző CRC kódot. Az adatkapcsolati rétegben az LMP és az L2CAP csomagok megkülönböztetésére a logikai csatornák szolgálnak (lásd 3.7 fejezet) Az L2CAP csomag felépítése, illetve több alapsávi csomagra tagolása a következő szakaszban kerül ismertetésre Az aszinkron csomagok fejléce 60 tartalmazza az adatfolyam vezérléséért felelős FLOW bitet is, amelynek vezérlése nem az L2CAP, hanem az összeköttetés vezérlő LC

feladata. 5.2 Az L2CAP protokoll és feladatai Az L2CAP protokoll elhelyezkedését a Bluetooth protokoll stackben a következő 5.2 ábra mutatja Ezen ábrán megfigyelhető továbbá a többi kommunikációs protokollal való kapcsolata is. SDP RFCOMM LMP L2CAP ACL TCS Audio Hang SCO Alapsáv 5.2 ábra: Bluetooth protokoll stack Hang átvitel céljára a telefon illetve audio alkalmazások általában az alapsávi szinkron összeköttetést alkalmazzák. A csomagkapcsolt audio adatátvitelnél mint például az IP telefon aszinkron összeköttetést alkalmazhatunk az L2CAP protokoll használatával. Az L2CAP protokollal szemben támasztott követelmények az egyszerűség és az alacsony overhead alkalmazása, mivel a Bluetooth egységeknek véges az adatfeldolgozáshoz szükséges kapacitása, valamint a protokoll implementálásához szükséges memória kapacitása is korlátos és lehetőség szerint minimális. 5.21 Protokoll multiplexálás Erre a funkcióra azért

van szükség, mert az alapsávi protokollok nem támogatják a felsőbb rétegek protokolljai számára a különböző típusú csomagok alkalmazását (lásd alapsávi csomagok fejlécének TYPE mezője). A multiplexálás megvalósításával az L2CAP protokoll különbséget tud tenni a felsőbb rétegek (SDP, RFComm, TCS) protokolljai között. 61 5.22 Szétválasztás és összerakás Az alapsávi csomagok mérete a csomag típusától függő fix érték (lásd 3.4 fejezet) Ennek következtében a nagyobb L2CAP csomagokat szét kell választani több kisebb méretű alapsávi csomagra (5.3 ábra), hogy a fizikai csatornán átvitelre kerülhessenek. A vevő oldalon az alapsávi csomagokra szétbontott csomagokat a hibaellenőrzés után össze kell rakni, ami szintén az L2CAP feladata. Hossz mező Csatorna azonosító L CH=10 Hasznos információs rész L CH=01 L CH=01 5.3 ábra: L2CAP csomagok szétválasztása a logikai csatornák alkalmazásával A csomagok

szegmentálása valamint összeállítása (SAR) arra a célra szolgál, hogy a felsőbb rétegek protokolljait támogassa, így ezen rétegekben használt csomagok méretei nem kötöttek az alapsávi csomagok méreteihez. 5.23 Quality of Service (QoS) Az L2CAP összeköttetések létesítésének folyamata során a két Bluetooth egység az elvárt QoS paramétereket egymással szemben tisztázhatják. Ezen paraméterek betartásának ellenőrzéséért az L2CAP felelős 5.24 Csoportok Több protokollban lehetőség van a csoportcímzésre. Az alapsávi protokoll az egységek csoportos kezelését teszi lehetővé egy piconeten belül azonos rendszeróra használatával és a frekvenciák szinkron ugratási sorozatával. Az L2CAP –ben történő csoport kezelése lehetővé teszi a piconetek egységes csoportként való kezelését, amely a különböző implementációk hatékonyabb alkalmazását segíti elő Az L2CAP –ben ezen funkció megvalósításának hiányában a

felsőbb rétegeknek kellene a különböző piconetekben lévő egységeket csoportokba szervezni. 62 5.3 L2CAP csomag felépítése Az L2CAP csomagok formátumát ez a szakasz mutatja be, összeköttetés orientált és összeköttetés nélküli adatcsatornák esetén. 5.31 Összeköttetés orientált pont-pont adatátviteli csatorna A csomagok felépítését az összeköttetés orientált pont-pont adatátviteli csatornán az 5.4 ábra mutatja L2CAP fejléc Hossz mező LSB 16 Csatorna azonosító Hasznos információ 16 MSB 5.4 ábra: L2CAP csomag felépítése pontpont-pont összeköttetések esetén Hossz mező A hossz mező a fejlécben helyezkedik el és a hasznos információt tartalmazó rész méretét adja meg byte-okban. A 16 bit maximálisan 65535+4 byte hosszú L2CAP csomagokat határoz meg. Ez a mező továbbá a csomag hosszának ellenőrzésével a megérkezett csomagok ellenőrzésére is szolgál Csatorna azonosító A csatorna azonosító a

csomaghoz tartozó címzettet azonosítja. Hasznos információt tartalmazó rész A hasznos információs rész hosszát a hosszúság mezőben szereplő érték határozza meg. Ezen rész tartalmazza még a felsőbb rétegek protokolljai által küldött információkat illetve parancsokat. A hasznos információs mező maximális hossza 65535 byte lehet, és 4 byte overhead-et okoz. 5.32 Összeköttetés nélküli pont-multipont adatátviteli csatorna A pont-multipont összeköttetések esetén az adat több azonos csoportban lévő 63 egységnek szól. Az L2CAP protokoll támogatja a csoportcímzést, bár az egységek közötti QoS szolgáltatást a pont-multipont összeköttetés megbízhatatlansága miatt már nem. Ez azért lehetséges, mert a protokoll nem képes garantálni a csoport minden tagja részére a sikeres átvitelt. Az összeköttetés nélküli pont-multipont L2CAP csomagok felépítését az 5.5 ábra mutatja LSB byte0 byte1 byte2 byte3 Hossz mező

Csatorna azonosító PSM Hasznos információ MSB Információ 5.5 ábra: L2CAP csomag felépítése pontpont-multipont összeköttetések esetén Hossz mező A hossz mező a hasznos információ és a PSM mező együttes hosszúságát határozza meg. Csatorna azonosító A csatorna azonosító ugyanazt a célt szolgálja mint pont-pont összeköttetések esetén. PSM A PSM mező a címmező ISO 3309 szabványnak megfelelő kibővítése. Feladata a protokoll multiplexálás megvalósítása Hasznos információt tartalmazó rész 0-65533 byte hosszúságú információs rész, amely tartalmazza a felsőbb protokoll rétegek által küldött információkat illetve parancsokat. 64