電気通信大学大学院情報システム学研究科博士（工学）の学位申請論文

(1)

実環境を考慮した無線 LAN と AODV ルーチングを用いたアドホックネットワークに関する研究

沖野正宗

電気通信大学大学院情報システム学研究科博士（工学）の学位申請論文

2007 年 3 月

(2)

実環境を考慮した無線 LAN と AODV ルーチングを用いたアドホックネットワークに関する研究

博士論文審査委員会

主査加藤聰彦助教授

委員伊藤秀一教授

委員曽和将容教授

委員本田弘樹助教授

委員岡田和則助教授

委員加藤聰彦助教授

(3)

著作権所有者沖野正宗

2007

(4)

A Study on Ad hoc Network Using Wireless LAN and AODV Routing Protocol Focusing on its Application to Real Environments

Masamune Okino

Abstract

This paper describes two study items on ad hoc networks using wireless LAN and AODV routing protocol considering the adaptation of ad hoc networks to real communication environments.

At first, this paper describes the result of performance evaluation experiment by building an actual ad hoc network and performing communication experiments. As for the network environments, this paper assumes that cellular phone network might not be used, and an ad hoc disaster network needs to be constructed when firefighters are working in a deep under ground environments. In the experiments, TCP based reliable data transfer is performed over an IEEE 802.11 wireless LAN based ad hoc network. The experiments have collected the characteristics of TCP, MAC and physical layer behaviors.

Next, this paper supposes the situation that a lot of ad hoc terminals exist in a network, and proposes AODV based ad hoc routing protocol for such a high density network environment. In such an environment, there are many wireless nodes in the radio propagation range, and the routing control message overhead may increase and may suppress data transfer. This proposal restricts nodes which send routing control messages to those which are located at the boundary of radio propagation range, and it is possible to reduce routing control messages and to transfer data packets efficiently.

(5)

実環境を考慮した無線 LAN と AODV ルーチングを用いたアドホックネットワークに関する研究

沖野正宗概要

近年、無線通信技術の発展に伴い、その場に集まったノード間が無線インタフェースを用いて簡易にネットワークを構築するアドホックネットワークに関する研究が注目されている。アドホックネットワークの適用例としては、センサーネットワーク、ITS (Intelligent

Transport System)における車車間通信、通信インフラが存在しない災害時などのネットワー

ク構築などが考えられており、実用化に向けた研究開発段階にあると考えられる。

「アドホック」に関する研究開発としては、レイヤ2におけるアクティビティと、レイヤ3におけるアクティビティが存在する。レイヤ2における研究開発としては、IEEE 802.11 ワーキンググループが行っている無線 LAN における無線ノード間の直接通信を行うための技術検討がある。一方レイヤ3における研究開発としては、直接無線通信を行うことができないノード間の通信を、他のノードがルータとして動作しパケットをマルチホップに中継するためのアドホックルーチングに関する検討が行われている。例えば、アドホックルーチングプロトコルの一つであるAODV (Ad hoc On-demand Distance Vector)では、通信時に通信相手への経路を要求するメッセージを隣接ノードへブロードキャストし、それを受信したノードも同様に隣接ノードへ再ブロードキャストしていき、宛先ノードもしくは宛先への経路を知っているノードがそれに応答するメッセージを発信元ノードへ送信することによって、宛先との間の経路を確立する方法を用いている。

これらレイヤ2およびレイヤ3のアドホックネットワークの基本的機能すなわち端末間の直接通信機能と、アドホックルーチング機能については、検討が進み方式が確定してきたという状況である。

このため現在では、アドホックネットワークの基本的な機能に加えて、その高機能化、

実用化に向けた検討も行われている。そこで、筆者は研究の初期から、実環境での利用を想定したアドホックネットワークの研究に取り組んでおり、以下の研究を行った。

• 無線LANと AODVルーチングを用いたアドホックネットワークの実環境における性能評価実験

• ノード数の多い高密度環境に適したアドホックルーチング方式の提案

(6)

第一の研究では、アドホックネットワークを実際に構築しその性能評価を行った。既存のインフラを使わない災害時の消防支援ネットワークを想定した。すなわち、大深度地下や地下鉄線路のような通常の携帯電話の電波が受信できない場所で 802.11 無線 LAN と AODVルーチングを用いた通信端末を導入し、消防士に持たせたまま火災現場と消防基地の間に設置することにより、基地と消防士との間でマルチホップネットワークを行うことが考えられる。

実験では、信頼性を提供するTCPによるデータ通信を対象とした。無線LANアドホックネットワークでは無線リンク上でのフレームロスにより MAC レイヤの再送が発生し、

さらにMACレイヤのリトライアウトにより、TCPレイヤの再送が発生し、これによりTCP のスループットを低下させる。また、無線リンク上でのフレームロスは物理レベルのRSS やSNRといった性能に大きく関係すると考えられる。このため、TCPレイヤ、MACレイヤ、物理レイヤの性能パラメータをそれぞれ評価することを実験の特徴とした。

第二の研究内容としては、実際にアドホックネットワークが普及した時点を想定し、高密度なアドホックネットワークの構築に適したアドホックルーチングプロトコルの提案を行った。このような高密度なアドホックネットワークでは、経路を発見・維持するためのルーチング用の制御メッセージのオーバヘッドが大きくなるという問題が生ずる。そこで本論文では、AODVルーチングを拡張し、無線伝播範囲の離れたノードにのみ経路制御メッセージを中継させることにより、経路制御のオーバヘッドを削減する方式を提案する。

これらの研究により、以下のことが明らかとなった。

• 第一の研究により、地下街や建物内などの遮蔽された空間において、100 から 150メートルの無線LANによる直接通信で、2から3ホップの200メートルを超えるマルチホップ通信が可能であることを明らかにした。また、直接通信において、一定の距離を越えると通信状況が急激に悪化し、TCPおよび MACレイヤにおいて、再送が急増し、通信するープットが劣化することを確認した。

• 第二の研究で提案した高密度なアドホックネットワークに適したルーチングプロトコルを用いることにより、従来方式のAODVに比べて効率的に経路制御メッセージの送信を行えることを明らかにした。さらに、送信される経路制御メッセージの数を抑えたことによって、効率的にデータパケットの転送を行うことができることを示した。

(7)

図目次

図2.1 IEEE802.11 無線LANの構成ネットワーク··· 12

図2.2 DCFにおける通信手順例··· 14

図2.3 IETFにおけるアドホックルーチングの標準化動向··· 18

図4.1 アドホックノードのプロトコル構造··· 31

図4.2 直接通信の場合のノード配置··· 35

図43 AとCの間の時間に対するTCPシーケンス番号とMAC再送率··· 39

図4.4 AとCの間のMACレイヤの再送回数··· 39

