JP5899328B2 - Ｔｃｐトラフィックをハンドリングするための方法及びネットワークノード - Google Patents

Description

本実施形態は、概してネットワークノード及びネットワークノードにおける方法に関する。より具体的には、本実施形態は、パケット交換（ＰＳ：Packet Switched）ネットワーク内のＴＣＰ（Transmission Control Protocol）トラフィックのハンドリングに関する。

典型的な通信システムは、例えば、ネットワークノードを経由して対応ノード（ＣＮ：Correspondent Node）に対応するモバイルノード（ＭＮ：Mobile Node）などのノードを含む。ネットワークノードは、無線アクセスネットワーク（ＲＡＮ：Radio Access Network）又はコアネットワーク（ＣＮ：Core Network）に配置されうる。通信システムは、有線又は無線システムであり得る。

モバイルノードは、ユーザ機器と呼ばれることができる。加入者は、モバイルノードによって、オペレータのコアネットワークによって提示されるサービス及びオペレータのＲＡＮ及びコアネットワークがアクセスを提供するオペレータのネットワーク外のサービスにアクセスすることができる。モバイルノードは、例えば、モバイル電話、セルラ電話、スマートフォン、タブレットコンピュータ又は無線ケイパビリティを有するラップトップ等の通信装置であってもよい。モバイルノードは、ポータブルの、ポケット収納可能な、手持ちの、コンピュータに含まれる、又は車載のモバイル装置であってもよく、ＲＡＮを介して他のモバイルノード又はサーバなどの他のエンティティと、音声及び又はデータを通信することを可能にすることができる。

通信システムは、複数のセルエリアに分割される地理的エリアをカバーするセルラネットワークであり得る。各セルエリアは、基地局、例えば無線基地局（ＲＢＳ）によってサービスされる。基地局は、用いられる技術及び専門用語に依存して、例えばｅＮＢ、ｅノードＢ、ノードＢ、Ｂノード、又は基地送受信局（ＢＴＳ：Base Transceiver Station）と呼ばれることもある。基地局は、基地局のレンジ内のモバイルノードと、無線周波数上で動作するエアインタフェースを介して通信する。

いくつかのバージョンの無線アクセスネットワークにおいて、いくつかの基地局は、典型的にはモバイル通信システムの第３世代（３Ｇ：the third Generation）、即ちＷＣＤＭＡ（Wideband Code Division Multiple Access）におけるように、例えば固定電話回線又はマイクロ波によって、無線ネットワークコントローラ（ＲＮＣ：Radio Network Controller）に接続される。無線ネットワークコントローラは、当該無線ネットワークコントローラに接続される複数の基地局の様々なアクティビティをスーパバイズし及び協調させる。モバイル通信システムの第２世代（２Ｇ：the second Generation）、即ちＧＳＭ（Global System for Mobile Communications）において、基地局は、ＢＳＣ（Base Station Controller）に接続される。ネットワークコントローラは、典型的には１つ以上のコアネットワークに接続される。

ネットワークノードは、例えばｅＮＢであり得る。対応ノードは、ＴＣＰ／ＩＰ（Internet Protocol）ネットワークを介してモバイルノードと通信可能な通信システムにおける任意のノードであり得る。対応ノードは、固定又はモバイルであり得る。それは、メールサーバ、インスタントメッセンジャサーバ、ソーシャルネットワークウェブサイト、ゲームサーバ、ＩＭＳネットワークにおけるＩＭＳノード等であってもよい。

ＴＣＰ及びＩＰは、インターネットプロトコルスイート（ＩＰＳ：Internet Protocol Suite）のプロトコルである。インターネットプロトコルスイートは、したがって、ＴＣＰ／ＩＰとも呼ばれる。ＩＰプロトコルはパケットを扱い、ＴＣＰは、ＩＰネットワークにおけるホスト間の信頼性の高い通信を提供するために広く使用されているプロトコルである。ＨＴＴＰ（Hypertext Transfer Protocol）、ＦＴＰ（File Transfer Protocol）、ＳＭＴＰ（Simple Mail Transfer Protocol）、ＮＦＳ（Network File System）、Ｔｅｌｎｅｔ及びＳＳＨ（Secure Shell）等のプロトコルは全て、有線ネットワーク及び無線ネットワークの両方において通信するＴＣＰトランスポートプロトコルに基づいている。

良好な信頼性に加えて、ＴＣＰは、ウィンドウメカニズムを介した優れた輻輳制御メカニズムも有する。クライアント及びサーバ間の接続において、クライアントは、サーバから１回で受信する用意があるデータの量をサーバに伝える。このデータの量は、ウィンドウサイズと呼ばれ得る。同様に、サーバは、クライアントから１回で受け取る用意があるデータの量をクライアントに伝える。このデータの量もまたウィンドウサイズと呼ばれ得る。ＴＣＰの送信側により送信されるデータの量を、ＴＣＰの受信側が支配する。受信側は、全ての確認応答（ＡＣＫ）と共にウィンドウ更新を送信側に返す。ウィンドウ更新は、さらなる許可を受信する前に送信側が送信することができる、許容されるオクテットの数を示している。ＡＣＫは、パケットの受信を確認応答するために、ＴＣＰにおいて使用されるフラグである。

モバイルネットワークにおいては、モバイルノードは通常、インターネットを検索し（例えば、ＨＴＴＰ）、電子メールを読み（例えば、ＳＭＴＰ）、ツイッター、フェイスブック等のソーシャルネットワーク及びオンラインチャットにアクセスする（例えば、ＳＩＰ（Session Initiation Protocol）又は他のアプリケーションプロトコル、ＭＳＮ、Ｓｋｙｐｅ等）ために、ＴＣＰを使用する。もちろん、ＵＤＰ（User Datagram Protocol）アプリケーションは、映像及び音声ベースのアプリケーションの急成長とともに年々増加している。しかしながら、ＴＣＰは、今なおモバイルノードによるパケットコアネットワーク（ＰＣＮ：Packet Core Network）において大多数により使用されるトランスポートプロトコルである。それは、トラフィックの約８０％以上を占める。

第３世代パートナーシッププロジェクト（３ＧＰＰ）のＬＴＥ（Long Term Evolution）は、モバイル通信についての標準であり、第４世代（４Ｇ）とも呼ばれ得る。ＬＴＥは、ＥＰＣ（Evolved Packet Core）及びＥ−ＵＴＲＡＮ（Evolved Universal Terrestrial Radio Access Network）を含む。ＥＰＣは、ＭＭＥ（Mobility Management Entity）、ＨＳＳ（Home Subscriber Server）、ＳＧＷ（Serving Gateway）、ＰＧＷ（Packet Data Network Gateway）及びＰＣＲＦ（Policy and Charging Rules Function）サーバ等の、いくつかのエンティティ、エレメント、ノード又はゲートウェイを含む。

ＭＭＥは、加入者及びセッション管理に関連する全ての制御プレーン機能を担当する。ネットワークは、プレーンとも呼ばれる３つの部分を含む。制御プレーンは、ネットワーク内の制御情報を伝達する。制御プレーンはまた、シグナリングとも呼ばれる制御情報を伝達する。ユーザプレーンは、ネットワークのユーザトラフィックを伝達する。管理プレーンは、ネットワーク管理に必要な動作及び管理トラフィックを伝達する。

ＨＳＳは、インターネットプロトコルマルチメディアサブシステム（ＩＭＳ：Internet Protocol Multimedia Subsystem）ネットワークの全ての加入者固有の権限並びにサービスプロファイル及びプリファレンスの中央リポジトリである。

ＳＧＷは、Ｅ−ＵＴＲＡＮに向かうパケットデータインタフェースの終端点である。モバイルノードがＥ−ＵＴＲＡＮ内のｅノードＢ間で移動するとき、ＳＧＷはローカルモビリティアンカーとして機能する。言い換えると、データパケットは、Ｅ−ＵＴＲＡＮ内のモビリティ及び例えば２Ｇ／ＧＳＭ及び３Ｇ／ＵＭＴＳのような他の３ＧＰＰ技術とのモビリティのため、ＳＧＷを通じてルーティングされる。

ＰＧＷは、ＰＤＮに向かうパケットデータインタフェースの終端点である。

ＰＣＲＦは、サービスポリシーを管理し、各モバイルノードセッション及びアカウントルール情報についてのサービス品質（QoS）情報を送信する。

汎用パケット無線サービス（ＧＰＲＳ）トンネリングプロトコル（ＧＴＰ）は、例えばＧＳＭ、ＵＭＴＳ及びＬＴＥネットワーク内のＧＰＲＳ（http://en.wikipedia.org/wiki/General_Packet_Radio_Service）を伝達するために使用される通信プロトコルのグループである。ＧＴＰは、その用途に応じて、ＧＴＰ−コントロール（ＧＴＰ−Ｃ）、ＧＴＰユーザプレーン（ＧＴＰ−Ｕ）及びＧＴＰ’の別々のサブプロトコルに分類され得る。ＧＴＰ−Ｃは、ＧＴＰの制御部であり、サービングＧＰＲＳサポートノード（ＳＧＳＮ）とＭＭＥとの間、ＳＧＳＮとＳＧＷとの間、ＳＧＷとＰＧＷとの間、及びＭＭＥの間のシグナリングメッセージのために使用される。ＧＴＰ−Ｃは、ＧＴＰ−Ｃヘッダを含む。

