修士論文

2006 年度 (平成 18 年)

移動ルータ間の協調による NEMO の安定性と通信品質の向上に関する研究慶應義塾大学大学院 政策・メディア研究科
塚田 学

修士論文要旨

Academic Year 2006

移動ルータ間の協調による NEMO の安定性と通信品質の向上に関する研究次世代インターネット環境において，移動する計算機をインターネット に接続する Network
Mobility（NEMO）や，Mobile IPv6 な どの移動体通信技術の必要性が高まってきた．特に，ITS（Inelligent Transport System）では自動車に搭載されている機器を NEMO を利用して，通信を行う需要が高まっ ている．また，人間の周囲の計算機をインターネットに接続する要求から，パーソナル エリアネットワーク（PAN）に NEMO が利用される．
NEMO による移動ネットワークが普及するにつれて，インターネットに接続された自動車に PANを携帯する人間が乗り込む場合など，複数の移動ネットワークが集合で移動する環境（NEMO 集合）が登場する．複数の NEMO が協調動作を行うことで，複数の移動ルータに接続された無線通信メディアを協調動作させる，などネットワーク資源に乏しい移動体通信環境を改善することが可能となる．
本研究の目的は，NEMO 集合全体で通信インターフェイス選択， バッテリ消耗の抑制を最適化することである．また，近隣の移動ルータの持つ通信イン ターフェイスの余剰通信帯域を効率的に利用し，NEMO 集合全体の通信品質を改善することである．本質的に個別のネットワークである NEMO を、集合として 1 つのネットワークに統合するため、セキュリティ、通信効率の最適化
等、様々な問題が発生する。
これらを実現するため，NEMO 集合に接続した複数の移動ルータ間 で接続性情報を動的な情報交換，協調して動作するモデルを提案した．その後，モデ ルに従い Mobile Routers Resource
Sharing（MRRS）システムの 設計と実装を行ない，実験環境にて実装の評価を行なった．
評価の結果，MRRS システムによって NEMO 集合内の通信イン ターフェイス選択，バッテリ消耗の抑制が最適化されたことが示された．移動ネットワーク 内のノードが NEMO 集合内全ての移動ルータの通信インターフェイスを利用 可能となり，またユーザーのポリシに応じた接続経路の使い分け，および経路多重化 による通信品質の改善を確認した．また，NEMO 集合全体で，バッテリの 消耗が抑制されたことが示された．
Keywords :1．IPv6，2．Network Mobility，3．Multihoming，4．Mobile IPv6，5．インターネット自動車
慶應義塾大学

政策・メディア研究科

塚田 学

Abstract of Master’s Thesis
Academic Year 2006

Improving communication stability and quality of NEMO
by multiple mobile routers cooperation
The demand for on-the-move and uninterrupted Internet connectivity is increasing in thenext generation IPv6 Internet. In order to fulﬁll such demand, protocols for host mobility(Mobile IPv6) and network mobility (NEMO) have been standerdized. Especially, in Intelligent
Transportation System (ITS) area, there is a strong demand to connect equipments installedon automobiles to the Internet with NEMO. At the same time, Parsonal Area Networks (PAN)
want to be connected to the Internet by NEMO. As mobile networks with NEMO deploy, NEMO
cluster which is interconnected mobile network will appear, for example drivers and passengers
who all have a PAN in an Internet-connected vehicle.
At the moment, each mobile routers of each PANs and Internet-connected vehicles are independently working and maintaining multiple tunnels with their home agents. But a collaboration
among those mobile routers could be considered in order to achieve reliability, load sharing, preference settings and eﬃcient battery saving for NEMO cluster. NEMO cluster arises brand-new
issues such as security, optimization of communication eﬃciency because of marging network.
To realize those improvements in the overall NEMO cluster, we propose the model to collaborate amoung mobile routers. With this model, the Mobile Routers Resource Sharing (MRRS)
system was designed and implemented. Evaluation results show that the redundancy and theoverall bandwidth for the nodes in the NEMO clusterare increased while overall energy consumption is saved.
Keywords :1．IPv6，2．Network Mobility，3．Multihoming，4．Mobile IPv6，5．InternetCAR
Keio University , Graduate School of Media and Governance

Manabu Tsukada

目次
第1章
1.1
1.2
1.3

序論
本研究の背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
本研究の目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
本研究の構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1
1
2
2

第 2 章 NEMO 集合における通信環境
2.1 移動体通信の要素技術 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Mobile IPv6 と Network Mobility (NEMO) の概要 . . . . . . . . . . . . .
2.1.2 複数 CoA 登録の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 NEMO の利用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 パーソナルエリアネットワーク . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2 インターネット自動車 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 NEMO 利用における通信環境と要求 . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1 無線通信メディアの整理 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2 想定ネットワーク利用状況 . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.3 移動ルータの電源 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.4 NEMO における通信品質向上への要求 . . . . . . . . . . . . . . . . . . . .
2.4 NEMO 集合の登場 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.1 ネットワーク環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.2 NEMO 集合の計算機 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5 NEMO 集合の現状と協調の必要性 . . . . . . . . . . . . . . . . . . . . . . . . . .
2.6 NEMO 集合の登場による問題点 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.6.1 複数の移動ネットワークプレフィクスに関する問題 . . . . . . . . . . . . .
2.6.2 NEMO 集合の境界に関する問題 . . . . . . . . . . . . . . . . . . . . . . . .
2.7 本章のまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3
3
3
5
8
8
9
10
10
12
12
13
15
15
16
17
18
18
18
19

第 3 章 NEMO 集合内の協調
3.1 NEMO 集合内の協調に対する要求事項 . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 ネットワーク構成に関する要求 . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2 NEMO 集合内の資源最適化に関する要求 . . . . . . . . . . . . . . . . . . .
3.1.3 セキュリティに関する要求 . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 NEMO 集合における協調モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 基本となる協調モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2 余剰資源共有型モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.3 集合内最適型モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.4 混在モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20
20
20
21
21
22
22
22
23
24

iv

3.2.5 協調モデルのまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NEMO 集合内資源の共有 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
本章のまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24
24
26

第 4 章 本研究の関連研究
4.1 NEMO 拡張型 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 NEMO SHAKE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.2 複数 MR における障害回避 . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.3 Multiple Gateway in Mobile Network (MGMN) . . . . . . . . . . . . . . .
4.1.4 Multiple Mobile Routers Management . . . . . . . . . . . . . . . . . . . .
4.2 Mobile Ad-hoc Network 型 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 各方式の比較 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4 本章のまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27
27
27
27
28
29
29
30
31

第5章
5.1
5.2
5.3
5.4
5.5

NEMO 集合の協調へのアプローチ
ネットワーク構成の考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
トンネル構成の考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NEMO 集合内の情報交換の考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
無通信時の動作の考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
通信発生時の動作の考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5.1 アプリケーション要求 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5.2 インターフェイス選択 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
アプリケーションの要求と無線通信インターフェイスの対応付け . . . . . . . . . .
本章のまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32
32
33
35
35
37
38
38
38
39

第 6 章 Mobile Routers Resource Sharing（MRRS）の設計
6.1 用語解説 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 MRRS のフローチャート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1 インターフェイス選択制御 . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.2 NMRL 広告受信時 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.3 通信情報広告受信時 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3 MRRS の状態遷移 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.1 状態 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.2 イベント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.3 状態遷移図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4 本章のまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40
40
41
41
44
44
46
46
48
50
50

第7章
7.1
7.2
7.3

51
51
51
51
52
55
57

3.3
3.4

5.6
5.7

Mobile Routers Resource Sharing の実装
実装環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
実装概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MRRS 実装の詳細 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.1 Neighbor Mobile Router List の管理 . . . . . . . . . . . . . . . . . . . . .
7.3.2 トラフィック情報の管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.3 インターフェイス制御 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
v

7.3.4 トラフィックの分散機構 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
本章のまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58
59

第 8 章 評価と考察
8.1 評価手法の検討 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2 評価環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.1 実験環境のネットワーク構成 . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.2 評価環境のネットワーク性能測定 . . . . . . . . . . . . . . . . . . . . . . .
8.3 定性評価 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.1 移動ルータ間の情報交換 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.2 動的なネットワーク構成の変更 . . . . . . . . . . . . . . . . . . . . . . . .
8.3.3 トラフィックの振り分け . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4 定量評価 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4.1 TCP トラッフィク発生時のスループットと RTT の計測 . . . . . . . . . .
8.4.2 TCP と UDP トラッフィク発生時のスループットと RTT の計測 . . . . . .
8.4.3 バッテリ消耗の抑制 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5 本章のまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

60
60
60
60
61
63
63
64
66
66
67
69
72
73

第 9 章 結論:研究のまとめと今後の課題
9.1 研究のまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2 今後の課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

74
74
74

付 録 A バッテリ残存時間における無線インターフェイスの起動と NEMO 動作の影響

81

7.4

付 録 B MRRS におけるローカル Binding と近隣移動ルータ経由の Binding の状態遷移表 82

図目次
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8

Mobile IPv6 の動作概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network Mobility の動作概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
複数 CoA 登録 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
パーソナルエリアネットワーク . . . . . . . . . . . . . . . . . . . . . . . . . . . .
自動車ネットワーク . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
想定ネットワーク利用状況 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NEMO 集合の例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NEMO 集合の現状と協調の必要性 . . . . . . . . . . . . . . . . . . . . . . . . . .

4
4
6
8
9
12
16
17

3.1
3.2
3.3

基本となる協調モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NEMO 集合における協調モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NEMO 集合における協調 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22
23
25

4.1
4.2

MGMN の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Multiple Mobile Routers Management の概要 . . . . . . . . . . . . . . . . . . . .

28
30

5.1
5.2
5.3
5.4
5.5

ネットワーク構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
トンネル構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NEMO 集合内の情報交換と動的ネットワーク構成の変更 . . . . . . . . . . . . . .
無通信時のバッテリ消耗の抑制 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
アプリケーション要求への対応 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32
33
35
36
39

6.1
6.2
6.3
6.4

MRRS におけるインターフェイス選択のフローチャート . . . . . . . . . . . . . .
NMRL 広告受信時のフローチャート . . . . . . . . . . . . . . . . . . . . . . . . .
通信広告受信時のフローチャート . . . . . . . . . . . . . . . . . . . . . . . . . . .
MRRS の状態遷移図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42
45
45
47

7.1
7.2
7.3
7.4
7.5
7.6
7.7
7.8

実装概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NMRL の管理 (ローカル外部インターフェイス情報) . . . . . . . . . . . . . . . . .
NMRL の管理 (近隣外部インターフェイス情報) . . . . . . . . . . . . . . . . . . .
トラフィック情報の管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ongoing Traﬃc 情報の取得の例 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
インターフェイス制御 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Netﬁlter を利用したトラフィック分散例 . . . . . . . . . . . . . . . . . . . . . . . .
ルーティングポリシーデータベース . . . . . . . . . . . . . . . . . . . . . . . . . .

52
52
53
56
56
58
59
59

8.1

実験環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

vii

8.2 tc コマンドによる通帯信域と通信遅延の設定例 . . . . . . . . . . . . . . . . . . . .
8.3 実験環境の評価 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4 NMRL の同期 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5 トラフィック情報の同期 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.6 電源供給状況の変化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.7 バッテリーセーブ状態への移行 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.8 トラフィック発生によるネットワーク構成の変更 . . . . . . . . . . . . . . . . . . .
8.9 通信の分配ポリシ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.10 ポート番号によるトラッフィクの振り分け . . . . . . . . . . . . . . . . . . . . . .
8.11 TCP 通信における移動ルータの参加 . . . . . . . . . . . . . . . . . . . . . . . . .
8.12 TCP 通信における移動ルータの参加によるスループットの変化 . . . . . . . . . .
8.13 TCP と UDP の混在通信における移動ルータの参加 . . . . . . . . . . . . . . . . .
8.14 TCP と UDP の混在通信における移動ルータの参加によるスループットの変化 . .
8.15 バッテリ消耗の抑制 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61
62
63
64
65
65
65
66
66
67
68
70
71
72

A.1 バッテリ残存時間における無線インターフェイスの起動と NEMO 動作の影響 . . .

81

表目次
2.1
2.2
2.3
2.4

無線通信メディアの整理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
バッテリ残存時間における無線デバイスの起動と NEMO 動作の影響 . . . . . . . .
移動体通信の通信品質向上に利用可能な情報例 . . . . . . . . . . . . . . . . . . . .
NEMO 集合における内部接続性と外部接続性の特徴 . . . . . . . . . . . . . . . . .

11
13
14
16

3.1

NEMO 集合における協調モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

4.1

関連研究の比較 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

5.1

ネットワーク構成の特徴 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

6.1
6.2

Neighbor Mobile Router List 広告のフォーマット . . . . . . . . . . . . . . . . . .
通信情報広告のフォーマット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41
41

8.1
8.2
8.3
8.4

各 PC の構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
実験環境の評価 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TCP 通信における移動ルータの参加によるスループットと RTT の変化 . . . . . .
実験環境の評価 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61
62
69
70

B.1 MRRS におけるローカル Binding の状態遷移表 . . . . . . . . . . . . . . . . . . .
B.2 MRRS における近隣移動ルータ経由の Binding の状態遷移表 . . . . . . . . . . . .

83
84

第 1 章 序論
本章では，本研究の背景，本研究の目的を述べる．また，本研究の構成について示す．

1.1

本研究の背景IEEE802.11a[1]/b[2]/g[3] や DSRC[4]，Bluetooth[5] など無線でのインターネット接続が整備されるに従い，計算機は場所を選ばずにインターネットへ接続できるようになった．そのため，移動中においても計算機をインターネットに接続することへの要求が高まっている．
しかし，移動する計算機をインターネットへ接続すると，既存のインターネットアーキテクチャ[6] では接続しているネットワークを切り替えると，IP アドレスが変化してしまう．これにより計算機が移動するたびに継続中のセッションが遮断されたり，通信相手が特定できない問題が発生する．これらの問題を解決するため，Mobile IPv6[7] という移動体通信技術が提案された．
Mobile IPv6 は移動するホストごとに問題を解決する仕組みを必要とするため，ホスト全てに
Mobile IPv6 の技術を組み込む必要が生じる．計算機を群として捉え移動をサポートするために
Mobile IPv6 を拡張した Network Mobility(NEMO)[8] が提案された．NEMO 基本仕様では 1 つの移動ルータが計算機群を代表して移動体通信機能を担当する．これにより，計算機群内のすべての計算機に移動体通信機能を組み込む必要が生じない．
これらの移動体支援技術によって，自動車内のセンサノードや人間が身に付けるウェアラブル
センサなどの大量の移動ノードがインターネットに接続することが可能になった．また，WIDE
プロジェクト [9] インターネット自動車ワーキンググループ [10] では，車両のスピードやブレーキ状態などの車両情報を自動車間で交換することで，自動車同士の協調作業を支援し，交通事故や交通渋滞などさまざまな交通問題を解決することを目指している．
一方，無線メディアによるインターネット接続は，通信可能エリアが無線電波の届く範囲に限られており，計算機の移動や障害物の存在によって通信の安定性に欠ける．また，広範囲で利用可能な長距離無線を用いた通信の通信可能エリアが広いため，その安定性は比較的良いが通信の帯域が限られる問題がある．これら無線メディアの特性を克服するため，複数無線インターフェ
イスの切替え利用や同時利用の研究 [11] が行われている．
また，無線メディアは遅延や帯域，金銭的な通信コストなどの特性がさまざまである．アプリ
ケーションが要求する特性を基に，無線メディアを選択する研究 [12] が行われている．
さらに，無線メディアは，移動体通信において非常に貴重な資源であるバッテリを消費させる
大きな要因である．計算機に複数の無線インターフェイスを搭載している場合，通信やバッテリなどの状況によっては多くの無線インターフェイスを起動することは望ましくない．通信やバッ
テリなどの状況によって，利用する無線インターフェイスが起動されるべきである．
一方，想定される移動計算機やセンサは，集合として移動しているケースが多い．例えば，人はウェアラブルセンサを身に付け，携帯電話，PDA1 を持ち歩く．また，このような人が，さまざま
1

Personal Digital Assistants

11.2. 本研究の目的なセンサが設置されている自動車に搭乗する場合などである．この場合，自動車内のネットワー
クには，自動車に設置されたセンサの他，搭乗者の持ち込むセンサや携帯端末が集合を構成する．
個別の計算機を対象とした移動体通信環境を改善するため仕組みでは，資源の利用効率は個別最適にとどまるため，移動計算機の集合全体では非効率となる．

1.2

本研究の目的

本研究の目的は，移動計算機群内の移動ルータを協調動作させ，移動ネットワークの単独の移動ルータへの依存を解消することである．各計算機の持つ無線デバイスをはじめとするさまざまな計算機資源を，通信の状態や資源の状態に応じて NEMO 集合内で相互に利用できる環境を作る
ことで，NEMO 集合全体の資源の利用効率を高めることを可能とする．利用されていない無線メディアを NEMO 集合内の他の計算機と共有したり，NEMO 集合内で，機能や性能が重複する無線メディアの一部を停止することで，バッテリ消耗を抑制する．

1.3

本研究の構成第 2 章では，本研究で想定する NEMO 集合の環境を説明し，本研究分野における本研究の位置
づけの説明を行なう．第 3 章では，NEMO 集合内の協調について議論し，問題点をまとめ要求事
項を整理する．第 4 章では，関連研究について説明を行なう．またそれぞれの技術と本研究の要求
事項との関係を考察する．第 5 章では，要求事項を満たすための方針を決定する．そのため，要求事項を満たすための機能ごとに考察を行なう．方針から，要求を満たすモデルとして提案する．
第 6 章では，提案したモデルに従い，Mobile Routers Resource Sharing（MRRS）の設計を行なう．第 7 章では，本研究で実装したシステムを説明する．第 8 章では，定性的評価と定量的評価について述べる．第 9 章において，本研究のまとめと今後の課題について述べる．

2

第 2 章 NEMO 集合における通信環境
移動体計算機における通信は，移動体通信技術を利用することで，インターネット上の移動による問題を解決する．また，複数の無線通信メディアを用いた通信を行うことで，無線通信メディ
アによる制約を緩和させたり，アプリケーションの要求に対応する通信メディアを選択すること
で，通信の性能を向上させる．本章では，移動体計算機における通信環境をまとめる．2.1 節において NEMO と複数 CoA 登録の移動体通信の要素技術を解説し，2.2 節で，これらの移動体通信技
術の利用環境を示す．2.3 節で，NEMO 利用における通信環境を説明し，求められている通信環
境について説明する．2.4 節で，NEMO 集合の環境について述べる．2.5 節では，複数通信メディアを利用した通信品質の向上の要求に付いて述べ，NEMO 集合内の協調の必要性について議論する．最後に，2.6 節で NEMO 集合環境によって新たに発生する問題について述べる．

2.1

移動体通信の要素技術

本研究に深く関わる移動体通信技術として，2.1.1 節で Mobile IPv6 と NEMO について示す．
また，移動体通信技術において複数無線インターフェイス利用を可能とする技術として，2.1.2 節
で複数 CoA 登録について説明する．

2.1.1

Mobile IPv6 と Network Mobility (NEMO) の概要

Mobile IPv6 は古くから開発されている移動体通信技術であるため，これを拡張した研究は数多い．そのなかに，本研究に関連する研究もあることから，関連研究として Mobile IPv6 を説明す
る．Mobile IPv6 の IETF[13] における標準化活動は，10 年にも及ぶ議論の結果 2004 年 6 月に終了した．現在は RFC3775[7] となっている．NEMO は移動計算機群の通信に不可欠で，本研究の目指すインターネット利用環境に深く関わる．そのため，本節では NEMO の標準化状況や基本的動作などを説明する．
NEMO は次世代インターネット環境における移動体通信技術として標準化に向けて IETF において NEMO Working Group(NEMO WG)[14] で議論されている．NEMO の利用は広範囲にわたることが想定され，早期の仕様の決定が望まれている．そのため NEMO WG では標準化の議論を簡略化し，早期に仕様の決定を行なうため，NEMO の仕様を NEMO 基本仕様と NEMO 拡張仕様に区別した．NEMO 基本仕様は経路最適化や，複数経路利用を含まない仕様であり，NEMO
拡張仕様はそれらが含まれる予定である．その上で，現在，NEMO 基本仕様が先に標準化された．
本節では NEMO 基本仕様について解説を行なう．
Mobile IPv6 と NEMO の用語は共通のものが多い．以下に，Mobile IPv6 と NEMO の用語を解説する．図 2.1 に Mobile IPv6 の概要を示し，図 2.2 に NEMO の概要を示す．
以下に NEMO の用語を示す．

3

2.1. 移動体通信の要素技術

Correspondent Node (CN)Home Agent(HA)

BC
BC

CN

Foreign link

Binding Update

HA

Internet

Foreign Link

Home link

AR

Internet

Home Link

AP

AR

AP

2. Binding Update

(a)
BUL

BUL
MN

MR

移動ルータ

MNN

移動

MR
MNN

1. 移動
移動ネットワーク

Mobile Network Node

図 2.2: Network Mobility の動作概要

図 2.1: Mobile IPv6 の動作概要• 移動ノード (MN)
移動体ノード．ネットワーク間を移動するノード．

• 移動ルータ (MR)
移動ネットワークを提供しているルータ．

• Home Agent(HA)
移動ネットワークのインターネット上の位置を把握している計算機．

• Correspondent Node(CN)通信相手の計算機．

• Home Link
Home Agent が接続したリンク．
• Foreign Link
移動ルータの移動先のリンク．

• Home Address
移動ルータを識別するための不変の IP アドレス．

• Care of Address(CoA)
移動先のネットワークで与えられる IP アドレス．

• BindingHome Address と Care-of Address の対応付け．移動ルータの Care-of Address は移動によって変化するが，Home Agent は Home Address と Care-of Address を対応付けることで転送先を識別する．Home Agent は対応付けのデータを Binding Cache (BC) によって管理する．
移動ルータは Binding Cache を更新するため Home Agent に Care-of Address を通知する．
このメッセージを Binding Update といい，Home Agent は移動ルータへ登録が正常に終了
4

第 2 章 NEMO 集合における通信環境したことを伝える．このメッセージを Binding Acknowledgement と呼ぶ．また，移動ルー
タは Binding Update を行なう計算機を Binding Update List（BUL）によって管理する．

• 移動ネットワーク
NEMO によって移動透過性・着信可能性をもつネットワーク．
• Mobile Network Node(MNN)
移動ネットワーク内のノード．

• 外部インターフェイス
移動ルータの持つインターネットへ接続された通信インターフェイス．

• 内部インターフェイス
移動ルータの持つ移動ネットワーク側の通信インターフェイス．

• Mobile Network Preﬁx (MNP)
移動ネットワークに広告されているネットワークプレフィクス．

Mobile IPv6 では図 2.1 に示す通り，Home Agent が MN の Care-of Address と Home Addressの対応づけを行なっている．移動ノードはネットワークを移動し新たな Care-of Address を取得す
ると Home Agent へと Care-of Address を通知する (Binding Update)．Home Agent は移動ノードの Home Address 宛のパケットを最新の Care-of Address へ転送することで，移動ノードは常に一意の IP アドレスで認識される．これによって，移動ノードは移動透過性と着信可能性を持つ．
通信の経路は図 2.1 中の (a) のように Home Agent を経由する．この他，Home Agent を経由しない通信を行なうための手法も標準化されているが，本研究と直接関係しないので省略する．
NEMO では，図 2.2 に示す通り，移動ルータは (MR) は常に不変のネットワークである移動ネッ
トワークを移動ネットワークに接続している Mobile Network Node(MNN) に提供している．移動ルータは異なるリンクへ移動すると移動先のネットワークで取得した Care of Address(CoA)を Home Agent(HA) に通知する．これにより，Home Agent は移動ルータに接続する移動ネット
ワークのネットワーク上の位置を把握する．その後，その移動ネットワーク宛のパケットを移動
ルータに転送することによって移動ネットワークはネットワーク上の移動を実現している．Home
Agent はパケット転送を行なう際，パケットに IP ヘッダを加える IP-in-IP カプセル化の処理を行う．Home Agent と移動ルータの間にはトンネルが生成される．トンネルの処理は移動ルータから Home Agent に転送される際にも行なわれる．この Home Agent と移動ルータでのヘッダを脱着する処理は Bi-directional トンネルリングと呼ばれる．

2.1.2

複数 CoA 登録の概要

NEMO では，Home Agent において移動ルータの取得した Care-of address を移動ルータの Home
Address と対応づける．NEMO 基本仕様では，Care-of Address と Home Address は必ず，１対１で対応づけられるため，同時に複数の Care-of Address を登録することができない．Home Address
は必ず，ひとつの Care-of Address に対応づけられる．つまり，複数の外部インターフェイスを備えている移動ルータにおいても，それらを同時に利用することはできない．TCP と UDP など異5

2.1. 移動体通信の要素技術