図4.5 位置AとDの間のTCPシーケンス番号と無線LANのリトライの時間的変化··· 40

図4.6 位置AとEの間のTCPシーケンス番号と無線LANのリトライの時間的変化···· 41

図4.7 AとGの間の時間に対するTCPシーケンス番号とMAC再送率··· 42

図4.8 AとGの間のMACレイヤの再送回数··· 42

図4.9 ノード間の距離に対するTCPスループットとMAC再送率··· 43

図4.10 ノード間の距離に対する受信データのRSSとTCP再送率··· 44

図4.11 AとIの間の時間に対するTCPシーケンス番号とMAC再送率··· 45

図4.12 マルチホップ通信の場合のノード配置··· 46

図4.13 通信実験1のネットワーク構成その1 ··· 48

図4.14 通信実験1 TCPシーケンス番号とMAC再送率の時間的変化··· 51

図4.15 通信実験1 無線LANの再送回数のヒストグラム··· 51

図4.16 通信実験1の2 TCPシーケンス番号とMAC再送率の時間的変化··· 52

図4.17 通信実験1の2 無線LANの再送回数のヒストグラム··· 52

図4.18 通信実験1のネットワーク構成その2 ··· 53

図4.19 通信実験2の1 3.5階離れた場合のTCPシーケンス番号と無線LANのリトライの時間的変化··· 55

図4.20 通信実験2の1 3.5階離れた場合の無線LANの再送回数のヒストグラム··· 55

図4.21 3階のノードの位置による通信状況··· 56

図4.22 通信実験3の1 2ホップ通信のTCPシーケンス番号と無線LANのリトライの時間的変化··· 58

図4.23 通信実験3の1 2ホップ通信の無線LANの再送回数のヒストグラム··· 58

図4.24 通信実験3の2 3ホップ通信のTCPシーケンス番号と無線LANのリトライの時間的変化··· 59

(10)

図4.25 通信実験3の2 3ホップ通信の無線LANの再送回数のヒストグラム··· 59

図5.1 方式の概念図··· 61

図5.2 RREQメッセージのフォーマット··· 65

図5.3 起動直後のノードの最初のRREQメッセージの配信··· 68

図5.4 起動直後のノードの2回目のRREQメッセージの配信とRREPメッセージの転送··· 69

図5.5 新たなノードが無線伝播範囲に移動してきた場合のRREQメッセージの転送···· 70

図5.6 隣接ノードが無線伝播範囲の外に移動した場合のRREQメッセージの転送··· 72

図5.7 ネットワーク内で送信された制御メッセージの総数の時間的変化、ノード数： 1000個、通信ノードペア数：20、移動なし··· 75

図5.8 宛先ノードで受信されたデータパケットの総数の時間的変化、ノード数： 1000個、通信ノードペア数：20個、移動なし··· 75

図5.9 ノード配置例··· 76

図5.10 ネットワーク内で送信されたRREQメッセージの総数の時間的変化、ノード数：500個、通信ノードペア数：1個、移動なし··· 79

図5.14 通信ノードペア数に対するネットワーク内で送信された経路制御メッセージの総数、ノード数1000個、移動なし··· 83

図5.15 通信ノードペア数に対する宛先ノードで受信されたデータパケットの総数、ノード数1000個、移動なし··· 83

図5.16 通信ノードペア数に対する通信ノード間のホップカウント、ノード数1000個、移動なし··· 84

図5.17 通信ノードペア数に対する経路確立時間、ノード数1000個、移動なし··· 84

図5.18 全ノード数に対するネットワーク内で送信された経路制御メッセージの総数、通信ノードペア数40個、移動なし··· 87

図5.19 全ノード数に対する宛先ノードで受信されたデータパケットの総数、通信ノードペア数：40個、移動なし··· 87

図5.20 全ノード数に対する通信ノード間のホップカウント、通信ノードペア数：

(11)

40個、移動なし··· 88

図5.21 全ノード数に対する経路確立時間、通信ノードペア数：40個、移動なし··· 88

図5.22 ネットワーク内で送信された経路制御メッセージの総数の時間的変化、ノード

数：1000個、通信ノードペア数：20個、0-5 m/sで移動··· 90

図5.23 宛先ノードで受信されたデータパケットの総数の時間的変化、ノード数：

1000個、通信ノードペア数：20個、0-5 m/sで移動··· 90

図5.24 通信ノードペア数に対するネットワーク内で送信された経路制御メッセージの

総数、ノード数：1000個、0-5 m/sで移動··· 92

図5.25 通信ノードペア数に対する宛先ノードで受信されたデータパケットの総数、ノ

ード数：1000個、0-5 m/sで移動··· 92

図5.26 全ノード数に対するネットワーク内で送信された経路制御メッセージの総数、

通信ノードペア数：20個、0-5 m/sで移動··· 94

図5.27 全ノード数に対する宛先ノードで受信されたデータパケットの総数、通信ノー

ドペア数：20個、0-5 m/sで移動··· 94

(12)

表目次

表 1 バウンダリノードの選択結果··· 77

(13)

第 1 章はじめに

1.1

^背景

近年の無線通信技術の発展に伴い、その場に集まったノード間が無線インタフェースを用いて簡易にネットワークを構築するアドホックネットワークに関する研究が注目されている[1]。アドホックネットワークの適用例としては、センサーネットワーク、ITS (Intelligent Transport Systems)における車車間通信、災害時など通信インフラが存在しない場合のネットワーク構築などが考えられており、実用化に向けた研究開発の段階にあると考えられる。

「アドホック」に関する研究開発としては、レイヤ2におけるアクティビティと、レイヤ3におけるアクティビティが存在する。レイヤ2における研究開発としては、IEEE 802.11 ワーキンググループ[2]が行っている無線 LAN における端末間の直接通信を行うための技術検討がある。IEEE 802.11で検討されている無線LANでは、基地局とその無線伝播範囲内に存在する無線ノードが通信を行うインフラストラクチャ・モードと、基地局を必要とせず、無線ノード同士が直接通信を行うアドホック・モードの2種類のネットワーク構成をサポートしている。このうちの後者がレイヤ2におけるアドホックの検討である。

一方レイヤ3における研究開発としては、直接無線通信を行うことができないノード間の通信を、他のノードがルータとして動作しパケットを中継するマルチホップ通信に関する検討が行われている。具体的には、IETFのMANET (Mobile Ad-hoc Networks)ワーキンググループによって、無線ノード間のマルチホップ通信を実現するためのアドホックルーチングプロトコルの標準化活動が行われている。

MANETではこれまでに、マルチホップ通信の実現のためにオンデマンド型ルーチング、

