A NEW METHOD TO SUPPORT UMTS/WLAN VERTICAL HANDOVER USING SCTP

Transcription

1 MOBILITY AND RESOURCE MANAGEMENT A NEW METHOD TO SUPPORT UMTS/WLAN VERTICAL HANDOVER USING SCTP LI MA, FEI YU, AND VICTOR C. M. LEUNG, THE UNIVERSITY OF BRITISH COLUMBIA TEJINDER RANDHAWA, BRITISH COLUMBIA INSTITUTE OF TECHNOLOGY r Internet Router... Fixed serve... This work is based in part on a article presented at IEEE VTCfall, Orlo, FL, Oct.. This work was supported by grants from Telus Mobility the Advanced Systems Institute of BC, by the Canadian Natural Sciences Engineering Research Council under grant CRD78-. Ro Unlike techniques based on MIP or SIP, the SCTP-based vertical hover scheme does not require the addition of components such as home/foreign agents or SIP server to the existing networks. ABSTRACT This article proposes a new method to facilitate seamless vertical hover between widearea cellular data networks such as UMTS WLANs using the Stream Control Transmission Protocol (SCTP). The multihoming capability dynamic address configuration extension of SCTP are applied in an UMTS/WLAN overlay architecture to decrease hover delay improve throughput performance. Unlike techniques based on Mobile IP or Session Initiation Protocol, the SCTP-based vertical hover scheme does not require the addition of components such as home/foreign agents or a SIP server to existing networks. Therefore, the proposed scheme provides a network-independent solution preferred by service providers. Performance evaluations are presented to demonstrate the effectiveness of the proposed scheme. INTRODUCTION The complementary characteristics of third-generation cellular networks such as the Universal Mobile Telecommunications System (UMTS) 8. wireless local area networks (WLANs) make integrating these two technologies attractive [, ]. While UMTS networks provide always-on wide-area connectivity with relatively low data rates to users with high mobility, WLANs offer much higher data rates to users with low mobility over smaller areas. Contemporary mobile devices are increasingly equipped with multiple (e.g., UMTS/WLAN) network interfaces, which enable the mobile user to access the Internet using the higher bwidth offered by a WLAN whenever possible, using UMTS service otherwise. Since mobile users accessing the Internet via UMTS/WLAN are free to move, an efficient mobility management scheme is crucial in this integration. Mobility management consists of support for roaming, which provides reachability of mobile users, support for hover (also referred to as hoff in the literature), which provides ongoing connection continuity in spite of movements across between UMTS WLANs. Hovers between UMTS WLANs are commonly referred to as vertical hovers. Many proposals to solve the mobility management problem in heterogeneous wireless networks are found in the literature. Mobile IP (MIP) [] from the Internet Engineering Task Force (IETF) is a network layer solution. By inserting a level of indirection into the routing architecture, MIP provides transparent support for host mobility, including the maintenance of active Transmission Control Protocol (TCP) connections User gram Protocol (UDP) port bindings. In this scheme, a home agent a foreign agent are used to bind the home address of a mobile host (MH) to the care-of address at the visited network provide packet forwarding when the MH is moving between IP subnets. Triangular routing of all incoming packets to the mobile host via the home network can cause additional delays waste of bwidth capacity. If the correspondent host has knowledge of where the MH is located, it can send packets directly to the care-of address of the MH, thus enabling route optimization. The Session Initiation Protocol (SIP)-based approach [] aims to keep mobility support independent of the underlying wireless access technologies network layer elements. SIP is an application layer protocol. When an MH moves during an active session into a different network, it first receives a new network address, then sends a new session invitation to the correspondent host. Subsequent data packets are forwarded to the MH using this new address. Although both MIP- SIP-based approaches can provide some level of vertical hover support between UMTS WLANs, experiments have shown that it is difficult to maintain the continuity of ongoing data sessions during hover due to the long hover latency [, ]. Mobile users may experience quality of service (QoS) degradation or session disruption/termination during vertical hovers if these approaches are used. In this article we introduce a novel transport-layer scheme to support UMTS/WLAN vertical hovers. Unlike techniques based on MIP or SIP, this approach follows the end-to-end principle [7] in the Internet: anything that can be done in the end system should be done there. Since the transport layer is the lowest end-to-end layer in the Internet protocol stack, it is a natural cidate for verti- -8//$. IEEE IEEE Wireless Communications August

