Sie sind auf Seite 1von 131

ABSTRACT

SONG, JUNG KEE. Performance Evaluation of Hando between UMTS/802.11b based on Mobile IP and Stream Control Transmission Protocol. (Under the direction of Professor Wenye Wang). Various wireless networks, contemporarily, have evolved as prime communication methods, encountering convergence paradigm among heterogeneous technologies including applications based on IP, which has given enormous impacts in our way of life because of its proved robustness and scalability as well as ample services. With the synergy of the two technologies, ubiquitous access to all-IP information sources has become reality. For wireless IP services, IP mobility is one of the major issues that should be resolved. Especially, the performance of hando mechanism is a pithy issue that determines the performance of application level services. Although Mobile IP (MIP) and its extensions, as network layer solutions, have been proposed and standardized, their hando mechanisms bring unavoidable transmission throughput degradation due to packet loss, registration delay, and transport layer blocking. Moreover, to accommodate MIP, signicant quantity of modications should be brought into each heterogeneous network architecture. In this thesis, we evaluate the performance of a transport layer hando approach, mobile SCTP (mSCTP), and compare it with that of a network layer solution, MIP. mSCTP is based on Stream Control Transmission Protocol (SCTP), the third general purpose transport layer protocol, standardized by IETF. SCTP conceptually enables seamless hando in transport layer without any change in IP protocol stack by its multi-homing feature and dynamic address reconguration (DAR) extension. We analyze the performance of mSCTP and MIP by introducing hando delay, end-to-end transmission throughput, and packet loss, and conduct a simulation study of the two protocols in 802.11b WLAN-only and UMTS/802.11b integrated networks using NS-2 network simulator.

Performance Evaluation of Hando between UMTS/802.11b based on Mobile IP and Stream Control Transmission Protocol by Jung Kee Song A thesis submitted to the Graduate Faculty of North Carolina State University in partial satisfaction of the requirements for the Degree of Master of Science

Department of Computer Science Raleigh 2005

Approved By:

Dr. Arne A. Nilsson

Dr. David Thuente

Dr. Wenye Wang Chair of Advisory Committee

ii

To my parents,

Dong Soo Song and Jeum Soon Son.

iii

Biography
Jung Kee Song was born and grew up in Seoul, Korea. He received his Bachelors degree in Computer Science from Kwangwoon University, Seoul, Korea, in February 1999. He had worked for DreamData, Inc., Seoul, Korea, as a software engineer from November 1998 to May 2002. He has been a Masters student in the Department of Computer Science at North Carolina State University since August 2003. He will work for Samsung Electronics Co., Ltd., Telecommunication Network Business, as an engineer, starting Fall 2005.

iv

Acknowledgements
A special thanks to Dr. Wenye Wang, my advisor, for her support and commitment. I would like to thank her for all her eorts guiding me throughout my research and sharing my personal diculties. I am also grateful to her for a great work environment she has provided me during my research. It has been my pleasure and honor working with her. I would like to thank Dr. Arne A. Nilsson and Dr. David Thuente for being on my advisory committee and providing valuable comments on my research. I would like to thank my colleagues in NetWIS Lab, Wei Liang, Avesh Agarwal, Nurcan Tezcan, Ming Zhao, Fei Xing, and Nagalakshmi Mahali for their advices and encouragements throughout the entire duration of my research and thesis preparation. I would like to thank my friends, Young June Pyun, Jang Eun Jun, and many others for their concerns and precious time when I was in need. They have been of great help and pleasure to my life in Raleigh. I also would like to thank my grandmother and parents for their endless love, support, and everything they have provided me for the whole my life. I appreciate their patience and trust on my long pursuit of study. I would not have accomplished this without them. I am grateful to my sister and brother-in-law for taking care of them in my absence.

Contents
List of Figures List of Tables 1 Introduction 1.1 Wireless IP Networks: the Future 1.2 The Need for IP Mobility . . . . 1.3 Motivation and Contributions . . 1.4 Related Works . . . . . . . . . . viii xi 1 1 3 3 5 8 8 9 14 15 16 16 17 24 28 30 30 32 32 34 36 36 38 40 42

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

2 IP Mobility: Hando Solutions 2.1 Mobile IP: A Network Layer Approach . . . . . . . . . . . 2.1.1 Agent Discovery and Registration . . . . . . . . . . 2.1.2 Mobility-Transparent Packet Forwarding: Tunneling 2.1.3 Problems . . . . . . . . . . . . . . . . . . . . . . . . 2.1.4 Enhancement Eorts . . . . . . . . . . . . . . . . . 2.2 mobile SCTP: A Transport Layer Approach . . . . . . . . . 2.2.1 Stream Control Transmission Protocol (SCTP) . . . 2.2.2 Dynamic Address Reconguration (DAR) . . . . . . 2.2.3 mSCTP: Make-Before-Break with Multi-Homing and

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DAR

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

3 Vertical Hando Architecture in Heterogeneous Networks 3.1 Network and Service Convergence: Trend . . . . . . . . . . . 3.2 IP-based Vertical Hando in UMTS/802.11b . . . . . . . . . 3.2.1 Mobile IP Vertical Hando . . . . . . . . . . . . . . . 3.2.2 mobile SCTP Vertical Hando . . . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

4 Performance Analysis of Mobile IP and mobile SCTP Hando 4.1 Hando Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Hando Delay in Mobile IP: TM IP . . . . . . . . . . . . . . . . . 4.1.2 Hando Delay in mobile SCTP: TmSCT P . . . . . . . . . . . . . 4.1.3 Comparison of Hando Delay in MIP (TM IP ) and mSCTP (TmSCT P )

