JP6553196B2 - トラフィックフローの監視 - Google Patents

Description

本発明は、通信に関する。

３ＧＰＰ ＨＳＰＡ、ＬＴＥ又は第五世代（５Ｇ）ネットワークのようなワイヤレステレコミュニケーションシステム、及び固定アクセスネットワークでは、顧客体験（ＣＥ）管理の目的は、システムリソースを効率的に使用しながら、必要量のシステムリソースを各アプリケーションセッションに与えることであり、即ち、顧客体験を最大にすることである。ＱｏＥの管理は、アプリケーションに対する相関インサイト(insight)及び測定、顧客体験ユーザ振舞い、ネットワーク状態、及びサービスクオリティを要求する。

１つの観点によれば、独立請求項の要旨が提供される。実施形態は、従属請求項に規定される。

具現化の１つ以上の例を添付図面及び以下の説明に詳細に示す。他の特徴は、説明及び図面からそして特許請求の範囲から明らかとなるであろう。

以下、本発明は、添付図面を参照して好ましい実施形態により詳細に説明する。

本発明の実施形態が適用されるワイヤレス通信システムを示す。 本発明の実施形態によるトラフィックフローの監視手順のシグナリング図である。 本発明の実施形態によるフローベースの監視及び測定のプロセスを示す。 個々の及び協働的フローベース測定値を得てアグリゲートするところを示す。 本発明の実施形態により相関ＱｏＥ、ユーザ振舞い、アプリケーション及びネットワーク側ＱｏＳインサイトを得るためのプロセスを示す。 顧客体験ＣＥエージェントのための配備オプションを示す。 ＣＥエージェント及びＣＥエージェント間相互作用を使用するケースを示す。 アプリケーションレイヤパケットヘッダからパースされたフロー記述子及び属性を示す。 パケットごとの監視アクションを示す。 個々の及び協力的なフローごとのＱｏＳ測定を示す。 ＣＥエージェント間の協力的測定及びリアルタイム状態更新を示す。 ＴＣＰフローに対しＣＥエージェントにより実行されるＱｏＳ測定を示す。 コア側ＣＥエージェントにおけるパケットロスの間接的局所化を示す。 ２つのＣＥエージェントでのダウンリンク方向の一方遅延測定を示す。 多数のＫＰＩの１つのＲＴＴ相関測定を示す。 アプリケーション特有のＱｏＥ測定を示す。 ネットワークセグメントにおける遅延プロフィールを示す。 混雑局所化及び異常値検出を示す。 遅延分布のスキューを示す。 分散型無線部側ＣＥエージェント配備を示す。 コア側スタンドアローンＣＥエージェント配備を示す。 合成ＣＥエージェント配備を示す。 インラインコア側ＣＥエージェント・対・タッピングコア側ＣＥエージェントを示す。 ３Ｇ ＢＴＳ／ＲＮＣ特有のＣＥエージェント具現化を示す。 Ｗｉ−Ｆｉ特有のＣＥエージェント具現化を示す。 ＬＴＥ Ｓ１−ＭＭＥインターフェイスにおける制御プレーン測定を示す。 本発明の実施形態による装置のブロック図である。

以下の実施形態は例示に過ぎない。明細書の多数の位置に「一(an)」、「１つの(one)」又は「幾つかの(some)」実施形態という語が現れるが、これは、必ずしも、その各々が同じ実施形態を指すか又は特徴が１つの実施形態のみに適用されることを意味するものではない。異なる実施形態の１つの特徴を組み合わせて他の実施形態を形成してもよい。更に、「備える(comprising)」及び「含む(including)」という語は、ここに述べる実施形態を、ここに記載した特徴のみで構成することに限定するものではなく、そのような実施形態は、ここに特別に記載されない特徴／構造を含んでもよいことを理解されたい。

図１は、本発明の実施形態が適用されるワイヤレス通信シナリオを示す。図１を参照すれば、セルラー通信システムは、決定された地理的エリアに無線カバレージを与えるように配置されるベースステーションを含む無線アクセスネットワークを備えている。ベースステーションは、例えば、数平方マイル以上に広がる比較的広いエリアにわたる無線カバレージをターミナル装置（ＵＥ）１０６に与えるように構成されたマクロセルベースステーション（ｅＮＢ）１０２を含む。容量の改善が要求される人口密度の高いホットスポットでは、小面積セルベースステーション（ｅＮＢ）１００が配備されて、ターミナル装置（ＵＥ）１０４に高データレートのサービスが提供される。そのような小面積セルベースステーションは、マイクロセルベースステーション、ピコセルベースステーション、又はフェムトセルベースステーションと称される。小面積セルベースステーションは、典型的に、マクロベースステーション１０２よりカバレージエリアが著しく小さい。セルラー通信システムは、第三世代パートナーシッププロジェクト（３ＧＰＰ）長期進化（ＬＴＥ）アドバンスト又はその進化バージョン（５Ｇのような）の仕様に基づいて動作する。

自動的で且つ高精度のネットワーク監視は、異常検出、問題局所化、根本的原因分析、及びトラフィック／ＱｏＳ／ＱｏＥ管理アクションを含む効率的なネットワークオペレーションを可能にする。インターネットベースのアプリケーションの連続使用及びＯＴＴコンテンツの消費によって発生する移動トラフィックの増加量を管理するには、オペレーションのリアルタイムインサイト及び端から端まで全体の効率が必要とされるときに、既存のものを越えるネットワーク側データ収集メカニズムが要求される。そのようなメカニズムは、ネットワーク運営者が顧客体験(Customer Experience)を所有できるようにする。非リアルタイムコール設定成功率又は高レベルアグリゲートスループット／データ量統計値の集合体のような慣習的なテルコ・ドメインＫＰＩは、ユーザプレーン又は個々のＯＴＴアプリケーションセッションに関する情報を搬送せず、従って、それらをＱｏＥインサイト発生に使用することができない。ＱｏＳ／ＱｏＥ／帯域巾管理／実施、混雑検出、混雑制御、ネットワークオペレーション及びトラブルシューティング、等の進歩型メカニズムは、ネットワーク及びユーザプレーンアプリケーションの状態に関するリアルタイム、高精度、及び粒状の情報を要求する。この情報は、判断の実行及び修正／予防アクションも可能にする。

通常、ユーザプレーントラフィック関連のＫＰＩは、もしあれば、オリジナルトラフィックに対してしばしば侵入的に、互いに独立して、測定され及び収集され、これは、測定を拡張不能にすると共に、専用のＫＰＩごとの統計学的評価にしか使用できなくする。

ネットワーク状態の自動的及び効率的な監視、ネットワーク側の問題（例えば、過負荷、混雑、失敗、非最適構成、等）の検出、並びに異常の局所化及び診断は、ＫＰＩの良好に定義された相関セットを有することで可能となる。種々のネットワーク監視解決策は、ＲＴＴ、遅延、ジッタ、負荷、スループット、等のネットワーク側ＱｏＳ ＫＰＩを別々に収集することができる。しかしながら、これらＫＰＩの測定は、時間的に相関もされないし、又、同じ端−端コンテキスト（例えば、ＴＣＰ接続）に基づいてもいない。更に、それらの解像度は、測定それ自体の間に既に制限されるか、或いはその後、測定値が収集され解釈されるまでに、即ちＱＣＩクラス／セル／ｅＮＢにわたってアグリゲートするときに又は測定時間窓が典型的に数分程度又はそれ以上であるときに、制限される。アグリゲートすることは、解像度を減少し且つリアルタイムで使用するケースを防止するだけでなく、情報及び詳細のロスも意味する。収集したＫＰＩのタイムリーな配信及びそれらのリアルタイム評価も問題であり、即ち異なるＫＰＩの測定値が非同期で収集され処理されることがある。非同期の測定、粗いアグリゲート粒度、長い測定窓、タイムリーな配信の欠如、並びに非同期の収集及び処理のために、当該情報が失われ、そしてコンテキストベースの分析（例えば、パターン、原因となる作用、相関ＫＰＩ値、又は変化、例えば、増加した遅延及びロス、並びに低下したスループットを同時に識別する）に測定値を使用することができない。ＫＰＩの分布が測定されそして別々に利用できるとしても、それらの個々の（ＫＰＩごとの）統計学的評価しかできず、ＫＰＩ間の相関（例えば、２つのＫＰＩがそれらのピークに同時に到達するかどうか、それらが同じ方向に動くか又は逆方向に動くか、等）は、依然、永久的に失われる。この種の情報は、改善型異常検出及び診断方法を適用すべきケースでは、該当している。長い（この状況では、１秒の時間窓は既に長い）測定窓及びアグリゲートに伴う問題は、測定値の更新が遅過ぎそして時間的ピークが平均化され、動的システムにおけるリアルタイム変化を検出できなくすることである。それ故、これら測定値を使用できるのは、粗くて長期の統計学的ネットワーク監視だけであり、効率的なネットワーク管理及びオペレーションを可能にするリアルタイム検出及び判断実行には使用できない。

既存のネットワーク監視システムにおける若干の測定値だけがＱｏＥに関連している。ある値又はスコアは、アプリケーションセッションの相対的な比較（例えば、高いスコアは、ビデオにおいてストールが少ないことを意味する）を可能にするが、それらは、ＱｏＥ測量に基づくものではなく、従って、エンドユーザの意見を反映せず又は量子化しない（むしろ、それらは、任意の方程式を経てのＱｏＳ測定値のアグリゲート数値表現に過ぎない）。

ＬＴＥでは、Ｓ１及びＸ２インターフェイスに混雑検出メカニズムが設けられず、従って、自然なＬＴＥプロトコルスタックには、ネットワーク状態に関する情報を与えるための内蔵型トランスポートネットワーク関連の測定値が存在しない。

一方アクティブ測定プロトコル（ＯＷＡＭＰ）は、一方遅延測定のための標準的フレームワークを定義する。このメカニズムは、送信者及び受信者とも称される２つのネットワークノード間のスケジューリングテストセッションに基づくものである。ＯＷＡＭＰは、関係者のクロックが同期されている（例えば、ＧＰＳを経て）と仮定する。テストセッション中に、送信者は、送信者側での送信に対応するタイムスタンプを各々保持する一連のＵＤＰテストパケットを送信する。受信者は、各テストデータグラムからタイムスタンプを読み取ってデコードし、そしてそれをそのローカルクロックと比較して、サーバーとそれ自身との間の一方遅延を計算する。測定結果は、収集されて、後で分析される。二方アクティブ測定プロトコル（ＴＷＡＭＰ）は、ラウンドトリップ（即ち、二方）遅延を測定するためのフレームワークである。ＯＷＡＭＰ及びＴＷＡＭＰは、両方とも、付加的なテストトラフィックをネットワークに注入することを要求し、この個別のテストトラフィックについて測定がなされる。それ故、収集した測定値は、テストトラフィックが経験した状態のみを反映し、それとは異なるかもしれない実際のユーザプレーントラフィックが経験した状態は反映しない。又、テストトラフィックそれ自体（一定ビットレートの非ＴＣＰトラフィックに近い）は、（ほとんどのＴＣＰベースの又はＴＣＰと親密な）リアルなフローに比してネットワーク状態に異なる仕方で対応している。それ故、個別のテストトラフィックから得られたインサイトの関連性は、オリジナルパケットで得られる測定値に比して低い。又、ＯＷＡＭＰ及びＴＷＡＭＰメカニズムは、充分な拡張性がない。というのは、多数のネットワークセグメントにおいて一方／二方遅延測定値を得るために、多数のピア・ツー・ピアテストセッションを、ネットワークセグメントごとに１つ、確立する必要があるからである。これは、ＯＷＡＭＰ／ＴＷＡＭＰ管理の複雑さ及び制御トラフィックのオーバーヘッドを高め（テストセッションを交渉するために）、そして注入されるテストトラフィックの量を増加することもある（１つのネットワークセグメントが多数のテストセッションによりカバーされるので）。更に、多数のＰＨＢに対応する測定値を得るために、ＰＨＢごとの（ＤＳＣＰごとの）個別セッションを手動で構成する必要がある。この解決策は、動的に変化するシナリオには使用できない。

ＨＳＤＰＡ及びＨＳＵＰＡでは、フレームプロトコル（ＦＰ）レイヤ内の遅延蓄積及びパケットロスを検出することに基づくｌｕｂ／ｌｕｒインターフェイスに、標準的な混雑検出及び混雑制御メカニズムが存在する。混雑検出を可能にする測定値は、ＦＰヘッダへ明確にエンコードされるので、それらは、端−端遅延／ロス測定又は付加的なＫＰＩを与えるように拡張されず、ｌｕｂ／ｌｕｒインターフェイスに限定される。更に、その解決策は、静的なスレッシュホールドに基づくもので、これは、あるネットワーク状態及びトラフィック混合シナリオにおいて混雑を正確に検出ことができない。

図２を参照してトラフィックフロー監視のための本発明の実施形態を以下に説明する。図２は、セルラー通信システムのネットワーク要素間にネットワークサービスパラメータを通信する方法を示すシグナリング図である。ネットワーク要素は、ネットワークノード、アクセスノード、ベースステーション、ターミナル装置、サーバーコンピュータ、又はホストコンピュータである。例えば、サーバーコンピュータ又はホストコンピュータは、バーチャルネットワークを生成し、これを通してホストコンピュータがターミナル装置と通信する。一般的に、バーチャルネットワークは、ハードウェア及びソフトウェアネットワークリソース並びにネットワーク機能を、単一のソフトウェアベースの監理エンティティ、バーチャルネットワークへと合成するプロセスを含む。他の実施形態では、ネットワークノードは、ターミナル装置である。ネットワークバーチャル化は、リソースバーチャル化としばしば合成されるプラットホームバーチャル化を含む。ネットワークバーチャル化は、多数のネットワーク又はネットワークの部分をサーバーコンピュータ又はホストコンピュータへと合成する外部バーチャルネットワーキングとして分類される。外部ネットワークバーチャル化は、最適化されたネットワーク共有をターゲットとする。別の分類は、単一システムのソフトウェアコンテナにネットワーク状機能を与える内部バーチャルネットワーキングである。又、バーチャルネットワーキングは、ターミナル装置をテストするのにも使用される。