2 cal hover support. Moreover, in the transport layer approach, no third party other than the endpoints participates in vertical hover, no modification or addition of network components is required, which makes this approach universally applicable to all present future network architectures. In addition, user mobility in wireless networks has a significant impact on transport layer performance. A transport layer approach to vertical hover enables the end nodes to adapt the flow congestion control parameters quickly, thus offering the potential for significant performance enhancements. This approach is used in [8], which proposes a new set of migrate options for TCP to support mobility. However, the approach in [8] requires globally changing the widely deployed TCP, which is very difficult, if not impossible, in practice. A new transport layer protocol, Stream Control Transmission Protocol (SCTP) [9], has recently been accepted by the IETF as a Request for Comments (RFC), joining TCP UDP as a general-purpose end-to-end protocol above the IP layer. In this article we apply the multihoming feature the latest dynamic address reconfiguration (DAR) extension [] of SCTP, referred to as the mobile extension of SCTP (msctp) [], to support UMTS/WLAN vertical hover. SCTP was previously proposed to support hover over homogeneous wireless networks []. However, experimental results in [] show a long interruption time during an SCTP hover. In this article we apply SCTP to support vertical hover between heterogeneous wireless networks. We consider UMTS/WLAN vertical hover support via two types of SCTP configurations, single-homing asymmetric configuration [] dual-homing symmetric configuration [], apply SCTP message bundling [] to reduce hover latency. The performance of these configurations is evaluated by computer simulations. Results show that the proposed scheme can overcome the problem of long interruption time during hover, especially in the dual-homing SCTP configuration. The rest of this article is organized as follows. The next section describes the UMTS/WLAN vertical hover problem. We present an overview of msctp. We describe the protocol architecture procedures to support UMTS/WLAN vertical hover using msctp. We then present the simulation results to evaluate the hover latency throughput performance. Finally, we conclude the article. UMTS/WLAN VERTICAL HANDOVER Since UMTS WLANs will coexist to offer Internet access to end users, the integration of these networks to allow seamless switchover of services would be desirable from both the operator end user perspectives. In this section we describe integrated UMTS/WLAN systems several challenges in this integration, particularly the issue of seamless vertical hover. INTEGRATED UMTS/WLAN SYSTEMS There are two different ways to design an integrated UMTS/WLAN network architecture, defined as tight coupling loose coupling GGSN SGSN RNC Node B UMTS coverage Internet server Tight coupling GGSN:Gateway GPRS service node SGSN: Serving GPRS service node RNC: Radio network controller Figure. Integrated UMTS/WLAN systems. Internet Mobile client interworking [,, ]. Figure shows the architecture for UMTS/WLAN integration. In a tight coupling interworking architecture, a WLAN is connected to an UMTS core network in the same manner as other UMTS radio access networks. The WLAN gateway implements all the UMTS protocols (authentication, mobility management, etc.) required in the UMTS radio access network. In this approach, UMTS WLAN would use the same authentication, mobility, billing infrastructures. The main advantage of this solution is that the mechanisms for mobility, QoS, security in the UMTS core network can be reused directly over the WLAN. However, tightly coupled solutions will be highly specific to the UMTS technology require extensive access interface stardization of WLANs beyond the existing stards. Moreover, the configuration design of UMTS network elements, such as the serving General Packet Radio Service (GPRS) support node (SGSN) gateway GPRS support node (GGSN), have to be modified to sustain the increased traffic from WLANs. In the loose coupling approach, the WLAN gateway does not have any direct connection to UMTS network elements. Instead, it connects to the Internet. WLAN traffic would not go through the UMTS core network. In this approach, UMTS WLAN can use different mechanisms protocols to hle authentication, mobility, billing. Nevertheless, they can share the same subscriber database for functions such as security, billing, customer manage- WLAN coverage Loose coupling WLAN gateway Access point IEEE Wireless Communications August

