DEIM Forum2013

モバイルネットワークにおける周辺端末からの情報に基づく協調制御ミドルウェアの提案と実装
平井 弘実†

山口実靖††

小口 正人†† お茶の水女子大学 〒 112-8610 東京都文京区大塚 2-1-1†† 工学院大学 〒 163-8677 新宿区西新宿 1-24-2
E-mail: †hiromi@ogl.is.ocha.ac.jp, ††sane@cc.kogakuin.ac.jp, †††oguchi@computer.org
あらまし近年スマートフォンの爆発的な普及と高性能化に伴い，スマートフォンを用いた大容量高速通信に対する需要が高くなっている．本研究はこのような需要に対応するため，スマートフォンに最適化した新しい通信制御の仕組みを提案する．TCP 輻輳制御は，エンドツーエンドのコネクションに対し，経路上の輻輳崩壊を回避するために 1
つの確認応答に対して送出するセグメント数を調節する役割を担っている．しかし，スマートフォンにおけるサービ
スは，主にクラウドサーバと連携することで高速処理やデータのバックアップなどを提供している．クラウドサーバ
は，WAN などの高帯域な有線経路によって支えられているため，スマートフォンからのアクセスにおいては，輻輳制
御のボトルネックは低帯域な無線通信区間，すなわちエンドホストからアクセスポイントまでの区間に存在すると考えられる．本稿では，我々はスマートフォンにおいて協調的通信制御を行うミドルウェアを提案する．既存の輻輳制
御は，有線経路を含む全体の経路上で起きた転送エラーに基づいてのみ輻輳崩壊を避けるためにフローを制御しているが，モバイル端末のインターネットアクセスにおいて性能劣化の主な原因は，無線区間に潜んでいるため，端末間が独立したエンド・エンドの輻輳制御は最適とは言い難い．そこで，本ミドルウェアは，アクセスポイント (AP) を共有するノード間で TCP のコネクション状況に関する情報を交換し，交換された情報を元にネットワーク負荷を判断し，

TCP の処理を補正する．輻輳制御を補正することにより，各端末に公平な通信帯域を割り当てることが可能であるため，端末間の通信速度の公平性が向上する．さらに，この仕組みにより無線 LAN 内のトラフィックを効果的に制御することができるため，トータルスループットの向上も期待できる．我々は本稿において，このミドルウェアを Android
端末上に実装し，輻輳制御の協調的補正の有効性を示すため実機における評価を行った．
キーワード

Android，モバイルネットワーク，TCP/IP，輻輳制御

Proposal and Implementation
on Cooperative Transmission Control Middleware
on a Smartphone in a WLAN Environment
Hiromi HIRAI† , Saneyasu YAMAGUCHI†† , and Masato OGUCHI†† Ochanomizu University
2-1-1 Otsuka, Bunkyou-ku, Tokyo, 112-8610, JAPAN†† Kogakuin University
1-24-2 Nishi-shinjuku, Shinjuku-ku, Tokyo,163-8677, Japan
E-mail: †hiromi@ogl.is.ocha.ac.jp, ††sane@cc.kogakuin.ac.jp, †††oguchi@computer.org
Key words Android，Mobile network，TCP/IP，Congestion control

1. 研 究 背 景

マートフォンは小型コンピュータという位置付けであるため，
汎用 PC のように動画の送受信やファイルの同期といった大規

近年，日本独自仕様の携帯電話に代わりスマートフォンが普模なデータ通信を行う点が特徴である．しかし一方で，スマー及している．従来の携帯電話は電話と電子メールに加えて低トフォンは，軽量化，及び小型化のために必要最小限のハード

トラフィックなインターネットアクセスが可能であったが，ス

ウェアリソースしか持たないため，処理能力や記憶容量が不十—1—分である．このデメリットを補うために，スマートフォン向け
サービスは，クラウドサーバと連携して，データ処理や定期
バックアップを行うといった仕様が標準になりつつある．

の見積り手法は未だ明らかではない．
他の手段として，Explicit Congestion Notiﬁcation [11] は経路上の不特定の地点においてパケットにビットを立てることで輻

このような社会的背景から，スマートフォンの高速大容量通輳状態を通知する．また Active Queue Management [12] [13] は，信に対する需要は高まっている．近年スマートフォンユーザが

輻輳崩壊が起きる前に，ルーティング機器上で意図的にパケッ増えたことにより 3G 回線が圧迫されているが，帯域不足を克トを損失させる仕組みである．これらの仕組みは差し迫った輻

復するために，無線 LAN アクセスポイント (AP) の設置やモ輳に備えて，セグメント送出量を減らすタイミングを検出する．

バイルルータの携帯が盛んである．そこで本研究は，スマート

しかし，これらの仕組みは，経路上の全てのネットワーク機器

