[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: January 9, 2008                                            ETRI
                                                            Youn-Hee Han
                                                                     KUT
                                                     Soohong Daniel Park
                                                     Samsung Electronics
                                                              Jaesun Cha
                                                                    ETRI
                                                            July 8, 2007


         Mobile IPv6 Fast Handovers over IEEE 802.16e Networks
                   draft-ietf-mipshop-fh80216e-02.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 9, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).







Jang, et al.             Expires January 9, 2008                [Page 1]

Internet-Draft             FMIPv6 over 802.16e                 July 2007


Abstract

   This document describes how a Mobile IPv6 Fast Handover can be
   implemented on link layers conforming to the 802.16e suite of
   specifications.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  IEEE 802.16e Handovers Overview  . . . . . . . . . . . . . . .  6
   4.  Network Topology Acquisition and Cell Selection  . . . . . . .  8
   5.  Interaction between FMIPv6 and IEEE 802.16e  . . . . . . . . .  9
     5.1.  Access Router Discovery  . . . . . . . . . . . . . . . . .  9
     5.2.  Handover Preparation . . . . . . . . . . . . . . . . . . .  9
     5.3.  Handover Execution . . . . . . . . . . . . . . . . . . . . 10
     5.4.  Handover Completion  . . . . . . . . . . . . . . . . . . . 10
   6.  The Examples of Handover Scenario  . . . . . . . . . . . . . . 11
     6.1.  Predictive Mode  . . . . . . . . . . . . . . . . . . . . . 11
     6.2.  Reactive Mode  . . . . . . . . . . . . . . . . . . . . . . 13
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   8.  Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 16
   9.  Normative References . . . . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 19

























Jang, et al.             Expires January 9, 2008                [Page 2]

Internet-Draft             FMIPv6 over 802.16e                 July 2007


1.  Introduction

   Mobile IPv6 (MIPv6) [RFC3775] is currently available to provide the
   session continuity during handover.  It is capable of handling IP
   handovers between different subnets in a transparent way for higher-
   level connections.  However, the handover latency resulting from
   MIPv6 is often unacceptable to real-time traffic such as Voice over
   IP, and Mobile IPv6 Fast Handover protocol (FMIPv6) [RFC4068] has
   been proposed as a mechanism to reduce the handover latency by
   predicting and preparing the impending handover in advance.

   As [RFC4260] pointed out, FMIPv6 assumes the support from the link-
   layer technology, but the specific link-layer information available,
   as well as the timing of its availability (before, during or after a
   handover occurs), differs according to the particular link-layer
   technology in use.

   This document describes Mobile IPv6 Fast Handovers over 802.16
   networks.  We begin with a summary of a handover procedure of
   [802.16e], 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 [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 9, 2008                [Page 3]

Internet-Draft             FMIPv6 over 802.16e                 July 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].

   Most of terms used in this draft are defined in MIPv6 [RFC3775] and
   FMIPv6 [RFC4068].

   The following terms come from IEEE 802.16e specification [802.16e].

      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 primitives are proposed by [802.21] and
   the standardization is in progress.  We also referred to
   [I-D.irtf-mobopts-l2-abstractions].

      Link_Detected (LD)

         A trigger from the link layer to the IP layer in a mobile node
         to report that a new link is detected.

      Link_Going_Down (LGD)





Jang, et al.             Expires January 9, 2008                [Page 4]

Internet-Draft             FMIPv6 over 802.16e                 July 2007


         A trigger from the link layer to the 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 the IP layer in a mobile node
         to report that the mobile node completes the link layer
         connection establishment with a new BS.

      Handover_Commit (HC)

         A control command from the 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 January 9, 2008                [Page 5]

Internet-Draft             FMIPv6 over 802.16e                 July 2007