3 OVERVIEW OF MOBILE SCTP A Mobile client... Router... Internet Router... Figure. SCTP support of seamless hover. Fixed server... Router... ment as peer IP domains. This scheme allows the independent deployment traffic engineering of UMTS WLAN. Network operators service providers can operate these two networks separately through roaming agreements. It is shown in [] that loose coupling offers several advantages over tight coupling, such as independent deployment traffic engineering of UMTS WLANs. VERTICAL HANDOVER BETWEEN UMTS AND WLAN Vertical hover between UMTS WLAN can be seen as the next evolutionary step from roaming in this integrated environment. Consider, for example, a laptop/hheld that supports both UMTS WLAN access capabilities. The end user of this mobile device is connected to the Internet via a WLAN at a hot spot. As the user moves out of the coverage of the hot spot, the mobile device detects the failing WLAN coverage switches the connection to a UMTS network. Similarly, when a mobile user connected to a UMTS network travels to a hot spot, the device detects the coverage of an overlaid WLAN. The end user may want to switch to WLAN access to enjoy the higher bwidth. Ideally, the end user would not be required to intervene in the vertical hover between these two networks, the QoS should not be degraded due to this hover. Therefore, the objective of designing a UMTS/WLAN vertical hover scheme is to make hover as seamless (with low latency negligible loss of data) efficient as possible. We introduce a new scheme to support UMTS/WLAN vertical hover using msctp, which is described in the following sections. B Mobile client... STREAM CONTROL TRANSMISSION PROTOCOL SCTP was originally designed as a specialized transport protocol for call control signaling in voice over IP (VoIP) networks has been specified by the rd Generation Partnership Project (GPP) to carry call signaling traffic in UMTS []. Recognizing that other applications could use SCTP s capabilities, the IETF has embraced SCTP as a general-purpose transport layer protocol. Like TCP, SCTP offers a point-to-point connection-oriented reliable delivery service for applications communicating over an IP network. It inherits many TCP functions at the same time incorporates many attractive new features. The most interesting new features of SCTP are partial reliability multihoming. Unlike TCP, which provides reliable deliveries, UDP, which provides unreliable deliveries, SCTP has a partial reliability mechanism, by which it can configure a reliability level. The reliability level defines how persistent an SCTP sender should be in attempting to send a message to the receiver (e.g., never retransmit, retransmit up to a certain time, retransmit until lifetime expires). The partial reliability mechanism benefits real-time traffic transferred during periods of poor QoS due to path failures or network congestion. One application of partial reliability is the delivery of real-time telephony signaling. Another core feature of SCTP is multihoming, which enables an SCTP session to be established over multiple interfaces identified by multiple IP addresses. SCTP normally sends packets to a destination IP address designated the primary address, but can reroute packets to an alternative secondary IP address if the primary IP address becomes unreachable. Accordingly, the path between two SCTP hosts using the primary address(es) is the primary path, a path between two SCTP hosts involving a secondary address is a secondary path. Note that two SCTP hosts can have only one primary path, but more than one secondary path. This type of session is defined as an association in SCTP. An SCTP association between two hosts, say, A B, is defined as {[a set of IP addresses at A] + [Port-A]} + {[a set of IP addresses at B] + [Port-B]}. Any of the IP addresses on either host can be used as a source or destination address in the IP packet. Before data can be exchanged, the two SCTP hosts must exchange the involved IP addresses in the association establishment stage. The multihoming mechanism is originally designed for fault-resilient communications between two SCTP endpoints over wired networks. This powerful feature has been exploited to support IP mobility using SCTP. Specifically, the SCTP DAR extension [], referred to as msctp [], can provide a simple but powerful framework for mobility support over IP networks. MOBILE SCTP In the base version of SCTP, the endpoints exchange all the IP addresses before the SCTP association is established, these IP addresses IEEE Wireless Communications August

