無線通信環境における複数インタフェース使用時の帯域幅集約ミドルウェアの提案と評価
宮崎 悦子 （指導教員: 小口 正人）
人間文化創成科学研究科 理学専攻 情報科学コース

1.

はじめに近年，モバイルインターネットは急速に発展しており，この基盤となる様々な無線通信技術が開発されているが，これらの技術は広帯域なものであっても有線での通信と比較するとネットワークそれぞれの帯域幅が未だに乏しいものが多い．また，比較的広帯域を確保している無線は利用可能なシーンが限定されているのが現状である．そこで同時に複数の無線技術の適用範囲がオーバーラップしたとき，ユーザが１つの無線技術だけでなく複数の無線技術を選択して利用できれば帯域の制限が緩和され，より充実したモバイルサービスを受けることが可能になると考えられる．そこで提案されているのが適用範囲にある無線技術の帯域幅を複数同時に使用することでより大きいスループットを得ようとする帯域幅集約（BandwidthAggregation）である．

2.

研究背景

帯域幅集約は様々な層において実現することが考えられるが，特に多く議論されているのがネットワーク層における制御である．ネットワーク層での制御では，手法によって専用機器も必要なく帯域幅集約を実現することができる [1]．上位層に現在広く使用されている TCP やUDP に対して透過的に振る舞うことができるのが利点であるが，トランスポート層のプロトコルとして TCPを用いて集約を行った場合，本来の順序とは異なる順序で到着するパケットが多くなる可能性が高い．パケット
受信側の TCP は，次に期待していたパケットより後のパケットを先に受信してしまうと，パケットが抜けたと認識してしまう．それにより TCP は本来不要であるはずの再転送を要求し，期待した集約効果を得ることができない．
さらに無線環境で通信を行った場合，有線の場合と比較してパケットロスが多く起こることが知られている．
ネットワーク層以下で帯域幅集約を行う際にパケットロスが起こると，TCP は特定の経路のパケットロスであることを認識できず輻輳制御を行ってしまう．その結果ウィンドウサイズが下がるので他のコネクションのスループットまで下がってしまい，期待した帯域幅集約の性能を得ることができない．
この問題を解決するために提案されているネットワーク層の帯域幅集約方式が提案されているが [2]，パケットロスが集中した場合，複数コネクションのスループットが下がってしまうことが問題となっている．既存研究では，この問題に対して，ほかの仕組みで無線のロスを減らすことができれば期待した性能を発揮することができるとしているが，現実には無線通信でのパケットロスを減らすことは大変困難である．

3.

提案手法

本研究ではトランスポート層とアプリケーション層の間にミドルウェアとして帯域を集約する層を新たに挿入することで，より効率の良い帯域幅集約を行う手法を提案する．
提案手法では経路ごとに独立した TCP のコネクションを持ち，それら複数のコネクションをミドルウェアで統合することで帯域を集約していることをアプリケーションが意識することなく通信可能であるというトランスポート層以下での制御でのメリットを残すことができる．さらにパケットロスが起こった場合に複数経路のスループットが下がってしまう原因となっている輻輳ウィンドウを経路ごとに持たせることで，既存研究で指摘されている問題点を回避する．
送信側の提案手法ミドルウェアは接続可能な経路すべてへそれぞれ TCP コネクションを張る．アプリケーションからデータを受け取るとパケットの大きさ分にデータを分割し，配信順の番号をデータへ付与してから確立されたコネクションへデータを送信していく．データを配信する経路を選択する際はそれぞれの経路でパケットを配信した場合，送信ノードから受信ノードまでどれだけ時間がかかるかを計算し，その見積もられた時間が一番短いと判断された経路へパケットを配信する．パケット
配信時間の見積もりには経路の有線及び無線部分の帯域幅，遅延と混雑状況を使用した．次の時間の見積もりを計算するために，パケットを配信するたびに配信した経路の混雑状況を更新する．
受信側のミドルウェアはそれぞれの TCP コネクションから受信されたパケットから付与されているパケット番号を読み出し，その時点でミドルウェアが期待していた番号のパケットだった場合にはそのままデータをアプリケーションへ渡す．期待した番号ではなかったらミドルウェアが持つバッファへパケットを一時貯めておき，次のパケットを待つ．それぞれの TCP コネクションから受信されるパケットは順番が正しくない可能性があるので，それを並び替えてからアプリケーションへ渡す役割を受信側ミドルウェアが果たす．

8070
Buffer Size [Packts]

シミュレーションによる評価

4.

ミドルウェアによる帯域幅集約の性能を評価するためにネットワークシミュレータを用いて実験を行った．
実験シナリオ4.1

図 1 に示されるような 3 本の無線経路を利用できるモバイル端末（ノード 2）がノード 1 から送信されたデータを 3 本の経路を同時に使用して受信するシナリオにおいて，開始から 18 秒たったところで一つの経路上でパケットロスを起こした際のそれぞれの経路でのスループットと受信側ミドルウェアのバッファにたまるパケットの量を観察した．
Node 1
10MbpsDelay = 50ms
200kbps
100kbps

10MbpsDelay = 15ms
Node 250kbps

図 1: 実験シナリオ
実験結果

4.2

既存研究 [2] で提案されたネットワーク層における帯域幅集約を実装した場合，一つの経路におけるパケットロスの影響が他の経路にも及び，すべての経路のスループットをが下がることが観察された [3]．それに対し，ミドルウェアによる帯域幅集約を実装した場合における経路選択それぞれの経路でのスループットを図 2 へ表した．
600

Throughput [kbps]

500
inf060504030201000510152025303540

Time [seconds]

図 3: 受信側バッファへ溜まったパケット量
見える．しかしこの図のスループットはミドルウェアからアプリケーションへデータを渡せるようになった瞬間のデータ量を表しており，図 3 に見られる通り，パケットロスを起こしたパケットを待つために受信側ミドルウェアのバッファが大きく成長している．このためロスしたパケットを待つためだけにすべての経路のパケット到達が一時的に遅れているだけと考えることができ，ネットワーク層での制御で起こっていた輻輳ウィンドウの低下によるスループット低下の問題とは異なる．ミドルウェ
アで観測されるスループットが下がってしまっている間もパケットロスが起こらなかった経路ではデータの転送が続けられ，その間に受信されているパケットはバッファへ貯められており，再送パケット到着後にまとめて配信される．

5.

結論と今後の課題

本研究では，既存研究で提案されているネットワーク層で帯域幅集約を行う際の問題点を解決するために，ミドルウェアにおける帯域幅集約を提案し，それを用いることにより，既存手法より優れた通信を行えるということを確認した．

400
inf1300

inf2200
100013579 11 13 15 17 19 21 23 25 27 29 31 33 35

参考文献[1] K. Koyama, Y Ito, H. MINENO and S. Ishihara:“Evaluation of Performance of TCP on Mobile IPSHAKE”, Transactions of Information Processing
Society of Japan, 2004.

!me [seconds]

図 2: 各経路のスループット
また，受信側ミドルウェアのバッファにたまるパケットの量がどの程度になっているかを表したグラフを図 3へ表した．
図 2 を見るとひとつだけ発生させたパケットロスがすべての経路のスループットを下げてしまっているように[2] K. Chebrolu, B. Raman, and R.R. Rao：“A Network Layer Approach to Enable TCP over Multiple Interfaces,” J. Wireless Networks (WINET),
Vol.11, No5, pp.637-650, Sept. 2005.
[3] 宮崎悦子, Onur Altintas, 小口正人: “複数無線インタフェース使用時のミドルウェアにおけるコネクション集約に関する検討”, DICOMO, 2010.