図２を参照すれば、アイテム２０１において、ネットワークノードＮＥ１は、ネットワーク内を送信されるユーザプレーントラフィックフローを監視し、選択されたデータパケットに対して測定を遂行する。監視に基づき、ネットワークノードは、２０２において、ユーザ測定データ、アプリケーション測定データ、経験クオリティ測定データ、ネットワーク側サービスクオリティ測定データ、及び１組のキー性能指示子、の１つ以上を相関的に収集する。相関的収集とは、（同じパケット、又はあるパケット及びそれに対応する応答パケットを使用して）１つの測定ラウンドにおいて、ネットワークノードＮＥ１がＱｏＥ、ＱｏＳ及びネットワーク状態を同時に定質化して、収集したＱｏＥ、ＱｏＳ及びネットワーク状態のインサイトが、各々、現在ネットワーク状態における所与のユーザのアプリケーションに対応するようにさせられることを意味する。相関的収集に基づいて、ネットワークノードは、２０３において、顧客の経験に対するリアルタイム相関インサイトを生成する。又、相関的収集に基づいて、ネットワークノードは、２０３において、経験クオリティの考えられる低下に対するネットワーク側の理由を決定する。

アイテム２０４において、ネットワークノードは、生成された相関インサイト、及び／又はＱｏＥ質低下に対する決定された理由を別のネットワークノードＮＥ２に指示する。或いは又、ネットワークノードは、生成された相関インサイト、及び／又はＱｏＥ質低下に対する決定された理由を別のネットワーク運営者に指示する。アイテム２０５において、前記他のネットワークノードは、生成された相関インサイト、及び／又はＱｏＥ質低下に対する決定された理由を各々受け取る。

ある実施形態は、当該ユーザ、アプリケーション、ＱｏＥ、ネットワーク側ＱｏＳ測定値及びＫＰＩの集合体を通して、リアルタイム相関インサイトを、ユーザの振舞い、アプリケーションセッションの属性、並びにアプリケーションのＱｏＥ及びネットワークの状態に与えることができる。ここで使用するユーザ測定データ、アプリケーション測定データ、経験クオリティ測定データ、ネットワーク側サービスクオリティ測定データ、及び／又は１組のキー性能指示子という語は、各々、当該ユーザ関連、アプリケーション／サービス関連、及び／又はネットワーク関連の測定データ及び／又は性能指示子を指す。一実施形態では、当該測定データは、ユーザプレーントラフィックから連続的パケット監視を通して収集される。各ユーザプレーンフローの確立が検出されて、所与のユーザ及びアプリケーションに関連付けされる。各ユーザプレーンフローに対して、当該イベント（例えば、データセグメント又は確認、再送信、破棄、順序がずれたセグメント、等の到着パケット）が検出されるか、又は新たなデータ断片が接続を通して任意の方向に転送されるときに連続的に更新される１組のＫＰＩがある（フローベース監視及び測定を示す図３を参照）。真のリアルタイム測定及びインサイト生成は、瞬時ＫＰＩ値が導出されたときに可能とされ、そして各当該イベントが検出されると直ちに更新される。このように生成されるＫＰＩは、各フローに対するパケットレベル端−端性能を直接反映し、従って、過渡的質低下／改善を含むアプリケーション性能に関する情報の効率的な捕獲を可能にする。当該測定データは、ＴＣＰ（これは、データを送信又はダウンロードするために多数のアプリケーションにより使用されるトランスポートレイヤプロトコルである）及び／又はＵＤＰトラフィック（例えば、ＲＴＰ／ＲＴＳＰ、等にわたってストリーミングする）から収集される。測定は、平易テキスト及び暗号（例えば、ＨＴＴＰＳ、ＴＬＳ、ＶＰＮ、等）フローにおいて遂行される。

一実施形態において、測定データは、単一の測定ポイントにより収集されるか、或いは移動ネットワークを通るユーザプレーントラフィックの端−端経路に沿った当該位置に配置された多数の測定ポイントにより収集される。多数の測定ポイントが使用されるケースでは、それらが協働して（即ち、特定の状態又は測定情報を交換して）、ネットワークに対するインサイトの精度及び／又は詳細レベル、並びにそれらの位置のみからアクセスできる特定情報を伴うアプリケーション性能を向上させる。個々の及び協働的フローベース測定値を得てアグリゲートすることを示す図４を参照されたい。ユーザアクション、アプリケーションパラメータ、及び既存のＫＰＩから導出できないＱｏＥ、例えば、アプリケーションごとのＵＬ／ＤＬデータボリューム又は高レベルスループット測定値に対して粒状の正確なビューが配信される。ＱｏＳ測定データは、個々のフローレベルで収集され、そして任意の考えられるレベル、例えば、アプリケーション（アプリケーションが多数の同時フローを通してデータを転送する場合）、ベアラ、セル、ＱＣＩ、ｅＮＢ、ＤＳＣＰ、Ｓ１、等へとアグリゲートされる。収集された測定データは、既存のレガシーＱｏＳ測定のスーパーセットを表わし、それ故、それらは、既存のＱｏＳ測定ベースで使用するケースも可能にする（例えば、遅延／負荷スレッシュホールドベースの検出、トリガー又はアクション）。

一実施形態において、監視ポイントは、ＴＣＰベースのアプリケーションのケースでは同じデータセグメント及びそれに対応する確認パケットをたどり、又はＲＴＰ／ＲＴＣＰ／ＲＴＳＰベースのアプリケーションのケースではデータフレーム及びそれに対応する受信者レポートをたどる。というのは、それらは、ネットワークを通して端から端まで横断し、そして監視ポイントが厳密に同じパケットに対して各当該ＫＰＩの測定を遂行する（個々に又は協働で）からである。その結果、パケット（又はパケット対、即ちデータ及びそれに対応する確認）当たりコヒレントなデータセット、及び各アプリケーションセッション／フロー当たりＱｏＥ及びＱｏＳ ＫＰＩの自然な相関セットの測定値が得られる。図５は、相関ＱｏＥ、ユーザ振舞い、アプリケーション及びネットワーク側ＱｏＳインサイトを得るところを示している。

一実施形態において、相関異常、質低下及び混雑の検出は、ボトルネック容量を推定しそして異常又は混雑が検出されて分析されるときのアプリケーションレベル性能（ＱｏＥ）を考慮することにより遂行される。従って、無線セル又はボトルネックトランスポートリンクの容量が測定され、リンク又はネットワーク要素の負荷が測定され、ＫＰＩのコンテキストベースプロフィールが生成され、そして普通でないイベント及びユーザプレーン異常がリアルタイムで検出される。この容量は、簡単な遅延／ロススレッシュホールドベースの混雑検出メカニズムより優れている。というのは、簡単な遅延／ロススレッシュホールドベースの混雑検出メカニズムは、普遍的でなく、そして静的なスレッシュホールドが、ネットワーク配備の不均質性及びアプリケーションにより生成されるトラフィックの動的性のために偽の肯定イベント又は誤った混雑イベントを生成するので、一般的なメカニズムとして適用できないからである。

一実施形態において、リアルタイム測定値及びＫＰＩ収集体は、個々のフローベースで検出されるイベント／パケットに基づいて即座に生成される。測定値は、フローレベルで既に入手でき、そして意義のある高いレベル（アプリケーション、ユーザ、セル、等の）までアグリゲートされる。測定データは、（人為的に注入されるテストトラフィックではなく）顧客体験を定義するユーザプレーンデータにおいて収集される。

一実施形態において、相関測定／収集は、ユーザ、アプリケーション、ＱｏＥ、及びネットワーク側ＱｏＳ ＫＰＩにおいて遂行される。

一実施形態において、プロフィーリング及び異常検出は、アプリケーションレベルユーザプレーンパケットフロー（即ち、高周波数の個々のイベント）にリアルタイムで（ＫＰＩオフラインの高度にアグリゲートされた時間シリーズではなく）適用される。従って、ユーザプレーン異常は、非常に早期に検出される。エンリッチ型ネットワーク監視、トラブルシューティング、顧客ケア及び／又はマーケッティングキャンペーンに対して情報が与えられる。

一実施形態において、検出された異常は、例えば、混雑による質低下を識別するために分析される。混雑の特徴付け、ボトルネック分類、及びシステム内の利用可能なリソース量の検出／測定が実行される。

ある実施形態は、アクティブなアプリケーションによって生成されるトラフィック及びパケットを観察することによりユーザプレーンに測定値が収集されるので、多売主環境、及び無線アクセス技術（３Ｇ、ＬＴＥ、５Ｇ及びＷｉ−Ｆｉを含むが、これに限定されない）に適用できる。ある実施形態は、測定値がＲＮＣにおいて３Ｇ特有のユーザプレーンプロトコルレイヤから収集されるｌｕｂ／ｌｕｒインターフェイスに適用される。

一実施形態において、測定は、ＴＣＰ及び非ＴＣＰフロー（例えば、ＵＤＰストリーミング）の両方において遂行される。これは、インサイトを任意の考えられるアプリケーションへと生成する（そして将来現われる新規なアプリケーションの迅速な採用を可能にする）。

一実施形態は、制御プレーン性能を定量化／定質化し、そしてＱｏＥ測定の精度を高めるために制御プレーンに適用できる。

一実施形態において、リアルタイム相関インサイトが、当該ユーザ、アプリケーション、ＱｏＥ、及びネットワーク側ＱｏＳ測定値及びＫＰＩの集合体を通して、ユーザ振舞い、アプリケーションセッションの属性、ＱｏＥ及びネットワークの状態へと生成される。１つの測定ラウンドでは、ＱｏＥ、ＱｏＳ及びネットワーク状態を定質化することができ、従って、インサイトを顧客体験に与えるだけでなく、考えられる質低下に対するネットワーク側の理由を指示することもできる。

一実施形態において、測定されたＱｏＥ質低下の相関に基づいて混雑検出が遂行され、そしてロスパターン検出、遅延プロフィール分析、及び相関遅延／ロス／スループットプロフィーリング及び分類のような進歩型指示子に基づいてネットワーク状態検出が遂行される。メカニズムは、パラメータ化を要求しない自動及び自己学習型であり、所与の端−端インスタンス（Ｓ１、Ｘ２、ｌｕｂ又はｌｕｒインターフェイスのような）を（自己）プロフィール化することができ、即ちそれ自身を所与のインスタンスに適応させ、そのインスタンスに典型的な振舞いを学習し、そしてそこからのずれを検出することができる。メカニズムは、それ自身を実際の状態に適応させることができ、これは、認識ネットワークに向かう主要ステップである。

一実施形態において、混雑の特徴付け及びボトルネックの分類は、プロフィーリング及びパターンマッチング技術に基づくもので、破棄パターン又は遅延分布属性のような改善型指示子を監視し分析することにより行われる。

一実施形態において、制御プレーン性能は、ユーザプレーンアプリケーションＱｏＥとの相関で監視され、ネットワークへのアタッチのような制御プレーン手順を含めてユーザ接続の全寿命をカバーする全体論的ＱｏＥインサイトを与える。

一実施形態において、顧客体験（ＣＥ）エージェントは、ユーザプレーンパケットにアクセスできるネットワーク要素で実行されるか又はそこにアタッチされる。図６は、ＣＥエージェントに対する配備オプションを示す。ＣＥエージェントは、ＵＥにより生成されるオリジナルトラフィックへのアクセスが可能である各位置においてネットワーク技術のトップに配備されて動作される。これは、異種のネットワーク配備もサポートする真の多売主解決策を可能にする。測定データは、ユーザプレーントラフィックそれ自体に収集され、これは、５Ｇのような新規な技術における配備を可能にする。例えば、ＳＧＷ／ＰＧＷ、ｅＮＢ／ＲＡＣＳ又はＨＳＰＡ＋ＢＴＳにおいて実行されるコア内のスタンドアローンボックスを仮定すれば、ＣＥエージェントは、中間ボックスとして働いて、通信端装置（一般的レベルにあるクライアント／ＵＥ及びサーバーと称される）により送信されるパケットを傍受し、要求されるユーザ、アプリケーション、ＱｏＥ及びＷｏＳ測定を遂行する。測定は、データパケットのヘッダコンテンツを監視し、パケットが傍受された時間を記録し、そしてヘッダエンリッチメントと称されるメカニズムを通して付加的なヘッダフィールドを追加／削減することにより実行される。ヘッダエンリッチメント、即ち付加的なヘッダフィールドの追加及び削減は、多数のＣＥエージェントが、それらのＣＥエージェント間に特定の情報を搬送する目的でユーザプレーンフローの端−端経路に配備される場合だけ行われる。これは、ネットワークセグメント当たり専用の測定値を収集し、及び質低下を検出した場合に問題を局所化するイネーブラーである。ＣＥエージェント及びＣＥエージェント間相互作用に対する使用ケースが図７に示されている。

別の実施形態において、通信エンティティにより生成されたユーザプレーンパケットへのアクセスが可能でないｌｕｂ／ｌｕｒインターフェイス（３Ｇ ＢＴＳ及びＲＮＣ）の２つのエンドポイントで実行するとき、ＣＥエージェントは、ｌｕｂ／ｌｕｒプロトコルヘッダのコンテンツを監視することにより当該情報を収集する。従って、ｌｕｂ／ｌｕｒフレームプロトコルフレームにおける監視は、それらインターフェイスにおけるロス及び遅延測定に使用されて、トランスポートネットワークの混雑の明確な指示を収集し（即ち、ＲＮＣによりＢＴＳへ送信されるＣＩ、ＲＬＣ状態ＰＤＵ、等）、そしてＨＳＰＡ ＦＰ制御フレーム（タイプＩ／タイプII）のコンテンツを観察し及びプロフィーリングすることでＨＳＰＡ混雑及びフロー制御の動作を監視する。更に、ＲＮＣにアタッチされたＣＥエージェントは、異常検出及び局所化に使用されるＲＲＣからのインサイト、例えば、無線インターフェイス又はカバレージ問題の明確な指示を収集する。

ＱｏＳ及びＱｏＥ測定は、プロトコルヘッダのコンテンツ、アプリケーションメタデータを抽出／監視し、そしてユーザアクション及び振舞いを検出することにより、ユーザプレーンフローごとに同時に実行される。ＱｏＳ測定は、システムの負荷増加のようなネットワーク状態及びユーザが同時に経験するサービスのレベルの正確な指示子であるＫＰＩのセットを含む（例えば、スループット、遅延、ＲＴＴ、パケットロス比、パケット破棄パターン、等）。従って、ＱｏＳ測定は、２つの分類、即ち各ＣＥエージェントにより独立して実行される個々の測定、及びＣＥエージェント間のアクティブな協力によってのみ得られる協力測定、を有する。協力は、ＴＣＰの二方向パケット転送を使用し、即ちその確認方法により、データがＤＬのみ又はＵＬのみに転送されてもパケットが各フローにおいてＵＬ及びＤＬの両方に送信される。又、非ＴＣＰフローも、ヘッダエンリッチメントを経て両方向に情報を搬送できる同様のメカニズム（例えば、ＤＬにおける普通のデータフローに加えてＵＬにおけるＵＥからのフィードバック）を有する。各々のケースにおいて、測定値は、フローごとに収集され、次いで、ネットワークのクオリティ及び状態を示すＫＰＩの生成に作用するように意義のある仕方でアグリゲートされ、効率的な混雑及び異常検出並びに分析を可能にし、そして最終的に、異常値を識別する。