4 UMTS layer layer Applications msctp IPv/IPv Mobile client WLAN layer layer Figure. Protocol architecture. IPv/IPv Layer layer cannot be changed during the session. However, in the integrated UMTS/WLAN environment, an MH may not have fixed, previously known IP addresses. Therefore, the base version of SCTP cannot be used directly to support UMTS/ WLAN vertical hover. Fortunately, the recently proposed DAR extension [] for SCTP enables the endpoints to add, delete, or change the IP addresses during an active SCTP association using address configuration (ASCONF) messages. This forms the basis of msctp [], the key address hling features of which are illustrated as follows. Without loss of generality, we use a clientserver model in the example, where a mobile client (MC) communicates with a fixed server (FS) using msctp, as shown in Fig.. In IP implementations, the outgoing interface of a multihomed host is often determined by the destination IP address. The mapping of outgoing source IP address destination address is done by a lookup in the host routing table maintained by the operating system. Assume that the MC uses IP address... at location A. Traffic between the MC FS is routed through router. When the MC moves from location A to location B, it detects the coverage of router gets a new IP address,... To add this new IP address to the SCTP association, the MC sends an ASCONF(Add IP Address,...) message to the FS. Note that the traffic is still routed through router since it is the primary choice. During the overlap time, when the signal from router becomes strong enough, the MC sends an ASCONF(Set Primary Address,...) message to the FS. Router becomes the primary router over which the MC s traffic is routed. The routing tables are changed in the MC FS accordingly. When the signal from router becomes too weak to support communications, the MC deletes IP address... from the association by sending an ASCONF(Delete IP Address,...) message to the FS. SUPPORTING UMTS/WLAN VERTICAL HANDOVER USING MSCTP In this section we introduce a new scheme to support UMTS/WLAN vertical hover using msctp. The rationale behind the proposed scheme is that, due to the multihoming feature of msctp, from the association point of view it does not matter whether an endpoint s network interfaces belong to the same network or not. As long Network nodes IPv/IPv Layer layer Applications msctp IPv/IPv Layer layer Fixed server 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. Particularly, msctp s capabilities to add, delete, change the IP addresses dynamically during an active SCTP association provides an end-to-end UMTS/WLAN vertical hover solution. Since no addition or modification of network components is required, the proposed scheme has a network architecture that is much simpler than those required by network layer or application layer solutions. We describe the protocol architecture the procedure in the proposed vertical hover scheme in the following subsections. PROTOCOL ARCHITECTURE Figure shows the simplified protocol architecture of the proposed scheme. Both the MC FS are assumed to implement msctp. In addition, we require both endpoints to implement SCTP message bundling. The MC supports both UMTS WLAN at the physical data link layers. There is no additional protocol requirement for other network nodes. To allow access to any FSs over the Internet in general, recognizing that at the present time these FSs are likely to support TCP rather than msctp, the FS in Fig. can in fact be a proxy server that provides msctp associations with MCs over UMTS/WLAN while connecting to other FSs via TCP over the Internet. VERTICAL HANDOVER PROCEDURES Using the multihoming feature of SCTP, an MC can have two IP addresses during vertical hover, one from the UMTS the other from the WLAN. Similarly, an FS can also be configured for: Single-homing: The FS provides only one IP address to support hover. Dual-homing: The FS allows more than one (usually two) IP addresses to support hover. Note that almost all servers in the current Internet are configured with only one IP address. Therefore, configuring each server with more than one IP address is not an easy task. This is why the authors of [] argue that it is natural to consider FS supporting hover with only one IP address as a fixed host should not add new IP addresses dynamically. However, the authors in [] suggest that a server should use multiple IP addresses to provide the MC with multiple paths in order to fully take advantage of the existence of a second interface at the MC for fault Since no addition or modification of network components is required, the proposed scheme has a network architecture that is much simpler than those required by network-layer or application-layer solutions. IEEE Wireless Communications August 7

