...

PDF 0.18MB

by user

on
Category: Documents
9

views

Report

Comments

Transcript

PDF 0.18MB
MANETs におけるTCP性能向上を目的としたマルチパス制御機構の提案
Proposal of Multipath Control Structure to Improve TCP Performance in MANETs
中央大学大学院理工学研究科 西秋 徹
Toru NISHIAKI
1.はじめに
制御を実現するプロトコルの実装が必要である.
近年,無線通信技術の発展により新たに登場した様々なサービス
そこで本稿では,その改善手法としてマルチパスにおける経路管
に対応し,シームレスに利用可能なユビキタスネット社会実現への期
理を実現する制御機構(MCP : Multipath Control Protocol)を提案す
待が高まっている.この要求に対して,従来の無線通信で広く利用さ
る.この新たなプロトコルは,TCP 層とマルチパスルーティングプロト
れているセルラー通信に加え,基地局に依存せず無線通信端末同
コルを管理する IP 層の間に導入することにより,複数経路に関する
士でフレキシブルにネットワーク構築が可能なモバイルアドホックネッ
情報の仲介を担う.これにより,複数経路に対する制御を行うことが
トワーク(MANETs : Mobile Ad hoc NETworks) が実現を助長する
できない TCP をサポートし,複数経路の管理及び制御を実現する.
技術として注目を集めている[1].また,そのネットワーク形態として,
こうして MCP により,輻輳による発生するパケット損失の抑制し,総合
近年ではスケーラブルでオープンなネットワークである次世代
的なパケット損失の抑制を実現することで TCP における通信性能向
MANETsの実現を見据えて,インフラとの共存型が主流となっている.
上を図る.
こうして,今後更に様々なアプリケーションがMANETs上で利用され
る こ と が 想 定 で き る た め , MANETs に お い て TCP ( Transmission
Control Protocol)通信を考慮した検討を行うことが必要とされ,様々
な研究が行われている.
2.ELFN 機能
TCPはパケット損失が発生した際,その発生原因を判別すること
ができない.従って,MANETsにおいて経路切断によるパケット損
こうした研究の下,MANETs環境におけるTCP通信は,通信性能
失の発生し対して,有線ネットワーク特有の原因である輻輳によるパ
が著しく低下することが実証されている[2,3].これはTCPの設計基準
ケット損失と認識される.これにより,TCPは輻輳制御としてウィンドウ
である有線ネットワークに比べ,MANETsでは頻繁にパケット損失が
サイズを縮小させるが,こうした制御は輻輳が実際に発生していない
発生するためである.その要因として,経路切断,輻輳,無線伝播損
経路に対して非効率な制御と言える.そこでこの問題を解決する手
失の 3 点が挙げられる.移動端末によりネットワークを構成しトポロジ
法としてELFN(Explicit Link Failure Notification)が提案されて
ーが動的に変化するMANETsでは,この中でも主として経路切断に
いる[2].この手法の概要を図 1 に示す.経路切断を認知した中継端
よるパケット損失の軽減に主眼が置かれている.従って,現在取り組
末は,ELFNパケットを送信元端末に対して送信する.これを受信し
まれてきた研究は経路切断に対する取り組みが多く,経路切断への
た送信元端末は,スタンバイ状態に遷移しTCP機能を停止させる.
適応性の高いルーティングプロトコルの開発によって改善を図ってい
これにより,再送制御や輻輳制御機能が停止することになるため,送
る.
信元端末による不必要な再送やウィンドウサイズの減少を抑制するこ
その代表的手法として,マルチパスルーティングプロトコルが挙げ
とが可能である.
られる.このプロトコルは,送信元端末と宛先端末の間において,複
数の経路を構築して通信を行う.こうして一方の経路が切断された際,
他方の経路を利用することで継続的に通信を行うことが可能である.
従って,経路切断により発生した損失パケットに対する再送を即座に
行うことができ,連続的なパケット損失を抑制することが可能である.
また,他のパケット損失要因として挙げられている輻輳に対しても,マ
ルチパスの利用によって性能改善への効果が期待できる.マルチパ
スでは利用できる経路を複数保持しているため,各経路の輻輳状態
に応じて送出するデータ量の調節が可能であると考えられる.しかし,
こうしたマルチパスにおける輻輳制御を考慮する際,現状の TCP 機
能では複数経路に対する管理及び制御を行うことができないため実
現が困難である.従って,マルチパス環境において各経路に対する
図 1 ELFN 概要
この方式をマルチパスに適応することで更なる転送効率の向上が
上記に示すように,MCP はトランスポート層とネットワーク層の仲介
期待できる.ELFN を受信した送信元端末は,マルチパスを保持して
を担う.MRP-MCP 間では,MRP から得られる各経路の Route ID と
いる場合,他方の経路を利用して再送を行うことができる.従って,
共に RTT 値を MCP におけるフロー制御の指標とし,各経路上端末
再送遅延を抑制することが可能となる.
の他セッションとの関与状況を輻輳制御の指標とする.また,
MCP-TCP 間では,MCP におけるフロー制御によって決定した各経
3.提案方式
路のウィンドウサイズの和,各経路の輻輳ウィンドウサイズの和,送信
3.1 目的・概要
バッファサイズの和を TCP に通知する.これによって,TCP で複数経
本提案方式では,マルチパスに適応した制御機構の設計を行い,
路を管理する必要がなく,1 本の経路情報として認識できる.以上の
TCP では管理不能な複数経路に対する管理・制御を実現する.主な
ような役割を 3.5 層のマルチパス制御機構が担うことで,TCP のサポ
機能として,各経路に対するフロー制御,及び輻輳制御が挙げられ
ートを実現する.
る.フロー制御では,各経路のウィンドウサイズを決定する.このウィ
ンドウサイズは,受信端末におけるバッファの空き容量および,RTT
値から算出される.また,輻輳制御では他セッションに関与した中継
3.3 MCP(Multipath Control Protocol)
3.3.1 フロー制御方式
端末から得られた輻輳予期情報を基に,送信元端末は輻輳ウィンド
各経路に対し状況に応じてウィンドウサイズを設定するフロー制御
ウサイズの減少を図る.また,その際に他方の経路が他セッションに
方式を提案する.通常の TCP では宛先端末が ACK によって通知す
関与していなければ,その経路に対して緩やかなウィンドウサイズの
る自身のバッファの空き容量状況より算出される.そこで,その情報
増加を行う.こうして,総合的にウィンドウサイズの維持を図り転送効
を MCP が受け取り各経路に対して分配することで,経路ごとのウィン
率の向上を実現する.
ドウサイズを決定する.その算出式を以下に示す.
Window Size ( t ) = Breceiver ×
3.2 プロトコルデザイン
本提案では,複数経路に対する制御を行うためにトランスポート層
とネットワーク層によるクロスレイヤアプローチのプロトコル設計を行う.
そこで,図 2 に示すようなプロトコルデザインを提案する.
RTTt
n
∑ RTT
i =1
i
上式について, t は変数, n は経路の本数, Breceiver は宛先端末
における空きバッファサイズ[packet]を示す.これにより,宛先端末が
受信できるパケット数の上限,及び各経路の伝送速度を RTT により
考慮することで,最適な経路ごとのウィンドウサイズを設定可能となる.
こうして,各経路に対する分割送信において効率なデータ転送を可
能とする.
3.3.2 マルチパス輻輳制御アルゴリズム
本提案ではマルチパス環境に適した輻輳制御アルゴリズムの設計
を行う.従来のアルゴリズムとの相違点として,以下に 2 点紹介する.
Ⅰ.輻輳予期フェーズの導入
図 2 プロトコルデザイン
本提案では従来の輻輳制御アルゴリズムに新しいフェーズとして,
輻輳予期フェーズを導入する.通常の輻輳制御における輻輳回避フ
■Network Layer (Multipath Routing Protocol : AODVM)
ェーズでは,ネットワーク上に流出するパケットを抑制することで輻輳
・マルチパスルーティングプロトコルの実装
回避を行う.しかし,輻輳が発生しやすい他セッションとの関与を判
・各経路に対する送受信バッファの保持及び管理
断基準とした制御を行っていない.そこで輻輳予期フェーズでは,中
■New Layer (MCP : Multipath Control Protocol)
継端末が他セッションとの関与を認知した段階で,送信元端末が輻
・各経路に対するフロー制御
輳ウィンドウサイズを一定,もしくは緩やかに減少させる.こうして,事
・各経路に対する輻輳制御
前に輻輳ウィンドウサイズを減少させることで,輻輳により発生するパ
■Transport Layer (TCP-SACK)
ケット損失を軽減させることが可能とずる.
・複数経路を統合した制御
i ) 他セッションとの直接的関与
他セッションとの直接的関与とは,経路上の中継端末が他セッショ
ンの経路上端末となる場合を指す.この場合,多数の通信でバッファ
Ⅱ.複数経路の相互性を利用した輻輳ウィンドウサイズの調節
を共有するため急激な蓄積が発生する.従って,オーバーフローが
上記で述べたように,輻輳予期フェーズでは他セッションとの関与
発生する前に輻輳ウィンドウサイズを軽減させる必要がある.そこで,
状態によって,事前にウィンドウサイズを緩やかに低下,もしくは一定
まず他セッションとの関与を認知した中継端末は,ACN(Anticipated
とする.その際,本提案では他方の経路の輻輳状態により,減少した
Congestion Notification)メッセージを送信元端末に対して送信する.
ウィンドウサイズを補完する制御を行う.また,他方の経路の輻輳状
また,そのメッセージの記載内容として直接的関与を意味する D フラ
態により場合分けし,その輻輳状態を考慮した処理を行う.こうして複
グを立て,関与しているセッション数 n を記載する.このメッセージを
数経路の相互性を活かした輻輳ウィンドウサイズの割り当てを行うこと
受信した送信元端末は,輻輳ウィンドウサイズに対して緩やかに減少
で,転送効率の向上を図る.
させる制御を行う.これに関して,図 3(a)に具体例を示す.
4.性能評価
ii ) 他セッションとの間接的関与
他セッションとの間接的関与とは,中継端末が周辺端末の通信の
影響を受け,キャリアセンスによる送信待機が発生する場合を指す.
4.1 シミュレーション条件
本研究の有用性を評価するために,ネットワークシミュレータ NS2 を
用いて検証した.表 1 にその際のシミュレーション条件を示す.
この場合,中継端末におけるバッファではキャリアセンスや RTS によ
表 1 シミュレーション条件
るパケットの蓄積は一時的である.そこで i)と同様に,まず他セッショ
ンとの関与を認知した中継端末は,ACN メッセージを作成する.また,
シミュレーション領域
1000×1000 [m]
そのメッセージに対して間接的関与を意味する I フラグを立てる.こ
端末数
50 [台]
れを受信した送信元端末は,輻輳ウィンドウサイズを一定とする制御
最大移動速度
1,5,10,20 [m/s]
移動モデル
Random WayPoint
トランスポートプロトコル
TCP-SACK
MAC プロトコル
IEEE802.11b
無線帯域幅
2[Mbps]
TCP パケットサイズ
1000[byte]
発生データ量
200[Kbyte]
データ発生確率
ポアソン分布
を行う. これに関して,図 3(b)に具体例を示す.
輻輳予期フェーズを考慮した輻輳ウィンドウサイズの変化
下の式によって算出される.
⎧[ SlowStart ]
⎪
⎪cwnd + 1
⎪
⎪
⎪[Congestion Avoidance]
⎪
⎪cwnd + 1 cwnd
⎪
cwnd = ⎨
⎪ Congestion Anticipation
]
⎪[
⎪ if Direct Participation
⎪
⎪ cwnd ± n
cwnd
⎪
⎪ else if Indirect Participation
⎪ constant
⎪⎩
上記の式において,輻輳予期フェーズでは直接的関与の場合,直
前の輻輳ウィンドウサイズより n/cwnd 減少させる.その際,n は中継
端末が関与しているセッション数を示す.従って,このセッション数が
多いほど,輻輳ウィンドウサイズの減少率が大きくなる.
たシングルパスルーティング(ELFN-S)及びマルチパスルーティング
(ELFN-M)と比較し,検討・考察を行う.
4.2 TCP スループット特性
図 4 に各方式における TCP スループット特性を示す.
100
80
80
throughput [Kbps]
以上より,本提案における各フェーズの輻輳ウィンドウサイズは以
また,本提案との比較対象として,2 で紹介した ELFN 機能を有し
throughput [Kbps]
図3
60
40
ELFN-S
ELFN-M
MCP
20
60
40
ELFN-S
ELFN-M
20
MCP
0
0
0
1
2
3
4
Number of Session
5
6
0
1
2
3
4
5
6
Number of Session
図 4 各方式おける TCP スループット特性 (a:1[m/s],b:20[m/s])
図 4 より,各方式共に端末の移動速度に関わらず,セッション数の
増加に伴い TCP スループットが低下していることがわかる.また,そ
の減少率は端末の移送速度に依存せず提案方式が最も低いことが
わかる.こうした特性が表れた理由として,セッション数の増加に伴っ
た輻輳の影響が考えられる.セッション数が多いネットワーク環境で
は,他のセッションに関与する端末が増加するため,バッファのオー
バーフローによるパケット損失が発生する確率が高くなる.従って,
再送回数が増加し転送効率の低下を招いたと考えられる.また,端
末の移動速度に対しても,提案方式が高い値を示すことから,マル
チパスを利用することで経路切断によるパケット損失の軽減も実現さ
れたと考えられる.こうして,経路切断及び輻輳によるパケット損失の
軽減により TCP スループットの向上を実現したと言える.
(b)20m/s
次に,この転送効率に影響する要因として考えられるパケット損失
図 6 各方式おける輻輳ウィンドウサイズの時間的変化
率及び輻輳ウィンドウサイズの特性について以下で検討を行う.
4.3 パケット損失率特性
図 6 より,提案方式における輻輳ウィンドウサイズの変化は,他の方
図 5 に各方式におけるパケット損失率特性を示す.本稿おけるパ
式と比較して,一定値を維持している時間が長いことがわかる.また,
ケット損失率は,中継端末のバッファからオーバーフローした単位時
端末の移動速度が増加に伴い,提案方式における輻輳ウィンドウサ
間当たりのパケット数を指す.
イズの変化が激しくなっていることがわかる.こうした特性が表れた要
4.5
3
ELFN-S
14
ELFN-S
ELFN-M
12
ELFN-M
10
MCP
drop rate [packet/sec]
4
3.5
drop rate [packet/sec]
因として,4.3 と同様に提案方式による輻輳制御の効果と考えられる.
16
MCP
2.5
2
1.5
1
4
2
0
2
3
4
5
6
輻輳ウィンドウサイズを抑制した際,他方の経路が通常状態であれ
6
0
1
補完を行った.従って,一方の経路が他のセッションとの関与により
8
0.5
0
本提案では,複数経路の相互性を利用して輻輳ウィンドウサイズの
ば輻輳ウィンドウサイズを増大させる.こうして安定した輻輳ウィンドウ
0
1
2
3
4
5
6
サイズを維持し,転送効率が向上したと言える.
Number of session
Number of Session
図 5 各方式おけるパケット損失率特性 (a:1[m/s],b:20[m/s])
5.結論
本研究では,MANETs におけるマルチパス環境にて,複数経路
図 5 より,各方式共に端末の移動速度及びセッション数の増加に
に対する制御を行う MCP を提案した.このプロトコルを 3.5 層として
伴って,パケット損失率が増加していることがわかる.また,セッション
導入することで,TCP では実現できない経路ごとの制御を可能とした.
数の増加に伴うパケット損失の増加率は提案方式が最も低いことが
そして性能評価を行った結果,端末の移動速度に関わらず,セッショ
わかる.こうした特性が得られた要因として,提案方式における各経
ン数の多い環境で効果が得られることがわかった.従って,輻輳が発
路に対する輻輳制御によるものと考えられる.本提案では,中継端末
生しやすい環境で有効であると言える.こうして,本研究の目的であ
が他セッションの関与を検知し,送信元端末が認知した段階で輻輳
る MANETs における TCP スループットの向上を実現したと言える.
ウィンドウサイズを軽減した.こうした事前制御によって,他セッション
の関与により発生するパケット損失を抑制した.
4.4 輻輳ウィンドウサイズの時間的変化
図 6 に各方式における輻輳ウィンドウサイズの時間的変化を示す.
その際,各方式の特性はある基準セッションに対して測定した値とす
謝辞
本研究を進めるにあたり,多大なるご指導,御助言を頂きました篠
田庄司教授に深く感謝致します.また,多くのご助力を頂いた同研
究室の諸氏にも感謝いたします.
る.
参考文献
[1] 間瀬憲一,中野敬介,仙石正和,篠田庄司“アドホックネットワー
ク”,電子情報通信学会誌,pp.127-134,2001 年 2 月.
[2] G. Holland and N. Vaidya, “Analysis of TCP performance over
mobile ad hoc networks”, In Proceedings of 5th ACM MobiCom,
pp. 219–230, 1999.
[3] A. A. Hanball, E. Altman, and P. Nain, “A Survey of TCP over Ad
Hoc Networks”, IEEE Communications Surveys and Tutorials,
(a)1m/s
vol. 7, no. 3, no. 3, pp. 22–36, 2005.
Fly UP