なる特性を持つ通信が同時に発生した場合など，複数の外部インターフェイスを同時に利用することが要求される．
複数の外部インターフェイスを同時に利用するため，Home Address を複数の Care-of Addressに対応づける必要がある．Multiple Care-of Address registration （複数 CoA 登録）[11] では，
Mobile IPv6 および NEMO で単一の HoA に対して複数の Binding を登録する手法について議論している．これは，本研究の要求事項に含まれるものであるため，関連研究として紹介する．
本節では，まず複数 CoA 登録で新たに定義された用語について解説し，動作概要について述べる．以下に用語の解説を行なう．
Binding Cache
HoA
CoA
2001::1111 2001:2::EUI64
2001::1111 2001:3::EUI64
2001::1111 2001:4::EUI64

Frag
R/M
R/M
R/M

BID lifetime
1111 102222 103333 10NEMO prefix table
HoA
MNP
2001::1111 2001:1:0:1::

length64

BC

CN

HA 2001:1::2

Internet

Foreign link
2001:2::/64

Foreign link
2001:3::/64

Foreign link
2001:4::/64

AR

AR
AR

CoA 2001:2::EUI64
BID 1111

Binding Update List
HA address CoA
2001:1::2
2001:2::EUI64
2001:1::2
2001:3::EUI64
2001:1::2
2001:4::EUI64

Home link
2001:1::/64

AR

CoA 2001:3::EUI64
BID 2222

BUL

CoA 2001:4::EUI64
BID 3333
HoA 2001::1111
MNP 2001:1:0:1::/64

MR

BID lifetime
1111 102222 103333 10
MNN

MNN

図 2.3: 複数 CoA 登録• Binding Unique Identiﬁcation number (BID)
BID は複数の Binding 登録を区別するための識別子である．Mobile Node は重複しない方法で BID を生成する．値には，負の数ではない整数を用いる．BID は管理者のポリシにしたがって，任意の時間で変更可能である．
• Primary Care-of Address (Primary CoA)6

第 2 章 NEMO 集合における通信環境

Primary Care-of Address とは Home Address に関連づけられた，プライマリの Care-of
Address である．Mobile Node は常にプライマリの Care-of Address を選択していなければならない．もし Primary Care-of Address が無効になった場合には，プライマリの Care-of
Address を選び直さなければならない．
• Binding Unique Identiﬁer sub-option
BID を記述するためのサブオプション．
複数の Care-of Address を取得した Mobile Node は Primary Care-of Address を選択し，Primary
Care-of Address を取得している外部インターフェイスをプライマリの外部インターフェイスとする．その後，Binding Unique Identiﬁer sub-option を付帯した Binding Update を行う．この時，複数 CoA 登録を示す’M’ フラグをセットする．Binding Update には重複しない BID を添付する．
Home Agent は Binding Update を受け付けると Binding Cache を追加するとともに BID も登録する．この登録の後，同様に Mobile Node はプライマリでない Care-of Address の登録を行う．図2.3 に 3 つの外部インターフェイスを搭載する移動ルータが 3 つの Care-of Address を取得した際の各 Care-of Address と BID の関係を示した．移動ルータは，各 Care-of Address （2001:2::EUI，2001:3::EUI，2001:4::EUI）に重複しない BID（1111，2222，3333）を対応付けて Binding Updateを送信する．Binding Update には，NEMO 基本仕様を示す’ R’ フラグと，複数 CoA 登録を示
す’M’ フラグをセットされている．Home Agent では，ひとつの Home Address（2001::1111）に複数の Care-of Address を対応づける．
BID は Home Address で Binding Cache を検索するのと同様に，Binding Cache を検索する鍵として用いられる．Home Agent は Home Address と BID の両方を鍵として用い，Binding Cache の検索を行なう．検索の結果，Home Address と BID が合致した Binding をルーティングに用いる．
どの BID をどの通信に用いるかは，ユーザのポリシとフィルタ情報によって事前に決めておく．
複数の Care-of Address のうちの 1 つが変更になった場合，MN は BID を含む Binding Updateを行なう．Binding Update を受け取ったノードは，BID に合致した Binding を更新する．
Mobile Node が 1 つの Care-of Address だけを登録することにした時，’M’ フラグを含まない
Primary Care-of Address の Binding Update を行なう．それによって，Binding Update を受け取ったノードは，Primary Care-of Address を登録し，Primary Care-of Address の Binding Cache以外を削除する．
また，Mobile IPv6 および Network Mobility の標準仕様において，ある Care-of Address で通信不能になった際，通信不能になった Care-of Address を Home Agent に通知することはできな
い．複数 CoA 登録においては通信不能でない Care-of Address を通じて Home Agent に通信不能となった Care-of Address を通知することができる．この処理は，Binding Update に Alternate
Care-of Address サブオプションを追加することで行なう．同様に，Binding Update に Alternate
Care-of Address サブオプションを追加することによって，一回の Binding Update で複数の Careof Address を登録することができる．これにより，広帯域／低遅延／低コストなインターフェイスを用いて，狭帯域／高遅延／高コストなインターフェイスの Care-of Address を通知することができる．

7

2.2. NEMO の利用

NEMO の利用

2.2

無線技術の発展や普及や 2.1 節の移動体通信技術の標準化によって，自動車や人が身に着けるウェアラブルセンサがインターネットに接続することが可能になった．2.2.1 節，2.2.2 節でそれぞれパーソナルエリアネットワークとインターネット自動車において，接続している計算機や，想定アプリケーションについて述べる．

2.2.1

パーソナルエリアネットワーク

パーソナルエリアネットワークは数十 cm から数 m といった人間の身の回りの計算機を接続したネットワークである．ノート PC や PDA，携帯端末などのモバイル端末のほか，ウェアラブル
センサなどが接続される．人間の移動によって利用できるネットワーク環境が変化するため，移動による問題を解決できる NEMO の利用が検討されている．
図 2.4 に示すとおり，パーソナルエリアネットワークがインターネットに移動体通信技術を利用して接続されると，さまざまなアプリケーションが登場すると予想される．パーソナルエリアネッ
トワークの想定環境を以下に挙げる．

携帯電話

Mobile Router (MR)

ウェアラブルセンサ-位置センサ-健康センサ-運動センサ
音楽プレイヤPersonal Area Network

図 2.4: パーソナルエリアネットワーク• パーソナルエリアネットワーク内の計算機
パーソナルエリアネットワーク内の計算機はウェアラブルセンサとその他のモバイル端末に分類される．ウェアラブルセンサは，身に着ける人の状態や，その周りの状況を計測できる機器である．例として，体温，脈拍など，健康に関する状態や，位置情報など行動に関する情報を取得するためセンサが挙げられる．モバイル端末は，携帯電話や PDA などのように
外部接続性を持ち NEMO などの移動体通信技術を搭載しているものと，音楽プレイヤ，電子辞書のように直接移動体通信技術が組み込まれていないものに分類される．

8

第 2 章 NEMO 集合における通信環境• 想定アプリケーション
パーソナルエリアネットワークでは，移動体通信技術によって移動透過性を確保されているため，通常の固定のインターネットで利用されるアプリケーションを利用できる．つまり，
Web ブラウジングや E メール，音楽のダウンロード，遠隔会議のビデオストリーミングなどである．これらの多くのアプリケーションは，移動ネットワークにユーザがおり，モバイ
ル端末がクライアント，インターネット上に設置された計算機にサーバとなる．このため，
これらの通信は移動ネットワーク側からインターネット側へ対して開始される．
一方，移動ネットワーク内のウェアラブルセンサの情報がインターネット上の計算機から利用可能になると，さまざまな情報を共有することができるようになる．例えば，体温，心拍数，血圧などを測定するセンサがインターネットへ接続されることで，リアルタイムに遠隔で健康に関する診断を受けられる．また，歩行時間や自転車の走行距離などの運動に関するデータを遠隔のトレーナと共有することで，より的確な指導を受けることが可能となる．こうしたサービスは，インターネット上の計算機から移動ネットワーク内のセンサへとアクセスする可能性がある．そのため，移動体通信技術が提供する着信可能性と，常時接続制が非常に重要な要素となる．

2.2.2

インターネット自動車

インターネット自動車では，自動車ネットワーク内の計算機がインターネットに接続され，自動車の持つ情報を互いに交換する．運転者たちが各自同社の情報を共有することでより安全で快適な交通を実現する．自動車には，自動車の情報を取得するため，さまざまなセンサが搭載される．
インターネット自動車では，移動に関する問題を解決できる NEMO の利用が検討されている．
図 2.5 に示すとおり，自動車内のさまざまな計算機がインターネットへ接続されると，さまざま
なアプリケーションが登場することが予想される．インターネット自動車の想定環境を以下に挙
げる．

車載ルータ

Mobile Router (MR)

自動車センサ- 位置センサ- スピードセンサ- ブレーキセンサ

カーナビ

ビデオカメラ

Vehicle Network

図 2.5: 自動車ネットワーク

9

2.3. NEMO 利用における通信環境と要求

インターネット自動車内計算機
インターネット自動車内のネットワークに接続する計算機は，自動車センサとそれ以外の計算機に分類される．自動車センサは，位置，スピード，ブレーキ，ワイパーの起動状況，オイルのメー
タなどの自動車の状態を取得するものである．それ以外の計算機は，外部接続性を持ち，NEMOの機能を搭載した車載ルータと，それらを持たないカーナビゲーションシステムや車載サーバな
どの計算機などがある．

想定アプリケーション
インターネット自動車は，パーソナルエリアネットワークと同様に移動体通信技術によって移動透過性を確保されているため，通常の固定のインターネットで利用されるアプリケーションを利用できる．これらの通信は移動ネットワーク側からインターネット側へ対して開始される．
一方，自動車をインターネットへ接続すると，自動車内に設置されたセンサの情報にインター
ネットを通じて参照可能となり，それらのセンサが発信する情報を互いに交換することで，さまざまな問題を解決できる．インターネット自動車プロジェクト [10] では，車両のスピードやブレー
キ状態などの車両情報を自動車間で交換することで，自動車同士の協調作業を支援し，交通事故や交通渋滞などさまざまな交通問題を解決することを目指している．例えば，運転者が各自動車のスピード情報を共有できれば，交通渋滞をリアルタイムに把握できる．また，急激なブレーキが動作した地点の情報を収集すれば，危険な道路を事故の起こる前に特定することが可能となる．

2.3

NEMO 利用における通信環境と要求

本節では，NEMO を利用する際の，通信環境の向上に対する要求にについて第 2.3.4 節に述べる．要求を満たすために，移動ルータが複数インターフェイスを利用するための対応などに付いて述べる．そのため，まず第 2.3.1 節で NEMO で利用されることが想定される無線通信メディアを整理し，第 2.3.2 節に NEMO における通信の利用状況，第 2.3.3 計算機資源の利用などについて説明する．

2.3.1

無線通信メディアの整理

NEMO で利用が想定される無線通信メディアは，通信範囲，通信帯域，通信遅延など異なる特性を持つ．全ての地域で利用可能な無線通信メディアは存在しないことや，全ての通信に適した
無線通信メディアは存在しないため，無線通信メディアは選択利用されるべきである．第 2.3.4 節に述べる要求事項を説明するため，本章では，NEMO において利用が想定される無線通信メディ
アを整理する．
無線通信メディアには，1 対多の同報型の通信と，1 対 1 のユニキャスト型の通信がある．ユニ
キャスト型の無線通信メディアは，一般的にアクセスポイントとノード，またはノード同士を接続する無線リンクである．無線リンクはあるエリアにおいての通信帯域の全量が決まっており，無線リンクに接続している全ノードで通信帯域を共有する．そのため，無線リンクに接続している数が増加すると，ひとつのノードが利用できる通信帯域は減少する．よって，利用可能範囲が狭い無線通信メディアは，少数のノードで帯域を利用できるため，広帯域であり，反対に利用範囲が広い無線通信メディアにおいては，各ノードが利用できる通信帯域が減少する傾向がある．一10

第 2 章 NEMO 集合における通信環境

方，利用可能範囲が狭い無線通信メディアはノードが移動によってアクセスポイントが利用できるエリアを離脱したり，アクセスポイントを変更することが頻繁になり，通信の安定性が低くな
る．広域で利用できる無線通信メディアは通信の安定性が高い．
本研究では，無線通信メディアはその通信距離や利用用途，特徴に応じて，近距離無線通信メ
ディア，境域通信メディア，中域通信メディア，広域通信メディアに分類した．各無線通信メディ
アを表 2.1 にまとめる．
短距離無線メディアとして，Bluetooth[5]，Zigbee[15] などの通信メディアが標準化されている．
通信距離は，主に人間 1 人が自分の直接的な活動を示す範囲である 20 メートルほどの通信メディア
である．パーソナルエリアネットワーク（PAN，Personal Area Network）内での利用が検討されている．また，高速道路の課金システムに利用されている Dedicated Short-Range Communication（DSRC）[4] も通信範囲から短距離無線メディアに分類される．
狭域通信メディアは，一般的に無線 LAN として知られており，IEEE802.11 により IEEE802.11a[1]/b[2]/g[3] として標準化されている．主にローカルネットワーク（LAN，Local Area Network）を構築するために利用される．これらの通信メディアの通信帯域は，11Mbps〜54 Mbps であり，
日本では IEEE802.11b/g は野外で利用可能であるが，IEEE802.11a は室内のみの利用となる．これらの無線メディアは障害物の影響を多く受けることが知られているが，通信範囲は数十メート
ルから数百メートルである．
中域通信メディアは，IEEE802.16[16]，IEEE802.16a[17] と IEEE802.16e[18]（WiMAX），IEEE802.20（iBurst）[19] などが登場している．IEEE 802.16 規格は 10〜66GHz の周波数帯を使用し，IEEE
802.16 の派生規格である IEEE802.16a 規格では 2〜11GHz を利用する．これらの無線メディアは，1
台のアンテナで約 50km をカバーし，最大で 70Mbps の通信を可能としている．また，市街全体をカバー可能な数百 km を通信範囲とし，主に，メトロポリタンネットワーク（MAN，Metropolitan Area
Network）を構築することを想定している．固定のアンテナへの通信を前提とする IEEE802.16aに対し，IEEE 802.16e では時速 150〜200km までの移動体に対応する．20MHz の帯域幅を使用した場合，最大 75Mbps 程度の通信が可能となる．また，1 つの基地局で半径数 km 程度のエリアをカバーでき，見通しのきかない範囲でも通信を行える特性がある．
広域通信メディアは，PHS（Personal Handy-phone System）[20] や第三世代携帯電話とよばれる cdma2000[21]，IMT2000[22] が標準化されている．カバーエリアは国規模にのぼり，広域網（WAN，Wide Area Network）での利用が想定されている．

メディアタイプ
利用用途
カバーエリア
通信帯域例

表 2.1: 無線通信メディアの整理
短距離無線
狭域
中域

PAN
〜 20 m
〜 1Gbps
DSRC
Bluetooth
UWB
ZigBeeLAN〜数百 m
11Mbps 〜54 Mbps
IEEE 802.11a
IEEE 802.11b
IEEE 802.11g

11MAN〜約 50 km
〜約 70Mbps
IEEE 802.16
IEEE 802.16aIEEE 802.20

広域WAN〜約 50 Km
〜2 MbpsPHS
W-CDMA
cdma20002.3. NEMO 利用における通信環境と要求

2.3.2

想定ネットワーク利用状況

移動ネットワークに発生する通信は，通信の開始の方向から 2 つに分類できる．はじめに移動
ネットワーク内の移動端末がインターネット上のサーバを利用する場合である．通信の開始は移動端末からインターネット上のノードになされる．カーナビによる地図データのダウンロードや，
音楽プレイヤによる音楽や曲リストのダウンロードがこれにあたる（図 2.6 の（１））．
もうひとつは，インターネット上のノードが，移動ネットワーク内のノードにアクセスする場合である．通信の開始はインターネット上のノードから移動端末になされる．医師が人間の身に着ける健康センサの情報を参照する場合や，インターネット上のノードがインターネット自動車
内のセンサの情報にアクセスする場合などがある（図 2.6 の（２））．
また，図 2.6 の（３）に示したように，Voice over IP（VoIP）[23, 24] のサービスのように通信の開始が，移動ネットワーク内のノード，もしくはインターネット上のノードどちらから始まる
か定まっていないサービスも存在する．
次世代移動体通信インターネットにおいては，センサノードの情報の交換などの通信が増加することが予想されている [25]．ビデオ会議システムのストリーミングや音楽ファイルのダウンロー
ドなどの激しく無線メディアの帯域を消費する期間以外に，センサへの着信を待ち受ける期間が想定される．移動ネットワークは通信が発生していない場合でも，インターネット上のノードからの着信の可能性を考慮して，通信を待ち受ける必要がある．

医師のPC

(1)

音楽サーバ

携帯電話

(3)

(2)

Internet

ウェアラブルセンサ

音楽プレイヤ

携帯電話

Personal Area Network
図 2.6: 想定ネットワーク利用状況

2.3.3

移動ルータの電源

移動体通信において，移動ネットワークの着信可能性，常時接続制を保証する移動ルータはもっとも重要な機器である．また，移動ネットワークの通信は，全て移動ルータを経由するため，移12

第 2 章 NEMO 集合における通信環境

動ルータが動作停止すると，独自に外部接続性を持たない移動ネットワーク内の計算機全てが通信不能になる．そのため，移動ルータを動作させる電源は，移動ネットワーク内でも最も貴重な資源のひとつであるといえる．
移動する計算機の多くは，AC による電源供給を受けられないため，一般的にはバッテリを搭載
し，電源とする．例えば，パーソナルエリアネットワークでは，携帯電話や PDA などの携帯端末が移動ルータを担当すると考えられる．人間が持ち歩く携帯端末の電源がバッテリであるため，こうした移動ルータは，バッテリが非常に重要な資源となる．そのため，バッテリ消耗を抑制する
非常に大きな要求がある．
移動ルータは，インターネットから移動ネットワークへの通信を待ち受ける必要性から，常時ひとつ以上の Care-of Address を Home Agent に登録する．そのため移動ルータは定期的，またはネットワーク間を移動する際，Binding Update を送信する必要がある．この間，無線通信デバ
イスを起動しておく必要が生じる．無線デバイスの起動やパケットの送信はバッテリの消耗に悪影響を及ぼすことが知られている [26, 27]．
本研究では，無線デバイスの起動と NEMO の動作がバッテリの消耗に及ぼす影響を調べ，実験
結果を表 2.2 にまとめた（実験の詳細は付録 A 参照）．表 2.2 の実験結果によると，NEMO の動作の有無は，バッテリの残存時間に影響しないことが示された．一方，無線（IEEE802.11b）有効を有効にした場合は，Binding Update の送信，Binding Acknowledgement の受信を含む NEMOの動作の有無に関わらず，バッテリ残存時間の低下が見られた．バッテリ消耗には，無線の起動が大きく影響することが示された．
表 2.2: バッテリ残存時間における無線デバイスの起動と NEMO 動作の影響
NEMO を無効
NEMO を有効（Binding ライフタイム 30 秒）
有線のみ
無線（IEEE802.11b）有効

6 時間 56 分
6 時間 01 分

6 時間 46 分
5 時間 59 分

人間が持ち歩く携帯端末のバッテリが非常に重要な資源となる一方，乗物に設置される移動ルー
タの電源による制約は緩い傾向がある．電車に設置される移動ルータは，有線による供給を受けることが可能である．また，自動車に設置される移動ルータは，エンジンから常にバッテリの充電を受けることが可能であるため，バッテリが非常に重要な資源とはならない．移動ルータにおけるバッテリの重要性は，個々の移動ルータによって異なり，均一ではない．バッテリ消耗を抑制する要求は，移動ルータのバッテリの供給状況や，バッテリ残量，通信の有無によって動的に変
化する．

2.3.4

NEMO における通信品質向上への要求

まず，本節において NEMO における通信品質向上への要求と，対策について説明する．
移動体通信において，一般的に，複数インターフェイスを切替え利用，同時利用することは，無線の利用可能範囲やネットワークの安定性，利用可能な帯域などが向上する利点がある．また，複数通信インターフェイスの中から，アプリケーションの要求に適した通信インターフェイスを選択することで，通信のユーザの要求に答えることが可能となる．しかし，一方，複数の無線イン
ターフェイスの起動はバッテリを消耗させるため，複数のインターフェイスの使用は必ず最善の13

2.3. NEMO 利用における通信環境と要求選択となるとは限らない．例えば，次世代移動体通信で想定されるセンサへの着信を待ち受ける
期間においては，最もバッテリの消耗の少ない無線インターフェイスだけを起動するほうが，バッ
テリの消耗を抑えられる点で適している．
複数の無線通信インターフェイスを利用するかは，状況によって判断する必要がある．移動体
通信における通信品質向上に利用可能な情報の例を表 2.3 に示した．本節では，ネットワーク帯域の増大，アプリケーション要求への対応，バッテリ消耗の抑制を考慮した動作を説明する．

情報の種類

表 2.3: 移動体通信の通信品質向上に利用可能な情報例
情報の例
アプリケーション層

通信の OSI モデル

トランスポート層
ネットワーク層
リンク層
物理層

Web，メール, SNMP，VoIP，
FTP，ビデオストリーミング
TCP，UDP
HoA，CoA，HA アドレス，送信先アドレス
通信デバイスの種類，AP 情報，
無線シグナルレベル，MTU
帯域，遅延ハードウェア

電源状態，インターフェイスの消費電力，CPU，
バッテリ残量，通信デバイス課金情報，メモリ，

移動ネットワーク

通信の有無• 通信の安定とネットワーク帯域の有効利用
複数インターフェイスを切替え利用，同時利用は通信の安定性，利用可能な帯域などが向上する利点がある．複数の通信インターフェイスを搭載している移動ルータは，複数 CoA 登録を利用して複数のトンネルを Home Agent との間に確立する．
無線通信メディアを利用する移動体通信においては，移動体とアクセスポイントとの位置が変化することによって，通信品質が動的に変化する．通信の安定のため，移動ルータが無線シグナルを監視し電波が微弱になるとその通信インターフェイスが利用不能になる前に通信を他の通信インターフェイスに移すことで通信の断絶期間を軽減することが可能である．
また，複数の通信インターフェイスを同時利用することで，全体として通信帯域の利用効率を高めることが可能である．例えば，移動ネットワーク内で複数の VoIP 端末が利用される
場合，送信元アドレスごとに違うインターフェイスに割り振ることで，輻輳を回避できる．

• アプリケーション要求への対応
複数インターフェイスを切替え利用，または同時利用は，アプリケーションの要求に答えるために有効である．アプリケーションは通信帯域や遅延に対し異なる要求を持つ．例えば，
双方向でリアルタイム性が要求される VoIP などの会話型のアプリケーションは低遅延への非常に大きな要求がある．一方，FTP などによるファイルのダウンロードやアップロード
は遅延に対する厳しい要求は無いものの，帯域が必要である．この他，通信の安定性を要求されるものや，アプリケーション要求が非常に緩やかなアプリケーションも存在する．移動14

第 2 章 NEMO 集合における通信環境

ルータが複数の無線通信インターフェイスを搭載する場合，単一の無線通信インターフェイ
スを利用するより，アプリケーションの要求に対応できる可能性が高い．

• バッテリ消耗の抑制
無線通信インターフェイスを搭載することは，通信の安定とネットワーク帯域の増大や，ア
プリケーション要求への対応など，さまざまな利点がある．しかし，NEMO の利用において想定される，移動ネットワーク内のノードへの着信を待ち受ける期間においては，複数
無線インターフェイスの弊害が発生する．複数無線インターフェイスを起動することによって，移動ルータのバッテリの消耗が増大する．待ち受け期間は，通信が行われていない期間であるため，複数の無線通信インターフェイスを起動する利点はない．そのため，移動ルー
タは，自身の持つ複数の無線通信インターフェイスの内，最も省エネルギーな無線通信イン
ターフェイスを起動し，移動ネットワークへの着信を待ち受ける．

2.4

NEMO 集合の登場

世界中で自動車が 10 億台に達する勢いで増大しており [28]，携帯電話はまもなく 2007 年には年間の総出荷台数が 10 億台を超える [29]．NEMO の標準化によってこれらを含む乗物や，パーソ
ナルエリアネットワークを構成する携帯端末に NEMO が搭載される．NEMO が普及するにしたがって，図 2.7 に示すような，自身の周りにパーソナルエリアネットワークを構築している搭乗者がインターネット自動車に乗り込む場合など，移動ネットワークと移動ネットワークが接続する
NEMO 集合が出現することが想定される．移動ネットワーク間の接続は，各移動ネットワークが近距離で接している場合に行われる．自動車内のネットワークは搭乗者の PC 利用に備えて，有線 LAN で構築されている場合には，パーソナルエリアネットワークは有線 LAN で接続される．
また，Ultra-Wideband (UWB)[30] に代表される広帯域，低遅延でさらに省電力である近距離無線を利用して接続する場合も想定される．無線メッシュネットワークのように素早くネットワー
クを構成でき，移動ネットワーク内の全てのノードに双方向通信が出来ることを想定する．

