Performance Evaluation of Handoff between UMTS/802.11b based on Mobile IP and Stream Control Transmission Protocol

(1)

SONG, JUNG KEE. Performance Evaluation of Handoff between UMTS/802.11b based on Mobile IP and Stream Control Transmission Protocol. (Under the direction of Pro-fessor Wenye Wang).

Various wireless networks, contemporarily, have evolved as prime communi-cation methods, encountering convergence paradigm among heterogeneous technologies including applications based on IP, which has given enormous impacts in our way of life because of its proved robustness and scalability as well as ample services. With the synergy of the two technologies, ubiquitous access to all-IP information sources has become reality.

For wireless IP services, IP mobility is one of the major issues that should be resolved. Especially, the performance of handoff mechanism is a pithy issue that determines the performance of application level services. Although Mobile IP (MIP) and its extensions, as network layer solutions, have been proposed and standardized, their handoff mechanisms bring unavoidable transmission throughput degradation due to packet loss, registration delay, and transport layer blocking. Moreover, to accommodate MIP, significant quantity of modifications should be brought into each heterogeneous network architecture.

(2)

by

Jung Kee Song

A thesis submitted to the Graduate Faculty of North Carolina State University

in partial satisfaction of the requirements for the Degree of

Master of Science

Department of Computer Science

Raleigh

2005

Approved By:

Dr. Arne A. Nilsson Dr. David Thuente

(3)

To my parents,

Dong Soo Song and

(4)

Biography

(5)

Acknowledgements

A special thanks to Dr. Wenye Wang, my advisor, for her support and commitment. I would like to thank her for all her efforts guiding me throughout my research and sharing my personal difficulties. I am also grateful to her for a great work environment she has provided me during my research. It has been my pleasure and honor working with her.

I would like to thank Dr. Arne A. Nilsson and Dr. David Thuente for being on my advisory committee and providing valuable comments on my research.

I would like to thank my colleagues in NetWIS Lab, Wei Liang, Avesh Agarwal, Nurcan Tezcan, Ming Zhao, Fei Xing, and Nagalakshmi Mahali for their advices and encouragements throughout the entire duration of my research and thesis preparation. I would like to thank my friends, Young June Pyun, Jang Eun Jun, and many others for their concerns and precious time when I was in need. They have been of great help and pleasure to my life in Raleigh.

(6)

List of Figures

2.1 Agent Discovery and Registration in MIP . . . 9

2.2 Agent Solicitation Message Format [RFC2002] . . . 10

2.3 Agent Advertisement Message Format [RFC2002] . . . 11

2.4 Registration Request Message Format [RFC2002] . . . 13

2.5 Registration Reply Message Format [RFC2002] . . . 14

2.6 Tunneling in MIP . . . 14

2.7 Minimal Tunneling Header Message Format [RFC2004] . . . 15

2.8 SCTP Association . . . 18

2.9 Multi-Session from an SCTP Endpoint . . . 19

2.10 mSCTP Multi-Homing . . . 19

2.11 SCTP Association Setup . . . 21

2.12 SCTP Association Close . . . 21

2.13 SCTP Common Header [RFC2004] . . . 22

2.14 ASCONF Parameter: Add IP Address (add-IP) . . . 25

2.15 ASCONF Parameter: Delete IP Address (delete-IP) . . . 26

2.16 ASCONF Parameter: Set Primary IP Address (set-primary-IP) . . . 26

2.17 DAR: ASCONF Chunk Format . . . 27

2.18 DAR: ASCONF-ACK Chunk Format . . . 27

2.19 mSCTP Handoff Signaling with Multi-Homing and DAR Extension . . . 29

3.1 Network and Service Convergence . . . 31

3.2 Mobile IP Vertical Handoff Architecture: UMTS(3GPP R99)/802.11b . 33 3.3 Mobile IP Vertical Handoff Architecture: UMTS(3GPP R5)/802.11b . . 34

3.4 mobile SCTP Vertical Handoff Architecture: UMTS(3GPP R99)/802.11b 35 3.5 mobile SCTP Vertical Handoff Architecture: UMTS(3GPP R5)/802.11b 35 5.1 NS-2 and the Related Modules used in the Simulation . . . 52

(10)

5.3 Network Architecture-2: (a) UMTS/802.11b integrated network (b) NS-2 Node Topology for Mobile IP + TCP and Mobile IP + SCTP (c) NS-2

Node Topology for mobile SCTP . . . 60

5.4 MIP+TCP Protocol Stack in 802.11b WLAN Topology . . . 62

5.5 MIP+TCP Protocol Stack in UMTS Topology . . . 63

5.6 MIP+SCTP Protocol Stack in 802.11b WLAN Topology . . . 64

5.7 MIP+SCTP Protocol Stack in UMTS Topology . . . 65

5.8 mSCTP Protocol Stack in 802.11b WLAN Topology . . . 67

5.9 mSCTP Protocol Stack in UMTS Topology . . . 68

5.10 Simulation Scenario Category (SIM-Nα-Pβ-Dγ) . . . 70

5.11 Handoff Rate (Occurrences of Handoff) . . . 72

5.12 Pseudo Code: MN Movement Generation . . . 73

5.13 MN Movement Pattern for 802.11b WLAN-Only Network: SIM-N1-Pβ-Dγ 74 5.14 MN Movement Pattern for UMTS/802.11b Integrated Networks: SIM-N2-Pβ-Dγ . . . 75

5.15 Handoff Behavior in 802.11b WLAN-Only Network (Uplink): SIM-N1-Pβ-D1 . . . 77

5.16 Total Handoff Delay in 802.11b WLAN-Only Network (Uplink): SIM-N1-Pβ-D1 (95% Confidence Interval) . . . 78

5.17 End-to-end Throughput in 802.11b WLAN-Only Network (Uplink): SIM-N1-Pβ-D1 (95% Confidence Interval) . . . 79

5.18 Packet Loss in 802.11b WLAN-Only Network (Uplink): SIM-N1-Pβ-D1 (95% Confidence Interval) . . . 81

5.19 Handoff Behavior in 802.11b WLAN-Only Network (Downlink): SIM-N1-Pβ-D1 . . . 82

5.20 Total Handoff Delay in 802.11b WLAN-Only Network (Downlink): SIM-N1-Pβ-D2 (95% Confidence Interval) . . . 83

5.21 End-to-end Throughput in 802.11b WLAN-Only Network (Downlink): SIM-N1-Pβ-D2 (95% Confidence Interval) . . . 84

5.22 Packet Loss in 802.11b WLAN-Only Network (Downlink): SIM-N1-Pβ -D2 (95% Confidence Interval) . . . 86

5.23 Handoff Behavior in UMTS/802.11b Integrated Networks (Uplink): SIM-N2-Pβ-D1 . . . 87