ＧＴＰ−Ｕトンネルは、ＧＴＰ−Ｕトンネルエンドポイント間でトランスポートパケットデータユニット（Ｔ−ＰＤＵ）及びシグナリングメッセージを伝達するために使用される。ＧＴＰ−Ｕは、ＧＴＰ−Ｕヘッダ及びＧＴＰ−Ｕペイロードを含む。ＴＣＰトラフィックは、ＧＴＰ−ＵペイロードのＴ−ＰＤＵに含まれる。ＰＤＵは、ＯＳＩモデルにおける所与のレイヤのプロトコルで指定されたデータの単位を表し、プロトコル制御情報及びユーザデータを含む。Ｔ−ＰＤＵは、モバイルノードと対応ノードとの間で移送されるＩＰデータである。Ｔ−ＰＤＵは、ＩＰ／ＵＤＰネットワーク上でも、ＧＴＰ−Ｕトンネルを介してパケット交換ネットワークを通過する。

ＬＴＥ４Ｇネットワークにおいては、ｅノードＢ、ＭＭＥ、ＰＧＷ及びＰＣＲＦは、ＧＴＰ−Ｃ及びＤｉａｍｅｔｅｒなどの制御プレーンシグナリングと、ベアラＱｏＳについてネゴシエートしている。Ｄｉａｍｅｔｅｒは、認証、承認及びアカウンティングのプロトコルである。Ｄｉａｍｅｔｅｒは、ＲＡＤＩＵＳ（Remote Authentication Dial In User Service）プロトコルに代わるものである。

ＩＰネットワーク上で送信されたデータは、「パケット」と呼ばれるより小さな単位に分割される。パケットは、最も小さなデータの単位であり、ＩＰネットワークにおいて送信されルーティングされる。より深いレベルのこれらのパケットを検査する技術が、ＤＰＩ（Deep Packet Inspection）と呼ばれる。ＤＰＩは、リアルタイムでネットワークを通じて流れるトラフィックのコンテンツ部分を検査するネットワーク技術である。ＤＰＩは、パケットが検査ポイントを通過するときにパケットのデータ部分及びおそらくヘッダも調べ、プロトコル不準拠、ウイルス、スパム、侵入を検索することにより、又はパケットが検査ポイントを通過できるかどうか若しくは異なる目的地へルーティングされる必要があるかどうかを決定するため若しくは統計的情報を収集する目的のための予め定義された基準により、パケットフィルタリングを実行する。ＤＰＩは、ＧＧＳＮ又はＰＧＷ等のネットワークに存在するノードにおいて、又は専用のＤＰＩノードにおいて実装され得る。

サービス品質（ＱｏＳ：Quality of service）は、異なるアプリケーション、ユーザ又はデータフローに異なる優先順位を提供するため、又はデータフローに対する一定レベルのパフォーマンスを保証するためのノードの能力と関連している。例えば、必要とされるビットレート、遅延、ジッタ、パケット破棄（packet dropping）の可能性、及び／又はビットエラー率が保障され得る。ＱｏＳは、ポリシングと呼ばれるトラフィック規制機能を提示する。ポリシング機能がトラフィック違反を識別すると、典型的にはトラフィックを破棄する。トラフィック破棄（traffic drop）は、トラフィックロス、パケットロス又はパケット破棄（packet drop）とも呼ばれ、１以上のデータパケットのロスを含み、ネットワークをわたって伝搬する１以上のパケットがその目的地に到達できない場合に発生する。トラフィック破棄の用語は、以下で用いられる。

Ｑｏｓのパラメータは、ＰＤＰ（Packet Data Protocol）のベアラレベルでポリシングを行うために、ＭＭＥからＳＧＷへダウンロードされる。Ｑｏｓパラメータは、ネットワーク上で送信するトラフィックの優先度、信頼性、速度及び量を制御するパラメータである。典型的なＱｏｓパラメータは、スループット、帯域幅、伝送遅延、ジッタ、ロス率及びエラー率であり得る。ＰＧＷ及びｅノードＢもまた、ネゴシエートされたＱｏｓに基づいてポリシングを実行する。ポリシングの目的は、ネゴシエートされた最大ビットレート（ＭＢＲ）ＱｏｓパラメータとのＰＤＰのベアラフローの一致を制御することである。ポリシングのみが、全てのダウンリンク（ＤＬ）ユーザプレーントラフィックの送信レートを監視する。アップリンク（ＵＬ）トラフィックは、ポリシングの対象ではない。ＤＬは、対応ノードからモバイルノードへのトラフィックであり、ＵＬは、モバイルノードから対応ノードへのトラフィックである。

ＰＤＰは、ＧＲＰＳネットワークと通信するために、パケット交換ネットワークにより使用されるネットワークプロトコルである。ＰＤＰコンテキストは、モバイルノード及び対応ノードとの間のパケットデータ接続又はリンク、即ちＰＤＮ（Public Data Network）であり、それらが互いに通信すること、例えばＩＰパケットを交換することを可能にする。ＰＤＰコンテキストは、特定の接続の継続期間、即ちデータセッションの間のみ存続する。モバイルノードは、同時にアクティブ化する１より多くのＰＤＰコンテキストを有してもよい。ＰＤＰコンテキストは、ルーティング、Ｑｏｓ、セキュリティ、ビリング等の特徴を定義する。

ＵＭＴＳ ３Ｇネットワークにおいて、ＲＮＣ、ＳＧＳＮ、ＧＧＳＮ（Gateway GPRS Support Node）及びＰＣＲＦは、ＰＤＰ毎のＭＢＲ Ｑｏｓパラメータを取得するためにＧＴＰ−Ｃ及びＤｉａｍｅｔｅｒ等のシグナリングをするコントロールプレーンとＰＤＰ ＱｏＳについてネゴシエートする。ダウンリンクのユーザプレーントラフィック上でポリシング機能を実行するのはＳＧＳＮだけでなく、ＧＧＳＮ及びＲＮＣもまたポリシング機能を実行する。ＧＧＳＮは、ユーザプレーンを提供し、パケットを転送及びルーティングする。それは、インターネット、ＩＭＳ、内部ＩＰドメイン等の外部パケットネットワークへのゲートウェイである。Ｇｉインタフェースは、インターネットに対し直接の又はＷＡＰゲートウェイを通じてのいずれかの、ＧＧＳＮ及びＰＤＮ間のＩＰベースのインタフェースである。

ポリシングアルゴリズムは、トークンバケット（token bucket）上で実装され得る。それは、ポリシングを実行するための簡単であるが効率的なアルゴリズムである。トークンバケットは、データ送信がトラフィックフロー内の帯域幅及びバリエーションに関する定義された制限に合致していることをチェックすることにより、フロー内のデータを規制するデバイスを管理するために使用される。データパケットが定義された制限に合致することをチェックされるべき場合に、バケットは、その時に十分なトークンを有するかどうかを見るために検査される。もしそうである場合、例えば、バイトで表したパケット長に相当する、適当な数のトークンがバケットから除去され、データパケットは通過する。もしバケット内のトークンが不十分である場合、データパケットは定義された制限に合致せず、バケットのコンテンツは変化しない。非準拠のパケットは破棄される可能性がある。

ＴＣＰは、ＰＣＮの主要なトラフィックタイプであり、したがって、このタイプのトラフィック上でポリシングが主に実行されている。

電子メールを読む等、ＴＣＰプロトコルを介してインターネット内の対応ノードと通信する、ＰＣＮネットワーク内のモバイルノードを考えてみる。加入者のトラフィックフローが、合意されたサービス閾値、例えばＭＢＲを超過する場合、ＰＣＮ内のノードは、ポリシング機能を用いてパケットを破棄するであろう。最大ビットレートは、ＰＤＰコンテキストについての合意された上限の送信レートを表し、ネゴシエートされたＱｏｓパラメータのセット中の値である。パケットが破棄されることに起因して、ますます多くのＴＣＰパケットがネットワーク上で再送信されるべきものとなり、特に、混雑時／日にネットワーク輻輳を引き起こす可能性がある。また、受信側、即ちモバイルノードから送信側の対応ノードにウィンドウサイズ更新と共に送信されるＡＣＫが遅いことに起因して、より多くのパケットがダウンリンクトラフィックにおいて破棄され得る。

ＰＤＰ上の過剰なトラフィックは、受信側、例えばモバイルノードから送信側、例えば対応ノードに短期間に送信されるＡＣＫ内のウィンドウサイズが大きすぎることにより、主に引き起こされ得る。結果、受信側が送信側に別のウィンドウサイズのＡＣＫで通知するまで、送信側が積極的に受信側に過剰なデータをすぐに送信することとなる。

無線通信ネットワークは、有線のインターネット及びＰＣＮネットワークと比較してより狭い帯域幅を有する。モバイルノードは、ネットワーク速度に適合しないことに気付かない。モバイルノードがＴＣＰ受信側として動作するとき、より大きなウィンドウサイズを送信側に告知（advertise）し、それが、ＧＳＮ（GPRS Supporting）ノードがＴＣＰトラフィック上でポリシングを行う原因となり得る。これは、ネットワークの輻輳、トラフィック破棄、再送及びパケット遅延といった問題を引き起こし得る。