リンクステート型ルーチング、ハイブリッド型ルーチングの3種類のルーチングプロトコルが検討されている。オンデマンド型ルーチングは、経路を要求する時に通信相手との経路を確立する手法であり、AODV (Ad hoc On-demand Distance Vector) [3]や、DSR (Dynamic Source Routing) [4]といったプロトコルが検討されている。これらのルーチングプロトコルでは通信要求時に経路を確立するため、定期的に送信する経路制御メッセージが少ないといったメリットがある一方で、通信要求から通信の開始までに時間が必要であるといった

(14)

特徴が上げられる。

リンクステート型ルーチングは、定期的にネットワークのトポロジー情報を交換し、あらかじめ全てのノード間の経路を確立しておく手法であり、OLSR (Optimized Link-State Routing) [5]やTBRPF (Topology Dissemination Based on Reverse-Path Forwarding) [6]といったプロトコルが検討されている。これらのプロトコルでは常に経路情報を保持しているため通信要求時にすぐに通信を開始することが可能であるが、定期的にトポロジー情報をネットワーク全体で交換する必要があるといった特徴がある。

ハイブリッド型ルーチングでは、オンデマンド型ルーチングとリンクステート型ルーチングを組み合わせた手法を用いている。例えば、ZRP (Zone Routing Protocol) [7]-[10]では近隣のノードに対しては、リンクステートに経路情報を管理し[8]、遠距離のノードに対してはオンデマンドに経路を確立している[9]。

これらのルーチングプロトコルのうち、2006年現在ではAODV、OLSR、TBRPFがRFC として標準化されている。さらに AODV と DSR を組み合わせたルーチング方式として DYMO (Dynamic MANET On-demand)[11]ルーチングが、OLSR の後継として OLSRv2 (Optimized Link-State Routing version 2) [12]がドラフトとして検討されている。

このように、レイヤ2およびレイヤ3のアドホックネットワークの基本的機能、すなわち端末間の直接通信機能と、アドホックルーチング機能については、検討が進み方式が確定してきたという状況であるといえる。

このため現在では、アドホックネットワークの基本的な機能に加えて、その高機能化、

実用化に向けた検討も行われている。このような研究例としては、以下のようなもの挙げられる。

• ある宛先に対して複数の経路を保持することによって通信の安定性を向上させるためのマルチパスルーチング技術[13]-[14]

• 通常のインターネットとの接続を実現するために、Mobile IPとアドホックルーチングプロトコルをインターワーキングさせる研究[15]

• IPアドレスや論理名の動的な割り当てを行うためのZeroConf [17]の検討

さらに、[19]-[23]のような実際の商品も販売され始めている。[21]ではルーチングプロト

コルのソフトウェアである[20]を組み込んだ小型携帯無線端末として、メッセージ送信、

ゲーム、携帯電話へのプラグイン・アダプタとしての機能を提供している。また、アドホックネットワークの性能評価を行うために、実際のアドホックシステムによるテストベッドを構築し性能評価実験を行っている検討もされている[24]-[28]。

(15)

1.2

^{本論文の研究}

筆者は研究の初期から、実環境での利用を想定したアドホックネットワークの研究に取り組んできており、以下の研究を行った。

第一の研究内容は、アドホックネットワークを実際に構築しその性能評価を行ったことである。前述にようにアドホックネットワークの適用例としては既存のインフラを使わない状況が考えられるが、このうちの災害時の消防支援ネットワークを想定した。すなわち、

大深度地下や地下鉄線路のような、通常の携帯電話の電波が受信できない場所では、消防活動を行う消防士との間で、何らかの通信路を確立することが望まれる。そこで802.11無線 LAN を用いた通信端末を導入し、消防士にもたせまた火災現場と消防基地の間に設置することにより、基地と消防士の間でマルチホップネットワークを行うことが考えられる。

第一の研究では、このようなネットワークを想定し、802.11 無線 LAN のアドホック・

モードとAODVルーチングを用いたアドホックネットワークを構築し、ノード間の距離やホップ数を変化させた場合の性能を評価した。具体的には、消防活動が困難な環境を想定して、地下街と建物の中を実験場所に選び、実験を行った。

実験では、信頼性を提供する TCPによるデータ通信を対象とした。無線LANアドホックネットワークでは無線リンク上でのフレームロスにより MAC レベルの再送が発生し、

さらにMACレベルのリトライアウトにより、TCPレベルの再送が発生し、これによりTCP のスループットを低下させる。また、無線リンク上でのフレームロスは物理レベルのRSS やSNRといった性能に大きく関係すると考えられる。このため、TCPレベル、MACレベル、物理レベルの性能パラメータをそれぞれ評価することを実験の特徴とした。

第二の研究内容としては、実際にアドホックネットワークが普及した時点を想定し、高密度なアドホックネットワークの構築に適したアドホックルーチングプロトコルの提案を行った。

例えば、新宿や渋谷といった繁華街でユーザのPDAに地域情報を配信するようなアプリケーションを想定する。この場合は、人が密集した状況で、無線伝播範囲が100メートル程度の通信を行うことになる。このような環境では、無線伝播範囲に多くのノードが存在するような高密度なアドホックネットワークを構築する必要があると考えられる。

このような高密度なアドホックネットワーク上で、現在検討されているアドホックルーチングプロトコルを用いた場合、経路を発見・維持するためのルーチング用の制御メッセージの送信オーバヘッドが大きくなるという問題が生ずる。例えば、上述の AODV では、

(16)

通信時に通信相手への経路を要求するRREQ (Route Request)メッセージを隣接ノードへブロードキャストし、それを受信したノードも同様に隣接ノードへ再ブロードキャストし、

宛先ノードもしくは宛先ノードへの経路を知っているノードがそれに応答する RREP (Route Reply)メッセージを発信元ノードへ送信することによって、宛先との間の経路を確立する方法を用いている。また、RREQメッセージを受信したノードによる、経路維持のための定期的な Hello メッセージの交換が必要とされている。このため、高密度なアドホックネットワークでは、これらの制御メッセージの送信オーバヘッドが大きくなる。

そこで本論文の第二の研究では、ノードの無線伝播範囲に多数のノードが存在するようなネットワークで、AODVを使用する場合に、あるノードと離れたノードにのみRREQメッセージを再ブロードキャストすることにより、ネットワークに広がるRREQメッセージの量を減少させるとともに、双方向の経路が確立された場合にのみ Hello メッセージの転送を制限する方式を提案する。

1.3

^{本論文の構成}

本論文の構成は以下の通りである。第 2 章では無線 LAN とアドホックルーチングの研究開発動向について述べる。また、後半でアドホックネットワークの実用に向けた研究動向についても触れる。第3章では実環境でのアドホックネットワークの利用を想定した際の課題点とその既存研究について述べ、本論文の研究内容へのアプローチと概要を述べる。

