卒業研究A

「NS-2による無線ネットワークのシミュレート」

02kc093 中村洸喜

1　概要

本実験はネットワークシミュレータns-2とnamを用いて無線ネットワークの特性をシミュレートしてデータと視覚の両面から観察した。

2　原理

実験を行うにあたって今回用いるプロトコルおよびNSのいくつかの機能について述べていく。

2-1　ns-2について

NSとは，カリフォルニア大学バークレイ校で開発されたネットワークシミュレータのことで、NS-2はバージョン2をあらわす。

NSのソース，マニュアル，英語のチュートリアルなどはhttp://www.isi.edu/nsnam/より取得できる。NS(バージョン2)は、C++とOtclで書かれたオブジェクト指向のイベントドリブン・ネットワークシミュレータでありローカル・広域ネットワークをシミュレートするのに役立つ。既存のモジュールを組み合わせてシミュレーションを行うにはOtclのスクリプトを書けば良く、又、新たなモジュールはC++で追加する。

インストールについては付録参照。

2-1-1　nam(network animator)

ns-2はOtclなどで記述したスクリプトに従いトレースファイルを出力する。そのトレースファイルをもとにシミュレーション内容をアニメーション化するツール。使用方法は実験方法にて述べる。

2-1-2　xgraph

ns上にて得られたシミュレート結果をXwindow ｓｙｓｔｅｍ上でグラフ化するツール。

2-1-3　nsによって生成されるトレースファイル

nsはスクリプトを解釈し、テキストファイルを出力する。この時、シミュレーションをトレースした状況を出力できる。このnsのトレース機能で出力される出力ファイルの見方を説明する。次はnsが出力するトレースファイルの例である。

s 0.032821055 _1_ RTR --- 0 message 32 [0 0 0 0] ------- [1:255 -1:255 32 0]

s 0.178591360 _2_ RTR --- 1 message 32 [0 0 0 0] ------- [2:255 -1:255 32 0]

s 1.113402886 _0_ RTR --- 2 message 32 [0 0 0 0] ------- [0:255 -1:255 32 0]

これらの各一行が，あるパケットに起こった1つのイベントに対応している。行のフォーマットは，空白で区切られ左から右へ順にそれぞれ以下の意味になっている。

１.イベントの種類．基本的にr, s, f, Dのいずれか

r : receive

s : sent

f : forward

D : drop

2.イベントの発生時刻

3.ノードナンバー

4.パケットがMAC層に関係するならMAC、トランスポート層に関係するならAGT、ルートパケットならRTRと表示する。

5.パケットのシーケンスナンバー(tcpのシーケンスナンバーではない)

6.パケットの種類(tcp、udpなど)

7.パケットのサイズ

8.一つ目の[　]内の数字

送られる予想時間(16進数)、受信ノードのMAC-ID、送信ノードのMAC-ID、パケットの種類をあらわす。

9.二つ目の[　]内の数字

送信元アドレス：ポート番号、目的アドレス：ポート番号、TTL、次のホップに存在するノードIDを表す。

10.三つ目の[　]内の数字

シーケンス番号、(ACK番号)を表す。

2-2　TCP

インターネットで利用される標準プロトコルで、OSI参照モデルのトランスポート層にあたる。ネットワーク層のIPと、セッション層以上のプロトコル(HTTP、FTP、SMTP、POPなど)の橋渡しをする。TCPはEnd to Endで確実なデジタル転送を行うものである。各ホストは、ポート番号ごとに異なるTCPによる転送を行うことが出来る。IPパケットは有限長で、信頼性も保証されてないが、TCPはIPパケットを用いデータをセグメントに区分しセグメントごとに受信確認や必要に応じて再送するなどして信頼性を保証する。また通信速度に応じて輻輳制御を行う。

2-2-1　TCP の特徴

TCPとUDPの、ユーザ側から見た基本的な違いを図１に示す。

	UDP	TCP