一実施形態において、進歩型監視及び測定は、広い範囲のＱｏＳ及びＱｏＥ ＫＰＩについてユーザプレーンインサイト生成及び計算のために実行される。ＣＥエージェントは、各横断パケットを傍受して、新たなＴＣＰ接続（ＴＣＰヘッダのＳＹＮフラグセットにより識別される）の確立を検出すると共に、非ＴＣＰフロー（例えば、ＵＤＰストリーミング）の確立及び存在も検出する。フローごとに、ＣＥエージェントは、傍受したパケットヘッダから検出された属性のセットを識別しそして維持する。属性は、例えば、アプリケーションレイヤタプル（プロトコル、ＩＰアドレス及びＴＣＰ／ＵＤＰポート）を含み、これは、フロー記述子と称される（アプリケーションレイヤパケットヘッダからパースされたフロー記述子及び属性を示す図８を参照されたい）。更に、ＣＥエージェント（例えば、Ｓ１／Ｘ２インターフェイス又はＲＡＣＳ）の位置においてＧＴＰトンネルでフローがカプセル化されるケースでは、外部ＩＰアドレス、ＵＬ及びＤＬ方向のＧＴＰトンネルエンドポイント識別子、及びＤＬ及びＵＬにおける外部ＩＰヘッダのＤＳＣＰクラス、フローロケータと称される、も、フロー属性の一部分となる。ＣＥエージェントは、プロトコルレイヤにおける付加的なヘッダフィールドも監視して、測定を遂行するか（例えば、ＴＣＰシーケンス／ＡＣＫ番号、ＴＣＰ広告窓、等を使用して）、或いは種々の次元に沿った測定値のアグリゲーションを可能にする（例えば、ＰＨＢごとのアグリゲーションを与えるためにＩＰ ＤＳＣＰフィールドを使用して）。フローの寿命中に、フロー記述子（ＤＳＣＰのような）の部分ではない属性は、変化する（例えば、リアルタイムベアラＱｏＳ更新のために）。ＣＥエージェントは、属性の変化した第１パケットが傍受されるや否や、それらの変化を検出し、そしてそれに対応するフローの属性をリアルタイムで更新する。

フローが検出された後に、ＣＥエージェントは、フローのパケットに対してＱｏＥ監視及びネットワーク側ＱｏＳ測定を遂行し続ける。所与のフローを監視することにより得られたＱｏＳ測定データは、フローのフロー記述子でインデックスされるフローごとのデータ構造体に収集される。ＣＥエージェントにより傍受される各パケットが分析され、そして既存のプロトコルヘッダに基づいて、実現可能なＱｏＥ及びＱｏＳ測定が実行される（パケットごとの監視アクションを示す図９を参照されたい）。

ＱｏＳ測定は、次の２つの分類に分けられる。即ち１）他のＣＥエージェントと同期せずに各ＣＥエージェントにより得られる個々の測定。個々のＱｏＳ測定は、（これに限定されないが）スループット（ＵＬ及びＤＬ方向に別々に収集された）、ＲＴＴ、遅延／ＲＴＴジッタ及びパケットロス（端−端の上流及び下流コンテキストに別々に収集された）を含む。及び２）プロトコルヘッダエンリッチメントを使用して関連ＣＥエージェント間の状態更新を通して得られる協力的測定。状態更新は、ＣＥエージェントにより定義されるネットワークセグメントの粒度で端−端ＱｏＳ測定の微細なセグメント化を可能にし、更に、プロトコルヘッダエンリッチメントは、ネットワークセグメントごとのＲＴＴに加えて各ＣＥエージェント間の個別のアップリンク及びダウンリンク一方遅延を測定することができる。

又、スループット及び負荷の測定（フローごと、アプリケーション、ベアラ、ＤＳＣＰクラス、セル、ｅＮＢ、等）も、混雑の検出、及びネットワークで利用可能なリソースの測定を可能にする。それ故、正確なスループット測定、及び高い負荷の検出を可能にする他の指示（増加したＲＴＴ／遅延のような）とのその相関が遂行される。個々の及び協力的なフローごとのＱｏＳ測定が図１０に示されている。

フローごとのＱｏＳ測定は、フロー属性の複数の次元に沿ってアグリゲートされ、例えば、所与のベアラ（Ｓ１インターフェイスにおける外部ＩＰアドレス及びＧＴＰトンネルＩＤにより識別される）、ＵＥ（各インターフェイスにおけるフロー記述子ＵＥアドレス）、ｅＮＢ（Ｓ１インターフェイスにおける外部ＩＰ ｅＮＢアドレス）、等に対応するアグリゲーションを生成する。（位置のような）フロー記述子の部分でない付加的な属性に沿ったアグリゲーションも実行される。又、複数のアグリゲーション次元も考えられ、例えば、各ｅＮＢ内にＤＳＣＰごとのアグリゲーションを生成する。このアグリゲーションは、アグリゲーション基準を満足するネットワークセグメントごとの連合又は各フローの測定値の和を生成することにより遂行される。高レベルアグリゲートにおける非常に多数のサンプルの収集を回避するため、アグリゲーションプロセス中にサンプルを破棄してサンプルサイズを減少する。

図１１は、ＣＥエージェント間の協力的測定及びリアルタイム状態更新を示す。協力的測定及び状態更新の実施は、図１１において、ＴＣＰフローに対するＲＴＴ及びロス測定により示されている（しかしながら、他のＫＰＩ、及びフィードバックも有する非ＴＣＰフローに対して原理は同じである）。各ＣＥエージェントは、ネットワーク内のＣＥエージェントを独特に識別し且つ位置決めする識別子（例えば、整数）を有する。各ＣＥエージェントは、ＱｏＳ測定データをその上流及び下流ネットワークセグメントに対して別々に収集する。測定が行われるとき、ＣＥエージェントは、測定タプルを、同じフローにおいて受け取った次のＵＬ及びＤＬパケットへエンリッチする。測定タプルは、ＣＥエージェント自身のアイデンティティ、測定のタイプ（例えば、下流ＲＴＴ）、及び測定値（例えば、４２ｍｓ）を含む。ＵＬパケットは、上流方向に配置されたＣＥエージェントへ情報を搬送し、一方、ＤＬパケットは、下流方向に情報を搬送する。ＣＥエージェントは、別のＣＥエージェントによりエンリッチされたヘッダを伴うパケットを傍受するときに、情報をデコードし、そして受け取ったデータを、その個々の測定データ、及び他の関連ＣＥエージェントから受け取った測定値と合成し、ネットワークセグメントごとのＱｏＳ ＫＰＩを生成する。測定タプルは、それらが得られたユーザプレーン接続においてインバンドで搬送されるので、デコードするＣＥエージェントは、受け取った測定値をそれ自身の上流及び下流測定値と合成するのに必要な完全なコンテキストを有する。状態更新は、各ＣＥエージェントにより得られた測定データが、同じユーザプレーン接続を傍受する各ＣＥエージェントに配布されて、同じ端−端コンテキストを共有する各関連ＣＥエージェントがネットワーク状態の共通の知識を維持することを保証する。この原理は、任意の数の関連ＣＥエージェントに対して一般化される。

ＣＥエージェントは、構成可能な窓サイズ（例えば、２００ｍｓ）をもつ連続時間窓においてＤＬ又はＵＬに送られるデータの量に基づいて接続のスループットを個々に測定する。ＣＥエージェントによりなされるスループット測定は、他のＣＥエージェントへ搬送される必要がない。というのは、それらが同じパケットを傍受し、そして同じスループット測定データを自動的に得ることができるからである。ＵＤＰのケースでは、スループットは、データグラムにより転送されるデータの量に基づいて測定される。ＴＣＰのケースでは、スループットは、データセグメントの到着及びＡＣＫセグメントの到着の両方に基づいて測定される。ＤＬにおいて到着するデータセグメントは、ＤＬデータスループットに貢献する。逆のＵＬ方向に受け取られるＡＣＫは、以前のＡＣＫに対応するデータＡＣＫ増分的確認の量に基づいて測定されるいわゆるＤＬバーチャルスループットを生成する。２つのタイプのスループットは、相補的であり、即ちＤＬデータスループットは、上流からのデータの到着を測定し（これは、上流ボトルネックがない場合にはパケットレベルにおいてラインスピードバーストを含む）、一方、バーチャルスループットは、ＵＥが最終的にデータを受信できるレートを測定する。データスループットとバーチャルスループットとの間の相違は、下流の最後の測定ポイントより下のボトルネックの検出及び測定を可能にし、例えば、ｅＮＢにあるか又はコアネットワークにあるＣＥエージェントにより狭い無線インターフェイス容量を正確に測定することである。これは、各ＣＥエージェントが、例えば、ヘッダエンリッチメントを経て情報を互いに交換する必要なく、個々の測定のみによりネットワーク状態にアクセスできるようにする。

ＴＣＰフローに対してＣＥエージェントにより実行されるＱｏＳ測定が図１２に示されている。ＣＥエージェントは、ハンドシェーク中にＴＣＰ接続において第１のＲＴＴ測定値を得て、初期のＳＹＮ、ＳＹＮ＋ＡＣＫ及びＡＣＫセグメント間の遅延を測定する。ハンドシェークが完了した後に、ＣＥエージェントは、（１）ＴＣＰヘッダにおける所与のシーケンス番号Ｓを伴うＴＣＰデータセグメントの観察と、（２）Ｓより高い確認番号を伴い逆方向（同じ接続において）に送信されるＡＣＫと、の間の時間を測定することによりＴＣＰ接続のＲＴＴを監視し続ける。この測定は、両方向に行われ、即ち各接続に対して、ＣＥエージェントは、下流セグメントに対するＲＴＴ（ＤＬにデータを送信する接続において測定された）及びアップリンクセグメントに対するＲＴＴ（ＵＬデータ送信において測定された）を維持する。ＴＣＰ ＲＴＴを測定するためにＣＥエージェントが使用する付加的なメカニズムは、ＴＣＰ受信器により送られる複写ＡＣＫと、ＴＣＰ送信者から発せられる第１の再送信との間の時間を測定する。ＴＣＰを越えてのＤＬデータ送信のケースでは、このメカニズムは、第１のＵＬ複写ＡＣＫと、それに対応するＤＬ再送信との間のＵＬ ＲＴＴを測定するのに使用される。ＵＬデータ送信のケースでは、このメカニズムは、ＤＬ ＲＴＴ測定を行う。ＴＣＰベースのＲＴＴ測定に加えて、ＣＥエージェントは、対応するＨＴＴＰ要求と応答メッセージとの間の時間を測定することによりＨＴＴＰレベルＲＴＴを測定する。ＲＴＴの測定は、ユーザプレーン及び制御プレーンの両方に確認又は要求・応答メカニズムを有する他のアプリケーション又はトランスポートレイヤプロトコルの場合に可能である。更に、ＤＮＳ ＲＴＴは、ＤＮＳ質問と応答ＵＤＰパケットとの間で測定され（ユーザプレーン）、そしてＲＴＴは、ＳＣＴＰレベルにおいて（ＨＥＡＲＴＢＥＡＴ及びＨＥＡＲＴＢＥＡＴ ＡＣＫ、制御プレーン）及び無線接続確立中のアタッチ要求及びアタッチ容認のような対応する制御プレーンメッセージ間に測定される。

ＣＥエージェントは、各接続におけるシーケンス及びＡＣＫ番号を監視し、そして順序ずれしたセグメント及び複写セグメントの両方を検出することによりＴＣＰ接続におけるロスを測定する。セグメントは、次に予想されるシーケンス内セグメントより高いシーケンス番号を有する場合に測定ポイントに順序ずれして到着する。予想されるシーケンス番号は、最後に受け取ったセグメントのシーケンス番号及びセグメントのサイズを加算することにより計算され、それらは、両方とも、ＴＣＰ／ＩＰパケットヘッダから得られる。順序ずれのセグメントは、上流のネットワークセグメントにおいて１つ以上のロスを指示する。失われたバイトの数は、予想されるシーケンス番号と受け取ったセグメントの番号との間の差を計算することにより直ちに得られ、一方、失われたセグメントの数は、失われたバイトをデータセグメントの平均サイズ（これは、ＣＥエージェントにより測定されプロフィーリングされてもよい）で除算することにより推定される。ＴＣＰ送信者は、失われたセグメントを再送信するので、シーケンスギャップを埋める再送信の数をカウントすることで、失われたセグメントの厳密な数が与えられる。少なくとも１つの端−端ラウンドトリップ時間の後に再送信が生じるとき（即ち、ＴＣＰ送信者がＴＣＰ受信者により送られる複写ＡＣＫ又はＳＡＣＫオプションに基づいてロスに気付くとき）、厳密な上流ロスカウントは、１つのＲＴＴだけ遅れる。しかしながら、ロスそれ自身は、瞬時に検出され、そして失われたパケットの厳密な数も、ＴＣＰメカニズムに依存することにより、できるだけ早く得られる。

ＴＣＰセグメントは、同じセグメント（同じシーケンス番号をもつ）が所与の接続において既に観察され、即ちその再送信がＣＥエージェントの観点から必要でない場合には、ＣＥエージェントにより複写と考えられる。しかしながら、そのような再送信は、下流のネットワークセグメントのどこかにロスがあることを意味する。というのは、そうでなければ、再送信が起きないからである。それ故、不必要な再送信は、下流のロスとしてカウントされる。他のＣＥエージェントにより個々に測定されて状態更新を通して報告される上流及び下流のロスの数を合成することにより、各ＣＥエージェントは、ネットワークセグメントごとのアップリンク及びダウンリンクロス比を得る。このロス比は、パケット及びバイトの両方に対応して表現される。