フォンの無線 LAN 利用時における通信性能の向上を試みる．

が対応する時のみ効果的であることから，通信インフラを新規

無線 LAN 利用時の通信性能劣化の原因として輻輳が挙げらに導入する必要があるためコストが大きく，実際には導入が進れる．TCP 通信には，輻輳崩壊を避けるために送り出すパケッ

んでいない．

トの量を回線の状況に応じて調節する制御が存在するが，こ我々の提案は、輻輳の早期発見技術の一つであり，モバイルの輻輳制御は，PC のような汎用コンピュータを想定しており，

端末の変更のみで導入が可能であるため，容易に導入すること

これまで有線志向で設計・開発されてきた．しかし，スマートができる．我々はこれまでに，いくつかの環境に対してチューフォンのように無線通信を常とする端末においては，最適であニングされたアルゴリズムを切り替えるミドルウェアを開発しるとは言い難い．何故なら，スマートフォンにおいては，近くた [14]．しかし，状況に合わせた多種のアルゴリズムを用意し，の AP までは無線アクセスを行うものの，その先は，WAN 等

蓄積されたパターン情報に基づいてアルゴリズムを切替えるとの高帯域ネットワークに支えられたクラウドサーバに繋がっていう手法は，現実世界への導入は必ずしも容易ではない．そこいることが多いためである [1] [2]．既存の輻輳制御は，エンドで本稿においては，我々は周辺環境に合わせて，既存のアルゴ

ツーエンドの経路の状態だけを頼りに，送り出すセグメント

リズムを補正するミドルウェアを提案する．

数を決定しているが，図 1 に示すようなスマートフォンのネッ

1. 2 Android OS

トワーク・トポロジにおいては，輻輳の可能性があるのは，ス

スマートフォン向けオペレーティングシステム (OS) には，

マートフォンと AP の間の低帯域なアクセス区間であると考え様々な種類が存在するが，その中でも一際注目を集めているのられる．本研究は，このようなスマートフォンのネットワーク

が Android OS である．Android OS とは，Google 社が提供するトポロジに最適化した輻輳制御手法の実現を目的とする．

OS，ミドルウェア，アプリケーション，ユーザインタフェース
をセットにした携帯端末向けプラットフォームである．Android

Smartphone 1

OS は，オープンソースで提供されているため，メーカやキャリ

Smartphone 2AP

Smartphone N
図1Long Fat Pipe

External
Network

Wireless
スマートフォンのネットワークトポロジ

アの制約がなく，様々なデバイスに自由に応用することができる．また端末メーカの視点では，標準的な OS が存在することにより，システムの開発費用を大幅に削減することができることが大きな利点である．これらの点から，Android を採用する
携帯端末メーカが増え，現在 Android はトップシェアとなった．

1. 1 関 連 研 究

Android の特徴として，従来の日本独自仕様の携帯電話と異な輻輳崩壊を回避する制御として，TCP Cubic [3] が現在の Linuxり，アプリケーションの開発と導入が容易であること，Linux

カーネルには採用されている．輻輳制御アルゴリズムを改良

Kernel を基盤とする，オープンソースプラットフォームであるするために，近年では以下に述べる仕組みが議論されている．

ためバックグラウンドの処理においても自由な開発が可能であLarge Initial Window [4] [5] は，通信コネクションの初期状態で，ることが挙げられる．

帯域幅を有効に使えていないことに注目し，輻輳ウィンドウの初期値を大きくすることが有効であると示したが，一方で複数端末が帯域を取り合っている場合については，考慮されていな
い．また，TCP Vegas [6] [7] は，損失ベースのアルゴリズムとは大きく異なり，理想の往復遅延時間 (RTT) と実際の RTT の差を元にネットワークの輻輳状態を見積もるアルゴリズムである．
しかしながら TCP Vegas は，競合する全ての端末が，同じ遅延

Application(Home,Telephone,Web)
Application Framework
Android Runtime
Core Libraries, Dalvik VM Ware
LibraryLinux Kernel 2.6
図 2 Android のアーキテクチャ

ベースアルゴリズムを採用している時にのみ効率的に働くが，一方で実世界においては大部分の端末は損失ベースのアルゴリ

図 2 に示すように，Android は Linux Kernel を基盤とし，スズムを採用しているため，実用性が低いと考えられる．このデマートフォンやタブレット端末をターゲットに，それらに適しメリットを補うために Hybrid TCP [8] [9] や Compound TCP [10]たコンポーネントが追加されている [15]．Linux OS と大きく

は，損失モードと遅延モードを備えているが，周辺環境の情報

異なる部分は，独自に開発された Android 用の Runtime であるが不十分であることから，常に効率的に動作する帯域幅遅延積