5 Note that almost all servers in the current Internet are configured with only one IP address. Therefore, configuring each server with more than one IP addresses is not an easy task. MC UMTS_IP MC WLAN_IP FS FS_IP ASCONF (Add IP Address, WLAN_IP) UMTS->WLAN ASCONF (Set Primary Address, WLAN_IP) ASCONF (Set Primary Address, WLAN_IP) WLAN->UMTS ASCONF (Delete IP Address, WLAN_IP) Figure. The vertical hover procedure (the FS is in a single-homing configuration). resilience. Which configuration (single-homing or dual-homing) should be used in an FS supporting hover is still an ongoing research topic. In this article the detailed hover procedures of both single-homing multihoming configurations are presented, the hover performance of the two configurations are compared. The vertical hover procedures of the single-homing dual-homing configurations are shown in Figs., respectively. For each of these configurations, the hover procedure has three basic steps: Add IP address Vertical hover triggering Delete IP address Note that UMTS-to-WLAN hover is shown in the upper part, hover in the reverse direction is in the lower part of each figure. The hover procedures are described as follows. Single-Homing FS In this case, an FS is configured with only one IP address, say, FS_IP. Assume that an MC has been allocated with an IP address, UMTS_IP, in a UMTS cell using this IP address to communicate with the FS via msctp. When the MC moves into a WLAN cell covered by a UMTS cell, it gets a new IP address, WLAN_IP, starts the add IP address process. The MC informs the FS of its new IP address by sending an ASCONF message to the FS with parameters set to add IP address WLAN_IP. The vertical hover triggering process allows the MC to trigger a hover based on some decision rules. The UMTS-to-WLAN hover is triggered by the MC sending an ASCONF message with parameters set to set primary address WLAN_IP. After the MC receives an acknowledgment (ACK) from the FS, the WLAN becomes the primary choice, the traffic between the MC the FS is routed through the WLAN. The WLAN-to-UMTS hover is triggered by the MC sending an ASCONF message with parameters set to set primary address UMTS_IP. After the MC receives an ACK from the FS, the UMTS becomes the primary choice, the traffic between the MC the FS is routed though the UMTS. If the MC loses the signal from the WLAN cell, it starts the delete IP address process. The MC sends an ASCONF message with parameters set to delete IP address WLAN_IP to request that the FS release the address WLAN_IP from its host routing table. After the MC receives an ACK from the FS, it deletes WLAN_IP from its address list, WLAN_IP is released from the association. In this configuration, because of the hshake process, the overall hover delay can be calculated as Delay overall = T ASCONF + T hover, where T ASCONF, the ASCONF ASCONF_ ACK transmission time, is ASCONF _ Chunk _ Size Bwidth, + Propagation_ Delay T hover is the change-over comm delay buffered data transfer time. Dual-Homing FS In this case the FS is configured with two IP addresses, say, FS_IP_ FS_IP_, as shown in Fig.. At the beginning of the procedure, UMTS_IP FS_IP_ are the primary IP addresses of the MC FS, respectively. There are two differences between this procedure that for a single-homing FS. The first difference is the add/delete IP address processes. In the dualhoming configuration, when the FS responds to the MC s add/delete IP address request with an 8 IEEE Wireless Communications August

6 MC UMTS_IP MC UMTS_IP FS FS_IP_ FS FS_IP_ ASCONF (Add IP Address, WLAN_IP) bundles with ASCONF (Add IP Address, FS_IP_) UMTS->WLAN ASCONF (Delete IP Address, WLAN_IP) WLAN->UMTS bundles with ASCONF (Delete IP Address, FS_IP_) The Vertical Hover Triggering process allows the MC to trigger a hover based on some decision rules. The UMTS to WLAN hover is triggered by the MC sending an ASCONF message with parameters set to Set Primary Address WLAN_IP. Figure. The vertical hover procedure (the FS is in a dual-homing configuration). ACK, the FS bundles an ASCONF to request the MC to add/delete the FS s secondary IP address into/from the association. The MC then sends an ACK to confirm the completion of the add/delete IP address process. The second difference is in the hover triggering process. Since both the MC FS are in dual-homing configuration, the MC can directly set the FS s secondary address as the primary destination in its host routing table start to send data on the new link. In this case, the hover delay becomes Delay overall = T hover. Since in the dual-homing configuration there is no hshake process in the vertical hover triggering process, the hover delay is smaller than that in the single-homing case. SIMULATION RESULTS AND DISCUSSIONS In this section we present discuss the simulation results of the proposed scheme. The objective of the simulations is to evaluate two critical performance metrics, UMTS/WLAN hover delay overall throughput for each of the two configurations described earlier. We use network simulator ns- to perform the simulations obtain the results reported in this article. We extend the SCTP module in ns- so that the multihoming feature can work over wireless links. The IEEE 8. WLAN model in ns- is used to represent the medium access control (MAC) layer. The bwidths are set to be 8 kb/s for the UMTS link Mb/s for the WLAN link. The network propagation delay is set to ms. FTP traffic is started at the MC at time s. The hover triggering process is activated at time s. We examine the impacts of the different FS configurations on the delay throughput performance. Figures 7 show the delay performance for vertical hover from UMTS to WLAN in the reverse direction, respectively. When the FS is in single-homing configuration, the hover delay is the time interval in which the FS receives the first packet on the new primary link the last packet on the old primary link. According to the simulation results, the UMTSto-WLAN hover delay is ms in Fig. a, WLAN-to-UMTS delay is ms in Fig. 7a. When FS is in dual-homing configuration, the hover delay is the time interval in which the FS receives the same transmission sequence number on both links. These two hover delays are reduced to ms in Fig. b ms in Fig. 7b, respectively. This is because when the FS is in single-homing configuration, the MC sends a set primary address request to trigger a hover, thus increasing the overall delay with a hshake processing time. However, when the FS is in dualhoming configuration, the MC can trigger a hover by directly setting the FS s secondary address; therefore, the hover delays in both directions are reduced significantly. Figure 8 shows the throughput performance for vertical hover in both directions. We can see that the throughput (bits per second) of an FS in a dual-homing configuration is much higher than that of an FS in a single-homing configuration. This is because, besides the delay advantage, a dual-homing FS allows both the MC FS to operate in a symmetric multihomed configuration. This configuration enables easy distinction of the two paths between the MC FS, so the redundant path can help provide fault tolerance to data transmission during hover. In the simulations buffered data are sent over both old new connections when a changeover of primary secondary paths occurs. In this way, packet loss retransmis- IEEE Wireless Communications August 9

