(57)【要約】【課題】帯域保証ネットワークでのデータ転送において保証帯域を効率良く利用して高いスループットを保つとともにユーザ間の公平性を保つことのできる装置を提供する。【解決手段】帯域情報保持部２５は、帯域保証ネットワークにてデータ送信端末からデータ受信端末へのフローに割り当てられた帯域保証値を保持する。伝送遅延時間算出部２６は、そのフローの帯域保証ネットワークによる伝送遅延時間を計測する。ウィンドウサイズ算出部２８は、帯域情報保持部２５に保持されている帯域保証値と、伝送遅延時間算出部２６で計測された伝送遅延時間とから、そのフローのデータが帯域保証値以内の帯域となるウィンドウサイズを算出する。ウィンドウサイズ書き込み部２９は、ウィンドウサイズ算出部２８で算出されたウィンドウサイズをデータ送信端末の帯域制御に使用させるためにデータ送信端末に通知する。【選択図】図２
2008205932.tif 000002
【特許請求の範囲】
【請求項１】
データ送信端末からデータ受信端末へ送信できる帯域が保証された帯域保証ネットワークにおいて前記データ送信端末と前記データ受信端末の間に配置されるノード装置であって、
前記帯域保証ネットワークにて前記データ送信端末から前記データ受信端末へのフローに割り当てられた帯域保証値を保持する帯域情報保持部と、
前記フローの前記帯域保証ネットワークによる伝送遅延時間を計測する伝送遅延時間算出部と、
前記帯域情報保持部に保持されている前記フローの帯域保証値と、前記伝送遅延時間算出部で計測された伝送遅延時間とから、前記フローのデータが前記帯域保証値以内の帯域となるウィンドウサイズを算出するウィンドウサイズ算出部と、
前記ウィンドウサイズ算出部で算出された前記ウィンドウサイズを前記データ送信端末の帯域制御に使用させるために前記データ送信端末に通知するウィンドウサイズ書き込み部と、を有するノード装置。
【請求項２】
前記データ送信端末から前記データ受信端末への時間的に集中して送信されたデータを分散させるシェーパー部を更に有する、請求項１に記載のノード装置。
【請求項３】
前記データ送信端末と前記データ受信端末の間のプロトコルは、データ受信装置の受信バッファの状態に依存してサイズが決定される広告ウィンドウと、前記帯域保証ネットワークでのパケット廃棄の状況に応じて前記データ送信端末がサイズを決定する輻輳ウィンドウとが定義され、前記広告ウィンドウのサイズと前記輻輳ウィンドウのサイズのいずれか小さい方を採用して前記データ送信端末での帯域制御に用いるプロトコルであり、
前記ウィンドウサイズ書き込み部は、前記データ受信端末から前記データ送信端末に通知される前記広告ウィンドウのサイズを、前記ウィンドウサイズ算出部で算出されたウィンドウサイズに書き換える、請求項１または２に記載のノード装置。
【請求項４】
前記ノード装置は前記帯域保証ネットワークのエッジにおいて前記データ送信端末に接続されており、
前記伝送遅延時間算出部は、前記データ送信装置と前記データ受信装置の間のコネクション確立において、前記データ送信端末から前記データ受信端末へ送信された信号の通過を認識した時刻から、前記データ受信端末から前記データ送信端末への応答の通過を認識した時刻までの時間を前記伝送遅延時間として計測する、請求項１から３のいずれか１項に記載のノード装置。
【請求項５】
データ送信端末からデータ受信端末へ送信できる帯域が保証された帯域保証ネットワークにおいて、前記データ送信端末から前記データ受信端末へのデータ送信の帯域を制御するための帯域制御方法であって、
前記帯域保証ネットワークにて前記データ送信端末から前記データ受信端末へのフローに割り当てられた帯域保証値を予め保持し、
前記フローの前記帯域保証ネットワークによる伝送遅延時間を計測し、
保持している前記フローの帯域保証値と、計測した伝送遅延時間とから、前記フローのデータが前記帯域保証値以内の帯域となるウィンドウサイズを算出し、
算出された前記ウィンドウサイズを前記データ送信端末の帯域制御に使用する、帯域制御方法。
【請求項６】
前記データ送信端末から前記データ受信端末への時間的に集中して送信されたデータを分散させる、請求項５に記載の帯域制御方法。
【請求項７】
前記データ送信端末と前記データ受信端末の間のプロトコルは、データ受信装置の受信バッファの状態に依存してサイズが決定される広告ウィンドウと、前記帯域保証ネットワークでのパケット廃棄の状況に応じて前記データ送信端末がサイズを決定する輻輳ウィンドウとが定義され、前記広告ウィンドウのサイズと前記輻輳ウィンドウのサイズのいずれか小さい方を採用して前記データ送信端末での帯域制御に用いるプロトコルであり、
前記データ受信端末から前記データ送信端末に通知される前記広告ウィンドウのサイズを、算出された前記ウィンドウサイズに書き換えることにより、前記ウィンドウサイズを前記データ送信端末の帯域制御に使用させる、請求項５または６に記載の帯域制御方法。
【請求項８】
前記帯域保証ネットワークのエッジにおいて前記データ送信端末に接続されたエッジノードで、前記データ送信装置と前記データ受信装置の間のコネクション確立において、前記データ送信端末から前記データ受信端末へ送信された信号の通過を認識した時刻から、前記データ受信端末から前記データ送信端末への応答の通過を認識した時刻までの時間を前記伝送遅延時間として計測する、請求項５から７のいずれか１項に記載の帯域制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、端末間でネットワークを介してデータを送受信するシステムにおけるフロー制御に関する。
【背景技術】
【０００２】
パソコンなどの端末の間ではインターネットなどのコンピュータネットワークを介した通信が行われる。この通信によってファイル等のデータが転送される。この種のデータ転送システムでは、トランスポート層のプロトコルとして、標準的なトランスポートプロトコルであるＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）が用いられることが多い。
【０００３】
また、データ転送においては大容量のデータを高速で転送することが要求されることがある。これに対して端末のＴＣＰプロトコルに変更を加えることで実効的なスループットを向上させる検討が数多くなされている（例えば、非特許文献１、２参照）。
【非特許文献１】浜  崇之、外３名，  “ストリーミング配信に適したＴＣＰ制御方式の提案”，  電子情報通信学会通信ソサイエティ大会（Ｂ・１１・２），  ２００６年９月，  ｐ．２６２
【非特許文献２】Ｙｕｎｈｏｎｇ  Ｇｕ、外３名，  “ＳＡＢＵＬ：Ａ  Ｈｉｇｈ  Ｐｅｒｆｏｒｍａｎｃｅ  Ｄａｔａ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ”，  Ｍａｎｕｓｃｒｉｐｔ，ｓｕｂｍｉｔｔｅｄ  ｔｏ  ＩＥＥＥ  ＣＯＭＭＵＮＩＣＡＴＩＯＮ  ＬＥＴＴＥＲＳ
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ＴＣＰでは、データを保存しておくウィンドウのサイズを自立的に変化させる帯域制御が行なわれる。しかし、この帯域制御では、ウィンドウサイズの変化に応じてスループットが鋸歯状になり、平均としてのスループットが低下してしまう。そのため、帯域が保証されたネットワークでのデータ転送において、保証された帯域を十分に活用できないという問題があった。
【０００５】
上述したＴＣＰプロトコルに変更を加えることで実効的なスループットを向上させる技術にはこの問題に対する対策がある。しかし、これらの技術は端末主導でデータのレートを制御する方式であるため、ユーザ間でスループットの公平性を保つのが困難であった。
【０００６】
本発明の目的は、帯域保証ネットワークでのデータ転送において保証帯域を効率良く利用して高いスループットを保つとともにユーザ間の公平性を保つことのできる装置を提供することである。
【課題を解決するための手段】
【０００７】
上記目的を達成するために、本発明のノード装置は、
データ送信端末からデータ受信端末へ送信できる帯域が保証された帯域保証ネットワークにおいて前記データ送信端末と前記データ受信端末の間に配置されるノード装置であって、
前記帯域保証ネットワークにて前記データ送信端末から前記データ受信端末へのフローに割り当てられた帯域保証値を保持する帯域情報保持部と、
前記フローの前記帯域保証ネットワークによる伝送遅延時間を計測する伝送遅延時間算出部と、
前記帯域情報保持部に保持されている前記フローの帯域保証値と、前記伝送遅延時間算出部で計測された伝送遅延時間とから、前記フローのデータが前記帯域保証値以内の帯域となるウィンドウサイズを算出するウィンドウサイズ算出部と、
前記ウィンドウサイズ算出部で算出された前記ウィンドウサイズを前記データ送信端末の帯域制御に使用させるために前記データ送信端末に通知するウィンドウサイズ書き込み部と、を有している。
【０００８】
本発明によれば、データ送信端末からデータ受信端末へ送信するデータのレートを保証帯域内で安定的に制御できるので、保証帯域を効率良く利用することができ、また帯域保証ネットワークによる保証帯域に基づいた帯域制御を行なうのでユーザ間の公平性が保たれる。
【０００９】
また、前記データ送信端末から前記データ受信端末への時間的に集中して送信されたデータを分散させるシェーパー部を更に有することにしてもよい。
【００１０】
これによればデータ送信端末から帯域保証ネットワークに送出されるデータが短時間に集中するのを防止することができる。
【００１１】
また、前記データ送信端末と前記データ受信端末の間のプロトコルは、データ受信装置の受信バッファの状態に依存してサイズが決定される広告ウィンドウと、前記帯域保証ネットワークでのパケット廃棄の状況に応じて前記データ送信端末がサイズを決定する輻輳ウィンドウとが定義され、前記広告ウィンドウのサイズと前記輻輳ウィンドウのサイズのいずれか小さい方を採用して前記データ送信端末での帯域制御に用いるプロトコルであり、
前記ウィンドウサイズ書き込み部は、前記データ受信端末から前記データ送信端末に通知される前記広告ウィンドウのサイズを、前記ウィンドウサイズ算出部で算出されたウィンドウサイズに書き換えることにしてもよい。
【００１２】
これによれば、ノード装置がデータ受信端末からデータ送信端末へ通知される広告ウィンドウサイズを書き換えるので、データ送信端末はそれを元に既存の動作をするだけであり、データ送信端末のプロトコルに本発明に特有の機能を加えることなくスループットを改善できる。
【００１３】
また、前記ノード装置は前記帯域保証ネットワークのエッジにおいて前記データ送信端末に接続されており、
前記伝送遅延時間算出部は、前記データ送信装置と前記データ受信装置の間のコネクション確立において、前記データ送信端末から前記データ受信端末へ送信された信号の通過を認識した時刻から、前記データ受信端末から前記データ送信端末への応答の通過を認識した時刻までの時間を前記伝送遅延時間として計測することにしてもよい。
【発明の効果】
【００１４】
本発明によれば、データ送信端末からデータ受信端末へ送信するデータのレートを保証帯域内で安定的に制御できるので、保証帯域を効率良く利用することができ、また帯域保証ネットワークによる保証帯域に基づいた帯域制御を行なうのでユーザ間の公平性が保たれる。
【発明を実施するための最良の形態】
【００１５】
一般的なＴＣＰでは広告ウィンドウと輻輳ウィンドウという２つのウィンドウが定義される。広告ウィンドウのサイズは受信側で受信バッファの状態に依存して決定される。輻輳ウィンドウのサイズは送信側でパケット廃棄の状況に応じて決定される。フロー制御に用いるウィンドウサイズには広告ウィンドウサイズと輻輳ウィンドウサイズのうちいずれか小さい方が選択される。このウィンドウサイズはＡＣＫが到着したときに更新される。
【００１６】
本実施形態では、データの送信側となるデータ送信端末と、データの受信側となるデータ受信端末との間は、帯域保証ネットワークによって帯域が保証される構成である。したがって、帯域保証値以下でデータを送出している限りパケットの廃棄が生じないことが想定される。それ故、データが帯域保証値以下で送出されるように広告ウィンドウサイズを調節すればパケットの廃棄を防ぐことができる。パケットの廃棄が生じなければ輻輳ウィンドウサイズが小さくならないので常に広告ウィンドウサイズがＴＣＰウィンドウサイズに採用されることになる。その結果、スループットが鋸歯状に変動しなくなり保証帯域の効率的な利用が可能となる。
【００１７】
そこで、本実施形態では、データ送信端末とデータ受信端末の間でエッジノードが、送信側と受信側の間の伝送遅延時間と、帯域保証ネットワークによる帯域保証値とから、データが帯域保証値以内で送出されるようなウィンドウサイズを算出し、データ受信端末からデータ送信端末へのＡＣＫパケットに記載される広告ウィンドウサイズを、算出したウィンドウサイズの値に書き換える。
【００１８】
これにより、データ送信端末からデータ受信端末へ送信するデータのレートを保証帯域内で安定的に制御できるので、保証帯域を効率良く利用することができる。また、帯域保証ネットワークによる保証帯域に基づいた帯域制御を行なうのでユーザ間の公平性が保たれる。また、エッジノードがＡＣＫパケットの広告ウィンドウサイズを書き換え、データ送信端末はそれを元に既存の動作をするだけなので、データ送信端末のＴＣＰプロトコルに変更を加えることなくスループットを改善することができる。
【００１９】
このとき帯域保証値と一致するレートでデータが送出されるようなウィンドウサイズが好適である。
【００２０】
また、本実施形態では、ＴＣＰ特有のＲＴＴ（Ｒｏｕｎｄ  Ｔｒｉｐ  Ｔｉｍｅ）毎のバースト的なデータの送出により途中のルータにおいてバッファのオーバーフローが生じるのを、ＴＣＰのデータパケットをシェーピングすることにより防止する。
【００２１】
以下、本実施形態について図面を参照して詳細に説明する。
【００２２】
図１は、本実施形態によるデータ通信システムの構成を示すブロック図である。図１を参照すると、本実施形態のデータ通信システムは、エッジノード１１，１２および帯域管理サーバ（ＲＡＣＳ（Ｒｅｓｏｕｒｃｅ  ａｎｄ  Ａｄｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｓｕｂ−ｓｙｓｔｅｍ）、Ｒｅｓｏｒｃｅ  Ａｇｅｎｔ）１３を有している。
【００２３】
データ送信端末１４はエッジノード１１に接続され、データ受信端末１５はエッジノード１２に接続されている。エッジノード１１とエッジノード１２は帯域保証ネットワーク１６上でデータを送受信することができる。これによりデータ送信端末１４からのデータがエッジノード１１とエッジノード１２を介してデータ受信端末１５へ転送される。
【００２４】
ＲＡＣＳ１３は帯域保証ネットワーク１６の全リンクの帯域情報を集中的に管理する装置である。帯域情報にはリンクに割り当てられた保証帯域の情報が含まれている。ＲＡＣＳ１３は管理している各リンクの帯域情報をエッジノード１１，１２に通知する。ＲＡＣＳ１３による帯域管理によって、データ送信端末１４からデータ受信端末１５へのリンクは帯域保証ネットワーク１６での保証帯域が確保される。その結果、データ送信端末１４が保証帯域以下でデータを送出する限り帯域保証ネットワーク１６内でパケットの廃棄は発生しない。
【００２５】
データ送信端末１４の接続されたエッジノード１１は、データ送信端末１４とデータ受信端末１５の間の伝送遅延時間を測定する。さらにエッジノード１１は、測定した伝送遅延時間と、ＲＡＣＳ１３から通知された帯域保証値とから、データが帯域保証値以内で送出されるようなウィンドウサイズを算出する。さらにエッジノード１１は、データ受信端末１５からデータ送信端末１４へのＡＣＫパケットに記載される広告ウィンドウサイズを、算出したウィンドウサイズの値に書き換える。
【００２６】
図２は、本実施形態のエッジノードの構成を示すブロック図である。図２を参照すると、エッジノード１１は、データ受信部２１、フロー識別・振り分け部２２、シェーパー部２３、データ送信部２４、帯域情報保持部２５、伝送遅延時間算出部２６、フロー情報保持部２７、ウィンドウサイズ算出部２８、および広告ウィンドウサイズ書き込み部２９を有している。
【００２７】
帯域情報保持部２５は、ＲＡＣＳ１３から通知されたサービス対象ユーザの帯域情報とユーザ情報（宛先・送信元ＩＰアドレス、宛先・送信元ポート番号）とを対応付けて保持する。帯域情報には、リンクに割り当てられた保証帯域の情報が含まれている。リンクは、ユーザ情報により識別することができる。
【００２８】
データ受信部２１は、データパケットやＡＣＫパケットなどのパケットを受信し、フロー識別・振り分け部２２に送る。
【００２９】
フロー識別・振り分け部２２は、帯域情報保持部２５に帯域情報とともに保持されているユーザ情報を基に、帯域を保証したデータ転送のサービスの対象となるフロー（サービス対象フロー）と、帯域を保証したデータ転送のサービスの対象とならないフロー（サービス非対象フロー）とを識別する。さらにフロー識別・振り分け部２２は、サービス対象フローのデータパケットを送出口２２ｂからシェーパー部２３へ、サービス対象フローのＡＣＫパケットを送出口２２ａから広告ウィンドウサイズ書き込み部２９へ、サービス非対象フローのパケットを送出口２２ｃからデータ送信部２４へと振り分ける。
【００３０】
シェーパー部２３は、フロー識別・振り分け部２２からのサービス対象フローのパケットをシェーピングしてパケットの送信間隔を均等にし、データ送信部２４に送る。
【００３１】
データ送信部２４は、シェーパー部２３からのパケットと、フロー識別・振り分け部２２からのパケットと、広告ウィンドウサイズ書き込み部２９からのパケットとを、帯域保証ネットワーク１６へ送出する。シェーパー部２３からのデータパケットはエッジノード１２に転送され、広告ウィンドウサイズ書き込み部２９からのＡＣＫパケットはデータ送信端末１４に転送される。また、フロー識別・振り分け部２２からのパケットは、その宛先によって指定された装置に転送される。
【００３２】
伝送遅延時間算出部２６は、データ送信端末１１とデータ受信端末１２の間の伝送遅延時間を計測する。伝送遅延時間は例えばＲＴＴである。
【００３３】
フロー情報保持部２７は、フロー識別・振り分け部２２で識別されるサービス対象フローのコネクション情報と、伝送遅延時間算出部２６で算出された伝送遅延時間とを対応付けて保持する。
【００３４】
ウィンドウサイズ算出部２８は、フロー情報保持部２７に保持されている伝送遅延時間と、帯域情報保持部２５に保持されている帯域情報の帯域保証値とを用いて、データの送出帯域が帯域保証値以内となるようなウィンドウサイズを算出する。
【００３５】
広告ウィンドウサイズ書き込み部２９は、データ受信端末１５からデータ送信端末１４へのＡＣＫパケットのウィンドウサイズのフィールドに、ウィンドウサイズ算出部２８で算出されたウィンドウサイズの値を書き込み、そのＡＣＫパケットをデータ送信部２４に送る。
【００３６】
図３は、エッジノードが伝送遅延時間を計測する様子を示す概念図である。図３を参照して伝送遅延時間の計測について説明する。なお、本実施形態では通信中にルーティング変更はなくＲＴＴは変動しないものとする。
【００３７】
伝送遅延時間の計測は、データ送信端末１４とデータ受信端末１５がスリーウェイハンドシェイクによりコネクションを確立するときに行なわれえる。コネクションを確立するとき、まずデータ受信端末１５はデータ送信端末１４に対してデータ要求としてＳＹＮパケットを送信する。データ送信端末１４は、データ受信端末１５からＳＹＮパケットを受信すると、それに対するＳＹＮ／ＡＣＫパケットをデータ受信端末１５へ送信する。データ受信端末１５は、データ送信端末１５からＳＹＮ／ＡＣＫパケットを受信すると、それに対するＡＣＫパケットをデータ送信端末１４へ送信する。
【００３８】
図３には、その中のデータ送信端末１４からデータ受信端末１５へのＳＹＮ／ＡＣＫパケットと、データ受信端末１５からデータ送信端末１４へのＡＣＫパケットとが示されている。そして、エッジノード（Ｓ−Ｅｄｇｅ）１１はＳＹＮ／ＡＣＫパケットの送信からＡＣＫパケットの受信までの時間を往復の伝送遅延時間として計測する。
【００３９】
図４は、伝送遅延時間を計測するときのエッジノード内のブロック間の信号のやりとりを示すシーケンス図である。図４を参照すると、データ送信端末１４側のエッジノード１１において、フロー識別・振り分け部２２は、データ送信端末１４からデータ受信端末１５へのＳＹＮ／ＡＣＫパケットを観測すると（ステップ１０１）、サービス対象フローのユーザ情報と共に伝送遅延時間計測開始要求を伝送遅延時間算出部２６に送る（ステップ１０２）。これにより遅延時間算出部２６は伝送遅延時間ｔ１の計測を開始する。
【００４０】
その後、フロー識別・振り分け部２２は、データ受信端末１５からデータ送信端末１４へのＡＣＫパケットを観測すると（ステップ１０３）、ユーザ情報と共に伝送遅延時間計測終了要求を伝送遅延時間算出部２６に送る（ステップ１０４）。これにより遅延時間算出部２６は伝送遅延時間ｔ１の計測を終了する。
【００４１】
以上のようにしてデータ送信端末１４とデータ受信端末１５の間の往復の伝送遅延時間ｔ１が計測される。伝送遅延時間ｔ１の計測を終えた伝送遅延時間算出部２６は、計測した伝送遅延時間ｔ１をユーザ情報と共に伝送遅延時間報告としてフロー情報保持部２７に通知する（ステップ１０５）。
【００４２】
なお、本来であればＲＴＴは伝送遅延時間ｔ１にデータ送信端末１４と送信側のエッジノード１１の間の伝送遅延時間ｔ２を加えた値である。しかし、本実施形態ではデータ送信端末１４と送信側のエッジノード１１との間の伝送遅延時間ｔ２が伝送遅延時間ｔ１に対して十分に小さな値であるとし、伝送遅延時間ｔ１をＲＴＴとみなしている。
【００４３】
図５は、フロー識別・振り分け部によるパケット振り分けを説明するための図である。図５を参照して、フロー識別・振り分け部によるパケット振り分けを詳細に説明する。
【００４４】
データ送信端末１４とデータ受信端末１５間でコネクションが確立されると、データの転送が開始される。
【００４５】
エッジノード１１のフロー識別・振り分け部２２は、データ送信端末１４からデータパケットを受信すると、そのパケットがサービス対象フローのデータパケットか、サービス非対象フローのデータパケットかを判断する。サービス対象フローのデータパケットであれば、フロー識別・振り分け部２２は、そのデータパケットを、送出口２２ｂを通してシェーパー部２３に送る。サービス非対象フローのデータパケットであれば、フロー識別・振り分け部２２は、そのデータパケットを、送出口２２ｃを通してデータ送信部２４に送る。
【００４６】
また、エッジノード１１のフロー識別・振り分け部２２は、データ受信端末１５からのＡＣＫパケットを受信すると、サービス対象フローのＡＣＫパケットか否か判定をする。サービス対象フローのＡＣＫパケットであれば、フロー識別・振り分け部２２は、そのＡＣＫパケットを、送出口２２ａを通して広告ウィンドウサイズ書き込み部２９に送る。サービス非対象フローのＡＣＫパケットであれば、フロー識別・振り分け部２２は、そのＡＣＫパケットを、送出口２２ｃを通してデータ送信部２４に送る。
【００４７】
図６は、ウィンドウサイズを算出するときのエッジノード内のブロック間の信号のやりとりを示すシーケンス図である。データ受信端末１５からの最初のＡＣＫパケットがエッジノード１１のフロー識別・振り分け部２２に到着すると（ステップ２０１）、フロー識別・振り分け部２２はウィンドウサイズ算出部２８に対して、サービス対象フローのユーザ情報と共にウィンドウサイズ計算要求を送る（ステップ２０２）。
【００４８】
ウィンドウサイズ計算要求を受けたウィンドウサイズ算出部２８は、そのユーザ情報を基にして、帯域情報保持部２５に対してユーザ情報に対応する帯域保証値を要求し（ステップ２０３）、フロー情報保持部２７に対してユーザ情報に対応するＲＴＴを要求する（ステップ２０４）。
【００４９】
フロー情報保持部２７は、ウィンドウサイズ算出部２８からの要求に応じてＲＴＴの値を返送する（ステップ２０５）。また、帯域情報保持部２５は、ウィンドウサイズ算出部２８からの要求に応じて帯域保証値を返送する（ステップ２０６）。
【００５０】
ＲＴＴと帯域保証値を受信したウィンドウサイズ算出部２８は、それらの値を基に、データ送信端末１４が帯域保証値以内でデータを送出するようなウィンドウサイズを算出する（ステップ２０７）。このとき帯域保証値と一致するレートでデータが送出されるようなウィンドウサイズが好適である。
【００５１】
ウィンドウサイズの求め方は例えば式（１）により求めることができる。
【００５２】
【数１】
2008205932.tif 000003
【００５３】
式（１）によれば、帯域保証値が１００［Ｍｂｐｓ］であり、ＲＴＴが０．０１［ｓ］である場合、ウィンドウサイズは１２５［ＫＢ］となる。
【００５４】
図７は、ＡＣＫパケットに広告ウィンドウサイズを書き込むときのエッジノード内のブロック間の信号のやりとりを示すシーケンス図である。図７を参照すると、まずウィンドウサイズ算出部２８が、サービス対象フローのウィンドウのサイズを算出する（ステップ３０１）。続いて、ウィンドウサイズ算出部２８は、算出したウィンドウサイズと、そのサービス対象フローのユーザ情報とを広告ウィンドウサイズ書き込み部２９に通知する（ステップ３０２）。広告ウィンドウサイズ書き込み部２９は、ウィンドウサイズ算出部２８から通知されたウィンドウサイズの値を、フロー識別・振り分け部２２からのＡＣＫパケットのウィンドウサイズのフィールドに書き込む（ステップ３０３）。広告ウィンドウサイズ書き込み部２９でウィンドウサイズが書き込まれたＡＣＫパケットはデータ送信部２４に送られる。
【００５５】
図８は、本実施形態によるデータ転送のスループットの遷移を示すグラフである。
【００５６】
エッジノード１１によってウィンドウサイズが書き込まれたＡＣＫパケットがデータ送信端末１４に到達してデータ送信端末１４とデータ受信端末１５の間のコネクションが確立すると、データ送信端末１４はデータ受信端末１５へデータの送信を開始する。
【００５７】
データ転送において、データ送信端末１４は、ＡＣＫパケットに書き込まれていた広告ウィンドウサイズと自身が管理している輻輳ウィンドウサイズとを比較し、いずれか小さい方をＴＣＰウィンドウサイズに採用する。
【００５８】
データ転送開始直後のＴＣＰスロースタート時には、エッジノード１１が書き換えた広告ウィンドウサイズより輻輳ウィンドウサイズの方が小さい状態となる。そのため輻輳ウィンドウサイズがＴＣＰウィンドウサイズに採用される。ＴＣＰスロースタート時にはデータ送信端末１４は図８に示されているようにスループットを少しずつ上昇させる。
【００５９】
スループットは少しずつ上昇して帯域保証値に近づく。しかし、データ転送が帯域保証値以内に収まるように広告ウィンドウサイズが設定されており、輻輳ウィンドウサイズが広告ウィンドウサイズを超えると、広告ウィンドウサイズがＴＣＰウィンドウサイズに採用されるので、データ送信端末１４からのデータレートは帯域保証値を越えることはない。
【００６０】
また、帯域保証ネットワークではデータレートが帯域保証値以下であればパケット廃棄が生じないため、データ送信端末１４が輻輳ウィンドウサイズを小さくすることがない。そのためエッジノード１１の書き込んだ広告ウィンドウサイズが常にＴＣＰウィンドウサイズとして採用され続ける。
【００６１】
以上の動作の結果としてスループットが帯域保証値付近で安定することになる。図８を参照すると、スループットは帯域保証値に達した後、帯域保証値付近で安定している。
【００６２】
本実施形態では、ＴＣＰコネクションでのデータ転送が継続されれば、スループットが帯域保証値付近にある状態の時間的な割合が高くなり、ＴＣＰスロースタートの状態の割合が低くなる。ストリーミングのような長時間にわたってデータ転送が継続的に行なわれるような状況では、輻輳ウィンドウサイズがＴＣＰウィンドウサイズとして採用される時間、すなわちスループットが帯域保証値を下回ってネットワークの利用効率が低くなる時間は、全体の通信時間の中で無視できるほど短いものとする。
【００６３】
このように、本実施形態では、エッジノード１１は、データが帯域保証値以内で送出されるようなウィンドウサイズを算出して、データ受信端末１５からデータ送信端末１４へのＡＣＫパケットに広告ウィンドウサイズとして書き込むので、データ送信端末１４は、ＡＣＫパケットの広告ウィンドウサイズをＴＣＰウィンドウサイズとして採用し、帯域保証値付近の安定したレートでデータを送出することができる。その結果、データ送信端末１４のＴＣＰプロトコルを変更しなくても保証帯域を効率良く利用して高いスループットを保つことができる。例えば、帯域保証ネットワーク下におけるリッチコンテンツ配信サービスにおいて、ネットワークのリソースを効率良く利用し、高スループットを保った状態でコンテンツを配信することができる。また、本実施形態では帯域保証ネットワーク１６による帯域保証値に基づいてデータのスループットが制御されるのでユーザ間の公平性が保たれる。
【００６４】
なお、本実施形態のデータ受信端末１５はバッファが十分大きく、大きなウィンドウサイズを扱えるものとする。例えば、データ送信端末１４とデータ受信端末１５のウィンドウスケールオプションが有効になっているものとする。
【００６５】
図９は、本実施形態のシェーパー部２３によるシェーピングの様子を説明するための図である。ＴＣＰには、送出されるデータが時間的に分散せず、図９（ａ）に示すようにＲＴＴ毎にバースト的にデータが送出されるという特有の性質がある。
【００６６】
シェーパー部２３は、スループットが低下しない範囲内でデータを時間的に分散させてバースト的な送出を緩和する。具体例としては、シェーパー部２３は、ＲＴＴ毎に集中しているパケット群を、互いのパケットの間隔が伝送遅延時間／パケット数となるように時間的に分散させる。
【００６７】
図９（ａ）を参照すると、シェーピング前にはＲＴＴ毎に送信データのデータ量が高い状態が現れている。それに対して、図９（ｂ）に示されているシェーピング後にはデータが分散され、データ量の高い状態が発生しなくなっている。
【００６８】
これによって、データ送信端末１４から帯域保証ネットワーク１６に送出されるデータが短時間に集中するのを防止することができる。例えば、ＴＣＰパス上のルータにバースト的なデータが流れ込んで、ルータのバッファがオーバーフローするのを防止することができる。
【図面の簡単な説明】
【００６９】
【図１】本実施形態によるデータ通信システムの構成を示すブロック図である。
【図２】本実施形態のエッジノードの構成を示すブロック図である。
【図３】エッジノードが伝送遅延時間を計測する様子を示す概念図である。
【図４】伝送遅延時間を計測するときのエッジノード内のブロック間の信号のやりとりを示すシーケンス図である。
【図５】フロー識別・振り分け部によるパケット振り分けを説明するための図である。
【図６】ウィンドウサイズを算出するときのエッジノード内のブロック間の信号のやりとりを示すシーケンス図である。
【図７】ＡＣＫパケットに広告ウィンドウサイズを書き込むときのエッジノード内のブロック間の信号のやりとりを示すシーケンス図である。
【図８】本実施形態によるデータ転送のスループットの遷移を示すグラフである。
【図９】本実施形態のシェーパー部２３によるシェーピングの様子を説明するための図である。
【符号の説明】
【００７０】
１１，１２    エッジノード
１３    帯域管理サーバ
１４    データ送信端末
１５    データ受信端末
１６    帯域保証ネットワーク
２１    データ受信部
２２    フロー識別・振り分け部
２２ａ、２２ｂ、２２ｃ    送出口
２３    シェーパー部
２４    データ送信部
２５    帯域情報保持部
２６    伝送遅延時間算出部
２７    フロー情報保持部
２８    ウィンドウサイズ算出部
２９    広告ウィンドウサイズ書き込み部
１０１〜１０５、２０１〜２０７、３０１〜３０３    ステップ
【図１】
2008205932.tif 000004
【図２】
2008205932.tif 000005
【図３】
2008205932.tif 000006
【図４】
2008205932.tif 000007
【図５】
2008205932.tif 000008
【図６】
2008205932.tif 000009
【図７】
2008205932.tif 000010
【図８】
2008205932.tif 000011
【図９】
2008205932.tif 000012