MIPSHOP Working Group                                        Heejin Jang
Internet-Draft                                               Samsung AIT
Expires: January 11, 2006                                   Junghoon Jee
                                                                    ETRI
                                                            Youn-Hee Han
                                                             Samsung AIT
                                                     Soohong Daniel Park
                                                     Samsung Electronics
                                                              Jaesun Cha
                                                                    ETRI
                                                           July 10, 2005


         Mobile IPv6 Fast Handovers over IEEE 802.16e Networks
                   draft-jang-mipshop-fh80216e-00.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 January 11, 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 January 11, 2006                [Page 1]


Internet-Draft             FMIPv6 over 802.16e                 July 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 Mobile IPv6 on IEEE 802.16e . . .  6
   4.  IEEE 802.16e Handovers Overview  . . . . . . . . . . . . . . .  8
   5.  Network Topology Acquisition, Cell Selection, and AR
       Discovery  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  Interaction between FMIPv6 and IEEE 802.16e  . . . . . . . . . 10
     6.1   Handover Preparation . . . . . . . . . . . . . . . . . . . 10
     6.2   Handover Execution . . . . . . . . . . . . . . . . . . . . 10
     6.3   802.16e Network Entry  . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 17
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
       Intellectual Property and Copyright Statements . . . . . . . . 19



























Jang, et al.            Expires January 11, 2006                [Page 2]


Internet-Draft             FMIPv6 over 802.16e                 July 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 January 11, 2006                [Page 3]


Internet-Draft             FMIPv6 over 802.16e                 July 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][8] and the standardization is in progress.  We also referred to
   [5].

      Link_Going_Down (LGD)

         A trigger from the link layer to IP layer in the MN to report
         that a link down event will be fired in the near future.

      Link_Up (LUP)





Jang, et al.            Expires January 11, 2006                [Page 4]


Internet-Draft             FMIPv6 over 802.16e                 July 2005


         A trigger from the link layer to IP layer in the MN to report
         that the MN completes L2 connection establishment with a new
         BS.

      Link_Switch (LSW)

         A control command come from IP layer to the link layer in the
         MN in order to force to switch to new BS.











































Jang, et al.            Expires January 11, 2006                [Page 5]


Internet-Draft             FMIPv6 over 802.16e                 July 2005


3.  Deployment Architectures for Mobile IPv6 on IEEE 802.16e

   In this section, we describe three possible deployment architectures
   of 802.16e network and the mobile node's handover on it.

   Figure 1 and 2 show the deployment with two IP subnets.  In Figure 1,
   an access router (AR) and several base stations (BS) forms a subnet
   and the AR plays a role of a centralized controller for handover.  In
   Figure 2, a subnet consists of three ARs and several BSs.  In this
   case, one or more ARs may serve as a controller for handover.  In
   both cases, the movement among BSs does not always require IP
   mobility.  The handover from BS1 to BS2, or within same subnet, may
   be carried out using link layer mobility without IP mobility.
   However, the handover from BS5 to BS6 may require the change of AR
   since BS5 and BS6 belong to the different subnets.

                  /-------------------------------------\
                 |               IP Backbone             |
                  \-------------------------------------/
                        |                         |
                  /-----------\             /-----------\
                 |     AR1     |           |     AR2     |
                  \-----------/             \-----------/
                  /  /  |  \  \             /  /  |  \  \
                 /  /   |   \  \           /  /   |   \  \
                /   |   |   |   \         /   |   |   |   \
              BS1 BS2  BS3  BS4 BS5     BS6 BS7  BS8  BS9 BS10

                 Figure 1. 802.16e deployment architecture
                          in a centralized manner



             /------------------------------------------------\
            |                    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




Jang, et al.            Expires January 11, 2006                [Page 6]


