DEIM Forum 2017 H2-3

Android OS における協調的輻輳制御手法による異種クライアント端末通信性能の向上
島田 歩実†

山口実靖††

小口 正人†† お茶の水女子大学 〒 112–8610 東京都文京区大塚 2-1-1†† 工学院大学 〒 163-8677 東京都新宿区西新宿 1-24-2
E-mail: †ayumi@ogl.is.ocha.ac.jp, oguchi@is.ocha.ac.jp, ††sane@cc.kogakuin.ac.jp
あらまし 近年のロスベース TCP はより高いスループットを確保するためにアグレッシブな輻輳制御手法を用いているが，無線接続環境においてはその手法によって膨大なパケットが無線 LAN アクセスポイントに蓄積され，その結果輻輳が発生してしまうという問題が生じている．先行研究では，ロスベース TCP の一種である CUBIC-TCP を輻輳制御アルゴリズムとして使用している Android 端末を用いて，無線 LAN アクセスポイントにおける ACK パケッ
トの蓄積を回避する協調的制御手法がスマートフォン端末向けに提案，実装された．本研究では，スマートフォン向けの既存手法をタブレット端末にナイーブに適用し，その性能向上の程度を示す．また，既存手法に改善を加えさらなる性能向上を実現する手法を提案する．そして性能評価により，通信速度と公平性が先行研究の手法よりも多数台
同時通信においてスマートフォンとタブレット共に向上したことを示す．
キーワード

輻輳制御，TCP，Linux，ミドルウェア，無線通信，Android

A Study of Android Tables Performance
Ayumi SHIMADA† , 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: †ayumi@ogl.is.ocha.ac.jp, oguchi@is.ocha.ac.jp, ††sane@cc.kogakuin.ac.jp

1. は じ め に十分な通信性能を発揮することができないという問題がある．
そこで先行研究では，輻輳制御アルゴリズムとしてロスベー

TCP プロトコルは，インターネットにおいて標準的に利用

ス方式の一種である CUBIC-TCP を採用している AndroidOSされているプロトコルの一つであるが，近年のインターネットを用いて，無線 LAN アクセスポイントにおける ACK パケッ

は通信速度と安定性が求められているため，TCP プロトコル

トの蓄積を回避する協調的制御手法がスマートフォン端末向けはより高いパフォーマンスを得るために改善がなされてきた．

に提案，実装された [1] [2] [3]．手法としては，同一 AP に接続

TCP の輻輳制御アルゴリズムには，ロスベース，遅延ベース，された端末数とクライアントサーバ間の往復遅延時間 (RTT)

ハイブリッドアルゴリズムの３種類があり，パケットロスを検の二つのパラメータをエンドホスト側でリアルタイムに観測知した時に輻輳ウィンドウを減少させる方式をとるロスベース

することで，その通信環境における理想的な輻輳ウィンドウ値

アルゴリズムは，Linux の標準 TCP アルゴリズムとしても採(CWND) をシステムが自動で算出し，補正を行う．この AP用されている．しかし，近年のロスベース TCP はより高いス

周りでの ACK パケットの蓄積を回避する手法により，端末間

ループットを確保するためによりアグレッシブにパケット送信

で通う帯域を公平に分け合うことで全体の通信速度と公平性のを行う輻輳制御手法を用いており，有線接続と比べて脆弱な無向上を実現している.

線接続環境においてはその手法によって膨大なパケットが蓄積

本研究では，本手法によるスマートフォンとタブレット端末

され，特に，同一アクセスポイント (AP) に接続する端末台数の通信性能の向上及びその改善について考察する. 具体的には，が多い場合は AP の通信機会が減ってしまうため，AP に膨大

