ΠΕΡΙΕΧΟΜΕΝΑ. 2. HCF Controlled Channel Access..σελ Classifier module..σελ MAC module...σελ. 23

Ευχαριστίες Θα θέλαµε να ευχαριστήσουµε θερµά τον κ. Πέτρο Νικοπολιτίδη, Λέκτορα του Τµήµατος Πληροφορικής της Σχολής Θετικών Επιστηµέων του Αριστοτελείου Πανεπιστηµίου Θεσσαλονίκης και επιβλέποντα της εργασίας µας, για την πολύτιµη καθοδήγηση του και την υποστήριξη που µας παρείχε καθ όλη τη διάρκεια ανάπτυξης της. Επίσης θα θέλαµε να ευχαριστήσουµε θερµά την εταιρεία ANTCOR για την βοήθεια που µας προσέφερε και ιδιαίτερα τον κ. Μπουρτούνη ηµήτριο, στέλεχος και project manager της εταιρείας. 1

ΠΕΡΙΕΧΟΜΕΝΑ 1. Γενικά για το 802.11...σελ. 4 1.1 Εισαγωγή...σελ. 4 1.2 Η αρχιτεκτονική του 802.11.σελ. 4 1.3 Τρόποι λειτουργίας του 802.11.σελ. 5 1.4 Το πρωτόκολλο 802.11..σελ. 7 1.5 Το MAC πλαίσιο του 802.11.σελ. 7 1.6 Το 802.11 PHY υποεπίπεδο.σελ. 10 1.7 Το πρωτόκολλο υποεπιπέδου MAC του 802.11 σελ. 12 1.8 Υπηρεσίες.σελ. 17 2. HCF Controlled Channel Access..σελ. 19 2.1 Περιγραφή του HCF Controlled Channel Access...σελ. 19 2.2 Η αρχιτεκτονική του λογισµικού...σελ. 22 2.2.1 Classifier module..σελ. 22 2.2.2 MAC module...σελ. 23 2.2.3 HCCA Scheduler Module...σελ. 29 3. Περιγραφή του Polling πρωτοκόλλου...σελ. 31 3.1 DPOLLING Πρωτόκολλο...σελ. 31 3.1.1 Ταξινόµηση πακέτων στον BS.σελ. 31 3.1.2 Ταξινόµηση πακέτων στον SS.σελ. 32 3.1.3 ιαφορές σε σχέση µε τον DCF του 802.11...σελ. 32 3.1.4 Τρόπος λειτουργίας πρωτοκόλλου..σελ. 32 3.1.5 Scheduling.σελ. 33 3.1.6 οµή-λειτουργικότητα πακέτων σελ. 34 STATE MACHINE του BS...σελ. 38 STATE MACHINE του SS...σελ. 44 2

4. Προσοµοίωση και Προσοµοιωτές ικτύων.σελ. 45 4.1 Προσοµοίωση ικτύων σελ.45 4.2 Προσοµοιωτής ικτύων..σελ. 46 4.3 ns (προσοµοιωτής)...σελ. 47 5. Μετρήσεις Αποτελέσµατα...σελ. 49 5.1 Σύγκριση 802.11-DPolling...σελ. 51 5.1.1 Παραδείγµατα FTP κίνησης χωρίς παρουσία θορύβο.....σελ. 51 5.1.2 Παραδείγµατα FTP κίνησης µε παρουσία θορύβου.....σελ. 65 5.1.3 Παραδείγµατα VoIP και FTP κίνησης χωρίς παρουσία θορύβου...σελ. 79 5.1.4 Παραδείγµατα VoIP και FTP κίνησης µε παρουσία θορύβου...σελ. 98 5.2 Σύγκριση HCCA-DPolling...σελ. 117 5.2.1 Παραδείγµα UDP κίνησης.. σελ. 117 5.2.2 Παράδειγµα VoIP και FTP κίνησης.. σελ. 120 6. Συµπεράσµατα...σελ. 126 7. Πιθανές Βελτιστοποιήσεις...σελ. 127 Βιβλιογραφία.σελ. 128 3

1. Γενικά για το 802.11 1.1 Εισαγωγή Το πρωτόκολλο IEEE 802.11 είναι µια τεχνολογία πρόσβασης στο δίκτυο για την παροχή συνδεσιµότητας µεταξύ ασύρµατων σταθµών και ενσύρµατων υποδοµών δικτύωσης. Με την ανάπτυξη του πρωτοκόλλου IEEE 802.11 και των σχετικών τεχνολογιών, επιτράπηκε στον µετακινούµενο χρήστη να κινείται σε διάφορα µέρη π.χ. αίθουσες συνεδριάσεων, διάδροµοι, λόµπι, καφετέριες, τάξεις, και ούτω καθ' εξής, και να έχει ακόµα πρόσβαση στα δεδοµένα του δικτύου. Επίσης, πέρα από τον εταιρικό εργασιακό χώρο, επιτράπηκε η πρόσβαση στο ιαδίκτυο, και ακόµη και οι εταιρικές ιστοσελίδες µπορούν να παρασχεθούν µέσω των δηµόσιων ασύρµατων «hot spot» δικτύων. Οι αερολιµένες, τα εστιατόρια, οι σιδηροδροµικοί σταθµοί, και οι πιο κοινές περιοχές σε όλες τις πόλεις µπορούν να διαµορφωθούν για να παρέχουν αυτήν την υπηρεσία. 1.2 Η αρχιτεκτονική του 802.11 Η λογική αρχιτεκτονική του 802.11 περιέχει διάφορα κύρια συστατικά: σταθµός (station ή STA), ασύρµατο σηµείο πρόσβασης (Wireless Access Point ή AP), ανεξάρτητο σύνολο βασικών υπηρεσιών (Independent Basic Service Set ή IBSS), σύνολο βασικών υπηρεσιών (Basic Service Set ή BSS), σύστηµα διανοµής (Distribution System ή DS), και εκτεταµένο σύνολο υπηρεσιών (Extended Service Set ή ESS). Μερικά από τα συστατικά της λογικής αρχιτεκτονικής του 802.11 αντιστοιχούν άµεσα σε συσκευές υλικού (hardware), όπως οι STAs και οι ασύρµατοι APs. Ο ασύρµατος STA περιέχει µια adapter card, µια PC card, ή µια ενσωµατωµένη συσκευή για να παρέχει ασύρµατη συνδεσιµότητα. Ο ασύρµατος AP λειτουργεί ως γέφυρα µεταξύ των ασύρµατων STAs και του υπάρχοντος υποβάθρου του δικτύου, για την πρόσβαση στο δίκτυο. Ένα IBSS είναι ένα ασύρµατο δίκτυο, που αποτελείται από τουλάχιστον δύο STAs, χρησιµοποιούµενο οπουδήποτε η πρόσβαση σε ένα DS δεν είναι διαθέσιµη. Ένα IBSS επίσης αναφέρεται µερικές φορές ως ad hoc ασύρµατο δίκτυο. Ένα BSS είναι ένα ασύρµατο δίκτυο, που αποτελείται από ένα µοναδικό ασύρµατο AP που υποστηρίζει έναν ή πολλαπλούς ασύρµατους πελάτες (clients). Ένα BSS επίσης αναφέρεται µερικές φορές ως infrastructure ασύρµατο δίκτυο. Όλοι οι STAs σε ένα BSS επικοινωνούν µέσω του AP. Ο AP παρέχει συνδεσιµότητα στο ενσύρµατο τοπικό LAN και παρέχει τη λειτουργία του bridging όταν ένας STA αρχίζει την επικοινωνία µε έναν άλλο STA ή µε έναν κόµβο στο DS. Ένα ESS είναι ένα σύνολο δύο ή περισσοτέρων ασύρµατων APs που συνδέονται µε το ίδιο ενσύρµατο δίκτυο που καθορίζει ένα ενιαίο λογικό τµήµα δικτύου οριοθετηµένο από έναν δροµολογητή (επίσης γνωστό ως subnet). Οι APs πολλαπλών BSSs διασυνδέονται από το DS. Αυτό επιτρέπει την µεταφερσιµότητα, επειδή οι STAs µπορούν να µετακινηθούν από ένα BSS σε ένα 4

άλλο BSS. Οι APs µπορούν να διασυνδέονται ενσύρµατα ή ασύρµατα, εντούτοις, τις περισσότερες φορές συνδέονται µε καλώδιο. Το DS είναι το λογικό συστατικό που χρησιµοποιείται για να διασυνδέσει τα BSSs. Το DS παρέχει τις υπηρεσίες διανοµής για να επιτρέψει το roaming των STAs µεταξύ των BSSs. Το επόµενο σχήµα δείχνει την αρχιτεκτονική του 802.11. Η αρχιτεκτονική του 802.11 1.3 Τρόποι λειτουργίας του 802.11 Το IEEE 802.11 καθορίζει τους ακόλουθους τρόπους λειτουργίας: Infrastructure Mode Ad hoc Mode Και στους δύο τρόπους λειτουργίας, ένα Service Set Identifier (SSID), επίσης γνωστό και ως wireless network name, προσδιορίζει το ασύρµατο δίκτυο. Το SSID είναι ένα όνοµα που διαµορφώνεται στον ασύρµατο AP (για το infrastructure mode) ή ένας αρχικός ασύρµατος client (για το ad hoc mode) που προσδιορίζει το ασύρµατο δίκτυο. Το SSID προβάλλεται περιοδικά από τον ασύρµατο AP ή τον αρχικό ασύρµατο client χρησιµοποιώντας ένα ειδικό MAC 802.11 frame διαχείρισης γνωστό ως beacon frame. 802.11 Infrastructure Mode Στον Infrastructure Mode, υπάρχει τουλάχιστον ένας ασύρµατο AP και ένας ασύρµατος client. Ο ασύρµατος client χρησιµοποιεί τον ασύρµατο AP για να έχει πρόσβαση στους πόρους ενός παραδοσιακού ενσύρµατου δικτύου. Το ενσύρµατο δίκτυο µπορεί να είναι ένα intranet οργάνωσης ή το ιαδίκτυο, ανάλογα µε την 5

τοποθέτηση του ασύρµατου AP. Ένα εκτεταµένο σύνολο υπηρεσιών (Extended Service Set ή ESS) παρουσιάζεται στο ακόλουθο σχήµα. 802.11 Infrastructure Mode 802.11 Ad Hoc Mode Στον Ad Hoc Mode, οι ασύρµατοι clients επικοινωνούν άµεσα ο ένας µε τον άλλον χωρίς τη χρήση ενός ασύρµατου AP, όπως φαίνεται στο ακόλουθο σχήµα. 802.11 Wireless Clients in Ad Hoc Mode Ο Ad hoc mode καλείται επίσης peer-to-peer mode. Οι ασύρµατοι clients στον ad hoc mode διαµορφώνουν ένα ανεξάρτητο σύνολο βασικών υπηρεσιών (Independent Basic Service Set ή IBSS). Ένας από τους ασύρµατους clients, ο πρώτος ασύρµατος client στο IBSS, αναλαµβάνει µερικές από τις ευθύνες του ασύρµατου AP. Αυτές οι ευθύνες περιλαµβάνουν την περιοδική beaconing process και το authentication των νέων µελών. Αυτός ο ασύρµατος client δεν ενεργεί ως γέφυρα για επαναµετάδοση πληροφοριών µεταξύ των ασύρµατων clients. Ο Ad hoc mode χρησιµοποιείται για να συνδέσει ασύρµατους clients όταν δεν υπάρχει παρόν κανένας ασύρµατος AP. Οι ασύρµατοι clients πρέπει να διαµορφωθούν ρητά ώστε να χρησιµοποιήσουν τον Ad hoc mode. Μπορεί να υπάρξει ένα µέγιστο εννέα µελών σε ένα ad hoc 802.11 ασύρµατο δίκτυο. 6

1.4 Το πρωτόκολλο 802.11 Η IEEE 802 επιτροπή προτύπων καθορίζει δύο χωριστά επίπεδα, τον έλεγχο λογικού συνδέσµου (Logical Link Control ή LLC) και τον έλεγχο προσπέλασης µέσων (Media Access Control ή MAC), για το επίπεδο συνδέσµου µετάδοσης δεδοµένων (Data Link Layer) του µοντέλου OSI. Το IEEE 802.11 ασύρµατο πρότυπο καθορίζει τις προδιαγραφές για το φυσικό επίπεδο και το υποεπίπεδο ελέγχου προσπέλασης µέσων (MAC) που επικοινωνεί µέχρι το επίπεδο LLC, όπως φαίνεται στο ακόλουθο σχήµα. 802.11 and OSI model Όλα τα συστατικά στην αρχιτεκτονική του 802.11 περιέρχονται είτε στο υποεπίπεδο ελέγχου προσπέλασης µέσων (MAC) του επιπέδου συνδέσµου µετάδοσης δεδοµένων είτε στο φυσικό επίπεδο. 1.5 Το MAC πλαίσιο του 802.11 Το MAC πλαίσιο του 802.11, όπως φαίνεται στο ακόλουθο σχήµα, αποτελείται από έναν MAC header, το σώµα του πλαισίου, και µια ακολουθία ελέγχου πλαισίου (Frame Check Sequence ή FCS). Οι αριθµοί στο ακόλουθο σχήµα αντιπροσωπεύουν τον αριθµό των bytes για κάθε πεδίο. 802.11 MAC Frame Format Πεδίο ελέγχου πλαισίου Το πεδίο ελέγχου πλαισίου, που παρουσιάζεται στο ακόλουθο σχήµα, περιέχει τις πληροφορίες ελέγχου που χρησιµοποιούνται για τον καθορισµό του τύπου του MAC 7

πλαισίου του 802.11 και την παροχή πληροφοριών απαραίτητων για τα ακόλουθα πεδία ώστε να καταλάβουν πως να χειριστούν το MAC πλαίσιο. Οι αριθµοί στο ακόλουθο σχήµα αντιπροσωπεύουν τον αριθµό των bits για κάθε πεδίο. Frame Control Field Μια περιγραφή κάθε υποπεδίου του πεδίου ελέγχου πλαισίου είναι η ακόλουθη: Το υποπεδίο της έκδοσης του πρωτοκόλλου παρέχει τη τρέχουσα έκδοση του πρωτοκόλλου 802.11 που χρησιµοποιείται. Λαµβάνοντας το οι STAs χρησιµοποιούν αυτή την τιµή για να καθορίσουν εάν υποστηρίζεται η έκδοση του πρωτοκόλλου του λαµβανόµενου πλαισίου. Τα υποπεδία του τύπου και του δευτερεύοντος τύπου καθορίζουν τη λειτουργία του πλαισίου. Υπάρχουν τρία διαφορετικά πεδία για τον τύπο του πλαισίου: έλεγχος, δεδοµένα, και διαχείριση. Υπάρχουν πολλαπλά πεδία για τον δευτερεύων τύπο για κάθε τύπο πλαισίου. Κάθε δευτερεύων τύπος καθορίζει τη συγκεκριµένη λειτουργία που εκτελείται για το σχετικό τύπο πλαισίου. Τα υποπεδία «προς DS» και «από DS» δείχνουν εάν το πλαίσιο πηγαίνει προς το DS ή βγαίνει από το DS (κατανεµηµένο σύστηµα), και χρησιµοποιούνται µόνο στα πλαίσια του τύπου δεδοµένων των STAs που συνδέονται µε ένα AP. Το υποπεδίο «περισσότερα θραύσµατα» δείχνει εάν περισσότερα θραύσµατα του πλαισίου, είτε τύπου δεδοµένων είτε τύπου διαχείρισης, πρόκειται να ακολουθήσουν. Το υποπεδίο «επανάληψη» δείχνει εάν το πλαίσιο αναµεταδίδεται ή όχι, είτε για τύπους δεδοµένων είτε για τύπους διαχείρισης πλαισίου. Το υποπεδίο «διαχείριση ενέργειας» δείχνει εάν ο STA που αποστέλλει είναι σε active mode ή power-save mode. Το υποπεδίο «περισσότερα δεδοµένα» δείχνει σε έναν STA σε power-save mode ότι ο AP έχει περισσότερα πλαίσια για αποστολή. Χρησιµοποιείται επίσης για APs για να δείξει ότι πρόσθετα broadcast/multicast πλαίσια πρόκειται να ακολουθήσουν. Το υποπεδίο «WEP» δείχνει εάν η κρυπτογράφηση και το authentication χρησιµοποιούνται στο πλαίσιο ή όχι. Μπορεί να τεθεί για όλα τα πλαίσια δεδοµένων και τα πλαίσια διαχείρισης, τα οποία θέτουν τον δευτερεύων τύπο στο authentication. 8

Το υποπεδίο «σειρά» δείχνει ότι όλα τα λαµβανόµενα πλαίσια δεδοµένων πρέπει να υποβληθούν σε επεξεργασία µε τη σειρά. Πεδίο Duration/ID Αυτό το πεδίο χρησιµοποιείται για όλα τα πλαίσια του τύπου ελέγχου, εκτός από αυτά µε δευτερεύων τύπο Power Save (PS) Poll, για να δείξει την εναποµείνουσα διάρκεια που απαιτείται για να λάβει την µετάδοση του επόµενου πλαισίου. Όταν ο δευτερεύων τύπος είναι PS Poll, το πεδίο περιέχει την Association Identity (AID) του STA που µεταδίδει. Πεδία ιεύθυνσης Ανάλογα µε τον τύπο πλαισίου, τα τέσσερα πεδία διεύθυνσης περιέχουν έναν συνδυασµό των ακόλουθων τύπων διεύθυνσης: BSS Identifier (BSSID). Το BSSID προσδιορίζει µοναδικά κάθε BSS. Όταν το πλαίσιο είναι από έναν STA σε ένα infrastructure BSS, το BSSID είναι η MAC διεύθυνση του AP. Όταν το πλαίσιο είναι από έναν STA σε ένα IBSS, το BSSID είναι η τυχαία παραγόµενη, τοπικά διαχειριζόµενη MAC διεύθυνση του STA που άρχισε το IBSS. Destination Address (DA). Η DA δείχνει τη MAC διεύθυνση του τελικού προορισµού που θα λάβει το πλαίσιο. Source Address (SA). Η SA δείχνει τη MAC διεύθυνση της αρχικής πηγής που δηµιούργησε και εν συνεχεία µετέδωσε το πλαίσιο. Receiver Address (RA). Η RA δείχνει τη MAC διεύθυνση του επόµενου άµεσου STA στο ασύρµατο µέσο που θα λάβει το πλαίσιο. Transmitter Address (TA). Η TA δείχνει τη MAC διεύθυνση του STA που µετέδωσε το πλαίσιο επάνω στο ασύρµατο µέσο. Έλεγχος ακολουθίας Το πεδίο ελέγχου ακολουθίας περιέχει δύο υποπεδία, το πεδίο Fragment Number και το πεδίο Sequence Number, όπως φαίνεται στο ακόλουθο σχήµα. Sequence Control Field Μια περιγραφή κάθε υποπεδίου του πεδίου ελέγχου ακολουθίας είναι η ακόλουθη: 9

Ο Αριθµός Ακολουθίας (Sequence Number) δείχνει τον αριθµό ακολουθίας κάθε πλαισίου. Ο αριθµός ακολουθίας είναι ο ίδιος για κάθε πλαίσιο που στέλνεται ως θραύσµα τεµαχισµένου πλαισίου, διαφορετικά, ο αριθµός αυξάνεται κατά ένα µέχρι να φτάσει 4095, όταν ξαναρχίζει και πάλι στο µηδέν. Ο Αριθµός Θραύσµατος (Fragment Number) δείχνει τον αριθµό κάθε πλαισίου που στέλνεται ως θραύσµα τεµαχισµένου πλαισίου. Η αρχική τιµή τίθεται 0 και έπειτα αυξάνεται κατά ένα για κάθε επόµενο πλαίσιο που στέλνεται από το τεµαχισµένο πλαίσιο. Σώµα πλαισίου Το σώµα του πλαισίου περιέχει τα δεδοµένα ή τις πληροφορίες που περιλαµβάνονται είτε στα πλαίσια του τύπου διαχείρισης είτε στα πλαίσια του τύπου δεδοµένων. Ακολουθία Ελέγχου Πλαισίου Ο STA που µεταδίδει χρησιµοποιεί έναν κυκλικό έλεγχο πλεονασµού (Cyclic Redundancy Check ή CRC) σε όλα τα πεδία του MAC header και του πεδίου του σώµατος του πλαισίου για να παράγει την τιµή της FCS. Έπειτα, ο STA που λαµβάνει χρησιµοποιεί τον ίδιο CRC υπολογισµό για να καθορίσει την τιµή του δικού του πεδίου FCS για να ελέγξει εάν οποιαδήποτε λάθη εµφανίστηκαν ή όχι στο πλαίσιο, κατά τη διάρκεια της µετάδοσης. 1.6 Το 802.11 PHY υποεπίπεδο Στο φυσικό υποεπίπεδο (PHY), το IEEE 802.11 καθορίζει µια σειρά τεχνικών κωδικοποίησης και µετάδοσης για τις ασύρµατες επικοινωνίες, εκ των οποίων οι πιο κοινές είναι η Frequency Hopping Spread Spectrum (FHSS), η Direct Sequence Spread Spectrum (DSSS), και η Orthogonal Frequency Division Multiplexing (OFDM) τεχνική µετάδοσης. Το ακόλουθο σχήµα παρουσιάζει τα πρότυπα 802.11, 802.11b, 802.11a, και 802.11g που υπάρχουν στο υποεπίπεδο PHY. Αυτά τα πρότυπα περιγράφονται στα τµήµατα που ακολουθούν. Standards for 802.11 at the PHY Layer IEEE 802.11 Το bit rate για τo αρχικό IEEE 802.11 πρότυπο είναι 2 Mbps χρησιµοποιώντας την τεχνική µετάδοσης FHSS και την S-Band Industrial, Scientific, and Medical (ISM) ζώνη συχνοτήτων, η οποία λειτουργεί στο φάσµα συχνοτήτων από 2.4 έως 2.5 Ghz. 10