Dalvik 仮想マシンを搭載している点である．その上にアプリ—2—ケーション・フレームワーク，アプリケーションが乗る形態と末数が増えると性能が劣化することが明らかである．また，端なるため，アプリケーションは Dalvik 仮想マシンに合わせて末数が少ない環境においては，全ての端末が UDP 通信を行っ開発すれば，直感的な操作性に優れた UI を利用することがでている時の方が，トータルスループットが高いが，端末数が多き，移植性も高い．また Dalvik 仮想マシンとは別に，BSD 標

い環境では，TCP 通信を行った時のトータルスループットの方

準 C ライブラリの派生物である Bionic libc が搭載されているたが高くなっており，この結果から端末数が多くなると輻輳制御

め，ネイティブバイナリも実行可能である．本研究が注目するは UDP に比べて帯域を効率良く活用できていると言える．TCP

通信制御は，カーネル内部で処理されているが，トランスポー

通信はエラー率が高くなると輻輳と判断して，送出量を少な

ト層の制御においては，Android 独自の最適化はなく，Linuxくするが，UDP はそのような判断を行わない．一般論として，

foundation [16] により配布される Linux Kernel のソースコード

TCP はパケット損失時に再送を行うため，通信速度が UDP にが利用されている．

劣るが，端末数が多い環境においては，その逆の結果が得られた．この結果は，輻輳制御を効果的に行うと AP やネットワー

2. 複数端末が AP を共有する時の挙動

ク経路が有する全体のトラフィックが制御されるため，再送機

本章においては，実際に複数端末で AP を共有し，帯域が混能を持たない UDP よりも高速な通信性能を実現できることをみ合っている場合の輻輳制御の挙動を確認する．本稿にて示す

示す．すなわち，輻輳制御をより効率良く行うことで，全体の実測値は，以下の図 3 に示す実験装置，及び表 1 に示す実験環

トラフィックの量を調節できれば，トータルスループットは向境を用いたものである．通信性能を測定するベンチマークとし上すると考えられる．輻輳制御が適切にセグメント数を調節し，て，Iperf for Android [17] を利用する．またクラウドサーバは，可用帯域を使い切り，パケット損失が全く起こらない最も理想遠隔地のスマートフォンからアクセスされることが多いため，的な振舞いをしたと仮定した場合，端末数が増えても常に端末

高遅延環境を想定し，往復遅延時間を 256ms とした．この遅延数が少ない時と同じ約 19Mbps の通信速度を維持することが可は，人工遅延装置 Dummynet [18] によって加えられる．

能と考えられ，実際の制御をこれに近づける．

実験環境

Total throughput (Mbps)

表1

Client hostModel number

GT-I9023

Firmware version

Android 4.1 (Jelly Bean)

Baseband version

I9023XXKD1

Kernel version

Linux 3.0.31

Build number

JRO03L

30
25
20
15

TCP

10

UDP

5
0
2

3

図4

複数端末で AP を共有した際の通信速度

Server host4
5
6
The number of hosts

7

8

Operating System Ubuntu10.04.3
Linux version

2.6.32-37-generic-pae

CPUIntel(R) Core(TM) i3 CPU 530@2.93GHz

Main Memory

3GB

2. 2 Android4.1 に搭載される標準の輻輳制御の振舞い
Dummynet

Intel(R) Pentium(R)4 CPU 3.20GHz

Throughput(mbps)

CPU

Access point
Model number

MZK-MF300N

Manufacturer

PLANEX COMMUNICATIONS INC.

Legacy mode

IEEE802.11g

600

25

500

20

400

15

300

10

200

5

100
0

0
0

Android Phone 1

20

40

60
Time(sec)

80

100

120

図 5 標準 TCP を利用する 1 台の端末で AP を占有した時の通信制御

Android Phone 2
Android Phone N

CWND

30

CWND

Throughput

Operating System FreeBSD 6.4-RELEASE

AP

Wired

Dummynet

Wired

ServerWireless

図3と通信速度の遷移

図 5 は，Android4.1 を起動した端末 1 台で AP を占有した時
実験装置の輻輳ウィンドウの値とその時の通信速度を示す．この図から
輻輳ウィンドウと通信速度には，相関関係あることがわかる．

2. 1 複数端末との AP 競合環境における通信性能の劣化
図 4 は，各端末数において AP を共有し同時に通信を行った
時のトータルスループットを示す．端末数が最も低い 2 台で APを共有している時は，UDP で約 25Mbps，TCP で約 19Mbps の

標準 TCP は，通信開始から少しづつ輻輳ウィンドウの値を増加させ，帯域の限界を探査する [19]．また，帯域の限界をパケッ
ト損失によって検出するとウィンドウの値を急激に減少させ，再度増加を試みている．この時，同時に通信速度も急減していトータルスループットを得ることができているが，いずれも端—3—

