UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

A new method to support UMTS/WLAN integrating using stream control transmission protocol Ma, Li 2004

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
831-ubc_2004-0265.pdf [ 5.05MB ]
Metadata
JSON: 831-1.0064942.json
JSON-LD: 831-1.0064942-ld.json
RDF/XML (Pretty): 831-1.0064942-rdf.xml
RDF/JSON: 831-1.0064942-rdf.json
Turtle: 831-1.0064942-turtle.txt
N-Triples: 831-1.0064942-rdf-ntriples.txt
Original Record: 831-1.0064942-source.json
Full Text
831-1.0064942-fulltext.txt
Citation
831-1.0064942.ris

Full Text

A New Method to Support UMTS/WLAN Integration Using Stream Control Transmission Protocol by L I M A . B.Eng, Beijing University of Aeronautics and Astronautics, China, 1991 A THESIS SUBMITTED IN PARTIAL F U L F I L M E N T OF THE REQUIREMENTS FOR THE D E G R E E OF M A S T E R OF APPLIED SCIENCE In THE F A C U L T Y OF G R A D U A T E STUDIES Department of Electrical and Computer Engineering We accept this thesis as conforming to the required standard THE UNIVERISTY OF BRITISH C O L U M B I A March 2004 © L i Ma, 2004 Library Authorization In presenting this thesis in partial fulfillment of the requirements for an advanced degree at the University of British Columbia, I agree that the Library shall make it freely available for reference and study. I further agree that permission for extensive copying of this thesis for scholarly purposes may be granted by the head of my department or by his or her representatives. It Is understood that copying or publication of this thesis for financial gain shall not be allowed without my written permission. i • t ob i Name of Author (please print) Date (dd/mm/yyyy) Title of Thesis: J\ hj^j Metkod *tb Support UhATZ / WLAj\l  ptrioce i '. Degree: M-A-Sc Year: Qpb 4-Department of Ve.c£vlco{,{ Cç^nJttr &Nj^<n e^vl\^ The University of British Columbia Vancouver, BC Canada Abstract Third generation (3G) wide area wireless networks and wireless local area networks (WLANs) possess complementary characteristics. The performance and flexibility of wireless services would be dramatically improved if users could seamlessly roam across these two types of networks. In recent years, Stream Control Transmission Protocol (SCTP) developed by the Internet Engineering Task Force (IETF) has gained significant popularity in the studying of next generation IP networks. SCTP has also been selected as a standard signaling protocol for service control in 3G wireless network. Its multi-streaming, multi-homing and partial reliable (PR) data transferring features are especially attractive for applications that have stringent performance and high reliability requirements. In this research, we propose a new method to facilitate seamless vertical handovers (VHOs) between 3G Universal Mobile Telecommunication System (UMTS) cellular networks and WLANs using SCTP. The multi-homing capability and dynamic address reconfiguration (DAR) extension of SCTP are applied in the U M T S / W L A N overlay architecture to decrease the VHO delay and improve the throughput performance. We develop the U M T S / W L A N bi-directional V H O procedures and study the different scenarios employing a single-homing and a dual-homing fixed server configurations to support the VHO. We compare the performance of these two possible configurations using the ns-2 simulation tool and recommend the better one for our further study. Unlike mobility solutions of network or application layer, SCTP-based vertical handover does not require additional components to be added into the existing networks. Therefore, the proposed scheme provides a network independent solution that is preferred by service providers. In addition, we propose a new scheme that we call Sending-buffer Multicast with Fast Retransmission (SMART-FRX) to allow the sender to enter into the slow start process when handover loss (FEL) occurs in the W L A N link, and retransmit the error loss (EL) caused by multi-path fading over the wireless channel to the same destination IP address. According to the current SCTP link failure detection and recovery process as described in the specification, during a link failure detection period, timeouts and backoffs on the primary link may result in the poor throughput of the whole system. The proposed S M A R T - F R X scheme multicasts the buffered and new data on both UMTS and W L A N links to subdue the effect of handover loss (HL), and avoid unnecessary long delays of retransmitting lost packets due to UMTS transmission errors over the alternate possibly unreachable W L A N destination address. Consequently, the throughput performance is increased significantly. Moreover, we develop a new analytical model to study the SCTP performance during the VHO. By comparing numerical results for the analytical model with simulation results, we demonstrate that our model is able to accurately predict SCTP throughput. The analytical model provides a useful tool to estimate the SCTP throughput performance. Abstract ii List of Tables vii List of Figures viii Acknowledgements x Chapter 1 Introduction 1 1.1 U M T S / W L A N Vertical Handover 1 1.2 Motivations 2 1.3 Contributions 4 1.4 Organization of Thesis 7 Chapter 2 Literature Review 8 2.1 U M T S / W L A N Integration 8 2.1.1 Overview 8 2.1.2 Related Work on U M T S / W L A N Integration 11 2.2 Related Work on Multi-homing and Transport Layer Protocol Supporting Mobility 12 2.2.1 Location Independent Network for IPv6 (LIN6) 13 2.2.2 Host Identity Protocol (HIP) 14 2.2.3 Current Transport Layer Protocol Supporting Mobility., 16 2.3 SCTP and MSCTP 17 2.3.1 SCTP Overview 17 2.3.2 Mobile SCTP (MSCTP) 22 2.4 A Summary of Related Work 26 Chapter 3 UMTS/WLAN Unforced VHO 29 3.1 System Architecture 29 3.2 Unforced VHO Procedure 31 3.2.1 Abstract Address-handling Model Description 32 3.2.2 The Proposed VHO Scheme and Procedures 35 3.2.3 Comparison of Single-homing and Dual-homing Configurations ... 40 Chapter 4 WLAN to UMTS Forced VHO 43 4.1 Problem Descriptions 43 4.1.1 Transport Layer Protocol in the Wireless Network 43 4.1.2 Data Transmission Subject to H L 45 4.1.3 Data Transmissions Subject to E L 48 4.2 The Proposed Scheme 49 4.2.1 The S M A R T Sub-scheme 50 4.2.2 The F R X Sub-scheme 53 4.3 The Proposed Analytical Model 54 4.3.1 Modeling Data Transmission Subject to H L on the W L A N Link ... 56 4.3.2 Modeling Data Transmission Subject to E L on the UMTS Link 58 Chapter 5 Simulation Results and Discussions 65 5.1 Simulation Methodology 65 5.1.1 Overview of Simulation Tools 66 5.1.2 The Simulation Model of U M T S / W L A N V H O Using MSCTP 68 5.1.3 Implementation of S M A R T - F R X 71 5.1.4 Validation of Analytical Model 74 5.2 Results and Discussions 75 5.2.1 U M T S / W L A N Unforced VHO 76 5.2.2 S M A R T - F R X Scheme 77 5.2.3 Comparison with Analytical Results 87 Chapter 6 Conclusions 94 Bibliography 97 Appendix A. Pseudo Code for the Analytical Model 100 Glossary of Acronyms 103 List of Tables Table 2-1 Complementary characteristics of the UMTS and W L A N technologies 9 Table 2-2 Comparison between SCTP, TCP and UDP [29] 19 Table 2-3 Summary of protocols supporting handover 27 Table 5-1 Features included in existing ns-2 SCTP module [39] 67 List of Figures Fig. 2-1 Generalized architecture for U M T S / W L A N integration 10 Fig. 2-2 LIN6 multi-homing supporting of handover 14 Fig. 2-3 SCTP in the IP reference model 18 Fig. 2-4 SCTP with multi-homing configuration 20 Fig. 2-5 SCTP packet format 21 Fig. 2-6 SCTP support of seamless handovers 24 Fig. 3-1 Architecture of U M T S / W L A N integration using MSCTP 30 Fig. 3-2 Simplified architecture of dual-homing configuration 33 Fig. 3-3 Three basic steps in V H O procedure 35 Fig. 3-4 V H O procedure (FS is in the single-homing configuration) 37 Fig. 3-5 VHO procedure (FS is in the dual-homing configuration) 39 Fig. 3-6 An asymmetric SCTP association 41 Fig. 4-1 Three types of packet loss affecting SCTP in mobile network 44 Fig. 4-2 SCTP transmissions when the W L A N link is in possibly unreachable period47 Fig. 4-3 SCTP transmissions when the W L A N link is in failure 47 Fig. 4-4 Data transmissions before application of the S M A R T scheme 51 Fig. 4-5 Data transmissions with application of the S M A R T scheme 52 Fig. 4-6 Transitions of cwnd size and error counter subject to H L 56 Fig. 4-7 The relation between the error counter n and Trto 57 Fig. 4-8 Transitions of cwnd size and probability subject to E L 60 Fig. 4-9 Combine the nodes with the same cwnd in the same round 64 Fig. 5-1 MSCTP-based V H O configurations 68 Fig. 5-2 M C and FS interaction with ASCONF and A S C O N F _ A C K chunks 70 Fig. 5-3 Implementation architecture of SCTP 72 Fig. 5-4 S M A R T - F R X simulation configuration 74 Fig. 5-5 Delay performance of the proposed V H O scheme (from UMTS to W L A N ) . 78 Fig. 5-6 Delay performance of the proposed VHO scheme (from W L A N to UMTS). 79 Fig. 5-7 Throughput performance of the proposed vertical handover scheme 80 Fig. 5-8 Comparison with and without S M A R T - F R X (n = 3) 82 Fig. 5-9 Comparison with and without S M A R T - F R X (n = 4) 83 Fig. 5-10 Comparison with and without S M A R T - F R X (n = 5) 84 Fig. 5-11 Comparison with and without S M A R T - F R X (n = 6) 85 Fig. 5-12 Comparison of analysis and simulation results (without SMART-FRX) 89 Fig. 5-13 Comparison of the analysis and simulation results (with SMART-FRX) 89 Fig. 5-14 Throughput vs. packet loss rate of UMTS link (Delay = 0 ms) 90 Fig. 5-15 Throughput vs. packet loss rate of UMTS link (Delay = 50 ms) 90 Fig. 5-16 Throughput vs. packet loss rate of UMTS link (Delay = 120 ms) 91 Fig. 5-17 Throughput vs. packet loss rate of UMTS link (Delay = 150 ms) 91 Fig. 5-18 Throughput vs. packet loss rate of UMTS link (Delay = 250 ms) 92 Fig. 5-19 Throughput vs. packet loss rate of UMTS link (Delay = 400 ms) 92 Acknowledgements First and foremost, I would like to express my sincerest gratitude to my advisor Professor Victor Leung, without whose guidance, encouragement and support, it would have been impossible to bring my research work to its logical conclusion. Ffis motivation and drive are the primary reason for arousing my interest in this research. I would also thank him for giving me this unique opportunity to learn and enjoy working in this research. I would like to gratefully acknowledge the support of Telus Mobility, the Advanced Systems Institute of BC and the Canadian Natural Sciences and Engineering Research Council, who support this work under grant CRD247855-01. I would like to thank Professor Vikram Krishnamurthy and Professor Vincent Wong for serving on my thesis committee. Their comments have enhanced my research in innumerable ways. I want to express my deep appreciation to Dr. Fei Yu and Dr. Tejinder Randhawa for their insightful suggestions and precious time spending with me to discuss some topics related to this project. Their help motivated and inspired me in many ways. I would like to thank fellow students Chu Zhang and Kassim Olawale for their comments and suggestions on editing of the thesis. Their help, support and encouragement have certainly made this research work memorable. Finally, I would like to express my special thanks to my husband Henry for his encouragement, love and consistent support during my studies in U B C . Chapter 1 Introduction The third generation (3G) cellular networks, e.g., Universal Mobile Telecommunication System (UMTS) networks [1] provide wide area coverage at high mobility and support low to medium data rates. On the other hand, the IEEE 802.11 Wireless Local Area Networks (WLANs) [2] support higher speed data transmissions, but cover only small areas and support limited mobility. The complementary characteristics of UMTS networks and WLANs make it attractive to integrate these two technologies. In this chapter, we describe U M T S / W L A N vertical handover (VHO) in Section 1.1. Sections 1.2 to 1.4 present the motivations, contributions, and organization of the thesis, respectively. 1.1 UMTS/WLAN Vertical Handover One of the main issues in U M T S / W L A N integration is handover. A handover is a process that occurs when a terminal changes the base station through which it is communicating. There are two types of handovers, the horizontal handover (HHO) and the vertical handover (VHO) [3]. An HHO occurs when a mobile user moves between cells of the same type in terms of coverage, data rates and mobility management mechanisms, such as UMTS to UMTS, or W L A N to W L A N . A V H O occurs when a mobile user moves between cells of different types, such as UMTS to W L A N or vice versa. An efficient U M T S / W L A N handover scheme is crucial to the integration of these two technologies. The aim of supporting VHO between UMTS and W L A N is to realize real-time multiple network access over these two heterogeneous networks. This enables a user to utilize both W L A N and UMTS networks in parallel. The V H O allows the application services to be seamlessly transferred between different networks. To the end user, this means that devices that have the network access capability over both networks can migrate between the two networks without the need to reboot or restart the devices, and network applications can continue to run during migrations. The ability to use networks in parallel gives the user or service provider the possibility to choose the most economical connection at a specific location. 1.2 Motivations Existing solutions for mobility management supporting an integration of UMTS and W L A N networks include network layer Mobile IP (MIP) [4] and application layer, e.g. Session Initiation Protocol (SlP)-based techniques [5]. MIP uses a home agent (HA) and a foreign agent (FA) to bind the home address of a mobile host (MH) to a care-of-address at the visited network and provides mobility-transparent packet forwarding when the M H moves between IP subnets. However, MIP suffers from the problems of triangular routing, high handoff latencies and large overheads of tunneling IP packets. Compared with MIP, SIP-based mobility offers attractive benefits for multimedia applications. However, some inherent problems with this approach make the adoption of this scheme difficult [6]. For example, as an application layer solution, it is not likely to be able to overcome the handover latency caused by the lower layers. Thus, it requires the support of a lower layer mobility protocol, e.g., MIP. Another issue is the interoperability of SIP and MIP. The H A and F A registration processes serve the same purpose as the SIP REGISTRATION function. The joint deployment of SIP and MIP becomes problematic. As MIP and SIP-based approaches have some unappealing characteristics, such as limited performance and additional complexity for the network architecture, people have proposed to solve the mobility problem in the transport layer. The rationale of proposing transport layer mobility is that mobility is an end-to-end issue instead of network component or router issue. An end-to-end problem should be solved in the end systems according to the end-to-end principle [7]. Transport layer mobility leaves the network untouched and still allows roaming between networks. This makes the entire networking architecture simpler by working without additional entities added into the network infrastructure, and without new software states such as Mobile IP's tunnel states introduced into the network. Additionally, with mobility supported by the transport layer, flow and congestion control parameters in the transport layer can be easily and quickly adapted to the new network during and after a VHO. User Datagram Protocol (UDP) or Transmission Control Protocol (TCP) supports the most popular suite of applications on the Internet today. However, for a long time, the existing UDP and TCP have been found to be inappropriate to support rapidly changing requirements introduced by today's IP networks [8][9]. UDP cannot support reliable data transmissions. For TCP, any time an endpoint's IP address becomes inaccessible due to interface failure, radio channel interference, or an M H moving out of range of its base station, the TCP's connection will timeout, abort and result in a recovery process initiated by the application. This recovery overhead and session delay are usually quite high and are unacceptable in a mobile communication environment. The limitations of UDP and TCP have motivated the IETF to develop a third transport layer protocol, known as the Stream Control Transmission Protocol (SCTP) [10][11]. Designed with fault tolerance in mind, SCTP is a reliable network-friendly protocol that could co-exist with UDP and TCP in a network. In addition to standard TCP features, SCTP incorporates a number of enhanced features that make it suitable for transferring data over mobile networks and providing mobility support. Firstly, SCTP is the lowest layer to support end-to-end services, which agrees with the end-to-end principle. Secondly, compared with MIP- and SIP-based mobility, an SCTP-based mobility approach has the following advantages: • No third party other than the end-points participates in the handover. • It can support concurrent usage of any type of access routers. • Additional network components or modifications of intermediate routers are not required. 1.3 Contributions SCTP is a relatively new protocol. Recent research on SCTP over wireless networks mainly aims at exploiting SCTP's current capabilities, or designing new features that can make SCTP well suited for wireless channel characteristics. However, so far there are still no large-scale experimental results available to verify if the current SCTP standard meets the high reliability requirements of the mobility management. Our research in this thesis focuses on the study of SCTP supporting heterogeneous wireless networks integration. The main contributions of this thesis are as follows: • Using mobile SCTP (MSCTP) [12][13] to support UMTS/WLAN VHOs [14]: We propose a new method to support U M T S / W L A N VHOs using MSCTP. Though the latest work on SCTP-based mobility [12] [13] proposed a single-homing asymmetric and a dual-homing symmetric configurations to support MSCTP-based handovers, implementation details are lacking. Besides, the existing work on MSCTP is mainly concerned with supporting of general handover managements. To apply the MSCTP technology for seamless U M T S / W L A N VHOs, neither detailed descriptions nor prototype implementations have been presented in the literature. In this thesis, we clarify key concepts on the architecture and develop procedures for the V H O support. We develop an implementation of MSCTP using Network Simulator ns-2 [15][16]. In order to realize efficient U M T S / W L A N bi-directional V H O procedures, we propose to use SCTP bundling and unbundling message technologies to simplify the handover procedures. We perform tests to compare the two possible configurations, the single-homing and the dual-homing configurations, and then recommend the one that has the better delay and throughput performance for further study. • Sending-buffer Multicast with Fast Retransmission (SMART-FRX): A number of problems may arise from wireless communications during VHOs in a W L A N and UMTS overlay environment, one of which is the timeout and the retransmission caused by sudden long delays because of the mobile user moving out of the coverage of a W L A N . This results in SCTP backoffs and poor throughput performance. We show that two types of packet loss can dominate the SCTP performance during a W L A N to UMTS forced VHO. One is the consecutive packet dropping on the W L A N link because of the route disconnection during the VHO, so called handover loss (HL); the other one is the high error rate over the wireless channel due to multi-path fading when data are transmitted on the UMTS link, so called error loss (EL). To deal with these two types of packet losses, we propose the S M A R T - F R X scheme. S M A R T - F R X is actually composed of the following two sub-schemes that perform different functionalities to assist the W L A N to UMTS forced V H O - Sending-buffer Multicast-Aided Retransmission (SMART) sub-scheme and Fast Retransmission (FRX) sub-scheme: 1) The S M A R T sub-scheme multicasts the data buffered in the primary W L A N link on both the UMTS and W L A N links, so that the UMTS link can enter into slow start data transmissions at the beginning of the VHO period instead of at the end of this period. 2) The F R X sub-scheme sends all retransmissions caused by E L to the UMTS destination IP address during the VHO. Thus, unnecessarily long delays of E L retransmissions to the possibly unreachable W L A N destination IP address can be avoided. • Modeling S C T P throughput: Due to the lack of research in analytical modeling of SCTP, in order to study the behavior of SCTP, some best-known proposed analytical models on TCP such as [17] and [18] can be applied. The work [19], which is the only work we can find on analytical modeling of SCTP, proposed to extend the TCP analytic model in [17] to study the data transfer performance in SCTP associations. However, simulation results show that the extended model generally provides a pessimistic estimate of the throughput exhibited in experiments. In order to provide a more reliable and accurate analytical model to predict the SCTP performance, we propose a new analytical model that takes into account the dynamic changes of the congestion window (cwnd), the Round Trip Time (RTT), both the slow start and congestion avoidance processes, the network propagation delay and other factors that may affect the SCTP performance. By validating the analytical model using simulation results based on a wireless random loss model, we show that the theoretical performance is able to match the simulation performance accurately. It provides a useful tool to study the SCTP performance during the VHO. 1.4 Organization of Thesis The rest of thesis is organized as follows: Chapter 2 presents the related work including an overview of the U M T S / W L A N integration, current multi-homing schemes to support mobility and an introduction of SCTP and MSCTP. Chapter 3 describes an abstract address-handling model, the architecture and the procedures of supporting U M T S / W L A N VHOs using MSCTP. Chapter 4 presents the S M A R T - F R X scheme to improve the W L A N to UMTS forced handover performance and the proposed SCTP analytical model. In Chapter 5 we describe the simulation methodology, present the simulation results for the proposed schemes and compare with analytical results. Finally, Chapter 6 concludes the thesis with a summary of the presented work and suggests future work. Chapter 2 Literature Review In this chapter, Section 2.1 gives an overview of related work on the U M T S / W L A N integration. Section 2.2 gives a brief description on the concept of multi-homing and reviews the related work including a number of existing proposed multi-homing approaches to address the end-host mobility issues. Finally, SCTP, MSCTP and their development status are reviewed in Section 2.3. 2.1 UMTS/WLAN Integration In this section, we first give an overview of the U M T S / W L A N integration in Section 2.1.1. Then the related work on the U M T S / W L A N integration schemes is reviewed in Section 2.2.2. 2.1.1 Overview With the recent successful deployment of W L A N in numerous hotspots, W L A N technology will play a key role in future wireless data transmissions. Cellular network operators have recognized this fact and strived to exploit the W L A N technology by integrating this technology into the cellular data networks. For this reason, U M T S / W L A N integration becomes an important research topic for the next generation IP-based wireless networks. An U M T S / W L A N integrated network combines the strengths of both UMTS and W L A N technologies and results in a wide-area system that is capable of providing users with ubiquitous service ranging from low to high data transmission speed in strategic locations. Table 2-1 shows the complementary Table 2-1 Complementary characteristics of the UMTS and W L A N technologies U M T S W L A N 802.11 Throughput 384 kbps and up to 2 Mbps 2 Mbps and up to 54 Mbps Typical cell range 35 km 50 m Applications Full mobility, wide geographical availability, public networks, small devices, support data and voice technologies. Nomadic usage, limited mobility, small geographical availability, public or private networks, laptops, support data transfer technology. characteristics of the UMTS and W L A N technologies. There are two generic approaches to the design of an integrated U M T S / W L A N network architecture as specified by the European Telecommunications Standards Institute (ETSI): so called tight coupling and loose coupling inter-working architectures [20]. Fig. 2-1 shows the generalized architecture for U M T S / W L A N integration. In the tight coupling inter-working architecture, the W L A N is connected to the UMTS core network in the same manner as other UMTS radio access networks. Serving General Packet Radio Service (GPRS) Support Node (SGSN) and Gateway GPRS Support Node GGSN need to be upgraded to be able to handle the much higher bit rate supported by the W L A N . The main advantage of this solution is that the mechanisms for mobility, QoS and security in the UMTS core network can be reused directly. However, tightly coupled solutions will be highly specific to the UMTS technology and cause a larger impact in the Mobile user AAA: Authentication, Authorization and Accounting IWU: Inter-working unit or gateway SGSN: GPRS support node GGSN: GPRS gateway node RNC: Radio network controller UTRAN: UMTS radio access Fig. 2-1 Generalized architecture for U M T S / W L A N integration need of extensive access interface standardization. Unlike the tight coupling approach, a loose coupling inter-working architecture introduces a new element called Inter-working Unit (IWU) or Gateway in the W L A N , so that the W L A N can be used as a packet-based access network complementary to the UMTS network. The UMTS network and the W L A N share the same Authentication, Authorization and Accounting (AAA) subscriber database for functions such as security, billing and customer management, but the two networks will be peer IP domains. This scheme avoids any impact on the SGSN and the GGSN and allows many network operators and service providers to operate through roaming agreements between the networks. 2.1.2 Related Work on UMTS/WLAN Integration Varma et al. proposed solutions using MIP or SIP for mobility management in integrated GPRS and W L A N [21]. However, they mainly studied the tight coupling architecture. For the loose coupling architecture, they address only location management issues instead of seamless heterogeneous handovers and left handover issues as future work. Although Buddhikot el al. focused on the loose coupling architecture [22], they introduced a complicated new network element called the inter-working access gateway (IOTA) in the W L A N , and new service access software on the client devices to integrate the W L A N with the UMTS network. Mobile-IP agent functionality is implemented in the IOTA system to support MIP technology. Tsao et al. proposed MIP, Gateway and Emulator approaches for U M T S / W L A N inter-working according to different deployment scenarios [23]. Most of these papers point out that tight coupling approach may achieve a better performance in terms of handover latency. However, the tight coupling approach lacks flexibility. The loose coupling architecture allows the independent deployment and traffic engineering of W L A N and UMTS, and therefore offers several architectural advantages over the tight coupling approach. Moreover, in existing solutions for mobility management that employ either MIP- or SIP-based techniques, changing the IP address could result in the loss of connectivity for upper layers due to long delays. Supporting concurrent usage of access points (APs) or base stations (BSs) to maintain the ongoing session is a challenging issue. It results in additional complexities in G G S N as well as IWU that requires further study. 2.2 Related Work on Multi-homing and Transport Layer Protocol Supporting Mobility In the IP terminology, a communication host or endpoint is called multi-homed if it can be addressed by (and thus "owns") multiple IP addresses. Multi-homing refers to a situation where an end-point has several parallel communication paths (or links) that it can use. Usually multi-homing is a result of either the host having several network interfaces or a single network interface with multiple IP addresses assigned. The concept of multi-homing allows more than one paths to coexist between different endpoints and concurrent usage of different APs (or BSs) when a mobile user is moving between different cells. Thus, it opens new horizons to people to develop new solutions to support inter-network mobility. In this section, we review a number of existing network and transport layer proposed approaches, other than MSCTP, to address issues of multi-homing supporting end-host mobility. This includes Location Independent Network for IPv6 (LIN6) in Section 2.2.1 and Host Identity Protocol (HIP) in Section 2.2.2. As a part of related work of transport layer protocol supporting mobility, though Migrate-TCP (M-TCP) did not use the concept of multi-homing, it was one of the most important approaches of transport layer protocol supporting mobility before the use of SCTP was proposed. We introduce this technique in Section 2.2.3. 2.2.1 Location Independent Network for IPv6 (LIN6) LEN6 [24] provides an IP layer solution for multi-homing supporting mobility by using LIN6 generalized identities (GIs). The scheme proposed a Location Independent Network Architecture (LINA) that is based on the idea of separating the identifier and the locator of a node. The network layer is divided into two sub-layers: the identification sub-layer and the delivery sub-layer. LIN6 is a protocol that supports mobility by applying LINA to IPv6. For practical purposes, LIN6 is carefully designed to maintain compatibility with conventional IPv6 so that there is a minimal impact on the existing IPv6 infrastructure. A host can be uniquely named by its LIN6 identity (node identifier) with the LIN6 prefix (location identifier), resulting in what is called a LIN6 GI. A Mapping Agent (MA) performs the mapping between a conventional IPv6 address to an LIN6 GI. LIN6 supports multi-homing by allowing a single GI, which acts as a fixed server (FS) or a corresponding host (CH) to be associated with several GIs that can be used by a mobile host (MH). Fig. 2-2 shows the mechanism of multi-homing to support a mobile client (MC)'s handover. In this figure, the steps of LIN6 multi-homing supporting of handover are as follows: 1) An M C whose node identifier is ID-2 issues a Mapping Update Request to M A so that it can get a new location identifier prefix-B. 2) The M C sends a Mapping Refresh Request to FS or C H whose node identifier is ID-1 to notify the changing of the location identifier. 3) The FS or C H sends a Query to M A and M A replies ID-1 with the new location identifier prefix-B of ID-2. M C FS/CH JD-1 • . prefix-1 3. Query ID-2 and reply with prefix-B • prefix-Al Path A: ID-2 src: prefix-1 + ID-1 dst: prefix-A + ID-2 ~. ' : ! i Move to j Path B: j j : src: prefix-1 + ID-1 I [ j dst: prefix-B + ID-2 prefix-B V 4. Data packet transmission 2. Mapping Refresh Request jyj^ 1. Mapping Update Request : FS: Fixed Server i CH: Corresponding Host MA: Mapping Agent MC: Mobile Client Fig. 2-2 LEN6 multi-homing supporting of handover 4) The FS or C H starts to transmit data packet on the new path: prefix-B+ID-2. The disadvantage of this approach is that, it is a proprietary solution; e.g., to use this approach, an IPv6 address is translated to a GI address, but the format of the GI is defined by individual service operator and there is no open standard so far. The second disadvantage of this scheme is, it splits the network layer to identification sub-layer and delivery sub-layer and introduces an additional component, Mapping Agent, into the network for the mobility and address management. Thus, there is a relatively high implementation complexity. The development of this technology is still in progress by Keio University, University of Tokyo, and Sony Computer Science Laboratory. 2.2.2 Host Identity Protocol (HIP) The HIP [25] architecture provides simple and efficient means for endpoints to communicate while being multi-homed, mobile, or simultaneously mobile and multi-homed. HTP defines a new layer called Host Identity Layer (HIL) that decouples the transport layer from the network layer, and introduces a new host identity namespace. The transport layer sockets are no longer named with IP addresses but with separate host identifiers (His). The host identity layer translates the HI into IP address by mapping between HI and EP addresses. The mappings from His to IP addresses can be extended from a static one-to-one into a dynamic one-to-many mapping. In order to support mobility, the multi-homing capability enables a moving end-host to be in a simultaneous one-to-many relationship. A Forwarding Agent is used as a rendezvous server that provides MD? Home Agent like functionality for HTP enabled mobility. HTP specifies a mechanism that allows a host to update its address(es) to its peers. The address update is implemented with a new HTP packet type, the HIP Readdress (REA) packet. Due to the danger of flooding attacks [26], the peer must always check the reachability of the node before it can use a new address. The reachability check is implemented with a pair of new HIP packet types, HIP Address Check (AC) and HTP Address Check Reply (ACR). In addition to initiating and reachability checking, an A C packet may also act as an acknowledgement for a preceding R E A packet. The HIP approach adds a new layer, HTL, between EP and transport layers and proposes to solve multi-homing and mobility problems by introducing Forward Agents into the EP networks, which act as Rendezvous servers and perform MEP H A functionality. This results in a high implementation complexity on the current EP network. HEP is developed by Ericsson Research Nomadic Laboratory in July 2003 and the research currently is in progress. 2.2.3 Current Transport Layer Protocol Supporting Mobility In early research of transport layer protocol supporting mobility, there was no multi-homing concept involved. One of the most important proposals is a TCP extension scheme called Migrate TCP (M-TCP), which was proposed by Snoeren and Balakrishnan [27]. M-TCP allows the TCP end-points to migrate from one IP address to another based on dynamic Domain Name System (DNS) updates. In M-TCP, whenever a mobile client moves to a new network, it obtains a new IP address and updates the DNS mapping for its host name. The separation of identity and location is achieved by using the host name and the IP address. In TCP, changing the mobile host's address would disrupt any ongoing TCP connection whenever a handover occurs. This disruption may result in the closing of the existing TCP connection. To overcome this problem, M-TCP is designed to support the secure migration of an established TCP connection across an TP address change. The basic idea of M-TCP is, a TCP peer can suspend an open connection and reactivate it from another IP address, which is transparent to an application that expects uninterrupted reliable communication with the peer. In a TCP connection migration process, the mobile host activates a previously established TCP connection from a new address by sending a special Migrate S Y N packet that contains a token identifying this as the old connection. The FS will then re-synchronize the connection with the mobile client using the new address. The consumed time of a TCP connection migration process is called TCP migration delay. The main advantage of this approach is that it has no need for a third party (HA or FA) for handover. However, M-TCP does not have multi-homing function. On the other hand, the M-TCP architecture may incurs similar or even worse handover delays compared with MIP because it relies on dynamic DNS for initiation of a connection. In a later paper [28], the work is continued towards a more generic mobile session layer concept. The authors concentrated on dealing with long-lasting but transient outages in connections, and suggested that in addition to solving the initial connection and mobility tracking problems, proper mobility architectures should also address the problems of graceful disconnections, recoveries from peer hibernations and the need of fast reconnections. These issues have become the motivations that led researchers turn to study SCTP supporting mobility, because these problems can be solved by the SCTP multi-homing, association graceful shutdown and failure detection and recovery functions. 2.3 SCTP and MSCTP In this section, we introduce the protocol of SCTP in Section 2.3.1. We review MSCTP and its related work in Section 2.3.2. 2.3.1 SCTP Overview SCTP was originally developed to carry telephony signaling messages over IP networks [29]. Due to its attractive features such as multi-homing and multi-streaming, SCTP has received much attention from the research community and industry. Until today, SCTP has gradually evolved into a general purpose transport protocol and may eventually replace TCP and perhaps also UDP in the future. Fig. 2-3 shows where SCTP fits in the IP architecture. Today SCTP has more than twenty-six implementations in over a dozen operating systems. A total of six conformance testing groups are working to detect and correct implementation inconsistencies in order to make SCTP ready for Users Application UDP TCP SCTP IP Ethernet IP Reference Model Application layer Transport Layer Network layer Link and P H Y layer Fig. 2-3 SCTP in the IP reference model deployment. Table 2-2 summarizes the services and features of SCTP in comparison with TCP and UDP. Like TCP, SCTP provides a reliable full-duplex connection called association between endpoints, and employs mechanisms to control congestion in the network. SCTP is connection-oriented in nature, but the SCTP association is a broader concept than the TCP connection. SCTP provides the means for each SCTP endpoint to provide the other endpoint (during association startup) with a list of transport addresses (i.e., multiple IP addresses in combination with an SCTP port) through which that endpoint can be reached and from which it will originate SCTP packets. The association spans over all of the possible source/destination combinations that may be generated from each endpoint's lists. Unlike TCP or UDP, SCTP offers an advanced delivery option - the partially reliable data transfer (PR) [30]. PR lets a user specify a reliability level on a per-message basis. The reliability level defines how persistent an SCTP sender should be in attempting to communicate a message to the receiver - for example, never retransmit, retransmit up to a certain times, retransmit until lifetime expires, or retransmit until the association aborts. SCTP PR offers the flexibility to provide intermediate reliability levels, in Table 2-2 Comparison between SCTP, TCP and UDP [29] Services/Features S C T P T C P * Connection-oriented Yes Yes No Full duplex Yes Yes Yes Reliable data transfer Yes Yes No -Partial-reliable data transfer Optional No No Unordered data delivery Yes No Yes Flow control Yes Yes No Congestion control Yes Yes No Explicit Congestion Notification (ECN) capable Yes Yes No Selective Acknowledgement (SACK) Yes Optional No Path Maximum Transmission Unit (PMTU) discovery Yes Yes No Fragmentation of user messages Yes Yes No Bundling and unbundling of user messages Yes Yes No Multi-streaming Yes No No Multi-homing Yes No No Reachability checking Yes No No Failure detection and recovery Yes No No addition to the two extremes that UDP and TCP currently provide. Therefore, it is particularly desirable for real-time telephony signaling and multimedia applications. The benefits of this option can be observed when real-time traffic is transferred during periods of poor quality of service, heavy congestion, and path failures within the network. SCTP's four-way handshake for association establishment makes it resistant to blind IP1=2.0.0.2 NI: Network Interface OS: Operating System IP1=8.0.0.3 Fig. 2-4 SCTP with multi-homing configuration denial-of-service attacks, thus increasing overall protocol security. A TCP connection allows for only one D? address at each endpoint. However, an SCTP endpoint is identified by an SCTP transport address, which is composed of multiple IP addresses and an SCTP port number, i.e., an SCTP endpoint A can be expressed as, endpoint A = [ IPX, IP2, ...IPn: SCTP port number]. Therefore, a single SCTP association allows multiple connections coexisting between two endpoints, so called SCTP multi-homing. Such multi-homing provides redundancy at the path level, thus increasing association survivability in the case of a network path failure. Fig. 2-4 shows an example of the network level fault tolerant SCTP multi-homing configuration. In this set up, there are four possible paths between endpoint A and endpoint B. * — 16 bits SOURCE PORT - — 16 bits — * DESTINATION PORT VERIFICATION T A G C H E C K S U M -*-8 b i t s - * -*-8 b i t s - * 16 bits T Y P E F L A G S L E N G T H C H U N K D A T A SCTP C O M M O N H E A D E R C H U N K 1 C O N T R O L OR D A T A T Y P E FLAGS L E N G T H C H U N K N CONTROL C H U N K D A T A OR D A T A Fig. 2-5 SCTP packet format Unlike TCP's byte-stream service, SCTP multi-streaming allows data from upper layer application to be multiplexed into one association. SCTP packets are structured to provide a message-oriented service and allow flexible message bundling. Fig. 2-5 illustrates a general SCTP packet format, which always begins with an SCTP common header. The common header provides the following three basic functions: 1) With the source and destination port numbers, together with LP addresses in the IP header, identify the association to which an SCTP packet belongs. 2) The verification tag ensures that the SCTP packet belong to the current incarnation of an association. 3) Data integrity of the entire packet is maintained with the checksum. The remainder of an SCTP packet consists of one or more concatenated building blocks called chunks. Chunks fall into two basic types: those that carry user information are called data chunks, and those that carry control information are called control chunks. This characteristic of SCTP is different from both TCP and UDP packets, which have control information in the header and a single optional data field. Currently fourteen different control chunks have been defined for association establishment, association termination, data Selective Acknowledgement (SACK), destination failure detection and recovery, Explicit Congestion Notification (ECN) and error reporting, which leaves an additional 240 new chunk types that may be defined in the future by the IETF. Each chunk is delineated by a chunk header, which identifies a chunk's type, special flags needed by a given chunk type and the length of the chunk. SCTP has the flexibility of concatenating or bundling different chunk types into a single SCTP packet1. The only restriction is that the size of a packet should not exceed the Path Maximum Transmission Unit(PMTU). 2.3.2 Mobile SCTP (MSCTP) SCTP introduces the idea of multi-homing [9]-[ll][29] where a host can support multiple connections with different interfaces and IP addresses simultaneously in an association. Although the primary goal of this feature is error resilience, it can provide a simple and powerful framework for mobility support in IP networks. To support multi-homing, SCTP endpoints exchange lists of IP addresses during the initiation of an 1 In the rest of this thesis, we only use bundle technology for control chunks. We are not going to bundle data chunks, i.e., each SCTP packet carries at most one data chunk. association. Changing an SCTP endpoint's address list in a running association using the recently proposed SCTP D A R extension [31] makes mobility and seamless handover possible. SCTP D A R enables the SCTP endpoints to add and delete IP addresses, and change the primary IP address dynamically in an active association using Address Configuration (ASCONF) and Address Configuration Acknowledgement (ASCONF_ACK) chunks. SCTP with its D A R extension is called MSCTP. Since the typical use of SCTP is for reliable data stream transmissions between a server and its client(s), in this thesis, without loss of generality, we use a client-server model to apply the MSCTP technology and discuss a seamless handover at a Mobile Client (MC) between UMTS and WLANs, where the other endpoint is a Fixed Server (FS). IP mobility can be divided into issues of location management and handover management [13]. There are two types of sessions considered in MSCTP: (1) sessions originated at MCs towards FSs; and (2) sessions originated at FSs towards MCs. Note that only sessions in (2) require the additional location management functionality for the session originator to find the current location of an M C . Since our research focuses on discussion of handover management, we only consider sessions in scenario (1), which fits well in the client-server model. The handover configuration is shown in Fig. 2-6. The only requirement for supporting the handover based on SCTP is that the M C and the FS hosts are equipped with the MSCTP implementation, i.e., SCTP with D A R extension. The basic assumption for seamless handover is that the M C is able to obtain a new IP address in the new location with the help of Dynamic Host Configuration Protocol (DHCP) in JPv4/IPv6 or stateless address auto-configuration in IPv6. The number of IP addresses used by the FS can be either one or two, respectively resulting in two. types of Location A >< Location B Fig. 2-6 SCTP support of seamless handovers configurations for the MSCTP handover: a single homing asymmetric configuration [13] or a dual homing symmetric configuration [12]. For both of these configurations, the procedure for the MSCTP handover is: 1) Before a handover, an SCTP association is established between an M C and FS. 2) The M C moves to a new location and obtains a new IP address. The M C adds the new IP address to the SCTP association using the ASCONF and A S C O N F j A C K chunks described in [31]. Thus, the M C becomes multi-homed and is now reachable by two different EP addresses. 3) The M C continues to move towards the new location. The M C should always play the active role to trigger an MSCTP handover because only the M C knows the movement of itself and the signal strength from the old and new BSs or APs. The method to realize a handover is by changing the M C ' s primary EP address. The possible rules for triggering a handover by the M C are: a) as soon as a new EP address is detected; b) by using an explicit indication from the underlying layer. 4) When the M C confirms the failure of the old link by detecting the signal strength from the physical layer, the M C informs its peer that its old IP address is now no longer reachable and can be removed from the SCTP association. 5) M C repeats the handover procedure whenever it moves to a new location, until the SCTP association is closed. Although Riegel and Tuexen proposed to use SCTP to support mobility management in [12] and Koh el al. further describe the architecture and handover procedure in [13], the following problems are found in the work. • The handover procedures described in both [12] and [13] are quite vague. Both proposed to use SCTP D A R extension to achieve the handover. However, these proposals lack detailed descriptions of the procedures. The parameter setting in the address configuration chunk (ASCONF) is not clear either. • Authors of [12] and [13] have different ideas regarding the configuration used to support MSCTP. Authors of [12] strongly suggest that a server must use multiple IP addresses to provide M C with multiple paths in order to fully take advantage of the existence of a second interface at the M C for fault resilience. However, authors of [13] argue that it is natural to consider FS supporting handover with only one IP address since a fixed host should not add new IP addresses dynamically. If it is unavoidable to use two IP addresses, FS probably need to be in the dual homing state from the association initiating stage. • Neither of these documents address implementations of simulation models or prototypes. Authors in [32] presents a prototype implementation for mobile SCTP (so called M-SCTP in [32]) with the configuration described in [13]. However, the experimental results show that there is a long interruption time during an SCTP handover. 2.4 A Summary of Related Work Table 2-3 summarize the protocols supporting handover that we have reviewed. The disadvantages of the network layer mobility can be summarized as follows: • As router solutions, most network layer solutions require additional hardware network components to be introduced into the network. Thus, these solutions have a high impact on the existing networks. • The overall network architecture is generally complicated for network layer solutions. • Mapping between TP addresses and node/location identifiers increases the traffic load on the endpoints and may result in unexpected delays in handover management. • It is difficult to implement flexible user interface selection policies. It may only be possible to explicitly defining static rules for interface changing. We have also reviewed the related work on transport layer mobility. We summarize the advantages of the transport layer mobility as follows: • Mobility is an end-to-end issue instead of a router or a network component issue. Solving mobility issues with transport layer protocols in endpoint systems make the entire network architecture simpler. • Transport layer protocol-based mobility can adapt flow and congestion control parameters quickly and easily to the new network during and after the handover. Table 2-3 Summary of protocols supporting handover Protocol IP Version Layer Endpoint ID Home Agent functionality Interface selection policy MIP IPv4/v6 Network IP address(es) H A Not defined LIN6 IPv6 Network Generalized ED (GI) Mapping Agent Not defined HTP IPv4/v6 Between L3 andL4 Host Identity (HI) Forward Agent Not defined M-TCP JPv4/v6 Transport TransportJ address None API SCTP IPv4/v6 Transport SCTP transport address None API SEP IPv4/v6 Application EP address(es) SEP servers Support • From the hardware point of view, transport layer mobility does not need additional components or mobility enabled routers incorporated into the network. Therefore, it has a low impact on the existing networks. From the software point of view, there is no need to introduce new software states such as MEP's tunnel states into the network. • Transport Layer Application Programming Enterface (API) makes it easy to implement user interface selection policies. SCTP is a relatively new protocol. Though recently researchers are investigating mechanisms that exploit SCTP's novel features to improve performance in wireless and mobile environments, there is still no large-scale experimental results available to verify if the current SCTP standard meets each of the high reliability requirements of the mobility managements in wireless networks or not. We believe that not only SCTP is a promising solution to support mobility, but also a good candidate for U M T S A V L A N integration in the next generation IP networks. MSCTP-based U M T S / W L A N integration requires neither hardware modifications to the current networks, nor software modifications to applications. It is independent of access technologies too. Therefore, it provides a network-independent solution that should be preferred by service providers. Chapter 3 UMTS/WLAN Unforced VHO This chapter explains the key design issues involved in MSCTP supporting U M T S / W L A N VHO. In Section 3.1, we present the architecture. In Section 3.2, we develop the VHO procedures in two possible configurations, the single-homing and the dual-homing configurations based on an abstract address-handling model, which is described in details in this section as well. 3.1 System Architecture The objective of designing an U M T S / W L A N integration scheme is to make the VHO between the two types of networks as seamless and efficient as possible. The rationale behind the proposed scheme of supporting U M T S / W L A N VHOs using SCTP is that, due to the SCTP multi-homing feature, from the association point of view, it does not matter whether an endpoint's network interfaces belong to the same technology or not. As long as it is possible for an interface to establish a connection to the Internet via an IP address, the interface can be added into the current association via its D? address. MSCTP provides an end-to-end soft handover solution for mobility management. Therefore, introducing MSCTP to support U M T S / W L A N integrations makes the entire network architecture simpler. Fig. 3-1 shows the architecture of U M T S / W L A N VHO using MSCTP. The architecture can be either tight coupling or loose coupling. The basic assumption for the seamless VHO between UMTS and W L A N cell is that the M C is able to obtain a new IP address when it moves into a W L A N cell, via either DHCP or stateless address auto-configuration in IPv6 network. The general requirements for SCTP to >•—^  GGSN A A A Server Tight Coupl ing • • SGSN MSCTP IPv4/v6 / UMTS & WLAty L1/L2 Dual Mode%--RNC .oose Coupling Gateway Router IPv4/v6 Protocol Stack for FS Protocol Stack for MC \ UMTS coverage / 'AAA: Authentication, Authorization, Accounting L1/L2: Layer 1/Layer 2 GGSN: Gateway GPRS Service Node SGSN: Serving GPRS Service Node Fig. 3-1 Architecture of U M T S / W L A N integration using MSCTP support seamless VHO are as follows: • Both M C and FS are equipped with MSCTP implementation, i.e., SCTP with D A R extension; • Dual-mode support of UMTS and W L A N is available at the physical and data link layers of the M C ; • Issues such as A A A , subscriber identification and QoS provisioning due to change of access network have been resolved through roaming agreements between UMTS and W L A N under one or more operator(s). It should be noticed that the mobility between UMTS and W L A N is not completely symmetric. To take advantage of the higher speed of W L A N , the VHO from UMTS to W L A N may take place as soon as the W L A N coverage is available. This is an unforced VHO process. However, in the reverse direction, the VHO from W L A N can be either a forced VHO process or not. This is because the W L A N to UMTS VHO can be triggered either by: 1) the M C leaving the W L A N coverage and losing the W L A N signal (a forced V H O process); or 2) the user's preference to perform a V H O from W L A N to UMTS under certain rules when both of W L A N and UMTS networks are available (an unforced V H O process). For example, during the W L A N peak traffic period, the user may not be satisfied with the quality of the W L A N service and may prefer to use UMTS instead. In this chapter, we only consider the V H O that is not a forced handover process in both directions. The case of W L A N to UMTS forced VHO will be discussed in Chapter 4. The reason we separate these two cases is that, for the forced handover process, SCTP failure detection and recovery functionalities are activated and result in a different handover procedure than that of an unforced one. 3.2 Unforced VHO Procedure U M T S / W L A N unforced V H O means that the application or user's agent in the M C explicitly requests a VHO based on the user's preference when both of the UMTS and W L A N coverage are available. In this subsection, we firstly present an abstract address-handling model in Section 3.2.1. Using this model definition makes our discussion on address handling and handover processing easier to follow. Then we introduce the proposed U M T S / W L A N V H O procedures for M C and FS in both the single-homing and the dual-homing configurations in Section 3.2.2. In Section 3.2.3, by comparing the vertical handover delay and other characteristics of these two configurations, we recommend the preferred configuration, on which the remainder of this thesis will be based. 3.2.1 Abstract Address-handling Model Description An SCTP association is the transport layer connection that SCTP provides to the endpoints. There are two endpoints and two address sets known by the peers [29] in an association. An association A between two endpoints El and E2 is given by: A = [El: Addr (El) ; E2: Addr (E2)]. In IP implementations, the outgoing interface of a multi-homed host is often determined by the destination IP address. The mapping of an outgoing source IP address and a destination address is done by a lookup in the host routing table maintained by the operating system [33]. Assume that an endpoint E has m source EP addresses: s_IPl, s_IPm and its peer has n destinationIP addresses: d_lPl,..., d_lPn in the association. The primary path in the association is the connection between sJ.Pl and dJPl. Then the host routing table of the endpoint E can be expressed as: RT(E) =[(sJPl,dJPl);(sJP2,dJP2),...,(sJPm,dJPn)]. Note that the primary IP address pair is separated from the secondary IP address pairs with a When m 4- n, the address mappings are not in one-to-one correspondence, and the routing table may allow a maximum of m x n possible paths between the two endpoints. \MC_IPi MCt  \MC_IP2 Fig. 3-2 Simplified architecture of dual-homing configuration We now apply this model to summarize the key address handling features implemented in SCTP D A R extension. We use the configuration in Fig. 3-2 as an example, where an association A is given by: A = [MC: Addr(MQ; FS : Addr(FS)]. 1) Add IP Address: • Before Add IP Address process: Addr0id(MC) = {MCJPl} Addr(FS) = {FSJPl} RToid (MC) = [(MCJPl, FSJPl)] RTotd (FS) = [(FSJPl, MCJPl)] • After Add IP Address process (MC's new IP address MCJPl is added to the association): Addrnew(MQ = Addr0id(MQ u {MCJP2} = {MCJPl, MCJPl] RTnew (MC) = [(MCJPl, FSJPl)] RTnew (FS) = [(FSJPl, MCJPl); (FSJPl, MCJP2)] 2) Delete IP Address: • Before Delete IP Address process: AddroidMC) = {MCJPl, MCJP2} Addr(FS) = {FSJPl} RT0id (MC) = [(MCJPl, FSJPl)] RToid(FS) = [(FSJPl, MCJPl); (FSJPl, MCJP2)] • After Delete IP Address process ( M C s address MCJPl is deleted from the association): Addrnew(MC) = Addrold(MC) - {MCJPl} = {MCJPl} RTnew (MC) = [(MCJPl, FSJPl)] RTnew (FS) = [(FSJPl, MCJPl)] 3) Set Primary Address: • Before Set Primary Address process: Addr(MQ = {MCJPl, MCJPl} Addr(FS) = {FSJP1, FSJPl} RToid (MQ = [(MCJPl, FSJPl); (MCJP2, FSJP2)] RToM(FS) = [(FSJPl, MCJPl); (FSJP2, MCJP2)] • After Set Primary Address process (MC requests FS to set address MCJP2 as the primary address): RTnew (MQ = [(MCJP2, FSJPl); (MCJPl, FSJPl)] RTnew (FS) = [(FSJP2, MCJP2); (FSJPl, MCJPl)] Note that in the dual-homing configuration shown in Fig. 3-2, though there are four possible paths between the two endpoints, for reasons of considerations on path diversity, policy-based routing, load balancing, etc., the routes between MC and FS are M C FS Step 1. Step 2. Step 3. INIT IN IT -ACK C O O K I E E C H O C O O K I E - A C K ASCONF (Add new IP) ASCONF-ACK VHO triggering • • • ASCONF (Delete old IP) ASCONF-ACK S H U T D O W N S H U T D O W N - A C K S H U T D O W N - C O M P L E T E association establishment M S C T P association closing Fig. 3-3 Three basic steps in VHO procedure set to be only two in the routing table, i.e. path (MC_/P1, FSJPl) and path (MCJPl, FSJPl). This configuration simplifies the abstract address-handling model and our further discussions on V H O procedure. 3.2.2 The Proposed VHO Scheme and Procedures To support VHOs, the FS may be configured for: (1) single homing, i.e., the FS provides only one IP address to support the handover; or (2) dual homing, i.e., the FS allows more than one (usually two) IP addresses to support the M C ' s mobility. For each of these configurations, the handover procedure has three basic steps between association establishment and closing processes as shown in Fig. 3-3: • Step 1, Add IP Address process: M C moves into "a new location, gets a new IP address and sends an ASCONF to request FS to add the new IP address to the current association. • Step 2, VHO Triggering process: M C triggers a VHO by either sending a "Set Primary IP Address" request with an ASCONF or directly setting the remote primary destination EP address. • Step 3, Delete IP Address process: M C is unable to detect signals from the old BS or AP and sends a "Delete EP Address" request with an ASCONF to FS to delete the M C ' s old EP address from the association. 1) The single-homing FS: The VHO procedure for FS in the single-homing configuration is shown in Fig. 3-4. Note that UMTS to W L A N V H O is shown in the upper part and the V H O in the reverse direction is in the lower part of the figure. When an M C moves into a W L A N cell covered by a UMTS cell, it gets a new EP address WLANJP. The "Add EP Address" process allows M C to inform the FS its new EP address. The "VHO Triggering" process allows M C to trigger a V H O based on some decision rules. The VHO from UMTS to W L A N is triggered by M C sending an ASCONF with parameter type set to "Set Primary Address". This is a handshake process. After that, FS sets the M C ' s new IP address as its primary destination address and sends an A S C O N F _ A C K to confirm the operation success. In this process, assuming that the data transmission rate is txmn_rate, because of the handshake process, the VHO delay can be calculated by: MC UMTS IP MC WLAN IP RT(MQ=[(UMTSJP, FSJP)] 1) ASCONF (Add IP Address, WLAN_IP) DATA RT(FS)=[(FSJP, UMTSJP)) ASCONF ACK 2) ASCONF (Set Primary Address, WLANJP) RT(FS)=[(FSJP, UMTSJP); (FSJP, WLANJP)] ASCONF ACK RT(MQ=[(WLANJP, FSJP)] RT(FS)=[(FSJP, WLANJP); (FSJP, UMTSJP)] DATA .UMTS—WLAN , ASCONF (Set Primary Address, UMTSJP) ASCONF ACK RT(MQ=[(UMTSJP, FSJP)] RT(FS)=[(FSJP, UMTSJP); (FSJP, WLANJP)] DATA 3) ASCONF (Delete IP Address, WLANJP) ASCONF ACK RT(MQ=[(UMTSJP, FSJP)] RT(FS)=[(FSJP, UMTSJP)] WLAN—>UMTS Fig. 3-4 VHO procedure (FS is in the single-homing configuration) De/aVoverall - ^ A S C O N F + ^ h a n d o v e r ' (3.1) where T A S C O N F is the transmission time of ASCONF and A S C O N F _ A C K chunks: TASCONF = (ASCONF_chunk_size/txmn_rate + propagation_delay) x 2, and ^handover = changeover command delay + buffered data transferring time. After the W L A N to UMTS VHO Triggering process, if M C loses the signal from the W L A N cell, it enters in the "Delete IP Address" process. M C sends an ASCONF with parameter type set to "Delete IP Address" to request FS to release the address WLAN_IP from its host routing table. When M C receives the A S C O N F _ A C K from FS, M C deletes WLAN_IP from its address list and WLAN_IP is released from the association. 2) The dual-homing FS: In SCTP, an SCTP packet is designed to carry multiple chunks, including both control and user data chunks. When small outbound messages are queued for transmissions, the sending endpoint can bundle as many small messages together as the current Path Maximum Transmission Unit (PMTU) allows and then transmits them in a single IP datagram [29]. An SCTP data receiver uses the length field of a chunk to determine the end of the data in each chunk, and then unbundles this bundled user message into individual messages. This is called the SCTP User Message Bundling service. In this way, the SCTP bundling message service not only reduces the overhead of additional SCTP and BP headers, it can also substantially reduce the number of SACKs needed by the data receiver. The bundling service is not a mandatory feature for implementation of SCTP, but we found it helpful to simplify the V H O procedure for FS in the dual-homing configuration. The V H O procedure for FS in the dual-homing configuration is shown in Fig. 3-5. There are two differences between this procedure and the one for FS in the single-homing MC UMTS IP 1) ASCONF (Add IP Address, WLANJP) MC WLAN IP RT(MQ=[(UMTSJP, FSJfl)] DATA ASCONF ACK bundled /vith ASCONF (Add IP Add ess, FS_IP2) ASCONF ACK RT(MQ=[(UMTSJP, FS_, (WLANJP, FSJP2)] 2) MC sets FS_IP2as the primary destination IP address RT(MQ=[(WLANJP, FS. (UMTSJP, FSJPl)] RT(MQ=[(UMTSJP, FS. (WLANJP, FSJP2)] 3) ASCONF (Delete IP Adc ASCONF ACK RT(MQ=[(UMTSJP, FS. FS FS IP1 piy, JP2); DATA MC sets FS_IP1 as the primary destination IP address IP1)\ D A T A ress, WLANJP) ASCONF_ACK bundled with ASCONF (Delete IP Ac dress, FSJP2) IP.1)} FS FS IP2 RT(FS)=[(FSJP1, UMTSJP)] RT(FS)=[(FSJP1, UMTSJP); (FSJP2, WLANJP)] RT(FS)=[(FSJP2, WLANJP); (FSJPl, UMTSJP)] -«.UMTS—WLAN RT(FS)=[(FSJP1, UMTSJP); (FSJP2, WLANJP)] RT(FS)=[(FSJP1, UMTSJP)] "WLAN —UMTS Fig. 3-5 V H O procedure (FS is in the dual-homing configuration) configuration. The first difference is the "Add/Delete IP" Address process. In the dual homing configuration, when FS responds to M C s adding/deleting IP address request with an Acknowledgement (ACK), FS bundles an ASCONF to request M C to add/delete the FS's secondary D? address into/from the association. The M C sends A S C O N F _ A C K to confirm the completion of Add/Delete IP Address process. The second difference is in the VHO Triggering process. Since both M C and FS are in the dual-homing configuration. M C can directly set the FS's secondary address as the primary destination in its host routing table and start to send data on the new link. In this case, there is no handshake process and the VHO delay becomes: Delayovemu — ^ h a n d o v e r -(3.2) 3.2.3 Comparison of Single-homing and Dual-homing Configurations In practice, network layouts may be less than ideal. The endpoints engaged in communications may have an asymmetric number of network addresses assigned to them. Fig. 3-6 shows an example in which an SCTP association is set up between a multi-homed endpoint sender and a single-homed endpoint receiver. In such a case, the redundant network addresses at the sender will help very little in providing fault resilience to the communication because of the routing tables shown in the figure. Due to the lack of redundancy, if the path between gateway router Snd_gwl and Snd_IPl breaks in either direction, the association will not survive. This is because of the fact that the number of possible different paths that can be used to route data between two endpoints can never be larger than the minimum number of IP addresses used by the endpoint. Therefore, we see from the example that if FS and M C are in one-to-two asymmetric Receiver R e c J P IH8> rface Control point Sender Receiver Destination Gateway Destination Gateway RecJP Snd_gwl Snd_JPl Rec_gw Snd_JP2 Rec_gw Fig. 3-6 An asymmetric SCTP association multi-homing configuration, a single path failure in the network may cause the association failure even when a backup path exists. The best solution of this problem is to let the FS have two IP addresses (even with only one physical interface), thus enabling both M C and FS to be in symmetric dual-homing configuration. This two-to-two configuration enables easy distinction of the two links at the M C . Unlike the single-homing configuration, the dual-homing configuration allows SCTP to represent different paths by different entries in the host routing table. It is beneficial in terms of fault resilience for both M C and FS to use all the IP addresses available to them when VHO is performed. The second advantage of the FS in dual-homing configuration over the single-homing configuration is, as we have seen in Section 3.2.2, the V H O delay for the FS in dual-homing configuration, ^handover, is less than that of the single-homing configuration, ( T A S C O N F + ^handover)-Sender Rec_gw Rec IP1 &Rec IP2 Because of these two advantages, we recommend the dual-homing configuration to support VHOs in the U M T S / W L A N integration environment. Chapter 4 WLAN to UMTS Forced VHO In Chapter 3, we developed the U M T S / W L A N unforced V H O procedure in both directions. However, in an U M T S / W L A N overlay environment, besides the user application explicitly requesting VHO, the most likely reason of triggering a W L A N to UMTS VHO is that the mobile user leaves the W L A N coverage and losses the signal from the W L A N AP. This is referred as the W L A N to UMTS forced handover process. In this section, we specifically focus on studying the SCTP behaviors when an M C leaves the W L A N coverage and goes into a W L A N to UMTS forced V H O period. The rest of this chapter is organized as follows. Section 4.1 describes the problem. Section 4.2 presents a new scheme that we call S M A R T - F R X to assist the data transmission during the W L A N possibly unreachable period. In Section 4.3, we present a comprehensive analytical model by modeling the SCTP throughput during the W L A N to UMTS forced VHO. 4.1 Problem Descriptions In this section, we divide the packet losses in the wireless environment into three types in Section 4.1.1. We describe problems that may be encountered on both W L A N and UMTS links during a W L A N to UMTS forced VHO in Sections 4.1.2 and 4.1.3. 4.1.1 Transport Layer Protocol in the Wireless Network In a wireless Internet environment, most packet losses are caused by multi-path fading over wireless channels, not by congestion [34] [35]. Mobile handovers as well as FS Gateway Router FS: Fixed Server M C : Mobile Client BS: Base Station AP Access Point Congestion Loss (CL) Handover Boss (HL) \ ^ W L A N UMTS Fig. 4-1 Three types of packet loss affecting SCTP in mobile network transmission errors in wireless Internet access result in the following three kinds of losses that will dominate the SCTP flow and congestion control behavior in W L A N / U M T S VHO situations. We illustrate the locations of these three losses in Fig. 4-1: • Congestion Loss (CL): C L happens in the routers or Gateway routers in wireless networks because of bandwidth limitations. • Error Loss (EL): This type of loss occurs in the wireless channel mainly due to multi-path fading. E L is the main packet losses when an M C communicates with a fixed server via a wireless link. • Handover Loss (HL): This type of loss is unrelated to network congestion and comes from handovers between cells when packets should be re-routed to and from the mobile client in a new location. Packets may be lost due to futile transmissions over the wireless network when an M C moves out of the old cell (e.g. W L A N coverage) and enters into a new cell (e.g. UMTS coverage). Among the above-mentioned three types of loss, two types of loss can dominate the SCTP performance in the W L A N to UMTS forced VHO process. One is consecutive packet dropping because of route disconnection from handovers, i.e, H L ; the other is high error rate caused by multi-path fading over radio channels, i.e., E L . Same as TCP, SCTP uses fast retransmission and timeout retransmission mechanisms to recover packet losses. Because H L is mainly caused by an M C at which the Received Signal Strength (RSS) from the old coverage has fallen below threshold for at least a period of the minimum Retransmission Timeout (RTO m i n ), it generally results in the SCTP Timeout (TO) retransmission. On the other hand, when we model data transfer subject to EL, we assume that packet losses happen only in the direction from sender to receiver. This assumption is acceptable because it is very rare that wireless fading may cause consecutive packet losses in both directions longer than RTO m j n (1-second time). Because of the SCTP fast retransmission algorithm, E L can be detected by a sender receiving duplicate SACKs [29]. In SCTP, a retransmission that is triggered by the sender receiving Four Duplicate SACKs (FD) is called the FD retransmission. In this chapter, we use H L to model the packet loss on the W L A N link and E L to model the packet loss on the UMTS link during the W L A N to UMTS forced VHO process. 4.1.2 Data Transmission Subject to H L When an endpoint's peer is multi-homed, the general rules for data transmissions and retransmissions specified in [11] can be summarized as the following: • By default, an endpoint should always transmit via the primary path. • A sender should try to retransmit a chunk to an alternative active destination address. • An SCTP endpoint uses a dynamic changing Timer 3 for Retransmission (T3-rtx) to ensure data delivery in the absence of any feedback from its peer. The initial value of this timer is referred as RTO. • Each time the T3-rtx expires for a destination address, an error counter of that destination address will be incremented and the value of the T3-rtx is doubled. An upper bound of this timer T3-rtxm!lX is decided by the Path.Max.Retrans threshold. When the value of the error counter exceeds the Path.Max.Retrans, the endpoint should mark the destination address as inactive. Therefore, the Path.Max.Retrans threshold is used to detect the failure of an individual address of the peer. Assume that the Path.Max.Retrans is PMR, the first T3-rtx is RTO, the total time taken to detect the failure of a destination EP address addr is Timefaiiure(addr) = RTO + 2 x RTO+ 2 2 x RTO +...+ 2PMR x RTO. We use the examples shown in Figs. 4-2 to 4-3 to illustrate the above-mentioned rules. Ef PMR is five as recommended in the specification [11], link failure occurs when there are six consecutive timeouts detected. Figs. 4-2 and 4-3 show the SCTP transmission when the W L A N link is in possibly unreachable period and the W L A N link is in failure, respectively. If we assume that RTO is set to be RTOmJn, which is 1 s as specified in the specification [11], the minimum total time for the W L A N link failure detection is: TimefaUureiaddrwLAN) = RTO +... + 2 5 x RTO = 63 s. In other words, as shown in Fig. 4-3, when an M C leaves the W L A N core area and losses the signal from the W L A N coverage, in a 63-second W L A N possibly Sender TSN= Receiverf Time Slow start • RTO 2RTO 4RTO SRTO Restore 1 Sender f_ T S N Receiver! c+lf c\k+\J c-w+2f 7"- • • S(c+k) \ I S(c+/fc+l)\ / S(c+k+2) \ I S(c+*+3) V U M T S Legend: I I Data transmission on W L A N link; I -saif I Data transmission on U M T S link; S(c): S A C K for T S N = c; n: Error counter of W L A N link; k: Data sent after T S N = c dequeues but before detecting a timeout Fig. 4-2 SCTP transmissions when the W L A N link is in possibly unreachable period «= 0 Sender 6 Time RTO 2RTO 4RTO SRTO \6RTO 32 RTO Legend: The same with that shown in Fig. 4-3. Fig. 4-3 SCTP transmissions when the W L A N link is in failure unreachable period, only (k+6) packets are successfully transmitted. In the following we explain how k is determined. We assume that a data chunk whose Transmission Sequence Number (TSN) is c encounters a timeout. When the chunk c dequeues from the sending buffer of the W L A N link, a T3-rtx equals to RTO is started. Before T3-rtx expires, the sender does not know that the chunk c will encounter a timeout. Therefore, the sender continuously sends data on the link, and k is the number of data chunks sent in the time period, which is from the time that chunk c dequeues from the W L A N sending buffer until the sender detects its timeout. In all cases, the condition of a TO retransmission being triggered is the complete loss of a block of data, TSNs from c to (c+k) and their corresponding SACKs. If the sender can receive SACKs during this block of data transmissions, the SCTP fast retransmission is activated instead. 4.1.3 Data Transmissions Subject to E L In this section, we study the SCTP behavior when transmissions are subject to EL. In the SCTP dual-homing configuration, according to the fault resilience and routing mechanism, when both primary and secondary links are not stable, data retransmissions on these two links follow Round Robin scheduling. Assuming that there are only two paths between two endpoints, a lost packet on the primary link is retransmitted on the secondary link; if the packet is found to be lost again on the secondary link, either detected by TO or by FD, the packet is next retransmitted on the primary link. This process repeats until the association error counter reaches the value of Maximum Association Retransmissions (Association.Max.Retrans). If the association error counter exceeds the limit indicated in this protocol parameter, the local endpoint marks the peer endpoint as unreachable and closes the association. In our case, when the W L A N link is in the possibly unreachable period, all TO data on the W L A N link are retransmitted on the UMTS link. If any of the packets are lost on the UMTS link, these packets are retransmitted via the W L A N link. However, because the W L A N is currently in the possibly unreachable period, the packet is thus waiting in the W L A N sending-buffer. Even if the packet can be dequeued, because H L is in effect on the W L A N link, it is unlikely that the packet can be successfully transmitted. While the UMTS link is unable to receive any information about this retransmission for a long time, it considers the packet as lost and a TO retransmission is triggered. This results in both W L A N and UMTS links being in TO retransmission processes. It would greatly reduce the data transmission rates and easily cause a shutting down of the association. 4.2 The Proposed Scheme From the problem descriptions, we see that under the current SCTP specification, when a primary link is in the failure detection period, SCTP packet TOs may cause serious slow down of data transmissions. This is because in the current SCTP specification, under the assumption that failures are temporary and can be repaired quickly, the SCTP's failure detection and recovery mechanism acts conservatively to ensure that associations do not prematurely and incorrectly assume link failures. However, a drawback of this conservative approach is that the performance unnecessarily suffers during the failure detection period. We show that the current SCTP failure detection and recovery mechanism described in the specification is too conservative to fully exploit SCTP's multi-homing capability to maintain seamless communications between the endpoints. We propose a novel scheme called S M A R T - F R X , a solution that does not wait until the W L A N link is restored or is determined to be in failure before initiating the recovery process. The S M A R T sub-scheme allows the data buffered for transmissions on the W L A N link to be multicasted on both W L A N and UMTS links during the time the W L A N destination IP address is possibly unreachable. If there is any packet loss caused by multi-path fading when the data is being multicasted, the F R X sub-scheme sends the retransmissions to the same destination IP address, without alternating retransmissions between the primary and secondary links. We argue that the proposed scheme fully takes advantage of the SCTP's multi-homing feature and avoids unnecessarily long delays caused by the retransmissions to the possibly unreachable alternate IP address. Therefore, it can improve the overall throughput significantly. In this section, we describe the S M A R T sub-scheme in Section 4.2.1 and the F R X sub-scheme in Section 4.2.2. 4.2.1 The SMART Sub-scheme We propose a new queue management scheme we call S M A R T to deal with H L on the W L A N link so that the overall throughput can be increased during the W L A N possibly unreachable period. The W L A N possibly unreachable period is defined as the period that begins at detecting of the first TO, i.e., the W L A N link error counter is set to be one, and ends at the time of either the W L A N link is restored or the link is set to be inactive. If the W L A N link error counter resets to zero before exceeding the Path.Max.Retrans, then the link is being restored. If the W L A N link error counter Sending-buffer of WLAN link 1st timeout 2 timeout c !.. c+k n* timeout {n+lf is SACKed c+k Sending-buffer of UMTS link time=RTO n=l If n < Path.Max.Retrans, ^>the WLAN link is c+k+n restored ana goes to slofl start. If n > Path.Max.Retrans, the WLAN link has :f> failed and UMTS link time=2RTO n=2 time=2"RTO n=Path.Max.Retrans goes to slow start. Note, c: TSN of data chunk that encounters the 1st timeout k: The number of data chunks transmitted between the chunk c dequeued and detection of its timeout n: Error counter of the W L A N link, i.e., the numbers of consecutive timeout detected. If n< Path.Max.Retrans { W L A N link is restored and goes to slow start;}// shown as C—!> Else { W L A N to UMTS V H O occurs and UMTS link goes to slow start;}// shown as t = ^ Fig. 4-4 Data transmissions before application of the S M A R T scheme exceeds the Path.Max.Retrans, then the W L A N link is set to be inactive. In SCTP, if a sender does not receive any responses from the peer in a given period, the sender cannot wait forever. The phrase "possibly unreachable" emphasizes that, if a sender notices that all expected responses are missing for consecutive packets sent to a destination address, the sender will then have to conclude that the particular destination address of the peer is very likely unreachable now. This leads to the algorithm of the TO failure detection in SCTP. Fig. 4-4 illustrates the data transmission before application of SMART. Our proposed S M A R T mechanism is to copy all the buffered data from the W L A N link to the UMTS link so that the data in sending-buffers of both W L A N and UMTS links are completely the same. New data are queued at the tails of both of these two sending-buffers. As shown in Fig. 4-5, because of the copying and multicasting actions, instead of waiting and only retransmitting the TO data from the W L A N link, the 1st timeout 2 n d timeout n* timeout (n+l)* is SACKed c ... c+k c+k+ Sending-buffer of WLAN link o Slow c+k the UMTS 222222 If n < Path.Max.Retrans, c c+m+Aj+n â+m+k+n+\ the WLAN link is restored ' >^ when the (c+k+n+l)6' data is start on link > Sending-buffer of UMTS link time=RTO n=l time=2RTO n=2 Note, c, k,n: Same as defined in Fig. 4-5 m: The number of data chunks transmitted on the UMTS link in a slow start process since n=2 during the WLAN link failure detection period. SACKed and goes to slow start. If n > Path.Max.Retrans, the WLAN link has failed and the UMTS link continues its data » , n „ m transmission. time=2 RTO n=Path.Max.Retrans If n< Path.Max.Retrans (WLAN link is restored and goes to slow start, data stops queuing on UMTS link;}// shown as i — - S Else {WLAN to UMTS VHO occurs and UMTS link continues with the data transmission, WLAN becomes inactive;}// shown as i s Fig. 4-5 Data transmissions with application of the S M A R T scheme UMTS link enters into a slow start process since the time of the first TO is detected on the W L A N link. This duplicate queuing action ends when the data sender detects the end of the W L A N possibly unreachable period. After this, 1) if the W L A N link is restored, new data are queued only in the a slow start process since the time of the first TO is detected on the W L A N link. This duplicate queuing action ends when the data sender detects the end of the W L A N possibly unreachable period. After this, 1) if the W L A N link is restored, new data are queued only in the W L A N sending-buffer and the W L A N link remains as the primary connection. The UMTS link becomes idle after all the buffered data have been sent out; or 2) if finally the W L A N link error counter exceeds the Path.Max.Retrans, a W L A N to UMTS forced VHO is triggered. As a result, the UMTS link becomes the primary connection and new data is queued only in the UMTS sending-buffer, while the W L A N link becomes the secondary connection and goes to the inactive state. In any case, the slow start data transmission process on the UMTS link starts at the beginning of the W L A N possibly unreachable period, instead of at the end of this period. 4.2.2 The FRX Sub-scheme The difference between H L and E L is that H L is usually detected by a TO, while E L can be detected by a sender receiving duplicate SACKs. Both TCP and SCTP detect losses in two ways, the retransmission timer timeouts and duplicate SACKs (or ACKs), but with a minor difference. In SCTP, four instead of three duplicate SACKs (or ACKs) are needed to trigger a retransmission. Except for this, SCTP bases its congestion control on the TCP congestion control principles [36]. In order to avoid E L on the UMTS link being unnecessarily retransmitted on the W L A N link when buffered data are multicasted under SMART, we propose to retransmit packet losses caused by E L to the same destination. According to the current SCTP fast retransmit algorithm, a single missed data chunk can be retransmitted quickly on the alternative link before the retransmission timer expires. Because of the shorter loss detection time of FD compared with that of TO, the data transmission rate when recovering from E L is generally better than that from H L . The idea of "all retransmissions are sent to the same destination as their original transmissions" was first proposed by a group of researchers in University of Delaware in [37]. Here, we extend this idea to deal with different losses caused by different reasons. If a loss is detected by the TO, S M A R T is activated to multicast the buffered and new data on both primary and alternate IP addresses. If FD detects a loss, the SCTP fast retransmission mechanism is triggered and the retransmission should be sent to the same destination IP address. The later scheme is what we call the FRX. With the proposed F R X solution, during the W L A N to UMTS forced handover, the unnecessary FD retransmissions on the possibly unreachable W L A N link and long waiting delays on the UMTS link can be avoided. 4.3 The Proposed Analytical Model Same as TCP, SCTP is a window-based transport protocol that provides reliable end-to-end data communications. It performs flow control and congestion control by regulating its sending window. SCTP includes several mechanisms, among which the timeout, the slow start, the congestion avoidance and the fast retransmission can have a significant effect on the traffic pattern. The congestion window, or cwnd, is a variable maintained and dynamically updated by the data sender. It is an indication of how much more data traffic, in number of bytes or chunks, the sender can inject into the path between the sender and receiver before causing path congestions. It is noted that when the data receiver is multi-homed, the data sender needs to maintain a separate cwnd for each of the destination IP addresses of the data receiver. In this thesis, we use chunk or packet as the unit of cwnd. In recent years, some analytical models have been proposed to characterize TCP performance in terms of round-trip delay and packet loss rate. The best-known analytical models for the steady state performance of TCP [17][18] captured the essence of TCP's congestion avoidance behavior by taking into account of fast retransmissions, timeouts and the impact of window limitations. Authors of [19] examined experimentally the application of TCP analytical model [17] to SCTP sources. However, the experiment results show that the model generally provide a pessimistic estimate of the throughput compared with that measured in a corresponding experiment. This is because in the TCP analytic model [17], the packet error rate p is not in fact the loss rate but the probability that a packet will be lost within a TCP "round" given that there has been no loss so far in the round. Once such a loss occurs, the remainders of packets sent in the current round are also considered to be lost. Thus, in the TCP analytical model [17], packet losses occurring in groups result in an actually higher per-packet loss rate. Other than this, there is very little work addressing the analytical modeling of SCTP. In order to theoretically analyze the SCTP performance in the W L A N to UMTS forced V H O process, in this chapter, we propose and derive an analytical SCTP performance analytical model. We consider an SCTP flow starting at time t = 0 s, for any given time r>0, the variable pkt is defined to be the number of packets successfully transmitted in the interval [0,f]. Then the throughput Thr during the interval [0, t] is defined as Thr = pkt 11. Note that pkt is the number of packets that has been SACKed. Unlike the work of [17]-[19], in calculations of the throughput, our model captures the dynamic changes of cwnd for the slow start, congestion avoidance and fast retransmission processes, and the changes of RTT with the delay in each round. The remainder of this section is organized as follows. In Section 4.3.1, we present how we model data transmissions subject to H L on the W L A N link. In Section 4.3.2, we develop an analytical model to study the data transmissions subject to E L on the UMTS link. Initial State: n = 0 cwnd = Wc Congestion Avoidance process 1S I timeout n= 1 /chunk is/ n = 0 cwnd = 1 ( g ACZ-M C W N D ~2 *sst = Wc/2\ \ **st = Well > 2 n d timeout n = 2 cwnd= 1 *sst = Wc/2 3rd timeout r Consecutive timeout for PMtfjtimes. n = PMR cwnd= 1 *sst = Wc/2 ' Consecutive forPMfl+1 timeout times n = PMR+l cwnd= 1 *sst = Wc/21 n = 0 cwnd = 2 *sst = Wc/2y chunk is SACKea"! n=0, slow start until cwnd = * sst n=0, slow start until cwnd = * sst n = 0 cwnd = 2 *sst= Wc/2^ Link becomes "Inactive" n=0, slow start until cwnd = * Sir 2 n d timeout n = 2 cwnd= 1 _ *sst- Wc/4^ 3rd timeout^ PRM^ timeout i (PRM+l)* timebut n • cwnd = 1 *sst= Wc/4S .slow start n = PM/Î PMR .Slow start Note: *sst (ssthresh) = max (current cwnd size/2, 2MTU), where MTU is the Max Transmission Unit. PMR represents Path.Max.Retrans and is a constant. n = PMR+\, cwnd = 1 *sst = Wc/4^ Link becomes "Inactive" Fig. 4-6 Transitions of cwnd size and error counter subject to H L 4.3.1 Modeling Data Transmission Subject to H L on the W L A N Link Fig. 4-6 is a state transition diagram that describes the behavior of n (error counter), cwnd (cwnd) and sst (slow start threshold (ssthresh)) on the W L A N link in the presence of HL. Wc is the current window size, PMR represents the Path.Max.Retrans, n is the value of the error counter or the times of consecutive TOs detected and n < (PMR+l). Then, RTO 2RT0 4RT0 8RT0 16RT0 32RTO l n o § § § ® 0 § <&-> 0 RTO 3RT0 7RTO 15RT0 31RT0 63RTO n=l n=2 n=3 n-4 n=5 n>5 Fig. 4-7 The relation between the error counter n and Trt0 1) In case of a timeout, all data that are in flight are marked for retransmissions: The cwnd will be set to one M T U (Message Transmission Unit), and the sst will be set to either one-half the current window size Wc or two M T U (whichever is greater). 2) If n reaches (PMR + 1), then the W L A N to UMTS forced V H O is triggered. The UMTS link becomes the primary connection. The W L A N link becomes the secondary connection and enters to the state of "Inactive". We now model the SCTP data transmission subject to H L on the W L A N link. As shown in Fig. 4-7, we define the duration of an M C staying outside of the W L A N coverage area as Trto. RTO equals to RTO m j n (one-second time) as recommended in specification. Then the throughput Thrut (in the unit of packets/second) is given by, o, XTno G (0,ls],i.e.,n<l (* + 2 ) /T; 0 , XTrto 6 (ls,3s],i.e.,ra = 2 (*+3)/r r t o, XTno e (3s,7s],i.e.,« = 3 (* + 4 ) /T; „ , XTno e (7s,15s],i.e.,n = 4 (k + 5)/Tno, e (15s,31s],i.e.,rc = 5 (k + 6)/Trlo, e (31s,63s],i.e.,n = 6 (4.1) where k is the number of packets on the way to the destination during the time from the first TO chunk dequeuing until the TO being detected. For details of the value k, please refer to Section 4.1.2. 4.3.2 Modeling Data Transmission Subject to E L on the UMTS Link Fig. 4-8 illustrates the transitions of cwnd size and probabilities on the UMTS link in the presence of EL . The definitions such as cwnd, sst, Wc, PMR and Trto are the same as in Sections 4.3.1 and 4.3.2. Besides, we set the initial value of sst to 65536 bytes (or 45 packets) with the packet size set to 1468 bytes. We define p to be the packet loss rate on the UMTS link and q = (1 - p) is the packet successful transmission rate. Then, we have: 1) When there is no packet loss, the slow start process stops when cwnd reaches 45 packets. This is because, when the cwnd equals to or is longer than the initial ssthresh, the system enters into congestion avoidance process from slow start. The SCTP congestion avoidance process continues after cwnd reaches 45. 2) In the proposed S M A R T - F R X scheme, the retransmissions of E L packets on the UMTS link are sent to the same destination address. Whenever the sender receives duplicate SACKs, the sender reduces its cwnd to one-half of the current window size, i.e., cwnd is set to be Wc/2 and sst is set to either Wc/2 or two M T U (whichever is greater). Before application of the SMART-FRX, since H L on the W L A N link dominates the SCTP performance, we ignore any E L that may happen on both the W L A N and UMTS links. Then, we can obtain the system throughput from equation (4.1). After S M A R T - F R X is applied, the UMTS link enters into slow start during 1 s < T r t 0 < 63 s. In this case, E L on the UMTS link may dominate the SCTP performance and cannot be ignored. To develop an analytical model to study the SCTP performance on the UMTS link with EL, we assume that packet losses happen only in the direction from the sender to the receiver. We model SCTP behavior in terms of "rounds", where a round starts when the sender begins the transmission of a window of packets and ends when the sender receives the last acknowledgement for packets in this window. The duration of a round is a function of window size cwnd. SCTP essentially doubles its window size for slow start stage and increases the cwnd size linearly for congestion avoidance stage if none of the packets in the previous window gets lost during the previous RTT. If there were one or more than one packet in the previous window that were lost, the window size is set to half of the current window size. We use a recursive function to calculate the SCTP throughput at the z'-th round. We use arrays cwnd(i) and qq(i) to denote the congestion window sizes and the packet successful transmission probabilities after the /-th round, respectively. We use the variables pkt(i) and RTT(i) to denote the accumulative number of successful packet transmissions and the accumulative RTT until the i-th round, respectively. Assuming that we already know the following parameters: the network propagation delay is a constant given by delay, the chunk size is given by Chunk_size, the data S A C K chunk size is given by SACK_size, the data transmission rate is txmnjrate and the loss rate is p. The transitions of the array cwnd(i) and qq(i) are illustrated in Fig. 4-8. 1) Before the data transmission starts, i.e., / = 0, there is only one element in cwnd(i) and qq(i). Since the initial cwnd size is 2 as specified in [11], we set the following initial values: cwnd(0) = (2), and qq(0) = (1). stands for cwnd size = x Fig. 4-8 Transitions of cwnd size and probability subject to E L 2) During the 1st round of data transmissions , we have a) The number of successful packet transmissions in the 1st round is given by, pkt(l) = cwnd(0) xqx qq(0) = 2q. b) The RTT of the 1st round data transmission is, RTT(1)= rtt(cwnd(0)) x qq(0) + delay = rtt(2) + delay, where rtt is a function of cwnd, which is the round trip time for cwnd packets transmission without delay,given by, rtt (cwnd) [cwnd • Chunk _ size + (cwnd 12) • SACK _ size] txmn rate (4.2) 3) After the 1st round, the round index / increases to 1, the arrays cwnd(0) and qq(0) are split into two elements. If all the packets in cwnd(0) are successfully transmitted, cwnd size becomes cwnd(0)x2 = 4, for slow start. If there is one or more than one packet loss, cwnd size becomes half of the current window size, i.e., cwnd(Qi)ll = 1. Since the current window size is 2, the probability that cwnd size transits from 2 to 4 is qcwnd{0) = g 2; the probability that cwnd size transits from 2 to 1 is 1 - qcwnm = 1 - q\ That is, cwnd(\) = (cwnd(0)x2 cwnd(0)x0.5) = (4 1), and qqiX) = (qq{Q)xqcwnm qq(0)x(l-qcwnd(0))) = (q2 \-q2) 4) During the second round of data transmissions, we have a) The number of accumulative successful packet transmissions until the second round is given by, pkt(2) = pkt(\) + number of successful packet transmissions at the 2nd round = pkt(l) + cwnd(\) xqx qq(l)T = 2q + 4q x q2 + Iq x (l-q2) = 3q3 + 3q b) The accumulative RTT until the 2nd round is given by, 7\7T(2) = RTT(i) + the round trip time of the 2nd round = RTT{\) + rtt(cwnd(\) x qq(l)T + delay = RTT(l) + m(4) x q2 + rtt{\) x (\-q) + delay We apply (4.2) to this expression and get, RTT(2) = rtt(3) + r»(3) q2 + Idelay. 5) After the 2nd round, the round index i increases to 2, the arrays cwnd(Y) and qq(\) are split into four elements. They are cwnd(2)= (4x2 4/2 1+1 [l/2~|) = (8 2 2 1), and qq(2) = (q2xq4 q2x(\-q) (\-q2)*q (\-q2)x{\-q)) = (q6 q2-q6 q-q3 \~q~qW) 6) During the 3rd round of data transmissions, we have a) The number of accumulative successful packet transmissions until the second round is given by, pkt(3) = pkt(2) + number of successful packet transmissions at the 3rd round = pkt(2) + cwnd(2) xqx qq(2)T b) The accumulative RTT until the 3rd round is given by, RTT(3) = RTT(2)+ the round trip time of 3rd round = RTT(2) + rtt(cwnd(2)) x qq(2)T + delay After the (i-l)-th round, the round index increases to (i-l). As a result of the calculations in round ( M ) , we get the value of variable pkl{i~\) and RTT{i-\), and arrays cwnd(i-\) and qq{i-\). During the z'-th round, we have, a) The number of accumulative successful packet transmissions until the z'-th round is, pkt(i) = pkt(i-l) + number of successful packet transmissions at the z'-th round T = pkt(i-l) + cwnd(i-l) xqx qq(i-Y) , b) The accumulative RTT until the z'-th round is, RTT(i) = RTT{i-\)+ the round trip time of the z'-th round = RTT(i-\) + rtt(cwnd(i-\)) x qq{i-\f + delay After the z'-th round, the 2 ( , _ 1 ) elements in the arrays cwnd{i-\) and qq(i-\) are split into 2' elements for cwnd(i) and qq(i), as illustrated in Fig. 4-8. For any cwnd size cwnd with transition probability value of qq in (z'-l)-th, qq splits to qqxqcwnd and qqx(l-qcwnd) in z'-th round; cwnd splits to {cwndxl) (for slow start) or to (cwnd+1) (for congestion avoidance) and cwnd/2 in z'-th round. We have, a) The number of accumulative successful packet transmissions until the (z'+l)-th round is, pkt(i+l) = pkt(i) + number of successful packet transmissions at the (z'+l)-th round = pkt(i) + cwnd(i) xqx qq(i) , b) The accumulative RTT until the (z'+l)-th round is, RTT((i+l) = RTT(i)+ the round trip time of the (z'+l)-th round = RTT(i) + rtt{cwnd{i)) x qq(i)T + delay We repeat this recursive function until a predefined round r is reached. Then, at the end of r-th round, the expected throughput throughput(p,r) is equal to the cumulative number of successful packet transmissions pkt{r) divided by the cumulative time taken RTT(r), i.e., throughput(p,r)= pkt(r)/RTT(r), if r is the final round number. In summary, given initial congestion window size cwnd(0), loss rate p, propagation delay, chunk and S A C K size, data transmission rate and ssthresh, we are able to calculate the link throughput until the certain round. Fig. 4-9 Combine the nodes with the same cwnd in the same round However, in this algorithm, for r-th round, there are 2r elements in the arrays cwnd(r) and qq(f). Therefore, the computation work load increases exponentially with r. We propose to combine the nodes with the same cwnd size in the same round together, so that the algorithm can be improved while preserving the accuracy of the results. Fig. 4-9 illustrates this method. At the end of the second round, we combine the nodes of cwnd 2 together. After the combination, At the end of the second round, the array cwnd(2) = (8 2 6 2 3 6 1) instead of before the combination (8 2 2 1); the array qq(2) - (q q+q —q -q l~q-q2+q3) instead of [cf q2-q6 q-q3 i-q-q2+q3). In this way, the number of elements in the arrays cwnd{i) and qq(i) are constrained to increase closely linearly instead of exponentially with increasing round number i. This method makes it possible to calculate the throughput for large number of rounds. Chapter 5 Simulation Results and Discussions In this chapter, we describe the simulation methodology in Section 5.1. We present and discuss the simulation results in Section 5.2. 5.1 Simulat ion Methodology We evaluate our proposed MSCTP-based U M T S / W L A N VHO, S M A R T - F R X scheme and validate the developed analytical model using the ns-2 network simulator [15] with the SCTP module [16] developed by the Protocol Engineering Lab at the University of Delaware. The simulation work consists of the following steps: 1) Design and implement the proposed schemes, set up the simulation configuration. 2) Design the simulation study, and select the performance metrics used to evaluate the simulation results. 3) Perform the simulations and verification tests. 4) Analyze and verify the simulation results by evaluating and comparing different scenarios and different parameter settings. In this section, we explain the simulation methodology in details. We give a brief overview of our simulation and computation tools, ns-2, its SCTP module, and Matlab in Section 5.1.1. Section 5.1.2 presents the design and implementation on the simulation model of MSCTP-based VHO. Section 5.1.3 describes the implementation of the proposed S M A R T - F R X scheme. In Section 5.1.4, we present the algorithm that we develop to implement the analytical model on Matlab. We describe the ns-2 experimental setting used to verify the proposed analytical model in this section too. 5.1.1 Overview of Simulation Tools Network Simulator - ns-2 [15], which is available on several platforms such as FreeBSD, Linux, SunOS, Solaris and Windows, is an object-oriented, discrete event driven network simulator targeted at computer networking and protocol research. It has become one of the most popular research tools in the networking area. Ns-2 provides substantial capabilities from graphically dealing with network traffic to simulation of routing, multicast and other IP protocols. It is an open-source simulation tool primarily useful for simulating local and wide area networks. It includes implementation of network protocols such as TCP, UDP, SCTP over wired and wireless (local and satellite) networks, traffic source behaviors such as FTP (File Transfer Protocol), TELNET (TCP/IP Terminal Emulation Protocol) and HTTP (Hypertext Transfer Protocol), queuing algorithms including fair queuing, RR (round-robin) and FIFO (First In First Out), router queue management mechanisms, and routing algorithms, etc. Its advantages have made it a useful tool that can be used extensively in network simulations. The ns-2 SCTP module [16] developed by the Protocol Engineering Lab at the University of Delaware currently supports the core features in [11] and [29]. These features with the referenced section numbers in [29] are summarized in Table 5-1. The SCTP agent establishes an association using a four-way handshake, but the handshake process is kept simple and does not strictly conform to the specification. For example, the handshake does not update RTT. Instead, RTT estimation begins with the first data Table 5-1 Features included in existing ns-2 SCTP module [39] Section in Feature description 5.1 Normal establishment of an association 6.1 Transmission data chunks 6.2 Acknowledgement of reception of data chunks 6.3 Management retransmission timer 6.4 Multi-homed SCTP endpoints 6.5 Stream identifier and stream sequence number 6.6 Ordered and unordered delivery 6.7 Report gaps in received data TSNs 7.2 SCTP slow-start and congestion avoidance 8.1 Endpoint failure detection 8.2 Path failure detection 8.3 H E A R T B E A T function without upper layer control chunk. SCTP packets generated by the SCTP agent and destined to a peer SCTP agent over a traced link generate a trace file. Matlab is an interactive program for numerical computation and data visualization; it is used extensively for analysis and design in research and engineering. We use the Matlab 6.5 to analyze and display the simulation results graphically. We implement our analytical model with the Matlab and validate the analytical model against ns-2 simulations. (a) FS is in the single-homing configuration Multi-homed Mobile Client (MC) node (b) FS is in the dual-homing configuration Multi-homed Mobile Client (MC) node Fig. 5-1 MSCTP-based VHO configurations 5.1.2 The Simulation Model of UMTS/WLAN VHO Using MSCTP The simulation configuration to test MSCTP-based U M T S / W L A N V H O is shown in Fig. 5-1. Fig. 5-1(a) shows the single-homing configuration and Fig. 5-1(b) shows the dual-homing configuration. Due to limitations of ns-2's architecture, a node cannot actually be multi-homed. To get around this limitation, each multi-homed node is actually made up of more than one nodes. As shown in Fig. 5-l(a) and (b), a multi-homed node has a "core node" and multiple "interface nodes" to simulate the interfaces. The SCTP agent resides in all the nodes, but traffic only goes to and from the interface nodes. The core node is used for routing and is connected to each interface node via a uni-directional link towards the interface node, but traffic does not traverse this link. Instead, these links are used to dynamically determine which outgoing interface node to use for sending to a particular destination. The SCTP agents are two-way agents, which means that they are symmetric in the sense that they represent both a sender and a receiver. MSCTP is SCTP with implementation of D A R [31]. It is an optional extension that is introduced to provide SCTP with the ability to reconfigure IP address information on an existing association. In details, the functions of D A R are: 1) A graceful method to add or delete interfaces or IP addresses to an existing association; and 2) A method for an endpoint to request its peer to set the primary destination address. SCTP together with the D A R extension makes it possible that an endpoint changes its one or multiple addresses dynamically without affecting the established association. Ns-2 SCTP module [16] supports multi-homing shown in Table 5-1, but it does not support DAR. In order to perform the simulations and obtain the results reported in this thesis, we extend the SCTP module so that the multi-homing feature can work over wireless links. As shown in Fig. 5-1, a multi-homed M C actually consists of two M C _ i f nodes that perform as the two interfaces of the M C , and an MC_core node that is a wired node and performs as a control part of the M C to determine the packet route. A l l these nodes are connected to SCTP agent to trigger SCTP traffic as the source and handle the incoming SCTP traffic as the destination. The design of the M C _ i f node is based on the nodes called MobileNode and BaseSation in the current ns-2 wireless communication module. The existing MIPBSAgent and MIPMHAgent are modified to support a new type of routing ASCONF Module ASCONF ASCONF Module A S C O N F _ A C K M C < User Data > FS Sender Receiver Fig. 5-2 M C and FS interaction with ASCONF and A S C O N F _ A C K chunks agent called Non-Ad-Hoc routing agent (NOAH) [40]. After introducing this new agent, the M C _ i f interface nodes act as the SCTP traffic source that can be controlled by the MC_core node. The ns-2 IEEE 802.11 W L A N module is used to support the M A C (Medium Access Control) layer. The bandwidths (data transmission rates) are set to be 384 Kbps for the UMTS link and 2 Mbps for the W L A N link. We implement two new messages that have the same functions as ASCONF and A S C O N F _ A C K chunks so that we can add or delete an IP address dynamically into or from the current active association. Fig. 5-2 shows the communication between the M C and FS endpoints with the ASCONF and A S C O N F _ A C K chunks. As the address reconfiguration requester, the M C creates an ASCONF chunk with a parameter of "Add" or "Delete" or "Set Primary Address". When the endpoint FS receives an ASCONF chunk from the remote M C peer, the processing of the ASCONF chunk begins: • If the Address Parameter in the ASCONF chunk is "Add" or "Delete", the specified address is added to or deleted from the destination list on the FS. • If the Address Parameter in the ASCONF chunk is "Set Primary Address", the specified address in the chunk is set to be the primary address by FS. With the implementation of the MSCTP function in the test network, after an SCTP association is initiated, under the coordination of SCTP agent and routing agent, FS starts to send FTP traffic to M C on the primary link. In the test network, we set the network propagation delay to be 120 ms, chunk size to be 1468 bytes, M T U to be 1500 bytes. We set the sending queue limits and the receiver window size to be large enough to ensure that they do not interfere the SCTP performance during a VHO. We initiate an association between the FS and M C endpoints at 0 s and trigger the FTP traffic on the primary W L A N (or UMTS) link from the FS to the M C at 1 s. To measure the MSCTP supporting V H O performance, we trigger a V H O at 5 s so that an ASCONF message is sent from the M C to request to switch the primary link to the secondary link. We record the TSN for each of the data chunks and monitor the overall throughput on both links at the receiver M C endpoint. The overall throughput is defined as the total number of distinct data chunks received from both links divided by the total elapsed time. We measure and analyze the VHO delay and the throughput at M C for the single-homing and the dual-homing configurations, and study the impact of different configurations on the VHO performance. 5.1.3 Implementation of SMART-FRX Fig. 5-3 shows the implementation architecture of SCTP. The SCTP instance module is composed of two basic functions: the SCTP sending function and the SCTP receiving function. Both these functions are implemented in the SCTP Agent. Above the sending module is the possible applications that use the services provided by SCTP such as FTP, TELNET, HTTP, etc. The SCTP data transmission mechanisms, retransmission Application (FTP, HTTP, etc.) SCTP Agent output (sending packet) Z SCTP Agent input (receiving SACK) Retxmn processing S M A R T - F R X , SCTP Agent input (receiving packet) SCTP Agent output (sending SACK) SCTP sending function SCTP receiving function Fig. 5-3 Implementation architecture of SCTP timers and timeout processes are part of the sending function. The SCTP specification does not allow a sender to multicast data on multiple paths. An SCTP sender maintains a primary destination to which all new data are sent. Only retransmissions are sent to the alternate destinations. However, we have seen that this mechanism is not suitable in the W L A N to UMTS forced VHO situation when there are consecutive packet losses and timeouts due to HL. This is the motivation behind the proposed S M A R T - F R X scheme. To implement the proposed Sending-buffer Multicast Aided Retransmission (SMART-FRX) scheme, we assume that: • Multiple (usually two) independent paths exist between the M C and the FS. • Receiver's advertised window (rwnd) at receiver side (the MC) is large enough not to constrain the sender. • There is no queue length limitation for the sending-buffers of both W L A N and UMTS links. These assumptions enable us to study the changes in cwnd at the sender, the cmTSN (cumulative TSN) and the TSN Gaps in S A C K [29] and other congestion control parameters independently for each destination. The S M A R T - F R X module is implemented in the retransmission processing module of the SCTP implementation architecture shown in Fig. 5-3. The entry point to activate the S M A R T - F R X module is that the W L A N link encounters a transmission TO that is marked by the W L A N error counter n being set to one. Without the S M A R T - F R X scheme, new traffic is always queued on the primary link and only the retransmitted data are queued on the secondary link. The S M A R T - F R X module enables the function that once the sender detects the W L A N link entering a possibly unreachable period, the sender copies the data in the sending buffer of the primary connection over the W L A N link to that of the secondary connection over the UMTS link, and enqueues new data chunks in both sending-buffers. Thus, the buffered data as well as any new data are able to multicast on both the primary and secondary links during the W L A N possibly unreachable period. Though the bandwidth of both links are different, the multicasting increases the data-sending rate that would have been reduced because of TO process on the primary connection. On the other hand, at anytime, if there is any packet loss detected by FD on the UMTS link, the retransmission is forced to be sent to the same destination. When the W L A N link possibly unreachable period ends, which is determined by either the W L A N link error counter n resetting to zero or reaching Path.Max.Retrans, the sender enqueues new data chunks to the current primary link only. Handover loss 2 Mbps primary link (WLAN) S M A R T - F R X 384 Kbps secondary link (UMTS) Error loss Fig. 5-4 S M A R T - F R X simulation configuration The simulation configuration to verify the effectiveness of the S M A R T - F R X scheme is shown in Fig. 5-4. Two packet-drop modules are inserted to the W L A N and the UMTS links, respectively. The parameters of the network propagation delay, the chunk size and the M T U size are set to be the same as that of Section 5.1.2. On the W L A N link, the packet-drop module drops consecutive packets so that the W L A N link encounters a TO and the error counter n becomes 1,2,...6 (Path.Max.Retrans), respectively. We monitor the TSN of each data chunks and the throughput performance for each the error counter value at the receiver with and without application of the S M A R T - F R X schemes. In order to make sure the correctness of the results, each scenario is tested for 10 times. We compare the delay and the throughput performance with and without the proposed scheme to ensure the effectiveness of the proposed scheme. 5.1.4 Validation of Analytical Model In Chapter 4, we developed an analytical model in order to study the throughput performance on the UMTS link with E L when the W L A N link is in possibly unreachable period. In this chapter, we use ns-2 to validate this analytical model. The pseudo code to implement the algorithm on Matlab 6.5 is attached as Appendix A. The simulation configuration on ns-2 is shown in Fig. 5-4. The simulation is with the S M A R T - F R X implemented. The implementation of the error loss module on the UMTS link would be critical to the relevance of any results obtained from the experimental set-up. We use the random loss error model in ns-2 to simulate the transmission of fixed size packets over a fading channel. The parameters of packet transmission error rates Pe are given by 0, 0.01.0.025, 0.05, 0.075, 0.1 and 0.11. For each of the packet loss rate, we run the simulation for 10 times and calculate the average throughput to observe and plot the relationship between the throughput and the packet loss rates. We change the test scenario by setting different network propagation delays as 0 ms, 50 ms, 120 ms, 150 ms, 250 ms and 400 ms. The experimental results are compared with the analytical predictions generated by the Matlab. The average error is given by: I throughputnnalytical - throughput simulation I A/simulations throughput • , ,. Erroravg = „ . ' (5 • 1 ) number of simulations The average error shows the mean difference between the analytical results and the simulation results. A smaller average error indicates a better model accuracy. In this way, the accuracy of the analytical model can be validated. 5.2 Results and Discussions We show our simulation results in this section. We analyze, compare and verify the simulation results with different scenarios and parameter settings. The objectives of the simulations are to evaluate the performance of our proposed schemes and validate the developed analytical model. In Section 5.2.1 we study the simulation results of the MSCTP-based U M T S / W L A N unforced VHO scheme. We analyze two critical parameters, the U M T S / W L A N VHO delay and the throughput for both FS in single-homing and dual-homing configurations. In Section 5.2.2, we observe the W L A N link TO and the UMTS link retransmission situation when a mobile user leaves the W L A N coverage and triggers a forced W L A N to UMTS VHO. We illustrate and compare the throughput performance before and after application of the S M A R T - F R X scheme and show the effectiveness of this scheme. Finally, in Section 5.2.3, we show the results of using ns-2 random loss error model to validate and verify the developed analytical model. 5.2.1 UMTS/WLAN Unforced VHO In this experiment, the bandwidth between the M C and the FS endpoints are set to be 384 Kbps for the UMTS link and 2 Mbps for the W L A N link. The network propagation delay is set to 100 ms. FTP traffic is triggered from M C at time 1 s. V H O Triggering process is activated at time 5 s. Data transmission is from M C to FS. Figs. 5-5 and 5-6 show the delay performance for the V H O from UMTS to W L A N and for the reverse direction, respectively. For FS in single-homing configuration, we define the VHO delay as the time difference between FS receives the first packet on the new primary link and the last packet on the old primary link. For FS in dual-homing configuration, assuming the first packet received by FS is TSN first, the V H O delay is defined as the time difference between FS receives TSN first on both links. According to the simulation results, when the FS is in the single-homing configuration, the UMTS to W L A N handover delay is 533 ms in Fig. 5-5(a) and W L A N to UMTS handover delay is 513 ms in Fig. 5-6(a). When FS is in the dual-homing configuration, these two handover delays are reduced to 234 ms in Fig. 5-5(b) and 212 ms in Fig. 5-6(b), respectively. This is because when the FS is in the single-homing configuration, the M C sends a "Set Primary Address" request to trigger a handover, thus increasing the overall delay with a handshake processing time. However, when the FS is in the dual-homing configuration, the M C can trigger a handover by directly setting the FS's secondary address. Therefore the handover delays in both directions are reduced significantly. Fig. 5-7 shows the throughput performance for V H O in both directions. We can see that the throughput (number of bits received/time) of FS in dual-homing configuration is much higher than that of FS in the single-homing configuration. This is because, besides the delay advantage, a dual-homing FS allows both M C and FS to operate in a symmetric multi-homed configuration. This configuration enables easy distinction of the two paths between the M C and the FS, so that the redundant path can help to provide the fault tolerance to the data transmissions during handover. In the simulations, the buffered data are sent at both old and new connections when a changeover occurs. In this way, packet loss and retransmission delay can be avoided. Duplicate packets can be dropped by the receiver, and different strategies may be employed by the sender and receiver to adapt flow, congestion and other QoS control parameters easily and quickly during and after the handover. In Fig. 5-7, we also observe that SCTP readily copes with the sudden change of the link bandwidth during a handover. 5.2.2 SMART-FRX Scheme The objective of these simulations is to evaluate the potential performance improvement of the proposed S M A R T - F R X scheme. We show the effectiveness of the proposed scheme by comparing the throughput performance with and without the (a) FS is in the single-homing configuration 600 Time (Second) (b) FS is in the dual-homing configuration 600 Time (Second) Fig. 5-5 Delay performance of the proposed V H O scheme (from UMTS to W L A N ) (a) FS is in the single-homing configuration 600 r 500 • 400 • CD E 3 CD O c CD of 300 { CO c o CO .22 200 r E C/J c CO Packets on WLAN link 100 Packets on UMTS link Handover time 4 5 Time (Second) (b) FS is in the dual-homing configuration 600 r E 3 O c CD 3 8" 300 r w c g '« .<2 200-E 05 e CO 100-Packets on UMTS link Packets on WLAN link 4 5 6 Time (Second) Fig. 5-6 Delay performance of the proposed V H O scheme (from W L A N to UMTS) (a) Handover from UMTS to W L A N Time (Second) (b) Handover from W L A N to UMTS Time (Second) Fig. 5-7 Throughput performance of the proposed vertical handover scheme proposed scheme. The configuration used in this simulation is a dual-homing configuration as shown in Fig 5-4. The threshold Path.Max.Retrans is set to 5 as specified in the SCTP standard. The other parameters are set as the following: RTO on W L A N link is 1 s, M T U is 1500 bytes, data chunk size is 1468 bytes, and the network propagation delay is 120 ms. Figs 5-8 to 5-11 show the received TSNs on both W L A N and UMTS links, and the throughput comparison with and without the proposed scheme. In each of the figure, (a) shows the received TSNs without the S M A R T - F R X scheme; (b) shows the received TSNs with the scheme; and (c) compares the throughput with and without the proposed scheme. The throughput is defined as the total number of bits received at the receiver divided by the total time elapsed. As shown by (a) and (b) in all these figures, at the beginning, the data traffic is on the primary W L A N link. We drop a block of chunks from TSN 214 to 260 on the W L A N link at time 3.9 s, so that the error counter on this link can be set to 1. After about 1 s, i.e., at about 4.95 s, the TO of TSN 214 is detected. Then, on the W L A N link, the cwnd size becomes 1, the T3-rtx increases to two RTO, i.e., 2 s, and the link enters into a failure detection period. Immediately after the error counter becomes to non-zero, TSN 214 to 260 are retransmitted on the alternative UMTS link. At the same time, on the W L A N link, with the new T3-rtx and the new cwnd value, TSN 261 is sent to test if the W L A N link has recovered. If we keep on dropping the chunks from TSN 261 to 266, we can make the error counter n to be increased to 2 up to 6. According to our observations on the TSN, with and without SMART-FRX, with the error counter increasing, data x 10 5 (c) Throughput comparison, W L A N link error counter =3 18 j . i i • r . . Time (Second) D a t a t x m n o n W L A N link D a t a t x m n o n U M T S link L o s t c h u n k s are re t ransmi t ted o n the U M T S link i W L A N link is res tored after error c o u n t e r v 10 15 20 2 5 T i m e ( S e c o n d ) (b) W i t h S M A R T - F R X , W L A N link error c o u n t e r =4 D a t a t x m n o n W L A N link D a t a t x m n o n U M T S link S l o w start d a t a t r a n s m i s s i o n o n U M T S link W L A N link is res to red at ler error c o u n t e r ----4 15 20 25 T i m e ( S e c o n d ) x 1 0 5 ( c ) Throughput c o m p a r i s o n , W L A N link error c o u n t e r =4 16r ' ' —i—; ' 1 1 T i m e ( S e c o n d ) 4 0 0 0 O 10 20 3 0 4 0 SO 6 0 Time (Second) (c) Throughput comparison, W L A N link error counter =5 Time (Second) Data txmn on W L A N link Data txmn on UMTS link Once W L A N link error counter exceeds Path. Max. Retrans=5, UMTS link becomes primary Ii W L A N link becomes inactive. I J Lost chunks are retransmitted on UMTS link 30 40 50 (Time (Second) (b) With SMART-FRX, W L A N error counter =6 Data txmn on W L A N link Data txmn on UMTS link - Slow start data transmission on UMTS link At the time =69.5s, UMTS link becomes primary link and continues with the data transmission. W L A N link becomes inactive. 30 40 50 Time (Second) x 10 5 (c) Throughput comparison, W L A N link error counter =6 Without S M A R T - F R X With SMART-FRX transmissions on the W L A N link become disrupted until either of the following happens, 1) A S A C K over W L A N link is received at the sender before the W L A N error counter n exceeds the Path.Max,Retrans. In this case, the error counter n resets to 0, the W L A N link enters into slow start and the traffic falls back to the W L A N link. Figs. 5-8 to 5-10 show the SCTP data transmission situation for this case. 2) The W L A N error counter n exceeds the Path.Max.Retrans. In this case, data transmissions are switched to the new primary link, the UMTS link. Fig. 5-11 shows SCTP data transmission situation for this case. As shown in Figs. 5-8 (c) to 5-11 (c), S M A R T - F R X does make difference on the throughput performance for n = 3 to 6: • Without SMART-RFX, due to the backoffs on the W L A N link, the secondary UMTS link is always waiting for data from the W L A N link for retransmission. The stop-and-wait on the W L A N link affects the utilization of the secondary link. • When the S M A R T - F R X is applied, the sender is able to multicast the buffered data on both the W L A N and UMTS links. Therefore, the UMTS link can enter into a slow start data transmissions process instead of a stop-and-wait process following with the W L A N link. Contrary to a sudden drop of the overall throughput, the overall throughput can be increased significantly because the UMTS link becomes much more aggressive. Figs. 5-8 (c) to 5-11 (c) show the throughput quickly converges to the UMTS data rate 384 Kbps with SMART-F R X . Figs. 5-8 to 5-11 also show that the larger the error counter n becomes, which means the longer time the M C staying outside of W L A N coverage, the more obvious the effectiveness of the S M A R T - F R X scheme. In Fig. 5-11, for both cases with and without SMART-FRX, when the W L A N link error counter n exceeds the Path.Max.Retrans at the time of 69.86475 s, the W L A N link is switched to be from "Active" state to "Inactive" state. A forced changeover makes the UMTS become the primary connection and data are only queued on the new primary link for transmission. From our simulations, we also notice that the S M A R T - F R X has no effect for n=l and 2. The throughput performance with and without S M A R T - F R X are similar. This is because the transmission rate of the W L A N link is much higher than that of the UMTS link. Therefore, when the first block of data TSN 214 to 260 are retransmitted on the UMTS link, the data transmission needs more time than that over the W L A N link. When the error counter is small, the W L A N link is restored before the UMTS link finishes the data transmission for TSN 214 to 260. Therefore, the throughput with and without the S M A R T - F R X scheme are the same. 5.2.3 Comparison with Analytical Results In order to validate the proposed analytical model, we focus our performance study on the UMTS link. We firstly compare the throughput performance predicted by the developed analytical model with that of simulation results when there is no E L on the UMTS link. Figs. 5-12 to 5-13 show this comparison for the cases with and without the S M A R T - F R X scheme. We count the beginning of the W L A N possibly unreachable period as the beginning of the time-axis. Then, the UMTS link starts to retransmit data at the time of 1 s (the RTO of the W L A N link is set to be 1 s). Y-axis is the throughput defined as the total number of chunks SACKed at the sender being divided by the total time elapsed. According to the analysis in Chapter 4, the W L A N link takes a total of 63 s to detect a link failure, i.e., the W L A N link error counter n increases to 6. As shown in Fig. 5-12, we see that, without the S M A R T - F R X scheme, both simulation results and analytical model predictions show the throughput dropping at the time that the W L A N link error counter n becomes 2. With SMART-FRX, Fig. 5-13 shows the data transmissions on the UMTS link with the W L A N error counter n increases the Path.Max.Retrans. We see that with the error counter increasing, instead of dropping during the link failure detection period, the throughput value from both the analytical model and simulations converge to the maximum data rate of the UMTS link (384 Kbps or 32 packets per second). We can see that for both cases of with and without the S M A R T - R F X scheme, the analysis results match the simulation results fairly well in all the tests. We have compared the analytical and the simulation results without E L on the UMTS link. We now consider the affects of E L on the accuracy of the analytical predictions. The following validation test is with the S M A R T - F R X implemented. As shown in Fig. 5-4, we employ a random loss error model to simulate E L on the UMTS link. Note that the results of both the analytical model and the simulation are based on normal operating conditions with a negligible probability of both W L A N and UMTS links falling into TO retransmission at the same time. In each figure of Figs. 5-14 to 5-19, we show the throughput comparison by the analysis and by the simulation over different Simu la t i on 0 10 20 30 40 50 60 T i m e (Second) Fig. 5-12 Comparison of analysis and simulation results (without SMART-FRX) 0 10 20 30 40 50 60 T ime (Second) Fig. 5-13 Comparison of the analysis and simulation results (with SMART-FRX) (a) Delay=Oms 0 0.02 0.04 0.06 0.08 0.1 Packet loss rate Fig. 5-14 Throughput vs. packet loss rate of UMTS link (Delay = 0 ms) (b) Delay=50ms Packet loss rate Fig. 5-16 Throughput vs. packet loss rate of UMTS link (Delay = 120 ms) (d) Delay=150ms a- Model ,1 i i i . i L_ 0 0.02 0.04 0.06 0.08 0.1 Packet loss rate 0.02 0.04 0.06 Packet loss rate 0.08 0.1 Fig. 5-18 Throughput vs. packet loss rate of UMTS link (Delay = 250 ms) (f) Delay=400ms B Model -©- Simulation 0 0.02 0.04 0.06 0.08 0.1 Packet loss rate packet loss rates from 0 to 0.11. From Figs. 5-14 to 5-19, different delays from 0 ms to 400 ms are applied in the tests. On all these plots, we see that the predictions given by the analytical model are quite closely matched to the simulation results, and there is in general a good agreement between the theoretical model and simulations. By comparing each figure with different delay settings, we see that the model predictions are more accurate as loss rates and network delays increase. The average error, which is calculated by equation (5.1), is about 4.98% for 10 simulation runs. This is not a significant level of error when an analytical model is used to predict the performance of transport layer protocols. In fact, with the loss rate and network delay increasing, the RTT would increase dramatically as the throughput approaches the capacity of the link. The analytical model takes into account of this factor and therefore can provide a fairly accurate prediction. Chapter 6 Conclusions In this thesis, a new method to support the U M T S / W L A N V H O using MSCTP has been proposed. We have studied different scenarios employing the single-homing and the dual-homing FS to support VHO. Our simulation results showed that the delay and the throughput performance could be improved significantly using the dual homing configuration. In the dual homing configuration, the duplicate transmissions of buffered data over both old and new paths can help the receiver and sender to adapt easily and quickly to a sudden change of link characteristics during and after a vertical handover. SCTP the dual-homing configuration readily copes with the sudden change of the link bandwidth. Under the current SCTP implementation, the SCTP congestion control causes significant throughput deteriorations when applied to wireless link with error losses. It misinterprets packet losses as indications of network congestions. In order to improve the low throughput performance problem during the W L A N to UMTS forced handover, we have proposed the S M A R T - F R X scheme to forced the UMTS link to engage in the slow start once the sender experiences the first timeout, and fast retransmissions over the UMTS link to the UMTS destination IP address. Because of the data multicasting on both UMTS and W L A N links during the W L A N possibly unreachable period, the throughput can be increased significantly. We have presented simulation results to validate this claim. Moreover, we have developed a new analytical model to study the performance of SCTP during a W L A N to UMTS forced VHO. By comparing the numerical results for the analytical model with simulation results, we demonstrate that our model is able to accurately predict SCTP throughput. The analytical model provides a useful tool to estimate of the SCTP throughput. We summarize our main contributions in this thesis as the following: • We have proposed a SCTP-based handover management scheme to support U M T S / W L A N integration and given an implementation of mobile SCTP (MSCTP) using ns-2. • In order to develop the U M T S / W L A N bi-directional V H O procedures, we have proposed to use SCTP bundling and unbundling message technology to simplify the handover procedures. • We have compared two possible configurations that MSCTP may employ to support VHO: the single-homing and the dual-homing configurations. Our simulation results show that using MSCTP in the dual-homing configuration gives a better delay and throughput performance than that of the single-homing configuration. • In order to improve the overall handover throughput performance, we have proposed to use a more effective queue management and retransmission scheme that we call S M A R T - F R X to assist W L A N to UMTS forced VHO. • We have implemented the S M A R T - F R X scheme in the simulation model and the simulation results show the effectiveness of the proposed scheme. • We have proposed a new analytical model to study the SCTP throughput performance on both W L A N and UMTS links during the W L A N possibly unreachable period. The accuracy of the model has been verified against simulation results over wireless links with random packet losses. In summary, SCTP is a new transport protocol with many superior features to TCP. Due to its attractive features, SCTP has been receiving more and more attention from the research community and industry. SCTP can be deployed in existing IP networks easily, because SCTP open source implementations are readily available. We believe that SCTP is not only a promising solution to support mobility in the next generation IP network, but also a good candidate for U M T S / W L A N integration. Our proposed methods are not limited to support mobility between UMTS and W L A N , but they can be applied to other inter-system handover processes as well. Not withstanding the above, some problems need further investigations: • Both WLAN and UMTS Links in TO Retransmissions: Considering the possibility that both W L A N and UMTS links fall into TO retransmissions during a VHO, is there any room to further reduce the data transmission delay and increase the throughput performance? • More Realistic Traffic to Validate the Analytical Model: In future work, it is hoped to extend the applicability of the developed analytical model to the traffic in real MSCTP supporting U M T S / W L A N VHO networks, so that the accuracy of the analytical model predication can be further verified. Bibliography [I] ETSI, "3GPP General Packet Radio Service (GPRS) Service description (Stage 2), TS 23.060, Version 3.12.0 Release 1999," www.3gpp.org, ETSI 2002. [2] "IEEE Standard for Wireless L A N M A C and P H Y Specifications," PDF: ISBN 0-7381-1812-5, Jan. 2000. [3] R. Becher, et al., "Broadband wireless access and future communication networks," in Proc. of the IEEE, vol. 89, no. 1, pp. 58-75, Jan. 2001. [4] C. Perkins, "EP mobility support," RFC2002, Oct. 1996. [5] M . Moh, G. Berquin, and Y . Chen, "Mobile EP telephony: mobility support of SEP," in Proc. of IEEE Computer Commun, and Networks, Oct. 1999. [6] V . Madisetti and A. Argyrious, "Transport layer QoS management for wireless multimedia services," www.soft-networks.com/vkm-vomo.pdf, Sept. 2002. [7] J. H . Saltzer, D. P. Reed, and D. D. Clark, "End-to-end arguments in system design," ACM Trans, on Comp. Sys., vol. 2, no. 4, pp. 277-288, Nov. 1984. [8] A . Jungmaier, M . Schopp, and M . Tuxen, "Performance Evaluation of the SCTP," in Proc. of IEEE ICATM 2000 Conf. on High Performance Switching and Routing, Jun. 2000. [9] R. Stewart and C. Metz, "SCTP: new transport protocol for TCP/IP," in IEEE Internet Computing, vol. 5, no. 6, pp. 64-69, Nov. 2001. [10] L . One and J. Yoakum, "An introduction to the Stream Control Transmission Protocol (SCTP)," RFC 3286, May 2002. [II] R. Stewart and Q. Xie, "Stream Control Transmission Protocol," EETF RFC 2960, Oct. 2001. [12] M . Riegel and M . Tuexen, "Mobile SCTP," draft-riegel-tuexen-mobile-sctp-03.txt, Aug. 2003, work in progress. [13] S. J. Koh, M . J. Lee, M . Riegel, L. Ma, and M . Tuexen, "Mobile SCTP for Transport Layer Mobility," draft-sjkoh-sctp-mobility-03.txt, Feb. 2004, work in progress. [14] L . Ma, F. Yu, V . C . M . Leung, and T. Randhawa, " A New Method to Support U M T S / W L A N Vertical Handover Using SCTP," in Proc. of IEEE VTC'03 Fall, Oct. 2003. [15] UC Berkeley, L B L , USB/ISI, and Xerox Pare., "Network Simulator ns-2," documentation and software, Version 2.1b8, http://www.isi.edu/nsnam/ns, 2001. [16] A . Caro and J. Iyengar, "ns-2 SCTP Module," ver. 3.4, http://pel.cis.udel.edu, Jul. 2003. [17] J. Padhye, et al, "Modeling TCP throughput: A simple model and its empirical validation," in ACM SIGCOMM'98, pp. 303-314, Vancouver, Canada, Sept. 1998. [18] N . Caidwell, S. Savage, and T. Anderson, "Modeling TCP latency," in Proc. Of IEEE INFORCOM'00, vol. 3, pp. 1742-1751, Tel Aviv, Israel, Mar. 2000. [19] R. Brennan and T. Ravier, "TCP analytic models applied to SCTP: An experimental evaluation," in Proc. of Information Technology and Telecommunications (IT&T),02, Oct. 2002. [20] ETSI, "Requirements and Architectures for Inter-working between HIPERLAN/3 and 3 r d Generation Cellular Systems," Tech. rep. ETSI TR 101 957, Aug. 2001. [21] V . K . Varma, et al, "Mobility management in integrated U M T S / W L A N networks," in Proc. ofIEEEICC'03, May 2003. [22] M . Buddhikot, et al, "Integration of 802.11 and third-generation wireless data networks," in Proc. of IEEE INFOCOM'03, Apr. 2003. [23] S. Tsao and C. Lin, "Design and evaluation of U M T S - W L A N interworking strategies," in Proc. ofVTC'02 Fall, Sept. 2002. [24] F. Teraoka, et al, "LIN6: A solution to mobility and multi-homing in IPv6," draft-teraoka-ipng-lin6-02.txt, Jun. 2003, work in progress. [25] P. Nikander and J. Arkko, "End-host mobility and multi-homing with host identity protocol," draft-nikander-hip-mm-01.txt, Dec. 2003, work in progress. [26] "Defining strategies to protect against TCP S Y N denial of service attacks," Cisco Systems, tech. memo, http://www.cisco.eom/warp/public/707/4.html, Aug. 2001. [27] A.C . Snoeren and H. Balakrishnan, "An end-to-end approach to host mobility," in Proc. of the 6th ACM/IEEE Intl. Conf. on Mobile Computing and Networking (MobiCom), Boston, M A , Aug. 2000. [28] A.C . Snoeren, H . Balakrishnan, and M . Frans Kaashoek, "Reconsidering Internet mobility," in Proc. of the 8th Workshop on Hot Topics in Operation Systems (HotOS-VIII), May 2001. [29] R. Stewart and Q. Xie. Stream Control Transmission Protocol (SCTP): A Reference Guide. Addison Wesley, New York, N Y , 2001. [30] R. Stewart, et al, "SCTP partial reliability extension," draft-stewart-tsvwg-prsctp-04.txt, May. 2003, work in progress. [31] R. Stewart, et al, "Stream Control Transmission Protocol (SCTP) dynamic address reconfiguration," draft-ietf-tsvwg-addip-sctp-07.txt, Feb. 2003, work in progress. [32] W. Xing, H. Karl, and A. Wolisz, "M-SCTP: design and prototypical implementation of an End-to-End mobility concept," in Proc. of the 5th Intl Workshop: The Internet Challenge: Technology and Applications, Berlin, Germany, Oct. 2002. [33] L . Coene, "Multi-homing issues in the SCTP," draft-coene-sctp-multihome-04.txt, Jun. 2003, work in progress. [34] S. Biaz and N . Vaidya, "Discriminating congestion losses from wireless losses using inter-arrival times at the receiver," in Proc. of IEEE Symposium ASSET'99, Mar. 1999. [35] N . Katsuhiro, et al, "New analytical model for the TCP throughput in wireless environment," in Proc. ofVTC'01 Spring, May 2001. [36] M . Allman, et al, "TCP Congestion Control," EETF RFC2581, Apr. 1999. [37] A . Caro, et al, "Retransmission policies with transport layer multihoming," in Proc. of ICON 2003, Sept. 2003. [38] S. Fu, M . Atiquzzaman, and W. Ivancic, "Evaluation of delay spike on SCTP, TCP Reno, and Eifel in a wireless mobile environment," in Proc. of Intl. Conf. on Computer Communications and Networks, pp. 575-578, Miami, FL , Oct. 2002. [39] R. Stewart, et al, "Stream Control Transmission Protocol (SCTP) Implementer's Guide," draft-ietf-tsvwg-sctpimpguide-10.txt, Nov. 2003, work in progress. [40] Daimler Chryler Research, "Extension to the ns Network Simulator," http://www.informatik.uni-mannheim.de/informatik/pi4/projects/MobileIP/ns- extension/. Appendix A. Pseudo Code for the Analytical Model %===================================== % Set initialize value. % parameters for "chunk_size", "sack_size", "bandwidth", "ntw_delay" and % "loss_rate" and "predefined_round_number" need to be set to start the algorithm %================================ cwnd = [2]; qq = [l]; current_element =1; p = loss_rate; q=l-p; delay = ntw_delay; pkt_cwnd = cwnd*q; cum_delay = ntw_delay; cum_rtt = [(cwnd*chunk_size+(cwnd/2)*sack_size)]/bandwidth; round = predefined_round_number; % % Do for every round % for r = 1 : (round-1) m = current_element; n = 2*current_element % % next round, there are n elements in the cwnd and qq arrays % generate next round qq, cwnd arrays % % % create 2*current_clement array % array = zeros(l,n); % % for next round qq % array(l:2:n) = qq; array(2:2:n) = qq; qq = array; for i = l :m qq(2*i) = qq(2*i)*qAcwnd(i); qq(2*i-l) = qq(2*i-l)*(l-qAcwnd(i)); end % — % for next round cwnd % array(l:2:n) = (cwnd*0.5); array(2:2:n) = cwnd+1; cwnd = array; % allow slow start until cwnd(n) = 45 if(r =2); cwnd(n) = 4; end; elseif(r = 3); cwnd(n) = 8; end; elseif(r = 4); cwnd(n) =16; end; elseif(r = 5); cwnd(n) =32; end; elseif(r = 6); cwnd(n) = 45; end; % % for new round rtt and packet % array(l:2:n) = cum_rtt; array(2:2:n) = cum_rtt; cum_rtt = array; array(l:2:n) = pkt_cwnd; array(2:2:n) = pkt_cwnd; pkt_cwnd = matrix; for i = l:n cum_rtt(i) = cum_rtt(i)+ (cwnd(i)*chunk_size+(cwnd(i)/2)*sack_size)/bandwidth; pkt_cwnd(i) = pkt_cwnd(i)+cwnd(i)*q; end pkt = 0; c_rtt = 0; cum_delay = cum_delay+ntw_delay; for i = 1 :n pkt = pkt+pkt_cwnd(i)*qq(i); c_rtt = c_rtt+cum_rtt(i)*qq(i)-i-cum_delay; end % % to implement the combine element method % temp_cwnd = sort(cwnd); counter = 1 ; new_cwnd(l) = temp_cwnd(l); for i = 2:n if(temp_cwnd(i) ~= new_cwnd(counter)) counter = counter+1; new_cwnd(counter) = temp_cwnd(i); end end % % generate new_qq arrary, add the transition probability with the same cwnd size together % for i = 1 xounter forj = l:n if(cwnd(j) = new_cwnd(i)) new_qq(i) = new_qq(i)+qq(j); end end current_element = counter; cwnd = new_cwnd qq = new_qq end; % % to calculate the throughput % thr = pkt/c_rtt; Glossary of Acronyms 3G 3rd Generation A A A Authentication, Authorization and Accounting A C Address Check A C K Acknowledgement A C R Address Check Reply AP Access Point API Application Programming Interface ASCONF Address Configuration chunk A S C O N F _ A C K Address Configuration Acknowledgement chunk Association. Max.Retrans Maximum Association Retransmissions BS Base Station C H Corresponding Host C L Congestion Loss cmTSN Cumulative Transmission Sequence Number cwnd Congestion Window D A R Dynamic Address Reconfiguration DHCP Dynamic Host Configuration Protocol DNS Domain Name System E C N Explicit Congestion Notification E L Wireless Channel Error Loss ETSI European Telecommunications Standards Institute F A Foreign Agent FD Four Duplicate SACKs FEFO First In First Out FS Fixed Server FTP File Transfer Protocol G G S N GPRS Gateway Node GI Generalized Identity GPRS General Packet Radio Service FIA Home Agent HHO Horizontal Handover HI Host Identifier HTJL Host Identity Layer HIP Host Identity Protocol HTP A C HIP Address Check fflP A C R HTP Address Check Reply HIP R E A HTP Readdress packet H L Handover Loss HTTP Hypertext Transfer Protocol IETF Internet Engineering Task Force IOTA Inter-working Access gateway IP Internet Protocol IWU Inter-working Unit LIN6 Location Independent Network for IPv6 LIN6 ID LIN6 Node Identifier LIN6 GI LIN6 Generalized ID LINA Location Independent Network Architecture M A Mapping Agent M A C Medium Access Control M C Mobile Client M H Mobile Host MIP Mobile IP MJPBS Mobile TP Base Station agent MTPMH Mobile IP Mobile Host agent MSCTP Mobile Stream Control Transmission Protocol M-TCP Migrate Transmission Control Protocol M T U Message Transmission Unit N O A H Non-Ad-Hoc Routing Agent NS Network Simulator Path.Max.Retrans Maximum Path Retransmissions P M T U Path Maximum Transmission Unit PR Partial Reliable data transfer R E A HTP Readdress RR Round Robin scheduling RSS Received Signal Strength RTO Retransmission Timeout RTOmin Minimum Retransmission Timeout RTT Round Trip Time rwnd Receiver's Advertised Window QoS Quality of Service S A C K Selective Acknowledgement SCTP Stream Control Transmission Protocol SGSN GPRS Support Node SIP Session Initiation Protocol S M A R T - F R X Sending-buffer Multicast with Fast Retransmission ssthresh Slow Start Threshold T3-rtx Timer 3 for Retransmission timeout TCP Transmission Control Protocol TELNET TCP/IP Terminal Emulation Protocol TO Timeout TSN Transmission Sequence Number UDP User Datagram Protocol UMTS Universal Mobile Telecommunication System V H O Vertical Handover WLANs Wireless Local Area Networks 

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.831.1-0064942/manifest

Comment

Related Items