WIDE Technical-Report in 2008

無線マルチホップ通信を用いた合宿バックボーンネットワーク
構築実験
wide-tr-keiichi-camp200709-wmn-02.pdf

WIDE Project : http://www.wide.ad.jp/

If you have any comments on this document, please contact to ad@wide.ad.jp

無線マルチホップ通信を用いた合宿バックボーンネット
ワーク構築実験島 慶一

1宇夫 陽次朗∗
河村 悠生‡

藤田 祥
飯塚 拓郎§

安本 直史
田中 陽介†
堀川 大輔¶

背景
災害地での救助活動にロボット, コンピュータ技術を利用する研究が近年活発に進められている.

従来, 被災地での情報収集作業は, 生身の人間が危険な地域に乗り込んでいく必要があった. このような現場は, 特に災害が発生した直後は危険であり, 二次災害を引き起こす可能性が高い. また
自然災害だけでなく, 近年ではテロなどの人為的な災害の発生も考えられ, その手段として使われる爆発物や有毒ガスなどは, 被災者のみならず救助者の生命をも危険にさらす可能性がある.
この問題を解決する手段として, 被災地域の情報収集を救助ロボットを用いて行う試みが続けられている [1]. 救助ロボットを用いて情報を事前に把握することで, 被災者が存在しない地域に救助者が進入していく危険を減らしたり, 救助者の生命に関わるような危険な場所をあらかじめ知ることができるようになる.
現在の多くの救助ロボットは有線接続, あるいは短距離無線通信を用いて遠隔操作される設計になっている. しかしながら, このような接続方式では, ロボット運用者が救助ロボットとともに危険な区域に進入していかなければならない.
我々は, この問題をインターネット技術を用いて解決することを試みる. 既存の通信インフラストラクチャが存在しない, あるいは破壊されて利用できない状況であっても, 短期間にネットワークを構築し, そのネットワークを用いて救助ロボットの操作, および被災地の情報収集を可能とする技術を実現する. 有線ネットワークの敷設は困難と考えられるため, ネットワーク構築の基本は無線ネットワークとなる. 被災地が屋外ならば, 広域の無線通信技術の利用も考えられるが, 屋内や地下での被災地での運用を考慮にいれると, 短距離の無線通信を組み合わせたマルチホップ無線通信がより適切であると考えられる. また, 被災地の地理形状は複雑になっていることが予想されるため, ネットワークの構成や規模は被災状況に応じて柔軟に対応できる能力を持ち, かつ必要に応じて拡大できなければならない. これらの作業は, それまで構築したネットワークを足がかりに, 救助ロボットが新たな無線基地局を増設することで対応できると考える. 我々は, このような被災地救助ロボット用のネットワークを Robohoc ネットワークと名付けた. Robohoc ネットワークの要求項目に関しては,[2] を参照してほしい.

∗ 株式会社インターネットイニシアティブ† 東京大学‡ 慶応義塾大学§ 電気通信大学¶ 株式会社インターネットオートモビリティ研究所

1

2

実験の目的
Robohoc ネットワークを実用的に運用するためには柔軟な無線アクセスポイントの配置, 通信可能距離の確保, 障害対応, 通信品質の確保など, 様々な要件を満たす必要がある [2]. 本実験では,Robohoc ネットワークの基礎となる, マルチホップ無線ネットワークの運用経験蓄積と基礎データの計測を目的とする.
具体的には, 複数の無線ネットワークインターフェースを装備した無線ルータを製作し, それらをメッシュ上に並べ, 既存の経路制御プロトコルでパケットの流れを制御した上でパケット転送性能を計測する.

3