ることから，コネクション確立時やパケット損失時からのウィ帯域に余裕を持たせる必要がある．通信速度の実測値から，αンドウ増加中に未使用帯域を残してしまっていることがわか=120Kbits が適切と判断し，この値を用いた．この式に基づきる．仮に TCP が予め AP を占有していることを認識していたな

計算された輻輳ウィンドウの最適値を表 2 に示す．

ら，パケット損失を検出しても輻輳ウィンドウを急減させる必

表 2 輻輳ウィンドウの最大値を設定するパラメータ

要はなく，その時点の未使用帯域を有効活用できたと考えられN（端末数）る [20]．

5

6

7

8

MAX CWND 69 57 49 43

2. 3 輻輳制御の補正
輻輳ウィンドウの値は通信速度と相関性があるため，輻輳
ウィンドウの値を操作することで，通信速度が間接的に操作できる．しかし，現状のシステム環境においても有線経路で輻
輳が起こらない保証はないため，フレキシブルにウィンドウス
ケールする必要がある．そこで我々は，無線の可用帯域を上回

表 2 に示される値を，輻輳ウィンドウの上限値とし，AP を共有する複数端末を同時に通信させ通信速度を測定した結果を
図 7 に示す．さらに，Fairness Index を計算した結果を図 8 に示す．Farness Index [22] とは，計算方法を以下に示すが，公平性を示す指標であり，1 に近いほど高い公平性を示す．

るパケット送出を防止し，同時に経路全体の輻輳を回避するた

∑k
xi )2
f i = ∑i=ik
2

めには，エンドツーエンドで輻輳制御を行うデフォルトの輻輳

