Informatika | Távközlés » Ad Hoc OMNeT++ szimulációs mérés

Mérési útmutató a Mobil kommunikációs laboratórium méréseihez IV.szmérés Ad Hoc OMNeT++ szimulációs mérés Mérés helye: Híradástechnikai Tanszék Mobil Távközlési és Informatikai Laboratórium (MC2L) I.B113 Összeállította: Horváth Cz. János PhD hallgató Karácsony Anna Szűcs Attila Schlegl Róbert Utolsó módosítás: 2003. május 5 Bevezetés Napjainkban egyre fontosabb szerepet játszik a mobilitás az élet minden területén. A jelenleg rendelkezésre álló mobil technológiák (pl GSM) azonban költséges infrastruktúrát és összetett telepítési munkálatokat igényelnek Sok esetben hasznos lenne, ha infrastruktúra kiépítése nélkül lehetne létrehozni kommunikációs hálózatokat. Ez az igény inspirálja a kutatókat arra, hogy feltárják az ad hoc hálózatokban rejlő lehetőségeket. Ugyanakkor sajnálatos módon még nem született olyan szervezet, amely összefogja és koordinálja a kutatók munkáját, így a kutatási,

főleg a teljesítményelemzésekre vonatkozó eredmények gyakran nem összemérhetőek. A távközlésben az ad hoc fogalma viszonylag új dolog. Egy mobil ad hoc hálózat olyan mobil pontok autonóm rendszere, ahol a résztvevő egységek között vezeték nélküli, rádiós csatorna biztosítja a kommunikációt. Ha két mobil pont nincs egymás adókörzetében, akkor a köztük forgalmazott összes üzenet a közbeeső pontokon fog keresztülmenni. Erre az időre ezen állomások router funkciót látnak el. Az állomások szabadon mozoghatnak, így a teljes hálózat topológiája rövid időn belül jelentősen megváltozhat. Ebben a környezetben kell olyan routing és titkosítási protokollt alkalmazni, amely a gyakori változások dacára képes a kommunikációs utak megtartására és azok adminisztrálására. Amennyiben a célunk az, hogy teljesítmény szempontjából összehasonlítsuk a különböző ad hoc megoldásokat, szükség van egy általános szimulációs

környezetre, amely azonos feltételeket teremt az elemzések elvégzéséhez. A mérés során egy ilyen általános szimulációs környezetet használunk, majd a már implementált ad hoc hálózati protokollokkal való futtatás után következtetéseket vonunk le azok teljesítményére vonatkozólag. A célunk az, hogy megismertessük az ad hoc hálózatok felépítésének és működésének alapelveit, bemutassuk az általunk alkalmazott szimulációs környezetet, valamint ismertessük az implementált protokollok teljesítményére vonatkozó következtetéseinket. Az OMNeT++ diszkrét esemény szimulátor Az OMNeT++ (Objective Modular Network Testbed in C++) egy objektumorientált diszkrét esemény szimulátor. Az alkalmazási területe főleg a számítógép-hálózatok, kommunikációs protokollok és elosztott rendszerek szimulálása, de kiválóan alkalmazható minden olyan területen, ahol a diszkrét eseményeken alapuló megközelítés helytálló. A

szimulálandó rendszerek modellezésére egymásba ágyazott modulokból álló modulhierarchia szolgál. Ez lehetővé teszi a rendszerfunkciók logikai felosztását és elkülönítését. A modulok üzenetküldéssel kommunikálhatnak, amelyre az OMNeT++ kétféle módszert kínál: direkt, illetve előre definiált paraméterű (késleltetés, hibavalószínűség, adatsebesség) csatornákon keresztüli üzenetátvitel. A szimulátor rugalmas működésének érdekében lehetőség nyílik a modulok számára paraméterek definiálására. A paraméterek használatával befolyásolhatók a modulok viselkedése, de segítségükkel szabályozható a felépített modulhierarchia is. A modulhierarchia alján lévő un. egyszerű modulok tartalmazzák a felhasználó által C++ nyelven megvalósított algoritmusokat. Az egyszerű modulok egymással konkurensen futnak, ami elősegíti pl. az elosztott rendszerek valóságnak megfelelő szimulálását Az OMNet++ fejlett