5.24 Total Handoff Delay in UMTS/802.11b Integrated Networks (Uplink): SIM-N2-Pβ-D1 (95% Confidence Interval) . . . 88

5.25 End-to-End Throughput in UMTS/802.11b Integrated Networks (Up-link): SIM-N2-Pβ-D1 (95% Confidence Interval) . . . 89

5.26 Packet Loss in UMTS/802.11b Integrated Networks (Uplink): SIM-N2-Pβ-D1 (95% Confidence Interval) . . . 91

5.27 Handoff Behavior in UMTS/802.11b Integrated Networks (Downlink): SIM-N2-Pβ-D2 . . . 93

(11)

5.29 End-to-End Throughput in UMTS/802.11b Integrated Networks (Down-link): SIM-N2-Pβ-D2 (95% Confidence Interval) . . . 95 5.30 Packet Loss in UMTS/802.11b Integrated Networks (Downlink):

(12)

List of Tables

1.1 IP Mobility Research in WLAN . . . 6

1.2 IP Mobility Research in 3G . . . 6

1.3 IP Mobility Research in UMTS/WLAN . . . 7

2.1 SCTP Chunk Type . . . 23

2.2 DAR: Address Configuration Chunks . . . 26

(13)

Chapter 1 Introduction

1.1 Wireless IP Networks: the Future

The Internet protocol suite has become one of the most essential and prevalent networking technologies in computer networks as well as telecommunication networks. Based on its layered architecture and packet switching capability, IP technology offers unified, flexible and scalable services to various applications over many heterogeneous networks. IP technology also enables cost efficient business transactions in highly ad-vanced forms of user applications. The benefits of IP, in turn, make today’s research and business move toward all-IP era.

Contemporarily, wireless technology eradicated the limitation of user mobility, which is originally ascribed to fixed wires. As wireless technology evolved, mobile users have become able to connect to various wireless information systems with different pur-poses. Among various wireless access technologies,wireless local area networks(WLAN) and cellular networks have turned out to be the most widely deployed infrastructures providing mobile access to voice and data services upon users’ needs.

(14)

few hundred meters range. On the other hand, cellular networks are, inherently, de-signed to cover much wider areas with relatively low bandwidth. Second generation (2G), GSM and CDMA networks, 2.5G, the General Packet Radio Service (GPRS) and Enhanced Data rates for Global Evolution (EDGE) networks, and emerging third generation (3G)Universal Mobile Telecommunications System(UMTS), CDMA2000 1x Evolution Data and Voice (EV-DV) are the major commercial cellular networks. For instance, 3G UMTS is designed to support up to 384 Kbps data rate for pedestrian users and 2Mbps rate for vehicular users within a few kilometers coverage areas. In this reason, exploiting their complimentary advantages, WLAN and 3G cellular networks can offer good quality of convergent services in a complimentary form.

Due to the advantages of IP protocol and wireless technology, we have en-countered wireless IP era based on their synergic effects. Having succeeded already, copious IP applications are to be ported into wireless services for mobile users. It is an apparent trend that IP leads the existing wireless access technologies to evolve into all-IP-based networks. The next generation all-IP wireless networks will enable us to exploit all the IP-based services in ubiquitous manner. To achieve the unified IP-based wireless networks and services, the integration of the existing networks and technologies are required.

(15)

1.2 The Need for IP Mobility

IP protocol has been designed based on the assumption that nodes have per-manent IP addresses which are fixed at particular points in the Internet. The concept of IP address had not been a problem before we encountered needs of change of point of attachment of nodes. In order to support node movements in IP networks, mobility management should be supported with the original protocol specification.

Mobility management contains two components: location management and handoff management [6]. Location management is a node’s location update process to allow its up-to-date location to be informed by other nodes while handoff management is to maintain on-going connections irrespective of node movements between independent networks. In the thesis, we focus on the latter: the performance of handoff management. The basic functionalities required in IP-based handoff solutions include a node movement detection when a node moves across a new IP subnet, and a mobility-transparent packet transmission. To support IP-based handoff, quite a few solutions have been proposed as network layer solutions including MIP, HAWAII [30], Cellular IP [13], and IDMP [26]. HAWAII, a domain-based mobility solution, Cellular IP, and IDMP are micro-mobility solutions proposed to solve out the signaling overhead problem of macro-mobility when a node frequently moves in foreign domain. MIP is an Internet standard to support network layer mobility. MIP handoff consists of two phases: agent discovery and registration.

Although the proposed IP-based handoff solutions solved the fundamental problem of node movement in the Internet, they still incur significant handoff delays which affect the quality of applications and services, especially in mobility-oriented envi-ronments. Hence, seamless IP-based handoff solutions are definitely required for future wireless IP networks.

1.3 Motivation and Contributions

(16)

and reliability of the system and services.

As discussed in Section 1.2, many legacy IP-based handoff solutions have been proposed as network layer solutions since the role of network layer is the manipulation of IP address and packet forwarding. Although MIP is a representative network layer handoff solution which has been widely deployed, it cannot avoid inherent deficits: registration and tunneling overhead.

Meanwhile, we will discuss a new method of IP-based handoff in transport layer usingStream Control Transmission Protocol(SCTP) [35]. SCTP provides a multi-homing feature with which a mobile node can hold multiple IP connections at a given moment. Based on multi-homing feature of SCTP, an extension, calleddynamic address reconfiguration (DAR) [34], has been proposed as an Internet draft. DAR consists of pairs of request and response messages to update IP address information between two end nodes. The multi-homing feature of SCTP and DAR extension enables a transport layer seamless handoff by eliminating registration delay and tunneling overhead.

Hence, we have brought our attention to the performance evaluation of the two IP-based handoff solutions, MIP and mSCTP, in wireless IP convergent networks. MIP, as a network layer solution, has been an Internet standard and most widely deployed but also incurs significant handoff delay. mSCTP, on the other hand, does not incur significant handoff delay based on the multi-homing feature of SCTP and DAR exten-sion. In that, we have a strong motivation in studying and comparing mSCTP, a new transport layer solution, with MIP such that we verify the feasibility of the transport layer handoff comparing to MIP in future wireless IP networks.

In the thesis, we study the mechanism of MIP and mSCTP, and introduce three performance metrics to compare the performance of MIP and mSCTP. These three performance metrics includetotal handoff delay,end-to-end throughput, andpacket loss. With the three performance metrics, we conduct an analysis and a simulation study using NS-2 network simulator [1] to evaluate the performance of MIP and mSCTP in UMTS/802.11b integrated networks. We have observed the following characteristics of mSCTP over MIP:

(17)

• End-to-end throughput of mSCTP is constant irrespective of handoff rate while that of MIP decreases proportional to handoff rate.

