テレビ受信カバレッジマップ

平成 23 年度
修士論文
無線 LAN を利用したトランスポート層、アプリ
ケーション層における QoS 向上のための諸検討
早稲田大学 基幹理工学研究科 情報理工学専攻
5110B034
金井 謙治
指導
甲藤 二郎
教授
2012 年 1 月 31 日
指導教授印
受付印
1
第 1 編
動画像配信向け適応レート制御方式の性能
評価
第1章
序論 ......................................................................................................................................5
1.1 研究背景 ...................................................................................................................................5
1.2 研究目的 ...................................................................................................................................5
第2章
TCP と UDP .........................................................................................................................6
2.1 TCP .................................................................................................................................................6
2.1.1 TCP Reno [6] .......................................................................................................................6
2.1.2 TCP Vegas [7] ......................................................................................................................7
2.1.3 CUBIC [8]............................................................................................................................7
2.2 UDP ............................................................................................................................................9
2.2.1 TFRC (TCP-Friendly Rate Control) [9] ...............................................................................9
2.2.2 TFRC の課題点.................................................................................................................15
2.2.3 TFWC (TCP-Friendly Window-based Congestion Control)[10] .......................................15
2.2.4 LDA (Loss Differentiation Algorithm) ..............................................................................17
2.2.5 VTP (Video Transport Protocol) [14].................................................................................19
2.2.6 Hybrid-TFRC[15] ..............................................................................................................21
第 3 章 ストリーミング...................................................................................................................23
3.1 ストリーミングとは.............................................................................................................. 23
3.2 IP ネットワーク上でのストリーミング ..............................................................................23
3.2.1 TCP と UDP ......................................................................................................................23
3.2.2 ストリーミングにおける課題点 ...................................................................................24
3.2.3 RTP(Real-time Transport Protocol)と RTCP(RTP Control Protocol)[11] .........................25
3.2.4 VIC (Video Conferencing Tool) [5] ...................................................................................30
第 4 章 無線 LAN におけるスループットおよび遅延理論算出 .................................................31
4.1 無線 LAN アクセス制御方式 ...............................................................................................31
4.2 無線 LAN におけるスループットおよび遅延理論算出 ....................................................31
4.3 マルコフモデルを利用したスループット算出モデル式[27] ...........................................33
4.3.1 パケット送信確率算出モデル式 .......................................................................................33
4.3.2 スループット算出モデル式 ...............................................................................................36
4.4 リトルの公式による遅延算出モデル式[29] ...........................................................................38
4.4.1 リトルの公式.......................................................................................................................38
4.4.2 リトルの公式を利用した遅延算出モデル式[29] ............................................................39
2
第 5 章 動画配信向け適応レート制御方式の性能評価 ...............................................................41
5.1 VIC への適応レート制御実装について ...............................................................................41
5.1.1 VIC への適応送信レート制御実装 ....................................................................................41
5.1.2 VIC への適応画像圧縮レート制御実装 ............................................................................42
5.1.3 VIC への各種適応レート制御実装について ....................................................................43
5.2 トランスポート層およびアプリケーション層における適応レート制御実装とその性
能評価 ............................................................................................................................................43
5.2.1 実験環境 .............................................................................................................................. 43
5.2.2 実験トポロジーおよび実験シナリオ ............................................................................... 44
5.2.3 客観画像評価手法............................................................................................................... 45
5.2.4 単独配信実験.......................................................................................................................46
5.2.5 動画像・TCP 競合配信実験 .............................................................................................. 48
5.2.6 公平性問題 .......................................................................................................................... 51
5.3 動画像配信向け適応レート制御実装とその性能評価 ......................................................52
5.3.1 実験シナリオ.......................................................................................................................52
5.3.2 分散と Fairness Index ..........................................................................................................53
5.3.3 動画像配信実験...................................................................................................................53
5.4 動画像配信実験におけるまとめ ..........................................................................................59
5.5 今後の課題点 ......................................................................................................................... 60
第 6 章 今後の展望 .......................................................................................................................... 61
参考文献 ............................................................................................................................................63
第2編
無線 LAN の実スループット特性に基づく寄
り道経路探索の評価
第1章
序論 ....................................................................................................................................65
1.1 研究背景 .................................................................................................................................65
1.2 研究目的 .................................................................................................................................66
第2章
最適寄り道経路.................................................................................................................67
2.1 最適寄り道経路[8,9] ..............................................................................................................67
2.2 従来評価モデル......................................................................................................................67
2.2.1 ワイヤレス通信が理想通り利用できる環境における評価[8] ..................................67
2.2.2 確率的にリソースが変動する環境下における評価[9] ..............................................68
第 3 章 実環境におけるスループット特性 ...................................................................................70
3
3.1 様々な環境下におけるスループット特性 .......................................................................... 70
3.1.1 実験環境 .......................................................................................................................... 70
3.1.2 実験結果 .......................................................................................................................... 70
3.2 公衆無線 LAN におけるスループット特性........................................................................ 72
3.2.1 Android Tablet vs Windows PC .........................................................................................73
3.2.2 公衆無線 LAN におけるスループット特性.................................................................74
第 4 章 寄り道特性評価...................................................................................................................75
4.1 評価指標 .................................................................................................................................75
4.2 基地局の可視化について......................................................................................................75
4.3 単一スループット特性環境下における寄り道特性評価 ..................................................75
4.4 複数スループット特性環境下における寄り道特性評価 ..................................................78
4.5 実都市における寄り道特性評価 ..........................................................................................82
4.5.1 実スループット特性に基づくモデル化 .......................................................................23
4.5.2 実都市を参考にした評価マップ作成 ........................................................................... 83
4.5.3 シミュレーション環境...................................................................................................84
4.5.4 シミュレーション評価...................................................................................................85
4.5.5 実機による評価............................................................................................................... 88
第 5 章 まとめと今後の展望...........................................................................................................92
参考文献 ............................................................................................................................................93
謝辞 .................................................................................................................................................... 94
発表文献リスト ................................................................................................................................95
4
第1章
序論
1.1 研究背景
近年，無線端末の普及，多様化により無線通信を利用する機会が増加した．特に，携帯
電話のみならず，駅，ファーストフード店，さらに新幹線でも無線環境が整っているため，
誰もが気軽に街中でインターネットの利用が可能となった．また一方で，動画像圧縮技術
の向上により，様々な動画像サービスの提供が行われている．携帯電話で TV 放送を受信で
きるワンセグ放送，Gyao[1]などのように，VoD(Video on Demand)のような単方向的な視聴
だけでなく，Youtube[2]やニコニコ動画[3]，Ustream[4]などのアプリケーションでは，誰で
も気軽に動画像の配信を楽しめ，双方向的な利用が行われている．
こうした中で，動画像コンテンツを無線ネットワーク上でもストレスなく行える必要が
出てきている．しかし，有線ネットワークと比較して無線ネットワークでは，通信帯域が
限られ，さらに，無線ネットワーク特有のパケットロスを起こすことから，動画像配信の
QoS(Quality of Service)を実現するためには，有線ネットワーク以上に難しい．
このような無線特有の問題を解決するために，輻輳制御や MAC レイヤにおいて，また，
複数のレイヤにまたがって多くの提案がされているが，実際のアプリケーションとの強調
が考慮されているものは少なく，実際の利用においても，多くの場合で有線向けの TCP の
上で動作するアプリケーションをそのまま無線ネットワークで利用し，アプリケーション
の性能を十分に発揮できていないのが現状である．
1.2 研究目的
本研究の目的は，有線無線ネットワーク混在網上で実機による動画像通信を VIC[5]とい
うアプリケーションを利用して行い，その際に問題となる点を具体的に示す．さらに，具
体的問題点を参考にし，VIC に新たな輻輳制御を組み込むことで，動画像配信の QoS を実
現することを目指している．
5
第2章
TCP と UDP
本章では，TCP (Transmission Control Protocol)・UDP (User Datagram Protocol)の輻輳制御に
ついて説明する．
2.1 TCP
ここでは，インターネットにおける輻輳制御方式の例として，TCP を用いた方式につい
て取り上げる．TCP では，受信側に Ack (Acknowledgement)という受信確認のパケットを送
信側に返信させ，送信側は，Ack パケットを受信するごとに送信するウィンドウサイズを増
加せる，といった制御が行われている．Ack パケットが何らかの理由で帰ってこなかった場
合，ウィンドウサイズを減少させることで輻輳を防ぎ，さらに，パケットのヘッダにシー
ケンス番号を付加することでフレームのロスを検知することが可能となり，ロスしたパケ
ットについて再送要求を行う．このような仕組みにより，TCP では信頼性の高い通信を行
うことが可能となる．以下に，TCP Reno，TCP Vegas，TCP Cubic の輻輳制御についてより
詳細な説明を行う．
2.1.1 TCP Reno [6]
TCP Reno[6]は，Ack パケットの到着をもとにして，転送レートの調節を行う，ウィンド
ウフロー制御を行っている．Reno では，輻輳ウィンドウサイズと呼ばれる Ack パケットの
受信を待たずして連続で送信可能なパケットの最大数の設定を行う．送信側では，データ
パケットを送信済みであるが，Ack パケットを受信していないパケット数が輻輳ウィンドウ
サイズよりも小さい場合，さらに続けてデータパケットの送信を行うことができる．もし，
Ack パケットを受信していないパケット数が輻輳ウィンドウサイズと等しくなった場合，パ
ケットの送信を停止し，Ack パケットの到着を待つ．Ack パケットを受信すると，輻輳ウィ
ンドウサイズ(cwnd)を(1.1)のように変更する．
⎧⎪cwnd + 1　if　cwnd < ssth
1
cwnd ← ⎨
cwnd +
otherwise
⎪⎩
cwnd
(1)
ここで，ssth は，slowstartthrethold と呼ばれる値で，
「スロースタートフェイズ」から「輻
輳回避フェイズ」と呼ばれる動作モードに移行する時の閾値である．(1)式から Reno では，
スロースタートフェイズ時には輻輳ウィンドウサイズを指数的に増加させ，輻輳回避フェ
イズ時には輻輳ウィンドウサイズを線形的に増加させる．
次に，Reno がパケット廃棄を検出した場合について述べる．Reno では，ネットワーク中
でパケット廃棄を検知する方法として，重複 Ack(Duplicate ACK)とタイムアウトといった二
種類があげられる．まず，重複 Ack によりパケット廃棄を検知した場合(Fast Retransmission)
では，閾値 ssth と輻輳ウィンドウサイズ cwnd を(2)式のように更新させる．
6
⎧ssth ← cwnd / 2
⎨
⎩ cwnd ← ssth
(2)
このため，高速回避フェイズにおいて，輻輳ウィンドウサイズは指数的に増加するよう
になる．もし，再送パケットに対応した Ack パケットを受信した場合，高速回避フェイズ
から輻輳回避フェイズへと移行することとなり，輻輳ウィンドウサイズを高速回避フェイ
ズ前の値に戻すようにする．
タイムアウトによりパケット廃棄を検知した場合，閾値 ssth と輻輳ウィンドウサイズ
cwnd を(3)式のように更新させる．
⎧ssth ← cwnd / 2
⎨
⎩ cwnd ← 1
(3)
図 1 に Reno の輻輳ウィンドウサイズの動作を示す．このような Reno のウィンドウフロ
ー制御により，ネットワークに送信されるパケット量を調節することが可能となり，ネッ
トワークにおける輻輳の防止，もしくは，早期の検知，解消へとつながる．
スロースタート
輻輳回避
輻輳回避
輻輳回避
輻輳回避
：輻輳ウィンドウ
：スロースタート閾値
時間
図 1 TCP-Reno におけるウィンドウ変化([12]より)
2.1.2 TCP Vegas [7]
TCP Vegas[7]は，Delay-based protocol の代表例であり，輻輳の指標としてパケットロスだ
けでなく，RTT の増減を利用して，よりネットワークの状況を考慮した輻輳制御方式であ
る．TCP Vegas の輻輳ウィンドウ制御は，ボトルネックとなるルータのキュー内パケット数
(diff)の推定値によって制御される．TCP Vegas の輻輳ウィンドウ制御の様子を(4)式，(5)式
に，diff の算出方法を(6)式に示す．
スロースタートフェイズ
7
(diff < γ)
⎧ cwnd + 1　cwnd = ⎨
(diff ≥ γ)
⎩cwnd × (1 − p ) (4)
輻輳回避フェイズ
(diff ≤ α)
⎧cwnd + 1 cwnd ⎪
cwnd = ⎨ cwnd　(α < diff <β)
⎪ cwnd − 1 cwnd　(diff ≥β)
⎩
(5)
diff の算出
diff =
cwnd cwnd
−
RTTmin RTT
(6)
ただし，
cwnd
：ウィンドウサイズ[パケット]
RTT
RTTmin
α,β,γ, p
：ラウンドとリップタイム[sec]
：最小 RTT [sec]
：定数
このような輻輳制御を行うことで，TCP Vegas では，ほかのトラフィックが存在しない場
合には，輻輳ウィンドウサイズはパケットロスを引き起こすことなく一定となり，TCP Reno
よりも 30%から 70%程度スループットを改善することができるといわれている．
しかしながら，TCP Reno と TCP Vegas が混在している場合には，TCP Reno の輻輳ウィン
ドウサイズ増加を，初期輻輳と判断してしまうことから，TCP Vegas の輻輳ウィンドウサイ
ズは減少傾向となり，結果，スループットが減少してしまう問題がある．
2.1.3 CUBIC [8]
CUBIC[8]は，BIC(Binary Increase Congestion Control)[13]の改良版であり，TCP Reno との
親和性を改善するため，新たなウィンドウ制御手法を用いている．CUBIC では，最後とパ
ケットロス時からの超過時間の三次関数で輻輳ウィンドウの増加幅が決定される．以下に
具体的な計算式を(7)式に示す．
cwnd = C (T − K ) 3 + Wmax
K = 3 Wmaxβ/ C
8
(7)
ロス時には以下のように設定する．
cwnd = cwnd ∗ (1 −β)
(8)
また，ロスを検知したときのウィンドウサイズが前回ロス時よりも小さいときには，
Wlast _ max を以下のように変更する．
Wlast _ max =
cwnd ∗ (2 −β)
2
(9)
ただし，
C
：Scaling factor
T
β
：最後のパケットロスからの経過時間
：パケットロス時の輻輳ウィンドウ減少率
Wlast _ max
：前回のパケットロス時のウィンドウサイズ
これまでの TCP 同様，輻輳ウィンドウは RTT ごとの更新ではあるが，RTT 数に依存しな
いウィンドウ制御を行うことが可能となる．
2.2 UDP
UDP (User Datagram Protocol)は，TCP とは異なり，Ack パケットの送信機能や，データパ
ケットの再送機能を持たず，より単純な制御となっている．UDP は，その単純な制御機構
により，信頼性が低下してしまうが，オーバーヘッドが小さく，高速な通信を行うことが
できることから，リアルタイムストリーミング用のプロトコルとして広く利用されている．
また，別の特徴として，単体ではレート制御を行わない，といったことがあげられる．し
かし，そのため，現在広く用いられている TCP と共存すると，UDP による通信の方が帯域
を占有してしまい，TCP の通信品質がひどく低下してしまうことが知られている．そのた
め，TFRC[9]や TFWC[10]，VTP[14]さらに Hybrid-TFRC[15]のような輻輳制御が必要となる．
2.2.1 TFRC (TCP-Friendly Rate Control) [9]
TFRC[9]とは，優先ネットワーク環境下で混在する TCP フローとの公平な帯域利用の実
現を目的としたユニキャストの輻輳制御メカニズムであり，UDP と同様に，再送制御を持
たないベストエフォート型の通信を行う．TFRC では，受信側から，受信スループットやロ
スイベント率などをフィードバックパケットとして送信側に送信し，送信側は，そのフィ
ードバックパケットを利用して適応的にレート変動を行い，QoS の確保，および TCP との
公平性を実現する．TFRC の輻輳制御は，TCP の輻輳制御と互換性を持つが，TCP ほど激し
いスループットの変動を行わないため，比較的スムーズな送信レートを重視するストリー
ミング配信などに適している．現在，TFRC は，Linux 上で DCCP(Datagram Congestion Control
9
Protocol)[16]の ccid3[17]として実装されつつある．
2.2.1.1 TFRC の輻輳制御メカニズム
TFRC の具体的な輻輳制御メカニズムを以下に示す．
①
受信側でロスイベント率の測定を行い，その情報をフィードバックパケットとして送
信側へ送信する．
②
送信側は，受信した情報を元に RTT の測定を行う．
③
ロスイベント率と RTT を TFRC のスループット方程式()に適用することで，送信レー
トの算出を行う．
④
送信側は，算出された送信レートでパケット送信を行う．
2.2.1.2 データパケットの内容
送信側から送られるデータパケットは以下の情報を保持する．
・シーケンス番号
シーケンス番号は，パケットを送信するたびに 1 ずつ増加する．
・そのパケットが送信された際のタイムスタンプ
パケット送信時間のタイムスタンプは，受信側でどのロスが同じロスイベントに属す
るかを判断するために用いられる．また，この値は，受信側によってエコーされ，送
信側が RTT の推定を行えるようにする．
・送信側が推定した RTT 値
推定 RTT 値は，タイムスタンプとともに，受信側が複数のロスがどのロスイベントに
属するか判断するのに用いられる．
2.2.1.3 フィードバックパケットの内容
受信側から送られるフィードバックパケットは以下の情報を保持する．
・最後に受信したデータパケットのタイムスタンプ
このタイムスタンプは，送信側が RTT を推定するのに用いられ，送信側がデータパケ
ット送信時のタイムスタンプを記録していない時のみに必要とされる．
・受信側で最後にデータパケットを受信したときから，今回のフィードバックパケットが
生成されたときまでの時間
・受信側が推定する送信レート
・受信側が推定するロスイベント率
2.2.1.4 TCP 推定レートの算出
送信側は，TCP Reno の動作から導かれたスループット方程式(10)式を用いて，最大送信
レートを算出する．以下にそのスループット方程式(10)式を示す．
10
X =
s
2bp
3bp
R
+ t RTO (3
p (1 + 32 p 2 ) )
3
8
(10)
ただし，
X　s
：送信レート[bytes/sec]
R
p
：RTT[sec]
t RTO
：TCP 再送タイムアウト値[sec]
b
：1 回の TCP Ack に対するパケット数
：パケットサイズ[bytes]
：ロスイベント率[ロスパケット/転送パケット]
2.2.1.5 送信側の挙動
フィードバックパケットを受信した際の送信側の挙動を以下に示す．
①
RTT sample 値を更新する．
Rsample = (t now − t recvdata ) − t delay
(11)
受信時のタイムスタンプから，フィードバックパケット内に保持されているタイムス
タンプと処理遅延を差し引いた値を RTT sample として記録する．
②
推定 RTT(R)値の更新
R = q × R + (1 − q) × Rsample
(12)
③ タイムアウト時間の更新
t RTO = 4 × R
④
(13)
送信レートの更新
If ( p > 0)
X = max(min( X calc ,2 × X recv ), s / t mbi )
Else
If (t now − t ld ≥ R)
(14)
X = max(min(2 × X ,2 × X recv ), s / R)
t ld = t now
上記のように送信レートを算出し，算出された送信レートと，受信側からの実際のレ
ートとを比較し，送信レートの更新を行う．ロスイベント率 p が 0 と等しい場合，ス
ロースタートフェイズに入り，ロスイベントが発生するまで，RTT ごとに送信レート
を 2 倍ずつ増加させていく．t ld (Time Last Doubled)は最後に送信レートが２倍になった
時間である．
11
⑤
nofeedback timer を max(4 R,
2s
) にリセットする．
X
一定時間フィードバックパケットを送信側が受信しなかった場合の挙動を以下に示す．
①
送信レートの上限を半分に減少させる．
If ( X calc > 2 × X recv )
X recv = max(
X recv
s
,
)
2 2 × t mbi
Else
X recv =
②
(15)
X calc
4
nofeedback timer を超過した場合，送信側が RTT sample を保持していなかったなら，
①のステップは無視し，送信レートを半分にする．
X = max(
nofeedback timer を max(4 R,
③
X s
,
)
2 t mbi
(16)
2s
) にリセットする．
X
2.2.1.6 受信側の挙動
受信側では，RTT ごとに 1 つのフィードバックパケットを送信側に送信するが，ロスイ
ベントを検知した場合，RTT の経過を待たずしてフィードバックパケットを送信する．も
し，一つのパケットを受信するのに RTT 以上の時間が経過した場合，パケットを受信する
毎にフィードバックパケットを生成する．
また，送信側が高い送信レートの際，RTT に迅速に対応できるように，RTT ごとに一つ
以上のフィードバックパケットを送信することが有益である．これは，フィードバックパ
ケットロスに対しても耐性がある．
パケットがシーケンスナンバー順に正しく受信されなかった時(Out-of-Order パケットが
受信された時)，後述するロスヒストリからロスイベントの削除を行う．
データパケットを受信した際の受信側の挙動を以下に示す．
① パケットヒストリに受信したパケットを加える．
② 前回までの p の値を p prev とし， p を後述するロスイベント率の計算方式で算出する．
③
p > p prev の場合，feedback timer を終了させ，下記の feedback timer のタイムアウト発生
時の動作で記述されている動作を行う．
p ≤ p prev の場合，何も動作を行わない．
12
ただし，パケットが到着した際，連続した二つのロス間隔が一つに合わさることが起
こったときは，送信側はすぐにフィードバックパケットを送信する．
feedback timer のタイムアウト発生時の動作を以下に示す．
受信側の feedback timer のタイムアウト発生時の動作は，最後のフィードバックパケット
を送信した後にデータパケットを受信したかどうかに依存する．
データパケットを受信していた場合，平均ロスイベント率 p の算出を行い，受信側で受
け取ったシーケンス番号が最大のパケット内の RTT 測定値を Rm としたとき，その Rm 秒以
内に受信したパケット数から実際のスループットである X recv の算出を行う．最後に，フィ
ードバックパケットを送信し，feedback timer のタイムアウトを Rm 秒にセットする．
一方，データパケットを受信していなかった場合，フィードバックパケットを送信せず
に，feedback timer のタイムアウトを Rm 秒にセットする．
2.2.1.7 ロスイベント率 p の算出
ロスヒストリからロスイベントへの変換
受信側はパケットロスヒストリをロスイベントレコードに記録し，RTT 以内に起きた複
数のパケットロスを一つのロスイベントとして扱う．これは，TFRC が連続したロスに対し
てロバストである必要があるためである．
受信側が，ロスしたパケットもしくは ECN(Explicit Congestion Notification)でマーキングさ
れたパケットを，新しいロスイベントとして扱うべきか，既存のロスイベントとして扱う
べきかを判断するために，到着したパケットのシーケンス番号とタイムスタンプを比較す
る．このとき受信側は，ロスパケットごとにその到着時間を推定するために，以下の(2.7)
式を用いる．
Tloss = Tbefore + ((Tafter − Tbefore ) × ( S loss − S before ) /( S after − S before ))
ただし，
S loss
：ロスパケットのシーケンス番号
S before
： S loss よりも前に到着した最後のパケットのシーケンス番号
S after
： S loss よりも後に到着した最初のパケットのシーケンス番号
Tbefore
： S before を受信したときのタイムスタンプ
Tafter
： S after を受信したときのタイムスタンプ
13
(17)
ロスイベント間隔
ロス間隔 A がシーケンス番号 S A のパケットで開始され，次のロス間隔 B がシーケンス番
号 S B で開始される場合，ロス間隔 A 内のパケット数は S B − S A で算出される．
平均ロス間隔
ロスイベント率を算出するために，まず，平均ロス間隔を算出する必要がある．また，
最後の n 個のロス間隔に重みづけをし，ロスイベント率が滑らかに変化するようにする．
まず，重み w0 から w( n −1) は次のように算出する．
n
If (i < )
2
wi = 1
Else
n
i − ( − 1)
2
wi = 1 −
n
( + 1)
2
(18)
これを用いて，平均ロスイベント間隔 I mean は次のようにして計算される．
I tot 0 = 0
I tot1 = 0
Wtot 0 = 0
for (i = 0 ~ n − 1){
I tot 0 = I tot 0 + ( I i × wi )
Wtot 0 = Wtot 0 + wi
}
for (i = 0 ~ n){
I tot1 = I tot1 + ( I i × w(i −1) )
}
I tot 0 = max( I tot 0 , I tot1 )
I mean =
I tot
Wtot
(19)
結果，ロスイベント率 p は，
14
p=
1
I mean
(20)
と求められる．
2.2.2 TFRC の課題点
TFRC は，レート制御をベースとして考えているため，次のような問題点がある，と[18]
では指摘している．具体的な問題点について以下に示す．
・あるネットワーク状況では，スループットが安定しない．[19]
・TCP 推定レートのグラフが凸状の性質を持つため，スループットが不安定となる．[20]
・正確な RTT 測定の困難さから，スループットが不安定となる．
[10]では，これらの問題点の指摘とともに，解決策として，レート制御ではなく，ウィン
ドウベースで TCP-Friendly の実現を行うための TFWC の提案を行っている．
2.2.3 TFWC (TCP-Friendly Window-based Congestion Control) [10]
TFWC[10]は，次に述べる TFRC の問題点を解決するために提案されたウィンドウベース
で TCP-Friendly を実現するために提案された制御方式である．
2.2.3.1 ウィンドウ算出
TFWC の cwnd 算出は，TFRC のように TCP 推定レート式を用いて算出する．以下の(21)
式にその方程式を示す．
W =
1
2p
3p
+ (12
) p (1 + 32 p 2 )
3
8
(21)
ただし，
W
p
：ウィンドウサイズ[パケット]
：ロスイベント率[ロスパケット/転送パケット]
2.2.3.2 ロスイベント率 p の算出
TFWC のロスイベント率 p は，TFRC のロスイベント率 p と同様に算出する．本稿 2.2.1.7
の項目にて具体的な方法を示している．
Loss Event Rate( p ) = 1/Average Loss Interval
(22)
2.2.3.3 AckVector(AckVec)
受信側は，AckVec にフィードバック情報を乗せて送信側へ返す．ただし，TCP のような
累積 Ack といった制御は行わない．AckVec は，パケットが届いたのか，届かなかったのか，
15
といったことを示すためのパケットリストである．AckVec は，送信から送られてきたパケ
ットを受信するたびにリストを伸ばし，そのパケットが正しく受信された場合，AckVec の
リストから到着したパケットを削除する．受信したか，受信しなかったか，の判断は，Ack
そのもので判断するため，送信側は，AckVec を受信した旨を受信側へ知らせるための Ack of
Ack(AoA)を送信する機構を持つ．以下に AckVec のメカニズムを示す．
①
受信側は，送信側からのデータパケットを受信すると AckVec を作成し，到着パケット
のリストを作成する．
②
作成した AckVec を送信側へ送信する．
③
送信側は，AckVec の受信をすると，受信側へ AoA を返す．
また，後述する「AckVec を受信したときの送信側の動き」に書かれている制御を行う．
④
受信側は，受信した AoA を元に AckVec から受信したパケットを削除する．
AckVec を受信したときの送信側の動き
送信側は，AckVec を受信した際，最後に受け取った Ack 番号の次から三つ margin を作成
する．例えば，最後に受け取った Ack 番号が 20 であった場合，margin は，19，18，17 とな
る．また，仮に margin 内でパケットロスが起きたとしても，送信側は，そのロスについて
考慮しない．次に，margin 作成後の Ack 番号から，例えば，10 番まで AckVec を受け取っ
たとすると，AoA の 10 番までの間に tempvec と，受信した AckVec を比較し，送信側はど
のパケットがロスをしているのかを知ることができる．図 2 の例では，
margin 内の 17 番は，
パケットロスとして考慮せず，12 番にパケットロスが起こったと判断する．
図2. AckVec受信のときの受信側の動き([10]より)
16
2.2.3.4 送信側の制御
送信側では，AckVec を受信するたびに以下のことを行う．
・ パケットロスの確認
・ 平均ロス間隔の算出
・ (21)式を用いて cwnd の算出
・ (23)式を満たしたとき，パケットを送信する．
Seqno. of New Data ≤ cwnd + Unacked Seqno.
(23)
・ RTT，RTO の更新
2.2.3.5 ウィンドウとレートのハイブリッド制御
ウィンドウ制御のみの場合だと，ロス率が高い場合，ウィンドウサイズを下げてしまい，
さらに，ウィンドウサイズが小さい場合，パケットロスを引き起こしてしまう．このよう
に，一度ウィンドウサイズを下げてしまうと元に戻らなくなってしまうということが，[10]
で実験により確認されている．そのため，ウィンドウサイズがある一定以下の場合，レー
ト制御に切り替わるような仕組みをとっている．(TFWC では，cwnd < 2 としている)
2.2.3.6 cwnd jitter
[10]の実験では，キュー制御が，drop-tail の場合，TFWC のスループットは，TFRC のそ
れよりも不安定な結果が得られていた．これは，それぞれのフローにおいて，異なるロス
率を持つことが原因としており，キュー制御を RED にすることで緩和されるとしている．
そこで，TFWC では，RTT ごとにランダムで cwnd jitter と呼ばれるものを加えることにして
いる．ただし，cwnd jitter は，新たに意味の無いパケットを加えるのではなく，将来送るべ
くパケットを前借するものとなっている．
2.2.4 LDA (Loss Differentiation Algorithm) [21]
有線ネットワーク上におけるパケットロスとは，ネットワークが輻輳状態にあることを
意味する．これは，ネットワーク上のパケットの流量がルーターバッファのキャパシティ
を超えてしまい，パケットがドロップしてしまうからである．輻輳に対して，TCP，TFRC
などの輻輳制御を行うプロトコルは，パケット送信レートを適応的に変化させることで，
ネットワーク上のパケットの流量を抑え，パケットロスを緩和させる，といった制御を行
う．
しかし，無線ネットワーク上では，必ずしもパケットロスがネットワークにおける輻輳
を意味するとは限らない．特に，マルチホップ無線ネットワークにおけるパケットロスは，
輻輳のみならず，ランダムなビットエラーや 802.11 のリンク層での再送制御超過によるロ
ス，パケットを送信するためのルートが存在しないルートエラーといった様々な原因が考
17
えられる．そのため，TFRC のような輻輳制御では，パケットロスを検知したら，もし，ネ
ットワークの輻輳状態が原因でなかったとしても，ネットワーク状態が輻輳状態にある，
と判断してしまい，不必要に送信レートを減少させてしまう，といったことが起こってし
まう．
このような問題を解決するために，無線ネットワークで輻輳制御を行う場合，無線特有の
ロスを識別して排除しようとする仕組みを持つ制御や，無線の特性を考慮した帯域推定を
行う制御が提案されている．特に，パケットロスが輻輳によるロスであるのか，無線特有
のロスであるのか，を区別する手法を LDA(Loss Differentiation Algorithm)という．[21]
LDA を用いることによって，パケットロスが輻輳によるロスであると判断された場合，
本来の輻輳制御を行い，パケットロスが無線特有のロスであると判断された場合，レート
を下げない，といった動作を行う．次に LDA 手法の一つである SPIKE 手法について説明を
行う．
2.2.4.1 SPIKE アルゴリズムによる輻輳以外のロスの排除[21]
SPIKE アルゴリズムでは，輻輳によるロスがバッファリング遅延を伴って発生するもの
である，という前提から，片方向遅延 ROTT(Relative One-way Trip Time)を監視し，ROTT の
値によって，パケットロスを輻輳によるロスか，そうでないか，を判別する．以下にその
図，および，図中で示されている Bspikestart ， Bspikeend の閾値の算出方法を示す．
図 3. SPIKE アルゴリズムによる無線特有ロスの排除([20]より)
Bspikestart ， Bspikeend の閾値は以下のようにして算出される．
18
Bspikestart = rott min +α∗ (rott max − rott min )
Bspikeend = rott min +β∗ (rott max − rott min )
(24)
ただし， rott min および rott max はそれぞれ，付近で観測される ROTT の最小値と最大値であ
り，αおよびβは 0 ≤ β≤ α ≤ 1 となる任意の値を設定する．
2.2.5 VTP (Video Transport Protocol) [14]
VTP は，無線特有のロスと輻輳によるロスの判別を行う LDA と，輻輳によるロスが発生
した際に受信レート AR(Achieved Rate)を用いて適切なレート減少量を計算する，といった
機構を組み込んだ End to End のレート制御方式である．
LDA として SPIKE アルゴリズム[21]を採用しており，ランダムロスに対して耐性を持た
せている．また，AR によって急激なレート減少を防止すると同時に，帯域の有効活用を行
う．さらに，仮想的に TCP エミュレートを行い，算出した TCP 推定レートに応じてレート
制御を行うことで，TCP との親和性を保つといったこともなされている．
VTP の具体的なレート制御の様子を以下の図に示す．輻輳によるロスが発生した際，TCP
New Reno が急激にレートを落とすのに対して，VTP は実際に受信可能レート(AR)を参考に
して，ちょうどバッファが溜まらないようなレートを推定し，そのレートまでしか送信レ
ートを減少させない．そして，TCP との公平性を維持するために，TCP が VTP に追いつく
までは送信レートを AR のまま維持し，TCP の送信レートが VTP に追いついたとき，VTP
の送信レートを TCP と等しくなるように増加させる．
19
図 4. VTP におけるレート制御([14]より)
2.2.5.1 具体的なアルゴリズム
SPIKE アルゴリズムでは，(24)式に示されているように片方向遅延 ROTT を用いて，輻輳
によるロスか，そうでないか，を判別していたが，VTP では，実装のしやすさから RTT を
用いて判別を行っている．SPIKE アルゴリズムによって，パケットロスが輻輳によるロス
であると判定されたとき，VTP は送信レートを一定期間 AR によって算出されたレートを
適用する．AR の算出は次の(3.5)式によって計算される．
1
ARk =σ⋅ ARk −1 + (1 −σ) ⋅ ( S k + S k −1 )
2
(25)
ただし，σは１に近い値の平滑化係数であり， S k は単位時間あたりに受信したバイト数で
AR のサンプルである．
この計算によって得られた AR に対して，さらに減少係数 γ(0~1)を乗算したレートにあわ
せる．このレートを維持する時間τは，
τ=
RTTmax
2(1 −τ)
(26)
として算出される．
この固定レートを時間τの間維持した後，(27)式によって TCP の Additive Increase の挙動
をとる．VTP における送信レートは，競合する TCP フローと等しいウィンドウサイズを
ewnd[パケット]として考えると，RTT ごとに 1 パケットずつ増加されるので，
ewnd = R × RTT
ewnd ' = R × RTT + 1
R × RTT + 1
R' =
RTT +ΔRTT
(27)
ここで，RTT の増加幅を一定と仮定すると，
R' =
R + 1 RTT
2 − RTT [−1] RTT
(28)
ただし， R' は更新される次の送信レート[パケット/秒]であり， R は現在の送信レート[パケ
ット/秒]であり， RTT [−1] は前回のラウンドの RTT [秒]である．
20
この式によって，RTT が増加しない状態では，RTT ごとに 1 パケットずつ送信レートが
増えていき，RTT が増加したときには，図 5 のようにレートを減少させる．
図 5 VTP の RTT 変化によるレート推移([22]より)
2.2.6 Hybrid-TFRC [15]
Hybrid-TFRC は，Hybrid-TCP の UDP ベース版として提案されている．Hybrid-TCP と同様
に，loss-mode と delay-mode を持ち，RTT を監視することで，その二つのモードを変化させ
ている．Loss-mode では，VTP と同様の制御を行い，delay-mode では，送信レートを VTP
で算出される AR に合わせる制御を持つ．RTT は競合フローによりパケットのバッファリン
グが発生すると，増加傾向になり，パケットロスが発生することにより，バッファに空き
が発生すると，パケットロス発生時には，一時的に急落し，そののち，バッファリングさ
れるまで増加しない．このように，RTT の増加または，維持（減少）の二つの状態により
loss-mode と delay-mode が切り替わる．つまり，RTT が増加している場合は，loss-mode に
なり VTP と同様の制御をすることで，帯域を確保しようとする，効率性の改善へ，RTT が
減少，または変化しない場合は，delay-mode になり送信レートをその時の公平性が保障され
ている帯域 AR に合わせることで，競合フローとの公平性への改善を狙う．このようにする
ことで，VTP では，競合フローとの公平性がバッファサイズと帯域遅延積(BDP)の等しい場
合のみ得られていなかったことが，Hybrid-TFRC では，それに加え，バッファサイズが BDP
よりも小さい場合も改善されることとなる．
しかしながら，Hybrid-TCP と同様の問題点を抱えており，バッファサイズが BDP よりも
大きい場合，パケットロスが発生したとしても，バッファからパケットが解消されること
はないため，ほとんどの場合において，増加傾向となってしまう．
（RTT が変化しない場合
21
がほとんどない）そのため，バッファサイズが BDP よりも大きい環境下では，Hybrid-TFRC
は，常に loss-mode となり，VTP と同様の制御となってしまう．以下の図 6 に，TCP-Reno,
Hybrid-TCP, VTP, Hybrid-TFRC の動きを示す．
図 6. 各種トランスポートプロトコルにおける cwnd 変化の様子
22
第３章 ストリーミング
本章では，一般的なストリーミングの技術について説明するとともに，ストリーミング
配信における課題点について説明する．
3.1 ストリーミングとは
ストリーミングとは，インターネットなどのネットワークを通じて映像や音声といった
マルチメディアデータを視聴する際に，データを全てダウンロードしてから再生するので
はなく，データをパケット化することで，受信と再生をリアルタイムに行う方式である．
従来，映像や音声などのデータを再生するためには，映像や音声などのデータをすべて
ダウンロードしなければならなかった．一方，ストリーミングでは，送信側では，マルチ
メディアデータを複数のパケットに分割して送信され，受信側では，分割されたデータの
みでデコードを行い，リアルタイムに再生を行うことが可能である．
3.2 IP ネットワーク上でのストリーミング
IP ネットワーク上でストリーミングを実現するには，大まかに二通りの方法が考えられ
る．TCP パケットを用いて，マルチメディアデータを送信するのか，UDP パケットを用い
て，マルチメディアデータを送信するか，である．しかし，実際には，TCP ではなく，UDP
を用いてマルチメディアデータを送信されている．この理由について，TCP と UDP の比較
を行いながら説明する．また，後述するストリーミングにおける課題点から，UDP 上で動
作する RTP(Real-time Transport Protocol)と RTCP(RTP Control Protocol)[11]を用いてのストリ
ーミングについて説明する．
3.2.1 TCP と UDP
TCP と UDP は，IP ネットワークで利用される代表的なトランスポート層プロトコルであ
る．TCP は，コネクション型のトランスポートプロトコルである．TCP では，スリーウェ
イ・ハンドシェイクといった形で通信経路を確保し，Ack 信号を利用することや，ネットワ
ークの輻輳状況に応じて，送信レートを柔軟に変化させる，といった輻輳制御を行うこと
で，相手に確実にパケットを到達させることを保証する．また，もし，パケットロスが起
きた場合であっても，送信側は，再送機構を持つことで，やはり受信側に確実にパケット
を到達させることが可能となる．このように，TCP は，信頼性の高い通信を実現させてい
る．しかし，その制御構造が複雑であるゆえに，プロトコルのオーバーヘッドは大きくな
23
り，ストリーミングのようなリアルタイム通信を行うには不適当であるといわれている．
一方，UDP は，コネクションレス型のトランスポートプロトコルである．UDP では，TCP
とは異なり，輻輳制御機構を持たないため，ネットワークの輻輳状況を考慮せず，一定の
送信レートでパケットを送り続ける動きをする．また，再送制御機構を持たないため，パ
ケットロスが起きたとしても，UDP 単体では，パケットの再送を行うことは無い．このよ
うに，UDP は，輻輳制御機構，再送制御機構を持たないため，プロトコルのオーバーヘッ
ドが小さく，高速な通信が可能となり，ストリーミングのようなリアルタイム通信に向い
ているといわれている．しかし，次に説明するストリーミングにおける課題点を満足する
ためには，UDP 単体では実現できず，上位のアプリケーション，RTP/RTCP が必要となって
くる．
3.2.2 ストリーミングにおける課題点
ストリーミングを行う上で，プロトコルには，高速性のみが必要となってくるわけでは
ない．以下に，具体的なストリーミングにおける課題点をまとめる．
メディア同期
メディア同期には，メディア内同期，メディア間同期，システム同期といった三階層同
期が存在する．
メディア内同期とは，単一メディア，例えば，音声のみ，動画のみ，の同期再生を指す．
これは，ネットワーク状況，ジッタによって送信パケットを一定間隔で送り出していたと
しても，到着時間間隔が一定でなく，揺らいでしまうといった問題があげられる．放送系
のような片方向通信であれば，受信側に大容量のバッファを用意することで緩和されるが，
電話のような双方向通信，リアルタイム通信を考える際，受信側に大容量のバッファを設
けることは妥当ではない．そのため，バッファ容量が小さくても適切に再生できるために，
一定間隔に再生時間を復元する必要がある．これは，送信時のタイムスタンプを利用する
ことで対策が採られている．
メディア間同期とは，複数メディア，例えば，音声と動画，の同期再生を指す．一般的
に，単一メディアの同期再生が可能となっても，メディア間同士では，同期が取れておら
ず，リップシンクのずれとして現れてしまう．そのため，NTP(Network Time Protocol)のよ
うな新たな第三者の基準となる時間軸を用意し，メディア再生時間に補正をかけることで，
メディア間で同期再生を可能としている．
システム同期とは，複数端末間で，同期を取ることを指す．これは，必ずしも必要とさ
れていることではないが，NTP(Network Time Protocol)といった基準となる時間軸を用意し，
端末ごとに時刻合わせをすることで対策が採られている．
24
パケットロス対策
UDP では，パケットロスが起きた場合，パケットの再送などは行わない．しかし，マル
チメディアデータを受信し，再生するとなると，パケットがロスした箇所をそのままにし
ておくと，エラーの伝搬が起きてしまい，受信した動画像が乱れてしまう問題がある．そ
のため，パケットロスが起きた箇所を復元できる FEC パケットのような制御，受信パケッ
トに際同期情報を入れることで，パケットロスが起きた箇所を飛ばして，次のパケットか
ら復号を試みる，といったネットワーク面と画像面の両面から対策が採られている．
輻輳制御
一般的に，配信する動画像の質を上げると，動画像のデータ量が増えてしまい，ネット
ワークの輻輳が起きやすくなってしまう．一方，配信する動画像のデータ量を下げると，
動画像の質が下がってしまう，といったトレードオフの問題がある．そのため，ネットワ
ークの状況に応じた適応的なレート制御を行うことで QoS の確保を行うことを，TFRC[9]
では提案されている．
3.2.3 RTP(Real-time Transport Protocol)と RTCP(RTP Control Protocol)[11]
UDP 単体では，制御構造の単純さゆえに，ストリーミング特有の課題を解決することが
できないことから，その上位層に位置する RTP/RTCP を用いて，メディア同期対策，パケッ
トロス対策を行う．具体的には，メディア同期再生のために，RTP タイムスタンプ，NTP
タイムスタンプを利用し，パケット廃棄対策では，パケットごとにシーケンス番号を与え
ることで，パケット廃棄を検知し，RTP に，ペイロードフォーマット拡張を用意すること
で，再同期情報を書き込む，といった拡張性を持たせている．RTP と RTCP は，リアルタイ
ムアプリケーション特有の層である，アダプテーション層で実装されており，アプリケー
ション層とトランスポート層の間に位置する．その様子を，図 7 に示す．次に，RTP と RTCP
の詳細な説明を行う．
25
アプリケーション層
トランスポート層
ビデオ
オーディオ
アダプテーション
UDP or TCP
ネットワーク層
IP
リンク・物理層
各種ネットワーク
RTP/RTCP
図 7. アダプテーション層の様子
3.2.3.1 RTP (Real-time Transport Protocol)[11]
RTP は，IP ネットワーク上で，end-to-end で，映像や音声などのリアルタイム性のあるデ
ータを，送るためのプロトコルである．ほぼ全ての VoIP 関連製品は，RTP を利用して音声
情報を IP ネットワーク上へ送出している．また，RTP は，音声や動画などのリアルタイム
データを運ぶためのプロトコルとして IETF，ITU で標準化されている．RTP の特徴を以下
にあげる．
パケット化
動画像圧縮することで，映像符号化データや，音声圧縮することで，音声符号化データ
を，パケット転送に適した長さのブロックに分割する．
メディア内同期
メディア内同期対策として，RTP では，RTP タイムスタンプを用いることで，ジッタに
より到着時間が揺らいだとしても，再生時刻の復元を可能にしてくれる．
パケットロス対策
パケットロス対策として，RTP では，パケットごとにシーケンス番号を設定している．
このシーケンス番号を見ることで，もし，シーケンス番号に不連続性が見られたら，パケ
ットロスが発生していると判断することができ，ロス検出可能となる．また，ペイロード
フォーマット拡張として拡張ヘッダを設けることで，メディアフォーマットごとに RTP パ
ケットのカスタマイズを可能にしている．
26
RTP パケットを UDP によって送信する様子を図 8 に示す．
映像の入力
映像の再生
SSRC識別子
送信側
受信側
動画像符号化
動画像復号化
クロック同期
RTP送信処理
RTP受信処理
UDP送信
UDP受信
パケット
IPヘッダ
UDPヘッダ
RTPヘッダ
データ
図 8. RTP を用いた送信の様子([23]より)
次に，RTP ヘッダの構造を説明する．RTP ヘッダは，図 9 に示すような構成になってい
る．バイトオーダは，最上位バイトから順に格納されるネットワークバイトオーダとなっ
ている．
v=2
P X
CSRC
カウント
M
パケットタイプ
シーケンス番号
タイムスタンプ
SSRC 識別子
CSRC 識別子(セッション参加者リスト)
ペイロードフォーマット拡張
データ
図 9 RTP ヘッダ構造([11]より)
27
・ v：RTP のバージョン識別子．１ビット用意されている．RFC1889，RFC3550 で規定さ
れているバージョンは，
「2」である．
・ P：パディング設定フラグ．1 ビット用意されている．この部分が 1 となっていたとき，
RTP パケットの終端にパディングバイトが追加されている．パディングバイトは，ペイ
ロードの一部分ではない．
・ X：拡張ヘッダ設定フラグ．1 ビット用意されている．この部分が 1 となっていたとき，
RTP ヘッダの後に拡張ヘッダが続く．
・ CSRC カウント：4 ビット用意されている．
・ M：マーカービット．1 ビット用意されている．RTP ストリーム中で特殊なパケットで
あることを示すために使用される．RTP のペイロードタイプによって異なる．
・ パケットタイプ：1 ビット用意されている．パケットに含まれるメディアフォーマット
の種類を識別する．
・ シーケンス番号：16 ビット用意されている．初期値は乱数によって定められる．
・ タイムスタンプ：32 ビット用意されている．パケットに含まれるデータの発生時間が記
述されている．
・ SSRC 識別子：同期送信元識別子．32 ビット用意されている．送信者の ID，セッション
内で送信元を認識するための乱数値．
・ CSRC 識別子：送信関係者を表す識別子．32 ビット×(0~15)の範囲で用意されている．
・ ペイロードフォーマット拡張：各種ペイロードタイプによって任意に拡張される．
・ データ：動画像や音声などのペイロード
3.2.3.2 RTCP (RTP Control Protocol)[11]
RTCP は，RTP と組み合わせて使われ，データのフローチェックや送信者受信者間の情報
を伝達するためのプロトコルであり，RTP でデータを送受信するためのセッションを制御
するサブプロトコルとして位置づけられている．また，データ転送の遅延やロス率などの
ネ ッ ト ワ ー ク 状 況 を 得 る プ ロ ト コ ル で あ り ， 定 期 的 に RTCP-SR(Sender Report) と
RTCP-RR(Receive Report)が送受信される．RTCP パケットは，RTP パケットと同様に UDP
パケットとして送られるが，RTP と違ってマルチメディアデータといったものを転送する
ことは無い．RTCP には，以下の五種類がある．
・ RR(Receiver Report)
RR は，受信者での受信品質に関する情報を伝えるために利用される．
・ SR(Sender Report)
SR は，送信者からのストリームに関する情報を伝える．
28
・ SDES(Source Description)
RTP セッションへの参加者の識別や，電子メールアドレス，電話番号といった細く情報
を伝える．
・ BYE
参加者がセッションを抜けたことを通知する．
・ APP
アプリケーションが独自拡張を行えるように用意されている．
続いて，RTCP のヘッダ，Sender Report，n 番目の Report block の構造について以下に示す．
v=2
P
RC
PT=SR=200
パケット長
送信元 SSRC 識別子
図 10 RTCP コモンヘッダ([11]より)
NTP タイムスタンプ (MSB)
NTP タイムスタンプ (LSB)
RTP タイムスタンプ
送出パケット数
送出バイト数
図 11 RTCP-Sender Report のヘッダ構造([11]より)
SSRC 識別子 #n
瞬時廃棄率
累積廃棄パケット数
シーケンス番号の最大値
ジッタ遅延
最新のSR受信時のNTP タイムスタンプ (LSR)
LSRから現在までの遅延(DLSR)
図 12 RTCP-Receive Report のヘッダ構造([11]より)
29
3.2.4 VIC (Video Conferencing Tool) [5]
ストリーミング配信の参照ソフトウェアとして，古くから VIC が知られている．VIC は，
テレビ会議用アプリケーションとして，カリフォルニア大学バークレー校と連携して，ロ
ーレンス・バークレー国立研究所のネットワーク研究グループによって開発された．VIC
は，テレビ会議用アプリケーションのみならず，音声版の RAT，セッションディレクトリ
の SDR と共に，RTP/RTCP や IP マルチキャストの実装参照コード，XCAST などの各種の
機能拡張などに幅広く活用されている．また，開発環境として，Linux，Solaris，Sun OS の
みならず，Windows 版も用意されており，さらにそれぞれの IPv4 用，IPv6 用というように，
幅広く対応している．最近では，主流の動画像圧縮技術である H.264 へ拡張した vic-h.264[24]
や，輻輳制御組み込みである vic-cc[18][25]の検討が進められている．特に後者の vic-cc は，
既存の vic に対して，TCP に親和性を有する輻輳制御技術である TFRC[9]と TFWC[10]の組
込みを図る試みである．
30
第 4 章 無線 LAN におけるスループットおよび遅延理論算出
第 4 章では，IEEE802.11 無線 LAN(802.11 無線 LAN)におけるスループットおよび遅延を
算出するための理論モデル式を紹介する．理論モデル式では，無線 LAN のアクセス制御方
式である CSMA/CA を利用しており，1 パケットを送信するのに，どれぐらいの時間がかか
ったのかを理論的に算出し，それを元に，スループット，遅延を算出する．算出理論式と
して，広く知られている Bianchi のスループットモデル式[27]，また，リトルの定理を利用
した遅延モデル式を紹介する．
4.1 無線 LAN アクセス制御方式
802.11 無線 LAN では，同一の無線チャネルを複数端末で共有するため，アクセス制御機
能が実装されている．そのアクセス制御機能として，CSMA/CA(Carrier Sense Multiple Access
with Collision Avoidance)が採用されており，DCF(Distributed Coordination Function)におけるア
クセス制御プロトコルで利用されている．
そもそも 802.11 無線 LAN では，自律的にパケットの送信タイミングを決定する DCF と，
集中制御によるアクセス制御機能である PCF(Point Coordination Function)が実装されている．
PCF はオプションとして用意されているのみであるため，ここでは，詳細は述べず概要
のみとする．PCF では，無線セル内において，基地局（アクセスポイント）が各端末に順
番にポーリング信号を送信し，その信号を受け取った端末のみがフレームの送信が可能と
なる．このように，PCF は，ポーリングに基づく集中制御によるアクセス制御方式である．
基地局からポーリング信号を送信するため，端末同士でフレームの衝突が発生しないとい
う利点がある．ただし，ポーリング信号同士が衝突する可能性は残る．
次に，802.11 無線 LAN における代表的なアクセス制御である DCF を述べる．DCF は，
自律分散制御となっており，フレームの衝突をできる限り回避するために，無線チャネル
の使用状況を見て（キャリアセンス）フレームを送信するかどうか決定する CSMA/CA ア
クセス制御が利用されている．CSMA/CA では，フレーム送信を送信する際に，送信端末は
ほかの端末が送信を行っているかどうかを知るために，キャリアセンスを行い，誰も送信
を行っていないことがわかると，ある期間(DIFS+Backoff)待機したのち，フレームの送信を
行う．もし，ほかの端末が送信を行っていた場合は，ほかの端末が送信を終わるまで待機
することとなる．
4.2 無線 LAN におけるスループットおよび遅延算出
前節で述べたように，802.11 無線 LAN では，送信フェイズが事細かに定義されている．
しかし，詳細な定義があるため，理論的に，1 つのパケットが送信にかかる時間を算出する
ことが可能となる．その結果，理論的に 802.11 無線 LAN レベルでの送信スループットおよ
び遅延を算出することが可能となる．次に，単純な 1 つの送信のみの場合を例に示す．そ
31
もそも，スループットとは，単一時間に，どれだけのデータ長を送信することができるか，
ということを意味する．つまり，あるデータ長のパケットを送信するのにかかった時間で
割ることで算出される．802.11 無線 LAN において，一つのパケットが送信されるのにかか
る時間を以下の図 13 に示す．今，単純に，RTS/CTS が利用されない状況を考える．キャリ
アセンスのため，送信権を獲得したのち，DIFS+Backoff 時間待機の後，データパケットが
送信される．
今パケット長を Data [Byte]，802.11 無線 LAN の送信ビットレートを Bitrate Mbps
モードであったとすると，1 つのデータパケットそのものを送信するのに Data*8/Bitrate 時
間かかることとなる．データ送信完了後，MAC 層レベルでの Ack が SIFS 後に受信される．
Ack パケット長を Ack [Byte]であったとすると，Ack パケットを受信するのに，Ack*8/Bitrate
時間かかることとなる．以上のように，一つのパケットを送信するフェイズ T は，以下の
ように算出されることとなる．
T = DIFS + Backoff + Data * 8 / Bitrate + SIFS + Ack * 8 / Bitrate
その結果，スループットは，以下の式のように算出される．
Throughput = Data * 8 / T
RTS/CTS を利用した場合も T の式に RTS,CTS 時間が加わるだけで，同様であるため，こ
こでは割愛する．また，遅延についても，もしパケットがバッファリングされなければ，
送信に T 時間かかり，それに空気中をパケットが飛んでいるフライトタイム時間が加算さ
れるだけである．
図 13. 802.11 無線 LAN において 1 パケットを送信するのにかかる時間[28]
これまでは非常に単純なモデルについて述べてきたが，実際には，端末が 1 台しかない
32
というわけではなく，多数の端末が存在する．そのため，ほかの端末が送信している期間，
Backoff 期間をモデル化しなければならない．それに加えて，CSMA/CA による待ち時間が
存在したとしても，アプリケーション層でそれを意識しないため，パケットは連続的に生
成される．そのような状況下では，パケットはバッファリングされ，バッファリング遅延
が発生することとなる．このような現実のモデルを考えた場合，非常に難しい問題となる．
4.3 マルコフモデルを利用したスループット算出モデル式 [27]
送信端末が 1 台ではなく，複数台存在した場合，CSMA/CA によりそれぞれの端末は待ち
時間が存在し，Backoff 時間も指数的に増加していく．このような複雑な状況下における理
論スループット算出モデル式である Bianchi のモデル式を紹介する．Bianchi のモデル式では，
送信権を獲得するまでの Backoff 状態をマルコフモデルにより表現している(図 15)．モデル
式を算出するにあたり，以下のことを仮定している．
・ideal channel conditions
(隠れ端末などが存在しない状況)
・a fixed number of stations
(端末数が途中で増減しない)
・always nonempty in the transmission queue(= saturation conditions)
(必ず送信するパケットが存在する)
→上位層から見た場合，バッファリング遅延を考慮しているわけではない
4.3.1 パケット送信確率算出モデル式
まずは，マルコフモデルを利用して，１端末から送信されるパケットの送信確率 τ を算出
する．
<CW に関する議論>
W = CWmin
CWmax = 2 m W
(29)
⇒ Wi = 2 i W (i ∈ (0, m))
（m は，衝突後の再送回数）
k ∈ (0, Wi − 2) i ∈ (0, m) (1)
P{i.k | i, k + 1} = 1
⎧
⎪ P{0, k | i,0} = (1 − p ) / W k ∈ (0, W − 1) i ∈ (0, m) (2)
⎪
0
0
⎨
⎪ P{i, k | i − 1,0} = p / Wi k ∈ (0, Wi − 1) i ∈ (1, m) (3)
⎪⎩ P{m, k | m,0} = p / Wm k ∈ (0, Wm − 1)
( 4)
(30)
マルコフモデルを利用した Window Size の遷移図を式で表すと上記の(30)式になる．(30)式
を詳細に見ると，上から次のようなこととなる．
33
・ back off counter が 100%の確率で左に１ずつ遷移していくことを意味する．
・ 送信後，再度 window size の値をそれぞれ確率 (1 − p ) / W0 で設定される．
・ 衝突後の window size の値をそれぞれ確率 p / Wi で設定される．
・ 最大再送回数に達した場合，それ以降は常に，最大再送回数時の window size の値にそ
れぞれ確率 p / Wm で遷移する．
⎧
bi −1, 0 ⋅ p = bi ,0 → bi ,0 = p i b0,0
0 < i < m (5)
⎪
pm
⎨
(6)
⎪bm −1,0 ⋅ p = (1 − p)bm ,0 → bm ,0 = 1 − p b0, 0
⎩
(31)
次に，(30)式を整理してみる．
--------------------------------------------------------整理する前に，まず，単純なマルコフ連鎖のモデルを考える．単純なマルコフ連鎖モデル
では，それぞれの状態遷移確率は次のように書くことができる．
1
b0 + b1
W
1
b1 = b0 + b2
(32)
W
…
1
bk = b0 + bk −1
W
b0 =
(32)より， b0 と bk の関係式を導く．
b0 =
1
b0 + b1
W
1
b0 + b0 + b2
W
1
1
b0 + b0 + … + b0 + bk
W
W
1
W
1
=
W
k
= b0 + bk
W
=
⇔ bk =
W −k
b0
W
(33)
--------------------------------------------------------(33)式を利用して，(30)式を整理する．
(ⅰ) 0<i<m のとき，
34
bi −1, 0 =
bi ,k
p
⋅ bi −2, 0より
Wi
W −k
= i
p ⋅ bi −1,0
Wi
(34)
(ⅱ)i=m のとき，
bm ,0 =
p
⋅ (bm −1, 0 + bm ,0 )より
Wm
W −k
= m
p ⋅ (bm −1,0 + bm, 0 )
Wm
bi ,k
(35)
(ⅲ)i=0 より，
b0, 0 =
bi ,k
1− p
(b0,0 + b1, 0 + …bm ,0 )より
W0
m
W −k
= 0
(1 − p )∑ b j , 0
W0
j =0
(36)
以上より，
bi ,k
⎧ (1 − p)∑ b j ,0
i = 0 (7 )
Wi − k ⎪
0 < i < m (8)
p ⋅ bi −1, 0
=
⋅⎨
Wi
⎪ p ⋅ (b
(9)
m −1, 0 + bm , 0 ) i = m
⎩
(37)
また，
m
m
i =0
i =0
b0, 0 = (1 − p )∑ bi ,0 ⇔ ∑ bi ,0 = b0,0 /(1 − p)
(38)
が成立することから，
(38)式は一つにまとめられ，
bi ,k =
Wi − k
bi , 0 i ∈ (0, m) k ∈ (0, Wi − 1)
Wi
となる．
システム全体の状態遷移確率を全て足すと 1 となることから
m Wi −1
∑ ∑b
i =0 k =0
i ,k
= 1 (40)が成立し，
(39)の両辺に Σ を足すことで，
35
(39)
m Wi −1
m Wi −1
Wi − k
bi , 0
Wi
k =0
1 = ∑ ∑ bi ,k =∑ ∑
i =0 k =0
i =0
⎛
(2 p ) m ⎞
1
⎟⎟ +
(41)
]
[W ⎜⎜ ∑ (2 p ) i +
1− p ⎠ 1− p
2
⎝ i =0
2(1 − 2 p )(1 − p )
∴ b0,0 =
(1 − 2 p )(W + 1) + pW (1 − (2 p ) m )
=
b0,0
m −1
ここで，送信確率 τ は，図 15 における back off counter=0 になったときの確率であるの
で，
m
τ= ∑ bi ,0 …(42)であるので，
i =0
(39),(41),(42)から，
τ=
2(1 − 2 p)
(1 − 2 p)(W + 1) + pW (1 − (2 p) m )
(43)
結果，送信確率 τ は，衝突確率 p，window size(W)，最大再送回数 m で表すことができる．
4.3.2 スループット算出モデル式
次に，上記で算出した送信確率 τ を利用して，Saturation Throughput のモデル式を算出す
る．
Throughput(S)の算出について，基本となる式はこれまでと同様の考え方(44)であるので，説
明は省略する．
S=
E[ payload transmitted in a slottime]
E[length of a slottime]
(44)
次に，１つの端末が送信を行い，かつ成功する勝率を考える．
Ptr: 少なくとも１つの端末が送信する確率
⇔1-(n 個の端末がどれも送信しない確率)
Ptr = 1 − (1 −τ) n
(45)
ここで，
Ps: 1 つの端末が送信し，さらに，成功する確率とすると，
n
C1τ(1 − τ ) n −1 = Ptr ⋅ Ps
⇔ Ps =
nτ (1 − τ ) n −1
1 − (1 − τ ) n
(46)
E[p]を平均 payload サイズとすると，(46)式の分子は， Ptr ⋅ Ps ⋅ E[ P] となる．
・σ: 空き slottime
誰も送信しないので，(1-Ptr)σ
36
・Ts: 送信（かつ成功）に必要な slottime
端末一つが送信成功するので，PtrPsTs
・Tc: collision による再送に必要な slottime
一つ以上の端末が送信し，かつ一つの端末の送信が失敗するので，Ptr(1-Ps)Tc
以上より，(44)式の分母は，
(1 − Ptr )σ+ PtsPsTs + Ptr (1 − Ps)Tc
とかける．
∴S =
PtrPsE[ P]
(1 − Ptr )σ+ PtsPsTs + Ptr (1 − Ps)Tc
(47)
(19)式から最大スループットを算出することを考える．
PtrPsE[ P]
(1 − Ptr )σ+ PtsPsTs + Ptr (1 − Ps)Tc
E[ p ]
=
1
(
− 1)σ+ Tc
Ptr
Ts − Tc +
Ps
S=
となり，E[p],Ts,Tc,は固定値であるので，
(
1
− 1)σ+ Tc
Ptr
=0
Ps
(48)
となればよい．
⎧Ts = H + E[ P] + SIFS +δ+ ACK + DIFS +δ
(49)
⎨
Tc = H + E[ P] + DIFS +δ
⎩
なお， H = PHYhdr + MAC hdr δ：伝送遅延である．
図 14. Bianchi モデル式によるスループット推移[27]
37
図 15. バックオフをマルコフモデルにより表現[27]
4.4 リトルの公式による遅延算出モデル式 [29]
802.11 無線 LAN を利用した際の end-to-end 遅延がどれぐらいになるのか，その理論算出
モデル式について説明する．もし，パケットが MAC 層でバッファリングしなければ，また，
ほかの端末が存在しなければ，すでに述べたように，end-to-end 遅延は，フライトタイム＋
CSMA/CA によるパケット送信時間となる．ただし，実際には，バッファリング遅延やほか
の端末による送信待ち時間が発生する．では，そのような遅延はどのように理論算出する
のか．ここでは，リトルの公式を利用した理論算出モデル式を紹介する．
4.4.1 リトルの公式
実際に end-to-end 遅延算出モデル式を紹介する前に，リトルの公式を説明する．
リトルの公式は，あるシステムに入ってくる客の割合 λ，一人の客があるシステムに滞在
する時間 W，あるシステム内に存在する客の平均人数 L が与えられるとすると，
L = λW
が成立する．
[証明]
38
N (t ) : 期間 t の間に到着した客の量
N d (t ) : 期間 t の間にシステムから客が出ていく量
L(t ) : システム内に滞在している客の量
とすると，
L(t ) = N (t ) − N d (t ) ( N (t ) ≥ N d (t ) )
λ = lim
t →∞
N (t )
t
(システムの平均到着数)
1 n
Wi
∑
n →∞ n
i =1
W = lim
(システム内での平均滞在時間)
t
1
L( s )ds
t →∞ t ∫
0
L = lim
(システム内にいる客の時間平均数)
N (t ) ≥ N d (t ) より，
N d (t )
t
N (t )
0
j =1
∑ W j ≤ ∫ L(s)ds ≤
j =1
d
∑W
j
が成立し，
t
1 N (t )
1
1 N (t )
W
≤
L
s
ds
≤
(
)
∑ j t∫
∑W j となる．
t j =1
t j =1
0
ここで，t→∞とすると，
両辺は λW となり，真ん中は L となるので，
L = λW が成立する．
4.4.2 リトルの公式を利用した遅延算出モデル式[29]
それでは，リトルの公式を利用した end-to-end 遅延算出モデル式について説明する．リト
ルの公式を利用すると，end-to-end 遅延算出モデル式は以下のように表現できる．
N active = λsys ⋅ T
(50)
ただし， N active : active ノード数，λsys : システムのパケット受信率， T : 平均送信時間
ここで，active ノード数は，
39
N active = N − N idle
(51)
= N − N ∗ Pidle
システムのパケット受信率は，
λsys = N idle ⋅λ
= N ∗ Pidle ⋅λ
(52)
以上より，(50),(51),(52)より
T=
=
N active
λsys
N (1 − Pidle )
N ⋅ Pidle ⋅λ
T =(
1
1
− 1) ⋅
Pidle
λ
∴ Delay = T − Tack − SIFS −δ (53)
となる．図 16 に，(53)式と Offered load との関係を示す．
図 16. リトルの公式を利用したモデル式による遅延の推移[29]
40
第 5 章 動画像配信向け適応レート制御方式の性能評価
第 5 章では，これまで紹介してきた UDP ベースの適応レート制御方式である TFRC, VTP,
Hybrid-TFRC を実アプリケーションである VIC に実装し，有線無線混在ネットワーク上で
の性能評価を行う．また，それに加えて，アプリケーション層に位置する画像圧縮技術面
において，ネットワーク状況に応じて画質を変化させた際の QoS 評価も行う．
5.1 VIC への適応レート制御実装について
5.1.1 VIC への適応送信レート制御実装
先に述べたように，VIC 単体では，ネットワーク状況に応じて送信レートを変化させる，
または，動画像圧縮率を変化させる，といった適応レート制御は実装されていない．その
ため，代表的な UDP ベースの適応レート制御方式である TFRC, VTP, Hybrid-TFRC を VIC
へ実装を行う．UDP では，送信から受信へパケットの送信を行うと，TCP のように確認応
答パケット（Ack パケット）の返信は行わない．そのため，ここでは，RTP/RTCP で利用さ
れている RTCP パケットの Sender Report(SR)および Receiver Report(RR)を利用してネットワ
ーク状況を観測する．実際に TFRC, VTP, Hybrid-TFRC で送信レートを算出するためには，
RTT およびパケットロス率といったパラメーターを取得する必要があるが，この取得に前
述した SR, RR を利用する．つまり，SR を送信した時間をタイムスタンプで取得し，SR が
受信側に到着した時間を取得する．同様に，RR を送信，受信時間を取得し，それぞれの差
分を合計すると，ある瞬間での RTT が算出される．また，受信側でデータフレーム（動画
像データ）の一定期間における受信率を計測し，RR を送信側へ返信する際に，その情報を
載せることで，送信側でパケットロス率の取得が可能となる．このようにして，RTCP を利
用して RTT およびパケットロス率を取得する．具体的な流れを図 17 に示す．ただし，単純
に算出された RTT を利用するのではなく，RTT の変動を抑えるために，(54)式で示すよう
な加重平均を利用する．
41
図 17. RTCP-SR および RR を利用した RTT，パケットロス率の取得
RTT = RTTsample × 0.1 + RTT × 0.9
(54)
5.1.2 VIC への適応画像圧縮レート制御実装
これまでは，トランスポート層における適応レート制御実装を述べてきたが，トランス
ポート層のみでなく，アプリケーション層における適応画像圧縮レート制御実装について
説明する．適応画像圧縮レート制御は，ネットワーク状況に応じて，最適な画質に変化さ
せる制御である．具体的には，ネットワーク状況を知るために，トランスポート層で算出
された送信レートを参照し，動画像圧縮のターゲットレートに設定する．例えば，ネット
ワーク状況に余裕がある場合，高い送信レートが算出され，送信レートが高いため，動画
像が高画質なものとなる．一方，ネットワーク状況に輻輳が起きている場合，送信レート
は低くなり，動画像の画質も低いものとなる．このようにすることで，ネットワーク状況
に輻輳が起きている場合でも，画質は劣化することになるが，ビットレートを抑えること
ができるため，フレームレートをある水準を保つことができる．
実際に，画質を変化させるために，本稿では，量子化パラメーターを変化させている．
量子化パラメーターはアプリケーションにより定義の仕方が異なるが，VIC では，Quality
値として定義されている．具体的には，1~30 の値の範囲を持ち，値が低いほど高画質にな
り，高いほど低画質となる．送信レートと Quality 値との関係を以下の図 18 に示す．
42
図 18. 送信レートと Quality 値との関係
5.1.3 VIC への各種適応レート制御実装について
これまで，トランスポート層およびアプリケーション層における具体的な実装アルゴリ
ズムを述べてきたが，実際の VIC への実装として，TFRC, VTP, Hybrid-TFRC を実装したも
のを，本稿では，VIC-TFRC, VIC-VTP, VIC-H-TFRC と命名し，利用している．なお，アプ
リケーション層における画質適応レート制御については，VIC-TFRC のみに適応しており，
後の章で説明する VIC-TFRC, VIC-VTP, VIC-H-TFRC における性能評価比較においては，ト
ランスポート層にのみの性能評価であり，アプリケーション層における制御は行っていな
い．
5.2 トランスポート層およびアプリケーション層における適応レート制御実装
とその性能評価
本章では，VIC へ適応レート制御実装として，適応送信レート制御として TFRC を，適応
画像圧縮レート制御を実装した，VIC-TFRC の実機を利用した性能評価を行う．
5.2.1 実験環境
性能評価実験として，実験環境を以下の表 1 に示す．
表 1: 実験環境
43
VIC，コーデック vic-1.15，H.261/H.263+
動画像
mobile&calendar(CIF)
競合 TCP
TCP-Reno
使用マシン
ThinkPad G50 (Celeron M 1.46GHz)
OS
Fedora 12
無線 LAN AP
Air Station Pro (802.11bg)
今回は，VIC のバージョン 1.15 を，VIC に含まれている動画像圧縮技術として，H.261
を利用しているが，H.263+，H.264 にも同様の適応ができると考えられる．また，用いた動
画像は，mobile&calendar で，カレンダーの前をおもちゃの機関車が横切るような動画像と
なっており，動画像圧縮効率が非常に悪いことが知られている．また，今回利用した無線
LAN 規格は，802.11g を利用した．以下に，用いた動画像 mobile&calendar の 1 フレームを
示す．
図 19. Mobile&calendar の様子
5.2.2 実験トポロジーおよび実験シナリオ
本章では，性能評価実験に利用した実験トポロジーおよび実験シナリオについて説明す
る．実験トポロジーでは，3 台の Linux ノート PC を利用しており，2 台は，送信側，1 台は，
受信側として利用している．また，送信側は，Access Point(AP)と無線ネットワークで接続
し，AP と受信側を有線ネットワークで接続するという有線無線混在ネットワーク環境下と
44
なる．AP と受信側の間に，IP 網ハードウェアエミュレーターである Packet Storm を挟み，
遅延を 10ms 発生させることで，より実環境に近い環境を想定している．送信側では，1 台
から VIC を利用して UDP パケット（ビデオパケット）を，もう 1 台から，iperf を利用して，
競合フローである TCP フローを送信している．それぞれ，送信の開始タイミングは，UDP
パケットは開始から常に送信を行い，TCP フローは，UDP フロー開始後 30 秒後に送信を行
い，120 秒間送信を行う．結果，UDP と TCP は，30~150 秒の間，競合していることとなる．
予備実験により，利用可能帯域は，9Mbps であったことから，利用可能帯域は 9Mbps を
想定している．また，初期条件として，UDP の初期送信レートは 6144kbps，フレームレー
ト 30fps，Quality 値 10 としている．
以下に実験で利用した実験トポロジーを図 20 に示す．
Tx1
Rx
Packet Storm
10/100[ms]
AP
wireless
Tx2
wired
図 20. 実験トポロジー
5.2.3 客観画質評価手法
受信動画像評価として，客観画質評価手法として知られる PSNR を利用している．PSNR
では，参照画像と劣化画像との差分を算出することで，劣化度合いを示す．以下に，算出
式を(55)式に示す．
1 x −1 y −1
MSE =
∑∑ X (i, j ) − X ' (i, j )
x × y i =0 j =0
PSNR = 20 × log10 (
45
255
MSE
)
(55)
2
5.2.4 単独配信実験
まずは，競合フローが存在しない場合の性能評価として，単独配信実験を行う．実験結
果として，評価する点は，受信レート，フレームレート，パケットロス，および，受信動
画像の四点に着目する．
VIC-TFRC では，オリジナルの VIC と比較して，ネットワーク状況に余裕があると，送
信レートを高くし，高画質の動画像を配信することが可能となる．実際に，初期条件での
mobile&calendar の送信レートは 5 Mbps 程度となり，利用可能帯域 9 Mbps よりも低く，ネ
ットワークに余裕があることがわかる．その結果，トランスポート層で送信レートを高く
設定でき，動画像の画質もあげることとなる．ただし，TFRC が TCP と同様の制御である
ため，意図的にパケットロスを発生させることとなり，パケットロスは，オリジナルの VIC
と比較して増加してしまう．パケットロスが発生すると，送信レートを下げ，再度，送信
レートをあげていく動きとなるため，受信レートは振動してしまうこととなる．
以下に，実験結果を図 21~24 に示す．
vic-tfrc
vic-tfrc2
14000
Throughput[kbps]
12000
10000
8000
6000
4000
2000
0
0
20
40
60
80
100
120
140
Time[s]
図 21. VIC と VIC-TFRC における受信レート比較
46
160
18
vic_tfrc_1flow
vic_1flow
400
300
200
100
0
0
20
40
60
80
100
120
140
160
180
Time[s]
図 22. VIC と VIC-TFRC におけるパケットロス比較
40
FrameReceive[frames]
loss_packet[packets]
500
vic-tfrc
vic
35
30
25
20
15
10
5
0
0
20
40
60
80
100
120
140
160
Time[s]
図 23. VIC と VIC-TFRC におけるフレームレート比較
47
180
35
33
31
29
27
25
23
21
19
17
15
vic-tfrc
vic
0
1000
2000
3000
4000
図 24. VIC と VIC-TFRC における受信動画像 PSNR 比較
表 2：VIC と VIC-TFRC における受信動画像ステータス比較
受信動画
vic-tfrc
vic
総フレーム数
3871
3680
ロスフレーム数
86
0
実受信フレーム総数
3785
3680
送信時間
133
123
平均再生フレーム数
28.46
29.92
5.2.5 動画像・TCP 競合配信実験
次に，競合フローとして TCP フローが存在するシナリオにおける実験結果を述べる．
先の単独配信実験と異なり，競合フローが存在することから，適応レート制御を持たな
いオリジナルの VIC において，ネットワーク状況に輻輳が起きたとしても，送信レートを
下げるといったことは行わず，その影響がパケットロスとして現れることとなる．また，
画質を変化させることは行わないため，受信レートが低くなるにも関わらず，画像ビット
レートは高いままとなり，その影響がフレームレートの劣化として現れることとなる．た
だし，受信動画像評価を行うと，画質を変化させていないため，1 フレームが完全に描ける
ようなものについては，一定画質を維持するが，パケットロスの影響により，1 フレームが
48
完全に描けないため，PSNR にばらつきが生まれることとなる．
一方，VIC-TFRC では，適応レート制御機能が実装されているため，競合フローが存在し，
ネットワークが輻輳したとしても，ネットワーク状況に応じて最適な送信レート制御が可
能となっている．そのため，送信レートは，単独フロー時よりも落ちることとなるが，パ
ケットロスを比較してみると，オリジナルの VIC と比較して，パケットロスは抑えられる
こととなる．ただし，送信レート制御が意図的にパケットロスを発生させてしまうことか
ら，パケットロスがなくなる，ということはない．また，画質を変化させることから，送
信レートが下がったとしても，動画像ビットレートを下げるため，フレームレートはある
水準を維持することが可能となる．
以下に，実験結果を図 25~29 に示す．
vic-tfrc
vic
reno-tfrc
reno-vic
14000
Throughput[kbps]
12000
10000
8000
6000
4000
2000
0
0
20
40
60
80
100
120
140
160
18
Time[s]
図 25. VIC と VIC-TFRC における受信レート比較
loss_packet[packets]
500
vic_tfrc_2flow
vic_2flow
400
300
200
100
0
0
20
40
60
80
100
120
140
160
180
Time[s]
図 26. VIC と VIC-TFRC におけるパケットロス比較
49
40
tfrc_2flow
vic_2flow
FrameReceive[frames]
35
30
25
20
15
10
5
0
0
20
40
60
80
100
120
140
160
180
Time[s]
図 27. VIC と VIC-TFRC における再生フレームレート
35
30
25
20
15
0
1000
2000
3000
4000
5000
6000
図 28. VIC-TFRC における Y 成分の PSNR 評価
35
30
25
20
15
0
1000
2000
3000
4000
図 29. VIC における Y 成分の PSNR 評価
50
5000
6000
表 3：VIC と VIC-TFRC における受信動画像ステータス比較
受信動画
vic-tfrc
vic
総フレーム数
5425
5459
ロスフレーム数
432
1730
実受信フレーム総数
4993
3729
送信時間
192
183
平均再生フレーム数
26.01
20.38
5.2.6 公平性問題
これまで，VIC-TFRC と TCP との競合時の性能評価を説明してきたが，本来，TFRC と
TCP，特に TCP-Reno との公平性は保たれているはずである．これは，TFRC の動きが
TCP-Reno のものと理論的に全く一致しているからである．今回の VIC-TFRC と TCP 競合時
の受信レートも同様に，公平性が満たされることが予想できるが，実際にはそのようには
いかない．この原因として，VIC-TFRC のレート更新を，完全に RTCP パケット依存となっ
てしまっていることにある．つまり，RTCP-SR と RR の送受信は，1s ごとに行われるため，
レート更新間隔は 1s となる．さらに，無線ネットワークにおける CSMA/CA のために遅延
が有線環境時よりも格段に伸びてしまう．その結果，ネットワーク状況の瞬時の変化に対
応できない．一方，TCP-Reno は，1 パケットにつき，1ack を返すため，レート更新間隔も
短く，ネットワークの瞬時の変化に対応が可能となる．このように，RTCP-SR および RR
の送信間隔の問題により，VIC-TFRC と TCP との間で公平性が満たされないという問題点
が発生することとなる．以下に，参考までに VIC-TFRC と TCP との RTT 比較を図 30 に示
す．
51
400
vic_tfrc_2flow
sample_rtt
reno_tfrc
350
RTT[ms]
300
250
200
150
100
50
0
0
20
40
60
80
100
120
140
160
180
Time[s]
図 30. VIC-TFRC と TCP との RTT 比較
5.3 動画像配信向け適応レート制御実装とその性能評価
これまでは，トランスポート層およびアプリケーション層における協調の性能評価のた
めに，VIC-TFRC のみを取り上げて評価を行ってきた．本章では，トランスポート層におけ
る各種 UDP ベースのレート制御手法の性能比較を行う．なお，以降では，アプリケーショ
ン層における動画像圧縮技術におけるレート制御手法は適応していない．これは，純粋に
トランスポート層における性能比較を行うためである．また，利用したトランスポート層
技術として，TFRC, VTP, Hybrid-TFRC を利用しており，それぞれ VIC-TFRC, VIC-VTP,
VIC-H-TFRC とする．
5.3.1 実験シナリオ
VIC-TFRC, VIC-VTP, VIC-H-TFRC の性能評価比較をするために，実機実験を行うが，実
験環境，実験トポロジーは，5.2 章で利用したものと全く同じであるため，ここでは割愛す
る．実験シナリオとして，4 種類のシナリオを用意した．
(ⅰ) 無線間距離 1m, 有線部遅延 10ms
(ⅱ) 無線間距離 1m, 有線部遅延 100ms
(ⅲ) 無線間距離 5m, 有線部遅延 10ms
(ⅳ) 無線間距離 5m, 有線部遅延 100ms
これら 4 種類のシナリオをそれぞれ 10 回ずつ計測し，その平均値を実験結果として利用
する．なお，評価指標として，受信レート，公平性の指標である Fairness Index，さらに，
受信レートの振動具合を示す分散を利用する．
52
5.3.2 分散と Fairness Index
動画像配信において，一般的に受信レートは振動せずになるべく一定に近い状態が望ま
しいとされている．これは，受信レート（送信レート）が振動してしまうと，動画像圧縮
面におけるビットレートも振動してしまい，安定したクオリティの画質を維持することが
難しくなるからである．そのため，本稿では，受信レートの振動具合を評価するために，
分散を利用する．また，5.2.6 章でも述べたように，公平性問題から，競合フローとどの程
度公平性が保たれているかを示す Fairness Index を評価指標として利用する．以下の式(56)，
(57)に，分散，
Fairness Index の算出式を示す．分散は，値が 1 に近ければ安定を意味し，Fairness
Index は，値が 0 に近ければ公平を意味する．
s2 =
1 n
∑ ( x − xi ) 2
n i =1
(56)
n
FI =
(∑ xi ) 2
i =1
n
n∑ x
i =1
(57)
2
i
5.3.2 動画像配信実験
ここでは，VIC-TFRC, VIC-VTP, VIC-H-TFRC を(ⅰ)～(ⅳ)の実験シナリオで 10 回ずつ実
験した結果を示す．評価指標は，受信レート，公平性を示す Fairness Index を利用する．
まず，実験シナリオ(ⅰ)では，無線間距離 1m, 有線部遅延 10ms と比較的緩い実験シナリ
オとなる．TFRC, VTP, H-TFRC の比較を行うと，TFRC は，2.2.2 章で説明したとおり，有
線ネットワーク向けに提案されたレート制御技術であり，無線ネットワークにおける干渉
やノイズによるランダムパケットエラーについては考慮していない．また，無線ネットワ
ークでは遅延が非常に増大してしまうことから，遅延の値をダイレクトにレート算出式に
使っているため，受信レートは最も低いものとなる．一方，VTP および Hybrid-TFRC では，
無線によるエラーと輻輳によるエラーを判別する LDA，さらに，遅延の差分を送信レート
算出に利用しているため，遅延の影響を受けにくく，TFRC よりも受信レートは高いものと
なる．ただし，今回の実験環境では，無線 NIC バッファが BDP よりも大きくなっているこ
とから，TCP-Reno との公平性は保たれず，いずれのレート制御も TCP-Reno に負けてしま
う結果となる．ただし，受信レートは，VTP，Hybrid-TFRC において改善されるため，公平
性は，TFRC と比較して，改善されることとなる．以下に実験シナリオ(ⅰ)における実験結
果を図 31,32 に示す．
53
図 31. 実験シナリオ(ⅰ)における受信レート比較
図 32. 実験シナリオ(ⅰ)における Fairness Index 比較
次に，実験シナリオ(ⅱ)では，無線間距離 1m, 有線部遅延 100ms という実験シナリオと
なる．実験シナリオ(ⅰ)と比較して，有線部遅延が 100ms になることで，遅延が増大するこ
とによる影響が出ることとなる．遅延が増大することによる影響は，TFRC に見られる．そ
の理由については，先に述べたとおりであるため，割愛する．その結果，TFRC における受
信レートが実験シナリオ(ⅰ)と比較して，減少することとなるが，VTP，Hybrid-TFRC にお
54
ける影響はそれほど出ない．また，TCP-Reno も RTT が増大することにより，Ack パケット
の返信に時間がかかり，輻輳ウィンドウの増加が遅れることとなる．そのため，TCP-Reno
においても，受信レートの減少がみられる．以上のことにより，TFRC, TCP-Reno において，
受信レートが減少し，VTP, Hybrid-TFRC において受信レートが大きく変化しないため，
Fairness Index において，改善することとなる．以下に実験シナリオ(ⅱ)における実験結果を
図 33,34 に示す．
実験シナリオ(ⅲ)では，無線間距離 5m，有線部遅延 10ms という実験シナリオとなる．実
験シナリオ(ⅰ)と比較して，無線間距離が 1m から 5m に伸びたことにより，無線ネットワ
ークにおける干渉やノイズが受けやすくなる．そのため，無線ネットワーク部における帯
域が狭くなることにより，全体的に受信レートが減少することとなる．帯域が狭くなる原
因としては，距離が長くなることにより，受信電波強度が下がり，また，ノイズも増加す
ることから SN 比が悪くなることとなる．その結果，802.11g のビットレートが 54 Mbps の
ように高い値から 36, 24 Mbps モードへとレートシフトが発生する．その結果，無線ネット
ワーク部の帯域が狭くなることとなる．以下に実験シナリオ(ⅲ)における実験結果を図
35,36 に示す．
図 33. 実験シナリオ(ⅱ)における受信レート比較
55
図 34. 実験シナリオ(ⅱ)における Fairness Index 比較
図 35. 実験シナリオ(ⅲ)における受信レート比較
56
図 36. 実験シナリオ(ⅲ)における Fairness Index 比較
最後に，実験シナリオ(ⅳ)では，無線間距離 5m, 有線部遅延 100ms というように，最も
厳しい実験シナリオとなる．これまでと同様に，無線間距離が増大することにより，無線
ネットワーク部の利用可能帯域が狭くなることから全体的に受信レートが減少し，有線部
遅延の増大により，TFRC および TCP-Reno にその影響がみられ，両者の受信レートが減少
することとなる．ただし，有線部遅延の増大による影響は，無線間距離 1m のときと比較し
て大きくは現れない．これは，無線間距離増大による遅延増大の影響が大きく，有線部遅
延が 10ms から 100ms になった影響が小さいことが原因として考えられる．いずれにせよ，
結果，TFRC は，大きく受信レートを下げることとなるが，VTP, Hybrid-TFRC は TFRC ほど
受信レートを下げることにはならず，無線ネットワークにおける有効性を示す結果となる．
以下に実験シナリオ(ⅳ)における実験結果を図 37,38 に示す．
57
図 37. 実験シナリオ(ⅳ)における受信レート比較
図 38. 実験シナリオ(ⅳ)における Fairness Index 比較
58
受信レートの振動具合を示す分散では，VIC-TFRC と比較して，VIC-VTP，VIC-H-TFRC
の方が抑えられる結果となる．これは，TFRC では，RTT，パケットロス率という二つの要
因から送信レートを算出し，RTT，パケットロス率ともに非常に値が振動してしまう．その
ため，算出される送信レートも大きく振動することとなる．一方，VTP, Hybrid-TFRC では，
RTT および RTT 差分のみで送信レートが算出され，差分を見ると，RTT ほど大きく振動す
ることはなく，送信レートの振動具合も抑えられる結果となる．以下に，各種レート制御
における分散の結果を図 39 に示す．
図 39. 各種レート制御における分散
5.4 動画像配信実験におけるまとめ
これまで，トランスポート層，アプリケーション層におけるレート制御実装と実機によ
る性能評価を述べてきた．トランスポート層，アプリケーション層の両アプローチから適
応レート制御を行う有効性，また，トランスポート層において，無線環境において，VTP,
Hybrid-TFRC の有効性を示す結果となった．特に，トランスポート層における各種レート制
御性能比較では，送信レート算出式の影響がダイレクトに出る結果となった．つまり，TFRC
では，RTT およびパケットロス率の二つの要因で送信レートが算出されるのに対して，VTP，
Hybrid-TFRC では，RTT(RTT 差分)のみで送信レートが算出される．その結果，RTT が増大
してしまう，パケットロス率が比較的高くなってしまう無線ネットワークのような環境下
では，VTP, Hybrid-TFRC は非常に有効であるといえる．しかし，VTP，Hybrid-TFRC の課
題として，TCP-Reno よりも受信レートを下げてしまう，また，パケットロス多発による受
信レートの低下が見受けられる．パケットロスが多発してしまう原因としては，やはり
VIC-TFRC と同様に，フィードバックパケットを RTCP-SR,RR に任せてしまっていることが
59
原因と考えられる．つまり，TCP-Reno のように，1 データパケットにつき 1Ack パケットと
いう方式ではなく，ある一定間隔(本稿では 100ms)ごとに送受信を行う方式では，動的なネ
ットワークの変化に対応することが難しくなる．また，もし，フィードバックパケットが
廃棄されてしまった場合，どのような対処を行うのか，という点についても，まだ未対処
な点が多く，今後の課題となる．
5.5 今後の課題点
前節で述べたように，フィードバックパケットの扱いをどうするか，という課題点もそ
うであるが，それ以上に，リアルタイム系のアプリケーションにとって非常に問題となる
ことが遅延の増大となる．図 40 に示すように，特に上り方向（無線→有線）の遅延が無線
ネットワークでは増大することが実験結果からわかる．これは，802.11g における CSMA/CA
により，送信権獲得，加えて，無線 NIC カードのバッファが非常に大きいことが原因とし
てあげられる．このように，リアルタイム系アプリケーションでは遅延をどれだけ抑えら
れるかが課題となり，無線ネットワークでどのようにしてそれを達成するかが，難しい問
題としてあげられる．一つの解決策として，MAC 層における，パケット滞留具合，CSMA/CA
の送信待ち時間の状態などを明らかにし，その情報をトランスポート層へ伝え，MAC 層の
状態を踏まえたクロスレイヤアプローチが考えられる．
図 40. 上り方向における片方向遅延
60
第 6 章 今後の展望
今後の展望として，5.5 章で述べたように，無線ネットワーク環境下における遅延を抑え
ることを目標として考える．
無線ネットワークでは，送信権獲得のための CSMA/CA や MAC 層レベルでのパケット再
送，利用可能帯域が，ノイズや干渉などの影響から流動的になりやすいことから，有線ネ
ットワークと比較して遅延が増大しやすい傾向にある．例えば，図 40 では，全体的な遅延
の増加傾向がみられ，また，図 41 では，全体的には，遅延は抑えられているが，部分的に
非常に遅延が増大している様子がわかる．リアルタイム系アプリケーションに焦点を当て
た場合，このような遅延増大は，非常に問題となる．例えば，VoIP の標準化では，End-to-End
遅延は，150ms 以下に抑えるという基準が存在する．
（図 42）このように，無線ネットワー
クで遅延を抑制するために，MAC 層における状態を明らかにすることが求められる．MAC
層の状態を推測する手段として，MAC 層レベルのパケット送信レートや遅延のモデル式を
利用して計算する手法が考えられる．アプリケーション層から送信される Offered Load から，
CSMA/CA により，throughput がどれぐらいになるか，モデル化している Bianchi の式を利
用すれば，Offered Load と throughput の関係性が得られる．さらに，リトルの定理を利用し
た delay 算出式により，Offered Load と end-to-end delay の関係性が得られる．これらのモデ
ル式からうまく MAC 層のバッファにおける滞留パケットをコントロールすることや，MAC
層における throughput をトランスポート層へ情報をフィードバックし，レート制御へ適応す
ることで，遅延の低減が望める．このように，トランスポート層と MAC 層とのクロスレイ
ヤアプローチで遅延の抑制，適応レート制御を行い，さらにアプリケーション層において，
画像圧縮技術面で適応レート制御をすることで，無線ネットワークにおけるリアルタイム
動画像配信の QoS が向上することが期待される．以下に参考として，Bianchi モデルを利用
した 802.11g におけるスループットとパケット生成レートとの関係を図 43 に示す．
300
RTT
RTT[msec]
250
200
150
100
50
0
0
50
100
150
200
Time[s]
図 41. Skype における遅延の推移
61
250
300
図 42. IP 電話の音声品質基準[30]
図 42. 802.11g におけるスループットとパケット生成レートとの関係
62
参考文献
[1] Gyao[online]: http://gyao.yahoo.co.jp/
[2] Youtube[online]: http://www.youtube.com/
[3]ニコニコ動画[online]: http://www.nicovideo.jp/
[4] Ustream[online]: http://www.ustream.tv/
[5] Video Conferencing Tool[online]:
http://www-mice.cs.ucl.ac.uk/multimedia/software/vic/
[6] W. Richard Stevens: "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast
Recovery Algorithms," IETF RFC 2581, 1999.
[7] L.S. Brakmo and L.L. Perterson: “TCP Vegas: End-to-End Congestion Avoidance on a Global
Internet,” IEEE Journal on Selected Areas in Communication, Vol. 13, Nov. 8, 1995.
[8] I. Rhee and L. Xu, “CUBIC: A New TCP-Friendly High-speed TCP Variant”, in Proc. of
PFLDnet 2005.
[9] M.Handley, S.Floyed, J.Padlhye and J.Widmer: “TCP Friendly Rate Control (TFRC)”, RFC3448,
January 2003.
[10] Soo-Hyun Choi and Mark Hnadley: “Designing TCP-Friendly Window-based Congestion
Control for Real-time Mulitmedia Applications”, PFLDNeT 2009, May 2009.
[11] H.Schulzrinne, S.Casner, R.Frederick, and V.Jacobson: ”RTP: A Transport Protocol for
Real-Time Applications”, RFC3550, July 2003.
[12] K. Kaneko, T. Fujikawa, Z. Su, and J. Katto, “TCP Fusion: A hybrid congestion control
algorithm for high-speed networks,” PFLDnet 2007.
[13] L. Xu, K. Harfoush and I. Rhee: “Binary Increase Congestion Control for Fast, Long Distance
Networks”, in Proc. of INFOCOM 2004.
[14] Guang Yang, Mario Gerla and M. Y. Sanadidi, "Adaptive Video Streaming in Presence of
Wireless Errors," MMNS 2004, LNCS 3271, pp. 26-38, 2004.
[15] T.Fujikawa et al.: "A Hybrid TCP-Friendly Rate Control for Multimedia Streaming," Packet
Video 2010, Dec.2010.
[16] E.Kohler, M.Handley, S.Floyd: “Datagram Congestion Control Protocol (DCCP)”, RFC4340,
March 2006.
[17] S.Floyd, E.Kohler, J.Padhye: “Profile for Datagram Congestion Control Protocol (DCCP)
Congestion Control ID 3: TCP-Friendly Rate Control(TFRC)”, RFC4342, March 2006.
[18] Soo-Hyun Choi: “Congestion Control for Real-time Interactive Applications”, Google summer
of Code 2008 project
[19] Soo-Hyun et al.: “Fairer TCP-Friendly Congestion Control Protocol for Multimedia Streaming
Applications”, UCL Research Note 2006.
63
[20] I.Rhee et al.: “Limitations of Equation-based Congestion Control” IEEE/ACM 2007.
[21] Song Cen et al, ”End-to-End Differentiation of Congestion and Wireless Losses”, IEEE/ ACM
Transactions on Networking, 11(5):703-717.
[22] H. Ujikawa and Jiro Katto, “Implementation Experiment of VTP-Based Adaptive Video
Bit-Rate Control over Wireless Ad-Hoc Networks”, IWAIT 2009, January 2009.
[23] 明壁 祐基: ”様々なデータを扱えるストリーミング技術を用いて機器間の通信・制御を
行う研究”, 2004 年 3 月
[24] VIC-H.264[online]:
http://mediatools.cs.ucl.ac.uk/nets/mmedia/wiki/VicH264
[25] Congestion Control to VIC[online]:
http://mediatools.cs.ucl.ac.uk/nets/mmedia/wiki/CongestionControl
[26] 藤川 和樹: “移動端末におけるリアルタイム系トランスポート層プロトコルの特性改
善”, 2008 年 2 月
[27] Giuseppe Bianchi, “Performance Analysis of the IEEE 802.11 Distributed Coordination
Function,” Selected Areas in Communications, IEEE Journal , 2000.
[28] 守倉正博：“高速無線 LAN 教科書” 2005 年
[29] Tien-Shin Ho, Kwang-Cheng Chen, “Performance Analysis of IEEE 802.11 CSMA/CA
Medium Access Control Protocol”, PIMRC 96.
[30] 千村保文, 井坂正純, 有山義博：“IP 電話通話品質評価法の標準化動向”沖テクニカルレ
ビュー 2005 年 4 月/第 202 号 Vol.72 No.2
64
第2編
無線 LAN の実スループット特性に基づく寄
り道経路探索の評価
第1章
序論
1.1 研究背景
近年，携帯電話，スマートフォン，さらに，タブレット端末といったように，無線携帯端
末の普及，多様化があげられる．それに加えて，文字ベースである Email，twitter[1]だけで
なく，Youtube[2]，Ustream[3]のような動画像配信サービスといったように，インターネッ
トサービスの普及，多様化もあげられる．その結果，これまでのように，家，職場といっ
たある空間内だけでインターネットサービスを受けるのではなく，街中，移動中でも無線
携帯端末を利用して，インターネットサービスを利用する機会が増加したといえる．特に，
街中でも無線 LAN 接続を可能にしてくれる FreeSpot サービス[4]や各キャリアによる公衆無
線 LAN サービス[5,6,7]の拡大により，街中でインターネットサービスを受けることが容易
になったと言える．また，今後，ロボット間あるいは遠隔操作などを含む M2M 通信も増加
していき，対象が人間だけでなく，無線通信が利用できる様々な対象へ拡大していくこと
が予想され，移動中，常にネットワーク通信が可能な環境への需要が高まると考えられる．
これに対して，通信インフラ面においても，セルラー通信，無線 LAN 通信，WiMAX とい
ったように，普及，多様化があげられる．しかしながら，現状ではアプリケーションニー
ズの多様化に対して，アプリケーション QoS(Quality of Service)が満足できるほどの無線イ
ンフラが整備されているとは言い難い．例えば，セルラー通信は，電波カバレッジ範囲が
非常に広いが，通信速度が遅く，さらに基地局設置のコストも高い．一方，無線 LAN 通信
は，電波カバレッジ範囲が狭いが，通信速度は速く，基地局設置のコストも安い．
そこで，筆者らは，目的地まで最短距離で移動するのではなく，多少余分な時間がかかっ
たとしても，無線 LAN 基地局近辺のような通信品質が良いエリアへ寄り道して目的地まで
移動する最適寄り道経路の利用を提案している[8,9]．すでに，レイリー・フェージングに基
づいた理論モデルによる評価により，寄り道経路による効果（増加情報量 対 増加距離）
が向上することが確認されている．しかしながら，これまでの研究では，利用した評価モ
デルと実環境による対比がなされていない．そこで，本稿では，実環境の実測データに基
づくスループット特性を利用し評価を行い，寄り道効果を示す．
65
1.2 研究目的
本稿では，前節の研究背景でも述べたように，実環境に基づくスループット特性を利用
し，寄り道効果を示す．これまでの従来評価では，レイリー・フェージングに基づいた理
論モデルの評価や，背景フローにより，有線部ボトルネックが発生した際の評価のみしか
行われておらず，実環境との対比がなされていなかった．そのため，より従来評価の結果
に説得性を持たせるために，実際に利用されている公衆無線 LAN サービスにおけるスルー
プット特性，さらに，実在する都市における AP 配置位置を参考に，シミュレーションマッ
プを作成し，シミュレーション評価により寄り道効果を示す．さらに，シミュレーション
評価により得られた寄り道経路を実際に歩き，実機を利用して，寄り道効果が得られるの
かを検証する．
最終的には，現在提案されている寄り道経路は，開始地点から目的地点までにおいて総
通信量が最大となる経路を選択するもののみであるが，ユーザのニーズに合わせて，様々
な寄り道経路を実装し，評価していく予定である．ユーザのニーズに合わせた寄り道経路
の一例として，消費電力を可能な限り抑えて通信量をなるべく稼ぐ経路などを実装予定で
ある．また，シミュレーション評価のみにとどまらず，実際の Android 端末で実行可能なア
プリケーションの作成も目指す．
66
第2章
最適寄り道経路
本章では，最適寄り道経路の定義，アルゴリズム，従来評価モデルについて説明する．
2.1 最適寄り道経路[8,9]
最適寄り道経路とは，ワイヤレス通信を効率良く利用するために，目的地まで最短経路
で行くのではなく，許容時間内に可能な限り通信品質の良い経路を選択し，目的地へ向か
う経路である(図 1)．この最適寄り道経路を決定するために，次にあげる 4 つの制約条件を
設ける．
(a) ユーザは，基地局からの距離に応じた通信速度で通信が可能である．
(b) ユーザは，最短経路の移動時間に対する許容時間を設定する．
(c) ユーザは，許容時間内であれば，通信品質の良い経路を選択することが可能である．
(d) ユーザは，許容時間内であれば，最大通信速度の地点で停止することが可能である．
本稿では，これら 4 つの制約条件を満たし，総転送量が最大となる経路を最適寄り道経路
とする．
図 1. 最適寄り道経路のイメージ図
2.2 従来評価モデル
最適寄り道経路を評価するに当たり，重要となるのは，評価マップ上に点在する基地局
のスループット特性，および，ユーザが基地局の位置やスループット特性といった情報を
どのように得るのか，という点にある．
2.1.1 ワイヤレス通信が理想通り利用できる環境における評価[8]
[8]では，基地局のスループット特性として，レイリー・フェージングに基づき干渉を考
慮しない理論モデルを利用している．また，ユーザは，あらかじめ基地局の位置やスルー
67
プット特性といった情報がわかっているという仮定のもと評価を行っている．評価に利用
した理論モデル式を(1)式に示す．
1.2 × 10 7
))
P (d ) = min(22,20 log 2 (1 + 2
(d + 3 2 ) 2
…(1)
ただし，d は基地局と端末の距離[m]，P(d)はスループット[Mbps]であり，22[Mbps]は，802.11g
の有効レートを想定している[10]．
また，基地局では，他のユーザがその基地局を共有して利用するということや，有線部
において背景フローの存在により，帯域が絞られるといったボトルネック要素は全く考慮
せず，非常に理想的な状況を想定している．
シミュレーション評価として，図 2 に示すような 1 辺 20m で 40×40=1600 個の頂点から成
る正方格子の評価マップを考える．結果，評価マップは 800m×800m の範囲を考えることと
なる．評価マップ上には，基地局（Access Point (AP)）をランダムに配置し，スタート地点
からゴール地点の間をユーザは，1[m/s]の速度で移動を行う．想定している最短経路は，
480[m]であるため，最短時間は 480[s]となる．シミュレーション評価として，評価マップを
1000 パターン用意し，許容時間と最適寄り道経路の通信品質の関係，基地局数と総転送量
改善率の関係を評価している．許容時間と最適寄り道経路の通信品質の関係において，許
容時間が増加すると，通信品質のより良好な経路を選択できるようになることや最大の通
信速度が得られる地点で停止できる時間が増加するため，許容時間が大きくなるほど，寄
り道をした際の総転送量も増加することが確認されている．さらに，基地局数と総転送量
改善率の関係において，寄り道による総転送量改善率は基地局の少ない場合に顕著であり，
基地局を増加させていくと，総転送量改善率は小さくなることが確認されている．
しかしながら，これらの評価は，(1)式に示されている理論モデル式が干渉やノイズを考
慮していない理論的な環境下，また，有線部における背景フローや，AP のシェアリングと
いったように，理想通り利用できる状況のみを考慮している．実際には，背景フローの存
在などによりボトルネックが発生するが，その際には，寄り道特性が変化することが考え
られる．
2.1.2 確率的にリソースが変動する環境下における評価 [9]
[9]では，有線部において一定の背景フローが常に存在した場合をモデル化し，寄り道特
性の評価を行っている．一定の背景フローが常に存在した場合をボトルネック AP と定義し，
ユーザがそのボトルネック AP を予想できる場合，予想できない場合の寄り道特性を明らか
にしている．ボトルネック AP の予想については，[8]と同様に，あらかじめユーザがどの基
地局がボトルネックとなるのかわかっている仮定のもと評価を行っている．シミュレーシ
ョン評価は[8]と同等のものであり，評価マップ 1000 パターンの平均値を算出している．そ
の結果，ボトルネックの予想可否によらず，寄り道効果が得られること，特に，予想可能
68
の場合，1.5~2 倍，さらに，予想可否によって 1.4~1.7 倍の寄り道効果が得られることが確
認されている．また，寄り道経路において転送量を獲得するのに，移動中と停止中の二つ
のパターンが存在するが，移動中よりも停止中に稼ぐことが可能な転送量が非常に多いこ
とも確認されている．電波カバレッジ範囲内であれば，基地局の方へ向かうにつれ，転送
量が増加することがわかるが，カバレッジ範囲ギリギリを移動するよりも，基地局へ向か
い，最大転送量が得られる地点で可能な限り停止することが転送量を稼ぐことにおいて効
果的となる．
しかしながら，[8]と同様のスループット特性を利用しているため，(1)式の理論モデル式
と実機評価との対比がなされていない．そのため，本稿では，実際に利用されている公衆
無線 LAN サービスにおけるスループット特性，さらに，実在する都市における AP 配置位
置を参考に，シミュレーションマップを作成し，シミュレーション評価により寄り道効果
を示す．
図 2. 評価 MAP の一例
69
第3章
実環境におけるスループット特性
これまでの従来評価では，レイリー・フェージングに基づく，干渉やノイズを考慮して
いない理論モデルによるスループット特性を利用してきたが，実環境との対比がなされて
いない．そのため，本章では，様々な環境下におけるスループット特性，また，実際に利
用されている公衆無線 LAN サービスにおけるスループット特性の計測を行った．
3.1 様々な環境下におけるスループット特性
3.1.1 実験環境
実機によりスループット特性を調査するために，3 つの環境を用意した．
(1) Line of Sight (LOS) outdoors
(2) LOS indoors
(3) Non-LOS (NLOS)
(1)では，屋外の障害物がなく，見渡しが良い広場を想定しており，実際に測定した場所は
キャンパスの中庭となる．(2)では，(1)の屋内版であり，実際に測定した場所は，55 号館 1F
のロビーとなる．(3)では，大きな金属製の扉といった障害物を挟んだ場合を想定しており，
実際に測定した場所は，55 号館 1F の会議室となる．そのとき，会議室内に AP を設置し，
金属製の扉を閉めて，外から AP にアクセスするようなシナリオで評価を行った．実験環境
は，Linux のノート PC を 2 台，無線 LAN は 802.11g となる．実験トポロジーは，送信端末
と AP を無線で接続し，AP と受信端末を有線で接続するアップロード実験となる．実験で
は，iperf[11]を利用して，TCP フローを送信し，10 回実験を行った平均値を実験結果として
利用している．実験環境を表 1 に示す．
表 1: 実験環境
3.1.2 実験結果
LOS outdoors，LOS indoors，NLOS それぞれの環境下で 10 回ずつ実験を行い，その平均
値を結果として利用している．LOS outdoor では，屋外であり，さらに，障害物が少なく，
70
見渡しが良いため，別の AP からの干渉を受けやすい．他の AP や端末からの電波がノイズ
として見なされ，SN 比が悪くなる．その結果，無線 LAN の利用可能帯域が狭くなり，ス
ループットが出なくなる．また，RSSI は距離の 2 乗に反比例するため，少し距離が離れる
だけで RSSI は急激に減少する．そのため，SN 比にも影響を受け，距離が離れると SN 比も
急激に悪くなってしまい，同様に無線 LAN の利用可能帯域が狭くなる．結果，スループッ
ト特性は，距離が少しでも離れると急激に落ちるようになるが，ある程度離れると RSSI の
減少率も低くなるため，なだらかな形になる．この傾向は屋内である LOS indoors において
も同様である．ただし，屋内であるため，屋外よりも他の AP からの干渉が受けにくい．そ
のため，最大スループットは，屋外のものよりも高くなる．扉という障害物がある NLOS
では，扉を挟んで急激に RSSI が落ちるため，スループットにもその様子が見られる．AP
と送信端末の間に扉が無い場合は，LOS indoor と同様の傾向となるが，扉を挟むことで急
激にスループットが落ちることとなる．実験結果を図 3, 4 に示す．実験結果で得られたス
ループット特性を，それぞれ LOS outdoors model(LOSOM), LOS indoors model(LOSIM), NLOS
model(NLOSM)として利用する．また，従来モデルをレイリー・フェージングモデル(RFM)
Throughput [Mbps]
として比較する．スループット特性モデルを図 5 に示す．
18
16
LOS outdoor
14
12
LOS indoor
10
NLOS
8
6
4
2
0
0
10
20
30
40
Distance [m]
図 3. 様々な環境下におけるスループット特性
71
50
60
Throughput [Mbps]
図 4. 様々な環境下における RSSI 特性
25
20
LOSOM
LOSIM
15
NLOSM
RFM
10
5
0
0
20
40
60
80
100
120
Distance [m]
図 5. それぞれのスループット特性モデル
3.2 公衆無線 LAN におけるスループット特性
前節では，競合フローが存在しない理想的な状況下での実機によるスループット特性
を評価したが，本節では，実際に利用されている公衆無線 LAN におけるスループット特性
を評価する．今回，評価を行った公衆無線 LAN サービスは，FreeSpot と NTT docomo によ
72
る Mzone を対象とした．送信端末を公衆無線 LAN へ接続し，iperf により 120 秒間 TCP フ
ローを送信し，120 秒間の平均送信 throughput を計測した．受信端末は，研究室の有線接続
された Windows PC を利用した．いずれの環境でも，5 回ずつ測定した平均値を利用してい
る．利用した送信端末は，Android Tablet(ICONIATAB A500)，および Windows ノート
PC(Windows 7)である．なお，NTT docomo による Mzone の計測は，Windows ノート PC で
行っている．実験環境を図 6 に示す．
図 6. 実験環境
3.2.1 Android Tablet vs Windows PC
Android Tablet と Windows PC の特性比較を行う．同一 AP へ 1flow ずつ，また，競合した
場合のスループット比較を行う．利用した無線 LAN は 802.11n を利用し，iperf[10]により
TCP フローを送信し，5 回の平均値を比較する．比較してみたところ，1flow 時，競合時と
もに，約 5 倍近くのスループット差があることが分かった．次節から述べる FreeSpot，Mzone
とのスループット比較も，このような特性があると考えられる．実験結果を図 7 に示す．
図 7. Android Tablet vs Windows PC
73
3.2.2 公衆無線 LAN におけるスループット特性
図 6 に示しているように，送信端末から受信端末まで，上り方向におけるスループット
計測を行った．利用した AP は，FreeSpot および NTT docomo の Mzone である．FreeSpot で
は，送信端末に Android Tablet を，Mzone では，Windows PC を利用して実験を行っている．
なお，計測は，店舗の目の前から計測を行っているため，店舗前を 0 m 地点と仮定してい
る．3.1 節で述べたように，屋外であるため，少しでも店舗から離れると，大きくスループ
ットが低下している様子がわかる．さらに，AP が店舗内に設置されていることがほとんど
であるため，3.1 節で計測された以上に，少しでも距離が離れると全くスループットが出な
くなってしまった．また，今回は，潜在的に競合フローが存在している状況であるため，
店舗によっては，ほとんどスループットが出ていない．このように，AP が店舗内にあるの
か，店舗外にあるのか，また，店舗の形状によって，スループット特性が様々に変化する
ことがわかる．実験結果を図 8 に示す．
図 8. 公衆無線 LAN サービスにおけるスループット特性(RFM は参考)
74
第4章
寄り道特性評価
本章では，前章で述べた実環境におけるスループット特性，公衆無線 LAN サービスにお
けるスループット特性を利用して寄り道特性評価を行う．
4.1 評価指標
寄り道特性を評価するにあたり，利用する評価指標は，[8,9]で利用していたものを採用す
る．つまり，最短経路と比較して寄り道することにより総転送量がどの程度増加するのか
を示す Improvement Ratio (IR)，ユーザが最短経路と比較してどの程度寄り道を許容するのか
を示す Longcut Ratio (LR)を利用する．さらに，[8,9]で停止の転送量に対する効果が高かっ
たということが確認されていたので，停止がどの程度総転送量を占めるのかを示す Staying
Ratio (SR)を新たに採用する．以下に，それぞれの計算式を示す．
Improvement Ratio =
Longcut Ratio =
Staying Ratio =
最適寄り道経路の総転送量
最短経路の総転送量
寄り道経路の許容時間
最短時間
停止による獲得転送量
最適寄り道経路の総転送量
…(2)
…(3)
…(4)
4.2 基地局の可視化について
従来評価において，基地局の位置，基地局におけるスループット特性については，あら
かじめわかっていることが前提としてのものである．本稿における評価は，従来と同様に，
基地局の位置，スループット特性はすべて明らかになっていることを想定するが，次に示
すように，経路探索を行う前に位置，スループット特性を得ることが可能であると仮定す
る．基地局の位置については，[11]で提案されているように，無線端末を一つのセンシング
端末とみなし，RSSI 値と GPS 情報を収集するセンサークラウドにより基地局の位置情報を
明らかにする．また，スループット特性については，基地局の利用状況を統計的にデータ
として収集しておき，ユーザは，そのデータベースにアクセスすることで，基地局のスル
ープット特性も知ることができるものとする．
4.3 単一スループット特性環境下における寄り道特性評価
寄り道特性を評価するに当たり，まずは単純な評価マップを利用する．つまり，評価マ
ップ上に点在する基地局のスループット特性が全て同一のものとする．評価マップは，
40×40=1600 個の正方格子で構成されており，1 辺が 10m となっている．そのため，評価マ
ップの範囲は，400m 四方となる．評価マップ上には，30 個の基地局がランダムに点在され
75
ている．基地局の数は，3.1 節で観測された競合 AP の平均値を利用している．AP のスルー
プット特性は，図 5 に示しているモデルを利用する．図 9 に，評価マップのイメージを示
す．シミュレーション実験では，評価マップを 1000 パターン用意し，シミュレーション評
価を行う．実験結果として，1000 パターンの平均値を利用する．評価指標は，4.1 節で紹介
した IR と LR の関係，また，獲得転送量と許容時間との関係を示す．
IR は，(2)式で定義しているように，最短経路の総転送量と寄り道経路の総転送量で決定
される．スループット特性が変化すると，最短経路 and/or 寄り道経路の総転送量が変化す
るため，IR は変化することとなる．例えば，LOSIM や LOSOM のように，カバレッジ範囲
が広いようなスループット特性では，寄り道をしない最短経路でも電波のセル範囲内を通
過する確率が高くなり，転送量が増加するようになる．一方，NLOSM のように，カバレッ
ジ範囲が非常に狭いようなスループット特性では，最短経路に電波のセル範囲が通過する
確率が減少するため，転送量は減少することとなる．対して，寄り道経路の総転送量は，
できる限り，セルの中心に向かい，停止して稼ごうとする．そのため，LOSOM よりも LOSIM
や NLOSM において，最大通信速度が高いため，停止による転送量が増加し，最終的に，
獲得総転送量も増加する．移動と停止を比較してみると，NLOSM は，電波セル範囲が狭い
ため，移動による転送量は見込めず，一方，最大通信速度は高いため，停止による獲得転
送量は増加する．同様に，LOSIM は，電波セル範囲も高く，最大通信速度も高いため，移
動，停止ともに，転送量を稼ぐことが可能となる．ただし，最短経路においても転送量を
稼ぐことができるため，IR を比較してみると，LOSIM，NLOSM のどちらが良い結果とな
るかは判断がつかない．まとめると，最短経路における転送量は，LOSIM，LOSOM，NLOSM
の順に大きくなり，寄り道経路における転送量は，許容時間が短い場合は，LOSIM，LOSOM，
NLOSM の順に大きくなるが，許容時間が長くなると，停止による転送量が増加するため，
LOSIM，NLOSM，LOSOM の順に高くなる．実験結果を図 10,11 に示す．図 10 より，IR は，
NLSOM，LOSOM，LOSIM の順に効果が大きくなっており，特に，LR=2 のときに，NLOSM
は，LOSOM よりも約 3 倍，LOSIM よりも約 5 倍大きい結果となっている．図 11 より，寄
り道における停止の効果は，LOSIM，NLOSM は，LOSOM よりも 1.3 倍程度，大きな結果
となっている．
76
Improvement ratio
図 9. 評価マップのイメージ図
30
25
LOSOM
LOSIM
20
NLOSM
15
RFM
10
5
0
0
0.5
1
1.5
Longcut ratio
図 10. それぞれのモデルにおける IR 比較
77
2
2.5
図 11. 寄り道経路における移動と停止の獲得転送量
4.4 複数スループット特性環境下における寄り道特性評価
次に，Heterogeneous 環境下における寄り道特性評価を行う．前節では Homogeneous 環境
下の評価を行ったが，Homogeneous 環境下では，400m 四方のエリアすべて同一のスループ
ット特性を持つ基地局が存在しているというあまり実環境にそぐわないシミュレーション
評価となっている．そのため，より実環境に近い評価をするために，一つの評価マップ内
に複数のスループット特性を持つ基地局を配置させる．前節と同様の評価マップを利用す
る．評価マップで利用する基地局の組み合わせを表 2 に示す．組み合わせでは，スループ
ット特性をそれぞれ 2 種類ずつ選択するシナリオと全てのスループット特性が混在してい
るシナリオを考える．
前節で述べたように，寄り道効果である IR は，最短経路の総転送量と最適寄り道経路の
総転送量で決定される．Homogeneous 環境下の結果より，最短経路の総転送量は，NLOSM，
LOSOM，LOSIM の順に大きくなる．一方，最適寄り道経路の総転送量は，許容時間が短い
場合は，NLOSOM，LOSOM，LOSIM の順に大きくなるが，許容時間が長くなると，通信
速度が最大の箇所で停止することが可能となるため，LOSIM，NLOSM，LOSOM の順に大
きくなる．この傾向は，Heterogeneous 環境下でも変わらず，スループット特性の組み合わ
せで IR は変化する．それゆえ，最短経路の総転送量は，Homogeneous 環境下の結果から，
マップパターン B，C，A の順に大きくなる．一方，寄り道経路の総転送量は，許容時間が
短い場合は，通信速度が最大となる地点へユーザが到達することが困難なため，移動によ
る影響が大きい．そのため，寄り道経路における総転送量は，マップパターン B，C，A の
順に大きくなる．しかし，許容時間が長くなると，最大通信速度が得られる地点へユーザ
78
が到達し，停止することが可能となる．そのため，停止による影響が大きくなり，マップ
間で総転送量に大きな違いは見られない．ただし，マップパターン B では，ほかのマップ
パターンと比較して，移動による転送量が少なくなってしまうため，総転送量は劣る結果
となる．その結果，寄り道効果は，マップパターン B，C，A の順に大きくなる．また，
Homogeneous 環境下における転送量の結果から，基地局の組み合わせを参考に，推定値を
式(5)により算出してみたところ，移動，停止による転送量において，推定値とシミュレー
ション結果の間でほとんど違いがないことがわかる．これは，評価マップを 1000 パターン
用意しているため，特異な傾向を持つ評価マップが存在したとしても，その他，大多数の
平均値に落ち着いてしまっていることを意味する．つまり，単一のスループット特性がわ
かれば，複数のスループット特性を持つ評価マップであっても，結果が推測できることを
意味する．今後，さらに 1 つの評価マップについて寄り道特性を詳細に見ていくため，現
実都市の基地局配置を参考にして，寄り道評価を行う．図 12~16 に，平均値とシミュレー
ション評価の比較を示す．
n
X =∑
k =1
APNUM k
EDAk
APNUM total
…(5)
ただし，X は推定値，n は，スループット特性数で本稿では n=3， APNUM total は，総 AP
数， APNUM k は，k 番目のスループット特性を持つ AP 数， EDAk は，k 番目のスループ
ット特性における移動，停止における獲得転送量を表す．
表 2：基地局の組み合わせ
79
図 12. それぞれのモデルにおける IR 比較
図 13. 寄り道経路における移動と停止の獲得転送量
80
図 14. 移動における転送量のシミュレーション評価と平均値の比較
図 15. 停止における転送量のシミュレーション評価と平均値の比較
81
図 16. 総転送量のシミュレーション評価と平均値の比較
4.5 実都市における寄り道特性評価
前節までは，評価マップ上における基地局配置は完全にランダムに行ってきた．その結
果，Heterogeneous 環境下では，ランダム配置した評価マップ 1000 パターンを利用して評価
したところ，平均値に落ち着くことが分かった．そこで，実際の店舗位置を参考にし，評
価マップを作成し，実際の市街地における寄り道特性評価を行う．
4.5.1 実スループット特性に基づくモデル化
3.2 節で，実際に利用されている公衆無線 LAN サービスにおけるスループット特性を評
価した．そのスループット特性を利用して，寄り道評価を行ううえで，実スループット特
性に基づくモデル化を行う．スループット特性評価時には，店舗直近を 0m として評価を開
始したが，寄り道評価を行う際に，店舗内へ立ち寄ることを許可するため，店舗内を 0m と
してモデル化する．今回は，単純化のため，店舗の形を 5m 四方の正方形の形をしていると
仮定する．また，3.1 節で実験したように，5m の距離の部屋内は，スループットがほとん
ど減少しないことがわかっているので，店舗内のスループットは，店舗直近と同じスルー
プットと仮定する．以上の仮定のもと，実スループット特性に基づきモデル化した結果を
図 17 に示す．また，従来評価モデルであるレイリー・フェージングモデル(RFM)を比較と
して載せる．
82
図 17. 公衆無線 LAN サービスにおけるスループット特性モデル(RFM は比較)
4.5.2 実都市を参考にした評価マップ作成
寄り道特性評価をするうえで，従来までは評価マップ上にランダムで AP を配置し，1000
パターンのシミュレーション評価を行い，その平均値を結果として利用してきた．しかし，
4.4 節で述べたように，ランダム配置した場合，特異な傾向を持つ評価マップが存在したと
しても，大多数の平均値に落ち着いてしまう結果となることが分かった．そのため，ラン
ダム配置して評価を行うよりも，実際の市街地を参考にし，実際に配置されている位置に
AP を配置し，その評価マップを利用して，寄り道特性評価を行う．
本稿では，参考にする市街地を東京の新宿駅周辺を考える．実際の公衆無線 LAN サービ
スが展開されている店舗を Google MAP[11]を参考にし，評価マップの作成を行う．評価マ
ップでは，400m×400m の範囲に 1 辺 5m の格子を 80×80＝6400 個配置する．なお，共通店
舗は，同一データで補完を行っている．図 18 に Google MAP を利用した実際の店舗位置を，
図 19 に実際の店舗位置を参考にした評価マップを示す．
83
図 18. Google MAP[13]を利用した実際の店舗位置
80
14
70
12
60
10
50
8
40
6
30
4
20
2
10
0
0
0
10
20
30
40
50
60
70
80
図 19. 実際の店舗位置を参考にした評価マップ
4.5.3 シミュレーション環境
前節で述べたような評価マップを利用して寄り道特性をシミュレーション評価する．人
の歩く速度を 1m/s，スタート地点を新宿駅近辺のあるデパートに，ゴール地点を 370m 離れ
たコーヒーショップに定め，寄り道評価を行う．本稿では，選択される寄り道経路は，こ
れまでと同様に，総転送量が最大となるような経路を選択することとする．また，オプシ
ョンとして，3G 携帯回線が利用できるシナリオも考える．3G 携帯回線のスループットは，
Android 携帯を利用して，iperf を 5 回送信したスループット値の平均値を算出したところ
84
0.32Mbps であった．そのため，マップ全体で 3G 携帯回線が利用できると考えた場合，
0.32Mbps の速度でどの地点でも通信が可能であると想定する．評価指標は，4.1 で紹介した
ものを利用する．評価シナリオとして，3G 携帯回線が利用できない場合と，3G 携帯回線が
利用できる場合の 2 パターンを想定する．図 20 に，評価マップのスタート地点とゴール地
点の位置関係を示す．
図 20. 評価マップ上のスタート地点とゴール地点の位置関係
4.5.4 シミュレーション評価
図 20 に示したような評価マップを利用して，実都市における寄り道特性を評価する．評
価では，まずはシミュレーション評価を行う．寄り道特性については，すでに 4.3 節で述べ
ている通りで，今回の評価マップについてもその特性が当てはまる．寄り道経路は，許容
時間，店舗ごとのスループット特性で変化する．基地局のカバレッジ範囲が狭いと，最短
経路上に電波範囲が被ることは少なく，最短経路近辺の基地局へ寄り道をして転送量を稼
ぐようになる．この時，許容時間が非常に短い場合，遠くに良いスループット特性を持つ
基地局が存在したとしても，そこまで到達することができず，基地局近傍の基地局に限ら
れる．一方，許容時間が長い場合，最短経路近傍に，良いスループット特性を持つ基地局
が存在しなければ，多少遠くても，良いスループット特性を持つ基地局へ向かい，転送量
を稼ぐこととなる．もし，最短経路近傍に良いスループット特性を持つ基地局が存在した
場合，そこへ向かい，時間が許す限り停止をして転送量を稼ぐこととなる．多少遠くへ寄
り道した場合，移動している時間分，転送量が稼げないため，停止する時間が短くなって
しまう．このように，寄り道経路では，許容時間，店舗におけるスループット特性で，移
動による転送量が多くなるのか，停止による転送量が多くなるのか，特性が変化すること
となる．最短経路における転送量は，店舗におけるスループット特性のみで決定される．
基地局のカバレッジ範囲が，最短経路に被っていなければ，最短経路は，ほとんど転送量
を稼げなくなるが，最短経路が，カバレッジの中心付近を通ることができると，転送量は
大きくなることとなる．今回の評価マップでは，スタート地点，ゴール地点付近に，基地
局が存在するため，最短経路では，多少の転送量を稼ぐこととなる．寄り道経路では，許
容時間により選択される経路が変化する．許容時間が短い場合，最短経路から少し離れた
85
場所にスループット特性の良い店舗が存在するが，そこへ寄り道するよりも，ゴール地点
の店舗で停止した方が転送量を稼げることがわかる．しかし，許容時間が長くなると，よ
りスループット特性の良い店舗へ寄り道する時間的余裕が生まれるため，そちらの方へ寄
り道し，時間の許す限り停止することとなる．実際の寄り道経路を図 21,22 に示す．
80
14
70
12
60
10
50
8
40
6
30
4
20
2
10
0
0
0
10
20
30
40
50
60
70
80
図 21. 許容時間が短い場合の寄り道経路
80
14
70
12
60
10
50
8
40
6
30
4
20
2
10
0
0
0
10
20
30
40
50
60
70
80
図 22. 許容時間が長い場合の寄り道経路
このように，許容時間により選択される寄り道経路が違うことがわかる．寄り道効果を
意味する IR は，最短経路における転送量と寄り道経路における転送量で決定される．最短
経路は，許容時間が変化しても一定であるが，寄り道経路における転送量は，許容時間に
よって変化する．許容時間が長い場合，最大通信速度が大きい場所で停止することが可能
となり，停止による転送量が増大するため，総転送量は爆発的に増大することとなる．3G
携帯回線の利用の有無もその傾向は変化しない．ただし，3G 携帯回線が利用できなかった
場合と比較して，全く通信が得られなかった期間，3G 携帯回線により多少の転送量を稼げ
86
るようになるため，移動による転送量が増加する．その結果，3G 携帯回線による最短経路
における転送量の増加率が大きくなるため，寄り道効果は，3G 携帯回線が利用できない場
合と比較して落ちることとなる．図 23,24,25 に実験結果を示す．図 23 より，許容時間が 1.5
倍のとき，3G 携帯回線の有無によらず，10~15 倍もの大きな寄り道効果が得られることが
わかる．また，図 26 より，3G 回線利用が有効の分，移動による転送量が増加するため，停
止の占める割合が多少下がるが，3G 携帯回線の有無によらず，総転送量の約 80~90%を停
止が占める結果となる．
図 23. 許容時間と寄り道効果の関係
87
図 24. 許容時間と総転送量の関係
図 25. 総転送量における停止が占める割合
4.5.5 実機による評価
次に，シミュレーション評価で得られた経路を，実際に実機を利用して経路上を移動し，
寄り道効果が得られるのかを検証する．まずは，ゴール地点の店舗において，移動と停止
の特性を評価する．実機で利用した端末は，引き続き Android Tablet (Acer ICONIA TAB A500)
88
を利用する．実験環境は，3.2 節で紹介したものと同じものである．評価シナリオを二つ用
意する．シナリオ A では，店舗の前を 60 秒停止せずに移動する(without staying)．シナリオ
B では，店舗の前を 60 秒移動するが，
通信品質の良い地点で 60 秒間停止を行う(with staying)．
通信品質が最大の地点で 60 秒間停止するため，シナリオ A よりもシナリオ B の方におい
て，転送量が増加するのは当然となる．図 26,27 に実験結果を示す．図 26 は，スループッ
トの推移を示しているが，シナリオ A と B を比較したところ，シナリオ B において，シナ
リオ A のピーク地点のスループットで，60 秒程度平衡状態になっていることがわかる．そ
のため，図 27 より，転送量が増大していることがわかる．120 秒移動したときと比較した
場合，約 1.5 倍程度の増加が見込めることがわかる．次に，実際に，図 21,22 で得られた寄
り道経路を歩き，寄り道経路，転送量を評価する．なお，今回は，3G 携帯回線は利用して
いない．図 28,29,30 に実機評価の結果を示す．図 29 より，総転送量がほとんど変化してい
ないため，図 28 の寄り道効果でも違いがほとんどないことがわかる．ただし，LR が 1.5 以
上において，実機評価の方が増加しているが，これは，実機で評価した際のスループット
値が，スループット特性をモデル化したときよりも高くなっているため，停止時にその影
響が出ている．いずれにせよ，実機評価でも，シミュレーション評価と同様の結果が得ら
れたことから，寄り道効果が実証されたことを示す．
図 26. スループットの推移の様子
89
図 27. シナリオごとの総転送量の比較
図 28. IR の実機評価とシミュレーション評価の比較
90
図 29. 総転送量の実機評価とシミュレーション評価の比較
91
第5章
まとめと今後の展望
本編では，無線 LAN の効率的な利用法としてすでに提案されている最適寄り道経路手法
を評価するに従来の評価モデルではなく，実機によるスループット特性をモデル化し，そ
の評価を行った．シミュレーション評価，実機評価を行い，両評価においておおよそ同様
の結果が得られた．シミュレーション評価では，3G 携帯回線の利用によらず，約 10～15
倍もの大きな寄り道効果が得られることが確認された．
今後の展望としては，今回は，3G 携帯回線および無線 LAN を利用して寄り道効果を示
したが，コグニティブ無線技術の発達により，セルラーのみならず，WiMAX，LTE といっ
た無線インフラ技術との同時アクセスも今後，見込めるため，それを見越し，セルラー回
線，WiMAX，LTE などのスループット特性データの充実を行う．それらの実スループット
データを参考に，従来モデルで紹介した理論モデルの改善を行う予定である．従来モデル
では，レイリー・フェージングのみを考慮し，ノイズフリーな環境を想定していたが，今
回，様々な店舗形状，無線規格の実スループットデータ評価を行ったので，理論モデルの
改善では，物理層，MAC 層，TCP 層を含めたスループット理論モデル式を提案していく予
定である．さらに，店舗ごとにより，物理層の特性が変化してくるため，店舗の形状に合
わせた理論モデル式も同時に必要となってくる．
さらに，店舗ごとの物理層の特性を評価マップに実装を行い，寄り道効果特性の評価が
必要である．本編では，セル形状を単純な円形にしているが，店舗形状により，セル形状
は異なるため，選択される寄り道経路にも変化が生まれる．その結果，寄り道効果特性が
変わることが予想される．
また，選択される寄り道経路にも，単純な獲得総転送量のうち最大となるもののみなら
ず，ユーザに合わせて，どういう寄り道経路を欲するかニーズが変わる．例えば，あるユ
ーザならば，獲得転送量よりも消費電力量を抑える，さらに消費電力量を抑えながら，あ
る程度の転送量が欲しい，またあるユーザは，なるべく最短経路で行きたいが，転送量も
欲しい，またあるユーザは，ある一定の転送量を得るには，どの経路がもっとも最短とな
るか，というように，様々な選択される寄り道経路が必要となってくる．このように，選
択される寄り道経路の種類ごとに合わせた経路探索アルゴリズムが必要となってくる．
以上のように，無線インフラを利用した寄り道経路手法には，まだまだ発展性が望める
と考えられる．
92
参考文献
[1] twitter [online]: http://twitter.com/
[2] Youtube [online]: http://www.youtube.com/
[3] Ustream [online]: http://www.ustream.tv/
[4 ] Freespot [online]: http://freespot.com/
[5]ドコモ Mzone [online]: http://www.nttdocomo.co.jp/service/data/mzone/
[6] au Wi-Fi Spot [online]: http://www.au.kddi.com/wifi/au_wifi_spot/index.html
[7]ソフトバンク Wi-Fi スポット[online]: http://mb.softbank.jp/mb/service_area/sws/gps/
[8] G.Motoyoshi, et al. “Advantages of Optimal Longcut Route for Wireless Mobile Users,” IEEE
ICC2011, June 2011.
[9] 園田, 本吉, 村瀬, 甲藤, “確率的にリソースが変動する場合の最適寄り道経路特性” 信
学技法, CQ2011-34, Sept.2011.
[10] R.Ando, T.Murase, and M.Oguchi,” Characteristics of QoS-Guaranteed TCP on Real Mobile
Terminal in Wireless LAN,” IEEE Communications Quality and Reliability (CQR) 2011, May 2011.
[11] iperf [online]: http://sourceforge.net/projects/iperf/
[12] 岩瀬, 小倉, 甲藤, “スマートフォンを用いたセンサークラウドによる WiFi フリースポ
ットの可視化,” IEICE 総合大会, March.2012.
[13] Google MAP [online]: http://maps.google.co.jp/
93
謝辞
本研究を行うにあたり，日頃から研究に関しての様々なご指導，その他，事務手続き面
など，あらゆる形でサポートしてくださった甲藤二郎教授に心から感謝の意を表します．
また，インターンシップ，共同研究において，同じく様々なご指導をしてくださった村
瀬 勉氏に深く感謝いたします．
最後に，研究面のみならず，様々な面でサポートしてくださったネットワーク班の皆さ
ま，ならびにお世話になりました甲藤研究室の皆さま，家族に深く感謝いたします．
2012 年 2 月 6 日
金井 謙治
94
発表文献リスト
[1] 金井謙治，甲藤二郎，“VIC を用いた適応レート制御実装とその性能評価”，信学技報，
NS2010-73，Oct. 2010.
[2] Kenji Kanai, Masaru Takeuchi, Jiro Katto, “Implementation and Performance Evaluations of
Adaptive Rate Control Mechanisms in VIC”, PCSJ2010/IMPS2010, Dec. 2010.
[3] 金井謙治，甲藤二郎，
“動画像配信向け適応レート制御方式の性能評価”， IEICE 総合大
会，March, 2011.
[4] 金井謙治，甲藤二郎，“動画像配信向け適応レート制御方式の性能評価”，信学技報，
NS2010-287， March, 2011.
[5] 金井謙治，赤松祐莉，甲藤二郎，村瀬勉，
“無線 LAN の実スループット特性に基づく寄
り道経路探索の評価”，IEICE 総合大会，March, 2012.
[6] 金井謙治，赤松祐莉，甲藤二郎，村瀬勉，
“無線 LAN の実スループット特性に基づく寄
り道経路探索の評価”，NS 研究会，March, 2012.
[7] Kenji Kanai, Yuri Akamatsu, Jiro KATTO, Tutomu Murase, “QoS Characteristics on a Longcut
Route with Various Radio Resource Models”, PerCom, March, 2012, Swizerland.
95