問題点
マルチホップ無線ネットワークを構築する場合, 各ノード間の通信チャネルとして同一チャネルを用いる場合と, 異なるチャネルを用いる場合に分類できる. MANET (Mobile Adhoc Network)のように, 無線メッシュネットワークを構成しているノードが移動する場合, 同一チャネルを用いた通信路を前提とすることが多い. これは, MANET が自立分散ネットワークであり, かつ移動によってノード間の近接度が変化するため, 状況に応じて通信範囲に含まれるノードが出現と消滅を繰り返すためである. 各ノードが異なるチャネルを用いて通信していると, ノードが近接した場合の通信確立手順が複雑になる. これに対して, IEEE802.15 などの省電力無線メッシュネットワー
クなどでは, ノード間の通信チャネルは通信時にネゴシエーションによって決定される. このようなネットワークにはコーディネータと呼ばれるノードが存在し, ある 2 点間の通信路の確立はコー
ディネータによって管理される. メッシュネットワーク全体のトポロジはコーディネータが把握しており, マルチホップ通信の経路上のタイムスロットがコーディネータによって決定されるため, 事前に通信チャネルの情報を共有しておく必要がない.
我々が提案する Robohoc ネットワークは, 自立分散して運用されることを目標としている. それと同時に, 被災地からの情報をできるだけ多く獲得するために, 広い帯域も必要としている. そのため, データリンク層としては IEEE802.11 系の広帯域無線通信路を選択した. IEEE802.11 技術を用いてメッシュネットワークを構成する場合, 同一チャネルを利用することが多いが, すべてのノードが同一チャネルを用いる設計では, チャネル干渉により, どこかのリンクの通信が, その通信とは無関係な他のリンクの通信を抑制してしまうと考えたため, 自立分散運用を維持しつつも, ノード間の通信に複数の無線チャネルを用いることができるように設計しようとしている.
過去 IEEE802.11a をデータリンク層として行った実験では, 単純に複数の無線ネットワークインターフェースを装備した機材でネットワークを構成した場合, たとえチャネルが異なっていても無線リンク間で干渉が発生し, スループットが低下する現象が確認されている. 図 1 に事前実験時のネットワーク構成を示す.
図 1 のトポロジを用いてスループットを計測した結果が図 2 である.
各無線区間には, 802.11a で利用できる異なるチャネルを割り当ててある. この状態で, AP1 を始点とし, AP2 から AP7 まで終点とした状態で netperf による UDP のスループット測定を実施した. その結果, 無線区間がひとつしかない場合 (1 ホップ) は実効帯域として 18Mbps 近い転送性能が出ているが, ホップ数が増えるに従って転送性能が落ちていく.
調査の結果, 転送性能低下の原因は, チャネル間の無線干渉の問題であるらしいことが判明してきた. 図 1 に示している通り, 各無線リンクは異なるチャネルを利用しているものの, 各ノードに実装されている無線ネットワークインターフェースの距離が近いため (近接して実装された PCI バ2• 2007-2./014.234• !"#$%&5!"##67"89:$%&;<=*3>+,?@9• UDP:*@9
JKLM
HN

ABC

ABD

JKLM
HF

ABE

JKLM
EH

JKLM
FN

ABF

JKLM
FF

ABG

ABH

JKLM
FO

ABI!"#$%&'()*+,

図 1: 事前実験で用いたトポロジ. 7 台の無線ノードを一列に接続した直線的なトポロジを構成. 各
無線リンクには異なるチャネルが割り当てられている.

3$%&-./+,01
234

UVWX

– 1$%&: 18Mbps56– 6$%&: 2.7Mbps56

4$%&-./7238
9:;<=>89;?
@A4BC?0DEF
7GHIJ0K;@L$%&M0NCO
PQ*RS7/J9;
T;

$%&M

図 2: 事前実験結果. 無線リンクが 2 つになると, 1 つの時と比較して転送性能がおよそ半分に落ちている. 以後, ホップ数が増えるごとに著しい転送性能劣化がみられる.
スブリッジに 4 つの miniPCI 型無線ネットワークインターフェースを装備), 他チャネルの送信電波をノイズとして検出し, その結果, パケット転送時の性能低下につながっていると考えられる.
そこで本実験では, 異なるチャネル間の干渉を抑えるため, 無線ノードのアンテナを無指向性から指向性に変更し, 実効転送性能の向上を目指す.

4ネットワーク構成
本実験で利用した無線ノードの写真を図 3 に, ノードの仕様概要を表 1 に示す.
事前実験で判明した問題に対応するため, 今回無線ノード間は Corega の指向性アンテナ (CG-WLANT02I, 図 4) を用いた.
無線メッシュネットワークは合宿地のプレナリ部屋に敷設した. プレナリ部屋のバックボーントポロジを図 5 に示す. 各無線ノードは IPv4/IPv6 の両方をサポートし, 3 つの無線ネットワークイ3図 3: 無線ノード