次に、第4章では無線LANとAODVルーチングプロトコルを用いたアドホックネットワークの性能評価実験について述べる。また、第5章では無線伝播範囲に多数のノードが存在するような高密度なアドホックネットワークに適した AODV ルーチングプロトコルの提案方式について述べる。また提案方式をソフトウェアシミュレータにより性能評価を行った結果についても示す。最後に、第6章では本論文の結論を述べる。

(17)

第 2 章無線 LAN とアドホックルーチングの研究開発動向

本章では、本論文を記述するために必要となる、無線 LAN 技術とアドホックルーチング技術の詳細と、その研究開発動向について示す。無線LAN技術については、IEEE 802.11 の動作を概説する。アドホックルーチング技術については、IETFのMANETワーキンググループでのこれまでの標準化動向と、AODVルーチング技術の詳細について示す。その後、

アドホックネットワークの実用化に向けた研究動向について述べる。

2.1

^無線LAN技術

無線LANは、LANの標準化組織であるIEEE802委員会の配下にある802.11と呼ばれるワーキンググループで標準化活動が行われている。802.11規格の対象となるプロトコルは、

主に以下の二つである。

・データリンク層（LLC レイヤと MAC レイヤで構成される）のうち、通信の分散制御や集中制御などを行うMACレイヤのプロトコル

・通信のデータ伝送速度や無線周波数帯域などに関する物理レイヤのプロトコル

802.11 の MACレイヤ技術としては、有線のイーサネットで使用されているアクセス制

御方式であるCSMA/CD (Carrier Sense Multiple Access with Collision Detection) を踏襲した CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance)と、オプション規定としてポーリング方式が採用されている。ここで、アクセス制御方式とは、無線ネットワーク環境において、無線端末がどのようなタイミングで通信相手にデータを送るかなどの制御を行う方式である。

アクセス制御の主な機能としては、

・ランダム・アクセスによる無線チャネル競合時の送信機会の平等化

・ランダム・アクセス時の隠れ端末対策：RTS/CTS (Request to Send / Clear to Send)制御

・ポーリングによる非競合アクセス

・パケット同士の衝突発生時や無線伝播誤り時の再送制御などがある。

(18)

2.1.1 IEEE802.11無線LANの構成ネットワーク

802.11無線LANのネットワーク構成にはアドホック・モードとインフラストラクチャ・

モードの 2 種類（図 2.1）がある。この節では、これらの各ネットワーク構成の説明をする。

2.1.1.1 アドホック・モードのネットワーク

アドホック・モードは図 2.1(a)に示すように基地局を必要とせず、端末のみによりネットワークが構成される。一般に端末は、パケットを中継する機能をもたず、直接無線伝播範囲にいる端末とパケットのやり取りが行われる。パケットを中継するマルチホップ通信を行うためには、IP レイヤ上でアドホックルーチングプロトコルを実装する必要がある。

アドホックルーチングプロトコルに関しては次節で述べる。

2.1.1.2 インフラストラクチャ・モードのネットワーク

インフラストラクチャ・モードのネットワークは図 2.1(b)に示すように基地局と、その電波伝搬範囲内に存在する端末で構成される。各端末は802.11のマネージメント機能を利用して、特定の 1 つの基地局と論理的な接続関係（Association）を確立する。一般的に、

バックボーン・ネットワーク

STA1 STA2

STA1

STA2 STA3

AP : Access Point、基地局 STA : Station、無線子機

(b) インフラストラクチャ・モード (a) アドホック・モード

AP

図 2.1: IEEE802.11 無線LANの構成ネットワーク

(19)

基地局はイーサネットなどのバックボーン・ネットワークに接続されており、端末とバックボーン・ネットワークとのパケット中継を行う。また、基地局配下の端末間が通信する際のパケット中継も行う。

2.1.2 MACフレーム

802.11無線LANでは、MACレイヤにおいて、無線デバイス間でやり取りされる無線パ

ケットのフレーム・フォーマットを定義する。付録A.1にIEEE 802.11無線LANのMAC フレームの基本フォーマットを示す。

MAC フレームはマネジメントフレーム、コントロールフレーム、データフレームの 3 つに分類されている。

2.1.2.1 マネジメントフレーム

端末、基地局同士でネットワークを構成するときに必要となる情報をやりとりするフレームである。無線セルの存在を放置するための Beacon フレーム、認証のための De /

Authenticationフレーム、基地局と端末間での関連付けを行うためのRe / Dis / Association

request / responseフレーム、端末が無線セルを発見するために用いられるProbe requestフレ

ームやそれに対応する基地局からの Probe responseフレーム、アドホック・モードにおいてパワーセーブ中の端末と通信する際に用いられるATIMフレームなどがある。

2.1.2.2 コントロールフレーム

通信を行う際に、通信の制御などに用いられるフレームである。IEEE802.11 系の MAC レイヤではMACレベルで応答確認を行っており、そのためのACKフレームや、隠れ端末問題を解消するための仮想キャリアセンスのための RTS/CTS フレームなどが規定されている。

2.1.2.3 データフレーム

上位層からのユーザーデータを送信するために用いられる。

2.1.3 MAC方式

802.11無線LANでは、同一の無線チャネルを複数端末で共有するためにMAC機能が実

装されている。IEEE802.11 では、前述のように CSMA/CA が採用されている。CSMA/CA

(20)

では各無線端末（基地局）がフレームの送信を試みるとき、チャネルがビジーかどうか検査（キャリアセンス）し、ビジーでないならデータフレームを送信し、チャネルがビジーの間は、アイドル状態になるまで待ち、その後さらにランダム時間待ってデータフレームを送信する方式を用いる。IEEE802.11ではCSMA/CAを基本とする必須のDCF (Distributed Coordination Function、自律分散制御方式)と、オプションのPCF (Point Coordination Function、集中制御方式)の二つが規定されている。

以下にアドホック・モードにおけるCSMA/CAを用いたDCFの通信手順例を示す。図 2.2 では、STA2、STA3、STA4 から STA1 へのデータ送信手順を示している。STA2、STA3、

STA4はDIFS (DCF Interframe Space)と呼ばれる時間信号が検出されなかった場合に、チャ

ネルがアイドル状態に変わったと判断する。次に、各STAは衝突回避手順であるバックオフ制御を実行し、バックオフ時間と呼ばれる更なる送信待機時間をランダムに決定する。

各 STA はバックオフ時間のあいだチャネルがアイドル状態であった場合にデータフレームを送信する。

図では、STA2 のバックオフ時間が 1 番短かったために、キャリアセンス後にデータフ

Ack

Data

Data Data

STA1

STA2

STA3

STA4

Ack 衝突

Data 再送

Ack

Data ･･････

バックオフ

持ち越されるバックオフ待機

待機待機

DIFS SIFS DIFS DIFS SIFS DIFS

DIFS : DCF Interframe Space SIFS : Short Interframe Space SIFS

