ノード状態情報に基づいたFastHandoff 制御機構の設計と実装

i-car B4小柴　晋koshi@sfc.wide.ad.jp

　　 親：湧川　隆次サブ親：三屋　光史朗

研究概要 ノード状態情報の取得

利用可能 IF L2, L3 状態情報 利用可能 ARs 位置情報 利用者の要望 ( 携帯電話は極力使わない等 )

複数の Handoff 機構の制御 適切な Handoff 機構の選択

研究背景 無線通信機器の普及、小型計算機の普及

移動中の接続性への需要 移動透過性への需要

移動透過性の提供 Mobile IPv6, LIN6 等 複数 IF サポート

Fast MIPv6 handoff latency 短縮、確実なパケット配信

本研究における問題意識 Fast Handoff 機構の trigger が未定義

利用可能な IF 依存 ( 数、特性等 ) messaging の timing 、内容が未定義 trigger となる情報と Handoff 処理の対応が未定義

複数ある Handoff 機構が選択できない 利用状況に応じた最適な Handoff ができない

本研究のアプローチ Fast Handoff/Handoff Trigger 制御機構の提供

trigger となる状態情報を抽象化 trigger と Handoff 処理の対応管理 リモートホストの状態情報の取得 ポリシーに基づいた Handoff 処理提供 trigger 条件と実行される処理の定義可能性提供

- 不明確な trigger/ 処理対応を抽象化、詳細な設定可能性提供- リモートホストの状態に基づいた Handoff 管理による互換性提供

システム構成 ノード状態情報取得機構

全レイヤーの情報を取得可能、 Proc Control 機構へ情報提供 リモートホスト状態情報取得機構

リモートホストと状態を交換、 Proc Control 機構へ情報提供 Proc Control 機構

取得した情報から trigger となる条件を監視 trigger となる条件を得た場合、対応する処理を実行

User Front End ノード管理者による policy 設定用 Front End

設計 ( 全体図 )

L1

L2

L3

L4

L5

L6

L7

node info.

Front Endset_policy();

show_status();

context trans

FHHO

FVHO

fnc1(values);

fnc2(values);

fnc3(values);

1 計算機内での処理の流れ

Proc Control

Proc Control 機構について Trigger 情報と Handoff の対応を管理

ノード内の全ての状態情報を監視可能 Policy DB を所有し、 trigger と処理の対応を管理 リモートホストの状態を取得、適切な処理を選択可能 Policy は Handoff 以外の trigger/ 処理を管理可能

•Fast Handoff 以外のシステムにも応用可能-Fast Handoff においては AR, MN, CN での利用を想定

設計 ( 動作概要 )internet

AR AR

電波が弱くなったMN

Handoff 処理検索 ( 電波が弱くなった ) ； →AR に通知 ↓context_trans( 弱い , H@, CoA, MAC);

Ack

Handoff 処理検索 (MN 弱くなった , GPS 無し ) ；　　→移動先 AR 検索　　　　　　　　　　　↓context_trans(MAC, 検索 , 近隣 AR);

発見Handoff 処理検索 ( 移動先発見 ); →start HI-draft05send_HI(MAC, H@, oCoA); メリット：　 -Handoff 前に独自の移動先

AR 検索が可能 ↓確実な Fast Handoff の実現

Trigger となる情報に関して trigger として利用可能と思われる情報

L2 情報：電波強度、 Link UP/Down 、 AP 混雑状況 L3 情報： prefix の変化 L4 情報： window size 、 DACK 、 RTO AP 位置情報 +MN 位置情報

最も効率的な Handoff に必要な情報 取得可能な情報の組み合わせを trigger とし、比較 基本となる挙動として定義

期待される成果 ノード上の状態情報取得機構 リモートホストとの状態情報共有機構 Fast Handoff 機構 +Handoff 処理制御機構

Vertical & Horizontal を同様に利用可能 Fast Handoff をより確実にするための拡張サポート

ノード管理者による Handoff 制御用 Front End 実験結果に基づいた基本制御仕様

Trigger 情報 vs Handoff 処理の基本セット定義

実装に関して NetBSD-1.5.3(or 1.6?) + KAME snap 使用言語： C Mobile IPv6 の実装として SFC-MIP6 を利用

Draft-18 実装 Fast Handoff

draft-ietf-mobileip-fast-mipv6-05.txt を実装 リモートホスト状態情報取得機構

draft-koodli-seamoby-ctv6-03.txt を実装

評価項目 定量評価

Trigger 情報 /Handoff 別性能評価 Handoff Latency Packet Loss Rate

プロトコルスイッチオーバーヘッド Horizontal to Vertical Vertical to Horizontal

計算処理オーバーヘッド 定性評価

Policy DB の内容通りに Handoff 処理を制御できたか

質疑応答、コメント下さい以上

例： Handoff 効率化についてInternet

・ L2 info を用いた HH の場合： 802.11b の場合

oAR nAR