3.  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 MN decodes
   this message to find out information about the parameters of neighbor
   BSs for its future handover.  With the provided information in
   MOB_NBR-ADV, the MN may minimize the handover latency by obtaining
   the channel number of neighbors and reducing the scanning time, or
   may select the better target BS based on the signal strength, QoS
   level, service price, etc.

   In 802.16e, the handover procedure is conceptually divided into two
   steps: ``handover preparation'' and ``handover execution''
   [SH802.16e].  The handover preparation can be initiated by either MN
   or BS.  During this period, neighbors are compared by the metrics
   such as signal strength or QoS parameters and a target BS is selected
   among them.  If necessary, the MN may try to associate (initial
   ranging) with candidate BSs to expedite a future handover.  Once the
   MN decides handover, it notifies its intent by sending a MOB_MSHO-REQ
   message to the serving BS.  The BS then replies with a MOB_BSHO-RSP
   containing the recommended BSs to the MN after negotiating with
   candidates.  Optionally it may confirm handover to the target BS over
   backbone when the target is decided.  The BS alternatively may
   trigger handover with a MOB_BSHO-REQ message.

   After handover preparation, handover execution starts.  When the MN
   selects the target BS and is about to move to the new link, it sends
   a MOB_HO-IND to the serving BS as a final indication for handover and
   conducts handover.  Once the MN makes a new attachment, it conducts
   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
   such as maximum transmit power, modulator/demodulator type, etc.  It
   then performs authorization and key exchange procedures, and finally
   registers with the target BS.  If the target BS has already learned
   some contexts such as authentication or capability parameters through
   backbone, it may omit the corresponding procedures.  For the detailed
   procedures of the 802.16 network entry, refer to section 6.3.22 of
   [802.16e].  After completing registration, the target BS starts to
   serve the MN and communication via target BS is available.  However,
   when the MN moves to a different subnet, it should re-configure a new



Jang, et al.             Expires January 9, 2008                [Page 6]

Internet-Draft             FMIPv6 over 802.16e                 July 2007


   IP address and re-establish IP connection.  To resume the active
   session of previous link, the MN should perform IP layer handover
   additionally.
















































Jang, et al.             Expires January 9, 2008                [Page 7]

Internet-Draft             FMIPv6 over 802.16e                 July 2007


