IP Mobility Optimizations (Mob T. Melia
Opts) RG NEC
Internet-Draft J. Korhonen
Expires: April 20, 2006 TeliaSonera
R. Aguiar
IT
October 17, 2005
Network initiated handovers problem statement
draft-melia-mobopts-niho-ps-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
The document is a first study towards network support for decision
making and execution of handovers. Starting form existing
technologies and considering new mobile operators trends, we draw
novel potential deployment scenarios and derive a set of associated
functionalities. These functional components base on assumptions
Melia, et al. Expires April 20, 2006 [Page 1]
Internet-Draft Network Initiated Handovers October 2005
listed in the document. Application areas for network initiated
handovers are therefore illustrated specifying a set of goals and
non-goals.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview of the problem . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Scenarios and Requirements . . . . . . . . . . . . . . . . . . 8
3.1. Administrative domain wise considerations . . . . . . . . 8
3.2. Technology wise considerations . . . . . . . . . . . . . . 11
3.3. NIHO Application Areas . . . . . . . . . . . . . . . . . . 11
3.4. Network assistance with global mobility management . . . . 13
3.5. Network assistance with local mobility management . . . . 13
3.6. Inter-domain handovers . . . . . . . . . . . . . . . . . . 13
4. Framework and Functional Components . . . . . . . . . . . . . 14
5. Design considerations . . . . . . . . . . . . . . . . . . . . 14
5.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Non-goals . . . . . . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Melia, et al. Expires April 20, 2006 [Page 2]
Internet-Draft Network Initiated Handovers October 2005
1. Introduction
Standards based IP mobility enabling protocols such as Mobile IP
[RFC3344] [RFC3775], HIP [I-D.ietf-hip-arch], MOBIKE [I-D.ietf-
mobike-design] and SCTP with address management support [I-D.ietf-
tsvwg-addip-sctp] [mSCTP] are all mobile node centric. Most handover
related decision making is done in the mobile node only.
Public mobile network access is gaining increased offer diversity,
both in terms of the types of access technologies, in terms of the
diversity of the offer (with clear separation of roles between access
and service providers), and in terms of the size of that offer. This
diversity has been compounded by increasing number of multi-access
capable terminals equipped with IP technologies. Overall, this
creates a complex environment, where the mobile terminal might not
have enough information or even the possibility to make an
intelligent handover decision. In fact, handover decisions and
inherent target network selection is not necessarily anymore based on
access availability but further depends on policies and commercial
roaming arrangements on access network level, access provider level
and service provider level. Furthermore, the information required
for an intelligent target network selection might change periodically
in such a frequency that maintaining all knowledge (and intelligence)
in the mobile node might not be viable anymore. Only the network
will have some of this information. However, none of the mobility
protocols above referred have capabilities or procedures to
significantly involve the network side entities in intelligent
handover decision making.
A good example of the type of information only available to the
network is the situation with radio resource usage. It is expected
that radio resource usage optimization will be a task of major
relevance in future wireless network environments, with millions of
users roaming between access routers across multiple technologies
(i.e. 802.11, 802.16, e.g. [draft-cui-mobopts-hcf-wlan-00]). This
function can resort to mechanisms and algorithms able to gather
measurements and force terminal handovers between cells. The
handover can be issued according to predefined mobility patterns,
mechanisms for intelligent flow balancing, mechanisms for optimized
resource re-allocation, mechanisms for user-traffic performance
optimization, or mechanisms for user profiling (e.g. access rights) -
all of them ultimately leading to better service to be provided to
the users. For these expectations to be realized, network control
capabilities are required in order to provide this ability to force
specific terminals to perform handovers, either between access points
or between different technologies.
Going even further, handovers over administrative domains i.e. inter-
Melia, et al. Expires April 20, 2006 [Page 3]
Internet-Draft Network Initiated Handovers October 2005
domain handovers are not explicitly prohibited with the existing IP
mobility enabling protocols but at the same time these protocols are
not designed or optimized for such cases in any way. Also a general
network controlled triggering mechanism for a handover from an
administrative domain to another does not currently exists. An
emulated behavior could somehow be achieved through selective misuse
of AAA like it is done on cellular side voice oriented systems these
days.
This problem statement document describes various scenarios where
handovers could be network initiated, even over administrative
domains, presenting some ideas on architecture for this situation.
This, however, will further require a new handover triggering
mechanism that originates from entities located in the network side,
and is acted upon by entities on the mobile node. These network side
entities may also be located in other administrative domains that the
mobile node is currently visiting. This document also discusses and
lists a set of goals and non-goals for further work that aims at
enabling network initiated and assisted handovers even over
administrative domains.
1.1. Overview of the problem
Current standard mobility protocols provide Internet connectivity to
mobile nodes roaming from one access router to another. To reduce
handover latency extensions have been proposed and are currently in
the stage to be accepted as experimental RFC. In all these
approaches, handover is still initiated by the mobile terminal. In
this document we present a list of requirements according to which
this characteristic is not adequate, and the protocols need to be
extended with handover initiation by the network.
There has been consensus in the last months to split local mobility
from global mobility. Local mobility in the access network mainly
optimizes control signaling by reducing the need to update the home/
visited network about user mobility. Local mobility can be handled
independently of the global mobility. As an example, the netlmm
working group charter has the task to study and specify a protocol to
enable mobile devices to move across an access network by reducing to
the minimum the complexity in the terminal itself. Therefore the
network is requested to handle user mobility by means of appropriate
scheme.
In this proposal the trigger for host route update executed by the
network (which is actually an handover execution) is originating in
the terminal. By means of layer two mechanisms (e.g. link up or link
down in IEEE 802.11) or layer three mechanisms (e.g. Neighbor
discovery) the terminal is detected on the new link and the route to
Melia, et al. Expires April 20, 2006 [Page 4]
Internet-Draft Network Initiated Handovers October 2005
the host updated for packet delivery. Thus, the whole network
involvement is simply support of routing update. The real trigger/
decision comes, once again, from the terminal.
In [I-D.daniel-mip-link-characteristic] some specifications are
provided to enable Mobile IPv6 and Mobile IPv4 capable nodes to
exchange link information with the HA and any CN. However, to
generalize the approach, the link characteristics exchange should
happen during the handover process, since the Binding Update
handshake conclude the handover process, when (bicasted) packets are
already routed to the new Care-of Address (nCoA). For instance,
specialized traffic shapers could be installed in the ARs to adapt a
selected MT-CN flow to the specific underlying wireless/wire line
access technology.
As an example of the relevance of the proposed strategy, it is
expected that predictive or stochastic algorithms could be
implemented at the network side (leaving less complex logic for the
MN) to perform handover decision depending on the mobile user
environment. For that additional (to the link characteristics)
parameters such as bit rate, quality of service parameters (e.g. in
IEEE 802.11e) , radio frequency, MN's view of the access point signal
level, network view of the MN's sending power and roaming related
information may have to be evaluated prior to any handover decision.
This kind of approach has been described, for instance, in
[draft-cui-mobopts-hcf-wlan-00] where a WLAN scenario is presented
and extensions to Mobile IPv6 messages are introduced to support an
handover control function for handover decision.
The approaches described represent only a subset on the potential
scenarios for real deployment. For incorporating future technologies
seamlessly it is essential that specific solutions are framed under a
general solution.
By adding network control to such hierarchical deployment (local and
global mobility domains), mobile operators gain additional control on
user mobility whilst taking into account resource allocation to
guarantee reliable end to end services.
In this document we identify a problem statement highlighting future
network requirements, showing potential architectural ideas for
achieving these results.
1.2. Terminology
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. The key
Melia, et al. Expires April 20, 2006 [Page 5]
Internet-Draft Network Initiated Handovers October 2005
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in BCP 14 [1].
This document frequently uses the following terms:
ASP
Access Service provider. A network operator that provides direct
IP packet forwarding to and from the end host.
MRMH
Mobility and Roaming Manager, usually located at home network.
The Roaming Manager part is aware of administrative relationships
between the home network, various ISPs and possibly with various
NAPs as well.
MRMV
Mobility and Roaming Manager located at visited network. MRMV is
generally delegated representative of MRMH in the visited network.
MSP
Mobility Service provider. A service provider that provides IP
mobility services. In order to obtain such service, the mobile
node must be authenticated and prove authorization to obtain the
service.
NIHO
Network initiated and assisted handover.
AN
Access Network composed of several access routers. Identified as
well as local mobility domain.
2. Assumptions
This document has some few fundamental assumptions concerning the
general networking environment and network initiated handovers. The
rest of the document makes use of the following assumptions:
Melia, et al. Expires April 20, 2006 [Page 6]
Internet-Draft Network Initiated Handovers October 2005
o Reusing existing security mechanisms -- The mobile node does not
need to create a new security mechanism in order to enable network
initiated and assisted handover triggering. The mobile node
should reuse the existing security associations it created while
establishing the initial access to the network and its mobility
service provider (MSP).
o All mobile nodes within the scope of this document are expected to
support at least one (potentially modified) existing or future IP
mobility enabling protocol.
o All mobile nodes, correspondent nodes and mobility management
nodes are not expected to understand or support network initiated
and assisted handovers. When either peer lacks support for
network initiated and assisted handover triggering and signaling
the peer supporting these features must fall back to the base IP
mobility protocol mechanisms.
o The network initiated handover concept relies on the presence of a
centralized functional entity. This entity controls the network
side and implement the intelligence to select nodes and targets
access routers. It is not in the scope of this document to
specify the policies that will be implemented here.
o To provide adequate scalable support, distributed functions are
required to support the above functional entity. This gives more
flexibility to the overall architecture and protocol operation.
o It is envisioned the presence of multi wireless access, such as
802.11, 802.16, UMTS, forming an heterogeneous composition of
macro and micro cells. The network support SHOULD leverage user
mobility focusing on vertical handovers. Hence, the terminal does
not need to apply filtering criteria to select a target network.
(which could be an expensive operation in heterogeneous
environments)
o Performing network initiated handover has the main implication
that the network has first to assess the terminal view of the
network. Signal level evaluation is a important matter when
coming down to user mobility. This is typically very well handled
with terminal initiated handovers and automatic evaluation of
signal level. Different methods apply to different technologies.
o Neighborhood discovery relates to the above assumption when
neighborhood scanning is requested from the network. It is
expected these functions to be available on the terminal side.
Melia, et al. Expires April 20, 2006 [Page 7]
Internet-Draft Network Initiated Handovers October 2005
3. Scenarios and Requirements
This section describes few usage scenarios where the network
initiated and assisted handover could be justified and deployed.
Also we list here initial requirements for the general network
initiated and assisted handover functionality.
3.1. Administrative domain wise considerations
Figure 1 and Figure 2 introduce two different possible scenarios. In
the first case one single administrative scenario is described. The
Mobile Operator (MO) owns both the ISPs and the NAPs. It provides as
well mobility services. This is the simplest case where security
restrictions are less relevant. The MO has therefore full control.
Figure 2 illustrates another example architecture, where the
signaling and triggering relationship between home network domain,
ISP domain, NAP domain and the mobile node domain are shown. Each of
previously mentioned technical domains may belong to a different
administrative domain.
Melia, et al. Expires April 20, 2006 [Page 8]
Internet-Draft Network Initiated Handovers October 2005
.--. <-++
Mobile Operator _( `. |S
Home Network ( MRMH ) |i
( ` . ) ) |n
`--(___.-' |g
^ |l
NIHO / triggers signaling |e
/ |
.--. V |a
_( `. |d
( ISP ) |m
( ` . ) ) |i
`--(___.-' |n
^ ^ |i
/ NIHO \ triggers signaling |s
/ \ |t
V V |r
.--. .--. |a
_( `. _( `. |t
( NAP ) ( NAP ) |i
( ` . ) ) ( ` . ) ) |v
`--(___.-' `--(___.-' |e
| |
| ) |d
V ) ) NIHO trigger & signaling |o
____ ) ) ) |m
|____|_Y |a
/_____/ |i
|n
<--+
Figure 1: An overall architecture for network initiated and assisted
handover. Single Administrative domain
Melia, et al. Expires April 20, 2006 [Page 9]
Internet-Draft Network Initiated Handovers October 2005
.--. <-+
_( `. |
Home Network ( MRMH ) |
( ` . ) ) |
`--(___.-' | D
^ ^ | o
NIHO / triggers \ signaling | m
/ \ | a
.--. V V .--. | i
_( `. NIHO triggers _( `. | n
<--- ( ISP A ) <---------------> ( ISP B ) ---> |
( ` . ) ) signaling ( ` . ) ) |
`--(___.-' `--(___.-' | 1
^ ^ ^ ^ ^ |
/ NIHO \ \ triggers / \ signaling |
/ \ \ / \ <-+
V V \ V V | D
.--. .--. \ .--. .--. | o
_( `. _( `. V _( `. _( `. | m
( NAP A ) ( NAP A ) ( NAP B ) ( NAP C ) | a
( ` . ) ) ( ` . ) ) ( ` . ) ) ( ` . ) ) | i
`--(___.-' `--(___.-' `--(___.-' `--(___.-' | n
| 2
| ) <-+
V ) ) NIHO trigger & signaling | D
____ ) ) ) | o
|____|_Y | m
/_____/ | 3
<-+
Figure 2: An overall architecture for network initiated and assisted
handovers over multiple administrative domains
The architecture in Figure 2 has been divided into three different
domains. Domain 1 represents the home network or the services
provider that owns and manages user's subscription. It eventually
contains Internet Service Providers (ISPs) as well.
Domain 2 contains Network Access Providers (NAPs). A NAP provides
access services for one or more Home Networks.
Domain 3 is the mobile node and may also represent the end user. The
end user does not need to have any relationship with NAPs or ISPs in
order the gain access to the services accessible through the home
network.
Melia, et al. Expires April 20, 2006 [Page 10]
Internet-Draft Network Initiated Handovers October 2005
3.2. Technology wise considerations
In the previous section we provided an high level view of network
relationships between the different entities involved. Figure 1 and
Figure 2 describes a general network view without describing which
technologies are supported and where optimizations take place. It is
clear MO will have different environment deployments. In the
following we give some examples on how technologies can be mapped to
NAP implementing several Access Networks and creating complex
overlapping of macro and micro cells scenarios.
+=====================================+
= UMTS MACROCELL =
= =
= =
= +--------------------------+ =
= | 802.16 CELL | =
= | | =
= | 802.11 | =
= | oo xx @@ | =
= | o o x x @ @ | =
= | o ox x@ @ | =
= | o xo @x @ | =
= | o ox x@ @ | =
= | o o x x @ @ | =
= | oo xx @@ | =
= +--------------------------+ =
= =
+=====================================+
Figure 3: Micro and Micro cells overlapping scenario
These cells can be actually owned by the same or by different NAPs.
In any case, the MRMH will collect information about all these cells
(as visible from the terminal) across the different domains.
3.3. NIHO Application Areas
At this point in time we foresee three possible application areas
that are listed and briefly described in the following section. Each
application area uses the NIHO triggering and signaling as part of
their tasks.
Melia, et al. Expires April 20, 2006 [Page 11]
Internet-Draft Network Initiated Handovers October 2005
o Application for Mobility Reasons
The general idea is to handle user mobility from the network side.
This particular application requires network capabilities to
request measurements and evaluate technologies specific link
conditions. The approach can be considered similar to what
current mobile networks do.
As an example, if we consider WLAN environments, the network could
gather (both proactive or reactive approaches apply) terminal
related information and select target access points/access
routers. Previous experiences [Measurement Module for mobility
management in WLAN networks] already demonstrated the feasibility
of the approach. The key idea is to deploy networks able to see
terminal positions upon request of measurements performed either
at the edge of the network or at the terminal. Scalability
considerations have to be done with respect to the overhead
introduced in terms of protocol operations and traffic load in the
network.
o Application for Resource Optimization Reasons
As mentioned before, network optimization is a delicate issue when
resources are scarce, especially in the access network. Although
standards able to support natively quality of services
capabilities are becoming mature to be sold on the market
(802.11e), networks are not yet ready to support these new
technologies. A cross layer design is therefore required to
convey link layer specific information to decision points located
in the access network.
These decision points will then execute resource optimization
algorithms given the existing traffic requirements and the
existing network capabilities.
o Application for inter-domain handover
Handovers that cause the mobile to cross administrative domain
borders involve inter-domain signaling. One example of this kind
of scenario is when the mobile node moves between different NAPs
under the same ISP or when even the ISP changes as a result of the
movement. In both of these scenarios the NIHO signaling could be
used to prepare the new target domain (either ISP and/or NAP) for
the arriving mobile node. Especially if the handover was
initiated from the network side, the handover initiating network
could help distributing all security, policies, billing and
service related material cross administrative domains before the
mobile node arrives.
Melia, et al. Expires April 20, 2006 [Page 12]
Internet-Draft Network Initiated Handovers October 2005
3.4. Network assistance with global mobility management
This aspect is particularly important for inter-domain handovers.
The network will provide information required for speeding the
handover. This information is related with two types of data: i)
operator related data, such as billing information, policies, etc..;
ii) terminal related data, such as security associations.
3.5. Network assistance with local mobility management
This aspect is particularly important for resource optimization and
intra-domain handovers. The network will provide information to lead
(or impose) the mobile terminal to associate to specific access
points.
3.6. Inter-domain handovers
Inter-domain handovers and inter-domain handover preparations require
entities involved in the triggering and signaling to have security
relationships in place between them. For example the MRMH located at
the home network (service provider) must have a security relationship
between all ISPs the end user can use for accessing services. Also
ISPs must have security relationship between all NAPs the end user
can use for accessing services. However, NAPs do no necessarily need
to have any relationship with the actual service provider. And going
even further the end user does not need to have any relationship
between NAPs and ISPs, only with the service provider. It is service
provider's duty to grant access to services via any NAP and ISP the
service provider has a direct or indirect pre-setup relationship.
In addition to obvious security and AAA related challenges between
the service operator, ISPs and NAPs, the general when and why to
trigger a handover towards the mobile node is not a trivial task.
The service provider's home network needs to have rather exact and up
to date knowledge of the mobile node's current topological location
and surrounding network conditions before it should trigger a
handover on the mobile node due same policy decision at the home
network. Example of such policy decisions is when a mobile node
roams (after a handover) to a target network the home network does
not want the end user to use for the active service set the end user
has requested. As a consequence the home network MRMH triggers a new
handover suggestion towards the mobile node indicating a more
feasible target network (based on the information the mobile node has
previously signaled to the home network MRMH). Another home network
policy decision could be distributing roaming end users in visited
networks based on some distribution criteria. Such criteria could,
for example, be directing voice users to ISP A network, where as data
service users to ISP B network. A simpler rationale can be simply
Melia, et al. Expires April 20, 2006 [Page 13]
Internet-Draft Network Initiated Handovers October 2005
redirecting the user to the mobile network whose charges are lower at
that time.
The whole policy mechanism in the home network MRMH is a complex
issue and out of scope of this document. However, the home network
MRMH needs information of its end users from dedicated NAP and ISP
entities. These information aggregating entities are discussed in
more detail in Section 4.
4. Framework and Functional Components
We can draw on the previous considerations to derive a framework
view.
We need the following basic components:
o Policy Decision Point
This could be on the MRMH or MRML depending on the case.
o Policy Enforcement Point
Namely the access routers
o Measurements Functions
Collectively distributed between the access routers and the mobile
terminals.
o Aggregators Components
The functionalities can be located at different points in the
network.
Overall, the PDP will retrieve data from the Measurement blocks both
in the network, and from the mobile terminal. The PDP will issue
policies to the PEPs, that will impose the policies.
5. Design considerations
5.1. Goals
This section lists the general goals for the network initiated and
assisted handovers framework design. The network initiated and
assisted handover framework solution MUST fulfil all the goals listed
below:
Melia, et al. Expires April 20, 2006 [Page 14]
Internet-Draft Network Initiated Handovers October 2005
G1 Independent of the IP mobility management mechanism -- The network
initiated and assisted handover triggering mechanism must be
independent of any particular IP mobility management protocol.
However, there might be mappings/implementations of the triggering
mechanism to a specific IP mobility protocol such as Mobile IP.
G2 Work over administrative domains e.g. in inter-domain handover
cases or when a multi-homed host is attached to multiple ISPs.
G3 Provide similar degree of security as existing with the current
security protocols.
5.2. Non-goals
This section lists issues that are considered as strictly out of
scope of this problem statement and requirements document.
o Designing a new security framework in order to enable network
initiated and assisted handover triggering.
o Initial bootstrapping problem -- The mechanism to gain the initial
access to some network is out of scope of.
6. IANA Considerations
This document does not define any new name spaces to be managed by
IANA. This document does not either reserve any new numbers or names
under any existing name space managed by IANA.
7. Security Considerations
At the time of writing this document, the threats to network
initiated and assisted IP handovers in general, and signaling and
triggering between the mobile node and corresponding network entities
are not widely understood, particularly in the inter-domain handover
case when the signaling and triggering takes place across
administrative domains. Part of the experimental task in preparing
network initiated and assisted handovers (even across administrative
domains) for eventual standards track will be to better characterize
threats to network initiated and assisted handovers, inter-domain
triggering and signaling, and design specific mechanisms to counter
them.
8. Acknowledgments
Melia, et al. Expires April 20, 2006 [Page 15]
Internet-Draft Network Initiated Handovers October 2005
The authors would like to thank Rajeev Koodli for his valuable
comments and suggestions.
9. References
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[I-D.daniel-mip-link-characteristic]
Park, S., "Link Characteristics Information for Mobile
IP", draft-daniel-mip-link-characteristic-02 (work in
progress), June 2005.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[I-D.ietf-hip-arch]
Moskowitz, R. and P. Nikander, "Host Identity Protocol
Architecture", draft-ietf-hip-arch-03 (work in progress),
August 2005.
[I-D.ietf-mobike-design]
Kivinen, T. and H. Tschofenig, "Design of the MOBIKE
Protocol", draft-ietf-mobike-design-03 (work in progress),
July 2005.
[I-D.ietf-tsvwg-addip-sctp]
Stewart, R., "Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration",
draft-ietf-tsvwg-addip-sctp-12 (work in progress),
June 2005.
[mSCTP] Xing, W., Karl, H., and A. Wolisz, "M-SCTP: Design and
prototypical implementation of an end-to-end mobility
concept", October 2002.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[draft-cui-mobopts-hcf-wlan-00]
Cui, Y., "Handover Control Function Based Handover for
Mobile IPv6", draft-cui-mobopts-hcf-wlan-00 (work in
progress), July 2005.
Melia, et al. Expires April 20, 2006 [Page 16]
Internet-Draft Network Initiated Handovers October 2005
[draft-daniel-mip-link-characteristic-02]
Park, S., "Link Characteristics Information for Mobile
IP", draft-daniel-mip-link-characteristic-02 (work in
progress), June 2005.
[Measurement Module for mobility management in WLAN networks]
Danda, J., Pacyna, P., Sikora, M., Loziak, K., Natkaniec,
M., and A. Glowacz, "Measurement Module for mobility
management in WLAN networks", Second International
Workshop on Multimedia Interactive Protocols and Systems,
November 2004.
Melia, et al. Expires April 20, 2006 [Page 17]
Internet-Draft Network Initiated Handovers October 2005
Authors' Addresses
Telemaco Melia
NEC Europe Network Laboratories
Kufuerstenanlage 36
Heidelberg 69115
Germany
Phone: +49 6221 90511 42
Email: telemaco.melia@netlab.nec.de
Jouni Korhonen
TeliaSonera Corporation.
P.O.Box 970
FIN-00051 Sonera
FINLAND
Phone: +358 40 534 4455
Email: jouni.korhonen@teliasonera.com
Rui L.A. Aguiar
Instituto de Telecomunicacoes Universidade de Aveiro
Aveiro 3810
Portugal
Phone: +351 234 377900
Email: ruilaa@det.ua.pt
Melia, et al. Expires April 20, 2006 [Page 18]
Internet-Draft Network Initiated Handovers 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.
Melia, et al. Expires April 20, 2006 [Page 19]