(制御アルゴリズムは活かしながら，これに加えて輻輳ウィンド

k

i=i

(1 <
=i<
= k)

xi

ウの最大値を設けることが望ましいと判断した．図 6 は，プロセスインタフェースに輻輳ウィンドウの上限値を表す変数を実設定する本手法を「輻輳制御の補正」と呼ぶ．

12
8
4

15
10
5
0
16ms

32ms

64ms
RTT

128ms 256ms

図 6 輻輳ウィンドウの上限値を各値に固定した端末のAP 占有時における通信速度

2. 2 節より，TCP Cubic の輻輳制御は，エンドツーエンドの起こしていることが示された．スマートフォンのネットワーク

0.96
0.94
0.92
0.9

5

図7

6
7
8
The number of hosts

通信速度の比較

5

6
7
8
The number of hosts

図 8 公平性の比較

Throughput

5

CWND

500

4

400

3

300

2

200

1

100

0

0
0

パケット損失によってのみ可用帯域を検出しているため，輻輳
ウィンドウの大きさが定まらず，未使用帯域や帯域混雑を引き

Adjusted

0.98

0

max_cwnd=16
max_cwnd=32
max_cwnd=64
max_cwnd=128
max_cwnd=256
max_cwnd=512
max_cwnd=1024

20

Default

1.02
1

16

Throughput(Mbps)

Throughput(Mbps)

25

Adjusted

Fairness Index

では，適切な帯域活用を行うために輻輳ウィンドウの上限値をThroughput(Mbps)

占し，60 秒間の TCP 通信を行った際の通信速度を示す．本稿Default

20

CWND

装し，上限値を各値に設定した Android 端末が単独で AP を独

10

20

30
Time(sec)

40

50

60

図 9 標準の輻輳制御を利用する 5 台の端末で AP を共有した時の通信
制御と通信速度の遷移

送及び，損失後の通信速度の低下を抑制することが可能だと考えられる．周辺環境が明らかであることを仮定すると，輻輳ウィンドウの理想値を次の式で計算することができる．N は端末数を示す．

Ideal cwnd =ているが，現実世界で実際に観測可能な最高転送速度は 20Mbps
程度 [21] であるため，この値に遅延時間を掛けたものを帯域幅遅延積 (BDP) とする．また，α=0Kbits の時，この式は理想的な輻輳ウィンドウを求められるが，現実世界においては適度に

CWND

100

4

80

3

60

2

40

1

20
0

0

BDP − αSegment size × N

IEEE802.11g の場合，理想的な最高転送速度は 54Mbps とされThroughput

5

0
図 10

CWND

フィックを調整することにより，輻輳によるパケット損失と再Throughpu(Mbps)

トポロジにおいて，無線 AP を共有する端末間で全体のトラ

10

20

30
40
Time(sec)

5060

補正した輻輳制御を持つ 5 台の端末で AP を共有した時の通信
制御と通信速度の遷移

さらに我々は，通信速度と公平性の向上が，輻輳制御の補正によって実現されたことを証明するために，端末数 5 台が競合通信を行ったうちの 1 台の端末の輻輳ウィンドウと通信速度の—4—

遷移を解析した結果を図 9，10 に示す．補正した輻輳制御を利知自体がオーバヘッドとならないよう柔軟な変更が可能である．

用した TCP 通信は，安定した適度な通信速度を維持している

この様子を図 12 に示す．また通知する情報の取得方法についことがわかるが，一方で標準の輻輳制御を利用した TCP 通信ては 3. 1 節で詳説する．

は，通信速度は過度な増加と減少を繰り返している．また補正

一方で輻輳制御補正モジュールは，周辺端末からブロードした輻輳制御に比べると，大きな輻輳ウィンドウを保持する場

キャストされた情報を収集し，無線 LAN が保有しているトラ合が多いが，実際には輻輳ウィンドウが大きい時も通信速度は

フィック量を計算する．この計算結果から周辺状況を判断し，下がっていることがある．これは，複数端末が競合しトラフィッ

自らの輻輳制御を補正して，可用帯域を過度に活用することがクが溢れているために，MAC 層における CSMA/CA レベルでないようにする．

の衝突が多数発生し，再送が繰り返されたことが原因だと考え

本ミドルウェアは，C 言語で記述されたプログラムをクロス
コンパイル [23] することで，Android 端末に導入している．ネられる．
これらの測定結果 (図 7，8) と解析結果 (図 9，10) から，複イティブバイナリは，Android 独自の DalvikVM を利用しない

数端末が競合する環境においては，上限値を設定することで輻ため，バックグラウンドで端末に高負荷を与えることなく高速

輳ウィンドウを過度に増加させないことが，通信速度の向上に処理を行うことが可能である．

効果的であることが明らかである．また本手法により，各端末

3. 1 カーネル解析システムツールに利用可能な帯域を均等に割り当てられ，一部の端末が帯域を協調制御ミドルウェアの一部である情報共有モジュールは，使いすぎることがなく，帯域をシェアすることができたため，通信処理があった時にカーネル内部の通信状況に関する情報公平性が向上したと考えられる．

を解析し，周辺端末に提供する．カーネル内部の処理は，通常
バックグラウンドで進められているため，ユーザ空間からその3. 協調制御ミドルウェアの実装

処理を監視することはできない．そこで本研究では，カーネル

2. 3 節に示された輻輳制御の補正を効果的に行うには，周辺環境を認識し，適応する必要がある．本章では，AP を共有する端末同士が互いに情報交換を行い，収集した情報に基づいて，内部の通信処理を解析するために，カーネルモニタを Androidに組込んだ．
カーネルモニタとは，Linux システムのカーネル内部の処理を解析する汎用 PC 向けシステムツールである．既存研究 [24]輻輳制御を補正する仕組みを示す．

が，既にカーネルモニタの Android への組込みに成功しており，
Notification

Other Hosts

同様の方法で導入を行った端末を本研究においても利用する．

cwnd, que length,
ca_state, …

Application

Notification
cwnd, que length,
ca_state, …

Adjustment

図 13 に示すようにカーネルモニタは、カーネルプロセスのMiddleware

Transmission
Adjustment

Notification

Broadcast Self
Information

タは様々な変数の値を取得可能とするが，本研究では TCP の
cwnd, que length
ca_state …

TCP/IP

監視及びパラメータのログの取得が可能である．カーネルモニ
処理にモニタ関数を組込み，輻輳ウィンドウ，RTT，ソケット
バッファキュー長，CA 状態を取得可能とした．CA 状態とは，

図 11

協調制御ミドルウェアの概念図

経路の状態を示すパラメータであり，正常の場合は Open，エラーを検出した場合は，それぞれ Disorder，CWR，Loss とな

Android
Phone
Android
Phone

る．取得されたパラメータはカーネル内のメモリ空間に記録さAndroid
Phone

TCP
StatusTCP
StatusTCP
Statusれ，プロセスインタフェースを介してミドルウェアが定期的にAndroid
Phone
Android
Phone

TCP
Status

アクセスすることが可能となる．このような方法により，ミド
ルウェアは間接的に通信の手続きを監視する．

TCP
StatusProcessing …

WLAN

AP

RouterOther
Networks(Cloud)Android Phone

図 12協調制御ミドルウェアの概念図

本ミドルウェアは，図 11 に示す 2 つのモジュールによって/* Decrease cwnd. */stac void tcp_cwnd_down(){
if(ca_state == 4){Applicaon
TCP
IP

Trace of Prams

TCP Source CodeKernel Monitor Funcon

Monitoring

tp->snd_cwnd = 1;}

Ethernet

Kernel Monitor Funcon

}

図 13

write

cwnd = 4 , ca_state = 0, …
cwnd = 8 , ca_state = 0, …
cwnd = 16 , ca_state = 0, …
cwnd = 32 , ca_state = 0, …
cwnd = 64 , ca_state = 4, …
cwnd = 1 , ca_state = 0, …
cwnd = 2 , ca_state = 0, …
cwnd = 4 , ca_state = 0, …
cwnd = 8 , ca_state = 0, …

カーネル解析システムツール

構成される．一方は，自らの通信処理を監視し，AP を共有する周辺端末に通信状況に関する情報を通知する役割を持つ情報

4. ミドルウェアの評価実験

共有モジュールである．このモジュールによる情報通知パケッ
トは，UDP のブロードキャストを利用するため，AP を共有す

4. 1 実 験 概 要る全ての端末に向けて転送されるが輻輳時には破棄される．本

本稿が提案するミドルウェアの効果を示すため，以下の評価

稿では，情報通知の間隔は 0.5 秒とするが，この間隔は情報通実験を行った．本ミドルウェアの特徴は，周辺端末に通信状況に関する情報を通知する点と，周辺端末からの通知を受けて，—5—

全体のトラフィックを予測し，輻輳制御を補正する点であるた
500

バヘッドにならないこと，アクティブに通信を行っている周辺400

端末数を通知パケットによって正確に認識できていることを示す必要がある．そこで，我々は，測定時間中にアクティブな送

CWND

め，ミドルウェアが定期的にブロードキャストする通知がオー

Host1
Host5

Host2
Host6

60

120
Time(sec)

Host3
Host7

Host4
Host8

300
200

信端末数が 5 台から 8 台まで増える場合と，アクティブな送信100

端末数が 8 台から 5 台まで減る場合を想定し，実験 1 と実験 200を行った．実験装置は，図 3 と同様とする．実験 1 と実験 2 の

180

240

アクティブな端末数の時系列変化を図 14，15 に示す．実験時
図 18間は合計 240 秒であるが，60 秒間隔で端末が 1 台ずつ通信を開始もしくは終了し，アクティブな送信端末数は増加もしくは100

数が増える場合には，通知パケットを受信した時に通知元の IP

80

アドレスを記憶し，送信端末数を更新する．一方で，送信端末が減る場合には，一定時間内に通知パケットを受けなかった IP

CWND

減少する．このような環境においてミドルウェアは，送信端末

実験 1：標準 TCP を利用した端末の輻輳制御の振舞い

Host1
Host5

Host2
Host6

60

120
Time(sec)

Host3
Host7

Host4
Host8

60
40

アドレスを削除することで，記憶している送信端末数を定期的20に更新している．本実験では，輻輳制御補正モジュールの端末

00

数更新間隔は 10 秒とする．このような送信端末数が変化する

180

240

環境におけるオーバヘッドを含めた通信速度を測定し，ミドル
図 19

ウェア導入による効果を示す．
通信開始

終了

通信開始

終了

実験 1：ミドルウェアを導入した端末の輻輳制御の振舞い
Host1
Host5

Host2
Host6

60

120
Time(sec)

Host3
Host7

Host4
Host8

500

Host 1
Host 2
Host 3
Host 4
Host 5
Host 6
Host 7
Host 8Host 1
Host 2
Host 3
Host 4
Host 5
Host 6
Host 7
Host 8
0

60

120

180

CWND

400

図 14 実験 1:端末数が増える場合 図 15

200
100
0

0

240 sec

300

60

120

180

0

240 sec

4. 2 実 験 結 果

1.5
1
0.5

2

Default

host1~5 host6

host7

Host1
Host5

Host2
Host6

60

120
Time(sec)

Host3
Host7

Host4
Host8

80

1.5
1

60
40
20

0.5

0
0

0

実験 2：標準 TCP を利用した端末の輻輳制御の振舞い

100

Adjusted

CWND

Adjusted

Throughput(Mbps)

Throughput(Mbps)

Default240

実験 2:端末数が減る場合
図 20

2

180

host8

図 16 実験 1:端末数が増える場合 図 17

host1

host2

host3 host4~8

0

180

240

実験 2:端末数が減る場合
図 21

実験 2：ミドルウェアを導入した端末の輻輳制御の振舞い

本評価実験の結果を図 16，17 に示す．アクティブな送信端末数が変化する環境下で，ミドルウェアを導入し，オーバヘッドを含めた通信速度を測定したところ，ミドルウェアを利用せず標準 TCP のみで制御した場合よりも，ミドルウェアを導入
し輻輳制御を補正した場合の方が，全ての端末において，通信速度が向上している．
また，実験 1，2 の輻輳制御の振舞いを解析した結果を図 18，

19，20，21 にまとめる．図 19，21 より，ミドルウェアを導入
した場合，全ての端末数の輻輳ウィンドウの上限値は統一されており，各送信端末数に応じて表 2 に基づき正しく補正されたことがわかる．

さらに，これらの解析結果から，図 18，20 より，標準の輻輳制御を利用した時の輻輳ウィンドウの振舞いは，周辺端末との協調が取られず，緩やかな増加と急激な減少を繰り返していることが確認できる．一方で，ミドルウェアを導入した端末の輻輳ウィンドウの振舞いを観察すると，輻輳ウィンドウの上限
値が制限されたことにより，安定したウィンドウサイズを保っており，転送エラーがほとんど発生していないことが明らかである．また，新たな周辺端末の通信開始時や通信終了時にも，ミドルウェアがすぐに適応し，効率的な通信が実現されている．
よって，本提案ミドルウェアが複数端末の競合通信時に有効で—6—

あることが示された．

5. まとめと今後の課題
標準的な輻輳制御アルゴリズムは有線ネットワーク向けに開発されてきたため、無線 LAN 環境下では常に良いとは限らない．標準の TCP コネクションは，端末間で互いに独立した制御を行うが，無線通信においてはノイズや電波干渉による任意の

うなってしまった場合には，ミドルウェアを持たない端末数が一定割合を超えた時に，輻輳制御の自動補正を停止させ，標準の輻輳制御を利用すべきである．そうすれば，本ミドルウェア
は常に現状維持もしくは，標準よりも良い通信性能を提供することが可能である．

謝辞

パケット損失があるため，損失ベースの Cubic は影響を受けや本研究は一部，独立行政法人情報通信研究機構の委託研究

すく性能劣化が顕著である．また無線接続区間は有線接続区間「新世代ネットワークを支えるネットワーク仮想化基盤技術のに比べて低帯域であるため，ほぼ常に無線区間がボトルネック

研究開発・課題ウ 新世代ネットワークアプリケーションの研究になっていると考えられる．

開発」によるものである．

我々は，スマートホン市場でシェア率の最も高い Android 端
末向けのミドルウェアを開発し，実際にその効果を示した．本ミドルウェアはカーネルモニタを利用して通信状況に関する情報を取得し，その情報をブロードキャストにより AP を共有す
る全ての端末に送信する．この情報通知により，環境に適応するため，ネットワーク上のトラフィック推測で輻輳制御を補正する．評価結果によれば，提案手法を導入した Android 端末上
で通信速度と公平性が向上が確認できた．本稿では，Android
プラットフォームにおいて，この協調的通信制御手法の有効性を証明したが，ミドルウェアを組込むことができれば，本手法は如何なるスマートフォンプラットフォームにおいてもその効果を発揮すると考えられる．
しかし，本ミドルウェアは，なお多くの課題を持つ．本稿では典型的なケースが紹介したが，自然環境には様々な状況が存在する．
（ 1 ） スマートフォン端末は海外などの遠隔地に存在するク
ラウドサーバにアクセスすることが多いが，常にその前提が成り立つとは限らない．そのような場合は，各 TCP コネクション
ごとに個別の RTT に基づいて，帯域幅遅延積を計算し，通信帯域を埋めつつも公平性を維持できる制御が必要となる．
（ 2 ） AP を共有する全ての端末が常に奪い合っているわけではない．本稿の実験においては，ベンチマークソフトウェアを利用し，大きなデータを転送する端末を実験装置としたが，現実世界においては，メールの送信等の帯域をさほど必要としない低トラフィックな通信を行う端末も存在する．このような端末にも公平に帯域を割り当てることは，かえって未使用帯域を残すことに繋がる．そこで，ソケットバッファキュー長を確認し，ユーザの通信需要に合わせた帯域割り当てを行うことが効果的であると考えられる．
（ 3 ） 本稿では，アップリンクについて言及し，実装ならびに評価を行ったが，アップリンクと同様ダウンリンクにおいても輻輳による通信性能劣化の問題は存在する．ダウンリンクについても MAC 層に頼るのではなく，トランスポート層においてパケット溢れを防止する対策が有効であると考えられる．
（ 4 ） 本稿では，AP を共有する全ての端末がミドルウェアを持つ時の評価を行ったが，ミドルウェアを持たない端末との混在環境については言及していない．そのような環境においても実験を行い，輻輳制御の補正により，かえって通信性能が低下してしまうことがないことを確認する必要がある．万一，そ文

献[1] Feng, Wu-chun, Pavan Balaji, Chris Baron, Laxmi N. Bhuyan,
and Dhabaleswar K. Panda. ”Performance characterization of a 10Gigabit Ethernet TOE,” Proceedings of IEEE Symposium on High
Performance Interconnects - HOTI , pp. 58-63, 2005.
[2] Chase, Jeffrey S., Andrew J. Gallatin, and Kenneth G. Yocum. ”Endsystem optimizations for high-speed TCP,” Communications Magazine, IEEE 39, no. 4 (2001): 68-74.
[3] Sangtae Ha, Injong Rhee and Lisong Xu, ”CUBIC: A New TCPFriendly High-Speed TCP Variant,” Proceedings of SIGOPS Operating Systems Review, 42(5):64-74, 2008.
[4] Dukkipati, Nandita, Tiziana Reﬁce, Yuchung Cheng, Jerry Chu, Tom
Herbert, Amit Agarwal, Arvind Jain, and Natalia Sutin. ”An argument for increasing TCP s initial congestion window,” ACM SIGCOMM Computer Communication Review 40, no. 3 (2010): 27-33.
[5] Allman, Mark, Chris Hayes, and Shawn Ostermann. ”An evaluationof TCP with larger initial windows,” ACM SIGCOMM Computer
Communication Review 28, no. 3 (1998): 41-52.
[6] Brakmo, Lawrence S., Sean W. O’malley, and Larry L. Peterson.
”TCP Vegas: New techniques for congestion detection and avoidance,” Vol. 24, no. 4. ACM, 1994.
[7] La, Richard J., Jean Walrand, and Venkatachalam Anantharam. ”Issues in TCP vegas,” Electronics Research Laboratory, College of Engineering, University of California, 1999.
[8] Kaneko, Kazumi, Tomoki Fujikawa, Zhou Su, and Jiro Katto. ”TCPFusion: a hybrid congestion control algorithm for high-speed networks,” Proceedings of Protocols for Future, Large-Scale & Diverse
Network Transports (PFLDNeT), 2007.
[9] Masafumi Hashimoto, G. Hasegawa, M. Murata. ”Performance Evaluation and Improvement of Hybrid TCP Congestion Control Mechanisms in Wireless LAN Environment,” Proceedings of Telecommunication Networks and Applications Conference, Australasian ATNAC , 2008.
[10] Song, Kun Tan Jingmin, Q. Zhang, and M. Sridharan. ”Compound
TCP: A scalable and TCP-friendly congestion control for high-speed
networks,” Proceedings of Protocols for Future, Large-Scale & Diverse Network Transports (PFLDNeT), 2006.
[11] Floyd, Sally. ”TCP and explicit congestion notiﬁcation,” ACM SIGCOMM Computer Communication Review 24, no. 5 : 8-23, 1994.
[12] Firoiu, Victor, and Marty Borden. ”A study of active queue management for congestion control,” Proceedings of IEEE International
Conference on Computer Communications (INFOCOM), vol. 3, pp.
1435-1444, 2000.
[13] Floyd, Sally, and Van Jacobson. ”Random early detection gateways
for congestion avoidance,” IEEE/ACM Transactions on Networking- TON , vol. 1, no. 4, pp. 397-413, 1993.
[14] Hiromi Hirai, Kaori Miki, Saneyasu Yamaguchi, and Masato Oguchi,”A Study on Transmission-Control Middleware on an Android Terminal in a WLAN Environment,” Proceedings of the Fourth International Conference on Wireless, Mobile Networks & Applications(WiMoA-2012)，pp.469-479, Delhi，India，May 2012.
[15] Android open source project, http://source.android.com—7—

[16] The Linux Kernel Archives, http://www.kernel.org/[17] Iperf For Android Project in Distributed Systems, http://www.
cs.technion.ac.il/∼sakogan/DSL/2011/projects/iperf/
index.html[18] The dummynet project, http://info.iet.unipi.it/∼luigi/
dummynet[19] Stevens, W.R.: ”TCP Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery Algorithms,” The Internet Society(RFC2001), 1997.
[20] Xylomenos, George, George C. Polyzos, Petri Mahonen, and Mika
Saaranen. ”TCP performance issues over wireless links,” Communications Magazine, IEEE 39, no. 4 (2001): 52-58.
[21] De Bruyne, Jeffrey, Wout Joseph, Leen Verloock, and Luc Martens.
”Evaluation of link performance of an indoor 802.11 g network.” Proceedings of Consumer Communications and Networking Conference(CCNC), 5th IEEE, pp. 425-429. IEEE, 2008.
[22] D.-M. Chiu and R. Jain, Analysis of the increase and decrease algorithms for congestion avoidance in computer networks, Computer
Networks and ISDN Systems, vol. 17, pp. 1-14, 1989.
[23] Sourcery G++ Lite for ARM GNU / Linux, http://www.
codesourcery.com[24] Miki, Kaori, Saneyasu Yamaguchi, and Masato Oguchi. ”Kernel
Monitor of Transport Layer Developed for Android Working on Mobile Phone Terminals,” Proceedings of The Tenth International Conference on Networks (ICN), pp. 297-302. 2011.

—8—