Network Working Group Eric. Njedjou Internet Draft France Telecom Expires April 2006 October 2005 IP location update for Network Controlled Mobility Management: Problem Statement draft-njedjou-mobopts-iplocup-netcomm-problem-00.txt 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 a "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html" This Internet-Draft will expire on April 17, 2006. Copyright Notice Copyright © The Internet Society (2005) Abstract Mobile IP is good at addressing IP session continuity (hide of the IP address change from transport layer perspective, as well as from the correspondent perspective) but certainly not optimal for mobility management as would perform 3GPP systems providers that want to extend their services to IP access systems. This document only njedjou Expires April 2006 [Page 1] Internet-Draft problem statement October 2005 describes the problem and is not meant to provide any solution nor any requirement thereof. Table of Contents 1. Introduction................................................2 2. Mobility Management basic principle for 3GPP access systems...................................................3 3. IP location update problem in Inter-System Mobility Management (3GPP to IP access systems.....................3 3.1. Redundancy of Mobile IP Location update procedures with inter-system mobility procedures..........................4 3.2. Mobile IP implementation by vendors.........................5 4. Security Considerations.....................................6 5. Conclusion..................................................6 6. References..................................................6 7. Acknowledgments.............................................6 8. Author's Addresses..........................................6 1.Introduction The basic principle of 3GPP mobility management systems for real time services is about the terminal reporting radio conditions to the network, that decides of the terminal handover need and target system and point of attachment based on the combination of these radio criteria to other parameters as operator policies or network profiles. This mobility management model with control facilities within the network has proved very successful for cellular operators radio resources usage. These operators may predominantly like to re- specify such well proven model for inter-system mobility management between UMTS, Evolved UMTS and IP access systems (802.11, 802.16...). When IP services are concerned (mostly the case when IP access systems and cellular PS systems are used), it becomes natural to think at Mobile IP to solve the session continuity problem. There comes the issue: for that session continuity function to be performed by Mobile IP, the terminal exchanges signaling with the network for route update of packets sent and received by the mobile terminal. Because inter-system mobility is required network controlled by 3GPP systems providers, the incumbent mobility management procedures have to be performed between the terminal and some control function in the network. Therefore the question of whether the signaling mechanism of Mobile IP is not redundant and concurrent to that of inter-system is legitimate. In radio environments, where capacity is limited, it is always a wish that the amount of signaling exchanged be reduced to a minimum. Njedjou Expires April 2005 [Page 2] Internet-Draft problem statement October 2005 2.Mobility Management basic principle for 3GPP access systems Basically, mobility management in 3GPP systems is made up of some major phases; . First, information is collected from terminal and radio access points to assess the need for a handover to take place (this information is exploited by handover algorithms based on operator policies) . Second, the handover target (with associated configuration parameters) is usually indicated to the station. . In a third phase, the handover procedure is executed (change of radio point of attachment) . In a last phase, if needed, the station location is updated in the 3GPP core network so that the terminal can be reached for further incoming calls. 3.IP location update problem in Inter-System Mobility Management (3GPP to IP access systems By IP Access Systems, we refer to radio access systems that are primarily designed for the transport of IP packets. These include IEEE standards 802.3, 802.11, 802.16… Cellular operators are complementing their coverage with IP access systems to be able to provide more real time and QoS demanding services. Because users require these services on the move, transition facilities to other systems are needed to ensure service continuity. Even if IP Access Systems come into play with alternative mobility management procedures (sometimes even poorly furnished), cellular operators would still like to perform inter-system mobility management as per the 3GPP scheme. When other systems are in play, the phases described earlier could be transformed as follows; . First, information is collected from terminals and radio access points(on the current system as well as on available access systems) to assess the need for a handover to take place (this information is exploited by handover algorithms based on operator policies) . Second, the handover target (with associated configuration parameters) is usually indicated to the station. Because this target can be of a different system and because of some requirements explicated earlier, the corresponding switch command might be indicated to the terminal over IP (see next paragraph for details). . In a third phase, the handover procedure is executed (change of link of attachment) Njedjou Expires April 2005 [Page 3] Internet-Draft problem statement October 2005 . In a last phase, the station location is updated in the network (change from a cellular location to an IP access location. This is not the IP location update procedure). Following such an update and provided that ther 3GPP interface remains on, the terminal actually has two locations, one on the 3GPP system and the other on the IP access system. Because of the economic constraint not to modify existing deployments (UMTS deployment nearly completed and Wifi -as per 1999 edition- deployment seriously advanced) and the need to provide seamless mobility services the sooner to customer, IP is a good candidate for the management of inter-system mobility between 3GPP and IP access systems. Effectively, a straightforward solution to manage inter- system mobility in a technology agnostic way is to use IP and above protocols to achieve that inter-system mobility because then control and management planes of either 3GPP or IP Access systems do not have to be changed. Also is this not easy to determine any will from 3GPP as an SDO to seriously change the design of UMTS control plane to accommodate inter-system. [ECCS] describes such scenarios where an IP transport is required for inter-system handover handling. This problem is however not within the scope of this document. In the reminder of this document, the four steps procedure described just below will be the one referred to. 3.1.Redundancy of Mobile IP Location update procedures with inter- system mobility procedures The IP location update of Mobile IP reports to the network information that the valid IP address of the terminal has changed to a new subnet. This information can actually theoretically be retrieved by alternative means that are less costly in signaling exchange over the air and certainly more optimal in terms of latency before exchanging again IP packets. Effectively, with the assumption that the 4 phases described earlier provide enough information to the network, The Mobile IP registration function become useless. The paragraph below provides an illustration. Let's consider a terminal undergoing a Voice over IP call on evolved 3G and for which an opportunity to handoff to an IP Access Systems has become available. The operator would basically want that handover to happen in order to release some capacity on the cellular network. In Phase 1 of the procedure described below, the network can already receive from the terminal or from any other network entity, information on this newly discovered IP access link (served QoS, radio quality, channel occupancy, IP connectivity information…). Whit these information, it such an entity will be able to decide whether the new link should be the target link of attachment. Njedjou Expires April 2005 [Page 4] Internet-Draft problem statement October 2005 Once such a handoff decision is taken, the network can send an order to request the terminal to configure IP connectivity on the new link and switch links, so that when the handover procedure (phase 3) is completed, the new IP location of the terminal is know of the network without performing the Mobile IP registration procedure. Indeed the new IP address to be used by the terminal would then be known of either parties. However when acknowledging the handover order received by the network, the terminal will still have to update the reverse tunneling to an anchor router in the operator network as well as that anchor router update the route for sending packets to the terminal. This paragraph give a way among many others possible to update the terminal newly active IP address without the need for the registration procedure of MIP. Before the solution space is reached though, the problem will have to be well understood. Therefore, IP location update procedures can be totally incorporated in the framework of an inter-system mobility management protocol that would serve a more general set of functionalities than session continuity of IP services. The gain would the reduction of signaling exchange needed for continuing an IP service between two systems as well as the latency. Effectively, a confirmation of the handover execution by the terminal could (end of phase 3) could also serve as indication to the network that IP packets can be forwarded to the new IP location, saving couple frequently sent bytes over the air interface. When using Mobile IP to indicate the change of IP location to the network, the procedure has to take place after the fourth phase presented earlier (for the network to have control on the IP address reselection) and is therefore not well timely operated. 3.2.Mobile IP implementation by vendors Cellular operators would basically like the Mobile IP registration (for updating location) to happen after the four phases procedure as described in the precedent paragraph has been executed. However, as the standard let it totally implementation dependant the set of events that trigger the registration procedure, it is practically impossible to find implementations of Mobile IP that have the same state machine for triggering the registration or re-registration procedure. Further, most of these implementations require on-demand heavy changes in order for the Mobile IP software to be modified in a way to perform the IP location procedure only after the mobility management phases have been performed. Therefore the fact that the IP location update function happens separately from the inter-system mobility mechanism is cumbersome for operators. Indeed operators that want to deploy seamless mobility for IP services have to make specific request to vendors to design Mobile IP implementations that fit their purpose. This burden becomes considerable when deployment is considered at a large scale. These would prefer to have an inter-system mobility management protocol Njedjou Expires April 2005 [Page 5] Internet-Draft problem statement October 2005 standardized, with intrinsically integrated IP location update functions. 4.Security Considerations The IP location update functions of Mobile IP incur many security problems that inter-system mobility procedures also will have to consider. Having that location update integrated in a general single framework would ease considerably the resolution of security issues that otherwise would have to be tackle twice. 5.Conclusion This document aims at explaining a potential gain in scalability and performance of inter-system mobility architectures in a wireless environment, if IP location update functions were performed as part of network controlled mobility management procedures and not as part of a different mechanism namely standalone Mobile IP. 6.References [MIPV4] "IP Mobility Support", C. Perkins (Editor), RFC 2002, October 1996. [MIPV6] "Mobility Support in IPv6", D. Johnson, C. Perkins, and Jari Arkko, draft-ietf-mobileip-ipv6-21.txt, work in progress, February 2003. 7.Acknowledgments The author would like to acknowledge reviewers of this document. 8.Author's Addresses Eric Njedjou France Telecom 4, rue du CLos Courtel 35512 Cesson Sévigné BP 91226 Phone: +33299124878 Email: eric.njedjou@france.telecom.com 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 Njedjou Expires April 2005 [Page 6] Internet-Draft problem statement October 2005 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. Njedjou Expires April 2005 [Page 7]