図 2.2: DCFにおける通信手順例

(21)

レームを送信している。その後、STA1 ではデータフレーム受信完了後、SIFS (Short

Interframe Space)時間あけてSTA2へACKフレームを送信している。

次に、STA3とSTA4はDIFS時間後、残りの持ち越されたバックオフ時間のバックオフ制御を行う。ここで、バックオフに用いられる乱数値が同じであれば、STA3とSTA4のようにデータフレームを同時に送信し、衝突が発生する。衝突後はSTA1からACKフレームを受信できず、STA3とSTA4は再送手順を行う。

再送手順では、STA3とSTA4において、バックオフ時間を再計算しセットしなおす。ここでは、STA3の方がSTA4よりもバックオフ時間が短いために、キャリアセンス後STA3 がデータフレームを送信し、その後ACKフレームを受信している。

また、このとき STAと STA1 の間の電波環境が悪化した場合は、STA4から送信したデータフレームが STA1 で受信することができなくなる。そのため、STA1 は STA4 へ ACK フレームを送信しない。このような状況では、STA4はSTA1からACKフレームを受信するまでデータフレームを再送し続ける。そして、その再送回数が一定数に達すると MAC レイヤで再送することを諦め、次のデータフレームの送信を試みる。この手順をリトライアウトと呼ぶ。リトライアウト回数については無線 LAN カードのドライバの実装によって異なる。

2.2

アドホックルーチング技術

2.2.1 アドホックルーチングの研究動向

IETFのMANETワーキンググループによって、無線ノード間のマルチホップ通信を実現

するためのアドホックルーチングプロトコルの標準化活動が行われている。これまでに様々なプロトコルを検討されており、AODV や DSR に代表されるオンデマンド型のルーチングプロトコルや、OLSRやTBRPFのようなリンクステート型のルーチングプロトコル、

オンデマンド型とリンクステート型を組み合わせたハイブリッド型ルーチングプロトコルがあげられる。

2.2.1.1 オンデマンド型ルーチング

通信を開始する際に初めて、通信相手に対する経路情報を検索する手法である。オンデマンド型ルーチングの場合、通信が開始されない間は経路情報の探索を行わないため、定期的な経路情報の交換が少ないといったメリットがある一方で、通信要求から通信の開始までに時間が必要であるといった特徴が上げられる。

(22)

オンデマンド型ルーチングのひとつのDSRでは、通信を要求するノードは経路を確立す

るためにRoute Requestメッセージをブロードキャストする。Route Requestメッセージを

受信したノードは、自身のIPアドレスをRoute Requestメッセージに入れて再ブロードキャストする。このとき既にRoute Requestメッセージに自身のIPアドレスが含まれている場合はそのRoute Requestメッセージを破棄する処理を行う。この再ブロードキャストによって宛先ノードまで到達したRoute RequestメッセージはRoute Replyメッセージによって応答される。Route ReplyメッセージはRoute Requestメッセージに入っている転送情報

をもとにRoute Requestメッセージの発信元ノードまで転送される。Route Replyメッセー

ジを受信したノードはそのメッセージ内に発信元ノードと宛先ノードまでの経路情報が含まれているので、その経路情報を各ノードで保持し、発信元ノードまで転送することによって、発信元ノードから宛先ノードまでの経路を確立することが可能となる。

AODVでは経路を確立するためにRoute Requestメッセージをブロードキャストし、それに対応するノードがRoute Replyメッセージを送信する処理はDSRと同じである。ただし、

Route Requestメッセージ内にそのメッセージの転送情報を記さないという特徴がある。そ

の代わりにRoute Requestメッセージを受信したノードはそのRoute Requestメッセージの発信元ノードに対するリバースルート情報を記録する。さらに、Route Replyメッセージを受信したノードはその Route Reply メッセージを送信したノード、つまり宛先ノードに対するフォワードパスルート情報を記録する。これらの経路情報によって全てのメッセージが転送される。

2.2.1.2 リンクステート型ルーチング

定期的に隣接情報を交換しておき、あらかじめ全てのノード間で経路を確立しておく手法である。あらかじめ全ノード間で経路情報を確立しておくため、通信要求からすぐにデータを送信することが可能である一方で、定期的に交換する経路制御メッセージが大きくなる、各ノードが保持する経路情報が莫大となってしまうというデメリットがあげられる。

OLSR はモバイルアドホックネットワークにおいて、ネットワークのトポロジー情報をノード間で定期的に交換するルーチングプロトコルである。このため、必要となった時点ですぐに経路が利用できるという利点を持っている。またこのプロトコルは、大規模でノード数の多い（密な）モバイルネットワークに適用するために、通常のリンクステートプロトコルに比較すると、最適化を行っている。具体的には、MPR (MultipointRelay)と呼ばれるノードを選択して、制御メッセージはその MPR 間のみで交換するとともに、データパケットの中継を行うこととしている。このため、制御メッセージのフラッディングやブロードキャストの数を減らすことができる。

(23)

FSRプロトコルは、大規模なネットワークにおける経路情報の更新のオーバヘッドを低下するための、複数のレベルのスコープの概念を導入している。ノードは、ネットワーク中の各宛先に対するリンクステート情報を有し、宛先のリンクステート更新を、定期的に隣接ノードにブロードキャストする。ただし、その頻度は宛先へのホップ数に依存する。

遠隔にある宛先に関連するステート更新は、近い宛先に対するものよりも、低い頻度で送信される。これにより、リンクステートメッセージの大きさを小さくすることができる。

このステート更新により、ノードはネットワークのトポロジマップを作成し、効率のよい経路を計算する。この結果、パケットが転送される経路は、その宛先に近づくにつれてより正確なものになる。さらに FSR では、トポロジメッセージを隣接ノードのみにブロードキャストすることにより、フラッディングのオーバヘッドを減らす工夫もなされている。

LANMAR は、大規模なネットワークにおける経路情報の更新のオーバヘッドを低下す

るためのプロトコルである。LANMAR におけるランドマークの概念は、メンバが共通の興味を持ち、グループとして移動するような論理的サブネット（戦場における旅団、会議場における同じ企業からの参加者など）の考え方を採用している。論理的サブネットに属するノードは、1 つのードを「ランドマーク」として動作させる。ランドマークはそのサブネットのノードに関する情報を保持する。このために各論理的サブネット内では、スコープのあるルーチングプロトコルを用いる。この例としてはFSRがあり、ここでは経路情報の更新メッセージはサブネット内に限定して転送される。遠方のノード（スコープの外のノード）に対する経路情報は対応するランドマークに代表させる。その結果、ルーチングテーブルは、対応するスコープ内のノードとランドマークノードに関する情報のみを含むことになり、ルーチングテーブルのサイズと更新トラヒックのオーバヘッドを大幅に低減できる。

