DEIM Forum2013 E6-1

無線 LAN 環境における環境情報に基づいた TCP パラメータ設定手法の評価
飯尾明日香†

小口正人†† お茶の水女子大学 〒 112-8610 東京都文京区大塚 2-1-1
E-mail: †asuka-i@ogl.is.ocha.ac.jp, ††oguchi@computer.org
あらまし近年，使用用途に応じた様々なセンサの開発が進んでおり，自動車など無数の高性能センサが搭載された端末では，精密な周囲の環境情報を取得可能である．このセンサ情報から生成される Conext は，自動車の場合には，主に事故防止やドライバの安全運転支援のため車両制御に利用されている．
一方で，WLAN(Wireless Local Area Network) 通信を行うそれらの端末における通信パラメータは周囲の状況に応じた設定がなされていないため，リソースを活用した効率的な通信を行っているとは言えない．
そこで，本研究では，上位層である TCP(Transmission Control Protcol) の輻輳制御に着目し，ここに環境情報として周辺端末数を利用することで，通信性能を改善する手法を検討する．通常，TCP の輻輳ウィンドウサイズ（cwnd）は周辺の端末数に関わらず輻輳制御アルゴリズムにより動的に制御されているが，本稿では，各端末が Context に応じcwnd を適切な値に固定して通信を行う独自の TCP を提案し，これを用いて通信を行った場合のスループットをシミュレーションにより測定して，評価を行った．
キーワード

環境情報，Context，TCP，輻輳制御方式，WLAN 通信

A Evaluation of TCP Parameter Setup Technique
Based on Environmental Information in Wireless LAN.
Asuka IIO† and Masato OGUCHI†† Ochanomizu University
2-1-1 Otsuka, Bunkyou-ku, Tokyo, 112-8610, JAPANE-mail: †asuka-i@ogl.is.ocha.ac.jp, ††oguchi@computer.org

1. は じ め に
現在，自動車には数百種類のセンサが搭載されており，自動車はこれらのセンサから GPS（全地球測位システム）によるない状態で通信を行っているという問題がある．そこで，本研
究では，環境情報を無線通信パラメータ設定に利用し，各端末が周囲の状況に応じた最適な設定を行うことで，通信効率を向上させる手法の検討を行う．

車両位置を始め，車両間隔，スピード，周辺端末数，加速度な

本稿では，環境情報の利用先として上位層の TCP（Trans-ど数多くの情報を取得できる．また，車載センサはドライバのmission Control Protocol）に着目した．TCP において，確認応安全機能強化の面から高精度化が進んでおり，搭載数も年々増答（ACK）を受けずに送信できるパケットの最大数である輻輳

加の傾向にある．このようなセンサから得た周囲の環境情報をウィンドウサイズ（cwnd）は輻輳制御アルゴリズムによりエンContext と呼ぶが，この Context は，自動車の場合には事故防止ドツーエンドで制御されているため，各端末は必ずしも周囲のや車両安定制御等に役立てられている．

状況に合った通信を行っているとは言えない．そこで，Context

一方，近年 WLAN（Wireless Local Area Network）による通信が一般化しているが，WLAN において通信に用いられる通として周辺端末数を利用し，各端末が最適な cwnd を用いて通信を行うことで通信性能の向上を目指す．

信パラメータは各々が独自のアルゴリズムに従って設定されて本研究では，輻輳制御アルゴリズムにより cwnd が制御さおり，その場の環境に応じた通信設定は行われない．したがっれる一般的な TCP を用いて通信を行った場合と，周辺端末数て，センサから環境情報を取得可能な端末であってもリソースに応じ最適な cwnd 値に固定して通信を行う独自の TCP を用を効率的に利用した通信が行われておらず，必ずしも最適ではいて通信を行った場合のそれぞれにおいて，周辺端末数に伴—1—

うスループットの変化をシミュレーションにより測定し，評無線通信が Context に強く依存することは理解されているが，価を行った．なお，実験にはネットワークシミュレータとして一方で，通信性能を改善するために Context を利用するようなOMNeT++ version4.1[1] を使用し，シミュレーションモデルはプロトコルがまだ完全には開発されていない．そこで，ネットINET Framework[2] および INETMANET[3] を使用した.

