JP2014513885A - 移動ネットワークのｔｃｐ性能を改善する方法及び装置 - Google Patents

Abstract

本発明は、移動ネットワークのＴＣＰ性能を改善するための方法、装置及びコンピュータプログラム製品を提供する。本発明は、コンテンツサーバーとユーザ装置との間の接続のクオリティ尺度を中間ネットワークノードにおいて得、クオリティ尺度が所定の条件を満足するかどうか中間ネットワークノードにおいて検出し、クオリティ尺度が所定の条件を満足しない場合には、コンテンツサーバーとユーザ装置との間の接続の凍結モードをトリガーする確認メッセージを中間ネットワークノードにより送信する、ことを含む。
ことを含む
【選択図】 図２

Description

本発明は、移動ネットワークのＴＣＰ性能の改善に関する。

無線アクセス技術は、システム容量を改善し、エンドユーザのデータレートを高め、そしてレイテンシーを下げるために完全パケットベースのフラットアーキテクチャー解決策に向かって進化している。フラットアーキテクチャー及び完全パケットベース技術とは、３ＧＰＰ技術の競争力を更に高めるコスト効率の良い解決策である。第１の進化ステップは、インターネットであり、即ち３Ｇシステムから長期進化（ＬＴＥ）への進化経路を合理化する高速パケットアクセス（Ｉ−ＨＳＰＡ）である。Ｉ−ＨＳＰＡの目的は、並列の回路交換インフラストラクチャーを段階的に廃止して、パケット交換のみとして動作し、複雑さ及びコストを低減することである。高レートの完全パケットベースの無線アクセス解決策は、良く知られたパケットサービスをインターネットから移動環境へと移行できるようにし、移動ネットワークユーザがインターネットにより提供されるアプリケーションにアクセスできるようにする。これらアプリケーションの大半（例えば、ファイル転送、ウェブブラウジング、等）は、信頼性のあるデータ転送のためにトランスミッションコントロールプロトコル（ＴＣＰ）を使用する。従って、システム性能の観点から、Ｉ−ＨＳＰＡ／ＬＴＥネットワークにおけるＴＣＰベースのユーザプレーントラフィックの効率的な取り扱いが非常に重要である。

移動環境では、効率的なＴＣＰオペレーションが要求されることで、多数の問題が生じる。というのは、元々、ＴＣＰは、ワイヤードネットワーク用に設計されたもので、混雑によりパケットロスが生じるからである。ビットエラーによりパケットロスとなる確率は、非常に低い。従って、パケットロスは、混雑の兆候として解釈され、これは、（再送信に加えて）フローレートを下げるＴＣＰフローコントロールアクションをトリガーする。ＴＣＰソースは、その再送信時間切れ（ＲＴＯ）タイマーが時間切れするとき、又は当該パケットより低いシーケンス番号に対して３重・２重確認（ＡＣＫ）が受信されたとき、パケットが失われると考える。ワイヤレス環境では、パケットロスは、エアインターフェイスに生じるビットエラーにより頻繁に引き起こされる。

ＴＣＰソースは、ビットエラーにより生じるパケットロスと、混雑により生じるパケットロスとの間を区別できないので、ビットエラーの場合にも、混雑の場合のように、接続のレートを誤って減少させる。ＴＣＰが開発されそしてワイヤードリンクにわたって送信するように最適化されていることは、ＴＣＰベースのトラフィックがワイヤレスリンクを経て送信されるときに重大な問題となる。欠落データの再送信を経てエアインターフェイスエラーを取り扱うために、「自動リピート・リクエスト（ＡＲＱ）及びハイブリッドＡＲＱ（ＨＡＲＱ）」のようなＵＭＴＳ及びＬＴＥ無線レイヤ特徴が導入された。これらの特徴は、全体的な性能を改善するが、ＴＣＰラウンドトリップ時間（ＲＴＴ）も増加させる。ＡＲＱ及びＨＡＲＱにより導入される改善に加えて、過渡的カバレージの問題の場合にはＴＣＰ性能低下が依然生じ、ハンドオーバーの場合にＸ２（ＬＴＥ）又はＩｕｒ（Ｉ−ＨＳＰＡ）を経てＴＣＰセグメントを転送することによりＴＣＰ ＲＴＴが急激に増加し、ハンドオーバー及びネットワーク非対称性の場合に順番の狂ったデータ配送によってＴＣＰ再送信が引き起こされる（ＬＴＥでは、セルの縁付近にＤＬカバレージしかないことが起こる）。これらの場合には、データ転送の効率が限定され、ＴＣＰのＲＴＯタイマーが時間切れし、ＴＣＰのスタートを低速化して、ＴＣＰソースに対する回復時間を長くする（回復時間とは、問題が生じる前に経験したスループットに到達するのに必要な時間である）。

本発明によれば、これらの環境においてＴＣＰの性能低下を防止するための考えられる方法は、送信問題が検出され又は予想されるときにＴＣＰソースを凍結し、そしてシステムが再び効率的に動作できるときにＴＣＰのオペレーションを再開することである。これは、悪い無線チャンネル状態又はハンドオーバーにより生じるＴＣＰ低速スタートの確率を最小にすると共に、カバレージの問題又はハンドオーバーが終わった後に低速スタートを通して回復するのではなく同じ速度でＴＣＰを続けられるようにする。この解決策は、高プライオリティ接続にサービスするニーズが過激な手段を要求するときコールドロップを経て又はスタービングを経て低プライオリティ接続を終了する有用な代替え策である。

しかしながら、送信問題が長時間続く場合には、最終的に幾つかのコールがドロップされねばならない。又、移動加入者の観点から、凍結された接続を、その接続を終了せずに（即ちウェブページのダウンロードを手動でキャンセルせずに）、長時間不定に許容すると仮定することは現実的でない。それでも、ＴＣＰ凍結は、短時間の送信問題が加入者へエスカレートすることを防止する上で助けとなり、従って、本発明は、満足なクオリティの経験を維持する上で助けとなる。

本発明は、進化型ノードＢ（ｅＮＢ）／Ｉ−ＨＳＰＡベーストランシーバステーション（ＢＴＳ）に付属するユーザがＴＣＰを経てデータ接続（アップリンク又はダウンリンク）を得るようなＬＴＥ／Ｉ−ＨＳＰＡ無線アクセスネットワークに適用される。

更に、本発明は、ＢＴＳに付属するユーザがＨＳＰＡベアラを使用することによりＴＣＰを経てデータ接続を得るようなワイドバンドコード分割多重化アクセス（ＷＣＤＭＡ（登録商標））／ＨＳＰＡ無線アクセスネットワークにも適用される。

ＴＣＰ性能に否定的に影響する無線アクセスネットワーク特有のファクタは、例えば、エアインターフェイスエラー、非対称性、過渡的カバレージの問題、例えば、カバレージホール、ハンドオーバー中の転送、及び過渡的エアインターフェイス混雑である。これらファクタの状況において、ＴＣＰソースは、そのデータレートを下げ、それに続いて比較的長い回復時間があり、その後、ソースは、適度なレートで送信することができる。

図１は、ＴＣＰフローの上に略述された考えられる問題の影響を示す。比較として、この図は、性能が低下する前の状態にフローが凍結され、次いで、低下状態が過ぎた後にその特定の状態からフローが続く場合に何が起こるかも示している。凍結がないと、ＴＣＰフローがその元のスループットに再び到達するまで長い回復時間があり、その間に甚だしい性能低下があって、アプリケーションのための実際上使用不能なデータレートを与える（ＴＣＰ時間切れの場合には、スループットがゼロ又はその付近に低下し得る）。他方、フローを凍結する場合には、回復時間が著しく短くなり、それにより、ＴＣＰベースのアプリケーションの応答性を維持し、ひいては、全体的クオリティの経験が移動加入者に与えられる。

エアインターフェイスエラーによるＰＣＴ性能低下は、ＴＣＰ固有の問題である。というのは、そのオペレーションが、送信媒体には実際上ビットエラーがないとの仮定に基づいているからである。これは、ワイヤードシステムの場合にも言えることであるが、送信異常によるパケットドロップの量が多いワイヤレスシステムの場合にはそうでない。ＴＣＰソースは、検出されたパケットドロップの理由に関する情報をもたず、即ち混雑によるパケットロスと送信エラーによるパケットロスとの間を区別することができない。

パケットドロップの理由に関わらず、ＴＣＰソースの反応は同じであり、即ち接続レートが下げられ、そして失われたと仮定されたパケットが再送信される。これは、送信ネットワーク混雑の場合には良好な解決策であるが、エアインターフェイスエラーの場合には効率的でない。というのは、ソースのスループットが不必要に下がり、全体的なシステム性能、及びユーザが経験するサービスのクオリティを低下させるからである。

ｅＮＢ又はＩ−ＨＳＰＡ ＢＴＳ（ＤＬ）又はＵＥ（ＵＬ）に位置されたＨＡＲＱ機能は、エアインターフェイスエラーの場合に欠落データを再送信する。問題が持続する場合には、データが首尾良く転送されるか又は最大量の許容再送信に到達するまで再送信が繰り返される。後者のケースでは、ＲＮＣ、ｅＮＢ又はＩ−ＨＳＰＡ ＢＴＳ（ＤＬ）又はＵＥ（ＵＬ）プロトコルに位置されたＲＬＣのＡＲＱ機能が同様のメカニズムを経てエアインターフェイスエラーに気を付ける。重大なエアインターフェイス問題では、結局のところ、最大量の許容ＲＬＣ再送信に到達し、データが破棄される。このメカニズムは、散発的なエアインターフェイスの問題を取り扱うには効率的であるが、依然、ＴＣＰの時間切れを引き起こすことがある。というのは、再送信がＲＴＴを増加させて、結局は、ＴＣＰ ＲＴＯタイマーの時間切れを招くからである。ソースのレートが急激に下がるときには、ＴＣＰ時間切れに続いて、常に、低速スタートとなる。更に好都合な場合には、ＲＴＴが増加しても、データレートが若干低下するだけである。

散発的なエアインターフェイスの問題に加えて、無線状態が悪いためにパケットロスが生じる状況が依然ある。例えば、セルの縁にいるＬＴＥユーザは、ネットワーク非対称的現象に悩まされ、即ちｅＮＢの高い送信電力のため、ユーザは、ダウンリンク接続を得るが、アップリンク方向にデータを送信することができない。従って、ダウンリンクで受信されたデータは受信器により確認することができない。というのは、アップリンクにおいて確認が送信されないからである。これは、複数の連続的時間切れを引き起こす。不必要なスループットの低下に加えて、これは、複数の時間切れ及び指数関数的なＴＣＰバックオフアルゴリズムのために、ＴＣＰソースがデータの再送信を試みる時点と時点との間に長いインターバル（＞１分）が経過するという問題も引き起こす。従って、無線状態は、不成功な再送信の直後に回復し、そしてソースは、次の再送信が行われるまでそれが通知されないことになる。そのように、ＴＣＰフローは、不必要に長い時間中アイドル状態となる。セルのカバレージエリアにホールがあるときにも、同じ問題が生じる。