接続形態	一対一および一対多どちらも可能	一対一のみ
アプリケーションの特定方法	UDPポート番号	TCPポート番号
送受信の単位	パケット(*1)	ストリーム(*2)
宛先までの到達保証	なし	あり
送信エラー時の動作	検知しない	自動的に再送
事前のアプリケーション同士の接続動作（コネクションの確立）	不要(*3)	必要(*4)
輻輳制御(*5)	行わない	行う

図１ TCPとUDPの違い

(*1)パケット……送信側が送ったパケットが、そのままの形で受信側に届く。ヘッダ情報を含め65536バイト以下でなければならない。

(*2)ストリーム……送信されるデータはの長さに制限はない。

(*3)コネクションレス型通信と呼ばれる。

(*4)コネクション型通信と呼ばれる。

(*5)ネットワークが混雑してきたら送る量を減らすこと。

UDPは基本的にIPのパケットにデータを乗せるだけだがTCPは以下のような制御を行う必要がある。

コネクション（接続性）の確立

送達確認(ACK)

到着順序保証

輻輳制御

2-2-2　コネクション（接続性）の確立

まず大前提として、アプリケーションはTCPで接続をオープンする際に、自分が能動的(active)に接続しにいくのか、受動的(passive)に相手側からの接続を待つのかを前もって決定しておく必要がある。前者をクライアント・アプリケーション（以下クライアント）、後者をサーバ・アプリケーション（以下サーバ）と呼ぶ。

接続確立時のシーケンスは以下のようになる。これを３ウェイ・ハンドシェークと呼んでいる。便宜上、クライアント←サーバの転送を下り、その逆を上りと称す。また、SYN, ACK ビットとはTCPパケットの14バイト目(下6ビット)にあるフラグの中の各ビットのことである。

３ウェイ・ハンドシェーク
サーバ		クライアント	説明
	←	SYN	上りコネクションの確立を試みる。
ACK+SYN	→		SYNに対するACKを立てる（上りコネクションの確立を承認）とともに、自らもSYNビットを立てることにより、下りコネクションの確立を試みる。
	←	ACK	下りコネクションの確立を承認する。

図２　３ウェイ・ハンドシェーク

これを見てもわかるように、上りと下りで論理的には別々のコネクションを確立するような感じになる。また、 TCPは全２重（同時に双方向の通信ができる）通信を行うことができる。

2-2-3送達確認(ACK)

TCPではデータを定められた長さに区分して送る。またTCPでは肯定応答をするために ACK ビットを使用する。コネクションの確立のところでは、 ACKはSYN（接続要求）に対する肯定応答として使用された。いったん接続が確立されると（３ウェイ・ハンドシェークで使われた３パケットの次のパケット以降）、ACKは相手からの実パケットに対する肯定応答という意味になる。TCPでユニークなところは、 ACKパケットを単独で返すだけではなく、自分が送信するパケットのTCPヘッダに、「前回のそちらからのパケットを正常に受信しました」という意味のACKビットを立てるということである。つまり、肯定応答とパケットの送信を１パケットで行うことができるということである。TCPではパケットを送信するたびに、送信側はシーケンス番号（TCPパケット・ヘッダの5バイト目）を増やしてゆき、ACK は相手側から受信した「シーケンス番号」番目のセグメントまでは正常に受信したことを相手側に知らせる。

ウィンドウとは、バッファ内でデータの読み書きを行ったり、格納してあるデータの管理を行ったりする領域のこと。ウィンドウの範囲内であれば、一時的にデータを保存しておくことができ、データの損失を防ぐことができる（バッファのサイズが足らず、データがあふれ出てしまうことをバッファオーバフローと言う）。

2-2-4　到着順序保証