ポリシングのトラフィック破棄は、対応ノードからモバイルノードへのネットワーク上のＴＣＰセグメント再送信の原因となるであろう。このことは、さらなるパケットコアネットワークオーバヘッドの原因となるであろう。

本実施形態の目的は、したがって、パケット交換ネットワーク内でのＴＣＰトラフィックの改善されたハンドリングを提供することである。

第１の態様によれば、目的は、パケット交換ネットワーク内でＴＣＰトラフィックをハンドリングするためのネットワークノードにおける方法により達成される。ネットワークノードは、モバイルノードからＴＣＰトラフィックを受信する。ＴＣＰトラフィックは、オリジナルウィンドウサイズを含む。ネットワークノードが破棄されるＴＣＰトラフィックに関する情報を有し、且つオリジナルウィンドウサイズが最適ウィンドウサイズよりも大きい場合に、ネットワークノードは、オリジナルウィンドウサイズを最適ウィンドウサイズと置換する。ネットワークノードは、パケット交換ネットワーク内の対応ノードへ、モバイルノードにより受信可能なＴＣＰトラフィックの量を示す、最適ウィンドウサイズを含むＴＣＰトラフィックを送信する。

第２の態様によれば、目的は、パケット交換ネットワーク内でＴＣＰトラフィックをハンドリングするためのネットワークノードにより達成される。ネットワークノードは、モバイルノードからＴＣＰトラフィックを受信するように構成される受信機を含む。ＴＣＰトラフィックは、オリジナルウィンドウサイズを含む。ネットワークノードが破棄されるＴＣＰトラフィックに関する情報を有し、且つオリジナルウィンドウサイズが最適ウィンドウサイズよりも大きい場合に、ネットワークノードは、オリジナルウィンドウサイズを最適ウィンドウサイズと置換するように構成される置換ユニットを含む。ネットワークノードは、パケット交換ネットワーク内の対応ノードへ、モバイルノードにより受信可能なＴＣＰトラフィックの量を示す、最適ウィンドウサイズを含むＴＣＰトラフィックを送信するように構成される送信機をさらに含む。

ネットワークノードが破棄されるＴＣＰトラフィックに関する情報を有し、且つオリジナルウィンドウサイズが最適ウィンドウサイズよりも大きい場合に、オリジナルウィンドウサイズが最適ウィンドウサイズと置換されるため、対応ノードは、モバイルノードがハンドリング可能な量のＴＣＰトラフィックだけをモバイルノードに送信する。したがって、パケット交換ネットワーク内のＴＣＰトラフィックのハンドリングが改善される。

本実施形態は、次の例の非網羅的なリストのうちの多くの利点を享受する。

本実施形態の利点は、モバイルノードにより対応ノードへより大きいＴＣＰウィンドウサイズが示されることに起因するネットワークノードポリシングにおけるダウンリンクのトラフィック破棄を、回避することができることである。

別の利点は、本実施形態は、ＴＣＰセグメントの再送信により引き起こされるネットワークオーバヘッドを大いに減少させるであろうということである。

ポリシングのトラフィック破棄が全くなく、より大きいウィンドウサイズがモバイルノードから対応ノードへ送信される場合、当該より大きいウィンドウサイズが維持されるであろう。これは、ネットワークにおける伝送性能にいかなる影響も与えないという利点を有する。

さらなる利点は、各ネットワークノードが本実施形態を実施することができ、実施形態の動的なアクティブ化又は非アクティブ化を実行しうることである。これは本実施形態の展開を容易する。

本実施形態は、それがネットワークノードのＰＤＰレベル又はＤＰＩ製品におけるＩＰフローレベルにあり得るという利点を提供する。

さらに、本実施形態の利点は、あまりにも大きなウィンドウサイズがモバイルノードから対応ノードに送信されることを回避することで、ポリシングのトラフィック破棄のリスクを減少させ、ネットワークオーバヘッドを減少させるということである。

本実施形態の他の利点は、ＬＴＥ、ＵＭＴＳ及びＧＳＭ等の多くの通信技術に対し適用できることである。

本実施形態は、上述した特徴及び利点に限定されない。当業者であれば、以下の詳細な説明を読んだ上で、追加的な特徴及び利点を認識するであろう。

本実施形態は、現在、さらなる実施形態を示す添付の図面を参照することにより、以下の詳細な説明においてより詳細に説明される。
通信ネットワークの実施形態を図示する概略図である。 方法の実施形態を示す概略的なブロック図及びフローチャートの組み合わせである。 通信ネットワークの実施形態を図示する概略図である。 方法の実施形態を示す概略的なブロック図及びフローチャートの組み合わせである。 ＬＴＥトランスポートプロトコルスタックの実施形態を図示する概略的なブロック図である。 方法の実施形態を示すフローチャートである。 ネットワークノードにおける方法の実施形態を示すフローチャートである。 ネットワークノードの実施形態を図示する概略的なブロック図である。 ネットワークノードの実施形態を図示する概略的なブロック図である。

図面は必ずしも縮尺通りではなく、特定の特徴の寸法は、明瞭化のために誇張されている可能性がある。その代わりに、本実施形態の原理を説明することが重要視されている。

本実施形態は、ネットワークノードにおけるポリシングメカニズムを改善する。モバイルノードから対応ノードに送信されるウィンドウサイズは、ポリシングの間ダウンリンク方向における不必要なトラフィック破棄を回避するように最適化される。これは、ＴＣＰトラフィックタイプのダウンリンクトラフィックに適用される。最適ウィンドウサイズは、ＰＤＰコンテキスト上のポリシングにおいてネットワークノードがパケットを破棄するまで使用されることはない。最初の時点で、モバイルノードは、最適ウィンドウサイズよりも大きい、オリジナルウィンドウサイズを対応ノードに告知する。以前にトラフィックの破棄が全くないため、ウィンドウサイズはネットワークノードによって最適化されない。ネットワークノードがＰＤＰ上でポリシングを行い、ＭＢＲを超過することに起因してトラフィックを破棄する場合にのみ、最適ウィンドウサイズを使用するであろう。そうでない場合、それが最適ウィンドウサイズにより示されるよりも大き過ぎるようであるとしても、ネットワークノードは、ＴＣＰトラフィックにおけるオリジナルウィンドウサイズを変更しないままにするであろう。これは、可能な限り許容レベルで性能を維持するためである。

図１は、本実施形態が実装され得る、無線通信ネットワーク１００を示す。通信ネットワーク１００は、いくつかの実施形態では、例えば、ＬＴＥ、ＬＴＥ Ａｄｖａｎｃｅｄ、ＵＭＴＳ、ＧＳＭ、ＷＣＤＭＡ、又は任意の他の３ＧＰＰ無線アクセス技術等の、１以上の無線アクセス技術に適用され得る。

通信ネットワーク１００は、ネットワークノード１１０を介して対応ノード１０５と通信するモバイルノード１０１を含む。

モバイルノード１０１は、任意の適切な通信装置又は対応ノード１０５と通信することが可能な通信ケイパビリティを有する計算装置（computational device）であってもよく、例えば、モバイルフォン、スマートフォン、ＰＤＡ（personal digital assistant）、タブレットコンピュータ、ラップトップ、ＭＰ３プレイヤ又はポータブルＤＶＤプレイヤ（又は類似のメディアコンテンツ装置）、デジタルカメラ、又はＰＣ等の固定された装置でさえあってもよいが、これらに限定されない。ＰＣは、ブロードキャスト／マルチキャストされたメディアのエンドステーションとしてモバイルステーションを介して接続されることもできる。モバイルノード１０１は、例えば、電子フォトフレーム、心臓監視、侵入又は他の監視機器、気象データ監視システム、乗り物、車または伝送通信機器等に組み込まれる通信装置であってもよい。モバイルノード１０１は、いくつかの図面においてＭＮと称される。

対応ノード１０５は、ピアノードと呼ばれてもよく、モバイル又は固定のいずれかであり得る。それは、メールサーバ、インスタントメッセンジャサーバ、ソーシャルネットワークウェブサイト、ゲームサーバ、ＩＭＳネットワーク内のＩＭＳノード等であってもよい。

ネットワークノード１１０は、例えば、ｅＮＢ、ＲＮＣ、ＳＧＷ、ＰＧＷ、ＳＧＳＮ、ＧＧＳＮ又はＤＰＩノードであってもよい。

モバイルノード１０１、ネットワークノード１１０及び対応ノード１０５間の通信リンクは、有線又は無線のいずれかを含む任意の適切な種類のリンクであってもよいことに留意すべきである。当該リンクは、当業者により理解される、例えばＯＳＩ（Open Systems Interconnection）モデルにより示されるタイプ及びレイヤのレベルに依存した、任意の適切なプロトコルを使用してもよい。

実施形態の例によれば、パケット交換ネットワーク内のＴＣＰトラフィックをハンドリングするための方法について、図２に示されるシグナリング図及びフローチャートの組み合わせを参照してここで説明する。ネットワークノード１１０は、前述したようにポリシング機能を実行する。ネットワークノード１１０は、ステップ２０１に入る前に、いかなるＴＣＰトラフィックも破棄したことがない。方法は、以下のステップを含み、当該ステップは、後述するのとは別の適切な順序で実行されてもよい。