CPUPentium M 1.2Ghz

Memory512MB

NIC

Atheros (miniPCI) x 4OS

NetBSD 4 に FreeBSD の Atheros ドライバを組み込んだもの
表 1: 無線ノードの構成

ンターフェース (rh4 に関しては 2 つ) で他の無線ノードと接続している. 無線ノード間の通信にはIEEE802.11a を用いた. 各無線リンクのチャネルはなるべく重ならないように調整したが, リンクの総数が 10 となっており, 利用できる 802.11a のチャネル数 (36, 40, 44, 48, 52, 56, 60, 64 の 8 つ)を超えているため, 36 と 64 チャネルは 2 カ所で用いられている.
各リンクは IPv6 ではリンクローカル・アドレスを用い, IPv4 では 203.178.158.0/26 から切り出した/30 のネットワークを用いてリンク間通信を実現している. 参加者が利用するネットワークは,各無線ノードの 4 つ目の無線ネットワークインターフェースを IEEE802.11b/g で運用して提供した. なお, 実験の過程で, 802.11g をアクセスポイントモードとして運用している際に無線ノードが異常終了してしまう問題が発見されたため, 実験後半は 802.11b のみの運用に移行している.
経路制御は, 初日は RIPng と RIPv2 で, 二日目以降は OSPFv3 を用いた.
インターネットへの接続は無線ノード rh2 のイーサネットインターフェース経由で実現した. よって, このトポロジでの最大ホップ数は無線ノード rh1 から rh2 へ至る 3 ホップということになる.

4

図 4: 指向性アンテナ (Corega CG-WLANT02I)

5

考察
図 5, 図 6 のトポロジでの転送性能計測結果を図 7 および図 8 に示す.
図 7 は無線ノード rh1 から他の無線ノード rh3, rh2, rh4 に対して netperf で TCP 転送性能を計測したときの結果である. 事前実験の結果と異なり, ホップ数が増加しても転送性能がほとんど低下していないことが確認された. また, 事前実験で得られた転送性能 (およそ 18Mbps) よりも, 本
実験でのスループットの方が向上している. これは, 指向性アンテナを用いたことによる無線リンクの高品質化や, 環境の変化 (事前実験は無線ノイズの多いオフィス内で実施された) が影響していると考えられる.
図 8 は, 無線ノード rh1 に IEEE802.11g を用いて接続したノート PC から, 無線ノード rh1, rh3,rh2, rh4 に対して netperf を用いて TCP 転送性能を計測した結果である. 無線ノード間の通信 (図7) の場合と異なり, 計測結果にばらつきがみられる. また, IEEE802.11g の実効転送性能として予想される値 (20Mbps 以上) を大きく下回る値が計測されている. 性能がでない原因は無線ノードのアクセスポイント機能の実装の問題ではないかと推測される. その後の解析で今回利用した Atheros
カードの hostap モードでは送信時のアンテナポートがランダムに切り替わってしまっていることが判明した．従来のハードウェア構成では２つあるアンテナポートの１つにしかアンテナが付いていなかった為，相当数のフレームがアンテナの付いていないポートから送出されパケットロスを起こしていたはずである．

5

AP interface prefixes:
2001:200:0:ff1a::/64
203.178.158.0/26

rh0
ath1.5/30

SSID: robohoc0-1
Channel: 64

ath0.10/30

rh4

rh5
ath1
.26/30

SSID: robohoc5-6
Channel: 60
txpower 12
ath2
ath2
:6::4/128.37/30.38/30ath1.30/30

SSID: robohoc2-4
Channel: 56
txpower 12

SSID: robohoc1-6
Channel: 44
txpower 12
ath0.18/30
SSID: robohoc1-3
Channel: 36
txpower 12

rh6
ath1.34/30

SSID: robohoc3-6
Channel: 48
txpower 12

SSID: robohoc2-5
Channel: 40
txpower 12

ath0
ath2 .14/30.33/30

ath2.29/30

ath1.25/30
rh2

rh1

ath2 ath1.17/30 .13/30

SSID: robohoc0-5
Channel: 52
txpower 12

ath0.6/30