エアインターフェイスのパケットロスは、ＴＣＰ性能に否定的影響を及ぼす唯一の無線アクセス特有の問題ではない。ＬＴＥ及びＩ−ＨＳＰＡシステムは、無線プロトコルを伴う分散型アーキテクチャーを、ハンドオーバー決定を担当するｅＮＢ又はＩ−ＨＳＰＡ ＢＴＳにおいて終了させる。ＬＴＥでは、ハンドオーバー中に（ＬＴＥには、ハードハンドオーバーしかない）、ソースｅＮＢがＸ２インターフェイスを経てターゲットｅＮＢへＤＬパケットを転送する（又はＳＩベースハンドオーバーの場合には、転送がＳＩインターフェイスを経て行われ、通常、Ｘ２ベースのハンドオーバーに比して長い転送経路及び送信遅延を生じさせる）。ＵＥデータは、ＵＥがターゲットｅＮＢに付属できるようになった後にターゲットｅＮＢによりＳＩインターフェイスを経てＳＡＥ−ＧＷへ送信される。付属が成功すると、ＳＡＥ−ＧＷの経路スイッチがトリガーされ、その結果、所与の時間に、ターゲットｅＮＢが、（ＳＡＥ−ＧＷから）ＳＩを経て及び（ソースｅＮＢから）Ｘ２インターフェイスを経てＵＥへ向けられたパケットを受信することになる。

Ｘ２インターフェイスを経て転送されるパケットは、ＳＩインターフェイスを経てターゲットｅＮＢへ直接送信されるものとは異なるそしておそらくは長い経路を進行する。両インターフェイスには混雑が生じ得る。これらのメカニズム、即ちＸ２転送及び遅い経路スイッチングは、ＴＣＰ性能の観点から２つの問題を引き起こし、即ち第１に、ＴＣＰソースは、急激な遅延増加のために低速スタートへ移行することがあり（転送パケットが長い経路を進行するので、ＲＴＴの急激な増加により、ＴＣＰソースのＲＴＯタイマーが時間切れして低速スタートを引き起こす機会が生じ）、そして第２に、行先へのＴＣＰパケットの順序ずれした配送のために不必要な再送信を生じることがある（ソースとターゲットｅＮＢを接続しているＸ２インターフェイスの遅延が、ＳＡＥ−ＧＷとターゲットｅＮＢを接続しているＳＩインターフェイスの遅延より大きいときには、経路スイッチの後にＳＩインターフェイスを経て送られるパケットが、Ｘ２インターフェイスを経て転送されたパケットが順序ずれ送信を生じさせる前に受信されて、紛らわしくもＴＣＰソースへパケットロスを指示するＡＣＫを複製することがある）。後者の問題を回避するため、ＬＴＥシステムでは、特殊な「エンドマーカー」ＧＴＰパケットが導入された。ＳＡＥ−ＧＷは、経路スイッチの前に、エンドマーカーＧＴＰパケットをソースｅＮＢへ送信する。このパケットは、それ自身、ユーザデータは含んでおらず、その唯一の目的は、ソースｅＮＢが、ユーザデータを含むＧＴＰパケットをそれ以上転送しないことを明確に指示することである。

従って、ターゲットｅＮＢは、Ｘ２インターフェイスを経てエンドマーカーが受信されるまで、ＳＩインターフェイスを経て受信したパケットをＵＥへ送信しない。しかしながら、エンドマーカーパケットがトランスポートネットワークにおいて失われて、ターゲットｅＮＢがユーザへトラフィックを送信するのを妨げることがある。これを回避するために、エンドマーカータイマーがターゲットｅＮＢにおいて実施され、そのタイマーが時間切れする前にエンドマーカーパケットが受信されない場合には、ターゲットｅＮＢが、ＳＩインターフェイスを経て受信したパケットをとにかくユーザへ送信し始める。エンドマーカータイマーの設定が不適切であると、ＴＣＰソースがパケットロスを誤って検出する状況を招く。タイマーの設定値が高過ぎると、エンドマーカーパケットのロスが、ＳＩインターフェイスを経て受信した新たなパケットを、例えば、長い時間インターバル、遅延させ、ＴＣＰ ＲＴＯタイマーの時間切れをトリガーする。タイマーの設定値が低すぎる場合には、高いＸ２遅延のために、エンドマーカータイマーは、最後に転送されたパケットが受信される前に時間切れし、複製ＡＣＫをトリガーする順序ずれした配送を生じさせることになる。

Ｉ−ＨＳＰＡシステムでは、ハンドオーバー中に、ＵＬ及びＤＬの両トラフィックが関連Ｉ−ＨＳＰＡ ＢＴＳ間でＩｕｒインターフェイスを経て転送される。その場所で転送すると、トラフィックの経路が突然増加し、遅延を突然増加させてＲＴＯタイマーが時間切れする可能性を生じさせ、ＴＣＰソースが低速スタートに入る。

上述したように、ＬＴＥ及びＩ−ＨＳＰＡの両システムでは、ハンドオーバー中の転送は、性能上の問題と、容量制限されたラストマイルリンクが搬送すべき付加的な負荷とを生じさせる。これらの問題に対する本発明の良好な解決策は、ハンドオーバーの始めにＴＣＰ接続を凍結し、そしてハンドオーバーが完了した後にそれらのオペレーションを再開することである。

ユーザの移動性のために、ｅＮＢ又はＷＣＤＭＡ／ＨＳＰＡ／Ｉ−ＨＳＰＡ ＢＴＳによりサービスされるべきトラフィック需要は、時間と共に変化し続ける。従って、プライオリティの高いユーザにサービスするために、プライオリティの低いユーザのスループットを下げねばならないか、又はそれらのあるものを完全にドロップしなければならないときがある。増加したトラフィック需要がしばらく保たれるだけであっても（即ち、何人かのユーザがｅＮＢを去るか又はそれらの接続を終了する）、プライオリティの低いＴＣＰ接続のスループットが著しく低下し、そして比較的長い回復時間の後に、それに影響される接続の元のスループットに到達する。他の場合には、高プライオリティトラフィックにサービスすることが問題であるときに、過渡的なエアインターフェイス混雑が生じ得る。これらの場合には、凍結再開メカニズムが良好なオペレーションを生じさせる。というのは、接続の短時間回復を許し、ＴＣＰの低速スタートを防止するからである。

移動ネットワークでは、エアインターフェイスは、ＴＣＰ接続のＥ２Ｅ経路における唯一のワイヤレスリンクとはならない。というのは、ＢＴＳは、マイクロ波無線リンクを経てワイヤード移動バックホールにしばしば接続されるからである。マイクロ波リンクのビットエラー率（ＢＥＲ）は、ＬＴＥ又はＷＣＤＭＡエアインターフェイスの場合に使用されるものと同様のエラー検出及び修正メカニズムを使用して、ほとんどの動作時間におけるワイヤードリンクのＢＥＲと同様と考えられる。ＢＥＲは、無線状態の望ましからぬ変化（例えば、フェージング、干渉、等）のために短い時間インターバル中に突然増加し、マイクロ波リンクの容量を減少させる。というのは、エアインターフェイスエラーが検出されたときには、より冗長なコード及び変調スキームが選択されるからである。これらの突然の変化は、ＴＣＰ接続のスループットを著しく低下させる。マイクロ波リンクの容量変化に加えて、トランスポートリンク（特に、容量制限のあるラストマイルリンク）上の過渡的混雑がＱｏＳの低下を引き起こす。

本発明は、エアインターフェイスカバレージの問題、過渡的エアインターフェイス又はトランスポート混雑が検出され又は予想されるとき、ハンドオーバーの決定がシステムによりなされるとき、又はサービスの権利レベルを確保するためにプライオリティの高いユーザをプライオリティの低いユーザより高くプライオリティ付けすることが要求されるときに、ＴＣＰ接続を凍結する解決策を提案する。凍結されるべく選択されたＴＣＰフローは、システムが安全オペレーションの可能性を確かめた後に再開することが許される。

ワイヤレスネットワークにおけるＴＣＰ性能の問題は、多数の論文に研究されている。ドキュメント［３］及び［２］は、ワイヤレス移動ネットワークのＴＣＰ性能を改善するための提案の概略を示す。

又、別のＴＣＰ凍結原理がドキュメント［１］に紹介されている。その論文の著者は、ＵＥがハンドオーバーの発生を予想するときに、ＵＥのＴＣＰ受信器がＴＣＰ ＡＣＫを０広告ウインドウサイズ（ゼロ・ウインドウ・アドバタイズメント−ＺＷＡ）で送信するようにさせることによりハンドオーバーの時間中にＴＣＰソースを「凍結(freeze)」することを提案している。このＺＷＡは、ＴＣＰソースが全ての再送信タイマーを凍結して、持続モードに入るように強制する。ハンドオーバーが終了すると、ＵＥのＴＣＰ受信器は、３重のＡＣＫを肯定的ウインドウサイズで送信して、ソースが持続モードを去るようにし、持続モードオペレーション以前に使用された同じＲＴＯタイマー値及び混雑ウインドウサイズを使用してセグメントの送信を続ける。

ドキュメント［１］で提案された解決策及び以下に述べる本発明による解決策は、両方とも、ＴＣＰ凍結の原理を使用するが、それらの間にはＺＷＡを送信する責任を負う機能の配置に関して大きな相違がある。というのは、ドキュメント［１］は、それをＵＥにおいて実施することを提案するが、本発明では、それを無線アクセスノードにおいて実施することが提案されるからである。ＵＥに凍結機能をもたせる場合の欠点は、ＵＥが移動ネットワークに関して限定された情報しか持たず、従って、ハンドオーバー及びネットワークカバレージホールを適切に予測できず、且つワイヤレストランスポートネットワークリンクの短期プライオリティ付け及び悪化無線状態により生じる問題を取り扱うことができないことである。

又、ＵＥがアプリケーションプロトコルスタックのＴＣＰレイヤとＲＲＣレイヤとの間にクロスレイヤ機能を実施することも要求される。更に、この解決策は、移動ネットワークオペレータによって直接影響されることはない。

それ故、本発明により無線ネットワークノードにおいて実施されるＴＣＰ凍結メカニズムは、より広い範囲及びより正確な凍結トリガーを与えることができ、且つＵＥに対して透過的で、ＵＥ製造者に規格及び実施上の影響を及ぼさないので、ＵＥにおいて実施されるものより有利である。

ドキュメント［６］は、移動ネットワークにおいてＴＣＰが切り離されるのを防止するために単純な凍結（ＰＥＴＳ）フレームワークを使用して持続ＴＣＰにおいてＴＣＰ凍結原理及び移動ＩＰを結合する解決策を提案する。そのフレームワークは、ＩＣＭＰメッセージを使用して、リンクの状態を監視しそしてリンクの故障を検出し、その際に、故障の期間中にＺＷＡによりＴＣＰフローが凍結される。従って、ＴＣＰ接続の終了をＰＥＴＳにより回避することができる。

しかしながら、この解決策は、本発明により解決される問題（悪いチャンネル状態における増加ＲＴＴ及びパケットロスのための偽の時間切れ、等）に取り組むことができない。というのは、ＩＣＭＰベースのリンク状態検出がその目的に適していないからである。又、本発明は、新たなＩＣＭＰメッセージをそのオペレーションに対して定義することに依存するものではない。

