[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-jang-mipshop-fh80216e) 00 01 02 03 04 05 06 07 RFC 5270

MIPSHOP Working Group                                        Heejin Jang
Internet-Draft                                               Samsung AIT
Intended status: Informational                              Junghoon Jee
Expires: July 6, 2007                                               ETRI
                                                            Youn-Hee Han
                                                                     KUT
                                                     Soohong Daniel Park
                                                     Samsung Electronics
                                                              Jaesun Cha
                                                                    ETRI
                                                         January 2, 2007


         Mobile IPv6 Fast Handovers over IEEE 802.16e Networks
                   draft-ietf-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 July 6, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2007).







Jang, et al.              Expires July 6, 2007                  [Page 1]

Internet-Draft             FMIPv6 over 802.16e              January 2007


Abstract

   This document describes how a Mobile IPv6 Fast Handover could be
   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  . . . . . . . . . . . . . . 12
     7.1.  Predictive Mode  . . . . . . . . . . . . . . . . . . . . . 12
     7.2.  Reactive Mode  . . . . . . . . . . . . . . . . . . . . . . 14
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   9.  Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 17
   10. Normative References . . . . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
   Intellectual Property and Copyright Statements . . . . . . . . . . 20
























Jang, et al.              Expires July 6, 2007                  [Page 2]

Internet-Draft             FMIPv6 over 802.16e              January 2007


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 base station (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 July 6, 2007                  [Page 3]

Internet-Draft             FMIPv6 over 802.16e              January 2007


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document is 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 July 6, 2007                  [Page 4]

Internet-Draft             FMIPv6 over 802.16e              January 2007


         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 and preparation for carrying IP
         packets.

      Link_Switch (LSW)

         A control command come from IP layer to the link layer in a
         mobile node in order to force the mobile node to switch from an
         old BS to a new BS.




































Jang, et al.              Expires July 6, 2007                  [Page 5]

Internet-Draft             FMIPv6 over 802.16e              January 2007


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 (BSs) form a single subnet.  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 IP mobility 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 with integrated BSs &
                                    ARs

   The FMIPv6 is a kind of IP mobility solution, so needs to be



Jang, et al.              Expires July 6, 2007                  [Page 6]

Internet-Draft             FMIPv6 over 802.16e              January 2007


   performed when a mobile node (MN) handovers across the subnet.
   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.  This document describes the case
   when an MN handovers across the subnet.












































Jang, et al.              Expires July 6, 2007                  [Page 7]

Internet-Draft             FMIPv6 over 802.16e              January 2007


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 adjustment and procedural
   flexibility.

   When an MN stays in a link, it listens to L2 neighbor advertisement
   messages, named MOB_NBR-ADV, from its serving BS.  A BS broadcasts
   them periodically to identify the network and announces the
   characteristics of neighbor BSs.  Once receiving this, the mobile
   node decodes this message to find out information about the
   parameters of neighbors for its future handover.  With the provided
   information in MOB_NBR-ADV, 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 procedure is conceptually divided into two
   steps: ``handover preparation'' and ``handover execution'' [8].  The
   handover preparation begins with a decision by 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, the 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 (s-BS).  The serving BS then replies with
   MOB_BSHO-RSP containing the recommended BSs to the MN after
   negotiating with candidates.  When the target is decided, the BS may
   confirm the handover to target BS (t-BS) over backbone.  The BS also
   can trigger handover with MOB_BSHO-REQ message.

   After handover preparation, handover execution starts.  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, then conducting handover.  Once the MN switches
   the link, it shall conduct 802.16e ranging through which it can
   acquire physical parameters from the 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 July 6, 2007                  [Page 8]

Internet-Draft             FMIPv6 over 802.16e              January 2007


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 advertisements.  A BS
   supporting mobile functionality shall broadcast a 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, the 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 methods 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.  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 July 6, 2007                  [Page 9]

Internet-Draft             FMIPv6 over 802.16e              January 2007


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 present their interaction
   by using the primitives.

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.  With the 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 (802.16) 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] tuple(s).
   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.  Note
   that this phase is 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, data packet
   transfer between MN and serving BS is not allowed any more.
   Therefore, if 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.



Jang, et al.              Expires July 6, 2007                 [Page 10]

Internet-Draft             FMIPv6 over 802.16e              January 2007


