pdf document - 千葉大学関屋・小室研究室

社団法人電子情報通信学会
THE INSTITUTE OF ELECTRONICS,
INFORMATION AND COMMUNICATION ENGINEERS
信学技報
TECHNICAL REPORT OF IEICE.
マルチチャネル無線ハイブリッドネットワークにおける
QoS を考慮したルーティング方式
長崎篤†
関屋大雄†
阪田史郎†
柳生健吾††
† 千葉大学大学院融合科学研究科〒 263-8522 千葉県千葉市稲毛区弥生町 1-33
†† (株) NTT ドコモ先進技術研究所〒 239-8536 神奈川県横須賀市光の丘 3-5
E-mail: nagasaki@graduate.chiba-u.jp, yagyuuk@nttdocomo.co.jp
あらましマルチチャネルを用いた無線ハイブリッドネットワークにおいて, AP (Access Point) 間の負荷のバランス
をとるためにデータ受信端末がチャネルを切り替え, 他の AP に接続するルーティング方式が提案されている. 一方, 1
つの AP に異なるアプリケーションフローが集中した場合における, QoS (Quality of Service) を考慮したルーティン
グ方式についてはまだ検討されていない. 本稿では, マルチチャネル無線ハイブリッドネットワークにおける QoS を
考慮したルーティング方式を提案する. 提案方式では, チャネルを切り替えることで, 低優先度フローが AP 間の負荷
分散を行い, 高優先度フローは通信品質が劣化してしまう恐れがある場合に限り, チャネルを切り替え, AP を変更す
る. シミュレーションにより, 提案方式の有効性を示す. キーワード
マルチチャネル, 無線ハイブリッドネットワーク, QoS, ルーティング
QoS Routing Method in Multichannel Wireless Hybrid Networks
Atsushi NAGASAKI† , Hiroo SEKIYA† , Shiro SAKATA† , and Kengo YAGYU††
† Graduate School of Advanced Integration Science, Chiba University
1-33, Yayoi-cho, Inage-ku, Chiba, 263-8522 Japan
†† Research Laboratories, NTT DOCOMO, INC.
3-5, Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-8536 Japan
E-mail: nagasaki@graduate.chiba-u.jp, yagyuuk@nttdocomo.co.jp
Abstract In wireless hybrid networks using multichannel, a routing protocol to balance the load among APs (Access Points) has been proposed. In the protocol, the data-receiving nodes switch their channels and associate with
other APs. However, the QoS (Quality of Service) has not been considered yet when various flows concentrate on a
certain AP. This paper proposes a routing protocol considering the QoS in multichannel wireless hybrid networks.
In the proposed protocol, low-priority flows keep a load among the APs by switching the channels. On the other
hand, high-priority flows change the AP by switching the channels only when the quality of the communication is
deteriorated. This paper shows performance evaluations by the network simulation and proves the effectiveness of
the proposed protocol.
Key words Multichannel, Wireless Hybrid Networks, QoS, Routing
1. はじめに
現在の無線ネットワークでは, 複数の AP (Access Point) に
よって広域をカバーすることにより, 通信エリアを拡大してい
る. しかし, 広域をカバーするためには, 非常に多くの AP が必
要となる. そこで, AP 間を有線 LAN (Local Area Network)
で接続し, 無線端末はマルチホップによって AP と通信を行う
ことで, 1 つの AP がより広域をカバーできるようになる. この
ようなネットワークは無線ハイブリッドネットワークと呼ばれ
る [1]– [4]. 無線ハイブリッドネットワークでは, 各 AP に異な
るチャネルを用いることで, 無線端末同士の干渉を抑え, スルー
プットの向上が望める [3]– [4]. しかし, 1 つの AP に異なるアプ
リケーションフローが集中した場合, 各フローの QoS (Quality
of Service) を考慮しなければならない [5]– [7].
QoS を保証するための MAC プロトコルとして, IEEE
802.11e EDCA (Enhanced Distributed Channel Access) [8]
—1—
wired network
wired network
AP1
ch1
Audio
ch2
B
A
Ch2 AP2
AP1 Ch1
AP2
60Kbps
Video
C
B 1000Kbps
A
F
E
F
D
Background
900Kbps
C
図 1 マルチチャネル無線ハイブリッドネットワークの例
E
D
G
(a)
が挙げられる. EDCA では, 優先度の高いパケットを優先して
送信するため, リアルタイム性の高いアプリケーションの通信
品質を保証することができる. しかし高負荷になると, 使用可能
な帯域が減少するため, リアルタイム性の高いアプリケーショ
ンも通信品質が劣化する. このため, 1 つの AP に集中したア
プリケーションフローの QoS を保証するためには, ネットワー
クレイヤにおいて, QoS を考慮したルーティング制御が必要で
ある.
本稿では, マルチチャネル無線ハイブリッドネットワークにお
いて, QoS を考慮したルーティング方式を提案する. 提案方式
では, AP に加わる負荷を分散させるために, 受信端末がチャネ
ルを切り替え, 他の AP からパケットを受信するという手法 [4]
を応用する. リアルタイム性の高いアプリケーションフロー
が可能な限り許容されるように, リアルタイム性の低いアプリ
ケーションの受信端末がチャネルを切り替えて各 AP に分散す
る. 一方リアルタイム性の高いアプリケーションの受信端末は
可能な限りチャネル切り替えを行わず, 通信品質が劣化してし
まう恐れがある場合に限りチャネル切り替えを行い, AP を変
更する. このようにして, リアルタイム性の高いアプリケーショ
ンの通信品質を改善する. シミュレーションにより, 提案方式
の有効性を示す.
2. マルチチャネル無線ハイブリッドネットワーク
図 1 に, マルチチャネルを用いた無線ハイブリッドネットワー
クの例を示す. 図 1 において, 端末 A, B, C, D はチャネル 1 で
AP1 と通信を行い, 端末 E, F はチャネル 2 で AP2 と通信を行
う. したがって, AP1 と AP2 に接続している端末は互いに異
なるチャネルを用いて通信を行うことができるため, 端末同士
の干渉の影響を軽減することができる.
ここで, 1 つの AP に異なるアプリケーションフローが集中
した場合を想定する. 各フローの QoS 保証のために, リアルタ
イム性の高いアプリケーションとリアルタイム性の低いアプリ
ケーションを区別した通信を行う必要がある. そのため, MAC
レイヤに EDCA [8] を適用することが考えられるが, 高負荷に
なると, 使用可能な帯域が減少するため, リアルタイム性の高い
アプリケーションも通信品質が劣化する. したがってルーティ
ングによって, 高負荷の状態を緩和し, リアルタイム性の高いア
プリケーションの通信品質を改善する必要がある.
3. 提案方式
本稿では, マルチチャネル無線ハイブリッドネットワークにお
いて, QoS を考慮したルーティング方式を提案する. 提案方式
で用いるアプリケーションは, バックグラウンド (Background),
Route Table of AP1
dst
A
B
D
G
nexthop
A
B
B
B
hops
1
1
2
3
type
MH
MH
MH
MH
chan
1
1
1
1
total load
60
1000
900
0
admit
0
0
0
0
application
AUDIO
VIDEO
BACKGROUND
path
(b)
dst nexthop
AP1
B
AP2
E
G
G
Route Table of D
hops type chan total load video load
2
PRIM 1
2860
1000
3
AP
2
0
0
1
MH
1
0
0
audio load
60
0
0
path
B AP1
E C AP2
(c)
図2
アプリケーションフローが混在したネットワークシステム
(a) ネットワークトポロジ (b) AP1 のルーティングテーブル
(c) 端末 D のルーティングテーブル
ビデオ (Video), オーディオ (Audio) の 3 種類である.
提案方式では, 最もリアルタイム性の低いバックグラウンド
の受信端末がチャネルを切り替え, 各 AP に分散する. こうす
ることで, 新たに接続するリアルタイム性の高いビデオやオー
ディオフローの許容数が増加する. 一方, リアルタイム性の要求
されるビデオの受信端末は, 可能な限りチャネル切り替えを行
わない. これは頻繁にチャネルを切り替えて AP を変更するこ
とによって, 通信品質が劣化することを避けるためである. し
かし AP に接続するフローが増加し, 高負荷になった場合, ビ
デオの通信品質は劣化し始める. このときビデオの受信端末は,
チャネルを切り替えて AP を変更し, 通信品質を改善する. 最
もリアルタイム性の高いオーディオの受信端末は, パケットロ
スや遅延を防ぐため, チャネル切り替えを行わない. この場合,
バックグラウンドフローやビデオフローが他の AP に移動する
ため, オーディオフローのトラヒックが使用可能な帯域に収ま
れば, オーディオフローの通信品質は常に維持される.
このように, バックグラウンドフローは各 AP に分散され, ビ
デオフローは通信品質が劣化してしまう場合にチャネル切替を
行う. しかしそれでもビデオやオーディオフローなど, リアル
タイム性の高いアプリケーションフローがバックグラウンドに
よる干渉を受けてしまう場合がある. その場合, AP において
バックグラウンドの送信抑制を行うことで, リアルタイムアプ
リケーションの通信品質を維持する.
図 2(a) に, 提案方式において扱うネットワークシステムの例
を示す. AP に異なるアプリケーションフローが混在する場合
を想定し, ネットワークに参加する全端末はあらかじめ AP ま
での経路を確立している. また, 提案方式で扱うルーティング
テーブル, 負荷の算出方法及び伝達方法には, 文献 [4] の手法を
応用する.
—2—
3. 1 ルーティングテーブル
図 2(b), (c) に, 図 2(a) のネットワークにおける AP1 と端末
D のルーティングテーブルをそれぞれ示す. 図 2(b), (c) におい
て, 太字で示したフィールドは提案方式で新たに追加したフィー
ルドである. dst はあて先端末, nexthop は次ホップ端末, hops
は各あて先端末までのホップ数を示している. また, type はあ
て先端末が AP または無線移動端末 (MH) かどうかを示してい
る. ここで, 図 2(c) において, あて先が AP1 となっているエン
トリの type が PRIM と示されている. これは, 最優先経路を
示しており, この経路を用いてデータ通信を行う. chan は経路
が用いているチャネル, path は経路上に存在する端末を示す.
AP1 のルーティングテーブルにおける total load は, 各あて
先端末に対するトラヒック負荷を表す. 各 AP はあて先端末ま
でのホップ数と, total load に記録された負荷に基づいて AP 全
体にかかる負荷を算出する. admit はそのエントリが有効であ
るかどうかを示す. もしエントリが有効であれば admit には 0
を挿入し, 無効であれば 1 を挿入する. AP は admit に 1 を挿
入することで, そのエントリのあて先端末へのパケット送信を
控えることができる. application はアプリケーションフローの
タイプ (BACKGROUND, VIDEO, AUDIO) を示す.
一方端末 D のルーティングテーブルにおける total load は,
各あて先 AP における合計負荷, video load 及び audio load は
total load 中のビデオ負荷とオーディオ負荷を表す. これらの
負荷情報は各 AP から定期的に伝達され, 常に更新される.
3. 2 負荷の算出方法
提案方式では, 次式を用いて AP に加わる合計負荷 LAP を算
出する [4].
LAP =
∑
(hi × li )
(1)
i
ここで, i は AP に接続された端末数を表し, hi は AP から端末
i までのホップ数, li は端末 i への負荷を示している. すなわち,
各端末への負荷に重みとしてホップ数を掛け, 足し合わせたも
のを AP の合計負荷として定義する.
提案方式では, バックグラウンド, ビデオ, オーディオの 3 種
類のアプリケーションを扱う. それぞれのアプリケーションの
合計負荷に基づき, AP を変更し, QoS を改善する. そのため,
各 AP におけるアプリケーションごとの合計負荷を算出する.
AP は各あて先端末が要求するアプリケーションと, その端末
へのトラヒック負荷を記録することができる. これにより, ア
プリケーションフローごとの負荷を (1) を用いて算出すること
ができる. アプリケーションフローごとに算出した負荷情報は,
AP のルーティングテーブルにおける total load フィールドに
記録される. AP は total load フィールドに記録された負荷情
報を, アプリケーションごとに分けて足し合わせ, 各無線端末に
伝達する.
3. 3 負荷情報の伝達方法
AP が算出した負荷情報は, HELLO パケットにのせて各無線
端末に伝達される. HELLO パケットは各 AP において定期的
に生成される. 生成された HELLO パケットはブロードキャス
トされ, 周囲の端末が受信することで AP における負荷情報を
得ることができる. このとき, チャネルを切り替えながら 1 回
ずつブロードキャストを行う. こうすることで, 様々なチャネ
ルに設定された端末に各 AP の負荷情報を伝達することが可能
になる.
HELLO パケットを受信した端末は, 自身のルーティングテー
Start
(2)
Tswitch <= 0?
No
Yes
(3)
Total load of VIDEO
and AUDIO on associated
NoAP is higher than θ?
No
Yes
(4)
If associate with other
AP, total load of VIDEO and
AUDIO of its AP is
higher than θ?
Start
No
Yes
No
(1)
No
Total load of associated
AP is higher than that
of other AP?
Yes
(5)
Tswitch = 0?
Yes
Set
Tswitch
Associate with other AP
with lower load
by switching channel
Associate with other AP
with lower load
by switching channel
Discard Tswitch ( Tswitch = -1)
図3
End
End
(a)
(b)
ルーティングアルゴリズムのフローチャート
(a) バックグラウンド受信端末の動作 (b) ビデオ受信端末の動作
ブルにおける type フィールドが最優先経路 (PRIM) であるエン
トリを参照する. もしそのエントリの次ホップ端末が, HELLO
パケットをブロードキャストした端末であれば, 再度 HELLO
パケットをブロードキャストする. このときもチャネルごとに
1 回ずつブロードキャストを行う. また, HELLO パケットの
受信端末は, 自身のルーティングテーブルにおける total load,
video load, audio load フィールドの負荷情報を更新する.
一方 HELLO パケットを受信しても, ルーティングテーブル
に, HELLO パケットの送信端末を経由した AP までの経路が
存在しない場合がある. このとき, 新たに HELLO パケットを
生成した AP までの経路をルーティングテーブルに加える. し
たがって, 各端末は HELLO パケットによって負荷情報を取得
しつつ, AP まで新たな経路を構築することができる.
3. 4 ルーティングアルゴリズム
図 3 に, 提案方式におけるルーティングアルゴリズムのフロー
チャートを示す. 提案方式では, 受信するアプリケーションに
よって動作が異なる. したがって, 1) バックグラウンド受信端
末の動作, 2) ビデオ受信端末の動作, 3) オーディオ受信端末の
動作についてそれぞれ説明する.
1) バックグラウンド受信端末の動作
図 3(a) に, バックグラウンド受信端末の動作を示す. バック
グラウンド受信端末は, 分岐 (1) で自身の AP の合計負荷と他
の AP の合計負荷をルーティングテーブルの total load フィー
ルドから取得し, 比較する. このとき, 別の AP の方が負荷が低
ければ, チャネルを切り替え, 負荷の低い AP に移動する. この
ようにバックグラウンド受信端末は, AP 間の負荷のバランスを
とるためにチャネル切り替えを行う. これは文献 [4] で提案され
—3—
ている AP 間の負荷分散ルーティングと同様の手順である. リ
アルタイム性の低いバックグランドフローが, 各 AP に分散す
ることで, 新たに接続するリアルタイム性の高いビデオやオー
ディオフローの許容数が増加する. また, バックグラウンドフ
ローによる干渉が軽減し, 通信品質を改善することができる.
2) ビデオ受信端末の動作
図 3(b) に, ビデオ受信端末の動作を示す. まず, 各受信端末
は非同期に動作するタイマーである Tswitch を有している. 受
信端末がチャネルを切り替えると判断した場合に, ランダムな待
ち時間が Tswitch に設定される. Tswitch はチャネルを切り替え
るまでの待ち時間を意味し, その後チャネル切り替えを行うこ
とができる. こうすることによって, 複数の端末が同時にチャネ
ル切り替えを行い, AP の負荷が急激に変化しないようにする.
分岐 (2) では既に Tswitch に値が設定されているか, つまり
現在, チャネルを切り替えるまで待機している状態なのかどう
かを判定する. もしチャネルを切り替えるまで待機している状
態でなければ, 分岐 (3) において, 接続している AP のビデオと
オーディオの合計負荷が閾値 θ を超えているか調査する. ビデ
オは, バックグラウンドに比べてリアルタイム性が高く, 頻繁に
チャネル切り替えを行うと通信品質が劣化する可能性がある.
そのため, AP における負荷に閾値 θ を設定し, ビデオとオー
ディオの合計負荷が θ を上回る場合に限りチャネルを切り替え,
AP を変更する. ここで, AP がバックグラウンドの送信を抑制
する可能性があるため, θ はビデオとオーディオの合計負荷に
基づいて定められ, バックグラウンドの合計負荷は考慮しない.
したがって, ビデオとオーディオの合計負荷が θ を超えていれ
ば, リアルタイム性の高いアプリケーションの通信品質を維持
することができない状況である. このため, ビデオ受信端末は,
現在 AP に接続しているビデオフローの通信品質が劣化しない
ように, AP の変更を検討する.
分岐 (4) では, 自身が移動した後, 移動先の AP におけるビデ
オとオーディオの合計負荷が θ を超えないかどうか判定する.
ここで移動先の AP のビデオとオーディオの合計負荷が θ を超
える場合は, チャネル切り替えを行わない. これは切り替え後,
移動先の AP の負荷が θ を超えると, 使用可能な帯域が減少す
るため, その AP に接続しているビデオやオーディオフローの
通信品質が劣化するからである. θ を超えなければ, AP を変更
しても, ビデオやオーディオフローの通信品質を維持できると
判断する. ここで, 分岐 (5) において, 現在 Tswitch は設定され
ていないため, Tswitch にランダムな待ち時間を設定し, 待ち時
間が終了するまでチャネル切り替えを行わない. Tswitch が設定
された端末は, その間フローチャートにおける分岐 (3), (4) の
処理は行わず, AP から送信されるパケットを受信するだけで
ある.
一方, 分岐 (2) において, Tswitch に値が設定されている場合
を考える. もし Tswitch が 0 でなければ, チャネル切り替えまで
の待ち時間が残っていると判断する. しかし, Tswitch が 0 であ
る場合, チャネル切り替えまでの待ち時間が終了したとみなす.
このとき, 再び前述と同じ動作を行い, AP を変更可能であるか
どうか判定する. Tswitch で設定された時間が終了するまでチャ
ネルを切り替えないため, その間に他の端末がチャネルを切り
替えて AP を変更する可能性がある. そのため, チャネルを切
り替える前に再び負荷の状態を調査する必要がある. その結果,
まだ切り替える必要があれば AP を変更し, 切り替える必要が
なければ, Tswitch を破棄する. これにより, ビデオ受信端末が
同時にチャネルを切り替え, 接続先の AP の負荷が増加し, 使
AP2
AP3
AP1
AP4
図 4 シミュレーショントポロジ
用可能な帯域が減少することによる通信品質の劣化を防ぐこと
ができる.
3) オーディオ受信端末の動作
頻繁なチャネル切り替えによるパケットロスの発生及び遅延
の増大を防ぐため, オーディオ受信端末はチャネル切り替えを
行わない. これは, バックグラウンドやビデオフローの AP の
変更によって, AP は常に一定の負荷に保たれるため, オーディ
オの通信品質に影響がないからである.
3. 5 AP におけるバックグラウンドの送信抑制
AP にビデオフローが存在し, AP に接続する全フローの合計
負荷が閾値 θ を超えた場合, AP はバックグラウンドの送信を抑
制する. これは, ビデオフローがバックグラウンドフローによる
干渉により, スループットの低下, 遅延の増大を引き起こすから
である. そこで, AP はビデオフローの通信品質を劣化させない
ために, 全フローの合計負荷が θ を下回るまでバックグラウン
ドフローを切断する. θ はビデオフローが帯域を限界まで使用
できる閾値であるため, 合計負荷がこの値を下回れば, ビデオフ
ローの通信品質が劣化することはない. また, 切断する際, ルー
ティングテーブルにおける切断対象のエントリの admit フィー
ルドに 1 を挿入する. これにより, AP がパケットを送信する
際, そのエントリが無効になっていることを認知できる. また,
送信を抑制されたバックグラウンドフローは, AP における負
荷が軽減した場合に, その AP から再び送信が開始される.
4. シミュレーション評価
図 4 に, シミュレーショントポロジを示す. 各 AP には互いに
異なるチャネルを割り当て, その周辺に端末をランダムに配置
する. データの種類はバックグラウンド, ビデオ, オーディオの
3 種類とし, 受信端末は AP1 の周辺からランダムに選択する.
表 1 にシミュレーション諸元を示す. MAC レイヤには IEEE
802.11e EDCA を適用し, バックグラウンドとビデオ送信時の
み RTS/CTS (Request to Send/Clear to Send) を用いる. ビ
デオ受信端末において, チャネル切り替えの判断基準である閾
値 θ が小さい場合, まだ帯域に余裕があるため, すぐにチャネル
を切り替える必要はない. このため, チャネル切り替え待ち時
間を示す Tswitch に設定される値は大きくてもよい. 逆に, θ が
大きい場合は帯域に余裕がないため, すぐにチャネルを切り替
える必要がある. したがって, Tswitch には小さい値を設定する
ことが望ましい. これは, QoS を保証する最適な θ 及び Tswitch
—4—
表 1 シミュレーション諸元
Simulation area
1000 m ×1000 m
Total simulation time
300 seconds
Physical layer
12Mbps IEEE 802.11a
MAC layer
IEEE 802.11e EDCA
with RTS/CTS
BACKGROUND packet size 1500 bytes
VIDEO packet size
1280 bytes
AUDIO packet size
160 bytes
BACKGROUND flow rate
0.9375 Mbps
VIDEO flow rate
1.0 Mbps
AUDIO flow rate
0.0625 Mbps
Transmission range
250 m
Threshold θ
7.2 Mbps
が存在することを示している.
本稿では予備実験に基づき, 閾値 θ を 7.2Mbps とし, Tswitch
は 3 秒から 10 秒の間でランダムに設定する. 初期フローは,
バックグラウンドフローを 4 本, ビデオフローを 1 本, オーディ
オフローを 1 本とする. 20 秒ごとに 1 本ずつビデオフローを追
加することで, フローが増加し, 高負荷になった場合の提案方式
の動作, 及びその有効性を確認する.
4. 1 各アプリケーションの総スループットの評価
図 5(a), (c), (e) に, それぞれ各手法における時間に対するバッ
クグラウンド, ビデオ, オーディオの総スループットを示す. こ
こで比較するプロトコルは, マルチチャネルプロトコル (MCP),
文献 [4] における負荷分散ルーティング (Load-Balancing), 提案
方式 (Proposed), の 3 つである. MCP とは, マルチチャネル無
線ハイブリッドネットワークおいて, チャネルの切り替えを行わ
ず, 近傍の AP のみと通信を行う方式である. また提案方式にお
いて, AP でバックグラウンドフローの送信抑制 (Transmission
Control) を行わないもの (TC-off), 及び送信抑制を行うもの
(TC-on) を比較する. ただし, すべてのプロトコルにおいて,
MAC レイヤに EDCA を適用する.
図 5(a), (c), (e) から, MCP ではバックグラウンドとビデオ
の両方の総スループットが低下している. 一方, 負荷分散ルー
ティングでは, すべてのアプリケーションにおいて, スループッ
ト変動が同時にみられる. これは AP 間の負荷を均一にするた
めに, アプリケーションの種類に関係なく頻繁にチャネルを切
り替えるためである. そのためリアルタイム性など, 通信品質
の違いを意識した差別化が実現されていない.
これらに対し, 提案方式 (TC-on) では, バックグラウンドの
総スループットは低下するが, ビデオの総スループットを安定
して増加させることができている. AP においてビデオとオー
ディオの合計負荷に閾値を設けることで, ビデオ受信端末は可
能な限りチャネル切り替えを行わず, 現在の AP に留まる. そ
の結果, 負荷分散ルーティングのように頻繁なチャネル切り替
えによるスループット変動は発生せず, 許容したビデオフロー
の通信品質を改善することができている.
また, 提案方式において, バックグラウンドの送信抑制を行う
(TC-on) ことによる効果を, 行わないもの (TC-off) と比較して
検証する. 図 5(a), (b) から, バックグラウンドの送信抑制を行
わない場合, バックグラウンドとビデオの両方において負荷分
散ルーティングと同様のスループット変動がみられる. しかし,
バックグラウンドの送信抑制行うと, バックグラウンドの総ス
ループットは低下するが, その分許容できるビデオフロー数が
増加し, 安定した通信を行うことができる. このことから, バッ
クグラウンドの送信抑制によってビデオフローの QoS が改善
できていることがわかる.
4. 2 各アプリケーションの平均遅延の評価
図 5(b), (d), (f) に, それぞれ各手法における時間に対する
バックグラウンド, ビデオ, オーディオの平均遅延を示す. 一般
に, リアルタイム片方向ビデオ通信における端末間の許容遅延
は, 10 秒以下とされている [9]. 図 5(b) から, 提案方式 (TC-on)
以外のプロトコルは, 高負荷になると遅延が 10 秒を超える. 特
に負荷分散ルーティングや, バックグランドの送信抑制を行わ
ない提案方式 (TC-off) では遅延のばらつきが顕著である. これ
らは, 頻繁なチャネル切り替えにより, AP に加わる負荷が常に
変動する. そのため, 負荷が軽減された場合はパケットが一気
に送信され, 遅延が緩和される. 逆に負荷が高くなった場合は,
キューイングされる時間が長くなるため, 遅延が増加してしま
う. リアルタイム性の要求されるビデオ通信にとって, 上記の
ような遅延の変動は望ましくない.
一方提案方式 (TC-on) では, ビデオの遅延は 100 ミリ秒以下
に抑えられていることがわかる. 提案方式 (TC-on) において,
ビデオ受信端末は通信品質が劣化する恐れがある場合, つまり
使用可能な帯域が残されていない場合にのみ, チャネル切り替
えを行い AP を変更する. また, バックグラウンドの送信抑制
により使用可能な帯域が増加するため, 同じ AP に接続するビ
デオフローの通信品質は向上する. その結果, ビデオの遅延が
抑えられ, QoS が改善される.
図 5(f) から, すべてのプロトコルにおいてオーディオは 5 ミ
リ秒以下の安定した通信を行っている. これはすべてのプロト
コルにおいて, MAC レイヤに EDCA を適用しているため, 優
先度の最も高いオーディオが常に優先して送信されるからで
ある. しかし, その中でも, 提案方式 (TC-on) はほとんど遅延
の変動がみられず, 最も安定した通信を行っている. 提案方式
(TC-on) では, バックグラウンドやビデオの受信端末が他の AP
への切り替えを行う. その結果, 使用可能な帯域が増加するた
め, オーディオ受信端末は, チャネル切り替えを行わずにその通
信品質を維持することができる.
4. 3 異なる端末配置での各アプリケーションにおけるスルー
プットと遅延の平均及び分散の評価
表 2, 3 に, 30 通りの端末配置でシミュレーションを行った場
合の, 各アプリケーションにおける平均スループット, 平均遅延
及びその分散を示す. 表 2, 3 から, MCP や負荷分散ルーティ
ングよりも, 提案方式の方がビデオの平均スループットが高く,
平均遅延も低いことがわかる. さらに, オーディオの遅延も提
案方式が最も低い. これは提案方式が, 様々な端末配置に対し
て, 他の 2 つの方式よりも柔軟に対応できることを示しており,
ビデオやオーディオにおけるスループットや, 遅延の分散から
みても明らかである.
5. まとめ
本稿では, マルチチャネル無線ハイブリッドネットワークに
おける QoS を考慮したルーティング方式を提案した. 提案方式
では, チャネルを切り替えることで, 低優先度フローが AP 間の
負荷分散を行い, 高優先度フローは通信品質が劣化してしまう
恐れがある場合に限り, チャネルを切り替え, AP を変更する.
シミュレーションにより, 提案方式の有効性を示した.
文
献
[1] M. J. Miller, W. D. List and N. H. Vaidya, “A hybrid network implementation to extend infrastructure reach,” Uni-
—5—
MCP
Load-Balancing
Proposed (TC-off)
Proposed (TC-on)
6
5
4
3
2
1
0
0
50
100
150
200
250
14
MCP
Load-Balancing
Proposed (TC-off)
Proposed (TC-on)
12
10
8
6
4
2
0
0
300
50
100
150
200
250
3
10
2
10
10
50
100
150
MCP
Load-Balancing
Proposed (TC-off)
Proposed (TC-on)
0.02
0.01
0
50
100
200
250
300
150
200
300
250
300
(e)
MCP
Load-Balancing
Proposed (TC-off)
Proposed
(TC-on)
4
10
3
10
2
10
10
MCP
Load-Balancing
Proposed (TC-off)
Proposed (TC-on)
4
3
2
1
0
0
50
100
150
200
250
300
0
50
100
150
200
Time [sec]
Time [sec]
Time [sec]
(b)
(d)
(f)
図5
250
5
1
1
0
0.03
0
Average Delay [msec]
Average Delay [msec]
4
10
0.04
Time [sec]
10
MCP
Load-Balancing
Proposed (TC-off)
Proposed
(TC-on)
5
0.05
300
5
10
0.06
(c)
(a)
6
10
0.07
Time [sec]
Time [sec]
Average Delay [msec]
Total Throughput [Mbps]
Total Throughput [Mbps]
Total Throughput [Mbps]
7
各アプリケーションの総スループット及び平均遅延の時間変化
(a), (b) バックグラウンドの総スループット及び平均遅延 (c), (d) ビデオの総スループッ
ト及び平均遅延 (e), (f) オーディオの総スループット及び平均遅延
表 2 異なる端末配置における各アプリケーションのスループットの平均及び分散
Protocol
Throughput[Mbps]
Background
Video
Audio
Average
Variance
Average
Variance
Average
Variance
MCP
0.551
1.38 ×10−3
0.577
8.99 ×10−4
0.062
6.17 ×10−9
Load-Balancing
0.871
3.28 ×10−3
0.948
2.03 ×10−3
0.061
4.25 ×10−6
−3
−4
Proposed (TC-on)
0.593
7.57 ×10
0.987
4.20 ×10
0.062
9.08 ×10−9
表 3 異なる端末配置における各アプリケーションの遅延の平均及び分散
Protocol
Delay[msec]
Background
Video
Audio
Average Variance Average Variance Average
Variance
MCP
178.767 9.16 ×103 286.670 7.43 ×103
1.248
5.98 ×10−2
Load-Balancing
81.395 2.20 ×103 96.584 3.25 ×103
1.382
1.30 ×10−1
Proposed (TC-on) 81.614 3.48 ×103 47.280 1.53 ×103
0.786
1.09 ×10−1
[2]
[3]
[4]
[5]
versity of Illinois, Champaign-Urbana, Tech. Rep., January
2003.
L. K. Law, S. V. Krishnamurthy and M. Faloutsos, “Capacity of hybrid cellular-ad hoc data networks,” in Proc. IEEE
Int. Conf. INFOCOM, pp. 1606-1614, April. 2008.
J. So and N. H. Vaidya, “Routing and channel assignment
in multi-channel multi-hop wireless networks with single-nic
devices,” Coordinated Sci. Lab. Tech. Rep., Univ. Illinois at
Urbana-Champaign, Urbana, IL, Dec. 2004.
J. So and N. H. Vaidya, “Load-balancing routing in multichannel hybrid wireless networks with single network interface,” IEEE Trans. Vehicular Technology, vol. 56, no. 1,
January 2007.
B. Park, W. Lee, S. Ahn and S. Ahn, “QoS-driven wireless broadband home networking based on multihop wireless mesh networks,” IEEE Trans. Consumer Electronics,
vol. 52, no. 4, November 2006.
[6] C. Liu, Y. Shu, L. Zhang and M. Ma, “Backup Routing for
Multimedia Transmissions over Mesh Networks,” in Proc.
IEEE Int. Conf. ICC ‘07, pp. 3829-3834, June 2007.
[7] M. Malli, Q. Ni, T. Turletti and C. Barakat, “Adaptive
fair channel allocation for QoS enhancement in IEEE 802.11
wireless LANs,” in Proc. IEEE Int. Conf. Commun. , vol.
6, pp. 3470-3475, Paris, France, June 2004.
[8] IEEE Std 802.11e-2005, “Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY) specifications. Amendment 8: Medium Access Control (MAC)
Quality of Service Enhancements.”
[9] ITU-T Recommendation G.1010, “End-user multimedia
QoS categories”, November 2001.
—6—

Download Report