ステップ２０１
モバイルノード１０１は、初めてアップリンクＴＣＰトラフィックをネットワークノード１１０に送信する。アップリンクＴＣＰトラフィックは、ＴＣＰヘッダ内にＴＣＰ ＡＣＫを含む。ＴＣＰ ＡＣＫメッセージは、モバイルノード１０１が対応ノード１０５から受け取る用意がある未処理データの量を示すウィンドウサイズを含む、ウィンドウ告知メッセージ（window advertisement message）である。未処理データの量は、オリジナルウィンドウサイズとも呼ばれることができ、ＴＣＰ ＡＣＫメッセージ内のフィールドである。

ＴＣＰトラフィックは、ＧＴＰ−ＵペイロードのＴ−ＰＤＵに含まれる。

ステップ２０２
ネットワークノード１１０は、アップリンクＴＣＰトラフィックを検査し、それがＴＣＰ ＡＣＫメッセージを含むかを判定する。ＴＣＰ ＡＣＫメッセージに含まれるオリジナルウィンドウサイズを検査するとき、ネットワークノード１１０は、オリジナルウィンドウサイズを最適ウィンドウサイズと比較し、オリジナルウィンドウサイズが最適ウィンドウサイズよりも大きいかを判定する。

最適ウィンドウサイズは、ＰＤＰ ＱｏＳのＭＢＲ率に関連付けられていてもよく、ＭＢＲと線型的な関係を有する。最適ウィンドウサイズは、固定又は可変のパラメータであってもよい。それは、実行時間の間動的に変化してもよい。ネットワークノード１１０は、ステップサイズとともにＰＤＰ上の最適ウィンドウサイズを減少させてもよい。但し、最適ウィンドウサイズは、予め定義された低い方のウォータマークより低くないかもしれない。

オリジナルウィンドウサイズが、最適ウィンドウサイズよりも大きいと判定すると、ネットワークノード１１０は、ＰＤＰコンテキスト上のポリシングにおいてそれが以前にパケットを破棄したことがあるか否かを調査する。ネットワークノード１１０が、以前にいかなるトラフィックも破棄したことがない場合、ネットワークノード１１０は、オリジナルウィンドウサイズの置換は全く必要ないと判定する。

オリジナルウィンドウサイズが最適ウィンドウサイズよりも小さいとネットワークノード１１０が判定する場合、ネットワークノード１１０はまた、オリジナルウィンドウサイズの置換は全く必要ないと判定する。

ステップ２０３
この例では、ネットワークノード１１０は、以前に破棄されたトラフィックを全く検知しなかったため、変更されていないオリジナルウィンドウサイズを含むアップリンクＴＣＰトラフィックを対応ノード１０５に転送する。それが最適ウィンドウサイズ、即ちＭＢＲよりも大きいとしても、それは、ＴＣＰ ＡＣＫ内のオリジナルウィンドウサイズを変更しないまま維持する。これは、性能を可能な限り同一のレベルに保つためである。

ステップ２０４
対応ノード１０５は、ネットワークノード１１０からオリジナルウィンドウサイズを含むアップリンクＴＣＰトラフィックを受信し、ネットワークノード１１０にダウンリンクＴＣＰトラフィックを送信することにより、ネットワークノード１１０に応答を返す。

ステップ２０５
ネットワークノード１１０は、そのポリシング機能を実行する。ポリシング機能の結果は、ダウンリンクＴＣＰトラフィックは、ネットワークノード１１０のＭＢＲを超過しているということであり、したがって、ネットワークノード１１０は、ＴＣＰトラフィックを破棄する。

オリジナルウィンドウサイズに加えて、ネットワーク環境、ルータ上のパケットスケジューラ、アプリケーションの種類、ＩＰセグメント等の他の要因が、ポリシングのトラフィック破棄に影響を及ぼす可能性がある。しかしながら、オリジナルウィンドウサイズは、ＴＣＰトラフィックを破棄する主要な理由であり得る。

ステップ２０６
ネットワークノード１１０は、その状態（state）を、ＴＣＰトラフィックを全く破棄していない状態からＴＣＰトラフィックを破棄したことを示す状態に変更する。状態は、例えばフラグによって表されることができ、“０”は、ネットワークノード１１０がＴＣＰトラフィックを全く破棄していないことを示し、“１”は、ネットワークノード１１０がＴＣＰトラフィックを破棄したことを示す。

ステップ２０７
モバイルノード１０１は、２回目のアップリンクＴＣＰトラフィックをネットワークノード１１０に送信する。アップリンクＴＣＰトラフィックは、ＴＣＰ ＡＣＫメッセージを含む。オリジナルウィンドウサイズは、ＴＣＰ ＡＣＫメッセージ内のフィールドである。

ステップ２０８
ネットワークノード１１０は、第２のアップリンクＴＣＰトラフィックを検査し、それがＴＣＰ ＡＣＫメッセージを含むかを判定する。ＴＣＰ ＡＣＫメッセージに含まれるオリジナルウィンドウサイズを検査するとき、ネットワークノード１１０は、オリジナルウィンドウサイズを最適ウィンドウサイズと比較し、オリジナルウィンドウサイズが最適ウィンドウサイズよりも大きいと判定する。言い換えると、モバイルノード１０１は、通信ネットワーク１００における性能に最適ではない量のＴＣＰトラフィックを送信することを望んでおり、したがって、ネットワーク性能により適したそのＴＣＰトラフィックの量を減らす必要がある。ステップ２０６で、ネットワークノードは、その状態を変更したので、ネットワークノード１１０は、ＴＣＰトラフィック内のＴＣＰ ＡＣＫメッセージにおいて、オリジナルウィンドウサイズを最適ウィンドウサイズと置換する。

ネットワークノード１１０は、モバイルノード１０１から対応ノード１０５に告知されたオリジナルウィンドウサイズを知っている。告知されたオリジナルウィンドウサイズが大きすぎる場合、ネットワークノード１１０は、このオリジナルウィンドウサイズを適正な値、即ち最適ウィンドウサイズに修正し得る。最適ウィンドウサイズは、ＴＣＰ性能及びスループットに影響を及ぼさない。さらに、最適ウィンドウサイズは、ネットワークノード１１０上でポリシングのＴＣＰトラフィック破棄を引き起こすことはない。

いくつかの実施形態では、対応ノード１０５へのＴＣＰ ＡＣＫにおいてネットワークノード１１０が最適ウィンドウサイズを使用しているとしても、ネットワークノード１１０におけるポリシング機能は、ダウンリンク速度がＭＢＲを超過していることに起因してＴＣＰトラフィックをなお破棄する。その後、ネットワークノード１１０は、ステップサイズとともにこのＰＤＰ上の最適ウィンドウサイズを減少させ、減少した最適ウィンドウサイズをＴＣＰ ＡＣＫメッセージに適用し得る。ポリシング機能がなおＴＣＰトラフィック破棄を引き起こす場合、ネットワークノード１１０は、最適ウィンドウサイズをさらに減少させ得る。しかしながら、最適ウィンドウサイズは、予め定義された低い方のウォータマークよりも低くなることはない。

ステップ２０９
ネットワークノード１１０は、最適ウィンドウサイズを含むアップリンクＴＣＰトラフィックを対応ノード１０５に転送する。

ステップ２１０
対応ノード１０５は、最適ウィンドウサイズを含むアップリンクＴＣＰトラフィックを受信する。対応ノード１０５は、ここで、オリジナルウィンドウサイズよりも小さい最適ウィンドウサイズについての情報を有するため、それは、ＴＣＰトラフィックを送信するその速度を落とす。

図３は、ＬＴＥに基づく通信ネットワーク１００の例示的な実施形態を図示するブロック図である。通信ネットワーク１００は、ｅノードＢ３０１と通信するモバイルノード１０１を含む。ｅノード３０１は、用いられる技術及び専門用語に依存して、基地局、ＲＢＳ、ｅＮＢ、ノードＢ、Ｂノード、ＢＴＳとも呼ばれ得る。基地局３０１は、ＳＧＷ３０５及びＰＧＷ３１０を含むコアネットワークに接続されている。ＰＧＷ３１０は、例えば、モバイルノード１０１にインターネットサービスを提供するインターネットホストを表す、対応ノード１０５に接続されている。図３では、ネットワークノード１１０は、ＳＧＷ３０５により例示されている。

パケット交換ネットワーク内でＴＣＰトラフィックをハンドリングするための方法は、図３に示すＬＴＥに基づく通信ネットワーク１００の例示的な実施形態によれば、図４に示すシグナリング図及びフローチャートの組み合わせを参照してここで説明される。図４では、ｅノードＢ３０１、ＳＧＷ３０５及びＰＧＷ３１０の各々がＧＳＮノードと呼ばれ得る。４Ｇ ＬＴＥネットワークでは、ｅノードＢ３０１、ＳＧＷ３０５及びＰＧＷ３１０の各々は、ネゴシエートされたベアラＰＤＰのＱｏＳパラメータに従って、ダウンリンク方向でのポリシング機能を実行する。この例では、ネットワークノード１１０は、ＳＧＷ３０５である。しかしながら、実施形態は、他のＧＳＮのうちのいずれか又は図４に図示される全てのＧＳＮノードにおいて実装されてもよい。図４中の全てのＧＳＮノードが本実施形態を実装する例において、ＴＣＰ ＡＣＫメッセージの二重検査を回避するために、ＧＳＮノードのうちの１つがアクティブ化されてもよい。ＳＧＷ３０５は、ステップ４０１に入る以前には、いかなるＴＣＰトラフィックも破棄したことがない。方法は、以下のステップを含み、それらのステップは、後述されているのとは別の適切な順序で実行されてもよい。