Εντούτοις, σε λιγότερο ιδανικές συνθήκες, χρησιµοποιείται µια χαµηλότερη ταχύτητα bit rate της τάξης του 1 Mbps. 802.11b Η σηµαντικότερη βελτίωση του IEEE 802.11 από το IEEE 802.11b είναι η τυποποίηση του φυσικού επιπέδου ώστε να υποστηρίζει υψηλότερα bit rates. Το IEEE 802.11b υποστηρίζει δύο επιπρόσθετες ταχύτητες, αυτές των 5.5 Mbps και των 11 Mbps, χρησιµοποιώντας την S-Band ISM. Η τεχνική µετάδοσης DSSS χρησιµοποιείται προκειµένου να παρασχεθούν τα υψηλότερα bit rates. Το bit rate των 11 Mbps είναι επιτεύξιµο σε ιδανικές συνθήκες. Σε λιγότερο ιδανικές συνθήκες, χρησιµοποιούνται οι πιο αργές ταχύτητες των 5.5 Mbps, 2 Mbps, και 1 Mbps. Σηµείωση Το 802.11b χρησιµοποιεί την ίδια ζώνη συχνοτήτων µε αυτήν που χρησιµοποιείται στους φούρνους µικροκυµάτων, τα ασύρµατα τηλέφωνα, τα baby monitors, τις ασύρµατες βιντεοκάµερες, και τις συσκευές Bluetooth. 802.11a Το IEEE 802.11a (το πρώτο πρότυπο που επικυρώθηκε, αλλά µόλις τώρα άρχισε να επεκτείνεται και να πωλείται µαζικά) λειτουργεί σε ένα bit rate της τάξεως των 54 Mbps και χρησιµοποιεί την C-Band ISM, η οποία λειτουργεί στο φάσµα συχνότητων από 5.725 έως 5.875 Ghz. Αντί του DSSS, το 802.11a χρησιµοποιεί την OFDM, η οποία επιτρέπει στα δεδοµένα να µεταδοθούν παράλληλα από υποσυχνότητες, και παρέχει µεγαλύτερη αντίσταση στις παρεµβολές και µεγαλύτερη ρυθµοαπόδοση. Αυτή η τεχνολογία υψηλής ταχύτητας επιτρέπει την ασύρµατη δικτύωση LAN για να αποδώσει καλύτερα τις εφαρµογές βίντεο και σύσκεψης. Επειδή δεν είναι στις ίδιες συχνότητες µε άλλες S-Band συσκευές (όπως τα ασύρµατα τηλέφωνα), η OFDM και το IEEE 802.11a παρέχουν ταυτόχρονα ένα υψηλότερο bit rate και ένα καθαρότερο σήµα. Το bit rate των 54 Mbps είναι επιτεύξιµο σε ιδανικές συνθήκες. Σε λιγότερο ιδανικές συνθήκες, χρησιµοποιούνται οι πιο αργές ταχύτητες των 48 Mbps, 36 Mbps, 24 Mbps, 18 Mbps, 12 Mbps, και 6 Mbps. 802.11g Το IEEE 802.11g λειτουργεί σε ένα bit rate της τάξης των 54 Mbps, αλλά χρησιµοποιεί την S-Band ISM και την OFDM. Το 802.11g είναι επίσης συµβατό προς τα πίσω µε το 802.11b και µπορεί να λειτουργήσει στα bit rates του 802.11b και µε τη χρήση DSSS. Οι 802.11g adapters ασύρµατου δικτύου µπορούν να συνδεθούν µε έναν ασύρµατο AP του 802.11b, και οι 802.11b adapters ασύρµατου δικτύου µπορούν να συνδεθούν µε έναν ασύρµατο AP του 802.11g. Κατά συνέπεια, το 802.11g παρέχει µια πορεία µετατροπής για τα δίκτυα 802.11b σε µια συµβατής συχνότητας τυποποιηµένη τεχνολογία µε ένα υψηλότερο bit rate. Οι υπάρχοντες adapters ασύρµατου δικτύου του 802.11b δεν µπορούν να αναβαθµιστούν στο 802.11g µε την ενηµέρωση του firmware του adapter, αλλά πρέπει να αντικατασταθούν. Αντίθετα από τη µετατροπή από 802.11b στο 802.11a (στο οποίο όλοι οι adapters δικτύου και 11

στους ασύρµατους clients και στους ασύρµατους APs πρέπει να αντικατασταθούν συγχρόνως), η µετατροπή από το 802.11b στο 802.11g µπορεί να γίνει αυξητικά. Όπως στο 802.11a, το 802.11g χρησιµοποιεί 54 Mbps σε ιδανικές συνθήκες και τις πιο αργές ταχύτητες των 48 Mbps, 36 Mbps, 24 Mbps, 18 Mbps, 12 Mbps, και 6 Mbps σε λιγότερο ιδανικές συνθήκες. 1.7 Το πρωτόκολλο υποεπιπέδου MAC του 802.11 Για να ξεκινήσουµε, υπάρχει το πρόβληµα κρυφού σταθµού (Hidden Node), το οποίο απεικονίζεται στην Εικόνα 1(α). Αφού όλοι οι σταθµοί δεν είναι εντός της εµβέλειας όλων των άλλων, οι µεταδόσεις που πραγµατοποιούνται σε ένα τµήµα µιας κυψέλης µπορεί να µη λαµβάνονται σε άλλα σηµεία στην ίδια κυψέλη. Στο παράδειγµα αυτό, ο σταθµός C µεταδίδει στο σταθµό Β. Αν ο Α ανιχνεύσει το κανάλι, δεν θα ακούσει τίποτα και θα συµπεράνει εσφαλµένα ότι µπορεί να αρχίσει να µεταδίδει στον Β. Υπάρχει επίσης το αντίστροφο πρόβληµα, το πρόβληµα του εκτεθειµένου σταθµού (Exposed Node), το οποίο απεικονίζεται στην Εικόνα 1(β). Εδώ ο Β θέλει να στείλει στον C, έτσι ανιχνεύει το κανάλι. Όταν ακούσει µια µετάδοση, συµπεραίνει εσφαλµένα ότι δεν πρέπει να στείλει στον C, αν και ο Α µεταδίδει στον D (που δεν φαίνεται). Επιπλέον, οι περισσότεροι ποµποδέκτες είναι ηµιαµφίδροµοι, γεγονός που σηµαίνει ότι δεν µπορούν ταυτόχρονα να µεταδίδουν και να ανιχνεύουν ριπές θορύβου σε µία µόνο συχνότητα. Εξαιτίας αυτών των προβληµάτων, το 802.11 δεν χρησιµοποιεί το CSMA/CD, όπως το Ethernet. Για να αντιµετωπιστεί το πρόβληµα αυτό, το 802.11 υποστηρίζει δύο καταστάσεις λειτουργίας. Η πρώτη, που ονοµάζεται Κατανεµηµένη Λειτουργία Συντονισµού ή DCF (Distributed Coordination Function), δεν χρησιµοποιεί κάποιο είδος κεντρικού ελέγχου (από αυτή την άποψη είναι παρόµοια µε το Ethernet). Η άλλη, που ονοµάζεται Σηµειακή Λειτουργία Συντονισµού ή PCF (Point Coordination Function), χρησιµοποιεί το σταθµό βάσης για τον έλεγχο όλων των δραστηριοτήτων στην αντίστοιχη κυψέλη του. Όλες οι υλοποιήσεις πρέπει να υποστηρίζουν την DCF, ενώ η PCF είναι προαιρετική. Θα εξετάσουµε και τις δυο καταστάσεις λειτουργίας µε τη σειρά. 12

Εικόνα 1. (a) Το πρόβληµα του κρυφού σταθµού. (b) Το πρόβληµα του εκτεθειµένου σταθµού. Όταν χρησιµοποιείται η DCF, το 802.11 χρησιµοποιεί ένα πρωτόκολλο που ονοµάζεται CSMA µε Αποφυγή Συγκρούσεων ή CSMA/CA (CSMA with Collision Avoidance). Στο πρωτόκολλο αυτό χρησιµοποιείται ανίχνευση τόσο του φυσικού όσο και του εικονικού καναλιού. Το CSMA/CA υποστηρίζει δυο µεθόδους λειτουργίας. Στην πρώτη µέθοδο, όταν ένας σταθµός θέλει να µεταδώσει ανιχνεύει το κανάλι. Αν είναι αδρανές, αρχίζει να µεταδίδει. Καθώς µεταδίδει δεν ανιχνεύει το κανάλι, αλλά στέλνει ολόκληρο το πλαίσιό του, το οποίο µπορεί να καταστραφεί στον παραλήπτη λόγω παρεµβολών εκεί. Αν το κανάλι είναι απασχοληµένο, ο αποστολέας αναβάλλει τη µετάδοση µέχρι το κανάλι να γίνει αδρανές, και τότε αρχίζει να µεταδίδει. Αν συµβεί µια σύγκρουση, οι σταθµοί που συγκρούστηκαν αναµένουν ένα τυχαίο χρονικό διάστηµα, χρησιµοποιώντας τον αλγόριθµο δυαδικής εκθετικής οπισθοχώρησης του Ethernet, και ξαναδοκιµάζουν αργότερα. Ο άλλος τρόπος λειτουργίας του CSMA/CA βασίζεται στο MACAW και χρησιµοποιεί ανίχνευση του εικονικού καναλιού, όπως φαίνεται στην Εικόνα 2. Στο παράδειγµα αυτό, ο Α θέλει να στείλει στον Β. Ο C είναι ένας σταθµός εντός της εµβέλειας του Α (και πιθανόν εντός της εµβέλειας του Β, αυτό όµως δεν έχει σηµασία). Ο D είναι ένας σταθµός εντός της εµβέλειας του Β αλλά όχι εντός της εµβέλειας του Α. Το πρωτόκολλο αρχίζει όταν ο Α αποφασίσει ότι θέλει να στείλει δεδοµένα στον Β. Ξεκινά στέλνοντας ένα πλαίσιο RTS στον Β, ζητώντας άδεια να του στείλει ένα πλαίσιο. Όταν ο Β λάβει την αίτηση αυτή, µπορεί να αποφασίσει να παραχωρήσει τη ζητούµενη άδεια, οπότε επιστρέφει ένα πλαίσιο CTS. Με τη λήψη του CTS, ο Α στέλνει το πλαίσιό του και ξεκινά ένα χρονόµετρο επιβεβαίωσης. Αφού λάβει ορθά το πλαίσιο δεδοµένων, ο Β απαντά µε ένα πλαίσιο επιβεβαίωσης, ολοκληρώνοντας την ανταλλαγή. Αν το χρονόµετρο επιβεβαίωσης του Α λήξει πριν φτάσει σε αυτόν η επιβεβαίωση, ολόκληρο το πρωτόκολλο εκτελείται ξανά. 13

Εικόνα 2. Ανίχνευση εικονικού καναλιού µε το CSMA/CA Ας εξετάσουµε τώρα την ανταλλαγή αυτή από την οπτική γωνία των C και D. Ο C βρίσκεται εντός της εµβέλειας του Α, έτσι µπορεί να λάβει το πλαίσιο RTS. Αν το λάβει, αντιλαµβάνεται ότι κάποιος θα στείλει σε λίγο δεδοµένα, έτσι για το καλό όλων αποφεύγει να µεταδώσει οτιδήποτε µέχρι να ολοκληρωθεί η ανταλλαγή. Από τις πληροφορίες που παρέχονται στην αίτηση RTS µπορεί να εκτιµήσει πόσο χρόνο θα πάρει η ανταλλαγή, συµπεριλαµβανοµένης της τελικής επιβεβαίωσης, έτσι ενεργοποιεί για τον εαυτό του ένα σήµα ότι το εικονικό κανάλι είναι απασχοληµένο, γεγονός που σηµειώνεται στην Εικόνα 2 ως ιάνυσµα Εκχώρησης ικτύου ή NAV (Network Allocation Vector). Ο D δεν ακούει το µήνυµα RTS, ακούει όµως το CTS, έτσι ενεργοποιεί και αυτός από την πλευρά του το σήµα NAV. Σηµειώστε ότι τα σήµατα NAV δεν µεταδίδονται. Είναι απλώς εσωτερικές υπενθυµίσεις ότι ο σταθµός πρέπει να παραµείνει σιωπηλός για µια συγκεκριµένη χρονική περίοδο. Σε αντίθεση µε τα ενσύρµατα δίκτυα, τα ασύρµατα δίκτυα είναι θορυβώδη και αναξιόπιστα, γεγονός που οφείλεται εν µέρει στους φούρνους µικροκυµάτων οι οποίοι χρησιµοποιούν και αυτοί τις µη αδειοδοτηµένες ζώνες ISM. Κατά συνέπεια, η πιθανότητα να καταφέρει ένα πλαίσιο να µεταδοθεί µε επιτυχία µειώνεται ανάλογα µε το µήκος του πλαισίου. Αν η πιθανότητα ένα bit να είναι εσφαλµένο είναι p, τότε η πιθανότητα να ληφθεί ορθά ένα πλαίσιο των n bit είναι (1-p) n. Για παράδειγµα, για p=10-4, η πιθανότητα ορθής λήψης ενός πλαισίου Ethernet πλήρους µεγέθους (12144 bit) είναι µικρότερη από 30%. Ακόµη και όταν p=10-6 θα καταστρέφονται περισσότερα από το 1% των πλαισίων, γεγονός που σηµαίνει περίπου δώδεκα πλαίσια ανά δευτερόλεπτο, και ακόµη περισσότερα αν χρησιµοποιούνται πλαίσια µε µέγεθος µικρότερο από το µέγιστο. Συµπερασµατικά, αν ένα πλαίσιο είναι πολύ µεγάλο έχει πολύ µικρή πιθανότητα να φτάσει ορθά, και µάλλον θα χρειαστεί να αναµεταδοθεί. Για να αντιµετωπιστεί το πρόβληµα των θορυβωδών καναλιών, το 802.11 επιτρέπει στα πλαίσια να τεµαχίζονται σε µικρότερα θραύσµατα (fragments), το καθένα από τα οποία έχει το δικό του άθροισµα ελέγχου. Τα θραύσµατα αριθµούνται και επιβεβαιώνονται χωριστά µέσω ενός πρωτοκόλλου παύσης και αναµονής (µε άλλα λόγια, ο αποστολέας δεν µπορεί να µεταδώσει το θραύσµα k+1 µέχρι να λάβει την επιβεβαίωση για το θραύσµα k). Αφού γίνει κατάληψη του καναλιού µε τα σήµατα RTS και CTS, µπορούν να σταλούν πολλά θραύσµατα στη σειρά, όπως φαίνεται στην 14

Εικόνα 3. Η ακολουθία των θραυσµάτων ονοµάζεται ριπή θραυσµάτων (fragment burst). Εικόνα 3. Μια ριπή θραυσµάτων. Ο κατακερµατισµός σε θραύσµατα αυξάνει τη διεκπεραιωτική ικανότητα, αφού περιορίζει τις αναµεταδόσεις στα λανθασµένα θραύσµατα, αντί σε ολόκληρα τα πλαίσια. Το µέγεθος των θραυσµάτων δεν καθορίζεται από το πρότυπο αλλά είναι παράµετρος κάθε κυψέλης, οπότε µπορεί να προσαρµόζεται από το σταθµό βάσης. Ο µηχανισµός του NAV διατηρεί τους άλλους σταθµούς σιωπηλούς µόνο µέχρι την επόµενη επιβεβαίωση, χρησιµοποιείται όµως ένας άλλος µηχανισµός (που περιγράφεται στη συνέχεια) για να επιτρέψει την αποστολή µιας ολόκληρης ριπής θραυσµάτων χωρίς παρεµβολές. Όλα τα παραπάνω ισχύουν για την κατάσταση λειτουργίας DCF του 802.11. Σε αυτή την κατάσταση λειτουργίας δεν υπάρχει κεντρικός έλεγχος και οι σταθµοί ανταγωνίζονται για το κανάλι, ακριβώς όπως και στο Ethernet. Η άλλη επιτρεπόµενη κατάσταση λειτουργίας είναι η PCF, στην οποία ο σταθµός βάσης χρησιµοποιεί περιόδευση για τους άλλους σταθµούς, ρωτώντας τους αν έχουν κάποια πλαίσια προς αποστολή. Αφού στην κατάσταση PCF η σειρά µετάδοσης ελέγχεται πλήρως από το σταθµό βάσης, δεν συµβαίνουν ποτέ συγκρούσεις. Το πρότυπο προδιαγράφει το µηχανισµό περιόδευσης αλλά όχι και τη συχνότητα περιόδευσης, τη σειρά περιόδευσης, ή ακόµα και το αν όλοι οι σταθµοί θα πρέπει να λαµβάνουν την ίδια εξυπηρέτηση. Ο βασικός µηχανισµός είναι να εκπέµπει ο σταθµός βάσης περιοδικά ένα πλαίσιο φάρου (beacon frame), µε συχνότητα 10 έως 100 φορές ανά δευτερόλεπτο. Το πλαίσιο φάρου περιέχει παραµέτρους του συστήµατος, όπως τις ακολουθίες µετάβασης συχνοτήτων και τους χρόνους παραµονής (για το FHSS), πληροφορίες συγχρονισµού ρολογιού, κλπ. Προσκαλεί επίσης τους νέους σταθµούς να εγγραφούν στην υπηρεσία περιόδευσης για ένα συγκεκριµένο ρυθµό µετάδοσης, ουσιαστικά λαµβάνει ένα εγγυηµένο ποσοστό του εύρους ζώνης, κάνοντας έτσι εφικτή την παροχή εγγυήσεων ποιότητας υπηρεσιών. 15

Ο χρόνος ζωής των µπαταριών είναι ένα µόνιµο πρόβληµα στις φορητές ασύρµατες συσκευές, έτσι το 802.11 δίνει αρκετή σηµασία στο ζήτηµα της διαχείρισης ισχύος. Συγκεκριµένα, ο σταθµός βάσης µπορεί να κατευθύνει έναν κινητό σταθµό έτσι ώστε να µεταπέσει σε κατάσταση νάρκης µέχρι να τον «αφυπνίσει» ρητά ο σταθµός βάσης ή ο χρήστης. Όταν, όµως, ζητά από ένα σταθµό να µεταπέσει σε κατάσταση νάρκης, ο σταθµός βάσης έχει την ευθύνη να αποθηκεύει προσωρινά τα πλαίσια που προορίζονται για το σταθµό όσο αυτός βρίσκεται σε νάρκη. Τα πλαίσια µπορούν να παραληφθούν αργότερα. Οι καταστάσεις λειτουργίας PCF και DCF µπορούν να συνυπάρχουν µέσα σε µια κυψέλη. Αρχικά µπορεί να φαίνεται αδύνατο να έχουµε ταυτόχρονα κεντρικό έλεγχο και κατανεµηµένο έλεγχο, το 802.11 όµως παρέχει µια µέθοδο επίτευξης αυτού του στόχου. Αυτή η µέθοδος λειτουργεί καθορίζοντας προσεκτικά το χρονικό διάστηµα µεταξύ των πλαισίων. Αφού σταλεί ένα πλαίσιο, πρέπει να περάσει ένα συγκεκριµένο διάστηµα νεκρού χρόνου πριν να επιτραπεί σε οποιονδήποτε σταθµό να στείλει ένα άλλο πλαίσιο. Έχουν οριστεί τέσσερα διαφορετικά διαστήµατα, το καθένα για κάποιο συγκεκριµένο σκοπό. Τα τέσσερα διαστήµατα φαίνονται στην Εικόνα 4. Εικόνα 4. ιαστήµατα µεταξύ πλαισίων στο 802.11 Το µικρότερο διάστηµα είναι το Βραχύ ιάστηµα Μεταξύ Πλαισίων ή SIFS (Short InterFrame Spacing). Χρησιµοποιείται για να δώσει στα δύο άκρα µιας συνδιάλεξης την ευκαιρία να µεταδώσουν πρώτα. Οι περιπτώσεις που περιλαµβάνονται είναι να στέλνει ο παραλήπτης ένα µήνυµα CTS σε απάντηση ενός RTS, να στέλνει ο παραλήπτης µια επιβεβαίωση για ένα θραύσµα ή ένα πλήρες πλαίσιο δεδοµένων, και να στέλνει ο αποστολέας µιας ριπής θραυσµάτων το επόµενο θραύσµα χωρίς να χρειαστεί να στείλει ξανά ένα µήνυµα RTS. Μετά από το διάστηµα SIFS υπάρχει πάντα ακριβώς ένας σταθµός ο οποίος έχει το δικαίωµα να απαντήσει. Αν δεν κάνει χρήση της ευκαιρίας αυτής και περάσει χρόνος ίσος µε το ιάστηµα PCF Μεταξύ Πλαισίων ή PIFS (PCF InterFrame Spacing), ο σταθµός βάσης µπορεί να στείλει ένα πλαίσιο φάρου ή ένα πλαίσιο περιόδευσης. Αυτός ο µηχανισµός επιτρέπει σε ένα σταθµό που στέλνει ένα πλαίσιο δεδοµένων ή µία ακολουθία θραυσµάτων να ολοκληρώσει το πλαίσιό του χωρίς να µπει κανείς άλλος στη µέση, δίνει όµως επίσης στο σταθµό βάσης την ευκαιρία να καταλάβει το κανάλι µόλις τελειώσει ο προηγούµενος αποστολέας, χωρίς να χρειαστεί να ανταγωνιστεί µε τους ανυπόµονους χρήστες. 16

Αν ο σταθµός βάσης δεν έχει τίποτα να πει και περάσει χρόνος ίσος µε το ιάστηµα DCF Μεταξύ Πλαισίων ή DIFS (DCF InterFrame Spacing), κάθε σταθµός µπορεί να προσπαθήσει να καταλάβει το κανάλι για να στείλει ένα νέο πλαίσιο. Ισχύουν οι συνηθισµένοι κανόνες ανταγωνισµού, και µπορεί να χρειαστεί να εκτελεστεί δυαδική εκθετική οπισθοχώρηση αν παρουσιαστεί σύγκρουση. Το τελευταίο χρονικό διάστηµα, το Εκτεταµένο ιάστηµα Μεταξύ Πλαισίων ή EIFS (Extended InterFrame Spacing), χρησιµοποιείται µόνο από ένα σταθµό που έχει µόλις λάβει ένα λανθασµένο ή άγνωστο πλαίσιο, και έχει στόχο να αναφέρει το πρόβληµα. Το σκεπτικό µε βάση το οποίο αυτό το συµβάν έχει τη χαµηλότερη προτεραιότητα είναι ότι, αφού ο παραλήπτης µπορεί να µην έχει ιδέα για το τι συµβαίνει, θα πρέπει να περιµένει αρκετό χρόνο έτσι ώστε να αποφεύγονται οι παρεµβολές σε µια συνδιάλεξη που βρίσκεται σε εξέλιξη µεταξύ δύο σταθµών. 1.8 Υπηρεσίες Το πρότυπο 802.11 καθορίζει ότι κάθε ασύρµατο LAN που συµµορφώνεται µε το πρότυπο πρέπει να παρέχει εννιά υπηρεσίες. Οι υπηρεσίες αυτές διαιρούνται σε δύο κατηγορίες: πέντε υπηρεσίες διανοµής και τέσσερις υπηρεσίες σταθµών. Οι υπηρεσίες διανοµής σχετίζονται µε τη διαχείριση των µελών µιας κυψέλης και την αλληλεπίδραση µε σταθµούς εκτός της κυψέλης. Αντιθέτως, οι υπηρεσίες σταθµών ασχολούνται µε τις δραστηριότητες µέσα σε µία µόνο κυψέλη. Οι πέντε υπηρεσίες διανοµής παρέχονται από τους σταθµούς βάσης και ασχολούνται µε τη δυνατότητα µετακίνησης των σταθµών καθώς αυτοί εισέρχονται και εγκαταλείπουν τις κυψέλες, συνδεόµενοι και αποσυνδεόµενοι από τους σταθµούς βάσης. Οι υπηρεσίες αυτές είναι οι ακόλουθες. 1. Συσχέτιση (Association). Η υπηρεσία αυτή χρησιµοποιείται από τους κινητούς σταθµούς για να συνδεθούν µε τους σταθµούς βάσης. Τυπικά χρησιµοποιείται αµέσως µόλις ένας σταθµός µετακινηθεί εντός της εµβέλειας του σταθµού βάσης. Με την άφιξη του, ο σταθµός ανακοινώνει την ταυτότητα και τις δυνατότητες του. Οι δυνατότητες περιλαµβάνουν τους υποστηριζόµενους ρυθµούς µετάδοσης δεδοµένων, την ανάγκη για υπηρεσίες PCF (δηλαδή, µε περιόδευση), και τις απαιτήσεις διαχείρισης ισχύος. Ο σταθµός βάσης µπορεί να αποδεχθεί ή να απορρίψει τον κινητό σταθµό. Αν ο κινητός σταθµός γίνει αποδεκτός, θα πρέπει στη συνέχεια να πιστοποιήσει την ταυτότητα του. 2. Αποσυσχέτιση (Disassociation). Είτε ο σταθµός είτε ο σταθµός βάσης µπορούν να αποσυνδεθούν, τερµατίζοντας έτσι τη συσχέτιση. Ο σταθµός θα πρέπει να χρησιµοποιεί την υπηρεσία αυτή πριν απενεργοποιηθεί ή πριν φύγει από την κυψέλη, ενώ ο σταθµός βάσης µπορεί επίσης να τη χρησιµοποιήσει πριν απενεργοποιηθεί για λόγους συντήρησης. 17

3. Επανασυσχέτιση (Reassociation). Με αυτή την υπηρεσία ένας σταθµός µπορεί να αλλάξει τον προτιµώµενο σταθµό βάσης. Αυτή η βοηθητική λειτουργία είναι χρήσιµη για τους κινητούς σταθµούς που µετακινούνται από κυψέλη σε κυψέλη. Αν χρησιµοποιηθεί σωστά, δεν θα χαθούν δεδοµένα κατά τη µεταβίβαση. (Το 802.11 όµως, όπως και το Ethernet, παρέχει µόνο υπηρεσίες βέλτιστης προσπάθειας.) 4. ιανοµή (Distribution). Η υπηρεσία αυτή προσδιορίζει πως θα δροµολογούνται τα πλαίσια που στέλνονται στο σταθµό βάσης. Αν ο προορισµός είναι τοπικός στο σταθµό βάσης, τα πλαίσια µπορούν να σταλούν άµεσα στην κυψέλη. ιαφορετικά, θα πρέπει να προωθηθούν µέσω του ενσύρµατου δικτύου. 5. Ενοποίηση (Integration). Όταν ένα πλαίσιο µπορεί να σταλεί µέσω ενός δικτύου που δεν είναι µορφής 802.11 και χρησιµοποιεί διαφορετική µέθοδο διευθυνσιοδότησης ή µορφή πλαισίων, η υπηρεσία αυτή διαχειρίζεται τη µετατροπή από τη µορφή του 802.11 στη µορφή που απαιτείται από το δίκτυο προορισµού. Οι υπόλοιπες τέσσερις υπηρεσίες είναι εσωτερικές στις κυψέλες (δηλαδή, σχετίζονται µε ενέργειες που γίνονται µέσα σε µία µόνο κυψέλη). Χρησιµοποιούνται αφού πραγµατοποιηθεί η συσχέτιση (σύνδεση), και είναι οι ακόλουθες. 1. Πιστοποίηση ταυτότητας (Authentication). Επειδή οι ασύρµατες µεταδόσεις είναι εύκολο να σταλούν ή να ληφθούν από µη εξουσιοδοτηµένους σταθµούς, ο σταθµός θα πρέπει να πιστοποιήσει την ταυτότητα του πριν του επιτραπεί να στείλει δεδοµένα. Μόλις ένας κινητός σταθµός συνδεθεί µε το σταθµό βάσης (δηλαδή, όταν γίνει αποδεκτός στην κυψέλη του), ο σταθµός βάσης του στέλνει ένα ειδικό πλαίσιο «πρόσκλησης» για να δει αν ο κινητός σταθµός γνωρίζει το µυστικό κλειδί (συνθηµατικό) που του έχει εκχωρηθεί. Ο σταθµός αποδεικνύει ότι γνωρίζει το µυστικό κλειδί κρυπτογραφώντας το πλαίσιο πρόσκλησης και επιστρέφοντας το στο σταθµό βάσης. Αν το αποτέλεσµα είναι ορθό, ο κινητός σταθµός εγγράφεται πλήρως στην κυψέλη. Στο αρχικό πρότυπο ο σταθµός βάσης δεν χρειαζόταν να αποδείξει και αυτός την ταυτότητά του στον κινητό σταθµό, είναι όµως ήδη σε εξέλιξη δουλειά για να επιδιορθωθεί αυτό το ελάττωµα του προτύπου. 2. Ακύρωση πιστοποίησης ταυτότητας (Deauthentication). Όταν ένας σταθµός που έχει ήδη πιστοποιηθεί θέλει να εγκαταλείψει το δίκτυο, ακυρώνεται η πιστοποίηση του. Μετά την ακύρωση της πιστοποίησης, ο σταθµός δεν µπορεί πια να χρησιµοποιήσει το δίκτυο. 3. Προστασία απορρήτου (Privacy). Για να διατηρούνται εµπιστευτικές οι πληροφορίες που στέλνονται µέσω ενός ασύρµατου LAN, θα πρέπει να κρυπτογραφούνται. Η υπηρεσία αυτή διαχειρίζεται την κρυπτογράφηση και την αποκρυπτογράφηση. Ο αλγόριθµος κρυπτογράφησης που προσδιορίζεται είναι ο RC4, που εφευρέθηκε από τον Ronald Rivest του M.I.T. 4. Παράδοση δεδοµένων (Data delivery). Τέλος, αφού η µετάδοση δεδοµένων είναι ο σκοπός του δικτύου, το 802.11 είναι φυσικό να παρέχει µια µέθοδο 18

