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

i-car B4

小柴　晋koshi@sfc.wide.ad.jp

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

研究背景

無線通信機器の普及、小型計算機の普及 移動中の接続性への需要 移動透過性への需要

移動体通信計算機上アプリケーションの可能性 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

BA

BA通信再開

既存の解決手法

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 の最適化

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 CN

DAD

BU

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

MN

Fast Handoff における問題点

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

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

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

問題点に対するアプローチ

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

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

本研究における解決手法

基本プロトコルとして以下の研究を利用 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 対応管理機構

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

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

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

期待される成果

利用状況における最適な Handoff 処理を提供 アプリケーション： how reliable should Handoff b

e? 位置情報： 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 の処理 最低限移動透過性の保証

例： 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

設計 ( 全体図 )

L1

L2

L3

L4

L5

L6

L7

node info.

Front Endset_policy();

show_status();

Policy DB

context trans

FHHO

FVHO

fnc1(values);

fnc2(values);

fnc3(values);

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

設計 (FHHO による FVHO サポート )

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@)

実装に関して

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

Draft-18 実装 FHHO

draft-ietf-mobileip-fast-mipv6-05.txt を実装 Context Transfer

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

評価項目

定量評価 SFC-MIP6 と Handoff Latency, Packet loss率を比較

基本 Fast Handoff と上記の項目について比較 計算処理オーバーヘッド

定性評価 Policy DB の内容通りに Handoff 処理を制御でき

たか 他の Fast Handoff との Interoperability( 可能なら )

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

以上

研究概要

利用環境に基づいた Fast Handoff 制御機構

解決へのアプローチ

HO 処理のトリガーとなる L2 情報を

問題意識

利用環境、通信状況に基づいた FHO 制御 Available Network Interfaces Link State Information(L2-info) Available Access Routers & their Location MN’s Current Location

Handoff 機構について

ネットワーク間移動時のパケット制御機構 Horizontal Handoff

同種類のネットワーク間の移動 単一 IF での移動を対象 L2 情報を用いた最適化を考慮

Vertical Handoff 異種のネットワーク間の移動 複数 IF での移動を対象

Fast Handoff の現状

Handoff の最適化機構 Fast Horizontal Handoff(HH)

draft-ietf-mobileip-fast-mipv6-05.txt 試験的な実装有り（ 2,3 個 ?） Interoperability が無い (why?)

Fast Vertical Handoff(VH) ドラフト無し 実装及び論文有り Interoperability に関しては特に考慮されていない

問題意識

利用環境に基づいた Handoff 処理制御の欠如 利用可能 IF L2 、 L3 状態情報 利用可能 AR 位置情報 利用者の希望

ノード状態情報と HO 処理の対応管理機構への需要

現状は全て実装依存

研究概要

ノード状態情報取得機構 Info. listed in previous slide

ノード状態情報と最適な Handoff 処理の対応 MN と ARどちらにも利用可能な設計 基本となる対応の定義 利用者の意思を反映可能にする Front End設計 対応に基づいた HO 処理の制御

設計 ( ノード状態情報取得機構 )

L1

L2

L3

L4

L5

L6

L7

・ Location Info・ Route Info・ Link State Info

socket

設計 (HO 処理制御機構 ) Cont.3

get_data.c

・全体的な処理の流れ ( イメージ )

read_data.c

ctl_behav.c

behav1.c

behav2.c behav3.c

behav4.c

設計 (HO 処理制御機構 ) Cont.・前スライドの例における内部処理イメージ@MN

情報収集機構からの情報 : 電波弱い

If( 電波弱い ) { 30秒 GPS 情報を待つ ;

If(GPS 情報有り ) sendmsg( 電波弱い , GPS 情報 ); else { GPS 情報 = GPS 情報無い ; sendmsg( 電波弱い , GPS 情報 ); }}

設計 (HO 処理制御機構 ) Cont.2・前々スライドの例における内部処理イメージ@AR

情報収集機構からの情報 : 電波弱い、 GPS 無い

If( 電波弱い && GPS 無い ) { sendmsg_neighborARs(MN’s MAC); 3秒 Ack を待つ ;

If(見えた ) start_HI_draft05(MAC, H@, oCoA, Lifetime); else sendmsg_MN(Fast Handoff できないかも );}

評価項目

定量評価 SFC-MIP6 と Handoff Latency 、パケットロス率を比較 計算処理オーバーヘッド ノード状態情報と HO 処理の対応の最適化 Realtime streaming を用いたパケットロス率比較 ノード状態情報通知機構の performance 最適な HO 処理選択 通信再開までの時間短縮 移動時のパケットロス削減

異なった Handoff 処理の制御 Horizontal Handoff: 同種のネットワーク間移動 Vertical Handoff ：異なったネットワーク間の移動

HO 処理とタイミングの同期管理機構