2.2.1.3 ハイブリッド型ルーチング

上記のオンデマンド型ルーチングとリンクステート型ルーチングの混合タイプのルーチング方式である。ハイブリッド型ルーチングとしてはZRPがあげられる。このプロトコルでは特定のホップ数以内のノードに対しては、intra-zone routing というリンクステート型ルーチングを用い、それより離れたノードに対してはinter-zone routingオンデマンド型ルーチングを用いて経路を確立する。オンデマンド型、リンクステート型ルーチングの両方の良い点を取り入れる手法だが、intra-zone routingとinter-zone routingを使い分ける境界線に関しては、使用するネットワークによって適切に変更する必要がある点、設計が複雑になる点などがデメリットとして考えられる。

(24)

2.2.1.4 アドホックルーチングの標準化の流れ

IETFにおけるアドホックルーチングプロトコルの標準化の流れを図 2.3に示す。複数検討されていたプロトコルの内いくつかは検討が終了し、残ったプロトコルがRFCとして標準化されている。AODVが2003年にRFC3561として、OLSRが 2003 年にRFC3626 とし

て、TBRPF が 2004年に RFC3684 として標準化された。さらに、MANETでは AODVと

DSR の機能を組み合わせたルーチング手法として DYMO といったルーチングがドラフトとして検討されている。さらに、OLSRの次バージョンも検討されている。

IETFにおけるアドホックルーチングプロトコルの標準化は、オンデマンド型のプロトコルが1つ、リンクステート型のプロトコルが1つにそれぞれ絞られてきたと考えられる。

2.3

AODVルーチング 2.3.1 概要

AODVルーチングプロトコルは、アドホックネットワークにおいて、通信を行うことを希望するノードの間で、ダイナミック、端末起動型、かつマルチホップのルーチングを実現する。AODVは、無線ノードが新たな宛先に対して経路をすばやく確立することを可能とする。この結果AODVは、ダイナミックなリンク状態の変化にすばやく対応でき、処理

ZRP ルーチング

AODV DSR

FSR OLSR

LANMAR

TBRPF オンデマンド

型

リンクステート型

ハイブリッド型

RFC3561 未だドラフト

ドラフトでDYMO として検討中 RFC3626

RFC3684

ドラフトでver.2 が検討中

2002年 2007年現在

図 2.3: IETFにおけるアドホックルーチングの標準化動向

(25)

能力・メモリに対して低いオーバヘッドを実現し、ネットワークの帯域に対するオーバヘッドも低いという特徴を持つ。

AODVでは経路情報を要求するためにRoute Request (RREQ)メッセージを、経路情報を返すためにRoute Reply (RREP)メッセージを、リンクが破損した場合のリンク修復にRoute

Error (RERR)メッセージをそれぞれ使用する。これらのメッセージはUDPを用いて転送さ

れ、普通のIPヘッダが使われる。AODVでは新しい宛先への経路情報が必要となると、ノードはRREQメッセージをブロードキャストする。RREQメッセージの宛先ノード自身か、

宛先への経路情報を持つノードに到達すると、RREP メッセージが、RREQ を発信したノードに対して、ユニキャストで転送される。RREQ のブロードキャストにおいて、発信元ノードへの逆向きの経路情報が設定され、RREP のユニキャストにおいて、宛先ノードへの経路が設定される。ノードは確立した経路が壊れているとわかると、RERR メッセージを使って、他のノードにリンクが壊れていることを知らせる。

2.3.2 メッセージフォーマット

AODVで使われるメッセージフォーマットとその内容を付録Bに示す。

2.3.3 Route Requestの生成

ノードは、ある宛先ノードに対する経路情報が必要で、かつ自分自身のルーチングテーブルに宛先ノードに対する有効な経路がない場合に、RREQ メッセージをブロードキャス

トする。RREQのDestination Sequence Numberフィールドには、ルーチングテーブルのこ

の宛先ノードに対応するシーケンス番号からコピーされ、Originator Sequence Numberフィールドには、そのノード自身のシーケンス番号が入る。また、RREQ IDには、ノードにおいて同じ宛先に対して使用したRREQ IDを1増加させた値が入る。これにより、隣接ノードがまた発信元ノードへRREQを戻してきたときに、再処理や再転送といったことを回避することができる。ホップカウントは0にセットされる。

RREQをブロードキャストした後、ノードは RREP を待つ。RREP がある一定時間到着しない場合は、ノードはRREQを再ブロードキャストしてもよい。再送されるRREQでは

RREQ IDが1増加される。経路情報を待っているデータパケットは発信元ノードでバッフ

ァリングされる。

RREQが不必要にネットワークに広がるのを防ぐために、AODVではエクスパンディングリングサーチと呼ばれる手法が取り入れられている。発信元ノードは最初にRREQをブロードキャストするときに、そのRREQの IPヘッダの TTLを TTL_STARTと呼ばれる定

(26)

数にセットする。その後発信元ノードはRREPを受信できない場合にTTLを一定数だけ増加して再ブロードキャストを行う。RREPが受信できない間は、この作業をTTLが一定値になるまで繰り返され、その一定値を超えるとネットワーク全体に広がるように大きな値にTTLの値をセットして転送する。

RREQをある一定数再送してもRREPを受信しない場合には、データは破棄されて、ICMP

のDestination Unreachableメッセージがアプリケーションに通知される。

2.3.4 Route Requestの再ブロードキャスト

ノードがブロードキャストされたRREQを受信した場合は、ある一定時間以内に、同じ発信元IPアドレスとRREQ IDを持つRREQを受信していないかをチェックする。受信されている場合は新たに受信したRREQを破棄する。破棄されない場合の処理は以下のようになる。RREQを受信すると、ノードは宛先に対するアクティブな経路を持っているかを調べる。持っていない場合は、以下のようにしてRREQの再ブロードキャストをする。

・ IPヘッダのソースIPアドレスを自分自身のIPアドレスに設定する。

・ RREQ の宛先シーケンス番号を、現在のパケット中の番号と、そのノードが保持するルーチングテーブル中の宛先シーケンス番号の大きいほうに設定する。

・ RREQ中のホップカウントを1増やす。

一方、ノードがアクティブな経路を持っている場合は、そのエントリの宛先シーケンス番号とRREQ中の宛先シーケンス番号とを比較する。パケット中のシーケンス番号の方が大きい場合は、ノードはアクティブな経路を持っていない場合と同様に、RREQ を再ブロードキャストする。ノードは以下の条件のうち一方が成立する場合にRREPを生成する。

・そのノード自身が宛先である。

・ノードが宛先へのアクティブな経路を有し、その宛先シーケンス番号が RREQ のシーケンス番号以上である。しかもD Flagがセットされていない場合。