felhasználói felületet kínál a szimuláció megjelenítésére és nyomon követésére. A felhasználó elindíthatja/megállíthatja a szimulációt, közben megjelenítheti és módosíthatja az objektumok paramétereit A szimulátor futási idejének csökkentésére is ad támogatást az OMNeT++: az animációs sebesség állítható, az animáció ki is kapcsolható, valamint elkészíthető a szimulátor parancssoros változata, ahol a felhasználói felület nem lassítja a program futását A modelltopológia leírására a NED nyelv használható. A NED nyelvű állományokban definiálhatók a hálózat egyszerű/összetett moduljai, a modulok paraméterei, a modulok közötti kapcsolatok és azok paraméterei A NED nyelv lehetőséget ad topológia minták készítésére is, ahol néhány modul típusát nem kell előre megadni, mindössze egy interfészt kell definiálni. A hiányzó modultípusok később paraméterek formájában adhatók meg A NED nyelvű kódok

ned kiterjesz- tésű fájlokban kapnak helyet, és a NEDC fordítóprogram segítségével alakíthatók C++ forráskódokká. A NED fájlokban definiált egyszerű modulok működését C++ nyelven lehet megadni, amihez az OMNeT++ széles eszköztárat biztosít. Ez az eszköztár nem más, mint egy osztályhierarchia. A hierarchia kiindulópontja a cObject osztály, amelynek a leszármazottai - többek között - az egyszerű és összetett modulok alapvető működését megvalósító cSimpleModule és cCompoundModule osztályok. A felhasználó ezen osztályokból származtathatja a saját osztályait, amelyekben a speciális modulokra jellemző sajátosságokat valósíthatja meg A modulok közötti kommunikáció támogatására szolgálnak a cMessage, a cPacket és a cGate osztályok. Az objektumhierarchia tartalmaz olyan osztályokat is, amelyek a rugalmas adattárolásra adnak segítséget, pl.: cArray, cQueue, cHead, cLinkedList A szimuláció eredményének könnyebb

kiértékelésére szolgál a cStatistic osztály és annak leszármazottjai. A számítógép- és távközlő-hálózatok modellezésénél fontos útvonal-keresési problémák hatékony megoldására használható a cTopology osztály Az itt felsoroltakon kívül még számos más osztály megtalálható az OMNeT++ -ban, az előző példák csupán a szimulátor lehetőségeinek illusztrálására szolgálnak. Mivel az OMNeT++ szabványos C++ nyelven íródott, platformfüggetlen. Nyitott forráskódú, így a teljes forráskód a felhasználó rendelkezésére áll, és szinte bármilyen operációs rendszer alatt lefordítható. A felhasználói felület Tcl/tk nyelvben készült, ezért a felhasználó ugyanazt a szimulációs környezetet használhatja minden operációs rendszer esetében. Az OMNeT++ PVM kiterjesztése alkalmassá teszi a szimulátort a többprocesszoros környezet hatékony kihasználására. Az OMNeT++ -ről további információ a szimulátor honlapján,

http://www.hitbmehu/phd/vargaa/omnetpphtm Internet címen érhető el a Általános ad hoc szimulátor felépítése Az általános ad hoc szimulátor szintén moduláris felépítésű. Az egyes modulok kialakítása, és a modulok közti kapcsolat tükrözi az ISO/OSI rendszerszemléletet. A modulok egy része újraimplementálható, cserélhető. A szimulátor önmagában nem alkalmas szimulációk futtatására, a cserélhető modulok számára csak egy programozói felületet biztosít. Az általános ad hoc szimulátor az OMNeT++ szimulátorhoz illeszkedve C++ nyelven készült A cserélhető modulok osztályszármaztatással, virtuális függvények implementálásával alakíthatók a felhasználó igényeihez. Az általános felépítést szem előtt tartva, a kiszolgáló rétegekben alapértelmezett modulok lettek megvalósítva, ezek módosításához, újraimplementálásához a szimulátor nem nyújt támogatást Mobility.xml Traffic.xml MobileNode[0]

MobileNode[1] InputDataParser Application NetworkLayer Application Scheduler DataLinkLayer PhysicalLayer NetworkLayer DataLinkLayer MobileNodeDatabase Transciever PhysicalLayer Transciever EnvironmentSimulation LogWriter SQL Server/ XML file/. Az általános Ad hoc szimulátor felépítése A mérés során a NetworkLayer álrétegben implementált routing protokollok teljesítményét vizsgáljuk. Az omnetppini állományban lehet megválasztani, hogy a szimuláció során melyik protokollt alkalmazzuk. Az InputDataParser modul Ennek a modulnak a feladata, hogy a felhasználó által megadott bemeneti adatokat értelmezze, és együttműködve az ütemező modullal a megfelelő időpontban érvényre juttassa. A bemeneti információk XML fájlok formájában adhatók meg Szimulációk futtatásához szükséges a csomópontok száma, és azok elhelyezkedése. Mivel mobil hálózatok szimulációjáról van szó, a felhasználónak lehetősége nyílik mozgási