Internet-Draft             FMIPv6 over 802.16e                 July 2005


   Figure 3 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.
   The handover in this architecture means a change of subnet, resulting
   in IP handovers.

                            /------------------\
                           |     IP Backbone    |
                            \------------------/
                                /     |     \
                               /      |      \
                              /       |       \
                           -----    -----    -----
                          | AR1 |  | AR2 |  | AR3 |
                          | BS1 |  | BS2 |  | BS3 |
                           -----    -----    -----

                Figure 3. 802.16e deployment architecture
                            with the integrated BS & AR
































Jang, et al.            Expires January 11, 2006                [Page 7]


Internet-Draft             FMIPv6 over 802.16e                 July 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 an 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 may
   decode 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'' [9].  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
   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 based on it.  To resume the active session of previous
   link, the MN should perform IP handover additionally.



Jang, et al.            Expires January 11, 2006                [Page 8]


Internet-Draft             FMIPv6 over 802.16e                 July 2005


5.  Network Topology Acquisition, Cell Selection, and AR Discovery

   An MN can learn the network topology and acquire L2 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 by removing the need to monitor
   transmission from the target BS for L2 broadcast.

   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 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.  Once the target is determined, the MN should learn the
   associated AR information, which is the AR discovery.  With BSID in
   MOB_NBR-ADV message, the MN requests the associated AR information to
   the PAR (Previous AR).  The result of resolving BSIDs is a list of
   [BSID, AR-Info] tuples.  AR-Info consists of the corresponding new
   router's information including its prefix, IP address and L2 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.








Jang, et al.            Expires January 11, 2006                [Page 9]


Internet-Draft             FMIPv6 over 802.16e                 July 2005


6.  Interaction between FMIPv6 and IEEE 802.16e

   In this section, we introduce three primitives for the close
   interaction between FMIPv6 and 802.16e, and the interaction is
   presented with it.

6.1  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 sends FBU (Fast Binding Update) to the PAR.  At this time, the
   Link_Going_Down (LGD) is introduced to signal L3 of L2 reception of
   MOB_BSHO-REQ/MOB_BSHO-RSP as soon as possible.  The MN may be
   notified of the target BS at the same time, but how to learn target
   BS is implementation-specific.  On receiving LGD, the MN L3 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 the 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
   possible, the MN should exchange a FBU and FBAck messages with the
   PAR before sending MOB_HO-IND to the serving BS so as to operate as
   predictive mode.

6.2  Handover Execution

   When the FBAck message arrives before the handover, the MN runs as
   predictive mode.  If the MN can not acquire the FBAck message on the
   current link, it should run as reactive mode.  One reason for this is
   that the MN has not sent FBU.  The other is that FBAck is lost during
   the handover.  Both cases means that the current link is not
   available anymore and the 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 Link_Switch trigger (LSW) from IEEE 802.21
   document [8] can be used to optimize the L2/L3 interaction.  The LSW



Jang, et al.            Expires January 11, 2006               [Page 10]


Internet-Draft             FMIPv6 over 802.16e                 July 2005


   trigger can be issued from the MN's L3 to L2 on the reception of
   FBAck message, thereby the MOB_HO-IND is sent immediately.  Similar
   concept has already introduced for the wireless LAN in [5].

6.3  802.16e Network Entry

   After switching the link, 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
   L2 informs its L3 of it with LinkUp (LUP) trigger, forcing L3 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, in predictive mode,
   the NAR starts to flush the buffered packets to the 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.  At this time, if the NAR is co-located with the target BS as
   shown in figure 3, its L3 may notify the reception of FNA to its L2
   (target BS) in order that the target BS can send the backbone message
   to the previously serving 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 January 11, 2006               [Page 11]


Internet-Draft             FMIPv6 over 802.16e                 July 2005