µετάδοσης και λήψης δεδοµένων. Επειδή το 802.11 ακολουθεί το µοντέλο του Ethernet και η µετάδοση στο Ethernet δεν είναι εγγυηµένα αξιόπιστη κατά 100%, ούτε η µετάδοση στο 802.11 είναι εγγυηµένα αξιόπιστη. Τα ανώτερα επίπεδα θα πρέπει να ασχοληθούν µε την ανίχνευση και την επιδιόρθωση σφαλµάτων. Οι κυψέλες του 802.11 έχουν κάποιες παραµέτρους οι οποίες µπορούν να εξεταστούν και, σε µερικές περιπτώσεις, να προσαρµοστούν. Αυτές σχετίζονται µε την κρυπτογράφηση, τα διαστήµατα χρόνου αναµονής, τους ρυθµούς µετάδοσης δεδοµένων, τη συχνότητα των φάρων, και άλλες τέτοιες λεπτοµέρειες. Τα ασύρµατα δίκτυα που βασίζονται στο 802.11 αρχίζουν σιγά-σιγά να εγκαθίστανται σε κτίρια γραφείων, αεροδρόµια, ξενοδοχεία, εστιατόρια, και πανεπιστηµιουπόλεις σε όλο τον κόσµο. Αναµένεται να αναπτυχθούν ραγδαία. 2. HCF Controlled Channel Access 2.1 Περιγραφή του HCF Controlled Channel Access Ο HCCA είναι ένας συγκεντρωµένος µηχανισµός πρόσβασης που ελέγχεται από τον υβριδικό συντονιστή (Hybrid Coordinator ή HC), ο οποίος υπάρχει στον QoS-enabled Access Point (QAP). Κάθε QoS-enabled σταθµός (QSTA) µπορεί να έχει µέχρι οκτώ καθιερωµένα ρεύµατα κυκλοφορίας (Traffic Streams ή TS). Ένα TS χαρακτηρίζεται από µια προδιαγραφή κυκλοφορίας (Traffic Specification ή TSPEC) η οποία διαπραγµατεύεται µεταξύ του QSTA και του QAP. Τα υποχρεωτικά πεδία του TSPEC περιλαµβάνουν τα εξής: Mean Data Rate, Delay Bound, Nominal SDU Size. Για όλα τα καθιερωµένα ρεύµατα ο QAP πρέπει να παρέχει µια υπηρεσία που συµµορφώνεται στην διαπραγµατευόµενη TSPEC υπό ελεγχόµενες συνθήκες λειτουργίας. Οι σταθµοί που χρησιµοποιούν το 802.11e πρέπει να είναι σε θέση να επεξεργαστούν τα πρόσθετα πλαίσια που αναφέρονται στον πίνακα 1. Πίνακας 1. QoS πλαίσια 19

Ο QAP επιβάλλει τις διαπραγµατευόµενες εγγυήσεις QoS µε το scheduling των φάσεων ελεγχόµενης πρόσβασης (Controlled Access Phases ή CAPs). Μια CAP είναι ένα χρονικό διάστηµα κατά τη διάρκεια του οποίου ο QAP µπορεί είτε να µεταδώσει MSDUs από καθιερωµένα downlink TSs ή να κάνει poll έναν ή περισσότερους QSTAs διευκρινίζοντας τη µέγιστη διάρκεια της ευκαιρίας µετάδοσης (Transmission Opportunity ή TXOP): ένας QSTA δεν επιτρέπεται ποτέ να υπερβεί το όριο TXOP που επιβάλλεται από τον QAP, συµπεριλαµβανοµένων interframe διαστηµάτων και acknowledgments. Εάν το ρεύµα κυκλοφορίας ενός polled QSTA δεν είναι backlogged, τότε ο QSTA αποκρίνεται µε ένα µηδενικό πλαίσιο (NULL). Το Σχήµα 1 παρουσιάζει ένα δείγµα CAP κατά τη διάρκεια του οποίου ο QAP µεταδίδει δύο πλαίσια και κάνει poll τον QSTA, ο οποίος µεταδίδει στη συνέχεια δύο πλαίσια. Αξίζει να σηµειωθεί ότι το scheduling των CAPs, δηλ. των ρευµάτων κυκλοφορίας HCCA, έχει επίσης επιπτώσεις στη γενική χωρητικότητα που αποµένει στην contention-based κυκλοφορία, δηλ. EDCA και DCF. Το 802.11e παρέχει τρεις τρόπους acknowledgement: Direct acknowledgement: κάθε πλαίσιο δεδοµένων επιβεβαιώνεται ότι παραλήφθηκε από το λαµβάνοντα σταθµό αµέσως αφότου έχει παραληφθεί σωστά. Ο λαµβάνων σταθµός µπορεί να κάνει piggyback το acknowledgement σε ένα εξερχόµενο πλαίσιο που κατευθύνεται στον αποστολέα σταθµό προκειµένου να µειωθεί το overhead του MAC (δείτε τους νέους τύπους πλαισίων στον πίνακα 1). Μια περαιτέρω βελτιστοποίηση συνίσταται σε χρησιµοποίηση του προαιρετικού χαρακτηριστικού γνωρίσµατος QAck. Εάν και ο QAP και ο αποστολέας QSTA είναι QAckenabled, τότε ο QAP µπορεί να κάνει piggyback ένα acknowledgement σε ένα πλαίσιο που κατευθύνεται σε έναv διαφορετικό QSTA από αυτόν που στέλνει. Κανένα acknowledgement: τα πλαίσια δεδοµένων ποτέ δεν επιβεβαιώνονται ότι παραδόθηκαν από το λαµβάνοντα σταθµό. Block acknowledgement: διάφορα acknowledgements αθροίζονται σε ένα πλαίσιο. Το 802.11e δεν διευκρινίζει µια τυποποιηµένη διαδικασία που ο αποστολέας σταθµός πρέπει να εφαρµόσει κατά τον τεµαχισµό και τη σύνδεση των MSDUs σε ένα καταιγισµό πλαισίων. εδοµένου ότι, στο καλύτερο της γνώσης µας, δεν υπάρχει καµία προηγούµενη δουλειά σε αυτό το ιδιαίτερο ζήτηµα, αφήνουµε αυτόν τον προαιρετικό τρόπο για µελλοντική έρευνα. 20

Σχήµα 1. Παράδειγµα της ακολουθίας ανταλλαγής πλαισίων του HCCA Το πρότυπο IEEE 802.11e δεν καθορίζει έναν υποχρεωτικό HCCA scheduling αλγόριθµο. Εντούτοις, ένας scheduler αναφοράς διευκρινίζεται και αναφέρεται εκεί µέσα για ενηµερωτικούς λόγους. Ο scheduler αναφοράς απαιτεί ότι οι ροές διευκρινίζουν τις ακόλουθες παραµέτρους TSPEC: Mean Data Rate, Nominal SDU Size, Maximum SDU Size και Maximum Service Interval (MSI). Το MSI µιας δεδοµένης ροής είναι ο µέγιστος χρόνος που αποµένει από την αρχή δύο επόµενων περιόδων υπηρεσιών σε εκείνη την ροή. Ο scheduler αναφοράς παράγει TDM-like schedules: σε κάθε TS διατίθεται περιοδικά ένα σταθερό ποσό χωρητικότητας. Η περίοδος καλείται Service Interval (SI) και είναι η ίδια για όλα τα ρεύµατα κυκλοφορίας. Υπολογίζεται ως το µικρότερο αναγνωρισµένο MSI. Η διάρκεια της TXOP ορίζεται έπειτα ως ο χρόνος που απαιτείται για να µεταδώσει τα πακέτα του Nominal SDU Size που φθάνουν στο συζητηµένο Mean Data Rate κατά τη διάρκεια του SI. Η TXOP στρογγυλεύεται προς τα πάνω για να περιέχει έναν ακέραιο αριθµό του Nominal SDU Size. Προκειµένου να αποφευχθεί το head of line blocking, η πραγµατική τιµή της TXOP είναι το µέγιστο µεταξύ της αξίας που λαµβάνεται µε την ανωτέρω διαδικασία και του χρόνου να µεταδωθεί ένα πακέτο µε το Maximum SDU Size. Ένα δείγµα schedule που παρουσιάζει τρεις αποδεκτές ροές (ι, j και k) αναφέρεται στο Σχήµα 2. Σχήµα 2. είγµα schedule µε τον scheduler αναφοράς 21

2.2 Η αρχιτεκτονική του λογισµικού Το πλαίσιο της προσοµοίωσης παρουσιάζεται στο Σχήµα 3 και αποτελείται από τα ακόλουθα modules: Classifier, MAC, HCCA sheduler. Αυτά περιγράφονται αργότερα σε αυτό το τµήµα και είναι λειτουργικά στην προσοµοίωση του HCCA του 802.11e. Τα modules Link Layer και Measurement είναι εξωτερικά ως προς το 802.11e και εξαρτώνται από το περιβάλλον προσοµοίωσης όπου το προτεινόµενο πλαίσιο εφαρµόζεται. Το προηγούµενο module απαιτείται για να συνδέσει το MAC µε τα ανώτερα επίπεδα. Η απόδοση αξιολογείται µέσω της χρήσης του Measurement module. Σχήµα 3. Modules Λογισµικού 2.2.1 Classifier module Η λειτουργία του Classifier module είναι να επικολλά κατάλληλα τα πακέτα που ανήκουν σε καθιερωµένα ρεύµατα κυκλοφορίας ένα προσδιοριστικό κυκλοφορίας (Traffic Identifier ή TID). Μόνο πακέτα από το Link Layer στο MAC επικολλούνται, επειδή τα uplink πακέτα περνούν απλώς στα ανώτερα επίπεδα χωρίς οποιαδήποτε µεταχείριση scheduling/διαφοροποίηση. 22

Κάθε σταθµός τρέχει ένα χωριστό instance του Classifier module, το οποίο µπορεί να είναι περαιτέρω εξειδικευµένο στους ακόλουθους δύο τύπους: Classifier για έναν QSTA: η πολιτική επικόλλησης είναι βασισµένη σε ένα σύνολο κανόνων συγκεκριµένο για κάθε τερµατικό Classifier για τον QAP: η πολιτική επικόλλησης είναι βασισµένη στο ανωτέρω σύνολο κανόνων και στο προσδιοριστικό του QSTA προορισµού. Τα MAC και HCCA Scheduler modules είναι σε θέση να ανακτήσουν το TID οποιουδήποτε πακέτου. 2.2.2 MAC module Σε αυτή την υποενότητα, περιγράφουµε τις κύριες δοµές δεδοµένων, τις συναρτήσεις και τα γεγονότα του MAC module. Υπάρχουν τρεις πολιτικές piggybacking, οι οποίες µπορούν να τεθούν σε µια ανά-σταθµό βάση: Κανένα piggybacking: τα µόνα πλαίσια που χρησιµοποιούνται είναι εκείνα που απαριθµούνται στην αριστερή στήλη του πίνακα 1 κάτω από τα «QoS frames» Piggybacking ενεργοποιηµένο: το MAC κάνει piggybacking ένα acknowledgement σε εξερχόµενα πλαίσια δεδοµένων που κατευθύνονται στον ίδιο σταθµό µόνο QAck: το προαιρετικό χαρακτηριστικό γνώρισµα QAck είναι ενεργοποιηµένο. Εποµένως, το piggybacking χρησιµοποιείται όποτε αυτό είναι δυνατό. Επινοήσαµε το ακόλουθο σύνολο γεγονότων που οδηγούν την µηχανή καταστάσεων του MAC: 23

HCCA_HAS_CONTROL. Αυτό το γεγονός δηλώνει στο σταθµό ότι έχει τον έλεγχο του µέσου. Ένας QSTA παράγει αυτό το γεγονός όταν γίνεται polled από τον QAP. Ο QAP παράγει αυτό το γεγονός όταν ακούει το µέσο ως IDLE για µια περίοδο µεγαλύτερη από την PIFS ή όταν λαµβάνει το τελευταίο πλαίσιο από έναν QSTA κατά τη διάρκεια ενός TXOP καταιγισµού. HCCA_LOST_CONTROL. Αυτό το γεγονός δηλώνει στο σταθµό ότι δεν έχει άλλο τον έλεγχο του µέσου. Παράγεται όταν ο scheduler του HCCA έχει οποιαδήποτε πακέτα προς αποστολή. Επίσης, ο QAP παράγει αυτό το γεγονός όταν ένας QSTA αποκρίνεται σωστά σε ένα πλαίσιο polling και ένας QSTA παράγει αυτό το γεγονός όταν ο QAP επιβεβαιώνει σωστά την παράδοση του τελευταίου πλαισίου του TXOP καταιγισµού. HCCA_DATA_RECV. Αυτό το γεγονός δηλώνει στο σταθµό ότι ένα πλαίσιο που µεταφέρει δεδοµένα που προορίζονται σε αυτόν τον σταθµό έχει παραληφθεί σωστά. HCCA_RECV. Αυτό το γεγονός δηλώνει στο σταθµό ότι ένα πλαίσιο οποιουδήποτε τύπου (acknowledgement, data και poll πλαίσια) που προορίζεται σε αυτόν τον σταθµό έχει παραληφθεί σωστά. HCCA_SUCCESS. Αυτό το γεγονός δηλώνει στο σταθµό ότι ένα downlink πλαίσιο δεδοµένων έχει επιβεβαιωθεί ότι παραδόθηκε σωστά από το λαµβάνοντα σταθµό. HCCA_TRANSMIT. Αυτό το γεγονός δηλώνει στο σταθµό ότι ένα downlink πλαίσιο έχει αποσταλεί. HCCA_TX_END. Αυτό το γεγονός παράγεται από τον QAP όταν λήγει το TXOP που χορηγείται σε ένα QSTA HCCA_CAP_HAND. Αυτό το γεγονός παράγεται από τον QAP όταν είναι χρόνος να ξεκινήσει µια νέα CAP, σύµφωνα µε τις απαιτήσεις του scheduler του HCCA. Το Σχήµα 4 παρουσιάζει τα ανωτέρω γεγονότα σε ένα δείγµα ακολουθίας ανταλλαγής πλαισίων: η µετάδοση δύο uplink πλαισίων δεδοµένων, που ακολουθείται από τη µετάδοση ενός downlink πλαισίου δεδοµένων, που υποθέτει ότι ούτε σύγκρουση εµφανίζεται ούτε καταστροφή πλαισίων λόγω του κακού καναλιού. 24

Στο Σχήµα 5 απεικονίζονται οι µηχανές πεπερασµένων καταστάσεων των QAP και QSTA MAC modules. Μετά από την έναρξη του υποσυστήµατος HCCA (γεγονός HCCA_START), ένας σταθµός εναλλάσσεται µεταξύ δύο κύριων καταστάσεων (HAS_CONTROL και LOST_CONTROL, που παρουσιάζονται λεπτοµερέστερα στο Σχήµα 6 και το Σχήµα 7). Η µόνη διαφορά µεταξύ του QAP και του QSTA είναι ότι ο πρώτος µπορεί να έχει πρόσβαση στο µέσο σε κάθε χρονική στιγµή, υπό τον όρο ότι οι τρέχουσες ανταλλαγές πλαισίων δεν διακόπτονται. Αντί αυτού, ο µόνος τρόπος για έναν QSTA να έχει πρόσβαση στο µέσο χρησιµοποιώντας τον HCCA, είναι να αποκρίνεται σε ένα poll από τον QAP. Το MAC ενηµερώνεται από τον scheduler του HCCA για τον χρόνο έναρξης της επόµενης CAP και χρησιµοποιεί ένα αφιερωµένο χρονόµετρο (mhcap_) σε αυτόν τον σκοπό. Σχήµα 4. Γεγονότα κατά τη διάρκεια ενός δείγµατος ακολουθίας ανταλλαγής πλαισίων 25

Σχήµα 5. ιάγραµµα καταστάσεων των QAP και QSTA MAC modules Σχήµα 6. ιάγραµµα καταστάσεων του MAC module (περίπτωση HAS_CONTROL) Όταν γίνει είσοδος στο HAS_CONTROL block (Σχήµα 6) ο σταθµός περιµένει το µέσο να γίνει IDLE. Τότε το MAC ζητά το πακέτο head-of-line στον scheduler του 26

HCCA. Εάν ο HCCA είναι unbacklogged αυτήν την περίοδο, τότε ο σταθµός χάνει αµέσως τον έλεγχο του µέσου. ιαφορετικά, το πλαίσιο στέλνεται στο φυσικό επίπεδο. Εάν υπάρχει ένα acknowledgement σε εκκρεµότητα ο σταθµός µπορεί να το κάνει piggyback στο εξερχόµενο πλαίσιο, υπό τον όρο ότι επιτρέπεται από τις δυνατότητες αποστολής και λήψης. Το εξερχόµενο πλαίσιο µπορεί ή όχι να απαιτήσει ένα ρητό acknowledgement. Στην πρώτη περίπτωση, ο κύκλος ξεκινάει ξανά αµέσως. Στη δεύτερη περίπτωση, ο σταθµός περιµένει το acknowledgement αφού µεταδώσει το πλαίσιο, και: εάν ένα acknowledgement παραλαµβάνεται σωστά µετά από ένα SIFS ο σταθµός επιστρέφει στην αρχική του κατάσταση εάν ο σταθµός είναι ο QAP και το µέσο δεν είναι IDLE για µια περίοδο µεγαλύτερη ή ίση του PIFS, τότε απαιτεί τον έλεγχο του µέσου, έτσι ώστε η contention-based κυκλοφορία δεν µπορεί να χρησιµοποιήσει τα time slots που διατηρούνται για τον HCCA κατά τη διάρκεια µιας φάσης αποκατάστασης (recovery state). εάν ο σταθµός είναι ο QAP και υπάρχει µια απάντηση στο τελευταίο poll πλαίσιο, τότε ο σταθµός χάνει τον έλεγχο του µέσου τέλος, εάν ο σταθµός είναι ένας QSTA και το τελευταίο πλαίσιο στον πρόσφατο TXOP καταιγισµό έχει επιβεβαιωθεί ότι παραδόθηκε, τότε ο σταθµός χάνει τον έλεγχο του µέσου. 27

Σχήµα 7. ιάγραµµα καταστάσεων του MAC module (περίπτωση LOST_CONTROL) Σχήµα 8. ιάγραµµα καταστάσεων των QAP και QSTA HCCA Sscheduler modules 28

Όταν γίνεται είσοδος στο LOST_CONTROL block (Σχήµα 7) ο σταθµός ακούει συνεχώς το µέσο. Τέσσερα γεγονότα µπορούν να εµφανιστούν: παραλαµβάνεται ένα acknowledgement για ένα πλαίσιο δεδοµένων που µεταδόθηκε προηγουµένως. Σε αυτήν την περίπτωση ο σταθµός επιστρέφει αµέσως στην αρχική κατάσταση παραλαµβάνεται ένα πλαίσιο δεδοµένων που απαιτεί ένα άµεσο acknowledgement, οπότε σ' αυτή την περίπτωση το acknowledgement µεταδίδεται µετά από µια διάρκεια SIFS εάν ο σταθµός είναι ένας QSTA µπορεί να λάβει ένα poll πλαίσιο από τον QAP. Σε αυτήν την περίπτωση ο σταθµός εισάγεται στο HCCA_HAS_CONTROL block τέλος, εάν ο σταθµός είναι ο QAP µπορεί να λάβει το τελευταίο πλαίσιο ενός TXOP καταιγισµού. Σε αυτήν την περίπτωση ο σταθµός εισάγεται στο HCCA_HAS_CONTROL block. 2.2.3 HCCA Scheduler Module Το κύριο συστατικό της αρχιτεκτονικής του προσοµοιωτή του HCCA είναι το HCCA Scheduler module. Αντίθετα από εκείνους που λειτουργούν στο επίπεδο δικτύου, οι schedulers που λειτουργούν στο MAC επίπεδο εξαρτώνται πολύ από το επίπεδο-2 και τα φυσικά επίπεδα. Κατά συνέπεια, έχουµε καθορίσει µια διεπαφή που είναι αρκετά γενική για να προσαρµόσει οποιοδήποτε είδος του scheduling αλγορίθµου στο διευκρινισµένο πλαίσιο. Η διεπαφή παρουσιάζεται στο Σχήµα.8, το οποίο εκθέτει τα block διαγράµµατα των QAP και QSTA HCCA Scheduler modules. Όταν είµαστε σε ενεργή κατάσταση (δηλαδή, όταν ο χρήστης ξεκινάει την προσοµοίωση του HCCA) τα schedules και του QAP και του QSTA εναλλάσσονται µεταξύ δύο κύριων καταστάσεων: IDLE. Αυτή είναι παθητική κατάσταση: τα πακέτα που έχουν µπει στη ουρά από downlink TSs δεν µεταδίδονται χρησιµοποιώντας τον HCCA και δεν παράγονται polls (QAP µόνο). Οι µόνες ενέργειες που επιτρέπονται στη τρέχουσα κατάσταση είναι: (α) enqueue ένα νέο downlink πακέτο ενός καθιερωµένου TS (β) πρόσθεση ενός νέου TS στο σύνολο των καθιερωµένων TSs 29

BUSY. Αυτή είναι ενεργή κατάσταση. Όλες οι επιτρεπόµενες ενέργειες στην προηγούµενη κατάσταση µπορούν να πραγµατοποιηθούν στην τρέχουσα. Επιπλέον, τα downlink πακέτα που ανήκουν σε καθιερωµένα TSs µπορούν να µεταδοθούν ή ο QAP µπορεί να κάνει poll τους QSTAs µε καθιερωµένα TSs. Σηµειώστε ότι οι QSTAs φθάνουν σε αυτή την κατάσταση µόνο στην παραλαβή ενός poll από τον QAP, ενώ ο ίδιος ο QAP είναι πάντα σε αυτή την κατάσταση εκτός από κατά τη διάρκεια των ευκαιριών µετάδοσης που χορήγησε στους QSTAs. Οι ακόλουθες συναρτήσεις είναι συγκεκριµένες για τον scheduling αλγόριθµο που χρησιµοποιείται στον QAP και στους QSTAs: enque (). Αυτή η συνάρτηση καλείται από το επίπεδο συνδέσµου όποτε ένα νέο downlink πακέτο έχει παραληφθεί από τα ανώτερα επίπεδα. Το εισερχόµενο πακέτο πρέπει να γίνει enqueued στις συγκεκριµένες δοµές δεδοµένων του HCCA Scheduler module. Υπάρχουν περιπτώσεις στις οποίες ο scheduler µπορεί να κάνει drop τα πακέτα, παραδείγµατος χάριν εάν ο buffer που διατίθεται για τα downlink πακέτα είναι πεπερασµένος ή σύµφωνα µε τις time-to-live πολιτικές πακέτων deque (). Αυτή η συνάρτηση καλείται από το MAC όταν ο σταθµός έχει τον έλεγχο του µέσου. Τα αποτελέσµατά του εξαρτώνται από τον scheduling αλγόριθµο και την παρούσα κατάσταση του scheduler. Οι επιτρεπόµενες ενέργειες περιλαµβάνουν: (i) ο scheduler περνάει στο MAC ένα downlink πακέτο για να µεταδοθεί (ii) ο scheduler διαβιβάζει στο MAC ότι ένας δεδοµένος QSTA πρέπει να γίνει polled µε µια διευκρινισµένη TXOP διάρκεια (iii) ένα poll στον ίδιο του τον εαυτό πρέπει να σταλεί (iv) καµία δράση προς διενέργεια. Φυσικά, οι ενέργειες (ii) και (iii) εκτελούνται µόνο από τον scheduler του QAP. get_next_cap (). [QAP µόνο] αυτή η συνάρτηση καλείται από το MAC όταν ο QAP scheduler χάνει τον έλεγχο του µέσου. Χρησιµοποιείται από τον scheduler για να δηλώσει στο MAC την έναρξη του επόµενου QAP. Μέχρι εκείνη τη χρονική στιγµή, η συνάρτηση HCCA του QAP είναι IDLE. addtspec (). [QAP µόνο] αυτή η συνάρτηση καλείται από το MAC όταν ζητείται η αποδοχή ενός νέου ρεύµατος κυκλοφορίας get_queue_size (). [QSTA µόνο] αυτή η συνάρτηση καλείται από το MAC πριν τη µετάδοση ενός πλαισίου δεδοµένων. Επιστρέφει το µέγεθος της ουράς ενός διευκρινισµένου TS. Αυτές οι πληροφορίες γίνονται piggybacked σε όλα τα πλαίσια δεδοµένων που παράγονται από έναν QSTA που ανήκει σε ένα καθιερωµένο TS. 30