ワークスタックの多層にわたり既存の通信プロトコルと Context

2. Context
2. 1 Context とはを接続する Context-aware のフレームワークの基礎を築いたという研究である．
車通信では，動的なチャンネル変更や端末の高い移動性がContext は「実体を特徴づけることのできるあらゆる情報」と考えられるため，接続状態を維持でき，高スループットでの通定義されている．ここでの実体とは，ユーザとアプリケーショ信が可能であるような環境が望まれる．そこで，この研究でンの間のやり取りに関連していると考えられる人，場所，物のは，アプリケーションが車通信における QoS を満たす上で利用ことを指しており，これにはユーザやアプリケーション自体も可能な Context を判断し，生成されたデータをネットワークス含まれている．Context をこのように定義することで，アプリタックの各層へ振り分けるフレームワークについて述べている．

ケーションを開発する際に必要となる，実体のその時の状況がContext は図 2 に示すように Collection，Decision，Distribution

わかるような情報の列挙がより容易になる．[4][5]を経由し，それぞれが適合する問題へ与えられる．すなわち，

図 1 は，センサ情報の取得から Context 生成の流れを表してDecision Engine がセンサを用いて収集したデータの中から無線いる．無数のセンサから取得した環境情報を収集し，さまざま通信性能の改善に利用できるものを選択し，選択したデータをなアプリケーションで利用しやすいように抽象化することで，無線通信プロトコル上の適合する層へ分配するシステムである．

より正確な Context を生成している．図 1 のように，Context は本研究はこのうち，TCP/UDP 層における Context-aware De-データベースで管理を行う．

cision およびその Context の TCP/UDP 層への適用において利用可能な技術の確立を目指したものであるといえる．

図 1 センサ情報から Context を生成

Context はさまざまなアプリケーションで利用することができることから，通信性能の改善にも利用可能であると考えられる．

2. 2 Context-Aware Computing
Context-Aware とは，たとえ人が意識しなくとも，コンピュータがリアルタイムで実体の情報を収集・処理し，Context 化して利用する技術や概念のことを示している．ユーザに必要な情報やサービスを提供するために Context を使用するシステムをContext-Aware であると呼ぶ．
Context-Awere Computing は，Context を利用して企業や個人の情報利用環境を改善しようとする取り組みで，システムや

図 2 C2D2 システムのダイアグラム

ユーザがその時に必要としている情報や機能を判断し，ユーザにサービスとして提供するものである．つまり，様々なシステ

2. 3. 2 MAC 層への Context 利用

ムやセンサなどから得られる実体の情報，すなわち，Context

無線 LAN 通信への Context 利用の有用性は，文献 [7] にも示と人とをリアルタイムで結びつける技術である．これは多数のされている．これは，MAC 層の CSMA/CA(Carrier Sense Mul-技術の連携によって実現するが，近年，システム連携の仕組み

tiple Access with Collision Avoidance) のバックオフ制御に着目が発展してきたことから Context-Awere Computing は実現が期し，Contention Window 初期値の設定に，周辺端末数を利用し，待され，重要性が高まっている．

通信リソースの効率的な利用を目的とする研究である．実環境

2. 3 関 連 研 究に近い環境を想定して条件設定を行い，シミュレーションによ2. 3. 1 C2D2 Engineる評価を行うことにより，MAC 層における環境情報利用の有Context 利 用 に 関 連 す る 研 究 と し て 文 献 [6] に 示 し た用性が示されている．

C2D2(Context-aware Collection，Decision，and Distribution) Engine について説明する．

本研究では，通信における MAC 層の上位層である TCP 層への Context 利用を考える．

—2—

3. TCP3. 1 TCP による輻輳制御
WLAN の国際標準として IEEE 802.11 が規定されており，IEEE 802.11 の上位層においては TCP により輻輳制御が実現されている．輻輳とはネットワークの混雑を表す言葉であり，ネットワーク上で多量のトラフィックが発生して，通常の通信が困難になることをいう．TCP は，輻輳制御により輻輳を回避する仕様となっている．代表的な TCP として Tahoe，Reno，

