Internet DRAFT - draft-melia-mipshop-niho-ps
draft-melia-mipshop-niho-ps
MIPSHOP Working Group T. Melia
Internet-Draft NEC
Expires: December 20, 2006 J. Korhonen
TeliaSonera
R. Aguiar
IT
S. Sreemanthula
Nokia
V. Gupta
Intel
June 18, 2006
Network initiated handovers problem statement
draft-melia-mipshop-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 December 20, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This is a first document describing the rational about network
Melia, et al. Expires December 20, 2006 [Page 1]
Internet-Draft Network Initiated Handovers June 2006
support for decision making and execution of handovers. Starting
from existing technologies and considering new trends from mobile
operators, we draw potential deployment scenarios and derive a set of
associated functionalities. These functionalities and associated
assumptions are listed in the document. Application areas for
network initiated handovers are then illustrated specifying a set of
goals and non-goals to be addressed in a future version.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview of the problem . . . . . . . . . . . . . . . . . 4
1.2. Definition of Network Initiated Handover . . . . . . . . . 6
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Administrative domain wise considerations . . . . . . . . 10
3.2. Technology wise considerations . . . . . . . . . . . . . . 13
3.3. NIHO Application Areas . . . . . . . . . . . . . . . . . . 13
4. General Requirements . . . . . . . . . . . . . . . . . . . . . 14
4.1. Network assistance with global mobility management . . . . 14
4.2. Network assistance with local mobility management . . . . 15
4.3. Inter-domain handovers . . . . . . . . . . . . . . . . . . 15
5. Framework and Functional Components . . . . . . . . . . . . . 16
6. NIHO with IEEE 802.21 . . . . . . . . . . . . . . . . . . . . 17
6.1. Network Selection . . . . . . . . . . . . . . . . . . . . 18
6.2. Handover Control . . . . . . . . . . . . . . . . . . . . . 20
7. Design considerations . . . . . . . . . . . . . . . . . . . . 22
7.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.2. Non-goals . . . . . . . . . . . . . . . . . . . . . . . . 23
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 28
Melia, et al. Expires December 20, 2006 [Page 2]
Internet-Draft Network Initiated Handovers June 2006
1. Introduction
Standards based IP mobility enabling protocols such as Mobile IP
[RFC3344] [RFC3775], HIP [RFC4423], MOBIKE [RFC4555] and SCTP with
address management support [I-D.ietf-tsvwg-addip-sctp] [mSCTP] are
all mobile node centric: the handover related decision making is
mostly done in the mobile node only.
Public mobile network access is gaining increased 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, and of operator-
provided multi-technology mobile connection software. 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 (as is often the case of operator-
provided software). 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 with
such a frequency that maintaining all knowledge (and intelligence) in
the mobile node might not be viable anymore. Some of this
information is only available for network elements. However, none of
the mobility protocols above referred have capabilities or procedures
to significantly involve network side entities in intelligent
handover decision making.
A good example of the type of information only available at network
entities is 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 task 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, with
additional increased resource usage for the network operator. For
these expectations to be realized, network control capabilities are
required to instruct specific terminals to perform handovers, either
between access points or between different technologies.
Melia, et al. Expires December 20, 2006 [Page 3]
Internet-Draft Network Initiated Handovers June 2006
Going even further, handovers over administrative domains i.e. inter-
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. Some
initial work in this direction is introduced in [I-D.nakhjiri-aaa-
hokey-ps]. The document describes how EAP keying material combined
with hierarchical schemes could enhance roaming scenarios.
This problem statement document describes various scenarios where
handovers could be network initiated, even over administrative
domains, presenting some ideas on functional components and protocol
operations required to fulfill the above requirements. 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 than the
one the mobile node is currently visiting. In Section 6 an example
is provided on how IEEE 802.21 can implement the required signalling.
Finally, 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 to mobility protocols are available
(e.g. [RFC4068], [RFC4140]). Although some of the approaches
support network initiation of the handover procedure, none of them
takes into consideration the existence of a backend combining
mobility, resource management and roaming scenarios. 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.
In [I-D.mohan-nflm-proto] a network based fast handoff based
mechanism is proposed. The scenario considers a mobility anchor
point controlling several access routers. On behalf of the mobile
node the serving access routers updates routes and binding caches
allowing the traffic to be routed to the new location. The trigger
comes from the mobile node.
There has been work started 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
Melia, et al. Expires December 20, 2006 [Page 4]
Internet-Draft Network Initiated Handovers June 2006
handled independently of the global mobility. As an example, in
[I-D.ietf-netlmm-nohost-ps] a list of requirements is given in order
to identify desired functionalities. In the proposed document mobile
devices are able 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 schemes.
In this last 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
the host updated for packet delivery. Thus, the whole network
intervention is simply the support of route update. The real
trigger/decision comes, once again, from the terminal.
Following the split between global mobility domain and local mobility
domain, [3GPP.23.882] provides additional scenarios where the network
controlled and initiated handovers are also considered. The key
point is that is the initiator of the handover procedure is mainly
the serving radio access network, in contrast to the above explained
methods.
More short term deployable solutions have also been proposed. In
[draft-cui-mobopts-hcf-wlan-00] a WLAN scenario is presented and
extensions to Mobile IPv6 messages are introduced to support an
handover control function for handover decision. [I-D.melia-mobopts-
niho-fmip] proposes a fast mobile IP based approach where both mobile
terminal and network initiated handovers are possible. Network
initiated handovers are combined with advanced admission control
mechanisms and potential race conditions are solved by appropriate
protocol operations.
Additional ways of providing information to the network enabling
handover decisions are presented in [I-D.korhonen-mobopts-link-
characteristics-ps]. Methods 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. Or (re)INVITE messages could
be issued, in 3GPP multimedia communications.
In the above mentioned examples we note an increasing involvement of
the network in the mobility management problem. The aim of this
Melia, et al. Expires December 20, 2006 [Page 5]
Internet-Draft Network Initiated Handovers June 2006
document is to identify common lines to existing solutions and to
derive the set of functionalities required to perform this kind of
handovers.
1.2. Definition of Network Initiated Handover
As mentioned above, available solutions rely on the existence of
triggers generated in the mobile terminal and conveyed to respective
network components which then will take adequate actions. However,
recently we have been assisting to new different trends [3GPP.23.882]
where the serving radio access network issue handover preparation/
execution by means of different events gathered at different levels
(e.g. radio conditions, QoS requirements). We therefore are required
to define use cases in which the network takes active decisions
without requiring the terminal to perform expensive operations.
In this document by network initiated handover we identify the action
taken in the network to initiate the handover based on:
o Link events originated in the mobile node. In this case the
terminal sends link events to the network. The event might be
generated because of radio variations, powering on of new network
devices or new service requirements. In all cases the measurement
action is required to be performed also in critical conditions.
For instance speed dynamic effects on terminal mobility have to be
taken into account as well as variable round trip time.
Positioning of the decision function is a critical issue.
o Events generated in the network for e.g. resource management
reasons. It should be noted that the Mobile Operator can initiate
an handover procedure also based on location and current services.
Multihoming scenarios can also be considered as part of the
overall optimization problem.
The action described is similar to exiting behavior of current GSM/3G
systems. Measurements are requested by the network and performed by
the mobile terminal. The results of these measurements, combined
with current QoS conditions and other user profile requirements,
could result in the execution of an handover. Measurements are a key
issue, for instance, in indoor wireless LANs environments, affected
also by different user mobility patterns.
1.3. Terminology
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Melia, et al. Expires December 20, 2006 [Page 6]
Internet-Draft Network Initiated Handovers June 2006
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
This document frequently uses the following terms:
NAP
Network Access 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 a local 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.
IS
Information services provide an information query mechanism for
mobile or network nodes to obtain information about specific
networks and their capabilities, as explained in IEEE 802.21. The
information service plays a critical role in the network selection
at the mobile node or in the network.
Melia, et al. Expires December 20, 2006 [Page 7]
Internet-Draft Network Initiated Handovers June 2006
ES
Event service is a protocol exchange mechanism between network
nodes to inform of recently happened or impending change in link
or network status information, as explained in IEEE 802.21. The
event notification can originate either from a mobile node or a
node in the network. Receipt and processing of an event belonging
to the ES may generate a reaction in the receiving node (e.g.
trigger IP layer mobility).
CS
Command service is a protocol exchange mechanism between network
nodes to instruct the recipient network nodes to execute a
specific function, as explained in IEEE 802.21. Execution of a
command service at the mobile node or a node in the network may
result in loss of current link connectivity and/or change in the
network point of attachment. Receipt and processing of a command
belonging to the CS generates an expected response in the
receiving node (e.g. create a new link layer connection,
disconnect a link layer connection, etc).
MIHF
Media independent handover function (MIHF)is a shim layer in the
mobility management protocol stack of the mobile nodes or network
element that provide media independent or inter-technology
mobility, specifically handovers (e.g. as defined in IEEE 802.21).
MIHF can implement one or more of IS, ES and CS.
MM
A mobility management entity (MM) implements network selection and
handover decision algorithms and utilizes mobility signaling
protocols and other protocols that aid in mobility functions. MM
functionality should utilize MIHF.
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 December 20, 2006 [Page 8]
Internet-Draft Network Initiated Handovers June 2006
o Reusing existing security mechanisms -- 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). Applicable scenarios are identified in
[I-D.nakhjiri-aaa-hokey-ps].
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. However, if a MN does not support
network initiated handover functionality, the network might refuse
to give service to that MN.
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.
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). Solutions similar to the 3GPP interface between
the Home Subscriber Server (HSS) and any application server, for
downloading of filtering criteria at registration time, could be
applied here - being the HSS a AAA backend, and the application
server the MRMV/MRMH.
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
considering user mobility. This is typically very well handled
with terminal initiated handovers and automatic evaluation of
signal level. Different methods apply to different technologies.
Melia, et al. Expires December 20, 2006 [Page 9]
Internet-Draft Network Initiated Handovers June 2006
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.
3. Scenarios
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 December 20, 2006 [Page 10]
Internet-Draft Network Initiated Handovers June 2006
.--. <-++
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 December 20, 2006 [Page 11]
Internet-Draft Network Initiated Handovers June 2006
.--. <-+
_( `. |
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.
Along these lines [I-D.nakhjiri-aaa-hokey-ps] proposes a distributed
Melia, et al. Expires December 20, 2006 [Page 12]
Internet-Draft Network Initiated Handovers June 2006
system interacting with a AAA backend. The introduced key Holder
element acting as a AAA client for the AAA server COULD -- in this
scenario -- be implemented at the boundaries of each single cloud,
belonging either to a NAP or to an ISP. SAs presented in the
document can be mapped to the mechanisms depicted in Figure 2.
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 potentially
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: An example of overlapping Micro and Micro cells
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
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 December 20, 2006 [Page 13]
Internet-Draft Network Initiated Handovers June 2006
o Application for Mobility Reasons
In this context user mobility is handled from the network side
assisted by the mobile terminal. 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. The most
challenging aspect is the freshness of the reported information.
Particular scenarios, such as WLAN, could impose stringent
requirements.
o Application for Resource Optimization Reasons
As mentioned before, network optimization is a delicate issue when
resources are scarce, especially in the wireless access network.
Standards that able to support natively quality of services
capabilities are becoming mature to be sold on the market
(802.11e). A cross layer design is therefore required to convey
link layer specific information to decision points located in the
access network.
These decision points can combine standard admission control
mechanisms with advanced NIHO functionalities, resulting in a new
dimension of mobility management (i.e. more terminals can be
granted with network access).
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.
4. General Requirements
4.1. 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)
Melia, et al. Expires December 20, 2006 [Page 14]
Internet-Draft Network Initiated Handovers June 2006
operator related data, such as billing information, policies, etc..;
ii) terminal related data, such as security associations.
4.2. 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.
4.3. 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
redirecting the user to the mobile network whose charges are lower at
that time. The IEEE 802.21 Information service, for instance, could
help in this process.
The whole policy mechanism in the home network MRMH is a complex
Melia, et al. Expires December 20, 2006 [Page 15]
Internet-Draft Network Initiated Handovers June 2006
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 5.
5. Framework and Functional Components
In the previous sections the need to implement decision points in the
network as well as measurements and aggregation functions has been
justified. We can draw on the previous considerations to derive a
framework view.
o Policy Decision Point
This could be on the MRMH or MRML depending on the case. In the
IEEE 802.21 draft event and command services for network initiated
handovers are associated with the Point of Services (PoS). In
[3GPP.23.882]the access nnetwork takes decision about initiating
the handover. Generalizing the approach we call this functional
entity Policy Decision Point. It is envisioned to place the PDP
at the edge of a localized mobility domain or in the home network.
In case of a ISP or NAP the PDP needs to have in place a SA with
the home domain of the mobile user as specified in [I-D.nakhjiri-
aaa-hokey-ps].
The PDP can trigger/enforce a horizontal or vertical handover,
depending on the user device. It is also envisioned the
possibility to detect multihomed devices as part of the resource
management process.
o Policy Enforcement Point
Enforcement points participating to the signalling, and
contributing to the scalable approach, are necessary. PEP are
mainly access routers terminating different kind of transport
protocols (e.g. ICMPv6 over the last hop and SCTP between network
components).
o Measurements Functions
Measurements functions are critical components considering the
overall procedure, being collectively distributed between the
access routers and the mobile terminals. As mentioned before, the
network, prior to any action, needs to assess the terminal view
(i.e. link signal quality) of the access network. Currently none
of the available protocols can support such feature. Options
could be specified, though scalability and security have to be
Melia, et al. Expires December 20, 2006 [Page 16]
Internet-Draft Network Initiated Handovers June 2006
deeply studied. It is well understood measurements are requested
from the network to the mobile terminal.
o Aggregators Components
To increase the overall scalability of the procedure aggregation
points could be installed in different places in the access
networks. Aggregated reports to PDP about QoS conditions, service
availability, network load help in the decision process
contributing to build an overall picture of the access network
conditions. reports could be periodic or event based. In either
cases information of several hundreds of mobile terminals could be
carried.
Generally, the PDP acts upon events and combines required actions
with user profiles. Depending on billing rates, user preferences
action A instead of action B can be issued. The transfer and
definition of such profiles is not in scope of this document.
6. NIHO with IEEE 802.21
IS, ES and CS as defined in IEEE 802.21 WG can be used as enablers
for network initiated and assisted handover scenarios between
different access technologies. The discussion of such scenarios in
IP networks can easily raise a long list of questions regarding the
feasibility of e.g. sending information in real-time between the
mobile node and the MM, and of sending commands between the MM and
the mobile node. The issue considered in these cases is typically
the delay that can be introduced by the transport and that may make
the overall handover delay quite considerable. This document does
not discuss these specific issues, and does not argue in favor or
against such issues. However, in order to identify some of the
scenarios of applicability for IS, ES and CS for network-controlled
handover, we need to consider the following classification of
handovers. There are two main reasons to perform a handover:
1. degradation of current link/connection quality: the quality of
the link is degrading and it is necessary to perform a handover
to avoid losing the current connection;
2. "opportunistic" handover: due to a set of events and based on
specific policies, it is preferable to move the communication to
another link.
In order to support inter-technology network-controlled handovers the
first case, the delay between the moment the handover decision is
made and the moment the command to perform the handover is received
Melia, et al. Expires December 20, 2006 [Page 17]
Internet-Draft Network Initiated Handovers June 2006
by the mobile node needs to be considered carefully. However, for
"opportunistic" handover the impact of such delay is less
significant, since the mobile node is not having any degradation over
the current link, and the handover will be performed because the
network has policies indicating that it is preferable to move to the
new link.
One motivation for performing opportunistic network-controlled
handover is load sharing, in scenarios where a network exercises
tight control of various wireless link technologies to distribute the
load of communications according to network policies.
The network may perform a network-controlled handover decision in at
least two steps.
1. Network selection, and
2. Handover control.
The two steps are described in the following sections
6.1. Network Selection
Network selection is a process of selecting a favorable network for a
mobile node to transfer or handover the ongoing services to the
selected network. The selected network may be a different link
technology from the previous one. It may also be possible that the
mobile node, after handover, may not experience exactly the same
level of QoS as the current link due to this network selection. But,
in general, it may result in some user benefit in one way or another
e.g. cost savings, higher bandwidth etc. MM in the network may have
access to subscriber profile, contracts, and device capabilities to
make use of the network selection algorithms for a certain subscriber
or mobile node.
Figure 4 shows a simple network selection procedure with the help of
the mobile node. This example call flow diagram employs remote event
services and information services. Remote command services are not
used in this particular example, however, they can also be useful in
the network selection mechanisms under certain scenarios. E.g.
depending on user geographical location, the network may command the
mobile node to perform a scan for a specific 802.11 network and
report the results that can be used in the network selection process.
In the scenario shown, the mobile node initially performs a
registration or attachment to the network on any link, e.g. 3GPP
network. The MM and the mobile node are able to discover each other
in the same or following step. MM may then register for specific
Melia, et al. Expires December 20, 2006 [Page 18]
Internet-Draft Network Initiated Handovers June 2006
remote event services, e.g. ES-link-detect by sending a registration
request and filter information for both 802.16 and 802.11 networks.
The mobile node accepts the request with a positive reply. From time
to time, the mobile node may receive broadcast information from
802.11 and 802.16 networks. In this scenario, the 802.16 broadcast
is received and a link-detect is sent by the 802.16 MAC layer to the
MIHF. The MIHF translates this to an ES-link-detect message to the
MIHF implementing ES in the network (collocated in the MM) with the
basic network information received in the broadcast.
The MM requests for more information about the network via the IS
query to another MIHF implementing IS to check the suitability of the
detected network due to roaming agreements. The MM decides that this
particular 802.16 network is not a favorable network and takes no
action. The mobile node also takes no action and does not report the
detection of same network more than once. At a later time, the
mobile node may receive beacon information from 802.11 AP and the MAC
layer in the mobile node reports the to the MIHF along with the SSID
information. The MIHF provides this information to the MM in the
network. The MM may perform an IS query based on the SSID
information and determines that this SSID belongs to a favorable
network. The network selection process, thereby, is completed.
Melia, et al. Expires December 20, 2006 [Page 19]
Internet-Draft Network Initiated Handovers June 2006
Mobile Node
|----------------------|
+--------+ +-------+ +-------+ +------+ +------+ +------+
|MIHF(ES)| | Link | | MM | | IS | |802.16| |802.11|
| | | Layers| | | | | | | | |
+--------+ +-------+ +-------+ +------+ +------+ +------+
| | | | | |
+------------------------------+ | | |
| Discovery & Registration| | | |
+------------------------------+ | | |
| 1.ES-reg-req | | | |
|<========================| | | |
| 2.ES-reg-resp | | | |
|========================>| | | |
~ ~ ~ ~ ~
| |3.DL-burst| | | |
| 4.link-detect|<--------------------------------| |
|<-------------| | | | |
| 5.ES-link-detect | | | |
|========================>|6.IS-query| | |
| | |--------->| | |
| | +-------------+ | | |
| | |not favorable| | | |
| | +-------------+ | | |
~ ~ ~ ~ ~ ~
| |7.Beacon | | | |
|8.link-detect |<-------------------------------------------|
|<-------------| | | | |
| 9.ES-link-detect | | | |
|========================>|10.IS-query | |
| | |--------->| | |
| | +-----------+ | | |
| | | favorable | | | |
| | +-----------+ | | |
| | | | | |
+--------+ +-------+ +-------+ +------+ +------+ +------+
|----------------------|
Legend: ===== ES over current link
Figure 4: Network Selection in Network
6.2. Handover Control
Handover control procedure follows a network selection process as
explained in the previous section. The following scenario in
Figure 5 shows a network-controlled handover procedure with fast MIP
handover signaling [RFC4068]. Here, the MM in the network utilizes
MIHF implementing CS and generates a link switch command with CS-
Melia, et al. Expires December 20, 2006 [Page 20]
Internet-Draft Network Initiated Handovers June 2006
switch-req to the mobile node. The parameters in the message may
include that a make-before-break mechanism is to be performed along
with the target link information e.g. 802.11 network as shown from
the network selection procedure earlier.
The MIHF indicates the Mobile IP function of the impending link
switch along with new link information. The Mobile IP functionality,
If necessary, i.e., it does not have a valid Access Router Tuple-Info
[RFC4068], it sends a Proxy Router Solicitation (PrRtrSol) with the
new link information (e.g. MAC address of AP) and the Proxy Router
Advertisement (PrRtrAdv) provides the relevant L3 information for the
mobile node to use on the new link. The MIHF in the mobile node
executes the command by sending an "associate" request to the 802.11
MAC which will perform all necessary L2 association and
authentication procedures for the new link. For completeness, steps
3 and 4 in Figure 5 can take place in parallel to steps 3 and 4.
A link-up indication is sent to the interested parties including
Mobile IP functionality. Mobile IP sends a Fast Binding Update (FBU)
to the old FA over the old link so that old FA could switch (tunnel)
the packets to the new FA. The mobile node now is able to receive
packets from new FA that are tunneled from old FA. At a later time,
the mobile node performs an Mobile IP update procedure to update the
binding in the HA and reroute the tunnels directly from HA to the new
FA in the new network corresponding to the 802.11 link. Once the
traffic uses the new link, the MIHF releases the old link by sending
a request to that MAC layer, here the 3GPP radio link. A CS-switch-
resp is sent back to the MM upon completion of the command.
The following signaling flow shows how the network controlled handoff
can work with fast MIP handover signaling [RFC4068]. It shows a
make-before-break mechanism, so that the mobile node sends the FBU on
the old link after the setup of the new link to minimize the latency
due to L2 association and authentication procedures. For
completeness, steps 3 and 4 in Figure 5 can take place in parallel to
steps 2 and 3.
Melia, et al. Expires December 20, 2006 [Page 21]
Internet-Draft Network Initiated Handovers June 2006
Mobile Node
|--------------------------|
+----+ +-----+ +-------+ +----+ +------+ +----+ +----+
|MIP | |MIHF | | Link | | MM | |802.11| | AR | | HA |
| | |(CS) | | Layers| | | | | | | | |
+----+ +-----+ +-------+ +----+ +------+ +----+ +----+
| | | | | | |
| | | +-----------+ | | |
| | | | Network | | | |
| | | | Selection | | | |
| | | +-----------+ | | |
| | 1.CS-switch-req | | | |
2.switch-ind|<====================| | | |
|<-------| 3. PrRtrSol | | | |
|=================================================>| |
| | 4. PrRtrAdv | | |
|<=================================================| |
| |3.associate| | | | |
| |---------->| 4.L2 Association | | |
5.link-up | |<---------------->| | |
|<--------| | | | | |
| | 6. FBU | | | |
|=================================================>| |
+----------------------------------------------------------------+
| Mobile IP update procedure over new link |
+----------------------------------------------------------------+
| 7.release | | | | |
| |---------->| | | | |
| | 8.CS-switch-resp | | | |
| |>>>>>>>>>>>>>>>>>>>>| | | |
| | | | | | |
+----+ +-----+ +-----+ +-----+ +----+ +------+ +---+
|------------------------------|
Legend: ===== over current link, >>>>over new link
Figure 5: Network-Controlled Handover Procedure
7. Design considerations
7.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 fulfill all the goals
listed below:
Melia, et al. Expires December 20, 2006 [Page 22]
Internet-Draft Network Initiated Handovers June 2006
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.
7.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.
8. 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.
9. 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.
Work along these lines already started. [I-D.nakhjiri-aaa-hokey-ps]
presents initial ideas how the problems described in this document
could be solved.
Melia, et al. Expires December 20, 2006 [Page 23]
Internet-Draft Network Initiated Handovers June 2006
10. Acknowledgments
The authors would like to thank Rajeev Koodli for his valuable
comments and suggestions.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006.
[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.
[draft-daniel-mip-link-characteristic-02]
Melia, et al. Expires December 20, 2006 [Page 24]
Internet-Draft Network Initiated Handovers June 2006
Park, S., "Link Characteristics Information for Mobile
IP", draft-daniel-mip-link-characteristic-02 (work in
progress), June 2005.
[3GPP.23.882]
3GPP, "3GPP system architecture evolution (SAE): Report on
technical options and conclusions", 3GPP TR 23.882 0.10.1,
February 2006.
[I-D.nakhjiri-aaa-hokey-ps]
Nakhjiri, M., "AAA based Keying for Wireless Handovers:
Problem Statement", draft-nakhjiri-aaa-hokey-ps-01 (work
in progress), January 2006.
[I-D.vidya-mipshop-handover-keys-aaa]
Narayanan, V., "Handover Keys Using AAA",
draft-vidya-mipshop-handover-keys-aaa-01 (work in
progress), October 2005.
[I-D.ietf-netlmm-nohost-ps]
Kempf, J., "Problem Statement for IP Local Mobility",
draft-ietf-netlmm-nohost-ps-00 (work in progress),
February 2006.
[I-D.mohan-nflm-proto]
Parthasarathy, M., "Network-based Fast Handovers for Local
Mobility (NFLM)", draft-mohan-nflm-proto-00 (work in
progress), October 2005.
[RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L.
Bellier, "Hierarchical Mobile IPv6 Mobility Management
(HMIPv6)", RFC 4140, August 2005.
[RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005.
[I-D.melia-mobopts-niho-fmip]
Melia, T., "Network initiated handover in fast mobile
IPv6", draft-melia-mobopts-niho-fmip-01 (work in
progress), July 2005.
[I-D.korhonen-mobopts-link-characteristics-ps]
Korhonen, J., "Link Characteristic Information for IP
Mobility Problem Statement",
draft-korhonen-mobopts-link-characteristics-ps-00 (work in
progress), October 2005.
Melia, et al. Expires December 20, 2006 [Page 25]
Internet-Draft Network Initiated Handovers June 2006
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
Srinivas Sreemanthula
Nokia
6000 Connection Dr.
Irving, Texas 75039
USA
Phone: +1 972 894 4356
Email: Srinivas.Sreemanthula@nokia.com
Melia, et al. Expires December 20, 2006 [Page 26]
Internet-Draft Network Initiated Handovers June 2006
Vivek Gupta
Intel Corporation
2111, NE 25 Avenue
Hillsboro, OR 97124
USA
Phone: +1 503 712 1754
Email: vivek.g.gupta@intel.com
Melia, et al. Expires December 20, 2006 [Page 27]
Internet-Draft Network Initiated Handovers June 2006
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 (2006). 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 December 20, 2006 [Page 28]