modell definiálására is. A mérésekhez szükséges forgalmi modellek definiálása is, hiszen csakis az üzenetváltások vizsgálatával nyerhetünk információt a protokoll teljesítményéről A mozgási és a forgalmi modellek a szimulátor bemeneti adatai A Scheduler modul A modul feladata a bemeneti adatok feldolgozásának ütemezése. Nagy méretű bemeneti adatállományok esetén az erőforrások gazdaságos, és egyenletes kihasználása érdekében megakadályozza, hogy az InputDataParser modul az összes bemenő adatot egy ütemben dolgozza fel. E modul feladata az időfüggő események ütemezése is Időzítést igényel a mozgási, és a forgalmi modellt tartalmazó állományok feldolgozása is. A mozgási modell, a leíró állományban lévő bejegyzésekkel adható meg A bejegyzések tartalmazzák a csomópont azonosítót, a mozgásváltozás időpontját, és egy sebességvektort. A csomópontok aktuális pozíciójának meghatározásához elengedhetetlen,

hogy az egyes bejegyzések a megfelelő időpillanatban kerüljenek a feldolgozást végző modulhoz Hasonlóan időfüggő eseményeket definiálnak a forgalmi modell bejegyzései Egy bejegyzés a következőket tartalmazza: az üzenetküldés időpontja (szintén a szimuláció kezdetéhez viszonyítva), a forrás és a cél csomópont száma, az üzenet tartalma vagy az üzenet hossza (a szimulációk szempontjából az üzenetcsomagok tartalma kevésbé, inkább azok mérete a lényeges). A GeneralMobileNodeDatabase modul A szimuláció során elvégzett számításokhoz szükség van a csomópontok bizonyos paramétereire, például az aktuális pozíciójukra. A számítások elvégzése többnyire a GeneralEnvironmentSimulation modulban történik, de elképzelhető olyan protokoll, amely épít a csomópontok pozíciójára, vagy egyéb paramétereire így a MobileNode modul almoduljai számára is hozzáférhetőnek kell lenni ezeknek a paramétereknek. Mivel több modul is

használhatja a csomópontokhoz kötődő információkat, célszerű azokat egy központi, bármely másik modul számára elérhető modulban elhelyezni. Ez a modul szolgálja ki tehát a többi modul csomópont-információkra irányuló kéréseit. Ez egy cserélhető modul, ami azt jelenti, hogy az alapértelmezett megvalósítása (bizonyos korlátok között) újra implementálható vagy tetszőlegesen bővíthető A GeneralLogwriter modul A modul feladata, hogy a szimuláció során történő fontos eseményeket, változóértékeket valamilyen maradandó formában rögzítse. Ezen információk alapján válik lehetővé később a protokollok működésének analizálása A modul cserélhető, és a többi modul számára is elérhető. Az alapértelmezett megvalósításban két funkciót biztosít a modul. Egyrészt lehetővé teszi egy tetszőleges szöveg, így a legfontosabb események rögzítését. Másrészt paraméterek küldhetők a kimenetre név – érték

párosok formájában. A GeneralEnvironmentSimulation modul A GeneralEnvironmentSimulation modul feladata a rádiós terjedési viszonyok modellezése. Ez a modul is cserélhető, így a felhasználó tetszőlegesen pontosíthatja a rádiós modellt. A modul lehetőséget biztosít különböző csatornák, ezáltal különböző csatornahozzáférési technikát alkalmazó rendszerek (pl. TDMA, CDMA) megvalósítására A modul a csomópontokat megvalósító modulok számára nyújt átviteli szolgáltatást Az átviteli csatornák esetén három paraméter adható meg: két csillapítási határérték, valamint az adatsebesség. A csatornák definiálásakor a felhasználó saját formulákat használhat a csillapítás, a késleltetés és a hibavalószínűség számítására Az átvitel elején kiszámított hibavalószínűség az átvitel időtartama alatt változhat, attól függően, hogy történik-e adás a vevő csomópont közelében. A felhasználó ebben az esetben

