Internet DRAFT - draft-jee-mip4-fh80216e
draft-jee-mip4-fh80216e
Network Working Group J. Jee
Internet-Draft ETRI
Expires: April 14, 2006 R. Koodli
Nokia Research Center
S. Park
Samsung Electronics
J. Cha
ETRI
H. Jang
Samsung AIT
October 11, 2005
Mobile IPv4 Fast Handovers for 802.16e networks
draft-jee-mip4-fh80216e-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 14, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes how a Mobile IPv4 Fast Handover can operate
Jee, et al. Expires April 14, 2006 [Page 1]
Internet-Draft FMIPv4 for IEEE 802.16e networks October 2005
on link layers confirming to the IEEE 802.16e suite of specification.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Deployment Architectures for Mobile IPv4 on 802.16e . . . . . 4
5. 802.16e Handovers in Detail . . . . . . . . . . . . . . . . . 5
6. FMIPv4 Message Exchanges . . . . . . . . . . . . . . . . . . . 7
7. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Scenario 12ab34cdef5678g . . . . . . . . . . . . . . . . . 8
7.2. Scenario 12ab345678cdef . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Jee, et al. Expires April 14, 2006 [Page 2]
Internet-Draft FMIPv4 for IEEE 802.16e networks October 2005
1. Introduction
Mobile IPv4 protocol [RFC3344] is currently available in order to
provide sessions continuity for mobile nodes. Though this Mobile
IPv4 is capable of handling IPv4 handovers between different subnets,
in a transparent way for higher-level connections, it is not adequate
in supporting real time application that requires low latency and
packet loss. Fast Handovers for Mobile IPv4 [I-D.koodli-fmipv4]
provides a mechanism to reduce latency and packet loss resulting from
Mobile IPv4 handover operations to solve the performance problem of
Mobile IPv4 in wireless mobile environments. Fast Handovers for
Mobile IPv4 addresses movement detection, IP address configuration
and location update latencies to meet the real time application
requirements.
This document gives a set of deployment examples for Mobile IPv4 Fast
Handovers on 802.16e networks. As modeled on the [I-D.jang-mipshop-
fh80216e], we begin with a brief overview of relevant aspects of
basic 802.16e. We examine how and when 802.16e's handover related
information might become available to the IP layers that implement
Fast Handover, both in the network infrastructure and on the mobile
node. Finally, we trace the protocol steps for Mobile IPv4 Fast
Handover in this environment.
802.16e standard[IEEE802.16e] is only used in this document as a
reference model since 802.16 standard is for fixed broadband wireless
access systems, but no restriction is made by this document.
2. Terminology
This document borrows all of the terminology from [RFC3344] and
[I-D.koodli-fmipv4], with the following additional terms from the
802.16e specification:
MOB_NBR-ADV : IEEE 802.16e neighbor advertisement message sent
periodically by a BS(Base Station).
MOB_MSHO-REQ : IEEE 802.16e handover initiation request message sent
by a MS(Mobile Station).
MOB_BSHO-RSP : IEEE 802.16e handover initiation response message sent
by a BS.
MOB_BSHO-REQ : IEEE 802.16e handover initiation request message sent
by a BS.
MOB_HO-IND : IEEE 802.16e handover indication message sent by a MS.
Jee, et al. Expires April 14, 2006 [Page 3]
Internet-Draft FMIPv4 for IEEE 802.16e networks October 2005
BSID : IEEE 802.16e BS identifier.
3. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
4. Deployment Architectures for Mobile IPv4 on 802.16e
The relationship between BSs(Base Stations), ARs(Access Routers) and
IP subnets is almost the same as the case of Mobile IPv6 which is
described in [I-D.jang-mipshop-fh80216e] except the existence of
FA(Foreign Agent) which may be co-located with AR. We only provide
figures for convenience.
/-------------------------------------\
| IP Backbone |
\-------------------------------------/
| |
/-----------\ /-----------\
| AR1 | | AR2 |
\-----------/ \-----------/
/ / | \ \ / / | \ \
/ / | \ \ / / | \ \
/ | | | \ / | | | \
BS1 BS2 BS3 BS4 BS5 BS6 BS7 BS8 BS9 BS10
Figure 1: 802.16e deployment architecture in a centralized manner
Jee, et al. Expires April 14, 2006 [Page 4]
Internet-Draft FMIPv4 for IEEE 802.16e networks October 2005
/------------------------------------------------\
| IP Backbone |
\------------------------------------------------/
| | | | | |
AR1 AR2 AR3 AR4 AR5 AR6
\ | / \ | /
\ | / \ | /
BS1 --(Subnet 1)--- BS5 BS6 --(Subnet 2)--- BS10
/ | \ / | \
/ | \ / | \
BS2 BS3 BS4 BS7 BS8 BS9
Figure 2: 802.16e deployment architecture in a distributed manner
/------------------\
| IP Backbone |
\------------------/
/ | \
/ | \
/ | \
----- ----- -----
| AR1 | | AR2 | | AR3 |
| BS1 | | BS2 | | BS3 |
----- ----- -----
Figure 3: 802.16e deployment architecture with integrated BS and AR
5. 802.16e Handovers in Detail
The 802.16e provides three handover modes, hard handover, fast BS
switching and soft handover in IEEE 802.16e []. In this version of
the draft, we first consider the hard handover mode because this is
the default mode in 802.16e.
An 802.16e handover provides the MS initiated handover and network
initiated handover according to which entity initiates the L2
handover in this network. Even though the MS or network entity can
initiate the L2 handover, the MS ultimately decides its target BS
with its own criteria. When MS does not want to choose one of BSs
which are suggested by the serving BS, MS can re-initiate L2 handover
Jee, et al. Expires April 14, 2006 [Page 5]
Internet-Draft FMIPv4 for IEEE 802.16e networks October 2005
from its side.
The L2 handover process in 802.16e networks consist of the following
steps:
1. MS acquires network topology information and channel information
for neighbor BSs by receiving MOB_NBR-ADV message which is
periodically broadcasted by the serving BS.
2. MS may perform scanning/association with the neighbor BSs, and
sends radio measurement reports to the serving BS.
3. 3. MS initiates handoff preparation by sending MOB_MSHO-REQ
message to the serving BS and the BS replies with MOB_BSHO-RSP
message containing the recommended target BSs. In case the serving
BS sends MOB_BSHO-REQ to initiate handoff preparation, the
recommended target BSs are included in MOB_BSHO-REQ message.
4. MS decides the target BS from the suggested BSs in MOB_BSHO-RSP
or MOB_BSHO-REQ by performing the BS decision algorithm.
5. MS sends MOB_HO-IND to the serving BS to commit a L2 handover.
6. MS shall synchronize to downlink transmissions of target BS, and
obtain DL and UL transmission parameters only if it did not receive
MOB-NBR-ADV message from the serving BS.
7. MS shall conduct network re-entry procedure with the target BS.
Network re-entry procedure is the same as the initial network entry
except that it may be shortened by the possession of the MS
information obtained from the serving BS over the backbone network.
8. MS completes the L2 handover by receiving the REG-RSP from the
target BS.
When a MS sends a MOB_HO-IND to the serving BS, any packet data
transfer between the MN and the serving BS is not possible even
though the resource retain timer does not expire in the serving BS.
Therefore, MS SHOULD send a FBU message to the serving BS before
sending the MOB_HO-IND to the serving BS to operate as the predictive
mode.
One possible way to operate as the predictive mode is to use the
association information during the scanning procedure, which
optionally supports the association procedure with neighbor BSs.
This can increase the probability for the FMIPv6 predictive mode can
happen. However, performing the association during the scanning
interval is an optional feature.
Jee, et al. Expires April 14, 2006 [Page 6]
Internet-Draft FMIPv4 for IEEE 802.16e networks October 2005
6. FMIPv4 Message Exchanges
An FMIPv4 handover normally consists of the following messages:
a. MN sends an RtSolPr (Router Solicitation for Proxy) to find out
about neighboring ARs.
b. MN receives a PrRtAdv (Proxy Router Advertisement) containing one
or more [BS-ID, AR-Info] tuples.
c. MN sends a FBU (Fast Binding Update) to PAR (Previous Access
Router).
d. PAR sends a HI (Handover Initiate) to NAR (New Access Router).
e. NAR sends a HAck (Handover Acknowledge) to PAR. The HAck
contains an NCoA that NAR assigns.
f. PAR sends an FBAck (Fast Binding Acknowledgment) to MN.
g. MN (re)sends FBU to NAR after attaching to it.
In case of reactive handover, MN connects to NAR prior to sending FBU
to PAR in the previous link. After step g, NAR forwards FBU to PAR
then steps d, e and f would take place from there.
7. Scenarios
In this section, we look at a few of the possible scenarios for using
FMIPv4 in an 802.16e context. We label each scenario by the sequence
of events that take place, where the numbered events are from Section
5 and the lettered events are from Section 6.
We describe a brief description and discussion of the benefits and
drawbacks for each scenario.
Jee, et al. Expires April 14, 2006 [Page 7]
Internet-Draft FMIPv4 for IEEE 802.16e networks October 2005
7.1. Scenario 12ab34cdef5678g
-------------- --------------
MN L3 MN L2 |serving BS PAR| |NAR target BS|
-------------- --------------
| | | | | |
| |<-----MOB_NBR-ADV-------| | | |
| |( Scanning )| | | |
|--------------(RtSolPr)-------------->| | |
|<--------------PrRtAdv----------------| | |
| | | | | |
| | [MN initiation] | | | |
| |------MOB_MSHO-REQ----->| | | |
| |<-----MOB_BSHO-RSP------| | | |
| | or | | | |
| | [BS initiation] | | | |
| |<-----MOB_BSHO-REQ------| | | |
| | | | | |
|------------------FBU---------------->| | |
| | | |-----HI---->| |
| | | |<---HAck----| |
|<-----------------FBAck---------------|--> | |
| |-------MOB_HO-IND------>| forward========>| |
disconnect | packets | |
| connect | | | |
| |<--------------802.16 network reentry------------->|
connect | | | |
|-------------------------FBU---------------------->| |
|<===============================================deliver |
| | | | packets |
Figure 4: Predictive mode in 802.16e
This scenario is the predictive mode of operation from the FMIPv4
specification. In this scenario, MN's actual L2 handover commitment
of sending MOB_HO-IND SHOULD happen only after sending FBU to PAR as
shown in Figure 4: Predictive mode in 802.16e. This mode of
operation requires that the decision of a target BS and handover
commit operations (steps 4 and 5) happen separately and under MN
control, so that step c can intervene between steps 4 and 5. Steps
d, e, and f may operate after steps 6, 7, and 8. The most important
point to operate as the predictive mode is to send FBU prior to
sending MOB_HO-IND to the serving BS because MS's sending MOB_HO-IND
to the serving BS results in disabling transferring any L3 packet
Jee, et al. Expires April 14, 2006 [Page 8]
Internet-Draft FMIPv4 for IEEE 802.16e networks October 2005
between the MN and PAR.
Steps a and b may happen after steps 3 to acquire fresh triplet
information of NARs. In this case, MN expects to get only the NARs
information that is related with the candidate target BSs.
Step a may be omitted in case where PAR has a capability of actively
sending PrRtAdv with the NARs information related with the suggested
BSs list in MOB_BSHO-RSP or MOB_BSHO-REQ. This case requires the
serving BS to notify the suggested BSs information to the PAR.
7.2. Scenario 12ab345678cdef
-------------- --------------
MN L3 MN L2 |serving BS PAR| |NAR target BS|
-------------- --------------
| | | | | |
| |<-----MOB_NBR-ADV-------| | | |
| |( Scanning )| | | |
|--------------(RtSolPr)-------------->| | |
|<--------------PrRtAdv----------------| | |
| | | | | |
| | [MN initiation] | | | |
| |------MOB_MSHO-REQ----->| | | |
| |<-----MOB_BSHO-RSP------| | | |
| | or | | | |
| | [BS initiation] | | | |
| |<-----MOB_BSHO-REQ------| | | |
| | | | | |
| |-------MOB_HO-IND------>| | | |
disconnect | | | |
| connect | | | |
| |<--------------802.16 network reentry------------->|
connect | | | |
|-------------------------FBU---------------------->| |
| | | |<---FBU-----| |
| | | |----FBAck-->| |
| | | forward | |
| | | packets=========>| |
|<================================================deliver |
| | | | packets |
Figure 5: Reactive mode in 802.16e
This scenario is the reactive mode from the FMIPv4 specification.
Jee, et al. Expires April 14, 2006 [Page 9]
Internet-Draft FMIPv4 for IEEE 802.16e networks October 2005
This scenario does not require MN's intervention between steps 4 and
5 as shown in Figure 5: Reactive mode in 802.16e.
Minimum requirement is to get an NAR's L2 information through steps a
and b from the serving BS. Therefore, steps a and b SHOULD happen
before the step 5.
8. Security Considerations
The security consideration of the Fast Handovers for Mobile IPv4
specification [I-D.koodli-fmipv4] are also applicable to this
document. Particularly, 802.16e architecture supports a number of
mandatory authorization mechanisms, for example, EAP-TTLS, EAP-SIM
and EAP-AKA, as well as, protects IP address management between the
MN and its network entity. That will allow secure handover operation
between the MN and network entity.
We will describe security issues in more detail in the updated
version of this document.
9. Acknowledgment
Authors would like to express special thanks to IETF Mobility Working
Group members of KWISF (Korea Wireless Internet Standardization
Forum) for their efforts on this work.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References
[I-D.ietf-mipshop-80211fh]
McCann, P., "Mobile IPv6 Fast Handovers for 802.11
Networks", draft-ietf-mipshop-80211fh-04 (work in
progress), April 2005.
[I-D.jang-mipshop-fh80216e]
Jang, H., "Mobile IPv6 Fast Handovers over IEEE 802.16e
Networks", draft-jang-mipshop-fh80216e-00 (work in
progress), July 2005.
Jee, et al. Expires April 14, 2006 [Page 10]
Internet-Draft FMIPv4 for IEEE 802.16e networks October 2005
[I-D.koodli-fmipv4]
Koodli, R. and C. Perkins, "Adapting Mobile IPv6 Fast
Handovers for IPv4", draft-koodli-fmipv4-00 (work in
progress), October 2004.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
Jee, et al. Expires April 14, 2006 [Page 11]
Internet-Draft FMIPv4 for IEEE 802.16e networks October 2005
Authors' Addresses
Junghoon Jee
ETRI
161 Gajeong-dong, Yuseong-gu
Daejeon, 305-350
KOREA
Phone: +82-42-860-5126
Email: jhjee@etri.re.kr
Rajeev Koodli
Nokia Research Center
313 Fairchild Drive
Mountain View, CA 94043
USA
Phone: +1 650 625 2359
Email: Rajeev.Koodli@nokia.com
Soohong Daniel Park
Samsung Electronics
416 Maetan-3dong, Yeongtong-gu
Suwon, 442-742
KOREA
Phone: +82-31-200-4508
Email: soohong.park@samsung.com
Jaesun Cha
ETRI
161 Gajeong-dong, Yuseong-gu
Daejeon, 305-350
KOREA
Phone: +82-42-860-5587
Email: jscha@etri.re.kr
Jee, et al. Expires April 14, 2006 [Page 12]
Internet-Draft FMIPv4 for IEEE 802.16e networks October 2005
Heejin Jang
Samsung AIT
P.O. Box 111
Suwon, 440-600
KOREA
Email: heejin.jang@samsung.com
Jee, et al. Expires April 14, 2006 [Page 13]
Internet-Draft FMIPv4 for IEEE 802.16e networks October 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jee, et al. Expires April 14, 2006 [Page 14]
