(57)【要約】【課題】  データ通信において、スループットの低下を極力抑えながらも大幅な省電力化を実現すること。【解決手段】  送信側のＷｅｂサーバ１は、データセグメント送信時に、当該データがＡＣＫを要求するデータセグメントか否かを示すＡＣＫ要否フラグを付与する。受信側の携帯電話２は、データセグメントを受信すると、上記ＡＣＫ要否フラグを参照して、ＡＣＫ要否フラグが付与されたデータセグメントにのみＡＣＫを返信する。これにより、送信されるＡＣＫの数が大幅に減少し、その結果Ｗｅｂサーバ１及び携帯電話２において消費される電力を大幅に減少させることができる。【選択図】  図１２
2006086611.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して他の情報処理装置と接続された情報処理装置であって、
前記他の情報処理装置から所定のプロトコルによりデータを受信する受信手段と、
前記受信されたデータに対する確認応答の送信の要否を判断する判断手段と、
前記受信されたデータのうち、前記確認応答を送信する必要があると判断されたデータに対する確認応答を前記他の情報処理装置へ送信する送信手段と
を具備することを特徴とする情報処理装置。
【請求項２】
請求項１に記載の情報処理装置であって、
前記判断手段は、前記データが受信された時から所定時間次のデータを受信しない場合に、当該受信されたデータに対する確認応答の送信が必要であると判断することを特徴とする情報処理装置。
【請求項３】
請求項１に記載の情報処理装置であって、
前記受信されたデータには、前記他の情報処理装置により前記確認応答送信の要否を示すフラグが付与されており、
前記判断手段は、前記フラグを参照することにより前記確認応答の送信の要否を判断することを特徴とする情報処理装置。
【請求項４】
請求項３に記載の情報処理装置であって、
前記所定のプロトコルはＴＣＰであり、
前記判断手段は、前記受信されたデータにコントロールフラグが付されている場合には、前記確認応答の送信の要否を示すフラグの種類に関わらず、当該受信されたデータに対する確認応答を送信する必要があると判断することを特徴とする情報処理装置。
【請求項５】
請求項４に記載の情報処理装置であって、
データが受信される毎に、当該受信されたデータの次に受信されるべきデータの第１のシーケンス番号を認識する手段と、
前記認識された第１のシーケンス番号と、前記認識後に最初に受信されたデータの第２のシーケンス番号とを比較する手段とを更に具備し、
前記判断手段は、前記比較の結果、前記第２のシーケンス番号の方が大きい場合には、当該第２のシーケンス番号のデータに付与された前記確認応答の送信の要否を示すフラグの種類に関わらず、前記第１のシーケンス番号の一つ前のシーケンス番号のデータに対する、既に送信済みの確認応答を再度送信する必要があると判断し、
前記送信手段は、前記再度の送信回数が４回以上とならないよう制御することを特徴とする情報処理装置。
【請求項６】
第１の情報処理装置と第２の情報処理装置がネットワークを介して接続されたシステムであって、
前記第１の情報処理装置は、
前記第２の情報処理装置へ送信するためのデータに、当該データに対する確認応答の送信の要否を示すフラグを付与する付与手段と、
前記フラグを付与されたデータを所定のプロトコルにより送信する第１の送信手段とを有し、
前記第２の情報処理装置は、
前記第１の情報処理装置から送信されたデータを前記所定のプロトコルにより受信する受信手段と、
前記付与されたフラグを基に、前記受信されたデータに対する確認応答の送信の要否を判断する判断手段と、
前記受信されたデータのうち、前記確認応答を送信する必要があると判断されたデータに対する確認応答を前記第１の情報処理装置へ送信する第２の送信手段とを有することを特徴とする情報処理システム。
【請求項７】
請求項６に記載の情報処理システムであって、
前記所定のプロトコルはＴＣＰであり、
前記第１の送信手段は、ウィンドウ制御により複数のデータを連続して送信し、
前記付与手段は、前記送信するための複数のデータのうちシーケンス番号が最大のデータに前記確認応答の送信を要する旨のフラグを付与し、その他のデータに前記確認応答の送信を要しない旨のフラグを付与することを特徴とする情報処理システム。
【請求項８】
ネットワークを介して他の情報処理装置と接続された情報処理装置が情報を処理する方法であって、
前記他の情報処理装置から所定のプロトコルによりデータを受信するステップと、
前記受信されたデータに対する確認応答の送信の要否を判断するステップと、
前記受信されたデータのうち、前記確認応答を送信する必要があると判断されたデータに対する確認応答を前記他の情報処理装置へ送信するステップと
を具備することを特徴とする情報処理方法。
【請求項９】
ネットワークを介して他の情報処理装置と接続された情報処理装置に、
前記他の情報処理装置から所定のプロトコルによりデータを受信するステップと、
前記受信されたデータに対する確認応答の送信の要否を判断するステップと、
前記受信されたデータのうち、前記確認応答を送信する必要があると判断されたデータに対する確認応答を前記他の情報処理装置へ送信するステップと
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、所定のプロトコルを用いて各種データを送受信することが可能な情報処理装置、情報処理システム、情報処理方法及びそのプログラムに関する。
【背景技術】
【０００２】
従来のインターネットのシステムでは、大容量のデータを如何に効率よく送受信することができるかということに重点が置かれていたために、スループットや遅延といった要素を最優先してシステム設計されていた。
【０００３】
インターネットで用いられるトランスポート層の通信プロトコルとしては、例えばコネクションレスのＵＤＰ（User Datagram Protocol）やコネクションを行なうことにより信頼性を確保するＴＣＰ（Transmission Control Protocol）があるが、例えば、上記ＵＤＰにおいて、受信側が、送信側から送信されたデータを正常に受信できなかった場合にのみＮＡＣＫ（Negative ACKnowledgement）を送信し、送信側では、当該ＮＡＣＫに対してのみデータを再送することにより、ネットワークの輻輳を防ぎ、多数のユーザにデータを効率よく、かつ高い信頼性で配信することができるようにした送受信装置が提案されている（特許文献１参照）。  
【特許文献１】特開平１１−１７７３７号公報（段落[０１１７]、図３等）
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ところで、今日における無線通信技術の進歩には目覚しいものがあり、場所に制約されずにネットワークを利用することが可能となる無線通信は、産業においても多くの影響を与えることが予想される。特に、複数の無線端末で構築するアドホックネットワークは、ネットワークを利用したサービスに新たな革新をもたらすこととなり、マルチホップセンサネットワークやメッシュネットワークといった応用で注目を集めている。
【０００５】
無線通信で構成されたネットワークでは、省電力な通信基盤を設計することが重要となる。無線通信の最大の利点は、通信ケーブルの制約から逃れて自由に動き回れることである。そのような無線通信における電力供給は基本的にバッテリを利用するため、電力容量には限界がある。特に、複数のセンサノードで形成されたセンサネットワークにおいては、ノードの再充電が困難な場所への設定も想定しているため、システム設計においては省電力が最優先項目となる。しかしながら、上記特許文献１の技術にように、スループットや遅延といった性能を重要視する従来のネットワークシステムにおいては、省電力なデータ通信を実現することに主眼がおかれていないため、無線通信に適用した場合には消費電力が高くなってしまう。
【０００６】
一方、現在の多くのアプリケーションで利用されているＴＣＰは、多くの改良がされてきた強靭な通信プロトコルであるが、省電力という点では、ほとんど最適化されていないのが現状である。省電力に特化した通信プロトコルを提案する動きもあるが、多数のコネクションが同一のネットワーク資源をユニキャスト通信で共有する際に、ＴＣＰ以上の性能を実現する信頼のあるプロトコルを設計することは容易ではない。また、インターネット環境との持続性を考えた場合、中継ノードでプロトコル変換をするよりも、ＴＣＰで通信をする方が余計な負荷がなくなる。従って、ＴＣＰの省電力化は重要な課題といえる。
【０００７】
以上のような事情に鑑み、本発明の目的は、データ通信において、スループットの低下を極力抑えながらも大幅な省電力が可能な情報処理装置、情報処理システム、情報処理方法及びそのプログラムを提供することにある。
【課題を解決するための手段】
【０００８】
上述の課題を解決するため、本発明の情報処理装置は、ネットワークを介して他の情報処理装置と接続された情報処理装置であって、前記他の情報処理装置から所定のプロトコルによりデータを受信する受信手段と、前記受信されたデータに対する確認応答の送信の要否を判断する判断手段と、前記受信されたデータのうち、前記確認応答を送信する必要があると判断されたデータに対する確認応答を前記他の情報処理装置へ送信する送信手段とを具備する。
【０００９】
ここで上記所定のプロトコルとは、例えばインターネット層のＴＣＰ、ＵＤＰ等、及びその他のプロトコルである。また上記確認応答とは、データの送信先のコンピュータが、データを受信したことを送信元のコンピュータに通知するための肯定的な返事のことを指し、通常、ＡＣＫ（ACKnowledgement）と呼ばれる。
【００１０】
上記構成によれば、上記他の情報処理装置からデータを受信する毎に当該データに対する確認応答の要否を判断し、必要な確認応答のみを他の情報処理装置へ返信することで、無駄な確認応答が送信されるのを防ぐことができるため、そのような無駄な確認応答を送信することにより消費する電力を大幅に減少させることができる。また、省電力を実現しながらも、従来のデータ通信におけるスループット性能を極力維持することができる。
【００１１】
上記情報処理装置において、前記判断手段は、前記データが受信された時から所定時間次のデータを受信しない場合に、当該受信されたデータに対する確認応答の送信が必要であると判断するようにしてもよい。
【００１２】
ここで所定時間とは例えば１ms〜５００ms秒程度、より好ましくは１ms〜１０msの範囲であるが、ネットワークを共有している情報処理装置の数や距離といったネットワーク環境、情報処理装置が利用するアプリケーション等によりそれ以外の範囲へ適宜変更することが可能である。上記所定時間経過前に受信したデータに対しては確認応答を送信せずに、所定時間を経過後に受信したデータにのみ確認応答を送信することで、上記他の情報処理装置へ送信される確認応答を減少させることができ、その結果省電力にデータ通信を行なうことが可能となる。具体的には、例えば、データを受信した時点から所定時間でタイムアウトする遅延タイマを設けて、かつ、所定時間経過前にデータを受信する度に当該遅延タイマがリセットするようにする。これにより、上記確認応答は、受信間隔が上記所定時間より短いデータに対しては返信されずに、受信間隔が上記所定時間より長いデータに対してのみ返信されることになる。
【００１３】
上記情報処理装置において、前記受信されたデータには、前記他の情報処理装置により前記確認応答送信の要否を示すフラグが付与されており、前記判断手段は、前記フラグを参照することにより前記確認応答の送信の要否を判断するようにしてもよい。例えば、ＴＣＰにおけるウィンドウ制御によってウィンドウサイズ分の一連のデータを送受信する場合には、上記他の情報処理装置により、当該ウィンドウの最後のデータにのみ確認応答を要する旨のフラグを付与が付与され、その他のデータには確認応答を要しない旨のフラグが付与される。当該フラグを参照することで、確認応答の要否を容易に判断することができ、必要な確認応答のみを送信することで、省電力なデータ通信が可能となる。
【００１４】
上記情報処理装置において、前記所定のプロトコルはＴＣＰであり、前記判断手段は、前記受信されたデータにコントロールフラグが付されている場合には、前記確認応答の送信の要否を示すフラグの種類に関わらず、当該受信されたデータに対する確認応答を送信する必要があると判断するようにしてもよい。
【００１５】
ここでコントロールフラグとは、ＴＣＰにおけるＳＹＮ（Synchronize Flag）、ＦＩＮ（Fin Flag）、ＲＳＴ（Reset Flag）、ＰＵＳＨ（Push Flag）、ＵＲＧ（Urgent Flag）等のフラグであり、各フラグのビットが１の場合、例えばＳＹＮならコネクションの開始、ＦＩＮならコネクションの終了、ＲＳＴならコネクションのリセット、ＰＵＳＨならアプリケーションにすぐに渡すデータ、ＵＲＧなら緊急に処理すべきデータ、といった意味をそれぞれ持っている。これらのコントロールフラグに対しては、上記確認応答送信の要否を示すフラグがオフになっていても、確認応答を送信することで、各コントロールフラグが持つ意味の処理を優先して実行することができ、従来のＴＣＰとの互換性を保つことができる。
【００１６】
上記情報処理装置は、データが受信される毎に、当該受信されたデータの次に受信されるべきデータの第１のシーケンス番号を認識する手段と、前記認識された第１のシーケンス番号と、前記認識後に最初に受信されたデータの第２のシーケンス番号とを比較する手段とを更に具備し、前記判断手段は、前記比較の結果、前記第２のシーケンス番号の方が大きい場合には、当該第２のシーケンス番号のデータに付与された前記確認応答の送信の要否を示すフラグの種類に関わらず、前記第１のシーケンス番号の一つ前のシーケンス番号のデータに対する、既に送信済みの確認応答を再度送信する必要があると判断し、前記送信手段は、前記再度の送信回数が４回以上とならないよう制御してもよい。
【００１７】
これにより、例えば、受信された複数のデータの順序（シーケンス番号）に抜けが生じていた場合、上記確認応答送信の要否を示すフラグがオフになっていても、当該抜けたシーケンス番号のデータ一つ前のデータに対する確認応答、すなわち当該抜けたシーケンス番号の再送を要求する確認応答を重複して送信することで、いわゆるＴＣＰにおける高速再送制御（Fast-Retrans-mission）を実行させることができ、従来のＴＣＰとの互換性を保つことができる。また上記重複送信の回数を３回までに限ることで、重複確認応答が限りなく送信されることにより電力を消費してしまうことを極力防ぐことができる。
【００１８】
本発明の情報処理システムは、第１の情報処理装置と第２の情報処理装置がネットワークを介して接続されたシステムであって、前記第１の情報処理装置は、前記第２の情報処理装置へ送信するためのデータに、当該データに対する確認応答の送信の要否を示すフラグを付与する付与手段と、前記フラグを付与されたデータを所定のプロトコルにより送信する第１の送信手段とを有し、前記第２の情報処理装置は、前記第１の情報処理装置から送信されたデータを前記所定のプロトコルにより受信する受信手段と、前記付与されたフラグを基に、前記受信されたデータに対する確認応答の送信の要否を判断する判断手段と、前記受信されたデータのうち、前記確認応答を送信する必要があると判断されたデータに対する確認応答を前記第１の情報処理装置へ送信する第２の送信手段とを有する。
【００１９】
この構成により、上記第１の情報処理装置が送信するデータに対する確認応答の要否を示すフラグを付与して第２の情報処理装置へデータを送信し、第２の情報処理装置は必要な確認応答のみを送信するため、不必要な確認応答の数が減少する結果、第２の情報処理装置の消費電力を大幅に減少させることができる。また、省電力化を実現しながらも、従来のデータ通信におけるスループット性能を極力維持することができる。
【００２０】
上記情報処理システムにおいて、前記所定のプロトコルはＴＣＰであり、前記第１の送信手段は、ウィンドウ制御により複数のデータを連続して送信し、前記付与手段は、前記送信するための複数のデータのうちシーケンス番号が最大のデータに前記確認応答の送信を要する旨のフラグを付与し、その他のデータに前記確認応答の送信を要しない旨のフラグを付与するようにしてもよい。これにより、例えばＴＣＰのウィンドウ制御においては、第１の情報処理装置はウィンドウの最後のデータに対する確認応答のみを要求するフラグを付与してウィンドウサイズ分の一連のデータを送信するため、上記第２の情報処理装置は、当該フラグを参照して、受信した一連のデータのうち最後のデータに対してのみ確認応答を返せばよいことを容易に判断することができ、複雑な処理を要することなく省電力化を実現することが可能となる。
【００２１】
本発明の情報処理方法は、ネットワークを介して他の情報処理装置と接続された情報処理装置が情報を処理する方法であって、前記他の情報処理装置から所定のプロトコルによりデータを受信するステップと、前記受信されたデータに対する確認応答の送信の要否を判断するステップと、前記受信されたデータのうち、前記確認応答を送信する必要があると判断されたデータに対する確認応答を前記他の情報処理装置へ送信するステップとを具備する。
【００２２】
また、本発明のプログラムは、ネットワークを介して他の情報処理装置と接続された情報処理装置に、前記他の情報処理装置から所定のプロトコルによりデータを受信するステップと、前記受信されたデータに対する確認応答の送信の要否を判断するステップと、前記受信されたデータのうち、前記確認応答を送信する必要があると判断されたデータに対する確認応答を前記他の情報処理装置へ送信するステップとを実行させるためのものである。
【発明の効果】
【００２３】
本発明によれば、データ通信において、スループットの低下を極力抑えながらも大幅な省電力が可能となる。
【発明を実施するための最良の形態】
【００２４】
以下、本発明の実施の形態を図面に基づき説明する。
【００２５】
本発明の目的は、データ通信、特に携帯端末による無線通信において消費される電力を減少させることである。そこでまず、無線通信における消費電力について説明する。ここでは、一般的な無線ＬＡＮ（Local Area Network）として利用されているIEEE802.11における消費電力と、ＴＣＰとの関係を例に挙げて説明する。
【００２６】
L. M. Feeneyは、IEEE802.11のピアツーピアの消費電力を実際の測定からモデル化した。このモデルでは、消費電力はEnergy = m × size + bで表される。本実施形態においては、2.4GHz  IEEE802.11  11Mbps WaveLAN PC Cardの測定結果を利用して消費電力を求める。図１は、送信ノードＡから受信ノードＢへパケットを送信する場合に、当該ＡとＢのノード、その近隣に存在するＣ、Ｄ及びＥのノードでのデータ通信において消費される電力について説明した図である。同図右上のスペースに点線で示された２つの円は送信ノードＡ及び受信ノードＢの通信範囲をそれぞれ示している。
【００２７】
IEEE802.11で送受信されるパケットは、ユニキャストの送信／受信パケット（同図Ａ／Ｂが送信／受信するパケット）、ブロードキャストの送信／受信パケットの４種類のパケットと、宛先以外のノードがユニキャストの通信時に受け取る受信パケットの計５種類のパケットに分類することができ、更に、当該宛先以外のノードが受信するパケットは、ノードの位置により更に３種類に分類することができる。すなわち、送信ノードと受信ノードの両方から受信できるパケット（同図のノードＣが受信できるパケット）、受信ノードのみから受信できるパケット（同図のＤが受信できるパケット）、送信ノードのみから受信できるパケット（同図のＥが受信できるパケット）である。
【００２８】
無線通信において送受信ノード以外のノードが電力を消費してしまうのは、データが電波距離内のすべてのノードへ届いてしまうという無線通信の特徴と、データを送信する際に、ＲＴＳ／ＣＴＳ（Request to Send／Clear to Send）等のＭＡＣ（Media Access Control）層での通信制御で電力を消費しているからである。
【００２９】
ところで、ＴＣＰでは、送信ノードが、送信したデータに対する確認応答（以下、ＡＣＫという）を受信ノードから受け取ることにより通信の信頼性を提供している。ＡＣＫでは、累積確認応答方式が利用されている。これは、後のＡＣＫが前のＡＣＫの情報を全て含んでいることを示している。またＡＣＫは全てのデータに対して送信される訳ではなく、大きく分けて次の３通りの仕組みにより送信される。
（１）複数のデータを受信した時にＡＣＫを送信する。多くの実装では、２個のデータを受信する毎にＡＣＫが送信される（遅延確認応答）。
（２）２００msの定期的な遅延タイマがタイムアウトする度に、ＡＣＫを送信すべきデータがあるか否かを調べ、ある場合にはＡＣＫを送信する。
（３）ＳＹＮ、ＦＩＮ、ＰＵＳＨ、ＲＳＴ等の特殊フラグ（コントロールフラグ）や、順序の異なる（シーケンス番号に抜けがある）データを受信した場合にＡＣＫを送信する。
【００３０】
このように、ＴＣＰにおいてはデータ以外にＡＣＫも送受信されるが、本発明者らは、図１に示すように、ＴＣＰの通信においてどれほどの消費電力がかかるのかを、データとＡＣＫでそれぞれ分けて計算した。また、ピアツーピアの無線通信において周辺ノードＣ、Ｄ及びＥへの影響も同時に調べた。なお、ＴＣＰでは、情報はセグメントという単位で送受信され、セグメントには、データを含むデータセグメントと、データを含まずＡＣＫを含むＡＣＫセグメントの２種類がある。
【００３１】
同図においては、送信ノードＡから送信されるデータセグメントは、ＰＬＣＰ（Physical Layer Convergence Protocol）ヘッダ（２４byte）、ＭＡＣフレームヘッダ（２０byte）、ＩＰヘッダ（２０byte）、ＴＣＰヘッダ（２０byte）を含めて１４６０byteと仮定する。また、ＡＣＫセグメントは、データが含まれないため８４byteとする。データロスがなく、最も電力効率のよい環境を考えると、２個のデータに対して１個のＡＣＫが送信される環境となる。同図では、送信ノードＡが１０００個のデータを送信し、受信ノードＢから５００個のＡＣＫを受信したことを想定している。各グラフの左側の棒がデータ送信に要する消費電力、右側の棒がＡＣＫ送信に要する消費電力を示している。
【００３２】
上記計算の結果、同図に示すように、ＡＣＫセグメントはデータセグメントの約１７分の１程度のデータ量しか無いのにも関わらず、各ノードでの情報の送信で消費される電力のうち、ＡＣＫセグメントにより消費される電力はかなり多いことが分かる。このことから、本発明者らは、送信されるＡＣＫセグメントの量を減らすことができれば、省電力化も可能になることを認識した。
【００３３】
しかし、ＡＣＫを減らすことができても、従来のＴＣＰの性能（例えばスループット）があまりにも低下することとなっては、せっかく省電力化に成功したとしても実用性に乏しいものとなる。そこで、次に本発明者らは、ＡＣＫセグメントを減らすことによるスループットへの影響を調べた。具体的には、ＴＣＰの送信ノードと受信ノードが帯域１０Mbps、遅延１０msのリンクで接続されたトポロジを想定して、ns-2というネットワークシミュレータ（www.isi.edu/nsnam/ns/を参照）によるシミュレーションを行なった。当該シミュレーションにおいては、データセグメントとＡＣＫセグメントのそれぞれのロスの影響を調べるために、ランダムにセグメントを破棄するようなロスモデルを、一方向のリンクにだけ適応するシミュレーションを行なった。当該シミュレーションにおいては、１４６０byteのデータを５０００秒送信し続けた。
【００３４】
図２は、データセグメントのみをランダムに破棄した場合のロス率とスループットとの関係を示した図である。Ｘ軸とＹ軸は、それぞれデータセグメントのロス率とスループットをlogで表示している。同図から、データセグメントは０．０１（１%）程度のロスでスループットが１０分の１の１Mbps程度まで落ちていることが分かる。
【００３５】
一方、図３は、ＡＣＫセグメントのみをランダムに破棄した場合のロス率とスループットとの関係を示した図である。図２と同様、Ｘ軸とＹ軸は、それぞれＡＣＫセグメントのロス率とスループットをlogで表示している。同図から、０．３（３０%）付近までは、ＡＣＫのロスはスループットにほとんど影響を与えないことが分かる。
【００３６】
次に、ＡＣＫセグメントのロス率が０．３から０．７の間を０．０１毎にずらして、同じロス率でそれぞれ１０００回実験を繰り返した。図４及び図５は、それぞれ０．３〜０．５、０．５〜０．７のロス率のシミュレーション結果を示した図である。図４に示すように、ロス率が０．３〜０．５の場合には、スループットが低くなるデータの割合が徐々に増えている。また図５に示すように、ロス率が０．６付近になるとスループットはほぼ０に近くなる。しかしながら、注目すべきことに、ロス率が０．６以降の場合でも、まれに９Mbps程度のスループットのデータが取得できた。
【００３７】
そこで本発明者らは、上記図５において、なぜ同じＡＣＫのロス率にも関わらず、スループットに雲泥の差がでるのかをＴＣＰの仕組みに着目して考察した。図６は、（ａ）ロス率０%の場合、（ｂ）ロス率７０%でスループットが９Mbps程度の場合、（ｃ）ロス率７０%でスループットがほとんど出ていない場合の３通りで、送信ノードにおける送信データセグメントと受信ＡＣＫセグメントのシーケンス番号を時系列的にプロットしたグラフである。上段が送信データセグメント、下段が受信ＡＣＫセグメントをそれぞれ示している。また、各グラフにおいて、Ｘ軸が時間（秒）、Ｙ軸がシーケンス番号をそれぞれ示している。
【００３８】
同図において、（ａ）は全くＡＣＫのロスが起こらない状況での理想的な通信を示している。上段のグラフと下段のグラフでプロットされている点の数が等しくなる。一方、（ｂ）と（ｃ）では、送信データセグメントに比べて受信ＡＣＫセグメントが少なくなっている。これは、７０%のＡＣＫセグメントを故意的に落としているからである。
【００３９】
（ｂ）と（ｃ）の送信データセグメントのグラフに注目すると、（ｂ）では、ほぼ（ａ）に近い形態となっているのに対し、（ｃ）では、同じシーケンス番号のデータセグメントが何度も送信されていることが分かる。また、（ｂ）と（ｃ）ではＸ軸の粒度が全く異なることも注目すべき点である。
【００４０】
この（ｂ）と（ｃ）の違いを、図７を用いて説明する。図７は、ＴＣＰの通信において送信ノードから送信されるデータに対してＡＣＫが送信される様子を示した図である。
【００４１】
ＴＣＰの性能を劣化させる最大の要因は、データセグメントの再送である。上記図６の（ｂ）の例から分かるように、データセグメントの再送が引き起こされなければ、性能（スループット）が極端に劣化することはない。上述したように、ＴＣＰでは累積確認応答方式が採られており、後に送信されたＡＣＫは、前に送信されたＡＣＫの情報を全て含んでいることを意味している。ＡＣＫが受信されない場合には、データの再送が引き起こされる。更に、ＴＣＰはウィンドウ（データを溜めておくバッファ領域）という概念を取り入れて、ウィンドウを利用した通信制御（ウィンドウ制御）を行っている。すなわち、ウィンドウ内の複数のデータ（ウィンドウサイズ分のデータ）は、ＡＣＫを待つことなく一度に送信することが可能となっている。図７においては、ウィンドウサイズは４であり、送信ノードにおいては当該ウィンドウ内のシーケンス番号１〜４のデータセグメントは一度に送信され、受信ノードにおいては各データセグメントのシーケンス番号に１を加えた数を、ＡＣＫとしてそれぞれ返す。またウィンドウサイズは、通信状況に応じて動的に変化し、通信が成功（ＡＣＫを受信）すると増加し、失敗する（再送が引き起こされる）と減少する。
【００４２】
以上のことから、ＴＣＰにおいて、ウィンドウの最後のセグメントに対するＡＣＫ（例えば図７のＡＣＫセグメント５）は、他のセグメントと比較して重要度が高いということがいえる。なぜなら、ウィンドウの最後のセグメントに対するＡＣＫが喪失した場合、送信側では必ず再送が引き起こされるからである。一方、ウィンドウの最後のセグメントに対するＡＣＫさえ届いていれば、再送は引き起こされない。以降、ウィンドウの最後のセグメントに対するＡＣＫをSignificant ACKと呼び、それ以外のＡＣＫをNegligible ACKと呼ぶ。
【００４３】
以上の実験・考察結果から、本発明者らは、ＴＣＰにおいてＡＣＫがかなりの電力を消費していること、及び、ＴＣＰの受容可能な性能を保ちながら、ＡＣＫセグメントを大幅に減らすことが可能であることを実証した。そこで、本発明者らは、上記Negligible ACKを全てなくすことを目標に、従来のＴＣＰに変更を加えることとした。以下、本発明におけるＴＣＰの設計方針について説明する。
【００４４】
ＴＣＰのＡＣＫを減少させることにより危惧されることは、一つにはウィンドウの膨張速度が小さくなることであるが（上述したように、ウィンドウサイズはＡＣＫを受信することにより増加するため）、それ以外にも、ＡＣＫのロスに対しての影響も考える必要がある。上記図７を例にして説明すると、例えば受信側は、セグメント４に対する５を要求するSignificant ACKしか返答しないと仮定する。この返答が送信側に到着すれば、１，２，３，４全てのセグメントの到着を送信側に伝えることになるため、再送は起こらない。一方、この場合のSignificant ACKが送信途中で喪失（ロス）してしまったとする。この場合、送信側は、１，２，３，４全てのセグメントが届いていないと一時的に認識する。ここでセグメント１の再送が行なわれるため、ウィンドウサイズは１に減少する。受信側では、当該再送されたセグメント１を受信した場合、当該１に対するＡＣＫはSignificant ACKとなり、５の値を返す。仮に、従来のＴＣＰにおいて、１，２，３のセグメントに対するＡＣＫを返していたとしても、セグメント４に対するSignificant ACKが送信途中で喪失した場合、結局セグメント４が再送されることになるため、従来のＴＣＰにおいても、本発明のＡＣＫを減少させたＴＣＰにおいても、処理的には同じ数のデータを送信することになる。
【００４５】
ここで、本発明のＴＣＰを設計する上でポイントとなるのは、Negligible ACKを削減していても、ウィンドウ全てのデータが再送される訳ではない点、すなわち上記２，３，４のセグメントは再送されない点と、データロス率によりSignificant ACKの数が動的に増減することである。そこで、本発明者らは、Negligible ACKとSignificant ACKとの関係を調べるため、上記図２から図６における環境と同様の環境でデータロス率を０%から０．１%まで変更させながら、Negligible ACKとSignificant ACKの数の比率を測定した。図８は、当該測定結果を示した図である。
【００４６】
同図に示すように、データロス率が増加するに従って、Significant ACKの比率は増加していく。従って、輻輳が酷い環境を想定した場合（例えばデータロス率が０．１%よりも更に大きい環境の場合）、ＴＣＰはウィンドウを膨張させることができなくなり、ほとんどのＡＣＫがSignificant ACKになる可能性もある。このように、Negligible ACKの削減は動的に行なうため、ロス率の高い環境においても高い性能が期待できる。
【００４７】
以上の方針をもとに、以下の実施例において、Negligible ACKを削減したＴＣＰの具体的な実装方法について説明する。
【００４８】
（第１の実施形態）  
本実施形態においては、上記Negligible ACKを削減するために、送信ノードと受信ノードの両端のＴＣＰを変更する。具体的には、送信ノードが、受信ノードへ送信するデータセグメントに、Negligible ACKを要求するデータセグメントか、Significant ACKを要求するデータセグメントかの識別子（フラグ）を予め付与して送信する。受信ノードは、受信したデータセグメントのうちSignificant ACKを要求するデータセグメントに対してのみＡＣＫを返す。以下、この手法を実現する通信システムについて説明する。本実施形態においては、送信ノードとしてＷｅｂサーバ、受信ノードとして携帯電話を適用している。
【００４９】
図９は、本実施形態における通信システムの構成を示した図である。同図に示すように、本実施形態においては、Ｗｅｂサーバ１と携帯電話２がホットスポット（登録商標）３を介して接続されている。
【００５０】
Ｗｅｂサーバ１は、ＨＴＭＬ（Hyper Text Markup Language）文書や、画像、音声その他のコンテンツを作成または蓄積し、それらのコンテンツを、携帯電話２が有するＷｅｂブラウザの要求に応じて提供する。携帯電話２は、例えば無線ＬＡＮによりホットスポット３に接続する。ホットスポット３は、Ｗｅｂサーバ１へのアクセスポイントとして、インターネット４を介してＷｅｂサーバ１と接続され、携帯電話２に、無線ＬＡＮによるインターネット接続サービスを提供する。Ｗｅｂサーバ１とホットスポット３、ホットスポット３と携帯電話２との通信プロトコルとしては、ＴＣＰ／ＩＰが用いられる。なお、Ｗｅｂサーバ１、携帯電話２及びホットスポット３の数は同図に示される数に限定されるものではない。
【００５１】
図１０は、上記Ｗｅｂサーバのハードウェア構成を示した図である。同図に示すように、Ｗｅｂサーバ１は、ＣＰＵ（Central Processing Unit）１１、ＲＯＭ（Read Only Memory）１２、ＲＡＭ（Random Access Memory）１３、通信部１４、操作入力部１５、表示部１６及びＨＤＤ（Hard Disk Drive）１７で構成され、それらがバス１８で接続されている。
【００５２】
ＣＰＵ１１は、Ｗｅｂサーバ１全体の動作を制御するメインコントローラであり、ＯＳ（Operating System）により提供されるプラットフォーム上で、例えばＷｅｂページの作成等における各種のアプリケーションや、ＴＣＰのプロトコルスタックを実行する。
【００５３】
ＲＯＭ１２は、Ｗｅｂサーバ１の電源オン時に実行するプログラムや、ハードウェア制御用のコード等のデータやプログラム等を格納する、読み出し専用の不揮発性のメモリである。またＲＡＭ１３は、Ｗｅｂページ作成・送信等に必要なプログラム等をロードしたり、当該プログラムの作業データを書き込んだりするために用いられる、書き込み可能な揮発性のメモリである。また通信部１４は、インターネットを介してＷｅｂページを構成するデータセグメントを携帯電話２へ送信し、携帯電話２から当該データセグメントに対するＡＣＫを受信する等の通信処理を行う。
【００５４】
操作入力部１５は、例えばマウス、キーボード等からなり、Ｗｅｂサーバ１に対するユーザの操作を入力し、当該操作情報を上記ＣＰＵ１１へ通知する。表示部１６は、例えばＬＣＤ（Liquid Crystal Display）、ＣＲＴ（Cathode Ray Tube）、ＰＤＰ(Plasma Display Panel)、ＯＥＬ(Organic Electroluminescence)等からなり、ユーザへ送信するためのＷｅｂページや、ユーザ操作時のＧＵＩ（Graphical User Interface）等を表示する。ＨＤＤ１７は、上記ＲＡＭ１３へロードされＣＰＵ１１により実行される各種プログラムやデータを格納する。
【００５５】
なお、図示しないが、携帯電話２の基本的なハードウェア構成も上記Ｗｅｂサーバと同様であり、ＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、通信部２４、操作入力部２５、表示部２６及びＨＤＤ２７を有する。携帯電話２においては、操作入力部２５はプッシュボタン、ジョグダイヤル等であり、表示部２６は例えばＬＣＤ（Liquid Crystal Display）である。また、ＨＤＤ２７の代わりに、例えばフラッシュメモリ等のカード型の記憶装置を有していてもよい。ＨＤＤ２７または当該フラッシュメモリ内には、ＯＳやＷｅｂページをダウンロードして表示するためのブラウザ等のプログラムやデータが格納される。
【００５６】
図１１は、Ｗｅｂサーバ１のデータ送受信処理における機能構成例を示すブロック図である。当該機能ブロックは、例えばＷｅｂサーバ１のＯＳのカーネル部分に実装されたＴＣＰのプロトコルスタックにより実現される。
【００５７】
同図に示すように、Ｗｅｂサーバ１のデータ通信処理は、データ制御部３１、ＴＣＰ制御部３２、ＴＣＢ(TCP Control Block)記憶部３３、送信バッファ３４、送信部３５、受信部３６、受信バッファ３７により実現される。
【００５８】
データ制御部３１は、Ｗｅｂサーバ１のデータ送受信処理において、ユーザ側のインタ
フェース部分を提供する。データ制御部３１は、ユーザの操作により、図１０の操作入力部１５を介して入力される指示に基づいて、ＨＤＤ１７に記憶されているデータを一旦読み込み、読み込んだデータを送信バッファ３４に書き込む。また、データ制御部３１は、受信バッファ３７のデータを読み込み、操作入力部１５を介して入力されるユーザの指示のもと、ＨＤＤ１７に書き込み、またはそのままプログラムで使用する。
【００５９】
ＴＣＰ制御部３２は、ＴＣＢ記憶部３３にネットワークを介して実行されるコネクションの状態を保持しながら、送信バッファ３４、送信部３５、受信部３６及び受信バッファ３７を制御し、データ送受信処理を実行する。
【００６０】
ＴＣＰ制御部３２は、データ制御部３１により書き込まれた送信バッファ３４内のデータをＴＣＰセグメントの大きさに区切り、ＴＣＰウィンドウの値（ウィンドウサイズ）の数のデータセグメントを、ＴＣＰウィンドウとして設定し、ＴＣＰウィンドウ内のデータセグメントを送信部３５に供給する。ウィンドウサイズは、送信されるデータセグメント量を示しており、インターネット４においてセグメントのロスがなければ、徐々に膨張する。しかし、セグメントがロスすると、ウィンドウサイズは、１セグメントに戻る。ＴＣＰ制御部３２は、このようなウィンドウサイズを用いて、送信するデータセグメントの量を調整する。
【００６１】
このとき、ＴＣＰ制御部３２は、ウィンドウ内のデータセグメントそれぞれに対して、上記当該データセグメントが、上記Negligible ACKを要求するデータセグメントか、Significant ACKを要求するデータセグメントかのフラグ（以下、ＡＣＫ要否フラグという）を付与して送信する。当該フラグ付与時の動作の詳細については後述する。
【００６２】
また、当該ＡＣＫ要否フラグ以外にも、特殊フラグを付与する必要がある場合には当該特殊フラグも付与する。特殊フラグとは、ＳＹＮ（Synchronize Flag）、ＦＩＮ（Fin Flag）、ＲＳＴ（Reset Flag）、ＰＵＳＨ（Push Flag）、ＵＲＧ（Urgent Flag）等のいわゆるコントロールフラグをいい、当該フラグがオン（bit = 1）になっていれば、ＳＹＮならコネクションの開始、ＦＩＮならコネクションの終了、ＲＳＴならコネクションのリセット、ＰＵＳＨならアプリケーションにすぐに渡すデータ、ＵＲＧなら緊急に処理すべきデータ、といった意味をそれぞれ持っている。
【００６３】
また、ＴＣＰ制御部３２は、送信部３５からデータセグメントが送信されると、内蔵する再送タイマを起動させる。再送タイマは、受信部３６に、携帯電話２から、Significant ACKセグメント（以下、単にSignificant ACKという）が受信されると停止する。再送タイマは、所定の時間（再送タイマ動作時間）が経過しても、受信部３６にSignificant ACKが受信されない場合、タイムアウトする。上記Significant ACKは、当該Significant ACKを要求するデータセグメントを含むウィンドウ内の全てのデータセグメントが携帯電話２へ届いたことを示している。
【００６４】
ＴＣＰ制御部３２は、再送タイマにより計時動作を行い、受信部３６を監視しており、携帯電話２から前回送信されたデータセグメントに対応するSignificant ACKが所定の時間（再送タイマ動作時間）内に受信されたか否かを判断し、その判断に基づいて、どのデータセグメントを送信部３５に供給するかを制御する。
【００６５】
具体的には、受信部３６が前回送信されたデータセグメントに対応するSignificant ACKを受信した場合、ＴＣＰ制御部３２は、ＴＣＰウィンドウの値を拡張し、受信したSignificant ACKが要求するデータセグメントから、ウィンドウサイズ分のデータセグメントを、ＴＣＰウィンドウとして設定し、ＴＣＰウィンドウ内のデータセグメントを送信部３５に供給する。例えば、ＴＣＰウィンドウの値が５であれば、受信したSignificant ACKが要求するデータセグメントから始まる５個のデータセグメントを、ＴＣＰウィンドウとして設定し、ＴＣＰウィンドウ内のデータセグメントを送信部３５に供給する。
【００６６】
一方、受信部３６がSignificant ACKを受信しなかった場合、ＴＣＰ制御部３２は、ネットワーク上でのセグメント（Significant ACKまたはデータセグメント）の喪失があったとして、ＴＣＰウィンドウの値を１に収縮し、前回送信したデータセグメントのうち、シーケンス番号の最小のデータセグメントである再送セグメントを、ＴＣＰウィンドウとして設定し、その再送セグメントを送信部３５に供給する。
【００６７】
ＴＣＢ記憶部３３は、メモリなどにより構成され、ＴＣＰ制御部３２により書き込まれたウィンドウサイズ、各セグメントのセグメントサイズ、再送タイマ動作時間、送信したがＡＣＫがないデータセグメントの最小シーケンス番号、及び、次に送信すべきデータセグメントのシーケンス番号等を保持している。送信バッファ３４は、例えば３２bytesのバッファにより構成され、携帯電話２に送信するデータセグメントが一旦蓄積され、蓄積されたデータセグメントは、送信部３５により送信されると消去される。これにより、データ制御部３１は、送信バッファ３４の空き領域に、新たにデータを書き込むことができる。
【００６８】
受信部３６は、携帯電話２から送信されたSignificant ACKを、インターネット４を介して受信する。受信バッファ３７は、例えば３２bytesのバッファにより構成され、受信部３６より書き込まれたデータが一旦蓄積される。蓄積されたデータは、データ制御部３１により読み込まれる。
【００６９】
また、図示しないが、携帯電話２も、データ制御部４１、ＴＣＰ制御部４２、ＴＣＢ記憶部４３、送信バッファ４４、送信部４５、受信部４６及び受信バッファ４７というように、基本的には上記Ｗｅｂサーバ１の機能構成ブロック図と同様の構成を有するが、ＴＣＰ制御部４７は、上記Ｗｅｂサーバ１のＴＣＰ制御部３２が、データセグメントに対するＡＣＫ要否フラグを付与する機能を有する代わりに、当該ＡＣＫ要否フラグを参照して、Ｗｅｂサーバ１に対するＡＣＫの送信の要否を判断する機能を有する。
【００７０】
すなわち、携帯電話２のＴＣＰ制御部４７は、Ｗｅｂサーバ１から受信したデータセグメントが、上記Significant ACKを要求するデータセグメントであった場合には送信部３５を介して当該Significant ACKを返し、それ以外のデータセグメントに対してはＡＣＫを送信しない。また、携帯電話２は、上記Ｗｅｂサーバへデータを送信するよりも上記Ｗｅｂサーバ１からデータを受信することが主であるため、上記Ｗｅｂサーバ１における再送タイマの機能は有していなくてもよい。また、ＴＣＢ記憶部４３には、上記Ｗｅｂサーバ１が次に送信すべきデータセグメントのシーケンス番号を保持している代わりに、次に受信すべきデータセグメントのシーケンス番号を保持している。
【００７１】
また、受信部３６は、Ｗｅｂサーバ１から受信したデータセグメントを無線ＬＡＮにより受信し、当該データを受信バッファ３７が一旦蓄積する。蓄積されたデータはデータ制御部３１に読み込まれ、ＨＤＤ２７へ保存されるか、またはアプリケーションに渡される。
【００７２】
次に、以上のように構成されたＷｅｂサーバ１及び携帯電話２の動作について説明する。
【００７３】
まず、Ｗｅｂサーバ１のデータセグメント送信時の動作について説明する。図１２は、当該動作について説明したフローチャートである。なお、同図においては、Ｗｅｂサーバ１が携帯電話２へ送信したがＡＣＫがないデータセグメントの最小のシーケンス番号をsend_una、携帯電話２へ次に送信するデータセグメントのシーケンス番号をsend_nxt、送信するデータセグメントのセグメントサイズをmaxseg、そしてウィンドウサイズをwindowと表記する。上述したように、これらのデータは上記ＴＣＢ記憶部３３に記憶されており、当該動作時には例えばＲＡＭ１３へロードされる。
【００７４】
同図に示すように、まず、Ｗｅｂサーバ１のＴＣＰ制御部３２は、携帯電話２に次に送信するデータセグメントのシーケンス番号をsend_nxtに設定する（ステップ５１）。そして、send_nxtの値からsend_unaの値を引いた値と、windowの値とを比較する（ステップ５２）。当該比較の結果、windowの値の方が大きい場合（ステップ５２のＹＥＳ）には、次に、上記send_nxtの値からsend_unaの値を引いた値にmaxsegを加えた値と、上記windowの値とを比較する（ステップ５３）。当該比較の結果、両者が等しくなる場合（ステップ５３のＹＥＳ）には、上記ＡＣＫ要否フラグのビットを１に設定する（ステップ５４）。また、両者が等しくない場合（ステップ５３のＮＯ）には、当該ＡＣＫ要否フラグのビットを０に設定する（ステップ５５）。そして、当該ＡＣＫ要否フラグを設定したデータセグメントを、送信部３５を介して携帯電話２へ送信する（ステップ５６）。
【００７５】
上記ステップ５３において、両者の値が等しくなる場合というのは、次に送信するデータセグメント（send_nxt）がウィンドウ内の最後のデータセグメントであることを示している。従って、その場合には当該ウィンドウ内の最後のデータセグメントに対してはSignificant ACKを要求するためにＡＣＫ要否フラグを１に設定する。
【００７６】
例えば、windowが５０、maxsegが１０であり、send_nxtが４０、send_unaが１０だとすると、上記ステップ５３において４０−１０＋１０＝４０>５０となるため、ＡＣＫ要否フラグのbitは０に設定する。また、windowが５０、maxsegが１０であり、send_nxtが５０（ウィンドウ内の最後のデータセグメント）、send_unaが１０だとすると、上記ステップ５３において５０−１０＋１０＝５０となるため、ＡＣＫ要否フラグのbitは１に設定する。すなわち、ウィンドウ内の最後のデータセグメントに対するＡＣＫのみを要求するように上記ＡＣＫ要否フラグを付与する。
【００７７】
次に、携帯電話２のデータセグメント受信時の動作について説明する。図１３は、当該動作について説明したフローチャートである。なお、同図においては、携帯電話２が次に受信すべきデータセグメントのシーケンス番号の値をrcv_nxt、Ｗｅｂサーバ１へ重複して送信されたＡＣＫの数をdup_cntと表記する。
【００７８】
同図に示すように、まず、携帯電話２は、上記Ｗｅｂサーバ１から送信されたデータセグメントを受信する（ステップ６１）。続いて、当該受信したデータセグメントのシーケンス番号をseqnoに設定する（ステップ６２）。そして、受信されたデータセグメントに付与された上記ＡＣＫ要否フラグを参照して、ＡＣＫの送信の要否を判断する（ステップ６３）。すなわち、上記ＡＣＫ要否フラグのbitが１になっていれば（ステップ６３のＹＥＳ）、ＡＣＫ（Significant ACK）を送信部４５によりホットスポット３を介してＷｅｂサーバ１へ送信する（ステップ６４）。
【００７９】
なお、例外処理として、上記ＡＣＫ要否フラグのbitが０の場合（ステップ６３のＮＯ）であっても、上記特殊フラグが付与されている否かを判断し（ステップ６５）、付与されている場合（ステップ６５のＹＥＳ）にはＡＣＫを送信する（ステップ６４）。これにより上記特殊フラグの意思を確実に反映させることができ、従来のＴＣＰとの互換性を保つことができる。
【００８０】
また、特殊フラグが付与されていない場合（ステップ６５のＮＯ）でも、上記設定したシーケンス番号seqnoと上記rcv_nxtとを比較して（ステップ６８）、seqnoの方が大きい場合には、dup_cntの値をカウントする（ステップ６７）。すなわち、上記設定したseqnoの方が次に受信すべきデータセグメントのシーケンス番号rcv_nxtよりも大きいということは、Ｗｅｂサーバ１から送信されたデータセグメントが届く順番に狂いが生じていることを示している。例えば、シーケンス番号が１，２，４，５，６，７と３が抜けて到着したような場合が挙げられる。これは、上記送信されたデータセグメントがインターネット４上またはホットスポット３との通信間に喪失したため、またはインターネット４や無線ＬＡＮの輻輳により、後に送信されたデータセグメントの方が先に到着していることによる。このような場合には、次に受信すべきデータセグメントの再送をＷｅｂサーバ１へ要求するためのＡＣＫ、すなわち次に受信すべきデータセグメントのシーケンス番号の一つ前のシーケンス番号のデータに対するＡＣＫ（上記例ではセグメント２に対するセグメント３を要求するＡＣＫ）を再度重複して送信する（ステップ６４）。ただし、当該重複の数を上記dup_cntによりカウントして、dup_cntの値が４未満となるように、すなわち送信する重複ＡＣＫの数を３つまでとし、４回以上重複ＡＣＫを送信しないように制御する（ステップ６９）。この処理により、上記Ｗｅｂサーバ１において、いわゆる高速再送制御が行われることとなり、従来のＴＣＰとの互換性を保つことができる。
【００８１】
なお、上記ステップ６６においてsecnoの方が小さい場合（ステップ６６のＮＯ）、及び上記ステップ６９においてdup_cntの値が４以上である場合には何のＡＣＫも送らずに終了する。これにより上記Negligible ACKが送信されるのを抑制することができる。
【００８２】
本発明者らは、本実施形態における手法を用いてデータを送信した場合に受信側からのNegligible ACKをどれほど削減することができるか、及びスループットはどうなるかについて検証した。図１４は、データロス率を０%から０．０２%まで０．００１%毎に増やして、本実施形態における手法と同様の手法を用いた場合と、現在のＴＣＰの事実上の標準とされているＴＣＰ−Ｒｅｎｏ方式を用いた場合とで、スループットとＡＣＫの数とをそれぞれ上記シミュレータにより測定した結果を示した図である。同図においては、１０Mbpsのリンクを100000個のデータセグメントを送信する１本のＴＣＰが流れる環境を想定している。ロス率をリンクに設定することにより、任意の確率でセグメントを落とすことが可能である。同図の棒グラフのうち、色塗りで示しているのがＴＣＰ−ＲｅｎｏにおけるＡＣＫの数、網掛けで示しているのが本実施形態の手法におけるＡＣＫの数であり、また折れ線のうち、ポイントを菱形で示しているのがＴＣＰ−Ｒｅｎｏにおけるスループット、正方形で示しているのが本実施形態におけるスループットである。
【００８３】
同図に示すように、ＴＣＰ−Ｒｅｎｏにおいては、９．３Mbpsから８．５Mbps程度のスループットの変動が見られ、ＡＣＫの数に関してはほぼ変わらず50000以上のＡＣＫが送られていた。一方、本実施形態の手法を用いた場合には、スループットは６Mbpsから７．５Mbps程度と、ロス率が０%の時で３０%程度のスループットの悪化が見られた。また、ロス率が高くなるに従って、ＴＣＰ−Ｒｅｎｏと本実施形態の手法の性能は近づいてくる。これは、ロス率が高い場合、ＴＣＰの輻輳制御によりウィンドウが小さくなり、Significant ACKの割合が多くなるためである。次に、ＡＣＫの数に注目すると、ロス率が０%の時には、本実施形態における手法の場合にはＴＣＰ−Ｒｅｎｏと比較して６０分の１程度減少していることが分かる。すなわち、９８．３%のＡＣＫが減少していることとなる。この測定結果により、本実施形態における手法を用いた場合には、スループットを受容可能な範囲に保ちながらも、従来のＴＣＰで送信されるＡＣＫの数を劇的に減少させることができることが分かる。
【００８４】
図１５は、受信側においてＡＣＫセグメントの送信により消費される電力を上記本発明の手法による場合とＴＣＰ−Ｒｅｎｏの場合とで計測し、比較した図である。同図においてＸ軸はデータロス率、Ｙ軸は消費電力を示している。同図に示すように、本実施形態による手法を用いることにより、最低（データロス率が０．１%の場合）でも約４０%、最高（データロス率が０%の場合）では約８５%の省電力が実現されている。このように、ＡＣＫの減少により、上記Ｗｅｂサーバ１及び携帯電話２の消費電力を劇的に減少させることができ、ＴＣＰを用いた快適な無線通信を行なうことができる。特に無線通信においては、消費電力はデータサイズよりもデータ数に依存して変動するため、データ数（ＡＣＫの数）を削減する本実施形態の手法は効果的である。
【００８５】
（第２の実施形態）  
上述の第１の実施形態においては、送信側（Ｗｅｂサーバ１）と受信側（携帯電話２）の両端のＴＣＰに変更を加えていた。しかし、無線通信においてはデータを受信することが一般的であるため、受信側のＴＣＰのみ変更することは実装面においても実現が容易であり、理想的であるといえる。そこで、本発明では、受信側のＴＣＰのみ変更する手法も実現することが可能である。以下、この場合の実施の形態について説明する。
【００８６】
図示しないが、本実施形態におけるネットワークの構成は、上記第１実施形態の図９で説明した構成と同様に、Ｗｅｂサーバ１、携帯電話２及びホットスポット３で構成される。Ｗｅｂサーバ１は、従来の例えばＴＣＰ−Ｒｅｎｏのような方式を用いてデータを送信することができる。携帯電話２のハードウェア構成も基本的には上記第１実施形態の場合と同様であるが、ＴＣＰ制御部４２等の機能は異なる。本実施形態においてＷｅｂサーバ１から送信されるデータセグメントは、従来のＴＣＰにおけるデータセグメントと同様である（上記ＡＣＫ要否フラグのような特別な処理を何も施されていない）ため、受信したデータセグメントに対して、ＡＣＫを送信すべきか否かの判断、すなわち、Negligible ACKとSignificant ACKとの識別を、上記ＡＣＫ要否フラグ等を参照することなく、自ら行なう必要がある。
【００８７】
当該Negligible ACKとSignificant ACKとの識別方法として、本発明者らは、ＴＣＰがウィンドウによって通信制御を行っている点に着目した。ウィンドウによるデータセグメントの転送はバースト的であることが知られている。本発明者らは、実際に、一本のリンクを複数のフローと共有するような環境において、従来のＴＣＰがどのような間隔でデータセグメントを送信しているのかについて調べた。
【００８８】
図１６はその結果を示した図である。同図においては、リンクを１０本のフローで共有している場合と、２００本のフローで共有している場合の２通りの実験を行った。上段の（ａ）が１０本のフローで共有している場合、下段の（ｂ）が２００本のフローで教諭している場合を示している。Ｘ軸及びＹ軸はそれぞれlogで表示されている。
【００８９】
同図に示すように、（ｂ）の場合には、２００本のフローで共有しているため、（ａ）の場合に比べて再送が頻繁に行なわれ、Ｘ軸の右側の、セグメントの送受信間隔が長い部分にも分布があることが分かる。この２つのグラフにおいて注目すべき点は、（ａ）及び（ｂ）の一番左側の部分である。この部分では、１ms以下の間隔のセグメント全体の４０%近く存在していた。これらのセグメントは、同一ウィンドウ内でバースト的に送られたセグメントであった。
【００９０】
これらの結果から、Significant ACKを要求するウィンドウの最後のセグメントが送信されてから、次のセグメントが送信されるまでには、あるアイドル時間が存在すると考えることが妥当である。すなわち、同図（ｂ）で説明すると、送受信間隔が０．０１sec付近から０．１sec付近の分布が当該アイドル時間を示していると考えられる。それよりも右側の部分は、データセグメント再送によるものであると推測できる。
【００９１】
本実施形態においては、この特徴を利用して、受信ノードの遅延タイマに変更を加えることとした。ここで、本実施形態における受信ノードをFlexible Delayed Timer（ＦＤＴ）と呼ぶこととする。従来のＴＣＰの受信ノードの遅延タイマは、一定間隔でタイムアウトし、その時にＡＣＫを送信するべきセグメントがある場合にＡＣＫを送信している。本実施形態のＦＤＴは、基本的には従来の遅延タイマと同じ仕組みであるが、一定間隔でタイムアウトせずに、セグメントを受け取る度にリセットされる。そのため、ＦＤＴの期間データセグメントを受信しない場合に、ＡＣＫが送信されることになる。これにより、結果的に上記ウィンドウの最後のデータに対してのみＡＣＫを返信することができる。すなわち、Significant ACKのみを送信し、Negligible ACKを送信しないようにすることが可能となる。
【００９２】
以下、本実施形態における携帯電話２の動作について説明する。図１７は、携帯電話２のデータセグメント受信時の動作を示したフローチャートである。同図において表記されているseqno、rcv_nxt、dup_cnt等の略語は上記第１実施形態における場合と同様の意味を有している。
【００９３】
同図に示すように、まず、携帯電話２は、受信部３６により、Ｗｅｂサーバ１から送信されたデータセグメントを受信する（ステップ７１）と、受信部のＴＣＰ制御部４２は、当該受信したデータセグメントのシーケンス番号をsecnoに設定する（ステップ７２）。そして、上記ＦＤＴの固定値Ｋを設定する（ステップ７３）。当該Ｋは、例えば１〜１０msである。続いて、上記設定したＦＤＴタイムアウトしたか否かを確認する（ステップ７４）。タイムアウトした場合（ステップ７４のＹＥＳ）には、上記secnoに設定したデータセグメントに対するＡＣＫを、送信部４５によりＷｅｂサーバ１へ送信する（ステップ７５）。また、一方で、上記受信されたデータセグメントに上記特殊フラグが付与されていないか、また順序が狂って到着したデータセグメントではないか等、上記第１実施形態の図１３と同様の処理を行い、必要に応じてＡＣＫを送信する（ステップ７６〜８０）。なお、本実施形態において、上記特殊フラグのうちＰＵＳＨフラグに対して即座にＡＣＫを返すことは、Bandwidth-Delay ProduceがＴＣＰの最大ウィンドウ長よりも小さなコネクションの場合に特に有効である。その場合には、本実施形態におけるＦＤＴがタイムアウトせずにセグメントが連続的に流れることになるからである。
【００９４】
以上の処理により、上記ＦＤＴを用いることで結果的にウィンドウの最後のデータセグメントのみにＡＣＫを返信することとなり、上記Negligible ACKを削減することが可能となる。また、特殊フラグに対してはＡＣＫを返し、また高速再送制御を行うことで、従来のＴＣＰとの互換性も保つことができる。
【００９５】
本発明者らは、上記第１実施形態の場合と同様、本実施形態における手法を用いた場合の性能について検証した。図１８は、本実施形態における手法を用いた場合のＡＣＫの数及びスループットをそれぞれシミュレーションにより測定した結果を示した図である。同図においても、上記図１４の場合と同様、１０Mbpsのリンクを100000個のデータセグメントを送信する１本のＴＣＰが流れる環境を想定している。本実施形態の手法においては、上記ＦＤＴのタイマ粒度によって性能が左右されることは明らかであるため、ＦＤＴの固定値Ｋを１ms、５ms、１０ms、５０ms、１００ms、５００msの６パターンに設定した場合についてそれぞれ測定した。同図において折れ線グラフで示されているのがスループット、棒グラフで示されているのがＡＣＫの数である。
【００９６】
同図に示すように、上記６パターンのどの場合においても、送信されたＡＣＫの数は等しかった。これは、ＦＤＴがタイムアウトする前に、送信側で再送タイマのタイムアウトによって再送が引き起こされていないことを示している。再送タイマの典型的な値は、２秒であり、その値よりも小さな値にすることにより、再送によるＡＣＫの増加を防ぐことが可能である。
【００９７】
また、１msのタイマを利用することで、上記第１実施形態の手法とほぼ同等のスループット性能（６．５Mbps程度）を示すことができる。また、ＦＤＴを１０msに設定しても、５%程度の性能劣化で済むため、十分受容範囲であるといえる。このように、本実施形態の手法によれば、受信側のＴＣＰのみを変更することによっても上記第１実施形態と同様にＡＣＫを削減し、かつ従来のＴＣＰの性能を受容範囲に保つことが可能であり、これにより、Ｗｅｂサーバ１及び携帯電話２の大幅な省電力化を実現することができる。
【００９８】
なお、本発明は、上述の実施形態にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変更を加え得ることは勿論である。
【００９９】
上述の実施形態においては、通信プロトコルとしてＴＣＰを用いていたが、本発明を適用可能なプロトコルはＴＣＰに限られず、ＵＤＰ等、ＡＣＫを用いて通信を行なうプロトコルであればどのようなプロトコルにも適用することが可能である。
【０１００】
上述の実施形態においては、無線端末として携帯電話を用いた例について説明したが、無線端末は勿論これに限られず、例えばＰＤＡやデータ計測用のセンサノード、ノートＰＣ等、あらゆる無線端末に適用することができる。
【０１０１】
上述の実施形態においてはＷｅｂサーバと携帯端末がホットスポットを介して通信を行なう場合について説明したが、ネットワークの構成はこの態様に限られるものではなく、例えば携帯電話等の無線端末同士が通信を行うような態様にも適用することができる。また、無線通信手段としては無線ＬＡＮを用いていたが、例えばBluetooth等の近距離無線通信規格やその他の規格も用いることができる。更に、本発明を、デスクトップ型のＰＣ等、有線によりネットワークに接続された機器に適用することも勿論可能である。
【０１０２】
また、上述の実施形態における手法に、別の手法を組み合わせることも可能である。例えば、ACK Reconstructionという仕組みが存在する。これは、ＡＣＫの数ではなくシーケンス番号を基準に輻輳制御を行うように送信側のＴＣＰを変更するものである。特に本発明の上記第１実施形態の手法において、当該ACK Reconstructionを送信側に利用することで、高いスループットが期待できる。
【０１０３】
また、ＡＣＫを削減するための別の手法として、例えば送信側で、ウィンドウ制御により送信したデータセグメントに対するＡＣＫが所定時間内に受信されず再送タイマがタイムアウトしてしまった場合に、当該送信したデータセグメントを再送するのではなく、当該送信済みのデータセグメントの次のシーケンス番号のデータセグメント（これを飛躍セグメントと称する）を送信する、という手法も考えられる。そしてこの場合、受信側では、飛躍セグメントを受信すると、まだ受信していないセグメントを要求するＡＣＫを返信する。例えば、送信側が１，２，３，４のデータセグメントを送信した場合に、４が喪失してしまい、送信側の再送タイマがタイムアウトしてしまったとする。そこで、送信側は送信したデータセグメントの次のデータセグメント５を送信する。受信側では当該５に対するＡＣＫとして４を返す。更に送信側では、当該４のＡＣＫを受けてデータセグメント４と、次の送信済みセグメント５を飛ばしたセグメント６を送信する。このような手法を用いることで、従来のＴＣＰならば１〜４全てのデータセグメントが再送されるのに比較して、再送されるデータセグメントの量を削減することができる。
【０１０４】
そして、再送されるデータセグメントを削減するこの手法と、ＡＣＫを削減することにより間接的に再送されるデータセグメントも削減する本発明の手法を組み合わせることで、省電力のみならずスループットを向上させることもできる。
【図面の簡単な説明】
【０１０５】
【図１】送信ノードＡ及び受信ノードＢ、それら以外に近隣に存在するＣ、Ｄ及びＥのノードでのデータ通信において消費される電力について説明した図である。
【図２】データセグメントのみをランダムに破棄した場合のロス率とスループットとの関係を示した図である。
【図３】ＡＣＫセグメントのみをランダムに破棄した場合のロス率とスループットとの関係を示した図である。
【図４】ＡＣＫセグメントのロス率０．３〜０．５の場合のスループットを示した図である。
【図５】ＡＣＫセグメントのロス率０．５〜０．７の場合のスループットを示した図である。
【図６】送信ノードにおける送信データセグメントと受信ＡＣＫセグメントのシーケンス番号を時系列的にプロットしたグラフである。
【図７】ＴＣＰの通信において送信ノードから送信されるデータに対してＡＣＫが送信される様子を示した図である。
【図８】データロス率を変更させながらNegligible ACKとSignificant ACKの数の比率を測定した結果を示した図である。
【図９】第１の実施形態における通信システムの構成を示した図である。
【図１０】Ｗｅｂサーバのハードウェア構成を示した図である。
【図１１】Ｗｅｂサーバ１のデータ送受信処理における機能構成例を示すブロック図である。
【図１２】Ｗｅｂサーバ１のデータセグメント送信時の動作について説明する。図１２は、当該動作について説明したフローチャートである。
【図１３】携帯電話２のデータセグメント受信時の動作について説明したフローチャートである。
【図１４】第１実施形態の手法とＴＣＰ−Ｒｅｎｏ方式とでＡＣＫの数とスループットを測定、比較した結果を示した図である。
【図１５】ＡＣＫの送信による消費電力を、第１実施形態による手法とＴＣＰ−Ｒｅｎｏとで計測して比較した図である。
【図１６】従来のＴＣＰがデータセグメントを送信している間隔について計測した結果を示した図である。
【図１７】携帯電話２のデータセグメント受信時の動作について説明したフローチャートである。
【図１８】第２実施形態における手法を用いた場合のＡＣＫの数及びスループットをそれぞれシミュレーションにより測定した結果を示した図である。
【符号の説明】
【０１０６】
１…Ｗｅｂサーバ
２…携帯電話
３…ホットスポット
４…インターネット
１４、２４…通信部
３１、４１…データ制御部
３２、４２…ＴＣＰ制御部
３３、４３…ＴＣＢ記憶部
３４、４４…送信バッファ
３５、４５…送信部
３６、４６…受信部
３７、４７…受信バッファ
【図１】
2006086611.tif 000003
【図２】
2006086611.tif 000004
【図３】
2006086611.tif 000005
【図４】
2006086611.tif 000006
【図５】
2006086611.tif 000007
【図６】
2006086611.tif 000008
【図７】
2006086611.tif 000009
【図８】
2006086611.tif 000010
【図９】
2006086611.tif 000011
【図１０】
2006086611.tif 000012
【図１１】
2006086611.tif 000013
【図１２】
2006086611.tif 000014
【図１３】
2006086611.tif 000015
【図１４】
2006086611.tif 000016
【図１５】
2006086611.tif 000017
【図１６】
2006086611.tif 000018
【図１７】
2006086611.tif 000019
【図１８】
2006086611.tif 000020