is megadhatja, hogy milyen formulát alkalmazzon a modul az additív jellegű hibák kiszámítására. A modul az alapértelmezett megvalósításban nem tartalmaz terep-szimulációt. Ez azt jelenti, hogy nem definiálhatók tereptárgyak, amelyek a rádiós átvitelt befolyásolnák. Azonban a cserélhetőségnek köszönhetően a rendszer bővíthető egy ilyen terep-szimulációval is. A MobileNode modul A MobileNode modul valósítja meg a szimulációban a mobil csomópontot. Számos almodult tartalmaz, amelyek az ábrán láthatóan kapcsolódnak egymáshoz A modul kialakításakor fontos szempont volt, hogy az almodulok az ISO/OSI architektúrához hasonlóan épüljenek fel. Mivel minden almodul cserélhető, a rétegelt felépítés lehetővé teszi, hogy csak az ad hoc útvonalválasztó protokollt megvalósító rétege(ke)t cseréljük, így ugyanazon körülmények között vizsgálhatók azok. A modul a Scheduler és a GeneralEnvironmentSimulation modulokkal van

közvetlen összeköttetésben. A Scheduler modultól forgalmi információkat kap, amelyeket továbbít az alkalmazási réteget megvalósító almodulja számára A GeneralEnvironmentSimulation modullal pedig a csomagátvitel megvalósításának érdekében van összekötve. A GeneralApplication almodul Ez az almodul minden GeneralMobileNode modulban megtalálható. A GeneralMobileNode modul ennek a modulnak továbbítja a Scheduler modultól kapott forgalmi információkat. Az almodul felhasználhatja ezen információkat az adatforgalom generálásához, de a felhasználó implementálhat saját algoritmust is erre a célra. A GeneralApplication almodul összeköttetésben áll a közvetlenül alatta lévő almodullal. Ez is cserélhető modul, azonban implementálásakor figyelembe kell venni az alsó réteg által biztosított szolgáltatások megfelelő paraméterezését. A GeneralLayer almodul Az almodul feladata, hogy támogassa a protokoll rétegek megvalósítását.

Lehetőséget biztosít alrétegek definiálására is, és ez a modul is cserélhető A GeneralMobileNode modul a GeneralLayer almodul három, specializált változatát tartalmazza: NetworkLayer, DataLinkLayer, PhysicalLayer. Ezek megfelelnek az ISO/OSI modell hálózati, adatkapcsolati és fizikai rétegeinek. Bár a GeneralMobileNode modulban a rétegek száma rögzített, az egyes rétegekben tetszőleges számú alréteg definiálható. Például az adatkapcsolati réteg tartalmazhat LLC és MAC alrétegeket is. A GeneralTransciever almodul A GeneralTransciever almodul a mobil csomópontokban lévő adó-vevő berendezések működését valósítja meg. Az adó-vevő esetében fontos paraméter az adóés a vevőantenna teljesítménye és a nyeresége Az izotróp antennákat kivéve ezek a paraméterek irányfüggők. A GeneralEnvironmentSimulation modul a csillapítás kiszámításához lekérdezheti az adó-vevők előbb említett paramétereit. A lekérdezéshez

természetesen megadja a kívánt irányt A GeneralTransciever modul is cserélhető, a felhasználónak lehetősége nyílik az antenna-karakterisztikák definiálására, vagy akár intelligens antennák megvalósítására. A rendszer működése Induláskor az InputDataParser modul megnyitja a mozgási és forgalmi modelleket tartalmazó bemeneti fájlokat. A mozgási modellt tartalmazó fájlból beolvassa a csomópontok kezdőpozícióit, és beírja azokat a MobileNodeDatabase modul által fenntartott adatbázisba. Ezután az InputDataParser modul a fájlokat párhuzamosan olvasva elkezdi elküldeni az időfüggő adatokat a Scheduler modulnak A Scheduler modul mind a mozgási, mind a forgalmi adatokból csak konstans számút ütemez be. Ha a beütemezett adatok száma eléri ezt az értéket, akkor nem fogad el több adatot az InputDataParser modultól, csak amikor a beütemezett adatok közül egy vagy több elküldésre kerül Az InputDataParser modul ilyenkor elkezd