ＴＣＰ凍結原理と同様の解決策がドキュメント［４］により提案された解決策によって使用されている。この解決策では、ＢＴＳがワイヤレスリンクの不良状態について明確なフィードバックを、固定ネットワークに存在するＴＣＰソースへ送信して、全ての時間切れタイマーをリセットする。この目的のために、ドキュメント［４］は、明確な不良状態通知（ＥＢＳＮ）ＩＣＭＰメッセージを実施することを提案している。しかしながら、ドキュメント［４］によるＥＢＳＮメカニズムは、新たなＩＣＭＰメッセージの実施を要求するが、本発明による解決策は、いかなる種類の新たなメッセージタイプの定義及び実施も要求しない。更に、ＥＢＳＮは、拡張型ＴＣＰ機能を要求し、これが、ドキュメント［４］に提案された解決策の有用性を制限している。本発明による解決策は、付加的なＴＣＰ機能を要求せず、そのオペレーションは、ＴＣＰレイヤに対して透過的である。

ＬＴＥネットワークにおけるハンドオーバー中の偽のＴＣＰ時間切れを回避するためにＴＣＰ凍結原理以外の解決策がドキュメント［５］によって使用されている。ＴＣＰソースを凍結するのではなく、著者により提案される２つの方法は、転送されるパケットの量を減少するという考え方をベースとしている。

本発明による解決策とは対照的に、両方の方法は、標準化されたハンドオーバーメッセージシーケンス（ＴＳ２３．４０１、ＴＳ．３６．４１３）の変更を要求する。というのは、経路のスイッチがターゲットｅＮＢにおけるハンドオーバー確認メッセージの受信より早期に行われるからである。これらの解決策の付加的な欠点は、ハンドオーバーが確認される前に経路スイッチを実行することで、ハンドオーバー不成功の際にシステム状態に一貫性がなくなるというリスクが導入されることである。ハンドオーバー及び制限された無線状態の場合にはＴＣＰトラフィックが停止されないので、これらの解決策では、混雑に関係のないパケットロスの影響を軽減することができない。

従来のドキュメントは、次の通りである。
［１］T. Goff, J. Moronski, D. S. Phatak, and V. Guptaの“Freeze−TCP: A true end-to-end TCP enhancement mechanism for mobile environments”、In proc. Of IEEE Infocom 2000, Tel-Aviv、第1537-1545ページ、２０００年５月２６−３０日。
［２］H. Elaraag、“Improving TCP Performance over Mobile Networks”、ACM Computing Surveys、第３４巻、第３号、２００２年９月、第３５７−３７４ページ。
［３］Y. Tian, K. Xu, and N. Ansari、“TCP in Wireless Environments: Problems and Solutions”、IEEE Radio Communications、第４３巻、第３号、２００５年３月、第Ｓ２７−Ｓ３２ページ。
［４］B. Bakhsi, P. Khrisna, N. H. Vaidya, and D. K. Pradhan、“Improving of TCP over wireless networks”、In proc. of 17^th International Conference on Distributed Computing Systems、１９９７年、第３６５−３７３号。
［５］D. Pacifico, M. Pacifico, C. Fischione, H. Hjalrmasson and K. H. Johansson、“Inproving TCP During the Intra LTE Handover”、In Proc. of IEEE Globecom ２００９年、ホノルル、第１−８ページ、２００９年１１月３０日−１２月４日。
［６］C. So-In, R. Jain, G. Dommety、“PETS: Persistent TCP using Simple Freeze”、In proc. of First International Conference on Future Networks、中国北京、第９７−１０２ページ、２００９年１０月１４−１７日。

本発明によれば、移動ネットワークのＴＣＰ性能を改良するための方法、装置及びコンピュータプログラム製品が提供される。

本発明の１つの態様によれば、
コンテンツサーバーとユーザ装置との間の接続のクオリティ尺度を中間ネットワークノードにおいて得、
クオリティ尺度が所定の条件を満足するかどうか中間ネットワークノードにおいて検出し、
クオリティ尺度が所定の条件を満足しない場合には、コンテンツサーバーとユーザ装置との間の接続の凍結モードをトリガーする確認メッセージを中間ネットワークノードにより送信する、
ことを含む方法が提供される。

前記態様のもとで定義される本発明の更に別の改善によれば、
−コンテンツサーバーとユーザ装置との間の接続は、サーバーからユーザ装置へコンテンツをダウンロードするためのダウンリンクであり、そして確認メッセージは、コンテンツサーバーへ送信され、
−コンテンツサーバーとユーザ装置との間の接続は、ユーザ装置からサーバーへコンテンツをアップロードするためのアップリンクであり、そして確認メッセージは、ユーザ装置へ送信され、
−前記検出は、クオリティ尺度が今度の所定時間周期内に所定の条件を満足するかどうか、得られたクオリティ尺度に基づいて、中間ネットワークノードにおいて予想することを含み、
−前記方法は、更に、
接続が凍結された後に、クオリティ尺度が所定の条件を満足するかどうか中間ネットワークノードにおいて検出し、
クオリティ尺度が所定の条件を満足する場合には、別の確認メッセージをコンテンツサーバー又はユーザ装置へ送信して、接続の凍結解除(defreeze)モードをトリガーする、
ことを含み、
−前記方法は、更に、所定の時間周期が経過した後に別の確認メッセージをコンテンツサーバー又はユーザ装置へ送信して、接続の凍結解除モードをトリガーすることを含み、
−クオリティ尺度は、無線チャンネルのクオリティ、セルの全負荷、エアインターフェイスカバレージ、過渡的なエアインターフェイス又はトランスポート混雑、又はハンドオーバー決定、或いは高プライオリティユーザのプライオリティ付けに関連し、
−前記接続は、送信コントロールプロトコルＴＣＰ接続であり、
−中間ネットワークノードは、無線アクセスノードである。

本発明の別の態様によれば、
コンテンツサーバーとユーザ装置との間の接続のクオリティ尺度を得るように構成された取得ユニットと、
クオリティ尺度が所定の条件を満足するかどうか検出するように構成された検出ユニットと、
クオリティ尺度が所定の条件を満足しない場合には、コンテンツサーバーとユーザ装置との間の接続の凍結モードをトリガーする確認メッセージをコンポーズするように構成された凍結ユニットと、
確認メッセージを転送するように構成されたトランシーバと、
を備えた装置が提供される。

前記態様のもとで定義される本発明の更に別の改善によれば、
−コンテンツサーバーとユーザ装置との間の接続は、サーバーからユーザ装置へコンテンツをダウンロードするためのダウンリンクであり、そして確認メッセージは、コンテンツサーバーへ送信され、
−コンテンツサーバーとユーザ装置との間の接続は、ユーザ装置からサーバーへコンテンツをアップロードするためのアップリンクであり、そして確認メッセージは、ユーザ装置へ送信され、
−検出ユニットは、更に、クオリティ尺度が今度の所定時間周期内に所定の条件を満足するかどうか、得られたクオリティ尺度に基づいて、予想するように構成され、
−検出ユニットは、更に、接続が凍結された後に、クオリティ尺度が所定の条件を満足するかどうか検出するように構成され、そしてクオリティ尺度が所定の条件を満足する場合には、凍結ユニットが、接続の凍結解除モードをトリガーする別の確認メッセージをコンポーズするように構成され、
−凍結ユニットは、更に、所定の時間周期が経過した後に、接続の凍結解除モードをトリガーする別の確認メッセージをコンポーズするように構成され、
−クオリティ尺度は、無線チャンネルのクオリティ、セルの全負荷、エアインターフェイスカバレージ、過渡的なエアインターフェイス又はトランスポート混雑、又はハンドオーバー決定、或いは高プライオリティユーザのプライオリティ付けに関連し、
−前記接続は、送信コントロールプロトコルＴＣＰ接続である。

本発明の別の態様によれば、コンピュータメモリにロードされたとき上述した方法のいずれかの段階を生じさせるコード手段を含むコンピュータプログラム製品が提供される。

本発明の更に別の態様によれば、上述したコンピュータプログラム製品であって、ソフトウェアコード部分が記憶されたコンピュータ読み取り可能な媒体を備えたコンピュータプログラム製品が提供される。

本発明の更に別の態様によれば、上述したコンピュータプログラム製品であって、処理装置の内部メモリにプログラムを直接ロードできるコンピュータプログラム製品が提供される。

前記態様のもとで定義される本発明の更に別の改善によれば、処理装置は、無線アクセスノードである。

本発明の実施形態の以上の説明及び以下の説明に関して、その説明及び図面に使用される「手段」及び「ユニット」という語は、同じ意味を有し、従って、交換可能であることに注意されたい。

これら及び他の目的、特徴、細部及び効果は、添付図面を参照した本発明の実施形態の以下の詳細な説明から明らかとなろう。

本発明の一実施形態によるＴＣＰフローの性能を示す図である。 本発明の一実施形態による凍結エージェントの動作を示す図である。 システムアーキテクチャーが本発明の一実施形態によるｅＮＢ／Ｉ−ＨＳＰＡＢＴＳ常駐凍結エージェントである場合を示す図である。 システムアーキテクチャーが本発明の一実施形態によるＳＡＥ−ＧＷ／ＧＧＳＮ常駐凍結エージェントである場合を示す図である。 システムアーキテクチャーが本発明の一実施形態によるＲＮＣ常駐凍結エージェントである場合を示す図である。 本発明の一実施形態による凍結エージェントのアーキテクチャーを示す。 本発明の一実施形態によるＡＣＫ取り扱いエンティティの動作を示す。 本発明の一実施形態による検出／予想エンティティの動作を示す。 本発明の一実施形態による凍結エージェント間通信を示すフローチャートである。 本発明の一実施形態によるネットワーク非対称の場合のシミュレーション結果を示す図である。 本発明の実施形態による中間ネットワークノードの一例を示す図である。

本発明の実施形態は、それら実施形態の一般的な例及び特定の例を参照して以下に詳細に述べる。しかしながら、この説明は、一例に過ぎず、ここに述べる実施形態は、本発明をそれに限定するものではないことを理解されたい。

本発明の一実施形態によれば、無線アクセスノード（ｅＮＢ、Ｉ−ＨＳＰＡ ＢＴＳ、ＳＡＥ−ＧＷ、ＲＮＣ）に位置する機能であって、ユーザプレーン接続の状態（無線チャンネルクオリティ、トランスポート混雑、ハンドオーバー、等）、セルの全負荷、又は他の当該クオリティ尺度に従い、且つ通常のＡＣＫメッセージを使用して選択されたＴＣＰ接続を凍結する機能を導入するという点で、従来とは異なる解決策が提案され、即ち本発明の実施形態による解決策は、ＴＣＰソースを凍結するために専用ＩＣＭＰ又は他のコマンドの使用を要求するものではない。従って、ここに提案する機能は、ＴＣＰレイヤに対して透過的であり、ＴＣＰソース又は受信器側に必要とされる付加的な機能はない。

以下、凍結エージェント（ＦＡ）と称されるここに提案する機能の範囲は、所与のＴＣＰフローが、無線カバレージの問題、トランスポート混雑又はハンドオーバーによる性能低下を経験するときを検出及び／又は予想し、そしてＴＣＰフローを凍結して、性能低下を防止することである。ＴＣＰフローのデータ転送は、過渡的な無線カバレージの問題が終わった後に又は（ハンドオーバーの場合に）遅い経路スイッチングが遂行されたときに再開される。過渡中に、ＴＣＰデータパケットは、通常の動作に基づいてシステムにより転送される。更に、適切なＱｏＳで高プライオリティ接続にサービスするのに低プライオリティ接続をドロップすることが要求されるか、又はプライオリティ付けが低プライオリティ接続に重大な性能低下をもたらすときに、ＦＡが使用される。

