第 12 部
モバイルコンピューティング

357

第

1章

はじめに
WIDE MOBSEC (Mobile Security) Working Group は、インターネット環境におけるモビリティとセキュリティに関して研究するグループである。
特に、インターネットプロトコルとして、Mobile-IP と IP セキュリティプロトコル (IPSEC) 、システム的には、ファイアウォールや携帯端末を用いたモバイル環境に関して研究するものである。
実際の作業は、IPA(情報処理振興事業協会) の創造的ソフトウェア育成事業の「連続移動空間に対するネットワーク環境の開発 (NECM) 」やインターネットカーコンソーシアムと密接に連係し 、実装と実験を行ってきた。
今年度は、NECM の最終年度にあたり、11 月に大規模な評価実験を慶應義塾大学で行った。MOBSEC 関係の実験項目としては 、次世代インターネットを取り入れた教室を想定した、移動 IP の大規模な評価実験を行った。
これは、IETF 仕様の Mobile-IP と VIP を実装した携帯ノート PC 約 40 台を、無線 LANで接続された教室間で移動させ、その移動 IP 的なローミング時間や、通信性能を測定し 、実環境で耐えられるか検証したものである。
本報告では、その教室環境における移動 IP の実験について報告する。また、今後の新しいモバイルインターネットの技術動向として注目している、MANET (Mobile Ad Hoc
Networking) に関して紹介する。IETF で Working Group が発足したので、その活動内容
を中心に報告する。

359

第

2章

教室環境を想定した移動体通信プロト コル運用実験

2.1

はじめに

近年、移動型の計算機をネットワークに接続して利用する機会が多くなった。これには、
主に以下に挙げるような背景がある。
計算機の小型化
可搬型の計算機が世に登場してから、急速に計算機の小型化・高性能化が始まった。
現在、計算機は常に携行できる大きさまで小型化され、人々の生活に入り込むようになった。
ネット ワークに対する需要の拡大
インターネットの急速な成長の影響もあり、計算機とネットワークは切り離して考えることができないものになっている。計算機上のソフトウェアもネットワークを前提としているものが多く、OS に関しても「ネットワーク OS 」などの言葉が既に意味をなさないものになりつつある。
インフラの整備
デジタル公衆電話や携帯電話、PHS の普及にともない、移動先でもコネクティビティを確保するのが容易になってきた。また、モデムデバイスを内蔵するなど移動先でのネットワークを意識した作りになってきている。
このように移動した先で計算機をネットワークに接続する機会が増えるにしたがって、
モーバイルコンピューティングへの要求も高まってきている。
こういった要求に応えるために、IETF ではインターネットでの透過的な移動を支援するためのプロトコルとして Mobile-IP[112] を定めた。また、WIDE 内では Virtual IP(VIP)[113]実装が存在する。以後これらのプロトコルを移動体通信プロトコルと呼ぶ。しかし 、残念ながらこれらのプロトコルは複数の実装が存在するものの、まだ広く普及しておらず、以下に示すような疑問点が存在する。

360

第 12 部

モバイルコンピューティング361

 相互接続性の不足

IETF では現在まで 2 回の IETF Mobile-IP の相互接続実験が行なわれているが、参加団体もそれほど 多くなく、まだ十分に接続性が試されているとは言いがたい。

 スケーラビリティへの疑問
前述のように移動体通信プロトコルは広く普及しているとは言いがたく、大規模な運用が行なわれていないのが現実である。実際にこれらのプロトコルが普及した場合、十分なスケーラビリティがあるのかが確認されていない。

 他の移動体支援ミドルウェアとの協調性

現在では Mobile-IP のように IP 層での移動をサポートするものだけではなく、移動するノード を支援するためのミド ルウェアやアプリケーションも多く開発されている。現実的な使用を想定するとそのようなミドルウェアと移動体通信プロトコルは同時に使用されることが考えられる。そのため、従来のアプリケーションの他に、他の移動体支援ミドルウェアとの協調性を確認する必要がある。

これらを明らかにするために、多数の携帯型計算機に複数の実装による移動体通信プロ
トコルを載せ、その上で移動体支援ミドルウェアを動作させ、実際に移動通信を行なってみることにより、実環境での運用の可能性を検証することにした。
実験は、携帯型計算機が同時かつ多数に移動する状況として、学生がラップトップコン
ピュータを持ち歩き、移動体通信プロトコルを利用して教室間を移動し 、授業中にネットワークを利用しながら学習する環境を想定して実験を行った。
なお、この実験は、IPA(情報処理振興事業協会) の創造的ソフトウェア育成事業の「連続移動空間に対するネットワーク環境の開発 (NECM) 」の一環として行なわれた。この実験に参加した団体は、WIDE, 東芝、Sun Microsystems, Stanford University の 4 団体である。