• mSCTP does not incur any packet loss based on its zero handoff delay while packet loss of MIP increases proportional to handoff rate such that transport layer transmission behavior can have negative effects.

• mSCTP does not require any third party agent while MIP needs additional efforts with the integration of agents into legacy architectures. This implies that mSCTP is easier to be deployed in heterogeneous networks.

To the best of our knowledge, it is a unique contribution of our thesis that we evaluate and compare the performance of network layer handoff solution, MIP, and that of the transport layer handoff solution, mSCTP, in UMTS/802.11b integrated network to verify the feasibility of mSCTP in future wireless IP networks.

1.4 Related Works

As the importance of IP-based mobility has increased, quite a few research efforts have been made in many aspects. Here, we list the previous works related to the same aspects in which we have pursued our research. We targeted three handoff protocols, TCP over MIP (MIP+TCP), SCTP over MIP (MIP+SCTP), and mSCTP, with regard to three performance parameters, handoff delay, end-to-end throughput, and packet loss. MIP+TCP and MIP+SCTP are protocol stacks to evaluate MIP performance. MIP+SCTP has been used in our simulation such that MIP and mSCTP can be fairly compared based on the same transport layer protocol, SCTP.

Table 1.1 shows the related works done in WLAN-only networks. [17] sug-gested a transport layer handoff mechanism, Transport Layer Seamless Handover for Mobile Networks (TraSH). TraSH provides a transport layer handoff based on multi-homing feature of SCTP. Unlike MIP, TraSH separated the new-IP discovery signaling procedure from data transfer procedure. TraSH also proposes a new location manage-ment mechanism which can be integrated into DNS services.

(18)

Table 1.1: IP Mobility Research in WLAN

MIP+TCP MIP+SCTP mSCTP

E2E Throughput Fu’03 [17] Fu’03 HPSR [15] Koh’04 CL [21] Noonan’02 ITT [27] Fu’03 [17]

Noonan’02 ITT [27] Handoff Delay Aydin’03 ICC [8] Aydin’03 ICC [8]

Fu’03 [17] Fu’03 [17]

Hsieh’03 INFO [19]

Packet Loss Aydin’03 ICC [8] Aydin’03 ICC [8]

Fu’03 [17] Fu’03 [17]

Hsieh’03 INFO [19]

Other Parameters Fu’03 [17] Koh’04 ACT [22]

Hsieh’03 INFO [19] Fu’03 [17]

used for location management of MN when a correspondent node (CN) initiates a data transmission to a mobile node (MN). This paper also deals with mSCTP over MIP and finally compares the mechanism of mSCTP with that of MIP. This paper has addressed the procedure of handoff and location management, not focusing on performance is-sues but on structures. [8] proposed yet another transport layer approach to Internet mobility using multi-homing feature of mSCTP.

Table 1.2: IP Mobility Research in 3G

E2E Throughput Handoff Delay Packet Loss

Other Parameters Bajwa’02 ISCON [9]

Table 1.2 shows the related works done in 3G networks. Although the trend of 3G networks is to be evolved into all-IP networks, the current research has not targeted IP-based mobility in 3G-only networks. [9] provided MIP evaluation in 3G networks.

(19)

interwork-Table 1.3: IP Mobility Research in UMTS/WLAN

E2E Throughput Matusz’03 LCN [25] Ma’04 W.Comm. [23] Handoff delay Matusz’03 LCN [25] Ma’04 W.Comm. [23] Packet loss

Other Parameters Buddhikot [12]

Buddhikot’03 INFO [11]

ing. [11] also includes experimental results of MIP agent performance and their proposed QoS mechanisms in this architecture. [23] introduced transport layer protocol, SCTP, and discuss the transmission behavior and throughput in the integrated networks.

The thesis consists of 6 chapters each of which describes the following: Chapter 2IP Mobility: Handoff Solutionsreviews the mechanism of MIP and mSCTP. In Section 2.1, MIP is explained as a network layer handoff solution and the related problems are discussed. In Section 2.2, mSCTP, a transport layer approach, is introduced with multi-homing feature of SCTP. We discuss the fundamental differences between the network layer approach and the transport layer approach.

In Chapter 3Vertical Handoff Architecture in Heterogeneous Networks, we dis-cuss the current trend of network and service convergence and example vertical handoff architectures using IP-based handoff. That is, MIP and mSCTP handoff architectures in UMTS/802.11b integrated network.

(20)

Chapter 2 IP Mobility: Handoff Solutions

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

2.1 Mobile IP: A Network Layer Approach

Mobile IP (MIP) is a network layer mobility solution for wireless IP networks. MIP defines three basic components:

• MN A mobile node that wanders within MIP network.

• HA An home agent, which is a special agent sitting on a router located in MN’s home link. MN is initially given an IP address, called home address, in its home network.

(21)

These three components cooperate to locate and register the current IP address of an MN as it moves across different IP subnets. MIP is also designed to provide mobility transparent packet transmission service, calledtunneling, to upper layer protocols.

MIP became an Internet standard based on its network layer mobility capa-bility, but incurs significant handoff delay due to its registration procedure and tunnel-ing overhead. The handoff delay also brtunnel-ings performance degradations to connection-oriented Internet applications. In this section, we discuss the procedure of MIP handoff: agent discovery,registration, andtunneling. We also introduce several enhancement ef-forts that have been aimed to improve MIP performance.

2.1.1 Agent Discovery and Registration

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

FA

Internet

HA

MN

MIP handoff: Agent Discovery and Registration

Agent Discovery Registration

(1)

(2)

(3) (4)

(2) (3)

(4)

Agent Solicitation Agent Advertisement

Registration Request Registration Response

Figure 2.1: Agent Discovery and Registration in MIP

(22)

(1) and msg (2) are agent discovery messages; msg (3) and msg (4) are registration mes-sages exchanged during an MIP handoff. The details of agent discovery and registration are followed.

1. Agent Discovery

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

0 8 16 24 32

SolicitationRouter ICMP

IP Header

VER=4 IHL

Destination Address=broadcast (255.255.255.255) or multicast (224.0.0.2) Checksum

Type of Service Total Length Identification Flags Fragment Offset Time to Live=1 Protocol=ICMP Header Checksum

Source Address=MN home address

Type=10 Code=0

Reserved

Figure 2.2: Agent Solicitation Message Format [RFC2002]

Agent solicitation message format is derived from the ICMP router solicitation message format. The message format is exactly the same as that of ICMP router solicitation. It should be noticed that Time to Livefield is set to 1 to probe one-hope only. Source Addressfield is set with an MN’s home address, and Destination Address field is filled with normal broadcast or multicast address. Type field in ICMP portion of the message is set to 10 which denotes ICMP solicitation. Other fields are filled according to regular IP header and ICMP message specifications.