上述したパケットロスの局所化は、各ＣＥエージェントがＴＣＰセグメント及びＡＣＫを個々に監視して、順序ずれ、再送信及び複写セグメントを検出及び分析することを要求する。しかしながら、ある配備（例えば、ＣＥエージェントの機能が埋め込み型のソフトウェア環境で実行される）では、そのような複雑なフローごとのシーケンス／ＡＣＫ監視に必要な計算リソースの量を入手できない。従って、無線部側ＣＥエージェントは、明確なロス検出を遂行せず、下流ロスの検出及び局所化の両方を行うのは（即ち、無線部側ロスとトランスポートネットワーク側ロスとの間を区別するのは）、中央ＣＥエージェント次第である。しかしながら、無線部側ＣＥエージェントからの明確なロス測定がないと、無線部又はトランスポートネットワークへのロスの局所化は、些細なものではなくなる。その解決策は、そのようなリソース限定の配備シナリオにおいて、無線部側ＣＥエージェントがそれ自身で測定を開始しないことに基づく。むしろ、中央ＣＥエージェントは、無線部側ＣＥエージェントによって測定を遂行すべきことを明確に指令する。これは、ＣＥエージェントが無線部側で（非ロス関連の）測定が実行されることを要求するコマンドでＤＬの各パケットにマークすることを経て実行される。このコマンドは、パケットと共に必要なコンテキスト情報を与えて、無線部側ＣＥエージェントがそのマークされたパケットの到着時に直ちに測定を遂行できるようにする。無線側ＣＥエージェントは、測定結果を、同じフローに対応する次のＵＬセグメントにおいて転送する（コア側ＣＥエージェントにおけるパケットロスの間接的な局所化を示す図１３を参照されたい）。中央ＣＥエージェントは、下流のロスを自律的に検出することができ、中央ＣＥエージェントは、局所化を遂行することができる。ロスの位置の推論は、非ロス関連の測定結果を保持するエンリッチされたパケットがどのようにしてコアへ搬送されるか分析することによって可能となる。中央ＣＥエージェントが、コマンドでエンリッチされたＤＬデータセグメントにおいて測定を遂行するよう無線部側ＣＥエージェントに指令するたびに、その結果は、ＵＥによるＤＬセグメントの受信を確認するＵＬ ＡＣＫセグメントにおいて受信されることが期待される。コマンドを伴うパケット（図１３のセグメント“Ａ”）が無線部側ＣＥエージェントにより受信されたが、パケットが無線部において失われた場合には、セグメント“Ａ”により指令された測定が生成され、そして無線部側ＣＥエージェントに記憶されるが、ＵＥにより転送されるＵＬにはそれに対応するＡＣＫがない。それ故、無線部側ＣＥエージェントは、その後のデータセグメント“Ｂ”がＵＥへ配信されて、保留中の測定結果を搬送するようにＵＬ ＡＣＫをトリガーするのを待機する必要がある。このＡＣＫは、セグメント“Ａ”のロスを指示する複写ＡＣＫである。測定セグメントのロスを指示している複写ＡＣＫにおける“Ａ”に対する測定結果を受け取ることにより、中央ＣＥエージェントは、セグメント“Ａ”が無線側ＣＥエージェントにより依然観察されていることを推論できるが（対応する測定値があるので）、セグメントはＵＥに到着しない。これは、セグメント“Ａ”が無線部側ＣＥエージェントから下流で、即ち無線部において、失われた場合にのみ可能である。同様に、ＣＥエージェントは、セグメント“Ａ”が失われ（複写ＡＣＫ）そしてそれに対応する測定値が第１の適当なＵＬパケットにおいて受信されず、セグメント“Ａ”が無線部側ＣＥエージェントに到着もしていないことを意味することを観察することによりトランスポートネットワーク側ロスを推論することができる。

シーケンス番号に基づくロス検出は、シーケンス番号を含むＴＣＰ接続及び他のプロトコル（おそらくＵＤＰを使用する）に適用できる効率的なメカニズムである（とりわけ、ＵＤＰよりもＲＴＰ）。或いは又、ロス測定について（埋め込み型シーケンス番号を持たない接続の場合）、各パケットは、サーバーから又はクライアントからオリジナルパケットを最初に受信するＣＥエージェントによりパケットごとのシーケンス番号でエンリッチされる。このエンリッチされたシーケンス番号において検出されるギャップは、失われたパケットの数を直ちにそして厳密に与える。

２つのＣＥエージェント間の各ネットワークセグメントにおいて一方ＵＬ及びＤＬ遅延を測定するためにヘッダエンリッチメント技術が使用される。正確な一方遅延測定データを得るには、ＣＥエージェントのクロックを同期する必要があり、これは、ネットワーク時間プロトコル（ＮＴＰ）、高精度時間プロトコル（ＰＴＰ）、又はＧＰＳのような外部メカニズムによって達成される。一方遅延サンプルを得るために、ソースからパケットを受信する第１のＣＥエージェント（例えば、ＤＬのＳＧｉインターフェイスにおけるＣＥエージェント及びＵＬのｅＮＢ側ＣＥエージェント）は、その現在タイムスタンプをパケットヘッダに対してエンリッチする。次のＣＥエージェントは、タイムスタンプを読み取り、そしてそれをそれ自身のクロックと比較して、第１のＣＥエージェントとそれ自身との間の一方遅延を計算する。ＣＥエージェントは、以前のＣＥエージェントによりパケットにおいてエンコードされたタイムスタンプをそれ自身の現在タイムスタンプとスワップした後に、パケットを次のセグメントへ転送する。ＣＥエージェントは、測定サンプルを得ると、その結果を、リアルタイム状態更新の一部分としてタイムスタンプを搬送した同じユーザプレーン接続に到着する次のＤＬ及びＵＬパケットへエンリッチする。一方遅延測定は、図１４において、２つのＣＥエージェントと共にダウンリンク方向に示されている。又、２つのＣＥエージェント間の一方ダウンリンク遅延の協力的測定は、アップリンク方向の一方遅延の測定にも適用される。

パケット転送方向に最後の１つであるＣＥエージェント（例えば、ダウンリンクではｅＮＢ又はアップリンクではＳＧｉインターフェイス）は、エンリッチされたデータをプロトコルヘッダから剥離する。この剥離は、ネットワークセグメントから漏れ出す情報がないことを保証し、エンドホストを混乱させるおそれを排除する。

ＲＴＰ／ＵＤＰストリーミング又はＶｏＩＰ／ＶｏＬＴＥのようなアプリケーション（ＲＴＰも使用する）については、ＲＴＰレベルシーケンス番号がロス検出のために使用される（ＴＣＰシーケンス番号と同様に）。又、上述した一方遅延測定も利用できる。更に、アプリケーションプロフィーリングについては、パケット到着間の時間のパターン及び種々の測定ポイントにおけるジッタの測定がそれらのクオリティの指示を与える。不安定で且つ変動するパターンを測定しそしてプロフィーリングすることにより質低下が検出される。質低下は、検出されたパターンをＣＥエージェント間で交換し、そして２つのＣＥエージェントが境を接するネットワークセグメントであって、（パケット転送方向に）最初のＣＥエージェントが依然安定なパターンを測定し、一方、次のＣＥエージェントが既に変動パターンを検出しているネットワークセグメントを見出すことにより、局所化される。接続の質に関する付加的な情報は、ＵＥにより送られた受信者レポート（ＲＲ）から抽出される。ＶｏＬＴＥのケースのように、会話に参加した両ＵＥは、ＲＲを送信し、両コールレッグの質がこのように監視される。

ＣＥエージェントの協力的測定及びリアルタイム同期は、自然に相関されたＫＰＩを生じる。というのは、同じユーザプレーンパケット又は対応する要求／応答又はデータ／ＡＣＫパケット対を使用して多数のＫＰＩを測定するのと同時に、測定されたＫＰＩを同じ端−端ラウンドトリップ内に分布させるからである。これは、多数のＫＰＩの１つのＲＴＴ相関測定を示す図１５に示されたように、ＣＥエージェントが１つのＲＴＴ内のフローごとの測定を更新することができるようにする。

ＱｏＥ測定は、プロトコルヘッダ及びアプリケーションメタデータ（ＴＣＰ、ＩＰ、ＵＤＰ、ＲＴＰ、ＲＴＣＰ、ＲＳＴＰ、ＨＴＴＰ、等）のコンテンツを抽出／監視し、そしてユーザアクション及び振舞いを検出することにより、ユーザプレーンフローごとに同時に実行される（アプリケーション特有のＱｏＥ測定を示す図１６を参照されたい）。後者は、フロー、セッション又はアプリケーション終了、ユーザ要求開始又は反応時間、自動／スクリプト発生イベントからのユーザ開始要求の分離の検出、挫折した使用パターンの検出、等により行われる。アプリケーションメタデータは、アプリケーション又はセッション特有の情報、例えば、ビデオ／オーディオストリームの解像度、コーデック、フォーマット又はエンコードレート、ウェブページのサイズ及びドメイン、コンテンツのタイプ、構造又は重要性、等を含む。ＱｏＥ測定値は、顧客体験の正確な指示子であるアプリケーション特有の専用ＫＰＩ及び測定値（例えば、ウェブページダウンロード時間、ビデオ再生及び停止時間、等）を含む。

一実施形態において、リアルタイム混雑検出、局所化及びボトルネック分類が実行される。同じ端−端経路を共有するＣＥエージェントは、同じＱｏＥインサイトと、ネットワークセグメントごとのＫＰＩの共有知識とを有するので、各ＣＥエージェントは、混雑を検出し、そしてそれを、定義されたネットワークセグメントの粒度で局所化することができる。混雑は、増加ＲＴＴ／遅延及びパケットロスに基づいて検出される。測定値をコンテキストに入れるために、ＣＥエージェントは、遅延及びロスを各ネットワークセグメントの負荷の関数としてプロフィーリングする。ネットワークセグメントに軽い負荷しか掛からない場合には、著しいパケットバッファが生じず、ネットワークセグメントにおける測定遅延は、システム固有の遅延である（即ち、物理的伝播遅延と、ネットワーク要素、トランスポート装置、等内の処理及び内部転送により付加されるレイテンシーとの和）。負荷が増加しそしてネットワークセグメントが端−端経路内にボトルネックを有するときには、ボトルネックリンクの前のパケットバッファがパケットを累積し始め、ネットワークセグメントにおいて測定される遅延は、ボトルネックバッファにより付加されるキュー遅延のために増加する。バッファがいっぱいの場合には、最大キュー遅延に対応する最大遅延が測定される。バッファが枯渇しない場合には、測定されるスループットが一定であり、ボトルネックリンクの容量に等しい。各ネットワークセグメントの遅延をプロフィーリングすることにより、ＣＥエージェントは、測定値をコンテキストに入れ、そしてネットワークセグメントの遅延増加が負荷増加によるものであるかどうか、従って、ネットワークセグメントが混雑しているかどうかを検出する。図１７は、ネットワークセグメントにおける遅延プロフィールを示す。

又、ＣＥエージェントは、パケットの破棄、及び混雑検出のためのそれらのパターンも監視する。散発的なロス（即ち、破棄と破棄との間に相関性のない単一のランダムな破棄）及び突発的な破棄（即ち、多数の連続するパケットを破棄する）は、異なるケースを示す。散発的な破棄（特にトランスポートネットワークセグメントにおける）は、進歩型キュー管理（ＡＱＭ）メカニズム（ＲＥＤ又はＣｏＤｅｌのような）の使用を示し、これは、バッファ負荷又はキュー遅延が増加するが、バッファには付加的な到来パケットを保持する自由スペースが依然ある場合にランダムな早期破棄を実行するものである。これは、システムリソースが著しく使用されるが、まだ混雑はなく、システムが効率的に使用される場合のセグメントを示す。他方、バッファのオーバーフローから生じる突発的破棄は、混雑の指示である。破棄の強度及び破棄のパターンを検査することにより、ＣＥエージェントは、ネットワークセグメントが過負荷の早期段階（散発的ロス）又は混雑の早期段階（テールドロップ）であるかどうか検出する。

ネットワークセグメントごとのプロフィーリング及び分析の他に、現在のセグメントごとのＲＴＴ／遅延及びロス測定値を端−端ＲＴＴ及びロス測定値と比較することによって混雑も局所化される。端−端ＲＴＴ／遅延及びロスの大半が同じネットワークセグメントの影響を受ける場合には、混雑が優勢なセグメントに局所化される（混雑局所化及び異常値検出を示す図１８を参照されたい）。ＫＰＩのパターン（即ち、このセグメントは、他のもの及び端−端に比して優勢である）は、混雑の位置を直接定義する。測定値及び所与のアグリゲーションレベルのＫＰＩパターン（例えば、単一ベアラ）を、より高いアグリゲーションレベルの測定値（例えば、セル又はｅＮＢレベル測定値）と比較することにより、同様のメカニズムを使用して異常値を検出することができる。低いアグリゲーションレベル（例えば、無線部）に混雑パターンがある一方、高いアグリゲーションレベルにはそのようなパターンがないケースでは、低いアグリゲーションレベルがおそらく個々の問題のために異常値となる。これは、ベアラ／ＵＥレベル無線部側ＲＴＴ／ロス測定値がセルレベル測定値に比して顕著である場合には、所与のＵＥに対する個々の不充分なチャンネルクオリティを検出するのに使用できる。これをトランスポートネットワーク測定値に適用すると、混雑の蓄積が、特定のＤＳＣＰコードポイント（区別されたサービスＩＰ ＱｏＳアーキテクチャーの場合）又は４ｐビット（イーサネット（登録商標）ＩＥＥＥ８０２．１ｐ ＱｏＳアーキテクチャーの場合）において検出される。混雑パターンは、通常、低プライオリティのトラフィックを表わすアグリゲーションレベルにおいて表示を開始する。というのは、それに対応するパケットが長いキュー遅延又は破棄を最初に経験するからである。

混雑の検出は、リアルタイムであり、そしてそれは、遅延／ロス測定値が問題を指示するや否や即座に起きる。ＣＥエージェントは、プロトコルヘッダエンリッチメントを使用して、個々の測定を他の関連ＣＥエージェントに同期させるので、検出のレイテンシーは、最低の理論的限界にある（即ち、情報は、あるＣＥエージェントから他のＣＥエージェントへインバンドヘッダエンリッチメントよりも急速に通過されることはない。というのは、アウトオブバンドシグナリングは、フロー識別タプルによりインバンドで搬送される自動コンテキスト情報の欠如によりオーバーヘッドが増加しても同じ物理的ネットワーク及びリンクを使用する必要があるからである）。