7.  The Examples of Handover Scenario

   In this section, the examples of handover procedure over 802.16e are
   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 new neighbor BSs in this message, it
              may perform scanning for them.

           3. Then the MN may try to resolve new neighbor's BSID to the
              associated AR by exchange of RtSolPr and PrRtAdv with the
              PAR.

           4. The MN may initiate 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.

           5. When the MN receives either MOB_BSHO-RSP or MOB_BSHO-REQ
              from BS, its L2 triggers Link_Going_Down to L3.

           6. On reception of LGD, the MN L3 exchanges FBU and FBAck
              with the PAR. Before sending FBAck, the PAR establishes
              tunnel with the NAR by exchange of HI and HAck messages.
              During this time, the NAR confirms NCoA available in new
              link via HAck.

           7. When the FBAck arrives before the handover, the MN
              operates as predictive mode. It sends MOB_HO-IND
              as a final indication for handovers.

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








Jang, et al.            Expires January 11, 2006               [Page 12]


Internet-Draft             FMIPv6 over 802.16e                 July 2005


           9. When the network entry is completed, the MN L2 signals
              its L3  with Link_Up and then the MN issues FNA to the
              NAR.

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


                                    --------------       --------------
      MN L3    MN L2               |serving BS PAR|     |NAR  target BS|
                                    --------------       --------------
        |      |                        |      |            |      |
        |      |<-----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 4: Predictive Fast Handover in 802.16












Jang, et al.            Expires January 11, 2006               [Page 13]


Internet-Draft             FMIPv6 over 802.16e                 July 2005


7.2  Reactive Mode

   The procedure is described as follows.


           1. A BS broadcasts MOB_NBR-ADV periodically.

           2. If the MN discovers new neighbors BS in this message, it
              may perform scanning for them.

           3. Then the MN may try to resolve BSID to the associated AR
              by exchange of RtSolPr and PrRtAdv with the PAR.

           4. The MN may initiate 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.

           5. When the MN receives either MOB_BSHO-RSP or MOB_BSHO-REQ
              from the BS, its L2 triggers Link_Going_Down to L3,
              thereby sending FBU if possible.

           6. When the MN can not receive FBAck on the current link, it
              runs as reactive mode. After conducting handover to the
              target BS, the MN should perform the 802.16e network entry
              procedure.

           7. As soon as it is completed, the MN L2 signals L3 with
              Link_Up and then the MN issues FNA encapsulating FBU to
              the NAR.

           8. Receiving FNA, the NAR verifies the availability of NCoA
              and forwards the inner FBU to the PAR, establishing the
              tunnel.

           9. 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 to NCoA to the MN.













Jang, et al.            Expires January 11, 2006               [Page 14]


Internet-Draft             FMIPv6 over 802.16e                 July 2005


                                    --------------       --------------
      MN L3    MN L2               |serving BS PAR|     |NAR  target BS|
                                    --------------       --------------
        |      |                        |      |            |      |
        |      |<-----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 5: Reactive Fast Handover in 802.16




















Jang, et al.            Expires January 11, 2006               [Page 15]


Internet-Draft             FMIPv6 over 802.16e                 July 2005


8.  Security Considerations

   The security consideration of the FMIPv6 specification [3] are
   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 January 11, 2006               [Page 16]


Internet-Draft             FMIPv6 over 802.16e                 July 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-02 (work in
        progress), February 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/D8, May 2005.


   [7]  Gupta, V. and D. Johnston, í—IEEE 802.21, A Generalized Model for
        Link Layer Triggersí˜, IEEE 802.21 Media Independent Handoff
        Working Group, Mar. 2004 mtg. mins., http://www.ieee802.org/21/
        march04_meeting_docs/21-04-0027-00-0000-Generalized_triggers.pdf,
        March 2004.

   [8]  Liu, X. and Y.-H. Han, í—Interaction between L2 and Upper Layers
        in IEEE 802.21í˜, IEEE 802.21 Media Independent Handoff Working
        Group, Mar. 2004 mtg. mins., http://www.ieee802.org/21/march04_
        meeting_docs/21-04-0008-00-0000-L2_upper_layer_interaction.ppt,
        March 2004.

   [9]  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 January 11, 2006               [Page 17]


Internet-Draft             FMIPv6 over 802.16e                 July 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 January 11, 2006               [Page 18]


Internet-Draft             FMIPv6 over 802.16e                 July 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 January 11, 2006               [Page 19]