Ph.D. Dissertation

Gda´nsk University of Technology Faculty of Electronics, Telecommunications and Informatics

Department: Computer Communications Author: Tomasz Mrugalski Studies type: Ph.D. Studies

Ph.D. Dissertation

Dissertation topic: Optimization of the autoconﬁguration mechanisms of the mobile stations supporting IPv6 protocol in the IEEE 802.16 environment

Polish title: Optymalizacja mechanizm´ow automatycznej

konﬁguracji stacji ruchomych wspierajacych, protok´o lIPv6 w ´srodowisku sieci IEEE 802.16

Supervisor: prof. dr hab. in˙z. J´ozef Wo´zniak

Gda´nsk, 2009-10-19 ii Contents

List of Figures ix

List of Tables xiii

Polish Extended Abstract xvii I. Wprowadzenie...... xvii

I.1. Prze laczenie, w warstwie IEEE 802.16...... xvii I.2. Rekonﬁguracja IPv6...... xviii I.3. Metryka HD...... xx I.4. Teza pracy...... xx

II. Przeglad, literatury...... xxi II.1. WiMAX Forum...... xxi II.2. Grupy robocze IETF...... xxi II.3. Uznane standardy...... xxi II.4. Niezale˙zne propozycje...... xxiii III. Propozycje usprawnie´n...... xxiii

III.1. U˙zycie istniejacych, optymalizacji...... xxiii III.2. Propozycje autorskie...... xxiv

III.3. Ominiecie, oczekiwania wstepnego, w DHCPv6...... xxiv III.4. Ominiecie, wykrywania zduplikowanych adresóww IPv6...... xxiv III.5. Wykrywanie zduplikowanych adresówpo stronie serwera...... xxv III.6. Zdalna autokonfiguracja poprzez DHCPv6...... xxv III.7. Konfiguracja routingu poprzez DHCPv6...... xxv

III.8. Zdalne uaktualnienie powiazańw, Mobile IPv6...... xxv IV. Analiza wydajno´sci...... xxvi IV.1. Model symulacyjny...... xxvi IV.2. Generatory liczb pseudolosowych...... xxvi IV.3. Metodologia obróbki wynikóweksperymentów...... xxvi IV.4. Dane empiryczne...... xxvii IV.5. Symulowane scenariusze...... xxvii IV.6. Eksperymenty symulacyjne...... xxviii IV.7. Przeprowadzone badania...... xxix IV.8. Transmisja i modele ruchu...... xxix

IV.9. Czas przygotowania do prze laczenia, ...... xxx IV.10. Czas ponownego wej´scia do sieci...... xxx iv CONTENTS

IV.11. Czas rekonﬁguracji stosu IPv6...... xxx IV.12. Czas konﬁguracji DHCPv6...... xxx IV.13. Przerwa w zdolno´sciach komunikacyjnych...... xxxi V. Wnioski i rezultaty...... xxxi V.1. Dibbler – implementacja DHCPv6...... xxxii V.2. Numbat – ´srodowisko symulacyjne...... xxxiii

1. Introduction 1 1.1. WiMAX Overview...... 1 1.1.1. MAC messages and CS sublayer...... 3 1.1.2. Initial Network Entry...... 3 1.1.3. Handover Process...... 4 1.1.4. Neighbor Advertisements...... 4 1.1.5. Scanning...... 5 1.1.6. 802.16 Handover...... 6 1.1.7. Network reentry...... 6 1.2. IPv6 Overview...... 7 1.2.1. IPv6 addressing...... 8 1.2.2. IPv6 reconﬁguration...... 9 1.2.3. IPv6 interface reinitialization...... 9 1.2.4. Automatic conﬁguration in IPv6...... 9 1.2.5. Router Discovery...... 10 1.2.6. DHCPv6...... 10 1.2.7. Duplicate Address Detection...... 11 1.2.8. Mobile IPv6 Overview...... 12 1.3. Mobile WiMAX/IPv6 convegence...... 12 1.3.1. Multi-layer handover procedure...... 13 1.4. Thesis...... 13 1.4.1. Research goals...... 13 1.4.2. Handover Delay metric...... 14 1.5. Terminology notice...... 15

2. Related work 17 2.1. WiMAX Forum...... 17 2.2. IETF working groups...... 18 2.3. Mobile IPv6...... 18 2.4. Fast Handovers for Mobile IPv6...... 19 2.5. Hierarchical MIPv6...... 20 2.6. Route Optimization in Mobile IPv6 using Static Shared Key...... 21 CONTENTS v

2.7. Enhanced Route Optimization for MIPv6...... 21 2.8. Mobility support in DHCPv6...... 22 2.9. Optimistic DAD...... 23 2.10. IEEE 802.21...... 24 2.11. IEEE 802.16e (Mobile WiMAX)...... 25 2.12. 802.16 extensions...... 25 2.13. Independent proposals...... 25 2.13.1. An Improved FHMIPv6 Handover for Mobile WiMAX...... 25 2.13.2. New Handover Mechanism for 802.16e Networks...... 26 2.13.3. Roaming Over WLAN and WiMAX...... 26 2.13.4. Seamless Realtime Traﬃc Handover Policy for IEEE 802.16m...... 27 2.13.5. Human Mobility Patterns...... 27 2.13.6. Mobile networks on Vehicles across Heterogeneous Networks...... 27 2.13.7. Fast RSVP reservation for Mobile IPv6...... 28 2.14. Summary...... 28

3. Proposed improvements 31 3.1. Existing features usage...... 31 3.1.1. WiMAX Optimizations...... 31 3.1.2. DHCPv6: Preference 255...... 34 3.1.3. DHCPv6: Rapid-commit...... 35 3.2. New improvement proposals...... 36 3.2.1. Skip initial delay in DHCPv6...... 36 3.2.2. Skip Duplicate Address Detection in IPv6...... 37 3.2.3. DHCPv6: Server side Duplicate Address Detection...... 38 3.2.4. Remote Autoconﬁguration via DHCPv6...... 40 3.2.5. Routing conﬁgured via DHCPv6...... 43 3.2.6. Mobile IPv6: Remote Binding Update...... 44

4. Efficiency analysis 49 4.1. Simulation model...... 50 4.1.1. Simulation length time...... 50 4.1.2. Numbat overview...... 51 4.1.3. 802.16 PHY profile...... 52 4.1.4. Mobility model...... 54 4.1.5. Traffic models...... 55 4.1.6. Limitations...... 56 4.2. Random numbers generators...... 57 4.2.1. Mersenne Twister...... 58 vi CONTENTS

4.2.2. PRNG Sequence length...... 59 4.2.3. Assured simulations independence...... 60 4.3. Experiment results methodology...... 60 4.3.1. Selecting sample sizes...... 60 4.3.2. Warm-up period...... 61 4.3.3. Trend estimation...... 63 4.4. Empirical data...... 66 4.4.1. DHCPv6 measurements: the Dibbler project...... 66 4.4.2. Mobile 802.16 Base Station hardware...... 67 4.5. Simulated scenarios...... 67 4.5.1. Scenario 1: No optimization...... 68 4.5.2. Scenario 2: 802.16e optimization...... 69 4.5.3. Scenario 3: DHCPv6: Skip initial delay...... 69 4.5.4. Scenario 4: DHCPv6: Preference 255...... 69 4.5.5. Scenario 5: DHCPv6: Rapid-commit...... 69 4.5.6. Scenario 6: IPv6: Skip DAD...... 69 4.5.7. Scenario 7: DHCPv6: Server side DAD...... 70 4.5.8. Scenario 8: DHCPv6: Remote configuration...... 70 4.5.9. Scenario 9: DHCPv6: Address parameters...... 70 4.5.10. Scenario 10: Mobile IPv6: Remote Binding Update...... 70 4.6. Experiments...... 70 4.6.1. Experiment 1: Downlink measurements...... 71 4.6.2. Experiment 2: Uplink measurements...... 72 4.6.3. Experiment 3: IPv6 and DHCPv6 configuration...... 72 4.6.4. Experiment 4: Handover Preparation and Delay...... 73 4.7. Traffic impact assessment...... 73 4.7.1. Downlink traffic...... 73 4.7.2. Uplink traffic...... 76 4.7.3. Traffic comparison...... 78 4.7.4. Packet size distribution...... 81 4.8. Handover oriented results...... 81 4.8.1. Handover preparation...... 82 4.8.2. Network Reentry Time...... 86 4.8.3. IPv6 Reconfiguration time...... 88 4.8.4. DHCP Configuration Time...... 91 4.8.5. Lack of communication capabilities...... 92 4.9. Efficiency comparison...... 97 4.10. Future research directions...... 99 CONTENTS vii

5. Conclusions 101 5.1. Practical aspects...... 102 5.1.1. Dibbler...... 103 5.1.2. Numbat...... 104 5.2. Future work...... 104

Bibliography 107

A. Simulation results 115 A.1. Experiment 1 results...... 115 A.1.1. Downlink traffic results...... 115 A.2. Experiment 2 execution...... 119 A.2.1. Uplink traffic results...... 119 A.3. Experiment 3 execution...... 124 A.3.1. 802.16 Network Reentry...... 124 A.3.2. IPv6 reconfiguration time...... 129 A.3.3. DHCP configuration time...... 134 A.4. Experiment 4 execution...... 138 A.4.1. Handover preparation...... 138 A.4.2. Lack of communication capabilities...... 143

B. Developed software 149 B.1. Numbat – simulation environment...... 149 B.1.1. Project impact...... 151 B.2. Dibbler – DHCPv6 implementation...... 152 B.2.1. Design assumptions...... 152 B.2.2. Supported features...... 153 B.2.3. Experimental features...... 156 B.2.4. Supported platforms...... 157 B.2.5. Project impact...... 158

C. List of Publications 159

Index 161 viii CONTENTS List of Figures

1. Example 802.16/IPv6 network...... 2

2. 802.16e network (re)entry...... 32 3. Server side Duplicate Address Detection...... 39 4. Remote autoconﬁguration...... 41 5. Routing conﬁguration via DHCPv6...... 43 6. Remote Binding Update...... 45

7. OFDMA frame structure...... 51 8. Mapping OFDMA slots to subchannels/symbols in downlink...... 53 9. Mapping OFDMA slots to subchannels/symbols in uplink...... 54 10. Beta distribution...... 56 11. Mersenne Twister distribution...... 59 12. Downlink warm-up period analysis...... 63 13. Uplink warm-up period analysis...... 64 14. Initial network conditions...... 68 15. Network conditions after first handover...... 72 16. Downlink traffic for scenario 3 (preference-255)...... 75 17. Downlink traffic for scenario 10 (remote-binding-update)...... 76 18. Comparison of downlink traffic...... 77 19. Downlink traffic efficiency...... 79 20. Uplink traffic efficiency...... 79 21. Uplink traffic for scenario 5 (rapid-commit)...... 80 22. Uplink traffic for scenario 7 (server-dad)...... 80 23. Truncated normal traffic histogram...... 81 24. Beta traffic histogram...... 82 25. Handover preparation time for scenario 5 (rapid-commit)...... 83 26. Handover preparation time for scenario 8 (remote-autoconf)...... 83 27. Standard deviation of handover preparation time...... 85 28. Handover preparation time for all scenarios...... 86 29. Network reentry time...... 87 30. IPv6 reconfiguration warm-up time...... 89 31. IPv6 reconfiguration time...... 90 32. Example comparison of select IPv6 reconfigurations...... 90 33. DHCPv6 configuration time for scenario 9 (address-params)...... 92 x LIST OF FIGURES

34. DHCPv6 configuration time comparison...... 93 35. Standard deviation of DHCPv6 configuration time...... 93 36. Lack of communication capability...... 94 37. Lack of communication capabilities warm-up time...... 94 38. Comparison of measured lack of communication periods...... 96 39. Comparison of lack of communication for selected scenarios...... 96 40. Received traffic per second (scenarios 1 and 10)...... 99

41. World map of conﬁrmed Dibbler users...... 103

42. Downlink traffic, scenario 1 (basic)...... 115 43. Downlink traffic, scenario 2 (wimax-optim)...... 116 44. Downlink traffic, scenario 4 (skip-initial-delay)...... 116 45. Downlink traffic, scenario 5 (rapid-commit)...... 117 46. Downlink traffic, scenario 6 (skip-dad)...... 117 47. Downlink traffic, scenario 7 (server-dad)...... 118 48. Downlink traffic, scenario 8 (remote-autoconf )...... 118 49. Downlink traffic, scenario 9 (address-params)...... 119 50. Uplink traffic, scenario 1 (basic)...... 120 51. Uplink traffic, scenario 2 (wimax-optim)...... 120 52. Uplink traffic, scenario 3 (preference-255 )...... 121 53. Uplink traffic, scenario 4 (skip-initial-delay)...... 121 54. Uplink traffic, scenario 6 (skip-dad)...... 122 55. Uplink traffic, scenario 8 (remote-autoconf )...... 122 56. Uplink traffic, scenario 9 (address-params)...... 123 57. Uplink traffic, scenario 10 (remote-binding-update)...... 123 58. Network Reentry, scenario 1 (basic)...... 124 59. Network Reentry, scenario 2 (wimax-optim)...... 124 60. Network Reentry, scenario 3 (preference-255 )...... 125 61. Network Reentry, scenario 4 (skip-initial-delay)...... 125 62. Network Reentry, scenario 5 (rapid-commit)...... 126 63. Network Reentry, scenario 6 (skip-dad)...... 126 64. Network Reentry, scenario 7 (server-dad)...... 127 65. Network Reentry, scenario 8 (remote-autoconf )...... 127 66. Network Reentry, scenario 9 (address-params)...... 128 67. Network Reentry, scenario 10 (remote-binding-update)...... 128 68. IPv6 reconfiguration, scenario 1 (basic)...... 129 69. IPv6 reconfiguration, scenario 2 (wimax-optim)...... 129 70. IPv6 reconfiguration, scenario 3 (preference-255 )...... 130 LIST OF FIGURES xi

71. IPv6 reconfiguration, scenario 4 (skip-initial-delay)...... 130 72. IPv6 reconfiguration, scenario 5 (rapid-commit)...... 131 73. IPv6 reconfiguration, scenario 6 (skip-dad)...... 131 74. IPv6 reconfiguration, scenario 7 (server-dad)...... 132 75. IPv6 reconfiguration, scenario 8 (remote-autoconf )...... 132 76. IPv6 reconfiguration, scenario 9 (address-params)...... 133 77. IPv6 reconfiguration, scenario 10 (remote-binding-update)...... 133 78. DHCPv6 configuration, scenario 1 (basic)...... 134 79. DHCPv6 configuration, scenario 2 (wimax-optim)...... 134 80. DHCPv6 configuration, scenario 3 (preference-255 )...... 135 81. DHCPv6 configuration, scenario 4 (skip-initial-delay)...... 135 82. DHCPv6 configuration, scenario 5 (rapid-commit)...... 136 83. DHCPv6 configuration, scenario 6 (skip-dad)...... 136 84. DHCPv6 configuration, scenario 7 (server-dad)...... 137 85. DHCPv6 configuration, scenario 8 (remote-autoconf )...... 137 86. DHCPv6 configuration, scenario 10 (remote-binding-update)...... 138 87. Handover preparation, scenario 1 (basic)...... 139 88. Handover preparation, scenario 2 (wimax-optim)...... 139 89. Handover preparation, scenario 3 (preference-255 )...... 140 90. Handover preparation, scenario 4 (skip-initial-delay)...... 140 91. Handover preparation, scenario 6 (skip-dad)...... 141 92. Handover preparation, scenario 7 (server-dad)...... 141 93. Handover preparation, scenario 9 (address-params)...... 142 94. Handover preparation, scenario 10 (remote-binding-update)...... 142 95. Lack of communication capabilities, scenario 1 (basic)...... 143 96. Lack of communication capabilities, scenario 2 (wimax-optim)...... 143 97. Lack of communication capabilities, scenario 3 (preference-255 )...... 144 98. Lack of communication capabilities, scenario 4 (skip-initial-delay)...... 144 99. Lack of communication capabilities, scenario 5 (rapid-commit)...... 145 100. Lack of communication capabilities, scenario 6 (skip-dad)...... 145 101. Lack of communication capabilities, scenario 7 (server-dad)...... 146 102. Lack of communication capabilities, scenario 8 (remote-autoconf )...... 146 103. Lack of communication capabilities, scenario 9 (address-params)...... 147 104. Lack of communication capabilities, scenario 10 (remote-binding-update)...... 147

105. Numbat environment example...... 149 106. Dibbler example: multiple clients...... 153 107. Dibbler example: server redundancy...... 154 108. Dibbler example: DNS Update...... 157 xii LIST OF FIGURES

109. Dibbler example: preﬁx delegation...... 158 List of Tables

1. 802.16 OFDMA PHY parameters...... 52 2. Scenario/feature matrix...... 68 3. Experiments summary...... 71 4. Downlink traffic results...... 74 5. Uplink traffic results...... 78 6. Handover preparation measurements...... 84 7. Network reentry measurements...... 87 8. IPv6 reconfiguration measurements...... 88 9. DHCPv6 configuration measurements...... 91 10. Measurements of lack of communication capability...... 95 11. Absolute values of handover parameters...... 97 12. Handover results (compared to basic scenario)...... 98 13. Handover results (compared to best standard case)...... 98 xiv LIST OF TABLES Acknowledgement

I would like to thank my dear Anna Szulc for her patience. I apol- ogize for all those evenings that I’ve spent in front of a monitor instead of together with you. I also have to thank professor J´ozef Wo´zniak for his invaluable insights, countless reviews and guide- lines that made this dissertation possible. I would also like to acknowledge support provided by professor Andrzej Pach as part of the PBZ-MNiSW-02-II/2007 research grant.

Tomasz Mrugalski xvi Acknowledgement Rozszerzone streszczenie

I. Wprowadzenie

Wraz ze zwiekszaj, ac, a, sie, popularno´scia, rozwiazańwykorzystuj, acych, cyfrowe przetwarzanie informacji, obserwowana jest rosnaca, atrakcyjno´sćró˙znego rodzaju technologii zwiazanych, z przetwarzaniem danych. Ilo´sćwytwarzanych, przechowywanych i wykorzystywanych informacji gwa ltownie sie, zwieksza,, powodujac, wzrost zainteresowania zarównou˙zytkownikówkońcowych, jak i operatorówsieciowych nowymi rozwia-, zaniami. Inne obserwowane zjawisko to rosnaca, dostepna, moc obliczeniowa w najnowszych urzadzeniach, przeno´snych typu PDA, smartphone czy netbook. Podobnie do innych urzadzeńelektronicznych,, tak˙ze urzadzenia, przeno´sne podlegaja, prawu Moore’a. Stwierdza ono, ˙zemoc dostepnych, urzadzeńpodwaja, sie, co 18 miesiecy., Jako bezpo´sredni rezultat obu trendówobserwowany jest ciag, ly wzrost zapotrzebowania na transmisje, i odbiórdanych cyfrowych. To z kolei stymuluje producentówsprzetu, i operatorówdo posze- rzania swojej oferty w zakresie rozwiazańmultimedialnych., Obie tendencje sa, jednak przyczyna, pewnego problemu. Z punktu widzenia sieci spe lnienie obu wymogówrównocze´snie – dostarczanie znacznych ilo´sci danych przy zapewnieniu mobilno´sci– jest trudne. Przyczyna, jest skomplikowany proces zmiany punktu pod laczenia, do sieci.

I.1. Prze laczenie, w warstwie IEEE 802.16

WiMAX jest komercyjna, nazwa, u˙zywana, do oznaczania rozwiazańbazuj, acych, na rodzinie standardów IEEE 802.16 [34]. Opracowana w roku 2004 specyfikacja jest okre´slana czesto, jako bezprzewodowy na- stepca, modemówDSL. Przewiduje ona zasieg, do 50 km oraz przepustowo´sćdo 70Mbps (a nawet 1Gbps dla stacjonarnych u˙zytkowników,przy zastosowaniu stacjonarnych stacji abonenckich zgodnych z rozsze- rzeniem 802.16m [43]). W ´srodowiskach miejskich du˙ze znaczenie ma dobra obs luga przypadkówbraku bezpo´sredniej widoczno´sci stacji bazowej (NLOS, ang. non line of sight). Opracowany standard posiada l jednak istotna, wade, – brak wsparcia mobilno´sci. Niedogodno´sćta, usunieto, w opublikowanym w roku 1 2006 rozszerzeniu 802.16e-2005 [36]. Pierwsze dostepne, komercyjnie rozwiazania, zacze, ly pojawiaćsie, na wieksz, a, skale, dopiero w roku 2009 (np. Nokia n810 WiMAX Edition [83]). W czasie mobilnej pracy urzadzenie, przeno´sne mo˙zestwierdzić, ˙ze oferowana jako´sćsygna lu nie jest zadowalajaca, i dostepne, sa, stacje bazowe, któreoferuja, lepsze parametry. Prowadzi to do decyzji o dokonaniu prze laczenia., Proces ten zosta lzdefiniowany jako szereg oddzielnych procedur:

• Og loszenia sasiadów, (Neighbor Advertisements) – Pierwszym krokiem w procesie prze laczania, jest mechanizm rozg laszania sasiadów.Zgodnie, z nim stacje bazowe 802.16 maja, mo˙zliwo´sćrozg laszania listy dostepnych, w sasiedztwie, innych stacji bazowych. Lista ta stanowi wskazówke, dla stacji ruchomej w zakresie potencjalnych celów,do których mo˙zliwe bedzie, prze laczenie., Ze wzgledu, na to, ˙ze

1Wbrew swojemu oznaczeniu, standard ten zosta lopublikowany w lutym 2006. xviii Polish Extended Abstract

w trakcie wysy lania wiadomo´sci NBR-ADV stacje ruchome zachowuja, pe lna, zdolno´sćtransmisyjna,, metryka HD2 ma warto´sć0, a zatem metoda nie wymaga ˙zadnych usprawnień.

• Skanowanie (Scanning) – Stacja ruchoma 802.16, po uzyskaniu listy potencjalnych sasiadówroz-, poczyna proces skanowania. Polega on na tymczasowym od laczeniu, od obecnej stacji bazowej, przeszukiwaniu dostepnych, kana lóww celu nas luchu stacji sasiednich, i oceny jako´sci sygna lu tych˙ze stacji. Dzieki, temu, ˙ze stacje ruchome maja, pe lna, dowolno´sćw definiowaniu czesto´sci, i d lugo´sci okresówskanowania, wp lyw tego mechanizmu na ca lo´sciowy opó´znienie procesu prze laczania jest

niewielki lub wrecz, ˙zaden. Przyk ladowo stacja ruchoma mo˙ze tak dobraćokresy skanowania, ˙zeby trafia ly pomiedzy, dwiem transmisjami pakietówdanych (np. pomiedzy, pakiety VoIP, przesy lane regularnie co kilkadziesiat, ms).

• Prze laczenie, (Handover) – Ostatnia, czynno´scia, przed rzeczywistym prze laczeniem, jest uzgodnienie z obecna, stacja, bazowa, celu prze laczenia,, a nastepnie, poinformowanie o od laczeniu., W trakcie ca lej procedury stacja ruchoma zachowuje zdolno´sci transmisyjne, wiec, nie ma konieczno´scioptymalizacji. Z punktu widzenia przysz lych optymalizacji kluczowa, role, bedzie, spe lnia lfakt, ˙ze to stacja ruchoma decyduje o rzeczywistym momencie od laczenia., Dzieki, temu mo˙ze nieco opó´znićten moment w celu dokonania dodatkowych krokówprzygotowawczych. Po zakończeniu tego kroku nastepuje, rzeczy- wiste od laczenie,, czyli rozpoczecie, dostrajania interfejsu radiowego do parametrówstacji docelowej. Stacja ruchoma traci mo˙zliwo´sćodbioru transmisji nadawanych przez dotychczasowa, stacje, bazowa.,

• Ponowne wej´scie do sieci (Network Reentry) – Standard 802.16 opisuje niezwykle skomplikowana, procedure, wej´scia do sieci jednocze´snie zaznaczajac,, ˙ze niektóre kroki moga, zostaćpominiete,, je˙zeli spe lnione bed, a, okre´slone warunki. Takimi warunkami jest zazwyczaj ponowne wej´scie do sieci oraz pewne dodatkowe informacje posiadane przez docelowa, stacje, bazowa, o przy laczaj, acej, sie, w la´snie stacji ruchomej. Spe lnienie poszczególnych warunkówle˙zyw gestii administratora sieci lub dostawcy

konkretnej implementacji. Wydaje sie, oczywiste, ˙zeproducenci dostarcza, rozwiazania, pozwalajace, na wykonanie ponownego wej´scia do sieci w sposóbzoptymalizowany. Oszacowano, ˙zeczas niezbedny, na ponowne wej´scie do sieci wyniesie ok. 100ms. Chocia˙zz punktu widzenia transmisji audio i/lub video jest to istotny okres, niestety nie ma przes lanek do próbdalszego znacznego skrócenia tej procedury.

Wa˙zna, obserwacja, jest fakt, ˙ze wszystkie procedury wykonywane w ramach protoko lu 802.16 zosta ly opracowane z my´sla, o stacjach ruchomych, sa, wiec, dobrze przystosowane do warunk´owmobilnych i nie wymagaja, istotnych zabieg´oww celu ich dalszej poprawy.

I.2. Rekonﬁguracja IPv6

Po zakończeniu prze laczenia, na poziomie warstwy 802.16, zazwyczaj konieczna jest rekonfiguracja warstw wy˙zszych. Chocia˙z w niektórych przypadkach mo˙zliwe jest jej unikniecie,, scenariusz obejmu- jacy, pe lna, rekonfiguracje, uwa˙zany jest najgorszy mo˙zliwy przypadek. Dlatego te˙zna nim skupiaja, sie, 2 Metryka Handover Delay (HD) zostanie omówiona w dalszej cze´scistreszczenia., Polish Extended Abstract xix

wszystkie analizy przedstawione w niniejszej rozprawie. Ze wzgledu, na zbli˙zajac, a, sie, masowa, migracje, do IPv6, zdecydowano sie, na analize, tej w la´snie wersji protoko lu. Analiza wykazuje, ˙ze wydajno´sćprawie wszystkich mechanizmówu˙zywanych w IPv6 jest nieakceptowalna z punktu widzenia mobilno´scii wymaga usprawnień.

• Og loszenia routera (Router Advertisements) – Chocia˙zstacja ruchoma uzyska la pewne informa-

cje konﬁguracyjne od poprzedniej stacji bazowej, nie dotycza, one niestety warstwy IP. Mechanizm konﬁguracji routingu bazuje na cyklicznie rozg laszanych przez router tzw. og loszeniach routera.

Wiadomo´scite zawieraja, informacje niezbedne, do konfiguracji tras (wpisóww tablicy routingu) przez wszystkie wez, ly, czyli w szczególno´sci stacje, końcowa., Stacja ruchoma po przemieszczeniu sie, do nowej lokalizacji (stacji bazowej) do wyboru: czekaćna nap lywajace, og loszenie routera (mo˙zliwe du˙zeopó´znienie) lub wymuszenie jego transmisji (opó´znienie spowodowane pro´sba, o pasmo i transmisja, dodatkowego pakietu). W zale˙zno´sci od przypadku (optymistyczny/przecietny/pesymistyczny), opó´znienie wprowadzone przez te, faze, konfiguracji wynosi 20 ms lub wiecej., W zwiazku, z tym, ˙ze istnieja, potencjalnie inne metody konfiguracji routingu, ta procedura wskazuje obiecujacy, obszar w zakresie mo˙zliwych propozycji optymalizacyjnych.

• Wstepne, opó´znienie DHCPv6 (Initial delay) – Standard opisujacy, dzia lanie DHCPv6 nakazuje, aby po pod laczeniu, do nowego lacza, (standard nie rozró˙znia inicjalnego pod laczenia, i prze laczenia, ”mobilnego”) odczekaćlosowy okres od 0 do 1 sekundy. Intencja, autorówby lo zmniejszenie obcia˙zenia, sieci w przypadku zaniku i przywrócenia zasilania w du˙zych sieciach. Niestety, nie uwzglednili, oni scenariuszy mobilnych. To losowe opó´znienie jest zupe lnie bezcelowe w przypadku u˙zytkowników ruchomych.

• Konfiguracja stanowa/DHCPv6 (Stateful Autoconfiguration) – W ramach rekonfiguracji wez, la IPv6, konieczne jest uzyskanie (lub potwierdzenie poprawno´sci obecnego) adresu IPv6 oraz dodatkowych parametrówkonfiguracyjnych, jak np. adresy zalecanych serwerówDNS, serwery SIP, kolejno´sć przeszukiwania domen itd. W tym celu wykorzystywana jest tzw. konfiguracja stanowa (stateful autoconfiguration), czyli z u˙zyciem serwera DHCPv6. Pierwszym krokiem takiej konfiguracji jest odkrycie lokalizacji serwerów(w DHCPv6 wiele serwerówmo˙zedzia laćrównocze´snie). Proces ten

polega na transmisji wiadomo´sci Solicit przez stacje, ruchoma, i oczekiwaniu na odpowiedzi wyge- nerowane przez ka˙zdy serwer. Zgodnie ze specyfikacja, DHCPv6 takie oczekiwanie powinno trwać co najmniej sekunde,, a zatem metryka HD przyjmuje warto´sć1000 ms. Widaćtutaj doskonale, ˙ze procedura konfiguracji poprzez DHCPv6 nie by la projektowana z my´sla, o mobilno´sci i szybkiej rekonfiguracji. Powoduje to, ˙zemechanizm DHCPv6 staje sie, jednym z g lównych obszarówposzukiwania usprawnień.

• Wykrywanie zduplikowania adres´ow (Duplicate Address Detection) – Po uzyskaniu adresu

z serwera DHCPv6 (lub jakiegokolwiek innego ´zród la), weze, l IPv6 musi sprawdzić,czy uzyskany adres nie jest ju˙z u˙zywany. S lu˙zy temu procedura wykrywania zduplikowanych adresów. Tutaj

r´ownie˙z mechanizm polega na transmisji pakietu i oczekiwaniu przez sekunde, na odpowied´zod xx Polish Extended Abstract

potencjalnego duplikatu. Ten niezwykle nieefektywny z punktu widzenia mobilno´sci mechanizm jest

dodatkowo os labiany przez fakt, ˙zew poprawnie skonfigurowanej sieci duplikaty nie wystepuj, a,, a ich wystapienie, zdarza sie, jedynie podczas ataku przez podszywanie lub na skutek b lednego, dzia lania którego´sz elementówsieci. Podobnie jak w poprzedniej procedurze, metryka HD przyjmuje warto´sć 1000ms, co powoduje, ˙ze mechanizm ten jest drugim z g lównych obszarówposzukiwania usprawnień.

• Uaktualnienie lokalizacji w Mobile IPv6 (Binding Update) – Ostatecznie po uzyskaniu i po-

twierdzeniu unikalno´sciuzyskanego adresu, stacja ruchoma musi poinformowa´cwez, ly, z kt´orymi utrzymuje komunikacje, (tzw. wez, ly korespondujace), oraz swojego agenta domowego o swoim nowym adresie. S lu˙zy do tego mechanizm uaktualniania lokalizacji w Mobile IPv6. Istnieje kilka

mo˙zliwych scenariuszy takiej wymiany. W przypadku podstawowym niezbedne, jest przeprowadzenie Return Routability Procedure, która jest niestety kosztowna czasowo. Istnieja, jednak metody znacznie szybsze (np. oparte o idee, wspó ldzielonego klucza), którewymagaja, wymiany jedynie 2 wiadomo´sci z ka˙zdym z wez, lówkorespondujacych., Ze wzgledu, na konieczno´sćprzes lania pakietu tam i z powrotem poprzez Internet (tzw. round trip time), procedura ta zajmuje istotnie d lugi okres czasu. Chocia˙z precyzyjne oszacowanie d lugo´sci jest raczej niemo˙zliwe, w pesymistycznym przypadku czas takiej wymiany mo˙zedochodzićdo kilkuset milisekund. Oznacza to, ˙zeomawiana procedura stanowi ´swietny obszar poszukiwania usprawnień.

I.3. Metryka HD

Proces prze laczenia, odbywajacy, sie, w ´srodowisku IPv6/802.16 jest istotnie skomplikowany. W celu u latwienia oceny poszczególnych kroków, zdefiniowano metryke, HD (handover delay), która okre´sla wp lyw danego mechanizmu lub procedury na przerwe, w zdolno´sciach transmisyjnych wez, la IPv6. Metryka wyra˙zona jest w milisekundach i okre´sla, jak d lugo stacja pozbawiona jest mo˙zliwo´sci wysy lania i odbioru danych. W trakcie analizy kolejnych kroków,okre´slono teoretyczne warto´sci HD, którezosta ly nastepnie, zweryfikowane podczas do´swiadczeń. Szczegó lowa definicja zosta la przedstawiona w rozdziale 1.4.2.

I.4. Teza pracy

Niezwykle istotne jest spostrze˙zenie, ˙zenie wszystkie kroki niezbedne, przy prze laczaniu, sa, powodem opó´znień.Z punktu widzenia u˙zytkownika jedynie procedury powodujace, brak zdolno´sci komunikacyjnych sa, problematyczne. Dlatego ca lo´sćbadańprzedstawionych w tej rozprawie skupia sie, na zlokalizowaniu i zminimalizowaniu takich w la´snie okresów.G lówna, teze, niniejszej pracy mo˙zna zdefiniowaćnastepuj, aco:, Proces rekonfiguracji IPv6 w czasie prze laczenia, w sieciach 802.16 nie jest optymalny i mo˙z- liwe jest osiagni, ecie, zwiekszonej, wydajno´sciprze laczania, poprzez modyfikacje, protoko lów IPv6, DHCPv6 oraz Mobile IPv6. W celu udowodnienia tej tezy, sformu lowano szereg celówbadaw- czych. Zdefiniowano tak˙ze metryke,, umo˙zliwiajac, a, porównanie znaczaco, ró˙znych mechanizmów.G lówne cele badawcze to:

• identyfikacja g lównych przyczyn opó´znieńw ´srodowisku 802.16/IPv6, Polish Extended Abstract xxi

• przeglad, wszystkich procedur i wy lonienie kandydat´owdo potencjalnej poprawy,

• propozycja usprawnie´nw ramach wybranych mechanizm´ow,

• weryﬁkacja u˙zyteczno´sci proponowanych optymalizacji.

II. Przeglad, literatury

Drugi rozdzia lrozprawy prezentuje ogólny stan badańprowadzonych w zakresie wsparcia mobilno´sci, toczace, sie, prace oraz wybrane propozycje. Zosta ly przedstawione wybrane grupy IETF, oraz wa˙zniejsze rezultaty ich dzia lań.W dalszej cze´sci, zosta ly omówione prace, tak˙ze zwiazane, z mobilno´scia,, prowadzone pod auspicjami IEEE. Rozdzia lten zamyka przeglad, niezale˙znych publikacji.

II.1. WiMAX Forum

WiMAX Forum jest organizacja, typu non-profit zrzeszajac, a, producentówsprzetu,, integratoróworaz organizacje rzadowe,, zajmujace, sie, regulacja, rynku bezprzewodowego (np. nadawaniem koncesji). Skupia sie, ona na testach interoperacyjno´sci, promowaniu rozwiazańbazuj, acych, na technologii 802.16, a tak˙ze pracuje nad definicja, elementówdodatkowych, o których nie wspomina standard, np. ASN (ang. Access Service Network).

II.2. Grupy robocze IETF

Internet Engineering Task Force jest ogólno´swiatowa, organizacja, o otwartej strukturze, zajmujac, a, sie, definiowaniem i rozwojem protoko lówu˙zywanych w bardzo szeroko pojetym, Internecie. Protokó l IPv6, a tak˙ze mobilno´sćsa, niezwykle wa˙znym zagadnieniem, znajdujacym, sie, w centrum zainteresowania IETFu. W celu analizy zagadnieńzwiazanych, z protoko lem IPv6, jak i ukierunkowaniem prac, powsta lszereg grup roboczych. Najwa˙zniejsze z nich to MIP4, mipshop, dna oraz mext.

II.3. Uznane standardy

W ramach wymienionych grup opracowano kilka protoko l´ow,bed, acych, standardem w zakresie wsparcia mobilno´sci, zw laszcza w obszarze IPv6. Najwa˙zniejsze z nich to:

• Mobile IPv6 – Protokó l definiujacy, zachowanie wez, la ruchomego, wez, lówkorespondujacych, oraz agenta domowego. Przeglad, najwa˙zniejszych operacji wchodzacych, w sk lad protoko lu Mobile IPv6 przedstawiono w końcowej cze´sci, rozdzia lu 1.

• Fast Handovers for Mobile IPv6 – Rozszerzenie Mobile IPv6, skupiajace, sie, na skróceniu czasu prze laczenia., Specyfikacja ta zosta la niedawno (czerwiec 2009) opublikowana jako dokument RFC5568. Skrócenie prze laczania, okupione jest jednak znaczacym, skomplikowaniem niezbednej, in- frastruktury – zdefiniowano nowe typy routerów, które musza, byćrozlokowane w odwiedzanych sieciach. xxii Polish Extended Abstract

• Hierarchical Mobile IPv6 – Autorzy tej propozycji zauwa˙zyli, ˙ze opó´znienia zwiazane, z komunikacja, z agentem domowym oraz wez, lami korespondujacymi, stanowia, znaczna, cze´sć, lacznej, sumy opó´znień.Dlatego te˙zzaproponowali, aby w odwiedzanej domenie umie´scićMobility Anchor Point

(MAP), kt´ory pe lni lby funkcje, namiastki agenta domowego w odwiedzanej sieci. W razie przemieszczenia wewnatrz, domeny, uaktualnianie po lo˙zenia dokonywane jest tylko lokalnie, pomiedzy wez, lem ruchomym oraz MAPem. Eliminacja konieczno´sci komunikacji ze znajdujacymi, sie, w odleg lych sieciach agentem domowym oraz wez, lami korespondujacymi, znacznie skraca czas prze laczania.,

• Route Optimization using Static Shared Key – W podstawowej wersji standardu po ka˙z-

dym przemieszczeniu zak lada sie,, ˙zeweze, l ruchomy korzystajacy, z nowootrzymanego adresu musi uwiarygodnićsie, przed agentem domowym i wez, lami korespondujacymi,, ˙zerzeczywi´scie jest tym wez, lem, za jakiego sie, podaje. S lu˙zydo tego Return Routability Procedure, która niestety jest do´sć czasoch lonna. Dopiero po jej zakończeniu mo˙zliwe jest przeprowadzenie procedury Binding Update. Autorzy tego dokumentu zaproponowali, aby zrezygnowaćz Return Routability Procedure na rzecz

prekonfigurowanych wspó ldzielonych kluczy. To proste, lecz efektywne rozwiazanie, umo˙zliwia skró- cenie czasu prze laczania, w przypadkach, kiedy da sie, je zastosować. G lównym ograniczeniem jest konieczno´sćwstepnej, konfiguracji wspólnego klucza przed nawiazaniem, po laczenia.,

• Enhanced Route Optimization for Mobile IPv6 –Wez, ly korespondujace, u˙zywaja, adresu domowego wez, la ruchomego jako identyfikatora. Adres IP, zarówno w wersji 4, jaki i 6, spe lnia dwie istotne funkcje: identyfikacyjna, (stanowi identyfikator wez, la) oraz lokalizacyjna, (okre´sla jego po lo˙zenie). Autorzy proponuja,, aby klasyczny adres domowy zastapićadresem, generowanym kryp- tograficznie [5]. Dla takiego adresu mo˙zliwe jest potwierdzenie zwiazku, publicznym kluczem wez, la. Weze, lruchomy demonstruje posiadanie swojego adresu domowego poprzez dostarczenie dowodu, ˙ze zna on prywatny klucz zwiazany, z tym˙ze adresem domowym. Dzieki, tej mo˙zliwo´sci, w wiekszo´sci, przypadkówmo˙zliwe jest ca lkowite wyeliminowanie procedury Return Routability Procedure.

• Wsparcie mobilno´sci w DHCPv6 – R´ownie˙z protok´o l DHCPv6 oferuje pewne mechanizmy

umo˙zliwiajace, wsparcie u˙zytkownikówruchomych. Najbardziej oczywistym elementem jest wiadomo´sć Confirm, która, wez, ly ruchome powinny wys laćpo wykryciu zmiany stanu lacza,, czyli np. po asocjacji z nowym wez, lem dostepowym., Standard okre´sla jednak, ˙ze serwery moga, wys laćtaka, odpowied´zjedynie w przypadku, kiedy autorytatywnie moga, stwierdzić,czy wszystkie weryfikowane w la´snie adresy sa, legalne na danym laczu, czy nie. W przeciwnym przypadku standard wyra´znie zabrania serwerom udzielania odpowiedzi na odebrana, wiadomo´sćConfirm. Z punktu widzenia we-, z la ruchomego po wys laniu wiadomo´sci Confirm mo˙zliwy jest brak odpowiedzi, pomimo obecno´sci

sprawnych serwerów. Ta niepewno´sći zwiazane, z nia, opó´znienia stawiaja, pod znakiem zapytania ca la, u˙zyteczno´sćtego mechanizmu.

• Optimistic DAD – Procedura wykrywania zduplikowanych adresów(DAD – Duplicate Address Detection) s lu˙zy do wykrywania potencjalnych konfliktówadresów. Optymistyczny DAD bazuje

na za lo˙zeniu, ˙ze wystapienie, konﬂiktu jest niezwykle ma le i przy spe lnieniu okre´slonych warunk´ow Polish Extended Abstract xxiii

mo˙zliwe jest u˙zywanie adresu ju˙zw czasie trwania weryﬁkacji jego unikalno´sci. Nak ladane sa, jednak istotne ograniczenia w stosowaniu optymistycznych adres´ow.

• IEEE 802.21 – Odmiennym standardem jest norma IEEE 802.21, opracowana w ramach organizacji

IEEE. Definiuje ona prze laczenie, niezale˙zne od technologii dostepowej, (ang. Media Independent Handover). Jego g lównym celem jest umo˙zliwienie prze laczania, w ´srodowisku heterogenicznym, jednak mo˙zete˙zzostaćwykorzystane jako sposóbkomunikacji pomiedzy, warstawami kompletnego stosu, np. 802.16 i IPv6.

• IEEE 802.16 – Rodzina protoko lówIEEE 802.16 oprócz podstawowych wersji oferuje równie˙zszereg rozszerzeń.Najwa˙zniejsze z nich to 802.16e (wsparcie mobilno´sci), 802.16f (definicja MIB), 802.16k

(mostkowanie pomiedzy, stacjami bazowymi), 802.16m (zaawansowany transfer danych, dochodzacy, do 1Gbps dla u˙zytkownik´owstacjonarnych i 100Mbps dla u˙zytkownik´owruchomych) i inne.

II.4. Niezale˙zne propozycje

Ostatnia, cze´sćrozdzia, lu 2 stanowi przeglad, niezale˙znych propozycji zwiazanych, z mobilno´scia, i jej ró˙znymi wariantami. Wspomniane zosta ly artyku ly i koncepcje takie, jak “An improved FHMIPv6 handover for Mobile WiMAX”, “New Handover Mechanism for 802.16e Networks”, “Roaming over WLAN and WiMAX”, “Seamless Realtime Traffic Handover Policy for IEEE 802.16m”, “Human Mobility Patterns”, “Mobile networks on Vehicles across Heterogenous Networks” oraz “Fast RSVP reservation dla Mobile IPv6”. Spostrze˙zenie, ˙ze chocia˙z wiele pracy zosta lo wykonanej w celu analizy i poprawy wydajno´sci, to jednak nadal brakuje uniwersalnego rozwiazania,, które mog loby sprawdzićsie, w ka˙zdych warunkach. Istnieje te˙zwiele przypadkówszczególnych, w których dostepne, obecnie rozwiazania, sprawdzaja, sie, s labo.

III. Propozycje usprawnie´n

W celu poprawy wydajno´sci prze laczania, w sieciach 802.16/IPv6, mo˙zliwe jest wykorzystanie szeregu istniejacych, mechanizmów. Chocia˙zpoprawiaja, wydajno´sć,nie czynia, tego w dostateczny sposóbi konieczne sa, dalsze kroki optymalizacyjne. Dlatego te˙zzosta lo zaproponowane kilka nowatorskich uspraw- nień.Rozdzia l3 zawiera analize, zalet oraz wad wszystkich poruszanych mechanizmów.

III.1. U˙zycie istniejacych, optymalizacji

Istniejace, standardy oferuja, wiele mechanizmówwspomagajacych, przemieszczanie i rekonfiguracje, po zmianie miejsca pod laczenia, do sieci. W szczególno´sci z punktu widzenia analizowanych zagadnieńnaste-, pujace, standardowe procedury okazuja, sie, u˙zyteczne:

• Optymalizacje WiMAX – Protok´o l IEEE 802.16e deﬁniuje wej´scie do sieci jako szereg oddziel-

nych kroków,które po spe lnieniu okre´slonych warunkówmoga, zostaćpominiete., W szczególno´sci sa, to capabilities negotation (negocjacja mo˙zliwo´sci, wiadomo´sci SBC-REQ,SBC-RSP), PKMv2 (mechanizm kryptograficzny zapewniajacy, poufno´sći wiarygodno´sć,wiadomo´sci PKM-EAP-REQ, xxiv Polish Extended Abstract

PKM-EAP-RSP), registration (logowanie do sieci, wiadomo´sci REG-REQ, REG-RSP) oraz service

ﬂow management (tworzenie i zarzadzanie, po laczeniami,, wiadomo´sci DSA-REQ, DSA-RSP i DSA- ACK ) moga, zosta´cpominiete,, o ile docelowa stacja bazowa dysponuje odpowiednia, wiedza, na temat przybywajacej, w la´snie stacji ruchomej.

• Preferencje 255 w DHCPv6 – Protokó lDHCPv6 przewiduje faze, odkrywania serwerów. Proces konfiguracji rozpoczyna klient wysy lajac, wiadomo´sć Solicit. Wszystkie dostepne, serwery og laszaja, swoja, obecno´sćoraz oferowane parametry odpowiadajac, wiadomo´scia, Advertise. Ze wzgledu, na to, ˙zemo˙zliwa jest obecno´sćwiecej, ni˙zjednego serwera, klient zobowiazany, jest kontynuowaćproces nas luchu przez 1000 ms. Ten mechanizm okaza lsie, ca lkowicie niepraktyczny w ´srodowisku mobilnym, gdzie przerwa 1000 ms jest nie do przyjecia., Dlatego te˙zmo˙zliwe jest skrócenie tego czasu. Klient przerywa nas luch, je˙zeli otrzyma odpowied´zod serwera, którego opcja Preference zosta la ustawiona

na maksymalna, warto´s´c255.

• Rapid-commit w DHCPv6 – Innym rozwiazaniem, skracajacym, czas konfiguracji DHCPv6 jest opcja rapid-commit. Klient rozpoczyna proces konfiguracji normalnie, tzn. wysy lajac, wiadomo´sć Solicit. Dodaje do niej jednak opcje, rapid-commit. Serwer, którywspiera to rozwiazanie,, mo˙ze pominaćfaz, e, odkrywania i od razu przydzielićadresy, prefiksy i inne opcje konfiguracyjne wysy lajac, wiadomo´sć Reply, zamiast Advertise.

III.2. Propozycje autorskie

Wymienione mo˙zliwo´sci oferowane przez standardy, chocia˙zu˙zyteczne, nie rozwiazuj, a, problemu du˙zych opó´znieńprzy rekonfiguracji IPv6. Dlatego te˙z opracowano kilka nowatorskich metod, które znaczaco, zmniejszaja, czas konfiguracji. Nastepuj, ace, sekcje skrótowo przedstawiaja, ka˙zda, z propozycji.

III.3. Ominiecie, oczekiwania wstepnego, w DHCPv6

Zdefiniowane przez standard DHCPv6 wstepne,, sztuczne opó´znienie rozpoczecia, konfiguracji o losowy okres czasu nie ma sensu w rozwiazaniach, mobilnych, wiec, powinno zostaćca lkowicie pominiete., Efekt ten mo˙zna uzyskaćpoprzez zmniejszenie zdefiniowanego w RFC3315 parametru SOL MAX DELAY do 0.

Ta optymalizacja bedzie, oznaczana jako skip-initial-delay.

III.4. Ominiecie, wykrywania zduplikowanych adres´ow w IPv6

W realnych warunkach duplikaty adresówprawie nigdy nie wystepuj, a,, wiec, po´swiecanie, ca lej sekundy na czynno´sćsprawdzenia unikalno´sci adresu jest bezcelowa. Jedna, z metod rozwiazania, tego problemu jest ca lkowita rezygnacja z wykonywania tej procedury. Przed zastosowaniem tego rozwiazania, nale˙zy jednak przeanalizowaćpotencjalne zagro˙zenia wynikajace, z pos lugiwania sie, zduplikowanym adresem. Efekt ten mo˙zna uzyskaćpoprzez zmiane, parametru DupAddrDetectTransmits na 0 (parametr zdefiniowany w RFC2462). Ta optymalizacja bedzie, oznaczana jako skip-dad. Polish Extended Abstract xxv

III.5. Wykrywanie zduplikowanych adres´ow po stronie serwera

Nowa, autorska, propozycja, jest przeniesienie cie˙zaru, procedury DAD z klienta na serwer DHCPv6 (ang. server-side DAD). Serwer mo˙ze utrzymywaćniewielka, pule, adresów, których unikalno´sćby laby potwierdzana zanim adres zosta lby w laczony, do puli dostepnych, adresów. Zatem w momencie, kiedy nastepuje, delegacja adresu do klienta, unikalno´sćjest ju˙zpotwierdzona. To rozwiazanie, posiada istotna, zalete, – procedure, DAD mo˙zna wykonaćprzed konfiguracja, klienta, a zatem skraca sie, istotnie czas konfiguracji. Ta optymalizacja bedzie, oznaczana jako server-dad.

III.6. Zdalna autokonﬁguracja poprzez DHCPv6

W zwiazku, z tym, ˙zena poziomie 802.16 znana jest lokalizacja docelowa zanim nastapi, prze laczenie,, mo˙zliwa jest komunikacja ze stacja, docelowa, przed zmiana, miejsca do laczenia, do sieci. W szczególno´sci mo˙zliwa jest wiec, komunikacja zdalna z odleg lym serwerem DHCPv6. Te, ceche, mo˙zna wykorzystaćdo przeprowadzenia konfiguracji DHCPv6 zanim nastapi, w la´sciwe przemieszczenie. Powoduje to, ˙zemo˙zliwe jest zniwelowanie wszelkich opó´znieńwprowadzanych przez DHCPv6. W celu komunikacji ze zdalnym serwerem DHCPv6 mo˙zliwe jest u˙zycie przeka´zników(ang. relay) DHCPv6, jednak w zmodyfikowanej formie. Konieczna jest definicja opcji, która okre´sla do którego serwera nale˙zy przes laćwiadomo´sćod klienta. Ta optymalizacja bedzie, oznaczana jako remote-autoconf.

III.7. Konﬁguracja routingu poprzez DHCPv6

W IPv4 protokó l DHCP odpowiada m.in. za konfiguracje, routingu. Inaczej jest w przypadku IPv6. Ze wzgledu, na to, ˙zew IPv6 ta, role, przeja, l mechanizm Og loszeńRoutera, DHCPv6 nie konfiguruje ju˙z routingu. Mo˙zliwe jest jednak uzupe lnienie przesy lanych informacji o niezbedne, dane do konfiguracji routingu. Zw laszcza w celu konfiguracji routingu lokalnego (tj. do prefiksu dostepnego, bezpo´srednio na laczu),, przydzielany adres wystarczy uzupe lnićjedynie informacja, o d lugo´sci prefiksu, aby otrzymać informacje niezbedne, do konfiguracji routingu lokalnego. Ten mechanizm bedzie, oznaczany jako address- params.

III.8. Zdalne uaktualnienie powiaza´nw, Mobile IPv6

Dzieki, znajomo´scidocelowego adresu IPv6 przed prze laczeniem,, mo˙zliwe jest wys lanie powiadomienia o nowej lokalizacji zanim nastapi, w la´sciwe przemieszczenie. Potencjalnie pozwala to zaoszczedzićpo, lowe, czasu podró˙zy w obie strony (round trip time) pomiedzy, wez, lem ruchomym a wez, lem korespondujacym., Wymaga to jednak analizy szeregu mo˙zliwych komplikacji, np. takich jak transmisja pakietówz nie- poprawnymi topologicznie adresami ´zród lowymi. Ta propozycja bedzie, oznaczana jako remote-binding- update. xxvi Polish Extended Abstract

IV. Analiza wydajno´sci

Rozdzia l 4 jest najobszerniejszym rozdzia lem ca lej pracy. Zosta l on po´swiecony, ocenie i weryfikacji proponowanych mechanizmów. Przedstawiono ró˙zne sposoby walidacji – od modeli analitycznych, poprzez eksperymenty symulacyjne a˙zdo rzeczywistych implementacji. Szczególny nacisk po lo˙zono na ró˙zne aspekty zwiazane, ze ´srodowiskiem symulacyjnym, takie jak metody doboru parametrówpoprzez obserwa- cje, rzeczywistych systemów, w lasno´sci generatorówliczb pseudolosowych, wykrywanie i pomijanie stanów nieustalonych symulacji oraz proponowany aparat statystyczny.

IV.1. Model symulacyjny

W celu oceny wydajno´sci proponowanych mechanizmów,opracowano symulator sieci 802.16 ze wsparciem rodziny protoko lówIPv6 oraz mobilno´sci. Jako ´srodowisko symulacyjne wykorzystano narzedzie, OMNeT++ 3.2, ze wzgledu, na szereg jego zalet: otwarte ´zród la, u˙zycie jezyka, C++, rozbudowana, do- kumentacje,, bezp latno´sćprzy zastosowaniach akademickich, przeno´sno´sć(zw laszcza pomiedzy, systemami Linux i Windows), wsparcie obliczeńrozproszonych oraz skalowalno´sć. Opracowane ´srodowisko o nazwie Numbat zosta lo udostepnione, szerszej spo leczno´sci na zasadach open source. Szczegó lowe informacje zosta ly przedstawione w dalszej cze´sci, niniejszego streszczenia.

IV.2. Generatory liczb pseudolosowych

Komputer jest maszyna, stanówi jego nastepny, stan jest w pe lni zdeterminowany przez poprzedni. Chocia˙zpe lna losowo´sćbez u˙zycia specjalistycznego sprzetu, jest niemo˙zliwa, powsta lo szereg algorytmów generujacych, sekwencje liczb, które stwarzaja, wra˙zenie losowych. Takie algorytmy nazywa sie, genera- torami liczb pseudolosowych. Ka˙zdy generator posiada szereg cech, którenale˙zywziaćpod, uwage, przy podejmowaniu decyzji o wyborze konkretnego algorytmu. Rozdzia l 4 zawiera analize, w la´sciwo´sci, przeglad, dostepnych, agorytmóworaz uzasadnienie podjetego, wyboru. We wszystkich eksperymentach symu- lacyjnych u˙zywano algorytmu o nazwie Mersenne Twister, g lównie ze wzgledu, na jego szybko´sć, jako´sć generowanej sekwencji oraz kolosalny okres (219937 − 1).

IV.3. Metodologia obróbki wyników eksperymentów

W celu poprawnego przeprowadzenia eksperymentu symulacyjnego, konieczne jest spe lnienie kilku wy- mogów. Pierwszym z nich jest dobórodpowiednio du˙zej liczby obserwacji, aby otrzymane wyniki cecho- wa ly sie, za lo˙zona,, wystarczajaco, wysoka, precyzja., Samo zwiekszanie, d lugo´sci trwania symulacji okazuje sie, niewystarczajace., Konieczne jest równie˙zokre´slenie, po jakim czasie symulacja osiaga, stan ustalony i odrzucenie pomiarówz poczatkowych, stanównieustalonych. Drugim elementem obróbki wynikówjest prawid lowe oszacowanie estymowanej warto´sci. Ze wzgledu, na ró˙zne klasy mierzonych parametrów(war- to´sci absolutne lub przyrostowe) zalecane by lo u˙zycie nieco zmodyfikowanej metodologii. Dodatkowo, do ka˙zdej estymaty obliczane by ly poziomy wiarygodno´sci, wzgledna, precyzja pomiaru oraz kilka dodatkowych miar. Polish Extended Abstract xxvii

IV.4. Dane empiryczne

Do poprawnego doboru parametrówmodelu symulacyjnego u˙zyto kilku ´zróde l. Cze´sćz, nich zosta la zdefiniowana bezpo´srednio w ró˙znego rodzaju standardach (np. IEEE802.16, DHCPv6, IPv6). Drugim sposobem na pozyskanie wiarygodnych informacji by ly pomiary parametrówdokonane przy u˙zyciu oprogramowania Dibbler. Jest to implementacja protoko lu DHCPv6, rozwijana przez autora od roku 2003.

Zosta la ona poszerzona o wiele elementówzwiazanych, ze wsparciem mobilno´sci. Opracowany zosta ltak˙ze specjalny tryb logowania, który umo˙zliwia pomiary z dok ladno´scia, mikrosekundowa,, zamiast u˙zywanej do tej pory sekundowej. Ostatnim ´zród lem weryfikacji poprawno´scidobranych parametrówby la implementacja stacji bazowej

802.16e, opracowana w firmie Intel. Od roku 2004 autor, bed, ac, pracownikiem tej˙ze, zajmowa l sie, rozwojem ´srodowiska walidacyjnego dla takiej w la´snie stacji. Chocia˙zze wzgledu, na ochrone, sekretówhandlo- wych oraz zobowiazanie, do nieujawniania informacji, nie jest mo˙zliwe podanie szczegó lów,to poprawne jest stwierdzenie, ˙zeotrzymane wyniki symulacyjne nie stoja, w sprzeczno´sci z rezultatami otrzymanymi w czasie pracy z rzeczywistym sprzetem, w laboratoriach.

IV.5. Symulowane scenariusze

W ramach oceny u˙zyteczno´sci proponowanych metod przygotowano 10 scenariuszy, zawierajacych, po- szczególne optymalizacje, zarówno opisane w standardzie, jak i nowe propozycje. W wiekszo´sci, przypad- kówscenariusze sa, przyrostowe, czyli zawieraja, wszystkie poprzednio w laczone, mechanizmy. Wyjatkiem, sa, sytuacje, kiedy dany problem mo˙zna rozwiazaćza, pomoca, wiecej, ni˙zjednej metody. Oto lista badanych scenariuszy:

• Scenariusz 1: basic – W tym scenariuszu zosta ly wy laczone, jakiekolwiek usprawnienia. Ten scenariusz jest uwa˙zany za najgorszy mo˙zliwy przypadek i s lu˙zyjako jeden z dw´och punkt´owodniesienia.

• Scenariusz 2: wimax-optim – W tym scenariuszu zosta ly w laczone, nastepuj, ace, optymalizacje na poziomie WiMAX: Docelowa stacja bazowa posiada wystarczajac, a, ilo´s´cinformacji a’priori o prze- laczanej, stacji ruchomej, co umo˙zliwia ominiecie, fazy negocjacji parametr´ow,rejestracji i tworzenie strumieni danych od nowa.

• Scenariusz 3: skip-initial-delay – Zawiera wszystkie w laczone, poprzednio optymalizacje. Dodatkowo ´ u˙zywana jest propozycja optymalizacji Ominiecie, oczekiwania wstepnego´na, poziomie DHCPv6.

• Scenariusz 4: preference-255 – Zawiera wszystkie w laczone, poprzednio optymalizacje. Dodatkowo u˙zywana jest standardowa mo˙zliwo´sćustawienia preferencji serwera DHCPv6 na maksymalna, war- to´sć255, co skutkuje wcze´sniejszym przerwaniem procesu odkrywania serwerówDHCPv6.

• Scenariusz 5: rapid-commit – Zawiera wszystkie w laczone, poprzednio optymalizacje. Dodatkowo w laczona, jest dostepna, w standardzie opcja protoko lu DHCPv6 o nazwie rapid-commit, kt´ora powoduje u˙zywanie dwuelementowej, zamiast typowej czteroelementowej wymiany wiadomo´sci (na wia- xxviii Polish Extended Abstract

domo´sćSolicit serwer odpowiada bezpo´srednio wiadomo´scia, Reply). Ten scenariusz mo˙zna okre´slić jako ńajlepszy standardowy”i u˙zywany jest jako drugi z punktówodniesienia.

• Scenariusz 6: skip-dad – Zawiera wszystkie w laczone, poprzednio optymalizacje. Dodatkowo w la-, ´ czona jest propozycja Ominiecie, procedury wykrywania zduplikowanych adres´ow”.

• Scenariusz 7: server-dad – Zawiera wszystkie optymalizacje ze scenariusza 5. Dodatkowo w laczona, ´ jest propozycja ”Procedura DAD po stronie serwera”. Propozycje Ominiecie, procedury DAD´oraz ”procedura DAD po stronie serwera”to dwie wykluczajace, sie, nawzajem propozycje rozwiazania, tego samego problemu. Jako ˙ze wykonanie DAD po stronie serwera jest funkcjonalnie lepsze od

niewykonywania procedury DAD, dlatego kolejne scenariusze zawieraja, w la´snie ta, optymalizacje.,

• Scenariusz 8: remote-autoconf – Zawiera wszystkie w laczone, optymalizacje ze scenariusza 7. W la-, czona zosta la tak˙ze propocyzja Zdalna´ konﬁguracja DHCPv6”.

• Scenariusz 9: address-params – Zawiera wszystkie w laczone, poprzednio optymalizacje. Wykorzy- stywana jest tak˙zepropozycja ”Konﬁguracja routingu poprzez DHCPv6”

• Scenariusz 10: remote-binding-update – Zawiera wszystkie optymalizacje w laczone, w poprzednim ´ scenariuszu. Dodatkowo w laczono, ostatnia, propozycje, Zdalne uaktualnienie lokalizacji”

IV.6. Eksperymenty symulacyjne

Bazujac, na przygotowanych scenariuszach, zdefiniowano i wykonano kilka eksperymentów. Ka˙zdy z nich powtórzono 10 razy, realizujac, kolejne scenariusze. Poni˙zej znaduje sie, lista wykonanych ekspery- mentów.

1. G l´ownym celem eksperymentu 1 by l pomiar ilo´sciodebranego ruchu w kierunku downlink, przy

czym transmisja odbywa la sie, dwukierunkowo. Symulowana sie´csk lada la sie, z 20 stacji abonenckich (z czego 19 jest ruchomych) oraz 4 stacji bazowych. Symulacja trwa la 20 sekund czasu symulowa- nego. U˙zyto ruchu typu “paczkowego” (ang. bursty), z rozmiarami pakietu opisanymi rozk ladem

normalnym. Model przemieszczenia by l oparty o interwa ly – przemieszczenie nastepowa, lo po okre- ´slonym czasie od zakończenia poprzedniej rekonfiguracji. W ka˙zdym z 10 przypadkówdokonano

ponad 7000 pomiarów, co pozwoli lo oszacowaćszybko´sćtransmisji z bardzo du˙za, dok ladno´scia, (od 0,68% do 1,43%).

2. Celem drugiego eksperymentu by lpomiar ilo´sci ruchu przes lanego w kierunku uplink. Po do´swiadcze-

niach z przeprowadzenia eksperymentu 1, dokonano zmiany parametr´ow.Liczbe, stacji abonenckich zmniejszono do 7, przy 3 stacjach bazowych. Czas symulacji nieznacznie wyd lu˙zono do 67 sekund. Parametry ruchowe pozosta ly bez zmian w stosunku do poprzedniego eksperymentu.

3. Trzeci eksperyment zosta l przeprowadzony z my´sla, o pomiarze parametr´owzwiazanych, z samym prze laczaniem., Z tego wzgledu, konieczne by lo dokonanie jak najwiekszej, liczby zmian miejsca pod- laczenia, do sieci, a zatem preferowany by ljak najd lu˙zszy czas symulacji. Dzieki, brakowi konieczno´sci Polish Extended Abstract xxix

zapisywania pomiar´owruchowych, mo˙zliwe by lo wielokrotne zwiekszenie, czasu symulacji. U˙zywajac, sieci z lo˙zonej z 20 stacji abonenckich i 4 stacje bazowe, mo˙zliwe by lo przeprowadzenie symulacji

trwajacych, od 1200 do 1600 sekund. Zmieniono model przemieszczeńna czasowo-losowy, tzn. co okre´slony przedzia l czasowy nastepowa, l handover do losowej stacji bazowej. W czasie trwania ka˙z- dego przemieszczenia obserwowano czas rekonfiguracji IPv6, czas konfiguracji DHCPv6 oraz czas ponownego wej´scia do sieci.

4. Ostatni, czwarty eksperyment mia lna celu pomiar pozosta lych parametr´owprze laczania, oraz prak- tyczne okre´slenie granic mo˙zliwo´sci ´srodowiska symulacyjnego. Dzieki, wprowadzeniu poprawek po obserwacjach poczynionych w trakcie poprzedniego eksperymentu, mo˙zliwe by lo dalsze wyd lu˙zenie

czasu symulacji. Jedynie scenariusz 6 zakończy l sie, po oko lo 3000 sekundach. Pozosta le trwa ly zgodnie z przewidywaniami 4800 sekund. Tak d lugi czas symulacji pozwoli l zebraćznaczac, a, liczbe, pomiarówinteresujacych, parametrów.Obserwowano czas przygotowania do prze laczenia, oraz laczny, czas braku zdolno´sci komunikacyjnych. Zastosowano tak˙zenowy model generowanego ruchu – pa-

kiety o znacznie wiekszej, d lugo´sci (do 1500 bajt´ow)przy rozk ladzie beta.

IV.7. Przeprowadzone badania

Korzystajac, z opracowanego oprogramowania, wykonano szereg eksperymentów,w czasie których ba- dano zachowanie sie, stacji ruchomych w ró˙znych warunkach. Szczególny nacisk po lo˙zono na badanie parametrówzwiazanych, z prze laczeniem,, takich jak: czas przygotowania do prze laczenia,, czas ponownego wej´scia do sieci, czas konfiguracji DHCPv6, czas ca lej rekonfiguracji warstwy IPv6, a tak˙zeokres braku zdolno´sci komunikacyjnych. Korzystajac, z okazji, zbadano równie˙zparametry ruchu przy zastosowanych modelach transmisji i mobilno´sci.

IV.8. Transmisja i modele ruchu

Wykonujac, prze laczenie,, urzadzenie, ruchome jest przez pewien okres pozbawione mo˙zliwo´sci komunikacji. Zak ladajac,, ˙zeprze laczenia, nastepuj, a, czesto,, ma to znaczacy, wp lyw na uzyskiwana, przep lywno´sć. Mo˙zna wiec,, niejako przy okazji, przeanalizowaćrównie˙zwp lyw czestych, prze laczeńna, ilo´sćtransmitowa- nych danych. Podobnie, jak to ma miejsce w omówionych poni˙zej przypadkach, kluczowym problemem w oszacowaniu warto´sci parametru jest okre´slenie momentu, w którym symulacja osiaga, stan ustalony. We wstepnej, fazie symulacji, mierzone warto´sciulegaja, radykalnym zmianom, które spowodowane sa, stanami nieustalonymi zwiazanymi, z rozpoczeciem, symulacji. Przy badaniu nate˙zenia, ruchu zastosowano wspomniane ju˙zdwa modele ruchu. Histogramy zawierajace, rozk lady wielko´sci pakietów(zarówno dla rozk ladu normalnego, jak i beta) przedstawiono w rozdziale 4. Ostatecznie, mo˙zliwe by lo pomierzenie ilo´sciprzesy lanych danych i porównanie poszczególnych rezul- tatów. Chocia˙zporównanie wizualne wykresównie by lo u˙zywane do oceny ilo´sciowej, mo˙zes lu˙zyćjako ilustracja osiagni, etych, rezultatów. Najbardziej wyra´zna, ró˙znice, widaćprzy porównaniu scenariusza pod- stawowego z najbardziej zaawansowanym. Przerwy spowodowane prze laczeniem, oraz rekonfiguracja, sa, xxx Polish Extended Abstract

bardzo widoczne. U˙zyty model ruchu (prze laczenie, po 4 sekundach od zakończenia poprzedniego prze- laczenia), dodatkowo uwydatnia te przerwy. Scenariusz 10, w którym u˙zyto analogicznego modelu ruchu przy w laczonych, wszystkich optymalizacjach sprawia, ˙zeprzerwy spowodowane prze laczeniem, skurczy ly sie, jedynie do pojedynczych, waskich, “pików”, kiedy transmisja na bardzo krótki czas spada do zera.

IV.9. Czas przygotowania do prze laczenia,

Po stwierdzeniu konieczno´sci zmiany punktu przy laczenia, do sieci i wybraniu miejsca docelowego, stacja ruchoma informuje o tym kontrolujac, a, ja, stacje, bazowa., Ta, po decyzji odno´snie wykonania prze lacze-, nia, udziela zgody stacji ruchomej, która ostatecznie od lacza, sie, od obecnej stacji w dogodnym dla siebie momencie, o czym informuje stosownym komunikatem. Ten okres nazywany jest czasem przygotowania do prze laczenia, (ang. Handover Preparation Time). Parametr ten by lbardzo stabilny, poniewa˙zzmienia l sie, jedynie w niewielkim zakresie 101 do 103 ms. Dopiero wprowadzenie zdalnej autokonfiguracji spowo- dowa lo wyd lu˙zenie tego parametru do przedzia lu 309 – 320 ms. Chocia˙ztakie wyd lu˙zenie jest zjawiskiem niepo˙zadanym,, nale˙zyzauwa˙zyć, ˙zew czasie fazy przygotowawczej stacja ruchoma zachowuje zdolno´sci komunikacyjne. Mo˙zna wiec, traktowaćten “objaw” jako niezbedny, koszt poprawy innych parametrów.

IV.10. Czas ponownego wej´scia do sieci

Po roz laczeniu, z dotychczasowa, stacja, bazowa,, stacja ruchoma rozpoczyna proces wej´scia do sieci w lokalizacji docelowej. Zgodnie z oczekiwaniami badania wykaza ly, ˙ze wp lyw na ten parametr maja, jedynie mechanizmy w laczone, w scenariuszu 2 (optymalizacje WiMAX). W tym przypadku obserwowano skr´ocenie czasu wej´scia do sieci z 595 ms do oko lo 80 ms.

IV.11. Czas rekonﬁguracji stosu IPv6

Po zakończeniu wej´scia do sieci na poziomie IEEE 802.16, nale˙zyrozpoczaćrekonfiguracj, e, stosu IPv6. Pomiary tego parametru pozwoli ly wyodrebnić3, grupy, na któredziela, sie, scenariusze. Zdecydowanie najwiekszy, wp lyw ma tutaj opcja rapid-commit (skrócenie z pu lapu oko lo 2400 ms do 1350 ms) oraz propozycje skip-dad i server-dad (dalsze zmniejszenie do warto´scioko lo 320 ms).

IV.12. Czas konﬁguracji DHCPv6

Istotnym elementem rekonfiguracji jest mechanizm DHCPv6. Biorac, równie˙zpod uwage,, ˙zeta w la´snie faza jest obszarem kilku propozycji optymalizacji, jej analiza nabiera szczególnego znaczenia. Analizujac, rezultaty z poszczególnych scenariuszy widać,˙ze na protokó l DHCPv6 najwiekszy, wp lyw maja, 3 optymalizacje: standardowa rapid-commit (zmniejszenie z 2100 ms do 1080ms), oraz Skip-dad (propozycja, scenariusz 6) oraz Server-dad (propozycja, scenariusz 7). W obu przypadkach czas zosta l skrócony do oko lo 80 ms. Polish Extended Abstract xxxi

IV.13. Przerwa w zdolno´sciach komunikacyjnych

Najwa˙zniejszym z analizowanych parametrówjest brak zdolno´sci komunikacyjnych (ang. Lack of communication capability), zwany potocznie, choćnieco niepoprawnie, opó´znieniem prze laczenia, (ang. Han- dover Delay). Okre´sla on, przez jaki czas stacja ruchoma nie ma mo˙zliwo´sci nadawania lub odbierania danych. Parametr ten ma najwieksze, znaczenie ze wzgledu, na to, ˙ze jest bezpo´srednio odczuwany przez u˙zytkownika końcowego. Dlatego te˙z mo˙ze stanowićnajbardziej wiarygodna, metryke, pomiaru jako´sci prze laczenia., Maja, na niego wp lyw prawie wszystkie analizowane do tej pory czynniki.

Z sumarycznego zestawienia widać, ˙zemo˙zna podzielićoptymalizacje na kilka grup. Najwiekszy, zysk czasowy uzyskiwany jest po w laczeniu, optymalizacji na poziomie WiMAX (scenariusz 2), opcji rapid- commit (scenariusz 5), oraz propozycji skip-dad (scenariusz 6) lub Server-dad (scenariusz 7). Kolejny, choćnieco mniejszy zysk, oferowany jest przez w laczenie, zdalnej konfiguracji (scenariusz 8). Pozostale optymalizacje nie wnosza, znaczacych, usprawnień.Pomiary braku zdolno´sci komunikacyjnych dla wszystkich scenariuszy zmienia ly sie, od poczatkowych, 2900ms a˙zdo 325ms. Podsumowujac, mo˙zna stwierdzić, ˙zezastosowanie kombinacji dostepnych, i zaproponowanych metod optymalizacji prze laczenia, umo˙zliwia osiagni, ecie, znaczacej, poprawy w zakresie trwania prze laczenia., Ma to ogromny wp lyw na wydajno´sć transmisji w stacjach mobilnych.

V. Wnioski i rezultaty

Ostatni, piaty, rozdzia l podsumowuje wykonane prace i przedstawia wnioski odno´snie u˙zyteczno´sci proponowanym usprawnie´n. W trakcie prac badawczych prowadzonych przez autora poczyniono wiele obserwacji. Najwa˙zniejsze z nich to:

• U˙zywajac, zaproponowanych technik poprawy mechanizmu prze laczania,, op´o´znienie zosta lo zmniej- szone z 1390ms do 325ms, co stanowi poprawe, o 76% w por´ownaniu do najlepszych standardowych metod.

• Zaproponowano kilka usprawnieńw protokole IPv6 i DHCPv6: ominiecie, oczekiwania wstepnego,, ominiecie, wykrywania zduplikowanych adresów,wykrywanie zduplikowanych adresówpo stronie serwera, zdalna autokonfiguracja, konfiguracja routingu poprzez DHCPv6 oraz zdalne uaktualnienie

powiaza´n., Wed lug wiedzy autora, sa, to pierwsze propozycje w skali ´swiatowej dotyczace, poprawy protoko lu DHCPv6 z punktu widzenia mobilno´sci.

• Pomys lprzeprowadzenia stanowej autokonfiguracji zdalnie, zanim weze, lruchomy znajdzie sie, fizycz- nie w zasiegu, lacza, jest nowatorski i nigdy wcze´sniej nie by l proponowany ani analizowany. Z tego wzgledu, mo˙zebyćtraktowany jako nowe rozwiazanie, ogólnie znanego problemu.

• Podobnie pomys l przesuniecia, obowiazkówweryfikacji, unikalno´sci otrzymanych adresówz klienta na serwer jest innowacyjny. Brak jest jakichkolwiek wzmianek na jego temat w ogólnie dostepnej, literaturze. xxxii Polish Extended Abstract

• Przeprowadzone badania umo˙zliwi ly identyfikacje, g lównych przyczyn opó´znień.Wyniki symulacyjne jednoznacznie potwierdzaja,, ˙ze obie przyczyny le˙za, w protoko lach IPv6 oraz DHCPv6. Powodem najwiekszych, opó´znieńjest procedura wykrywania zduplikowanych adresów.Zaproponowano dwie metody optymalizacyjne, które pozwalaja, ca lkowicie wyeliminowaćte opó´znienia: ominiecie, wykrywania zduplikowanych adresóworaz realizacja tej procedury po stronie serwera. Chocia˙zpierwsza

jest znaczaco, prostsza, obni˙za ona poziom pewno´sci, z jakim mo˙zliwe jest u˙zywanie adresu, dlatego te˙zdruga propozycja jest bardziej u˙zyteczna.

• W ramach prowadzonych prac powsta ly dwa projekty: Dibbler (implementacja protoko lu DHCPv6) oraz Numbat (´srodowisko symulacyjne sieci 802.16/IPv6). Oba projekty zyska ly uznanie na arenie

miedzynarodowej, i sa, obecnie u˙zywane odpowiednio: w 30 i 8 krajach na ca lym ´swiecie.

• Zosta lo udowodnione, ˙zezdalna automatyczna konﬁguracja jest u˙zytecznym sposobem na zmniej-

szenie opó´znieńnawet w wysoce zoptymalizowanych przypadkach. Dzieki, znajomo´sciadresu i pa- rametrówdocelowych przed dokonaniem prze laczenia,, po fizycznym zmianie miejsca do laczenia, do sieci stacja ruchoma nie musi ju˙ztracićczasu na konfiguracje, w lokalizacji docelowej. To powoduje, ˙zemo˙zliwe jest uzyskanie dalszej poprawy i ostatecznie zmniejszenie ca lego czasu prze laczenia, do zaledwie 320 ms.

W ´swietle przedstawionych osiagni, ećmo˙zna, stwierdzić, ˙ze teza rozprawy, stwierdzajaca, ˙ze proces rekonfiguracji IPv6 w czasie prze laczenia, w sieciach 802.16 nie jest optymalny i mo˙zliwe jest osiagni, ecie, zwiekszonej, wydajno´sci prze laczania, poprzez modyfikacje, protoko lów IPv6, DHCPv6 oraz Mobile IPv6 zosta la udowodniona.

V.1. Dibbler – implementacja DHCPv6

Dibbler jest pierwsza, pe lna, implementacja, protoko lu DHCPv6, kt´oraoferuje funkcjonalno´s´cserwera, klienta, przeka´znika oraz requestora3. Obecnie oprogramowanie wspiera systemy Windows NB4, 2000, XP,

2003, Viste, oraz Windows 7, a tak˙zesystemy Linux oraz Mac OS X. Oferuje obie formy autokonfiguracji: stanowa, (czyli nadawanie adresówi prefiksów)oraz bezstanowa, (czyli nadawanie opcji konfiguracyjnych). Poza podstawowa, funkjonalno´scia,, wpierany jest szereg rozszerzeń,np. konfiguracja serwerówDNS, urza-, dzeńSIP, serwerówczasu itp. Dibbler jest oprogramowaniem open source. Oznacza to, ˙zejest on dostepny, za darmo wraz z kodem ´zród lowym i ka˙zdy dysponujacy, odpowiednimi umiejetno´sciami, mo˙ze u˙zywać, mo- dyfikować,a nawet rozpowszechniaćw lasne wersje.

Ze wzgledu, na to, ˙ze oprogramowanie to zosta lo w laczone, do kilku popularnych dystrybucji Linuksa (Debian, Ubuntu, Gentoo, OpenWRT oraz PLD), nie jest mo˙zliwe bezpo´srednie ´sledzenie ilo´scii lokalizacji u˙zytkownik´ow.Z autorem skontaktowali sie, u˙zytkownicy z 30 kraj´ow(Polska, Niemcy, Czechy, Francja, Hiszpania, Stany Zjednoczone, Chiny, Malezja, Kanada, Taiwan, Szwajcaria, Turcja, Indie, Wielka Bryta- nia, Austria, Izrael, Norwegia, Tajlandia, Finlandia, Filipiny, Wenezuela, Bo´snia i Hercegowina, Portugalia

3 Brak polskiego odpowiednika tej nazwy. Requestor jest to specjalny rodzaj programu nawiazuj, acy, komunikacje, z serwerem w celu wys lania zapyta´no udzielone dzier˙zawy (leasequery). Polish Extended Abstract xxxiii oraz Nowa Zelandia4). Innym sposobem oceny popularno´sci dostarczanego oprogramowania jest uczest- nictwo w li´scie mailowej po´swieconej, oprogramowaniu Dibbler. Zainteresowanie wyra˙zaja, ﬁrmy takie, jak Broadcom, Cisco, Conexant, HP, Intel, L&T Infotech, Mitel, Nokia, Orange (France Telecom), Qualcomm, Sony, Toshiba, Wipro, Xerox i inne.

Autor zosta l zaproszony na kilka sesji testowych DHCPv6, zwiazanych, ze spotkaniami grupy IETF w Amsterdamie, Vancouver oraz Filadelfii. Dibbler okaza lsie, jedynym rozwiazaniem,, które oferuje wszystkie funkcjonalno´sci: serwera, klienta, przeka´znika i requestora. Interoperacyjno´sćz komercyjnymi rozwia-, zaniami pozwala stwierdzić, ˙ze jest to produkt dojrza ly i w pe lni u˙zyteczny.

Dibbler jest tak˙zecieszacym, sie, powodzeniem ´srodowiskiem badawczym. Sze´sciu studentów(czterech z Polski, oraz po jednym z Turcji oraz Tajlandii) wykorzysta lo Dibblera w swoich magisterskich pracach dyplomowych (lub odpowiednikach). Oprogramowanie to by lo tak˙zeu˙zywane w wielu projektach studenc- kich. Interesujacym, przyk ladem jest projekt zrealizowany przez grupe, sze´sciu studentówz Uniwersytetu w Tuluzie. Autor opublikowa ltak˙ze kilka artyku lówzwiazanych, z Dibblerem i protoko lem DHCPv6. Wa˙z- niejsze miedzynarodowe, publikacje to artyku ly przyjete, i wyg loszone na konferencjach takich, jak 8th IEEE International Conferenc on Telecommunications w Zagrzebiu oraz 1st IEEE International Conference on Information Technology w Gdańsku.

V.2. Numbat – ´srodowisko symulacyjne

W ramach prac badawczych opracowano ´srodowisko, kt´ore umo˙zliwia symulacje, prze laczenia, w ´srodowisku 802.16/IPv6 wraz z odwzorowaniem wszystkich analizowanych warstw. Implementacja zosta la oparta na standardzie 802.16-2005, znanym r´ownie˙zjako 802.16e lub mobilny WiMAX. W jej sk lad wcho- dza, nastepuj, ace, komponenty i funkcjonalno´sci:

• Warstwa radiowa/PHY – oferuje transmisje, unicastowa, (punkt-punkt) od stacji abonenckiej do stacji bazowej oraz transmisje, multicastowa, (punkt-wielopunkt) od stacji bazowej do wielu stacji abonenckich.

• Modulacja OFDMA – Specyfikacja 802.16-2005 opisuje kilka ró˙znych modulacji, któremoga, być u˙zywane w sieciach WiMAX. OFDMA jest najpopularniejsza, z nich. Wykonana implementacja oferuje nieco uproszczony model, który oferuje jednak pe lna, strukture, tzw. ramki radiowej, transmisje, symboli i kodówCDMA oraz kalkulacje, podkana lów,symboli oraz slotów.

• Zarzadzanie, pasmem – Wspierane sa, mechanizmy zarzadzania, pasmem, dostepne, w sieciach 802.16: pro´sby o pasmo BWR (ang. Bandwidth Request), kody CDMA w celach rangingu, prze laczania, lub pro´sby o pasmo. Generowane i poprawnie obs lugiwane sa, równie˙zwiadomo´sci UL-MAP i DL-MAP, któreodpowiadaja, za strukture, ramki radiowej. • Klasy ruchu: BE oraz UGS – Zaimplementowano pe lne wsparcie dla klasy ruchu BE (Best Effort) oraz Unsolicited Grant Service (UGS). Wsparcie dla pozosta lych, nietypowych klas ruchu (rt-PS,

nrt-PS oraz ert-PS) jest na razie cze´sciowe., 4 Kraje zosta lyuporzadkowane, w kolejno´sci, w jakiej z autorem komunikowali sie, u˙zytkownicy. xxxiv Polish Extended Abstract

• Warstwa kontrolna (ang. control plane): ranging – w pe lni obs lugiwana jest procedura rangingu (wiadomo´sci RNG-REQ oraz RNG-RSP).

• Warstwa kontrolna: negocjacja parametr´ow– zosta lo zaimplementowanie wsparcie dla mechanizmu

Basic Capabilities Negotiation, wchodzacego, w sk lad procedury wej´scia do sieci (wiadomo´sci SBC- REQ oraz SBC-RSP).

• Warstwa kontrolna: kryptografia – ze wzgledu, na du˙za, z lo˙zono´sćproblemówkryptograficznych (ob- s luga, ochrony kryptograficznej zajmuje sie, ca ly oddzielny protokó lPKMv2), wsparcie dla szyfrowa- nia, autoryzacji i uwierzytelniania zosta lo wykonane w stopniu minimalnym, niezbednym, do osza- cowania wnoszonych opó´znień.

• Warstwa kontrolna: rejestracja sieciowa – dodano r´ownie˙zwsparcie dla mechanizmu logowania do sieci (wiadomo´sciREG-REQ oraz REG-RSP).

• Warstwa kontrolna: tworzenie i zarzadzanie, strumieniami – zaimplementowano tworzenie i zarzadza-, nie strumieniami us lugowymi (ang. service ﬂows). Obs lugiwane jest zar´owno tworzenie strumieni od

poczatku,, jak i ich odtwarzanie po prze laczeniu, (wiadomo´sci DSA-REQ, DSA-RSP oraz DSA-ACK).

• Warstwa danych: strumienie – warstwa danych (ang. data plane) zawiera wsparcie dla tzw. regu l warstwy konwergencji (ang. Convergence Sublayer Rules lub CS rules). Wspierane typy klasyﬁkacji

bazuja, na lokalnych i globalnych adresach IPv6.

• Warstwa kontrolna: scanning – z punktu widzenia mobilno´sci, procedura skanowania sasiaduj, acych, stacji bazowych jest niezwykle wa˙zna. Przygotowana implementacja w pe lni obs luguje ten mechanizm (wiadomo´s´cSCN-REQ oraz SCN-RSP).

• Warstwa kontrolna: prze laczenie, inicjowane przez stacje, abonencka, – 802.16 oferuje dwa sposoby zmiany miejsca przy laczenia, do sieci: zg loszone przez stacje, bazowa, lub przez stacje, abonencka., Pierwszy sposóbnie zyska l przychylno´sci producentówsprzetu,, wiec, w u˙zyciu jest g lównie model drugi. Jest on wspierany przez symulator Numbat. (wiadomo´sci MSHO-REQ, BSHO-RSP oraz HO-IND).

• Warstwa kontrolna: ponowne wej´scie do sieci – u˙zywajac, terminologii zaczerpnietej, ze specyfikacji 802.16, handoverem nazywa sie, faze, od laczania, od obecnej stacji bazowej i informowania o przewi- dywanej docelowej stacji bazowej. Procedura nastepuj, aca, po zmianie miejsca lokalizacji nosi nazwe, ponownego wej´scia do sieci (ang. network reentry). Procedura ta posiada liczne elementy, które przy spe lnieniu okre´slonych warunków(np. wiedza na temat parametrówoczekiwanej stacji klienc-

kiej po stronie stacji bazowej) moga, zosta´cpominiete., Przygotowany symulator umo˙zliwia dowolne w laczanie, i wyl aczanie, element´owtej procedury w zale˙zno´sci od analizowanego scenariusza.

• Modele generowanego ruchu – Zaimplementowano kilka modeli ruchu, kt´ore moga, by´cu˙zywane w zale˙zno´sci od potrzeb. Typ ruchu okre´sla sie, dla ka˙zdej stacji abonenckiej oddzielnie, dlatego mo˙zliwa Polish Extended Abstract xxxv

jest symulacja wielu typ´owruchu naraz. Wspierane modele to: stacja nieruchoma, prze laczenie, po okre´slonym czasie do kolejnej stacji bazowej, prze laczenie, po okre´slonym czasie do losowej stacji bazowej, ruch po okregu, i prze laczenie, bazujace, na pomiarze si ly sygna lu (odleg lo´sci) od stacji bazowych; ruch po linii prostej i prze laczenie, bazujace, na pomiarze si ly sygna lu (odleg lo´sci) od stacji bazowych.

• Wsparcie dla wielu stacji klienckich i bazowych – Mo˙zliwa jest symulacja wielu stacji. Parametry

okre´slane moga, by´czbiorczo lub dla ka˙zdej stacji oddzielnie.

Ponad warstwa, sieciowa, (WiMAX) dzia la warstwa sieciowa, która, w tym przypadku jest ca la rodzina protoko lówIPv6. Wsparcie zosta lo zaimplementowane ze szczególnym uwzglednieniem, elementówistot- nych z punktu widzenia mobilno´sci. W ´srodowisku Numbat zaimplementowano nastepuj, ace, modu ly:

• IPv6Node – podstawowy weze, l IPv6, który generuje i odbiera ruch IPv6. Obs lugiwane jest kilka modeli. Pierwszym z nich jest ruch generowany paczkami (ang. burst), gdzie co okre´slony czas wysy lana jest pewna ilo´sćpakietówo zadanym rozmiarze. Ten typ ruchu dobrze oddaje transmisje czu le na opó´znienia, jak ruch VoIP lub transmisja wideo. Inny u˙zywane model generuje ruch typu

cie˙zkiego, (ang. bulk), gdzie pakiety wysy lane sa, co okre´slony interwa l, przy czym d lugo´sćpakietów zazwyczaj zbli˙zona jest do maksymalnego. Ten typ ruchu dobrze odwzorowuje transmisje, danych, np. ´sciaganie, du˙zych plikówwideo. Mo˙zliwa jest konfiguracja szeregu parametrów,takich jak maksymalny rozmiar pakietu, rozmiar serii oraz rozk lad rozmiaru pakietów(np. rozk lad normalny lub beta).

• DHCPv6Cli – modu lodpowiedzialny za operacje zwiazane, z protoko lem DHCPv6 po stronie klienta. Opr´ocz standardowego dzia lania wraz z mo˙zliwo´scia, w laczania, i wy laczania, optymalizacji oferowa- nych przez standard, wspiera on wszystkie proponowane mechanizmy optymalizacyjne.

• DHCPv6Srv – modu lodpowiedzialny za operacje zwiazane, z protoko lem DHCPv6 po stronie serwera. Podobnie do klienta, umo˙zliwia on w laczanie, lub wy laczanie, wszystkich standardowych i proponowanych usprawnie´n.

• MIPv6mn – modu l oferujacy, funkcjonalno´s´cwez, la ruchomego (ang. mobile node) protoko lu Mo- bile IPv6. G l´owna, funkcjonalno´scia, jest mechanizm Binding Update wraz z jego proponowanym usprawnieniem, u˙zywany podczas przemieszczenia.

• MIPv6cn – modu loferujacy, funkcjonalno´s´cwez, la korespondujacego, (ang. correspondent node) protoko lu Mobile IPv6. Wspiera on mechanizm Binding Update po stronie zdalnej, tj. aktywnie obs luguje

otrzymywane wiadomo´sci Binding Update, generujac, stosowne odpowiedzi Binding Acknowledge.

• MIPv6ha – prosty modu l, zapewniajacy, funkcjonalno´s´cagenta domowego protoko lu Mobile IPv6.

• IPv6disp – modu l koordynujacy, dzia lanie pozosta lych modu l´owIPv6. Pe lni role, rozdzielacza (ang. dispatcher) ruchu IPv6. xxxvi Polish Extended Abstract

´ Srodowisko Numbat wspiera równie˙zwszystkie proponowane rozszerzenia: ominiecie, oczekiwania wstep-, nego, ominiecie, procedury wykrywania zduplikowanych adresów,procedura wykrywania zduplikowanych adresówpo stronie serwera, zdalna konfiguracja IPv6, Zdalne uaktualnienie lokalizacji oraz konfiguracja routingu poprzez DHCPv6. Ka˙zde z nich mo˙ze zostaćw laczone, lub wy laczone, dla ka˙zdej stacji osobno, w zale˙zno´sciod potrzeb.

Bezpo´srednim rezultatem prac zwiazanych, z opracowaniem symulatora Numbat, by lo kilka artyku lów opublikowanych na arenie miedzynarodowej., Wa˙zniejsze publikacje to artyku l“Numbat – extensible simulation environment for mobile, IPv6 capable IEEE 802.16 stations”, zaprezentowany na konferencji IEEE ATNAC’2007 (Australasian Telecommunication Networks and Applications Conference w Chirstchurch w Nowej Zelandii) oraz ”How to Improve Inefficiencies in IPv6 Handovers in IEEE 802.16 Networks”. Zosta l on wyg loszony na miedzynarodowej, konferencji ATNAC’2008, zorganizowanej przez University of Adelaide w Australii, pod auspicjami IEEE i przy wspó lpracy z firma, Cisco. Dodatkowo artyku l“Reconfiguration Efficiency Analysis in IPv6 Handovers in IEEE 802.16 Environment” zosta lprzyjety, do publikacji w pre- sti˙zowym czasopi´smie Telecomunication Systems (uka˙ze sie, sie, wydaniu Vol. 45, No. 2-3, 2010). Liczba wszystkich publikacji zwiazanych, tematycznie z praca, wynosi 12. 1. Introduction

This chapter provides introduction to mobility topics and offers high level overview of the handover related issues. Justification of the area of study selection is provided with some additional background information. Goals and the main thesis of this dissertation are also defined. As a convenience to the non-expert readers, short introduction describing WiMAX, IPv6, DHCPv6 and Mobile IPv6 protocols is provided.

As digital data processing solutions are becoming ubiquitous, the growing attractiveness of various kinds of related technologies is observed. The amount of digital information created, stored, retrieved and transmitted is increasing rapidly, thus stimulating interest in related areas of both end users and network operators. At the same time, portable and diﬀerent hand-held devices are becoming smaller and more powerful. As with all electronic equipment, also mobile devices are aﬀected by Moore’s law, which states that the computing power of devices doubles every 18 months. With wireless technologies reaching their maturity, more users are expected to use mobile devices. As a direct result of both trends, users’ demand for transmission and reception of digital data is constantly increasing. This in turn results in growing popularity of various mobile oriented multimedia applications, like video on demand or VoIP services. From the network point of view, two requirements – delivering large amounts of data and providing mobility – are very hard to achieve at the same time. That is because changing a point of attachment to the network by a mobile station is usually complicated.

1.1. WiMAX Overview

WiMAX is a commercial name of networks and various types of equipment that are conformant to the 802.16 specifications [34, 36], developed by IEEE. Considered as a wireless replacement for DSL lines, WiMAX meets or exceeds expectations. Offering a range of up to 50km, with throughput up to 70Mbps (1Gbps for stationary subscribers will be provided by the 802.16m extension) and good handling of NLOS (non line of sight) scenarios, it seems to be the perfect network solution for urban, suburban and rural areas. A WiMAX network consists of several base stations and a large number of subscriber stations, both fixed and mobile. An example WiMAX network is presented in Fig.1. First version, designated as 802.16-2004 [34], or 802.16d was published in 2004 and describes operation of wireless fixed Metropolitan Area Networks. An extension, designated 802.16e-2005 or 802.16e [36], that provides support for mobility was published two years later1. It is also commonly referred to as “mobile

1Contrary to its designation, 802.16-2005 speciﬁcation was published in early 2006. 2 Introduction

Figure 1: Example 802.16 network with four base stations and 20 subscribers

WiMAX”. This dissertation in general and this section in particular focuses on this enhanced version. For general 802.16 overview and comparison to other wireless protocols, see [120]. References for more thorough analysis and operation details of 802.16 networks are provided in [87].

WiMAX network consists of two entities: Subscriber Stations, and Base Stations. Subscriber Stations, often abbreviated as SS, are small devices installed at customer’s premises or connected to customer’s hardware. In an average metropolitan network, the number of Subscriber Stations is expected to be in the range of thousands per Base Station. Each Subscriber Station has to be wirelessly connected to a controlling Base Station, before any services may be provided. The average metropolitan network is expected to have several Base Stations. (Specification defines also experimental mesh mode that allow subscriber stations to communicate directly, without assistance from Base station, but this mode is outside of scope of this dissertation.) Process of establishing connectivity between Subscriber Station and its serving Base Station is called Network Entry. There are two types of Subscriber Stations: fixed and mobile. In this dissertation, it is assumed that Subscriber Station is mobile, unless clearly stated otherwise. Mobile Introduction 3

Subscibers are often abbreviated as MS or MSS in the literature. Subscriber Station may be within range of several Base Stations. To access its current neighboring Base Stations and evaluate signal quality, it may periodically initiate procedure called Scanning. Once it detects that serving Base Station no longer oﬀers best connection, handover procedure may be initiated. After detachment from serving Base Station is complete, Subscriber Station adjusts radio to tune in to target Base Station transmissions and performs Network Reentry procedure. All mentioned procedures (network entry, scanning, handover and network reentry) are commonly referred to as Control plane activities.

1.1.1. MAC messages and CS sublayer

802.16 is a connection oriented protocol. Data transmission is ogranized in radio frames, typically spanning 5ms interval. All transmissions occurring during each radio frames are controlled by Base Station. Each radio frame is divided into downlink subframe, where Base Station sends data to Subscriber Stations and uplink subframe, where Subscriber Stations send data to Base Station. Each transmission conveys one or more MAC messages2. Over 50 types of control messages were defined in [36]. They are used for control and signalling different aspects of WiMAX operation, like ranging, scanning or various stages of network entry. To transmit user data, a convergence sublayer was defined. It is used to convey user data (e.g. IPv4, IPv6 or Ethernet) packets over MAC messages. The first two MAC messages in each radio frame are DL-MAP and UL-MAP messages. Each map contains allocations for specified Subscribers and also general opportunities for various requests, like ranging or bandwidth requests. All operations related to data processing are commonly referred to as Data plane activities. Bandwidth management is connection oriented. Base Station maintains several service flows for each Subscriber Station: Basic, Primary and Secondary service flows for control traffic and at least one uplink and one downlink user data connections. Each service flow has defined traffic type. The worst type is Best Effort, as it offers virtually not guarantees regarding QoS. Subscriber has to request bandwidth by sending Bandwidth Request (BWR) message every time it wants to transmit any data. Another common type is UGS – Unsolicited Grant Service. During service flow creation, Subscriber and Base Stations agree on service parameters. After that procedure is complete, base station offers transmission opportunities for that Subscriber on a regular basis. There are other, less commonly used traffic types: nrtPS, rtPS, and ertPS. For more details regarding frame structure, see Section 4.1.3 and corresponding figures (Fig.7,8 and9). Complete frame structure is described in [46] and the specifiction itself [36].

1.1.2. Initial Network Entry

Network Entry is a complicated process and consists of several steps. Depending on Base Station capabilities conﬁguration, and existing conditions, certain steps of the procedure may be omitted. The ﬁrst operation intended for radio adjustment and tuning is called ranging. Subscriber Station sends CDMA

2Using packing and fragmentation features, it is possible to send part of a single message, single message, or several messages in one transmission. 4 Introduction code or RNG-REQ message, which is replied with RNG-RSP message that contains information regarding received signal strength and quality. Ranging can be repeated up to 16 times, if radio adjustments do not produce expected signal quality. During network reentry that is the only necessary step, if certain extra conditions are met. Although handover ranging conveys different options compared to normal ranging, the basic principles are the same. The next step is basic capabilities negotiation. Subscriber station constructs list of all supported features and sends it, using SBC-REQ message. Base Station, removes from that list unsupported and disabled features and sends response in SBC-RSP message. Depending on subscriber and base station capabilities, security negotiation may follow. That is handled by a separate Privacy Key Management protocol. 802.16-2005 [36] introduces version 2 of that protocol. As security is a very broad topic, issues related to cryptographic protection were left out of scope of this dissertation. For a detailed explanation regarding security in WiMAX networks, see [1]. Details of PKMv2 protocol are provided in [82]. Following step is a network registration. Subscriber Station sends REG-REQ message. Base Station decides if Subscriber is allowed to log into the network (usually by contacting AAA server, but exact operation is left up to Base Station vendors) and sends a reply using REG-RSP message. After Subscriber Station is logged into the network, the last step to be completed is service flows creation that will be used to transmit user data. For each requested service flow (usually there are at least two – one for uplink and one for downlink) a DSA-REQ message is sent with all intended parameters of the service flow (traffic type, maximum sustained rate, maximum jitter, etc.). Base Station responds with DSA-RSP message that is finally acknowledged by DSA-ACK message transmission by Subscriber Station. This concludes network entry procedure and begins normal operation.

1.1.3. Handover Process

During normal operation, a subscriber station is associated with one base station, so called Serving Base Station (SBS). Due to degrading signal quality, unsatisfactory quality of service or forced by the network operator, subscriber station intends to migrate to another base station, called Target Base Station (TBS). IEEE 802.16e-2005 protocol provides various mechanisms that make such handover possible. To enable several handover improvement mechanisms, like Neighbor Advertisements and Network Reentry certain informations between Base Stations must be exchanged, e.g. list of neighboring base stations or details regarding subscriber that is about to change location. This task is coordinated by Access Service Network (ASN). Details of the ASN operation are discussed in [115]. Following sections discuss available mechanisms in detail. As mechanims are radically different and affect different aspects of subscriber station configuration, unified method of assessing its impact is required. A HD3 metric is used for that purspose. See Section 1.4.2 for definition of this metric.

1.1.4. Neighbor Advertisements

Serving Base Station possesses information regarding neighboring base stations. That information is provided by the network administrator. List of possible target base stations is periodically announced to

3Handover Delay. Introduction 5 the associated subscriber stations. It is important to realize that this list does not provide complete set of target base stations. Subscriber and Target Base Station might be on the opposite sides of the area covered by Serving Base Station , so communication between them might not be possible. Another important factor is a real life competition. It is a reasonable assumption that one operator will advertise only its own base stations. There might be other nearby base station operated by another service provider. Therefore the list obtained via Neighbor Advertisement should be considered as a hint or a guideline rather than as a complete list. It is important to note that neighbor advertisements are received during full communication capability. Therefore HD metric for Neighbor Advertisement equals 0 ms, so this method does not require optimization.

1.1.5. Scanning

Once Mobile Subscriber Station changes its physical location while still being within range of serving Base Station, its connection quality with serving Base Station may degrade. At the same time, it may come within range of another Base Stations, called Neighbors. Those Base Stations may be discovered through previously discussed Neighbor Advertisements or a procedure called Scanning. After receiving Neighbor Advertisement from Serving Base Station, a Subscriber Station has approxi- mated information about possible targets for handover. To verify current status of all base stations within range, subscriber station performs scanning. This procedure includes temporary disassociation with serving base station and attempt to receive transmissions from other base stations. During normal operation, due to efficiency reasons, base station uses various coding mechanisms and modulations, so called burst profiles. To successfully decode that information, DCD and DL-MAP messages must be received and decoded. However, at regular intervals base station sends information how to decode following data, using well known burst profile. This feature allows not associated subscriber stations to receive transmissions and perform signal strength measurement and quality assessment. To perform scanning, subscriber station sends SBC-REQ request to its Serving Base Station. Base Station grants requested scanning periods to Subscriber Station using SCN-RSP message and suspends support for this subscriber (i.e. does not send bandwidth grants for uplink traffic and buffers possible downlink traffic) for the time of scanning. A Subscriber Station tries to synchronize with other base stations, receive its transmissions and assess signal strength and quality. After successful reception of data from neighboring Base Station, various transmission quality metrics, like CINR, RSSI, relative delay or Round-Trip Delay are measured. After scanning procedure is complete, subscriber station may send scanning report to its Serving Base Station using SCN-REP message. Subscriber station cannot maintain communication with its corresponding nodes or its Base Station during the scanning procedure. It is the only way to fully confirm that communication with base station in question is indeed possible, so it is a critical step for handover. Duration of the scanning period is variable as scanning period length, number of iterations, as well as interval between consecutive scanning periods, are requested by the subscriber station itself. Therefore it can adjust scanning procedure parameters to the currently supported services. Also, as a Serving Base Station is aware of its neighbors, it can arrange subscriber’s scanning period to overlap with neighbor’s DCD transmission times. That may improve 6 Introduction chances of successful scanning. HD metric of this method is difficult to measure as in theory scanning periods can be arbitrary long. In practice scanning periods will seldom exceed 20 ms. If longer scanning is required, it can be split into several smaller periods. Those facts indicate that scanning does not pose significant impact on handover delays.

1.1.6. 802.16 Handover

After successful scanning, subscriber station has verified information about possible handover targets. After Subscriber Station decides that serving Base Station is no longer the best (algorithm for making handover decision is not defined by the specification and it is left up to vendors to develop it), handover procedure may be initiated. Subscriber Station informs its intent by sending MSHO-REQ message with one or more intended handover targets. Base Station may amend this list and send it back to Subscriber by using BSHO-RSP message. Optionally, Base Station can notify the Target Base Station via backbone network, so necessary preparation can be arranged in advance. Such operation, however, is outside of scope of 802.16 specification and exact handover decision algorithm was left up to hardware vendors. The exact instant of departure is chosen by Subscriber Station. The last transmitted message is a HO-IND message that indicates actual detachment and concludes handover operation at serving Base Station. Serving Base Station, after receiving such indication, frees all resources required to support leaving Subscriber Station. Subscriber station maintains full communication capability until the Handover Indication message is sent, therefore this step does not require any optimization. Subscriber Station then performs ranging and continues with network reentry at target Base Station.

1.1.7. Network reentry

After leaving Serving Base Station, the Subscriber Station adjusts its radio to receive transmissions from a Target Base Station and performs network reentry at the new location. Full network entry procedure consists of several steps. Anonymous ranging is intended for proper radio tuning. Base station sends information about quality of the received signal, so subscriber can adjust transmitting power and frequency. Anonymous ranging consists of 2 messages (CDMA code and RNG-RSP message), possibly iterated multiple times. Next step is Ranging – base station provides connection identifier for the pre- provisioned connections, specific for this particular subscriber as well as timing, power and burst profile information. Negotiate Basic Capabilities is performed to find least common denominator between subscriber and serving station supported capabilities, like ARQ support and list of supported modulations. Privacy Key Management [82] is an optional, but widely used step to provide cryptographic protection, key exchange and authentication. Registration performed afterwards specifies additional information about IP protocol version used, SS capabilities, vendor specific information etc. This is the first exchange of the signed messages, if such cryptographic protection was agreed on. Final step is to create connections by using Dynamic Service Flow procedure. If base station has information about service flows configured in previous location, it may choose to update connection identifiers, rather than recreate connections from scratch. After successful registration subscriber is logged into the network, it is able to communicate Introduction 7 only with its base station for control purposes. To send and receive data traffic, service flows must be created. Since service flows are unidirectional, so one or more uplink and downlink flows must be created (or previously existing flows must be updated). After reentry is complete, mobile subscriber may start to reconfigure network layer, i.e. IPv6.

1.2. IPv6 Overview

Next generation of IP protocol, commonly referred to as IPv6 was developed in 1996 [17]. Compared to its predecessor IPv4, it offers number of benefits. The most obvious is expanded address space – addresses are 128 bits long, compared to 32 bits in IPv4. This results in about 3.4 · 1038 addresses being potentially available, which effectively solves addresses shortage encountered in IPv4. Another benefit is stateless address autoconfiguration (SAA, [101]), which allows any IPv6 nodes connected together to communicate (e.g. in ad hoc networks). Mandatory multicast supports is another advantage of IPv6. Constant size header with simplified structure (no header checksum) eases burden on routers, allowing greater scalability. Network layer security (IPSec) is mandatory in IPv6, but optional in IPv4. Another interesting feature are jumbograms. Jumbograms are large IPv6 packets that can be up to 4GB long. In comparison, IPv4 supports only packets up to 64KB. Use of jumbograms may improve performance in networks that offer high MTU. Listed features strongly favors IPv6 as a protocol of choice for the incoming decades. Thorough discussions regarding IPv6 benefits are provided in numerous sources [85, 84, 80]. Comparison of IPv4 and IPv6 from the mobility perspective is available in [119]. Each entity that has IPv6 stack implemented is called a node. There are two types of nodes: those, which accept traffic not directed to them (called routers) and those, who don’t (called hosts). Although defined in 1996 ([17]), its rate of adoption has been somewhat slower than initially anticipated. However, there are strong indicators suggesting that massive migration to dual-stack (i.e. supporting both IPv4 and IPv6) or IPv6-only started around 2008. The most important driving force behind this is the United States’ Department of Defense (DOD). According to a DOD Memorandum dated June 9th, 2003 [57], DOD is obliged to switch its internal IT structures and all their contractors must provide all services using IPv6 by the year 2008. This forces all vendors interested in governmental orders to fulfill those requirements and provide services and hardware that is IPv6 capable. This domino effect was observed in 2008 as number of allocated IPv6 leases increased by 800% worldwide [9], compared to previous year. Currently vendors and solution providers interested in government contracts are struggling to achieve full IPv6 compliance. Although IPv6 support it advertised by numerous vendors, interoperability issues are abundant, and often there are still significant limitations present and offered solutions are immature. As this fact is brought to a broader attention, further work towards resolving existing interoperability issues is expected. Defense Information Systems Agency (DISA) created official IPv6 test certification process to verify vendor’s claims regarding IPv6 compatibility [24]. Number of high profile companies and organizations are providing support for IPv6 protocol. Microsoft Vista operating system, released in 2007, has IPv6 protocol enabled by default [69]. In January 2008, six of thirteen root DNS servers started to provide connectivity over IPv6 [33]. With this development it is 8 Introduction now possible for two Internet nodes to communicate exclusively using IPv6 only, without any assistance from the IPv4 stack. Shortly after (March 2008), Google started to provide access to its services using IPv6 [13]. Other notable examples of successful migration to IPv6 are 2008 Summer Olympic Games in Beijing, that were the first major world event that provided connectivity using IPv6 [7]. Also all network operations of the Games were conducted using IPv6 [8].

Another and perhaps even more fundamental cause of accelerating migration is uneven distribution of IPv4 addresses. Because the Internet began in the USA, most of the IPv4 user space is allocated for the USA and, to some lesser extent, Europe. From the IPv4 pool distribution, the poorest region of the world is Asia4. Rapidly developing large countries such as India or China require vast amounts of addresses, a desire that cannot be satisﬁed with depleting IPv4 pool. Therefore, the rates of adoption of IPv6 technology in several Asian countries are among the highest in the world. According to some sources [110], exhaustion of the unallocated IPv4 address pool will happen in March 2010. Although exact date is impossible to predict, human factor also has to be accounted in such predictions. When any commodity is in short supply, people tend to acquire more than is actually needed, as meeting demand in future may not be possible. Such paradox is often colloquially called self-fulﬁlling prophecy and is observed in various aspects of human society. For example, a bank run (also known as a run on the bank) is a phenomenon, when clients of a bank start to withdraw their deposits due to (possibly false) believe that bank may become insolvent. As more people withdraw their deposits, the likelihood of additional clients joining the process increases. This can destabilize the bank to the point where it faces bankruptcy. Numerous examples of such positive feedback in various disciplines are discussed in [108].

1.2.1. IPv6 addressing

Each IPv6 address is 128 bit long and is split into two parts: the first leading n bits are called prefix, while remaining 128 − n bits are called host address. Although there are no specified rules regarding n value, in most cases involving end users, an even split (n = 64) is used. That is particularly true with initial steps of node bring-up. Each node’s network interface contains fixed, globally unique layer 2 address5. In case of Ethernet, 802.11 (WiFi), Bluetooth and 802.16 (WiMAX) networks, that is a so called MAC address. This 48 bit address is extended to form a 64 bit node address (EUI-64). It is prepended with a well known (fe80::) link-local prefix. Together, they form a link-local address that can be used for communication with other nodes available on the link. Unfortunately, due to its scope limited to a single link, it is not sufficient to maintain communication on a larger distance. Therefore global address is usually required. Site local and organization scope was defined [31], but is no longer in use and is considered obsolete.

4IPv4 allocations are similarly scarce in Africa, but due to a minimal demand, that is considered smaller issue. 5That is almost always true. For rare cases, when device does not have layer 2 address, see [101]. Introduction 9

1.2.2. IPv6 reconﬁguration

When the data link layer changes a point of attachment, upper layers must also be reconfigured. In the optimistic case, when intra-domain handover takes place (i.e. handover between two base stations governed by the same operator), the network operator possesses information about the current subscriber location. It is possible to adjust routing strategies, so the subscriber will be able to send and receive IP datagrams without changing its IP address. This is only an option and even during handover between the same operators’ base stations it is not always reasonable (e.g. due to large number of subscribers and thus complicated routing table may degrade routing efficiency and manageability. Therefore operators may want to limit excessive routing modifications.) Inter-domain handover is a more difficult case than intra-domain handover. As such, research should focus on the worst case scenarios, such as inter-domain handover. When a subscriber completes network reentry, the higher layer (i.e. IPv6), must be reconfigured. According to IPv6 standards ([81], [101], [22], [49]), the following steps are necessary. After moving to its new location, the IPv6 node must obtain a new address and configure routing parameters. Stateless and usually stateful autoconfiguration are used to obtain those new parameters. In IP protocol, the address serves two goals: equipment identity (nodes are identified by their addresses) and designate location (an address determines its user’s location). Therefore a mobile node is required to inform its corresponding nodes about a new location. As important parts of this reconfiguration process were not designed with mobility in mind, they introduce significant delays. Following sections provide insight into specific elements of the reconfiguration process.

1.2.3. IPv6 interface reinitialization

According to [81], section 7.2.1: When IPv6, multicast capable interface is (re) initialized, the node must join all-nodes multicast group and solicited-node multicast address corresponding to its link-local address. Association with new Base station is considered as interface reinitialization, therefore mentioned operations must be performed. Luckily, joining multicast groups ma be carried in parallel to other operations, thus do not increase handover delay. As such, its HD metric is considered 0 ms.

1.2.4. Automatic conﬁguration in IPv6

There are two ways of acquiring global IPv6 addresses. The first is through Router Advertisement messages mechanism. Routers periodically announce list of networks and routes that are available through it. RA transmission can be also initiated by explicit request. Any node is allowed to send Router Solicitation message for that purpose. RA can also announce one or more prefixes that are available locally. Such local prefixes can be autonomous, i.e. hosts are allowed to generate global addresses by using announced prefix and their host addresses. Generated address is a fully operational global address. Those two elements of automatic configuration (link-local addresses generation and Router Advertisement messages) are commonly referred to as Stateless Autoconfiguration (or SAA). Reader is encouraged to get acquainted with [101] for further studies regarding this topic. 10 Introduction

1.2.5. Router Discovery

Routing configuration in IPv6 networks is performed using stateless autoconfiguration mechanism called Router Advertisements [101]. Router periodically announces advertisements describing which prefixes are available directly on the link and which prefixes are reachable via router. Those advertisements might also be requested by nodes, which are not willing to wait for the next unsolicited announcement. Although this procedure can be executed quickly and with successful results, its main disadvantage is that no other configuration parameters, except routing, might be obtained by those means. This includes lack of basic parameters like DNS server addresses, domain name, VoIP configuration and other. Necessity to transmit extra message and wait for response introduces additional delay every time subscriber moves to a new location. Its duration depends on how fast base station is able to grant requested bandwidth and how fast router is able to send response. HD metric is estimated to be within 40 ms range.

1.2.6. DHCPv6

Second way of acquiring global IPv6 address is by means of Dynamic Host Configuration Protocol for IPv6 [22], commonly abbreviated as DHCPv6. Once node initializes its IPv6 stack it may choose6 to obtain its configuration parameters from DHCPv6. Contrary to previous method, all granted parameters, especially addresses, delegated prefixes, assigned fully qualified domain names, and temporary addresses, may be variable in time, and its state is closely monitored. Hence the DHCPv6 configuration is called Stateful autoconfiguration. Once IPv6 node initializes its IPv6 stack, first Solicit message is transmitted. To avoid network congestion after power black-out, this first transmission should be delayed by a random amount of time from 0 to 1 second. This message is sent to a well-known multicast address that all servers and relays must listen to. It contains list of requested options. Proposed values may be also specified as hints, regarding client’s preferences. As DHCPv6 protocol allows for multiple servers to be present and active on a single link, client expects to receive one or more Advertise messages, each with set of proposed options, addresses and prefixes. All available servers respond with advertisements containing their proposed addresses and configuration parameters. As specified in [22], client waits 1 second to allow all servers to generate and send answers. Options specified in Advertise message are not granted, but rather provided as advertisements. Once client chooses server that suits best its needs, it asks for actual assignment, by sending Request message. This message is also sent to the same multicast address as before, but also contains unique server identifier (Server DUID). Such message is ignored by all, but one server. This chosen server grants requested options and performs additional actions, if necessary (e.g. communicate with DNS server for Dynamic DNS Update purposes). Assigned parameters are sent in Reply message. This concludes configuration from the DHCPv6 perspective. Clearly, HD metric of the basic DHCP configuration is over 1000 ms, so this is a major area for possible improvement. There is also special message that node should send, once it reattaches to a network interface (after

6 Although Router Advertisement messages contain information, if stateful autoconfiguration should be performed or not, it is a common practice to ignore those notifications and use configuration method specified by system administrator. Introduction 11 reassociation with wireless access point/base station or replugging cable in a fixed network). Its intended purpose is to confirm that used parameters are still valid in that location, regardless if this is the same location as before losing connectivity. Client sends Confirm message with all assigned addresses, prefixes and configuration parameters. Server responds with a Reply message if certain conditions are met. Unfor- tunately, to do so, server must be able to authoritatively tell that all addresses sent by client are or are not valid. In for some reason (e.g. receiving unknown address) server is unable to perform this verification on all addresses, it must not send a Reply message. As a result, if client is notified that one of its addresses is not appropriate for current link, it must restart configuration procedure from the beginning. As this confirmation step has no guarantee to be concluded in a timely fashion, it appears reasonable to skip it altogether, discard old and obtain new address, without any unnecessary delays. Properly configured server will assign the same address as it is still maintaining addresses bound for that particular client. There are other mechanisms available in the DHCPv6 protocol that are not interesting from the mobility perspective. Assigned parameters must be periodically renewed (using Renew message). This mechanism allows clients to verify that their controlling server is still operational. On the other hand, server maintains information regarding its client’s reachability. Should the communication with current server be lost, clients try to switch to any other available servers using Rebind message. Another mechanism available is a notification sent to the server that assigned address is duplicated. Decline message is used for that purpose. For the completeness of DHCPv6 overview, it should also be noted that that there is a special mode of operation, when only host independent parameters are assigned (i.e. parameters that are the same for all nodes, e.g. DNS server address). This mode is called stateless DHCPv6. Although final version of DHCPv6 specification was published in 2003, there is extensive work being conducted regarding extensions and additions. To date of publication of this dissertation, over 20 extensions were accepted or being worked on. This work is focused around DHC group of Internet Engineering Task Force [19]. For additional sources regarding DHCPv6, reader is encouraged to familiarize with [74, 73, 80, 77].

1.2.7. Duplicate Address Detection

Regardless of its origin, for each new obtained address there is a procedure that verifies its uniqueness. It is called Duplicate Address Detection. Node sends Neighbor Solicitation message to a multicast group that is generated from the address in question. If there are any other nodes that use that address, they will receive this message and respond with Neighbor Advertisement message. From the mobility perspective it is crucial to note that wait for such unlikely responses should take at least 1 second (or more, if repeated transmissions are defined for a given interface type). For details regarding DAD operation, see [81, 101]. For message structures and details of operation, regarding IPv6, Neighbor Discovery, Stateless Autoconfiguration, Addressing architecture and related topics, see [98, 99]. This procedure is mandatory for all IPv6 nodes starting to use new address and affects both stateful or stateless autoconfigurations. When handover is completed, a node must initiate DAD procedure, which introduces another 1000 ms delay. Again, HD metric is over 1000 ms. It should be noted that address duplications are extremely rare, so this delay is an excellent candidate for improvement. 12 Introduction

1.2.8. Mobile IPv6 Overview

Mobile IPv6 [49] is a protocol, which allows nodes to remain reachable while moving around in the IPv6 Internet. It assumes that Mobile Node (often abbreviated as MN) is identified by its home address, regardless of its current location. While mobile node remains at its home location, it communicates as any ordinary node. However, once it relocates to a different location, its communication changes. Additional entity called Home Agent intervenes in such case. It intercepts incoming traffic, encapsulates and redirects it to current Mobile Node location. Also, responses from Mobile Node to Correspondent Node are not sent directly, but rather tunneled through Home Agent. Thanks to this approach, packets are always topologically correct. Every time Mobile Node changes its location, it must inform its Home Agent about its current location to its Home Agent. That is achieved by sending Binding Update message. Home Agent responds with Binding Acknowledgement. To prove to the Correspondent Node or a Home Agent that new address indeed belongs to Mobile Node, a set of tests is conducted. It is commonly referred to as Return Routability Procedure. That communication mode is not optimal, however. If Correspondent Node is Mobile IPv6 aware, then better operation is available. After location change, Mobile Node informs not only its Home Agent, but also its Correspondent Node. Update procedure is performed in the same way as with Home Agent. Mobile IPv6 protocol specifies also tunneling mode for communication, remote detection if Correspondent Node is Mobile IPv6 aware or not, cryptographic protection, extra IPv6 header and additional options for conveying mobility related parameters via Router Advertisement messages. It is somewhat interesting to note that in specification, mobile entity is called Mobile Node, not Mobile Host, indicating that mobility is expected to soon cover also mobile networks, when mobile device will be a router, not a host. Indeed, network mobility standardization was a goal of IETF group called NEMO (short for Network Mobility). Base framework for that protocol has reached RFC phase recently [18]. For in depth analysis of Mobile IPv6 comparison to other mobility protocols, see [119]. Although Binding Update procedure consists of exchange of only two messages, they are not exchanged locally, but rather between two distant nodes, located in different networks. Assuming that a message processing time is very small (thus can be neglected), this procedure takes full round trip time from the current mobile node location to its corresponding node or a home agent. This step concludes reconfiguration. After its completion, mobile node regains communication capabilities and normal operation may be resumed. This might be one of the longest steps in the whole handover process, described in the last two sections.

1.3. Mobile WiMAX/IPv6 convegence

First commercial solutions supporting mobility appeared in 2008 and are already deployed7. Also, mobile devices supporting WiMAX became available in 2009. Nokia N810 WiMAX Edition is a notable example [83]. Currently IEEE 802.16 based network solutions are rapidly gaining acceptance, both in

7Cities of Amsterdam,Netherlands and Boston,USA offered WiMAX services first. Currently there are over 500 WiMAX networks deployed througout the world. Introduction 13 academic and telecommunication sectors. Most of the already deployed solutions are fixed, but road-maps of major telecommunication corporations indicate that mobile versions will be commercially available in a very near future [100], [113]. According to WiMAX Forum [114], as of October 2009, there are 502 WiMAX deployments in 145 countries. Support is provided by number of large vendors and operators, like Alcatel-Lucent, Alvarion, Comcast, Cisco, Huawei, Intel, Motorola, NEC, Nokia, Samsung, Siemens and many more [30]. It appears reasonable to assume that a significant part of all mobile WiMAX stations in a near future will be dual-stack or even IPv6 only. Therefore author chose IEEE 802.16-2005 as a PHY/MAC layer and IPv6 as a network layer for the research environment. The choice of IPv6 has an interesting aspect, in that IPv6 provides extensive automatic configuration mechanisms, including stateless (i.e. Router Ad- vertisements, [81]) and stateful (dynamic host configuration protocol – DHCPv6, [22]) autoconfiguration, Duplicate Address Detection ([101]), and Mobile IPv6 ([49]).

1.3.1. Multi-layer handover procedure

Different network layers will produce dramatically different delays during handover. The PHY and MAC layers of the WiMAX stack have been developed with mobility support and fast processing in mind. Therefore delays introduced are considered small (reaching a few hundred milliseconds range, usually slightly above 100 ms). Unfortunately, IPv6 protocols family was not designed in this manner. Several steps introduce delays that are very large from the mobility point of view (in the order of one second or more). For example, the DHCPv6 server discovery phase takes exactly one second as clients are required to wait for possible responses from other servers, even when one or more servers have already responded (according to DHCPv6 specification,[22]).

1.4. Thesis

It is essential to realize that not all handover steps are causing handover delays. From the user’s perspective, only lack of communication capability periods are troublesome. Therefore all research presented in this dissertation is focused on minimizing or even eliminating such periods completely. Based on the intended goal of this work, the main thesis can be defined as follows: IPv6 reconfiguration process during handovers in 802.16 networks is not optimal and it is possible to achieve improved handover efficiency by IPv6, DHCPv6 and Mobile IPv6 protocols modifications. To prove this thesis, number of research goals were defined. Also, to measure impact of diverse algorithms in a uniform way, a new metric has been defined for assessment purposes.

1.4.1. Research goals

Research goals of this dissertation can be deﬁned as follows:

• Identify major causes of handover delays in the 802.16/IPv6 environment – every part of the handover has to studied, understood and analyzed. 14 Introduction

• Review all and select most delay inducing procedures – every used procedure, its potential for improvement and impact on the overall handover procedure has to be assessed.

• Propose improvements in selected methods – proposed amendments or enhancements for those handover procedures that were deemed suitable for improvement.

• Verify usefulness of proposed procedures – new proposal must be rigorously validated, before any claims regarding its usefulness are made.

Fulﬁlling all mentioned research goal will prove the thesis deﬁned in Section 1.4.

1.4.2. Handover Delay metric

Full scale handover process, described above, is long and complicated. During certain steps, like scanning or IPv6 autoconfiguration, a subscriber station is unable to maintain communication. Since various real time transfers, e.g., multimedia transmissions are one of major applications foreseen for WiMAX, interruptions in communication are highly problematic. For various services, like videoconferences or voice connections, such communication gaps are considered by end users as unacceptable and leading to a subjective perception of a poor service. To some lesser extent, this disadvantage also affects video on demand streaming. Packet drops and delays in this case can easily be counteracted by buffering more data. In interactive multimedia scenarios (e.g. VoIP), this issue may not be overcome by extensive buffering. Adding extra delay is not desired as it may be perceived as further service quality degradation by end users. Actions or procedures are identified, which can be characterized by the following features:

Blocking property – during such an action communication with corresponding nodes is not possible;

Action necessity – means that this action cannot be omitted without severely degrading or rendering impossible the whole handover process;

Action is time consuming – a considered action introduces signiﬁcant gaps – idle intervals between communication opportunities.

To conveniently assess and compare radically diﬀerent handover phases, new metric called Handover Impact is proposed. It is expressed in milliseconds and speciﬁes how long mobile IPv6 station does not have full communication capability due to the analyzed method. X expresses metric value, while HD() stands for its symbolic designation. HD is expressed in millisecond units.

X = HD(step)[ms] (1.1) In general, lower scored methods are considered “better”, because they introduce smaller latency. If a method allows IPv6 node to communicate immediately, with no delay at all, its HD value is equal to 0 ms, thus it does not hinder communication in any way, so – assuming no other dependencies – it does not require any optimizations or improvements. Handover Latency would be a better term to describe this property as during handover packets (or traﬃc in general) are not delayed. However, this metric is more often referred to using its colloquial name – Handover Delay [78]. Introduction 15

1.5. Terminology notice

Several terms are sometimes used interchangeably as one device often performs several functions simultaneously. Depending on which functionality is relevant in a given context, a laptop with WiMAX interface can be referred to as Subscriber Station, IPv6 node, DHCPv6 client or Mobile Node. Base station is an IPv6 router. It also provides DHCPv6 server functionality, IPv6 routing capability and may also serve as Home Agent and/or DHCPv6 Relay. 16 Introduction 2. Related work

Following chapter presents general mobility research status, works in progress and selected proposals. WiMAX Forum organization and its main groups are mentioned. IETF groups are brieﬂy presented and selected standards – Mobile IPv6 (MIP6), Fast Handovers for Mobile IPv6 (FMIP6), Hierarchical Mobile IPv6 (HMIP6), several other enhancements and Optimistic DAD and mobility related aspects of DHCPv6 protocol. Work conducted under the auspices of IEEE is also presented: Mobile WiMAX (802.16-2005) and Media Independent Handover (802.21). Review of several independent proposals concludes this chapter.

There are numerous solutions and proposals in the area of handover optimization. In the following sections, more important, interesting or promising examples are brieﬂy presented. Important aspect of the Mobile IPv6 protocol is route optimization. There are several works dedicated to this feature. Taxonomy and analysis of available and proposed route optimizations in IPv6 can be found in [106].

2.1. WiMAX Forum

WiMAX Forum is a non-profit ogranization formed to certify and promote the compatibility and interoperability of broadband wireless products based upon IEEE 802.16 standard. WiMAX Forum’s goal is to accelerate introduction of WiMAX based systems to market. To achieve highest possible interoperability, WiMAX Forum works closely with service providers, hardware vendors and regulators [114]. Several hundred companies and government regulators are members of the WiMAX Forum. Notable examples are Alcatel-Lucent, Alvarion, British Telecom, Cisco System, Fujitsu, Intel Corporation, Motorola, Nokia, Samsung and others. Working within WiMAX Forum is split between several working groups. The most important are Certification Working Group (dedicated to standarization of the certification process), Marketing Working Group (working on improving WiMAX related technologies visibility), Technical Working Group (develops technical specifications for the WiMAX Forum Certification program which enable interoperability and conformance testing of products based on the IEEE 802.16 OFDMA MAC/PHY as driven by WiMAX Forum SPWG requirements, [117]), Network Working Group (creates end-to-end networking specifications for fixed, nomadic, portable and mobile WiMAX systems, beyond what is defined in the scope of IEEE* 802.16, [118]) and several smaller groups. 18 Related work

2.2. IETF working groups

IP mobility is considered by Internet Engineering Task Force (IETF) one of the more important topics. Most RFC documents and drafts related to mobility were created as a work conducted in the following groups. There are several working groups dedicated to various aspects of handover and mobility in general. As of July 2009, there are 118 IETF working groups. Notable groups related to mobility are:

• MIP4 working group is focused in Mobile IPv4, its further standardization, MIB database deﬁni- tions, interactions in VPN scenarios, back porting Fast Handovers from Mobile IPv6 to Mobile IPv4 and others. As its work is focused solely on IPv4, work results from that group are outside of scope for this dissertation.

• Mobile IP Performance, Signaling and Handoﬀ Optimization (mipshop), working group designed two notable protocols: Fast Handover in Mobile IPv6 and Hierarchical Mobile IPv6. The group “will continue to work on HMIPv6 and FMIPv6, and the necessary extension to improve these protocols” [71]. Another goal of this group is to deﬁne delivery of information for 802.21 MIH services.

• DNA group (Detecting Network Attachment), was created to develop mechanisms that reduce or avoid delays associated with Router Discovery and Duplicate Address Detection, in cases where they are not necessary. According to [20] “When an IPv6 node detects or suspects that its underlying link layer (L2) connectivity has or may have undergone a change, it needs to check whether its IP layer (L3) addressing and routing conﬁguration are still valid or have changed. In case that the L3 connectivity has changed, the node needs to reconﬁgure and may need to initiate mobility procedures, such as sending Mobile IP binding updates.

• Mobility Extensions for IPv6 (mext) working group is another entity created to design mobility related extensions. The primary goal of MEXT is to enhance base IPv6 mobility by continuing work on developments that are required for wide-scale deployments and specific deployment scenarios. Additionally, the working group will ensure that any issues identified by implementation and interoperability experience are addressed, and that the base specifications are maintained. The group will also produce informational documentation, such as design rationale documents of description of specific issues within the protocol. All materials developed within this group are available in [68].

2.3. Mobile IPv6

Mobile IPv6 protocol was designed under the auspices of (not existing anymore) mobileip working group. Although the initial work started in January 1996, oﬃcial speciﬁcation was not published until July 2003 [49]. Being widely accepted as the only reasonable mobility solution for IPv6, it serves as a foundation for number of extensions [96, 56, 90,4]. Basic operations of this protocol were described in Section 1.2.8 of this dissertation. Default Mobile IPv6 is used in all scenarios analyzed in this dissertation, with the exception of cases, where Remote Binding Update proposal is used. Remote Binding Update is discussed in Section 3.2.6. Related work 19

2.4. Fast Handovers for Mobile IPv6

As Mobile IPv6 is considered the only reasonable way of providing mobility support in IPv6 networks, intense research was dedicated to its enhancement and improvements in various dedicated scenarios. One of the most notable examples of such works is Fast Handovers for Mobile IPv6 (FMIPv6) proposal, that was accepted and published recently as RFC 5568 [56]. Intent of this proposal is to improve handover latency due to Mobile IPv6 procedures. This standard introduces number of new participants to the mobility environment: Previous Access Router (PAR) and New Access Router (NAR) are Access Routers that are present in previous and new locations, respectively. After Mobile Node obtains information about its prospective target location, using link-layer mechanisms (like scanning in 802.16 networks or “scan” in 802.11, as suggested by author of Fast Handovers proposal), it sends this list to PAR using new message called Proxy Router Advertisement (or RtSolPr). Returned list with resolved access point identifiers to subnet-specific information is sent in Proxy Router Advertisement (or PrRtAdv). Based on that information, Mobile Node generates New Care- of Address to be used at new location. Before Mobile Node detaches from previous link, Fast Binding Update (FBU ) message that contains NCoA is transmitted to PAR. PAR then sends Handover Initiate (HI ) message to NAR. NAR responds with Handover Acknowledge (HAck). As a result, PAR sends Fast Binding Acknowledgement (FBack to Mobile Node. PAR and NAR also configure tunnel linking each other. It will be used to forward traffic from old to new location. Also, if Mobile Node will not report immediately after arriving at its new location, incoming traffic will be buffered by NAR. Depending on whether FBack is received on previous link, there are two possible modes of operation:

Predictive – Mobile Node receives FBack on the previous link. That indicated that packet tunneling is already in progress by the time Mobile Node handovers to new location. Mobile Node should send Unsolicited Neighbor Advertisement (UNA) immediately after attaching to new location to announce its arrival, so buﬀered and arriving packets will reach it immediately.

Reactive – Mobile Node did not receive FBack on the previous link (because it didn’t sent FBU or left link before reply was received). Mobile node sends FBU immediately after sending UNA to PAR to conﬁrm its new location.

This proposal introduces two new entities: Previous Access Router and New Access Routers, with functionality somewhat similar to Foreign Agents from Mobile IPv4. Although this approach limits amount of data to be lost during each handover, it imposes number of severe drawbacks. The most important is the requirement to deploy mobility aware agents (modified Access Routers) in every visited network. By doing so, one of the biggest benefits of Mobile IPv6 (compared to Mobile IPv4) is forfeited. This aspect of not requiring any support from visited network has huge impact on scalability and deployment prospects. To implement Mobile IPv6, one has to deploy it only in its home network (1 network). To implement any scenario that involves foreign agents (Mobile IPv4 or Fast Handovers in Mobile IPv6), one has to modify its home network and all networks to be visited (possibly hundreds of networks). Another significant flaw is a requirement for Access Routers to not only handle additional signaling 20 Related work traffic, but also forward and buffer incoming traffic. Traffic buffering requirement poses significant burden to router. This also excludes less powerful hardware from being usable. As majority of WLAN access points (major applicability scenario envisaged by author of Fast Handovers proposal) are indeed not very powerful and have only limited amount of memory, its applicability for this protocol is very doubtful. There are also other problematic aspects. As pointed out by the author itself, NAR may allocate different NCoA address than generated by Mobile Node. Special Router Advertisement with Neighbor Ad- vertisement Acknowledge option is sent to indicate new address. Said approach to address management is a deviation from clearly distinguishing between stateless and stateful automatic configuration mechanisms in IPv6 (router partially takes role of a DHCPv6 server). Proposed changes offer decreased handover latency at a cost of deployment of complicated infrastructure. Tunneling between old and new locations is an interesting idea, but after long discussion (24 revisions before Mobile IPv6 draft was published as a standard) the concept of foreign agents was removed from Mobile IPv6. Is should also be noted that stateful configuration is not supported in Fast Handovers and new mechanism is introduced to override standard behavior.

2.5. Hierarchical MIPv6

Hierachical Mobile IPv6 (HMIPv6) [96] is a recent (October 2008) standard that introduces extensions to Mobile IPv6 and IPv6 Neighbour Discovery to allow local mobility handling. Hierarchical mobility management for Mobile IPv6 is designed to reduce the amount of signaling between the mobile node, its correspondent nodes, and its home agent. New entity, Mobility Anchor Point (MAP), is used during intra-domain handovers. It can also be used to improve the performance of Mobile IPv6 in terms of handover speed. Concept of a hierarchical Mobile IPv6 network that utilizes MAP, is introduced. Once Mobile Node reaches its new location, it creates two care-of addresses. First is the address obtained in the “regular” way (called Local Care-of Address, LCoA), while the second (Regional Care-of Address, RCoA) is generated from MAP’s advertisements. While entering new domain, Mobile Node performs one extra Binding Update – between its LCoA and MAP. After that update is complete, Home Agent and Correspondent Nodes are updated with RCoA, instead of LCoA. Once Mobile Node changes its point of attachment within the same domain, it needs to perform Binding Update to MAP that is usually much faster than update to Home Agent and Correspondent Nodes (MAP and MN are in the same network). Interesting to note is that – somewhat contrary to its name – it is explicitly forbidden to use one RCoA address as a care-of address for update sent to another MAP. This form of multi-level hierarchy is not allowed as it would cause packets to be encapsulated several times, degrading protocol’s performance and efficiency. Proposed enhancement offers several benefits. It shortens Binding Update procedure in intra-domain cases. Also Correspondent Nodes and Home Agent are not informed about exact MN location, which may be considered significant benefit for privacy conscious users. Also, Mobile Node doesn’t need permanent home address or home agent in order to be HMIPv6-aware. There are several other, smaller advantages. Mobile Node may send data packets via its Home Agent immediately after sending Binding Update. Related work 21

Unfortunately, Home Agent will not be able to route traffic back to the Mobile Node before it receives the Binding Update. On the other hand, HMIPv6 introduces several drawbacks. It requires deploying MAPs in all networks that are to provide HMIPv6 support. Deploying single MAP in a domain may easily prove to be a bottleneck of this new solution, as MAP is required to not only maintain information regarding all visitors, but also forward all their incoming and outgoing traffic. Although there is a possibility to deploy more than one MAP in a domain, additional MAPs introduce new problems. MN has to choose one of several available MAPs, but algorithm for such selection is not defined. Also, requirement for Mobile Node managing another address that is restricted in some cases (it is not allowed to use RCoA to communicate with Correspondent Nodes within the same domain), requires modification of the source address selection algorithm. Another aspect is a trade-off between handover speed and overall throughput. As authors themselves admit, if the traffic is sent through Home Agent, data exchanged between MAP and Mobile Node is encapsulated twice, which reduces usable throughput. It also affects MTU of transmitted and received packets, so proper operation of Path MTU Discovery [67] is required. HMIPv6 offers interesting approach to mobility, but its usefulness deeply depends on the size of a domain and the speed of a Mobile Node. Distinction between macro and micro-mobility offers much better support for intradomain movement. Unfortunately, the cost is quite high. It is worth noting that mipshop working group continues its endavours to further improve HMIPv6. As such, it may become very valuable extension of a basic Mobile IPv6 protocol. It should also be noted that from the perspective of this dissertation – focusing on inter-domain handovers – HMIPv6 does not offer any benefits.

2.6. Route Optimization in Mobile IPv6 using Static Shared Key

A Mobile Node and a Correspondent Node may preconfigure data that is useful for computing Binding Management Key in advance, that can be used for authorizing Binding Updates, as proposed in [90]. The idea is useful when Correspondent Node and Mobile Node are managed by the same organization or have otherwise established out of band communication channels. Binding Management Key may be then used for authorizing management messages, especially Binding Update and Binding Acknowledgment messages. This very straight-forward proposal is very useful in cases, where its usage is applicable, i.e. when both nodes have established relation or preconfigured common data in some way. Not requiring usage of Return Routability Procedure offers important handover latency decrease. Unfortunately, the requirement for providing both nodes with preconfigured data greatly limits scope of applicability of this proposal.

2.7. Enhanced Route Optimization for MIPv6

Route optimization techniques defined in MIPv6 [49] are perceived as not completely efficient. They enable mobile and correspondent nodes to communicate via direct routing path, despite changes of point of attachment by the mobile node. Both nodes use mobile node’s home address for mobile node identification. As node changes its location, also its care-of address changes. After each change, mobile node performs 22 Related work

Binding Update procedure. To verify that Binding Update is indeed performed by mobile node and not an impostor, two tests are performed (“home address test” and “care-off address test”, commonly referred together to as “return routability procedure”). These tests allow the correspondent node to verify mobile node’s reachability at the home and care-of addresses, thus proving that home address and the care-of address binding is legitimate. As pointed out in [4], the advantage of the return routability procedure is that it is light-weight and does not require any extra dependencies, like public-key infrastructure on preexisting relationship between the mobile node and the correspondent node (e.g. a shared secret). On the other hand, the procedure has significant negative impact on handover latency, since both tests consist of an end-to-end message exchange between the mobile node and the correspondent node. Also, during home address test, home agent is involved, which further increases delays. As such, several route optimization techniques were proposed. [106] provides taxonomy and analysis of available and proposed route optimizations in IPv6. To minimize impact of return routability procedure and also increase cryptographic protection, Akko, Vogh and Haddad proposed Enhanced Route Optimization for MIPv6 [4]. Enhanced Router Optimization secures a mobile node’s home address against impersonation through an interface identifier that is cryptographically and verifiably bound to the public component of the mobile nodes’ public/private-key pair. There is only one test required validates the home address prefix and subsequent home address tests are unnecessary. Enhanced Route Optimization takes advantage of Cryptographically Generated Addresses (CGA), defined in [5]. It provides strong, cryptographic binding between its interface identifier and the CGA owner’s public key. This facilitates lower handoff delays, longer binding lifetimes, as well as reduced signaling overhead for mobile nodes that temporarily do not move. Enhanced Route Optimization proposal also introduces Concurrent Care-of Address tests. Mobile node is allowed to perform Binding Update to a new Care-of Address, without providing a proof of reachability at that new location. Correspondent node registers the new address on a tentative basis and sets it to unverified state. Data packets can then be sent and received from this new address. In parallel, reachability verification continues until address is verified. Practical usefulness of this proposal is unclear. Although its principles are valid, this feature is not commonly used. The requirement to support CGA appears to be one of the main causes.

2.8. Mobility support in DHCPv6

DHCPv6 protocol [22] was designed as a general protocol for automatic configuration of IPv6 nodes. As almost all of its timers are specified in seconds, it is not uncommon to observe DHCPv6 events happening within minutes or even hours. As such, this protocol may be considered slow paced. There is one mechanism defined that aids mobility scenarios – a Confirm message. Client is expected to send this message once it detects reattachment to a link. The idea is to confirm, if leased addresses and other configuration options are valid in current location or not. However, DHCPv6 allows multiple servers to be present on link. Therefore server can definitely answer if parameters in question are valid or not only if it is authoritative. This leads to the uncertainty. In some cases server may not send answer at all. Related work 23

Once client does not get answer after 1 second, it may retransmit the message. This leads to potentially huge delays that are unwanted in real-time or time sensitive applications. Therefore Confirm mechanism, although useful in cases, where fast reconfiguration is not needed, is not suitable for scenarios analyzed in this dissertation. There is another aspect of DHCPv6 protocol that favors mobility. Instead of usual 4 message exchange (Solicit, Advertise, Request, Reply), Rapid-commit option allows much faster exchange. If supported by both server and client, it is possible to conclude stateful autoconfiguration using only 2 messages: Solicit is replied directly with Reply. Another useful feature is server discovery phase. Once client sends Solicit message, it is expected to wait 1000ms for Advertise messages coming in from available servers. This waiting phase may be prematurely finished, when Advertise with maximum value (255) was received. Both configuration modes are well known, but they are not dealing with the issue of configuring new address on the interface. Duplicate Address Detection procedure is still required.

2.9. Optimistic DAD

Optimistic Duplicate Address Detection [72] (Optimistic DAD) is a modification of Neighbor Discovery [81] and Stateless Autoconfiguration [101] processes. Its main purpose is to minimize address configuration delays in the successful case, and to reduce disruption as far as possible in the failure case. As pointed out by its author, Optimistic DAD “is a useful optimization because in most cases DAD is far more likely to succeed than fail. The existing IPv6 address configuration mechanisms provide adequate collision detection mechanisms for the fixed hosts they were designed for. However, a growing population of nodes needs to maintain continuous network access despite frequently changing their network attachment. Optimizations to the DAD process are required to provide these nodes with sufficiently fast address configuration.” A new address state – Optimistic – is introduced. It may be considered a mixture of Tentative and Deprecated states. Newly obtained address is assigned in optimistic state. This address cannot be used for sending Neighbor Solicitation or Router Solicitation messages. This seriously limits Optimistic Node (i.e. Node that supports Optimistic DAD) capability for communicating with its neighbors in a regular way (i.e. discovering them using Neighbor Discovery mechanism). Optimistic node sends packets to its default router instead. Router is expected to respond with standard ICMP Redirect message that contains all necessary information for direct communication. Authors provide interesting analysis of necessary conditions for DAD procedure to fail, using Birthday Paradox. Even using randomly generated host addresses, the probability of collision in 500 node network is 5.4e − 14. For theoretical network consisting of 500.000 nodes the probability raises to 5.4e − 08, which is still extremely unlikely to happen. Also, it should be noted that host addresses are usually generated from unique L2 addresses, which in turn are expected to be unique. For 802 network family hardware, each is assigned one or more 3 octet identifier that is supposed to be appended with 3 octets of unique values. The general observation is that this approach offers unique L2 addresses in a global scale, except rare cases when low-end vendors try to further limit its manufacturing costs and mass producing multiple network cards with the same address. 24 Related work

Optimistic DAD assumes that address duplication is very unlikely. As such, beneﬁts of DAD speed up outweigh the cost of failed cases, i.e. when address is detected to indeed be duplicated. That is a reasonable assumption and as such, the proposal may be used in various scenarios. There are, however, several aspects that may hinder its deployment and usefulness. As pointed out in [72], Section 2.4, a node with only Optimistic Address is unable to determine router’s Link-Layer Address. In such case, Optimistic Node will not be able to communicate with the router until at least one of its addresses is no longer optimistic (i.e. classic DAD procedure is completed). Also, in a negative case, when address is proven to be duplicated, consequences are quite severe. While optimistic DAD still taking place, Mobile Node is allowed to use its new optimistic address, e.g. to send Binding Update. This may lead to broken connections, as Correspondent Nodes and Home Agent will send data that will be received by the actual owner of the address in question, rather than Mobile Node. This unknowing node will not recognize incoming packets and will either drop them (e.g. UDP packets) or close connection (e.g. RST packet in TCP connections).

2.10. IEEE 802.21

In recent years multi-technology enabled terminals have become available. It is often beneficial to switch between different types of access networks, depending on various conditions. Such possible switch introduces number of new challenges. At the same time, each network type offers its own unique handover technique, which further complicates overall handover process. New IEEE working group was created to address those challenges. Developed solution was designated as IEEE 802.21 and named Media Indepen- dent Handover services [44]. Handovers are distinguished depending on the ability to connect at both old and new locations. Sce- narios that allow connectivity at new location before losing connectivity at old location are called make- before-break. If mobile entity is not able to do such thing, break-before-make scenario is used instead. That is the case with classical handover in 802.16 networks. The main purpose of IEEE 802.21 is to enable handovers between heterogeneous technologies (including IEEE 802 family and cellular) without service interruption, hence improving the user experience of mobile terminals. It also provides a framework split into several services that may be used to communicate between layers, usually layer 2 and 3 of ISO/OSI reference model. Event Service may be used to notify that various events occurred., e.g. link up event may lead up to IPv6 configuration initiation. Command Service offers a way to perform certain tasks, e.g. initiate handover. Information Service provides additional information useful from the handover perspective, e.g. list of available networks or network operator. Those services may also be used by higher layers, e.g. in handover-aware applications. This protocol introduces extra abstraction layer, but benefits from doing so greatly outweigh the costs. Although intended purpose of those mechanisms are vertical handovers (i.e. between different radio access technologies), they may still be beneficial in horizontal handovers (between different networks of the same type). As such, selected mechanisms from the 802.21 standard were used in the simulation environment. One notable example is an event mechanism that was used to synchronize operations between 802.16 and Related work 25

IPv6. For a discussion on simulation environment, see 4.1.2. Overview of the 802.21 is presented in [88].

2.11. IEEE 802.16e (Mobile WiMAX)

Mobile WiMAX standard oﬀers number of optimizations that may be exploited, assuming certain conditions are met. Therefore full procedure as described in 1.1.2 is usually performed only once, during ﬁrst network entry. Further reentries are less time consuming. Exact duration of the reentry process is considered one of the more important parameters of a base station and it is highly dependant on the amount of information about subscriber that base station has before actual reentry takes place. Conservative estimation may be that HD metric is in high hundreds for this, but there are solutions with HD less than 100 ms known to exist. Further optimizations require detailed analysis of the medium access mechanisms and are outside of the scope of this paper. As those mechanisms are core of the 802.16 standard, they are directly applicable to analyzed scenarios. As such, they were used during most experiments. See 4.5.2 for details regarding used 802.16 optimizations.

2.12. 802.16 extensions

Official mobile WiMAX (802.16e-2005, [36]) specification was published in early 2006. It did not conclude works focused on 802.16, but offered a “reference snapshot” of current work. It also serves as a base for a number of proposals and future works. Notable examples developed under auspices of IEEE working groups are Corrigendum 1 and 2 (an errata and minor improvements), 802.16f-2005 (Management Information Base, [37]), 802.16k-2007 (a specification defining bridging 802.16 networks, [42]), 802.16g- 2007 (Management Plane Procedures and Services, [38]), 802.16i (Mobile Management Information Base, [39]), 802.16j (Multihop relay, [40]), 802.16h (Coexistence Mechanisms for license-exempt Operation, [41]) and 802.16m (Advanced Air Interface with data rates of 100Mbps mobile and 1 Gbps fixed [43]). It is also worth noting that updated 802.16 specification containing 802.16e-2005, updated with Corrigendum 1, 2, 802.16f, 802.16g and P802.16i, was published as united specification 802.16-2009 [35].

2.13. Independent proposals

802.16 working group of IEEE is actively developing numerous extensions to the 802.16 protocol, as mentioned in the previous section. At the same time, number of independent proposals was published. Following sections provide brief review of selected independent publications.

2.13.1. An Improved FHMIPv6 Handover for Mobile WiMAX

Jinsha, Cui and Zhixiong proposed an improved FHMIPv6 Handover Scheme for Mobile WiMAX [47]. The proposal assumes MAP (introduced in HMIPv6) and NAR/PAR (introduced in FMIPv6, [56]) deployment in a WiMAX network. Authors also suggest using MIH ([44]) for inter-layer communication during preparation and handover. It provides an interesting approach to MIPv6 deployment – including 26 Related work two optimizations – in the mobile WiMAX network. It does not, however, touch any topics related to stateful autoconﬁguration. Although being informative, this paper is useful for educational purposes, but lacks any new proposals.

2.13.2. New Handover Mechanism for 802.16e Networks

Although 802.16e defines framework for all mobility related operations, like scanning, ranging, handover and network reentry, it does not specify exact algorithms and procedures of the full handover procedure itself, leaving this up to the vendors. Fattah and Alnuweiri [26] describe classic handover procedure, with minor proposed improvements. Neighbor Advertisement messages are extended with new option conveying information regarding supported traffic types. Handover decision is based, among others, on a supported traffic type at potential destinations. Although useful assuming certain conditions (network with low load; subscriber is always granted requested resources), in a real network base station ability to support given traffic type is not equal with granting requested service flows by subscribers. Authors propose using RSSI measurements as the sole way of assessing signal quality during scanning. Taking into consideration that there are 3 other metrics defined in the standard (CINR, relative delay and round-trip delay), proposed approach is somewhat surprising. Provided results of simulated scenarios indicate that used network model was very simple as all dependencies are strictly linear. Some conclusions are also controversial, e.g. handover takes 100ms with only one neighboring base station, but takes over 500ms, when there are 5 base stations nearby. As this paper is focused exclusively on 802.16, it did not provide any insight into upper (IPv4, IPv6) layers.

2.13.3. Roaming Over WLAN and WiMAX

Another related area of study is a vertical handover. Changing not only point of attachment to the network, but also wireless access technology is a diﬃcult topic. Gondi and Agoulmine in [29] discuss such movements and propose Roaming Intermediatory Interworking architecture to address related issues. Proposed architecture includes Roaming Intermediatory (RI) that acts like a broker between home and visited networks. It is independent entity that is not related to any of the network operators. Various aspects involving network selection, network presence, authentication, authorization and billing between operators are discussed. Although RI is an interesting theoretical concept, its real life feasibility is disputable. It would require one entity for a designated area (e.g. a country), probably managed by a single government agency or other well trusted organization. Another uncommon proposal is to determine current location of a mobile user using triangulation. Information of the coverage networks in the neighboring cells are informed by the home network. Such solution would require complete network coverage maps of any location that is going to be supported. Moreover, that information is expected to be kept at home network and not obtained locally. This publication has one very strong point, however. Authors assembled actual 802.16 and 802.11 networks, developed and deployed proposed architecture and performed actual measurements. Unfortu- Related work 27 nately, handover latency is disappointing – depending on the handover type (WiMAX to WiFi or vice versa), measured latency is between 8 and 10 seconds. As authors acknowledge that observed latency is a possible area of future improvements, further research results should be anticipated.

2.13.4. Seamless Realtime Traﬃc Handover Policy for IEEE 802.16m

A new policy was proposed by Sachin, Song and Chong [95] to limit handover latency and conform to strict requirements imposed by (still under development) draft standard 802.16m. According to [43], latency interruption in connection between mobile subscriber station and network should not be more than 150msec in case of inter-frequency handover and less than 50msec in case of intra-frequency handover.

2.13.5. Human Mobility Patterns

Human mobility pattern (HMP) is an upcoming field in mobile network technology. Shrestha, Song, Song and Chong proposed new handover decision algorithm that is based on analysis of HMP [95]. Authors convince that by understanding people’s mobility patterns of mobile subscriber station can be anticipated. Furthermore, they assume that such knowledge could be leveraged to optimize handover performance by exploiting the users’ mobility characteristics. They rightfully point out that focus should be on an Mobile Subscriber Station (MSS) that travel with high speed rather than pedestrian speed, because at the walking speed MSS with ongoing connection need only one handover or even no handover at all. Extensive 2 month study of 20 volunteers showed that there is a very high repeatability (around 90%) in routes chosen by individuals regarding paths leading to their most popular destinations (school, work and shopping). On the other hand, predictability was quite low regarding drink/food or work/recreation activities. Based on those frequent routes, Mobile Subscriber Station constructs list of visited Base Stations with recorded times spent in each cell, with possible branches indicating different paths. This information can be used for estimate expected duration of stay within current base station and anticipate departure time and likely next destination. This in turn can be leveraged to begin negotiations with target base station early and save time during actual handover. Detailed proposal, including technical details of the handover process, is presented. This proposal is unique and simulation results indicate that its usefulness is quite large. Although it may be useful for repetitive travels only, it does not provide any extra benefit while visiting new networks. Published results indicate that handover time using this method is below 150msec, therefore meeting requirements specified in 802.16m. As such, it is very valuable contribution to the mobility research.

2.13.6. Mobile networks on Vehicles across Heterogeneous Networks

Paik and Choi focused their research on slightly different topic – how to enable mobile networks, mainly in mobile vehicles. To achieve stated goal, a new architecture was designed. To support IPv6 connectivity, DHCPv6 agents and Handoff Management Center (HMC) were proposed in [89]. DHCPv6 agent is a functional combination of a server and a client. During vehicle movement, it is perceived as a client by the outside world. It leases prefixes from a stationary DHCPv6 servers. At the same time, it offers addresses 28 Related work to nodes inside mobile network. To achieve better connectivity, support for multiple mobile routers was envisaged. In case, when more than one mobile router is available, algorithm for selecting primary mobile router is provided. HMS tries to limit or even completely eliminate packet losses during handovers by using forward loss recovery (FLS). It is expected to anticipate signal degradation and imminent handover and instruct old access router to forward all incoming traffic to next access router. Unfortunately, the paper was published in 2003 – no final DHCPv6 or Mobile IPv6 specifictions were available, thus work was based on draft versions. As a direct effect, proposed architecture attempts to leverage features that are no longer present in final specifications (e.g. Foreign Agent). Also, not using NEMO [18] is considered a serious limitation. As such, to be of practical use, this work would require major overhaul and update to current standards.

2.13.7. Fast RSVP reservation for Mobile IPv6

Dutkiewicz analyzed interesting problem in a related area. In a paper [25] new cross layer scheme for efficient resource reservation using RSVP protocol in a mobile environment, named Fast RSVP. Fast RSVP includes a number of mechanisms such as advanced resource reservation on neighbor tunnels and optimized router, handover sessions and path merges. Classic RSVP protocol is designed for wired and fixed networks, therefore its use in a mobile environment creates number of issues: the control messages cannot be identified in the tunnel; RSVP protocol advance resource reservation scheme are not available and there are no mechanisms that allow distinguishing between RSVP requests and ordinary traffic. Proposed mode of operation features handover process split into two stages. The first stage consists of setup of the resource reservation neighbor tunnel. Second is dedicated to resource reservation on the optimized route.

2.14. Summary

Brief review of selected publications presented in this chapter shows how diverse various aspects of mobility research are. Depending on intended goal, defined problems and proposed goals may take radically different forms. Each mentioned standard, proposal or paper introduce slightly different solutions or point out new aspects. Depending on the intended use, there are numerous ways to solve certain mobility and handover related issues. As number of researches conducted in the area increases, it is becoming more obvious that there is no “silver bullet” – one solution that will solve all issues. Therefore each proposed solution may be the best for only a certain scope of problems. As such, direct comparison between them is often not possible. It is a reasonable conclusion that none of the presented publications ultimately dealt with the handover latency, caused by stateful autoconfiguration. Although optimistic DAD mechanism tried to solve DAD procedure delays to some extent, its limitations (both pointed out in the paper itself and discovered later) may hinder its deployment and limit it usefulness. Also, while only minority of available proposals mentions DHCPv6 operations, none focus on it. That crucial, but overlooked part of IPv6 reconfiguration is one of the major areas of improvement proposed in this dissertation. In the later chapters of this dissertation, number of proposals are defined to solve this and related autoconfiguration Related work 29 problems. 30 Related work 3. Proposed improvements

This chapter contains list of possible extensions and improvements, both allowed by existing standards and introduced in this dissertation. Already defined mechanisms include WiMAX network reentry and its various types; preference and rapid-commit options offered by DHCPv6 are discussed. New proposals include skipping Duplicate Address Detection (DAD) mechanism; performing DAD mechanism on server side; performing remote autoconfiguration; configuring routing based on data provided via DHCPv6; and performing Mobile IP’s Binding Update while still being in the old location. Details of each modification are provided and are accompanied with discussion regarding benefits and drawbacks from the mobility perspective.

As explained in the previous chapter (see Sections 1.1.3 and 1.2.2), there are several mechanisms that introduce signiﬁcant delays to the handover procedure. To limit, or – in some cases – even completely eliminate such delays, a number of new improvements have been proposed. Section 3.1 with following subsections describes optimization oﬀered by existing standards, while Section 3.2 and following subsections explain new proposals.

3.1. Existing features usage

There are several optional featured already deﬁned in existing protocols that could prove useful during handover. Those features and their proposed usage are described in the following subsections. They are not considered proposals, but rather are going to be used for constructing “best standard” scenarios, used for comparison with actual proposals. Comparing new proposals with existing ones will provide insight into proposal’s usefulness. It should be stressed out that these are not new proposals. Besides improvements mentioned in following subsections, experiments discussed in Section 4.6 will also cover situation, where all conﬁguration and mobility processes run in their original form, without any improvements whatsoever. Such scenario will be referred to as “basic” and will be used as a reference, worst case.

3.1.1. WiMAX Optimizations

802.16 protocol [34] features complicated network entry mechanism. In its later version [36], mobility support was added. Network reentry (i.e. network entry after changing point of attachment, recovering from sleep mode or similar) was deﬁned. This reentry process is not ﬁxed, but rather consists of several 32 Proposed improvements

Figure 2: 802.16e Network Entry/Reentry procedure. Handover ranging phase applies only to reentry. Dashed green lines mark phases that may be skipped under certain conditions phases, which could be optional, assuming certain conditions are met. Depending on subscriber capabilities, base station conﬁguration and its a’priori knowledge about reentering subscriber, some phases of the reentry may be skipped. Full network reentry procedure has been presented in Fig.2 for high level overview. During ﬁrst RNG-REQ – RNG-RSP message exchange, subscriber and base station agree on the actual network reentry scenario. Following parts may (or may not) be omitted:

SBC exchange – During this phase both participants negotiate set of commonly supported features. Such knowledge may be stored in a client database or shared by the previous serving base station. If base station knows subscriber station capabilities in advance, it may choose to skip this step.

PKM – Privacy Key Management version 2 was introduced in [36]. It features significant improvements over older version 1, specified in [34], such as mutual authentication between subscriber station and base station and support for key hierarchy and Extensible Authentication Protocol (EAP). Security related activities can be split into two phases. First handles subscriber authorization and AK exchange. Second offers TEK exchange. Also standard does not specify how to use EAP. It is provided as a way for vendor-dependent solutions, so exact message exchanges and operations may vary.

REG exchange – During this phase subscriber station logs into the network, access control is checked and ﬁnally access to the network is being granted. If the access has been granted already, this step Proposed improvements 33

also may be skipped. If base station knows keys used by subscriber station and they are still valid, base station may choose to not exchange new keys. Each key is accompanied with several parameters like lifetime and SAID (Security Association IDentifier). SAID numbers are unique within one base station. As such, they may be different between base stations, thus base station has to provide new SAID identifiers and mapping between old and new values. SAID update option may be sent for that purpose in RNG-RSP message. For introduction to PKM operation, see [1] or [82].

Service flow creation – WiMAX is a connection oriented network. To transmit user data, subscriber station has to create at least two service flows: one uplink and one downlink. There are numerous parameters associated with each service flow, like traffic type, QOS parameters, security association used etc. Each service flow is identified by 2 unique identifiers: Connection ID (CID) and Service Flow ID (SFID). In most cases, there is a one to one mapping between them (except uncommon scenarios, when service flow is deactivated, but not deleted). If parameters of the service flows are know by target base station and they can still be provided, base station may choose to not recreate service flows from scratch, but rather reuse them. In such case, base station creates those service flows on its own, without any subscriber station interaction. If base station is not able to provide the same CID identifiers as used in previous location, it may generate new and provide subscriber station with the update list. CID Update option sent in RNG-RSP message may be used for this purpose.

Depending on amount of knowledge about incoming subscriber, base station may decide, which steps are necessary and communicate its decision to subscriber station . Simulation scenarios are defined in the following chapters. Although used simulation environment allows flexible selection of used WiMAX optimizations, scenario offering WiMAX optimizations will feature all options enabled. This scenario, where all mentioned phases are skipped will be designated as “wimax-optim”.

BENEFITS: • Allows flexible approach to L2 handover. Depending on network operator preferences, tradeoff between handover speed and flexibility in provided services may be achieved.

• Depending on local conditions and network administrator preference, parts of the reentry process may be selectively skipped or left operational

• Skipping service ﬂow creation is especially desirable, as waiting for possible DSA-RSP message retransmissions may increase HD metric by up to 1000 ms.

• Omitting network registration and key generation is usually time consuming as responses often cannot be generated locally by base station. Other entities in the network (e.g. AAA server) usually have to participate in the exchange, introducing additional delays. 34 Proposed improvements

DRAWBACKS: • base station must have a’priori knowledge about incoming subscriber station. 802.16e-2005 speciﬁ- cation [36] does not deﬁne how to obtains such knowledge. Such information sharing mechanisms between base stations are left for implementers and device vendors.

Benefits/Drawback discussion: There are other optimizations possible as well. In particular, base station can instruct subscriber station not to initiate higher layers reconfiguration. In the area of this study that is IPv6 layer (with all layers on top of it). However, using this flag means that data to and from subscriber station will be using the same addressing as before changing location. That means that network operator will take care of the routing reconfiguration. Therefore this improvement may be used in intra-domain handover only, where both source and target locations are managed by the same entity. As this requirement greatly reduces scope of discussed issues, it is not being taken into consideration and the worst (i.e. inter-domain handover) scenario is always assumed. Other possible optimizations are not related to network protocols in general, but rather specific implementations, like the requirement to download boot code via TFTP or refreshing clock synchronization by using NTP.

3.1.2. DHCPv6: Preference 255

When IPv6 node initiates stateful autoconfiguration process, it transmits Solicit message intended to be received by all DHCPv6 servers, as specified by [22]. Each server responds with an Advertise message. Each server may be configured by the system administrator to be “more” or “less” preferred. That is reflected by a specific value of the Preference option from range 0 to 255. Client, after receiving first response to its query, does not know if there are other servers. According to [22], it must wait exactly 1000ms for possible additional replies. There is one exception to that rule. As it is not possible to have server preference set to 256 or more, client must accept response with Preference option set to maximum value of 255 and continue autoconfiguration immediately, without waiting for other possible replies. This improvement offered by [22] will be referred to as “preference-255”.

BENEFITS: • Skips waiting period for possible responses from other servers. HD metric is expected to decrease by up to 1000ms.

DRAWBACKS: • It is not possible to reliably provide redundancy as all replies except the ﬁrst will be ignored by the client.

• Mutually exclusive with Rapid-commit option.

Benefits/Drawback discussion: Theoretically it is possible to still provide redundancy by configuring all servers to maximum preference. In such case, all available servers would be competing for getting client’s attention. As only the first response is being accepted by client, winning server would be the one, which responded first. This approach creates race conditions as may cause severe issues. For example, Proposed improvements 35 if one server is faster than the others, it will intercept all incoming clients and remaining slower servers will never get any chance to serve clients. Therefore it is reasonable course of action to assume that redundancy is lost in this scenario. However, since usually DHCPv6 server will be located on the base station itself, there are no additional redundancy benefits from providing extra servers. Once the device offering DHCPv6 (base station) crashes, no traffic is able to get through, so any additional servers will also get disconnected. On the other hand, reducing HD metric by 1000ms is a huge benefit, therefore from the mobility perspective, using maximum preference is highly recommended. For a discussion regarding DHCPv6 redundancy, see [11]. Also, this approach can only be used with 4 message exchange scenario. It does not apply to the 2 message exchange that is more efficient (faster) from the mobility perspective. Therefore its practical appliance in mobile environments is rather limited.

3.1.3. DHCPv6: Rapid-commit

Another possible optimization provided by the DHCPv6 specification [22] is a Rapid-commit option. During normal configuration, client transmits Solicit message and expects to receive one or more Advertise messages from available servers. After choosing the best suitable1 server, client transmits Request message addressed to this specific server2. Server responds with Reply message, which finally contains addresses and other configuration parameters assigned to this client. This typical scenario is sometimes referred to as “4 message stateful autoconfiguration”. It is possible to speed up the process by eliminating two messages. Client can include Rapid-commit option in the Solicit message to indicate that it is interested in a quick configuration. Servers, which are configured to support this way of configuration, answer with Reply message, skipping Advertise – Request part. This mechanism will be referred to as “rapid-commit”.

BENEFITS: • Skips one second waiting phase for Advertise messages. This eﬀectively decreases HD metric by 1000 ms.

• Skips Advertise and Request messages, thus simplifying operation.

• Provides better improvement than Preference option set to maximum value (see subsection 3.1.2). Not only eliminates the 1000 ms long server discovery phase, but also decreases number of exchanged messages by two.

DRAWBACKS: • It is not possible to reliably provide redundancy as all additional replies (except the ﬁrst) will be ignored by client.

1Selection algorithm is implementation dependent. 2Messages are actually sent to the multicast address, but contain server’s unique identiﬁer (DUID), therefore are immediately discarded by other servers. 36 Proposed improvements

• If there are multiple servers available, this method causes duplicate allocations. Each server will grant requested resources (e.g. addresses), but only the ﬁrst one will actually be used. It is a general practice to not use Rapid-commit option in networks that oﬀer server redundancy.

• Mutually exclusive with Preference-255 option.

Benefits/Drawback discussion: Using Rapid-commit option may cause to waste some resources if there is more than one server. Each existing server will allocate address and possibly other configuration options requested by client, but client will be able to use only the first received set of parameters. Also, server redundancy in the 802.16 environment is not feasible. See benefits/drawback discussion in Section 3.1.2.

3.2. New improvement proposals

In the following sections new proposed mechanisms are described. They are introducing number of novel solutions related to handover efficiency. Although each proposal is unique and deals with different inefficiency, their ultimate goal is the same – to minimize handover latency. Those novel ideas were designed by the author and described in several published papers [74, 76, 78].

3.2.1. Skip initial delay in DHCPv6

DHCPv6 specification [22], Section 17.1.2 states that first message sent by the client on the interface must be delayed by a random amount of time between 0 and 1000 milliseconds. This delay is supposed to avoid all clients transmitting at the same time after power outage. However, in the mobility environment, waiting up to 1000 ms just to limit non-existing congestion is clearly not acceptable. Therefore this initial delay should be omitted completely. This proposed configuration will be referred to as “skip-initial-delay”.

BENEFITS: • Speeds up network reentry. Optimistic case decreases ﬁrst network entry by up to 1000 ms, while average case is decreased by 500 ms. Therefore HD metric is decrease by 500 ms on average with potential for 1000 ms decrease.

• Prevents network congestion after power outages in ﬁxed environments. It does not apply to units with their own power source (i.e. most mobile units).

DRAWBACKS: • May be obsoleted by using advanced methods. See section 3.2.4.

• Aﬀects only the ﬁrst network entry.

• Required changes to DHCPv6 speciﬁcation.

Beneﬁts/Drawbacks discussion: Authors of the [22] didn’t take into consideration wireless mobile environment and its requirements. As each mobile device has its own power supply, it is not possible Proposed improvements 37 to reboot all devices at once. The only remote possibility to actually aﬀect numerous mobile devices simultaneously is by generating huge electromagnetic pulse. Due to requirements for generating such distortion, this scenario is considered extremely unlikely. Two known phenomena that possibly could cause such conditions are unusually strong solar outbursts hitting Earth ionosphere or electromagnetic shockwave after nuclear explosion. In both cases, the phenomenon itself would draw such attention that slight network congestion caused by rebooting mobile stations would become irrelevant.

3.2.2. Skip Duplicate Address Detection in IPv6

[101] in Section 5.4 specifies that every IPv6 node after receiving a new address, must perform Duplicate Address Detection procedure. This DAD procedure is intended to detect possible, but unlikely duplicates, i.e. if there are other nodes that use this recently acquired address. To do so, node transmits Neighbor Solicitation message to the all-nodes multicast address. As specified in [101], the Neighbor Solicitation’s Target IP Address is set to solicited-node address (a multicast address that is computed as function of node’s unicast address, see [31] for details) being checked, the IP source is set to the unspecified address and the IP destination is set to the solicited-node multicast address of the address being verified. If there is a node that already uses this address (a duplicate), it will respond with Neighbor Advertisement message. When there is no response (i.e. there are no nodes with duplicate address), node is supposed to wait 1000 ms ([101], Section 5.1) for a possible response. Furthermore, according to [101], as this is the first IPv6 message to be sent from an interface after interface reinitialization, the node should also delay the transmission by a random delay between 0 and 1000 milliseconds (RETRANS DELAY counter). After waiting that time, node may also restart transmission and wait phase up to 3 times (MAX NEIGHBOR ADVERTISEMENT counter), which essentially leads to the delay being quadrupled. In this dissertation, it is assumed that this time is set to minimal possible value of 0 (just one transmission, no retransmissions). This mechanism is not 100% accurate. For example, node must not respond to Neighbor Solicitation messages, when its address is tentative. So if there are two nodes that will have the same address assigned within less than 1000 ms delay, they will not detect its duplication as during DAD procedure, the same address will be in a tentative mode on both nodes. Also, any malicious node attempting denial of service attack may simply choose to not respond to Neighbor Solicitation message. This proposed optimization will be referred to as “skip-dad”.

BENEFITS: • Speeds up conﬁguration process. HD metric of the whole handover process is expected to be decreased by 1000 ms.

• In a properly conﬁgured network that is not under attack, duplicate addresses never happen.

• Duplicate Address Detection procedure was meant for multicast capable environments. Although it is possible to use it in point-to-point environments (802.16 in the uplink direction is essentially a 38 Proposed improvements

point-to-point as subscribers are able to communicate with its Base station only and not with other Subscribers.), its usefulness is greatly limited. Therefore by skipping DAD, little beneﬁt is forfeited.

DRAWBACKS: • Assuming unlikely conditions are met (multicast support is provided and supported by both subscriber station and base station; and network is misconﬁgured or under attack), subscriber station may miss the chance to detect duplicated address.

• Impact of this mechanism can be limited by other means (e.g. Optimistic DAD procedure [72], see Section 2.9 for brief overview).

• Better approach is available. See Section 3.2.3 for Server side DAD proposal.

Benefits/Drawback discussion: In a real life environment, address duplicates are extremely rare and are sign of severe network misconfiguration or a malicious attack. In the former case, nodes no longer are able to perform their duties. In the second case – a malicious attack – to spoof duplicate address, attacker must have already penetrated the network. After link has been compromised, attacker can trigger numerous error conditions and DAD procedure will not prevent him from doing so. To work properly, DAD requires full multicast capability. In basic mode, WiMAX base stations do not offer capability for subscriber stations to communicate with each other. Separate feature – multicast service flows – must be supported and configured to achieve this capability. Therefore, in typical scenario it is not even possible that DAD procedure would succeed. If, due to reasons discussed above, DAD should not be omitted, following section proposes better approach to the Duplicated Address Detection delay problem.

3.2.3. DHCPv6: Server side Duplicate Address Detection

As mentioned in Section 3.2.2, in some cases skipping DAD procedure completely may not be the best option. Therefore following approach has been proposed. To expedite automatic configuration process, server may maintain a small pool of IPv6 addresses that are checked against duplication. Full DAD procedure must be performed for each address added to this pool. This check is being done by the server. After successful validation, address is ready to be leased by clients. It is essential for a server to passively participate in the DAD procedure for those addresses, i.e. to answer for possible DAD messages, sent by other nodes trying to use such address. This can be easily achieved by temporary configuring address in question on server’s local interface. Before server sends information about particular lease to the client, assigned address should be removed from the server’s interface (i.e. server should stop responding to DAD messages sent to this specific address). It does not offer any benefits to assign such pre-validated addresses to the clients that do not support this extension. In case of client not supporting this extension, client after receiving such address, will initiate the DAD procedure anyway, rendering the whole optimization useless. To make sure that client supports this enhancement, client should send special suboption to the server in the IA NA option in the Solicit or Request messages. It will inform the server that this particular client supports server-dad and Proposed improvements 39

NEIGHBOR SOLICIT (3) BS

DHCPv6 REQUEST (1) 1 2 Classicapproach DHCPv6 REPLY (2) SS SS BS 3 4 Neighbor Adv (4) ? Link

Duplicate node

Neighbor Solicit (1) Link Proposedapproach DHCPv6 REQUEST (3) 1 2

DHCPv6 REPLY (4) BS SS BS

3 4 Neighbor Adv (2) ? SS

duplicate node

Figure 3: Server side Duplicate Address Detection. Classic approach (depicted in the upper image) assumes that client verifies address uniqueness. Proposed improvement (lower image) limits time window, when subscriber is involved in the configuration it is possible to grant such prevalidated address. On the other hand, to confirm that server supports this enhancement, it should send this option back to the client in the IA NA option in the Reply message. Comparison of classic and proposed Duplicate Address Detection procedure is shown on Fig.3. This proposed improvement will be referred to as “server-dad”.

BENEFITS: • Eliminates DAD procedure from the client conﬁguration process.

• Speeds up reconﬁguration process by length of DAD procedure. HD metric is expected to be decreased by at least 1000 ms.

• This proposal is fully compatible with remote-autoconf extension (discussed in Section 3.2.4). It removes necessity for client to be physically present on the link. Therefore with this feature, remote conﬁguration becomes possible.

• Fully backward compatible with DHCPv6 servers and clients that do not support it. 40 Proposed improvements

DRAWBACKS: • Adds extra operations to the server, thus limiting its scalability.

• Requires both server and client modiﬁcation.

• With compromised server, it is possible to cause client to use duplicated address.

• Address reservation may prove to be diﬃcult, but possible

Benefits/Drawback discussion: Compared to other DAD improvements, this proposal does not modify the mechanism itself, but rather changes its executor. It is being performed by the DHCPv6 server that provides the address rather than DHCPv6 client (i.e. node that receives the address). Although the procedure still takes 1000ms, it can be done in advance, i.e. during server bring-up. Once server becomes operational, it has small pool of addresses at its disposal. When incoming client requests for prevalidated address, it can be served and used immediately. Therefore, from the client’s perspective, the delay is eliminated. This feature is fully backward compatible. Clients that do support it can work flawlessly with servers that lack support and server that provide support can process requests from clients that lack such support. As this feature affects client and server as well, both entities have to be modified. One of the security hazards is that once server becomes compromised, it is trivial to trick clients to use duplicated addresses. That is not, however, a significant issue as once the attacker gained access to the server, it may spoof already used addresses, thus creating duplicated address scenario anyway. Also, once attacker gains ability to spoof DHCPv6 server, there are other attack vectors that are more harmful than DAD.

3.2.4. Remote Autoconﬁguration via DHCPv6

During normal handover procedure, data link layer (e.g. 802.16) initiates and performs handover procedure. This phase is often referred to as L2 handover. After such procedure is completed, network layer (e.g. IPv6) handover is performed. Doing so, delays introduced by each layer are adding up, resulting in a large overall delay. Using data gathered by 802.16, subscriber knows its target location, before actual handover occurs. This prior knowledge may be exploited to initiate connection with a DHCPv6 server, located at the destination network. As all base stations are connected to the core network, it is possible to make connection between base stations using backbone network. To initiate and maintain such communication, already existing DHCPv6 relays may be used, albeit in a modiﬁed form. In a classical conﬁguration, relays work as intermediaries between clients and servers. From the client’s perspective, direct communication with server or via relays is indistinguishable. Relays act as representatives of the server. From the server’s perspective client is connected to the remote link. By modifying relay’s behavior, it is possible to use relays to forward data from client to server and vice versa. In this scenario, client is aware of the relays. It sends messages to relays and expects them to be forwarded to the remote server. Thus relays act as representative of the client. From the server’s perspective, client is connected directly to the local link. To achieve such operation, relays and servers must support this new mode. Proposed improvements 41 Target BS Serving BS Serving

Figure 4: Once client gains knowledge about its next point of attachment prior to executing handover, it can communicate with DHCPv6 server at the destination location to perform conﬁguration before actual handover occurs. Client maintains full communication capability while performing this remote conﬁg- uration

It is client’s responsibility to define, which destination server it would like send DHCPv6 requests to. Client should include extra option to define, which server it would like connect to. This information will be used by relays to forward messages to final destination. Knowledge about destination location identifiers is provided by WiMAX layers. “BS ID” obtained during scanning and/or L2 handover preparation is a functional equivalent of the MAC address. DHCPv6 server unique identifier (see [22]) of type DUID-LL can be generated from such information. It is up to the relay to find actual location of the destination server. Overview of this improvement is depicted on Fig.4. This feature will be referred to as “remote-autoconf”.

BENEFITS: • Allows obtaining IP conﬁguration (address and extra parameters) at target location, before actual handover.

• Knowledge about target location can be leveraged to further improve reconﬁguration, e.g. to perform Mobile IPv6 updates (see Section 3.2.6).

• This procedure can be executed while mobile node still maintains connection capability at source location. As connectivity is available during remote DHCPv6, HD metric of this process is decreased to 0 ms. 42 Proposed improvements

DRAWBACKS: • Requires client, relay and server modiﬁcation

• Slows down handover procedure (adds at least extra round trip time between source and target location to the handover preparation time).

• Forwarding messages from the relays perspective may prove to be diﬃcult.

Benefits/Drawback discussion: This approach allows mobile node to communicate with target location before actually changing point of attachment to the network. This ability can be used to remotely obtain all required configuration parameters, including IPv6 address. Such a’priori knowledge about target location can be used in several ways. All parameters may be used immediately after reaching new location. Also those parameters may be used to perform some additional steps, e.g. notify corresponding nodes about new address. Proper target base station selection may prove to be difficult. During scanning, parameters of available neighbor base stations are detected and the best one is chosen. That base station’s ID is sent to current base station as a best candidate for handover. However, due to configuration or other conditions, serving base station may forbid handover to that potential target base station and force subscriber to use another destination. This renders the data gathered in scanning phase obsolete. Such scenario is unlikely, but possible. There are 3 possible approaches to deal with that problem:

Cooperative – To initiate handover, Subscriber Station sends list of desired target Base Stations. As- suming Base Station cooperation, Subscriber will receive permission to execute handover to desired location. In such case, remote DHCPv6 autoconﬁguration can be initiated before actual handover procedure is initiated.

Conservative – This approach may be considered worst case scenario. Subscriber station assumes that base station will not allow handover to proposed target location, but rather force subscriber station to use diﬀerent destination. Subscriber station can initiate remote autoconﬁguration after BSHO- RSP message is received from base station. This causes subscriber station to wait for base station response before actual IPv6 preparation can take place.

Hybrid – Once scanning is complete, subscriber station has list of possible destination targets. Instead of initiating remote IPv6 configuration for the best target, it starts remote configuration process for all targets, before triggering actual handover. If base station changes denies request to move to a specified target and provides other location as destination, subscriber station may already have completed configuration retrieval for that location. Subscriber station may then continue with handover process and discard configuration for remaining, not used locations. Theoretically, it is possible that base station may provide destination target that was not previously discovered during scanning procedure, but such behavior is highly unlikely. It would force subscriber station to perform handover to a base station that it was unable to listen to.

As conservative approach is considered the worst case scenario, it was selected for validation during simulation and modeling. Other approaches should be considered areas for possible further improvements. Proposed improvements 43

In current form, this proposed method requires WiMAX as a network layer. This functionality can be broadened to other network types. Such networks need to provide information regarding target location, before actual handover is performed and while mobile station maintains full communication capability. Reﬁning such requirements and broadening its application to other network types is another area of further studies.

router ATION SOLICIT OUTER R MENT ERTISE NG ADV ION) ROUTI IGURAT G CONF (ROUTIN

S OLICIT (serv er discovery) DHCPv6 client, ADVERT ISE (server ano host uncement) REQUEST REPLY (address and configuration DHCPv6 server parameters)

router

S OLICIT (serv er discovery) DHCPv6 client, REPLY (ad dress, routin host and g information configuration parameters)

DHCPv6 server

Figure 5: Routing configuration via DHCPv6. Standard approach assumes that routing and address configuration will be done using 2 separate mechanisms, using 2 and 4 message exchange (with the possibility to decrease number of messages to 2 for address configuration). This situation is presented in the upper diagram. Proposed mechanism assumes that routing parameters are sent together with address and other configuration options using DHCPv6 exchange. This situation was depicted in the lower diagram. Messages that convey configuration options are marked in blue. Messages that can be omitted in certain cases are marked with dashed line.

3.2.5. Routing conﬁgured via DHCPv6

During normal configuration, IPv6 nodes are expected to wait for (or force router to transmit) router advertisements to configure routing. From the mobile node perspective, that requirement is unfortunate as it introduces additional delays. To solve this problem, authors propose new method for routing configuration. As clients must exercise message exchange with DHCPv6 server, it may also provide extra information that allows clients to configure routing. To convey this information, new DHCPv6 option – address parameters – have been proposed and support for this option have been implemented. For an overview of this proposal, see Fig.5. This proposal has been thoroughly described in [79] and was 44 Proposed improvements practically verified using [80] code. This feature will be referred to as “address-params”. This name was selected, because for local routing configuration already exchanged address information must be extended by only minor extra information. This extra information can be considered extra address parameters. Hence the proposed name.

BENEFITS: • Skips waiting period for Router Advertisement messages.

• Allows routing conﬁguration on a per node basis.

DRAWBACKS: • Requires both server and client modiﬁcation.

Benefits/Drawback discussion: In a classical approach, IPv6 hosts are configured in both stateless and stateful manner. After finishing stateful configuration (DHCPv6), node is able to receive Router Advertisement messages, periodically sent by routers. As transmission intervals are configurable and may even be several minutes, nodes may choose to demand such message, instead of waiting for next transmission. To do so, a host should send Router Solicitation message. However, as prevention against network flooding, routers may be configured to not transmit more than certain number of Router Advertisement messages per second. Should the threshold be met, further Router Solicitation messages will be ignored. Therefore, nodes are usually able to speed up configuration process, but are not guaranteed that such speed up will actually work. On the other hand, DHCPv6 servers are required to respond as fast as possible, regardless of number of already sent messages. Additionally, as DHCPv6 communication must be performed anyway, it is better to add extra information about routing, rather than wait for routing configuration to complete and then start DHCPv6 configuration. Although it may be possible to run DHCPv6 configuration and request for RA simultaneously, routing configuration before address configuration is complete is difficult. In particular, when adding new routing entries to the routing table, it would not be possible to specify source address for this particular route. For details, regarding address selection, see [21]. Adding extra information to DHCPv6 exchange requires both server and client code modification. That is not considered an issue, however, as Dibbler code providing such functionality was implemented by author is available for everyone [80]. It is worth noting that standard DHCPv6 protocol requires routers for operation and cannot be used in separated, single segment networks (i.e. without routers). With this modification, such limitation is removed. For a practical aspect of this proposal, see FAQ section in [79].

3.2.6. Mobile IPv6: Remote Binding Update

Mobile IPv6 protocol requires mobile node to notify its Home Agent and Correspondent Node about new address by using Binding Update procedure. Typically such procedure is the last step after handover is complete and address reconfiguration is already completed at new location. However, using remote Proposed improvements 45 autoconfiguration mechanism described in Section 3.2.4, mobile node gains information about its next location and new address to be used at that location before actually performing handover. This information can be used to notify its home agent and corresponding nodes about upcoming address change. This a’priori knowledge can be leveraged to send Binding Update before actual handover is performed. There is a certain danger is doing so, however. Since mobile node prepares to change locations, it is logical conclusion to assume that transmission capabilities are degraded and it is uncertain if sent message will be delivered reliably. Although WiMAX provides safe delivery mechanisms like ARQ or Hybrid ARQ, they require subscriber station to be associated with base station and actively retransmit messages, should their reception be not confirmed. Therefore danger of actually losing transmitted Binding Update is very real and should be dealt with.

CN 5 . 3 B . i B n 4 d i n . in 1 d B g # i i n n A e Backbone g d t i c a A n k d network c g n p k U o n w U p o l g w d e Target n a d i le t g Serving d d e e BS in g # m e 2 BS B e . # n 1 1 t # 2

2. handover SS/MN SS/MN (old location, before handover) (new location, after handover)

Figure 6: Remote Binding Update. Once mobile node learns its new address (valid for destination location) while still being in the old location, it sends Binding Update message to Correspondent Node and performs handover to the destination location. Assuming successful transmission, handover and reentry completed on time, Mobile Node will be able to receive Binding Acknowledge #1. However, this ﬁrst binding update may fail due to number of reasons: failed BU #1 transmission, too long reentry, etc. Therefore second Binding Update is transmitted immediately after network reentry is complete

To solve this problem, mobile node should retransmit Binding Update once it reaches its new location. Depending on if the ﬁrst transmission was successful or not, corresponding nodes and home agent may receive duplicated Binding Update. Depending on the implementation, such incoming updates will be processed twice or the second copy will be discarded. In both cases, Binding Update mechanism will work properly. In case of lost transmission from old location, only one copy will be received and update will be performed normally, without any advantages compared to classic Mobile IPv6 protocol. This proposed feature was depicted in Fig.6. 46 Proposed improvements

It should be noted that in the classic Mobile IPv6, besides sending Binding Update to Correspondent Nodes, Mobile Node must provide proof that it is indeed in possession of the new care-of address. To meet this requirement, Return Routability Procedure is performed. It consists of two tests (home address test and care-of address test) that include communication via home agent. Such not direct communication require additional time that contributes to the total latency. Fortunately, there are several ways to overcome that limitation. One of the most common is Route Optimization, described in Section 2.7. During simulation, it was assumed that only Binding Update was performed, and the Return Routability Proce- dure was skipped. This feature will be referred to as “remote-binding-update”. In previous publications ([76], [78]) is was referred to as “Split Binding Update”.

BENEFITS: • Can reduce Binding Update procedure by up to half of round trip time to Corresponding Nodes/Home Agent in optimistic scenario.

• Requires only Mobile Node modiﬁcation.

DRAWBACKS: • Requires remote-autoconf improvement.

• In worst case scenario (transmission at old location was not successful), this method does not improve anything.

Benefits/Drawback discussion: To achieve better time savings, precise time estimation is required. Mobile node, while still in the old location, can communicate with its home agent and corresponding nodes. Using simple methods (e.g. ICMP Echo Requests), it can measure round trip time to its home agent. This does not introduce any delays, since mobile node maintains full communication capabilities during measurement procedure. When round trip time is evaluated, mobile node can send Binding Update message from the old location and then perform handover. It can wait half of the round trip time before making handover. Therefore in the average case scenario it is assumed that lack of communication period (caused by the binding update procedure) will be halved. Subscriber can also estimate time required to perform network reentry at the new location. Information about network reentry optimizations available might be obtained during scanning (by using scanning with association, type 0, 1 or 2) or via additional option provided by the DHCPv6 server. If the mobile node concludes that half of the round trip time is greater than estimated network reentry time, it can wait longer between Binding Update transmission and actual handover. There is a possible danger, however. If the response – Binding Acknowledgement message – is received at destination location before network reentry and reconfiguration is complete, it will be dropped and subscriber will have to resend binding update. To work around this problem, base stations might buffer control traffic messages. Since control plane messages are rare, its buffering should not burden base stations. Proposed solution – to retransmit Binding Update after reentry and reconfiguration is complete – solves aforementioned problem. Also, Binding Update retransmission once subscriber station concludes Proposed improvements 47 network reentry at target location assures that bindings will be update, albeit with normal efficiency in the worst case. Adding yet another preparatory step further increases handover preparation time. However, since it is up to subscriber station to define both handover initiation phase (MSHO-REQ transmission) and the actual handover time (HO-IND transmission), subscriber station is able to extend length of this preparation time. Extra factor must be taken into consideration, however. Decision to initiate handover has been made already, so radio conditions are deteriorating. Further delaying handover may cause mobile station to be unable to successfully transmit any messages. That issue can be solved by modifying criteria for algorithm that triggers handover. Such modifications are outside of scope of this paper. 48 Proposed improvements 4. Efficiency analysis

This chapter is devoted to the assessment and veriﬁcation of proposed mechanisms. Various validation methods are explored: analytical model, simulation and real-life implementation. Requirements, simulation environments, their capabilities and limitations are discussed. Methods used to gather empirical data are presented. Analysis of available pseudo-random number generators and assessment of selected PRNG is provided. Description of simulation arrangements – scenarios and experiments – follows. Mathematical methodology for results processing (selecting simulation length, discarding warm-up periods and parameter estimation) is discussed. Appliance of those methods to estimate actual handover parameters is thoroughly discussed and illustrated with numerous diagrams. Comparison of used optimization techniques conclude this chapter.

To support validity of new proposals, it is a common practice to create theoretical models of proposed methods. By studying their properties, conclusions about modeled mechanism can be deducted. Unfor- tunately, construction of analytical model is only possible for simpler systems. Therefore it is often not feasible to propose reliable model for more complex systems, like multi-subscriber 802.16 networks with advanced IPv6 mechanisms. Another commonly accepted approach to mechanism validation is to design and implement a simulation. By running a simulation, various parameters and properties of the simulated proposal can be measured. By analyzing simulation result, one can draw conclusions about properties of the simulated system. It is essential to properly process obtained results as simulation environment and methods may introduce unwanted artifacts and errors to observed values. Third and least frequently used verification method is an actual implementation of proposed mechanisms in a real environment or a testbed installation. Generally considered difficult to achieve, as often elements of discussed stacks and systems are not yet available (or it is not possible to modify them). Despite those limitations, this method can provide the best verification possible – a real life use cases. To gain confidence in optimizations proposed in Chapter3, two separate approaches were used: simulation and partial implementation. Construction of theoretical model was rejected due to complicated environment and concerns whether constructed model will closely reflect real system. Section 4.1 discusses simulation models and results, which support proposed optimizations. Finally, selected elements of the proposal have been implemented in real and working software. This implementation has been presented in Section 4.4.1. 50 Efficiency analysis

4.1. Simulation model

To verify correctness and evaluate eﬃciency of proposed mechanisms, simulator of aﬀected systems was developed. OMNeT++ [104] was selected as the environment suitable for that purpose. OMNeT++ is a component-based, modular and open-architecture discrete event network simulator. It allows construction or arbitrary complex networks of interconnected modules. This environment was chosen, due to following reasons:

• Open source – source code is available for use and modiﬁcation. This critical requirement allows modiﬁcation of any part of the code.

• Written in C++ – Simulation speed is essential in complicated systems. The scalability of system coded in fast languages (C,C++) are better, compared to slower languages (Java, tcl, perl, etc.)

• Extensive documentation – Detailed User’s Guide [104] is available, accompanied by extensive set of examples and tutorials.

• Free – It is free of charge for personal and academic purposes. OMNeT++ is distributed under Academic Public License.

• Portable – OMNeT++ simulation engine runs on Linux, numerous UNIX systems and even Windows. Such broad coverage allows better scalability. Should home PC prove to be not powerful enough to complete calculations, simulation may be run on university cluster. Although simulation eﬃciency never exceeded modern home PC’s capabilities, possibility to use more powerful systems was not ruled out before implementation was complete.

• Distributed – OMNeT++ support computation in distributed environment, further increasing scalability.

• Scalable – Simple modules may be connected together to form larger, more complex compound modules. This leads to an effective hermetization. As a direct effect, one module may be modified, without any changes to remaining blocks.

4.1.1. Simulation length time

There are two ways of generating statistically reliable results. First is to run the same experiment (simulation) multiple times. Each simulation ends with one measured value. Simulations are repeated, and values obtained during all runs are averaged (or statistically processed in other way). This methodology is well suited for cases, when warm-up period is short, compared to the length of one simulation run. Otherwise total sum of warm-up periods in all runs will lead to significant waste of computation time. Another approach is to exercise one long simulation run. Observations of measured value are taken during that simulation and processed to obtain final results. In such case number of observations is of the same order as in previous method, but the observations are gathered during one long run, rather than several shorter runs. This approach is best suited for cases, where warm-up time is relatively large, compared Efficiency analysis 51 to total simulation time. That is the case in mobile WiMAX/IPv6 environments, therefore this approach was used during experiments conducted as part of this dissertation. In both cases (multiple shorter runs or one long run), total number of observations should be assessed to determine statistical error. In case of unsatisfactory results, correct action depends of used approach. More simulation runs (approach 1) or longer simulation run (approach 2) is required.

4.1.2. Numbat overview

Neither OMNeT++, nor any of its available extensions, does provide support for 802.16 networks simulation. It oﬀers experimental support for IPv6 and Mobile IPv6, but this support relies on precise, but complicated and slow INET framework [103]. Therefore new environment was developed for the purpose of mobile IPv6 stations simulation in the 802.16 environment. This project was started in 2005 under the name Numbat [75]. Numbat provides means for simulation of 802.16 stations with advanced IPv6 stack on top. Example simulation being run in Numbat is presented in Fig.105. The source code is distributed as open source project and is available to everyone. Details regarding Numbat project, its distribution and feedback received worldwide is brieﬂy presented in Section B.1.

Figure 7: OFDMA frame structure. One OFDMA frame is split into downlink and uplink subframes. Frame starts with a preamble that is followed with the DL-MAP that contains information required for decoding DL bursts. In particular, ﬁrst DL burst contains UM-MAP. n-th OFDMA contains DL-MAP for decoding n downlink subframe and UL-MAP to decode n+1 uplink subframe. Subframes are separated by small intervals TTG and RTG, required to switch radio between reception and transmission. This image was taken from [36] 52 Eﬃciency analysis

4.1.3. 802.16 PHY proﬁle

802.16 standard family defines radio channel and enumerates its allowed bandwidth sizes. Several supported modulations are listed in 802.16 [34] and further allowed parameters are added in 802.16e extension [36]. There are two transmission duplex schemes: Time Division Duplex (TDD) and Frequency Division Duplex (FDD) defined for 802.16 networks. Although both are specified, it appears that most existing devices use TDD, due to the fact that it allows assymetric uplink/downlink ratio (subscribers are expected to download much more information than transmit). Therefore discussed analysis uses TDD. Each OFDMA radio channel is split into number of subchannels in the 802.16 protocol. Transmission is organized as repeating periods called radio frames. Each frame allows transmission of number of symbols. Very common, although technically incorrect, approach is to use symbols to express time on a sub-frame timescale. Transmission can occur on several subchannels simultaneously. Radio frame can be visualized as two dimensional array, with symbols/time on first axis and subchannel number on second. Each intersection of symbol/subchannel value is called slot. Slots can be allocated for transmission. Slots allocated for one transmission must form a rectangle in the symbol/subchannel space. Fig.8 and9 depicts such example allocations for downlink and uplink, respectively. Overall OFDMA frame structure is explained in Fig.7. For details regarding radio frame construction, see [87].

Table 1: 802.16 OFDMA PHY parameters, used in simulation

Parameter Value Proﬁle OFDMA ProfP3 Channel bandwidth 7MHz Radio frame 5ms Symbols per radio frame 48 Subchannels 16 Modulation QPSK 1/2 Radio frame split (uplink/downlink) 1:1 Bytes per slot 12

As simulation was focused on 802.16 control plane and IPv6 layer, investigating different parameter sets of 802.16 layer was not the priority. Therefore the same set of parameters was used throughout all simulations. Those parameters are defined in Table1. Efficiency analysis 53

Figure 8: Mapping OFDMA slots to subchannels/symbols in downlink. Time intervals are represented by OFDMA symbols. Available frequencies are split into subchannels. Those two axes form two dimensional plane. One unit is called a slot. Each slot spans one subchannel and one or more (2 in the presented example) OFDMA symbols in the time axis. Each downlink transmission allocates one or more adjacent slots. Slots are allocated with increasing subchannel index. When edge of Data Region is reached, mapping in continued from the lowest numbered OFDMA subchannel in the next available symbol. This image was taken from [36] 54 Eﬃciency analysis

Figure 9: Mapping OFDMA slots to subchannels/symbols in uplink. Similar approach is used as in downlink, with the notable diﬀerence in slot deﬁnition. In uplink, each slot spans one or more subchannels and one or more OFDMA symbols in the time axis (3 in the presented example). Each uplink transmission allocates adjacent slots with increasing subchannel index. Once UL zone boundary is reached, mapping is continued from the lowest numbered OFDMA symbol in the next available subchannel. This image was taken from [36]

4.1.4. Mobility model

Several mobility models were implemented in Numbat environment.

1. Fixed. Subscriber stations are not moving. This type may be used as a reference: ideal, lossless, always connected station or as an easy way to generate background traﬃc.

2. Time-triggered. In this model, handover occurs after certain timeout after previous handover is complete. Although this approach does not model real scenario very closely, it is excellent for the handover procedure studies. Target base station is selected iteratively. Eﬃciency analysis 55

3. Distance based. In this approach, subscriber changes its physical location and periodically performs scanning to discover nearest base stations. Once base station with better properties is discovered via scanning, handover procedure is initialized. Two types of traﬃc paths are supported: moving along a straight line and moving around in a circle. Careful selection of base and subscriber stations’ locations are required as it directly aﬀects handover process (or lack of thereof).

4. Random time-triggered. This approach is similar to the time-triggered model. Subscriber station initiates next handover after certain period since last handover has passed. The diﬀerence is that the next base station is chosen randomly from the full list of all base stations. To ensure actual handover, current serving base station is excluded from the selection process.

As the main area of research in this dissertation is the handover procedure itself and not algorithm leading to the eventual handover decision, the most suitable mobility models are 2 and 4. As such, those two models are used throughout all the experiments.

4.1.5. Traﬃc models

As stated in Section (see 1.4.1), the main area of concern are multimedia applications as they are the most sensitive type of traﬃc. Therefore most models are related to multimedia streaming or multimedia related purposes. Out of wide variety of available options, following models were implemented:

• Bursty traffic – This traffic model is dedicated to generation of traffic that is variable in time.

Once every tI interval, bn packets are sent. Packets have random size from Lmin to Lmax. The

Lmin+Lmax size of packet is a truncated normal distribution, with mean L = 2 and standard deviation µ = 0.8 ∗ (L − Lmin). Lmin = 48 was selected as lower bound as this is the smallest possible IPv6 packet with useful payload – an empty UDP packet. Example values used in some scenarios are

tI = 12ms, bn = 3 and Lmax = 512. This type of traﬃc may be used to simulate VoIP connections, where certain amount of data is created in regular intervals.

• Bulk traffic – This type of traffic is intended to reflect bulk data transmission, e.g. FTP session or MPEG-2 or H.264 video streaming. It is expected that packet sizes will usually be close to maximum.

Smaller packets will also be recorded, albeit on a much smaller scale. Once every tI interval, packet of size L is being sent. There are several distributions that allow modeling such conditions. Beta distribution was chosen as most suitable. It is defined as: Γ(α + β) f(x; α, β) = xα−1(1 − x)β−1 (4.1) Γ(α)Γ(β) where Γ is defined as: Z ∞ Γ(z) = tz−1e−t dt (4.2) 0 Depending on α and β parameters used, β distribution can assume radically different shapes. Ex- amples are presented in Fig.4.1.51. For the purpose of simulating traffic discussed above, α = 8.0 and β = 0.5 was used. 1Image generated from gnuplot source, provided by Wikipedia, under GNU GPL license. 56 Efficiency analysis

2.6

2.4 α = β = 0.5 2.2 α = 5, β = 1 α = 1, β = 3 2 α = 2, β = 2 α = 2, β = 5 1.8 1.6 1.4 1.2 1 0.8 0.6 0.4 0.2 0 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Figure 10: Beta distribution can assume radically diﬀerent shapes, depending on α and β parameters used. The example taken from [111]

The actual amount of data transmitted is dependent on configured QoS parameters, namely MSR (Maximum Sustained Rate) in Best Effort traffic. However, from the handover analysis perspective, it is reasonable to use traffic that sends small packets very often as it may be used as connectivity indicator. For easier investigation of mobility related issues, no buffering or queuing mechanism of any kind was used on both subscriber and base stations. The only exception is a mandatory queue mechanism in the 802.16 MAC layer. Measurements of packet size observations and other distribution related data, including histograms, are discussed in Section 4.7.4.

4.1.6. Limitations

Every simulation provides a model of a real system. As such, it uses certain simpliﬁcations and some cases are not covered. Certain less important mechanisms are not fully implemented or provided implementation is simpliﬁed. Following list contains such notable shortcomings:

• IPv6 multicast downlink traffic is not supported. When base station intends to send IPv6 packet that is supposed to reach several or all subscribers, it may send only one copy of such message (assuming subscribers joined necessary multicast groups). In the Numbat environment, such messages are sent multiple times, one for each subscriber. This simplification is a reasonable model, as multicast traffic is considered an advanced feature and seldom supported by vendors. This causes Router Advertisement messages to be sent for each subscriber separately. This may slightly increase Efficiency analysis 57

bandwidth usage. As simulations did not operated in network congestion conditions, that should not aﬀect results is measurable way.

• No firewalls at base station. Early simulation runs (experiment 1) did not contain any firewall implementation. This caused subscriber station to continue sending uplink packets as soon as it reattached to the target base station. As a result, subscriber was sending packets with old source address. Target base station, not equipped with firewall (or source address correctness checks in routing subsystem), was forwarding this topologically incorrect traffic. Corresponding node, not aware of the mobile node’s movement, accepted packets. This may have lead to misjudged handover impact on uplink traffic. This limitation was removed after experiment 1. Following simulation runs are no longer affected by this issue (especially experiment 2, intended for uplink traffic analysis).

• 802.16 OFDMA scheduler is simpliﬁed. The actual OFDMA channel is divided into several subchannels. Transmission may be held on one or multiple channels. Real bandwidth grants are often multi-subchannel, causing stations to transmit on several subchannels simultaneously. Finding available slot for transmission is non-trivial as is requires allocation of “rectangle” in subchannel–time plane. This topic was discussed in Section 4.1.3 and presented in Fig.7. To avoid this diﬃculty, n subchannels are simulated as single n times longer channel.

• There is no 802.16 fragmentation or packing implemented. [34] oﬀers several methods of joining and splitting Service Data Units (SDUs) into one bigger chunk, sent together. This approach improves bandwidth utilization, as headers to user data ratio is improved. This mechanism is not implemented.

4.2. Random numbers generators

Computer is a ﬁnite state machine and its next state is fully determined by the previous one. Although true randomness is impossible, number of algorithms have been developed to generate stream of numbers that appear to be random. As they are not truly random, such class is often referred to as pseudo random number generators (PRNG). Although sequences that are closer to truly random can be generated using hardware random number generators, its use is limited by availability of required dedicated hardware. Depending on the expected area of application, there are several properties of a PRNG that should be taken into consideration:

• Period. That is considered the most important parameter. All PRNGs generate series of values. Such series are not inﬁnite, but rather repeat themselves. Every time a number is generated, PRNG changes its internal state. Period speciﬁes how many numbers are generated before PRNG returns to its initial state.

• Weak seeds. Initial state of the PRNG is defined by a small set of data called seed. Some PRNGs exhibit very limited capabilities for certain seeds (e.g. Middle-Square Method generates only zeros, when 0000 is used as seed.). Existence of weak seeds is considered a serious flaw for a PRNG, especially from cryptographic perspective. 58 Efficiency analysis

• Computational Complexity. Some PRNGs require longer computation for next number generation. That parameter is especially important when large quantities of pseudo-random numbers are required. That is particularly true with long lasting simulations.

• Memory requirements. As most other algorithms do, also PRNGs require memory to store its internal state. As modern computers have signiﬁcant amount of memory available, this property is rarely an issue.

• Warm-up period. Each PRNG requires initial value called seed that deﬁnes initial state. Initially generated sequences of numbers sometimes lack required statistical properties and thus fail random quality tests [64, 61]. Some PRNGs begin to generate high quality number sequences faster than others. Such PRNG are said to be getting started quicker. Such PRNGs are considered more useful.

Achieving as long sequence as possible is not the only criteria during proper PRNG selection. Equally, or even more important, is the requirement of consecutive numbers to be uniformly distributed. There are numerous tests defined to assess PRNG quality in that matter. See [10] for quality assessment methodology. Two well known and respected test suites are Diehard by prof. George Marsaglia [64] and TestU01, developed L’Ecuyer and Simard [61]. Algorithms for numerous PRNGs are known and publicly available. Historically, the first algorithm, called Middle-square method, was proposed by John von Neumann in 1946 [112]. It has many flaws, very short sequence, weak seeds that produce constant output and others. Its only advantage was that is was quick and didn’t require any of the precious memory resources, used at that time. This method is no longer in use. Until recently, the most common class of PRNGs was Linear Congruential Generators (LCG). This class is particularly well studied [10, 27, 53]. Although interesting, and useful for simple applications, this class generates sequences that have many flaws, as pointed in [27] with predictability being one of the most severe. Also, sequence length is often no longer than 232 − 1. Although [59] proposed LCG of the order higher than 1, which is expected to have sequence (231)5 − 1 long, its statistical properties were not verified. Linear Feedback Shift Registers (LFSR) is another class of PRNG. It is also very well studied [54, 12, 58] and number of approaches was proposed to improve their properties [60, 91]. There are also other algorithms known for producing very long pseudo-random sequences. Lagged Fibonacci generator is an interesting concept that offer improved sequence lengths. There are multiple versions and modifications of this algorithm, e.g. proposed in [94] or [3]. Unfortunately, proper LFG initialization is a very complex problem. Also, potential issue with LFGs is that mathematical theory behind them is incomplete. Therefore it is necessary to rely on statistical tests rather than theoretical performance. Due to those properties, LFGs are not commonly used.

4.2.1. Mersenne Twister

A new class of algorithms called Mersenne Twister was proposed in 1998 [65]. It was specifically designed to avoid many of the problems with earlier generators. Notable feature of Mersenne Twister is its colossal period of 219937 − 1, is proven to generate uniformly distributed values in up to 623 dimensions Efficiency analysis 59 and runs faster than other statistically reasonable generators [109]. Mersenne Twister is quickly becoming the pseudo-random number generator of choice in many applications and used as a default in R, Matlab analysis tools and also scripting languages like Python or Ruby. Due to its very low memory requirements (around 2 kilobytes) it is preferred PRNG in almost any environment, except small embedded devices with severe memory limitations. The most important reason for choosing Mersenne Twister as PRNG in experiments conducted by author was its extremely long period, good equidistribution and excellent results of tests using TestU01 library [62]. Using PRNG with too short period may cause simulation (during consecutive runs or even during one run) start repeating sequence. This would prevent simulation results from being independent. Also, generators with poor equidistribution would cause favor set of specific values or ranges that would impact simulation credibility. Example of comparison of two PRNGs (RANDU, proposed in [55] and Mersenne Twister) are presented in Fig. 11.

Figure 11: Comparison of two Pseudo-random Number Generators. Sequences generated by RANDU, proposed by [55], are correlated and have poor equidistribution (left diagram). Mersenne Twister has uniformly distributed numbers in its sequence (right diagram). Diagram taken from [16].

4.2.2. PRNG Sequence length

Thorough validation of over 100 diﬀerent PRNGs is provided in [62] with Mersenne Twister getting excellent results. This section only serves as a simple illustration of scale of available sequence length. Mersenne Twister was used in simulation environment. To roughly assess if its period is adequate, following simple evaluation was undertaken. Modern PC hardware, equipped with recent Intel Core 2 Quad 9300 processor, featuring 4 cores was used to execute all simulations [45]. Following equation can be used to calculate upper bound of CPU eﬃciency in generating pseudo-random numbers:

N ∗ σ Ω = cores ∗ (1 − µ) (4.3) IPS ∗ IRND Where Ncores is number of cores in the system; σ is a clock of each CPU core; IPS is a number of clock ticks required to process one instruction; IRND is a number of instructions required to generate next pseudo-random number; µ is system overhead (i.e. percentage of available system resources that are used by operating system and background tasks). 60 Eﬃciency analysis

Assuming following conditions:

• Full use of processing power for simulation σ = 2.5 ∗ 109;

• Each core is capable of running 1 instruction in every cycle (IPS = 1);

• Generation of one pseudo-random number takes only 1 instruction (IRNG = 1);

• Every instruction executed by CPU is used exclusively for pseudo-random number generation;

• There is no communication overhead between cores;

• Operating system does not use any resources and there are no other processes running (µ = 0);

used CPU is capable of generating 10 billion random numbers per second2. To consume full Mersenne Twister sequence, one would still require about 2, 8 ∗ 105985 years of calculations. As age of universe is considered to be 1, 38 ∗ 1010 years old, from the practical perspective it can be safely assumed that there is no chance to exhaust full sequence of numbers, regardless of time horizon selected.

4.2.3. Assured simulations independence

Even with such extremely long period of Mersenne Twister, there is still danger of using exactly the same initial seed in repeated simulations. This would cause PRNG to produce exactly the same stream of numbers, causing correlation between simulation runs. To avoid this unwanted correlation, diﬀerent seeds were used. OMNeT++ environment provides convenient automatic selection of unique seeds. For each simulation run, seed is deﬁned as

seed = RunNumber ∗ Num (4.4)

where Num is total number of simulations. According to author’s knowledge, although no one has proven that seeds 0, 1, 2,... are well apart in the sequence, this is probably true, due to extremely long sequence of Mersenne Twister. See [104] for short discussion regarding this issue.

4.3. Experiment results methodology

During simulation various parameters were measured. This section describes uniﬁed methodology used to process raw simulation results, discusses used methods and ways of extracting useful information.

4.3.1. Selecting sample sizes

Although general methods of selecting sample sizes are well known [10, 28, 50], they are described here for the sake of completeness of experiment and results description. By studying properties of ﬁnite sample of inﬁnite population, conclusions can be drawn regarding properties of the whole population. To estimate parameter values with desired accuracy, certain assumptions

2Note that this upper estimation is greatly exaggerated. Efficiency analysis 61 are required. As exact value is not computable or measurable, statistical approach must be used. One can say with confidence α that an estimated value Θˆ n does differ from the real value Θ no more than absolute error , where Θˆ n is an estimation of real value Θ, based on observation on n samples. This requirement is formally described as follows:

P (|Θˆ n − Θ| ¬ ) 1 − α (4.5)

According to [6], in general case, the absolute error is equal to standard deviation of mean values in sample set, multiplied by value of distribution zα for deﬁned α and n:

σ = z √ (4.6) α n By solving equation 4.6 for n, the following equation is obtained:

z2 σ2 n α (4.7) min 2 As exact variation σ for the whole population is unknown, it has to be estimated. There are several estimators for variance in ﬁnite subset of inﬁnite population. The following estimator was used during results processing: Pn (X − X)2 Sˆ2 = i=1 i (4.8) n − 1 Main advantages of this estimator are its simplcity, and its consistent and unbiased properties. Fur- thermore, depending on size of the sample n, for smaller sets Student’s t-distribution tα,n0−1 may be used instead of zα. Although there are no sharp criteria, there is a general recommendation that any set with at least 30 observations is considered large [107].

Finally, using equation (4.8) and discussed assumptions, minimal number of samples nmin required for estimation error no greater than is expressed by equation (4.9).

t2 Sˆ2 n = α,n−1 (4.9) min 2

4.3.2. Warm-up period

The proper determination of simulation warm-up time is one of crucial steps for ensuring simulation credibility. There are numerous methods for choosing length of the warm-up time. One of the simplest methods is to observe measured value. Once this value stops increasing or decreasing with increasing number of observation and begins oscillation instead, warm-up period finishes and steady state is reached. Another approach was mentioned in [97]. First observation that is neither minimum nor maximum of the rest of observations may be considered beginning of the steady state. Following less crude approach, originally proposed by [97] was adopted and modified. Let there be a sequence of n independent and identically distributed random variables X1...Xn, each having finite values of expected value µ and variance σ2 > 0. Central limit theorem [10] states that with increasing n, the 62 Efficiency analysis distribution of the sample average of these random variables approaches normal distribution with a mean µ and variance σ2/n irrespective of the shape of original distribution.

Let the sum of n random variables be Yn, given by Yn = X1 + ... + Xn. Then, deﬁning a new random variable Y − nµ Z = n √ (4.10) n σ n

The distribution of Zn converges towards standard normal distribution N(0,1) as n approaches ∞. Another random variable may be introduced: Pn X Y = i=1 i (4.11) n n

Following conditions apply to Y n. Expected value is estimated as:

EY n = µ (4.12) and estimated variation is deﬁned as follows: σ2 2Y = (4.13) D n n Applying those conditions to sample, following equation emerges: σ s = √ (4.14) n where µ and σ are expected value and standard deviation of the sampled distribution, respectively. Fol- lowing linear equation can be obtained:

log s = −0.5 log n + log σ (4.15)

Therefore, if the simulation approaches steady state, the standard deviation of samples plotted against log(n) should begin steady decrease. Rate of that decrease should be tangential to line with −0.5 slope. This point defines end of the warm-up period and is often referred to as cut-off point. If fluctuations in samples are high, it may be difficult to spot curve’s trend. Therefore moving average algorithm was used to smooth out high frequency fluctuations. For each sample, number of previous and following values was averaged. The moving average of length 2k + 1 is as follows:

( (2k + 1)−1 Pn+k x if n k + 1 x = i=n−k i (4.16) n −1 P2n−1 (2n − 1) i=1 xi if n < k + 1 The value of k should be not too high, as this would blur long term trend, but large enough to smooth out short term disturbances. After applying moving average algorithm to obtained samples and applying methods discussed above, standard deviation for n observations was plotted against log n. Two examples of such diagrams are presented in Fig.12 and Fig.13 for downlink and uplink traﬃc, respectively. Other examples are presented and discussed in later parts of this chapter. Eﬃciency analysis 63

4.3.3. Trend estimation

Overall data throughput cannot be measured directly, only its transient values can. Values of traﬃc received so far on mobile node (downlink) or corresponding node (uplink) are measured instead. Naive approach is to simply divide received number of bytes by time required to receive them. This, however, provides reliable information only for instants in time when packets were received. To gain better understanding of a throughput as a continuous process, trend estimation is required.

Figure 12: Downlink warm-up period analysis. Standard deviation of downlink traffic is plotted against log(n). Initial warm-up period contains erratic changes. After stabilization (around log(n) = 3, 24, marked with vertical dotted line), standard deviation begins steady decrease with increasing number of samples (n). Similar to uplink, also downlink traffic is measured in intervals no greater than 12ms. Traffic generation begins 1500 milliseconds after simulation start. In scenarios Scn1 to Scn5 initial configuration is completed after traffic generation starts. As subscriber is not configured yet, not traffic can be handled. This results in initial traffic measurements being exactly zero. As a direct result, also standard deviation is zero. This effect is most visible in scenarios Scn1 and Scn2. “Skip initial delay” mechanism, introduced in scenario 3, limits this initial no traffic period (see Scn3 and Scn4). Individual scenarios are described in Section 4.5. Downlink traffic analysis is available in Section 4.7.1 64 Efficiency analysis

Figure 13: Uplink traffic warm-up period analysis. Standard deviation of uplink traffic is plotted against log(n). Warm-up period contains erratic changes. After stabilization (around log(n) = 2, 86, marked with vertical dotted line), standard deviation steadily decreases with increasing number of samples (n). Amount of sent traffic is recorded no rarer than once every 12ms as samples are collected every time packet is sent or received by IPv6 layer. Traffic generation begins 1500 milliseconds after simulation start. In scenarios Scn1 to Scn4 network entry and initial IPv6 configuration takes longer than generator delay. Therefore plots for those scenarios indicate no deviation in beginning phase as all initial measurements are exactly zero. After initial configuration is complete, regular traffic starts and standard deviation begins to fluctuate. Individual scenarios are described in Section 4.5. Uplink traffic analysis is available in Section 4.7.2

Let xi be amount of traffic sent or received so far at specified time ti. In a perfect case, mobile node transmits and receives constant amount of data in every time period. Assuming no losses due to handover or other factors, xi = f(ti) should be linearly dependent. Therefore linear function was used for trend estimation. Least Squares Method [28] is the most frequently used approach. It provides a way to fit a best trend line to a set of observed values. The best trend line is defined as model, for which the sum of squared residuals has least value. Residual is a difference between observed value and the value given by the model:

ri = yi − f(xi, β0, β1) (4.17)

where β0 and β1 are model parameters. In cases, where observations are expected to be linearly dependent, following model is used: Eﬃciency analysis 65

y = β0 + β1x (4.18)

Regardless of used model, distance function χ2 is determined by the following equation:

n 2 X 2 χ (β0, β1) = ri (4.19) i=1 2 In linear case, β0 is called intercept and β1 is called slope. χ function is minimized when its gradient with respect to each parameter is equal to zero. χ2 can be interpreted as a total distance of all points from trend line and lower value means better approximation. The elements of the gradient are the partial derivatives of χ2 with respect to the parameters:

2 n ∂χ X ∂ri = 2 r = 0 (4.20) ∂β i ∂β 0 i=1 0

2 n ∂χ X ∂ri = 2 r = 0 (4.21) ∂β i ∂β 1 i=1 1 After solving equations (4.20) and (4.21), the following equations emerge:

Pn i=1(xi − x)(yi − y) β1 = Pn 2 (4.22) i=1(xi − x) n n 1 X 1 X β = y − β y = y − β x (4.23) 0 n i 1 n i 1 i=1 i=1

Trend equation (4.18) with calculated β0 and β1 values on its own is not credible without several additional parameters, namely standard error of its parameters, correlation coeﬃcient and relative precision of the estimate. For discussion regarding usage and practical aspects of discussed parameters, see [50]. Standard error of a method of measurement or estimation is the standard deviation of the sampling distribution associated with the estimation method. For directly measured value it is equal to the standard deviation of the samples. For parameters that are common to the whole sample population (i.e. β0 and

β1) it is calculated from equations (4.24) and (4.25). Standard error can be considered a metric used for estimation precision of a given parameter.

s S2(r) Pn x2 S = i=1 i (4.24) β0 Pn 2 n i=1(xi − y) s S2(r) S = (4.25) β1 Pn 2 i=1(xi − x) Next important quality metric is correlation. Depending on type of analyzed data, correlation is expected to be very high (e.g. for sent or received traﬃc over time) or very close to 0 for events expected to be constant in time (e.g. for handover time that should last roughly the same amount of time, regardless of simulation time). Correlation with simulation time is a convenient way of detecting cases, when network 66 Eﬃciency analysis

(or a selected entity) performance deteriorates with time. There are several ways to measure correlation between two variables. The most commonly used is a Pearson correlation coeﬃcient. It is deﬁned as follows:

Pn i=1(xi − x)(yi − y) rxy = (4.26) pPn 2pPn 2 i=1(xi − x) i=1(yi − y) r is bound by <–1;1>. The bigger the absolute value, the more linearly dependent are the two values. Positive value indicates forward correlation, while negative indicate inverse correlation. Determination coefficient is defined as squared value of r. In a statistical analysis, it is a common practice to provide squared determination coefficient rather than r itself, as it is more convenient way of determining correlation scale. The last parameter that is used as a quality indicator of the simulation results is relative estimation precision. It is sometimes referred to as relative error. Relative precision smaller than 5% indicates that conclusions drawn from finite observation can be also applied to general population. Values in range 5% to 10% allow limited extrapolation for general population. Precision worse than 10% indicates that conclusions applied to infinite population will be unreliable. Relative estimation precision may be derived from the confidence interval (4.27) equation:

σ σ P X − U √ ¬ µ ¬ X + U √ = 1 − α (4.27) α n α n After transformation, following formula emerges:

U · σ µ U · σ P 1 − α √ ¬ ¬ 1 + α √ = 1 − α (4.28) X · n X X · n With increasing number of observations, µ/X converges to 1, so size of the conﬁdence interval is U σ determined by α√ . This factor, expressed as percentage, is the relative estimation precision: X n

t S(x) B(x) = α,n√−1 · 100% (4.29) X n − 1

4.4. Empirical data

During time of writing this dissertation, author had no access to mobile 802.16 environment with IPv6 support, much less the one with capabilities to modify its software or ﬁrmware. Therefore it was not possible to perform experiments on actual real life system, measure its parameters, augment it with proposed improvement and repeat measurements. There are parts of the 802.16/IPv6 stack that were available, however. Following subsections describe empirical data gathering process.

4.4.1. DHCPv6 measurements: the Dibbler project

There are several DHCPv6 implementations available. Dibbler code [80] was selected for measurement purposes, due to author’s familiarity with its code, open source nature and wide usage3. Dibbler’s 3Since its inception in 2003, authors received feedback from 30 countries and were contacted by numerous professionals, including RFC authors. For detailed description, see appendix B.2 Efficiency analysis 67 correctness was field tested during 3 interoperability test sessions held in Amsterdam, Vancouver and Philadelphia in 2007 and 2008. As DHCPv6 can be considered slow-paced protocol (working on seconds, minutes and hours time horizon, rather than milliseconds), default Dibbler logging capability offer time measurements expressed in y-m-d h:m:s format. For the purpose of better measurement accuracy, logging mechanism was augmented with new timestamp mechanism. It allows far better time interval measurements, expressed in microsec- onds. This feature was used for gathering information regarding message processing delays, on server, client and relays. This logging mechanism was merged to Dibbler source code and is now available in its standard distribution. For latest Dibbler version, see [80]. Brief description of Dibbler project with additional details is provided in Section B.2. Measured parameters were used to specify corresponding timers in the simulation environment.

4.4.2. Mobile 802.16 Base Station hardware

During time of writing this dissertation, mobile 802.16e hardware was not widely available. Europe’s first mobile WiMAX network was deployed in Amsterdam on June 17th, 2008 [2]. Deployed by Alcatel- Lucent, it provides city wide coverage and offers high speed Internet access. Unfortunately, there is no information whether IPv6 is supported. As of October 2009, WiMAX Forum [114] reported that there are over 500 WiMAX networks deployed in 145 countries. Unfortunately, WiMAX Forum does not provide any reports regarding commercial IPv6 deployments at this time. During his Ph.D studies, author worked at Intel Corp. and was involved in WiMAX base station development. Between years 2004 and 2007, author participated in 802.16 base station validation and gained practical experience and insight into actual hardware architecture, issues and solutions used. Un- fortunately, due to trade secrets and non-disclosure agreement, actual performance results will not be disclosed. Obtained simulation results do not conflict with the actual hardware measurements.

4.5. Simulated scenarios

Changing point of attachment in an IPv6 enabled 802.16 network is a complicated process. To thoroughly investigate it, several mechanisms were taken into consideration. Besides analyzing features included in the standards (802.16e [36], DHCPv6 [22] and Mobile IPv6 [49], also several novel proposals were investigated. Detailed description of those proposed mechanisms is presented in Chapter3. Often mechanisms are taking advantage of each other. There is often no strict “require” relation, but rather a general recommendation to first use mechanism A before enabling mechanism B. As such, they were sorted in a rough “simplest to most advanced” order. This approach also has another side effect. Instead of analyzing each mechanism separately, it is being used with previous ones. Therefore scenarios were generally prepared in an incremental manner. Details regarding every scenario are presented in following sections. Summary scenario comparison is presented in Table2. 68 Efficiency analysis

Figure 14: Initial network conditions for simulation of 20 subscribers and 4 base stations. Each subscriber has exactly one corresponding node. Note that not all subscribers are mobile

Each scenario describes subscriber, base station or network capabilities rather than exact network conditions. Parameters, such as number of subscribers, base stations or type and amount of traﬃc are deﬁned on a per experiment basis. See Section 4.6 for experiment details. Example initial subscriber station assignment to base stations was as shown in Fig.14.

Table 2: Scenario/feature matrix. Features included in a scenario are marked with letter ’y’

Feature Scn1 Scn2 Scn3 Scn4 Scn5 Scn6 Scn7 Scn8 Scn9 Scn10 wimax-optim y y y y y y y y y preference-255 y y y y y y y y skip-initial-delay y y y y y y y rapid-commit y y y y y y skip-dad y server-dad y y y y remote-autoconf y y y address-params y y remote-binding-update y

4.5.1. Scenario 1: No optimization

That is the most basic scenario, with no optimization whatsoever. Each subscriber station performs full network entry after changing point of attachment. RNG-RSP is received, SBC-REQ and SBC-RSP are exchanged. The same applies to PKM conﬁguration and registration (REG-REQ and REG-RSP) messages. Connections are recreated from scratch, using DSA-REQ, DSA-RSP, and DSA-ACK messages. Eﬃciency analysis 69

DHCPv6 client does not use any mechanisms (like preference value set to 255 or rapid-commit option) to speed up configuration process. Also IPv6 configuration is performed exactly as specified in [17, 81, 101]. Full Duplicate Address Detection procedure is performed, routing is configured via Router Advertisement messages and Binding Update procedure is initiated after new care-of address is received at destination location.

4.5.2. Scenario 2: 802.16e optimization

This scenario offers first improvement. IPv6 layer is operating as before, but there are numerous improvements in the 802.16 mechanisms. Target base station now possesses enough information to properly handle incoming subscriber. SBC-REQ/SBC-RSP, REG-REQ/REG-RSP are not exchanged. Service flows are not created form scratch, but rather its parameters (like SFID and CID) are updated during handover ranging. Thus no DSA-REQ, DSA-RSP or DSA-ACK messages are exchanged. Details regarding those improvements are discussed in Section 3.1.1.

4.5.3. Scenario 3: DHCPv6: Skip initial delay

This scenario oﬀers 802.16 improvements, introduced in scenario 4.5.2. In a classic approach, DHCPv6 conﬁguration starts after initial random delay between 0 and 1000ms. This scenario features new mechanism (or rather disables part of standard behavior) – skipping initial delay on the DHCPv6 layer. Details of this proposal are discussed in Section 3.2.1.

4.5.4. Scenario 4: DHCPv6: Preference 255

This scenario includes both previously introduced mechanisms: 802.16e mobility improvements, and initial delay in DHCPv6 is skipped. Also server preference value is set to special maximum value 255, which causes clients to end Advertise gathering phase prematurely. Details of this mechanism are discussed in Section 3.1.2.

4.5.5. Scenario 5: DHCPv6: Rapid-commit

In this scenario all previously mentioned mechanisms are enabled: 802.16e mobile improvements, skip initial delay and preference is set to 255. Also, both DHCPv6 clients and servers support and use rapid- commit option that causes servers to assign addresses and parameter immediately, rather than going with advertisement phase. This eﬀectively shortens DHCPv6 conﬁguration from 4 to 2 messages. Details are available in Section 3.1.3.

4.5.6. Scenario 6: IPv6: Skip DAD

All features discussed so far (802.16e optimizations, skip initial delay, preference set to 255 and rapid- commit option) are also present in this scenario. The diﬀerence is that Duplicate Address Detection 70 Eﬃciency analysis procedure is not performed after new IPv6 address is assigned to the client. Details of this proposal are discussed in Section 3.2.2.

4.5.7. Scenario 7: DHCPv6: Server side DAD

As skip-dad and server-side-dad are different solutions to the same problem, they are mutually exclusive. Therefore this is the first scenario that does not offer full set of previous improvements. It features 802.16e optimizations, skip initial delay, preference 255, rapid-commit option and DAD procedure executed by the server, but does not include skip DAD mechanism used in previous scenario. Details of the server-dad proposal are presented in Section 3.2.3. As server side DAD procedure is considered better solution than completely skipping DAD, all following scenarios will use server-dad, rather than skip-dad.

4.5.8. Scenario 8: DHCPv6: Remote conﬁguration

This scenario adds remote DHCPv6 configuration capability – early configuration for next location, while still being connected to previous location. Previous mechanisms are also present: 802.16e optimization, skip initial delay, preference 255, rapid-commit option and server side DAD procedure. Details of remote configuration are discussed in Section 3.2.4.

4.5.9. Scenario 9: DHCPv6: Address parameters

This scenario is similar to previous one, but extends set of available features with DHCPv6 address parameters. Addresses offered by DHCPv6 server are also supplemented with extra information regarding prefixes. This allows routing configuration to be achieved via DHCPv6. Details of addr-params proposal are discussed in Section 3.2.5.

4.5.10. Scenario 10: Mobile IPv6: Remote Binding Update

This is the last scenario. While still covering all other mechanisms and proposals (except skip-dad), it introduces the last proposal – Remote Binding Update. It requires a’priori knowledge about care-of address at destination location. Such knowledge can be gained by using remote-autoconf procedure. Therefore remote-binding-update cannot be used without remote-autoconf. Details regarding remote-binding-update proposal are discussed in Section 3.2.6.

4.6. Experiments

As 802.16/IPv6 network required significant time to stabilize, second approach discussed in Section 4.1.1 was used. For each scenario/experiment pair, one long simulation was executed, rather than number of shorter simulations. Several simulation experiments were conducted. Each simulation run featured simulation of a number of subscriber and base station, with majority of the subscribers being mobile and performing handovers. Each experiment was repeated 10 times, one for each scenario. In each simulation Efficiency analysis 71 run, various numbers of subscriber and base stations were simulated. Depending on purpose of the experiment, different traffic and mobility models were used. Summary information regarding experiments is presented in Table3. Details are discussed in the following sections. During each experiment, any given value was observed multiple times (e.g. handover delay during each handover; downlink traffic after each sent or received packet, etc.).

Table 3: Experiments summary. Most important parameters for each experiment

Experiment 1 2 3 4 Number of subscribers 20 7 20 5 Number of base stations 4 3 4 3 Simulation time [s] 60 67 1801 4800 Traﬃc model bursty bursty bursty bulk Packet interval [ms] 12 12 12 11.1 Burst size 3 3 3 1 Packet sizes [min-max] 48-512 48-512 48-512 48-1500 Mobility model time time random time random time triggered triggered triggered triggered

4.6.1. Experiment 1: Downlink measurements

Purpose of this experiment was the measurement of uplink and downlink traffic. Due to discovered issue, only downlink traffic results were used (see discussion in Section 4.1.6 regarding this limitation). 4 base stations and 20 subscriber stations were configured. 19 subscriber stations were mobile and 1 was fixed. Stations were using time-triggered mobility model. First mobile subscriber was used as test subject while remaining 19 were used as background. Fixed station also provided reference results for ideal, lossless, no-delay case. Bursty traffic with small packets was used (see Section 4.1.5 for details). Experiment was rerun 10 times, once for each optimization scenario. Each scenario was conducted for 60 seconds of simulated time. Depending on the speed of configuration efforts and readiness to receive data, from 6500 to 17600 traffic samples were collected in each simulation. During this experiment, both uplink and downlink traffic was generated. Results from this experiment were used for downlink traffic analysis in Section 4.7.1. Example state of the network after all mobile nodes completed first handover is presented in Fig.15. During this experiment, there were 432 different vectors (i.e. measured values, changing over time) recorded. Being the first large scale experiment, parameter selection was based on previous, small scale experiments. Although not execution efficient, this experiment was concluded successfully. Due to huge size, results processing (logs and result files were over 3GB) was difficult, however. 72 Efficiency analysis

Figure 15: Network conditions after ﬁrst handover wave. Each mobile subscriber chose one random base station, other than current base station. The only subscriber that is still associated with the same base station is SS[19], as it is ﬁxed

4.6.2. Experiment 2: Uplink measurements

Second experiment was conducted with uplink traffic in mind. Three base stations and 7 subscriber stations were simulated. All subscriber stations were mobile and were using time triggered mobility model. First subscriber station was used as a test subject, while remaining stations were treated as background. Mobile stations were using time-triggered mobility model. Due to stability issues encountered during experiment 1, number of samples was decreased. Although more samples were recorded by the simulation environment, in each scenario only 9335 samples were collected. Data gathering took from 31 to 66 seconds of simulated time, depending on complexity and efficiency of mechanisms used in a particular scenario. Downlink traffic was generated, but acted as a background transfer. As such, it impacted routing and 802.16 MAC queuing mechanisms, indirectly affecting uplink traffic. Results from this experiment were used for uplink traffic analysis in Section 4.7.2.

4.6.3. Experiment 3: IPv6 and DHCPv6 conﬁguration

Third experiment was conducted with handover parameters estimation in mind. Network reentry, IPv6 reconfiguration time and DHCPv6 configuration time was observed. Four base stations were handling traffic from 20 subscribers. 19 subscribers were mobile, while one was fixed. Stations were using random time-triggered mobility model. As handover itself was the main object of analysis, simulation had to be long enough to cover significant number of handovers. Simulation time was very long for that purpose. Although selected to last 1801 seconds, due to memory leaks and environment limitations no scenario reached target time. Simulation ceased at 1209s to 1596 seconds, depending on the scenario used. Both uplink and downlink traffic was generated, but its measurements were not recorded. This resulted in much smaller result files, even compared to over order of magnitude shorter experiments 1 and 2. Results from Efficiency analysis 73 this experiment are discussed in Section 4.8.

4.6.4. Experiment 4: Handover Preparation and Delay

Issues encountered during experiment 3 were resolved by several improvements and fixes in the simulation engine. As a direct result of those changes, simulation length in experiment 4 was tripled, albeit at a cost of decreasing number of stations. All but one scenario reached intended length of 4800 sec- onds4. There were 5 subscribers with 3 base stations. Once again random time-triggered mobility model was used. Bulk traffic model (see Section 4.1.5) was used. This resulted in traffic being generated using beta distribution, with maximum packet length set to 1500 bytes. Although this maximum packet size is typical for Ethernet networks, such MTU is commonly used in non-Ethernet networks. Results from this experiment were used for estimation of handover preparation time (see Section 4.8.1) and lack of communication capabilities (see Section 4.8.5).

4.7. Traﬃc impact assessment

Experiment results are discussed in this section. Several experiments were conducted, each with different objective in mind. Purpose of each experiment is discussed in each subsection. In a real life, traffic is generated by applications that are often not aware of mobility related issues. They transmit data whenever they see fit and completely ignore possible handovers or reconfigurations in progress. Therefore measuring outgoing traffic on an application layer is not good practice, as part of this traffic may not actually be transmitted due to limited communication capability during handovers. On the other hand, measuring outgoing traffic on a physical layer is also not reliable as it also includes control traffic. The best approach to this problem is to measure outgoing traffic at the corresponding node that is stationary and is always available. In a similar manner, measuring traffic generated by corresponding node does not make sense as it is always connected and is able to transmit data whenever it is required. Such traffic should be measured at the recipient mobile node’s application layer. That is the actual traffic that has reached its destination. To investigate impact of handover delays on actual throughput, two parameters were observed. Received bytes by a mobile node (referred to as “downlink traffic”) and received bytes by correspondent, fixed node (referred to as “uplink traffic”).

4.7.1. Downlink traﬃc

Downlink traffic measurements were taken during experiment 1. Parameters used for simulation are discussed in section 4.6.1. Although traffic was generated in uplink and downlink directions, this section presents results for downlink only. Uplink traffic was regarded as background traffic. Downlink traffic was recorded every time IPv6 packet was sent or received in IPv6 layer. Experiment 1 generated traffic bursts once every 12ms in both uplink and downlink directions, therefore amount of

4Scenario 6 was aborted after about 3000 seconds, which is nevertheless good result. 74 Eﬃciency analysis

traﬃc was recorded at least once every 12ms.

Table 4: Downlink traﬃc results for experiment 1. Designation explanations and result discussion is available in Section 4.7.1

Scn1 Scn2 Scn3 Scn4 Scn5 Scn6 Scn7 Scn8 Scn9 Scn10

xbegin 1737 1737 1737 1737 1737 1737 1737 1737 1737 1737

xend 7097 7097 7097 7097 7097 7097 7097 7097 7097 7097 n 5361 5361 5361 5361 5361 5361 5361 5361 5361 5361 0,5 0,5 0,5 0,5 0,5 0,5 0,5 0,5 0,5 0,5 α 0,95 0,95 0,95 0,95 0,95 0,95 0,95 0,95 0,95 0,95

nmin 2165 2368 4456 6662 2940 533 729 512 488 479 S(x) 149,7 175,7 155,6 149,9 261,6 309,5 300,4 309,9 310,2 302,4 S2(x) 22402 30861 24198 22482 68458 95775 90226 96046 96239 91447 S(z) 14 15 20 25 16 7 8 7 7 7 S2(z) 200 219 412 616 272 49 67 47 45 44

β1 12,36 16,09 13,29 12,32 36,72 60,91 58,80 61,95 62,46 60,34

β0 -123,08 -100,49 -32,46 26,52 -31,49 -87,97 -81,55 -92,05 -89,29 -87,32

Sβ1 0,0013 0,0012 0,0018 0,0023 0,0009 0,0003 0,0004 0,0003 0,0003 0,0003

Sβ0 0,5004 0,5613 0,8232 1,0785 0,6851 0,2898 0,3436 0,2834 0,2777 0,2769

tα,n−1 1,6449 1,6449 1,6449 1,6449 1,6449 1,6449 1,6449 1,6449 1,6449 1,6449 B(x) 1,43% 0,68% 1,22% 1,13% 1,19% 1,20% 1,18% 1,20% 1,19% 1,19%

rxy 0,9955 0,9964 0,9915 0,9862 0,9980 0,9997 0,9996 0,9998 0,9998 0,9998 R2 0,9911 0,9929 0,9830 0,9726 0,9960 0,9995 0,9993 0,9995 0,9995 0,9995

Simulation results are presented in Table4. Following designations were used: xbegin is a number of

the ﬁrst observation used for assessment; xend is a number of the the last observation used for assessment; n is a number of observations; is maximum allowed absolute error (expressed in KB); α is a conﬁdence

level; nmin is a minimal sample size that provides required precision and conﬁdence α; x is an mean value of x (expressed in KB); S(x) is a standard deviation of x (expressed in KB); S2(x) is a variation 2 of x (expressed in KB ); z is mean value of residual z (expressed in KB); β1 is a slope of the trend

line (expressed in KB); β0 is an intercept of trend line (expressed in KB/s); Sβ1 is a standard error of

β1 (expressed in KB); Sβ0 is a standard error of β0 (expressed in KB/s); tα,n−1 is a value of Student’s t-distribution for α and n − 1 degrees of freedom; B(z) is a relative precision of the estimate (expressed 2 in %); rxy is a Pearson’s product-moment correlation coefficient; R is a squared Pearson’s correlation coefficient. For each scenario graph of standard deviation of collected samples was plotted. Cutoff point was selected as log(n) = 3, 24, therefore first 1737 samples were discarded. Remaining samples were use for downlink traffic estimation. Warm-up cutoff point is presented in Fig.12 as a vertical dotted line. Warm-up period selection procedure is discussed in Section 4.3.2. Efficiency analysis 75

Figure 16: Downlink traffic for one subscriber in scenario 3 (preference-255). Measurements were conducted at intervals no greater than 12ms. Preference-255 optimization offers shorter handover delay, compared to scenario 1 and 2. However, lack of communication capabilities periods during handover are still clearly visible as horizontal sections of the curve. Graph presents averaged downlink traffic (100 observations presented as one point).For full results, see AppendixA. Error bars visualize relative estimation precision (B(z) parameter)

Besides numerical comparison, downlink performance was also plotted for graphical evaluation. Al- though every subscriber had conﬁgured the same bandwidth, none fully used it. That is caused by a mobility model used. Subscribers initiate next handover after certain interval after previous handover is complete. This interval is set to very low values of 3 seconds, except scenario 1, where it was set to 4 seconds. In the slowest scenarios (scenarios 1 to 4) handovers take over 2,5 seconds to complete, therefore ratio of transmission period to handover period is very low. This directly aﬀects amount of data that were transmitted.

Presenting error bars on a chart that contains several thousand samples would render the diagram completely unreadable. Therefore for sake of clarity of presentation, each group of 100 samples was averaged and this limited set was plotted. Hundred fold decrease in samples size resulted in signiﬁcant improvement in readability. The actual calculation was conducted on full sample. Example results for scenario 3 are presented in Fig.16. Scenario 10 is presented in Fig.17. Those two scenarios were selected as a good illustration of improvements between weakly optimized (e.g. Scn3) and highly optimized (e.g. Scn10) scenarios. Full results for all scenarios are presented in appendixA. 76 Eﬃciency analysis

Figure 17: Downlink traffic for scenario 10 (remote-binding-update). Measurements were conducted at intervals no greater than 12ms. Mechanisms enabled in this scenario (e.g. Remote-binding-update) offer superior handover techniques, compared to less advanced scenarios. Handover delays are no longer noticeable. For better readability only partial results are presented (from 10 to 20 seconds). Also, traffic samples were averaged (100 observations presented as a single point). For full results, see AppendixA. Error bars visualize relative estimation precision ( B(z) parameter)

4.7.2. Uplink traﬃc

Uplink traffic analysis was based on experiment 2, discussed in Section 4.6.2. Numerical results are presented in Table5. Uplink traffic was recorded every time IPv6 packet was sent or received in subscriber’s IPv6 layer. Experiment 1 generated traffic bursts once every 12ms in both uplink and downlink directions, therefore amount of traffic was recorded at least once every 12ms. Warm-up period was chosen in the same manner as for downlink. Cutoff point was selected as 2, 86, resulting in discarding first 724 samples in the warm-up phase. Remaining 8612 samples were used for uplink traffic estimation. Uplink traffic warm-up assessment was presented in Fig.13. Depending on scenario, throughput was estimated to values between 18,16KBps (Scn1: basic) to 63,92KBps (Scn:10 remote-binding-update). Due to large sample size, relative precision of the estimate B(x) was very accurate and ranged from 1, 33% to 1, 38%. Also, one can say with 95% confidence that the actual uplink traffic was within 0,5KBps of the calculated values. Furthermore, very high Pearson correlation coefficient (close to one) confirm rather obvious relation that amount of traffic transmitted is dependent on time. Efficiency analysis 77

Figure 18: User data received by mobile nodes, plotted against simulation time for all 10 scenarios. Complete simulation is presented on top, while zoomed in fragment is on the bottom. Decreasing handover time results in better handover/connectivity ratio, total throughput increases with each scenario. Data used are from experiment 1 78 Eﬃciency analysis

As an example, rapid–commit scenario was presented in Fig.21. Being the best “standard” scenario, it may be regarded as comparison scenario for proposed scenarios (Scn6 – Scn10). While handover periods are shorter compared to previous scenarios, they are still well over one second long and are clearly visible. In a larger timescale, however, traﬃc may be perceived as continuous. Proposed scenario server-dad is depicted in Fig.22. Compared with server-dad scenario, handover delays are much shorter and are barely noticeable.

Table 5: Uplink traﬃc results, obtained during experiment 2. Designations are explained in Section 4.7.1. Results are discussed in Section 4.7.2

Scn1 Scn2 Scn3 Scn4 Scn5 Scn6 Scn7 Scn8 Scn9 Scn10

xbegin 724 724 724 724 724 724 724 724 724 724

xend 9335 9335 9335 9335 9335 9335 9335 9335 9335 9335 n 8612 8612 8612 8612 8612 8612 8612 8612 8612 8612 0,5 0,5 0,5 0,5 0,5 0,5 0,5 0,5 0,5 0,5 α 0,95 0,95 0,95 0,95 0,95 0,95 0,95 0,95 0,95 0,95

nmin 3273 3549 3463 3594 4752 5434 5359 5447 5436 5433 x 608,25 640,92 651,50 659,82 888,89 1013,18 997,33 1020,03 1014,70 1016,64 S(x) 302,41 327,88 319,93 332,07 439,05 502,07 495,16 503,24 502,21 502,00 S2(x) 91449 107504 102355 110268 192767 252078 245184 253251 252218 252008 S(z) 14,35 13,75 13,64 13,86 14,69 7,13 13,09 3,12 3,52 7,82 S2(z) 205,99 189,19 186,01 192,21 215,67 50,78 171,42 9,76 12,40 61,22

β1 18,16 21,16 20,55 21,61 42,22 63,64 61,69 65,51 65,41 63,92

β0 -32,07 -65,26 -28,12 -50,74 -57,59 -100,84 -100,04 -99,02 -104,21 -93,59

Sβ1 0,0005 0,0005 0,0005 0,0004 0,0004 0,0002 0,0003 0,0001 0,0001 0,0002

Sβ0 0,3474 0,3254 0,3334 0,3323 0,3574 0,1730 0,3173 0,0761 0,0855 0,1904

tα,n−1 1,6449 1,6449 1,6449 1,6449 1,6449 1,6449 1,6449 1,6449 1,6449 1,6449 B(x) 1,34% 1,38% 1,32% 1,36% 1,33% 1,34% 1,34% 1,33% 1,33% 1,33%

rxy 0,9989 0,9991 0,9991 0,9991 0,9994 0,9999 0,9997 1,0000 1,0000 0,9999 R2 0,9977 0,9982 0,9982 0,9983 0,9989 0,9998 0,9993 1,0000 1,0000 0,9998

4.7.3. Traﬃc comparison

It is essential to stress out that faster handover does not make device “faster” in sense of ability to transmit or receive more data. This observed property is a side effect of mobility model used and should be treated as such. This phenomena can be observed on diagram presented in Fig.18. The most important parameter presented in Tables4 and5 are β1 values. That parameter represents the real throughput in uplink and downlink, respectively. The same traffic model, but exercised on fixed subscriber, yielded result of 68,05KBps for downlink and 68,10KBps for uplink. This ideal, no loss scenario was used a reference to calculate losses introduced by mobility. Results are presented in Fig. 19 for downlink and Fig. 20 for Efficiency analysis 79 uplink. Theoretical limit was marked with the bar outline, above red bars.

Figure 19: Downlink traffic efficiency. Each scenario is compared to fixed, ideal, no-loss scenario. Actual traffic is marked with solid bars, while theoretical level is marked with transparent outline areas. Loses decrease with increasing number of enabled optimizations. Data expressed in kilobytes per second

Figure 20: Uplink traffic efficiency. Each scenario is compared to fixed, ideal, no-loss scenario. Actual traffic is marked with solid bars, while theoretical level is marked with transparent outline areas. Loses decrease with increasing number of enabled optimizations. Data expressed in kilobytes per second. 80 Efficiency analysis

Figure 21: Uplink traﬃc for scenario 5 (rapid-commit). Although all improvements available in standard protocols are enabled, periods of no–communication are clearly visible as horizontal lines. See Fig. 22 for comparison with the server-dad scenario

Figure 22: Uplink traffic for scenario 6 (server-dad). First proposed improvement caused significant improvement over “best standard” (rapid-commit) scenario. Handover periods are still visible, but are much smaller, compared to scenario 5 (see Fig. 21) Efficiency analysis 81

4.7.4. Packet size distribution

Two traffic models were used throughout the experiments. Theoretical models are described in Section 4.1.5. First model could be described as bursty traffic. According to this model, packets are generated together, in groups (“a burst”). Size of each packet has normal distribution, albeit with sharp upper and lower bounds defined. Example realization of this traffic is presented in Fig. 23. Samples were recorded during experiment 3. In experiments 1-3, where this type of traffic was used, lower bound was 48 and upper bound was 512.

Figure 23: Truncated normal traﬃc histogram. This distribution of packet sizes is used in bursty traﬃc model. Packet sizes expressed in bytes, range from 48 to 512

Another traffic model is used to simulate bulk traffic, like file transmission or video streaming. In this case packets often have maximum size, with smaller packets being rather uncommon. Histogram of packet sizes for this type of traffic is presented in Fig.24. Data was gathered during experiment 4.

4.8. Handover oriented results

Parameters related to handover time measurements were collected during experiments 3 and 4. Details of those experiments are discussed in Sections 4.6.3 and 4.6.4, respectively. Due to assumed handover model (next handover initiated 3 seconds after previous one was completed on 802.16 layer), simulation time had to be very long (in the order of thousands seconds) to collect reasonable number of handover related measurements. 82 Eﬃciency analysis

Figure 24: Beta traﬃc histogram, generated from packet size observations during experiment 4. This distribution of packet sizes is used in bulk traﬃc model. Packet size ranges from 48 to 1500, with probability of given size increasing exponentially

4.8.1. Handover preparation

During handover preparation period, mobile station maintains full communication capability. As such, it is desirable, but not critical to shorten this phase as much as possible. Handover preparation time is deﬁned as a time between decision to initiate handover procedure to actually leaving current base station. In an 802.16 environment, such deﬁnition is bound by CDMA code transmission (initial request for bandwidth for following handover control messages) and actual HO-IND message transmission.

Measurements were conducted during experiment 4, described in Section 4.6.4. Handover preparation appears to be stable and does not vary between scenarios that do not use remote-autoconf functionality (scenarios 1 – 7) and its HD metric oscillates around 102ms. Those cases also have very low standard deviation of just 10ms to 11ms. As a direct result, estimation is very precise: absolute error no greater than 1ms with 95% confidence. Such precision required significant sample size (287 – 315). Relatively large jitter introduced by packets traveling via backbone in scenario 8 to 10 caused significantly larger standard deviation – 76ms to 79ms. As a result, number of required samples was bigger (438 to 466), even though maximum error was increased to 6ms. Numerical results were presented in Table6.

Analysis of β1 value and Pearson coefficient confirms that handover preparation time is not correlated with simulation time. Important observation is that introduction of remote-autoconf adds over 200ms of extra preparation time. That is to be expected as remote-autoconf optimization performs vital steps of reconfiguration in advance. Compared to classical handover, this results in longer preparation, but shorter actual handover. It should be noted that this change does not increase HD metric. Efficiency analysis 83

Figure 25: Handover preparation time in a “best standard” scenario (rapid-commit, Scn5). Each point represents single observation of handover preparation time. Values are clearly quantized by 802 radio frame length, that was equal 5ms in all experiments

Figure 26: Handover preparation time in a remote-autoconf scenario (Scn8). Preparation time is aﬀected by round trip time to destination location, as required by remote-autoconf procedure. In congestion conditions, that can occasionally lead to increased preparation time 84 Eﬃciency analysis

As handover preparation is not dependent on time, linear regression results in almost ideally horizontal

line (β1 ≈ 0) with β0 deﬁning mean value of observations. Therefore β0 parameter may also be used handover preparation estimation. Its values are closely matching samples mean (x). For scenarios 1–7 the diﬀerence is no larger than 0.003s. For scenarios 8 and 10 it is exactly 10ms. The only noticeable

diﬀerence is observed for scenario 9 (x equals 488ms, while β1 equals 540ms). Likely explanation of this discrepancy is a packet delay irregularity introduced by remote-autoconf mechanism. Investigation, why this did not aﬀect scenarios 8 and 10, may provide additional information.

Table 6: Handover preparation time. Data gathered during experiment 4. Designation explanations are available in Section 4.8.1

Scn1 Scn2 Scn3 Scn4 Scn5 Scn6 Scn7 Scn8 Scn9 Scn10

xbegin 28 28 28 28 28 28 28 28 28 28

xend 979 1411 1387 785 887 1215 792 486 1409 1211 n 952 1384 1360 758 860 1188 765 459 1382 1184

nmin 298 298 285 315 287 299 306 441 466 438 0,001 0,001 0,001 0,001 0,001 0,001 0,001 0,006 0,006 0,006 x 0,101 0,101 0,103 0,101 0,103 0,103 0,101 0,318 0,319 0,320 S(x) 0,010 0,010 0,010 0,011 0,010 0,010 0,011 0,076 0,079 0,076 S2(x) 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,006 0,006 0,006

β1 -9,2E-8 -8,8E-8 2,6E-7 9,7E-7 4,0E-7 4,9E-8 -2,7E-7 9,4E-6 2,2E-6 1,3E-6

β0 0,101 0,101 0,103 0,099 0,103 0,103 0,101 0,309 0,314 0,317

Sβ1 0,0324 0,0269 0,0321 0,0363 0,0341 0,0290 0,0362 0,0466 0,0269 0,0291

Sβ0 0,0033 0,0027 0,0028 0,0037 0,0035 0,0030 0,0037 0,0153 0,0088 0,0096

tα,n−1 1,6465 1,6460 1,6460 1,6469 1,6466 1,6461 1,6468 1,6482 1,6460 1,6461 B(x) 0,56% 0,46% 0,44% 0,64% 0,56% 0,49% 0,63% 1,85% 1,09% 1,14%

rxy -0,0119 -0,0114 0,0342 0,0721 0,0317 0,0058 -0,0182 0,0623 0,0387 0,0214 R2 0,0001 0,0001 0,0012 0,0052 0,0010 0,0000 0,0003 0,0039 0,0015 0,0005

Following designations were used in Tables6,7,8,9 and 10: xbegin is the ﬁrst observation used for

assessment; xend is the last observation used for assessment; n is a number of observations; is maximum

allowed absolute error (expressed in seconds); α is a conﬁdence level; nmin is a minimal sample size that provides required precision and conﬁdence α; x is an mean value of x (expressed in seconds); S(x) is a 2 standard deviation of x; S (x) is a variation of x; z is mean value of residual z; β1 is a slope of the trend

line (expressed in seconds); β0 is an intercept of trend line (no units); Sβ1 is a standard error of β1; Sβ0

is a standard error of β0; tα,n−1 is a value of Student’s t-distribution for α and n − 1 degrees of freedom; 2 B(z) is a relative precision of the estimate; rxy is a Pearson’s product-moment correlation coefficient; R is a squared Pearson’s correlation coefficient. Due to similar value ranges in scenarios 1–7, it is not possible to present them in a readable form on one graph. Therefore only two scenarios were selected for presentation in this chapter. Remaining, complete Efficiency analysis 85 results are available in AppendixA. Graph of handover preparation time measured in scenarios 5 and 8 are presented in Fig.25 and Fig.26, respectively. Measured values of handover preparation intervals are not continuous, but rather quantized. Both scenarios exhibit this property, but it is much more visible in scenarios 1 through 5, due to smaller absolute values. Those “quantization levels” are determined by length of 802.16 radio frame length that was set to 5ms in all simulation scenarios. Therefore value of handover preparation time is always multiplicity of 5ms. In scenario 8 values occasionally differ significantly from average. That is caused by occasional congestion conditions, both in serving and target base stations MAC layers and the backbone network itself.

Figure 27: Standard deviation of handover preparation time. It is very low for scenarios 1-7. Unfortunately, as delays introduced by backbone round trip times are often an order of magnitude higher than those observed during 802 handover preparation procedure, standard deviation of the whole procedure is quite erratic for scenarios that include remote autoconﬁguration (Scn8-Scn10). Such disturbances are occasionally seen past warm-up period. Cut-oﬀ point was chosen at log(n) = 1.45, therefore initial 28 observations were discarded

Selection of warm-up period for handover preparation time proved to be difficult. Standard deviation of handover preparation measurements is presented in Fig.27. Although scenario 1–7 have very low deviation, convergence in scenarios with remote-autoconf exhibit occasional disturbances. That is likely caused by remote autoconfiguration (enabled in scenarios 8 through 10). As packets travel via backbone, they are susceptible to network congestion events that may introduce delays of the order of magnitude larger than average measured value. Therefore occassional bumps are observed in those scenarios. Convergence visibility would be better in a longer simulation. Unfortunately, due to limitations discussed in Section 4.6.3 further increase in simulation time was not possible. 86 Efficiency analysis

Figure 28: Handover preparation time. Estimations are almost equal for scenarios Scn1–Scn7. Remote auto- conﬁguration, introduced in scenario 8 causes additional delay in preparation phase, as destination location must be contacted before handover is commenced

Finally, estimation of handover preparation values were presented in Fig. 28. The only optimization feature that ever aﬀected this parameter was remote-autoconf, introduced in scenario 8. Although not desirable, such increase is not very troubling, as subscriber maintains connection capability during this period. Therefore end user’s experience is not directly aﬀected and HD metric retains its value of 0 ms. Yet prolonging preparation time may cause 802.16 signal strength and quality to degrade to a level where successful transmission and reception will no longer be possible. As this dissertation focuses on handover procedure itself and not the algorithms that lead to handover initiation, this issue is outside of scope of this thesis. The easiest solution to this hypothetical problem would be to modify handover decision algorithm to be remote-autoconf aware. When remote-autoconf is enabled, handover initiation should be triggered earlier.

4.8.2. Network Reentry Time

The next step after mobile station detaches from serving base station, is network reentry at target base station. This parameter is measured from the HO-IND transmission at source location to the finish of service flow connections at target base station. During this procedure, subscriber is not able to send or receive user traffic, therefore this is the first interval during handover that actually affects end user.

The only improvement that affects that 802.16 specific phase are mechanisms introduced in scenario 2. They are part of the 802.16e-2005 [36] extension to the 802.16 protocol. Depending on approach used to estimate reentry time (averaged value or regression), its HD metric is decreased by 514ms or 507ms. As mechanisms introduced in later scenarios are applicable for IP layers, they do not affect network reentry on the 802.16 layer. Efficiency analysis 87

Figure 29: Network reentry time. It is nearly equal for all scenarios that include 802.16 network entry optimizations (scenarios 2-10). Available and proposed improvements on the IPv6 layer do not aﬀect 802.16 network reentry operations

Table 7: Network reentry time measurements. Designation explanations are available in Section 4.8.1. Data from experiment 3

Scn1 Scn2 Scn3 Scn4 Scn5 Scn6 Scn7 Scn8 Scn9 Scn10

xbegin 2 2 2 2 2 2 2 2 2 2

xend 432 466 465 466 417 380 380 397 364 416 n 431 465 464 465 416 379 379 396 363 415

nmin 429 40 44 42 41 47 49 26 28 25 0,004 0,004 0,004 0,004 0,004 0,004 0,004 0,004 0,004 0,004 x 0,595 0,081 0,076 0,079 0,082 0,076 0,077 0,088 0,087 0,087 S(x) 0,050 0,015 0,016 0,016 0,015 0,017 0,017 0,012 0,013 0,012 S2(x) 0,003 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000 0,000

β1 1,6E-5 7,8E-6 -5,5E-6 -8,6E-6 1,8E-5 9,1E-6 3,3E-6 -1,3E-6 6,9E-7 -3,7E-6

β0 0,582 0,075 0,080 0,086 0,070 0,070 0,075 0,089 0,087 0,089

Sβ1 0,0477 0,0453 0,0460 0,0451 0,0441 0,0505 0,0513 0,0503 0,0525 0,0487

Sβ0 0,0285 0,0037 0,0036 0,0036 0,0037 0,0039 0,0041 0,0045 0,0046 0,0043

tα,n−1 1,6484 1,6481 1,6481 1,6481 1,6485 1,6489 1,6489 1,6487 1,6491 1,6485 B(x) 0,67% 1,45% 1,61% 1,51% 1,51% 1,86% 1,85% 1,16% 1,26% 1,12%

rxy 0,1536 0,2198 -0,1457 -0,2352 0,4409 0,1902 0,0674 -0,0442 0,0205 -0,1323 R2 0,0236 0,0483 0,0212 0,0553 0,1944 0,0362 0,0045 0,0020 0,0004 0,0175

Numerical results for handover reentry are presented in Table7. It can be said with 95% confidence, 88 Efficiency analysis that exact values of reentry times are no different that 4ms from the estimated value. Quick analysis of Pearson coefficient and β1 values strongly indicate that reentry time is not dependent on simulation time. Due to steady measurements, variation is very low. This leads to a very good estimation precision – between 0,67% and 1,86%. Summary values for each scenario are presented in Fig.29.

4.8.3. IPv6 Reconﬁguration time

After network reentry is complete, IPv6 address has to be reconﬁgured. Length of this procedure may be called IP reconﬁguration time. It is measured from the completion of network reentry till completion of Location Update procedure. That procedure also concludes the whole handover process.

Table 8: IPv6 reconﬁguration measurements, based on data from experiment 3. Designation explanations are available in Section 4.8.1

Scn1 Scn2 Scn3 Scn4 Scn5 Scn6 Scn7 Scn8 Scn9 Scn10

xbegin 2 2 2 2 2 2 2 2 2 2

xend 425 454 457 459 418 381 381 398 365 417 n 424 453 456 458 417 380 380 397 364 416

nmin 281 409 454 414 90 51 52 55 52 47 0,020 0,020 0,020 0,020 0,020 0,020 0,020 0,020 0,020 0,020 x 2,401 2,438 2,463 2,449 1,359 0,315 0,313 0,237 0,242 0,241 S(x) 0,203 0,245 0,259 0,247 0,114 0,086 0,087 0,090 0,087 0,083 S2(x) 0,041 0,060 0,067 0,061 0,013 0,007 0,008 0,008 0,008 0,007

β1 1,5E-5 5,9E-5 -3,3E-6 -5,2E-5 2,0E-5 -9,8E-6 -3,6E-6 -4,7E-6 3,6E-6 -2,3E-5

β0 2,39 2,39 2,47 2,49 1,35 0,32 0,32 0,24 0,24 -0,26

Sβ1 0,0486 0,0468 0,0469 0,0466 0,0489 0,0513 0,0514 0,0502 0,0525 0,0488

Sβ0 0,1171 0,1147 0,1161 0,1147 0,0667 0,0167 0,0167 0,0128 0,0135 0,0124

tα,n−1 1,6485 1,6482 1,6482 1,6482 1,6485 1,6489 1,6489 1,6487 1,6491 1,6485 B(x) 0,68% 0,78% 0,81% 0,78% 0,68% 2,31% 2,36% 3,13% 3,10% 2,80%

rxy 0,0332 0,1025 -0,0054 -0,0900 0,0685 -0,0400 -0,0147 -0,0215 0,0155 -0,1156 R2 0,0011 0,0105 0,0000 0,0081 0,0047 0,0016 0,0002 0,0005 0,0002 0,0134

Similar to previous properties, also this essential parameter was measured during 10 simulation runs, one for each scenario. Data were collected during experiment 3, described in Section 4.6.3. Number of samples required for assumed precision are much smaller than actual collected sample set. Therefore one can say with 95% confidence that real value of this parameter differs no greater than 20ms from estimated value. Averaged values are similar to those obtained from linear regression. First three scenarios exhibit reconfiguration time around 2400ms. The first improvement is offered with introduction of rapid-commit (scenario 5), when HD metric is decreased to around 1350ms. The next significant optimization is observed when skip-dad (scenario 6) is enabled. In such case, IP reconfiguration time (and so is HD metric) is limited Efficiency analysis 89 to 315ms. Similar results were obtained in scenario 7 (server-dad). That is an expected outcome, as skip- dad and server-dad are functionally identical. The last, smallest shortening of this process is observed with introduction of remote autoconfiguration in scenario 8 and HD metric remains stable for the remaining scenarios (around 240ms).

To discard initial measurements in phase, where simulation is unstable, standard deviation of measured values were plotted (Fig.30). Values do not increase or often decrease with increasing number of samples. This indicates that from the IP reconfiguration time, there is actually no warm-up time required and all samples may be used as the core sample set. However, to avoid influence of initial state of the simulation, first sample for each scenario was discarded anyway.

Relative estimation precision is excellent for first 5 scenarios (ranging from 0,68% to 0,81%) and very good for remaining cases (2,31% to 3,10%). Assumed parameters for absolute errors (confidence level 95%, absolute error no greater than 20ms) show that gathered sample set is sufficient in all cases. Final IP reconfiguration time is presented in Fig.31. To visually present differences in reconfiguration, sample values for three selected scenarios were presented in Fig.32. Numerical results were presented in Table8. Complete results for all scenarios are presented in AppendixA.

Figure 30: IPv6 reconﬁguration time warm-up selection. Measured values indicated that it is almost completely independent of network conditions. There is no noticeable warm-up time as standard deviation of measured samples begin to decreases from the beginning of the simulation 90 Eﬃciency analysis

Figure 31: IPv6 reconfiguration time. Scenarios can be split into 3 separate groups from the IPv6 reconfiguration perspective. First, least efficient group is the one that offers up to skip-initial-delay optimization. Optimizations used in those scenarios (1-4) do not offer any noticeable IPv6 reconfiguration changes. First improvement is observed, when rapid-commit procedure is used (scenario 5). Proposed improvements further decrease reconfiguration time

Figure 32: Example comparison of selected IPv6 reconﬁguration time measurements. Values recorded during experiment 3 are presented. For clarity of presentation, only selected (2,5 and 8) scenarios are presented. Improvement between scenarios is clearly noticeable Eﬃciency analysis 91

4.8.4. DHCP Conﬁguration Time

Penultimate analyzed parameter is the time required to complete DHCPv6 exchange. As most proposed improvements are related to the automatic configuration, this property may be used as a rough estimation of improvement quality. As DHCP configuration is part of IP layer reconfiguration, those two values are in strict relation. Measurements of this parameter were taken during experiment 3, described in Section 4.6.3. Simula- tions were run 10 times. Except initial fluctuation, standard deviation of measured DHCPv6 configuration time is steadily decreasing for scenarios 1-7 and maintains the same range for remaining cases. As initial cut-off point was chosen as log(n) = 1, initial 10 samples were discarded and not used for parameter estimation. For scenarios 1-4, DHCPv6 configuration time (so was the HD metric) was oscillating around value of 2100 ms. Scenario 5 proved to be able to finish configuration faster by over 1000 ms. That result, however, was easily beaten by scenarios 6-7, which were able to conclude configuration in 78ms. Intro- duction of remote-autoconf in scenario 8 affected all remaining cases – average configuration took 220ms. Similar values were obtained by linear regression. Summary results for all 10 scenarios are presented in Fig.34 and numeric values are in Table9.

Table 9: DHCPv6 conﬁguration measurements, based on results from experiment 3. Designation explanations are available in Section 4.8.1

Scn1 Scn2 Scn3 Scn4 Scn5 Scn6 Scn7 Scn8 Scn9 Scn10

xbegin 10 10 10 10 10 10 10 10 10 10

xend 432 466 466 466 418 381 381 794 728 832 n 423 457 457 457 409 372 372 785 719 823

nmin 245 399 317 285 14 11 14 557 618 518 0,007 0,007 0,007 0,007 0,007 0,007 0,007 0,020 0,020 0,020 x 2,097 2,113 2,115 2,111 1,079 0,078 0,078 0,223 0,234 0,215 S(x) 0,066 0,085 0,076 0,072 0,016 0,014 0,016 0,287 0,302 0,276 S2(x) 0,004 0,007 0,006 0,005 0,000 0,000 0,000 0,082 0,091 0,076

β1 1,5E-7 3,6E-6 -6,2E-6 -1,2E-5 3,7E-6 2,8E-6 -2,8E-6 -6,0E-6 -3,9E-5 -5,7E-6

β0 2,10 2,11 2,12 2,12 1,08 0,08 0,08 0,23 0,26 0,22

Sβ1 0,0482 0,0464 0,0464 0,0463 0,0488 0,0512 0,0513 0,0355 0,0371 0,0347

Sβ0 0,1021 0,0990 0,0991 0,0986 0,0532 0,0041 0,0041 0,0130 0,0142 0,0122

tα,n−1 1,6485 1,6482 1,6482 1,6482 1,6486 1,6490 1,6490 1,6468 1,6470 1,6467 B(x) 0,25% 0,31% 0,28% 0,26% 0,12% 1,49% 1,71% 7,56% 7,93% 7,39%

rxy 0,001 0,018 -0,035 -0,074 0,091 0,071 -0,063 -0,008 -0,049 -0,009 R2 0,000 0,0003 0,001 0,005 0,008 0,005 0,004 0,0001 0,002 0,0001

Slope of the linear regression is very low, on the order of 10−6 or less. Together with very low Pear- son coefficient, it indicates that DHCPv6 configuration time is independent of simulation time. Relative 92 Efficiency analysis estimation precision is within acceptable values (well below 2%) for scenarios 1-7. It is unusually high for scenarios 8-10 (over 7%). There is a good explanation for this behavior, however. Remote autoconfiguration optimization, introduced in scenario 8, triggers DHCPv6 exchange while still at the old location. After it is completed, handover occurs and is followed by network reentry. In the final steps of network reentry, “normal” DHCP configuration is triggered. As address for this location is already obtained, this configuration finishes immediately, without any actual message transmission. As a result, number of completed configurations is actually doubled, but every other sample is very close or equal zero. This causes standard deviation to be quite large, and so is relative precision. For demonstration purposes, example measurements from scenario 9 were presented in Fig.33. Standard deviations of increasing sample sets are plotted in Fig.35.

4.8.5. Lack of communication capabilities

The last and the most important handover parameter is the lack of communication capabilities, often improperly referred to as handover delay or more colloquially “handover blackout”. Other often used name for the same property is handover latency. That is the actual interval, when mobile node is not able to send or receive data. As such, this parameter has the biggest impact from the end user perspective. It is measured from detachment from serving base station to ﬁnish of the Binding Update mechanism at the new location. This parameter may be perceived as a handover quality metric.

Figure 33: Example DHCPv6 configuration time for scenario 9 (address-params). As every handover with remote- autoconf enabled triggers extra DHCP configuration (first before handover and second after handover), the latter does not send any messages, but uses address and parameters obtained during first exchange. This results in every other configuration time to be close to zero Efficiency analysis 93

Figure 34: DHCPv6 conﬁguration time. The biggest improvement is observed with introduction of rapid-commit (scenario 5) and skip-dad/server-side-dad (scenarios 6 and 7)

Figure 35: Standard deviation of DHCP configuration time. Scenarios 1–7 offer relatively low deviation, while cases 8–10 have very high deviation. Cause of this behavior is discussed in Section 4.8.4 94 Efficiency analysis

Figure 36: Lack of communication capability estimations for all 10 scenario. Delay is steadily decreasing as number of enabled optimizations increases. The most signiﬁcant gain is observed for rapid-commit (Scn5), skip-dad (Scn6), and server-side-dad (Scn7) mechanisms

Figure 37: Lack of communication capabilities warm-up time. Due to common processing with other results from experiment 4, initial 28 samples were discarded. Standard deviation of lack of communication capability periods decreases immediately, proving that suﬃcient number of samples was discarded

This parameter was estimated based on 10 simulation runs, executed as part of the experiment 4 (see Section 4.6.4). Numerical results are presented in Table 10. Depending on scenario, 486 to 1411 samples were collected. To eliminate initial fluctuations, standard deviation of samples was plotted and simulation warm-up time was selected. Standard deviation decreases steadily, but in order to remove initial fluctuations, cutoff point was selected at log(n) = 1, 447. Therefore first 27 samples were discarded. Remaining samples were used for parameter estimation. Due to assumed criteria, there is 95% chance that the real value of handover delay is different from calculated estimation by less than 5ms (scenarios Efficiency analysis 95

1-7) or 20ms (scenarios 8-10). Graph of standard deviation is presented in Fig.37. Linear regression shows that handover delay is extremely weakly dependent on simulation time. It is worth noting that slope of trend line has positive or negative slope, depending on the scenario. The biggest slope value is of 10−5 order of magnitude. Further backed by very low Pearson coefficient, following statement seems reasonable: the real handover delay value is independent of time and any tiny observed dependency is a simulation artifact. Relative estimation precision is in range between 0,15% and 1,8%. Such precise estimation support statement that simulation criteria were more than adequate for sufficient parameter measurement. Handover delay varies greatly between scenarios. Starting with HD metric over 2900ms in scenario 1, it consistently decreases to 1391ms in scenario 5. skip-dad and server-side-dad improvements (scenarios 6 and 7) offer significant decrease to 400ms range. This may be further decreased by using optimization from scenarios 8-10. This allows handover delay to be finally minimized to 320ms range, with minor (±5 ms) differences between scenarios. Similar values were obtained as results of linear regression. Both results are presented in Fig. 36. Values of all handover delays for all 10 simulations were presented in Fig.38. As observations in several scenarios are from similar range, this figure may appear difficult to read. For clarity of presentation, results limited to scenarios 1,3,5 and 10 are presented in Fig.39.

Table 10: Measurements of lack of communication capability. Data recorded during experiment 4. Designation explanations are available in Section 4.8.1

Scn1 Scn2 Scn3 Scn4 Scn5 Scn6 Scn7 Scn8 Scn9 Scn10

xbegin 28 28 28 28 28 28 28 28 28 28

xend 979 1411 1387 785 888 1216 793 486 1410 1270 n 952 1384 1360 758 861 1189 766 459 1383 1243

nmin 872 680 690 688 728 681 743 38 41 40 0,005 0,005 0,005 0,005 0,005 0,005 0,005 0,020 0,020 0,020 x 2,903 2,392 2,394 2,388 1,391 0,400 0,399 0,320 0,315 0,325 S(x) 0,090 0,079 0,080 0,080 0,082 0,079 0,083 0,075 0,077 0,076 S2(x) 0,008 0,006 0,006 0,006 0,007 0,006 0,007 0,006 0,006 0,006

β1 5,2E-7 -2,2E-6 -5,3E-6 -4,8E-6 6,3E-7 1,0E-7 -1,5E-6 6,4E-6 -1,9E-6 -9,3E-7

β0 2,901 2,397 2,408 2,395 1,390 0,400 0,401 0,313 0,320 0,327

Sβ1 0,0324 0,0269 0,0319 0,0363 0,0341 0,0290 0,0362 0,0467 0,0269 0,0291

Sβ0 0,0942 0,0643 0,0648 0,0867 0,0475 0,0118 0,0147 0,0153 0,0087 0,0094

tα,n−1 1,6465 1,6460 1,6460 1,6469 1,6466 1,6461 1,6468 1,6482 1,6460 1,6461 B(x) 0,16% 0,15% 0,15% 0,20% 0,33% 0,95% 1,23% 1,80% 1,08% 1,09%

rxy 0,0079 -0,0381 -0,0916 -0,0485 0,0064 0,0016 -0,0131 0,0439 -0,0331 -0,0167 R2 0,0001 0,0015 0,0084 0,0023 0,0000 0,0000 0,0002 0,0019 0,0011 0,0003 96 Eﬃciency analysis

Figure 38: Comparison of measured handover delays for all scenarios. As scenario groups oﬀer similar handover delays, some graphs overlap. See Fig. 39 for comparison of selected scenarios

Figure 39: Comparison of lack of communication capability for selected scenarios. By using only one scenario from each “group” improves visual quality of the presentation. See Fig. 38 for complete view with results plotted for all scenarios Eﬃciency analysis 97

4.9. Eﬃciency comparison

Nine diﬀerent mechanisms were assessed during experiments discussed in this chapter. Summary results of measured parameters are presented as absolute values in Table 11. As comparing absolute values may not be the best way to assess usefulness of tested mechanisms, also relative values were calculated. It is useful to compare relative values against two scenarios: scenario 1, as it is the most basic case (“worst case”), without any optimizations; and scenario 5, as it is the most advanced case allowed by standards. Those two relative comparisons were presented in Tables 12 and 13, respectively. For improved visual assessment, “better”5 values are marked green, while “worse” values are marked red.

Table 11: Estimated values of all measured handover parameters (absolute values). All values are speciﬁed in seconds

Parameter Scn1 Scn2 Scn3 Scn4 Scn5 Scn6 Scn7 Scn8 Scn9 Scn10 HO Preparation 0,101 0,101 0,103 0,101 0,103 0,103 0,101 0,318 0,319 0,320 DHCP conf. time 2,097 2,113 2,115 2,111 1,079 0,078 0,078 0,223 0,234 0,215 802.16 reentry 0,595 0,081 0,076 0,079 0,082 0,076 0,077 0,088 0,087 0,087 IPv6 conf. time 2,401 2,438 2,463 2,449 1,359 0,315 0,313 0,237 0,242 0,241 Lack of comm. 2,903 2,392 2,394 2,388 1,391 0,400 0,399 0,320 0,315 0,325

Handover preparation time is mostly the same during first 7 scenarios and differs very slightly. There is no improvement in this parameter. Unfortunately, with introduction of remote address configuration (see Section 3.2.4), handover preparation is slightly increased. It should be noted that HD metric for handover preparation is 0ms in all cases, as subscriber maintains communication capability. That increase may be considered the necessary cost of shortening other, more critical phases of the handover. If such increase by average 220 ms is deemed too large, there are several options available to address this issue. Handover decision algorithm may be modified to trigger handover earlier. If subscriber’s algorithm is not suitable for modification, base station initiated handover may be used instead. Nevertheless, extending preparation phase should not pose any impact on user’s experience, as mobile node maintains full connectivity during handover preparation. Also, conservative mode of Remote Autoconf (that is considered the worst case) was simulated. Assuming more optimistic approaches (hybrid or even cooperative), better results may be obtained. Network reentry time is only affected by IEEE 802.16 optimizations enabled in scenario 2 (see Section 3.1.1). Scenarios 2–10 maintain similar level of roughly 80ms as all remaining optimizations focus on IP layer rather than 802.16. DHCPv6 configuration time is not affected by any standard improvements (scenarios 2–4), except rapid-commit option introduced in scenario 5. That result can be significantly improved by over an order of magnitude by two proposed mechanisms: skip-dad (scenario 6) or server- side-dad (scenario 7). Inclusion of remote-autoconf in scenario 8 slightly worsens results, but they are still

5In case of all parameters, faster completion of any given procedure is more desirable, thus smaller value means better operation. 98 Eﬃciency analysis

over 400% better than best standard case.

Table 12: Estimated values of all measured handover parameters. Values are relative, with scenario 1 (no optimizations) used as a reference

Parameter Scn1 Scn2 Scn3 Scn4 Scn5 Scn6 Scn7 Scn8 Scn9 Scn10 HO Preparation 1,000 1,004 1,027 1,003 1,026 1,024 1,002 3,164 3,175 3,186 DHCP conf. time 1,000 1,007 1,009 1,007 0,514 0,037 0,037 0,106 0,111 0,102 802.16 reentry 1,000 0,135 0,128 0,133 0,138 0,127 0,130 0,149 0,147 0,146 IPv6 conf. time 1,000 1,015 1,026 1,020 0,566 0,131 0,130 0,099 0,101 0,100 Lack of comm. 1,000 0,824 0,825 0,823 0,479 0,138 0,138 0,110 0,109 0,112

IPv6 configuration time is part of the IPv6/802.16 handover that takes the most time. Impacted by only one standard mechanism (rapid-commit option), its HD metric varies from 2,449ms to 1,359 in standard cases. Similar to DHCPv6 configuration time, the bigger improvement is observed with skip-dad and server-side-dad mechanism in scenarios 6 and 7, respectively. Further improvement on a smaller scale can be achieved thanks to remote-autoconf mechanism (scenario 8). Final and most important parameter – lack of communication capability – may be perceived as a logical sum of all previously investigated parameters. Being the only one that is directly observable by end user, it requires special attention. Being affected by essentially all improvements, it is steadily decreasing with number of enabled mechanisms. Standard based scenarios offer a way to decrease lack of communication capabilities from over 2900ms in scenario 1 to over 1390ms in scenario 5, which may be considered a good result. Unfortunately, with HD metric around 1500ms, the delay is still clearly noticeable by end users. Therefore further improvements are desired. Two proposed mechanisms – skip-dad and server-side-dad – speed up handover by almost one second, down to 400ms range. That result can be further improved by remote-autoconf (scenario 8), down to 320ms.

Table 13: Estimated values of all measured handover parameters. Values are relative, compared to the best available standard mechanisms (scenario 5)

Parameter Scn1 Scn2 Scn3 Scn4 Scn5 Scn6 Scn7 Scn8 Scn9 Scn10 HO Preparation 0,975 0,978 1,001 0,978 1,000 0,998 0,976 3,084 3,095 3,106 DHCP conf. time 1,944 1,958 1,961 1,957 1,000 0,073 0,072 0,207 0,217 0,199 802.16 reentry 7,244 0,980 0,930 0,964 1,000 0,923 0,940 1,077 1,063 1,054 IPv6 conf. time 1,768 1,795 1,813 1,802 1,000 0,232 0,230 0,175 0,178 0,177 Lack of comm. 2,088 1,720 1,722 1,717 1,000 0,288 0,287 0,230 0,227 0,234

Although following method was not used for qualitative or quantitative handover assessment, it is used to illustrate scope of gained improvement. Fig. 40 shows traffic reception in basic and optimized scenarios. In former case handover periods are clearly visible and their impact on overall transmission is huge. After enabling all optimizations, transmission is much more fluent, without noticeable pauses. Efficiency analysis 99

Figure 40: Received traffic per second for scenarios 1 and 10. Upper diagram shows traffic for basic case, when all optimizations are disabled (scenario 1). Handover periods, when traffic is not received or transmitted, are clearly visible. Lower diagram shows traffic with all optimizations enabled (scenario 10). Traffic is almost continuous. Handovers are visible as very narrow spikes, where throughput drops to 0 bytes per second for very brief periods. Values are specified in bytes per second

4.10. Future research directions

It is somewhat surprising to note that proposed way of configuring routing via DHCPv6 (address- params, enabled in scenario 9) did not affect handover performance. That may be explained by overlapping times, when mechanisms work. After 802.16 network reentry is complete, mobile node initiates stateful autoconfiguration (DHCPv6) and DAD procedure. Router Advertisements may be received during that time. Therefore mobile node has routing already configured once DAD procedure is completed and thus serving this information via DHCPv6 does not provide any further benefits. This phenomenon will be an 100 Efficiency analysis area of further research. Another unexpected observation is that remote-binding-update did not further improve handover performance. There are several possible explanations. Binding Update message may not have been transmitted before detachment took place at old location. Another possible result would be that subscriber or base station does not accept incoming messages before subscriber’s address is configured. If the Binding Acknowledgement is arriving earlier, then subscriber will not be able to receive it. As the actual root cause of this behavior remains unknown, it is going to be area of further investigation. Is seems reasonable to assume that after additional tuning (e.g. increasing delay between first Binding Update transmission and detachment from serving base station), remote-binding-update mechanism may prove its usefulness. On the other hand, it may be useful to add extra option to Binding Update message to notify Corresponding Node about current mobile node’s location or expected arrival at destination location. Such ideas require modification of Mobile IPv6 protocol, however. 5. Conclusions

This ﬁnal chapter oﬀers summary of discussed topics, provides conclusions regarding usefulness of proposed 802.16/IPv6 handover improvements. Results of the work – several mechanism proposals, developed simulation environment and DHCPv6 implementation – and their impact is assessed. Summary of all achievements and directions of future work conclude this dissertation.

During the course of numerous experiments and research conducted by the author, number of conclusions emerged. Main results obtained in this dissertation clearly prove that:

1. Using proposed handover latency mitigation techniques, the delay was decreased from 1390 ms to 325 ms. (Section 4.9, table 11) This oﬀers handover delay reduction by over 76%, compared to the best case oﬀered by standards.

2. Several efficiency related DHCPv6 improvements were proposed and validated: Skip initial delay in DHCPv6, Skip Duplicate Address Detection, Server side Duplicate Address Detection, Remote Autoconfiguration, Routing configuration via DHCPv6 and Remote Binding Update. According to author’s knowledge, these are the first proposals related to mobility efficiency in DHCPv6.

3. The idea to perform stateful autoconﬁguration remotely, before client is physically attached to the link is new and was never analyzed before. As such, it is a novel solution to a well known problem. Furthermore, obtained results clearly conﬁrm usefulness of presented proposals.

4. Idea to move address verification duties (Duplicate Address Detection) from client to server side is another unique proposal. According to author’s knowledge, that is the first time such mechanism was ever proposed. Delay caused by Duplicate Address Detection has been eliminated completely with two proposed solutions: Skip DAD and Server side DAD. While both are equally effective, Server Side DAD provides far better reliability as the DAD procedure is indeed performed. This offers equal confidence in address correctness as with classic DAD procedure. Therefore Server Side DAD procedure is preferred, compared to Skip DAD approach. This procedure is network type agnostic and can be used in networks other than 802.16.

5. Conducted research allowed major causes of handover latency to be located. Obtained experiment results indicate that the biggest delays are introduced in IPv6 protocol stack. Some parts of IPv6 and DHCPv6 were not designed with mobility in mind. The biggest delay is caused by Duplicate 102 Conclusions

Address Detection in IPv6. Two novel proposed and thoroughly validated ideas removed this delay completely.

6. It has been demonstrated that 802.16 handovers (and L2 in general) are fast, compared to IP layer reconﬁguration. As 802.16e-2005 protocol was designed with mobility in mind, properly executed handover, changing point of attachment and network reentry is done within 100ms range.

7. Number of improvements was proposed. Each proposal had its unique beneﬁts and the best results were obtained when using combination of mechanisms. Optimizations must be carefully chosen, however, as some optimizations improve certain parameters at the cost of degrading others. The particularly degraded property is the handover preparation time.

8. During the course of research, two projects emerged: Dibbler (a DHCPv6 implementation, [80]) and Numbat (802.16/IPv6 simulation environment, [75]). Both projects are successful and are used around the world.

9. It has been proved that Remote autoconfiguration method provides useful way for further shortening of highly optimized handover routines. Thanks to a’priori knowledge gained through remote autoconfiguration, mobile node does not waste time on DHCPv6 configuration after changing points of attachment. Validated in several setups, this proposal offers 20% improvements in handover delay. Achieved HD metric values before remote autoconfiguration (400ms) were limited to 320ms.

10. Experimental implementation of Address Parameters extension proved its usefulness during simulation runs and practical tests. It is now distributed with Dibbler releases.

11. Address Parameters and Server Side DAD proposal are particularly worthy candidates for broader adoption. Anticipated further work includes creation and publication of RFC draft and initiation of formal discussion with IETF work groups. Hopefully, after thoroughly discussed by DHCPv6 experts, those proposals will be accepted as RFC documents.

12. Proposed Remote Autoconﬁguration mechanism proved useful, but somewhat less than originally anticipated. Further research focused on hybrid and cooperative modes may yield better results than currently used conservative mode.

In the light of the presented achievements, it can be stated that the thesis: IPv6 reconfiguration process during handovers in 802.16 networks is not optimal and it is possible to achieve improved handover efficiency by IPv6, DHCPv6 and Mobile IPv6 protocols modifications has been proven.

5.1. Practical aspects

During research conducted during creation of this dissertation, two main projects were developed and released as open source. This distribution model appear to provide maximum gains, compared to Conclusions 103 other distribution methods. GPL license allows use, modification and even redistribution by anyone for any purpose, including commercial. This approach results in a rapid acceptance in home, research and industrial environments. Source code, exposed to scrutiny of experts and curious minds around the world is validated much more thoroughly. Contributions like fixes and code patches that include new functionalities sent by advanced users are another beneficial factor.

5.1.1. Dibbler

Dibbler is a full featured DHCPv6 implementation that includes server, client, relay and requestor. Currently this software supports Windows NT4, 2000, XP, 2003, Vista and Windows 7 and Linux systems. Support for Mac OS X was added recently. It offers both stateful (i.e. IPv6 address granting) and stateless (i.e. options granting) autoconfiguration. Besides basic functionality, it also offers numerous enhancements, e.g. DNS servers and domain names configuration. Dibbler is open source software, distributed under GNU GPL v2 licence. It means that it is freely available, free of charge and can be used by anyone (including commercial users). Source code is also provided, so anyone skilled enough can fix bugs, add new features and distribute his/her own version.

Figure 41: World map with marked countries that Dibbler software is used in. Data based on feedback received from users.

Dibbler is distributed (as open source) from the project website [80]. It was also accepted as part of several Linux distributions: Debian, Ubuntu, Gentoo, OpenWRT and PLD. Due to open distribution method, the exact number of deployments is impossible to assess. However, it can be roughly estimated by the amount of received e-mails from its users. Author received feedback from users from 30 countries (Poland, Germany, Czech Republic, France, Spain, United States, China, Malaysia, Canada, Taiwan, Switzerland, Turkey, India, United Kingdom, Austria, Hungary, Cuba, Japan, Sweden, Luxembourg, Australia, Israel, Norway, Thailand, Finland, Philippines, Venezuela, Bosnia and Herzegovina, Portugal and New Zealand). World map with marked countries that provided feedback is shown in Fig. 41. This 104 Conclusions software is currently used on 5 continents. Another quantity that may be used as a popularity indicator is project’s mailing list. As of July 2009, there are 86 members subscribed. That includes users from following companies: Broadcom, Cisco, Conexant, HP, Intel, L&T Infotech, Mitel, Nokia, Orange (France Telecom), Qualcomm, Sony, Toshiba, Wipro and Xerox. Author has been invited to several DHCPv6 interoperability events, associated with IETF meetings: in Amsterdam, Vancouver and Philadelphia. During each event, Dibbler proved to be most feature rich solution and the only one that included all 4 entities: server, client, relay and requestor. Interoperability testing showed that provided software in on par with commercial solutions and other open source software. Dibbler is also a successful research environment. Six undergraduate students (four from Poland, one from Turkey and Thailand) completed their master theses and obtained their M.Sc. titles. It was also used in numerous student projects. Notable example is a work of group of 6 students from University of Toulouse. Several papers were presented at international conferences regarding Dibbler and DHCPv6 protocol. Two notable examples are [74] (a Dibbler overview paper, published in 2005 on 8th IEEE International Conference on Telecommunications in Zagreb, Croatia and [77] (DNS Update issues from the DHCPv6 perspective, published in 2008 on 1st IEEE International Conference on Information Technology, Gdansk). Complete list of author’s publications is presented in AppendixC.

5.1.2. Numbat

Numbat is a discrete event simulation environment, based on OMNeT++ and developed with 802.16 and IPv6 mobility in mind. Its development was supported by 3 undergraduate students. As of May 2009, two of them graduated and obtained their M. Sc. Being freely distributed under GNU GPL open source license, code of this project spurred interest among students and researches world-wide. Since project inception in 2006, feedback from 8 countries was received, both from universities and commercial research centers. One notable example is DLR – German Aerospace Agency, developing WiMAX based solution for european airports. Being one of only few WiMAX simulation environments available, perspective for further grows for Numbat are very favorable. Author intends to continue development of this environment. Author published several papers related to Numbat and research conducted using this tool. Two notable examples are [76] (Numbat architecture and capabilities overview, published at ATNAC’2007, an IEEE conference held in Cristchurch, New Zealand) and [78] (Handover Improvement techniques, published at ATNAC’2008, an IEEE conference held in Adelaide, Australia). Complete list of author’s publications is presented in AppendixC.

5.2. Future work

As this research proved validity of several proposed solutions, the next logical step is to implement remaining features and verify them in a real life environment. Dibbler will be enhanced with this purpose in mind. Author intends to publish IETF drafts regarding proposed server-side-dad, address-params and remote-binding-update extensions. After discussion on IETF mailing lists, and verification by independent experts, those proposals hopefully will be published as RFC documents. Similar approach will be used Conclusions 105 for another method designed during related research. This work includes new method of IPv4 traffic tunneling over IPv6-only network and remote configuration of such tunnels. Another research direction includes broader applicability of proposed methods. It would be very beneficial to develop network agnostic version of proposed mechanisms that require 802.16 as underlying network, namely remote-autoconf and remote-binding-update mechanism. 106 Conclusions Bibliography

[1] S. Ahson, M. Ilyas “WiMAX: Standards and security”, CRC Press, Sep. 2007

[2] Alcatel-Lucent Press Oﬀce, “Worldmax launches Aerea: the ﬁrst commercial wireless broadband network in Amsterdam”, http://www.edubourse.com/finance/actualites.php?actu=42361, June 2008

[3] S. Aluru, “Parallel additive lagged Fibonacci random number generators”, Proceedings of the 10th international conference on Supercomputing, ACM, Philadelphia, 1996

[4] J. Arkko, Ch. Vogt, W. Haddad, “Enhanced Route Optimization for Mobile IPv6”, RFC4866, IETF, May 2007

[5] T. Aura, “Cryptographically Generated Addresses (CGA)”, RFC3972, IETF, March 2005

[6] A. Balicki, W. Makać “Metody Wnioskowania statystycznego”, Wydawnictwo Uniwersytetu Gdańskiego, Gdańsk, 1997

[7] The Beiging Organizing Committee for the Games of the XXIX Olympiad, “The Oﬃcial Website of the Beijing 2008 Olympic Games”, http://ipv6.beijing2008.cn/en (available via IPv6 only), retrieved Oct. 2009

[8] The Beiging Organizing Committee for the Games of the XXIX Olympiad, “Beijing2008.cn leaps to next generation Net”, http://en.beijing2008.cn/news/official/preparation/n214384681. shtml, retrieved Oct. 2009

[9] I. van Beijnum, “The year in IPv4: addresses: almost 200 million served”, http://arstechnica.com/ business/news/2009/01/the-year-in-ipv4-addresses-almost-200-million-served.ars, retrieved Jan. 2009

[10] S. Brandt “Analiza Danych”, Wydawnictwo Naukowe PWN, Warsaw, 1998

[11] J. Brzozowski, J. Tremblay, J. Chen, T. Mrugalski, “DHCPv6 Redundancy Deployment Considera- tions”, draft-ietf-brzozowski-dhc-dhcpv6-redundancy-deployment-considerations-00.txt, IETF draft (work in progress), Oct. 2009

[12] C.L. Chen, “Linear Dependencies in Linear Feedback Shift Registers”, IEEE Transactions on Com- puter, Volume C-35, Issue 12, Dec. 1986

[13] L. Colitti, E. Kline “Looking towards IPv6”, Oﬃcial Google Blog, http://googleblog.blogspot. com/2008/05/looking-towards-ipv6.html, May 2008 108 BIBLIOGRAPHY

[14] A. Concei¸cao, J. Li, D. Florencio F. Kon, “Is IEEE 802.11 Ready for VoIP?”, Microsoft Research, IEEE International Workshop on Multimedia Signal Processing, Oct.2006

[15] M. Crawford “Transmission of IPv6 Packets over Ethernet Networks”, RFC 2464, IETF, Dec. 1998

[16] I. Dalal, J. Hrwayne-Gidansky, D. Stefan “On the Fast Generation of Long-period Pseudorandom Number Sequences”, IEEE Long Island Systems, Applications and Technology Conference, May 2008

[17] S. Deering, R. Hinden, “Internet Protocol, Version 6 (IPv6) Speciﬁcation”, RFC 2460, IETF, Dec.1998

[18] V. Devarapalli, R. Wakikawa, A. Petrescu, P. Thubert “Network Mobility (NEMO) Basic Support Protocol”, RFC3963, IETF, Jan. 2005

[19] dhc WG, “Dynamic Host Conﬁguration working group”, http://www.ietf.org/html.charters/ dhc-charter.html, IETF, retrieved July 2009

[20] dna WG, “Detecting Network Attachment (dna)”, IETF, http://www.ietf.org/html.charters/ dna-charter.html, retrieved July 2009

[21] R. Draves, “Default Address Selection for Internet Protocol version 6 (IPv6)”, RFC3484, IETF, Feb.2003

[22] R. Droms, Ed. “Dynamic Host Conﬁguration Protocol for IPv6 (DHCPv6)”, RFC3315, IETF, July 2003

[23] R. Droms, Ed. “DNS Conﬁguration options for Dynamic Host Conﬁguration Protocol for IPv6 (DHCPv6)”, RFC3846, IETF, Dec. 2003

[24] J. Duncan, K. Thomas, “Is your System IPv6 Capable”, The Testing Times, http://jitc.fhu.disa. mil/tst_time/docs/year/mar08.pdf, DISA, March 2008

[25] E. Dutkiewicz, Y. Sun, B. Feng, Y. Zhang, G. Fang, J. Shi “Fast RSVP: A Cross Layer Resource Reservation Scheme for Mobile IPv6 Networks”, 12th IEEE Symposium on Computers and Commu- nications, Beijing, July 2007

[26] H. Fattah, H. Alnuweiri “A New Handover Mechanism for IEEE 802.16e Wireless Networks”, Inter- national Wireless Communications and Mobile Computing Conference, IWCMC ’08, Aug. 2008

[27] A.M. Fireze, R. Kannn, J.C. Lagrias “Linear Congruential Generators do not produce random sequences”, 25th Annual Symposium on Foundations of Computer Science, Oct.1984

[28] L. Gajek, M. Ka luszka, “Wnioskowanie statystyczne”, Wydawnictwa Naukowo-Techniczne, Warsaw, 2000

[29] V. K. Gondi, Nazim Agoulmine“Secured Roaming Over WLAN and WiMAX Networks”, 2nd IEEE/I- FIP International Workshop on Broadband Convergence Networks, BcN ’07, May 2007 BIBLIOGRAPHY 109

[30] B. Harpham, “WiMAX operators and vendors from around the world announce new deployments, growing commitment at the 2nd Annual WiMAX Forum Global Congress”, http://www.wimaxforum. org/node/1161, WiMAX Forum, June 2009

[31] R. Hinden, S. Deering, “IP Version 6 Addressing Architecture”, RFC 4291, IETF, Feb.2006

[32] R. Hinden, S. Deering, “IPv6 Multicast Address Assignments”, RFC 2375, IETF, July 1998

[33] Inter Assigned Numbers Authority, “IPv6 Addresses for the Root Servers”, http://www.iana.org/ reports/2008/root-aaaa-announcement.html, retrieved Oct.2009

[34] IEEE 802.16 working group, “802.16d-2004: IEEE Standard for Local and Metropolitan Area Net- works – Part 16: Air Inter- face for Fixed Broadband Wireless Access Systems”, IEEE Standard, Oct.2004

[35] IEEE 802.16 working group, “802.16-2009: IEEE Standard for Local and metropolitan area networks Part 16: Air Interface for Broadband Wireless Access Systems”, IEEE Standard, May 2009

[36] IEEE 802.16 working group, “802.16e-2004: IEEE Standard for Local and Metropolitan Area Net- works – Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems”, IEEE Standard, Feb. 2006

[37] IEEE 802.16 working group, “802.16f-2005: IEEE Standard fo Local and metropolitan area networks Part16: Air Interface for Fixed Broadband Wireless Access Systems – Amendment 1: Management Information Base”, IEEE Standard, 2005

[38] IEEE 802.16 working group, “802.16g-2007: IEEE Standard for Local and metropolitan area networks – Part 16: Air Interface for Fixed and Mobile Boradband Wireless Access Systems – Amendment 3: Management Plane Procedure and Services”, IEEE Standard, 2007

[39] IEEE 802.16 working group, “802.16i/D5: IEEE Standard for Local and metropolitan area networks Part 16: Air Interface for Fixed Broadband Wireless Access Systems Draft Amendment: Management Information Base Extensions”, IEEE Draft Standard (withdrawn), Oct. 2007

[40] IEEE 802.16 working group, “P802.16j/D9: IEEE Draft Amendment to IEEE Standard for Local and metropolitan area networks Part 16: Air Interface for Fixed and Mobile boradband Wireless Access System Multihop Relay Speciﬁcation”, IEEE Draft Standard, Feb. 2009

[41] IEEE 802.16 working group, “P802.16h/D9: IEEE Draft Amendment to IEEE Standard for Local and Metropolitan Area Networks Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems – Improved Coexistence Mechanisms for License-Exempt Operation”, IEEE Draft Standard, Mar. 2009

[42] IEEE 802.16 working group, “802.16k-2007: IEEE Standard for Local and Metropolitan Area Net- works Media Access Control (MAC) Bridges Ammendment 5: Bridging of IEEE 802.16”, IEEE Stan- dard, 2007 110 BIBLIOGRAPHY

[43] IEEE 802.16 Broadband Wireless Access Working Group, “Draft IEEE 802.16m Requirements”, IEEE Standard, Oct. 2007.

[44] IEEE working group, “IEEE Standard for Local and metropolitan networks – Part 21: Media Inde- pendent Handover”, IEEE, Jan 2009

[45] Intel Corp., “Microprocessor Quick Reference Guide”, http://www.intel.com/pressroom/kits/ quickreffam.htm, retrieved on June 2009

[46] Intel Corp., “OFDMA PHY SAP Interface Speciﬁcation for 802.16 Broadband Wireless Access Base Stations”, http://www.intel.com/netcomms/technologies/wimax/PHY_SAP_API.pdf, June, 2007

[47] Y. Jinsha, B. Cui, C. Zhixiong, “An Improved FHMIPv6 Handover Scheme For Mobile WiMAX”, 4th International Conference on Wireless Communications, Networking and Mobile Computing, 2008. WiCOM’08, Oct. 2008

[48] D. Johnson “Reserved IPv6 Subnet Anycast Addresses”, RFC 2526, IETF, March 1999

[49] D. Johnson, C. Perkins, J. Arkko “Mobility support in IPv6”, RFC3775, IETF, Jun.2004

[50] H. Kassyk-Rokicka, Ed.“Statystyka Zbi´orZada´n”, Polskie Wydawnictwo Ekonomiczne, Warsaw, 1999

[51] V. Kalusivalingam, “Network Information Services (NIS) Conﬁguration Options for Dynamic Host Conﬁguration Protocl for IPv6 (DHCPv6)”, RFC3898, IETF, Oct.2004

[52] V. Kalusivalingam, “Simple Network Time Protocol (SNTP) Conﬁguration Option for DHCPv6”, RFC4075, IETF, May 2005

[53] R. S. Katti, R. G. Kavasseri “Secure Pseudo-random Bit Sequence Generation using Coupled Linear Congruential Generators”, IEEE International Symposium on Circuits and Systems, May 2008

[54] E. Key, “An analysis of the structure and complexity of nonlinear binary sequence generators”, IEEE Transactions on Information Theory, Volume 22, Issue 6, Nov 1976

[55] D. E. Knuth, “Art of computer programming”, Wydawnictwa Naukowo-Techniczne, Warsaw, 2002

[56] R. Koodli, Ed. “Mobile IPv6 Fast Handovers”, RFC5568, IETF, July 2009

[57] M. Kraus, “DOD: Transition to IPv6”, http://www.usipv6.com/2003arlington/presents/ Marilyn_Kraus.pdf, Dec.2003

[58] C. Lauradoux “From Hardware to Software Synthesis of Linear Feedback Shift Registers”, IEEE International Parallel and Distributed Processing Symposium, March 2007.

[59] P. L’Ecuyer, F. Blouin “Linear congruential generators of order K>1”, Winter Simulation Conference Proceedings, Dec. 1998 BIBLIOGRAPHY 111

[60] P. L’Ecuyer, F. Panneton “A new class of linear feedback shift register generators”, Winter Simulation Conference Proceedings, 2000, Montreal, Dec. 2000

[61] P. L’Ecuyer, R. Simard “TestU01: A Software Librry in ANSI C for Empiricial Testing of Random Number Generators”, http://www.iro.umontreal.ca/~simardr/testu01/tu01.html, April 2009

[62] P. L’Ecuyer, R. Simard“TestU01: A C Library for Empirical Testing of Random Number Generators”, Transactions on Mathematical Software, ACM, Aug.2007

[63] X. Li, S. Dawkins, D. Ward, A. Durand “Softwire Problem Statement”, RFC2925, IETF, July 2007

[64] G. Marsaglia,“Diehard Battery of Tests of Randomness”, http://www.stat.fsu.edu/pub/diehard/, Florida State University, 1995

[65] M. Matsumoto, T. Nishimura “Mersenne Twister: A 623-dimensionally Equidistributed Uniform Pseudorandom Number Generator.”, ACM Trans. on Modeling and Computer Simulation, Jan. 1998.

[66] P. Matusz, P.Macha´n, J.Wo´zniak, “Analysis of proﬁtability of inter-system handovers between IEEE 802.11b and UMTS”, LCN’03, IEEE International Conference, Oct.2003

[67] J. McCann, S. Deering, J. Mogul “Path MTU Discovery for IP version 6”, RFC1981, IETF, August 1996

[68] mext WG, “Mobility EXTensions fo IPv6 (mext)”, IETF, http://www.ietf.org/html.charters/ mext-charter.html, retrieved July 2009

[69] Microsoft TechNet, “Microsoft Internet Protocol Version 6 (IPv6)”, http://technet.microsoft. com/en-us/network/bb530961.aspx, retrieved Oct. 2009

[70] D. Mills, “Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI”, RFC4330, IETF, Jan. 2006

[71] mipshop WG, “Mobility fo IP: Performance, Signaling and Handoﬀ Optimization (mipshop)”, IETF, http://www.ietf.org/html.charters/mipshop-charter.html, retrieved July 2009

[72] N. Moore “Optimistic Duplicate Address Detection (DAD) in IPv6”, RFC4429, IETF, Apr. 2006

[73] T. Mrugalski, “Metoda szybkiego wdra˙zania IPv6 przy wykorzystaniu DHCPv6”, Techonologie Infor- macyjne conference, Gda´nsk, 2004

[74] T. Mrugalski, “Dibbler – a portable Dynamic Host Conﬁguration Protocol for IPv6 implementation”, Proceeeding of the 8th IEEE International Conference on Telecommunications, ConTEL 2005, Zagreb, June 2005

[75] T. Mrugalski, “Numbat – mobile IPv6 in WiMax environment”, project homepage, http://klub. com.pl/projects/numbat/, Oct. 2009 112 BIBLIOGRAPHY

[76] T. Mrugalski, J. Wo´zniak“Numbat - extensible simulation environment for mobile, IPv6 capable IEEE 802.16 stations”, Australasian Telecommunication Networks and Applications Conference, ATNAC 2007, Christchurch, New Zealand, Dec. 2007

[77] T. Mrugalski, K. Nowicki, K. Wnuk, “Next generation automatic IP conﬁguration deployment issues”, 1st IEEE International Conference on Information Technology, IT 2008, Gda´nsk, May 2008

[78] T. Mrugalski, J. Wo´zniak “How to Improve the Eﬃciency of IPv6 Handovers in IEEE 802.16 Net- works”, IEEE Australasian Telecommunication Networks and Apllications Conference, ATNAC 2008, Adelaide, Australia, Dec. 2008

[79] T. Mrugalski, “Dibbler User’s Guide”, available on http://klub.com.pl/dhcpv6/, Mar.2009

[80] T. Mrugalski, “Dibber – a portable DHCPv6”, project homepage, http://klub.com.pl/dhcpv6/, retrieved Oct.2009

[81] T. Narten, E. Nordmark, W. Simpson, H. Soliman “Neighbor Discovery for IP version 6 (IPV6)”, RFC4861, IETF, Sep.2007

[82] T. Nied´zwiecki “Analiza i implementacja protoko lu Privacy Key Management (PKMv2) zgodnego z

norma, IEEE 802.16e (WiMAX)”, master thesis, Gda´nsk University Of Technology, Gda´nsk, 2006

[83] Nokia, “Nokia N810 WiMAX Edition Speciﬁcations”, https://www.nokiausa.com/find-products/ phones/nokia-n810-wimax-edition/specifications, retrieved Sep.2009

[84] K. Nowicki, J. Wo´zniak “Sieci LAN,MAN,WAN”, wyd. Fundacji Postepu, Telekomunikacji, Warsaw, 2000

[85] K. Nowicki , J. Swiatowiak´ “Protoko ly IPv6”, wyd. Politechniki Gda´nskiej, Gda´nsk, 2001

[86] K. Nowicki, J. Wo´zniak “Przewodowe i bezprzewodowe sieci LAN”, Wyd. Politechniki Warszawskiej, Warsaw, 2002

[87] F. Ohrtman, “WiMAX Handbook”, McGraw-Hill Press, May 2005

[88] A. De La Oliva, A. Banchs, I. Soto “An Overview of IEEE 802.21: Media-Independent Handover Services”, IEEE Wireless Communications, Aug. 2008

[89] E. K. Paik, Y. Choi“Seamless Mobility Suppport for Mobile Networks on Vehicles across Heterogenous Wireless Access Networks”, The 57th IEEE Semiannual Vehicular Technology Conference, April 2003

[90] C. Perkins, “Securing Mobile IPv6 Route Optimization Using a Static Shared Key”, RFC4449, IETF, June 2006

[91] A. Poorghanad, A. Sadr, A. Kashanipour “Generating High Quality Pseudo Random Number Using Evolutionary methods”, International Conference on Computational Intelligence and Security. CIS ’08. , Dec. 2008 BIBLIOGRAPHY 113

[92] J. Rosenberg, H. Schulzrinne “Session Initiation Protocol (SIP): Locating SIP Servers”, RFC3263, IETF, Jun. 2002

[93] H. Schulzrinne, B. Volz “Dynamic Host Conﬁguration Protocol (DHCPv6) Options for Session Initi- ation Protocol (SIP) Servers”, RFC3319, IETF, July 2003

[94] B. R. Shankar, K. Kamath, “(2,1)-Lagged Fibonacci Generator Using Elliptic Curver over Finite Fields”, International Conference on Computer Engineering and Technology, ICCET’08, Jan 2009

[95] S. L. Shrestha, Nah-Oak Song, S. Chong “Seamless Realtime Traﬃc Handover Policy for IEEE 802.16m Mobile WiMAX”, 43rd Annual Conference on Information Sciences and Systems, CISS 2009, March 2009

[96] H. Soliman, C. Castelluccia, K. ElMalki, L. Bellier “Hierarchical Mobile IPv6 (HMIPv6) Mobility Management”, RFC5380, IETF, Oct. 2008

[97] R. Stankiewicz, “Analytical Modles of Selected DiﬀServ Netowk Elements Supporting Assured For- warding”, AGH University of Science and Technology, Krak´ow,2007

[98] R. Stevens, “Biblia TCP/IP”, tom. 1, RM Press, Warsaw, 1998

[99] R. Stevens, “Biblia TCP/IP”, tom. 2, RM Press, Warsaw, 1998

[100] K. Tae Lee, “Create the future with Mobile WiMAX”, IEEE Communications Magazine, May 2007

[101] S. Thomson, T. Narten, T. Jinmei “IPv6 Stateless Address Autoconﬁguration”, RFC4862, IETF, Sep. 2007

[102] O. Troan, R. Droms “IPv6 Prefxi Options for Dynamic Host Conﬁguration Protocol (DHCP) version 6”, RFC3633, IETF, Dec. 2003

[103] A. Varga, Ed. “INET Framework for OMNeT++ 4.0”, http://inet.omnetpp.org/, retrieved on June 2009

[104] A. Varga, “OMNeT++ User Manual, 3.2”, www.omnetpp.org, version 3.2, retrieved Jan. 2009

[105] S. Venaas, T. Chown, B. Volz “Information Refresh Time Option for Dynamic Host Conﬁguration Protocol for IPv6 (DHCPv6)”, RFC4242, IETF, Nov.2005

[106] Ch. Vogt, J. Arkko “A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimiza- tion”, RFC4651, IETF, Feb. 2007

[107] Wikipedia, “Przedzia lUfno´sci” (Conﬁdence Interval), http://pl.wikipedia.org/wiki/Przedzia% C5%82_ufno%C5%9Bci, retrieved on April 2009

[108] Wikipedia, “Positive feedback”, http://en.wikipedia.org/wiki/Positive_feedback, retrieved on July 2009 114 BIBLIOGRAPHY

[109] Wikipedia, “Pseudorandom number generator”, http://en.wikipedia.org/wiki/Pseudorandom_ number_generator, retrieved on June 2009

[110] Wikipedia “IPv4 address exhaustion”, http://en.wikipedia.org/wiki/IPv4_address_ exhaustion, retrieved on June 2009

[111] Wikipedia “Beta distribution”, http://en.wikipedia.org/wiki/Beta_distribution, retrieved on June 2009

[112] Wikipedia “Middle-square method”, http://en.wikipedia.org/wiki/Middle-square_method, retrieved on June 2009

[113] WiMAX Forum, “Mobile WiMAX – Part II: A Comparative Analysis”, http://www.intel.com/ netcomms/technologies/wimax/mobile_wimax_p2.pdf, Apr.2006

[114] WiMAX Forum, “WiMAX Forum Overview”, http://wimaxforum.org/about/ wimax-forum-overview, retrieved Oct.2009

[115] WiMAX Forum Network Working Group, “WiMAX Forum Network Architecture, Release 1, Ver- sion 1.3.0”, http://members.wimaxforum.org/apps/org/workgroup/nwg/documents.php?folder_ id=1511#folder_1511, Nov. 2008

[116] WiMAX Forum, “WiMAX Forum Member Roster”, http://wimaxforum.org/about/ member-roster, retrieved Oct.2009

[117] WiMAX Forum Technical Working Group, “WiMAX Forum Technical Working Group Homepage”, http://members.wimaxforum.org/apps/org/workgroup/twg/index.php, retrieved Oct.2009

[118] WiMAX Forum Network Working Group, “WiMAX Forum Network Working Group”, http:// members.wimaxforum.org/apps/org/workgroup/nwg/index.php, retrieved Oct.2009

[119] J. Wo´zniak, K. Nowicki, T. Mrugalski, “Mobile users issues, in micro and macro scale, in IP networks”, SIS2004, Lodz, Sep.2004.

[120] J. Wo´zniak, K. Gier lowski, T. Gierszewski, P. Macha´n,T. Mrugalski, T. Klajbor, R. Orlikowski

“Postepy, w standaryzacji i analiza kierunk´owrozwoju pakietowycj sieci bezprzewodowych”, Przeglad Telekomunikacyjny, August 2007 A. Simulation results

This appendix contains complete results of all experiments referred to in previous chapters. Cases already presented in Chapter4 are not duplicated, but rather references are provided instead. Presented results are provided for completeness only. They may serve as an illustration for further in depth analysis, however.

A.1. Experiment 1 results

Discussion of results regarding this experiment is available in Section 4.6.1.

A.1.1. Downlink traﬃc results

For downlink traffic warm-up selection period, see Fig. 12. Summary results, compared to the efficiency of a fixed node, are presented in Fig. 19, in Section 4.7.3.

Figure 42: Downlink traﬃc observed in scenario 1 (basic). Received traﬃc was observed on mobile node’s IPv6 layer at intervals no greater than 12ms. 116 Simulation results

Figure 43: Downlink traﬃc observed in scenario 2 (wimax-optim). Received traﬃc was observed on mobile node’s IPv6 layer at intervals no greater than 12ms.

Downlink traﬃc results for scenario 3 (preference-255 ) are presented in Fig. 16, in Section 4.7.1.

Figure 44: Downlink traﬃc observed in scenario 4 (skip-initial-delay). Received traﬃc was observed on mobile node’s IPv6 layer at intervals no greater than 12ms. Simulation results 117

Figure 45: Downlink traﬃc observed in scenario 5 (rapid-commit). Received traﬃc was observed on mobile node’s IPv6 layer at intervals no greater than 12ms.

Figure 46: Downlink traﬃc observed in scenario 6 (skip-dad). Received traﬃc was observed on mobile node’s IPv6 layer at intervals no greater than 12ms. 118 Simulation results

Figure 47: Downlink traﬃc observed in scenario 7 (server-dad). Received traﬃc was observed on mobile node’s IPv6 layer at intervals no greater than 12ms.

Figure 48: Downlink traﬃc observed in scenario 8 (remote-autoconf ). Received traﬃc was observed on mobile node’s IPv6 layer at intervals no greater than 12ms. Simulation results 119

Figure 49: Downlink traﬃc observed in scenario 9 (address-params). Received traﬃc was observed on mobile node’s IPv6 layer at intervals no greater than 12ms.

Downlink traﬃc results for scenario 10 (remote-binding-update) are presented in Fig. 17, in Section 4.7.1.

A.2. Experiment 2 execution

Discussion of results regarding this experiment is available in Section 4.6.2.

A.2.1. Uplink traﬃc results

For uplink traffic warm-up selection period, see Fig. 13. Summary results, compared to the efficiency of a fixed node, are presented in Fig. 19, in Section 4.7.3. 120 Simulation results

Figure 50: Uplink traﬃc observed in scenario 1 (basic). Traﬃc transmitted by mobile node was observed on correspondent node’s IPv6 layer at intervals no greater than 12ms.

Figure 51: Uplink traﬃc observed in scenario 2 (wimax-optim). Traﬃc transmitted by mobile node was observed on correspondent node’s IPv6 layer at intervals no greater than 12ms. Simulation results 121

Figure 52: Uplink traﬃc observed in scenario 3 (preference-255 ). Traﬃc transmitted by mobile node was observed on correspondent node’s IPv6 layer at intervals no greater than 12ms.

Figure 53: Uplink traﬃc observed in scenario 4 (skip-initial-delay). Traﬃc transmitted by mobile node was observed on correspondent node’s IPv6 layer at intervals no greater than 12ms. 122 Simulation results

Uplink traﬃc results for scenario 5 (rapid-commit) are presented in Fig. 21, in Section 4.7.2.

Figure 54: Uplink traﬃc observed in scenario 6 (skip-dad). Traﬃc transmitted by mobile node was observed on correspondent node’s IPv6 layer at intervals no greater than 12ms.

Uplink traﬃc results for scenario 7 (server-dad) are presented in Fig. 22, in Section 4.7.2.

Figure 55: Uplink traﬃc observed in scenario 8 (remote-autoconf ). Traﬃc transmitted by mobile node was observed on correspondent node’s IPv6 layer at intervals no greater than 12ms. Simulation results 123

Figure 56: Uplink traﬃc observed in scenario 9 (address-params). Traﬃc transmitted by mobile node was observed on correspondent node’s IPv6 layer at intervals no greater than 12ms.

Figure 57: Uplink traﬃc observed in scenario 10 (remote-binding-update). Traﬃc transmitted by mobile node was observed on correspondent node’s IPv6 layer at intervals no greater than 12ms. 124 Simulation results

A.3. Experiment 3 execution

Discussion of results regarding this experiment is available in Section 4.6.3.

A.3.1. 802.16 Network Reentry

Summary results, presenting comparative comparison between scenarios, are presented in Fig. 29, in Section 4.8.2.

Figure 58: 802.16 Network Reentry measurements, in scenario 1 (basic)

Figure 59: 802.16 Network Reentry measurements, in scenario 2 (wimax-optim) Simulation results 125

Figure 60: 802.16 Network Reentry measurements, in scenario 3 (preference-255 )

Figure 61: 802.16 Network Reentry measurements, in scenario 4 (skip-initial-delay) 126 Simulation results

Figure 62: 802.16 Network Reentry measurements, in scenario 5 (rapid-commit)

Figure 63: 802.16 Network Reentry measurements, in scenario 6 (skip-dad) Simulation results 127

Figure 64: 802.16 Network Reentry measurements, in scenario 7 (server-dad)

Figure 65: 802.16 Network Reentry measurements, in scenario 8 (remote-autoconf ) 128 Simulation results

Figure 66: 802.16 Network Reentry measurements, in scenario 9 (address-params)

Figure 67: 802.16 Network Reentry measurements, in scenario 10 (remote-binding-update) Simulation results 129

A.3.2. IPv6 reconﬁguration time

For IPv6 reconﬁguration warm-up period selection, see Fig. 30. Summary results, presenting comparative comparison between scenarios, are presented in Fig. 31, in Section 4.8.3.

Figure 68: IPv6 reconﬁguration measurements in scenario 1 (basic)

Figure 69: IPv6 reconﬁguration measurements in scenario 2 (wimax-optim) 130 Simulation results

Figure 70: IPv6 reconﬁguration measurements in scenario 3 (preference-255 )

Figure 71: IPv6 reconﬁguration measurements in scenario 4 (skip-initial-delay) Simulation results 131

Figure 72: IPv6 reconﬁguration measurements in scenario 5 (rapid-commit)

Figure 73: IPv6 reconﬁguration measurements in scenario 6 (skip-dad) 132 Simulation results

Figure 74: IPv6 reconﬁguration measurements in scenario 7 (server-dad)

Figure 75: IPv6 reconﬁguration measurements in scenario 8 (remote-autoconf ) Simulation results 133

Figure 76: IPv6 reconﬁguration measurements in scenario 9 (address-params)

Figure 77: IPv6 reconﬁguration measurements in scenario 10 (remote-binding-update) 134 Simulation results

A.3.3. DHCP conﬁguration time

For DHCPv6 conﬁguration warm-up period selection, see Fig. 35. Summary results, presenting comparative comparison between scenarios, are presented in Fig. 34, in Section 4.8.4.

Figure 78: DHCPv6 conﬁguration measurements in scenario 1 (basic)

Figure 79: DHCPv6 conﬁguration measurements in scenario 2 (wimax-optim) Simulation results 135

Figure 80: DHCPv6 conﬁguration measurements in scenario 3 (preference-255 )

Figure 81: DHCPv6 conﬁguration measurements in scenario 4 (skip-initial-delay) 136 Simulation results

Figure 82: DHCPv6 conﬁguration measurements in scenario 5 (rapid-commit)

Figure 83: DHCPv6 conﬁguration measurements in scenario 6 (skip-dad) Simulation results 137

Figure 84: DHCPv6 conﬁguration measurements in scenario 7 (server-dad)

Figure 85: DHCPv6 conﬁguration measurements in scenario 8 (remote-autoconf ) 138 Simulation results

Uplink traﬃc results for scenario 9 (address-params) are presented in Fig. 33, in Section 4.8.4.

Figure 86: DHCPv6 conﬁguration measurements in scenario 10 (remote-binding-update)

A.4. Experiment 4 execution

Discussion of results regarding this experiment is available in Section 4.6.4.

A.4.1. Handover preparation

For handover preparation warm-up period selection, see Fig. 27. Summary results, presenting comparative comparison between scenarios, are presented in Fig. 28, in Section 4.8.1. Simulation results 139

Figure 87: Handover preparation measurements in scenario 2 (basic)

Figure 88: Handover preparation measurements in scenario 2 (wimax-optim) 140 Simulation results

Figure 89: Handover preparation measurements in scenario 3 (preference-255 )

Figure 90: Handover preparation measurements in scenario 2 (skip-initial-delay) Simulation results 141

Handover preparation results for scenario 5 (rapid-commit) are presented in Fig. 25, in Section 4.8.1.

Figure 91: Handover preparation measurements in scenario 6 (skip-dad)

Figure 92: Handover preparation measurements in scenario 7 (server-dad)

Handover preparation results for scenario 8 (remote-autoconf ) are presented in Fig. 26, in Section 4.8.1. 142 Simulation results

Figure 93: Handover preparation measurements in scenario 9 (address-params)

Figure 94: Handover preparation measurements in scenario 2 (remote-binding-update) Simulation results 143

A.4.2. Lack of communication capabilities

For lack of communication capabilities warm-up period selection, see Fig. 37. Summary results, presenting comparative comparison between scenarios, are presented in Fig. 36, in Section 4.8.5.

Figure 95: Lack of communication capabilities, scenario 1 (basic)

Figure 96: Lack of communication capabilities, scenario 2 (wimax-optim) 144 Simulation results

Figure 97: Lack of communication capabilities, scenario 3 (preference-255 )

Figure 98: Lack of communication capabilities, scenario 4 (skip-initial-delay) Simulation results 145

Figure 99: Lack of communication capabilities, scenario 5 (rapid-commit)

Figure 100: Lack of communication capabilities, scenario 6 (skip-dad) 146 Simulation results

Figure 101: Lack of communication capabilities, scenario 7 (server-dad)

Figure 102: Lack of communication capabilities, scenario 8 (remote-autoconf ) Simulation results 147

Figure 103: Lack of communication capabilities, scenario 9 (address-params)

Figure 104: Lack of communication capabilities, scenario 10 (remote-binding-update) 148 Simulation results B. Developed software

Two projects were started and developed during author’s Ph.D studies: Dibbler (a DHCPv6 implementation) and Numbat (IEEE 802.16/IPv6 simulation environment). Both projects are distributed as open source, published under GNU General Public License version 2.

B.1. Numbat – simulation environment

Neither OMNeT++, nor any of its available libraries, does provide support for 802.16 networks simulation. It oﬀers experimental support for IPv6 and Mobile IPv6, but this support relies on precise, but complicated and slow INET framework [103]. Therefore new environment was developed for the purpose of mobile IPv6 stations simulation in the 802.16 environment. This project was started in 2005 under the name Numbat [75]. Numbat provides means for simulation of 802.16 stations with advanced IPv6 stack on top.

Figure 105: Numbat environment example, depicting scenario with 5 subscribers and 3 base stations. State of the subscriber #4, its MAC and IPv6 layers are inspected

Following features were developed and are now supported in 802.16 layer: 150 Developed software

• 802.16e support – Implementation was based on 802.16-2005 [36] standard, often referred to as 802.16e or Mobile WiMAX.

• Simple radio/PHY layer – unicast (subscriber to base station) and multicast (base station to subscriber stations) transmissions

• OFDMA modulation – OFDMA-based PHY model, required for 802.16e simulation that includes CDMA codes, radio frame, and simpliﬁed subchannels/symbols/slots calculation

• Bandwidth management – Bandwidth Request (BWR), CDMA codes for ranging and bandwidth grants (proper UL-MAP and DL-MAP messages are generated)

• BE and UGS traffic – Two 802.16 classes of traffic are supported: Best Effort (BE) and Unsolicited Grant Service (UGS)

• Control plane – Network entry with all required stages: ranging (RNG-REQ, RNG-RSP messages), basic capabilities negotiation (SBC-REQ, SBC-RSP messages), cryptography (PKM-REQ, PKM- RSP) and network registration (REG-REQ, REG-RSP messages) are supported.

• Control plane: service ﬂow creation and management (DSA-REQ, DSA-RSP, and DSA-ACK message)

• Control plane: scanning, used to detect other nearby base stations (SCN-REQ, SCN-RSP messages)

• Control plane: subscriber initiated handover (MSHO-REQ, BSHO-RSP, and HO-IND messages) and network reentry

• Several mobility models: ﬁxed, handover after timeout, and distance based handover in several variations. For details, please see Section 4.1.5.

• Several optional optimizations allowed by 802.16-2005 standard. They can be enabled or disabled on a per subscriber or per scenario basis.

• Support for multiple subscribers (optimizations can be enabled on a per subscriber basis)

• Connection management and queuing

• Multiple base and subscriber stations support

On top of 802.16 layer, independent IPv6 family stack was implemented. Following features, among others, are provided:

• IPv6Node: traffic source/sink, with statistics and various traffic generation models. Traffic models are presented and discussed in Sections 4.1.5 and 4.7.4.

• RAGen/RArcv: Router Advertisement generator and receiver, used to conﬁgure routing in IPv6 nodes. Developed software 151

• DHCPv6cli: DHCPv6 client implementation that supports all of the existing and proposed enhancements.

• DHCPv6srv: DHCPv6 server implementation, intended for conﬁguration provision. It supports relays and all proposed enhancements.

• MIPv6mn: Simple implementation of the Mobile IPv6 Mobile Node.

• MIPV6cn: Simple implementation of the Mobile IPv6 Corresponding Node.

• MIPv6ha: Provides functionality of Mobile IPv6 Home Agent.

• IPv6disp: IPv6 dispatcher that intelligently redirects packets to speciﬁc modules. It is also mobility aware.

There are also number of several general purpose framework mechanisms that were implemented. Notable features are:

• Event signaling – Simple event signaling, allowing one module to notify others that certain event was started or completed. Thanks to this mechanism, developers don’t have to understand all already written code, just wait for specific event to occur. Those notifications are loosely based on the same principles as Media Independent Handover events, described in 802.21 specification [44].

• Event based FSM – Although OMNeT++ provides FSM implementation, it was not sufficient for intended purposes. One of the major limitations was the inability to maintain consistent state and ignore input. Workaround suggested by OMNeT++ User’s Guide [104] was to leave and return to the same state immediately. However, in 802.16 control plane, there are numerous operations that should be performed upon state change. As such, standard OMNeT++ approach was not suitable and new FSM was implemented. There are clearly defined states and events. State change diagrams can be plotted in a definite and consistent manner. For each state, following functions are defined: onEnter(), onEvent() and onExit(). States can be transitive or stationary. Also there is a well defined list of inputs for each FSM.

• Logger – Standard logging capabilities offered by OMNeT++ was also insufficient. Developed logger offers several logging level, from debugging to critical, offers several modes of time designations and provides name of the module that reported given message. Output can also be redirected to a file. Thanks to those features, it is possible to easily adjust size of a log file – detailed information during simulation development and debugging and only essential information during actual experiment.

B.1.1. Project impact

Numbat is distributed (as open source) from the project website [75]. As of July 2009, author received feedback from users residing in 8 countries: Poland, Germany, United States, Iran, Finland, China, Oman and Spain. One notable example of user feedback was received from DLR – german aerospace agency 152 Developed software that is working on a WiMAX deployment project. Its purpose is to deploy WiMAX in number of airports throughout the European Union. Author published several papers related to Numbat and research conducted using this tool. Two notable examples are [76] (Numbat architecture and capabilities overview, published at ATNAC’2007, an IEEE conference held in Christchurch, New Zealand) and [78] (Handover Improvement techniques, published at ATNAC’2008, an IEEE conference held in Adelaide, Australia). Numbat was also subject of 3 master theses (at Gdansk University of Technology) and major part of another three (in Poland, Turkey and Thailand). All 3 GUT students graduated with good marks and now hold M.Sc. degrees.

B.2. Dibbler – DHCPv6 implementation

Dibbler is a portable DHCPv6 solution, which features server, client, relay and requestor. Currently there are ports available for Windows XP, 2003 and Vista (support for NT4 and 2000 is considered experimental) and Linux 2.4/2.6 systems. It supports both stateful (i.e. IPv6 address granting) and stateless (i.e. options granting) autoconfiguration. Besides basic functionality (specified in base DHCPv6 specification, RFC3315 [22]), it also offers several enhancements, e.g. DNS servers and domain names configuration. Dibbler is an open source software, distributed under GNU GPL v2 license. It means that it is freely available, free of charge and can be used by anyone (including commercial users). Source code is also provided, so anyone skilled enough can fix bugs, add new features and distribute his/her own version. The Dibbler project has been started as master thesis of the two students of the Faculty of Electronics, Telecommunications and Informatics of Gdansk University of Technology in Poland. After graduation in September 2003, Dibbler is being developed by Tomasz Mrugalski as part of his Ph.D. studies.

B.2.1. Design assumptions

Dibbler project is based on the following design principles:

• Portable. DHCPv6 support on multiple platforms is poor and often non-existent, e.g. in pre-Vista MS Windows environment. Limiting implementation to only one or several chosen environments would greatly reduce importance of this project. Therefore produced code must be as portable as possible.

• Layered. To meet portability requirements, code is split to two layers. Higher, system independent layer is responsible for core logic of the protocol. It is implemented in C++. This language was chosen due to good object oriented mechanisms support as well as good portability. Lower layer is very small and is system dependent. It is responsible for network interface and system speciﬁc tasks, e.g. running as daemon in Linux or running as Windows service in Windows environment. This layer is coded in C.

• Extensible. The option concept in the DHCPv6 protocol was designed with future extensions in mind. Therefore implementation must be easily extensible. This was accomplished by using object Developed software 153

oriented features such as inheritance or polymorphism. This further strengthens C++ as a language of choice.

• Open. Author strongly believes in an open source development model. Among key advantages of this approach is easy access to the source code by all interested persons. Possibility to modify the code to suit speciﬁc individual needs is another advantage. In the author’s opinion, it is a duty of every scientist to share the results of his work. In computer science this can be easily accomplished by publishing source code and allowing other to exploit it. It is interesting to note that several students, as well as researchers and large industry employees from around the world have contacted author regarding various aspects of Dibbler implementation.

• Well documented. Lack of proper documentation is a common ﬂaw among open source projects. To avoid this, Dibbler should provide extensive manuals accompanied with multiple examples, User’s Guide for regular users and Developer’s Guide for potential developers to ease internal structure learning process.

B.2.2. Supported features

As of July 2009, Dibbler supports following features:

Figure 106: Dibbler usage in the most typical scenario: Several clients supported by single server.

• Basic server discovery and address assignment (Solicit, Advertise, Request and Reply messages) – This is a most common case: client discovers servers available in the local network, then asks for an address (and possibly additional options like DNS conﬁguration), which is granted by a server. Simple Dibbler deployment usage is shown in Fig.106. 154 Developed software

Figure 107: Dibbler redundancy example: several servers present on the same link. Clients have the liberty of choosing the best suitable server.

• Server redundancy/Best server discovery – when client detects more than one server available (by receiving more than one Advertise message), it chooses the best one and remembers remaining ones as a backup.

• Multiple servers support – Client is capable of discovering and maintaining communication with several servers. For example, client would like to have 5 addresses conﬁgured. Preferred server can only grant 3, so client chooses to use one of the remaining servers. This capability was depicted in Fig.107.

• Relay support – In a larger network, which contains several Ethernet segments and/or wireless access points, sometimes centrally located DHCPv6 server might not be directly reachable. In such case, additional proxies, so called relays, might be deployed to relay communication between clients and a remote server. Dibbler server supports indirect communication with clients via relays. Stand-alone, lightweight relay implementation is also available. Clients are capable of talking to the server directly or via relays.

• Address renewal – After receiving address from a server, client might be instructed to renew its address at regular intervals. Client periodically sends Renew message to a server, which granted its address. In case of communication failure, client is also able to attempt emergency address renewal (i.e. it sends Rebind message to any server).

• Unicast communication – if speciﬁc conditions are met, client could send messages directly to a server’s unicast address, so additional servers does not need to process those messages. It also Developed software 155

improves eﬃciency, as all nodes present in LAN segment receive multicast packets.1

• Duplicate address detection – Client is able to detect and properly handle faulty situation, when server grants an address which is illegally used by some other host. It will inform server of such circumstances (using Decline message), and request another address. Server will mark this address as used by unknown host, and will assign another address to a client.

• Power failure/crash support – After client recovers from a crash or a power failure, it still can have valid addresses assigned. In such circumstances, client uses Conﬁrm message, to verify if those addresses are still valid.

• Normal and temporary addresses – Depending on its purpose, client can be conﬁgured to ask for normal (IA NA option) or temporary (IA TA option) addresses. Although use of temporary addresses is rather uncommon, both dibbler server and client support it.

• Hint system – Client can be conﬁgured to send various parameters and addresses in the Solicit and Request message. It will be treated as a hint by the server. If such hint is valid, it will be granted for this client.

• Server caching – Server can cache granted addresses, so the same client will receive the same address each time it asks. Size of this cache can be conﬁgured.

• Stateless mode – Client can be configured to not ask for any addresses, but the configuration options only. In such case, when no addresses are granted, such configuration is called stateless (Information- request message is used instead of normal Request).

• Rapid Commit – Sometimes it is desirable to quicken conﬁguration process. If both client and server are conﬁgured to use rapid commit option, address assignment procedure can be shortened to two messages, instead of usual four. Major advantage is lesser network usage and quicker client startup time.

Except base speciﬁcation [22] behavior, Dibbler also supports several enhancements:

• DNS Servers – During normal operation, almost all hosts require constant use of the DNS servers. It is necessary for event basic operations, like web browsing. DHCPv6 client can ask for information about DNS servers and DHCPv6 server will provide necessary information. [23]

• Domain Name – Client might be interested in obtaining information about its domain. Properly configured domain allow reference to a different hosts in the same domain using hostname only, not the full domain name, e.g. alice.example.com with properly configured domain can refer to another host in the same domain by using ’bob’ only, instead of full name bob.example.com. [23]

1Nodes, which do not belong to speciﬁc multicast group, drop those packets silently. However, determining if host belongs or not to a group must be performed on each node. Also using multicast communication increases the network load. 156 Developed software

• NTP Servers – To prevent clock misconﬁguration and drift, NTP protocol [70] can be used to synchronize clocks. However, to use it successfully, location of near NTP servers must be known. Dibbler is able to conﬁgure this information. [52]

• Time Zone – To avoid time-related ambiguities, each host should have time zone set properly. Dibbler is able to pass this parameter to all clients, who request it.

• SIP Servers – Session Initiation Protocol (SIP) [92] is commonly used in VoIP solutions. One of the necessary information is SIP server addresses. This information can be passed to the clients. [93]

• SIP Domain Name – SIP domain name is another important parameter of the VoIP capable nodes. This parameter can be passed to all clients, who ask for it. [93]

• NIS, NIS+ Server – Network Information Service is a protocol for sharing authentication parameters between multiple Unix or Linux nodes. Both NIS and NIS+ server addresses can be passed to the clients. [51]

• NIS, NIS+ Domain Name – NIS or NIS+ domain name is another necessary parameter for NIS or NIS+. It can be obtained from the DHCPv6 server to all clients, who require it. [51]

• Option Renewal Mechanism (Lifetime option)– All of the options mentioned on this list can be refreshed periodically. This might be handy if one of those parameters change. [105]

• Dynamic DNS Updates – Server can assign a fully qualiﬁed domain name for a client. To make such name useful, DNS servers must be informed that such name is bound to a speciﬁc IPv6 address. This procedure is called DNS Update. There are two kinds of the DNS Updates: forward and reverse. First is used to translate domain name to an address. The second one is used to obtain full domain name of a known address. This example is depicted in Fig.108.

• Prefix Delegation – Server can be configured to manage a prefix pool, i.e. clients will be assigned whole pools instead on single addresses. This is very useful, when clients are not simple end users (e.g. desktop computers or laptops), but rather are routers (e.g. cable modems). This functionality is often used for remote configuration of IPv6 routers. [102]

B.2.3. Experimental features

Dibbler also serves as a testbed for experiments and practical validation environment for various proposals. Support for several uncommon or proposed features is available at various states of maturity:

• Address parameters – during normal operation, DHCPv6 grants addresses only, without any preﬁx information. Thus only the address itself can be conﬁgured, not the route entries associated with it. To overcome this limitation, address parameters may be also passed. For details regarding this feature, see Section 3.2.5. Developed software 157

Figure 108: Dibbler example: DNS Update. Several update scenarios are supported. Update can be performed by server or a client. During parameter assignment, client and server negotiate, which one will do the update. In this example, update is exersized by server.

• Delegated Prefix Handling – Once client receives prefix, it is being split to several shorter prefixes, one for each local network interface. Only interfaces that have routing enabled, are up and running, have IPv6 support are taken into consideration. This approach allows easy remotely configured router scenario. This scenario is presented in Fig.109.

• Tunnel configuration – Dibbler allows highly experimental tunnel configuration. IPv4 over IPv6 tunnels (softwires) are important part of the post IPv4-only networks. They are considered crucial step in the IPv4 to IPv6 migration. There is a separate IETF working group that is dedicated to softwire operation and configuration. For a legacy IPv4 traffic handling in IPv6-only networks, see [63].

• Relay redirection – To exploit remote automatic configuration (discussed in Section 3.2.4), a way of specifying destination server is required. During normal operation, relays are statically configured to forward traffic to one or more selected servers. Dibbler implementation offers several techniques, besides standard operation. One notable example is a “guess mode”. Once enabled, it allows relay to guess expected destination by taking into consideration number of message parameters. For details, see Dibbler’s User Guide [79].

B.2.4. Supported platforms

Dibbler runs on Linux systems with kernels from 2.4 and 2.6 series. IPv6 (compiled into kernel or as module) support is necessary to run dibbler. Dibbler also runs on Windows XP, 2003 and Vista. Recently support for Mac OS X was contributed by two independent users. That is a nice example of open source development model. Support for Windows NT4 and 2000 is limited and considered experimental. Due to lack of support and any kind of information from Microsoft, this state is not expected to change. 158 Developed software

Figure 109: Prefix delegation handled by dibbler. Prefix received from the server is split by the client to equal subprefixes used on available network interfaces.

Although Dibbler was developed on the i386 architecture, there are ports available for other architec- tures: IA64, AMD64, PowerPC, HPPA, Sparc, MIPS, S/390, Motorola m68k and Alpha.

B.2.5. Project impact

Project impact is discussed in detail in Section 5.1. C. List of Publications

1. T. Mrugalski, “Metoda szybkiego wdra˙zania IPv6 przy wykorzystaniu DHCPv6”, 2nd Information Technologies conference TI’2004, Gda´nsk, Poland

2. J. Wo´zniak; K. Nowicki; T. Mrugalski, “Problemy obs lugi u˙zytkownik´owruchomych, w skali mikro i makro, w sieciach IP” (Problems with Mobile users support in IP networks i micro and macro scale), 12th conference on Networks and Information Systems, SIS’2004, Lodz, 2004

3. T. Mrugalski, “Dibbler – a portable dynamic host conﬁguration protocol for IPv6 implementation”, Proceedings of 8th IEEE International Conferernce on Telecommunications, Zagreb, Croatia, 2005, Volume 1, June 15-17, 2005 Page(s):71 – 75 (IEEE Xplore)

4. T. Mrugalski“Problem stanowych zap´orogniowych w aspekcie wsparcia mobilno´sci”, 3rd Information Technologies conference, TI’2005, Gda´nsk, Maj 2005

5. J. Wo´zniak, P. Matusz, T. Mrugalski, M. Paw lowski, “Wireless Metropolitan Area Network as Emer- gency Response System”, Proceedings of the IEEE Int. Conf. on Technologies for Homeland Security and Safety – TEHOSS’2005, Gdansk, 2005, ISBN 83-917681-9-8

6. J. Wo´zniak, P. Matusz, K. Gier lowski, T. Gierszewski, T. Klajbor,P. Macha´n,T. Mrugalski, R. Wielicki, “Heterogeniczne sieci bezprzewodowe – wybrane problemy funkcjonowania” (Heterogenic

wireless networks – selected functional problems), Przeglad, Telekomunikacyjny. Wiadomo´sci Teleko- munikacyjne. Nr 2-3/2005

7. J. Wo´zniak, P. Machań,T. Mrugalski, T. Klajbor, K. Gier lowski “Algorytmy i mechanizmy koegzys- tencji oraz wspó lpracy heterogenicznych pakietowych systemówradiowych”, Elektronika – Kon- strukcje, Technologie, Zastosowania, 9/2007

8. J. Wo´zniak, K. Gier lowski, T. Gierszewski, P. Macha´n, T. Mrugalski, T. Klajbor, R. Orlikowski

“Postepy, w standaryzacji i analiza kierunk´owrozwoju pakietowych sieci bezprzewodowych”, Przeglad, telekomunikacyjny – wiadomo´scitelekomunikacyjne, 8/9 2007

9. T. Mrugalski, J. Wo´zniak, “Numbat – extensible simulation environment for mobile, IPv6 capable IEEE 802.16 stations”. Australasian Telecommunication and Network Applications Conference, Christchurch, New Zealand (2007), pp. 396-401, CD-ROM IEEE Catalog Number: 07EX2003C – ISBN 1-4244-1558-6 (IEEE Xplore)

10. T. Mrugalski, K. Nowicki, K. Wnuk, “Next generation automatic IP conﬁguration deployment issues”, 1st International Conference on Information Technology, 2008. IT 2008.; 18-21 May 2008 Gda´nsk, Poland (IEEE Xplore)

11. T. Mrugalski, J. Wo´zniak, “How to Improve the Eﬃciency of IPv6 Handovers in IEEE 802.16 Net- works”, Australasian Telecommunication Networks and Applications Conference, 2008. ATNAC 2008. 7-10 Dec. 2008 Page(s):282 – 287, Adelaide, Australia (IEEE Xplore) 160 List of Publications

12. T. Mrugalski, J. Wo´zniak, “Reconﬁguration Eﬃciency Analysis in IPv6 Handovers in IEEE 802.16 Environment”, Telecommunication Systems, Vol.45, No 2-3, 2010 (in press)

13. J. Brzozowski, J. Tremblay, J. Chen, T. Mrugalski, “DHCPv6 Redundancy Deployment Considera- tions”, draft-ietf-brzozowski-dhc-dhcpv6-redundancy-deployment-considerations-00.txt, IETF draft (work in progress), Oct. 2009 Index

4 message autoconfiguration, 35 DSA-RSP message, xxiv,4, 33, 68, 69, 150 802.16,1 Duplicate Address Detection, 37 802.16d-2004,1 Fast Binding Acknowledgement message, 19 802.16e-2005,1 Fast Binding Update message, 19 Advertise message, xxiv, 10, 23, 34, 35, 69, 153, FBack message, 19 154 FBU message, 19 all-nodes multicast address, 37 FHMIPv6, 25 Anonymous ranging,6 Foreign Agent, 19 ASN,4 HAck message, 19 Bandwidth Request message,3 Handover,6 base station,3,5,6,9, 32, 33 Handover Acknowledge message, 19 Best Effor,3 Handover Initiate message, 19 Binding Acknowledgement message, 12, 46, 100 HI message, 19 Binding Acknowledgment message, 21 HO-IND message,6, 47, 82, 86, 150 Binding Update message, 12, 21, 24, 44–46, 100 Home Agent, 44 break-before-make, 24 IA NA option, 38, 39, 155 BSHO-RSP message,6, 42, 150 IA TA option, 155 BWR message,3, 150 ICMP Redirect message, 23 CDMA code message,6 IETF, 18 CID Update option, 33 Information-request message, 155 CINR,5 IPv6,7 Confirm message, xxii, 11, 22, 155 jumbogram,7 Control Plane,3 Correspondent Node, 44 Least Squares Method, 64 cut-off point, 62 make-before-break, 24 DAD, 39 Media Independent Handover, 24 Data plane,3 Metropolitan Area Network,1 DCD message,5 mext WG, 18 Decline message, 11, 155 MIH, 24 DL-MAP message,3,5, 150 mip4 WG, 18 dna WG, 18 mipshop WG, 18 DSA-ACK message, xxiv,4, 68, 69, 150 Mobile IPv6, 18 DSA-REQ message, xxiv,4, 68, 69, 150 mobileip WG, 18 162 Index

MSHO-REQ message,6, 47, 150 Preference-255 option, 36 Previous Access Router, 19 NAR, 19 PRNG, 57 NCoA, 19 Proxy Router Advertisement message, 19 Neighbor Advertisement Acknowledge option, 20 PrRtAdv message, 19 Neighbor Advertisement message,5, 11, 26, 37 pseudo random number generator, 57 Neighbor Solicitation message, 11, 23, 37 Network entry,3 RA message, 44 New Access Router, 19 Ranging,6 New Care-of Address, 19 rapid-commit, 35 node,7 Rapid-commit option, 23, 34–36 rapid-commit option, xxiv, xxx Optimization Rebind message, 11, 154 — address-params, 43, 44, 119, 123, 128, 133, REG-REQ message, xxiv,4, 68, 69, 150 138, 142, 147 REG-RSP message, xxiv,4, 68, 69, 150 — basic, 134 remote-autoconf, 40 — preference-255, 34, 116, 121, 125, 130, 135, Renew message, 11, 154 140, 144 Reply message, xxiv, 10, 11, 23, 35, 39, 153 — rapid-commit, 35, 117, 122, 126, 131, 136, 141, Request message, 10, 23, 35, 38, 153, 155 145 residual, 64 — remote-autoconf, 39, 40, 118, 122, 127, 132, RNG-REQ message,4, 32, 150 137, 141, 146 RNG-RSP message,4,6, 32, 33, 68, 150 — remote-binding-update, 44, 46, 119, 123, 128, Round Trip Delay,5 133, 138, 142, 147 Router Advertisement message,9, 12, 20, 44, 56, — server-dad, 38, 39, 70, 118, 122, 127, 132, 137, 69 141, 146 Router Solicitation message,9, 23, 44 — skip-dad, 37, 70, 117, 122, 126, 131, 136, 141, RSSI,5 145 RtSolPr message, 19 — skip-initial-delay, 36, 116, 121, 125, 130, 135, 140, 144 SAA,9 — wimax-optim, 31, 116, 120, 124, 129, 134, 139, SAID, 33 143 SAID update option, 33 SBC-REQ message, xxiii,4,5, 68, 69, 150 PAR, 19 SBC-RSP message, xxiii,4, 68, 69, 150 PKM-EAP-REQ message, xxiii scanning,5 PKM-EAP-RSP message, xxiv SCN-REP message,5 PKM-REQ message, 150 SCN-REQ message, 150 PKM-RSP message, 150 SCN-RSP message,5, 150 Preference option, xxiv, 34, 35 Security Association ID, 33 preference-255, 34 Security Association, 33 Index 163 seed, 58 Serving Base Station,4,5 skip-dad, 37 skip-initial-delay, 36 Solicit message, xxiv, 10, 23, 34, 35, 38, 153, 155 Stateful Autoconﬁguration, 10 Stateless Autoconﬁguration,9 Stateless DHCPv6, 11 subscriber station,5, 33, 34, 46

Target Base Station,4,5

UGS,3 UL-MAP message,3, 150 UNA message, 19 Unsolicited Neighbor Advertisement message, 19

WiMAX optimizations, 31