7 Transmission sequence number Packets on WLAN link Packets on UMTS link Transmission sequence number Packets on WLAN link Packets on UMTS link (a) (b) Figure. Delay performance of the proposed vertical hover scheme (from UMTS to WLAN) with the FS in a) single-homing; b) dual-homing configuration. sion delay can be avoided. Duplicated packets are dropped by the receiver, different strategies may be employed by the sender receiver to adapt flow, congestion, other QoS control parameters easily quickly during after hover. In Fig. 8 we also observe that SCTP readily copes with the sudden change of link bwidth during a vertical hover. Going from low bwidth to high bwidth in a UMTS-to-WLAN hover results in SCTP going into slow start, whereas going in the reverse direction from high-bwidth WLAN to low-bwidth UMTS, SCTP congestion avoidance control is activated. CONCLUSIONS A new method to support UMTS/WLAN vertical hover using SCTP, more specifically a dynamic address reconfiguration extension called msctp, has been proposed in this article. Although UMTS/WLAN vertical hover has been presented for current interest, the proposed method is useful for supporting vertical hover between any heterogeneous wireless networks in general is not limited to UMTS WLAN. We have studied different scenarios employing single-homing dual-homing fixed servers to support hover. Simulation results show that delay throughput performance can be improved significantly using the dualhoming configuration with message bundling. In the dual-homing configuration, duplicated buffered data transmission over both old new paths may help the receiver sender to adapt to a sudden change in link characteristics easily quickly during after a vertical hover. REFERENCES [] A. K. Salkintzis, C. Fors, R. Pazhyannur, WLAN- GPRS Integration for Next-generation Mobile Networks, IEEE Wireless Commun., vol. 9, no., Oct.. pp.. Packets on UMTS link Packets on UMTS link Transmission sequence number Packets on WLAN link Transmission sequence number Packets on WLAN link (a) (b) Figure 7. Delay performance of the proposed vertical hover scheme (from WLAN to UMTS) with the FS in a)single-homing; b) dual-homing configuration. IEEE Wireless Communications August