εδοµένου ότι η διαδικασία του scheduler µπορεί να απαιτήσει κάποιες πληροφορίες κατάστασης, καταστήσαµε διαθέσιµο το πλήρες σύνολο γεγονότων που περιγράφηκαν στην προηγούµενη ενότητα στο HCCA scheduler module. Εντούτοις, είναι αρκετά απίθανο ότι οποιοσδήποτε scheduler θα απαιτήσει όλους τους τύπους γεγονότων. Κατά συνέπεια, επιτρέπουµε σε έναν scheduler να καταχωρήσει ρητά το υποσύνολο των γεγονότων για το οποίο επιθυµεί να ενηµερώνεται σύµφωνα µε τις απαιτήσεις του. 3. Περιγραφή του Polling πρωτοκόλλου Σε ένα Polling πρωτόκολλο εµφανίζεται το µοντέλο master-slave, όπου υπάρχει ένας κεντρικός σταθµός, ο Access Point (AP ή BS), στον οποίο συνδέονται όλοι οι άλλοι σταθµοί (SSs). Σε ένα τέτοιο δίκτυο υπάρχει ανταλλαγή πακέτων µεταξύ AP και SSs, τον ρόλο του master τον έχει ο AP και οι slaves είναι οι SSs. Οι λειτουργίες που εκτελεί ένας BS είναι: 1. Ενηµερώνεται για την κατάσταση των ουρών των SSs. Αυτό γίνεται στέλνοντας πακέτα Poll Request στους SSs και λαµβάνοντας πακέτα Poll Response από αυτούς. 2. Καθορίζει πόσα πακέτα από κάθε ουρά των SSs θα δεχτεί. Αυτό γίνεται στέλνοντας Poll Grant πακέτα στους SSs. 3. Καθορίζει πόσα πακέτα από κάθε ουρά του θα στείλει στους SSs. Ο SS πράττει αναλόγως του είδους του πακέτου που θα δεχτεί από τον BS. 3.1 DPOLLING Πρωτόκολλο Το πρωτόκολλο αυτό σχεδιάστηκε για να εξυπηρετήσει ένα outdoor ασύρµατο δίκτυο µε 2 διαφορετικά είδη κίνησης και συγκεκριµένα για κίνηση VoIP και FTP. Σκοπός του είναι να εξυπηρετήσει την real-time κίνηση και να έχει αυξηµένο throughput. 3.1.1 Ταξινόµηση πακέτων στον BS Για να µπορέσουµε να ξεχωρίσουµε τα 2 διαφορετικά είδη κίνησης χρησιµοποιούµε διάφορες ουρές. Στον BS η ταξινόµηση των πακέτων γίνεται βάσει του είδους του πακέτου (real time ή no real time) και του προορισµού του. Έτσι στον BS χρησιµοποιούνται 2 * αριθµός_των_sss ουρές και µία ουρά η οποία κρατά διάφορα άλλα πακέτα όπως τα PING, ARP κτλ. 31

Π.χ. αν έχουµε 10 SSs o BS έχει 10 ουρές (voip_queues) όπου κρατάει τα VoIP πακέτα (1 ουρά ανά SS), 10 ουρές (ftp_queues) όπου κρατάει τα FTP πακέτα και µία ουρά (other_queue) για τα άλλα πακέτα όπως τα PING, ARP κτλ. 3.1.2 Ταξινόµηση πακέτων στον SS Ο SS έχει 3 ουρές, µία ουρά (voip_queue) όπου αποθηκεύονται τα VoIP πακέτα, µία ουρά (ftp_queue) όπου αποθηκεύονται τα FTP πακέτα και µία ουρά (other_queue) όπου αποθηκεύονται άλλου είδους πακέτα όπως PING, ARP κτλ. 3.1.3 ιαφορές σε σχέση µε τον DCF του 802.11 Οι αλλαγές µε το 802.11 είναι: 1. Απενεργοποίηση του ACK για κάθε πακέτο (στέλνεται bulk ack µόνο για την FTP κίνηση) 2. Λαµβάνεται απόφαση από τον BS για το πόσα πακέτα θα στείλει ο κάθε σταθµός από κάθε κίνηση. 3. εν γίνεται ανίχνευση καναλιού αφού για να στείλει ένας σταθµός πακέτα πρέπει να έχει λάβει πακέτο Poll Grant από τον BS. 3.1.4 Τρόπος λειτουργίας πρωτοκόλλου Ο τρόπος λειτουργίας του πρωτοκόλλου είναι ο εξής: Στην αρχή ο BS στέλνει ένα πακέτο PollRequest στον πρώτο SS για να πληροφορηθεί για την κατάσταση των ουρών του SS. Ο SS όταν λάβει ένα τέτοιο πακέτο αποκρίνεται µε ένα πακέτο PollResponse όπου πληροφορεί τον BS για τις ουρές του (voip_queue, other_queue_, ftp_queue). Αφού έχει πληροφορηθεί για την κατάσταση των ουρών όλων των SSs αρχίζει η διαδικασία του UPLINK SCHEDULE όπου ο BS στέλνει PollGrant πακέτα στους SSs ώστε να αρχίσουν αυτοί να µεταδίδουν και τους ενηµερώνει πόσα πακέτα θα στείλουν από κάθε queue. Η διαδικασία αυτή ξεκινάει µε τον πρώτο SS που έχει µη µηδενικές ουρές (δηλαδή έχει πακέτα να στείλει). Έτσι λοιπόν στέλνει ένα PollGrant πακέτο σε αυτόν τον SS και περιµένει από αυτόν ένα PollEnd πακέτο το οποίο θα σηµάνει το τέλος της µετάδοσης πακέτων από τον SS. Ο SS στέλνει πρώτα όλα τα πακέτα της other_queue µετά όλα τα πακέτα της voip_queue και µετά τα ftp πακέτα της ftp_queue. Αν τα πακέτα που έστειλε ο SS ήταν µόνο VoIP τότε προχωράει µε τον επόµενο SS που έχει πακέτα (δεν µας ενδιαφέρει αν χάθηκε πακέτο αφού δεν έχει νόηµα η επαναµετάδοση). Αν ο BS λάβει και FTP πακέτα από τον SS, µόλις πάρει το PollEnd πακέτο τότε του στέλνει ένα BulkAck πακέτο µε το οποίο γνωστοποιεί στον SS για τυχόν χαµένα FTP πακέτα. Όταν έχουν ληφθεί σωστά όλα τα FTP πακέτα (δηλαδή ο BS στέλνει ένα BulkAck µε 0 lost packets), τότε όταν λάβει το PollEnd πακέτο, ο BS προχωράει στον επόµενο SS που έχει πακέτα για να στείλει. Όταν ολοκληρωθεί η διαδικασία αυτή (όλοι οι «έχοντες πακέτα» SSs έστειλαν πακέτα) τότε ο BS στέλνει τα δικά του πακέτα 32

(DOWNLINK SCHEDULE). Ο BS ξεκινάει να στέλνει πρώτα όλα τα πακέτα της other_queue. Μετά στέλνει όλα τα πακέτα VoIP από κάθε voip_queue και µετά αρχίζει να στέλνει FTP πακέτα από κάθε ftp_queue (καθορίζεται από το scheduling). Ξεκινάει να στέλνει πακέτα FTP από την πρώτη ftp_queue δηλαδή πακέτα που θα σταλούν στον πρώτο SS. Όταν στείλει τα πακέτα που πρέπει από αυτή την queue στέλνει ένα PollEnd στον SS ώστε να τον ενηµερώσει ότι τέλειωσε η µετάδοση. Στην συνέχεια ο SS αποκρίνεται στέλνοντας ένα BulkAck πακέτο. Αν υπάρχουν χαµένα FTP πακέτα τότε γίνεται επαναµετάδοση των χαµένων πακέτων έως ότου ληφθούν όλα σωστά. Μόλις µεταφερθούν όλα σωστά (δηλαδή ο SS στείλει µηδενικό BulkAck) τότε ο BS συνεχίζει µε την επόµενη ftp_queue. Μόλις ολοκληρωθεί η διαδικασία τότε ο BS ξεκινάει από την αρχή την όλη διαδικασία, δηλαδή ξεκινά µε την ενηµέρωση για την κατάσταση των ουρών των SSs. Στην αρχή ο SS βρίσκεται σε κατάσταση αναµονής και περιµένει να δεχτεί ένα πακέτο από τον BS. Αν το πακέτο είναι PollRequest τότε αποκρίνεται µε ένα πακέτο PollResponse µε το οποίο ενηµερώνει τον BS για την κατάσταση της ουράς του και επιστρέφει στην αρχική κατάσταση αναµονής. Αν λάβει ένα πακέτο PollGrant τότε στέλνει όλα τα πακέτα της other_queue, όλα τα πακέτα της voip_queue και τα ftp πακέτα της ftp_queue αναλόγως µε το πως ορίζονται στο PollGrant πακέτο (ορίζεται στο scheduling) και στη συνέχεια στέλνει ένα πακέτο PollEnd και επιστρέφει στην αρχική κατάσταση αναµονής. Τέλος αν δεχτεί ένα πακέτο BulkAck διάφορο του µηδενός τότε επαναµεταδίδει µόνο τα χαµένα πακέτα από την ακριβώς προηγούµενη µετάδοση, δηλαδή τα πακέτα που ορίζονται στο BulkAck, στέλνει ένα πακέτο PollEnd και επιστρέφει στην αρχική κατάσταση αναµονής. 3.1.5 Scheduling Μόλις ο BS πάρει πληροφορία για την κατάσταση των ουρών όλων των SS τότε αρχίζει η διαδικασία η οποία καθορίζει πόσα πακέτα και από ποια ουρά θα σταλούν από κάθε κόµβο. Τα βήµατα της διαδικασίας είναι τα εξής: 1. Από το slot period (χρόνος µίας γύρας ) αφαιρείται µισό ms για κάθε SS, χρόνος που αντιστοιχεί στην αποστολή του PollRequest και την λήψη του PollResponse από τον BS 2. Μετράει (κατά προσέγγιση) τον αριθµό των bytes (slotbytes) που αντιστοιχεί στον παραπάνω χρόνο. 3. Από τα παραπάνω bytes αφαιρεί όλα τα πακέτα της voip_queue και της other_queue όλων των κόµβων. 4. Αν έχουν µείνει bytes από την παραπάνω διαδικασία αρχίζει να δίνει FTP πακέτα ξεκινώντας από τον 1 ο SS στην πρώτη γύρα και από την πρώτη ftp_queue του BS (δηλαδή τα πακέτα που έχουν προορισµό τον 1 ο SS). Σε 33

κάθε γύρα ξεκινα η µοιρασιά της ftp κίνησης απο τον επόµενο σταθµό (µεταβλητή WhoisFirst) για καλύτερη κατανοµή της ftp κίνησης στους SSs. 5. Σε ένα σταθµό το max grant για τα ftp πακέτα που του δίνεται είναι 700 byte. Παράδειγµα Έστω ότι υπολογίστηκαν τα slotbytes (1 η γυρα ) και είναι 5000 bytes και έστω ότι έχουµε συνολικά 1000 bytes VoIP πακέτα και 500 other πακέτα (ARP, Ping, κτλ.). Τότε το scheduling θα αποφασίσει ότι θα στείλει όλα τα VoIP πακέτα, όλα τα other πακέτα και 5000-1000-500=3500 bytes ftp πακέτα. Το µοίρασµα των ftp πακέτων θα γίνει ως εξής: Θα ξεκινήσει από τον 1 ο SS. Αν έχει ftp πακέτα στην ουρά του (το ξέρει ο BS από το PollResponse) τότε του δίνει ένα ftp πακέτο (ανώτερη τιµή 700byte). Μετά συνεχίζει από την 1 η ftp_queue του BS, δηλαδή την queue που τα πακέτα της έχουν προορισµό τον 1 ο SS. Αν έχει ftp πακέτα στην ουρά του τότε του δίνει ένα ftp πακέτο (ανώτερη τιµή 700byte). Μετά συνεχίζει από τον 2 ο SS και µετά από την 2 η ftp_queue του BS. Η διαδικασία τελειώνει ώσπου να µηδενιστούν τα slotbytes. Στην επόµενη γύρα η µοιρασία θα ξεκινήσει από τον 2 ο SS. Έστω ότι έχουν όλοι οι κόµβοι FTP πακέτα στην ουρά τους και το µέγεθος του κάθε πακέτου είναι 700 bytes. Τότε θα µοιραστούν: 700 στον 1 ο SS (µένουν 3500-700=2800 slotbytes) 700 στον BS για την 1 η ftp_queue (µένουν 2800-700=2100 slotbytes) 700 στον 2 ο SS (µένουν 2100-700=1400 slotbytes) 700 στον BS για την 2 η ftp_queue (µένουν 1400-700=700 slotbytes) 700 στον 3 ο SS (µένουν 700-700=0 slotbytes) 3.1.6 οµή-λειτουργικότητα πακέτων Παρακάτω παρουσιάζονται η δοµή και η λειτουργικότητα των διαφόρων πακέτων που χρησιµοποιούµε στο πρωτόκολλο µας: Poll Request Το πακέτο αυτό στέλνεται από τον BS στους SSs για να ενηµερωθεί ο BS για την κατάσταση των ουρών τους. 34

Ο header του αποτελείται από ένα πεδίο, το dpolling_type µεγέθους 2 bytes, το οποίο δείχνει το είδος του πακέτου (Poll Request). Poll Response Το πακέτο αυτό στέλνεται από τον SS στον BS και ενηµερώνει τον BS για την κατάσταση των ουρών του. Ο header του αποτελείται από τα εξής πεδία: dpolling_type Το πεδίο αυτό δείχνει το είδος του πακέτου (Poll Response) και έχει µέγεθος 2 bytes. seqno Το πεδίο αυτό κρατά έναν αύξοντα αριθµό για αναγνώριση του πακέτου και έχει µέγεθος 2 bytes. data Το πεδίο αυτό δείχνει το σύνολο των bytes των πακέτων που βρίσκονται στην other_queue του SS και έχει µέγεθος 4 bytes. data1 Το πεδίο αυτό δείχνει το σύνολο των bytes των πακέτων που βρίσκονται στην ftp_queue του SS και έχει µέγεθος 4 bytes. data2 Το πεδίο αυτό δείχνει το σύνολο των bytes των πακέτων που βρίσκονται στην voip_queue του SS και έχει µέγεθος 4 bytes. Poll Grant Το πακέτο αυτό στέλνεται από τον BS στον SS για να ενηµερώσει ο BS τον SS πόσα πακέτα θα στείλει από κάθε queue του και έτσι ξεκινάει η διαδικασία αποστολής πακέτων από τον SS. Ο header του αποτελείται από τα εξής πεδία: dpolling_type Το πεδίο αυτό δείχνει το είδος του πακέτου (Poll Response) και έχει µέγεθος 2 bytes. seqno 35

Το πεδίο αυτό κρατά έναν αύξοντα αριθµό για αναγνώριση του πακέτου και έχει µέγεθος 2 bytes. data Το πεδίο αυτό δείχνει το σύνολο των bytes των πακέτων που θα στείλει ο SS από την other_queue του και έχει µέγεθος 4 bytes. data1 Το πεδίο αυτό δείχνει το σύνολο των bytes των πακέτων που θα στείλει ο SS από την voip_queue του και έχει µέγεθος 4 bytes. data2 Το πεδίο αυτό δείχνει το σύνολο των bytes των πακέτων που θα στείλει ο SS από την ftp_queue του και έχει µέγεθος 4 bytes. Poll End Το πακέτο αυτό στέλνεται από τον BS ή τον SS και δηλώνει το τέλος της διαδικασίας αποστολής πακέτων από τον BS και τον SS αντίστοιχα. Ο header του αποτελείται από ένα πεδίο, το dpolling_type µεγέθους 2 bytes, το οποίο δείχνει το είδος του πακέτου (Poll End). Bulk Ack Όταν γίνεται αποστολή ftp πακέτων τότε σε κάθε ftp πακέτα ενσωµατώνονται 2 headers: ο dpolling_data_hdr_t header αυτός ο header αποτελείται από ένα πεδίο, το dpolling_type µεγέθους 2 bytes, το οποίο δείχνει το είδος του πακέτου (ftp). ο my_arq_subhdr_t header αυτός ο header αποτελείται από δύο πεδία o seqno αυτό το πεδίο κρατά τον αύξοντα αριθµό του ftp πακέτου και έχει µέγεθος 2 byte. o numpkts αυτό το πεδίο κρατά τον αριθµό των πακέτων που έστειλε ο BS και έχει µέγεθος 2 byte. 36

Όταν ένας σταθµός (είτε BS είτε SS) δέχεται ftp πακέτα, όταν τελειώσει αυτή η διαδικασία (το γνωρίζει από την λήψη του Poll End) αποκρίνεται µε ένα πακέτο bulk ack, µε το οποίο ενηµερώνει τον αποστολέα αν τυχόν υπήρχαν χαµένα πακέτα. Ο header του αποτελείται από δύο subheader: τον dpolling_bulkack_hdr_t header αυτός ο header αποτελείται από ένα πεδίο, το dpolling_type µεγέθους 2 bytes, το οποίο δείχνει το είδος του πακέτου (Bulk Ack). τον my_ack_subhdr_t header αυτός ο header αποτελείται από δύο πεδία o len αυτό το πεδίο κρατά τον αριθµό των χαµένων ftp πακέτων και έχει µέγεθος 2 byte. o buf[128] αυτό το πεδίο είναι ένας πίνακας 128 στοιχείων (µεγέθους 2 bytes) όπου το κάθε στοιχείο δείχνει τον αύξοντα αριθµό του χαµένου πακέτου (ο αριθµός αυτός έχει δοθεί από τον αποστολέα κατά την διάρκεια της αποστολής των ftp πακέτων). 37

STATE MACHINE του BS ST_START EV_START sendpollreq to 1 ST_WAIT_POLL_RSP sendpollreq current_node <= nn_ EV_TXTIMEOUT EV_RECV_POLL_RSP sendpollreq current_node_>nn_ e=ev_trigger ST_UPLINK_SCHED 38

ST_UPLINK_SCHED grants_=0 e=ev_trigger grants_>0 sendpollgrant EV_TRIGGER grants>0 sendpollgrant ST_RECV_DATA EV_BULK_END SS hasn't FTP grants>0 sendpollgrant EV_TX_TIMEOUT EV_RX_POLLEND grants_=0 e=ev_trigger sendpollgrant BS has received ftp packets e=ev_trigger miss PollEnd e=ev_trigger ST_SEND_BULK_ACK grants=0 e=ev_trigger ST_DOWNLINK_SCHED 39

ST_RECV_DATA e=ev_bulk_end ST_SEND_BULK_ACK EV_BULKEND EV_TRIGGER e=ev_trigger lost packets no lost packets ST_RECV_BULK_DATA EV_RXPOLLEND ST_WAIT_BULK_END EV_TX_TIMEOUT e=ev_trigger 40

41

ST_DOWNLINK_SCHED EV_TRIGGER e =ev_trigger ST_SEND_DATA EV_TRIGGER EV_TXRESUME FTP packets to send sendpollend No FTP packets to send current_queue_<=nn_ e=ev_trigger No FTP packets to send current_queue_>nn_ e=ev_start ST_START ST_WAIT_BULK_ACK 42

ST_WAIT_BULK_ACK sendpollend EV_TX_TIMEOUT EV_RECV_BULK_ACK No lost packets e=ev_trigger lost packets e=ev_trigger ST_DOWNLINK_SCHED ST_SEND_BULK_DATA EV_TRIGGER EV_TXRESUME mygrant_bulk<=0 sendpollend mygrant_bulk>0 43

STATE MACHINE του SS 44

4. Προσοµοίωση και Προσοµοιωτές ικτύων 4.1 Προσοµοίωση ικτύων Ένας προσοµοιωτής δικτύων (network simulator) είναι ένα κοµµάτι λογισµικού ή υλικού που προβλέπει τη συµπεριφορά ενός δικτύου, χωρίς την παρουσία ενός πραγµατικού δικτύου. Χρήσεις των προσοµοιωτών δικτύων Οι προσοµοιωτές δικτύων εξυπηρετούν ποικίλες ανάγκες. Συγκρινόµενοι µε το κόστος και το χρόνο που περιλαµβάνονται στη δηµιουργία ενός ολόκληρου πεδίου δοκιµών που περιέχει πολλαπλά δικτυωµένους υπολογιστές, δροµολογητές και data links, οι προσοµοιωτές δικτύων είναι σχετικά γρήγοροι και ανέξοδοι. Επιτρέπουν στους µηχανικούς να εξετάσουν τα σενάρια που µπορεί να είναι ιδιαίτερα δύσκολο ή ακριβό να τα µιµηθούν χρησιµοποιώντας πραγµατικό υλικό, για παράδειγµα, η προσοµοίωση των επιπτώσεων µιας ξαφνικής απότοµης αύξησης στην κυκλοφορία ή µιας επίθεσης DoS σε µια υπηρεσία δικτύου. Οι προσοµοιωτές δικτύων είναι ιδιαίτερα χρήσιµοι στο να επιτρέπουν στους σχεδιαστές να εξετάσουν τα νέα πρωτόκολλα δικτύου ή τις αλλαγές στα υπάρχοντα πρωτόκολλα σε ένα ελεγχόµενο και αναπαράξιµο περιβάλλον. Οι προσοµοιωτές δικτύων, όπως το όνοµα υποδηλώνει, χρησιµοποιούνται από ερευνητές, developers και QA για να σχεδιάσουν διάφορα είδη δικτύων, να προσοµοιώσουν και έπειτα να αναλύσουν την επίδραση των διάφορων παραµέτρων στην απόδοση δικτύων. Ένας τυπικός προσοµοιωτής δικτύων όπως ο NetSim καλύπτει ένα ευρύ φάσµα των τεχνολογιών δικτύων και βοηθά τους χρήστες να χτίσουν σύνθετα δίκτυα από τις βασικές δοµικές µονάδες, όπως την ποικιλία των κόµβων και των συνδέσεων. Με τη βοήθεια των προσοµοιωτών, κάποιος µπορεί να σχεδιάσει ιεραρχικά δίκτυα χρησιµοποιώντας διάφορους τύπους κόµβων όπως υπολογιστές, hubs, bridges, δροµολογητές, optical cross-connects, multicast δροµολογητές, κινητές µονάδες, MSAUs κ.λπ. Τύποι προσοµοιωτών δικτύων ιάφοροι τύποι τεχνολογιών δικτύων ευρείας περιοχής (WAN), όπως το TCP, το ATM, το IP κ.λπ. και τεχνολογιών τοπικών δικτύων (LAN) όπως το Ethernet, τα token rings κ.λπ. µπορούν όλα να προσοµοιωθούν µε έναν τυπικό προσοµοιωτή και ο χρήστης µπορεί να εξετάσει και να αναλύσει τα διάφορα τυποποιηµένα αποτελέσµατα. Υπάρχει µια ευρεία ποικιλία προσοµοιωτών δικτύων, που κυµαίνονται από τον πιο απλό έως τον πιο σύνθετο. Στη χειρότερη περίπτωση, ένας προσοµοιωτής δικτύων πρέπει να επιτρέπει στον χρήστη να αναπαραστήσει µια τοπολογία δικτύου, διευκρινίζοντας τους κόµβους στο δίκτυο, τις συνδέσεις µεταξύ των κόµβων και την κυκλοφορία µεταξύ των κόµβων. Τα πιο περίπλοκα συστήµατα µπορούν να 45