2.4.1

ネットワーク環境

本節では，本研究の対象となる NEMO 集合の環境を説明する．PDA，携帯電話および車載ルー
タなどの移動ルータは，それぞれ NEMO 基本仕様にしたがって，単一移動ルータ，単一 Home
Agent，単一移動ネットワークの環境で動作する．これらの移動ルータが特定の期間において動的に集合を構成し，集団で移動する．NEMO 集合が構成されている際は，複数移動ルータ，複数Home Agent，複数移動ネットワークの環境となる．移動ルータは，動的に NEMO 集合への参加・離脱を行うため，移動ルータの数，Home Agent の数，移動ネットワークの数は動的に変更される．
また，移動ネットワーク内のウェアラブルセンサや自動車センサなど，常時インターネットから着信可能である必要のあるノードが多数存在する．そのため，NEMO 集合が構成されている，
いないに関わらず，移動ネットワーク内のノードは一意の IP アドレスで識別される必要がある．
NEMO 集合は，複数の移動ネットワークが集合で移動するため，NEMO 集合内部ネットワー
クの構成は，長時間変化しないため，安定性が高い．一方，外部接続性は，移動によってアクセ
スポイントを切り替わったり，障害物が存在するため，比較的不安定である．また，NEMO 集合
内のネットワークは，有線や短距離無線で構成されるため，広帯域・低遅延という特性がある．ま15

2.4. NEMO 集合の登場

外部接続性

Internet

Mobile Router (MR)

Mobile Router (MR)

音楽プレイヤ

NEMO集合内部接続性

車載ルータ

携帯電話

自動車センサウェアラブルセンサ

Personal Area Network

ビデオカメラカーナビ

Vehicle Network

図 2.7: NEMO 集合の例
た，一般的に，短距離無線はより長距離の無線に比べ出力が低いため消費電力が小さい．NEMO
集合において一般的な内部接続性と外部接続性の特徴を表 2.4 にまとめた．
表 2.4: NEMO 集合における内部接続性と外部接続性の特徴

2.4.2

内部接続性

外部接続性

通信距離

短距離

長距離

ネットワーク環境

ネットワーク構成が長時間変化しない（安定性が高い）

アクセスポイントの変化や障害物の影響（安定性が低い）

通信帯域

広帯域

低帯域

通信遅延

低遅延

高遅延

消費電力

消費電力が低い

消費電力が高いNEMO 集合の計算機

NEMO 集合には複数の移動ルータが接続されている．それらの移動ルータが持つ無線通信イン
ターフェイスは 2.3.1 節に示したとおり，通信遅延・通信帯域，通信可能エリアなどの特徴がさまざまである．
また，NEMO 集合には携帯端末の移動ルータや，乗物に設置された移動ルータなど，多様な移動ルータが存在する．人間が持ち歩く携帯端末のバッテリが非常に重要な資源となる一方，自動16

第 2 章 NEMO 集合における通信環境

車に設置される移動ルータは，エンジンから常にバッテリの給電を受けることが可能であるなど，乗物に設置される移動ルータの電源による制約は緩い傾向がある．さらに，CPU やメモリといった計算機資源も，それぞれの移動ルータが処理すると想定される動作によってさまざまなものが搭載されている．

2.5

NEMO 集合の現状と協調の必要性

現状の NEMO 集合においても 2.3.4 節で述べた，移動体通信における通信品質向上への要求がある．各移動ルータは，それぞれに通信の安定とネットワーク帯域の増大，アプリケーション要求への対応，バッテリ消耗の抑制などを目指して，独立に動作する．そのため，個々の移動ルー
タが意志決定をしても個別に最適になり，NEMO 集合全体で最適にならない問題がある．それぞれの移動ネットワークは，単独の移動ルータに依存する．図 2.8 に NEMO 集合の例を示し，現状の問題点を示す．

Internet
起動

起動

起動

MR1

MR2
node

node

移動ネットワーク1

MR3

移動ネットワーク2

node

移動ネットワーク3
NEMO集合図 2.8: NEMO 集合の現状と協調の必要性• 通信の安定とネットワーク帯域の増大への制限
通信の安定のため，移動ルータが無線シグナルを監視し電波が微弱になると，その通信イン
ターフェイスが利用不能になる前に通信を他の通信インターフェイスに移すことで，通信の断絶期間を軽減することが可能である．また，複数の通信インターフェイスを同時利用することで，通信の輻輳を回避できる．しかし，移動ルータは，その移動ルータに搭載された無線通信インターフェイスのみを同時に利用するため，移動ネットワークの安定とネットワー
ク帯域の増大は個別の移動ルータによって行われる．NEMO 集合の問題点は，個々の移動ルータが意志決定をしても，全体で最適にならない点である．よって，移動ネットワークの通信の安定性とネットワーク帯域は単独の移動ルータの持つ無線通信インターフェイスに依存する．

• アプリケーション要求への対応への制限
移動ルータが複数の無線通信インターフェイスを搭載する場合，単一の無線通信インター
フェイスを利用するより，アプリケーションの要求に対応できる可能性が高い．しかし，移17

2.6. NEMO 集合の登場による問題点

動ルータは，その移動ルータに搭載されている無線通信インターフェイスを選択することで，アプリケーションの要求に応える．そのため，NEMO 集合において，個々の移動ルータが意志決定をしても，全体で最適にならない可能性がある．

• バッテリ消耗の抑制への制限
移動ネットワーク内のノードへの着信を待ち受ける期間においては，複数無線インターフェイスを起動することによって，移動ルータのバッテリの消耗が増大する．そのため，最も省
エネルギーな無線通信インターフェイスを起動し，移動ネットワークへの着信を待ち受ける．
しかし，それぞれの移動ルータは，その移動ルータに搭載されている無線通信インターフェ
イスの中で省エネルギーな無線通信インターフェイスを起動し，着信可能性を保証する．そのため，NEMO 集合において，個々の移動ルータが意志決定をしても個別に最適になり，全体で最適にならない．それぞれの移動ネットワークが，それぞれの移動ルータに搭載されている無線通信インターフェイスに依存している．
このように，現状の NEMO 集合では，各移動ルータは独立に動作するため，移動 nn 体通信における通信品質向上は，個別の移動ネットワークごとに最適になっている．それによってそれぞれの移動ネットワークは，単独の移動ルータに依存する問題が発生する．表 2.4 に示した通り，NEMO集合における内部接続性は，外部接続性と比較すると，ネットワーク安定性が高く，低遅延・広帯域である．そのため，近隣に接続している移動ルータによる NEMO 集合内の協調によって，通信環境を改善できると考えられる．次章では，NEMO 集合内の協調を議論する．

2.6

NEMO 集合の登場による問題点

本章では，NEMO 集合環境によって新たに発生する問題について述べる．

2.6.1

複数の移動ネットワークプレフィクスに関する問題

複数の移動ネットワークから構成される NEMO 集合は，任意の時期に新規の移動ルータが参加してする場合があり，複数の移動ネットワークプレフィクスが広告される．移動ネットワーク内の計算機は，新たに表れた移動ルータの広告する移動ネットワークプレフィクスから，複数の IP
アドレスを取得する．複数の移動ルータが動作している NEMO 集合では，全ての IP アドレスが利用可能である．しかし，移動ルータが NEMO 集合から離脱すると，NEMO 集合内では離脱した移動ルータが広告する移動ネットワークプレフィクスは到達不能となる．移動ネットワーク内のノードが複数の IP アドレスの中から，常に利用可能な IP アドレスを選択する必要がある．そのためには，移動ネットワーク内のノードは，離脱することのない移動ルータをあらかじめ知る必要がある．一方，通信相手から，移動ネットワーク内のノードへ通信が開始される場合は，移動ネットワーク内のノードの IP アドレスが宛先アドレスとして指定されるため，移動ネットワー
ク内のノードの IP アドレス選択の問題は発生しない．

2.6.2

NEMO 集合の境界に関する問題

2.4 節において，NEMO 集合は，移動ルータの内部インターフェイス同士が接続した状態と定義した．しかし，ある移動ルータが内部インターフェイスで接続したネットワークが他の移動ルー
18

第 2 章 NEMO 集合における通信環境

タの内部インターフェイスに接続する移動ネットワークでない場合もある．移動ルータは，内部
インターフェイスで接続したネットワークが，他の移動ルータの内部インターフェイスに接続する移動ネットワークであるか確かめる必要が生じる．

2.7

本章のまとめ

本章では，まず NEMO と Mobile IPv6 の移動通信技術の概要と利用環境について述べた．また，NEMO の普及によって移動ルータ同士が接続する NEMO 集合が登場する可能性について述
べた．NEMO 集合では，従来どおり個別の移動ルータで通信品質の改善やバッテリ消耗の抑制を行うと，NEMO 集合では最適とならない．NEMO 集合内で移動ルータ同士が協調して，通信品
質の改善やバッテリ消耗の抑制する必要性を説明した．

19

第 3 章 NEMO 集合内の協調
第 2 章において，移動ネットワークにおける移動通信環境と NEMO 集合について説明した．本章では，NEMO 集合内の協調について議論し，また，既存技術を適応するだけでは解決できない
課題を説明する．

NEMO 集合内の協調に対する要求事項

3.1

NEMO 集合内の協調によって，移動ネットワークの単独の移動ルータへの依存を解消し，NEMO集合全体の利用可能帯域，残存時間，信頼性などの通信環境を向上する．本節では，NEMO 集合
における協調モデルを実現するための要求事項をまとめる．

3.1.1

ネットワーク構成に関する要求

本節では，ネットワーク構成に関する要求をまとめる．

• A. 複数移動ルータ，複数 HA，複数移動ネットワークへの対応
NEMO 集合内には，複数移動ルータ，複数 HA の支援，複数移動ネットワークが存在する
可能性がある．NEMO 集合内の協調には，任意の数の複数移動ルータ，複数 HA，複数移動
ネットワークに対応する必要がある．移動ネットワークが NEMO 集合を構成している場合，異なる移動ネットワークから通信が発生して，利用する外部インターフェイスが衝突する可能性がある．この衝突を回避する必要がある．
• B. 移動ネットワークの動的参加・離脱に対応
NEMO 集合は，複数の移動ネットワークが動的に参加・離脱を行うため，移動ルータの数，
HA の数，移動ネットワークの数は動的に変更される．NEMO 集合内の協調には，動的に変化する移動ルータ，複数 HA，複数移動ネットワークに対応する必要がある．特に，内部インターフェイス側のリンクが分離して，通信不能を起こすことを回避すべきである．HA 側においては，NEMO リンクの分割を検知することができないため，各移動ルータが処理する必要がある．
• C. エンドノード（MNN）への変更と影響
今後の移動計算機群には計算機資源を豊富に持つ計算機と持たない計算機，インターネット
接続性を持つ計算機と持たない計算機が混在する．また，計算機の一部は頻繁に群への参加・離脱を行なう．したがって，有効に通信を振り分けるためにはそれらの計算機の動きを検知・管理する必要が生じる．複数の接続性を選択利用する機構を想定する際，エンドノー
ドが利用する接続性を選択する方法が考えられる．しかし，この方法では，例えば一時的に20

第 3 章 NEMO 集合内の協調

インターネット自動車の環境を利用する計算機に対しても新たな機能を追加する必要が生じてしまう．インターネット自動車に持ち込まれる全ての計算機に新たな機能を追加することは，インストールコストが高い．また，インターネット自動車のネットワーク環境を利用するために新たな機能を必要とするという解決方法では，インターネット自動車の普及を阻害する要因となる．また，インターネット自動車には計算機資源に乏しいセンサーノードが多く含まれる．そのため，エンドノードへ新たな機能を追加ことなく他の要求事項を満たす必要がある．
また，NEMO 集合に複数の移動ルータが接続しており，複数の無線通信インターフェイス
が利用可能である場合，移動ネットワーク内のノードが利用する無線通信インターフェイス
を選択できるべきである．また，通信中の無線通信インターフェイスが利用不能になった場
合，移動ネットワーク内のノードは代替の無線通信インターフェイスを利用できるべきである．利用する無線通信インターフェイスを変更する際，ネットワーク層より上位の層に透過的である必要がある．

3.1.2

NEMO 集合内の資源最適化に関する要求• D. NEMO 集合内で利用する外部インターフェイスを選択できること
NEMO 集合内に複数の利用可能な無線通信インターフェイスが存在する場合，利用する無線通信インターフェイスを選択できる必要がある．無線通信インターフェイス切替え利用が可能であるか，または同時利用が可能であるべきである．これらのインターフェイスは，パラメータに基づいて選択され利用される必要がある．また，移動ネットワークから送信されるトラフィックと，インターネットから送信されるトラフィックの両方について，無線通信
インターフェイスの選択が可能である必要がある．そのため，移動ルータ側と HA 側両方でトラフィックの送信先を決定できる必要がある．
• E. バッテリ消耗の抑制
通常の NEMO においては，常時接続制と着信可能性を保証するため，移動ルータは 1 つ以
上の無線通信インターフェイスを起動する必要がある．そのため，全ての移動ルータにおいて，無線通信インターフェイス起動によるバッテリ消耗が発生する．複数の移動ネットワー
クが接続している NEMO 集合においては，NEMO 集合全体で 1 つ以上の無線通信インター
フェイスを起動することで，常時接続制と着信可能性を保証できる．2.3.3 節で述べた通り，
移動ルータの電源の状態によって，バッテリの重要度が大きく異なる．バッテリ消耗を抑制するためには，最も電源に余裕がある移動ルータが無線通信インターフェイスを起動することが望ましい．

3.1.3

セキュリティに関する要求• F. IPsec の終端を変更しない
NEMO において，Home Address と Care-of Address の対応付けは，非常に重要な処理であり，移動ルータから Care-of Address を通知するための Binding Update は厳重な暗号で守られている．悪意のあるノードに対応付けを破壊された場合，移動ネットワークは通信不能になる．よって，NEMO 集合内の協調によって，HA は悪意のあるノードからの Binding21

3.2. NEMO 集合における協調モデル

Update を受け付けてはならない．NEMO において，移動ルータと HA の間の全てのシグナ
リングは，IPsec [31] によって認証される．この認証の利用は，移動ルータと HA の IPsec
利用 [32] に規定されている．また，移動ルータと HA との間のトンネルを利用した全ての通信は，IP Encapsulating Security Payload (ESP) [33] によって守られる．NEMO 集合内の協調によって NEMO にセキュリティの前提を棄損してはならない．

3.2

NEMO 集合における協調モデル

3.2.1

基本となる協調モデル

最も基本となる協調モデルを図 3.1 に示す．NEMO 集合内の資源を全ての移動ルータで共有するために，移動ルータは，自身の持つ資源を共有できるようにしたり，それを利用する．
共有資源

共有

利用

共有

利用

移動ルータ

図 3.1: 基本となる協調モデル
第 3.3 節に挙げたように，協調して NEMO 集合内の資源を利用できれば，移動ネットワークの安定性と通信品質は向上することが想定される．しかし，無線通信メディアの特性として，通信帯域の全量が決まっており，利用しているノードが利用帯域を共有する．あるノードが無線通信
メディアを用いて通信を行なうと，その他のノードが利用できる通信帯域は減少する．また，各移動ルータはバッテリ消耗抑制への要求を持つため，利害が一致しない状況が発生する．
本研究では，共有資源の利用の形態に応じて，余剰資源共有型モデルと集合内最適型モデルを定義する．
余剰資源共有型の協調は，移動ルータ間の協調による通信品質の改善と自身の利益が相反する可能性のある協調であり，集合内最適型の協調は，移動ルータの所有者が同じなど移動ルータ間の利益が相反しない協調である．どちらも NEMO 集合内の協調によって，通信品質の向上には同意しているものとする．また，余剰資源共有型と集合内最適型の両協調モデルの混在モデルについても説明する．
図 3.2 は資源利用を模式的に表したものである．共有資源とは無線通信インターフェイスとバッテリを示し，状況に応じて，各移動ルータは自身の持つ資源を NEMO 集合全体で利用できる状態に置く．点線は利害対立がなく，同一の判断基準で動くことが可能である範囲を表している．

3.2.2

余剰資源共有型モデル

余剰資源共有型モデルは，余剰の利用可能帯域が存在する無線通信インターフェイスを NEMO集合全体で共有利用するモデルである．例えば，別々の個人に所属する移動ルータ間の協調など

22

第 3 章 NEMO 集合内の協調

共有資源

共有資源

各自の判断で余剰の資源を供出・提案

各自の移動ネットワーク
状態に応じて利用共通の判断で
資源を供出

移動ルータ

全体移動ネットワーク
状態に応じて利用

移動ルータ

余剰資源共有型協調モデル

集合内最適型協調モデル

共有資源

各自の判断で余剰の資源を供出・提案

各自の移動ネットワーク
状態に応じて利用共通の判断で資源を供出全体移動ネットワーク
状態に応じて利用

移動ルータ
余剰資源共有型と集合内最適型の混在モデル

図 3.2: NEMO 集合における協調モデルを想定したモデルである．NEMO 集合内の協調によって，通信品質の向上することに同意している一方，各移動ルータは，NEMO 集合全体の最適化と自身の利益が相反しない行動を取る．例えば，移動ルータ自身が提供する移動ネットワークと別の移動ネットワークの両方で通信が発生し，無線通信インターフェイスの使用において競合が起きた場合，無線通信インターフェイスを持つ
移動ルータが優先する通信を制御できることが望ましい．移動ルータは図 3.2 に示すように，無線通信インターフェイスの共有利用を提案・申し入れを基本として協調する．余剰資源共有型モデ
ルでは，各移動ルータは，NEMO 集合の状態に応じて，各自の移動ルータが自身の持つ無線通信
インターフェイスの広告を行ない，協調を強制されない．つまり，別の移動ルータに利用された
くない期間は，自身の無線通信インターフェイスの広告を停止する．また，資源の共有・利用において，不利益を被る移動ルータが発生することを避ける必要がある．

3.2.3

集合内最適型モデル

集合内最適型モデルは，各移動ルータの利害対立を想定しないモデルであり，集合内の資源利用
効率を最適にするモデルである．例えば，同一個人が所有する移動ルータ，または，親族など非常に親しいものに所属する移動ルータ間の協調を想定したモデルである．つまり，各移動ルータ間において利害対立が生じない前提で，協調を行なう．例えば，移動ルータ自身が提供する移動ネッ
トワークと別の移動ネットワークの両方で通信が発生し，無線通信インターフェイスの使用において競合が起きた場合において，全ての移動ルータで統一の基準で動作を決定できる．移動ルータは図 3.2 に示すように，供用資源の供出を，各自の移動ルータの判断でなく，通信の優先度に応じて，全体で統一の判断を行う．共有資源の利用で競合が起こった場合も全体で統一の判断で行うことが可能である．ある通信に対し，移動ルータ間に優先順位の相違がないため，一意の優先順位によって通信の重要度を決定できる．例えば，自動車における緊急通信のなど優先度の高い

23

3.3. NEMO 集合内資源の共有

通信は，通信の発生元のネットワークに関わらず優先する．移動ルータ間での利害対立がないた
め，資源の共有・利用において，不利益を被る移動ルータが発生することを避ける必要がない．

3.2.4

混在モデル

余剰資源共有型モデルの協調と集合内最適型モデルの協調の両協調モデルの混在環境が想定される．混在モデルにおいて，各移動ルータの動作を変更する必要はない．
余剰資源共有型モデルの協調を行う移動ルータ間においては，無線通信インターフェイスの共有利用を提案・申し入れを基本として協調するため，利用するかどうかの判断は各移動ルータに委ねられている．そのため，集合内最適型協調を行う移動ルータでも共有資源の利用は可能である．ただしこの場合の無線インターフェイス利用に関する競合では，通信の優先度に関わらず，無線通信インターフェイスを持つ計算機が優先される．また，集合内最適型モデルの協調を行う移動ルータ群は同一の判断に基づいて動作するため，仮想的に単一の移動ルータとして考慮すると，NEMO 集合全体では，余剰資源共有型モデルの協調で動作していると認識できる．余剰資源共有型協調の移動ルータが集合内最適型モデルの協調の移動ルータの無線通信インターフェイスを利用する際には，通信の優先度に関わらず，無線通信インターフェイスを持つ計算機が優先される．

3.2.5

協調モデルのまとめ

余剰資源共有型モデルの協調と集合内最適型モデルの協調の両協調モデルの比較を表 3.1 に示す．
表 3.1: NEMO 集合における協調モデル
余剰資源共有型モデルの協調

集合内最適型モデルの協調

別々の個人

同一個人または，
非常に親しい者同士自身の持つ資源と余剰の共有資源

集合内の最適な資源

利害対立

起きる

起きない

判断基準

個々の移動ルータで別NEMO 集合全体で統一
優先度を通信の種類によって判断想定するシナリオ（所有者）
利用する資源無線通信インターフェイスの利用に 関する競合の回避方法

3.3

無線通信インターフェイスを搭載している移動ルータを優先

NEMO 集合内資源の共有

第 2.5 節で述べたように，現状では，各移動ルータは独立に動作するため，移動体通信における通信品質向上は，個別の移動ネットワークごとに最適になっている．それによって，それぞれの移動ネットワークは，単独の移動ルータに依存する問題が発生する．本来，複数の移動ネットワーク
が NEMO 集合を構成している場合は，個別の移動ネットワークごとに効率化するより，NEMO
集合を効率化するほうが全体としての通信品質向上が見込まれる．
NEMO 集合全体で，通信品質を向上させるためには，移動ルータ間で協調動作する必要がある．
図 3.3 に NEMO 集合内における協調の例を示す．

24

第 3 章 NEMO 集合内の協調

CN

CN

起動

起動

起動

MR1

Internet

CN

MR2

停止
停止

MR3

MR1

トラフィック分散によるロードバランシング

CN

アプリケーション要求に適した通信経路の選択

MR2

MR3

MNN

移動ネットワーク1

移動ネットワーク2

MNN

移動ネットワーク3

移動ネットワーク1(1) NEMO集合（広帯域通信時）

最小電力無線通信デバイスを用いた着信可能性の保証

停止

MR1

移動ネットワーク3

Internet

CN

起動

停止

停止

MR2

移動ネットワーク2(2) NEMO集合（通信時）

MR3

MR1

CN

起動

MR2

参加
離脱

移動ネットワーク2

MR3
MNN

MNN

移動ネットワーク1

起動

移動ネットワーク3

移動ネットワーク1(3) NEMO集合（無通信時/低通信時）

移動ネットワーク2

移動ネットワーク3(4) NEMO集合（動的追加/離脱）

図 3.3: NEMO 集合における協調• トラフィック分散によるロードバランシング
一般的に，移動体通信における帯域のボトルネックは，移動ルータとアクセスポイント間の広域通信メディアの部分で発生する．したがって，この区間のトラフィックを複数の経路へと分散することで，移動ネットワーク内のノードが行う通信の輻輳を回避できる．結果，利用可能な通信帯域を増大する．図 3.3 の（１）に示すように，発生したトラフィックを NEMO
集合内の全ての移動ルータの持つ無線通信デバイスに分散することができれば，単独の移動
ルータに依存している現状よりも，NEMO 集合全体として通信帯域の利用効率を高めることが可能である．NEMO 集合内の無線通信デバイスのうち利用されていない通信デバイスを利用することで，移動ネットワークの内部のノードが利用可能な帯域は増大する．

• アプリケーション要求に適した通信経路の選択
アプリケーションには，VoIP のようにリアルタイム性が要求されるものや，ファイルのダ
ウンロードのように帯域が要求されるものなど，さまざまな要求がある．移動ルータは，ア
プリケーションの要求に応じて，通信を転送する無線通信インターフェイスを選択する．無線通信インターフェイスを選択の際，単独の移動ルータに搭載されている無線通信インター
フェイスのみから選択を行うため，移動ルータがアプリケーションの要求に応えられる範囲

25

3.4. 本章のまとめ

は，単独の移動ルータに依存している．図 3.3 の（２）に示すように，NEMO 集合全体の移動ルータに搭載されている無線通信インターフェイスから選択するほうが，よりアプリケー
ションの要求に応えられる可能性が高い．

• 最小電力無線通信デバイスを用いた着信可能性の保証
移動ネットワーク内のノードへの着信を待ち受ける期間においては，複数無線インターフェイスを起動することによって，移動ルータのバッテリ消耗が増大する問題がある．移動ルー
タは，最も省エネルギーな無線通信インターフェイスを起動し，移動ネットワークへの着信を待ち受ける．移動ルータが独立に動作する場合，移動ネットワークの数だけ無線通信イ
ンターフェイスを起動する必要が生じる．図 3.3 の（３）に示すように NEMO 集合内でひとつの無線通信インターフェイスを用いて複数の移動ネットワークを着信可能にできれば，NEMO 集合全体では，バッテリの消耗を抑制できる．

