大規模アドホックネットワークにおける 階層的な名前解決法 理工学部情報学科　後藤研究室 1G02P050-7 鈴木　幹也

アドホックネットワーク 無線端末同士で即席のネットワークを構築できる インフラストラクチャに依存しない 災害時などでの利用が期待される インターネットの技術が不十分な場面もある アドホックネットワークとは、無線端末同士で即席のネットワークを構築できる技術で、 その際に無線の基地局やアクセスポイントといったインフラストラクチャを必要としません。 そのため災害時など、インフラストラクチャが使用不可能になってしまった場面などでの利用が期待されています。 しかし、インフラストラクチャに依存しなくても平気なため、現在インターネットで使われている技術だけでは不十分な場面も出てきます。

名前解決 IPアドレスを覚えやすい文字列に対応させる アドホックネットワークでは固定された端末の存在が保証されない インターネットではDNS アドホック特有の名前解決が必要 そのひとつに名前解決があります。 現在のインターネットではDNSが利用されています。 DNSはネットワーク上に複数の固定された端末が存在することが前提となっており、 それらの端末が他の端末のIPアドレスと名前の対応を管理します。 しかし、これは固定された端末の存在が保証されないアドホックネットワークでは不十分です。 そこでアドホックネットワークには特有の名前解決が必要になります。 そこで、本論文ではアドホック向けの名前解決方を提案します。

ルーティングプロトコル（１） 提案方式の前に、アドホックにおけるルーティングプロトコルについて説明します。 アドホックネットワークでは特有のルーティングプロトコルが必要になってきます。 アドホックネットワークのルーティングプロトコルは、大きく分けるとプロアクティブ型、リアクティブ型、ハイブリッド型の3つに分けられ、～のようなプロトコルがそれぞれあります。 これらは状況によっていろいろ使い分けられます。

ルーティングプロトコル（２） 特徴 通信を開始する際に遅延が発生しない。 プロアクティブ型 制御メッセージが常に流れる。 リアクティブ型 通信を開始する際に遅延が発生する。 制御メッセージが流れない。 ハイブリッド型 複合プロトコル。 性能は十分には明らかにされていない。 プロトコルの各タイプの特徴はこのようになってます。 プロアクティブ型は通信を開始する際に遅延が発生しません。しかし、制御メッセージが常に流れてしまいます。 それに対し、リアクティブ型は通信を開始する際に遅延が発生してしまいますが、制御メッセージが流れません。 ハイブリッド型はこの二つのタイプの長所を複合したプロトコルなのですが、その性能はまだ十分には明らかにされていません。

提案方式（１） 階層的 名前を集約する端末をSNC (Sub　Name Cordinator)、NC (Name Cordinator)として選出する SNC・・・周囲の端末の名前とIPアドレスの対応を管理する NC・・・SNCの端末の名前とIPアドレスの対応を管理する 次に、本研究で提案する名前解決の方式について説明します。 提案方式は、大規模なネットワークでも効率よく名前解決が行えるように階層的な仕組みになっています。 この提案方式ではまず、名前を集約する端末をSNC、NCとしてネットワーク中から選出します。 SNC、NCはそれぞれ周囲の端末の名前とIPアドレスの対応を管理する、SNCの端末の名前とIPアドレスの対応を管理する。 という役割を果たします。

提案方式（２） 名前の登録 （１）SNC、NCは定期的に名前とIPアドレスをフラッディング 次に名前の登録です。 まずSNC、NCはネットワーク中に自分の名前とIPアドレスを定期的にフラッディングし、その存在を知らせます。 これを受け取った各端末は自身の名前にSNCの名前をドットと共に付加して、それをSNCに登録します。 また、SNCはNCに自分の名前を登録します。

提案方式（３） たとえばこのようなネットワークがあったとき、sunをNC、~をSNCとしたとき、これらの端末は自分がSNC、またはNCであることをネットワーク上にフラッディングします。 SNCである～はその名前をNCであるSUNに登録します。 また他の端末はそれぞれのSNCへ自分の名前を登録します。 たとえばcommetという端末ならばSNCのearthにcommet.earthとして名前を登録することになります。

提案方式（４） 今の図を階層的にあらわすとこのような形になります。 この図をもとにneptuneがcommet.earthの名前解決を行う流れを説明します。 まず、neptuneは自身のSNCであるvenusにcommet.earthのIPアドレスを問い合わせます。 VenusはそのIPアドレスを知っていればそれをneptuneに返します。 しかし、知らなかった場合は名前からearthに聞けばわかると推測し、earthのアドレスをneptuneに返します。 このとき、venusがearthのアドレスを知らなければNCであるSUNに聞きに行きます。 このように、問い合わせが一回で終了する場合と、2回で終了する場合と三回で終了する場合の３つの場合に分けて名前解決がおこなわれます。

性能評価 NS２というシミュレーターを用いて測定 名前解決にかかる時間（応答時間）を測定 測定1・・・１回の問い合わせにかかる時間 　（１）→（２） 測定2・・・2回の問い合わせにかかる時間 　　　　　　　（１）→（２）→（３）→（４） 測定3・・・3回の問い合わせにかかる時間 （１）→（２）´→（３）´→（２）→（３）→（４） ネットワーク中を流れるパケット量の測定 次に提案方式の性能をNS2というシミュレータを用いて評価します。 今回は1000ｍ×1000mの範囲に100個の端末が存在するネットワークを想定し、 一回の問い合わせにかかる時間を測定一、二回の～、三回の～測定さんとし、それぞれ名前解決にかかる時間を測定します。 また、ネットワーク中に流れるパケットの量も測定しました。 この測定を今回の提案方式であるOLSRを用いた場合とリアクティブ型のプロトコルであるAODVを用いた場合とで行い、比較しました。

測定結果（応答時間の比較） 測定項目 OLSR(msec) AODV(msec) 測定1 22.00 105.93 測定2 41.18 　　測定項目 　OLSR(msec) AODV(msec) 測定1 22.00 105.93 測定2 41.18 190.83 測定3 71.73 254.74 まず応答時間の結果はこのようになりました。 プロアクティブ型のOLSRのほうがだいぶ早いことがわかります。 問い合わせが三回になってしまっても十分短い時間で行えることがわかります。

測定結果（パケット量の比較） 流れたパケット(byte) OLSR 1466978 AODV 11659 次にネットワーク中を流れたパケットの量の比較ですが OLSRでは約１．４メガ、AODVでは約11ｋバイトのパケットが流れていました。 やはり、制御メッセージが多く流れてしまうためOLSRを用いた場合は大量のパケットが流れていることがわかりました。

結論 大規模なアドホックネットワークでも十分短い時間で名前解決を行える 名前から次に問い合わせるべきSNCがわかるため効率が良い ベースになるプロトコルによって性能が異なる

今後の課題 周囲の環境が無線に及ぼす影響 既存のDNSとの共存 SNC、NC選出のための明確なアルゴリズム 端末が他のＳＮＣのゾーンに移ってしまった場合の処理

付録１(OLSRのWillingness) 定数名 値 WILL_NEVER WILL_LOW 1 WILL_DEFAULT 3 WILL_HIGH 5 WILL_ALWAYS 7

付録2（DNSとの共存）

付録３（DNS）

付録（フラッディング）

付録（フラッディング　MPR）