Network Working Group H. Jang
Request for Comments: 5270 SAMSUNG
Category: Informational J. Jee
ETRI
Y. Han
KUT
S. Park
SAMSUNG Electronics
J. Cha
ETRI
June 2008
Mobile IPv6 Fast Handovers over IEEE 802.16e Networks
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
抽象
This document describes how a Mobile IPv6 Fast Handover can be implemented on link layers conforming to the IEEE 802.16e suite of specifications. The proposed scheme tries to achieve seamless handover by exploiting the link-layer handover indicators and thereby synchronizing the IEEE 802.16e handover procedures with the Mobile IPv6 fast handover procedures efficiently.
この文書では、モバイルIPv6高速ハンドオーバが仕様のIEEE 802.16eのスイートに準拠したリンク層の上に実装する方法について説明します。提案方式は、リンク層ハンドオーバーインジケータを利用することにより、効率的に、モバイルIPv6高速ハンドオーバ手順のIEEE802.16eハンドオーバ手順を同期することによってシームレスなハンドオーバを実現しようとします。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. IEEE 802.16e Handover Overview . . . . . . . . . . . . . . . . 4
4. Network Topology Acquisition and Network Selection . . . . . . 5
5. Interaction between FMIPv6 and IEEE 802.16e . . . . . . . . . 6
5.1. Access Router Discovery . . . . . . . . . . . . . . . . . 6
5.2. Handover Preparation . . . . . . . . . . . . . . . . . . . 7
5.3. Handover Execution . . . . . . . . . . . . . . . . . . . . 8
5.4. Handover Completion . . . . . . . . . . . . . . . . . . . 9
6. The Examples of Handover Scenario . . . . . . . . . . . . . . 10
6.1. Predictive Mode . . . . . . . . . . . . . . . . . . . . . 10
6.2. Reactive Mode . . . . . . . . . . . . . . . . . . . . . . 12
7. IEEE 802.21 Considerations . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Mobile IPv6 Fast Handover protocol (FMIPv6) [RFC5268] was proposed to complement the Mobile IPv6 (MIPv6) [RFC3775] by reducing the handover latency for the real-time traffic. FMIPv6 assumes the support from the link-layer technology; however, the specific link-layer information available and its available timing differs according to the particular link-layer technology in use, as pointed out in [RFC4260], which provides an FMIPv6 solution for the IEEE 802.11 networks. So, this document is proposed to provide an informational guide to the developers about how to optimize the FMIPv6 handover procedures, specifically in the IEEE 802.16e networks [IEEE802.16][IEEE802.16e].
モバイルIPv6高速ハンドオーバプロトコル（FMIPv6と）[RFC5268]は、リアルタイムトラフィックのハンドオーバ待ち時間を低減することによって、モバイルIPv6（MIPv6の）[RFC3775]を補完するために提案されました。 FMIPv6とは、リンク層技術からの支援を想定しています。しかし、特定のリンク層情報が利用可能であり、その利用可能なタイミングと異なるIEEE 802.11ネットワークのFMIPv6とソリューションを提供する[RFC4260]で指摘したように、使用中の特定のリンク層技術に係ります。したがって、この文書は、具体的なIEEE802.16eネットワーク[IEEE802.16] [IEEE802.16e規格]に、FMIPv6とのハンドオーバ手順を最適化する方法について開発者に情報ガイドを提供することが提案されています。
The proposed scheme achieves seamless handover by exploiting the link-layer handover indicators and designing an efficient interleaving scheme of the 802.16e and the FMIPv6 handover procedures. The scheme targets a hard handover, which is the default handover type of IEEE 802.16e. For the other handover types, i.e., the Macro Diversity Handover (MDHO) and Fast Base Station Switching (FBSS), the base stations in the same diversity set are likely to belong to the same subnet for diversity, and FMIPv6 might not be needed. Regarding the MDHO and the FBSS deployment with FMIPv6, further discussion will be needed and is not in the scope of this document.
提案方式は、リンク層ハンドオーバーインジケータを利用するとの802.16eとFMIPv6とのハンドオーバ手順の効率的なインタリーブスキームを設計することにより、シームレスなハンドオーバを実現します。スキームは、IEEE 802.16eのデフォルトのハンドオーバータイプで、ハードハンドオーバを、標的とします。他のハンドオーバータイプ、すなわち、マクロダイバーシチハンドオーバ（MDHO）および高速基地局スイッチング（FBSS）の場合は、同じダイバーシティセット中の基地局は、多様性のために、同じサブネットに属している可能性がある、とFMIPv6とは必要ではない可能性があります。 MDHOとFMIPv6としてFBSSの展開について、さらに議論が必要とされ、この文書の範囲ではありません。
We begin with a summary of handover procedures of [IEEE802.16e] and then present the optimized complete FMIPv6 handover procedures by using the link-layer handover indicators. The examples of handover scenarios are described for both the predictive mode and reactive mode.
我々は[IEEE802.16e規格]のハンドオーバ手順の概要から始まり、その後、リンク層ハンドオーバーインジケータを使用して最適化された完全なFMIPv6とのハンドオーバ手順を提示します。ハンドオーバシナリオの例は、予測モードと反応モードの両方のために記載されています。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "オプション" であります[RFC2119]に記載されているように解釈されます。
Most of terms used in this document are defined in MIPv6 [RFC3775] and FMIPv6 [RFC5268].
このドキュメントで使用される用語のほとんどは、MIPv6の[RFC3775]とFMIPv6の[RFC5268]で定義されています。
The following terms come from the IEEE 802.16e specification [IEEE802.16e].
以下の用語は、IEEE 802.16eの仕様[IEEE802.16e規格]から来ます。
MOB_NBR-ADV
MOB_NBR-ADV
An IEEE 802.16e neighbor advertisement message sent periodically by a base station.
IEEE 802.16eの近隣広告メッセージは、基地局によって定期的に送信されます。
MOB_MSHO-REQ
MOB_MSHO-REQ
An IEEE 802.16e handover request message sent by a mobile node.
モバイルノードによって送信されたIEEE 802.16eのハンドオーバ要求メッセージ。
MOB_BSHO-RSP
MOB_BSHO-RSP
An IEEE 802.16e handover response message sent by a base station.
基地局によって送信されたIEEE 802.16eのハンドオーバ応答メッセージ。
MOB_BSHO-REQ
MOB_BSHO-REQ
An IEEE 802.16e handover request message sent by a base station.
基地局によって送信されたIEEE 802.16eのハンドオーバ要求メッセージ。
MOB_HO-IND
MOB_HO-IND
An IEEE 802.16e handover indication message sent by a mobile node.
モバイルノードによって送信されたIEEE 802.16eのハンドオーバ指示メッセージ。
BSID
BSID
An IEEE 802.16e base station identifier.
IEEE 802.16eの基地局識別子。
Compared with the handover in the WLAN (Wireless Local Area Network), the IEEE 802.16e handover mechanism consists of more steps since the 802.16e embraces the functionality for elaborate parameter adjustment and procedural flexibility.
802.16eのは、精巧なパラメータ調整や手続きの柔軟性のための機能を包含するのでWLAN（無線ローカルエリアネットワーク）におけるハンドオーバと比べて、IEEE 802.16eのハンドオーバ機構は、複数のステップから成ります。
When a mobile node (MN) stays in a link, it listens to the Layer 2 neighbor advertisement messages, named MOB_NBR-ADV, from its serving base station (BS). A BS broadcasts them periodically to identify the network and announce the characteristics of neighbor BSs. 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 a 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, Quality-of-Service (QoS) level, service price, etc.
モバイルノード（MN）は、リンクにとどまるときは、そのサービング基地局（BS）から、MOB_NBR-ADVという名前のレイヤ2ネイバーアドバタイズメントメッセージにリッスンします。 BSは、ネットワークを識別し、隣接BSの特性を発表するために定期的に放送します。これを受けて、MNは、その将来のハンドオーバのための隣接BSのパラメータに関する情報を見つけるために、このメッセージをデコードします。 MOB_NBR-ADVで提供された情報を用いて、MNは、近隣のチャンネル番号を取得し、スキャン時間を低減することによりハンドオーバ待ち時間を最小化することができる、又は信号強度、サービス品質（QoSに基づいて、より良好なターゲット基地局を選択することができます。 ）レベル、サービスの価格、など
The handover procedure is conceptually divided into two steps: "handover preparation" and "handover execution" [SH802.16e]. The handover preparation can be initiated by either an MN or a BS.
「ハンドオーバ準備」および「ハンドオーバ実行」[SH802.16e]：ハンドオーバ手順は、概念的に2つのステップに分割されます。ハンドオーバの準備は、MNまたは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 to handover, it notifies its intent by sending a MOB_MSHO-REQ message to the serving BS (s-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 (t-BS) over backbone when the target is decided. Alternatively, the BS may trigger handover with a MOB_BSHO-REQ message.
この期間中、隣人は、信号強度またはQoSパラメータのような指標によって比較され、ターゲット基地局は、それらの中から選択されます。必要であれば、MNは、将来のハンドオーバーを促進するために候補基地局と（初期レンジング）関連付けることを試みることがあります。 MNがハンドオーバを決定すると、それはサービング基地局（S-BS）へMOB_MSHO-REQメッセージを送信することによって、その意図を通知します。 BSは、MOB_BSHO-RSPは、候補者と交渉した後、MNにお勧めのBSを含むで応答します。ターゲットが決定されたときに必要に応じて、それはバックボーン上のターゲットBS（T-BS）へのハンドオーバを確認することができます。代替的に、BSは、MOB_BSHO-REQメッセージでハンドオーバをトリガすることができます。
After handover preparation, handover execution starts. The MN sends a MOB_HO-IND message to the serving BS as a final indication of its handover. Once it 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 and modulator/demodulator type. It then performs authentication 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 details of the 802.16 handover procedures, refer to Section 6.3.22 of [IEEE802.16e]. After completing registration, the target BS starts
ハンドオーバの準備の後、ハンドオーバの実行を開始します。 MNは、ハンドオーバの最終指示として基地局にMOB_HO-INDメッセージを送信します。それは新しいアタッチメントを作成したら、それはそこを通って、それが、ターゲットBSから物理パラメータを取得することができるターゲットBSにそのパラメータをチューニング範囲の802.16eを行います。正常ターゲットBSとレンジング後、MNは、最大送信電力及び変調器/復調器タイプなどの基本機能を交渉します。次に、認証・鍵交換手順を行い、最終的にターゲットBSに登録します。ターゲットBSが既にバックボーンを通じて、このような認証や能力のパラメータとして、いくつかの状況を学習している場合は、対応する手順を省略することができます。 802.16ハンドオーバ手順の詳細については、[IEEE802.16e規格]のセクション6.3.22を参照してください。登録が完了した後、ターゲットBSが開始されます
to serve the MN and communication via target BS is available. However, in case the MN moves to a different subnet, it should reconfigure a new IP address and reestablish an IP connection. To resume the active session of the previous link, the MN should also perform IP layer handover.
ターゲットBSを介してMNと通信サービスを提供することが可能です。しかし、MNが別のサブネットに移動した場合には、それが新しいIPアドレスを再設定し、IP接続を再確立する必要があります。前のリンクのアクティブなセッションを再開するには、MNは、IP層のハンドオーバーを実行する必要があります。
This section describes how discovery of adjacent networks and selection of target network work in the IEEE 802.16e for background information.
このセクションでは、背景情報のためのIEEE 802.16eの中の隣接するネットワークとターゲットネットワークの仕事の選択の方法を発見を説明しています。
An MN can learn the network topology and acquire the link information in several ways. First of all, it can do that via L2 neighbor advertisements. A BS supporting mobile functionality shall broadcast a MOB_NBR-ADV message periodically that includes the network topology information (its maximum interval is 1 second). This message includes BSIDs and channel information of neighbor BSs, and it is used to facilitate the MN's synchronization with neighbor BSs. An MN can collect the necessary information of the neighbor BSs through this message for its future handover.
MNは、ネットワークトポロジを学び、いくつかの方法でリンク情報を取得することができます。まず第一に、それはL2の近傍通知を経由してそれを行うことができます。 MOB_NBR-ADVメッセージをブロードキャストしなければならないモバイル機能をサポートするBSは、定期的にそのネットワークトポロジー情報を含んでいる（その最大間隔は1秒です）。このメッセージは、隣接BSのチャンネルのBSIDや情報を含み、隣接BSとMNの同期を容易にするために使用されます。 MNは、その将来のハンドオーバのために、このメッセージを介して隣接BSの必要な情報を収集することができます。
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 [IEEE802.16e].
ネットワークトポロジを取得するための別の方法は、適切なハンドオーバターゲットを見つけるために利用可能な基地局を求め、監視する処理である走査です。 MOB_NBR-ADVメッセージは、隣接BSに関する静的な情報を含んでいるが、走査は、リンク品質パラメータとしてではなく動的パラメータを提供します。 MOB_NBR-ADVメッセージは、隣接のBSID定期のリストを提供し、スキャンは、いくつかの十分な基地局を整理する方法を提供しますので、新しい基地局が広告で発見されたときに、MNは、スキャンを経由して、それらを識別し、に自分のBSIDを解決することをお勧めしますBSが接続されたサブネットの情報。アソシエーション、走査中に発生する任意初期レンジング手順は、差し迫ったハンドオーバを容易にするために有用な方法の一つです。 MNは、ターゲットBSの適切な選択の目的のためのパラメータとサービスの可用性情報の範囲とそれに潜在的な将来のハンドオーバを迅速取得することができます。関連の詳細な説明は[IEEE802.16e規格]のセクション6.3.22に記載されています。
Besides the methods provided by 802.16e, the MN may rely on other schemes. For instance, the topology information may be provided through the MIIS (Media Independent Information Service) [IEEE802.21], which has been developed by the IEEE 802.21 working group. The MIIS is a framework by which the MN or network can obtain network information to facilitate network selection and handovers.
802.16eのによって提供される方法に加えて、MNが他の方式に依存することができます。例えば、トポロジー情報は、IEEE 802.21ワーキンググループによって開発されたMIIS（メディア独立情報サービス）[IEEE802.21]を介して提供されてもよいです。 MIISは、MNまたはネットワークがネットワーク選択及びハンドオーバを容易にするために、ネットワーク情報を取得することが可能なフレームワークです。
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, and policy. How to select the target BS is not in the scope of this document.
ネイバーについて学習した後、MNは、サービングBSよりもより良いサービスを提供することができBSを、見つけるためにそれらを比較することができます。ターゲットBSは、要求されるQoS、コスト、ユーザの好み、およびポリシーなどの様々な条件を考慮して決定することができます。ターゲットBSを選択する方法この文書の範囲ではありません。
In this section, a set of primitives is introduced for an efficient interleaving of the IEEE 802.16e and the FMIPv6 procedures as below. The following sections present the handover procedures in detail by using them.
このセクションでは、プリミティブのセットは以下のようにのIEEE802.16eとFMIPv6と手続きの効率的なインタリーブのために導入されます。以下のセクションでは、それらを用いて詳細にハンドオーバ手順を提示します。
o NEW_LINK_DETECTED (NLD)
O NEW_LINK_DETECTED（NLD）
A trigger from the link layer to the IP layer in the MN to report that a new link has been detected.
MNでのIP層へのリンク層からのトリガは、新たなリンクが検出されたことを報告します。
o LINK_HANDOVER_IMPEND (LHI)
O LINK_HANDOVER_IMPEND（LHI）
A trigger from the link layer to the IP layer in the MN to report that a link-layer handover decision has been made and its execution is imminent.
MNでのIP層へのリンク層からのトリガは、リンク層ハンドオーバ決定がなされたことを報告すると、その実行が目前に迫っています。
o LINK_SWITCH (LSW)
O LINK_SWITCH（LSW）
A control command from the IP layer to the link layer in the MN in order to force the MN to switch from an old BS to a new BS.
新しいBSに古いBSから切り替えるようにMNを強制するために、MNにおけるリンク層へのIP層からの制御コマンド。
o LINK_UP (LUP)
（LUP）LINK_UP O
A trigger from the link layer to the IP layer in the MN to report that the MN completes the link-layer connection establishment with a new BS.
MNでのIP層へのリンク層からのトリガは、MNが新しいBSとのリンク層接続確立が完了したことを報告します。
Once a new BS is detected through reception of a MOB_NBR-ADV and scanning, an MN may try to learn the associated access router (AR) information as soon as possible. In order to enable its quick discovery in the IP layer, the link layer (802.16) triggers a NEW_LINK_DETECTED primitive to the IP layer (FMIPv6) on detecting a new BS.
新しいBSがMOB_NBR-ADVとスキャンの受信によって検出されると、MNはできるだけ早く関連したアクセスルータ（AR）情報を学ぶことを試みることがあります。 IP層での迅速な検出を有効にするために、リンク層（802.16）が新BSを検出する上でIP層（FMIPv6と）にNEW_LINK_DETECTEDプリミティブトリガします。
Receiving the NEW_LINK_DETECTED from the link layer, the IP layer tries to learn the associated AR information by exchanging an RtSolPr (Router Solicitation for Proxy Advertisement) and a PrRtAdv (Proxy Router Advertisement) with the PAR (Previous Access Router).
リンク層からNEW_LINK_DETECTEDを受け、IP層はPAR（前のアクセスルータ）とRtSolPrを（プロキシ広告のためのルーター要請）と代理ルータ広告（プロキシルータアドバタイズメント）を交換することにより、関連したAR情報を学ぶためにしようとします。
According to [RFC5268], the MN may send an RtSolPr at any convenient time. However, this proposal recommends that, if feasible, the MN send it as soon as possible after receiving the NEW_LINK_DETECTED for quick router discovery because detection of a new BS usually implies MN's movement, which may result in handover.
[RFC5268]によると、MNは、任意の都合のよい時間にRtSolPrをを送信することができます。しかし、この提案は実現可能な場合には、新たなBSの検出は、通常のハンドオーバーをもたらす可能性がMNの動きを、暗示しているため、MNは、迅速なルータ検出用NEW_LINK_DETECTEDを受けた後、できるだけ早くそれを送る、ことをお勧めします。
Transmission of RtSolPr messages may cause the signaling overhead problem that is mentioned in Section 2 of [RFC4907]. To rate-limit the retransmitted RtSolPr messages, FMIPv6 provides a back-off mechanism. It is also possible that attackers may forge a MOB_NBR-ADV message so that it can contain a bunch of bogus BSIDs or may send a flood of MOB_NBR-ADV messages each of which contains different BSIDs. This problem is mentioned in Section 8.
RtSolPrをメッセージの送信は、[RFC4907]のセクション2に記載されているシグナリングオーバーヘッドの問題を引き起こす可能性があります。再送さRtSolPrをメッセージにレート制限するには、FMIPv6とは、バックオフメカニズムを提供します。偽のBSIDの束を含むことができ、または異なるのBSIDが含まれているそれぞれのMOB_NBR-ADVメッセージの洪水を送信できるように、攻撃者がMOB_NBR-ADVメッセージを偽造することも可能です。この問題は、セクション8に記載されています。
When the MN decides to change links based on its policy such as the degrading signal strength or increasing packet loss rate, it initiates handover by sending a MOB_MSHO-REQ to the BS and will receive a MOB_BSHO-RSP from the BS as a response. Alternatively, the BS may initiate handover by sending a MOB_BSHO-REQ to the MN.
MNは、このような劣化信号強度または増加パケットロス率などの方針に基づいてリンクを変更することを決定する場合には、BSにMOB_MSHO-REQを送信することによってハンドオーバを開始し、応答として基地局からMOB_BSHO-RSPを受信します。代替的に、BSは、MNにMOB_BSHO-REQを送信することによってハンドオーバを開始することができます。
On receiving either a MOB_BSHO-RSP or a MOB_BSHO-REQ, the link layer triggers a LINK_HANDOVER_IMPEND in order to signal the IP layer of arrival of MOB_BSHO-REQ/MOB_BSHO-RSP quickly. At this time, the target BS decided in the link layer is delivered to the IP layer as a parameter of the primitive. The primitive is used to report that a link-layer handover decision has been made and its execution is imminent. It can be helpfully used for FMIPv6 as an indication to start the handover preparation procedure, that is to send an FBU (Fast Binding Update) message to the PAR.
MOB_BSHO-RSP又はMOB_BSHO-REQのいずれかを受信すると、リンク層は急速MOB_BSHO-REQ / MOB_BSHO-RSPの到着のIP層をシグナリングするためにLINK_HANDOVER_IMPENDをトリガします。このとき、ターゲットBSは、プリミティブのパラメータとして、IPレイヤに配信されたリンク層で決めました。プリミティブは、リンク層ハンドオーバ決定がなされたことを報告するために使用され、その実行が目前に迫っています。親切すなわちPARにFBU（高速バインディング更新）メッセージを送信することで、ハンドオーバ準備手続きを開始する指示としてFMIPv6とのために使用することができます。
To avoid erroneous results due to unreliable and inconsistent characteristics of link, for instance, to move to the unpredicted network or to stay in the current network after sending an FBU, Section 2 of [RFC4907] advises the use of a combination of signal strength data with other techniques rather than relying only on signal strength for handover decision. For example, the LINK_HANDOVER_IMPEND may be sent after validating filtered signal strength measurements with other indications of link loss such as lack of beacon reception.
リンクの信頼性が低く、一貫性のない特性に誤った結果を回避するために、例えば、予期せぬネットワークに移動するか、FBUを送信した後、現在のネットワークに滞在する、[RFC4907]のセクション2は、信号強度データの組合せの使用をアドバイス他の技術というより、ハンドオーバ決定のための信号強度にのみ依存します。例えば、LINK_HANDOVER_IMPENDは、ビーコン受信の欠如などのリンク損失の他の適応症でフィルタリングされた信号強度測定値を検証した後に送信されてもよいです。
Once the IP layer receives the LINK_HANDOVER_IMPEND, it checks whether or not the specified target network belongs to a different subnet based on the information collected during the Access Router Discovery step. If the target proves to be in the same subnet, the MN can continue to use the current IP address after handover, and there is no need to perform FMIPv6. Otherwise, the IP layer formulates a prospective NCoA (New Care-of Address) with the information provided in the PrRtAdv message and sends an FBU message to the PAR.
IP層はLINK_HANDOVER_IMPENDを受信すると、指定されたターゲット・ネットワークがアクセスルータ発見ステップの間に収集された情報に基づいて、異なるサブネットに属するか否かをチェックします。ターゲットは、同じサブネット内にあることが判明した場合、MNは、ハンドオーバ後に、現在のIPアドレスを使用し続けることができ、かつFMIPv6とを実行する必要はありません。そうでない場合は、IP層は、代理ルータ広告メッセージで提供される情報と将来のNCOA（新気付アドレス）を策定し、PARにFBUメッセージを送信します。
When the FBU message arrives in the PAR successfully, the PAR and the NAR (New Access Router) process it according to [RFC5268]. The PAR sets up a tunnel between the PCoA (Previous Care-of Address) and NCoA by exchanging HI (Handover Initiate) and HAck (Handover Acknowledge) messages with the NAR, forwarding the packets destined for the MN to the NCoA. The NCoA is confirmed or re-assigned by the NAR in the HAck and, finally delivered to the MN through the FBack (Fast Binding Acknowledgment) in case of predictive mode.
FBUメッセージが正常にPARに到着すると、PARとNAR（新アクセスルータ）は、[RFC5268]に従ってそれを処理します。 PARはNCOAにMN宛のパケットを転送HI交換（ハンドオーバ開始）および上記ハンドオフ（ハンドオーバ肯定応答）NARとのメッセージによってPCOA（旧気付アドレス）とNCOA間にトンネルを設定します。 NCOAは、予測モードの場合に確認されるか、NARによって割り当てられた再上記ハンドオフおよび、最後にFBACK（ファストバインディング肯定応答）を介してMNに配信します。
After the MN sends a MOB_HO-IND to the serving BS, data packet transfer between the MN and the BS is no longer allowed. Note that when a MOB_HO-IND is sent out before an FBack arrives in the MN, it is highly probable that the MN will operate in reactive mode because the serving BS releases all the MN's connections and resources after receiving a MOB_HO-IND. Therefore, if possible, the MN should exchange FBU and FBack messages with the PAR before sending a MOB_HO-IND to the BS so as to operate in predictive mode.
MNは、サービング基地局にMOB_HO-INDを送信した後、MNとBSとの間のデータパケットの転送は、もはや許されません。 MOB_HO-INDがFBACKがMNに到着する前に、送信されたとき、サービングBSは、MOB_HO-INDを受け取った後、すべてのMNの接続およびリソースを解放するため、MNは、反応性モードで動作する可能性が高いことに注意してください。可能であればそのため、MNは、予測モードで動作するように基地局にMOB_HO-INDを送信する前に、PARとFBUとFBACKメッセージを交換すべきです。
If the MN receives an FBack message on the previous link, it runs in predictive mode after handover. Otherwise, it should run in reactive mode. In order for the MN to operate in predictive mode as far as possible after handover, implementations may allow use of a LINK_SWITCH primitive. The LINK_SWITCH is a command in order to force the MN to switch from an old BS to a new BS and the similar concept has introduced for the wireless LAN in [RFC5184]. When it is applied, the MN's IP layer issues a LINK_SWITCH primitive to the link layer on receiving the FBack message in the previous link. Until it occurs, the link layer keeps the current (previous) link if feasible and postpones sending a MOB_HO-IND message while waiting for the FBack message.
MNは、前のリンクにFBACKメッセージを受信した場合、それはハンドオーバ後の予測モードで実行されます。それ以外の場合は、反応モードで実行する必要があります。 MNがハンドオーバ後に可能な限り予測モードで動作するために、実装は、プリミティブLINK_SWITCHの使用を可能にすることができます。 LINK_SWITCHは、無線LAN [RFC5184]のために導入された新BSと似た概念に、古いBSから切り替えるようにMNを強制するために、コマンドです。それが適用されると、MNのIP層は、前のリンクでFBACKメッセージを受信すると、リンク層への原始LINK_SWITCHを発行します。それが発生するまで、リンク層は、実現可能な場合には、現在の（前の）リンクを保持し、FBACKメッセージを待っている間にMOB_HO-INDメッセージを送信延期します。
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. When the network entry procedure is completed and the link layer is ready for data transmission, it informs the IP layer of the fact with a LINK_UP primitive.
リンクを切り替えた後、MNは、ターゲットBSと同期との802.16eネットワークエントリ手順を行います。 MN交換RNG-REQ / RSP、SBC-REQ / RSP、PKM-REQ / RSP、ターゲットBSとREG-REQ / RSPメッセージ。 （以前に）サービングBSは、予めバックボーン上のターゲットBSにコンテキストを転送した場合、これらのメッセージの一部を省略してもよいです。ネットワークエントリ手順が完了し、リンク層は、データ伝送のための準備ができているとき、それは原始的LINK_UPと実際のIP層に通知します。
Section 2 of [RFC4907] recommends that link indications should be designed with built-in damping. The LINK_UP primitive defined in this document is generated by the link layer state machine based on the 802.16e link layer message exchanges, that is, the IEEE 802.16e network entry and the service flow creation procedures. Therefore, the LINK_UP is typically less sensitive to changes in transient link conditions. The link may experience an intermittent loss. Even in such a case, the following FMIPv6 operation is performed only when the MN handovers to the link with a different subnet and there is no signaling overhead as a result of a intermittent loss.
[RFC4907]のセクション2は、リンク適応内蔵減衰を有するように設計されなければならないことをお勧めします。この文書で定義されたプリミティブLINK_UPが802.16eのリンク層メッセージ交換に基づいて、リンク層の状態マシンによって生成される、すなわち、IEEE 802.16eのネットワークエントリ及びサービスフローの作成手順。したがって、LINK_UPは、一般的に、過渡リンク条件の変化に鈍感です。リンクは断続的な損失が発生することがあります。このような場合であっても、次のFMIPv6と動作が異なるサブネットにリンクする場合にのみ、MNのハンドオーバを行い、間欠損失の結果として何のシグナリングオーバーヘッドは存在しません。
When the MN's IP layer receives a LINK_UP primitive from the link layer, it should check whether it has moved into the target network predicted by FMIPv6. In case the target BS is within the same subnet, the MN does not perform the FMIPv6 operation.
MNのIP層は、リンク層からプリミティブLINK_UPを受信すると、それはFMIPv6とによって予測されたターゲットネットワークに移動したかどうかを確認する必要があります。ターゲットBSが同じサブネット内にある場合には、MNは、FMIPv6と動作を行いません。
* If the MN discovers itself in the predicted target network and receives an FBack message in the previous link, the MN's IP layer sends an UNA (Unsolicited Neighbor Advertisement) to the NAR (predictive mode).
* MNが予測されたターゲットネットワークに自分自身を発見し、前のリンクでFBACKメッセージを受信した場合、MNのIP層はNARにUNA（迷惑近隣広告）（予測モード）を送信します。
* If the MN has moved to the target network without receiving an FBack message in the previous link, the IP layer sends an UNA and also an FBU message immediately after sending the UNA message (reactive mode). The NAR may provide a different IP address by using an RA (Router Advertisement) with a NAACK (Neighbor Advertisement Acknowledge) option other than the formulated NCoA by the MN.
* MNは、前のリンクでFBACKメッセージを受信することなく、ターゲットネットワークに移動した場合は、IP層は、直ちにUNAメッセージ（アクティブモード）を送信した後も、UNAとFBUメッセージを送信します。 NARは（肯定応答近隣広告）MNによって処方NCOA以外のオプションをNAACKとRA（ルータ広告）を使用して、異なるIPアドレスを提供してもよいです。
* The MN may discover itself in the unpredicted network (erroneous movement). If this is the case, the MN moves to the network that is not the target specified in the LINK_HANDOVER_IMPEND primitive. For the recovery from such an invalid indication, which is mentioned in Section 2 of [RFC4907], the MN should send a new FBU to the PAR according to Section 5.6 of [RFC5268] so that the PAR can update the existing binding entry and redirect the packets to the new confirmed location.
* MNは、予期せぬネットワーク（誤った動き）に自分自身を発見することができます。この場合、MNは、プリミティブLINK_HANDOVER_IMPENDで指定されたターゲットではないネットワークに移動します。 [RFC4907]のセクション2に記載されている無効な指示、から回復するために、MNがPARは、既存のバインディングエントリを更新し、リダイレクトすることができるように、[RFC5268]のセクション5.6に従ってPARに新しいFBUを送るべき新しい確認された場所へのパケット。
In both cases of predictive and reactive modes, once the MN has moved into the new link, it uses the NCoA formulated by the MN as a source address of the UNA, irrespective of NCoA availability. It then starts a Duplicate Address Detection (DAD) probe for NCoA according to [RFC4862]. In case the NAR provides the MN with a new NCoA, the MN MUST use the provided NCoA instead of the NCoA formulated by the MN.
予測および反応性モードの両方の場合において、MNは、新しいリンクに移動した後、それに関係なくNCOAの可用性、UNAのソースアドレスとしてMNによって処方NCOAを使用します。次に、[RFC4862]に記載NCOAための重複アドレス検出（DAD）プローブを開始します。場合NAR新しいNCOAとMNを提供し、MNは、MNによって処方NCOAの代わりに設けNCOAを使用しなければなりません。
When the NAR receives an UNA message, it deletes its proxy neighbor cache entry if it exists, and forwards buffered packets to the MN after updating the neighbor cache properly. Detailed UNA processing rules are specified in Section 6.4 of [RFC5268].
NARはUNAメッセージを受信すると、それが存在する場合、そのプロキシ近隣キャッシュエントリを削除し、転送し、適切近隣キャッシュを更新した後、MNにパケットをバッファリング。詳細UNA処理ルールは、[RFC5268]のセクション6.4で指定されています。
In this section, the recommended handover procedures over 802.16e network are shown for both predictive and reactive modes. It is assumed that the MN handovers to the network that belongs to a different subnet.
このセクションでは、802.16eのネットワークを介して推奨ハンドオーバ手順は、予測および反応性モードの両方のために示されています。これは、異なるサブネットに属しているネットワークにMNのハンドオーバするものとします。
In the following figures, the messages between the MN's Layer 2 (MN L2) and the BS are the IEEE 802.16 messages, while messages between the MN's Layer 3 (MN L3) and the PAR and messages between PAR and NAR are the FMIPv6 messages. The messages between the MN L2 and the MN L3 are primitives introduced in this document.
PARとNARとの間のMNのレイヤ3（L3 MN）とPARとメッセージ間のメッセージは、FMIPv6とのメッセージであるが、以下の図において、MNのレイヤ2（L2 MN）とBS間のメッセージは、IEEE 802.16メッセージです。 MN L2とL3 MN間のメッセージは、この文書に導入プリミティブです。
The handover procedures in the predictive mode are briefly described as follows. Figure 3 illustrates these procedures.
次のように予測モードのハンドオーバ手順を簡単に説明します。図3は、これらの手順を示しています。
2. If the MN discovers a new neighbor BS in this message, it may perform scanning for the BS.
2. MNはこのメッセージに新しいネイバーBSを発見した場合、それは、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 by a NEW_LINK_DETECTED primitive.
新しいBSがMOB_NBR-ADVおよび走査により発見された場合3.、MNのリンク層は、プリミティブNEW_LINK_DETECTEDによってIP層に通知します。
4. The MN tries to resolve the new BS's BSID to the associated AR by exchange of RtSolPr and PrRtAdv messages with the PAR.
4. MNはPARとRtSolPrをと代理ルータ広告メッセージの交換によって、関連するARに新しいBSのBSIDを解決しようとします。
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.
前記MNは、BSへMOB_MSHO-REQメッセージを送信することによってハンドオーバを開始し、基地局からMOB_BSHO-RSPを受信します。代替的に、BSは、MNにMOB_BSHO-REQを送信することによってハンドオーバを開始することができます。
6. When the MN receives either a MOB_BSHO-RSP or a MOB_BSHO-REQ from the BS, its link layer triggers a LINK_HANDOVER_IMPEND primitive to the IP layer.
MNは、基地局からMOB_BSHO-RSP又はMOB_BSHO-REQのいずれかを受信すると、そのリンク層は、IP層にプリミティブLINK_HANDOVER_IMPENDをトリガ6。
7. On reception of the LINK_HANDOVER_IMPEND, the MN's IP layer identifies that the target delivered along with the LINK_HANDOVER_IMPEND belongs to a different subnet and sends an FBU message to the PAR. On receiving this message, the PAR establishes tunnel between the PCoA and the NCoA by exchange of HI and HAck messages with the NAR, and it forwards packets destined for the MN to the NCoA. During this time, the NAR may confirm NCoA availability in the new link via HAck.
LINK_HANDOVER_IMPENDの受信7.、MNのIP層はLINK_HANDOVER_IMPENDと共に配信対象が異なるサブネットに属し、PARにFBUメッセージを送信することを識別する。このメッセージを受信すると、PARはNARとHI及びHAck処理メッセージの交換によってPCOAとNCOA間にトンネルを確立し、それはNCOAにMN宛てのパケットを転送します。この間、NARハックを介した新しいリンクでNCOAの可用性を確認することができます。
8. The MN receives the FBack message before its handover and sends a MOB_HO-IND message as a final indication of handover. Issue of a MOB_HO-IND may be promoted optionally by using a LINK_SWITCH command from the IP layer. Afterwards it operates in predictive mode in the new link.
8. MNは、ハンドオーバ前FBACKメッセージを受信し、ハンドオーバの最終的な指標としてMOB_HO-INDメッセージを送信します。 MOB_HO-INDの問題は、IPレイヤからLINK_SWITCHコマンドを使用して、任意に促進することができます。その後、それは新しいリンクでの予測モードで動作します。
9. The MN conducts handover to the target BS and performs the IEEE 802.16e network entry procedure.
9. MNは、ターゲット基地局へのハンドオーバを行い、IEEE 802.16eのネットワークエントリ手順を行います。
10. As soon as the network entry procedure is completed, the MN's link layer signals the IP layer with a LINK_UP. On receiving this, the IP layer identifies that it has moved to a predicted target network and received the FBack message in the previous link. It issues an UNA to the NAR by using the NCoA as a source IP address. At the same time, it starts to perform DAD for the NCoA.
10.とすぐにネットワークエントリ手順が完了すると、MNのリンク層はLINK_UPとIPレイヤを知らせます。これを受けて、IPレイヤは、それが予測されたターゲットネットワークに移動し、前のリンクにFBACKメッセージを受信したことを識別する。これは、送信元IPアドレスとしてNCOAを使用することによってNARにUNAを発行します。同時に、それはNCOAのためDADを実行するために開始します。
11. When the NAR receives the UNA from the MN, it delivers the buffered packets to the MN.
NARは、MNからUNAを受信すると11は、それがMNにバッファリングされたパケットを配信します。
(MN L3 MN L2) s-BS PAR t-BS NAR
| | | | | |
1-2. | |<---MOB_NBR-ADV --------| | | |
| |<-------Scanning------->| | | |
3. |<-NLD-| | | | |
4. |--------------(RtSolPr)-------------->| | |
|<--------------PrRtAdv----------------| | |
| | | | | |
5. | |------MOB_MSHO-REQ----->| | | |
| |<-----MOB_BSHO-RSP------| | | |
| | or | | | |
| |<-----MOB_BSHO-REQ------| | | |
6. |<-LHI-| | | | |
7. |------------------FBU---------------->| | |
| | | |--------HI-------->|
| | | |<------HACK--------|
|<-----------------FBack---------------|--> | |
| | | Packets==============>|
8. |(LSW)>|-------MOB_HO-IND------>| | | |
disconnect| | | | |
connect | | | | |
9. | |<---------IEEE 802.16 network entry-------->| |
10. |<-LUP-| | | | |
|----------------------------UNA-------------------------->|
11. |<==================================================== Packets
| | | | |
Figure 3. Predictive Fast Handover in 802.16e
802.16eの図3.予測の高速ハンドオーバー
The handover procedures in the reactive mode are described as follows. Figure 4 is illustrating these procedures.
次のように反応モードにおけるハンドオーバ手順が記載されています。図4は、これらの手順を示しています。
8. The MN does not receive the FBack message before handover and sends a MOB_HO-IND message as a final indication of handover. Afterwards, it operates in reactive mode in the new link.
8. MNはハンドオーバ前に戻るメッセージを受信して、ハンドオーバの最終的な指標としてMOB HO-ANDメッセージを送信しません。その後、それは新しいリンクに反応モードで動作します。
9. The MN conducts handover to the target network and performs the 802.16e network entry procedure.
9. MNは、ターゲットネットワークへのハンドオーバを行い、802.16eのネットワークエントリ手順を行います。
10. As soon as the network entry procedure is completed, the MN's link layer signals the IP layer with a LINK_UP. On receiving this, the IP layer identifies that it has moved to the predicted target network without receiving the FBack in the previous link. The MN issues an UNA to the NAR by using NCoA as a source IP address and starts to perform DAD for the NCoA. Additionally, it sends an FBU to the PAR in the reactive mode.
10.とすぐにネットワークエントリ手順が完了すると、MNのリンク層はLINK_UPとIPレイヤを知らせます。これを受けて、IP層は、それが前のリンクでFBACKを受けることなく、予測されたターゲットネットワークに移動したことを識別します。 MNは、送信元IPアドレスとしてNCOAを使用することによってNARにUNAを発行し、NCOAのためDADを実行するために開始します。さらに、それは反応モードでPARにFBUを送信します。
11. When the NAR receives the UNA and the FBU from the MN, it forwards the FBack to the PAR. The FBack and Packets are forwarded from the PAR and delivered to the MN (NCoA) through the NAR. The NAR may supply a different IP address than the NCoA by sending an RA with a NAACK option to the MN.
NARは、MNからUNAおよびFBUを受信すると、PARにFBACKを転送する11。 FBACKパケットがPARから転送とNARを介してMN（NCOA）に配信されます。 NARは、MNにNAACKオプションでRAを送信することにより、NCOAとは異なるIPアドレスを供給することができます。
(MN L3 MN L2) s-BS PAR t-BS NAR
| | | | | |
1-2. | |<---MOB_NBR-ADV & Scan--| | | |
| |<-------Scanning------->| | | |
3. |<-NLD-| | | | |
4. |--------------(RtSolPr)-------------->| | |
|<--------------PrRtAdv----------------| | |
| | | | | |
5. | |------MOB_MSHO-REQ----->| | | |
| |<-----MOB_BSHO-RSP------| | | |
| | or | | | |
| |<-----MOB_BSHO-REQ------| | | |
6. |<-LHI-| | | | |
7. |--------FBU----X---> | | | |
8. | |-------MOB_HO-IND------>| | | |
disconnect| | | | |
connect | | | | |
9. | |<---------IEEE 802.16 network entry-------->| |
10. |<-LUP-| | | | |
|----------------------------UNA-------------------------->|
|----------------------------FBU--------------------------)|
11. | | | |<-------FBU-------)|
| | | |<-----HI/HAck----->|
| | | | (if necessary) |
| | | Packets & FBack=========>|
|<=========================================================|
| | | | | |
Figure 4. Reactive Fast Handover in 802.16e
802.16eの図4.反応性高速ハンドオーバ
It is worth noting that great research has been conducted on defining generic services in the IEEE 802.21 working group that facilitate handovers between heterogeneous access links. The standard works are named as a Media Independent Handover (MIH) Service [IEEE802.21], and propose three kinds of services: Media Independent Event Service (MIES), Media Independent Command Service (MICS), and Media Independent Information Service (MIIS).
偉大な研究は、異種アクセスリンク間のハンドオーバーを促進するIEEE 802.21ワーキンググループでの一般的なサービスの定義に行われていることは注目に値します。 MIIS（メディア独立イベントサービス（MIES）、メディア独立コマンドサービス（MICS）、およびメディア独立情報サービス：標準の作品はメディア独立ハンドオーバ（MIH）サービス[IEEE802.21]という名前、およびサービスの3種類を提案しています）。
An MIES defines the events triggered from lower layers (physical and link) to higher layers (network and above) in order to report changes of physical and link-layer conditions. On the other hand, an MICS supports the commands sent from higher layers to lower layers, and it provides users with a way of managing the link behavior relevant to handovers and mobility. An MIIS provides a framework by which the MN or network can obtain network information to facilitate network selection and handovers.
MIESは、物理およびリンク層の状態の変化を報告するために、下部（物理及びリンク）層より高い層（上記ネットワークなど）へのトリガイベントを定義します。一方、MICSは、下位層に上位層から送信されたコマンドをサポートし、それがハンドオーバーと移動性に関連するリンクの動作を管理する方法をユーザーに提供します。 MIISは、MNまたはネットワークがネットワーク選択及びハンドオーバを容易にするために、ネットワーク情報を取得することが可能なフレームワークを提供します。
Although the purpose of IEEE 802.21 has been developed to enhance the user experience of MNs roaming between heterogeneous networks, the results may be utilized to optimize the handover performance in a homogeneous network. When the MIH primitives are available for handover in the 802.16e network, the MN can use them instead of the primitives proposed in this document. Table 1 shows examples of the mapping between the proposed primitives and the MIH primitives.
IEEE 802.21の目的は、異種ネットワーク間でローミングするMNのユーザ体験を向上させるために開発されたが、結果は、同種ネットワークにハンドオーバー性能を最適化するために利用することができます。 MIHプリミティブは、802.16eのネットワークにおけるハンドオーバのために用意されていた場合、MNは、この文書で提案されたプリミティブの代わりにそれらを使用することができます。表1は、提案されたプリミティブとMIHプリミティブとの間のマッピングの一例を示します。
+-------------------------+-------------------------+
| Proposed primitives | MIH primitives |
+===================================================+
| NEW_LINK_DETECTED | LINK_DETECTED |
+---------------------------------------------------+
| LINK_HANDOVER_IMPEND | LINK_HANDOVER_IMMINENT |
+---------------------------------------------------+
| LINK_SWITCH | HANDOVER_COMMIT |
+---------------------------------------------------+
| LINK_UP | LINK_UP |
+---------------------------------------------------+
Table 1. The Proposed Primitives and MIH Primitives
表1.提案プリミティブとMIHプリミティブ
The primitives defined in this document are used only for local indication inside of the MN, so no security mechanism is required to protect those primitives. However, FMIPv6 messages and IEEE 802.16e messages, which may trigger the primitives, need to be protected.
この文書で定義されたプリミティブは唯一のMNの内部ローカル指示のために使用されているので、何のセキュリティメカニズムは、これらのプリミティブを保護するために必要とされません。しかし、プリミティブを引き起こす可能性FMIPv6とメッセージおよびIEEE 802.16eのメッセージは、保護する必要があります。
Security considerations of the FMIPv6 specification [RFC5268] are applicable to this document. It is also worthwhile to note that the IEEE802.16e has a security sub-layer that provides subscribers with privacy and authentication over the broadband wireless network. This layer has two main component protocols: a privacy key management protocol (PKM) for key management and authentication and an encapsulation protocol for encrypting data. From the perspective of the 802.16e, FMIPv6 messages are considered as data and are delivered securely by using those protocols.
FMIPv6と仕様[RFC5268]のセキュリティ上の考慮事項は、この文書に適用されます。 IEEE802.16e規格は、ブロードバンド・ワイヤレス・ネットワーク上のプライバシーと認証を加入者に提供するセキュリティサブ層を有していることに注意することも価値があります。鍵管理、認証、データを暗号化するためのカプセル化プロトコルのプライバシーキー管理プロトコル（PKM）：この層は、2つの主要なコンポーネントプロトコルを有しています。 802.16eの観点から、FMIPv6とメッセージがデータとして考えられ、これらのプロトコルを使用して確実に送達されます。
However, some of IEEE 802.16e management messages are sent without authentication. For example, there is no protection to secure 802.16e broadcast messages. It may be possible for the attacker to maliciously forge a MOB_NBR-ADV message so that it contains the bogus BSIDs, or send a flood of MOB_NBR-ADV messages having different bogus BSIDs toward the MN. As a result, the MN may trigger a bunch of NEW_LINK_DETECTED primitives and send useless consecutive RtSolPr messages to the PAR, finally resulting in wasting the air resources. Therefore, the MN SHOULD perform scanning when detecting new BSs in the received MOB_NBR-ADV messages in order to assure the included neighbor information.
しかし、IEEE 802.16eの管理メッセージの一部は、認証なしで送信されます。例えば、802.16eのブロードキャストメッセージを確保するためには保護がありません。攻撃者が悪意を持って、それが偽のBSIDを含むようにMOB_NBR-ADVメッセージを偽造、またはMNに向けて異なる偽のBSIDを持つMOB_NBR-ADVメッセージの洪水を送信することが可能です。その結果、MNはNEW_LINK_DETECTEDプリミティブの束を引き起こすことが、最終的に空気のリソースを無駄になり、PARに無用の連続RtSolPrをメッセージを送信します。受信されたMOB_NBR-ADVメッセージに新しい基地局を検出したときしたがって、MNが含まれる近隣情報を確保するためにスキャンを実行する必要があります。
It is also possible that attackers try a DoS (Denial-of-Service) attack by sending a flood of MOB_BSHO-REQ messages and triggering LINK_HANDOVER_IMPEND primitives in the MN. But the IEEE 802.16e provides a message authentication scheme for management messages involved in handover as well as network entry procedures by using a message authentication code (MAC) such as HMAC/CMAC (hashed/cipher MAC). Thus, those management messages are protected from the malicious use by attackers who intend to trigger LINK_HANDOVER_IMPEND or LINK_UP primitives in the MN.
攻撃者がMOB_BSHO-REQメッセージの洪水を送信し、MNにLINK_HANDOVER_IMPENDプリミティブをトリガすることにより、DoS攻撃（サービス拒否）攻撃を試みることも可能です。しかし、IEEE 802.16eのようなHMAC / CMACなどのメッセージ認証コード（MAC）を使用してハンドオーバならびにネットワークエントリ手順に関与する管理メッセージのためのメッセージ認証スキームを提供する（ハッシュ/暗号MAC）。したがって、これらの管理メッセージは、MNにLINK_HANDOVER_IMPENDまたはLINK_UPプリミティブをトリガするつもり攻撃者が悪質な使用から保護されています。
Many thanks to the 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, Rajeev Koodli, Jonne Soininen, Gabriel Montenegro, Singh Ajoy, Yoshihiro Ohba, Behcet Sarikaya, Vijay Devarapalli, and Ved Kafle who have provided technical advice.
この作品で彼らの努力のためのKWISF（韓国無線インターネット標準化フォーラム）のIETFモビリティ作業部会のメンバーに感謝します。また、当社は、アルパースE. Yegin、Jinhyeockチェ、ラジーブKoodli、Jonne Soininen、ガブリエルモンテネグロ、シンAjoy、義弘大場、ベーチェットSarikaya、ビジェイDevarapalli、および技術的なアドバイスを提供してきたVED Kafleに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]トムソン、S.、Narten氏、T.、およびT.神明、 "IPv6のステートレスアドレス自動設定"、RFC 4862、2007年9月。
[RFC5268] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5268, June 2008.
[RFC5268] Koodli、R.、エド。、 "モバイルIPv6高速ハンドオーバ"、RFC 5268、2008年6月。
[IEEE802.16] "IEEE Standard for Local and Metropolitan Area Networks, Part 16: Air Interface for Fixed Broadband Wireless Access Systems", IEEE Std 802.16-2004, October 2004.
[IEEE802.16]「ローカルのためのIEEE Standardとメトロポリタンエリアネットワーク、パート16：固定ブロードバンド無線アクセスシステムのためのエアインタフェース」、IEEE STD 802.16-2004、2004年10月。
[IEEE802.16e] "IEEE Standard for Local and Metropolitan Area Networks, 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.
[IEEE802.16e規格]「ローカルおよびメトロポリタンエリアネットワークのIEEE標準、改正2：固定結合され、モバイル運用のための物理的および媒体アクセス制御層許諾バンドと正誤表1で」、IEEE規格の802.16eの-2005およびIEEE標準802.16-2004 /コリント1から2005まで、2006年2月。
[RFC4260] McCann, P., "Mobile IPv6 Fast Handovers for 802.11 Networks", RFC 4260, November 2005.
[RFC4260]マッキャン、P.、 "802.11ネットワークのためのモバイルIPv6高速ハンドオーバ"、RFC 4260、2005年11月。
[RFC5184] Teraoka, F., Gogo, K., Mitsuya, K., Shibui, R., and K. Mitani, "Unified Layer 2 (L2) Abstractions for Layer 3 (L3)-Driven Fast Handover", RFC 5184, May 2008.
[RFC5184]寺岡、F.、午後、K.、三ツ矢、K.、渋井、R.、およびK.三谷、 "レイヤ3（L3）駆動型高速ハンドオーバの統合レイヤ2（L2）抽象"、RFC 5184 、2008年5月。
[RFC4907] Aboba, B., "Architectural Implications of Link Indications", RFC 4907, June 2007.
[RFC4907] Aboba、B.、 "リンク適応の建築的意味"、RFC 4907、2007年6月。
[IEEE802.21] "Draft IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services", IEEE Std P802.21 D9.0, February 2008.
[IEEE802.21]「ローカルおよびメトロポリタンエリアネットワークのためのIEEE規格のドラフト：メディア独立ハンドオーバサービス」、IEEE STD P802.21 D9.0、2008年2月を。
[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.
[SH802.16e]キム、K.、キム、C.、およびT.キム、「IEEE 802.16eのブロードバンド無線アクセスのためのシームレスハンドオーバメカニズム」、計算科学の巻に関する国際会議。 2、pp.527-534、2005。
Authors' Addresses
著者のアドレス
Heejin Jang SAMSUNG Advanced Institute of Technology P.O. Box 111 Suwon 440-600 Korea
テクノロジーのHeejinチャン・SAMSUNG先進研究所私書箱111水原440から600韓国箱
EMail: heejin.jang@gmail.com
メールアドレス：heejin.jang@gmail.com
Junghoon Jee Electronics and Telecommunications Research Institute 161 Gajeong-dong, Yuseong-gu Daejon 305-350 Korea
Junghoonジヨン電子通信研究院161 Gajeong洞、儒城区大田305から350韓国
EMail: jhjee@etri.re.kr
メールアドレス：jhjee@etri.re.kr
Youn-Hee Han Korea University of Technology and Education Gajeon-ri, Byeongcheon-myeon Cheonan 330-708 Korea
技術のユン・喜漢韓国大学教育Gajeon里、Byeongcheon-北面天安330から708韓国
EMail: yhhan@kut.ac.kr
メールアドレス：yhhan@kut.ac.kr
Soohong Daniel Park SAMSUNG Electronics 416 Maetan-3dong, Yeongtong-gu Suwon 442-742 Korea
Soohongダニエル・パーク三星電子416 Maetan-3dong、霊通区水原442から742韓国
EMail: soohong.park@samsung.com
メールアドレス：soohong.park@samsung.com
Jaesun Cha Electronics and Telecommunications Research Institute 161 Gajeong-dong, Yuseong-gu Daejon 305-350 Korea
Jaesunチャ電子通信研究院161 Gajeong洞、儒城区大田305から350韓国
EMail: jscha@etri.re.kr
メールアドレス：jscha@etri.re.kr
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78および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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。