通信装置、通信システム、プログラム及び通信方法
【課題】広帯域及び高遅延環境において、スループットを向上させることができる通信装置等の技術を提供すること。
【解決手段】送信側通信装置１は、受信ウィンドウサイズ（Ｒｗｎｄ＝３）が通知されると、通知された受信ウィンドウサイズに応じて、１〜３番目までのパケットを受信側通信装置２に送信する。送信側通信装置１は、ａｃｋ＝４の確認応答を受信すると、４〜６番目のパケットを送信する。送信側通信装置１は、広帯域及び高遅延環境である場合、パケットの送信が停止される期間を予測し、ａｃｋ＝７が受信される前に、７〜９番目のパケットを追加的に送信する。この場合、送信側通信装置１は、送信ウィンドウサイズを受信ウィンドウサイズよりも大きくして、拡大送信を実行する。受信側通信装置２の受信バッファは、空いている状態であるので、追加的に送信された７〜９番目のパケットは、受信側通信装置２に届く。
【解決手段】送信側通信装置１は、受信ウィンドウサイズ（Ｒｗｎｄ＝３）が通知されると、通知された受信ウィンドウサイズに応じて、１〜３番目までのパケットを受信側通信装置２に送信する。送信側通信装置１は、ａｃｋ＝４の確認応答を受信すると、４〜６番目のパケットを送信する。送信側通信装置１は、広帯域及び高遅延環境である場合、パケットの送信が停止される期間を予測し、ａｃｋ＝７が受信される前に、７〜９番目のパケットを追加的に送信する。この場合、送信側通信装置１は、送信ウィンドウサイズを受信ウィンドウサイズよりも大きくして、拡大送信を実行する。受信側通信装置２の受信バッファは、空いている状態であるので、追加的に送信された７〜９番目のパケットは、受信側通信装置２に届く。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＴＣＰ（Transmission Control Protocol）等の通信方式によって他の通信装置と通信する通信装置等の技術に関する。
【背景技術】
【０００２】
ＴＣＰは、現在、インターネットやイントラネット等で広く利用されている。ＴＣＰでは、データを受信側の通信装置が、データを送信する側の通信装置からパケットを受信した場合、受信側の通信装置は、送信側の通信装置に対して、確認応答（ａｃｋ：acknowledgement）を返すように構成されている。これにより、ＴＣＰでは、信頼性の高い通信を実現することができる。
【０００３】
ＴＣＰでは、スライドウィンドウ方式が採用されており、送信側の通信装置は、確認応答（ａｃｋ）が届く度にウィンドウをスライドさせるようにしてパケットを順番に受信側の送信装置へ送信する。
【０００４】
また、ＴＣＰでは、一般的にフロー制御と、輻輳制御が実行される。フロー制御では、受信側の通信装置が、送信側の通信装置に対して、最新の受信ウィンドウサイズを通知する。送信側の通信装置は、通知された受信ウィンドウサイズに応じた送信量のパケットを送信する。これにより、受信側の通信装置の受信バッファからパケットが溢れ出してしまうことを防止することができる。
【０００５】
一方、輻輳制御では、送信側の通信装置が、スロースタートアルゴリズム及び輻輳回避アルゴリズムに従って、輻輳ウィンドウサイズを制御することで、ネットワークの輻輳（混雑）を回避している。スロースタートアルゴリズムでは、最初に輻輳ウィンドウサイズが１ＭＳＳ（Maximum Segment Size）に設定され、徐々に輻輳ウィンドウサイズが大きくされる。輻輳回避アルゴリズムでは、パケットの紛失等や、ＲＴＴ（Round Trip Time）の変化から輻輳を検知し、輻輳ウィンドウサイズが調整される等の処理が実行される。なお、送信側の通信装置からパケットが送信される場合、輻輳ウィンドウサイズ及び受信ウィンドウのうち、小さいほうのウィンドウサイズに対応する送信量のパケットが送信される。
【０００６】
なお、ＴＣＰに関連する技術は、下記特許文献１、２等に記載されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００６−００５８３３号公報
【特許文献２】特開２００６−２７９７３０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ここで、送信側の通信装置と、受信側の通信装置との間の経路の帯域が広帯域であり、かつ、上記経路が長く、ＲＴＴが大きい（以下、高遅延と呼ぶ）場合を想定する。この場合、上記経路が広帯域環境であるので、輻輳ウィンドウサイズが受信ウィンドウサイズに達し、送信側の通信装置から送信されるパケットの送信量は、受信ウィンドウサイズによって決定される。すなわち、フロー制御が支配的な状態となる。上記経路が長く、ＲＴＴが大きい（高遅延）場合、実際には、受信側の送信装置の受信バッファが空いている期間が長いにも拘らず、送信側の通信装置は、フロー制御により、受信ウィンドウサイズに対応する送信量のデータしか送信することができない。すなわち、広帯域及び高遅延環境において、フロー制御による制限によって、スループットが上がらないといった問題がある。
【０００９】
以上のような事情に鑑み、本発明の目的は、広帯域及び高遅延環境において、スループットを向上させることができる通信装置等の技術を提供することにある。
【課題を解決するための手段】
【００１０】
上記目的を達成するため、本発明の一形態に係る通信装置は、通信部と、制御部とを具備する。
前記通信部は、受信側通信装置から受信ウィンドウサイズを受信し、かつ、送信ウィンドウサイズに応じた送信量のパケットを前記受信側通信装置に送信する。
前記制御部は、前記受信側通信装置との間の経路が広帯域及び高遅延環境であるか否かを判定し、広帯域及び高遅延環境であると判定された場合に、前記送信ウィンドウサイズが前記受信ウィンドウサイズを超えない第１のウィンドウサイズとされる第１の状態を、前記送信ウィンドウサイズが前記受信ウィンドウサイズを超える第２のウィンドウサイズとされる第２の状態へ切り替え、前記第２の状態で前記受信ウィンドウサイズを超えた送信量の前記パケットを送信する。
【００１１】
この通信装置では、広帯域及び高遅延環境である場合に、送信ウィンドウサイズが、受信ウィンドウサイズを超えるサイズ（第２のウィンドウサイズ）とされ、受信ウィンドウサイズを超えた送信量のパケットが送信される。これにより、広帯域及び高遅延環境下において、スループットを向上させることができる。
【００１２】
上記通信装置において、前記通信部は、前記通信部は、確認応答を前記受信側通信装置から受信してもよい。この場合、前記制御部は、前記確認応答が受信されるタイミングで前記パケットを前記送信部から送信させ、かつ、前記第２の状態で、前記確認応答の受信タイミングから前記パケットの送信が停止される期間を予測し、前記期間に前記パケットを追加的に前記送信部から送信させてもよい。
【００１３】
この通信装置では、受信側の通信装置に対して、適切なタイミングで、パケットを追加的に送信することができる。
【００１４】
上記通信装置において、前記制御部は、前記期間内に前記パケットを分散して前記送信部から送信させてもよい。
【００１５】
このように、パケットを分散して送信することで、バースト送信を回避することができる。これにより、経路の途中でパケットが紛失してしまうことを防止することができる。
【００１６】
上記通信装置において、前記制御部は、前記第２の状態で、前記確認応答が所定時間内に集中して受信されたかを判定し、前記確認応答が集中して受信された場合に、前記確認応答の受信タイミングに応じた前記パケットの送信を部分的に規制してもよい。
【００１７】
このように、前記確認応答が集中して受信された場合に、前記確認応答の受信タイミングに応じた前記パケットの送信を部分的に規制することで、バースト送信を回避することができる。これにより、経路の途中でパケットが紛失してしまうことを防止することができる。
【００１８】
上記通信装置において、前記制御部は、送信された前記パケットの前記経路上での紛失を検知し、前記第２の状態で前記パケットの紛失が検知された場合に、前記送信ウィンドウサイズが第２のウィンドウサイズとされる前記第２の状態を、前記ウィンドウサイズが前記第２のウィンドウサイズよりも小さい第３のウィンドウサイズとされる第３の状態へ切り替えてもよい。
【００１９】
これにより、紛失したパケットを適切に再送することができる。
【００２０】
上記通信装置において、前記制御部は、前記第２の状態が前記第３の状態に切り替えられた場合に、第３のウィンドウサイズを超えて既に送信済みのパケットは、送信しなかったとして扱ってもよい。
【００２１】
このように、第３のウィンドウサイズを超えて既に送信済みのパケットを、送信しなかったとして扱うことで、パケット紛失によるエラーから速やかに回復することができる。
【００２２】
上記送信装置において、前記第３のウィンドウサイズは、前記受信ウィンドウサイズよりも大きくてもよい。
【００２３】
このように、第３のウィンサイズを受信ウィンドウサイズよりも大きくすることで、パケット紛失によるエラーからの回復がさらに速くなる。
【００２４】
上記通信部において、前記通信部は、選択確認応答を前記受信側通信装置から受信し、前記制御部は、前記選択確認応答に基づいて、前記第３のウィンドウサイズの大きさを補正してもよい。
【００２５】
これにより、パケット紛失によるエラーからの回復がさらに速くなる。
【００２６】
上記通信装置において、前記制御部は、前記第２の状態が前記第３の状態へ切り替えられる頻度を判定し、前記頻度が所定の閾値よりも大きい場合には、前記第２の状態での前記受信ウィンドウサイズを超えた送信量の前記パケットの送信を規制してもよい。
【００２７】
これにより、パケット紛失による再送が頻発する場合には、受信ウィンドウサイズを超えたパケットの送信が規制される。
【００２８】
上記通信装置において、前記制御部は、前記第２の状態が前記第３の状態へ切り替えられる頻度に応じて、前記第２のウィンドウサイズを可変に制御してもよい。
【００２９】
これにより、例えば、パケットの再送が頻繁に起きる場合には、第２のウィンドウサイズを大きくし、パケットの再送が頻繁に起こらないようであれば、第２のウィンドウサイズを小さくする等、第２のウィンドウサイズを適切に変化させることができる。
【００３０】
本発明の一形態に係る通信システムは、受信側通信装置と、送信側通信装置とを具備する。
前記送信側通信装置は、通信部と、制御部とを有する。
前記通信部は、前記受信側通信装置から受信ウィンドウサイズを受信し、かつ、送信ウィンドウサイズに応じた送信量のパケットを前記受信側通信装置に送信する。
前記制御部は、前記受信側通信装置との間の経路が広帯域及び高遅延環境であるか否かを判定し、広帯域及び高遅延環境であると判定された場合に、前記送信ウィンドウサイズが前記受信ウィンドウサイズ超えない第１のウィンドウサイズとされる第１の状態を、前記送信ウィンドウサイズが前記受信ウィンドウサイズを超える第２のウィンドウサイズとされる第２の状態へ切り替え、前記第２の状態で前記受信ウィンドウサイズを超えた送信量の前記パケットを送信する。
【００３１】
本発明の一形態に係るプログラムは、通信装置に、受信側通信装置から受信ウィンドウサイズを受信するステップを実行させる。
送信ウィンドウサイズに応じた送信量のパケットを受信側通信装置に送信するステップを実行させる。
前記受信側通信装置との間の経路が広帯域及び高遅延環境であるか否かを判定するステップを実行させる。
広帯域及び高遅延環境であると判定された場合に、前記送信ウィンドウサイズが前記受信ウィンドウサイズを超えない第１のウィンドウサイズとされる第１の状態を、前記送信ウィンドウサイズが前記受信ウィンドウサイズを超える第２のウィンドウサイズとされる第２の状態へ切り替えるステップを実行させる。
前記第２の状態で前記受信ウィンドウサイズを超えた送信量の前記パケットを送信するステップを実行させる。
【００３２】
本発明の一形態に係る通信方法は、受信側通信装置から受信ウィンドウサイズを受信することを含む。
送信ウィンドウサイズに応じた送信量のパケットを受信側通信装置が送信される。
前記受信側通信装置との間の経路が広帯域及び高遅延環境であるか否かが判定される。
広帯域及び高遅延環境であると判定された場合に、前記送信ウィンドウサイズが前記受信ウィンドウサイズを超えない第１のウィンドウサイズとされる第１の状態が、前記送信ウィンドウサイズが前記受信ウィンドウサイズを超える第２のウィンドウサイズとされる第２の状態へ切り替えられる。
前記第２の状態で前記受信ウィンドウサイズを超えた送信量の前記パケットが送信される。
【発明の効果】
【００３３】
以上説明したように、本発明の一形態によれば、広帯域及び高遅延環境において、スループットを向上させることができる通信装置等の技術を提供することができる。
【図面の簡単な説明】
【００３４】
【図１】本発明の一実施形態に係る通信システムを示す図である。
【図２】ＯＴＣＰの基本的な考え方を説明するための図である。
【図３】ＯＴＣＰの基本的な考え方を説明するための図である。
【図４】ＴＣＰに基づく通常送信と、ＯＴＰＣに基づく拡大送信の切りかえるときの動作を示すフローチャートである。
【図５】通常送信中、拡大送信中などの各状態における、送信ウィンドウサイズ（輻輳ウィンドウサイズ）を示す図である。
【図６】パケットの送信パターンの測定から拡大送信までの処理を示すフローチャートである。
【図７】パケット送信停止期間の予測について説明するための図であり、パケットの送信タイミングを示す図である。
【図８】追加送信時刻と、追加送信量とが決定される際の処理を説明するための図である。
【図９】追加送信時刻と、追加送信量とが決定される際の処理を説明するための図である。
【図１０】バーストａｃｋに対するバースト送信を防止する際の処理を示すフローチャートである。
【図１１】図１０に示す処理を説明するための補足図であり、記憶スロットに記憶される時刻の変化の様子を示す図である。
【図１２】ＯＴＰＣに基づく拡大送信中においてエラーが発生した場合のリカバリの問題を説明するためのシーケンス図である。
【図１３】送信側通信装置が、素早くエラーから復帰する処理を示すシーケンス図である。
【図１４】エラーから復帰（リカバリ）する際の処理を示すフローチャートである。
【図１５】エラーから復帰（リカバリ）する際の処理を示すフローチャートである。
【発明を実施するための形態】
【００３５】
＜通信システム及び通信装置の構成＞
以下、図面を参照しながら、本発明の実施形態を説明する。図１は、本実施形態に係る通信システム１００を示す図である。
【００３６】
図１に示すように、通信システム１００は、相互にネットワークを介して接続された送信側通信装置１及び受信側通信装置２を有する。送信側通信装置１は、データを送信する側の通信装置であり、受信側通信装置２は、データを受信する側の通信装置である。通信装置１、２としては、例えば、サーバ、ＰＣ（Personal Computer）、携帯電話機などが挙げられるがこれらに限られない。
【００３７】
送信側通信装置１は、通信部１１と、制御部１２と、記憶部１３とを有する。同様に、受信側通信部１１も、通信部２１と、制御部２２と、記憶部２３とを有する。制御部１２、２２は、例えば、ＣＰＵであり、通信装置１、２の各部を統括的に制御する。記憶部１３、２３は、通信装置１、２の制御に必要な各種のプログラムや、各種のデータを記憶するＨＤＤ（Hard Disc Drive）、ＳＳＤ（Solid State Drive）等を含む。また、記憶部１３、２３は、制御部１２の作業領域として用いられる不揮発性のメモリ（例えば、ＲＡＭ（Random Access Memory））を含む。
【００３８】
送信側通信装置１の通信部１１は、送信すべきデータ等を含むパケットを受信側通信装置２に送信したり、受信側通信装置２からパケットを受信したりする。受信側通信装置２の通信部１１は、送信側通信装置１から送信されたパケットを受信したり、確認応答（ａｃｋ：acknowledgement）等の情報を含むパケットを送信側通信装置１に送信したりする。
【００３９】
＜動作説明＞
次に、本実施形態に係る通信システム１００の動作について説明する。
本実施形態に係る通信システム１００では、通常のＴＣＰに従って、パケットの通常送信が実行される第１の状態と、本実施形態の特徴に係るＯＴＣＰ（Optimistic TCP：楽観的ＴＣＰ）に従って、パケットの拡大送信が実行される第２の状態とを有している。
【００４０】
［通常のＴＣＰに従う場合の動作］
まず、通信システム１００が、通常のＴＣＰに従って通信する場合について説明する。まず、通信システム１００は、３ウェイハンドシェイクにより、ＴＣＰコネクションを確立する。３ウェイハンドシェイクでは、ＭＳＳ（Maximum Segment Size）が決定される。送信側通信装置１から送信されるデータがＭＳＳを超える場合、送信側においてデータが複数のパケットに分割される。
【００４１】
通信システム１００では、スライドウィンドウ方式が採用されており、送信側通信装置１は、確認応答（ａｃｋ）が届く度に送信ウィンドウをスライドさせるようにしてパケットを順番に受信側の送信装置へ送信する。
【００４２】
また、通信システム１００では、フロー制御と、輻輳制御とが実行される。フロー制御では、受信側通信装置２は、確認応答（ａｃｋ）を送信する際に、受信ウィンドウサイズ（Ｒｗｎｄ）を送信側通信装置１に通知する。この場合、受信側通信装置２は、ＴＣＰヘッダの中に存在する受信ウィンドウサイズのフィールドに現在の受信ウィンドウサイズを入れて、送信側通信装置１に送信する。送信ウィンドウサイズは、受信ウィンドウサイズを超えない大きさとされ、これにより、送信側から送信されたパケットが受信装置の受信バッファから溢れ出してしまうことが防止される。
【００４３】
輻輳制御では、送信側通信装置１には、輻輳ウィンドウが設定され、送信側通信装置１は、例えば、スロースタートアルゴリズムや、輻輳回避アルゴリズム等に従って、輻輳ウィンドウサイズ（Ｃｗｎｄ）を制御する。スロースタートアルゴリズムでは、最初に輻輳ウィンドウサイズが１ＭＳＳ（Maximum Segment Size）に設定され、徐々に輻輳ウィンドウサイズが大きくされる。輻輳回避アルゴリズムでは、パケットの紛失等や、ＲＴＴ（Round Trip Time）の変化から輻輳を検知し、輻輳ウィンドウサイズが調整される等の処理が実行される。
【００４４】
なお、送信装置から送信されるパケットの送信量は、輻輳ウィンドウサイズ及び受信ウィンドウのうち、小さいほうのウィンドウサイズに対応する送信量とされる。
【００４５】
［ＯＴＰＣの動作］
次に、ＯＴＣＰ（楽観的ＴＣＰ）について説明する。
まず、ＯＴＣＰの基本的な考え方について説明する。図２、図３は、ＯＴＣＰの基本的な考え方を説明するための図である。なお、図２、３では、理解を容易にするために、受信ウィンドウサイズ（Ｒｗｎｄ）や、受信バッファサイズ等は、実際のサイズよりも小さく設定されている。
【００４６】
図２に示すように、送信側通信装置１は、受信側通信装置２から受信ウィンドウサイズ（この例では、Ｒｗｎｄ＝３）が通知されると、通知された受信ウィンドウサイズに応じて、１〜３番目までのパケットを受信側通信装置２に送信する。受信側通信装置２は、１〜３番目のパケットを受信バッファに記憶し、アプリケーションプログラムは、受信バッファに記憶された１〜３番目のパケットを受信バッファから引き抜く。
【００４７】
受信側通信装置２は、１番目のパケットが受信されると、ａｃｋ＝２の確認応答を送信側通信装置１に送信し、２〜３番目のパケットが受信されると、ａｃｋ＝４の確認応答を送信側通信装置１に送信する。送信側通信装置１は、ａｃｋ＝２の確認応答が受信されると、送信ウィンドウをスライドさせて、４番目のパケットを送信し、ａｃｋ＝４が受信されると、５〜６番目のパケットを送信する。
【００４８】
受信側通信装置２は、４〜５番目のパケットを受信バッファに記憶し、アプリケーションプログラムは、受信バッファに記憶された４〜５番目のパケットを受信バッファから引き抜く。
【００４９】
図２の右側において破線で示す期間がＲＲＴと略等しい期間となる。ここで、例えば、送信側通信装置１と、受信側通信装置２との距離が離れている（例えば、日本−ＵＳ）等の理由により、ＲＴＴが大きく、高遅延環境である場合を想定する。このように、ＲＴＴが大きく、高遅延環境である場合、受信側通信装置２の受信バッファが空いている期間が大きい。
【００５０】
図３を参照して、受信バッファが空いているならば、送信装置側から追加的にパケットを送信しても届くので、ＯＴＰＣでは、受信バッファが空いている期間に、追加的にパケットを送信することとしている（７〜９番目のパケット参照）。
【００５１】
図３に示す動作について、送信側通信装置１を基準にして簡単に説明する。送信側通信装置１は、受信ウィンドウサイズ（Ｒｗｎｄ＝３）が通知されると、通知された受信ウィンドウサイズに応じて、１〜３番目までのパケットを受信側通信装置２に送信する。送信側通信装置１は、ａｃｋ＝４の確認応答を受信すると、４〜６番目のパケットを送信する。送信側通信装置１は、ａｃｋ＝７が受信される前に、７〜９番目のパケットを追加的に送信する。このとき、受信バッファは、空いている状態であるので、追加的に送信された７〜９番目のパケットは、受信側通信装置２に届く。
【００５２】
「ＴＣＰに基づく通常送信と、ＯＴＰＣに基づく拡大送信との切り替え」
次に、送信側通信装置１の処理について、具体的に説明する。まず、ＴＣＰに基づく通常送信と、ＯＴＰＣに基づく拡大送信の切り替えについて説明する。
【００５３】
図４は、そのときの送信側通信装置１の処理を示すフローチャートである。図５は、通常送信中、拡大送信中などの各状態における、送信ウィンドウサイズ（輻輳ウィンドウサイズ）を示す図である。
【００５４】
ステップ１０１では、送信側通信装置１の制御部１２は、通常のＴＣＰに基づいて、通常送信を実行している。この通常のＴＣＰに基づく通常送信については、上記した通りである。なお、図５（Ａ）に示すように、通常送信中では、送信ウィドウサイズ（第１の送信ウィンドウサイズ）（ｓｎｄ＿ｕｎａ〜ｓｎｄ＿ｕｎａ）は、受信ウィンドウサイズよりも小さく設定されている。
【００５５】
ステップ１０２では、制御部１２は、受信側通信装置２から送信された確認応答（ａｃｋ）が受信されたか否かを判定する。確認応答（ａｃｋ）が受信された場合（ステップ１０２のＹＥＳ）、制御部１２は、輻輳ウィンドウサイズ（Ｃｗｎｄ）が、受信ウィンドウサイズ（Ｒｗｎｄ）以上であるかを判定する（ステップ１０３）。受信ウィンドウサイズは、確認応答と共にパケットにて受信側通信装置２から通知される。
【００５６】
輻輳ウィンドウサイズが受信ウィンドウサイズ未満の場合（ステップ１０３のＮＯ）、ステップ１０４へ進む。ステップ１０４では、制御部１２は、前回ａｃｋ受信時の受信ウィンドウサイズ（ＰｒｅＲｗｎｄ）を、今回受信した受信ウィンドウサイズ（Ｒｗｎｄ）とし、カウンタによるカウント値（Ｃｎｔ）をゼロとする。そして、ステップ１０１へ戻る。
【００５７】
輻輳ウィンドウサイズが受信ウィドウサイズ以上である場合（ステップ１０３のＹＥＳ）、制御部１２は、今回受信された受信ウィンドウサイズ（Ｒｗｎｄ）が、前回ａｃｋ受信時の受信ウィンドウサイズ（ＰｒｅＲｗｎｄ）と等しいかを判定する（ステップ１０５）。今回の受信ウィンドウサイズが、前回の受信ウィンドウサイズと等しくない場合（ステップ１０５のＮＯ）、制御部１２は、ステップ１０４へ進む。そして、前回の受信ウィンドウサイズ（ＰｒｅＲｗｎｄ）を、今回の受信ウィンドウサイズ（Ｒｗｎｄ）をとし、カウンタによるカウント値（Ｃｎｔ）をゼロとする。そして、ステップ１０１へ戻る。
【００５８】
今回の受信ウィンドウサイズが、前回の受信ウィンドウサイズと等しい場合（ステップ１０５のＹＥＳ）、制御部１２は、カウンタによるカウント値を１プラスする（ステップ１０６）。次に、制御部１２は、カウント値が３以上であるかを判定する（ステップ１０７）。カウント値が３未満である場合（ステップ１０７のＮＯ）、制御部１２は、ステップ１０１へ戻る。
【００５９】
一方、カウント値が３以上である場合（ステップ１０７のＹＥＳ）、制御部１２は、パケットの送信パターンを測定する（ステップ１０８）。
【００６０】
ステップ１０１〜１０７に示す処理では、制御部１２は、送信側通信装置１と、受信側通信装置２との間の経路が広帯域及び高遅延（ＲＴＴが大きい）環境であるかを判定している。すなわち、上記経路が低帯域環境であったり、低遅延（ＲＴＴが小さい）環境であったりする場合、輻輳ウィンドウサイズは、受信ウィンドウサイズに達しない。一方、上記経路が広帯域及び高遅延環境である場合、輻輳ウィンドウサイズが受信ウィンドウサイズに達する。ステップ１０１〜１０７では、この関係を利用して、上記経路が広帯域及び高遅延環境であるかを判定している。そして、広帯域及び高遅延環境であると判定された場合、ＯＴＰＣに基づくパケットの拡大送信が実行される（図３、図６参照）。
【００６１】
「パケットの送信パターンの測定〜拡大送信」
図６は、パケットの送信パターンの測定から拡大送信までの処理を示すフローチャートである。
【００６２】
図６に示すように、制御部１２は、拡大送信に先立って、パケットの送信パターンを測定する（ステップ２０１）。そして、制御部１２は、測定された測定パターンに応じて、追加送信時刻及び追加送信量を決定する（ステップ２０２）。次に、制御部１２は、ステップ２０２で決定された追加送信時刻となったかを判定する（ステップ２０３）。追加送信時刻となった場合（ステップ２０３のＹＥＳ）、制御部１２は、ステップ２０２で決定された追加送信量分のパケットを送信する（ステップ２０４）。なお、ステップ２０４では、受信側通信装置２からの確認応答が受信されるタイミング以外のタイミングで、追加送信が実行される。以降では、ＯＴＰＣに基づく拡大送信が実行される（ステップ２０５）。
【００６３】
"パケットの送信停止期間の予測"
図６に示すステップ２０１では、送信パターンを測定することで、パケットの送信が停止される期間を予測している。図７は、パケット送信停止期間の予測について説明するための図であり、パケットの送信タイミングを示す図である。図７中、実線で表された三角形は、観測期間中に行われたパケットの送信タイミングを示しており、波線で表された三角形は、観測によって類推された、これから送信されるであろうパケットの送信タイミングを示している。また、図７中、逆三角形は、パケットの送信が停止されるであろうと予測される期間の中央を示している。
【００６４】
ここで、上記したように、通常送信中では、ａｃｋが受信されるタイミングで、送信ウィンドウをスライドさせて、パケットを送信している。ａｃｋは、送信側通信装置１によって以前に送信されたパケットが、受信装置に届いたことを示す確認信号である。したがって、基本的には、送信側受信装置からのパケットは、ＲＴＴごとに、似たパターンで送信されることになる。なお、セルフクロッキング等、様々な理由によって、多少ずれることがあるが、多少ずれたとしても、その後の送信パターンは、ＲＴＴごとに、定期的に似たようなパターンとなる。
【００６５】
したがって、制御部１２は、パケットの送信パターンを測定することで、パケットの送信が停止される期間を予測することができる。送信パターンの測定においては、典型的には、図７に示すように、１ＲＴＴ分のパケットの送信パターンを測定すれば、パケットの送信が停止される位置を予測することができる。この場合、送信パターンの測定の開始点及び終了点は、どのような位置であってもよい。
【００６６】
パケットの送信が停止される期間の予測により、送信側通信装置１は、受信側通信装置２に対して、適切なタイミングで、パケットを追加的に送信することができる。
【００６７】
"追加送信時刻及び追加送信量の決定"
図８及び図９は、追加送信時刻と、追加送信量とが決定される際の処理を説明するための図である。図８及び図９では、実線の三角形が既に送信されたパケットの送信タイミングを示しており、破線の三角形がこれから送信されるであろうパケットの送信タイミングを示している。
【００６８】
図８を参照して、送信タイミングの最大空き時間をＴとする。次回の予測最大空き時間Ｔの開始時刻Ｔstart及び終了時刻Ｔendは、前回の最大空き時間の開始時刻及び終了時刻をＲＴＴ分進めたポイントである。制御部１２は、パケットの送信パターンからこの予測最大空き時間Ｔを算出（予測）し、この時間Ｔに追加送信を実行する。ここで、制御部１２が、予測最大空き時間Ｔに何ら制限なくパケットを送信してしまうと、バーストが発生してしまう可能性がある。そこで、本実施形態では、送信側通信装置１は、予測最大空き時間Ｔに、パケットを分散して受信側通信装置２に送信することとしている。
【００６９】
図９を参照して、バースト対策として、制御部１２が１ｍｓ当たりに最大送信可能なパケット数をＡとする。パケット数を抑制して、パケットを送信した場合であっても、バーストが発生する可能性がある。そこで、制御部１２は、Ｓｍｓの間パケットを送信した場合、Ｐｍｓ以上パケットの送信を休止する処理を実行する。Ｐｍｓは、パケットの送信が最低限、休止される時間である。
【００７０】
制御部１２は、Ｔ＞ｎＳ＋（ｎ＋１）Ｐの条件を満たす最大のｎを求める。なお、図９に示す例では、ｎ＝３とされている。次に、制御部１２は、Ｐ’＝（Ｔ−ｎＳ）／（ｎ＋１）によって、Ｐ’を求める。Ｐ’は、予測最大空き時間Ｔにおいて、パケットの送信が実際に休止される時間である。制御部１２は、Ｐ’を求めると、Ｔstart＋Ｐ’により、最初に追加送信を実行すべき時刻を求める。制御部１２は、同様にして、送信の休止時刻及び再開時刻を求めることができる。制御部１２は、このようにして求められた追加送信時刻に、追加送信を実行する（図６、ステップ２０３、２０４参照）。
【００７１】
予測最大空き時間Ｔの間の追加送信量は、ｎＳＡにより決定される。制御部１２は、追加送信時間の間は、１ｍｓにＡ回、送信ウィンドウサイズ（輻輳ウィンドウサイズ）を１大きくし、その大きくした分だけ追加送信を実行する（図５（Ｂ）参照）。すなわち、制御部１２は、拡大送信中は、受信側通信装置２から通知された受信ウィンドウサイズよりも送信ウィンドウサイズを大きくして、パケットの追加送信を実行する。なお、以降の説明では、受信側通信装置２から通知された受信ウィンドウよりも拡大された送信ウィンドウサイズ（第２の送信ウィンドウサイズ）を仮想ウィンドウサイズ（ＶＲｗｎｄ）と呼ぶ場合がある。
【００７２】
図９に示したように、パケットを分散して送信することで、バースト送信を回避することができる。これにより、経路の途中でパケットが紛失してしまうことを防止することができる。
【００７３】
"確認応答（ａｃｋ）に対する、パケットのバースト送信の防止"
次に、確認応答（ａｃｋ）に対する、パケットのバースト送信の防止について説明する。
制御部１２は、確認応答に対するパケットの送信を実行している。確認応答がバーストして受信された場合（バーストａｃｋ）、確認応答に対するパケットの送信がバーストする場合がある。本発明者らが実際に試験を行った結果、受信側通信装置２が送信した確認応答（ａｃｋ）がバーストしていないにも関わらず、この確認応答がバーストして送信側通信装置１に受信される場合があった。そこで、送信側通信装置１の制御部１２は、バーストａｃｋに対して、バースト送信をしてしまわないようにパケットの送信を制御することとしている。
【００７４】
図１０は、バーストａｃｋに対するバースト送信を防止する際の処理を示すフローチャートである。図１１は、図１０に示す処理を説明するための補足図であり、記憶スロットに記憶される時刻の変化の様子を示す図である。
【００７５】
制御部１２は、ＯＴＰＣに基づく拡大送信中において（ステップ３０１）、確認応答（ａｃｋ）が受信されたかを判定する（ステップ３０２）。確認応答が受信された場合（ステップ３０２のＹＥＳ）、制御部１２は、記憶スロットの位置Ｐを１プラスする（ステップ３０３）。なお、制御部１２は、記憶スロットの位置Ｐを１プラスする前に、記憶スロットの位置Ｐが記憶スロットの位置Ｐが、記憶スロットの数Ｎ以上であるかを判定し、判定が肯定的である場合には、記憶スロットの位置Ｐを０としておく。図１１に示す例では、記憶スロットの数Ｎは、４とされている。
【００７６】
制御部１２は、記憶スロットの位置Ｐを１プラスすると、現在の時刻（Ｔ（Ｐ））を記憶スロットに記憶する（ステップ３０４）。例えば、図１１に示すように、ａｃｋ＃３６が受信された場合、制御部１２は、ａｃｋ＃３６の時刻を、ａｃｋ＃３２の時刻に上書きして記憶スロットに記憶する。
【００７７】
次に、制御部１２は、現在の時刻（Ｔ（Ｐ））と、Ｎ個前に記憶された時刻（Ｔ（Ｐ＋１））とを比較し、現在の時刻（Ｔ（Ｐ））と、Ｎ個前に記憶された時刻（Ｔ（Ｐ＋１））との差が、Ｌｍｓ（例えば、１０ｍｓ）未満であるかを判定する（ステップ３０５）。なお、図１１に示すように、現在の時刻（Ｔ（Ｐ））と、Ｎ個前に記憶された時刻（Ｔ（Ｐ＋１））との差は、Ｐ＝３の場合には、ａｃｋ＃３６の時刻と、ａｃｋ＃３３の時刻とを比較することで算出することができる。
【００７８】
現在の時刻（Ｔ（Ｐ））と、Ｎ個前に記憶された時刻（Ｔ（Ｐ＋１））との差が、Ｌｍｓ以上である場合（ステップ３０５のＮＯ）、そのまま、次のステップ３０７へ進む。
【００７９】
一方、現在の時刻（Ｔ（Ｐ））と、Ｎ（Ｎ＝４）個前に記憶された時刻（Ｔ（Ｐ＋１））との差が、Ｌｍｓよりも小さい場合（ステップ３０５のＹＥＳ）、輻輳ウィンドウサイズ（Ｃｗｎｄ）（送信ウィンドウサイズ）を１マイナスする。そして、次のステップ３０７へ進む。
【００８０】
ステップ３０７では、輻輳ウィンドウに空きがあるかを判定する。輻輳ウィンドウに空きがない場合（ステップ３０７のＮＯ）、ステップ３０１へ戻り、ステップ３０１以降の処理を実行する。一方、輻輳ウィンドウに空きがある場合（ステップ３０７のＮＯ）、確認応答に対してパケットを送信する（ステップ３０８）。
【００８１】
以上のような処理により、Ｌｍｓの時間内に、Ｎ個以上のパケットの送信が規制される。これにより、バーストａｃｋに対するバースト送信を防止することができる。
【００８２】
「拡大送信中におけるエラーからの復帰（１）」
次に、拡大送信中におけるエラーからの復帰について説明する。
通常のＴＣＰ技術では、受信側通信装置２は、順番通りにパケットが受信されず、後に受信されるはずのパケットが先に受信された場合、まだ前のパケットが受信されていていないことを送信側通信装置１に通知する方法が用いられている。この場合、受信側通信装置２は、前と同じ確認応答（ａｃｋ）を送信側通信装置１に返すことで、まだ前のパケットが受信されていないことを通知する。
【００８３】
ここで、ＯＴＰＣに基づく拡大送信中においてエラーが発生した場合のリカバリの問題について説明する。
【００８４】
図１２は、ＯＴＰＣに基づく拡大送信中においてエラーが発生した場合のリカバリの問題を説明するためのシーケンス図である。
【００８５】
送信側通信装置１（制御部１２）は、受信側通信装置２から受信ウィンドウサイズ（この例では、Ｒｗｎｄ＝３）が通知されると、通知された受信ウィンドウサイズに応じて、１〜３番目までのパケットを受信側通信装置２に送信する。受信側通信装置２は、１〜２番目のパケット、３番目のパケットが受信されると、ａｃｋ＝３、ａｃｋ＝４を送信側通信装置１に返す。
【００８６】
送信側通信装置１は、送信ウィンドウサイズを、受信側から受信された受信ウィンドウサイズを超える大きさとして、４〜６番目のパケットを送信する。なお、図１２に示す例では、送信ウィンドウサイズは、受信ウィンドウサイズの２倍とされている。
【００８７】
受信側通信装置２は、４〜５番目のパケット、６番目のパケットが受信されると、ａｃｋ＝６、ａｃｋ＝７を送信側通信装置１に返す。
【００８８】
送信側通信装置１は、受信側通信装置２からａｃｋ＝３、ａｃｋ＝４を受信すると、送信ウィンドウをスライドさせて、７〜８番目、９番目のパケットを受信側通信装置２に送信する。このとき、７番目のパケットがロストしたとする。受信側通信装置２は、７番目のパケットが受信される前に、８番目のパケットが受信されたので、前回と同じ確認応答（ａｃｋ＝７）を送信側通信装置１に返す。同様に、受信側通信装置２は、７番目のパケットが受信される前に、９番目のパケットが受信されたので、さらに、確認応答（ａｃｋ＝７）を送信側通信装置１に返す。
【００８９】
送信側通信装置１は、ａｃｋ＝６、（最初の）ａｃｋ＝７が受信されると、１０〜１１番目のパケット、１２番目のパケットを送信する。１０〜１２番目のパケットは、受信バッファに入りきらないので、受信バッファから溢れる。すなわち、本来の受信ウィンドウサイズを超えて送信したパケットは、受信バッファから溢れて、ロストする。
【００９０】
送信側通信装置１は、複数回、ａｃｋ＝７が受信された場合、７番目のパケットがロストしたと判断して、７番目のパケットを受信側通信装置２に再送する。受信側通信装置２は、７番目のパケットが受信されると、７〜９番目のパケットが正常に受信されたとして、ａｃｋ＝１０を送信側通信装置１に返す。
【００９１】
送信側通信装置１は、ａｃｋ＝１０が受信されると、１０番目のパケットを再送する。受信側通信装置２は、１０番目のパケットが受信されると、ａｃｋ＝１１を送信側通信装置１に返し、送信側通信装置１は、このａｃｋ＝１１により１１番目のパケットを再送する。同様の処理が１２番目のパケットが再送されるまで繰り返される。
【００９２】
すなわち、拡大送信において本来の受信ウィンドウサイズを超えて送信された１０番目〜１２番目のパケットは、送信側通信装置１においてロストパケットとして扱われてしまうので、１つずつの再送となる。これにより、エラーから復帰するまでに時間がかかってしまうという問題がある。そこで、送信側通信装置１は、素早くエラーから復帰する処理を実行する。
【００９３】
図１３は、送信側通信装置１が、素早くエラーから復帰する処理を示すシーケンス図である。図１３の説明では、送信側通信装置１が複数回、ａｃｋ＝７を受信したとことから説明する。なお、送信側通信装置１が複数回ａｃｋ＝７を受信するまでのシーケンスは、図１２と同様である。
【００９４】
送信側通信装置１は、複数回、ａｃｋ＝７が受信された場合、７番目のパケットがロストしたと判断して、７番目のパケットを受信側通信装置２に再送する。このとき、送信側通信装置１は、拡大されている送信ウィンドウサイズ（仮想ウィンドウサイズ）を、本来の受信ウィンドウサイズ（Ｒｗｎｄ＝３）へ戻す（第３のウィンドウサイズ）。そして、送信キューを修正して、本来の受信ウィンドウサイズを超えて既に送信済みのパケット（図１３の例では、１０〜１２番目のパケット）は、送信しなかったこととして扱う。
【００９５】
受信側通信装置２は、７番目のパケットが受信されると、７〜９番目のパケットが正常に受信されたとして、ａｃｋ＝１０を送信側通信装置１に返す。送信側通信装置１は、ａｃｋ＝１０を受信すると、１０〜１２番目のパケットを受信側通信装置２に対して送信する。
【００９６】
すなわち、送信側通信装置１は、本来の受信ウィンドウサイズを超えて送信したパケット（１０〜１２番目のパケット）は、送信しなかったとして扱うので、ロストパケットとして扱われない。したがって、本来の受信ウィンドウを超えて既に送信済みのパケット（１０〜１２番目のパケット）が１つずつ再送されるようなことがなくなるので、素早くエラーから復帰することができる。
【００９７】
エラーからの復帰が完了した場合、送信側通信装置１は、再び拡大送信を実行する。
【００９８】
「拡大送信中におけるエラーからの復帰（２）」
ここで、上記したように、送信側通信装置１の制御部１２は、エラーからの復帰時に送信ウィンドウサイズを、本来の受信ウィンドウサイズに戻し、本来の受信ウィンドウサイズを超えて送信したパケットは、送信しなかったとして扱う。
【００９９】
本来の受信ウィンドウサイズを超えて送信したパケットは、packets-to-rollback=（sent-packets）−（original-window-size）として求めることができる。
【０１００】
しかしながら、タイミングにより、本来の受信ウィンドウサイズを超えて送信されたパケットが、受信側送信装置の受信バッファに、数パケット収まる場合がある。
【０１０１】
ところで、ＴＣＰのＴＣＰヘッダ内には、オプションフィールドが用意されており、このオプションフィールドを利用することで、受信側通信装置２は、選択確認応答（ｓａｃｋ）を送信側通信装置１に返すことができる。選択確認応答（ｓａｃｋ）は、既に届いたパケットの番号の情報等を含む。送信側通信装置１は、確認応答（ａｃｋ）と、選択確認応答（ｓａｃｋ）とにより、どのパケットが紛失して、どのパケットが受信側通信装置２に届いているのかを認識することができる。
【０１０２】
本来の受信ウィンドウサイズを超えて送信されたパケットが、受信バッファに数パケット収まった場合、送信側では、送信しなかったとして扱っている領域を指定した選択確認応答（ｓａｃｋ）が、ｄｕｐ_ｓｕｃｋとして受信側通信装置２に受信されてしまう。この場合、送信側通信装置１は、送信しなかったとして扱っている領域を指定した選択確認応答（ｓａｃｋ）を不正であるとして無視してしまう（本当に不正である場合と区別できない）。また、本来の受信ウィンドウサイズを超えて送信されたパケットが、受信バッファに数パケット収まった場合、エラーからの復帰完了時に受信側通信装置２から送信される確認応答ａｃｋを不正であるとして無視してしまう（本当に不正である場合と区別できない）。これにより、エラーの復帰に時間がかかってしまうという問題がある。
【０１０３】
そこで、送信側通信装置１は、本来の受信ウィンドウサイズを超えて送信されたパケットが、受信バッファに数パケット収まったような場合でも、素早くエラーから復帰することができるような処理を実行する。以降では、これについて説明する。
【０１０４】
図１４及び図１５は、エラーから復帰（リカバリ）する際の処理を示すフローチャートである。
【０１０５】
図１４に示すように、ＯＴＰＣに基づく拡大送信中において（ステップ４０１）、制御部１２は、確認応答（ａｃｋ）が受信されたかを判定する（ステップ４０２）。確認応答（ａｃｋ）が受信された場合（ステップ４０２のＹＥＳ）、今回受信された確認応答（ａｃｋ）が、前回受信された確認応答と同じであるかを判定する（ステップ４０３）。
確認応答（ａｃｋ）が前回と異なる場合（ステップ４０３のＮＯ）、制御部１２は、カウンタによるカウント値（ｄｕｐｃｎｔ）をゼロとし（ステップ４０４）、ステップ４０１へ戻る。一方、確認応答（ａｃｋ）が前回と同じである場合（ステップ４０３のＹＥＳ）、制御部１２は、カウンタによるカウント値（ｄｕｐｃｎｔ）を１プラスする（ステップ４０５）。
【０１０６】
次に、制御部１２は、カウンタによるカウント値が３以上であるかを判定する（ステップ４０６）。カウント値が３未満の場合（ステップ４０６のＮＯ）、制御部１２は、ステップ４０１へ戻る。一方、カウント値が３以上である場合（ステップ４０６のＹＥＳ）、制御部１２は、拡大されている送信ウィンドウサイズ（仮想ウィンドウサイズ）を小さくする（ステップ４０７）（図５（Ｂ）→（Ｃ））。これにより、制御部１２は、第１のリカバリ状態に移行し（ステップ４０８）、ロストパケットの再送を実行する。
【０１０７】
送信ウィンドウサイズが変更されるとき、制御部１２は、送信ウィンドウサイズ（仮想ウィンドウサイズ）を本来の受信ウィンドウサイズへ戻さず、送信ウィンドウサイズを受信ウィンドウサイズよりもすこし大きいサイズへと変更する（第３の送信ウィンドウサイズ）。この場合、制御部１２は、packets-to-rollback=（sent-packets）−（original-window-size）−（rollback-margin）により、送信ウィンドウサイズを縮小するサイズを決定する。このとき、制御部１２は、受信ウィンドウサイズ＋marginを超えて既に送信済みのパケットは、送信しなかったものとして扱う（図５（Ｃ）斜線領域参照）。
【０１０８】
図１５を参照して、制御部１２は、第１のリカバリ中において（ステップ５０１）、確認応答（ａｃｋ）が受信されたかを判定する（ステップ５０２）。受信側通信装置２からの確認応答（ａｃｋ）が受信された場合（ステップ５０２のＹＥＳ）、制御部１２は、今回受信された選択確認応答（ｓａｃｋ）が前回受信された選択確認応答と同じであるかを判定する（ステップ５０３）。
【０１０９】
今回受信された選択確認応答（ｓａｃｋ）が前回受信された選択確認応答と異なる場合（ステップ５０３のＮＯ）、制御部１２は、カウンタのカウント値をゼロとし（ステップ５０４）、ステップ５０１へ戻る。一方、今回受信された選択確認応答（ｓａｃｋ）が前回受信された選択確認応答と同じ場合（ステップ５０３のＹＥＳ）、制御部１２は、カウンタのカウント値を１プラスする（ステップ５０５）。
【０１１０】
次に、制御部１２は、カウント値が３以上であるかを判定する（ステップ５０６）。カウント値が３未満の場合（ステップ５０６のＮＯ）、制御部１２は、ステップ５０１へ戻る。一方、カウント値が３以上の場合（ステップ５０４のＹＥＳ）、先ほど、縮小された送信ウィンドウサイズ（仮想ウィンドウサイズ）をさらに縮小して補正する（ステップ５０７）（図５（Ｃ）→図５（Ｄ））。このとき、制御部１２は、受信側通信装置２から繰り返し通知された選択確認応答（ｓａｃｋ）の位置まで送信ウィドウサイズを戻す。受信側通信装置２の受信バッファからパケットが溢れた場合、選択確認応答が同じ値を示し続けるようになるので、この性質が利用されている。なお、選択確認応答（ｓａｃｋ）の位置よりも右側に位置する既に送信済みのパケットは、送信されなかったものとして扱われる（図５（Ｄ）斜線領域参照）。
【０１１１】
送信ウィンドウサイズが補正されると、制御部１２は、第２のリカバリ状態に移行し（ステップ５０８）、ロストパケットの再送を実行する。そして、リカバリが完了すると、通常送信状態に移行する（ステップ５０９）。そして、制御部１２は、再び、拡大送信を実行する（図４、図６参照）。なお、制御部１２は、リカバリ完了時に、パケットのロストが発生した時点での仮想ウィンドウサイズまで高速に仮想ウィンドウサイズを拡大する処理を実行してもよい。この場合、制御部１２は、仮想ウィンドウサイズが縮小されたときに、もとの仮想ウィンドウサイズを記憶しておき、このもとの仮想ウィンドウサイズまで高速に仮想ウィンドウサイズを戻す処理を実行する。これにより、リカバリ完了後のスループットを向上させることができる。
【０１１２】
図１４、図１５に示す処理により、送信側通信装置１は、本来の受信ウィンドウサイズを超えて送信されたパケットが、受信バッファに数パケット収まったような場合でも、素早くエラーから復帰することができる。
【０１１３】
ここで、リカバリが頻繁に発生する場合があり得る。このような場合には、送信ウィンドウサイズを拡大して、拡大送信を実行してもパケットの再送の分だけ無駄になってしまう。そこで、通常送信を拡大送信に切り替える条件として、輻輳ウィンドウが受信ウィンドウに達したこと、受信ウィンドウが安定した状態となったことの他に（図４参照）、リカバリが頻発していないことを条件としてもよい。この場合、送信側通信装置１は、リカバリが発生する頻度を判定し、このリカバリが頻繁に起こっている場合には、通常送信から拡大送信への切り替えを規制する。
【０１１４】
また、制御部１２は、仮想ウィンドウサイズを、リカバリが発生する頻度に応じて、可変に制御してもよい。この場合、リカバリ頻度が大きい場合には、仮想ウィンドウサイズは、小さくなり、リカバリ頻度が小さい場合には、仮想ウィンドウサイズは、大きくなる。
【０１１５】
〈作用等〉
以上説明したように、本実実施形態では、広帯域及び高遅延環境である場合に、送信ウィンドウサイズが、受信ウィンドウサイズを超えるサイズ（第２のウィンドウサイズ）とされ、受信ウィンドウサイズを超えた送信量のパケットが送信される。これにより、広帯域及び高遅延環境下において、スループットを向上させることができる。
【０１１６】
また、本実施形態では、送信側通信装置１の改良だけでよく、受信側通信装置２の改良は必要ない。受信側通信装置２は、一般のＴＣＰスタックを用いた通常実装を備えていれば足りる。また、本実施形態では、通信経路に追加機器を設置する必要もない。したがって、コスト抑えた展開が可能である。
【符号の説明】
【０１１７】
１・・・送信側通信装置
２・・・送信側通信装置
１２・・・制御部
１００・・・通信システム
【技術分野】
【０００１】
本発明は、ＴＣＰ（Transmission Control Protocol）等の通信方式によって他の通信装置と通信する通信装置等の技術に関する。
【背景技術】
【０００２】
ＴＣＰは、現在、インターネットやイントラネット等で広く利用されている。ＴＣＰでは、データを受信側の通信装置が、データを送信する側の通信装置からパケットを受信した場合、受信側の通信装置は、送信側の通信装置に対して、確認応答（ａｃｋ：acknowledgement）を返すように構成されている。これにより、ＴＣＰでは、信頼性の高い通信を実現することができる。
【０００３】
ＴＣＰでは、スライドウィンドウ方式が採用されており、送信側の通信装置は、確認応答（ａｃｋ）が届く度にウィンドウをスライドさせるようにしてパケットを順番に受信側の送信装置へ送信する。
【０００４】
また、ＴＣＰでは、一般的にフロー制御と、輻輳制御が実行される。フロー制御では、受信側の通信装置が、送信側の通信装置に対して、最新の受信ウィンドウサイズを通知する。送信側の通信装置は、通知された受信ウィンドウサイズに応じた送信量のパケットを送信する。これにより、受信側の通信装置の受信バッファからパケットが溢れ出してしまうことを防止することができる。
【０００５】
一方、輻輳制御では、送信側の通信装置が、スロースタートアルゴリズム及び輻輳回避アルゴリズムに従って、輻輳ウィンドウサイズを制御することで、ネットワークの輻輳（混雑）を回避している。スロースタートアルゴリズムでは、最初に輻輳ウィンドウサイズが１ＭＳＳ（Maximum Segment Size）に設定され、徐々に輻輳ウィンドウサイズが大きくされる。輻輳回避アルゴリズムでは、パケットの紛失等や、ＲＴＴ（Round Trip Time）の変化から輻輳を検知し、輻輳ウィンドウサイズが調整される等の処理が実行される。なお、送信側の通信装置からパケットが送信される場合、輻輳ウィンドウサイズ及び受信ウィンドウのうち、小さいほうのウィンドウサイズに対応する送信量のパケットが送信される。
【０００６】
なお、ＴＣＰに関連する技術は、下記特許文献１、２等に記載されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００６−００５８３３号公報
【特許文献２】特開２００６−２７９７３０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ここで、送信側の通信装置と、受信側の通信装置との間の経路の帯域が広帯域であり、かつ、上記経路が長く、ＲＴＴが大きい（以下、高遅延と呼ぶ）場合を想定する。この場合、上記経路が広帯域環境であるので、輻輳ウィンドウサイズが受信ウィンドウサイズに達し、送信側の通信装置から送信されるパケットの送信量は、受信ウィンドウサイズによって決定される。すなわち、フロー制御が支配的な状態となる。上記経路が長く、ＲＴＴが大きい（高遅延）場合、実際には、受信側の送信装置の受信バッファが空いている期間が長いにも拘らず、送信側の通信装置は、フロー制御により、受信ウィンドウサイズに対応する送信量のデータしか送信することができない。すなわち、広帯域及び高遅延環境において、フロー制御による制限によって、スループットが上がらないといった問題がある。
【０００９】
以上のような事情に鑑み、本発明の目的は、広帯域及び高遅延環境において、スループットを向上させることができる通信装置等の技術を提供することにある。
【課題を解決するための手段】
【００１０】
上記目的を達成するため、本発明の一形態に係る通信装置は、通信部と、制御部とを具備する。
前記通信部は、受信側通信装置から受信ウィンドウサイズを受信し、かつ、送信ウィンドウサイズに応じた送信量のパケットを前記受信側通信装置に送信する。
前記制御部は、前記受信側通信装置との間の経路が広帯域及び高遅延環境であるか否かを判定し、広帯域及び高遅延環境であると判定された場合に、前記送信ウィンドウサイズが前記受信ウィンドウサイズを超えない第１のウィンドウサイズとされる第１の状態を、前記送信ウィンドウサイズが前記受信ウィンドウサイズを超える第２のウィンドウサイズとされる第２の状態へ切り替え、前記第２の状態で前記受信ウィンドウサイズを超えた送信量の前記パケットを送信する。
【００１１】
この通信装置では、広帯域及び高遅延環境である場合に、送信ウィンドウサイズが、受信ウィンドウサイズを超えるサイズ（第２のウィンドウサイズ）とされ、受信ウィンドウサイズを超えた送信量のパケットが送信される。これにより、広帯域及び高遅延環境下において、スループットを向上させることができる。
【００１２】
上記通信装置において、前記通信部は、前記通信部は、確認応答を前記受信側通信装置から受信してもよい。この場合、前記制御部は、前記確認応答が受信されるタイミングで前記パケットを前記送信部から送信させ、かつ、前記第２の状態で、前記確認応答の受信タイミングから前記パケットの送信が停止される期間を予測し、前記期間に前記パケットを追加的に前記送信部から送信させてもよい。
【００１３】
この通信装置では、受信側の通信装置に対して、適切なタイミングで、パケットを追加的に送信することができる。
【００１４】
上記通信装置において、前記制御部は、前記期間内に前記パケットを分散して前記送信部から送信させてもよい。
【００１５】
このように、パケットを分散して送信することで、バースト送信を回避することができる。これにより、経路の途中でパケットが紛失してしまうことを防止することができる。
【００１６】
上記通信装置において、前記制御部は、前記第２の状態で、前記確認応答が所定時間内に集中して受信されたかを判定し、前記確認応答が集中して受信された場合に、前記確認応答の受信タイミングに応じた前記パケットの送信を部分的に規制してもよい。
【００１７】
このように、前記確認応答が集中して受信された場合に、前記確認応答の受信タイミングに応じた前記パケットの送信を部分的に規制することで、バースト送信を回避することができる。これにより、経路の途中でパケットが紛失してしまうことを防止することができる。
【００１８】
上記通信装置において、前記制御部は、送信された前記パケットの前記経路上での紛失を検知し、前記第２の状態で前記パケットの紛失が検知された場合に、前記送信ウィンドウサイズが第２のウィンドウサイズとされる前記第２の状態を、前記ウィンドウサイズが前記第２のウィンドウサイズよりも小さい第３のウィンドウサイズとされる第３の状態へ切り替えてもよい。
【００１９】
これにより、紛失したパケットを適切に再送することができる。
【００２０】
上記通信装置において、前記制御部は、前記第２の状態が前記第３の状態に切り替えられた場合に、第３のウィンドウサイズを超えて既に送信済みのパケットは、送信しなかったとして扱ってもよい。
【００２１】
このように、第３のウィンドウサイズを超えて既に送信済みのパケットを、送信しなかったとして扱うことで、パケット紛失によるエラーから速やかに回復することができる。
【００２２】
上記送信装置において、前記第３のウィンドウサイズは、前記受信ウィンドウサイズよりも大きくてもよい。
【００２３】
このように、第３のウィンサイズを受信ウィンドウサイズよりも大きくすることで、パケット紛失によるエラーからの回復がさらに速くなる。
【００２４】
上記通信部において、前記通信部は、選択確認応答を前記受信側通信装置から受信し、前記制御部は、前記選択確認応答に基づいて、前記第３のウィンドウサイズの大きさを補正してもよい。
【００２５】
これにより、パケット紛失によるエラーからの回復がさらに速くなる。
【００２６】
上記通信装置において、前記制御部は、前記第２の状態が前記第３の状態へ切り替えられる頻度を判定し、前記頻度が所定の閾値よりも大きい場合には、前記第２の状態での前記受信ウィンドウサイズを超えた送信量の前記パケットの送信を規制してもよい。
【００２７】
これにより、パケット紛失による再送が頻発する場合には、受信ウィンドウサイズを超えたパケットの送信が規制される。
【００２８】
上記通信装置において、前記制御部は、前記第２の状態が前記第３の状態へ切り替えられる頻度に応じて、前記第２のウィンドウサイズを可変に制御してもよい。
【００２９】
これにより、例えば、パケットの再送が頻繁に起きる場合には、第２のウィンドウサイズを大きくし、パケットの再送が頻繁に起こらないようであれば、第２のウィンドウサイズを小さくする等、第２のウィンドウサイズを適切に変化させることができる。
【００３０】
本発明の一形態に係る通信システムは、受信側通信装置と、送信側通信装置とを具備する。
前記送信側通信装置は、通信部と、制御部とを有する。
前記通信部は、前記受信側通信装置から受信ウィンドウサイズを受信し、かつ、送信ウィンドウサイズに応じた送信量のパケットを前記受信側通信装置に送信する。
前記制御部は、前記受信側通信装置との間の経路が広帯域及び高遅延環境であるか否かを判定し、広帯域及び高遅延環境であると判定された場合に、前記送信ウィンドウサイズが前記受信ウィンドウサイズ超えない第１のウィンドウサイズとされる第１の状態を、前記送信ウィンドウサイズが前記受信ウィンドウサイズを超える第２のウィンドウサイズとされる第２の状態へ切り替え、前記第２の状態で前記受信ウィンドウサイズを超えた送信量の前記パケットを送信する。
【００３１】
本発明の一形態に係るプログラムは、通信装置に、受信側通信装置から受信ウィンドウサイズを受信するステップを実行させる。
送信ウィンドウサイズに応じた送信量のパケットを受信側通信装置に送信するステップを実行させる。
前記受信側通信装置との間の経路が広帯域及び高遅延環境であるか否かを判定するステップを実行させる。
広帯域及び高遅延環境であると判定された場合に、前記送信ウィンドウサイズが前記受信ウィンドウサイズを超えない第１のウィンドウサイズとされる第１の状態を、前記送信ウィンドウサイズが前記受信ウィンドウサイズを超える第２のウィンドウサイズとされる第２の状態へ切り替えるステップを実行させる。
前記第２の状態で前記受信ウィンドウサイズを超えた送信量の前記パケットを送信するステップを実行させる。
【００３２】
本発明の一形態に係る通信方法は、受信側通信装置から受信ウィンドウサイズを受信することを含む。
送信ウィンドウサイズに応じた送信量のパケットを受信側通信装置が送信される。
前記受信側通信装置との間の経路が広帯域及び高遅延環境であるか否かが判定される。
広帯域及び高遅延環境であると判定された場合に、前記送信ウィンドウサイズが前記受信ウィンドウサイズを超えない第１のウィンドウサイズとされる第１の状態が、前記送信ウィンドウサイズが前記受信ウィンドウサイズを超える第２のウィンドウサイズとされる第２の状態へ切り替えられる。
前記第２の状態で前記受信ウィンドウサイズを超えた送信量の前記パケットが送信される。
【発明の効果】
【００３３】
以上説明したように、本発明の一形態によれば、広帯域及び高遅延環境において、スループットを向上させることができる通信装置等の技術を提供することができる。
【図面の簡単な説明】
【００３４】
【図１】本発明の一実施形態に係る通信システムを示す図である。
【図２】ＯＴＣＰの基本的な考え方を説明するための図である。
【図３】ＯＴＣＰの基本的な考え方を説明するための図である。
【図４】ＴＣＰに基づく通常送信と、ＯＴＰＣに基づく拡大送信の切りかえるときの動作を示すフローチャートである。
【図５】通常送信中、拡大送信中などの各状態における、送信ウィンドウサイズ（輻輳ウィンドウサイズ）を示す図である。
【図６】パケットの送信パターンの測定から拡大送信までの処理を示すフローチャートである。
【図７】パケット送信停止期間の予測について説明するための図であり、パケットの送信タイミングを示す図である。
【図８】追加送信時刻と、追加送信量とが決定される際の処理を説明するための図である。
【図９】追加送信時刻と、追加送信量とが決定される際の処理を説明するための図である。
【図１０】バーストａｃｋに対するバースト送信を防止する際の処理を示すフローチャートである。
【図１１】図１０に示す処理を説明するための補足図であり、記憶スロットに記憶される時刻の変化の様子を示す図である。
【図１２】ＯＴＰＣに基づく拡大送信中においてエラーが発生した場合のリカバリの問題を説明するためのシーケンス図である。
【図１３】送信側通信装置が、素早くエラーから復帰する処理を示すシーケンス図である。
【図１４】エラーから復帰（リカバリ）する際の処理を示すフローチャートである。
【図１５】エラーから復帰（リカバリ）する際の処理を示すフローチャートである。
【発明を実施するための形態】
【００３５】
＜通信システム及び通信装置の構成＞
以下、図面を参照しながら、本発明の実施形態を説明する。図１は、本実施形態に係る通信システム１００を示す図である。
【００３６】
図１に示すように、通信システム１００は、相互にネットワークを介して接続された送信側通信装置１及び受信側通信装置２を有する。送信側通信装置１は、データを送信する側の通信装置であり、受信側通信装置２は、データを受信する側の通信装置である。通信装置１、２としては、例えば、サーバ、ＰＣ（Personal Computer）、携帯電話機などが挙げられるがこれらに限られない。
【００３７】
送信側通信装置１は、通信部１１と、制御部１２と、記憶部１３とを有する。同様に、受信側通信部１１も、通信部２１と、制御部２２と、記憶部２３とを有する。制御部１２、２２は、例えば、ＣＰＵであり、通信装置１、２の各部を統括的に制御する。記憶部１３、２３は、通信装置１、２の制御に必要な各種のプログラムや、各種のデータを記憶するＨＤＤ（Hard Disc Drive）、ＳＳＤ（Solid State Drive）等を含む。また、記憶部１３、２３は、制御部１２の作業領域として用いられる不揮発性のメモリ（例えば、ＲＡＭ（Random Access Memory））を含む。
【００３８】
送信側通信装置１の通信部１１は、送信すべきデータ等を含むパケットを受信側通信装置２に送信したり、受信側通信装置２からパケットを受信したりする。受信側通信装置２の通信部１１は、送信側通信装置１から送信されたパケットを受信したり、確認応答（ａｃｋ：acknowledgement）等の情報を含むパケットを送信側通信装置１に送信したりする。
【００３９】
＜動作説明＞
次に、本実施形態に係る通信システム１００の動作について説明する。
本実施形態に係る通信システム１００では、通常のＴＣＰに従って、パケットの通常送信が実行される第１の状態と、本実施形態の特徴に係るＯＴＣＰ（Optimistic TCP：楽観的ＴＣＰ）に従って、パケットの拡大送信が実行される第２の状態とを有している。
【００４０】
［通常のＴＣＰに従う場合の動作］
まず、通信システム１００が、通常のＴＣＰに従って通信する場合について説明する。まず、通信システム１００は、３ウェイハンドシェイクにより、ＴＣＰコネクションを確立する。３ウェイハンドシェイクでは、ＭＳＳ（Maximum Segment Size）が決定される。送信側通信装置１から送信されるデータがＭＳＳを超える場合、送信側においてデータが複数のパケットに分割される。
【００４１】
通信システム１００では、スライドウィンドウ方式が採用されており、送信側通信装置１は、確認応答（ａｃｋ）が届く度に送信ウィンドウをスライドさせるようにしてパケットを順番に受信側の送信装置へ送信する。
【００４２】
また、通信システム１００では、フロー制御と、輻輳制御とが実行される。フロー制御では、受信側通信装置２は、確認応答（ａｃｋ）を送信する際に、受信ウィンドウサイズ（Ｒｗｎｄ）を送信側通信装置１に通知する。この場合、受信側通信装置２は、ＴＣＰヘッダの中に存在する受信ウィンドウサイズのフィールドに現在の受信ウィンドウサイズを入れて、送信側通信装置１に送信する。送信ウィンドウサイズは、受信ウィンドウサイズを超えない大きさとされ、これにより、送信側から送信されたパケットが受信装置の受信バッファから溢れ出してしまうことが防止される。
【００４３】
輻輳制御では、送信側通信装置１には、輻輳ウィンドウが設定され、送信側通信装置１は、例えば、スロースタートアルゴリズムや、輻輳回避アルゴリズム等に従って、輻輳ウィンドウサイズ（Ｃｗｎｄ）を制御する。スロースタートアルゴリズムでは、最初に輻輳ウィンドウサイズが１ＭＳＳ（Maximum Segment Size）に設定され、徐々に輻輳ウィンドウサイズが大きくされる。輻輳回避アルゴリズムでは、パケットの紛失等や、ＲＴＴ（Round Trip Time）の変化から輻輳を検知し、輻輳ウィンドウサイズが調整される等の処理が実行される。
【００４４】
なお、送信装置から送信されるパケットの送信量は、輻輳ウィンドウサイズ及び受信ウィンドウのうち、小さいほうのウィンドウサイズに対応する送信量とされる。
【００４５】
［ＯＴＰＣの動作］
次に、ＯＴＣＰ（楽観的ＴＣＰ）について説明する。
まず、ＯＴＣＰの基本的な考え方について説明する。図２、図３は、ＯＴＣＰの基本的な考え方を説明するための図である。なお、図２、３では、理解を容易にするために、受信ウィンドウサイズ（Ｒｗｎｄ）や、受信バッファサイズ等は、実際のサイズよりも小さく設定されている。
【００４６】
図２に示すように、送信側通信装置１は、受信側通信装置２から受信ウィンドウサイズ（この例では、Ｒｗｎｄ＝３）が通知されると、通知された受信ウィンドウサイズに応じて、１〜３番目までのパケットを受信側通信装置２に送信する。受信側通信装置２は、１〜３番目のパケットを受信バッファに記憶し、アプリケーションプログラムは、受信バッファに記憶された１〜３番目のパケットを受信バッファから引き抜く。
【００４７】
受信側通信装置２は、１番目のパケットが受信されると、ａｃｋ＝２の確認応答を送信側通信装置１に送信し、２〜３番目のパケットが受信されると、ａｃｋ＝４の確認応答を送信側通信装置１に送信する。送信側通信装置１は、ａｃｋ＝２の確認応答が受信されると、送信ウィンドウをスライドさせて、４番目のパケットを送信し、ａｃｋ＝４が受信されると、５〜６番目のパケットを送信する。
【００４８】
受信側通信装置２は、４〜５番目のパケットを受信バッファに記憶し、アプリケーションプログラムは、受信バッファに記憶された４〜５番目のパケットを受信バッファから引き抜く。
【００４９】
図２の右側において破線で示す期間がＲＲＴと略等しい期間となる。ここで、例えば、送信側通信装置１と、受信側通信装置２との距離が離れている（例えば、日本−ＵＳ）等の理由により、ＲＴＴが大きく、高遅延環境である場合を想定する。このように、ＲＴＴが大きく、高遅延環境である場合、受信側通信装置２の受信バッファが空いている期間が大きい。
【００５０】
図３を参照して、受信バッファが空いているならば、送信装置側から追加的にパケットを送信しても届くので、ＯＴＰＣでは、受信バッファが空いている期間に、追加的にパケットを送信することとしている（７〜９番目のパケット参照）。
【００５１】
図３に示す動作について、送信側通信装置１を基準にして簡単に説明する。送信側通信装置１は、受信ウィンドウサイズ（Ｒｗｎｄ＝３）が通知されると、通知された受信ウィンドウサイズに応じて、１〜３番目までのパケットを受信側通信装置２に送信する。送信側通信装置１は、ａｃｋ＝４の確認応答を受信すると、４〜６番目のパケットを送信する。送信側通信装置１は、ａｃｋ＝７が受信される前に、７〜９番目のパケットを追加的に送信する。このとき、受信バッファは、空いている状態であるので、追加的に送信された７〜９番目のパケットは、受信側通信装置２に届く。
【００５２】
「ＴＣＰに基づく通常送信と、ＯＴＰＣに基づく拡大送信との切り替え」
次に、送信側通信装置１の処理について、具体的に説明する。まず、ＴＣＰに基づく通常送信と、ＯＴＰＣに基づく拡大送信の切り替えについて説明する。
【００５３】
図４は、そのときの送信側通信装置１の処理を示すフローチャートである。図５は、通常送信中、拡大送信中などの各状態における、送信ウィンドウサイズ（輻輳ウィンドウサイズ）を示す図である。
【００５４】
ステップ１０１では、送信側通信装置１の制御部１２は、通常のＴＣＰに基づいて、通常送信を実行している。この通常のＴＣＰに基づく通常送信については、上記した通りである。なお、図５（Ａ）に示すように、通常送信中では、送信ウィドウサイズ（第１の送信ウィンドウサイズ）（ｓｎｄ＿ｕｎａ〜ｓｎｄ＿ｕｎａ）は、受信ウィンドウサイズよりも小さく設定されている。
【００５５】
ステップ１０２では、制御部１２は、受信側通信装置２から送信された確認応答（ａｃｋ）が受信されたか否かを判定する。確認応答（ａｃｋ）が受信された場合（ステップ１０２のＹＥＳ）、制御部１２は、輻輳ウィンドウサイズ（Ｃｗｎｄ）が、受信ウィンドウサイズ（Ｒｗｎｄ）以上であるかを判定する（ステップ１０３）。受信ウィンドウサイズは、確認応答と共にパケットにて受信側通信装置２から通知される。
【００５６】
輻輳ウィンドウサイズが受信ウィンドウサイズ未満の場合（ステップ１０３のＮＯ）、ステップ１０４へ進む。ステップ１０４では、制御部１２は、前回ａｃｋ受信時の受信ウィンドウサイズ（ＰｒｅＲｗｎｄ）を、今回受信した受信ウィンドウサイズ（Ｒｗｎｄ）とし、カウンタによるカウント値（Ｃｎｔ）をゼロとする。そして、ステップ１０１へ戻る。
【００５７】
輻輳ウィンドウサイズが受信ウィドウサイズ以上である場合（ステップ１０３のＹＥＳ）、制御部１２は、今回受信された受信ウィンドウサイズ（Ｒｗｎｄ）が、前回ａｃｋ受信時の受信ウィンドウサイズ（ＰｒｅＲｗｎｄ）と等しいかを判定する（ステップ１０５）。今回の受信ウィンドウサイズが、前回の受信ウィンドウサイズと等しくない場合（ステップ１０５のＮＯ）、制御部１２は、ステップ１０４へ進む。そして、前回の受信ウィンドウサイズ（ＰｒｅＲｗｎｄ）を、今回の受信ウィンドウサイズ（Ｒｗｎｄ）をとし、カウンタによるカウント値（Ｃｎｔ）をゼロとする。そして、ステップ１０１へ戻る。
【００５８】
今回の受信ウィンドウサイズが、前回の受信ウィンドウサイズと等しい場合（ステップ１０５のＹＥＳ）、制御部１２は、カウンタによるカウント値を１プラスする（ステップ１０６）。次に、制御部１２は、カウント値が３以上であるかを判定する（ステップ１０７）。カウント値が３未満である場合（ステップ１０７のＮＯ）、制御部１２は、ステップ１０１へ戻る。
【００５９】
一方、カウント値が３以上である場合（ステップ１０７のＹＥＳ）、制御部１２は、パケットの送信パターンを測定する（ステップ１０８）。
【００６０】
ステップ１０１〜１０７に示す処理では、制御部１２は、送信側通信装置１と、受信側通信装置２との間の経路が広帯域及び高遅延（ＲＴＴが大きい）環境であるかを判定している。すなわち、上記経路が低帯域環境であったり、低遅延（ＲＴＴが小さい）環境であったりする場合、輻輳ウィンドウサイズは、受信ウィンドウサイズに達しない。一方、上記経路が広帯域及び高遅延環境である場合、輻輳ウィンドウサイズが受信ウィンドウサイズに達する。ステップ１０１〜１０７では、この関係を利用して、上記経路が広帯域及び高遅延環境であるかを判定している。そして、広帯域及び高遅延環境であると判定された場合、ＯＴＰＣに基づくパケットの拡大送信が実行される（図３、図６参照）。
【００６１】
「パケットの送信パターンの測定〜拡大送信」
図６は、パケットの送信パターンの測定から拡大送信までの処理を示すフローチャートである。
【００６２】
図６に示すように、制御部１２は、拡大送信に先立って、パケットの送信パターンを測定する（ステップ２０１）。そして、制御部１２は、測定された測定パターンに応じて、追加送信時刻及び追加送信量を決定する（ステップ２０２）。次に、制御部１２は、ステップ２０２で決定された追加送信時刻となったかを判定する（ステップ２０３）。追加送信時刻となった場合（ステップ２０３のＹＥＳ）、制御部１２は、ステップ２０２で決定された追加送信量分のパケットを送信する（ステップ２０４）。なお、ステップ２０４では、受信側通信装置２からの確認応答が受信されるタイミング以外のタイミングで、追加送信が実行される。以降では、ＯＴＰＣに基づく拡大送信が実行される（ステップ２０５）。
【００６３】
"パケットの送信停止期間の予測"
図６に示すステップ２０１では、送信パターンを測定することで、パケットの送信が停止される期間を予測している。図７は、パケット送信停止期間の予測について説明するための図であり、パケットの送信タイミングを示す図である。図７中、実線で表された三角形は、観測期間中に行われたパケットの送信タイミングを示しており、波線で表された三角形は、観測によって類推された、これから送信されるであろうパケットの送信タイミングを示している。また、図７中、逆三角形は、パケットの送信が停止されるであろうと予測される期間の中央を示している。
【００６４】
ここで、上記したように、通常送信中では、ａｃｋが受信されるタイミングで、送信ウィンドウをスライドさせて、パケットを送信している。ａｃｋは、送信側通信装置１によって以前に送信されたパケットが、受信装置に届いたことを示す確認信号である。したがって、基本的には、送信側受信装置からのパケットは、ＲＴＴごとに、似たパターンで送信されることになる。なお、セルフクロッキング等、様々な理由によって、多少ずれることがあるが、多少ずれたとしても、その後の送信パターンは、ＲＴＴごとに、定期的に似たようなパターンとなる。
【００６５】
したがって、制御部１２は、パケットの送信パターンを測定することで、パケットの送信が停止される期間を予測することができる。送信パターンの測定においては、典型的には、図７に示すように、１ＲＴＴ分のパケットの送信パターンを測定すれば、パケットの送信が停止される位置を予測することができる。この場合、送信パターンの測定の開始点及び終了点は、どのような位置であってもよい。
【００６６】
パケットの送信が停止される期間の予測により、送信側通信装置１は、受信側通信装置２に対して、適切なタイミングで、パケットを追加的に送信することができる。
【００６７】
"追加送信時刻及び追加送信量の決定"
図８及び図９は、追加送信時刻と、追加送信量とが決定される際の処理を説明するための図である。図８及び図９では、実線の三角形が既に送信されたパケットの送信タイミングを示しており、破線の三角形がこれから送信されるであろうパケットの送信タイミングを示している。
【００６８】
図８を参照して、送信タイミングの最大空き時間をＴとする。次回の予測最大空き時間Ｔの開始時刻Ｔstart及び終了時刻Ｔendは、前回の最大空き時間の開始時刻及び終了時刻をＲＴＴ分進めたポイントである。制御部１２は、パケットの送信パターンからこの予測最大空き時間Ｔを算出（予測）し、この時間Ｔに追加送信を実行する。ここで、制御部１２が、予測最大空き時間Ｔに何ら制限なくパケットを送信してしまうと、バーストが発生してしまう可能性がある。そこで、本実施形態では、送信側通信装置１は、予測最大空き時間Ｔに、パケットを分散して受信側通信装置２に送信することとしている。
【００６９】
図９を参照して、バースト対策として、制御部１２が１ｍｓ当たりに最大送信可能なパケット数をＡとする。パケット数を抑制して、パケットを送信した場合であっても、バーストが発生する可能性がある。そこで、制御部１２は、Ｓｍｓの間パケットを送信した場合、Ｐｍｓ以上パケットの送信を休止する処理を実行する。Ｐｍｓは、パケットの送信が最低限、休止される時間である。
【００７０】
制御部１２は、Ｔ＞ｎＳ＋（ｎ＋１）Ｐの条件を満たす最大のｎを求める。なお、図９に示す例では、ｎ＝３とされている。次に、制御部１２は、Ｐ’＝（Ｔ−ｎＳ）／（ｎ＋１）によって、Ｐ’を求める。Ｐ’は、予測最大空き時間Ｔにおいて、パケットの送信が実際に休止される時間である。制御部１２は、Ｐ’を求めると、Ｔstart＋Ｐ’により、最初に追加送信を実行すべき時刻を求める。制御部１２は、同様にして、送信の休止時刻及び再開時刻を求めることができる。制御部１２は、このようにして求められた追加送信時刻に、追加送信を実行する（図６、ステップ２０３、２０４参照）。
【００７１】
予測最大空き時間Ｔの間の追加送信量は、ｎＳＡにより決定される。制御部１２は、追加送信時間の間は、１ｍｓにＡ回、送信ウィンドウサイズ（輻輳ウィンドウサイズ）を１大きくし、その大きくした分だけ追加送信を実行する（図５（Ｂ）参照）。すなわち、制御部１２は、拡大送信中は、受信側通信装置２から通知された受信ウィンドウサイズよりも送信ウィンドウサイズを大きくして、パケットの追加送信を実行する。なお、以降の説明では、受信側通信装置２から通知された受信ウィンドウよりも拡大された送信ウィンドウサイズ（第２の送信ウィンドウサイズ）を仮想ウィンドウサイズ（ＶＲｗｎｄ）と呼ぶ場合がある。
【００７２】
図９に示したように、パケットを分散して送信することで、バースト送信を回避することができる。これにより、経路の途中でパケットが紛失してしまうことを防止することができる。
【００７３】
"確認応答（ａｃｋ）に対する、パケットのバースト送信の防止"
次に、確認応答（ａｃｋ）に対する、パケットのバースト送信の防止について説明する。
制御部１２は、確認応答に対するパケットの送信を実行している。確認応答がバーストして受信された場合（バーストａｃｋ）、確認応答に対するパケットの送信がバーストする場合がある。本発明者らが実際に試験を行った結果、受信側通信装置２が送信した確認応答（ａｃｋ）がバーストしていないにも関わらず、この確認応答がバーストして送信側通信装置１に受信される場合があった。そこで、送信側通信装置１の制御部１２は、バーストａｃｋに対して、バースト送信をしてしまわないようにパケットの送信を制御することとしている。
【００７４】
図１０は、バーストａｃｋに対するバースト送信を防止する際の処理を示すフローチャートである。図１１は、図１０に示す処理を説明するための補足図であり、記憶スロットに記憶される時刻の変化の様子を示す図である。
【００７５】
制御部１２は、ＯＴＰＣに基づく拡大送信中において（ステップ３０１）、確認応答（ａｃｋ）が受信されたかを判定する（ステップ３０２）。確認応答が受信された場合（ステップ３０２のＹＥＳ）、制御部１２は、記憶スロットの位置Ｐを１プラスする（ステップ３０３）。なお、制御部１２は、記憶スロットの位置Ｐを１プラスする前に、記憶スロットの位置Ｐが記憶スロットの位置Ｐが、記憶スロットの数Ｎ以上であるかを判定し、判定が肯定的である場合には、記憶スロットの位置Ｐを０としておく。図１１に示す例では、記憶スロットの数Ｎは、４とされている。
【００７６】
制御部１２は、記憶スロットの位置Ｐを１プラスすると、現在の時刻（Ｔ（Ｐ））を記憶スロットに記憶する（ステップ３０４）。例えば、図１１に示すように、ａｃｋ＃３６が受信された場合、制御部１２は、ａｃｋ＃３６の時刻を、ａｃｋ＃３２の時刻に上書きして記憶スロットに記憶する。
【００７７】
次に、制御部１２は、現在の時刻（Ｔ（Ｐ））と、Ｎ個前に記憶された時刻（Ｔ（Ｐ＋１））とを比較し、現在の時刻（Ｔ（Ｐ））と、Ｎ個前に記憶された時刻（Ｔ（Ｐ＋１））との差が、Ｌｍｓ（例えば、１０ｍｓ）未満であるかを判定する（ステップ３０５）。なお、図１１に示すように、現在の時刻（Ｔ（Ｐ））と、Ｎ個前に記憶された時刻（Ｔ（Ｐ＋１））との差は、Ｐ＝３の場合には、ａｃｋ＃３６の時刻と、ａｃｋ＃３３の時刻とを比較することで算出することができる。
【００７８】
現在の時刻（Ｔ（Ｐ））と、Ｎ個前に記憶された時刻（Ｔ（Ｐ＋１））との差が、Ｌｍｓ以上である場合（ステップ３０５のＮＯ）、そのまま、次のステップ３０７へ進む。
【００７９】
一方、現在の時刻（Ｔ（Ｐ））と、Ｎ（Ｎ＝４）個前に記憶された時刻（Ｔ（Ｐ＋１））との差が、Ｌｍｓよりも小さい場合（ステップ３０５のＹＥＳ）、輻輳ウィンドウサイズ（Ｃｗｎｄ）（送信ウィンドウサイズ）を１マイナスする。そして、次のステップ３０７へ進む。
【００８０】
ステップ３０７では、輻輳ウィンドウに空きがあるかを判定する。輻輳ウィンドウに空きがない場合（ステップ３０７のＮＯ）、ステップ３０１へ戻り、ステップ３０１以降の処理を実行する。一方、輻輳ウィンドウに空きがある場合（ステップ３０７のＮＯ）、確認応答に対してパケットを送信する（ステップ３０８）。
【００８１】
以上のような処理により、Ｌｍｓの時間内に、Ｎ個以上のパケットの送信が規制される。これにより、バーストａｃｋに対するバースト送信を防止することができる。
【００８２】
「拡大送信中におけるエラーからの復帰（１）」
次に、拡大送信中におけるエラーからの復帰について説明する。
通常のＴＣＰ技術では、受信側通信装置２は、順番通りにパケットが受信されず、後に受信されるはずのパケットが先に受信された場合、まだ前のパケットが受信されていていないことを送信側通信装置１に通知する方法が用いられている。この場合、受信側通信装置２は、前と同じ確認応答（ａｃｋ）を送信側通信装置１に返すことで、まだ前のパケットが受信されていないことを通知する。
【００８３】
ここで、ＯＴＰＣに基づく拡大送信中においてエラーが発生した場合のリカバリの問題について説明する。
【００８４】
図１２は、ＯＴＰＣに基づく拡大送信中においてエラーが発生した場合のリカバリの問題を説明するためのシーケンス図である。
【００８５】
送信側通信装置１（制御部１２）は、受信側通信装置２から受信ウィンドウサイズ（この例では、Ｒｗｎｄ＝３）が通知されると、通知された受信ウィンドウサイズに応じて、１〜３番目までのパケットを受信側通信装置２に送信する。受信側通信装置２は、１〜２番目のパケット、３番目のパケットが受信されると、ａｃｋ＝３、ａｃｋ＝４を送信側通信装置１に返す。
【００８６】
送信側通信装置１は、送信ウィンドウサイズを、受信側から受信された受信ウィンドウサイズを超える大きさとして、４〜６番目のパケットを送信する。なお、図１２に示す例では、送信ウィンドウサイズは、受信ウィンドウサイズの２倍とされている。
【００８７】
受信側通信装置２は、４〜５番目のパケット、６番目のパケットが受信されると、ａｃｋ＝６、ａｃｋ＝７を送信側通信装置１に返す。
【００８８】
送信側通信装置１は、受信側通信装置２からａｃｋ＝３、ａｃｋ＝４を受信すると、送信ウィンドウをスライドさせて、７〜８番目、９番目のパケットを受信側通信装置２に送信する。このとき、７番目のパケットがロストしたとする。受信側通信装置２は、７番目のパケットが受信される前に、８番目のパケットが受信されたので、前回と同じ確認応答（ａｃｋ＝７）を送信側通信装置１に返す。同様に、受信側通信装置２は、７番目のパケットが受信される前に、９番目のパケットが受信されたので、さらに、確認応答（ａｃｋ＝７）を送信側通信装置１に返す。
【００８９】
送信側通信装置１は、ａｃｋ＝６、（最初の）ａｃｋ＝７が受信されると、１０〜１１番目のパケット、１２番目のパケットを送信する。１０〜１２番目のパケットは、受信バッファに入りきらないので、受信バッファから溢れる。すなわち、本来の受信ウィンドウサイズを超えて送信したパケットは、受信バッファから溢れて、ロストする。
【００９０】
送信側通信装置１は、複数回、ａｃｋ＝７が受信された場合、７番目のパケットがロストしたと判断して、７番目のパケットを受信側通信装置２に再送する。受信側通信装置２は、７番目のパケットが受信されると、７〜９番目のパケットが正常に受信されたとして、ａｃｋ＝１０を送信側通信装置１に返す。
【００９１】
送信側通信装置１は、ａｃｋ＝１０が受信されると、１０番目のパケットを再送する。受信側通信装置２は、１０番目のパケットが受信されると、ａｃｋ＝１１を送信側通信装置１に返し、送信側通信装置１は、このａｃｋ＝１１により１１番目のパケットを再送する。同様の処理が１２番目のパケットが再送されるまで繰り返される。
【００９２】
すなわち、拡大送信において本来の受信ウィンドウサイズを超えて送信された１０番目〜１２番目のパケットは、送信側通信装置１においてロストパケットとして扱われてしまうので、１つずつの再送となる。これにより、エラーから復帰するまでに時間がかかってしまうという問題がある。そこで、送信側通信装置１は、素早くエラーから復帰する処理を実行する。
【００９３】
図１３は、送信側通信装置１が、素早くエラーから復帰する処理を示すシーケンス図である。図１３の説明では、送信側通信装置１が複数回、ａｃｋ＝７を受信したとことから説明する。なお、送信側通信装置１が複数回ａｃｋ＝７を受信するまでのシーケンスは、図１２と同様である。
【００９４】
送信側通信装置１は、複数回、ａｃｋ＝７が受信された場合、７番目のパケットがロストしたと判断して、７番目のパケットを受信側通信装置２に再送する。このとき、送信側通信装置１は、拡大されている送信ウィンドウサイズ（仮想ウィンドウサイズ）を、本来の受信ウィンドウサイズ（Ｒｗｎｄ＝３）へ戻す（第３のウィンドウサイズ）。そして、送信キューを修正して、本来の受信ウィンドウサイズを超えて既に送信済みのパケット（図１３の例では、１０〜１２番目のパケット）は、送信しなかったこととして扱う。
【００９５】
受信側通信装置２は、７番目のパケットが受信されると、７〜９番目のパケットが正常に受信されたとして、ａｃｋ＝１０を送信側通信装置１に返す。送信側通信装置１は、ａｃｋ＝１０を受信すると、１０〜１２番目のパケットを受信側通信装置２に対して送信する。
【００９６】
すなわち、送信側通信装置１は、本来の受信ウィンドウサイズを超えて送信したパケット（１０〜１２番目のパケット）は、送信しなかったとして扱うので、ロストパケットとして扱われない。したがって、本来の受信ウィンドウを超えて既に送信済みのパケット（１０〜１２番目のパケット）が１つずつ再送されるようなことがなくなるので、素早くエラーから復帰することができる。
【００９７】
エラーからの復帰が完了した場合、送信側通信装置１は、再び拡大送信を実行する。
【００９８】
「拡大送信中におけるエラーからの復帰（２）」
ここで、上記したように、送信側通信装置１の制御部１２は、エラーからの復帰時に送信ウィンドウサイズを、本来の受信ウィンドウサイズに戻し、本来の受信ウィンドウサイズを超えて送信したパケットは、送信しなかったとして扱う。
【００９９】
本来の受信ウィンドウサイズを超えて送信したパケットは、packets-to-rollback=（sent-packets）−（original-window-size）として求めることができる。
【０１００】
しかしながら、タイミングにより、本来の受信ウィンドウサイズを超えて送信されたパケットが、受信側送信装置の受信バッファに、数パケット収まる場合がある。
【０１０１】
ところで、ＴＣＰのＴＣＰヘッダ内には、オプションフィールドが用意されており、このオプションフィールドを利用することで、受信側通信装置２は、選択確認応答（ｓａｃｋ）を送信側通信装置１に返すことができる。選択確認応答（ｓａｃｋ）は、既に届いたパケットの番号の情報等を含む。送信側通信装置１は、確認応答（ａｃｋ）と、選択確認応答（ｓａｃｋ）とにより、どのパケットが紛失して、どのパケットが受信側通信装置２に届いているのかを認識することができる。
【０１０２】
本来の受信ウィンドウサイズを超えて送信されたパケットが、受信バッファに数パケット収まった場合、送信側では、送信しなかったとして扱っている領域を指定した選択確認応答（ｓａｃｋ）が、ｄｕｐ_ｓｕｃｋとして受信側通信装置２に受信されてしまう。この場合、送信側通信装置１は、送信しなかったとして扱っている領域を指定した選択確認応答（ｓａｃｋ）を不正であるとして無視してしまう（本当に不正である場合と区別できない）。また、本来の受信ウィンドウサイズを超えて送信されたパケットが、受信バッファに数パケット収まった場合、エラーからの復帰完了時に受信側通信装置２から送信される確認応答ａｃｋを不正であるとして無視してしまう（本当に不正である場合と区別できない）。これにより、エラーの復帰に時間がかかってしまうという問題がある。
【０１０３】
そこで、送信側通信装置１は、本来の受信ウィンドウサイズを超えて送信されたパケットが、受信バッファに数パケット収まったような場合でも、素早くエラーから復帰することができるような処理を実行する。以降では、これについて説明する。
【０１０４】
図１４及び図１５は、エラーから復帰（リカバリ）する際の処理を示すフローチャートである。
【０１０５】
図１４に示すように、ＯＴＰＣに基づく拡大送信中において（ステップ４０１）、制御部１２は、確認応答（ａｃｋ）が受信されたかを判定する（ステップ４０２）。確認応答（ａｃｋ）が受信された場合（ステップ４０２のＹＥＳ）、今回受信された確認応答（ａｃｋ）が、前回受信された確認応答と同じであるかを判定する（ステップ４０３）。
確認応答（ａｃｋ）が前回と異なる場合（ステップ４０３のＮＯ）、制御部１２は、カウンタによるカウント値（ｄｕｐｃｎｔ）をゼロとし（ステップ４０４）、ステップ４０１へ戻る。一方、確認応答（ａｃｋ）が前回と同じである場合（ステップ４０３のＹＥＳ）、制御部１２は、カウンタによるカウント値（ｄｕｐｃｎｔ）を１プラスする（ステップ４０５）。
【０１０６】
次に、制御部１２は、カウンタによるカウント値が３以上であるかを判定する（ステップ４０６）。カウント値が３未満の場合（ステップ４０６のＮＯ）、制御部１２は、ステップ４０１へ戻る。一方、カウント値が３以上である場合（ステップ４０６のＹＥＳ）、制御部１２は、拡大されている送信ウィンドウサイズ（仮想ウィンドウサイズ）を小さくする（ステップ４０７）（図５（Ｂ）→（Ｃ））。これにより、制御部１２は、第１のリカバリ状態に移行し（ステップ４０８）、ロストパケットの再送を実行する。
【０１０７】
送信ウィンドウサイズが変更されるとき、制御部１２は、送信ウィンドウサイズ（仮想ウィンドウサイズ）を本来の受信ウィンドウサイズへ戻さず、送信ウィンドウサイズを受信ウィンドウサイズよりもすこし大きいサイズへと変更する（第３の送信ウィンドウサイズ）。この場合、制御部１２は、packets-to-rollback=（sent-packets）−（original-window-size）−（rollback-margin）により、送信ウィンドウサイズを縮小するサイズを決定する。このとき、制御部１２は、受信ウィンドウサイズ＋marginを超えて既に送信済みのパケットは、送信しなかったものとして扱う（図５（Ｃ）斜線領域参照）。
【０１０８】
図１５を参照して、制御部１２は、第１のリカバリ中において（ステップ５０１）、確認応答（ａｃｋ）が受信されたかを判定する（ステップ５０２）。受信側通信装置２からの確認応答（ａｃｋ）が受信された場合（ステップ５０２のＹＥＳ）、制御部１２は、今回受信された選択確認応答（ｓａｃｋ）が前回受信された選択確認応答と同じであるかを判定する（ステップ５０３）。
【０１０９】
今回受信された選択確認応答（ｓａｃｋ）が前回受信された選択確認応答と異なる場合（ステップ５０３のＮＯ）、制御部１２は、カウンタのカウント値をゼロとし（ステップ５０４）、ステップ５０１へ戻る。一方、今回受信された選択確認応答（ｓａｃｋ）が前回受信された選択確認応答と同じ場合（ステップ５０３のＹＥＳ）、制御部１２は、カウンタのカウント値を１プラスする（ステップ５０５）。
【０１１０】
次に、制御部１２は、カウント値が３以上であるかを判定する（ステップ５０６）。カウント値が３未満の場合（ステップ５０６のＮＯ）、制御部１２は、ステップ５０１へ戻る。一方、カウント値が３以上の場合（ステップ５０４のＹＥＳ）、先ほど、縮小された送信ウィンドウサイズ（仮想ウィンドウサイズ）をさらに縮小して補正する（ステップ５０７）（図５（Ｃ）→図５（Ｄ））。このとき、制御部１２は、受信側通信装置２から繰り返し通知された選択確認応答（ｓａｃｋ）の位置まで送信ウィドウサイズを戻す。受信側通信装置２の受信バッファからパケットが溢れた場合、選択確認応答が同じ値を示し続けるようになるので、この性質が利用されている。なお、選択確認応答（ｓａｃｋ）の位置よりも右側に位置する既に送信済みのパケットは、送信されなかったものとして扱われる（図５（Ｄ）斜線領域参照）。
【０１１１】
送信ウィンドウサイズが補正されると、制御部１２は、第２のリカバリ状態に移行し（ステップ５０８）、ロストパケットの再送を実行する。そして、リカバリが完了すると、通常送信状態に移行する（ステップ５０９）。そして、制御部１２は、再び、拡大送信を実行する（図４、図６参照）。なお、制御部１２は、リカバリ完了時に、パケットのロストが発生した時点での仮想ウィンドウサイズまで高速に仮想ウィンドウサイズを拡大する処理を実行してもよい。この場合、制御部１２は、仮想ウィンドウサイズが縮小されたときに、もとの仮想ウィンドウサイズを記憶しておき、このもとの仮想ウィンドウサイズまで高速に仮想ウィンドウサイズを戻す処理を実行する。これにより、リカバリ完了後のスループットを向上させることができる。
【０１１２】
図１４、図１５に示す処理により、送信側通信装置１は、本来の受信ウィンドウサイズを超えて送信されたパケットが、受信バッファに数パケット収まったような場合でも、素早くエラーから復帰することができる。
【０１１３】
ここで、リカバリが頻繁に発生する場合があり得る。このような場合には、送信ウィンドウサイズを拡大して、拡大送信を実行してもパケットの再送の分だけ無駄になってしまう。そこで、通常送信を拡大送信に切り替える条件として、輻輳ウィンドウが受信ウィンドウに達したこと、受信ウィンドウが安定した状態となったことの他に（図４参照）、リカバリが頻発していないことを条件としてもよい。この場合、送信側通信装置１は、リカバリが発生する頻度を判定し、このリカバリが頻繁に起こっている場合には、通常送信から拡大送信への切り替えを規制する。
【０１１４】
また、制御部１２は、仮想ウィンドウサイズを、リカバリが発生する頻度に応じて、可変に制御してもよい。この場合、リカバリ頻度が大きい場合には、仮想ウィンドウサイズは、小さくなり、リカバリ頻度が小さい場合には、仮想ウィンドウサイズは、大きくなる。
【０１１５】
〈作用等〉
以上説明したように、本実実施形態では、広帯域及び高遅延環境である場合に、送信ウィンドウサイズが、受信ウィンドウサイズを超えるサイズ（第２のウィンドウサイズ）とされ、受信ウィンドウサイズを超えた送信量のパケットが送信される。これにより、広帯域及び高遅延環境下において、スループットを向上させることができる。
【０１１６】
また、本実施形態では、送信側通信装置１の改良だけでよく、受信側通信装置２の改良は必要ない。受信側通信装置２は、一般のＴＣＰスタックを用いた通常実装を備えていれば足りる。また、本実施形態では、通信経路に追加機器を設置する必要もない。したがって、コスト抑えた展開が可能である。
【符号の説明】
【０１１７】
１・・・送信側通信装置
２・・・送信側通信装置
１２・・・制御部
１００・・・通信システム
【特許請求の範囲】
【請求項１】
受信側通信装置から受信ウィンドウサイズを受信し、かつ、送信ウィンドウサイズに応じた送信量のパケットを前記受信側通信装置に送信する通信部と、
前記受信側通信装置との間の経路が広帯域及び高遅延環境であるか否かを判定し、広帯域及び高遅延環境であると判定された場合に、前記送信ウィンドウサイズが前記受信ウィンドウサイズを超えない第１のウィンドウサイズとされる第１の状態を、前記送信ウィンドウサイズが前記受信ウィンドウサイズを超える第２のウィンドウサイズとされる第２の状態へ切り替え、前記第２の状態で前記受信ウィンドウサイズを超えた送信量の前記パケットを送信する制御部と
を具備する通信装置。
【請求項２】
請求項１に記載の通信装置であって、
前記通信部は、確認応答を前記受信側通信装置から受信し、
前記制御部は、前記確認応答が受信されるタイミングで前記パケットを前記送信部から送信させ、かつ、前記第２の状態で、前記確認応答の受信タイミングから前記パケットの送信が停止される期間を予測し、前記期間に前記パケットを追加的に前記送信部から送信させる
通信装置。
【請求項３】
請求項２に記載の通信装置であって、
前記制御部は、前記期間内に前記パケットを分散して前記送信部から送信させる
通信装置。
【請求項４】
請求項２に記載の通信装置であって、
前記制御部は、前記第２の状態で、前記確認応答が所定時間内に集中して受信されたかを判定し、前記確認応答が集中して受信された場合に、前記確認応答の受信タイミングに応じた前記パケットの送信を部分的に規制する
通信装置。
【請求項５】
請求項１に記載の通信装置であって、
前記制御部は、送信された前記パケットの前記経路上での紛失を検知し、前記第２の状態で前記パケットの紛失が検知された場合に、前記送信ウィンドウサイズが第２のウィンドウサイズとされる前記第２の状態を、前記ウィンドウサイズが前記第２のウィンドウサイズよりも小さい第３のウィンドウサイズとされる第３の状態へ切り替える
通信装置。
【請求項６】
請求項５に記載の通信装置であって、
前記制御部は、前記第２の状態が前記第３の状態に切り替えられた場合に、第３のウィンドウサイズを超えて既に送信済みのパケットは、送信しなかったとして扱う
通信装置。
【請求項７】
請求項６に記載の通信装置であって、
前記第３のウィンドウサイズは、前記受信ウィンドウサイズよりも大きい
通信装置。
【請求項８】
請求項７に記載の通信装置であって、
前記通信部は、選択確認応答を前記受信側通信装置から受信し、
前記制御部は、前記選択確認応答に基づいて、前記第３のウィンドウサイズの大きさを補正する
通信装置。
【請求項９】
請求項５に記載の通信装置であって、
前記制御部は、前記第２の状態が前記第３の状態へ切り替えられる頻度を判定し、前記頻度が所定の閾値よりも大きい場合には、前記第２の状態での前記受信ウィンドウサイズを超えた送信量の前記パケットの送信を規制する
通信装置。
【請求項１０】
請求項９に記載の通信装置であって、
前記制御部は、前記第２の状態が前記第３の状態へ切り替えられる頻度に応じて、前記第２のウィンドウサイズを可変に制御する
通信装置。
【請求項１１】
受信側通信装置と、
前記受信側通信装置から受信ウィンドウサイズを受信し、かつ、送信ウィンドウサイズに応じた送信量のパケットを前記受信側通信装置に送信する通信部と、前記受信側通信装置との間の経路が広帯域及び高遅延環境であるか否かを判定し、広帯域及び高遅延環境であると判定された場合に、前記送信ウィンドウサイズが前記受信ウィンドウサイズ超えない第１のウィンドウサイズとされる第１の状態を、前記送信ウィンドウサイズが前記受信ウィンドウサイズを超える第２のウィンドウサイズとされる第２の状態へ切り替え、前記第２の状態で前記受信ウィンドウサイズを超えた送信量の前記パケットを送信する制御部とを有する送信側通信装置と
を具備する通信システム。
【請求項１２】
通信装置に、
受信側通信装置から受信ウィンドウサイズを受信するステップと、
送信ウィンドウサイズに応じた送信量のパケットを受信側通信装置に送信するステップと、
前記受信側通信装置との間の経路が広帯域及び高遅延環境であるか否かを判定するステップと、
広帯域及び高遅延環境であると判定された場合に、前記送信ウィンドウサイズが前記受信ウィンドウサイズを超えない第１のウィンドウサイズとされる第１の状態を、前記送信ウィンドウサイズが前記受信ウィンドウサイズを超える第２のウィンドウサイズとされる第２の状態へ切り替えるステップと、
前記第２の状態で前記受信ウィンドウサイズを超えた送信量の前記パケットを送信するステップと
を実行させるプログラム。
【請求項１３】
受信側通信装置から受信ウィンドウサイズを受信し、
送信ウィンドウサイズに応じた送信量のパケットを受信側通信装置に送信し、
前記受信側通信装置との間の経路が広帯域及び高遅延環境であるか否かを判定し、
広帯域及び高遅延環境であると判定された場合に、前記送信ウィンドウサイズが前記受信ウィンドウサイズを超えない第１のウィンドウサイズとされる第１の状態を、前記送信ウィンドウサイズが前記受信ウィンドウサイズを超える第２のウィンドウサイズとされる第２の状態へ切り替え、
前記第２の状態で前記受信ウィンドウサイズを超えた送信量の前記パケットを送信する
通信方法。
【請求項１】
受信側通信装置から受信ウィンドウサイズを受信し、かつ、送信ウィンドウサイズに応じた送信量のパケットを前記受信側通信装置に送信する通信部と、
前記受信側通信装置との間の経路が広帯域及び高遅延環境であるか否かを判定し、広帯域及び高遅延環境であると判定された場合に、前記送信ウィンドウサイズが前記受信ウィンドウサイズを超えない第１のウィンドウサイズとされる第１の状態を、前記送信ウィンドウサイズが前記受信ウィンドウサイズを超える第２のウィンドウサイズとされる第２の状態へ切り替え、前記第２の状態で前記受信ウィンドウサイズを超えた送信量の前記パケットを送信する制御部と
を具備する通信装置。
【請求項２】
請求項１に記載の通信装置であって、
前記通信部は、確認応答を前記受信側通信装置から受信し、
前記制御部は、前記確認応答が受信されるタイミングで前記パケットを前記送信部から送信させ、かつ、前記第２の状態で、前記確認応答の受信タイミングから前記パケットの送信が停止される期間を予測し、前記期間に前記パケットを追加的に前記送信部から送信させる
通信装置。
【請求項３】
請求項２に記載の通信装置であって、
前記制御部は、前記期間内に前記パケットを分散して前記送信部から送信させる
通信装置。
【請求項４】
請求項２に記載の通信装置であって、
前記制御部は、前記第２の状態で、前記確認応答が所定時間内に集中して受信されたかを判定し、前記確認応答が集中して受信された場合に、前記確認応答の受信タイミングに応じた前記パケットの送信を部分的に規制する
通信装置。
【請求項５】
請求項１に記載の通信装置であって、
前記制御部は、送信された前記パケットの前記経路上での紛失を検知し、前記第２の状態で前記パケットの紛失が検知された場合に、前記送信ウィンドウサイズが第２のウィンドウサイズとされる前記第２の状態を、前記ウィンドウサイズが前記第２のウィンドウサイズよりも小さい第３のウィンドウサイズとされる第３の状態へ切り替える
通信装置。
【請求項６】
請求項５に記載の通信装置であって、
前記制御部は、前記第２の状態が前記第３の状態に切り替えられた場合に、第３のウィンドウサイズを超えて既に送信済みのパケットは、送信しなかったとして扱う
通信装置。
【請求項７】
請求項６に記載の通信装置であって、
前記第３のウィンドウサイズは、前記受信ウィンドウサイズよりも大きい
通信装置。
【請求項８】
請求項７に記載の通信装置であって、
前記通信部は、選択確認応答を前記受信側通信装置から受信し、
前記制御部は、前記選択確認応答に基づいて、前記第３のウィンドウサイズの大きさを補正する
通信装置。
【請求項９】
請求項５に記載の通信装置であって、
前記制御部は、前記第２の状態が前記第３の状態へ切り替えられる頻度を判定し、前記頻度が所定の閾値よりも大きい場合には、前記第２の状態での前記受信ウィンドウサイズを超えた送信量の前記パケットの送信を規制する
通信装置。
【請求項１０】
請求項９に記載の通信装置であって、
前記制御部は、前記第２の状態が前記第３の状態へ切り替えられる頻度に応じて、前記第２のウィンドウサイズを可変に制御する
通信装置。
【請求項１１】
受信側通信装置と、
前記受信側通信装置から受信ウィンドウサイズを受信し、かつ、送信ウィンドウサイズに応じた送信量のパケットを前記受信側通信装置に送信する通信部と、前記受信側通信装置との間の経路が広帯域及び高遅延環境であるか否かを判定し、広帯域及び高遅延環境であると判定された場合に、前記送信ウィンドウサイズが前記受信ウィンドウサイズ超えない第１のウィンドウサイズとされる第１の状態を、前記送信ウィンドウサイズが前記受信ウィンドウサイズを超える第２のウィンドウサイズとされる第２の状態へ切り替え、前記第２の状態で前記受信ウィンドウサイズを超えた送信量の前記パケットを送信する制御部とを有する送信側通信装置と
を具備する通信システム。
【請求項１２】
通信装置に、
受信側通信装置から受信ウィンドウサイズを受信するステップと、
送信ウィンドウサイズに応じた送信量のパケットを受信側通信装置に送信するステップと、
前記受信側通信装置との間の経路が広帯域及び高遅延環境であるか否かを判定するステップと、
広帯域及び高遅延環境であると判定された場合に、前記送信ウィンドウサイズが前記受信ウィンドウサイズを超えない第１のウィンドウサイズとされる第１の状態を、前記送信ウィンドウサイズが前記受信ウィンドウサイズを超える第２のウィンドウサイズとされる第２の状態へ切り替えるステップと、
前記第２の状態で前記受信ウィンドウサイズを超えた送信量の前記パケットを送信するステップと
を実行させるプログラム。
【請求項１３】
受信側通信装置から受信ウィンドウサイズを受信し、
送信ウィンドウサイズに応じた送信量のパケットを受信側通信装置に送信し、
前記受信側通信装置との間の経路が広帯域及び高遅延環境であるか否かを判定し、
広帯域及び高遅延環境であると判定された場合に、前記送信ウィンドウサイズが前記受信ウィンドウサイズを超えない第１のウィンドウサイズとされる第１の状態を、前記送信ウィンドウサイズが前記受信ウィンドウサイズを超える第２のウィンドウサイズとされる第２の状態へ切り替え、
前記第２の状態で前記受信ウィンドウサイズを超えた送信量の前記パケットを送信する
通信方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公開番号】特開２０１２−９５１９０（Ｐ２０１２−９５１９０Ａ）
【公開日】平成２４年５月１７日（２０１２．５．１７）
【国際特許分類】
【出願番号】特願２０１０−２４２１３７（Ｐ２０１０−２４２１３７）
【出願日】平成２２年１０月２８日（２０１０．１０．２８）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
【公開日】平成２４年５月１７日（２０１２．５．１７）
【国際特許分類】
【出願日】平成２２年１０月２８日（２０１０．１０．２８）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
[ Back to top ]