NewReno，Vegas，Cubic 等があり，輻輳制御アルゴリズムは

図 3 TCP Tahoe における cwnd の変化

TCP によって様々な方式となっている．
TCP では，ウィンドウフロー制御をすることによって，輻ないように改良したものである．すなわち，始めはスロース輳の防止・早期回避を可能にしているが，一方で，輻輳回避

タートフェーズで cwnd の急速な増加を図り，その後，cwnd がフェーズにおける輻輳による cwnd の減少幅が，その後の線形

ssthresh に到達すると，輻輳回避フェーズへと移行する．輻輳

増加時の増加幅と比較し大きいため，一度輻輳が起き cwnd が回避フェーズでは，輻輳が起こると ssthresh を半分に更新し，下がると，cwnd が増加するまでに時間がかかり，輻輳制御がcwnd を ssthresh まで下げてから線形的に増加させ，輻輳が起こ原因となったスループットの低下が起こる場合がある．以下でる度にこれを繰り返す (図 4)．また，パケットロスなどによりは，TCP Tahoe と TCP Reno の輻輳アルゴリズムについて説明

タイムアウトが起きると，cwnd を 1 に変更しスロースタートし，本稿で比較評価に用いた TCP である TCP NewReno についフェーズの動作へと戻る．て触れる．

3. 2 TCP Tahoe
TCP Tahoe は，スロースタートフェーズと呼ばれる，ACK セグメントを受信した分だけ cwnd を増加させる動作を行う (式(1)，if 条件式)．
cwnd + 1cwnd ←−cwnd + 1cwnd

if cwnd < ssthresh(1)otherwise

cwnd=1 でセグメントを送信すると，受信側から 1 つの ACK セ

図 4 TCP Reno における cwnd の変化

グメントが送信されるため cwnd は 2 となる．cwnd が 2 のとき

2 つのセグメントを送信するため，受信側からは 2 つの ACKセグメントが送信され，cwnd は 4 となる．このようにスロースタートフェーズでは cwnd を 1,2,4,8,16,…と指数関数的に増加させていく．ここで，ssthresh はスロースタートから輻輳回避のフェーズへ移行する際の閾値である．ssthresh 初期値は多3. 4 TCP NewReno
TCP Reno では SACK（selective acknowledgement）がない場
合に，複数パケットが損失すると高速再転送および高速リカバリアルゴリズムが有効に動作しない問題があった．この高速リカバリアルゴリズムを修整したものが TCP NewReno である．

くの実装で広告ウィンドウサイズが設定されるが，ある程度大4. 独自の TCPきい値であれば任意である．
また，輻輳が起こると ssthresh は以下のように更新される．

ssthreshssthresh ←−2(2)3. 節で述べたように，通常，TCP では cwnd を輻輳制御アルゴリズムにより動的に制御している．しかし，本研究ではContext として周辺端末数を利用し，各端末が初めから適切な

その後，cwnd を 1 まで下げ，再びスロースタートフェーズを行cwnd 値に固定して通信を行うことで，通信性能の向上を試みう．やがて cwnd が ssthreth に達すると輻輳回避フェーズへ移行る．そこで，文献 [8] より，帯域幅遅延積（式（3）上式）を用し，cwnd を式 (1) の otherwise 条件式を用いて線形的に増加さい，これを端末数に応じて平等に分けることで，公平かつ効率せる．ここで再度輻輳が起こると，再び式 (2) を用いて ssthrethの良い通信を目指す．

を更新し，cwnd を 1 まで下げ，スロースタートフェーズへ移行する．TCP Tahoe はこの動作を繰り返す（図 3）．また，高速再送アルゴリズムが採用された点も TCP Tahoe の特徴である．

帯域幅遅延積 [bit] = 帯域幅 [bit/s] × RT T [s]cwnd = 帯域幅遅延積 ÷ 端末数(3)

3. 3 TCP Reno
TCP Reno は TCP Tahoe がベースのアルゴリズムで，TCP

ここで，RTT（Round Trip Time）は往復遅延時間を表す．

Tahoe に対してエラーが起きても必ずしも cwnd を 1 まで下げ