vi 4.2 End-to-End Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 End-to-End Throughput in Mobile IP: M IP . . . . . . . . . . . 4.2.2 End-to-End Throughput in mobile SCTP: mSCT P . . . . . . . 4.2.3 Comparison of End-to-End Throughput in MIP and mSCTP . . Packet Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Packet Loss in Mobile IP: LM IP . . . . . . . . . . . . . . . . . . 4.3.2 Packet Loss in mobile SCTP: LmSCT P . . . . . . . . . . . . . . 4.3.3 Comparison of Packet Loss in MIP (LM IP ) and mSCTP (LmSCT P ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 45 47 48 49 49 50 50 51 51 52 53 57 57 58 61 69 76 77 81 86 86 92 98 98 100

4.3

5 Simulation and Results 5.1 NS-2 and Related Modules . . . . . . . . . . . . . . . . . 5.1.1 NS-2 Network Simulator . . . . . . . . . . . . . . 5.1.2 Related Modules . . . . . . . . . . . . . . . . . . . 5.2 System Models, Protocols, and Scenarios . . . . . . . . . 5.2.1 Assumptions . . . . . . . . . . . . . . . . . . . . . 5.2.2 Network Architecture . . . . . . . . . . . . . . . . 5.2.3 Protocol Stacks . . . . . . . . . . . . . . . . . . . . 5.2.4 Simulation Scenarios . . . . . . . . . . . . . . . . . 5.3 Simulation Results of 802.11b WLAN-only Network . . . 5.3.1 Uplink Behaviors . . . . . . . . . . . . . . . . . . . 5.3.2 Downlink Behaviors . . . . . . . . . . . . . . . . . 5.4 Simulation Results of UMTS/802.11b Integrated Networks 5.4.1 Uplink Behaviors . . . . . . . . . . . . . . . . . . . 5.4.2 Downlink Behaviors . . . . . . . . . . . . . . . . . 5.5 Further Discussion . . . . . . . . . . . . . . . . . . . . . . 5.5.1 Randomness in the Simulation . . . . . . . . . . . 5.5.2 Impact of Hando Rate in the Simulation . . . . .

6 Conclusion and Future Work 102 6.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 6.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Bibliography A NS-2 Simulation A.1 Network Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . A.1.1 Network Architecture-1: 802.11b WLAN-Only Network . . . A.1.2 Network Architecture-2: UMTS/802.11b Integrated Networks A.2 Protocol Stacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.2.1 MIP+TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.2.2 MIP+SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.2.3 mSCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.3 Hando Rate and MN movement . . . . . . . . . . . . . . . . . . . . A.3.1 802.11b WLAN-Only Network . . . . . . . . . . . . . . . . . A.3.2 UMTS/802.11b Integrated Networks . . . . . . . . . . . . . . 106 110 110 110 111 112 112 112 113 115 115 115

. . . . . . . . . .

. . . . . . . . . .

vii A.4 Trac . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 B FAQs 117 B.1 How has NS-2 SCTP module been used in wireless topology? . . . . . . 117 B.2 How many simulations did you run for each scenario? . . . . . . . . . . 119

viii

List of Figures
2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17 2.18 2.19 3.1 3.2 3.3 3.4 3.5 5.1 5.2 Agent Discovery and Registration in MIP . . . . . . . . . . . . . . Agent Solicitation Message Format [RFC2002] . . . . . . . . . . . . Agent Advertisement Message Format [RFC2002] . . . . . . . . . . Registration Request Message Format [RFC2002] . . . . . . . . . . Registration Reply Message Format [RFC2002] . . . . . . . . . . . Tunneling in MIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . Minimal Tunneling Header Message Format [RFC2004] . . . . . . . SCTP Association . . . . . . . . . . . . . . . . . . . . . . . . . . . Multi-Session from an SCTP Endpoint . . . . . . . . . . . . . . . . mSCTP Multi-Homing . . . . . . . . . . . . . . . . . . . . . . . . . SCTP Association Setup . . . . . . . . . . . . . . . . . . . . . . . . SCTP Association Close . . . . . . . . . . . . . . . . . . . . . . . . SCTP Common Header [RFC2004] . . . . . . . . . . . . . . . . . . ASCONF Parameter: Add IP Address (add-IP) . . . . . . . . . . . ASCONF Parameter: Delete IP Address (delete-IP) . . . . . . . . ASCONF Parameter: Set Primary IP Address (set-primary-IP) . . DAR: ASCONF Chunk Format . . . . . . . . . . . . . . . . . . . . DAR: ASCONF-ACK Chunk Format . . . . . . . . . . . . . . . . . mSCTP Hando Signaling with Multi-Homing and DAR Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10 11 13 14 14 15 18 19 19 21 21 22 25 26 26 27 27 29 31 33 34 35 35 52

Network and Service Convergence . . . . . . . . . . . . . . . . . . . . . . Mobile IP Vertical Hando Architecture: UMTS(3GPP R99)/802.11b . Mobile IP Vertical Hando Architecture: UMTS(3GPP R5)/802.11b . . mobile SCTP Vertical Hando Architecture: UMTS(3GPP R99)/802.11b mobile SCTP Vertical Hando Architecture: UMTS(3GPP R5)/802.11b NS-2 and the Related Modules used in the Simulation . . . . . . . . . . Network Architecture-1: (a) 802.11b WLAN-Only Network (b) NS-2 Node Topology for Mobile IP + TCP and Mobile IP + SCTP (c) NS-2 Node Topology for mobile SCTP . . . . . . . . . . . . . . . . . . . . . .

59

ix 5.3 Network Architecture-2: (a) UMTS/802.11b integrated network (b) NS-2 Node Topology for Mobile IP + TCP and Mobile IP + SCTP (c) NS-2 Node Topology for mobile SCTP . . . . . . . . . . . . . . . . . . . . . . MIP+TCP Protocol Stack in 802.11b WLAN Topology . . . . . . . . . MIP+TCP Protocol Stack in UMTS Topology . . . . . . . . . . . . . . MIP+SCTP Protocol Stack in 802.11b WLAN Topology . . . . . . . . . MIP+SCTP Protocol Stack in UMTS Topology . . . . . . . . . . . . . . mSCTP Protocol Stack in 802.11b WLAN Topology . . . . . . . . . . . mSCTP Protocol Stack in UMTS Topology . . . . . . . . . . . . . . . . Simulation Scenario Category (SIM-N-P -D ) . . . . . . . . . . . . . . Hando Rate (Occurrences of Hando) . . . . . . . . . . . . . . . . . . Pseudo Code: MN Movement Generation . . . . . . . . . . . . . . . . . MN Movement Pattern for 802.11b WLAN-Only Network: SIM-N1-P -D MN Movement Pattern for UMTS/802.11b Integrated Networks: SIMN2-P -D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hando Behavior in 802.11b WLAN-Only Network (Uplink): SIM-N1P -D1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Total Hando Delay in 802.11b WLAN-Only Network (Uplink): SIMN1-P -D1 (95% Condence Interval) . . . . . . . . . . . . . . . . . . . . End-to-end Throughput in 802.11b WLAN-Only Network (Uplink): SIMN1-P -D1 (95% Condence Interval) . . . . . . . . . . . . . . . . . . . . Packet Loss in 802.11b WLAN-Only Network (Uplink): SIM-N1-P -D1 (95% Condence Interval) . . . . . . . . . . . . . . . . . . . . . . . . . . Hando Behavior in 802.11b WLAN-Only Network (Downlink): SIMN1-P -D1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Total Hando Delay in 802.11b WLAN-Only Network (Downlink): SIMN1-P -D2 (95% Condence Interval) . . . . . . . . . . . . . . . . . . . . End-to-end Throughput in 802.11b WLAN-Only Network (Downlink): SIM-N1-P -D2 (95% Condence Interval) . . . . . . . . . . . . . . . . . Packet Loss in 802.11b WLAN-Only Network (Downlink): SIM-N1-P D2 (95% Condence Interval) . . . . . . . . . . . . . . . . . . . . . . . . Hando Behavior in UMTS/802.11b Integrated Networks (Uplink): SIMN2-P -D1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Total Hando Delay in UMTS/802.11b Integrated Networks (Uplink): SIM-N2-P -D1 (95% Condence Interval) . . . . . . . . . . . . . . . . . End-to-End Throughput in UMTS/802.11b Integrated Networks (Uplink): SIM-N2-P -D1 (95% Condence Interval) . . . . . . . . . . . . . Packet Loss in UMTS/802.11b Integrated Networks (Uplink): SIM-N2P -D1 (95% Condence Interval) . . . . . . . . . . . . . . . . . . . . . . Hando Behavior in UMTS/802.11b Integrated Networks (Downlink): SIM-N2-P -D2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Total Hando Delay in UMTS/802.11b Integrated Networks (Downlink): SIM-N2-P -D2 (95% Condence Interval) . . . . . . . . . . . . . . . . .

5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13 5.14 5.15 5.16 5.17 5.18 5.19 5.20 5.21 5.22 5.23 5.24 5.25 5.26 5.27 5.28

60 62 63 64 65 67 68 70 72 73 74 75 77 78 79 81 82 83 84 86 87 88 89 91 93 94

x 5.29 End-to-End Throughput in UMTS/802.11b Integrated Networks (Downlink): SIM-N2-P -D2 (95% Condence Interval) . . . . . . . . . . . . . 5.30 Packet Loss in UMTS/802.11b Integrated Networks (Downlink): SIMN2-P -D2 (95% Condence Interval) . . . . . . . . . . . . . . . . . . . .

95 96

xi

List of Tables
1.1 1.2 1.3 2.1 2.2 5.1 5.2 5.3 IP Mobility Research in WLAN . . . . . . . . . . . . . . . . . . . . . . . IP Mobility Research in 3G . . . . . . . . . . . . . . . . . . . . . . . . . IP Mobility Research in UMTS/WLAN . . . . . . . . . . . . . . . . . . SCTP Chunk Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DAR: Address Conguration Chunks . . . . . . . . . . . . . . . . . . . . 802.11b WLAN and Wireless Physical Congurations in the Simulation Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UTRAN and Wireless Physical Conguration in the Simulation Model . Simulation Scenarios (See Figure 5.10, Section 5.2.2, and Section 5.2.3) . 6 6 7 23 26

56 57 71

Chapter 1

Introduction
1.1 Wireless IP Networks: the Future
The Internet protocol suite has become one of the most essential and prevalent networking technologies in computer networks as well as telecommunication networks. Based on its layered architecture and packet switching capability, IP technology oers unied, exible and scalable services to various applications over many heterogeneous networks. IP technology also enables cost ecient business transactions in highly advanced forms of user applications. The benets of IP, in turn, make todays research and business move toward all-IP era. Contemporarily, wireless technology eradicated the limitation of user mobility, which is originally ascribed to xed wires. As wireless technology evolved, mobile users have become able to connect to various wireless information systems with dierent purposes. Among various wireless access technologies, wireless local area networks (WLAN) and cellular networks have turned out to be the most widely deployed infrastructures providing mobile access to voice and data services upon users needs. The two technologies have dierent characteristics in terms of physical specications. WLAN, standardized as 802.11b, 802.11g, and 802.11a, provides fairly fast data rates to nomadic users. Among the specications, 802.11b is the most widely deployed standard using 2.4 GHz frequency band providing up to 11 Mbps data rates within a

2 few hundred meters range. On the other hand, cellular networks are, inherently, designed to cover much wider areas with relatively low bandwidth. Second generation (2G), GSM and CDMA networks, 2.5G, the General Packet Radio Service (GPRS) and Enhanced Data rates for Global Evolution (EDGE) networks, and emerging third generation (3G) Universal Mobile Telecommunications System (UMTS), CDMA2000 1x Evolution Data and Voice (EV-DV) are the major commercial cellular networks. For instance, 3G UMTS is designed to support up to 384 Kbps data rate for pedestrian users and 2Mbps rate for vehicular users within a few kilometers coverage areas. In this reason, exploiting their complimentary advantages, WLAN and 3G cellular networks can oer good quality of convergent services in a complimentary form. Due to the advantages of IP protocol and wireless technology, we have encountered wireless IP era based on their synergic eects. Having succeeded already, copious IP applications are to be ported into wireless services for mobile users. It is an apparent trend that IP leads the existing wireless access technologies to evolve into all-IP-based networks. The next generation all-IP wireless networks will enable us to exploit all the IP-based services in ubiquitous manner. To achieve the unied IP-based wireless networks and services, the integration of the existing networks and technologies are required. In the evolution of wireless IP networks, we encounter quite a few problems. IP mobility is an importunate topic among them. Due to the inherent properties of wireless communication networks, hando between two independent physical networks are inevitable. Hando procedures aect the overall performance of application level services. Since wireless IP networks provide IP applications and services to mobile users, IP-based seamless hando solution is required. Moreover, in order to integrate heterogeneous networks, IP-based vertical hando solution is also needed. In the thesis, we discuss two IP-based hando solutions, Mobile IP (MIP), a network layer solution, and mobile SCTP (mSCTP), a transport layer solution in 3G and WLAN integrated networks.

1.2

The Need for IP Mobility


IP protocol has been designed based on the assumption that nodes have per-

manent IP addresses which are xed at particular points in the Internet. The concept of IP address had not been a problem before we encountered needs of change of point of attachment of nodes. In order to support node movements in IP networks, mobility management should be supported with the original protocol specication. Mobility management contains two components: location management and hando management [6]. Location management is a nodes location update process to allow its up-to-date location to be informed by other nodes while hando management is to maintain on-going connections irrespective of node movements between independent networks. In the thesis, we focus on the latter: the performance of hando management. The basic functionalities required in IP-based hando solutions include a node movement detection when a node moves across a new IP subnet, and a mobilitytransparent packet transmission. To support IP-based hando, quite a few solutions have been proposed as network layer solutions including MIP, HAWAII [30], Cellular IP [13], and IDMP [26]. HAWAII, a domain-based mobility solution, Cellular IP, and IDMP are micro-mobility solutions proposed to solve out the signaling overhead problem of macro-mobility when a node frequently moves in foreign domain. MIP is an Internet standard to support network layer mobility. MIP hando consists of two phases: agent discovery and registration. Although the proposed IP-based hando solutions solved the fundamental problem of node movement in the Internet, they still incur signicant hando delays which aect the quality of applications and services, especially in mobility-oriented environments. Hence, seamless IP-based hando solutions are denitely required for future wireless IP networks.

1.3

Motivation and Contributions


We have addressed current trend toward wireless IP networks and network

convergence. We have also noted that IP-based mobility solutions are in the pithy parts of the evolution toward unied all-IP wireless networks. In future wireless IP networks, the performance of IP-based hando solutions will determine the performance

4 and reliability of the system and services. As discussed in Section 1.2, many legacy IP-based hando solutions have been proposed as network layer solutions since the role of network layer is the manipulation of IP address and packet forwarding. Although MIP is a representative network layer hando solution which has been widely deployed, it cannot avoid inherent decits: registration and tunneling overhead. Meanwhile, we will discuss a new method of IP-based hando in transport layer using Stream Control Transmission Protocol (SCTP) [35]. SCTP provides a multihoming feature with which a mobile node can hold multiple IP connections at a given moment. Based on multi-homing feature of SCTP, an extension, called dynamic address reconguration (DAR) [34], has been proposed as an Internet draft. DAR consists of pairs of request and response messages to update IP address information between two end nodes. The multi-homing feature of SCTP and DAR extension enables a transport layer seamless hando by eliminating registration delay and tunneling overhead. Hence, we have brought our attention to the performance evaluation of the two IP-based hando solutions, MIP and mSCTP, in wireless IP convergent networks. MIP, as a network layer solution, has been an Internet standard and most widely deployed but also incurs signicant hando delay. mSCTP, on the other hand, does not incur signicant hando delay based on the multi-homing feature of SCTP and DAR extension. In that, we have a strong motivation in studying and comparing mSCTP, a new transport layer solution, with MIP such that we verify the feasibility of the transport layer hando comparing to MIP in future wireless IP networks. In the thesis, we study the mechanism of MIP and mSCTP, and introduce three performance metrics to compare the performance of MIP and mSCTP. These three performance metrics include total hando delay, end-to-end throughput, and packet loss. With the three performance metrics, we conduct an analysis and a simulation study using NS-2 network simulator [1] to evaluate the performance of MIP and mSCTP in UMTS/802.11b integrated networks. We have observed the following characteristics of mSCTP over MIP: Total hando delay of mSCTP is constant regardless of hando rate while that of MIP increases proportional to hando rate and period a mobile node resides in foreign links.

5 End-to-end throughput of mSCTP is constant irrespective of hando rate while that of MIP decreases proportional to hando rate. mSCTP does not incur any packet loss based on its zero hando delay while packet loss of MIP increases proportional to hando rate such that transport layer transmission behavior can have negative eects. mSCTP does not require any third party agent while MIP needs additional eorts with the integration of agents into legacy architectures. This implies that mSCTP is easier to be deployed in heterogeneous networks. To the best of our knowledge, it is a unique contribution of our thesis that we evaluate and compare the performance of network layer hando solution, MIP, and that of the transport layer hando solution, mSCTP, in UMTS/802.11b integrated network to verify the feasibility of mSCTP in future wireless IP networks.

1.4

Related Works
As the importance of IP-based mobility has increased, quite a few research

eorts have been made in many aspects. Here, we list the previous works related to the same aspects in which we have pursued our research. We targeted three hando protocols, TCP over MIP (MIP+TCP), SCTP over MIP (MIP+SCTP), and mSCTP, with regard to three performance parameters, hando delay, end-to-end throughput, and packet loss. MIP+TCP and MIP+SCTP are protocol stacks to evaluate MIP performance. MIP+SCTP has been used in our simulation such that MIP and mSCTP can be fairly compared based on the same transport layer protocol, SCTP. Table 1.1 shows the related works done in WLAN-only networks. [17] sug-

gested a transport layer hando mechanism, Transport Layer Seamless Handover for Mobile Networks (TraSH). TraSH provides a transport layer hando based on multihoming feature of SCTP. Unlike MIP, TraSH separated the new-IP discovery signaling procedure from data transfer procedure. TraSH also proposes a new location management mechanism which can be integrated into DNS services. Another transport layer mobility mechanism has been suggested in [22]. This paper also proposes a seamless hando solution using mSCTP. Unlike in TraSH, MIP is

Table 1.1: IP Mobility Research in WLAN

E2E Throughput

MIP+TCP Fu03 [17]

MIP+SCTP Fu03 HPSR [15] Noonan02 ITT [27]

Hando Delay

Packet Loss

Other Parameters

Aydin03 ICC [8] Fu03 [17] Hsieh03 INFO [19] Aydin03 ICC [8] Fu03 [17] Hsieh03 INFO [19] Fu03 [17] Hsieh03 INFO [19]

mSCTP Koh04 CL [21] Fu03 [17] Noonan02 ITT [27] Aydin03 ICC [8] Fu03 [17] Aydin03 ICC [8] Fu03 [17] Koh04 ACT [22] Fu03 [17]

used for location management of MN when a correspondent node (CN) initiates a data transmission to a mobile node (MN). This paper also deals with mSCTP over MIP and nally compares the mechanism of mSCTP with that of MIP. This paper has addressed the procedure of hando and location management, not focusing on performance issues but on structures. [8] proposed yet another transport layer approach to Internet mobility using multi-homing feature of mSCTP. Table 1.2: IP Mobility Research in 3G MIP+TCP E2E Throughput Hando Delay Packet Loss Other Parameters MIP+SCTP mSCTP

Bajwa02 ISCON [9]

Table 1.2 shows the related works done in 3G networks. Although the trend of 3G networks is to be evolved into all-IP networks, the current research has not targeted IP-based mobility in 3G-only networks. [9] provided MIP evaluation in 3G networks. Table 1.3 shows the related works done in UMTS/WLAN integrated networks. [12] and [11] discuss the integration of UMTS and WLAN in architectural aspects. They introduced two alternative architectures: tightly-coupled and loosely-coupled interwork-

Table 1.3: IP Mobility Research in UMTS/WLAN E2E Throughput Hando delay Packet loss Other Parameters MIP+TCP Matusz03 LCN [25] Matusz03 LCN [25] Buddhikot [12] Buddhikot03 INFO [11] MIP+SCTP mSCTP Ma04 W.Comm. [23] Ma04 W.Comm. [23]

ing. [11] also includes experimental results of MIP agent performance and their proposed QoS mechanisms in this architecture. [23] introduced transport layer protocol, SCTP, and discuss the transmission behavior and throughput in the integrated networks. The thesis consists of 6 chapters each of which describes the following: Chapter 2 IP Mobility: Hando Solutions reviews the mechanism of MIP and mSCTP. In Section 2.1, MIP is explained as a network layer hando solution and the related problems are discussed. In Section 2.2, mSCTP, a transport layer approach, is introduced with multihoming feature of SCTP. We discuss the fundamental dierences between the network layer approach and the transport layer approach. In Chapter 3 Vertical Hando Architecture in Heterogeneous Networks, we discuss the current trend of network and service convergence and example vertical hando architectures using IP-based hando. That is, MIP and mSCTP hando architectures in UMTS/802.11b integrated network. In Chapter 4 Performance Analysis of Mobile IP and mobile SCTP Hando, we conduct the performance analysis of MIP and mSCTP in terms of hando delay, end-to-end throughput, and packet loss. The corresponding NS-2 simulation study are followed in Chapter 5 Simulation and Results. Finally, Chapter 6 Conclusion and Future Work concludes the thesis with future works and discussions.

Chapter 2

IP Mobility: Hando Solutions


In this chapter, we describe two IP-based hando solutions: a network layer approach, Mobile IP (MIP) and, a transport layer approach, mobile SCTP (mSCTP) that are evaluated in this study. First, we will describe the basic mechanism of MIP: agent discovery, registration, and tunneling. Then, Stream control transmission protocol (SCTP) and dynamic address reconguration (DAR) extension of SCTP are covered to examine mSCTP mechanism.

2.1

Mobile IP: A Network Layer Approach


Mobile IP (MIP) is a network layer mobility solution for wireless IP networks.

MIP denes three basic components: MN HA A mobile node that wanders within MIP network. An home agent, which is a special agent sitting on a router located in

MNs home link. MN is initially given an IP address, called home address, in its home network. FA A foreign agent, which is another special agent built in a router residing

in foreign links.

9 These three components cooperate to locate and register the current IP address of an MN as it moves across dierent IP subnets. MIP is also designed to provide mobility transparent packet transmission service, called tunneling, to upper layer protocols. MIP became an Internet standard based on its network layer mobility capability, but incurs signicant hando delay due to its registration procedure and tunneling overhead. The hando delay also brings performance degradations to connectionoriented Internet applications. In this section, we discuss the procedure of MIP hando: agent discovery, registration, and tunneling. We also introduce several enhancement efforts that have been aimed to improve MIP performance.

2.1.1

Agent Discovery and Registration


MIP hando consists of two phases: agent discovery and registration. Agent

discovery is a period in which an MN detects its movement from one subnet to another and obtains a new IP address, called Care-of-Address (CoA). Registration is a procedure in which an MN informs the HA its CoA, and the HA advertises the reachability of the MN to other routers.

MIP handoff: Agent Discovery and Registration


(4)

HA
(3)

Internet
(1) (2)

FA

MN Agent Discovery
(1) Agent Solicitation (2) Agent Advertisement

Registration
(3) Registration Request (4) Registration Response

Figure 2.1: Agent Discovery and Registration in MIP

Figure 2.1 shows agent discovery and registration period of MIP: message (msg)

10 (1) and msg (2) are agent discovery messages; msg (3) and msg (4) are registration messages exchanged during an MIP hando. The details of agent discovery and registration are followed.

1. Agent Discovery Through agent discovery period, an MN tries to detect its movement in a new subnet and, if so, it obtains a CoA of the foreign link. Agent discovery period is composed of two messages: msg (1) agent solicitation, msg and (2) agent advertisement (see Figure 2.1). Although FA broadcasts msg (2) agent advertisement message periodically, an MN can actively request msg (2) agent advertisement by sending an msg (1) agent solicitation. By sending an msg (1) agent solicitation, an MN can trigger a hando more promptly. Figure 2.2 shows the message format of agent solicitation dened in [RFC2002] [28].
0 8 16 24 32

VER=4

IHL Type of Service Total Length Identification Flags Fragment Offset Time to Live=1 Protocol=ICMP Header Checksum Source Address=MN home address Destination Address=broadcast (255.255.255.255) or multicast (224.0.0.2) Type=10 Code=0 Checksum Reserved

IP Header

ICMP Router Solicitation

Figure 2.2: Agent Solicitation Message Format [RFC2002] Agent solicitation message format is derived from the ICMP router solicitation message format. The message format is exactly the same as that of ICMP router solicitation. It should be noticed that Time to Live eld is set to 1 to probe one-hope only. Source Address eld is set with an MNs home address, and Destination Address eld is lled with normal broadcast or multicast address. Type eld in ICMP portion of the message is set to 10 which denotes ICMP solicitation. Other elds are lled according to regular IP header and ICMP message specications. Once an agent received msg (1) agent solicitation (see Figure 2.1), the agent broadcasts an msg (2) agent advertisement message. Figure 2.3 shows the message format of msg (2) agent advertisement. Msg (2) agent advertisement (see Figure 2.1) message format is also derived

11
0 8 16 24 32

VER=4

IHL Type of Service Total Length Identification Flags Fragment Offset Time to Live Protocol=ICMP Header Checksum Source Address=HA and/or FA address Destination Address=broadcast (255.255.255.255) or multicast (224.0.0.1) Type=9 Code Checksum Num Addrs Addr Entry Size Lifetime (of this Advertisement) Router Address[1] Preference Level[1] Router Address[2] Preference Level[2]

IP Header

ICMP Router Advertisement

. . .

Type=16 Length Sequence Number (maximum) Registration Lifetime R BHFMGV Reserved CareofAddress[1] CareofAddress[2]

. . . . . .

Mobility Agent Advertisement Extension PrefixLength Extension (Optional)

Type=19

Length

PrefixLength[1]

PrefixLength[2]

Figure 2.3: Agent Advertisement Message Format [RFC2002]

from ICMP router advertisement message format. In addition to the original ICMP router advertisement message, mobility agent advertisement extension and optional prex-length extension are added. As shown in Figure 2.3, an msg (2) agent advertisement message carries CoAs to the MN. Type eld of ICMP message portion is set to 9 to denote ICMP advertisement. Num Addrs means how many pairs of Router Address and Preference Level values are contained. Addr Entry Size represents the size of a pair of Router Address and Preference Level elds. Lifetime eld is set with the period of time this advertisement is valid. (i.e., how often an agent broadcasts an advertisement message.) The Type eld in Mobility Agent Advertisement Extension identies the extension itself. Registration Lifetime eld is related to registration procedure. As we will discuss later in this subsection, an HA maintains a binding information of an MNs home address and CoA. Registration Lifetime eld denotes the maximum binding time after which MN should re-register its CoA. Care-of-Address eld is set with an available

12 CoA allowed. Optional Prex-Length Extension is used for MN to calculate network prex portion of agent address, in order to identify MN itself has been moved. Upon reception of msg (2) agent advertisement (see Figure 2.1), the MN dispatches a CoA from the message and set the CoA as a new foreign address in its MIP implementation. Upon the completion of agent discovery, the MN performs registration of its CoA with HA.

2. Registration Once an MN detects its movement into a new subnet and obtains a CoA through agent discovery period, the MN tries to register its CoA with the HA. Registration is a procedure to have a HA create, update, or delete the binding information of an MNs home address and its CoA. So, when a given lifetime of a binding information is about to expire, the corresponding MN should register its CoA again with the HA. Registration is composed of two messages: msg (3) registration request (see Figure 2.1) and msg (4) registration response. Msg (3) registration request and msg (4) registration response messages are exchanged in UDP packet format. Figure 2.4 shows registration request message format. Msg (3) registration request (see Figure 2.1) can be sent by MN to HA directly when MN obtained collocated CoA as well as via FA when MN obtained FAs CoA. In the latter case, FA receives a msg (3) registration request and relays the message to HA. It should be noticed that msg (3) registration request must be authenticated such that HA can conrm the message is not delivered from any malicious party. Source Address eld and Destination Address eld of IP header are lled with an MNs home address and the address of an FA obtained during agent discovery period, respectively. (If an MN obtains a collocated CoA rather than an FAs CoA, the collocated CoA and the address of HA are set, instead.) In the header portion of the UDP message, Destination Port eld is set to 434 identifying MIP registration message. Type eld in Fixed-Length Portion of Registration Request identies registration request message. Lifetime eld of registration request denotes a period of time for which MN wants the binding information lasted. MN Home Address, HA Address, and Careof-Address elds deliver the values their name designate. Identication eld is used for MN to identify a particular registration request it send, in order to prevent itself from malicious replaying attack. Finally, Mobile-Home Authentication Extension is followed.

13
0 8 16 24 32

VER=4

IHL Type of Service Total Length Identification Flags Fragment Offset Time to Live Protocol=UDP Header Checksum Source Address Destination Address Source Port Destination Port=434 Length Checksum Type=1 S B D M G V rsv Lifetime MN Home Address HA Address CareofAddress Identification
Optional Extensions

IP Header

UDP Header

FixedLength Portion of Registration Request

Option

Type=32 Index (SPI)

Length

Security Parameter
MobileHome Authentication Extension

Authenticator (Default equals Keyed MD5)

More Optional Extensions

Option

Figure 2.4: Registration Request Message Format [RFC2002]

Upon reception of a msg (3) registration request message (see Figure 2.1), HA updates the binding information according to the received CoA. If no error occurs during the binding update procedure, HA sends msg (4) registration response back to either MN or FA which relays it to MN. Msg (4) registration response message informs MN the result of registration procedure, whether or not it is successfully completed. Figure 2.5 shows msg (4) registration response message format dened in RFC 2002. (The only dierent part, Fixed-Length Portion of Registration Reply, is depicted.) Msg (4) registration reply message (see Figure 2.1), has identical to msg (3) registration request message except the following elds: Type eld of Fixed-Length Portion of Registration Reply is set to 3. Code delivers specic error code encountered during the process of registration. Lifetime eld denotes a period of time HA would practically maintain the binding information requested.

14
0 8 16 24 32

Type=3

Code MN Home Address HA Address Identification

Lifetime
FixedLength Portion of Registration Reply

Figure 2.5: Registration Reply Message Format [RFC2002]

2.1.2

Mobility-Transparent Packet Forwarding: Tunneling


MIP is designed to provide mobility-transparent packet forwarding to MN

regardless of its location in foreign links. This mobility support is based on tunneling capability. From the information given by agent discovery, an HA sets up a virtual tunnel, which is a particular route, to the CoA of MN (either an FAs CoA or a collocated CoA). The HA forwards the packets, originally destined to the home address of the MN, to the CoA of the MN. Figure 2.6 shows tunneling procedure of MIP.
MIP handoff: Tunneling CN Internet HA Tunneling FA

MN
Tunneling overhead Outer IP header Triangular routing

Figure 2.6: Tunneling in MIP MIP provides three tunneling options: IP in IP encapsulation, minimal encapsulation, and generic routing encapsulation (GRE). First, IP in IP encapsulation is an original tunneling mechanism in which an original IP datagram, destined to MNs home

15 address, is encapsulated to the IP payload part of another IP datagram and tunneled to MNs CoA. As an encapsulation requires 20 bytes of additional IP header, end-to-end throughput decreases. Second, minimal encapsulation option uses 12 bytes additional header to reduce the overhead of IP in IP encapsulation, but requires modications on several elds in the IP header of original packets. Last, GRE is adopted by MIP in order to support other protocols as well as IP.
0 Protocol 8 S Reserved Original Destination Address Original Source Address (if present) 16 24 Header Checksum 32 Minimum Forwarding Header

Figure 2.7: Minimal Tunneling Header Message Format [RFC2004]

2.1.3

Problems
So far in this section, we described MIP mechanism including agent discovery,

registration, and tunneling. Although MIP resolves host mobility in IP layer, additional agents and tunneling overheads degrade performance of data transmission to/from mobile host when hando occurs. Such problems are listed below: High hando delay MIP hando delay is ascribed to agent discovery delay

and registration delay as we discussed in this section. As we discuss in Chapter 4 and Chapter 5, MIP hando delay increases proportional to hando rate and period of time MN stays in foreign links. Hence, MIP hando can cause signicant performance degradation, especially in highly mobility-oriented environments. Tunneling overhead [23] Tunneling mechanism of MIP oers mobility trans-

parent routing service to upper layer protocols. However, two major drawbacks exist in tunneling. First, an additional IP header should be attached to an original IP datagram. The 20-byte overhead decreases end-to-end transmission throughput. Second, since tunneling generates triangular routing path, additional network delay cannot be avoided.

16 Conict with network security solutions [17]

2.1.4

Enhancement Eorts
In order to reduce hando delay and tunneling overhead incurred by MIP, quite

a few enhancement eorts have been made. There have been many other extensions and drafts in terms of more general mobility architecture and performance, but we focus on MIP extensions regarding hando performance. We discuss two major internet drafts MIP with route optimization and hierarchical MIP. Optimized routing Optimized routing [29] is an MIP extension to reduce tun-

neling overhead. In this extension, MN informs its CoA to CN directly so that CN can send data packets to the CoA directly without tunneling by HA. In order to realize the optimized routing, CN maintains a binding cache in which CoAs of MN are being updated as MN moves. Regional registration and hierarchical Mobile IP MIP regional registration [18]

and HMIP [33] are another MIP extension to reduce signaling overhead. Hierarchical MIP is categorized as a micro-mobility solution. When the frequency of an MN movement inside of a subnet increases, signaling overhead for the MNs registration of its CoA with the HA increases and cause high hando delay. In order to reduce the signaling overhead, a hierarchical mobility agent, called gateway foreign agent (GFA) [7][18], is dened. Whenever a hando is triggered from an MN movement, the MN registers its CoA with the most nearby local GFA. As the HA had already been noticed about the tunneling information to the GFA in the previous (or the rst) registration, the tunneling of packets are processed in a hierarchical manner from the HA to the GFA, and the GFA to the FA, and the FA to the MN.

2.2

mobile SCTP: A Transport Layer Approach


mobile SCTP (mSCTP) is a transport layer hando solution based on Stream

Control Transmission Protocol (SCTP) and dynamic address reconguration (DAR) extension. Originally designed to support telephony signaling messages, SCTP has

17 been adopted as the third general purpose transport protocol 1 by IETF, inheriting main features of TCP including the concept of ow control and congestion control. SCTP, in addition, provides two novel features, multi-homing and multi-streaming. Multihoming is a concept that two end hosts can hold multiple connections at the same time while multi-streaming is a feature that multiple streams of data can be delivered under independent controls within a single connection. mobile SCTP (mSCTP) utilizes multi-homing feature of SCTP in such a way that two end hosts hold two transport layer connection identities at the same time when an MN stays in an overlapped region moving from one subnet to another. In addition, DAR extension is used to deliver messages of add-ip, delete-ip, and set-primary-ip requests. All the mSCTP hando procedures are processed between two end-to-end hosts without involving any third party agent. As discussed in Section 2.1, one of the major problems of MIP is that an MN cannot keep communicating with a CN while it has to deal with its registration of its CoA with the HA during hando period. However, mSCTP can provide a seamless hando solution based on its multi-homing feature and DAR extension. In the following subsections, we discuss SCTP details and DAR extension.

2.2.1

Stream Control Transmission Protocol (SCTP)


We introduce Stream Control Transmission Protocol (SCTP), the third gen-

eral purpose transport layer protocol, in this subsection. SCTP provides a connectionoriented, reliable transport service over IP network as TCP does. SCTP also supports congestion control and packet loss recovery function. In addition, SCTP has unique features including multi-homing and multi-streaming. Based on these two features, SCTP was originally designed to provide a reliable transport between two end hosts using multiple, independent control of streams.

1. SCTP Endpoint and Association: Multi-homing A transport endpoint in TCP/IP network is canonically dened as a pair of IP address and port number. In TCP, a connection is established between two (IP address,
Stream Control Transmission Protocol (SCTP) is the third general purpose transport protocol standardized by IETF, after TCP and UDP.
1

18 port number) endpoints, and a TCP connection is always one-to-one relationship of a single IP address from each endpoint. Unlike in TCP, an SCTP endpoint can multiplex multiple IP addresses on a multi-homed (interfaced) host. An SCTP association is dened as [a set of IP addresses at A]+[Port-A]+[a set of IP addresses at Z]+[PortZ] [36]. That is, two SCTP endpoints, having set of IP addresses, comprise an SCTP association. Figure 2.8 shows an example of an SCTP association.
Endpoint A SCTP Layer SCTP Association Endpoint B SCTP Layer

#$ #$ $ $ $#$## #$ #$ # # $        "!       ! "!" " !"!" !" ! "!"!

Port

           

Port

IP Layer IP_A1 IP_A2 IP Networks

IP Layer IP_B1 IP_B2

Figure 2.8: SCTP Association In Figure 2.8, Endpoint A, having IP(A1) and IP(A2), established an SCTP association with Endpoint B, which has IP(B1) and IP(B2). In this example, Endpoint A uses IP(A2) as its primary IP address while Endpoint B uses IP(B2). Meanwhile, an SCTP endpoint can establish multiple sessions (associations) to other endpoints at the same time [37]. That is, an SCTP endpoint can utilize its multihomed network interfaces to signal to more than two peer nodes at a given moment. Figure 2.9 shows concurrent associations from an endpoint, Endpoint A, to a set of endpoints, Endpoint B, Endpoint C, and Endpoint D. Based on association and multisession features, an SCTP node can support multi-homing capability as shown in Figure 2.10. In Figure 2.10, the MN and the CN establish an SCTP association. Within the association, multi-homed MN can utilize multiple-path communications by signaling to

19

Multiple Sessions from an SCTP Endpoint

Endpoint C Node 3

Endpoint D

Endpoint B Node 2

Association

Endpoint A Node 1

Figure 2.9: Multi-Session from an SCTP Endpoint

mSCTP: MultiHoming CN

SCTP Association

AP

Internet Cellular networks

BS

MN

Network interface 1 Network interface 2

Endtoend connection 1 Endtoend connection 2

Figure 2.10: mSCTP Multi-Homing

the AP and the BS at the same time, and notice the CN to use either of the MNs IP addresses as a destination IP address. In this example, having two network interfaces, the MN moves from the BS area to the AP area. While the MN stays in the coverage of

20 both networks, the MN is able to exploit its multiple network interfaces to communicate with the CN based on association and multi-session capability. More details of mSCTP hando will be discussed in Subsection 2.2.3. It should be noticed that an SCTP association is dierent from multi-homed TCP connections in such a way that an SCTP association has a single control over multiple IP addresses while each TCP connection is controlled in totally independent manner. Prospective applications of SCTP multi-homing, based on the concept of association, are a reliable signaling with failover support, transport load balancing for multi-homed hosts, elimination of head-of-line blocking (with the help of multi-stream of SCTP), and transport layer hando.

2. Setup and Close an Association Since SCTP is a connection-oriented transport protocol, two endpoints should establish an association (see item 1. SCTP Endpoint and Association: Multi-homing in this subsection) before exchanging data chunks. Unlike TCP, SCTP uses four-way handshake to setup an association. Four-way handshake can prevent TCP SYN-oodingattack, which is ascribed to the three-way handshake of the connection initialization of TCP. Figure 2.11 shows the signaling of an SCTP association setup process. Endpoint A starts four-way handshake association setup process by sending an INIT chunk. Upon receiving INIT chunk, endpoint B responds by sending an INITACK chunk. INIT-ACK chunk contains a state cookie, which should be sent back to itself (endpoint B) by endpoint A. State cookie prevents well-known TCP SYNooding attack, which is attributed to the fact that a malicious node sends SYN packet continuously until the other endpoint runs out of its resources. Endpoint B veries the authenticity of a state cookie delivered back in a COOKIE-ECHO chunk. Once endpoint B recognizes an authentic state cookie value, a COOKIE-ACK chunk is responded to endpoint A. After nishing the four-way handshake, an SCTP association between endpoint A and endpoint B has been setup and reliable connection-oriented data transmissions are followed. It should be noted that COOKIE-ECHO chunk and COOKIE-ACK chunk are able to be bundled with data chunks. As SCTP is a reliable transport protocol, it also provides a way to close an existing association. Figure 2.12 shows the signaling of an SCTP association close

21

Endpoint A

SCTP: Setup of an Association Fourway handshake

Endpoint B

INIT INITACK COOKIE COOKIE ECHO

ACK

Association

Association

Figure 2.11: SCTP Association Setup

process.

Endpoint A

SCTP: Close an Association Threemessage handshake

Endpoint B

Association

SHUTDOW

Association

NACK SHUTDOW SHUTDOW NCOMP LE TE

In

state of association, endpoints do not accept packets (to send) from upper layer protocols

Figure 2.12: SCTP Association Close SCTP association close is a three-message handshake process. Endpoint A

22 sends a SHUTDOWN chunk to endpoint B. From this moment, endpoint A does not take any data from upper layer. Once endpoint B received SHUTDOWN chunk, endpoint B does not accept any user data from upper layer protocol, and send SHUTDOWN-ACK chunk to endpoint A. Upon receiving SHUTDOWN-ACK chunk, endpoint A enters the CLOSE state of the association, and respond with SHUTDOWN-COMPLETE chunk to endpoint B. With the reception of the SHUTDOWN-COMPLETE chunk, the association enters CLOSE state in endpoint B as well. One of major dierences between SCTP association close and TCP connection close process is that SCTP does not allow half-closed state that TCP does.

3. Message Formats An SCTP packet is composed of an SCTP common header and number of chunks. A chunk is a unit of information within an SCTP packet [37]. As a unit of SCTP message building block, many dierent types of chunks have been dened, categorized into either control chunks or data chunks. Figure 2.13 shows an SCTP message formats including its common header and chunks.
0 8 16 24 32 SCTP Common Header

Source port number

Destination port number

Chunk type

Verification tag Adler32 checksum Chunk flags Chunk data

Chunk length
Chunk 1

... . . . ...

Chunk type

Chunk flags Chunk data

Chunk length
Chunk N

Figure 2.13: SCTP Common Header [RFC2004] In common header, source port number eld is set with a senders endpoint port number. Destination port number eld represents the port number of the destination endpoint. Verication tag is used to provide a distinction between current packets and packets from previous associations. It also prevents endpoints from being exposed to

23 malicious packet-injecting attack. Adler-32 checksum supports received data integrity check. The checksum covers common header and all the appended chunks. Chunks are the actual building blocks of SCTP. Each chunk consists of chunk type, chunk ags, chunk length, and chunk data elds. Chunk type identies the type of chunk. Chunk ags provides special ags used for the chunk. Chunk length is set with the length of the chunk in bytes. At the end of a chunk, chunk data is followed. Table 2.1: SCTP Chunk Type

Chunk Type 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x3f 0x7f 0xbf 0x

Chunk Name DATA INIT INIT-ACK SACK HEARTBEAT HEARTBEAT-ACK ABORT SHUTDOWN SHUTDOWN-ACK ERROR COOKIE-ECHO COOKIE-ACK ECNE CWR SHUTDOWN-COMPLETE Special expansion code 1 Special expansion code 2 Special expansion code 3 Special expansion code 4

Description User data Initiation of SCTP association Response to INIT chunk Acknowledgement of user data Keep alive message Response to HEARTBEAT Ungraceful termination of an association Graceful termination of an association Response to SHUTDOWN Report of an error Pass a state cookie Response to COOKIE-ECHO Explicit Congestion Notication Echo Congestion Window Reduced Graceful termination complete IETF-dened expansion code IETF-dened expansion code IETF-dened expansion code IETF-dened expansion code

Table 2.1 shows the dened chunk types in [RFC 2960] [35]. Multiple chunks can be bundled together in an SCTP packet, regardless of whether they are control chunks or data chunks. By exploiting this feature of SCTP, mSCTP hando carries two additional types of control chunks, ASCONF and ASCONF-ACK (which we discuss in the next subsection), with data chunks in a same packet. This factor is one of the advantages of SCTP that allows seamless hando without any hando delay in transport layer.

24 4. Data Transfer and Congestion Control Once an association has been established, two SCTP endpoints can transfer user data. First, application data are chopped into smaller pieces if they are too big to be t in an SCTP packet according to the path maximum transmission unit (MTU). Application data are entered data chunk queue in SCTP layer to be packed in an SCTP packet. At the same time, if any type of control chunk is ready at the control chunk queue in SCTP layer, the control chunks are bundled together with data chunks in the front of data queue. On the other endpoint, upon reception of an SCTP packet, chunks are unbundled into control chunks and data chunks. For fragmented data chunks, data chunks are reassembled in SCTP layer and put into stream reordering queues. Unbundled control chunks also conduct their anticipated functions in SCTP layer. SCTP provides congestion control mechanism to adapt its transmission rate in shared networks. SCTP congestion control has been designed based on the rateadaptive window-based scheme of TCP [16]. Hence, SCTP reduces the transmission rate whenever a network congestion is detected. However, several unique features, apart from TCP, are introduced. Based on its mandatory SACK mechanism, SCTP supports inherent fastrecovery functionality without explicit mechanism. The mandatory SACK mechanism allows SCTP avoid slow start after multiple segment losses in a single window. The SACK mechanism, as a result, increases throughput of SCTP by ecient bandwidth usage. In slow start and congestion avoidance stage of SCTP, congestion window (cwnd) is increased by the number of acknowledged bytes while TCP refers to the number of ACK segments to increase its cwnd. In congestion avoidance stage of SCTP, cwnd can be increased only after full cwnd is consumed. SCTP, also, waits its fast retransmission until four Duplicated ACKs are received [16].

2.2.2

Dynamic Address Reconguration (DAR)


As we discussed in Subsection 2.2.1, SCTP allows both end nodes to hold

multiple IP addresses at a given moment. Dynamic address reconguration (DAR) extension, in addition, denes three major parameters with which mSCTP hando can be

25 performed: Add IP Address (add-IP), Delete IP Address (delete-IP), and Set Primary Address (set-primary-IP). Add-IP is a parameter to add new IP addresses in an active association. Delete-IP is to delete an old IP addresses from an existing association. Set-primary-IP function is used to inform the other end node to change the destination IP address of its IP datagram to the designated IP address. Now, we discuss these three DAR parameters with more details.

1. Add-IP, Delete-IP, and Set-Primary-IP parameters The three new parameter types dened in DAR, add-IP, delete-IP, and setprimary-IP, are employed in mSCTP to perform seamless transport layer hando. The word, seamless, in this context, means data transmission is almost not aected by hando procedure. In mSCTP, this seamless hando is guaranteed by exploiting multihoming feature of SCTP and dynamic IP address congurations of DAR extension. Add IP address (add-IP) is an ASCONF parameter to inform the other end node to add a new IP address in its active association. Figure 2.14 shows the message format of add-IP ASCONF parameter.
0 8 16 24 32

Type=0xC001 Length = Variable ASCONFRequest Correlation ID Address Parameter

Figure 2.14: ASCONF Parameter: Add IP Address (add-IP) The value, 0xC001, of type eld identies add-IP parameter. Length eld is variable since address parameter can carry multiple IP addresses. ASCONF-request correlation ID is used for a sender of the ASCONF chunk to distinguish the particular chunk from other chunks. Address parameter eld holds IP address (either IPv4 or IPv6 address) in TLV format, which is described in 3.3.2.1 of RFC2960 [35]. Figure 2.15 shows delete-IP ASCONF parameter, which is used to notice the other end node to delete IP addresses, specied in the chunk, from an active association. Type eld is set with the value, 0xC002, to be identied as delete-IP ASCONF parameter. Length eld is variable as it is in add-IP ASCONF parameter; Address parameter can be organized with multiple IP addresses. ASCONF-request correlation

26
0 8 16 24 32

Type=0xC002 Length = Variable ASCONFRequest Correlation ID Address Parameter

Figure 2.15: ASCONF Parameter: Delete IP Address (delete-IP)

ID identies a particular chunk from other chunks so that the sender of the chunk can discriminate it. TLV type of address parameter is followed. Figure 2.16 shows the message format of set-primary-IP address ASCONF parameter.
0 8 16 24 32

Type=0xC004 Length = Variable ASCONFRequest Correlation ID Address Parameter

Figure 2.16: ASCONF Parameter: Set Primary IP Address (set-primary-IP) The value of 0xC004 in type eld describes it is a set-primary-IP ASCONF parameter. Length, ASCONF-request correlation ID, and address parameter are used in the same purpose as in add-IP and delete-IP ASCONF parameters. In order to deliver these DAR parameters, two additional chunks, Address Conguration Change Chunk (ASCONF) and Address Conguration Acknowledgment (ASCONF-ACK), are dened.

2. ASCONF/ASCONF-ACK Chunks Address Conguration Change Chunk (ASCONF) and Address Conguration Acknowledgment (ASCONF-ACK) are additional chunk types dened in DAR internet draft [34]. Table 2.2 shows ASCONF and ASCONF-ACK chunk types. Table 2.2: DAR: Address Conguration Chunks Chunk Type 0xc1 0x80 Chunk Name ASCONF ASCONF-ACK Description Address Conguration Change Acknowledgement to ASCONF

27 ASCONF chunk carries DAR ASCONF parameters including add-IP, deleteIP, and set-primary-IP. It should be noticed that ASCONF chunks can be bundled with other data chunks in an active association during an mSCTP hando procedure. This property of SCTP and DAR makes mSCTP hando delay be neglected as we will discuss in Chapter 4. Figure 2.17 shows the message format of ASCONF chunk.
0 8 16 24 32

Type=0xC1

Chunk Flags Chunk Length Serial Number Address Parameter ASCONF Parameter #1

. . .

ASCONF Parameter #N

Figure 2.17: DAR: ASCONF Chunk Format Type eld is lled with the value, 0xC1, to identify ASCONF chunk. Chunk ags led is not used in ASCONF chunk and set to 0. Chunk length denotes the length of the chunk itself. Serial number is set to a value from 0 to 4294967295 (2 *32 - 1) range, in order to distinguish a particular ASCONF chunk from other chunks. Address parameter is set to a sender address to help receiver nd the related association. ASCONF parameter elds contain add-IP, delete-IP, and set-primary-IP parameters which will be discussed later in this subsection. ASCONF-ACK chunk delivers a reply message to an ASCONF request. Figure 2.18 shows the message format of ASCONF-ACK chunk.
0 8 16 24 32

Type=0x80

Chunk Flags Chunk Length Serial Number ASCONF Parameter Response #1

. . .

ASCONF Parameter Response #N

Figure 2.18: DAR: ASCONF-ACK Chunk Format

28 The value of 0x80 in type eld identies it is an ASCONF-ACK chunk. Chunk ags eld is not used and set to 0. Chunk length represents the length of the chunk itself. Serial number carries the serial number of ASCONF chunk which it replies to. ASCONF parameter response elds deliver the processed status of the ASCONF requests. By default, without any error occurred in ASCONF-ACK sender side, no ASCONF parameter response eld is appended. That is, if no error occurs, only type, chunk ags, chunk length, and serial number elds are returned in an ASCONF-ACK chunk. As discussed in the subsection, DAR extension, based on multi-homing feature of SCTP, allows seamless mSCTP hando in transport layer. In the next subsection, we discuss how mSCTP hando works based on multi-homing and DAR extension.

2.2.3

mSCTP: Make-Before-Break with Multi-Homing and DAR


Make-before-break handovers involve a mobile node making the new link while

maintaining the old link; when the new link is ready, the old link can be broken. [32] In this section, we have discussed essential components of mobile SCTP (mSCTP) including Stream Control Transmission Protocol (SCTP) and dynamic address reconguration (DAR) extension. Based on multi-homing feature of SCTP and DAR, makebefore-break IP-based hando is able to be performed. During a hando period, legacy network layer hando mechanisms, including MIP, have a certain period in which an MN must communicate with agents other than its peer node, CN. Hence, the existing active connection suers from packet loss, waste of bandwidth by transport layer slow start, and so on. As hando delay increases, the performance degradation becomes bigger. On the other hand, mSCTP node can utilize two network adapters in an association to make a new data path while still communicating with its peer node. To perform a hando, mSCTP exchange at most three pairs of ASCONF/ASCONF-ACK control chunks bundled with data chunks with its peer node. Figure 2.19 shows mSCTP hando signaling messages. The MN has communicated with the CN through the BS node. For this communication, the MN used the network interface-1. During its movement toward the AP, the MN exchanges router solicitation and router advertisement with the AP using the

29
mSCTP: Handoff Signaling

MN

BS

AP

CN

Data Chunks Acknowledgment to Data Chunks Router Solicitation Router Advertisement AddIP ASCONF Chunk (with Data Chunks) ASCONFACK Chunk SetPrimaryIP ASCONF Chunk (with Data Chunks) ASCONFACK Chunk DeleteIP ASCONF Chunk (with Data Chunks) ASCONFACK Chunk Data Chunks

Network interface 1 Network interface 2

Endtoend connection 1 Endtoend connection 2

Figure 2.19: mSCTP Hando Signaling with Multi-Homing and DAR Extension

network interface-2. The router discovery process is performed independently from the data transmission in the network connection-1. Once the MN obtained a new IP for the network interface-2, the MN bundle an add-IP ASCONF chunk into other data chunks in the network connection-1. The CN responds with ASCONF-ACK chunk bundled with SACK chunks for received data. When the MN determines to use the interface-2, the MN sends set-primary-IP ASCONF chunk together with data chunks to the CN. The CN replies back with ASCONF-ACK. Upon reception of the ASCONF-ACK chunk, the MN begins to use the interface-2. Delete-IP ASCONF and ASCONF-ACK can be exchanged to erase the old IP address from the association.

30

Chapter 3

Vertical Hando Architecture in Heterogeneous Networks


In Chapter 1, we talked about the evolving IP based wireless services and addressed the inherent mobility problem. In Chapter 2, we introduced a network layer mobility solution, Mobile IP (MIP), and a transport layer solution, mobile SCTP (mSCTP). It is an apparent trend that such IP-based hando solutions will be deployed in future wireless IP networks. In the mean time, we have quite a few dierent wireless access technologies and service networks at the same time. In this chapter, we discuss one of the encountered trends among the contemporary wireless services: Network and Service Convergence. We also discuss the architectures of IP-based vertical hando between heterogeneous networks based on MIP and mSCTP.

3.1

Network and Service Convergence: Trend


Various wireless network services, including 2G, 2.5G/3G, and 802.11 Wi-Fi,

are contemporarily provided for dierent needs from customers. This variety comes from the fact that network operators decide type of network based on required coverage of network, target user base, their business prot, and so forth. The deployed networks

31 are divided into three categories: wireless LAN (WLAN), wireless MAN, and wireless WAN. Wireless LAN includes 802.11b, 802.11g, and 802.11a. Wireless MAN, which is targeting mobile Internet users in a city area, includes 802.16a, 802.16b, and 802.16e [31]. Wireless WAN includes all the current cellular infrastructure access networks such as CDMA2000, GSM, GPRS, and UMTS [10]. Among the dierent wireless access networks and services, Wireless LAN and wireless WAN have complementary characteristics. Wireless LAN generally provides relatively high data rate with small coverage while wireless WAN networks oer relatively low data rate with large coverage area. For instance, a WLAN standard, 802.11b, provides up to 11Mbps data rate with a few hundred meters of radius while UMTS UTRAN supports up to 2Mbps data rate for xed node and 386Kbps for pedestrian users with a few kilometers of radius. Therefore, by using both of the network services, wide coverage area is guaranteed with high data rate where WLAN services are available.

802.11b

802.11b 802.11b 802.11b

CDMA2000 1x EVDO

802.11b

802.11b 802.11b

UMTS UTRAN

802.11b

802.11b

802.11b

UMTS UTRAN 802.11b 802.11b 802.11b

Figure 3.1: Network and Service Convergence

32 Figure 3.1 shows an example of network and service convergence and user mobility. The user accesses the best network in terms of the data rate, communication expense, etc. However, we should notice that certain problems exist due to the heterogeneity of the dierent technologies. Since it is wireless mobile communication, mobility support is again one of the most fundamental problem to be solved. In this thesis, in order to evaluate the performance of hando eects in integrated networks, UMTS/802.11b integrated networks are investigated. In the next section, we discuss the IP-base hando mechanism for the vertical hando between UMTS and 802.11b networks.

3.2

IP-based Vertical Hando in UMTS/802.11b


In addition to the existing IP-based networks and services (either it is xed

networks or wireless access networks such as Wi-Fi hot spots), commercial cellular networks and services are also evolving toward all-IP networks due to many technological and economical reasons. Thus, IP-based hando solutions will be the essential part of future wireless IP convergent networks. In this section, we discuss the architecture and performance issues of UMTS/802.11b integrated networks, as a case study, to examine the IP-based Hando solutions: Mobile IP (MIP) and mobile SCTP (mSCTP). In the thesis, in order to focus on only the hando performance, we study loosely-coupled vertical hando architecture where 802.11b WLAN does not have any correlation with UMTS network but directly connected to public IP networks.

3.2.1

Mobile IP Vertical Hando


Mobile IP (MIP), as an Internet Standard, has been deployed widely in various

networks and services. For instance, 3GPP2 adopted MIP as a standard IP mobility solution and uses MIP in the packet switching domain of the networks. Moreover, the deployed MIP service has already been used to integrate the CDMA2000 network and the 802.11 WLAN network. An example of this integrated network services is the network service product called, NETSPOT SWING, provided by a Korean network operator, KTF. The concept of the service is that the multi-homed user device always

33 connects to the CDMA2000 cellular service and MIP Hando occurs whenever the user enters a Wi-Fi hotspot area. For UMTS network, MIP has not yet been adopted as a standard IP mobility solution. One of the disadvantages of MIP in architectural point of view is that it requires additional components: Home Agent (HA) and Foreign Agent (FA) which have to be installed in certain routers and/or network gateways. Moreover, as we will discuss later in the thesis, MIP incurs signicant hando delay due to the inevitable registration procedure. To install MIP capability into UMTS (3GPP R991 ) network, agent modules should be implemented in SGSN or corresponding network gateways. Figure 3.2 shows an MIP vertical hando architecture in UMTS(3GPP R99)/802.11b integrated network.
Mobile IP Vertical Handoff in UMTS(3GPP R99)/802.11b
802.11b Domain AP MN One Connection at a time Agent Router Core Network Packet Switching Agent SGSN GGSN Internet

UMTS UTRAN NodeB RNC

Figure 3.2: Mobile IP Vertical Hando Architecture: UMTS(3GPP R99)/802.11b In this architecture, the MN is registered to a home agent (HA), which is located in either 802.11b domain or UMTS core network packet switching gateway. The MN, having its home address, registers its new CoA with HA whenever it moves in a new IP subnet and obtain a CoA. Only one transport connection is maintained between the MN and a correspondent node (CN). All the packets destined to the MNs CoA are tunneled to foreign agent (FA), which again forwards the original IP datagram to the MN. It should be noted that vertical hando is an inter-technology hando. Hence, MIP registration and tunneling incur higher delay than that of in homogeneous environment due to the routing overhead between dierent technologies. Figure 3.3 shows MIP vertical hando architecture in UMTS(3GPP R52 )/802.11b integrated network.
1 2

3GPP Release99 (R99) is the rst version of UMTS specications [20]. 3GPP R5 is the release that followed R99 and R4. The main issues in R5 are GSM/EDGE RAN

34

Mobile IP Vertical Handoff in UMTS(3GPP R5)/802.11b


802.11b Domain AP MN One Connection at a time UMTS UTRAN Agent NodeB RNC Release5 AllIP Agent Router Core Network Packet Switching Internet SGSN GGSN Internet

Figure 3.3: Mobile IP Vertical Hando Architecture: UMTS(3GPP R5)/802.11b

In 3GPP R5 all-IP network, agent modules can be sit on RNC. In this architecture, UMTS UTRAN supports IP-based protocol stack. This all-IP access network provides more exible IP routing service, but MIP hando overhead cannot be avoided. In MIP vertical hando architecture, certain modication has to be made into legacy network components. This task is not very favorable to network operators.

3.2.2

mobile SCTP Vertical Hando


Unlike MIP vertical hando, mSCTP vertical hando does not require any

additional modication on existing components. (In the thesis, we focus on hando functionality of IP mobility. Location management of mSCTP can be resolved with DNS service and not covered in the thesis.) As discussed in Chapter 2, mSCTP directly interacts with CN to trigger transport layer hando. This end-to-end hando procedure is one of the most important advantages that SCTP oers such that no hando architecture dierence exists between homogeneous environments and heterogeneous environments. Figure 3.4 shows mSCTP vertical hando architecture in UMTS(3GPP R99)/802.11b integrated network. No additional component is installed, and the MN directly interacts with CN in end-to-end manner. Figure 3.5 represents mSCTP vertical hando architecture in UMTS(3GPP R5)/802.11b integrated network. mSCTP does not required any modication in this architecture, either.
(GERAN) and IP transport within the access network [20].

35

mobile SCTP Vertical Handoff in UMTS(3GPP R99)/802.11b


802.11b Domain AP MN Two Connections at the same time Router Internet

UMTS UTRAN NodeB RNC

Core Network Packet Switching SGSN GGSN

Figure 3.4: mobile SCTP Vertical Hando Architecture: UMTS(3GPP R99)/802.11b


mobile SCTP Vertical Handoff in UMTS(3GPP R5)/802.11b
802.11b Domain AP MN Two Connections at the same time Router Core Network Packet Switching UMTS UTRAN NodeB RNC Release5 AllIP Internet SGSN GGSN Internet

Figure 3.5: mobile SCTP Vertical Hando Architecture: UMTS(3GPP R5)/802.11b

mSCTP, using multi-homing feature of SCTP, does not incur any hando delay in UMTS/802.11b integrated network as well. We will conduct a performance analysis of MIP and mSCTP with regard to end-to-end throughput, total hando delay, and packet loss, in Chapter 4, and represent the simulation and results including vertical hando architecture in Chapter 5.

36

Chapter 4

Performance Analysis of Mobile IP and mobile SCTP Hando


We have discussed the network layer hando, Mobile IP (MIP), and the transport layer hando, mobile SCTP (mSCTP), in terms of their mechanisms in Chapter 2. In this chapter, we conduct a theoretical analysis of MIP and mSCTP hando with regard to hando delay, end-to-end throughput, and packet loss. These three parameters are very important performance metrics since they show whether a given hando procedure can make seamless end-to-end transmission for ubiquitous users and feasible to be deployed, especially in a highly mobile-oriented environment. After the analysis of MIP and mSCTP in this chapter, we conduct a simulation study with corresponding system models in Chapter 5. We provide a performance evaluation on the simulation results of MIP and mSCTP in 802.11b WLAN-only network and UMTS/802.11b integrated network.

4.1

Hando Delay
In this section, we will analyze hando delay incurred by MIP and mSCTP.

Hando delay represents delayed period by a given hando procedure; otherwise, total

37 amount of transferred data would be the same as in xed network. As we discussed in Chapter 2, agent discovery and registration of CoA with HA generate MIP hando delay. In case of mSCTP, no signicant hando delay occurs since dynamic address reconguration (DAR) control chunks can be bundled with other data chunks (see Chapter 2). For analysis of hando delay, we begin with the denitions of parameters.

TM IP TmSCT P Tad Trd Treg TDAR Tas Taa TCoA TregREQ TBU TregRES Trs Tra TnewIP TaddIP TdelIP TsetprimaryIP TASCON F TASCON F ACK

MIP hando delay (second) mSCTP hando delay (second)

MIP agent discovery delay mSCTP router discovery delay

MIP CoA registration delay mSCTP dynamic address reconguration delay

MIP agent solicitation time MIP agent advertisement time MIP CoA processing time MIP registration request time MIP registration binding update MIP registration response time

mSCTP router solicitation time mSCTP router advertisement time mSCTP new-IP processing time

mSCTP add-IP time mSCTP delete-IP time mSCTP set-primary-IP time

mSCTP ASCONF chunk send delay mSCTP ASCONF-ACK chunk send delay

38 Each parameter above denotes certain time of delay in particular operations occurring during hando procedures of either MIP or mSCTP. By summing up all the delay parameters taken by partial operations of MIP and mSCTP, TM IP and TmSCT P represent hando delay of MIP and mSCTP, respectively. In Subsection 4.1.1 and Subsection 4.1.2, we will discuss TM IP and TmSCT P , respectively.

4.1.1

Hando Delay in Mobile IP: TM IP


Hando delay is dened as the period of time between the moment at which an

existing IP address becomes not available for end-to-end data transmission by movement of a node into a new subnet and the moment at which the end node receives a sequence of end-to-end packet using a newly obtained IP address. During the dened hando delay period, MIP incurs two activities, agent advertisement and registration, to process a hando (see Subsection 2.1.1). Hence, MIP hando delay (TM IP ) consists of two phases: agent discovery (Tad ) period and registration (Treg ) period (see Section 2.1). That is, TM IP = Tad + Treg (4.1)

Agent discovery (Tad ) and registration (Treg ), in turn, are composed of the following operations, respectively: Agent discovery (Tad ) Agent discovery (Tad ) period consists of agent solicita-

tion (Tas ), agent advertisement (Taa ), and CoA processing time (TCoA ) of an MN. As we have discussed in Section 2.1, MIP hando occurs when an MN moves from one subnet to another. For the movement detection of MN, agent discovery (Tad ) is executed by an MN and an FA (or possibly HA) cooperation. Agent solicitation (Tas ) (see item 1. Agent Discovery in Subsection 2.1.1) is a modied ICMP message broadcasted by an MN to search for an agent. Agent advertisement (Taa ) is also a modied ICMP broadcast message sent by an agent [28]. CoA processing time (TCoA ) represents time taken by MN to dispatch a CoA from FAs agent advertisement message [33]. As a result, the delay incurred by agent discovery is: Tad = Tas + Taa + TCoA (4.2)

39 By accomplishing the above three operations, agent discovery period of MIP (Tad ) make MN ready to trigger registration period (Treg ) with its obtained CoA. Registration (Treg ) Once an MN obtained a CoA from FAs agent advertise-

ment, it triggers registration (Treg ) of its CoA with the HA. Registration (Treg ) period is composed of registration request (TregREQ ) by MN, binding entry update for a new CoA (TBU ) by the HA, and registration response (TregRES ) by the HA. That is, Treg = TregREQ + TBU + TregRES (4.3)

Registration process can be successfully completed only when all the parties do not encounter any error during TregREQ , TBU , and TregRES periods. If any error occurs (mostly authentication failure), the HA sends a registration reply message with a corresponding error code and registration request message is retransmitted by the MN after proper handling of the error specied in error code eld. In order to prevent denial-of-service attack, which an unauthorized malicious node can ood registration trac to an HA, registration request (TregREQ ) and registration response (TregRES ) messages should be authenticated by an HA and an MN, respectively (see item 2. Registration in Subsection 2.1.1). As we discussed in Subsection 2.1.1, registration request (TregREQ ) and registration response (TregRES ) are delivered in UDP packets. Finally, agent discovery period and registration period constitutes MIP hando delay (TM IP ): TM IP = Tad + Treg = Tas + Taa + TCoA + TregREQ + TBU + TregRES
Tad Treg

(4.4)

In Equation (4.4), agent discovery (Tad ) period is an inevitable procedure due to the fact that the movement of an MN should be detected at IP layer. However, registration (Treg ) period is MIP-specic hando delay. Since MIP is a network layer mobility mechanism, the actual logic behind the transparent data transmission is a modied routing mechanism. MIP updates this routing information located in HAs

40 binding update table upon a registration request from an MN which obtained a new CoA. Including binding update (TBU ) period and an additional authentication overhead, registration delay (Treg ) can be signicantly long when an MN communicates with others in a highly movement-oriented environment. It should be noticed that hando delay (TM IP ) may interrupt on-going data transmission such that end-to-end throughput decreases and data packet loss possibly occurs.

4.1.2

Hando Delay in mobile SCTP: TmSCT P


Hando delay is the period of time from the moment at which an existing

IP address becomes not available for end-to-end data transmission by movement of a node into a new subnet to the moment at which the end node receives a sequence of end-to-end packet using a newly obtained IP address. During this period, mSCTP hando generates router discovery procedure performed between an MN and an access router, and dynamic address reconguration (DAR) procedure between an MN and a CN. Hence, in order to analyze mSCTP hando delay (TmSCT P ), we employ router discovery period (Trd ) and DAR period (TDAR ) dened early in this section. Equation (4.5) represents mSCTP hando delay (TmSCT P ): TmSCT P = Trd + TDAR (4.5)

Router discovery (Trd ) period and DAR (TDAR ) procedure, in turn, are composed of the following operations, respectively: Router discovery (Trd ) Router discovery (Trd ) period is composed of router so-

licitation (Trs ), router advertisement (Tra ), and processing time of newly obtained IP (TnewIP ) in an MNs protocol stack. That is, Trd = Trs + Tra + TnewIP (4.6)

Router discovery (Trd ) procedure of mSCTP is dierent from agent discovery (Tad ) of MIP in two folds. First, agent advertisement (Taa ) of MIP uses a modied ICMP router advertisement (Tra ) (see Figure 2.3) [14]. On the other hand, mSCTP hando can use a standard ICMP router advertisement message, which is at least

41 12-byte shorter than an agent advertisement of MIP. This means that the signaling overhead in router discovery (Trd ) of mSCTP is not greater than that of agent discovery (Tad ) of MIP. That is, M IP : Tad > mSCT P : Trd (4.7)

Second and more importantly, router discovery (Trd ) of mSCTP can be performed while transmitting data packets in an SCTP association exploiting multi-homing feature of SCTP. Hence, actual delay caused by mSCTP router discovery (Trd ) can be neglected. That is, Trd 0 Dynamic address reconguration (TDAR ) (4.8) The other part of mSCTP hando

procedure is a transport layer dynamic IP address conguration procedure employed from dynamic address reconguration (DAR) extension of SCTP. DAR procedure period (TDAR ) consists of three ASCONF parameters: add-IP (TaddIP ) procedure, set-primary-IP (TsetprimaryIP ) procedure, and delete-IP (TdelIP ) procedure. That is, TDAR = TaddIP + TsetprimaryIP + TdelIP (4.9)

Each ASCONF parameter is delivered an ASCONF chunk and replied by an ASCONF-ACK chunk. Therefore, three pairs of ASCONF/ASCONF-ACKs are exchanged (see Subsection 2.2.2 and Subsection 2.2.3): TaddIP TsetprimaryIP TdeleteIP = TASCON F + TASCON F ACK = TASCON F + TASCON F ACK = TASCON F + TASCON F ACK (4.10)

As we discussed in Subsection 2.2.2, all the control chunks in DAR procedure can be bundled with other data chunks in mSCTP transmission. Thus, the actual delay caused by DAR (TDAR ) procedure can also be converged to zero. This is a very important fact such that the hando delay of mSCTP (TmSCT P ) can be zero. Consequently, mSCTP hando delay is expressed as:

42 TmSCT P = Trd + TDAR = (Trs + Tra + TnewIP ) + (TaddIP + TsetprimaryIP + TdelIP ) = ( Trs + Tra + TnewIP ) + [3 (TASCON F + TASCON F ACK )]
Trd 0 (by multihoming ) TDAR 0 (by chunkbundling )

(4.11)

In Equation (4.11), again, Trd can be neglected because router discovery can be processed in an interface while data are being transmitted in another interface. TDAR period can be considered to be zero by bundling ASCONF and ASCONF-ACK control chunks with other data chunks. As we will discuss in Section 4.2, although DAR procedure incurs a constant throughput decrease, it allows mSCTP supports quasiseamless hando (i.e., TmSCT P 0).

4.1.3

Comparison of Hando Delay in MIP (TM IP ) and mSCTP (TmSCT P )


In this subsection, we compare hando delay of MIP and mSCTP by comparing

agent discovery (Tad ) of MIP and router discovery (Trd ) of mSCTP as well as registration delay (Treg ) of MIP and dynamic address reconguration (TDAR ) of mSCTP. As we discuss in Subsections 4.1.1 and 4.1.2, MIP agent discovery (Tad ) and mSCTP router discovery (Trd ) are as follows: M IP : Tas + Taa + TCoA
Tad

mSCT P :

Trs + Tra + TnewIP


Trd 0 (by SCT P multihoming )

(4.12)

That is, M IP : Tad mSCT P : Trd (4.13)

As shown in (4.12), agent discovery (Tad ) of MIP is greater than router discovery (Trd ) of mSCTP since multi-homing feature of SCTP makes the actual delay of router discovery (Trd ) of mSCTP be neglected (see Equation (4.8)). Likewise, the relationship between MIP registration delay (Treg ) and mSCTP DAR procedure (TDAR ) is like the following: TregREQ + TBU + TregRES
MIP:Treg

TaddIP + TsetprimaryIP + TdeleteIP (4.14)


mSCTP:TDAR 0 (by ASCON F chunkbundling )

43 That is, M IP : Treg mSCT P : TDAR (4.15)

This is because the ASCONF chunks in the DAR procedure (TDAR ) can be bundled with other data chunks in mSCTP transmission (see Equation (4.11)). Finally, we come to the following conclusion for hando delay of MIP (TM IP ) and hando delay of mSCTP (TmSCT P ). M IP : Tad + Treg That is, M IP : TM IP mSCT P : TmSCT P (4.17) mSCT P : Trd + TDAR (4.16)

As we will see in Chapter 5, when hando rate increases, the accumulated total hando delay of MIP increases and aects the overall transmission throughput while that of mSCTP is fairly constant near zero, which means seamless data transmissions in a highly movement-oriented environment. Before discuss the simulation study, we analyze end-to-end throughput in the next section.

4.2

End-to-End Throughput
In Section 4.1, we analyzed the hando delay of MIP and mSCTP. The second

parameter we analyze is end-to-end transmission throughput of MIP and mSCTP. As discussed in Section 4.1, MIP incurs certain delay due to the MNs agent discovery and registration of its CoA with HA. Hando delay directly aects end-to-end throughput decrease since data communication should be paused during hando period. In addition, tunneling overhead is to be considered as a throughput degradation factor as well. In case of mSCTP, router discovery and DAR procedure are required to allow a CN become aware of the newly obtained IP address of an MN. However, mSCTP hando delay can be neglected as shown in Equation (4.11) (see Section 4.1), and no other signicant factors aect end-to-end throughput of mSCTP. In this section, we introduce a new variable, number of hando, to analyze end-to-end throughput of MIP and mSCTP with regard to hando rate. End-to-end transmission throughput shows

44 how the two dierent hando protocols aect the overall transmission eciency. We begin with the denition of parameters:

M IP mSCT P T CP SCT P lM IP (i) lmSCT P (i) lM IP lmSCT P ltunnel lDAR Tf l Ts

MIP end-to-end throughput (bps) mSCTP end-to-end throughput (bps)

Total TCP data load without any hando (bit) Total SCTP data load without any hando (bit)

Data loss during ith MIP hando (bit) Data loss during ith mSCTP hando (bit)

Average loss of trac during an MIP hando (bit) Average loss of trac during an mSCTP hando (bit)

MIP tunneling overhead (bit) Dynamic address reconguration overhead (bit)

Period that an MN stays in foreign links (seconds)

Total transmission duration (seconds)

Number of hando during Ts

In addition, the following constant variables will be used in the analysis: Size of MIP forwarding header (20 bytes 8) (bit) Path MTU (576 bytes 8) (bit) Size of ASCONF chunk (24 bytes 8) (bit) Size of ASCONF-ACK chunk (8 bytes 8) (bit)

FM IP PMTU

CASCON F CASCON F ACK

45 As dened above, M IP and mSCT P denote end-to-end throughput of MIP and mSCTP in bit-per-second, respectively. T CP and SCT P represent total prospective data load of TCP and SCTP with xed end node (i.e., hando never occurs). is the number of hando during the transmission time (Ts ) employed to evaluate the variation of end-to-end throughput with regard to hando rate. lM IP (i) and lmSCT P (i) denote the amount of data loss, in number of bits, due to ith hando delay in MIP and mSCTP, respectively. Tf l represents the time period that MN stays in foreign links other than its home link. Ts denotes the total transmission duration. In Subsection 4.2.1 and Subsection 4.2.2, using the dened parameters, we discuss end-to-end throughput of MIP and mSCTP, respectively.

4.2.1

End-to-End Throughput in Mobile IP: M IP


End-to-end throughput is dened as the total data bits an end node receives

during transmission duration. Since MIP hando incurs data loss during its hando delay periods, end-to-end transmission throughput of MIP (M IP ), when a number of hando occurs during Ts of transmission period, can be denoted as follows: M IP = T CP (
i=1 lM IP (i)

+ ltunnel ) (4.18)

Ts T CP [( lM IP ) + ltunnel ] (bps) Ts

As shown in Equation (4.18), end-to-end throughput of MIP (M IP ) is total TCP trac oered (T CP ) subtracted by total data loss due to MIP hando delay (sum of lM IP (i) where i = 1 to ) and tunneling overhead (ltunnel ) divided by total transmission duration (Ts ). Hence, end-to-end throughput of MIP (M IP ) depends upon loss of trac due to MIP hando (lM IP ) and tunneling overhead (ltunnel ). Endto-end throughput of MIP (M IP ) decreases proportional to number of hando during the transmission period ( ). Now, let us examine amount of data loss due to MIP hando (lM IP ) and tunneling overhead (ltunnel ): lM IP = T CP TM IP Ts (4.19)

Equation (4.19) represents the average data loss per MIP hando (lM IP ) in

46 (bit) in terms of MIP hando delay (TM IP ) discussed in Section 4.1. ltunnel = T CP Tf l FM IP , Ts PMTU (4.20)

where FM IP = 160 (bit) and PMTU = 4608(bit), then ltunnel 0.0347 T CP Tf l Ts (4.21)

Equation (4.20) shows data loss incurred by MIP tunneling (ltunnel ) during the transmission period. The variable Tf l denotes the total time an MN stays in foreign links other than its home link such that tunneling is required. FM IP is the size of tunneling (outer) IP header attached to tunneling packets. P M T U is a path maximum transmission unit to which all the packets larger than this should be fragmented. Here, we assume that P M T U is set to 576 bytes (4608 bits) since 576-byte is the size of a packet that all IPv4 nodes must be able to receive. As a result, in Equation (4.21), tunneling overhead (ltunnel ) can be explained as 0.0347 (FM IP bit per fragmented IP datagram) multiplied by the fraction of data trac when an MN stays in foreign links. Therefore, we can observe in Equations (4.19) and (4.21) that data loss due to MIP hando (lM IP ) and tunneling overhead (ltunnel ) increase proportional directly to MIP hando delay (TM IP ) and the fraction of period of time an MN stays in foreign links (Tf l ). Now, by putting the result of Equations (4.19) and (4.21) to Equation (4.18), end-to-end throughput of MIP (M IP ) is derived as follows: M IP = = = T CP [( lM IP ) + ltunnel ] Ts T CP [( T CP T CP
T CP Ts TM IP Ts

) + (0.0347

T CP Ts

Tf l )]

Ts [( TM IP ) + (0.0347 Tf l )] (4.22)

Ts T CP T CP [( TM IP ) + (0.0347 Tf l )] 2 Ts Ts

As shown in Equation (4.22), end-to-end throughput of MIP (M IP ) also decreases directly proportional to MIP hando delay (TM IP ) and the fraction of period of time an MN stays in foreign links (Tf l ). In addition, when the number of hando during the transmission ( ) increases, end-to-end throughput (M IP ) of MIP decreases proportional to this hando rate.

47

4.2.2

End-to-End Throughput in mobile SCTP: mSCT P


End-to-end throughput is dened as the total data bits an end node receives

during transmission duration. Hence, end-to-end throughput of mSCTP (mSCT P ) with hando (number of hando during Ts ) is denoted as follows: mSCT P = SCT P
i=1 (lmSCT P (i)

+ lDAR ) (4.23)

Ts SCT P [ (lmSCT P + lDAR )] (bps) Ts

In Equation (4.23), lmSCT P (i) denotes data loss incurred by ith mSCTP hando delay. lDAR represents DAR chunk overhead required for an mSCTP hando. Endto-end throughput of mSCTP (mSCT P ) is the total SCTP Trac oered (SCT P ) subtracted by the total data loss due to mSCTP hando delay (sum of lmSCT P (i) where i = 1 to ) and DAR chunk overhead, divided by the total transmission duration (Ts ). Hence, end-to-end throughput of mSCTP (mSCT P ) depends on the amount of data loss due to mSCTP hando (lmSCT P ) and decreases directly proportional to hando rate. Now, let us discuss data loss incurred by mSCTP hando delay (lmSCT P ) and DAR chunk overhead (lDAR ) (We employ a parameter, lmSCT P , average data loss per mSCTP hando): lmSCT P where TmSCT P 0, lmSCT P 0 (4.25) = SCT P TmSCT P , Ts (4.24)

In Equation (4.24), lmSCT P is denoted by the fraction of data loss during a hando period. However, the average hando delay of mSCTP is zero (see Equation (4.11)), lmSCT P becomes zero. lDAR = 3 (CASCON F + CASCON F ACK ), where CASCON F = 192 bits, and CASCON F ACK = 64 bits, lDAR = 3 (192 + 64) = 768 bits (4.27) (4.26)

48 Equation (4.26) shows DAR chunk overhead (lDAR ). As shown in Equation (4.10), three DAR ASCONF parameters (add-IP, set-primary-IP, and delete-IP) require three pairs of ASCONF/ASCONF-ACK chunk. Thus, DAR procedure incurs three times CASCON F and CASCON F ACK bits overhead per mSCTP hando. Since the size of ASCONF chunk and ASCONF-ACK chunk are 192 bits and 64 bits, respectively (see Subsection 2.2.2), (lDAR ) becomes 768 bits in Equation (4.27). Although the three pairs of ASCONF and ASCONF-ACK chunks can be bundled with other data chunks, it incurs 768 bits throughput decrease. As a result, loss of trac due to an mSCTP hando (lmSCT P ) converges to a constant value, 768 bits, which is not signicant over hando rate. Now, by applying the results of Equations (4.25) and (4.27) to Equation (4.23), end-to-end throughput of mSCTP (mSCT P ) is derived as follows: mSCT P = = SCT P [ (lmSCT P + lDAR )] Ts SCT P [ (0 + 768)] Ts SCT P ( 768) Ts

(4.28)

As shown in Equation (4.28), end-to-end throughput of mSCTP (mSCT P ) is represented as the total SCTP trac load without any MN movement (SCT P ) subtracted by 768-bit DAR procedure overhead for number of Handos during the transmission, divided by the transmission duration (Ts ). That is, mSCTP hando does not incur much loss of trac and is able to support seamless hando with a constant 768-bit throughput decrease per hando.

4.2.3

Comparison of End-to-End Throughput in MIP and mSCTP


To compare end-to-end throughput of MIP (mSCT P ) and that of mSCTP

(mSCT P ), we refer to the derived Equations of mSCT P and mSCT P : Equations (4.22) and (4.28). T CP T CP [( TM IP ) + (0.0347 Tf l )] 2 Ts Ts SCT P ( 768) Ts (4.29)

As discussed, end-to-end throughput of MIP (M IP ) decreases by the product of number of hando ( ) and MIP hando delay (TM IP ) and the fraction of the period

49 of time MN stays in foreign links (Tf l ). On the other hand, end-to-end throughput of mSCTP (mSCT P ) maintains total oered trac load excluding 768-bit per hando (which does not depend on hando delay) divided by transmission duration (Ts ), which proves: M IP : M IP mSCT P : mSCT P (4.30)

4.3

Packet Loss
We discussed hando delay and end-to-end throughput of MIP and mSCTP in

Section 4.1 and Section 4.2, respectively. In this section, we analyze packet loss based on hando delay and data loss discussed in the above two sections. To evaluate hando performance, we dene packet loss as the total number of packets lost during hando periods. We begin with the denition of additional variables:

LM IP LmSCT P S

MIP packet loss (number of packet) mSCTP packet loss (number of packet) Size of a packet (bit)

LM IP denotes the number of packet loss of MIP during hando periods while LmSCT P represents the number of packet loss of mSCTP during hando periods. The variable, S, is the size of a TCP and/or SCTP packet.

4.3.1

Packet Loss in Mobile IP: LM IP


As we dened packet loss as the total number of packets lost during hando

periods, packet loss of MIP hando (LM IP ) can be represented as follows:

LM IP

=
i=1

lM IP (i) S

lM IP (number of packet) S CP T Ts TM IP S T CP S Ts (4.31)

= TM IP

50 In Equation (4.31), lM IP (i) denotes data loss incurred by ith MIP hando delay. Packet loss of MIP hando (LM IP ) with hando during transmission duration (Ts ) is the sum of data loss incurred by each hando divided by a packet size. As a result of derivation of Equation (4.31), MIP hando (LM IP ) is directly proportional to the hando delay and hando rate product.

4.3.2

Packet Loss in mobile SCTP: LmSCT P


Since packet loss is the total number of packets lost during hando periods,

packet loss of mSCTP hando (LmSCT P ) can also be denoted as the sum of data loss incurred by each hando delay divided by a packet size.

LmSCT P

=
i=1

lmSCT P (i) S

lmSCT P (number of packet) S P SCT TmSCT P Ts S (4.32)

= 0

However, in Equation (4.32), packet loss of mSCTP (LmSCT P ) becomes zero since an average hando delay of mSCTP is zero as derived in Equation (4.11). That is, mSCTP packet loss is theoretically zero regardless of hando rate.

4.3.3

Comparison of Packet Loss in MIP (LM IP ) and mSCTP (LmSCT P )


Packet loss, in the thesis, shows how reliably hando protocol supports data

transport between an MN and a CN. From Equations (4.31) and (4.32), it turned out that the packet loss of mSCTP hando is less that that of MIP. M IP : TM IP T CP S Ts mSCT P : 0 (4.33)

Especially, as hando rate becomes higher, packet loss of MIP and mSCTP has greater dierence, which means end-to-end transmission of mSCTP can be more reliable and ecient than that of MIP. Finally, we have the following result with packet loss of MIP and mSCTP. M IP : LM IP mSCT P : LmSCT P (4.34)

51

Chapter 5

Simulation and Results


In previous chapters, we have discussed the network layer hando, Mobile IP (MIP), and the transport layer hando, mobile SCTP (mSCTP). We analyzed the performance of the two dierent hando mechanisms with regard to hando delay, endto-end throughput, and packet loss. In this chapter, we describe details of our simulation and results. First, we introduce NS-2 network simulator and the related modules used in our simulation. Second, our system model, including the network architecture, hando protocol stacks, and designed scenarios, is followed. Finally, we represent and analyze the simulation results in terms of total hando delay, end-to-end throughput, and packet loss in 802.11b WLAN-only network and UMTS/802.11b integrated network.

5.1

NS-2 and Related Modules


For the simulations of the described network architectures in this chapter, NS-

2 network simulator [1] has been used. In addition, a contributed module, NS-2 SCTP [5], has been patched into an original NS-2 version 2.26 [2] and certain modication has been made to the original NS-2 in order to make NS-2 SCTP module work in our wireless simulation model. Figure 5.1 shows the structure of NS-2 modules used in the thesis. As shown in Figure 5.1, we used NS-2 all-in-one version 2.26 to integrate

52

FTP TCP SCTP IP Mobile DSDV Static       


WLAN MAC 802.11b Fixed Wireless Physical NS2 Version 2.26

Figure 5.1: NS-2 and the Related Modules used in the Simulation

NS-2 SCTP module. Our system model is built based on wireless physical, 802.11b WLAN MAC, DSDV Ad Hoc protocol, MIP, TCP, SCTP, and FTP implementation provided in NS-2 network simulator. DSDV routing protocol has been used to route packets between base station node and mobile node (MN) in NS-2 topology since NS-2 wireless infrastructure originally designed and implemented in that respect. In addition, we modied the settings of wireless MAC protocol to simulate UMTS access network. Details about NS-2 and the related modules are described in Section 5.1.1 and Section 5.1.2, respectively.

5.1.1

NS-2 Network Simulator


NS-2 is a discrete event simulator developed by LBL, Xerox PARC, UCB,

and USC/ISI [1]. Since NS-2 is an open source project, variety of IP-based network components have been developed and contributed over a long period of time [1]. NS-2 is now oered as an all-in-one package which includes most of the major IP protocol suite. NS-2 is written in two languages, C++ and Otcl. the majority of core codes are developed in C++ language for the sake of performance. Based on the hierarchical characteristics of C++ language, most of the NS-2 components are implemented based on core modules, such as node, link, packet, and agent, etc., and organized as a hierarchical structure. Most of the C++ implementations have corresponding Otcl

53 implementations through OTCL Linkage. Hence, the two hierarchical structures are mutually related and oer great performance to core component developers, and the ease of implementation for end users to simulate, respectively. In the mean time, each scenario that users design and build up is developed in TCL scripts. For instance, each scenario in our simulation, specied in Section 5.2.4, has been implemented in an independent TCL script le for each of dierent category. NS-2 has its advantages and disadvantages due to the fact that it has been evolved as an open source project. The major advantage is that NS-2 already has ample contributed modules for quite a large range of contemporary network research including IP protocol suite and a few wireless technologies. For instance, we used 802.11 WLAN, SCTP, and MIP implementations among the standard modules NS-2 provides at the moment. This is one of the most important reasons we chose NS-2 for our simulation. However, one of the burdens working on NS-2 is that the contributed modules have developed by dierent personnel in dierent version of NS without an integrated interface. This fact made us suer from excessive integration eorts throughout the work period, and nally employed NS-2 legacy modules with modied settings.

5.1.2

Related Modules
In the previous section, we described the general facts about NS-2 network

simulator and the reason why NS-2 has been used in the thesis. In this section, the major modules used in the simulation are introduced with details. In addition, we briey cover two contributed modules which we worked on, but have not been employed in our nal system model.

1. SCTP Module NS-2 SCTP module version 3.4 [5], implemented by University of Delaware, was patched into NS-2 all-in-one version 2.26 to simulate Stream Control Transmission Protocol. NS-2 SCTP module version 3.4 covers the following features dened in RFC 2960 [35]: Normal establishment of an association Two end nodes establish an SCTP as-

sociation using a four-way handshake (see item 3. Setup and Close an Association in Subsection 2.2.1) using this feature.

54 Transmission of data chunks This feature of NS-2 SCTP module supports

transmission of data chunks in an established association. Management retransmission timer timer mechanism of SCTP packet. Acknowledgement of reception of data Chunks been implemented in NS-2 SCTP module. Multi-homed SCTP endpoints SCTP multi-homing has also been implemented SACK function of SCTP has NS-2 SCTP module provides retransmission

in NS-2 SCTP module. Each network interface of a node should be dened as a regular NS-2 node. This fact makes an mSCTP MN, with two network interfaces, be composed of three NS-2 nodes. Stream identier and stream sequence number has been provided by NS-2 SCTP module. Ordered and unordered delivery SCTP is able to process both ordered and unMulti-stream feature of SCTP

ordered delivery for dierent control of chunks. This feature has been implemented in this module. SCTP slow-start and congestion avoidance SCTP slow-start and congestion

avoidance have been implemented in this module (see item 4. Data Transfer and Congestion Control in Subsection 2.2.1). Endpoint failure detection SCTP has a endpoint failure detection and auto-

failover feature. This function is provided by this module. Path failure detection in this module. Path heartbeat Path heartbeat function, to check the availability of endpoint Path failure detection function has been implemented

and path, has been provided in this module. In our simulation, SCTP has been used in two major purposes. One is the expanded transport layer hando protocol, mobile SCTP (mSCTP), which we compare with MIP in the thesis. The other purpose of SCTP module is to be used as a pure transport protocol comparing to TCP. Most of existing MIP implementation is used

55 with TCP (MIP+TCP) as a transport layer protocol. However, for fair comparison between MIP hando and mSCTP hando, we added a protocol stack, SCTP as a transport protocol over MIP (MIP+SCTP). NS-2 SCTP module provides all the features required to simulate mSCTP hando. However, we met a problem while integrating SCTP module in a wireless and wired mixed topology of NS-2. Original NS-2 implementation requires hierarchical routing scheme for this wireless/wired infrastructure network topologies. On the other hand, originally developed for xed networks only, NS-2 SCTP module made conicts with the hierarchical routing scheme. Hence, we made a modication to NS-2 classier module to resolve the conicts (see Appendix B).

2. Mobile IP Module NS-2 Mobile IP (MIP) modules have been implemented by Sun Microsystems, Inc. and University of Southern California. The modules oer the capabilities of home agent (HA) and foreign agent (FA). When an MN moves into a new subnet, agent discovery and registration procedure is triggered (see Subsection 2.1.1). Once the registration is nished, MIP module tunnels data packets to the newly obtained Care-of-Address (CoA) through an FA (see Subsection 2.1.2). This module provides an implementation of the triangular routing problem, which is one of the major reasons why MIP brings about quite a signicant end-to-end throughput degradation. In our simulation, TCP over Mobile IP (MIP+TCP) and SCTP over Mobile IP (MIP+SCTP) have been implemented for MIP hando protocol stack. This is to give a fair comparison with mSCTP as mentioned in 1. SCTP module in this subsection. For the simulation of MIP hando in 802.11b WLAN only network, we used a canonical settings of HA and FA capabilities sitting on AP nodes. Likewise, for UMTS/802.11b integrated network, we set the capabilities of HA and FA in an AP node of 802.11b and an Node-B node of UMTS, respectively.

3. 802.11b WLAN Rice Monarch (Mobile Networking Architectures) Project [3] provided substantial extensions to NS-2 network simulator. The 802.11 MAC protocol was one of the features in the project, and the current module in NS-2 2.26 version, which we used, has been ported from Monarch Project by University of California.

56 NS-2 802.11 module includes C++ implementations (Mac802 11Class) and related TCL implementations. In our simulation, data rate of the 802.11 module has been changed to 11Mbps to simulate 802.11b standard. For 802.11b WLAN environment, this module is used along with the wireless channel implementation and two ray ground propagation model over wireless physical module of NS-2. Table 5.1: 802.11b WLAN and Wireless Physical Congurations in the Simulation Model specications Channel WirelessChannel Propagation TwoRayGround Net-Interface WirelessPhy Tx coverage 250 (m) radius Radio Frequency 2.4 (GHz) Data Rate 11 (Mbps) MAC 802.11b Antenna OmniAntenna

Table 5.1 shows the congurations used for 802.11b networks in the simulation. The coverage of an 802.11b AP has been set to 250m radius, and 2.4GHz of radio frequency has been used.

4. UMTS Module NS-2 does not provide any standard CDMA implementation at the moment. During the course of the thesis work, we found a few UMTS extensions contributed by dierent personnel. Enhanced UMTS radio access network extensions for ns-2 (EURANE) [4] module, which was developed within european commission 5th framework project SEACORN, is one of the contributed modules to simulate UMTS UTRAN architecture. UMTS extensions for ns-2 module [24], developed by Pablo Martin and Paula Ballester, is another set of UMTS implementation to simulate WCDMA access network. However, unfortunately, both modules could not be accommodated in our simulation due to the fact that the integration of SCTP module into UMTS module generated conicts in implementation details as well as with dierent runnable NS-2 version. We have made eorts throughout the entire period of our thesis work. However, the dierent modules from dierent contributors released for dierent versions of NS-2 made

57 us decide to use existing NS-2 WLAN module with modied settings for UTRAN. We leave this as a future work. Finally, we set the following parameters for UMTS network parts. Table 5.2: UTRAN and Wireless Physical Conguration in the Simulation Model Channel Propagation Net-Interface Tx coverage Radio Frequency Data Rate MAC Antenna specications WirelessChannel TwoRayGround WirelessPhy 500 (m) radius 2.175 (GHz) 2 (Mbps) WLAN OmniAntenna

5.2

System Models, Protocols, and Scenarios


In this section, we start with the basic assumptions we made for our system

model. We, then, describe Network Architecture where we have run the simulation scenarios. Then, the targeted hando protocol stacks are described. We also categorize all the dierent simulation scenarios and dene SIM-N-P -D notation for the purpose of managing our simulation work in an easier manner and give an intuitive guide to our readers. In addition, an additional variable, hando rate, is described followed by the designed MN movement patterns for the simulation scenarios.

5.2.1

Assumptions
Throughout our simulation work, we assume that the

Coverage of networks

coverage of networks is overlapped, regardless of the fact whether it is the case of 802.11b WLAN-only network or UMTS/802.11b integrated networks. No matter which hando protocols are used, physically exclusive networks cannot avoid fundamental interruption of data transmission. Thus, we set this assumption to evaluate hando protocols in seamlessly covered areas.

58 Multi-homed facility Multi-homing capability of an mSCTP MN is a basic

assumption set by the protocol itself. We have built the mSCTP simulation models based on this assumption. Mobile IP in UMTS Unlike in 3GPP2, Mobile IP has not yet been adopted

as a standard mobility solution in 3GPP. In the released UMTS architecture, we assume that the Node-B has MIP agent capability for simulation purpose. Simplied UTRAN protocol stack As it is the simulation of IP layer hando and

transport layer hando targeting all-IP oriented environment, the UMTS UTRAN interface protocol stack has been simplied for the purpose of focusing on the dierent hando mechanism itself. Details of protocol stacks will be discussed in Subsection 5.2.3.

5.2.2

Network Architecture
In this subsection, we dene two network architectures and their corresponding

NS-2 topologies to simulate twelve dierent scenarios specied in Table 5.3 in Subsection 5.2.4. The network architectures show the roaming environments. We consider two network architectures: 802.11b WLAN-only network and UMTS/802.11b integrated networks.

1. Network Architecture-1: 802.11b WLAN-Only Network Network Architecture-1 is designed to simulate the three hando protocols between two 802.11b WLAN subnets: MIP+TCP, MIP+SCTP, and mSCTP. (We will describe the protocol stacks in Section 5.2.3 with more details.) Figure 5.2 (a) shows the 802.11b WLAN-only network architecture. Figure 5.2 (b) and (c) represent the corresponding NS-2 topologies. In Figure 5.2 (b) topology, we have run MIP hando scenarios including MIP+TCP and MIP+SCTP. Figure 5.2 (c) topology has been built to simulate mSCTP hando. It should be noted that three NS-2 nodes (MN core, MN if0, and MN if1) compose one practical mSCTP MN in Figure 5.2. This is because NS-2 SCTP module has been implemented in such a way that network interfaces should be dened as regular NS-2 nodes.

59

NETWORK ARCHITECTURE1

CN 11Mb 10ms

802.11b WLANOnly Network

100Mb 2ms AP MN

100Mb 2ms AP

(a) Fixed Node Access Point Mobile Node CN

MIP+TCP MIP+SCTP
11Mb, 10ms Router

Fixed Node Access Point Mobile Node

CN

mSCTP

11Mb, 10ms Router 100Mb, 2ms AP1 MN_if0 MN_if1 (c) 100Mb, 2ms AP2

100Mb, 2ms MIP/ HA

100Mb, 2ms MIP/ FA

MN

(b)

mSCTP Node

MN_Core

Figure 5.2: Network Architecture-1: (a) 802.11b WLAN-Only Network (b) NS-2 Node Topology for Mobile IP + TCP and Mobile IP + SCTP (c) NS-2 Node Topology for mobile SCTP In Figure 5.2 (b) topology, we simulated two MIP hando protocol stacks: MIP+TCP and MIP+SCTP to give a fair comparison with mSCTP, which has been simulated in Figure 5.2 (c) topology. The wireless characteristics of Network Architecture-1 is congured according to the 802.11b WLAN conguration shown in Table 5.1 in Subsection 5.1.2.

2. Network Architecture-2: UMTS/802.11b Integrated Network Network Architecture-2 is designed to simulate the three hando protocols in UMTS/802.11b WLAN integrated networks: MIP+TCP, MIP+SCTP, and mSCTP.

60 (We will describe the protocol stacks in Section 5.2.3 with more details.) Figure 5.3 (a) shows the UMTS/802.11b WLAN integrated networks architecture.
NETWORK ARCHITECTURE2
CN Internet 6Mb 10ms 6Mb 2ms GGSN 100Mb 2ms AP NodeB 100Mb 2ms SGSN 622Mb 1ms RNC MN

UMTS/802.11b Integrated Networks

(a) Fixed Node AP or BS (NodeB) Mobile Node (MN)

CN 6Mb, 10ms Router

MIP+TCP MIP+SCTP

Fixed Node AP or BS (NodeB) Mobile Node (MN)

mSCTP
CN 6Mb, 10ms Router

100Mb, 2ms AP(FA)

6Mb, 2ms GGSN 100Mb, 2ms SGSN

100Mb, 2ms AP MN_if0 MN_if1 NodeB

6Mb, 2ms GGSN 100Mb, 2ms SGSN 622Mb, 1ms RNC

MN

NodeB(HA) 622Mb, 1ms

622Mb, 1ms RNC mSCTP Node

MN_core

622Mb, 1ms

(b)

(c)

Figure 5.3: Network Architecture-2: (a) UMTS/802.11b integrated network (b) NS-2 Node Topology for Mobile IP + TCP and Mobile IP + SCTP (c) NS-2 Node Topology for mobile SCTP Figure 5.3 (b) and Figure 5.3 (c) represent the the corresponding NS-2 topologies for Network Architecture-2. In Figure 5.3 (b) topology, MIP+TCP and MIP+SCTP have been simulated, and in Figure 5.3 (c), mSCTP has been simulated. In order to simulate mSCTP hando in UMTS/802.11b integrated networks in Figure 5.3 (c), three NS-2 nodes (MN core, MN if0, and MN if1) have been employed. During the hando period, MN if0 interface and MN if1 interface maintain multiple end-to-end connec-

61 tions in a form of SCTP association. The multi-homing feature enables an mSCTP MN perform virtually seamless hando by maintaining more than a single stream of communication. The wireless characteristics of Network Architecture-2 is congured according to the UTRAN conguration shown in Table 5.2 in Subsection 5.1.2.

5.2.3

Protocol Stacks
In this subsection, the three hando protocol stacks used in the simulation

are described. The three protocol stacks include TCP over Mobile IP (MIP+TCP), SCTP over Mobile IP (MIP+SCTP), and mobile SCTP (mSCTP). MIP+TCP and MIP+SCTP are categorized as network layer hando solutions, and mSCTP is in the category of transport layer hando solution. Based on the three hando protocol stacks introduced in this subsection, we have run twelve dierent simulation scenarios in the two network architectures we discussed in Subsection 5.2.2.

1. TCP over Mobile IP (MIP+TCP) As the rst set of hando protocol, we use TCP over MIP (MIP+TCP). This protocol stack is to simulate the traditional MIP hando approach. MIP is a network layer mobility protocol that is most widely deployed having various extensions due to its performance decit. MIP supports hando based on the registration of MNs CoA (either FAs CoA or collocated CoA) with HA and subsequent packet tunneling, when MN stays in foreign links (see Section 2.1). The two features are the main functionalities that support IP-based hando but the major drawbacks of MIP at the same time.

(1) MIP+TCP in 802.11b topology Figure 5.4 shows MIP+TCP protocol stack in 802.11b WLAN-only topology. MIP module is used in L3 layer for network layer hando. NS-2 congurations of each layer are as follows: L1 layer NS-2 wireless physical module is used between MN and HA/FA, and

wired physical module is used between HA/FA and Router as well as Router and CN.

62

NS2 PROTOCOL STACK: Mobile IP + TCP in 802.11b WLAN Topology

Fixed Node Access Point Mobile Node Handoff Layer

MN L5 L4 L3 L2 L1

HA

Router


FTP TCP IP/Mobile IP 802.11b IP/Mobile IP 802.11b 802.3 IP 802.3 Wireless Physical


FTP TCP IP 802.3 10BaseT

CN

L5 L4 L3 L2 L1

100BaseT Wired Physical

Figure 5.4: MIP+TCP Protocol Stack in 802.11b WLAN Topology

L2 layer

For MN, 802.11 MAC module is used with 11Mbps data rate. 802.3

ethernet has been used in xed nodes. HA and FA have been enabled with both 802.11b and ethernet, in order to work as AP nodes. L3 layer MN and HA/FA are set with NS-2 MIP module to support network

layer hando. Once MN moves into a new foreign link, MIP-enabled AP (HA/FA) node tunnels packets to the MN through router nodes including the FA. Fixed nodes provide IP protocol. L4 layer Two end nodes, MN and CN, establish TCP connection based on

NS-2 TCP agent module. L5 layer For application level protocol, FTP has been used.

(2) MIP+TCP in UMTS topology Figure 5.5 shows MIP+TCP protocol stack in UMTS topology. In the UMTS topology, the MN communicates with the Node-B node. Node-B connects to RNC ,and, in turn, RNC connects to the gateway node, SGSN. SGSN is connected to GGSN, which communicates with CN via routers.

63

NS2 PROTOCOL STACK: Mobile IP + TCP for UMTS Topology

Fixed Node Access Point Mobile Node Handoff Layer GGSN

MN

NodeB

RNC

SGSN

L4 L3 L2 L1


FTP TCP IP/Mobile IP WLAN MAC IP/Mobile IP
WLAN MAC


FTP TCP IP 802.3 10BaseT

CN

L4 L3 L2 L1

IP 802.3

IP 802.3

IP 802.3

802.3

Wireless Physical

Physical Layer (T1/E1)

Figure 5.5: MIP+TCP Protocol Stack in UMTS Topology

L1 layer

NS-2 wireless physical module is used between MN and Node-B, and

wired physical module is used among other xed nodes. From Node-B node to GGSN node, nodes are connected by 100Mbps to 622Mbps speed xed physical while router to CN has been connected by 10Mbps. The coverage of Node-B is congured to be 500 m radius area. L2 layer For MN and Node-B, WLAN MAC module is used with modied

settings: 2Mbps data rate. 802.3 ethernet has been used for xed nodes. L3 layer MN and Node-B are set with NS-2 MIP module to support network

layer hando. Once MN moves into a new foreign link, MIP-enabled AP and/or Node-B node tunnels packets to the MN through intermediate nodes. Fixed nodes provide IP protocol. L4 layer Two end nodes, MN and CN, establish TCP connection based on

NS-2 TCP agent module. L5 layer For application level protocol, FTP has been used.

This protocol stack is used along with MIP+TCP in 802.11b topology shown in Figure 5.4, in order to simulate MIP+TCP hando in UMTS/802.11b integrated networks.

2. SCTP over Mobile IP (MIP+SCTP)

64 As the second set of hando protocol, we used SCTP over MIP (MIP+SCTP). With this protocol stack, we tried to evaluate the performance of MIP while giving a fair comparison with mSCTP hando. By using SCTP as a transport layer protocol over MIP, MIP and mSCTP can be compared under the eect of the same transmission mechanism. As in traditional MIP, MIP+SCTP supports hando based on the registration of CoA and packet tunneling in network layer by HA and FA. Only dierence from MIP+TCP is that SCTP transport protocol is sat on MIP capability.

(1) MIP+SCTP in 802.11b topology Figure 5.6 shows MIP+SCTP protocol stack in 802.11b WLAN topology.

NS2 PROTOCOL STACK: Mobile IP + SCTP in 802.11b WLAN Topology

Fixed Node Access Point Mobile Node Handoff Layer

MN

HA

Router

L4 L3 L2 L1


FTP SCTP IP/Mobile IP 802.11b IP/Mobile IP 802.11b 802.3 IP 802.3 Wireless Physical 100BaseT Wired Physical


FTP SCTP IP 802.3 10BaseT

CN

L4 L3 L2 L1

Figure 5.6: MIP+SCTP Protocol Stack in 802.11b WLAN Topology

L1 layer

NS-2 wireless physical module is used between MN and HA/FA, and

wired physical module is used between HA/FA and Router as well as Router and CN. L2 layer For MN, 802.11 MAC module is used with 11Mbps data rate. 802.3

ethernet has been used in xed nodes. HA and FA have been enabled with both 802.11b and ethernet, in order to work as AP nodes. L3 layer MN and HA/FA are set with NS-2 MIP module to support network

65 layer hando. Once MN moves into a new foreign link, MIP-enabled AP (HA/FA) node tunnels packets to the MN through router nodes including the FA. Fixed nodes provide IP protocol. L4 layer Two end nodes, MN and CN, establish SCTP connection based on

NS-2 SCTP module. L5 layer For application level protocol, FTP has been used.

As presented in Figure 5.6, we used NS-2 MIP implementation for MN and AP nodes. In the same way as shown in MIP+TCP protocol stack, once MN moves across another 802.11b subnet, MIP-enabled AP node tunnels packets to MN through other NS-2 nodes including FA.

(2) MIP+SCTP in UMTS topology Figure 5.7 shows MIP + SCTP protocol stack in UMTS topology. In the UMTS topology, MIP-enabled MN communicates with MIP-enabled Node-B node. Again, like in MIP+TCP protocol stack in UMTS topology, Node-B connects to RNC, and, in turn, RNC connects to the gateway node, SGSN.
NS2 PROTOCOL STACK: Mobile IP + SCTP for UMTS Topology
Fixed Node Access Point Mobile Node Handoff Layer GGSN

MN

NodeB

RNC

SGSN

L4 L3 L2 L1


FTP SCTP IP/Mobile IP WLAN MAC IP/Mobile IP
WLAN MAC


FTP SCTP IP 802.3 10BaseT

CN

L4 L3 L2 L1

IP 802.3

IP 802.3

IP 802.3

802.3

Wireless Physical

Physical Layer (T1/E1)

Figure 5.7: MIP+SCTP Protocol Stack in UMTS Topology

L1 layer

NS-2 wireless physical module is used between MN and Node-B, and

wired physical module is used among other xed nodes. From Node-B node to

66 GGSN node, nodes are connected by 100Mbps to 622Mbps speed xed physical while router to CN has been connected by 10Mbps. The coverage of Node-B is congured to be 500 m radius area. L2 layer For MN and Node-B, WLAN MAC module is used with modied

settings: 2Mbps data rate. 802.3 ethernet has been used for xed nodes. L3 layer MN and Node-B are set with NS-2 MIP module to support network

layer hando. Once MN moves into a new foreign link, MIP-enabled AP and/or Node-B node tunnels packets to the MN through intermediate nodes. Fixed nodes provide IP protocol. L4 layer Two end nodes, MN and CN, establish TCP connection based on

NS-2 SCTP module. L5 layer For application level protocol, FTP has been used.

This protocol stack is used along with MIP+TCP in 802.11b topology shown in Figure 5.4, in order to simulate MIP+TCP hando in UMTS/802.11b integrated networks. As discussed above in this subsection, MIP+TCP and MIP+SCTP protocol stacks are identical with regard to the structure except the fact that the two protocol stacks use dierent transport layer protocol. Both protocol stacks were designed to evaluate network layer (L3) hando performance based on MIP. However, MIP+SCTP is designed to compare network layer hando to transport layer hando with fairness in terms of transmission capability.

3. mobile SCTP (mSCTP) As a third set of hando protocol, we used mobile SCTP (mSCTP). This protocol set is to simulate the transport layer end-to-end hando mechanism. mSCTP oers quasi-seamless hando by enabling DAR procedures with multi-homing feature of SCTP. This transport layer (L4) hando does not require any agent to route packets by extra tunneling process, but notify the newly obtained IP address to the other end node of the SCTP association using an ASCONF control chunks (Add-IP, Delete-IP, and Set-Primary-IP). As we discussed in Subsection 2.2.2, ASCONF control chunks can be bundled with the other data chunks and, thus, incur no additional delay. All the

67 data packets are routed based on regular IP routing mechanism.

(1) mSCTP in 802.11b topology Figure 5.8 shows mSCTP protocol stack in 802.11b WLAN topology. We used NS-2 SCTP multi-homing feature for this protocol stack. In uplink transmission, NS2 SCTP force-source method has been used to switch the interface and NS-2 SCTP set-primary-destination method has been used in downlink transmission.

NS2 PROTOCOL STACK: mobile SCTP in 802.11b WLAN Topology

Fixed Node Access Point Mobile Node Handoff Layer

L4 L3 L2 L1


FTP IP 802.11b

MN

HA

Router

mobile SCTP IP 802.11b 802.3 100BaseT IP 802.3 Wired Physical


FTP IP 802.3

CN

mobile SCTP

L4 L3 L2 L1

Wireless Physical

10BaseT

Figure 5.8: mSCTP Protocol Stack in 802.11b WLAN Topology

L1 layer

NS-2 wireless physical module is used between MN and HA/FA, and

wired physical module is used between HA/FA and Router as well as Router and CN. L2 layer For MN, 802.11 MAC module is used with 11Mbps data rate. 802.3

ethernet has been used in xed nodes. HA and FA have been enabled with both 802.11b and ethernet, in order to work as AP nodes. L3 layer With this protocol stack, no agent is required. MN and AP nodes

are also set with regular IP module in this layer. Fixed nodes provide IP protocol as well.

68 L4 layer Two end nodes, MN and CN, establish mSCTP association based on

NS-2 SCTP module. MN and CN also interact in end-to-end manner based on DAR extension (see Subsection 2.2.2) to support transport layer hando. L5 layer For application level protocol, FTP has been used.

(2) mSCTP in UMTS topology Figure 5.9 shows mSCTP protocol stack in UMTS topology. In the UMTS topology, mSCTP MN communicates with Node-B node. In the same way as in MIP UMTS topology, Node-B connects to RNC, and, in turn, RNC connects to the gateway node, SGSN. The multi-homing capability of NS-2 SCTP has been used to implement mSCTP hando.
NS2 PROTOCOL STACK: mobile SCTP for UMTS Topology
Fixed Node Access Point Mobile Node Handoff Layer GGSN

L4 L3 L2 L1


FTP IP

MN

NodeB

RNC

SGSN

mobile SCTP IP
WLAN MAC


FTP IP 802.3 10BaseT

CN

mobile SCTP

L4 L3 L2 L1

IP 802.3

IP 802.3

IP 802.3

WLAN MAC

802.3

Wireless Physical

Physical Layer (T1/E1)

Figure 5.9: mSCTP Protocol Stack in UMTS Topology

L1 layer

NS-2 wireless physical module is used between MN and Node-B, and

wired physical module is used among other xed nodes. From Node-B node to GGSN node, nodes are connected by 100Mbps to 622Mbps speed xed physical while router to CN has been connected by 10Mbps. The coverage of Node-B is congured to be 500 m radius area. L2 layer For MN and Node-B, WLAN MAC module is used with modied

settings: 2Mbps data rate. 802.3 ethernet has been used for xed nodes.

69 L3 layer L4 layer MN and Node-B as well as xed nodes are set with regular IP protocol. Two end nodes, MN and CN, establish SCTP association based on

NS-2 SCTP module. MN and CN also interact in end-to-end manner based on DAR extension (see Subsection 2.2.2) to support transport layer hando. L5 layer For application level protocol, FTP has been used.

As we have presented in this subsection, the three hando protocol stacks are simulated in two network architectures: 802.11b WLAN-only network and UMTS/802.11b integrated network. Among the three dierent protocol stacks, MIP+TCP and MIP+SCTP are designed to simulate MIP (network layer) hando and mSCTP is designed for transport layer hando.

5.2.4

Simulation Scenarios
In Section 5.2.2 and Section 5.2.3, we presented the network architectures and

the protocol stacks, respectively. In this section, we dene the simulation scenarios based on the network architectures, the protocol stacks, and additional parameters including the direction of transmission, hando rate, and MN movement pattern.

1. Simulation Scenario Category (SIM-N-P -D ) The scenarios include two MIP hando protocols (MIP+TCP and MIP+SCTP) and mSCTP hando in two dierent network architectures (roaming patterns) described in Section 5.2.2. The scenarios are designed to evaluate the performance of MIP hando and mSCTP hando in a fair manner. That is, we assumed the transmission behavior of TCP is fairly dierent from that of SCTP with regard to its congestion control, ow control mechanism, interaction with other layers in the stack, etc., so it should be required to simulate the behavior of SCTP as a pure transport layer protocol over MIP and compare it to mSCTP transmission. For simplicity and lucidity, we dene a notation to categorize the simulation scenarios: SIM-N-P -D as shown in Figure 5.10. This notation has been used to manage the simulation work and results in a clear way as well as to help readers to have intuitive distinction between dierent scenarios. Hence, we put the SIM-N-P -D notation in every simulation scenario category from this point on.

70

Denotation: SIM NP D

N : Network Architecture
(Roaming Pattern)

= 1 : 802.11b WLAN Only = 2 : UMTS/802.11b = 1 : Mobile IP + TCP = 2 : Mobile IP + SCTP = 3 : mobile SCTP =1 =2
: Uplink (MN to CN) : Downlink (CN to MN)

P : Protocol

D : Transmission direction

Figure 5.10: Simulation Scenario Category (SIM-N-P -D )

As shown in Figure 5.10, N, P , and D denote the networks architecture, the protocol stack, and the direction of transmission, respectively. N denotes the network architecture (Roaming Pattern) (see Section 5.2.2)

in the simulations. We built two major network architectures which are 802.11b WLAN-only ( = 1) and UMTS/802.11b integrated networks ( = 2). P presents the protocol sets (see Section 5.2.3) used in the simulation. Mobile

IP + TCP ( = 1) is the protocol set to simulate traditional Mobile IP hando. Mobile IP + SCTP ( = 2) is to give a fair comparison to mobile SCTP having SCTP as a general purpose transport protocol. mobile SCTP ( = 3) is to simulate the transport layer hando based on the DAR extension of SCTP. D describes the direction of the transmission whether MN-to-CN Uplink (

= 1) or CN-to-MN Downlink ( = 2). For example, mSCTP hando in UMTS/802.11b integrated networks during uplink transmission can be denoted as SIM-N2-P3-D1. With the combination of the mobility scenarios dened in Figure 5.10, we have run twelve simulation scenarios to study the performance eects of MIP hando and

71 mSCTP hando, varying hando rate (which will be described in the subsection), in both 802.11b WLAN-only network and UMTS/802.11b integrated networks environments. Table 5.3: Simulation Scenarios (See Figure 5.10, Section 5.2.2, and Section 5.2.3) N: Network P : Protocol 1 MIP+ TCP 2 MIP+ SCTP 3 mSCTP 1 2 UMTS/ 802.11b 2 3 MIP+ TCP MIP+ SCTP mSCTP D : Direction 1 Uplink 2 Downlink 1 Uplink 2 Downlink 1 Uplink 2 Downlink 1 Uplink 2 Downlink 1 Uplink 2 Downlink 1 Uplink 2 Downlink

802.11b

In summary, as listed in Table 5.3, the simulation scenarios have been designed based on the two network architectures given in Section 5.2.2 and the three protocol stacks given in Section 5.2.3. By combining the network architectures and the hando protocol stacks, we designed twelve dierent scenarios to evaluate and compare the performance of the network layer hando, MIP, and the transport layer hando, mSCTP.

2. Hando Rate In order to evaluate the performance of the three hando protocol stacks, we introduce a variable hando rate in the simulation. Hando rate ( ) is number of handos during our simulation unit time 600

seconds (10 minutes). We increase hando rate ( ) and investigated how the three hando protocol stacks react with respect to total hando delay, end-to-end throughput, and packet loss. The reason we employed hando rate ( ) is to measure the variation of performance parameters according to various intensity of mobile environment. Hence our simulation results will show which hando protocol is more seamless and reliable irrespective of hando rate

72 ( ). For nomadic users, the performance of hando protocol does not give much negative eect, but we aimed to evaluate the performance of the hando protocols for ubiquitous users. During 600 seconds of transmission duration, 0 to 10 hando occurrences have been simulated. That is, the lowest rate of 0 hando to the highest rate of 10 Handos per 10-minute unit time have been simulated to evaluate the performance of the three hando protocol stacks.
Number of Handoff () 10 9 8 7 6 5 4 3 2 1 100 200 300 Simulation Time (sec) 400 500 600 Time to trigger the MN movement

Figure 5.11: Hando Rate (Occurrences of Hando) Figure 5.11 shows the designed occurrences of hando during the unit time of the simulation. The x-axis denotes the simulation time while the y-axis represents the number of handos. Each point in the gure represents the starting time of MN movement which triggers a hando. By each of the MN movement, MN is designed to move into a new subnet such that MIP registration or mSCTP DAR procedure occurs. The MN movement distribution is explicitly determined in order to avoid random movement.

3. MN movement In order to make 11 dierent hando rate (0 to 10 times per unit time) for each scenario, the MN movement generation algorithm in Figure 5.12 has been used in our NS-2 TCL scripts. t in the pseudo code represents the total transmission duration of the simulation. is the hando rate. is the initial transmission oset which is used to settle down the initial link status.

73

Pseudo Code: MN Movement Generation


IF = 0 THEN DO NOTHING ELSE WHILE i NOT GREATER THAN DO IF i IS ODD t $ns_ at i * +1 ELSE $ns_ at END IF END END IF

[( [(

) )

i *

t +1

] ]

MN MOVE TO (x0, y0)

MN MOVE TO (x1, y1)

t Transmission Duration Number of Handoff Initial Transmission Offset

Figure 5.12: Pseudo Code: MN Movement Generation

Based on the MN movement generation algorithm, we designed two dierent MN movement patterns for 802.11b WLAN-only network and UMTS/802.11b integrated networks, respectively. The two MN movement patterns are as follows: MN movement in 802.11b WLAN-only network: SIM-N1-P -D As listed

in Table 5.3, MIP+TCP (SIM-N1-P1-D ), MIP+SCTP (SIM-N1-P2-D ) and mSCTP (SIM-N1-P3-D ) simulations have been run in 802.11b WLAN-only networks. For the three protocols, the same MN movement pattern has been used for fair comparison. The MN movement in 802.11b WLAN is illustrated in Figure 5.13. Two 802.11b access points, A and B, are deployed as shown in Figure 5.13. The radius of a 802.11b network is set to 250 meters. The MN is located in the coordination of (100, 100) at the beginning and moves toward the coordination (250, 250). For the scenarios with more than two handos, the MN moves between the two coordination points back and forth. The MN moves at the constant velocity of 10 m/s (or 36 km/h). The time for MN to reach the overlapped region

74

400

r=2

50
(325, 325)

300

(meter)

MN AP Movement path

(250, 250) 200

100

(100, 100)


(0, 0)

A (25, 25) 100 200 Speed of MN 300 400 (meter) 500

v r = 25 0
10 m/s = 36 km/h approx. 7.07 sec approx. 7.07 sec Time to reach the overlapped region Time taken in the overlapped region Round Trip Time of MN 21.21 sec

Figure 5.13: MN Movement Pattern for 802.11b WLAN-Only Network: SIM-N1-P -D is approximately 7.07 seconds and the time taken in the overlapped region is approximately 7.07 seconds. That is, the round trip time between two coordination points is approximately 21.21 seconds. As we mentioned in the previous section, we assumed that the simulation topologies have certain overlapped areas. We particularly set the overlapped area as in Figure 5.13 since 7.07 seconds can be considered as reasonably enough time for both MIP and mSCTP to trigger their hando procedures. The speed of MN has been set to 10 m/s to target a semi-vehicular speed node in a city area. This is because we focused on highly movement-oriented environment. MN movement in UMTS/802.11b integrated networks: SIM-N2-P -D For

UMTS/802.11b integrated networks, MIP+TCP (SIM-N1-P1-D ), MIP+SCTP (SIM-N1-P2-D ) and mSCTP (SIM-N1-P3-D ) simulations have been run as well. For the three protocols, the same MN movement pattern has been used for fair comparison. Figure 5.13 shows the movement pattern.

10

/s

75

(meter)

Speed of MN

10 m/s = 36 km/h approx. 7.07 sec approx. 7.07 sec

Time to reach the overlapped region Time taken in the overlapped region Round Trip Time of MN 21.21 sec

500

(500, 500)

400

r=5

00

300 (250, 250) 200

MN NodeB AP Movement path

100

(100, 100)


(0, 0)

A (25, 25) 100

10

/s

r=

250

200

300

400

500

(meter)

Figure 5.14: MN Movement Pattern for UMTS/802.11b Integrated Networks: SIM-N2P -D An AP, A, and a Node-B, B, are placed in UMTS/802.11b integrated networks topology. The radius of a 802.11b network is set to 250 meters, and that of UMTS is set to 500 meters. The MN, initially, stays in the coordination of (250, 250) in UMTS region. According to the hando rate to simulate, the MN moves between UMTS region and 802.11b region at the time specied in the MN movement generation algorithm (see Figure 5.12). Like in 802.11b WLAN-only network, the MN moves at the constant velocity of 10 m/s (or 36 km/h). The time for MN to reach the overlapped region is approximately 7.07 seconds and the time taken in the overlapped region is approximately 7.07 seconds. In this heterogeneous environment, we also targeted a semi-vehicular speed node in a city area to simulate highly movement-oriented environment.

76 4. Trac For all the simulation scenarios, the same FTP trac is used. FTP data packets are transmitted for 600 seconds (from 30 second to 630 second period). We gave initial 30-second period to obtain stable link status before transmission.

5. Performance Parameters For the performance evaluation of hando protocols, we use the same parameters used in Chapter 4. Performance Analysis of Mobile IP and mobile SCTP Hando. The three performance parameters, total hando delay, end-to-end throughput, and packet loss, have been measured as follows: Total hando delay In order to obtain a hando delay from the simulation

result, we analyze the simulation traces and measure the dierence between the time a hando is triggered and the time a transport layer packet is successfully received after the hando period (i.e., registration period for MIP and DAR procedure for mSCTP). We nally measure the total hando delay by summing up all the hando delays. End-to-end throughput From the simulation trace of each scenario, we calcu-

lated the total number of bits successfully received. To obtain end-to-end throughput in bps, the total number of bits received are divided by the total transmission duration. Packet loss In the simulation analysis, packet loss has been measured by count-

ing the number of packets lost during total hando delay.

5.3

Simulation Results of 802.11b WLAN-only Network


In this section, we describe the simulation results of the three hando protocol

stacks in 802.11b WLAN (SIM-N1-P -D ) (see Figure 5.10) in terms of total hando delay, end-to-end throughput, and packet loss.

77

5.3.1

Uplink Behaviors
In this subsection, we discuss the MN-to-CN simulation results of the hando

protocol stacks. Figure 5.15 shows an example of the uplink (MN to CN) transmission behavior (with ve handos in the unit time, 10-minute) of the three protocol stacks in 802.11b WLAN-only network (SIM-N1-P -D1) (see Figure 5.10).
18 x 10
8

Handoff Behavior in 802.11b WLAN (Uplink) mSCTP

16

MIP+SCTP
14

Number of Bits Received (bit)

12

10

Handoff Delay
0

MIP+TCP
0 100 200 300 400 500 600

Time (second)

Figure 5.15: Hando Behavior in 802.11b WLAN-Only Network (Uplink): SIM-N1-P D1 The x-axis in Figure 5.15 denotes the simulation time. The y-axis represents the number of total bits received at CN. Each line shows the transmission bit rate of each hando protocol. From the result, ve hando delay periods are recognized in both MIP+TCP and MIP+SCTP protocol stacks. Although MIP+SCTP CN received more data than that of MIP+TCP, both protocol stacks show inherent hando delay of MIP due to its registration period. On the other hand, mSCTP hando shows the highest transmission rate without any delayed period in Figure 5.15. This is because mSCTP uses multi-homing and DAR procedure, which provides ASCONF chunk bundling in ordinary data packets (see Subsection 2.2.2). In the uplink transmission (MN to CN), mSCTP MN determines to switch to a newly obtained IP address while moving in an overlapped region. This procedure is implemented by using force-source method (see Appendix A) provided by NS-2 SCTP module. Now, we will discuss the three performance parameters one by one.

78

1. Total Hando Delay We measured the total accumulated hando delay for 11 dierent hando rates. Hando delay in MIP includes registration period while mSCTP requires DAR procedure (see Subsections 2.1.1 and 2.2.2). As mSCTP DAR procedure sends and receives at most three pairs of ASCONF and ASCONF-ACK control chunks (256-bit per each pair) bundling with the other data chunks, the hando delay can be neglected although it incurs a 768-bit throughput decrease per hando. Figure 5.16 shows the uplink (MN to CN) hando delay of MIP+TCP, MIP+SCTP, and mSCTP over hando rate.
Total Handoff Delay in 802.11b WLAN (Uplink)
140

120

100

Delay (second)

80

MIP+SCTP

60

MIP+TCP

40

20

mSCTP
0

10

Handoff Rate (# per 10minute)

Figure 5.16: Total Hando Delay in 802.11b WLAN-Only Network (Uplink): SIM-N1P -D1 (95% Condence Interval) Total hando delays vs hando rate shows how the hando delay of each hando protocol reacts when mobility intensity increases. In Figure 5.16, the total hando delays of MIP+TCP and MIP+SCTP linearly increase as expected from our analysis in Subsection 4.1.1. In contrast, mSCTP hando does not incur any delay irrespective of the hando rate. This is due to the fundamental dierence between MIP hando registration procedure and mSCTP DAR procedure. That is, mSCTP can trigger DAR procedure by bundling ASCONF and ASCONF-ACK chunks with the other data chunks.

79 The result shows that the hando delay of two MIP protocol stacks becomes more signicant as hando rate increases. As we discussed in Subsections 4.2.1 and 4.3.1, hando delay and hando rate product directly aects the end-to-end throughput and packet loss. (We discuss the results of end-to-end throughput and packet loss later in this subsection.) Thus, MIP cannot be a proper hando approach in highly mobility-oriented environments. On the other hand, mSCTP does not aect any significant throughput decrease nor packet loss by keeping zero hando delay regardless of hando rate.

2. End-to-end Throughput In the analysis in Section 4.2, we concluded end-to-end throughput decrease directly proportional to the product of hando delay and hando rate. Now, from the transmission behavior of each scenario, we calculated the end-to-end throughput of three dierent hando protocol stacks. Each scenario (SIM-N1-P -D ) (see Figure 5.10) has been run with 11 dierent hando rates (0 to 10 hando occurrences in 10-minute unit time). The uplink end-to-end throughput has been calculated as the total number of bits received at CN divided by the transmission duration. Figure 5.17 shows the uplink (MN to CN) end-to-end throughput in bit-per-second (bps) over the hando rate.
2.8 x 10
6

EndtoEnd Throughput in 802.11b WLAN (Uplink)

2.6

mSCTP

2.4

Throughput (bps)

MIP+SCTP

2.2

1.8

MIP+TCP

1.6

10

Handoff Rate (# per 10minute)

Figure 5.17: End-to-end Throughput in 802.11b WLAN-Only Network (Uplink): SIMN1-P -D1 (95% Condence Interval)

80 The end-to-end throughput of MIP+TCP and MIP+SCTP decreases as hando rate increases while that of mSCTP maintains consistent values regardless of the hando rate. First, the basic end-to-end throughput without any hando in MIP+TCP is about 2.026 Mbps, and it goes down to 1.745 Mbps when 10 handos occur in the unit time, 10 minutes. The dierence, 281 Kbps, makes 161 Mbits data loss out of 1215.6 Mbits total possible data transmission during the unit time. Second, MIP+SCTP produces about 2.678 Mbps end-to-end throughput when no hando occurs and approximately 2.269 Mbps with 10 handos. The 409 Kbps difference incurs 245.4 Mbits data loss out of 1606.6 Mbits of total possible data transmissions. The reason why MIP+SCTP produces better basic transmission rate than that of MIP+TCP is that SCTP uses SACK algorithm as well as multi-chunk message based stream with enhanced congestion control mechanism (see Subsection 2.2.1). Unlike TCP, SCTP does not mandatorily require in-order data arrival in packet sequence level but in each chunk level. So, all the in-order data chunks can be handed over to the upper layer protocol in protocol stack irrespective of the fact whether there was any out-of-order data chunk. Finally, the end-to-end throughput of mSCTP keeps about 2.695 Mbps data rate irrespective of the hando rate. This means that mSCTP can exploit up to about 1617 Mbits of data transmission during unit time, without any signicant loss of data. As shown in Figure 5.17, mSCTP produces very stable and higher end-to-end throughput comparing to MIP+TCP and MIP+SCTP, regardless of the hando rate. That is, mSCTP, the transport layer hando can be much more ecient, in terms of throughput, than MIP in highly mobility-oriented environments.

3. Packet Loss To measure packet loss, we counted the total number of data packets lost during total hando delay periods. The packet loss over the hando rate shows how the hando protocols react under the variation of the intensity of MN mobility. Especially, data packet losses can trigger congestion control of transport layer protocol, and thus, aect the quality of service. Figure5.18 shows the uplink (MN to CN) packet loss in number of packets lost over the hando rate. Figure 5.18 shows that the number of packet loss of MIP+SCTP and MIP+TCP increases proportional to hando rate while that of mSCTP does not increase and main-

81
Packet Loss in 802.11b WLAN (Uplink)
8

Packet Loss (# of packet)

MIP+SCTP
3

MIP+TCP

mSCTP
0

10

Handoff Rate (# per 10minute)

Figure 5.18: Packet Loss in 802.11b WLAN-Only Network (Uplink): SIM-N1-P -D1 (95% Condence Interval) tains zero. First, the number of packet loss in MIP+TCP increases linearly showing a little uctuation with the highest value of 5.167 in 9-hando scenario. Second, the number of packet loss of MIP+SCTP also has a little uctuation increasing up to 6.717 at 10-hando scenario. Finally, mSCTP maintains zero packet loss irrespective of hando rate. This is the result from the fact that the multi-homing of SCTP and DAR procedure makes no hando delay (see Subsection 4.3.2). As we have seen in Figure 5.16, the hando delay of MIP+TCP and MIP+SCTP shows identical relationship with the packet loss. That is, the number of packet loss in MIP+TCP and MIP+SCTP is directly aected by the total hando delay periods as discussed in Section 4.3. In this subsection, we presented and analyzed the result of the uplink (MN to CN) performance of the MIP+TCP, MIP+SCTP, and mSCTP handos in terms of total hando delay, end-to-end throughput, and packet loss. In the next subsection, the downlink (CN to MN) behaviors are discussed.

5.3.2

Downlink Behaviors
In this subsection, we discuss the downlink (CN to MN) behaviors of the

802.11b WLAN simulation results. Generally, it is known that downlink trac over-

82 whelms uplink trac in terms of the proportion of the application level services. Figure 5.19 is an example transmission behavior (with ve handos per unit time) of the three hando protocol stacks for downlink (CN to MN) trac in 802.11b WLAN (SIM-N1P -D2) (see Figure 5.10).
16 x 10
8

Handoff Behavior in 802.11b WLAN (Downlink) mSCTP

14

MIP+SCTP

12

Number of Bits Received (bit)

10

Handoff Delay
0

MIP+TCP
0 100 200 300 400 500 600

Time (second)

Figure 5.19: Hando Behavior in 802.11b WLAN-Only Network (Downlink): SIM-N1P -D1 Like in the uplink transmission, the x-axis in Figure 5.19 is the simulation time and the y-axis is the number of total bits received at MN. In this graph, the bit rate of mSCTP is also higher than that of MIP+TCP and MIP+SCTP. With MIP+TCP and MIP+SCTP protocols, we can notice ve hando delay periods during the transmission while mSCTP does not make any delay period. In the downlink transmission (CN to MN), mSCTP MN triggers DAR procedure with three pairs (add-IP, set-primary-IP, and delete-IP) of ASCONF and ASCONF-ACK control chunks cooperating with CN. After receiving an add-IP ASCONF request, CN adds the received IP address as a new IP address in the existing association and responds with ASCONF-ACK. In turn, MN sends a set-primary-IP chunk to let CN switch the transmission to the new IP address. Upon the reception of the set-primary-IP ASCONF chunk, CN switches the destination address to the requested IP address and respond back to MN with ASCONF-ACK. Delete-IP can also be performed if it is preferable. We implemented this scenario using set-primary-destination method provided by NS-2 SCTP module. Now, we analyze the

83 performance of the three hando protocols in terms of total hando delay, end-to-end throughput, and packet loss.

1. Total Hando Delay Figure 5.20 shows the downlink (CN to MN) hando delay (in second) over the hando rate.
Total Handoff Delay in 802.11b WLAN (Downlink)
120

100

MIP+TCP
80

Delay (second)

60

MIP+SCTP
40

20

mSCTP

10

Handoff Rate (# per 10minute)

Figure 5.20: Total Hando Delay in 802.11b WLAN-Only Network (Downlink): SIMN1-P -D2 (95% Condence Interval) In downlink case, the total hando delay of MIP+TCP and MIP+SCTP increase proportional to the hando rate while that of mSCTP keeps zero irrespective of the hando rate. However, the MIP hando delay is not as smooth as that of the uplink case showing more uctuations. With the same reason with uplink case, MIP hando brings about the unavoidable registration delay (see Subsections 2.1.1 and 4.1.1). On the contrary, mSCTP performs DAR procedure using at most three pairs of ASCONF and ASCONF-ACK control chunks (256-bit per each pair) bundling with the other data chunks in the existing transmission. In addition, the total hando delay of MIP+TCP and MIP+SCTP shows quite an identical trend although the dierence is not perfectly identical. This is because, as we discussed in the uplink case, the registration procedure of MIP should be processed regardless of the transport layer protocols used.

84

2. End-to-end Throughput Figure 5.21 shows the downlink (CN to MN) end-to-end throughput in bitper-second (bps) over the hando rate.
2.7 x 10
6

EndtoEnd Throughput in 802.11b WLAN (Downlink)

2.6

mSCTP
2.5

MIP+SCTP
2.4

Throughput (bps)

2.3

2.2

2.1

1.9

1.8

MIP+TCP
0 1 2 3 4 5 6 7 8 9 10

1.7

Handoff Rate (# per 10minute)

Figure 5.21: End-to-end Throughput in 802.11b WLAN-Only Network (Downlink): SIM-N1-P -D2 (95% Condence Interval) As in the uplink end-to-end throughput, the throughput of MIP+TCP and MIP+SCTP decreases as the hando rate increases while that of mSCTP maintains consistent values irrespective of the hando rate. Overall trend of transmission looks very similar to the uplink behavior, but the average throughput of MIP is slightly lower than that of the uplink case. This is because downlink incurs unavoidable tunneling overhead while uplink is able to transmit to CN directly. Although the ene-to-end throughput of mSCTP is consistently maintained, a 768-bit DAR procedure overhead is incurred per each hando as discussed in Subsection 4.2.2. First, the basic throughput without any hando in MIP+TCP is about 1.970 Mbps, and it goes down to 1.752 Mbps when 8 handos occur within the 10-minute unit time. The dierence, 218 Kbps, makes 130.8 Mbits data loss out of 1182 Mbits total possible data transmission during the unit time. Second, MIP+SCTP produces about 2.673 Mbps throughput when no hando occurs and approximately 2.326 Mbps with 10 handos. The 347 Kbps dierence incurs 208.2 Mbits data loss out of 1603.8 Mbps

85 total possible data transmissions. Last, the end-to-end throughput of mSCTP keeps about 2.664 to 2.672 Kbps regardless of the hando rate. This means that mSCTP can exploit up to about 1603.2 Mbps data transmission during the unit time, 10-minute, without any signicant loss. However, it should be noted that mSCTP MN should trigger DAR procedure by sending two to three pairs (add-IP, set-primary-IP, and delete-IP) of ASCONF and ASCONFACK control chunks to CN in order to notice CN the fact that CN should switch the destination IP address to MNs newly obtained IP address. The accumulated DAR procedures during the scenario decrease the end-to-end throughput of mSCTP although the amount of decrease is insignicant. That is, the throughput decrease is denitely insignicant amount comparing to that of MIP+ TCP and MIP+SCTP. Here, we should notice that the DAR procedure does not incur any delay at all while generating the insignicant throughput decrease. As shown in the gure, mSCTP produces a stable and higher end-to-end throughput over MIP+TCP and MIP+SCTP in the downlink case as well. The effect of mSCTP becomes very apparent when the hando rate increases. mSCTP shows far better end-to-end transmission throughput in highly hando intensive environment by exploiting its multi-homed seamless hando mechanism.

3. Packet Loss Figure 5.22 shows the downlink (CN to MN) packet loss in number of packets lost over the hando rate. The gure shows the same overall trend as in the uplink case. However, the number of packet loss in MIP+TCP and MIP+SCTP is a bit smaller than that of in the uplink case. This result can be explained by the relationship of total hando delay of MIP+TCP and MIP+SCTP. The smaller hando delay yields the smaller packet loss. Meanwhile, mSCTP shows zero packet loss based on the multi-homing feature. Having 3.933 and 3.233 highest packet losses in 8 and 10-hando scenarios, respectively, MIP+TCP and MIP+SCTP do not incur signicant congestion control problems in transport layer. However, it is apparent that the chance of transport layer transmission timeout become higher when the hando rate increases. On the other hand, without any packet loss, mSCTP is able to support stable and reliable data transmissions irrespective of hando rate.

86
Packet Loss in 802.11b WLAN (Downlink)
5

4.5

MIP+TCP

Packet Loss (# of packet)

3.5

2.5

MIP+SCTP

1.5

0.5

mSCTP

10

Handoff Rate (# per 10minute)

Figure 5.22: Packet Loss in 802.11b WLAN-Only Network (Downlink): SIM-N1-P -D2 (95% Condence Interval)

5.4

Simulation Results of UMTS/802.11b Integrated Networks


In this section, we describe the simulation results of the hando protocol stacks

in UMTS/802.11b integrated networks (SIM-N2-P -D ) (see Figure 5.10) with regard to total hando delay, end-to-end throughput, and packet loss. By the comparative analysis, we evaluate the performance of hando in UMTS/802.11b integrated networks based on MIP+TCP, MIP+SCTP, and mSCTP.

5.4.1

Uplink Behaviors
In this subsection, we discuss the MN-to-CN simulation results of the hando

protocol stacks. Figure 5.23 shows an example of the uplink (MN to CN) transmission behavior (with ve handos in the unit time, 10-minute) of the three protocol stacks in UMTS/802.11b integrated networks (SIM-N2-P -D1) (see Figure 5.10). The x-axis in Figure 5.23 represents the simulation time, and the y-axis represents the number of total bits received at CN. Each line of graph shows the transmission bit rate of each hando protocol. Five hando delay periods are recognized in both

87
Handoff Behavior in UMTS/802.11b (Uplink) mSCTP
14

16

x 10

MIP+SCTP

12

Number of Bits Received (bit)

10

Handoff Delay
0

MIP+TCP
0 100 200 300 400 500 600

Time (second)

Figure 5.23: Hando Behavior in UMTS/802.11b Integrated Networks (Uplink): SIMN2-P -D1 MIP+TCP and MIP+SCTP protocol stacks. Although MIP+SCTP CN received more data than that of MIP+TCP, both protocol stacks show inherent hando delay of MIP due to its registration period. On the other hand, mSCTP hando shows the highest transmission rate without any delayed period in Figure 5.23. This is because mSCTP uses multi-homing and DAR procedure, which provides ASCONF chunk bundling in ordinary data packets (see Subsection 2.2.2). Like in the 802.11b WLAN-only network architecture, force-source method (see Appendix A) of NS-2 SCTP module has been used to implement this scenarios. In Figure 5.23, it should be noted that the data rate varies during the transmission period. According to the position of MN ,whether it is in UMTS Node-B coverage or in 802.11b AP coverage, MN utilizes the underlying network data rates. Now, we discuss each performance parameter with details.

1. Total Hando Delay We measured the total accumulated hando delay during the simulation time. Hando delay in MIP includes registration period while mSCTP requires DAR procedure (see Subsections 2.1.1 and 2.2.2). As mSCTP DAR procedure sends and receives at most three pairs of ASCONF and ASCONF-ACK control chunks (256-bit per each

88 pair) bundling with the other data chunks, the hando delay can be neglected although it incurs a 768-bit throughput decrease per hando. Figure 5.24 shows the uplink (MN to CN) hando delay of MIP+TCP, MIP+SCTP, and mSCTP over hando rate.
Total Handoff Delay in UMTS/802.11b (Uplink)
120

100

80

Delay (second)

60

MIP+SCTP

40

MIP+TCP
20

mSCTP
0 0 1 2 3 4 5 6 7 8 9 10

Handoff Rate (# per 10minute)

Figure 5.24: Total Hando Delay in UMTS/802.11b Integrated Networks (Uplink): SIM-N2-P -D1 (95% Condence Interval) Total hando delays vs hando rate shows how the hando delay of each hando protocol reacts when mobility intensity increases. In Figure 5.24, the total hando delays of MIP+TCP and MIP+SCTP linearly increase as expected from our analysis in Subsection 4.1.1. In contrast, mSCTP hando does not incur any delay irrespective of the hando rate. This is due to the fundamental dierence between MIP hando registration procedure and mSCTP DAR procedure. That is, mSCTP can trigger DAR procedure by bundling ASCONF and ASCONF-ACK chunks with the other data chunks. The result shows that the hando delay of two MIP protocol stacks becomes more signicant as hando rate increases. As we discussed in Subsections 4.2.1 and 4.3.1, hando delay and hando rate product directly aects the end-to-end throughput and packet loss. (We discuss the results of end-to-end throughput and packet loss later in this subsection.) Thus, MIP cannot be a proper hando approach in highly mobility-oriented environments. On the other hand, mSCTP does not aect any significant throughput decrease nor packet loss by keeping hando delay zero regardless of

89 hando rate.

2. End-to-end Throughput In the analysis in Section 4.2, we concluded end-to-end throughput decrease directly proportional to the product of hando delay and hando rate. Now, from the transmission behavior of each scenario, we calculated the end-to-end throughput of three dierent hando protocol stacks. Each scenario (SIM-N2-P -D ) (see Figure 5.10) has been run with ten dierent hando rates (0 to 10 hando occurrences in 10-minute unit time). The uplink end-to-end throughput has been calculated as the total number of bits received at CN divided by the transmission duration. Figure 5.25 shows the uplink (MN to CN) end-to-end throughput in bit-per-second (bps) over the hando rate.
1.3 x 10
6

EndtoEnd Throughput in UMTS/802.11b (Uplink)

1.25

1.2

mSCTP
1.15

Throughput (bps)

1.1

1.05

MIP+SCTP

0.95

0.9

MIP+TCP
0.85

0.8

4 5 6 Handoff Rate (# per 10minute)

10

Figure 5.25: End-to-End Throughput in UMTS/802.11b Integrated Networks (Uplink): SIM-N2-P -D1 (95% Condence Interval) For all the three hando protocol stacks, the end-to-end throughput with 1hando is increased from the case of 0-hando. This is due to the fact that the MN utilize the higher bandwidth of 802.11b from 1-hando scenarios (see item 3. MN movement in Subsection 5.2.4). This result shows the benet of the network convergence paradigm we discussed in Chapter 3. However, the end-to-end throughput of MIP+TCP and MIP+SCTP still decreases as hando rate increases while that of mSCTP maintains consistent values regardless of the hando rate. First, the end-to-end throughput of

90 MIP+TCP, without any hando, is about 1.024 Mbps. It is the maximum data rate that MIP+TCP can obtain in UMTS coverage. The data rate of MIP+TCP goes up to 1.039 Mbps in 1-hando scenario, but goes down to 872 Kbps when 10 handos occur in the unit time, 10 minutes. It shows that the hando delay and hando rate product aects the degradation of end-to-end throughput in spite of the benet of the network integration. Second, MIP+SCTP produces about 1.196 Mbps end-to-end throughput when no hando occurs. The end-to-end throughput of MIP+SCTP reaches 1.219 Mbits in 1-hando scenario due to the bandwidth benet of 802.11b network. However, it goes down to approximately 954 Kbps with 8 handos. It shows MIP+SCTP also cannot take advantage of the benet of network integration when hando rate increases. The reason why MIP+SCTP produces better basic transmission rate than that of MIP+TCP is that SCTP uses SACK algorithm as well as multi-chunk message based stream with enhanced congestion control mechanism (see Subsection 2.2.1). Unlike TCP, SCTP does not mandatorily require in-order data arrival in packet sequence level but in each chunk level. So, all the in-order data chunks can be handed over to the upper layer protocol in the stack irrespective of the fact whether there was any out-of-order data chunk. Finally, the end-to-end throughput of mSCTP is 1.195 Mbps without any hando in the UMTS coverage. With 1-hando, it goes up to 1.238 Mbps with the benet of 802.11b bandwidth. Unlike MIP handos, the end-to-end throughput of mSCTP is maintained consistently irrespective of the hando rate (except 0-hando scenario). This means that mSCTP can exploit the higher data rate of 802.11b, without any signicant loss of data. As shown in Figure 5.25, mSCTP produces very stable and higher end-to-end throughput comparing to MIP+TCP and MIP+SCTP, regardless of the hando rate. That is, mSCTP, the transport layer hando can be much more ecient, in terms of throughput, than MIP in highly mobility-oriented environments.

3. Packet Loss To measure packet loss, we counted the total number of data packets lost during total hando delay periods. The packet loss over the hando rate shows how the hando protocols react under the variation of the intensity of MN mobility. Especially,

91 data packet losses can trigger congestion control of transport layer protocol, and thus, aect the quality of service. Figure5.26 shows the uplink (MN to CN) packet loss in number of packets lost over the hando rate.
Packet Loss in UMTS/802.11b (Uplink)
14

12

10

Packet Loss (# of packet)

MIP+SCTP

MIP+TCP
2

mSCTP
0

10

Handoff Rate (# per 10minute)

Figure 5.26: Packet Loss in UMTS/802.11b Integrated Networks (Uplink): SIM-N2-P D1 (95% Condence Interval) Figure 5.26 shows that the number of packet loss of MIP+SCTP and MIP+TCP increases proportional to hando rate while that of mSCTP does not increase and maintain zero. First, the number of packet loss in MIP+TCP increases quite linearly showing a little uctuation with 10.281 highest in 10-hando scenario. Second, the number of packet loss of MIP+SCTP also has a little uctuation increasing up to 8.656 at 10hando scenario. Finally, mSCTP maintains zero packet loss irrespective of hando rate. This is the result from the fact that the multi-homing of SCTP and DAR procedure makes no hando delay (see Subsection 4.3.2). As we have seen in Figure 5.24, the hando delay of MIP+TCP and MIP+SCTP shows identical relationship with the packet loss. That is, the number of packet loss in MIP+TCP and MIP+SCTP is directly aected by the total hando delay periods.

4. Remark In this subsection, we presented and evaluated the result of the uplink (MN to CN) performance of the MIP+TCP, MIP+SCTP, and mSCTP handos in terms

92 of total hando delay, end-to-end throughput, and packet loss. We already addressed the advantages of mSCTP over MIP protocol stacks. Apart from the performance dierence between MIP and mSCTP, we should also bring our attention to performance improvement coming from SCTP protocol. In Figures 5.25, MIP+SCTP generates higher throughput than MIP+TCP while total hando delay of MIP+SCTP is larger than that of MIP+TCP in certain hando rate ranges as shown in Figure 5.24. This observation seems contradictory to our expectation because usually the large the delay the low the throughput. For example, in the 6-hando rate case in Figure 5.24, the total hando delay of MIP+TCP is 32.3% lower than that of MIP+SCTP. Nevertheless, the end-to-end throughput of MIP+SCTP in the 6-hando rate case in Figure 5.25 shows 6.4% throughput improvement over MIP+TCP. This implies that SCTP protocol has advantages over TCP as a transport layer protocol in mobile wireless environments. Hence, mSCTP can be considered as a seamless and ecient hando protocol by exploiting advantages of SCTP transport as well as DAR procedures. In the next subsection, the downlink (CN to MN) behaviors are discussed.

5.4.2

Downlink Behaviors
In this subsection, we discuss the downlink (CN to MN) behaviors of the

UMTS/802.11b integrated networks. Generally, it is known that downlink trac overwhelms uplink trac in terms of the proportion of the application level services. Figure 5.27 is an example transmission behavior (with ve handos in the unit time) of the three hando protocol stacks for downlink (CN to MN) trac in UMTS/802.11b integrated networks (SIM-N2-P -D2) (see Figure 5.10). Like in the uplink transmission, the x-axis in Figure 5.27 is the simulation time and the y-axis is the number of total bits received at MN. The result shows the variation of data rate during the transmission. All the three hando protocol stacks take advantage of the network integration in Figure 5.27. The bit rate of mSCTP is higher than that of MIP+TCP and MIP+SCTP. With MIP+TCP and MIP+SCTP protocols, we can notice ve hando delay periods during the transmission. In the downlink transmission (CN to MN), mSCTP MN triggers DAR procedure with three pairs (add-IP, set-primary-IP, and delete-IP) of ASCONF and ASCONF-

93
Handoff Behavior in UMTS/802.11b (Downlink) mSCTP
8

x 10

MIP+SCTP

Number of Bits Received (bit)

Handoff Delay
0

MIP+TCP
0 100 200 300 400 500 600

Time (second)

Figure 5.27: Hando Behavior in UMTS/802.11b Integrated Networks (Downlink): SIM-N2-P -D2 ACK control chunks cooperating with CN. After receiving an add-IP ASCONF request, CN adds the received IP address as a new IP address in the existing association and responds with ASCONF-ACK. In turn, MN sends a set-primary-IP chunk to let CN switch the transmission to the new IP address. Upon the reception of the set-primaryIP ASCONF chunk, CN switches the destination address to the requested IP address and respond back to MN with ASCONF-ACK. Delete-IP can also be performed if it is preferable. We implemented this scenario using set-primary-destination method provided by NS-2 SCTP module. Now, we analyze the performance of the three hando protocols in terms of total hando delay, end-to-end throughput, and packet loss.

1. Total Hando Delay Figure 5.28 shows the downlink (CN to MN) hando delay (in second) over the hando rate. In downlink case, the total hando delay of MIP+TCP and MIP+SCTP increase proportional to the hando rate while that of mSCTP keeps zero irrespective of the hando rate. With the same reason with uplink case, MIP hando brings about the unavoidable registration delay (see Subsections 2.1.1 and 4.1.1). On the contrary, mSCTP performs DAR procedure using at most three pairs of ASCONF and ASCONF-

94
Total Handoff Delay in UMTS/802.11b (Downlink)
120

100

80

Delay (second)

60

MIP+SCTP

40

MIP+TCP

20

mSCTP
0

10

Handoff Rate (# per 10minute)

Figure 5.28: Total Hando Delay in UMTS/802.11b Integrated Networks (Downlink): SIM-N2-P -D2 (95% Condence Interval) ACK control chunks (256-bit per each pair) bundling with the other data chunks in the existing transmission. In addition, the total hando delay of MIP+TCP and MIP+SCTP shows quite an identical trend although the dierence is not perfectly identical. This is because, as we discussed in the uplink case, the registration procedure of MIP should be processed regardless of the transport layer protocols used.

2. End-to-end Throughput Figure 5.29 shows the downlink (CN to MN) end-to-end throughput in bitper-second (bps) over the hando rate. As in the uplink case, the end-to-end throughput of all the three hando protocol stacks shows the highest value from all the dierent hando rate scenarios. This is because MN initially stays in UMTS region in the 0-hando scenario. From the 1-hando scenario to 10-hando scenario, MN takes the benet of 802.11b network bandwidth whenever it raises hando into 802.11b region. However, in spite of the benet of network integration, the throughput of MIP+TCP and MIP+SCTP decreases as the hando rate increases while that of mSCTP maintains quite consistent values irrespective of the hando rate.

95
EndtoEnd Throughput in UMTS/802.11b (Downlink)

1.7

x 10

1.6

mSCTP

1.5

Throughput (bps)

1.4

MIP+SCTP

1.3

1.2

MIP+TCP

1.1

0.9

10

Handoff Rate (# per 10minute)

Figure 5.29: End-to-End Throughput in UMTS/802.11b Integrated Networks (Downlink): SIM-N2-P -D2 (95% Condence Interval) First, the basic throughput without any hando in MIP+TCP is about 1.012 Mbps. In 1-hando scenario, the throughput of MIP+TCP goes up to 1.457 by utilizing the higher bandwidth of 802.11b network. However, it goes down to 1.197 Mbps when 10 handos occur within the 10-minute unit time. Second, MIP+SCTP produces about 1.225 Mbps throughput when no hando occurs. As it is in MIP+TCP, the end-to-end throughput of MIP+SCTP goes up to 1.566 Mbps in 1-hando scenario, but, again, goes down to approximately 1.308 Mbps with 10 handos. Although MIP+SCTP produces little bit higher throughput than MIP+TCP, both of two MIP hando protocol stacks incur unavoidable throughput decrease. Last, the end-to-end throughput of mSCTP is 1.224 Mbps without any hando. The throughput of mSCTP reaches 1.585 Mbps in 1-hando scenario by exploiting 802.11b bandwidth. Then, mSCTP hando maintains about the same data rates as in 1-hando scenario with little uctuations. This means that mSCTP can utilize the benet of network integration without any signicant data loss. Like in 802.11b WLANonly network, mSCTP has only 768-bit DAR procedure overhead per hando. The accumulated DAR procedure overhead decreases the end-to-end throughput of mSCTP, but the amount of decrease is insignicant comparing to that of MIP. Here, we should notice that the DAR procedure does not incur any delay at all while generating the

96 insignicant throughput decrease. The throughput degradation of MIP hando in downlink transmission of UMTS /802.11b integrated networks is not as big as that of 802.11b WLAN-only network. For all the three hando protocols, the throughput of 10-hando scenario is even higher than that of 0-hando scenario in which MN stays only in UMTS region. This shows the benet of network integration. However, the throughput of MIP+TCP and MIP+SCTP still decreases signicantly comparing to that of mSCTP. As shown in Figure 5.29, mSCTP produces quite stable and higher end-to-end throughput over MIP+TCP and MIP+SCTP in the downlink case as well. The eect of mSCTP becomes very apparent when the hando rate increases. mSCTP shows far better end-to-end transmission throughput in highly hando intensive environment by exploiting its multi-homed seamless hando mechanism.

3. Packet Loss Figure 5.30 shows the downlink (CN to MN) packet loss in number of packets lost over the hando rate.
Packet Loss in UMTS/802.11b (Downlink)
12

10

Packet Loss (# of packet)

MIP+SCTP
4

MIP+TCP
2

mSCTP
0

10

Handoff Rate (# per 10minute)

Figure 5.30: Packet Loss in UMTS/802.11b Integrated Networks (Downlink): SIM-N2P -D2 (95% Condence Interval) Figure 5.30 shows that the number of packet loss of MIP+SCTP and MIP+TCP increases proportional to hando rate while that of mSCTP does not increase and main-

97 tain zero. First, the number of packet loss in MIP+TCP increases quite linearly showing a little uctuation with the highest value of 7.968 in 10-hando scenario. Second, the number of packet loss of MIP+SCTP also has a little uctuation increasing up to 8.219 at 10-hando scenario. Finally, mSCTP maintains zero packet loss irrespective of hando rate. This is the result from the fact that the multi-homing of SCTP and DAR procedure makes no hando delay (see Subsection 4.3.2). As we have seen in Figure 5.28, the hando delay of MIP+TCP and MIP+SCTP shows identical relationship with the packet loss. That is, the number of packet loss in MIP+TCP and MIP+SCTP is directly aected by the total hando delay periods.

4. Remark In this subsection, we have discussed the downlink (CN to MN) behaviors of three hando protocol stacks in UMTS/802.11b integrated networks. From Figures 5.28 and 5.29, it should be noticed that MIP+SCTP produces higher throughput than MIP+TCP while total hando delay of MIP+SCTP is larger than that of MIP+TCP in certain hando rate ranges. As discussed in the uplink case, it is contradictory to our expectation. For instance, in the 4-hando rate case in Figure 5.28, the dierence of total hando delay between MIP+TCP and MIP+SCTP is about 32.8%. MIP+TCP shows even better performance in terms of hando delay in this case. However, the throughput dierence between MIP+TCP and MIP+SCTP in the 4-hando rate case in Figure 5.29 shows MIP+SCTP has 8.4% throughput improvement over MIP+TCP. This implies that SCTP protocol is a more proper transport layer protocol than TCP in mobile wireless environments. Thus, mSCTP, inherently adopting SCTP as a transport protocol, can perform more ecient data transmissions than any MIP approach at the moment.

In this chapter, we presented our simulation system model and evaluated the performance of MIP hando and mSCTP hando based on the result of the simulation. mSCTP hando, having no signicant delay and packet loss, produces the highest and consistent end-to-end throughput regardless of hando rate.

98

5.5

Further Discussion
In this section, we discuss two major issues that have been addressed during the

defense of the thesis. These issues reminded us of important facts that we experienced during the thesis work but could not draw a substantial attention at that moment.

5.5.1

Randomness in the Simulation


During the design phase of the simulation, we avoided random factors in the

simulation system model. However, some of the simulation scenarios generated quite large condence intervals, especially when hando rate went high. These phenomena have been observed in both 802.11b WLAN-only network and UMTS/802.11b integrated networks. Hence, we investigated the related NS-2 modules to nd the origin of randomness. A function in our tcl scripts, ns-random, takes a seed number as a parameter from our command line input. Based on the given seed, NS-2 random number generator (RNG) generates a stream of number vectors. The stream of number vectors are used in many parts of simulations, and among them, the most closely related eects in our simulation are as follows: MIP related factors In MIP registration module, the interval of beacon message

is determined based on the generated random sequence of numbers. This random beacon period is generated from both base station (BS) and mobile node (MN) based on the sequence. (Refer to the following NS-2 codes for more details [2]). ######################################################### # $NS-2-HOME/ns-allinone-2.26/ns-2.26/mobile/mip-reg.cc # ######################################################### int MIPBSAgent::command(int argc, const char*const* argv) { ... timer_.resched(Random::uniform(0, beacon_)); ... } int MIPMHAgent::command(int argc, const char*const* argv)

99 { ... rtx_timer_.resched(Random::uniform(0, beacon_)); ... } TCP related factors The generated random sequence of numbers is used to

schedule the packet timer of TCP agent. Also, time-to-live (TTL) value of a TCP packet is determined by the random sequence. (Refer to the following NS-2 codes for more details [2]). ################################################## # $NS-2-HOME/ns-allinone-2.26/ns-2.26/tcp/tcp.cc # ################################################## void TcpAgent::send_much(int force, int reason, int maxburst) { ... delsnd_timer_.resched(Random::uniform(overhead_)); ... } void TcpAgent::output(int seqno, int reason) { ... qsh->ttl() = Random::integer(256); ... } SCTP related factors Based on the generated random sequence of numbers,

SCTP module obtains exponentially distributed SCTP packet inter-arrival time. SCTP module also uses the random sequence to calculate the next heartbeat (See Table 2.1 in Subsection 2.2.1) packet interval. (Refer to the following NS-2 codes for more details [2]). ######################################################### # $NS-2-HOME/ns-allinone-2.26/ns-2.26/apps/sctp_app1.cc # ######################################################### double SctpApp1::next() {

100 ... return Random::exponential() * interval_; ... } #################################################### # $NS-2-HOME/ns-allinone-2.26/ns-2.26/sctp/sctp.cc # #################################################### double SctpAgent::CalcHeartbeatTime(double dRto) { ... dRetVal += (int(Random::uniform()) % uiHeartbeatInterval); ... } Wireless physical modulation The generated sequence vectors are used to de-

termine the scalability of bit error probability for wireless modulation. (Refer to the following NS-2 codes for more details [2]). ############################################################ # $NS-2-HOME/ns-allinone-2.26/ns-2.26/mobile/modulation.cc # ############################################################ BPSK::BitError(double Pr) { ... x = (double)(((int)Random::uniform()) % 1000); ... } Since NS-2 is a discrete event-based simulator, it assigns each of the above events in an event-list structure, and the main scheduler dispatches each event from the list structure and executes it. In this way, the sequences of these events generate randomness in the simulation.

5.5.2

Impact of Hando Rate in the Simulation


Throughout the simulation study, hando rate has been adopted as an impor-

tant variable to evaluate the dierent hando protocols with regard to dierent scale of mobility.

101 Although the accumulation of hando delays is supposed to be identical to the total hando delay generated by corresponding hando rate, the simulation results showed that the relationship between the two values is not perfectly linear. This observation can be attributed to the fact that the actual performance degradation of hando protocols in dierent scale of mobility comes from various reasons including node movement, possible randomness from underlying network components as discussed in Subsection 5.5.1, and so on. Thus, our performance evaluation approach with hando rate can be considered to be at least more approximate to prospective experimental results than that of linear accumulation approach.

102

Chapter 6

Conclusion and Future Work


Throughout the thesis, we discussed two dierent hando protocols, Mobile IP (MIP) and mobile SCTP (mSCTP). MIP incurs unavoidable hando delay ascribed to agent discovery and registration procedure (see Subsection 2.1.1) while mSCTP provides a quasi-seamless hando based on its multi-homing feature and dynamic address reconguration (DAR) extension [34] (see Subsection 2.2.2). In this chapter, we conclude the performance evaluation of MIP and mSCTP hando, and discuss future works.

6.1

Conclusion
Future wireless IP networks requires seamless IP-based hando solutions for

ubiquitous users. Many network layer IP-based hando solutions have already been proposed, and especially Mobile IP (MIP) has been standardized to be deployed in many networks. However, due to its inherent network layer mechanisms, MIP hando cannot avoid signicant delay which aects end-to-end throughput and transport layer transmission behaviors. MIP hando performance is acceptable to nomadic users, but future wireless IP convergent networks require quasi-seamless IP-based hando solutions, which can support highly mobile-oriented computing environment utilizing heterogeneous networks. mobile SCTP (mSCTP), a transport layer approach, has several advantages

103 over MIP based on multi-homing feature of Stream Control Transmission Protocol (SCTP) [35] and dynamic address reconguration (DAR) extension [34]. Based on those new protocol features, mSCTP hando supports non-delayed IP-based hando without packet loss. Hence, in this thesis, we conducted an analysis of MIP and mSCTP with regard to hando delay, end-to-end throughput, and packet loss, followed by the corresponding NS-2 simulation. In the analysis of MIP and mSCTP hando, hando delay, end-to-end throughput, packet loss have been introduced as performance parameters. We discussed each step of MIP and mSCTP operation to analyze their hando delay. MIP hando includes agent discovery and registration period during which end-to-end transmission cannot be processed properly. On the other hand, mSCTP hando delay can be neglected since it exploits multi-homing and DAR procedure. It should be noted that total hando delay of MIP increases as hando rate increases while that of mSCTP is kept being zero. End-to-end throughput has been analyzed by introducing a parameter, hando rate. End-to-end throughput of MIP decreases directly proportional to hando rate and hando delay product while mSCTP throughput is maintained constant without any signicant data loss irrespective of hando rate. We also showed that MIP hando incurs certain packet loss according to its hando delay. mSCTP, on the other hand, does not incur any packet loss during its hando period. Since packet loss can aect the behavior of transport layer trac, mSCTP hando provides much more reliable transmission than MIP, especially when hando rate becomes high. Using NS-2 network simulator, we designed a system model to simulate the analyzed performance parameters for MIP and mSCTP hando in 802.11b WLAN-only network and UMTS/802.11b integrated networks. The simulation results supported our analysis by showing the analyzed relationship between MIP and mSCTP hando for each of performance parameter. In UMTS/802.11b architecture, end-to-end throughput of MIP hando did not decrease as much as that of in 802.11b WLAN-only network because of the advantage of network integration. However, mSCTP still showed higher throughput based on zero hando delay. Throughout the thesis, we employed hando rate as a variable to evaluate the performance of MIP and mSCTP hando. Hence, our result supports how MIP and mSCTP hando react when hando rate increases. To conclude, mSCTP hand-

104 o provides quasi-seamless IP-based hando regardless of increase of hando rate in both homogeneous and heterogeneous network environments. As a promising IP-based hando solution in future wireless IP convergent networks, mSCTP should have more attention in both academic and industry research society.

6.2

Future Work
Throughout the thesis work, we have concentrated on the performance evalu-

ation of hando protocols. During the course of the work, we narrowed down the topic of our research based on quite a few assumptions. Thus, we have come up with several encouraged suggestions from our work. Now, we share the open issues as future work. In the thesis, we concentrated on the performance evaluation of hando. Meanwhile, as we introduced in Section 1.2, location management of a mobile node (MN) is another major topic of IP mobility. A few previous works have already proposed location management schemes for mSCTP protocol. For instance, [17] proposed a location management method using DNS service. However, it is still an open issue to build a exible and scalable location management scheme for mSCTP such that the hando protocol can be exploited. Also, a method to interact with AAA architecture is required to be applied in real service networks. AAA architecture might give an additional complexity that aects the performance of hando protocols. Hence, the adaptation of hando protocols into existing AAA architecture is an important issue. Throughout the thesis, we focused on network layer and transport layer hando approaches. However, an interaction between link layer protocol and network layer and/or transport layer hando protocols can assist the decision of hando timing for more stable and reliable mobility management. In academic research, it is not easy to conduct an experimental research on some infrastructure networks such as 3G networks. Especially, network convergence and vertical hando topic is quite dicult to setup an experimental environment. That is one of the reasons we chose the simulation study. During our NS-2 simulation study, we made certain assumptions since NS-2 does not oer any standardized modules to simulate cellular networks. Several contributed modules were found during the research,

105 but could not be used in our simulation due to the reasons we mentioned in item 4. UMTS Module in Subsection 5.1.2. Hence, we leave a further simulation and a real experimental study as future work.

106

Bibliography
[1] The network simulator - ns-2: http://www.isi.edu/nsnam/ns. [2] Ns-2 network simulator release all-in-one 2.26: http://www.isi.edu/nsnam/dist/nsallinone-2.26.tar.gz. [3] Monarch project: Wireless and mobility extensions to ns-2:

http://www.monarch.cs.cmu.edu/cmu-ns.html, 2000. [4] Eurane (enhanced umts radio access network extensions) for ns-2: http://www.tiwmc.nl/eurane/, 2005. [5] Ns-2 sctp module: http://pel.cis.udel.edu, 2005. [6] Ian F. Akyildiz, Janise Mcnair, Joseph S. M. HO, Huseyin Uzunalioglu, and Wenye Wang. Mobility Management for Next Generation Wireless systems. In Proceedings of The IEEE, volume 87, pages 13471384, August 1999. [7] Ian F. Akyildiz, Jiang Xie, and Shantidev Mohanty. A survey of mobility management in next-generation all-ip-based wireless systems. IEEE Wireless Communications, 11(4):1628, August 2004. [8] Ilknur Aydin, Woojin Seok, and Chien-Chung Shen. Cellular SCTP: A TransportLayer Approach to Internet Mobility. In Proceedings of Computer Communications and Networks, 2003. ICCCN 2003., pages 285290, October 2003. [9] Waheed Uz Zaman Bajwa, Syed Aan Ahmed, Adeel Abbas, Sameer Zulqar, and Amir Qayyum. Mobile IP Based Mobility Management For 3G Wireless Networks.

107 In Proceedings of Students Conference, 2002. ISCON 2002., volume 2, pages 1010, August 2002. [10] Jerey Bannister, Paul Mather, and Sebastian Coope. Convergence technologies for 3g networks: Ip, umts, egprs and atm. Wiley, 2004. [11] M. Buddhikot, G. Chandranmenon, S. Han, Y. W. Lee, S. Miller, and L. Salgarelli. Integration of 802.11 and Third-Generation Wireless Data Networks. In Proceedings of IEEE Infocom 2003., volume 1, pages 503512, March 2003. [12] Milind M. Buddhikot, Girish Chandranmenon, SeungJae Han, Yui-Wah Lee, Scott Miller, and Luca Salgarelli. Design and implementation of a wlan/cdma2000 interworking architecture. [13] A. T. Campbell, J. Gomez, S. Kim, A. G. Valko, Chieh-Yih Wan, and Z. R. Turanyi. Design, implementation, and evaluation of cellular ip. IEEE Personal Communications, 7(4):4249, August 2000. [14] S. Deering. Icmp router discovery messages:

http://www.ietf.org/rfc/rfc1256.txt?number=1256, 1991. [15] Shaojian Fu and Mohammed Atiquzzaman. Improving End-to-End Throughput of Mobile IP using SCTP. In Proceedings of High Performance Switching and Routing, 2003, pages 171176, June 2003. [16] Shaojian Fu and Mohammed Atiquzzaman. Sctp: State of the art in research, products, and technical challenges. IEEE Communications Magazine, 42(4):6476, April 2004. [17] ShaoJian Fu, Mohammed Atiquzzaman, Liran Ma, William Ivancic, Yong-Jin Lee, Jstin S. Jones, and Song Lu. TraSH: A Transport Layer Seamless Handover for Mobile Networks. Technical Report Technical Report, Univ. of OKlahoma, November 2003. [18] Eva Gustafsson, Annika Jonsson, and Charles E. Perkins. Mobile ipv4 regional registration: http://www.ietf.org/proceedings/04aug/i-d/draft-ietf-mobileip-reg-

tunnel-09.txt, 2004.

108 [19] Robert Hsieh, Zhe Guang Zhou, and Aruna Seneviratne. S-MIP: A Seamless Hando Architecture for Mobile IP. In Proceedings of IEEE Infocom 2003., volume 3, pages 17741784, March 2003. [20] Heikki Kaaranen, Ari Ahtiainen, Lauri Laitinen, Siamak Naghian, and Valtteri Niemi. Umts networks: Architecture, mobility and services. Wiley, 2001. [21] Seok Joo Koh, Moon Jeong Chang, and Meejeong Lee. msctp for soft handover in transport layer. IEEE Communications Letters, 8(3):189191, March 2004. [22] Seok Joo Koh, Hee Young Jung, and Jae Hong Min. Transport Layer Internet Mobility based on mSCTP. In Proceedings of Advanced Communication Technology, 2004, volume 1, pages 329333, 2004. [23] Li Ma, Fei Yu, Victor C. M. Leung, and Tejinder Randhawa. A New Method To Support UMTS/WLAN Vertical Handover Using SCTP. IEEE Wireless Communications, 11(4):4451, August 2004. [24] Pablo Martin and Paula Ballester. Umts extensions for nework simulator, ns-2: http://www.geocities.com/opahostil/, 2005. [25] Pawel Matusz, Przemyslaw Machan, and Jozef Wozniak. Analysis of Protability of Inter-system Handovers between IEEE 802.11b and UMTS. In Proceedings of IEEE LCN 2003, pages 210217, October 2003. [26] A. Misra, S. Das, A. Dutta, A. McAuley, and S. K. Das. Idmp-based fast handos and paging in ip-based 4g mobile networks. IEEE Communications Magazine, 40(3):138145, March 2002. [27] James Noonan, Philip Perry, and John Murphy. A Study of SCTP Services in a Mobile-IP Network. In Proceedings of ITT Conference, volume 1, October 2002. [28] C. Perkins. Ip mobility support: http://www.ietf.org/rfc/rfc2002.txt?number=2002, 1996. [29] Charles Perkins and David B. Johnson. Route optimization in mobile ip: http://klug.org/ griswold/drafts-rfcs/draft-ietf-mobileip-optim-11.txt, 2001.

109 [30] R. Ramjee, K. Varadhan, L. Salgarelli, S. R. Thuel, Shie-Yuan Wang, and T. La Porta. Hawaii: A domain-based approach for supporting mobility in wide-area wireless networks. IEEE/ACM Transactions on Networking, 10(3):396410, June 2002. [31] Clint Smith and John Meyer. 3g wireless with wimax and wi-. McGraw-Hill, 2005. [32] Hesham Soliman. Mobile ipv6: Mobility in a wireless internet. Addison Wesley, 2004. [33] Hesham Bellier. Soliman, Claude Catelluccia, mobile ipv6 Karim mobility El Malki, and Ludovic (hmipv6):

Hierarchical

management

http://www.ietf.org/proceedings/04aug/i-d/draft-ietf-mipshop-hmipv6-02.txt, 2004. [34] R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, and P. Conrad. control transmission protocol (sctp) dynamic address Stream

reconguration:

http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-addip-sctp-11.txt, 2005. [35] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and V. Paxson. Stream control transmission protocol: http://www.ietf.org/rfc/rfc2960.txt?number=2960, 2000. [36] Randall Stewart and Chris Metz. Sctp: New transport protocol for tcp/ip. IEEE Internet Computing, 5(6):6469, November 2001. [37] Randall R. Stewart and Qiaobing Xie. Stream control transmission protocol (sctp): A reference guide. Addison Wesley, 2002.

110

Appendix A

NS-2 Simulation
In Appendix A, we describe core parts of our simulation implementation. As discussed in Section 5.2, we describe our simulation implementation in four parts: network architecture, protocol stacks, hando rate, and trac.

A.1
A.1.1

Network Architectures
Network Architecture-1: 802.11b WLAN-Only Network
The following code is a part of our TCL scripts to set up the 802.11b network

environment for our simulation. ################################################# # 802.11b WLAN # ################################################# #---------------------------------------------------------$ns_ node-config -adhocRouting DSDV \ -llType LL \ -macType Mac/802_11 \ -ifqType Queue/DropTail/PriQueue \ -ifqLen 50 \ -antType Antenna/OmniAntenna \ -propType Propagation/TwoRayGround \ -phyType Phy/WirelessPhy \

111 -channelType Channel/WirelessChannel \ Mac/802_11 set dataRate_ 11.0Mb # 802.11b data rate #---------------------------------------------------------As a wired/wireless routing protocol, DSDV has been used. It should be noted that NS-2 wirless modules use Ad hoc routing protocol to route packets between wireless topology and wired topology. 11 Mbps data rate has been used to simulate a 802.11b network.

A.1.2

Network Architecture-2: UMTS/802.11b Integrated Networks


The following code is a part of our TCL scripts to set up a UMTS network

environment in our simulation. ################################################# # UMTS # ################################################# #-------------------------------------------------------------$ns_ node-config -adhocRouting DSDV \ -llType LL \ -macType Mac/802_11 \ -ifqType Queue/DropTail/PriQueue \ -ifqLen 50 \ -antType Antenna/OmniAntenna \ -propType Propagation/TwoRayGround \ -phyType Phy/WirelessPhy \ -channelType Channel/WirelessChannel \ Mac/802_11 set dataRate_ 2.0Mb # UMTS data rate Phy/WirelessPhy set Pt_ 4.5099 # UMTS coverage: r=500m Phy/WirelessPhy set freq_ 2.175e9=20 # UMTS radio frequency #-------------------------------------------------------------Because of the reasons discussed in item 4. UMTS Module in Subsection 5.1.2, we used NS-2 Mac/802 11 MAC module with modied settings. Maximum data rate of 2 Mbps has been used to simulate UMTS network. Also, the transmission power and radio frequency have been changed to 4.5099 and 2.175 GHz, respectively.

112

A.2
A.2.1

Protocol Stacks
MIP+TCP
The following code is a part of our TCL scripts for MIP+TCP settings.

################################################# # MIP+TCP # ################################################# #-------------------------------$ns_ node-config -mobileIP ON # TCP connection set tcp1 [new Agent/TCP] set sink1 [new Agent/TCPSink] $ns_ attach-agent $MN $tcp1 $ns_ attach-agent $CN $sink1 $ns_ connect $tcp1 $sink1 #-------------------------------NS-2 MIP implementation is activated for mobile nodes and base station (agent) nodes. The above code example shows MN-to-CN trac. The default TCP packet size, 1040byte, has been used.

A.2.2

MIP+SCTP
The following code is a part of our TCL scripts for MIP+SCTP settings for

MN-to-CN trac. ################################################# # MIP+SCTP # ################################################# #-------------------------------$ns_ node-config -mobileIP ON # SCTP connection (association) set sctp1 [new Agent/SCTP] $sctp1 set mtu_ 1040 $sctp1 set dataChunkSize_ 1008 set sink1 [new Agent/SCTP]

113 $ns_ attach-agent $MN $sctp1 $ns_ attach-agent $CN $sink1 $ns_ connect $sctp1 $sink1 #-------------------------------NS-2 MIP implementation is activated for mobile nodes and base station (agent) nodes. The SCTP packet size has been modied to 1040-byte for fair comparison with that of TCP.

A.2.3

mSCTP
The following code is a part of our TCL scripts for mSCTP settings for MN-

to-CN trac. ################################################# # mSCTP # ################################################# #-----------------------------------------------# SCTP connection (association) set sctp1 [new Agent/SCTP] $sctp1 set mtu_ 1040 $sctp1 set dataChunkSize_ 1008 $ns_ multihome-attach-agent $node_(0) $sctp1 set sink1 [new Agent/SCTP] $ns_ attach-agent $CN $sink1 $ns_ connect $sctp1 $sink1 # mSCTP DAR procedure # if MN-to-CN transmission $sctp1 force-source $node_(1) # if CN-to-MN transmission use the following code # $sctp1 set-primary-destination $node_(1) #-----------------------------------------------NS-2 MIP implementation has not been activated in this protocol stack. The SCTP packet size has been modied to 1040-byte for fair comparison with MIP protocol stacks which used a 1040-byte packet size. The following code is DAR procedure triggered during hando in MN-to-CN trac.

#################################################

114 # mSCTP: MN-to-CN DAR procedure # ################################################# #---------------------------------------------------------------if { $delta == "0" } { } else { for {set i 1} {$i < $delta+1} {incr i} { if { $i%2 == 1 } { $ns_ at [expr (($i*(($opt(ftp-stop)-30)/($delta+1)))+40)] \ "$sctp1 force-source $node_(2)" } else { $ns_ at [expr (($i*(($opt(ftp-stop)-30)/($delta+1)))+40)] \ "$sctp1 force-source $node_(1)" } } } #---------------------------------------------------------------fource-source method of NS-2 SCTP module has been used. The DAR procedure in CN-to-MN trac has been written as follows:

################################################# # mSCTP: CN-to-MN DAR procedure # ################################################# #---------------------------------------------------------------if { $delta == "0" } { } else { for {set i 1} {$i < $delta+1} {incr i} { if { $i%2 == 1 } { $ns_ at [expr (($i*(($opt(ftp-stop)-30)/($delta+1)))+40)] \ "$sctp1 set-primary-destination $node_(2)" } else { $ns_ at [expr (($i*(($opt(ftp-stop)-30)/($delta+1)))+40)] \ "$sctp1 set-primary-destination $node_(1)" } } } #---------------------------------------------------------------set-primary-destination method of NS-2 SCTP module has been used.

115

A.3
A.3.1

Hando Rate and MN movement


802.11b WLAN-Only Network

################################################### # Handoff Rate and MN movement: 802.11b WLAN-Only # ################################################### #-------------------------------------------------------------------# MN movement generation set delta [lindex $argv 0] if { $delta == "0" } { } else { for {set i 1} {$i < $delta+1} {incr i} { if { $i%2 == 1 } { $ns_ at [expr (($i*(($opt(ftp-stop)-30)/($delta+1)))+30)] \ "$MN setdest 250.000000000000 250.000000000000 10.000000000000" } else { $ns_ at [expr (($i*(($opt(ftp-stop)-30)/($delta+1)))+30)] \ "$MN setdest 100.000000000000 100.000000000000 10.000000000000" } } } #-------------------------------------------------------------------The MN in 802.11b WLAN-only network is initially located in the coordination of (100, 100) as shown in Figure 5.13 in Subsection 5.2.4. According to the value of the variable, $delta, the MN moves between the points (100, 100) and (250, 250).

A.3.2

UMTS/802.11b Integrated Networks

################################################### # Handoff Rate and MN movement: UMTS/802.11b # ################################################### #-------------------------------------------------------------------# MN movement generation set delta [lindex $argv 0] if { $delta == "0" } { } else { for {set i 1} {$i < $delta+1} {incr i} {

116 if { $i%2 == 1 } { $ns_ at [expr (($i*(($opt(ftp-stop)-30)/($delta+1)))+30)] \ "$MN setdest 100.000000000000 100.000000000000 10.000000000000" } else { $ns_ at [expr (($i*(($opt(ftp-stop)-30)/($delta+1)))+30)] \ "$MN setdest 250.000000000000 250.000000000000 10.000000000000" } } } #-------------------------------------------------------------------The MN in UMTS/802.11b integrated networks is initially located in the coordination of (250, 250) as shown in Figure 5.14 in Subsection 5.2.4. According to the value of the variable, $delta, the MN moves between the points (250, 250) and (100, 100).

A.4

Trac

################################################# # FTP Traffic # ################################################# #--------------------------------------------------------------------set ftp1 [new Application/FTP] $ftp1 attach-agent $tcp1 # $sctp1 is used in MIP+SCTP and mSCTP $ns_ at $opt(ftp-start) "$ftp1 start" $ns_ at $opt(ftp-stop).0001 "stop" #--------------------------------------------------------------------For all the scenarios, the same FTP trac has been used for application layer trac.

117

Appendix B

FAQs
B.1 How has NS-2 SCTP module been used in wireless topology?
While building a scenario using NS-2 SCTP module [5] together with existing NS-2 wireless modules, a coniction has been found. Wired-wireless infrastructure network in NS-2 requires a special routing scheme, called hierarchical routing, but NS-2 SCTP came with an error with the hierarchical routing implementation. Hence, we made a modication in our TCL script and NS-2 routing module to avoid the problem. The following is the error we met during our work. ----------------------------------------------cant read "Node_(4)": no such element in array while executing "return $Node_($id)" (procedure "_o3" line 3) (Simulator get-node-by-id line 3) invoked from within "$self get-node-by-id [lindex $L 0" (procedure "_o3" line 14) (Simulator compute-hier-routes line 14) invoked from within "$self compute-hier-routes "

118 (procedure "_o3" line 3) (Simulator compute-routes line 3) invoked from within "[Simulator instance] compute-routes" (procedure "Agent/rtProto/Static" line 2) (Agent/rtProto/Static init-all line 2) invoked from within "Agent/rtProto/Static init-all" (procedure "_o232" line 8) (RouteLogic configure line 8) invoked from within "[$self get-routelogic] configure" (procedure "_o3" line 5) (Simulator run line 5) invoked from within "$ns_ run " (file "./tcl/sim-131.tcl" line 205) ----------------------------------------------To resolve the problem, we set wiredRouting option in node conguration to OFF, which is usually set to ON for regular wireless nodes. #$ns_ node-config -wiredRouting OFF After that modication, we encountered another error like the following: --- Classfier::no-slot{} default handler (tcl/lib/ns-lib.tcl) --_o82: no target for slot 0 _o82 type: Classifier/Hier content dump: classifier _o82 0 offset 0 shift 2147483647 mask 0 slots ---------- Finished standard no-slot{} default handler ---------In order to solve the problem, we referred to the following part of a core module in NS-2 which has been provided by University of California. ################################################################ # $NS-2-HOME/ns-allinone-2.26/ns-2.26/classifier/classifier.cc # ################################################################

119

NsObject* Classifier::find(Packet* p) { ... //Tcl::instance().evalf("\%s no-slot \%ld", name(), cl); ... } As shown in the above code, we commented out the line to avoid the problem. This modication has been tested in NS-2 all-in-one 2.26 version.

B.2

How many simulations did you run for each scenario?


For 802.11b WLAN-only network architecture, rst we tried 32 runs for each

scenario. However, 60 runnings gave us smoother results at last. For UMTS/802.11b integrated networks, a set of the entire simulation, with 32 runs for each scenario, has taken more than a week running time such that we could not recongure the simulation settings as quickly as required. Hence, we maintained 32 runs for each scenario in this network architecture.

Das könnte Ihnen auch gefallen