4.  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 periodically (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 BSs in order to find
   suitable handover targets.  While a 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
   information of the subnet where the BS is connected.  The
   association, an optional initial ranging procedure occurring during
   scanning, is one of the helpful methods to facilitate the impending
   handover.  The 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.  The
   detailed explanation of association is described in section 6.3.22 of
   [802.16e].

   After learning about neighbors, the MN may compare them to find a BS
   which can serve better than the serving BS.  The target BS may be
   determined by 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 January 9, 2008                [Page 8]

Internet-Draft             FMIPv6 over 802.16e                 July 2007


5.  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 proposed by IEEE
   802.21 WG [802.21] for the close interaction between FMIPv6 and
   802.16e, and present the detailed interaction procedures.

5.1.  Access Router Discovery

   Once a new BS is detected through the reception of a MOB_NBR-ADV and
   scanning, an MN may try to learn the associated AR information as
   soon as possible.  In order to enable quick discovery of the
   associated AR information in the IP layer, the link layer (802.16)
   triggers a Link_Detected primitive to the IP layer (FMIPv6) on
   detecting the new BS.

   Receiving the Link_Detected from the link layer, the IP layer tries
   to learn the associated AR information by exchanging the RtSolPr
   (Router Solicitation for Proxy Advertisement) and PrRtAdv (Proxy
   Router Advertisement) with the PAR.  The result of resolving BSIDs is
   a list of [BSID, AR-Info] tuple(s).  AR-Info consists of AR's prefix,
   IP address and link layer address.

5.2.  Handover Preparation

   As mentioned in section 4, an MN initiates handover by sending a
   MOB_MSHO-REQ to the BS and receives a MOB_BSHO-RSP from the BS as a
   response.  Alternatively, the BS can initiate handover by sending a
   MOB_BSHO-REQ to the MN.  After receiving either MOB_BSHO-RSP or
   MOB_BSHO-REQ message, the MN sends an FBU (Fast Binding Update) to
   the PAR.  At this time, the Link_Going_Down (LGD) is used to signal
   the IP layer of the arrival of MOB_BSHO-REQ/MOB_BSHO-RSP in the link
   layer as soon as possible.  According to 7.3.6 of [802.21], this
   notification is designed to be triggered when the link layer
   connection is expected to go down (Link_Down) within a certain time
   interval, as a consequence, it can be used for making adequate a
   priori preparation to before actual handover

   On receiving LGD, the IP layer sends an FBU to the PAR.  Before
   sending an FBack (Fast Binding Acknowledgement) to the MN, the PAR
   sets up tunnel between PCoA (Previous CoA) and NCoA (New CoA) by
   exchanging HI (Handover Initiate) and HAck (Handover Acknowledge)
   messages with the NAR, and forwards the packets destined for the MN
   to NCoA.  During this time, an available NCoA is confirmed with a
   HAck message.

   After the MN sends a MOB_HO-IND to the serving BS, data packet
   transfer between MN and BS is not allowed any more.  Therefore, if



Jang, et al.             Expires January 9, 2008                [Page 9]

Internet-Draft             FMIPv6 over 802.16e                 July 2007


   possible, the MN should exchange an FBU and an FBack message with the
   PAR before sending a MOB_HO-IND to the BS so as to operate in
   predictive mode.

5.3.  Handover Execution

   When an FBack message arrives before handover, an MN runs in
   predictive mode.  If the MN can not acquire an FBack message on the
   current link, it should run in reactive mode after handover.  Note
   that when a MOB_HO-IND is sent before an FBack arrives, the MN will
   operate in reactive mode because the serving BS releases MN's all
   connections and resources after it receives a MOB_HO-IND The BS may
   retain the resource until the resource retain timer expires.

   When an FBack message arrives, a Handover_Commit (HC) may be issued
   from the IP layer to the link layer so as to promote the issue of
   MOB_HO-IND message immediately.  Until the HC occurs, the link-layer
   may keep the current link and postpone sending a MOB_HO-IND message
   as long as possible to operate in predictive mode.  Similar concept
   has already introduced for the wireless LAN in
   [I-D.irtf-mobopts-l2-abstractions].  An HC is provided by MIH (Media
   Independent Handover) command service of the [802.21].

   After switching links, the MN synchronizes with the target BS and
   performs the 802.16e network entry procedure.  The MN exchanges 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 beforehand.  On completion of the network entry
   procedure, according to WiMAX model, the initial connection between
   the MN and the NAR such as initial service flow (ISF) needs to be
   established by the network.  For more detailed description, refer to
   [WiMAX-NWG].  After that, the 802.16 layer informs the IP layer of
   the fact with a Link_Up (LUP) primitive, forcing the IP layer to send
   an FNA (Fast Neighbor Advertisement) to the NAR.  In case of reactive
   mode, the MN should include an FBU within an FNA message.

5.4.  Handover Completion

   When an MN establishes link connectivity with the NAR, it sends an
   FNA message to the NAR.  When an NCoA in the FNA is acceptable, in
   predictive mode, the NAR stops defending the NCoA and delivers the
   buffered packets to the MN.  In reactive mode, the MN sends the FNA
   containing the FBU.  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 forwards the inner FBU to the PAR, establishes the
   tunnel, and finally delivers packets destined for the NCoA to the MN.



Jang, et al.             Expires January 9, 2008               [Page 10]

Internet-Draft             FMIPv6 over 802.16e                 July 2007


6.  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.  In
   following scenarios, an MN is assumed to move to a different subnet.

6.1.  Predictive Mode

   The procedure is described briefly as follows.

          1. A BS broadcasts a MOB_NBR-ADV periodically.

          2. If an MN discovers a new neighbor BS in this message, it
             may perform scanning for the BS.

          3. When a new BS is found through the MOB_NBR-ADV and
             scanning, the MN's link layer notifies it to the IP layer
             (FMIPv6) by a Link_Detected primitive.

          4. Then the MN tries to resolve the new BS's BSID to the
             associated AR by exchange of RtSolPr and PrRtAdv messages
             with the PAR.

          5. The MN initiates handover by sending a MOB_MSHO-REQ message
             to the BS and receives a MOB_BSHO-RSP from the BS.
             Alternatively, the BS may initiate handover by sending a
             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 a Link_Going_Down
             primitive to the IP layer.

          7. On reception of a Link_Going_Down, the MN's IP layer sends
             an FBU message to the PAR. If the PAR receives this, it
             establishes tunnel with the NAR by exchange of HI and HAck
             messages. During this time, the NAR confirms NCoA
             availability in the new link via HAck.

          8. The MN receives an FBack message before its handover and
             operates in predictive mode after handover. It sends a
             MOB_HO-IND message as a final indication of handovers.
             Issue of a MOB_HO-IND may be promoted by using a
             Handover_Commit command from the IP layer.








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

Internet-Draft             FMIPv6 over 802.16e                 July 2007


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

           10. As soon as the network entry procedure is completed, the
              MN's link layer signals the IP layer with a Link_Up and
              the MN issues an 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                   | s-BS PAR |        | NAR t-BS |
                                       ----------          ----------
        |      |                        |      |            |      |
        |<-LD--|<-----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---------------|-->         |      |
        |(HC)>|--------MOB_HO-IND------>|   forward========>|      |
     disconnect                         |   packets         |      |
        |   connect                     |      |            |      |
        |<-LUP-|<-------------802.16 network entry---------------->|
     connect                            |      |            |      |
        |-------------------------FNA---------------------->|      |
        |<===============================================deliver   |
        |      |                        |      |         packets   |



               Figure 3. Predictive Fast Handover in 802.16








Jang, et al.             Expires January 9, 2008               [Page 12]

Internet-Draft             FMIPv6 over 802.16e                 July 2007


6.2.  Reactive Mode

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

          1.~ 7. The same as the case of predictive Mode.

          8. In case the MN cannot receive an FBack message before its
             handover, it operates in reactive mode after handover.
             It sends a MOB_HO-IND message as a final indication of
             handovers.

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

          10. As soon as the network entry procedure is completed, the
             MN's link layer signals the IP layer with a Link_Up and
             the MN issues an FNA encapsulating an FBU to the NAR.

          11. Receiving the FNA, the NAR verifies the availability of
             NCoA and forwards the inner FBU to the PAR, establishing
             the tunnel. If the NAR detects an 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 January 9, 2008               [Page 13]

Internet-Draft             FMIPv6 over 802.16e                 July 2007


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

                Figure 4. Reactive Fast Handover in 802.16




















Jang, et al.             Expires January 9, 2008               [Page 14]

Internet-Draft             FMIPv6 over 802.16e                 July 2007


7.  Security Considerations

   The security consideration of the FMIPv6 specification [RFC4068] 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 MN and the network entity.











































Jang, et al.             Expires January 9, 2008               [Page 15]

Internet-Draft             FMIPv6 over 802.16e                 July 2007


8.  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, Yoshihiro Ohba and Behcet Sarikaya who have provided the
   technical advice.












































Jang, et al.             Expires January 9, 2008               [Page 16]

Internet-Draft             FMIPv6 over 802.16e                 July 2007


9.  Normative References

   [I-D.irtf-mobopts-l2-abstractions]
              Teraoka, F., "Unified L2 Abstractions for L3-Driven Fast
              Handover", draft-irtf-mobopts-l2-abstractions-03 (work in
              progress), May 2007.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC4068]  Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
              July 2005.

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

   [802.16e]  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.

   [802.21]   IEEE 802.21 Working Group Document,"Draft IEEE Standard
              for Local and Metropolitan Area Networks: Media
              Independent Handover Services", IEEE P802.21/D05.00,
              April 2007.

   [SH802.16e] 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.

   [WiMAX-NWG] WiMAX Network Working Group, "WiMAX Forum Network
              Architecture (Stage 3: Detailed Protocols and Procedures)",
              Release 1.0.0, March 28, 2007.













Jang, et al.             Expires January 9, 2008               [Page 17]

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

Internet-Draft             FMIPv6 over 802.16e                 July 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (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, THE IETF TRUST 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 January 9, 2008               [Page 19]


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