• 移動ルータの動的参加・離脱
移動ルータは，動的に NEMO 集合への参加・離脱を行う．NEMO 集合内の移動ルータの数，
HA の数，移動ネットワークの数は動的に変更される．通信発生中に，移動ルータの参加・離脱が起こる場合には，通信が遮断されてはならない．移動ルータの参加・離脱に関わらず，通信が継続されなければならない．通信待ち受け中に移動ルータの参加・離脱が起こる場合には，それぞれの移動ネットワークにたいする着信可能性は，継続して提供されなければならない．図 3.3 の（１）〜（４）に示す NEMO 集合内の協調において，移動ルータの動的参加・離脱が考慮されなくてはならない．

3.4

本章のまとめ

本章では，NEMO 集合内の協調について要求事項をまとめ，協調モデルについて議論した．移動ルータ間の利害対立に着目して，余剰資源共有型モデルと集合内最適型モデルを議論した．最後に，実現する NEMO 内資源の共有について示した．

26

第 4 章 本研究の関連研究
本章では本研究に関連する技術として，NEMO を拡張した技術を 4 つ挙げる．また，Mobile
Ad-hoc Network における関連研究をあげる．その後，3.1 節で述べた NEMO 集合内の協調に対する要求事項に関する各方式の比較を行う．

4.1

NEMO 拡張型

4.1.1

NEMO SHAKE

Mobile IP SHAKE[34] は移動体計算機群のインターネット接続性を共有することを目的としている．複数端末の回線を同時に利用することで，広帯域な通信を可能としている．また，複数回線を利用するためのトラフィックを分配する機能を，移動端末と Home Agent に持たせている．
NEMO SHAKE[35] では，NEMO を用いた通信の安定性の向上，複数経路通信，通信帯域の増大を実現するため，MR が複数相互接続し，Alliance を構築する．Alliance 内の他の MR が持つ
外部リンクを用いて通信する MR は Alliance leader（ALR），ALR 宛のトラフィックを中継する
MR は Alliance Member（AMR）と呼ばれる．
SHAKE では，複数の経路にトラフィックを分配させる場所が重要となる．NEMO SHAKE では，MR 配下の端末である MNN が通信相手と通信を行う際にやりとりされるパケットが必ず移動
ルータの Home Agent を経由するという NEMO の特徴を利用し，トラフィック分配機構を AMRの Home Agent に設置する．ALR は，AMR の外部リンクを利用するために，自身の Home Agentに AMR を登録する．ALR の Home Agent は，ALR の Mobile Network Preﬁx 宛のパケットを登録された MR へそれぞれ分配している．AMR は ALR の Home Agent から配送されたパケットを
MR 間の通信により ALR へ転送している．
[36] では SHAKE におけるジッタを考慮したパケット配送によって，ネットワーク性能の低下を防ぐ研究が行われている．また，[37] では，外部インターフェイスの性能の変化に動的に追従するロードバランシングの研究が行われている．

4.1.2

複数 MR における障害回避[38] では，複数 MR における障害の回避が提案されている．移動ルータの外部インターフェイ
スの障害，内部インターフェイスの障害，移動ルータ自身の障害の際に，移動ネットワークに接続する他の移動ルータが，バックアップとして動作する．外部インターフェイスに障害の起きた
移動ルータは，バックアップの移動ルータへ，障害通知 ICMP メッセージを送信する．メッセー
ジを受信した移動ルータは，障害回避の通信経路を確立するため，障害の起こった移動ルータのHome Agent との間にトンネルを確立する．[38] では，障害が起こった移動ルータのわかりに送信する Binding Update を Preﬁx Peer Binding Update（PPBU）として定義している．障害が起27

4.1. NEMO 拡張型

こった移動ルータは移動ネットワークへのルータ広告を停止し，替わりにバックアップの移動ルー
タがルータ広告を開始することで，移動ネットワーク内のノードは，新たなトンネルを利用可能にする．
上記の環境においては，移動ネットワーク内のノードが複数の IP アドレスを取得する可能性があり，適切な Home Agent との間にトンネルが確立されてない場合，送信元アドレスフィルタリ
ング [39] によって，パケットがブロックされる可能性がある．[40] においては，移動ルータにおいて移動ネットワーク内のノードによる通信の送信元の IP アドレスを認識し，[39] に定義される
PPBU を送信することで，適切なトンネルを設定する仕組みを提案している．

4.1.3

Multiple Gateway in Mobile Network (MGMN)

MGMN[41] は，移動体計算機群のインターネット接続性を共有し，エンドノードに着信可能性と移動透過性を達成しているため，本研究と関連する．
MGMN では，移動する計算機群においてインターネット接続性を動的に共有する機構の設計と実装を行なっている．本節では，この論文で設計実装された MGMN について解説を行なう．まず，用語を解説した後，図 4.1 概要を説明する．

Internet
IEEE802.11b

PHSgateway2

gateway1
Router Advertisement option
prefix 2001:1:0:1::/64
Type IEEE802.11b
Bandwidth 11Mbps
linkstatus associated
etc ......

Router Advertisement option

Internal Network
2001:1:0:1:EUI64
2001:2:0:2:EUI64

2001:1:0:1:EUI64
2001:2:0:2:EUI64

Gateway list
Policy list

prefix 2001:2:0:2::/64
Type PHS
Bandwidth 128Kbps
linkstatus associated
etc ......

Gateway list
Internal NodeInternal Node

図 4.1: MGMN の概要

以下に用語の説明を行なう．

• Internal Network
計算機の通信が可能な内部ネットワーク．
• Internal Node
内部ネットワーク内のすべてのノード．
28

Policy list

第 4 章 本研究の関連研究• Gateway
Internal Node がインターネットへの接続性を他の Internal node へと提供している状態を示す．Gateway はインターネットと内部ネットワークの両方に接続している．
• 外部インターフェイス
Gateway がもつインターフェイスのうちインターネットへ接続しているインターフェイス．
• Gateway 情報
Gateway のもつ外部インターフェイスに関する情報，および Gateway として機能するための情報．Internal Node はこの情報を元に利用する Gateway を選択する．
図 4.1 に概要を示す．Gateway はルータ広告にオプションを付加することで自身の持つ外部イ
ンターフェイスの情報を Internal Network へと送信する．送信される情報は，ネットワークプレ
フィクス，メディアタイプ，帯域情報リンク状態などである．Internal Node はこれらの Gateway
情報を Gateway List へと格納する．また，Internal Node は Gateway 情報によって Gateway を選択するためのポリシをあらかじめ設定し，保持している．
Internal Node は，送信元アドレスを選択することでどのインターネット接続性を利用するかを決定することが可能である．この機構では，移動透過性や着信可能性を保証することはできない．
よって，Internal Node は Mobile IPv6 によって移動を透過することを想定している．

4.1.4

Multiple Mobile Routers Management

Multiple Mobile Routers Management[42, 43] では，複数 CoA 登録の仕組みをバーチャルイン
ターフェイスモデルと移動ルータ間の動的な情報共有モデルを導入して拡張した．図 4.2 に示す
通り，移動ネットワーク参加した移動ルータ（MR1，MR3）は，メインの移動ルータ（MR2）のバーチャルインターフェイスとして加わる．移動ルータ間は，リンクローカルマルチキャストを利用して情報交換が行われる．
移動ネットワーク内でメインとなる移動ルータを Primary MR（PMR）といい，それ以外の移動ルータを non-PMR と定義している．各移動ルータは Neighbor Egress interface List（NEL）
データベースを扱い，移動ネットワークに含まれる全ての移動ルータの外部インターフェイスの情報を保持する．NEL 広告によって全ての移動ルータの NEL は同期されている．移動ネットワー
ク内のノードに通信が発生した場合は，移動ルータ内のデフォルトルータである PMR がインターネットへの経路を選択する．PMR において，non-PMR はバーチャルインターフェイスとして認識されているため，経路選択は，複数 CoA 登録と同じ仕組みで実現できる．また，インターネッ
トから移動ネットワークへのトラフィックの振り分けは，Home Agent において行われる．

4.2

Mobile Ad-hoc Network 型[44] では，Mobile Ad-hoc Network（MANET）[45] における広域接続性が議論されている．Mobile Ad-hoc Network において，グローバル IP アドレスを用いるための手法を定義している．
MANET ノード間でグローバルインターネットへの経路を交換する仕組は，計算機集合内の協調に関わるため，ここで説明を行う．
MANET ノードは，インターネットゲートウェイ広告を受信することで，MANET からインター
ネットへ接続する経路を発見する．インターネットゲートウェイはインターネットゲートウェイ
29

4.3. 各方式の比較

HA
for Multiple CoA
Registration

join

Binding Cache
HoA
CoA
MR2 HoA MR1 CoA
MR2 HoA MR2 CoA
MR2 HoA MR2 CoA

BID
BID1
BID2
BID3

Frag
R/M
R/M
R/M

Internet
BID2

BID3

BID1

join

Real
interface

MR1

Virtualinterface

MR2

VirtualinterfaceMR3

default route
MNN

Mobile Netowrk

図 4.2: Multiple Mobile Routers Management の概要
広告を定期的に送信する．Reactive 型の MANET には適さないため，インターネットゲートウェ
イ要請を定義している．インターネットゲートウェイ要請を受信したインターネットゲートウェ
イは，インターネットゲートウェイ広告を送信する．

4.3

各方式の比較

本節では 3.1 節で述べた NEMO 集合内の協調に対する要求事項に関する各方式の比較を行う．
ネットワーク構成に関する要求のうち，複数移動ルータ，複数 HA，複数移動ネットワークへの対応（A）を満たす研究はなかった．複数移動ルータ，複数 HA，複数移動ネットワークへの対応（A）については，考慮されている技術も存在したが（NEMO SHAKE，複数 MR における障害回
避，MMRM，MANET Global v6 + NEMO），いずれも移動ルータ間で通信経路の衝突が起こる
場合については，考慮されていない．移動ネットワークの動的参加・離脱に対応（B）は全ての技術で満たされている．エンドノード（MNN）の変更と影響（C）では，全ての技術で経路変更によるアプリケーションへの影響は考慮されていた．しかし，複数 MR における障害回避 と MGMN
エンドノードへの変更が必要である．
NEMO 集合内の資源最適化に関する要求のうち，NEMO 集合内で利用する外部インターフェイ
スを選択できること（D）の要求は本章で説明した多くの技術で，満たされていた．Mobile IPv6
や NEMO などの移動体通信に関する技術は，ネットワークの移動に関する問題のみを解決している．そのため，複数経路利用などマルチホーミングに関する研究は，これらの技術の拡張として行われている．本章で説明を行った研究は，複数計算機のインターネット接続性を共有する研究30

第 4 章 本研究の関連研究であるための技術であったため，（D）の要求を満たすことを目的としている．唯一，複数 MR における障害回避は，障害の起こった移動ルータのバックアップを目的としているため，外部イン
ターフェイスの選択は行えない．バッテリ消耗を抑制できること（E）の要求を満たした技術は，存在しなかった．バッテリ消耗の抑制は移動端末にとって非常に重要であるが，本章で説明した技術は，複数経路利用などマルチホーミングに関するものであり，バッテリの消耗の抑制は対象外であった．
IPsec の終端を変更しない（F）要求は，NEMO SHAKE，複数 MR における障害回避，MMRM
で満たされていない．これらの技術では，NEMO のトンネルの前提を変更しているため，新たな仕組みを議論する必要がある．MGMN では，エンドノードが Mobile IPv6 を利用することが想定されているため，Mobile IPv6 の前提を変更しない．
表 4.1: 関連研究の比較

A.
B.
C.
D.
E.
F.

4.4

技術名

A

B

C

D

E

F

NEMO SHAKE
複数 MR における障害回避
MGMN
MMRM
MANET Global v6 + NEMO

×

○

○

○

×

×

×

○

×

×

×

×

×

○

×

○

×

○

×

○

○

○

×

×

×

○

○

○

×

○

複数移動ルータ，複数 HA，複数移動ネットワークへの対応
移動ネットワークの動的参加・離脱に対応
エンドノード（MNN）の変更と影響
NEMO 集合内で利用する外部インターフェイスを選択できること
バッテリ消耗を抑制できること
IPsec の終端を変更しない

本章のまとめ

本章では，複数外部インターフェイスの利用についての関連技術をまとめた．その後，関連研究とこれらの技術との関係を考察した．関連する技術では，本研究の全ての要求を達成できない
ことが確認された．次章では，目的を達成するためのアプローチについて述べる．

31

第 5 章 NEMO 集合の協調へのアプローチ
本章では，NEMO 集合内の協調へのアプローチを議論する．はじめに，ネットワーク構成の考察を行い，次にトンネルの構成を議論する．NEMO 集合内の協調のための情報交換の考察を行う．
その後に，トラフィックの状態によってトンネルの構成を変更する方法を提案し，通信発生時と無通信時の考察を行う．

5.1

ネットワーク構成の考察

本節では，NEMO 集合における移動ルータの接続時の構成を考察する．移動ルータは，内部インターフェイス（Ingress）と外部インターフェイス（Egress）を持つため，移動ルータ同士の接続は図 5.1 に示す 3 つの構成のいずれかを取る．

AP

MR1

MR1

MR2

MR1

MR2

MR1

MR2

MR2

Ingress-Egress

Egress-Egress

Ingress-Ingress

図 5.1: ネットワーク構成

Ingress-Egress 型は移動ルータの内部インターフェイスと外部インターフェイスが接続する構成である．また，NEMO の経路最適化 [46, 47] で議論されている構成である．この型は，移動ネッ
トワークが階層を構成しているため，論理的には複数の階層に渡って移動ルータが多段にネットワークを構成する可能性がある．
Egress-Egress 型は，移動ルータの外部インターフェイス同士が接続する構成である．外部イン
ターフェイス同士を接続する方法として，外部インターフェイスが同じアクセスポイント（AP）に接続する方法がある．各移動ルータはインターネットへの接続と他の NEMO への接続を実現する．しかし，移動ルータと AP との接続は移動によって不安定になったり，遅延・帯域の点で問題がある可能性がある．また，従来の移動ルータの持つ外部インターフェイスと内部インターフェイスの他に，移動ルータ同士を接続するインターフェイスを定義する必要がある．移動ルー
タ同士の接続は，2.4.1 節で述べた通り，広帯域・低遅延・省電力であることが望ましい．Mobile
Gateway[48] においては，この構成が取られている．
Ingress-Ingress 型は，移動ルータの内部インターフェイス同士が接続する構成である．
32

第 5 章 NEMO 集合の協調へのアプローチ

本研究では，移動ルータの外部インターフェイスやバッテリなどの資源を NEMO 集合内の協調によって，効率的に利用することを目的とする．相互の移動ルータが階層的な構造である場合，上位の移動ルータが下位の移動ルータの資源を利用することは困難である．相互の移動ルータが資源を利用し合うためには対称の構成であることが望ましいため，Ingress-Egress 型の構成を除外する．また，相互の移動ルータを接続するための新たなインターフェイスを定義するよりも，既に存在するインターフェイスを用いて接続されることが望ましい．そのため，本研究では，内部
インターフェイス同士が接続する Ingress-Ingress 型が望ましい．一方，各移動ルータの内部イン
ターフェイスがアクセスポイントであった場合，相互の NEMO が接続しない問題がある．内部イ
ンターフェイスが有線や，無線メッシュネットワークのように双方向で通信できるメディアであれば，内部インターフェイスは，移動ネットワーク内のノードとの通信を想定しているため，一般的に広帯域・低遅延・省電力である．内部インターフェイスは，NEMO 集合内の協調を行うことに適した特性を持っている．本研究では，Ingress-Ingress 型を対象とする．

5.2

トンネル構成の考察

NEMO において，移動ルータと Home Agent の間の全てのシグナリングは，Home Agent のIPsec 利用 [32] に規定されている．NEMO 集合においても，シグナリングを処理するノードや，トンネルの終端ノードに変更を加えることは，NEMO の前提を変更することになる．これは，セキュリティの観点から望ましくない．また，NEMO の前提を変更する場合，新たなセキュリティの仕組みを必要とする．トンネルの終端ノードに変更を加えずに，トンネルの作り方を配慮することで，アプリケーションの遅延や帯域への要求に対応したり，バッテリの消耗を抑制できる．本
研究では，トンネルの終端ノードに変更を加えない方法を採用する．図 5.2 と表 5.1 に各トンネルの構成に対するバッテリの消耗と通信品質の特性を示す．

図 5.2: トンネル構成• 通常の NEMO
各移動ルータが各移動ネットワークの着信可能性を保証する．そのため，無通信時においても，全ての移動ルータが最低ひとつの外部インターフェイスを起動する必要が生じる．その33

5.2. トンネル構成の考察

表 5.1: ネットワーク構成の特徴
通常の NEMO

他移動ルータの接続性を利用

全ての接続性を利用

バッテリ消耗

×

○

×

通信品質

△

△

○

ため，全ての移動ルータで外部インターフェイスの起動によるバッテリの消耗が発生する．
一方，通信が発生した場合，移動ルータは自身の提供する移動ネットワークを送信元または送信先とするトラフィックの全てをその移動ルータに搭載されている外部インターフェイス
から送信する．アプリケーションの要求する遅延，帯域などの通信品質を満たすために利用可能な外部インターフェイスは，その移動ルータに搭載されているインターフェイスに限られる．移動ルータは，自身に搭載されている外部インターフェイスの中から，移動ネット
ワーク内のノードの通信に最も適したインターフェイスを選択する．

• 他移動ルータの接続性を利用
NEMO 集合内でただひとつの外部インターフェイスを起動することで，NEMO 集合全体の着信が可能となる．外部インターフェイスを起動する移動ルータは，電源の供給を受ける移動ルータやバッテリの余裕がある移動ルータ，エネルギー消耗の少ないメディアを持つ移動
ルータだけが行うことで，その他のネットワーク構成よりバッテリ消耗が抑制できる．一方，通信が発生した場合は，トンネルの重複 [47, 46] による通信品質の劣化が発生する．本構成
は，バッテリ消耗の抑制を優先した構成だと定義できる．
• 全ての接続性を利用
NEMO 集合内全ての移動ルータが外部インターフェイスを起動する．そのため，全ての移動ルータで外部インターフェイスの起動によるバッテリの消耗が発生する．一方，通信が発生した場合，複数経路から通信に最も適した経路を選択できるため，通信品質が向上する可能性がある．アプリケーションの要求する通信品質を満たすために利用可能な外部インターフェイスは，その移動ルータに搭載されているインターフェイスに限られない．本構成は，通信品質を優先した構成だと定義できる．
常時接続を基本とする移動通信において，無線メディアの起動は必須であるが，バッテリの消耗を引き起こしてしまう．しかし，複数経路にトラフィックを分散することで帯域を向上することが可能である．一般的に，遅延や帯域への要求とバッテリの消耗抑制への要求は相反する．しかし，無通信時は遅延や帯域への要求が低減するため，バッテリの消耗抑制への要求が相対的に高まる．反対に，通信が発生した場合は，遅延や帯域への要求が高まる．各ネットワーク構成の特性を考慮して，通信状況に応じてトンネル構成を変更することで，全てのネットワーク特性の有利な点を引き出せる．
よって，無通信時には，他移動ルータの接続性を利用するトンネル構成を適用し，通信が発生すると全ての接続性を利用するトンネル構成を適用することが望ましいと考えられる．

34

第 5 章 NEMO 集合の協調へのアプローチ

5.3

NEMO 集合内の情報交換の考察

NEMO 標準仕様では，移動ネットワークに複数の移動ルータが接続することを想定しないため，
移動ルータは互いに近隣の移動ルータが NEMO 集合に接続していることを検知できない．これは，複数移動ルータ間の情報交換が欠如しているためである．NEMO 集合では，移動ルータ同士
は，広帯域・低遅延の高品質なネットワークで接続されるため，移動ルータ間で内部インターフェ
イスを用いてこれらの情報を共有するのが適当である．
（図 5.3）．移動ルータ間が定期的に情報交換を行うことで，各移動ルータは近隣の移動ルータが NEMO 集合に参加・離脱する動きを検知することが可能となる．
第 2.3.4 節に示した通り，移動ルータが通信品質向上のために必要とする情報は，通信の OSI モ
デルの情報や，ハードウェアの情報，移動ネットワークの状況など多岐にわたる．これらの情報が NEMO 集合の通信品質向上する上で，必要不可欠である．本研究では，移動ルータ間でこれらの情報を交換し，交換された情報を用いて，動的にネットワーク構成を変更することで，NEMO集合全体の通信品質の向上や，安定性の向上を目指す．ネットワーク構成の変更は，5.2 節に示した通り，NEMO, Mobile IPv6 の機能を利用する．

図 5.3: NEMO 集合内の情報交換と動的ネットワーク構成の変更

5.4

無通信時の動作の考察

無通信時は，通信発生時と比べ，通信品質への要求が相対的に低減し，バッテリの消耗抑制への要求が相対的に高まる．NEMO 集合全体への着信可能性を保証しながら，バッテリの消耗抑制への要求へ応えるため，移動ルータ間で協調する．NEMO 集合全体でバッテリ消耗の抑制への要35

5.4. 無通信時の動作の考察

求が相対的に低い移動ルータが，着信可能性を保証することが望ましい．バッテリ消耗の抑制への要求が相対的に低い移動ルータは一般的に，以下のようなものが想定される．

1. 電源供給を受ける移動ルータ
2. バッテリに余裕がある移動ルータ
3. バッテリ消費の少ない外部インターフェイスを持つ移動ルータ
NEMO 集合内の移動ルータの起動時間を最大化するため，バッテリの残存時間が一番長い移動
ルータが，NEMO 集合の着信可能性を保証するアプローチを取る．この方法においては，図 5.4に示すように，移動ルータ x において，外部インターフェイスの単位時間あたりの電源消費量を
ECx ，バッテリ残量を Ex ，内部インターフェイスと通信デバイス以外の単位時間あたりの電源消費量を αx とし，各移動ルータのスコアを以下の式 5.1 で算出する．スコアはある移動ルータのバッ
テリの総量を，単位時間あたりのバッテリ消耗量で割ったものである．スコアは，NEMO 集合内の協調がない場合の移動ルータの起動可能である期間 Tx を示す．最もスコアの大きい移動ルータ
が無線通信インターフェイスを起動する．

移動ルータ

EC1

EC2

EC3: 外部インターフェイスの
単位時間あたりの電源消費

E1

E2

E3: バッテリ残量

α1

α2

α3: 通信デバイス以外の単位時間あたりの電源消費

図 5.4: 無通信時のバッテリ消耗の抑制

Tx =

Ex
ECx + αx

(5.1)

無線通信インターフェイスを起動する移動ルータを on 無線通信インターフェイスを起動していない移動ルータを of f とすると，Ton と Tof f は，式 5.2 となる．移動ルータ on は，単位時間あたりのバッテリ消耗量が (ECon + αon ) であるのに対し，移動ルータ on は，単位時間あたりのバッ
テリ消耗量が αon となる．移動ルータが n 台接続している NEMO 集合全体でのバッテリ消耗の抑制は単位時間 R となる（式 5.3）．ただし，式 5.3 は無線通信インターフェイスを起動する移動
ルータ on が変更にならない場合である．式 5.3 より，NEMO 集合に参加する移動ルータが増大す
ると，本システムのバッテリ消耗を抑制する効果が増大することがわかる．

Ton =

Eon
,
ECon + αon

Tof f =

36

Eof f
αof f

(5.2)

第 5 章 NEMO 集合の協調へのアプローチ

n
∑
Ek
Ek
Eon
Eon
R =
(
−
)−(
−
)
αk
ECk + αk
αonECon + αon
k=1

=

n
∑

(

k=1

Eon × ECon
Ek × ECk)−()
αk × (ECk + αk )αon × (ECon + αon )(5.3)

無線通信インターフェイスを起動する対象となる移動ルータ on が変更になる要因として以下の4 つの場合が考えられる．このうち，NEMO 集合の分割・統合，電源の供給状況の変化，外部イ
ンターフェイスの利用状況の変化は，ランダムに起こる要因であり，数式を利用して変更の有無を予測することは困難である．

• NEMO 集合の分割・統合• 電源の供給状況の変化• 外部インターフェイスの利用状況の変化• バッテリ残量の変化
一方，バッテリ残量の変化による移動ルータ on の変更は，移動ルータ on における式 5.1 のス
コアを他の移動ルータのスコアが上回った場合に発生する．つまり，式 5.1 のスコアが NEMO 集
合で 2 番目に高い移動ルータを second とすると，移動ルータ on と移動ルータ second のバッテリ残量比がバッテリ消耗比より大きい場合（式 5.4 を満たす場合）に移動ルータ on の変更が発生
する．一度バッテリ残量の変化による移動ルータ on の変更が発生すると，移動ルータ on と移動
ルータ second のバッテリ残量比とバッテリ消耗比は拮抗し，連続的に移動ルータ on の変更が発生する恐れがある．移動ルータ on の変更は通信経路の変更を意味しており，一般的に通信経路の変更は，一時的に通信品質の悪化を引き起こす．無通信時においては，通信品質への要求は相対的に小さいが，移動ネットワーク内のノードへの着信の可能性は常にあるため，通信品質の悪化
望ましくない．よって，一度移動ルータ on に選定された移動ルータは，一定期間移動ルータ onとして動作することが望ましい．

