One document matched: draft-jang-mipshop-fh80216e-01.txt
Differences from draft-jang-mipshop-fh80216e-00.txt
MIPSHOP Working Group Heejin Jang
Internet-Draft Samsung AIT
Expires: June 12, 2006 Junghoon Jee
ETRI
Youn-Hee Han
Samsung AIT
Soohong Daniel Park
Samsung Electronics
Jaesun Cha
ETRI
December 12, 2005
Mobile IPv6 Fast Handovers over IEEE 802.16e Networks
draft-jang-mipshop-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 June 12, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes how a Mobile IPv6 Fast Handover could be
Jang, et al. Expires June 12, 2006 [Page 1]
Internet-Draft FMIPv6 over 802.16e December 2005
implemented on link layers conforming to the 802.16e suite of
specifications.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Deployment Architectures for Mobility on IEEE 802.16e . . . . 6
4. IEEE 802.16e Handovers Overview . . . . . . . . . . . . . . . 8
5. Network Topology Acquisition and Cell Selection . . . . . . . 9
6. Interaction between FMIPv6 and IEEE 802.16e . . . . . . . . . 10
6.1. Access Router Discovery . . . . . . . . . . . . . . . . . 10
6.2. Handover Preparation . . . . . . . . . . . . . . . . . . . 10
6.3. Handover Execution . . . . . . . . . . . . . . . . . . . . 11
6.4. Handover Completion . . . . . . . . . . . . . . . . . . . 11
7. The Examples of Handover Scenario . . . . . . . . . . . . . . 13
7.1. Predictive Mode . . . . . . . . . . . . . . . . . . . . . 13
7.2. Reactive Mode . . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 18
10. Normative References . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Jang, et al. Expires June 12, 2006 [Page 2]
Internet-Draft FMIPv6 over 802.16e December 2005
1. Introduction
In order to provide the session continuity during handover, Mobile
IPv6 protocol [2] is currently available. It is capable of handling
IP handovers between different subnets in a transparent way for
higher-level connections. However, the handover latency resulting
from standard Mobile IPv6 is often unacceptable to real-time traffic
such as Voice over IP, and Mobile IPv6 Fast Handover protocol
(FMIPv6) [3] has been proposed as a mechanism to improve the handover
latency by predicting and preparing the impending handover in
advance.
As [4] pointed out, Mobile IPv6 Fast Handover assumes the support
from the link-layer technology, but the particular link-layer
information available, as well as the timing of its availability
(before, during or after a handover has occurred), differs according
to the particular link-layer technology in use.
This document describes Mobile IPv6 Fast Handovers on 802.16
networks. There are three kinds of handover modes, hard handover,
fast BS switching and soft handover in IEEE 802.16e. In this version
of the draft, we consider the hard handover mode because this is the
default mode. We begin with a summary of a handover procedure on
802.16e [6], the amendment of 802.16 for mobility. Then the
interaction between 802.16e and FMIPv6 is presented with the
primitives proposed by IEEE 802.21 for the close interaction between
Layer 2 and Layer 3. Lastly, the examples of handover scenario are
described for both predictive mode and reactive mode.
Jang, et al. Expires June 12, 2006 [Page 3]
Internet-Draft FMIPv6 over 802.16e December 2005
2. Terminology
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 [1].
Most of terms used in this draft are defined in Mobile IPv6 [2] and
FMIPv6 [3].
The following terms come from IEEE 802.16e specification [6].
MOB_NBR-ADV
IEEE 802.16e neighbor advertisement message sent periodically
by a base station.
MOB_MSHO-REQ
IEEE 802.16e handover request message sent by a mobile node.
MOB_BSHO-RSP
IEEE 802.16e handover response message sent by a base station.
MOB_BSHO-REQ
IEEE 802.16e handover request message sent by a base station.
MOB_HO-IND
IEEE 802.16e handover indication message sent by a mobile node.
BSID
IEEE 802.16e base station identifier.
Additionally, the following triggers are proposed by IEEE 802.21
[7] and the standardization is in progress. We also referred to
[5].
New_BS_Found (NBF)
A trigger from the link layer to IP layer in a mobile node to
report that new BS is detected.
Link_Going_Down (LGD)
Jang, et al. Expires June 12, 2006 [Page 4]
Internet-Draft FMIPv6 over 802.16e December 2005
A trigger from the link layer to IP layer in a mobile node to
report that a link down event will be fired in the near future.
Link_Up (LUP)
A trigger from the link layer to IP layer in a mobile node to
report that the mobile node completes L2 connection
establishment with a new BS.
Link_Switch (LSW)
A control command come from IP layer to the link layer in a
mobile node in order to force to switch to new BS.
Jang, et al. Expires June 12, 2006 [Page 5]
Internet-Draft FMIPv6 over 802.16e December 2005
3. Deployment Architectures for Mobility on IEEE 802.16e
In this section, we describe two possible deployment architectures of
802.16 networks and the mobile node's handover over it.
Figure 1 shows the deployment with two IP subnets. An access router
(AR) and several base stations (BS) form single subnet and the AR
plays a role of the centralized controller for handover. In this
case, the movement between BSs does not always require IP mobility.
The handover from BS1 to BS2, or within same subnet, can be carried
out using link layer mobility without IP mobility. However, the
handover from BS5 to BS6 may require the change of AR since they
belong to the different subnets respectively.
/-------------------------------------\
| IP Backbone |
\-------------------------------------/
| |
/-----------\ /-----------\
| AR1 | | AR2 |
\-----------/ \-----------/
/ / | \ \ / / | \ \
/ / | \ \ / / | \ \
/ | | | \ / | | | \
BS1 BS2 BS3 BS4 BS5 BS6 BS7 BS8 BS9 BS10
Figure 1. The 802.16e deployment architecture
in a centralized manner
Figure 2 represents an alternative 802.16e deployment where a subnet
consists of only single AR and single BS. In this case, a BS may be
integrated with an AR, composing one box in view of implementation.
Every handover in this architecture means a change of subnet,
resulting in IP handovers.
/------------------\
| IP Backbone |
\------------------/
/ | \
/ | \
/ | \
----- ----- -----
| AR1 | | AR2 | | AR3 |
| BS1 | | BS2 | | BS3 |
----- ----- -----
Figure 2. The 802.16e deployment architecture
Jang, et al. Expires June 12, 2006 [Page 6]
Internet-Draft FMIPv6 over 802.16e December 2005
with the integrated BS & AR
Therefore, the FMIPv6 does not need to be performed whenever a mobile
node (MN) moves to new link. Regarding its specific operation, the
FBU (Fast Binding Update) message is sent conditionally depending on
whether the target BS is under different subnet or not. The
information may be available to the MN before handover through the
link-layer technology or implementation-specific method. In this
document, the MN is assumed to move to the different subnet.
Jang, et al. Expires June 12, 2006 [Page 7]
Internet-Draft FMIPv6 over 802.16e December 2005
4. IEEE 802.16e Handovers Overview
Compared with the handover in the wireless LAN, the 802.16e handover
mechanism consists of more steps since 802.16e embraces the
functionality for elaborate parameter adjustments and procedural
flexibility.
When a mobile node (MN) stays in a link, it listens to L2 neighbor
advertisement message, named MOB_NBR-ADV, from its serving BS. A BS
broadcasts it periodically to identify the network and announces the
characteristics of neighbor BSs. Once an MN receives this, it
decodes this message to find out information about the parameters of
neighbors for its future handover. With the provided information in
this message, the MN may minimize the handover latency by decoding
the channel number of neighbors and reducing the scanning time, or
may select the target BS tailored for its taste.
In 802.16e, the handover may be initiated by either MN or BS, and
regardless of whoever initiates, the handover procedure is
conceptually divided into two steps: ``handover preparation'' and
``handover execution'' [8]. The handover preparation begins with a
decision of MN or BS. During the handover preparation, neighbors are
compared by the metrics such as signal strength or QoS parameters and
the target BS is selected among them. If necessary, an MN may try to
associate (initial ranging) with candidate BSs to expedite a
potential future handover. Once the MN decides handover, it may
notify its intent by sending MOB_MSHO-REQ message to the serving BS.
The serving BS then replies with MOB_BSHO-RSP containing the
recommended BSs after negotiation with candidates. Also, the BS can
trigger handover with MOB_BSHO-REQ message. In both cases, BS may
confirm the handover to target BS over backbone.
After handover preparation, handover execution occurs. When the MN
sets the target BS finally and is about to move to the link, it sends
MOB_HO-IND to the serving BS as a final indication for handover and
for resource release for it, then conducting handover. Once the MN
switches the link, it shall conduct 802.16e ranging through which it
can acquire physical parameters from target BS, tuning its parameters
to the target BS. After ranging with the target BS successfully, the
MN negotiates basic capabilities and performs authentication, finally
registering with the target BS. If the target BS has already learned
some contexts such as authentication or capability parameters through
backbone, the MN may omit the corresponding procedures. Since this
point, the target BS starts to serve the MN and communication via
target BS is available. However, when the MN moves to different
subnet, it should re-configure new IP address and re-establish IP
connection. To resume the active session of previous link, the MN
should perform IP handover additionally.
Jang, et al. Expires June 12, 2006 [Page 8]
Internet-Draft FMIPv6 over 802.16e December 2005
5. Network Topology Acquisition and Cell Selection
An MN can learn the network topology and acquire the link information
in two ways. One method is via L2 neighbor advertisement. A BS
supporting mobile functionality shall broadcast MOB_NBR-ADV message
including the network topology at a periodic interval (maximum
interval, 1sec.). This message includes the BSID and channel
information of neighbor BSs and is used to facilitate the MN's
synchronization with neighbor BSs. An MN can collect the necessary
information of the neighbor BSs for its future handover through this
message.
Another method for acquisition of network topology is scanning, which
is the process to seek and monitor available BS suitability as
targets for handover. While the MOB_NBR-ADV message includes static
information about neighbor BSs, scanning provides rather dynamic
parameters such as link quality parameters. Since the MOB_NBR-ADV
message delivers a list of neighbor BSIDs periodically and scanning
provides a way to sort out some adequate BSs, it is recommended that
when new BSs are found in the advertisement, an MN identifies them
via scanning and resolves their BSIDs to the associated network
information. The association, optional initial ranging procedure
occurring during scanning, is one of the helpful method to facilitate
the impending handover. An MN is able to get ranging parameters and
service availability information for the purpose of proper selection
of the target BS and expediting a potential future handover to it.
After learning about neighbors, the MN may compare them to find
another BS which can serve better than the serving BS. This is
called Cell selection. The target BS may be determined considering
various criteria such as required QoS, cost, user preference, policy,
etc. How to select the target BS is not in the scope of this draft.
Jang, et al. Expires June 12, 2006 [Page 9]
Internet-Draft FMIPv6 over 802.16e December 2005
6. Interaction between FMIPv6 and IEEE 802.16e
In this section, we describe the desirable FMIPv6 handover procedure
in 802.16 networks. We introduce four primitives for the close
interaction between FMIPv6 and 802.16e, and the interaction is
presented with them.
6.1. Access Router Discovery
Once a new BS is detected through the reception of MOB_NBR-ADV, an MN
tries to learn the associated AR information. This procedure is
called AR discovery. With new BSID in MOB_NBR-ADV message, the MN
requests the associated AR information to the PAR (Previous AR). To
minimize the possible latency from new BS detection in link layer to
the resolution in IP layer (fmip6), the link layer can trigger the
NEW_BS_FOUND primitive to the IP layer within the MN.
The result of resolving BSIDs is a list of [BSID, AR-Info] tuples.
AR-Info consists of the corresponding new AR's information including
its prefix, IP address and link layer address. The RtSolPr (Router
Solicitation for Proxy Advertisement) and PrRtAdv (Proxy Router
Advertisement) messages of FMIPv6 are used for the resolution. If
IEEE 802.16e network is able to provide the MN with AR information,
AR discovery of FMIPv6 may be skipped. Note that network topology
acquisition, cell selection, and AR discovery are not necessarily
involved with any specific handover procedure and the MN may perform
them at any convenient time.
6.2. Handover Preparation
As mentioned in Section 4, an MN may initiate handover by sending
MOB_MSHO-REQ to the serving BS and receive MOB_BSHO-RSP from it.
Also, the BS can initiate handover by sending MOB_BSHO-REQ to the MN.
After receiving either MOB_BSHO-RSP or MOB_BSHO-REQ message, the MN
may send FBU (Fast Binding Update) to the PAR. At this time, the
Link_Going_Down (LGD) is introduced to signal IP layer of the arrival
of MOB_BSHO-REQ/MOB_BSHO-RSP in link layer as soon as possible. The
MN may be notified of the target BS as a parameter at the same time.
On receiving LGD, the MN's IP layer (fmip6) sends FBU to the PAR.
Before sending FBAck (Fast Binding Acknowledgement) to the MN, the
PAR sets up tunnel between PCoA (Previous CoA) and NCoA (New CoA) by
exchange of HI (Handover Initiate) and HAck (Handover Acknowledge)
messages, and forwards the packets destined for MN to NCoA. During
this time, an available NCoA is confirmed with HAck message.
After the MN sends a MOB_HO-IND to the serving BS, any packet data
transfer between MN and serving BS is not allowed even though the
resource retain timer does not expire in serving BS. Therefore, if
Jang, et al. Expires June 12, 2006 [Page 10]
Internet-Draft FMIPv6 over 802.16e December 2005
possible, the MN should exchange a FBU and a FBAck message with the
PAR before sending MOB_HO-IND to the serving BS so as to operate as
predictive mode.
6.3. Handover Execution
When the FBAck message arrives before the handover, the MN runs
predictive mode. If the MN can not acquire FBAck message on the
current link, it should run reactive mode after handover. One reason
for this is that the MN has not sent FBU. The other is that FBAck is
lost during the handover. Both cases mean that the current link is
not available anymore and handover is already in progress. Note that
when MOB_HO-IND is sent prior to the arrival of FBAck, the MN should
operate as reactive mode. In both cases, the MN should conduct the
handover right after sending a MOB_HO-IND to the serving BS. When
the serving BS receives this message, it releases MN's all
connections and resources. The serving BS may retain the resource
until the resource retain timer expires.
If applicable, the primitive from IP layer to link layer can be used
to optimize the L2/L3 interaction. Link_Switch trigger (LSW) can be
issued from the IP layer to link layer within MN when FBAck message
arrives, thereby the MOB_HO-IND is sent immediately. Similar concept
has already introduced for the wireless LAN in [5] and IEEE 802.21
document [8] also provides MIH command service for the same reason.
After switching links, the MN synchronizes with the target BS and
performs the 802.16e network entry procedure. The MN may exchange
the RNG-REQ/RSP, SBC-REQ/RSP, PKM-REQ/RSP, REG-REQ/RSP messages with
the target BS. Some of these messages may be omitted if the
(previously) serving BS transferred the context to the target BS over
the backbone before. As soon as completing the network entry, the
MN's link layer informs its IP layer of the fact with Link_Up (LUP)
trigger, forcing IP layer to send FNA (Fast Neighbor Advertisement)
to the NAR (New AR). In case of reactive mode, the MN should include
the FBU within the FNA message.
6.4. Handover Completion
Receiving the FNA, the NAR should verify the availability of NCoA.
If the NAR detects the NCoA is already in use, it MUST discard the
FBU and reply with Router Advertisement with Neighbor Advertisement
Acknowledge (NAACK) option to the MN. Otherwise, the NAR starts to
flush the buffered packets to MN in predictive mode. In reactive
mode, the NAR should forward the inner FBU to the PAR, establishing
the tunnel, finally forwarding the packets destined to the NCoA to
the MN. At this time, if the NAR is co-located with the target BS as
shown in figure 2, BS's IP layer may notify the reception of FNA to
Jang, et al. Expires June 12, 2006 [Page 11]
Internet-Draft FMIPv6 over 802.16e December 2005
its link layer (target BS) in order that the target BS can send the
backbone message to the previously serving BS (previous BS) for
resource releases. When serving BS receives this, it shall remove
all resources for the MN regardless of expiration of resource retain
timer according to Section 6.3.21 of [6].
Jang, et al. Expires June 12, 2006 [Page 12]
Internet-Draft FMIPv6 over 802.16e December 2005
7. The Examples of Handover Scenario
In this section, the recommended handover procedure over 802.16
network is shown for both predictive mode and reactive mode. Note
that there is no need of IP mobility when the target BS is under same
subnet. Therefore FBU is sent conditionally depending on whether the
target BS is under different subnet or not. In following scenarios,
the MN is assumed to move to different subnet.
7.1. Predictive Mode
The procedure is described briefly as follows.
1. A BS broadcasts MOB_NBR-ADV periodically.
2. If the MN discovers a new neighbor BS in this message, it
may perform scanning for it.
3. When new BS is found through the MOB_NBR-ADV or scanning,
MN's link layer notifies it of the IP layer (fmip6) by
NEW_BS_FOUND primitive.
4. Then the MN may try to resolve new neighbor's BSID to the
associated AR by exchange of RtSolPr and PrRtAdv with the
PAR.
5. The MN initiates handover by sending MOB_MSHO-REQ to the
serving BS and receive MOB_BSHO-RSP from it. Also, the
serving BS can initiate handover by sending MOB_BSHO-REQ
to the MN.
6. When the MN receives either MOB_BSHO-RSP or MOB_BSHO-REQ
from BS, its link layer triggers Link_Going_Down to IP
layer.
7. On reception of LGD, the MN IP layer exchanges FBU and
FBAck with the PAR. Before sending the FBAck, the PAR
establishes tunnel with the NAR by exchange of HI and HAck
messages. During this time, the NAR confirms NCoA
availability in new link via HAck.
8. When the FBAck arrives before handover, the MN
operates as predictive mode. It sends MOB_HO-IND
as a final indication of handovers.
Jang, et al. Expires June 12, 2006 [Page 13]
Internet-Draft FMIPv6 over 802.16e December 2005
9. The MN conducts handover to the target BS and performs
802.16e network entry procedure.
10. When the network entry is completed, the MN link layer
signals its IP layer with Link_Up and then the MN issues
FNA to the NAR.
11. When the NAR receives the FNA from the MN, it delivers
the buffered packets to the MN.
-------------- --------------
MN L3 MN L2 |serving BS PAR| |NAR target BS|
-------------- --------------
| | | | | |
|<-NBF-|<-----MOB_NBR-ADV-------| | | |
| |( Scanning )| | | |
|--------------(RtSolPr)-------------->| | |
|<--------------PrRtAdv----------------| | |
| | | | | |
| | [MN initiation] | | | |
| |------MOB_MNHO-REQ----->| | | |
|<-LGD-|<-----MOB_BSHO-RSP------| | | |
| | or | | | |
| | [BS initiation] | | | |
|<-LGD-|<-----MOB_BSHO-REQ------| | | |
| | | | | |
|------------------FBU---------------->| | |
| | | |-----HI---->| |
| | | |<---HACK----| |
|<-----------------FBACK---------------|--> | |
|(LSW)>|-------MOB_HO-IND------>| forward========>| |
disconnect | packets | |
| connect | | | |
|<-LUP-|<--------------802.16 network reentry------------->|
connect | | | |
|-------------------------FNA---------------------->| |
|<===============================================deliver |
| | | | packets |
Figure 3. Predictive Fast Handover in 802.16
7.2. Reactive Mode
The procedure is described as follows in case of reactive mode.
Jang, et al. Expires June 12, 2006 [Page 14]
Internet-Draft FMIPv6 over 802.16e December 2005
1. A BS broadcasts MOB_NBR-ADV periodically.
2. If the MN discovers a new neighbor BS in this message, it
may perform scanning for it.
3. When new BS is found through the MOB_NBR-ADV or scanning,
MN's link layer notifies it of the IP layer (fmip6) by
NEW_BS_FOUND primitive.
4. Then the MN may try to resolve new neighbor's BSID to the
associated AR by exchange of RtSolPr and PrRtAdv with the
PAR.
5. The MN initiates handover by sending MOB_MSHO-REQ to the
BS and receive MOB_BSHO-RSP from the BS. Also, the BS
can initiate handover by sending MOB_BSHO-REQ to the MN.
6. When the MN receives either MOB_BSHO-RSP or MOB_BSHO-REQ
from the BS, its link layer triggers Link_Going_Down to
IP layer, thereby sending FBU if possible.
7. When the MN can not receive FBAck on the current link, it
runs the reactive mode. After conducting handover to the
target BS, the MN performs the 802.16e network entry
procedure.
8. As soon as the network entry procedure is completed, the
MN's link layer signals its IP layer with Link_Up and then
the MN issues the FNA encapsulating FBU to the NAR.
9. Receiving FNA, the NAR verifies the availability of NCoA
and forwards the inner FBU to the PAR, establishing the
tunnel.
10. If the NAR detects the NCoA is already in use, it MUST
discard the FBU and reply with Router Advertisement with
NAACK option to the MN. Otherwise, it delivers the
packets destined for NCoA to the MN.
Jang, et al. Expires June 12, 2006 [Page 15]
Internet-Draft FMIPv6 over 802.16e December 2005
-------------- --------------
MN L3 MN L2 |serving BS PAR| |NAR target BS|
-------------- --------------
| | | | | |
|<-NBF-|<-----MOB_NBR-ADV-------| | | |
| |( Scanning )| | | |
|--------------(RtSolPr)-------------->| | |
|<--------------PrRtAdv----------------| | |
| | | | | |
| | [MN initiation] | | | |
| |------MOB_MSHO-REQ----->| | | |
|<-LGD-|<-----MOB_BSHO-RSP------| | | |
| | or | | | |
| | [BS initiation] | | | |
|<-LGD-|<-----MOB_BSHO-REQ------| | | |
| | | | | |
|-----------------(FBU)--------------->| | |
| |-------MOB_HO-IND------>| | | |
disconnect| | | | |
| connect | | | |
|<-LUP-|<--------------802.16 network reentry------------->|
connect | | | |
|-------------------------FNA[FBU]----------------->| |
| | | |<---FBU-----| |
| | | |----FBACK-->| |
| | | forward | |
| | | packets=========>| |
|<================================================deliver |
| | | | packets |
Figure 4. Reactive Fast Handover in 802.16
Jang, et al. Expires June 12, 2006 [Page 16]
Internet-Draft FMIPv6 over 802.16e December 2005
8. Security Considerations
The security consideration of the FMIPv6 specification [3] is
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, secure IP address
management between the MN and its network entity. That will allow
secure handover operation between the mobile node and the network
entity.
Further security considerations will be carefully studied along with
this document.
Jang, et al. Expires June 12, 2006 [Page 17]
Internet-Draft FMIPv6 over 802.16e December 2005
9. Acknowledgment
Many thanks IETF Mobility Working Group members of KWISF (Korea
Wireless Internet Standardization Forum) for their efforts on this
work. In addition, we would like to thank Alper E. Yegin, Jinhyeock
Choi and Misun Do who have provided the technical advice.
10. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[3] Koodli, R., "Fast Handovers for Mobile IPv6",
draft-ietf-mipshop-fast-mipv6-03 (work in progress),
October 2004.
[4] McCann, P., "Mobile IPv6 Fast Handovers for 802.11 Networks",
draft-ietf-mipshop-80211fh-04 (work in progress), April 2005.
[5] Mitani, K., "Unified L2 Abstractions for L3-Driven Fast
Handover", draft-koki-mobopts-l2-abstractions-03 (work in
progress), October 2005.
[6] IEEE 802.16 TGe Working Document (Draft Standard), "Amendment
for Physical and Medium Access Control Layers for Combined Fixed
and Mobile Operation in Licensed Bands", 802.16e/D12, October 2005.
[7] IEEE 802.21 Working Group Document (Draft Standard),"Draft IEEE
Standard for Local and Metropolitan Area Networks: Media
Independent Handover Services", IEEE P802.21/D00.03, October 2005.
[8] Kim, K., Kim, C., and T. Kim, "A Seamless Handover Mechanism
for IEEE 802.16e Broadband Wireless Access", International
Conference on Computational Science, vol. 2, pp. 527-534, 2005.
Jang, et al. Expires June 12, 2006 [Page 18]
Internet-Draft FMIPv6 over 802.16e December 2005
Authors' Addresses
Heejin Jang
Samsung Advanced Institute of Technology
P.O. Box 111
Suwon 440-600
KOREA
Email: heejin.jang@samsung.com
Junghoon Jee
Electronics and Telecommunications Research Institute
161 Gajeong-dong, Yuseong-gu
Daejon 305-350
KOREA
Email: jhjee@etri.re.kr
Youn-Hee Han
Samsung Advanced Institute of Technology
P.O. Box 111
Suwon 440-600
KOREA
Email: yh21.han@samsung.com
Soohong Daniel Park
Samsung Electronics
416 Maetan-3dong, Yeongtong-gu
Suwon, Gyeonggi-do 442-742
KOREA
Email: soohong.park@samsung.com
Jaesun Cha
Electronics and Telecommunications Research Institute
161 Gajeong-dong, Yuseong-gu
Daejon 305-350
KOREA
Email: jscha@etri.re.kr
Jang, et al. Expires June 12, 2006 [Page 19]
Internet-Draft FMIPv6 over 802.16e December 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.
Jang, et al. Expires June 12, 2006 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-24 07:58:04 |