επιτρέπουν στο χρήστη να διευκρινίσει τα πάντα για τα πρωτόκολλα που χρησιµοποιούνται για να χειριστούν την κυκλοφορία του δικτύου. Οι γραφικές εφαρµογές επιτρέπουν στους χρήστες να απεικονίσουν εύκολα τα έργα του προσοµοιωµένου περιβάλλοντός τους. Οι εφαρµογές που βασίζονται στο κείµενο µπορούν να παρέχουν µια λιγότερο διαισθητική διεπαφή, αλλά µπορούν να επιτρέπουν πιο προηγµένες µορφές προσαρµογής. Άλλες, όπως GTNets, είναι programming-oriented, παρέχοντας ένα πλαίσιο προγραµµατισµού που ο χρήστης κατόπιν προσαρµόζει για να δηµιουργήσει µια εφαρµογή που προσοµοιώνει το περιβάλλον δικτύου που εξετάζεται. Στις επικοινωνίες και την έρευνα στον τοµέα των δικτύων υπολογιστών, η προσοµοίωση δικτύων είναι µια τεχνική όπου ένα πρόγραµµα µοντελοποιεί τη συµπεριφορά ενός δικτύου είτε µε τον υπολογισµό της αλληλεπίδρασης µεταξύ των διαφορετικών οντοτήτων του δικτύου (hosts/δροµολογητές, data links, πακέτα, κ.λπ.) χρησιµοποιώντας µαθηµατικούς τύπους, είτε συλλαµβάνοντας πραγµατικά και αναπαράγοντας παρατηρήσεις από ένα δίκτυο παραγωγής. Η συµπεριφορά του δικτύου και των διαφόρων εφαρµογών και υπηρεσιών που αυτό υποστηρίζει µπορούν έπειτα να παρατηρηθούν σε ένα εργαστήριο δοκιµών, οι διάφορες ιδιότητες του περιβάλλοντος µπορούν επίσης να τροποποιηθούν µε έναν ελεγχόµενο τρόπο για να αξιολογήσουν πώς το δίκτυο θα συµπεριφερόταν κάτω από διαφορετικές συνθήκες. Όταν ένα πρόγραµµα προσοµοίωσης χρησιµοποιείται από κοινού µε τις live εφαρµογές και τις υπηρεσίες προκειµένου να παρατηρηθεί η απ άκρου σε άκρο απόδοση στο desktop του χρήστη, η τεχνική αναφέρεται επίσης ως network emulation. 4.2 Προσοµοιωτής ικτύων Ο προσοµοιωτής (ή προσοµοιωτής δικτύων) είναι το πρόγραµµα που είναι υπεύθυνο για τον υπολογισµό του πώς θα συµπεριφερόταν το δίκτυο. Τέτοιο λογισµικό µπορεί να διανεµηθεί µε µορφή πηγής (λογισµικό) ή συσκευασµένο υπό τη µορφή αφιερωµένης συσκευής υλικού. Οι χρήστες µπορούν έπειτα να προσαρµόσουν τον προσοµοιωτή για να εκπληρώσουν τις συγκεκριµένες ανάγκες της ανάλυσής τους. Οι προσοµοιωτές διατίθενται συνήθως υποστηρίζοντας τα δηµοφιλέστερα πρωτόκολλα που χρησιµοποιούνται σήµερα, όπως το IPv4, IPv6, UDP, και το TCP. Open Source Προσοµοιωτές Ο ευρύτερα χρησιµοποιηµένος open source προσοµοιωτής δικτύων στην έρευνα είναι ο NS - 2 που τρέχει σε Linux. Παρά τη δηµοτικότητά του, ένα βασικό µειονέκτηµα του είναι η δυσκολία στην εκµάθηση και χρησιµοποίηση της διεπαφής χρήστη που βασίζεται σε script. Προσοµοιώσεις Οι περισσότεροι από τους εµπορικούς προσοµοιωτές είναι οδηγούµενοι από GUI, ενώ µερικοί προσοµοιωτές δικτύων απαιτούν scripts ή εντολές εισόδου (παράµετροι 46

δικτύων). Οι παράµετροι δικτύου περιγράφουν την κατάσταση του δικτύου (τοποθέτηση κόµβων, υπάρχουσες συνδέσεις) και των γεγονότων (µεταδόσεις δεδοµένων, αποτυχίες συνδέσεων, κ.λπ.). Μια σηµαντική έξοδος των προσοµοιώσεων είναι τα αρχεία ιχνών (trace files). Τα αρχεία ιχνών µπορούν να τεκµηριώσουν κάθε γεγονός που εµφανίστηκε στην προσοµοίωση και χρησιµοποιείται για την ανάλυση. Ορισµένοι προσοµοιωτές έχουν επιπρόσθετη λειτουργία συγκράτησης δεδοµένων αυτού του τύπου, άµεσα από ένα περιβάλλον παραγωγής σε λειτουργία, σε διάφορους χρόνους της ηµέρας, εβδοµάδας, µήνα, προκειµένου να απεικονιστούν οι συνθήκες της µέσης, της χειρότερης, και της καλύτερης περίπτωσης. Οι προσοµοιωτές δικτύων µπορούν επίσης να παρέχουν άλλα εργαλεία για να διευκολύνουν την οπτική ανάλυση των τάσεων και των πιθανών προβληµατικών σηµείων. Τεχνικές προσοµοίωσης Οι περισσότεροι προσοµοιωτές δικτύων χρησιµοποιούν την discrete event προσοµοίωση, στην οποία αποθηκεύεται ένας κατάλογος εκκρεµών «γεγονότων», και αυτά τα γεγονότα υποβάλλονται σε επεξεργασία µε τη σειρά, µε µερικά γεγονότα να προκαλούν µελλοντικά γεγονότα -- όπως το γεγονός της άφιξης ενός πακέτου σε έναν κόµβο που προκαλεί το γεγονός της άφιξης αυτού του πακέτου σε έναν downstream κόµβο. Μερικά προβλήµατα προσοµοίωσης δικτύων, ειδικότερα αυτά που στηρίζονται στη θεωρία της εισαγωγής σε ουρά (queueing theory), ταιριάζουν στις προσοµοιώσεις Μαρκοβιανής αλυσίδας, στις οποίες δεν διατηρείται κατάλογος µελλοντικών γεγονότων και η προσοµοίωση αποτελείται από τη µετάβαση µεταξύ διαφορετικών συστηµάτων καταστάσεων σε ένα memoryless µοντέλο. Η προσοµοίωση Μαρκοβιανής αλυσίδας είναι τυπικά γρηγορότερη αλλά λιγότερο ακριβής και ευέλικτη από τη λεπτοµερή discrete event προσοµοίωση. Μερικές προσοµοιώσεις είναι cyclic based προσοµοιώσεις και αυτές είναι γρηγορότερες σε σύγκριση µε τις event based προσοµοιώσεις. Η προσοµοίωση δικτύου µπορεί να είναι ένα δύσκολο έργο. Παραδείγµατος χάριν, εάν η συµφόρηση είναι υψηλή, τότε ο υπολογισµός της µέσης κατοχής είναι πολύ δύσκολη λόγω της υψηλής µεταβλητότητας. Για να υπολογίσει την πιθανότητα µιας υπερχείλισης buffer σε ένα δίκτυο, ο χρόνος που απαιτείται για µια ακριβή απάντηση µπορεί να είναι εξαιρετικά µεγάλος. Οι εξειδικευµένες τεχνικές όπως «control variates» και «important sampling» έχουν αναπτυχθεί στην speed simulation. 4.3 ns (προσοµοιωτής) Ο ns ή network simulator (επίσης γενικά αποκαλούµενος ns-2, αναφορικά µε την τρέχουσα έκδοση του) είναι ένας discrete event προσοµοιωτής δικτύων Είναι δηµοφιλής στον ακαδηµαϊκό κόσµο για την εκτεταµένη (λόγω του open source προτύπου του) και την άφθονη online τεκµηρίωση. Ο ns χρησιµοποιείται γενικά στην προσοµοίωση των routing και multicast πρωτοκόλλων, µεταξύ των άλλων, και 47

χρησιµοποιείται πολύ στην ad hoc έρευνα. Ο ns υποστηρίζει µια σειρά δηµοφιλών πρωτοκόλλων δικτύων, που παρέχουν αποτελέσµατα προσοµοίωσης για ενσύρµατα και ασύρµατα δίκτυα. Μπορεί να χρησιµοποιηθεί επίσης ως limited-functionality network emulator. Ο NS έχει χορηγηµένη άδεια για χρήση υπό την έκδοση 2 της GNU General Public License. Σχεδίαση Ο ns δηµιουργήθηκε σε C++ και παρέχει µια διεπαφή προσοµοίωσης µέσω της OTcl, µιας αντικειµενοστρεφούς διαλέκτου της Tcl. Ο χρήστης περιγράφει µια τοπολογία δικτύου µε τη συγγραφή των OTcl scripts, και έπειτα το κύριο πρόγραµµα του ns προσοµοιώνει την τοπολογία αυτή µε διευκρινισµένες παραµέτρους. 48

5. Μετρήσεις Αποτελέσµατα Όταν τρέχουµε τα διάφορα τεστ παράγονται κάποια αποτελέσµατα και µερικές µεταβλητές που εµφανίζονται είναι οι εξής: 1. Average Throughput: µέσος όρος της κυκλοφορίας (εσωτερικής και εξωτερικής) που πέρασε από όλους τους κόµβους 2. RTT (Round-Trip-Time) για τα Ping πακέτα: είναι το χρονικό διάστηµα που µεσολαβεί από την δηµιουργία του Ping πακέτου στον agent µέχρι την παραλαβή της απάντησης από τον ίδιο agent. 3. ΜOS: µετρά την ποιότητα της VoIP κλήσης. 4. VoIPDelay: χρονικό διάστηµα που µεσολαβεί από την δηµιουργία του VoIP πακέτου στον agent µέχρι την αποστολή του στον προορισµό του. (δηλαδή ο χρόνος αναµονής στην ουρά). Mean Opinion Score (MOS) Στη φωνητική και την τηλεοπτική επικοινωνία, η ποιότητα συνήθως υπαγορεύει εάν η εµπειρία είναι καλή ή κακή. Εκτός από την ποιοτική περιγραφή που ακούµε, όπως «αρκετά καλή» ή «πολύ κακή», υπάρχει µια αριθµητική µέθοδος για την περιγραφή της φωνητικής και της τηλεοπτικής ποιότητας, η οποία καλείται Mean Opinion Score (MOS). Το MOS δίνει µια αριθµητική ένδειξη της αντιληπτής ποιότητας των µέσων που παραλαµβάνονται αφού έχουν διαβιβαστεί και τελικά συµπιεστεί χρησιµοποιώντας codecs. Το MOS εκφράζεται σε έναν αριθµό, από 1 έως 5, 1 όντας το χειρότερο και 5 το καλύτερο. Το MOS είναι αρκετά υποκειµενικό, δεδοµένου ότι είναι αριθµοί που προκύπτουν από αυτό που γίνεται αντιληπτό από τους ανθρώπους κατά τη διάρκεια των δοκιµών. Εντούτοις, υπάρχουν εφαρµογές λογισµικού που µετρούν το MOS στα δίκτυα, όπως βλέπουµε παρακάτω. Οι τιµές του Mean Opinion Score (MOS) Εκφραζόµενοι σε ακέραιους, οι αριθµοί είναι αρκετά εύκολο να βαθµολογηθούν. 5 - τέλεια. Όπως την πρόσωπο µε πρόσωπο συνοµιλία ή τη ραδιοφωνική λήψη. 4 - αποδεκτή. Οι ατέλειες µπορούν να γίνουν αντιληπτές, αλλά ο ήχος είναι ακόµα καθαρός. Αυτό είναι (υποθετικά) το εύρος για τα cell phones. 3 ενοχλητική. 2 - πολύ ενοχλητική. Σχεδόν αδύνατη η επικοινωνία. 1 - αδύνατη η επικοινωνία. 49

Οι τιµές δεν πρέπει υποχρεωτικά να είναι ακέραιοι αριθµοί. Ορισµένα κατώτατα όρια και ορισµένα όρια εκφράζονται συχνά σε δεκαδικές τιµές από αυτό το φάσµα του MOS. Για παράδειγµα, µια τιµή από 4.0 έως 4.5 αναφέρεται ως toll-quality και αποφέρει την πλήρη ικανοποίηση. Αυτή είναι η συνήθης τιµή για το PSTN και πολλές υπηρεσίες VoIP στοχεύουν σε αυτήν, συχνά µε επιτυχία. Οι τιµές που πέφτουν κάτω από το 3.5 θεωρούνται απαράδεκτες από πολλούς χρήστες. Πώς διεξάγονται τα tests του MOS; Ορισµένοι άνθρωποι κάθονται και υποχρεώνονται να ακούσουν κάποιο ήχο. Καθένας τους δίνει µια βαθµολογία από 1 έως 5. Κατόπιν υπολογίζεται ένας αριθµητικός µέσος όρος, δίνοντας το Mean Opinion Score (MOS). Κατά τη διεξαγωγή των tests του MOS, υπάρχουν ορισµένες φράσεις που συστήνονται για να χρησιµοποιηθούν από το ITU-T. Αυτές είναι: You will have to be very quiet. There was nothing to be seen. They worshipped wooden idols. I want a minute with the inspector. Did he need any money? Παράγοντες που επηρεάζουν το Mean Opinion Score Το MOS µπορεί εύκολα να χρησιµοποιηθεί για σύγκριση µεταξύ των υπηρεσιών VoIP και των providers. Αλλά το πιο σηµαντικό, χρησιµοποιείται για την αξιολόγηση της εργασίας των codecs, οι οποίοι συµπιέζουν τον ήχο και την εικόνα για να εξοικονοµήσουν bandwidth, αλλά µε συγκεκριµένες απώλειες στην ποιότητα. Τα tests του MOS γίνονται για τους codecs σε συγκεκριµένο περιβάλλον. Υπάρχουν εντούτοις ορισµένοι άλλοι παράγοντες που επηρεάζουν την ποιότητα του ήχου και του βίντεο που µεταφέρεται. Αυτοί οι παράγοντες δεν πρόκειται να συµπεριληφθούν στις τιµές του MOS, έτσι κατά τον καθορισµό του MOS για έναν ορισµένο κωδικοποιητή-αποκωδικοποιητή (codec), µια υπηρεσία ή ένα δίκτυο, είναι σηµαντικό όλοι οι άλλοι παράγοντες να είναι ευνοϊκοί στο µέγιστο για µια καλή ποιότητα, και για τις τιµές του MOS υποθέτουµε ότι αυτό λήφθηκε υπό ιδανικές συνθήκες. Mean Opinion Score tests αυτοµατοποιηµένα µε τη χρήση λογισµικού εδοµένου ότι τα tests του MOS που χρησιµοποιούν τον άνθρωπο για εξαγωγή αποτελεσµάτων είναι αρκετά υποκειµενικά και λιγότερο παραγωγικά από πολλές απόψεις, υπάρχουν σήµερα διάφορα εργαλεία λογισµικού που πραγµατοποιούν τα αυτοµατοποιηµένα tests του MOS επεκτείνοντας το στα δεδοµένα VoIP. Αν και στερούνται το ανθρώπινο στοιχείο, το καλό µε αυτά τα tests είναι ότι λαµβάνουν υπόψη όλες τις συνθήκες που εξαρτώνται από το δίκτυο, οι οποίες θα µπορούσαν να επηρεάσουν την ποιότητα της φωνής. Μερικά παραδείγµατα είναι τα AppareNet Voice, Brix VoIP Measurement Suite, NetAlly, PsyVoIP και VQmon/EP. 50

5.1 Σύγκριση 802.11-DPolling 5.1.1 Παραδείγµατα FTP κίνησης χωρίς παρουσία θορύβου Παράδειγµα 1 Στο παράδειγµα αυτό τρέξαµε τον NS για 10 sec µε αριθµό κόµβων 8, χωρίς την παρουσία θορύβου και µε το bandwidth να είναι 11Mb. Επίσης συµµετείχαν 6 τεστ όπου το 1 ο τεστ περιλαµβάνει το 802.11 πρωτόκολλο χωρίς την ύπαρξη κρυµµένου κόµβου και χωρίς RTS/CTS πακέτα, το 2 ο τεστ περιλαµβάνει το 802.11 πρωτόκολλο µε την ύπαρξη κρυµµένου κόµβου και χωρίς RTS/CTS πακέτα, το 3 ο τεστ περιλαµβάνει το 802.11 πρωτόκολλο µε την ύπαρξη κρυµµένου κόµβου και µε RTS/CTS πακέτα, το 4 ο τεστ περιλαµβάνει το δικό µας πρωτόκολλο (DPOLLING) µε την ύπαρξη κρυµµένου κόµβου και µε slot period=50 ms, το 5 ο τεστ περιλαµβάνει το δικό µας πρωτόκολλο (DPOLLING) µε την ύπαρξη κρυµµένου κόµβου και µε slot period=100 ms και το 6 ο τεστ περιλαµβάνει το δικό µας πρωτόκολλο (DPOLLING) µε την ύπαρξη κρυµµένου κόµβου και µε slot period=400 ms. Παρακάτω φαίνονται µερικά αποτελέσµατα. Test Class Last Rx Avg_Throughput Ftp 9.99742 4.90138e+06 Ftp 9.99871 4.09368e+06 Ftp 9.99932 3.29997e+06 Ftp 9.9979 5.01574e+06 802.11-ftp-nortsnohn-nodes8-error0 802.11-ftp-nortsnodes8-error0 802.11-ftp-rtsnodes8-error0 dpolling-50ms-ftppoll-nodes8-error0 dpolling-100ms-ftppoll-nodes8-error0 Ftp 9.99675 5.75822e+06 51

dpolling-400ms-ftppoll-nodes8-error0 Ftp 9.96754 6.6959e+06 Πίνακας 1: παρουσιάζει το AVERAGE_THROUGHPUT για κάθε πρωτόκολλο Σύγκριση του 802.11 µε το DPolling µε slot period = 50 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερη απόδοση από το 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Σύγκριση του 802.11 µε το DPolling µε slot period = 100 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερη απόδοση από το 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Σύγκριση του 802.11 µε το DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερη απόδοση από το 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Σύγκριση του DPolling µε slot period = 100 ms, του DPolling µε slot period = 100 ms και DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι όσο µεγαλώνει το slot period τόσο µεγαλώνει η απόδοση. Αυτό συµβαίνει επειδή όταν µεγαλώνει το slot period τότε αυξάνεται και ο αριθµός των ftp bytes που περνάνε ανά γύρα. Αντιθέτως όταν είναι µικρό το slot period τότε µειώνονται τα ftp bytes που περνάνε ανά γύρα και αυξάνονται οι γύρες, πράγµα που σηµαίνει ότι στέλνονται παραπάνω µη οφέλιµα πακέτα όπως PollGrant, PollRequest κτλ. 52

Test Class #Samples Average Ping 16 0.65165 Ping 17 0.391035 Ping 17 0.540482 Ping 19 0.107411 Ping 19 0.179421 802.11-ftp-nortsnohn-nodes8-error0 802.11-ftp-nortsnodes8-error0 802.11-ftp-rtsnodes8-error0 dpolling-50ms-ftppoll-nodes8-error0 dpolling-100ms-ftppoll-nodes8-error0 dpolling-400ms-ftppoll-nodes8-error0 Ping 18 0.437983 Πίνακας 2: παρουσιάζει το µέσο όρο του RTT των Ping πακέτων για κάθε πρωτόκολλο Σύγκριση του 802.11 µε το DPolling µε slot period = 50 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του RTT των Ping πακέτων από το 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από το παραπάνω φαίνεται η προτεραιότητα που δίνουµε στα πακέτα της other_queue η οποία είναι ίδια µε την προτεραιότητα της voip_queue. 53

Σύγκριση του 802.11 µε το DPolling µε slot period = 100 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του RTT των Ping πακέτων από το 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από το παραπάνω φαίνεται η προτεραιότητα που δίνουµε στα πακέτα της other_queue η οποία είναι ίδια µε την προτεραιότητα της voip_queue. Σύγκριση του 802.11 µε το DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του RTT των Ping πακέτων από το 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Αντιθέτως το πρωτόκολλό µας παρουσιάζει µεγαλύτερο µέσο όρο του RTT των Ping πακέτων από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Αυτο συµβαίνει επειδή έχουµε πολύ µεγάλο slot period πράγµα που σηµαίνει ότι σε κάθε γύρα στέλνονται αρκετά FTP πακέτα µε αποτέλεσµα τα Ping πακέτα που βρίσκονται στην other_queue να καθυστερούν να σταλούν. Σύγκριση του DPolling µε slot period = 50 ms, του DPolling µε slot period = 100 ms και DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι όσο µεγαλώνει το slot period τόσο µεγαλώνει ο µέσος όρος του RTT των Ping πακέτων. Αυτό συµβαίνει επειδή όταν µεγαλώνει το slot period τότε αυξάνεται και ο αριθµός των ftp bytes που περνάνε ανά γύρα µε αποτέλεσµα να καθυστερούν τα Ping πακέτα. 54

Γραφική παράσταση 1: παρουσιάζει το RTT των Ping πακέτων για κάθε πρωτόκολλο συναρτήσει του χρόνου. 55

Γραφική παράσταση 2: παρουσιάζει τα bytes που δέχτηκε κάθε κόµβος 56

Γραφική παράσταση 3: παρουσιάζει τα bytes που έστειλε κάθε κόµβος. Σύγκριση του 802.11 µε το DPolling µε slot period = 50 ms Εδώ παρατηρούµε ότι η καµπύλη του δικού µας πρωτοκόλλου είναι οµαλή πράγµα που σηµαίνει ότι µπορούµε να εγγυηθούµε ένα σταθερό bandwidth σε κάθε κόµβο. Αντιθέτως στο 802.11 µε την παρουσία κρυµµένου κόµβου χωρίς RTS/CTS πακέτα όλοι οι κόµβοι εκτός του 0 παρουσιάζουν ελάχιστη κίνηση ενώ στο 802.11 µε την παρουσία κρυµµένου κόµβου µε RTS/CTS πακέτα κάποιοι κόµβοι έχουν ελάχιστη κίνηση. Σύγκριση του 802.11 µε το DPolling µε slot period = 100 ms Εδώ παρατηρούµε ότι η καµπύλη του δικού µας πρωτοκόλλου είναι οµαλή πράγµα που σηµαίνει ότι µπορούµε να εγγυηθούµε ένα σταθερό bandwidth σε κάθε κόµβο. Αντιθέτως στο 802.11 µε την παρουσία κρυµµένου κόµβου χωρίς RTS/CTS πακέτα όλοι οι κόµβοι εκτός του 0 παρουσιάζουν ελάχιστη κίνηση ενώ στο 802.11 µε την παρουσία κρυµµένου κόµβου µε RTS/CTS πακέτα κάποιοι κόµβοι έχουν ελάχιστη κίνηση. 57

Σύγκριση του 802.11 µε το DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι η καµπύλη του δικού µας πρωτοκόλλου είναι οµαλή πράγµα που σηµαίνει ότι µπορούµε να εγγυηθούµε ένα σταθερό bandwidth σε κάθε κόµβο. Αντιθέτως στο 802.11 µε την παρουσία κρυµµένου κόµβου χωρίς RTS/CTS πακέτα όλοι οι κόµβοι εκτός του 0 παρουσιάζουν ελάχιστη κίνηση ενώ στο 802.11 µε την παρουσία κρυµµένου κόµβου µε RTS/CTS πακέτα κάποιοι κόµβου έχουν ελάχιστη κίνηση. Παράδειγµα 2 Στο παράδειγµα αυτό τρέξαµε τον NS για 10 sec µε αριθµό κόµβων 16, χωρίς την παρουσία θορύβου και µε το bandwidth να είναι 11Mb. Επίσης συµµετείχαν 6 τεστ όπου το 1 ο τεστ περιλαµβάνει το 802.11 πρωτόκολλο χωρίς την ύπαρξη κρυµµένου κόµβου και χωρίς RTS/CTS πακέτα, το 2 ο τεστ περιλαµβάνει το 802.11 πρωτόκολλο µε την ύπαρξη κρυµµένου κόµβου και χωρίς RTS/CTS πακέτα, το 3 ο τεστ περιλαµβάνει το 802.11 πρωτόκολλο µε την ύπαρξη κρυµµένου κόµβου και µε RTS/CTS πακέτα, το 4 ο τεστ περιλαµβάνει το δικό µας πρωτόκολλο (DPOLLING) µε την ύπαρξη κρυµµένου κόµβου και µε slot period=50 ms, το 5 ο τεστ περιλαµβάνει το δικό µας πρωτόκολλο (DPOLLING) µε την ύπαρξη κρυµµένου κόµβου και µε slot period=100 ms και το 6 ο τεστ τπεριλαµβάνει το δικό µας πρωτόκολλο (DPOLLING) µε την ύπαρξη κρυµµένου κόµβου και µε slot period=400 ms. Παρακάτω φαίνονται µερικά αποτελέσµατα. Test Class Last Rx Avg_Throughput 802.11-ftp-norts- nohn-nodes16- error0 Ftp 9.99877 4.90123e+06 Ftp 9.99866 3.8911e+06 802.11-ftp-nortsnodes16-error0 802.11-ftp-rtsnodes16-error0 Ftp 9.99857 3.19979e+06 58

Ftp 9.99964 3.76855e+06 Ftp 9.99707 4.82319e+06 dpolling-50ms-ftppoll-nodes16-error0 dpolling-100ms-ftppoll-nodes16-error0 dpolling-400ms-ftppoll-nodes16-error0 Ftp 9.99787 6.19185e+06 Πίνακας 1: παρουσιάζει το AVERAGE_THROUGHPUT για κάθε πρωτόκολλο Σύγκριση του 802.11 µε το DPolling µε slot period = 50 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει λίγο µικρότερη απόδοση από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και λίγο µεγαλύτερη απόδοση από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Σύγκριση του 802.11 µε το DPolling µε slot period = 100 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερη απόδοση από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Σύγκριση του 802.11 µε το DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερη απόδοση από το 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Σύγκριση του DPolling µε slot period = 50 ms, του DPolling µε slot period = 100 ms και DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι όσο µεγαλώνει το slot period τόσο µεγαλώνει η απόδοση. Αυτό συµβαίνει επειδή όταν µεγαλώνει το slot period τότε αυξάνεται και ο αριθµός των ftp bytes που περνάνε ανά γύρα. Αντιθέτως όταν είναι µικρό το slot period τότε µειώνονται τα ftp bytes που περνάνε ανά γύρα και αυξάνονται οι γύρες, πράγµα που σηµαίνει ότι στέλνονται παραπάνω µη οφέλιµα πακέτα όπως PollGrant, PollRequest, κτλ. 59