上記のシーケンスで見たように、受信側では、ストリームのうち何セグメント目までを受信したかを意識してACK番号をセットしてACKを返し、データが途中で抜けた場合はデータが到着するたびに正常に連続して受信できたセグメント番号の次の値を返す。送信側ではパケットを送出するたびにタイマーを発生させ、一定時間にACKが返らないと、データの再送を行う(タイムアウト)。また、（途中のルータによる再送などで）重複したパケットが到着する場合もあるが、この場合はパケット・ヘッダのシーケンス番号がすべて同一になるので、受信側はシーケンス番号（＋データ長）を見て、自分がすでにACKを返した分のデータ・ストリームは無視（破棄）する。

2-2-5　輻輳制御

輻輳制御は通信路の容量に応じて送信側が送信量を調節することで、シリアル通信などで使われるフロー制御としては、XON/XOFFという文字を使って行うソフトウェア・フロー制御と、モデムの信号線をオンオフすることによって行うハードウェア・フロー制御というものがある。これは制御信号が信頼できる通信路を使えるという前提があるから行える処理でありインターネットでは使用できない。

2-2-6　スロースタートアルゴリズム

TCPの輻輳制御にスロースタートアルゴリズムというものをがある。最初は１つでAckが届くうちは一度に送る数を増やしていく。この送信者が一度に送信することの出来るデータ量を輻輳ウインドウという。増え方は1,2,4と倍々だがある程度(しきい値)までいったら、１ずつになる。グラフにすると、図3のようになる。

図3　スロースタートアルゴリズムの基本的な動作

最初は、小さい数のセグメントを送り、Ack１つにつき輻輳ウインドウ幅を１ずつ増やす。だが、多く送ると、それだけ輻輳の可能性が増える。なので、しきい値までいったら、輻輳が起きたと判断しゆっくりと増やしていく。Ackがタイムアウトにより１つでも返ってこなかった場合、輻輳ウインドウを１にする。グラフにすると、図4のような形である。

図4　スロースタートアルゴリズムにおける輻輳発生時の処理

図４のように基本は１まで戻す形になる。そうすることによって連続して輻輳は発生しないからである。しかし１まで戻せば、連続して輻輳は発生しないが、また多く送ることができるまでに時間がかかる。なので、Fast Retransmitは３回同じAckがきたとき(トリプルAck)図5のようになる。

図5　スロースタートアルゴリズムにおける輻輳発生時の処理2

つまり、スロースタートアルゴリズムとは、送る数を増やしつつ、輻輳が起きる送信数を手探りで探していく方法だ、と考えるとわかりやすいといえる。

2-3　FTP

ファイルを転送するときに使われるプロトコル。インターネットでHTTPやSMTP/POPと並んで頻繁に利用されるプロトコルである。FTPはIETFによってRFC 959で定義されている。

2-4　DSDV

DSDV（Destination Sequenced Distance Vector）ルーティングは、古典的な Bell-Ford ルーティングアルゴリズムをもとにした、テーブル駆動型のルーティングプロトコルである。この方式では、モバイルネットワーク内のルータ間でルーティング情報がループしないよう、改良が加えられている。モバイルネットワーク中の各ノードは、同一ネットワーク内の到達可能なすべての宛先とその宛先までのホップ数（この場合、無線ホップ数）を記録した、ルーティングテーブルを管理している。したがって、送信元ノードが経路を必要とするしないに関わらず、常に利用可能なルーティング情報が準備されている。シーケンス番号方式は、経路が新しいか古いかをモバイルホストが判断するのに使用する。ルーティングテーブルの更新情報は、テーブルの整合性を維持するためにネットワーク全体に定期的に送信される。したがって、ネットワーク中に多くの制御トラフィックを生成してしまい、ネットワーク資源の利用効率を低下させる結果となってしまう。この問題を軽減させるために、DSDV は 2 種類のルーティング情報更新用パケットを使用する。1 つは、フルダンプ(full dump)である。このパケットは、利用可能なすべてのルーティング情報を格納しており、ネットワークプロトコルデータユニット(NPDU)を複数要求することができる。ノードの移動が時折発生する程度では、このパケットが送信されることはまれである。もう 1 つは、フルダンプより小さな差分(incremental)パケットである。こちらは、最後に行なったフルダンプ以降の更新情報のみを送信する時に用いる。新しいルーティング情報をブロードキャストする時、宛先ノードのアドレス、宛先までのホップ数、そしてそのブロードキャストの新しい一意なシーケンス番号とともに、宛先についての情報を受信した時のシーケンス番号を格納する。最も新しいシーケンス番号を持つ経路が常に使用される。2つの経路更新情報が同じシーケンス番号を持つ場合、ホップ数の少ない経路を選択する。