ステップ４０１
このステップは、図２のステップ２０１に対応する。モバイルノード１０１は、初めてｅノードＢ３０１にアップリンクＴＣＰトラフィックを送信する。アップリンクＴＣＰトラフィックは、ＴＣＰ ＡＣＫメッセージを含む。ＴＣＰ ＡＣＫメッセージは、ＴＣＰ ＡＣＫメッセージ内のフィールドとしてオリジナルウィンドウサイズを含む。アップリンクＴＣＰトラフィックは、また、ウィンドウ告知メッセージとも呼ばれ得る。

ステップ４０２
このステップは、図２のステップ２０１に対応している。ｅノードＢ３０１は、ＧＴＰプロトコルを用いて、即ちＧＴＰペイロード内で、ＳＧＷ３０５にアップリンクＴＣＰトラフィックを転送する。

ステップ４０３
このステップは、図２のステップ２０２に対応している。ＳＧＷ３０５は、アップリンクＴＣＰトラフィックを検査し、アップリンクＴＣＰトラフィックがＴＣＰ ＡＣＫメッセージを含むかを判定する。アップリンクＴＣＰトラフィックがＴＣＰ ＡＣＫメッセージを含む場合、ＳＧＷ３０５は、ＴＣＫ ＡＣＫメッセージ内のオリジナルウィンドウサイズがＰＤＰコンテキスト内の最適ウィンドウサイズよりも大きいかをチェックする。

ＴＣＰ ＡＣＫメッセージに含まれるオリジナルウィンドウサイズを検査するとき、ＳＧＷ３０５は、オリジナルウィンドウサイズを最適ウィンドウサイズと比較し、オリジナルウィンドウサイズが最適ウィンドウサイズよりも大きいかを判定する。

上述したように、ＳＧＷ３０５は、ネゴシエートされたベアラＰＤＰのＱｏＳパラメータに従って、ダウンリンク方向上でポリシングを実行する。ユーザプレーンにおいては、ＧＴＰ−Ｕ ＴＣＰトラフィックは、ポリシングの対象となり、検査される。ＰＤＵを伝送するＴ−ＰＤＵは、ユーザトラフィックであり、ＴＣＰのタイプである。これは、図５において図示され、ＬＴＥトランスポートプロトコルスタックを表す。ｅノードＢ３０１、ＳＧＷ３０５及びＰＧＷ３１０の周りの点線は、それらが図１においてネットワークノード１１０と呼ばれることを示す。ＩＰは、図５に示されるＬＴＥトランスポートプロトコルスタックの“下位レベル”と呼ばれ得る。図５の最も左の列では、モバイルノード１０１についてＴＣＰがＩＰの上に構築されているものとして示されている。図５の最も左の列のＰＤＵ５０１は、ＩＰ及びＴＣＰを含む。図５の中間の左列及び中間の右列では、ＵＤＰ（User Datagram Protocol）がＩＰの上に構築されている。ＧＴＰは、ＵＤＰ又はＴＣＰとともに使用され得る。中間の左列及び中間の右列には、ＴＣＰ及びＩＰを含むＴ−ＰＤＵ５０３が含まれる。最も左の列にはＴＣＰ及びＩＰを含むＰＤＵ５０１が示されている。

オリジナルウィンドウサイズが最適ウィンドウサイズより大きいと判定した後、ＳＧＷ３０５は、それが以前にＰＤＰコンテキスト上のポリシングにおいてトラフィックを破棄したことがあるか否かを調査する。ＳＧＷ３０５が、以前にポリシングに起因してＰＤＰ上のいかなるトラフィックも破棄していない場合、ＳＧＷ３０５は、オリジナルウィンドウサイズを置換する必要はない、即ちＳＧＷ３０５は何のアクションも取らないと判定する。

ＳＧＷ３０５が、オリジナルウィンドウサイズが最適ウィンドウサイズよりも小さいと判定する場合、ＳＧＷ３０５は、また、オリジナルウィンドウサイズを置換する必要はないと判定する。

ステップ４０４
このステップは、図２のステップ２０３に対応する。ＳＧＷ３０５は、以前に破棄されたトラフィックを検出することができなかったため、ＧＴＰペイロード内の変更されていないオリジナルウィンドウサイズを含むアップリンクＴＣＰトラフィックをＰＧＷ３１０に転送する。それが最適ウィンドウサイズ、即ちＭＢＲよりも大きいとしても、それは、ＴＣＰ ＡＣＫ内のオリジナルウィンドウサイズを変更しないまま維持する。これは、可能な限り性能を同一レベルに維持するためである。

ステップ４０５
このステップは、図２のステップ２０３に対応する。ＰＧＷ３１０は、ＳＧＷ３０５からオリジナルウィンドウサイズを含むアップリンクＴＣＰトラフィックを受信し、対応ノード１０５にダウンリンクＴＣＰトラフィックを転送する。

ステップ４０６
このステップは、図２のステップ２０４に対応する。対応ノード１０５は、ＰＧＷ３１０からオリジナルウィンドウサイズを含むアップリンクＴＣＰトラフィックを受信し、ＰＧＷ３１０にダウンリンクＴＣＰトラフィックを送信することによって、ＰＧＷ３１０に応答を返す。

対応ノード１０５からモバイルノード１０１へのダウンリンクＰＤＵは、ＧＴＰトンネル内のパケットコアネットワークにおいて、Ｔ−ＰＤＵになる。

ステップ４０７
このステップは、図２のステップ２０４に対応する。ＰＧＷ３１０は、ＳＧＷ３０５にＧＴＰペイロード内に含まれるダウンリンクＴＣＰトラフィックを転送する。

ステップ４０８
このステップは、図２のステップ２０５に対応する。しばらくしてから、モバイルノード１０１から対応ノード１０６に送信された大きなオリジナルウィンドウサイズに起因して、少しの間、ダウンリンクの速度がＭＢＲを超過する。ＳＧＷ３０５は、ＭＢＲなどのＱｏＳパラメータに基づいて、そのポリシング機能を実行する。ポリシング機能の結果は、ダウンリンクＴＣＰトラフィックが、ＳＧＷ３０５のＭＢＲを超過し、したがってＳＧＷ３０５がＴＣＰトラフィックを破棄することである。

ステップ４０９
このステップは、図２のステップ２０６に対応する。ＳＧＷ３０５は、その状態（state）を、ＴＣＰトラフィックを全く破棄したことがない状態から、ＴＣＰトラフィックを破棄したことがあることを示す状態に変更する。

ステップ４１０
このステップは、図２のステップ２０７に対応する。モバイルノード１０１は、２回目のアップリンクＴＣＰトラフィックをｅノードＢ３０１に送信する。アップリンクＴＣＰトラフィックは、ＴＣＰ ＡＣＫメッセージを含む。オリジナルウィンドウサイズは、ＴＣＰ ＡＣＫメッセージ内のフィールドである。

ステップ４１１
このステップは、図２のステップ２０７に対応する。ｅノードＢ３０１は、ＳＧＷ３０５にＧＴＰプロトコルを用いて、即ちＧＴＰペイロード内でアップリンクＴＣＰトラフィックを転送する。

ステップ４１２
このステップは、図２のステップ２０８に対応する。ＳＧＷ３０５は、新たなアップリンクＴＣＰトラフィックを検査し、それがＰＤＰレベル毎にＴＣＰ ＡＣＫメッセージを含むかを判定する。上述したように、ＴＣＰ ＡＣＫメッセージは、パケット交換ネットワーク１００内のＧＴＰ−Ｕトンネル上で送信される。ＴＣＰ ＡＣＫメッセージに含まれるオリジナルウィンドウサイズを検査するとき、ＳＧＷ３０５は、オリジナルウィンドウサイズを最適ウィンドウサイズと比較し、オリジナルウィンドウサイズが最適ウィンドウサイズよりも大きいかを判定する。言い換えると、モバイルノード１０１は、通信ネットワーク１００における性能に対し最適でない量のＴＣＰトラフィックを送信することを望んでおり、したがって、ネットワーク性能に対しより適切な、最適化された量のＴＣＰトラフィックを送信するように指示される必要がある。ＳＧＷ３０５は、ステップ４０９でその状態を変更し、従って、モバイルノード１０１から対応ノード１０５に送信された大きすぎるオリジナルウィンドウサイズに起因してトラフィックが破棄されたことがあることを知っているため、ＳＧＷ３０５は、ＴＣＰトラフィック内のＴＣＰ ＡＣＫメッセージにおいて、オリジナルウィンドウサイズを最適ウィンドウサイズと置換する。言い換えると、ＴＣＰ ＡＣＫメッセージ内のオリジナルウィンドウサイズは、最適ウィンドウサイズに更新される。最適ウィンドウサイズは、ＳＧＷ３０５において予め定められることができ、ＰＤＰ ＱｏＳコンテキストに関連付けられる。

ステップ４１３
このステップは、図２のステップ２０９に対応する。ＳＧＷ３０５は、最適ウィンドウサイズを含み、ＧＴＰペイロードに含まれるアップリンクＴＣＰトラフィックをＰＧＷ３１０に転送する。