Eon
ECon + αon<
Esecondαsecond

5.5

(5.4)

通信発生時の動作の考察

通信発生時は，無通信時と比較すると，バッテリの消耗抑制への要求が相対的に低減し，通信品質への要求が相対的に高まる．発生した通信の特性に応じて，NEMO 集合内で最も適した無線
通信インターフェイスを利用することが望ましい．以下に示すように，アプリケーションごとに
通信品質に対する要求が異なる．

37

5.6. アプリケーションの要求と無線通信インターフェイスの対応付け

5.5.1

アプリケーション要求• 通信遅延への要求が高いアプリケーション
電話（VoIP）やビデオ会議システム，ネットワーク対戦ゲームなど，対話型アプリケーショ
ンは，遅延が大きい場合には，非常に利用が困難となる．

• 通信帯域への要求が高いアプリケーション
自動車のカーナビゲーションシステムの最新地図のダウンロードや，パーソナルエリアネッ
トワークの音楽ファイルファイルのダウンロードなどは，ユーザが利用するまでの時間を短縮するため，通信帯域への要求が高い．

• 安定性への要求が高いアプリケーション
自動車の車両情報や，パーソナルエリアネットワークの健康センサなど，常時少量の通信が発生する通信に対しては，アクセスポイント間のハンドオーバーの少ない，広域無線メディアが適している．

5.5.2

インターフェイス選択

アプリケーションの要求 A には，式 5.5 のように，要求の最小値を記述する．
遅延要求の最小を Dmin とし，通信帯域要求の最小を Bmin とする．安定性要求の最小を Sminとする．遅延パラメータとしては，無線区間の影響を移動ルータから Home Agent までのラウンド
トリップタイムを用いる．実際の通信の遅延は，MNN から通信相手までの遅延となるが，MNNから移動ルータまでや，Home Agent から通信相手までのラウンドトリップタイムは，いずれのトンネルを利用しても遅延は共通であるため，通信経路選択のパラメータとしては不必要である．
通信帯域は，あらかじめ外部インターフェイスに決められている予想帯域を用いる．安定性のパラメータとしては，2.3.1 節で述べた，通信範囲と安定性に正の相関がある無線の特徴を考慮して，無線の通信範囲を記述することとする．

A{Dmin , Bmin , Smin }(5.5)

MNN のアプリケーションの要求に対して，最も遅延・帯域・安定性の通信品質を満たす外部イ
ンターフェイスから，通信を送信できることが望ましい．通信発生時は，バッテリの消耗抑制への要求が相対的に低減するが，一方でバッテリの消耗抑制の要求は存在する．
図 5.5 に示した通り，移動ルータは発生した通信に対し，NEMO 集合全体で通信遅延，通信帯
域と安定性を比較し，最適な外部インターフェイスより通信を送信する．複数の外部インターフェ
イスが要求を満たすのであれば，そのなかでバッテリ消耗への影響が最小であるインターフェイ
スを選択することが望ましい．バッテリ消耗の影響は，5.4 節に示したように無通信時と同様の方法で可能である．

5.6

アプリケーションの要求と無線通信インターフェイスの対応付け

移動ルータに搭載される複数無線インターフェイスを同時利用するため，複数 Care-of Address
登録を利用する．複数 Care-of Address 登録では，移動ルータの単一の Home Address に対して，

38

第 5 章 NEMO 集合の協調へのアプローチ

D1
B1
S1

D2
B2
S2

通信品質

D3
B3
S3

D4
B4
S4

D: 通信遅延
B: 通信帯域
S: 安定性
電源

移動ルータ1

EC1

EC2

E1

E2

α1

α2

移動ルータ3EC3: 外部インターフェイスの
単位時間あたりの電源消費
E3: バッテリ残量

移動ルータ3

α3: 通信デバイス以外の単位時間あたりの電源消費

図 5.5: アプリケーション要求への対応
複数の Care-of Address を登録するために，Care-of Address 毎に Binding Unique Identiﬁcation
番号（BID）を割り当てる．BID の割り当て方は，実装者の裁量が許されている．
また，アプリケーションの要求される通信特性に応じて，無線通信インターフェイスを選択できる必要がある．アプリケーションに応じて，利用する Binding を選択することで，アプリケーションの要求に最も適した無線通信インターフェイスを選択可能にするため，BID と無線通信インター
フェイスに関連づける必要がある．つまり，BID を無線通信インターフェイス毎に固定し，BIDの割り当て運用を行なう．これによって，アプリケーション要求する特性に最も適した，Binding
を無線通信インターフェイスと関連づけて選択できるようになる．

5.7

本章のまとめ

本章では，第 3 章でまとめた要求事項を満たす，アプローチを議論した．ネットワーク構成の考察では NEMO のセキュリティの前提を変更しない方法を採用した．NEMO 集合内で交換された情報を基に，NEMO と Mobile IPv6 の機能を利用して，動的にネットワーク構成を変更することを提案した．具体的には，通信が発生していない場合には，バッテリ消耗を抑制するネットワー
ク構成へと変更する．一方，通信が発生した場合には，通信の要求する通信品質を満たすネット
ワーク構成へと変更する．

39

第 6 章 Mobile Routers Resource Sharing（MRRS）の設計
本章では，第 5 章で提案したモデルを基に Mobile Routers Resource Sharing（MRRS）を提案
する．本システムは，複数 Care-of Address 登録を拡張して行う．

6.1

用語解説

• 近隣移動ルータ（Neighbor Mobile Router，NMR）
同一 NEMO 集合内に接続する移動ルータ．互いの内部インターフェイスから情報を交換できることを前提とする．

• ローカル外部インターフェイス（Local Egress Interface, ローカル IF）
移動ルータに搭載されている外部通信インターフェイス．

• 近隣外部インターフェイス（Neighbor Egress Interface, Neighbor IF）
同一 NEMO 集合内に接続する移動ルータに搭載されている外部通信インターフェイス．本システムでは，NEMO 集合内の全ての移動ルータにおいて，全ての Local Egress Interface
および Neighbor Egress Interface が検索可能，利用可能になる．

• ローカル Binding（Local Binding）
ローカル外部インターフェイスで取得した Care-of Address の登録による Binding．

• 近隣 Binding（Neighbor Binding）
移動ルータの内部インターフェイスで取得した Care-of Address の登録による Binding．近隣外部インターフェイスを経由する Binding．

• Neighbor Mobile Router List （NMRL）
同一 NEMO 集合内に接続する移動ルータの情報を格納するデータベース．Local Egress
Interface および Neighbor Egress Interface の情報，バッテリ情報などが格納される．全ての移動ルータがこのデータベースを扱う．

• Neighbor Mobile Router List 広告 （NMRL 広告）
同一 NEMO 集合内に接続する移動ルータで Neighbor Mobile Router List を同期するためのメッセージ．ローカル IF の情報やバッテリの情報の変更を近隣移動ルータに通知する．送信先をオールノードマルチキャストにし，宛先ポート番号を 11233 に設定した UDP パケッ
トを送信する．UDP パケットに含まれる情報は表 6.1 のとおりである．

40

第 6 章 Mobile Routers Resource Sharing（MRRS）の設計

表 6.1: Neighbor Mobile Router List 広告のフォーマット
要素
形式

種類

Mobile Router
情報

外部インターフェイス
情報

Home Address
電源の供給状況
バッテリ残量バッテリ予想残存時間
内部インターフェイス起動コスト
Binding 状態
BID
ライフタイム帯域
遅延
外部インターフェイス起動コスト
課金情報（optional）
シグナルレベル（optional）

IPv6 address
充電中・バッテリ使用
整数（％）
整数（分）
1 から 10NMRLE ADD・NMRLE DEL
整数
秒
整数（bits/sec）
整数（ミリ秒）1 から 10
Yes・ NOSN 比• 通信情報広告
移動ルータが担当する移動ネットワークに発生した通信の情報を交換するメッセージ．イン
ターネットから移動ネットワークへ，または移動ネットワークからインターネットへ通信情報が含まれる．送信元アドレス，送信先アドレス，フローのタイプ，通信量，ライフタイムなどが含まれる．メッセージフォーマットは表 6.2 のとおりである．
表 6.2: 通信情報広告のフォーマット
要素
形式
通信の Port 番号整数

送信元アドレス

IPv6 アドレス
IPv6 アドレス秒
整数（Bits/sec）

送信先アドレス
ライフタイム帯域

6.2

MRRS のフローチャート

本節では，インターフェイス選択制御と NMRL 広告受信時，通信情報広告受信時のフローチャー
トについて述べる．

6.2.1

インターフェイス選択制御

Mobile Routers Resource Sharing における移動ルータのインターフェイス選択は図 6.1 に示すとおり，大別して 4 つの部分からなる．通信状況の共有 ，通信発生時の Binding の確立 ，通信停止時の Binding の確立，NMRL データベースの同期である．
41

6.2. MRRS のフローチャート

図 6.1: MRRS におけるインターフェイス選択のフローチャート

42

第 6 章 Mobile Routers Resource Sharing（MRRS）の設計

Mobile Routers Resource Sharing では通信が発生すると，その通信の要求に適応する通信イン
ターフェイスを選択し，通信の停止時は最も省エネなインターフェイスを NEMO 集合全体で共有する．そのため，通信状況の情報を共有する必要が生じる．各移動ルータは通信状況を基に，利用する通信インターフェイス選択を判断するため，通信状況の共有は最も基本的な情報である．よって，Mobile Routers Resource Sharing の動作の最もはじめに行われるべきである．
• 通信状況の共有
通信状況の共有では，まず自身の移動ルータに通信が発生しているかどうかを確認する．発
生した通信の情報は任意のライフタイムをつけて管理する．通信が発生している場合は，発生している通信の通信状況広告を行ない，通信発生時の Binding の確立 へと進行する．また，自身の移動ルータに通信が発生していない場合でも，近隣の移動ルータに通信が発生しているかどうか調べ，発生している場合は，通信発生時の Binding の確立 へと進行し，通信停止時の Binding の確立へと進行する．

• 通信発生時の Binding の確立
通信発生時の Binding の確立では，自身に搭載されている無線通信インターフェイスと NMRL
データベースの中からから，通信の特性に最も合致するものを検索する．検索は，発生した通信の遅延，帯域，安定性などへの要求を基に行う．図 6.1 の（a）は，5.5.2 で述べた方法
によって選択される．また，利用中の外部インターフェイスのシグナルレベルが閾値より下
がっている場合，シグナルレベルが良好なインターフェイスが存在しないか確かめ，存在す
る場合は，そのインターフェイスが選択される．
該当するインターフェイスが自身の移動ルータに搭載されている場合，Local IF の使用 （点線囲み）へと進行する．該当の外部インターフェイスを起動し，Binding Update を送信して，Binding を作成する．その後，Binding の成立，不成立に基づいて，NMRL エントリを追加または，削除する（NMRL データベースの同期）．
近隣の移動ルータに搭載されている場合は，Neighbor IF の使用（点線囲み）へと進行する．
Neighbor IF の使用では，近隣移動ルータの該当インターフェイスが利用可能である場合，
内部インターフェイスから Binding Update を送信する．Binding が確立した場合，NMRL
データベースの同期へと進み，Binding が確立できない場合には Local IF の使用へと進行
する．自身の移動ルータの持つ最も通信に適した無線通信インターフェイスから Binding
Update を送信し，NMRL データベースの同期へと進む．

• 通信停止時の Binding の確立
通信停止時の Binding の確立では，自身に搭載されている無線通信インターフェイスと NMRL
データベースの中からから，相対的に最もバッテリの消耗への要求が少ない移動ルータを検索する．１）電源供給を受ける移動ルータ２）バッテリに余裕がある移動ルータ３）バッテ
リ消費の少ない外部インターフェイスを持つ移動ルータを基に行う．図 6.1 の（b）は 5.4 節
で述べた数式 5.1 のスコアが最も高いものを選択する．また，利用中の外部インターフェイスのシグナルレベルが閾値より下がっている場合，シグナルレベルが良好なインターフェイスが存在しないか確かめ，存在する場合は，そのインターフェイスが選択される．
該当するインターフェイスが近隣の移動ルータに搭載されている場合は，Neighbor IF の使用（点線囲み）へと Local IF の使用 （点線囲み）へと進行する．Neighbor IF の使用では，

43

6.2. MRRS のフローチャート

近隣移動ルータの該当インターフェイスが利用可能である場合，内部インターフェイスからBinding Update を送信する．Binding が確立した場合，NMRL データベースの同期へと進
み，Binding が確立できない場合には Local IF の使用へと進行する．自身の移動ルータの持つ最もバッテリ消耗の少ない無線通信インターフェイスから Binding Update を送信し，NMRL データベースの同期へと進む．

• NMRL データベースの同期
NMRL データベースの同期では，Local IF での Binding の情報をに対応する NMRL を BIDで検索し，該当エントリを BOUND に変更する．Local IF での Binding が成立しなかった
場合は，該当の NMRL エントリを NOT BOUND に変更する．一方，Neighbor IF 経由で送信した Binding Update によって成立した Binding は近隣の移動ルータには通知しない．
移動ルータは，Local IF で成立した Binding 情報のみ，NMRL 広告を行う．これは，Local
IF で成立した Binding は近隣の移動ルータと共有する必要があるが，Neighbor IF 経由のBinding は，共有資源を利用している状態であるためである．
Local IF における NMRL エントリの変更は，移動ルータの電源情報を更新した後，NMRL
広告を送信することによって，近隣の移動ルータに通知される．NMRL 広告の受信時の処理は，6.2.2 節で述べる．

6.2.2

NMRL 広告受信時

各移動ルータの Local IF で成立した Binding の情報は，NMRL 広告によって近隣の移動ルータに通知される．図 6.2 に NMRL 広告受信時のフローチャートを示す．
NMRL 広告を受信した移動ルータは，対応する NMRL エントリを追加する．既に該当のエントリが追加されている場合には，エントリのライフタイムを更新する．NMRL 広告を受信してNMRL エントリが追加される場合は，近隣の外部インターフェイスが利用可能になったことを示しているため，内部のインターフェイスから Binding を確立する．また，追加された NMRL エ
ントリに該当する外部インターフェイスを経由するトンネルが作成されている場合には，Binding
Update を送信しない．該当のトンネルは，NEMO の標準機能である BUL 管理によって更新さ
れる．

6.2.3

通信情報広告受信時

図 6.3 に通信情報広告受信時のフローチャートを示す．移動ルータが通信情報広告を受信すると，該当する外部インターフェイスからのトンネルが既に生成されているか，NMRL を検索する．既にトンネルが生成されている場合には，該当の経路を利用可能であるため，処理が終了する．一方，トンネルが不成立である場合は，発生した通信に適した外部インターフェイスを検索する．該
当の外部インターフェイスがローカル IF である場合には，インターフェイスを起動し，Binding
Update を送信する．Binding が成立すると，NMRL エントリを追加し，Binding が不成立の場合
は，NMRL エントリを削除する．その後，電源状態を更新し，NMRL 広告を行う．通信が発生した移動ルータは，NMRL 広告を受信し，最も適したトンネルを利用可能となる．

44

第 6 章 Mobile Routers Resource Sharing（MRRS）の設計

図 6.2: NMRL 広告受信時のフローチャート

図 6.3: 通信広告受信時のフローチャート

45

6.3. MRRS の状態遷移

MRRS の状態遷移

6.3

本節では，MRRS の状態遷移を示す．MRRS の状態遷移は NEMO の状態遷移を拡張したものである．MRRS の状態遷移図を図 6.4 に示す．図は MRRS を動作させている一台の移動ルータについての状態遷移図である．一台の移動ルータが複数のローカル外部インターフェイスを搭載しており，複数の近隣移動ルータが NEMO 集合を構成していることを想定している．各移動ルータ
がそれぞれ図のような状態を持っている．ある移動ルータのローカル外部インターフェイスは，その他の移動ルータの近隣外部インターフェイスとなる．各移動ルータにとって，ロカール外部イ
ンターフェイスの状態遷移は，IF DOWN，IF UP NO COA，WAIT BACK，LOCAL BOUNDの４種類がある．一方，近隣外部インターフェイスの状態遷移は，NMRL 広告を受信することで，
NMRL エントリが追加されるごとに，該当する外部インターフェイス経由の Binding の状態遷移が開始される．

6.3.1

状態

ローカルインターフェイスの状態遷移の状態を以下に述べる．IF DOWN，IF UP NO COA，
WAIT BACK，LOCAL BOUND の４種類がある．

• IF DOWN
ローカルインターフェイスの初期状態．無線通信インターフェイスを起動していない状態で，バッテリの消耗を抑制できる．そのインターフェイスを利用する必要がない場合はこの状態になり，利用する必要が生じる場合のみ，他の状態への遷移する．

• IF UP NO COA
ローカルインターフェイスで Care-of Address が利用できない状態．HA との Binding は確立されていない状態で，インターフェイスと HA との双方向トンネルも確立されていない状態．

• WAIT BACK
Binding Acknowledgement（BACK）の受信を待っている状態．最初の Care-of Address の登録の場合，Binding は確立されておらず，移動ネットワークノードはこのインターフェイ
スを利用できない．Care-of Address の再登録の場合，Binding は確立されており，HA と無線通信インターフェイスには双方向トンネルが設定されている．この場合は，移動ネット
ワークノードはこのインターフェイスを利用可能である．
• LOCAL BOUND
正常に HA への Care-of Address の登録が完了した状態．Binding が成立しており，無線通信インターフェイスと HA との間に双方向トンネルが設定されている．
近隣インターフェイスの状態遷移の状態を以下に述べる．WAIT BACK，NEIGHBOR BOUND，
REMOVE NIF の２種類がある．

• WAIT BACK46

第 6 章 Mobile Routers Resource Sharing（MRRS）の設計

LOCAL BINDING2LOCAL BINDING1DYNAMIC HOME AGENTDISCOVERYLOCAL_BOUNDUNSELECTED&
IFダウン&
CoA消滅
DELEG送信

BACK受信&BU再送信期限の更新&
NMRL広告移動検知 &
BU送信

BU再送信期限切れ&
BU送信

移動検知 &BU送信

UNSELECTED&
IFダウン&
DELEG送信DHAAD_REQ期限切れ&
DHAAD_REQ送信
HOME_REG回数制限 &DHAAD_REQ送信 &NMRL広告WAIT_BACK

NO_HA
BACK_128受信 &DHAAD_REQ送信&
NMRL広告IF_DOWN

移動検知 &DHAAD_REQ送信

BU_TIMER期限切れ &BU送信

IF_DOWN

DHAAD_REP受信&
BU送信

SELECTED&
IFアップ

CoA消滅
移動検知 &DHAAD_REQ送信

CoA消滅
UNSELECTED &
IFダウン

START

IF_UP_NO_COA

NEIGHBOR BINDING2NEIGHBOR BINDING1BU_TIMER期限切れ &BU送信

NMRLエントリ追加 &BU送信

WAIT_NMRLNMRLエントリ削除

NMRLエントリ削除

DYNAMIC HOME AGENTDISCOVERY

WAIT_BACKDHAAD_REP受信&
BU送信

HOME_REG回数制限 &DHAAD_REQ送信

BU再送信期限切れ& BACK受信&
BU送信
BU再送信期限の更新

BACK_128受信 &DHAAD_REQ送信

NEIGHBOR_BOUND

NO_HADHAAD_REQ期限切れ&
DHAAD_REQ送信

図 6.4: MRRS の状態遷移図

Binding Acknowledgement（BACK）の受信を待っている状態．最初の登録の場合，Bindingは確立されておらず，移動ネットワークノードはこのインターフェイスを利用できない．再登録の場合，Binding は確立されており，HA と無線通信インターフェイスには双方向トン
47

6.3. MRRS の状態遷移

ネルが設定されている．この場合は，移動ネットワークノードはこのインターフェイスを利用可能である．

• NEIGHBOR BOUND
正常に HA への Care-of Address の登録が完了した状態．Binding が成立しており，無線通信インターフェイスと HA との間に双方向トンネルが設定されている．設定された双方向トンネルは，近隣移動ルータとその HA の双方向トンネルと，その内部インターフェイスと
HA との双方インターフェイスとの二重の双方向トンネルである．

Dynamic Home Agent Address Discovery (DHAAD) の状態を以下に述べる．
• NO HA
Care-of Address を登録するべき HA のアドレスを発見していない状態．Dynamic Home
Agent Address Discovery (DHAAD) の手続きを行っている状態．全ての Care-of Addressについて Binding が確立されていない．
Neighbor Mobile Router List の状態を以下に述べる．
• WAIT NMRLNeighbor Mobile Router List のエントリの追加を待ち受ける状態．

6.3.2

イベント

MRRS の状態遷移におけるローカル Binding にたいするイベントを以下に述べる．移動検知，
BU 再送信期限切れ，BACK 受信，BACK 128 受信，DHAAD REP 受信，BU TIMER 期限切れ，
DHAAD REQ 期限切れ，HOME REG 回数制限，SELECTED，UNSELECTED が存在する．
• 移動検知移動ルータが他のネットワークに接続する事象．新規の Care-of Address の取得．

• BU 再送信期限切れ
Binding Update の再送信期限が切れる事象．移動ルータは Binding を更新するために，Binding Update を送信する必要が生じる．
• BACK 受信
HA へ Care-of Address が正常に登録されたことを示す，Binding Acknowledgement（BACK）の受信．
• BACK 128 受信
Care-of Address が Home Agent へと正常に登録されなかった理由を示す， Statues Codeが 128 以上の Binding Acknowledgement（BACK）の受信．‘• DHAAD REP 受信
Dynamic Home Agent Address Discovery (DHAAD) Reply メッセージの受信．移動ルータ
利用するべき HA のアドレスを取得する．
48

第 6 章 Mobile Routers Resource Sharing（MRRS）の設計• BU TIMER 期限切れ
送信した Binding Update に対し，HA が返答する Binding Acknowledgement が規定時間以内に受信できず，期限が切れる事象．移動ルータは Binding を更新するために，Binding
Update を再送信する必要が生じる．

• DHAAD REQ 期限切れ
送信した Dynamic Home Agent Address Discovery (DHAAD) Request メッセージに対し，HA が返答する Binding Acknowledgement Dynamic Home Agent Address Discovery(DHAAD) Reply メッセージが規定時間以内に受信できず，期限が切れる事象．移動ルータ
利用するべき HA のアドレスを取得するために，DHAAD Request メッセージを再送信する必要が生じる．

• HOME REG 回数制限
送信した Binding Update に対し，HA が返答する Binding Acknowledgement が時間以内に規定回数受信できない事象．移動ルータ利用するべき HA のアドレスを取得するために，
DHAAD Request メッセージを再送信する必要が生じる．

• SELECTED
アプリケーションの要求，バッテリ残量，無線通信インターフェイスの特性や通信状況などを考慮した結果，その無線通信インターフェイスの利用が選択される事象．Binding を確立
し，HA との双方向トンネルを設定するための状態へと移行させる．

• UNSELECTED
アプリケーションの要求，バッテリ残量，無線通信インターフェイスの特性や通信状況などを考慮した結果，その無線通信インターフェイスを利用しないことが決定される事象．Bindingが成立している場合には，Binding を解消し，HA との双方向トンネルを解消する．

• COA 消滅
ローカルインターフェイスに Care-of Address がひとつもなくなる事象．

MRRS の状態遷移における近隣経由の Binding に対するイベントを以下に述べる．NMRL エン
トリ追加と NMRL エントリ削除が存在する．
• NMRL エントリ追加
NEMO 集合に接続している近隣移動ルータから Neighbor Mobile Router List （NMRL）広
告受信を受信し，NMRL にエントリを追加する事象．近隣移動ルータにおいて，Binding が成立したことを示しており，近隣移動ルータ経由の Binding を成立させるための状態へと移行させる．
• NMRL エントリ削除
NEMO 集合に接続している近隣移動ルータから NMRL 広告受信を受信し，NMRL エント
リを削除する事象，または，NMRL エントリの有効期限が切れて，NMRL エントリを削除する事象．NMRL 広告受信を受信し，NMRL エントリを削除された場合，近隣移動ルータ

49

6.4. 本章のまとめ

経由の Binding は無効となる．NMRL エントリの有効期限が切れて，NMRL エントリを削除された場合は，近隣移動ルータが NEMO 集合を離脱したことを示し，近隣移動ルータ経
由の Binding は無効となる．

6.3.3

状態遷移図