3 実験

今回はWindowsを用いて実験を行った。nsはもともとUNIXで開発されたソフトウェアなのでWindowsではCygwinを必要とする。今回は3ノードおよび5ノードの無線ネットワークについて3パターンの実験を行った。ｎamによるアニメーションの動作に加えnsのトレースファイルとxgraphの出力の3点から観察を行った。3パターンとも基本は同じtclスクリプトを用いており。違うのはノード数と移動方法のみである。また実験1、2では各ノードが目的地に向かってフラフラと移動するように設定した。これはノード間の距離や速度などによる通信への影響を見るためである。基本的には指定されたノード間でFTPによるファイル転送を802.11無線LAN上で行う。この時ルーティングプロトコルはDSDVを使う。

3-1　3ノードの移動する無線ネットワーク

3ノードの無線ネットワークをシミュレートしnamやトレースファイルで観察する。

(１)Cygwin Bash Shellを起動。startxコマンドでXserverを起動する。

(２)ns net01.tclとコマンドを打つことでシミュレートする。

図6　 simwrls01のイメージ図

図6のように3つのノード0、1、2に対してノード1からノード2へファイル転送を行う。ただしノード1と2は直接通信できない。このような状況でノード1は左から右へ、ノード2は右から左へ移動する。

スクリプトnet01.tcl付録参照。以下に要所の説明を記す。

まず、Otclにおいて基本的にset val(変数名) 変数に設定する値という構文になっている。

#以降はコメント文である。

set val(chan) Channel/WirelessChannel ;# channel type
set val(prop) Propagation/TwoRayGround ;# radio-pripagation model
set val(netif) Phy/WirelessPhy ;# network interface type　
set val(mac) Mac/802_11 ;# MAC type
set val(ifq) Queue/DropTail/PriQueue ;# interface queue type
set val(ll) LL ;# link layer type
set val(ant) Antenna/OmniAntenna ;# antenna model
set val(ifqlen) 50 ;# maxpacket in ifq
set val(nn) 3 ;# number of mobile nodes
set val(rp) DSDV ;# routing protocol
set val(x) 600 ;# X dimension of topography　シミュレート領域の大きさ
set val(y) 600 ;# Y dimension of topography　X座標とY]座標を用いて設定する
set val(stop) 130 ;# time of simulation end　シミュレートの終了時刻

ここまでは連想配列valにさまざまな初期値を入れている。

set ns [new Simulator]

ここでシミュレータのオブジェクトを生成する。シミュレータは変数＄nsで参照される。

以下3行のコマンド中の[ ]内のtrace01.trなどの部分はシミュレートの際に書き出すファイル名であり任意のものを設定できる。

set tracefd [open trace01.tr w]　#トレースファイルの設定
set windowVsTime2 [open win01.tr w]　#Xgraph用のファイル
set namtrace [open simwrls01.nam w] #namで使用するアニメーションファイル

ここでは各ノードの基本的な設定が行われる。

￥記号は継続行を意味するので￥記号で終わらない行までまとめて1行であると解釈される。

$ns node-config -adhocRouting $val(rp) \
-llType $val(ll) \
-macType $val(mac) \
-ifqType $val(ifq) \
-ifqLen $val(ifqlen) \
-antType $val(ant) \
-propType $val(prop) \
-phyType $val(netif) \
-channelType $val(chan) \
-topoInstance $topo \
-agentTrace ON \
-routerTrace ON \
-macTrace OFF \
-movementTrace ON

ここで＄val(nn)個のノードが生成される。