ノードは常に、ルーチングテーブルの発信元IPアドレスへの逆向きの経路に対するエントリを生成または更新する。発信元IPアドレスへの経路が存在する場合は、以下のいずれかの場合にのみ更新される。

・ RREQのソースシーケンス番号が、ノードがもつルーチングテーブルの発信元IPアドレスに対応するエントリの宛先シーケンス番号よりも大きい

・シーケンス番号が等しいが、RREQ 中のホップカウントがルーチングテーブル中のものよりも小さい。

逆向きの経路のエントリが作成または更新される場合は以下のアクションが実行される。

・ RREQ の発信元シーケンス番号、エントリの宛先シーケンス番号のフィールドにコピ

(27)

ーされる。

・ルーチングテーブルのネクストホップは、RREQ をブロードキャストしたノードとなる。IPアドレスはRREQヘッダの発信元IPアドレスとなる。

・ RREQのホップカウントが、ルーチングテーブルにコピーされる。

2.3.5 Route Replyの生成

ノードがRREQを受信したとき、そのノードが宛先ノードに対する有効な経路情報を持つ中間ノードか、もしくは宛先ノード自信である場合に、そのノードはRREPを生成し、

RREQの発信元IPアドレスで指定されたノードに対してユニキャストで転送される。送信の際は、RREQの発信元 IPアドレスと宛先IPアドレスをRREPの対応する値にコピーする。それ以外の動作は、ノードが宛先自信であるか、宛先への有効な経路情報を持つ中間ノードかによって異なる。

・宛先ノードによるRREPの生成

RREP を生成するノードが宛先自信であるなら、RREQ の中のシーケンス番号と自分が保持している発信元IPアドレスに対するシーケンス番号を比較し、大きい方の値を自分が保持するシーケンス番号として更新し、その値をRREPのDestination Sequence Numberフィールドにコピーする。RREPのHop Countフィールドには0をセットして転送する。

・中間ノードによるRREPの生成

RREP を生成するノードが宛先への経路情報を持っている中間ノードの場合は、その中間ノードは宛先ノードの代わりになり、自分の保持している発信元IPアドレスに対するシーケンス番号をRREPのDestination Sequence Numberフィールドにコピーする。RREPに指

定するHop Countフィールドには、自分の保持している宛先ノードに対するホップカウン

トをセットする。

2.3.6 Gratuitous Route Replyの生成

ノードがRREQを受信してRREPで応答した場合は、それ以上RREQをフォワードしない。従って、中間ノードがRREPを応答した場合、宛先ノードは発信元ノードへの経路情報を知ることができない。そこで、宛先ノードが発信元ノードへの経路情報を知るためには、発信元ノードはRREQのG Flag (gratuitous Flag)をセットする必要がある。G FlagがセットされているRREQに対して中間ノードがRREPを返す場合には、中間ノードは同時に宛先ノードに対してもGratuitous RREPをユニキャストしなければならない。

Gratuitous RREPには以下のような情報を含む

(28)

・ Hop Count : 中間ノードが保持する、発信元ノードに対するホップカウント

・ Destination IP Address : RREQを作った発信元ノードのIPアドレス

・ Destination Sequence Number : RREQを作った発信元ノードのシーケンス番号

・ Originator IP Address : RREQの宛先ノードのIPアドレス

・ Lifetime : RREQの発信元ノードへの経路の残りLifetime

Gratuitous RREPは宛先ノードへのパスに沿って転送される。それはまさに宛先ノードは

既に発信元ノードにRREQを送っていて、このRREPはそのRREQへの応答であるかのごとく送られる。

2.3.7 Route Replyの転送

ノードがRREPを受信すると、まずRREP中のDestination Sequence Numberフィールドと自分が保持する宛先IPアドレスに対するシーケンス番号とを比較する。この宛先ノードへの経路に対するエントリは、以下のいずれかが成立する場合に、生成または更新される。

・ルーチングテーブルの中のシーケンス番号が無効な場合

・ RREPの中のDestination Sequence Numberフィールドが自分の保持する宛先IPアドレ

スに対するシーケンス番号よりも大きくて、かつそのシーケンス番号が有効な場合

・両者のシーケンス番号が同じで、ノードが保持する経路情報がアクティブでない、ま

たは RREP中の Hop Countがルーチングテーブルのエントリのホップカウントより小

さい場合

現在のノードがRREPのOriginator IP Addressフィールドで示されるノードではなく、かつ、宛先ノードへの経路のエントリが生成または変更された場合は、ノード発信元ノードに対するエントリを調べ、RREP をフォワードする。もし破損しているリンク、もしくは片方向のリンクを使ってRREPを送る場合はA Flagがセットされる。発信元ノードがA Flag のセットされたRREPを受信したときに、RREP-ACKを送り返すことでRREPの受信が確認できるようになる。また、RREPの転送時にRREPメッセージのHop Countフィールドを1増加する。

2.3.8 Helloの交換

ノードは隣接ノードに対して Hello メッセージをブロードキャストすることによって、

隣接ノードと接続しているかどうかの情報を提供することができる。一定時間毎に、ノードはブロードキャストされたかどうかチェックする。例えば、RREQやレイヤ2メッセージなど。もし送信されていなかったら、ノードはHelloと言われるTTL=1のRREPをブロ

(29)

ードキャストする。このRREPメッセージフィールドには以下の内容がセットされる。

・ Destination IP Address : Helloの送信ノードのIPアドレス

・ Destination Sequence Number : Helloの送信ノードのシーケンス番号

・ Hop Count : 0

・ Life time : 一定値

ノードは隣接ノードからパケットを受信することによって接続しているかどうかを確かめることができる。もし隣接ノードから Hello を受け取って、その後一定時間以上なんらかのメッセージを受け取らなかったら、端末はこの隣接ノードへのリンクが切断していると判断する。また、ノードがいかなる制御パケットを受け取った時でも、それは明示的に

Helloの受信と同じような意味を持つ。このときは制御メッセージパケットのIPヘッダの

発信元IPアドレスによって示されている端末への接続の確立を意味している。

2.3.9 RERRの生成と転送

RERR メッセージは複数の宛先に対して送る場合にはブロードキャストで、ひとつの宛先に対して送る場合にはユニキャストで、複数の宛先にブロードキャストを送る場合は複数の宛先に対して反復してユニキャストで転送される。RERR メッセージが送信される条件は以下の3通りのいずれかである。

・データの転送中に、その宛先に対するネクストホップへのリンクが破損していることを検知した場合。

・あるノードに対する有効な経路を持っていなくて、しかも修正されていないノード宛のデータパケットを受信した場合

・隣接ノードから一つもしくはそれ以上の有効な経路のためのRERRを受信した場合ノードはルーチングテーブル中のある経路に関するリンクの破損を検知すると、その破損したリンクによって影響を受ける宛先を調べ、その宛先を RERR の Unreachable