スマートフォン向けの既存手法をタブレット端末にもナイーブな ACK パケットが蓄積されてしまう. その結果パケットロスに適用し，その性能向上の程度を示す．また，既存手法に改善や輻輳などの深刻なエラーが発生し，エンドホスト側の端末がを加えスマートフォンとタブレット端末の両方においてさらなタをリアルタイムにモニタする汎用 PC 向けシステムツールでる性能向上を実現する手法を提案する.
本論文の構成は以下の通りである．2. 章で研究背景についてある．図 2 に示したように，TCP のソースコードにモニタ関述べ，3. 章で先行研究について紹介をする．続いて 4. 章で基数を挿入し，カーネルを再構築することで，メモリからログを礎実験について示す．5. 章で先行研究のシステム評価実験とそ得ることが可能となる．既存研究 [1] は，すでに Android が搭の結果を示し，6. 章で先行研究のシステムへの改変内容とその載されたスマートフォン端末へのカーネルモニタの組み込みに評価実験と結果を示す．最後に，7. 章で本稿をまとめる．

成功しており，本研究においては同様の方法でスマートフォン
端末だけでなくタブレット端末への導入も行った．

2. Android OS
本研究では，Android プラットホーム上で動作するシステム
を扱う．Android OS [5] は Google 社が開発した OS で，オープンソースであることから誰でも自由にカスタマイズ可能であるという特徴を持つ．また Linux カーネルがベースとなっており，
ロスベース TCP の一種である CUBIC-TCP [7] を輻輳制御ア
ルゴリズムとして採用している．CUBIC-TCP は BIC-TCP [6]の改良版であり，BIC のスケーラビリティを維持しながらウィ

図 2 カーネルモニタの概要

ンドウサイズ制御が簡素化した高速 TCP である．
図 1 は CUBIC-TCP の振舞で，縦軸が CWND，横軸が時間

3. 2 輻輳制御ミドルウェア

を示す．最後のパケット損失時からの経過時間を元に 3 次関数

先行研究 [2] [3] で開発された輻輳制御ミドルウェアは， カー(1) によりウィンドウサイズを算出し，パケットロスが検出さネルモニタをベースとしたシステムであり，無線 LAN-AP にれるとウィンドウサイズを急減させる．3 次関数の C はスケー

おける ACK パケットの蓄積を回避し，複数の端末が同一の AP

ルファクタ，t は最後のパケット損失時からの経過時間，Wmaxに接続して通信するときの全体の通信速度と公平性の向上を可

は最後のパケット損失時のウィンドウサイズを表す．

能にしている．

このように CUBIC-TCP は遅延ベースアルゴリズムと比べ具体的な制御方法は以下の通りである．

経路の状況を把握せずに通信をするため，パケット損失が生じるまで各端末がアグレッシブに通信をし過ぎる傾向がある. よって無線接続環境においては AP 周りで ACK パケットの蓄積が生じ輻輳の原因になってしまうといった問題がある．

(1) AP を共有する端末間で UDP パケットをブロードキャ
ストし合うことで，同じ AP への同時接続端末数を把握.

(2) (1) で検知した接続台数と式 2 から, 適切な CWND サ
イズの上限値候補 1 と下限値候補 1 をそれぞれ算出.

(3) カーネルモニタから現在の RTT 値と最小 RTT 値を取得.

(4) (3) から 式 5 を用いて RTT 増減量を計算.
(5) RTT 増減量と表 1 から, 適切な CWND サイズの上限
値候補 2 と下限値候補 2 をそれぞれ算出.

(6) 上限値候補 1 と上限値候補 2，下限値候補 1 と下限値
候補 2 をそれぞれ比べ，小さいほうを最適な CWND の上限値
及び下限値としてプロセスインタフェースに 0.5 秒ごとに書き

図 1 CDUBIC-TCP の振舞

込み，補正．

√
Wcubic = C(t −3Wmax 3) + WmaxC(1)

