(57)【特許請求の範囲】
【請求項１】
アプリケーションセッションに関連するデータフローを検出するために、ネットワークノードにおいて、通信システムの端末装置に関連するデータトラフィックを監視するステップと、
前記ネットワークノードにおいて、前記アプリケーションセッションに関して前記端末装置に提供されるべき要求される体感品質QoEレベルを定義するリソース要件情報を定めるステップと、
利用可能なネットワークリソースの状態に関する情報を取得するために、前記ネットワークノードにおいてネットワーク状態を監視するステップと、
前記ネットワークノードにおいて、データフロー経路に輻輳が存在するかどうかを検査し、存在する場合、前記輻輳をローカライズし、同じリソースに対して競合する一連のアプリケーションを検出するステップと、
前記ネットワークノードにおいて、前記アプリケーションセッションに関して前記端末装置で体感する体感品質QoEに関する情報を取得するための体感品質QoE測定を実行するステップと、
前記体感品質QoE測定および前記利用可能なネットワークリソースの状態に基づいて、前記リソース要件を満たすために前記アプリケーションセッションの前記体感品質QoEを強化するために、ネットワークノードにおいて１つ又は複数のアクションを実行するステップと
を含むことを特徴とする方法。
【請求項２】
前記方法は、前記１つ又は複数のアクションが、トラフィック管理/ QoE強化および/
またはリソース再配布アクションの体感品質QoE管理アクションを含む、
請求項１に記載の方法。
【請求項３】
前記方法は、既存のネットワークメカニズムが前記アプリケーションセッションの体感品質QoEターゲットに対して対抗することを防止するために、前記ネットワークノードにおいて体感品質QoE管理を実行するステップを含む、
請求項１に記載の方法。
【請求項４】
前記方法は、過負荷または増加する負荷傾向が検出された場合に、TCPソースによって生成された負荷を低減することによって、前記ネットワークノードにおいて能動的な負荷調整を実行するステップを含む、
請求項１に記載の方法。
【請求項５】
前記方法は、前記ネットワークノードにおいて、TCPセグメントペーシングを、体感品質QoE強化アクションによって定義されたシェーピングレートに調整することによって、TCPスループットおよび送信機動作を最適化するステップを含む、
請求項１に記載の方法。
【請求項６】
前記方法は、前記ネットワークノードにおいて、無線リソースの負荷を平衡させるか、またはトランスポートネットワーク上の負荷を低減するために、端末装置を代替無線レイヤまたは代替無線アクセス技術にリダイレクトすることによってトラフィックステアリングおよび/またはWi-Fiオフロードを実行するステップを含む、
請求項１に記載の方法。
【請求項７】
前記方法は、前記ネットワークノードにおいて、所定の輻輳基準が満たされた場合に、前記アプリケーションセッションの接続終了または接続スロットリングを実行するステップを含む、
請求項１に記載の方法。
【請求項８】
前記方法は、前記ネットワークノードにおいて、データフローまたはアプリケーションセッションを別のものよりも優先するによって、体感品質QoE強化を実行するステップを含む、
請求項１に記載の方法。
【請求項９】
前記方法は、前記ネットワークノードにおいて、前記アプリケーションセッションの前記リソース要件が満たされていない場合、無線ベアラを変更するためのデフォルトのQCI / SPI変更アクションを開始するステップを含む、
請求項１に記載の方法。
【請求項１０】
前記方法は、前記ネットワークノードにおいて、体感品質QoE強化アクションと並行してデフォルトのQCI / SPI変更アクションを開始するステップを含む、
請求項９に記載の方法。
【請求項１１】
少なくとも１つのプロセッサと、
コンピュータプログラムコードを含む少なくとも１つのメモリと
を含み、
前記少なくとも１つのメモリおよび前記コンピュータプログラムコードは、前記少なくとも１つのプロセッサによって、前記装置に
アプリケーションセッションに関連するデータフローを検出するために、通信システムの端末装置に関するデータトラフィックを監視するステップと、
前記端末装置において、データフロー経路に輻輳が存在するかどうかを検査し、存在する場合、前記輻輳をローカライズし、同じリソースに対して競合する一連のアプリケーションを検出するステップと、
前記アプリケーションセッションに関して前記端末装置に提供されるべき要求される体感品質QoEレベルを定義するリソース要件情報を定めるステップと、
前記利用可能なネットワークリソースの状態に関する情報を取得するために、前記装置にネットワーク状態を監視するステップと、
体感品質QoE測定を実行して、前記アプリケーションセッションに関して前記端末装置で体感した体感品質QoEに関する情報を取得するステップと、
前記体感品質QoE測定および前記利用可能なネットワークリソースの状態に基づいて、前記リソース要件を満たすために前記アプリケーションセッションの前記体感品質QoEを強化するために１つ又は複数のアクションを実行するステップと
を実行させることを特徴とする装置。
【請求項１２】
前記１つ又は複数のアクションは、トラフィック管理/ QoE強化および/またはリソース再配布アクションの体感品質QoE管理アクションを含む、
請求項１１に記載の装置。
【請求項１３】
前記少なくとも１つのメモリおよび前記コンピュータプログラムコードは、前記少なくとも１つのプロセッサを用いて、前記装置に、既存のネットワークメカニズムが前記アプリケーションセッションの体感品質QoEターゲットに対して対抗することを防止するために、体感品質QoE管理を実行するステップを実行させる、
請求項１１に記載の装置。
【請求項１４】
少なくとも１つのプロセッサによって前記装置に、過負荷または増加する負荷傾向が検出された場合に、TCPソースによって生成される負荷を低減することによって、能動的な負荷調整を、実行させるように構成された、
請求項１１に記載の装置。
【請求項１５】
前記少なくとも１つのメモリおよび前記コンピュータプログラムコードは、前記少なくとも１つのプロセッサによって、前記装置に、TCPセグメントペーシングを、体感品質QoE強化アクションによって定義されたシェーピングレートに調整することによって、TCPスループットおよび送信機動作を最適化させるように構成された、
請求項１１に記載の装置。
【請求項１６】
前記少なくとも１つのメモリおよび前記コンピュータプログラムコードは、無線リソースの負荷を平衡させるか、またはトランスポートネットワーク上の負荷を低減するために、端末装置を代替無線レイヤまたは代替無線アクセス技術にリダイレクトすることによって、前記装置にトラフィックステアリングおよび/またはWi-Fiオフロードを実行させるように構成された、
請求項１１に記載の装置。
【請求項１７】
前記少なくとも1つのプロセッサは、所定の輻輳基準が満たされた場合に、前記アプリケーションセッションの接続終了または接続スロットリングを前記装置に実行させる、
請求項１１に記載の装置。
【請求項１８】
前記少なくとも１つのメモリおよび前記コンピュータプログラムコードは、前記少なくとも１つのプロセッサによって、データフローまたはアプリケーションセッションを別のものよりも優先させることによって、前記装置に体感品質QoE強化を実行させるように構成された、
請求項１１に記載の装置。
【請求項１９】
前記少なくとも１つのメモリおよび前記コンピュータプログラムコードは、前記少なくとも１つのプロセッサによって、前記装置に前記アプリケーションセッションのリソース要件が満たされていない場合、無線ベアラを変更するためのデフォルトのQCI / SPI変更アクションを開始させる、
請求項１１に記載の装置。
【請求項２０】
前記少なくとも１つのメモリおよび前記コンピュータプログラムコードは、前記装置に、体感品質QoE強化アクションと並行してデフォルトQCI / SPI変更動作を開始させるように構成された、
請求項１９に記載の装置。
【請求項２１】
前記少なくとも１つのメモリおよび前記コンピュータプログラムコードは、前記少なくとも１つのプロセッサによって、前記装置に、専用アプリケーション固有のキーパフォーマンスインジケータを使用して、体感品質QoEを測定させるように構成される、
請求項１１に記載の装置。
【請求項２２】
前記少なくとも１つのメモリおよび前記コンピュータプログラムコードは、前記少なくとも１つのプロセッサを用いて、前記装置に、各アプリケーションの個々のニーズ、ユーザ/アプリケーションポリシーおよびポリシー、および課金制御/サービス品質ルールおよびネットワーク状況に基づいて、アプリケーションセッションに関して端末装置に提供される必要な体感品質QoEレベルを定義させる、
請求項１１に記載の装置。
【請求項２３】
アプリケーションセッションに関連するデータフローを検出するために、通信システムの端末装置に関連するデータトラフィックを監視するように構成されたフロー検出器と、  前記アプリケーションセッションに関して前記端末装置に提供されるべき要求された体感品質QoEレベルを規定するリソース要件情報を導出するように構成された要件生成器と、
利用可能なネットワークリソースの状態に関する情報を取得するために、ネットワーク状態を監視するように構成された回路と、
前記端末装置において、データフロー経路に輻輳が存在するかどうかを検査し、存在する場合、前記輻輳をローカライズし、同じリソースに対して競合する一連のアプリケーションを検出するように構成されたデータフロー検出器と、
前記アプリケーションセッションに関する端末装置で体感された体感品質QoEに関する情報を取得するために、QoE測定を実行するように構成された品質計と、
前記体感品質QoE測定および前記利用可能なネットワークリソースの状態に基づいて、前記リソース要件を満たすために前記アプリケーションセッションの前記体感品質QoEを強化するために１つ又は複数のアクションを実行するように構成されたリソースマネージャと
を含む装置。
【請求項２４】
コンピュータによって読み取り可能な配布媒体上に具現化され、装置にロードされると、請求項１から１０のいずれか１項に記載の方法を実行するプログラム命令を含むコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信に関する。
【背景技術】
【０００２】
QoE（Quality of Experience）は、ユーザーの立場から提供されるサービスの全体的な価値の尺度である。 QoEは、妥当性、柔軟性、モビリティ、セキュリティ、コスト、パーソナライズおよび/または選択など、ユーザー全体の価値に貢献するさまざまな要因を考慮している。
【発明の概要】
【課題を解決するための手段】
【０００３】
１つ実施形態によれば、独立請求項の主題が提供される。複数の実施形態は従属請求項に規定されている。
【０００４】
実装の1つ又は複数の例は、添付の図面および以下の説明でより詳細に説明される。 他の特徴は、説明および図面、ならびに請求項から明らかになるであろう。
【０００５】
以下、添付の図面を参照して本発明を好ましい実施形態により詳細に説明する。
【図面の簡単な説明】
【０００６】
【図１】本発明の実施形態が適用される無線通信システムを示す図である。
【図２】本発明の一実施形態による中央QoEオーケストレーションの手順のシグナリング図である。
【図３】集中型QoE管理と強化（enforcement）の展開とインターフェースを示す図である。
【図４】本発明の一実施形態による中央QoEオーケストレーションのためのプロセスを示す図である。
【図５】輻輳状態に応じたアクションのオーケストレーションと調和を示す図である。
【図６】中央QoEオーケストレーターと別のネットワークノードとの統合および論理インターフェースを示す。
【図７】フロー/アプリケーション固有の動作を示す図である。
【図８】QoE強化と組み合わせたTCP最適化および過負荷管理を示す図である。
【図９】動的QoS管理を示す図である。
【図１０】TCP最適化を示す図である。
【図１１】RFSPインデックスに基づくアクティブモードトラフィックステアリングを示す図である。
【図１２】アクションのオーケストレーションと調和を示す図である。
【図１３】TCP過負荷管理の有効化と無効化を示す図である。
【図１４】アイドルモードのTS / Wi-Fiオフロードによる調和を示す図である。
【図１５】QoS / QoE管理のための第三者エンティティとPCRF / PCEFとの論理的統合を示す図である。
【図１６】本発明の一実施形態による装置のブロック図である。
【図１７】本発明の一実施形態による装置のブロック図である。
【発明を実施するための形態】
【０００７】
以下の実施形態は例示的なものである。 明細書は、いくつかの場所における「1つの」、「1つの」、又は「いくつかの」実施形態に言及することができるが、必ずしもそのような各参照が同じ実施形態にあることを意味するものではなく、 単一の実施形態にのみ適用される。 異なる実施形態の単一の特徴を組み合わせて、他の実施形態を提供することもできる。 さらに、「含む（comprising）」および「含む（including）」という言葉は、記載された実施形態を記載された特徴のみからなるものに限定するものではなく、そのような実施形態が具体的に言及されていない特徴/構造を含み得る。
【０００８】
図1は、本発明の実施形態を適用することができる無線通信のシナリオを示す。図1を参照すると、セルラー通信システムは、決定された地理的領域において無線カバレージを提供するように配置された基地局を含む無線アクセスネットワークを備えることができる。基地局は、例えば、数平方マイルを越えた比較的広い領域にわたる無線カバレッジを端末装置（UE）106に提供するように構成されたマクロセル基地局（eNB）102を含むことができる。改善された容量が必要とされる密集した占有されたホットスポットでは、小エリアセル基地局（eNB）100を展開して、端末装置（UE）104に高データレートサービスを提供することができる。そのような小面積セル基地局は、マイクロセル基地局、ピコセル基地局、またはフェムトセル基地局と呼ばれてもよい。小エリアセル基地局は、典型的には、マクロ基地局102よりも著しく小さいカバレージエリアを有する。セルラー通信システムは、第3世代パートナーシッププロジェクト（3GPP）LTE（long-term evolution）またはその進化バージョンの仕様に従って動作することができる。
【０００９】
モバイル事業者は、インターネットベースのデータ駆動型OTTアプリケーション（マルチメディア、ソーシャルネットワーキングサイト、eコマース、Webブラウジングなど）の利用が増加するにつれて、ネイティブおよびOTTアプリケーション/サービスにアクセスしているユーザーに対して、優れた品質（QoE）を提供する。ネットワーク側のリソースは、ユーザーのモビリティ、アプリケーションおよびトラフィック需要、およびネットワーク側の輻輳（無線アクセスおよび/またはモバイルバックホールに関する）を含むあらゆる条件の下で、必ずしも良好なQoEを提供できない。輻輳のもとで、アプリケーションは同じリソースを競合する。ゆえに、可能な限り最良のQoE全体を提供するためには、能動的なトラフィック管理および強化アクション（例えば、帯域幅制限、ベアラ優先順位付け、スケジューリングなど）が必要である。したがって、アプリケーションとQoEの検出と監視、輻輳の検出とローカライズ、非効率的なリソース割り当てや輻輳による劣化の防止/解決、および選択されたアクションの実行/実行のためのネットワーク機能が必要である。3G、HSPAおよび/またはLTEなどの3GPPモバイルシステムでは、ポリシーおよび課金制御（PCC）フレームワークは、ユーザーまたはアプリケーションの差別化およびトラフィック管理のための標準化されたソリューションである。しかし、PCCフレームワーク（PCRF / PCEFによって管理されるPCC / QoSルールを含む）および関与する機能は、アプリケーションのQoEを管理する能力を有していない。PCCフレームワークは、輻輳の場合にアプリケーションまたはベアラにリソースを割り当てる方法を直接定義または管理しない。PCCルールは、輻輳時にフローが同じリソースに対して競合していることを考慮せずに、各ユーザ/ベアラ/アプリケーション/フローごとに個別に定義され、実施される。これは、一部のアプリケーションが過剰供給され、良好なQoEに必要なリソースよりも多くのリソースを使用するという顧客満足の観点から、非効率的なシステム利用につながる可能性がある。
【００１０】
ここで、図2を参照しながら、中央QoEオーケストレーションのための本発明の実施形態を説明する。図2は、セルラー通信システムのネットワーク要素間でQoEパラメータを通信するための方法を示す信号図を示す。ネットワーク要素は、ネットワークノード、アクセスノード、基地局、端末装置、サーバコンピュータ、またはホストコンピュータであってもよい。例えば、サーバコンピュータまたはホストコンピュータは、ホストコンピュータが端末装置と通信する仮想ネットワークを生成することができる。一般に、仮想ネットワーキングは、ハードウェアおよびソフトウェアのネットワークリソースおよびネットワーク機能を、単一のソフトウェアベースの管理エンティティ、仮想ネットワークに組み合わせるプロセスを含み得る。別の実施形態では、ネットワークノードは端末装置であってもよい。ネットワーク仮想化にはプラットフォームの仮想化が含まれ、多くの場合、リソースの仮想化が組み合わされる。ネットワーク仮想化は、多くのネットワークまたはネットワークの一部をサーバコンピュータまたはホストコンピュータに結合する外部仮想ネットワークとして分類できる。外部ネットワークの仮想化は、最適化されたネットワーク共有を目標としている。別のカテゴリは、単一のシステム上のソフトウェアコンテナにネットワークのような機能を提供する内部仮想ネットワーキングである。仮想ネットワークは、端末装置を試験するためにも使用され得る。
【００１１】
図2を参照すると、ステップ201において、端末装置UEに関連するデータトラフィックは、中央のQoEオーケストレーターのようなネットワークノードNEによって監視される。中央のQoEオーケストレーターは、ネットワークに接続された別個のエンティティ（QoS / QoE管理エンティティQMEなど）でも、中央のQoEオーケストレーターも別のネットワークノード（PGW、PCEF、および/またはPCRFなど）に統合できる。項目202,203において、アプリケーションセッションが端末装置に対して開始され、対応するデータフローがシステム内のアプリケーションセッション内で転送されてもよい。監視201に基づいて、ネットワークノードNEが、ステップ204において、アプリケーションセッションに関連するデータフロー202,203を検出した場合、ネットワークノードは、要求されたQoEレベルを定義するリソース要件情報を定めるアプリケーションセッションに関して端末装置に提供される。ステップ205において、ネットワークノードは、アプリケーションセッションに関して端末装置で体感するQoEに関する情報を得るために、QoE測定を実行する。項目206,207において、QoE測定の品質に基づいて、ネットワークノードは、リソース要件を満たすためにアプリケーションセッションのQoEを強化（向上）するために1つ又は複数のアクションを実行する。
【００１２】
一実施形態では、リソース要件を満たすためにアプリケーションセッションのQoEを強化（向上）するアクションは、トラフィック管理/ QoE強化および/またはリソース再配布アクションなどのQoE管理アクションを含む。
【００１３】
一実施形態では、QoE管理機能、それらの実行およびオーケストレーションが作成され、システムに追加される。
【００１４】
一実施形態では、中央QoEオーケストレーターなどの装置は、QoE劣化を検出し、輻輳を検出してローカライズし、アプリケーションのQoEを強化するために、相関アプリケーション情報、QoE情報およびネットワーク状態情報をメインに保持する。システムがサポートしているものに応じて、リソースの再配布方法を変更するために、複数のアクション（トラフィックシェーピング、QCI / SPI変更、TCP最適化と過負荷管理、トラフィックステアリングなど）が、システムによってサポートされているもの、輻輳があるかどうか、輻輳した再送信元が何であるかに応じて、リソースの再配布方法を変更するために、トリガーまたは制御される可能性がある。中央のQoEオーケストレーターは、複数のアクションを共同して同じ目標、すなわちアプリケーションに対して良好なQoEを提供するように動作させることができる。中央のQoEオーケストレーターは既存のメカニズムを調和させることもできるため、QoEターゲットに対抗することはできない（つまり、中央のQoEオーケストレーターは、既存のネットワークメカニズムがアプリケーションセッションのQoEターゲットの品質に反するのを防ぐことができる）。
【００１５】
一実施形態では、ネイティブおよびOTTアプリケーションセッションの全体的なQoE管理が実行される。 QoE管理には、通信システムのエンドツーエンドアクションを編成および/またはハーモライズすることによるリアルタイムQoE測定、ネットワーク状態監視、コンテキストベースQoE強化が含まれる。
【００１６】
一実施形態では、中央QoEオーケストレーターQMEのような装置がQoE管理のためにコアネットワークに提供される（図3参照）。中央のQoEオーケストレーターQMEは、コンテキストと特定の劣化タイプへの適用性に基づいて選択された一連の特殊なアクションを通じて、個々のアプリケーションセッションレベル（ネイティブ、すなわちオペレータサービスおよびOTTアプリケーションセッションを含む）と輻輳制御（例えば、QoEインシデント、無線または輸送渋滞）でQoE管理が可能である。中央のQoEオーケストレーターQMEは、QoE管理に独自のメカニズムを使用します。 ただし、利用可能であれば、QoEオーケストレーターQMEは、QoE管理に以前のシステム機能を使用することもできる。したがって、中央のQoEオーケストレーターは、他のネットワーク要素（SPR / HSS、PCRF、PGW / PCEF、コンテンツサーバなど）に接続するためのインターフェースGxx、Sd、Gi / SGi、3001,3002,3003を含むことができる。中央のQoEオーケストレーターQMEは、場所データ、加入者/加入/オペレータポリシー、PCC / QoSルールなどの追加の洞察およびコンテキスト情報も収集することができる。
【００１７】
一実施形態は、3GPPネットワークの様々なリリース（複数の技術の共存を含む）におけるQoS / QoE管理に適用可能である。一実施形態は、アクセスゲートウェイ（例えば、S2aインターフェースを介したWi-Fi）を介して3GPPコアネットワークに統合された非3GPPアクセスネットワークにも適用可能である。
【００１８】
一実施形態では、中央QoEオーケストレーターは、通信システムにおけるネイティブおよびOTTアプリケーションのためのリアルタイムの全体的なQoE管理および強化を実行する。中央のQoEオーケストレーターは、LTE、WCDMA（登録商標） / HSPA（+）、Wi-Fiおよび/またはマルチRAT異種システム内のインラインスタンドアロンエンティティとして展開できる。あるいは、既存のネットワーク要素（PGW、PCEFおよび/またはPCRFなど）を中央QoEオーケストレーション機能を実行するように構成することもできる。中央のQoEオーケストラは、QoEとリソース使用効率を最大限に高めることができる。したがって、中央のQoEオーケストレーターはトラフィックを監視してデータフローとアプリケーションセッションを検出し、適切なレベルのQoEを保証する再送信要件を導き出し、QoE測定を実行して顧客体験の洞察を生成する。さらに、中央のQoEオーケストレーターは、ネットワークの状態を監視して、利用可能なネットワークリソース（トランスポートおよび無線リソース）の状態に関する最新のビューを作成し、エンドツーエンドパスに輻輳がある場合はそれを検出する。それをローカライズし（例えば、UEおよびアプリケーションセッションを識別および/または定位する）、同じリソースに対して競合する一連のアプリケーションを検出することができる。中央のQoEオーケストレーターは、ネットワーク状態、QoE、オペレータポリシーなどの外部入力に応じて、複数のアクションを実行して、すなわち、すなわち、ベアラのアプリケーショントラフィックまたはQoSパラメータを管理して、アプリケーションのQoE要件を満たし、アプリケーションのQoE要件を満たす。トラフィックの操作（例えば、シェーピング）などの中央QoEオーケストレーター内でトリガーされてもよい。または中央のQoEオーケストレーターが標準インターフェースを介してネットワーク側のメカニズムを起動する可能性がある。アプリケーションに対して良好なQoEを提供するために、複数のアクションを実行して並列に調整することができる。QoEを管理することができない既存のネットワークメカニズムもまた、QoE管理と調和することができ、すなわち、QoEターゲットに対抗しないように中央QoEオーケストレーターによって有効/無効にされる。
【００１９】
中央QoEオーケストレーターによって実行されるQoE管理および強化の粒度は、個々のアプリケーションセッション（例えば、特定のビデオダウンロード）および/またはアプリケーションの集約（例えば、一括ダウンロードの累積帯域幅の計算および実施）を対象とすることができる。 各アプリケーションセッションは、その存続期間中に複数のデータフローを組み込むことができる。
【００２０】
ここで、図4を参照していくつかの実施形態を説明する。図4を参照すると、ステップ401において、端末装置UEに関連するデータトラフィックは、中央のQoEオーケストレーターのようなネットワークノードによって監視される。アプリケーションセッションは、端末装置に対して開始されてもよく、対応するデータフローは、システム内のアプリケーションセッション内で送信されてもよい。ステップ402において、ネットワークノードは、アプリケーションセッションに関連するデータフローを検出する。ステップ403において、ネットワークノードは、アプリケーションセッションに関する端末装置に提供されるべき要求されたQoE品質レベルを定義するリソース要求情報を導出する。ステップ404において、ネットワークノードは、アプリケーションセッションに関する端末装置で体感するQoEに関する情報を取得するために、QoE測定を実行する。ステップ405において、測定された体感品質QoEに基づいて、ネットワークノードは、リソース要求を満たすためにアプリケーションセッションのQoEを強化するために1つ又は複数の事前定義されたアクションを実行する。中央のQoEオーケストレーターは、特定のアプリケーションセッションに対応するフローを検出、識別、ローカライズする。中央のQoEオーケストレーターは、アプリケーションタイプおよび要求（例えば、メディアレートまたは要求されるコンテンツの量）に基づいて、セッションのリソース（帯域幅など）要件を定義する。初期化フェーズ（ステップ401,402,403）の後、アプリケーションセッションの全寿命の間、アプリケーションセッションのQoEが管理される（ステップ404,405）。
【００２１】
図5に示すように、QoE管理はアプリケーションセッションのQoEを強化する連続プロセスである（5004）。QoEマネージャは、良好なQoE、アプリケーションの現在のQoE、ネットワークの状態と利用可能なリソース（輻輳を解決するために使用される代替RATまたはトランスポートネットワークセグメントも含む）、PCC / QoSルールに必要な再送信元を考慮する。アプリケーションセッションのQoEは専用アプリケーション固有の指標またはKPIによって測定される（ビデオダウンロードのためのストール、ウェブブラウジングのための時間外ページダウンロード時間など）。ネットワーク状態には、輻輳の検出、ローカリゼーション、および利用可能なリソースの検出および/または測定が含まれる。代替的なRAT、周波数層および/またはトランスポートネットワークの再送信元は、トポロジデータベース、ネットワーク発見および/または測定再ポートによって識別される。 PCC / QoSルールおよび他のポリシーは、QoE管理が動作しなければならない限界として、またはQoEを改善するために変更される可能性のあるパラメータとして考えられる。
【００２２】
中央QoEオーケストレーターの動作は、所与のリソース（例えば、セル、トランスポートリンクなど）について輻輳が検出されたかどうかに依存する（5001）。輻輳がない場合、中央のQoEオーケストレーターは、リソースを個別に共有するアプリケーションセッションのQoEを管理する（5002）。つまり、同じリソースに対して競合していないアプリケーションセッション間の影響を考慮する必要はない。この場合、中央QoEオーケストレーターは、QoSパラメータ（ベアラ属性など）およびPCCルールをアプリケーションセッションに適用して、アプリケーションのQoEを制限しないことを確認する。輻輳が存在する場合、中央のQoEオーケストレーターは、同じ共有リソースに対して競合するアプリケーションセッションを特定し、その要件を検討し、QoEが保持されるようなリソースを再配布するためのアクションを実行し、希少なリソースが無駄にならないようにする。
【００２３】
中央のQoEオーケストレーターは、QoE管理のためにQoE強化と輻輳制御、過剰プロビジョニングを防止するために個々のアプリケーションまたはアプリケーショングループのリソース使用量の制限を実施する（輻輳がない場合）こと、不十分な割り当てを防ぐために輻輳したリソースを再配布する（輻輳がある場合）ことを実行する。
【００２４】
中央のQoEオーケストレーターは、無線ベアラ（3G / HSPAのLTEおよびSPIのQCI）の優先順位を昇格または降格することによって動的QoS管理を実行する（5005）。無線リソースに輻輳がある場合、動的QoS管理を使用して、無線インタフェースリソースをベアラレベルに再分配することができる。輻輳がなければ、動的QoS管理は、デフォルトQoSパラメータが実際に使用されるアプリケーションに対して良好なQoEを提供しない場合、デフォルトQoSパラメータを変更するために使用される。同じベアラ上で同時に実行される複数のアプリケーションがある場合、動的QoS管理はQoE強化と組み合わせて使用される。
【００２５】
中央のQoEオーケストレーターは、TCPソースによって生成される負荷を軽減することによって、TCPオーバーロード管理を実行する（5006）。TCPオーバーロード管理は、ACKシェーピング、アドバタイズウィンドウ（AWND）操作、および/またはスケーリングファクタ（SF）操作などのアクションを含むことができる。負荷を軽減するための積極的な負荷調整機構を提供するために、軽負荷過負荷または増加傾向が検出された場合、TCP過負荷管理がアクティブになる。
【００２６】
中央のQoEオーケストレーターは、TCPセグメントのペーシングがQoEの適用によって定義されたシェーピングレートに調整されるように、TCPのスループットと送信機の動作を最適化することによってTCPの最適化を実行する。
【００２７】
中央のQoEオーケストレーターは、無線リソースの負荷を分散するため、またはトランスポートネットワークの負荷を軽減するために、（代替無線リソースが分離したトランスポートを適用する場合）UEを代替無線レイヤまたはRATに再調整することによってトラフィックステアリング/ Wi-Fiオフロードを実行する。リアルタイムトラフィックステアリング（TS）（5007）は、進行中のアクティブな接続およびデータ転送中に実行される（UEからのMP-TCPサポートを必要とする）。アクティブモードTS（5007）は、データ転送中にアイドル期間があるが、無線ベアラがまだ確立されているときに実行される。 アイドルモードTS（5008）は、UEがセルから離脱するときに実行される。実時間TS及び/又は能動モードTSは、QoEを管理するために使用されてもよく、一方、アイドルモードTSはQoE管理と調和して、アイドルモードTSの結果として新たな接続がすでに輻輳しているリソース（例えば、セル）に向かうことを防止する。
【００２８】
中央QoEオーケストレーターは接続終了（5009）を実行する。QoE要件に従って同じリソースに対して競合するアプリケーションを処理することができない重大な輻輳がある場合、セッションの一部はネットワーク側から抑制または終了され、 既存のリソースを十分に活用することができる。接続終了の基準は、様々な入力およびポリシー（アプリケーションタイプ、オペレータポリシー、加入者/加入など）に基づいてもよい。 アプリケーションを抑制または終了するかどうかは、アプリケーションセッションのQoEターゲットによって決めることができる。
【００２９】
したがって、中央のQoEオーケストレーターは、システム内のエンドツーエンドのアクションを編成および/または調和させることによって、リアルタイムQoE測定、ネットワーク状態監視、QoE強化などのアプリケーションセッション、ネットワークおよびユーザーコンテキストベースのQoE管理を実行する。中央のQoEオーケストレーターは、複数のアプリケーションのQoEを同時に実行して、同じベアラ上でトラフィックを送信できる。中央のQoEオーケストレーターは、無線側の輻輳の場合にQoEを強化し、ネットワークの輻輳を転送し、システムに輻輳がない場合にも適用する。中央のQoEオーケストレーターは、共通のQoEターゲットに基づいて複数のアクションを調整する。これにより、代替アクション間の潜在的な競合を排除し、アクションがお互いに反動しないようにし、それらを並列で実行できるようにして、QoEの強化の効率を高める。中央のQoEオーケストレーターは、QoE認識を持たない既存のメカニズム（アイドルモードトラフィックステアリングなど）と、リアルタイムQoE管理の対象を調和させる。
【００３０】
中央QoEオーケストレーターQMEは、PGW、PCEFおよび/またはPCRFなどの既存のネットワーク要素上で実行されるか、またはその中で実行されるエンティティであってもよく、QoS / QoE管理エンティティQMEなどのスタンドアロンエンティティであってもよい。中央のQoEオーケストレーターQMEには、大量のセッション/接続/フローが集約されるネットワークロケーションでのユーザプレーントラフィックへのアクセスが提供されている。中央のQoEオーケストレーターQMEの別のネットワークノードとの統合および/または論理インターフェースを示す図6を参照されたい。このネットワークロケーションにより、QoEマネージャは、代替無線レイヤと、コアネットワークと個々の無線ヘッド、eNB、BSまたはAPとの間の接続を提供するトランスポートインフラストラクチャを含む、ネットワークステータスに関する一貫した広範なビューを収集することができる。直径および/またはRADIUSプロトコルを使用するHSS / SPR、PCRF / PCEF（すなわちPCC）およびMMEを有する追加のインターフェース（6001）が実装されて、PCC / QoSルールならびにユーザー/ベアラの識別情報（identity）に対する洞察を得る。この連関した洞察は、効率的なシステムリソースの利用を維持しながら、アプリケーションセッションのQoEを強化するために、QoEオーケストレーターQMEがQoEをトリガーするタイミングとアクションについて正確な決定を下すことを可能にする。QoEの適用（アプリケーションシェイパーごとに実装される可能性がある）は、中央のQoEオーケストレーターQMEがユーザーの飛行機のトラフィックをインラインで継続的に実行する。
【００３１】
中央のQoEオーケストレーターは、新しいフロー（例えば、TCPフローおよびUDPフロー）を検出し（7001）、ユーザーを識別し（7005）、それらが属するアプリケーションセッションを識別する（7006）ためにユーザープレーンパケットを監視する（図7参照）。 明白なTCP-SYN接続確立または部分フロー、すなわち前に観測されなかったアドレス/ポート組を有するパケットを認識することにより、新しいフローが検出される（7001）。アプリケーションセッション識別情報は、アプリケーション層（例えば、HTTP）ヘッダ、既知のポート/アドレスから導出され（7002）、宛先IPアドレスを有するDNSクエリをマーチするか、TLSセキュリティ確立の場合にSSLハンドシェイクを分解する。ユーザーの識別情報は、UEのIPアドレス、またはRADIUSなどの外部インターフェースから取得されたIMSIなどの追加情報に基づくことができる。検出されたフロー、ユーザーおよびアプリケーションセッションIDを使用して、中央QoEオーケストレーターは、フローと使用セッションおよびアプリケーションセッションとの関連付けを作成し（7007）、アプリケーションセッションのマッピング（7003）を所与のベアラおよび位置に維持する。ベアラ情報は、ユーザープレーン監視がGTPベースのインターフェース上で実行される場合、GTP-TEIDおよび外部IPアドレスから導出されてもよく、または、その情報は、サポートエンティティからのヘッダーエンリッチメントまたは外部インターフェースからのオフバンドを介してインバンドで受信されてもよい。位置情報は同様の機構を介して取得されてもよい。
【００３２】
新しいアプリケーションセッションでは、中央のQoEオーケストレーターは、ユーザー/アプリケーションポリシーごとのアプリケーション（例えば、ビデオセッションのメディアレート、ウェブページのダウンロード時間目標を維持するためのダウンロードレートなど）の個々のニーズとPCC / QoSルール（該当する場合）に基づいて、初期リソース（帯域幅など）要件、及び、（ネットワーク、リソース、ユーザーの位置での輻輳状態、既に確立されている他のベアラや進行中のセッションなどのような）コンテキストおよび条件を定義する（7004）。これらの要件の最低値は、アプリケーションセッションを処理し、その存続期間中にQoEを強化するQoE管理プロセスの最初のBW要件として提案されている。初期帯域幅選択の完全なコンテキストはQoE管理にも転送され、選択を無効にすることができる（PCCルールまたは輻輳したリソースのために最初のBW要件では適切なQoEが不十分な場合） （同じベアラ内の複数のアプリケーションを処理する場合など）必要に応じて追加のアクションを実行することによって、アプリケーションのパフォーマンスを向上させることができる。アプリケーションセッションの存続期間中に、新しい接続が確立され、セッションに動的に追加されるだけでなく、セッションが完了してセッションから削除される可能性がある。ユーザー（およびセッションの）のローカライゼーションは、リアルタイムでUEのハンドオーバに続く、すなわち、位置マッピングは毎回最新の状態に維持される。QoE管理は、アプリケーションに対応する各フローが終了するまで実行され（7010）、アプリケーションセッション自体も終了する（7009）。
【００３３】
ここで、QoE管理とは、良好なQoEを確保し、QoEの低下を防ぎ、アプリケーションセッションの劣化を解決するために実行されるアクションを指す。 これらのアクションには、例えば、QCI / SPI変更、QoE強化、リアルタイム/アクティブモードTS / Wi-Fiオフロードなどが含まれる。
【００３４】
ここで、QoE強化とは、追加のCプレーンシグナリング（QCI変更に必要なシグナリングなど）を行わずに、アプリケーションニーズに応じてリソースを再配布できる特定のQoE管理アクションを指す。 例えば、シェーパ階層をQoE強化のために使用することができる。
【００３５】
QoEの強化は、中央QoEオーケストレーターの継続的な活動（activity）である。QoEの強化は、所与のユーザーのアプリケーションセッションの累積トラフィック、または（任意選択的に）任意のポリシーに基づいてグループ化されたアプリケーションのセットについて動作するシェーパ（shaper）を使用して実装されてもよい（例えば、ピアツーピアのような所与のタイプの各アプリケーションなど）。シェーパは、シェーパによって管理されるアプリケーション（またはアプリケーション）のQoE要件に基づいてレートが定義されるパケットバッファ内の余分なデータを遅延させることによって、対応するトラフィックの最大レートを実施する。シェーパは、バーストで到着する可能性があるパケットまたは送信に適さないパケット（スロットルが必要な場合）を格納するために、一定量のバッファスペースを必要とする。シェーパは、所与の量のデータサイズ（すなわち、バーストサイズ）までより高い伝送レートを可能にするバーストサイズおよびバーストレートなどの属性も有することができる。シェーパは、シェーパから転送されたパケットが別のシェーパのバッファにエンキューされ、（おそらく動的階層トークンバケット構造を使用して）階層的帯域幅分布を作成するように階層に編成することができる。シェーパは、あるアプリケーションによって利用されない帯域幅が他のシェーパに転送され、最大のシステム効率のために許容レートを一時的に増加させるように、リソースの借用を互いに実施することもできる（作業を節約する方法を実装するため）。システムに輻輳がない場合、QoEの強化はアプリケーションの帯域幅要件に従うが、過剰な割り当てを防ぎ、輻輳した場合の強化の構成を準備するために、必要以上に多くのリソースを（かなり）受け取ることができないようにする。さらに、帯域幅の増加（例えば、ファイルのダウンロードまたはアップロード、ウェブブラウジング）の恩恵を受ける可能性のあるアプリケーションの場合、QoEの強化により帯域幅の割り当てが増え、利用可能なリソースに合理的な負荷が生じる。つまり、データ転送の機会を浪費しないためです。輻輳が発生した場合、中央のQoEオーケストレーターは、同じリソースと利用可能なリソースの量について競合する一連のアプリケーションを識別する。中央のQoEオーケストレーターは、輻輳したリソースを表す累積シェーパと、シェーパレートとして利用可能なリソースの量で構成されたシェーパ階層を構築し、リソースを共有するアプリケーションセッションのシェーパを共通シェーパにチャネル化することができる。この階層は、QoEフレンドリーな方法で共有リソースの帯域幅を効率的に再分配することができ、アプリケーションセッションによって利用されなかったリソースは他のアプリケーションセッションによって借用され、システム利用を最大限に維持することができる。シェーパは、トラフィック（すなわち、固有の送信レートと比較してバックプレッシャフロー）を絞り込むために使用されるだけでなく、他のフロー/アプリケーションに優先順位を付けるためにも使用される。したがって、輻輳の場合、輻輳したリソースのデータをスケジューリングするシェーパの一部は、対応するアプリケーションセッションのQoEを強制するためにそのレートを増加さえすることができる（非対話型トラフィックまたはバルクトラフィックを抑制する）。シェーピング動作は、アプリケーションセッションの最大量（または、オペレータポリシーに応じて、重要なもの）が良好なQoEでサービスされるように、システム効率を維持する（すなわち、利用可能なリソースを完全に利用する）。これにより、アプリケーションセッションのQoE要件に従って利用可能なリソースを再配布する必要が生じる場合がある。利用可能なリソースは、スループット測定値と輻輳/過負荷検出、つまり輻輳/過負荷リソースの測定されたスループットを実際の使用可能容量と相関させることによって、中央QoEオーケストレーターによって検出される。QoEの強化をサポートするために、動的QoS管理（無線輻輳の場合）または（アプリケーションが同時に満たすことができない矛盾する要求を持っている場合）接続終了さえするなど、追加の並列アクションがトリガーされる（後で調和の詳細を参照してください）。
【００３６】
QoE強化アクションは、シェーパアーキテクチャのバッファオーバーフローがTCP ACKシェーピングまたはAWND操作によって防止される共生インターワーキングを作成するために、TCP最適化およびオーバーロード管理アクションの一部と連携する。図8は、QoE強化と組み合わせたTCP最適化と過負荷管理を示している。ACKシェーピング（8002）は、肯定応答セグメントをTCPソースに遅らせることにより、新しいデータセグメントを送信することができるレートを低下させる。 AWND操作（8003）は、ネイティブTCPフロー制御を無効にして、送信機が送信を許可するデータ量を制限する。このようなアクションがなければ、潜在的なバッファオーバーフローにより、エンドツーエンドのTCP輻輳制御の増加をトリガーするために管理対象接続のパフォーマンスが一貫して低下するテールドロップが発生する。代わりに、QoE強化インフラストラクチャのバッファ（8001）は、目標BWが一組の接続で強化される場合、トラフィックのソースも、その送信レートに一致するように（すなわち、パケットを廃棄することなく）円滑にバックプレッシャされるように、可能な限り目標BWに送信する。これにより、中央のQoEオーケストレーターが重大な輻輳ポイントそのものになるのを防ぐこともできる。目標と実際のレートまたはトラフィックバーストの一時的な差異は、依然としてバッファによって吸収される。しかし、非TCPトラフィック（例えば、UDP上のピアツーピア）は、オペレータポリシーに従って抑制される可能性がある。このようなトラフィックが検出された場合、破棄はトラフィック制御の合理的なメカニズムである。他のアプリケーションは、RTP上でリアルタイムストリーミングを提供することができる。これらのために、TCPフレンドリレート制御動作をトリガーするための受信機レポートの操作が使用される。さらに、VoLTEやRTP / RTSP / RTCPを介して運ばれる他のネイティブサービスなどのリアルタイムアプリケーションは、スロットリング、降格、またはフロー制御/終了の対象にはならない。
【００３７】
図9は、動的QoS管理を示しており、QCI / SPI変更アクションが示されている。 QCI / SPIは、パケットスケジューラがeNB / BSでベアラをどのように処理し、ベアラがマッピングされているトランスポートQoSクラスをどのように処理するかを定義する。動的QoS管理は、ベアラをリアルタイムで変更する（すなわち、ベアラを促進または降格させる）。輻輳がない場合（9001）、中央QoEオーケストレーターは、アプリケーションの要件をサポートできない場合に備えて、ベアラのデフォルトQCI / SPIを変更するアクションの開始を検討する。無線インターフェースに輻輳がある場合（9002）、そのアクションの役割は、アプリケーションのニーズに応じてリソースを再配布する際の主要なQoE強化措置をサポートすることである。QCI / SPIの変更（昇進）は、QoE劣化が検出/予測されるアプリケーション/ベアラを含む場合があり（9006）、または他のアプリケーション/ベアラがそのシェアを無線リソースから変更（降格）（9007）することを伴い得る。3Gでは、シグナリングオーバーヘッドのない帯域内メカニズムである中央QoEオーケストレーターによってパケットのDSCPマーキングを変更することで、アプリケーション認識RAN機能の上でSPI変更を実行できる。LTEでは、標準のベアラ変更手順によってQCIの変更がトリガーされる。標準的なLTE実装のシグナリングオーバーヘッドのために、中央QoEオーケストレーターは、QCIの変更をシグナリングの予算に適合させる場合に、システムの制御プレーン容量と負荷を決定すること（9003）を検討する。 さらに、QCI / SPI修正量（例えば、BS / eNB毎秒）の個々の中央QoEオーケストレーター固有の制限が考慮されることもある。制御プレーンノードを過負荷状態から保護するためにQCI変更をバーストで開始することはできない。 代わりに、一定の時間に限られた数のQCI変更手順のみが実行されるように調整される。LTEの代替QCI変更実装として、コアで実行され、eNBによって解釈されるDSCPパケットマーキングによってQCIが変更される場合がある。さらに、QoE管理エンティティがeNB自体またはeNBと適切に統合されたRACSで実装されている場合、QoE管理エンティティは、追加の通信なしで内部的にベアラの優先順位に影響を与える可能性がある。
【００３８】
上述したように、QCI / SPI変更は、基本的なQoE強化アクションと並行して動作することができる。すなわち、中央QoEオーケストレーター自体によって実行されるシェーピングと相補的な方法で無線パケットスケジューラのリソース共有に依存する。あるいは、QCI / SPIの変更が頻繁に行われないように（つまり制御プレーンの過負荷を防止するために）、中央のQoEオーケストレーターは、各ベアラ（非GBRベアラ）をネイティブにマッピングする同一のQCI / SPIクラスに対してインターネットAPNに確立される。このアプローチは、無線インターフェース上のベアラの優先度を等しくし、QoE強化アクションに依存して、シェーピングを介してアプリケーションのQoEを処理し、動的QoS管理の必要性を排除する。これは恒久的なルールでも適応可能なルールでもよい。過負荷が検出されたリソースまたはリソースセットにのみ適用される。この手段は、新たに確立されたベアラに限定されているので、ベアラの支配的な部分が同じQoSクラスに収束するまで、ランプアップ期間が存在する。これにより、動的QoS管理が影響を受ける要素に課す制御プレーンのオーバーヘッドが排除される。あるいは、システム内のすべての非GBRベアラに対してデフォルトで同じQCI / SPIを使用し、QoS / QoEターゲットを達成し、QoE管理の動作を通じてPCCルールを実施することができる。シェーパによって考慮される（または補償される）追加のリソース共有メカニズム（QCIベースの再配布）が存在しないため、コアネットワークで実行される場合のQoE強制動作の効率をさらに高めることさえある。
【００３９】
QCI / SPIの変更は、無線インターフェース上の無線ベアラにリソースがどのように割り当てられるかを調整するだけなので、同じベアラ内に複数のアプリケーションが存在する場合（9004）、QoEの強化によってインベアラシェーピングが実行され（9005）、ベアラのリソースがアプリケーションによってさらに共有される方法を決定する。無線輻輳の場合のQCI / SPIがアプリケーションのリソース共有を効果的に定義するため、このアクションは必ずしもトランスポート輻輳の処理には使用できない。
【００４０】
TCP最適化は、TCP接続を終了することなく（すなわち、中央QoEオーケストレーターがTCPプロキシを開始することなく）実行されてもよい。図10は、TCP最適化の選択肢（10001）を示す。TCP最適化は、オンザフライでエンドツーエンドのTCP接続を分割し、TCPエンドポイントとして最適化を実行するトランスペアレントプロキシとしてセントラルQoEオーケストレーターQMEによって実行され（10004）、TCP最適化を外部のTCPプロキシエンティティにアウトソーシングして（10003）、帯域内シグナリングを介してそれを命令することによって実行される（10002）。
【００４１】
図11は、RFSPインデックスに基づくアクティブモードのトラフィックステアリングを示しています。アクティブモードトラフィックステアリングは、RFSPインデックスシグナリングおよびネットワーク発信ベアラの非アクティブ化（5a）を含むことができる。RFSPインデックスは、UEが無線接続を確立する際に考慮すべき異なるRATまたは周波数帯の優先順位を定義する。無線ベアラが非アクティブ化されるとき、RFSPインデックスはeNBに伝達され(2)、対応する優先順位リストはUEにシグナリングされる。非アクティブ化の適切なスケジュールは、トラフィック分析（1）と、アプリケーショントラフィックにおける次の適切なアイドル期間の検出（3,4）に基づいている。 （接続を手動で切り離して再確立しようとするUEやユーザに頼るのではなく）ベアラはネットワーク側から非アクティブにされる（6）。ベアラの非アクティブ化はアプリケーション自体を終了させないので、次にネットワークにアクセスする必要があるので、UEは、デタッチ中に受信された優先順位リストにしたがって接続を再確立する（7）。
【００４２】
接続終了アクションは、所与のフロー内の各パケットを破棄し、および/またはTCP RSTパケットを双方向に送信すること（TCP接続用）を含む。
【００４３】
中央のQoEオーケストレーターは、図12に示すように、アクションのオーケストレーションとハーモナイゼーション（調和）を実行する。対応するシェーパを維持するためにフローおよびアプリケーションセッションに連続的に続くQoEの強化など、連続的に実行されるアクションがある。TCP最適化動作（プロキシありまたはなし）（1200）は、強化インフラストラクチャのバッファをシームレスに管理し、ネットワークの状態に関係なくTCP動作を実際に強化するために、QoE強化アクション（1201）と協働する。追加のアクションは、システム負荷（すなわち、輻輳のレベルまたは負荷の傾向）およびアプリケーションセッションのQoEに応じて、必要に応じてトリガーされる。負荷ベースの開始と共通のQoE目標は、代替アクションの間で暗黙の調和（1202）を作成し、従ってトリガーと並行して実行されてもよい。
【００４４】
負荷が増加するのに応じて、TCP過負荷管理アクションと呼ばれるソフト負荷防止メカニズムがアクティブ化される。このアクションのトリガーは、特定の共有リソースを介した中央QoEオーケストレーターによる過負荷の検出である。これらのアクションは、スループットの低下に敏感でないフロー、または低優先度またはベストエフォートで配信されるアプリケーションに属するフローのみを対象とする。いずれの場合も、アクション自体は対象フロー上で個別に実行される。ソフトウェア過負荷防止メカニズムは、TCP最適化アクションと同様にネイティブTCPメカニズムを利用して、ネットワークの洞察を利用したTCP操作を実装される。ACKシェーピングおよびAWND操作（1203）は、特定のフローのレートを選択的に低減するメカニズムとしてトリガーされて、他のフロー/アプリケーションセッションのためにスケジューリングされるリソースを解放するか、または輻輳を完全に解決することもできる。SF操作（1203）は、TCPハンドシェイク中にウィンドウスケーリングがネゴシエートされる場合に、SYN / SYN-ACKセグメントに存在するウィンドウスケーリングファクタを除去する、補完的軽量オーバーロード管理アクションである。その結果、TCPソースと受信機は、ピアエンティティがウィンドウスケーリングを処理することができない（または意図している）と推測し、64KBの上限を持つ従来のアドバタイズされたウィンドウサイズを使用する。SFアクションは、最初のハンドシェイクパケットで動作する必要があるだけであり、後でその接続に従う必要はないため、非常に軽量である。
【００４５】
TCPオーバーロード管理アクションは、負荷に応じてオンに切り替えられ、新しいフローに選択的に適用される（これは、SF操作に必要ですが、AWND管理またはACKシェーピングにも適用される可能性がある）。既存のフローが終了し、新しいフローが確立されると、フロー集団は徐々に過負荷管理アクションの対象となる。図13は、TCP過負荷管理動作の起動1301および停止1302を示す。 負荷が減少した場合のアクションの段階的排除は、新しいフローが過負荷管理アクションをバイパスしているのと同じロジックに従い、最終的に各管理対象フローを置き換える。
【００４６】
TCP過負荷管理アクションは、ネイティブにQoE施行アクションと相互運用し、同じフローに対して毎回ではなく動的QoS管理1204と同時にトリガーされてもよい。TS / Wi-Fiオフロードアクション1205の対象となる可能性のあるフローのアクションをトリガーすることは可能であるが、TS / Wi-Fiオフロードが完了した後にフローが終了して再確立されるので効率的ではない（デバイスが 新しいIPアドレスを受け取る）。
【００４７】
動的QoS管理のオーケストレーションは、無線側の輻輳がある場合に、ベアラ間で無線リソースのシェアに影響を及ぼすようトリガーされ得る。このアクションは、無線インターフェースに十分なリソースがあるにも関わらず、デフォルトのベアラ設定によってQoEの低下が発生した場合など、過負荷または軽輻輳の場合に適用できる。これらのケースでは、わずかなベアラを再設定するだけで、QoEの劣化を解決または防止することができる。このメカニズムは、QoE管理の補助ツールであり、以下の他のアクションと同時にトリガーされる可能性がある：QoE強化（はい）、TCPオーバーロード管理、及び、TCP最適化（いいえ）、（つまり、肯定的な区別につながるQoS管理アクションの主題はTCP過負荷管理の対象にはならない。輻輳を解決するためにこれらのフローのレートが低下する必要がある場合は、TCP最適化を降格の補助メカニズムとして使用することができる）。アクションをトリガーすることは、アプリケーションのQoEが現在のセル/ RATコンテキスト内で強化されることを意味し、したがって、対応するUE /ベアラを同時にTS / Wi-Fiオフロードの対象にすることは妥当ではない。
【００４８】
アイドル・モード・トラフィック・ステアリング/ Wi-Fiオフロード（1207）は、代替無線層にユーザーをリダイレクトして、無線の負荷を分散させるか、またはトランスポートの負荷を低減する（代替無線が不連続トランスポートを適用する場合）。リアルタイムまたはアクティブモードのTS / Wi-Fiオフロード動作は、個々のUEに対してトリガーされてもよい。 したがって、それらは専用のアクションを提供するが、アイドルモードTSはキャンプUE上で動作するので、非決定論的で非リアルタイムの動作である。TS / Wi-Fiオフロードの複数の変種がシステム内に共存する可能性がある。
【００４９】
実時間TSは、UEがアクティブな接続および進行中のデータ転送を有する間に、トラフィックのステアリングまたはオフロードを実行することができる。実時間TSの円滑な実行は、UEがMP-TCPをサポートすることを必要とし、すなわち、複数のRATを介してTCP接続（エンド・ツー・エンドのUE-サーバ通信）を仮想的に分割し、同一接続内の複数のRATを介して同時にデータを受信することができる。その場合、MP-TCP接続は、最初にターゲットRATをオンにし、次にソースRATをオフにすることによって、あるRATから別のRATに移行することができる。実時間TSは、代替のRAT /トランスポートリソースを利用することができることにより、無線リソースまたはトランスポート輻輳を制御するために、UEまたはUEのセットごとにトリガーされてもよい。
【００５０】
アクティブモードトラフィックステアリングは、UEの無線ベアラがまだ確立されているが、アプリケーションが現在アイドルである場合、すなわち進行中のデータ転送がない場合にTSアクションをトリガーする。適用可能性は実時間TSと同じであるが、UE側のサポートは必要ない（一方、アクティブモードのトラフィックステアリングは、再確立が完了するまで、接続が完全に壊れているため、待ち時間が長くなり、より侵入しやすくなる）。
【００５１】
アイドルモードトラフィックステアリングは、キャンプUE、すなわち確立された無線ベアラを持たないUEのRAT /セル選択に影響を及ぼす。これは、ポリシー/負荷/無線チャネル測定基準に基づいてRAT間の負荷を均衡させることである。したがって、アイドルモードのトラフィックステアリングは、輻輳の場合には適用されず、非決定的であり、カウンタアクションを防止するためにQoE管理と調和しなければならない。中央のQoEオーケストレーターは、過負荷が検出されたセル/ Wi-Fi APまたは永続的な過負荷/輻輳のあるリソースへのTSまたはWi-Fiオフロードを禁止する。
【００５２】
アイドルモードのトラフィックステアリングは、QoE管理と調和している。 図14は、アイドルモードTS / Wi-Fiオフロードによるアイドルモードトラフィックステアリングの調和を示している。調和（ ハーモナイゼーション）は、TSがUEを輻輳したリソースに振り向けるのを防止することである。 輻輳は、ターゲットRATにサービスを提供する無線側（1401）またはトランスポートネットワーク（1402）上にあってもよいことに留意されたい。 いずれの場合も、目標RATの使用を提唱することから、TSがブロックされる（1403）。しかしながら、他方向へのトラフィックステアリング、すなわち、輻輳したセル/ RATから十分なリソースを有するものへのステアリングが可能にされる（1404）。
【００５３】
一実施形態では、QoE管理エンティティQMEは、データトラフィックを監視してアプリケーションセッションを検出し、そのリソース要件を導出し、QoE測定を実行する。さらに、QMEはネットワークの状態を監視して、エンドツーエンドパスの輻輳を検出してローカライズし、同じ再送信元に対して競合する一連のアプリケーションを検出する。この相関した洞察を使用して、QMEはネットワーク内のQoE劣化を予防または解決するための積極的または反応的なアクションを開始する。QMEは、QoEの観点から最適なシステムに近いリソース分散スキームを維持するために、輻輳またはQoEの低下がない場合でも、ベア・リソースまたはアプリケーションのQoSプロファイルをリソース要件に合わせる。これにより、輻輳が発生した場合、QoE強制に必要な対話の程度は限られており、割り当てられたリソースが減少した場合でも、大きな過渡が回避され、アプリケーションはできるだけスムーズで予測可能なサービスとして受け取る。QMEはPCCシステムと連携して、アクションを実行するための既存のPCRF / PCEF機能を利用し、その決定をPCC / QoSルールと調和させる。
【００５４】
一実施形態では、標準化されたGxxインターフェースを使用して、QMEを、既にモバイルシステムに展開されているPCRF / PCEFベースの施行メカニズムと統合する。既存のPCCインフラストラクチャと連携して、既存のポリシーとの動作を調和させ、GxxやオプションでSdなどのインターフェースを介して既存のネットワーク機能を部分的に再利用するQoE駆動の動的トラフィック管理アクションを実装する。Gxxインターフェースは、a）PCEFに関する情報を取得するため、およびPCEF内のPCRFによって供給されるQoSルール、およびb）PCRFを介してPCEFに追加の施行動作をプッシュするために使用することができる。Gxxインターフェースは、UEが開始したQoS変更要求として強化アクションをマスクすることによって利用される。これにより、PCRFが標準化されたGxxインターフェースを実装している場合に、QMEとPCRFの統合がベンダーに依存しないソリューションになる。QMEはまた、PCRFに対して追加のQoE /アプリケーション固有のトリガーを提供するためにSdインターフェースを実装してもよい。これにより、ロジックをアプリケーション特有のイベント、QoE劣化などに作用することができる高度なPCRF実装にシフトすることが可能になり、QMEから必要な情報/トリガーを受信する。
【００５５】
図15は、QoS / QoE管理のための第三者エンティティとPCRF / PCEFとの論理的統合を示す。集中調和型QoS / QoE管理は、PCRF / PCEFベースの施行メカニズムが既にネットワークに配備されている場合に実装される。PCEFを強化ポイントとして再利用することは、既存のインフラ投資を保護する。サードパーティのQMEがPCEFを動的に制御できるようにすることで、アプリケーションセッションをユーザー、アプリケーションセッション、QoEおよびネットワーク状態を意識した方法で、リアルタイムで管理することができ、PCRF / PCEFのみの能力に基づいては不可能である。QMEの決定は、従来のPCC / QoSルールに基づいてPCRF / PCEFによって適用されるトラフィック処理を考慮し、PCRFおよびQMEに起因する非効率的または矛盾する動作を防止する調和のとれたトラフィック管理ソリューションを作成される。
【００５６】
QMEは、アプリケーションを検出し、そのQoEを測定し、アプリケーションのメタデータを収集し、ユーザーの動作を認識するために、ユーザープレーンパケットを監視する。新しいアプリケーションセッションが開始されると、QMEはそのリソース要件を検出し、PCCルールが最初に良好なQoEを妨げる程度にトラフィックを制限するかどうかを評価する。PCCルールが制限要因（例えば、UEによって確立されたベアラのMBRがアプリケーションセッションの帯域幅要件よりも低い）である場合、QMEは、セッションを終了させるか、またはコンテンツ適応をトリガーすることができる。さもなければ、QMEは、アプリケーションとのネットワークメカニズムを調和させるために、アプリケーションのニーズに最も適したQoSプロファイルを動的に選択することができる。ユーザープレーンのパケット監視は、ネットワーク側の輻輳を検出してローカライズするための効率的かつ機密性の高い方法である。輻輳がある場合、QMEは混雑したネットワークセグメント内の利用可能なリソースを測定し、影響を受けるユーザー、すなわち、同じボトルネックリソースに対して競合するものを特定する。アクティブなアプリケーションセッション、それらのリソースニーズ、オペレータポリシーおよび優先順位、加入プロファイルなどに基づいて、QMEは、リソースの再配布方法、すなわち、個々のアプリケーションセッションまたはアプリケーションのセットが受け取るリソースは何か等を定義する。アプリケーションの差別化およびリソース割り当ての粒度は、個々のアプリケーションセッション（例えば、特定のビデオダウンロード）および/またはアプリケーションの集約（例えば、一括ダウンロードの累積帯域幅の計算および実施）を対象とすることができる。最大のユーザー数に対して（または、輻輳が激しい場合には、オペレータの視点からの優先度が最も高いユーザーに対して）良好なQoEを提供するために、QMEは、適切な治療（例えば、重要なトラフィックの優先順位付け、非インタラクティブなバックグラウンドトラフィックのシェーピングなど）を実行するアクションについて決定する。QMEは、PCEFにさらに伝搬するPCRFにコマンド（例えば、QCI変更/ベアラ変更、帯域幅制限など）を送信するために、Gxxインターフェースを使用する。Gxxインターフェースは、PCRF自体によってプロビジョニングされたルールに基づいて、PCEFによって実施された強化に関する情報を得るためにQMEでも使用する。
【００５７】
Gxxインターフェースには、SGWによって終端されるか、ネットワーク内の別の信頼できるAGWによって終端されるかによって、2つのバリエーションがある。SGWの変形はGxcインターフェースと呼ばれ、AGWの変形はGxaインターフェースと呼ばれる。 QME統合の場合、GxaまたはGxcインターフェースの使用は、QMEの導入と導入によって異なる。
【００５８】
QMEは、コアネットワーク内のユーザプレーンパケットモニタリングから、そのユーザー、アプリケーション、およびQoEの洞察（insight）を直接取得するインラインネットワーク要素する（図15を参照）。あるいは、QMEは、コアネットワーク、無線アクセス、または任意の他のユーザープレーンまたは制御プレーンインタフェースに配置された別個のモニタリングエンティティ、スニファ、またはプローブを介して洞察を収集する集中エンティティであってもよい。どちらの場合も、PCRFとの統合はGxaインターフェースを使用する。
【００５９】
S5 / S8インターフェイス上でPMIPを使用する場合、GxcはSGW内のPCRFとBBERFの間で使用され、無線アクセスネットワークにQoSを適用する。 この場合、QMEは、PCRFとSGWとの間に位置し、PCRFに向かってBBERFとして作用し、SGWに対してPCRFとして作用する。
【００６０】
あるいは、QMEをSGW自体と統合することもできます。その場合、PCRFとの統合にはGxcインターフェースが使用される。 これは、GTPとPMIPがS5上で使用される場合の両方で可能である。
【００６１】
一実施形態では、アプリケーションセッションのQoEを強化するために、QoE管理アクションを、端末装置が開始したQoS変更要求としてマスクすることができる。したがって、QMEは、UEから発信されたかのようにマスクされたQoS変更をトリガーすることができる可能性がある。その場合、PCEFを制御することは、QMEが、UEの開始したQoS変更要求としてPCRFにそのコマンドを提出することを要求する。ここで、QoS変更要求は、新しいルールを追加するか、または既存ルールを修正または削除するクレジット制御要求（CCR）として実施される。 CCRには、対応するQoSオプションとともに、施行の範囲内にあるIPフローの定義が含まれている。これには、以下の属性を持つCCRの作成が必要です。CC-Request-Type AVPは、「UP-DATE_REQUEST」に設定されている。イベントトリガー（event-trigger）AVPは 「RE-SOURCE_MODIFICATION_REQUEST」に設定されている。パケットフィルタ操作（packet-filter-operation）AVPは、「追加」、「変更」または「削除」に設定されている。パケットフィルタ情報（packet-filter-information）AVPは、強化（エンフォースメント）が適用されるトラフィック（IPフィルタを介して）を定義する。QoS情報（QoS-information）AVPは、要求されたQoSを示すように設定される。
【００６２】
パケットフィルタ情報は、QMEが利用可能な強化の粒度を定義する。 パケットフィルタは、プロトコル、ソースおよび宛先IPアドレス（マスクされていてもよい）、およびソースおよび宛先ポート番号（または範囲）を含むIPフローごとに作成されてもよい。 この情報は、ユーザプレーンパケットヘッダのモニタリングに基づいて、QMEによって取得され、満たされ得る。
【００６３】
QMEで利用可能な強化アクションは、サポートされているQoS情報の可能なセットによって定義される。QoS情報は、以下の1つ又は複数を含むことができる。対応するベアラのQCI；DLまたはULで保証されたデータレートを設定すること；DLまたはULで最大データレートを設定すること；さらに、許可された保証されたデータレートおよび最大の許可されたデータレートパラメータを自動的に導出するためにPCRFによって使用される最小必要帯域幅を設定することが可能である。
【００６４】
Gxxインターフェースは、PCRFがQMEから独立して管理するQoSルールに関する情報を取得するためにも使用される。PCRFは、QoSルールインストールAVPまたはQoSルール除去AVP内のGxxインターフェース上の再認証要求（RAR）メッセージでQoSルールを送信することができる。QMEは、QoSルールのアクティブ化または除去を受け入れる再認証応答（RAA）で応答する。
【００６５】
PCRFによって独立して管理されるQoSルールを取得する別の方法は、GxトラフィックをQMEに転送するGxインターフェースに直径ルーティングエージェント（DRA）を展開することである。これにより、PCRFに対して透過的にQoSルールを洞察することができる。 その場合、GxxインターフェースはQoSルールをPCRFに伝播する単方向インターフェースとしてのみ使用される。
【００６６】
任意選択的に、Sdインターフェースは、PCRFとQMEとの間で使用されてもよく、QMEはTDFとしても機能する。 QMEはPCRFからADCルールを直接受信することがある。これらのルールは、既存のPCEFで専用のPCCルールを使用して区別される可能性のある一連のアプリケーションを示し、QMEによって報告される情報が必要である。QMEは、標準のTDF報告機能（例えば、アプリケーションセッションの識別、アプリケーションセッションの開始および終了の検出および指示）のみを実行することができ、又は、拡張された非標準化データセット（例えば、アプリケーションのQoE、輻輳表示など）を提供することができる。拡張測定を受信するには、Sdインターフェースの標準化またはPCRFの独自サポートが必要である。
【００６７】
一実施形態は、少なくとも1つのプロセッサと、コンピュータプログラムコードを含む少なくとも1つのメモリとを備える装置を提供し、前記少なくとも1つのメモリおよびコンピュータプログラムコードは、前記少なくとも1つのプロセッサによって、上述したネットワーク要素またはネットワークノードの手順を実行する。したがって、少なくとも1つのプロセッサ、少なくとも1つのメモリ、およびコンピュータプログラムコードは、ネットワーク要素またはネットワークノードの上述の手順を実行するための手段の実施形態と考えることができる。図16は、そのような装置の構造のブロック図を示す。この装置は、ネットワーク要素に含まれていてもよいし、ネットワークノードに含まれていてもよい。装置はネットワーク要素またはネットワークノードにチップセットまたは回路を形成することができる。いくつかの実施形態では、装置はネットワーク要素またはネットワークノードである。この装置は、少なくとも1つのプロセッサを含む処理回路（10）を備える。処理回路（10）は、データトラフィックを監視し、アプリケーションセッションに関連するデータフローを検出するように構成されたデータフロー検出器（16）を含むことができる。データフロー検出器（16）は、上述したように、アプリケーションセッションに関連するデータフローを検出し、データフローおよびアプリケーションセッションに関する情報をリソース要件決定回路（18）に出力するように構成することができる。リソース要件決定回路（18）は、アプリケーションセッションに関する要求されるQoEレベルを定義するように構成される。装置は、アプリケーションセッションに関して端末装置で体感する情報QoEを取得するためにQoE測定を実行するように構成されたQoE測定回路（12）をさらに備えることができる。QoE測定回路は、上述したように、端末装置で体感したQoEを測定し、QoE強化回路（14）に端末装置で体感したQoEに関する情報を出力するように構成することができる。QoE強化回路（14）は、リソース要件を満たすためにアプリケーションセッションのQoEを強化するために、1つ又は複数のアクションを実行するように構成されている。
【００６８】
処理回路（10）は、サブ回路として回路（12）から回路（18）を含むことができ、または同じ物理処理回路によって実行されるコンピュータプログラムモジュールとみなすことができる。メモリ（20）は、回路（12）から回路（18）の動作を指定するプログラム命令を含む1つ又は複数のコンピュータプログラム製品（24）を格納することができる。メモリ（20）は、例えば、中央QoEオーケストレーションのための定義を含むデータベース（26）を格納することができる。装置は、端末装置との無線通信能力を装置に提供する通信インタフェース（図16には図示せず）をさらに含むことができる。通信インターフェースは、無線通信を可能にする無線通信回路を備え、無線周波数信号処理回路およびベースバンド信号処理回路を含むことができる。ベースバンド信号処理回路は、送信機および/または受信機の機能を実行するように構成することができる。いくつかの実施形態では、通信インターフェースは、少なくともアンテナと、いくつかの実施形態では、基地局に関する遠隔地における無線周波数信号処理を含む遠隔無線ヘッドに接続されてもよい。そのような実施形態では、通信インターフェースは、無線周波数信号処理の一部のみを実行してもよいし、無線周波数信号処理を全く実行しなくてもよい。通信インターフェースと遠隔無線ヘッドとの間の接続は、アナログ接続またはデジタル接続であってもよい。いくつかの実施形態では、通信インターフェースは有線通信を可能にする固定通信回路を含むことができる。
【００６９】
別の実施形態は、少なくとも1つのプロセッサと、コンピュータプログラムコードを含む少なくとも1つのメモリとを備える装置を提供し、前記少なくとも1つのメモリおよびコンピュータプログラムコードは、前記少なくとも1つのプロセッサによって、上述したネットワーク要素またはネットワークノードの手順を実行する。したがって、少なくとも1つのプロセッサ、少なくとも1つのメモリ、およびコンピュータプログラムコードは、ネットワーク要素またはネットワークノードの上述の手順を実行するための手段の実施形態と考えることができる。図17は、そのような装置の構造のブロック図を示す。装置は、ネットワーク要素から構成されてもよいし、ネットワークノード内に含まれてもよい。装置は、チップセットまたは回路網をネットワーク要素またはネットワークノード内に形成することができる。いくつかの実施形態では、装置はネットワーク要素またはネットワークノードである。この装置は、少なくとも1つのプロセッサを含む処理回路（10）を備える。処理回路（10）は、データトラフィックを監視し、アプリケーションセッションに関連するデータフローを検出するように構成されたフロー検出器（17B）を備えることができる。フロー検出器（17B）は、上述したように、アプリケーションセッションに関連するデータフローを検出し、データフローおよびアプリケーションセッションに関する情報を要件生成器（18B）に出力するように構成することができる。要件生成器（18B）は、アプリケーションセッションに関する要求されるQoEレベルを定義するように構成される。この装置は、QoE測定を実行して、アプリケーションセッションに関する端末装置で体感する情報QoEを取得するように構成された品質計（12B）をさらに備えることができる。品質計（12B）は、上述したように、端末装置で体感したQoEを測定し、端末装置で体感したQoEの情報をリソースマネージャ（14B）に出力するように構成することができる。リソースマネージャ（14B）は、リソース要件を満たすためにアプリケーションセッションの体感品質QoEを強化するために、1つ又は複数のアクションを実行するように構成されている。
【００７０】
処理回路（10）は、サブ回路として回路（12B）から回路（18B）を含むことができ、または同じ物理処理回路によって実行されるコンピュータプログラムモジュールとみなすことができる。メモリ（20）は、回路（12B）から回路（18B）の動作を指定するプログラム命令を含む1つ又は複数のコンピュータプログラム製品（24）を格納することができる。メモリ（20）は、例えば、中央QoEオーケストレーションのための定義を含むデータベース（26）を格納することができる。装置は、端末装置との無線通信機能を装置に提供する通信インタフェース（図17には図示せず）をさらに含むことができる。通信インターフェースは、無線通信を可能にする無線通信回路を備え、無線周波数信号処理回路およびベースバンド信号処理回路を含むことができる。ベースバンド信号処理回路は、送信機および/または受信機の機能を実行するように構成することができる。いくつかの実施形態では、通信インターフェースは、少なくともアンテナと、いくつかの実施形態では、基地局に関する遠隔地における無線周波数信号処理を含む遠隔無線ヘッドに接続されてもよい。そのような実施形態では、通信インターフェースは、無線周波数信号処理の一部のみを実行してもよいし、無線周波数信号処理を全く実行しなくてもよい。通信インターフェースと遠隔無線ヘッドとの間の接続は、アナログ接続またはデジタル接続であってもよい。いくつかの実施形態では、通信インターフェースは有線通信を可能にする固定通信回路を含むことができる。
【００７１】
このアプリケーションで使用されているように、「回路」という用語は、以下のすべてを指す。
（a）アナログおよび/またはデジタル回路のみの実装などのハードウェアのみの回路実装；
（b）回路およびソフトウェアおよび/またはファームウェアの組み合わせ、例えば（該当する場合）：（i）プロセッサまたはプロセッサコアの組み合わせ; （ii）デジタル信号プロセッサ、ソフトウェア、および装置に特定の機能を実行させるために一緒に働く少なくとも1つのメモリを含むプロセッサ/ソフトウェアの一部; （c）ソフトウェアまたはファームウェアが物理的に存在しない場合であっても、動作のためにソフトウェアまたはファームウェアを必要とするマイクロプロセッサまたはマイクロプロセッサの一部のような回路。
【００７２】
この「回路」の定義は、このアプリケーションのこの用語のすべての用途に適用される。さらなる例として、本出願で使用される場合、用語「回路」は、単にプロセッサ（または複数のプロセッサ）またはプロセッサの一部分、例えばプロセッサの実装をもカバーする。 マルチコアプロセッサの1つのコア、およびその（またはそれらの）付随するソフトウェアおよび/またはファームウェアを含む。 「回路」という用語は、例えば特定の要素に適用可能であれば、ベースバンド集積回路、特定用途向け集積回路（ASIC）および/または本発明の実施形態による装置のためのフィールドプログラマブルグリッドアレイ（FPGA）回路を含む。
【００７３】
図1〜17に関連して上述したプロセスまたは方法は、1つ又は複数のコンピュータプログラムによって定義される1つ又は複数のコンピュータプロセスの形で実行することもできる。コンピュータプログラムは、コンピュータプログラムのモジュールも包含するものとみなされるべきである。上記の処理は、より大きいアルゴリズムのプログラムモジュールまたはコンピュータプロセスとして実行されてもよい。コンピュータプログラムは、ソースコード形式、オブジェクトコード形式、または何らかの中間形式であってもよく、それは、プログラムを運ぶことができる任意のエンティティまたはデバイスであるキャリアに格納されてもよい。そのようなキャリアには、一時的および/または非一時的なコンピュータ媒体、例えば、コンピュータメモリ、読み取り専用メモリ、電気搬送波信号、電気通信信号、およびソフトウェア配布パッケージを含むことができる。必要とされる処理能力に応じて、コンピュータプログラムは、単一の電子デジタル処理ユニット内で実行されてもよいし、複数の処理ユニットの間で分散されてもよい。
【００７４】
本発明は、上で定義されたセルラーまたは移動通信システムに適用できるが、他の適切な通信システムにも適用可能である。使用されるプロトコル、セルラー通信システムの仕様、それらのネットワーク要素、および端末装置は急速に発展する。そのような開発は、記載された実施形態に対する追加の変更を必要とすることがある。したがって、すべての単語および表現は、広義に解釈されるべきであり、それらは、実施形態を例示することを意図したものであり、限定するものではない。
【００７５】
技術が進歩するにつれて、本発明の概念を様々な方法で実施できることは、当業者には明らかであろう。 本発明およびその実施形態は、上記の例に限定されず、特許請求の範囲内で変更することができる。
【００７６】
略語のリスト
ACK    肯定応答
AP    アクセスポイント
APN    アクセスポイント名
AWND    広告ウィンドウ
BS、BTS    基地局
BW    帯域幅
CoDel    制御遅延
DNS    ドメインネームシステム
DSCP    差別化サービスコードポイント
eNB    進化ノードB（evolved node-B）
GTP    一般パケット無線サービストンネリングプロトコル
HSPA    高速パケットアクセス
HSS    ホーム加入者サービス
HTTP    ハイパーテキスト転送プロトコル
IMSI    国際モバイル加入者識別情報
IP    インターネットプロトコル
LTE    ロングタームエボリューション
MME    モビリティ管理エンティティ
MP-TCP    マルチパスTCP
OTT    オーバーザトップ（over the top）
PCC    ポリシーと課金管理
QCI QoS    クラスインデックス
QoE    体感品質（quality of experience）
QoS    サービス品質
RAT    無線アクセス技術
RED    ランダム早期検出
RFSP    RAT /周波数選択の優先順位
SAE-GW    サービスアーキテクチャの進化ゲートウェイ
SF    スケーリング係数
SPI    スケジューリング優先度インデックス
SSL    セキュアソケットレイヤー
TCP    伝送制御プロトコル
TEID    トンネルエンドポイントID
TLS    トランスポート層のセキュリティ
TS    トラフィックステアリング
UDP    ユーザーデータグラムプロトコル
UE    ユーザー装置
WCDMA     広帯域符号分割多元接続
PGW PDN    ゲートウェイ
PDN    パケットデータネットワーク
PCEF    ポリシーと課金執行機能
PCRF    ポリシーと課金ルール機能
Wi-Fi    ワイヤレス忠実度
RADIUS    ユーザサービスのリモート認証ダイヤル
RAN    無線アクセスネットワーク
AVP    属性 - 値ペア
KPI    キーパフォーマンスインジケータ
RNC    無線ネットワークコントローラ
RACS    リソースと承認制御サブシステム
OFCS    オフライン充電システム
ANDSF    アクセスネットワークの検出と選択機能
SADM    一斉通信デバイスマネージャ
WAM    Wi-Fiアクティベーションマネージャ
WSM    Wi-Fiシステム/サービスマネージャ
SGW    サービングゲートウェイ
【符号の説明】
【００７７】
１０  処理回路
１２  QoE測定回路
１２Ｂ  品質計
１４  QoE強化回路
１４Ｂ  リソースマネジャー
１６  データフロー検出器
１６Ｂ  フロー検出器
１８  リソース要件決定回路
１８Ｂ  要件生成器
２０  メモリ
２４  コンピュータプログラム製品
２６  データベース
【図１】
0006701196.tif 000002
【図２】
0006701196.tif 000003
【図３】
0006701196.tif 000004
【図４】
0006701196.tif 000005
【図５】
0006701196.tif 000006
【図６】
0006701196.tif 000007
【図７】
0006701196.tif 000008
【図８】
0006701196.tif 000009
【図９】
0006701196.tif 000010
【図１０】
0006701196.tif 000011
【図１１】
0006701196.tif 000012
【図１２】
0006701196.tif 000013
【図１３】
0006701196.tif 000014
【図１４】
0006701196.tif 000015
【図１５】
0006701196.tif 000016
【図１６】
0006701196.tif 000017
【図１７】
0006701196.tif 000018