6.3.  Handover Execution

   When the FBAck message arrives before handover, the MN runs
   predictive mode.  If the MN can not acquire FBAck message on the
   current link, it should run the reactive mode after handover.  Note
   that when MOB_HO-IND is sent prior to the arrival of FBAck, the MN
   should operate as reactive mode since 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 the link layer within MN when FBAck
   message arrives to make the possibility of predictive mode operation
   higher or to promote the issue of MOB_HO-IND message immediately.
   Similar concept has already introduced for the wireless LAN in [5]
   and the IEEE 802.21 document [8] also provides MIH (Media Independent
   Handover) 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 and 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.  On completion of the network entry procedure,
   according to WiMAX model, the initial service flow (ISF) for IPv6 CS
   needs to be established by the network.  ISF is the first flow of the
   pre-provisioned service before carrying the data packets.  For more
   detailed description, refer to [9].  After that, 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, in predictive mode, 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
   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.






Jang, et al.              Expires July 6, 2007                 [Page 11]

Internet-Draft             FMIPv6 over 802.16e              January 2007


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 the 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 a new BS is found through the MOB_NBR-ADV or
              scanning, the 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 receives 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 July 6, 2007                 [Page 12]

Internet-Draft             FMIPv6 over 802.16e              January 2007


           9. The MN conducts handover to the target BS and performs
              802.16e network entry procedure.

           10. As soon as the network entry and ISF setup are 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.

           11. When the NAR receives the FNA from the MN, it delivers
              the buffered packets to the MN.


                                       ----------          ----------
      MN L3   MN L2                   | s-BS PAR |        | NAR t-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 & ISF ------------>|
     connect                            |      |            |      |
        |-------------------------FNA---------------------->|      |
        |<===============================================deliver   |
        |      |                        |      |         packets   |



               Figure 3. Predictive Fast Handover in 802.16








Jang, et al.              Expires July 6, 2007                 [Page 13]

Internet-Draft             FMIPv6 over 802.16e              January 2007


7.2.  Reactive Mode

   The procedure is described as follows in case of reactive mode.


           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 a new BS is found through the MOB_NBR-ADV or
              scanning, the 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 receives 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 and ISF setup are 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 July 6, 2007                 [Page 14]

Internet-Draft             FMIPv6 over 802.16e              January 2007


                                       ----------          ----------
      MN L3   MN L2                   | s-BS PAR |        | NAR t-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 & ISF ------------>|
     connect                            |      |            |      |
        |-------------------------FNA[FBU]----------------->|      |
        |      |                        |      |<---FBU-----|      |
        |      |                        |      |----FBACK-->|      |
        |      |                        |  forward          |      |
        |      |                        |  packets=========>|      |
        |<================================================deliver  |
        |      |                        |      |          packets  |

                Figure 4. Reactive Fast Handover in 802.16




















Jang, et al.              Expires July 6, 2007                 [Page 15]

Internet-Draft             FMIPv6 over 802.16e              January 2007


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 July 6, 2007                 [Page 16]

Internet-Draft             FMIPv6 over 802.16e              January 2007


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.













































Jang, et al.              Expires July 6, 2007                 [Page 17]

Internet-Draft             FMIPv6 over 802.16e              January 2007


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", RFC 4068,
        July 2005.

   [4]  McCann, P., "Mobile IPv6 Fast Handovers for 802.11 Networks",
        RFC 4260, November 2005.

   [5]  Teraoka, F., "Unified L2 Abstractions for L3-Driven Fast
        Handover", draft-irtf-mobopts-l2-abstractions-01 (work in
        progress), September 2006.

   [6]  IEEE 802.16 TGe Working Document, "Amendment 2:
        Physical and Medium Access Control Layers for Combined Fixed and
        Mobile Operation in Licensed Bands and Corrigendum 1",
        IEEE Std 802.16e¢â-2005 and IEEE Std 802.16¢â-2004/Cor 1-2005,
        February 2006.

   [7]  IEEE 802.21 Working Group Document,"Draft IEEE Standard for Local
        and Metropolitan Area Networks: Media Independent Handover
        Services", IEEE P802.21/D03.00, December 2006.

   [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.

   [9]  WiMAX Network Working Group, "End-to-End Network Systems
        Architecture (Stage 3: Detailed Protocols and Procedures)",
        August 2006 release 1 V&V Draft.
















Jang, et al.              Expires July 6, 2007                 [Page 18]

Internet-Draft             FMIPv6 over 802.16e              January 2007


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
   Korea University of Technology and Education

   Email: yh21.han@gmail.com


   Soohong Daniel Park
   Samsung Electronics
   416 Maetan-3dong, Yeongtong-gu
   Suwon 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 July 6, 2007                 [Page 19]

Internet-Draft             FMIPv6 over 802.16e              January 2007


Full Copyright Statement

   Copyright (C) The Internet Society (2007).

   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.

   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.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Jang, et al.              Expires July 6, 2007                 [Page 20]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/