Internet DRAFT - draft-njedjou-mobopts-iplocup-netcomm-problem
draft-njedjou-mobopts-iplocup-netcomm-problem
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]