Test Class #Samples Average 802.11-ftp-norts- nohn-nodes16- error0 Ping 15 0.81364 Ping 15 0.669833 Ping 12 0.810025 Ping 19 0.159558 Ping 18 0.227278 802.11-ftp-nortsnodes16-error0 802.11-ftp-rtsnodes16-error0 dpolling-50ms-ftppoll-nodes16-error0 dpolling-100ms-ftppoll-nodes16-error0 dpolling-400ms-ftppoll-nodes16-error0 Ping 16 0.507006 Πίνακας 2: παρουσιάζει το µέσο όρο του RTT των Ping πακέτων για κάθε πρωτόκολλο Σύγκριση του 802.11 µε το DPolling µε slot period = 50 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του RTT των Ping πακέτων από το 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από το παραπάνω φαίνεται η προτεραιότητα που δίνουµε στα πακέτα της other_queue η οποία είναι ίδια µε την προτεραιότητα της voip_queue. 60

Σύγκριση του 802.11 µε το DPolling µε slot period = 100 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του RTT των Ping πακέτων από το 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από το παραπάνω φαίνεται η προτεραιότητα που δίνουµε στα πακέτα της other_queue η οποία είναι ίδια µε την προτεραιότητα της voip_queue. Σύγκριση του 802.11 µε το DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του RTT των Ping πακέτων από το 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από το παραπάνω φαίνεται η προτεραιότητα που δίνουµε στα πακέτα της other_queue η οποία είναι ίδια µε την προτεραιότητα της voip_queue. Σύγκριση του DPolling µε slot period = 50 ms, του DPolling µε slot period = 100 ms και DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι όσο µεγαλώνει το slot period τόσο µεγαλώνει ο µέσος όρος του RTT των Ping πακέτων. Αυτό συµβαίνει επειδή όταν µεγαλώνει το slot period τότε αυξάνεται και ο αριθµός των ftp bytes που περνάνε ανά γύρα µε αποτέλεσµα να καθυστερούν τα Ping πακέτα. 61

Γραφική παράσταση 1: παρουσιάζει το RTT των Ping πακέτων για κάθε πρωτόκολλο συναρτήσει του χρόνου. 62

Γραφική παράσταση 2: παρουσιάζει τα bytes που δέχτηκε κάθε κόµβος 63

Γραφική παράσταση 3: παρουσιάζει τα bytes που έστειλε κάθε κόµβος. Σύγκριση του 802.11 µε το DPolling µε slot period = 50 ms Εδώ παρατηρούµε ότι η καµπύλη του δικού µας πρωτοκόλλου είναι οµαλή πράγµα που σηµαίνει ότι µπορούµε να εγγυηθούµε ένα σταθερό bandwidth σε κάθε κόµβο. Αντιθέτως στο 802.11 µε την παρουσία κρυµµένου κόµβου χωρίς RTS/CTS πακέτα όλοι οι κόµβοι εκτός του 0 παρουσιάζουν ελάχιστη κίνηση ενώ στο 802.11 µε την παρουσία κρυµµένου κόµβου µε RTS/CTS πακέτα κάποιοι κόµβοι έχουν ελάχιστη κίνηση. Σύγκριση του 802.11 µε το DPolling µε slot period = 100 ms Εδώ παρατηρούµε ότι η καµπύλη του δικού µας πρωτοκόλλου είναι οµαλή πράγµα που σηµαίνει ότι µπορούµε να εγγυηθούµε ένα σταθερό bandwidth σε κάθε κόµβο. Αντιθέτως στο 802.11 µε την παρουσία κρυµµένου κόµβου χωρίς RTS/CTS πακέτα όλοι οι κόµβοι εκτός του 0 παρουσιάζουν ελάχιστη κίνηση ενώ στο 802.11 µε την παρουσία κρυµµένου κόµβου µε RTS/CTS πακέτα κάποιοι κόµβοι έχουν ελάχιστη κίνηση. 64

Σύγκριση του 802.11 µε το DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι η καµπύλη του δικού µας πρωτοκόλλου είναι οµαλή πράγµα που σηµαίνει ότι µπορούµε να εγγυηθούµε ένα σταθερό bandwidth σε κάθε κόµβο. Αντιθέτως στο 802.11 µε την παρουσία κρυµµένου κόµβου χωρίς RTS/CTS πακέτα όλοι οι κόµβοι εκτός του 0 παρουσιάζουν ελάχιστη κίνηση ενώ στο 802.11 µε την παρουσία κρυµµένου κόµβου µε RTS/CTS πακέτα κάποιοι κόµβοι έχουν ελάχιστη κίνηση. 5.1.2 Παραδείγµατα FTP κίνησης µε παρουσία θορύβου Παράδειγµα 1 Στο παράδειγµα αυτό τρέξαµε τον NS για 10 sec µε αριθµό κόµβων 8, µε παρουσία θορύβου 0.0001 (1 στα 10000 bytes κατεστραµµένο) και µε το bandwidth να είναι 11Mb. Επίσης συµµετείχαν 6 τεστ όπου το 1 ο τεστ περιλαµβάνει το 802.11 πρωτόκολλο χωρίς την ύπαρξη κρυµµένου κόµβου και χωρίς RTS/CTS πακέτα, το 2 ο τεστ περιλαµβάνει το 802.11 πρωτόκολλο µε την ύπαρξη κρυµµένου κόµβου και χωρίς RTS/CTS πακέτα, το 3 ο τεστ περιλαµβάνει το 802.11 πρωτόκολλο µε την ύπαρξη κρυµµένου κόµβου και µε RTS/CTS πακέτα, το 4 ο τεστ περιλαµβάνει το δικό µας πρωτόκολλο (DPOLLING) µε την ύπαρξη κρυµµένου κόµβου και µε slot period=50 ms, το 5 ο τεστ περιλαµβάνει το δικό µας πρωτόκολλο (DPOLLING) µε την ύπαρξη κρυµµένου κόµβου και µε slot period=100 ms και το 6 ο τεστ περιλαµβάνει το δικό µας πρωτόκολλο (DPOLLING) µε την ύπαρξη κρυµµένου κόµβου και µε slot period=400 ms..παρακάτω φαίνονται µερικά αποτελέσµατα. Test Class Last Rx Avg_Throughput 802.11-ftp-norts- nohn-nodes8- error0.0001 Ftp 9.99761 4.44657e+06 Ftp 9.9984 3.70813e+06 802.11-ftp-nortsnodes8-error0.0001 802.11-ftp-rtsnodes8-error0.0001 Ftp 9.99754 2.9321e+06 65

dpolling-50ms-ftp- poll-nodes8- error0.0001 Ftp 9.99736 4.06959e+06 dpolling-100ms-ftp- poll-nodes8- error0.0001 Ftp 9.99913 4.51489e+06 dpolling-400ms-ftp- poll-nodes8- error0.0001 Ftp 9.99703 4.67851e+06 Πίνακας 1: παρουσιάζει το AVERAGE_THROUGHPUT για κάθε πρωτόκολλο Σύγκριση του 802.11 µε το DPolling µε slot period = 50 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερη απόδοση από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Σύγκριση του 802.11 µε το DPolling µε slot period = 100 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερη απόδοση από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Σύγκριση του 802.11 µε το DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερη απόδοση από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Σύγκριση του DPolling µε slot period = 50 ms, του DPolling µε slot period = 100 ms και DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι όσο µεγαλώνει το slot period τόσο µεγαλώνει η απόδοση. Αυτό συµβαίνει επειδή όταν µεγαλώνει το slot period τότε αυξάνεται και ο αριθµός των ftp bytes που περνάνε ανά γύρα. Αντιθέτως όταν είναι µικρό το slot period τότε µειώνονται τα ftp bytes που περνάνε ανά γύρα και αυξάνονται οι γύρες, πράγµα που σηµαίνει ότι στέλνονται παραπάνω µη οφέλιµα πακέτα όπως PollGrant, PollRequest, κτλ. 66

Test Class #Samples Average 802.11-ftp-norts- nohn-nodes8- error0.0001 Ping 16 0.587175 Ping 16 0.550837 Ping 18 0.635006 802.11-ftp-nortsnodes8-error0.0001 802.11-ftp-rtsnodes8-error0.0001 dpolling-50ms-ftp- poll-nodes8- error0.0001 Ping 19 0.141537 dpolling-100ms-ftp- poll-nodes8- error0.0001 Ping 19 0.206311 dpolling-400ms-ftp- poll-nodes8- error0.0001 Ping 19 0.224842 Πίνακας 2: παρουσιάζει το µέσο όρο του RTT των Ping πακέτων για κάθε πρωτόκολλο Σύγκριση του 802.11 µε το DPolling µε slot period = 50 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του RTT των Ping πακέτων από το 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από το παραπάνω φαίνεται η προτεραιότητα που 67

δίνουµε στα πακέτα της other_queue η οποία είναι ίδια µε την προτεραιότητα της voip_queue. Σύγκριση του 802.11 µε το DPolling µε slot period = 100 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του RTT των Ping πακέτων από το 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από το παραπάνω φαίνεται η προτεραιότητα που δίνουµε στα πακέτα της other_queue η οποία είναι ίδια µε την προτεραιότητα της voip_queue. Σύγκριση του 802.11 µε το DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του RTT των Ping πακέτων από το 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από το παραπάνω φαίνεται η προτεραιότητα που δίνουµε στα πακέτα της other_queue η οποία είναι ίδια µε την προτεραιότητα της voip_queue. Σύγκριση του DPolling µε slot period = 50 ms, του DPolling µε slot period = 100 ms και DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι όσο µεγαλώνει το slot period τόσο µεγαλώνει ο µέσος όρος του RTT των Ping πακέτων. Αυτό συµβαίνει επειδή όταν µεγαλώνει το slot period τότε αυξάνεται και ο αριθµός των ftp bytes που περνάνε ανά γύρα µε αποτέλεσµα να καθυστερούν τα Ping πακέτα. 68

Γραφική παράσταση 1: παρουσιάζει το RTT των Ping πακέτων για κάθε πρωτόκολλο συναρτήσει του χρόνου. 69

Γραφική παράσταση 2: παρουσιάζει τα bytes που δέχτηκε κάθε κόµβος 70

Γραφική παράσταση 3: παρουσιάζει τα bytes που έστειλε κάθε κόµβος. Σύγκριση του 802.11 µε το DPolling µε slot period = 50 ms Εδώ παρατηρούµε ότι η καµπύλη του δικού µας πρωτοκόλλου είναι οµαλή πράγµα που σηµαίνει ότι µπορούµε να εγγυηθούµε ένα σταθερό bandwidth σε κάθε κόµβο. Αντιθέτως στο 802.11 µε την παρουσία κρυµµένου κόµβου χωρίς RTS/CTS πακέτα όλοι οι κόµβοι εκτός του 0 παρουσιάζουν ελάχιστη κίνηση ενώ στο 802.11 µε την παρουσία κρυµµένου κόµβου µε RTS/CTS πακέτα κάποιοι κόµβοι έχουν ελάχιστη κίνηση. Σύγκριση του 802.11 µε το DPolling µε slot period = 100 ms Εδώ παρατηρούµε ότι η καµπύλη του δικού µας πρωτοκόλλου είναι οµαλή πράγµα που σηµαίνει ότι µπορούµε να εγγυηθούµε ένα σταθερό bandwidth σε κάθε κόµβο. Αντιθέτως στο 802.11 µε την παρουσία κρυµµένου κόµβου χωρίς RTS/CTS πακέτα όλοι οι κόµβοι εκτός του 0 παρουσιάζουν ελάχιστη κίνηση ενώ στο 802.11 µε την παρουσία κρυµµένου κόµβου µε RTS/CTS πακέτα κάποιοι κόµβοι έχουν ελάχιστη κίνηση. 71

Σύγκριση του 802.11 µε το DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι η καµπύλη του δικού µας πρωτοκόλλου είναι οµαλή πράγµα που σηµαίνει ότι µπορούµε να εγγυηθούµε ένα σταθερό bandwidth σε κάθε κόµβο. Αντιθέτως στο 802.11 µε την παρουσία κρυµµένου κόµβου χωρίς RTS/CTS πακέτα όλοι οι κόµβοι εκτός του 0 παρουσιάζουν ελάχιστη κίνηση ενώ στο 802.11 µε την παρουσία κρυµµένου κόµβου µε RTS/CTS πακέτα κάποιοι κόµβοι έχουν ελάχιστη κίνηση. Παράδειγµα 2 Στο παράδειγµα αυτό τρέξαµε τον NS για 10 sec µε αριθµό κόµβων 16, µε παρουσία θορύβου 0.0001 (1 στα 10000 bytes κατεστραµµένο) και µε το bandwidth να είναι 11Mb. Επίσης συµµετείχαν 6 τεστ όπου το 1 ο τεστ περιλαµβάνει το 802.11 πρωτόκολλο χωρίς την ύπαρξη κρυµµένου κόµβου και χωρίς RTS/CTS πακέτα, το 2 ο τεστ περιλαµβάνει το 802.11 πρωτόκολλο µε την ύπαρξη κρυµµένου κόµβου και χωρίς RTS/CTS πακέτα, το 3 ο τεστ περιλαµβάνει το 802.11 πρωτόκολλο µε την ύπαρξη κρυµµένου κόµβου και µε RTS/CTS πακέτα, το 4 ο τεστ περιλαµβάνει το δικό µας πρωτόκολλο (DPOLLING) µε την ύπαρξη κρυµµένου κόµβου και µε slot period=50 ms, το 5 ο τεστ περιλαµβάνει το δικό µας πρωτόκολλο (DPOLLING) µε την ύπαρξη κρυµµένου κόµβου και µε slot period=100 ms και το 6 ο τεστ περιλαµβάνει το δικό µας πρωτόκολλο (DPOLLING) µε την ύπαρξη κρυµµένου κόµβου και µε slot period=400 ms. Παρακάτω φαίνονται µερικά αποτελέσµατα. Test Class Last Rx Avg_Throughput 802.11-ftp-norts- nohn-nodes16- error0.0001 Ftp 9.99956 4.40063e+06 Ftp 9.9981 3.57839e+06 802.11-ftp-nortsnodes16-error0.0001 802.11-ftp-rtsnodes16-error0.0001 Ftp 9.99783 2.88952e+06 72

dpolling-50ms-ftp- poll-nodes16- error0.0001 Ftp 9.9994 3.00352e+06 dpolling-100ms-ftp- poll-nodes16- error0.0001 Ftp 9.99757 3.94925e+06 dpolling-400ms-ftp- poll-nodes16- error0.0001 Ftp 9.99641 4.50554e+06 Πίνακας 1: παρουσιάζει το AVERAGE_THROUGHPUT για κάθε πρωτόκολλο Σύγκριση του 802.11 µε το DPolling µε slot period = 50 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερη απόδοση από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και µικρότερη από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Σύγκριση του 802.11 µε το DPolling µε slot period = 100 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερη απόδοση από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Σύγκριση του 802.11 µε το DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερη απόδοση από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Σύγκριση του DPolling µε slot period = 50 ms, του DPolling µε slot period = 100 ms και DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι όσο µεγαλώνει το slot period τόσο µεγαλώνει η απόδοση. Αυτό συµβαίνει επειδή όταν µεγαλώνει το slot period τότε αυξάνεται και ο αριθµός των ftp bytes που περνάνε ανά γύρα. Αντιθέτως όταν είναι µικρό το slot period τότε µειώνονται τα ftp bytes που περνάνε ανά 73

γύρα και αυξάνονται οι γύρες, πράγµα που σηµαίνει ότι στέλνονται παραπάνω µη οφέλιµα πακέτα όπως PollGrant, PollRequest, κτλ. Test Class #Samples Average 802.11-ftp-norts- nohn-nodes16- error0.0001 Ping 16 0.764544 Ping 16 0.594137 Ping 15 0.891533 802.11-ftp-nortsnodes16-error0.0001 802.11-ftp-rtsnodes16-error0.0001 dpolling-50ms-ftp- poll-nodes16- error0.0001 Ping 19 0.200847 dpolling-100ms-ftp- poll-nodes16- error0.0001 Ping 18 0.273017 dpolling-400ms-ftp- poll-nodes16- error0.0001 Ping 18 0.460956 Πίνακας 2: παρουσιάζει το µέσο όρο του RTT των Ping πακέτων για κάθε πρωτόκολλο 74

Σύγκριση του 802.11 µε το DPolling µε slot period = 50 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του RTT των Ping πακέτων από το 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από το παραπάνω φαίνεται η προτεραιότητα που δίνουµε στα πακέτα της other_queue η οποία είναι ίδια µε την προτεραιότητα της voip_queue. Σύγκριση του 802.11 µε το DPolling µε slot period = 100 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του RTT των Ping πακέτων από το 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από το παραπάνω φαίνεται η προτεραιότητα που δίνουµε στα πακέτα της other_queue η οποία είναι ίδια µε την προτεραιότητα της voip_queue. Σύγκριση του 802.11 µε το DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του RTT των Ping πακέτων από το 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από το παραπάνω φαίνεται η προτεραιότητα που δίνουµε στα πακέτα της other_queue η οποία είναι ίδια µε την προτεραιότητα της voip_queue. Σύγκριση του DPolling µε slot period = 50 ms, του DPolling µε slot period = 100 ms και DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι όσο µεγαλώνει το slot period τόσο µεγαλώνει ο µέσος όρος του RTT των Ping πακέτων. Αυτό συµβαίνει επειδή όταν µεγαλώνει το slot period τότε αυξάνεται και ο αριθµός των ftp bytes που περνάνε ανά γύρα µε αποτέλεσµα να καθυστερούν τα Ping πακέτα. 75

Γραφική παράσταση 1: παρουσιάζει το RTT των Ping πακέτων για κάθε πρωτόκολλο συναρτήσει του χρόνου. 76

Γραφική παράσταση 2: παρουσιάζει τα bytes που δέχτηκε κάθε κόµβος 77

Γραφική παράσταση 3: παρουσιάζει τα bytes που έστειλε κάθε κόµβος. Σύγκριση του 802.11 µε το DPolling µε slot period = 50 ms Εδώ παρατηρούµε ότι η καµπύλη του δικού µας πρωτοκόλλου είναι οµαλή πράγµα που σηµαίνει ότι µπορούµε να εγγυηθούµε ένα σταθερό bandwidth σε κάθε κόµβο. Αντιθέτως στο 802.11 µε την παρουσία κρυµµένου κόµβου χωρίς RTS/CTS πακέτα όλοι οι κόµβοι εκτός του 0 παρουσιάζουν ελάχιστη κίνηση ενώ στο 802.11 µε την παρουσία κρυµµένου κόµβου µε RTS/CTS πακέτα κάποιοι κόµβοι έχουν ελάχιστη κίνηση. Σύγκριση του 802.11 µε το DPolling µε slot period = 100 ms Εδώ παρατηρούµε ότι η καµπύλη του δικού µας πρωτοκόλλου είναι οµαλή πράγµα που σηµαίνει ότι µπορούµε να εγγυηθούµε ένα σταθερό bandwidth σε κάθε κόµβο. Αντιθέτως στο 802.11 µε την παρουσία κρυµµένου κόµβου χωρίς RTS/CTS πακέτα όλοι οι κόµβοι εκτός του 0 παρουσιάζουν ελάχιστη κίνηση ενώ στο 802.11 µε την παρουσία κρυµµένου κόµβου µε RTS/CTS πακέτα κάποιοι κόµβοι έχουν ελάχιστη κίνηση. 78

Σύγκριση του 802.11 µε το DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι η καµπύλη του δικού µας πρωτοκόλλου είναι οµαλή πράγµα που σηµαίνει ότι µπορούµε να εγγυηθούµε ένα σταθερό bandwidth σε κάθε κόµβο. Αντιθέτως στο 802.11 µε την παρουσία κρυµµένου κόµβου χωρίς RTS/CTS πακέτα όλοι οι κόµβοι εκτός του 0 παρουσιάζουν ελάχιστη κίνηση ενώ στο 802.11 µε την παρουσία κρυµµένου κόµβου µε RTS/CTS πακέτα κάποιοι κόµβοι έχουν ελάχιστη κίνηση. 5.1.3 Παραδείγµατα VoIP και FTP κίνησης χωρίς παρουσία θορύβου Παράδειγµα 1 Στο παράδειγµα αυτό τρέξαµε τον NS για 10 sec µε αριθµό κόµβων 8, χωρίς παρουσία θορύβου και µε το bandwidth να είναι 11Mb. Επίσης συµµετείχαν 6 τεστ όπου το 1 ο τεστ περιλαµβάνει το 802.11 πρωτόκολλο χωρίς την ύπαρξη κρυµµένου κόµβου και χωρίς RTS/CTS πακέτα, το 2 ο τεστ περιλαµβάνει το 802.11 πρωτόκολλο µε την ύπαρξη κρυµµένου κόµβου και χωρίς RTS/CTS πακέτα, το 3 ο τεστ περιλαµβάνει το 802.11 πρωτόκολλο µε την ύπαρξη κρυµµένου κόµβου και µε RTS/CTS πακέτα, το 4 ο τεστ περιλαµβάνει το δικό µας πρωτόκολλο (DPOLLING) µε την ύπαρξη κρυµµένου κόµβου και µε slot period=50 ms, το 5 ο τεστ περιλαµβάνει το δικό µας πρωτόκολλο (DPOLLING) µε την ύπαρξη κρυµµένου κόµβου και µε slot period=100 ms και το 6 ο τεστ περιλαµβάνει το δικό µας πρωτόκολλο (DPOLLING) µε την ύπαρξη κρυµµένου κόµβου και µε slot period=400 ms. Παρακάτω φαίνονται µερικά αποτελέσµατα. Test Class Last Rx Avg_Throughput 802.11-voipftp- norts-nohn-nodes8- error0 Ftp 9.9984 3.41856e+06 802.11-voipftp- norts-nohn-nodes8- error0 VoIP 9.99668 114163 802.11-voipftpnorts-nodes8-error0 Ftp 9.99669 2.31994e+06 79

VoIP 9.99771 108774 Ftp 9.99306 1.39854e+06 VoIP 9.99873 105255 802.11-voipftpnorts-nodes8-error0 802.11-voipftp-rtsnodes8-error0 802.11-voipftp-rtsnodes8-error0 dpolling-50ms- voipftp-poll-nodes8- error0 Ftp 9.99878 4.26738e+06 dpolling-50ms- voipftp-poll-nodes8- error0 VoIP 9.99139 119348 dpolling-100ms- voipftp-poll-nodes8- error0 Ftp 9.99771 4.98256e+06 dpolling-100ms- voipftp-poll-nodes8- error0 VoIP 9.97854 119296 dpolling-400ms- voipftp-poll-nodes8- error0 Ftp 9.98632 5.79384e+06 80

dpolling-400ms- voipftp-poll-nodes8- error0 VoIP 9.93597 118158 Πίνακας 1: παρουσιάζει το AVERAGE_THROUGHPUT κάθε κίνησης(voip και FTP) για κάθε πρωτόκολλο Σύγκριση του 802.11 µε το DPolling µε slot period = 50 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερη απόδοση και για τα 2 είδη πακέτων (FTP,VoIP) από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Σύγκριση του 802.11 µε το DPolling µε slot period = 100 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερη απόδοση και για τα 2 είδη πακέτων (FTP,VoIP) από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Σύγκριση του 802.11 µε το DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερη απόδοση και για τα 2 είδη πακέτων (FTP,VoIP) από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Σύγκριση του DPolling µε slot period = 50 ms, του DPolling µε slot period = 100 ms και DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι όσο µεγαλώνει το slot period τόσο µεγαλώνει η FTP κίνηση και µικραίνει η VoIP κίνηση. Αυτό συµβαίνει επειδή όταν µεγαλώνει το slot period τότε αυξάνεται και ο αριθµός των ftp bytes που περνάνε ανά γύρα. Αντιθέτως όταν είναι µικρό το slot period τότε µειώνονται τα ftp bytes που περνάνε ανά γύρα και αυξάνονται οι γύρες.. 81

Test Class #Samples Average 802.11-voipftp- norts-nohn-nodes8- error0 Ping 33 0.6741 Ping 29 0.70321 Ping 27 0.974344 802.11-voipftpnorts-nodes8-error0 802.11-voipftp-rtsnodes8-error0 dpolling-50ms- voipftp-poll-nodes8- error0 Ping 37 0.121376 dpolling-100ms- voipftp-poll-nodes8- error0 Ping 37 0.186141 dpolling-400ms- voipftp-poll-nodes8- error0 Ping 37 0.402149 Πίνακας 2: παρουσιάζει το µέσο όρο του RTT των Ping πακέτων για κάθε πρωτόκολλο Σύγκριση του 802.11 µε το DPolling µε slot period = 50 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του RTT των Ping πακέτων από το 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από το παραπάνω φαίνεται η προτεραιότητα που 82

δίνουµε στα πακέτα της other_queue η οποία είναι ίδια µε την προτεραιότητα της voip_queue. Σύγκριση του 802.11 µε το DPolling µε slot period = 100 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του RTT των Ping πακέτων από το 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από το παραπάνω φαίνεται η προτεραιότητα που δίνουµε στα πακέτα της other_queue η οποία είναι ίδια µε την προτεραιότητα της voip_queue. Σύγκριση του 802.11 µε το DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του RTT των Ping πακέτων από το 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από το παραπάνω φαίνεται η προτεραιότητα που δίνουµε στα πακέτα της other_queue η οποία είναι ίδια µε την προτεραιότητα της voip_queue. Σύγκριση του DPolling µε slot period = 50 ms, του DPolling µε slot period = 100 ms και DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι όσο µεγαλώνει το slot period τόσο µεγαλώνει ο µέσος όρος του RTT των Ping πακέτων. Αυτό συµβαίνει επειδή όταν µεγαλώνει το slot period τότε αυξάνεται και ο αριθµός των ftp bytes που περνάνε ανά γύρα µε αποτέλεσµα να καθυστερούν τα Ping πακέτα. 83