for {set i 0} {$i < $val(nn) } { incr i } {
set node_($i) [$ns node]
}

# Provide initial location of mobilenodes　ノードの初期位置の設定

各ノードにX,Y,Zの座標を設定する。

$node_(0) set X_ 300.0　#X.Y,Z座標で設定
$node_(0) set Y_ 300.0
$node_(0) set Z_ 0.0

$node_(1) set X_ 100.0
$node_(1) set Y_ 460.0
$node_(1) set Z_ 0.0

$node_(2) set X_ 500.0
$node_(2) set Y_ 130.0
$node_(2) set Z_ 0.0

# Generation of movements　シミュレート中の各ノードの動作の設定

$ns at 15.0 "$node_(1) setdest 500.0 340.0 5.2"

$ns at 35.0 "$node_(1) setdest 500.0 480.0 5.2"

$ns at 55.0 "$node_(1) setdest 500.0 440.0 5.2"

$ns at 75.0 "$node_(1) setdest 500.0 310.0 5.2"

$ns at 95.0 "$node_(1) setdest 500.0 460.0 5.2"

$ns at 15.0 "$node_(2) setdest 100.0 200.0 5.0"

$ns at 30.0 "$node_(2) setdest 100.0 40.0 5.0"

$ns at 50.0 "$node_(2) setdest 100.0 140.0 5.0"

$ns at 70.0 "$node_(2) setdest 100.0 240.0 5.0"

$ns at 90.0 "$node_(2) setdest 100.0 140.0 5.0"

Setdest以降の空白で区切られた各値のうち最初の値は目標地点のX座標次がY座標　最後の値は速度となっている。

上の例の場合、時刻15.0にノード1は500.0、340.0に向かって速度5.2で移動する。

また時刻ごとに細かく目的地を変えることでノードにふらふらとした動作をさせている。

# Set a TCP connection between node_(1) & node_(2)　ノード間の通信の設定
set tcp [new Agent/TCP/Newreno]　#TCPのバージョンはNewrenoを用いる
$tcp set class_ 2
set sink [new Agent/TCPSink]
$ns attach-agent $node_(1) $tcp
$ns attach-agent $node_(2) $sink
$ns connect $tcp $sink
set ftp [new Application/FTP]
$ftp attach-agent $tcp
$ns at 10.0 "$ftp start"

(3)生成されたトレースファイルsimwrls01.namをnamを起動させ観察する。

(4)同様にwin01.trをXgraphを起動させグラフを観察する。グラフは図7参照。

図7　win01.tr

(5)home内にtrace01.trという名前のトレースファイルがテキストファイル形式で生成されている。膨大な行数なので全てを検証するのは困難である。そのためグラフよりイベントの発生時刻を参考にし、要所要所(図7の場合、時刻40付近、時刻105付近が通信の開始と終了点なのでそこを見てみるとよい)での通信の動きを観察するとわかりやすいだろう。

トレースファイルについては膨大な行数のため割愛する。

結果、図7のグラフとトレースファイルによりackが時刻38付近まで送信されていないことがわかった。同様に時刻105付近で通信が終了している。始めの通信開始までの無通信時間はルーティングプロトコルとして用いたDSDVの仕様によるものと思われる。DSDVは送信要求発生前にあらかじめ各端末への経路情報、ルーティングテーブルを作成しておく。つまり時刻38付近までは各端末が初期のルーティングテーブルの情報のやり取りをしていたと思われる。通信終了については単純にノード間の距離が離れたためと思われる。

3-2　5ノードの移動する無線ネットワーク

3-1と同様の手順でnet02.tcl、simwrls02.nam、win02.tr、trace02.trと実験、観察を行う。

図8　simwrls02の動作イメージ

基本的なスクリプトは3-1と共通である。今回はノード数を2つ追加する。各ノードの動作は図８のようにノード１と４、ノード2と3がそれぞれノード0を経由しファイル転送を行う。この時ノード1はノード3の、ノード3はノード1の初期位置へと向かい移動する。同様にノード2はノード4の、ノード4はノード2の初期位置へと移動する。