3. 先 行 研 究
3. 1 カーネルモニタ
カーネル内部の処理は通常バックグラウンドで進められているため，通常ユーザ空間からその処理の様子を監視することはまた，先行研究 [4] において帯域幅は接続台数に伴い変化することが確認されているため，帯域幅に関しては，式 3 から計算した値を用いている. ただし，BWmax はその通信環境における最高通信速度，f(端末数) は端末数の増加による合計通信速度の低下を表す単調減少の関数であり，式 4 を用いている．
接続台数が増えるほど，CWND の補正値は小さくなる．

できない．そこで既存研究 [1] によりカーネル内部の情報を見るためにカーネルモニタと呼ばれるツールが開発された．カー

Ideal cwnd =Bandwidth[M bps] × RT T [sec](2)
Segmentsize(1.5Kbyte) × N umberOf T erminals

ネルモニタは本研究のベースとして用いられており，Android
端末の TCP 通信時における輻輳ウィンドウサイズ (CWND)
や往復遅延時間 (RTT) などのカーネル内部の様々なパラメー

Bandwidth = BW max × f (N umberOf T erminals) (3)f (N umberOf T erminals) = N umberOf T erminals−0.15 (4)さらに，通信中はカーネルモニタを 0.5 秒単位で常時監視し，その時点の RTT(current rtt) とその最小値 (min rtt) を取得する．min rtt は，通信中で最も小さい RTT を常に上書きしていくことで値を更新する. 取得した値をもとに式 5 を用

図 3 実験トポロジ

いて RTT の増減量 (ratio rtt) を求める．そして表 1 のように
表2

ratio rtt の大きさに従って，CWND の上限値候補と下限値候補を定める．特に ratio rtt が 331.0 以上になるとトラフィック

Nexus 5Nexus 7が混んできたとみなし，CWND を１にして一時的に通信最小

Firmware version

5.1.1

6.0.0

モードに移行し，その後に起こり得るさらなる遅延を回避する．

Kernel version

3.4.0-geaa8415-dirty 3.4.0-g272b14b-dirty

Build number

LMY49H

RTT 増減量が大きくなるほど，CWND の補正値は小さくなる．
ratio rtt = current rtt − min rtt

Android Model number

実験環境

server(5)

MRA58KOS

Ubuntu 14.04 (64bit) / Linux 3.13.0

CPUIntel(R) Core(TM)2 Quad CPU Q8400

Main Memory
AP

Model

8.1GiBMZK-MF300N(Planex)

Communication system

IEEE 802.11g

表 1 RTT 値による制御パラメータ

ratio rtt

0-51-

106- 161- 331-

max cwnd2 555 555

555

555

555

min cwnd2

10

2

1

200

50

4. 2 実 験 結 果
スマートフォン端末，タブレット端末それぞれの端末数増加時における合計通信速度の評価結果を図 4 に示す．スマート

これらの制御によって，通信中において同じ AP を共有する
他端末が通信を始めたことやそれに伴って急に RTT の値が増加したことを本システムが検知すると，リアルタイムに CWND
を理想的な値に補正することでトラフィック発生量を制限し，途中から通信を始めた端末にも均等に帯域を分け合えるよう制フォン端末は 3 台同時通信，タブレット端末は 2 台同時通信をピークに，台数が増加するほど合計通信速度も減少することが確認できた．
この結果より，同時接続端末数の増加と共に減少するスルー
プットの向上が求められると考察することができる．

御することができる．
ただし本システムの制御手法は，AP 周りの通信状況に基づき，問題が発生した場合にのみ迅速に CWND の最大値と最小値を定めるだけであり，その範囲の中でデフォルトの TCP ア
ルゴリズムによる制御が行われる．このように，基本的な TCPの輻輳制御アルゴリズムは変更せずエンドホスト側にのみ変更を加えるだけであるため，本システムの導入は容易である．
本研究では，近年スマートフォン端末と共に普及しているタ
ブレット端末にもこのシステムを組み込み，従来のスマートフォンに加え，より性能の高い端末が同一 AP に接続して通信を行うときの全体の通信性能の検証実験を行う．

図4

端末数変化時における合計通信速度

