(57)【要約】  本発明は、ゲートウェイノードあるいは終端ノードで、ＴＣＰ同時転送の性能低下現象を改善する方法及び装置を提供するためのものである。本発明は、非対称帯域幅リンクを有する加入者網における転送制御プロトコル（ＴＣＰ）の両方向同時転送のための転送制御方法であって、両方向同時転送時、逆方向リンクで転送するための転送制御プロトコル（ＴＣＰ）ＡＣＫパケットを獲得する過程と、上記ＡＣＫパケットが獲得された時点に、上記逆方向リンクに対応する順方向リンクの帯域幅を測定する過程と、上記測定された帯域幅に従って上記順方向リンクの以後の帯域幅を予測し、上記予測された帯域幅が、上記順方向リンクに割り当てられた最大帯域幅に比べて上記順方向リンクを通じたＡＣＫパケットの転送を許容できる程度の余裕帯域幅を維持するようにする順方向リンクの最適ウィンドウサイズを計算する過程と、上記計算された最適ウィンドウサイズを上記ＡＣＫパケットに含まれる受信ウィンドウサイズとして挿入して、上記ＡＣＫパケットをデスティネーションノードに伝達する過程とを含むことを特徴とする。
2008536356.tif 000002
【特許請求の範囲】
【請求項１】
非対称帯域幅リンクを有する加入者網における転送制御プロトコル（ＴＣＰ）の両方向同時転送のための転送制御方法であって、
両方向同時転送時、逆方向リンクで転送するための転送制御プロトコル（ＴＣＰ）ＡＣＫパケットを獲得する過程と、
前記ＡＣＫパケットが獲得された時点に、前記逆方向リンクに対応する順方向リンクの帯域幅を測定する過程と、
前記測定された帯域幅に従って前記順方向リンクの以後の帯域幅を予測し、前記予測された帯域幅が、前記順方向リンクに割り当てられた最大帯域幅に比べて前記順方向リンクを通じたＡＣＫパケットの転送を許容できる程度の余裕帯域幅を維持するようにする順方向リンクの最適ウィンドウサイズを計算する過程と、
前記計算された最適ウィンドウサイズを前記ＡＣＫパケットに含まれる受信ウィンドウサイズとして挿入して、前記ＡＣＫパケットをデスティネーションノードに伝達する過程と
を含むことを特徴とする転送制御方法。
【請求項２】
前記ＡＣＫパケットを獲得する過程は、
前記加入者網の終端ノードで、前記ＡＣＫパケットを生成するものであることを特徴とする請求項１記載の転送制御方法。
【請求項３】
前記帯域幅を測定する過程は、
前記ＡＣＫパケットが受信された時点で、前記順方向リンクの帯域幅を推定する段階と、
予測遂行回数をカウントしながら、前記推定された帯域幅に基づいて前記順方向リンクの帯域幅を反復的に予測する段階と
を含むことを特徴とする請求項１記載の転送制御方法。
【請求項４】
前記最適ウィンドウサイズを計算する過程は、
前記予測遂行回数が予め決まる反復回数に到達するまで、前記予測された帯域幅が前記最大帯域幅を超過しなければ、前記反復回数を最適ウィンドウの最終推薦値として格納する段階と、
前記予測遂行回数が前記反復回数に到達する以前に前記予測された帯域幅が前記最大帯域幅に到達すれば、前記予測遂行回数と以前ＡＣＫパケットに対して格納された最適ウィンドウの最終推薦値のうち、大きい値に予め決まる最大転送ユニット（ＭＴＵ）サイズを掛けて前記最適ウィンドウサイズを計算する段階と
を含むことを特徴とする請求項３記載の転送制御方法。
【請求項５】
前記反復回数は、前記ＡＣＫパケットを含むＡＣＫされたパケットのデータ量を表す衝突ウィンドウエミュレーション値（emul_cwnd）を前記最大転送ユニット（ＭＴＵ）サイズで割った値であることを特徴とする請求項４記載の転送制御方法。
【請求項６】
前記最適ウィンドウサイズは、予め決まる最大衝突ウィンドウ値を超過しないように設定されることを特徴とする請求項５記載の転送制御方法。
【請求項７】
前記予測遂行回数が前記反復回数に到達するまで、前記予測された帯域幅が前記最大帯域幅を超過しなければ、前記ＡＣＫパケットの前記受信ウィンドウサイズを修正しなくて、前記デスティネーションノードに伝達する過程を更に含むことを特徴とする請求項４記載の転送制御方法。
【請求項８】
前記ＡＣＫパケットを獲得する過程は、前記加入者網のゲートウェイノードで、終端ノードにより生成された前記ＡＣＫパケットを受信するものであることを特徴とする請求項１記載の転送制御方法。
【請求項９】
前記ＡＣＫパケットを獲得する過程は、
前記ゲートウェイノードに引込されるインターネットプロトコル（ＩＰ）パケットを受信し、前記ＩＰパケットのヘッダに含まれたプロトコル識別子を参照して前記ＩＰパケットがＴＣＰパケットであるか否かを確認する段階と、
前記ＩＰパケットがＴＣＰパケットでなければ、前記ＩＰパケットをバイパスする段階と、
前記ＩＰパケットがＴＣＰパケットであれば、前記ＴＣＰパケットに含まれたソース及びデスティネーションのＩＰアドレスとポート番号によって、前記ＴＣＰパケットに関連したＴＣＰセッションが前記ゲートウェイノードに既に存在するか否かをを確認する段階と、
前記ＴＣＰセッションが存在しなければ、前記ＴＣＰパケットに関連した前記ＴＣＰセッションを追加し、前記ＴＣＰパケットをバイパスする段階と
を含むことを特徴とする請求項８記載の転送制御方法。
【請求項１０】
前記ＡＣＫパケットを獲得する過程は、
前記ＴＣＰセッションが存在すれば、前記ＴＣＰパケットに含まれたフラグのうち、ＡＣＫフラグのみ設定されているか否かを確認する段階と、
前記ＴＣＰパケットのＡＣＫフラグのみ設定されていなければ、前記ＴＣＰパケットをバイパスする段階と、
前記ＴＣＰパケットのＡＣＫフラグのみ設定されていれば、前記ＴＣＰパケットのサイズによって前記ＴＣＰパケットがＡＣＫパケットであるかデータパケットであるかを確認する段階と、
前記ＴＣＰパケットがデータパケットであれば、前記データパケットのサイズによって衝突ウィンドウエミュレーション初期値（init_emul_cwnd）を設定し、前記データパケットをバイパスする段階と、
前記ＴＣＰパケットがＡＣＫパケットであれば、前記衝突ウィンドウエミュレーション初期値が０より大きいか否かを確認する段階と、
前記衝突ウィンドウエミュレーション初期値が０より大きくなければ、前記ＡＣＫパケットをバイパスする段階と
を更に含むことを特徴とする請求項９記載の転送制御方法。
【請求項１１】
非対称帯域幅リンクを有する加入者網における転送制御プロトコル（ＴＣＰ）の両方向同時転送のための転送制御装置であって、
両方向同時転送時、逆方向リンクで転送するためのＴＣＰＡＣＫパケットを獲得するＴＣＰ分類部と、
前記ＡＣＫパケットが獲得された時点に、前記逆方向リンクに対応する順方向リンクの帯域幅を測定し、前記測定された帯域幅に従って前記順方向リンクの以後の帯域幅を予測し、前記予測された帯域幅が、前記順方向リンクに割り当てられた最大帯域幅に比べて前記順方向リンクを通じたＡＣＫパケットの転送を許容できる程度の余裕帯域幅を維持するようにする順方向リンクの最適ウィンドウサイズを計算する帯域幅推定／予測部と、
前記計算された最適ウィンドウサイズを前記ＡＣＫパケットに含まれる受信ウィンドウサイズとして挿入して、前記ＡＣＫパケットをデスティネーションノードに伝達する転送速度制御部と
を含むことを特徴とする転送制御装置。
【請求項１２】
前記ＴＣＰ分類部、前記帯域幅推定／予測部、及び前記転送速度制御部は、前記加入者網の終端ノードに備えられることを特徴とする請求項１１記載の転送制御装置。
【請求項１３】
前記帯域幅推定／予測部は、
前記ＡＣＫパケットが受信された時点で前記順方向リンクの帯域幅を推定し、
予測遂行回数をカウントしながら、前記推定された帯域幅に基づいて前記順方向リンクの帯域幅を反復的に予測することを特徴とする請求項１１記載の転送制御装置。
【請求項１４】
前記帯域幅推定／予測部は、
前記予測遂行回数が予め決まる反復回数に到達するまで、前記予測された帯域幅が前記最大帯域幅を超過しなければ、前記反復回数を最適ウィンドウの最終推薦値として格納し、
前記予測遂行回数が前記反復回数に到達する以前に前記予測された帯域幅が前記最大帯域幅に到達すれば、前記予測遂行回数と以前のＡＣＫパケットに対して格納された最適ウィンドウの最終推薦値のうち、大きい値に予め決まる最大転送ユニット（ＭＴＵ）サイズを掛けて、前記最適ウィンドウサイズを計算することを特徴とする請求項１３記載の転送制御装置。
【請求項１５】
前記反復回数は、前記ＡＣＫパケットを含むＡＣＫされたパケットのデータ量を表す衝突ウィンドウエミュレーション値（emul_cwnd）を前記最大転送ユニット（ＭＴＵ）サイズで割った値であることを特徴とする請求項１４記載の転送制御装置。
【請求項１６】
前記最適ウィンドウサイズは、予め決まる最大衝突ウィンドウ値を超過しないように設定されることを特徴とする請求項１５記載の転送制御装置。
【請求項１７】
前記転送速度制御部は、前記予測遂行回数が前記反復回数に到達するまで、前記予測された帯域幅が前記最大帯域幅を超過しなければ、前記ＡＣＫパケットの前記受信ウィンドウサイズを修正しなくて、前記デスティネーションノードに伝達することを特徴とする請求項１４記載の転送制御装置。
【請求項１８】
前記ＴＣＰ分類部、前記帯域幅推定／予測部、及び前記転送速度制御部は、
前記加入者網のゲートウェイノードに備えられることを特徴とする請求項１１記載の転送制御装置。
【請求項１９】
前記ＴＣＰ分類部は、
前記ゲートウェイノードにインターネットプロトコル（ＩＰ）パケットを受信し、前記ＩＰパケットのヘッダに含まれたプロトコル識別子を参照して、前記ＩＰパケットがＴＣＰパケットであるか否かを確認し、
前記ＩＰパケットがＴＣＰパケットでなければ、前記ＩＰパケットをバイパスし、
前記ＩＰパケットがＴＣＰパケットであれば、前記ＴＣＰパケットに含まれたソース及びデスティネーションのＩＰアドレスとポート番号によって、前記ＴＣＰパケットに関連したＴＣＰセッションが前記ゲートウェイノードに既に存在するか否かを確認し、
前記ＴＣＰセッションが存在しなければ、前記ＴＣＰパケットに関連した前記ＴＣＰセッションを追加し、前記ＴＣＰパケットをバイパスすることを特徴とする請求項１１記載の転送制御装置。
【請求項２０】
前記ＴＣＰ分類部と連結されるセッションパラメータ初期化部を更に含み、
前記セッションパラメータ初期化部は、
前記ＴＣＰセッションが存在すれば、前記ＴＣＰパケットに含まれたフラグのうち、ＡＣＫフラグのみ設定されているか否かを確認し、
前記ＴＣＰパケットのＡＣＫフラグのみ設定されていなければ、前記ＴＣＰパケットをバイパスし、
前記ＴＣＰパケットのＡＣＫフラグのみ設定されていれば、前記ＴＣＰパケットのサイズによって前記ＴＣＰパケットがＡＣＫパケットであるか、データパケットであるかを確認し、
前記ＴＣＰパケットがデータパケットであれば、前記データパケットのサイズによって衝突ウィンドウエミュレーション初期値（init_emul_cwnd）を設定した後、前記データパケットをバイパスし、
前記ＴＣＰパケットがＡＣＫパケットであれば、前記衝突ウィンドウエミュレーション初期値が０より大きいか否かを確認し、
前記衝突ウィンドウエミュレーション初期値が０より大きくなければ、前記ＡＣＫパケットをバイパスすることを特徴とする請求項１９記載の転送制御装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、加入者網（Asymmetric Subscriber Network）に関し、特に非対称帯域幅リンクを有する加入者網の終端ノードあるいはゲートウェイノードで、転送制御プロトコル（Transport Control Protocol；以下、ＴＣＰと称する）の両方向（bidirectional）同時転送性能を向上させるための転送制御方法及び装置に関する。
【背景技術】
【０００２】
広帯域コード分割多元接続（Wideband Code Division Multiple Access；以下、ＷＣＤＭＡと称する）、非対称デジタル加入者線路（Asymmetric Digital Subscriber Line；以下、ＡＤＳＬと称する）、無線広帯域インターネット（Wireless Broadband Internet；以下、Ｗｉｂｒｏと称する）は、上りリンクと下りリンクに対して帯域幅を予め割り当てる加入者網である。通常の加入者網は、インターネット上でパケットの転送のためにＴＣＰを使用するが、ＴＣＰは基本的に帯域幅が予め割り当てられた状況を考慮しなくて設計されたため、後述するいろいろ問題点を起こすことができる。
【０００３】
通常の加入者網は、各加入者別に使用可能な帯域幅を加入時、あるいは接続時に決定する。例えば、ＷＣＤＭＡの場合、パケットサービスのためのサービス品質（Quality of Service；以下、ＱｏＳと称する）等級（Class）と上り（Uplink）／下り（Downlink）最大ビット率（Maximum Bit rate）などが加入時に決定され、加入者が呼を試みる度に、上記ＱｏＳ等級と上記最大ビット率によって割り当てられた帯域幅だけの資源（Resource）のみを使用できるように制限する。
【０００４】
インターネットを通じたパケットサービスは、網から加入者端末へ向かう下りリンクのパケットトラフィック量が上りリンクのパケットトラフィック量より格段に多い場合が大部分である。したがって、多くの種類の加入者網は決まった帯域幅をより効率よく使用するために、下りリンクに対して上りリンクより多い帯域幅を割り当てており、このような加入者網を非対称（Asymmetric）加入者網と称する。例えば、ＷＣＤＭＡでは、上り６４Ｋｂｐｓ、下り３８４Ｋｂｐｓで加入者がアップロードとダウンロードを同時に遂行することができる。
【０００５】
ところが、ＴＣＰを利用したデータ転送において、非対称帯域幅リンクでは、特別に両方向転送時に深刻な性能低下をもたらしうる。具体的に、下り転送データに対するＡＣＫ（Acknowledge：Ａｃｋ）が上り転送データにより遅延されるＡＣＫクロッキング（Ack-clocking）現象が発生することになれば、これによって、下りリンク転送速度（downlink data rate）が上りリンク伝送速度程度に落ちることになる。
【０００６】
例えば、ネットワークのゲートウェイノードは予め決まるウィンドウ以内でＡＣＫなしに下りパケットを加入者ノードに連続して転送した後、上記下りパケットに対するＡＣＫを待つ。ところが、加入者ノードは、上りパケットを優先的に転送するために、上記下りパケットに対するＡＣＫの転送を遅延させる。このように、加入者ノードの転送バッファには、上りデータ転送のためのパケットが満たされているので、下りパケットに対するＡＣＫが転送できなければ、これによって、下りリンクの転送速度が上りリンクの転送速度程度に落ちることになる。
【０００７】
したがって、このような非対称帯域幅リンクの上で、両方向ＴＣＰ転送を支援するに当たって、一方リンクの転送速度が他方リンクの転送速度により減少することを防止するための技術を必要とすることになった。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
前述したように動作される従来技術の問題点を解決するために発案した本発明の目的は、非同期帯域幅リンクで、ＴＣＰ上り／下り同時転送の性能低下現象を改善する方法及び装置を提供することにある。
【０００９】
本発明の他の目的は、ゲートウェイノードあるいは終端ノードで、ＴＣＰ同時転送の性能低下現象を改善する方法及び装置を提供することにある。
【課題を解決するための手段】
【００１０】
本発明の望ましい実施形態は、非対称帯域幅リンクを有する加入者網における転送制御プロトコル（ＴＣＰ）の両方向同時転送のための転送制御方法であって、両方向同時転送時、逆方向リンクで転送するための転送制御プロトコル（ＴＣＰ）ＡＣＫパケットを獲得する過程と、上記ＡＣＫパケットが獲得された時点に、上記逆方向リンクに対応する順方向リンクの帯域幅を測定する過程と、上記測定された帯域幅に従って上記順方向リンクの以後の帯域幅を予測し、上記予測された帯域幅が、上記順方向リンクに割り当てられた最大帯域幅に比べて上記順方向リンクを通じたＡＣＫパケットの転送を許容できる程度の余裕帯域幅を維持するようにする順方向リンクの最適ウィンドウサイズを計算する過程と、上記計算された最適ウィンドウサイズを上記ＡＣＫパケットに含まれる受信ウィンドウサイズとして挿入して、上記ＡＣＫパケットをデスティネーションノードに伝達する過程とを含むことを特徴とする。
【００１１】
本発明の他の実施形態は、非対称帯域幅リンクを有する加入者網における転送制御プロトコル（ＴＣＰ）の両方向同時転送のための転送制御装置であって、両方向同時転送時、逆方向リンクで転送するためのＴＣＰＡＣＫパケットを獲得するＴＣＰ分類部と、上記ＡＣＫパケットが獲得された時点に、上記逆方向リンクに対応する順方向リンクの帯域幅を測定し、上記測定された帯域幅に従って上記順方向リンクの以後の帯域幅を予測し、上記予測された帯域幅が、上記順方向リンクに割り当てられた最大帯域幅に比べて上記順方向リンクを通じたＡＣＫパケットの転送を許容できる程度の余裕帯域幅を維持するようにする順方向リンクの最適ウィンドウサイズを計算する帯域幅推定／予測部と、上記計算された最適ウィンドウサイズを上記ＡＣＫパケットに含まれる受信ウィンドウサイズとして挿入して、上記ＡＣＫパケットをデスティネーションノードに伝達する転送速度制御部とを含むことを特徴とする。
【発明の効果】
【００１２】
以上、前述したように動作する本発明において、開示される発明のうち、代表的なことによって得られる効果を簡単に説明すれば、次の通りである。
【００１３】
本発明は、ＴＣＰ転送の間、一定のＴＣＰ転送帯域幅を使用するように制限することによって、ＴＣＰ転送の特徴であるスロースタート、衝突回避（congestion avoidance）などによる必須不可欠なパケットドロップ、即ち衝突発生を事前に防止する。
【００１４】
また、ＴＣＰ非対称帯域幅リンク状況の両方向同時転送時、上り／下り転送で、各々制限された転送速度だけの帯域幅のみを使用するため、ＡＣＫクロッキングによる歩留まり同期（throughput sync）が発生しなくなる。即ち、上り／下り各転送で、余裕分の帯域幅を通じて反対方向のＡＣＫが円滑に伝えられるようにすることで、より効率のよい帯域幅の使用が可能である。
【発明を実施するための最良の形態】
【００１５】
以下、添付図面に基づき、本発明の好適な実施形態についての動作原理を詳細に説明する。なお、本発明を説明するに当たり、関連のある公知の技術あるいは構成についての具体的な説明が本発明の要旨を余計に曖昧にする恐れのあると認められる場合、その詳細な説明は省かれる。さらに、後述する用語は本発明における機能を考慮して定義された用語であり、これらはユーザ、運用者の意図または慣例などによって変わることがある。よって、これらの用語の定義は、この明細書の全般に亘っての内容に基づいて行われるべきである。
【００１６】
後述する本発明の主要な要旨は、上り及び下りの各転送方向で予め決まるしきい値を超過しない転送速度でパケット転送がなされるようにし、残りの帯域幅を通じて反対方向にＡＣＫ転送がなされるようにするものである。このような本発明は、同時転送時にも各方向のＡＣＫ転送に影響を受けないで、固定された転送速度を保障する。
【００１７】
下記では、本発明の具体的な実施形態を説明するための帯域幅割り当て加入者網（Bandwidth pre-allocated subscriber network）の例として、ＷＣＤＭＡを使用する。このために、下記にＷＣＤＭＡ網の各ノードと参照点について説明する。
【００１８】
図１は、本発明が適用されるＷＣＤＭＡ網の構成図を概略的に示すものである。
【００１９】
上記図１を参照すれば、移動端末（Mobile station：ＭＳ）１０は、ＵＴＲＡＮ（UMTS（Universal Mobile Telecommunications System）Terrestrial Radio Access Network）２０と接続されて音声及びデータ呼（call）を処理し、回線サービス（ＣＳ：Circuit Service）とパケットサービス（ＰＳ：Packet Service）を共に支援する。図示しないが、ＵＴＲＡＮ２０は、基地局（Base Station or Node B）と、無線ネットワーク制御器（Radio Network Controller：ＲＮＣ）から構成される。上記基地局は、移動端末１０とＵｕインターフェース（Interface）を介して連結され、上記無線ネットワーク制御器は、コアネットワーク３０とＩｕインターフェースを介して連結される。上記コアネットワーク（Core Network）３０は、ＳＧＳＮ（Serving GPRS（General Packet Radio Service）Support Node）３２とＧＧＳＮ（Gateway GPRS Support Node）３４を通称するものである。
【００２０】
ＵＴＲＡＮ２０は、移動端末１０からエアー（air）上で転送された無線データ、あるいは制御メッセージ（control message）をＧＰＲＳトンネリングプロトコル（ＧＴＰ：GPRS Tunneling Protocol；以下，“ＧＴＰ”と称する）に従ってプロトコル変換を遂行する。ＧＰＲＳは、ＵＭＴＳネットワークで遂行するパケットデータサービスである。
【００２１】
ＳＧＳＮ３２は、移動端末１０の加入者情報と位置情報を管理するサービスノードであって、ＵＴＲＡＮ２０とＩｕインターフェースを介して連結され、ＧＧＳＮ３４とはＧｎインターフェースを介して連結されて、データ及び制御メッセージなどを送受信する。そして、ＳＧＳＮ３２は、ホーム位置登録器（ＨＬＲ：Home Location Register）３６とＧｒインターフェースを介して連結されて、加入者情報及び位置情報を登録する。
【００２２】
上記ホーム位置登録器３６は、パケットドメイン（packet domain）の加入者情報及びルーティング（routing）情報などを格納し、上記ＧＧＳＮ３４とはＧｃインターフェースを介して連結される。ホーム位置登録器３６は、移動端末１０のローミング（roaming）等を考慮して他のネットワーク（図示せず）に位置することもできる。
【００２３】
ＧＧＳＮ３４は、ＵＭＴＳネットワークにおいて、ＧＴＰの終端に該当するアクセスポイントであり、Ｇｉインターフェースを介してインターネット（internet）４０、あるいはパケットドメインネットワーク（ＰＤＮ：Packet Domain Network）や他のＰＬＭＮ（Public Land Mobile Network）などの外部ネットワークと連動できるゲートウェイノードとして動作する。ＧＧＳＮ３４は、パケットデータサービス加入者のＰＤＰ（Packet Data Protocol）アドレスとルーティング情報、即ちＳＧＳＮアドレスを格納する。ルーティング情報は、インターネット４０からのデータトラフィックを端末の現在スイッチングポイント、即ちＳＧＳＮにトンネリングするのに使われる。
【００２４】
パケットデータサービスをアクセスするために、まず、移動端末は自分が位置する地域をカバーするＳＧＳＮと論理的リンクを設定する。この際、ＳＧＳＮは上記移動端末に対してＰＤＰコンテキスト（context）を生成（create）し、移動端末に対する認証（Authorization）及び承認（Authentication）手続きを遂行する。上記ＰＤＰコンテキストは、移動端末の状態と位置を始めとしてパケットデータサービスのために必要な全ての種類の情報を含む。
【００２５】
トラフィックデータを送受信するために、移動端末はＰＤＰ活性化（ＰＤＰ Activation）手続きを要求することによって、使用しようとするパケットデータアドレス、即ちＩＰアドレスを活性化するようになっている。このような動作は、移動端末と該当するＧＧＳＮとの間でなされて、この際、外部システム、即ちインターネットとの連動（interworking）が開示される。具体的に、ＰＤＰコンテキストは移動端末とＧＧＳＮ及びＳＧＳＮ内で生成される。
【００２６】
待機または準備状態の移動端末は、一つまたはその以上のＰＤＰコンテキストを有することができる。ＰＤＰコンテキストは、Ｘ．２５やＩＰのようなＰＤＰ類型、Ｘ．１２１アドレスのようなＰＤＰアドレス、サービス品質（Quality of Service：ＱｏＳ）、ＮＳＡＰＩ（Network Service Access Point Identifier）、付加的にアクセスポイント名（Access Point Name：ＡＰＮ）のような互いに異なるデータ転送パラメータを定義する。
【００２７】
次に、図２を参照して、パケットデータサービスをアクセスするためにＰＤＰコンテキストを活性化する動作を説明する。上記図２は、ＰＤＰコンテキスト活性化手続きを示すメッセージ流れ図である。上記ＰＤＰコンテキスト活性化手続きは、ＧＰＲＳ接触（Attach）手続きがなされた以後に遂行される。
【００２８】
ＵＭＴＳパケットドメインでは、データトラフィックを転送するためにＧＴＰトンネルを生成する。ＰＤＰ活性化手続きを通じて生成されるＧＴＰトンネルは、各々互いに異なる一つのＰＤＰコンテキストと対応する。ＧＴＰトンネルが生成される場合は、移動端末がＵＭＴＳコアネットワークに要請する移動端末初期活性化（MS-Initiated Activate）と外部システムからＵＭＴＳコアネットワークに要請するネットワーク要請活性化（Network Requested Activate）の２つの場合に大別される。ここでは、移動端末が要請する場合の動作を図示した。
【００２９】
上記図２を参照すれば、移動端末はパケットデータサービスのための呼を設定するために、ＳＧＳＮへＰＤＰコンテキスト活性化要請（Activate PDP Context Request）メッセージ（message）を転送する（６０）。上記ＰＤＰコンテキスト活性化要請メッセージに含まれるパラメータには、ＮＳＡＰＩ、ＴＩ（Transaction Identifier）、ＰＤＰ類型、ＰＤＰアドレス、ＡＰＮ、及びＱＯＳ属性などがある。
【００３０】
上記ＮＳＡＰＩは、移動端末で生成される情報であって、５番から１５番まで全１１個の値を使うことができる。上記ＮＳＡＰＩ値は、ＰＤＰアドレス及びＰＤＰコンテキスト識別子と一対一対応してＧＴＰトンネルを区分するために、ＧＴＰトンネルの各々に固有な値と指定される。ＰＤＰアドレスは、ＵＭＴＳドメインで使われる移動端末のＩＰアドレスを表し、上記ＰＤＰコンテキスト情報を区分する情報である。ＰＤＰコンテキストはＧＴＰトンネルの各種情報を格納しており、ＰＤＰコンテキストＩＤにより管理される。
【００３１】
上記ＴＩは、移動端末とＵＴＲＡＮ、ＳＧＳＮなどで使われて、各ＧＴＰトンネルを区分するために、ＧＴＰトンネル別に固有な値を有する。上記ＮＳＡＰＩは、上記ＴＩとは異なり、移動端末とＳＧＳＮ及びＧＧＳＮで使われる。
【００３２】
上記ＰＤＰタイプは、上記ＰＤＰコンテキスト活性化要求メッセージを通じて生成しようとするＧＴＰトンネルの種類、即ちタイプを表す。上記ＧＴＰトンネルの種類には、ＩＰ、ＰＰＰ（Point to Point Protocol）、モバイルＩＰ（Mobile IP）などがある。上記ＡＰＮは、上記ＧＴＰトンネルを生成要請する移動端末が現在接続しようとするサービスネットワークの接続ポイントを表す。
【００３３】
上記ＱＯＳは、現在生成されるＧＴＰトンネルを通じて転送されるパケットデータの要求された品質等級を表す。ＱｏＳ等級が高いＧＴＰトンネルを使用するパケットデータはＱＯＳ等級が低いＧＴＰトンネルを使用するパケットデータより先に処理される。
【００３４】
上記ＰＤＰコンテキスト活性化要請メッセージを受信したＳＧＳＮは、ＵＴＲＡＮを通じて移動端末へ無線接続ベアラーセットアップ（Radio Access Bearer Setup）メッセージを転送して無線接続ベアラーを設定する（６２）。このように、ＳＧＳＮとＵＴＲＡＮとの間、及びＵＴＲＡＮと移動端末との間に無線接続ベアラーが設定されるによって、無線を通じたパケットデータ転送に必要な資源（resource）が割り当てられる。
【００３５】
ＵＴＲＡＮに追跡（trace）機能が活性化されている場合、ＳＧＳＮは追跡要求（Invoke Trace）メッセージを、ＨＬＲや運用及びメインテナンスセンター（ＯＭＣ：Operation and Maintenance Center）から得た追跡（trace）情報と共にＵＴＲＡＮへ転送する（６４）。上記追跡機能は、データの流れを追跡するための用途として使われる。
【００３６】
ＵＴＲＡＮを通じて無線接続ベアラーが設定された状態で、ＳＧＳＮはＧＧＳＮへＰＤＰコンテキスト生成要求（Create PDP Context Request）メッセージを転送する（６６）。上記ＧＧＳＮのアドレスは、上記ＰＤＰコンテキスト活性化要求メッセージに含まれたＡＰＮにより指示することができる。上記ＰＤＰコンテキスト活性化要求メッセージにＡＰＮがないか含まれたＡＰＮが有効なＧＧＳＮアドレスを表していない場合、ＳＧＳＮにより適切なＧＧＳＮが選択される。上記過程（６６）で、コアネットワークのＧＴＰトンネルが生成される。この際、ＳＧＳＮとＧＧＳＮとの間にはトンネル終端点識別子（ＴＥＩＤ：Tunnel End point ID）が新しく設定されるが、上記ＴＥＩＤは、ＧＴＰトンネルを使用するネットワークノードの間にパケットデータを転送するために設定されるものである。即ち、ＳＧＳＮはＧＧＳＮのＴＥＩＤを記憶しており、ＧＧＳＮはＳＧＳＮのＴＥＩＤを記憶している。上記ＰＤＰコンテキスト生成要求メッセージにはＧＧＳＮがＳＧＳＮにパケットデータを転送する時に使用すべきＴＥＩＤが含まれている。
【００３７】
ＧＧＳＮは、上記ＰＤＰコンテキスト生成要求メッセージに応答してＰＤＰコンテキスト生成が正常に完了すれば、ＰＤＰコンテキスト生成応答（Create PDP Context Response）メッセージをＳＧＳＮへ転送する（６８）。これで、ＳＧＳＮとＧＧＳＮとの間にＧＴＰトンネルが生成され、上記ＧＴＰトンネルを通じて実際パケットデータ転送が可能になる。ＳＧＳＮがＧＧＳＮへデータを転送するために使われるＴＥＩＤは、上記ＰＤＰ生成応答メッセージに含まれる。
【００３８】
上記ＰＤＰ生成応答メッセージを受信したＳＧＳＮは、ＰＤＰコンテキスト活性化許容（Activate PDP Context Accept）メッセージを移動端末へ転送する（７０）。移動端末が上記ＰＤＰ活性化許容メッセージを受信することによって移動端末とＵＴＲＡＮとの間に無線経路が生成され、ＵＴＲＡＮとＳＧＳＮ及びＧＧＳＮの間にＧＴＰトンネルの生成が完了する。これで、移動端末は、上記ＧＴＰトンネルを通じて自分のＰＤＰアドレスを有する全てのパケットデータを送受信することが可能になる。
【００３９】
上記図２でのように、端末がパケットサービスを受けるために呼を試みる初期にＱｏＳ情報をＵＴＲＡＮへ転送することになり、上記ＱＯＳ情報は、各ＵＴＲＡＮ、ＳＧＳＮ、ＧＧＳＮの間に折衷がなされて、また移動端末に伝えられる。この際、ＳＧＳＮでは、移動端末の加入者がＷＣＤＭＡに加入する当時に許諾されたＱｏＳをＨＬＲから得て来て、現在の要請されたＱＯＳと比較する過程を経ることもある。このようなＱｏＳ情報中には、最大上り／下りビット率（Maximum up／down bit rate）、保障上り／下りビット率（Guaranteed up／down bit-rate）などが含まれるが、上記折衷されたＱｏＳプロファイルに従うビット率により、上記移動端末のための無線資源が割り当てられて、ＳＧＳＮ／ＧＧＳＮでは、ＱＯＳポリシーに従って差等ＱＯＳ（DiffServ（Differential Services）ＱｏＳ）サービスを遂行することになる。
【００４０】
加入者が呼を設定し、ネットワークに接続した以後、ＦＴＰ／ＨＴＴＰ（Hyper Text Transfer Protocol）／ＷＡＰ（Wireless Access Protocol）などのサービスを利用するためには、終端間転送階層プロトコル（end-to-end transport layer protocol）であるＴＣＰが使われる。ＵＭＴＳ網の場合、ＴＣＰ終端は端末とＧＧＳＮとなる。上記図２のようなＰＤＰコンテキスト活性化を通じてＧＧＳＮは上りリンク及び下りリンクのＴＣＰ転送のための帯域幅を割り当てる。両方向同時転送がなされる場合、ＧＧＳＮは上りリンクのためのＴＣＰセッションと下りリンクのためのＴＣＰセッションを設定し、上記セッションは各々割り当てられた帯域幅を持って独立的に動作する。
【００４１】
ＴＣＰは、ＩＰ（Internet Protocol）を基盤とする接続指向プロトコル（connection-  oriented protocol）である。これは、クライアント−サーバー（Client-server）が接続設定（connection establishment）過程を経なければならないことを意味する。また、ＴＣＰ／ＩＰシュート（Suite）では、データを分割（segment）して転送し、チェックサム（checksum）検査、一連番号（Sequence Number：Ｓ／Ｎ）検査、データ衝突（data corruption）を確認する。ＴＣＰは、受信者に受信確認だけでなく、無欠性（completeness）と一連番号まで要求する信頼性ある転送メカニズム（reliable transport mechanism）である。
【００４２】
ＴＣＰは、プロセス間の通信のためにポート番号を使用し、転送階層プロトコルが提供できる流れ制御（Flow control）と誤り制御（Error Control）を支援する。流れ制御のためには、スライディングウィンドウプロトコル（Sliding window protocol）を使用し、誤り制御のためにはチェックサムの他にも、ＴＣＰタイマー、再転送などを使用する。
【００４３】
ＴＣＰ流れ制御は、受信側で送信側のデータ転送量を調節及び定義することをいう。ＴＣＰは、応用プログラムから伝えられるデータを格納するためにバッファを使用し、転送するデータサイズを決定するためにウィンドウを定義する。ＴＣＰは、ウィンドウに正義されたバイト数だけのデータのみを転送することができる。このような流れ制御のためには、スライディングウィンドウ技法が使われる。
【００４４】
ＴＣＰは網で発生する衝突を制御するために終端の衝突制御を提供する。ＴＣＰ衝突制御は、送信側で網内の衝突によってパケットドロップ（drop）が発生した場合、再転送などを効果的に遂行するために使われる。ＴＣＰ送信側は、現在の網の帯域幅を照射（probe）するために、スロースタート（Slow start）アルゴリズムを使用し、パケットドロップが発生されれば、衝突回避（congestion avoidance）アルゴリズムを通じて損失パケットを再転送し、伝送速度を回復させる。
【００４５】
本発明の望ましい実施形態によるＧＧＳＮは、流入するパケットの各々に対してＴＣＰであるかＴＣＰＡＣＫであるかを判断し、仮にＴＣＰＡＣＫの場合、現在及び未来のビット率を推定及び予測する。仮に、上記推定及び予測されたビット率が、許容された最大ビット率を超過しない予め決まるしきい値に到達したならば、上記ＴＣＰＡＣＫパケットの受信側（これは、データパケットの送信側となる）に対して転送速度を制限する。これは、ＴＣＰＡＣＫが遅延されているので、パケットトラフィックの転送を制限するためである。ここで、上記しきい値は、該リンクの許容された最大帯域幅に比べて、ＴＣＰＡＣＫパケットが転送されるに充分な余裕分を維持できる程度に決まる。即ち、上記しきい値は、上記最大帯域幅でＴＣＰＡＣＫパケットを転送するための転送帯域幅を減算した値であって、ＴＣＰＡＣＫパケットのサイズ及び発生間隔などによって実験的あるいは経験的に決めることができる。このように、一方リンクの帯域幅を最大帯域幅を超過しないように制限することによって、残りの余裕資源を通じて反対側リンクのＴＣＰＡＣＫパケットを転送することができる。
【００４６】
ＧＧＳＮは流入するパケットのヘッダにより、上記パケットがＴＣＰデータであるかＴＣＰＡＣＫであるかを確認する。ＩＰを基盤とするＴＣＰで使われるヘッダの構造は、図３に示した通りである。
【００４７】
図３に示すように、ＴＣＰ／ＩＰヘッダは、ＩＰヘッダとＴＣＰヘッダから構成される。
【００４８】
上記ＩＰヘッダを説明すれば、４ビットのプロトコルバージョン（Protocol Version）は、インターネットヘッダのフォーマットを表す。以下、ＲＦＣ７９１に開示されたバージョン４のフォーマットを説明する。４ビットのヘッダ長さ（Header Length）は、インターネットヘッダの長さであり、データの開始を指示する。サービス類型（Type Of Service）は、遅延（Delay）と信頼性（Reliability）及び処理量（Throughput）の点で希望するサービスの品質を表す８ビットの情報である。１６ビットの全体長さ（Total Length）は、バイト単位で測定されたパケット（ヘッダ及びデータ）の長さである。パケット識別子（Packet Identifier）は、データグラムのフラグメント（fragments）を組立てるために送信側で割り当てた１６ビットの識別値である。各々１ビットである３個のフラグの中で、１番目の予備されたビットは０に設定され、２番目のビットであるＤＦはフラグメント（Fragment）であるか否かを表し、３番目のビットであるＭＦは最後のフラグメントであるか否かを表す。１３ビットのフラグメントオフセット（Fragment Offset）は、該フラグメントがデータグラムのどの位置に属するかを表す。有効時間（Time To Live：ＴＴＬ）は、該データグラムが残留できる最大時間を８ビットで表す。８ビットのプロトコル識別子（Protocol Identifier）は、データグラムのデータ部分で使われるプロトコル（ここでは、ＴＣＰ）を表す。１６ビットのヘッダチェックサム（Header Checksum）は、ヘッダのみの誤り訂正情報である。ソースアドレス（Source Address）とデスティネーションアドレス（Destination Address）は、各々ソースノードとデスティネーションノードの３２ビットＩＰアドレスを表す。これらの中で、変化する情報は全体長さとパケット識別子とヘッダチェックサムである。
【００４９】
次に、上記ＴＣＰヘッダに対して説明すれば、ソースポートアドレス（Source Port Address）とデスティネーションポートアドレス（Destination Port Address）は、各々１６ビットであって、セグメントを転送／受信するソースノードとデスティネーションに該当する応用プログラムのポート番号を表す。３２ビットのシーケンス番号（Sequence Number）は、セグメントに含まれたデータの最初のバイト（即ち、オクテット）に与えられた番号を表す。ＴＣＰは連結設定時、乱数生成器（random generator）により初期シーケンス番号（Initial Sequence Number：ＩＳＮ）を生成する。そして、ＴＣＰは信頼性ある連結を保障するために、伝えられる各バイト毎にシーケンス番号を与えて、上記シーケンス番号を通じてセグメントの最初のバイトを知らせてくれる。
【００５０】
３２ビットのＡＣＫ番号（Acknowledge Number）は、セグメントの送信側で相手受信側から受信することを期待するシーケンス番号である。即ち、セグメントを受信した受信側がバイトＮを成功的に受信したならば、受信側はＡＣＫ番号フィールドにＮ＋１を明記して送信側へ転送する。確認応答とデータをピギーバック（piggy-backing）することができる。
【００５１】
４ビットのＨＬＥＮ（Header Length）は、ＴＣＰヘッダの長さを４バイトワード個数で表す。ヘッダの長さは２０乃至６０バイトであるので、ＨＬＥＮの範囲は５乃至１２である。６ビットの予備されたフィールドは０に設定される。
【００５２】
制御フラグ（Control Flags）は、標準化されたＴＣＰＡＣＫの場合に、ＡＣＫの類型を決定するのに使われる６個のフラグ（ＵＲＧ、ＡＣＫ、ＰＳＨ、ＲＳＴ、ＳＹＮ、ＦＩＮ）を含む。上記制御フラグの意味は下記に示した通りであり、値‘１’が設定（set）、即ち真（true）を意味する。
【００５３】
ＵＲＧ（Urgent Pointer）：緊急指示子（Urgent Pointer）フィールドの有効か否かを表す。
ＡＣＫ（Acknowledge）：ＡＣＫフィールドの値が有効か否かを表す。初期化及び同期パケットを除外したデータパケットとＡＣＫパケットのＡＣＫフラグは‘１’に設定される。
ＰＳＨ（Push）：“プッシュ（Push）”機能が要求されたか否かを表す。
ＲＳＴ（Reset）：接続リセットが要求されることを表す。
ＳＹＮ（Synchronization）：シーケンス番号を同期化するための同期パケットであることを表す。
ＦＩＮ（Final）：送信側でこれ以上転送するデータがないことを表す。
【００５４】
１６ビットのウィンドウサイズ（Window Size）は、送信側で受容できるシーケンス番号の最大サイズであって、受信側で維持されなければならないバイト単位のウィンドウサイズとなる。上記ウィンドウサイズは、受信側が要求する広告ウィンドウサイズ（Advertised window size：Adv_Win）であり、上記ウィンドウサイズの最大値は６５５３５である。
【００５５】
１６ビットのＴＣＰチェックサムは、ヘッダとデータのチェックサムである。１６ビットの緊急指示子（Urgent Pointer）は、ＵＲＧフラグに従って、繋がる緊急データのシーケンス番号を表す。
【００５６】
以下、本発明の具体的な実施形態を説明するに当たって、上りリンクより非常に大きい帯域幅を下りリンクに対して割り当てるＷＣＤＭＡのようなシステムを例として説明するはずである。しかしながら、本発明はこのような例に限定されなく、一方リンクに対して他方リンクより非常に大きい帯域幅を割り当てて、両側リンクに対して全てＴＣＰを使用する全ての種類の通信システムに対して適用可能であることは勿論である。したがって、下記では、データパケットを転送するリンクを順方向リンク（Forward Link）と、上記データパケットに対応するＡＣＫパケットを転送するリンクを逆方向リンク（Reverse Link）と説明する。また、本明細書では、本発明のアルゴリズムが網のＴＣＰ終端であるゲートウェイノードにより遂行されることと説明する。
【００５７】
図４は、本発明の望ましい実施形態によるゲートウェイノードの構成を示すものである。ここでは、ゲートウェイノードで両方向同時転送時、ＴＣＰ転送制御を遂行する部分のみを図示した。
【００５８】
図４を参照すれば、ゲートウェイノードは、ＴＣＰ分類部（TCP classification module）１１０、セッションパラメータ初期化部（session parameter initialization module）１２０、帯域幅推定／予測部（bandwidth estimation／prediction module）１３０、及び伝送速度制御部（rate control module）１４０から構成される。
【００５９】
ＴＣＰ分類部１１０は、流入するパケットのＩＰプロトコルフィールド（図３のプロトコルＩＤ）を検査して、転送階層プロトコルがＴＣＰであるパケットを見付ける。また、ＴＣＰパケットの場合、ソース及びデスティネーションＩＰアドレスとソース／デスティネーションポート番号をキー（key）として、ＴＣＰセッションを管理する。ＴＣＰ各パケット別に、ＳＹＮ、ＡＣＫ、ＦＩＮなどのフラグを分類して該当するＴＣＰセッションを管理する。
【００６０】
セッションパラメータ初期化部１２０は、衝突ウィンドウエミュレーション初期値（Initial Emulated Congestion Window：init_emul_cwndと称する）を計算する。上記init_emul_cwndは、ＴＣＰ３−方向ハンドシェーク（3-way handshake）以後の最初のデータ転送ＡＣＫが受信される前まで、順方向チャネル（forward channel）へデータ転送のために転送されたパケットの量で決定する。また、この際、最初のデータ転送パケットのサイズを最大転送ユニット（Maximum Transfer Unit：以下、ＭＴＵと称する）エミュレーション値（emulated MTU）として格納する。衝突ウィンドウエミュレーション値（emul_cwnd）は、ＡＣＫが逆方向チャネル（reverse channel）で転送される度にＡＣＫされたパケットの量だけ増加する。即ち、emul_cwndは、送信側のｃｗｎｄの増加のような方式によりスロースタート状態で増加する。上記のように求められたemul_cwnd及びＭＴＵサイズなどのパラメータはＴＣＰ分類部１１０により帯域幅推定／予測部１３０に提供される。
【００６１】
帯域幅推定／予測部１３０は、可能な帯域幅測定方式により、逆方向チャネルで転送されるＡＣＫがゲートウェイノードを通過する度に、あるいは順方向チャネルで転送されるデータがゲートウェイノードを通過する度に現在の各ＴＣＰセッションに維持された帯域幅を推定する。そして、上記推定された帯域幅に基づいて、以後の幾つかのサンプルパケットに対する帯域幅予測を遂行する。この際、予測範囲（prediction range）は、emul_cwndを使用する。即ち、帯域幅推定／予測部１３０は、現在通過されるＡＣＫが以後の帯域幅に影響を及ぼす予測範囲を上記emul_cwndと見做して、上記予測範囲の間、同じ特性のパケット転送があることと仮定して推定を繰り返して遂行する。このような予測、即ち推定の反復（iteration）の途中、予測された帯域幅が加入者の割り当てられた最大帯域幅より小さな、予め決まる一定水準（portion）、即ち上位しきい値に到達すれば、帯域幅推定／予測部１３０は、これを伝送速度制御部１４０に知らせて、送信側がＴＣＰ転送速度（sending rate）を減少させるようにする。
【００６２】
伝送速度制御部１４０は、送信側がＴＣＰ転送速度を減らすことができるように受信側からゲートウェイノードを経て逆方向チャネルで転送されるＡＣＫパケットを変形する。逆方向チャネルのＡＣＫパケットを変形することは、上記ＡＣＫパケットに含まれた広告ウィンドウサイズ（Advertised window size：以下、Adv_Winと称する）を修正することで、遂行可能である。即ち、上記予測された帯域幅が上記一定水準に到達する時の推定反復回数を利用して、最適ウィンドウサイズ（optimal_win）を選定し、上記選ばれた最適ウィンドウサイズを上記ＡＣＫパケットに含まれたAdv_Winと取り替える。上記最適ウィンドウサイズを通じて送信側の転送速度を制限することができる。
【００６３】
伝送速度制御部１４０は、上記最適ウィンドウサイズによる転送速度が一度決定されれば、続けて上記転送速度が維持されるように逆方向チャネルのＡＣＫパケットを変形し、仮に帯域幅推定／予測部１３０で予測失敗が発生した場合、また放送ウィンドウサイズの修正を試みる。
【００６４】
一方、上記帯域幅推定／予測部１３０は、帯域幅推定時、“特定予測範囲の間、同じ特性のパケット転送があること“を仮定している。したがって、仮に前述した仮定が合わない時、帯域幅予測失敗（bandwidth prediction failure）が発生する。帯域幅予測失敗が発生されれば、伝送速度制御部１４０により送信側の転送速度が急速に低減できることになるので、このような問題を防止するために、下記のように予測失敗に備える。
【００６５】
−帯域幅推定／予測部１３０は、帯域幅予測の以後の２つのサンプル時間の間、予め決まった下位しきい値以下の帯域幅が維持される場合、帯域幅予測失敗と見做す。
【００６６】
−伝送速度制御部１４０は、計算された最適の広告ウィンドウサイズが衝突ウィンドウエミュレーション初期値より小さい場合、以前のサンプルでの予測反復回数を利用して最適ウィンドウサイズを再計算する。
【００６７】
以上のような動作により、ＴＣＰ転送は、上記最適ウィンドウサイズにより、加入者に割り当てられた最大帯域幅より小さな上位しきい値だけの帯域幅のみを使用することになる。上り／下り同時転送において、本発明のアルゴリズムを遂行する場合、各々の転送方向に上位しきい値以下の一定の転送速度でＴＣＰ転送がなされるので、残りの帯域幅を通じて反対方向データパケットに対するＡＣＫパケットの転送が可能になる。これによって、両方向同時転送時にも、各方向の転送に妨害を受けないで固定された転送速度で転送が保障される。
【００６８】
図５Ａ及び図５Ｂは、本発明の望ましい実施形態により動作するゲートウェイノードの動作を示すフローチャートである。ここで、ＴＣＰ分類部１１０はステップ２０２乃至ステップ２１０を遂行し、セッションパラメータ初期化部１２０はステップ２１２乃至ステップ２２６を遂行し、帯域幅推定／予測部１３０はステップ２２８乃至ステップ２５０を遂行し、伝送速度制御部１４０はステップ２５２を遂行する。下記のステップはゲートウェイノードで両方向同時転送時に遂行することができる。
【００６９】
図５Ａを参照すれば、ステップ２０２で、ＴＣＰ分類部１１０は、ゲートウェイノードに引込される上りあるいは下りリンクパケットを受信する。上記パケットのフォーマットは、先に図示した図３に示した通りである。ステップ２０４で、ＴＣＰ分類部１１０は、上記パケットのプロトコルＩＤに従って上記パケットがＴＣＰパケットであるか否かを判断する。仮に、ＴＣＰパケットでなければ、ステップ２２２に進行し、上記パケットはバイパスされる。一方、ＴＣＰパケットであれば、ステップ２０６に進行する。
【００７０】
ステップ２０６で、ＴＣＰ分類部１１０は、上記ＴＣＰパケットが新たなＴＣＰセッションに関連したものであるか、既存のＴＣＰセッションに関連したものであるかを判断する。この際、上記ＴＣＰセッションの既設定されたか否かは、上記ＴＣＰパケットのソースＩＰアドレス、デスティネーションＩＰアドレス、ソースポート番号、デスティネーションポート番号を確認することにより判断する。即ち、ＴＣＰ分類部１１０は、上記ＴＣＰパケットのソースＩＰアドレス、デスティネーションＩＰアドレス、ソースポート番号、及びデスティネーションポート番号を、既存のＴＣＰセッションエントリーリストの中の各ＴＣＰセッションエントリーと比較して、一致するＴＣＰセッションエントリーが存在する場合、上記ＴＣＰパケットに関連したＴＣＰセッションが既に存在すると判断する。上記ＴＣＰパケットに関連したＴＣＰセッションが存在すれば、ステップ２１２に進行する。一方、上記ＴＣＰパケットに関連したＴＣＰセッションが存在しなければ、新たなＴＣＰセッションであると判断し、ステップ２０８に進行する。
【００７１】
ステップ２０８で、ＴＣＰ分類部１１０は、上記ＴＣＰパケットのフラグのうち、ＳＹＮフラグのみ‘１’に設定されているかを確認する。ここで、ＳＹＮフラグのみ設定されていることは、上記ＴＣＰパケットがＴＣＰセッションのパラメータ初期化のために使われるＴＣＰ同期パケットであることを意味する。したがって、ステップ２１０で、ＴＣＰ分類部１１０は、上記ＴＣＰパケットに含まれたソース／デスティネーションＩＰ／ポート値を新たなＴＣＰセッションエントリーとしてＴＣＰセッションエントリーリストに追加し、ステップ２２２に進行して、上記ＴＣＰパケットをバイパスする。一方、上記ＴＣＰパケットがＴＣＰ同期パケットでなければ、非正常的な（abnormal）パケットと見なして、ステップ２２２に進行する。この場合、上記ＴＣＰパケットは、デスティネーションノードで適切に処理される。
【００７２】
ステップ２１２で、セッションパラメータ初期化部１２０は、上記ＴＣＰパケットをＴＣＰ分類部１１０から提供されて、上記ＴＣＰパケットのフラグのうち、ＡＣＫ（ＡＣＫ）フラグのみ‘１’に設定されているかを確認する。仮に、ＡＣＫフラグのみ設定されていれば、ステップ２１４に進行する。一方、ＡＣＫフラグが設定されていなかったり、ＡＣＫフラグの他のフラグが設定されていれば、ステップ２２２に進行し、上記ＴＣＰパケットはバイパスされる。
【００７３】
ステップ２１４で、セッションパラメータ初期化部１２０は、上記ＴＣＰパケットがデータパケットであるか、あるいはデータ転送に対するＡＣＫパケットであるかを確認する。ここで、ＡＣＫパケットであるか否かは、上記ＴＣＰパケットのサイズを検査する等のパケット検査（packet inspection）により分かる。上記ＴＣＰパケットがＡＣＫパケットでない場合、ステップ２１６で、セッションパラメータ初期化部１２０は、上記ＴＣＰパケットに関連したＴＣＰセッションのセッションパラメータ初期化が完了した否かを確認する。上記ステップ２１６の確認は、セッションパラメータ初期化の完了を表す初期化完了フラグinitial_emul_cwnd_found_flagが‘ＯＮ’に設定されているか否かにより分かる。上記initial_emul_cwnd_found_flagは、セッションパラメータ初期化部１２０、あるいはＴＣＰ分類部１１０により参照されることができ、その設定に対する説明は後述する。
【００７４】
仮に、セッションパラメータ初期化が完了したならば、ステップ２２２に進行し、上記ＴＣＰデータパケットはバイパスされる。一方、上記セッションパラメータ初期化が完了しなかったら、ステップ２１８で、上記ＴＣＰデータパケットに関連したＴＣＰセッションの衝突ウィンドウエミュレーション初期値init_emul_cwndを、上記ＴＣＰデータパケットのＩＰヘッダ内の長さ値（“iph->length”と称する）だけ増加させる。ここで、上記init_emul_cwndは、該ＴＣＰセッションが初めて始まる時、初期値‘０’に設定され、関連したＴＣＰデータパケットが転送される度に、上記ステップ２１８のように、上記ＴＣＰパケットのデータ長さだけ増加する。上記ステップ２１８が遂行された後、ステップ２２２に進行し、上記ＴＣＰデータパケットはバイパスされる。
【００７５】
一方、上記ステップ２１４で、上記ＴＣＰパケットがＡＣＫパケットであれば、ステップ２２０で、セッションパラメータ初期化部１２０は、上記ＴＣＰパケットに関連したＴＣＰセッションのinit_emul_cwndが０より大きいかを確認する。これは、上記init_emul_cwndが正常的に設定されたかを確認するためである。仮に、init_emul_cwndが０より大きくなければ、正常でない場合と判断し、ステップ２２２に進行する。この場合、上記ＴＣＰＡＣＫパケットは、デスティネーションノードで適切に処理される。一方、上記init_emul_cwndが０より大きければ、即ち正常的に設定されていれば、ステップ２２４に進行する。
【００７６】
次に、図５Ｂを参照すれば、ステップ２２４で、セッションパラメータ初期化部１２０は、前述した初期化完了フラグinitial_emul_cwnd_found_flagに従ってセッションパラメータ初期化が完了したか否かを確認する。仮に、上記初期化完了フラグinitial_emul_cwnd_found_flagが‘ＯＮ’に設定されていなければ、ステップ２２６で、セッションパラメータ初期化部１２０は、init_emul_cwndをemul_cwndに設定し、上記初期化完了フラグinitial_emul_cwnd_found_flagが‘ＯＮ’に設定してセッションパラメータ初期化が完了したことを表示する。上記emul_cwndは、以後、帯域幅予測過程で予測範囲（prediction range）で使われる。一方、上記初期化完了フラグinitial_emul_cwnd_found_flagが既に‘ＯＮ’に設定されていれば、ステップ２２８に進行する。
【００７７】
ステップ ２２８で、帯域幅推定／予測部１３０は、上記ＴＣＰＡＣＫパケット内の一連番号から上記ＴＣＰＡＣＫパケットが重複ＡＣＫ（Duplicate Ack）であるか否かを判断する。ここで、重複ＡＣＫとは、上記ＴＣＰＡＣＫパケットが以前の転送で流失されて、再転送されたものであることを意味する。
【００７８】
仮に、上記ＴＣＰＡＣＫパケットが再転送されたものであれば、ステップ２３０で、上記emul_cwndはinit_emul_cwndに維持される。一方、上記ＴＣＰＡＣＫパケットが再転送されたものでなければ、ステップ２３２で、上記emul_cwndは、以前のemul_cwnd値に比べて、確認応答されるバイト値、即ち送信されたバイト値（transmitted_bytes）だけ増加する。上記送信されたバイト値は、上記ＴＣＰＡＣＫパケットのＡＣＫ番号と以前のＡＣＫ番号の差により分かる。ここで、ＡＣＫ番号とは、ＡＣＫパケットに対応するデータパケットの一連番号を意味する。上記ステップ２２６、２３０及び２３２からステップ２３４に進行する。
【００７９】
ステップ２３４で、帯域幅推定／予測部１３０は、予め決まる推定アルゴリズムに従って上記ＴＣＰＡＣＫパケットに対応する順方向リンクに対する現在の時点の帯域幅を推定する。上記帯域幅の推定は、上記ＴＣＰＡＣＫパケットが流入した現在の時点の瞬間的な帯域幅を測定するものである。
【００８０】
ステップ２３６で、帯域幅推定／予測部１３０は、帯域幅制限のための最適ウィンドウ値optimal_winが既に決定されたか否かを確認する。上記optimal_winは、上記ＴＣＰＡＣＫパケットを受信するデスティネーションノードの帯域幅を制限するためのものである。仮に、optimal_winが既に決定されたならば、ステップ２５２に進行し、そうでなければ、ステップ２３８乃至２５０を遂行してoptimal_winを決定する。
【００８１】
ステップ２３８で、帯域幅推定／予測部１３０は、上記emul_cwndを利用して予測範囲を表す帯域幅予測の反復回数を算出する。ここで、反復回数は、上記emul_cwndを現在のＴＣＰセッションの予め決まるＭＴＵサイズ（MTU_size）で割った値となる。また、ステップ２３８で、帯域幅予測の遂行回数を表すｉが０に初期化される。
【００８２】
ステップ２４０で、上記予測遂行回数ｉが上記反復回数より小さいか否かを確認する。上記Bw_pred(i)は、加入者が最大で使用できる帯域幅の限界であるth_highを越えないまま、上記ステップ２４０で、上記予測遂行回数ｉが上記反復回数に到達すれば、ステップ２４２で、上記予測遂行回数ｉ、即ち上記反復回数は、最適ウィンドウ最終推薦値last_recommend_optimal_windowとして格納される。この際、上記ＴＣＰＡＣＫパケットは修正されないままバイパスされる。一方、上記予測遂行回数ｉが上記反復回数より小さければ、ステップ２４４で、帯域幅推定／予測部１３０は、予め決まる予測アルゴリズムに従って現在の同一な特性を有するパケットが受信されたと仮定して、未来の帯域幅Bw_pred(i)を予測する。ここで、上記予測アルゴリズムは、本発明の主要な要旨とはあまり関連がないので、詳細な説明を省略する。
【００８３】
ステップ２４６で、上記Bw_pred(i)が上記th_high以上であるか否かを確認する。上記th_highは、非対称帯域幅リンクで、両方向同時ＦＴＰ転送時、反対方向のＡＣＫパケット受信が可能な程度に制限される。仮に、上記Bw_pred(i)が上記th_highより小さければ、ステップ２４８で、上記予測遂行回数ｉを１だけ増加させた後、ステップ２４０に復帰する。一方、上記Bw_pred(i)が上記th_highより大きいか等しければ、ステップ２５０に進行し、optimal_winを決定する。上記ステップ２５０で、上記optimal_winは、最適ウィンドウ最終推薦値last_recommend_optimal_windowと上記予測遂行回数ｉのうち、大きい値にＭＴＵサイズ（MTU_size）を掛けた値で決定される。この際、上記optimal_winは、ＴＣＰに対し、予め決まる最大ウィンドウ値max_cwndを超過できない。上記optimal_winが決定されれば、ステップ２５２に進行する。
【００８４】
ステップ２５２で、転送速度制御部１４０は、上記ＴＣＰＡＣＫパケットに含まれている広告ウィンドウサイズAdv_winを上記optimal_winに取り替えて、デスティネーションノードに伝達（forwarding）する。デスティネーションノードは、上記optimal_win以内で、上記ＴＣＰＡＣＫパケットに対応するＴＣＰセッションのデータパケットを転送することになる。これは、デスティネーションノードがＴＣＰＡＣＫなしに多過ぎるデータパケットを転送しないことを意味する。
【００８５】
図６と図７は、各々従来技術と本発明において、上り／下りリンク転送速度の変化を示すものである。
【００８６】
まず、図６を参照すれば、順方向転送速度は、赤色で表示し、逆方向転送速度は青色で表示した。図示したように、順方向転送速度は、逆方向転送と似た水準で同期されている。一方、図７を参照すれば、赤色で表示された順方向転送は、青色で表示した逆方向転送に影響されないで、割り当てられた水準の転送速度を維持している。
【００８７】
下記の＜表１＞は６４／３８４ｋｂｐｓの非対称帯域幅リンクを使用するＷＣＤＭＡのＧＧＳＮにおいて、本発明による下りリンク帯域幅の向上を示すシミュレーション結果である。
【００８８】
【表１】
2008536356.tif 000003
【００８９】
上記＜表１＞に示すように、従来技術の場合、下りリンク速度が上りリンクと似た水準である５４．０８ｋｂｐｓで同期されたが、本発明の場合、下りリンク速度が上りリンクに影響されないで、割り当てられた最大帯域幅である３８４ｋｂｐｓに比較的近接した３３７．１ｋｂｐｓを維持している。
【００９０】
上記では、中間転送ノードであるゲートウェイノードでの動作を説明したが、図５Ａ及び図５Ｂに説明した本発明のアルゴリズムを終端ノード、例えば端末機に適用することも可能である。言い換えると、非対称帯域幅を割り当てられてＴＣＰ転送に使用する端末では、両方向にＴＣＰ同時転送を試みる時、ＴＣＰＡＣＫパケットが転送できるように、各ＡＣＫパケットに含まれた広告ウィンドウサイズを調節することによって、伝送速度を制限することで、同時転送時の速度低下の問題を解決する。
【００９１】
具体的に、図５Ａを参照すれば、端末はネットワークを通じてデスティネーションノードへ転送しようとするＩＰパケットを生成した後、上記生成されたＩＰパケットに対してステップ２０４乃至２５２を遂行する。即ち、端末は逆方向リンクで転送するＡＣＫパケットを生成し、上記ＡＣＫパケットの広告ウィンドウサイズAdv_winを、ステップ２２４乃至２５０により決定した最適ウィンドウ値optimal_winに取り替えて伝達したり、あるいは上記ＡＣＫパケットを修正しなくてバイパスする。これで、端末は順方向リンクの帯域幅がＡＣＫパケットを転送するのに充分な程度の余裕分を有するようにする。
【００９２】
このように、端末及びゲートウェイノードは、デスティネーションノードへ転送しようとするＩＰパケットを獲得した後、上記獲得したＩＰパケットに対してステップ２０４乃至２５２を遂行する。
【００９３】
以上、本発明の詳細な説明の欄においては具体的な実施形態について詳述したが、本発明はこれに限定されるものではなく、本発明の範囲を逸脱しない限り、各種の実施形態が提供可能である。よって、本発明の真の技術的な範囲は上述の実施形態によって定まるものではなく、特許請求の範囲とその均等物によって定まるべきである。
【図面の簡単な説明】
【００９４】
【図１】本発明が適用されるＷＣＤＭＡ網の構成図を概略的に示す図である。
【図２】ＰＤＰコンテキスト活性化手続きを示すメッセージ流れ図である。
【図３】ＩＰを基盤とするＴＣＰで使われるヘッダの構造を示す図である。
【図４】本発明の望ましい実施形態によるゲートウェイノードの構成を示す図である。
【図５Ａ】本発明の望ましい実施形態により動作するゲートウェイノードの動作を示すフローチャートである。
【図５Ｂ】本発明の望ましい実施形態により動作するゲートウェイノードの動作を示すフローチャートである。
【図６】従来技術と本発明において、上り／下りリンク転送速度の変化を示す図である。
【図７】従来技術と本発明において、上り／下りリンク転送速度の変化を示す図である。
【符号の説明】
【００９５】
１１０  ＴＣＰ分類部
１２０  セッションパラメータ初期化部
１３０  帯域幅推定／予測部
１４０  伝送速度制御部
【図１】
2008536356.tif 000004
【図２】
2008536356.tif 000005
【図３】
2008536356.tif 000006
【図４】
2008536356.tif 000007
【図５Ａ】
2008536356.tif 000008
【図５Ｂ】
2008536356.tif 000009
【図６】
2008536356.tif 000010
【図７】
2008536356.tif 000011
【国際調査報告】
2008536356.tif 000012
2008536356.tif 000013