Γραφική παράσταση 1: παρουσιάζει το RTT των Ping πακέτων για κάθε πρωτόκολλο συναρτήσει του χρόνου. Test Class #Samples Average 802.11-voipftp- norts-nohn-nodes8- error0 VoIP 53 2.88667 802.11-voipftpnorts-nodes8-error0 VoIP 35 4.16825 84

VoIP 37 4.01769 802.11-voipftp-rtsnodes8-error0 dpolling-50ms- voipftp-poll-nodes8- error0 VoIP 56 4.36174 dpolling-100ms- voipftp-poll-nodes8- error0 VoIP 56 4.31238 dpolling-400ms- voipftp-poll-nodes8- error0 VoIP 56 3.30829 Πίνακας 3: παρουσιάζει το µέσο όρο του MOS της VoIP κλήσης για κάθε πρωτόκολλο Σύγκριση του 802.11 µε το DPolling µε slot period = 50 ms Εδώ παρατηρούµαι ότι το πρωτόκολλό µας παρουσιάζει µεγαλύτερο µέσο όρο του MOS της VoIP κλήσης από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου,από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από τον αντίστοιχο του 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από το παραπάνω φαίνεται ότι έχουµε καλύτερη ποιότητα VoIP κλήσης. Σύγκριση του 802.11 µε το DPolling µε slot period = 100 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερο µέσο όρο του MOS της VoIP κλήσης από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από τον αντίστοιχο του 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από το παραπάνω φαίνεται ότι έχουµε καλύτερη ποιότητα VoIP κλήσης. 85

Σύγκριση του 802.11 µε το DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του MOS της VoIP κλήσης από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από τον αντίστοιχο του 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Αυτό οφείλεται στο µεγάλο slot period, όπου περνάει µεγάλη FTP κίνηση ανά γύρα µε αποτέλεσµα να καθυστερεί την VoIP κίνηση. Σύγκριση του DPolling µε slot period = 50 ms, του DPolling µε slot period = 100 ms και DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι όσο µεγαλώνει το slot period τόσο µικραίνει ο µέσος όρος του MOS της VoIP κλήσης. Αυτό συµβαίνει επειδή όταν µεγαλώνει το slot period τότε αυξάνεται και ο αριθµός των ftp bytes που περνάνε ανά γύρα µε αποτέλεσµα να καθυστερεί και να µειώνεται η VoIP κίνηση. Test Class #Samples Average 802.11-voipftp- norts-nohn-nodes8- error0 VoIP 53 0.376857 VoIP 35 0.144501 VoIP 37 0.201288 802.11-voipftpnorts-nodes8-error0 802.11-voipftp-rtsnodes8-error0 dpolling-50ms- voipftp-poll-nodes8- error0 VoIP 56 0.0932366 dpolling-100ms- voipftp-poll-nodes8- error0 VoIP 56 0.15587 86

dpolling-400ms- voipftp-poll-nodes8- error0 VoIP 56 0.353895 Πίνακας 4: παρουσιάζει το µέσο όρο του VoIP DeLay των VoIP πακέτων για κάθε πρωτόκολλο Σύγκριση του 802.11 µε το DPolling µε slot period = 50 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του VoIPDelay των VoIP πακέτων από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από τον αντίστοιχο του 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από τα παραπάνω φαίνεται ότι τα πακέτα VoIP στο πρωτόκολλό µας µένουν λιγότερη ώρα στην ουρά (γρήγορη εξυπηρέτηση). Σύγκριση του 802.11 µε το DPolling µε slot period = 100 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του VoIPDelay των VoIP πακέτων από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου και από τον αντίστοιχο του 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Αντιθέτως είναι µεγαλύτερος από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Σύγκριση του 802.11 µε το DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερο µέσο όρο του VoIPDelay των VoIP πακέτων από τον αντοίστοιχο του 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από τον αντίστοιχο του 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Αυτό οφείλεται στο µεγάλο slot period, όπου περνάει περισσότερη FTP κίνηση ανά γυρα πράγµα που καθυστερεί της VoIP κίνηση. Σύγκριση του DPolling µε slot period = 50 ms, του DPolling µε slot period = 100 ms και DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι όσο µεγαλώνει το slot period τόσο µεγαλώνει ο µέσος όρος του VoIPDelay των VoIP πακέτων. Αυτό συµβαίνει επειδή όταν µεγαλώνει το slot period τότε αυξάνεται και ο αριθµός των ftp bytes που περνάνε ανά γύρα µε αποτέλεσµα να καθυστερεί η VoIP κίνηση. 87

Γραφική παράσταση 2: παρουσιάζει το VoIP Delay των VoIP πακέτων για κάθε πρωτόκολλο συναρτήσει του χρόνου. Παράδειγµα 2 Στο παράδειγµα αυτό τρέξαµε τον NS για 10 sec µε αριθµό κόµβων 16, χωρίς παρουσία θορύβου και µε το bandwidth να είναι 11Mb. Επίσης συµµετείχαν 6 τεστ όπου το 1 ο τεστ περιλαµβάνει το 802.11 πρωτόκολλο χωρίς την ύπαρξη κρυµµένου κόµβου και χωρίς RTS/CTS πακέτα, το 2 ο τεστ περιλαµβάνει το 802.11 πρωτόκολλο µε την ύπαρξη κρυµµένου κόµβου και χωρίς RTS/CTS πακέτα, το 3 ο τεστ περιλαµβάνει το 802.11 πρωτόκολλο µε την ύπαρξη κρυµµένου κόµβου και µε RTS/CTS πακέτα, το 4 ο τεστ περιλαµβάνει το δικό µας πρωτόκολλο (DPOLLING) µε την ύπαρξη κρυµµένου κόµβου και µε slot period=50 ms, το 5 ο τεστ περιλαµβάνει το δικό µας πρωτόκολλο (DPOLLING) µε την ύπαρξη κρυµµένου κόµβου και µε slot period=100 ms και το 6 ο τεστ περιλαµβάνει το δικό µας πρωτόκολλο (DPOLLING) µε την ύπαρξη κρυµµένου κόµβου και µε slot period=400 ms. Παρακάτω φαίνονται µερικά αποτελέσµατα. 88

Test Class Last Rx Avg_Throughput 802.11-voipftp- norts-nohn-nodes16- error0 Ftp 9.99551 1.64888e+06 802.11-voipftp- norts-nohn-nodes16- error0 VoIP 9.99898 249165 802.11-voipftp- norts-nodes16- error0 Ftp 9.98296 280029 802.11-voipftp- norts-nodes16- error0 VoIP 9.99974 203909 Ftp 9.26348 213933 VoIP 9.9953 140969 Ftp 9.9925 2.52352e+06 802.11-voipftp-rtsnodes16-error0 802.11-voipftp-rtsnodes16-error0 dpolling-50msvoipftp-pollnodes16-error0 dpolling-50msvoipftp-pollnodes16-error0 VoIP 9.96312 272801 89

Ftp 9.99832 3.14062e+06 VoIP 9.99974 270727 Ftp 9.99295 4.32586e+06 dpolling-100msvoipftp-pollnodes16-error0 dpolling-100msvoipftp-pollnodes16-error0 dpolling-400msvoipftp-pollnodes16-error0 dpolling-400msvoipftp-pollnodes16-error0 VoIP 9.99637 265133 Πίνακας 1: παρουσιάζει το AVERAGE_THROUGHPUT κάθε κίνησης(voip και FTP) για κάθε πρωτόκολλο Σύγκριση του 802.11 µε το DPolling µε slot period = 50 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερη απόδοση και για τα 2 είδη πακέτων (FTP,VoIP) από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και µικρότερη από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Σύγκριση του 802.11 µε το DPolling µε slot period = 100 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερη απόδοση και για τα 2 είδη πακέτων (FTP,VoIP) από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. 90

Σύγκριση του 802.11 µε το DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερη απόδοση και για τα 2 είδη πακέτων (FTP,VoIP) από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Σύγκριση του DPolling µε slot period = 50 ms, του DPolling µε slot period = 100 ms και DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι όσο µεγαλώνει το slot period τόσο µεγαλώνει η FTP κίνηση και µικραίνει η VoIP κίνηση. Αυτό συµβαίνει επειδή όταν µεγαλώνει το slot period τότε αυξάνεται και ο αριθµός των ftp bytes που περνάνε ανά γύρα. Αντιθέτως όταν είναι µικρό το slot period τότε µειώνονται τα ftp bytes που περνάνε ανά γύρα και αυξάνονται οι γύρες. Test Class #Samples Average 802.11-voipftp- norts-nohn-nodes16- error0 Ping 30 1.29811 802.11-voipftp- norts-nodes16- error0 Ping 16 1.57611 Ping 6 3.83082 Ping 37 0.210497 802.11-voipftp-rtsnodes16-error0 dpolling-50msvoipftp-pollnodes16-error0 dpolling-100msvoipftp-pollnodes16-error0 Ping 37 0.273222 91

dpolling-400msvoipftp-pollnodes16-error0 Ping 37 0.631789 Πίνακας 2: παρουσιάζει το µέσο όρο του πρωτόκολλο RTT των Ping πακέτων για κάθε Σύγκριση του 802.11 µε το DPolling µε slot period = 50 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του RTT των Ping πακέτων από το 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από το παραπάνω φαίνεται η προτεραιότητα που δίνουµε στα πακέτα της other_queue η οποία είναι ίδια µε την προτεραιότητα της voip_queue. Σύγκριση του 802.11 µε το DPolling µε slot period = 100 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του RTT των Ping πακέτων από το 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από το παραπάνω φαίνεται η προτεραιότητα που δίνουµε στα πακέτα της other_queue η οποία είναι ίδια µε την προτεραιότητα της voip_queue. Σύγκριση του 802.11 µε το DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του RTT των Ping πακέτων από το 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από το παραπάνω φαίνεται η προτεραιότητα που δίνουµε στα πακέτα της other_queue η οποία είναι ίδια µε την προτεραιότητα της voip_queue. Σύγκριση του DPolling µε slot period = 50 ms,του DPolling µε slot period = 100 ms και DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι όσο µεγαλώνει το slot period τόσο µεγαλώνει ο µέσος όρος του RTT των Ping πακέτων. Αυτό συµβαίνει επειδή όταν µεγαλώνει το 92

slot period τότε αυξάνεται και ο αριθµός των ftp bytes που περνάνε ανά γύρα µε αποτέλεσµα να καθυστερούν τα Ping πακέτα. Γραφική παράσταση 1: παρουσιάζει το RTT των Ping πακέτων για κάθε πρωτόκολλο συναρτήσει του χρόνου. 93

Test Class #Samples Average 802.11-voipftp- norts-nohn-nodes16- error0 VoIP 111 2.81248 802.11-voipftp- norts-nodes16- error0 VoIP 51 1.43149 VoIP 36 1.50236 VoIP 125 4.30728 VoIP 124 4.16975 802.11-voipftp-rtsnodes16-error0 dpolling-50msvoipftp-pollnodes16-error0 dpolling-100msvoipftp-pollnodes16-error0 dpolling-400msvoipftp-pollnodes16-error0 VoIP 118 2.23855 Πίνακας 3: παρουσιάζει το µέσο όρο του MOS της VoIP κλήσης για κάθε πρωτόκολλο Σύγκριση του 802.11 µε το DPolling µε slot period = 50 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερο µέσο όρο του MOS της VoIP κλήσης από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από τον αντίστοιχο του 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου 94

κόµβου. Από το παραπάνω φαίνεται ότι έχουµε καλύτερη ποιότητα VoIP κλήσης. Σύγκριση του 802.11 µε το DPolling µε slot period = 100 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερο µέσο όρο του MOS της VoIP κλήσης από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από τον αντίστοιχο του 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από το παραπάνω φαίνεται ότι έχουµε καλύτερη ποιότητα VoIP κλήσης. Σύγκριση του 802.11 µε το DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερο µέσο όρο του MOS της VoIP κλήσης από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από τον αντίστοιχο του 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από το παραπάνω φαίνεται ότι έχουµε καλύτερη ποιότητα VoIP κλήσης. Σύγκριση του DPolling µε slot period = 50 ms, του DPolling µε slot period = 100 ms και DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι όσο µεγαλώνει το slot period τόσο µικραίνει ο µέσος όρος του MOS της VoIP κλήσης. Αυτό συµβαίνει επειδή όταν µεγαλώνει το slot period τότε αυξάνεται και ο αριθµός των ftp bytes που περνάνε ανά γύρα µε αποτέλεσµα να καθυστερεί και να µειώνεται η VoIP κίνηση. Test Class #Samples Average 802.11-voipftp- norts-nohn-nodes16- error0 VoIP 111 0.478242 802.11-voipftp- norts-nodes16- error0 VoIP 51 0.883325 95

VoIP 36 1.40099 VoIP 125 0.161208 VoIP 124 0.204187 802.11-voipftp-rtsnodes16-error0 dpolling-50msvoipftp-pollnodes16-error0 dpolling-100msvoipftp-pollnodes16-error0 dpolling-400msvoipftp-pollnodes16-error0 VoIP 118 0.52115 Πίνακας 4: παρουσιάζει το µέσο όρο του VoIP DeLay των VoIP πακέτων για κάθε πρωτόκολλο Σύγκριση του 802.11 µε το DPolling µε slot period = 50 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του VoIPDelay των VoIP πακέτων από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από τον αντίστοιχο του 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από τα παραπάνω φαίνεται ότι τα πακέτα VoIP στο πρωτόκολλό µας µένουν λιγότερη ώρα στην ουρά (γρήγορη εξυπηρέτηση). Σύγκριση του 802.11 µε το DPolling µε slot period = 100 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του VoIPDelay των VoIP πακέτων από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από τον αντίστοιχο του 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από τα παραπάνω φαίνεται ότι τα πακέτα VoIP στο πρωτόκολλό µας µένουν λιγότερη ώρα στην ουρά (γρήγορη εξυπηρέτηση). 96

Σύγκριση του 802.11 µε το DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του VoIPDelay των VoIP πακέτων από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από τον αντίστοιχο του 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από τα παραπάνω φαίνεται ότι τα πακέτα VoIP στο πρωτόκολλό µας µένουν λιγότερη ώρα στην ουρά (γρήγορη εξυπηρέτηση). Σύγκριση του DPolling µε slot period = 50 ms, του DPolling µε slot period = 100 ms και DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι όσο µεγαλώνει το slot period τόσο µεγαλώνει ο µέσος όρος του VoIPDelay των VoIP πακέτων. Αυτό συµβαίνει επειδή όταν µεγαλώνει το slot period τότε αυξάνεται και ο αριθµός των ftp bytes που περνάνε ανά γύρα µε αποτέλεσµα να καθυστερεί η VoIP κίνηση. Γραφική παράσταση 2: παρουσιάζει το VoIP Delay των VoIP πακέτων για κάθε πρωτόκολλο συναρτήσει του χρόνου. 97

5.1.4 Παραδείγµατα VoIP και FTP κίνησης µε παρουσία θορύβου Παράδειγµα 1 Στο παράδειγµα αυτό τρέξαµε τον NS για 10 sec µε αριθµό κόµβων 8, µε παρουσία θορύβου 0.0001 (1 στα 10000 bytes κατεστραµµένο) και µε το bandwidth να είναι 11Mb. Επίσης συµµετείχαν 6 τεστ όπου το 1 ο τεστ περιλαµβάνει το 802.11 πρωτόκολλο χωρίς την ύπαρξη κρυµµένου κόµβου και χωρίς RTS/CTS πακέτα, το 2 ο τεστ περιλαµβάνει το 802.11 πρωτόκολλο µε την ύπαρξη κρυµµένου κόµβου και χωρίς RTS/CTS πακέτα, το 3 ο τεστ περιλαµβάνει το 802.11 πρωτόκολλο µε την ύπαρξη κρυµµένου κόµβου και µε RTS/CTS πακέτα, το 4 ο τεστ περιλαµβάνει το δικό µας πρωτόκολλο (DPOLLING) µε την ύπαρξη κρυµµένου κόµβου και µε slot period=50 ms, το 5 ο τεστ περιλαµβάνει το δικό µας πρωτόκολλο (DPOLLING) µε την ύπαρξη κρυµµένου κόµβου και µε slot period=100 ms και το 6 ο τεστ περιλαµβάνει το δικό µας πρωτόκολλο (DPOLLING) µε την ύπαρξη κρυµµένου κόµβου και µε slot period=400 ms. Παρακάτω φαίνονται µερικά αποτελέσµατα. Test Class Last Rx Avg_Throughput 802.11-voipftp- norts-nohn-nodes8- error0.0001 Ftp 9.99962 3.1163e+06 802.11-voipftp- norts-nohn-nodes8- error0.0001 VoIP 9.9931 114178 802.11-voipftp- norts-nodes8- error0.0001 Ftp 9.9928 2.14567e+06 98

802.11-voipftp- norts-nodes8- error0.0001 VoIP 9.99941 107321 Ftp 9.99291 1.17421e+06 VoIP 9.99775 106136 802.11-voipftp-rtsnodes8-error0.0001 802.11-voipftp-rtsnodes8-error0.0001 dpolling-50ms- voipftp-poll-nodes8- error0.0001 Ftp 9.99117 3.44446e+06 dpolling-50ms- voipftp-poll-nodes8- error0.0001 VoIP 9.9946 117772 dpolling-100ms- voipftp-poll-nodes8- error0.0001 Ftp 9.99998 3.91698e+06 dpolling-100ms- voipftp-poll-nodes8- error0.0001 VoIP 9.98898 117582 99

dpolling-400ms- voipftp-poll-nodes8- error0.0001 Ftp 9.99459 4.01894e+06 dpolling-400ms- voipftp-poll-nodes8- error0.0001 VoIP 9.98032 116889 Πίνακας 1: παρουσιάζει το AVERAGE_THROUGHPUT κάθε κίνησης(voip και FTP) για κάθε πρωτόκολλο Σύγκριση του 802.11 µε το DPolling µε slot period = 50 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερη απόδοση και για τα 2 είδη πακέτων (FTP,VoIP) από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και µικρότερη από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Σύγκριση του 802.11 µε το DPolling µε slot period = 100 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερη απόδοση και για τα 2 είδη πακέτων (FTP,VoIP) από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Σύγκριση του 802.11 µε το DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερη απόδοση και για τα 2 είδη πακέτων (FTP,VoIP) από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Σύγκριση του DPolling µε slot period = 50 ms, του DPolling µε slot period = 100 ms και DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι όσο µεγαλώνει το slot period τόσο µεγαλώνει η FTP κίνηση και µικραίνει η VoIP κίνηση. Αυτό συµβαίνει επειδή όταν µεγαλώνει το slot period τότε αυξάνεται και ο αριθµός των ftp bytes που περνάνε ανά γύρα. Αντιθέτως όταν είναι µικρό το slot period τότε µειώνονται τα ftp bytes που περνάνε ανά γύρα και αυξάνονται οι γύρες. 100

Test Class #Samples Average 802.11-voipftp- norts-nohn-nodes8- error0.0001 Ping 33 0.628052 802.11-voipftp- norts-nodes8- error0.0001 Ping 30 0.492897 Ping 31 0.8342 802.11-voipftp-rtsnodes8-error0.0001 dpolling-50ms- voipftp-poll-nodes8- error0.0001 Ping 36 0.156186 dpolling-100ms- voipftp-poll-nodes8- error0.0001 Ping 37 0.228562 dpolling-400ms- voipftp-poll-nodes8- error0.0001 Ping 37 0.212057 Πίνακας 2: παρουσιάζει το µέσο όρο του RTT των Ping πακέτων για κάθε πρωτόκολλο Σύγκριση του 802.11 µε το DPolling µε slot period = 50 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του RTT των Ping πακέτων από το 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από το παραπάνω φαίνεται η προτεραιότητα που 101

δίνουµε στα πακέτα της other_queue η οποία είναι ίδια µε την προτεραιότητα της voip_queue. Σύγκριση του 802.11 µε το DPolling µε slot period = 100 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του RTT των Ping πακέτων από το 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από το παραπάνω φαίνεται η προτεραιότητα που δίνουµε στα πακέτα της other_queue η οποία είναι ίδια µε την προτεραιότητα της voip_queue. Σύγκριση του 802.11 µε το DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του RTT των Ping πακέτων από το 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από το παραπάνω φαίνεται η προτεραιότητα που δίνουµε στα πακέτα της other_queue η οποία είναι ίδια µε την προτεραιότητα της voip_queue. 102

Γραφική παράσταση 1: παρουσιάζει το RTT των Ping πακέτων για κάθε πρωτόκολλο συναρτήσει του χρόνου. Test Class #Samples Average 802.11-voipftp- norts-nohn-nodes8- error0.0001 VoIP 53 2.95247 802.11-voipftp- norts-nodes8- error0.0001 VoIP 32 3.2738 103

VoIP 33 4.13648 802.11-voipftp-rtsnodes8-error0.0001 dpolling-50ms- voipftp-poll-nodes8- error0.0001 VoIP 33 4.34221 dpolling-100ms- voipftp-poll-nodes8- error0.0001 VoIP 36 4.23737 dpolling-400ms- voipftp-poll-nodes8- error0.0001 VoIP 36 4.19765 Πίνακας 3: παρουσιάζει το µέσο όρο του MOS της VoIP κλήσης για κάθε πρωτόκολλο Σύγκριση του 802.11 µε το DPolling µε slot period = 50 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερο µέσο όρο του MOS της VoIP κλήσης από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από τον αντίστοιχο του 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από το παραπάνω φαίνεται ότι έχουµε καλύτερη ποιότητα VoIP κλήσης. Σύγκριση του 802.11 µε το DPolling µε slot period = 100 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερο µέσο όρο του MOS της VoIP κλήσης από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από τον αντίστοιχο του 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από το παραπάνω φαίνεται ότι έχουµε καλύτερη ποιότητα VoIP κλήσης. 104

Σύγκριση του 802.11 µε το DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερο µέσο όρο του MOS της VoIP κλήσης από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από τον αντίστοιχο του 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από το παραπάνω φαίνεται ότι έχουµε καλύτερη ποιότητα VoIP κλήσης. Σύγκριση του DPolling µε slot period = 50 ms, του DPolling µε slot period = 100 ms και DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι όσο µεγαλώνει το slot period τόσο µικραίνει ο µέσος όρος του MOS της VoIP κλήσης. Αυτό συµβαίνει επειδή όταν µεγαλώνει το slot period τότε αυξάνεται και ο αριθµός των ftp bytes που περνάνε ανά γύρα µε αποτέλεσµα να να καθυστερεί και να µειώνεται η VoIP κίνηση. Test Class #Samples Average 802.11-voipftp- norts-nohn-nodes8- error0.0001 VoIP 53 0.362953 802.11-voipftp- norts-nodes8- error0.0001 VoIP 32 0.351958 VoIP 33 0.174959 802.11-voipftp-rtsnodes8-error0.0001 dpolling-50ms- voipftp-poll-nodes8- error0.0001 VoIP 33 0.127165 dpolling-100ms- voipftp-poll-nodes8- error0.0001 VoIP 36 0.181269 105

dpolling-400ms- voipftp-poll-nodes8- error0.0001 VoIP 36 0.194123 Πίνακας 4: παρουσιάζει το µέσο όρο του VoIP DeLay των VoIP πακέτων για κάθε πρωτόκολλο Σύγκριση του 802.11 µε το DPolling µε slot period = 50 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του VoIPDelay των VoIP πακέτων από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από τον αντίστοιχο του 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από τα παραπάνω φαίνεται ότι τα πακέτα VoIP στο πρωτόκολλό µας µένουν λιγότερη ώρα στην ουρά (γρήγορη εξυπηρέτηση). Σύγκριση του 802.11 µε το DPolling µε slot period = 100 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του VoIPDelay των VoIP πακέτων από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου και από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Αντιθέτως είναι µεγαλύτερος από τον αντίστοιχο του 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Σύγκριση του 802.11 µε το DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του VoIPDelay των VoIP πακέτων από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου και από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Αντιθέτως είναι µεγαλύτερος από τον αντίστοιχο του 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Σύγκριση του DPolling µε slot period = 50 ms, του DPolling µε slot period = 100 ms και DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι όσο µεγαλώνει το slot period τόσο µεγαλώνει ο µέσος όρος του VoIPDelay των VoIP πακέτων. Αυτό συµβαίνει επειδή όταν µεγαλώνει το slot period τότε αυξάνεται και ο αριθµός των ftp bytes που περνάνε ανά γύρα µε αποτέλεσµα να καθυστερεί η VoIP κίνηση. 106