4. 基 礎 実 験
4. 1 実 験 概 要
まず基礎実験として，本研究で用いる Android 端末である，
スマートフォン端末 (Nexus 5) とタブレット端末 (Nexus 7) の評価を行った．
図 3 と表 2 に実験環境を示す．サーバ機と AP の間に人工

5. 性能評価実験
5. 1 実 験 概 要
続いて，先行研究によって開発された輻輳制御ミドルウェアの性能を評価すべく，スマートフォン端末及びタブレット端末にミドルウェアをナイーブに適用した．

遅延装置 dummynet [8] を挟み，有線部の往復遅延時間を特に

4. 章と同様の実験環境下において，スループットやカーネル

輻輳が生じやすい高遅延環境を模擬するために 512ms に設定

モニタによって観測されたパラメータ値から，それぞれの端末している．この環境において一つの AP に接続した Androidの振舞を検証，評価した．

端末とサーバ間において iperf [9] を用いて通信を行い，ネット

5. 2 実 験 結 果

ワーク全体の通信スループットを測定した．この環境において，合計の通信速度の評価結果を図 5 に示す．青のグラフはス

Android 端末の台数を 1 台から 6 台まで 1 台ずつ増加させた．

マートフォン端末 (Nexus 5) の結果，赤のグラフはタブレット
端末 (Nexus 7) の結果であり，スマートフォン端末，タブレッ

ト端末それぞれにおける，補正を行わないデフォルトのミド
ルウェアオフの状態，輻輳制御手法による補正を行ったミドル
ウェアオンの状態の結果を示す. グラフより，スマートフォン
端末においては 3 台同時通信，6 台同時通信共に，スループットの向上が見られるが，やはり台数増加と共に通信性能が落ちる減少に変わりはないことがわかる．一方，タブレット端末においては，6 台同時通信においては多少のスループットの向上が見られるが，3 台同時通信においては大きく低下してしまうといった結果が得られた．
以上の結果より，台数増加と共に急激に通信速度が低下する
減少や，ミドルウェアによる性能の低下を改善すべく，輻輳制

図 6 CWND の推移 (改良前 1)

御法に改良を加えた．その改良の詳細は 6. 節に示す．

図 7 CWND の推移 (改良前 2)
図 5 合計通信速度 (改良前)

表 3 RTT 値による制御パラメータ改善前

6. 既存研究の改良

改善後

ratio rtt max min max min
0-555

200 1000 200

6. 1 改良点詳細

51-

200

50

700

150

5. 節の実験から確認した問題点を解決すべく，先行研究に

106-

100

10

400

100

よって提案された輻輳制御手法を改変した．図 6 と図 7 は先行

161-

10

2

200

10

研究のミドルウェアによって制御された CWND の 6 台同時通

331-

1

1

50

1

信における推移を示す．3. 2 節に記述したように，本システム
は通信中において同じ AP を共有する他端末が通信を始めたことに伴って急激に RTT 値が増加したことを感知すると，輻輳
制御法を発動する．図 6 は全端末の RTT 値が急激に増え，本制御手法が発動し，CWND が制御されている場合であるが，全ての端末において CWND の抑制が厳しすぎる様子がわかる．また図 7 は，6 台中 2 台のみの RTT 値が急激に増加し，本制御手法が発動している場合であるが，本システムによってCWND が制御されている 2 台の端末の CWND が厳しく抑えられているのに対し，その他 4 台の端末は本手法が発動していないことによって帯域を大きく占領している．このように，本システムが発動している端末とそうでない端末が混在する場合に，それぞれの端末に与えられる帯域に大きな差が出てしまい，
全体の公平性が落ちていることが確認できた．そこでこれらの点に着目し，CWND の抑制を緩くすることで，全端末において本システムが発動している場合に，帯域を無駄なく使用するようにした．また，本システムが発動している端末とそうでな
い端末が混在する場合には，帯域の使用量の差が縮まるようにした．その変更点を表 3 に示す．