ステップ４１４
このステップは、図２のステップ２０９に対応する。ＰＧＷ３１０は、最適ウィンドウサイズを含むアップリンクＴＣＰトラフィックを対応ノード１０５に送信する。

ステップ４１５
このステップは、図２のステップ２１０に対応する。対応ノード１０５は、最適ウィンドウサイズを含むアップリンクＴＣＰトラフィックを受信する。対応ノード１０５は現在、オリジナルウィンドウサイズよりも小さい最適ウィンドウサイズについての情報を有するため、ＴＣＰトラフィックを送信するその速度を落とす。

図２及び図４に例示されたように、パケット交換ネットワークにおけるＴＣＰトラフィックをハンドリングする方法の例は、ここで図６のネットワークノード１１０の観点から見て説明されるであろう。方法は、以下のステップを含み、それらのステップは、後述されているのとは別の適切な順序で実行されてもよい。

ステップ６０１
このステップは、図２のステップ２０１並びに図４のステップ４０１及び４０２に対応する。ネットワークノード１１０は、モバイルノード１０１からアップリンクＴＣＰトラフィックを受信する。いくつかの実施形態においては、ＴＣＰトラフィックは、ＧＴＰペイロード内に含まれる。

ステップ６０２
このステップは、図２のステップ２０２及び２０８並びに図４のステップ４０３及び４１２に対応する。ネットワークノード１１０は、ＴＣＰトラフィックがＴ−ＰＤＵタイプかどうかチェックする。ＴＣＰトラフィックがＴ−ＰＤＵタイプではない場合、図６で“Ｎｏ”で示され、方法は終了するか又はステップ６０１に戻る。ＴＣＰトラフィックがＴ−ＰＤＵタイプである場合、図６で“Ｙｅｓ”で示され、方法はステップ６０３に進む。

ステップ６０３
このステップは、図２のステップ２０２及び２０８並びに図４のステップ４０３及び４１２に対応する。ＴＣＰトラフィックがＴ−ＰＤＵタイプであるとネットワークノード１１０が判定したとき、それは、ＴＣＰトラフィックがＴＣＰ ＡＣＫを含むかどうかをチェックする。ＴＣＰトラフィックがＴＣＰ ＡＣＫを含まない場合、図６で“Ｎｏ”で示され、方法は終了するか又はステップ６０１に戻る。ＴＣＰトラフィックがＴＣＰ ＡＣＫを含む場合、図６で“Ｙｅｓ”で示され、方法はステップ６０４に進む。

ステップ６０４
このステップは、図２のステップ２０２及び２０８並びに図４のステップ４０３及び４１２に対応する。このステップは、ステップ６０５の前又は後に実行されてもよい。ＴＣＰトラフィックがＴＣＰ ＡＣＫを含むことをネットワークノード１１０が判定したとき、それは、オリジナルウィンドウサイズを最適ウィンドウサイズと比較する。比較の結果、オリジナルウィンドウサイズが最適ウィンドウサイズよりも小さい場合、図６で“Ｎｏ”で示され、方法は終了するか又はステップ６０１に戻る。比較の結果、オリジナルウィンドウサイズが最適ウィンドウサイズよりも大きい場合、図６で“Ｙｅｓ”で示され、方法はステップ６０５に進む。

ステップ６０５
このステップは、図２のステップ２０２及び２０８並びに図４のステップ４０３及び４１２に対応する。オリジナルウィンドウサイズが最適ウィンドウサイズよりも大きいとネットワークノード１１０が判定したとき、ネットワークノード１１０は、ネットワークノード１１０がポリシングに起因してＴＣＰトラフィックを破棄したことがあるかどうかを判定することに進む。ネットワークノード１０１が、ポリシングに起因してＴＣＰトラフィックを破棄したことがない場合、図６で“Ｎｏ”で示され、方法は終了するか又はステップ６０１に戻る。ネットワークノード１１０が、ポリシングに起因してＴＣＰトラフィックを破棄したことがある場合、図６で“Ｙｅｓ”で示され、方法はステップ６０６に進む。

ステップ６０６
このステップは、図２のステップ２０８及び図４のステップ４１２に対応する。ネットワークノード１１０が、以前にポリシングに起因してＴＣＰトラフィックを破棄したことがあると判定したとき、それは、オリジナルウィンドウサイズを最適ウィンドウサイズと置換し、最適ウィンドウサイズを含むアップリンクＴＣＰトラフィックを対応ノード１０５に転送する。

他の例示的な実施形態では、ネットワークノード１１０は、ポリシング機能を実装するＤＰＩノードであってもよい。ＤＰＩノードは、図のいずれにも示されていない。ＤＰＩは、Ｇｉインタフェース上に存在し得る。ＤＰＩは、ＰＤＰコンテキストを知らず、５タプルによって識別されるＩＰフローに対処するのみである。ＤＰＩは、Ｇｘインタフェースを介してＰＣＲＦからＱｏＳ情報を得る。Ｇｘインタフェースは、ＧＧＳＮ及びＰＣＲＦ間のオンラインポリシーインタフェースであり、課されるルールに基づいて、サービスデータフローをプロビジョニングするために使用される。ＤＰＩは、パケットを検査するのに良好なケイパビリティを有するため、モバイルノード１０１から対応ノード１０５へのＴＣＰトラフィックフロー内のＴＣＰ ＡＣＫのオリジナルウィンドウサイズを知ることはＤＰＩには非常に容易である。ネットワークノード１１０が、ＤＰＩとして例示される場合、方法は、上述した図２、図４及び図６に示されるのと同一である。オリジナルウィンドウサイズが最適ウィンドウサイズよりも大きく、ＤＰＩノード上のポリシングに起因してトラフィック破棄があった場合、最適ウィンドウサイズが使用される。

いくつかの実施形態では、Ｇｉインタフェース上にＤＰＩがある場合、本実施形態は、ＤＰＩノード上で使用され得る。そして、ネットワーク内のノードの中の全ての他のノードは、本実施形態を実装しない。

本実施形態がオペレータのネットワーク内で実装される場合、本実施形態は、全てのネットワークノード１１０において実装され、本実施形態は、動的にアクティブ化又は非アクティブ化される。

本実施形態は、３Ｇ ＵＭＴＳネットワークに適用されることもできる。ＲＮＣ、ＳＧＳＮ及びＧＧＳＮ（図示せず）の各々は、ダウンリンクペイロードがＭＢＲレートを超過することを回避するためにポリシング機能を有する。例として、ＳＧＳＮペイロードを取り上げる。ＳＧＳＮは、ダウンリンクユーザプレーンＧＴＰ−Ｕトラフィックにポリシングを実行する。速度がＭＢＲを超過する場合、ポリシングはＰＤＰ上でトラフィックを破棄するであろう。本実施形態によれば、ＭＢＲに達するときには、ポリシングのトラフィック破棄を回避するために、モバイルノード１０１から対応ノード１０５に送信されたＴＣＰ ＡＣＫ内の最適ウィンドウサイズが使用される。

本実施形態は、ＳＧＳＮ及びＧＧＳＮを含む、２Ｇ ＧＳＭネットワークに適用されることもできる。

上述した方法のいくつかの実施形態は、ここでネットワークノード１１０の観点から見て説明されるであろう。図７は、ネットワークノード１１０における、パケット交換ネットワーク１００内でＴＣＰトラフィックをハンドリングするための本方法を記述するフローチャートである。いくつかの実施形態では、パケット交換ネットワーク１００は、ＧＳＭ、ＵＭＴＳ又はＬＴＥに基づく。いくつかの実施形態では、ネットワークノード１１０は、ｅＮＢ、ＳＧＷ、ＰＧＷ、ＲＮＣ、ＳＧＳＮ、ＧＧＳＮ又はＤＰＩノードである。方法はネットワークノード１１０によって実行されるべき以下のステップを含み、それらのステップは、任意の適切な順番が取られてもよい。

ステップ７０１
このステップは、図２のステップ２０１及び２０７、図４のステップ４０１、４０２、４１０及び４１１、並びに図６のステップ６０１に対応する。ネットワークノード１１０は、モバイルノード１０１からＴＣＰトラフィックを受信する。ＴＣＰトラフィックは、オリジナルウィンドウサイズを含む。ネットワークノード１１０は、ここで、ＴＣＰトラフィックを検査するための準備ができる。いくつかの実施形態では、ＴＣＰトラフィックはＴＣＰ ＡＣＫメッセージを含み、ＴＣＰ ＡＣＫメッセージはオリジナルウィンドウサイズを含む。

ステップ７０２
このステップは、図２のステップ２０２及び２０８、図４のステップ４０３及び４１２、並びに図６のステップ６０２に対応する。いくつかの実施形態では、ネットワークノード１１０は、受信されたＴＣＰトラフィックを検査し、ＴＣＰトラフィックがＧＴＰ−ＵペイロードのＴ−ＰＤＵに含まれるかを判定する。

ステップ７０３
このステップは、図２のステップ２０２及び２０８、図４のステップ４０３及び４１２、並びに図６のステップ６０３に対応する。いくつかの実施形態では、ネットワークノード１１０は、受信されたＴＣＰトラフィックを検査し、ＴＣＰトラフィックがＴＣＰ ＡＣＫメッセージを含むかを判定する。