2.2

実験環境

2.2.1

ハード ウェア環境およびソフト ウェア環境

実験は 34 台のラップトップ PC を使い、学生が実際に二つの教室を移動する環境を想定して行なった。
使用したソフトウェアは、移動体通信のプロトコルとして、IETF Mobile-IP と VIP の2 種類である。IETF Mobile-IP は東芝、Sun、Stanford の 3 種類の実装を使用した。VIPは WIDE の実装を用いた。
また、移動体支援ミドルウェアとしては、現在 WIDE で開発中である以下の 2 つを使用した。

 切断時運用が可能なファイルシステム (PFS)[114]1997 年度 WIDE 報告書362

 地理的位置情報システム (GLI)[115]図 2.1に実験環境の概観を示す。
The Internet
Home Agent
Home Router
PFS Master
ServerCorrespondentNode

GLI Server

H1

H2

H3

FireWallHome Network

R1

1Mbps

ADSL
Link

7Mbps

R2

R3

R4
Classroom A

B1

H4

Classroom B

B1
H5

Foreign Agent
DHCP Server

Mobile Nodes

Foreign Agent
DHCP Server

Mobile Nodes

図 2.1: 教室実験環境の概観
図 2.1におけるラップトップ (Mobile Nodes) を除く各ホストの構成を以下に示す。

 Home Network

10Mbps イーサネット

 H1

第 12 部

モバイルコンピューティング

ハード ウェア構成: Cyrix 6x86-PR200+, 64MB
機能 1: Mobile-IP のホームエージェント (東芝による実装)
機能 2: VIP のホームルータ
機能 3: PFS のマスタサーバ

 H2
ハード ウェア構成: Pentium 100MHz, 32MB
機能: 移動ノード (Mobile Node) からの ping による接続性確認の対象
ネットワークスループット計測のためのターゲットホスト H3
ハード ウェア構成: Pentium ODP 83MHz, 24MB
機能: GLI サーバ

 R1 および R2
ハード ウェア構成: ADSL モデム対性能: R1 → R2 は 7Mbps, R2 → R1 は 1Mbps

 Classroom A

10Mbps イーサネット

 B1