図 6.4 に MRRS の状態遷移図を示す．状態遷移図は，上部にローカル外部インターフェイスによる Binding の状態遷移，下部に近隣外部インターフェイスによる Binding の状態遷移を示している．
各 Local Binding は，安定状態で IF DOWN から開始する．SELECTED のイベントが発生す
ると，LOCAL BOUND 状態へ移行するため，インターフェイスを起動する．Care-of Address を取得する（移動検知）と Dynamic Home Agent Discovery Request メッセージを送信し，Home
Agent アドレスを取得する．Home Agent に Binding Update を送信し，外部インターフェイスを利用可能な状態（LOCAL BOUND）にする．通信が停止したり，さらに適した外部インターフェ
イスが利用可能となると，UNSELECTED のイベントが発生し，インターフェイスを停止する．
近隣 Binding の状態遷移は，NMRL 広告を受け付ける状態である WAIT NMRL から開始される．NMRL 広告を受信すると，該当の NMRL エントリが追加される．WAIT NMRL 状態からは，異なる NMRL 広告を受信するごとに各近隣 Binding の状態遷移が発生する．NMRL エントリが追加されると，内部インターフェイスから Binding Update を送信し，Binding を確立する．

6.4

本章のまとめ

本章では，第 5 章で議論したアプローチを基に，Mobile Routers Resource Sharing（MRRS）を提案した．本システムは，複数 Care-of Address 登録を拡張し，通信状況や移動ルータの状態に適応して，動的にネットワーク構成を変更することで，NEMO 集合全体における移動ルータの安定性と通信品質の向上を実現する．本章では，MRRS のフローチャートと状態遷移を説明した．

50

第 7 章 Mobile Routers Resource Sharing の実装
本章では，本論文で実装した MRRS について説明を行なう．

7.1

実装環境

本論文では，Linux 2.6.15.7[49] 上の NEMO Platform(NEPL)[50] 上で動作する複数 CoA 登録の拡張実装 [51, 52] を用いた．2006 年 6 月 30 日のスナップショット (beta2-20060630) を用いた．
本実装は，NEPL の提供するデーモン (nemod) を拡張した．

7.2

実装概要

Mobile Routers Resource Sharing 拡張の nemod は，起動時に二つのソケットを開く．ひとつは移動ルータ間で NMRL を同期するための RAW ソケットであり，もうひとつは，移動ルータに発生しているトラフィックを共有するための RAW ソケットである．どちらのソケットも，移動ルー
タの内部インターフェイス側から UDP のリンクローカルマルチキャストに対して，通信を行うものである．前者はポート番号 11233 を利用し，後者はポート番号 11234 を利用する．
図 7.1 に nemod の動作のうち本研究における拡張部分の動作概要を示した．移動ルータが Care-of
Address を取得・変更・削除し，Binding Update List(BUL) を更新すると同時に，NMRL エント
リも更新される．更新された NMRL エントリの情報は，内部インターフェイスを通じて，近隣の移動ルータに通知される．この際，電源の供給状況やバッテリ残量の情報も更新され，更新された情報がこの NMRL 広告に含まれる．NMRL 広告を受け取った nemod は，対応する NMRL エン
トリを追加，または削除する．各 NMRL エントリには NMRL 広告に含まれるライフタイムが設定され，定期的な更新のない NMRL エントリは削除される．ip6tables[53] が通知するトラッフィ
ク状態を定期的に監視して，トラッフィク情報を内部インターフェイスを通じて，近隣移動ルータに通知される．電源を供給されている移動ルータは，すべてのインターフェイスを起動して，複数のトンネルを確立する．バッテリ駆動の移動ルータは，通信が発生していない場合は，ひとつの無線通信インターフェイスを起動するか，または，内部インターフェイスからのトンネルを確
立する．

7.3

MRRS 実装の詳細

本節では，MRRS の機能である，NMRL の管理，トラッフィク情報の管理，インターフェイス
制御について説明する．

51

7.3. MRRS 実装の詳細

MR1

NEMOD

NEMOD

MR2

traffic
info

BUL

NMRL

BUL manager

NMRL manager

Traffic
managerInterface
managertraffic
info

NMRL

USERLAND

acpi

interface
management

Battery

UDP socket
for exchanging
NMRL

UDP socket
for exchanging
traffic info

Egressinterfaces

traffic monitor

ip6tables

Ingress
interfaces

UDP socket
for exchanging
NMRL

UDP socket
for exchanging
traffic info

KERNEL
Ingress
interfaces

Mobile Network

図 7.1: 実装概要

7.3.1

Neighbor Mobile Router List の管理

図 7.2 と図 7.3 に NMRL の同期に関する処理を行う機能の実装概要を示す．図 7.2 には，追加実装した nemod の BUL エントリの追加・更新・削除の処理から NMRL エントリの追加・更新・削除の処理と NMRL 広告までの処理を示した．図 7.3 には NMRL 広告の受信から NMRL エン
トリの追加・更新・削除までの処理を示した．各データベースと処理の内容を示した後，動作の概要を説明する．
mn_recv_ba(d)

bul_delete

(c)

(b)

削除

bul_update_timer

bul_add

追加

タイマ更新

BUL

nmrl_delete

nmrl_local_add
IF情報取得

nmrl_expire
削除

nmrl_add
追加

タイマ更新
ACPI
電源状況
バッテリ残量update_battery

NMRL
電源情報
の更新

send_nmrl_adv

NMRLE_ADDまたはNMRLE_DELの送信

図 7.2: NMRL の管理 (ローカル外部インターフェイス情報)52

conf_parse
初期化

callback
nmrl_update_timer(a)net_iface

第 7 章 Mobile Routers Resource Sharing の実装(e)

NMRLE_ADDまたはNMRLE_DELの受信
nmrl_adv_recv

NMRLE_DELの受信

NMRLE_ADDの受信追加の場合
nmrl_add

nmrl_delete

nmrl_expire

更新の場合

nmrl_update_timer

callback

NMRL

図 7.3: NMRL の管理 (近隣外部インターフェイス情報)• BUL データベース
Binding Update List．移動ルータが Binding Update を送信する送信先のノードのリスト．
移動ルータは定期的に Binding Update を送信し，Binding Update が成功すると，BUL の対応するエントリのライフタイムが更新される．ライフタイムの期限が切れたエントリは削除される．
• NMRL データベース
Neighbor Mobile Router List データベース．NEMO 集合に所属する移動ルータの持つ外部
インターフェイスの情報や，電源状態の情報を格納するデータベース．NEMO 集合に所属する移動ルータ全てが，このデータベースを持つ．NMRL 広告を用いて，移動ルータ間でデータベースは同期される．各エントリはタイマで管理されており，ライフタイムの期限が切れたエントリは削除される．
• net iface データベース
ネットワークインターフェイス情報のデータベース．インターフェイス名，BID，BID プラ
イオリティ，インターフェイス電源消費量などが含まれる．nemod 起動の際に設定ファイル（通常は nemod.conf）から読み込まれる．

• conf parse 処理部
nemod 起動の際に設定ファイル（通常は nemod.conf）を読み込む処理．Home Address，Home Agent Address，移動ネットワークプレフィクスや BID など移動ルータの設定情報を読み込む．本実装では，設定ファイルの読み込みを拡張し，インターフェイス電源消費量をデータベースに入力できるようにした．
• bul add 機能
53

7.3. MRRS 実装の詳細

BUL エントリを追加する機能．BUL エントリは，Home Address，Home Agent Address，
BID で識別される．Binding Update を送信する前に，Binding に対応するエントリを追加する．追加するエントリには，現在時刻とライフタイムが記録される．
• bul delete 機能
BUL エントリを削除する機能．BUL エントリは，Home Address，Home Agent Address，
BID で識別される．ライフタイムの期限切れなどの場合に呼ばれる．
• bul update timer 機能
移動ルータが Binding Acknowledgement を受信したときに呼ばれる機能．対応する BUL エ
ントリのタイマ期限が更新される．

• nmrl update timer 機能
NMRL エントリのタイマ期限を更新する機能．各 NMRL エントリにはライフタイムが設定されている．
• update battery 機能
移動ルータの電源の供給状況と，バッテリ残量の情報を更新する機能．電源情報は各 NMRL
エントリで更新される．電源情報の取得は ACPI[54] コマンドを利用して取得する．

• nmrl local add 機能
ローカル外部インターフェイスから成立した BUL エントリの情報を NMRL エントリに格納する機能．Neighbor Binding の場合は，NMRL エントリには追加しない．

• nmrl add 機能
NMRL エントリを追加する機能．NMRL エントリは，Home Address，Home Agent Address，
BID で識別される．追加するエントリには，現在時刻とライフタイムが記録される．
• nmrl delete 機能
NMRL エントリを削除する機能．NMRL エントリは，Home Address，Home Agent Address，
BID で識別される．
• nmrl expire 関数
各 NMRL のタイマ期限が切れると呼ばれる Callback 関数．NMRL から対応するエントリを削除するため，nmrl delete 機能が呼ばれる．

• send nmrl adv 機能
NMRL の追加・更新・削除の情報を NEMO 集合内の他の移動ルータに通知するため，NMRL
広告の送信を行う機能．エントリの追加・更新の際には NMRLE ADD を送信し，エントリの削除の場合には，NMRLE DEL を送信する．
• nmrl adv recv 機能
NEMO 集合内の他の移動ルータの NMRL の追加・更新・削除の情報を共有するため，NMRL
広告を受信する機能．
54

第 7 章 Mobile Routers Resource Sharing の実装

図 7.2 の（a）に示す通り，nemod が起動すると設定ファイルから設定を読み込み，net iface デー
タベースが初期化される．NMRL の処理のトリガは BUL エントリのイベントから発生するもの
が以下の 3 つがある．BUL エントリの追加（図 7.2 の（b））と，BUL エントリの削除（図 7.2 の（c）），BUL エントリの更新（図 7.2 の（d））．また，NMRL 広告の受信（図 7.3 の（e））のトリガもある．
図 7.2 の（b）に示すように BUL エントリが追加されると，ローカル Binding か近隣 Binding
かの判定を行い，ローカル Binding の場合のみ，NMRL エントリを追加する．その際，インターフェイス電源消費量は net iface データベースから取得する． 追加された NMRL エントリには，Callback 関数として，nmrl expire を設定する．nmrl expire 関数はタイマ期限が切れると呼ばれ，対応する NMRL エントリを削除する．図 7.2 の（c）に示すように BUL エントリが削除されると，対応する NMRL エントリが削除される．削除された NMRL エントリの情報は，NMRL 広告の NMRL DEL を用いて，NEMO 集合全体の移動ルータに通知される．図 7.2 の（d）に示すよ
うに，Binding Update が成功し，対応する BUL エントリのタイマ期限が更新されると，対応する NMRL エントリのタイマ期限が更新される．次に，電源の情報が更新される．電源の情報は，
ACPI コマンドの情報に基づいて取得される．電源の供給状況は，charged，discharging，chargingと表わされる．また，バッテリの残量は，百分率で表わされる．更新された NMRL エントリの情報は，NMRL 広告の NMRL DEL を用いて，NEMO 集合全体に通知される．
図 7.3 の（e）に示すとおり，近隣の移動ルータから，NMEL DEL の NMRL 広告を受け取ると，対応する NMEL エントリを削除する．また，NMEL ADD の NMRL 広告を受け取った場合，対応する NMEL エントリが存在する場合と，存在しない場合で処理が異なる．対応する NMEL
エントリが存在する場合，対応する NMRL エントリのタイマ期限を更新する．対応する NMEL
エントリが存在しない場合は，対応する NMRL エントリを追加する．NMRL エントリの追加時には，nmrl expire を callback 関数を設定しておく．近隣 Binding が成立している間は，定期的にNMRL 広告を受信して，タイマ期限切れの前にタイマ期限が更新される．移動ルータが NEMO
集合から離脱した場合や，近隣 Binding が不成立となった場合は，NMEL エントリのタイマ期限が切れ，対応する NMRL エントリが削除される．

7.3.2

トラフィック情報の管理

図 7.4 にトラフィック情報の管理に関する処理を行う部分の実装概要を示す．各データベースと処理の内容を示した後，動作の概要を説明する．

• Target Traﬃc データベース
監視する対象となるトラフィックの情報を格納するデータベース．格納されている送信先と送信元のポート番号，送信先と送信元の IP アドレス，フローのタイプに一致するトラフィッ
ク監視する．

• Ongoing Traﬃc データベース
監視する対象となるトラフィックのうち，現状流れているトラフィックのデータベース．送
信先と送信元のポート番号，送信先と送信元の IP アドレス，フローのタイプと，トラフィッ
クが発生している移動ルータの Home Address が格納される．Ongoing Traﬃc エントリは，タイマで管理されており，タイマ期限切れのエントリは削除される．

55

7.3. MRRS 実装の詳細

traffic_init

(b)

参照

TargetTraffic(a)(c)

update_traffic_status

traffic_adv_recv

callback
ontraffic_add

ontraffic_expire

ontraffic_update_timer

追加

ontraffic_delete

削除

タイマ更新
Ongoing
traffic
data

send_traffic_adv

図 7.4: トラフィック情報の管理• traﬃc init 機能
Target Traﬃc データベースを初期化する機能．監視対象の送信先と送信元のポート番号，送
信先と送信元の IP アドレス，フローのタイプのリストを作り出す．
• update traﬃc status 機能
定期的に，移動ルータに発生するトラフィックを監視する機能．ip6tables のログ出力から直近の 1000 行を検査し，監視対象のトラフィックが発生しているか確認する．最後にトラフィックが確認された時間を前回のトラフィック発生時と比べ，新しくなっている場合は，
Ongoing Traﬃc データベースにエントリを加える．図 7.5 に ip6tables を用いた発生しているトラフィックの検査の例を挙げる．図 7.5 は，TCP の送信先ポート番号 5001 のトラフィッ
クを確認する場合の例である．
¶³

ip6tables コマンド
ip6tables -A PREROUTING -t mangle -p tcp --destination-port 5001 -j LOG
ip6tables ログ出力
Jan 3 01:07:57 tu-ka-laptop kernel: [4328130.641000] IN=eth1 OUT=
MAC=00:40:26:42:a2:ad:00:08:0d:4b:ce:35:86:dd SRC=2001:0001:0000:0002:0000:0000:0000:feed
DST=2001:0003:0000:0001:0000:0000:0000:0001 LEN=80 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=TCP
SPT=34542 DPT=5001 WINDOW=5760 RES=0x00 SYN URGP=0µ図 7.5: Ongoing Traﬃc 情報の取得の例• ontraﬃc add 機能
Ongoing Traﬃc エントリを追加する機能．追加するエントリには，現在時刻とライフタイ
ムが記録される．
• ontraﬃc update timer 機能56´

第 7 章 Mobile Routers Resource Sharing の実装

各 Ongoing Traﬃc エントリにはライフタイムが設定されており，Ongoing Traﬃc エントリのタイマ期限を更新する機能．

• ontraﬃc expire 機能
各 Ongoing Traﬃc のタイマ期限が切れると呼ばれる Callback 関数．Ongoing Traﬃc から対応するエントリを削除するため，ontraﬃc delete 機能が呼ばれる．

• ontraﬃc delete 機能
Onoing Traﬃc エントリを削除する．Ongoing Traﬃc エントリは，送信先と送信元のポート
番号，送信先と送信元の IP アドレス，フローのタイプ，トラフィックが発生している移動
ルータの Home Address で識別される．
• traﬃc adv recv 機能
NEMO 集合内の移動ルータに発生しているトラフィックの情報を交換するために，通信情報広告の送信を行う．通信の発生を確認したときに，NEMO 集合内にリンクローカルマル
チキャストアドレスに送信する．
• send traﬃc adv 機能
NEMO 集合内の移動ルータに発生しているトラフィックの情報を交換するために，通信情報広告の受信を行う．
図 7.4 の（a）に示す通り，移動ルータの起動時に監視の対象となるトラフィックのリストを初期化する．次に，図 7.4 の（b）に示すように，定期的にトラフィック情報の更新を行う．トラフィッ
ク情報は，図 7.5 の例のように，ip6tables のログ出力から取得する．新たに通信が発生している
場合は，Ongoing Traﬃc データベースにエントリを追加する．エントリには，ontraﬃc expire を
callback 関数として設定する．エントリのライフタイムは，本実装では３０秒に設定した．エント
リのタイマ期限が切れた場合は，該当のエントリが削除される．通信が発生した場合で，既に該当のエントリが存在している場合は，タイマ期限を更新する．移動ルータに発生したトラフィックの情報は，通信情報広告を送信することで，NEMO 集合内の他の移動ルータと共有する．図 7.4の（c）に示すように，NEMO 集合内の他の移動ルータに通信が発生した場合には，通信情報広告を受信する．新たに通信が発生している場合は，Ongoing Traﬃc データベースにエントリを追加する．通信情報広告を受信した場合で，既に該当のエントリが存在している場合は，タイマ期限を更新する．エントリには，ontraﬃc expire を callback 関数として設定する．エントリのライフ
タイムである３０秒が経過すると，エントリのタイマ期限が切れ，該当のエントリが削除される．

7.3.3

インターフェイス制御

図 7.6 にインターフェイス制御に関する処理を行う部分の実装概要を示す．各処理の内容を示した後，動作の概要を説明する．データベースの説明は，7.3.2 節および 7.3.1 節に記述されている．

• battery status check 機能
電源供給の状態をチェックする機能．

57

7.3. MRRS 実装の詳細

battery_status_check

Ongoing
traffic
data

NMRL

取得

traffic_check

net_iface

IF情報
取得

取得

IF情報
取得

up_all_if

IF情報取得

down_high_if

if_up

図 7.6: インターフェイス制御• traﬃc check 機能
通信状況を確認する機能．

• up all if 機能
全ての外部インターフェイスを起動する機能．

• down high if 機能
最もバッテリ消耗の少ない外部インターフェイスを起動する機能．

• if up 機能
要求のあるインターフェイスを起動する機能．
図 7.6 に示すインターフェイス制御の処理は定期的に行われる．まず，電源の供給状況を確かめ，電源が供給されている場合は，バッテリセーブへの要求が低いと判断し，全ての外部インターフェイスを起動する．起動する外部インターフェイスは，net iface データベースから取得する．バッテリ駆動であることを確認した場合，トラフィックの状況を確認する．トラフィック情報は，OngoingTraﬃc データベースより取得する．登録されているトラフィックが流れていない場合は，現在利用できるインターフェイスを NMRL から取得し，最もバッテリ消耗の少ないインターフェイスを残して，全てのインターフェイスを停止する．インターフェイス名は net iface データベースより所得する．トラフィック状況を確認した際，登録されているトラフィックが見つかると，対応する
外部インターフェイスを起動する．

7.3.4

トラフィックの分散機構

トラフィックの分散機構は NEPL の複数 CoA 登録の仕組み [52] を踏襲し，netﬁlter[53] によって行っている．BID ごとにひとつルーティングテーブルを持ち，どのルーティングテーブルを参照するべきかは，ルーティングポリシーデータベース（RPDB）を参照して決められる．パケットには，図 7.7 に示す ip6tables コマンドでマークをつける．図 7.7 の例は，TCP 送信先ポート 5001

58

第 7 章 Mobile Routers Resource Sharing の実装

番を 201，TCP 送信先ポート 5002 番を 202，UDP 送信先ポート 5002 番を 101，ICMPv6 に 101とマークを付けている．RPDB には，図 7.8 に示す通り，移動ネットワーク（2001:2:0:2::/64）から送信されるパケットのうち 0x65（十進数で 101）とマークがついているものは 101 番のルーティ
ングテーブルを参照すると設定されている．同様に 0xca （十進数で 202）のパケットは，202 番のルーティングテーブル，0xc9（十進数で 201）のパケットは，201 番のルーティングテーブルを参照する．各ルーティングテーブルには，トンネルインターフェイス ip6tnl1 など最終的に送信されるデバイス名が指定される．Home Agent においても，あらかじめ図 7.7 に示される netﬁlter の設定を設定しておく必要がある．
¶³

ip6tables -A PREROUTING -t mangle -p tcp --destination-port 5001 -j MARK --set-mark 201
ip6tables -A PREROUTING -t mangle -p tcp --destination-port 5002 -j MARK --set-mark 202
ip6tables -A PREROUTING -t mangle -p udp --destination-port 5003 -j MARK --set-mark 101
ip6tables -A PREROUTING -t mangle -p icmpv6 -j MARK --set-mark 101µ´

図 7.7: Netﬁlter を利用したトラフィック分散例
¶
1005:
1005:
1005:
1006:

³
from 2001:2:0:2::/64 fwmark 0x65 lookup 101
from 2001:2:0:2::/64 fwmark 0xca lookup 202
from 2001:2:0:2::/64 fwmark 0xc9 lookup 201
from 2001:2:0:2::/64 lookup 201µ´

図 7.8: ルーティングポリシーデータベース

7.4

本章のまとめ

本節では，Linux 2.5.16.7 上で実装した MRRS を説明した．本実装では，NEPL の提供する nemod
デーモンを拡張した．nemod から Binding 情報を取得，netﬁlter から通信状況を取得，ACPI から電源情報を取得し，NMRL リストへ追加した．MR 間で NMRL を同期し，通信インターフェ
イス選択し，インターフェイス制御する．

59

第 8 章 評価と考察
本章では，本研究で実装した MRRS の評価を行う．定量評価では，スループットや遅延を計測し，本システムが動作した際の性能改善やオーバーヘッドを測定する．

8.1

評価手法の検討

本研究の目的として，NEMO の安定性と通信品質の向上をあげている．本章では，本研究で提案した NEMO 集合内の協調システムである MRRS が目的を満たすか検証する．
8.3 節の定量評価においては，複数の移動ルータの情報を把握するための NMRL データベースが同期されているか検証する．5 章で述べた通信状況によってネットワークの構成を変更するアプ
ローチが動作するか検証する．また，複数の移動ルータの外部インターフェイスを利用できるか検証する．
8.4 節の定性評価においては，NEMO 集合内の協調によって，NEMO のネットワーク安定性が向上し，バッテリ消耗が抑制されたか検証する．また，遅延，帯域，パケット到達率などの通信品質の向上が見られるか検証する．また，NEMO 集合内協調によるオーバーヘッドを測定し，NEMOの安定性と通信品質の向上と比較考察する．

8.2

評価環境

本システムの定性評価および定量評価を行うため，評価環境を構築した．本節では評価環境の構成と，ネットワーク性能や利用した計算機の性能について述べる．

8.2.1

実験環境のネットワーク構成

評価実験においては，予期しないトラフィックが測定に影響しないように，図 8.1 に示すローカ
ルな IPv6 ネットワークを構築した．
図 8.1 に示される実線は Ethernet ケーブルを示している．また，点線で示されるインターフェ
イスは Traﬃc Control（tc）コマンド [55, 56] を利用して，通信帯域と通信遅延を設定した．図 8.2に設定例を示す．
（B）は IEEE802.11g の無線，（C）は IEEE802.11b の無線で構成されている．図8.1 に示す通り，（A）のリンクは，通信遅延を 50 ミリ秒，通信帯域を 2024 Kbits/sec に設定した．
また，MR1 は（A）のインターフェイスには BID に 101 を割り当て，プライオリティは 5 とした．
無線通信メディアの電源消費量を 5 とした．プライオリティは，数字が大きいほど優先順位が高く，電源消費量は数字が大きいほど消費量が多いことを示す．同様に，（B）の通信遅延を 200 ミリ
秒，通信帯域を 1024Kbits/sec，BID を 201，プライオリティを 15，電源消費量を 15 とした．
（C）の通信遅延を 300 ミリ秒，通信帯域を 1024Kbits/sec，BID を 202，プライオリティを 10，電源消費量を 10 とした．また，各 router は 5 秒毎にルータ広告を行っている．

60

第 8 章 評価と考察

2001:1:0:1::1

2001:2:0:1::1

HA1

HA2
2001:2::2

2001:1::2

CN

2001:3::2

2001:2::1
Router 4
2001::4

2001:1::1

2001::1

Router 1

2001::2

2001:4::/64

2001:5::/64

MR1

MR2

2001:1:0:2::1

2001:2:0:2::1

2001:1:0:2::feed

MNN1

50 ms

BID
: 101
BidPriority :5Consumption: 5

2001:6::/64(C):(A) Bandwidth : 2048kbps

Router 3

(B)

(A)

Delay

2001::3

Router 2

Delay:

200 ms(B) Bandwidth : 1024kbps
BID
: 201
BidPriority :15
Consumption: 15: 300 ms
(C) Delay
Bandwidth : 1024kbps
BID
: 202
BidPriority :10
Consumption: 10

2001:2:0:2::feed

MNN2

図 8.1: 実験環境¶³

tc qdisc replace dev eth0 root handle 1:0 netem delay 50ms
tc qdisc replace dev eth0 parent 1:1 handle 10: tbf rate 2048kbit buffer 160000 limit 300000µ´

図 8.2: tc コマンドによる通帯信域と通信遅延の設定例
図 8.1 中の各計算機の性能を表 8.1 に示した．
表 8.1: 各 PC の構成
CPU

MR1
MR2
HA1
HA2, CN
MNN1
Router

8.2.2

Intel Pentium M processor 1500MHzIntel Pentium M processor 1.10GHzIntel Pentium III (Coppermine)
Transmeta Crusoe Processor TMTM5600
Mobile Intel Pentium III M 1200MHz
AMD Enhanced Am486X4

メモリ

OS

512MB
512MB
256MB
256MB
1024MB
64M

