[要約] RFC 5270は、IEEE 802.16eネットワーク上でのMobile IPv6の高速ハンドオーバーに関する標準化ドキュメントです。このRFCの目的は、モバイルデバイスが異なるアクセスポイント間でスムーズに切り替えるための手順とプロトコルを提供することです。
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
IEEE 802.16Eネットワーク上のモバイルIPv6高速ハンドオーバー
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.
このドキュメントでは、IEEE 802.16eの仕様スイートに準拠したリンクレイヤーにモバイルIPv6の高速ハンドオーバーを実装する方法について説明します。提案されたスキームは、リンク層のハンドオーバーインジケーターを悪用することにより、シームレスなハンドオーバーを達成しようとし、それにより、モバイルIPv6ファーストハンドオーバー手順を効率的にIEEE 802.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は、リンク層技術からのサポートを想定しています。ただし、利用可能な特定のリンク層情報と利用可能なタイミングは、[RFC4260]で指摘されているように、IEEE 802.11ネットワークのFMIPv6ソリューションを提供するように、使用中の特定のリンク層技術に従って異なります。したがって、このドキュメントは、特にIEEE 802.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].
「必須」、「そうでない」、「必須」、「「shall」、「shall」、「shill」、「suff」、「ofs "、" becommended "、" bay "、および「optional」」[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.
WLAN（ワイヤレスローカルエリアネットワーク）のハンドオーバーと比較して、IEEE 802.16Eハンドオーバーメカニズムは、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）から、layer 2 neighbor Advertisementメッセージ（mob_nbr-adv）に耳を傾けます。BSはそれらを定期的に放送してネットワークを特定し、近隣BSSの特性を発表します。これを受け取ると、MNはこのメッセージを解読して、将来のハンドオーバーのために近隣BSSのパラメーターに関する情報を見つけます。MOB_NBR-ADVに提供された情報を使用すると、MNは、近隣のチャネル数を取得してスキャン時間を短縮することにより、ハンドオーバーレイテンシを最小限に抑えるか、信号強度、サービス品質に基づいてより良いターゲットBを選択する場合があります（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パラメーターなどのメトリックによって比較され、それらの中でターゲットBSが選択されます。必要に応じて、MNは、将来のハンドオーバーを促進するために、候補BSSと関連付けようとすることができます。MNが引き渡しを決定すると、MOB_MSHO-REQメッセージをサービングBS（S-BS）に送信することにより、その意図に通知します。その後、BSは、候補者と交渉した後、推奨されるBSSをMNに含むMOB_BSHO-RSPで返信します。オプションで、ターゲットが決定されたときに、バックボーンを介してターゲット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 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.
ハンドオーバーの準備後、ハンドオーバーの実行が開始されます。MNは、Handoverの最終的な兆候として、MOB_HO-INDメッセージをサービングBSに送信します。新しい添付ファイルを作成すると、ターゲットBSから物理パラメーターを取得できる802.16Eの範囲を実行し、ターゲットBSにパラメーターを調整します。ターゲットBSの範囲を正常に測定した後、MNは最大送信電力やモジュレーター/復調器タイプなどの基本的な機能を交渉します。次に、認証と主要な交換手順を実行し、最後にターゲットBSで登録します。ターゲットBSがバックボーンを介して認証パラメーターや機能パラメーターなどのコンテキストを既に学習している場合、対応する手順を省略する場合があります。802.16ハンドオーバー手順の詳細については、[IEEE802.16E]のセクション6.3.22を参照してください。登録を完了した後、ターゲットBSはMNのサービスを開始し、ターゲットBSを介した通信を利用できます。ただし、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 Neighbor Advertisementsを介してそれを行うことができます。モバイル機能をサポートするBSは、ネットワークトポロジ情報を含むMOB_NBR-ADVメッセージを定期的にブロードキャストするものとします（その最大間隔は1秒です）。このメッセージには、隣接BSSのBSIDとチャネル情報が含まれており、MNの近隣BSSとの同期を促進するために使用されます。MNは、将来の引き渡しのためにこのメッセージを通じて隣人BSSの必要な情報を収集できます。
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].
ネットワークトポロジを取得する別の方法はスキャンです。これは、適切なハンドオーバーターゲットを見つけるために利用可能なBSSを探して監視するプロセスです。MOB_NBR-ADVメッセージには近隣BSSに関する静的情報が含まれていますが、スキャンはリンク品質パラメーターなどのかなり動的なパラメーターを提供します。mob_nbr-advメッセージは近隣bsidsのリストを定期的に配信し、スキャンはいくつかの適切なBSSを整理する方法を提供するため、新しいBSSが広告で見つかった場合、MNはスキャンを介してそれらを識別し、BSIDを分解することをお勧めします。BSが接続されているサブネットの情報。スキャン中に発生するオプションの初期範囲の手順である協会は、差し迫った引き渡しを促進するための役立つ方法の1つです。MNは、ターゲットBを適切に選択し、潜在的な将来のハンドオーバーを促進する目的で、範囲のパラメーターとサービスの可用性情報を取得できます。関連性の詳細な説明は、[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（Media Independent Information Service）[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は、必要なQO、コスト、ユーザーの好み、ポリシーなどのさまざまな基準を考慮することにより決定できます。ターゲット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.
このセクションでは、IEEE 802.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_imbend（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.
MNに古いBSから新しいBSに切り替えるように強制するために、MNのIPレイヤーからMNのリンクレイヤーへの制御コマンド。
o LINK_UP (LUP)
o link_up（lup）
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を検出する際にnew_link_detectedプリミティブをIPレイヤー（fmipv6）にトリガーします。
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（プロキシ広告のルーター勧誘）とPRRTADV（プロキシルーター広告）を交換することにより、関連する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を送信する場合があります。ただし、この提案には、実現可能な場合、MNは、新しいBSの検出が通常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はバックオフメカニズムを提供します。また、攻撃者はMOB_NBR-ADVメッセージを偽造して、大量の偽のbsidを含めることができるように、またはそれぞれが異なるbsidを含むbob_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にbov_msho-reqを送信することでハンドオーバーを開始し、BSからbsからmob_bsho-rspを応答として受け取ります。あるいは、BSはMOB_BSHO-REQをMNに送信することにより、引き渡しを開始する場合があります。
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のいずれかを受信すると、Link LayerはLink_Handover_Imbendをトリガーして、MOB_BSHO-REQ/MOB_BSHO-RSPの到着のIPレイヤーをすばやく通知します。この時点で、リンクレイヤーで決定されたターゲットBSは、プリミティブのパラメーターとしてIPレイヤーに配信されます。原始は、リンク層のハンドオーバー決定が下され、その実行が差し迫っていることを報告するために使用されます。FMIPv6には、ハンドオーバー準備手順を開始するための兆候として役立つことができます。つまり、FBU（高速バインディングアップデート）メッセージをPARに送信します。
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_imbendは、ビーコン受信の欠如など、リンク損失の他の兆候を使用してフィルター付き信号強度測定を検証した後に送信できます。
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_imbendを受信すると、指定されたターゲットネットワークがアクセスルーターの発見ステップ中に収集された情報に基づいて、別のサブネットに属しているかどうかをチェックします。ターゲットが同じサブネットにあることが判明した場合、MNは引き継ぎ後も現在のIPアドレスを使用し続けることができ、FMIPv6を実行する必要はありません。それ以外の場合、IPレイヤーは、PRRTADVメッセージで提供されている情報を使用して、FBUメッセージをPARに送信し、将来のNCOA（新しいケアオブアドレス）を定式化します。
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は、HI（ハンドオーバーイニシエート）とハック（ハンドオーバー確認）メッセージをNARと交換して、PCOA（以前の住所）とNCOAの間にトンネルを設定し、MN用のパケットを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をサービングBSに送信した後、MNとBS間のデータパケット転送は許可されなくなります。FBACKがMNに到着する前にMOB_HO-INDが送信されると、MOB_HO-INDを受信した後にMNのすべての接続とリソースをリリースするため、MNが反応モードで動作する可能性が非常に高いことに注意してください。したがって、可能であれば、MNはPARとFBUとFBACのメッセージをPARと交換する必要があります。MOB_HO-INDをBSに送信して、予測モードで動作するようにします。
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 Primitiveの使用が可能になる場合があります。Link_switchは、MNに古いBSから新しいBSに切り替えることを強制するためのコマンドであり、[RFC5184]のワイヤレスLANに同様の概念が導入されています。適用されると、MNのIPレイヤーは、前のリンクでFBACKメッセージを受信する際にリンクレイヤーにリンク_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は、ターゲットBSとRNG-REQ/RSP、SBC-REQ/RSP、PKM-REQ/RSP、およびreg-Req/RSPメッセージを交換します。これらのメッセージのいくつかは、（以前）サービスを提供する（以前）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レイヤーはUNA（未承諾の近隣広告）をNAR（予測モード）に送信します。
* 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（Neighbor Advertisement Aumpounded）オプションを備えたRA（Router Advertisement）を使用して、異なる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_imbendプリミティブで指定されたターゲットではないネットワークに移動します。[RFC4907]のセクション2で言及されているこのような無効な適応症からの回復のために、MNは[RFC5268]のセクション5.6に従って新しいFBUをPARに送信する必要があります。新しい確認された場所へのパケット。
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がMNに新しいNCOAを提供する場合、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 Handoversは、異なるサブネットに属するネットワークへの携帯電話を想定しています。
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.
次の図では、MNのレイヤー2（MN L2）とBSの間のメッセージはIEEE 802.16メッセージであり、MNのレイヤー3（MN L3）とPARとNARの間のPARとメッセージの間のメッセージはFMIPV6メッセージです。MN L2とMN L3の間のメッセージは、このドキュメントで導入されたプリミティブです。
The handover procedures in the predictive mode are briefly described as follows. Figure 3 illustrates these procedures.
予測モードでのハンドオーバー手順は、次のように簡単に説明されています。図3は、これらの手順を示しています。
1. A BS broadcasts a MOB_NBR-ADV periodically.
1. BSは定期的にex_nbr-advを放送します。
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.
3. 新しいBSがMOB_NBR-ADVとスキャンを介して見つかった場合、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およびPRRTADVメッセージの交換により、新しいBSのBSIDを関連付けられたARに解決しようとします。
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.
5. MNは、bsにmob_msho-reqメッセージを送信することにより、ハンドオーバーを開始し、BSからmob_bsho-rspを受け取ります。あるいは、BSはMOB_BSHO-REQをMNに送信することにより、引き渡しを開始する場合があります。
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.
6. MNがBSからMOB_BSHO-RSPまたはMOB_BSHO-REQを受信すると、そのリンクレイヤーはLink_Handover_ImbendをIPレイヤーにトリガーします。
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.
7. link_handover_imbendを受信すると、MNのIPレイヤーは、link_handover_imbendとともに配信されたターゲットが別のサブネットに属し、fbuメッセージをパーに送信することを識別します。このメッセージを受信すると、PARは、NARとのHIとハックメッセージの交換により、PCOAとNCOAの間にトンネルを確立し、MN用のパケットをNCOAに転送します。この間、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メッセージを受信し、Handoverの最終的な表示として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は、ターゲットBSへのハンドオーバーを実行し、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メッセージを受信したことを識別します。NARをソースIPアドレスとして使用することにより、UNAをNARに発行します。同時に、それはNCOAのためにパパを演奏し始めます。
11. When the NAR receives the UNA from the MN, it delivers the buffered packets to the MN.
11. NARがMNからUNAを受信すると、バッファリングされたパケットを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
図3. 802.16Eの予測高速ハンドオーバー
The handover procedures in the reactive mode are described as follows. Figure 4 is illustrating these procedures.
反応モードでのハンドオーバー手順は次のように説明されています。図4は、これらの手順を示しています。
1. ~ 7. The same as procedures of predictive mode.
1. 〜7。予測モードの手順と同じ。
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は、ハンドオーバー前にフィードバックメッセージを受信せず、ハンドオーバーの最終的な兆候としてMobho-inメッセージを送信します。その後、新しいリンクでリアクティブモードで動作します。
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を実行し始めます。さらに、反応モードでFBUをPARに送信します。
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.
11. NARがMNからUNAとFBUを受信すると、FBACKをPARに転送します。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
図4. 802.16eの反応性高速ハンドオーバー
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ワーキンググループで、不均一なアクセスリンク間のハンドオーバーを促進する一般的なサービスを定義する際に、優れた研究が行われていることは注目に値します。標準作業は、メディア独立ハンドオーバー（MIH）サービス[IEEE802.21]と名付けられ、3種類のサービスを提案します：メディア独立イベントサービス（MIES）、Media Independent Command Service（MICS）、およびMedia Independent Information Service（MIIS）。
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の目的は、不均一なネットワーク間のMNSローミングのユーザーエクスペリエンスを強化するために開発されていますが、結果を利用して、均一なネットワークでのハンドオーバーパフォーマンスを最適化することができます。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の内部での局所的表示にのみ使用されるため、これらのプリミティブを保護するためにセキュリティメカニズムは必要ありません。ただし、Primitiveをトリガーする可能性のある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には、ブロードバンドワイヤレスネットワーク上のプライバシーと認証を加入者に提供するセキュリティサブレイヤーがあることに注意する価値があります。このレイヤーには、2つの主要なコンポーネントプロトコルがあります。キー管理と認証用のプライバシーキー管理プロトコル（PKM）と、データを暗号化するためのカプセル化プロトコルです。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ブロードキャストメッセージを保護するための保護はありません。攻撃者がbogus bsidsを含むようにmob_nbr-advメッセージを悪意を持って偽造したり、mnに向かって異なる偽のbsidを持つmob_nbr-advメッセージの洪水を送信することが可能かもしれません。その結果、MNはnew_link_detectedのプリミティブの束をトリガーし、役に立たないRTSOLPRメッセージをPARに送信する可能性があり、最終的に大気資源を無駄にします。したがって、MNは、含まれている近隣情報を保証するために、受信したMOB_NBR-ADVメッセージの新しいBSSを検出するときにスキャンを実行する必要があります。
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_IMBEND PRIMITIVESをトリガーすることにより、DOS（拒否）攻撃を試みることも可能です。しかし、IEEE 802.16Eは、HMAC/CMAC（Hashed/Cipher Mac）などのメッセージ認証コード（MAC）を使用して、ハンドオーバーに関与する管理メッセージおよびネットワーク入力手順にメッセージ認証スキームを提供します。したがって、これらの管理メッセージは、MNのLink_Handover_ImbendまたはLink_up Primitivesをトリガーするつもりの攻撃者による悪意のある使用から保護されています。
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モビリティワーキンググループメンバーに感謝します。さらに、Alper E. Yegin、Jinhyeock Choi、Rajeev Koodli、Jonne Soininen、Gabriel Montenegro、Singh Ajoy、Yoshihiro Ohba、Behcet Sarikaya、Vijay Devarapalli、Ved Kafleが技術的なアドバイスを提供しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、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] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月。
[RFC5268] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5268, June 2008.
[RFC5268] Koodli、R.、ed。、「Mobile IPv6 Fast Handovers」、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標準、パート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 STD 802.16E-2005およびIEEE STD 802.16-2004-2004/COR 1-2005、2006年2月。
[RFC4260] McCann, P., "Mobile IPv6 Fast Handovers for 802.11 Networks", RFC 4260, November 2005.
[RFC4260] McCann、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] Teraoka、F.、Gogo、K.、Mitsuya、K.、Shibui、R。、およびK. Mitani、 "Unified Layer 2（l2）abstractions for Layer 3（L3）駆動高ファーストハンドオーバー"、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ブロードバンドワイヤレスアクセスのシームレスなハンドオーバーメカニズム」、Computational Science Conference bol。2、pp.527-534、2005。
Authors' Addresses
著者のアドレス
Heejin Jang SAMSUNG Advanced Institute of Technology P.O. Box 111 Suwon 440-600 Korea
Heejin Jang Samsung Advanced Institute of Technology P.O.Box 111 Suwon 440-600 Korea
EMail: heejin.jang@gmail.com
Junghoon Jee Electronics and Telecommunications Research Institute 161 Gajeong-dong, Yuseong-gu Daejon 305-350 Korea
Junghoon Jee Electronics and Telecommunications Research Institute 161 Gajeong-Dong、Yousong-Gu Daejon 305-350 Korea
EMail: jhjee@etri.re.kr
Youn-Hee Han Korea University of Technology and Education Gajeon-ri, Byeongcheon-myeon Cheonan 330-708 Korea
Youn-Hee Han韓国技術教育と教育大学Gajeon-RI、Byeongcheon-Myon Cheonan 330-708 Korea
EMail: yhhan@kut.ac.kr
Soohong Daniel Park SAMSUNG Electronics 416 Maetan-3dong, Yeongtong-gu Suwon 442-742 Korea
スーホンダニエルパークサムスンエレクトロニクス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
Jaesun Cha Electronics and Telecommunications Research Institute 161 Gajeong-Dong、Yousong-Gu Daejon 305-350 Korea
EMail: jscha@etri.re.kr
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。