本稿では，すべての端末数において式（3）を適用し，端末—3—数ごとに適切な cwnd を定めて通信を行う TCP を独自の TCPと呼ぶ．

5. 検 証 実 験
5. 1 シンプルな環境
初めに，AP（Access Point）から等距離にある複数の端末が，AP を経由しサーバにパケットを送信するシンプルなシミュ
レーションモデルを使用した (図 5)．
図 6 距離 50m 時のトータルスループット比較

図 5 シミュレーションモデル

このモデルにおいて，全端末数を用い 4. 節で述べた式（3）を適用し cwnd を定めて通信する独自の TCP と，その比較対象として一般的に使用されている TCP である TCP NewReno の 2 種類の TCP を使用して，端末数に伴うトータルスループットを測定した．端末は，AP を中心とした円周上に均等に配置しているものとする．また，無線規格は IEEE802.11g を使用し，広告ウィンドウサイズは十分大きい値に設定した．
シミュレーションパラメータを表 1 に示す．なお，ここでのRTT とは，OMNeT++上で設定するコネクションの往復遅延時

図 7 距離 50m 時の RTT 比較間のみを表した時間であり，実際の測定値とは異なる．
このモデルを使用し，まず，AP と端末間の距離 50m 時のトータルスループットを測定し，次に，距離 100m 時のトータルスループットを測定した．このとき，独自の TCP で式（3）に用いる RTT は，AP からの距離 50m 時では 200msec とし，100m時では 180msec とした．これは，実験を行った際の RTT の増減幅内，または，増減幅の前後で，それぞれ高いスループットが求められた数値である．
シミュレーション結果を図 6，図 8 に示す．また，それぞれの場合における各端末の RTT の増減を図 7，図 9 に示す．これ

図8

距離 100m 時のトータルスループット比較

は，縦軸が RTT[sec]，横軸がシミュレーション時間であり，端末数を 20 台とした場合の結果である．
表15. 2 実環境に近づけた環境

シミュレーションパラメータ

先ほど実験を行ったモデルでは，端末を AP から特定の距離無線規格

IEEE8002.11gに均等に配置していた。このような環境は，実環境では考えにシミュレーション時間

20sec

くい。そこで，より実環境に近づけるため，端末を 2 グループ

データレート54Mbpsに分け，AP と端末間の距離を変え，それぞれ均等に配置する

RTT40msec

モデルを構築し，実験を行った（図 10）．

周波帯域

2.4GHz

最大セグメントサイズ

65,280Byte

広告ウィンドウサイズ

33,423,360Byte

5. 2. 1 AP と端末間の距離 25 ｍと 50 ｍの共存
AP と端末間の距離が 25 ｍ（距離 I）の端末と，AP と端末間の距離が 50 ｍ（距離 II）の端末を同数用意し，5. 1 節と同様に，AP を中心とした円周上に端末を均等に配置したモデルを考えた（図 10）．シミュレーションパラメータは表 1 と同様で

—4—

図9

距離 100m 時の RTT 比較

図 12

距離 25m，50m 時の RTT 比較に，帯域に余裕を確保できるよう 30msec とし，cwnd を決定した．
シミュレーション結果のトータルスループットを図 13，RTTを図 14 に示す．

図 10

シミュレーションモデルある．また，独自の TCP で式（3）に用いる RTT は，帯域に若干の余裕を確保できるように，パラメータに設定した 40msecよりも少し小さい 30msec とし，cwnd を決定した．
また，シミュレーション結果の図 11 における横軸の端末数とは，図 10 において距離 I に配置した端末数と距離 II に配置

図 13

距離 50m，100m 共存時のトータルスループット比較した端末数の合計値である．また，図 12 は各端末の RTT の増減を示す．

図 11

距離 25m，50m 共存時のトータルスループット比較

5. 2. 2 AP と端末間の距離 50 ｍと 100 ｍの共存
続いて，距離 I を 50m，距離 II を 100m とし，同様に実験を行った．こちらも，独自の TCP で式（3）に用いる RTT も同様—5—

