(57)【要約】【課題】  ＴＣＰの性能低下を迅速に復旧することができるマルチＴＣＰ確認応答を用いたＴＣＰ輻輳制御システム及び方法を提供する。【解決手段】  受信パケットにパケット損失が発生した移動ノードが、再転送されるパケットを受信する段階と、移動ノードが、転送すべき確認応答パケットの数を計算する段階と、移動ノードが、計算された数だけのマルチ確認応答パケットを生成し、送信ノードに転送する段階と、送信ノードが受信したマルチ確認応答パケットに応じて、輻輳ウィンドウ値を増加させ、ＴＣＰ転送を行う段階とを含む。【選択図】  図５
2006222960.tif 000002
【特許請求の範囲】
【請求項１】
無線リンクを含む統合網におけるＴＣＰ（Ｔｒａｎｓｐｏｒｔ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）輻輳制御方法であって、
受信パケットにパケット損失が発生した移動ノードが、再転送されるパケットを受信する段階と、
前記移動ノードが、転送すべき確認応答パケットの数を計算する段階と、
前記移動ノードが、前記計算された数だけのマルチ確認応答パケットを生成し、送信ノードに転送する段階と、
前記送信ノードが受信したマルチ確認応答パケットに応じて、輻輳ウィンドウ値を増加させ、ＴＣＰ転送を行う段階と、
を含むことを特徴とするマルチＴＣＰ確認応答を用いたＴＣＰ輻輳制御方法。
【請求項２】
ネットワーク階層プロトコルに関係なく動作することを特徴とする請求項１に記載のマルチＴＣＰ確認応答を用いたＴＣＰ輻輳制御方法。
【請求項３】
前記ネットワーク階層プロトコルは、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）、ＩＰｖ６、無線ＩＰ、ＭＩＰｖ６（Ｍｏｂｉｌｅ  ＩＰｖ６）のうち少なくとも１つを含むことを特徴とする請求項２に記載のマルチＴＣＰ確認応答を用いたＴＣＰ輻輳制御方法。
【請求項４】
前記マルチ確認応答パケットを生成し、送信ノードに転送する段階は、
受信されたパケットのＴＣＰヘッダーに含まれたシーケンスナンバーと、現在まで受信されたパケットのシーケンスナンバーのうち最も大きい値である最大シーケンスナンバーと、を比較する段階と、
前記比較の結果、前記受信パケットのシーケンスナンバーが大きい場合には、現在受信されたパケットのシーケンスナンバーを、最大シーケンスナンバーにアップデートする段階と、
前記比較の結果、前記受信パケットのシーケンスナンバーが等しいか若しくは小さい場合には、マルチ確認応答パケットを生成する段階と、
を含むことを特徴とする請求項１に記載のマルチＴＣＰ確認応答を用いたＴＣＰ輻輳制御方法。
【請求項５】
前記マルチ確認応答パケットを生成する段階は、
前記移動ノードが、予想する次のパケットのシーケンスナンバーである予想シーケンスナンバーを計算する段階と、
前記移動ノードが、前記予想シーケンスナンバーから前記移動ノードが転送すべき前記マルチ確認応答パケットの全体長さである応答データ長さを計算する段階と、
前記移動ノードが生成及び転送しようとする確認応答パケットの個数を決定する段階と、
前記最終応答シーケンスから前記予想シーケンスナンバーに至るパケット区間を前記確認応答パケットの個数に均等に分割し、分割した確認応答パケット別の確認応答ナンバーフィールド値を算出する段階と、
前記算出した各パケット別確認応答フィールド値によって、各々の確認応答パケットを生成し、前記送信ノードに転送する段階と、
を含むことを特徴とする請求項４に記載のマルチＴＣＰ確認応答を用いたＴＣＰ輻輳制御方法。
【請求項６】
前記応答データ長さは、前記予想シーケンスナンバーから最終応答シーケンスを差し引いた値に設定されることを特徴とする請求項５に記載のマルチＴＣＰ確認応答を用いたＴＣＰ輻輳制御方法。
【請求項７】
前記予想シーケンスナンバーは、受信されたＴＣＰパケットのシーケンスナンバー、データ長さ、及び、ＴＣＰ制御ブロックの受信バッファ情報を用いて計算されることを特徴とする請求項６に記載のマルチＴＣＰ確認応答を用いたＴＣＰ輻輳制御方法。
【請求項８】
前記確認応答パケットの個数は、前記移動ノードが現在受信可能なバッファのサイズである告知ウィンドウ（ａｄｖｅｒｔｉｓｅｄ  ｗｉｎｄｏｗ）値を前記移動ノードが受信可能なデータの最大サイズである最大セグメントサイズで除した値に設定されることを特徴とする請求項５に記載のマルチＴＣＰ確認応答を用いたＴＣＰ輻輳制御方法。
【請求項９】
前記確認応答ナンバーフィールド値は、初期値として前記最終シーケンスナンバーを有し、前記確認応答ナンバーフィールド値が前記予想シーケンスナンバーと同一になるまで所定のサイズだけ増加しながら変更されることを特徴とする請求項５に記載のマルチＴＣＰ確認応答を用いたＴＣＰ輻輳制御方法。
【請求項１０】
前記所定のサイズは、前記応答データ長さを、前記確認応答パケットの個数で除した値に設定されることを特徴とする請求項９に記載のマルチＴＣＰ確認応答を用いたＴＣＰ輻輳制御方法。
【請求項１１】
無線リンクを含む統合網におけるＴＣＰ（Ｔｒａｎｓｐｏｒｔ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）輻輳制御方法であって、
移動ノードで受信したパケットのＴＣＰヘッダーに含まれたシーケンスナンバーと、現在まで受信されたパケットのシーケンスナンバーのうち最も大きい値である最大シーケンスナンバーと、を比較し、前記無線リンクを含む統合網においてＴＣＰパケット損失が発生したか否かを判断する段階と、
前記判断結果、ＴＣＰパケット損失が発生した場合には、
ａ）前記移動ノードが予想する次のパケットのシーケンスナンバーである予想シーケンスナンバーを計算する段階と、
ｂ）前記移動ノードが前記予想シーケンスナンバーから前記移動ノードが転送すべき前記マルチ確認応答パケットの全体長さである応答データ長さを計算する段階と、
ｃ）前記移動ノードが生成及び転送しようとする確認応答パケットの個数を決定する段階と、
ｄ）前記最終応答シーケンスから前記予想シーケンスナンバーに至るパケット区間を前記確認応答パケットの個数に均等に分割し、分割した確認応答パケット別確認応答ナンバーフィールド値を算出する段階と、
ｅ）前記算出した各パケット別確認応答フィールド値によって各々の確認応答パケットを生成し、前記送信ノードに転送する段階と、
を含むことを特徴とするマルチＴＣＰ確認応答を用いたＴＣＰ輻輳制御方法。
【請求項１２】
ネットワーク階層プロトコルに関係なく動作することを特徴とする請求項１１に記載のマルチＴＣＰ確認応答を用いたＴＣＰ輻輳制御方法。
【請求項１３】
前記ネットワーク階層プロトコルは、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）、ＩＰｖ６、無線ＩＰ、ＭＩＰｖ６（Ｍｏｂｉｌｅ  ＩＰｖ６）のうち少なくとも１つを含むことを特徴とする請求項１１に記載のマルチＴＣＰ確認応答を用いたＴＣＰ輻輳制御方法。
【請求項１４】
無線リンクを含む統合網に位置し、ＴＣＰ（Ｔｒａｎｓｐｏｒｔ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）を用いて通信する移動ノードであって、
受信したパケットのＴＣＰヘッダーに含まれたシーケンスナンバーと、現在まで受信されたパケットのシーケンスナンバーのうち最も大きい値である最大シーケンスナンバーと、を比較し、前記無線リンクを含む統合網においてＴＣＰパケット損失が発生したか否かを判断し、
前記判断結果、ＴＣＰパケット損失が発生した場合には、前記移動ノードで予想する次のパケットのシーケンスナンバーである予想シーケンスナンバー、前記移動ノードが転送すべき前記マルチ確認応答パケットの全体長さである応答データ長さ、及び、前記移動ノードで生成及び転送しようとする確認応答パケットの個数を計算し、
前記移動ノードが受信した最終応答シーケンスから前記予想シーケンスナンバーに至るパケット区間を前記確認応答パケットの個数に均等に分割し、分割した確認応答パケット別確認応答ナンバーフィールド値を算出し、確認応答パケット別確認応答ナンバーフィールド値による各々の確認応答パケットで構成されるマルチＴＣＰ確認応答パケットを生成し、送信ノードに転送することを特徴とするＴＣＰ輻輳を制御する移動ノード。
【請求項１５】
前記応答データ長さは、前記予想シーケンスナンバーから前記最終応答シーケンスを差し引いた値に設定されることを特徴とする請求項１４に記載のＴＣＰ輻輳を制御する移動ノード。
【請求項１６】
前記確認応答パケットの個数は、前記移動ノードが現在受信可能なバッファのサイズを、移動ノードが受信可能なデータの最大サイズである最大セグメントサイズで除した値に設定されることを特徴とする請求項１４に記載のＴＣＰ輻輳を制御する移動ノード。
【請求項１７】
前記確認応答ナンバーフィールド値は、初期値として前記最終シーケンスナンバーを有し、前記確認応答ナンバーフィールド値が前記予想シーケンスナンバーと同一になるまで所定のサイズだけ増加しながら変更されることを特徴とする請求項１４に記載のＴＣＰ輻輳を制御する移動ノード。
【請求項１８】
前記所定のサイズは、前記応答データ長さを、前記確認応答パケットの個数で除した値に設定されることを特徴とする請求項１７に記載のＴＣＰ輻輳を制御する移動ノード。
【請求項１９】
無線リンクを含む統合網に位置し、ＴＣＰ（Ｔｒａｎｓｐｏｒｔ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）輻輳制御（Ｃｏｎｇｅｓｔｉｏｎ  Ｃｏｎｔｒｏｌ）を用いて通信するノードであって、
パケット損失によるマルチ確認応答パケットを生成して転送する移動ノードから前記マルチ確認応答パケットを受信し、受信した確認応答パケットに応じて輻輳ウィンドウ値を増加させ、ＴＣＰ転送を行うことを特徴とするＴＣＰ輻輳制御実行ノード。
【請求項２０】
無線リンクを含む統合網においてＴＣＰ（Ｔｒａｎｓｐｏｒｔ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）輻輳制御（Ｃｏｎｇｅｓｔｉｏｎ  Ｃｏｎｔｒｏｌ）を行うシステムであって、
受信パケットにパケット損失が発生した移動ノードが再転送されるパケットを受信し、転送すべき確認応答パケットの数を計算し、該計算された数だけのマルチ確認応答パケットを生成して転送する受信ノードと、
前記受信ノードから前記マルチ確認応答パケットを受信し、受信した確認応答パケットに応じて輻輳ウィンドウ値を増加させ、ＴＣＰ転送を行う送信ノードと、
を含むことを特徴とするＴＣＰ輻輳制御実行システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチＴＣＰ確認応答を用いたＴＣＰ輻輳制御システム及びその方法に関し、より詳細には、有無線統合網において無線端末が有線網のサーバとＴＣＰ接続を通して通信を行うにあたって、無線端末の移動により発生するパケット損失によるＴＣＰ終端間の性能低下を防止するために、マルチＴＣＰＡＣＫパケットを用いて既存のＴＣＰ輻輳制御方法の問題点を解決することができるマルチＴＣＰ確認応答を用いたＴＣＰ輻輳制御システム及びその方法に関する。
【背景技術】
【０００２】
有無線統合環境において、無線端末（Ｍｏｂｉｌｅ  Ｎｏｄｅ、以下、ＭＮという）は、ウェブ、電子メールなどインターネットサービスを利用するために、有線網のサーバ（Ｃｏｒｒｅｓｐｏｎｄｅｎｔ  Ｎｏｄｅ、以下、ＣＮという）からＴＣＰ接続を通してサービスを提供される。一方、ＭＮの移動性によるＴＣＰ接続の流れが切れないようにするために、移動ＩＰプロトコルを使用する。
【０００３】
最近、携帯用端末機の普及が増加するに伴って、いつでも、どこでも無線端末を用いてインターネットサービスを利用しようとするユーザの欲求が次第に増加している。しかしながら、ＭＮとＣＮ間のデータ転送のために多く使われているＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）は、パケット損失率が相対的に低い有線網と固定端末機のみを考慮して設計されたものである。したがって、性能が低く、終端間の遅延度（ｌａｔｅｎｃｙ）が長く、且つパケット損失率が高いため、ハンドオフに起因するパケット損失がしきりに発生する無線網または有無線統合網に使用する場合には、終端間の性能低下をもたらすなどいろいろな問題点を有している。
【０００４】
既存のＴＣＰプロトコルは、有線網及び固定網を考慮して設計された。既存の有線網は、パケット損失率が低く、接続切れ現象も少ない。したがって、有線網におけるパケット損失は、大部分、ネットワークの中間ノードにおいてバッファオーバーフローなどによる輻輳現象に起因して発生する。これにより、ＴＣＰプロトコルでは、信頼性の高いサービスを提供するために、低速起動と輻輳回避など輻輳制御アルゴリズムを行い、ネットワークに流入するデータの量を低減することによって、これ以上の輻輳現象が発生しないようにする。
【０００５】
輻輳制御（Ｃｏｎｇｅｓｔｉｏｎ  Ｃｏｎｔｒｏｌ）は、ネットワーク装備が処理できる能力以上に入力されるトラフィック又は特定のポートに集中したトラフィックにより発生する輻輳現象、すなわち装備が続いて過負荷状態にあることを解決する技術を言う。
【０００６】
ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）の輻輳制御（Ｃｏｎｇｅｓｔｉｏｎ  Ｃｏｎｔｒｏｌ）メカニズムは、１９８８年のＴＣＰ  Ｔａｈｏｅ以来、１９９０年のＴＣＰ  Ｒｅｎｏ、１９９５年のＴＣＰ  Ｖｅｇａｓに至るまで多様なバージョンで実現された。ＴＣＰの輻輳制御メカニズムの基本的なアルゴリズムは、低速起動（Ｓｌｏｗ  Ｓｔａｒｔ）、輻輳回避（Ｃｏｎｇｅｓｔｉｏｎ  Ａｖｏｉｄａｎｃｅ）、高速再転送（Ｆａｓｔ  Ｒｅｔｒａｎｓｍｉｔ）を含む。
【０００７】
ＴＣＰ輻輳制御の主な目的は、送信端末の転送率を直接制御することで、輻輳により損失されたデータを再転送することである。ＴＣＰは、ＯＳＩ参照モデルの４階層に属するプロトコルであって、送信端末と受信端末間のノードの数に関係無く終端間に動作する。ＴＣＰは、送信端末及び受信端末を両端とする１つのループ（ｌｏｏｐ）を形成し、このループに受信側が転送する確認（Ａｃｋｎｏｗｌｅｄｇｅ）情報とウィンドウ（Ｗｉｎｄｏｗ）、そしてタイムアウト（ｔｉｍｅｏｕｔ）機能を用いて輻輳制御メカニズムを具現している。
【０００８】
ＴＣＰ  Ｔａｈｏｅ以前のＴＣＰは、受信端末が知らせるウィンドウのサイズに相当分のセグメントを転送することによって、接続（ｃｏｎｎｅｃｔｉｏｎ）を行い、転送を始めた。すなわち、受信端末が知らせるウィンドウのサイズが１つのセグメントのサイズより大きければ、始めから複数のセグメントを転送することが可能である。しかしながら、２つの終端端末間に輻輳（ｃｏｎｇｅｓｔｉｏｎ）が発生したり、速度が遅いリンクが存在すれば、中間のノード、すなわち一般的にルータは、パケットをバッファリングする必要が生じるが、この場合、途中に１つのルータでもバッファの容量が充分でない場合には、パケットの損失が発生する。損失が発生すれば、損失が発生したことを感知するための遅延と再転送による遅延が発生するので、ＴＣＰの処理率は、急激に減少する。これを輻輳崩壊（ｃｏｎｇｅｓｔｉｏｎ  ｃｏｌｌａｐｓｅ）という。
【０００９】
輻輳崩壊を解決するために、「パケットの保存（ｃｏｎｓｅｒｖａｔｉｏｎ  ｏｆ  ｐａｃｋｅｔｓ）」の原則が登場するようになった。この原則は、現在設定されている接続が平衡状態にあるということ、例えば、１つのパケットが完全に転送される前までは、新しいパケットを転送しない状態を意味する。理論的に、このような状態では、輻輳が発生することはないが、実際インターネットには輻輳が発生するようになり、その原因として、現在設定された接続が平衡状態に至っていないか、又は、送信端末が１つのパケットの転送が終了する前に新しいパケットを転送したか、又は、ネットワーク資源の限界によって現在の経路では平衡状態に至らない場合などが考えられる。
【００１０】
これらのうち、現在設定された接続が平衡状態に至っていない場合のために考案されたアルゴリズムが、低速起動（ＳｌｏｗＳｔａｒｔ）である。これは、低速で転送を開始して、現在設定された接続が平衡状態に至るようにするというものである。送信端末は、受信端末からの“Ａｃｋ”メッセージを受信しない状態では、新しいセグメントを転送することができず、受信端末もやはり送信端末が転送したセグメントが到着する前には、“Ａｃｋ”メッセージを転送することができないので、受信端末が転送する“Ａｃｋ”メッセージは、設定された接続の一種のタイマーの役割をすると考えることができる。
【００１１】
すなわち、同じデータサイズを有するセグメントを転送する場合には、転送速度が遅いリンクを通過するときに転送遅延が最も大きいので、そのときの遅延による間隔で“Ａｃｋ”を発生するようになり、したがって、送信端末はそれ以上の転送速度でセグメントを転送することができるとしても、“Ａｃｋ”が受信されない状況では、新しいセグメントを転送することができなくなる。
【００１２】
低速起動では、既存のＴＣＰに輻輳ウィンドウ（ｃｏｎｇｅｓｔｉｏｎ  ｗｉｎｄｏｗ：ｃｗｎｄ）が追加された。初めて接続が設定される場合、または輻輳によってセグメントの損失が発生した場合には、輻輳ウィンドウ（ｃｗｎｄ）の値は、１に初期化される。そして、送信端末は、受信端末が知らせるウィンドウと輻輳ウィンドウ（ｃｗｎｄ）のうち小さい値に送信ウィンドウのサイズを決定する。
【００１３】
受信端末からの“Ａｃｋ”が転送されるとき毎に、輻輳ウィンドウ（ｃｗｎｄ）の値は、１ずつ増加する。すなわち、送信端末が新しい接続を設定し、１つのセグメントを転送した後、このセグメントに対する“Ａｃｋ”を受信すれば、送信端末は、２個のセグメントを転送することができる。そして、仮に、これら２個のセグメントに対する“Ａｃｋ”が受信されれば、さらに４個のセグメントを転送することができ、次には、８個、１６個のように指数的に増加するようになる。輻輳ウィンドウ（ｃｗｎｄ）は、このような方式で増加しながら、低速起動閾値（Ｗｔ、以下、Ｗｔという）に到達すれば、輻輳回避（ｃｏｎｇｅｓｔｉｏｎ  ａｖｏｉｄａｎｃｅ）が動作する。
【００１４】
送信端末と受信端末間に発生するパケットの流失は、物理的な誤謬または輻輳によるバッファリング過程でのバッファ空間の不足から発生する。最近、転送技術及び媒体が発展するに伴って、物理的に損失する比率は非常に低くなったが、大部分のパケット損失は、輻輳によるものと考えることができる。もちろん、この仮定は、相対的に高い転送誤謬確率を有する無線リンクの場合には成立しない。
【００１５】
輻輳回避は、輻輳が発生した旨を知らせる過程と、輻輳が発生した場合、現在のネットワークの使用を減少させる過程により動作する。低速起動と輻輳回避は、別個のアルゴリズムであるが、共に動作する。
【００１６】
新しい接続を設定するとき、初期の輻輳ウィンドウ（ｃｗｎｄ）の値は、１セグメントに設定される。輻輳が発生した場合には、現在の輻輳ウィンドウ（ｃｗｎｄ）サイズの１／２値をＷｔに設定する。輻輳の原因がタイムアウトによる場合には、輻輳ウィンドウ（ｃｗｎｄ）の値は、さらに１になり、低速起動状態となる。輻輳が発生しない場合には、輻輳ウィンドウ（ｃｗｎｄ）の値が続いて増加するようになるが、増加する方式は、現在の状態が低速起動輻輳ウィンドウ又は輻輳回避輻輳ウィンドウによって異なる。仮に、低速起動である場合には、前述したように、毎度“Ａｃｋ”が受信される時毎に、輻輳ウィンドウ（ｃｗｎｄ）の値を１ずつ増加させ、輻輳ウィンドウ（ｃｗｎｄ）の値が現在設定されたＷｔ値と同一になれば、以後には、輻輳回避状態に進入するようになる。
【００１７】
輻輳回避状態では、“Ａｃｋ”が受信される時毎に、輻輳ウィンドウ（ｃｗｎｄ）を「１／輻輳ウィンドウ」サイズずつ増加させる。これは、低速起動での輻輳ウィンドウ（ｃｗｎｄ）の増加が指数的であるのに対して、線形的な増加であると言える。
【００１８】
再転送閾値（ｒｅｔｒａｎｓｍｉｔ  ｔｈｒｅｓｈｏｌｄ）以上の重複Ａｃｋを受信する場合、ＴＣＰは、再転送タイマーに関係無く、該当セグメントをすぐに再転送するようになるが、これを高速再転送（Ｆａｓｔ  Ｒｅｔｒａｎｓｍｉｔ）という。ここで、重複Ａｃｋは、例えば、時間超過以前にＡｃｋが到着しない送信ＴＣＰによって発生する。
【００１９】
再転送タイマーは、損失または損傷されて廃棄されるセグメントを処理するためにＴＣＰが保有するタイマーであり、再転送時間は、１つのセグメントを転送し、確認応答（Ａｃｋ）を待つ時間として定義される。ＴＣＰは、セグメントを転送した後、該当セグメントのための再転送タイマーを駆動する。タイマーが終了する前に、特定のセグメントに対する確認応答が受信されれば、そのタイマーは消滅され、応答が受信される前にタイマーが終了すれば、該当セグメントは再転送され、タイマーは初期化される。
【００２０】
例えば、再転送閾値が３なら、３個の連続した複製Ａｃｋが受信される場合、送信端末は、該当セグメントが損失されたものと判断し、転送されるべき該当端末を再転送するようになる。
【００２１】
以上説明したような有線網における輻輳制御とは異なって、無線リンクでは、ＢＥＲ（Ｂｉｔ  Ｅｒｒｏｒ  Ｒａｔｅ）が有線リンクに比べて比較的高く、制限された帯域幅を有していて、ハンドオフ現象がしきりに発生する。したがって、有線網におけるパケット損失は、中間ルータにおいての輻輳現象によるが、無線リンクが含まれた環境では、パケット損失が主に無線リンクの高いＢＥＲまたはハンドオフに起因して発生する。
【００２２】
このような理由で、無線リンクでは、パケット損失が発生した場合には、送信側では一層早くパケットを転送しなければならないが、現在のＴＣＰ送信側では、無線リンクに発生したパケット損失がネットワークの輻輳に起因したものと判断し、輻輳制御アルゴリズムを行い、ＴＣＰの転送速度を低下させる。これにより、ＴＣＰプロトコルの性能は、急激に低下し、ネットワークの効率も低下するようになる。
【００２３】
図１は、一般的なＴＣＰ輻輳制御アルゴリズムを有無線統合網に適用する場合のパケット損失過程を示す。
【００２４】
すなわち、図１は、ＴＣＰプロトコルに使われる輻輳制御アルゴリズムを有無線統合網にそのまま適用する場合、性能低下現象が発生する原因を示す。まず、ＣＮ１００から転送されたデータは、基地局（Ｂａｓｅ  Ｓｔａｔｉｏｎ）１２０を経てＭＮ２００に伝達される。ＭＮ２００では、それに対する応答と共に相当するデータを転送するが、無線リンク上でパケット崩壊（Ｃｏｒｒｕｐｔ  １）が発生し、ＣＮ１００では、タイムアウト期間の間に“Ａｃｋ”パケットを受信しないようになる。これにより、ＣＮ１００では、ネットワークにおいて輻輳が発生したものと誤認して、輻輳制御アルゴリズムである低速起動と輻輳回避アルゴリズムを動作させて、輻輳ウィンドウ（ｃｗｎｄ）のサイズを１に再設定するようになる。
【００２５】
ここで、輻輳ウィンドウ値は、前述したように、ＴＣＰで相手方の応答無く転送することができる最大のパケット個数であるから、輻輳ウィンドウ（ｃｗｎｄ）が小さければ小さいほどＴＣＰの転送速度が遅くなるようになり、ＴＣＰの性能が低下する。また、ＣＮ１００でも、転送されたデータに対する応答が無線リンク上で崩壊され（Ｃｏｒｒｕｐｔ  ２）、タイムアウト以内にそれに対する“Ａｃｋ”パケットを受信しなければ、輻輳制御アルゴリズムが動作するので、ＭＮ２００のＴＣＰ性能が大きく低下するようになる。
【００２６】
したがって、既存に一般的に使われたＴＣＰ輻輳制御アルゴリズムを有無線統合網に適用する場合、ネットワークでは、輻輳が発生しなかったにもかかわらず、無線網の高いパケット損失率に起因して、ＴＣＰの性能が大きく低下する現象が発生する。ここで、無線リンクが含まれるネットワークにおけるＴＣＰ輻輳制御アルゴリズムに対する修正の必要性が求められている。
【発明の開示】
【発明が解決しようとする課題】
【００２７】
本発明は、前述のような問題点を解決するためになされたもので、本発明の目的は、既存のＴＣＰ輻輳制御メカニズムを変更して、損失されたパケットを受信する移動端末側でマルチＴＣＰ確認応答を生成し、送信端末に転送し、送信端末は、それによるＴＣＰ転送を行うことによって、ＴＣＰの性能低下を迅速に復旧することができるマルチＴＣＰ確認応答を用いたＴＣＰ輻輳制御システム及び方法を提供することにある。
【課題を解決するための手段】
【００２８】
上記目的を達成するために、本発明の一態様に係るマルチＴＣＰ確認応答を用いたＴＣＰ輻輳制御方法は、受信パケットにパケット損失が発生した移動ノードが、再転送されるパケットを受信する段階と、移動ノードが、転送すべき確認応答パケットの数を計算する段階と、移動ノードが、計算された数だけのマルチ確認応答パケットを生成し、送信ノードに転送する段階と、送信ノードが受信したマルチ確認応答パケットに応じて、輻輳ウィンドウ値を増加させ、ＴＣＰ転送を行う段階とを含む。
【００２９】
上記方法は、ネットワーク階層プロトコルに関係なく動作し、上記ネットワーク階層プロトコルは、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）、ＩＰｖ６、無線ＩＰ、ＭＩＰｖ６（Ｍｏｂｉｌｅ  ＩＰｖ６）のうち少なくとも１つを含む。
【００３０】
上記マルチ確認応答パケットを生成し、送信ノードに転送する段階は、受信されたパケットのＴＣＰヘッダーに含まれたシーケンスナンバーと、現在まで受信されたパケットのシーケンスナンバーのうち最も大きい値である最大シーケンスナンバーと、を比較する段階と、比較の結果、受信パケットのシーケンスナンバーが大きい場合には、現在受信されたパケットのシーケンスナンバーを、最大シーケンスナンバーにアップデートする段階と、比較の結果、受信パケットのシーケンスナンバーが等しいか若しくは小さい場合には、マルチ確認応答パケットを生成する段階とを含む。
【００３１】
上記マルチ確認応答パケットを生成する段階は、移動ノードが、予想する次のパケットのシーケンスナンバーである予想シーケンスナンバーを計算する段階と、移動ノードが、予想シーケンスナンバーから移動ノードが転送すべきマルチ確認応答パケットの全体長さである応答データ長さを計算する段階と、移動ノードが生成及び転送しようとする確認応答パケットの個数を決定する段階と、最終応答シーケンスから予想シーケンスナンバーに至るパケット区間を確認応答パケットの個数に均等に分割し、分割した確認応答パケット別の確認応答ナンバーフィールド値を算出する段階と、算出した各パケット別確認応答フィールド値によって、各々の確認応答パケットを生成し、送信ノードに転送する段階とを含む。
【００３２】
上記応答データ長さは、予想シーケンスナンバーから最終応答シーケンスを差し引いた値に設定され、予想シーケンスナンバーは、受信されたＴＣＰパケットのシーケンスナンバー、データ長さ及びＴＣＰ制御ブロックの受信バッファ情報を用いて計算される。
【００３３】
上記確認応答パケットの個数は、移動ノードが現在受信可能なバッファのサイズである告知ウィンドウ（ａｄｖｅｒｔｉｓｅｄ  ｗｉｎｄｏｗ）値を移動ノードが受信可能なデータの最大サイズである最大セグメントサイズで除した値に設定される。
【００３４】
上記確認応答ナンバーフィールド値は、初期値として最終シーケンスナンバーを有し、確認応答ナンバーフィールド値が予想シーケンスナンバーと同一になるまで所定のサイズだけ増加しながら変更される。
【００３５】
上記所定のサイズは、応答データ長さを確認応答パケットの個数で除した値に設定される。
【００３６】
また、本発明の他の態様に係るマルチＴＣＰ確認応答を用いたＴＣＰ輻輳制御方法は、移動ノードで受信したパケットのＴＣＰヘッダーに含まれたシーケンスナンバーと、現在まで受信されたパケットのシーケンスナンバーのうち最も大きい値である最大シーケンスナンバーと、を比較し、無線リンクを含む統合網においてＴＣＰパケット損失が発生したか否かを判断する段階と、判断結果、ＴＣＰパケット損失が発生した場合には、ａ）移動ノードが予想する次のパケットのシーケンスナンバーである予想シーケンスナンバーを計算する段階と、ｂ）移動ノードが予想シーケンスナンバーから移動ノードが転送すべきマルチ確認応答パケットの全体長さである応答データ長さを計算する段階と、ｃ）移動ノードが生成及び転送しようとする確認応答パケットの個数を決定する段階と、ｄ）最終応答シーケンスから予想シーケンスナンバーに至るパケット区間を確認応答パケットの個数に均等に分割し、分割した確認応答パケット別確認応答ナンバーフィールド値を算出する段階と、ｅ）算出した各パケット別確認応答フィールド値によって各々の確認応答パケットを生成し、送信ノードに転送する段階とを含む。
【００３７】
また、本発明のさらに他の態様に係るＴＣＰ輻輳を制御する移動ノードは、受信したパケットのＴＣＰヘッダーに含まれたシーケンスナンバーと、現在まで受信されたパケットのシーケンスナンバーのうち最も大きい値である最大シーケンスナンバーと、を比較し、無線リンクを含む統合網においてＴＣＰパケット損失が発生したか否かを判断し、判断結果、ＴＣＰパケット損失が発生した場合には、移動ノードで予想する次のパケットのシーケンスナンバーである予想シーケンスナンバー、移動ノードが転送すべきマルチ確認応答パケットの全体長さである応答データ長さ、及び、移動ノードで生成及び転送しようとする確認応答パケットの個数を計算し、移動ノードが受信した最終応答シーケンスから予想シーケンスナンバーに至るパケット区間を確認応答パケットの個数に均等に分割し、分割した確認応答パケット別確認応答ナンバーフィールド値を算出し、確認応答パケット別確認応答ナンバーフィールド値による各々の確認応答パケットで構成されるマルチＴＣＰ確認応答パケットを生成し、送信ノードに転送することを特徴とする。
【００３８】
また、本発明のさらに他の態様に係るＴＣＰ輻輳制御実行ノードは、パケット損失によるマルチ確認応答パケットを生成して転送する移動ノードからマルチ確認応答パケットを受信し、受信した確認応答パケットに応じて輻輳ウィンドウ値を増加させ、ＴＣＰ転送を行うことを特徴とする。
【００３９】
また、本発明のさらに他の態様に係るＴＣＰ輻輳制御実行システムは、無線リンクを含む統合網においてＴＣＰ（Ｔｒａｎｓｐｏｒｔ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）輻輳制御（Ｃｏｎｇｅｓｔｉｏｎ  Ｃｏｎｔｒｏｌ）を行うシステムであって、受信パケットにパケット損失が発生した移動ノードが再転送されるパケットを受信し、転送すべき確認応答パケットの数を計算し、該計算された数だけのマルチ確認応答パケットを生成して転送する受信ノードと、受信ノードからマルチ確認応答パケットを受信し、受信した確認応答パケットに応じて輻輳ウィンドウ値を増加させ、ＴＣＰ転送を行う送信ノードと、を含むことを特徴とする。
【発明の効果】
【００４０】
本発明は、ＴＣＰパケット損失が発生した場合に、受信側移動ノードを用いてマルチ確認応答パケットを転送することによって、ノードのネットワーク階層に関係なく、固定ノードのＴＣＰ階層をも変更する必要なく、無線環境におけるＴＣＰパケット損失によるＴＣＰ転送性能低下を迅速に復旧することができる利点を有する。
【発明を実施するための最良の形態】
【００４１】
本実施形態では、無線リンクが含まれたネットワークにおいて、ネットワーク階層でＩＰｖ６及び無線ＩＰｖ６を使用した場合、無線リンクでのエラー又はノードの移動によるハンドオフに起因して発生するパケット損失によりＴＣＰの終端間性能を低下させる問題を解決するためのメカニズムとして、マルチ（Ｍｕｌｔｉｐｌｅ）ＴＣＰ  Ａｃｋパケットを使用する方法を提案する。
【００４２】
本実施形態のマルチＴＣＰ確認応答生成方法は、送信側の輻輳ウィンドウ値が受信側で転送した有効なＡｃｋパケットの個数により増加するＴＣＰ輻輳制御アルゴリズムに着目したものであって、移動ノードのＴＣＰでハンドオフ完了後に受信されたＴＣＰパケットに対するＡｃｋ転送時、複数のＡｃｋメッセージを生成して転送し、送信側では、複数のＡｃｋメッセージを受信することによって、１に減少した輻輳ウィンドウ値を速かに増加させることによって、ＴＣＰの性能を迅速に復元することをその核心内容とする。
【００４３】
本実施形態のマルチＴＣＰ確認応答生成方法の特徴は、簡単で且つ効果的にハンドオフによるＴＣＰの性能低下を補償することができ、移動ノードに容易に適用することができるという点である。
【００４４】
以下、添付の図面を参照して、本発明の好ましい実施形態を詳細に説明する。
【００４５】
図２は、本実施形態の有無線統合ネットワークの全体的な構成を示す。
【００４６】
図２の有無線統合ネットワークは、インターネット網を中心にして、左側は、有線リンクに接続しており、右側には、移動通信網と代表される無線リンクに接続している。
【００４７】
ＭＮ（Ｍｏｂｉｌｅ  Ｎｏｄｅ）２００は、図２の有無線統合ネットワークのうち無線ネットワーク内に位置する移動ノードを示し、図２に示されるように、モバイルホスト（Ｍｏｂｉｌｅ  Ｈｏｓｔ）や無線ノートブックなどを例示することができ、基地局１２０を介してインターネットに連動している。
【００４８】
ＣＮ（Ｃｏｒｒｅｓｐｏｎｄｅｎｔ  Ｎｏｄｅ）１００は、相手方ＴＣＰピア（Ｐｅｅｒ）ノードを示すもので、それ自体は、移動ノードまたは固定ノードのいずれも可能であるが、図２のネットワークでは、固定ノードだけで表現されている。図２のＣＮ１００は、有線リンクに接続している電子メールサーバ、ウェブサーバ、固定ホスト（Ｆｉｘｅｄ  Ｈｏｓｔ）などであることができる。
【００４９】
本実施形態が適用される図２のネットワーク内のＭＮ２００とＣＮ１００は、ＴＣＰ通信をすると仮定し、後述する本実施形態は、主にＣＮ１００を送信側、ＭＮ２００を受信側にしてＴＣＰパケットを転送する状況を仮定している。
【００５０】
図３は、本実施形態のマルチＴＣＰ確認応答生成方法の動作プロトコルスタックを示す。
【００５１】
図３は、ＴＣＰ／ＩＰ階層モデルにおいて本実施形態のマルチＴＣＰ確認応答生成方法を提供するＭＴＡＧモジュール２１０の位置を示している。
【００５２】
ＴＣＰ／ＩＰ階層モデルでは、最下位層に物理的にデータを転送するためのハードウェアを設けており、ハードウェア上位にネットワークインタフェース（データリンク）階層が位置する。ネットワークインタフェース階層は、イーサネット（登録商標）などのデータリンクを介して通信をするためのインタフェースとなる階層である。
【００５３】
ネットワークインタフェース階層の上位には、ネットワーク階層（インターネット階層）が存在するが、ここでは、ＩＰプロトコルが使われる。ＩＰプロトコルは、ＩＰアドレスに基づいてパケットを転送する。ＣＮ１００の場合には、固定網に接続していると仮定したので、ＩＰまたはＩＰｖ６などが使われ、ＭＮ２００は、ＩＰ／ＩＰｖ６の他に無線環境のためのＭＩＰ（Ｍｏｂｉｌｅ  ＩＰ）／ＭＩＰｖ６をも使用しなければならない。
【００５４】
ネットワーク階層の上位には、トランスポート階層が位置する。トランスポート階層の最も重要な役割は、アプリケーションプログラム間の通信を実現することである。本実施形態のＭＴＡＧモジュール２１０は、トランスポート階層に位置している。本実施形態では、ＭＮ２００が受信側となるものと仮定したので、ＭＴＡＧモジュール２１０は、ＭＮ２００のトランスポート階層に位置している。ＣＮ１００とＭＮ２００との両方について、トランスポート階層の上位には、アプリケーション階層が存在する。
【００５５】
図３に示されるように、本実施形態のマルチＴＣＰ確認応答生成方法は、ＭＮ２００のＴＣＰ階層で受信されたパケットを処理する場合に適用するようになる。ＭＮ２００は、マルチＴＣＰ確認応答生成方法を実現するＭＴＡＧ（Ｍｕｌｔｉｐｌｅ  ＴＣＰ  ＡＣＫｓ  Ｇｅｎｅｒａｔｉｏｎ）モジュール２１０を含む。ＭＴＡＧモジュール２１０は、ハンドオフによるＴＣＰ性能低下を早く復旧できるように、ＴＣＰ輻輳制御プロトコルを修正及び補完する機能を提供する。
【００５６】
図３から分かるように、本実施形態のマルチＴＣＰ確認応答生成方法は、ネットワーク階層で使われるプロトコルであるＩＰｖ４／ＩＰｖ６環境に全て適用することができる。すなわち、本実施形態のマルチＴＣＰ確認応答生成方法は、ＭＮ２００のＴＣＰ階層で動作するので、ネットワーク階層プロトコルに独立的である。
【００５７】
図４は、本実施形態のマルチＴＣＰ  Ａｃｋ生成方法を用いた移動ノードの受信パケット処理過程を示す。
【００５８】
ＭＮ２００のＴＣＰ階層では、最大シーケンスナンバー（ｍａｘ＿ｓｅｑ＿ｎｏ）という変数を置き、現在まで受信されたパケットの最大シーケンスナンバーを保存する。ＭＮ２００が、ＣＮ１００から転送されるＴＣＰパケットを受信した場合には（ステップ４０１。図中ではステップをＳと略す。）、ＭＮ２００は、受信されたパケットのＴＣＰヘッダーの、シーケンスナンバーフィールド（ｓｅｑ＿ｎｏ）値と、最大シーケンスナンバーと、を比較し（ステップ４０２）、受信されたパケットのシーケンスナンバーが、最大シーケンスナンバーより大きい場合には、ＭＮ２００は、正常のパケットが受信されたものと判定し、現在受信されたパケットのシーケンスナンバーを、最大シーケンスナンバーに再設定する（ステップ４０３）。すなわち、ＭＮ２００は、正常に到着したパケットに対しては、最大シーケンスナンバーを、シーケンスナンバーにアップデートし、受信データ処理段階に進行する（ステップ４０５）。
【００５９】
ここで、ＴＣＰセグメントのシーケンスナンバー（Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ）とは、該当ＴＣＰセグメントに含まれたデータの１番目のバイトに付与された番号を示す。ＴＣＰは、信頼性ある接続を保証するために伝達される各バイト毎に番号を付与するが、シーケンスナンバーは、目的地ＴＣＰにセグメントの１番目のバイトがこの順序番号に該当するバイトであることを知らせる。
【００６０】
受信されたパケットのシーケンスナンバーが、最大シーケンスナンバーより小さいか又は同じ場合には、再転送されるパケットが受信されたことを意味する。パケットが再転送されるということは、ＭＮ２００の移動によりハンドオフが発生したり、無線リンクのエラーによるパケット損失が発生したりして、送信側ＴＣＰで再転送タイマーが満了（ｅｘｐｉｒｅ）したからである。ＣＮ１００のＴＣＰ階層で再転送が発生すれば、輻輳ウィンドウ（ｃｗｎｄ）値が１又は半分に減少するので、ＴＣＰの転送速度が減少する。ＣＮ１００から再転送されたパケットの処理は、ＭＮ２００側ＴＣＰ階層のＭＴＡＧ処理モジュール２１０で担当する（ステップ４０４）。
【００６１】
ＭＴＡＧモジュール２１０は、マルチＡＣＫパケットを生成し、ＣＮ１００に転送した後、受信されたパケットを受信データ処理段階に進行する（ステップ４０５）。すなわち、ＭＴＡＧモジュール２１０は、ＭＮ２００のＴＣＰ階層で転送すべき応答パケットを用いて新しいデータを応答する多数のＴＣＰ  Ａｃｋパケットを生成し、ＣＮ１００に転送し、ＣＮ１００側ＴＣＰの輻輳ウィンドウ（ｃｗｎｄ）値が早くハンドオフ以前の値に復帰する。
【００６２】
図５は、本実施形態の移動ノードのＭＴＡＧモジュールの具体的な動作を示すフローチャートである。
【００６３】
ＭＴＡＧモジュール２１０の中心的な動作については既に説明したので、図５では、ＭＴＡＧモジュール２１０に関する具体的で且つ詳細な動作について詳細に説明する。
【００６４】
まず、ＭＴＡＧモジュール２１０に使われる変数について説明する。
【００６５】
予想シーケンスナンバー（ａｃｋ＿ｓｅｑ＿ｎｏ）：ＭＮ２００で予想する次のパケットのシーケンスナンバー
【００６６】
最終応答シーケンス（ｌａｓｔ＿ａｃｋ＿ｓｅｑ）：ＭＮ２００が最終的に転送したＴＣＰＡＣＫパケットの確認応答（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）ナンバーフィールドの値
【００６７】
応答データ長さ（ａｃｋ＿ｄａｔａ＿ｌｅｎ）：ＭＮ２００がＣＮ１００に転送すべき全体ＡＣＫパケットの長さ
【００６８】
マルチ応答シーケンス（ｍｕｌｔｉ＿ａｃｋ＿ｓｅｑ）：ＭＮ２００がＣＮ１００に転送すべきＡＣＫパケットの確認応答ナンバーフィールド値
【００６９】
Ｎ：ＭＮ２００で生成及び転送しようとするＡＣＫパケットの個数
【００７０】
上記変数を使用してＭＴＡＧモジュール２１０が、図５のように動作する。
【００７１】
ＡＣＫパケットを１つ転送する代わりに、多数の有効なＡＣＫパケットを生成するために、まず、受信されたＴＣＰパケットのシーケンスナンバー、データ長さ及びＴＣＰ制御ブロックの受信バッファ情報を用いて、次の予想シーケンスナンバーを計算する（ステップ５０１）。このとき、予想シーケンスナンバーの計算は、既存のＴＣＰプロトコルで提示された方法により行われ、本実施形態では特別に他の方法を提案するものではない。
【００７２】
予想シーケンスナンバー値が求められると、受信ＴＣＰが応答すべきデータの長さである応答データ長さ（ａｃｋ＿ｄａｔａ＿ｌｅｎ）は、予想シーケンスナンバー（ａｃｋ＿ｓｅｑ＿ｎｏ）から最終応答シーケンス（ｌａｓｔ＿ａｃｋ＿ｓｅｑ）値を差し引いた値から求めることができる（ステップ５０２）。すなわち、“応答データ長さ（ａｃｋ＿ｄａｔａ＿ｌｅｎ）＝予想シーケンスナンバー（ａｃｋ＿ｓｅｑ＿ｎｏ）−最終応答シーケンス（ｌａｓｔ＿ａｃｋ＿ｓｅｑ）”として表現することができる。
【００７３】
応答データ長さ（ａｃｋ＿ｄａｔａ＿ｌｅｎ）、すなわち、受信ＴＣＰが転送すべきＡＣＫパケットの全体データ長さが定められると、転送するＡＣＫパケットを幾つかに区分して転送すべきかを決定しなければならないが、このとき、必要となるのがＮ値である。Ｎ値は、上記で定義した通り、ＭＮ２００で生成及び転送しようとするＡＣＫパケットの個数である。
【００７４】
Ｎ値は、任意に設定されるものではなく、告知ウィンドウ（ａｄｖｅｒｔｉｓｅｄ  ｗｉｎｄｏｗ：ａｗｎｄ）をＭＳＳ（Ｍａｘｉｍｕｍ  Ｓｅｇｍｅｎｔ  Ｓｉｚｅ：最大セグメントサイズ）で除した値に設定される（ステップ５０３）。その理由は、多数のＡＣＫパケットを無条件的に生成して転送する場合には、ネットワークの輻輳を招くことがあるので、ＭＮ２００の受信バッファサイズを考慮してＮ値を決定しなければならないからである。
【００７５】
ここで、告知ウィンドウ（ａｗｎｄ）は、受信ＴＣＰが、送信ＴＣＰに知らせる値であって、ＭＮ２００が、現在受信可能なバッファのサイズを示す。また、ＭＳＳ（最大セグメントサイズ）は、目的地が受信することができるデータの最大サイズを規定するＴＣＰヘッダーオプションであって、最大データサイズは、送信側と受信側間の接続設定段階中に決定される。最大データサイズは、セグメントの送信側でなく、受信側により決定される。
【００７６】
ＭＮ２００が転送すべきＡＣＫパケットの個数Ｎが定められると、転送するＡＣＫパケットの各々に含むフィールドの内容を決定しなければならない。
【００７７】
まず、最終応答シーケンス（ｌａｓｔ＿ａｃｋ＿ｓｅｑ）から予想シーケンスナンバー（ａｃｋ＿ｓｅｑ＿ｎｏ）に至る区間（［ｌａｓｔ＿ａｃｋ＿ｓｅｑ、ａｃｋ＿ｓｅｑ＿ｎｏ］）をＮ個の区間に分割する。そして、マルチ応答シーケンス（ｍｕｌｔｉ＿ａｃｋ＿ｓｅｑ）値を、最終応答シーケンス（ｌａｓ＿ａｃｋ＿ｓｅｑ）値に設定し（ステップ５０４）、変数ｎを１に初期セッティングする（ステップ５０５）。ここで、マルチ応答シーケンス（ｍｕｌｔｉ＿ａｃｋ＿ｓｅｑ）値は、後続の手続でＡＣＫパケットの確認応答ナンバーフィールドに挿入され、最終応答シーケンス値と変数ｎ及びＮ値を用いて計算される。
【００７８】
マルチ応答シーケンス（ｍｕｌｔｉ＿ａｃｋ＿ｓｅｑ）と変数ｎに対する初期化作業が終了後、ｎがＮより小さいか、または、同一であり（ｎ≦Ｎ）、マルチ応答シーケンス（ｍｕｌｔｉ＿ａｃｋ＿ｓｅｑ）が、予想シーケンスナンバー（ａｃｋ＿ｓｅｑ＿ｎｏ）より小さいか、または、同一である（マルチ応答シーケンス≦予想シーケンスナンバー）ことを条件として（ステップ５０６）、転送すべき各ＡＣＫパケットの確認応答番号を、マルチ応答シーケンス（ｍｕｌｔｉ＿ａｃｋ＿ｓｅｑ）値を用いて算出し、これを用いてＡＣＫパケットを転送する。
【００７９】
この過程で必要なマルチ応答シーケンス（ｍｕｌｔｉ＿ａｃｋ＿ｓｅｑ）値は、次の式１のように表現されることができる（ステップ５０７）。
【００８０】
（式１）
マルチ応答シーケンス（ｍｕｌｔｉ＿ａｃｋ＿ｓｅｑ）＝最終シーケンスナンバー（ｌａｓｔ＿ａｃｋ＿ｓｅｑ）＋ｎ×応答データ長さ（ａｃｋ＿ｄａｔａ＿ｌｅｎ）／Ｎ
【００８１】
ここで、ｎは、初期値として１を有する変数であり、Ｎは、ＭＮ２００が転送すべきＡＣＫパケットの個数であることは、既に説明した通りである。
【００８２】
マルチ応答シーケンス（ｍｕｌｔｉ＿ａｃｋ＿ｓｅｑ）値を求めると、ＡＣＫパケットの確認応答ナンバーフィールドにマルチ応答シーケンス（ｍｕｌｔｉ＿ａｃｋ＿ｓｅｑ）値を代入し、ＴＣＰ送信側ＣＮ１００に転送する（ステップ５０８）。１つのＡＣＫパケットを転送した後には、ｎ値を１だけ増加させ（ステップ５０９）、ステップ５０６からステップ５０９までを反復する。
【００８３】
すなわち、ＭＮ２００は、最終応答シーケンス（ｌａｓｔ＿ａｃｋ＿ｓｅｑ）から予想シーケンスナンバー（ａｃｋ＿ｓｅｑ＿ｎｏ）に至る区間の値を、Ｎ個の値で除し、マルチ応答シーケンスが、予想シーケンスナンバーと同じになるまでマルチ応答シーケンスの値を応答データ長さ（ａｃｋ＿ｄａｔａ＿ｌｅｎ）／Ｎずつ増加させながら、マルチ応答シーケンスをＡＣＫパケットの確認応答番号に設定した後、Ｎ個のＡＣＫパケットを生成し、ＣＮ１００に転送する。
【００８４】
ステップ５０６で、ｎがＮより小さいか、または、同一であり（ｎ≦Ｎ）、マルチ応答シーケンス（ｍｕｌｔｉ＿ａｃｋ＿ｓｅｑ）が予想シーケンスナンバーより小さいか、または、同一であるという条件を満足しない場合には、これにより、ＭＮ２００が転送すべき全てのＡＣＫパケットを転送した状態となるので、最終応答シーケンス（ｌａｓ＿ａｃｋ＿ｓｅｑ）を予想シーケンスナンバー（ａｃｋ＿ｓｅｑ＿ｎｏ）値にアップデートし（ステップ５１０）、受信パケット処理ルーチンに進入する（ステップ５１１）。
【００８５】
ここで、確認応答ナンバー（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ  ｎｕｍｂｅｒ）は、ＴＣＰセグメントの発信地ノードが相手側ノードから受信しようとするバイトの番号を定義する。仮にセグメントを受信した受信ノードが相手ノードからバイト番号ｘを成功的に受信した場合には、受信ノードは、確認番号をｘ＋１に定義する。
【００８６】
図６は、本実施形態のＭＴＡＧモジュールの動作を示す図である。
【００８７】
図６では、ハンドオフ又は無線リンクの特性によりパケット損失が発生し、ＣＮ１００のＴＣＰ再転送タイマーが終了し、ＣＮ１００で損失されたパケットを再転送する場合の例を仮定した。
【００８８】
ＣＮ１００がＭＮ２００にＴＣＰパケットを転送する過程で、基地局１２０からＭＮ２００に至る無線リンク区間において、ハンドオフに起因してシーケンスナンバー１０００以後のパケットが損失されたと仮定する。ＣＮ１００は、再転送タイマーの終了により輻輳ウィンドウ（ｃｗｎｄ）を１セグメントに設定し、シーケンスナンバーが１０００であるパケットから再転送するようになる。ＭＮ２００では、ＣＮ１００から再転送されたパケットを受信し、受信したパケットのシーケンスナンバーを分析する。この場合、受信されたパケットのうちシーケンスナンバーが１５００及び２０００であるパケットは既に受信したので、予想シーケンスナンバー（ａｃｋ＿ｓｅｑ＿ｎｏ）は、２５００であり、最終応答シーケンス（ｌａｓｔ＿ａｃｋ＿ｓｅｑ）は、１０００である。
【００８９】
図６では、告知ウィンドウ（ａｗｎｄ）が５０００バイトであり、目的地が受信できるデータの最大サイズを規定するＴＣＰヘッダーオプションであるＭＳＳ（Ｍａｘｉｍｕｍ  Ｓｅｇｍｅｎｔ  Ｓｉｚｅ）が５００である場合には、転送すべき応答パケット個数Ｎは、下記のように計算される。
【００９０】
Ｎ＝ａｗｎｄ／ＭＳＳ＝５０００／５０＝１０
【００９１】
したがって、ＭＮ２００では、シーケンスナンバー［１０００、２５００］区間のパケットをＮで除し、ＡＣＫ番号が１１５０、１３００、１４５０、…、２５００であるパケットをＣＮ１００に転送する。ＣＮ１００で新しいＡＣＫを受けたとき、始めには、低速起動（Ｓｌｏｗ  Ｓｔａｒｔ）により輻輳ウィンドウ（ｃｗｎｄ）値を１ずつ増加する。輻輳ウィンドウ（ｃｗｎｄ）値が、低速起動閾値を越えた場合は、輻輳回避アルゴリズムを適用して、輻輳ウィンドウ（ｃｗｎｄ）値を増加させる。
【図面の簡単な説明】
【００９２】
【図１】一般的なＴＣＰ輻輳制御アルゴリズムを有無線統合網に適用する場合のパケット損失過程を示す図である。
【図２】本実施形態の有無線統合ネットワークの全体的な構成を示す図である。
【図３】本実施形態のマルチＴＣＰ確認応答生成方法の動作プロトコルスタックを示す図である。
【図４】本実施形態のマルチメディアサービス制御を示すフローチャートである。
【図５】本実施形態の移動ノードのＭＴＡＧモジュールの具体的な動作流れを示すフローチャートである。
【図６】本実施形態のＭＴＡＧモジュール動作を示す図である。
【符号の説明】
【００９３】
１００  ＣＮ（Ｃｏｒｒｅｓｐｏｎｄｅｎｔ  Ｎｏｄｅ）
１２０  基地局（Ｂａｓｅ  Ｓｔａｔｉｏｎ）
２００  ＭＮ（Ｍｏｂｉｌｅ  Ｎｏｄｅ）
２１０  ＭＴＡＧ（Ｍｕｌｔｉｐｌｅ  ＴＣＰＡＣＫｓ  Ｇｅｎｅｒａｔｉｎｇ）モジュール
【図１】
2006222960.tif 000003
【図２】
2006222960.tif 000004
【図３】
2006222960.tif 000005
【図４】
2006222960.tif 000006
【図５】
2006222960.tif 000007
【図６】
2006222960.tif 000008