AZ AMI TÉMAKÖRÉBE TARTOZÓ

H-1116 Budapest, Fehérvári út 130.

Bay Zoltán Alkalmazott Kutatási Alapítvány

1509 Budapest Pf. 53 Tel.: (+36-1) 4630-500 Fax: (+36-1) 4630-505

AZ AMI TÉMAKÖRÉBE TARTOZÓ KOMMUNIKÁCIÓS PROTOKOLLOK HATÉKONYSÁGÁNAK VIZSGÁLATA

- tanulmány és mérési beszámoló -

Készült a KPI és a BZAKA közötti OMFB-01105/2004 számú szerződés 1. számú feladatának teljesítéseként

Készítette: Bay Zoltán Alkalmazott Kutatási Alapítvány AmI Projekt csoport

Budapest, 2005.04.29.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata

Tartalomjegyzék

1.

BEVEZETÉS ............................................................................................................................................... 6 1.1 A FELADAT INDOKOLTSÁGA ÉS AKTUALITÁSA ...................................................................................... 8 1.2 LEHETSÉGES „AMI” ALKALMAZÁSOK .................................................................................................. 9 1.2.1 Járművek közötti „AmI” alkalmazások (Inter-car) ......................................................................... 9 1.2.1.1 1.2.1.2 1.2.1.3 1.2.1.4 1.2.1.5 1.2.1.6 1.2.1.7 1.2.1.8 1.2.1.9

1.2.2

Ráfutásos baleset-megelőzés ................................................................................................................. 9 Dinamikus tempomat ............................................................................................................................ 9 Forgalom-információ terjesztése/gyűjtése........................................................................................... 10 Sürgősségi esetek (mentő-, tűzoltó-, rendőrautó) ................................................................................ 10 Autópálya díjszedő rendszer értéknövelt szolgáltatásokkal................................................................. 10 Az útmentén elhelyezett AmI-csomópontok jelentősége..................................................................... 10 Környezeti viszonyok változásainak érzékelése és továbbítása........................................................... 11 Felügyelt előzés................................................................................................................................... 11 Gyermek-felügyelet a forgalomban..................................................................................................... 11

Járművön belüli „AmI” alkalmazások (Intra-car)........................................................................ 11

1.2.2.1

„BAN” (Body Area Network) a járműben .......................................................................................... 11

1.2.3 Intelligens műhely (Smart Workshop) ........................................................................................... 12 1.2.4 Intelligens otthon (Assisted living) ................................................................................................ 12 1.3 A TANULMÁNY VEZÉRFONALA: AZ ALKALMAZHATÓSÁG KÉRDÉSE .................................................... 13 1.4 ÁTTEKINTÉS AZ AMI-VAL KAPCSOLATOS VEZETÉKNÉLKÜLI HÁLÓZATI TECHNOLÓGIÁKRÓL ............. 14 1.4.1 IEEE 802.11 (WLAN).................................................................................................................... 14 1.4.2 Bluetooth ....................................................................................................................................... 14 1.4.3 HiperLAN ...................................................................................................................................... 15 1.4.4 HomeRF ........................................................................................................................................ 15 1.5 A FREKVENCIA- ÉS TELJESÍTMÉNY-HASZNÁLATRA VONATKOZÓ MAGYARORSZÁGON ÉRVÉNYES SZABÁLYOZÁSOK .............................................................................................................................................. 16 1.5.1 A frekvenciasáv és kijelölésének eredeti célja............................................................................... 16 1.5.1.1

1.5.2 1.5.3 1.5.4 1.5.5 2.

Rádióberendezés megnevezése............................................................................................................ 17

Kötelezettségek RLAN berendezések használata esetén ................................................................ 19 RLAN berendezések üzembehelyezése........................................................................................... 19 RLAN berendezések használata..................................................................................................... 19 Szolgáltatás nyújtása RLAN berendezésekkel ............................................................................... 19

WIRELESS LAN HÁLÓZATOK............................................................................................................ 21 2.1 BEVEZETÉS A 802.11-BE ..................................................................................................................... 21 2.1.1 802.11b (Wi-Fi)............................................................................................................................. 21 2.1.2 802.11g.......................................................................................................................................... 21 2.1.3 802.11a (Wi-Fi5)........................................................................................................................... 21 2.1.4 802.11h.......................................................................................................................................... 21 2.1.5 802.11e.......................................................................................................................................... 21 2.1.6 802.11f........................................................................................................................................... 22 2.1.7 802.11i........................................................................................................................................... 22 2.1.8 802.1x............................................................................................................................................ 22 2.2 A 802.11B SZABVÁNY ÉS ANNAK HÁLÓZATI ELEMEI........................................................................... 22 2.2.1 Infrastruktúra mód ........................................................................................................................ 22 2.2.2 Ad Hoc üzemmód........................................................................................................................... 23 2.3 AZ IEEE 802.11 RÉTEGEK LEÍRÁSA .................................................................................................... 23 2.3.1 A PMD alréteg .............................................................................................................................. 24 2.3.2 A PLCP alréteg ............................................................................................................................. 25 2.3.3 A MAC áttekintése......................................................................................................................... 25

BZAKA

AmI Project

3.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata 2.3.4 2.4 2.4.1

A WaveLAN közeg-hozzáférési protokolljai .................................................................................. 26 VEZETÉKNÉLKÜLI HÁLÓZATTERVEZÉSI SZEMPONTOK ........................................................................ 27

Vezetéknélküli hálózati kiegészítők, antennatipusok ..................................................................... 27

2.4.1.1

2.4.2

2.4.2.1

2.4.3 2.4.4

WLAN antennatípusok........................................................................................................................ 27

Hálózattervezési eljárások ............................................................................................................ 28 Tervezési eljárás .................................................................................................................................. 29

Térképes adatbázis segítségével való tervezés .............................................................................. 30 Hot-spot gerinccsatlakozás ........................................................................................................... 31

2.4.4.1 2.4.4.2

Az elosztó rendszer megvalósításának lehetőségei.............................................................................. 31 A logikai szolgálatok interfészei ......................................................................................................... 31

2.5 802.11-ALAPÚ SZOLGÁLTATÁS BEVEZETÉSÉNEK TECHNOLÓGIAI KOCKÁZATAI ................................. 32 2.5.1 A 802.11 eszközök használatának biológiai kockázata ................................................................. 32 2.5.2 A 2.4 GHz ISM sávon üzemelő berendezések egymást zavaró hatása........................................... 33 2.5.3 Biztonsági kockázatok áttekintése ................................................................................................. 35 2.5.3.1 2.5.3.2

2.5.4

A biztonságos hálózatok nem mobilisak ............................................................................................. 36 A mobil hálózatok nem biztonságosak ................................................................................................ 36

Adatbiztonsági alapfogalmak ........................................................................................................ 38

2.5.4.1 2.5.4.2

Adatvédelmi szempontok a vezeték nélküli hálózatokban .................................................................. 39 Támadások .......................................................................................................................................... 40

2.6 A 802.11 PROTOKOLL VIZSGÁLATA .................................................................................................... 43 2.6.1 A javasolt vizsgálatok.................................................................................................................... 43 2.6.2 Vizsgálatok részletes leírása ......................................................................................................... 46 2.6.2.1

Az IEEE által javasolt konformancia vizsgálatok................................................................................ 46

2.7 SZIMULÁCIÓS VIZSGÁLAT ................................................................................................................... 48 2.7.1 Adatgyűjtő eszközök és hálózatelemzők......................................................................................... 48 2.7.1.1 2.7.1.2 2.7.1.3 2.7.1.4

2.7.2

OPNET [58] ........................................................................................................................................ 49 A COMNET modellezőeszköz [58] .................................................................................................... 51 A GLOMOSIM modellezőeszköz [54]................................................................................................ 52 NS – hálózati szimulátor [53].............................................................................................................. 53

Szimulációs eredmények................................................................................................................ 57

2.7.2.1 2.7.2.2 2.7.2.3 2.7.2.4 2.7.2.5

Zavarás két hop távolságra (Double Ring) .......................................................................................... 57 TCP instabilitás ................................................................................................................................... 59 Egyenlőtlenség (Unfairness)................................................................................................................ 61 Unfairness kialakulásához vezető topológia, 2. példa ......................................................................... 62 Értékelés.............................................................................................................................................. 66

2.8 MÉRÉSES VIZSGÁLAT .......................................................................................................................... 67 2.8.1 Irodalomkutatás ............................................................................................................................ 67 2.8.2 A BZAKA által, a projekt keretében kiépített mobil hálózat bemutatása ...................................... 71 Mérési összeállítás és mérési eredmények bemutatása ............................................................................... 74 2.8.2.1 2.8.2.2 2.8.2.3

2.8.3 3.

Mérési leírás a WLAN hatótávolságának és más paramétereinek megállapításához........................... 74 Mérések zárt környezetben.................................................................................................................. 75 Mérések nyílt terepen .......................................................................................................................... 79

Általános értékelés és konklúzió.................................................................................................... 89

BLUETOOTH ........................................................................................................................................... 90 3.1 BEVEZETÉS ......................................................................................................................................... 90 3.2 RENDSZERSPECIFIKÁCIÓ ..................................................................................................................... 91 3.2.1 Fizikai réteg: A Bluetooth rádiós interfész.................................................................................... 91 3.2.2 Bluetooth rádiós csatornák és piconetek....................................................................................... 92 3.2.3 Scatternet ...................................................................................................................................... 93 3.2.4 Kapcsolattípusok ........................................................................................................................... 95 3.2.5 CsomagTípusok ............................................................................................................................. 97 3.2.5.1 3.2.5.2 3.2.5.3 3.2.5.4 3.2.5.5 3.2.5.6

3.2.6 3.2.7 3.2.8

Bluetooth eszközök működési állapotai ....................................................................................... 103 Energiatakarékos üzemmódok..................................................................................................... 105 Protokollszerkezet ....................................................................................................................... 106

3.2.8.1 3.2.8.2

4.

A Bluetooth csomagokról általában..................................................................................................... 97 A csomagok szerkezete ....................................................................................................................... 98 Hozzáférési (access) kód ..................................................................................................................... 98 Fejrész (BB_header).......................................................................................................................... 100 Hasznos teher (Payload) .................................................................................................................... 101 Az adatátvitelre használható csomagtípusok ..................................................................................... 101

Szállítási protokollok......................................................................................................................... 107 Adoptált protokollok ......................................................................................................................... 108

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata 3.2.9 Magasabb szintű szolgáltatások, Profilok................................................................................... 110 3.3 SZIMULÁCIÓS VIZSGÁLAT........................................................................................................ 111 3.3.1 SZIMULÁCIÓS ESZKÖZÖK....................................................................................................... 111 3.3.1.1 3.3.1.2 3.3.1.3 3.3.1.4

3.3.2

BlueHoc............................................................................................................................................. 111 Blueware ........................................................................................................................................... 116 BT-Sim.............................................................................................................................................. 116 Bluetooth-sim .................................................................................................................................... 116

Szimulációs VizsgálaT................................................................................................................. 118

3.3.2.1 3.3.2.2

Eszközfelderítés ideje........................................................................................................................ 118 Csomagvesztés .................................................................................................................................. 119

3.3.3 Értékelés...................................................................................................................................... 120 3.4 MÉRÉSES VIZSGÁLAT ........................................................................................................................ 121 3.4.1 Családi házas környezetben végzett mérések .............................................................................. 121 3.4.2 OrszÁgÚton végzett mérések....................................................................................................... 123 3.4.3 Értékelés...................................................................................................................................... 124 4.

A JÖVŐ POTENCIÁLIS SZÉLESSÁVÚ KOMMUNIKÁCIÓJA..................................................... 125 4.1 IEEE 802.15.3 .................................................................................................................................. 127 4.1.1 A piconet fogalma és elemei........................................................................................................ 128 4.1.2 Alapműködések a piconetben. Indítás, csatlakozás, leállás ........................................................ 129 4.1.3 Hozzáférés a csatornához............................................................................................................ 129 4.1.4 A piconet irányításának átadása. Alárendelt piconetek .............................................................. 131 4.1.5 Energiagazdálkodás .................................................................................................................... 132 4.1.6 A fizikai réteg fő jellemzői........................................................................................................... 132 4.2 A 802.15.4 SZABVÁNY ...................................................................................................................... 133 4.2.1 Bevezetés ..................................................................................................................................... 133 4.2.2 802.15.4 Hálózati topológiák ...................................................................................................... 134 4.2.2.1 4.2.2.2

4.2.3

Csillag topológiájú hálózat kiépülése ................................................................................................ 135 Peer-to-peer topológiájú hálózat kiépülése........................................................................................ 135

A 802.15.4 architektúrája............................................................................................................ 136

4.2.3.1 4.2.3.2

A 802.15.4 fizikai rétege ................................................................................................................... 137 A 802.15.4 adatkapcsolati rétege....................................................................................................... 139

4.3 IEEE 802.16 ..................................................................................................................................... 140 4.3.1 A 802.16 MAC réteg.................................................................................................................... 142 4.4 IEEE 802.20 ..................................................................................................................................... 143 4.5 DEDICATED SHORT-RANGE COMMUNICATIONS (DSRC).................................................................. 144 5.

ÁLTALÁNOS ÖSSZEFOGLALÓ ÉS KÖVETKEZTETÉSEK ........................................................ 146

6.

IRODALOM ............................................................................................................................................ 148

7.

RÖVIDÍTÉSLISTA................................................................................................................................. 150

8.

ÁBRÁK JEGYZÉKE.............................................................................................................................. 154

9.

TÁBLÁZATOK JEGYZÉKE ................................................................................................................ 157

1.

SZ. MELLÉKLET: A MÉRÉSI KÖRNYEZET BEMUTATÁSA ..................................................... 158

BZAKA

AmI Project

5.


1. BEVEZETÉS A Bay Zoltán Alkalmazott Kutatási Alapítványon (BZAKA) belül az Ambiens Intelligencia (AmI) projekt csoport azzal a céllal kapott egyedi támogatást az Nemzeti Kutatási és Technológiai Hivataltól (NKTH), hogy a hazai távközlési kompetenciát szinergikus kapcsolatba hozza a hazánkban jelentősnek tekinthető – pélául a közlekedési rendszerek területén meglévő – egyéb kompetenciákkal. A jelen tanulmány és mérési beszámoló ezt a stratégiai küldetést szem előtt tartva készült. A Kutatás-fejlesztési Pályázati és Kutatáshasznosítási Iroda (KPI) és a BZAKA közötti OMFB-01105/2004 számú, 2004.11.22. keltezésű szerződés két feladatot ír elő. A 2.sz feladatról szóló szakmai beszámolót a BZAKA 2005.01.30.-én a KPI-nak benyujtotta. Az 1.sz. feladat az alábbiakat írja elő: 1. feladat: Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata. A járműveken használható kommunikációs protokollok közül elvileg több vezetéknélküli technológia is szóba jöhetne a vizsgálatok szempontjából. Ezek a következő szabványokban meghatározott technológiák: IEEE 802.11 (WiFi) 802.15 (WPAN) 802.16 (WiMax) 802.20. A 802.11 (WiFi) szabvány a nagysebességű vezetéknélküli helyi hálózatokat (WLAN) definiálja. A személyes környezetbeli vezetéknélküli hálózatokat (WPAN) leíró 802.15 szabvány több kisebb szabványból áll össze. Az IEEE 802.15.1 szabvány (Bluetooth) egy általános, alacsony költségű megoldást nyújt a kis hatótávolságú, vezetéknélküli, ad-hoc, rádiós adatátvitelre. A 802.15.3 (WiMedia) szabvány a szélessávú személyes környezetbeli vezetéknélküli hálózatokat írja le, míg az IEEE 802.15.4 (Zigbee) szabvány a keskenysávú szenzor hálózatokat definiálja. Az IEEE 802.16 szabvány fix hozzáférést biztosító vezetéknélküli szélessávú rendszert határoz meg, az IEEE 802.20 szabvány pedig egy nagy utazási sebességnél is szélessávú vezetéknélküli kommunikációt, biztosító rendszert definiál. Jelenleg azonban csak a WiFi és a Bluetooth szabványnak megfelelő eszközök megvásárolhatóak, a többi technológia még fejlesztés alatt áll. Gyakorlati megjelenésük legkorábban 2004. év végén várható. Ezért jelenleg csak: IEEE 802.15.1 (Bluetooth) IEEE 802.11 (WiFi) technológia hatékonyságának vizsgálatát tűzzük ki célul. A vizsgálatok mindkét technológia esetében kiterjednek az alábbiakra:

garantált hatótávolság, eszközfelderítés idő, csomagvesztés, késleltetés, késleltetés-ingadozás, átlagos átbocsátóképesség.

A fenti jellemzőket statikus környezetben és mozgó környezetben is vizsgálni fogjuk.

6.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata Jelen tanulmány és beszámoló a fenti feladat teljesítéseként készült. A szerkesztés folyamán célszerűnek tűnt a bevezetésben az alábbiakra kitérni: − egy, a konkrét feladat indokoltságát és aktualitását bemutató áttekintés (1.1 fejezet) − lehetséges „AmI” alkalmazások (1.2 fejezet) − a jelen tanulmány vezérfonalának, azaz a vizsgált vezetéknélküli hálózati technológiák alkalmazhatósági kérdésének rövid, vezetői összefoglalója (1.3 fejezet) − áttekintés az „AmI”-val kapcsolatos vezetéknélküli hálózati technológiákról (1.4 fejezet) − a Magyarországon érvényes, frekvencia- és teljesítmény-használattal kapcsolatos főbb szabályok áttekintése (1.5 fejezet). Jelen bevezető ezt az öt témát foglalja röviden össze. A további fejezetekben a tanulmány részletesen kifejti a vizsgált két vezetéknélküli protokoll (2. fejezet: IEEE 802.11 család; 3.fejezet: Bloetooth) műszaki jellemzőit, bemutatja az elvégzett méréseket, illetve szimulációkat és kiértékeli az eredményeket. Külön (4.) fejezetet szentelünk a jövőben számításba veendő, világszerte kidolgozás alatt álló szabványok és protokollok bemutatására és rövid elemzésére. A tanulmány végén (5. fejezet) figyelembe véve a potenciális alkalmazások legfőbb követelményeit, a mérésekkel és szimulációkkal megvizsgált, és a jövőben kidolgozásra kerülő vezetéknélküli hálózati technológiák felhasználhatóságára vonatkozó következtetéseket ismertetjük. Az 1.sz. melléklet a tanulmányban beszámolt mérések reprodukálhatóságához szükséges körülményeket írja le.

BZAKA

AmI Project

7.


1.1

A FELADAT INDOKOLTSÁGA ÉS AKTUALITÁSA

A vezetéknélküli hálózati technológiák alkalmazása napjainkban új, ígéretes távlatokat nyit a távközlés és az infokommunikáció által „áthatott” szektorok világában. A piacon különféle eszközök vásárolhatók, melyek számos kommunikációs szabványt alkalmazva hatékony vezetéknélküli kommunikációt biztosítanak. Napjainkban a vezetéknélküli kommunikációs technológiák egyre nagyobb teret nyernek a hálózati megoldások piacán. Ezen technológiák már képesek önszerveződő (ad hoc) hálózatok kialakítására is. Ugyanakkor nagy szerep jut a beépített autonóm szenzoroknak is, amelyek a fent említett hálózatba kötve igen hatékonynak bizonyulnak globális érzékelési feladatok megoldására. Az ilyen rendszereket Környezeti Intelligens Alkalmazásoknak (Ambient Intelligence Applications - AmI) is nevezik. A jelen tanulmány és mérési beszámoló célja annak vizsálata, hogy az AmI triviális alkalmazásai miként bővithetők, és a bővítésnek meg vannak-e a ma alkalmazott szabványok között a magvalósítási lehetőségei. Az AmI rendszereket számos területen alkalmazhatjuk. Az egyik, igen ígéretes terület a közlekedési rendszerekben talál helyet. A közúti forgalom túlzott növekedése miatt az autóbalesetek sajnos mindennapossá váltak, az enyhébb kimenetelűek jelentős anyagi károkat okozva a társadalomnak, míg a súlyosabb fajták emberéleteket is követelve. A balesetek számának csökkentésére egy lehetséges megoldás újabb útszakaszok építése, tehát a forgalom szétosztása. Ez a megközelítés nem gazdaságos, mivel a beruházások költségigénye magas, illetve a túlzsúfolt, nem hosszútávra tervezett régi infrastruktúrák gátolják az autóutak bővítését. Egy másik megközelítés olyan jármű-technológiák (AmI rendszerek) kifejlesztését célozza meg amelyek különböző elektronikus vezérlési rendszerekkel a vezető biztonságát, hatékonyságát és kényelmét kívánják javítani. A jármű vezérlési rendszere a különböző szenzorok által érzékelt, illetve a többi járműtől begyűjtött adatokra támaszkodik. Ilyen típusú rendszerek kutatása nemzetközi szinten az utóbbi években egyre nagyobb figyelmet kap, erre jó példa lehet a nemrég alakult Car-to-car Communication Consortium (C2CCC) [1], amelyet a nagy európai autógyártó cégek alapítottak 2004-ben. Ez a konzorcium főleg a már széles körben elterjedt IEEE 802.11 szabványt kívánja alkalmazni a járművek közötti kommunikáció megvalósításához. Az autógyárak számára elkerülhetetlen, hogy 5-10 (az elsők pedig akár már 1-2) éven belül az autók alapfelszerelésének részévé tegyék a modern kommunikációs képességeket. Azon autógyárak melyek ezen a területen élen járnak, piaci előnyre tehetnek szert. A kommunikációs képesség alkalmazása maga csak a kezdet, számtalan további – a fogyasztók számára is kézzelfogható előnyöket jelentő – szolgáltatás alapja. Az első lépések megtétele különösen fontos lehet az európai autógyártók számára, hiszen az utóbbi években egyre jobban kiéleződött a nemzetközi verseny, tekintve, hogy a japán autógyártók tovább növelték piaci részesedésük arányát. Egy ilyen eszköz beépítése nem jelent lényeges többletköltséget (kb. 1%).

8.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata Az AmI rendszerek, azaz az önszerveződő szenzor hálózatok a járműközlekedés területén észlelhető ígéretes alkalmazásokon kívül számos más területen is sikerrel kecsegtetnek, úgy, mint: − Intelligens műhely (erre alább mutatunk példát) , gyártósorok, áruház, stb. − Egészségügy − Katonai alkalmazások − Környezetvédelem − stb. 1.2

LEHETSÉGES „AMI” ALKALMAZÁSOK

A továbbiakban felsorolunk és röviden kifejtünk néhány alkalmazást, amelyek közül az 1.2.1.1, 1.2.1.2, 1.2.2.1, 1.2.3 fejezetben leírtakat a BZAKA AmI csoport kifejleszteni tervezi. Látható, hogy az alábbiakban kifejtett alkalmazások megvalósításához elengedhetetlen a vezetéknélküli hálózati technológia használata. A felsorolt alkalmazások többsége feltételezi azt, hogy mindegyik, a hálózatban résztvevő csomópont rendelkezzen mind a szokványos, mind az ad hoc típusú kommunikációhoz szükséges képességgel (GSM/UMTS, GPRS, WLAN, stb.). Ugyanakkor a járművek a saját földrajzi helyzetüket is meghatározhatják (pl. a GPS vagy GALILEO rendszerek használatával) és érzékelő szenzorok segítségével a környezet változásainak vagy a nem megfelelő környezeti körülmények észlelésére és ezen információk felhasználására valamint azok továbbítására is képesek. 1.2.1

JÁRMŰVEK KÖZÖTTI „AMI” ALKALMAZÁSOK (INTER-CAR)

1.2.1.1 Ráfutásos baleset-megelőzés Autópályákon a legtöbb baleset a meggondolatlan vezetési stílus miatt (szokatlan fékezések, sávváltások) illetve a túl hosszú vezetői reakcióidő (emberi tényező) miatt történik. AmI alkalmazásokkal a balesetek száma csökkenthető. Az autópályákon közlekedő járművek együttese dinamikus és önszervező (ad hoc) hálózatokként viselkedik, ezáltal lehetővé válik, hogy az autók közötti AmI kommunikáció segítségével (az információ járműről járműre történő továbbterjedésével) figyelmeztessük a járművezetőket az esetleges közelgő veszélyről, illetve, ha szükséges, akkor akár közbe is avatkozzunk a jármű irányításába.

1.2.1.2 Dinamikus tempomat Az autók sebességét állandó értéken tartó automatikus szabályozó berendezést már nagyon régen alkalmazzák főleg olyan országokban, ahol nagy távolságokat kell megtenni viszonylag zavartalan, kis forgalomban. Európai körülmények között, ahol az autópálya lehajtók és egyéb – a forgalom ütemét változtató – körülmények nem engedik meg a beállított, állandó sebességgel való autózást, ennél alkalmazkodóbb rendszerre van szükség. Ez az ACC (Adaptive Cruise Control), mely mára – bár magas áron, de – a piacon kapható. A rendszer magas árát legfőképp a radarberendezés költségességének a következménye.

BZAKA

AmI Project

9.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata Az „AmI technikákkal olcsóbb és nagyobb funkcionalitású megoldás valósítható meg. Amennyiben a járműveken a radar helyett kis hatótávolságú (100m - 1km) rádiókommunikációs eszközt használunk, úgy a jármű ennek segítségével felderíti környezetét. Az egy irányba haladó járművek felismerik, hogy egy ad hoc konvojban vannak és összehangolhatják sebességüket. Így minden jármű megbecsülheti a konvojban elfoglalt helyét, és súlyozni tud, hogy mely más járművek sebességéhez hangolja a sajátját. Ezáltal egy több résztvevős ráfutásos baleset abban az esetben is elkerülhető, amikor az ACC-vel felszerelt járművek képtelenek időben beavatkozni.

1.2.1.3 Forgalom-információ terjesztése/gyűjtése Ezen alkalmazások a városi közlekedést segítik. Olyan esetben, ha egy útszakaszon torlódás alakul ki, a kommunikációs képességgel rendelkező járművek ad hoc módon továbbítják az információt, mely egy központi forgalomirányítóhoz jutva, elősegíti a korai problémamegoldást (pl. közlekedési lámpák átállítása). A rendszer ad hoc jellegéből adódó újabb előny az, hogy a forgalommal kapcsolatos információk a közeledő (de a forgalmi torlódást még el nem érő) járművekhez is eljutnak, amelyek elkerülő utakat választhatnak.

1.2.1.4 Sürgősségi esetek (mentő-, tűzoltó-, rendőrautó) A nagy járműsűrűségű területeken nagyon fontos közlekedési előnyben részesíteni a sürgősségi esetekben használatos járműveket. AmI alkalmazás szemléletben ezen járművek ún. sürgősségi jelzést szórnak. A jelzés a kiválasztott útvonalon ad hoc módon terjedve, időben figyelmezteti a járművezetőket a magasabb prioritású jármű érkezéséről, átrendezve a forgalmat és így elősegítve annak előrehaladását.

1.2.1.5 Autópálya díjszedő rendszer értéknövelt szolgáltatásokkal Az autópálya díjszedő rendszerek infrastruktúrája egyúttal az AmI technológia közlekedési rendszerekben történő alkalmazásához szükséges infrastruktúrát is hordozza. Ezért az „AmI” technológia kis költség-többlettel képes az autópálya díjszedő rendszereket értéknövelt szolgáltatásokkal kiegészíteni.

1.2.1.6 Az útmentén elhelyezett AmI-csomópontok jelentősége Az AmI-képességekkel ellátott járművek számának ugrásszerű növekedése a tapasztalatok szerint akkor várható, ha az elérhető szolgáltatások mennyiségéből és minőségéből származó előnyök meghaladják a beruházáshoz szükséges gazdasági befektetések mértékét. Ezért az út menti AmI-csomópontok hálózatának kiépítése önmagán túlmutató jelentőséggel bír, hiszen katalizátorként hat e technológia általános elterjedésére, következésképpen a jármű-jármű kommunikáció egyes alkalmazásainak mihamarabbi térhódítására. Figyelembe véve, hogy Magyarország az Európai Unió erőteljes ösztönzése – és elsősorban pályázati keretek között megvalósuló anyagi támogatása – mellett éppen napjainkban új autópálya szakaszok építésével igyekszik behozni korábbi lemaradását, egyes nemzetközi kutatási együttműködésekben kulcsszerepet játszhatunk e technológia vizsgálatára alkalmas tesztkörnyezet kialakításával. Különösen igaz ez akkor, ha hozzátesszük, hogy e környezet kialakításának költségigénye eltörpül az új autópálya mintegy két milliárd forintos kilométerenkénti építési költségéhez képest.

10.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata Ugyanakkor azt is fontosnak tartjuk megjegyezni, hogy az ilyen típusú hálózat megvalósítását és az arra épülő szolgáltatások elterjedését megelőzően célszerű meghatározni az állami szerepvállalás feltételeit, a frekvenciahasználat leendő szabályait, illetve rögzíteni a közszolgálati és kereskedelmi szolgáltatások viszonyrendszerét. Készítendő tanulmányunk a konkrét szakmai feladatokon túl a fenti szempontokat is figyelembe veszi.

1.2.1.7 Környezeti viszonyok változásainak érzékelése és továbbítása Gyakran előfordul a közlekedési viszonyok hirtelen változása (közutak/autópályák jegesedése, ködös idő, átlagosnál erősebb széllökések), amelyek veszélyt jelentenek a közlekedő járművekre. A felmerülő veszélyek elhárítására használhatjuk az ad hoc hálózatokat. Például, ha egy jármű egy kritikus helyzetet (köd, tükörjég vagy baleset) érzékel, akkor a megfelelő információkat a veszélyes hely közvetlen környezetében tartózkodó összes közlekedési résztvevőnek továbbadhatja. Itt fontos szerepet játszhatnak az út menti útviszony-érzékelő szenzorok is, melyek információszórási képességgel rendelkeznek.

1.2.1.8 Felügyelt előzés A közúti baleseteknek nagy hányada a rosszul végrehajtott előzésekből származik. Az ilyen típusú balesetek számának csökkentésére kiválóan alkalmazhatóak az ad hoc rendszerek. A járművekben és az út mentén elhelyezett szenzorok és kommunikációs egységek által szolgáltatott információk (jármű koordinátái, a közel lévő járművek pozíciójának és sebességének pontos ismerete) értelmezésével biztonságosan meghatározható az, hogy egy előzés mennyi idő alatt kivitelezhető, valamint az hogy a tervezett előzés mennyire biztonságos. A rendszer közlekedésbiztonságot növelő hatása, csökkent látási viszonyok (ködös időjárás, kanyaros útviszonyok) esetén igen látványos lehet.

1.2.1.9 Gyermek-felügyelet a forgalomban Mindannyiunk számára fontos gyermekeink közúti biztonsága. A biztonságot segíti egy olyan rendszer használata, amelyben a gyermekek jelenlétét a közutakon kis adóteljesítményű rádiós egységekkel környezetünknek és a közlekedésben résztvevőknek jelezzük. Ilyen esetben megelőzhetjük az esetleges felelőtlen viselkedésekből adódó baleseteket (pl. közúton való nem megfelelő átkelést, növelve így a közúti biztonságot). 1.2.2

JÁRMŰVÖN BELÜLI „AMI” ALKALMAZÁSOK (INTRA-CAR)

1.2.2.1 „BAN” (Body Area Network) a járműben Napjainkban, elterjedőben vannak az ún. BAN hálózatok (Body Area Network), amelyek az emberi testen elhelyezett érzékelők (szívverés, légzés, stb. mérése) egymás közti kommunikációját teszik lehetővé. Ha ezeket, a szenzor hálózatokat rendszerbe szervezzük a járművek központi egységeivel (például vezetéknélküli technológiát alkalmazva), információt nyerve a vezető és a jármű utasainak jelenlegi állapotáról (fáradtság, stb.), csökkenthetjük az „egészségügyi” problémákból adódó közlekedési balesetek számát. Ha a rendszer alapos tesztek után is megbízhatónak bizonyul, és a jogi feltételek tisztázásra kerülnek, a jármű akár önálló döntést is hozhat a további tennivalókról és értesítheti az illetékes hatóságot (mentő-, rendőr-állomást).

BZAKA

AmI Project

11.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata 1.2.3

INTELLIGENS MŰHELY (SMART WORKSHOP)

A gyártási folyamatokban igen fontos szerepet játszik a lehető leghatékonyabb termelés mellett a dolgozók teljes biztonsága is. Ezek elősegítése számos módon, folyamatosan zajlik, de az eredmények és az új kihívások (pl. gyártósorok gyakori átrendezése, feladatváltás) azt mutatják, hogy van még tökéletesítési lehetőség. Mindezen új rendszerek megvalósíthatósága erősen függ az alkalmazott hálózati technológia jellemzőitől. A rendszer segítheti a gyártási folyamat optimalizálását azáltal, hogy például a dolgozók által ténylegesen használt közlekedési útvonalakat regisztrálja, miáltal támpontot ad a műhely átrendezésére. Ugyanakkor a munkadarab (például egy készülő porcelánszobor) mellé helyezett hő- és páratartalom-mérő szenzorokkal felszerelt „AmI” eszköz környezeti hőmérséklet és páratartalom adatok gyűjtésével optimális időpontban képes figyelmeztetni a műhelymestert a folyamatban lévő munkafázis (pl. festék száradása) időszerű teendőiről vagy az azoktól való eltérésről, csökkentve így a selejtgyártást és közvetve a termelési költségeket. Az élelmiszeriparban megkövetelt higiéniai szabályok biztosítása hasonlóan számos szenzorhálózatokra épülő AmI alkalmazást igényelhet. 1.2.4

INTELLIGENS OTTHON (ASSISTED LIVING)

Segítségre szoruló, idős vagy folyamatosan nagy szellemi terhelés alatt álló személyek életének támogatása és felügyelete is lehetséges az AmI technológiákkal. Az igen szerteágazó témában több ismert cég végez kutatást. Ilyen témakör például a járó/otthon kezelt betegek adatainak (testhőmérséklet, vérnyomás, EKG adatok, stb.) mérése, naplózása és valós idejű távmegfigyelése. A rendszer a betegek gyógyszeres és otthoni kezelésének időbeli ütemezését és ellenőrzését is támogathatja. Egy intelligens épületirányító-rendszer segítségével az ott tartózkodók mozgásának illetve jelenlétének figyelembe vételével hőmérséklet, páratartalom, fényviszonyok, épületőrzés/figyelés intelligens szabályozása végezhető.

12.

AmI Project

BZAKA


1.3

A TANULMÁNY VEZÉRFONALA: AZ ALKALMAZHATÓSÁG KÉRDÉSE

Mint azt már korábban említettük, az 1.2 fejezetben röviden bemutatott alkalmazások mindegyike feltételezi a vezeték nélküli kommunikációs technológia használatát. Ezen technológiai megoldások igénybe vétele nélkül ugyanis ezen alkalmazások lényegében nem megvalósíthatóak. Jelen tanulmány összeállításánál elsősorban a támogatási szerződésben megfogalmazott feladatokat vettük figyelembe, és arra törekedtünk, hogy a feladatban szereplő vezeték nélküli protokollokat a lehető legteljesebben jellemezzük (2. és 3. fejezet.) Ugyanakkor fontosnak tartottunk ezen túlmenően egy olyan áttekintést is nyújtani, amely bemutatja a jövőbeni szélessávú, nagy mobilitású, dinamikus vezeték nélküli hálózati technológiák alapjául szolgáló főbb fejlődési irányokat (5. fejezet). A tanulmány során mindvégig szem előtt tartottuk az 1.2 fejezetben bemutatott alkalmazások legfontosabb követelményeit. Ezért a kísérletekben szereplő szimulációk és mérések megtervezésének fázisában nagy súlyt fektettünk e követelmények legteljesebb kielégíthetőségének. A kísérletek elvégezésekor, illetve a kapott eredmények kiértékelésekor arra kerestünk választ, hogy a vizsgált technológiák az alkalmazások által megkövetelt előírásoknak mely peremfeltételek mellett és milyen mértékben képesek megfelelni. Az elemzésekben kiemeljük a két vizsgált vezeték nélküli protokoll előnyeit és hátrányait, valamint rámutatunk arra, hogy azok mely alkalmazáshoz, milyen hatékonysággal használhatók.

BZAKA

AmI Project

13.


1.4

ÁTTEKINTÉS AZ AMI-VAL KAPCSOLATOS HÁLÓZATI TECHNOLÓGIÁKRÓL

VEZETÉKNÉLKÜLI

Az utóbbi években a távközlés területén a vezeték nélküli adatátviteli technológiák gyors elterjedésének lehettünk tanúi. Ennek nyilvánvaló példája a mára mindennapok részévé vált mobiltelefónia. A hálózatok alapjául szolgáló protokollok, mint pl. a globális rendszer mobil kommunikációhoz (Global System for Mobile Communication, GSM) és a kódosztásos többszörös hozzáférés (Code Division Multiple Access, CDMA), csak viszonylag kis adatátviteli sebességet tesznek lehetővé, és alapvetően hangátvitelre alkalmasak. A hangátvitelre szolgáló protokollok mellett az elmúlt néhány évben szükségessé vált a hatékonyabb adatátvitelre használható protokollok kifejlesztése, vezeték nélküli környezetben. Megjelent az igény ugyanis a nagysebességű vezeték nélküli helyi hálózatok (Wireless Local Area Networks, WLAN) kiépítésére. Ezeket, a megoldásokat a vezeték nélküli hálózatok által nyújtott kényelem, kiépítésük és karbantartásuk egyszerűsége teszi vonzóvá. A növekvő igények kielégítésére folyamatosan egyre újabb, nagyobb adatátviteli sebességet lehetővé tevő, biztonságosabb protokoll szabványok jelennek meg. Ezek közül a jelentősebbek az IEEE (Institute of Electrical and Electronics Engineers) folyamatos fejlesztés alatt álló 802.11 sorozatú szabványai. Jelenleg a legtöbb piaci forgalomban kapható vezeték nélküli helyi hálózat kiépítésére alkalmas eszköz az IEEE 802.11b szabványon alapul. 1.4.1

IEEE 802.11 (WLAN)

Az IEEE 802.11 szabványon alapuló 802.11a, 802.11b (WIFI) és 802.11g által definiált protokoll ajánlások lehetőséget nyújtanak épületen belüli és azok közötti vezeték nélküli hálózatok kialakítására. Elterjedőben van otthoni, illetve nyilvános internet szolgáltatásra (hotspot) való alkalmazásuk. Megfelelő minőségű vezetékes kapcsolattal el nem látott területeken, ahol nem lehetséges digitális előfizetői vonal (Digital Subscriber Line, DSL) kiépítése, a nagysebességű lakossági és üzleti internet hozzáférésű hálózatok kiépítésére a legegyszerűbb alternatíva a 802.11 szabvány. Megvalósítása Magyarországon engedélyezéssel kapcsolatos feladatokat vet fel, amelyeket a 1.5 fejezetben részletezünk. 1.4.2

BLUETOOTH

A Bluetooth [4] kis teljesítményű rádiós technológia, amelyet azzal a céllal fejlesztettek ki, hogy helyettesítse a jelenleg használt vezetékes átvitelt az egymáshoz „közel” lévő elektronikus készülékek, például számítógépek, nyomtatók, digitális személyi asszisztensek (Personal Digital Assistant, PDA) és mobil telefonok között. E technológia alkalmas kis kiterjedésű helyi hálózatok kiépítésére is, bár elsődlegesen egy-egy eszköz összekapcsolására használják. A Bluetooth a 2.4GHz-es sávon működik. Ahhoz, hogy a Bluetooth-al felszerelt készülékek képesek legyenek 720kbit/s nagyobb sebességű adatcserére 10 méteresnél nem nagyobb körzetben, az interferencia elkerülése végett 1mW átviteli teljesítményt és frekvenciaugrásos kódolást használnak.

14.

AmI Project

BZAKA


HIPERLAN

Az Európai Távközlési Szabványügyi Intézet (European Telecommunications Standard Institute, ETSI) 1991-1996 között a nagyobb átviteli sebesség biztosítása érdekében kifejlesztette a nagysebességű rádiós helyi hálózatokat (High Performance Radio Local Area Network, HiperLAN) [5], hogy nagyobb átviteli sebességet tudjanak biztosítani a vezeték nélküli hálózaton, mint amit az IEEE 802.11 akkor tudott nyújtani (1-2 Mbps). A HiperLAN/2 egy továbbfejlesztés, amely aszinkron adatátvitelt és az időzítésre érzékeny szolgáltatásokat biztosít. 1.4.4

HOMERF

Az otthoni rádió frekvencia (Home Radio Frequency, HomeRF) [6] két szabványt kombinál – a 802. 11-et és a továbbfejlesztett, zsinór nélküli digitális távközlés (Digital Enhanced Cordless Telecommunication, DECT) hordozható telefon szabványt. A HomeRF frekvenciaugrásos technikát alkalmaz 1,6 Mbps sebesség elérésére, 300m távolságra a szabadban és 30m távolságra házon belül. Habár az ipari alkalmazások általában nagyobb távolságokat igényelnek, otthoni alkalmazások esetében a HomeRF ideális. 802.1

802.1

802.1

54

11

54

500

500

Frekvencia [GHz]

5

Kódolás

OFDM

Technológi

Hiper

Hiper

1

23.5

500

50

2.4

2.4

DSSS

OFDM

HomeR

802.15

802.16

54

10

55

155

100

500

50

50

100

2.4

5

5

2.4

3.1-

2-11

FHSS

OFD

OFDM

FHSS

OFDM

OFDM

Bluetooth

Sávszéles Távolság

1. táblázat: Különböző vezeték nélküli technológiák paraméterei

A fentebb bemutatott vezeték nélküli adatátviteli technológiák néhány tulajdonságát az [1] foglalja össze. Ezek a technológiák azonban még korántsem olyan kiforrottak, mint a vezetékes adatátvitelt biztosító szabványok. Fontos feladat tehát a vezeték nélküli hálózatok megbízhatóságának, teljesítőképességének és biztonságosságának továbbfejlesztése, annak érdekében, hogy a megbízható vezetékes hálózatokhoz szokott felhasználók magas minőségi igényeit kielégítsék.

BZAKA

AmI Project

15.


1.5

A FREKVENCIA- ÉS TELJESÍTMÉNY-HASZNÁLATRA VONATKOZÓ MAGYARORSZÁGON ÉRVÉNYES SZABÁLYOZÁSOK

A továbbiakban röviden bemutatjuk a WLAN hálózatok kialakítására vonatkozó Magyarországon érvényes szabályozásokat. (Itt lényegében [8]-at vettük alapul.) 1.5.1

A FREKVENCIASÁV ÉS KIJELÖLÉSÉNEK EREDETI CÉLJA

A 2400-2483,5 MHz frekvenciasávot kis hatótávolságú összeköttetések létesítésére jelölték ki. A sávban harmadlagos jelleggel üzemeltethetők a rádiós helyi hálózati (Radio Local Area Network, RLAN) berendezések. A harmadlagos jelleg azt jelenti, hogy a frekvenciasáv elsődleges és másodlagos jellegű felhasználói előnyt élveznek a harmadlagos használóval szemben. A harmadlagos felhasználóknak el kell tűrni az előnyt élvezők által okozott zavarásokat, ugyanakkor nem zavarhatják azokat. Megjegyzendő, hogy a Frekvenciasávok Nemzeti Felosztási Táblázata (FNFT), illetve a frekvenciasávok felhasználási szabályai szerint a sávban még több fajta kis hatótávolságú eszköz (Short Range Device, SRD), pl. távirányító, riasztó, stb. is működtethető harmadlagos jelleggel. A frekvenciasáv RLAN-nok használatára vonatkozó sávkijelölési szabályait az Európai Rádió-Távközlési Bizottság (European Radiocommunications Committee, ERC) 24 ország közöttük Magyarország - által elfogadott ERC/DEC/(01)07 számú, 2001. március 12-én hatályba lépett ERC Határozata tartalmazza. Az RLAN-nokra vonatkozó műszaki szabályokat Magyarországon a 6/2003. (III.31.) IHM rendelet tartalmazza. A rendelet rendelkezései kötelezők a felhasználók részére, amely szerint a fent nevezett frekvenciasávban: − az izotróp sugárzóra vonatkoztatott effektív kisugárzott teljesítmény (Effective Isotropic Radiated Power, EIRP) nem lehet nagyobb, mint: 100 mW; − a berendezések csak beépített (külső antenna csatlakozó nélkül) vagy a gyártó által a készülékhez szállított (dedikált) antennával használhatók; − a csatorna távolság és a kitöltési tényező nincs korlátozva; − a spektrális teljesítménysűrűség értéke: •

maximum 20 dBW/MHz (kiterjesztett spektrumú, közvetlen szekvenciális esetben);

•

10 dbW/100 kHz (kiterjesztett spektrumú, frekvenciaugrásos esetben);

− ajánlott szabványok: EN 300 328-1, EN 300 440-1. Tekintettel arra, hogy a harmadlagos jelleggel működő rádióalkalmazások (RLAN) védettséget nem élveznek más azonos sávú rádiószolgálattal szemben, a frekvencia használatáért frekvenciahasználati díjat nem kell fizetni, továbbá az ilyen jellegű rádióállomások használata az un. általános felhatalmazás körébe tartozik, üzemeltetésükhöz sem frekvenciakijelölési határozat, sem egyedi rádióengedély nem szükséges. Az RLAN berendezések frekvenciasáv felosztásának az eredeti célja az volt (2. táblázat), hogy megadja a lehetőséget az egymáshoz közel lévő, épületen vagy telephelyen belüli számítógépek vezeték nélküli, rádiós úton történő összekötésére. A frekvenciasáv felosztása után, a későbbiekben, túlmenően az eredeti célon, kiderült, hogy több kisebb hálózat összekapcsolásával egy rendszer hatósugara nagyobb területekre is kiterjeszthető és így az összekapcsolt számítógépekkel lehetővé vált Internet szolgáltatás nyújtása is. 16.

AmI Project

BZAKA


Rádióberendezés megnevezése

Teljesítmény

Megjegyzés

FNFT nemzeti lábjegyzet száma

2400—2483,5 MHz

Általános alkalmazású (távmérő, távirányító, riasztó, adatátviteli, videoátviteli és hasonló célú) kis hatótávolságú eszközök

10 mW EIRP

Kizárólag épületen belüli használatra

H38

2400—2483,5 MHz

Általános alkalmazású (távmérő, távirányító, riasztó, adatátviteli, videoátviteli és hasonló célú) kis hatótávolságú eszközök

2,5 mW EIRP

—

H38

2446,5—2483,5 MHz

Szélessávú adatátviteli alkalmazások

100 mW EIRP


H153

2400—2483,5 MHz

Szélessávú adatátviteli alkalmazások

10 mW EIRP


H153

2446—2454 MHz

Mozgásérzékelő és riasztó alkalmazások

25 mW EIRP

—

H154

Frekvencia vagy frekvenciasáv

2. táblázat: Magyarországon érvényes frekvencia-felhasználási szabályok

Az alábbi frekvenciasávban működő rádióberendezések esetében (3. táblázat) frekvenciakijelölési határozat kell az állomások telepítéséhez, valamint rádióengedély kell a berendezések üzemeltetéséhez. A frekvencialekötés illetve frekvenciahasználat után díjat nem kell fizetni. A berendezések forgalomba hozatala előtt a hatósági nyilvántartásba kell vetetni a készüléket. Frekvencia vagy frekvenciasáv

5725—5850 MHz

FNFT*

1.5.1.1 Rádióberendezés megnevezése A sávban az állandóhelyű szolgálat keretében harmadlagos jelleggel (nem tarthatnak igényt védelemre az elsődleges és másodlagos rádiószolgálat rádióállomásai által okozott káros zavarásokkal szemben) kiskapacitású (legfeljebb 2 Mbit/s) digitális kiterjesztett spektrumú pont-pont rendszerek rádióberendezései részére is kijelölhető frekvencia. Kapacitás: max. 2 Mbit/s. Jelfeldolgozási nyereség: min. 10 dB EIRP maximum: ha L ≥ 30 km, akkor EIRP maximum = 21 dBW ha L <30 km, akkor EIRP maximum = (6 + 0,5L) dBW ahol L az áthidalt távolság km-ben

lábjegyzet száma

H166

3. táblázat: Frekvenciakijelölési határozatot igénylő rádióberendezések

A kérelmeket a Hírközlési Területi Hivatal (HTH) budapesti irodájához kell benyújtani. Minden kérelemnek tartalmaznia kell a következőket:

BZAKA

AmI Project

17.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata − a kérelmező nevét, telephelyének címét, levelezési címét, az ügyintéző nevét, telefonszámát, a Hírközlési Felügyelet nyilvántartási számát (ha van); − amennyiben a kérelmező az eljárás lefolytatásával megbíz valakit, akkor a megbízólevél eredeti példányát; − okirat módosításához vagy megszüntetéséhez az eredeti okiratot; − a kérelmező cégbírósági bejegyzésének – másolatát 1; − adóazonosító jelét vagy adószámát 1; − egy számla számát (bankszámlaszámát), amelyről a használati díjakat fogják fizetni 1. − Az illetékről szóló 1990. évi XCIII. törvény szerinti (2000 Ft értékű) illetékbélyeget, vagy a leendő Engedélyes illetékmentességéről szóló nyilatkozatát, igazolását. A frekvenciakijelölési határozat kiadására vonatkozó kérelemnek az általános részben ismertetetteken túl a következőket kell tartalmaznia: − a frekvenciaengedélyezési terv 2 eredeti példányát; − az állomás, berendezés, antenna és engedélyes adatlapokat a megadott formában floppy lemezen, az adatszolgáltatás folyamán az ékezetes magyar nagybetűk használata kötelező valamint figyelembe kell vennie a felhasznált berendezések és antennák kötött karakteres megadását; − a frekvenciaengedélyezési tervet csak a Mérnöki Kamara mikrohullámú hálózatok / rendszerek tervezésére feljogosító engedéllyel rendelkező tervező készíthet; − a tervező – számításokkal alátámasztott – nyilatkozatát a sugár-egészségügyi követelmények betartásáról. A rádióengedély kérelemnek az általános részben ismertetetteken túl a következőket kell tartalmaznia: − a használatbavételi eljárás jegyzőkönyvének másolatát; − az engedély megszüntetés esetén a berendezések sorsát, igazoló nyilatkozatot; − közcélú hálózat létesítőjének/üzemeltetőjének nyilatkozatát a magasságkorlátozás bejegyzéséről, illetve ennek hiányában a később esetlegesen bekövetkező minőségromlás tudomásul vételéről; a magasság korlátozás ingatlan nyilvántartásba történő bejegyzése csak a közcélú hálózat üzemeltetői részére engedélyezhető. − a telephely tulajdonosának nyilatkozatát, amelyben hozzájárul a berendezés és az antenna telepítéséhez; − az üzembe helyező mérési jegyzőkönyvét vagy nyilatkozatát arról, hogy a hálózat üzembe helyezése a frekvenciakijelölési határozatnak, illetve az ott fel nem sorolt paraméterek esetében a rendszertechnikai tervnek megfelelően történt; − ha a frekvenciakijelölési határozat meglévő rádióhálózat módosításához kapcsolódik, akkor a rádióengedély eredeti példányát. − A hálózatban csak igazolt megfelelőségű rádióberendezés használható. 1

Csak olyan kérelmezőnek kell megadni, aki nem rendelkezik érvényes frekvenciakijelölési határozattal vagy rádióengedéllyel.

18.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata Az Európai Bizottság 2003. március 20-án kiadott 2003/203/EC számú ajánlása (Official Journal L 078, 25/03/2003 P. 0012-0013) támogatja a nyilvános, üzleti és nem üzleti célú RLAN szolgáltatásokat. Javasolja a tagországoknak, hogy mellőzzék az RLAN berendezések egyedi engedélyezését, de ugyanakkor felhívja a figyelmet az 1999/5/EC, rádió- és telekommunikációs terminálokra vonatkozó előírások (Radio & Telecom Terminal Equipment Directive, R&TTE) betartására. 1.5.2

KÖTELEZETTSÉGEK RLAN BERENDEZÉSEK HASZNÁLATA ESETÉN

Az RLAN berendezésekkel történő Internet szolgáltatás nyújtása kötelezettségekkel jár, amelyek teljesítését a hírközlési hatóság (Hírközlési Területi Hivatal, HTH) szigorúan megköveteli és azok betartását folyamatosan, ellenőrzi rádióellenőrzési és piacfelügyeleti tevékenysége során. A kötelezettségek az alábbiakra terjednek ki: − berendezések forgalomba hozatala és forgalmazása; − berendezések üzembe helyezése és üzemben tartására; − szolgáltatás nyújtása. 1.5.3

RLAN BERENDEZÉSEK ÜZEMBEHELYEZÉSE

A kereskedelemben beszerzett berendezéseket úgy kell üzembe helyezni, ahogy az a gyártó által megadott használati-kezelési útmutatóban le van írva. Különösen vonatkozik ez az antennák használatára, ahol a megadott beépített (integrált) vagy a készülékkel együtt szállított (dedikált) antenna helyett nem szabad mást használni, ugyanis nagyobb nyereségű antenna alkalmazásával könnyen túl lehet lépni a megengedett kisugárzott teljesítményeket. Ha valaki az alapvető követelményeket, befolyásoló változtatásokat vagy bővítéseket végez az RLAN berendezésén – ide tartozik egy nagyobb nyereségű antenna vagy végerősítő berendezés használata is – gyártónak tekintendő és ezért minden felelősséget vállalnia kell. Ez azt jelenti, hogy az üzemeltetőnek – többek között – kötelessége lefolytatnia egy új megfelelőségi eljárást, a megváltoztatott berendezés új paramétereivel, azonban nem lesz esélye megfelelősséget bizonyítania, ha az állomás paraméterei meghaladják az előzőekben említett ERC Határozat 1. számú mellékletében megadott követelményeket. 1.5.4

RLAN BERENDEZÉSEK HASZNÁLATA

Amint arról már volt szó, az RLAN berendezések használatához egyedi rádióengedély nem szükséges. Az ilyen berendezések használata az általános felhatalmazás körébe tartozik. Ugyanakkor fontos szabály, hogy csak az a rádióberendezés tartható üzemben, amely teljesíti a forgalomba hozatalra vonatkozó külön jogszabályban meghatározott követelményeket. Rádióberendezést üzemben tartani csak olyan állapotban szabad, ahogy azt forgalomba hozták (2/2001. (I.31.) Miniszterelnöki Hivatalt Vezető Miniszteri (MeHVM) rendelet 15.§). 1.5.5

SZOLGÁLTATÁS NYÚJTÁSA RLAN BERENDEZÉSEKKEL

Ha Magyarországon valaki szolgáltatást akar nyújtani, azt a HTH Budapesti Irodánál be kell jelenteni a szolgáltatás nyújtásának megkezdése előtt legalább harminc nappal. A szolgáltatást a HTH Budapesti Iroda akkor veszi nyilvántartásba, ha a bejelentés minden feltétele teljesül, ellenkező esetben hiánypótlásra szólít fel. A bejelentésnek - többek között - tartalmaznia kell:

BZAKA

AmI Project

19.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata − vállalkozás és szakirányú képesítés igazolását; − a hatósággal kapcsolattartó személy adatait és elérhetőségét; − a szolgáltatásra alkalmas hálózat adatait és a felhasznált berendezéseket, továbbá a bejelentésre kötelezett berendezések forgalomba hozatalának bejelentéséről szóló határozat számát; − a hálózat interfészeit; − általános szerződési feltételeket; − ügyfélszolgálat működtetését. A bejelentés céljára készített formanyomtatvány a 252/2001. (XII.18.) Kormányrendelet mellékletében található. Nyilvánosság számára biztosított szolgáltatás esetén mellékelni kell a szolgáltatásra vonatkozó Általános Szerződési Feltételeket. Tekintettel arra, hogy az RLAN Internet szolgáltatás során a frekvenciasáv használata harmadlagos, továbbá, hogy az egymás zavarásának a veszélye is fennállhat, kívánatos, hogy az RLAN szolgáltatók – saját érdekükben is – figyelmeztessék ügyfeleiket a szolgáltatás bizonyos eseteiben előforduló korlátozottságokról. Amennyiben a hálózat interfészeinek adatai nem szerepelnek a HTH nyilvántartásában, az alkalmazott interfészeket be kell jelenteni a 26/2001. (XII.22.) MeHVM rendelet szerint.

20.

AmI Project

BZAKA


2. WIRELESS LAN HÁLÓZATOK 2.1

BEVEZETÉS A 802.11-BE

E fejezet szándéka az, hogy általános áttekintést nyújtson a WLAN szabványokról. Az IEEE 802.11 rádiós szabványok meghatároznak egy levegőn keresztüli (over-the-air) interfészt a rádiós kliens és a bázisállomás, vagy a hozzáférési pont között, akárcsak a rádiós kliensek között. A 802.11 szabványok hasonlíthatóak az IEEE 802.3 Ethernet szabványához. Definiálják úgy a fizikai (Physical, PHY) mind a közeghozzáférés vezérlés (Media Access Control, MAC) réteget, és úgy vannak kialakítva, hogy megoldják a kompatibilitás kérdését a WLAN felszerelések gyártói között. 2.1.1

802.11B (WI-FI)

A 802.11b, vagy vezetéknélküli torzításmentesség (Wireless Fidelity, Wi-Fi), a mai IEEE WLAN szabvány, ami a 2.4 GHz frekvenciasávon működik. A fizikai réteg a közvetlen sorrendű szórt spektrumon (Direct Sequence Spread Spectrum, DSSS) alapul és az adatcsere akár 11 Mbits/s sebességű is lehet, 100 méteres hatótávolságon. 2.1.2

802.11G

A 802.11g szabvány egy olyan technológiát definiál 2.4 GHz sávon, ami nagyobb adatsebességet nyújt (54 Mbps értékig) ortogonális frekvenciaosztásos nyalábolást (Orthogonal Frequency Division Multiplexing, OFDM) használva, úgy, hogy kompatibilis marad a 802.11b-vel. 2.1.3

802.11A (WI-FI5)

A 802.11a egy nagy teljesítményű IEEE WLAN szabvány, ami az 5 GHz-es frekvenciasávon működik, OFDM moduláción alapuló fizikai rétegre épül és 54Mbps-nál nagyobb sebességű adatátvitelt szolgáltat. A 802.11a nem kompatibilis a 802.11b-vel és használata Magyarországon csak engedély beszerzésével lehetséges (lásd 1.5). Az IEEE a 802.11b/a WLAN szabványok további fejlesztésén dolgozik. A továbbiakban röviden bemutatjuk a legfontosabb új javaslatokat. 2.1.4

802.11H

A 802.11h szabvány a MAC réteget egészíti ki úgy, hogy az megfeleljen az európai előírásoknak az 5GHz-es frekvencián működő WLAN-ok terén. Az európai előírások megkövetelik, hogy az eszközök sugárzási teljesítmény vezérlését (Transmission Power Control, TPC) biztosítsák, valamint a dinamikus frekvenciaválasztást (Dynamic Frequency Selection, DFS) is támogassák. A TPC korlátozza a kimenő teljesítményt egy olyan értékre, mellyel még elérhető a legtávolabbi felhasználó is. A DFS kiválasztja azt a csatornát, amelyen a más rendszerekkel való interferencia minimális. 2.1.5

802.11E

Elsődleges célja az interoperabilitás megvalósítása a különböző 802.11x szabványok között, a 802.11 MAC kiegészítése a szolgáltatásminőség biztosításával (Quality of Service, QoS) és különböző szolgáltatás osztályok (Class of Service, CoS) definiálása.

BZAKA

AmI Project

21.


802.11F

Célja olyan szabvány létrehozása, amely a hozzáférési pontok közötti protokoll (Inter-Access Point Protocol, IAPP) ajánlásait tartalmazza. Az IAPP azon szükséges képességeket szolgáltatja, melyek lehetővé teszik különböző gyártók hozzáférési pontjainak együttműködését egy 802.11 WLAN linkekből álló elosztó rendszerben. 2.1.7

802.11I

A 802.11i szabvány a 802.11 MAC réteget javított biztonsággal és hitelesítési mechanizmussal egészíti ki. Az új szabvány a továbbfejlesztett titkosítási szabvány (Advanced Encryption Standard, AES) technológiáját használja és két új protokoll segítségével a 802.11 eszközök biztonságát növeli. A Wi-Fi-védett hozzáférést (Wi-Fi Protected Access, WPA) biztosító technológia segítségével a vezeték nélküli kommunikáció két dinamikusan generált 128 bites kulccsal tehető biztonságosabbá (a jelenlegi 802.11 szabványok csak egy 128 bites statikus kulcsot használnak). A protokollok kidolgozása lezárult, így a chipgyártók megkezdhetik az alkatrészek fejlesztését és tesztelését. 2.1.8

802.1X

A 802.11x egy kiterjeszthető és biztonságos hitelesítési protokoll, amely bármilyen típusú helyi hálózat (Local Area Network, LAN) fölött fut, beleértve rádiós és vezetékes hálózatokat. A létező hot-spotokkal és hitelesítési rendszerekkel való korlátozott együttműködés miatt a 802.1x a magánhálózatokban a legelterjedtebb. A 802.1x szabvány széles körű elfogadásához a hozzáférési technológiák új generációjának kifejlesztése szükséges. 2.2

A 802.11B SZABVÁNY ÉS ANNAK HÁLÓZATI ELEMEI

Az IEEE 802.11b (Wi-Fi) szabvány, mint az összes IEEE 802 jelű szabvány, a közeghozzáférés-vezérlési (MAC) és a fizikai (PHY) rétegeket definiálja. Kétfajta működésmódot támogat: az infrastruktúra üzemmódot, amelynél egy központi állomás vezérli a hozzáférést a hálózathoz; illetve az ad hoc üzemmódot, amelynél semmiféle fix infrastruktúrára nincs szükség. Ezeknek, az üzemmódoknak megfelelően a szabvány kétféle közeghozzáférési módot definiál: az elosztott irányítási funkciót (Distributed Coordination Function, DCF) és a központi irányítási funkciót (Point Coordination Function, PCF). 2.2.1 INFRASTRUKTÚRA MÓD Infrastruktúra módban egy celluláris hálózat épül fel, ahol a cellákat a szabvány alapszolgáltatási rendszernek (Basic Service Set, BSS) hívja (lásd 1. ábra). Minden BSS-t egy hozzáférési pont (Access Point, AP) vezérel. A hozzáférési pont feladata, hogy a csomópontokat periodikusan lekérdezve (polling) a csomagküldéseket ütemezze a hálózatban. A hozzáférési pontok egymáshoz akár vezetékes (tipikusan Ethernet), akár vezeték nélküli hálózattal kapcsolódhatnak. Ezeket a cellákat összekapcsoló hálózatot hívja a szabvány elosztó hálózatnak (Distribution System, DS). A teljes, több cellából álló hálózat neve kiterjesztett szolgáltatási hálózat (Extended Service Set, ESS).

22.

AmI Project

BZAKA


1. ábra: BSS-ből álló infrastruktúra hálózat

2.2.2

AD HOC ÜZEMMÓD

Az ad hoc üzemmódban működő hálózatban az IEEE 802.11b szabvány szerint minden csomópont közvetlenül tud kommunikálni a rádiós interfész hallótávolságán belül levő csomópontokkal (2. ábra). A távolabbi csomópontok közötti kommunikációt a speciális ad hoc útvonalválasztó protokollok teszik lehetővé. A hálózatot alkotó csomópontok e protokollok segítségével maguk gondoskodnak a hálózat feltérképezéséről és az útvonalválasztásról, illetve a csomagok továbbításáról. Ezekben a hálózatokban tehát minden állomás egyben útvonalválasztó (router) is lehet, ahol a távoli csomópontok között kiépült folyamok csomagjait a közbeeső csomópontok továbbítják. Az ilyen hálózatokat ezért többugrásos (multihop) ad hoc hálózatoknak nevezik.

2. ábra: Ad hoc hálózat

Az ad hoc hálózatok kifejlesztésével lehetővé vált egy mobil hálózat igen gyors, minden előkészítés nélküli felállítása. Ez jól alkalmazható olyan helyzetekben, ahol egy ideiglenes hálózatot kell rövid idő alatt, minél egyszerűbben felépíteni, például egy rendezvény vagy konferencia résztvevőinek hálózatba kapcsolására. Ad hoc hálózatok alkalmazása célszerű lehet mentőalakulatoknál, rendőrségi, katonasági vagy tűzoltósági hálózatoknál, vagy várótermekben is. 2.3

AZ IEEE 802.11 RÉTEGEK LEÍRÁSA

A 802.11 szabvány [1] a fizikai réteggel illetve az adatkapcsolati rétegben lévő közeghozzáférési alrétegével foglalkozik (lásd 3. ábra). A fizikai réteget két alréteg alkotja: a Physical Layer Convergence Procedure (PLCP) és a Physical Media Dependent (PMD) alréteg. A PMD határozza meg a vett és az adott jel fizikai tulajdonságait és az átviteli közegnek megfelelő modulációs eljárást. A PLCP a MAC-től kapott adatot menedzsment információkkal látja el, keretbe foglalja és illeszti a közegtől függő rendszerhez. Ezeket az alrétegeket a következő alfejezetekben bővebben tárgyaljuk. BZAKA

AmI Project

23.


3. ábra: Az IEEE 802.11 referencia modellje

2.3.1

A PMD ALRÉTEG

A PMD alréteg ismertetésénél fontos megjegyezni, hogy az IEEE 802.11 szabvány három átviteli közeget támogat (infra, optikai, rádiós és mikrohullámú) [1]. Az infra/optikai rendszer, továbbiakban InfraLAN, a száloptikai linkekhez hasonló frekvencián dolgozik. Fényspektrumot használ, így nem kell a működéshez szükséges engedélyeztetés, nincs frekvenciakorlát, ami nagyobb átviteli sebességet és sávszélességet jelent. Az infraoptikai vevő csak a jel amplitúdóját érzékeli, ami hatékonyan csökkenti az interferenciát, de a napfény és egyéb fényforrások interferencianövelő tényezőként hatnak. További hátrány, hogy az adó és a vevő egységeknek közvetlenül “látniuk” kell egymást(a közéjük eső tárgyak (falak) megszakíthatják a fény útját). A mikrohullámú rendszer, továbbiakban RadioLAN, az 5.8 GHz frekvencián üzemel. Ezért a rendszer keskenysávú, egy frekvenciás modulációt használ. Mivel szórt spektrumú eljárásokat nem alkalmaz, így ebből fakadó többletinformáció nem biztosított és nagy átviteli sebesség érhető el vele. A rádiófrekvenciás rendszer a WaveLAN. Átviteli sebessége alacsonyabb, az InfraLAN vagy a RadioLAN sebessége. Ez a tulajdonság a szórt spektrumú eljárások használatának következménye. Ezzel a különleges módszerrel a 2.4 GHz-es frekvenciasávban fellépő zajok, zavarok hatását próbálják csökkenteni. A rádiófrekvenciás rendszereknél alkalmazott speciális átviteli technikák közül az egyik az FHSS (Frequency Hoping Spread Spectrum), vagyis a frekvenciaugrásos szórt spektrum (1 Mbps, 2 Mbps). Az eljárás lényege, hogy a felhasználható frekvenciatartományt 75 darab 1 MHz-es alcsatornára osztották. A rendszer kevesebb, mint 400 ms időközönként vált alcsatornát egy véletlenszerűen, de előre meghatározott sorrend szerint (pszeudorandom). Ez a módszer a kommunikáció lehallgatását idegen szereplő számára nagymértékben megnehezíti, ráadásul a nemkívánatos zajok hatását is lecsökkenti. A másik módszer a DSSS (Direct Sequence Spread Spectrum), vagyis a direktszekvenciális spektrumszórás (1 Mbps, 2 Mbps, 5.5 Mbps, 11 Mbps). Ennél a frekvenciasávot 25 MHz-es vagy 5 MHz-es csatornákra bontották. Az egy rendszert alkotó egységek csak egy csatornán kommunikálnak. Az átvitt jelet egy bináris álvéletlen sztringgel, a szórókóddal modulálják úgy, hogy a biteket ráképezik egy chipsorozatra. A szórási arány az egy bitet reprezentáló chipek száma. Minél magasabb a szórási arány, annál ellenállóbb a jel az interferenciával szemben, illetve minél alacsonyabb ez az arány, annál nagyobb sávszélességet vehet igénybe a felhasználó. A WaveLAN esetén a szórási arány 11. Az IEEE 802.11 többféle modulációs eljárást ír elő. Az alapszabvány FHSS esetén 1 Mbps-ra a 2FSK (kétállapotú Frequency Shift Keying), 2 Mbps-ra a 4FSK (négyállapotú Frequency Shift Keying), DSSH esetén 1 Mbps-ra a BPSK (Binary Phase Shift Keying), 2 Mbps-ra a QPSK (Quadrature Phase Shift Keying), a 802.11a kiegészítés 5 GHz-es sávjában az OFDM (Orthogonal Frequency Division Multiplexing), a 802.11b kiegészítés

24.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata 5.5 Mbps-os és a 11 Mbps-os névleges átviteli sebességére a CCK (Complementary Code Keying) alkalmazását teszi kötelezővé. 2.3.2

A PLCP ALRÉTEG

Amint már utaltunk rá, a PLCP alréteg a MAC által küldött adatot a közegtől függő PMD-hez illeszti. A PLCP keret részei: az előtag, a fejrész, a MAC adatelem és az ellenőrző összeg [1]. A különböző átviteli technikákhoz más és más keret tartozik. A MAC adaton kívüli részt minden esetben 1 Mbps sebességgel küldik ki, hogy a kompatibilitást visszafelé is biztosítsák.

4. ábra: A PLCP keret FHSS esetén

5. ábra: A PLCP keret DSSS és HR/DSSS esetén

Szórt spektrumú eljárások esetén a PLCP keret hasonló felépítésű, a MAC adatot nem követi toldalék. Az SYNC (Sychronization) mező a keretszinkronszót tartalmazza, az SFD (Start Frame Delimiter) a keretidőt definiálja. A fejrészben az FHSS-nél (4. ábra) a PLW (PSDU length word) a MAC adatelemet alkotó oktettek számát, a PSF (PLCP Signaling Field) az adatátviteli sebességet határozza meg 1 Mbps-tól 4.5 Mbps-ig, 0.5 Mbps lépésközzel. A DSSS-nél (5. ábra) a SIGNAL az adatátviteli sebességet ('0X0A' - 1 Mbps '0X14' -2 Mbps, '0X37' - 5.5 Mbps,'0X6E' - 11 Mbps ), a LENGTH a MAC adatelem hosszát adja meg, a SERVICE-t későbbi használat számára foglalták le. 2.3.3

A MAC ÁTTEKINTÉSE

A továbbiakban az adatkapcsolati réteg MAC szintjének keretfelépítéséről lesz szó. A MAC keret három fő részből áll: a fejrészből, a kerettestből és a keret ellenőrző összegből (FCS – Frame Check Sequence), ahogy azt a 6. ábra szemlélteti.

6. ábra: A MAC keret felépítése

BZAKA

AmI Project

25.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata A fejrész 30 bájtos és 7 mezős, ezek a keretvezérlő, az adási időtartam, a cím1, a cím2, a cím3, a szekvencia vezérlő és a cím4 mező. A keretvezérlő 2 bájtos és 11 almezőt tartalmaz.

7. ábra: A keretvezérlő mező felépítése

A 2 bit méretű protokollverzió azonosítja a 802.11 szabvány verzióját. A 2, illetve 4 bit hosszúságú típus és altípus a keret funkcióját határozza meg. A további 8 mező mindegyike 1 bites. A To DS mező értéke 1, abban az esetben ha a keret belép egy osztott rendszerbe, a From DS 1 értékű, ha elhagyja az osztott rendszert. A More Frag 1, ha tördelés történt, és a MAC adatelem következő töredékéről van szó. A Retry 1, ha újraküldték a keretet. A Pwr Mgt 1, ha az állomás energiatakarékos üzemmódban van. A More Data 1, ha az állomás számára további adatelemeket tároltak el. A WEP 1, ha titkosítás történt. Az Order 1, ha a keretek sorrendje fontos. 2.3.4

A WAVELAN KÖZEG-HOZZÁFÉRÉSI PROTOKOLLJAI

A WaveLan rendszer már előzőekben is bemutatott közeg-hozzáférési módszereit a CSMA/CD és a CSMA/CA csatorna-hozzáférési protokollok biztosítják [1]. Optimális esetben, ha egyetlen adóállomás kíván forgalmazni, akkor egyszerűen megtörténik az átvitel az adó és vevő között. Ha azonban, és ez a gyakoribb eset, több állomás is egyszerre szeretne adni ezen a csatornán, akkor ütközés fog fellépni. Ez késleltetést okoz, mert miközben egy időrés eltelik, hasznos forgalom nem megy át a csatornán. A CSMA/CD protokoll a hasonló ütközésekett próbálja felderíteni a küldés előtt és, s megtörtént ütközés esetén, az újraküldést menedzselni. A küldő először belehallgat a csatornába. Ha szabad, akkor adni kezd, ha nem, akkor egy véletlen számot (Random Backoff) választ egy adott intervallumból mely az újraküldés elütti várakozás idejét adja.(ez a sikertelen kísérletek hatására növekedni fog). A CSMA/CA hatékonyabban kezeli az ütközéseket, a rejtett csomópont problémára is megoldást nyújt, valamint kiküszöböli az állomások közötti interferenciát. Minden sikeres adatátvitelt a keretek közötti adott idő (Inter Frame Space – IFS) eltelte után a versengés szakasza követ, ami megegyezik a CSMA/CD módszernél leírtakkal. Ha a következő időrésben a csatorna szabad, akkor ellentétben a CSMA/CD-vel, adat helyett egy RTS (Request to Send) üzenetet küld az adó, amelyre a vevőtől egy CTS választ vár.A sikeres kapcsolatfelépítés az adatátvitel megkezdédének előfeltétele. A vevő,CRC ellenőrzés után nyugtát (Acknowledge -ACK) küld. Ez az úgynevezett RTS/CTS mechanizmus (8. ábra). Az első generációs WaveLAN implementációk még nem alkalmazták az RTS/CTS nyugtázásos eljárást.

8. ábra: Az RTS/CTS mechanizmus üzenetei

26.

AmI Project

BZAKA


9. ábra: A CSMA/CA protokoll szakaszai

A csatorna-hozzáférés prioritását a 802.11 szabvány a keretek közötti időköz (Inter Frame Space – IFS) változtatásával szabályozza. Az IFS ugyanis az a minimális idő, amit az állomás a csatorna-felszabadulás érzékelését követően vár. Minél kisebb az IFS, annál nagyobb a prioritás. Ennek alapján négy szint különböztethető meg: rövid IFS (Short Inter Frame Space SIFS), pont koordinációjú IFS (Point Coordination IFS - PIFS), osztott IFS (Distributed IFS DIFS), kiterjesztett IFS (Extended IFS -EIFS), ezek viszonyát a 9. ábra mutatja. 2.4

VEZETÉKNÉLKÜLI HÁLÓZATTERVEZÉSI SZEMPONTOK

A legegyszerűbb és a leghatékonyabb vezetéknélküli hálózat az, ha egy kliens kommunikál a hozzáférési ponttal úgy, hogy „látóhatáron belül” vannak és nincs adaptív zaj a csatornán. Sajnos ezt kivételes esetektől eltekintve biztosítható. A felhasználóknak meg kell osztaniuk a hozzáférési közeget, így zavarok léphetnek föl a csatornán, és előfordulhat olyan eset isamikor egyes egységek és a hozzáférési pont között megszakad a kapcsolat. A 802.11b szabvány jól tolerálja a zajos környezetet és a mostoha körülményeket. A hálózat tervezése során arra figyelembe kell venni kommunikációs csatorna közelében található: − olyan egységeket, amelyek elnyelik a mikrohullámokat (fák, téglafalak, vakolt falak és emberek). − olyan egységeket, amelyek reflektálják vagy szórják a hullámokat, mint a fémek, kerítések, csövek, tükrök. − 2.4 GHz-es zajforrásokat, mint a mikrohullámú sütők, vezetéknélküli telefonok, más 802.11b hálózatok. Minél több zavaró tényezőt tudunk megszüntetni ezek közül a kommunikációs csatornában, annál jobb minőségű összekötetést tudunk létesíteni, magasabb jel/zaj tényezővel (Signal-toNoise Ratio, SNR). Valószínűleg nem lehet az összes problémaforrást megszüntetni, de minimalizálni kell őket! A továbbiakban röviden ismertetjük azokat az antennatípusokat és azok főbb jellemzőit, amelyek a hálózattervezésnél kiegészítőként szerepelhetnek. Ezután rátérünk azon szempontok ismertetésére, amelyeket figyelembe kell venni a különböző vezetéknélküli hálózatok tervezésénél. 2.4.1

VEZETÉKNÉLKÜLI HÁLÓZATI KIEGÉSZÍTŐK, ANTENNATIPUSOK

2.4.1.1 WLAN antennatípusok Mivel a különböző gyártók által forgalmazott antennák teljesítmény jellemzői eltérhetnek, és az előírt hatósági szabályozásokat be kell tartani, ezért ez a rész ismertető jellegű. A tervezés előtt célszerű a gyártóval konzultálni és a számunkra lehető legjobb antennát kiválasztani. BZAKA

AmI Project

27.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata A körsugárzó antennák (10. ábra) a tér minden irányába sugározzák a jelet. Mind az épületeken belül, mind azokon kívül használhatóak. A körsugárzó antenna nyeresége (Transmitter Antenna Gain, GT) 0 dB körüli érték. Tipikus alkalmazása: végberendezés antenna. A Yagi antennákat (11. ábra) két távoli hálózat közötti pont-pont kommunikáció biztosítására tervezték. A Yagi antennák nyeresége (GT) tipikusan 16 – 20 dB. A híd antennák intelligens antennáknak tekinthetőek, mivel az adatkapcsolati rétegben dolgoznak. Ezek az antennák képesek a vett zajos jelből az információt kinyerni. A szektor antennákat (12. ábra) speciálisan hozzáférési pontok és pont-multipont kommunikáció biztosítására tervezték. A szektor antennák nyeresége 8.8 és 14.5 dB között van. A parabola antennák (13. ábra) speciálisan kültéri híd antennának lettek tervezve, hogy megvalósítsák a pont-pont kommunikációt két távoli hálózat között. A parabola antennák GT-je tipikusan 18 dB körüli érték.

10. ábra: Külső körsugárzó

2.4.2

11. ábra: YAGI antenna

12. ábra: Szektor antenna

13. ábra: Parabola antenna

HÁLÓZATTERVEZÉSI ELJÁRÁSOK

Habár a magyarországi számadatok különböznek az alább használtaktól, a tervezési folyamat általános jellegű. A direktszekvenciális spektrumszórásnál (DSSS) a hasznos jel sávszélességét kiterjesztjük. Ezáltal az egységnyi frekvenciasávra eső energia csökken, ez - a keskenysávú rendszerekhez viszonyítva - az interferencia csökkenését eredményezi. A DSSS jelfeldolgozási nyeresége (Processing Gain, PG) a chipsebesség és adatsebesség arányának logaritmusa. Gyakorlatilag a DSSS rendszer kis teljesítménysűrűségű zajként jelenik meg a keskenysávú rendszerek számára. A keskenysávú zajok/zavarok elnyomhatók, melynek folyamatát 14. ábra szemlélteti.

14. ábra: Elnyomás DSSS rendszerben

28.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata Amint már említettük az FHSS működési elve, hogy előre meghatározott sorozat szerint a vivőfrekvenciát időközönként megváltoztatjuk. Ehhez pontos szinkronizálásra van szükség. Két esetet különböztetünk meg: lassú és gyors FH. Az lassú esetén egy vivőn több bitet is átvihetünk, míg gyors FH esetén egy bit alatt többször is vivőt váltunk. A gyors FH-nak jobb az interferencia-elnyomó képessége, viszont a pontos frekvencia szintézerek miatt drágább is. Ezért WLAN-okban tipikusan lassú FH-t használnak. Az FHSS interferencia-elnyomását a 15. ábra mutatja be.

15. ábra: FHSS interferencia-elnyomása

2.4.2.1 Tervezési eljárás Ahogy azt már megjegyeztük, a 802.11 típusú vezeték nélküli helyi hálózatok a cellás elvet alkalmazzák. A rendszert cellákra osztják, és minden cellát egy bázisállomás vezérel. Habár egy WLAN állhat egyetlen cellából egyetlen AP-vel, a legtöbb esetben több cella alkot egy hálózatot és az AP-ket egy elosztó hálózat köti össze. Az IEEE 802.11b eszközök a szabadon felhasználható 2.4 GHz-es frekvenciasávot használják a kommunikációra, azon belül pedig maximálisan 14 csatorna foglalható le. A csatornák száma és kiosztása azért fontos, mivel országonként, illetve régiónként eltérő számú csatornákat használhatnak. Magyarországon, illetve általában Európában az 1-13 csatornák használatosak, de Spanyolországban csak a 10-11 csatornák, míg Franciaországban csak a 1013 csatornák használhatók. Az Egyesült Államokban a Szövetségi Kommunikációs Bizottság (Federal Communications Commission, FCC) az 1-11 csatornák használatát engedélyezte, mígn Japánban mind a 14-es csatorna használható. A frekvenciasávok szétosztása kétféleképpen történhet: − Egy hozzáférési ponthoz hozzárendelhetjük az összes lehetséges frekvenciasávot, és frekvenciaugrást alkalmazunk a zajok kiküszöbölésére. Ehhez szükségünk van egy nagyteljesítményű körsugárzós antennára. − Kis cellákat alakítunk ki és a szomszédos cellák frekvenciáit úgy választjuk meg hogy ne fedjék át egymást (cellás elv). Az első esetben nagyobb teljesítményű AP-kra van szükségünk az egész tér lefedéséhez és ez igen költségesezért inkább a második esetet alkalmazzák gyakrabban. A cellás elvvel (átfedő cellák, nem átfedő frekvenciasávok) kiküszöböljük a szomszédos cellák közötti interferenciát, és nagy teljesítményű AP-kat sem kell alkalmaznunk.

BZAKA

AmI Project

29.


16. ábra: Cellás elv, különböző frekvenciasávokkal

Az Egyesült Államokban használt 11 csatornák frekvenciáit a 4. táblázattartalmazza. A csatornakiosztással kapcsolatban fontos megjegyezni, hogy a csatornafrekvencia tulajdonképpen az adó-vevők (transceiver) által használt központi frekvenciát jelenti (pl. 2.412 GHz az 1., és 2.417 GHz a 2. csatornának). Mivel a központi frekvenciák között csak 5 MHz eltérés van, és mivel egy 802.11b jel 30 MHz-es frekvenciaspektrumot fed le, a hasznos spektrum kb. 15 MHz-es sávszélességet foglal el a központi frekvencia mindkét oldalán. Emiatt átfedés jön létre a szomszédos csatornák frekvenciasávjai között. Ezérta szomszédos cellák frekvenciatávolságának legalább öt csatorna sávszélességűnek kell lennie, így a szomszédos csatornák közötti áthallás/zavarás sikerrel kiküszöbölhető. Például használhatjuk az (1, 6, 11), (2, 7, 3), (8, 4, 9), vagy a (8, 5, 10) kombinációkat. Csatornák

Frekvenciák (GHz)

1

2.412

2

2.417

3

2.422

4

2.427

5

2.432

6

2.437

7

2.442

8

2.447

9

2.452

10

2.457

11

2.462

4. táblázat: Az USA-ban használt IEEE 802.11b csatorna frekvenciák

2.4.3

TÉRKÉPES ADATBÁZIS SEGÍTSÉGÉVEL VALÓ TERVEZÉS

Abban az esetben, ha egy kis területet szeretnénk lefedni, akkor először felmérjük azt hogy területen milyen zavaró tényezőkkel kell számolnunk. Úgy tervezzük a hálózatunkat, a nemkívánt tényezők hatása minimális legyen. Nagyméretű területek lefedésének tervezésében a térképi adatbázisok segítségünkre lehetnek.A térképi adatbázisoka terepelemek terjedési jellemzőit tartalmazzák, melyek felhasználásával a kisugárzott rádiófrekvenciás jelek csillapítása becsülhető.

30.

AmI Project

BZAKA


HOT-SPOT GERINCCSATLAKOZÁS

Az előző fejezetben – a zavaró hatások kiküszöbölését szem előtt tartva – a cellák tervezésének folyamatát, majd azok különböző alakzatú hálózattá való szervezését (gyűrű, busz, csillag) mutattuk be.

2.4.4.1 Az elosztó rendszer megvalósításának lehetőségei Az elosztó rendszer kiterjesztett hálózati szolgáltatásokat nyújt a hozzákapcsolódó BSS-ek és helyi hálózatok integrációján keresztül. Ezáltal tetszőleges bonyolultságú vezeték nélküli hálózat kialakítását teszi lehetővé. A szabvány logikailag elkülöníti a BSS-en belül használt átviteli közeget az elosztó rendszer átviteli közegétől. Ez az architektúrának rugalmasságot kölcsönöz, valamint az elosztó rendszer függetlenül definiálható a fizikai megvalósítás jellegzetességeitől. Így a felsőbb felhasználó rétegek felé transzparens szolgáltatás nyújtható (különálló BSS-ek együttese egyetlen BSS-ként szolgál).amit a szabvány kiterjesztett szolgálati összeillesztésnek nevez (Extended Service Set, ESS). A BSS-ek elhelyezésére a szabvány nem tartalmaz megkötéseket. A BSS-ek területei, a folyamatos lefedést biztosítása érdekében részlegesen átfedhetik egymást. Egy fizikai helyen több különböző szervezet, vagy vállalat által létesített vezeték nélküli helyi hálózat is működhet, illetve egy infrastruktúra hálózaton belül ad-hoc hálózat is kialakítható.

2.4.4.2 A logikai szolgálatok interfészei A 802.11-es szabvány lehetőséget ad arra, hogy: az elosztó rendszer a már meglévő vezetékes helyi hálózattól eltérő legyen -a rendszer adatkapcsolati vagy hálózati réteg alapú legyen. Az architektúra általánossága abból adódik, hogy a szabvány alkotói között több csoport képviseltette az érdekeit. A szabvány explicit módon nem definiálja az elosztó rendszert, helyette az architektúra komponensek közötti szolgálatokat határozza meg.

17. ábra: A teljes 802.11 architektúra.

A szolgálatok állomás és elosztó rendszer szolgálatokra bonthatók. BZAKA

AmI Project

31.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata Az állomás szolgálatok − Azonosítás: A cellán belüli szolgálat lehetővé teszi az átviteli közeghez való hozzáférést. Az átviteli közeghez való kapcsolódás céljából az állomásnak azonosítania kell magát. A vezetékes LAN hálózatokban a fizikai hálózathoz való hozzáférés szabályozható, (eltérően a a WLAN hálózatoktól). A szolgáltatás, a vezetékes LAN hálózatok hozzáférésével azonos szabályozást tesz lehetővé. Az architektúrák lehetnek nyitottak(bármilyen, a szabványnak megfelelő eszköz hozzáférhet az átviteli közeghez), és osztott kulcsúak (shared key); − Az állomás az átviteli közeghez való hozzáférésének megszűntetése; − Titkosítás: Az adatbiztonság megköveteli, hogy bizonyos kereteket csak a címzett olvashasson. Ez a WLAN rendszerekben nagyon fontos, mivel míg a vezetékes LAN hálózatokban csak az figyelheti a forgalmat, aki a hálózathoz kapcsolódik, addig a WLAN hálózatoknál bárki, akinek a szabványnak megfelelő rádiós interfésze van és az adás közelében tartozkodik, adatokat fogadhat; − Az állomás hozzárendelése egy hozzáférési ponthoz való hozzárendelése: egy állomás adatküldésének feltétele a megfelelő hozzáférési ponthoz való hozzárendeltség. Az elosztó rendszer számára szükséges annak ismerete hogy az állomás melyik cellába tartozik; − Egy meglévő BSS - állomás összerendelés megszüntetése. Az elosztó rendszer szolgálatai − A MAC szolgálati adatcsomagok (MAC Service Data Unit, MSDU) szállítása az elosztórendszeren belül a BSS – állomás összerendelő szolgálat információinak felhasználásával; − Integráció: MSDU adategységek szállítása az elosztórendszer és a vezetékes hálózat között; − Az állomás hozzáférési pontok közötti mozgásának biztosítása. 2.5

802.11-ALAPÚ SZOLGÁLTATÁS KOCKÁZATAI

BEVEZETÉSÉNEK

TECHNOLÓGIAI

Ebben a fejezetben azokat a lehetséges hátrányokat ismertetjük, amelyek a 802.11 technológia nyilvános hálózatokban való bevezetésekor felmerülhetnek. E kockázatok fontosságát nemcsak a technológia belső tulajdonságai adják, hanem az emberi tevékenység, a tipikus szolgáltatási környezet, valamint általában véve a rádiós technológiákról elterjedt közvélekedés miatt különös hangsúlyt kell fektetni a kockázatok elemzésére. Ezen kockázatok felmérésére a 7. fejezet során vizsgálati útmutatókat adunk meg. 2.5.1

A 802.11 ESZKÖZÖK HASZNÁLATÁNAK BIOLÓGIAI KOCKÁZATA

A WLAN viszonylag új technológia. A műszakilag fejlettebb területeken is csak néhány éve (1998 óta) használják rendszeresen. Mivel nem ionizáló sugárzás, hatása nem tanulmányozott eléggé, eddig általában a hadiiparban is használatos, vagy biológiai iparban alkalmazott sugárzásokat vizsgálták. A távközlésben használt spektrumokat ilyen alacsony adási teljesítmény mellett nem tesztelték, különösen nem nyilvános, emberektől néhány méterre levő eszközök esetében. Ugyanakkor a 2.4 GHz-es tartomány biológiailag veszélyes, nagy teljesítményen módosíthatja a fehérjék szerkezetét.

32.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata Az USA piacát a Szövetségi Kommunikációs Tanács (Federal Communications Commission, FCC) ellenőrzi. Ugyanakkor a küszöb-értékekhez szükséges kutatásokat, a vizsgálatokat és a berendezések ellenőrzését más szervezetek végzik, jellemzően az American National Standards Institute – ANSI és az Institute of Electrical and Electronics Engineers – IEEE. A rádiósugárzással kapcsolatos szabványokat e két szervezet által támogatott, gyakorlatilag ugyanaz az orvosbiológus csoport dolgozta ki. A témakörrel foglalkozó orvosbiológusok jelentős része az ionizáló és radioaktív sugárzások szakértője, így szabványaik nem mindig követik a spektrum sajátosságait. Az ionizáló sugarak olyan mértékben adnak át energiát a testnek, hogy az felmelegszik. A rádiósugárzást korlátozó szabványok jelenség nem kívánt hatásait figyelembe véve alakították ki ajánlásaikat. Ellenben a mikrohullámú, nem ionizáló sugarak alacsony, néhány wattos adási teljesítmény mellett átadott energiáját elnyeli a test, nem melegíti fel a bőrt. A sugárzás hatását hosszabb távon, folyamatosan is kifejtheti. Ez azonban több, független és költséges vizsgálatokat igényelne. A gyártók gyakran az IEEE 802.11 szabványra hivatkoznak, amikor termékeik tulajdonságait reklámozzák. A szabvány szerint az alacsony teljesítményű sugárzó eszközök, amennyiben nem haladják meg a javasolt Specific Absorption Rate – SAR, a jelenlegi kutatási eredmények alapján nem jelentenek veszélyt a felhasználókra és a nyilvánosságra. Európában több helyen szigorúbbak az előírások. Az USA-ban érvényes FCC 15.247 dokumentumban meghatározott 1000 mW maximális sugárzási teljesítményhez képest az Európai ETS 300-328 100 mW határoz meg. Összefoglalva, egy leendő szolgáltatónak fontos e kockázatokat figyelembe venni, mert • •

•

2.5.2

Etikailag nem megengedhető, hogy olyan szolgáltatás során szerezzen profitot, amelyik másoknak (különösen harmadik, vétlen félnek) maradandó károsodást okozhat Még nem eldöntött tény, hogy az FCC küszöbértékei megfelelőek-e. Ugyanakkor a legelterjedtebb minősítési eljárások során csak az FCC ajánlásait tartják be. Tehát könnyen lehet, hogy az ‘FCC-approved’ logó huzamosabb EXPOSURE esetén károsodást okoz. Ez később jogi problémákat vethet fel, amennyiben nem informálják kellőképpen a kockázatokról az érintett feleket. Legtöbb esetben az FCC értékei is antenna nélkül értendők. Vizsgálni kell, hogy az antenna mennyire erősíti fel ezeket az értékeket. Emiatt fontos a sugárzási vizsgálatok elvégzése.

A 2.4 GHZ ISM SÁVON ÜZEMELŐ BERENDEZÉSEK EGYMÁST ZAVARÓ HATÁSA

Az utóbbi években nagyon megnőtt a mobil hálózati felhasználók száma. Így megnőtt az igény a különböző Vezetéknélküli Személyi Hálózatok (Wireless Personal Area Network, WPAN) létrehozására, amelyben adatkommunikációra képesek a résztvevő laptopok, palmtopok és egyéb mobil egységek felhasználva a vezeték nélküli technológiákat. Ilyen technológiák a már ismertetett Bluetooth, infravörös (IR) és WLAN rendszerek is, amelyek nagy sávszélességű adatkommunikációt biztosítanak, sőt speciális hálózati egységeken keresztül az Internethez való csatlakozást is lehetővé teszik. Amint említettük a WLAN-nál alapvetően rádiófrekvenciát (RF) vagy az infravörös (IR) tartományt használják átviteli közegnek. Az RF LAN-okat tipikusan ipari, tudományos és orvosi (ISM) sávban (902-928 MHz, 2400-2483.5 MHZ és 5725-5850MHz). Ezek a frekvenciák nem igényelnek engedélyeztetést, így a LAN termékek hordozhatóak.

BZAKA

AmI Project

33.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata Ugyanakkor az ISM sávbeli rendszerek védelme érdekében az adóteljesítményt korlátozzák: maximum 1W USA-ban, maximum 100mW Európában és maximum 10mW Japánban. Az IR és RF technológiáknak különböző tervezési megkötéseik vannak. Az IR vevő tervezés egyszerű (tehát olcsó is) az RF-hez viszonyítva, mivel az IR vevők a jel amplitúdóját detektálják és nem a fázisát vagy frekvenciáját. Így csak minimális szűrésre van szükség a rádiós interferencia elleni védelem céljából. Azonban az IR ugyanazt a sávot használja, amit a napfény és néhány fénycső típus. Ezek a források csökkentik a jel-zaj viszonyt (SNR – Signal to Noise Ratio) és akár lehetetlenné is tehetik a működést. IR LAN-ok építésére két megközelítés létezik: − Az adó jelét fókuszálják, ekkor a hatótávolság néhány km és kültérben is használható. − Az adó jele reflektálódhat a falakon vagy körsugárzót használnak, ekkor a hatótávolság 10-20m. Az RF LAN-oknak sokkal több tervezési megkötéssel kell számolniuk. Az RF spektrum szűk erőforrás ezért mindenütt szabályozzák. Ezért tették a WLAN-okat az ISM sávba. További tervezési nehézség, hogy a kisugárzott jelek spektruma adott sávra van korlátozva, ami precíziós oszcillátorokat, szűrőket stb. igényel. Az RF rendszereknek a környezeti zajjal is számolniuk kell. Pl. atmoszférikus zaj vagy mesterséges (fénymásoló, mikrohullámú sütő, stb.), valamint az ISM sávban rádióamatőrök is zavarhatnak. Beltérben üzemelő LAN-oknak további problémákkal megküzdeniük, melyet a több utas terjedés kombinálva a mozgással (Rayleigh-fading, frekvencia szelektív fading) és az elnyelés okoz. A legtöbb építészeti anyag nem ereszti át az IR sugárzást, ezért a lefedési terület lecsökken egy szobára. Az RF gyakorlatilag immunis az elnyeléssel és a visszaverődéssel szemben. A RF LAN hálózatok a 2.4Ghz-es frekvenciasávban kétféle jelmodulációt alkalmaznak. Ezek a már leírt DSSS és FHSS modulációk. Az átvitel technikájának kulcskérdése a robosztusság. Ebben a tekintetben a két megoldás eltérő. A WLAN-ok két lehetséges interferencia forrása: más WLAN jelenléte az adott földrajzi területen és az ISM sáv más használói. Az utóbbi ellen az FHSS a jobb, mert az ugratási sorozat megválasztásával az interferencia lényegesen csökkenthető (18. ábra). A DSSS pedig a szórási faktorral védekezik az interferencia ellen. Mivel várhatóan több LAN is működhet egyazon területen, ezért biztosítani kell, hogy FHSS esetben az ugratási sorozatok ortogonálisak legyenek. DSSS esetben minden LAN-nak külön csatornát kell lefoglalni. Ezért az FHSS interferencia elnyomása jobb, az FHSS keskeny kb. 1MHz-es csatornákat használ, míg a DSSS akár 25MHZ-est is.

18. ábra FHSS és DSSS összehasonlítás

A spektrumszórást itt a meglehetősen kellemetlen csatorna elleni védelemre használják. A kódokat csak az egyes rendszerek elkülönítésre használják, a felhasználókat a MAC réteg választja szét egymástól tipikusan időosztásban! 34.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata Az FHSS-t használó berendezésekben van egy beépített mechanizmus, amely az esetleges zavart frekvenciasávokat (pl. mikróhullámú sütő, orvosi berendezések, stb.) érzékeli, és ennek megfelelően állítja a frekvenciaugatás során a használható frekvenciákat. A fent leírtak következtében az FHSS-t használó Bluetooth technológia hatékonyabb a DSSS-t használó IEEE802.11b rendszereknél a zavaró külső rádiós hullámok szempontjából. Ellenben mind a két rendszer ugyanabban a 2.4GHz-es ISM sávban működik, így egyenesen következik, hogy zavarhatják egymást. Ezt a jelenséget megvizsgálandó megalakult egy munkacsoport az IEEE-én belül, az IEEE802.15.2 [3]. Ez a munkacsoport jutott arra az eredményre, hogy a Bluetooth rendszer nagyon megzavarhatja az IEEE802.11b adatkommunikációját. Így, ha egy Bluetooth eszköz kevesebb, mint 10 cm-nél közelebb van az IEEE802.11b eszközhöz, akkor annak a kiépített kapcsolata teljesen megszakad. Ha ezt a távolságot 1 méterre növeljük, akkor is az IEEE802.11b eszköz kapcsolata 50%-os csomagveszteséget szenved. Ugyanez a zavarás - bár nem ilyen mértékben - fordítva is fennáll. Így, ha két eszköz 10 cm-nél közelebb van egymáshoz, akkor a Bluetooth kapcsolat 60%-os adatveszteséget könyvelhet el. Mérések és szimulációs vizsgálatok során megállapították, hogy egy magas kihasználtságú Bluetooth pikocella jelentős negatív hatást fejt ki a hatótávolságon belülre elhelyezett 802.11 állomásra, különös tekintettel az AP által küldött hosszabb csomagokra. Ezt a hatásnak az alacsonyabb sávszélességű DSSS módban adó állomások vannak jobban kitéve, mert a hosszú csomagok így nagyobb hosszabb ideig használják ugyanazt a frekvenciát folyamatosan. Ezáltal nő a valószínűsége, hogy a Bluetooth adó frekvencia-ugrás sorozata “belép” abba a sávba. Az FHSS esetében ellenben ez egy sikeres megoldás lehet, ugyanis a hosszabb csomagokat több frekvenciára kell ’felosztani’, így ritkábban ütköznek a Bluetooth adással. Az RTS/CTS mechanizmus sajnos nem zárja ki a zavarást és ütközést, ugyanis egy már RTS által foglalt sávot akár Bluetooth ugrási szekvencia is lefoglalhat. Ugyancsak a 2.4Ghz-es frekvenciasávban működnek a mikrohullámú sütők, valamint egyéb orvosi eszközök is. Mikrohullámú sütővel végzett kísérleteink során a kinyitott ajtajú működő sütő teljesen megszakította a kommunikációt. Ez természetesen nem egy életszerű zavarási eset, zárt ajtajú, előírásszerű működés esetén nem volt zavaró tényező. Ellenben kórházakban felmerülhet az a veszély, hogy egy 802.11 rendszer zavarja az orvosi műszer működését. Ezért a rendszer telepítése előtt azonosítani kell a potenciális konfliktusokat és a helyszínen mérésekkel kell ellenőrizni a kölcsönhatást. 2.5.3

BIZTONSÁGI KOCKÁZATOK ÁTTEKINTÉSE

A vezetéknélküli hálózatok biztonságossá tétele rendkívül kényes és összetett feladat. Egyensúlyt kell találni két egymásnak látszólag teljesen ellentmondó tulajdonság között. A szakértők ezt a biztonság és mobilitás paradoxonként említik, mely a következőképp hangzik: a biztonságos hálózatok nem mobilisak, a mobil hálózatok pedig nem biztonságosak. A 802.11 szabványba épített biztonsági megoldások hibái mára közismertek. Az Internetről több olyan software segédeszköz letölthető, amelyek segítségével, egy komolyabb szakismeretekkel nem rendelkező támadó is néhány óra alatt megfejtheti azokat a kulcsokat, amelyekkel a kommunikációt titkosítják. Mivel a szabvány által biztosított vezetékessel egyenértékű titkosítási (Wired Equivalent Privacy, WEP) kulcsok biztonsági szintje még csak meg sem közelíti a nevében állítottakat, az IEEE két csoportot hozott létre a szükséges új szabványok kidolgozására.

BZAKA

AmI Project

35.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata A 802.1x csoport által létrehozott szabvány lényege, hogy meghatározza, hogyan alkalmazható a bővíthető hitelesítési protokoll (Extensible Authentication Protocol, EAP) vezetékes és WLAN környezetben. Az EAP különféle hitelesítési eljárások (mint például a RADIUS, lásd [47]) használatát teszi lehetővé. A 802.11i feladata az, hogy egy sokkal hatékonyabb, vezeték nélküli titkosítási eljárást szolgáltasson. Két megoldás született. Az egyik az ideiglenes kulcs integritás protokoll (Temporal Key Intergity Protocol, TKIP), amely egyrészt megoldást nyújt a WEP hiányosságaira, másrészt lehetőséget ad a csomagonkénti kulcsváltásra valamint az üzenet sértetlenségének ellenőrzésére. A másik a továbbfejlesztett titkosítási szabvány (Advanced Encryption Standard, AES), melyet az Egyesült Államok kormánya fejlesztett ki a már elavult adattitkosítási szabvány (Data Encryption Standard, DES) és a tripla DES (Triple Data Encryption Standard, 3DES) leváltására. A Wi-Fi Alliance 2002 októberében jelentette be Wi-Fi védettségű hozzáférés (Wi-Fi Protected Access, WPA) nevű megoldását, amely a TKIP-et felhasználva hivatott a biztonságos kommunikációt szolgálni, mindaddig, amíg a piacon megjelennek az AES-t támogató termékek.

2.5.3.1 A biztonságos hálózatok nem mobilisak A jelenlegi WPA-nak megfelelő termékekkel építhetünk ugyan biztonságos vezeték nélküli hálózatot, azonban ebben az esetben a mobilitásról teljesen le kell mondanunk. Tételezzük fel, hogy cégünk minden osztályának különféle hozzáférési jogosultságokat kívánunk kiadni bizonyos erőforrásokhoz. Ekkor minden csoporthoz létrehozzuk és beállítjuk a megfelelő kulcsokat, és ezzel lehetővé tesszük, hogy saját részlegük közelében (ahonnan elérhetők az ott elhelyezett hozzáférési pontok), biztonságosan használhassák vezeték nélküli eszközeiket. Ha azonban egy másik részleg hozzáférési pontjainak körzetébe érnek, az ottani kulcsok hiányában nem képesek kapcsolatot létesíteni. Ezt a fajta helyhez kötöttséget feloldhatjuk különféle megoldásokkal, mint például a virtuális helyi hálózatok (Virtual Local Area Network, VLAN) kiterjesztésével illetve különböző makromobilitási protokollok használatával. Ezek azonban vagy a bonyolult konfigurálás vagy a gerinchálózatra nehezedő többletterhelés miatt nem jelenthetnek igazi alternatívát. Mindezen megoldások egyik legnagyobb hátránya, hogy a hálózatot használó kilétéről semmiféle információval nem szolgálnak.

2.5.3.2 A mobil hálózatok nem biztonságosak A vezetékes hálózatokkal összevetve, egy olyan hálózatban, ahol a felhasználók a rendszer különböző szegmensei között mozognak rendkívül nehéz a megfelelő biztonságot elérni. Vezetékes hálózatoknál ugyanis a kliensek egy csatlakozási ponthoz rendelhetők, és a továbbiakban azon kapcsolódási pont tulajdonságainak finomhangolásával, minden felhasználóhoz pontosan meghatározott hozzáférési jogok rendelhetők. WLAN hálózatokban a kliens helyének meghatározása nem triviális és amúgy sem használható önmagában jogosultságok kezelésére, hiszen az adott felhasználónak a rendszer bármelyik pontjáról azonos szolgáltatásokat kell tudnia igénybe venni. Itt tehát magát a felhasználót kell azonosítani és hozzárendelni a megfelelő jogokat. Ez elvileg megoldható lenne úgy, hogy mindenkihez dedikált titkosított csatornákat, ún. virtuális magánhálózatot (Virtual Private Network, VPN) építünk ki. Ez azonban szintén óriási terhelést róna a gerinchálózatra, illetve sok ügyféloldali konfigurálást és segítségnyújtást igényelne, amelyek fényében közel sem egy kifizetődő megoldás.

36.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata Maguk az AP-k is veszélyforrások lehetnek, hiszen ezeket bárki (akár egy külső látogató) számára könnyen elérhető helyre telepítik, például íróasztalokra, mennyezetre. Ezért tehát a lehető legkevesebb feladatot kell az AP-kra hagyni, a lehető legnagyobb mértékben el kell kerülni, hogy a rendszer működéséhez szükséges, vagy biztonsági adatokhoz hozzáférjenek illetve módosítani tudják azokat. A biztonság szempontjából tehát a minél “vékonyabb” AP-k a megfelelők.

BZAKA

AmI Project

37.


ADATBIZTONSÁGI ALAPFOGALMAK

Ebben a fejezetben az alapvető adatvédelmi szolgáltatásokat [48] ismertetjük. A hitelesítés célja, hogy általa a felhasználók egymás identitását le tudják ellenőrizni. Az azonosításnál az azonosító fél olyan információt használ fel az azonosítandó félről, amely publikus, míg az azonosítandó fél olyan információt használ fel a digitális aláírás létrehozásához, amely titkos, csak számára ismert. Az azonosító így biztos lehet abban, hogy a digitális aláírás hiteles mivel a generálását csak az azonosítandó fél végezhette el. A hitelesítést lehet üzenetek hitelességének az ellenőrzésére is használni. Ilyenkor a digitális aláírás az üzenetből készül el egy egyirányú függvény segítségével. Ha az üzenet a továbbítás folyamán megváltoztatódik, akkor a vevő az ellenőrzés során nem ugyanazt az értéket kapja vissza, mint amelyet a digitális aláírás mutat. A titkosítás célja az, hogy az információt elrejtse az illegális felhasználók elől. A titkosított adatokat csak egy kulcs birtokában lévő személy képes elolvasni. Ez a kulcs csak az illetékes személyek birtokában van meg, így az illegális behatolók nem tudják az adatokat értelmezni. A kulcs segítségével az adatok dekódolása nem igényel különösebben nagy számítási kapacitást, míg a kulcs ismerete nélkül csak igen nagy erőfeszítéssel dekódolható az információ. Az adatok titkosításán kívül a forgalmat is szokták titkosítani. A forgalom titkosításának a célja megakadályozni, hogy valaki a hálózati forgalom megfigyeléséből hasznos információt nyerjen. Erre azért van szükség, mert az adatok titkosításával nem változik meg a forgalom karakterisztikája. Megfigyelhető például a forrás és a célcím, a használt portok, az átvitel időpontja vagy az üzenetek gyakorisága, stb. A titkosítás lehet szimmetrikus vagy asszimetrikus kulcsú. Ha az adatok kódolásához és dekódolásához ugyanarra a kulcsra van szükség, akkor szimmetrikus kulcsú titkosításról beszélünk. Ekkor a vevőhöz valamilyen biztonságos módon kell a kulcsot eljuttatni. A legismertebb szimmetrikus kulcsú titkosítás a DES (Data Encription Standard). Az asszimetrikus kulcsú titkosításnál külön kulcsot használnak a kódolásra és külön kulcsot a dekódolásra. Minden felhasználónak két kulcsa van egy titkos és egy publikus. Ezek a kulcsok egymás inverzei, vagyis egy a publikus kulcsal átkódolt adat a titkos kulcsal dekódolható, ez fordítva is működik. A küldő publikus kulcsát a vevő is ismeri és a küldő hitelesítésére használja. Ilyenkor a küldő az adatokat a csak általa ismert saját titkos kulcsával hitelesíti. Ha a küldő a vevő publikus kulcsával átkódolja a küldendő üzenetet, akkor titkosítás történik, ugyanis ezt az adatot csak a vevő tudja a titkos kulcsával dekódolni. A legismertebb aszimmetrikus titkosítási algoritmus az RSA. Az integritásvédelem során az információt védjük meg az illegális módosításoktól. Az információhoz egy olyan digitális kivonat van csatolva, amely segítségével leellenőrizhetjük, hogy módosítva lettek-e az adatok. Integritásvédelmet szoktak használni a kapcsolatok sérülésének/módosításának a detektálására is. Előfordulhat ugyanis, hogy a támadó bizonyos üzeneteket vagy csomagokat töröl, vagy beszúr az üzenetfolyamba. Mivel minden üzenet egyenként sértetlen, ezért a vevő ezt a támadást nem fogja észrevenni, mivel az integritásvédelem csomagonként működik. Ennek megakadályozására használnak kapcsolatintegritásvédelmet, melynek segítségével a kapcsolat teljes integritásának védelme garantálható. A hozzáférés védelem rendszer különböző erőforrásaihoz történő hozzáférés ellenőrzésére és korlátozására biztosít mechanizmusokat. Ide tartozik az adatokhoz való illegális hozzáférés elleni védelem vagy a fizikai erőforrások illegális használatának a megakadályozása. Ilyen védelmet biztosít például a Kerberos.

38.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata Valamelyik fél megpróbálhatja letagadni, hogy korábban üzenetet kapott (vagy küldött) egy másik felhasználótól. Ezt akadályozza meg a letagadhatatlanság szolgáltatás. Minden adatvédelmi szolgáltatásnak, akár szimmetrikus akár aszimmetrikus kulcsú titkosítást használ, központi kérdése a kulcsmenedzsment. Ha a kulcsmenedzsment nem biztonságos, akkor bármilyen erős kriptográfiai protokoll könnyen támadhatóvá válik. A kulcsmenedzsment feladata a megfelelő kulcsok eljuttatása az arra jogosult feleknek. Gondoskodni kell azon kívül a kulcsok generálásáról, tárolásáról, és a lejárt kulcsok érvénytelenítéséről. Két fajta kulcsmenedzsment megoldás létezik: az elosztott és a központi kulcsmenedzsment. Az aszimmetrikus kulcsú titkosítási technikákat használva megszabadulhatunk a kulcs szétosztás problémájától. Ekkor azonban biztosítanunk kell a publikus kulcstár integritását és hitelességüknek az ellenőrzését. A publikus kulcsok hitelességét hitelesítő egységek garantálják, bizonyítványokat kibocsátva az illető kulcs tulajdonosáról. Ezeknek a hitelesítő egységeknek a kiléte és a publikus kulcsa széles körben ismert, így garantálva van, hogy a kommunikáló felek egymás bizonyítványát beszerezhetik.

2.5.4.1 Adatvédelmi szempontok a vezeték nélküli hálózatokban A vezeték nélküli és mobil hálózatokban a kommunikációs mechanizmus az üzenetszórásra alapul, ami az alkalmazott adatvédelmi megoldások iránti követelményeket a vezetékes hálózatokban alkalmazottak fölé emeli. Egy fix topológia hiányában a mobil rendszerek nem rendelkeznek fizikai védelemmel az illegális hozzáférés és lehallgatás ellen. A mobil rendszerek adatvédelmi rendszerét [9] olyan módon tervezni, hogy az ne okozzon számottevő késleltetéseket a kapcsolatok felépítésében és a kommunikációban. A vezeték nélküli hálózatok sávszélessége és a telepeik kapacitása sokkal alacsonyabb, mint a vezetékes hálózatoké, ezért a javasolt adatvédelmi mechanizmusok üzenetei rövidek és alacsony számúak legyenek. A megoldások késleltetés és csomagvesztés-toleránsak kell legyenek. Ezeken kívül a következő szempontoknak kell megfeleljenek a vezeték nélküli adatvédelmi protokollok: •

Nem szabad a közbenső hálózatot biztonságosnak feltételezni: a használt hálózatok adatvédelmi technológiájáról minimális feltételezést szabad csak elfogadni

•

Kölcsönös hitelesítés: a hálózati entitás (bázisállomás) és a mobil terminál között, lehetővé teszi, hogy a terminál a bázisállomás hitelességét leellenőrizze így megakadályozva a fantom hálózatok létrehozását

•

Adatok titkosítása és integritásvédelme: aktív és passzív betolakodók ellen nyújtanak védelmet

•

Követhetetlenség: az identitás, helyzet és mobilitás információ védelmét garantálja. A mobil állomásoknak lehetővé kell tenni, hogy olyan módon kérjenek szolgáltatásokat a hálózattól, hogy a lehallgató támadó ne jusson információhoz a kérés elemzésekor.

•

Opcionális adatvédelem: mivel az adatvédelem számos esetben erőforrás igényes (processzor, sávszélesség) egyes adatvédelmi funkciók opcionálissá tétele növelné a rendszer dinamizmusát

•

Hajlékonyság: a rendszer képes legyen új kriptográfiai technikákkal való bővíthetőségre. A jelenlegi mobil rendszerek erre nem képesek

•

Együttműködés: a mobil rendszerekben használt adatvédelmi termékek/módszerek egymással együttműködőek legyenek.

BZAKA

AmI Project

39.


2.5.4.2 Támadások Támadások típusai A hálózatok elleni támadások [48] formája lehet passzív vagy aktív típusú támadás. A passzív támadás során a támadó megfigyeli, lehallgatja a hálózaton átküldött információkat, de nem módosítja azokat. Ezzel a célja, hogy a megszerzett adatcsomagokból számára hasznos információt próbáljon meg kinyerni. Ilyen információ lehet a felhasználó személyes adatain kívül, hálózatok, szerverek belépési jelszavai, stb. Ezeket az információkat később a támadó további adatok megszerzéséhez vagy adatbázisok, a továbbított titkosított adatok visszafejtéséhez tudja felhasználni. Az aktív támadás során a támadó nemcsak megfigyeli hanem módosítja is a hálózaton átküldött információkat. Aktív támadások használatával, sokkal több lehetősége van a támadónak a felhasználók becsapására vagy a titkos adataiknak a megszerzésére. Az aktív támadások kivitelezése viszont általában sokkal nehezebb, mint a passzív támadásoké. Aktív támadás végrehajtásához a támadónak hozzáférése kell legyen a hálózat egy termináljához vagy sok esetben magához az átviteli közeghez (vezetékhez). Az átviteli közeghez sok esetben nem egyszerű hozzáférni, hiszen a vezetékek a föld alatt húzódhatnak, ráadásul optikai vezeték esetén a kábelre csatlakozás sem triviális. Vezetéknélküli hálózatok esetében mind a passzív mind az aktív támadást könnyebb kivitelezni. Ezekben a hálózatokban elég ha a támadó a vezetéknélküli infrastruktúra rádió lefedettségi zónáján belül tartózkodik és rendelkezik egy a többi egységhez hasonló rádiós interfésszel. Támadások a kriptográfiai protokollok ellen A hitelesítő anonimitása elleni támadás A felhasználók anonimitása kompromittált, ha a támadó meg tud szerezni egy a felhasználó által generált digitális aláírást. Ha az adatok egy olyan hitelesítő rendszerrel voltak aláírva amely az üzenetek parciális visszanyerését biztosítja (mint például az ISO/IEC 9796-2 aláírások), akkor a támadó akinek hozzáférése van a publikus ellenőrző kulcsok egy nagyobb halmazához, ezeket sorra az aláíráson kipróbálhatja. Ha az ellenőrző procedúra sikertelen, akkor a támadó feltételezheti, hogy az alkalmazott kulcs tulajdonosa nem a hitelesítő egység. Hasonló támadás intézhető más hitelesítő rendszerek ellen is, ha a támadónak hozzáférése van az aláírt adatokhoz. Tartalomellenőrző támadás Ez a támadás hasonló a hitelesítő elleni támadáshoz és arra lehet használni, hogy a támadó számára ismeretlen aláírásnak egy részét visszafejtsük. Feltételezzük, hogy a támadónak birtokában van egy digitális aláírás, ismeri az aláírót és az aláírt üzenet nagy részét. Ekkor a támadó ismételten próbálja kitalálni a hiányzó adatot, amelyet az ismert üzenetrésszel összemásol és átkódol, majd összehasonlítja az eredeti átkódolt üzenettel, amelyet úgy kap meg, hogy az aláírást leellenőrzi az ismert felhasználó ellenőrző kulcsával. Forráskicserélő támadás A forráskicserélő támadás során a támadó megszerzi a megtámadott egység publikus kulcsát, és úgy rendezi, hogy erre a publikus kulcsra egy hitelesítőtől kapjon egy bizonyítványt mintha a sajátja lenne. Ez lehetővé teszi azt, hogy a támadó az illető egységnek adja ki magát, mint például egy üzenet hitelesítésekor. Ezek a támadások

40.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata elkerülhetőek, ha a hitelesítő egység ragaszkodik bizonyítékok felmutatásához a hitelesítési bizonyítványt kérő egység kilétét illetően. Idő-memória kompromisszumos támadás Ez a támadás olyan üzenetek megfejtésére használható, amelyeknek ismert az aláírása. Feltételezzük, hogy a K üzenetnek k bitje van és ismerjük a h(K) aláírást. Ekkor a támadó kiszámítja és eltárolja 2r értékét a h(K)-nak. Amikor a h(K) aláírás a protokoll működése során feltűnik a támadó, ezt összehasonlítja az eltárolt értékekkel. Annak a valószínűsége, hogy a megfelelő értéket eltárolta 2k-r, tehát a támadónak 2k-r aláírást kell elkapjon, hogy a K-t megfejtse. Részlegesen választott kulcstámadás A támadás a részlegesen választott kulcs-generáló protokollok ellen használható. Ezekben a protokollokban két egység, X és Y, véletlenszerű értékekkel járulnak hozzá egy f(x,y) szessziókulcs generálásához. X küldi el először el a hozzájárulását, a x-et, Ynak. Ekkor Y-nak lehetősége lesz rá, hogy kiszámítsa 2s variációját y-nak és a megfelelő f(x.y)-t mielőtt elküldené y-t az X-nek. Ezen a módon az Y kiválaszthatja a kulcs s bitjét a részleges kulcsnak. Az s értéke, tehát a kulcs előállításában a szerepek súlya, az Y számítási kapacitásától és a rendelkezésére álló időtől függ. Kulcs-szétválasztásos támadás Tegyük fel, hogy A titkosít valamit a hitelesítési protokoll folyamán egy szimmetrikus K kulcsot használva. Most feltételezzük, hogy egy teljesen független protokoll során, amely egy E egység és az A között működik, az E adatokat küld A-nak, amelyeket A ugyanazzal a K kulccsal titkosít és visszaküldi E-nek. Ilyenkor az E számára lehetővé válik, hogy ezt a kulcs szétválasztási problémát felhasználja arra, hogy az első protokoll üzeneteit (A és B közötti) a második protokoll üzeneteivel kicserélje (kiválasztott üzeneteken küldve az A-nak átkódolás céljából majd ezeket B-nek küldve A-nak adva ki magát). A kriptográfiai protokollok sajátosan érzékenyek erre a támadásra, ha az utolsó üzenet a protokollból kódolva van. Ebben az esetben az E számára lehetővé válik, hogy kicserélje a B-nek küldött üzenetet, míg A azt hiszi, hogy a protokoll helyesen végrehajtódott. Ez a támadás elkerülhető, ha szesszió kulcsokat használunk, amelyek frissítve vannak minden használat előtt. A „középen-lévő-ember” támadás A középen-lévő-ember (man-in-the-middle) típusú támadás a kulcs-cserélő protokollok ellen lehet bevetni. A támadás során a támadó a két résztvevő fél közé beépülve mindkét félnek úgy adja ki magát, mintha az a másik féllel, kommunikálna. A támadó az A által küldött adatokat nem küldi át a B-nek hanem, megtartja magának és helyette az általa generált adatokat, küldi el. Ugyanezt játssza el fordítva is, tehát a B üzenetei helyett a saját üzeneteit küldi el A-nak. A támadónak így lehetősége lesz rá, hogy a titkosított adatkommunikációt elfogja és dekódolja. Ezt a támadást hatékonyan lehet felhasználni például a Diffie-Hellmann kulcs-cserék ellen. Támadások a vezetéknélküli hálózatok ellen Az IEEE 802.11 vezetéknélküli hálózatokban az adatok, a vezérlő/menedzsment keretek, hitelesítési információk mind ugyanazon a csatornán vannak továbbítva, így támadásnak vannak kitéve. Ilyenfajta támadások lehetnek [9]: 1. a támadó megpróbál titkos adatokra és identitás információkra szert tenni lehallgatva a hálózatot és lelopva az adatcsomagokat. BZAKA

AmI Project

41.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata 2. a támadó megpróbálja az adatokat, a vezérlő/menedzsment kereteket vagy a hitelesítési adatokat módosítani. 3. a támadó megpróbál hamis adatokat, vezérlő/menedzsment kereteket vagy hitelesítési adatokat beszúrni a felhasználói kommunikációba. 4. a támadó megpróbálja másnak kiadni magát, hogy eltérítse és megértse a félrevezetett felhasználó kommunikációját 5. a támadó megpróbálja megakadályozni a terminálok és a bázisállomások helyes működését, az erőforrások kisajátításával, a csatorna leterhelésével, stb. 6. a támadó megpróbálja az adatvédelmi kiegyezést megszakítani, hogy a hitelesítést legyengítse vagy a felhasználói jelszavakhoz hozzáférjen. Ilyenkor megpróbálja úgy beállítani, mintha a két fél közül valamelyik, nem igényelné a biztonságosabb adatvédelmi eljárást. 7. a támadó egy bázisállomásnak adja ki magát egy virtuális hálózatot szimulálva.

42.

AmI Project

BZAKA


2.6

A 802.11 PROTOKOLL VIZSGÁLATA

A 802.11 szabványcsalád egy fejlesztés alatt álló, viszonylag új szabvány. A szabvány megjelenésével egyidejűleg több gyártó is fejlesztett és piacra vitt termékeket, amelyek nem feltétlenül voltak kompatibilisek egymással. A szabvány később rögzített ajánlásait így nem mindig követték a termékek. A későbbi fejlesztések során néha a gyártók előnyben részesítették a saját termékeikkel való kompatibilitást, mint a szabvánnyal. Erre adott esetben a szabvány is lehetőséget teremtett, mivel néhány opciót a gyártókra bízott. Az IEEE, a 802.11 szabvány kidolgozója csak a fizikai réteg konformancia vizsgálatára dolgozott ki ajánlást [37]. A második réteg, valamint a különböző gyártók termékeinek együttműködésére nincsenek ajánlások. Éppen ezért jellemző a sok pontatlanság, rémhír, idegenkedés. Így fontos a megbízható és alapos információgyűjtés, amely alapja lehet a későbbi beruházási döntéseknek, a műszaki tartalom későbbi bővítésének, valamint a marketingtevékenységnek 2.6.1

A JAVASOLT VIZSGÁLATOK

A telephelyünkön üzemeltetünk egy teszt-hálózatot, amelyről a tanulmány 0 fejezetében részletesen beszámolunk. Az itt bemutatott mérési eredmények szoros kapcsolatban vannak a NAP2005 pályázatban bemutatott alkalmazás-részfeladatokkal. Az itt bemutatott eredményeket és tapasztalatokat felhasználjuk a továbbiakban az említett részfeladatok kidolgozásában. Fontos megemlíteni, hogy az üzemeltetés során több vizsgálati elrendezést volt alkalmunk kipróbálni. Eddigi méréseink során az eredmények relevanciája alapján igyekeztünk azokat a konfigurációkat beazonosítani, amelyek valós segítséget nyújtanak az eszköz vizsgálatában. Ezen tapasztalatok, valamint az elméleti áttekintés alapján összeállítottuk egy teszt-sorozatot, amely segít a választott eszköz minősítésében. A tesztsorozat két területre fókuszál. Egyrészt ellenőrzi, hogy a vizsgálat tárgya valóban megfelel-e a 802.11b szabványnak, valamint milyen képességekkel rendelkezik. A vizsgálatok egy része az eszközök teljesítményét értékeli különböző, tipikus felhasználási helyzetben. Az 5. táblázat sorszámozva tartalmazza a javasolt vizsgálatokat. Sors Vizsgálat neve zám

A vizsgálat rövid leírása

Típusa

1

AP mód

Működik-e a kapcsolat? Ping, www

I/N

2

AH mód

Működik-e a kapcsolat? Ping, www

I/N

3

AP mód

Optimális távolságban, max. átviteli Skála sebesség

4

AH mód

Optimális távolságban, max. átviteli Skála sebesség

5

Hatótávolság – több Antenna nélkül milyen távolságig Skála konfigurációban lehet pl. 30dB S/N határig kommunikálni

BZAKA

AmI Project

43.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata Sors Vizsgálat neve zám


Típusa

6

Több mobil állomás teljesítménye – több konfiguráció és vizsgálat

Ugyanabban a térben (azaz egymás Skála hatótávolságán belül) több mobil állomás kommunikál. Milyen teljesítményt érnek el. Fairness kérdések.

7

Csatorna váltás

Működik-e? vezérelhető?

8

Csatorna áthallás 1.

Egy területen levő eszközök esetén, Skála különböző csatornákon áthallás – milyen mértékben rontja a mért csatornát a zavaró csatorna forgalma (S/N arányban, átvitelben)

9


Mikrohullámú sütő v. egyéb ISM Skála sávos berendezés hatása minden csatornára (S/N arányban, átvitelben)

10

RTS/CTS mechanizmus 1.

Szabályosan van implementálva?

11


Hány százalékkal javítja az átviteli Skála teljesítményt az RTS/CTS mechanizmus?

12

AP Roaming 1.

Képes-e AP-t váltani a mobil állomás

13

AP Roaming 2.

Milyen teljesítmény kiesést okoz egy Skála AP-váltás

14

Árnyékolás /fading/

Teljesítményromlás akadályok, emberi árnyékolásának hatására

15

SSID

Képes-e a rendszer SSID védelmet I/N nyújtani

16

MAC Filter

Képes-e a rendszer MAC szűréses I/N védelmet nyújtani

17

WEP

Képes-e a rendszer WEP védelmet I/N nyújtani

18

WEP128

Képes-e a rendszer védelmet nyújtani

19

IEEE-Annex A Proforma

Rádiós interfész fizikai rétegének Lásd megfelelőségi vizsgálata, táblázat

21

Terméktámogatás

Installáció, Meghajtók, Menedzsment interfész

I/N

I/N

I/N

beltéri Skála test

WEP128 I/N 7.

Ár, Adminisztratív

5. táblázat: Javasolt tesztsorozatok összefoglalója

44.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata A következő, 6. táblázat foglaltuk össze azokat a vizsgálatokat, amelyeket újra kell mérni, ha az eszközhöz más típusú antennát csatlakoztatunk. Alapesetben az eszközzel szállított antennával kell a vizsgálatot elvégezni. Sorsz.

Vizsgálat neve


Típusa

1

Sugárzási teljesítmény

Teljesítménye kisebb-e a szabványosnál

I/N

2

AP mód

Optimális távolságban, max. átviteli sebesség

Skála

3

Hatótávolság – több konfigurációban

Antenna nélkül milyen távolságig lehet kommunikálni

Skála

4

Több mobil állomás teljesítménye – több konfiguráció és vizsgálat

Ugyanabban a térben (azaz egymás hatótávolságán belül) több mobil állomás kommunikál. Milyen teljesítményt érnek el. Fairness kérdések.

Skála

5

Csatorna váltás

Működik-e? Vezérelhető?

I/N

6


Egy területen levő eszközök esetén, különböző csatornákon áthallás – milyen mértékben rontja a mért csatornát a zavaró csatorna forgalma (S/N arányban, átvitelben)

Skála

7


Mikrohullámú sütő v. egyéb ISM sávos berendezés hatása minden csatornára (S/N arányban, átvitelben)

Skála

8


Hány százalékkal javítja az átviteli teljesítményt az RTS/CTS mechanizmus?

Skála

9

AP Roaming 2.

Milyen teljesítmény-kiesést okoz egy AP-váltás

Skála

Árnyékolás /fading/

Teljesítményromlás beltéri akadályok, emberi test árnyékolásának hatására

Skála

Terméktámogatás

Antennaillesztés és telepítés, Technikai paraméterek, Ár, Menedzsment interfész

Adminisztratív

10

11

6. táblázat: Új antenna illesztése

BZAKA

AmI Project

45.


VIZSGÁLATOK RÉSZLETES LEÍRÁSA

2.6.2.1 Az IEEE által javasolt konformancia vizsgálatok Az IEEE PICS Proforma vizsgálatai a vizsgált eszköz 802.11 protokollnak megfelelő fizikai rétegbeli működést ellenőrzi. Végrehajtásához szükséges egy protokoll-teszter, amely a vezeték nélküli interfészen érkező jeleket fejrésszel együtt képes rögzíteni. Ennek alapján már el lehet végezni a teszteket, de ez a munka még így is jelentős erőfeszítést igényel, ugyanis a hexadecimális értékeket vissza kell fejteni a protokoll leírása szerint. A vizsgálatok hatékony végzése érdekében szükséges még egy kiegészítő szoftver modult is beszerezni, amely a 802.11 protokoll szerint értelmezi a hexadecimális kódokat. Továbbá szükséges a rádiós csatornák energiaszintjének és spektrumának mérése. A javasolt vizsgálatokat az alábbi 7. táblázat foglalja össze, amely az IEEE javaslata [37] alapján állítottunk össze. Megjegyezzük, hogy elméletileg a ’WiFi’ címkével ellátott eszközök sikeresen át kell essenek egy ilyen tesztelésen. A táblázat 3. oszlopában a K betű a kötelező protokollelemet jelzi, az O pedig az opcionálist. A TX adási módot, az RX fogadási/vevési módot jelent. Vizsgált jellemző

Státusz Eredmény

Hosszú előtag és fejrész (TX) Hosszú DSSS előtag (preamble) függ a TX-től

K

Hosszú PLCP integritás-ellenőrző generálása TX váltásának képessége Támogatott sávszélességek Adat-bitsorozat ’felcserélése’ (scrambling) Adat-bitsorozat ’felcserélése’ helyes inicializálás

(scrambling)

esetén

’Channel Agility’ csatorna-váltás adott időn belül

O

Hosszú előtag és fejrész (TX) Rövid előtag (preamble) függ a TX-től

O

Rövid fejrész küldése

O

Hosszú előtag és fejrész (RX) PLCP formátum felismerése

K

PLCP integritás-vizsgálat elvégzése RX váltásának képessége ’Felcserélt’ (scrambled) adat-bitsorozat kezelése Működési csatornák ellenőrzése Az Európai Szabvány (ETSI) szerinti 13 csatornán K valóban a megadott frekvencia tartományban történik a kommunikáció (vizsgálat mind a 13 csatornára)

46.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata Vizsgált jellemző

Státusz Eredmény

Ugratási szekvenciák

K

CCK bitek hozzárendelése a vivő-jelekhez 5.5 Mbit/s módban 11 Mbit/s módban PBCC bitek hozzárendelése a vivő-jelekhez 5.5 Mbit/s módban 11 Mbit/s módban ChannelCollisionAvoidance funkcionalitás CCA Mode 1 – energia alapján

O

CCA Mode 4 – CarrierSense Timer alapon

O

CCA Mode 5 – energia szint érzékelés nagysebességű O CarrierSense esetén Az egész csomag adása/vétele alatt CCA–foglalt jelzés M korrekt PLCP esetén, ’hibás vivő’ rossz PDU esetén Az egész csomag adása/vétele alatt CCA–foglalt jelzés M nem specifikált, de korrekt PLCP esetén A TX antenna kiválasztása

O

A RX antenna diverzitása

O

Antenna port elérhetősége

O

Ha van antenna port, akkor 50ohmos impedancia

K O

Sugárzási energia szint szabályozása

Ha a szint nagyobb 100mW-nál, a szabályozás kötelező K Rádiós interfész működési hőmérséklete 0°C és 40°C között -30°C és 70°C között (spurious) adás ellenőrzése TX-RX váltás idő (5 mikro sec) RX-TX váltás idő () Slot idő = TX-RX idő + energia szint érzékelés idő (15mikro sec) Hibás Adat (ED) Jelzés ideje Minimális adási energia szint Adási spektrális maszk megfelel a szabványnak

BZAKA

AmI Project

47.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata Vizsgált jellemző

Státusz Eredmény

Adási frekvencia-közép toleranciája Chip-órajelének frekvencia toleranciája Adási jel felfutási idő (power on ramp) Adási jel lecsengési idő (power down ramp) Rádiós Frekvencia vivő elnyomása (supression) Adási moduláció pontossága Vevő min. bemeneti energia szintje Vevő max. bemeneti energia szintje Vevő szomszédos-csatorna szűrése Menedzsment Információs Adatbázis – MIB MIB PHY Objektum támogatása 7. táblázat: A fizikai interfész konformancia vizsgálata

2.7

SZIMULÁCIÓS VIZSGÁLAT

A szimulációs rendszereket valóságos folyamatok modellen – jellegzetesen számítógépen való „lejátszására” alkalmazzák. Előnyük hogy elvileg tetszőleges bonyolultságú rendszer vizsgálható, illetve szabadon eldönthető a modellezés mélysége. Megkülönböztetünk általános célú szimulációs nyelveket mint (pl. SIMULA, GPSS). Ezek előnye hogy széles problémaosztályra alkalmazhatók, viszont feladatonként jelentős egyedi fejlesztést igényelnek illetve a grafikus képességek általában korlátozottak. Ezen kívül beszélhetünk piaci szimulációs szoftverekről (pl. OPNET, COMNET). Jó tulajdonságaik a jól kidolgozott grafikus képességek, a kiterjedt modellkönyvtár illetve a „pilótavizsga” utáni azonnali alkalmazhatóság. Hátrányuk a magas ár illetve az általában szűkebb – pl. kommunikációs - problémaosztály. Megemlítjük még a “freeware” eszközöket (pl. OMNET++, ANCLES, CLASS, Ns-2), melyek ingyenesek. Gyakran a piaci szoftverekhez hasonló de szűkebb problémaosztályú képeségekkel. Hátrány hogy általában korlátozottabb - üzleti – felhasználhatósággal rendelkeznek. Egyedi fejlesztésű célszoftverek melyek előnyük a teljesen kézben tartható képességek valamint a könnyű felhasználhatóság. Hátrányuk a hosszú fejlesztési idő, és a szűk problémaosztály. 2.7.1

ADATGYŰJTŐ ESZKÖZÖK ÉS HÁLÓZATELEMZŐK

Ebben az alfejezetben összefoglaljuk a széleskörűen alkalmazott ismertebb diszkrét-esemény szimulációs eszközök fő jellemzőit. Szót ejtünk az ezeket támogató hálózatelemzőkről is, mint a Network Associates Sniffer-ről és az OPNET Alkalmazásjellemző Környezetről.

48.

AmI Project

BZAKA


2.7.1.1 OPNET [58] Az OPNET (OPtimized Network Engineering Tools. Optimalizált hálózattervező eszközök) egy széleskörűen alkalmazható eseményvezérelt szimulációs rendszer, mely alkalmas kommunikációs hálózatok és elosztott rendszerek modellezésére részletes protokoll és teljesítményelemzéssel. Az OPNET számos eszközt tartalmaz, melyek a modellezési és szimulációs projektek egyes szakaszainak megfelelően három kategóriába sorolhatók. Ezek a szakaszok a következők: modellspecifikáció, adatgyűjtés és szimuláció, valamint az elemzés. Továbbá előnye a könnyen kezelhető grafikus környezet és a platformfüggetlenség. Nagyszámú beépített protokollal rendelkezik, melyek forrása elérhető, módosítható, valamint újabb protokollok adhatók hozzá, és nagyszámú segédfüggvény támogatja a fejlesztést. Modellspecifikáció A modellspecifikáció során a modellező a tanulmányozott hálózati rendszer egy reprezentációját hozza létre. Az OPNET támogatja a modellek újrafelhasználását, azaz a modellek olyan beágyazott modellekre alapozhatóak, melyeket korábban készítettek el és modellkönyvtárakban tároltak. A specifikációszerkesztőkkel a modellek különböző szintű részletezettséggel adhatók meg. Ezek a szerkesztők az aktuális hálózati rendszer hierarchikus struktúrájának megfelelően osztályokba sorolják a modellezési információkat. A legmagasabb szintű szerkesztő, a Projektszerkesztő alakítja ki a hálózati topológiák, álhálózatok, és kapcsolatok modelljeiből álló hálózatmodelleket, melyeket pedig a Csomópontszerkesztővel adhatunk meg. A Csomópontszerkesztő írja le a csomópontok belső szerkezetét, funkcionális elemeiket és a közöttük lévő adatfolyamokat. A csomópontok olyan folyamatmodell modulokból állnak, melyeket a Folyamatszerkesztővel adhatunk meg. A hálózat hierarchiájának legalacsonyabb szintjén a folyamatmodellek írják le az adott modul viselkedését a protokollokkal, algoritmusokkal és alkalmazásokkal kapcsolatban, véges automatákat és egy magas szintű nyelvet felhasználva. Számos más szerkesztő is elérhető a folyamat - vagy csomópont - szintű modellek által hivatkozott különböző adatmodellek definiálására, mint amilyenek például a csomagformátumok és a folyamatok közötti vezérlőinformációk. További szerkesztőkkel készíthetünk, módosíthatunk, vagy csak megtekinthetünk különböző sűrűségfüggvényeket, melyekkel különböző eseményeket irányíthatunk. Ilyen például a csomagok küldése vagy fogadása között eltelt idő meghatározása. A modellspecifikáció-szerkesztők egy grafikus felületet biztosítanak a felhasználónak, mellyel változtathatja a modelleket ábrázoló objektumokat és a megfelelő folyamatokat. Mindegyik szerkesztő a modell egy adott absztrakciós szintjének megfelelő objektumokat és műveleteket adhatja meg. Ezért a Projektszerkesztő adja meg a hálózat csomópontjait és kapcsolatait, a Csomópontszerkesztő a processzorokat, sorokat és a hálózat csomópontjaiban lévő adó és fogadó egységeket, a Folyamatszerkesztő pedig a folyamatok állapotait és átmeneteit. Az alábbi ábra az egyes szerkesztők absztrakciós szintjeit szemlélteti.

BZAKA

AmI Project

49.


19. ábra: A három absztrakciós szint: Projekt-, Csomópont- és Folyamatszerkesztők

Adatgyűjtés és szimuláció Az OPNET a szimuláció alatt többféle kimenetet tud készíteni attól függően, hogy a modellező ezt hogyan definiálja. A modellezők legtöbb esetben beépített adattípusokat is használhatnak: kimenetvektorokat és skalárokat, valamint animációkat. A kimenetvektorok idősorozatok szimulációs adatait reprezentálják. Ezek a vektorok idő-érték párokat tartalmazó bejegyzések listájából állnak. A bejegyzések első értéke tekinthető a független, a második pedig a függő változónak. A skaláris statisztikák a szimuláció alatt gyűjtött statisztikákból származtatott egyedi értékek. Ilyen például az átlagos átviteli ráta, az eldobott cellák számának maximuma, az átlagos válaszidő és más egyéb statisztikák. Az OPNET a szimuláció alatt vagy az után megtekinthető animációkat is tud készíteni. A modellező definiálhat többféle animációt is, például csomagfolyamokat, állapotátmeneteket és statisztikákat. Elemzés A szimuláció alatt összegyűjtött adatok többsége kimenetvektor és skalár állományokban tárolódik. Ezeknek az adatoknak az elemzésére az OPNET egy Elemzőeszköz nevű segédeszközt nyújt, amely ábrázoló és numerikus feldolgozó-funkciók gyűjteménye.

20. ábra: Skaláris adatok (felső grafikon), vektor adatok (alsó grafikon) megjelenítése.

50.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata Az Elemzőeszköz az adatokat grafikonok és nyomkövetések formájában jeleníti meg. A nyomkövetések az X és Y tengelyek értékpárjainak listáját tartalmazzák. Tárolásukra és megjelenítésükre elemzőtáblákat használ. Az Elemzőeszköz a szimulációs eredmények feldolgozására és új nyomkövetések készítésére módszerek széles választékát támogatja. Ebben benne van a hisztogramok, sűrűség és kumulatív eloszlásfüggvények, valamint a konfidencia intervallumok számítása is. Támogatja továbbá a matematikai szűrők használatát is a vektor vagy nyomkövetési adatok feldolgozásához. A matematikai szűrők előre definiált számításokra, valamint statisztikai és aritmetikai operátorokra alapozott hierarchikus blokkdiagramokként vannak definiálva. A következő két ábra az Elemzőeszköz által készített grafikonokat szemlélteti.

21. ábra: Négy grafikont megjelenítő elemzőeszköz

2.7.1.2 A COMNET modellezőeszköz [58] A COMNET diszkrét-esemény szimuláció segítségével valósághű hálózatjellemzőket kaphatunk. Ilyen jellemző például a kapcsolatok kihasználtsága és a kapcsolók, forgalomirányítók teljesítménye. Módszerünkkel felmérhetjük az összeállított erősen ingadozó forgalom káros következményeit, és hatását előrejelezhetjük a teljes hálózat teljesítményére. Forgalmi mérések Az alapkofigurációs modell felépítéséhez egy nagyméretű intézményi hálózatban a Concord Network Health nevű hálózatelemző rendszerrel gyűjthető össze nyomkövetési információ. Különböző széles és keskeny sávú kapcsolatokon végezhetőek méréseket, például 45 Mbps ATM, 56 Kbps, és 128 Kbps Frame Relay összeköttetéseken. A COMNET a tranzakciókat a következőkkel reprezentálja: üzenetforrás, cél, üzenet méret, valamint az útvonalon lévő kommunikációs berendezések és kapcsolatok. Az üzenetküldési intenzitás egy beérkezési időköz eloszlással van megadva, azaz az egymást követő csomagok között eltelt idővel. Az M/Pareto modellben a Poisson-eloszlás intenzitással generál ingadozásokat vagy üzeneteket. Ezt az információt a szimulációban úgy adjuk meg, hogy az egymást követő érkezések közötti időintervallum hossza átlagosan 1/λ. Erre a célra az exponenciális eloszlást használjuk. Az exponenciális eloszlásnak a beérkezések közötti időre való alkalmazásával egy Poisson-eloszlás szerinti érkezési mintát fogunk kapunk. COMNETben a beérkezések közötti időt az Exp(1/λ) függvénnyel implementáltuk. A modellben a Concord Network Health-ben lévő mintának megfelelően 1 másodpercnek állítottuk be a beérkezési időközt, ami megegyezik λ = 1/másodperc beérkezési intenzitással.

BZAKA

AmI Project

51.


22. ábra: A hálózat topológiának az a része

23. ábra: Az üzenetforrás. távoli kliens

24. ábra: Beállítások

2.7.1.3 A GLOMOSIM modellezőeszköz [54] A Glomosim egy Parsec által fejlesztett skálázható szimulációs környezet mely párhuzamos és diszkrét-esemény modellezési képességekkel rendelkezik. Támogat drótnélküli, internet valamint műhold-kommunikációs protokollokat, valamint akár ezek közötti kommunikáció modellezését is. A Glomosim az OSI modellhez hasonlóan többrétegű architektúrát képvisel, melyek között elérhető standard API interfészek vannak. Így lehetőség nyílik a különböző rétegmodellek különböző programozók általi gyors modellfejlesztésére.

52.

AmI Project

BZAKA


25. ábra: A Glomosim rétegelt szerkezete

A szimulációs eszköz működése PARSEC fordítón alapul. Egy új protokoll implementációja az eszközben, feltételezi a C progamozó nyelv ismeretét, illetve néhány fordítói függvény használatát. Az Glomosim eszközbe beépített protokollok képességeit az alábbi táblázat tartalmazza. Mobility

Random waypoint, Random drunken, Trace based

Radio Propagation

Two ray and Free space

Radio Model

Noise Accumulating

Packet Reception Models

SNR bounded, BER based with BPSK/QPSK modulation

Data Link (MAC)

CSMA, IEEE 802.11 and MACA

Network (Routing)

IP with AODV, Bellman-Ford, DSR, Fisheye, LAR scheme 1, ODMRP, WRP

Transport

TCP and UDP

Application

CBR, FTP, HTTP and Telnet 26. ábra: A beépített protokollok képességei

2.7.1.4 NS – hálózati szimulátor [53] Az NS egy objektum orientált, diszkrét idejű, eseményvezérelt, freeware (ingyenesen letölthető) hálózati szimulátor, melyet C++-ban írtak és OTcl nyelvvel (interpretált nyelv) lehet módosítani illetve vezérelni a szimulátoron belül az objektumokat. A szimulátor rendelkezik egy C++ osztály hierarchiával (előre lefordított hierarchiának is nevezik), valamint egy, az előzőhöz szorosan kapcsolódó, OTcl osztály hierarchiával (ez az ún. interpretált hierarchia). A két hierarchia szorosan kapcsolódik egymáshoz; a felhasználó szemszögéből egy az egyhez megfeleltetés létezik az interpretált hierarchiában lévő osztály és a lefordított hierarchiában lévő osztály között.

BZAKA

AmI Project

53.


27. ábra: A C++ és az OTcl kapcsolata

A hierarchia gyökere a TclObject osztály.

28. ábra: OTcl osztályhierarchia

A felhasználó új szimulációs objektumot az értelmező nyelven (OTcl) keresztül hoz létre. Az új objektumpéldány az értelmező keresztül jön létre a memóriában és le lesz tükrözve egy neki megfelelő objektumnak a lefordított hierarchiában. Az olvasóban felmerülhet a gondolat, hogy miért szükséges két nyelv. Mivel a szimulátornak két alap feladatot kell megoldania, feladatonként célszerübb két eszközt, két nyelvet, bevetni. Először is a szimulátornak le kell írni valamely protokoll (AODV, TCP, stb.) működést, ehhez szükség van bizonyos fokú rendszerprogramozásra, ahol bájtokat, vagy biteket kell mozgatni, illetve csomagok fejléceit kell manipulálgatni, valamint az algoritmusok implementálása és futása is viszonylag gyors kell legyen. Ezeknél, a feladatoknál a futási idő nagyon fontos (ezt előre lefordított modulokkal érhetjük el), ezért kézenfekvő volt a C++ nyelv használata. Másfelöl, a szimuláció közben nagyon sokszor (mindig), szükség van bizonyos szintű konfigurációra (hány csomópont legyen a hálózatban, milyen protokollt használjanak, milyen legyen a hálózati topológia, stb.), ebben az esetben a gyors módosítási majd újrafuttatási képesség (iterálás) a fontos, ezért az OTcl tűnt a legjobb megoldásnak az NS fejlesztőinek. Az NS teljesíti mindkét fenn említett feladatot, amit egy hálózati szimulátortól elvárnak a C++ és az OTcl révén. A C++ gyorsan fut, de lassan lehet benne a módosításokat elvégezni, így inkább alkalmas a protokollok implementálására. Az OTcl sokkal lassabban fut, viszont nagyon gyorsan lehet benne elvégezni a változtatásokat (interaktív módon), így alkalmas a szimuláció gyors konfigurálására. 54.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata Az NS-t hálózati szimulációra használják, ezért kiemelném a két fő komponensét, ami elengedhetetlenül szükséges a szimulációkhoz, ez a két komponens a csomópont (node) és az összeköttetés (link), amellyel kapcsolatot teremthetünk két node között. A node (lásd 16. ábra) egy belépési pontból (entry point) és címfeldolgozókból (address és port classifier) áll, valamint a használni kívánt protokollokat (Ágens) lehet hozzá csatlakoztatni (például TCP).

29. ábra: A csomópont (node) felépítése

A link (összeköttetés) kapcsolatot teremt két node között, lehet simplex (19. ábra), duplex, félduplex ill. rádiós vagy vezetékes.

30. ábra: Összeköttetés (link)

Egy tipikus csomag folyam irányt két node között az alábbi ábrán lehet megtekinteni (31. ábra).

BZAKA

AmI Project

55.


31. ábra: A folyam útja két node között

Mivel vizsgálódásaink fókuszában a mobil ad hoc hálózatok állnak, ezért az alábbiakban bemutatjuk egy tipikus mobil csomópont felépítését, architektúráját az NS szimulátorban (32. ábra). A különböző modulok összerakása egy OTcl állományban történik, ahol a meglévő, C++-ban lefordított modulokat összerakva kialakul a mobil csomópont. A nyilak az adatcsomagok útját az ábrán, nyilak szemléltetik.

32. ábra: Mobil csomópont architektúra (NS)

56.

AmI Project

BZAKA


SZIMULÁCIÓS EREDMÉNYEK

Az IEEE 802.11b protokollra épülő többugrásos (multi-hop) mobil ad hoc hálózatokban több súlyos hiányosságot észleltünk, amelyek a MAC és PHY rétegek nem megfelelő működéséből adódnak. Mivel fontos ismernünk a protokoll viselkedését - különleges esetekben is - ezért ún. nem szabványos (invalid) szimulációs vizsgálatokat végeztünk . Az ilyen típusú rendellenességek a protokoll normál működése folyamán nem reprodukálhatók, csak szimuláció útján vizsgálhatóak.

2.7.2.1 Zavarás két hop távolságra (Double Ring) A “Double Ring" jelenséget az IEEE 802.11b fizikai réteg által használt rádiós adó-vevő egy jellegzetessége okoz, melyet az [54][56] tanulmányok írnak le. A rádiós adó-vevő jellegzetessége, hogy az a távolság, ameddig két csomópont adása zavarja egymást, jóval nagyobb (körülbelül kétszer akkora), mint az a távolság, amíg még megértik egymás adását. Az 1. csomópont körüli szürke színű gyűrű jelöli azt a területet, amin belül elhelyezkedő csomópontok zavarhatják a vételt az 1. csomópontnál, de kommunikálni már nem tudnak vele. Ez azt jelenti, hogy hiába küld egy csomópont RTS vagy CTS üzeneteket, lehetnek a hálózatban olyan csomópontok, amelyek már túl messze vannak ahhoz, hogy ezeket megértsék, de még elég közel ahhoz, hogy adásukkal a csomópont adását zavarják. Az 33. ábra illusztrálja ezt az esetet: az 1. csomópont számára a 2. csomópont ebben a (szürkével jelölt) sávban van, ezért az általa küldött csomagot az 1. csomópont nem fogja tudni értelmezni, de az a 3. csomópont által küldött csomaggal ütközést fog szenvedni.

33. ábra: A “Zavarás két hop távolságra” jelenség (NS)

BZAKA

AmI Project

57.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata Emiatt a 802.11b protokollra épülő ad hoc hálózatokban nem igazán beszélhetünk az exposed node problémáról. Ugyanis ha fellép a „két hop távolságra zavarás” jelensége, a 33. ábra C csomópontja gyakorlatilag helyesen teszi, hogy nem forgalmaz a D irányába, adása ugyanis zavarná az A-tól B-hez érkező csomag vételét. Az „exposed terminal” probléma tehát itt inkább azt jelenti, hogy a C csomópont valóban kénytelen hallgatni, ha az A csomópont éppen forgalmaz. A szabvány ugyan (opcionálisan) lehetővé teszi, hogy ha egy csomópont egy RTS hatására beállította a virtuális közeg hozzáférési mutatóját (NAV), de adott időn belül nem hallja az RTS-re válaszul küldött CTS keretet, akkor törölje a NAV-ját. A „double ring” probléma ismeretében azonban kérdéses, hogy ennek az eljárásnak van-e gyakorlati haszna. A következőkben bemutatjuk az ns-2 eszköz segítségével kapott szimulációs eredményeket.

34. ábra: A “double ring” jelenséget szemléltető topológia

A szimulációban (34. ábra) két egyidejű adatfolyam forgalmazás történik, az 1. és 2., illetve a 3. és 4. csomópontok között. Mindkét folyam az [1s; 60s] időintervallumban forgalmaz, miközben a 3. és 4. csomópontok egyenletesen távolodnak az 1->2 folyamtól, a szaggatott vonallal rajzolt nyíl irányában.

35. ábra: Zavarás két hop távolságra

58.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata A 35. ábra felső grafikonja az egyes folyamok által az adott időpontig átvitt adatok mennyiségét ábrázolja és az idő függvényében, az alsó grafikonon pedig a két folyam távolságát (a 2. és 3. csomópontok közötti távolságot) követhetjük. Továbbá a felső grafikonon bejelöltük a MAC szinten ütközés miatt elveszett csomagokat: csúcsukra állított négyszögek jelölik (az y = 2e + 6 értéknél) az adott időpontokban bekövetkezett ütközéseket. A csomópont-párok (folyamok) kezdetben 300m távolságra helyezkednek el egymástól, ilyen távolságban már a 2. és 3. csomópontok sem hallják egymást (tehát nem működik az RTS/CTS mechanizmus a közeg lefoglalására), de a double ring probléma miatt zavarják egymás adását. Ez a tény az [1s; 22s] időintervallumban történt nagyszámú ütközésből látható, illetve abból, hogy a 2. csomópont nagyon kevés adatot képes fogadni. Ennek az oka, hogy a 2. csomópontnál (amely az 1->2 folyamban a vevő) a 3. csomópont által küldött csomagok gyakran ütközést okoznak az 1. által küldött csomagokkal. Ugyanakkor az 1. csomópont által küldött csomagok a jóval távolabb levő 4. csomópontnál (tehát a 3->4 folyam vevőjénél) már nem okoznak ütközést. Látható, hogy csak „22s időpontban” tud elindulni az 1->2 folyam: ekkor 550 m távolság van a 2. és 3. csomópont között, és ebben a távolságból - a 2. csomópontnál - már nem zavarják a vételt a 3. csomópont által küldött csomagok. Ez az 550m távolság tehát valamivel több, mint kétszerese annak a távolságnak, amin belül a csomópontok még megértik egymás adását.

2.7.2.2 TCP instabilitás A TCP protokoll (Transmission Control Protocol) az IP alapú hálózatokban (így az interneten is) leggyakrabban használt adatátviteli protokoll. Szerepe végpontok közötti biztonságos kapcsolat kiépítése, azaz gondosodik az adatcsomagok garantált, kettőzésmentes célba juttatásáról és azok sorrendjének megőrzéséről. Mivel az IP alapú hálózatok forgalmának nagy részét TCP forgalom teszi ki, fontos, hogy a TCP-t az alkalmazott protokollhierarchia minden szintje támogassa. Az IEEE 802.11b protokoll felett működő TCP folyamok teljesítménye azonban bizonyos esetekben messze elmarad az optimálistól. A TCP instabilitás néven ismert jelenség részletes leírása az [54] tanulmányban olvasható. A jelenség lényege, hogy multi-hop ad hoc hálózatokban akár egyetlen TCP kapcsolat sávszélessége is erősen ingadozhat. A problémát részben az előzőekben leírt „két hop távolságra zavarás”, részben a TCP nem megfelelő torlódáskezelő mechanizmusai okozzák. Egy több ugrásból álló útvonalon (ahol folyamatos a forgalom) előfordulhat, hogy az útvonal egy adott szakaszában járó csomagok küldése zavarja a más útvonalon elküldött csomagok vételét. A jelenséget a 36. ábra szemlélteti. Az ábra szerint az 1. csomópont szeretne csomagot küldeni az 5. csomópontnak, de mivel távol vannak egymástól, a köztük levő csomópontoknak is részt kell a venniük a csomagot továbbításában. Ezzel egyidejűleg a 4. csomópont át szeretne küldeni egy csomagot az 5.-nek, ezért RTS/CTS váltás segítségével lefoglalták maguk körül a közeget.

BZAKA

AmI Project

59.


36. ábra: TCP instabilitás 4 ugrásos TCP folyam esetén

Az RTS és CTS üzenetek által lefedett területet sötétebb szürke körök jelzik. A világosabb árnyalatú mező jelzi azt a távolságot, amin belül a 4. csomópont adása még ütközhet más csomópontokéval (ez hozzávetőlegesen két ugrás távolság). Ennek megfelelően, ha az 1. csomópont (amely nem tud a 4.-5. csomópontok között lezajló átvitelről) el akar küldeni egy csomagot a 2. csomópontnak, akkor az általa küldött RTS keret a 2. csomópontnál ütközést fog szenvedni. Az 1. csomópont többször próbálkozik az újraküldéssel, és ha a szabványban előre meghatározott számú alkalommal sem sikerül választ (CTS keretet) kapnia a 2. csomóponttól, akkor jelenti az útvonalválasztó réteg felé, hogy megszűnt az összeköttetés a 2. csomópont felé (egy mobil ad hoc hálózatnál előfordulhat, hogy a csomópontok mozognak, és ezért egy korábban élő kapcsolat megszakad, erre tehát fel kellett készíteni a protokollokat). A fent leírtak hatására az 1. csomópontban működő útvonalválasztó réteg megpróbálja az 5. csomópont felé vezető útvonalat újra felderíteni, és előbb-utóbb ismét megtalálja a 2. csomópontot. Ez alatt az idő alatt viszont az 1. csomóponton található TCP protokoll időzítője is nagy valószínűséggel lejár, mivel az elküldött csomagját nem TCP nyugtázták, ezért elindítja az ismert slow-start mechanizmust, ami a kapcsolat által használható sávszélességét 1 csomagra csökkenti, (és erről az értékről kezdi növelni újra). Észrevehető, hogy a MAC rétegben fellépő problémát a TCP réteg csak súlyosbítja, hiszen pl. UDP alkalmazásával nem fordulna elő felsőbb szinteken időzítő óra lejárás és slow-start. Az [54] tanulmány szerzői megoldásként a TCP maximális ablakméretének csökkentését javasolják; ennek hatására kevesebb adat lesz egyszerre a hálózaton, és kisebb valószínűséggel észlelhető a fent leírt probléma. Ugyanakkor ez azzal jár, hogy az átvitel sebessége is lecsökken, főleg egy olyan kapcsolatnál, amelynek hosszú a körülfordulási ideje 2. 2

A körülfordulási idő (Round-Trip Time, RTT ) a TCP kapcsolatok egyik jellemző mérőszáma. Azt az időtartamot jelöli, ami egy adatcsomag elküldése és az azt nyugtázó csomag vétele között telik el.

60.

AmI Project

BZAKA


2.7.2.3 Egyenlőtlenség (Unfairness) Az egyenlőtlenség (unfairness) a következő jelenséget jelenti: ha több kapcsolat működik egyszerre egy hálózatban, és bizonyos aszimmetriák léteznek a kapcsolatok között, akkor előfordulhat, hogy egy kapcsolat „kiszorítja” a többit, és azok rovására nagyobb sávszélességet ér el. Ilyen aszimmetria előfordulhat a következők miatt: 1. A kapcsolatok eltérő hossza 2. Ha az útvonalválasztó protokoll csomagjai nem egyszerre tájékoztatják a csomópontokat a topológia megváltozásáról 3. Információs aszimmetria: az egyes kapcsolatokban a küldő csomópontok nem azonos információval rendelkeznek a másik kapcsolatról. Természetesen minél kevésbé közelíti meg a kapcsolatok összegzett sávszélesség igénye a rendelkezésre álló maximális sávszélességet, annál kevésbé jelenik meg az unfairness, hiszen ha a „kapcsolatok” csak ritkán küldenek adatokat, akkor a hátrányos helyzetben levő folyamoknak is elég ideje lesz megszerezni és használni a közeget. A továbbiakban részletesen elemezünk olyan eseteket, amelyek unfairness kialakulásához vezethetnek. Unfairness kialakulásához vezető topológia, 1. példa Ezt a topológiát és a jelenség magyarázatát a [55] tanulmány mutatja be. A csomópontok elhelyezkedését a 37. ábra szemlélteti. Két kapcsolat működik a hálózatban, az 1. csomópont küld a 2. csomópontnak, ill. a 3. csomópont a 4.-nek. Az ábrán látható két nagy kör jelöli az 1. és 3. csomópontok által “elérhető” területet, vagyis amilyen távolságból még érthetőek az általuk elküldött üzenetek, illetve amilyen távolságon belül elküldött üzeneteket ezek a csomópontok még sikeresen fogadhatnak csomagokat.

37. ábra: Információs aszimmetriához vezető topológia

Látható, hogy az 1. csomópont nem tud a 3. csomópont létezéséről, ugyanakkor a 3. csomópont hallani fogja a 2. által küldött CTS kereteket. Ezáltal a 3. csomópont mindig pontosan tudni fogja, hogy mikor próbálkozhat RTS küldésével, mert a 2. által küldött CTS keretekből tudja, hogy az 1. mikor forgalmaz. Ezzel szemben az 1. csomópont nem tudja, hogy mikor küldhet, vagyis mindig vaktában próbálja elküldeni a csomagjait. Ez azzal jár, hogy a 2. csomópont, amelyik hallja a 3. és 4. csomópontok közötti forgalmat, sok esetben nem fog tudni CTS-el válaszolni, mert zavarhatja a 3. adását. Ilyenkor az 1. csomópont mindig backoff-ra kényszerül, ami jelentősen visszaveti az általa átvitt adatok mennyiségét. Ezt az esetet hívjuk információs aszimmetriának.

BZAKA

AmI Project

61.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata Az ns-2 szimulációk során használt topológia megegyezett a 37. ábra topológiájával. Az 1. és 3. csomópontokban konstans bitsebességű (CBR) forgalomgenerátorok működnek, amelyek a [3s, 30s] időintervallumban állítanak elő 0.005 másodpercenként 1000 byte-os csomagokat. A csomópontok azonos prioritású csomagokat küldenek. A hálózatban útvonalválasztó protokoll nem működik. A grafikonon 10 szimuláció eredményének átlaga van ábrázolva. A 38. ábra az egyes folyamok által átvitt adatok mennyiségét ábrázolja.

38. ábra: Információs aszimmetria UDP/CBR forgalmak esetén

Látható, hogy a 802.11b a fentebb leírt információs aszimmetria miatt erősen egyenlőtlen helyzetet teremt a két folyam átviteli értékei között.

2.7.2.4 Unfairness kialakulásához vezető topológia, 2. példa Tekintsük a 39. ábra és 40. ábra látható hálózatot, ahol az 1. és 3., illetve az 5. és a 2. csomópontok között épült ki kapcsolat. Az elvégzett szimulációk ebben a hálózatban is az unfairness probléma megjelenésére utaltak.

62.

AmI Project

BZAKA


39. ábra: Az 1. csomópont küld adatot a 3. csomópontnak

40. ábra: Az 5. csomópont küld adatot a 2. felé

Az ábrákon szemléltetjük az egyes csomópontok által elküldött összes MAC szintű keretet (vezérlőkereteket és adatcsomagokat). Az ábrákon az idő fentről lefelé haladva nő, a függőleges vonalak pedig az egyes csomópontokat jelképezik (hasonlóan egy szekvencia diagramhoz). Vastagított vonallal jelöltek azok a csomagok, amelyeket az a csomópont kap meg, amelynek szól az adott csomag, és szaggatott vonallal azok a csomagok, amelyeket egy csomópont hall, de azok nem neki szólnak (ugyanakkor, ha ezek vezérlőkeretek, akkor felhasználja őket a virtuális vivőérzékelése (NAV) beállítására). BZAKA

AmI Project

63.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata Kérdés, hogy mi történik, ha ez a két kapcsolat egyszerre van jelen a hálózatban. Nézzük azokat az eseteket, amikor egy csomópont nem küldhet, mert éppen más küld a környezetében. Két eset fordulhat elő: 1. Ha a csomópont tud róla, hogy nem küldhet, mert hallott egy RTS vagy CTS üzenetet. Ekkor azt is pontosan tudja, hogy meddig nem küldhet, és amikor a NAV-ja lejár, a szabványnak megfelelően próbálkozik RTS küldésével. 2. Ha a küldő csomópont szabadnak véli a közeget, a vevő ellenben nem. Ebben az esetben a vevő nem fog az RTS-re CTS-el válaszolni, aminek hatására a küldőnél elindul a véletlen exponenciális „backoff”, így az, bizonytalan ideig várni kényszerül. A küldő ebben az esetben nem tudja, hogy mikor próbálkozhatna a küldéssel, így amikor lejár a backoff időzítője, ismét vaktában fog próbálkozni. A probléma itt tehát az, hogy a küldeni szándékozó csomópontnak nincs információja arról az adatátvitelről, ami miatt nem tudja elküldeni a nála várakozó csomagot. Ha a két kapcsolat egyszerre van jelen a hálózatban, akkor az 5->2 folyam azért kerül hátrányos helyzetbe, mert a folyam csomagjait továbbító csomópontok többször kényszerülnek a 2. esetben leírt várakozásra (az átvitelt pedig az előbb leírtak miatt alapvetően ezek a típusú várakozások korlátozzák). Egyrészt ez az eset fordul elő, amikor a folyam egy saját, korábban elküldött csomagját továbbítja a 3. csomópont a 2. felé, ilyenkor ugyanis a 3. csomópont által elküldött RTS üzenetet a 4. is hallja, ezért nem fog tudni az 5. csomópontnak CTS-el válaszolni. Továbbá akkor is hasonló helyzet alakul ki, amikor az 1. csomópont által küldött csomagot továbbítja a 2. csomópont a 3.-nak. Ilyenkor a 3. csomópont CTS keretét hallja a 4. csomópont, és ezért nem fog tudni válaszolni CTS-el az 5. csomópontnak. Hasonlóképpen, amikor az 1. csomópont a 2.-nak küld, akkor a 3. csomópont a 2.-tól hallott CTS hatására fogja a közeget foglaltnak tekinteni, és ezért nem fogja tudni a 4. csomópont küldését engedélyezni. A másik kapcsolat (1->3) esetében ez az eset akkor fordul elő, amikor az 5. csomópont által küldött csomagot továbbítja a 4. csomópont a 3. felé. Ekkor a 3. által küldött CTS üzenetet fogja hallani a 2. csomópont, és ezért nem fog tudni válaszolni az 1.-nek. Hasonlóképpen, amikor az 5. csomópont a 4.-nek küld, akkor a 4. által küldött CTS keretet hallja a 3. csomópont, ezért nem fog tudni a 2. csomópontnak CTS-t küldeni. Vagyis a második pontban leírt várakozásra három esetben kényszerül az 5->2 folyam, míg az 1->3 folyam csak két esetben, emiatt az előbbi a sávszélesség kisebb hányadát fogja csak megszerezni. Ha az unfairness jelenség nem lépne fel, akkor azonos sebességű forrásokat feltételezve az 1. és 5. csomópontokban, az átvitt adatmennyiségnek meg kellene egyeznie a két kapcsolatban (hiszen csomagok ideális esetben nem veszhetnek el útközben). Ebben az esetben is a szimulált topológia megegyezett a 39. ábra bemutatott topológiával. Az 1. és 5. csomópontokban konstans bitsebességű (CBR) forgalomgenerátorok működnek, amelyek 0.01 másodpercenként 1000 byte-os csomagokat állítanak elő a [3s, 30s] időintervallumban. A csomópontok azonos prioritású csomagokat küldenek. A hálózatban útvonalválasztó protokollt nem használtunk, az útvonalak manuálisan lettek beállítva. A (41. ábra) 10 szimuláció eredményének átlagát ábrázolja.

64.

AmI Project

BZAKA


41. ábra: Unfairness UDP folyamok esetén

Látható, hogy a két folyam átvitele erősen egyenlőtlen lesz a fentebb leírt problémák miatt. Azért fogja az 5->2 folyam a rendelkezésre álló sávszélesség kisebb hányadát megszerezni, mert a folyam csomagjait továbbító csomópontok gyakrabban kényszerülnek backoff-ra. Ez akkor fordulhat elő, amikor egy csomópont RTS keretet küld a következőnek, de az nem válaszolhat CTS kerettel, mert a közeget foglaltnak találja (például azért, mert egy másnak szóló RTS vagy CTS üzenet hatására beállította a NAV-ját). Ez az eset akkor fordul elő, amikor: 1. a 3. csomópont az 5. csomóponttól származó csomagot továbbítja a 2. felé (ekkor a 4. csomópont a 3. által küldött RTS keretet hallja, ennek hatására beállítja a NAV-ját, ezért nem küldhet az 5. csomópontnak CTS-t) 2. a 2. csomópont az 1. csomóponttól származó csomagot továbbítja a 3. felé (ekkor a 4. csomópont a 3. által küldött CTS keretet hallja, ennek hatására beállítja a NAV-ját, ezért nem küldhet az 5. csomópontnak CTS-t) 3. az 1. csomópont küld csomagot a 2. csomópontnak (ekkor a 3. csomópont a 2. által küldött CTS keretet hallja, ennek hatására beállítja a NAV-ját, ezért nem küldhet a 4. csomópontnak CTS-t) Ezzel párhuzamosan a másik folyam esetében is előfordulhat, hogy az 1. csomópont olyankor küld RTS keretet a 2. csomópontnak, amikor az a közeget foglaltnak látja, ez azonban ritkábban fordul elő: 1. amikor a 4. csomópont az 5. csomóponttól származó csomagot továbbítja a 3. felé (ekkor a 2. csomópont a 3. által küldött CTS keretet hallja, ennek hatására beállítja a NAV-ját, és ezért nem küldhet az 1. csomópontnak CTS-t) 2. amikor az 5. csomópont küld csomagot a 4. csomópontnak (ekkor a 3. csomópont a 4. által küldött CTS keretet hallja, ennek hatására beállítja a NAV-ját, ezért nem küldhet a 2. csomópontnak CTS-t) Mivel a források azonos sebességgel küldenek, ezek az esetek körülbelül azonos gyakorisággal fordulnak elő, azaz az 5->2 folyam csomagjait továbbító csomópontok nagyobb eséllyel próbálnak olyankor RTS-t küldeni, amikor a közeg foglalt lesz a vevőnél. Ezért gyakrabban kényszerülnek backoff-ra, és ez megmagyarázza, hogy a folyam miért tudja csak a sávszélesség kisebb hányadát megszerezni. BZAKA

AmI Project

65.


2.7.2.5 Értékelés Az IEEE 802.11 protokollra épülő multi-hop ad hoc hálózatokban több olyan probléma is kimutatott, melyek jelenlegi állapotában nem teszik alkalmassá minőségi szolgáltatás biztosítására. Ezen problémák miatt nem garantálható a minőségi hálózati forgalom, ezért a protokoll alkalmatlan kritikus alkalmazások kiszolgálására. Az utóbbi időben a vezetéknélküli technológiákat kutatók körében számos olyan próbálkozás született, amely e problémák kiküszöbölését tűzték ki célul. Ezekről a tanulmányban ejtünk néhány szót, mint a 802.11 protokoll lehetséges továbbfejlesztési irányvonalairól.

66.

AmI Project

BZAKA


2.8

MÉRÉSES VIZSGÁLAT

A WLAN térnyerése miatt manapság már minden jelentősebb távközlési kutató műhelyben vannak kisebb-nagyobb WaveLAN teszthálózatok, azonban ezek jelentős részéről nem születnek nemzetközi publikációk. Mivel a kutatások fő irányvonalát néhány jelentősebb teszthálózaton elvégzett vizsgálatok jól összegzik, elégségesnek tartjuk ezek bemutatását. Egy rövid irodalomkutatás után részletesen ismertetjük saját teszthálózatunkban folyó tevékenységeket, hogy betekintést nyújtsunk az alapvető tesztelési eljárásokba is. Ezeket a tapasztalatokat jól lehet hasznosítani például a konformancia-, teljesítmény- és együttműködési-vizsgálatok elvégzésénél. Ezt a fejezetet gyakorlati illusztrációnak szántuk az eddig ismertetett elméleti jellegű áttekintéshez. Ugyanakkor bemutatjuk a BZAKA telephelyén, a jelen projekt keretein belül kialakított mobil hálózatot és az elvégzett mérési eredményeket, kielemezve azokat és levonva a következtetéseket. A méréses vizsgálat során legfőbb célunk volt, hogy részletes elemzést adjunk a használatos eszközökről, jellemezzük azokat különböző szempontból és felmérjük, hogy mennyire felelnek meg az 1.2.1 fejezeten leírt alkalmazások elősegítéséhez. A jelen fejezet a 2005.04.22-én és 2005.04.26-án, a BZAKA AmI Projekt csoport által elvégzett méréseken alapul. A mérési jegyzőkönyv jellegű részleteket, diagrammokat, stb. a tanulmány során (*) jelzi. 2.8.1

IRODALOMKUTATÁS

Ebben a fejezetben két teszthálózatot mutatunk be. Mindkét hálózaton a vezetéknélküli adatátvitel teljesítményét vizsgálták különböző körülmények között. A San Diego California Egyetem kutatói a [38] publikáció szerzői. Ebben a cikkben egy 2.4 Ghz-en működő DSSS vezeték nélküli hálózatot állítottak össze, majd annak vizsgálták a működését. TCP folyamokat és UDP forgalmakat vizsgáltak, megpróbálták felderíteni a teljesítménybeli problémák gyökereit, hogy megtalálják azokra a megoldást. A mérések során több paramétert változtattak a jobb eredmény elérése céljából, pl. hardver, meghajtók. − Heterogén rendszer (hardver): A mérésben résztvevő gépek teljesítménye különböző volt és több interfészt használtak az átvitelben, amelyre előtte még nem volt példa. − Új megvalósítások (hardver): A korábbi publikációkban még a 900 Mhz-es rendszereket mutatták be, ezzel szemben itt a 2.4 GHz-es verziót választották. − Kétirányú átvitel: Az eddigiekben UDP forgalmat mértek, itt TCP folyamokat is vizsgálták, majd vizsgálták annak következményeit is. − Operációs rendszer (szoftver): Linux operációs rendszert választották BSD operációs rendszer helyett. A kiépített hálózat nagyon egyszerű volt, egy link (1 ugrás) két géppel (42. ábra). Az eszközök helyzetének mozgásának kihatását a mérések során nem vizsgálták, mivel a hálózat mérete ezt nem tette lehetővé. Hardver: A tesztek során három gépet használtak, amelyből mindig kettő volt aktív. Egy Linux-os alkalmazással vizsgálták, hogy a mérések során más vezeték nélküli hálózatból jövő forgalom ne zavarja az eredményeket. 2.4 Ghz-en működő ISA (asztali számítógép) és PCMCIA (laptop) kártyákat használtak, amelyek névlegesen 2 Mbps átvitelt biztosítottak.

BZAKA

AmI Project

67.


42. ábra Hálózati topológia

Szoftver: Minden eszközön Linux operációs rendszer futott, 2.0.32-es kernellel, a WaveLAN meghajtók, mint kernel modulok működtek. Úgy módosították a meghajtókat, hogy a jelszintekről és zajszintekről információt kapjanak. A tcpdump nevű alkalmazást a mérések alatt arra használták, hogy az interfészen elküldött és fogadott csomagokról információt szerezzenek, hogy a későbbiekben kielemezzék azokat. Mérési helyszínek: A három gépből kettőt használtak a mérések során, azokat több szobában helyezték el. Az eszközöket nem mozgatták, hogy a mozgásból eredendő problémák ne jöjjenek elő. A mérések során TCP és UDP forgalmat generáltak különböző csomagméret (100 byte, 500 byte, 1000 byte, 1500 byte) alkalmazásával, azért hogy a kétirányú adatátvitelt az egyirányúval is összehasonlíthassák. A csomópontok között mindkét irányban elvégezték a kísérleteket, hogy a rendszerben rejlő aszimmetriákra is fényt deríthessenek. A100 bájt csomagméretű UDP teszteknél a csomagok 90-95 %-a elveszett, sőt ezek még az interfészt sem érték el az eszközmeghajtónak köszönhetően. Az oka a buffer rövidsége volt, mivel rövid méretű csomagokat nagyon gyorsan generált a forrás, ez okozta az eldobásokat. Gyorsabb interfésszel való összehasonlításnál jobb eredményt kaptak, csak 50% került eldobásra. A TCP teszteknél ez a jelenség nem jelentkezett, mert a TCP protokoll ablakos forgalomszabályozást alkalmaz. Azt tapasztalták, hogy időnként a vártnál nagyobb TCP csomagok haladnak át a fizikai csatornán. Oka, hogy a visszautasított csomagok egy várakozási sorba kerülnek és nagyobb csomagokká szerveződnek. Ezt a folyamatot erősíti egyrészt a MAC alrétegnél a CSMA/CA protokoll versenyeztetési szakasza által okozott késleltetés. Érdekes módon alakult a TCP és az UDP forgalom átviteli sebessége a hardver függvényében. Az ISA interfészek közötti kommunikációban volt az UDP átviteli sebessége a legnagyobb, 1.8 Mbps, míg ez PCMCIA eszközök között már csak 1.28 Mbps volt. Mi ennek az oka? Az, hogy az ISA kártya gyorsabban küld, mint a PCMCIA kártya. TCP forgalomnál az ISA kártya mivel gyors küldő, elárasztja a vevőt, így a vesztés miatt gyakori újraküldésre van szükség, illetve torlódásvezérlésre van szükség, ami lecsökkenteni az átviteli sebességet. PCMCIA kártyánál nincs ilyen probléma, mivel az lassabb küld. Másik különbség, hogy a PCMCIA kártya a küldések előtt mindig eldobott néhány csomagot az átvitel előtt, ezzel sebességcsökkenést okozva az ISA kártyához képest. A PCMCIA kártya érzékenyebb a zavarokkal szemben, ennek köszönhetően hatótávolsága is kisebb. A szerzők az előző mérésekhez képest több mindent megvizsgáltak, azokat állandóan változtatták, majd a különbségek alapján keresték a probléma gyökerét. Vizsgálták a különböző interfészeket, hardver eszközöket, az operációs rendszert.

68.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata A Texas és a Cincinatti Egyetem kutatói egy olyan hálózatot mutatnak be ([39]), amely az WLan hálózatok ad-hoc üzemmódbeli teljesítményét vizsgálták az útvonalválasztás és a szállítási réteg szempontjából. Az operációs rendszer részeként implementáltak egy útvonalválasztó protokollt, amelyet a mérések során felhasználtak. A mérések során szintén asztali számítógépet és laptopokat használtak fel (43. ábra).

43. ábra Több ugrásos teszthálózat

Minden számítógép Linux operációs rendszert futtatott. Az asztali gépben a Lucent WaveLAN ISA típusú kártyája, a laptopokban PCMCIA típusú kártyája működött. Mivel a kártyák még az első generációs sorozatból származott, ezért nem ismerték az RTS/CTS mechanizmust. A [37] cikkhez hasonlóan azt tapasztalták, hogy a számítógépek teljesítményeiben levő különbségek befolyásolják a hálózat teljesítményét. A PCMCIA kártya hasonlóan az előbb említett cikkhez itt is rosszabb (1.2 Mbps) eredményt produkált, mint az ISA verzió (1.8 Mbps). A PCMCIA bufferelési technikája okozta az átvitel csökkenését. A mérések során egy független démon program segítségével törölték az útvonaltáblában levő bejegyzéseket, hogy így kényszerítsék rá az állomásokat új útvonal keresésére. Ezek után elsőnek azt mérték meg, hogy mennyi ideig tart az útvonalak felderítése. Ez fontos a hálózat teljesítményének vizsgálatában, hiszen ez jelentősen megnövelheti a késleltetések nagyságát. Ehhez az öt gépet láncba állították úgy, hogy azok csak a saját szomszédaikat hallották, de a többi állomást nem. A hálózatban nem volt más forgalom, kivéve azt, ami az útvonal felderítésére szolgált. Azt tapasztalták, hogy az ugrások növekedésével a felderítési idő növekedett, ez egy ugrásnál 3 másodperc, míg négy ugrásnál már 15 másodperc volt. Fontos megjegyezni, hogy az első ugrás az ISA és PCMCIA kártya között volt, ez okozta azt, hogy PCMCIA kártyák között az egy ugrásra mért idő 4 másodperc volt. Az előbbiekben terhelés nélküli hálózaton mértek. Utána UDP forgalom mellett is lemérték az előzőeket, az első csomópont 0.6 Mbps átviteli sebességet produkálva küldte el az UDP csomagokat a lánc végén levő állomásnak. Azt tapasztalták, hogy több ugrásnál az útvonal felderítésének ideje jelentősen megnőtt, ennek oka az ütközés volt. A harmadik mérésnél inkább az UDP teljesítményének vizsgálatára koncentráltak. Az elrendezés továbbra sem változott. A méréseket változó felajánlott forgalomra, különböző számú állomásra is lefuttatták. Azt tapasztalták, hogy az első két ugrásnál az átviteli sebesség nagyjából megegyezett a felajánlott forgalommal, míg az utána következő ugrásoknál ez már jelentősen megváltozott, a csomageldobás jelentősen megnőtt. A probléma hátterében a rejtett csomóponti probléma állt. Említettük, hogy a kártyák nem ismerhették az RTS/CTS mechanizmust.

BZAKA

AmI Project

69.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata A negyedik mérésnél a TCP teljesítményét vizsgálták. Az elrendezés hasonló volt az előzőekhez, de az állomásokat óvatosabban helyezték el úgy, hogy azok a két ugrásra levő szomszédok átvitelét is érzékelhessék, de köztük ne jöjjön létre egy újabb link. A TCP folyamokat FTP segítségével állították elő, majd tcpdump nevű segédprogram segítségével vizsgálták azt. Tapasztalatuk azt mutatta, hogy az ugrások növelésével az átviteli sebesség fokozatosan csökkent. Ámbár az ütközések és a csomag eldobások száma az elhelyezésnek megfelelően csökkent, a felderítés ideje a backoff-nak köszönhetően növekedett. Még jelentős teszthálózat működik a francianemzeti informatikai laboratóriumban (INRIA), valamint a Berkeley Egyetemen [40][41]. Az INRIA kutatói teljesítményelemzéseket végeztek, míg a Berkeley Egyetemen ezen túlmenően biztonsági kérdésekkel, valamint nagyobb sebességgel (városi közlekedésben résztvevő járművek) mozgó állomások interferencia és handover jelenségekkel is foglalkoztak.

70.

AmI Project

BZAKA


A BZAKA ÁLTAL, A PROJEKT KERETÉBEN KIÉPÍTETT MOBIL HÁLÓZAT BEMUTATÁSA

A BZAKA mobil WLAN teszthálózata alapjául a 802.11b és a Bluetooth (IEEE802.15.1) szabvány szolgál. A telepített eszközök és azok rövid ismertetése a következő ábrákon láthatók. Ugyanakkor röviden ismertetjük a felhasznált szoftvereket és mérési eszközöket is, amelyeket a kísérletek során használtunk.

44. ábra Proxim Orinoco WLAN hálózati kártya

45. ábra 3COM Bluetooth hálózati kártya

46. ábra Bázisállomás (Acces Point – AP)

BZAKA

AmI Project

71.


47. ábra Körsugárzó antenna

48. ábra Mobil állomás

49. ábra GPS készülék

72.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata A következőkben bemutatott mérések fizikai eszközei IEEE802.11b szabvány alapú Proxim gyártmányú Wavelan hálózati kártyák voltak (44. ábra). Típusuk Proxim Orinoco Gold 11Mb. Ugyanakkor használtunk 3Com® Wireless Bluetooth™ típusú Bluetooth hálózati kártyákat (49. ábra) is a további mérésekhez. A mérések során a hálózati kártyákat (PCMCIA típusú) a mobil állomásoknak használt laptopokba kellett tenni (48. ábra). A laborban egy bázisállomás (Access Point) állt rendelkezésre (46. ábra). A bázisállomás típusa Linksys WRT54G. A mérések folyamán két mobil állomás (laptop + wavelan kártya) és egy bázisállomás állt rendelkezésre. A bázisállomás egy Ethernet alapú fix hálózatra hidal át (bridgeing). A nyílt terepen készült mérések esetében a földrajzi helyzet meghatározásához egy Garmin GPSmap 60CS típusú GPS vevőkészüléket használtunk. A mérések során felhasznált programok: − WaveLan hálózati Orinoco 0.9b.

kártya

meghajtóprogram:

Orinoco

0.7

verzió,

illetve

− időszinkronizációt megvalósító program: NTP (Network Time Protocol) 4.0.99 verziójú megvalósítása. A mérések előtt szükséges volt a mobil hálózat szinkronizálása egy külső számítógépre. A mérés csak a szinkronizáció után kezdődhetett el. Ellenkező esetben a különböző pontokon mért adatok időben elcsúszhattak volna egymástól, illetve az adatokból nem a valós információkat kaptuk volna meg. − DBS (Distributed Benchmark System) forgalom-generáló és mérő program 1.1.5a verzió [52]. A mérésekben a háttérforgalom előállításához a DBS nevű forgalomgenerátort használtuk. A DBS program egy jól konfigurálható alkalmazás, amely segítségével tetszőleges forgalmat lehet előállítani. A következőkben röviden bemutatjuk a DBS-t és annak részeit. − A DBS egy elosztott forgalomgenerátor, amely az általa előállított folyamok néhány forgalmi paraméterének kiértékelését is elvégzi. A program három egységből áll. Egyrészt tartalmaz egy dbsc nevű vezérlő modult. Másrészt a forgalom forrásaként illetve nyelőjeként szereplő összes gépen futnia kell a dbsd démonnak. A harmadik modul a kiértékelő és grafikus ábrázoló program. A forgalomgenerálás első lépéseként a vezérlő elküldi a leendő forgalomforrásnak, illetve nyelőnek a generálandó forgalom előállításának szabályát illetve azt, hogy a mérés mennyi ideig fog tartani. Ezután a forrás és a nyelő felveszi a kapcsolatot, és elkezdődik a tényleges forgalom küldése. Mikor a parancsfájlban leírt csomagmennyiség átvitelre került, vagy lejárt a mérésre szánt idő, a forgalom nyelője elküldi a vezérlőnek az általa megkapott és regisztrált összes csomag paramétereit: sorszámát, küldésének és megérkezésének idejét és a csomag méretét. Ezeket a dbsc program egy fájlban rögzíti. Ezen adatokat a vezérlő feldolgozza. Az eredményeket pedig a harmadik modullal a dbs_view-val akár grafikusan is megjeleníthetjük. A mérési konfigurációk és a pontos rendszerleírás megtalálható az 1. sz. Mellékletben.

BZAKA

AmI Project

73.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata MÉRÉSI ÖSSZEÁLLÍTÁS ÉS MÉRÉSI EREDMÉNYEK BEMUTATÁSA A kísérleti hálózaton több teljesítményvizsgálati mérést végeztünk. A mérési elrendezéseket úgy alakítottuk ki, hogy az 1.2 fejezetben bemutatott alkalmazásokhoz minél valószerűbben illeszkedjenek. Így jellemezni tudtuk a 802.11b szabvány hatékonyságát és felhasználhatóságát a már említett alkalmazásokban. A mérések első részét zárt teremben végeztük. Ekkor a fő célunk az volt, hogy összehasonlítsuk a szabvány főbb jellegzetességeit akkor, ha a hálózati eszközök bázisállomás illetve ad hoc üzemmódban működnek, amivel az 1.2.2, 1.2.3 és 1.2.4 fejezetekben bemutatott alkalmazásokra való használhatóságot kívántuk vizsgálni. A mérések második részében az ad hoc üzemmód tulajdonságait vizsgáltuk valós, nyílt terepen, kipróbálva ezzel a szabvány használhatóságát az 1.2.1 fejezetben bemutatott alkalmazások esetén. A méréseket először a szakirodalomban talált mérésekhez hasonlóan alapmérésekkel kezdtük, hogy olyan információkhoz jussunk, amelyek alapot adnak a bonyolultabb mérésekhez.

2.8.2.1 Mérési leírás a WLAN hatótávolságának és más paramétereinek megállapításához A WLAN eszközök gyártói által megadott paraméterek alapján olyan mérési környezet felállítására volt szükség, ahol az áthidalandó távolság nem több 1000 m-nél, és a kommunikációs eszköz szempontjából releváns egyéb paraméterek (rálátás a másik antennára, visszaverődést okozó felületek a közelben, azonos kommunikációt használó, de a mérés szempontjából idegen eszközök zavaró hatása) mérhetők, illetve becsülhetők. Mivel a mérés költségvetése és a hozzá rendelkezésre álló idő korlátozott volt, szükségessé vált az antennák távolságának és egymáshoz képesti sebességének mérésére egy hatékony módszert használni. Az ideális eszköz egy számítógéphez illeszthető lézeres távolságmérő eszköz lett volna, ám egy ilyennek a költségei nem feleltek meg a körülményeknek. Az adott helyzetben optimális megoldást a GPS technika alkalmazása jelentette. A mérésekre különböző helyszíneken került sor: − Vasbeton-szerkezetű házban ahol más, 2.4GHz-en működő eszközök is jelen vannak. − Ipartelepek között futó egyenes mellékutcában, ahol az utca szélén többemeletes vasbeton, illetve fémszerkezetű épületek vannak, melyekben, a mérésben alkalmazott kommunikációs protokoll szerint kommunikáló eszközöket is használnak. − Családi házas lakóövezetben, egyenes utcában, ahol a házak egy-, maximum kétemeletesek és mindegyikhez kb. 600m2 nem beépített telekrész is tartozik és – méréseink ideje alatt – WLAN technológiát használó eszközt nem üzemeltetnek. − Egyenes országúton, nyílt terepen, mezőgazdasági területek közt Láthatjuk, hogy az elvégzett mérések két kategóriába sorolhatók: − Mérések zárt környezetben − Mérések nyílt terepen

74.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata Az első kategóriába eső mérések esetén egy telepített bázisállomás és két mobil egység szolgált mérőállomásként (lásd 2.8.2 fejezet). A két mobil egység közötti kommunikációs paramétereket vizsgáltuk abban az esetben, ha azok bázisállomás vagy ad hoc üzemmódban működtek. Megjegyezzük azt, hogy ezen mérések során igyekeztünk mindig a bázisállomás hatósugarán belül maradni a mobil egységekkel és főleg az üzemmódok közti különbségeket felderíteni. A második kategóriába tartozó mérések két, ad hoc üzemmódban működő mérőállomással került lebonyolításra (lásd 2.8.2 fejezet). A mérések során az egyik mérőállomás a mérési helyszínen egy helyben állt (telepített egység), míg a másik egység mozgott (mobil egység). A telepített mérőállomás helyzete GPS segítségével (200 mérés átlagából képezve) legalább ±4m pontossággal került meghatározásra. A mobil mérőállomás egy személyautó tetején került elhelyezésre, melynek helyzetét a telepített állomás helyét is meghatározó GPS eszközzel lehetett meghatározni. A mérések többsége során a mobil állomás kis, egyenletes sebességgel (6-10km/h) eltávolodott a telepített állomástól, majd kijutva az adáskörzetből megfordult és ugyanígy visszahajtott. A GPS készülék által másodpercenként mért pozíció és sebességadatokat – időbélyeggel ellátva – a mobil állomáshoz tartozó számítógép rögzítette. A GPS a mérések teljes időtartama alatt legalább ±5m pontossággal mért, de a visszaállási pontosság a mérések során ±2m-nél jobb volt. Látni fogjuk a mérések elemzése során, hogy az eredményekre nagy hatással van a közúti forgalom mértéke is. Éppen ezért a méréseket kis és nagy közúti forgalom esetén is elvégeztük. A mérés alatt a mobil és a telepített mérőállomás számítógépei folyamatosan működtek és naplózták a kommunikáció paramétereit időbélyeggel együtt. A mérés végső kiértékelésére off-line módon zajlott. Ennek során az időbélyegek alapján egymás mellé kerültek a távolság, sebesség adatok a kommunikáció paramétereivel, melyek segítségével kerültek a grafikonok megrajzolásra.

2.8.2.2 Mérések zárt környezetben Ad Hoc és Bázisállomás üzemmódok összehasonlítása egy adatfolyam esetén Az összehasonlító mérések eredményei szolgálnak referenciaként annak eldöntéséhez, hogy mely teljesítményváltozások forrása a fizikai réteg szintjén előforduló esemény (ütközés, alacsony jelszint), a fizikai réteg és a csomagtovábbítás kapcsolata, illetve az útvonalkeresés. Ezen méréseknél egy-egy adatfolyamot alkalmaztunk a topológiában szereplő két mérőállomás között (lásd (*) 50. ábra). A két mobil állomás első esetben ad hoc üzemmódban működött, míg második esetben bázisállomás módban. Mindkét esetben TCP és UDP forgalom alkalmazásával vizsgáltuk a rendszer viselkedését. A felajánlott forgalom 8 Mbps volt.

(*) 50. ábra Hálózati elrendezések Bázisállomás ill. Ad Hoc üzemmódban

BZAKA

AmI Project

75.


(*) 51. ábra Átviteli sávszélesség különböző üzemmódokban.

Bár a WaveLAN hálózati kártyák fizikai rétege 11Mbps-os sávszélességgel rendelkezik, a mérések során tapasztalható, hogy az adatkapcsolati réteg feletti rétegek számára a gyakorlatban csak 5Mbps-os sávszélességet biztosítanak. Ez a CSMA/CA közeghozzáférés [54] többletforgalmával és a keretek közt előírt szünetekkel magyarázható. UDP forgalom esetén ((*) 51. ábra) hasonló a helyzet, bár a sávszélesség alacsonyabb.

(*) 52. ábra Késleltetés különböző üzemmódokban

Az ad hoc üzemmódhoz képest, bázisállomás üzemmódban a TCP és az UDP forgalom esetében is a sávszélesség a felére csökkent. Ezt tapasztaljuk, ha a (*) 51. ábra látható sávszélesség-görbéket hasonlítjuk össze. Ez a jelenség annak tulajdonítható, hogy a bázisállomás üzemmódban az adatforgalom minden esetben a bázisállomáson keresztül zajlik. Így az upstream és a downstream forgalom ugyanazt a közeget használja, tehát a rendelkezésre álló sávszélességet meg kell osztani köztük. Ez abban az esetben is fennáll, ha a két mobil egység közvetlenül látja egymást.

76.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata A fenti jelenségen kívül UDP forgalom esetén tapasztalható, hogy a csomagkésleltetés is jelentősen megnövekedett (lásd (*) 52. ábra). Ez a késleltetés-növekedés azzal magyarázható, hogy az ad hoc módhoz képest csökkent a sávszélesség, ugyanakkor az alkalmazott forgalom miatt a meghajtó puffere jelentős mértékben feltöltődik keretekkel. Időnként a meghajtó eldob a pufferben várakozó „legöregebb” csomagok közül annyit, hogy a puffer telítettsége adott érték alá csökkenjen. Ezt alátámasztja a csomagküldési, érkezési információkat tartalmazó állomány is. Az eredményeket vizsgálva kiderül, hogy bár a csomagvesztés alacsony mértékű (2,84%), ezek a csomagvesztések sorszám szerint kettő egymást követő, rövid időintervallumban történnek. Ez magyarázza a késleltetés kétszeri visszaesését is ((*) 52. ábra). Az átviteli sávszélességet azonban nem befolyásolja, hiszen a keretek állandó ütemben haladnak, annyi különbséggel, hogy az „öregebb” csomagok eldobása után „frissebb” csomagokat küldünk. Ad Hoc és Bázisállomás üzemmódok összehasonlítása több adatfolyam esetén Az előző méréseknél mindig egy-egy adatfolyamot vizsgáltunk. Az eredményekből láthattuk a sávszélesség és a késleltetések változását attól függően, hogy milyen üzemmódban működött a hálózat. Kérdés, hogy milyen változások következhetnek be akkor, ha több gépről (53. ábra) van szó, és egyszerre több TCP folyam és UDP forgalom generálódik a hálózaton belül. Megjegyzés: az ábrán látható több mobil egység lényegében egy-egy adatfolyamot szimbolizál.

53. ábra. Több munkaállomásos elrendezés

Az alábbi méréseknél egy-egy TCP folyam, illetve UDP forgalom indult a három mobil állomásról egy negyedik felé ad hoc és bázisállomás üzemmódban. A folyamok ugyanabban az időben indulnak.

(*) 54. ábra 3 db TCP folyam Ad Hoc módban (csomagsorszám, sávszélesség)

A TCP átvitel esetén látható, hogy a három folyam osztozik a használható sávszélességen ((*) 54. ábra). Ha a keretek sorszámának növekedését vizsgáljuk, láthatjuk, hogy az egyes folyamok nem haladnak ugyanolyan prioritással, de a különbség szinte elhanyagolható. A sávszélesség a folyamok számának arányában erősen lecsökkent. BZAKA

AmI Project

77.


(*) 55. ábra 3 db UDP adatforgalom Ad Hoc módban (késleltetés)

Ha az UDP forgalmak késleltetését vesszük figyelembe ((*) 55. ábra), láthatjuk, hogy az egyik adatforgalom csomagjai minimális késleltetéssel, míg a másik két forgalom csomagjai 100 ms-os késleltetéssel érkeznek meg. Ezek alapján látszik, hogy az első csomagot elküldő gép előnyre tesz szert a többihez képest. Hasonló eredményeket tapasztalhatunk, ha megvizsgáljuk e forgalmakat bázisállomás üzemmódba kapcsolva.

(*) 56. ábra 3 db TCP folyam bázisállomás üzemmódban (csomagsorszám, sávszélesség)

78.

AmI Project

BZAKA


2.8.2.3 Mérések nyílt terepen A nyílt terepen végzett méréseket UDP forgalommal végeztük. A mérés során az adó egység ezredmásodpercenként egy 1024 bájt nagyságú csomagot küldött a vevőnek, azaz a generált forgalom 8 Mbit/s sebességű volt. Az előzetes próbamérések során azt láttuk, hogy a WiFi rendszer ad hoc üzemmódbeli maximális átbocsájtóképessége a gyakorlatban 5 Mbit/s körüli. Ennek alapján állítottuk be a felajánlott forgalmat 8 Mbit/s bitsebességűre, hogy az biztosan mindig kitöltse a rendelkezésre álló sávszélességet. Ezzel elkerültük, hogy esetleg azért mérjünk a ténylegesnél alacsonyabb átbocsájtóképesség értéket, mert nem generálunk a kapacitás kihasználásához elegendő adatforgalmat. Az adási puffer és a vételi puffer is 32 Kbyte nagyságú volt. A mérések időtartama 120 és 360 másodperc között változott. Ipartelepi mérések (1) Amint már említettük, ebben az esetben a mérések olyan környezetben kerültek megrendezésre, ahol többemeletes vasbeton szerkezetű épületek voltak jelen. Ezekben az épületekben több helyen is használtak, a mérésekben alkalmazott kommunikációs szabvány szerint működő eszközöket. Ezek, a mérés helyszínéhez nagyon közel működő eszközök, ugyanazt a szabványt használva, ugyanazon frekvenciasávon, interferenciát idézve elő nagymértékben zavarták a mérések pontosságát. Az első méréscsoport helyszínéül a BZAKA telephelyéhez közel eső Kondorfa utcát választottuk. A környéken több nagyobb épület van jelen, ahol nem ritka az olyan cégtelephely, ahol vezetéknélküli hálózati szolgáltatás működik. Ugyanakkor a vasbeton szerkezetű épületek is erős hullám-visszaverődést produkáltak, miáltal interferenciát okoztak a mérések során. Láthatjuk a mérési eredményekből, hogy hiába az egyenes útszakasz és a kis közúti forgalom, az említett zavaró körülmények nagyon lerontották a rendszer mért teljesítményét. Az ábrán láthatóak a mérés során nyert eredmények, amelyek kiterjednek az adatkapcsolati átvitelminőséget jellemző paraméterekre (a. ábra: Sávszélesség; b. ábra: Csomagkésleltetés; c. ábra: Késleltetés-ingadozás), illetve a vezetéknélküli rádiós kapcsolat minőségét mutató értékre (e. ábra: Jelszint). A d. ábra mutatja a két állomás közti távolság változását az idő függvényében. Az ábrán látható, hogy a 2.8.2.1 alfejezetben említett mobil állomás megközelítőleg egyenletesen távolodik a telepített állomástól. A GPS készülék által mért adatokból kiderül, hogy a mobil egységet hordozó jármű sebessége átlagosan 6 km/h volt. Az a. ábrán látható sávszélesség-grafikon csökkenő tendenciája a két mobil állomás közti távolság növekedésének tudható be. A sávszélesség-grafikon magán hordozza az interferencia és a mérési környezetben jelenlévő zavaró körülmények jeleit. A következtetést a görbe jellegéből, azaz az erős ingadozásból vonhatjuk le. Ebben a környezetben a kapcsolat igen hamar „leromlik”, és használhatatlanná válik. Ugyanakkor vizsgálva a rádiós kapcsolatot jellemző jelerősség-grafikont (e. ábra), megállapíthatjuk, hogy, ha a jelszint -85dBm alá csökken, az adatkapcsolat a két egység között megszakad. A hálózati összeköttetés megszakadása kb. a 60. másodpercben történik meg, amikor a két egység közti távolság kb. 70 méter (d. ábra). Kijelenthetjük tehát, hogy ebben az esetben a hatótávolság nem több mint 70 méter. A csomagkésleltetés és ingadozás (b., c. ábra) is mutatja a kapcsolat minőségének a csökkenését. A két egység közti távolság növekedésével együtt nő az ábrán látható két paraméter.

BZAKA

AmI Project

79.


450 400 350 Distance [m]

300 250 200 150 100 50 0 0

50

100

150

200

Time [sec]

a)

d) 0 -10

0

50

100

150

200

-20

SL [dBm]

-30 -40 -50 -60 -70 -80 -90 -100 Time [sec]

b)

e)

c) (*) 57. ábra: a) Sávszélesség; b) Csomagkésleltetés; c) Késleltetés-ingadozás (Jitter); d) Távolság; e) Jelerősség;

80.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata Ipartelepi mérések (2) Megismételtük az „Ipartelepi mérések” kategóriájába tartozó vizsgálatokat egy olyan helyszínen, ahol az épületsűrűség és az egyéb zavaró tényezők hasonlóak az előbbi esethez. Különbséget képez a közúti forgalom intenzitása. Amíg az előbbi esetben nem volt jelen egyéb közlekedő jármű a mérési helyszínen a mérésben résztvevő autón kívül, addig ebben az esetben igen nagy közúti forgalom játszott közbe. Az eredményeket az (*) 58. ábra mutatja. Jelen esetben a mobil egységet hordozó jármű nemcsak távolodott a telepített állomástól, de egy idő után megfordult és visszafele haladva közeledett is. Az átlagsebesség ez esetben 17 km/h volt, néhol elérve akár a 42 km/h-t is. Az adatforgalmat jellemző grafikonokból kitűnik az, hogy mikor szakad meg a hálózati kapcsolat a két állomás között. Ezt mind az átbocsátóképességet mutató a. ábra, mind a jelerősséget jellemző e. ábra is mutatja. Látható az a. ábrán, hogy a mérés kezdetekor, amikor a két mérőegység még egymáshoz közel helyezkedett el, a kapcsolat által biztosított sávszélesség értéke meghaladja az 5 Mbps-ot. Ahogy a két egység közötti távolság nő, ez a biztosított sávszélesség egyre csökken, míg el nem éri a 0-t. Ugyanígy csökken a jelerősséget jellemző érték is (e. ábra), míg el nem éri a határesetnek számító -85 dBm értéket. Ez esetben mondhatjuk azt, hogy a kapcsolat a két állomás között megszakadt. Ha összevetjük a sávszélesség-, a jelerősség- és a távolság-grafikonokat, látható, hogy a kapcsolat megszakadása körülbelül a 100. másodpercben történik, amikor a két állomás közti távolság kb. 500 méterre tehető. Az a. ábrán megfigyelhető az is, hogy, a kapcsolat kb. a 200 másodpercnél újra „élni” kezd. Érdekesség az, hogy a d. ábrából látható, hogy ebben a pillanatban a két állomás közti távolság több mint 1000 m. A jelenséget a magas interferencia-hányadosnak tulajdoníthatjuk. Látható a sávszélesség-grafikonon, hogy a 200-310 mp.-es intervallumon az adatkapcsolat igen rossz minőséggel bír (az átlagos átvitel kevesebb mint 1 Mbps, nagyon változékony, néhol elérve a 0 Mbps-t is, tehát megszakad). Ugyanakkor a jelerősség is mindvégig közelíti a -85dBm értéket. Az a pillanat, amikor a kapcsolat újra minőségi javulást tudhat be, kb. a mérés 310 mp.-ben következik be. Ekkor a két egység közötti távolság megegyezik a kapcsolat bontásánál mért távolsággal, azaz 500 m.-el. Megállapítható tehát, hogy ez esetben a hálózat hatósugara 500 m. Megvizsgálva a késleltetés és a késleltetés-ingadozás grafikonokat is, az előbbi észrevételeket tehetjük. A késleltetés-grafikonon látható nagy ugrás a mobil egységek pufferelési tulajdonsága miatt következik be. Ez esetben tehát, amikor a kapcsolat megszakad, a mobil egység hálózati kártyája pufferben tárolja az elküldendő adatcsomagokat. Amint a kapcsolat újra „élni” kezd, ezeket a csomagokat megpróbálja átküldeni. Azt az időintervallumot reprezentálja csomagkésleltetés grafikonon látható ugrás a 100. mp.-ben, amit az adatcsomagok a pufferben töltöttek, vagyis amíg a kapcsolat teljesen meg volt szakadva. Látható, hogy a késleltetésingadozás-görbe is követi az előbbi észrevételt. Ebben a környezetben (Ipartelepi környezet) általánosan megállapítható tehát, hogy, egy sűrűn beépített területen, ahol ugyanazon vezetéknélküli kommunikációs szabvány szerint több hálózat is működik, igen rosszul használható dinamikus és mobilis vezetéknélküli hálózatok létrehozására az IEEE 802.11b szabvány. Ez a minősítés még romolhat, abban az esetben, ha közúti forgalom is jelen van a mérés helyszínén.

BZAKA

AmI Project

81.


1400 1200

Distance [m]

1000 800 600 400 200 0 0

100

200

300

400

Time [sec]

a)

d) 0 -10 0

100

200

300

400

-20

SL [dBm]

-30 -40 -50 -60 -70 -80 -90 -100 Time [sec]

e)

b)


82.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata Lakóövezeti mérések Ezeket a kísérleteket egy olyan családi házas lakóövezetben végeztük el, ahol az egyenes utca “direkt rálátást” biztosított. Ez azt jelenti, hogy az elhelyezett telepített mérőállomás és a mobil állomás között nem volt akadály (épület, domborzat, stb.) a mérések folyamán. A kísérlet helyszínén a házak egy-, maximum kétemeletesek és mindegyikhez kb. 600m2 nem beépített telekrész is tartozik és – méréseink ideje alatt – WLAN technológiát használó eszközt nem üzemeltetnek. A kísérlet ideje alatt a helyszínen nem volt közúti forgalom, vagy csak nagyon elenyésző arányban. Jelen esetben is a mobil állomást hordozó jármű egyenletes sebességgel, átlagosan 9 km/h-al távolodott a telepített eszköztől. Az eredményekből látható ((*) 59. ábra), hogy a kommunikációt sokkal jobb minőségi paraméterek jellemezték, mint előbbi esetben. Ha az a., e. és d. ábrákat összevetjük, láthatjuk, hogy a kapcsolat kb. 500 méteres távolságig „élt”. A hirtelen minőségcsökkenést (a 150.-ik másodpercben) a két mérőállomás közti “direkt rálátás” megszűnése okozta (az utca végi kanyar miatt). A kommunikációt jellemző három grafikonon (a., b., c. ábra) fellelhető hirtelen minőségcsökkenések (tüskék) annak tulajdoníthatók, hogy időnként egyegy autó fordult be az utcába, zavarva ezzel a két mérőegység kommunikációját. Levonhatjuk a következtetést tehát, hogy a WLAN technológiát alkalmazó rendszerek esetén, nagy távolságok áthidalását csak “direkt rálátás” biztosításával érhetünk el. Ezt a következtetés a következőkben bemutatott mérési eredmények is alátámasztják.

BZAKA

AmI Project

83.


500 450 400

Distance [m]

350 300 250 200 150 100 50 0 0

50

100

150

200

250

300

200

250

300

Time [sec]

a)

d) 0 -10

0

50

100

150

-20

SL [dBm]

-30 -40 -50 -60 -70 -80 -90 -100 Time [sec]

b)

e)


84.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata Országúti mérések (1) A bemutatott eredményekből tapasztalhattuk, hogy a lakóházak, vasbeton épületek és a közúti forgalom milyen hatással van a vezetéknélküli, WLAN típusú adatkommunikáció minőségi paramétereire. A következő két kísérlet során azt vizsgáltuk, hogy mi történik akkor, ha a lakóházak és egyéb épületek nincsenek jelen. Vizsgáltuk, hogy ez esetben szükségeltetik-e a “direkt rálátás” a két mobil egység között, illetve, hogy mennyire befolyásolja a közúti forgalom a kommunikációt. Mindezen, fent említett feltételeket figyelembe véve a (*) 60. ábra által összefoglalt eredményeket olyan, lakóterületen kívüli helyeken mértük, ahol nem volt jelen közúti forgalom. A mérés itt is vizsgálta a „direkt rálátás” szükségességét nagy távolságok áthidalására. A mérő-jármű ez esetben kb. 550 méteres távolságról indult és egyenletes sebességgel közeledett (kb. 7 km/h-el) a telepített egységhez. Megjegyezzük, hogy a mérés indításakor a két mérőállomás között nem volt biztosított a „direkt rálátás”. Érdekes jelenséget figyelhetünk meg a sávszélesség-grafikonon. Mivel a két állomás között a „direkt rálátást” biztosítottuk, a kapcsolat minősége jelentős javulást mutat. Ez kb. a 80. másodpercben figyelhető meg. Ekkor a két állomás közti távolság kb. 300 méter, a jelszint meghaladja a -85 dBm-et és a sávszélesség is növekedni kezd. Látható az a. ábrán, hogy a biztosított sávszélesség kb. 90. másodpercben stabilizálódik. Ez az interferencia-hányados igen csekély mértkének tulajdonítható. Ezt a megjegyzést a csomag-késleltetés és –ingadozás, illetve a jelszint stabilitása is alátámasztja. Így tehát a relatív kicsi (300 m.) hatótávolság a „direkt rálátás” hiányának tulajdonítható.

BZAKA

AmI Project

85.


600 500

Distance [m]

400 300 200 100 0 0

50

100

150

Time [sec]

a)

d) 0 -10

0

50

100

150

-20

SL [dBm]

-30 -40 -50 -60 -70 -80 -90 -100 Time [sec]

e)

b)


86.

AmI Project

BZAKA


Országúti mérések (2) A (*) 61. ábra olyan eredményeket mutat, amelyeket az előbbi kísérlethez hasonló környezetben mértünk, azaz nem volt lakóterület a helyszínhez közel. Így az épületek által előidézett interferencia nem zavarta az adatkommunikációt. Ugyanakkor jelen kísérletben a terepviszonyok igen nagy távolságig biztosítottak „direkt rálátást”. A mérésekkel azt vizsgáltuk, hogy ilyen körülmények között milyen hatással van a közúti forgalom a vezetéknélküli hálózati kapcsolatra. A kísérletben a mérő-jármű megint kétirányú utat tesz meg. Az első fázisban távolodik, majd közeledik a telepített mérőegységhez. Ugyanakkor erre a kísérletre jellemző a nagy utazási sebesség is. Itt, ugyanis a mérő-jármű elérte a 60 km/h maximális sebességet is. Az átlagos utazósebesség 40 km/h volt. Az ábrákról láthatjuk, hogy a biztosított sávszélesség minősége igen hamar lecsökken és mértéke már kis távolságnál is nagyon ingadozik. A kapcsolat minőségének romlása észrevehető a jelszint mértékéből is, amely igen rövid idő alatt lecsökken -80 dBm alá. A kísérlet 5-110 mp. időintervallumában tanúi lehetünk a sávszélesség igen erős ingadozásának. Ezt az ingadozást a jelenlévő közúti forgalom idézi elő. Megjegyezzük, hogy stabil, szélessávú kommunikáció ilyen sávszélesség-ingadozás mellett nem megvalósítható. Látható az ábrákról, hogy egy idő után a kapcsolat teljesen megszakad. Ez kb. 1000 méteres távolságnál következik be a kísérlet 110-ik másodpercében, majd a 220-ik másodpercben, kb. 1200 méteres távolságban újra létrejön és hasonló ingadozást mutat mint a kísérlet kezdetén. A késleltetés és késleltetés-ingadozás grafikonokon tapasztalható nagy értéknövekedést a hálózati eszközök már említett pufferelési tulajdonságának tulajdonítjuk.

BZAKA

AmI Project

87.


2500

Distance [m]

2000

1500

1000

500

0 0

50

100

150

200

250

300

350

250

300

350

Time [sec]

a)

d) 0 -10

0

50

100

150

200

-20

SL [dBm]

-30 -40 -50 -60 -70 -80 -90 -100 Time [sec]

b)

e)


88.

AmI Project

BZAKA


ÁLTALÁNOS ÉRTÉKELÉS ÉS KONKLÚZIÓ

Amint az előző fejezetben láthattuk, több szempontból vizsgáltuk a WLAN típusú technológia alkalmazhatóságát különböző valós mérések elvégzése alapján. Ezeket a mérési összeállításokat úgy alakítottuk ki, hogy folyamatosan szem előtt tartottuk az 1.2 fejezetben bemutatott alkalmazások kommunikációval kapcsolatos követelményeit. Az elvégzett és kiértékelt mérésekből általánosan megállapítható, hogy a WLAN technológia több alkalmazás szempontjából hiányos és még fejlesztésre szorul, de ugyanakkor, megfelelően megtervezve a WLAN hálózatot, több helyen is használható jelen állapotában is. Az eredményekből megállapítható, hogy az épületen belüli alkalmazások esetén, ha ugyanolyan prioritású egységek közti kommunikációt kell megvalósítani, amelyek helyileg közel vannak egymáshoz, a szabvány által biztosított ad hoc üzemmódot kell használni a kommunikáció megvalósítására. Ebben az esetben jobb átbocsátóképességet és nagyobb stabilitást lehet elérni. Amint felmerül az igény, hogy a hatósugarat kiterjesszük, és még hálózati hozzáférést is biztosítani kell, egy bázisállomás szükséges. Dinamikus, nagy mobilitású és hatósugarú vezetéknélküli hálózatok esetén (pl. autópályák mentén, forgalomban, stb.) a következő megjegyzések tehetők. Általánosan megállapítható, hogy, egy sűrűn beépített területen, ahol ugyanazon vezetéknélküli kommunikációs szabvány szerint több hálózat is működik, igen rosszul használható dinamikus és mobilis vezetéknélküli hálózatok létrehozására az IEEE 802.11b szabvány. Ez a minősítés még romolhat, abban az esetben, ha közúti forgalom is jelen van a mérés helyszínén. Ugyanakkor a WLAN technológiát alkalmazó rendszerek esetén, nagy távolságok áthidalását csak “direkt rálátás” biztosításával érhetünk el.

BZAKA

AmI Project

89.


3. BLUETOOTH 3.1

BEVEZETÉS

A Bluetooth technológia fejlesztése 1998-ban kezdődött, amikor az Ericsson, a Nokia, az Intel, az IBM és a Toshiba megalakította a Bluetooth Special Interest Group-ot (SIG), melynek célja az volt, hogy kifejlesszen és elterjesszen egy általános megoldást a kis hatótávolságú, vezeték nélküli, rádiós adatátvitelre, amely lehetővé teszi, hogy a hordozható elektronikus eszközök – például laptopok, mobiltelefonok, PDA-k (Personal Digital Assistant), stb. – ad-hoc módon, vezetékek felhasználása nélkül kommunikáljanak. Az elsődleges szempont a kis méret, az alacsony fogyasztás és az alacsony 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 technológia a nevét Harald Blaatand dán viking királyról kapta, aki egyesítette a skandináv országokat a 10. században. A Bluetooth célja pedig hasonlóan a hordozható elektronikus eszközök egységes kommunikációjának megteremtése volt. Amikor a kifejlesztést elkezdték, akkor már a 802.11 (WaveLAN) specifikációja létezett, így a Bluetooth eszköz célkörét úgy választották meg, hogy a WaveLAN-nak ne legyen konkurense, hiszen a Bluetooth SIG-ot alkotó cégek többnyire érdekeltek a WaveLAN sikerében is.

62. ábra: Egy Bluetooth eszköz a méreteit jelző gyufaszállal

A Bluetooth SIG az új technológia elterjesztése érdekében úgy döntött, hogy az általuk megírt specifikációt ingyen rendelkezésére bocsátja azon cégeknek, akik vállalják, hogy Bluetooth termékeket vezetnek be a piacra. Ezáltal kb. 3000 cég adoptálta a Bluetooth technológiát, akiknek így megvolt az előnyük, hogy a specifikációt megtekinthették annak nyilvánosságra hozatala előtt (1999. nyara). 1999. decemberében a Bluetooth SIG a 3Com, a Lucent, a Microsoft és a Motorola csatlakozásával 9 tagúra bővült, majd 2001-ben a Lucent helyét egykori mikroelektronikai divíziója, az Agere vette át. A Bluetooth specifikáció [71] 1200 oldalt tesz ki, és a 802.15.1. szabvány alapját is ez a specifikáció adja. A technológia leírása nem egy formális nyelvű dokumentum, hanem próza. Ennek előnye, hogy sokkal könnyebben olvasható, mint egy szabvány, hátránya viszont, hogy félreértelmezhető.

90.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata 3.2 3.2.1

RENDSZERSPECIFIKÁCIÓ FIZIKAI RÉTEG: A BLUETOOTH RÁDIÓS INTERFÉSZ

Annak érdekében, hogy a Bluetooth világszerte használható legyen, olyan működési frekvenciasávot kellett választani, amelynek használata nem engedélyköteles. Az egyetlen ilyen sáv a 2,45 GHz-es ISM (Industrial Scientific Medical) frekvenciatartomány, amely Amerikában és Európában 2400 MHz-től 2483,5 MHz-ig tart (kivéve Spanyolországban és Franciaországban), míg Japánban a 2471 MHz – 2497 MHz-es tartományt fedi le. Európában és Amerikában 79, míg Japánban, Spanyolországban és Franciaországban 23 vivőfrekvenciát (hop) határoztak meg, melyek között pontosan 1 Mhz távolság van (részletesebben lásd 8. táblázat). RÉGIÓ

KIJELÖLT FREKVENCIÁK (HOPOK)

FREKVENCIATARTOMÁNY

EURÓPA ÉS AMERIKA

2400 – 2483,5 MHZ

F= 2402 + K MHZ

K= 0 ….. 78

JAPÁN

2471 – 2497 MHZ

F= 2473 + K MHZ

K= 0 ….. 22

SPANYOLORSZÁG

2445 – 2475 MHZ

F= 2449 + K MHZ

K= 0 ….. 22

FRANCIAORSZÁG

2446,5 – 2483,5 MHZ

F= 2454 + K MHZ

K= 0 ….. 22

8. táblázat: A frekvenciatartományok és a kijelölt frekvenciák az adott régiókban

Mivel az ISM frekvenciasávot bárki használhatja, a Bluetooth eszközöknek meg kell birkózniuk a más eszközök által kibocsátott rádióhullámok miatti interferenciával. Ezt a frekvenciasávot használják például az egyes orvosi műszerek, garázsajtó-nyitók és mikrohullámú sütők. A Bluetooth-ban ezt a problémát két módszerrel küszöbölik ki. Az egyik a frekvenciaugratásos technika (frequency hopping) alkalmazása, melynek során a rendelkezésre álló frekvenciatartományban kijelölnek bizonyos frekvenciákat (hop) és az adási frekvencia másodpercenként 1600-szor vált álvéletlenszerűen ezen kijelölt frekvenciák között. A másik módszer a spektrumszórás, amely azt jelenti, hogy a jel teljesítményét „szétkenik” a teljes 1 MHz-es tartományon. A két technika alkalmazásával próbálják csökkenteni az interferenciából következő csomagvesztések valószínűségét. A frekvenciaugratás miatt csökken az ütközések valószínűsége, de ha mégis bekövetkezik az ütközés, akkor a spektrumszórás miatt minimális lesz az elveszett bitek száma. Az elveszett bitek visszaállítása érdekében hibajavító kódolás alkalmazható, de ha ez sem segít, akkor a csomagokat újraadják. A Bluetooth eszközök az adási teljesítményük szerint 3 osztályba sorolhatók. Ezen teljesítmény-osztályokat a 9. táblázat mutatja. Teljesítmény-szabályozás csak az első osztályba sorolt eszközöknél kötelező, 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 az energiafogyasztás optimalizálását, valamint az interferencia szint csökkentését. A teljesítmény 2 – 8 dB-es lépésközönként csökkenthető vagy növelhető. A vevő egység az RSSI (Received Signals Strength Indicator – vevő oldali jelerősség mutató) 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.

BZAKA

AmI Project

91.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata 3. osztályú eszközöknél a rádió hatósugara nagyjából 10 méter, az 1. osztályú eszközök esetében pedig körülbelül 100 métert tesz ki. Teljesítmény osztály

Max. kimeneti teljesítmény

Min. kimeneti teljesítmény

1

100 mW (20 dBm)

1mW (0 dBm)

2

2,5 mW (4 dBm)

0,25 mW (-6 dBm)

3

1 mW (0 dBm)

N/A

9. táblázat: Bluetooth teljesítmény-osztályok

3.2.2

BLUETOOTH RÁDIÓS CSATORNÁK ÉS PICONETEK

Egy Bluetooth csatornát egy álvéletlen frekvenciaugratási sorozat reprezentál. Azon Bluetooth egységek összességét, melyek ugyanazt a csatornát használják, piconetnek nevezzük. Azt az egységet, amely vezérli a csatornán lezajló kommunikációt, a piconet masterének hívjuk, az összes többi egységet pedig slave-nek. Minden Bluetooth egységnek van egy 48 bites egyedi azonosítója, mely bele van égetve a chipbe, tehát a működése során nem lehet megváltoztatni. Ezt az azonosítót leszámítva minden egység azonos hardver és szoftver interfésszel rendelkezik, függetlenül a piconetben betöltött szerepétől (master vagy slave). Tehát a master és slave fogalmak csak a piconetben betöltött szerepeket jelentik: a kapcsolat-felépítést kezdeményező egység lesz a master, a többi pedig slave. A piconetben két slave nem kommunikálhat közvetlenül egymással, csak a masteron keresztül. Egy masterhoz legfeljebb 7 aktív slave csatlakozhat. A specifikáció lehetővé teszi, hogy a piconeten belül egy úgynevezett adaptált csatornát használjon néhány slave. Ennek a lényege, hogy a teljes frekvenciakészletből néhányat a kommunikáló felek használaton kívülinek jelölhetnek, így eltérhetnek az alapértelmezett frekvenciaugrási sorozattól. Az adaptált csatornán arra is lehetőség van, hogy a slave ne a piconet alapértelmezett ugrási frekvenciáján válaszoljon a master lekérdezésére, hanem ugyanazon a frekvencián, ahol a master megszólította. A csatornák FH/TDD (Frequency Hop/Time Division Duplex) sémát használnak. A TDD technika azt jelenti, hogy a csatornák 625 μs hosszúságú időintervallumokra (résekre) vannak felosztva. A páros sorszámú időrésekben a master jogosult adást kezdeményezni. A megszólított slave a vett csomagra a következő, páratlan sorszámú időrésben jogosult a választ megkezdeni, így az egymást követő időrésekben felváltva történik csomagküldés illetve csomagvétel. Az adaptált csatornákat kivéve minden csomag átvitele után frekvenciaugrás következik be, így minden csomagküldéshez más-más frekvenciát alkalmaznak. Másodpercenként maximum 1600 frekvenciaugrás következik be. Azért nem pontosan 1600 ugrás, mert vannak több (3 illetve 5) időrés hosszú csomagok is, amelyek adása egy frekvencián történik. A csatornát reprezentáló álvéletlen számsorozat azt definiálja, hogy az egymást követő időrésekben milyen frekvenciát kell használni. A számsorozatot a master 48 bites azonosítója határozza meg, míg a számsorozaton belüli pozíciót (azaz hogy az éppen aktuális időrésben melyik frekvenciát kell használni) a master rendszerórájának állása definiálja. Az adott piconetben résztvevő egységeknek tehát ismerniük kell a master azonosítóját és óraállását (azaz rá kell szinkronizálódniuk a csatornára), különben nem fognak tudni kommunikálni a piconetben. 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.

92.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata A szinkronizáció érdekében minden slave eltárol egy offset időt, amely az adott slave rendszerórájának eltérését jelenti a master órájától (lásd 63. ábra). A master a 48 bites azonosítóját és az órájának állását a kapcsolat felépítésekor tudatja a slave-ekkel, ezáltal az adott piconetben szereplő összes slave fogja tudni a soron következő frekvenciát.

63. ábra: Az ugrási frekvencia előállítása slave egységekben

Az átvitel sebességét 1 Ms/s-ben (egy millió szimbólum per másodpercben) határozta meg a korábbi specifikáció, ez a sebesség azonban a 2.0-ás specifikáció szerint akár már 3 Ms/s-ig is növelhető. 3.2.3

SCATTERNET

A Bluetooth a berendezéseket piconetekbe szervezi, egy ilyen minihálózatban maximum 8 berendezés lehet aktív. Ennél nagyobb számú felhasználó esetén több piconet jön létre, melyek egymás között a kapcsolatot, az úgynevezett átjátszókon keresztül tartják, így biztosítva, hogy a piconetek egy nagyobb hálózatot alkossanak. A piconetek összességét nevezzük scatternetnek. Az ugyanazt a csatornát használó egységeknek, azaz egy piconet tagjainak osztozniuk kell a csatorna sávszélességén. Habár a csatornák 1 MHz sávszélességűek, egyre több Bluetooth egység hozzáadásával az átviteli sebesség gyorsan lecsökken 1 Mbit/sec-ról néhány tíz kbit/sec-re. Másrészről hiába áll rendelkezésünkre kb. 80 MHz (Európában), ha egyidejűleg ebből csak 1 MHz-et használunk ki. A problémák kiküszöbölésére és a nagyobb hálózatok létrehozására alkották meg a piconetek összességét, a scatternetet. Az elv a következő: ahelyett, hogy az összes Bluetooth egység 1 piconetbe csatlakozna, több kisebb piconetet hozunk létre, hiszen egy felhasználó tipikusan nem akar az összes másik felhasználóval kommunikálni, csak a felhasználók bizonyos csoportjával. Tehát csak ezen felhasználói csoportokból alkotunk piconeteket, melyek természetesen átfedik egymást. Mivel minden piconetnek megvan a maga frekvenciaugratási sorozata, ezért (jó esetben) minden piconet más-más frekvenciasávban működik párhuzamosan. A scatternet aggregált átviteli sebessége (az egyes felhasználókra jutó sávszélesség összege), valamint az egy felhasználóra jutó átviteli sebesség jóval nagyobb lesz, mintha az összes felhasználó egy piconetbe csatlakozna. Ennek oka, hogy az egy piconetbe tartozó egységek csak maguk között osztják meg az 1 MHz sávszélességet, a többi piconet egységeivel nem osztozkodnak. Minél több piconetbe csoportosítjuk az összes felhasználót annál jobb lesz az aggregált átviteli sebesség. Viszont minél több piconetet hozunk létre, annál valószínűbb, hogy ütközés következik be, ezáltal csökken az összteljesítmény.

BZAKA

AmI Project

93.


64. ábra: Egy scatternet megközelítés

A Bluetooth egységek egyszerre két vagy több piconetbe is tartozhatnak időmultiplexálás (TDM: Time Division Multiplexing) segítségével. Ez azt jelenti, hogy az egység egy adott időpillanatban csak az egyik piconethez tartozik, de bizonyos időperiódusonként átvált a piconetek között. Mivel minden piconet különböző frekvenciaugratási sorozatot használ, ezért egy olyan egységnek, amely több piconethez is tartozik, ismernie kell minden érintett piconet masterének azonosítóját, és órájának állását, hogy a megfelelő sorozatot elő tudja állítani (lásd 65. ábra).

65. ábra: Az ugratási frekvencia előállítása több piconethez tartozó egység esetén

Egy Bluetooth egység slave-ként több piconetben is szerepelhet, de masterként csak egyben, hiszen ha két piconetnek ugyanaz az egység lenne a mastere, akkor ugyanazt az ugrási sorozatot használnák, tehát az a két piconet valójában csak egy lenne (ellentmondás). Egy master vagy egy slave akkor kapcsolódhat egy másik piconethez slave-ként, ha a másik piconet mastere végrehajtja a page eljárást. Ha egy slave akar átcsatlakozni, akkor értesíti a jelenlegi piconet masterét, hogy egy meghatározott ideig nem lesz elérhető (átmegy hold vagy sniff módba). Ettől kezdve az egység a két piconet között ugrál. A távolléte alatt a régi piconetben a kommunikáció zajlik tovább. Ha egy master akar átcsatlakozni egy másik piconetbe slave-ként, akkor a régi piconetbeli kommunikáció szünetel, amíg vissza nem tér. Az 66. ábra két piconetet ábrázol, melyeknek az egyik slave-jük közös. Az óraállások közötti ofszetet a piros és kék körszeletek jelölik.

94.

AmI Project

BZAKA


66. ábra: Két piconet egy közös slave-vel

Ha az egyik piconetben a master és az átcsatlakozni kívánó slave között létezik SCO link, akkor az átcsatlakozás csak a link számára fenntartott időrések közötti időtartamra lehetséges. Mivel azonban a két csatorna nincs szinkronizálva, ezért holtidővel is számolni kell, ami alatt a slave az új piconetben nem tud még csomagot fogadni. Például ha 6 időrés van a fenntartott időrések között, akkor is csak két időrést tud effektíven kihasználni a slave a másik piconetben (lásd 67. ábra).

67. ábra: Időzítések piconetek közötti kommunikáció esetén

3.2.4

KAPCSOLATTÍPUSOK

A Bluetooth-ban a master és egy slave között háromféle kapcsolat (link) jöhet létre: •

szinkron, szimmetrikus, kapcsolatorientált link (SCO: synchronous connectionoriented);

•

kibővített szinkron, kapcsolatorientált link (eSCO: extended synchronous connectionoriented);

•

aszinkron, kapcsolat nélküli link (ACL: asynchronous connectionless).

BZAKA

AmI Project

95.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata Az SCO link szimmetrikus (full-duplex), áramkörkapcsoltnak tekinthető. Pont-pont összeköttetéseket támogat két egység között, melyeket tipikusan hangátvitelre használnak. A csatornán az SCO link számára egyenlő időközönként egymás utáni két időrést foglalnak le (master-to-slave és slave-to-master időrés). Az egyenlő időköz lehet 2, 4 vagy 6 időrés. A lefoglalt időrésekben elvileg nem kommunikálhat senki más, csak az, aki részt vesz az SCO kapcsolatban, azonban a nagyobb prioritású üzenetek (például LMP üzenetek, QoS garanciák miatti üzenetek) a lefoglalás ellenére is küldhetők ezekben az időrésekben. A maximális átviteli sebesség SCO linken 64 kbit/sec mindkét irányban. Az SCO linken nem alkalmaznak újraküldést, de a bithibák ellen FEC (Forward Error Correction) mechanizmussal védekeznek. A szinkron összeköttetéseket a master hozza létre az LMP protokoll parancsainak segítségével. A master egység az általa vezérelt piconeten belül maximálisan 3 szinkron összeköttetést létesíthet. A slave egységek ugyanazzal a masterrel maximálisan 3, míg különböző master egységekkel 2 szinkron összeköttetést létesíthetnek. 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 is jogosult az előre meghatározott időrésekben adni. Az eSCO link annyival tud többet az SCO linknél, hogy nem feltétlenül szimmetrikus, azaz az egyik irányba nagyobb sávszélesség foglalható, illetve lehetőség van a lefoglalt időréseket követő időrésekben az újraküldésre. Az ACL linktípus szimmetrikus vagy aszimmetrikus, csomagkapcsolt, pont-pont és ponttöbbpont összeköttetéseket támogat, amelyet általában adatátvitelre használnak. Az adatintegritás megőrzése érdekében újraküldést és egy bites csomagsorszámozást alkalmaznak, valamint szükség esetén itt is használják a FEC mechanizmust. Az aszinkron kommunikáció azokban az üres időrésekben valósulhat meg, amelyek nincsenek lefoglalva szinkron adatátvitel céljából. Egy master valamint egy slave között csak egy darab ACL összeköttetés valósulhat meg. Az ACL kapcsolatok vezérlésére a piconetek master egységei lekérdezéses technikát (polling scheme) alkalmaznak, azaz egy slave csak akkor kezdhet csomagküldésbe a páratlan sorszámú (slave-to-master) időrésben, ha a master az előző páros sorszámú (master-to-slave) időrésben lekérdezte (megcímezte) a slave-et. Ezáltal a slave-ek és a master felváltva használják a csatornát időosztásos alapon, így elkerülhetők a slave-ek egyidejű csomagküldéséből adódó ütközések. A master elvileg szabadon dönthet arról, hogy melyik slave-eket kérdezi le, és hogy milyen sorrendben. Azonban a QoS garanciák teljesítése érdekében bizonyos időközönként akkor is meg kell szólítania a slave-t, ha nincsen adata a slave számára, hiszen csak annak a slave-nek van joga a csatornát használni, akit a master megszólított. 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. A slave-ek lekérdezése történhet implicit vagy explicit módon. Amikor a master küld egy adatcsomagot a master-to-slave időrésben, akkor a címzett a következő időrésben válaszolhat (implicit lekérdezés). Ha a masternek nincsen közlendője egy adott slave felé, de le szeretné kérdezni, akkor küld egy POLL csomagot, melyre a slave válaszolhat (explicit lekérdezés). A szinkron és aszinkron linktípus természetesen kombinálható is. Például a master és egy slave között egy SCO link mellett lehet egy ACL link is. A 68. ábrán látható esetben a master és az 1. slave között van egy SCO és egy ACL link, míg a master és a 2. slave között nincs SCO link, csak egy ACL link.

96.

AmI Project

BZAKA


68. ábra: SCO és ACL linkek egy mastert és két slave-et tartalmazó piconetben

3.2.5

CSOMAGTÍPUSOK

3.2.5.1 A Bluetooth csomagokról általában A kommunikáció a Bluetooth hálózatokban csomagokkal történik. Egy csomag 1, 3 vagy 5 időrés hosszúságú lehet. Ha a csomag több mint egy időrés hosszúságú, akkor a küldéshez használt frekvencia nem változik meg a csomagot tartalmazó többi időrésben. A hosszú csomag elküldése után a frekvencia a már leírt módon, a master órájától függően változik. Például: legyen k, k+1, k+2, k+3 négy egymást követő időrés; az ezekhez tartozó frekvencia pedig fk, fk+1, fk+2, fk+3. Ekkor egy 3 időrés hosszóságú csomag, amely a k időrésben kezdődik, végig fk frekvenciát fogja használni. A következő csomag a k+3-as időrésben fog kezdődni fk+3 frekvenciával (lásd 69. ábra). f(k)

f(k+1)

f(k+2)

f(k+3)

f(k+4)

f(k+5)

f(k+3)

f(k+4)

f(k+5)

Master

Slave f(k) Master

Slave f(k)

f(k+5)

Master

Slave

69. ábra: A Bluetooth csomagok és a küldésükhöz használt csatornák frekvenciája

BZAKA

AmI Project

97.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata A Bluetooth-ban alapvetően ötféle csomag van (lásd 70. ábra). Mindegyik csomag tartalmaz egy hozzáférési kód (access code, AC) mezőt, esetlegesen egy fejrészt és egy vagy két felhasználói adatokat szállító mezőt. A csomagok „Little endian” bit sorrenddel rendelkeznek.

70. ábra: Csomagtípusok felépítése a Bluetooth-ban

Az ID csomagot kapcsolat-felépítéskor használják. A POLL csomagot a master használja a slave explicit lekérdezésére akkor, amikor egyébként nincs mit elküldenie a slave-nek, míg a NULL csomag nyugtázásra használatos, amikor a slave-nek nincs hasznos információja. Fentiekből következik, hogy a POLL és NULL csomagoknak nincs hasznos teher (payload) része. Az FHS (Frequency Hopping Sequence) csomagot a piconetek felépítésekor használják, ez tartalmazza a küldő egyedi azonosítóját, a master által a slave-hez rendelt logikai címet (LT_ADDR), valamint a master rendszerórájának állását. Ezek az információk a frekvenciasorozat-generáláshoz és a piconeten belüli kommunikációhoz használatosak. Az FHS csomag payload részét 2/3 rátájú FEC kódolással védik a bithibák ellen. Ehhez (15,10) paraméterű Hamming-kódot használnak, ami annyit jelent, hogy minden 10 bites blokkhoz 5 paritásbitet csapnak hozzá. Ezáltal a vételi egységnek lehetősége van 1 bithiba kijavítására, és 2 bithiba észlelésére (a Hamming-távolság 4). A különféle ACL, SCO és eSCO csomagok pedig szinkron vagy aszinkron adatokat szállítanak a payload részben (a link típusától függően).

3.2.5.2 A csomagok szerkezete 3.2.5.3 Hozzáférési (access) kód Minden egyes csomag az access kóddal (AC) kezdődik (felépítését a 71. á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 piconet hozzáférési kódja a master 48 bites azonosítójából származik, ezért ez minden piconet számára egyedi. Ezáltal ez a mező azonosít minden, az adott csatornán küldött csomagot, azaz egy piconetben küldött összes csomagot ugyanaz a hozzáférési kód előzi meg. Ha egy egység kap egy csomagot, akkor összehasonlítja a csomag hozzáférési kódját a sajátjával. Ha a kettő nem egyezik meg, akkor a csomag további része eldobásra kerül.

98.

AmI Project

BZAKA


71. ábra: Access kód felépítése

A rendszer 3 különböző típusú access kódot definiál: •

csatorna access kód (CAC - Channel Access Code) – egy piconet csatorna azonosítására

•

eszköz access kód (DAC - Device Access Code) – egy adott eszköz megszólításához (page)

•

inquiry access kód (IAC - Inquiry Access Code) - eszközfelderítéshez

Előhang (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 72. ábra mutatja.

72. ábra: Preamble

Szinkron szó A szinkron szó egy 64 bites kódszó, amely egy 24 bites úgynevezett LAP (Lower Address Part) címből származik. CAC használatakor ez a 24 bites LAP a master egység egyedi azonosítójából, IAC esetén a 24 bites LAP cím előre definiált illetve dedikált, DAC esetén a megszólított slave egység azonosítójábó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. A szinkron szavak közötti Hamming távolság 14. A szinkron szavak előállításához használt algoritmusokkal jó autókorrelációs tulajdonságok érhetők el. A szinkron szavak származtatásának folyamatát részletesen a Bluetooth specifikáció tartalmazza. Lezáró (Trailer) A trailer felépítése hasonló a preamble felépítéséhez, ahogy azt a 73. á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é.

BZAKA

AmI Project

99.


73. ábra: A trailer kétféle felépítése CAC használatakor

3.2.5.4 Fejrész (BB_header) Az ID csomag kivételével az összes csomag tartalmaz egy 54 bites fejléc (BB_header) mezőt, melynek felépítését a 74. ábra mutatja.

74. ábra: BB_header mező felépítése

Logikai cím (LT_ADDR) A 3 bites logikai cím (Logical Transport ADDRess - LT_ADDR) mező szolgál a slave-ek megkülönböztetésére a piconeten belül. A master-to-slave időrésben ez a mező a címzett slave-et azonosítja, míg a slave-to-master időrésben a küldő slave-et határozza meg. A csupa nullát tartalmazó LT_ADDR a broadcast csomagok számára van fenntartva, jelezve, hogy a megcímzett egység a masterhez tartozó összes slave. Azok a slave egységek címei, amelyek kiválnak, vagy parkolt állapotba kerülnek, a piconeten belüli é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ő (TYPE) 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 egy, valamint több időrés ideig tartó csomagok, illetve a szinkron és aszinkron csomagok között. Folyamszabályozás mező (FLOW) A FLOW mezőt csak ACL link esetén használják, és forgalomszabályozásra szolgál. Ha a vevő egység puffere megtelik, akkor bebillenti a FLOW flaget 0-ra, ezáltal a küldő egység szünetelteti a csomagküldést. Amikor a küldő FLOW=1 értékű csomagot kap, azaz amikor a vevő puffere kiürült, akkor folytatja a csomagküldést.

100.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata 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, azaz a vett csomag végén található HEC (Header Error Check) kód megegyezik a vételi egység által számított CRC-vel, akkor a válaszban az ARQN értéke 1, ellenkező esetben 0. Ha az adatot nem követi nyugtázás, akkor alapértelmezésben hibás átvitelt feltételezünk és újraküldjük. SEQN mező A SEQN (Sequential Numbering, SEQN) az ACL adatcsomagok sorszámozására 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écet egy 8 bites HEC (Header Error Check) kód zárja le, amely a fejléc integritását ellenőrzi. Így a fejlécben lévő 6 értékes mező összesen 18 bitet tesz ki, de ezt még 1/3 arányú FEC (Forward Error Check) kódolással is védik, ami annyit jelent, hogy minden bitet megháromszoroznak. Ezáltal jön ki az 54 bites fejléc (header) mező.

3.2.5.5 Hasznos teher (Payload) Az ACL, SCO és eSCO csomagok szinkron vagy aszinkron adatokat szállítanak a payload részben. A payload mező további három mezőre osztható (lásd 75. ábra), amelyekből nincs mindegyik feltétlenül minden csomagtípusnál jelen. (például SCO és eSCO csatorna esetében a DV csomagokat kivéve hiányzik a fejrész mező a payloadból.)

75. ábra: A payload felépítése ACL típusú csomag esetén

ACL csatorna esetén a 16 bites ACL_pld_hdr mező tartalmazza a logikai csatorna 2 bites azonosítóját, valamint a payload hosszát. A logikai csatorna azonosítója határozza meg, hogy a csomag a Link Managerhez vagy az L2CAP réteghez kerül további feldolgozásra. Az ACL_pld_body mező hordozza a tényleges felhasználói információkat, melynek hossza 82704 bit lehet. Az adatintegritást 16 bites CRC-vel biztosítják. Az ACL csomag payload részét 2/3 arányú FEC kódolással védhetik, míg az SCO csomagot 1/3 vagy 2/3 rátájúval.

3.2.5.6 Az adatátvitelre használható csomagtípusok Adatátvitelre több csomagtípust használhatunk, melyekkel más-más megbízhatóság mellett más-más átviteli sebességet lehet elérni. A DH1;3;5 csomagok az ACL összeköttetések adatait hivatottak átvinni, méghozzá hibakezelés nélkül. A H jelzés a csomag kódjában a nagy sebességre (high rate), a szám pedig az elfoglalt időrések számára utal. A DM3;5 csomagok az azonos számozású DH csomagok közepes sebességű (M= medium rate) változatai, a sebességcsökkenés az okozza, hogy ezek a csomagok tartalmaznak hibakezelést, ami csökkenti az átvitelre kerülő bitek számát, a hibakezelést elősegítő bitek számával. Az AUX csomag a DH1 csomag változata, ahol a payload fejléc nem tartalmaz CRC-t.

BZAKA

AmI Project

101.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata A HV1-3 csomagok az SCO összeköttetések adatátviteléért felelnek. Minél nagyobb a HV csomag kódja annál több adatot képes egyszerre átvinni, viszont annál inkább romlik a hibajavító képessége. A HV3-as csomagok 30 bájt átvitelére képesek, viszont nem képesek semmilyen hibakezelési funkciót ellátni. A DV csomag a HV1 csomag kiegészítése adat átvitelre alkalmas mezőkkel. Ekkor a csomag két része külön kerül lekezelésre. Az EV3-5 csomagok az eSCO adatokat szállítják. A payload mezőjük nem tartalmaz fejrészt. Az adatokat CRC védi, és ezeknél a csomagoknál van lehetőség az újraküldésre. A következő táblázatok mutatják be az egyes csomagtípusok jellemzőit és a velük elérhető maximális átviteli sebességet. Utóbbit a következő képlet alapján lehet számítani. Vmax =

lrakomány nidoszelet ⋅ 625μs

1. egyenlet

Az ACL csomagok átviteli jellemzői:

FELHASZNÁLÓI RAKOMÁNY (BÁJT)

TÍPUS

FEC

CRC

ASZIMMETRIKUS MAX. SEBESSÉG (KB/S)

SZIMMETRIKUS MAX. SEB. (KB/S)

ELŐRE

VISSZA

DM1

0-17

2/3

VAN

108.8

108.8

108.8

DH1

0-27

NINCS VAN

172.8

172.8

172.8

DM3

0-121

2/3

VAN

258.1

387.2

54.4

DH3

0-183

NINCS VAN

390.4

585.6

86.4

DM5

0-224

2/3

VAN

286.7

477.8

36.3

DH5

0-339

NINCS VAN

433.9

723.2

57.6

NINCS NINCS 185.6

185.6

185.6

AUX1 0-29

10. táblázat: Az elérhető bitsebességek ACL link esetén

102.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata Az SCO csomagok átviteli jellemzői: TÍPUS


FEC

CRC


HV1

10

1/3

NINCS

64.0

HV2

20

2/3

NINCS

64.0

HV3

30

NINCS

NINCS

64.0

DV

10+(0-9) (ADAT)

2/3 (ADAT)

VAN AZ ADATRA

64.0+57.6 (ADAT)

11. táblázat: Az elérhető bitsebességek SCO link esetén

Az eSCO csomagok átviteli jellemzői: TÍPUS

IDŐRÉSEK SZÁMA


FEC

CRC


EV3

1

1-30

NINCS

VAN

96.0

EV4

3

1-120

2/3

VAN

192.0

EV5

3

1-180

NINCS

VAN

288.0

12. táblázat: Az elérhető bitsebességek eSCO link esetén

3.2.6

BLUETOOTH ESZKÖZÖK MŰKÖDÉSI ÁLLAPOTAI

A 76. ábra a Bluetooth összeköttetés vezérlő által használt állapotok átmeneteit mutatja be. Két fő állapot a STANDBY (készenlét) valamint CONNECTION (kapcsolat) állapot. Ezen kívül hét alállapot van, amelyek átmeneti állapotok az eszközfelderítéshez és a kapcsolatkiépítéshez. 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. Az eszköz kapcsolat állapotban képes adatforgalmat bonyolítani.

BZAKA

AmI Project

103.


Készenlét (Standby)

Hívás (page)

Felderítés

Hívás keresés

keresés

Felderítés (inquiry)

Master válasz Felderítés

Slave válasz

válasz

Kapcsolat

76. ábra: A Bluetooth csatorna kialakítás állapot átmenetei

A kapcsolat-felépítési eljárást valamelyik Bluetooth egység kezdeményezi, ez az egység lesz a felépülő piconet mastere. A piconet létrehozásához a kapcsolódni kívánó egységeknek ismerniük kell egymás azonosítóját és órájának állását. Ha a master ismeri az általa csatlakoztatni kívánt egység címét, akkor a kapcsolat-felépítés page (hívás) eljárással történik meg, de ha a slave címe nem ismert, akkor a page eljárást megelőzi egy úgynevezett inquiry (felderítés) eljárás, melynek során a master feltérképezi a hatótávolságán belül lévő egységeket és lekérdezi az azonosítójukat. A page eljárás során a cél a slave egység csatlakoztatása a piconethez, amihez először fel kell ébreszteni készenléti állapotból. Mivel ilyenkor a slave azonosítója ismert, ezért a slave-hez rendelt 32 ébresztési frekvencia is ismert, tehát már csak a konkrét frekvenciát kell megtudni, amit a slave órája határoz meg. Ezért a master megbecsli a slave órájának állását, amiből meghatároz egy ébresztési frekvenciát. Ezután a master 16 page üzenetet küld ki 16 különböző frekvencián (10 ms), amely frekvenciák a slave ébresztési frekvenciái közül kerülnek ki a következőképpen: az egyik a becsült frekvencia, valamint 8 ébresztési frekvencia a becsült érték előtt, és 7 frekvencia utána. Ezáltal a becslés tűrése ±7 ébresztési frekvencia. Ezt a műveletet a master 128-szor megismétli (1,28 sec). Ha nem érkezik válasz, akkor a master a maradék 16 ébresztési frekvencián is kiküldi a page üzeneteket. Amikor a slave egység megkap egy page üzenetet, akkor aktiválja magát, és visszaküld egy nyugtát. Ezután a master küld egy üzenetet a slave-nek (FHS csomag), amely tartalmazza a kirendelt LT_ADDR címet, a master azonosítóját és óraállását. Az üzenet nyugtázása után a slave egység becsatlakozott a piconetbe, azaz képes kommunikálni a masterrel.

104.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata Az inquiry eljárás a következőképpen működik: a master inquiry üzeneteket küld egy jól meghatározott, minden Bluetooth egység számára közös (ismert) csatornán. Amikor egy slave egység veszi ezt az üzenetet, véletlen hosszú ideig vár. Ha a várakozás után újból vesz egy inquiry üzenetet, visszaküld egy választ, amely tartalmazza az azonosítóját, és órájának állását.

77. ábra: Kapcsolat-felépítés állapotgráf

3.2.7

ENERGIATAKARÉKOS ÜZEMMÓDOK

A Bluetooth-ban 3 energiatakarékos üzemmód (low power modes) létezik: sniff, hold, park (lásd 77. ábra). Ezek részletes ismertetése és a közöttük lévő különbségek érzékeltetése következik ebben a szakaszban. Habár ezeket az üzemmódokat arra tervezték, hogy csökkentsék az eszközök energiafogyasztását, más céljuk is van. Például ezek segítségével oldható meg, hogy egy piconetben résztvevő aktív eszköz page vagy inquiry eljárást hajtson végre más eszközök felé, vagy részt vegyen egy másik piconetbeli kommunikációban. A három üzemmód közül a sniff módban a legnagyobb az energiafogyasztás. Ha a slave egy ACL linken keresztül kommunikál a masterrel, akkor minden ACL időrésben figyelnie kell a master adását. Sniff módban a slave megegyezik a masterrel, hogy csak minden N-edik időrésben figyeli a master adását, tehát csökken azon időrések száma, amelyben a master kommunikálhat ezzel a slave-vel. Ezen időréseket sniff időréseknek nevezzük. Sniff üzemmódban a slave nem veszíti el a master által neki rendelt LT_ADDR címét.

BZAKA

AmI Project

105.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata Hold üzemmódban a második legnagyobb az energia-felvétel. A hold módban történő működés azt jelenti, hogy a slave egy meghatározott ideig nem fogad ACL csomagokat. Ezáltal a slave felszabadíthatja az erőforrásait, és például page eljárást hajthat végre, vagy csatlakozhat ezen időintervallum alatt egy másik piconethez. Ha azonban a slave SCO linket is fenntart, akkor az SCO csomagokat köteles fogadni (hiszen az SCO linket valós idejű alkalmazások használják), tehát csak a link számára fenntartott időrések közötti időre válthat át hold módba. Hold módba váltás előtt a slave közli a masterrel, hogy mennyi ideig marad ebben a módban. Ha lejár az idő, akkor a slave felébred, szinkronizálódik a csatornához, majd fogadja a master további utasításait. A hold üzemmódba átlépő slave szintén megtartja az LT_ADDR címét. Ha a hold üzemmód alatt nem valamilyen más funkció végrehajtása a cél (lásd fent), akkor tipikusan olyan eszközök alkalmazzák, melyek viszonylag ritkán bonyolítanak le adatforgalmat, és amelyeknél fontos szempont az alacsony fogyasztás. Egy ilyen eszköz például egy légkondicionáló, amely percenként csak egyszer küld adatot. A három üzemmód közül a park módban a legkisebb az energiafogyasztás. Ha egy slave egység nem kíván résztvenni a kommunikációban, de a csatornához való szinkronizációt meg szeretné tartani, akkor határozatlan időre átmehet park módba. Park módba lépéskor a slave elveszíti az LT_ADDR címét, de kap helyette két másikat: egy 8 bites PM_ADDR (Parked Member Address) címet, és egy szintén 8 bites AR_ADDR (Access Request Address) címet. A PM_ADDR a park módban lévő slave-ek megkülönböztetésére szolgál. A PM_ADDR címet a master által kezdeményezett, míg az AR_ADDR címet a slave által kezdeményezett piconetbe való visszatérési eljárás során használják. Mivel a park módban lévő slave-eknek nincs LT_ADDR címük, a nekik szóló üzeneteket csak üzenetszórással (LT_ADDR = 0) lehet elküldeni. Annak érdekében, hogy a park módú slave-ek megtartsák a szinkronizációt, és megkapják az üzenetszórással küldött csomagokat, periodikusan felébrednek, és belehallgatnak a master által fenntartott úgynevezett beacon csatornába. A beacon csatorna paramétereit a park módba történő áttéréskor kapják meg a mastertől. A master szintén a beacon csatornát használja a slave felébresztésére. Ha a slave szeretne visszatérni a piconetbe, akkor a beacon csatorna időrését követő időrésben küld egy üzenetet a masternak. Habár a park üzemmód elsődleges célja az energiatakarékosság, van még egy előnye: ennek segítségével lehet egy masterhez több, mint 7 slave-et csatlakoztatni. Habár egyidőben egy masterhez legfeljebb 7 aktív slave csatlakozhat, a park módba való ide-oda váltogatással elérhető, hogy virtuálisan akár 255 slave csatlakozzon ugyanazon masterhez. 3.2.8

PROTOKOLLSZERKEZET

A Bluetooth vezeték nélküli technológia protokolljai alapvetően két csoportba sorolhatók: szállítási (transport) protokollok * és adoptált (middleware) protokollok (lásd 78. ábra). A szállítási protokollokat kifejezetten a Bluetooth technológia megvalósítására fejlesztették ki, míg az adoptált protokollok már meglévő protokollok, melyeket a szállítási protokollok fölé helyezve lehet bizonyos alkalmazásokat megvalósítani. A leglényegesebb különbség a kettő között, hogy minden Bluetooth egységnek az összes szállítási protokollt tartalmaznia kell, míg az adoptált protokollok közül legalább egyet kell támogatnia. *

Az itt szerepelő szállítási protokollok nem azonosak az OSI modell szerinti szállítási réteggel.

106.

AmI Project

BZAKA


78. ábra: A Bluetooth protokollszerkezete

3.2.8.1 Szállítási protokollok A szállítási protokollok közül értelemszerűen a Radio réteg a felelős a rádiós interfészért, azaz ez a réteg gondoskodik a modulált bitfolyamok küldéséről és fogadásáról. Ide tartozik még a használt frekvenciasáv, a frekvenciaugratás technikája, a spektrumszórás, a csatornák definiálása, valamint a moduláció kérdése. A Baseband réteg segítségével lehet két Bluetooth egység között vezeték nélküli kommunikációs csatornát létrehozni. Feladatai közé tartozik az időzítések kezelése, a keretezés, a csomagok definiálása, linkek létrehozása, hibakezelés és hibajavítás. A Link Manager protokoll (LMP) egy tranzakciós protokoll két kommunikáló Bluetooth egység Link Manager entitása között, melynek feladata a Baseband link tulajdonságainak beállítása, a kapcsolatok felépítése és vezérlése. Két Link Manager entitás képes megtanulni egymás tulajdonságait, például hogy az adott eszköz támogatja-e az SCO linktípust, vagy hogy mely energiatakarékos üzemmódok érhetők el. A Link Manager tranzakciók segítségével végrehajtható az egységek hitelestés, elvégezhető a titkosítási paraméterek egyeztetése, beállítható a maximális csomagméret. Az LMP feladata a csatornák felépítése az egyes Bluetooth eszközök között, ez a réteg végzi az adási teljesítmény vezérlését és vételi erősség visszacsatolását, továbbá ez kezeli az eszköz piconetbeli állapotát is (hold, park, sniff mode). Ez a réteg biztosít helyet a QoS megvalósítására is. A Bluetooth specifikáció QoS támogatásra csak az úgynevezett ACL lekérdezési idő egyeztetését írja elő. A slave csak akkor adhat egy ACL csatornán, ha a master megszólítja. A master által kezdeményezett két lekérdezés (polling) közti időtartamot hívjuk lekérdezési időnek (poll time), amelyek kezelésére az LMP biztosít funkciókat. Az LMP az érkező jelzések lefordításáért és szűréséért is felel eltakarva az alsóbb rétegeket. Az LMP üzeneteinek továbbítására külön csomag típus áll rendelkezésre, amely struktúrájában megegyezik a felhasználói csomagokkal. Az LMP üzeneteinek nagyobb a prioritása, mint a felhasználói adatoknak. Az LMP üzeneteit nem késleltethetik az L2CAP üzenetei, de elszenvedhetnek késletetést alsóbb rétegbeli üzenetektől.

BZAKA

AmI Project

107.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata Az L2CAP (Logical Link Control & Adaptation Protocol) réteg a logikai csatornák vezérlésével foglalkozik. Ezen a szinten a master illetve slave szerepeknek már nincs jelentősége. Az L2CAP támogatja a logikai csatornák multiplexálását is. A logikai csatornák két Bluetooth egység L2CAP entitása között szállítják az információkat, melyeknek háromféle típusa van: jelzéscsatorna, kapcsolat nélküli (connectionless) csatorna, és kapcsolatorientált (connection-oriented) csatorna. Az L2CAP réteg a felsőbb rétegek számára a logikai csatorna típusának megfelelően újabb csomagformátumokat definiál. Ezek a csomagok sokkal nagyobbak, mint a Baseband csomagok, ezért darabolásra lehet szükség a küldő oldalon, és csomagösszerakásra a vételi oldalon, melyek az alsóbb és felsőbb rétegek számára transzparensen zajlanak le. Az L2CAP támogatja a felsőbb protokollbeli multiplexálást, csomag szétvágást és összeillesztést, valamint a Quality of Service (QoS) információk kezelését. Az L2CAP protokoll az alsóbb szintek által nyújtott funkciókra épül. A Baseband rétegben nincs lehetőség a felsőbb rétegek csomagjainak szétválasztására típus alapján. Az L2CAP implementációk feladata a QoS szerződések betartatása is. Az L2CAP réteg egyszerű csoportkezelésre is lehetőséget nyújt. Egy csoportnak szánt csomag a csoport minden tagjához elküldésre kerül. A HCI (Host Controller Interface) nem egy protokoll, mint az a nevéből is adódik, hanem egy szabványos interfész, melyen keresztül a felsőbb rétegek elérhetik az alsó három Bluetooth réteget, és amelyen keresztül utasíthatják őket hálózati kapcsolatok létrehozására, page és inquiry eljárások végrehajtására, hitelesítés (autentikáció) kérésére, valamint valamely energiatakarékos üzemmód aktiválására.

3.2.8.2 Adoptált protokollok Amíg a szállítási protokollokat minden Bluetooth egységnek támogatni kell, addig az adoptált protokollok közül csak legalább egyet. Az SDP (Service Discovery Protocol) segítségével egy Bluetooth egység képes felderíteni a másik egység által felkínált szolgáltatásokat, és képes megtanulni, hogy hogyan lehet e szolgáltatásokat igénybe venni. Az SDP nem biztosít hozzáférést e szolgáltatásokhoz, csupán a szolgáltatások jellemzőit és igénybevételükkel kapcsolatos információkat teszi közzé a többi Bluetooth egység számára. Egy szolgáltatás igénybevétele más protokollok segítségével, de az SDP által szolgáltatott információk alapján történik.

79. ábra: Adoptált protokollok és alkalmazások Bluetooth-ban

108.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata Az RFCOMM protokoll egy olyan réteg, amely soros interfészt biztosít a felsőbb rétegek számára. Ez a protokoll tulajdonképpen az RS-232-es soros interfész jeleit emulálja, és képes több soros port jeleit multiplexálni. Valójában arra találták ki, hogy a soros portot használó alkalmazásokat módosítás nélkül Bluetooth környezetben is használni lehessen. A TCS (Telephony Control Signaling) protokoll és az AT parancskészlet segítségével megoldható a telefonhívások vezérlése. Az AT parancskészletet arra fejlesztették ki, hogy soros vonalon keresztül vezérelje a modemet, és ez által bonyolítsa le a hívásfelépítést. Ebből következően a Bluetooth eszközök az RFCOMM protokollon keresztül küldenek és fogadnak hívásfelépítéshez szükséges csomagokat. Például egy laptopon futó tárcsázó program (dialer) az AT parancskészlet segítségével utasíthatja a mobiltelefont egy híváskezdeményezésre. A Bluetooth fejlesztői a TCS-AT mellett kifejlesztették a TCS-BIN (Binary) protokollt, amely nem veszi igénybe az RFCOMM-ot, és közvetlenül az L2CAP réteghez kapcsolódik (lásd 79. ábra). Ezen protokoll feladatai közé tartozik a híváskezdeményezés, kapcsolatbontás, vivőjelérzékelés, hívásfogadás, stb. A TCS-BIN a TCS-AT-vel szemben pont-többpont összeköttetést is támogat. Az SDP (Service Discovery Protokoll) olyan primitíveket definiál, amelyeken keresztül megtalálhatóak az egyes Bluetooth egységek által kínált, vagy azokon keresztül elérhető szolgáltatások. Az SDP megalkotására azért volt szükség, mert a Bluetooth dinamikusan változó környezetében az elérhető szolgáltatások is dinamikusan változnak. Az SDP az alkalmazásoknak kínál könnyedséget, hogy azok meg tudják találni az elérhető szolgáltatásokat, és meg tudják azok képességeit határozni. Ahhoz, hogy egy applikáció meg tudja határozni az elérhető szolgáltatásokat, az SDP-nak a többek között a következő funkciókat kell ellátnia: •

Az alkalmazás számára szükséges szolgáltatás keresése szolgáltatási osztály alapján, ezzel párhuzamban, egy szolgáltatás számára felismerhetőség a szolgáltatás alapján.

•

Az alkalmazás számára válogatási lehetőség a szolgáltatások között, anélkül, hogy annak minden tulajdonságát ismerné.

•

Olyan szolgáltatások felismerése, amelyek újonnan jelentek meg a rádió hatótávján belül, vagy egy hatótávon belüli eszköz újonnan indított.

•

Egy újonnan indított szolgáltatást ne kelljen regisztrálni semmilyen központi egységnél.

•

A szolgáltatások, szolgáltatási osztályok, és tulajdonságok egyedi azonosítását.

•

Egy szolgáltatás megkeresését anélkül, hogy más eszközöket ebbe bevonna.

•

Az SDP-nak átlátszónak kell lennie.

Az alábbi ábrán az SDP rendszer egyszerű felépítése látható. Jól látható, hogy a szolgáltatás, amely meg akarja jeleníteni magát, nem önkényesen teszi azt, hanem egy SDP szerver segítségével. Az alkalmazás sem önkényesen keresi a szolgáltatást, ezt egy SDP kliens segítségével éri el. A SDP kliens és szerver tartalmazza a szolgáltatás kereséséhez szükséges eljárásokat és végzik a tényleges keresést. A Bluetooth ezeken kívül számos más protokollt is adoptált. Például támogatja a PPP-t (Point-to-Point Protocol), amely a soros vonalon keresztüli IP kommunikációt teszi lehetővé. További protokollok: •

OBEX (Object Exchange) protokoll: objektumok cseréje vezeték nélküli eszközök között

BZAKA

AmI Project

109.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata •

WAP (Wireless Application Protocol): Internet hozzáférés mobiltelefonról

•

vCard/vCal: névjegykártyák és naptári bejegyzések információinak leírása és kódolása (OBEX-re épül)

Kliens alkalmazás

Szerver alkalmazás

SDP kérés SDP kliens

SDP szerver SDP válasz

80. ábra SDP szolgáltatás felépítése

3.2.9

MAGASABB SZINTŰ SZOLGÁLTATÁSOK, PROFILOK

A Bluetooth technológiát az alábbi célokra fejlesztették ki, amelyeket a Bluetooth specifikáció profiloknak nevez. Ezek tulajdonképpen a protokollszerkezet függőleges vetületei, és a következő általános kategóriákba sorolhatóak: 1. Mobil Headsetek 2. Adat szinkronizálás 3. Nyomtatás 4. Fájl megosztás (file sharing) 5. Vezetékhelyettesítés (Wire Replacement). A profilok célja tulajdonképpen annak egyértelmű definiálása, hogy az egyes alkalmazások mely protokollokra épülnek, ezáltal elérhető, hogy a különböző, de azonos alkalmazást futtató Bluetooth eszközök képesek legyenek együttműködni. Az egyes profilok egymásra épülnek, ezáltal egyfajta hierarchiát alkotnak. Minden profil alapja a GAP (Generic Access Profile), amely tulajdonképpen a szállítási protokollokat tartalmazza, és amely sok más mellett az alapvető rádiós környezetet, az eszközök összekapcsolását, a fizikai és logikai linkeket, valamint a biztonsági algoritmusokat definiálja. Egy másik alapvető profil a soros port profil, amely a GAP mellett az RFCOMM protokollra épül, és megadja, hogy hogyan használható az RFCOMM protokoll a szállítási protokollok felett. Több profil épül erre a profilra. Például az általános objektumcsere profil, amely definiálja, hogy hogyan lehet objektumokat OBEX protokoll segítségével az RFCOMM felett cserélgetni. Léteznek továbbá mobiltelefonnal és modemmel kapcsolatos profilok, valamint faxküldéssel és LAN hozzáféréssel kapcsolatosak, amelyek mind az RFCOMM profilra épülnek. (A LAN hozzáférési profilt az 1.2 specifikáció már nem ajánlja használatra.)

110.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata A Bluetooth SIG a már létező profilok mellett újak kidolgozásával is foglalkozik, mint például nagysebességű rádiós profil; nyomtatás profil; IP kommunikációs profil, amely nem használja sem az RFCOMM sem a PPP protokollokat; autós profil; stb. 3.3


A Bluetooth rendszer olyan jellemzőit vizsgáltuk számítógépes szimulációval, amelyek nem vagy csak nehezen vizsgálhatók méréses eszközökkel. Először bemutatjuk a rendszer vizsgálatához rendelkezésre álló szimulátorokat, majd néhány fontos paramétert vizsgálunk. 3.3.1

SZIMULÁCIÓS ESZKÖZÖK

3.3.1.1 BlueHoc Bevezetés A BlueHoc szimulátor [68] a “Network Simulator” (NS-2.1b6) rendszert bővíti ki Bluetooth funkcionalitással. A BlueHoc az IBM nyilvános licenszének megfelelően (IBM Public License - IPL) ingyenesen letölthető az IBM developerWorks oldaláról. Működése Eszközfelderítés és kapcsolatfelvétel A BlueHoc az eszközfelderítéshez és -csatlakoztatáshoz használatos ún. inquiry és page procedúrák tekintetében a Bluetooth specifikációban meghatározottakat nagyon jól közelíti. A szimuláció egy master (vezérlő) csomópont és több slave (irányított) csomópont létrehozásával kezdődik, majd a master elkezdi a felderítést (inquiry), azaz a masterhoz tartozó BThost objektum HCI_Inquiry parancsot küld a Baseband (alapsávi) rétegnek (lásd ábra). Bár a HCI parancsokat a valóságban a fizikai buszon haladó csomagok szállítják, a szimuláció ezt a funkciót függvényhívásokkal valósítja meg. A HCI_inquiry parancs paraméterei a várt válaszok száma és a felderítés maximális ideje, amelyeket a grafikus felületen keresztül lehet megadni. A HCI_Inquiry parancs hatására a Baseband réteg Inquiry csomagokat kezd küldeni. Az adási frekvencia a master órájától és a GIAC kódtól függ. Az egyes slave egységek az inquiry csomagokra FHS csomagokkal válaszolnak, amelyek az adott slave egység címét és óraállását tartalmazzák. Amikor megfelelő számú válasz összegyűlt, vagy lejárt a felderítésre engedélyezett idő, a master elkezdi felépíteni a kapcsolatot (page) a megtalált slave egységgel R1 módban. A kapcsolatfelvételhez szükséges jelzéseknek csak egy részét valósították meg. A BlueHoc jelenleg egyetlen piconet létrehozását támogatja, amelyben egy master és hét slave egység lehet. LMP jelzések

BZAKA

AmI Project

111.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata A page procedúra után a slave egység már a master ugrási sorozatára szinkronizálódott, és a kapcsolatkezelő protokoll (Link Manager Protocol – LMP) egy aszinkron csomagkapcsolt összeköttetést (Asynchronous Connection-Less - ACL) épít ki a master és a slave egység között. Ehhez a masterben lévő LMP alrendszer egy LMP_host_connection_req üzenetet küld a salve hasonló alrendszerének. Amikor a master megkapja a választ a slave-től, HCI eseményben értesíti a BTHost objektumot a kapcsolat sikeres vagy sikertelen felépüléséről a kiválasztott egységgel. Ezután a master QoS beállítási LMP parancsot küld a slave-nek az alkalmazás igényeinek megfelelő QoS paraméterekkel. A szimulátorban ACL összeköttetésenként egy folyam lehetséges. Az LMP továbbítja a QoS paramétereket a “deficit round robin” (DRR) elvű ütemezőnek, amely eldönti, hogy az új kapcsolatot el lehete fogadni vagy vissza kell utasítani. L2CAP kapcsolatfelépítés A QoS paraméterek beállítása után az LMP HCI_QoS_setup_complete_event eseményt küld a BThost objektumnak. Ezután a kapcsolat-felépítést kezdeményező fél L2CAP_connection_request üzenetére a másik fél L2CAP_connection_response üzenettel válaszol. Minden L2CAP csatornához egy kapcsolatazonosító (connection identifier - CID) tartozik, így egyetlen ACL kapcsolaton keresztül több csatorna létrehozható. A jelzések átviteléhez az 1-es CID-et használják. A szimulátor azonban ezt a funkciót nem támogatja. Az L2CAP szintű QoS egyeztetés szintén nincs még implementálva. QoS leképzés A QoS paramétereket ACL kapcsolatonként csak egyszer lehet a szimulációban beállítani. A hagyományos alkalmazások (pl. Telnet, FTP, VoIP) QoS igényeit az RFC 1363 -hoz hasonló folyammegadással lehet a MAC rétegbeli ütemezőhöz eljuttatni. A DRR ütemező először a vételi viszonyok és az alkalmazási rétegbeli MTU méret alapján meghatározza a baseband réteg által használandó csomagtípust, és az aktuális terheltség és az új kapcsolat igényei alapján eldönti, hogy az elfogadható-e. Ha igen, a kapcsolat round robin ciklusonként kap valamekkora kiszolgálási időt. Időfoglalásra csak az előre haladó (mastertől a slave felé menő) forgalom esetében van lehetőség. A foglalás jelenleg közvetlenül a folyammegadásból következik, ami pedig attól függ, hogy a grafikus felületen a felhasználó FTP, Telnet vagy “voice” alkalmazást választott-e. Az L2CAP (Logical Link Control and Adaptation Protocol) szimulációja Az L2CAP_connection_req és a L2CAP_connection_response üzenetek küldésén, fogadásán és a távoli CID azonosítók kezelésén kívül az L2CAP rétegnek két fő feladata van: − A felsőbb rétegekből érkező csomagokat darabolja, majd a vételi oldalon összeállítja (segmentation and reassembly - SAR). − Megvalósítja a DATA_WRITE primitívet a felsőbb rétegbeli csomagok adott CID-del azonosított logikai csatornán történő átviteléhez.

112.

AmI Project

BZAKA


81. ábra: Kapcsolatfelépítésl és QoS paraméterek beállításáva

Az NS-2 TCP/IP szimulációinak használata Az ns-2 a TCP/IP szimulációk széles körét képes megvalósítani. Az ns-2 különféle szállítási rétegeket, útvonalválasztási protokollokat és alkalmazásokat képes szimulálni. Többek között az alábbi szállítási rétegeket megvalósító osztályokat nyújtja: − Agent/UDP − Agent/TCP: Tahoe TCP forrás − Agent/TCP/Reno: Reno TCP forrás − Agent/TCP/NewReno: új Reno − Agent/TCP/Sack1: külön nyugtázó (Selective repeat) TCP − Agent/TCP/Vegas Az ns forgalomgenerátorokkal és szimulált alkalmazásokkal is rendelkezik. Utóbbiak például: − Application/FTP: FTP alkalmazás − Application/Telnet: Telnet alkalmazás Forgalomgenerátorok például: − Application/Traffic/Exponential : ON, OFF forgalom pl. hang − Application/Traffic/Pareto : ON, OFF börsztös forgalom Pareto eloszlás szerinti időkkel

BZAKA

AmI Project

113.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata − Application/Traffic/CBR : konstans bitsebességű forgalom − Application/Traffic/Trace : mérési fájból történő forgalomgenerálás Grafikus Interfész A Bluehoc grafikus felületén keresztül a piconetben szereplő maximálisan nyolc egység paramétereit lehet beállítani. Az interfészt egy Tk nyelvű szkript biztosítja, és semmilyen hibaellenőrzést nem valósít meg, és alapértelmezett értékek sincsenek megadva. Egy szimuláció futtatásához legalább a következőket kell beállítani: Master csomópont esetében: − Starttime: (bekapcsolás időpontja másodpercben): Általában 0. − NumResponses (várt válaszok száma): Az inquiry folyamat során hány választ várunk be, maximálisan a slave egységek száma. − InqTimeout (a felderítés maximális időtartama másodpercben): Általában 10,24 mp. Slave csomópont esetében: − Starttime (bekapcsolás időpontja másodpercben): A slave egységek általában a master után kell bekapcsolni. − InqScanOffset (másodpercben): Általában 0 és 2,56 között. Szimulációs idő: Öt lehetőség közül lehet választani: 10, 20, 30, 40 és 50 mp. Alkalmazások: Minden kapcsolat esetében meg kell adni, hogy az alábbi alkalmazások közül melyikre jellemző forgalom haladjon a kapcsolaton: − FTP − Telnet − Voice (ez a hangátvitel az ns-2 Application/Traffic/Exponential forgalomgenerátorát használja) A szimulátor beállítása A grafikus felület működéséhez a Tk ablakozós shelljére, a wish -re van szükség. A telepítés után a szimulátor az ~ns/run könyvtárában a "wish bluehoc.tcl" paranccsal indítható. Ez indításkor egy "Bluehoc configuration" fejlécű ablakot jelenít meg. A Configure menüben adható meg a szimulációs idő. A Scenario gombra kattintva megadható a mérési összeállítás. Egy master és maximum hét slave eszközzel futhat a szimuláció, és megadható milyen távolságra legyenek egymástól. Az létrehozott eszközökre illetve a közöttük lévő linkekre duplán kattintva beállíthatjuk azok jellemzőit. Először a master egységet kell konfigurálni, majd a slave egységeket.

114.

AmI Project

BZAKA


82. ábra: A master beállítása

Az eszközök beállítása után az Output menüpontban választhatók ki, hogy milyen a naplózást (pl. nam, BTTrace) illetve grafikonokat kérünk, majd elmenthetjük a szimulációs összeállítást. A szimuláció ekkor indul el. A szimuláció végeztével a kért grafikonok illetve naplófájlok megtekinthetők, elemezhetők. Naplózás A BlueHoc kétféle naplóformátumot támogat: − Nam − BTTraces (Bluetooth specifikus napló) A nam formátumú naplófájlokat az ns csomag részét képező nam (Network animator) programmal lehet megnyitni. A BlueHoc által generált nam napló kétféle eseményt tartalmaz: 'hop' és 'node' eseményeket, amelyek hatására láthatóvá válnak a linkeken haladó csomagok, kiíródnak a csomópontok állapotai, stb. A Bluetooth specifikus napló az inquiry és page procedúrák alatt érkező minden csomagról, továbbá a sikeresen vett LMP és L2CAP üzenetekről tartalmaz bejegyzéseket. A 'DELAY' szót tartalmazó sorok az átbocsátóképesség és a késleltetés eloszlásáról adnak információt. A naplófájl formátuma:

BZAKA

AmI Project

115.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata BD_ADDR <eszközcím> DELAY SIZE clock <szimulációs idő> .

3.3.1.2 Blueware A Blueware-t [70] azért fejlesztették ki, hogy a Bluetooth specifikációban a nagyobb hálózatokkal (scatternetekkel) kapcsolatban nyitva hagyott kérdéseket vizsgálni lehessen, és a gyakorlatban is meg lehessen valósítani az önszervező Bluetooth hálózatokat. A három fő probléma a topológia kialakítása, a linkek forgalmának ütemezése és a forgalomirányítás megoldása. Az első abból adódik, hogy a Bluetoothban az üzenetszóráson alapú vezetéknélküli hálózatokkal (pl. 802.11) ellentétben a rádiós közelség még nem határozza meg a hálózat topológiáját, mivel az eszközöknek explicit módon is kapcsolatot kell létrehozniuk egymással. Az, hogy mely eszközökkel építünk ki kapcsolatot jelentősen befolyásolja a hálózat átviteli sebességét. Mivel a Bluetooth eszközök egyszerre csak egy linken képesek kommunikálni, és ugyanakkor forgalomtovábbítási feladatuk is van, el kell dönteniük, hogy mikor melyik kapcsolatukon és mennyi ideig kommunikálnak, azaz a forgalom ütemezésére van szükség. Az ütemezés, ami a második probléma, szintén alapvetően meghatározza a hálózat teljesítményét. Bluetooth rendszerre optimalizált útvonalválasztó protokollra pedig azért van szükség, mert a Bluetooth eszközök tipikusan kis memóriával és korlátozott energiaforrásokkal rendelkeznek, amiket célszerű figyelembe venni az útvonalválasztó algoritmus tervezésekor.

3.3.1.3 BT-Sim A BT-Sim [69] egy Java nyelven írott, HCI szintű Bluetooth hardware szimulátor, amely lehetővé teszi, hogy valódi Bluetooth eszközök nélkül is fejleszthessünk és tesztelhessünk Bluetooth-os alkalmazásokat. A BT-Sim a PalmSource által kifejlesztett Palm OS Simulatorral is együttműködik. Előnyei, hogy az alkalmazás és a szimulált eszköz közötti kommunikáció könnyen megfigyelhető; egyszerűen ellenőrizhető, hogyan működne az alkalmazás nagyszámú Bluetooth eszközzel; olyan szolgáltatás működése is tesztelhető, amelyhez még nincs valós hardver; illetve segítségével automatizálható a szoftvertesztelés. Hátrányai viszont, hogy a műveletek időzítése nem felel meg pontosan a valós eszközökkel tapasztaltnak; nem veszi pontosan figyelembe a rádiós környezet okozta hatásokat; és nem egy adott Bluetooth hardver implementáció pontos szimulációját nyújtja.

3.3.1.4 Bluetooth-sim A Bluetooth-sim a Budapesti Műszaki Egyetem Távközlési és Médiainformatikai Tanszékén fejlesztett, C++ nyelven írt, objektum orientált, diszkrét esemény szimulátor, mely pontosan modellezi a Bluetooth rendszer Radio és Baseband rétegének működését, az egységek között zajló üzenetcserét, ám ez sem modellezi az összes Bluetooth funkciót (pl. szegmentálás, ARQ), valamint nincs grafikus megjelenítési felülete.

116.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata A szimulátor felépítése A Bluetooth-sim szimulátorban a Bluetooth egységeket leíró objektum a BtNode, mely modellezi az adatkapcsolati és hálózati rétegbeli funkciók többségét. Az egységek működésének jól elkülöníthető részeit beágyazott objektumok valósítják meg. Minden egységhez tartozik egy StateManager objektum, mely az aktuális állapotot tartja nyilván, valamint az állapotok közti váltásokat vezérli. Külön puffer van az adat csomagok (DataBuffer), illetve a vezérlő csomagok (ControlBuffer) tárolására. Az egységek részét képezi egy Router objektum, mely az elküldött csomagok útvonalát határozza meg. A piconetek közti illetve azon belüli adatforgalom ütemezését valósítja meg az InterPiconetScheduler, illetve az IntraPiconetScheduler. Az rádiós hatótávolságon belüli egységek által használt frekvenciákat az InterferenceManager objektum tárolja, melynek segítségével megállapítható, hogy egy csomag vétele sikeres volt-e vagy sem. A forgalmat alkotó csomagokat a BtPacket objektumok valósítják meg. Az adatforgalmat az egységekhez kapcsolt külön objektum biztosítja. A szimulációk során egy véletlen forgalom generátort alkalmaztam (SourceRandom), mely előre meghatározott sűrűséggel állít elő DH1, DH3, DH5 típusú csomagokat. Két kommunikáló egység felépítését az 5.1. ábra jeleníti meg.

83. ábra: Kommunikáló Bluetooth egységek a Bluetooth-sim szimulátorban

BZAKA

AmI Project

117.



3.3.2.1 Eszközfelderítés ideje Egy technológiához kapcsolódó eszköz-felderítési idő alapvetően azt befolyásolja, hogy mennyire alkalmas a technológia gyors reagálást igénylő feladatok ellátására. A Bluetooth rendszer által biztosított eszköz-felderítési idő vizsgálatához a Bluetooth-sim szimulátort és a következő mérési összeállítást használtuk. Egyre növekvő számú (maximum 200 darab) Bluetooth csomópontot helyeztünk a síkra úgy, hogy az eszközök egymás rádiós hatótávolságán belül legyenek, majd minden csomópont esetében elindítottuk az eszközfelderítési folyamatot (inquiry – inquiry scan), aminek hatására az eszközök elkezdték felderíteni a környezetüket. Amikor két eszköz megtalálta egymást, rögtön felépítettük közöttük a kapcsolatot (page). A szimuláció során azt mértük, hogy mennyi idő alatt épül ki az összes lehetséges kapcsolatok fele úgy, hogy mindegyik link működőképes. Egy link akkor működőképes, ha szimmetrikusan épült ki, azaz mindkét eszköz (mind a master, mind a slave) úgy gondolja, hogy a kapcsolat felépült. A működésképtelen kapcsolatok kiszűrésére a Bluetooth rendszer egy nagy periódusidejű időzítőt (link supervision timeout) használ, amely lejártakor lebontja a kapcsolatot, ha azon az időzítő futása alatt nem történt üzenetcsere. Amíg ez nem történik meg, a hibás kapcsolat foglalja a master erőforrásait. Ha sok csomópont foglalkozik egyszerre eszközfelderítéssel, nagy az interferencia, gyakrabban vész el a slave-ek által küldött utolsó ún. „page response” csomag és megnő az aszimmetrikusan kiépült vonalak száma is. Azért mérjük tehát az összes lehetséges link felének felépülési idejét, mert ez jól mutatja az eszközfelderítés sebességét, ugyanakkor kiszűrjük az ún. link supervision timeout hatását. A szimuláció során kiépült linkek száma tehát:

⎢ n ∗ (n − 1) ⎥ ⎢⎣ ⎥⎦ , ha n < 15 4

⎢ 7n ⎥ , egyébként, ⎢ 2 ⎥⎦ ⎣ ahol n a csomópontok száma. Az Bluetooth-sim interferencia modellje úgy működik, hogy ha két, egyazon frekvencián küldött csomag valamekkora részben időben átfedi egymást, akkor 0,9 valószínűséggel mindkét csomag elvész. A csomópontok véletlenszerű ideig tartózkodnak inquiry illetve inquiry scan állapotban, az egyes állapotokban tartózkodás ideje a (0, 2048) időrés intervallumban egyenletes eloszlású. A két inquiry frekvencia train hatását figyelmen kívül hagytuk. A következő ábrán a felderítési időt logaritmikus skálán ábrázoltuk, a görbe 10 szimulációs futás átlagát és szórását mutatja.

118.

AmI Project

BZAKA


1000

Idő (s)

100

10

1

4

8 19

19

18

0

7 17

17

6

9

2

3 16

15

14

14

8

1

4

5 13

12

12

11

0

7 10

93

10

86

72

79

65

58

51

44

37

30

23

9

16

2

1

0 ,1

A fe ld e ríté s t vé g z ő c s o m ó p o n to k s z á m a

84. ábra: Eszközfelderítési idő

A várakozásoknak megfelelően egy nagyobb scatternet felépítése több időt vesz igénybe, azonban a növekedés nem lineáris, hanem exponenciális. Ennek oka első sorban az inquiry folyamat során küldött nagy üzenetszámból következő nagy interferencia.

3.3.2.2 Csomagvesztés Fontos kérdés, hogy mennyire érzékeny egy rádiós alapú kommunikációs technológia az interferenciára. Itt most nem a külső tényezők hatását, hanem azt vizsgáljuk, hogy milyen hatást fejt ki a Bluetooth egységek kommunikációja a többi Bluetooth egység kommunikációjára. Ehhez szintén a Bluetooth-sim szimulátort használjuk. A lehető legkisebb (egy master és egy slave egységből álló) piconetekkel dolgozunk, amelyekben mindkét egység egy igen nagy fájlt kíván átvinni a másiknak, azaz mindig kitölti a hozzá rendelt adási időrést. Mivel a kommunikáció a masterhoz rendelt ugrási sorozaton történik, az, hogy hány slave egységet teszünk egy piconetbe, az interferencia szempontjából lényegtelen. Minden egység különféle csomagtípusokat küld: DH1, DH3 és DH5 csomagokat, rendre 0,3 ; 0,1 és 0,6 valószínűsséggel. A szimuláció során először létrehozunk egy referencia piconetet, majd további piconeteket úgy, hogy bármely két egység egymás rádiós hatósugarán belül legyen. A piconetek nincsenek időszinkronban, azaz az adási időrések véletlenszerűen fedik egymást. Az automatikus újraküldés (ARQ) funkciót nem használjuk. Ezek után azt vizsgáljuk, hogy a referencia piconetben küldött csomagok mekkora valószínűséggel mennek át sikeresen a rádiós csatornán egy adott piconet-szám mellett. A következő ábra tehát a sikeres átvitel valószínűségét mutatja az interferáló piconetek számának függvényében.

BZAKA

AmI Project

119.


1,2

1

P

0,8

dh1 dh3 dh5

0,6

0,4

0,2

0 1

6

11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96 101 106 111 116 121 126 131 136 A piconetek száma

85. ábra: Sikeres adatátvitel valószínűsége az interferáló piconetek számának függvényében

Az ábrán jól látható, hogy az interferenciára a hosszabb csomagok sokkal érzékenyebbek, mint a rövidek, ami abból következik, hogy ha hosszabb ideig tart egy adott frekvencián az átvitel, nagyobb a valószínűsége, hogy egy másik piconetben is történik az idő alatt adás, így a csomagvesztés valószínűsége is nő. Az ábrán látható, hogy a piconetek számával logaritmikusan csökken a sikeres átvitel valószínűsége. 3.3.3

ÉRTÉKELÉS

A fenti vizsgálatokból az látszik, hogy a Bluetooth technológia olyan alkalmazásokban használható jól, ahol jellemzően nincs szükség gyors reagálásra, és viszonylag kisszámú Bluetooth eszköz működik egymás rádiós hatósugarában. Minél több egység kerül egymás közelébe, annál lassabb lesz az új eszközök becsatlakoztatása, és annál lassabb lesz a meglévő scatternetben az adatkommunikáció. A technológia tehát elsősorban kevés kommunikáló eszköz közötti vezetékek kiváltására alkalmas.

120.

AmI Project

BZAKA


3.4

MÉRÉSES VIZSGÁLAT

A Bluetooth rendszer vizsgálatát a 2.8.2 fejezetben leírtak szerint, illetve azokhoz igen hasonlóan végeztük az alábbi változtatásokkal. Egyrészt, természetesen Bluetooth hálózati kártyákat használtunk (ld. 45. ábra). A kártyák 1-es osztályúak, azaz 100mW-os adóteljesítménnyel rendelkeznek. Ezekhez a kártyákhoz nem csatlakoztatható külső antenna, csak a beépített antennájuk nyitható fel a jobb adás-vétel érdekében. Ezt a mérésekhez meg is tettük. A méréseket két kültéri helyszínen végeztük. Az első helyszín családi házas, külvárosi jellegű volt (Bp. XI. ker, Kővirág utca, a Szabadságharcosok útja és a Tambura utca között), a második pedig mezőgazdasági területek közötti egyenes országút (Törökbálint, Raktárvárosi út a DEPO-nál). A méréseket két Bluetooth egységgel végeztük, amelyek egy piconetet alkottak. Az egyik egység (slave) mindig egy talapzaton állt, hozzávetőlegesen ötven centiméteres magasságban. A másik mozgásban lévő egység volt (master) , ennek pozícióját GPS segítségével követtük nyomon. A családi házas környezetben (ahol alacsony volt a forgalom), a mozgó mérő egységet az autó tetején, míg a forgalmas országúton az autón belül, annak hátsó ablaka mögött helyeztük el. Az autó először távolodott a rögzített mérőponttól addig, amíg ki nem került annak rádiós hatósugarából, majd visszatért a mérőponthoz. A slave egység folyamatosan figyelte és naplózta a vett jel erősségét (RSSI – Received Signal Strength Indicator) és a kapcsolat minőségét (LQ – Link Quality). Ha a kapcsolat megszakadt, folyamatosan próbált újra kapcsolódni a masterhez. Néhány különbségtől eltekintve a mérési módszerek megegyeztek a WiFi rendszert vizsgáló mérésekben használtakkal, úgy mint: mérés előtt időszinkronizáció, DBS alapú forgalomgenerálás és mérés, 8Mbit/s sebességű UDP forgalom (1 ms-onként 1024 byte nagyságú UDP csomag küldése). 3.4.1

CSALÁDI HÁZAS KÖRNYEZETBEN VÉGZETT MÉRÉSEK

A családi házas környezetben végzett mérések eredményét a (*) 86. ábra mutatja. A két mérőeszköz távolságát mutató d) és az átbocsátóképességet mutató a) ábrát összevetve látható, hogy a mérés során a rádió hatósugara körülbelül 100 méternek adódott, ami megfelel a nominális értéknek. Az átbocsátóképesség 440Kbit/s körül tetőzött. Látható, hogy az eszközök távolodásakor az átbocsátóképesség fokozatosan csökken, majd a kapcsolat megszakad. Az újraépülésekor látható átvitel-tüskét (kb. 2,9Mbit/s) mérési hibának kell tekintenünk, ekkora átbocsátóképességre ugyanis a Bluetooth rendszer 1.1-es verziója nem képes. A késleltetés (b) ábra) normál működés közben néhány tíz milliszekundum nagyságrendű volt. Az ábrán látható 150 másodperces késleltetési maximum abból adódik, hogy a kapcsolat megszakadásától a csomagok a pufferben várakoznak, és a kapcsolat újraépülésekor kerülnek átvitelre. A csatornán csak 180 feletti kapcsolat-minőség (LQ) esetén történt adatátvitel.

BZAKA

AmI Project

121.


250

Distance [m]

200

150

100

50

0 0

100

200 Time [sec]

a)

d) 0 0

100

200

-2

RSSI

-4

-6

-8

-10

-12 Time [sec]

b)

e) 300

250

LQ

200

150 100

50 0 0

100

200 Time [sec]

c)

f)

(*) 86. ábra: a) Sávszélesség; b) Csomagkésleltetés; c) Késleltetés-ingadozás (Jitter); d) Távolság; e) Vett jelerősség indikátor; f) Kapcsolat-minőség;

122.

AmI Project

BZAKA


ORSZÁGÚTON VÉGZETT MÉRÉSEK

A forgalmas országúti környezetben végzett mérések eredményét a (*) 87. ábra mutatja. Az eredmények nagyon hasonlók a családi házas környezetben mértekhez. A rádió hatósugarát itt 101 méternek mértük. Az átbocsátóképesség itt is 440 Kbit/s-on tetőzött. Amíg az eszközök egymáshoz közel helyezkedtek el az átboácsótképesség átlagos értéke 417 Kbit/s volt, a csomagvesztés 5,2% körüli. Az eszközfelderítési idő itt 12 másodpercnek adódott. A kapcsolat-minőségét és a vett jel erősségét mutató görbékben látható egy kb. 2 másodperc hosszú szakadás. Ez annak a következménye, hogy a kernel megszűntette a hosszú ideig működésképtelen kapcsolathoz tartozó hálózati interfészt (bnep0). Ekkor természetesen az ezt az interfészt használó mérőeszközök csupán egy hibaüzenetet írnak ki, mert abban a pillanatban nem létező interfész paramétereit akarjuk velük vizsgálni. A háttérben futott egy script, amely folyamatosan azt figyelte, hogy létezik-e a vizsgált hálózati interfész, és ha nem, akkor megpróbálta azt létrehozni. Amikor az interfész újra elérhetővé vált, az LQ és RSSI paraméterek megfigyelése folytatódott. 700 600

Distance [m]

500 400 300 200 100 0 0

100

200

Time [sec]

a)

d) 10

5

0 RSSI

0

100

200

-5

-10

-15

-20 Time [sec]

b)

BZAKA

e)

AmI Project

123.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata 300

250

LQ

200

150 100

50 0 0

100

200

Time [sec]

c)

f)

(*) 87. ábra: a) Sávszélesség; b) Csomagkésleltetés; c) Késleltetés-ingadozás (Jitter); d) Távolság; e) Vett jelerősség indikátor; f) Kapcsolat-minőség;

3.4.3

ÉRTÉKELÉS

A mérési eredmények azt mutatják, hogy a Bluetooth technológia viszonlyag kis rádiós hatótávolsága valamint nagy eszközfelderítési ideje miatt az autók közötti kommunikációs céljainknak nem felelnek meg. Ugyanakkor az autón illetve a lakáson belüli alkalmazásokban jól alkalmazható a technológia.

124.

AmI Project

BZAKA


4. A JÖVŐ POTENCIÁLIS SZÉLESSÁVÚ KOMMUNIKÁCIÓJA Napjainkban egyre nagyobb a felhasználók igénye arra, hogy otthoni vagy irodai adatátviteli eszközeiket vezetéknélküli összeköttetéssel rendezhessék hálózatba. Az összeköttetések felhasználási lehetőségeinek köre igen széles: a nagyméretű adatfájlok átvitelétől kiterjedhet egészen a multimédiás alkalmazásokig, videófolyamok továbbításáig (88. ábra). Számos olyan szabvány készült (89. ábra), amely a fenti célok megvalósítására alkalmazható vezetéknélküli rendszereket ír le. Ide tartozik a Bluetooth technológia is (amely megfelel a 802.15.1 szabványnak), amely lényegében egy kezdeti próbálkozás a számítógépek és perifériáik, valamint a mobil eszközök közötti vezetékek olcsó és egyszerű helyettesítésére sikerrel alkalmazható. Egyszerűsége azonban a nagysebességű adatátviteli paraméterek feláldozásával jár együtt.

88. ábra: Alkalmazási lehetőségek

Egy újabb módját kínálja vezetéknélküli személyi hálózatok (Wireless Personal Area Networks - WPAN) kialakításának az IEEE (Institute of Electrical and Electronics Engineers) 802.15.3 szabványa [59]. A szabványnak megfelelő hálózatok akár 255 vezetéknélküli eszközből is állhatnak, az összeköttetés hatósugara maximum 55 méter lehet, az adatátviteli sebesség pedig elérheti az 55 Mbps-os értéket. A tervezéskor az energiatakarékosság mellett a költségek alacsony szinten tartása, a szükséges új alkatrészek számának minimalizálása is fontos szempont volt. A szabvány kidolgozása során ugyancsak nagy figyelmet fordítottak arra, hogy az új WPAN hálózatok és a már meglévő vezetéknélküli hálózatok egymás melletti üzeme zavartalan legyen. Erre azért volt szükség, mert a 802.15.3 hálózatok is a szabadon használható, 2.4 GHz-es ipari, tudományos és orvosi célú (Industrial, Scientific and Medical ISM) sávban működnek [60].

BZAKA

AmI Project

125.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata A 802.15.3 szabvány ultraszélessávú (Ultra Wide Band - UWB) vezeték nélküli technológiát használ. Főleg a különféle szórakoztató-elektronikai készülékekben, digitális kijelzők esetén, DVD-lejátszókban, set-top boxokban, kamerákbna stb. alkalmazzák az emítet szabványt. A következő három év során megjelenő, 1 Gbps feletti sebességű UWB-rendszerek olyan lejátszók elterjedését is elősegíthetik, amelyek teljes filmeket lesznek képesek igen rövid idő alatt letölteni. Ugyancsak fontos célterületnek számít a hordozható merevlemezek piaca. 2004 harmadik negyedévére ígérték a gyártók a 110 Mbps adat-sávszélességet nyújtó UWB eszközök piacon való megjelenését. Ugyanakkor a harmadik generációs, 220 Mbps feletti sebességre képes megoldás első mintái 2004 utolsó negyedévében, míg a 480 Mbps és 1 Gbps sebességű modellek a jövő évben jelenhetnek meg.

89. ábra: Vezetéknélküli szabványok

Nagyon fontos követelmény az újonnan kifejlesztett szabványokkal szemben, hogy támogassanak különböző szolgáltatásminőségi paramétereket (Quality of Service - QoS) garantáló módszereket. A QoS tulajdonképpen a hálózatok képessége az erőforrások meghatározott rend szerinti felosztására [61]. Általánosságban elmondható, hogy az ezt támogató hálózatokon a magas prioritású üzenetek előnyben részesülnek az alacsonyabb prioritásúakkal szemben. Így versenyhelyzetben az előbbiek továbbítása az utóbbiak feltartóztatásával garantált sávszélességen biztosítható. Ezekkel a megoldásokkal tehát garantálni lehet a stabil, nagy sebességű átvitelt az ezt igénylő (például multimédiás, hangot, illetve képet továbbító) szolgáltatások számára. Az egyre nagyobb szerepet kapó ad-hoc hálózatok előzetesen kiépített infrastruktúra nélkül, a változó viszonyokhoz alkalmazkodva is képesek üzemelni. A 802.15.3 hálózatok is ad-hoc hálózatok, megfelelve ezzel a terjedőben lévő ilyen irányú igényeknek. A 802.15.3 protokoll szerint felépülő rendszerek a Bluetooth-hoz hasonlóan mester-szolga architektúrájúak. A Bluetooth rendszertől eltérő módon, a mester eszköz (Piconet Coordinator - PNC) csak a csatorna-hozzáférés vezérlésével és az ütemezéssel kapcsolatos feladatokat lát el, az adattovábbításban nem vesz részt. A protokoll az adatátvitel céljára egy időosztásos (Time Division Multiple Access - TDMA) rendszert ír le, a csatornaidőből az egyes eszközök számára kiosztott időréseket úgynevezett főkeretekbe foglalva.

126.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata Jelen alfejezetben röviden bemutatásra kerül az IEEE 802.15 szabványcsoport néhány eleme. Ezek a szabványok jelenleg még nem rendelkeznek gyakorlati megvalósítással, viszont a piaci megjelenésük után gyors elterjedésük várható. Így röviden bemutatjuk az IEEE 802.15.3 szabványt. Ezen szabvány a szélessávú WPAN hálózatokat definiálja és írja le. A szélessávú WPAN hálózatok leírása után a keskenysávú szenzor hálózatok kerülnek bemutatásra, amelyeket az IEEE 802.15.4 szabvány foglal magába. Jelen tanulmány célja ugyanakkor a szélessávú hozzáférést biztosító rendszerek bemutatása is. Ezek közé tartoznak az IEEE 802.16 [62] és az IEEE 802.20 [63] szabványok. Az első szabvány fix hozzáférést biztosító vezetéknélküli szélessávú rendszert határoz meg. Ezzel szemben a második szabvány a nagy utazási sebességnél is szélessávú vezetéknélküli kommunikációt biztosító rendszert definiálja. A 1. és a 2. táblázat több szempontot figyelembe vevő rövid technológiai összehasonlítást mutat a fentebb említett rendszerekről. WiMAX 802.16

802.20

3G

IP mobilitás (> 1Mbps)

IP barangolás (roaming) és hívásátadás (handoff) (> 1Mbps)

Áramkör-kapcsolt celluláris adattovábbítás (< 1Mbps)

Új MAC and PHY rétegek IP-re kihegyezve és adaptív antennák

W-CDMA és CDMA-2000

Visszafele kompatibilis a 802.16-al

Mobilitásra optimalizált

GSM következménye

2-6 GHz között

Licenszköteles sávok 3.5 GHz alatt

Licenszköteles sávok 2.7 GHz alatt

Csomag-kapcsolt Architecture

Csomag-kapcsolt

Vonal-kapcsolt

Alacsony késleltetés

Alacsony késleltetés

Magas késleltetés

A 802.16 MAC és PHY rétegek kibővítése

1. táblázat: Technológiai összehasonlítás: 802.16, 802.20, 3G WiMAX 802.16

WLAN 802.11

WPAN 802.15

Frekvenciasáv

2-11GHz

2.4GHz

változó

Hatótávolság

~50 km

~100 méter

~10méter

Átviteli sebesség

70 Mbps

11 Mbps - 55 Mbps

20Kbps - 55 Mbps

Felhasználók száma

Több ezer

> 10

> 10

2. táblázat: Technológiai összehasonlítás: WiMAX, WLAN, WPAN

4.1

IEEE 802.15.3

Az alábbiakban ismertetjük, hogyan definiálja a 802.15.3-as szabvány a vezetéknélküli személyi hálózatokban az úgynevezett piconetek elemeit, felépítését. Áttekintjük a hálózat alapvető működését. Bemutatjuk a csatorna-hozzáférés alapjául szolgáló főkeret-struktúrát és az e keretekben lebonyolítható adatátvitel szabályait. Ugyanakkor rövid leírást adunk a főkeretek képzésének lehetséges módjairól. A fejezet végén érintünk néhány, a hálózat fenntartásával kapcsolatos kérdést, valamint bemutatjuk a szabvány által biztosított energiagazdálkodási lehetőségeket. BZAKA

AmI Project

127.


A PICONET FOGALMA ÉS ELEMEI

A piconet egy vezetéknélküli adatátviteli rendszer, amely lehetővé teszi, hogy az erre alkalmas eszközök egymással kommunikáljanak. A piconetet az különbözteti meg a hasonló hálózatoktól, hogy az adatforgalom általában egy személyhez vagy tárgyhoz köthető, és egy, minden irányban körülbelül 10m kiterjedésű térben zajlik, körülvéve a helyhez kötött vagy éppen mozgó embert vagy tárgyat.

90. ábra: A piconet elemei A piconet alapköveit, építőelemeit az adatátviteli eszközök jelentik (device - DEV). Közülük egy eszköznek fel kell vállalnia a piconet-irányító (Piconet Coordinator - PNC) szerepét. A rendszerben résztvevő eszközök viszonyát a 90. ábra mutatja. Szokás a PNC-t mesternek (master), a többi eszközt pedig szolgának (slave) is nevezni, utalva ezzel a rendszer mester-szolga architektúrájára. Ebben az architektúrában az adatátvitelhez használt csatorna felügyeletét a felek nem közösen látják el, fölötte a mester gyakorolja a kizárólagos ellenőrzést. Egyúttal gondoskodik a csatorna megosztásáról a hálózathoz csatlakozó szolgák között. Az ütközéseket elkerülendő, a szolgák csak akkor küldhetnek adatot, amikor a mester őket erre felszólította. Előfordulhat, hogy a szerepek vándorolnak, azaz, hogy a korábban szolga szerepet betöltő eszköz mester szerepbe kerül. A PNC szolgáltatja a piconet működésének alapvető időzítését a vezérkeret (beacon) felépítésével és sugárzásával. A PNC ezen felül a szolgáltatás minőségével (Quality of Service), energiagazdálkodással és hálózatbiztonsággal kapcsolatos feladatokat is elláthat. A nagy kiterjedésű hálózatok létrehozása érdekében a szabvány lehetővé teszi, hogy egy újonnan kialakult piconetet egy, már létező piconetnek alárendelve formáljunk. Ezeket gyermek (child), vagy szomszéd (neighbor) piconetnek hívjuk, a fölérendelt piconethez való kapcsolódás módja szerint. A gyermek vagy szomszéd piconettel nem rendelkező piconeteket független (independent) piconetnek nevezzük. A 802.15.3 közeghozzáférés vezérlő (Medium Access Control - MAC) protokollját úgy alakították ki, hogy gyors csatlakozást tegyen lehetővé, támogassa az ad-hoc hálózati formát és a QoS adatátvitelt. Kezelnie kell tudni azt, hogy a hálózat elemeinek száma dinamikusan változik, és mindemellett hatékony adattovábbításra legyen képes.

128.

AmI Project

BZAKA


ALAPMŰKÖDÉSEK A PICONETBEN. INDÍTÁS, CSATLAKOZÁS, LEÁLLÁS

A piconet indítása. Egy piconet létrejöttéről akkor beszélünk, ha egy 802.15.3 szabványnak megfelelő eszköz, amely képes a PNC feladatok ellátására is, vezérkereteket (beacon) kezd el sugározni. A PNC egyik legfontosabb feladata, hogy vezérkereteket adjon, amelyek megfelelő információt tartalmaznak a piconetről. Egy piconet elindításakor a PNC végigpásztázza a lehetséges csatornákat, üres csatorna után kutatva. Ha talál ilyet, és meggyőződik róla, hogy a csatorna bizonyos ideje üres, akkor elkezdi sugározni a vezérkereteket. Amennyiben nincs üres csatorna, akkor a PNC alárendelt piconetet formálhat. (Ennek két fajtája a lentebb bemutatandó gyermek és szomszéd piconet.) Szintén ehhez folyamodhat, ha piconet működése közben bármikor észleli, hogy a csatornát egy másik piconet is használja. Ha van nála „alkalmasabb” eszköz a PNC feladatok ellátására, akkor a kialakítás után a szerepét annak átadhatja. Ezt az eljárást hívásátadásnak (handover) nevezzük. Csatlakozás a piconethez. Ahhoz, hogy egy eszköz csatlakozzon egy piconethez, egy eljáráson kell átesnie. Erre vonatkozó kérését a főkeret versengéses hozzáférési periódusában (lásd később) közli a PNC-vel. A PNC dönt arról, hogy az eszköz csatlakozhat-e, és ha igen, akkor mikor csatlakozhat a hálózathoz. A csatlakozással egy eszköz-azonosítót (Device ID DEVID) kap. A piconetben lévő eszközöknek mind van azonosítójuk, és minden eszköznek csak egy ilyen azonosítója van. A csatlakozás során az eszköz egyúttal információkat is kap a piconetben rendelkezésre álló szolgáltatásokról, valamint a PNC is tájékozódik az új eszköz képességeiről. Ha az új eszköz csatlakozott a piconethez, akkor a PNC információt küld róla a piconet többi elemének, és az új eszközről szóló információt tesz a vezérkeretbe. Ez lehetővé teszi, hogy a többi eszköz informálva legyen az új kapcsolódásáról, valamint, hogy az új eszközt a régiek tájékoztatni tudják a piconet elemeiről. Ha egy eszköz el kívánja hagyni a piconetet, vagy a PNC el kívánja azt távolítani, akkor egy kiválási eljárás zajlik le. A piconet megszüntetése. Ha a PNC el kívánja hagyni a piconetet és nincs más olyan eszköz a piconetben, amely a PNC feladatkört el tudná látni, akkor a vezérkeret-be a PNC leállásáról sugároz információt. Ha a PNC hirtelen, hívásátadás nélkül hagyja el a hálózatot, akkor a piconet működése leáll, és egy arra alkalmas eszköz a régi piconetből egy új piconetet épít fel a korábban leírt módon. Az alárendelt (gyermek vagy szomszéd) piconeteknek lehetőségük van a leállás után tovább működni. 4.1.3

HOZZÁFÉRÉS A CSATORNÁHOZ

A 802.15.3 hálózatokban az időzítés, és így az adatátvitel alapjául is a főkeret (superframe) szolgál. A főkeret három fő részre bontható (91. ábra): − A vezérkeret (beacon) időzítésre, a csatornaidő-kiosztás megadására és hálózatfenntartási információk közlésére használatos. A vezérkeretet a PNC építi fel és küldi a piconetben résztvevő minden egyes eszköznek. − A versengéses hozzáférési periódusban (Contention Access Period - CAP) parancsok kiadása, illetve az aszinkron adatcsere végrehajtása lehetséges. Ebben a részben történik az egyes eszközök csatorna-hozzáférésének vezérlése. − A versengés nélküli periódusban (Contention Free Period - CFP) pedig a csatornaidő adatátviteli célú kiosztása (Channel Time Allocation - CTA) történik meg. Az adatot

BZAKA

AmI Project

129.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata átvinni szándékozó eszközök a PNC-től erre időréseket kapnak, meghatározott kezdési és befejezési időpontokkal. A versengés nélküli periódusban kétféle időrés szerepelhet. A menedzsment időrésekben (Management Time Slots - MTS, vagy Management Channel Time Allocations - MCTA) az eszközök a hálózat fenntartásával kapcsolatos információkat cserélhetnek a PNC-vel. A garantált időrések (Guaranteed Time Slots - GTS) pedig izokrón adatfolyamok (amelyek adatcsomagjai szakaszosan, szabályos időközönként érkeznek) és aszinkron adatkapcsolatok felépítésére használhatók fel.

91. ábra: A 802.15.3 főkeretek szerkezete

A vezérkeret, mint azt említettük, szinkronizációs célokat is ellát: minden, a piconetben részt vevő eszköz a vezérkeret elejéhez állítja be a saját óráját. Ezen kívül a vezérkeret értesíti az eszközöket a piconet működésével kapcsolatos fontos történésekről A versengéses hozzáférési periódusok hosszát a PNC határozza meg, és a vezérkeretben közli az eszközökkel. A versengéses hozzáférési periódusok közeghozzáférése az ütközést elkerülő vivőérzékeléses többszörös hozzáférési protokoll (Carrier Sense Multiple Access with Collision Avoidance - CSMA/CA) protokoll szerint folyik. Ezekben a periódusokban kérhetik az eszközök a piconethez való csatlakozást és az arról történő leválást is. A versengés nélküli periódusokban egy időosztásos többszörös hozzáférési protokoll (Time Division Multiple Access - TDMA) használatával az eszközök meghatározott időréseket kapnak. Az, hogy az időréseknek meghatározott kezdeti időponttal és időtartammal rendelkeznek, hatékony energiagazdálkodásra, és QoS módszerek alkalmazására ad lehetőséget. Egy adott főkeretre vonatkozó csatornaidő-kiosztás mindig a főkeret elején lévő vezérkeretben kerül kihirdetésre. Ha egy eszköz csatornaidőt kap, akkor biztosítva van, hogy annak időtartama alatt a csatornát más eszköz nem fogja használni. A kapott időrés felhasználásának módjáról az eszköz, elvégzendő feladatait számbavéve maga dönt. Ha egy időrésben zajló adatkommunikáció forrásaként és céljaként is ugyanaz az eszköz van feltüntetve, akkor ezt az időrést magán időrésnek hívjuk. (private CTA). Ez nem piconetbeli adatforgalomra, hanem alárendelt (gyermek vagy szomszéd) piconetek működésének folytatására használatos.

130.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata A PNC képes megváltoztatni a főkereten belül a rendszeres időközönként kiosztott csatornaidő helyét. Azonban, ha egy eszköz lemarad egy vezérkeretről, akkor nem tudja kihasználni a neki szánt csatornaidőt. Ennek elkerülésére az eszközök egy különleges fajtájú csatornaidőt is igényelhetnek, amelyet pszeudo-statikus csatornaidő-kiosztásnak hívunk. A pszeudo-statikusan kiosztott időrések helye az egymás után következő főkeretekben megegyezik. Az ilyen csatornaidőt kapott eszközök (bizonyos számú vezérkeretig) akár a vezérkeretről lemaradva is szabadon használhatják az időrésüket. Amennyiben a PNC ezen időréseket újra fel kívánja használni, akkor előtte meghatározott ideig várnia kell, hogy biztosan elkerülje az adatok ütközését. Ugyancsak figyelemmel kell lennie arra, hogy a más eszközöknek kiosztott időrések ne legyenek átfedésben a pszeudo-statikus időréssel. A nem pszeudo-statikusan kiosztott csatornaidőt, amely helye tehát az egymás után következő főkeretekben különbözik, dinamikusan kiosztott csatornaidőnek hívjuk. 4.1.4

A PICONET IRÁNYÍTÁSÁNAK ÁTADÁSA. ALÁRENDELT PICONETEK

Ebben a fejezetben további olyan működéseket vizsgálunk, amelyek, a fentebb megismert alapműködésekkel együtt, fontos szerepet játszanak a piconet fenntartásában. Gyermek piconet létrehozása. A gyermek piconet egy, már létrejött („szülő”) piconet alá rendelve formálható. Erre például akkor van szükség, ha az eredeti piconet hatósugarát szeretnénk kiterjeszteni. Egy piconetben ugyanabban az időben több gyermek piconet is létezhet. A gyermek piconet működése a szülő piconet által meghatározott időrésekben zajlik (lásd 92. ábra). Ettől eltekintve a gyermek piconet a szülő piconettől függetlenül viselkedik, egyéb ügyeiben a szülő piconet nem érintett. A gyermek piconet PNC-je a szülő piconet része. A szabvány nem támogatja a két piconetben lévő eszközök közvetlen adatátvitelét. A kommunikáció a gyermek piconet PNC-jén keresztül valósulhat meg. Ha a piconet egy eszköze gyermek piconetet kíván kialakítani, akkor ehhez csatornaidőt kér az éppen aktuális PNC-től. (Az időrés típusát -pszeudo-statikus- később ismertetjük). A gyermek piconet PNC-je ebben az időrésben használhatja a gyermek piconetet vezérlő, saját maga által felépített vezérkeretet.

92. ábra: A szülő és a gyermek piconetek viszonya

Szomszéd piconet létrehozása. Akkor alkalmazzák, ha több piconet között kell megosztani a csatornát, mert már nincs több szabad csatorna. Hasonlóan a gyermek piconethez, a szomszéd piconetből is lehet több, az időzítéstől eltekintve a szülő piconettől függetlenül működik. Azonban a szomszéd piconet PNC-je nem része a szülő piconetnek, így egyik oda tartozó eszközzel sem tud adatkapcsolatot létesíteni.

BZAKA

AmI Project

131.


ENERGIAGAZDÁLKODÁS

A 802.15.3 szabvány fontos célja, hogy lehetővé tegye a hosszú üzemelési időt a telepről működő eszközök számára. Ennek egy módja, ha az eszközök a főkeret időtartamához viszonyítva hosszabb ideig lecsökkentik teljesítményüket, vagy teljesen kikapcsolnak. A piconet eszközei ezért négyféle állapotban lehetnek. Ezek az aktív, a piconet-szinkronizált energiatakarékos (Piconet-Synchronized Power Saving - PSPS), a szinkron energiatakarékos (Synchronous Power Saving - SPS), és a hibernált (Hibernate) módok. A piconet-szinkronizált energiatakarékos módot felvenni kívánó eszközök jelzik szándékukat a PNC felé, amely regisztrálja ezt. A PNC meghatározott időközönként ébresztő vezérkereteket küld, amelyeket a készenléti állapotban lévő eszközöknek figyelniük kell. A szinkron energiatakarékos üzemmódban üzemellő eszközök csak meghatározott időközönként kerülnek aktív állapotba, és csak ekkor végeznek adatcserét. A hibernált mód pedig tetszőleges idejű kikapcsolást enged meg az ezt választó eszköznek. Ebben az esetben az eszközök nem figyelik a vezérkereteket, mindössze annyit kommunikálnak a PNC-vel, amennyi a piconetben maradásához szükséges. A piconet eszközei képesek arra, hogy adóteljesítményüket változtassák. Ez az eljárás két célt szolgálhat. Egyfelől, az interferencia elkerülése érdekében lehetséges, hogy a PNC maximumra állítsa az adóteljesítményt a vezérkeret és a versengéses hozzáférési periódus idejére. Másfelől, az energiatakarékosság szolgálatában, az eszközök a kapcsolat minőségétől függően növelhetik, vagy csökkenthetik az adóteljesítményüket, miközben egymással kommunikálnak. 4.1.6

A FIZIKAI RÉTEG FŐ JELLEMZŐI

A WPAN-ok fizikai rétege a 2.4 és 2.4835 GHz közötti ipari, tudományos és orvosi célú frekvenciasávban üzemel, amelynek használata engedélyhez nem kötött. A szabvány egy 4 és egy 3 csatornás csatorna-kiosztási tervet határoz meg. (Utóbbit a 802.11b hálózatok melletti üzemelés megkönnyítésére.) A támogatott adatsebességek száma 5, ezek 11-től 55 Mbps-ig terjednek [60]. Mivel a közeget más felhasználókkal és rendszerekkel is meg kell osztani, a 802.15.3 hálózatok számos olyan technikát alkalmaznak, amely minimalizálja az ilyen körülmények okozta zavarokat. Ezek között említendők a fentebb már bemutatott módszerek a csatorna pásztázása, állapotának lekérdezése, a dinamikus csatornaválasztás, a frekvenciaátlapolódást minimalizáló csatornakiosztás, az adóteljesítmény változtatására való képesség, valamint a szomszéd piconetek kialakításának lehetősége.

132.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata Fontosnak tartjuk egy pár szót ejteni az ultraszélessávú technológiáról is. Az UWB technológia a hagyományos adatátviteli eljárásokkal (rádió- és tévé-műsorszórás, Bluetooth, Wireless LAN stb.) ellentétben nem csupán egy szűk, koncentrált sávot, hanem egy rendkívül széles frekvenciatartományt használ. Ez lehetővé teszi nagyon alacsony energiájú és rövid impulzusok alkalmazását, és enyhíti az interferenciákkal és visszaverődésekkel járó problémákat is. Jól jellemzi a technológiát, hogy az illetékes hatóságok az UWB-eszközök maximális sugárzási teljesítményét úgy állapították meg, hogy az hozzávetőleg egyenlő a háztartásokban használatos elektronikai eszközök megengedett elektromágneses kisugárzásával. Bár az UWB technológiát eredetileg a hagyományos FM-műsorszórás leváltására szánták, különböző informatikai vállalkozások hamar felismerték benne a vezeték nélküli számítógépes adatátvitel gyorsabbá tételének lehetőségét. Az IEEE Wireless Personal Area Networks (WPAN, 802.15) munkacsoportjában olyan szabvány van születőben, amely az eredetileg használni kívánt spektrumot kisebb egységekre osztja fel – ezt a kis kiterjedésű hálózatokhoz szánt megoldást Wireless USB-nek is nevezik. 4.2

A 802.15.4 SZABVÁNY

4.2.1

BEVEZETÉS

A 802.15.4-es szabvány vezetéknélküli eszközök személyi hálózatba (WPAN) való kapcsolódására nyújt megoldást. A standard CSMA alapú csatorna hozzáférést használ, ütközés elkerülő technológiával, és lehetővé teszi csillag illetve peer-to-peer hálózati topológiák létrejöttét. A csatorna hozzáférése versengés alapú, viszont a csillag topológiák esetében opcionálisan lehetővé válik vezérkeretek létrehozására. Ebben az esetben az időrések a PAN koordinátor (mester) által lesznek kiosztva az idő-kritikus forgalmat bonyolító eszközök között. A szabvány két fajta eszköztípust engedélyez, maximális illetve csökkentett képességű csomópontok csatlakozhatnak a WPAN-ra. A standard két fizikai réteget specifikál: egy a 868 MHz/915 MHz sávban működő DSSS (Direct Sequence Spread Spectrum) alapú és egy a 2.4 GHz DSSS alapú fizikai réteget. Az utóbbi 250 Kbps névleges sávszélességgel rendelkezik, míg az előbbi 20-40 Kbps névleges sávszélességre képes. A használt fizikai réteg a különböző országok korláltozásainak függvényében lesz kiválasztva. Mint láthatjuk a 802.15.4 egy alacsony sebességű WPAN technológiát specifikál. Egy ilyen rádiós technológia fő alkalmazási területe alacsony költségű vezetéknélküli hálózatok kiépítésénél lenne, ahol alacsony energiaigényű és kis sávszélességű igényeket kell kielégíteni. A 802.15.4 WPAN technológia főbb célkitűzései: könnyű üzembe helyezhetőség, biztonságos adatátvitel, kis hatótávolság, igen alacsony költségek, energiatakarékosság illetve egyszerű protokolláris architektúra elérése volt. A 802.15.4 rendszer néhány karakterisztikája: − nominális 250 Kbps illetve 20-40 Kbps − 16 csatorna a 2.4 GHz sávban, 10 illetve 1 csatorna a 915 MHz / 868 MHz sávban − csillag illetve peer-to-peer topológiák − 254 hálózati eszköz 8 bites címmel, illetve ennél több eszköz 16- illetve 64 bites címmel − garantált időrések allokációja − CSMA-CA csatornahozzáférés BZAKA

AmI Project

133.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata − biztonságos adatátvitel támogatása − alacsony energia igény és energia monitorizálási lehetőség − kapcsolat minőség monitorizálási lehetőség 4.2.2

802.15.4 HÁLÓZATI TOPOLÓGIÁK

A használni kívánt alkalmazások függvényében a 802.15.4 WPAN eszközei csillag illetve peer-to-peer topológiába rendeződve működhetnek. A csillag topológiában a kommunikáció az eszközök és egy központi egység, a mester (PAN koordinátor), között zajlik. Ez a topológia olyan szolgáltatásoknál megfelelő ahol egy eszköz a többi eszköznek bizonyos szolgáltatásokat kell nyújtson. Nem feltétlenül a mester kell a szolgáltató legyen, a szolga eszközök között is megvalósítható kommunikáció. Ebben az esetben a szolgák közti forgalmat a mester saját magán keresztül fogja továbbítani. A csillag topológiára egy példát a 93. ábra mutat. Az összes eszköznek mindkét típusú hálózatban egyedi 64 bites címmel kell rendelkeznie. A kommunikáció során az eszköz használhatja ezt a címét, vagy a kezdeti asszociáció során lecserélheti egy rövidebb címre, amelyet a mester fog számára kiosztani.

93. ábra: Csillag topológia a 802.15.4 hálózatokban

A csillag topológiát használó rendszerek lehetnek otthoni automatizációs alkalmazások, PC perifériák, játékok vagy egészségügyi alkalmazások. A peer-to-peer topológia (94. ábra) is rendelkezik egy PAN koordinátorral, viszont a csillag topológiával ellentétben lehetővé teszi, hogy az egymás rádiós hatósugarában lévő eszközök egymással direktbe kommunikáljanak. Ezáltal a peer-to-peer topológia jóval komplexebb hálózatok felépítését teszi lehetővé. A 802.15.4 ebben az üzemmódban alkalmazhatóvá válik az ipari vezérlés és figyelés, vezetéknélküli szenzor hálózatok, biztonságtechnika, stb. területén. A peer-to-peer hálózat lehet ad hoc, önrendező és öngyógyító. A belőle felépülő ad hoc hálózat kiterjedhet több rádió-ugráson keresztül is, ezáltal lehetővé téve, hogy az egymást direktben nem látó csomópontok is kommunikálhassanak. A többugrásos funkciókat megvalósító protokollokat (például útvonalválasztás, felderítés) ellenben a specifikáció nem tartalmazza. Minden egyes független PAN egy azonosítót fog választani magának. Ez az azonosító lehetővé teszi a rövid eszközcímek használatát és a PAN-ok közti kommunikációt. 134.

AmI Project

BZAKA


94. ábra: Peer-to-peer topológia a 802.15.4 hálózatokban

4.2.2.1 Csillag topológiájú hálózat kiépülése Egy maximális képességű csomópont hozhatja létre a csillag PAN topológiát, ezáltal a hálózat mesterévé válva. Az illető csillag hálózat a többi létező csillag hálózattól függetlenül fog működni, mivel minden egyes hálózatban egyedi PAN azonosító fog használatba kerülni. A többi eszköz csak a PAN azonosító kiválasztása után csatlakoztatható a PAN-hoz.

4.2.2.2 Peer-to-peer topológiájú hálózat kiépülése A peer-to-peer PAN-ban minden eszköz direktben kommunikálhat a rádió zónájában lévő többi eszközzel. Egy eszköz szintén ki lesz kijelölve, mint a PAN mestere, ez a döntés különböző szempontok szerint valósulhat meg. A standard lehetővé teszi a peer-to-peer topológia továbbfejlődését klaszter-fa topológiává (95. ábra). Ennek a hálózatnak, ellentétben az előbbi topológiákkal, minden egyes tagjának maximális képességű csomópontnak kell lennie. A fa struktúra elemei koordinátor szerepet vállalhatnak, szerepük szinkronizálni a hálózat eszközeit egymással. A koordinátorok közül egynek a szerepe az egész hálózat koordinációja lesz.

95. ábra: Klaszter-fa topológia a 802.15.4 hálózatokban

BZAKA

AmI Project

135.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata A PAN mestere fogja az első klasztert létrehozni, ezáltal a klaszter mesterévé válva. Ennek a klaszternek az azonosítója nulla lesz, és a mester egy nem használt PAN azonosítóval fogja üzenetszórás által hirdetni. A szomszédos eszközök ezt az üzenetet megkapván kérhetik a csatlakozásukat az illető klaszterhez. Ha a mester engedélyezi az eszköz kérelmét, akkor az gyerek tagként csatlakozik a klaszterbe és az illető klasztert már ő is hirdetni fogja. Ezeket a hirdetéseket vevő távolabbi eszközök is csatlakozhatnak az illető klaszterbe a hirdető gyerek tagon keresztül. Ha egy eszköz tagságát a mester nem engedélyezi, akkor más klasztert kell, hogy keressen, amelyhez csatlakozhat. Az így létrejövő több-ugrásos hálózat legfőbb előnye, hogy a lefedett terület jelentősen kiterjeszthető a csillag illetve egyszerű peer-to-peer topológiákkal szemben, ezáltal lehetővé téve a korlátozott rádiós hatótávolság áthidalását. Hátránya az üzenetek késleltetett terjesztése és a megnövekedett szoftver architekturális (protokoll és algoritmus) komplexitás. 4.2.3

A 802.15.4 ARCHITEKTÚRÁJA

A 802.15.4 protokolláris felépítése követi az ISO által definiált OSI hét réteges protokoll modellt. Akárcsak a többi IEEE 802 standardoknál egy 802.15.4 eszköz architektúrája tartalmaz egy fizikai réteget (PHY), amely a rádiófrekvenciás átjátszót (RF transceiver) és a hozzá tartozó vezérlő mechanizmusokat tartalmazza, továbbá egy médium-hozzáférési alréteget (MAC) amely biztosítja a csatorna elérését a különféle átviteli módok számára. A protokoll verem felépítését a 96. ábra mutatja.

96. ábra: Egy 802.15.4 eszköz belső architektúrája

Az ábrán látható felsőbb protokoll rétegek specifikációja az applikációk megvalósítóira van bízva. A hagyományos vezetékes hálózatokban a hálózati réteg feladata a hálózati topológia felépítése és fenntartása, akárcsak a címzési és szolgáltatás hozzárendelési feladatok ellátása (pl.: címzés, útvonalválasztás, és adatvédelem). Hasonló szolgáltatásokat kell megvalósítani a vezetéknélküli hálózatoknál is, viszont e szolgáltatások megvalósítása ezeknél jóval több nehézségbe ütközik a speciális körülményeknek (például limitált energia) betudhatóan. A standardra épülő hálózati rétegektől elvárt, hogy önállóan szerveződő és önfenntartó tulajdonságokkal rendelkezzenek. A fennebb bemutatott hálózat topológiákat megvalósító algoritmusok is a hálózati rétegben lesznek implementálva a különböző igényeknek megfelelően. Így például nem valószínű, hogy egy PC perifériának tervezett eszköz képes lesz peer-to-peer vagy klaszter-fa architektúrában részt venni. Ezeknek a felsőbb rétegeknek a specifikációja nem a 802.15.4 standard feladata.

136.

AmI Project

BZAKA


4.2.3.1 A 802.15.4 fizikai rétege Mint már korábban említettük az IEEE 802.15.4 szabványa két fizikai (PHY) réteget specifikál, amelyek feladata (a MAC réteggel együtt) széleskörű vezetéknélküli alkalmazások lehetővé tétele. A DSSS technológia alkalmazása ugyanakkor lehetővé teszi alacsony költségű és alacsony energia igényű digitális áramkörök használatát. A 2.4 GHz-es változat az ISM sávban működik, ami gyakorlatilag nemzetközi szinten használt, ennek következtében nagyobb elterjedésre és így alacsonyabb gyártási költségekre számíthatunk. Ugyanakkor azt is figyelembe kell venni, hogy az ISM sáv már számos más vezetéknélküli technológia által is használt, mint például a Bluetooth és az IEEE 802.11 (WaveLAN), ezért ez a frekvencia sáv igencsak szennyezett. A 802.15.4 által támogatott másik két sávtartomány a 868 illetve a 915 MHz-es, amelyből a 868 MHz Európában, a 915 MHz pedig az Egyesült Államokban van engedélyezve. Ezeknek a frekvencia sávoknak a használata így lecsökkentheti az amúgy is nagy ISM sávbeli interferencia problémákat, illetve a terjedési tulajdonságaikból (kisebb terjedési veszteség) is előnyt kovácsolhatnak. A 868/915 MHz sávszélességű eszközök így például nagyobb lefedettségű és kevesebb csomópontú hálózatok építésére alkalmasak. A 2.4 GHz-es PHY réteg 250 Kbps nominális sávszélességet garantál, míg a 868/915 MHz-en 20 illetve 40 Kbps nominális sávszélesség garantált. A 2.4 GHz nagyobb sávszélessége nagy részben a magasabb rendű modulációnak köszönhető, ahol is minden egyes szimbólum több bitet reprezentál. A fizikai réteg a következő feladatok megvalósításáért felelős: − a rádiós átjátszó aktiválása és de-aktiválása − energia monitorizálása az illető csatornán − csomagok vételezésénél a rádiós kapcsolat minőségének a jelzése − üres csatorna felbecsülése a CSMA-CA-hoz − csatorna frekvencia kiválasztása − adatok küldése és vétele Csatorna frekvenciák a 802.15.4 rendszerben A standard összesen 27 csatornát definiál amint a 97. ábra is mutatja. A 868/915 MHz-es PHY egyetlen csatornát támogat a 868.0 és 868.6 MHz sávban és 10 csatornát a 902.0 és 928.0 MHz sávban. A csatornák geográfiailag különböző támogatottsága miatt nem valószínű, hogy egyetlen hálózat mind a 11 csatornát felhasználná, de mivel frekvenciában elég közel állnak egymáshoz így az eszközök hardvere nagyon hasonló lesz, ezáltal csökkentve a gyártási költségeket. A 2.4 GHz-es PHY 16 csatornát támogat a 2.4 és 2.4835 GHz sávban. Az ISM sáv nemzetközileg engedélyezett, ezért a 2.4 GHz-en működő eszközök gyártása már eleve olcsóbb lesz.

BZAKA

AmI Project

137.


97. ábra: A 802.15.4 csatornáinak frekvencia struktúrája

Mivel az otthoni hálózat valószínűleg többfajta vezetéknélküli rendszert is fog tartalmazni, amelyek ugyanazt a frekvencia sávot használják, ezért fontos szempont lesz a csatorna újraválasztási képesség. Ennek megfelelően a 802.15.4 standard lehetővé teszi a dinamikus csatornaváltást, viszont nem ad rá konkrét megoldást a hálózati rétegre hárítván a feladatot. A MAC réteg egy csatorna pásztázási (scan) funkciót definiál, amely a támogatott csatornákon végighaladva egy vezérkeret (beacon) után kutat. A PHY réteg ezzel kapcsolatban számos alacsony szintű funkciót támogat, mint például a vevő energia detektálása, kapcsolat minőség felmérése illetve csatornaváltás. Ezek a funkciók használhatóak a hálózat által, hogy a kezdeti működési csatornáját kiválassza, és szükség esetén egy másik csatornára váltson. Rádiós hatósugár és interferencia Az IEEE 802.15.4 szabványa a 2.4 GHZ-es PHY-re jelenleg -85 dBm-es vételi érzékenységet határoz meg, a 868/915 MHz-es PHY-re pedig -92 dBm-et. Ezeknek az értékeknek az elérése alacsony költségvetésű hardver implementációkkal is lehetséges lesz. Mindkét esetben a jobb minőségű alkatrészek kb. 10 dB-el fogják a specifikációban leírtakat túlszárnyalni. Természetesen az elérhető rádiós lefedettség a vevő érzékenységének és az adási teljesítménynek a függvénye. A standard kimondja, hogy minden egyes eszköz legalább 1 mW adási teljesítménnyel kell rendelkezzen, viszont a betöltendő funkciójának függvényében a tényleges adási teljesítmény lehet alacsonyabb vagy magasabb. A tipikus 1 mW-os teljesítménnyel rendelkező eszközöktől 10 – 20 méteres rádiós lefedettséget várhatunk el. Ez által egy megfelelően érzékeny és moderáltan növelt teljesítményű 802.15.4 hálózat a csillag topológia használatával képes lesz otthoni alkalmazásban a teljes lefedettség biztosítására. Azok az alkalmazások, amelyek nagyobb csomag késleltetést engedélyeznek, ad hoc topológiában képesek lesznek nagyobb területek lefedésére, a standardban megadott teljesítmény értékek növelése nélkül. A 2.4 GHZ-en működő eszközök inkább ki lesznek téve az interferenciának, mivel ezt a frekvencia tartományt használják a Bluetooth illetve a 802.11b által specifikált eszközök is. Elvileg ez az interferencia a 802.15.4 alkalmazásai által elviselhető mértékűnek tűnik, ugyanis ezek az alkalmazások aránylag alacsony QoS igényeket támasztanak, nem igényelnek valós idejű átvitelt és így többszöri újraküldéssel is próbálkozhatnak. Ezzel ellentétben az IEEE 802.15.4 szabványának egy elsődleges szempontja az energiagazdálkodás, amely hosszú élettartalmú eszközökhöz vezet. Mivel a 802.15.4 eszközök a működési idejük 99 %-ban alvó üzemmódban lesznek és működés közben is csak alacsony teljesítményen, és kis hatósugárral sugároznak, nem fognak jelentős zavaró tényezőt jelenteni a más típusú 2.4 GHz-en működő rendszerek számára. 138.

AmI Project

BZAKA


4.2.3.2 A 802.15.4 adatkapcsolati rétege Az IEEE 802-es szabványai az adatkapcsolati réteget két alrétegre, a médium-hozzáférési alrétegre (Media Access Control - MAC) és a logikai-kapcsolat vezérlő alrétegre (Logical Link Control - LLC) osztják. Az LLC a 802.2 szabványban van standardizálva és a 802 szabványok, mint például a 802.3, 802.11, 802.15.1, stb., által közösen használt. A MAC alréteg a PHY réteghez és a hardverhez közelebb áll, ezért a fizikai réteg implementációjától függően változhat. A 802.15.4 MAC alrétege egy IEEE 802.2 I típusú LLC-nek nyújt szolgáltatásokat egy szolgáltatás-specifikus konvergenciai alrétegen (SSCS) keresztül. Ugyanakkor lehetőség van arra is, hogy az SSCS-t kikerülve egy megfelelő LLC direkt módon hozzáférjen a MAC szolgáltatásaihoz. Az SSCS feladata a különböző LLC-k közti kompatibilitás biztosítása és lehetővé teszi, hogy a MAC egy egységes menedzsment platformról legyen elérhető. Ez a modell lehetővé teszi ugyanakkor, hogy a MAC olyan funkciókat is nyújtson, amelyek nincsenek a 802.2-ben specifikálva, ezáltal lehetővé téve a fentebb leírt komplex topológiájú hálózatok létrehozását. A MAC funkciói asszociáció és de-asszociáció, nyugtázott csomagok elküldése, csatorna hozzáférési mechanizmus, csomagok hiba-ellenőrzése, garantált időrések menedzsmentje, vezérkeretek menedzsmentje. Ezekről a funkciókról a későbbiekben részletesebben írunk. A MAC alréteg két szolgáltatást nyújt a felsőbb rétegek felé, amelyek két SAP-on keresztül érhetőek el. A MAC adat szolgáltatása az MCPS-SAP-on keresztül érhető el, a menedzsment szolgáltatásai pedig az MLME-SAP-on keresztül. Ez a kétfajta szolgáltatás egy interfészt biztosít az SSCS (vagy egy másik LLC) illetve a PHY rétegek között. A MAC menedzsment szolgáltatása csak 26 primitívet tartalmaz. Ez a 802.15.1 (Bluetooth) 131 primitívjéhez (!) és 32 eseményéhez képest igen kevés, így egy alacsony komplexitású 802.15.4 MAC megvalósítást eredményez. Ezáltal lehetővé válik az alacsony költségvetésű és igényű (lowend) applikációk megvalósítása, még alacsonyabb költségekkel, mint amelyek a Bluetooth esetében voltak. A főkeretek (superframe) stuktúrája Bizonyos alkalmazásoknak szüksége lehet dedikált sávszélességre, hogy alacsony késleltetéseket garantálhassanak. Ezeknek az igényeknek a figyelembe vételével a 802.15.4-es szabványt felruházták az opcionális főkeret (superframe) móddal. A vezérkeretekben egy dedikált hálózat koordinátor (mester avagy PNC) úgynevezett vezérkereteket (beacon) küld egy előre meghatározott időintervallum szerint. Ez az intervallum 15 ms-tól egészen 245 másodpercig terjedhet. Két vezérkeret közti idő 16 egyenlő időrésre van felosztva, függetlenül a főkeret hosszától. Egy eszköz bármilyen időpillanatban küldhet egy időrésen belül, viszont be kell fejezze a kommunikációt a következő vezérkeret érkezéséig. A csatorna hozzáférés az időrésekben versengéses alapú, ugyanakkor a PNC kirendelhet időréseket egyetlen eszköznek is. A garantált sávszélesség illetve alacsony késleltetés igényű eszközök így a dedikált időrések által megfelelő QoS minőséget kaphatnak. Ezeket a dedikált időréseket garantált időréseknek nevezzük (Guaranteed Time Slots – GTS) és a versengés nélküli periódusban vannak kiosztva (lásd 98. ábra) amely a versengéses periódust követi.

BZAKA

AmI Project

139.


98. ábra: A 802.15.4 főkeret struktúrája garantált időrésekkel

A versengés nélküli periódus hossza változó lehet az eszközök igényeitől függően. Amikor a főkeretben GTS-ek vannak kiosztva akkor minden eszköz be kell, hogy fejezze a kommunikációt a versengéses periódusban mielőtt a versengés nélküli periódus megkezdődne. Az eszközöknek a versengés nélküli periódus kezdete és a hossza a vezérkeretben lesz a tudtára adva a PNC által. A 802.15.4 tehát a hálózati konfigurációtól függően két fajta csatorna hozzáférési mechanizmust támogat. A vezérkeretes módban, főkeretes, időrés alapú CSMA-CA mechanizmus van használatban. A vezérkeret-nélküli módban ugyanakkor időrés nélküli vagy standard CSMA-CA van használatban. Ez a következőképpen működik. Amikor egy eszköz egy vezérkeret-nélküli hálózatban szeretne adatot küldeni először leellenőrzi, hogy egy másik eszköz éppen nem használja-e ugyanazt a csatornát. Ha a csatorna használatban van, akkor az eszköz egy véletlenszerűen választott idő intervallumra visszafogja magát, vagy ha már többször is próbálkozott, akkor kudarcot jelent. A véletlen várakozás letelte után újra próbálkozik a csatorna megszerzésére. A keretek nyugtázására nem CSMA mechanizmust használnak mivel ezek rögtön az előzőleg küldött csomagok után következnek, így a csatorna még a nyugtázásra váró eszközé. A vezérkeretes módban minden eszköz, amely a versengéses periódusban akar küldeni a következő időrés kezdetéig kell, hogy várakozzon. A következő időrésben megállapítja, hogy valaki használja-e az illető időrést. Ha egy másik eszköz már küldésben van, akkor az illető eszköz egy véletlen számú időrésnyire visszafogja a küldési szándékát, vagy feladja a további próbálkozásait. A nyugtázások itt sem CSMA alapon vannak visszaküldve. 4.3

IEEE 802.16

Az IEEE 802.16 rendszert a Pont-Multipont alkalmazásokhoz fejlesztették ki. A rendszer teljesíteni hivatott ez egyre növekvő sávszélesség igényeket mind feltöltési, mind letöltési irányban. A hozzáférés és sávszélesség-allokációs algoritmusoknak alkalmazkodni kell a csatornánként akár több száz felhasználói terminál jelenlétéhez, az olyan végpontokkal egyetemben, amelyeken keresztül egyszerre több felhasználó csatlakozik. A felhasználók által igényelt szolgáltatások rendkívül változatosak, lehetnek akár a hagyományos időosztásos többszörös hozzáféréssel (TDM) működő hang és adatforgalom, vagy a csomag orientált VoIP szolgáltatások. Ahhoz, hogy ilyen változatos szolgáltatásokra legyen képes, a 802.16nak tudnia kell alkalmazkodni a folyamatos és a börsztös, csomagszerű átvitelhez is.

140.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata Eredetileg az IEEE 802.16 rendszert 2001-2002-ben kezdték el fejleszteni. Ekkor még a 1066GHz sávokba szánt, szórt spektrumú, széles sávú összeköttetést nyújtó WMAN közegszabványokra. Ellenben a gyártók számára ez a túl magas frekvenciasáv nem volt vonzó. Ezért alakult egy a 2-10 GHz-es sávokra koncentráló 802.16a másik munkacsoport. A 10-66 GHz-es sávhoz készült fizikai réteg tervezésekor figyelembe vették, hogy az ilyen vivőfrekvencián dolgozó eszközöknél az optikai rálátás adott. Ilyen feltételek mellet könnyű volt eldönteni, hogy egy vivőfrekvenciás, direktmodulált rendszert terveznek, ezt a rádió interfészt, WirelessMAN-SC''-nek nevezték el. A rendszer pont-multipont jellege miatt TDM átvitellel működik, ahol az egyes kliensekhez egy-egy időrésen keresztül jut el az adat. A feltöltés irányú adatforgalom időosztásos többszörös hozzáféréssel (TDMA) működik. Ezzel szemben a 2-11 GHz-es sávban a 802.16 eszközöket úgy tervezték, hogy az állomásoknak nem kell optikai rálátásban lenni egymáshoz képest. Hol alkalmazható a 802.16? A távoli telephelyek nagy sebességű összekötésére eddig a legjobb megoldásként üvegszálas technológiát ajánlottak a telekommunikációs szolgáltatók. A 802.16-os WMAN hálózatok ezen a téren hozhatnak áttörést, jelentősen olcsóbb árszinten. Ráadásul a rádiókommunikációban elterjedt összes hullámhosszon használhatók, ami lehetővé teszi a túlterhelt sávokból történő menekülést szabadabb sávokba. Az persze korlát, hogy elvi okokból nem készíthető olyan eszköz, amely a teljes, most már 2-66 MHz-es sávot át tudná fogni. A most használni tervezett 3,5 GHz-es, Európában e célra kijelölt sáv egyébként még nem olyan zsúfolt. A 30 kilométeres távolságot akár pont-multipont üzemmódban is ki tudja szolgálni, és talán még irányított antennák sem kellenek hozzá. A nagy távolságú WiFi összeköttetés – alacsonyabb megengedett sugárzási teljesítménye miatt – csak erősen irányított antennákkal megy. Azt sem szabad elfelejteni, hogy már 6 évvel korábban is volt lehetőség nagyobb távolságok rádiós összekötésére használva az akkor már meglévő WiFi eszközöket. Időközben ezek az eszközök is fejlődtek. Akkor legfeljebb 11Mbps sávszélességet lehetett biztosítani. Mostanára ezek a sávszélességek, amelyeket a modern WiFi rendszerek már képesek biztosítani a 108Mbps sebességet. Ez már ugyanúgy tud helyettesíteni egy telephelyek közötti gerinckapcsolatot, mint a még mindig csak készülődő 802.16x WMAN közegszabvány változatok bármelyike, azok jelenleg maximálisnak szánt 110 Mbps sebességéhez viszonyítva. Ezért kérdéses az, hogy vajon a még csak kiforróban új rendszer egyáltalán életben tud-e maradni. Természetesen nagyon sok érv szól a 802.16x rendszerek mellett, amelyből néhányat már említettünk. Az IEEE 802.16a vezeték nélküli kommunikációs szabványtervezet előkészítését a WiMax (Worldwide Interoperability for Microwave Access) Forum nonprofit szervezet vállalta. Több távközlési cég is jelezte részvételi szándékát a szabványtervezet készítésében. A csoport 2003 elején nyilvánosságra hozta, hogy megkezdte a szabványtervezet előzetes kompatibilitási tanulmányai elkészítését a 2 GHz - 11 GHz-es rádiófrekvenciára vonatkozólag. A 802.16a vezeték nélküli szabvány költséghatékony, nagy sávszélességet biztosító pont-pont kapcsolatok, és gerinchálózatok építését teszi majd lehetővé. A WiMax által propagált 802.16a szabványtervezetnek megfelelő eszközökkel akár 48 kmnyi távolság is áthidalható és akár 70 Mbit/s adatátviteli sebesség is elérhető. A 802.16a kapcsolat kiépítése a csoporttag Intel szerint egy T1-es (1,5 Mbit/s) vezetékes kapcsolat költségeinek csupán 50 százalékába kerül. A végfelhasználókhoz így hamarabb eljuthatnak a szélessávú szolgáltatások, mivel a vezetékes megoldásokkal szemben a vezeték nélküli gerinchálózatok kiépítése nem igényel jelentős építési, tervezési, engedélyezési munkálatokat.

BZAKA

AmI Project

141.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata A 802.16a ígéretesnek bizonyult az úgynevezett hotspot hozzáférés területén is. Már több, nyilvános hozzáférési szolgáltatást működtető céggel tárgyalások folynak a 802.16a szabványtervezet támogatásával kapcsolatban. Ilyen például a Cometa Networks, T-Mobile és a Wayport. A cégek lecserélhetik a vezetékes gerinchálózatukat a 802.16a szabványnak megfelelő vezeték nélküli termékekkel és tovább növelhetik szolgáltatási területüket. Mi több, a szélessávú kapcsolatot igénylő felhasználók számára akár 802.16a alapú szolgáltatást is vezethetnek be. Egyetlen hátulütője a 802.16a szabványtervezetnek az, hogy a megfelelő termékek ára egyelőre magas. Míg egy 802.11b szabványnak megfelelő vezeték nélküli adapter ára 40 dollár alá csökken, a 802.16a szabványtervezetnek megfelelő modemek ára még 500-600 dollár körül van. Különböző előrejelzések szerint azonban ezek az árak akár 200 dolláros szintre is csökkenhetnek. Ugyanakkor a 802.16a alapú szolgáltatások biztosításához szükséges bázisállomások ára is igen magas (kb. 7000 dollár). 4.3.1

A 802.16 MAC RÉTEG

A 802.16 MAC magába foglalja azokat a szolgáltatás-specifikus rétegeket is, amelyek a felsőbb protokollokhoz történő illesztést segítik. A MAC réteg fölött a közös MAC funkciókat megvalósító réteg helyezkedik el, amely a MAC kulcsfontosságú funkcióit közvetíti. Szolgáltatás-specifikus alréteg A 802.16 kétféle konvergencia réteget definiál a felsőbb rétegekhez való illesztésre. Az ATM konvergencia alréteget, és a csomagorientált konvergencia alréteget a csomagkapcsolt protokollok illesztésére, mint például Ethernet, IPv4, IPv6, stb. Az alréteg elsődleges feladata, hogy a MAC Service Data Unit-okat (SDU) átalakítsa az adott protokollban használt adatkeretekké, és hogy megőrizze, illetve megteremtse a QoS lehetőségét, így lehetővé téve a fix sávszélesség allokációt. Ezeken az alapvető feladatokon kívül az alréteget olyan összetettebb műveletekre is felkészítették, mint például az adatkeretek Preamble mezejének elnyomását és rekonstrukcióját a hatékonyabb rádiós átvitel érdekében. Common Part Sublayer A 802.16 MAC kapcsolatorientált működésű. Minden átfutó szolgáltatás, beleértve az eredetileg kapcsolatmentes protokollokat is, egy egyedi azonosítóval rendelkező kapcsolathoz van rendelve. Ez módot biztosít a sávszélesség igénylésre, a QoS paraméterek asszociációjára és adaptálására, az adatok megfelelő alréteghez történő továbbítására. A kapcsolatokat egy 16 bites kapcsolatazonosító (Connection Identifier, CID) azonosítja. Minden előfizetői állomás (Subscriber Station, SS) egy 48 bites MAC címmel rendelkezik, de ez főleg hardver vagy berendezés-azonosítóként szolgál, mivel a különböző hálózati műveletek közben a CID az elsődleges azonosító. A hálózatba belépéskor az SS-hez hozzárendelünk három menedzsment-kapcsolatot mind feltöltés, mind letöltés irányba. Ez a három kapcsolat három különböző QoS paramétert tükröz, melyeket különböző menedzsment szinteken használunk. Az első kapcsolat ezek közül rövid, időkritikus MAC és rádió kontrol (Radio Link Control, RLC) adatokat szállít. Az elsődleges menedzsment kapcsolat hosszabb, kevésbé időkritikus üzeneteket szállít, mint például az hitelesítés vagy kapcsolatfelépítés. A másodlagos menedzsment kapcsolat a protokollfüggő üzenetek szállítására szolgál, mint például a DHCP, TFTP, vagy SNMP. Ezen kívül az SS-ekhez hozzárendeljük a saját szállítási kapcsolatukat az egyéb, összevont szolgáltatásokhoz, ezek a kapcsolatok kétirányúak.

142.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata A MAC ezeken kívül fenntart még bizonyos csatornákat, egyéb célokra. Egy kapcsolat szolgál a versenyhelyzetes kezdeti hozzáférésre. Egy másik, a lefele irányuló broadcast csomagok vételére és a sávszélesség-igények pollozására szolgál. Ezen kívül vannak még multicast polling kapcsolatok is, ezeken keresztül lehet egy állomást multicast csoportokhoz rendelni. A MAC PDU formátuma A MAC PDU az adatkeret, amely a bázisállomás és az SS-ek MAC rétege között utazik. A MAC PDU egy fix hosszúságú fejlécből, egy változó hosszúságú hasznosadat-mezőből (Payload) és egy opcionális CRC (ciklikus redundancia-kód) mezőből áll. Két alapvető fejléc formátum van: az általános és a sávszélesség-igénylő fejléc. (Lásd: 99. ábra)

99. ábra: Az általános 802.16 MAC PDU fejléc

A sávszélesség-igénylő MAC PDU-k kivételével a MAC PDU-k tartalmazhatnak MAC menedzsment információkat, vagy konvergencia-alréteg adatokat. Háromféle MAC alfejléc létezik. A Grand Management Subheader-ben egy SS sávszélességet kérhet a bázisállomástól. A Fragmentation Subheader azt mutatja, hogy vannak-e és hol vannak SDU fragmentumok a keretben. A Packing Subheader azt mutatja meg, hogyan van több SDU egymás után illesztve a Payload-ban. A Grant Management és a Fragmentation alfejléceket közvetlenül az általános MAC fejléc után kell elhelyezni, és a Type mezőben jelezni kell meglétüket. A Packing Subheader-t mindegyik MAC SDU elé kell helyezni, és a Type mezőben jelezni kell. 4.4

IEEE 802.20

Az IEEE 802.20 szabvány [63] a legesélyesebb az egyre közeledő 4G számára és várhatóan a már 2004 végére elkészül. A várakozások szerint a 2009-es év végére több mint 30 millió mobil felhasználó fogja világszerte ezt a technológiát használni. A tervek szerint ezen új szabvány lehetővé teszi a 4 Mbps-t adatátviteli sebesség elérését és a licenszköteles 3,5 GHzes frekvenciasávot fogja használni. Ugyanakkor az IEEE 802.20 lehetővé teszi a mobiltelefonok számára, hogy akár 250 km/h-s sebességgel haladó járművekről is zavartalanul működjenek. A standard az interaktív hang és videó alkalmazások használata mellett nagysebességű adatátvitelre is alkalmas lesz. IP centrikus tervezése lehetővé teszi majd VoIP szolgáltatások megvalósítását, továbbá, hogy a népszerű IP alkalmazásokat (pl. online játékok) könnyen át lehessen tenni erre a környezetre.

BZAKA

AmI Project

143.


100. ábra: A 802.20 spektrális hatékonysága más rendszerekéhez képest

A 100. ábra bemutatja a 802.20 tervezett spektrális hatékonyságát a fontosabb mobil technológiákkal összehasonlítva. Látható, hogy például a 3G szabványhoz (Edge) képest sokkal nagyobb lesz a hatékonysága. Ezt az ugrásszerű javulást számos továbbfejlesztett technológia bevetésével, mint például a bázisállomások lecsökkentése, a fizikai rádiós réteg hatékonyabbá tétele (szórt spektrumú technológiák, OFDM, jelfeldolgozás), fogják elérni. A szabvány fontosabb jellemzői: − valós idejű és nem-valós idejű forgalmak transzparens átvitele − állandó kapcsolat a mobil és bázisállomás között − univerzális frekvencia használat − technológiák közti barangolás támogatása (pl. WLAN és 802.20 között) − inter-cella és inter-zóna közti zavarmentes barangolás − QoS támogatása (IPv4 és IPv6 QoS) − gyors erőforrás foglalás mindkét irányú forgalom esetén − felhasználói adatsebességek dinamikus menedzsmentje − a jelenlegi mobil rendszerekkel együttműködésre képes 4.5

DEDICATED SHORT-RANGE COMMUNICATIONS (DSRC)

Az utóbbi években az egyre nagyobb igény a közlekedésben és szállításban is használható kommunikációra hozta létre az amerikai DSRC rendszert [64]. Ennek a vezetéknélküli technológiának a célja, hogy az intelligens szállítási eszközöknek (Intelligent Transportation Systems – ITS) egy olyan rendszert biztosítson, amely lehetővé teszi az erre épülő alkalmazások megvalósítását. A cél jármű-jármű (vechicle-to-vechicle, v2v) illetve járműútszakasz (vechicle-to-roadside, v2r) közti megbízható kommunikáció biztosítása.

144.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata A DSRC jelenleg még fejlesztési stádiumban van, viszont már megtörténtek a kezdeti lépések a gyakorlati megvalósulása fele is. E célból az amerikai használatára az 5.9 GHz-es sávban lefoglaltak egy 75 MHz-es szélességű csatornát. Jelenleg az ASTM E17.51-es kódjelű csoportja foglalkozik a szabvánnyal; céljuk, hogy az IEEE vezetéknélküli WLAN standardot alakítsák át alkalmassá a DSRC igényei számára. Ennek a módosított standardnak a 802.11a Roadside Applications (R/A) nevet adták. A 802.11a R/A három csatorna típust jelöl ki a hozzárendelt csatornakapacitásból. Ezek a v2v csatorna (ch172), kontroll csatorna (ch178) illetve a v2r szerviz-csatorna (ch174, 176, 180, 182). A kontroll csatorna üzenetszórásos-alapú kommunikációra lesz nagy részben felhasználva, ugyanakkor támogatni fogja bizonyos típusú unicast kommunikáció meglétét is. Tehát a 802.11 MAC protokollja elvileg támogatni tudná a v2v és v2r szerviz-csatorna kommunikációját az olyan esetekben, mint pl. jármű flotta illetve infrastruktúra-alapú vezetéknélküli v2r kommunikáció. Azonban, mint ahogy a jelen tanulmányban is bemutatjuk, a 802.11 alapú WLAN hálózatok számos olyan problémával rendelkeznek, amelyek a valós idejű és megbízható kommunikációt megvalósíthatatlanná teszik. A DSRC a jövőben e hiányosságoknak a figyelembe vételével fogja áttervezni a 802.11-et, hogy alkalmassá tegye az ITS megvalósítására.

BZAKA

AmI Project

145.


5. ÁLTALÁNOS ÖSSZEFOGLALÓ ÉS KÖVETKEZTETÉSEK A WLAN térnyerése és a hálózati eszközök árainak nagyarányú csökkenése miatt manapság igen széles körben elterjedtek a kisebb-nagyobb IEEE 802.11b (WiFi) alapú hozzáférési vezetéknélküli hálózatok. Nem ritka az olyan bevásárlóközpont vagy szálloda, amelyben WiFi hálózat elérhető, sőt manapság szinte kötelező ilyen nemű hálózati hozzáférést biztosítani az ügyfelek számára. Jelen tanulmány célja hogy a vezetéknélküli WLAN és Bluetooth technológiák jelentőségére, fontosságára és széleskörű alkalmazhatóságára felhívja a modern műszaki társadalom figyelmét. Elmondható, hogy bármilyen igény vagy alkalmazás jelenik meg a piacon, amely hálózati kapcsolatot vagy kommunikációs összeköttetést igényel, a WLAN típusú vezetéknélküli hálózati összeköttetés, mint alkalmas technológia az esetek nagy részében alkalmazásra kerül. A 1.2.1 fejezetben röviden leírt alkalmazások is feltételeznek kommunikációs közeget. Szimulációs és valós környezetben elvégzett mérésekre támaszkodva több szempontból megvizsgáltuk a WLAN és Bluetooth alkalmasságát a fent említett alkalmazások esetén. Az elért eredmények alapján elmondható, hogy az IEEE 802.11b alapon működő hálózati eszközök további fejlesztésre szorulnak, főleg olyan esetekben, ha dinamikus, nagy mobilitású, stabil vezetéknélküli kommunikációt (pl. autópályán haladó autók összeköttetése) kívánunk megvalósítani. Ugyanakkor a szabvány a jelenlegi részben kiforrottnak mondható műszaki színvonalán is több említett alkalmazás esetén sikerrel alkalmazható. Ilyen például a 1.2.3 és 1.2.4 fejezetekben bemutatott AmI alkalmazás. A tanulmány során bemutattuk azt is, hogy a stabil vezetéknélküli kommunikációs igények esetén tapasztalt hiányosságok nemcsak a szabvány hibáinak tulajdoníthatók, hanem az egyéb, 2.4 GHz-es szabad frekvenciasávot használó eszközök zavaró hatásainak is. A Bluetooth technológia szintén egyre elterjedtebb a rövid és kis sávszélességet átvivő vezetékek kiváltásában, mivel kényelmessé teszi az autós kihangosítók, a headsetek, illetve a modemek használatát. A tanulmányban bemutatott szimulációs és valódi méréses vizsgálatok megmutatták, hogy az autók közötti kommunikációhoz a technológia kevésbé használható, viszont autón, lakáson, gyárüzemen belül használt kis sávszélesség-igényű alkalmazásokban sikerrel alkalmazható. A 802.15 protokollcsaládból bemutattuk a 802.15.4 illetve a 802.15.4 protokollokat. Amint a tanulmányban szemléltettük a fent említett protokollok tervezési szempontjai között kevésbé szerepelt a mobilitás támogatása, ezért az ITS alkalmazásokban nem használhatóak. A 802.15.3 olyan alkalmazásoknak javasolt, ahol igény van a szélessávú, energia-hatékony átvitelre. Ilyen alkalmazások lehetnek az „AmI” elven támogatott gyártósorok, illetve az „AmI” alapú intelligens otthon szcenáriók. A 802.15.4 hasonló elven működik mint a 802.15.3, viszont alacsony sávszélességű és fokozottan az energiatakarékosságot helyezi középpontba. Ezért a szenzor hálózatokban kiválóan alkalmazható. Ilyen típusú hálózatok előfordulhatnak például útszéli szenzor rendszerekben, illetve a fentebb említett két alkalmazás továbbá több más esetben is. Az IEEE 802.16 nagy sávszélességű és nagy távolságú pont-többpont kapcsolatok kiépítésére alkalmas. Ezért ezek a protokollok lehetővé teszik a távoli helyeken működő szenzor hálózatok adatainak egy központi helyre történő begyűjtését.

146.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata A 802.20 technológia a 3G típusú rendszerek kiváltását célozza, különös figyelmet szentelve a nagysebességű mobilitás támogatására. Jelenleg nincs információ arról, hogy mennyire alkalmas az ITS-ben való használatra. Ahhoz, hogy az ITS alkalmazások igényeit kielégítse, rendkívül dinamikus szolgáltatási skálát kell biztosítson, például jármű konvojok esetén dinamikus csoportok létrehozását. A gyakorlati mérések és szimulációs vizsgálatok alapján elmondható, hogy a v2r (jármű-útszél) típusú ITS alkalmazásokban a technológia használható. Az IEEE 802.11a R/A direkt az ITS alkalmazások támogatását célozza meg. Ez IEEE 802.11-re épül, amely sajnos a jelenlegi állapotában kevésbé alkalmas a technológiai feladat megoldására. Az ad hoc WLAN rendszereknek néhány hiányosságát a jelen tanulmány is kimutatta. Végkövetkeztetésként elmondható, hogy még számos megoldandó feladat vár a DSRC rendszer tervezőire, valamint az, hogy az ITS alkalmazások sikere nagymértékben függ a jövőben továbbfejlesztett 802.11a R/A szabvány hatékonyságától.

BZAKA

AmI Project

147.


6. IRODALOM [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61]

http://www.car-to-car.org/ "IEEE Standard 802.11b-1999", September 1999. IEEE 802.15 WPAN™ Task Group 2 (TG2), http://www.ieee802.org/15/pub/TG2.html J. Kardash, "Bluetooth Architecture Overview", Intel Technology Journal Q2, 2000. M. Johnson, "HiperLAN/2 – The Broadband Radio Transmission Technology Operating in the 5 GHz Frequency Band", HiperLAN/2 Global Forum, 1999. "HomeRF Specification Revision 2.01”, Zhengping Zuo: „In-building Wireless LANs”, http://www.cis.ohio-state.edu/~jain/cis788-99/wireless_lans/ Hírközlési Területi Hivatal, "Szélessávú adatátvitel a 2,4 GHz-es frekvenciasávban", Tájékoztató, 2003 június, http://www.hif.hu. http://www.drizzle.com/~aboba/IEEE/ www.westel900.net/internet/szolgaltatasok/wlan.html www.pgsm.hu/kinalat/szolgaltatasok/wlan_hu.html www.ebstrategy.com/Books/M-Business/RevenueModel/802.11b_WiFi.html www.mobilestar.com www.amazingports.com www.aland.net www.boingo.com www.btopenzone.com www.cometanetworks.com www.defaultcity.net/index-eng.html www.getontheair.net www.gric.com www.ipass.com first.nespot.com/english/web www.metronet.at www.netcheckin.biz www.ntt.com/release_e/news02/0004/0425.html www.nttdocomo.com www.singtel.com www.sonera.com www.starhub.com/online/wirelessbroadband/faq.html www.swisscom-eurospot.ch, news.zdnet.co.uk/story/0,,t269-s2131606,00.html www.homerun.telia.com www.telstra.com.au www.t-mobile.de/hotspot www.vodafone.com www.wayport.com IEEE Standard 802.11b-1999 Annex A George Xylomenos, George C. Polyzos: „TCP and UDP Performance over a Wireless LAN” Saman Desilva, Samir R. Das: “Experimental Evaluation of a Wireless Ad Hoc Network” INRIA Homepage, http://www.inria.fr Bay Area Research Wireless Access Network, http://www.cs.berkeley.edu/~randy/Daedalus/BARWAN/BARWAN_index.html B. Aboba, M. Beadles, "The Network Access Identifier", RFC 2486, January 1999. P. Congdon, B. Aboba, T. Moore, A. Palekar, A. Smith, G. Zorn, D. Halasz, A. Li, A. Young, J. Roese, "IEEE 802.1x RADIUS Usage Guidelines", IETF Internet Draft, July 2001. www.palowireless.com/homerf/homerfspec.asp http://standards.ieee.org/getieee802/download/802.11b-1999.pdf www.westel900.net/internet/szolgaltatasok/wlan.html C. Rigney, S. Willens, A. Rubens, and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. Schneider, B., “Applied cryptography: protocols, algorithms, and source code in C” Volume ISBN 0-471-59756-2, John Wiley & Sons, 1996. Trapeze Networks, "AP Architecture Impact on the WLAN, Part 1: Security and Manageability", White Paper, 2003. Trapeze Networks, "AP Architecture Impact on the WLAN, Part 1: Scalability, Performance and Resiliency", White Paper, 2003. www.iobox.de DBS Home Page: http://shika.aist-nara.ac.jp/member/yukio-m/dbs/ http://www.isi.edu/nsnam/ns/ Shugong Xu, Tarek Saadawi, City University of New York, "Does the IEEE 802.11b MAC Protocol Work Well in Multihop Wireless Ad Hoc Networks?", IEEE Communications Magazine, June 2001. V. Kanodia, C. Li, A. Sabharwal, B. Sadeghi, E. Knightly, "Ordered Packet Scheduling in Wireless Ad Hoc Networks. Mechanisms and Performance Analysis", In proceedings of MOBIHOC`02, June 2002., Lausanne, Switzerland Attila Török, István Moldován, Csaba Simon, "Improving TCP Performance in Mobile Ad Hoc Networks Using Mobility Prediction", In proceedings of IEEE MWCN 2001, Recife, Brasil. Michael Cloran (BEng in Telecommunications), “Simulation of IEEE 802.11 PCF function in GloMoSim “,DUBLIN CITY UNIVERSITY SCHOOL OF ELECTRONIC ENGINEERING, April 2004. Gyires Tibor. “Hálózatok szimulációja”, (http://elek.inf.elte.hu/Informatikai/I5E.pdf) R. F. Heile, I. C. Gifford, J. D. Allen, P. Kinney,l, “Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for High Rate Wireless Personal Area Networks (WPAN)”, Draft Standard for Telecommunications and Information Exchange Between Systems, Draft P802.15.3/D15, October 2002 J. Karaoguz: High-Rate Wireless Personal Area Networks, IEEE Communications Magazine, December 2001, pp. 96-102 Lu, H. L., Faynberg, I.: An Architectural Framework for Support of Quality of Service in Packet Networks, IEEE Communications Magazine, 2002 június, 98-105.

148.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata [62] [63] [64] [65] [66] [67] [68] [69] [70] [71]

http://www.ieee802.org/16/tge/ http://grouper.ieee.org/groups/802/20/ Jing Zhu, Sumit Roy, ”MAC for Dedicated Short Range Communications in Intelligent Transportation System”, IEEE Communications Magazine, December 2003. http://www.debian.org/devel/debian-installer/ http://www.agere.com/mobility/wireless_lan_drivers.html http://pcmcia-cs.sourceforge.net/ http://bluehoc.sourceforge.net/tutorial/docpage.html http://btsim.sourceforge.net/ http://nms.lcs.mit.edu/projects/blueware/software/ Bluetooth Core Specification 2.0, http://www.bluetooth.org

BZAKA

AmI Project

149.


7. RÖVIDÍTÉSLISTA AC ACC ACK ACL AES AH AMI ANCLES ANSI AODV AP API ARQ ARQN ASTM AT ATM AUX BAN BER BPSK BSD BSS BZAKA CAC CAP CBR CCA CCK CD CDMA CFP CID CRC CTA CTS CSMA CSMA/CA CSMA/CD DAC DBS DC DCF DECT DES DEV DEVID DFS DH DHCP

150.

Access Code Adaptive Cruise Control Acknowledge Asynchronous Connectionless Advanced Encryption Standard Ad Hoc mode Ambient Intelligence ATM Networks Call-LEvel Simulator American National Standards Institute Ad-Hoc on Demand Distance Vector Access Point Application Program Interface Automatic Repeat Request Automatic Repeat Request Number American Society for Testing and Materials ATtention Asynchronous Transfer Mode Auxiliary Body Area Network Bit Error Ratio Binary Phase Shift Keying Berkeley Software Distribution Basic Service Set Bay Zoltán Alkalmazott Kutatási Alapítvány Channel Access Code Contention Access Period Constant Bit Rate Clear Channel Assessment Complementary Code Keying Collosion Detect Code Division Multiple Access Contention Free Period Connection Identifier Cyclic Redundancy Code Channel Time Allocation Clear To Send Carrier-Sense Multiple Access CSMA/Collision Avoidance CSMA/Collosion Detect Device Access Code Distributed Benchmark System Direct Current Distributed Coordination Function Digital Enhanced Cordless Telecommunication Data Encryption Standard Device Device Identifier Dynamic Frequency Selection Data High Dynamic Host Configuration Protocol

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata DSSS DIFS DRR DS DSL DSR DSRC DSSS DV EAP ED EIFS EIRP EKG ERC ESS ETS ETSI FCC FCS FEC FH FHS FHSS FNFT FTP GAP GIAC GPRS GPS GPSS GSM GT GTS HCI HEC HTH HTTP HV IAC IAPP IBM ID IEEE IETF IFS IHM IP IPL IR ISA ISBN

BZAKA

Direct Sequence Spread Spectrum Distributed IFS Deficit Round Robin Distribution System Digital Subscriber Line Dynamic Source Routing Dedicated Short-Range Communications Direct Sequence Spread Spectrum Data Voice Extensible Authentication Protocol Erroneous Data Extended IFS Effective Isotropic Radiated Power Electrocardiogram European Radiocommunications Committee Extended Service Set Educational Testing Service (?) European Telecommunications Standards Institute Federal Communications Commission Frame Check Sequence Forward Error Correction Frequency Hop Frequency Hopping Sequence Frequency Hoping Spread Spectrum Frekvenciasávok Nemzeti Felosztási Táblázata File Transfer Protocol Generic Access Profile General Inquiry Access Code General Packet Radio Service Global Positioning System General Purpose Simulation Software Global System for Mobile Communications Transmitter Antenna Gain (?) Guaranteed Time Slots Host Controller Interface Header Error Check Hírközlési Területi Hivatal Hypertext Transfer Protocol High quality Voice Inquiry Access Code Inter-Access Point Protocol International Business Machines Corporation Identifier Institute of Electrical & Electronics Engineers Internet Engineering Task Force Inter Frame Space Informatikai és Hírközlési Minisztérium Internet Protocol IBM Public License Infrared Industry Standard Architecture International Standard Book Number (kiveheto)

AmI Project

151.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata ISM ISO ISO/IEC ITS KPI LAN LAP LAR LLC LMP LQ LSB MAC MACA MCTA MIB MSDU MTS MTU N/A NAP NAV NS NTP OBEX ODMRP OFDM OS OSI PAN PARSEC PBCC PC PCF PCMCIA PDA PDU PG PHY PIFS PLCP PLW PMD PNC PPP PSDU PSF PSPS QPSK R/A RFC RFCOMM

152.

Industrial Scientific Medical International Organization for Standardization International Electrotechnical Commission Intelligent Transportation Systems Kutatás-fejlesztési Pályázati és Kutatáshasznosítási Iroda Local Area Network Lower Address Part Location Aware Routing Logical Link Control Link Manager Protokoll Link Quality Least Significant Bit Media Access Control Management Channel Time Allocations Management Channel Time Allocations Management Information Base MAC Service Data Unit Management Time Slots Maximum Transfer Unit Not Available Nemzetközi nagyprojekt Network Allocation Vector Network Simulator Network Time Protocol Object Exchange On-Demand Multicast Routing Protocol Orthogonal Frequency Division Multiplexing Operating System Open Systems Interconnection Personal Area Network Parallel Simulation Environment for Complex Systems (?) Packet-based Binary Convolutionary Code Personal Computer Point Coordination Function Personal Computer Memory Card International Association Personal Digital Assistant Protocol Data Unit Processing Gain Physical Point Coordination IFS Physical Layer Convergence Procedure PSDU length word Physical Media Dependent Piconet Coordinator Point-to-Point Protocol PHY Sublayer Service Data Unit PLCP Signaling Field Piconet-Synchronized Power Saving Quadrature Phase Shift Keying Roadside Applications Request for Comment Radio Frequency Communication

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata RLAN RLC RSA RSSI RTS RTT SAP SAR SCO SDP SDU SEQN SFD SIFS SIG S/N SNMP SNR SPS SRD SS SSCS SSID TCP TCS TDD TDM TDMA TFTP TKIP TPC UDP UMTS USB UWB VLAN VPN WAP WEP WIFI WLAN WMAN WPA WPAN

BZAKA

Radio Local Area Network Radio Link Control Rivest, Shamir, & Adleman Received Signals Strength Indicator Request to Send Round-Trip Time Service Access Point Specific Absorption Rate Synchronous Connection-Oriented Link Service Discovery Protocol Service Data Unit Sequential Numbering Start Frame Delimiter Short Inter Frame Space Special Interest Group Signal/Noise Simple Network Management Protocol Signal-to-Noise Ratio Synchronous Power Saving Short Range Device Subscriber Station Service Specific Convergence Sublayer Secure Set Identifier Transmission Control Protocol Telephony Control Signaling Time Division Duplex Time Division Multiplexing Time Division Multiple Access Temporal Key Intergity Protocol Temporal Key Integrity Protocol (formerly WEP2) Transmission Power Control User Datagram Protocol Universal Mobile Telecommunications System Universal Serial Bus Ultra Wide Band Virtual Local Area Network Virtual Private Network Wireless Application Protocol Wired Equivalent Privacy Wireless Fidelity Wireless Local Area Network Wireless Metropolitan Area Network Wi-Fi Protected Access Wireless Personal Area Network

AmI Project

153.


8. ÁBRÁK JEGYZÉKE 1. ábra: BSS-ből álló infrastruktúra hálózat ............................................................................. 23 2. ábra: Ad hoc hálózat............................................................................................................. 23 3. ábra: Az IEEE 802.11 referencia modellje........................................................................... 24 4. ábra: A PLCP keret FHSS esetén........................................................................................ 25 5. ábra: A PLCP keret DSSS és HR/DSSS esetén ................................................................... 25 6. ábra: A MAC keret felépítése............................................................................................... 25 7. ábra: A keretvezérlő mező felépítése ................................................................................... 26 8. ábra: Az RTS/CTS mechanizmus üzenetei .......................................................................... 26 9. ábra: A CSMA/CA protokoll szakaszai ............................................................................... 27 10. ábra: Külső körsugárzó....................................................................................................... 28 11. ábra: YAGI antenna ........................................................................................................... 28 12. ábra: Szektor antenna ......................................................................................................... 28 13. ábra: Parabola antenna ....................................................................................................... 28 14. ábra: Elnyomás DSSS rendszerben .................................................................................... 28 15. ábra: FHSS interferencia-elnyomása.................................................................................. 29 16. ábra: Cellás elv, különböző frekvenciasávokkal ................................................................ 30 17. ábra: A teljes 802.11 architektúra. ..................................................................................... 31 18. ábra FHSS és DSSS összehasonlítás.................................................................................. 34 19. ábra: A három absztrakciós szint: Projekt-, Csomópont- és Folyamatszerkesztők........... 50 20. ábra: Skaláris adatok (felső grafikon), vektor adatok (alsó grafikon) megjelenítése........ 50 21. ábra: Négy grafikont megjelenítő elemzőeszköz ............................................................... 51 22. ábra: A hálózat topológiának az a része ............................................................................. 52 23. ábra: Az üzenetforrás. távoli kliens.................................................................................... 52 24. ábra: Beállítások................................................................................................................. 52 25. ábra: A Glomosim rétegelt szerkezete ............................................................................... 53 26. ábra: A beépített protokollok képességei ........................................................................... 53 27. ábra: A C++ és az OTcl kapcsolata.................................................................................... 54 28. ábra: OTcl osztályhierarchia .............................................................................................. 54 29. ábra: A csomópont (node) felépítése.................................................................................. 55 30. ábra: Összeköttetés (link) .................................................................................................. 55 31. ábra: A folyam útja két node között ................................................................................... 56 32. ábra: Mobil csomópont architektúra (NS).......................................................................... 56 33. ábra: A “Zavarás két hop távolságra” jelenség (NS).......................................................... 57 34. ábra: A “double ring” jelenséget szemléltető topológia..................................................... 58 35. ábra: Zavarás két hop távolságra........................................................................................ 58 36. ábra: TCP instabilitás 4 ugrásos TCP folyam esetén ......................................................... 60 37. ábra: Információs aszimmetriához vezető topológia.......................................................... 61 38. ábra: Információs aszimmetria UDP/CBR forgalmak esetén ............................................ 62 39. ábra: Az 1. csomópont küld adatot a 3. csomópontnak...................................................... 63 40. ábra: Az 5. csomópont küld adatot a 2. felé ...................................................................... 63 41. ábra: Unfairness UDP folyamok esetén ............................................................................. 65 42. ábra Hálózati topológia ...................................................................................................... 68 43. ábra Több ugrásos teszthálózat .......................................................................................... 69 44. ábra Proxim Orinoco WLAN hálózati kártya .................................................................... 71 45. ábra 3COM Bluetooth hálózati kártya ............................................................................... 71 46. ábra Bázisállomás (Acces Point – AP)............................................................................... 71 47. ábra Körsugárzó antenna.................................................................................................... 72 48. ábra Mobil állomás............................................................................................................. 72 154.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata 49. ábra GPS készülék.............................................................................................................. 72 (*) 50. ábra Hálózati elrendezések Bázisállomás ill. Ad Hoc üzemmódban ........................... 75 (*) 51. ábra Átviteli sávszélesség különböző üzemmódokban. ............................................... 76 (*) 52. ábra Késleltetés különböző üzemmódokban ................................................................ 76 53. ábra. Több munkaállomásos elrendezés............................................................................. 77 (*) 54. ábra 3 db TCP folyam Ad Hoc módban (csomagsorszám, sávszélesség) .................... 77 (*) 55. ábra 3 db UDP adatforgalom Ad Hoc módban (késleltetés) ........................................ 78 (*) 56. ábra 3 db TCP folyam bázisállomás üzemmódban (csomagsorszám, sávszélesség) ... 78 (*) 57. ábra: a) Sávszélesség; b) Csomagkésleltetés; c) Késleltetés-ingadozás (Jitter); d) Távolság; e) Jelerősség; ........................................................................................................... 80 (*) 58. ábra: a) Sávszélesség; b) Csomagkésleltetés; c) Késleltetés-ingadozás (Jitter); d) Távolság; e) Jelerősség; ........................................................................................................... 82 (*) 59. ábra: a) Sávszélesség; b) Csomagkésleltetés; c) Késleltetés-ingadozás (Jitter); d) Távolság; e) Jelerősség; ........................................................................................................... 84 (*) 60. ábra: a) Sávszélesség; b) Csomagkésleltetés; c) Késleltetés-ingadozás (Jitter); d) Távolság; e) Jelerősség; ........................................................................................................... 86 (*) 61. ábra: a) Sávszélesség; b) Csomagkésleltetés; c) Késleltetés-ingadozás (Jitter); d) Távolság; e) Jelerősség; ........................................................................................................... 88 62. ábra: Egy Bluetooth eszköz a méreteit jelző gyufaszállal.................................................. 90 63. ábra: Az ugrási frekvencia előállítása slave egységekben ................................................. 93 64. ábra: Egy scatternet megközelítés ...................................................................................... 94 65. ábra: Az ugratási frekvencia előállítása több piconethez tartozó egység esetén................ 94 66. ábra: Két piconet egy közös slave-vel................................................................................ 95 67. ábra: Időzítések piconetek közötti kommunikáció esetén.................................................. 95 68. ábra: SCO és ACL linkek egy mastert és két slave-et tartalmazó piconetben ................... 97 69. ábra: A Bluetooth csomagok és a küldésükhöz használt csatornák frekvenciája .............. 97 70. ábra: Csomagtípusok felépítése a Bluetooth-ban ............................................................... 98 71. ábra: Access kód felépítése ................................................................................................ 99 72. ábra: Preamble.................................................................................................................... 99 73. ábra: A trailer kétféle felépítése CAC használatakor ....................................................... 100 74. ábra: BB_header mező felépítése..................................................................................... 100 75. ábra: A payload felépítése ACL típusú csomag esetén .................................................... 101 76. ábra: A Bluetooth csatorna kialakítás állapot átmenetei .................................................. 104 77. ábra: Kapcsolat-felépítés állapotgráf................................................................................ 105 78. ábra: A Bluetooth protokollszerkezete............................................................................. 107 79. ábra: Adoptált protokollok és alkalmazások Bluetooth-ban ............................................ 108 80. ábra SDP szolgáltatás felépítése....................................................................................... 110 81. ábra: Kapcsolatfelépítésl és QoS paraméterek beállításáva ............................................. 113 82. ábra: A master beállítása .................................................................................................. 115 83. ábra: Kommunikáló Bluetooth egységek a Bluetooth-sim szimulátorban....................... 117 84. ábra: Eszközfelderítési idő ............................................................................................... 119 85. ábra: Sikeres adatátvitel valószínűsége az interferáló piconetek számának függvényében ................................................................................................................................................ 120 (*) 86. ábra: a) Sávszélesség; b) Csomagkésleltetés; c) Késleltetés-ingadozás (Jitter); d) Távolság; e) Vett jelerősség indikátor; f) Kapcsolat-minőség;.............................................. 122 (*) 87. ábra: a) Sávszélesség; b) Csomagkésleltetés; c) Késleltetés-ingadozás (Jitter); d) Távolság; e) Vett jelerősség indikátor; f) Kapcsolat-minőség;.............................................. 124 88. ábra: Alkalmazási lehetőségek ......................................................................................... 125 89. ábra: Vezetéknélküli szabványok..................................................................................... 126 90. ábra: A piconet elemei...................................................................................................... 128 BZAKA

AmI Project

155.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata 91. ábra: A 802.15.3 főkeretek szerkezete ............................................................................. 130 92. ábra: A szülő és a gyermek piconetek viszonya............................................................... 131 93. ábra: Csillag topológia a 802.15.4 hálózatokban ............................................................. 134 94. ábra: Peer-to-peer topológia a 802.15.4 hálózatokban..................................................... 135 95. ábra: Klaszter-fa topológia a 802.15.4 hálózatokban....................................................... 135 96. ábra: Egy 802.15.4 eszköz belső architektúrája ............................................................... 136 97. ábra: A 802.15.4 csatornáinak frekvencia struktúrája...................................................... 138 98. ábra: A 802.15.4 főkeret struktúrája garantált időrésekkel .............................................. 140 99. ábra: Az általános 802.16 MAC PDU fejléc .................................................................... 143 100. ábra: A 802.20 spektrális hatékonysága más rendszerekéhez képest............................. 144

156.

AmI Project

BZAKA


9. TÁBLÁZATOK JEGYZÉKE 1. táblázat: Különböző vezeték nélküli technológiák paraméterei........................................... 15 2. táblázat: Magyarországon érvényes frekvencia-felhasználási szabályok ............................ 17 3. táblázat: Frekvenciakijelölési határozatot igénylő rádióberendezések ................................ 17 4. táblázat: Az USA-ban használt IEEE 802.11b csatorna frekvenciák.................................. 30 5. táblázat: Javasolt tesztsorozatok összefoglalója................................................................... 44 6. táblázat: Új antenna illesztése .............................................................................................. 45 7. táblázat: A fizikai interfész konformancia vizsgálata .......................................................... 48 8. táblázat: A frekvenciatartományok és a kijelölt frekvenciák az adott régiókban................. 91 9. táblázat: Bluetooth teljesítmény-osztályok .......................................................................... 92 10. táblázat: Az elérhető bitsebességek ACL link esetén....................................................... 102 11. táblázat: Az elérhető bitsebességek SCO link esetén....................................................... 103 12. táblázat: Az elérhető bitsebességek eSCO link esetén ..................................................... 103

BZAKA

AmI Project

157.


1. SZ. MELLÉKLET: A MÉRÉSI KÖRNYEZET BEMUTATÁSA Az alábbi leírás ismerteti a mérésekhez használt eszközöket, és a mérés elvégzéséhez szükséges telepítési illetve beállítási folyamatot. 1.1

A MÉRÉSHEZ HASZNÁLT ESZKÖZÖK LISTÁJA:

• 12V-230V inverter, mobitronic pocket power type 830-012PP • Notebook, IBM ThinkPad R50e • Külső antenna, YSC-RE05U-MC • WLAN kártya, Orinoco 8420-WD PCMCIA card • Bluetooth kártya, 3com 3CRWB6096B PCMCIA card A méréshez minden eszközből 2 db szükséges. 1.2

AZ ESZKÖZÖK TELEPÍTÉSE

A méréshez használt software linux operációs rendszert igényel, ezen okok miatt Debian linux került telepítésre a gépekre. A telepítéshez használt CD a Debian Network install [65], ami csak a telepítéshez szükséges legfontosabb csomagokat tartalmazza. A telepítés folyamán esetlegesen kijelölt a CD-n nem található csomagokat a hálózatról tölti le. A CD a tesztelés alatt álló - és így folyamatosan frissülő – 2005. március 05-i csomagokat tartalmazta. A jelenleg tesztelés alatt álló Debian verzió a sarge 3.0 r2. A linux által használt kernel a debian csomagként letölthető 2.4.27-2-386 verzió. 1.2.1

PCMCIA KÁRTYÁK HASZNÁLATA

A fent említett PCMCIA kártyák (lásd: 2.8.2 fejezet) használata a linux alatt okozott nehézségeket.

1.2.1.1 A WLAN kártya használata A WLAN kártya használatához a gyártó honlapján található driver (wl_lkm_722_abg.tar.gz) letöltése szükséges [66]. Ezen driver forráskódot tartalmaz, a fordításához a következő csomagok telepítése szükséges: •

kernel-image-2.4-386

•

kernel-headers-2.4-386

•

kernel-source-2.4.27

Szükséges továbbá a pcmcia-cs-3.2.8.tar.gz forrás letöltése is [67]. A driver fordítás a következő lépésekben történik: 1. kernel forrás telepítése, .tar.bz2 file kibontása 2. ln -s /usr/src/kernel-source-2.4.27 /usr/src/linux 3. cp /boot/config-2.4.27-2-386 /usr/src/linux/.config 4. kernel headers telepítése

158.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata 5. ln -s /usr/src/kernel-headers-2.4.27-2-386 /usr/src/include 6. /usr/src/linux könyvtárban: make menuconfig 7. beállítás: [General setup]/[PCMCIA/CardBus support]/[PCMCIA/CardBus support] = disable 8. make dep; make bzImage; make modules 9. /usr/src könyvtárba pcmcia-cs-3.2.8.tar.gz kibontása 10. ln –s /usr/src/pcmcia-cs-3.2.8 /usr/src/pcmcia 11. pcmcia-cs könyvtárba wl_lkm_722_abg.tar.gz kibontása 12. pcmcia-cs könyvtárban: ./Configure; ./Install 13. /etc/default/pcmcia file szerkesztése: PCIC=i82365 14. /etc/init.d/pcmcia restart Ezek után a WLAN kártya használható. A kártya beillesztésekor célszerű kiadni a /etc/init.d/pcmcia start parancsot. A kivétele előtt feltétlenül ki kell adni a /etc/init.d/pcmcia stop parancsot ellenkező esetben a gép lefagy.

1.2.1.2 A Bluetooth kártyák használata Ezeknél a kártyáknál a driver oldaláról vizsgálva szerencsésebb a helyzet, a kártya behelyezése után a rendszer rögtön érzékeli és kezelni is tudja. Az érdekesség csupán annyi, hogy 2 soros port jelenik meg a rendszerben. Ezek után a Bluetooth használatához ezeket a soros portokat kell megfelelően bekonfigurálni. A következő csomagok telepítése szükséges: •

setserial

•

bluez-utils

A kártya használatba vételéhez a következő parancsok kiadása szükséges: 1. /etc/init.d/pcmcia start 2. modprobe -a hci_uart 3. modprobe -a l2cap 4. hciattach /dev/ttyS16 any 115200 Esetünkben a kártya csatlakoztatásakor 16-os és 17-es soros portok jelentek meg a rendszerben. 5. hciconfig hci0 inq Ha minden rendben zajlott akkor itt megjelenik a rendszerben hci0 eszköz, és az alábbi parancs ezen eszköz tulajdonságait (pl. MAC címét) jeleníti meg. hcitool scan paranccsal megjeleníthetők a hatótávolságon belül érzékelt bluetooth eszközök. A kártya eltávolításához a következő parancsok kiadása szükséges: 1. kill -TERM `pgrep hciattach` 2. rmmod rfcomm BZAKA

AmI Project

159.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata 3. rmmod l2cap 4. rmmod hci_uart 5. /etc/init.d/pcmcia stop 6. unplug the card Ezek kiadása feltétlen meg kell, hogy történjen, ellenkező esetben a gép lefagy. 1.3

ESZKÖZÖK KONFIGURÁCIÓJA A MÉRÉSHEZ

A mérések elvégzéséhez IP szintű kapcsolat szükséges a két gép között. A két gépnél különféle okok miatt itt már eltérően kell konfigurálni. 1.3.1

MÉRÉS A WLAN KÁRTYÁVAL

A konfiguráláshoz szükséges a wireless-tools csomag telepítése a gépre. Ezek után lehetséges a eth1 (esetünkben) wireless ethernet interfész konfigurációja. Az egyik gépen futtatandó parancsok a következők: 1. iwconfig eth1 essid wwwq mode Ad-Hoc channel 5 2. ifconfig eth1 10.0.0.1 mtu 1500 up A másik gépen futtatandó parancsok a következők: 1. iwconfig eth1 essid wwwq mode Ad-Hoc channel 5 2. ifconfig eth1 10.0.0.2 mtu 1500 up Ha minden rendben történt, ezek után a két gép látja egymást. Ha a két gép között a 1.3.3után a két gép látja egymást. Ha a két gép között a 1.3.3 fejezetben leírt időszinkronizációt is elvégeztük, kezdődhet a mérés. 1.3.2

MÉRÉS A BLUETOOTH KÁRTYÁVAL

A mérés konfigurációja itt bonyolultabb, mint WLAN esetén. Ahhoz, hogy az alkalmazott módszerrel IP-s kapcsolat jöjjön létre, már a konfigurálásnál előfeltétel, hogy a két gép lássa egymást. Amennyiben a két gép között a bluetooth kapcsolat megszakad, szükséges bizonyos szintű újrakonfigurálás, hogy a látómezőbe kerüléskor a kapcsolat ismét helyreállhasson.

1.3.2.1 Első gép beállítása Inicializáló parancsok az egyik gépen: 1. brctl addbr pan0 2. ifconfig pan0 10.0.0.1 3. brctl setfd pan0 0 4. brctl stp pan0 off 5. modprobe -a bnep 6. sleep 1 160.

AmI Project

BZAKA

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata 7. pand -s -M --role=NAP Mind itt, mind egy a kapcsolat megszakadása utáni újrakapcsolódáskor szükséges kiadni az alábbi parancsokat: 1. until ifconfig bnep0 ; do : ; done >/dev/null 2> /dev/null Ez a rész várakozik, amíg bnep0 interfész létrejön, azaz a második gép képes kapcsolódni. 2. brctl addif pan0 bnep0 3. ifconfig bnep0 0.0.0.0 up Az előző két sor pedig beálltja bnep0 interfészt. Az automatikus újrakapcsolódás megvalósításához, amit a mérésben felhasználtunk, szükséges meg egy script írása, ami folyamatosan figyeli bnep0 interfész létezését, ha rendben találja nem csinál semmit. Ha viszont a kapcsolat megszakadása miatt az interfész megszűnt, az előbb ismertetett parancsokkal megpróbálja beállítani azt.

1.3.2.2 Második gép beállítása Inicializáló parancsok a második gépen: 1. modprobe -a bnep Mind itt, mind egy a kapcsolat megszakadása utáni újrakapcsolódáskor szükséges kiadni az alábbi parancsokat: 1. until ifconfig bnep0 ; do pand -c 00:0A:5E:49:06:46 ; done > /dev/null 2> /dev/null Esetünkben a 00:0A:5E:49:06:46 azonosító az első gépben található kártya MAC címe. Ez a rész folyamatosan próbál kapcsolódni az első géphez. Ezt addig ismétli, amíg bnep0 interfész létrejön, képes az első géphez kapcsolódni. 2. ifconfig bnep0 10.0.0.2 up Ez a sor bnep0 interfész beállítását végzi el. Az automatikus újrakapcsolódás megvalósításához, ugyanaz szükséges, amit az első gép esetében leírtunk. 1.3.3

IDŐSZINKRONIZÁCIÓ

A két gép szerepe ebben az esetben is eltér egymástól. Az egyik gép lesz a referenciaórát szolgáltató szerver. A másik kliensként kapcsolódik hozzá a mérés megkezdése előtt és a szerver órája alapján állítja be a saját óráját. A megvalósításhoz szükséges a következő csomagok telepítése: •

ntp-simple

•

ntpdate

A telepítés után a szinkronizációhoz a szerver gépen a /etc/init.d/ntp-server start parancs kiadása szükséges.

BZAKA

AmI Project

161.

Az AmI témakörébe tartozó kommunikációs protokollok hatékonyságának vizsgálata A kliens gépen a ntpdate -B 10.0.0.1 parancs kiadására van szükség. Ez utóbbi parancsot javasolt többször futtatni, pl. watch program segítségével, ugyanis csak fokozatosan áll be a gép órája egy bizonyos pontosságra.

1.4

DBS

A mérések ideje alatt mindkét mérést végző számítógépen folyamatosan futott a dbsd démon. A mérésekhez a következő dbs parancsfájlt használtuk (udp_MO_1024_f.cmd): { sender { hostname = 10.0.0.2; #hostname = 193.225.128.237; port = 60001; so_debug = OFF; tcp_trace = OFF; no_delay = OFF; send_buff = 32768; recv_buff = 32768; mem_align = 8192; pattern {1024, 1024, 0.001, } receiver { #hostname = 193.225.128.235; hostname = 10.0.0.1; port = 60001; so_debug = OFF; tcp_trace = OFF; no_delay = OFF; recv_buff = 32768; send_buff = 32768; mem_align = 8192; pattern {1024, 1024, 0.001, } file = results/udp_MO_1024_f protocol = UDP start_time = 0.0; connection_mode= AFTER; end_time = 240; send_times = 2048000;

0.0}

0.0}

}

Az fájlban látható end_time változót a mérés kívánt hosszának megfelelően állítottuk be. A mérés elindítása a dbsc -d -d udp_MO_1024_f.cmd paranccsal történt.

162.

AmI Project

BZAKA

AZ AMI TÉMAKÖRÉBE TARTOZÓ

Recommend Documents