本発明によれば、数秒以内に終わる過渡的な障害又はネットワークサービスの短時間の中断（ＬＴＥハンドオーバー中にサービス中ｅＮＢから切り離すときとターゲットｅＮＢに首尾良く付属させるときとの間に費やされる時間のような）に反応することができる。これらの場合に、凍結メカニズムは、低いチャンネルクオリティに露出される接続が不充分なサービスレベルを経験し、システムによりドロップされ、又は悪いエンドユーザ経験のために加入者により終了されるときに現在状況とは対照的な改善されたＱｏＳを与える。ＴＣＰが凍結した後に、その機能は、当該クオリティ尺度を監視し続け、凍結を終了してデータ転送を再開できる最適な時間を見出す。ハンドオーバーにおいて、この尺度は、（ＳＡＥ−ＧＷがダウンリンク経路スイッチに対する必要なベアラ変更を完了した後に）ＭＭＥによりターゲットｅＮＢへ送られる経路スイッチ要求Ａｃｋメッセージであるか、又はターゲットｅＮＢへの首尾良い付属である。凍結が、トランスポートクオリティの低下（遅延の増加及び／又はパケットのドロップ、スループットの低下、高い負荷、接続の問題、等）によりトリガーされるか、又はセル負荷の増加によりトリガーされると、この機能は、凍結解除に適した時間を検出するために当該尺度の収集及び評価を続ける。

同様に、ＬＴＥシステムにおける無線カバレージの問題のためにＴＣＰフローが凍結された場合には、ＦＡは、その問題が終わって接続を安全に再開できる時間を検出するための手段をもつ必要がある。ＵＥの全てのフローが凍結されるのではない（例えば、ＶｏＩＰ又は他の非ＴＣＰベースのフローも存在する）場合には、ｅＮＢは、前記ＵＥの非凍結フローに対応するＣＱＩレポートから無線リンクのクオリティに関する情報を収集することができ、これは、凍結された接続を再開するに充分なほどクオリティが良好になったかどうか評価する可能性を与える。全てのフローが凍結された場合には、ＵＥは、セル特有の参照記号の受信パワー（ＲＳＲＰ）を依然監視する。これらの参照記号は、全てのセルにおいて標準化リソースエレメントで送信され（即ち、それら記号の時間・周波数スケジュールが知られており）、従って、各ＵＥは、ｅＮＢにより全くスケジュールされなくてもその無線リンクのクオリティの良好な推定値を得ることができる。ＵＥは、通常のＲＳＲＰを受信することにより、その無線リンクが回復したことを検出した場合に、スケジューリング要求（ＳＲ）ＲＲＣメッセージをＳＲＢＯシグナリングベアラにおいて送信し、これは、ランダムアクセスチャンネル（ＲＡＣＨ）へマップされ、ＵＥが、ｅＮＢにより以前に発行されたスケジューリンググラントを得ることなく、ｅＮＢへ通知を送信できるようにする。ｅＮＢのＲＲＭエンティティは、ＳＲメッセージを受信し、そして回復に関してＦＡに通知し、ＵＥのアイデンティティを指示する。

いずれにせよ、接続を凍結に保つ条件がもはや維持されないとの通知の失敗により接続が不当に長時間くっついて凍結されるのを回避するために接続が特定の時間中凍結された場合に接続を強制的に再開させるガードタイマーが実施される。このタイマーは、凍結の決定を生じた最初のトリガーに関わらず、接続ごとにスタートされねばならない。或いは又、このタイマーは、トリガーの形式に基づいて異なる値にセットされてもよい（即ち、ガードタイマーは、ハンドオーバーでトリガーされる凍結の方が、カバレージホールでトリガーされる凍結より低くセットされる。というのは、ハンドオーバーは、適度な時間制約でコントロールされる事象であるが、カバレージの不充分なエリアにＵＥがどれほど長く存在するか前もって分からないからである）。あるフローを凍結するためのトリガーが、前もって分かる特定の時間インターバル中に他のフローをプライオリティ付けする場合には、ガードタイマーは、この計画された時間インターバル（又はそれより高いビット）にセットすることができる。

上述したように、検出及び予想は、ＦＡが当該無線ネットワーク測定値（例えば、ＲＲＣ事象Ａ３測定値）、トランスポートネットワーク管理情報（例えば、ＭＷＲリンク条件）、トラフィック管理情報（例えば、接続のＱＣＩ又はＳＰＩ）、及びハンドオーバー管理情報（例えば、ＨＯ決定）を収集することを要求する。これらの情報断片に基づいて、当該事象（性能低下を招く事象、例えば、ハンドオーバー、無線状態悪化、等）を検出し又は予想をすることができる。これらの事象は、以後、凍結トリガーと称される。

ＦＡの観点から、接続は、凍結状態にあるか（ＦＡが凍結トリガーを検出しそして適当なアクションを撮る場合）、又は通常の状態にある。ＦＡは、各接続のための専用レジスタを有し、ノードを横断した最後のＡＣＫがそこにコピーされる。この動作は、接続に対して透過的である。というのは、通常の状態では、各ＴＣＰ ＡＣＫがシステムによって受信され、ＦＡレジスタにコピーされ、そして不変のまま転送されるからである。凍結トリガーが受信されると（例えば、ハンドオーバー事象により発生されて）、ＦＡは、関連ＴＣＰ接続を凍結状態にセットして、事象が存在する間にソースを持続モードへ強制することによる性能低下のおそれを回避する。接続に対して凍結状態をセットする際に、その機能は、ＴＣＰ受信器に代わって、接続の記憶されたＡＣＫをゼロ広告ウインドウサイズ（ＺＷＡ）で再送信する（図２）。

ＺＷＡを受信すると、ＴＣＰソースは、持続モードに入り、ＲＴＯタイマー及び混雑ウインドウサイズを凍結し、そして新たなデータの送信を停止する。その間、ＺＷＡを受信する前にソースにより送信されたパケットに対する応答として受信器によって送信された更なるＡＣＫは、ＦＡレジスタにコピーされ（レジスタのコンテンツは、新たなＡＣＫが検出された後に、記憶されたＡＣＫをその新たなものに置き換えることで更新され）、そして変更されたコンテンツと共に送信される（広告ウインドウがゼロにセットされて）。接続が凍結状態にある間に、ＦＡは、凍結状態を維持すべきか終了すべきか決定するために当該尺度の監視を続ける。凍結状態をトリガーした状況がもはや存在しない場合には（即ち、カバレージの問題が終わるか又は遅い経路スイッチングが成功したときには）、それが凍結解除トリガーとみなされ、接続を通常状態へ移行させる。

通常状態へスイッチして戻ると、ＦＡは、受信器に代わって、記憶されたＴＣＰ ＡＣＫを非ゼロ広告ウインドウサイズ（ＮＺＷＡ）で送信する。これは、ＴＣＰソースを持続モードから去らせて、新たなデータの送信をスタートさせる。ＺＷＡの受信とＮＺＷＡの受信との間に費やされる時間中に持続モードにあるＴＣＰソースは、考えられるパケットロス及び長い遅延によって影響されない。従って、それらのレートが不必要に低下せず、ひいては、凍結解除後の回復がより迅速になる。連続するＡＣＫがＦＡによってソースへ不変のまま転送される。ＺＷＡを含むＡＣＫが失われた場合に、受信器は、受信したデータパケットに対する応答としてＡＣＫを送信し続ける。これらのＡＣＫは、ＦＡにより捕獲され、そして変更されたコンテンツ（即ち、ゼロ広告ウインドウ）で送信され、最終的に、ソースを持続モードへ強制的に入れることができる。更に、ＦＡは、ソースがデータ転送を再開したかどうか観察するためにデータパケットを監視しなければならない。トラフィックがない場合には、保護タイマーが終了した後に、ＮＺＷＡを伴うＡＣＫが再送信される。

ＦＡは、ｅＮＢ／Ｉ−ＨＳＰＡ ＢＴＳ／ＲＮＣの各々で又はその選択されたセットで実施され、及び／又はＬＴＥ／Ｉ−ＨＳＰＡ／ＷＣＤＭＡシステムのＳＡＥ−ＧＷ／ＧＧＳＮの全部で又はその選択されたセットで実施され、そしてアップリンク及び／又はダウンリンクＴＣＰ接続を取り扱うことができる。機能が実施されるノードを横断するＴＣＰ接続の全部を機能が取り扱うか又はそのサブセットのみを取り扱うかは、オペレータの方針次第である。例えば、オペレータは、この特徴を特別なユーザのみに与える。ＦＡを実施する（ターンオンする）ノードは、適切な動作に対して互いに通信しなければならない（例えば、ｅＮＢ／Ｉ−ＨＳＰＡ ＢＴＳとＦＡ機能との間のハンドオーバーの場合には、ＺＷＡは、ソースｅＮＢ／Ｉ−ＨＳＰＡ ＢＴＳによって送信されるが、ＮＺＷＡは、ターゲットｅＮＢ／Ｉ−ＨＳＰＡによって送信されねばならない。しかしながら、ＡＣＫは、ソースｅＮＢ／Ｉ−ＨＳＰＡ ＢＴＳにより記憶され、即ち当該情報は、ターゲットｅＮＢ／Ｉ−ＨＳＰＡ ＢＴＳにおいて入手できねばならない）。改善型の凍結トリガー検出及び予想に対してＦＡを実施するノード間の通信も要求される。

凍結トリガーを生じると考えられる事象又は条件は、次のものを含むが、それに限定されない。
（１）指定されたフローの短期プライオリティ付け：プライオリティ付けされないＴＣＰ接続は、プライオリティ付けのインターバルに対して、そのパケットがドロップ／遅延され又は全接続がドロップされるのではなく、凍結される。
（２）ハンドオーバー：ＵＥのハンドオーバーが予想され又は検出された場合に、それに属するＴＣＰ接続は、ハンドオーバーの終了まで、凍結される。
（３）不充分な無線カバレージ：不充分なアップリンク／ダウンリンク無線状態がＵＥについて検出され又は予想される場合には、無線状態が回復するまで、そのＴＣＰ接続が凍結される。
（４）マイクロ波リンク無線状態の悪化：マイクロ波リンクがＢＥＲの増加及び／又はリンク容量の低下に苦しむ間にＢＴＳを通して延びるＴＣＰ接続の全部又は一部分が凍結される。
（５）トランスポートリンクの混雑：プライオリティが低過ぎる接続を強制的に凍結することにより負荷を一時的に下げることができる。

有効な実施は、ＬＴＥ、Ｉ−ＨＳＰＡ又はＷＣＤＭＡ／ＨＳＰＡシステム、ＳＡＥ−ＧＷ、Ｉ−ＨＳＰＡ ＧＷ（ＧＧＳＮ）又はＲＮＣ及びｅＮＢ、Ｉ−ＨＳＰＡ ＢＴＳ又はＷＣＤＭＡ ＢＴＳを経てデータコールを得るユーザで構成される。