Linux 2.6.15.7
Linux 2.6.15.7
Linux 2.6.15.7
Linux 2.6.15.7
Linux 2.6.15.7
FreeBSD 4.9-R

評価環境のネットワーク性能測定

本システムの性能の測定を行うため，評価の前提となる評価環境の性能を測定する．性能測定
では，図 8.3 に示すように，通常の IPv6 を用いた場合の経路，Mobile IPv6 を用いた場合の経路，

61

8.2. 評価環境

本システムで利用される経路の 3 つで測定を行なった．また，いずれも通信帯域と通信遅延を設定したリンクを経由する経路の測定を行なった．
通信帯域は，iperf コマンド [57] を用いて測定した．iperf は CN をサーバとして，各 MR と MNN
をクライアントとして 100 秒間実行した．通信遅延は ping6 コマンド [58] を利用して，Echo request
を 100 回送信し，平均のラウンドトリップタイムを計測した．計測結果を表 8.2 にまとめた．
NEMO や Mobile IPv6 を有効にしない場合，tc コマンドで設定した通りのネットワーク性能を記録し，評価環境が意図どおりに構築されていることが示された．また，Mobile IPv6 を起動した
際には，Home Agent を経由するため，通信相手までのホップ数が増大し，さらにパケットのカプセル化と脱カプセル化のオーバーヘッドによってネットワーク性能が悪化していることがわかる．これらのオーバーヘッドは測定結果として想定される通りであり，本実験環境は評価環境として妥当である．
Usual IPv6

HA1

CN

Mobile IPv6

HA2

HA1

CN

All path with MRRS

HA2

HA1

CN

HA2

Router 4
Router 4

Router 1(a)

MR1

Router 2

Router 3

(b)

(c)

MR2

Router 1

Router 2(d)Router 4

Router 3(e)

MR1

Router 1

(f)

(g)

MR2

MR1

Router 2

Router 3

(h)

(i)

MR2

MNN2

図 8.3: 実験環境の評価

(a)
(b)
(c)
(d)
(e)
(f)
(g)
(h)
(i)

表 8.2: 実験環境の評価
平均 RTT 平均スループット

ホップ数

53.320 ms
207.031 ms
308.322 ms
54.199 ms
209.667 ms
310.252 ms
55.441 ms
208.061 ms
305.844 ms

3 ホップ
3 ホップ
3 ホップ
5 ホップ
5 ホップ
5 ホップ
8 ホップ
6 ホップ
6 ホップ

1940 Kbits/sec
972 Kbits/sec
977 Kbits/sec
1790 Kbits/sec
895 Kbits/sec
789 Kbits/sec
1507 Kbits/sec
868 Kbits/sec
768 Kbits/sec

62

第 8 章 評価と考察

8.3

定性評価

本節では，本システムの設計の正当性と実装が適当に動作するかを検証するために，本研究で実装した MRRS を動作させ，評価を行う．本研究で実装した MRRS が以下の動作を検証する．

• 移動ルータ間の情報交換• 動的なネットワーク構成の変更• トラフィックの振り分け

8.3.1

移動ルータ間の情報交換

本実験では，2 つの移動ルータが NEMO 集合を構成した際，情報交換が適切に行われているか検証する．実験は，図 8.1 に示した実験環境を用いた．移動ルータ間で交換される情報は，NMRLとトラフィック情報である．
まず，移動ルータ MR1 と MR2 が NEMO 集合を構成したところ，MR2 のデバッグメッセージに図 8.4 の出力を得た．NMRL と BUL の情報がデバッグ情報として出力される．NMRL における最初の列は，外部インターフェイスがローカル（LOCAL）か近隣（NEIGH）かを示している．
2 列目がそのインターフェイスに割り当てられた BID である．3 列目（PRI）は BID プライオリ
ティを示している．4 列目の HoA は外部インターフェイスが搭載されている移動ルータの Home
Address を示す．5 列目はバッテリの情報である．移動ルータの電源供給がなされている場合には，
AC と表示され，バッテリによる電源供給の場合には，BAT と表示される．百分率はバッテリの残量である．NMRL エントリの最後の列（cons）は，外部インターフェイスの電源消費を表わす．
数字が大きいほどバッテリ消耗が激しいことを示している．
BUL のエントリは MRRS 独自の実装ではなく，NEMO の仕様に基づくものである．図 8.4 の出力によって，NEMO 集合に 3 つの外部インターフェイスが存在しており，移動ルータ MR2 がHome Agent まで３つのトンネルを確立していることがわかる．
移動ルータが NEMO 集合から離脱した際，移動ルータ MR2 の NMRL の近隣 Binding のエン
トリはライフタイム分経過した後，タイマ期限切れによって削除された．また，BUL エントリの内，内部インターフェイスの Care-of Address を登録した者がライフタイム分経過した後，タイマ
期限切れによって削除された．さらに，内部インターフェイス経由で確立されていたトンネルは削除された．
¶³====NMRL======================================================================| LOCAL | BID 202 | PRI 10 | HoA 2001:2:0:1:0:0:0:2222 | BAT 97 % | cons 10 || LOCAL | BID 201 | PRI 15 | HoA 2001:2:0:1:0:0:0:2222 | BAT 97 % | cons 15 || NEIGH | BID 101 | PRI 5 | HoA 2001:1:0:1:0:0:0:1111 | AC 100 % | cons 5 |====BUL ======================================================================| BULE | BID 202 | PRI 10 | CoA 2001:6:0:0:207:40ff:fe7c:4b44 | eth1 | ba ready || BULE | BID 201 | PRI 15 | CoA 2001:5:0:0:a00:46ff:fee6:9f1f | ath0 | ba ready || BULE | BID 101 | PRI 5 | CoA 2001:1:0:2:a00:46ff:fee1:f55 | eth0 | ba ready |==============================================================================µ

図 8.4: NMRL の同期63´

8.3. 定性評価

次に，移動ルータ MR1 と MR2 が NEMO 集合を構成している際に，MNN1 から MR1 経由でCN へポート 5001 番のトラフィックを送信し，MNN2 から MR2 経由で CN へポート 5002 番とポート 5003 番のトラフィックを送信した．移動ルータ MR2 のデバックメッセージとして，図 8.5の出力を得た．
ONGOING TRAFFIC のエントリには，３つのトラフィック情報が出力されている．最初のエントリは，MR1 経由で発生したポート 5001 番のトラフィックの情報を表わしており，2 番目，3番目のエントリは，MR2 で発生した，ポート 5002 番，ポート 5003 番のトラフィックの情報を表わしている．
トラフィックが流れつづけている間は，各エントリが削除されることはなかった．次に，各トラフィックの送信を停止した際，それぞれのエントリはライフタイムである１５秒が経過した後，タ
イマ期限切れによって削除された．
以上のことから，NMRL の同期と，トラフィック情報の同期は正常に動作していることが確認
できた．
¶

³

|||||||| ONGOING TRAFFIC |||||||||||||||||||||||||||||||||||| port 5001 | HoA 2001:1:0:1:0:0:0:1111 | lifetime 15 | expire 30 || port 5002 | HoA 2001:2:0:1:0:0:0:2222 | lifetime 15 | expire 30 || port 5003 | HoA 2001:2:0:1:0:0:0:2222 | lifetime 15 | expire 30 ||||||||| ONGOING TRAFFIC |||||||||||||||||||||||||||||||||||µ´

図 8.5: トラフィック情報の同期

8.3.2

動的なネットワーク構成の変更

本実験では，トラフィックとバッテリ残量に応じて動的にネットワークの構成を変更できるか検証する．実験は，図 8.1 に示した実験環境を用いた．
まず，電源供給された移動ルータ MR1 と MR2 を接続し，NEMO 集合を構成した（図 8.6）．
MR2 のデバッグメッセージに図 8.7 の上部を得た．図 8.7 は紙面の余白の都合上，BID プライオリ
ティを省略し，Home Address と Care-of Address を省略形で記述した．メッセージから，NEMO集合には，3 つの利用可能な外部インターフェイスが存在しており，MR2 の NMRL には 3 つのNMRL エントリが追加されている．また，BUL の出力より MR2 は HA2 との間に 3 つのトンネルを確立している様子がわかる．
次に，移動ルータ MR2 の電源ケーブルをはずし，バッテリ駆動に変更する．MR2 は電源供給状況の変化から，バッテリーセーブ状態への移行する．NMRL エントリを検索し，最もバッテリ消費の少ないインターフェイス以外の電源をオフにする．この場合は，移動ルータ MR1 の電源状
態が AC であるため，BID の 101 が選ばれた．図 8.7 の下部を参照すると，MR2 の NMRL には，最もバッテリ消耗の少ない外部インターフェイスに対応するエントリだけが示されている．また，HA2 とのトンネルの確立を示す BUL には，最もバッテリ消耗の少ない外部インターフェイスを経由するトンネルのエントリが追加されている．電源の供給状況に応じて，ネットワークの構成を動的に変更することが可能であることが示された．
次に，MNN2 から移動ルータ MR2 経由で CN へポート 5001 番，5002 番とポート 5003 番のト
ラフィックを送信した．移動ルータ MR2 のデバックメッセージとして，図 8.8 の出力を得た．発64

第 8 章 評価と考察
¶

HA1

HA2

ath0

MR1

eth1

MR2
eth0

MR2の電源ケーブルをはずす

HA1

MR1

HA2

MR2

図 8.6: 電源供給状況の変化³

update_battery_all: battery status: AC
97%
update_battery_all: lowest IF is BID 101
update_battery_all: UP
up_all_if: ifconfig eth1 up
up_all_if: ifconfig ath0 up
up_all_if: ifconfig eth0 up====NMRL=======================================================| LOCAL | BID 202 | HoA 2001:2:0:1::2222 | AC 97 % | cons 10 || LOCAL | BID 201 | HoA 2001:2:0:1::2222 | AC 97 % | cons 15 || NEIGH | BID 101 | HoA 2001:1:0:1:::1111 | AC 100 % | cons 5 |====BUL =======================================================| BULE | BID 202 | CoA 2001:6::EUI | eth1 | ba ready|| BULE | BID 201 | CoA 2001:5::EUI | ath0 | ba ready|| BULE | BID 101 | CoA 2001:1:0:2::EUI | eth0 | ba ready|===============================================================（省略）

MR2 の電源ケーブルをはずす

update_battery_all: battery status: BATTERY
97%
update_battery_all: lowest IF is BID 101
update_battery_all: DOWN
down_high_if: ifconfig eth1 down
down_high_if: ifconfig ath0 down====NMRL=======================================================| NEIGH | BID 101 | HoA 2001:1:0:1::1111 | AC 100 % | cons 5 |====BUL =======================================================| BULE | BID 101 | CoA 2001:1:0:2::EUI | eth0 | ba ready|===============================================================µ

図 8.7: バッテリーセーブ状態への移行
生したトラフィックに適する外部インターフェイスを起動し，それぞれのインターフェイスからトンネルを生成できることを確認した．
¶³|||||||| ONGOING TRAFFIC |||||||||||||||||||||||||||||||||||| port 5001 | HoA 2001:2:0:1:0:0:0:2222 | lifetime 15 | expire 28 || port 5002 | HoA 2001:2:0:1:0:0:0:2222 | lifetime 15 | expire 28 || port 5003 | HoA 2001:2:0:1:0:0:0:2222 | lifetime 15 | expire 28 ||||||||| ONGOING TRAFFIC |||||||||||||||||||||||||||||||||||
update_battery_all: battery status: BATTERY
96%
update_battery_all: lowest IF is BID 101
update_battery_all: UP
up_all_if: ifconfig eth1 up
up_all_if: ifconfig ath0 up
up_all_if: ifconfig eth0 up====NMRL======================================================================| NEIGH | BID 101 | PRI 5 | HoA 2001:1:0:1:0:0:0:1111 | AC 100 % | cons 5 || LOCAL | BID 202 | PRI 10 | HoA 2001:2:0:1:0:0:0:2222 | BAT 96 % | cons 10 || LOCAL | BID 201 | PRI 15 | HoA 2001:2:0:1:0:0:0:2222 | BAT 96 % | cons 15 |====BUL ======================================================================| BULE | BID 101 | PRI 5 | CoA 2001:1:0:2:a00:46ff:fee1:f55 | eth0 | ba ready|| BULE | BID 202 | PRI 10 | CoA 2001:6:0:0:207:40ff:fe7c:4b44 | eth1 | ba ready|| BULE | BID 201 | PRI 15 | CoA 2001:5:0:0:a00:46ff:fee6:9f1f | ath0 | ba ready|==============================================================================µ

図 8.8: トラフィック発生によるネットワーク構成の変更

65

´

´

8.4. 定量評価

8.3.3

トラフィックの振り分け

本実験では，ポート番号によってトラフィックの振り分けが可能であることを示す．本実験には，図 8.1 に示した実験環境を用いた．本実験では，ポート番号によるトラフィックを示すため，
MNN2 から CN へポートに 5001 番，5002 番，および 5003 番，を指定したトラフィックを流す．
実験には，経路とその経路に要するラウンドトリップタイムを示すため，traceroute6[58] コマン
ドを用いた．移動ルータ MR2 の振り分けポリシを図 8.9 に示すように設定した．MR2 は，ポー
ト 5001 番をリンク（B）へ，ポート 5002 番をリンク（C）へ，ポート 5003 番をリンク（A）へと転送する設定となっている．
ポート番号に 5001 番，5002 番，5003 番を指定した traceroute6 コマンドにおいて図 8.10 の出力を得た．NEMO のトンネルによってパケットがカプセル化されている区間については，経路の出力が得られない．そのため，トンネル区間をのぞいた出力は，3 つの出力で同様の経路となる．
一方，ラウンドトリップタイムに着目すると，ポート 5001 番で 207.79 ミリ秒，ポート 5002 番で310.48 ミリ秒，ポート 5003 番で 58.5 ミリ秒となり，図 8.3 と表 8.2 にまとめたラウンドトリップ
タイムとほぼ同様となった．以上のことから，設定の通りにトラフィックの振り分けが可能である
ことが検証された．
¶

CN

HA1

HA2

(A)

(B)

(C)

ポート5003番

ポート5001番

ポート5002番

MR1

MR2

MNN2
図 8.9: 通信の分配ポリシ³

MNN2# traceroute6 -p 5001 CN
traceroute to CN (2001:3::2) from 2001:2:0:2::feed,
30 hops max, 16 byte packets
1 MR2 (2001:2:0:1::2222) 0.357 ms 0.264 ms 0.101 ms
2 HA2 (2001:2::2) 207.9 ms 203.633 ms 207.71 ms
3 Router4 (2001:2::1) 211.715 ms 207.479 ms 207.783 ms
4 CN (2001:3::2) 207.792 ms 207.58 ms 207.983 ms
MNN2# traceroute6 -p 5002 CN
traceroute to CN (2001:3::2) from 2001:2:0:2::feed,
30 hops max, 16 byte packets
1 MR2 (2001:2:0:1::2222) 3.427 ms 0.608 ms 2.869 ms
2 HA2 (2001:2::2) 305.173 ms 307.605 ms 307.859 ms
3 Router4 (2001:2::1) 303.909 ms 307.769 ms 307.905 ms
4 CN (2001:3::2) 307.858 ms 311.732 ms 311.841 ms
MNN2# traceroute6 -p 5003 CN
traceroute to CN (2001:3::2) from 2001:2:0:2::feed,
30 hops max, 16 byte packets
1 MR2 (2001:2:0:1::2222) 0.357 ms 0.263 ms 0.242 ms
2 HA2 (2001:2::2) 51.902 ms 55.475 ms 55.767 ms
3 Router4 (2001:2::1) 55.709 ms 55.61 ms 55.67 ms
4 CN (2001:3::2) 59.747 ms 55.532 ms 60.21 msµ

図 8.10: ポート番号によるトラッフィクの振り分け

8.4

定量評価

本節では，本システムの性能測定を行う．

66´

第 8 章 評価と考察

8.4.1

TCP トラッフィク発生時のスループットと RTT の計測

本実験では，移動ルータが NEMO 集合へ参加し，利用できる経路が増加することに伴って，利用可能な帯域が向上することを示す．スループットの向上が見られるか確認する．実験は，図 8.1に示した実験環境を用いた．本実験では，MNN2 から CN まで MR2 経由で 3 種類の TCP トラ
フィックと ICMPv6 のトラッフィクが発生している時に，新規に移動ルータ（MR2）が参加した
場合のトラッフィクのスループットとラウンドトリップタイムを計測する．スループットの計測に iperf，ラウンドトリップタイムの計測には ping6 を利用した．
CN

TCP ポート5001番

CN

TCP ポート5002番
TCP ポート5003番
ICMPv6

HA1
(A)

HA2
(B)

MR1の参加

(C)

MR1

HA1

HA2
(B)

(A)

MR2

MR1

(C)

MR2

MR1の離脱MNN2

MNN2

０秒から１００秒まで
２００秒から３００秒まで

１００秒から２００秒まで

図 8.11: TCP 通信における移動ルータの参加
実験では，CN を iperf のサーバ，MNN2 を iperf のクライアントとし，同時にポート番号に 5001
番，5002 番，5003 番を指定した TCP トラフィックを流した．スループットの記録は 3 秒間隔で行った．同時に，MNN2 から CN へ，56 バイトの ICMPv6 パケットを 1 秒間隔で送信した．本実
験を 300 秒間行った．
0 秒から 100 秒では，全ての通信が MR2 の外部インターフェイスから送受信される．TCP ポー
ト 5002 番のトラフィックがリンク（B）から送受信され，TCP ポート 5001 番，TCP ポート 5003
番，および ICMPv6 のトラフィックがリンク（C）から送受信される．
100 秒から 200 秒では，MR1 の移動ネットワークと MR2 の移動ネットワークが内部で接続し，NEMO 集合が構成される．MR2 は合計で，NEMO 集合内の複数の MR の持つ 3 つの外部イン
ターフェイスを利用可能になる．TCP ポート 5003 番，および ICMPv6 のトラフィックがリンク（A）から送受信される．TCP ポート 5002 番のトラフィックがリンク（B）から送受信され，TCP
ポート 5001 番のトラフィックがリンク（C）から送受信される．
200 秒から 300 秒では，移動ルータ MR1 が NEMO 集合を離れて MNN2 から発生する全てのト
ラフィックが MR2 の持つ外部インターフェイスを経由することとなる．トラフィックの振り分け
ポリシは 0 秒から 100 秒のポリシと同様である．
スループットとラウンドトリップタイムの実験結果を図 8.12 に示す．スループットのグラフは，3 種類の TCP トラッフィクの合計である．
0 秒から 100 秒までは，TCP ポート 5001 番と TCP ポート 5003 番で激しい輻輳が起こっていたと想定される．表 8.3 に示す通り， 0 秒から 100 秒までのスループットを基準とすると，MR1

67

8.4. 定量評価

TCP ポート番号 5001

3500

TCP ポート番号 5002

Throughput (Kbits/sec)

TCP ポート番号 5003

3000
MR1の参加MR1の離脱

2500

2000

1500

1000

500

0
1200
RTT

RTT (Seconds)

1000
800
600
400
200
0
Packet loss
0

50

100

150

200

250

300

経過時間 (秒)図 8.12: TCP 通信における移動ルータの参加によるスループットの変化
が NEMO 集合に参加している期間である 100 秒から 200 秒は，TCP ポート 5001 番と TCP ポー
ト 5003 番でスループットの向上が見られた．TCP ポート 5001 番で 357.9 Kbits/sec （83% 向上），また TCP ポート 5003 番で 788.41 Kbits/sec（161%向上）のスループットが改善した．また，3 種類の TCP トラッフィクの合計スループットは，1073.15 Kbits/sec （74%向上）の向上が見ら68

第 8 章 評価と考察

表 8.3: TCP 通信における移動ルータの参加によるスループットと RTT の変化
0 秒〜100 秒
100 秒〜200 秒
200 秒〜300 秒

TCP ポート 5001 番
TCP ポート 5002 番
TCP ポート 5003 番
TCP 合計RTT

428.73 Kbits/sec
530.26 Kbits/sec
489.56 Kbits/sec
1448.55 Kbits/sec

786.63 Kbits/sec
457.11 Kbits/sec
1277.97 Kbits/sec
2521.70 Kbits/sec

502.30 Kbits/sec
498.20 Kbits/sec
296.21 Kbits/sec
1296.70 Kbits/sec

539.51 ミリ秒

61.33 ミリ秒

671.37 ミリ秒

れた．本システムが動作することで利用可能な帯域を増大できることが確認できた．一方，移動
ルータ MR1 が，NEMO 集合を離脱する際，離脱検知と経路切替えに伴うパケットロスが起きる
ため，200 秒から 300 秒の 3 種類の TCP の合計スループットは，0 秒から 100 秒までのスループットを基準とすると，151.85 Kbits/sec（10%）減少した．
また，ping6 プログラムの記録から，ICMPv6 のトラフィックが移動ルータの参加の際に 3 秒間，移動ルータの離脱の際に 3 秒間通信不能となったことを確認した．これらは，移動ルータの参加・離脱の検知，利用経路の切替えによるものである．MNN と CN のラウンドトリップタイムは，移動ルータ MR1 の参加によって，539.51 ミリ秒から 61.33 ミリ秒へと減少した．これはラウンドト
リップタイムの 478.18 ミリ秒（81%）の改善に相当する．

8.4.2

TCP と UDP トラッフィク発生時のスループットと RTT の計測

本実験では，移動ルータが NEMO 集合へ参加し，利用できる経路が増加することに伴って，利用可能な帯域が向上することを示す．スループットの向上が見られるか確認する．実験は，図 8.1に示した実験環境を用いた．
本実験では，MNN2 から CN まで MR2 経由で 2 種類の TCP トラフィックと 1 種類の UDP トラ
フィック，ICMPv6 のトラッフィクを発生させる．トラフィック発生中に，新規に移動ルータ（MR2）が参加した場合のトラッフィクのスループットとラウンドトリップタイムを計測する．スループッ
トの計測に iperf，ラウンドトリップタイムの計測には ping6 を利用した．
実験では，CN を iperf のサーバ，MNN2 を iperf のクライアントとし，同時にポート番号に 5001
番，5002 番を指定した TCP トラフィックとポート番号に 5003 番を指定した UDP トラフィックを流した．UDP のトラフィックは，800Kbits/sec に設定して送信した．スループットの記録は 3 秒
間間隔で行った．さらに同時に，MNN2 から CN へ，56 バイトの ICMPv6 パケットを 1 秒間隔で送信した．本実験は，300 秒間行った．
0 秒から 100 秒では，全ての通信が MR2 の外部インターフェイスから送受信される．TCP ポー
ト 5002 番のトラフィックがリンク（B）から送受信され，TCP ポート 5001 番，UDP ポート 5003
番，および ICMPv6 のトラフィックがリンク（C）から送受信される．
100 秒から 200 秒では，MR1 の移動ネットワークと MR2 の移動ネットワークが内部で接続し，NEMO 集合が構成される．MR2 は合計で，NEMO 集合内の複数の MR の持つ 3 つの外部イン
ターフェイスを利用可能になる．UDP ポート 5003 番，および ICMPv6 のトラフィックがリンク（A）から送受信される．TCP ポート 5002 番のトラフィックがリンク（B）から送受信され，TCP
ポート 5001 番のトラフィックがリンク（C）から送受信される．
200 秒から 300 秒では，移動ルータ MR1 が NEMO 集合を離れて MNN2 から発生する全てのト

69

8.4. 定量評価

TCP ポート5001番

CN

CN

TCP ポート5002番
UDP ポート5003番 0.8Mbps
ICMPv6

HA1

HA2

HA1

HA2

MR1の参加

(A)

(B)

MR1

(C)

(B)

(A)

MR2

(C)

MR1

MR2

MR1の離脱MNN2

MNN2

０秒から１００秒まで
２００秒から３００秒まで

１００秒から２００秒まで

図 8.13: TCP と UDP の混在通信における移動ルータの参加
ラフィックが MR2 の持つ外部インターフェイスを経由することとなる．トラフィックの振り分け
ポリシは 0 秒から 100 秒のポリシと同様である．
表 8.4: 実験環境の評価
0 秒〜100 秒
100 秒〜200 秒

200 秒〜300 秒

TCP ポート 5001 番
TCP ポート 5002 番
UDP ポート 5003 番
TCP と UDP 合計

217.89 Kbits/sec
691.16 Kbits/sec
660.16 Kbits/sec
1569.22 Kbits/sec

800.55 Kbits/sec
786.13 Kbits/sec
665.52 Kbits/sec
2252.20 Kbits/sec

98.12 Kbits/sec
529.13 Kbits/sec
691.19 Kbits/sec
1318.45 Kbits/sec

パケットロス率19.2 %（19/99）
1522.56 ミリ秒

6.4 % （ 6/94）
56.84 ミリ秒

22.6 %（21/93）
1096.48 ミリ秒

RTT