混雑により生じるＱｏＥ質低下は、ＣＥエージェントにより検出されるか（それらが既に起きていてユーザに見える欠陥として示される場合）又は予想される（短い時間フレーム内に現在環境の下で質低下が生じる場合）。予想は、ＵＥのプレイアウトバッファをモデリングし、そしてＵＥが更なるデータをダウンロードするようにアクティブに試みるにも関わらず事前にバッファされたデータの量が減少することを検出することにより、例えば、（ＹｏｕＴｕｂｅ（登録商標）のような通常のビデオサイトにより使用される）進歩的ＨＴＴＰダウンロードを使用するビデオダウンロードの場合に可能である。このプレイアウトバッファは、アプリケーションセッション特有のビデオ属性（時間巾、メディアレート）を検出し、そしてダウンロードの開始からどれほど多くのデータがＵＥによりダウンロードされて確認されたか追跡することによりモデリングされる。プレイアウトバッファが枯渇するたびに、ＵＥのビデオ再生が停止して、ＱｏＥ質低下を引き起こす。ＵＥに見える質低下は、ＱｏＥインシデントと称される。ＱｏＥインシデントは、アプリケーション特有である。ウェブブラウジングの場合、ＱｏＥインシデントは、低速ウェブページダウンロード又は低速ＤＮＳ分析であり、バルクデータ転送の場合、ＱｏＥインシデントは、ＴＣＰが多数の連続する時間切れで悩まされるか又はスループットが所要最小レートより下がったときである。ＱｏＥ質低下によりダウンロードをおそらく中止するユーザも、ＱｏＥインシデントである。又、ＱｏＥインシデントの付加的なトリガーがＣＥエージェントにより実施される。ＣＥエージェントは、ＱｏＥ問題が混雑により生じるのではなくＵＥ制限のような他の理由で生じるかどうか自動的に認識することができる。ＵＥ制限は、所与のＵＥのＱｏＥ問題がアップリンクＴＣＰ ＡＣＫで送信される小さな又はゼロＴＣＰの広告窓と相関して、ＵＥのアプリケーションがデータの受信と同程度の速さでデータを処理できないことを指示する場合に、検出される。

搬送混雑が検出された場合には、ボトルネックネットワークセグメントの利用可能な帯域巾が、そのセグメントを共有する接続の累積的スループット測定によって与えられる。又、スループット測定と、固有遅延より高い測定遅延の部分との合成で、ボトルネックリンクの前のネットワークバッファのサイズが定義される。ＣＥエージェントが、物理的／論理的リンクを伴うトポロジーデータベース、及び混雑したネットワークセグメントを作り上げるそれらの各容量を有する場合には、測定で得られるスループットとほぼ同じ容量を有するリンクを選択することにより更なる局所化が可能である。

又、遅延、スループット及びロスパターンを分析することにより、ＣＥエージェントは、制限を生じるシェーパー又はポリサーがあるかどうか検出し、そしてボトルネックを更に分類することもできる。シェーパーの場合には、スループットがシェーピングレートに絞られるまでバーストの送信が許されるために、瞬間的に測定されるスループットがシェーピングレートを越えることがある。破棄は、おそらく、（バッファがいっぱいになったとき）遅延増加期間の後に生じ、そしてそれらは、（バッファオーバーフローのために）バーストで生じる。ポリサーの場合には、構成されたポリサーレートに適合しないパケットが破棄される。従って、ポリサー要素の後に測定されるスループットは、所与のスレッシュホールドを決して越えない。ロスは、よりランダムで、必ずしも遅延の蓄積と相関しない。又、ＣＥエージェントは、ＡＱＭの構成が不充分なバッファも検出する。構成が不充分なＡＱＭは、散発的なランダム破棄の持続レベルをトリガーし、これは、バッファが著しいキュー遅延を付加するのを防止し（従って、ネットワークセグメントにおける遅延を低く保ち）、同時に、ＴＣＰ接続が高いスループットに到達するのを防止する。というのは、それらが常に混雑回避へ強制されるからである。又、遅延、ロス及びスループットのパターンの他に、遅延分布のモーメント及び統計学的パラメータも、ＣＥエージェントにより監視され、そしてボトルネック分類に使用される。特に、遅延分布の正のスキュー（遅延分布のスキューを示す図１９を参照）は、大半のパケットに対して長いキュー遅延を生じるときに大きなバッファと共にボトムネックリンクを有することの良好な指示子である。

ＱｏＥインシデントの頻度及び強度は、厳格さの定量化又は混雑の影響を与え、これは、対抗策又は修正アクションにおいて判断するための基礎として取り上げられる。又、搬送混雑の厳格さは、高プライオリティトラフィックがどれほど影響を受けるかに基づいて量子化される。正確な局所化（例えば、無線及び搬送混雑間の区別）、及びＣＥエージェントにより与えられる個々の問題又はセル／ｅＮＢレベル問題の検出は、適切なアクションを選択する上で必須である。不充分なチャンネルクオリティによるＱｏＥ問題は、（例えば、メディア適応により）影響のあるＵＥを特に取り扱う集中アクションを要求する。無線部側混雑は、ベアラのプライオリティ決め又は格下げ、或いはＵＥごと、アプリケーションごと又はフローごとの帯域巾管理により解消される。搬送混雑は、混雑制御アクションを要求するか、或いは又、トランスポートスケジューラにおける重み最適化、帯域巾管理／シェーパー再構成又は容量増加を要求する。混雑が検出されると、ＣＥエージェントは、アプリケーションの望ましい帯域巾、及び最適状態に到達又は近付くことのできる対応する無線及び搬送構成を含む最適な状態（即ち、ベアラＱｏＳパラメータ、重み構成、シェーパーレート、容量割り当て、等）も計算する。現在状態と最適状態との間の相違を知ることで、ＣＥエージェントは、ベアラのプライオリティ決め、帯域巾の絞り、ＳＤＮを経てのトランスポートサービス提供、又はトランスポート装置における重み再構成のような正しい介入程度又は介入量で適切なネットワーク最適化アクションを示唆又はトリガーすることができる。ＣＥエージェントは、アクションをトリガーするために外部エンティティ（混雑制御メカニズム、ネットワーク最適化又は管理エンジン、ＳＤＮコントローラ、ＰＣＲＦ／ＰＣＥＦ、等）へ情報を与えることができる。

更に、ＣＥエージェントは、それが収集するＫＰＩのコンステレーションをプロフィーリングする。プロフィーリングの結果は、ネットワーク要素又は端−端コンテキスト（例えば、Ｓ１／Ｘ２インターフェイス）が有する状態のセットである。これは、低負荷状態、異なるタイプの高負荷状態及び混雑状態を含む。又、最小遅延又はレイテンシー、有効最大遅延値、及び混雑下の容量のようなノード又はコンテキスト特有の固有パラメータが収集される。後者は、無線インターフェイス及びＳ１インターフェイスの両方において変化する。無線容量は、ユーザ位置及び移動の関数として変化し、一方、混雑下の搬送容量は、ｅＮＢが他のネットワーク要素と共にアグリゲーションリンクを共有する場合には、異なる値をとり得る。精巧なネットワーク及びトラフィック管理アクションを可能にするために、（例えば、経路スイッチ又は他の異常による）既知のＫＰＩパターン／有効状態からの偏差も検出される。

一実施形態において、配備特有アーキテクチャー、オペレーション及び能力が開示される。プロトコルヘッダ（例えば、ＴＣＰ／ＩＰ／ＧＴＰ）を経ての協力測定及びリアルタイム状態更新のために実施オプションが提供される。ＣＥエージェントのために多数の配備オプションがあり、異なる測定範囲、粒度、及びアグリゲーションの可能性を生じる。更に、ＣＥエージェントのアーキテクチャー及びオペレーション（例えば、情報のソース）は、配備シナリオに特有なものである。例えば、ＬＴＥ関連の配備及び３Ｇ ＢＴＳ／ＲＮＣ特有の実施が開示される。ＬＴＥにおいて、考えられる配備は、ｅＮＢ側ＣＥエージェントのみであり（分散型無線部側ＣＥエージェント配備を示す図２０を参照）、ここで、ＣＥエージェントは、ｅＮＢで実行され又はそれにアタッチされる（例えば、ＢＳにおいて、又はＲＡＣＳのアプリケーションとして実施される）。ｅＮＢ／ＲＡＣＳ側ＣＥエージェントは、個々に、ネットワークの無線部側及びコア側部分を別々に監視し、並びにＸ２トラフィックを検出し及びＸ２を経て転送されるユーザプレーンパケットにおいて協力的測定を実行することができる（例えば、一方Ｘ２の転送遅延を測定するタイムスタンプ）。更に、ＣＥエージェントは、アプリケーションセッションのＱｏＥを個々に測定することができる。

コア側のスタンドアローン配備も、ＣＥエージェントがコアネットワーク要素（例えば、ＳＧＷ／ＰＧＷ）の一部分として又はスタンドアローン中間ボックスとして配備されるときの実現可能な代替物である（コア側スタンドアローンＣＥエージェントエージェント配備を示す図２１を参照）。コア側のＣＥエージェントは、外部ネットワークセグメント及び運営者のネットワークセグメントを別々に測定することができる。又、ＳＧＷ側ＣＥエージェントは、ｅＮＢごとのトラフィックを別々に監視することもできる。更に、ネットワークトポロジーデータベースが利用できるか又は適当なヒューリスティックが使用される場合には、ＳＧＷ側ＣＥエージェントは、ｅＮＢ間の測定を相関させ、そして多数のｅＮＢにおける混雑が（例えば、共有トランスポートネットワークリンクにより）或いは個々の最終マイル又は無線部側制限により関係しているかどうか検出することができる。

ＣＥエージェントの合成配備は、ｅＮＢごとのインスタンス及びコア側要素をもつことである（合成ＣＥエージェント配備を示す図２２を参照）。ＣＥエージェント間の協力的測定のために、コアネットワークセグメント及び外部ネットワークに対して、ｅＮＢ無線インターフェイス、Ｘ２インターフェイス、Ｓ１インターフェイスごとに測定値が生成される。Ｘ２関連の測定値（ターゲットｅＮＢのトラフィックを監視するＣＥエージェントにおいて生成される）は、リアルタイムＣＥエージェント状態更新の一部分として上流に送られ、それ故、コア側インスタンスは、他のセグメントに相関されるＸ２セグメントのビューも有する。又、ＳＧＷ側ＣＥエージェントは、Ｓ１インターフェイスにおけるＧＴＰ／ＵＤＰ／ＩＰプロトコルスタックの一部分であるｅＮＢ ＩＰアドレスに基づきリアルタイムでｅＮＢレベルにおいてベアラ及びＵＥを局所化することもできる。Ｓ１インターフェイスにＩＰｓｅｃが使用される場合でも、ＣＥエージェントは、依然、（外部ＩＰアドレスのコンテンツに基づいて）ｅＮＢごとＤＳＣＰごとの測定を遂行することができる。

又、合成配備において、ｅＮＢ側ＣＥエージェントは、ユーザの移動をリアルタイムで検出し、そしてユーザの位置をネットワーク側情報としてコア側ＣＥエージェントに又は付加的な又は外部の情報受信者へ与えることができる。又、位置情報に加えて、ｅＮＢ側のＣＥエージェントは、ベアラ属性を転送することもできる（ｅＮＢに対してローカルな構成、例えば、ベアラに対して構成されたＱＣＩ重み（ｗＱＣＩ）、並びに標準的パラメータ、例えば、ベアラのＱＣＩ／ＧＢＲ／ＭＢＲを含む）。図２３は、インラインコア側ＣＥエージェント対タッピングコア側ＣＥエージェントを示す。コア側ＣＥエージェントは、（例えば、インバンドヘッダエンリッチメントに対して）パケットを変更できることを意味するインラインネットワーク要素、又はデータストリームのリードオンリコピーのみを受け取るタッピングネットワーク要素である。後者の配備は、運営者がコア側に付加的なネットワーク要素を含ませる気にならない場合に該当する。しかしながら、この場合でも、コア側ＣＥエージェントは、依然、無線部側ＣＥエージェントから情報をインバンドで効率的に受け取り、従って、ネットワークとのセグメントごとの精度を有することができる。

ｅＮＢ側ＣＥエージェントがＲＡＣＳにおけるアプリケーションとして実施される場合には、付加的な無線部側情報（例えば、無線チャンネルクオリティ、タイミング進み、等）並びにセル／セクタレベル移動及び位置情報（明確なハンドオーバー通知及びグローバルセルＩＤ）へアクセスすることができる。ＣＥエージェントは、これらの情報断片をコアネットワークへ転送して、コア側ＣＥエージェント又は他のエンティティを、正確な無線部側又は位置情報でエンリッチすることができる。

図２４は、３Ｇ ＢＴＳ／ＲＮＣ特有のＣＥエージェント実施を示す。ＣＥエージェントは、ＲＮＣに配置され、ユーザプレーン、無線部側、並びにｌｕｂ及びｌｕｒトランスポートにおいてインサイトを収集することができる。ＢＴＳ側ＣＥエージェントは、協力的測定及び３Ｇ ＢＴＳからＲＮＣ側ＣＥエージェントへの上流情報を可能にするために軽いサポート的役割を果たす任意の相対物である。