凍結エージェント（ＦＡ）は、Ｓ１−Ｕ／Ｇｎ−Ｕインターフェイスを経てＳＡＥ−ＧＷ／ＧＧＳＮに接続されるＬＴＥ ｅＮＢ／Ｉ−ＨＳＰＡ ＢＴＳに付属されるか又はそこで実行されるソフトウェアコンポーネントであり、一方、隣接するｅＮＢ／Ｉ−ＨＳＰＡ ＢＴＳは、Ｘ２／Ｉｕｒインターフェイスを経て接続される。ＦＡは、当該無線ネットワーク測定値（例えば、ＲＲＣ事象Ａ３測定値）、トランスポートネットワーク管理情報（例えば、ＭＷＲリンク状態）、トランスポートネットワーク測定値（例えば、一方向遅延、ＲＴＴ、パケットドロップ比、スループット、負荷）、トラフィック管理情報（例えば、接続のＱＣＩ、オペレータの方針、等）、及びハンドオーバー管理情報（例えば、ＨＯ決定）を収集する。この情報は、凍結トリガー又は凍結解除トリガーである事象を検出及び／又は予想するために使用される。検出のみ可能な事象は、カバレージホール、リンク停止、等である。これらの場合に、ＦＡにより取られるアクションは反応的である。

ハンドオーバー、無線チャンネル悪化、混雑、等の他の事象は、検出及び／又は予想可能である。これらの場合には、ＦＡにより取られるアクションが先見的であるが、前者の場合には、ＦＡのアクションが反応的である。所与の事象の予想（ハンドオーバー、無線チャンネル悪化、混雑、等）及び／又は検出（即ち、カバレージホール、リンク停止、ハンドオーバー、無線チャンネル悪化、混雑、等）と並列に、ＦＡ管理エンティティは、ＴＣＰトラフィックを監視し、そしてｅＮＢ／Ｉ−ＨＳＰＡ ＢＴＳを通過する最新のＡＣＫをＡＣＫレジスタに記憶する。接続ごとに個別のレジスタが維持される。カバレージの問題を検出又は予想しそしてハンドオーバー、等を予想するために無線測定値が使用され、ＭＷＲリンクの過渡的な悪化を検出するためにトランスポートネットワーク管理情報が使用され、トランスポートネットワークの質低下を検出／予想するためにトランスポートネットワーク管理情報及び測定値が使用され（しかしながら、これは、トランスポートネットワーク状態又はトランスポートリンクの負荷に関する情報が顕著なレイテンシーを伴わずに入手でき、従って、過渡的な問題を効率的に検出してＦＡにより処理できる場合に限定され）、所与のユーザがハンドオーバー中であることを検出するためにハンドオーバー決定が使用されるが、ユーザの中で短期プライオリティ付けを遂行するためにトラフィック管理情報が要求され、これは、スケジューリングメカニズムによる長期契約グレードベースのプライオリティ付けの範囲外である。

関連する方針は、ＱＣＩ（ＬＴＥ）又はＳＰＩ（Ｉ−ＨＳＰＡ）システム巾ごとに定義され、そしてネットワーク管理データベース（ＮｅｔＡｃｔ）から各ｅＮＢ／Ｉ−ＨＳＰＡ ＢＴＳへダウンロードされて、凍結アクションに関与できるようにする。更に、ｅＮＢ／Ｉ−ＨＳＰＡ ＢＴＳレベルにおいてシステム巾の方針を局所的に無効化するためのオプションを設けることもできる。方針は、所与の接続に適用されるトリガーを含む。ハンドオーバー関連トリガーが特定のＱＣＩ／ＳＰＩ又は所与の接続に対して構成される場合には、関連ｅＮＢ／Ｉ−ＨＳＰＡ ＢＴＳのＦＡは、Ｘ２／Ｉｕｒインターフェイスを経て当該情報を交換できねばならない。情報のフォーマットは、所有権のあるものでも、標準的なものでもよい（図３）。必要な情報を搬送するのに、新たなメッセージを定義することが要求されず、任意の情報エレメント（ＩＥ）として既存のものに追加することができる。例えば、ＬＴＥでは、Ｘ２−ＡＰリソース状態更新メッセージは、あるＦＡからピアＦＡへＦＡ状態情報を周期的に報告するために任意のＩＥのプレースホルダーとして使用することができる。ＨＯトリガーされる凍結の場合には、Ｘ２−ＡＰ ＳＮ状態転送メッセージ（標準的なＨＯシグナリングの一部分）は、最新のＺＷＡをソースｅＮＢからハンドオーバー中のＵＥのターゲットｅＮＢへ標準的なＨＯシグナリングの一部分として転送するのに使用できる（ＵＥの複数のフローが凍結を受ける場合には、全ての各フローのＺＷＡが送信されねばならない）。

初期のハンドオーバー要求メッセージに対してＳＮ状態転送が好ましい理由は、受け入れコントロールがＵＥにハンドオーバーを実行させない場合にはターゲットｅＮＢによりそのメッセージを依然拒絶できるが、ＨＯが許可された後にはＳＮ状態転送メッセージがソースｅＮＢからターゲットｅＮＢへ送信されることである。メッセージ及び当該ＩＥを含む手順は、以下に詳細に述べる。

所与の接続に対して、ＦＡは、ユーザプロフィールによって許された凍結アクションに関連する特定のデータのみを監視する（トリガーを検出又は予想するために）。凍結トリガーが検出されると、ＦＡは、接続のレジスタに記憶されたＡＣＫを再使用することによりＺＷＡを送信する。凍結解除が検出されると、ＦＡは、接続のレジスタに記憶されたＡＣＫを再使用することによりＮＺＷＡを送信する。両方の場合に、記憶されたＡＣＫの広告ウインドウフィールドだけが、再送信の前に変更される。有効な代替え策は、ＮＺＷＡ内の広告ウインドウサイズを、オリジナルＡＣＫに含まれたものより小さな値にセットすることである。このオプションは、そうしている間に受信器の状態が変化して、オリジナルＡＣＫで報告されたデータの量を取り扱いできなくなることが起きるので有用である。ＮＺＷＡは、データの流れを再スタートさせ、パケットが受信器に到達すると、正しい広告ウインドウサイズで新たなＡＣＫをトリガーする。凍結状態の間に、新たなＡＣＫは、広告ウインドウをゼロにセットして転送される。

或いは又、ＦＡは、ＳＡＥ−ＧＷ／Ｉ−ＨＳＰＡ ＧＷ（ＧＧＳＮ）に付属された又はそこで実行されるソフトウェアコンポーネントである。この位置は、ＳＡＥ−ＧＷ／Ｉ−ＨＳＰＡ ＢＴＳによりサービスされるｅＮＢ／Ｉ−ＨＳＰＡ ＢＴＳに接続されたユーザの各ＴＣＰベースのデータフローをＦＡが取り扱いできるようにする。或いは又、ＦＡにより取り扱われるフローの数は、オペレータにより定義されるトラフィック管理方針に適合するものに制限される。しかしながら、ＴＣＰ凍結をトリガーすることが許された事象に基づいて、ＦＡは、全トラフィック混合も監視する。ＦＡの中央位置は、ハンドオーバーの場合に完全コントロールされる可能性のような利益を与え、即ち別の無線アクセスノードで実行されるピアＦＡと通信する必要はない。次いで、無線カバレージの問題は、ｅＮＢ／Ｉ−ＨＳＰＡ ＢＴＳから当該測定値が収集される場合だけＦＡにより取り扱うことができる。その中心位置であるために、潜在的に重大な性能低下を引き起こすか又は低プライオリティ接続の選択的破棄を要求する移動バックホール及びバックボーンにおける過渡的なトランスポートネットワーク問題は、容易に検出することができる（図４）。

ＷＣＤＭＡ／ＵＭＴＳシステムでは、ＦＡは、ＲＮＣに付属された又はそこで実行されるソフトウェアコンポーネントである。ＲＮＣは、ＦＡの唯一の実現可能な位置である。というのは、これは、無線レイヤ２のプロトコルが終了されるネットワークエレメントであり、従って、ＦＡがＴＣＰパケットに直接アクセスできるからである。ＦＡの機能及び能力は、ＬＴＥ／Ｉ−ＨＳＰＡシステムの場合に説明したものと同様である。ＲＮＣのリロケーション中にＨＳＤＰＡ接続の性能を改善するためにＦＡが適用されるときには、その解決策が、当該ＲＮＣ間で情報を交換するための能力を有していなければならない（図５）。

ＦＡは、４つの主たるエンティティ、即ちフロー分類エンティティ、ＡＣＫ取り扱いエンティティ、トリガー検出及び予想エンティティ、及び最後に、凍結管理エンティティ（図６）、で構成される。ＳＡＥ−ＧＷ、ＳＧＳＮ又はＲＮＣに位置するＦＡの場合にも同様のアーキテクチャーが使用される。新たな接続が確立されるとき、フロー分類エンティティは、利用可能なＩＤ（ＩＭＳＩ、ＥＰＣベアラＩＤ、ＲＡＢ ＩＤ、ＰＤＰコンテキスト、等）に基づいてそれを識別し、そしてそれがＴＣＰを使用してデータ転送を行うかチェックする。そうである場合には、凍結管理エンティティが、適用される方針をチェックする（ＭＭＥ、ＲＲＭ及びＮｅｔＡｃｔから受け取られるユーザプロフィール、ＱｏＳパラメータ及び構成に基づいて）。接続をＦＡにより管理すべき場合には、接続の状態が凍結管理エンティティにより通常へセットされる（この状態は、ローカルの意味しか持たず、即ちＴＣＰソースは、それに気付かない）。ＡＣＫ取り扱いエンティティは、接続のための専用ＡＣＫレジスタを生成し、そして最後のＡＣＫを接続のＡＣＫレジスタへコピー及び記憶し始める。

ＦＡがターンオンされる（ＦＡは、接続に対してアップリンク及びダウンリンク方向に別々にターンオンできる）ＴＣＰ接続のＡＣＫは、ＡＣＫ取り扱いエンティティによって取り扱われる（図７）。接続のどの方向に対して機能をターンオン／オフするか指定するのは、オペレータの方針次第である。しかしながら、これは、一貫した仕方で行われねばならず、例えば、ＦＡがハンドオーバーについてアクチベートされる場合には、当該ｅＮＢ／Ｉ−ＨＳＰＡ ＢＴＳの両方がＦＡをサポートしなければならない。ソースｅＮＢ／Ｉ−ＨＳＰＡ ＢＴＳは、ＦＡ機能をターンオンするが、ターゲットがそのようにしない場合には、凍結管理エンティティは、凍結トリガーが検出されたときにアクションをとってはならない（即ち、接続の状態を凍結にセットしてはならない）。第１のアクションとして、ＡＣＫをインターセプトすると、ＡＣＫは、接続のＡＣＫレジスタに記憶される（レジスタは、所与の接続に対して最新の、１つのＡＣＫのみを含む）。次いで、接続状態がチェックされる。状態が通常である場合には、ＡＣＫが戻され、即ち更なるアクションなしに転送される。状態が凍結である場合には、広告ウインドウをゼロにセットした状態で新たなＡＣＫが転送のために戻される。

