MOBOPTS Research Group A. Dutta (Ed.) Internet-Draft Telcordia Expires: April 20, 2006 Y. Ohba TARI H. Yokota KDDI R&D Labs H. Schulzrinne Columbia Univ. October 17, 2005 Problem Statement for Heterogeneous Handover draft-ohba-mobopts-heterogeneous-requirement-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 20, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes the problem statement and a set of issues and requirement specific to heterogeneous handover. Careful consideration needs to be given to these set of requirements while Dutta (Ed.), et al. Expires April 20, 2006 [Page 1] Internet-Draft Heterogeneous Handover October 2005 designing an optimized handover framework in a heterogeneous mobility scenario. These problem statements help determine the key functions that are responsible for delay during handover involving interdomain and heterogeneous access technology. Analysis of these issues and requirements can be applied to any existing mobility optimization framework. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Handover Taxonomy . . . . . . . . . . . . . . . . . . . . . . 4 3. Performance Requirements . . . . . . . . . . . . . . . . . . . 7 4. Handover Delay Analysis . . . . . . . . . . . . . . . . . . . 9 5. Optimizing Handover Delay . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1 Normative References . . . . . . . . . . . . . . . . . . . 15 9.2 Information References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . 18 Dutta (Ed.), et al. Expires April 20, 2006 [Page 2] Internet-Draft Heterogeneous Handover October 2005 1. Introduction Handover is a process by which a mobile node moves from one point of attachment to another point of attachment in a network. This handover can be primarily classified into homogeneous and heterogeneou handover. Heterogeneous handover includes movement between various types of wireless networks and different administrative domains. Supporting terminal handovers across heterogeneous access networks such as CDMA, 802.11 and GPRS is a clear challenge, as each access network has different QoS, security and bandwidth characteristics. Similarly movement between two different kinds of domains poses a challenge since a mobile will need to re-establish authentication and authorization as well in the new domain and each administrative domain may or may not have any prior security arrangement. In order to be able to provide an optimized handover solution for a heterogeneous handover case, it is essential to determine the key functions that contribute to the handover delay. Determining these key functions help define the right set of mechanism needed to design an optimized handover framework. In this document, we introduce the concept of heterogeneous handover, illustrate the key performance characteristics requirement for a real-time communication, cite alternate scenarios that represent a heterogeneous handover involving different access technologies and different administrative domains. We discuss several challenges, problems and issues that give rise to handover delay, packet loss and jitter during the heterogeneous handover. These issues and problem sets can be used as guidelines while designing an optimized heterogeneous handover solution. Dutta (Ed.), et al. Expires April 20, 2006 [Page 3] Internet-Draft Heterogeneous Handover October 2005 2. Handover Taxonomy An access network is defined as the backhaul network that provides the first hop or last hop access to the mobile in an end-to-end communication system. When a mobile during an active communication session moves from one access network to another access network and changes its point of attachment it is subjected to disruption in continuity of service. During the handover, as the mobile changes its point-of-attachment in the network a mobile terminal may end up communicating using its second interface in the new network, change its subnet or domain it is connected to. Based on the type of movement and access network we can primarily define the handover in the following ways. Thus we can define following combination of handovers in our analysis. Primarily these could be categorized as A) Inter-subnet and B) Intra-subnet. An Inter-subnet Handover can comprise the following combination of handover that fall into category A. 1) Inter-technology, Inter-domain 2) Inter-technology, Intra-domain 3) Intra-technology, Inter-domain 4) Intra-technology, Intra-domain An intra-subnet handover can consist of the following types of handover that fall into category B. 1) Intra-Tech, Intra-domain 2) Inter-Tech, Intra-domain Heterogeneous handover is a handover that requires authorization for acquisition or modification of resources assigned to a mobile and the autorization needs interaction with a central authority in a domain. In many cases an authorization procedure in a heterogeneous handover follows an authentication procedure that also requires interaction with a central authority in a domain. All the scenarios A-1, A-2, A-3, A-4 B1 and B-2 described above could cover the scope of heterogeneous handover. These will be more clear as we describe different types of handoff scenarios in the following sections. Dutta (Ed.), et al. Expires April 20, 2006 [Page 4] Internet-Draft Heterogeneous Handover October 2005 +-------------+------------+ | | | |INTERTECH |INTERTECH | | INTERDOMAIN |INTRADOMAIN | | | | | | | INTERSUBNET +-------------+------------+ | | | | INTRATECH |INTRATECH | | INTERDOMAIN |INTRADOMAIN | | | | | | | +-------------+------------+ | | | | INTRASUBNET | INTRATECH & INTRA DOMAIN | |--------------------------| | INTERTECH & INTRA DOMAIN | | | +--------------------------+ Figure 1: Handover Taxonomy Intra-subnet: When a mobile moves between two radio access networks that are part of the same subnet and does not change its layer 3 identifier (i.e. IP address), it is called Intra-subnet handover. During an intra-subnet handover, the mobile may be subjected to an inter-technology handover as well if both the access networks with different radio access technologies (e.g.,CDMA, 802.11) belong to the same subnet. However during an intra-subnet and inter-technology handover, the L3 identifier of the terminal may change if the terminal starts to communicate using an interface that is part of a different access network. Inter-subnet: A mobile is subjected to an Inter-subnet handover when it moves between two different radio access networks that belong to two different subnets. As a result, its L3 identifier (e.g., IP address) is changed thus giving rise to a need for any mobility management protocol such as Mobile IP [RFC3344], Mobile IPv6 [RFC3775], SIP-Mobility [SIPMM], HIP [I-D.ietf-hip-base] that can take care of the continuity of the existing application. An Inter- subnet handover can be viewed as a super set of all types of handover scenarios and may include intra-domain, Inter-domain, Inter- technology or Intra-technology handover. All of these types of handovers are described in this document. Inter-subnet handover potentially gives rise to packet loss and jitter because of delay Dutta (Ed.), et al. Expires April 20, 2006 [Page 5] Internet-Draft Heterogeneous Handover October 2005 associated with transition at layer 2 and layer 3. Inter-technology: A mobile may be equipped with multiple interfaces, where each interface can support different access technology (802.11, CDMA). A mobile may like to communicate with one interface at any time in order to conserve the power. During the handover the mobile may move out of the footprint of one access technology (e.g., 802.11) and move into the footprint of a different access technology (e.g., CDMA). This will warrant switching of the communicating interface on the mobile as well. This type of Inter-technology handover is often called as Vertical Handover since the mobile makes moevement between two different cell sizes. A vertical handover can be termed as upward vertical handover or downward vertical handover based on the direction of movement such as smaller cell to larger cell or vice versa [vertical]. A mobile moving from 802.11 network to cellullar network can be viewed as upward vertical handover. An intertechnlogy handover may affect the quality-of-service of the multimedia communication, since each access network offers different bandwidth. Intra-technology: An intra-technology handover is defined when a mobile moves between the same type of access technology such as between 802.11[a,b,n] and 802.11 [a,b,n] or between CDMA1XRTT and CDMA1EVDO. In this scenario a mobile may be equipped with a single interface (with multiple PHY types of the same technology) or with multiple interfaces. An Intra-technology handover may involve intra- subnet or inter-subnet movement and thus may need to change its L3 identifier as it moves. Inter-domain: A domain can be defined in several ways. But for the purposes of roaming we define domain as an administrative domain which consists of networks that are managed by a single administrative entity which authenticates and authorizes a mobile for accessing the networks. An administrative entity may be a service provider, an enterprise and any organization. As a mobile moves between two administrative domains, it is also subjected to inter- subnet handover, as two different domains are assumed to be part of two different subnets. Thus an Inter-domain handover will by-default be subjected to inter-subnet handover and in addition it may be subjected to either inter-technology or intra-technology handover. Inter-domain handover will be sujected to all the transition steps a subnet handover goes through in addition to an authentication process. These extra steps contribute to additional delay on the top of delays due to regular subnet handover. Intra-domain: When a mobile's movement is confined to movement within an administrative domain it is called intra-domain movement. An intra-domain movement may involve intra-subnet, inter-subnet, intra- technology and inter-technlogy as well. Dutta (Ed.), et al. Expires April 20, 2006 [Page 6] Internet-Draft Heterogeneous Handover October 2005 3. Performance Requirements In order to provide desirable quality of service for interactive VoIP and streaming traffic, one needs to limit the value of end-to-end delay, jitter and packet loss to a certain threshold level. ITU-T and ITU-E standards define the acceptable values for these parameters. For example for one-way delay, ITU-T G.114 recommends 150 ms as the upper limit for most of the applications, and 400 ms as generally unacceptable delay. One way delay tolerance for video conferencing is in the range of 200 to 300 ms. Also if an out-of- order packet is received after a certain threshold it is considered lost. References [RFC2679], [RFC2680] and 2681 [RFC2681] describe some of the measurement techniques for delay and jitter. An end-to-end delay consists of several components, such as network delay, operating system (OS) delay, CODEC delay and application delay. Network delay consists of transmission delay, propagation delay, queueing delay in the intermediate routers. Operating System related delay consists of scheduling behavior of the operating system in the sender and receiver. CODEC delay is generally caused due to packetization and depacketization at the sender and receiver end. Application delay is mainly attributed to playout delay that helps compensate the delay variation within a network. End-to-end delay and jitter values can be adjusted using proper value of the playout buffer at the receiver end. In case of interactive VoIP traffic, end-to-end delay affects the jitter value and is an important issue to consider. During a mobile's frequent handover, transient traffic cannot reach the mobile and this contributes to the jitter as well. If the end system has a playout buffer, then this jitter is subsumed by the playout buffer delay, but otherwise this adds to the delay for interactive traffic. Packet loss is typically caused by congestion, routing instability, link failure, lossy links such as wireless links. During a mobile's handover a mobile is subjected to packet loss because of its change in attachment to the network. Thus for both streaming traffic and VoIP interactive traffic packet loss will contribute to the service quality of the real-time application. Number of packets lost is proportional to the delay during handover and rate of traffic the mobile is receiving. Lost packets contribute to congestion in case of TCP traffic because of re-transmission, but it does not add to any congestion in case of streaming traffic that is RTP/UDP based. Thus it is essential to reduce the packet loss and effect of handover delay in any mobility management scheme. We provide some instances of performance requirement here. For example, according to ETSI TR 101 [ETSI] a normal voice conversation can tolerate up to 2% packet loss. If a mobile is subjected to frequent handover during a conversation, each handover will contribute to packet loss for the period of handover. Thus maximum Dutta (Ed.), et al. Expires April 20, 2006 [Page 7] Internet-Draft Heterogeneous Handover October 2005 loss during a conversation needs to be reduced to an acceptable level. There is no clear threshold value for packet loss for streaming application, but it needs to be reduced as much as possible to provide better quality of service to a specific application. Dutta (Ed.), et al. Expires April 20, 2006 [Page 8] Internet-Draft Heterogeneous Handover October 2005 4. Handover Delay Analysis Effects of Heterogeneous handover: We analyze the handover delay associated with heterogeneous handover and the factors that contribute to this. As a mobile goes through a heterogeneous handover process, it is subjected to handover delay because of the rebinding of properties at several layers of the protocol stack. There are several common properties that may contribute to the rebinding of these layers. These properties can mostly be attributed to things such as access characteristics (e.g., bandwidth, channel characteristics), access mechanism (e.g. CDMA, CSMA/CA, TDMA), configuration of layer 3 parameters, re-authentication, re- authorization, rebinding of security association at all layers. During any handover procedure any multimedia application running within a client gets affected because of the delays incurred within each of the layers of the protocol stack. Next we look at every layer and analze rebinding of some of these common properties at each layers as a client is subjected to heterogeneous handover. Layer 2 delay: Depending upon the access type (e.g., 802.11, CDMA), the mobile goes through several transition steps, before the new layer 2 link is re-established. As an example an 802.11 link goes through the process of scanning, authentication and association during the reattachment to the new 802.11 access network. Similarly other access networks such as CDMA and GPRS networks go through a series of state transitions during their reasociation to the new point of attachment. Each of these state transitions contributes to certain delays as the mobile goes through each of these transition. After a new link is established, depending upon type of handover scenario, other layers in the protocol need to get rebound. For example in case of intra-technology, intra-subnet handover, there is no other layer besides layer 2 that is affected and the handover delay is attributed to the delay due to layer 2 transitions only. Even in the case of handoff consisting of intra-domain, intra- technology, intra-subnet handoff where there is layer 2 delay only, some sort of authorization procedure needs to be performed when swithing to the new access network. The procedure may take more steps if layer-2 characteristics such as QoS characteristics are different betweeen the old and new access networks than the case where layer-2 chatersteristics are the same betweeen the old and new access networks. So the difference of layer-2 characteristics can qualify a intra-technology handover as a heterogeneous handover as well. Thus the scenario B-1 may also qualify to be a heterogeneous handover. Layer 3 delay: A layer 3 transition process goes through several steps such as new IP address acquisition, duplicate address Dutta (Ed.), et al. Expires April 20, 2006 [Page 9] Internet-Draft Heterogeneous Handover October 2005 detection, ARP update, and local authentication. Where a successful local authentication allows the mobile to send packets beyond the first hop router. For example in some cases there is some authorization process involved even before a new IP address is obtained. Methods of IP address acquisition are different based on if it is IPv4, IPv6 and access network is LAN or WAN. There are several protocols such as DHCP, DHCPv6, PPP or stateless autoconfiguration that can be used to take care of IP address acquisition. Each of these methods may take different amount of time for a layer 3 transition to complete. After a layer 3 transition is complete and layer 3 address is re-established, there are certain functions in the upper layer that need to be completed. These include functions such as sending the binding update from the mobile, media redirection at the sending host. Delays incurred due to these functioncs can be attributed to transport delay, processing delay at the end hosts etc. In the inter-subnet mobility category which is intra-domain a minimal authorization procedure is needed to obtain and use the IP address in the new subnet. But the required steps can be minimized if already established security contexts in the domain are utilized for the procedure. But inter-subnet, inter-domain mobility may need additional authorization process. Application layer delay: In a typical inter-domain mobility scenario independent of inter-technology or intra-technology handoff, an authentication and authorization procedure would need to be executed for establishing layer 2 and layer 3 properties from scratch in the new domian. This can be an extraordinally undesired delay component during handoff. References [multinetwork], [hybrid], [interdomain] are few examples of inter-subnet handover involving inter-domain mobility that provide some case studies. If the inter-subnet handover involves inter-domain mobility, then the delay introduced due to authentication and authorization procedure adds to the handover latency and consequently affects the ongoing multimedia sessions. The authentication and authorization procedure may include EAP authentication where an AAA server may be involved in EAP messaging during the handover. Depending upon the type of architecture, in some cases the AAA signals traverse all the way to the AAA server in the home domain of the mobile as well before the network service is granted to the mobile in the new network. Thus it is desirable that interactions between the mobile and AAA servers must be avoided or be reduced during the handover. By way of expedited registrations, these interaction can be reduced. But it is more desirable if these can be avoided altogether during the handover itself. Dutta (Ed.), et al. Expires April 20, 2006 [Page 10] Internet-Draft Heterogeneous Handover October 2005 5. Optimizing Handover Delay Optimizing the handover delays: Thus it is evident that a mobile is subjected to different amount of delay based on the types of handover it is subjected to. For example an intra-subnet, intra-technology handover will take much less time than inter-subnet and inter- technology handover, because the mobile goes through a less number state transitions during the handover process. Thus there are certain common properties such as characteristics of the access network, security association at each layers of the protocol stack during re-attachment, ways of layer 3 binding (e.g., obtaining IP address, binding update, media redirection), authorization, authentication in the new network play an important role to determine the overall handover delay. Thus a heterogeneous handover will be subjected to higher handover delay compared to complete homogeneous handover (e.g.,a combination of intra-technology, intra-domain, intra-subnet). Thus it is desirable to devise a mechanism or framework that will help reduce these handover delays either by executing these state transitions in parallel or completing some of these proactively ahead of time. A simple example may be to reduce the handover delay by discovering the new point of attachment, preconfiguring the new L3 identifier, sending the binding update proactively or limiting it within a certain boundary limit and completing the authentication and authorization ahead of time prior to the movement into the new network. There are several optimized mobility management solutions at different layers, [RFC4068], [RFC4140],[I-D.ohba-mobopts-mpa- framework], [SIPFAST], currently proposed that attempt to reduce these handover delay and mitigate the effect of handover delay. Dutta (Ed.), et al. Expires April 20, 2006 [Page 11] Internet-Draft Heterogeneous Handover October 2005 6. Security Considerations This document describes the problem statement and issues associated with heterogeneous handover. Any framework supporting optimized heterogeneous handover will need to make sure that the signaling and data are properly secured during the handover. This security mechanism can be provided at any layer of the protocol stack. Dutta (Ed.), et al. Expires April 20, 2006 [Page 12] Internet-Draft Heterogeneous Handover October 2005 7. IANA Considerations This document has no actions for IANA. Dutta (Ed.), et al. Expires April 20, 2006 [Page 13] Internet-Draft Heterogeneous Handover October 2005 8. Acknowledgments Authors would like to acknowledge Kenichi Taniuchi, Victor Fajardo and Subir Das for many helpful discussion. Dutta (Ed.), et al. Expires April 20, 2006 [Page 14] Internet-Draft Heterogeneous Handover October 2005 9. References 9.1 Normative References [ETSI] ETSI, "Telecommunications and Internet Protocols Harmonization Over Networks (TIPHON) Release 3: end-to-end Quality of Service in TIPHON systems; Part 1: General aspects of Quality of Service.", ETSI TR 101 329-6 V2.1.1. 9.2 Information References [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999. [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [I-D.ietf-hip-base] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-03 (work in progress), June 2005. [RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. [RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005. [I-D.ohba-mobopts-mpa-framework] Ohba, Y., "A Framework of Media-Independent Pre- Authentication (MPA)", draft-ohba-mobopts-mpa-framework-01 (work in progress), July 2005. [SIPMM] Schulzrinne, H. and E. Wedlund, "Application Layer Mobility USing SIP", ACM MC2R. [SIPFAST] Dutta, A., Madhani, S., Chen, W., Altintas, O., and H. Schulzrinned, "Fast handoff Schemes for Application Layer Mobility Management", PIMRC 2004. Dutta (Ed.), et al. Expires April 20, 2006 [Page 15] Internet-Draft Heterogeneous Handover October 2005 [vertical] Stemm, M. and R. Katz, "Vertical handoffs in wireless overlay networks", Mobile Network Applications 1998. [multinetwork] McNair, J. and F. Zhu, "Vertical Handoffs in Fourth- Generation Multinetwork Environments", IEEE Wireless Communications June 2004. [hybrid] Politis, C., Ann Chew, K., Akhtar, N., Georgiades, M., Tafazolli, R., and T. Dagiuklas, "Hybrid Multilayer Mobility Management with AAA context transfer capabilities of All-IP Networks", IEEE Wirless Communications August 2004. [interdomain] Dutta, Das, Li, Ohba, Baba, and Schulzrinne, "Secured Mobile Multimedia Communication for Wireless Internet", IEEE ICNSC 2004 March 2004. Authors' Addresses Ashutosh Dutta Telcordia Technologies 1 Telcordia Drive Piscataway, NJ 08854 USA Phone: +1 732 699 3130 Email: adutta@research.telcordia.com Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscataway, NJ 08854 USA Phone: +1 732 699 5305 Email: yohba@tari.toshiba.com Dutta (Ed.), et al. Expires April 20, 2006 [Page 16] Internet-Draft Heterogeneous Handover October 2005 Hidetoshi Yokota KDDI R&D Labs 2-1-15 Ohara Fujimino-Shi Saitama, Japan 356-8502 Japan Phone: +81 49 278 7894 Email: yokota@kddilabs.jp Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 USA Phone: +1 212 939 7004 Email: hgs@cs.columbia.edu Dutta (Ed.), et al. Expires April 20, 2006 [Page 17] Internet-Draft Heterogeneous Handover October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Dutta (Ed.), et al. Expires April 20, 2006 [Page 18]