以下が3-1との主な相違点である。ノードの増加および初期位置と目的地を変更してある。

また今回も時刻ごとに目的地を変えることでふらふらとした動作を行わせている。

# Provide initial location of mobilenodes

$node_(0) set X_ 300.0

$node_(0) set Y_ 300.0

$node_(0) set Z_ 0.0

$node_(1) set X_ 100.0

$node_(1) set Y_ 460.0

$node_(1) set Z_ 0.0

$node_(2) set X_ 110.0

$node_(2) set Y_ 140.0

$node_(2) set Z_ 0.0

$node_(3) set X_ 500.0

$node_(3) set Y_ 450.0

$node_(3) set Z_ 0.0

$node_(4) set X_ 500.0

$node_(4) set Y_ 130.0

$node_(4) set Z_ 0.0

# Generation of movements

$ns at 15.0 "$node_(1) setdest 500.0 360.0 5.2"

$ns at 35.0 "$node_(1) setdest 500.0 560.0 5.2"

$ns at 55.0 "$node_(1) setdest 500.0 260.0 5.2"

$ns at 75.0 "$node_(1) setdest 500.0 400.0 5.2"

$ns at 95.0 "$node_(1) setdest 500.0 460.0 5.2"

$ns at 15.0 "$node_(2) setdest 500.0 40.0 5.0"

$ns at 35.0 "$node_(2) setdest 500.0 240.0 5.0"

$ns at 55.0 "$node_(2) setdest 500.0 140.0 5.0"

$ns at 75.0 "$node_(2) setdest 500.0 340.0 5.0"

$ns at 95.0 "$node_(2) setdest 500.0 140.0 5.0"

$ns at 15.0 "$node_(3) setdest 100.0 400.0 4.7"

$ns at 35.0 "$node_(3) setdest 100.0 490.0 4.7"

$ns at 55.0 "$node_(3) setdest 100.0 460.0 4.7"

$ns at 75.0 "$node_(3) setdest 100.0 360.0 4.7"

$ns at 95.0 "$node_(3) setdest 100.0 460.0 4.7"

$ns at 15.0 "$node_(4) setdest 100.0 100.0 5.5"

$ns at 35.0 "$node_(4) setdest 100.0 150.0 5.5"

$ns at 55.0 "$node_(4) setdest 100.0 180.0 5.5"

$ns at 75.0 "$node_(4) setdest 100.0 40.0 5.5"

$ns at 95.0 "$node_(4) setdest 100.0 140.0 5.5"

図9　win02.tr

図9のグラフより時刻90付近で大きな伸びが見られる。これは各ノードの移動速度の差が以下に述べるような状態をで引き起こしたためと思われる。ノード1，4に比べてノード2、3の移動速度は若干遅く設定してある。そのためノード2、3は図10のようにノード1、4よりも目的地に到達するのが遅い。namの動作を見ると図10に見られるように目的地に到達するころには通信は行われていない。そのためノード1、4が目的地に到達後はノード2、3のみが通信を行うためノード0にかかる負荷が少なくなると思われる。それがこの結果につながったと思われる。

図10　時刻90付近での各ノードの様子

3-3　5ノードの移動する無線ネットワーク(パターン2)

同様にnet03.tcl、simwrls03.nam、win03.tr、trace03.tr について実験、観察を行う。

図11　simwrls03の動作イメージ

3-2について各ノードの移動パターンを変えてシミュレートした。今回も基本スクリプトは3-1と同様で異なる点は各ノードの移動パターンのみである。図11のようにノード1と4がノード0を経由して通信を行う。同様にノード2と3もノード0を経由し通信を行う。今回は各ノードが反時計回りに移動する。これにより各ノードが交錯することがない。これは実験2と比べてノードが接近したり重なったときの影響と見比べるためである。

以下が3-2との主な相違点である。ノードの目的地を変更することで3-2と違った移動を行わせている。