Once an agent received msg (1) agent solicitation (see Figure 2.1), the agent broadcasts an msg (2) agent advertisement message. Figure 2.3 shows the message format of msg (2) agent advertisement.

(23)

...

0 8 16 24 32

AdvertisementRouter ICMP IP Header AdvertisementAgent Mobility Extension Prefix−Length Extension (Optional)

VER=4 IHL Total Length

Flags Time to Live

Type of Service

Identification Fragment Offset Protocol=ICMP Header Checksum Source Address=HA and/or FA address

Destination Address=broadcast (255.255.255.255) or multicast (224.0.0.1)

Type=9 Code Checksum

Num Addrs Addr Entry Size Lifetime (of this Advertisement) Router Address[1]

Preference Level[1] Router Address[2] Preference Level[2]

Type=16 Length Sequence Number (maximum) Registration Lifetime Reserved

Care−of−Address[1] Care−of−Address[2]

Type=19 Length Prefix−Length[1] Prefix−Length[2] R B HF M GV

Figure 2.3: Agent Advertisement Message Format [RFC2002]

from ICMP router advertisement message format. In addition to the original ICMP router advertisement message, mobility agent advertisement extension and optional prefix-length extension are added. As shown in Figure 2.3, an msg (2) agent adver-tisement message carries CoAs to the MN.Type field of ICMP message portion is set to 9 to denote ICMP advertisement. Num Addrsmeans how many pairs ofRouter Address andPreference Levelvalues are contained. Addr Entry Sizerepresents the size of a pair of Router Address and Preference Level fields. Lifetime field is set with the period of time this advertisement is valid. (i.e., how often an agent broadcasts an advertisement message.)

(24)

CoA allowed. Optional Prefix-Length Extension is used for MN to calculate network prefix portion of agent address, in order to identify MN itself has been moved.

Upon reception of msg (2) agent advertisement (see Figure 2.1), the MN dis-patches a CoA from the message and set the CoA as a new foreign address in its MIP implementation. Upon the completion of agent discovery, the MN performs registration of its CoA with HA.

2. Registration

Once an MN detects its movement into a new subnet and obtains a CoA through agent discovery period, the MN tries to register its CoA with the HA. Regis-tration is a procedure to have a HA create, update, or delete the binding information of an MN’s home address and its CoA. So, when a given lifetime of a binding information is about to expire, the corresponding MN should register its CoA again with the HA.

Registration is composed of two messages: msg (3) registration request (see Figure 2.1) and msg (4) registration response. Msg (3) registration request and msg (4) registration response messages are exchanged in UDP packet format. Figure 2.4 shows registration request message format.

Msg (3) registration request (see Figure 2.1) can be sent by MN to HA directly when MN obtained collocated CoA as well as via FA when MN obtained FA’s CoA. In the latter case, FA receives a msg (3) registration request and relays the message to HA. It should be noticed that msg (3) registration request must be authenticated such that HA can confirm the message is not delivered from any malicious party.

(25)

Request RegistrationPortion of Fixed−Length

Mobile−Home Authentication

Extension

0 8 16 24 32

IP Header

More Optional Extensions

HeaderUDP

Option Option

VER=4 IHL

Source Port Length

S B rsv

Optional Extensions

Length Index (SPI)

Type of Service Total Length

Identification Flags Fragment Offset

Time to Live Protocol=UDP Header Checksum

Source Address Destination Address

Destination Port=434 Checksum

Type=1 Lifetime

MN Home Address HA Address Care−of−Address

Identification

Type=32 Security Parameter

Authenticator (Default equals Keyed MD5) D M G V

Figure 2.4: Registration Request Message Format [RFC2002]

Upon reception of a msg (3) registration request message (see Figure 2.1), HA updates the binding information according to the received CoA. If no error occurs during the binding update procedure, HA sends msg (4) registration response back to either MN or FA which relays it to MN. Msg (4) registration response message informs MN the result of registration procedure, whether or not it is successfully completed. Figure 2.5 shows msg (4) registration response message format defined in RFC 2002. (The only different part, Fixed-Length Portion of Registration Reply, is depicted.)

(26)

0 8 16 24 32

Fixed−Length Portion of Registration

Reply

Type=3 Code Lifetime MN Home Address

HA Address

Identification

Figure 2.5: Registration Reply Message Format [RFC2002]

2.1.2 Mobility-Transparent Packet Forwarding: Tunneling

MIP is designed to provide mobility-transparent packet forwarding to MN regardless of its location in foreign links. This mobility support is based on tunneling capability. From the information given by agent discovery, an HA sets up a virtual tunnel, which is a particular route, to the CoA of MN (either an FA’s CoA or a collocated CoA). The HA forwards the packets, originally destined to the home address of the MN, to the CoA of the MN. Figure 2.6 shows tunneling procedure of MIP.

HA

MN CN

Internet

Tunneling FA

MIP handoff: Tunneling

Outer IP header Triangular routing Tunneling overhead

Figure 2.6: Tunneling in MIP

(27)

address, is encapsulated to the IP payload part of another IP datagram and tunneled to MN’s CoA. As an encapsulation requires 20 bytes of additional IP header, end-to-end throughput decreases.

Second, minimal encapsulation option uses 12 bytes additional header to reduce the overhead of IP in IP encapsulation, but requires modifications on several fields in the IP header of original packets. Last, GRE is adopted by MIP in order to support other protocols as well as IP.

0 8 16 24 32

Minimum Forwarding

Header

Protocol Reserved Header Checksum

Original Destination Address Original Source Address (if present) S

Figure 2.7: Minimal Tunneling Header Message Format [RFC2004]

2.1.3 Problems

So far in this section, we described MIP mechanism including agent discovery, registration, andtunneling. Although MIP resolves host mobility in IP layer, additional agents and tunneling overheads degrade performance of data transmission to/from mo-bile host when handoff occurs. Such problems are listed below:

• High handoff delay MIP handoff delay is ascribed to agent discovery delay and registration delay as we discussed in this section. As we discuss in Chapter 4 and Chapter 5, MIP handoff delay increases proportional to handoff rate and period of time MN stays in foreign links. Hence, MIP handoff can cause significant performance degradation, especially in highly mobility-oriented environments.

(28)

• Conflict with network security solutions [17]

2.1.4 Enhancement Efforts

In order to reduce handoff delay and tunneling overhead incurred by MIP, quite a few enhancement efforts have been made. There have been many other extensions and drafts in terms of more general mobility architecture and performance, but we focus on MIP extensions regarding handoff performance. We discuss two major internet drafts MIP with route optimization andhierarchical MIP.