ステップ７０４
このステップは、図２のステップ２０２及び２０８、図４のステップ４０３及び４１２、並びに図６のステップ６０５に対応する。いくつかの実施形態では、ネットワークノード１１０は、受信されたＴＣＰトラフィックを検査し、ネットワークノード１１０が破棄されたＴＣＰトラフィックについての情報を有するかどうかを判定する。いくつかの実施形態では、ネットワークノード１１０は、ポリシング機能を含み、破棄されたＴＣＰトラフィックは、ポリシング機能に関連付けられる。

ステップ７０５
このステップは、図２のステップ２０２及び２０８、図４のステップ４０３及び４１２並びに図６のステップ６０４に対応する。このステップは、ステップ７０４の前又は後に実行されてもよい。いくつかの実施形態では、ネットワークノード１１０は、受信されたＴＣＰトラフィックを検査し、オリジナルウィンドウサイズが最適ウィンドウサイズよりも大きいかどうかを判定する。いくつかの実施形態では、最適ウィンドウサイズは、ネットワークノード１１０において予め定義されている。いくつかの実施形態では、最適ウィンドウサイズは、ＭＢＲに関連付けられている。ＭＢＲは、ＰＤＰ又はベアラのものである。最適ウィンドウサイズは、固定の最適ウィンドウサイズ又は動的な最適ウィンドウサイズであってもよい。

ステップ７０７
いくつかの実施形態では、ネットワークノード１１０は、オリジナルウィンドウサイズの置換をアクティブ化する。ネットワークノード１１０は、例えば、モバイルノード１０１又は対応ノード１０５から指示を受信した時点でオリジナルウィンドウサイズの置換をアクティブ化してもよく、又は、予め定められた時間後若しくは一定間隔で置換をアクティブ化してもよい。

ステップ７０８
このステップは、図２のステップ２０８、図４のステップ４１２及び図６のステップ６０６に対応する。ネットワークノード１１０が破棄されたＴＣＰトラフィックについての情報を有するとき、且つオリジナルウィンドウサイズが最適ウィンドウサイズよりも大きいときに、ネットワークノード１１０は、オリジナルウィンドウサイズを最適ウィンドウサイズと置換する。

ステップ７０９
このステップは、図２のステップ２０９、並びに図４のステップ４１３及び４１４に対応する。ネットワークノード１１０は、モバイルノード１０１により受信可能なＴＣＰトラフィックの量を示す、最適ウィンドウサイズを含むＴＣＰトラフィックを、パケット交換ネットワーク１００内の対応ノードに送信する。

ステップ７１０
このステップは、図２のステップ２０３、並びに図４のステップ４０４及び４０５に対応する。いくつかの実施形態では、ネットワークノード１１０が、破棄されたＴＣＰトラフィックについての情報を全く有しない場合、ネットワークノード１１０は、オリジナルウィンドウサイズを含むＴＣＰトラフィックを対応ノード１０５に転送する。

ステップ７１１
いくつかの実施形態では、ネットワークノード１１０は、オリジナルウィンドウサイズの置換を非アクティブ化する。長い間全くトラフィック破棄がなかった場合、ネットワークノード１１０は、オリジナルウィンドウサイズの置換を非アクティブ化する。長い間全くトラフィック破棄がなかったことを検出できるようにするために、ネットワークノード１１０は、トラフィック破棄の間の時間を監視し、当該時間が予め定められた閾値を超過したときに、置換を非アクティブ化する。

図７に示す、パケット交換ネットワーク１００内でＴＣＰ（transmission control protocol）トラフィックをハンドリングするための方法ステップを実行するために、ネットワークノード１１０は、図８に示すような配置を含む。いくつかの実施形態では、ネットワークノード１１０は、ポリシング機能を含み、破棄されるＴＣＰトラフィックは、ポリシング機能に関連付けられる。いくつかの実施形態では、パケット交換ネットワーク１００は、ＧＳＭ、ＵＭＴＳ又はＬＴＥに基づく。いくつかの実施形態では、ネットワークノード１１０は、ｅＮＢ、ＳＧＷ、ＰＧＷ、ＲＮＣ、ＳＧＳＮ、ＧＧＳＮ又はＤＰＩノードである。

ネットワークノード１１０は、モバイルノード１０１からＴＣＰトラフィックを受信するように構成される受信機８０１を含む。ＴＣＰトラフィックは、オリジナルウィンドウサイズを含む。

いくつかの実施形態では、ネットワークノード１１０は、オリジナルウィンドウサイズの置換をアクティブ化するように構成されるアクティブ化ユニット８０３を含む。

いくつかの実施形態では、ネットワークノードは、ネットワークノード１１０が破棄されたＴＣＰトラフィックについての情報を有するかどうかを判定し、且つオリジナルウィンドウサイズが最適ウィンドウサイズより大きいかどうかを判定するように構成される、判定ユニット８０５を含む。いくつかの実施形態では、判定ユニット８０５は、ＴＣＰトラフィックがＧＴＰ−ＵペイロードのＴ−ＰＤＵに含まれるかを判定するようにさらに構成される。いくつかの実施形態では、最適ウィンドウサイズはネットワークノード１１０において予め定義されている。いくつかの実施形態では、最適ウィンドウサイズは、ＭＢＲに関連付けられる。最適ウィンドウサイズは、固定された最適ウィンドウサイズ又は動的な最適ウィンドウサイズであってもよい。いくつかの実施形態では、ＴＣＰトラフィックは、ＴＣＰ ＡＣＫメッセージを含む。ＴＣＰ ＡＣＫメッセージは、オリジナルウィンドウサイズを含む。いくつかの実施形態では、判定ユニット８０５は、ＴＣＰトラフィックがＴＣＰ ＡＣＫメッセージを含むかを判定するようにさらに構成される。

ネットワークノード１１０は、ネットワークノード１１０が破棄されたＴＣＰトラフィックについての情報を有する場合、且つオリジナルウィンドウサイズが最適ウィンドウサイズよりも大きい場合に、オリジナルウィンドウサイズを最適ウィンドウサイズと置換するように構成される、置換ユニット８０７を含む。

ネットワークノード１１０は、モバイルノード１０１により受信可能なＴＣＰトラフィックの量を示す最適ウィンドウサイズを含むＴＣＰトラフィックを、パケット交換ネットワーク１００内の対応ノード１０５に送信するように構成され得る、送信機８１０を含む。いくつかの実施形態では、送信機８１０は、ネットワークノード１１０が破棄されたＴＣＰトラフィックについての情報を全く有しない場合に、オリジナルウィンドウサイズを含むＴＣＰトラフィックを対応ノードに転送するようにさらに構成される。

いくつかの実施形態では、ネットワークノード１１０は、オリジナルウィンドウサイズの置換を非アクティブ化するように構成される、非アクティブ化ユニット８１３を含む。

パケット交換ネットワーク１００においてＴＣＰトラフィックをハンドリングするための本メカニズムは、本実施形態の機能を実行するためのコンピュータプログラムコードとともに、図８に示されるネットワークノードの配置におけるプロセッサ８２０のような１以上のプロセッサを通じて実装され得る。プロセッサは、例えば、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）プロセッサ、ＦＰＧＡ（Field-programmable gate array）プロセッサ又はマイクロプロセッサであってもよい。上述したプログラムコードは、例えば、ネットワークノード１１０にロードされているとき本実施形態を実行するためのコンピュータプログラムコードを伝達するデータキャリアの形式で、コンピュータプログラム製品として提供されてもよい。そのようなキャリアの１つが、ＣＤ ＲＯＭディスクの形式であってもよい。しかしながら、メモリスティックのような他のデータキャリアで実現可能である。コンピュータプログラムコードは、さらに、サーバ上の純粋なプログラムコードとして提供されることができ、リモートでネットワークノード１１０にダウンロードされることができる。

上で示した実施形態のいくつかの例示的な実装について、ここで述べる。記載されたソリューションは、任意の適切な通信標準をサポートし、任意の適切なコンポーネントを使用する任意の適当な種類の通信ネットワークにおいて実装され得るが、記載されたソリューションの特定の実施形態は、図３に示されるようなＬＴＥネットワークにおいて実装されてもよい。例示的なネットワークは、ネットワークノード１１０を介したモバイルノード１０１及び対応ノード１０５の間の通信をサポートするのに適した、任意の追加的なエレメントをさらに含んでもよい。図示されたネットワークノード１１０は、ハードウェア及び／又はソフトウェアの任意の適切な組み合わせを含む通信装置を表し得るが、このネットワークノード１１０は、特定の実施形態において、図９により詳細に示される例示的なネットワークノード１１０のような装置を表す。

図９に示されるように、例示的なネットワークノード１１０は、処理回路９２０、メモリ９３０、無線回路９１０及び少なくとも１つのアンテナを含む。少なくとも１つのアンテナは、図８に示される受信機８０１及び送信機８１０に対応する。無線回路９１０は、ＲＦ（Radio Frequency）回路及びベースバンド処理回路（図示せず）を含むことができる。特定の実施形態では、ネットワークノード１１０により提供されているものとして上述された機能のうちのいくつか又は全てが、図９に示されるメモリ９３０等のコンピュータ読み取り可能な媒体に格納される命令を実行する、処理回路９２０によって提供され得る。図９に示される処理回路９２０は、図８に示されるプロセッサに対応する。ネットワークノード１１０の代替的な実施形態は、図９に示されるもの以上の追加的なコンポーネントを含んでもよい。当該コンポーネントは、上述した機能のうちのいずれか及び／又は上述した実施形態をサポートするために必要な任意の機能を含む、ネットワークノード１１０の機能の特定の特徴を提供することを担当することができる。