várakozni egészen az új szabad jelzésig A Scheduler a beütemezett adatokat a megfelelő időpontban továbbítja a rendeltetési helyükre: a mozgási adatokat a MobileNodeDatabase modulnak, míg a forgalmi adatokat a megfelelő csomópontoknak. Ha a MobileNodeDatabase modulhoz megérkezik egy mozgási adatokat tartalmazó üzenet, akkor frissíti az adatbázis tartalmát az új adatokkal. Amikor forgalmi adatokat tartalmazó üzenetek érkeznek a MobileNode modulhoz, a modul azonnal továbbítja azokat az Application almoduljához. Az Application almodul előállítja az elküldendő adatcsomagot, majd továbbítja azt a hálózati réteget megvalósító almodulnak. A hálózati réteget megvalósító modul előállítja a saját protokoll adategységeit (PDU), majd az alrétegein keresztül elküldi azokat az adatkapcsolati réteget megvalósító modul számára. Ez a modul szintén előállítja a saját protokoll adategységeit, amelyek aztán a fizikai réteget

megvalósító modulhoz érkeznek. A fizikai réteg ezután a Transcievernek küldi az adatokat, amely kerettovábbítási kérelmek formájában elküldi a kereteket az EnvironmentSimulation modulnak. Az EnvironmentSimulation modul kiválasztja a Transciever által meghatározott csatornát, majd minden egyes csomópontra (mint célra) kiszámolja a csatorna csillapítását, a keret késleltetését és kezdeti bithiba-valószínűségét. Ehhez felhasználja a forrás és cél csomópontok adó-vevőinek teljesítmény paramétereit Amennyiben a csillapítás a csatornára megadott határérték alatt marad, a keret bekerül egy átmeneti tárolóba a kiszámított késleltetés idejére. Amennyiben egyidőben több csomópont is forgalmaz, az átmeneti tárolóban lévő keretekre additív jellegű hibavalószínűségek számolódnak. Minden keret esetében a célcsomópont és a zavaró adó között számítódik ki a csillapítás, majd pedig a hibavalószínűség, ami

azután hozzáadódik a keret aktuális hibavalószínűségéhez. Amikor lejár az adott keretre számított késleltetési idő, a keret kikerül az átmeneti tárolóból, majd az „összegyűjtött” bithiba-valószínűség alapján az EnvironmentSimulation modul „elrontja” a bitjeit. Végül, a keret továbbításra kerül a célcsomópont felé A célcsomóponthoz történő megérkezéskor a csomagok a különböző rétegeken keresztül feljutnak az alkalmazási rétegig, ahol a Logwriter modul szolgáltatásainak igénybe vételével megtörténhet az esemény rögzítése. Alkalmazott routing protokollok A szimulációs környezetben eddig a Flood, a DSR és az OLSR protokollok kerültek implementálásra a NetworkLayer almodulban. A továbbiakban a három protokoll rövid ismertetése következik Elárasztás (Flooding) Az elárasztás a legegyszerűbb reaktív útvonalválasztó protokoll. Az algoritmus lényege, hogy minden csomópont a hozzá beérkezett

csomagokat minden szomszédjának továbbküldi. Ez a módszer nagyszámú kettőzött csomagot eredményez a hálózatban, ezért a forráscsomópont az azonosítóját és egy sorszámot tesz bele minden csomagba, így a többi csomópont ellenőrzi, hogy korábban továbbította-e már ezt az üzenetet vagy sem. Az elárasztás előnye, hogy mindig a legrövidebb utat választja, mert az összes lehetséges utat egyszerre választja. Hátrány viszont, hogy a – sorszámozás használata ellenére – sok csomag miatt a hálózat átbocsátóképessége jelentősen lecsökken. Dinamikus útvonalválasztó protokoll (DSR) A DSR (Dynamic Source Routing) protokoll esetén a hálózat minden csomópontja egy útvonal gyorsítótárat (routing cache) tart fenn, amiben az éppen használt utakat tárolják. A tárat folyamatosan frissítik minden új útvonal esetén A protokollnak két fő fázisa van: az útvonal felderítés (route discovery) és az útvonal karbantartás (route

maintenance). Ha egy csomópont üzenetet akar küldeni, akkor először a saját útvonal gyorsítótárát vizsgálja meg, hogy van-e benne a célcsomópontra vonatkozó információ. Amennyiben van, akkor ezen az útvonalon elküldi a csomagot, ha nincs, akkor útvonalkérő (route request) csomagot küld egy útvonal felderítésére. A csomag a forrás és a cél címét tartalmazza, valamint egy egyedi azonosító számot. A csomagnak van egy útvonal információ (route record) része, ami a bejárt útvonalat tartalmazza, a csomópontok, melyek a csomagot megkapják, ide teszik be a címüket. Itt is, mint az előbb bemutatott AODV protokollnál egy ilyen kérést a csomópontok csak egyszer küldenek tovább. A célcsomópont vagy egy közbenső csomópont, amelyik útvonal gyorsítótára tartalmaz érvényes utat a célig válaszüzenetet (route reply) küld. Amennyiben egy közbenső csomópont talál utat a célcsomópontig, az útvonal információba kell befűznie a