Γραφική παράσταση 2: παρουσιάζει το VoIP Delay των VoIP πακέτων για κάθε πρωτόκολλο συναρτήσει του χρόνου. Παράδειγµα 2 Στο παράδειγµα αυτό τρέξαµε τον NS για 10 sec µε αριθµό κόµβων 16, µε παρουσία θορύβου 0.0001 (1 στα 10000 bytes κατεστραµµένο) και µε το bandwidth να είναι 11Mb. Επίσης συµµετείχαν 6 τεστ όπου το 1 ο τεστ περιλαµβάνει το 802.11 πρωτόκολλο χωρίς την ύπαρξη κρυµµένου κόµβου και χωρίς RTS/CTS πακέτα, το 2 ο τεστ περιλαµβάνει το 802.11 πρωτόκολλο µε την ύπαρξη κρυµµένου κόµβου και χωρίς RTS/CTS πακέτα, το 3 ο τεστ περιλαµβάνει το 802.11 πρωτόκολλο µε την ύπαρξη κρυµµένου κόµβου και µε RTS/CTS πακέτα, το 4 ο τεστ περιλαµβάνει το δικό µας πρωτόκολλο (DPOLLING) µε την ύπαρξη κρυµµένου κόµβου και µε slot period=50 ms, το 5 ο τεστ περιλαµβάνει το δικό µας πρωτόκολλο (DPOLLING) µε την ύπαρξη κρυµµένου κόµβου και µε slot period=100 ms και το 6 ο τεστ περιλαµβάνει το δικό µας πρωτόκολλο (DPOLLING) µε την ύπαρξη κρυµµένου κόµβου και µε slot period=400 ms. Παρακάτω φαίνονται µερικά αποτελέσµατα. 107

Test Class Last Rx Avg_Throughput 802.11-voipftp- norts-nohn-nodes16- error0.0001 Ftp 9.99419 1.49871e+06 802.11-voipftp- norts-nohn-nodes16- error0.0001 VoIP 9.9991 248855 802.11-voipftp- norts-nodes16- error0.0001 Ftp 9.97163 286525 802.11-voipftp- norts-nodes16- error0.0001 VoIP 9.99932 201486 Ftp 9.96001 185397 VoIP 9.99962 139346 802.11-voipftp-rtsnodes16-error0.0001 802.11-voipftp-rtsnodes16-error0.0001 dpolling-50msvoipftp-pollnodes16-error0.0001 Ftp 9.99856 2.20286e+06 108

dpolling-50msvoipftp-poll nodes16-error0.0001 VoIP 9.99264 269485 Ftp 9.99985 2.55493e+06 VoIP 9.99134 266624 Ftp 9.99958 3.05522e+06 dpolling-100msvoipftp-pollnodes16-error0.0001 dpolling-100msvoipftp-pollnodes16-error0.0001 dpolling-400msvoipftp-pollnodes16-error0.0001 dpolling-400msvoipftp-pollnodes16-error0.0001 VoIP 9.89758 265659 Πίνακας 1: παρουσιάζει το AVERAGE_THROUGHPUT κάθε κίνησης(voip και FTP) για κάθε πρωτόκολλο Σύγκριση του 802.11 µε το DPolling µε slot period = 50 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερη απόδοση και για τα 2 είδη πακέτων (FTP,VoIP) από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και µικρότερη από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. 109

Σύγκριση του 802.11 µε το DPolling µε slot period = 100 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερη απόδοση και για τα 2 είδη πακέτων (FTP,VoIP) από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Σύγκριση του 802.11 µε το DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερη απόδοση και για τα 2 είδη πακέτων (FTP,VoIP) από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Σύγκριση του DPolling µε slot period = 50 ms, του DPolling µε slot period = 100 ms και DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι όσο µεγαλώνει το slot period τόσο µεγαλώνει η FTP κίνηση και µικραίνει η VoIP κίνηση. Αυτό συµβαίνει επειδή όταν µεγαλώνει το slot period τότε αυξάνεται και ο αριθµός των ftp bytes που περνάνε ανά γύρα. Αντιθέτως όταν είναι µικρό το slot period τότε µειώνονται τα ftp bytes που περνάνε ανά γύρα και αυξάνονται οι γύρες. Test Class #Samples Average 802.11-voipftp- norts-nohn-nodes16- error0.0001 Ping 30 1.36102 802.11-voipftp- norts-nodes16- error0.0001 Ping 18 1.59781 802.11-voipftp-rtsnodes16-error0.0001 Ping 10 3.73018 110

Ping 37 0.268584 Ping 37 0.324154 dpolling-50msvoipftp-pollnodes16-error0.0001 dpolling-100msvoipftp-pollnodes16-error0.0001 dpolling-400msvoipftp-pollnodes16-error0.0001 Ping 37 0.58557 Πίνακας 2: παρουσιάζει το µέσο όρο του RTT των Ping πακέτων για κάθε πρωτόκολλο Σύγκριση του 802.11 µε το DPolling µε slot period = 50 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του RTT των Ping πακέτων από το 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από το παραπάνω φαίνεται η προτεραιότητα που δίνουµε στα πακέτα της other_queue η οποία είναι ίδια µε την προτεραιότητα της voip_queue. Σύγκριση του 802.11 µε το DPolling µε slot period = 100 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του RTT των Ping πακέτων από το 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από το 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από το παραπάνω φαίνεται η προτεραιότητα που δίνουµε στα πακέτα της other_queue η οποία είναι ίδια µε την προτεραιότητα της voip_queue. Σύγκριση του 802.11 µε το DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του RTT των Ping πακέτων από το 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από το 802.11 χωρίς RTS/CTS πακέτα µε την 111

ύπαρξη κρυµµένου κόµβου και από το 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από το παραπάνω φαίνεται η προτεραιότητα που δίνουµε στα πακέτα της other_queue η οποία είναι ίδια µε την προτεραιότητα της voip_queue. Γραφική παράσταση 1: παρουσιάζει το RTT των Ping πακέτων για κάθε πρωτόκολλο συναρτήσει του χρόνου. 112

Test Class #Samples Average 802.11-voipftp- norts-nohn-nodes16- error0.0001 VoIP 111 2.81279 802.11-voipftp- norts-nodes16- error0.0001 VoIP 50 1.52988 VoIP 37 1.58613 VoIP 76 4.0868 VoIP 74 3.78606 802.11-voipftp-rtsnodes16-error0.0001 dpolling-50msvoipftp-pollnodes16-error0.0001 dpolling-100msvoipftp-pollnodes16-error0.0001 dpolling-400msvoipftp-pollnodes16-error0.0001 VoIP 74 2.72147 Πίνακας 3: παρουσιάζει το µέσο όρο του MOS της VoIP κλήσης για κάθε πρωτόκολλο Σύγκριση του 802.11 µε το DPolling µε slot period = 50 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερο µέσο όρο του MOS της VoIP κλήσης από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από τον αντίστοιχο του 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου 113

κόµβου. Από το παραπάνω φαίνεται ότι έχουµε καλύτερη ποιότητα VoIP κλήσης. Σύγκριση του 802.11 µε το DPolling µε slot period = 100 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερο µέσο όρο του MOS της VoIP κλήσης από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από τον αντίστοιχο του 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από το παραπάνω φαίνεται ότι έχουµε καλύτερη ποιότητα VoIP κλήσης. Σύγκριση του 802.11 µε το DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι το πρωτόκολλό µας παρουσιάζει µεγαλύτερο µέσο όρο του MOS της VoIP κλήσης από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από τον αντίστοιχο του 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από το παραπάνω φαίνεται ότι έχουµε καλύτερη ποιότητα VoIP κλήσης. Σύγκριση του DPolling µε slot period = 50 ms, του DPolling µε slot period = 100 ms και DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι όσο µεγαλώνει το slot period τόσο µικραίνει ο µέσος όρος του MOS της VoIP κλήσης. Αυτό συµβαίνει επειδή όταν µεγαλώνει το slot period τότε αυξάνεται και ο αριθµός των ftp bytes που περνάνε ανά γύρα µε αποτέλεσµα να να καθυστερεί και να µειώνεται η VoIP κίνηση. Test Class #Samples Average 802.11-voipftp- norts-nohn-nodes16- error0.0001 VoIP 111 0.503861 802.11-voipftp- norts-nodes16- error0.0001 VoIP 50 0.856714 114

VoIP 37 1.29903 VoIP 76 0.220899 802.11-voipftp-rtsnodes16-error0.0001 dpolling-50msvoipftp-pollnodes16-error0.0001 dpolling-100msvoipftp-pollnodes16-error0.0001 dpolling-400msvoipftp-pollnodes16-error0.0001 VoIP 74 0.275526 VoIP 74 0.441021 Πίνακας 4: παρουσιάζει το µέσο όρο του VoIP DeLay των VoIP πακέτων για κάθε πρωτόκολλο Σύγκριση του 802.11 µε το DPolling µε slot period = 50 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του VoIPDelay των VoIP πακέτων από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από τον αντίστοιχο του 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από τα παραπάνω φαίνεται ότι τα πακέτα VoIP στο πρωτόκολλό µας µένουν λιγότερη ώρα στην ουρά (γρήγορη εξυπηρέτηση). Σύγκριση του 802.11 µε το DPolling µε slot period = 100 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του VoIPDelay των VoIP πακέτων από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από τον αντίστοιχο του 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από τα παραπάνω φαίνεται ότι τα πακέτα VoIP στο πρωτόκολλό µας µένουν λιγότερη ώρα στην ουρά (γρήγορη εξυπηρέτηση). 115

Σύγκριση του 802.11 µε το DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του VoIPDelay των VoIP πακέτων από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα χωρίς την ύπαρξη κρυµµένου κόµβου, από τον αντίστοιχο του 802.11 χωρίς RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου και από τον αντίστοιχο του 802.11 µε RTS/CTS πακέτα µε την ύπαρξη κρυµµένου κόµβου. Από τα παραπάνω φαίνεται ότι τα πακέτα VoIP στο πρωτόκολλό µας µένουν λιγότερη ώρα στην ουρά (γρήγορη εξυπηρέτηση). Σύγκριση του DPolling µε slot period = 50 ms, του DPolling µε slot period = 100 ms και DPolling µε slot period = 400 ms Εδώ παρατηρούµε ότι όσο µεγαλώνει το slot period τόσο µεγαλώνει ο µέσος όρος του VoIPDelay των VoIP πακέτων. Αυτό συµβαίνει επειδή όταν µεγαλώνει το slot period τότε αυξάνεται και ο αριθµός των ftp bytes που περνάνε ανά γύρα µε αποτέλεσµα να καθυστερεί η VoIP κίνηση. Γραφική παράσταση 2: παρουσιάζει το VoIP Delay των VoIP πακέτων για κάθε πρωτόκολλο συναρτήσει του χρόνου. 116

5.2 Σύγκριση HCCA-DPolling 5.2.1 Παραδείγµα UDP κίνησης Στο παράδειγµα αυτό τρέξαµε τον NS για 10 sec µε αριθµό κόµβων 8 χωρίς την παρουσία θορύβου και µε το bandwidth να είναι 11Mb. Επίσης συµµετείχαν 4 τεστ όπου το 1 ο τεστ περιλαµβάνει το 802.11.e πρωτόκολλο χωρίς την ύπαρξη κρυµµένου κόµβου, το 2 ο τεστ περιλαµβάνει το δικό µας πρωτόκολλο (DPOLLING) µε την ύπαρξη κρυµµένου κόµβου και µε slot period=40 ms, το 3 ο τεστ περιλαµβάνει το δικό µας πρωτόκολλο (DPOLLING) µε την ύπαρξη κρυµµένου κόµβου και µε slot period=100 ms και το 4 ο τεστ περιλαµβάνει το δικό µας πρωτόκολλο (DPOLLING) µε την ύπαρξη κρυµµένου κόµβου και µε slot period=200 ms. Η κίνηση που δηµιουργήσαµε ήταν UDP-cbr (constant bit rate) πακέτα, δηλαδή δηµιουργήθκε συνεχόµενη κίνηση από udp πακέτα. Παρακάτω φαίνονται µερικά αποτελέσµατα Test Class Last Rx Avg_Throughput Ucbr 9.99912 5.33335e+06 Ucbr 9.9975 3.97531e+06 Ucbr 9.99912 5.45264e+06 802.11ehcca_udpcbr-nortsnohn-nodes8-error0 dpolling-40mshcca_udpcbr-pollnodes8-error0 dpolling-100mshcca_udpcbr-pollnodes8-error0 dpolling-200mshcca_udpcbr-pollnodes8-error0 Ucbr 9.99307 6.14017e+06 Πίνακας 1: παρουσιάζει το AVERAGE_THROUGHPUT για κάθε πρωτόκολλο 117

Σύγκριση του 802.11e µε το DPolling µε slot period = 40 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερη απόδοση από το 802.11e και αυτό οφείλεται στο µικρό slot period (o HCCA έχει 80ms). Αφού έχουµε µικρό slot period επιτρέπουµε λίγη κίνηση να περάσει σε κάθε γύρα και έχουµε πολλές γύρες οι οποίες κινούν αρκετά µη ωφέλιµα πακέτα όπως PollRequests, PollGrants, κτλ. Σύγκριση του 802.11e µε το DPolling µε slot period = 100 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει λίγο µεγαλύτερη απόδοση από το 802.11e και αυτό οφείλεται στο λίγο µεγαλύτερο slot period που έχουµε (o HCCA έχει 80ms). Αφού έχουµε µεγαλύτερο slot period επιτρέπουµε περισσότερη κίνηση να περάσει σε κάθε γύρα. Σύγκριση του 802.11e µε το DPolling µε slot period = 200 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει πολύ µεγαλύτερη απόδοση από το 802.11e και αυτό οφείλεται στο µεγαλύτερο slot period που έχουµε (o HCCA έχει 80ms). Αφού έχουµε µεγαλύτερο slot period επιτρέπουµε περισσότερη κίνηση να περάσει σε κάθε γύρα. Σύγκριση του DPolling µε slot period = 40 ms, του DPolling µε slot period = 100 ms και DPolling µε slot period = 200 ms Εδώ παρατηρούµε ότι όσο µεγαλώνει το slot period τόσο µεγαλώνει η απόδοση. Αυτό συµβαίνει επειδή όταν µεγαλώνει το slot period τότε αυξάνεται και ο αριθµός των udp bytes που περνάνε ανά γύρα. Αντιθέτως όταν είναι µικρό το slot period τότε µειώνονται τα udp bytes που περνάνε ανά γύρα και αυξάνονται οι γύρες, πράγµα που σηµαίνει ότι στέλνονται παραπάνω µη οφέλιµα πακέτα όπως PollGrant, PollRequest, κτλ. 118

Γραφική παράσταση 1: παρουσιάζει τα bytes που δέχτηκε κάθε κόµβος 119

Γραφική παράσταση 2: παρουσιάζει τα bytes που έστειλε κάθε κόµβος. Εδώ παρατηρούµε ότι υπάρχει ισοµερής κατανοµή του bandwidth στους κόµβους επειδή και τα 2 πρωτόκολλα κάνουν polling (ενώ στο 802.11 (DCF) υπάρχουν πολλές ανωµαλίες στις καµπύλες πράγµα που σηµαίνει µη ισοµερής κατανοµή του bandwidth). 5.2.2 Παράδειγµα VoIP και FTP κίνησης Στο παράδειγµα αυτό τρέξαµε τον NS για 10 sec µε αριθµό κόµβων 8 χωρίς την παρουσία θορύβου και µε το bandwidth να είναι 11Mb. Επίσης συµµετείχαν 4 τεστ όπου το 1 ο τεστ περιλαµβάνει το 802.11.e πρωτόκολλο χωρίς την ύπαρξη κρυµµένου κόµβου, το 2 ο τεστ περιλαµβάνει το δικό µας πρωτόκολλο (DPOLLING) µε την ύπαρξη κρυµµένου κόµβου και µε slot period=40 ms, το 3 ο τεστ περιλαµβάνει το δικό µας πρωτόκολλο (DPOLLING) µε την ύπαρξη κρυµµένου κόµβου και µε slot period=100 ms και το 4 ο τεστ περιλαµβάνει το δικό µας πρωτόκολλο (DPOLLING) µε την ύπαρξη κρυµµένου κόµβου και µε slot period=200 ms. 120

Παρακάτω φαίνονται µερικά αποτελέσµατα. Test Class Last Rx Avg_Throughput Ftp 9.99874 3.54099e+06 VoIP 9.98734 117550 Ftp 9.99287 3.57766e+06 VoIP 9.994 117242 Ftp 9.98752 4.83682e+06 VoIP 9.99695 116976 802.11ehcca_voipftp-nortsnohn-nodes8-error0 802.11ehcca_voipftp-nortsnohn-nodes8-error0 dpolling-40mshcca_voipftp-pollnodes8-error0 dpolling-40mshcca_voipftp-pollnodes8-error0 dpolling-100mshcca_voipftp-pollnodes8-error0 dpolling-100mshcca_voipftp-pollnodes8-error0 dpolling-200mshcca_voipftp-pollnodes8-error0 Ftp 9.99966 5.3989e+06 121

dpolling-200mshcca_voipftp-pollnodes8-error0 VoIP 9.94825 116674 Πίνακας 1: παρουσιάζει το AVERAGE_THROUGHPUT κάθε κίνησης(voip και FTP) για κάθε πρωτόκολλο Σύγκριση του 802.11e µε το DPolling µε slot period = 40 ms Εδώ παρατηρούµε ότι η απόδοση του πρωτόκολλου µας και για τις 2 κινήσεις βρίσκεται στα ίδια επίπεδα περίπου µε το 802.11e (είµαστε λίγο κάτω στην VoIP κίνηση και λίγο πάνω στην FTP). Σύγκριση του 802.11e µε το DPolling µε slot period = 100 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερη απόδοση για την FTP κίνηση και µικρότερη απόδοση για την VoIP. Έχουµε καλύτερη FTP κίνηση γιατί έχουµε µεγαλύτερο slot period, άρα σε κάθε γύρα αφήνουµε παραπάνω FTP κίνηση να περάσει. Για τον ίδιο λόγο υστερούµε στην VoIP κίνηση. Σύγκριση του 802.11e µε το DPolling µε slot period = 200 ms Εδώ παρατηρούµε ότι το πρωτόκολλό µας παρουσιάζει µεγαλύτερη απόδοση για την FTP κίνηση (πολύ µεγάλη διαφορά) και µικρότερη απόδοση για την VoIP. Έχουµε καλύτερη FTP κίνηση γιατί έχουµε µεγαλύτερο slot period, άρα σε κάθε γύρα αφήνουµε παραπάνω FTP κίνηση να περάσει. Για τον ίδιο λόγο υστερούµε στην VoIP κίνηση. Σύγκριση του DPolling µε slot period = 40 ms, του DPolling µε slot period = 100 ms και DPolling µε slot period = 200 ms Εδώ παρατηρούµε ότι όσο µεγαλώνει το slot period τόσο µεγαλώνει η FTP κίνηση και µικραίνει η VoIP κίνηση. Αυτό συµβαίνει επειδή όταν µεγαλώνει το slot period τότε αυξάνεται και ο αριθµός των ftp bytes που περνάνε ανά γύρα. Αντιθέτως όταν είναι µικρό το slot period τότε µειώνονται τα ftp bytes που περνάνε ανά γύρα και αυξάνονται οι γύρες. 122

Test Class #Samples Average VoIP 56 4.37554 VoIP 55 4.37332 VoIP 55 4.31741 802.11ehcca_voipftp-nortsnohn-nodes8-error0 dpolling-40mshcca_voipftp-pollnodes8-error0 dpolling-100mshcca_voipftp-pollnodes8-error0 dpolling-200mshcca_voipftp-pollnodes8-error0 VoIP 54 4.06001 Πίνακας 2: παρουσιάζει το µέσο όρο του MOS της VoIP κλήσης για κάθε πρωτόκολλο Σύγκριση του 802.11e µε το DPolling µε slot period = 40 ms Εδώ παρατηρούµε ότι ο µέσος όρος του MOS της VoIP κλήσης του πρωτοκόλλου βρίσκεται στα ίδια επίπεδα µε τον αντίστοιχο του 802.11e (για την ακρίβεια υστερούµε πολύ λίγο). Αξίζει να σηµειωθεί οτι το µέγιστο MOS για τον codec είναι 4.4, και θεωρείται ότι ένα MOS > 3.8 είναι αρκετά καλό. Σύγκριση του 802.11e µε το DPolling µε slot period = 100 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του MOS της VoIP κλήσης από τον αντίστοιχο του 802.11e. Αυτό οφείλεται στην αύξηση του slot period στο πρωτόκολλό µας σε σχέση µε την πρώτη περίπτωση. Αξίζει να σηµειωθεί ότι το µέγιστο MOS για τον codec είναι 4.4, και θεωρείται ότι ένα MOS > 3.8 είναι αρκετά καλό. Σύγκριση του 802.11e µε το DPolling µε slot period = 200 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µικρότερο µέσο όρο του MOS της VoIP κλήσης από τον αντίστοιχο του 802.11e. Αυτό οφείλεται στην περαιτέρω αύξηση του slot period στο πρωτόκολλο µας σε σχέση µε την 123

πρώτη περίπτωση. Αξίζει να σηµειωθεί ότι το µέγιστο MOS για τον codec είναι 4.4, και θεωρείται οτι ένα MOS > 3.8 είναι αρκετά καλό. Σύγκριση του DPolling µε slot period = 40 ms, του DPolling µε slot period = 100 ms και DPolling µε slot period = 200 ms Εδώ παρατηρούµε ότι όσο µεγαλώνει το slot period τόσο µικραίνει ο µέσος όρος του MOS της VoIP κλήσης. Αυτό συµβαίνει επειδή όταν µεγαλώνει το slot period τότε αυξάνεται και ο αριθµός των ftp bytes που περνάνε ανά γύρα µε αποτέλεσµα να καθυστερεί και να µειώνεται η VoIP κίνηση. Test Class #Samples Average VoIP 56 0.0677639 VoIP 55 0.0719995 VoIP 55 0.151037 802.11ehcca_voipftp-nortsnohn-nodes8-error0 dpolling-40mshcca_voipftp-pollnodes8-error0 dpolling-100mshcca_voipftp-pollnodes8-error0 dpolling-200mshcca_voipftp-pollnodes8-error0 VoIP 54 0.232072 Πίνακας 3: παρουσιάζει το µέσο όρο του VoIP DeLay των VoIP πακέτων για κάθε πρωτόκολλο 124

Σύγκριση του 802.11e µε το DPolling µε slot period = 40 ms Εδώ παρατηρούµε ότι ο µέσος όρος του VoIPDelay των VoIP πακέτων του πρωτοκόλλου µας βρίσκεται στα ίδια επίπεδα µε τον αντίστοιχο του 802.11e (για την ακρίβεια υστερούµε λίγο). Σύγκριση του 802.11e µε το DPolling µε slot period = 100 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει µεγαλύτερο µέσο όρο του VoIPDelay των VoIP πακέτων από τον αντίστοιχο του 802.11e. Αυτό οφείλεται στην αύξηση του slot period στο πρωτόκολλο µας σε σχέση µε την πρώτη περίπτωση, πράγµα που σηµαίνει ότι επιτρέπουµε περισσότερη FTP κίνηση να περάσει µε συνέπεια να καθυστερούν τα VoIP πακέτα περισσότερο. Σύγκριση του 802.11e µε το DPolling µε slot period = 200 ms Εδώ παρατηρούµε ότι το πρωτόκολλο µας παρουσιάζει ακόµη µεγαλύτερο µέσο όρο του VoIPDelay των VoIP πακέτων από τον αντίστοιχο του 802.11e. Αυτό οφείλεται στην περαιτέρω αύξηση του slot period στο πρωτόκολλο µας σε σχέση µε την πρώτη περίπτωση, πράγµα που σηµαίνει ότι επιτρέπουµε περισσότερη FTP κίνηση να περάσει µε συνέπεια να καθυστερούν τα VoIP πακέτα περισσότερο. Σύγκριση του DPolling µε slot period = 40 ms, του DPolling µε slot period = 100 ms και DPolling µε slot period = 200 ms Εδώ παρατηρούµε ότι όσο µεγαλώνει το slot period τόσο µεγαλώνει ο µέσος όρος του VoIPDelay των VoIP πακέτων. Αυτό συµβαίνει επειδή όταν µεγαλώνει το slot period τότε αυξάνεται και ο αριθµός των ftp bytes που περνάνε ανά γύρα µε αποτέλεσµα να καθυστερεί η VoIP κίνηση. 125

Γραφική παράσταση 1: παρουσιάζει το VoIP Delay των VoIP πακέτων για κάθε πρωτόκολλο συναρτήσει του χρόνου. 6. Συµπεράσµατα Μέτα από τη διεξαγωγή πολλών τεστ καταλήξαµε στα παρακάτω συµπεράσµατα. Τα πλεονεκτήµατα του πρωτοκόλλου µας σε σχέση µε τον DCF του 802.11 είναι ότι σε outdoor δίκτυα µεγάλου φόρτου και πολλών διαφορετικών κινήσεων: 1. καταφέρνουµε να εξυπηρετήσουµε καλύτερα την real-time κίνηση και πετυχαίνουµε πολύ καλύτερη ποιότητα της real-time κίνησης από ότι το 802.11 2. καταφέρνουµε να έχουµε µικρότερη καθυστέρηση της real-time κίνησης. 3. µπορούµε να εγγυηθούµε σε όλους τους κόµβους ένα σταθερό bandwidth. 4. πετυχαίνουµε µεγαλύτερο throughput, δηλαδή το δίκτυο µας έχει µεγαλύτερη κυκλοφορία. 126