• Optimized routing Optimized routing [29] is an MIP extension to reduce tun-neling overhead. In this extension, MN informs its CoA to CN directly so that CN can send data packets to the CoA directly without tunneling by HA. In order to realize the optimized routing, CN maintains a binding cache in which CoAs of MN are being updated as MN moves.

• Regional registration and hierarchical Mobile IP MIP regional registration[18] and HMIP [33] are another MIP extension to reduce signaling overhead. Hier-archical MIP is categorized as a micro-mobility solution. When the frequency of an MN movement inside of a subnet increases, signaling overhead for the MN’s registration of its CoA with the HA increases and cause high handoff delay. In order to reduce the signaling overhead, a hierarchical mobility agent, called gate-way foreign agent(GFA) [7][18], is defined. Whenever a handoff is triggered from an MN movement, the MN registers its CoA with the most nearby local GFA. As the HA had already been noticed about the tunneling information to the GFA in the previous (or the first) registration, the tunneling of packets are processed in a hierarchical manner from the HA to the GFA, and the GFA to the FA, and the FA to the MN.

2.2 mobile SCTP: A Transport Layer Approach

(29)

been adopted as the third general purpose transport protocol1by IETF, inheriting main features of TCP including the concept of flow control and congestion control. SCTP, in addition, provides two novel features, multi-homing and multi-streaming. Multi-homing is a concept that two end hosts can hold multiple connections at the same time while multi-streaming is a feature that multiple streams of data can be delivered under independent controls within a single connection.

mobile SCTP (mSCTP) utilizes multi-homing feature of SCTP in such a way that two end hosts hold two transport layer connection identities at the same time when an MN stays in an overlapped region moving from one subnet to another. In addition, DAR extension is used to deliver messages of add-ip, delete-ip, and set-primary-ip re-quests. All the mSCTP handoff procedures are processed between two end-to-end hosts without involving any third party agent.

As discussed in Section 2.1, one of the major problems of MIP is that an MN cannot keep communicating with a CN while it has to deal with its registration of its CoA with the HA during handoff period. However, mSCTP can provide a seamless handoff solution based on its multi-homing feature and DAR extension. In the following subsections, we discuss SCTP details and DAR extension.

2.2.1 Stream Control Transmission Protocol (SCTP)

We introduce Stream Control Transmission Protocol (SCTP), the third gen-eral purpose transport layer protocol, in this subsection. SCTP provides a connection-oriented, reliable transport service over IP network as TCP does. SCTP also supports congestion control and packet loss recovery function. In addition, SCTP has unique fea-tures including multi-homing and multi-streaming. Based on these two feafea-tures, SCTP was originally designed to provide a reliable transport between two end hosts using multiple, independent control of streams.

1. SCTP Endpoint and Association: Multi-homing