8 9 Overall throughput at receiver (b/s) 8 7 FS is in dual homing FS is in single homing Overall throughput at receiver (b/s) 8 FS is in dual homing FS is in single homing (a) (b) Figure 8. Throughput performance of the proposed vertical hover scheme; hover a) from UMTS to WLAN; b) from WLAN to UMTS. [] M. Buddhikot et al., Integration of 8. Thirdgeneration Wireless Networks, Proc. IEEE INFO- COM, San Francisco, CA, Apr.. [] C. E. Perkins, IP Mobility Support, RFC, Oct. 99. [] H. Schulzrinne E. Wedlund, Application-Layer Mobility Using SIP, ACM Mobile Comp. Commun. Rev., vol., no., July, pp [] W. Xing, H. Karl, A. Wolisz, M-SCTP: Design Prototypical Implementation of an End-to-End Mobility Concept, Proc. th Int l. Wksp., Berlin, Germany, Oct.. [] P. A. Pangalos et al., End-to-end SIP based Real Time Application Adaptation During Unplanned Vertical Hovers, Proc. IEEE GLOBECOM, San Antonio, TX, Nov.. [7] J. H. Saltzer, D. P. Reed, D. D. Clark, End-to-end Arguments in System Design, ACM Trans. Comp. Sys., vol., no., Nov. 98, pp [8] A. C. Snoeren H. Balakrishnan, An end-to-end Approach to Host Mobility, Proc. ACM Mobicom, Boston, MA, Aug.. [9] R. Stewart et al., Stream Control Transport Protocol, IETF RFC 9, Oct.. [] R. Stewart et al., Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration, draft-ietf-tsvwgaddip-sctp-8.txt, Sept., work in progress. [] M. Riegel M. Tuexen, Mobile SCTP, draft-riegel-tuexen-mobile-sctp-.txt, Aug., work in progress. [] S. J. Kohet al., Mobile SCTP for Transport Layer Mobility, draft-sjkoh-sctp-mobility-.txt, Feb., work in progress. [] R. Stewart Q. Xie, Stream Control Transmission Protocol, a Reference Guide, Addison Wesley Longman,. [] A. K. Salkintzis, The EAP-GPRS Protocol for Tight Integration of WLANs G Cellular Networks, Proc. IEEE VTC Fall, Orlo, FL, Oct.. [] GPP, UTRAN Iub Interface: Signaling transport, GPP TS., v..., Dec.. BIOGRAPHIES LI MA (marym@ece.ubc.ca) received a B.Eng. degree in applied mathematics from Beijing University of Aeronautics Astronautics in 99 an M.A.Sc. degree in electrical engineering from the University of British Columbia (UBC), Canada, in. From 99 to she was a network engineer in the Technical Center of Guangdong Post Telecom, a software engineer in Singapore Telecom, a network planner in C Communications Inc. Her research interests are UMTS/WLAN integration using Stream Control Transmission Protocol (SCTP) modeling SCTP in wireless networks. FEI YU [S, M ] (feiy@ece.ubc.ca)received an M.S. degree in computer engineering from Beijing University of Posts Telecommunications in 998, a Ph.D. degree in electrical engineering from UBC in. From 998 to 999 he was a system engineer at China Telecom, working on the planning, design, performance analysis of national SS7 GSM networks. From to he was a research development engineer at Ericsson Mobile Platforms, Sweden, where he worked on dual-mode UMTS/GPRS hsets. He is currently a postdoctoral research fellow at UBC. His research interests are quality of service, cross-layer design, mobility management in wireless networks. VICTOR C. M. LEUNG [S 7, M 89, SM 97, F ] (vleung@ece. ubc.ca) received a B.A.Sc. (Hons.) degree in electrical engineering from UBC in 977, was awarded the APEBC Gold Medal as head of the graduating class in the Faculty of Applied Science. He attended graduate school at UBC on a Natural Sciences Engineering Research Council Postgraduate Scholarship obtained a Ph.D. degree in electrical engineering in 98. From 98 to 987 he was a senior member of technical staff at Microtel Pacific Research Ltd. (later renamed MPR Teltech Ltd.), specializing in the planning, design, analysis of satellite communication systems. He also held a part-time position as visiting assistant professor at Simon Fraser University in In 988 he was a lecturer in the Department of Electronics at the Chinese University of Hong Kong. He joined the Department of Electrical Engineering at UBC in 989, where he is a professor, holder of the TELUS Mobility Industrial Research Chair in Advanced Telecommunications Engineering, a member of the Institute for Computing, Information Cognitive Systems. His research interests are in the areas of architectural protocol design performance analysis for computer telecommunication networks, with applications in satellite, mobile, personal communications, high-speed networks. He is a Fvoting member of ACM. He is an editor of IEEE Transactions on Wireless Communications an associate editor of IEEE Transactions on Vehicular Technology. He is the Technical Programming Committee (TPC) Co-Chair in networking for IEEE WCNC, New Orleans, Louisiana, has served on the TPCs of numerous international conferences. TEJINDER S. RANDHAWA (tejinder_rhawa@bcit.ca) until recently was a research scientist at the New Media Innovation Center (NewMIC), Vancouver, Canada, where he led research development of software defined radios, vertical hoffs, mobile ad hoc networks in the Wireless group. Prior to NewMIC, he worked in industry for years, holding senior positions with Acterna, Microtel Pacific Research (MPR) Teltech, MacDonald Dettwiler & Associates, Atomic Energy of Canada Ltd. He is a faculty member at the British Columbia Institute of Technology an adjunct professor at Simon Fraser University, has taught graduate senior undergraduate level courses in wireless network protocols, data network protocols, distributed systems, network security, database systems for several years. He received his Ph.D. in engineering science from Simon Fraser University (). He has Master s degrees from both Simon Fraser University (997) the University of Saskatchewan (988). He has co-authored a book more than IEEE technical papers. IEEE Wireless Communications August