"パケット交換ネットワーク100内でTCPtransmissioncontrolprotocolトラフィックをハンドリングするためのネットワークノード110における方法であって、オリジナルウィンドウサイズを有するTCPトラフィックを、モバイルノード101から受信すること201,401,402,410,411,601,701と、前記ネットワークノード110が破棄されるTCPトラフィックに関する情報を有し、且つ前記オリジナルウィンドウサイズが最適ウィンドウサイズよりも大きい場合に、前記オリジナルウィンドウサイズを前記最適ウィンドウサイズに置換すること208,412,606,708と、前記パケット交換ネットワーク100内の対応ノード105へ、前記モバイルノード101により受信可能なTCPトラフィックの量を示す、前記最適ウィンドウサイズを有する前記TCPトラフィックを送信すること209,413,414,709と、を含む方法。前記ネットワークノード110が前記破棄されるTCPトラフィックに関する情報を有するかを判定すること202,208,403,412,605,704と、前記オリジナルウィンドウサイズが前記最適ウィンドウサイズよりも大きいかを判定すること202,208,403,412,604,705と、をさらに含む、請求項1に記載の方法。前記オリジナルウィンドウサイズの前記置換をアクティブ化すること707と、前記オリジナルウィンドウサイズの前記置換を非アクティブ化すること711と、をさらに含む、請求項1~2のいずれかに記載の方法。前記ネットワークノード110が前記破棄されるTCPトラフィックに関する情報を有しない場合に、前記対応ノードへ、前記オリジナルウィンドウサイズを有する前記TCPトラフィックを転送すること203,404,405,710、をさらに含む、請求項1~3のいずれかに記載の方法。前記TCPトラフィックがGTP-UgeneralpacketradioservicetunnellingprotocoluserdatatunnelingペイロードのT-PDUtransportprotocoldataunitに含まれることを判定すること202,208,403,412,602,702、をさらに含む、請求項1~4のいずれかに記載の方法。前記ネットワークノード110は、ポリシング機能を含み、前記破棄されるTCPトラフィックは、前記ポリシング機能に関連付けられる、請求項1~5のいずれかに記載の方法。前記最適ウィンドウサイズは、前記ネットワークノード110において予め定義される、請求項1~6のいずれかに記載の方法。前記最適ウィンドウサイズは、MBRmaximumbitrateに関連付けられる、請求項1~7のいずれかに記載の方法。前記最適ウィンドウサイズは、固定された最適ウィンドウサイズ又は動的な最適ウィンドウサイズである、請求項1~8のいずれかに記載の方法。前記TCPトラフィックは、TCPのACKacknowledgementメッセージを含み、TCPACKメッセージは、前記オリジナルウィンドウサイズを含み、前記方法は、前記TCPトラフィックが前記TCPACKメッセージを含むことを判定すること202、208、403、412、603、703をさらに含む、請求項1~9のいずれかに記載の方法。前記パケット交換ネットワーク100は、GSMglobalsystemformobilecommunication、UMTSuniversalmobiletelecommunicationssystem又はLTElongtermevolutionに基づく、請求項1~10のいずれかに記載の方法。前記ネットワークノード110は、eNBevolvedNodeB、SGWservinggateway、PGWpacketdatanetworkgateway、RNCradionetworkcontroller、SGSNservinggeneralpacketradioservicesupportnode、GGSNgatewaygeneralpacketradioservicesupportnode、又はDPIdeeppacketinspectionノードである、請求項1~11のいずれかに記載の方法。パケット交換ネットワーク100内でTCPtransmissioncontrolprotocolトラフィックをハンドリングするためのネットワークノード110であって、前記ネットワークノード110は、オリジナルウィンドウサイズを有するTCPトラフィックを、モバイルノード101から受信するように構成される受信機801と、前記ネットワークノード110が破棄されるTCPトラフィックに関する情報を有し、且つ前記オリジナルウィンドウサイズが最適ウィンドウサイズよりも大きい場合に、前記オリジナルウィンドウサイズを前記最適ウィンドウサイズに置換するように構成される置換ユニット807と、前記パケット交換ネットワーク100内の対応ノード105へ、前記モバイルノード101により受信可能なTCPトラフィックの量を示す、前記最適ウィンドウサイズを有する前記TCPトラフィックを送信するように構成される送信機810と、を含む、ネットワークノード110。前記ネットワークノード110が前記破棄されるTCPトラフィックに関する情報を有するかを判定し、前記オリジナルウィンドウサイズが前記最適ウィンドウサイズよりも大きいかを判定するように構成される、判定ユニット805をさらに含む、請求項13に記載のネットワークノード110。前記オリジナルウィンドウサイズの前記置換をアクティブ化するように構成されるアクティブ化ユニット803と、前記オリジナルウィンドウサイズの前記置換を非アクティブ化するように構成される非アクティブ化ユニット813と、をさらに含む、請求項13~14のいずれかに記載のネットワークノード110。前記送信機810は、前記ネットワークノード110が前記破棄されるTCPトラフィックに関する情報を有しない場合に、前記対応ノードへ、前記オリジナルウィンドウサイズを有する前記TCPトラフィックを転送するようにさらに構成される、請求項13~15のいずれかに記載のネットワークノード110。前記TCPトラフィックがGTP-UgeneralpacketradioservicetunnellingprotocoluserdatatunnelingペイロードのT-PDUtransportprotocoldataunitに含まれることを判定するように構成される判定ユニット805をさらに含む、請求項13~16のいずれかに記載のネットワークノード110。前記ネットワークノード110は、ポリシング機能を含み、前記破棄されるTCPトラフィックは、前記ポリシング機能に関連付けられる、請求項13~17のいずれかに記載のネットワークノード110。前記最適ウィンドウサイズは、前記ネットワークノード110において予め定義される、請求項13~18のいずれかに記載のネットワークノード110。前記最適ウィンドウサイズは、MBRmaximumbitrateに関連付けられる、請求項13~19のいずれかに記載のネットワークノード110。前記最適ウィンドウサイズは、固定された最適ウィンドウサイズ又は動的な最適ウィンドウサイズである、請求項13~20のいずれかに記載のネットワークノード110。前記TCPトラフィックは、TCPのACKacknowledgementメッセージを含み、TCPACKメッセージは、前記オリジナルウィンドウサイズを含み、前記ネットワークノード110は、前記TCPトラフィックが前記TCPACKメッセージを含むことを判定するように構成される判定ユニット805をさらに含む、請求項13~21のいずれかに記載のネットワークノード110。前記パケット交換ネットワーク100は、GSMglobalsystemformobilecommunication、UMTSuniversalmobiletelecommunicationssystem又はLTElongtermevolutionに基づく、請求項13~22のいずれかに記載のネットワークノード110。前記ネットワークノード110は、eNBevolvedNodeB、SGWservinggateway、PGWpacketdatanetworkgateway、RNCradionetworkcontroller、SGSNservinggeneralpacketradioservicesupportnode、GGSNgatewaygeneralpacketradioservicesupportnode、又はDPIdeeppacketinspectionノードである、請求項13~23のいずれかに記載のネットワークノード110。本実施形態の目的は、したがって、パケット交換ネットワーク内でのTCPトラフィックの改善されたハンドリングを提供することである。第1の態様によれば、目的は、パケット交換ネットワーク内でTCPトラフィックをハンドリングするためのネットワークノードにおける方法により達成される。ネットワークノードは、モバイルノードからTCPトラフィックを受信する。TCPトラフィックは、オリジナルウィンドウサイズを含む。ネットワークノードが破棄されるTCPトラフィックに関する情報を有し、且つオリジナルウィンドウサイズが最適ウィンドウサイズよりも大きい場合に、ネットワークノードは、オリジナルウィンドウサイズを最適ウィンドウサイズと置換する。ネットワークノードは、パケット交換ネットワーク内の対応ノードへ、モバイルノードにより受信可能なTCPトラフィックの量を示す、最適ウィンドウサイズを含むTCPトラフィックを送信する。第2の態様によれば、目的は、パケット交換ネットワーク内でTCPトラフィックをハンドリングするためのネットワークノードにより達成される。ネットワークノードは、モバイルノードからTCPトラフィックを受信するように構成される受信機を含む。TCPトラフィックは、オリジナルウィンドウサイズを含む。ネットワークノードが破棄されるTCPトラフィックに関する情報を有し、且つオリジナルウィンドウサイズが最適ウィンドウサイズよりも大きい場合に、ネットワークノードは、オリジナルウィンドウサイズを最適ウィンドウサイズと置換するように構成される置換ユニットを含む。ネットワークノードは、パケット交換ネットワーク内の対応ノードへ、モバイルノードにより受信可能なTCPトラフィックの量を示す、最適ウィンドウサイズを含むTCPトラフィックを送信するように構成される送信機をさらに含む。ネットワークノードが破棄されるTCPトラフィックに関する情報を有し、且つオリジナルウィンドウサイズが最適ウィンドウサイズよりも大きい場合に、オリジナルウィンドウサイズが最適ウィンドウサイズと置換されるため、対応ノードは、モバイルノードがハンドリング可能な量のTCPトラフィックだけをモバイルノードに送信する。したがって、パケット交換ネットワーク内のTCPトラフィックのハンドリングが改善される。本実施形態は、次の例の非網羅的なリストのうちの多くの利点を享受する。本実施形態の利点は、モバイルノードにより対応ノードへより大きいTCPウィンドウサイズが示されることに起因するネットワークノードポリシングにおけるダウンリンクのトラフィック破棄を、回避することができることである。別の利点は、本実施形態は、TCPセグメントの再送信により引き起こされるネットワークオーバヘッドを大いに減少させるであろうということである。ポリシングのトラフィック破棄が全くなく、より大きいウィンドウサイズがモバイルノードから対応ノードへ送信される場合、当該より大きいウィンドウサイズが維持されるであろう。これは、ネットワークにおける伝送性能にいかなる影響も与えないという利点を有する。さらなる利点は、各ネットワークノードが本実施形態を実施することができ、実施形態の動的なアクティブ化又は非アクティブ化を実行しうることである。これは本実施形態の展開を容易する。本実施形態は、それがネットワークノードのPDPレベル又はDPI製品におけるIPフローレベルにあり得るという利点を提供する。さらに、本実施形態の利点は、あまりにも大きなウィンドウサイズがモバイルノードから対応ノードに送信されることを回避することで、ポリシングのトラフィック破棄のリスクを減少させ、ネットワークオーバヘッドを減少させるということである。本実施形態の他の利点は、LTE、UMTS及びGSM等の多くの通信技術に対し適用できることである。本実施形態は、上述した特徴及び利点に限定されない。当業者であれば、以下の詳細な説明を読んだ上で、追加的な特徴及び利点を認識するであろう。本実施形態は、ネットワークノードにおけるポリシングメカニズムを改善する。モバイルノードから対応ノードに送信されるウィンドウサイズは、ポリシングの間ダウンリンク方向における不必要なトラフィック破棄を回避するように最適化される。これは、TCPトラフィックタイプのダウンリンクトラフィックに適用される。最適ウィンドウサイズは、PDPコンテキスト上のポリシングにおいてネットワークノードがパケットを破棄するまで使用されることはない。最初の時点で、モバイルノードは、最適ウィンドウサイズよりも大きい、オリジナルウィンドウサイズを対応ノードに告知する。以前にトラフィックの破棄が全くないため、ウィンドウサイズはネットワークノードによって最適化されない。ネットワークノードがPDP上でポリシングを行い、MBRを超過することに起因してトラフィックを破棄する場合にのみ、最適ウィンドウサイズを使用するであろう。そうでない場合、それが最適ウィンドウサイズにより示されるよりも大き過ぎるようであるとしても、ネットワークノードは、TCPトラフィックにおけるオリジナルウィンドウサイズを変更しないままにするであろう。これは、可能な限り許容レベルで性能を維持するためである。図1は、本実施形態が実装され得る、無線通信ネットワーク100を示す。通信ネットワーク100は、いくつかの実施形態では、例えば、LTE、LTEAdvanced、UMTS、GSM、WCDMA、又は任意の他の3GPP無線アクセス技術等の、1以上の無線アクセス技術に適用され得る。通信ネットワーク100は、ネットワークノード110を介して対応ノード105と通信するモバイルノード101を含む。モバイルノード101は、任意の適切な通信装置又は対応ノード105と通信することが可能な通信ケイパビリティを有する計算装置computationaldeviceであってもよく、例えば、モバイルフォン、スマートフォン、PDApersonaldigitalassistant、タブレットコンピュータ、ラップトップ、MP3プレイヤ又はポータブルDVDプレイヤ又は類似のメディアコンテンツ装置、デジタルカメラ、又はPC等の固定された装置でさえあってもよいが、これらに限定されない。PCは、ブロードキャスト/マルチキャストされたメディアのエンドステーションとしてモバイルステーションを介して接続されることもできる。モバイルノード101は、例えば、電子フォトフレーム、心臓監視、侵入又は他の監視機器、気象データ監視システム、乗り物、車または伝送通信機器等に組み込まれる通信装置であってもよい。モバイルノード101は、いくつかの図面においてMNと称される。対応ノード105は、ピアノードと呼ばれてもよく、モバイル又は固定のいずれかであり得る。それは、メールサーバ、インスタントマッサージャサーバ、ソーシャルネットワークウェブサイト、ゲームサーバ、IMSネットワーク内のIMSノード等であってもよい。ネットワークノード110は、例えば、eNB、RNC、SGW、PGW、SGSN、GGSN又はDPIノードであってもよい。モバイルノード101、ネットワークノード110及び対応ノード105間の通信リンクは、有線又は無線のいずれかを含む任意の適切な種類のリンクであってもよいことに留意すべきである。当該リンクは、当業者により理解される、例えばOSIOpenSystemsInterconnectionモデルにより示されるタイプ及びレイヤのレベルに依存した、任意の適切なプロトコルを使用してもよい。実施形態の例によれば、パケット交換ネットワーク内のTCPトラフィックをハンドリングするための方法について、図2に示されるシグナリング図及びフローチャートの組み合わせを参照してここで説明する。ネットワークノード110は、前述したようにポリシング機能を実行する。ネットワークノード110は、ステップ201に入る前に、いかなるTCPトラフィックも破棄したことがない。方法は、以下のステップを含み、当該ステップは、後述するのとは別の適切な順序で実行されてもよい。ステップ201モバイルノード101は、初めてアップリンクTCPトラフィックをネットワークノード110に送信する。アップリンクTCPトラフィックは、TCPヘッダ内にTCPACKを含む。TCPACKメッセージは、モバイルノード101が対応ノード105から受け取る用意がある未処理データの量を示すウィンドウサイズを含む、ウィンドウ告知メッセージwindowadvertisementmessageである。未処理データの量は、オリジナルウィンドウサイズとも呼ばれることができ、TCPACKメッセージ内のフィールドである。TCPトラフィックは、GTP-UペイロードのT-PDUに含まれる。ステップ202ネットワークノード110は、アップリンクTCPトラフィックを検査し、それがTCPACKメッセージを含むかを判定する。TCPACKメッセージに含まれるオリジナルウィンドウサイズを検査するとき、ネットワークノード110は、オリジナルウィンドウサイズを最適ウィンドウサイズと比較し、オリジナルウィンドウサイズが最適ウィンドウサイズよりも大きいかを判定する。最適ウィンドウサイズは、PDPQoSのMBR率に関連付けられていてもよく、MBRと線型的な関係を有する。最適ウィンドウサイズは、固定又は可変のパラメータであってもよい。それは、実行時間の間動的に変化してもよい。ネットワークノード110は、ステップサイズとともにPDP上の最適ウィンドウサイズを減少させてもよい。但し、最適ウィンドウサイズは、予め定義された低い方のウォータマークより低くないかもしれない。オリジナルウィンドウサイズが、最適ウィンドウサイズよりも大きいと判定すると、ネットワークノード110は、PDPコンテキスト上のポリシングにおいてそれが以前にパケットを破棄したことがあるか否かを調査する。ネットワークノード110が、以前にいかなるトラフィックも破棄したことがない場合、ネットワークノード110は、オリジナルウィンドウサイズの置換は全く必要ないと判定する。オリジナルウィンドウサイズが最適ウィンドウサイズよりも小さいとネットワークノード110が判定する場合、ネットワークノード110はまた、オリジナルウィンドウサイズの置換は全く必要ないと判定する。ステップ203この例では、ネットワークノード110は、以前に破棄されたトラフィックを全く検知しなかったため、変更されていないオリジナルウィンドウサイズを含むアップリンクTCPトラフィックを対応ノード105に転送する。それが最適ウィンドウサイズ、即ちMBRよりも大きいとしても、それは、TCPACK内のオリジナルウィンドウサイズを変更しないまま維持する。これは、性能を可能な限り同一のレベルに保つためである。ステップ204対応ノード105は、ネットワークノード110からオリジナルウィンドウサイズを含むアップリンクTCPトラフィックを受信し、ネットワークノード110にダウンリンクTCPトラフィックを送信することにより、ネットワークノード110に応答を返す。ステップ205ネットワークノード110は、そのポリシング機能を実行する。ポリシング機能の結果は、ダウンリンクTCPトラフィックは、ネットワークノード110のMBRを超過しているということであり、したがって、ネットワークノード110は、TCPトラフィックを破棄する。オリジナルウィンドウサイズに加えて、ネットワーク環境、ルータ上のパケットスケジューラ、アプリケーションの種類、IPセグメント等の他の要因が、ポリシングのトラフィック破棄に影響を及ぼす可能性がある。しかしながら、オリジナルウィンドウサイズは、TCPトラフィックを破棄する主要な理由であり得る。ステップ206ネットワークノード110は、その状態stateを、TCPトラフィックを全く破棄していない状態からTCPトラフィックを破棄したことを示す状態に変更する。状態は、例えばフラグによって表されることができ、0は、ネットワークノード110がTCPトラフィックを全く破棄していないことを示し、1は、ネットワークノード110がTCPトラフィックを破棄したことを示す。ステップ207モバイルノード101は、2回目のアップリンクTCPトラフィックをネットワークノード110に送信する。アップリンクTCPトラフィックは、TCPACKメッセージを含む。オリジナルウィンドウサイズは、TCPACKメッセージ内のフィールドである。ステップ208ネットワークノード110は、第2のアップリンクTCPトラフィックを検査し、それがTCPACKメッセージを含むかを判定する。TCPACKメッセージに含まれるオリジナルウィンドウサイズを検査するとき、ネットワークノード110は、オリジナルウィンドウサイズを最適ウィンドウサイズと比較し、オリジナルウィンドウサイズが最適ウィンドウサイズよりも大きいと判定する。言い換えると、モバイルノード101は、通信ネットワーク100における性能に最適ではない量のTCPトラフィックを送信することを望んでおり、したがって、ネットワーク性能により適したそのTCPトラフィックの量を減らす必要がある。ステップ206で、ネットワークノードは、その状態を変更したので、ネットワークノード110は、TCPトラフィック内のTCPACKメッセージにおいて、オリジナルウィンドウサイズを最適ウィンドウサイズと置換する。ネットワークノード110は、モバイルノード101から対応ノード105に告知されたオリジナルウィンドウサイズを知っている。告知されたオリジナルウィンドウサイズが大きすぎる場合、ネットワークノード110は、このオリジナルウィンドウサイズを適正な値、即ち最適ウィンドウサイズに修正し得る。最適ウィンドウサイズは、TCP性能及びスループットに影響を及ぼさない。さらに、最適ウィンドウサイズは、ネットワークノード110上でポリシングのTCPトラフィック破棄を引き起こすことはない。いくつかの実施形態では、対応ノード105へのTCPACKにおいてネットワークノード110が最適ウィンドウサイズを使用しているとしても、ネットワークノード110におけるポリシング機能は、ダウンリンク速度がMBRを超過していることに起因してTCPトラフィックをなお破棄する。その後、ネットワークノード110は、ステップサイズとともにこのPDP上の最適ウィンドウサイズを減少させ、減少した最適ウィンドウサイズをTCPACKメッセージに適用し得る。ポリシング機能がなおTCPトラフィック破棄を引き起こす場合、ネットワークノード110は、最適ウィンドウサイズをさらに減少させ得る。しかしながら、最適ウィンドウサイズは、予め定義された低い方のウォータマークよりも低くなることはない。ステップ209ネットワークノード110は、最適ウィンドウサイズを含むアップリンクTCPトラフィックを対応ノード105に転送する。ステップ210対応ノード105は、最適ウィンドウサイズを含むアップリンクTCPトラフィックを受信する。対応ノード105は、ここで、オリジナルウィンドウサイズよりも小さい最適ウィンドウサイズについての情報を有するため、それは、TCPトラフィックを送信するその速度を落とす。図3は、LTEに基づく通信ネットワーク100の例示的な実施形態を図示するブロック図である。通信ネットワーク100は、eノードB301と通信するモバイルノード101を含む。eノード301は、用いられる技術及び専門用語に依存して、基地局、RBS、eNB、ノードB、Bノード、BTSとも呼ばれ得る。基地局301は、SGW305及びPGW310を含むコアネットワークに接続されている。PGW310は、例えば、モバイルノード101にインターネットサービスを提供するインターネットホストを表す、対応ノード105に接続されている。図3では、ネットワークノード110は、SGW305により例示されている。パケット交換ネットワーク内でTCPトラフィックをハンドリングするための方法は、図3に示すLTEに基づく通信ネットワーク100の例示的な実施形態によれば、図4に示すシグナリング図及びフローチャートの組み合わせを参照してここで説明される。図4では、eノードB301、SGW305及びPGW310の各々がGSNノードと呼ばれ得る。4GLTEネットワークでは、eノードB301、SGW305及びPGW310の各々は、ネゴシエートされたベアラPDPのQoSパラメータに従って、ダウンリンク方向でのポリシング機能を実行する。この例では、ネットワークノード110は、SGW305である。しかしながら、実施形態は、他のGSNのうちのいずれか又は図4に図示される全てのGSNノードにおいて実装されてもよい。図4中の全てのGSNノードが本実施形態を実装する例において、TCPACKメッセージの二重検査を回避するために、GSNノードのうちの1つがアクティブ化されてもよい。SGW305は、ステップ401に入る以前には、いかなるTCPトラフィックも破棄したことがない。方法は、以下のステップを含み、それらのステップは、後述されているのとは別の適切な順序で実行されてもよい。ステップ401このステップは、図2のステップ201に対応する。モバイルノード101は、初めてeノードB301にアップリンクTCPトラフィックを送信する。アップリンクTCPトラフィックは、TCPACKメッセージを含む。TCPACKメッセージは、TCPACKメッセージ内のフィールドとしてオリジナルウィンドウサイズを含む。アップリンクTCPトラフィックは、また、ウィンドウ告知メッセージとも呼ばれ得る。ステップ402このステップは、図2のステップ201に対応している。eノードB301は、GTPプロトコルを用いて、即ちGTPペイロード内で、SGW305にアップリンクTCPトラフィックを転送する。ステップ403このステップは、図2のステップ202に対応している。SGW305は、アップリンクTCPトラフィックを検査し、アップリンクTCPトラフィックがTCPACKメッセージを含むかを判定する。アップリンクTCPトラフィックがTCPACKメッセージを含む場合、SGW305は、TCKACKメッセージ内のオリジナルウィンドウサイズがPDPコンテキスト内の最適ウィンドウサイズよりも大きいかをチェックする。TCPACKメッセージに含まれるオリジナルウィンドウサイズを検査するとき、SGW305は、オリジナルウィンドウサイズを最適ウィンドウサイズと比較し、オリジナルウィンドウサイズが最適ウィンドウサイズよりも大きいかを判定する。上述したように、SGW305は、ネゴシエートされたベアラPDPのQoSパラメータに従って、ダウンリンク方向上でポリシングを実行する。ユーザプレーンにおいては、GTP-UTCPトラフィックは、ポリシングの対象となり、検査される。PDUを伝送するT-PDUは、ユーザトラフィックであり、TCPのタイプである。これは、図5において図示され、LTEトランスポートプロトコルスタックを表す。eノードB301、SGW305及びPGW310の周りの点線は、それらが図1においてネットワークノード110と呼ばれることを示す。IPは、図5に示されるLTEトランスポートプロトコルスタックの下位レベルと呼ばれ得る。図5の最も左の列では、モバイルノード101についてTCPがIPの上に構築されているものとして示されている。図5の最も左の列のPDU501は、IP及びTCPを含む。図5の中間の左列及び中間の右列では、UDPUserDatagramProtocolがIPの上に構築されている。GTPは、UDP又はTCPとともに使用され得る。中間の左列及び中間の右列には、TCP及びIPを含むT-PDU503が含まれる。最も左の列にはTCP及びIPを含むPDU501が示されている。オリジナルウィンドウサイズが最適ウィンドウサイズより大きいと判定した後、SGW305は、それが以前にPDPコンテキスト上のポリシングにおいてトラフィックを破棄したことがあるか否かを調査する。SGW305が、以前にポリシングに起因してPDP上のいかなるトラフィックも破棄していない場合、SGW305は、オリジナルウィンドウサイズを置換する必要はない、即ちSGW305は何のアクションも取らないと判定する。SGW305が、オリジナルウィンドウサイズが最適ウィンドウサイズよりも小さいと判定する場合、SGW305は、また、オリジナルウィンドウサイズを置換する必要はないと判定する。ステップ404このステップは、図2のステップ203に対応する。SGW305は、以前に破棄されたトラフィックを検出することができなかったため、GTPペイロード内の変更されていないオリジナルウィンドウサイズを含むアップリンクTCPトラフィックをPGW310に転送する。それが最適ウィンドウサイズ、即ちMBRよりも大きいとしても、それは、TCPACK内のオリジナルウィンドウサイズを変更しないまま維持する。これは、可能な限り性能を同一レベルに維持するためである。ステップ405このステップは、図2のステップ203に対応する。PGW310は、SGW305からオリジナルウィンドウサイズを含むアップリンクTCPトラフィックを受信し、対応ノード105にダウンリンクTCPトラフィックを転送する。ステップ406このステップは、図2のステップ204に対応する。対応ノード105は、PGW310からオリジナルウィンドウサイズを含むアップリンクTCPトラフィックを受信し、PGW310にダウンリンクTCPトラフィックを送信することによって、PGW310に応答を返す。対応ノード105からモバイルノード101へのダウンリンクPDUは、GTPトンネル内のパケットコアネットワークにおいて、T-PDUになる。ステップ407このステップは、図2のステップ204に対応する。PGW310は、SGW305にGTPペイロード内に含まれるダウンリンクTCPトラフィックを転送する。ステップ408このステップは、図2のステップ205に対応する。しばらくしてから、モバイルノード101から対応ノード106に送信された大きなオリジナルウィンドウサイズに起因して、少しの間、ダウンリンクの速度がMBRを超過する。SGW305は、MBRなどのQoSパラメータに基づいて、そのポリシング機能を実行する。ポリシング機能の結果は、ダウンリンクTCPトラフィックが、SGW305のMBRを超過し、したがってSGW305がTCPトラフィックを破棄することである。ステップ409このステップは、図2のステップ206に対応する。SGW305は、その状態stateを、TCPトラフィックを全く破棄したことがない状態から、TCPトラフィックを破棄したことがあることを示す状態に変更する。ステップ410このステップは、図2のステップ207に対応する。モバイルノード101は、2回目のアップリンクTCPトラフィックをeノードB301に送信する。アップリンクTCPトラフィックは、TCPACKメッセージを含む。オリジナルウィンドウサイズは、TCPACKメッセージ内のフィールドである。ステップ411このステップは、図2のステップ207に対応する。eノードB301は、SGW305にGTPプロトコルを用いて、即ちGTPペイロード内でアップリンクTCPトラフィックを転送する。ステップ412このステップは、図2のステップ208に対応する。SGW305は、新たなアップリンクTCPトラフィックを検査し、それがPDPレベル毎にTCPACKメッセージを含むかを判定する。上述したように、TCPACKメッセージは、パケット交換ネットワーク100内のGTP-Uトンネル上で送信される。TCPACKメッセージに含まれるオリジナルウィンドウサイズを検査するとき、SGW305は、オリジナルウィンドウサイズを最適ウィンドウサイズと比較し、オリジナルウィンドウサイズが最適ウィンドウサイズよりも大きいかを判定する。言い換えると、モバイルノード101は、通信ネットワーク100における性能に対し最適でない量のTCPトラフィックを送信することを望んでおり、したがって、ネットワーク性能に対しより適切な、最適化された量のTCPトラフィックを送信するように指示される必要がある。SGW305は、ステップ409でその状態を変更し、従って、モバイルノード101から対応ノード105に送信された大きすぎるオリジナルウィンドウサイズに起因してトラフィックが破棄されたことがあることを知っているため、SGW305は、TCPトラフィック内のTCPACKメッセージにおいて、オリジナルウィンドウサイズを最適ウィンドウサイズと置換する。言い換えると、TCPACKメッセージ内のオリジナルウィンドウサイズは、最適ウィンドウサイズに更新される。最適ウィンドウサイズは、SGW305において予め定められることができ、PDPQoSコンテキストに関連付けられる。ステップ413このステップは、図2のステップ209に対応する。SGW305は、最適ウィンドウサイズを含み、GTPペイロードに含まれるアップリンクTCPトラフィックをPGW310に転送する。ステップ414このステップは、図2のステップ209に対応する。PGW310は、最適ウィンドウサイズを含むアップリンクTCPトラフィックを対応ノード105に送信する。ステップ415このステップは、図2のステップ210に対応する。対応ノード105は、最適ウィンドウサイズを含むアップリンクTCPトラフィックを受信する。対応ノード105は現在、オリジナルウィンドウサイズよりも小さい最適ウィンドウサイズについての情報を有するため、TCPトラフィックを送信するその速度を落とす。図2及び図4に例示されたように、パケット交換ネットワークにおけるTCPトラフィックをハンドリングする方法の例は、ここで図6のネットワークノード110の観点から見て説明されるであろう。方法は、以下のステップを含み、それらのステップは、後述されているのとは別の適切な順序で実行されてもよい。ステップ601このステップは、図2のステップ201並びに図4のステップ401及び402に対応する。ネットワークノード110は、モバイルノード101からアップリンクTCPトラフィックを受信する。いくつかの実施形態においては、TCPトラフィックは、GTPペイロード内に含まれる。ステップ602このステップは、図2のステップ202及び208並びに図4のステップ403及び412に対応する。ネットワークノード110は、TCPトラフィックがT-PDUタイプかどうかチェックする。TCPトラフィックがT-PDUタイプではない場合、図6でNoで示され、方法は終了するか又はステップ601に戻る。TCPトラフィックがT-PDUタイプである場合、図6でYesで示され、方法はステップ603に進む。ステップ603このステップは、図2のステップ202及び208並びに図4のステップ403及び412に対応する。TCPトラフィックがT-PDUタイプであるとネットワークノード110が判定したとき、それは、TCPトラフィックがTCPACKを含むかどうかをチェックする。TCPトラフィックがTCPACKを含まない場合、図6でNoで示され、方法は終了するか又はステップ601に戻る。TCPトラフィックがTCPACKを含む場合、図6でYesで示され、方法はステップ604に進む。ステップ604このステップは、図2のステップ202及び208並びに図4のステップ403及び412に対応する。このステップは、ステップ605の前又は後に実行されてもよい。TCPトラフィックがTCPACKを含むことをネットワークノード110が判定したとき、それは、オリジナルウィンドウサイズを最適ウィンドウサイズと比較する。比較の結果、オリジナルウィンドウサイズが最適ウィンドウサイズよりも小さい場合、図6でNoで示され、方法は終了するか又はステップ601に戻る。比較の結果、オリジナルウィンドウサイズが最適ウィンドウサイズよりも大きい場合、図6でYesで示され、方法はステップ605に進む。ステップ605このステップは、図2のステップ202及び208並びに図4のステップ403及び412に対応する。オリジナルウィンドウサイズが最適ウィンドウサイズよりも大きいとネットワークノード110が判定したとき、ネットワークノード110は、ネットワークノード110がポリシングに起因してTCPトラフィックを破棄したことがあるかどうかを判定することに進む。ネットワークノード101が、ポリシングに起因してTCPトラフィックを破棄したことがない場合、図6でNoで示され、方法は終了するか又はステップ601に戻る。ネットワークノード110が、ポリシングに起因してTCPトラフィックを破棄したことがある場合、図6でYesで示され、方法はステップ606に進む。ステップ606このステップは、図2のステップ208及び図4のステップ412に対応する。ネットワークノード110が、以前にポリシングに起因してTCPトラフィックを破棄したことがあると判定したとき、それは、オリジナルウィンドウサイズを最適ウィンドウサイズと置換し、最適ウィンドウサイズを含むアップリンクTCPトラフィックを対応ノード105に転送する。他の例示的な実施形態では、ネットワークノード110は、ポリシング機能を実装するDPIノードであってもよい。DPIノードは、図のいずれにも示されていない。DPIは、Giインタフェース上に存在し得る。DPIは、PDPコンテキストを知らず、5タプルによって識別されるIPフローに対処するのみである。DPIは、Gxインタフェースを介してPCRFからQoS情報を得る。Gxインタフェースは、GGSN及びPCRF間のオンラインポリシーインタフェースであり、課されるルールに基づいて、サービスデータフローをプロビジョニングするために使用される。DPIは、パケットを検査するのに良好なケイパビリティを有するため、モバイルノード101から対応ノード105へのTCPトラフィックフロー内のTCPACKのオリジナルウィンドウサイズを知ることはDPIには非常に容易である。ネットワークノード110が、DPIとして例示される場合、方法は、上述した図2、図4及び図6に示されるのと同一である。オリジナルウィンドウサイズが最適ウィンドウサイズよりも大きく、DPIノード上のポリシングに起因してトラフィック破棄があった場合、最適ウィンドウサイズが使用される。いくつかの実施形態では、Giインタフェース上にDPIがある場合、本実施形態は、DPIノード上で使用され得る。そして、ネットワーク内のノードの中の全ての他のノードは、本実施形態を実装しない。本実施形態がオペレータのネットワーク内で実装される場合、本実施形態は、全てのネットワークノード110において実装され、本実施形態は、動的にアクティブ化又は非アクティブ化される。本実施形態は、3GUMTSネットワークに適用されることもできる。RNC、SGSN及びGGSN図示せずの各々は、ダウンリンクペイロードがMBRレートを超過することを回避するためにポリシング機能を有する。例として、SGSNペイロードを取り上げる。SGSNは、ダウンリンクユーザプレーンGTP-Uトラフィックにポリシングを実行する。速度がMBRを超過する場合、ポリシングはPDP上でトラフィックを破棄するであろう。本実施形態によれば、MBRに達するときには、ポリシングのトラフィック破棄を回避するために、モバイルノード101から対応ノード105に送信されたTCPACK内の最適ウィンドウサイズが使用される。本実施形態は、SGSN及びGGSNを含む、2GGSMネットワークに適用されることもできる。上述した方法のいくつかの実施形態は、ここでネットワークノード110の観点から見て説明されるであろう。図7は、ネットワークノード110における、パケット交換ネットワーク100内でTCPトラフィックをハンドリングするための本方法を記述するフローチャートである。いくつかの実施形態では、パケット交換ネットワーク100は、GSM、UMTS又はLTEに基づく。いくつかの実施形態では、ネットワークノード110は、eNB、SGW、PGW、RNC、SGSN、GGSN又はDPIノードである。方法はネットワークノード110によって実行されるべき以下のステップを含み、それらのステップは、任意の適切な順番が取られてもよい。ステップ701このステップは、図2のステップ201及び207、図4のステップ401、402、410及び411、並びに図6のステップ601に対応する。ネットワークノード110は、モバイルノード101からTCPトラフィックを受信する。TCPトラフィックは、オリジナルウィンドウサイズを含む。ネットワークノード110は、ここで、TCPトラフィックを検査するための準備ができる。いくつかの実施形態では、TCPトラフィックはTCPACKメッセージを含み、TCPACKメッセージはオリジナルウィンドウサイズを含む。ステップ702このステップは、図2のステップ202及び208、図4のステップ403及び412、並びに図6のステップ602に対応する。いくつかの実施形態では、ネットワークノード110は、受信されたTCPトラフィックを検査し、TCPトラフィックがGTP-UペイロードのT-PDUに含まれるかを判定する。ステップ703このステップは、図2のステップ202及び208、図4のステップ403及び412、並びに図6のステップ603に対応する。いくつかの実施形態では、ネットワークノード110は、受信されたTCPトラフィックを検査し、TCPトラフィックがTCPACKメッセージを含むかを判定する。ステップ704このステップは、図2のステップ202及び208、図4のステップ403及び412、並びに図6のステップ605に対応する。いくつかの実施形態では、ネットワークノード110は、受信されたTCPトラフィックを検査し、ネットワークノード110が破棄されたTCPトラフィックについての情報を有するかどうかを判定する。いくつかの実施形態では、ネットワークノード110は、ポリシング機能を含み、破棄されたTCPトラフィックは、ポリシング機能に関連付けられる。ステップ705このステップは、図2のステップ202及び208、図4のステップ403及び412並びに図6のステップ604に対応する。このステップは、ステップ704の前又は後に実行されてもよい。いくつかの実施形態では、ネットワークノード110は、受信されたTCPトラフィックを検査し、オリジナルウィンドウサイズが最適ウィンドウサイズよりも大きいかどうかを判定する。いくつかの実施形態では、最適ウィンドウサイズは、ネットワークノード110において予め定義されている。いくつかの実施形態では、最適ウィンドウサイズは、MBRに関連付けられている。MBRは、PDP又はベアラのものである。最適ウィンドウサイズは、固定の最適ウィンドウサイズ又は動的な最適ウィンドウサイズであってもよい。ステップ707いくつかの実施形態では、ネットワークノード110は、オリジナルウィンドウサイズの置換をアクティブ化する。ネットワークノード110は、例えば、モバイルノード101又は対応ノード105から指示を受信した時点でオリジナルウィンドウサイズの置換をアクティブ化してもよく、又は、予め定められた時間後若しくは一定間隔で置換をアクティブ化してもよい。ステップ708このステップは、図2のステップ208、図4のステップ412及び図6のステップ606に対応する。ネットワークノード110が破棄されたTCPトラフィックについての情報を有するとき、且つオリジナルウィンドウサイズが最適ウィンドウサイズよりも大きいときに、ネットワークノード110は、オリジナルウィンドウサイズを最適ウィンドウサイズと置換する。ステップ709このステップは、図2のステップ209、並びに図4のステップ413及び414に対応する。ネットワークノード110は、モバイルノード101により受信可能なTCPトラフィックの量を示す、最適ウィンドウサイズを含むTCPトラフィックを、パケット交換ネットワーク100内の対応ノードに送信する。ステップ710このステップは、図2のステップ203、並びに図4のステップ404及び405に対応する。いくつかの実施形態では、ネットワークノード110が、破棄されたTCPトラフィックについての情報を全く有しない場合、ネットワークノード110は、オリジナルウィンドウサイズを含むTCPトラフィックを対応ノード105に転送する。ステップ711いくつかの実施形態では、ネットワークノード110は、オリジナルウィンドウサイズの置換を非アクティブ化する。長い間全くトラフィック破棄がなかった場合、ネットワークノード110は、オリジナルウィンドウサイズの置換を非アクティブ化する。長い間全くトラフィック破棄がなかったことを検出できるようにするために、ネットワークノード110は、トラフィック破棄の間の時間を監視し、当該時間が予め定められた閾値を超過したときに、置換を非アクティブ化する。図7に示す、パケット交換ネットワーク100内でTCPtransmissioncontrolprotocolトラフィックをハンドリングするための方法ステップを実行するために、ネットワークノード110は、図8に示すような配置を含む。いくつかの実施形態では、ネットワークノード110は、ポリシング機能を含み、破棄されるTCPトラフィックは、ポリシング機能に関連付けられる。いくつかの実施形態では、パケット交換ネットワーク100は、GSM、UMTS又はLTEに基づく。いくつかの実施形態では、ネットワークノード110は、eNB、SGW、PGW、RNC、SGSN、GGSN又はDPIノードである。ネットワークノード110は、モバイルノード101からTCPトラフィックを受信するように構成される受信機801を含む。TCPトラフィックは、オリジナルウィンドウサイズを含む。いくつかの実施形態では、ネットワークノード110は、オリジナルウィンドウサイズの置換をアクティブ化するように構成されるアクティブ化ユニット803を含む。いくつかの実施形態では、ネットワークノードは、ネットワークノード110が破棄されたTCPトラフィックについての情報を有するかどうかを判定し、且つオリジナルウィンドウサイズが最適ウィンドウサイズより大きいかどうかを判定するように構成される、判定ユニット805を含む。いくつかの実施形態では、判定ユニット805は、TCPトラフィックがGTP-UペイロードのT-PDUに含まれるかを判定するようにさらに構成される。いくつかの実施形態では、最適ウィンドウサイズはネットワークノード110において予め定義されている。いくつかの実施形態では、最適ウィンドウサイズは、MBRに関連付けられる。最適ウィンドウサイズは、固定された最適ウィンドウサイズ又は動的な最適ウィンドウサイズであってもよい。いくつかの実施形態では、TCPトラフィックは、TCPACKメッセージを含む。TCPACKメッセージは、オリジナルウィンドウサイズを含む。いくつかの実施形態では、判定ユニット805は、TCPトラフィックがTCPACKメッセージを含むかを判定するようにさらに構成される。ネットワークノード110は、ネットワークノード110が破棄されたTCPトラフィックについての情報を有する場合、且つオリジナルウィンドウサイズが最適ウィンドウサイズよりも大きい場合に、オリジナルウィンドウサイズを最適ウィンドウサイズと置換するように構成される、置換ユニット807を含む。ネットワークノード110は、モバイルノード101により受信可能なTCPトラフィックの量を示す最適ウィンドウサイズを含むTCPトラフィックを、パケット交換ネットワーク100内の対応ノード105に送信するように構成され得る、送信機810を含む。いくつかの実施形態では、送信機810は、ネットワークノード110が破棄されたTCPトラフィックについての情報を全く有しない場合に、オリジナルウィンドウサイズを含むTCPトラフィックを対応ノードに転送するようにさらに構成される。いくつかの実施形態では、ネットワークノード110は、オリジナルウィンドウサイズの置換を非アクティブ化するように構成される、非アクティブ化ユニット813を含む。パケット交換ネットワーク100においてTCPトラフィックをハンドリングするための本メカニズムは、本実施形態の機能を実行するためのコンピュータプログラムコードとともに、図8に示されるネットワークノードの配置におけるプロセッサ820のような1以上のプロセッサを通じて実装され得る。プロセッサは、例えば、DSPDigitalSignalProcessor、ASICApplicationSpecificIntegratedCircuitプロセッサ、FPGAFieldprogrammablegatearrayプロセッサ又はマイクロプロセッサであってもよい。上述したプログラムコードは、例えば、ネットワークノード110にロードされているとき本実施形態を実行するためのコンピュータプログラムコードを伝達するデータキャリアの形式で、コンピュータプログラム製品として提供されてもよい。そのようなキャリアの1つが、CDROMディスクの形式であってもよい。しかしながら、メモリスティックのような他のデータキャリアで実現可能である。コンピュータプログラムコードは、さらに、サーバ上の純粋なプログラムコードとして提供されることができ、リモートでネットワークノード110にダウンロードされることができる。上で示した実施形態のいくつかの例示的な実装について、ここで述べる。記載されたソリューションは、任意の適切な通信標準をサポートし、任意の適切なコンポーネントを使用する任意の適当な種類の通信ネットワークにおいて実装され得るが、記載されたソリューションの特定の実施形態は、図3に示されるようなLTEネットワークにおいて実装されてもよい。例示的なネットワークは、ネットワークノード110を介したモバイルノード101及び対応ノード105の間の通信をサポートするのに適した、任意の追加的なエレメントをさらに含んでもよい。図示されたネットワークノード110は、ハードウェア及び/又はソフトウェアの任意の適切な組み合わせを含む通信装置を表し得るが、このネットワークノード110は、特定の実施形態において、図9により詳細に示される例示的なネットワークノード110のような装置を表す。図9に示されるように、例示的なネットワークノード110は、処理回路920、メモリ930、無線回路910及び少なくとも1つのアンテナを含む。少なくとも1つのアンテナは、図8に示される受信機801及び送信機810に対応する。無線回路910は、RFRadioFrequency回路及びベースバンド処理回路図示せずを含むことができる。特定の実施形態では、ネットワークノード110により提供されているものとして上述された機能のうちのいくつか又は全てが、図9に示されるメモリ930等のコンピュータ読み取り可能な媒体に格納される命令を実行する、処理回路920によって提供され得る。図9に示される処理回路920は、図8に示されるプロセッサに対応する。ネットワークノード110の代替的な実施形態は、図9に示されるもの以上の追加的なコンポーネントを含んでもよい。当該コンポーネントは、上述した機能のうちのいずれか及び/又は上述した実施形態をサポートするために必要な任意の機能を含む、ネットワークノード110の機能の特定の特徴を提供することを担当することができる。本実施形態は、上述した好ましい実施形態に限定されるものではない。様々な代替、変更及び均等物が使用され得る。したがって、上述の実施形態は、実施形態の範囲を限定するものとして受け取られるべきではなく、添付の特許請求の範囲によって定義される。含むcomprisescomprisingという用語が本明細書で用いられる場合、定められた特徴、整数、ステップ又はコンポーネントの存在を特定するために受け取られるが、1以上の他の特徴、整数、ステップ、コンポーネント又はこれらの集合の存在又は追加を除外するものではないことを強調すべきである。エレメントに先立つa又はanという語は、そのようなエレメントが複数存在することを排除するものではないことにも留意すべきである。添付の特許請求の範囲において定義された方法のステップは、本実施形態から逸脱することなく、請求項に表れる順序とは異なる順序で実行され得ることも強調すべきである。"