A transport endpoint in TCP/IP network is canonically defined as a pair of IP address and port number. In TCP, a connection is established between two (IP address,

1

(30)

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

Endpoint A Endpoint B

IP Layer IP Layer

SCTP Layer SCTP Layer

IP Networks

IP_B1 IP_B2 IP_A1 IP_A2

SCTP Association

Port Port

Figure 2.8: SCTP Association

In Figure 2.8, Endpoint A, having IP(A1) and IP(A2), established an SCTP association with Endpoint B, which has IP(B1) and IP(B2). In this example, Endpoint A uses IP(A2) as its primary IP address whileEndpoint Buses IP(B2).

Meanwhile, an SCTP endpoint can establish multiple sessions (associations) to other endpoints at the same time [37]. That is, an SCTP endpoint can utilize its multi-homed network interfaces to signal to more than two peer nodes at a given moment. Figure 2.9 shows concurrent associations from an endpoint, Endpoint A, to a set of endpoints, Endpoint B, Endpoint C, andEndpoint D. Based on association and multi-session features, an SCTP node can support multi-homing capability as shown in Figure 2.10.

(31)

Association

Endpoint B

Endpoint C Endpoint D Multiple Sessions from an SCTP Endpoint

Node 1 Node 2

Node 3

Endpoint A

Figure 2.9: Multi-Session from an SCTP Endpoint

CN

MN

AP BS

Cellular networks mSCTP: Multi−Homing

Internet

SCTP Association

Network interface 1 Network interface 2

End−to−end connection 1 End−to−end connection 2

Figure 2.10: mSCTP Multi-Homing

(32)

both networks, the MN is able to exploit its multiple network interfaces to communicate with the CN based on association and multi-session capability. More details of mSCTP handoff will be discussed in Subsection 2.2.3.

It should be noticed that an SCTP association is different from multi-homed TCP connections in such a way that an SCTP association has a single control over multiple IP addresses while each TCP connection is controlled in totally independent manner.

Prospective applications of SCTP multi-homing, based on the concept of as-sociation, are a reliable signaling with failover support, transport load balancing for multi-homed hosts, elimination of head-of-line blocking (with the help of multi-stream of SCTP), and transport layer handoff.

2. Setup and Close an Association

Since SCTP is a connection-oriented transport protocol, two endpoints should establish anassociation (see item 1. SCTP Endpoint and Association: Multi-homingin this subsection) before exchanging data chunks. Unlike TCP, SCTP uses four-way hand-shake to setup an association. Four-way handhand-shake can prevent TCP SYN-flooding-attack, which is ascribed to the three-way handshake of the connection initialization of TCP. Figure 2.11 shows the signaling of an SCTP association setup process.

Endpoint A starts four-way handshake association setup process by sending an INIT chunk. Upon receiving INIT chunk, endpoint B responds by sending an INIT-ACK chunk. INIT-INIT-ACK chunk contains a state cookie, which should be sent back to itself (endpoint B) by endpoint A. State cookie prevents well-known TCP SYN-flooding attack, which is attributed to the fact that a malicious node sends SYN packet continuously until the other endpoint runs out of its resources. Endpoint B verifies the authenticity of a state cookie delivered back in a COOKIE-ECHO chunk. Once endpoint B recognizes an authentic state cookie value, a COOKIE-ACK chunk is re-sponded to endpoint A. After finishing the four-way handshake, an SCTP association between endpoint A and endpoint B has been setup and reliable connection-oriented data transmissions are followed. It should be noted that COOKIE-ECHO chunk and COOKIE-ACK chunk are able to be bundled with data chunks.

(33)

INIT

COOKIE−ECHO

INIT−ACK

COOKIE−ACK

Association

Setup of an Association

SCTP:

Four−way handshake Endpoint B

Endpoint A

Figure 2.11: SCTP Association Setup

process.

Endpoint B Endpoint A SCTP:_{Three−message handshake}Close an Association

SHUTDOWN−COMPLETE

SHUTDOWN−ACK

SHUTDOWN

Association

state of association, endpoints do not accept In

packets (to send) from upper layer protocols

Figure 2.12: SCTP Association Close

(34)

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

3. Message Formats

An SCTP packet is composed of an SCTP common header and number of chunks. A chunk is a unit of information within an SCTP packet [37]. As a unit of SCTP message building block, many different types of chunks have been defined, categorized into either control chunks or data chunks. Figure 2.13 shows an SCTP message formats including its common header and chunks.

0 8 16 24 32

SCTP Header Common Source port number Destination port number

Adler−32 checksum Verification tag

Chunk type Chunk flags Chunk length Chunk data

. . .

.

Chunk type Chunk flags Chunk length Chunk data

. . .

Chunk 1

Chunk N

Figure 2.13: SCTP Common Header [RFC2004]

(35)

malicious packet-injecting attack. Adler-32 checksum supports received data integrity check. The checksum covers common header and all the appended chunks.

Chunks are the actual building blocks of SCTP. Each chunk consists of chunk type,chunk flags,chunk length, andchunk datafields. Chunk typeidentifies the type of chunk. Chunk flags provides special flags used for the chunk. Chunk length is set with the length of the chunk in bytes. At the end of a chunk,chunk data is followed.

Table 2.1: SCTP Chunk Type

Chunk Type Chunk Name Description

0x00 DATA User data

0x01 INIT Initiation of SCTP association

0x02 INIT-ACK Response to INIT chunk

0x03 SACK Acknowledgement of user data

0x04 HEARTBEAT Keep alive message

0x05 HEARTBEAT-ACK Response to HEARTBEAT

0x06 ABORT Ungraceful termination of an association 0x07 SHUTDOWN Graceful termination of an association

0x08 SHUTDOWN-ACK Response to SHUTDOWN

0x09 ERROR Report of an error

0x0a COOKIE-ECHO Pass a state cookie

0x0b COOKIE-ACK Response to COOKIE-ECHO

0x0c ECNE Explicit Congestion Notification Echo

0x0d CWR Congestion Window Reduced

0x0e SHUTDOWN-COMPLETE Graceful termination complete 0x3f Special expansion code 1 IETF-defined expansion code 0x7f Special expansion code 2 IETF-defined expansion code 0xbf Special expansion code 3 IETF-defined expansion code 0xff Special expansion code 4 IETF-defined expansion code

(36)

4. Data Transfer and Congestion Control

Once an association has been established, two SCTP endpoints can transfer user data. First, application data are chopped into smaller pieces if they are too big to be fit in an SCTP packet according to the path maximum transmission unit (MTU). Application data are entered data chunk queue in SCTP layer to be packed in an SCTP packet. At the same time, if any type of control chunk is ready at the control chunk queue in SCTP layer, the control chunks are bundled together with data chunks in the front of data queue.

On the other endpoint, upon reception of an SCTP packet, chunks are unbun-dled into control chunks and data chunks. For fragmented data chunks, data chunks are reassembled in SCTP layer and put into stream reordering queues. Unbundled control chunks also conduct their anticipated functions in SCTP layer.

SCTP provides congestion control mechanism to adapt its transmission rate in shared networks. SCTP congestion control has been designed based on the rate-adaptive window-based scheme of TCP [16]. Hence, SCTP reduces the transmission rate whenever a network congestion is detected. However, several unique features, apart from TCP, are introduced.

Based on its mandatory SACK mechanism, SCTP supports inherent fast-recovery functionality without explicit mechanism. The mandatory SACK mechanism allows SCTP avoid slow start after multiple segment losses in a single window. The SACK mechanism, as a result, increases throughput of SCTP by efficient bandwidth usage.

In slow start and congestion avoidance stage of SCTP, congestion window (cwnd) is increased by the number of acknowledged bytes while TCP refers to the number of ACK segments to increase itscwnd. In congestion avoidance stage of SCTP, cwnd can be increased only after full cwnd is consumed. SCTP, also, waits its fast retransmission until four Duplicated ACKs are received [16].

2.2.2 Dynamic Address Reconfiguration (DAR)

(37)

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

1. Add-IP, Delete-IP, and Set-Primary-IP parameters

The three new parameter types defined in DAR, add-IP, delete-IP, and set-primary-IP, are employed in mSCTP to perform seamless transport layer handoff. The word, seamless, in this context, means data transmission is almost not affected by handoff procedure. In mSCTP, this seamless handoff is guaranteed by exploiting multi-homing feature of SCTP and dynamic IP address configurations of DAR extension.

Add IP address (add-IP) is an ASCONF parameter to inform the other end node to add a new IP address in its active association. Figure 2.14 shows the message format of add-IP ASCONF parameter.

0 8 16 24 32

Type=0xC001 Length = Variable ASCONF−Request Correlation ID

Address Parameter

Figure 2.14: ASCONF Parameter: Add IP Address (add-IP)

The value, 0xC001, of type field identifies add-IP parameter. Length field is variable since address parameter can carry multiple IP addresses. ASCONF-request correlation ID is used for a sender of the ASCONF chunk to distinguish the particular chunk from other chunks. Address parameter field holds IP address (either IPv4 or IPv6 address) in TLV format, which is described in 3.3.2.1 of RFC2960 [35]. Figure 2.15 shows delete-IP ASCONF parameter, which is used to notice the other end node to delete IP addresses, specified in the chunk, from an active association.

(38)

0 8 16 24 32

Length = Variable ASCONF−Request Correlation ID

Address Parameter Type=0xC002

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

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

0 8 16 24 32

Length = Variable ASCONF−Request Correlation ID

Address Parameter Type=0xC004

Figure 2.16: ASCONF Parameter: Set Primary IP Address (set-primary-IP)

The value of 0xC004 in type field describes it is a set-primary-IP ASCONF parameter. Length, ASCONF-request correlation ID, and address parameter are used in the same purpose as in add-IP and delete-IP ASCONF parameters.

In order to deliver these DAR parameters, two additional chunks, Address Configuration Change Chunk (ASCONF) and Address Configuration Acknowledgment (ASCONF-ACK), are defined.

2. ASCONF/ASCONF-ACK Chunks

Address Configuration Change Chunk (ASCONF) and Address Configuration Acknowledgment(ASCONF-ACK) are additional chunk types defined in DAR internet draft [34]. Table 2.2 shows ASCONF and ASCONF-ACK chunk types.

Table 2.2: DAR: Address Configuration Chunks Chunk Type Chunk Name Description

(39)

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

8 16 24 32

Type=0xC1 Chunk Flags Chunk Length Serial Number

Address Parameter ASCONF Parameter #1

ASCONF Parameter #N

..

.

0

Figure 2.17: DAR: ASCONF Chunk Format

Type field is filled with the value, 0xC1, to identify ASCONF chunk. Chunk flags filed is not used in ASCONF chunk and set to 0. Chunk length denotes the length of the chunk itself. Serial number is set to a value from 0 to 4294967295 (2×

*32 - 1) range, in order to distinguish a particular ASCONF chunk from other chunks. Address parameter is set to a sender address to help receiver find the related association. ASCONF parameter fields contain add-IP, delete-IP, and set-primary-IP parameters which will be discussed later in this subsection.

ASCONF-ACK chunk delivers a reply message to an ASCONF request. Figure 2.18 shows the message format of ASCONF-ACK chunk.

0 8 16 24 32

Serial Number

ASCONF Parameter Response #1

ASCONF Parameter Response #N

Type=0x80 Chunk Flags Chunk Length

..

.

(40)

The value of 0x80in type field identifies it is an ASCONF-ACK chunk. Chunk flags field is not used and set to 0. Chunk length represents the length of the chunk itself. Serial number carries the serial number of ASCONF chunk which it replies to. ASCONF parameter response fields deliver the processed status of the ASCONF requests. By default, without any error occurred in ASCONF-ACK sender side, no ASCONF parameter response field is appended. That is, if no error occurs, only type, chunk flags, chunk length, and serial number fields are returned in an ASCONF-ACK chunk.

As discussed in the subsection, DAR extension, based on multi-homing feature of SCTP, allows seamless mSCTP handoff in transport layer. In the next subsection, we discuss how mSCTP handoff works based on multi-homing and DAR extension.

2.2.3 mSCTP: Make-Before-Break with Multi-Homing and DAR ”Make-before-break handovers involve a mobile nodemakingthe new link while maintaining the old link; when the new link is ready, the old link can be broken.” [32]

In this section, we have discussed essential components ofmobile SCTP(mSCTP) includingStream Control Transmission Protocol(SCTP) anddynamic address reconfig-uration (DAR) extension. Based on multi-homing feature of SCTP and DAR, make-before-break IP-based handoff is able to be performed.

During a handoff period, legacy network layer handoff mechanisms, including MIP, have a certain period in which an MN must communicate with agents other than its peer node, CN. Hence, the existing active connection suffers from packet loss, waste of bandwidth by transport layer slow start, and so on. As handoff delay increases, the performance degradation becomes bigger.

On the other hand, mSCTP node can utilize two network adapters in an as-sociation to make a new data path while still communicating with its peer node. To perform a handoff, mSCTP exchange at most three pairs of ASCONF/ASCONF-ACK control chunks bundled with data chunks with its peer node. Figure 2.19 shows mSCTP handoff signaling messages.

(41)

CN MN

Data Chunks

Acknowledgment to Data Chunks

Router Advertisement

ASCONF−ACK Chunk

Data Chunks Add−IP ASCONF Chunk mSCTP: Handoff Signaling

AP BS

(with Data Chunks)

(with Data Chunks) Set−Primary−IP ASCONF Chunk

(with Data Chunks) Delete−IP ASCONF Chunk

Network interface 1 Network interface 2

End−to−end connection 1 End−to−end connection 2 Router Solicitation

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

network interface-2. The router discovery process is performed independently from the data transmission in the network connection-1.

(42)

Chapter 3 Vertical Handoff Architecture in

Heterogeneous Networks

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

3.1 Network and Service Convergence: Trend

(43)

are divided into three categories: wireless LAN (WLAN), wireless MAN, and wireless WAN. Wireless LAN includes 802.11b, 802.11g, and 802.11a. Wireless MAN, which is targeting mobile Internet users in a city area, includes 802.16a, 802.16b, and 802.16e [31]. Wireless WAN includes all the current cellular infrastructure access networks such as CDMA2000, GSM, GPRS, and UMTS [10].

Among the different wireless access networks and services, Wireless LAN and wireless WAN have complementary characteristics. Wireless LAN generally provides relatively high data rate with small coverage while wireless WAN networks offer rela-tively low data rate with large coverage area. For instance, a WLAN standard, 802.11b, provides up to 11Mbps data rate with a few hundred meters of radius while UMTS UTRAN supports up to 2Mbps data rate for fixed node and 386Kbps for pedestrian users with a few kilometers of radius. Therefore, by using both of the network ser-vices, wide coverage area is guaranteed with high data rate where WLAN services are available.

802.11b _802.11b 802.11b

802.11b 802.11b

802.11b

802.11b 802.11b 802.11b 802.11b

802.11b

UMTS UTRAN

UMTS UTRAN CDMA2000 1x EV−DO

(44)

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

3.2 IP-based Vertical Handoff in UMTS/802.11b

In addition to the existing IP-based networks and services (either it is fixed networks or wireless access networks such as Wi-Fi hot spots), commercial cellular networks and services are also evolving toward all-IP networks due to many technological and economical reasons. Thus, IP-based handoff solutions will be the essential part of future wireless IP convergent networks. In this section, we discuss the architecture and performance issues of UMTS/802.11b integrated networks, as a case study, to examine the IP-based Handoff solutions: Mobile IP (MIP) and mobile SCTP (mSCTP).

In the thesis, in order to focus on only the handoff performance, we study loosely-coupled vertical handoff architecture where 802.11b WLAN does not have any correlation with UMTS network but directly connected to public IP networks.

3.2.1 Mobile IP Vertical Handoff

(45)

connects to the CDMA2000 cellular service and MIP Handoff occurs whenever the user enters a Wi-Fi hotspot area.

For UMTS network, MIP has not yet been adopted as a standard IP mobility solution. One of the disadvantages of MIP in architectural point of view is that it requires additional components: Home Agent (HA) and Foreign Agent (FA) which have to be installed in certain routers and/or network gateways. Moreover, as we will discuss later in the thesis, MIP incurs significant handoff delay due to the inevitable registration procedure.

To install MIP capability into UMTS (3GPP R991) network, agent modules should be implemented in SGSN or corresponding network gateways. Figure 3.2 shows an MIP vertical handoff architecture in UMTS(3GPP R99)/802.11b integrated network.

Node−B RNC

Agent Router

Agent

SGSN GGSN

Internet Core Network Packet Switching

MN

One Connection at a time

AP 802.11b Domain

UMTS UTRAN

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

Figure 3.2: Mobile IP Vertical Handoff Architecture: UMTS(3GPP R99)/802.11b

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

1

3GPP Release’99 (R99) is the first version of UMTS specifications [20].

(46)

Node−B RNC Agent Router

MN

One Connection at a time

Internet

UMTS UTRAN SGSN GGSN

Agent

Core Network Packet Switching

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

Release5 All−IP

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

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

3.2.2 mobile SCTP Vertical Handoff

Unlike MIP vertical handoff, mSCTP vertical handoff does not require any additional modification on existing components. (In the thesis, we focus on handoff functionality of IP mobility. Location management of mSCTP can be resolved with DNS service and not covered in the thesis.) As discussed in Chapter 2, mSCTP directly interacts with CN to trigger transport layer handoff. This end-to-end handoff proce-dure is one of the most important advantages that SCTP offers such that no handoff architecture difference exists between homogeneous environments and heterogeneous environments.

Figure 3.4 shows mSCTP vertical handoff architecture in UMTS(3GPP R99)/802.11b integrated network. No additional component is installed, and the MN directly interacts with CN in end-to-end manner.

Figure 3.5 represents mSCTP vertical handoff architecture in UMTS(3GPP R5)/802.11b integrated network. mSCTP does not required any modification in this architecture, either.

(47)

Node−B RNC Router

SGSN GGSN

Internet MN

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

Two Connections at the same time

UMTS UTRAN Core Network Packet Switching

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

Node−B RNC

Router

MN

AP

Internet SGSN GGSN

Core Network Packet Switching

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

Two Connections at the same time

UMTS UTRAN 802.11b Domain

Release5 All−IP

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

(48)

Chapter 4 Performance Analysis of Mobile

IP and mobile SCTP Handoff

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

4.1 Handoff Delay

(49)

amount of transferred data would be the same as in fixed network. As we discussed in Chapter 2,agent discoveryandregistrationof CoA with HA generate MIP handoff delay. In case of mSCTP, no significant handoff delay occurs since dynamic address reconfig-uration (DAR) control chunks can be bundled with other data chunks (see Chapter 2). For analysis of handoff delay, we begin with the definitions of parameters.

TM IP , MIP handoff delay (second)

TmSCT P , mSCTP handoff delay (second)

Tad , MIP agent discovery delay

Trd , mSCTP router discovery delay

Treg , MIP CoA registration delay

TDAR , mSCTP dynamic address reconfiguration delay

Tas , MIP agent solicitation time

Taa , MIP agent advertisement time

TCoA , MIP CoA processing time

Treg−REQ , MIP registration request time

TBU , MIP registration binding update

Treg−RES , MIP registration response time

Trs , mSCTP router solicitation time

Tra , mSCTP router advertisement time

Tnew−IP , mSCTP new-IP processing time

Tadd−IP , mSCTP add-IP time

Tdel−IP , mSCTP delete-IP time

Tset−primary−IP , mSCTP set-primary-IP time

TASCON F , mSCTP ASCONF chunk send delay

(50)

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

4.1.1 Handoff Delay in Mobile IP: TM IP

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

TM IP = Tad+Treg (4.1)

Agent discovery (Tad) and registration (Treg), in turn, are composed of the following operations, respectively:

• Agent discovery (Tad) Agent discovery (Tad) period consists of agent solicita-tion (Tas), agent advertisement (Taa), and CoA processing time (TCoA) of an MN. As we have discussed in Section 2.1, MIP handoff occurs when an MN moves from one subnet to another. For the movement detection of MN, agent discovery (Tad) is executed by an MN and an FA (or possibly HA) cooperation.

Agent solicitation (Tas) (see item 1. Agent Discoveryin Subsection 2.1.1) is a modified ICMP message broadcasted by an MN to search for an agent. Agent ad-vertisement (Taa) is also a modified ICMP broadcast message sent by an agent [28]. CoA processing time (TCoA) represents time taken by MN to dispatch a CoA from FA’s agent advertisement message [33]. As a result, the delay incurred by agent discovery is:

(51)

By accomplishing the above three operations, agent discovery period of MIP (Tad) make MN ready to trigger registration period (Treg) with its obtained CoA.

• Registration (Treg) Once an MN obtained a CoA from FA’s agent advertise-ment, it triggers registration (Treg) of its CoA with the HA. Registration (Treg) period is composed of registration request (Treg−REQ) by MN, binding entry up-date for a new CoA (TBU) by the HA, and registration response (Treg−RES) by the HA. That is,

Treg=Treg−REQ+TBU +Treg−RES (4.3)

Registration process can be successfully completed only when all the parties do not encounter any error during Treg−REQ, TBU, and Treg−RES periods. If any error occurs (mostly authentication failure), the HA sends a registration reply message with a corresponding error code and registration request message is re-transmitted by the MN after proper handling of the error specified in error code field. In order to prevent denial-of-service attack, which an unauthorized mali-cious node can flood registration traffic to an HA, registration request (Treg−REQ) and registration response (Treg−RES) messages should be authenticated by an HA and an MN, respectively (see item 2. Registration in Subsection 2.1.1). As we discussed in Subsection 2.1.1, registration request (Treg−REQ) and registration response (Treg−RES) are delivered in UDP packets.

Finally, agent discovery period and registration period constitutes MIP handoff delay (TM IP):

TM IP = Tad+Treg

= Tas+Taa+TCoA

| {z }

Tad

+Treg−REQ+TBU +Treg−RES

| {z }

Treg

(4.4)

(52)

binding update table upon a registration request from an MN which obtained a new CoA.

Including binding update (TBU) period and an additional authentication over-head, registration delay (Treg) can be significantly long when an MN communicates with others in a highly movement-oriented environment. It should be noticed that handoff delay (TM IP) may interrupt on-going data transmission such that end-to-end throughput decreases and data packet loss possibly occurs.

4.1.2 Handoff Delay in mobile SCTP: TmSCT P

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

TmSCT P = Trd+TDAR (4.5) Router discovery (Trd) period and DAR (TDAR) procedure, in turn, are com-posed of the following operations, respectively:

• Router discovery (Trd) Router discovery (Trd) period is composed of router so-licitation (Trs), router advertisement (Tra), and processing time of newly obtained IP (Tnew−IP) in an MN’s protocol stack. That is,

Trd=Trs+Tra+Tnew−IP (4.6)

Performance Evaluation of Handoff between UMTS/802.11b based on Mobile IP and Stream Control Transmission Protocol

Contents

List of Figures

List of Tables

Chapter 1

Introduction

1.1

Wireless IP Networks: the Future

1.2

The Need for IP Mobility

1.3

Motivation and Contributions

1.4

Related Works

Chapter 2

IP Mobility: Handoff Solutions

2.1

Mobile IP: A Network Layer Approach

...

...

...

2.2

mobile SCTP: A Transport Layer Approach

. . .

.

.

.

. . .

..

.

..

.

Chapter 3

Vertical Handoff Architecture in

Heterogeneous Networks

3.1

Network and Service Convergence: Trend

3.2

IP-based Vertical Handoff in UMTS/802.11b

Chapter 4

Performance Analysis of Mobile

IP and mobile SCTP Handoff

4.1

Handoff Delay