ＲＮＣ側ＣＥエージェントは、Ｅ−ＤＣＨデータフレームのＦＳＮを監視することによりフレームレベルにおいてＵＬロスを直接検出することができる。各Ｅ−ＤＣＨフレームは、多数のＭＡＣ−ｉｓ ＰＤＵを搬送することができる。それ故、単一のフレームロスは、多数のＭＡＣ−ｉｓ ＰＤＵロスを指示することができる。ＤＬロスは、ＲＬＣプロトコルレイヤにおいてＲＮＣ側ＣＥエージェントに見え（確認モードが構成される場合に）、これは、ＵＥのＲＬＣ ＡＭエンティティにより送られる状態ＰＤＵにおいて否定的確認により指示される。しかしながら、ＲＬＣ ＰＤＵのどの部分が失われたかの情報は得られず、それ故、ＲＬＣベースのＤＬロス検出の粒度は、限定される。失われたＤＬ ＲＬＣ ＰＤＵは、ＲＮＣ側ＲＬＣエンティティにより再送信される。パケットロスに加えて、ＲＬＣタイマーがＲＮＣにおいて時間切れする場合にも再送信が生じる。これらのイベントは、ベースステーションから受け取られる対応する状態ＰＤＵ（従って、否定的ＡＣＫ）を伴わずにＰＤＵの再送信の検出を経てＲＮＣ側ＣＥエージェントにより確認される。タイマーの時間切れは、レイヤ２ ＲＴＴが時間間隔を越えることを指示する。従って、ｌｕｂには異常に大きな遅延が生じる。又、ＲＬＣリセットメッセージがＣＥエージェントにより検出され、それらは、対応するＵＥに対する無線プロトコルスタックの完全な崩壊を指示する。リセットが単一のＵＥに影響するだけの場合には、これは、おそらく、個々の無線チャンネル問題によるものである。リセットが同じベースステーションにおいて著しい数のＵＥに対して同時に生じる場合には、おそらく、共通の異常が存在する（極端なｌｕｂ混雑のような）。３Ｇベースステーションは、ＵＬドロップ指示メッセージを経て３Ｇベースステーションそれ自体により破棄されるＰＤＵについてＲＮＣに通知する。それらＰＤＵのコンテンツは、３Ｇベースステーションにおいて利用でき、そしてメッセージにおいてＲＮＣへ指示される。この情報ソースは、３Ｇ ＢＴＳ側ＣＥエージェントの支援なしに利用できる。ｌｕｂトランスポートにおけるより正確なＤＬロス検出をサポートするために、３Ｇ ＢＴＳ側ＣＥエージェントは、ＦＳＮ監視を経てＨＳ−ＤＳＣＨデータフレームロスを検出し、そしてそのロスをＲＮＣ側ＣＥエージェントに報告する。ＢＴＳ及びＲＮＣ側ＣＥエージェントは、（予備の拡張物を使用して）ｌｕｂフレームプロトコルにおいてヘッダエンリッチメントを経て効率的に通信する。各ＨＳ−ＤＳＣＨフレームは、多数のＭＡＣ−ｄ ＰＤＵを搬送し、それ故、単一のフレームロスが多数のＭＡＣ−ｄ ＰＤＵロスを指示する。

ｌｕｂノード同期手順は、各３Ｇ ＢＴＳとのｌｕｂインターフェイスにおいてＲＴＴを得るためにＲＮＣ側ＣＥエージェントにより利用される。この手順の間に、ＲＮＣは、ＲＮＣ特有の時間指示を搬送するＤＬノード同期メッセージを送信する。この時間指示は、ＵＬノード同期メッセージにおいて３Ｇ ＢＴＳによりエコー処理される。このＵＬメッセージの受信と、ＲＮＣにおけるオリジナルメッセージの送信との間の時間差が、ＲＴＴ測定値与える。

３Ｇ ＢＴＳ側ＣＥエージェントは、ＨＳ−ＤＳＣＨデータフレームにおけるＤＲＴを監視することにより遅延の増加又は減少（即ち、ジッタ）を検出することができる。ＤＲＴは、ＲＮＣが１ｍｓ精度でフレームを送信するときに時間をエンコードする。しかしながら、ＤＲＴは、相対的なカウンタに過ぎず、絶対的なタイムスタンプではないので、３Ｇ ＢＴＳ側ＣＥエージェントは、それらを使用して、フレーム内のＤＲＴ間の差を計算し、そしてそれを、ＢＴＳにおけるフレームの測定された到着間時間と比較するだけである。測定された到着間時間がＤＲＴ間の差より大きい場合には、ＤＬにおいてｌｕｂインターフェイスに遅延増加があり、さもなければ、遅延が減少する。ＤＲＴでの演算は、モジュロ４０９６０で行われる。時間に伴うジッタの累積を３Ｇ ＢＴＳにおいて使用し、ｌｕｂインターフェイスにおいて相対的なＤＬ遅延を追跡することができる。３Ｇ ＢＴＳ側ＣＥエージェントが、ＤＬデータフレームで受け取られた最後のＤＲＴを（予備の拡張物として）各ＵＬ Ｅ−ＤＣＨデータフレームへエンリッチする場合には、ＲＮＣ側ＣＥエージェントが高い粒度のｌｕｂ ＲＴＴ測定値を得る。しかしながら、ｌｕｂインターフェイスにおける明確な一方遅延測定値は、ＲＮＣ及びｅＮＢのクロックが同期されそしてタイムスタンプがＲＮＣ側ＣＥエージェント（ＤＬにおける）及び３Ｇ ＢＴＳ側ＣＥエージェント（ＵＬにおける）によりデータフレームのヘッダへエンリッチされる。

ＭＡＣ−ｄフローレベルにおいてＦＰレイヤから収集された遅延／ジッタ及びロス測定データは、ユーザプレーントラフィックフローと相関されるべきである。相関は、Ｅ−ＲＮＴＩ（Ｅ−ＤＣＨ及びＨＳ−ＤＳＣＨデータフレームにおける）又は専用Ｈ−ＲＮＴＩ（ＨＳ−ＤＳＣＨデータフレームにおける）一時的ＵＥ特有識別子を通して行うことができる。Ｅ−ＲＮＴＩ及びＨ−ＲＮＴＩは、無線ベアラ設定手順の間にＲＮＣにより割り当てられる。（ＲＡＢ ＩＤで識別される）無線ベアラは、ＲＮＣとＵＥとの間でユーザプレーントラフィックを搬送する。無線ベアラは、（ＧＴＰ ＴＥＩＤで識別される）コアネットワーク（ＣＮ）ベアラに接続され、ＲＮＣとＳＧＳＮ／ＳＧＷとの間でトラフィックを搬送する。ＲＮＣにおいて、ＲＡＢ ＩＤとＧＴＰ ＴＥＩＤとの間に１対１のマッピングがあり、そしてＥ−／Ｈ−ＲＮＴＩとＲＡＢ ＩＤとの間にもマッピングがある。ＦＰレイヤから生じる測定値をＵＥ ＩＰフローと相関させるために、ＩＰフローと、それに対応するＣＮベアラとの間のＲＮＣ側ＣＥエージェントによりマッピングが維持される。マッピングは、コアネットワークから到着するユーザプレーンパケットにおいてＧＴＰヘッダのＧＴＰ ＴＥＩＤ及び内部ＩＰヘッダのＵＥ ＩＰを観察することにより確立される。マッピングは、ＵＥ ＩＰ、ＧＴＰ ＴＥＩＤ、ＲＡＢ ＩＤ、Ｅ−／Ｈ−ＲＮＴＩ間接的チェーンを経てＵＥ ＩＰフローとＦＰレイヤ測定との相関を可能にする。

ＲＮＣにおいて、ＣＥエージェントは、電力制御測定及びＵＥごとの無線チャンネル状態を含めてＲＲＭへアクセスする。又、ＲＮＣ側ＣＥエージェントは、３Ｇ ＢＴＳからＲＮＣへのＥ−ＤＣＨ ＵＬデータフレームにおいて搬送されるＨＡＲＱ失敗指示メッセージを聴取することを経てＤＣＨチャンネルのＨＡＲＱ失敗（及び対応ユーザに対する不充分な無線チャンネルクオリティの指示）を明確に検出することもできる。失敗指示メッセージは、対応するＵＥの識別を可能にする情報を搬送する。

３Ｇ ＢＴＳは、ＢＴＳにおけるバッファオーバーフローを防止するという目的でフロー制御メカニズムを有する。無線バッファの状態に基づき、３Ｇ ＢＴＳは、それがｌｕｂインターフェイスを通して送信することが許されたデータの量についてＲＮＣに通知する。その情報は、量子化され、そしてＭＡＣ−ｄ ＰＤＵ（ＴＹＰＥ−１ ＨＳ−ＤＳＣＨデータフレーム、固定ＭＡＣ−ｄ ＰＤＵサイズ）又はデータバイト（Ｔｙｐｅ−２ ＨＳ−ＤＳＣＨデータフレーム、柔軟性ＭＡＣ−ｄ ＰＤＵサイズ）のいずれかに対応するクレジットとして表わされる。クレジットには、スケジューリングプライオリティインデックス（ＳＰＩ）と称され、ｌｕｂフレームにＣｍＣＨ−ＰＩフィールドとしてエンコードされるフロープライオリティの粒度が割り当てられる（１６個の考えられるクラスを伴う）。クレジットは、容量割り当てｌｕｂ制御メッセージを経てＲＮＣへ搬送される。フロー制御メカニズムに加えて、３Ｇ ＢＴＳは、ＨＳＤＰＡ混雑制御も実施する。混雑は、遅延蓄積及び／又はフレームロスの検出を経てＢＴＳにおいて検出される。混雑の緩和は、同じクレジット割り当てメカニズムに基づき、そして混雑は、クレジットの減少を生じる。この場合に、容量割り当てメッセージは、フロー制御又は混雑制御のいずれかにより割り当てられる最小のクレジットを搬送し、即ち混雑制御は、フロー制御メカニズムの割り当てを越えてクレジットを減少させる。更に、容量割り当てメッセージは、３Ｇ ＢＴＳにより検出されたＤＬ混雑状態（混雑、遅延蓄積又はフレームロスがない）も搬送する。クレジット割り当ての監視は、ＲＮＣ側ＣＥエージェントが無線インターフェイス混雑を検出し（ＤＬ混雑指示なしにクレジットが減少される場合）、そしてｌｕｂ ＤＬ搬送混雑の明確な検出（混雑指示に基づく）を行えるようにする。クレジット割り当ては、プライオリティクラスごとにｌｕｂにおける利用可能な帯域巾の量を明確に指示する。ＵＬ ｌｕｂ混雑は、Ｅ−ＤＣＨデータフレームにおける遅延及びロスを監視することによりＲＮＣそれ自体によって検出される。

又、ＣＥエージェントは、ｌｕｒ（即ち、ＲＮＣ間のインターフェイス）を監視して、ＲＮＣ間ソフトハンドオーバー及びＳＲＮＣリロケーションを検出する。ｌｕｒは、ｌｕｂ ＦＰと同様に、サービングＲＮＣ（ＳＲＮＣ）とドリフトＲＮＣ（ＤＲＮＣ）との間にフレームプロトコルを使用し、それ故、上述したｌｕｂ測定メカニズムは、ｌｕｒインターフェイスにも適用できる。

図２５は、Ｗｉ−Ｆｉ特有のＣＥエージェント実施を示す。Ｗｉ−Ｆｉ及び３ＧＰＰネットワーク統合のケースでは、ＣＥエージェントに対して考えられる位置が、Ｗｉ−ＦｉＡＰそれ自体、Ｓ２ＧＷ、ＰＧＷ及びコアネットワークである。Ｓ２ＧＷは、Ｓ２ａインターフェイスにおいてＰＧＷに向かうＧＴＰトンネルを終了し、そして（ＰＧＷによりシグナリングされるＵＬ ＴＦＴを経て）ユーザＩＰフローとＧＴＰトンネルとの間の相関性を維持する。Ｓ２ＧＷ及びＰＧＷのＣＥエージェント間の測定は、ＧＴＰベースのＬＴＥ Ｓ１インターフェイスに基づくＧＴＰでの測定と同様である。Ｗｉ−Ｆｉ ＡＰ側ＣＥエージェントは、ユーザＩＰフローレベルでの測定を遂行することができ、これは、Ｓ２ＧＷ ＣＥエージェントにより収集されてＧＴＰベースの測定と相関される。

一実施形態において、エンリッチメントの実施では、協力的測定及びリアルタイム状態更新のための通信は、ユーザプレーンパケットのインバンドヘッダエンリッチメントを経て遂行される。これは、情報の全コンテキスト（例えば、フローアイデンティティ、タイミング、等）がパケットそれ自体により自然に搬送されるので、ユーザプレーン接続それ自体に関連した情報を交換するための効率的なメカニズムである。エンリッチメントに適したプロトコルヘッダは、ユーザプレーンにおけるＴＣＰ及び／又はＩＰであり、これらは、両方とも、オプションフィールド（ヘッダ拡張を行う各アプリケーションにより共有される付加的な４０バイト）の使用を可能にする。又、予約されたビット又はＩＰ ＤＳＣＰフィールドも、それが他の使用ケースと衝突しなければ、使用してもよい。更に、ＲＴＰヘッダは、実際的な関連性を有するＵＤＰデータトラフィックの大部分をカバーする付加的な情報を含ませるための標準的手段も与える。又、Ｓ１／Ｓ５／Ｓ２ａインターフェイスにおいて、ＧＴＰ−Ｕパケットは、標準的なＧＴＰ拡張メカニズムを経て付加的な情報でエンリッチされる。ｌｕｂ／ｌｕｒインターフェイスにおいて、フレームプロトコルは、いわゆる予備的拡張の形態で付加的データをヘッダに含ませるための効率的なメカニズムを与え、これは、ルーターにおける処理オーバーヘッドのためにＩＰヘッダエンリッチメントより好ましい。

エンリッチされたプロトコルヘッダに関わらず、エンリッチメント（及び種々のプロトコルフィールドにおいて順次に要求される変化、例えば、サイズ、オフセット、チェック和）は、高い効率を得るためにハードウェア又はファームウェア（例えば、ネットワークカード又は専用ネットワークプロセッサ）で部分的に又は完全に遂行される。

一実施形態において、制御プレーン測定が実行される。ＣＥエージェントの能力は、制御プレーンにおけるパケット監視を含む。図２６は、ＬＴＥ Ｓ１−ＭＭＥインターフェイスにおける制御プレーン測定を示す。ＣＥエージェントが、ｅＮＢとＭＭＥ（Ｓ１−ＭＭＥインターフェイス）との間、又はＳＡＷ−ＧＷとＭＭＥ（Ｓ１１インターフェイス）との間で交換される制御プレーンパケットにアクセスできる位置に配備される場合には、ＣＥエージェントは、制御プレーンパケットに対してＱｏＳ測定を遂行することができる。ＳＣＴＰベースのＳ１−ＭＭＥインターフェイスにおいて、図２６ａに示したように、ＳＣＴＰレベルの「ハートビート」及び「ハートビートＡＣＫ」メッセージを使用して、ｅＮＢ側及びＭＭＥの両方に向かって制御プレーンＲＴＴを測定することができる。これらのＳＣＲＰメッセージは、Ｓ１−ＡＰメッセージ部分を搬送せず、それ故、測定されたＲＴＴは、ｅＮＢ及びＭＭＥの制御プレーン処理負荷に依存しない。Ｓ１−ＡＰメッセージを搬送する制御プレーンメッセージ交換を使用してＲＴＴを測定することにより、ネットワーク要素の処理負荷及び付加的なシグナリングオーバーヘッドに依存する制御プレーンＲＴＴを得ることができる。制御プレーンＲＴＴの測定に加えて、ＣＥエージェントは、ＭＭＥからｅＮＢへ送られる傍受されたＳ１−ＡＰ初期コンテキスト設定要求メッセージからベアラごとのＱｏＳパラメータ（ＤＬ／ＵＬのＱＣＩ、ＡＲＰ、ＧＢＲ、ＤＬ／ＵＬのＭＢＲ、ＤＬ／ＵＬのＵＥ−ＡＭＢＲ）をパースすることができる。ＵＥがネットワークにアタッチしそしてそのデフォールトベアラを確立するのにどれほど時間が掛かるか測定するには、Ｓ１−ＡＰ初期ＵＥメッセージ（アタッチ要求）と、Ｓ１−ＡＰ初期コンテキスト設定要求（アタッチ受け容れ）メッセージとの間のレイテンシーを測定する必要がある（図２６ｂを参照）。多数の進行中のパラレルなアタッチ手順間を区別するため、対応メッセージの識別が、ｅＮＢ内のＳ１インターフェイス上でＵＥ関連性を独特に識別するｅＮＢ ＵＥ Ｓ１ＡＰ ＩＤに基づいて行われる。