fxp0.41/30

ath0.2/30

ath2.9/30

SSID: robohoc0-4
Channel: 36
txpower 12ath2
not used

ath0.1/30

SSID: robohoc2-3
Channel: 64
txpower 20

ath0.21/30

ath1.22/30

rh3

Internet Gateway

図 5: プレナリ部屋バックボーントポロジの設定. 各無線リンクは IEEE802.11a を用いて構成. 各リンクに異なる無線チャネルを割り当てることで干渉を軽減.

6結論
本実験は 被災地救助ロボットネットワーク (Robohoc ネットワーク) の実現に必要な, 無線メッシュネットワークの運用経験の蓄積と, 基礎データの取得を目的として実施した. 事前実験の結果から, 単純に無線ネットワークインターフェースを複数装備した機材を無線ノードとして利用した
場合には, マルチホップ通信において著しい性能劣化がみられることがわかっていた. その原因と考えられた異なるチャネル間の影響を軽減するため, 指向性アンテナを用いて無線ノード間通信を実現した. その結果, マルチホップ通信での性能が向上することが確認された.
今後は, Robohoc ネットワークを現実のものとするための, 自動ネットワーク設定技術, 容易なネットワーク拡張技術, 耐障害性技術などを実現していく.

参考文献[1] B. Shah and H. Choset, “Survey on Urban Search and Rescue Robots,” Journal of theRobotics Society of Japan, Vol.22, No.5, pp.582–586, July 2004.
[2] K. Shima and Y. Uo, “Requirements for Quick Network Construction Mechanisms for theOn-Site Emergency Rescue Activity,” Internet Conference 2006 (IC2006), October 2006.

6ath3:ff10::1
158.65User segment prefixes:
2001:200:0:ff10::/60
203.178.158.0/23

SSID: rh0
Channel: 6
txpower 20
2001:200:0:ff10::/64
203.178.158.64/26

ath3:ff11::1
158.129

SSID: rh1
Channel: 1
txpower 20
2001:200:0:ff11::/64
203.178.158.128/26

rh0

rh4

ath3
:ff14::1.159.65

rh1

ath3
SSID: rh5
:ff15::1
Channel: 1.159.129 txpower 20
2001:200:0:ff15::/64
203.178.159.128/26
rh5
rh6
SSID: rh6
ath3:ff16::1
Channel: 11.159.193 txpower 20
2001:200:0:ff16::/64
203.178.159.192/26

SSID: rh4
Channel: 11
txpower 20
2001:200:0:ff14::/64
203.178.159.64/26

ath3:ff12::1
158.193

SSID: rh2
Channel: 6
txpower 20
2001:200:0:ff12::/64
203.178.158.192/26

ath3:ff13::1.159.1

SSID: rh3
Channel: 1
txpower 20
2001:200:0:ff13::/64
203.178.159.0/26
rh3

rh2

図 6: プレナリ部屋ユーザーセグメントの設定. 各無線ノードは IEEE802.11b/g (後半は 802.11b専用として運用) アクセスポイントとして運用され, それぞれ異なるサブネットを提供. 無線ノード

rh4 と rh6 は, 当初運用予定に入っていたが, 干渉軽減のために運用を中止.

Preliminary Result
30.0Mbps
22.5Mbps
15.0Mbps
7.5Mbps
0Mbps

1hop (1-3)

2hops (1-3-2)

3hops (1-3-2-4)

TCP throughput between APs

図 7: 図 5 のネットワークで, 無線ノード rh1 と, 無線ノード rh3, rh2, rh4 の間で nerperf による

TCP スループットを測定した結果. それぞれの無線ノードに対して, 各 3 回ずつ計測.

7

Preliminary Result
8Mbps
6Mbps
4Mbps
2Mbps
0Mbps

1hop (C-1)

2hop (C-1-3)

3hops (C-1-3-2)4hops (C-1-3-2-4)

TCP throughput from the client on AP1 to other APs

図 8: 図 5 のネットワークで, 無線ノード rh1 に接続した 802.11g クライアントと, 無線ノード rh1,rh3, rh2, rh4 の間で nerperf による TCP スループットを測定した結果. それぞれの無線ノードに対して, 各 3 回ずつ計測.

8