3. 節に示したように，本システムは通信中において同じ APを共有する他端末が通信を始めたことやそれに伴って急に RTTの値が増加したことを本システムが検知すると，リアルタイムに CWND を理想的な値に補正する. 特に表 3 の改良前の制御パラメータ値を見てわかるように，RTT 増減量が大きくなる
ほど CWND の下限値が非常に小さく設定してあり，これが図6 や図 7 に見られた結果の原因であると予測した．そこで，表3 の改善後の制御パラメータ値のように変更を加え，CWNDの抑制を緩くした．以上のように改良された制御法によって制御された CWND の振舞を図 8 と図 9 に示す．図 8 は全端末において本システムが発動している場合であるが，改良前よりも制御されている CWND の振舞が大きくなっている．また，図9 は，約 50 秒までは 6 台中 3 台のみにおいて本システムが発動している場合であるが，発動していない他 3 台との CWNDの大きさの差が明らかに縮まっていることが確認出来る．さらに，改良前と後の違いを容易に比較できるよう，6 台中 1 台のCWND の推移を取り出し，図 10 にまとめた．改良前と比べる

とより明らかなように，CWND の抑制は穏やかになっている．

良前と比べ，大きく下がった．特に，スマートフォン端末におこの改良後の輻輳制御法を用い，5. 節と同様の環境において再いては，制御手法を用いないときと比べ，3 台同時通信の場合実験を行った．

最大 32%,6 台同時通信の場合最大 317%スループットが向上した．これはより適した通信量を保つことで，帯域を有効に使うことができたためであると予測できる．一方，タブレット端末
においては 6 台同時通信の場合最大 21%，スループットの向上が確認できたが，3 台同時通信の場合は約 22%低下してしまっ
た．タブレット端末はスマートフォン端末に比べ，CPU やメモ
リの違いから高性能であり，制御手法を用いない場合も 3 台通信においては既に高い通信性能を発揮している．よって，同時接続台数が少ない場合は本システムを作動しないようにするな
どといった対策が必要であると予測でき，今後の課題といえる．

図 8 CWND の推移 (改良後 1)

図 11 合計通信速度 (改良前，改良後比較)

図 9 CWND の推移 (改良後 2)

6. 2. 2 公 平 性
次に，Fairness Index [10] を用いて通信時における公平性の評価を行った．Fairness Index とは，公平性を示す指標であり，
式 6 で算出された値が 1 に近いほど高い公平性を示す．

F airnessIndex : fi =

(

∑k
xi )2
(1 <
∑i=1
=i<
= k)
k
2

k

i=1

xi

(6)

図 12 に示すように，6 台同時通信の場合，公平性がスマー
トフォン端末において最大 18%，タブレット端末において最大55%向上した．これは端末間で公平に帯域を分け合っているためであると考えられる．一方，3 台同時通信においては，スマー
トフォン端末とタブレット端末の両方において公平性が低下し
図 10 CWND の推移 (改良前，改良後比較)た．これは，輻輳制御モードに入らずに通信をしている端末が，輻輳制御モードに入っている端末よりも大きく帯域を占領して

6. 2 改良手法による実験結果
6. 2. 1 合計通信速度
まず，合計の通信速度の評価結果を図 11 に示す．青のグラしまうためであると考えられ，改善を要すると考えられる．

7. まとめと今後の課題

フはスマートフォン端末 (Nexus 5) の結果，赤のグラフはタブ

本研究では，ロスベース TCP を使用する端末が多数台同時

レット端末 (Nexus 7) の結果である. また，それぞれ補正を行に通信する場合において，AP に ACK パケットが蓄積し輻輳わないデフォルトの状態での結果，改良前の輻輳制御手法によを起こす問題を回避するために，先行研究によって開発された

る補正を行った結果，改良後の輻輳制御手法による補正を行っ

輻輳制御ミドルウェアの異種クライアントへの導入と改変をた結果である. グラフより，スマートフォン端末及びタブレット