MN1. 電波が弱くなってきた！

3. 電波弱いんだけど　　　　　 && GPS 無いです

2.HO 処理検索→ AR に通知4.HO 処理検索　　条件： GPS 無し && 電波弱い　　　　　　　　　↓　　近隣 AR に MN の MAC 検索

5. この MAC 知らない？6. 見えるよ7.HO 処理検索　　条件：移動先 AR 発見　　　　　　　　↓　　　 HI-draft05 を開始 メリット：

　・ GPS が無くても移動先 AR を特定　・より確実な Handoff

設計(FMIP による vertical handoff support)

internet

AR

携帯基地局

MN=802.11b=cell phone電波弱い！

接続開始(get nCoA)

handoff_prep(H@, nCoA)

MN Link Down!

Ack

Fwd packets dst to MN(nCoA)

Packets from ARBU

BA

fwd_stop (H@)

研究背景 無線通信機器の普及、小型計算機の普及

移動中の接続性への需要 移動透過性への需要

移動体通信計算機上アプリケーションの可能性 P2P Grid Computing Realtime Streaming etc.

本研究のメインターゲット

移動体通信に対する要望 Realtime Streaming において : 電話等

Handoff Latency の短縮 時間が経過したパケットは必要無い

その他の Streaming(buffer 有り ) ：音楽配信等 Handoff Latency の短縮 Buffer 用に多少時間が経過しても確実に配送

共通点 無駄なパケット配送の削減

MIPv6 における問題点 高速な Handoff は全く約束されていない

L3 情報を移動検知に利用： RA の間隔に依存 移動後通信再開までの処理に時間が必要 移動時にパケットロスが生じる

Handoff 最適化機構への需要　 -Handoff Latency を短縮するための機構　 - 確実にパケットを MN へ配送するための機構

MIPv6 ：移動時の処理・あらかじめ CN と通信を行いながら移動した場合：

internet

CNHA

router router

移動通信パケットフロー

MN

RA

DAD

BU

BABA

通信再開

既存の解決手法 2種類の Handoff に対する最適化機構の提案

Horizontal Handoff:同種ネットワーク AP間の移動 Vertical Handoff ：異種ネットワーク AP間の移動

Fast Horizontal Handoff(FHHO) draft-ietf-mobileip-fast-mipv6-05.txt L2 情報を用いた最適化も考慮

Fast Vertical Handoff(FVHO) ドラフト無し、実装及び論文有り 複数 IF を用いた Handoff の最適化

問題点に対するアプローチ より柔軟な Handoff 機構の提供

利用可能 IF 、状態による Handoff 処理制御 利用可能状態情報の模索 Handoff 処理と状態情報の関連付けの汎用化 独自の Handoff 処理の定義及び拡張可能性提供

ノードの利用形態及び状況に最適な Handoff 処理を実現　 - 利用環境において最短な Handoff Latency　 - 利用環境において最も確実な packet 配信

FHHO ：移動時の処理概要internet

Access Router(AR) AR

AckMN Link Down

Fwd packets dst to oCoA

MN Link Up

Fwd packets dst to oCoA

Packets dst to CNDAD

BU

L2 addr + H@ + oCoA電波が弱い！！

MN

Fast Handoff における問題点 Handoff 処理開始の基準が不明確

L2 情報と Handoff 処理の関連付けが不明確 AR 主導 or MN 主導 AR<-->MN 間の messaging が不確定 (timing 、内容

等 ) 適切な Handoff 処理は計算機依存

利用可能 IF 利用可能 ARs 利用可能サービス (GPS 等 ) 利用者の要望 ( 携帯は極力使いたくない等 )

実装内容 ノード状態情報取得機構 ノード状態情報と Handoff 対応管理機構

コンフリクトの処理 対応設定用 Front End

ノード状態情報通知機構 draft-koodli-seamoby-ctv6-03.txt

Fast Handoff 実装 draft-ietf-mobileip-fast-mipv6-05.txt Vertical Handoff support拡張

本研究における解決手法 基本プロトコルとして以下の研究を利用

Fast Handoff:draft-ietf-mobileip-fast-mipv6-05 Context Transfer:draft-koodli-seamoby-ctv6-03 Mobile IPv6:SFC-MIPv6

基本プロトコルを以下の項目について拡張 ノード上のあらゆる状態情報を取得 (not only L2) リモートのノード状態情報取得 上記ノード状態情報に基づいた Handoff 処理制御 ノード管理者による Handoff 処理設定用フロントエンド

期待される成果 利用状況における最適な Handoff 処理を提供

アプリケーション： how reliable should Handoff be? 位置情報： which AR? What kind of Handoff? 利用可能 IF ： which IF? What kind of Handoff? L2 情報： timing, What kind of Handoff?

拡張 Handoff が全て Fail した場合 Draft で述べられている最低限の Fast Handoff 処理 通常の MIPv6 の処理 最低限移動透過性の保証