が見られなかったが，端末の配置を実環境に近づけ距離を均一でなくしたモデルの場合では，端末数の増加に伴いトータルスループットが大きく低下したため，従来の TCP では効率の良い通信が行われていないことがわかった．また，独自の TCP を用いたとき，端末の配置が複雑な場合でも，TCP NewReno ほ
ど端末数の増加による性能の低下は見られなかった．
以上から，実環境では，帯域幅遅延積を周辺端末と平等に分けて通信を行うことで，従来の TCP より良い性能での通信が可能であると考えられる．

7. 今後の課題
今後は，AP からの距離に応じてデータレートが異なる環境における提案手法の評価を行う．さらに，端末の移動性を考慮したより複雑なモデルを用いてシミュレーションを行い，通信性能の向上を実現したい．また，最終的には，周囲の端末数が大きく変化した際に，リアルタイムで通信パラメータを変更しその時の状況に適応した通信を行う TCP を実装したい．

謝図 14

辞

距離 50m，100m 時の RTT 比較本研究を進めるにあたり，株式会社トヨタ IT 開発センター

5. 3 考察図 6，図 8 では，TCP NewReno と独自の TCP の 2 種類の通信性能はほぼ変わらないと言える．これは，簡単な WLAN モデルを用いて実験を行ったことから，TCP NewReno に大きな非効率が発生しておらず，cwnd の値の違いによる性能差が出にくかったためと考えられるが，図 7，図 9 において RTT を比較してみると，どちらも TCP NewReno はシミュレーション時間の増加に伴い 6 ｓ程度まで増加しているのに対し，独自のTCP では 3 ｓ程度で安定している．よって，提案手法では従来の TCP より効率の良い通信が行われていると考えられる．
一方で，端末配置に 2 種類の距離を用いた環境では，TPC

NewReno のトータルスループットは，端末数の増加と共に大きく低下しているが，独自の TCP のトータルスループットは，端末数が増加しても大きな低下は見られず，その優位性がはっきりと現れた（図 11，図 13）．また，図 12，図 14 の RTT の比較においても，その優位性を明確に示した．
より実環境に近い複雑な端末配置では TCP NewReno の輻輳制御が効率良く機能していないが，独自の TCP における cwnd設定では効率の良い通信が行われていると考えられる．このことから，端末数に応じて帯域を均等に分けた独自の TCP の有用性が示せた．の Onur Altintas 氏，松本真紀子氏に大変有用なアドバイスをいただきました．深く感謝いたします．
文

献[1] OMNeT++：
http://www.omnetpp.org/[2] INET Framework：
http://inet.omnetpp.org/[3] INETMANET Framework for OMNEST/OMNeT++ 4.x (based on
INET Framework)：
https://github.com/inetmanet/inetmanet/wiki[4] Daniel Salder, Anind K.Dey and Gregory D.Abowd, ”The Context Toolkit : Aiding the Development of Context-Enabled Applications”, In Proccedings of CHI’99,PIttsburgh,PA,May 15-20,1999,(toappear).ACM Press.
[5] Day, Anind K., ”Understanding and Using Context”(2001). HumanComputer Interaction institute.Paper 34.
http://repository.cmu.edu/hcii/34[6] Joseph Camp, Onur Altintas, Rama Vuyyuru, and Dinesh Rajan,”Context-awere Collection,Decision,and Distribution(C2D2) Engine
for Multi-Dimensional Adaptation in Vehicular Networks”, VANET
11, pp.85-86，September 23, 2011[7] 松本真紀子，小口正人，”無線端末の周辺情報を利用した MAC層におけるマルチプルアクセス手法の一検討”，電子情報通信学会ネットワークシステム研究会，NS2011-106，pp.13-18，2011
年 11 月[8] W.Richard Stevens 著，橘 康雄，井上 尚司訳（2000）『詳解 TCP/IP〈Vol.1〉プロトコル』ピアソンエデュケーション 327pp.

6. ま と め
WLAN 通信環境において，一般に使用されている輻輳制御を行う TCP NewReno と，Context に応じて cwnd を適切な値に保ったまま通信を行う独自の TCP を用い，端末数に伴うトータルスループットをシミュレーションにより求め，その性能を比較した．その結果，TCP NewReno では端末の配置が AP から等距離にあるというシンプルなモデルの場合，通信性能の低下—6—