凍結管理エンティティから関連コマンドが受信される場合に偽のＡＣＫを生成するために、記憶されたＡＣＫがコピーされる。コマンドが凍結であるときには、ＡＣＫ取り扱いエンティティは、記憶されたＡＣＫのコンテンツを使用してＺＷＡを伴う偽のＡＣＫを生成する。或いは又、記憶されたＡＣＫのコンテンツに基づいてＺＷＡを一度に送信するのではなく、凍結コマンドを受信した際に待機タイマーをスタートさせることができる。待機タイマーが時間切れする前に新たなＡＣＫが受信された場合には、その新たなＡＣＫがＺＷＡへ変換される。待機タイマーが時間切れするまでＡＣＫが受信されない場合には、最新の記憶されたＡＣＫが使用される。いずれにせよ、ＡＣＫのコンテンツは、広告ウインドウサイズ以外、変更されない。コマンドが凍結解除であるときには、ＡＣＫ取り扱いエンティティは、記憶されたＡＣＫのコピーを生成して、それを送信する。適度な時間内に凍結解除トリガーが検出されない場合を取り扱うために凍結管理エンティティにおいてガードタイマーが実施される。このタイマーが時間切れすると、凍結管理エンティティは、ＡＣＫのオリジナルコンテンツを保持するか又は広告ウインドウを小さな値（これは、最大セグメントサイズに少なくとも等しくなければならず、さもなければ、取るに足らないウインドウシンドローム回避のためにＴＣＰソースが新たなデータを送信することが許されない）にセットする指示と共に凍結解除コマンドを送信する。後者のオプションは、前者よりセキュアである。というのは、データのバーストを伴うシステムのオーバーランを一度に防止するからである。受信器における状況は、凍結中に変化し、従って、記憶されたＡＣＫに指定されたデータの量を収容できないことがあり、それ故、このオプションは、新たなデータパケットに対する応答として送信されるＡＣＫを経て、受信器が実際の広告ウインドウサイズを指定するようにさせる。或いは又、データ転送を再開するレートは、ソースにおいて高速再送信及び高速回復をトリガーする同じコンテンツの３重ＡＣＫを送信することにより下げることができる。高速回復中に、ソースのレートが下げられる（半分にされる）が、ＦＡが適用されない場合の低速スタートより依然良好である。

更に、ＦＡは、ソースがデータ転送を再開したかどうか観察するためにデータパケットを監視しなければならない。トラフィックがない場合には、保護タイマーが終了した後にＮＺＷＡを伴うＡＣＫが再送される。

トリガー検出／予想エンティティは、ＲＲＭから及びトランスポートネットワーク管理からデータを収集する。収集できるＲＲＭ測定値のリストは、信号対干渉及びノイズ比（ＳＩＮＲ）測定値、ＨＡＲＱ故障レポート、スケジューリング遅延、エアインターフェイススループット、エアインターフェイス負荷測定値、ＨＯ決定及びＡ３測定値を含むが、これに限定されない（図８）。ＦＡがｅＮＢ／Ｉ−ＨＳＰＡ ＢＴＳに位置する場合には、測定値が局所的に得られ、従って、ハードウェア又は他のプラットホーム特有の制約だけが、ＵＥにより報告される測定値を除いて、測定レポートの粒度及び頻度を制限し、ここで、粒度は、対応する規格（ＬＴＥの場合には、ＲＲＣ規格［３６．３３１］）により許された最大レポート周期性により制約される。ＳＡＥ−ＧＷ／ＧＧＳＮ又はＲＮＣに位置するＦＡは、エアインターフェイス状態については非常に僅かな情報しか収集できず、測定されたデータの粒度及び測定レポートの頻度は、トランスポートネットワークの容量及び予想／検出メカニズムのレイテンシーにより制限される。ＲＲＭ測定値は、エアインターフェイスの質低下を検出又は予想し、そしてハンドオーバー決定を予想又は検出するのに使用することができる。エアインターフェイスの質低下は、規定のスレッシュホールドを経て検出することができ、即ちスレッシュホールドを越えた場合には、検出メカニズムが凍結又は凍結解除トリガーを送信する。

考えられる実施形態では、適応性の、単純化できない一次のマルコフ連鎖を使用することができ、ここでは、状態の数が予め構成され、状態は、Ｅ−ＤＰＤＣＨチャンネルクオリティインターバル、例えば、ＳＩＮＲ又はブロックエラー率（ＢＬＥＲ）インターバルを表わす。測定値が得られると、予想アルゴリズムは、状態移行確率を更新することによりチャンネルの適否の学習をスタートする。チャンネルの質低下又は改善は、予想スレッシュホールドを適用することにより予想することができる。このアルゴリズムは、誤った予想の場合にはそれ自身で修正することができる。ハンドオーバーは、ＨＯ管理と通信するか（ｅＮＢ／Ｉ−ＨＳＰＡ ＢＴＳに位置するＦＡ）、又は関連ハンドオーバーコマンドを受信する（ＳＡＥ−ＧＷ／ＧＧＳＮに位置するＦＡ）ことにより、検出される一方、ハンドオーバーは、ＵＥにより送信された無線測定値から予想することができる。或いは又、Ａ３トリガーにより定義されたものより厳密なスレッシュホールドを使用することができる。低プライオリティ接続より上に高プライオリティ接続をプライオリティ付けするのにＦＡが使用されるときに、負荷情報、スケジューリング遅延及びスループットを使用することができる。

トランスポート関連測定値（遅延、インターフェイス利用、負荷、パケットドロップ、混雑レベル、等）は、ポイント対ポイントリンクの場合にはトランスポートインターフェイスから直接的に収集され、又はトランスポート管理エンティティから収集される（トランスポート測定値に対するトリガーの定義は、トランスポートリンクに対する直接的なインターフェイスの場合だけ実現可能であり、さもなければ、これらの測定値及びレポートは、決定における観点としてのみ使用されねばならない）。この解決策は、ＦＡトリガーをセットすべきときに状況を検出するため、利用可能な測定方法（例えば、Ｉｕｂを経て利用可能なフレームシーケンス番号及び遅延参照時間ベース測定値）、又は良く知られた技術（ネットワークエレメント間に送信される単一及び二重マークパケット、等）を使用しなければならない。検出／予想エンティティは、ＦＡをターンオンさせたフローについてのみ測定値を収集する。

ネットワークオペレータは、任意のＦＡ事象を定義することができるが、最も単純なものは、ハンドオーバー、無線状態の質低下、及びＵＥの短期プライオリティ付けである。検出／予想エンティティは、ＵＥに対するＦＡ事象を予想又は検出すると、凍結又は凍結解除トリガーを凍結管理エンティティへ送信し、これは、次いで、凍結事象ルールデータベースから行われるべき適切なアクションをルックアップする。このデータベースは、定義されたオペレータ方針、構成データ、及びユーザプロファイルに基づいて生成される。データベースは、凍結管理エンティティにより維持される。

テーブル１は、データベースの規範的レコードを示す。データベースは、ＲＲＣ及びＨＯ管理データに基づいて連続的に更新され、即ちＩＭＳＩは、ＢＴＳにおけるＵＥの接続／切断／ハンドオーバーに基づいてデータベースに追加／削除され、そしてＲＡＢ ＩＤは、データＲＡＢのアクチベーション／デアクチベーションに基づき追加／削除される。ＦＡがＩＭＳＩ又はＲＡＢ ＩＤについてイネーブルされない場合には、それがデータベースに含まれないか、又は適切なアクションが「ノー」アクションにセットされる。ある事象の場合にとられるべきアクションは、オペレータの方針に基づいてセットされる。例えば、特別なユーザのＴＣＰ接続は、ハンドオーバー及び無線カバレージ悪化の場合にはコールをドロップするのではなく凍結状態にセットされるが、短期プライオリティ付けによる凍結状態ではない。このように特別なユーザの接続を凍結することは、ユーザのための高いＱｏＳに貢献する。同様に、低プライオリティの接続は、高プライオリティ接続のための余地を残すためにそれをドロップするのではなく凍結状態にセットされる。凍結メカニズムのこの適用は、高及び低の両プライオリティのユーザがアクションの一部分を行う上で助けとなり、即ち高プライオリティユーザは、低プライオリティユーザの帯域巾を取得することができる一方、低プライオリティユーザは、凍結周期が延長されない場合にデータ転送を再開する機会を依然有する（完全にドロップされるのではなく）。又、ＵＥの異なるＲＡＢ ＩＤに対して異なるアクションをセットすることもできる。

テーブル１：凍結事象ルールデータベースの規範的レコード

凍結管理エンティティが、検出された［事象、ＩＭＳＩ］対についてデータベース内のレコードを見出さないか、又はそれに対応するエントリーが「ノーアクション」である場合には、そのエンティティがその事象を無視する。さもなければ、凍結／凍結解除コマンドをＡＣＫ取り扱いエンティティへ発行する。

ＦＡがハンドオーバーについてアクチベートされそしてＦＡがｅＮＢに位置する場合には、ソース及びターゲットｅＮＢにおけるＦＡは、適切な動作に要求されるデータを交換できねばならない。というのは、ソースｅＮＢに常駐するＦＡによってＺＷＡ（１つ又は複数）が送信されねばならず、一方、ターゲットｅＮＢに常駐するＦＡによってＮＺＷＡ（１つ又は複数）が送信されねばならないからである（図９）。従って、要求された凍結アクションでＵＥのハンドオーバーを設定する間に、ソースｅＮＢのＦＡは、ターゲットｅＮＢのＦＡに、ＵＥのフローに対してそれがＦＡ機能をサポートするかどうか尋ねなければならない。関連情報の交換は、メッセージのための新たな任意のＩＥ、即ち凍結要求ＩＥ、凍結イネーブルＩＥ及びＺＷＡ ＩＥを定義することにより、標準化されたハンドオーバーメッセージシーケンスを使用して、実施することができる。ＨＯ要求Ｘ２メッセージを送信するときに（ステップ１）、ソースｅＮＢは、ＨＯ中のＵＥのどのフローが凍結アクションを要求するか指示するために任意の凍結要求ＩＥを埋める（例えば、対応するフローＩＤを列挙することにより）。ターゲットｅＮＢは、凍結要求ＩＥのフローＩＤごとに、ターゲットｅＮＢのＦＡがその特定のフローに対する凍結アクションをサポートするかどうか指示する任意の凍結イネーブルＩＥを挿入することにより、ＨＯ要求Ａｃｋメッセージにおいて要求に応答する（ステップ２）。これは、ｅＮＢが異なるＦＡオプションで構成されたときでもシステムの一貫した動作を保証するために要求される。

ＵＥのＨＯ決定がなされる（例えば、チャンネルクオリティが悪いために早期に凍結トリガーがあった）ときにＵＥの１つ以上のフローが何らかの理由で既に凍結されていた場合には、ソースｅＮＢは、ＨＯ要求Ａｃｋメッセージを受信した後に対応フローのＮＺＷＡ（１つ又は複数）を送信することにより、ターゲットｅＮＢにより凍結がサポートされないＵＥの全ての凍結されたフローを凍結解除しなければならない（ステップ３）。既に凍結状態にあるフローに対してターゲットｅＮＢが凍結をサポートする場合には、ソースｅＮＢのＦＡは、ガードタイマーを停止し（ＨＯ中にガードタイマーの時間切れにより凍結解除を早目にトリガーするのを防止するために）、そしてステップ４を省略する（これらの既に凍結されたフローに対して送信する必要のある付加的なＺＷＡはない）。

凍結されるべきフローのセット（即ち、まだ凍結されておらず、ソース及びターゲットの両ｅＮＢにより凍結アクションがサポートされるフロー）が鎮静化された後に、ソースｅＮＢは、対応するＺＷＡをそれらの各々へ送信することにより（ハンドオーバー中のＵＥの）それらフローを凍結する（ステップ４）。次いで、ソースｅＮＢは、ＨＯコマンドをＵＥへ送信して、ＵＥがソースｅＮＢから離れるようにする（ステップ５）。ＵＬデータフローの場合には、ソースｅＮＢは、ＵＥがソースｅＮＢから完全に離れる前にエアインターフェイス上の考えられる再送信を促進するために、ＵＥへの（Ｎ）ＺＷＡ（１つ又は複数）の送信成功をＨＡＲＱプロセスで確認するまで、ＨＯコマンドメッセージをＵＥへ送信してはならない。