行った．具体的には，まず先行研究によってスマートフォン向

端末において，改良後の輻輳制御手法を使った場合，同時通信けに開発された輻輳制御ミドルウェアをナイーブにタブレット

端末が 3 台から 6 台に増加した時のスループットの低下率が改端末へと導入し，評価実験を行った．その評価実験の結果から，

[5]
[6]

[7]
図 12 公 平 性

手法には CWND を厳しく抑制し過ぎており，帯域を有効に使用できていないという問題点を見出し，制御パラメータに改変を加え，再実験を行った．その結果，合計通信速度が，スマー
トフォン端末においては，3 台同時通信の場合最大 32%,6 台同時通信の場合最大 317%向上した．一方，タブレット端末においては 6 台同時通信の場合最大 21%，スループットの向上が確認できたが，3 台同時通信の場合は約 22%低下してしまったた
め，今後の課題といえる．さらに公平性を評価したところ，6
台同時通信の場合，スマートフォン端末において最大 18%，タ
ブレット端末において最大 55%向上した．この結果より，適切な CWND の上限値と下限値を設定することによって，多数の端末間で公平に帯域を分け合っていることが確認できた．一方，

3 台同時通信においては，スマートフォン端末とタブレット端末の両方において公平性が低下した．
通信速度，公平性の両方の観点において，同時接続台数が少ない場合はデフォルトの状態で既に高い性能を発揮しているた
め，必ずしも本システムを作動する必要はないと言える．よって，同一 AP への接続台数によってシステムの発動の有無をコ
ントロールするといった改良が必要である．
さらなる今後の課題としては，スマートフォン端末とタブレッ
ト端末が複数混在している場合の制御手法の性能評価を予定している. さらに，WLAN 環境下だけでなく，LTE 環境下における輻輳制御ミドルウェアの作動も確認済みであるため，LTE
環境下における制御手法の効果も確認していく予定である．

謝

辞本研究を進めるにあたり，NTT ドコモの早川愛さんに大変有用なアドバイスをいただきました．深く感謝いたします．
文

献[1] Kaori Miki, Saneyasu Yamaguchi, and Masato Oguchi:“Kernel Monitor of Transport Layer Developed for Android
Working on Mobile Phone Terminals,” Proc. ICN2011,
pp.297-302, January 2011.
[2] Hiromi Hirai, Saneyasu Yamaguchi, and Masato Oguchi: ”AProposal on Cooperative Transmission Control Middleware
on a Smartphone in a WLAN Environment,”Proc. IEEE
WiMob2013, pp.710-717, October 2013.
[3] Ai Hayakawa, Saneyasu Yamaguchi, Masato Oguchi: “Reducing the TCP ACK Packet Backlog at the WLAN Access
Point,” Proc. ACM IMCOM2015, 5-4, January 2015.
[4] Makiko Matsumoto and Masato Oguchi: Multiple Access

[8]
[9]
[10]

in MAC Layer Based on Surrounding Conditions of WirelessStations In Proc. the 1st International Workshop on Vehicular Communications and Applications (VCA2012) in conjunction with the 11th Annual Mediterranean Ad Hoc Networking Workshop (Med-Hoc-Net2012), pp.133-140, June2012.
Android open source project, http://source.android.com
L. Xu, K. Harfoush, and I. Rhee, ”Binary Increase Congestion Control for Fast, Long Distance Networks,” Proceedings of Tech. Report, Computer Science Department, NC
State University, 2003.
Sangtae Ha, Injong Rhee and Lisong Xu ”CUBIC: a new
TCP-friendly high-speed TCP variant” ACM SIGOPS Operating Systems Review - Research and developments in theLinux kernel, vol.42, pp.64-74, July 2008.
The dummynet project: http://info.iet.unipi.it/ luigi/dummynet
Iperf For Android Project in Distributed Systems,
http://www.cs.technion.ac.il/ sakogan/DSL/2011/projects/iperf/index.ht
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.