Fast Handoffにおける

ノード状態情報に基づいたFast
Handoff制御機構の設計と実装
i-car B4
小柴晋
[email protected]
親：湧川隆次
サブ親：三屋光史朗
研究背景

無線通信機器の普及、小型計算機の普及



移動中の接続性への需要
移動透過性への需要
移動体通信計算機上アプリケーションの可能性




P2P
Grid Computing
Realtime Streaming
etc.
本研究のメインターゲット
移動体通信に対する要望

Realtime Streamingにおいて:電話等



その他のStreaming(buffer有り)：音楽配信等



Handoff Latencyの短縮
時間が経過したパケットは必要無い
Handoff Latencyの短縮
Buffer用に多少時間が経過しても確実に配送
共通点

無駄なパケット配送の削減
MIPv6における問題点

高速なHandoffは全く約束されていない



L3情報を移動検知に利用：RAの間隔に依存
移動後通信再開までの処理に時間が必要
移動時にパケットロスが生じる
Handoff最適化機構への需要
-Handoff Latencyを短縮するための機構
-確実にパケットをMNへ配送するための機構
既存の解決手法

2種類のHandoffに対する最適化機構の提案



Fast Horizontal Handoff(FHHO)



Horizontal Handoff:同種ネットワークAP間の移動
Vertical Handoff：異種ネットワークAP間の移動
draft-ietf-mobileip-fast-mipv6-05.txt
L2情報を用いた最適化も考慮
Fast Vertical Handoff(FVHO)


ドラフト無し、実装及び論文有り
複数IFを用いたHandoffの最適化
Fast Handoffにおける問題点

Handoff処理開始の基準が不明確




L2情報とHandoff処理の関連付けが不明確
AR主導 or MN主導
AR<->MN間のmessagingが不確定(timing、内容等)
適切なHandoff処理は計算機依存




利用可能IF
利用可能ARs
利用可能サービス(GPS等)
利用者の要望(携帯は極力使いたくない等)
問題点に対するアプローチ

より柔軟な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拡張
設計(全体図)
set policy
L7
show status
L6
values
L5
L4
L3
Front End
values
node info.
L2
values
L1
Policy DB
context trans
FHHO
FVHO
設計(HO処理制御機構)
・L2
infoを用いたHHの場合：802.11bの場合
Internet
5.このMAC知らない？
oAR
7.HO処理検索
条件：移動先AR発見
↓
HI-draft05を開始
6.見えるよ
nAR
3.電波弱いんだけど
&&
GPS無いです
2.HO処理検索→ARに通知
MN
1.電波が弱くなってきた！
3.HO処理検索
条件：GPS無し&&電波弱い
↓
近隣ARにMNのMAC検索
設計(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できないかも);
}
設計(HO処理制御機構) Cont.3
・全体的な処理の流れ(イメージ)
get_data.c
read_data.c
ctl_behav.c
behav1.c
behav4.c
behav2.c
behav3.c
実装環境



NetBSD-1.5.3(or 1.6?) + KAME snap
使用言語：C
Mobile IPv6の実装としてSFC-MIP6を利用

Draft-18実装
評価項目

定量評価





SFC-MIP6とHandoff Latency、パケットロス率を比較
計算処理オーバーヘッド
ノード状態情報とHO処理の対応の最適化
Realtime streamingを用いたパケットロス率比較
ノード状態情報通知機構のperformance
コメント下さい

終わり
研究概要

利用環境に基づいたFast Handoff制御機構




異なったHandoff処理の制御



最適なHO処理選択
通信再開までの時間短縮
移動時のパケットロス削減
Horizontal Handoff:同種のネットワーク間移動
Vertical Handoff：異なったネットワーク間の移動
HO処理とタイミングの同期管理機構
解決へのアプローチ

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処理の制御
設計(ノード状態情報取得機構)
L7
L6
L5
・Location Info
・Route Info
・Link State Info
L4
L3
L2
L1
socket

Download Report