ＨＯコマンドが送信された後に、ソースｅＮＢ（より正確には、ソースｅＮＢに付属されるＦＡエンティティ）は、次のアクションを行う。即ち、ダウンリンクデータトラフィックの場合には、ＵＥの凍結されたフローに対応するＺＷＡ（１つ又は複数）をＳＮ状態転送メッセージのＺＷＡ ＩＥへ挿入することにより、それらをターゲットｅＮＢへ転送し（ステップ６）；アップリンクデータフローの場合には、ＺＷＡと共に行先から受信されたＡＣＫを通常のハンドオーバーデータ転送手順に基づいてターゲットｅＮＢへ転送し（ステップ７）；従って、ＳＮ状態転送メッセージを使用する必要はない。いずれの場合にも、ＮＺＷＡ（１つ又は複数）が生成されて、ＵＥのＴＣＰソースへ送信される（ＵＬデータフロー）か、或いはコアネットワーク又はインターネットに位置するＴＣＰソース（ファイルサーバー、ウェブサーバー、コンテンツサーバー）へ送信される（ＤＬデータフロー）ときに、ターゲットｅＮＢは、転送された最新のＺＷＡ（１つ又は複数）におけるＴＣＰシーケンス番号を使用してフローを後で（ステップ９ａ又は９ｂにおいて）凍結解除することができる。

イントラサイトＨＯのための任意の最適化として、前記Ｘ２メッセージに情報エレメントを挿入することによりＦＡ間でデータを交換することは省略される。というのは、ＨＯには１つのｅＮＢしか含まれず、凍結及び凍結解除の両アクションがこのｅＮＢにおける同じＦＡによって取り扱われるからである。

ダウンリンクデータトラフィックの場合、ＦＡにより送られるＺＷＡ（１つ又は複数）がＴＣＰソースに到達するのにある程度の時間がかかるので、ＴＣＰソースは、凍結トリガーが検出される前に受信器により送信された確認に対する応答として付加的なパケットを受信器へ平均時間で（即ち、ＵＥのフローを凍結するためＦＡがＺＷＡ（１つ又は複数）を既に送信した後に）依然送信することができる（図２も参照）。ＨＯコマンドがＵＥへ送られる前にこれらのデータパケットが到達する場合には、ＵＥのＴＣＰ受信器がそれらパケットのためのＡＣＫを依然送信する。これらの付加的なＡＣＫは、ソースｅＮＢのＦＡによりインターセプトされ、ＺＷＡへ変換され、そしてＴＣＰソースへ転送される。又、これらの付加的なＺＷＡは、その後のＳＮ状態転送メッセージに埋め込まれたＺＷＡＩＥとして、Ｘ２インターフェイスを経てターゲットｅＮＢのＦＡへ搬送されねばならない。これは、ターゲットｅＮＢのＦＡが、最新の確認されたシーケンス番号をもつＮＺＷＡを経て凍結解除を実行し（ステップ９ａ又は９ｂ）、解決策の性能を改善できるようにする。

アップリンクデータトラフィックの場合には、コアネットワーク又はインターネットに位置する受信器は、ＺＷＡを受信する前にソース（ＵＥ）により送られたデータパケットに対する応答としてＡＣＫを依然送信する。それらＡＣＫは、ステップ８ａにおいてＵＥの付属が成功した後に、又はステップ８ｂにおいて経路スイッチ要求Ａｃｋを受信した後に、ＴＣＰソースを凍結解除するのに使用される。後者のケースでは、ソースｅＮＢから受信されたＺＷＡを伴うＡＣＫは、経路スイッチ要求Ａｃｋが受信されるまで、ターゲットｅＮＢによりエアを経てＵＥへ不変のまま転送される。凍結解除の後に、ＺＷＡと共にソースｅＮＢから受信されたＡＣＫは、ターゲットｅＮＢによりＮＺＷＡと共にＵＥへ転送される。

ターゲットｅＮＢが凍結解除トリガーに遭遇するとき（例えば、ステップ８ａにおけるＵＥ付属成功、又はステップ８ｂにおける経路スイッチ要求Ａｃｋの受信）、ターゲットｅＮＢは、ＮＺＷＡを送信することによってＵＥのフローを凍結解除する（ステップ９ａ又は９ｂ）。又、ＮＺＷＡは、ＨＯ決定の時間に既に凍結されていたフローにも送られ、即ちＨＯの完了は、他の全てのトリガーに対する最終的な凍結解除トリガーとして働く。

ソースｅＮＢのＦＡからターゲットｅＮＢのＦＡへデータを転送するのに使用される任意の情報エレメント（凍結要求ＩＥ、凍結イネーブルＩＥ、ＺＷＡ ＩＥ）は、マルチベンダー環境においてｅＮＢ間での凍結アクションの相互運用性を与えるために標準化されねばならない。この標準化は、これらのＩＥに気付かないレガシーｅＮＢがそれらを受信時に無視すべき（応答も送信しないしエラー手順もトリガーしない）形態で行うことができる。凍結アクションをサポートするｅＮＢは、凍結関連ＩＥに対する応答の欠如を否定指示として処理しなければならず、即ちターゲットｅＮＢにおいて凍結が全くイネーブルされなかったかのように処理し、そしてそれに応じて動作しなければならない（既に凍結されたフローに対してＮＺＷＡを送信することにより凍結をキャンセルし、ＺＷＡ ＩＥを送信しない）。

凍結メカニズムの実施をＬＴＥに焦点を当てて説明したが、この実施は、Ｉ−ＨＳＰＡ又はＷＣＤＭＡ／ＨＳＰＡシステムについても同様に実現することができる。ＨＯでトリガーされる凍結の場合を特定例として詳細に述べた。他のトリガー（チャンネル質低下、短期プライオリティ付け、等）による凍結メカニズムの動作は、ネットワークノード間の通信を要求せず、このケースから容易に派生させることができる。

ＴＣＰ送信者がＵＥである（即ち、ＵＥの観点からＴＣＰトラフィックがアップリンクである）場合には、ＦＡの動作は、上述したものと全く同じであり、ＺＷＡ及びＮＺＷＡだけがＵＥへ送信される（図２に基づく）。アップリンクＴＣＰトラフィックでＵＥのＨＯがある場合には、ソースｅＮＢのＦＡが、ダウンリンクＴＣＰトラフィックでのＵＥの場合と同様に働く。ＵＥの場合を若干容易にする唯一の相違は、ソースｅＮＢが、Ｘ２を経てのその後のＳＮ状態転送メッセージにおいて付加的なＺＷＡ（１つ又は複数）をターゲットｅＮＢへ転送しなくてもよいことである。というのは、これらのパケットは、標準的なＸ２ハンドオーバートラフィック転送の一部分としてターゲットｅＮＢへいずれ転送されるからである。最後のＺＷＡをＳＮ状態転送メッセージにおいてターゲットｅＮＢへ送信すること（ステップ６）は、もちろん、好都合である。

ここに提案するＦＡ機能の性能は、ユーザがファイル転送プロトコル（ＦＴＰ）でファイルダウンロードを実行する場合のシミュレーションで評価された。ＬＴＥハンドオーバーによりトリガーされた凍結の結果は、ネットワーク非対称の場合に（即ち、ＵＥがダウンリンクには充分なカバレージを有するが、アップリンクには有していないとき）ＴＣＰ性能が凍結で効率的に改善できることを示している。凍結機能の性能を評価するのに使用された尺度は、ハンドオーバーコマンドが送信された直後に１０２４ｋバイトのデータをダウンロードするのに必要な時間である。２つの異なるトラフィック設定がシミュレーションされ、異なる数のユーザと共にケース１及びケース２で表され、各ユーザは、シミュレーション中に１つのアクティブなＦＴＰ接続を有する。ケース１及びケース２には各々５０人及び２０人のＦＴＰユーザがおり、その全員が凍結メカニズムを受け、更に、このＦＴＰユーザに対して、凍結メカニズムを受けない２００人のＶｏＩＰユーザ及び９０人のＨＴＴＰユーザがいた。これらのユーザは、７つのｅＮＢ間に均一に分散され（ｅＮＢ当たり１セル）、そしてランダム中間点移動モデルに従って３ｋｍ／ｈの速度で移動した。ケース１及びケース２の両方において、ＨＯブレーク時間（即ち、ＵＲがソースｅＮＢから離れるときと、ターゲットｅＮＢに付帯するときとの間の時間）について３つの時間インターバル（３０、６０及び１００ｍｓ）がシミュレーションされた。図１０は、複数の時間切れにより生じる長いアイドル時間を排除することで、ＦＡ機能が、１０２４ｋバイトのデータをダウンロードするのに必要な時間を著しく短縮することを示す。利得は、ケース１で約５０ｓ、そしてケース２で１０ｓより大きく、この時間での利得は、ユーザのＱｏＥを著しく増加し、そしてユーザが不満足なサービスのために別の移動ネットワークオペレータへスイッチングするのを防止するのに充分なものである。

図１１は、本発明の一実施形態による中間ネットワークノードの一例を示す図である。図１１によれば、本発明の一実施形態により、上述したように、凍結エージェントとしてみなすことができるか又は凍結エージェントを備えた中間ネットワークノード１１０は、トランシーバ１１１を備えている。このトランシーバは、ＵＥ、コンテンツサーバー又は他のベースステーション、等と通信することができ、即ちメッセージを送信及び受信することができる。トランシーバ１１１は、更に、例えば、ＦＴＰサーバーのようなコンテンツサーバーと、ユーザ装置との間の接続のクオリティ尺度を得るようにされる。凍結エージェント１１０は、更に、クオリティ尺度が所定の条件を満足するか又は今度の時間周期内に所定の条件を満足するかどうか検出し及び／又は予想する検出／予想ユニット１１２を備えている。この検出／予想ユニット１１２は、クオリティ尺度が所定の条件を満足しない場合に、例えば、コンテンツサーバーとユーザ装置との間のＴＣＰ接続である接続を凍結するためのトリガーとして確認メッセージをコンポーズすることのできる凍結ユニット１１３に接続される。確認メッセージは、トランシーバ１１１を経てコンテンツサーバーへ送信される。更に、検出／予想ユニット１１２は、接続が凍結された後に、クオリティ尺度が所定の条件を再び満足するかどうか検出する。所定の条件を満足することが検出された場合には、凍結ユニット１１３は、トランシーバ１１１を経て接続の凍結解除モードをトリガーする別の確認メッセージを送信することでＴＣＰ接続を再開させる。

凍結エージェントは、更に、タイマー（図示せず）を備え、タイマーが時間切れしたときに、凍結ユニットは、トランシーバ１１１を経てＴＣＰ接続を再開させる。

コンテンツサーバーとユーザ装置との間の接続は、サーバーからユーザ装置へコンテンツをダウンロードするためのダウンリンクであるか、又はユーザ装置からサーバーへコンテンツをアップロードするためのアップリンクであることに注意されたい。更に、ユーザ装置と別のリモートノードとの接続もあり、例えば、ｅ−メールアタッチメントのようなコンテンツをユーザ装置からリモートノードへアップロードすることができる。