スループットとラウンドトリップタイムの実験結果を図 8.14 に示す．スループットのグラフは，2 種類の TCP トラッフィクと 1 種類の UDP トラフィックの合計である．
表 8.2 の (i) に示した通り，TCP のトラフィックにおいて 768 Kbits/sec のスループットを記録した経路に，本実験では，800 Kbits/sec の UDP トラフィックを流す．そのため，0 秒から 100 秒において，図 8.14 中の（C）の経路は，TCP ポート 5001 番と UDP ポート 5003 番のトラフィッ
クで激しい輻輳が起こっていたと予想される．
UDP は輻輳回避の仕組みがなく，経路（C）の利用可能な帯域を消耗している．一方，輻輳回避の仕組みが有効な TCP のスループットは，非常に低く 217.89 Kbits/sec に抑えられている．また，この期間のパケットロス率は，19.2%を記録している．
100 秒から 200 秒において，移動ルータ MR1 が NEMO 集合に参加することで，新たな経路が利用可能となった．この期間では，複数経路利用によって輻輳を回避することで，TCP ポート 5001
番でスループットの向上が見られた．表 8.4 に示す通り， 0 秒から 100 秒までのスループットを基準とすると，MR1 が NEMO 集合に参加している期間は，TCP ポート 5001 番のスループット
が 217.89 Kbits/sec から 800.55 Kbits/sec へ向上した．これは，267% のスループット改善に相70

第 8 章 評価と考察

TCP ポート番号 5001

2500

TCP ポート番号 5002
UDP ポート番号 5003
MR1の参加MR1の離脱Throughput (Kbits/sec)

2000

1500

1000

500

0
2500
RTT

RTT (Seconds)

2000
1500
1000
500

0
Packet loss
0

50

100

150

経過時間 (秒)

200

250

300

図 8.14: TCP と UDP の混在通信における移動ルータの参加によるスループットの変化
当する．また，2 種類の TCP と 1 種類の UDP のスループットの合計は，682.99 Kbit/sec（44%）
増加した．
本システムが動作することで利用可能な帯域を増大できることが確認できた．一方，移動ルー
タ MR1 が，NEMO 集合を離脱する際，離脱検知と経路切替えに伴うパケットロスが起きるため，
200 秒から 300 秒の 2 種類の TCP と 1 種類の UDP トラフィックの合計スループットは，0 秒から

71

8.4. 定量評価

100 秒までのスループットを基準とすると，250.76Kbits/sec （16%）減少した．
また，ping6 プログラムの記録から，ICMPv6 のトラフィックが移動ルータの参加の際に 4 秒間，移動ルータの離脱の際に 8 秒間通信不能となったことを確認した．これらは，移動ルータの参加・離脱の検知，利用経路の切替えによるものである．MNN と CN のラウンドトリップタイムは，移動ルータ MR1 の参加によって，1522.56 ミリ秒から 56.84 ミリ秒へと減少した．これはラウンド
トリップタイムの 1465.72 ミリ秒（96%）の改善に相当する．

バッテリ消耗の抑制

8.4.3

本実験では，NEMO 集合内の協調によって，バッテリの消耗抑制にあたえる影響を示す．実験は，MR2 の NEMO 協調の機能を無効化したものと，機能を有効にしたものを比較することで行う．
NEMO 集合内には，電源の供給が行われている MR1 とバッテリ駆動の MR2 が接続している．
NEMO 集合内における協調を無効にしている場合，MR2 は自身の持つ外部インターフェイスのうち最もバッテリ消耗の少ないインターフェイスを起動する．本実験では，実験マシンの内蔵無線の ath0 を起動する．また，NEMO 集合内における協調を有効にしている場合，MR2 は，電源の供給が行われている MR1 の外部インターフェイスを経由するトンネルを確立する．
実験結果を図 8.15 に示した．NEMO 集合内における協調を無効にしている場合，MR2 の起動
時間は 4 時間 38 分であったの対し，NEMO 集合内における協調を有効にしている場合は，5 時間
15 分起動していた．NEMO 集合内の協調によって，バッテリ駆動の移動ルータ MR2 の起動時間
が 37 分間延長した．これは，12%の改善に相当する．
100
NEMO集合内協調が有効
NEMO集合内協調が無効

9080Battery remaining (%)

70

37分延長
12 %改善

60
50
40
30
20
10
0

0

50

100

150

200
経過時間（分）図 8.15: バッテリ消耗の抑制

72

250

300

350

第 8 章 評価と考察

8.5

本章のまとめ

本章では，本研究で提案した MRRS の有効性を検証した．定性評価では，本研究で実装した
MRRS が正常に動作することを確認した．定量評価では，本システムを用いることで，通信時には遅延・帯域・パケット到達率などの通信の品質が向上した．さらに無通信時場合には，バッテリ消耗の抑制が可能であることを確認した．
結論として，新たな移動ルータの参加による通信品質の改善は，移動ルータの離脱によるオー
バーヘッドと比較して大きい．しかし，移動ルータの参加・離脱が頻繁に繰り返される環境においては，オーバーヘッドが増大し，通信品質の改善が減少することが予想される．本システムの適応は，移動ルータが長期間にわたって NEMO 集合を構成する場合が望ましいことがわかった．

73

第 9 章 結論:研究のまとめと今後の課題
本章では，まとめと今後の課題を挙げ，本論文の結論とする．

9.1

研究のまとめ本研究によって，NEMO 集合に接続する移動ルータを協調動作させて，移動体ネットワークが単独の移動ルータへ依存を解消することが可能となった．各移動ルータの持つ無線デバイスをはじめとするさまざまな計算機資源を，通信の状態や資源の状態に応じて NEMO 集合内で相互に利用できる環境を作ることで，NEMO 集合全体の資源の利用効率を高めた．
また，これらの機構は既存の IPv6 ノードにたいして新たな機能の追加や変更を必要とすることなく構築できた．そのため，本研究で構築したシステムは NEMO 集合内に持ち込まれる計算機
すべてにこれらの利点を提供できる．

9.2

今後の課題

今後の課題として，実用性，セキュリティの対応，負荷分散，標準化への議論などが挙げられる．
本システムの実用性として，本システムを自動車に設置し，運用を行なう．インターネット自動車プロジェクトの実証実験において本研究を用いることで，システムの改良を行なう．具体的には，実際のフィールドで実験を行なうことで無線メディアの特性を考慮したシステムの構築を行なう必要が生じる．また，ポリシを記述するインターフェイスを充実することで．利便性を向上させる．
本システムにおいて，複数トンネルを用いてトラフィック分散を行なうことができる．帯域や遅延など特性の違うメディアを利用して複数トンネルを同時利用する場合．パケットの到着順序が一様にならない．そのため，TCP など上位の層を考慮したトラフィック分配の仕組みが必要となる．今後は，トラフィック分配の仕組みなどを検討する必要がある．

74

謝辞
本論文の作成にあたり，御指導いただきました慶應義塾大学環境情報学部教授 村井純博士，同大学環境情報学部教授 萩野達也博士，同大学理工学部教授 寺岡文男博士，同大学大学院政策・メディア研究科助教授 植原啓介博士に深く感謝いたします．
本論文にとどまらず，研究慶應義塾大学環境情報学部教授 徳田英幸博士，同大学環境情報学部教授 中村修博士，同大学環境情報学部助教授 楠本博之博士，同大学政策・メディア研究科助教授
高汐一紀博士，同大学境情報学部専任講師 湧川隆次博士に感謝致します．
また，本論文の全般をとおして，ご指導と助言をいただきました，奈良先端科学技術大学院大学教授 砂原秀樹博士，ソニー・エリクソン・モバイルコミュニケーションズ株式会社ならびに慶
應義塾大学大学院政策・メディア研究科 博士課程 杉本信太氏，同大学大学院政策・メディア研究
科 助手 朝枝仁博士，同大学院 政策・メディア研究科 助手 佐藤雅明氏，同大学大学院政策・メディア研究科 博士課程 三屋光史朗氏，同大学大学院政策・メディア研究科 研究員 岡田耕司氏，
東京大学大学院情報理工学系研究科 研究員 Romain Kuntz 氏に感謝いたします．
いつも研究を助けていただいた慶應義塾大学大学院政策・メディア研究科 修士課程 中村友一氏，同大学環境情報学部 永井ゆり氏，同大学総合政策学部 加藤伸悟氏に感謝します．
また，いつも同じ時期に本論文を書いて，互いの論文を参考にし不備を指摘しあった同期の友人 遠山祥広氏，小椋康平氏，吉田雅史氏，松園和久氏，谷隆三郎氏，工藤紀篤氏に深く感謝致します．
そして，本論文の作成にあたって御協力していただいた WIDE プロジェクト インターネット自動車ワーキンググループの皆様，慶應義塾大学 徳田・村井・楠本・中村・高汐・湧川合同研究室の皆様に感謝致します．とくに，週 1 回のミーティングにおいて本論文を書くに当たっての相談を聞いていただき，適切なアドバイスを与えて下さった icar 研究グループの皆様に感謝致します．

75

参考文献
[1] IEEE Std 802.11a 1999. Supplement to IEEE standard for information technology - telecommunications and information exchange between systems - local and metropolitan area networks - speciﬁc requirements. Part 11: wireless LAN Medium Access Control (MAC) andPhysical Layer (PHY). Institute of Electrical and Electronic Engineers, Inc., New York,NY, 1999.
[2] IEEE Std 802.11b 1999. Supplement to 802.11-1999,Wireless LAN MAC and PHY speciﬁcations: Higher speed Physical Layer (PHY) extension in the 2.4 GHz band. Institute ofElectrical and Electronic Engineers, Inc., New York, NY, 1999.
[3] IEEE Std 802.11g 2003. IEEE 802.11g-2003 IEEE Standard for Information technology Telecommunications and information exchange between systems - Local and metropolitan
area networks - Speciﬁc requirements - Part 11: Wireless LAN Medium Access Control(MAC) and Physical Layer (PHY) speciﬁcations - Amendment 4: Further Higher-Speed
Physical Layer Extension in the 2.4 GHz Band. Institute of Electrical and Electronic
Engineers, Inc., New York, NY, 2003.
[4] Dedicated Short-Range Communication - Physical layer using microwave at 5.8 GHz (review), July 2004. EN 12253:2004.
[5] Bluetooth. Speciﬁcation of the bluetooth system. Bluetooth speciﬁcation, Bluetooth, December 1999.
[6] R.Hinden S.Deering. Internet Protocol version 6 (IPv6) speciﬁcation, December 1998. IETF
RFC 2460.
[7] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in IPv6, June 2004. IETF RFC
3775.
[8] Vijay Devarapalli, Ryuji Wakikawa, Alexandru Petrescu, and Pascal Thubert. Network
Mobility (NEMO) Basic Support Protocol, January 2005. IETF RFC3963.
[9] WIDE project, June 2005. http://www.wide.ad.jp/.
[10] InternetCAR project, January 2007. http://www.icar.wide.ad.jp/.
[11] R. Wakikawa, Wakikawa Ryuji, T. Ernst, and K. Nagami. Multiple Care-of Addresses
Registration, October 2006. IETF work in progress, draft-ietf-monami6-multiplecoa-01.txt.

76

第 9 章 結論:研究のまとめと今後の課題[12] Koshiro Mitsuya, Kazuyuki Tasaka, and Ryuji Wakikawa. A Schema Fragment for
Flow Distribution, October 2006. IETF work in progress, draft-mitsuya-monami6-ﬂowdistribution-policy-02.
[13] The Internet Engineering Task Force, January 2007. http://www.ietf.org/.
[14] NEMO - Network Mobility Working Group, January 2007. http://www.ietf.org/html.
charters/nemo-charter.html.
[15] Zigbee consortioum, 2005. http://www.zigbee.org.
[16] IEEE Std 802.16-2004. IEEE standard for Local and metropolitan area networks, Part
16:Air Interface for ﬁxed broadband wireless access systems. Institute of Electrical andElectronic Engineers, Inc., New York, NY, October 2004.
[17] IEEE Std 802.16a 2003. IEEE Standard for Local and metropolitan area networks — Part
16: Air Interface for Fixed Broadband Wireless Access Systems— Amendment 2: Medium
Access Control Modiﬁcations and Additional Physical Layer Speciﬁcations for 2-11 GHz.
Institute of Electrical and Electronic Engineers, Inc., New York, NY, May 2003.
[18] IEEE Std 802.16e 2005. IEEE Standard for Local and metropolitan area networks Part
16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems Amendment
for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operationin Licensed Bands. Institute of Electrical and Electronic Engineers, Inc., New York, NY,
2005.
[19] IEEE 802.20 Mobile Broadband Wireless Access (MBWA), January 2007. http://www.
icar.wide.ad.jp/.
[20] PHS -Personal Handy-phone System-, January 2007. http://www.phsmou.or.jp/.
[21] 3GPP2. CDMA2000 wireless ip network standard: Packet data mobility and resource
management. 3GPP2 std. X.S0011-003-C v1.0, September 2003.
[22] International Telecommunication Union, January 2007. http://www.itu.int/.
[23] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg. SIP: Session Initiation Protocol,
March 1999. IETF RFC 1631.
[24] H.323 version6 - Packet-based multimedia communications systems, May 2006. http://www.itu.int/.
[25] F.L. Lewis. Wireless sensor networks, November 2004. Smart Environments: Technologies,
Protocols, Applications, ed. D.J. Cook and S.K. Das, Wiley, New York, 2004.
[26] Ahmed Safwat, Hossam Hassanein, and Hussein Mouftah. Energy-aware routing in manets:
analysis and enhancements. In MSWiM ’02: Proceedings of the 5th ACM international
workshop on Modeling analysis and simulation of wireless and mobile systems, pages 46–
53, New York, NY, USA, 2002. ACM Press.
779.2. 今後の課題[27] Peng-Jun Wan, Gruia Calinescu, Xiangyang Li, and Ophir Frieder. Minimum-energy broadcast routing in static ad hoc wireless networks, 2001. IEEE INFOCOM, Anchorage, AK.
[28] Inc. Japan Automobile Manufacturers Association. The motor industry of japan 2006, May
2006. http://www.jama-english.jp/publications/MIJ2006.pdf, 78 ページ.
[29] Neil Mawston.
Global mobile phone shipments will reach 1 billion units
in 2006, April 2006.
http://www.strategyanalytics.net/default.aspx?mod=
PressReleaseViewer&a0=2878.
[30] Ultra-Wideband (UWB) technology forum, January 2007. http://uwbforum.org/index.
php.
[31] S. Kent and R. Atkinson. Security Architecture for the Internet Protocol, November 1998.
IETF, RFC 2401.
[32] Arkko J., Devarapalli V., and F. Dupont. Using IPsec to Protect Mobile IPv6 Signaling
between Mobile Nodes and Home Agents, June 2004. IETF RFC 3776.
[33] Kent S. and R. Atkinson. IP Encapsulating Security Payload (ESP), November 1998. IETF,
RFC 2406.
[34] Hiroshi Mineno, Yuki Kawashima, Susumu Ishihara, and Tadanori Mizuno. Collaboration
mechanism for mobile ip-based link aggregation system, April 2006. IPSJ Digital Courier,Vol. 2, pp.357-368.
[35] 中安 俊行, 舛田 知広, 石原 進 . 車載 Mobile Router を用いた通信回線共有方式におけるAlliance の構築手法の設計および実装, July 2006. マルチメディア，分散，協調とモバイル(DICOMO2006) シンポジウム論文集, 情報処理学会シンポジウムシリーズ.
[36] Y. Kawashima, H. Mineno, S. Ishihara, and T. Mizuno. Evaluation of method for multiple path distribution based on delay-jitter, January 2006. Applications and the Internet
Workshops, 2006. SAINT Workshops 2006. International Symposium on Volume , Issue ,23-27.
[37] H.Esaki and H.Kan. Dynamic traﬃc load balancing mechanism for shake architecture, June
2005. Proceedings of IEEE WirelessCom2005.
[38] J. Ryu, N. Choi, E. Paik, T. Kwon, and C. Park. Failover for Multiple Mobile Routers in a
Mobile Network, October 2006. IETF work in progress, draft-ryu-nemo-mr-failover-02.txt.
[39] P. Ferguson and D. Senie. Network Ingress Filtering: Defeating Denial of Service Attacks
which employ IP Source Address Spooﬁng, May 2000. IETF RFC2827.
[40] J. Ryu, N. Choi, E. Paik, T. Kwon, and C. Park. Bypassing Ingress Filtering for Multihomed
mobile network, 2006 June. IETF work in progress, draft-ryu-nemo-ingress-ﬁltering-00.txt.
[41] 日野哲志, 湧川隆次, 植原啓介, and 村井純. 複数の移動計算機による協調通信機構の設計と実装, 2001.
78

第 9 章 結論:研究のまとめと今後の課題[42] 塚田学. Mobile network におけるインターネット接続性の動的共有に関する研究, 2005. 慶應
義塾大学 環境情報学部 卒業論文.
[43] Manabu Tsukada, Thierry Ernst, Ryuji Wakikawa, and Koshiro Mitsuya. Dynamic management of multiple mobile routers, November 2005. IEEE Malaysia International Conference on Communications and IEEE International Conference on Networks (MICC & ICON
2005), Vol.2, pp.1108-1113, Kuala Lumpur, Malaysia.
[44] Ryuji Wakikawa, Jari T. Malinen, Charles E. Perkins, Anders Nilsson, and Antti J. Tuominen. Global Connectivity for IPv6 Mobile Ad Hoc Networks, 2006 March. IETF work inprogress, draft-wakikawa-manet-globalv6-05.txt.
[45] Mobile Ad-hoc Networks (MANET), January 2007.
charters/manet-charter.html.

http://www.ietf.org/html.

[46] C. Ng, P. Thubert, M. Watari, and F. Zhao. Network Mobility Route Optimization Problem
Statement, September 2006. IETF work in progress, draft-ietf-nemo-ro-problem-statement03.
[47] C. Ng, F. Zhao, M. Watari, and P. Thubert. Network Mobility Route Optimization Solution
Space Analysis, September 2006. IETF work in progress, draft-ietf-nemo-ro-space-analysis03.
[48] A Networked Human Transporter as an Experimental Testbed of Mobile Gateway. Ryuji
Wakikawa and Kouji Okada and Noriyuki Shigechika and Tomohiro Ishihara and Yuki Oyabu and Yuri Nagai and Jun Murai, 2006. 1st IEEE Workshop on Automotive Networking
and Applications (AutoNet 2006).
[49] Linux online, January 2007. http://www.linux.org/.
[50] NEPL, NEMO Platform for Linux, January 2007. http://www.mobile-ipv6.org.
[51] NEPL, Multiple Care-of addresses registration, January 2007.
nautilus6.org/MCoA.

http://software.

[52] Romain Kuntz and Jean Lorchat. Building a fault tolerant network using a multihomed
mobile router: A case study, November 2006. Asian Internet Engineering Conference (AINTEC 2006) Bangkok, Thailand.
[53] netﬁlter/iptables project homepage - The netﬁlter.org project, January 2007. http://www.
netfilter.org/.
[54] Hewlett-Packard Corporation, Intel Corporation, Microsoft Corporation, Phoenix Technologies Ltd., and Toshiba Corporation. Advanced Conﬁguration and Power Interface
Speciﬁcation, December 30 2005. Revision 3.0a.
[55] Linux advanced routing & traﬃc control, January 2007. http://lartc.org/.

79

[56] netem - Network Emulation, January 2007. http://developer.osdl.org/shemminger/
netem/.
[57] NLANRDAST : Iperf 2.0.2 - The TCPUDP Bandwidth Measurement Tool, January 2007.
http://dast.nlanr.net/Projects/Iperf/.
[58] iputils, January 2007. http://linux-net.osdl.org/index.php/Iputils.
[59] VAIO type U VGN-U50, January 2007.
VGN-U50/.

http://www.vaio.sony.co.jp/Products/[60] Sony Programmable I/O Control Device Driver, January 2007. http://www.popies.net/
sonypi/.

付 録A

バッテリ残存時間における無線インターフェイスの起動と NEMO 動作の影響

無線インターフェイスの起動と NEMO の動作がバッテリの消耗に及ぼす影響を調べた．実験にはソニー製 VAIO type U VGN-U50[59] に Linux 2.6.15 の NEPL[50] をインストールして行った．
無線デバイスを起動した場合と，無効にした場合，NEMO を有効にした場合，無効にした場合をそれぞれ調べた．NEMO の Binding ライフタイムは 30 秒に設定した．バッテリ残量の測定実験はSony Programmable I/O Control Device Driver [60] の出力を 3 秒ごとに記録することで行った．
NEMO の動作によるバッテリの消耗の原因には，Binding Update の送信や Binding Acknowledgement の受信などが想定される．実際には，NEMO の動作の影響は，無線インターフェイス
停止時に 10 分（2%），無線インターフェイス起動時に 1 分（0.2%）とほとんど見られなかった．
一方，無線インターフェイスの起動は，NEMO 停止時に 55 分（14%），NEMO 起動時に 46 分
（12%）のバッテリ消耗の悪化が見られた．
100
無線インターフェイス停止・NEMO停止

90

無線インターフェイス停止・NEMO起動
無線インターフェイス起動・NEMO停止

80

無線インターフェイス起動・NEMO起動

70
60
50
40
30
20
10
0

0

50

100

150

200

250

300

350

400

図 A.1: バッテリ残存時間における無線インターフェイスの起動と NEMO 動作の影響

81

450

付 録B

MRRS におけるローカル Binding と近隣移動ルータ経由の Binding の状態遷
移表

表 B.1 に MRRS におけるローカル Binding の状態遷移表を示し，表 B.2 に MRRS における近隣移動ルータ経由の Binding の状態遷移表を示す．

82

83

BU 送信
→ WAIT BACKDHAAD REQ 送信→ NO HA→ WAIT BACK——-

→ L BOUND——–→ NO HA——→ IF DOWN
黙って破棄
→ IF UP NO COA
黙って破棄→ WAIT BACK

黙って破棄

→ L BOUNDBU 送信→ WAIT BACK

IF D

NO H

LOCA

WAIT

IF U

IF アップ→ IF UP NO COA——→ IF UP NO COA——–

DHAAD REP 受信

状態

NO HA

LOCAL BOUND

SELECTED

BU 送信→ WAIT BACK———→ NO HA→ WAIT BACKWAIT BACK——–→ LOCAL BOUND——→ NO HA→ WAIT BACK——→ IF DOWN——→ IF UP NO COA
BU 送信——→ IF DOWN
IF ダウン→ IF DOWN
IF ダウン
DELEG 送信IF DOWN
IF ダウン
DELEG 送信→ IF DOWN
IF ダウン→ IF DOWN（なし）→ IF UP NO COA→ L BOUND（なし）→ IF UP NO COA

黙って破棄→ NO HA→ L BOUND——→ IF DOWN——→ IF UP NO COA
BU 再送期限の更新
NMRL 広告→ L BOUND
黙って破棄

BACK 受信——–→ LOCAL BOUND
DHAAD REQ 送信→ NO HA→ WAIT BACK——→ IF DOWN——→ IF UP NO COA——–——→ IF DOWN——→ IF UP NO COA
（なし）

イベント
UNSELECTED
CoA 消滅→ WAIT BACK——→ IF DOWNDHAAD REQ 送信→ NO HA
BU 送信

IF DOWNIF UP NO COA——→ IF DOWN——
→ IF UP NO COA
——–

移動検知

状態

表 B.1: MRRS におけるローカル Binding の状態遷移表
イベント
BU 再送信期限切れ BU TIMER 期限切れ DHAAD REQ 期限切れ

黙って破棄
→ NO HA→ L BOUND——→ IF DOWN——–
→ IF UP NO COA
DHAAD REQ 送信
NMRL 広告
NO HA
黙って破棄

BACK 128 受信——→ IF DOWN——→ IF UP NO COA
DHAAD REQ 送信
NMRL 広告→ NO HA——–→ LOCAL BOUND———→ NO HAHOME REG 回数制限

付 録 B MRRS におけるローカル Binding と近隣移動ルータ経由の Binding の状態遷移表

84

———
→ WAIT BACK———→ NEIGHBOR B

WAIT BACKNEIGHBOR BOUND

DHAAD REQ 期限切れ

BU 送信
→ WAIT BACK———–→ WAIT BACKDHAAD REQ 送信→ NO HA———–→ NEIGHBOR B———→ WAIT NMRL————→ NEIGHBOR B

NMRL エントリ削除

イベント
HOME REG 回数制限
NMRL エントリ追加

黙って破棄→ NEIGHBOR B

黙って破棄→ WAIT BACKBU 送信
→ WAIT BACK———–→ NEIGHBOR B

DHAAD REQ 送信→ NO HA
黙って破棄→ NEIGHBOR B

BU 送信→ NO HA
BU 送信→ WAIT BACKBU 再送信期限の更新→ NEIGHBOR B
黙って破棄→ NEIGHBOR B

BU TIMER 期限切れ

状態

NEIGHBOR BOUND

WAIT BACK

状態

表 B.2: MRRS における近隣移動ルータ経由の Binding の状態遷移表
イベント
BU 再送信期限切れ BACK 受信BACK 128 受信
DHAAD REP 受信