Seamoby Working Group Stefano Faccin
INTERNET DRAFT Rajeev Koodli
17 September 2001 Franck Le
Jari T. Malinen
Rene Purnadi
Nokia Research Center
Dormant Mode Handover Support in Mobile Networks
draft-koodli-paging-00.txt
Status of This Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
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 document is an individual submission for the mobile-ip Working
Group of the Internet Engineering Task Force (IETF). Comments should be
submitted to the seamoby@diameter:org mailing list.
Distribution of this memo is unlimited.
Abstract
This document defines an IP paging concept that supports IP dormancy
for hosts and Mobile Nodes. The concept specifies a generic model that
can be applied to several mobility mechanisms (including Mobile IPv6,
Localized Mobility Managament) and is independent of the layer-2 access
technology and paging capabilities. The model allows for optimizations
of the benefits of layer-2 paging when present, while minimizing the
impact on layer-2 paging.
Expires 17 March 2002 [Page i]
Internet Draft Dormant Mode Handover Support 17 September 2001
Contents
Status of This Memo i
Abstract i
1. Introduction 2
2. Terminology 2
3. Protocol Overview 3
4. IP Paging Model 4
4.1. Mobile Node IP Paging States . . . . . . . . . . . . . . 4
4.2. IP Paging Illustration . . . . . . . . . . . . . . . . . 5
4.3. Advertising Paging Area Information . . . . . . . . . . . 6
4.4. PF Discovery . . . . . . . . . . . . . . . . . . . . . . 7
4.5. Paging Area Update . . . . . . . . . . . . . . . . . . . 7
4.6. Detecting IP Dormant MN . . . . . . . . . . . . . . . . . 7
4.7. Paging Deregistration . . . . . . . . . . . . . . . . . 8
5. IP Paging Identity 8
5.1. The network configures L3 IP Paging Identity . . . . . . 8
5.2. The L3 IP Paging Identity via autoconfiguration . . . . . 9
5.3. L2 identity for paging . . . . . . . . . . . . . . . . . 10
6. Security Model for IP Paging 10
6.1. Authentication of Paging Request messages . . . . . . . . 10
6.2. Authentication of Paging Response . . . . . . . . . . . . 12
6.3. Authentication of Paging Area Update . . . . . . . . . . 13
6.4. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Application of IP Paging Model to Different Scenarios 16
8. Comparing Against the Requirements 18
8.1. Impact on Power Consumption . . . . . . . . . . . . . . 19
8.2. Scalability . . . . . . . . . . . . . . . . . . . . . . 19
8.3. Control of Broadcast/Multicast/Anycast . . . . . . . . . 20
8.4. Efficient Signaling for Inactive Mode . . . . . . . . . 20
8.5. No Routers . . . . . . . . . . . . . . . . . . . . . . . 20
8.6. Multiple Dormant Modes . . . . . . . . . . . . . . . . . 20
8.7. Independence of Mobility Protocol . . . . . . . . . . . 21
8.8. Support for Existing Mobility Protocols . . . . . . . . 21
8.9. Dormant Mode Termination . . . . . . . . . . . . . . . 21
8.10. Network Updates . . . . . . . . . . . . . . . . . . . . 22
8.11. Efficient Utilization of L2 . . . . . . . . . . . . . . 22
Expires 17 March 2002 [Page ii]
Internet Draft Dormant Mode Handover Support 17 September 2001
8.12. Orthogonality of Paging Area and Subnets . . . . . . . . 22
8.13. Future L3 Paging Support . . . . . . . . . . . . . . . . 23
8.14. Robustness Against Failure of Network Elements . . . . . 23
8.15. Reliability of Packet Delivery . . . . . . . . . . . . . 23
8.16. Robustness Against Message Loss . . . . . . . . . . . . 23
8.17. Flexibility of Administration . . . . . . . . . . . . . 24
8.18. Flexibility of Paging Area Design . . . . . . . . . . . 24
8.19. Availability of Security Support . . . . . . . . . . . . 24
8.20. Authentication of Paging Location Registration . . . . . 24
8.21. Authentication of Paging Area Information . . . . . . . . 25
8.22. Authentication of Paging Messages . . . . . . . . . . . 25
8.23. Paging Volume . . . . . . . . . . . . . . . . . . . . . 25
A. Hierarchical Overlapping Paging Area Support 26
Addresses 28
Expires 17 March 2002 [Page 1]
Internet Draft Dormant Mode Handover Support 17 September 2001
1. Introduction
The problem of Dormant Mode Host Alerting, otherwise known as IP Paging,
is well-defined and described in [2]. It is generally accepted that
an IP Paging solution would offer many advantages including, power
saving when it is not available in certain Layer 2 technologies (and
enhancing it in those that already offer it), reduced IP layer signaling
during dormant mode movements, and offering location tracking across
heterogeneous access technologies, among others. While these advantages
are compelling, the solution itself has to meet certain requirements.
Specifically, it is identified that an IP Paging proposal has to address
the requirements set forth in RFC 3154. In this document, we propose a
mechanism for IP Paging that provides the following advantages.
1. is independent of any mobility management protocol
2. can be adopted with several mobility management protocols while
not only allowing to enjoy the benefit of DMHA in terms of both
power saving and reduced signaling message exchange, but actually
optimizing both
3. allows to optimize the interaction between IP paging and L2
paging mechanisms when present
4. minimizes impact on L2 paging and link layer technologies
5. provides improvements in terms of power saving and minimization
of mobility signaling with respect to the presence of L2 paging
only
6. supports both implicit and explicit IP dormancy
7. allows support of different access technologies in the same IP
paging area
8. supports dynamic IP paging area
Our proposal addresses the requirements set forth in RFC 3154. This is
outlined in Section 8.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and "silently
ignore" in this document are to be interpreted as described in RFC 2119.
Expires 17 March 2002 [Page 2]
Internet Draft Dormant Mode Handover Support 17 September 2001
3. Protocol Overview
We coalesce the functional entities identified in RFC 3154, namely
the Dormant Mobility Agent, the Tracking Agent, and the Paging Agent,
into a single logical entity which we call the ``Paging Function'' or
``PF''. There are several advantages to such a coalescing of different
functional elements. First, it provides a single, trusted channel of
paging-related communication between a MN and the network. For all
paging purposes, the MN communicates with a single logical entity and
secures its communication using an appropriate security association
it shares with that entity. Second, since the MN deals with a single
entity, the problem of discovering different functionalities is
alleviated. Depending on where the PF is realized, the MN deals with
its Access Router or visited domain Mobility Agent only. Third, since
the MN deals with a single entity, the number of separate messages
necessary to communicate with different elements, potentially over an
expensive air interface, can be reduced by aggregating them together.
For instance, a single message can establish the necessary paging state
at DMA, TA and the PA.
The PF may be realized in different ways in practice. We provide some
examples in Section 7. Note that since the IP dormancy of a MN has to
be checked before the packet can be delivered to a MN, all the incoming
packets traverse the PF. When an IP packet arrives at a PF, where the
MN has last established its presence, the PF has to determine how to
forward the packet. We propose two ways by which the PF acertains that
the MN to which the packet is addressed to has undergone dormant mode
handover. First, prior to undergoing the dormant mode handover, the MN
performs an explicit registration with the PF. Second, we allow for an
implicit registration, in which the network may initiate IP Paging when
it discovers that a MN is no longer reachable. The details of these
registration procedures are presented in 4.
Once the PF determines the need for IP Paging, it initiates a paging
message addressed to an IP Paging Area (IP-PA). We identify each IP-PA
by an IP multicast group, whose members are typically all the access
routers to which a MN could be ``dormantly connected''. We propose
sending IP Paging messages over the access network, which is typically
connected with a higher-speed network compared to the access link
bandwidth, and make use of Layer 2 paging as much as possible over the
air interface. This ensures preserving spectrum where it is considered
important and allows usage of enhanced IP messages over a higher-speed
access network. Each IP-PA could span multiple subnets and each subnet
could represent a disparate access technology. An IP Paging message
sent to the IP-PA multicast group contains a unique paging identity that
is known both to the latest PF and the MN. This paging identity serves
two purposes. It acts as input to a function that creates a Layer 2
identity to page once an IP Paging message is received over the access
network. Where Layer 2 paging is not available, the unique paging
Expires 17 March 2002 [Page 3]
Internet Draft Dormant Mode Handover Support 17 September 2001
identity is used to send an IP Paging message over the access link. The
description of this unique paging identity and the IP Paging message
sent over the acces network itself is described in Section 5.
One or more of the PFs perform paging (either L2 or IP layer) in
response to the arrival of an IP Paging message over the access network.
In response to this access link paging message, the MN wakes up and
responds to the access link paging message. The MN may then proceed to
perform IP layer registrations, such as a Binding Updates. The access
link paging messages must be secure and allow for mutual authentication
of the network and the MN. These messages and the corresponding
operations (in the form of a state machine) are described in Section 4.
In the subsequent section, we describe the relation between the IP
paging and Layer 2 paging.
It is clearly identified that the IP paging mechanism must address
the security considerations. These are elaborated in Section 6. We
discuss the realization of the PF entity in an AR or a Mobility Agent
in Section 7. Finally, we describe some important enahncements to the
basic IP Paging protocol in Section A.
4. IP Paging Model
4.1. Mobile Node IP Paging States
The MN IP paging states model the MN behavior in terms of MN activity
and reachability at IP level. The following states are defined.
- MN de-registered: MN is not reachable, has no IP address
allocated and is not able to send or receive any packets to the
network (e.g. terminal is powered off).
- MN Registered-Active: MN has performed the registration to
access the network, has a valid IP address, and is capable
of sending and receiving packets without need for additional
signaling.
- MN Registered-IP Dormant: Location tracking is at the IP-PA
level, i.e., routing information is available to route packets to
the "paging area" or, better, to the node acting as PF. While IP
dormant, MN wakes up only to perform appropriate operations (e.g.
listen for paging, signal when entering a new IP-PA, etc.). In
order to forward packets to the MN the network needs to page the
terminal at the IP level (IP paging).
When the terminal is not a mobile node but any generic host, we define
the following states.
Expires 17 March 2002 [Page 4]
Internet Draft Dormant Mode Handover Support 17 September 2001
- Active Host: the host is connected to the network, has a valid
IP address is capable of sending and receiving packets without
need for additional signaling.
- IP Dormant Host: the host is reachable only at the IP-PA level,
i.e., routing information are available to route packets to the
"paging area" or, better, to the node acting as PF. While IP
dormant, the host wakes up only to perform appropriate operations
(e.g. listen for paging, paging area updates needed when
entering a new IP-PA, etc.). In order to forward packets to
the host, the network needs to page the host at the IP level(IP
paging).
4.2. IP Paging Illustration
We illustrate the concepts using Figure 1.
At time t0 packets destined for the MN arrive at the PF. At t1, the PF
realizes that the MN is IP dormant. At t2 the PF sends ``IP Paging
Request'' message to all ARs within the IP-PA where the MN is located.
At t3 the Access Router either sends a L3 paging request (e.g., a router
advertisement with paging extension) or it converts the IP Paging
Request message into an appropriate L2 paging message and forwards the
request to the MN. When L2 paging is used, the L3 paging id is mapped to
a L2 paging id. At the assigned time slot (t4) or the paging channel,
the MN wakes up and listens to the page. The MN then responds to the
paging message with a ``Paging Response'' message to its AR. The MN
(either subsequently or together with the Paging Response message)
performs the IP mobility (neighbor discovery and binding updates)
procedures. At t5, the MN or its new AR requests PF to forward the
buffered packets and delete the state of dormancy of the MN.
The PF determines that the MN is dormant based on explicit ``Paging
Registration'' message that the MN sends before entering IP-dormant
state. The PF may also determine, implicitly, that the MN is IP-dormant
based on a MN-specific timer that expires in the event of traffic
inactivity. When a MN wakes up in response to paging, the PF performs
``Paging De-registration'' in order to update or remove state related to
MN's dormancy.
The IP Paging Request message is resent if it is not acknowledged. The
acknowledgements, i.e., the Paging Response message could arrive from
any of the ARs or directly from the MN. The re-transmissions are done up
to a configurable number of times.
Expires 17 March 2002 [Page 5]
Internet Draft Dormant Mode Handover Support 17 September 2001
|
| (t0) incoming packet
V
+----+
| |
| PF | (t1) PF realizes that MN is dormant
| |
+----+
( |
/ |<- (t2) ``IP Paging Request'' to all ARs within IP-PA.
|<- (t5) MN (or AR on its behalf) requests PF to forward packets.
+---------|---------------------------+`
| +---|----+--------+--------+ |
| | | | | | |
| | | | | | |
| V | V V V |
| +----+ | +----+ +----+ +----+ |
| | AR | | | AR | | AR | | AR | |
| +----+ \+----+ +----+ +----+ |
| | \ |^ | | |
| | \ || | |<- (t3) L3/L2 Paging Request to all MN
| V \V| V V in each AR
| +----+ |
| | MN | (t4) MN wakes-up and replies with ``Paging Response''.
| +----+ MN performs IP mobility
| to connect to AR and CN
| IP paging area |
+-------------------------------------+
Figure 1: IP Paging Illustration
4.3. Advertising Paging Area Information
The MN determines the identity of the IP Paging Area (IP-PA) it
currently is in based on the IP-PA Identity that is advertised.
Together with the IP-PA Identity, other IP-PA information, such as the
IP-PA profile that indicates characteristics of that paging area, could
be broadcast as well. The IP-PA Identity and profile information are
advertised by Paging Functions to all the Access Routers in the IP-PA by
multicasting them to the ARs. On receipt of this information, each AR
in the IP-PA needs to advertise the same information to the MNs in its
subnet. This is done using extensions to Router Advertisements.
Expires 17 March 2002 [Page 6]
Internet Draft Dormant Mode Handover Support 17 September 2001
The multicast address for IP Paging Area Advertisements is the same used
by the PF to send IP Paging Requests in its IP-PA.
4.4. PF Discovery
The MN needs to know the identity of the serving PF to send the
different Paging messages such as Paging Area Update, IP Paging
Registration in the case of explicit dormancy, etc. In the implicit
dormancy case, the MN still needs to know the identity of the serving
PF: e.g., when it moves to an area served by a new PF, the MN needs
to provide the new PF with the identity of the previous PF so that IP
paging state in the previous PF can be released and information required
at the new PF (e.g. local paging session key) can be retrieved. As
described in the following corresponding sections, many mechanisms exist
for the MN to discover the PF identity.
The PF discovery can be done in several ways. The PF address can be
sent over router advertisements. Or the MN can send a Paging Function
Discovery Request to a pre-defined well-known anycast address. And
then, one of the Paging Functions, serving the area the MN is currently
located, would reply in a Paging Function Discovery Reply, providing
its identity. Once it discovers the PF, the MN then perform all the
required procedures with the selected PF.
4.5. Paging Area Update
When the MN realizes that it has moved to a different IP-PA, the MN
initiate a paging area update procedure. The paging area update will
inform the the PF the current IP-PA so that paging can be efficiently
directed to the correct IP-PA. The Paging Area Update message is
typically sent when a MN learns of a new paging area from paging area
advertisements.
4.6. Detecting IP Dormant MN
The PF declares that a MN is IP dormant upon receiving an explicit
message to requet IP dormancy from the MN (explicit dormancy).The
message requires to carry information such as the indication that MN
wishes to go IP dormant, authentication data to verify the source of
request, the Paging Area identity, etc. On the other hand, if the the
lack of traffic activity timer expires (implicit dormancy), the PF
determines that the MN is dormant again.
Expires 17 March 2002 [Page 7]
Internet Draft Dormant Mode Handover Support 17 September 2001
4.7. Paging Deregistration
Paging deregistration is required in the following cases.
- when MN goes out of coverage: the state in the PF must be
released, and this will also save unecessary paging. This can be
e.g based on a timer with a long expiration time.
- when the MN becomes active, the paging state in the PF must be
released.
- when the MN handovers to a new PF, the paging state in the old PF
must be released.
In the latter two cases, the Paging Response message or the Paging Area
Update message to the new PF, results in releasing the paging state.
For instance, when the MN is attached to a new PF, the latter sends a
message to the old PF to release the state.
5. IP Paging Identity
To ensure that IP paging in an IP-PA can trigger L2 paging so that
the appropriate identity can be used at L2 to page the MN (i.e. the
identity at L2 that the MN is expecting to be paged with), an L3 IP
paging identity is proposed for the MN. The identity is generated
according to a well-know mechanism and based on a well-known set of
inputs. This guarantees all MNs and networks know how to compute it.
This also allows for the identity to be auto-configurable. This L3 IP
paging identity needs to be unique only within an IP-PA. This allows for
a shorter identifier.
The assumption is that when the MN is registered to the network, both
the MN and the network (in particular the PF) know the L3 IP Paging
Identity that will be used for paging while MN is within the IP-PA. A
mapping algorithm is defined for each link layer technology (if needed)
to convert the L3 IP Paging Identity into a L2 temporary identity that
can be used to page the MN at L2. When MN is IP dormant and enters
an area of coverage of a specific link layer technology, it will map
the L3 IP Paging Identity to a L2 identity. When an IP Paging message
is received by an AR, it is pushed to the AP where the L3 IP Paging
Identity is mapped by the AP to a L2 paging identity according to the
link layer technology. The L2 identity is then used to page the MN.
5.1. The network configures L3 IP Paging Identity
The PF generates a temporary L3 IP paging identity that is valid for an
IP-PA. If the IP-PA consists of multiple access technologies, the L3 IP
Expires 17 March 2002 [Page 8]
Internet Draft Dormant Mode Handover Support 17 September 2001
Paging Identity will have the length equal to the shortest length of
the L2 paging identity in a particular technology. Therefore, for that
particular technology that has the shortest length L2 paging identity,
the L2 paging identity is equal to the L3 paging identity. For the
other access technology, the L2 paging identity is the expansion of the
L3 IP paging identity. To cover the case of the distibuted PF, each L3
IP paging identity consists of PF unique part and MN unique part. This
scheme allows the uniqueness of the L3 paging identity in an IP-PA and
uniqueness of L2 paging identity in each access technology.
Let's assume that the IP-PA consists of access technology A that
requires 32 bits L2 paging identity, access technology B that requires
128 bits paging identity and access technology C that requires 20 bits
L2 paging identity. The PF will generate a 20 bits temporary L3 IP
paging identity for the MN. When the MN uses access technology C, it
uses the temporary L3 IP paging identity as its L2 paging identity.
If the MN acquires access technology A, the MN will expand the 20
bits temporary L3 IP paging identity into 32 bits L2 paging identity,
retaining the uniqueness of the temporary L3 paging identity. In case
of distributed PF, the uniqueness of the temporary L3 IP Paging identity
can be defended by assigning the first `n' bits unique to the PF and the
remaining of the bits unique to the MN.
In addition to computing the L2 Paging Identity, both the MN and the
access point also use the L3 IP Paging identity to calculate the time
slot/paging channel to be monitored.
5.2. The L3 IP Paging Identity via autoconfiguration
Each AR broadcasts PA identifier (PA-Id) that consists of AR specific
part and paging area specific part. Upon receiving this PA-Id, the MN
uses a hash function `F1' to its own identifier (e.g., its NAI, its
permanent IP Address, etc.) and generates L3 IP Paging Id that consists
of the AR specific part that is received from PA-Id and the result of
`F1' toward its own identifier. The length of the L3 IP Paging Id is
maximum equal to the L2 paging id in that particular access technology.
When the MN sends a paging area update, the newly calculated L3 IP
Paging Id, together with old L3 IP Paging Id and old PF, are included in
the paging area update request message. If the newly calculated L3 IP
Paging Id is valid, an SUCCESS indication is sent by the PF to the MN
through paging area update response message. If it is not valid, the PF
calculates a new L3 IP paging Id that consists of the AR specific part
and MN specific part, and sends it to the MN via the paging area update
response. From the L3 IP Paging Id, the MN uses another function `F2'
to calculate the L2 Paging Id and function `F3' to calculate the time
slot/paging channel to monitor. The access point also uses the L3 IP
Expires 17 March 2002 [Page 9]
Internet Draft Dormant Mode Handover Support 17 September 2001
Paging Id to calculate the L2 paging Id (using F2 function) and the time
slot/paging channel (using F3 function).
5.3. L2 identity for paging
IP Paging must trigger L2 paging for technologies that have it. L2
paging is based on temporary identifiers specific to the L2 technology.
Even if the L2 temporary identifier is known at the location where MN
went IP dormant, the identifier cannot be used for paging in the points
of attachment under other ARs since the identifier may be already in
use. In addition, if several link layer technologies are supported
in same IP-PA, IP paging cannot use the L2 paging identity of one
technology to page in the others.
Link-layer technology needs to know what time-slot/paging channel to
use to page the MN. The correct time-slot/paging channel is known at
location where MN went IP dormant, but not necessarily at the point
of attachment where the MN actually is located. How do the points of
attachment select the appropriate time-slot/paging channel to page? The
time slot/paging channel is decided based on the L3 paging identity.
For instance, in the current cellular systems, the time slot/paging
channel is obtained using a hash function to the IMSI.
6. Security Model for IP Paging
IP paging protocol MUST have a strong security mechanism to prevent
all the threats identified and described in [4] that may affect
the IP paging protocol performance. Without an adequate security
scheme, IP paging may not provide all the identified benefits but
results in opposite effects, namely, increased signaling load due to IP
paging, congested network, reduced battery life and even breakdown in
communication for the MN.
The different paging messages SHOULD be authenticated.
6.1. Authentication of Paging Request messages
The Paging Request messages SHOULD be authenticated. Otherwise, an
intruder may send fake Paging Request messages to the dormant MN. The MN
will unnecessarily wake up and this may prevent that MN from switching
to dormant mode. As a result, the MN may quickly run out of battery,
hence become inaccessible. In wireless networks, the MN will also try
to set up the radio connection and this may result in the waste of radio
resources, which are already rare and expensive.
Expires 17 March 2002 [Page 10]
Internet Draft Dormant Mode Handover Support 17 September 2001
Many methods are possible to authenticate the Paging Request messages:
The MN and the network can set up a Paging session key `K'. The
mechanism to compute and distribute this key is out of the scope of this
document. Then the network can use this key to authenticate the Paging
Request message.
Paging Request authentication may be performed between the PF and the MN
or between the AR and the MN. If performed in AR, the PF may store this
paging session key and distribute it to the different Access routers of
the paged area in the paging message; or the access router may retrieve
it from a Key Storage Center.
Anti Replay protection may be provided using timestamps, however, time
stamp based protocols require the involved nodes to have time clocks and
for those time clocks to be both synchronized and secured. We propose
the following mechanism to provide authentication of Paging Request
message. See Figure 2.
1. When an incoming packet destined to a dormant MN arrives at the
PF, the latter pages different access routers of the Paging Area
by sending a Paging Request multicast message.
2. The Paging message may contain the session key shared between the
MN and the network; or a receiving AR may retrieve it from a Key
Storage Center.
3. The Access router generates a random number R, and creates a
sequence number N1. This sequence number is user and router
specific and must only increase in value.
The Access Router computes a Token based at least on R, N1, K and
a common algorithm shared with the MN: Token (N1, R, K).
The access router encrypts N1 using K, K[N1], and sends the Token
(N1, R, K), the random number, R, and the encrypted N1 to the MN
for network authentication.
4. On receipt of the IP paging request, the MN
- deciphers N1 using K (K[N1), and verifies its validity: N1
must always increase in value; this will ensure the freshness of
the message
- verifies the token: the MN can thus make sure the IP Paging
Request is coming from the valid network
Expires 17 March 2002 [Page 11]
Internet Draft Dormant Mode Handover Support 17 September 2001
|
| 1)incoming packet
V
+----+
| |
| PF | PF realizes that MN is dormant
| | K
+----+
|
| 2)Page to all AR within the IP paging area
|
+------------|-----------------------+
| +------+ -------+--------+ |
| | | | | |
| |(K) |(K) |(K) |(K) |
| V V V V |
| +----+ +----+ +----+ +----+ |
| | AR | | AR | | AR | | AR | |
| +----+ +----+ +----+ +----+ |
| | |^ | | |
| | || | | 3) L3 paging broadcast to
| | || | | all MN in each AR
| | || | | Token (N1, R, K)
| | || | | R, K[N1]
| V V| V V |
| +----+ |
| | MN | 4) MN deciphers N1
| +----+ verifies Token|
| keeps N1 for future
+------------------------------------+
IP paging area
Figure 2: Securing the Paging Request
If the authentication data is computed by the PF, anti replay attacks
may also be provided by sequence numbers shared between the MN and the
PF. But these sequence numbers must be synchronized. As an example,
every time MN changes PF, the sequence number could be re-initiated.
6.2. Authentication of Paging Response
The Paging Response message SHOULD be authenticated: this will provide
user authentication for network access and will ensure the validity of
the user before forwarding the incoming packets. Authentication of the
Expires 17 March 2002 [Page 12]
Internet Draft Dormant Mode Handover Support 17 September 2001
Paging Response is based on a local session paging key K shared between
the network and the MN. The mechanism to compute this key is out of the
scope of this document. Based on this key, the local challenge, the MN
computes a token whose validity is verified by the PF.
In order to expedite the network access authentication, the PF may
supply the key to all the ARs in the paging area. The MN, when it
performs neighbor discovery procedures to connect to the new AR, may
supply a token using the key and a challenge specific to the AR. Since
the AR would have already received the session key K, it can perform
local authentication without having to approach a AAA server, for
example. See [idle-mode-ct] for details.
1. in the Paging Request message, the PF (or the AR) generates and
includes a Local Challenge.
2. the MN takes this Local Challenge, the local session paging
key K and eventually some other information to compute some
authentication data to be included in the Paging Response
3. the PF (or the AR) verifies the validity of the Paging Response.
If the AR verifies the Paging Response, it sends a corresponding
Paging Response message to the PF.
6.3. Authentication of Paging Area Update
Paging Area Update SHOULD be authenticated. This will limit the
possible damages of Bogus Paging Information identified and described in
[4].
When MN sends a Paging Area Update, the paging information SHOULD be
authenticated. This authentication can be based on a local session
paging key shared between the MN and the PF. The PF can be either the
current one or a new one. The MN will e.g., compute a token based on
the Paging information, the session key and other relevant information.
If the PF is the current one, the PF will already have the session
key and can verify the token. If the PF is a new one, the new PF can
forward the token to the previous PF to have it verified. The MN then
sets up a new session key with the new PF.
As another alternative, the new PF may get the session key either
from the previous PF or from a Key Storage Center, and then perform
authentication of the paging messages.
Anti replay attacks may be provided using:
Expires 17 March 2002 [Page 13]
Internet Draft Dormant Mode Handover Support 17 September 2001
|
| 1)incoming packet
V
+----+
| |
| PF | PF realizes that MN is dormant
| | K
+----+
|
| 2)Page to all AR within the IP paging area
|
+------------|-----------------------+
| +------+ -------+--------+ |
| | | | | |
| |(K) |(K) |(K) |(K) |
| V V V V |
| +----+ +----+ +----+ +----+ |
| | AR | | AR | | AR | | AR | |
| +----+ +----+ +----+ +----+ |
| | |^ | | |
| | || | | 3) L3 paging broadcast to
| | || | | all MN in each AR
| | || | | Local Challenge
| | || | | |
| V V| 4) Paging Response |
| +----+ authentication data
| | MN | (LC, K) |
| +----+ |
| |
+------------------------------------+
IP paging area
Figure 3: Securing the Paging Response
- timestamps, but time stamp based protocols require the involved
nodes to have time clocks and for those time clocks to be both
synchronized and secured.
- sequence numbers but these sequence numbers must be synchronized.
As an example, every time MN changes PF, the sequence number
could be re- initiated.
- random numbers generated by the authenticating PF: the MN first
send a Paging Area Update and the authentication PF will, in
Expires 17 March 2002 [Page 14]
Internet Draft Dormant Mode Handover Support 17 September 2001
response, provide this random number. The MN will resend the
Paging Are Update containing authentication data computed from
the Paging information, and the random number. This method
therefore requires additional messages.
6.4. Filtering
Filtering MAY be applied to reduce the potential DoS Amplification
damages identified and described in [4] and will allow detection of
Bogus CN.
Filtering can be applied on the source or on the types of the packets:
- The MN specifies sources of packets for which it should woken
up. Packets from sources not authorized will not generate paging
request when they reach Paging Function.
- The MN can also specify the type of packets it should be woken up
for.
The MN can send the filtering information to the network at IP Paging
Area Update; and MN can update them at paging response or at any time.
The network may also have some pre-defined filtering rules of its own.
Filtering allows a flexible handling of incoming packets. Based on the
filtering information, the packets can be:
- discarded: packets are discarded and MN will not receive them
- buffered: packets are buffered up to maximum size of per-MN FIFO
buffer and provided to the MN only when the MN becomes active.
Buffer overflow can be handled by storing only the recent packets
or according to other criteria (e.g. "priority")
- grouped:packets are buffered until a certain amount. When that
amount is reached, MN is paged and the packets delivered, or
- processed based on other rules.
Efficiency of filtering is strongly related to the ability to verify the
type or source of packets: A bogus CN can, e.g., send packets using
fake source addresses. So there needs to be a mechanism to "verify" the
source. The MN may be able to establish a Security Association with
CN for which it wishes to be woken up (e.g., a SIP server) and provide
filtering function with security parameters so that it can verify source
authenticity for packet from CNs.
Expires 17 March 2002 [Page 15]
Internet Draft Dormant Mode Handover Support 17 September 2001
Filtering assumes that MN knows in advance what CN will initiate
a Mobile Terminated communication. This may be acceptable in some
specific environments. MN knows in advance what Mobile Terminated
services will take place (e.g. SIP calls from a Call Control Function
it has previously registered with, IMPP from server it has previously
provided presence information to, e-mail server it has previously
"registered" with, etc.); but this may not always be applicable and more
particularly for push services to the MN from unknown sources.
7. Application of IP Paging Model to Different Scenarios
The IP paging model can be applied to several different scenarios,
whether IP mobility is present or not. In case IP mobility mechanisms
are present, the IP paging model can be applied to different scenarios.
Scenarios for Mobile IPv4 are not described in this section, but the IP
paging model can be applied to Mobile IPv4 as well.
Figure 4 represents the scenario where Mobile IPv6 is
adopted in the network. In such a case, the PF can be either in the
Access Router (AR) or it can be a node in the network not related to
mobility.
+-----------------------------+
/ \
/ \
+----+ + IP Network +
| PF |-------> |
+----+ | |
| + +
| \ /
| \ /
| +-----------------------------+
|
|---------+-------+-----------+-------+-------+
| | | | | |
| IP Paging Area| |IP Paging Area |
+--|---------|-------|---+ +----|-------|-------|---+
| +V---+ +--V-+ +--V-+ | | +--V-+ +--V-+ +--V-+ |
| | AR | | AR | | AR | | | | AR | | AR | | AR | |
| +----+ +----+ +----+ | | +----+ +----+ +----+ |
+------------------------+ +------------------------+
Figure 4: MIPv6 scenario.
Expires 17 March 2002 [Page 16]
Internet Draft Dormant Mode Handover Support 17 September 2001
Figure 5 represents the scenario where Mobile IPv6 Regional Registration
is adopted in the network. In such a case, the PF can
be either in the Access Router (AR), in one of the Crossover Routers,
in the GMA or it can be a node in the network not related to mobility
(e.g. in case of implicit dormancy). In the Figure, CR is a Cross-over
Router.
+------------------>+----+
| +-----------|GMA |------------+
| / +----+ \
| / +----+ +----+ \ IP
+----+ + | CR | | CR | + Network
| PF |------->+----+ +----+ |
+----+ | +----+ +----+ +----+ +----+ |
| + | CR | | CR | | CR | | CR | +
| \+----+ +----+ +----+ +----+/
| \ /
| +-----------------------------+
|
|---------+-------+-----------+-------+-------+
| | | | | |
| IP Paging Area| |IP Paging Area |
+--|---------|-------|---+ +----|-------|-------|---+
| +V---+ +--V-+ +--V-+ | | +--V-+ +--V-+ +--V-+ |
| | AR | | AR | | AR | | | | AR | | AR | | AR | |
| +----+ +----+ +----+ | | +----+ +----+ +----+ |
+------------------------+ +------------------------+
Figure 5: MIPv6 Regional Registration.
Figure 6 represents the scenario where Hierarchical Mobile IPv6
is adopted in the network. In such a case, the PF can be either in the
Access Router (AR), in the MAP, or it can be a node in the network not
related to mobility.
In scenarios where PF is distributed to the ARs, each AR acts as a PF
for a given MN in a given moment. The simplest approach to implement a
distributed PF is by defining as PF for a given MN the latest AR where
the MN is connected before the MN becomes IP dormant (explicitly or
implicitly). As shown in Figure 7, the PF forwards IP paging messages
to all ARs within the IP-PA. Each AR will forward the IP paging to all
the MNs connected to the AR with the appropriate interactions between IP
Paging and L2 paging, when L2 paging is present.
Expires 17 March 2002 [Page 17]
Internet Draft Dormant Mode Handover Support 17 September 2001
+------------------>+----+
| +-----------|MAP |------------+
| / +----+ \
| / \
+----+ + IP Network +
| PF |-------> |
+----+ | |
| + +
| \ /
| \ /
| +-----------------------------+
|
|---------+-------+-----------+-------+-------+
| | | | | |
| IP Paging Area| |IP Paging Area |
+--|---------|-------|---+ +----|-------|-------|---+
| +V---+ +--V-+ +--V-+ | | +--V-+ +--V-+ +--V-+ |
| | AR | | AR | | AR | | | | AR | | AR | | AR | |
| +----+ +----+ +----+ | | +----+ +----+ +----+ |
+------------------------+ +------------------------+
Figure 6: HMIPv6 Scenario.
In hierarchical IP mobility solutions such as MIPv6RR, the PF can be
located in any of the mobile agents. In particular, the PF can be
distributed to the ARs, to the CRs or implemented in the GMA. If PF is
in the GMA, the CR and AR do not maintain any state for a MN when MN is
IP dormant. MIPv6RR is used, as currently specified, only when MN is
not IP dormant. If the PF is in a CR, IP-PA covers all ARs "below" CR
and or even larger area. "Above" the CR, all mobility-aware routers
(CRs and GMA) maintain the state for the MN (normal MIPv6RR). If the PF
is in the AR, the scenario is the same as the MIPv6 or flat LMM. Similar
to the PF in a CR, all mobility-aware routers (CRs and GMA) maintain the
state for the MN.
The optimal location of the PF depends on relation with IP mobility and
LMM and may depend on type of the terminal and the user.
8. Comparing Against the Requirements
The proposed paging concept is compared to the draft-ietf-seamoby-paging-
requirements-01.txt
Expires 17 March 2002 [Page 18]
Internet Draft Dormant Mode Handover Support 17 September 2001
|t4:incoming packet routed
|last point of attachment(AR2)
|
+----------|------------------------+ +---------------------+
| | IP-PA 1 | | IP-PA 2 |
| _____ V t5:IP paging to all ARs in|IP-PA1 |
| / \ / \ \ \ | | |
| +---+ +---+ +---+ +---+ +---+ | | +---+ +---+ +---+ |
| |AR1| |AR2| |AR3| |AR4| |AR5| | | |AR6| |AR7| |AR8| |
| +---+ +---+ +---+ +---+ +---+ | | +---+ +---+ +---+ |
+-----------------------------------+ +---------------------+
| | |
| | |
| | t3:moves to AR3, no L3 mobility procedure
| t1:moves with L3 mobility procedure (active handoff)
t0:MN point t2:goes dormant, AR2 becomes PF
of attachment
is AR1
Figure 7: IP paging applied to the distributed PF scenario.
8.1. Impact on Power Consumption
The IP paging protocol MUST minimize impact on the Host's dormant mode
operation, in order to minimize excessive power drain.
The proposed paging concept utlilizes IP-PA (IP Paging Area) where the
MN does not have to wake up and execute L3 procedure while inside an
IP-PA to make the MN wakes up less frequently.
It allows further optimizations in terms of power saving and reduced
signaling message exchange when adopted in conjunction with IP mobility
mechanisms.
It also allows to optimize the interaction between IP paging and L2
paging mechanisms when present. As an example, with the proposed model
an IP dormant MN does not need to perform any L2 mobility signaling when
moving within the same IP paging area
8.2. Scalability
The IP paging protocol MUST be scalable to millions of Hosts.
Expires 17 March 2002 [Page 19]
Internet Draft Dormant Mode Handover Support 17 September 2001
Distributing and allowing flexible location of the paging function in
flat or hierarchical mobility scenarios as well in non-mobile networks
in the proposed paging concept provides scalability
8.3. Control of Broadcast/Multicast/Anycast
The protocol SHOULD provide a filter mechanism to allow a Host prior
to entering dormant mode to filter which broadcast/multicast/anycast
packets active a page. This prevents the Host from awakening out of
dormant mode for all broadcast/multicast/anycast traffic.
The paging function is capable of filtering the paging message (based
on explicit information provided by the MN)
8.4. Efficient Signaling for Inactive Mode
The IP paging protocol SHOULD provide a mechanism for the Tracking Agent
to determine whether the Host is in inactive mode, to avoid paging when
a host is completely unreachable.
The proposed paging concept introduces explicit and implicit dormancy.
In the explicit dormancy, the MN explicitly sends a message to the
tracking agent (as one of the functions in the PF) to indicate that it
is going to be dormant. In the implicit dormancy, the PF assumes the MN
is dormant after the lack of activity from the MN goes beyond a certain
threshold (e.g. a timer).
8.5. No Routers
Since the basic issues involved in handling mobile routers are not well
understood and since mobile routers have not exhibited a requirement for
paging, the IP paging protocol MAY NOT support routers. However, the IP
paging protocol MAY support a router acting as a Host.
The proposed paging concept does not have mobile routers.
8.6. Multiple Dormant Modes
Recognizing that there are multiple possible dormant modes on the Host,
the IP paging protocol MUST work with different implementations of
dormant mode on the Host.
The solution does not presently describe different dormancy modes
however, using the ability of a MN to provide information to the PF
regarding its requirements for the dormancy either during the paging
Expires 17 March 2002 [Page 20]
Internet Draft Dormant Mode Handover Support 17 September 2001
area update or explicit IP paging registration, such scenarios can be
easily supported.
8.7. Independence of Mobility Protocol
Recognizing that IETF may support multiple mobility protocols in the
future and that paging may be of value to hosts that do not support a
mobility protocol, the IP paging protocol MUST be designed so there is
no dependence on the underlying mobility protocol or on any mobility
protocol at all. The protocol SHOULD specify and provide support for a
mobility protocol, if the Host supports one.
The proposed paging concept does not depend on any existing
mobility protocol to function. On the other hand, it can enhance
existing mobility protocols. For instance, when the MN responds to
a Paging Request message to its AR, it can include Binding Update as
encapsulation in the Paging Response message. The Paging Response
message can also include a request for transfer of network contexts
from the MN's previous AR. Furthermore, our support for securing paging
messages can be used for expedited network access authentication.
8.8. Support for Existing Mobility Protocols
The IP paging protocol MUST specify the binding to the existing IP
mobility protocols, namely mobile IPv4 [2] and mobile IPv6 [3]. The IP
paging protocol SHOULD make use of existing registration support.
The proposed paging concept works with Mobile IP. The PF can be
co-located in any Mobility Agent, including the Foreign Agent. The
Paging Registration message can be constructed as an extension to the
Registration Request or a Binding Update message.
Furthermore, when the PF is realized in a Mobility Agent, the expiration
of lifetime field in the binding cache can serve as a trigger for
determining the implicit dormancy of the MN. For example, when PF is
realized in a GMA, the GMA's regional binding cache can provide the
input for determining the implicit dormancy of the MN.
8.9. Dormant Mode Termination
Upon receipt of a page (either with or without an accompanying L3
packet), the Host MUST execute the steps in its mobility protocol to
re-establish a routable L3 link with the Internet.
When the MN wakes up, either due to entering a new IP-PA, the need to
send IP packets or as a response to a page, the MN executes the steps in
Expires 17 March 2002 [Page 21]
Internet Draft Dormant Mode Handover Support 17 September 2001
the mobility protocol and re-establishese a routable L3 link with the
Internet. For instance, when the MN receives a router advertisement
with paging extension as an L3 Paging Request message, one of the things
the MN does is to formulate a new CoA and it could include the Binding
Update in the Paging Response message as encapsulation.
8.10. Network Updates
Recognizing that locating a dormant mode mobile requires the network to
have a rough idea of where the Host is located, the IP paging protocol
SHOULD provide the network a way for the Paging Agent to inform a
dormant mode Host what paging area it is in and the IP paging protocol
SHOULD provide a means whereby the Host can inform the Target Agent when
it changes paging area. The IP paging protocol MAY additionally provide
a way for the Host to inform the Tracking Agent what paging area it is
in at some indeterminate point prior to entering dormant mode.
The proposed paging concept has the L3 procedure to update the paging
function and all mobility agent 'above' the paging function when the MN
changes the IP-PA.
8.11. Efficient Utilization of L2
Recognizing that many existing wireless link protocols support paging at
L2 and that these protocols are often intimately tied into the Host's
dormant mode support, the IP paging protocol SHOULD provide support to
efficiently utilize an L2 paging protocol if available.
The proposed concept has been developed in order to work with all
the currently known L2 paging mechanisms in the different link layer
technologies. The concept allows access-independent L3 paging and
optimized interworking with L2 paging . As an example, with the
proposed model an IP dormant MN does not need to perform any L2 mobility
signaling when moving within the same IP paging area. The concept
minimizes impact on L2 paging and link layer technologies by allowing
for IP paging signaling and advertisement of IP paging information
through optimizations at L2 Moreover, it provides improvements in terms
of power saving and minimization of mobility signaling with respect to
the presence of L2 paging only.
8.12. Orthogonality of Paging Area and Subnets
The IP paging protocol MUST allow an arbitrary mapping between subnets
and paging areas.
Expires 17 March 2002 [Page 22]
Internet Draft Dormant Mode Handover Support 17 September 2001
The proposed paging concept does not associate the paging area and
subnets. The proposed paging concept allows an IP-PA to have multiple
subnet and each AR is allowed to belong to different types of IP-PA
8.13. Future L3 Paging Support
Recognizing that future dormant mode and wireless link protocols may be
designed that more efficiently utilize IP, the IP paging protocol SHOULD
NOT require L2 support for paging.
The concept does not require L2 support for paging and, thanks to
the introduction of the IP paging Identity allow for future L3 paging
only.
8.14. Robustness Against Failure of Network Elements
The IP paging protocol MUST be designed to be robust with respect to
failure of network elements involved in the protocol. The self- healing
characteristics SHOULD NOT be any worse than existing routing protocols.
The distributed and flexible location of paging function contributes to
the robustness against failure of network elements.
8.15. Reliability of Packet Delivery
The IP paging protocol MUST be designed so that packet delivery is
reliable to a high degree of probability. This does not necessarily
mean that a reliable transport protocol is required.
The paging request will be resent if a response is not received
after PAGE_RESPONSE_RX_TIME expires on the access network. The
re-transmission are performed for at most PAGE_RQST_RE_TX number of
times. When L2 Paging is initiated on the access link as a result of
receiving an IP Paging request, we rely on the underlying L2 protocol to
reliably page the MN.
8.16. Robustness Against Message Loss
The IP paging protocol MUST be designed to be robust with respect to
loss of messages.
Expires 17 March 2002 [Page 23]
Internet Draft Dormant Mode Handover Support 17 September 2001
The paging message will be resent if it is not acknowledged. The
reduction of the number of message during the IP dormant state naturally
reduce the possibility of message lost
8.17. Flexibility of Administration
The IP paging protocol SHOULD provide a way to flexibly auto- configure
Paging Agents to reduce the amount of administration necessary in
maintaining a wireless network with paging.
The proposed paging concept can configure the paging function to
be located in any mobility agent (another access router in the flat
LMM or in any access router, any cross-over router or the GMA in the
hierarchical MIPv6RR). Moreover, dynamic IP Paging Areas are supported,
where the size and scope of the areas can be modified dynamically.
8.18. Flexibility of Paging Area Design
The IP paging protocol MUST be flexible in the support of different
types of paging areas. Examples are fixed paging areas, where a fixed
set of bases stations belong to the paging area for all Hosts, and
customized paging areas, where the set of base stations is customized
for each Host.
The proposed paging concept is flexible enough to accommodate the
concept of hierarchical overlapping paging area and the paging area
with multiple access technologies. Moreover, dynamic IP Paging Areas
are supported, where the size and scope of the areas can be modified
dynamically.
8.19. Availability of Security Support
The IP paging protocol MUST have available authentication and encryption
functionality at least equivalent to that provided by IPSEC.
The proposed IP paging security solutions support authentication and
encryption functionality, equivalent to that provided by IPsec
8.20. Authentication of Paging Location Registration
The IP paging protocol MUST provide mutually authenticated paging
location registration to insulate against replay attacks and to avoid
the danger of malicious nodes registering for paging.
Expires 17 March 2002 [Page 24]
Internet Draft Dormant Mode Handover Support 17 September 2001
The proposed paging concept provides mutual authenticated paging
location registration (both Paging area update and Paging Area Response
are authenticated) with anti replay attacks so the network can make sure
the user is valid and the user can also make sure he is communication
with the valid network
8.21. Authentication of Paging Area Information
The IP paging protocol MUST provide a mechanism for authenticating
paging area information distributed by the Paging Agent.
Authentication of PAU and PAR prevent possible attacks from bogus
paging area information. If the Paging Area information are incorrect,
the PAR will tell the MN. In such case, PAR and PAU may still be sent
unnecessarily over the access link. Authentication of the advertised
paging area information would avoid that but there may be some issues
with anti replay attacks if time stamps are not valid.
8.22. Authentication of Paging Messages
The IP paging protocol MUST provide a mechanism for authenticating
L3 paging messages sent by the Paging Agent to dormant mode Hosts.
The protocol MUST support the use of L2 security mechanisms so
implementations that take advantage of L2 paging can also be secured.
L3 Paging messages sent by the Agent (IP Paging Request, Paging Area
Response, etc.) are authenticated; and if L2 security is present, it
will enhance the security level and make it even more difficult for an
intruder to perform the desired type of attacks
8.23. Paging Volume
The IP paging protocol SHOULD be able to handle large numbers of paging
requests without denying access to any legitimate Host nor degrading its
performance.
The proposed paging concept can handle a large number of paging
request without denying access to any legitimate Host nor degrading its
performance. The limiting factor may be the L2 (wireless link)
Expires 17 March 2002 [Page 25]
Internet Draft Dormant Mode Handover Support 17 September 2001
References
[1] N. Asokan, Patrik Flykt, C. Perkins, and Thomas Eklund. AAA for
ipv6 Network Access (work in progress). Internet Draft, Internet
Engineering Task Force, March 2000.
[2] J. Kempf. Dormant mode host alerting (ip paging) problem
statement. Request for Comments (Informational) 3132, Internet
Engineering Task Force, June 2001.
[3] O. Levkowetz and et al. Problem description: Reasons for doing
context transfers between nodes in an ip access network (work
in progress). Internet Draft, Internet Engineering Task Force,
February 2001.
[4] P. Mutaf, "IP Paging Security Requirements", Internet draft, Internet
Engineering Task Force, May 2001
A. Hierarchical Overlapping Paging Area Support
Functional model for overlapping PAs gives no indication on
implementation or allocation of PFs to any specific node. According to
different implementation options, PFs can be located all in the same
node(i.e. same node acts as PF for more than one PA and more than one
type of PA). No relation between PAs at different levels
Different mobile nodes/users have different traffic patterns and
mobility patterns, e.g., some MNs generate very low traffic and stay
dormant for long time (e.g. basic voice terminals that generate/receive
few calls a day), others are very heavy on traffic (e.g. data MNs may
be always on and receive/send data almost continuously). Based on the
different behaviours, the relation between mobility procedures and IP
Paging is different. For low traffic MN would make sense to use large
IP-PA since, even if the MN moves a lot inside the IP-PA, the traffic
patterns indicates that the MN will have to wake up and perform IP
mobility procedure not very often. Although in this case IP paging will
require multicast of paging messages to a larger area, there is however
a large saving in terms of the IP mobility signalling in the network
and on the radio link otherwise needed to keep track of the MN point of
attachment.
For always-on terminals that are always in an IP session (i.e. they go
dormant very rarely and only for very limited periods of time), it would
make sense to consider small IP-PA or even rely only on L2 paging only
when available. If the MN moves often, IP mobility procedures will be
performed quite often but, when the MN needs to wake-up for incoming
packets, paging has less impact in terms of latency in delivering the
packets and in terms of signalling needed for paging.
This concept allows several types of IP-PA defined in the system,
each type corresponds to a specific set of terminal capabilities/user
Expires 17 March 2002 [Page 26]
Internet Draft Dormant Mode Handover Support 17 September 2001
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | | | | | | | | | | |
| PF1 | | PF4 | | PF2 | | PF6 | | PF5 | | PF3 |
| | | | | | | | | | | |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
\ | | | | /
+-----\--------|----------|-----------------|-----------|--------/---+
| \ \ | IP-PA 1 Type 3 / / |
| +-----\--------\---------\-----+ +-----------------/--------/---+ |
| | \ IP-PA 1 Type 2 \ | | IP-PA 2 Type 2 / | |
| | +-----\-------- ---+ +---\--------------+ +--------------/---+ | |
| | | IP-PA1 Type 1 | | IP-PA 2 Type 1 | | IP-PA 3 Type 1 | | |
| | | +--+ +--+ +--+ | | +--+ +--+ +--+ | | +--+ +--+ +--+ | | |
| | | |AR| |AR| |AR| | | |AR| |AR| |AR| | | |AR| |AR| |AR| | | |
| | | +--+ +--+ +--+ | | +--+ +--+ +--+ | | +--+ +--+ +--+ | | |
| | +------------------+ +------------------+ +------------------+ | |
| +------------------------------+ +------------------------------+ |
+--------------------------------------------------------------------+
|->| |->| |-->
1 1 1
|->| |-->
2 2
|-->
3
1 = MN "care for" PA Type1, perform "PA Update" in this cases
2 = MN "care for" PA Type2, perform "PA Update" in this cases
3 = MN "care for" PA Type3, perform "PA Update" in this case
Figure 8: Hierarchical Overlapping Paging Area
requirements/services being used by the user. For examples, IP-PA type
3 is for MNs with low traffic and long period of dormancy, IP-PA type
1 is for MNs with very brief periods of dormancy and almost continuous
traffic. The choice of the PA Type most appropriate for the MN can be
done in several ways:
The visited domain where the MN is roaming determines it based on the
user profile and terminal capabilities, and indicates it to the MN. In
such case, the MN may be indicated one or more PA types, and decision
of which one to use at a certain point in time is based on MN status:
if MN is inactive (no active sessions at all) MN can choose the PA Type
that minimizes the need for mobility procedures; if MN is in active
sessions for services that require continuous or frequent exchange of
Expires 17 March 2002 [Page 27]
Internet Draft Dormant Mode Handover Support 17 September 2001
data (e.g. real-time multimedia services), MN choose the PA Type that
allows the most precise tracking of the MN. Or the MN itself makes the
selection based on user preferences, user profile, services currently
used, etc. Other cases are possible
Each access router "broadcasts" the IP-PA identifier(s) for the IP-
PA(s) it belongs to. Each Access Router may belong to one or more IP-
PAs, but one AR belongs to only one IP-PA of a specific type. E.g. if
the AR belongs to three IP-PAs, it will broadcast three different IP-PA
identifiers
The IP-PA identifier(s) must be broadcasted by the AR in such a way that
the MNs can easily determine what types of IP-PA are supported and their
identifiers. Several solutions are available. Also IP-PA types need to
be standardized to guarantee inter-operation at roaming. The number of
types of paging areas in a given network can be dynamic, i.e. it does
not need to be mandated by the standards. E.g. this means that, if the
standard defines 10 types of IP-PAs, a given network may adopt only 2
Addresses
Questions about this memo can also be directed to the authors:
Stefano M. Faccin Rajeev Koodli
Mobile Networks Lab Communications Systems Lab
Nokia Research Center Nokia Research Center
6000 Connection Drive 313 Fairchild Drive
Irving, Texas 75039 Mountain View, California 94043
USA USA
Phone: +1 972 894-4994 Phone: +1-650 625-2359
EMail: stefano.faccin@nokia.com EMail: rajeev.koodli@nokia.com
Fax: +1 972 894-4589 Fax: +1 650 625-2502
Franck Le Jari T. Malinen
Mobile Networks Lab Communications Systems Lab
Nokia Research Center Nokia Research Center
6000 Connection Drive 313 Fairchild Drive
Irving, Texas 75039 Mountain View, California 94043
USA USA
Phone: +1 972 374-1256 Phone: +1-650 625-2355
EMail: franck.le@nokia.com EMail: jmalinen@iprg.nokia.com
Fax: +1 972 894-4589 Fax: +1 650 625-2502
Rene Purnadi
Mobile Networks Lab
Nokia Research Center
6000 Connection Drive
Irving, Texas 75039
Expires 17 March 2002 [Page 28]
Internet Draft Dormant Mode Handover Support 17 September 2001
USA
Phone: +1 972 894-4897
EMail: rene.purnadi@nokia.com
Fax: +1 972 894-4589
Expires 17 March 2002 [Page 29]