無線 LAN { イーサネット間ブリッジ H4
ハード ウェア構成: Intel 486DX4 100MHz, 24MB
機能 1: フォーリンエージェント (東芝による実装)
機能 2: DHCP サーバ

 Classroom B

10Mbps イーサネット

 B2

無線 LAN { イーサネット間ブリッジ H5
ハード ウェア構成: MicroSPARC

363

1997 年度 WIDE 報告書364

機能 1: Mobile-IP のフォーリンエージェント (Sun による実装)
機能 2: DHCP サーバ

34 台の移動ノードとして利用したハード ウェアは次のようなものである。計算機として
IBM ThinkPad560 (Pentium133MHz, 24MB) 、DEC HiNote Ultra II (Pentium 120MHz,
24MB) である。ネットワークインタフェイスとしては無線 LAN と 10Mbps イーサネット(有線) を利用した。
搭載したハード ウェア及びソフトウェアの組合わせを表 2.1に示す。
表 2.1: 教室研究室実験のソフトウェア環境
ハード ウェア

TP560
TP560
TP560
DHU
DHU

2.3

OS
BSD/OS
BSD/OS
BSD/OS
Linux
Linux

GLI
東芝 MIPYes
東芝 MIPNo
VIP
Yes
Stanford MIP No
Sun MIP
No
移動体支援

PFS
Yes
Yes
Yes
Yes
Yes

IF

台数

無線
無線
無線
有線
有線

1
9
10
8
6

実験の内容

実験用クライアント PC を、教室 A に置き、教室 B へと順次数台ずつ移動させる。MobileIP は各教室に設置したフォーリンエージェントを使用する。ノードの移動に伴い以下のパラメータがどのように変化するかを記録する。

 Mobile-IP の移動時のオーバーヘッド
 スループット (双方向) ホームエージェントの負荷
また、他の移動体通信支援ミドルウェアと問題なく協調動作をすることを確認する。

2.3.1

実験の手順

最初にすべての移動ノード を教室 A に設置する。Mobile-IP/VIP はそれぞれのホーム
エージェント /ホームルータに登録を行ない、すべてのノードがホームネットワークにあるホストと正しく通信できるかを確認する。

第 12 部

モバイルコンピューティング

365

その後、順次数台ずつ移動ノードを教室 A から教室 B へと移動させる。各ノードの移動が完了した時点で、ネットワークのスループットを計測する。同時に移動する台数を変化させながら、この計測を繰り返す。
実際の移動は表 2.2 のように行なった。

表 2.2: ノード の移動シーケンス
回

移動したノード 数

1
2
3
4
5

4
4
4
8
14

移動したノード の内訳
MIP(東芝) 、MIP(stanford), MIP(Sun), VIP
MIP(東芝) 、MIP(stanford), MIP(Sun), VIP
MIP(東芝) 、MIP(stanford), MIP(Sun), VIP
MIP(東芝)x2 、MIP(stanford)x2, MIP(Sun)x1, VIPx2
MIP(東芝)x5 、MIP(stanford)x3, MIP(Sun)x2, VIPx5

2.4

実験結果および考察

2.4.1

各実装の相互接続性および VIP との同時運用について

東芝, Stanford, Sun の Mobile-IP の実装においては、それぞれの相互接続性が確認された。また、VIP のホームルータと Mobile-IP のホームエージェントを同一のホストで動作させたが問題なく動作した。また、Mobile-IP と VIP のプロトコルも互いに干渉することなく通信可能なことが確認された。

2.4.2

Mobile-IP の移動時のオーバヘッド

Mobile-IP を使用しているノードが移動した時、その移動を検出してからホームエージェ
ントへの登録が成功するまでの時間を東芝の Mobile-IP の実装で計測した。結果を表 2.3に示す。
表中、ラウンドトリップ時間欄の [IM] は、その登録要求が \Identi cation Mismatch" で拒否されたことを示している。Identi cation Mismatch とは、登録要求の replay protection のために、登録要求の中にノード側の時刻情報を記録するが、この時刻情報がホームエージェン
トの時刻情報とずれが生じていることを意味している。そのため、登録要求が Identi cation
Mismatch で拒否された場合、ノードはそのずれを修正して再登録を行なわなければならない。また 同欄内の T/O は、登録要求に対する応答がノードが期待した時間内に帰ってこなかったため、タイムアウトを起こしたことを示している。東芝の実装ではタイムアウ
トは 3 秒となっている。

1997 年度 WIDE 報告書366

表 2.3: Mobile-IP の移動時の登録オーバヘッド
ホスト名

1
2
3
4
5

bsdi01
bsdi02
bsdi03bsdi06
bsdi07
bsdi04bsdi05bsdi08bsdi09bsdi10

登録パケットのラウンドトリップ時間 (msec)

110.6
97.0
94.6
222.9[IM]87.7[IM]
849.0[IM]305.1
210.0[IM]161.8[IM]T/O

T/O 69.7
T/O 93.7
T/O 117.6
T/O
T/O
88.6

T/O 89.315
79.2

1 、2、3 回の移動では、同時に移動するノードが 4 台しかないので、移動時のオーバヘッ
ドは非常に小さく、非常に良好に動作していると言える。しかし 、同時に移動した台数の多い 4, 5 回目の移動では、登録要求のタイムアウトが起きているノードがほとんどであり、移動の検出から登録完了までのオーバヘッドはあきらかに大きくなっている。同時にIdenti cation Mismatch の応答も多くなっているが、これは単にこの移動ノード の時間がホームエージェントと合っていなかったことを意味している。各応答自体のラウンドトリッ
プ時間はそれほど大きくないことを考慮すると、オーバヘッドは登録要求のタイムアウトに強く支配されることが分かる。
加えて、登録要求/応答のラウンドトリップ時間を比較すると、同時に移動した台数の多
い 4 、5 回目の移動の方がラウンドトリップ時間が大きくなっていることがわかる。
しかし 、この調査を行なった移動ノードはすべて無線 LAN を通してのアクセスであったため、パケットの消失やラウンドトリップ時間の増加が、ホームエージェント及びフォー
リンエージェントの負荷が高いために大きくなっているのか、あるいは無線 LAN の輻輳によるものなのかはこのデータからは分からない。そこで、ホームネットワークおよび移動先である教室 B でのパケットダンプから、Mobile-IP の登録要求及び応答のパケットを抽出しオーバヘッドを計測した。5 回目の移動において観測された登録要求/応答パケットをまとめたものを表 2.4, 2.5に示す。
観測時刻は 5 回目の移動において最初に観測された登録要求パケットからの相対時刻になっている。また、教室 B とホームネットワークに配置したパケット収集用のホストの時
刻は完全に一致していないため、時刻には誤差がある。表中の観測時間の欄において、\×"は観測されるべきパケットが観測されなかったことを示し 、空欄は観測され得ないパケッ
ト、すなわちそのパケットの経路ではそのネットワークを通らないことを表わしている。

第 12 部367

モバイルコンピューティング

表 2.4: 5 回目の移動時に観測された登録パケット (1)
ホスト名

bsdi04

教室 B

観測時刻
ホームネット

00:00:00.000
00:00:00.020
00:00:00.040
00:00:00.070
00:00:00.090
00:00:00.120
00:00:00.140

00:00:00.030
00:00:00.040
00:00:00.130
00:00:00.140

×bsdi05bsdi0800:00:03.080
00:00:03.120
00:00:03.140
00:00:03.170
00:02:04.390
00:02:04.430
00:02:04.440
00:02:04.480
00:00:09.280
00:00:09.320
00:00:09.340
00:00:09.370
00:00:09.380
00:00:09.420
00:00:09.440

00:00:03.130
00:00:03.140
00:02:04.420
00:02:04.430
00:00:09.330
00:00:09.340
00:00:09.430
00:00:09.440

×00:00:11.440
00:00:11.470 00:00:11.480
00:00:11.490 00:00:11.480
×00:00:14.440
00:00:14.470 00:00:14.480
00:00:14.490 00:00:14.480
00:00:14.520

パケットの内容

パケットの方向

登録要求
登録要求
登録応答 [IM]
登録応答 [IM]
登録要求
登録要求
登録応答 [RA]登録応答 [RA]
登録要求
登録要求
登録応答 [RA]登録応答 [RA]
登録要求
登録要求
登録応答 [RA]登録応答 [RA]
登録要求
登録要求
登録応答 [IM]
登録応答 [IM]
登録要求
登録要求
登録応答 [RA]登録応答 [RA]
登録要求
登録要求
登録応答 [RA]登録応答 [RA]
登録要求
登録要求
登録応答 [RA]登録応答 [RA](MN-FA)(FA-HA)(HA-FA)(FA-MN)(MN-FA)(FA-HA)(HA-FA)(FA-MN)(MN-FA)(MN-FA)(HA-FA)(FA-MN)(MN-FA)(FA-HA)(HA-FA)(FA-MN)(MN-FA)(FA-HA)(FA-FA)(FA-FA)(MN-FA)(FA-HA)(HA-FA)(FA-MN)(MN-FA)(FA-HA)(HA-FA)(FA-MN)(MN-FA)(FA-HA)(HA-FA)(FA-MN)

1997 年度 WIDE 報告書368

表 2.5: 5 回目の移動時に観測された登録パケット (2)
ホスト名

bsdi09観測時刻
ホームネットclassB
00:01:14.190
00:01:14.230
00:01:14.240
00:01:14.330
00:01:14.340
00:01:14.430
00:01:14.440

00:01:14.230
00:01:14.230
00:01:14.430
00:01:14.430

×bsdi1000:01:16.560
00:01:16.580 00:01:16.580
00:01:16.590 00:01:16.580
00:01:16.630
×00:02:26.620
00:02:26.630 00:02:26.620
00:02:26.640 00:02:26.620
00:02:26.680

パケットの内容

パケットの方向

登録要求
登録要求
登録応答 [IM]
登録応答 [IM]
登録要求
登録要求
登録応答 [RA]登録応答 [RA]
登録要求
登録要求
登録応答 [RA]登録応答 [RA]
登録要求
登録要求
登録要求
登録応答 [RA]登録応答 [RA](MN-FA)(FA-HA)(HA-FA)(FA-MN)(MN-FA)(FA-HA)(HA-FA)(FA-MN)(MN-FA)(FA-HA)(HA-FA)(FA-MN)(MN-FA)(MN-FA)(FA-HA)(HA-FA)(FA-MN)第 12 部

モバイルコンピューティング369

この結果を見ると、各ノードが送信した要求はノード bsdi10 の最初の登録要求以外すべて
ホームエージェントに到達しており、またホームエージェントは最大でも 20ms 以内にすべての登録要求に対して応答を返していることが分かる。よって同時に多数のノードが移動しても、登録動作についてはホームエージェントがオーバヘッド の原因ではないことが分かる。また、ホームエージェントからの登録応答パケットも教室 B のネットワークにほぼすべて到達していることが分かる。よって今回の実験では、ノード の登録要求がタイムアウトする原因となっているのは、主にフォーリンエージェントが登録応答メッセージを落としてしまっていることであることが分かった。
また、bsdi04 の最初の登録要求/応答のラウンドトリップ時間は 849ms と大きいが、有線でのパケットダンプから推測されるラウンドトリップ時間は 70ms である。よってこの遅延は Mobile-IP のプロトコルに起因するものではなく、無線 LAN によるものであると推測される。
本実験では出来る限り移動ノードを同時に移動させたつもりであったが、このパケットダンプからは、実際には登録を行なっている時間が 2 分程度と大きくずれていることが分かった。これは、無線 LAN を使用したため、ネットワークへの接続時間を完全に同期させることが出来なかったためと思われる。

2.4.3

Mobile-IP の移動時のスループット

Mobile-IP を使用した際の TCP のスループットが、同時に移動するノード 数によってどのように変化するかを計測した。TCP のスループットの計測には nttcp を用い、移動ノードから通信相手へのスループットと、その逆の双方向を測定した。
この実験の結果を図 2.2に示す。

グラフ中の MN は移動ノード、CN は通信相手を表わす。
グラフから分かるように、移動ノード の台数が増えるにしたがってそれぞれのノード の
スループットが低下していくことが分かるが、移動ノードが増加するため通信量の総量も増加することを考えると、このスループットの低下は妥当なものと考えられ、特に Mobile-IP
を利用しているために低下しているとは言えない。しかし 、MN から CN への通信と CNから MN への通信を比較すると、明らかに CN から MN へのパフォーマンスが悪いことが分かる。これは、CN から MN への通信の場合、ホームエージェント及びフォーリンエー
ジェントが大きな IP パケットをトンネリングしなければならないため、そのオーバヘッドが現れていると考えられる。また、ホームエージェントもフォーリンエージェントもルータではなくホストとしてネットワークに接続されているため、ホームネットワーク及び教室 B のネットワークに、トンネリングされた大きなパケットと、トンネルに入る/出る大きなパケットの 2 つが流れることになってしまうためにそれぞれのネットワークの帯域を冗長に消費してしまうことも原因と考えられる。
次に、ホームエージェント及びフォーリンエージェントのトンネリングの性能を見るた
め、ホームネットワークと教室 B のネットワークのパケットダンプから、特定の TCP セッ1997 年度 WIDE 報告書

370

MN-CN
CN-MN

1.4
1.2

MN-CN

Mbit/s

1
0.8
0.6
0.4

CN-MN

0.2
0
0

5

10

15

20

25

num. of hosts
図 2.2: Mobile-IP のスループットの変化

30

35

第 12 部

371

モバイルコンピューティング

ションについて、CN から MN へのパケット及び 、それらがトンネリングされたパケット数を調べた。この結果を表 2.6に示す。

表 2.6: ホームエージェントおよびフォーリンエージェントのトンネリング性能
教室 B

ホームネットワーク

トンネルに入るべき数 トンネルされた数 トンネルされた数 トンネルから出た数

6438

6396

6385

6382

ホームエージェントおよびフォーリンエージェントはトンネリングの際はそれほど多くのパケットを落としていないことがわかる。このことから、ホームエージェント及びフォー
リンエージェントのトンネリングが間に合わずにパフォーマンスが劣化しているわけではないことが分かる。しかし逆に言えば TCP の輻輳制御によってホームエージェントおよび
フォーリンエージェントのトンネリング性能限界を越えないようなパケット送出レートに落ちているとも考えられるため、トンネリング性能がボトルネックではないとは言えない。

2.4.4

Mobile-IP のホームエージェント の負荷の変化

Mobile-IP を使用した移動ノード の数の変化に対して、ホームエージェントの負荷の変化を測定した。この実験の結果を図 2.3に示す。この結果より、Mobile-IP におけるホーム
エージェントは、一度に移動する台数の急激な増加に対しては負荷も急激に増加することが確認された。

Num. of PCs
8

6.67

12

8.67

24

229
1

2

4

10

20

40

100

図 2.3: ホームエージェントの負荷の変化

200

Load

1997 年度 WIDE 報告書

372

しかしこの負荷の高さのために登録要求に応えられないといったことや、移動ノードへのパケット転送時にパケットを落とすといったことが観測されていないことを考えると、この結果には疑問が残る。また、ホームエージェントのホストでは PFS のマスターサーバのデーモンも稼働していたためこの負荷がホームエージェントのものだけとも言い切れない。今後詳しく原因を究明していきたい。

2.4.5

他の移動体支援ミド ルウェアとの協調性

切断時運用可能なファイルシステムとして、PFS を各ラップトップ PC に搭載して運用した。結果として Mobile-IP 及び VIP といった移動体通信プロトコルに影響を受けることなく動作することが確認された。しかし 、PFS 自体の問題として、少ない台数の場合は良好に動作することが確認されたが、移動する台数が増加するに従い処理のもたつき、ばた
つきが管理側、ユーザ側から確認され、改良の余地を残している。
移動するノードの地理的な位置を収集管理する地理的位置情報システム GLI では、教室の位置を番号により識別しノードの識別子と対応付けて、移動ノードから GLI エリアサー
バに定期的に登録送信を行った。本環境での実験の結果、移動体通信プロトコルを利用しても、良好に動作した。また、GLI の実験結果としては、本来無線 LAN や携帯電話、PHS等の低速回線に対応したプロトコル設計であるため、イーサネットなど有線のネットワーク
においても良好に動作した。本実験ではユーザが設定した送信間隔により登録送信を行っていたため、GLI データベースに必要ないデータのエントリが多数が蓄積された。移動したことを自動認識し 、移動した際にのみ登録送信を行うなどのより効率的な処理方針を持つ必要がある。

2.5

まとめ

移動体通信プロトコルを利用した移動する計算機についての実験を行なった。実験は実環境に近い形として、教室環境を想定して、34 台のノードと、IETF Mobile-IP と VIP という複数のプロトコルおよび 、IETF Mobile-IP では東芝, Sun, Stanford の複数の実装を同時に利用した。また、移動体支援ミドルウェアとの同時利用を行なった。本実験により、IETF
Mobile-IP については複数の実装間での相互接続性が確認された。また、34 台のノードであれば同時に移動体通信プロトコルを利用し 、十分な通信が行なえることが確認された。
また、Mobile-IP については、多数の移動ノードが同時に移動しても登録時のオーバヘッ
ドはそれほど大きくないことが確認された。これはたとえば休み時間に学生が徐々に教室に入り、ネットワークに接続するような環境ではネットワークに対する負荷はあまり大きくなく、現在の計算機の能力でも十分対応できることを意味している。しかし 、通信のパ
フォーマンスについてはあまり良好な結果を得ることができなかった。また、ノード 数の増大に伴いホームエージェントの負荷が大きくなることも確認され、各移動ノードが高速なリンクに接続していても十分な性能が得られなくなることが予想される。この対策とし

第 12 部

モバイルコンピューティング

373て、たとえばホームエージェントおよびフォーリンエージェントの分割管理等を行うということが考えられる。必要であれば 、今後このような負荷分散を支援するためのプロトコル拡張などについても議論していきたい。

3章
MANET (Mobile Ad Hoc Networking)第3.1 MANET(Mobile Ad Hoc Networking)
3.1.1

はじめに

近年のポータブルな計算機環境の進展と、無線技術の進歩によって、インターネットの
モバイル技術は、ますます重要になってきている。
ここでは、モバイルインターネットの分野で、MOBILE WG につづき、IETF の WG になった、Mobile Ad Hoc Networking(MANET) に関し 、その技術的内容を IETF の WG 活
動内容とともに述べる。

3.1.2

MANET とは従来からのインターネットのアーキテクチャは、基本的に静的なネットワークトポロジを仮定している。このトポロジでは、図 3.1のように通常サブネットと呼ばれる LAN が相互にルータを介して接続されているモデルである。ネットワークトポロジの変化には、動的ルーティングの技術で対応している。しかし 、この技術は、無線のモバイル環境のように、頻繁にトポロジが変化するような場合には適合しない。
ラップトップタイプのモバイルコンピューティングの出現や、ワイヤレス LAN 技術の進歩、セルラーシステムを利用して IP 通信を行うことによって、インターネットにおいても、固定されているルータに、ノードがローミングして動的に接続することが可能となった。Mobile-IP は 、このような目的のために、移動透過性を実現するためのプロトコルである。
つまり、Mobile-IP の場合は、基本的に、ネットワークのトポロジの変化は想定しておらず、ノード (端末) 自体のモビリティを実現している。また、従来から存在するインター
ネットには、極力影響を与えないような配慮も行っている。

MANET は、モバイル環境における別の種類の課題に対するものである。それは、図 3.2に示すように、モバイルノード 自身がルーティングの機能を持ち、自律しながら移動する、
無線リンクでのド メインを形成するものである。

374

第 12 部

モバイルコンピューティング

subnetsubnetRouterRouterRoutersubnetRouterRoutersubnetRoutersubnet

図 3.1: 従来型インターネットアーキテクチャ

subnetMANET
subnetRouterRouter

MANET
Isolated
Routersubnet

MANET

RouterRoutersubnetRouterMANET

MANET
Isolated

図 3.2: MANET 型アーキテクチャ

375

376

1997 年度 WIDE 報告書

無線リンクを利用して、隣接サイトのノードを発見し 、その間で、ノード の情報や経路情報などを交換し 、相互がつながる。その輪が広がっていき、1 つのド メインを形成、その中で、互いにデータ通信が可能になっていく (Isolated)。一端がインターネットと接続されると、ド メイン自体がインターネットに接続されていく。
MANET は、このように、Mobile-IP とは違う形で、モバイルユーザに対してシームレ
スなインターネット接続を提供する。また、Mobile-IP では、ローミングに秒オーダの時間が必要であるが、MANET 環境は、無線環境を前提としているので、高速な移動も考慮している。
MANET では、次に示すような特徴を持つ。

 トポロジーの動的変化 (Dynamic topologies)
 通信帯域が有線網に比べて小さいこと (Bandwidth constrained) 通信速度が変化すること (Variable capacity links)
 パワーセーブのオペレーションが必要なこと (Power constrained operation) 物理的なセキュリティが限られていること (Limited physical security)
これらの特徴を解決していくことが研究課題でもある。

3.2

インターネット と MANET

従来から、MANET に関する研究・開発は行われてきたが、独自仕様と独自プロトコルで実装されてきた。
しかし 、近年、安価な無線ネットシステムが出回るようになった。そうすると、それらの多種な無線システム間を接続する必要性も大きくなる。インターネットを利用すること
でその要求に簡単に応じることが可能になる。
このため、インターネットプロトコルを利用した MANET が注目されてくるようになった。

3.3 IETF MANET Working Group
今までに述べてきたように、MANET にインターネット技術を適用し 、必要なプロトコルを決めるため、IETF にて、MANET Working Group(WG) が 、97 年 8 月のミュンヘン
会合から発足した。
本 WG のまず手始めに、MANET 環境におけるルーティングプロトコルに限定して検討
し 、さらにその関連技術を通してこのようなアーキテクチャを実現することを目的としている。

第 12 部

モバイルコンピューティング

377

これは、MANET アーキテクチャの場合は、接続性が重要な基盤技術であり、またノード 間で交換し合わなければならないルーティングプロトコルが重要だからである。
WG を設立することで、従来からのクローズドな仕様であったものを、IP ベースでオープンな仕様にしすること、また拡張性あるプロトコルにすることも目指している。
プロトコルは、ユニキャストにおける IP ルーティングプロトコルの検討からはじめている。
WG 発足時に定めた予定では、本 WG は以下のスケジュールで活動することになっている。

 97 年 10 月までに、ルーティングプロトコルの提案
 98 年春までに、提案されたプロトコルの議論
 98 年夏に、最初のプロトコル提案と実装、性能評価
 99 年 3 月に、プロトコルの修正と評価の完成
 99 年 12 月に、Proposed Standard としての発行を目標

3.4

提案されている MANET のルーティングプロト コル

ここでは、WG に提案されているいくつかのルーティングプロトコルについて、紹介する。

3.4.1

IMEP(The Internet MANET Encapsulation Protocol)

IMEP は、MANET WG のチェアとサブチェアから提案されているドラフトである [116]。
IMEP は 、論理的には 、IP 層とその上位層やルーティング機能の間に位置するものである。
つまり、IMEP は、MANET 環境における共通のネットワーク層のプロトコルであって、種々のルーティングアルゴ リズムによるオペレーションや、IP より上位層のプロトコルから同じ インターフェースを用いて利用できるように意図されている。
現状の IMEP では、

 リンクの状態センシング
 複数の制御メッセージの統合化 (Aggregation) と、カプセル化
 ブロードキャストへの信頼性の付加
 ネットワーク層のアドレス解決
 セキュリティ(認証) 処理の為のフック機構の提供

1997 年度 WIDE 報告書

378の各機能を提供している。
さらに、機能を付加したり、物理リンクによって、各機能を ON/OFF したりできる。
このプロトコルの目的は、種々の物理層の技術やトポロジーを、共通化することである。

3.4.2

TORA(Temporally Ordered Routing Algorithm)

TORA は、MANET WG のチェアとサブチェアからの提案プロトコルである [117]。
このルーティングプロトコルは、distance-vector でも link-state でもなく、link reversalと呼ばれるアルゴ リズムの 1 つであり、ループフリーなルーティングが可能となる。
各ノード の 高さ"をメトリックとして扱い、いつでも、宛先をルート (root) とする方向性がある非周期のグラフ (directed acyclic graph) が定まる。
TORA の実装では、3 つの機能から成っている。

 経路生成 経路維持 経路消去経路生成機能は、query/reply を実行することで、直ちに実施される。
経路維持機能は、あるノードが 、最新のダウンストリームリンクを失った時、または、
アップストリームリンクを得た時、または、経路自身を必要な時に起動され、グラフを再構成する。
しかし 、TORA では最短経路は計算できないようである。

3.4.3

AODV(Ad hoc On-demand Distance Vector) Routing Algorithm

AODV は、Sun に移った C. Perkins から提案されたプロトコルである [118]。彼は、Mobile
IP の仕様決定にも深く関わっている。
AODV は、ループフリーの経路アルゴ リズムである。このプロトコルは、基本的には、
distance vector アルゴ リズムである。オンデマンドでソースルーティングを行う。これによって、維持ルートの更新回数を減らす。
本プロトコルは、シーケンス番号を使うことで、ループを回避し 、1 つの宛先に対して 1
つの経路を維持する。
発信元シーケンス番号は、逆方向の経路を提供するために、あて先シーケンス番号は、順方向経路を提供するために用いられる。
経路発見要求には、要求者が知っているシーケンス番号を含むことで、古い経路を得られないようになっている。
ユニーク ID を付けたブロードキャスト メッセージにより、重複配布を防いでいる。

第 12 部

モバイルコンピューティング

379

AODV を用いて、各ノードは、すべての隣接ノードに、リンクが切れた時に通告する。
本プロトコルは、実装するには単純であるが、オーバヘッドが大きいと言われている。

3.4.4

ZRP(Zone Routing Protocol)

ZRP は、Cornell 大学からの提案プロトコルである [119]。
従来からの Proactive(つまり、distance vector 方式のように経路情報を伝播させていく方法) と、Reactive(必要になったときに、その都度、経路情報を調べる方法) の両者を融合したプロトコルである。
まず、自ノードを中心に、そこからある半径 (ホップ数) 内をゾーンとして定義する。そのゾーン内は、Proactive 方式によって経路情報を流通し 、すべてのノードの情報を把握している (Intrazone routing) 。それより外は、Reactive 方式によって経路を管理し 、必要なノード 以外の情報は保持しない (Interzone routing)。
ある宛先への経路探索は、まず、自ゾーン内なら、保持している経路情報から検索する。
もしなければ 、 border casting"と呼ぶ方法で、経路を検索する。これは 、ゾーンの境界
ノード (半径のノード ) ごとに、経路探索を伝播させて経路を探すものである。これにより、伝播させる経路探索数を減らすとともに、ソースルーティングとして指定するのが、境界ノードごとで済ませられるので、指定するノード 数も減らせる。

3.4.5

DSR(Dynamic Source Routing)

DSR は、CMU の Monarch プロジェクトの一環で開発されているプロトコルである [120]。
本プロジェクトは、真にシームレスなワイヤレスとモバイルホストとのネットワーキングを実現するための、適合型ネットワーキングプロトコルとプロトコルインターフェースを開発している。

DSR は、各ノードが、動的に、宛先ノード へのソースルートを得ることができるプロトコルである。
ソースルートを利用する利点は、宛先までの中間ノードは、ルーティングを情報を維持する必要がないからである。
経路が必要な時に、動的に経路発見をすることで、定期的に経路情報を交換することが不要になる。とくに、ネットワークトポロジが安定している時に顕著である。

3.5

今後の MANET WG の活動方向

MANET は 、物理リンクの特性、移動範囲、台数規模、移動速度等の利用環境により、
かなり、プロトコルの仕様に影響を受けやすい。
そのため前提となる環境のコンセンサスを得られず、議論がなかなか収束しない。

3801997 年度 WIDE 報告書

また、現在 MANET では経路情報のプロトコルに限って議論をしている。しかし 、それ以外にも以下のような問題点が挙げられている。

 セキュリティ
 マルチキャスト
 QoS
 IPv6
 DNS 等の他のサービスとの関係
提案されている各プロトコルを共通の土台で議論するため、シミュレーション環境も共通化することも努力されている。
非常に重要な研究テーマとして今後の活動にも注目していきたい。

第

4章

おわりに
98 年 3 月の合宿において、2 年続いた MOBSEC WG は終了し 、新しい形でモバイルイ
ンターネットに関する研究を WIDE でできないか、しばらく検討することになった。
現在、MOBSEC WG 及び NECM に参加したメンバーを中心に、定期的に会合を開き、
ブレ インストーミングの形で、各メンバーの意見交換を行っている。また、世の中の技術動向、研究動向のサーベイも行っている。
新しい形でのモバイル、及び 、セキュリティに関して研究するコミュニティの発足と活躍が期待される。

381

382

1997 年度 WIDE 報告書