制御プレーン性能（例えば、接続又は他のシグナリング手順の完了時間）と、ベアラが完了した後にデータを送信するアプリケーションに対して測定されたＱｏＥとの相関性により、ユーザの全体論的ＱｏＥを得ることができる。ネットワークへの接続が完了するのに長時間を要する場合には、ユーザプレーンの性能及びデータアプリケーションのＱｏＥがその後良好であっても、ユーザの全ＱｏＥが依然不充分である。この場合、ユーザプレーン及び制御プレーン測定の相関性が全ＱｏＥ質低下の理由を与える。又、どの制御プレーントランザクションに対してメッセージ交換を完了するのに通常長時間を要するか、又はどのネットワーク要素が長い応答時間で応答するかチェックすることにより、根本的な原因が自動的に導出される。最小応答時間の測定は、シグナリングの観点から負荷のかからないネットワークで予想される制御プレーン手順の固有のレイテンシーを与える。測定から又はＱｏＳターゲットに対して構築される遅延プロフィールのコンテキストにおける遅延の評価は、高い負荷が接続破棄を招く前に制御プレーン過負荷の早期兆候を捕えるためにおそらく成功であるが完了に通常より長時間掛かる検出手順を可能とする。

一実施形態は、アプリケーション不可知論、多売主及び効率的方法において端−端及び局所化ＫＰＩの関連セットを与えて、種々のネットワーク配備及び技術をサポートすることができる。多数のＫＰＩのコンテキスト的、相関リアルタイム評価は、自動問題局所化及び根本的問題分析を可能とする。更に、ネットワーク側の測定とアプリケーションのＱｏＥとの組み合わせは、ＱｏＥ管理、及びＱｏＥベースのネットワークオペレーションを可能にする。ユーザ振舞いへのリアルタイム相関インサイトは、当該ユーザ、アプリケーション並びにＱｏＥ特有データ及びＫＰＩ（例えば、ユーザアクション、アプリケーション特有メタデータ、ダウンロード時間、アプリケーションレベルレイテンシー、ビデオ停止、再生時間、等）、及びＱｏＳ ＫＰＩ（例えば、スループット、ＲＴＴ、遅延、ジッタ、パケットロス、ＴＣＰ時間切れ、パケット破棄パターン、等）を通して、アプリケーションセッションの属性、顧客の経験及びネットワーク状態（ローカル及び端−端の両方）と共に与えられる。ＫＰＩは、ユーザプレーンパケットが傍受される適当な位置において実行される低コスト、インバンド、トランスポート技術不可知論的アプリケーションレイヤ測定から導出される。顧客体験（ＣＥ）エージェントと称されるエンティティが設けられる。このＣＥエージェントは、ＬＴＥ ｅＮＢ、ＲＡＣＳ、ＨＳＰＡ＋ＢＴＳ、３ＧＢＴＳ、ＲＮＣ、ＳＡＥ−ＧＷ、又は（Ｓ１、Ｇｎ、Ｇｉ又はＳＧｉインターフェイスに配備された）コアネットワークにおけるスタンドアローンネットワーク要素として配備される。

次のものを含むがこれに限定されない多数の使用ケースがサポートされる。リアルタイムアプリケーション検出、ユーザ振舞い、アプリケーション特有の及びＱｏＥの測定は、データフロー、アプリケーションセッションレベル及び任意のより高いアグリゲーション（セル、ｅＮＢ、カバレージエリア、ＲＮＣ、等）レベルにおいて行われる。ＱｏＥは、各アプリケーションに対する当該情報、例えば、再生時間及びビデオの停止回数／期間、ダウンロード時間、並びにウェブ及びチャットアプリケーションのレイテンシー、等を捕獲する専用ＫＰＩを通して査定される。更に、ユーザ振舞いは、コンテキスト（ダウンロードのキャンセル又は部分的にダウンロードされるウェブページのリフレッシュ、等）において監視される。

ＣＥＭ分析は、ＱｏＥ ＫＰＩ及び検出されたＱｏＥ質低下の根本的原因のコンテキスト情報を通して行われる。

ユーザレベル、アプリケーション特有のＱｏＥ及びＱｏＳ測定、混雑検出及び局所化、ボトルネック分類、等から得たインサイトを相関させることにより、改善型異常検出が与えられる。

ネットワーク監視／オペレーション及びトラブルシューティングが行われる。生成されたＱｏＳ／ＱｏＥインサイトは、ネットワークオペレーションツール、ダッシュボード／視覚化、アラーム／レポートシステム、顧客ケア、マーケッティング、等へチャンネル送信される。

レガシーＱｏＳ駆動解決策により要求されるもののスーパーセットを表わすＱｏＳ測定値が与えられる（ＲＴＴ、遅延ターゲット、ロス、スループット、等）。それ故、遅延／ロススレッシュホールドベースのアラーム／アクションのような慣習的なレガシーＱｏＳベースのトリガーも可能になる。

データ転送の効率を改善するため、或いはＱｏＥ、ＱｏＳ、負荷、効率、等、例えば、ＴＣＰ最適化、動的ＱｏＳ管理、帯域巾管理／実施、メディア適応、自己編成ネットワーク使用ケース（例えば、ＭＬＢ）、トランスポートＳＯＮ（Ｔｒａ−ＳＯＮ）、トラフィックステアリング／Ｗｉ−Ｆｉオフロード、混雑制御、等を管理するために、他の進歩型メカニズムにサービスが提供される。

適当な帯域巾管理及びＱｏＳ／ＱｏＥ実施が、進行中アプリケーションセッション、それらの需要又は帯域巾要求、ネットワーク状態、混雑検出及び局所化、等の相関について行われ、構築される。個々のフローレベルに既にあるインサイト及び測定データを収集することで、ＴＣＰトラフィックを終了せずに（即ち、ＴＣＰプロキシーなしに）非侵襲的ＴＣＰ最適化メカニズム（例えば、ＡＷＮＤ管理、ＡＣＫシェーピング）が可能となる。

一実施形態において、多数のＴＣＰ接続及びＨＴＴＰオブジェクトにわたる相関型測定（例えば、近代的なマルチスレッドウェブブラウザにわたるウェブページダウンロードの進行を追跡するため）及び種々のアプリケーションレイヤプロトコル（例えば、同じウェブページダウンロードのユーザ経験に影響するＤＮＳ解像度及びＨＴＴＰレイテンシー）の相関が実行される。測定データは、各アプリケーションプロトコルレイヤにおいて相関的に収集及び配信され、関連測定値間に垂直に（アプリケーションプロトコルを横切って）及び水平に（同じアプリケーションプロトコル内で）リンケージを自然に形成する。

ＵＰＣＯＮ混雑検出のためのメカニズムも開示される。異なるフロー間で又は同じフローの異なるパケット間でも相関検出を行うことのできるインサイトがユーザプレーンアプリケーションに与えられる。ＱｏＥ測定並びにそれらのイネーブラー（例えば、ＨＴＴＰレイテンシー）及びＴＣＰ ＲＴＴが連続的に配信される。

ユーザプレーンパケットそれ自体は、測定を実行するのに使用され、付加的なテストトラフィックを必要とせず、又、測定について交渉するための専用制御セッションも行わない。ユーザプレーンパケットの最上部で測定を実行することにより、結果は、実際の該当するトラフィックに直接対応し、そして人為的に生成される無関係のテストトラフィックには対応しない。又、当該ＰＨＢに対応して（即ち、それらはアクティブに使用され）、構成を必要とせずにネットワーク設定及び変化にそれ自身を自己適応させて、自動的な測定が遂行される。プロトコルヘッダへエンリッチされる付加的なデータは、フルサイズのパケットに比して制限され、従って、付加的なデータに関してオーバーヘッドが低い。

混雑検出メカニズムは、任意の状態の任意のネットワーク（既存のＨＳＰＡシステムも含む）に適用可能である。

一実施形態は、少なくとも１つのプロセッサ、及びコンピュータプログラムコードを含む少なくとも１つのメモリを備えた装置において、その少なくとも１つのメモリ及びコンピュータプログラムコードは、少なくとも１つのプロセッサとで、装置が、前記ネットワーク要素又はネットワークノードの手順を実行するようにさせるよう構成された装置を提供する。従って、少なくとも１つのプロセッサ、少なくとも１つのメモリ、及びコンピュータプログラムコードは、ネットワーク要素又はネットワークノードの前記手順を実行するための手段の実施形態として考えられる。図２７は、そのような装置の構造のブロック図である。この装置は、ネットワーク要素又はネットワークノードで構成され、例えば、装置は、ネットワーク要素又はネットワークノードのチップセット又は回路を形成する。幾つかの実施形態において、装置は、ネットワーク要素又はネットワークノードである。装置は、少なくとも１つのプロセッサを含む処理回路１０を備えている。処理回路１０は、ネットワークに送信されるユーザプレーントラフィックフローを監視して、選択されたデータパケットに対して測定を遂行するよう構成されたフローモニタ１６を備えている。処理回路１０は、更に、ユーザ測定データ、アプリケーション測定データ、経験クオリティ測定データ、ネットワーク側サービスクオリティ測定データ、及び１組の重要業績指示子（ＫＰＩ，key performance indicator）のうちの１つ以上を相関的な監視に基づいて収集するように構成された測定データコレクタ１８を備えている。測定データコレクタ１８は、上述したように、相関収集を遂行し、そして収集されたデータ／指示子に関する情報をインサイトジェネレータ１２へ出力するように構成され、ここで、インサイトジェネレータ１２は、顧客体験に対するリアルタイム相関インサイトを生成するように構成される。更に、装置は、顧客体験に対して生成されたリアルタイム相関インサイトをネットワーク運営者及び／又は別のネットワークノードに指示するよう構成されたインサイト指示子１４を備えている。

処理回路１０は、回路１２から１８をサブ回路として含んでもよいし、又はそれらは、同じ物理的処理回路により実行されるコンピュータプログラムモジュールとして考えられてもよい。メモリ２０は、回路１２から１８のオペレーションを特定するプログラムインストラクションより成る１つ以上のコンピュータプログラム製品２４を記憶する。メモリ２０は、更に、例えば、トラフィックフロー監視のための定義を含むデータベース２６を記憶する。更に、装置は、ターミナル装置との無線通信能力を装置に与える通信インターフェイス（図２７には示さず）も備えている。この通信インターフェイスは、ワイヤレス通信を可能にする無線通信回路を備え、そして高周波信号処理回路及び基本帯域信号処理回路を備えている。基本帯域信号処理回路は、送信器及び／又は受信器の機能を実行するように構成される。幾つかの実施形態において、通信インターフェイスは、少なくともアンテナを含むリモート無線ヘッド、及びある実施形態では、ベースステーションに対するリモート位置の高周波信号処理に接続される。そのような実施形態では、通信インターフェイスは、高周波信号処理の幾つかだけを実行するか、又は高周波信号処理を全く実行しない。通信インターフェイスとリモート無線ヘッドとの間の接続は、アナログ接続でも、デジタル接続でもよい。幾つかの実施形態では、通信インターフェイスは、ワイヤード通信を可能にする固定通信回路を含む。

本明細書で使用する「回路」という語は、次のもの、即ち（ａ）アナログ及び／又はデジタル回路のみにおける実施のようなハードウェアのみの回路実施；（ｂ）回路及びソフトウェア及び／又はファームウェアの組み合わせ、例えば、（該当すれば）（ｉ）プロセッサ又はプロセッサコアの組み合わせ、或いは（ii）デジタル信号プロセッサを含むプロセッサ／ソフトウェアの部分、ソフトウェア、及び装置に特定の機能を遂行させるために一緒に働く少なくとも１つのメモリ；及び（ｃ）ソフトウェア又はファームウェアが物理的に存在しなくてもオペレーションのためにソフトウェア又はファームウェアを要求するマイクロプロセッサ又はマイクロプロセッサの部分のような回路；の全部を指す。

「回路」のこの定義は、本出願におけるこの用語の全ての使用に適用される。更に別の例として、本出願に使用するように、「回路」という語は、単にプロセッサ（又は多数のプロセッサ）或いはプロセッサの一部分、例えば、マルチコアプロセッサの１つのコア、及びそれ（又はそれら）に付随するソフトウェア及び／又はファームウェアの実施もカバーする。又、「回路」という語は、例えば、本発明の実施形態による装置のための特定の要素、基本帯域集積回路、特定用途向け集積回路（ＡＳＩＣ）、及び／又はフィールドプログラマブルグリッドアレー（ＦＰＧＡ）回路をカバーしそしてそれらに適用される。

又、図１から２７に関して上述したプロセス又は方法は、１つ以上のコンピュータプログラムによって定義された１つ以上のコンピュータプロセスの形態で実行されてもよい。コンピュータプログラムは、コンピュータプログラムのモジュールも包含すると考えねばならず、例えば、前記プロセスは、大きなアルゴリズム又はコンピュータプロセスのプログラムモジュールとして実施される。コンピュータプログラムは、ソースコード形態、オブジェクトコード形態、又はある中間形態であり、そしてプログラムを搬送できるエンティティ又は装置であるキャリアに記憶される。そのようなキャリアは、一時的及び／又は非一時的コンピュータメディア、例えば、レコード媒体、コンピュータメモリ、リードオンリメモリ、電気的キャリア信号、テレコミュニケーション信号、及びソフトウェア配布パッケージを含む。必要とされる処理能力に基づいて、コンピュータプログラムは、単一の電子的デジタル処理ユニットで実施されるか、又は多数の処理ユニットの中に分散される。