本実施形態は、上述した好ましい実施形態に限定されるものではない。様々な代替、変更及び均等物が使用され得る。したがって、上述の実施形態は、実施形態の範囲を限定するものとして受け取られるべきではなく、添付の特許請求の範囲によって定義される。

“含む（comprises/comprising）”という用語が本明細書で用いられる場合、定められた特徴、整数、ステップ又はコンポーネントの存在を特定するために受け取られるが、１以上の他の特徴、整数、ステップ、コンポーネント又はこれらの集合の存在又は追加を除外するものではないことを強調すべきである。エレメントに先立つ“a”又は“an”という語は、そのようなエレメントが複数存在することを排除するものではないことにも留意すべきである。

添付の特許請求の範囲において定義された方法のステップは、本実施形態から逸脱することなく、請求項に表れる順序とは異なる順序で実行され得ることも強調すべきである。

Claims (18)

1. パケット交換ネットワーク（１００）内でＴＣＰ（transmission control protocol）トラフィックをハンドリングするためのネットワークノード（１１０）における方法であって、前記ネットワークノード（１１０）は、Ｇｉインタフェース上でダウンリンクのユーザプレーントラフィックの送信レートを監視するポリシング機能を有するＤＰＩ（Deep Packet Inspection）ノードであり、前記方法は、
   オリジナルウィンドウサイズの情報を有するアップリンクＴＣＰトラフィックを、モバイルノード（１０１）から受信すること（２０１，４０１，４０２，４１０，４１１，６０１，７０１）と、
   前記ネットワークノード（１１０）の前記ポリシング機能により破棄される破棄ダウンリンクＴＣＰトラフィックに関する情報を前記ネットワークノード（１１０）が有しない場合に、対応ノードへ、前記オリジナルウィンドウサイズを有する前記アップリンクＴＣＰトラフィックを転送すること（２０３，４０４，４０５，７１０）と、
   前記ネットワークノード（１１０）が前記ポリシング機能に関連付けられる破棄ダウンリンクＴＣＰトラフィックに関する情報を有すると共に、前記オリジナルウィンドウサイズが最適ウィンドウサイズよりも大きい場合に、前記オリジナルウィンドウサイズを前記最適ウィンドウサイズに置換すること（２０８，４１２，６０６，７０８）と、
   前記パケット交換ネットワーク（１００）内の前記対応ノード（１０５）へ、前記モバイルノード（１０１）により受信可能なダウンリンクＴＣＰトラフィックの量を示す、前記最適ウィンドウサイズを有する前記アップリンクＴＣＰトラフィックを送信すること（２０９，４１３，４１４，７０９）と、
   を含む方法。
2. 前記ネットワークノード（１１０）が前記破棄ダウンリンクＴＣＰトラフィックに関する情報を有するかを判定すること（２０２，２０８，４０３，４１２，６０５，７０４）と、
   前記オリジナルウィンドウサイズが前記最適ウィンドウサイズよりも大きいかを判定すること（２０２，２０８，４０３，４１２，６０４，７０５）と、
   をさらに含む、請求項１に記載の方法。
3. 前記オリジナルウィンドウサイズの前記置換をアクティブ化すること（７０７）と、
   前記オリジナルウィンドウサイズの前記置換を非アクティブ化すること（７１１）と、
   をさらに含む、請求項１〜２のいずれかに記載の方法。
4. 前記ＴＣＰトラフィックがＧＴＰ−Ｕ（general packet radio service tunnelling protocol user data tunneling）ペイロードのＴ−ＰＤＵ（transport protocol data unit）に含まれることを判定すること（２０２，２０８，４０３，４１２，６０２，７０２）、
   をさらに含む、請求項１〜３のいずれかに記載の方法。
5. 前記最適ウィンドウサイズは、前記ネットワークノード（１１０）において予め定義される、請求項１〜４のいずれかに記載の方法。
6. 前記最適ウィンドウサイズは、ＭＢＲ（maximum bit rate）に関連付けられる、請求項１〜５のいずれかに記載の方法。
7. 前記最適ウィンドウサイズは、固定された最適ウィンドウサイズ又は動的な最適ウィンドウサイズである、請求項１〜６のいずれかに記載の方法。
8. 前記アップリンクＴＣＰトラフィックは、ＴＣＰのＡＣＫ（acknowledgement）メッセージを含み、
   ＴＣＰ ＡＣＫメッセージは、前記オリジナルウィンドウサイズを含み、
   前記方法は、前記アップリンクＴＣＰトラフィックが前記ＴＣＰ ＡＣＫメッセージを含むことを判定すること（202、208、403、412、603、703）をさらに含む、請求項１〜７のいずれかに記載の方法。
9. 前記パケット交換ネットワーク（１００）は、ＧＳＭ（global system for mobile communication）、ＵＭＴＳ（universal mobile telecommunications system）又はＬＴＥ（long term evolution）に基づく、請求項１〜８のいずれかに記載の方法。
10. パケット交換ネットワーク（１００）内でＴＣＰ（transmission control protocol）トラフィックをハンドリングするためのネットワークノード（１１０）であって、前記ネットワークノード（１１０）は、Ｇｉインタフェース上でダウンリンクのユーザプレーントラフィックの送信レートを監視するように構成されるポリシング機能を有するＤＰＩ（Deep Packet Inspection）ノードであり、前記ネットワークノード（１１０）は、
    オリジナルウィンドウサイズの情報を有するアップリンクＴＣＰトラフィックを、モバイルノード（１０１）から受信するように構成される受信機（８０１）と、
    前記ネットワークノード（１１０）の前記ポリシング機能により破棄される破棄ダウンリンクＴＣＰトラフィックに関する情報を前記ネットワークノード（１１０）が有しない場合に、対応ノードへ、前記オリジナルウィンドウサイズを有する前記アップリンクＴＣＰトラフィックを転送するように構成される送信機（８１０）と、
    前記ネットワークノード（１１０）が前記ポリシング機能に関連付けられる破棄ダウンリンクＴＣＰトラフィックに関する情報を有すると共に、前記オリジナルウィンドウサイズが最適ウィンドウサイズよりも大きい場合に、前記オリジナルウィンドウサイズを前記最適ウィンドウサイズに置換するように構成される置換ユニット（８０７）と、
    を含み、
    前記送信機（８１０）は、前記パケット交換ネットワーク（１００）内の前記対応ノード（１０５）へ、前記モバイルノード（１０１）により受信可能なダウンリンクＴＣＰトラフィックの量を示す、前記最適ウィンドウサイズを有する前記アップリンクＴＣＰトラフィックを送信するようにさらに構成される、
    ネットワークノード（１１０）。
11. 前記ネットワークノード（１１０）が前記破棄ダウンリンクＴＣＰトラフィックに関する情報を有するかを判定し、
    前記オリジナルウィンドウサイズが前記最適ウィンドウサイズよりも大きいかを判定するように構成される、判定ユニット（８０５）をさらに含む、
    請求項１０に記載のネットワークノード（１１０）。
12. 前記オリジナルウィンドウサイズの前記置換をアクティブ化するように構成されるアクティブ化ユニット（８０３）と、
    前記オリジナルウィンドウサイズの前記置換を非アクティブ化するように構成される非アクティブ化ユニット（８１３）と、
    をさらに含む、請求項１０〜１１のいずれかに記載のネットワークノード（１１０）。
13. 前記ＴＣＰトラフィックがＧＴＰ−Ｕ（general packet radio service tunnelling protocol user data tunneling）ペイロードのＴ−ＰＤＵ（transport ｐｒｏｔｏｃｏｌ ｄａｔａ ｕｎｉｔ）に含まれることを判定するように構成される判定ユニット（８０５）をさらに含む、請求項１０〜１２のいずれかに記載のネットワークノード（１１０）。
14. 前記最適ウィンドウサイズは、前記ネットワークノード（１１０）において予め定義される、請求項１０〜１３のいずれかに記載のネットワークノード（１１０）。
15. 前記最適ウィンドウサイズは、ＭＢＲ（maximum bit rate）に関連付けられる、請求項１０〜１４のいずれかに記載のネットワークノード（１１０）。
16. 前記最適ウィンドウサイズは、固定された最適ウィンドウサイズ又は動的な最適ウィンドウサイズである、請求項１０〜１５のいずれかに記載のネットワークノード（１１０）。
17. 前記アップリンクＴＣＰトラフィックは、ＴＣＰのＡＣＫ（acknowledgement）メッセージを含み、
    ＴＣＰ ＡＣＫメッセージは、前記オリジナルウィンドウサイズを含み、
    前記ネットワークノード（１１０）は、前記アップリンクＴＣＰトラフィックが前記ＴＣＰ ＡＣＫメッセージを含むことを判定するように構成される判定ユニット（８０５）をさらに含む、請求項１０〜１６のいずれかに記載のネットワークノード（１１０）。
18. 前記パケット交換ネットワーク（１００）は、ＧＳＭ（global system for mobile communication）、ＵＭＴＳ（universal mobile telecommunications system）又はＬＴＥ（long term evolution）に基づく、請求項１０〜１７のいずれかに記載のネットワークノード（１１０）。

Images