Destination IP AddressにセットしRERRメッセージを送信する。RERRを受け取る必要のあ

る隣接ノードがただ一つだけ存在する場合、RERR はその宛先へユニキャストされる。そうでない場合、RERRのUnreachable Destination IP Addressフィールドに到達不可な宛先をセットし、ブロードキャストアドレスへ送信される。

2.4

アドホックネットワークの実用に向けた研究動向

現在では、アドホックネットワークの実用化・高機能化に向けた研究が活発に行われて

(30)

おり、さらにはアドホックルーチング技術を用いた市販製品も発売され始めている。研究例及び製品例を以下に述べる。

2.4.1 マルチパスルーチング

これまでに IETF で検討されてきたアドホックルーチングプロトコルでは、ノードの移動や消滅によるリンクの切断が発生した際に、リンクの切断を検知したノードがその旨を通知し、再び経路を確立するまでの間データパケットが転送できなくなってしまう問題点があった。そこで、[13]、[14]ではアドホックネットワーク上で複数の経路を確立するマルチパスリーチングに関する研究が行われている。リンクの切断などが発生した際に、あらかじめ用意しておいた別経路を通信用に用いることによって通信の安定性を向上させる技術である。[13]では、AODV を基に発信元ノードと宛先ノードの間で複数の経路を確立する手法を提案している。RREQメッセージに”Last Hop”フィールドを追加し、これまでに受信したことのあるRREQ IDのRREQを受信した場合でも、”Last Hop”フィールドに記されているアドレスが異なる場合は、そのRREQを再ブロードキャストするという特徴により複数パスを確立している。また、[14]では OLSR を改良したマルチパスルーチングに関する検討が行われている。

2.4.2 インターネットとの接続

上述したような研究は、アドホックネットワーク内にいる無線ノード同士の通信を想定しており、インターネットへの接続を考慮しているものではない。しかし、今後アドホックネットワークが普及することにより、無線ノードがアドホックネットワークに参加し、

尚且つインターネットへ接続するような仕組みを検討する必要がある。このような研究も幾つか行われている。アドホックネットワーク内にいる無線ノードは通常のインターネットとは異なるアドレス体系を持つため、それらを相互接続させるためのいくつかの課題が挙げられる。

2.4.2.1 インターネットとのゲートウェイの探索及びルーチング方法

アドホックネットワーク上にいる無線ノードは、インターネットへ接続するためのゲートウェイの情報を取得し、インターネットへ接続する必要がある。また、インターネット上にあるノードからアドホックネットワーク上にいる無線ノードへゲートウェイを通じて通信できる必要もある。これらの要件を解決するために Mobile IPを用いる手法が検討されている[15]。[15]では、AODVとMobile IPを組み合わせ、Mobile IPのFA (Foreign Agent)

(31)

をアドホックネットワークとインターネットとのゲートウェイとして機能させる方法である。無線ノードがアドホックネットワークに参加した時点で、FAを探索するためのRREQ メッセージをブロードキャストし、それに応答するメッセージで FA と無線ノードの間で経路が確立し、レジストレーションを行う。これによって、無線ノードとFAの間ではAODV に従った IP 転送を行い、FA と HA (Home Agent)またはインターネット上のノードとは

Mobile IPを用いたIP転送が行われる。

また[16]では、IPv6 を対象としたインターネット接続に関する様々な手法が検討されており、ゲートウェイの発見、ルーチング方法だけでなく、下で述べるグローバルアドレスの取得方法についても規定されている。

2.4.2.2 IPアドレスの割り当て方法

IPv4ネットワークにおいて、DHCP (Dynamic Host Configuration Protocol)サーバが存在する場合には自動で一意なIPアドレスを取得することが可能であるが、アドホックネットワークのようにDHCPサーバを設置することが難しいネットワークにおいては、IPアドレスを取得することができない。そこで、自動的に一意なIPアドレスを割り当てる方法が必要となってくる。現在IETFのZeroConf (Zero Configuration Networking)[17]と呼ばれるワーキンググループでは、TCP/IPをベースとしたLAN内に接続されたクライアントPCや周辺機器、あるいはそれらの上で稼動している種々のアプリケーション等といった一連のノードを設定不要にてネットワークに参加させることを目的としている。ZeroConf による IP アドレスの割り当て方法は、Auto-IP 技術により「192.254.0.0/16」のアドレス空間から未使用の IPアドレスを探索し、そこから任意のIPアドレスを自分のアドレスとして割り当てる方法が検討されている。

IPv6ネットワーク環境においては、アドホックネットワーク内の無線ノードはインターネットとのゲートウェイの情報をなんらかの方法により取得したときに、その情報の中からネットワークプレフィックスアドレスと自身の MAC アドレスを用いて自動生成する [18]。

2.4.3 製品化

市販製品としては、アドホックルーチングプロトコルのソフトウェアだけでなく、アドホック技術の組み込まれた小型携帯無線端末も発売されている。

(32)

2.4.3.1 スカイリー・ネットワークス

DECENTRAとよぶマルチホップ型の通信ネットワーク製品を開発している[19]-[21]。PC

や PDAを端末兼ルータとして利用可能。2002年9月にはレスキューナウ・ドット・ネットと会社が、練馬区・東京都合同総合防災訓練に本システムを用いた実験を行った。そこでは、ノート PCや PDA を用いた一時的ネットワークを構築し、（株）衛星ネットワークの通信衛星を用いてインターネットへの接続を行っている。採用しているアドホックルーチングプロトコルなどの詳細仕様は公開されていない。

2.4.3.2 Greenpacket

米国の会社で、携帯無線端末同士がマルチホップのネットワークを構築するためのソフ

トウェアSONBuddyを開発している[22]。安全な通信を特徴としており、IPSecを用いた暗

号通信を行うことを特徴としている。またインターネットとの相互接続の機構も実現している。同社はMobile IPのソフトウェアSONAccessも開発している。日本の取り扱いは東洋通信機が行っている。プロトコルなどの詳細については公開されていない。

2.4.3.3 Meshnetworks

同じく米国の会社で、アドホックのピアツーピアのルーチングを用いた通信システムを開発している[23]。特徴は無線LANインタフェースに加えて、QDMAという独自の無線通信方式を開発していることと、電波伝播時間測定と三角測量によるGPSによらない位置決め機能を提供していることである。詳細の手順等は公開されていない。

近年では、上で述べたように実用化・高機能化に向けた研究が行われており、アドホックネットワークを実環境に適合させるための研究に対する必要性が高まっている。

電気通信大学大学院情報システム学研究科 博士（工学）の学位申請論文

実環境を考慮した無線 LAN と AODV ルーチングを用いた アドホックネットワークに関する研究

沖 野 正 宗