本発明は、上述したセルラー又は移動通信システムに適用できるが、他の適当な通信システムにも適用できる。使用するプロトコル、セルラー通信システムの仕様、それらのネットワーク要素、及びターミナル装置は、急速に発展する。そのような発展は、ここに述べる実施形態に対して余計な変更を要求する。それ故、全ての言葉及び表現は、広く解釈されねばならず、それらは、実施形態を例示するもので、それに限定するものではない。

当業者に明らかなように、技術の進歩に伴い、本発明の概念は、種々の仕方で実施することができる。本発明及びその実施形態は、上述した例に限定されず、特許請求の範囲内で変化し得る。

略語のリスト
３ＧＰＰ：第三世代パートナーシッププロジェクト
ＡＭＢＲ：アグリゲート最大ビットレート
ＡＰ：アクセスポイント
ＡＲＰ：割り当て及び保持プライオリティ
ＢＳＴ：ベースステーション
ＣＤＮ：コンテンツ配信ネットワーク
ＣＥ：顧客体験
ＣＥ−Ａ：顧客体験エージェント（ＣＥエージェント）
ＣＥＭ：顧客体験管理
ＣｍＣＨ−ＰＩ：共通チャンネルプライオリティ指示子
ＣＮ：コアネットワーク
ＣＳＶ：カンマ分離価値
ＤＬ：ダウンリンク
ＤＲＴ：遅延基準時間
ＤＳＣＰ：区別サービスコードポイント
ＥＣＧＩ：進化型セルグローバル識別子
ｅＮＢ：進化型ノードＢ
ＦＣＯ：柔軟性コンテンツオプチマイザー
ＦＰ：フレームプロトコル
ＦＳＮ：フレームシーケンス番号
ＦＰＴ：ファイル転送プロトコル
ＧＢＲ：保証ビットレート
ＧＰＲＳ：汎用パケット無線サービス
ＧＰＳ：グローバルポジショニングシステム
ＧＴＰ：ＧＰＲＳトンネルプロトコル
ＨＥ：ヘッダエンリッチメント
ＨＳＤＰＡ：高速ダウンリンクパケットアクセス
ＨＳＰＡ：高速パケットアクセス
ＨＳＵＰＡ：高速アップリンクパケットアクセス
ＨＴＴＰ:ハイパーテキスト転送プロトコル
ＨＴＴＰＳ：ハイパーテキスト転送プロトコルセキュア
ＩＭＳＩ：国際移動加入者アイデンティティ
ＩＰ：インターネットプロトコル
ＩＳＰ：インターネットサービスプロバイダー
ＫＰＩ：重要業績指示子
ＬＴＥ：長期進化
ＭＢＲ：最大ビットレート
ＭＭＥ：移動管理エンティティ
ＭＳＳ：最大セグメントサイズ
ＮＴＰ：ネットワークタイムプロトコル
ＯＷＡＭＰ：一方アクティブ測定プロトコル
ＰＣＥＦ：ポリシー・アンド・チャージングエンフォースメントファンクション
ＰＣＲＦ：ポリシー・アンド・チャージングルールファンクション
ＰＨＢ：ホップごとの振舞い
ＰＴＰ：高精度タイムプロトコル
ＱｏＥ：体験クオリティ
ＱｏＳ：サービスクオリティ
ＲＡＣＳ：無線アプリケーションクラウドサーバー
ＲＡＣＳ−Ｃ：コア内のＲＡＣＳ
ＳＤＮ：ソフトウェア定義ネットワーキング
ＲＮＣ：無線ネットワークコントローラ
ＳＰＩ：スケジューリングプライオリティインデックス
ＲＲＣ：無線リソースコントロール
ＲＴＴ：ラウンドトリップタイム
ＳＡＥ−ＧＷ：サービスアーキテクチャー進化ゲートウェイ
ＳＣＴＰ：ストリームコントロール送信プロトコル
ＳＯＮ：自己編成ネットワーク
ＴＣＰ：送信コントロールプロトコル
ＴＦＴ：トラフィックフローテンプレート
ＴＬＳ：トランスポートレイヤセキュリティ
ＴＷＡＭＰ：二方アクティブ測定プロトコル
ＵＤＰ：ユーザデータグラムプロトコル
ＵＥ：ユーザ装置
ＵＬ：アップリンク
ＵＰＣＯＮ：ユーザプレーン混雑管理
ＶｏＩＰ：ボイスオーバーＩＰ
ＶｏＬＴＥ：ボイスオーバーＬＴＥ
ＶＰＮ：バーチャルプライベートネットワーク

１０：処理回路
１２：インサイトジェネレータ
１４：インサイト指示子
１６：フローモニタ
１８：測定データコレクタ
２０：メモリ
２２：ＴＸ／ＲＸ
２４：ソフトウェア
２６：データベース
１００、１０２：ベースステーション（ｅＮＢ）
１０４、１０６：ターミナル装置（ＵＥ）

Claims (22)

1. 顧客体験に対するインサイトを生成する方法において、
   ネットワークノードにおいてネットワークに送信されるユーザプレーントラフィックフローを監視して、選択されたデータパケットに対して測定を遂行し、
   前記監視に基づき、ネットワークノードにおいて、ユーザ測定データ、アプリケーション測定データ、体験クオリティ測定データ、ネットワーク側サービスクオリティ測定データ、及び１組の重要業績指示子の１つ以上を含むリアルタイムデータを相関的に収集し、相関的に収集するとは、１つの測定ラウンドにおいて、リアルタイムデータを、パケット又はパケット及びそれに対応する１つ以上の応答パケットから収集して、相関的に収集されるリアルタイムデータの各断片が現在ネットワーク状態にリアルタイムで対応するようにすることを意味し、
   前記相関的な収集に基づき、ネットワークノードにおいて、顧客体験に対するリアルタイム相関インサイトを生成し、
   データパケットのヘッダコンテンツを監視し、
   データパケットが傍受されたときに時間を記録し、
   ヘッダエンリッチメントにより付加的なヘッダフィールドを追加又は除去し、及び
   状態情報及びＱｏＳ測定情報の少なくとも１つをネットワークノード間で交換する、
   ことを含む方法。
2. ネットワークノードにおいて、前記ユーザプレーントラフィックフローをユーザ装置及びアプリケーションに関連付けることを更に含む、請求項１に記載の方法。
3. ネットワークノードにおいて、前記収集されたリアルタイム測定データに基づきユーザプレーントラフィックフローに関連した関連イベントを検出するのに応答して前記１組の重要業績指示子を更新することを更に含む、請求項１又は２に記載の方法。
4. 前記関連イベントは、パケット到着、パケット再送信、パケット破棄、順序ずれセグメント転送、及びデータ転送の１つ以上を含む、請求項３に記載の方法。
5. ＴＣＰトラフィック及びＵＤＰトラフィックに対するリアルタイムＱｏＳ測定データを収集することを更に含む、請求項１から４のいずれか１項に記載の方法。
6. 前記収集に基づき、体験クオリティの低下に対するネットワーク側の理由を決定し及び指示することを更に含む、請求項１から５のいずれか１項に記載の方法。
7. ユーザプレーントラフィックフローの端−端経路内で１つ以上のＱｏＳ測定ポイントにおいてＱｏＳ測定を実行することを更に含む、請求項１から６のいずれか１項に記載の方法。
8. 顧客体験に対するインサイトに関する情報をネットワーク運営者及び別のネットワークノードの１つ以上に与えることを更に含む、請求項１から７のいずれか１項に記載の方法。
9. フローレベルＱｏＳ測定データを、アプリケーションレベルＱｏＳ測定データ、ユーザレベルＱｏＳ測定データ、又はセルレベルＱｏＳ測定データのような高レベルＱｏＳ測定データへアグリゲートすることを更に含む、請求項１から８のいずれか１項に記載の方法。
10. 前記１組の重要業績指示子は、ユーザ関連のＱｏＳ重要業績指示子、アプリケーション関連のＱｏＳ重要業績指示子、体験クオリティ関連のＱｏＳ重要業績指示子、及びネットワーク状態関連のＱｏＳ重要業績指示子の１つ以上を含む、請求項１から９のいずれか１項に記載の方法。
11. 相関ユーザプレーン異常検出を遂行して、混雑及びトランスポートリンクボトルネックの１つ以上により生じる体験クオリティの低下を識別することを更に含む、請求項１から１０のいずれかに１項記載の方法。
12. ユーザプレーンアプリケーション体験クオリティと相関して制御プレーン性能の監視を遂行することを更に含む、請求項１から１１のいずれか１項に記載の方法。
13. 測定された体験クオリティ低下の相関に基づき混雑検出を遂行することを更に含む、請求項１から１２のいずれか１項に記載の方法。
14. ロスパターン検出、遅延プロフィール分析、並びに相関遅延−ロス−スループットプロフィーリング及び分類の少なくとも１つに基づいてネットワーク状態検出を遂行することを更に含む、請求項１から１３のいずれか１項に記載の方法。
15. 通信インスタンスの典型的な振舞いを決定し、及び
    典型的な振舞いからの偏差を検出する、
    ことを更に含む請求項１から１４のいずれか１項に記載の方法。
16. データパケットが第１の測定ポイントで傍受され、ヘッダが第２の測定ポイントでエンリッチされる場合に、前記方法は、受け取った測定データをデコードして、第１の測定ポイントの測定データ及び他の測定ポイントから受け取った測定データと合成し、ネットワークセグメントごとの重要業績指示子を更新することを含む、請求項１から１５のいずれか１項に記載の方法。
17. 前記方法は、
    ＴＣＰヘッダにおけるＴＣＰデータセグメントの観察と、逆方向に送信される関連確認との間の時間を測定し、及び
    ＴＣＰ受信者により送られる複写確認と、ＴＣＰ送信者から発せられる第１の再送信との間の時間を測定する、
    ことの少なくとも１つによりＴＣＰ接続のＲＴＴを監視することを含む、請求項１から１６のいずれか１項に記載の方法。
18. 前記方法は、対応するＨＴＴＰ要求とＨＴＴＰ応答メッセージとの間の時間を測定することによりＨＴＴＰレベルのＲＴＴを測定することを含む、請求項１から１７のいずれか１項に記載の方法。
19. 少なくとも１つのプロセッサ、及び
    コンピュータプログラムコードを含む少なくとも１つのメモリ、
    を備えた装置において、少なくとも１つのメモリ及びコンピュータプログラムコードは、少なくとも１つのプロセッサとで、装置が、
    ネットワークに送信されるユーザプレーントラフィックフローを監視して、選択されたデータパケットに対して測定を遂行し、
    前記監視に基づき、ユーザ測定データ、アプリケーション測定データ、体験クオリティ測定データ、ネットワーク側サービスクオリティ測定データ、及び１組の重要業績指示子の１つ以上を含むリアルタイムデータを相関的に収集し、相関的に収集するとは、１つの測定ラウンドにおいて、リアルタイムデータを、パケット又はパケット及びそれに対応する１つ以上の応答パケットから収集して、相関的に収集されるリアルタイムデータの各断片が現在ネットワーク状態にリアルタイムで対応するようにすることを意味し、
    前記収集に基づき、前記相関的に収集したリアルタイムデータを使用することにより、顧客体験に対するリアルタイム相関インサイトを生成し、
    データパケットのヘッダコンテンツを監視し、
    データパケットが傍受されたときに時間を記録し、
    ヘッダエンリッチメントにより付加的なヘッダフィールドを追加又は除去し、及び
    状態情報及びＱｏＳ測定情報の少なくとも１つをネットワークノード間で交換する
    ようにさせるよう構成された装置。
20. ネットワークに送信されるユーザプレーントラフィックフローを監視して、選択されたデータパケットに対して測定を遂行するための手段、
    前記監視のための手段に応答して、ユーザ測定データ、アプリケーション測定データ、体験クオリティ測定データ、ネットワーク側サービスクオリティ測定データ、及び１組の重要業績指示子の１つ以上を含むリアルタイムデータを相関的に収集するための手段であって、相関的に収集するとは、１つの測定ラウンドにおいて、リアルタイムデータを、パケット又はパケット及びそれに対応する１つ以上の応答パケットから収集して、相関的に収集されるリアルタイムデータの各断片が現在ネットワーク状態にリアルタイムで対応するようにすることを意味するものである手段、
    前記相関的に収集したリアルタイムデータを使用して、顧客体験に対するリアルタイム相関インサイトを生成するための手段、
    データパケットのヘッダコンテンツを監視するための手段、
    データパケットが傍受されたときに時間を記録するための手段、
    ヘッダエンリッチメントにより付加的なヘッダフィールドを追加又は除去するための手段、及び
    状態情報及びＱｏＳ測定情報の少なくとも１つをネットワークノード間で交換するための手段、
    を備えた装置。
21. 請求項２から１８のいずれかに記載の方法を実施するための手段を更に備えた請求項２０に記載の装置。
22. プログラムインストラクションがネットワークノードで実行されるときに、ネットワークノードが、
    ネットワーク側ユーザプレーントラフィックフローを監視して、選択されたデータパケットに対して測定を遂行し、
    前記監視に基づき、ユーザ測定データ、アプリケーション測定データ、体験クオリティ測定データ、ネットワーク側サービスクオリティ測定データ、及び１組の重要業績指示子の１つ以上を含むリアルタイムデータを相関的に収集し、相関的に収集するとは、１つの測定ラウンドにおいて、リアルタイムデータを、パケット又はパケット及びそれに対応する１つ以上の応答パケットから収集して、相関的に収集されるリアルタイムデータの各断片が現在ネットワーク状態にリアルタイムで対応するようにすることを意味し、
    前記収集に基づき、前記相関的に収集したリアルタイムデータを使用することにより、顧客体験に対するリアルタイム相関インサイトを生成し、
    データパケットのヘッダコンテンツを監視し、
    データパケットが傍受されたときに時間を記録し、
    ヘッダエンリッチメントにより付加的なヘッダフィールドを追加又は除去し、及び
    状態情報及びＱｏＳ測定情報の少なくとも１つをネットワークノード間で交換する、
    ようにさせるよう構成されたプログラムインストラクションを含むコンピュータプログラム。