célig vezető útvonalat. Szimmetrikus kapcsolat esetén a válaszüzenet ugyanazt az utat járja be, mint az útvonalkérő üzenet, egyébként pedig útvonalat kell keresnie. Az összeköttetések hibáinak felderítésére és a gyorsítótárak konzisztenciájának megtartására a protokoll hibacsomagokat (route error packet) és nyugtákat (acknowledgement) használ. Javított kapcsolatállapot alapú forgalomirányítás (OLSR) Az OLSR (Optimized Link State Routing) protokoll alapja a klasszikus kapcsolatállapot alapú forgalomirányítás. A klasszikus kapcsolatállapot alapú útvonalválasztó protokollban a csomópontok HELLO csomagokkal felkutatják a szomszé- dos csomópontokat, ECHO csomagokkal pedig a késleltetést határozza meg minden szomszédra vonatkozóan. Ezek után egy csomópont az ún kapcsolatállapot csomagját – melyben a szomszédok-vonali késleltetés párok listája van – az elárasztás módszerével osztja szét a hálózatban. A

csomópontok a legrövidebb utak kiszámításához a Dijkstra-algoritmust használják, és ennek eredménye alapján töltik ki a forgalomirányító táblájukat. Az OLSR protokoll oly módon kíván javítani az előbb leírt algoritmuson, hogy a hálózatban az elárasztás okozta többletforgalmat csökkenti. A broadcast üzeneteket nem továbbítja minden csomópont, mint az elárasztásnál, és a csomópontok nem az összes hozzá kapcsolódó vonalra vonatkozó információt terjesztik szét a hálózatban. A protokollban kulcsfogalom a multipoint relays (MPRs) Ez jelöli azokat a csomópontokat, amelyek a broadcast üzeneteket továbbítják. Egy csomópont kijelöli, hogy mely szomszédos csomópontok továbbítsák a tőle kapott üzeneteket; e szomszédok halmazát nevezzük a csomópont MPR halmazának. A csomópontok MPR-nek csak olyan szomszédokat választhatnak, melyekkel szimmetrikus kapcsolatban állnak. Egy csomópont azon szomszédai, akik nem tartoznak az MPR

halmazába, azok is megkapják és feldolgozzák a csomópont broadcast üzeneteit, de nem továbbítják, így jól kiválasztott MPR halmazok esetén a hálózat többletforgalma jóval kisebb, mint elárasztást alkalmazva. További javítást jelent még, hogy egy csomópont csak arra vonatkozó információt közöl, hogy mely csomópontok jelölték őt MPR-nek. Ellenőrző kérdések 1. Mik az előnyei az ad hoc hálózatoknak? 2. Mire használható az OMNeT++ szimulátor? 3. Soroljon fel néhány az OMNeT++ által támogatott osztályt! Mire szolgálnak ezek? 4. Vázolja fel az ad hoc szimulátor moduláris felépítését! 5. Mik az egyes modulok feladatai? 6. Vázolja fel a rendszer működését! Mérési feladatok 1. Futassa le az ad hoc szimulációt a mérésvezető által megadott bemeneti állományokkal a Flood és a DSR routing protokollokkal, figyelje meg a kimenetként kapott állományokat 2. Hozzon létre 5 csomópontból álló hálózat bemeneti állományait

a példa fájlok mintájára a következők szerint: • Mindegyik álljon, egymásnak küldjenek üzeneteket • Egy csomópont mozog, a mozgó küld vagy a többiek küldenek neki • Mindegyik mozog, egymásnak küldenek üzeneteket Figyeljenenk oda, hogy ne mozogjanak túl gyorsan a csomópontok egymáshoz viszonyítva, gondolják át, hogy miért fontos követelmény ez. Találjanak olyan modelleket, amikor a csomópontok megkapják az üzeneteket és olyat, amikor nem. A statisztikai kimeneti állományban figyeljék meg, hogy az elküldött üzenetek közül mennyi érkezett meg a különböző mozgási és forgalmi modellek esetében. 3. A DSR és a Flood protokoll összehasonlítása a hálózati forgalom szempontjából (az adatokat a statisztikai állományban találják) 4. Az APPLICATIONxls alapján hasonlítsák össze a DSR és a Flood protokollban az üzenetek késleltetését