凍結エージェントの以上の規範的な説明において、本発明の原理を理解する上で関連のあるユニットだけが、機能ブロックを使用して説明された。凍結エージェントは、更に、その各々の動作に必要な更に別のユニットを含む。しかしながら、それらユニットの説明は、本明細書では省略される。装置の機能的ブロックの配列は、本発明を限定すると解釈されるものではなく、機能は、１つのブロックで遂行されてもよいし、サブブロックへと更に分割されてもよい。

上述した本発明によれば、エアインターフェイスカバレージの問題、過渡的エアインターフェイス又はトランスポート混雑が検出され又は予想されるとき、ハンドオーバーの決定がシステムによりなされるとき、又はサービスの権利レベルを保証するためにプライオリティの高いユーザをプライオリティの低いユーザより高くプライオリティ付けすることが要求されるときに、ＴＣＰ接続を凍結する解決策が提案される。凍結されるべく選択されたＴＣＰフローは、システムが安全オペレーションの可能性を確かめた後に再開することが許される。本発明は、無線アクセスノード（ｅＮＢ、Ｉ−ＨＳＰＡ ＢＴＳ、ＳＡＥ−ＧＷ、ＲＮＣ）に位置する機能であって、ユーザプレーン接続の状態（無線チャンネルクオリティ、トランスポート混雑、ハンドオーバー、等）、セルの全負荷、又は他の当該クオリティ尺度に従い、且つ通常のＡＣＫメッセージを使用して選択されたＴＣＰ接続を凍結する機能を提供するもので、即ちこの解決策は、ＴＣＰソースを凍結するために専用のＩＣＭＰ又は他のコマンドの使用を要求するものではない。

前記説明では次のような省略形が使用される。

上述した本発明の目的上、次のことに注意されたい。
−おそらくソフトウェアコード部分として実施されそして（デバイス、装置及び／又はそのモジュールの例として、或いは装置及び／又はそのモジュールを含むエンティティの例として）無線アクセスノード又はユーザ装置にプロセッサを使用して実行される方法ステップは、ソフトウェアコード独立であり、そして方法ステップにより定義された機能が保存される限り、既知の又は将来開発されるプログラミング言語を使用して指定することができる。
−一般的に、方法ステップは、実施形態及び具現化される機能に関するその変形形態の考え方を変えることなくソフトウェアとして又はハードウェアにより具現化するのに適している。

−方法ステップ、及び／又は上述した装置又はそのモジュールにおいておそらくハードウェアコンポーネントとして具現化されるデバイス、ユニット又は手段（例えば、上述した実施形態により装置の機能を実行するデバイス）は、ハードウェア独立であり、そして既知の又は将来開発されるハードウェア技術、或いはそれらの混成、例えば、ＭＯＳ（金属酸化物半導体）、ＣＭＯＳ（相補的ＭＯＳ）、ＢｉＭＯＳ（バイポーラＭＯＳ）、ＢｉＣＭＯＳ（バイポーラＣＭＯＳ）、ＥＣＬ（エミッタ結合ロジック）、ＴＴＬ（トランジスタ・トランジスタロジック）、等、を使用して、又、例えば、ＡＳＩＣ（特定用途向けＩＣ（集積回路））コンポーネント、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）コンポーネント、ＣＰＬＤ（コンプレックスプログラマブルロジックデバイス）コンポーネント、又はＤＳＰ（デジタルシグナルプロセッサ）コンポーネントを使用して具現化することができる。

−デバイス、ユニット又は手段（例えば、上述した装置及びユーザ装置、又はそれらの各ユニット／手段のいずれか）は、個々のデバイス、ユニット又は手段として具現化できるが、デバイス、ユニット又は手段の機能が保存される限り、それらがシステム全体にわたり分散形態で具現化されることを除外するものではない。
−装置は、半導体チップ、チップセット、或いはそのようなチップ又はチップセットを含む（ハードウェア）モジュールにより表されるが、これは、装置又はモジュールの機能が、ハードウェアで具現化されるのではなく、プロセッサで実行するための／実行される実行可能なソフトウェアコード部分を含むコンピュータプログラム又はコンピュータプログラム製品のような（ソフトウェア）モジュールのソフトウェアとして具現化される可能性を除外するものではない。
−デバイスは、例えば、互いに機能的に協働するか、又は互いに機能的に独立しているが同じデバイスハウジング内にあるかに関わらず、装置として又は２つ以上の装置のアッセンブリとしてみなされる。

一般的に、上述した態様に基づく各機能的ブロック又は要素は、各部分のここに述べる機能を遂行するようにされるだけであれば、各々、ハードウェア及び／又はソフトウェアの既知の手段により具現化できることに注意されたい。上述した方法ステップは、個々の機能的ブロックにおいて又は個々のデバイスにより実現でき、或いは１つ以上の方法ステップは、単一の機能的ブロックにおいて又は単一のデバイスにより実現できる。

一般的に、方法ステップは、本発明の考え方を変えることなくソフトウェアとして又はハードウェアにより具現化するのに適している。デバイス及び手段は、個々のデバイスとして具現化できるが、これは、デバイスの機能が保存される限り、システム全体にわたり分散形態でそれらが具現化されることを除外するものではない。そのような原理及び同様の原理は、当業者に明らかであると考えられる。

本説明の意味におけるソフトウェアは、コード手段又は部分より成るソフトウェアコード、或いは各機能を遂行するためのコンピュータプログラム又はコンピュータプログラム製品、並びに各データ構造又はコード手段／部分が記憶されたコンピュータ読み取り可能な（記憶）媒体のような有形の媒体において実施されるか、又は潜在的に処理中に信号又はチップにおいて実施されるソフトウェア（或いはコンピュータプログラム又はコンピュータプログラム製品）を含む。

上述した実施形態、並びに一般的及び特定の例は、例示の目的で与えられたもので、本発明をそれに限定するものではないことに注意されたい。むしろ、特許請求の範囲内に包含される全ての修正や変更が網羅されることが意図される。

１１０：中間ネットワークノード
１１１：トランシーバ
１１２：検出／予想ユニット
１１３：凍結ユニット

Claims (21)

1. コンテンツサーバーとユーザ装置との間の接続のクオリティ尺度を中間ネットワークノードにおいて得、
   前記クオリティ尺度が所定の条件を満足するかどうか中間ネットワークノードにおいて検出し、
   前記クオリティ尺度が所定の条件を満足しない場合には、コンテンツサーバーとユーザ装置との間の接続の凍結モードをトリガーする確認メッセージを中間ネットワークノードにより送信する、
   ことを含む方法。
2. コンテンツサーバーとユーザ装置との間の前記接続は、サーバーからユーザ装置へコンテンツをダウンロードするためのダウンリンクであり、そして前記確認メッセージは、コンテンツサーバーへ送信される、請求項１に記載の方法。
3. コンテンツサーバーとユーザ装置との間の前記接続は、ユーザ装置からサーバーへコンテンツをアップロードするためのアップリンクであり、そして前記確認メッセージは、ユーザ装置へ送信される、請求項１に記載の方法。
4. 前記検出は、前記クオリティ尺度が今度の所定時間周期内に所定の条件を満足するかどうか、得られたクオリティ尺度に基づいて、中間ネットワークノードにおいて予想することを含む、請求項１から３のいずれか１つに記載の方法。
5. 前記接続が凍結された後に、前記クオリティ尺度が所定の条件を満足するかどうか中間ネットワークノードにおいて検出し、
   前記クオリティ尺度が所定の条件を満足する場合には、別の確認メッセージをコンテンツサーバー又はユーザ装置へ送信して、前記接続の凍結解除モードをトリガーする、
   ことを更に含む、請求項１から４のいずれか１つに記載の方法。
6. 所定の時間周期が経過した後に別の確認メッセージをコンテンツサーバー又はユーザ装置へ送信して、前記接続の凍結解除モードをトリガーすることを更に含む、請求項１から５のいずれか１つに記載の方法。
7. 前記クオリティ尺度は、無線チャンネルのクオリティ、セルの全負荷、エアインターフェイスカバレージ、過渡的なエアインターフェイス又はトランスポート混雑、又はハンドオーバー決定、或いは高プライオリティユーザのプライオリティ付けに関連している、請求項１から６のいずれか１つに記載の方法。
8. 前記接続は、送信コントロールプロトコルＴＣＰ接続である、請求項１から７のいずれか１つに記載の方法。
9. 前記中間ネットワークノードは、無線アクセスノードである、請求項１から８のいずれか１つに記載の方法。
10. コンテンツサーバーとユーザ装置との間の接続のクオリティ尺度を得るように構成された取得ユニットと、
    前記クオリティ尺度が所定の条件を満足するかどうか検出するように構成された検出ユニットと、
    前記クオリティ尺度が所定の条件を満足しない場合には、コンテンツサーバーとユーザ装置との間の接続の凍結モードをトリガーする確認メッセージをコンポーズするように構成された凍結ユニットと、
    前記確認メッセージを転送するように構成されたトランシーバと、
    を備えた装置。
11. コンテンツサーバーとユーザ装置との間の前記接続は、サーバーからユーザ装置へコンテンツをダウンロードするためのダウンリンクであり、そして前記確認メッセージは、コンテンツサーバーへ送信される、請求項１０に記載の装置。
12. コンテンツサーバーとユーザ装置との間の前記接続は、ユーザ装置からサーバーへコンテンツをアップロードするためのアップリンクであり、そして前記確認メッセージは、ユーザ装置へ送信される、請求項１０に記載の装置。
13. 前記検出ユニットは、更に、前記クオリティ尺度が今度の所定時間周期内に所定の条件を満足するかどうか、得られたクオリティ尺度に基づいて、予想するように構成される、請求項１０から１２のいずれか１つに記載の装置。
14. 前記検出ユニットは、更に、前記接続が凍結された後に、前記クオリティ尺度が所定の条件を満足するかどうか検出するように構成され、そして
    前記クオリティ尺度が所定の条件を満足する場合に、前記凍結ユニットは、前記接続の凍結解除モードをトリガーする別の確認メッセージをコンポーズするように構成される、請求項１０から１３のいずれか１つに記載の装置。
15. 前記凍結ユニットは、更に、所定の時間周期が経過した後に、前記接続の凍結解除モードをトリガーする別の確認メッセージをコンポーズするように構成され、請求項１０から１４のいずれか１つに記載の装置。
16. 前記クオリティ尺度は、無線チャンネルのクオリティ、セルの全負荷、エアインターフェイスカバレージ、過渡的なエアインターフェイス又はトランスポート混雑、又はハンドオーバー決定、或いは高プライオリティユーザのプライオリティ付けに関連している、請求項１０から１５のいずれか１つに記載の装置。
17. 前記接続は、送信コントロールプロトコルＴＣＰ接続である、請求項１０から１６のいずれか１つに記載の装置。
18. 処理装置のためのプログラムを備え、そのプログラムが処理装置で実行されるとき請求項１から９のいずれか１項の段階を遂行するためのソフトウェアコード部分を含む、コンピュータプログラム製品。
19. 前記ソフトウェアコード部分が記憶されたコンピュータ読み取り可能な媒体を備えた、請求項１８に記載のコンピュータプログラム製品。
20. 前記処理装置の内部メモリに前記プログラムを直接ロードできる、請求項１８に記載のコンピュータプログラム製品。
21. 前記処理装置は、無線アクセスノードである、請求項１８又は２０に記載のコンピュータプログラム製品。

Images