JP6416418B2

JP6416418B2 - アプリケーションを連携制御するためのシステムおよび方法

Info

Publication number: JP6416418B2
Application number: JP2017566660A
Authority: JP
Inventors: グリンシュプン，エドワード; ファウチャー，デイビッド; レイマン，マーティン; シャルマ，サミールクマール; シザー，セオドア
Original assignee: アルカテル−ルーセント
Priority date: 2015-06-25
Filing date: 2016-06-20
Publication date: 2018-10-31
Anticipated expiration: 2036-06-20
Also published as: CN107787596A; US9838893B2; JP2018523383A; EP3314941A1; WO2016209744A1; US20160381698A1; CN107787596B

Description

例示的な実施形態は、一般に、ロングタームエボリューション（ＬＴＥ：Ｌｏｎｇ−ＴｅｒｍＥｖｏｌｕｔｉｏｎ）無線アクセスネットワーク（ＲＡＮ：ＲａｄｉｏＡｃｃｅｓｓＮｅｔｗｏｒｋ）メトリックを使用した連携アプリケーション制御のためのシステムおよび方法に関する。

図１は、第３世代パートナーシッププロジェクトロングタームエボリューション（３ＧＰＰＬＴＥ：３ｒｄＧｅｎｅｒａｔｉｏｎＰａｒｔｎｅｒｓｈｉｐＰｒｏｊｅｃｔＬｏｎｇ−ＴｅｒｍＥｖｏｌｕｔｉｏｎ）ＩＰコネクティビティネットワーク（ＩＰ−ＣＡＮ：ＩＰＣｏｎｎｅｃｔｉｖｉｔｙＮｅｔｗｏｒｋ）１００（無線ネットワークとも呼ばれる）を介して無線でインターネットプロトコル（ＩＰ：ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）パケットデータネットワーク（ＩＰ−ＰＤＮ：ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌＰａｃｋｅｔＤａｔａＮｅｔｗｏｒｋ）１００１（インターネットとも呼ばれる）に接続されたモバイルユーザ機器（ＵＥ：ＵｓｅｒＥｑｕｉｐｍｅｎｔ）１１０を有する従来のネットワーク１０を示す。ＩＰ−ＣＡＮ１００は、一般に、サービングゲートウェイ（ＳＧＷ：ｓｅｒｖｉｎｇｇａｔｅｗａｙ）１０１、パケットデータネットワーク（ＰＤＮ：ｐａｃｋｅｔｄａｔａｎｅｔｗｏｒｋ）ゲートウェイ（ＰＧＷ：ｐａｃｋｅｔｄａｔａｎｅｔｗｏｒｋｇａｔｅｗａｙ）１０３、ポリシーおよび課金ルール機能（ＰＣＲＦ：ｐｏｌｉｃｙａｎｄｃｈａｒｇｉｎｇｒｕｌｅｓｆｕｎｃｔｉｏｎ）１０６、モビリティマネジメントエンティティ（ＭＭＥ：ｍｏｂｉｌｉｔｙｍａｎａｇｅｍｅｎｔｅｎｔｉｔｙ）１０８、および進化型ノードＢ（ｅＮＢ：ＥｖｏｌｖｅｄＮｏｄｅＢ）１０５（セルとも呼ばれる）を含む。ＩＰ−ＰＤＮ１００１は、アプリケーションまたはプロキシサーバ、メディアサーバ、電子メールサーバ、他の接続されたＵＥなどを含み得るアプリケーション機能（ＡＦ：ＡｐｐｌｉｃａｔｉｏｎＦｕｎｃｔｉｏｎ）１０９を含む。

ＩＰ−ＣＡＮ１００内において、ｅＮＢ１０５は、進化型ユニバーサル移動体通信システム（ＵＭＴＳ：ＵｎｉｖｅｒｓａｌＭｏｂｉｌｅＴｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓＳｙｓｔｅｍ）地上波無線アクセスネットワーク（ＥＵＴＲＡＮ：ＥｖｏｌｖｅｄＵｎｉｖｅｒｓａｌＭｏｂｉｌｅＴｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓＳｙｓｔｅｍＴｅｒｒｅｓｔｒｉａｌＲａｄｉｏＡｃｃｅｓｓＮｅｔｗｏｒｋ）と呼ばれるものの一部であり、ＩＰ−ＣＡＮ１００のうちＳＧＷ１０１、ＰＧＷ１０３、およびＭＭＥ１０８を含む部分は、進化型パケットコア（ＥＰＣ：ＥｖｏｌｖｅｄＰａｃｋｅｔＣｏｒｅ）と呼ばれる。図１には単一のｅＮＢ１０５のみが示されているが、ＥＵＴＲＡＮは任意の数のｅＮＢを含み得ることが理解されなければならない。同様に、図１には単一のＳＧＷ、ＰＧＷ、およびＭＭＥのみが示されているが、ＥＰＣは任意の数のこれらのコアネットワーク要素を含み得ることが理解されなければならない。

ｅＮＢ１０５は、ＵＥ１１０を含むＵＥのための無線リソースおよび無線サービスエリアを提供する。明確であることを目的として、１つのＵＥのみが図１に示される。しかし、任意の数のＵＥがｅＮＢ１０５に接続され（または、アタッチさせられ）得る。ｅＮＢ１０５は、ＳＧＷ１０１およびＭＭＥ１０８に動作可能に結合される。ＵＥ１１０は、ＵＥ１１０上でアプリケーションを動作させ得るアプリケーション機能１１５をさらに含み得、アプリケーションは、アプリケーションまたはプロキシサーバ、メディアサーバ、電子メールサーバ、他の接続されたＵＥなどから調達され得る。

ＳＧＷ１０１は、ユーザデータパケットをルーティングおよび転送するとともに、ＵＥのｅＮＢ間ハンドオーバー中、ユーザプレーンのためのモビリティアンカーとしても機能する。ＳＧＷ１０１は、第３世代パートナーシッププロジェクトロングタームエボリューション（３ＧＰＰＬＴＥ）と他の３ＧＰＰ技術との間におけるモビリティのためのアンカーとしても機能する。アイドル状態のＵＥに対して、ＳＧＷ１０１は、ダウンリンクデータ経路を終端し、ＵＥのためのダウンリンクデータが到達したときにページングをトリガーする。

ＰＧＷ１０３は、ＵＥ１１０のためのトラフィックの入口／出口の点となることにより、ＵＥ１１０と外部パケットデータネットワーク（例えば、ＩＰ−ＰＤＮ）との間における接続性を提供する。知られているように、所与のＵＥは、複数のＰＤＮにアクセスするために１つを上回るＰＧＷとの同時接続性をもち得る。

ＰＧＷ１０３はさらに、ポリシー施行、ＵＥのためのパケットフィルタ処理、課金サポート、合法的傍受、およびパケットスクリーニングを実施し、その各々がよく知られた機能である。ＰＧＷ１０３は、世界規模相互運用マイクロ波アクセス（ＷｉＭＡＸ：ＷｏｒｌｄｗｉｄｅＩｎｔｅｒｏｐｅｒａｂｉｌｉｔｙｆｏｒＭｉｃｒｏｗａｖｅＡｃｃｅｓｓ）および第３世代パートナーシッププロジェクト２（３ＧＰＰ２：３ｒｄＧｅｎｅｒａｔｉｏｎＰａｒｔｎｅｒｓｈｉｐＰｒｏｊｅｃｔ２（符号分割多元接続（ＣＤＭＡ：ｃｏｄｅｄｉｖｉｓｉｏｎｍｕｌｔｉｐｌｅａｃｃｅｓｓ）１Ｘおよびエンハンストボイスデータオプティマイズド（ＥｖＤＯ：ＥｎｈａｎｃｅｄＶｏｉｃｅＤａｔａＯｐｔｉｍｉｚｅｄ））などの、３ＧＰＰと非３ＧＰＰ技術との間におけるモビリティのためのアンカーとしても機能する。

さらに図１を参照すると、ｅＮＢ１０５はさらに、ＭＭＥ１０８に動作可能に結合される。ＭＭＥ１０８は、ＥＵＴＲＡＮのための制御ノードであり、再送信を含むアイドルモードＵＥページングおよびタギングプロシージャに責任を負う。ＭＭＥ１０８は、ネットワークへのＵＥの初期アタッチメント中、およびコアネットワーク（ＣＮ：ＣｏｒｅＮｅｔｗｏｒｋ）ノード再配置をともなうＬＴＥ内ハンドオーバー中、ＵＥのための特定のＳＧＷを選択することについても責任を負う。ＭＭＥ１０８は、図１に示されない家庭加入者サーバ（ＨＳＳ：ＨｏｍｅＳｕｂｓｃｒｉｂｅｒＳｅｒｖｅｒ）と相互作用することによりＵＥを認証する。

非アクセス層（ＮＡＳ：ＮｏｎＡｃｃｅｓｓＳｔｒａｔｕｍ）シグナリングは、ＭＭＥ１０８において終端し、ＵＥのための一時的な識別情報の生成および割り当てについて責任を負う。ＭＭＥ１０８はさらに、サービスプロバイダーの公衆陸上モバイルネットワーク（ＰＬＭＮ：ＰｕｂｌｉｃＬａｎｄＭｏｂｉｌｅＮｅｔｗｏｒｋ）にキャンプオンするためのＵＥの権限を確認し、ＵＥローミング制約を施行する。ＭＭＥ１０８は、ＮＡＳシグナリングのための暗号化／完全性保護のためのネットワークにおける終端点であり、セキュリティー鍵管理を行う。

ＭＭＥ１０８はさらに、ＭＭＥ１０８において終端するＳＧＳＮ（図示せず）からのＳ３インターフェースを使用した、ＬＴＥと２Ｇ／３Ｇアクセスネットワークとの間におけるモビリティのための制御プレーン機能を提供する。

ポリシーおよび課金ルール機能（ＰＣＲＦ）１０６は、ポリシー決定を行い、課金ルールを設定するエンティティである。ポリシーおよび課金ルール機能（ＰＣＲＦ）１０６は、加入者データベースにアクセス可能であり、３ＧＰＰＴＳ２３．３０３「ポリシーおよび課金制御アーキテクチャ」において指定されるように、３ＧＰＰアーキテクチャにおいて役割を果たす。特に、ＰＧＷを介したＰＣＲＦは、無線ベアラを構成し得、ＰＣＲＦは、特定のベアラに属するパケットのフロー制御に関係するＰＧＷおよびＳＧＷに対するポリシーをさらに構成し得る。「ベアラ」は、ＵＥ１１０上の１つまたは複数のアプリケーションのための情報を交換するために使用される仮想リンク、チャンネル、またはデータフローであると理解され得る。

ＵＥ１１０内のアプリケーション機能（ＡＦ）１１５が、ＩＰ−ＣＡＮ１００を介してアプリケーション機能（ＡＦ）１０９と通信して、アプリケーションセッションを確立し、アプリケーションコンテンツおよび他のアプリケーションに特有の情報を受信および送信する。ＡＦ１０９は、ＩＰ−ＰＤＮ内のサーバ、もしくはピアエンドユーザデバイス、またはこれらの組み合わせであり得る。ＡＦ１０９は、エンドユーザ体感品質を改善することに役立つようにアプリケーション挙動を適応させることを可能にし得るアプリケーションレベルポリシーを受信するためにＰＣＲＦ１０６に登録し得る。

図２は、従来のＥ−ＵＴＲＡＮノードＢ（ｅＮＢ）１０５の図である。ｅＮＢ１０５は、メモリ２４０、プロセッサ２２０、スケジューラ２１０、および通信インターフェース２６０を含む。プロセッサ２２０は、コアネットワークエンティティ処理回路、ＥＰＣエンティティ処理回路などとも呼ばれ得る。プロセッサ２２０は、ｅＮＢ１０５の機能を（本明細書において説明されるように）制御し、メモリ２４０と通信インターフェース２６０とに動作可能に結合される。

ｅＮＢは、個々の幾何学的サービスエリアセクタ領域内においてＵＥにサービスする共有された無線リソースプールを含む１つまたは複数のセルまたはセクタを含み得る。各セルが個別に、図２に示される要素を収容し得る。本明細書を通して、ｅＮＢ、セル、またはセクタという用語は、交換可能に使用される。

さらに図２を参照すると、通信インターフェース２６０は、ＵＥに／から、または、他のＥＰＣネットワーク要素および／またはＲＡＮ要素への制御プレーンまたはインターフェースを介して、制御およびデータ信号を（有線および／または無線で）送信／受信するための、１つまたは複数のアンテナに接続された１つまたは複数の送信器／受信器を含む様々なインターフェースを含む。スケジューラ２１０は、ｅＮＢ１０５により、ＵＥ１１０に、およびＵＥ１１０から送信および受信される制御およびデータ通信をスケジューリングする。スケジューラ２１０は、これらのスケジューリング機能を実施するための専用プロセッサを含み得るか、または、スケジューラ２１０は（図２に示されるように）プロセッサ２２０内に常駐し得る。メモリ２４０は、ｅＮＢ１０５に、およびｅＮＢ１０５から送信および受信されるデータをバッファおよび記憶し得る。

典型的には１ミリ秒に等しい、送信時間間隔（ＴＴＩ：ＴｒａｎｓｍｉｓｓｉｏｎＴｉｍｅＩｎｔｅｒｖａｌ）ごとに、スケジューラが、（ｅＮＢ１０５からＵＥ１１０への）ダウンリンクおよび（ＵＥ１１０からｅＮＢ１０５への）アップリンク方向において無線リンク上でデータを搬送する異なるベアラに、特定の数の物理リソースブロック（ＰＲＢ：ＰｈｙｓｉｃａｌＲｅｓｏｕｒｃｅＢｌｏｃｋ）を割り当て得る。スケジューラは、さらに、割り当てられた数のＰＲＢ内に何ビットの情報が収容され得るかを規定し得る変調および符号化スキーマ（ＭＣＳ：ＭｏｄｕｌａｔｉｏｎａｎｄＣｏｄｉｎｇＳｃｈｅｍａ）を決定し得る。後者は、所与の割り当てられた数のＰＲＢおよびＭＣＳ値に対する、ＴＴＩごとに送信されるＰＲＢ内に含まれ得るデータのビット数に関する参照表を提示する、３ＧＰＰＴＳ３６．２１３の表７．１．７．１−１および７．１．７．２．１−１により規定される。ＭＣＳは、ＵＥ１１０により報告されたチャンネル品質インジケーター（ＣＱＩ：ＣｈａｎｎｅｌＱｕａｌｉｔｙＩｎｄｉｃａｔｏｒ）値を使用してスケジューラにより計算され、ＣＱＩ値は、ＵＥ１１０により測定された信号対干渉およびノイズ比（ＳＩＮＲ：ＳｉｇｎａｌｔｏＩｎｔｅｒｆｅｒｅｎｃｅａｎｄＮｏｉｓｅＲａｔｉｏ）の形態による無線チャンネル状態から導出され得る。

スケジューラ２１０は、トラフィック優先度階層を表すサービス品質（ＱｏＳ：ＱｕａｌｉｔｙｏｆＳｅｒｖｉｃｅ）クラス識別子（ＱＣＩ：ＱｕａｌｉｔｙｏｆＳｅｒｖｉｃｅＣｌａｓｓＩｄｅｎｔｉｆｉｅｒ）に基づいて共有された無線リソースプール内においてＰＲＢ割り当て決定を行い得る。現在ＬＴＥに規定された９つのＱＣＩクラスが存在し、１が最高優先度を表し、９が最低優先度を表す。１から４のＱＣＩは、ある特定のデータフローＱｏＳ特性をスケジューラが維持する対象となる保証されるビットレート（ＧＢＲ：ＧｕａｒａｎｔｅｅｄＢｉｔｒａｔｅ）クラスのために予約されている。５から９のＱＣＩは、ベストエフォートトラフィックの様々なカテゴリのために予約されている。

スケジューラの動作は標準化されていない一方で、一般的に容認される特定の包括的な種類のスケジューラが存在する。例として、絶対優先度スケジューラ（ＳＰＳ：ｓｔｒｉｃｔｐｒｉｏｒｉｔｙｓｃｈｅｄｕｌｅｒ）、および比例重み付けフェア共有持分スケジューラ（ＰＷＦＳＳ：ｐｒｏｐｏｒｔｉｏｎａｌｗｅｉｇｈｔｅｄｆａｉｒｓｈａｒｅｓｃｈｅｄｕｌｅｒ）が挙げられる。両方の種類が、非ＧＢＲクラスのための特定の最小データトラフィックを維持するための十分なリソースを残しながら、可能なときはいつでもＧＢＲベアラスループット制約を満たすように専用リソースを割り当てることにより、まずＧＢＲの需要に応えることを試みる。ＳＰＳは、必要とされ得るすべてのリソース（より低い優先度クラスに不足が生じないように特定の最小量のリソースを除く）を使用して、より高い優先度クラスを割り当て、より低い優先度クラスは、一般に、残りのリソースを受け取る。ＰＷＦＳＳは、使用されていないリソースが利用可能でない限り上回り得ない、リソースの特定の重み付けされた共有持分を、各非ＧＢＲＱＣＩクラスに与える。

仮想無線アクセスネットワーク（ＶＲＡＮ：ＶｉｒｔｕａｌＲａｄｉｏＡｃｃｅｓｓＮｅｔｗｏｒｋ）アーキテクチャを使用すると、様々なｅＮＢ機能およびコンポーネントが、ＶＲＡＮクラウド内における複数の処理回路および複数の物理ノードにわたって分散され得ることが理解されなければならない。同様に、仮想無線コアネットワークアーキテクチャを使用すると、ＭＭＥ１０８、Ｐ−ＧＷ１０３、Ｓ−ＧＷ１０１、ＰＣＲＦ１０６の様々な機能およびコンポーネントが、仮想無線コアクラウド内における複数の処理回路および複数の物理ノードにわたって分散され得る。

ハイパーテキスト転送プロトコル（ＨＴＴＰ：ＨｙｐｅｒｔｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）適応型ストリーミング（ＨＡＳ：ＨｙｐｅｒｔｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌＡｄａｐｔｉｖｅＳｔｒｅａｍｉｎｇ）は、ビデオオンデマンド（ＶｏＤ：ＶｉｄｅｏｏｎＤｅｍａｎｄ）サービスを配信するために広く採用されている技術である。ビデオは、短いセグメント（典型的には２から１０秒の持続期間）にセグメント分けされ、各セグメントは、複数のビデオフォーマット／分解能およびレートで符号化される。ＨＡＳクライアントは、ネットワーク状態の任意のばらつきを滑らかにするために、ＨＡＳクライアントにおいて受信されたビデオデータのためのキャッシュバッファを維持する。ＨＡＳクライアントは、レート決定アルゴリズム（ＲＤＡ：ＲａｔｅＤｅｔｅｒｍｉｎａｔｉｏｎＡｌｇｏｒｉｔｈｍ）を動作させて、（ビデオセグメントの要求を送信することと、ビデオセグメントのダウンロードを完了することとの間に満了する時点までに、ＨＡＳクライアントが、ビデオセグメントサイズを分割することにより取得し得る）ネットワークスループットのＨＡＳクライアントの推定、ＨＡＳクライアントのキャッシュバッファ満杯度、および様々なヒューリスティックに基づいて、（事前符号化されたビデオセグメントのコンテンツキャッシュ内に位置する）次のビデオデータセグメントのためのビデオレートを選択する。セグメントのためのより高いビデオレートは、より大きなビデオセグメントサイズと、このようなセグメントを配信するために必要とされるより広い帯域幅とを犠牲にして、より鮮明な映像品質とより良好なエンドユーザ体感品質（ＱｏＥ：ｑｕａｌｉｔｙｏｆｅｘｐｅｒｉｅｎｃｅ）とを生成する。その一方で、より低いビデオレートは、ビデオセグメントを配信するためにより少ない帯域幅リソースを必要とするが、より不鮮明な、または場合によっては、ブロック状の映像品質に関係し得る。１つのビデオセグメントから別のビデオセグメントへのレート選択における頻繁な変更が低いユーザＱｏＥに寄与し得るので、様々なヒューリスティックの使用が、異なるビデオセグメントのためのレート選択における特定のレベルの安定性を確実なものとし得る。

ＨＡＳの異なるバリエーションは、従来、アプリケーションベンダーにより実装されてきた。３ＧＰＰおよび国際電気通信連合（ＩＴＵ：ＩｎｔｅｒｎａｔｉｏｎａｌＴｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎＵｎｉｏｎ）は、ＤＡＳＨメディアプロトコル記述子（ＭＰＤ：ＭｅｄｉａＰｒｏｔｏｃｏｌＤｅｓｃｒｉｐｔｏｒ）ファイル（マニフェストファイルとも呼ばれる）において説明される、利用可能なビデオセグメントフォーマットおよびセグメントの位置に関する情報をＨＡＳアプリケーションクライアントが受信するフォーマットを標準化するために、ＨＴＴＰを介した動的適応型ストリーミング（ＤＡＳＨ：ＤｙｎａｍｉｃＡｄａｐｔｉｖｅＳｔｒｅａｍｉｎｇｏｖｅｒＨＴＴＰ）規格を用意した。

従来、深刻な無線ネットワーク輻輳状態では、輻輳状態において利用可能な無線リンクキャパシティに基づいて、ベストエフォート無線リンク上でモバイル適応型ストリーミングビデオを見ることができるＵＥの数は、多くの場合、それが本来可能な数より著しく少ない。この理由の１つは、モバイルハイパーテキスト転送プロトコル（ＨＴＴＰ）適応型ストリーミング（ＨＡＳ）アプリケーションが欲張りで、非連携的であることである。輻輳状態において、（現在、ほとんどのネットワークにおいてベストエフォートＬＴＥサービスクラスを主に使用する）ＨＡＳアプリケーションは、利用可能なＲＡＮリソースに関する認識の欠如を被る。したがって、ＵＥ、およびＵＥ上で動作するＨＡＳアプリケーションは、連携した手法で利用可能なＲＡＮリソースを最大化することができない。特に、各ＨＡＳアプリケーションは、個々のビデオセグメントレート決定アルゴリズム（ＲＤＡ）により決定された制限内において、個別にＲＡＮリソースの各ＨＡＳアプリケーションの共有を最大化することを試みる。したがって、各モバイルＨＡＳアプリケーションは、ＲＤＡにより推定されるネットワークスループットにより許容される最高ビデオ再生レートを選択する。再生前バッファが満杯でない（すなわち、適応型ストリーミングアプリケーションが「ハングリーステート」である）場合、ＨＡＳアプリケーションは、できる限り早くビデオセグメントを取得することを試み、選択されたビデオレートより著しく大きいＲＡＮリソースの消費をもたらす。このような個々の欲張りな挙動の結果として、ＲＡＮ輻輳状態において、ＨＡＳビデオを実際に受信するＵＥの数は、利用可能なＲＡＮリソースの連携した利用をともなう場合よりも著しく少ない数であり得る。

図３は、同じ１０Ｍｈｚセルによりサービスされる１８個のベストエフォートＨＡＳクライアントを含む従来の無線ネットワークの場合におけるシミュレーション結果をグラフで示す（他のネットワークトラフィックも存在し得るが、図示されない）。元の６個のＨＡＳクライアント４００に、後からさらに１２個のＨＡＳクライアント４０２が加わることにより、輻輳状態が生まれる。このシミュレーションにおけるすべてのＨＡＳクライアントが、約５００Ｋｂｉｔ／秒を最低の利用可能なビデオレートとした複数のビデオレートで符号化されたビデオを見る。輻輳が始まった後、（１８個の総クライアントのうち）最良のチャンネル状態である２つのクライアント４００ａのみが、ビデオを含む（再生前バッファが空でない）。残りの１６個のクライアントはより悪いチャンネル状態であるので、残りの１６個のクライアントにスケジューラが割り当てる物理リソースブロック（ＰＲＢ）のフェアな共有持分は、最低の利用可能なビデオレートですら持続するのに十分でない。したがって、従来のネットワークにおいてＨＡＳアプリケーションを動作させながら、全部で１８個のクライアントのうちの２つのクライアントのみがサービスされ得る。

従来、（例えば）ベストエフォートの代わりに、保証されるビットレート（ＧＢＲ）サービスクラスを各ＨＡＳクライアントに割り当てることにより、個々のＨＡＳクライアントの各々のためにｅＮＢにおいてスループット制限を施行することに関係するＨＡＳアプリケーションを動作させるＵＥを最適化するための解決策が存在する。しかし、この解決策は、少なくとも２つの理由により実行可能でない。まず、このような解決策は実現するには高価である。特に、一部のネットワークオペレーターは、特にフラットレートデータプランに対応する環境において、ＧＢＲが経済的に実用的でないと考える。第２に、より悪いチャンネル状態においてＵＥは、保証されるレートを維持するために、著しく多くのリソース（ＰＲＢ）を消費し得、このことが、輻輳状態に関連する問題をさらに悪化させ得る。例えば、図４は、図３に示される１８個のＵＥのうちの２つのＵＥ４００ａのみが、「最良のチャンネル状態」ステートを経験するのに対し、残りの１６個のＵＥがより悪いチャンネル状態を経験することをグラフで示す。図３と図４とに示すグラフによる表現は、ＨＡＳアプリケーションの目的に対する典型的なチャンネル状態と考えられ得る。ＵＥに割り当てられるリソースの量がチャンネル状態によっても制限される、適応型ＧＢＲ（ＡＧＢＲ：ＡｄａｐｔｉｖｅＧＢＲ）サービスクラス技術を使用することにより、より悪いチャンネル状態におけるＵＥに関係する問題が軽減され得る一方で、電気通信産業は、従来、ＨＡＳトラフィックの大部分がベストエフォートアプローチを使用するので、ＡＧＢＲアプローチを採用することの実行可能性のみを研究してきた。

従来、輻輳状態においてビデオを再生することができるＵＥの数を最大化しながら、ＨＡＳクライアントがベストエフォート無線リソースを連携した手法で使用することを施行することが可能な、アプリケーションレベルの承認制御およびリソース分配ポリシーのためのメカニズムが存在しない。同様に、従来、ＨＡＳビデオを再生することを試みながら、低質（最低の要求されるビデオレート未満）のチャンネル状態にあるＵＥがネットワークリソースを奪うことを防ぐための承認制御およびリソース分配ポリシーが存在せず、承認されたＵＥの数を最大化することもしながら、すべての承認されたＵＥがビデオを首尾よく再生することを確実にするために、利用可能なＲＡＮリソースを「承認された」ＵＥ間で適切に分配するための従来のメカニズムがまったく存在しない。

米国特許第８，９４９，４４０号明細書

少なくとも１つの例示的な実施形態が、無線ネットワークにおいてアプリケーションの動作を連携制御する方法に関する。

一実施形態において、本方法は、ネットワークリソースを共有するベアラのためのスケジューリングされた共有リソースレート情報とチャンネル状態情報とを、少なくとも１つのネットワークノードの１つまたは複数のプロセッサにより取得することと、ベアラに関係する１つまたは複数のアプリケーション機能から、利用可能なビデオレート情報を、１つまたは複数のプロセッサにより受信することと、スケジューリングされた共有リソースレート情報と、チャンネル状態情報と、利用可能なビデオレート情報とに基づいて、ベアラに関係するユーザ機器（ＵＥ）のためのユーザ機器（ＵＥ）ポリシーを、１つまたは複数のプロセッサにより計算することであって、ＵＥポリシーが、ＵＥのためのスループット制約を含む、計算することと、ＵＥのうちの少なくとも１つにより使用されるアプリケーションの動作を連携制御するために、１つまたは複数のアプリケーション機能にＵＥポリシーを、１つまたは複数のプロセッサによりエクスポートすることとを含む。

例示的な一実施形態において、本方法は、チャンネル状態情報から導出されるチャンネル状態メトリックに基づいて、ＵＥを順序付けすることと、チャンネル状態メトリックとＵＥの順序付けとを使用してＵＥのための承認制御を呼び出すこととをさらに含む。

例示的な一実施形態において、本方法は、承認制御を呼び出すことが、最小の利用可能なビデオレートによりビデオを再生することをサポートするために必要とされるスケジューリングされた共有リソースレートの平均アグリゲート値の和が、利用可能なネットワークリソースの平均アグリゲートレート以下である場合に、アプリケーションサービスを受信するためにＵＥの第１のサブセットを承認することを含むこととを含み、利用可能なネットワークリソースの平均アグリゲートレートが、設定可能なマージンファクターを含み、チャンネル状態メトリックのより高い値が、より良好なチャンネル状態に対応する。

例示的な一実施形態において、本方法は、スケジューリングされた共有リソースレート情報が、ハイパーテキスト転送プロトコル適応型ストリーミング（ＨＡＳ）アプリケーショントラフィックを搬送するすべてのベアラに割り当てられることが想定される平均数の物理リソースブロック（ＰＲＢ）を含む平均アグリゲート物理リソースブロック（ＰＲＢ）レートであること、を含む。

例示的な一実施形態において、本方法は、チャンネル状態情報が、物理リソースブロック（ＰＲＢ）当たりの有用ビットの平均数を含み、有用ビットが、再送信されたビットではない複数のデータビットであること、を含む。

例示的な一実施形態において、本方法は、利用可能なビデオレート情報を受信することが、ＨＡＳクライアントと、ベアラに関係する１つまたは複数のアプリケーション機能に関係するＨＡＳネットワークコンテンツサーバとのうちの１つから、ハイパーテキスト転送プロトコル適応型ストリーミング（ＨＡＳ）ビデオレートを受信することを含むこと、を含む。

例示的な一実施形態において、本方法は、ＵＥポリシーを計算することが、ＵＥのためのスループット制約を示すＵＥごとのタプルを計算することを含むこと、を含む。

例示的な一実施形態において、本方法は、スループット制約が、最大の許可されたビデオビットレートと、ＵＥのための最大の許可されたスループットとを含むこと、を含む。

例示的な一実施形態において、本方法は、ＵＥポリシーの計算が、ＵＥの第１のサブセットに対する体感品質（ＱｏＥ）効用関数を最大化することを含むこと、を含む。

少なくとも１つの実施形態が、少なくとも１つのネットワークノードに関する。

例示的な一実施形態において、少なくとも１つのネットワークノードが、ネットワークリソースを共有するベアラのためのスケジューリングされた共有リソースレート情報とチャンネル状態情報とを取得することと、ベアラに関係する１つまたは複数のアプリケーション機能から、利用可能なビデオレート情報を受信することと、スケジューリングされた共有リソースレート情報と、チャンネル状態情報と、利用可能なビデオレート情報とに基づいて、ベアラに関係するユーザ機器（ＵＥ）のためのユーザ機器（ＵＥ）ポリシーを計算することであって、ＵＥポリシーが、ＵＥのためのスループット制約を含む、計算することと、ＵＥのうちの少なくとも１つにより使用されるアプリケーションの動作を連携制御するために、１つまたは複数のアプリケーション機能にＵＥポリシーをエクスポートすることと、を行うように構成された、１つまたは複数のプロセッサを含む。

例示的な一実施形態において、少なくとも１つのネットワークノードは、１つまたは複数のプロセッサが、チャンネル状態情報から導出されるチャンネル状態メトリックに基づいて、ＵＥを順序付けすることと、チャンネル状態メトリックとＵＥの順序付けとを使用してＵＥのための承認制御を呼び出すことと、を行うようにさらに構成されること、を含む。

例示的な一実施形態において、少なくとも１つのネットワークノードは、１つまたは複数のプロセッサが、最小の利用可能なビデオレートによりビデオを再生することをサポートするために必要とされるスケジューリングされた共有リソースレートの平均アグリゲート値の和が、利用可能なリソースの平均アグリゲートレート以下である場合に、アプリケーションサービスを受信するためにＵＥの第１のサブセットを承認することにより、承認制御を呼び出すことと、利用可能なリソースの平均アグリゲートレートが、設定可能なマージンファクターを含むことと、チャンネル状態メトリックのより高い値が、より良好なチャンネル状態に対応することと、を含む。

例示的な一実施形態において、少なくとも１つのネットワークノードは、スケジューリングされた共有リソースレート情報が、ハイパーテキスト転送プロトコル適応型ストリーミング（ＨＡＳ）アプリケーショントラフィックを搬送するすべてのベアラに割り当てられることが想定される平均数の物理リソースブロック（ＰＲＢ）を含む平均アグリゲート物理リソースブロック（ＰＲＢ）レートであること、を含む。

例示的な一実施形態において、少なくとも１つのネットワークノードは、チャンネル状態情報が、物理リソースブロック（ＰＲＢ）当たりの有用ビットの平均数を含み、有用ビットが、再送信されたビットではない複数のデータビットであること、を含む。

例示的な一実施形態において、少なくとも１つのネットワークノードは、１つまたは複数のプロセッサが、ＨＡＳクライアントと、ベアラに関係する１つまたは複数のアプリケーション機能に関係するＨＡＳネットワークコンテンツサーバとのうちの１つから、ハイパーテキスト転送プロトコル適応型ストリーミング（ＨＡＳ）ビデオレートを受信することにより、利用可能なビデオレート情報を受信すること、を含む。

例示的な一実施形態において、少なくとも１つのネットワークノードは、１つまたは複数のプロセッサが、ＵＥのためのスループット制約を示すＵＥごとのタプルを計算することによりＵＥポリシーを計算すること、を含む。

例示的な一実施形態において、少なくとも１つのネットワークノードは、スループット制約が、ＵＥのための最大の許可されたスループットと最大の許可されたビデオビットレートとを含むこと、を含む。

例示的な一実施形態において、少なくとも１つのネットワークノードは、１つまたは複数のプロセッサが、ＵＥの第１のサブセットに対する体感品質（ＱｏＥ）効用関数を最大化することによりＵＥポリシーを計算すること、を含む。

例示的な一実施形態において、少なくとも１つのネットワークは、１つまたは複数のプロセッサが、最大の許可されたビデオビットレートに基づいて、次のビデオセグメントを要求する前に、最小遅延を計算するようにさらに構成されること、を含む。

少なくとも１つの例示的な実施形態が、非一時的なコンピュータ可読媒体に関する。

例示的な一実施形態において、非一時的なコンピュータ可読媒体は、ネットワークリソースを共有するベアラのためのスケジューリングされた共有リソースレート情報とチャンネル状態情報とを取得することと、ベアラに関係する１つまたは複数のアプリケーション機能から、利用可能なビデオレート情報を受信することと、スケジューリングされた共有リソースレート情報と、チャンネル状態情報と、利用可能なビデオレート情報とに基づいて、ベアラに関係するユーザ機器（ＵＥ）のためのユーザ機器（ＵＥ）ポリシーを計算することであって、ＵＥポリシーが、ＵＥのためのスループット制約を含む、計算することと、ＵＥのうちの少なくとも１つにより使用されるアプリケーションの動作を連携制御するために、１つまたは複数のアプリケーション機能にＵＥポリシーをエクスポートすることとのための命令を含むプログラムを含む。

少なくとも１つの例示的な実施形態が、ソフトウェアコードを含む非一時的なコンピュータ可読媒体上のコンピュータプログラムに関する。

例示的な一実施形態において、ソフトウェアコードを含む非一時的なコンピュータ可読媒体上のコンピュータプログラムは、ネットワークリソースを共有するベアラのためのスケジューリングされた共有リソースレート情報とチャンネル状態情報とを、少なくとも１つのネットワークノードの１つまたは複数のプロセッサにより取得するステップと、ベアラに関係する１つまたは複数のアプリケーション機能から、利用可能なビデオレート情報を、１つまたは複数のプロセッサにより受信するステップと、スケジューリングされた共有リソースレート情報と、チャンネル状態情報と、利用可能なビデオレート情報とに基づいて、ベアラに関係するユーザ機器（ＵＥ）のためのユーザ機器（ＵＥ）ポリシーを、１つまたは複数のプロセッサにより計算するステップであって、ＵＥポリシーが、ＵＥのためのスループット制約を含む、計算するステップと、ＵＥのうちの少なくとも１つにより使用されるアプリケーションの動作を連携制御するために、１つまたは複数のアプリケーション機能にＵＥポリシーを、１つまたは複数のプロセッサによりエクスポートするステップとを実施するように構成される。

例示的な実施形態の上述のおよび他の特徴および利点が、添付図面を参照しながら例示的な実施形態を詳細に説明することより明らかとなる。添付図面は、例示的な実施形態を示すように意図されており、特許請求の範囲の意図される範囲を限定するように解釈されてはならない。添付図面は、明示的に記載されない限り、一定の縮尺で描かれているとみなされるべきではない。

従来の第３世代パートナーシッププロジェクトロングタームエボリューション（３ＧＰＰＬＴＥ）ネットワークを示す図である。従来のＥ−ＵＴＲＡＮノードＢ（ｅＮＢ）の図である。ネットワーク輻輳期間中にサービスされるハイパーテキスト転送プロトコル適応型ストリーミング（ＨＡＳ）クライアントを有する従来の無線ネットワークに対するシミュレーション結果のグラフである。図３に示す従来の無線ネットワークシミュレーションにおける、延長された期間にわたってサービスされるＨＡＳクライアントをグラフで示す図である。例示的な一実施形態による、再構成された３ＧＰＰＬＴＥネットワークを示す図である。例示的な一実施形態による、再構成されたＥ−ＵＴＲＡＮノードＢ（ｅＮＢ）を示す図である。例示的な一実施形態による、ネットワークインサイト機能（ＮＩＦ：ＮｅｔｗｏｒｋＩｎｓｉｇｈｔｓＦｕｎｃｔｉｏｎ）サーバを示す図である。例示的な一実施形態による、無線ネットワークにおいてアプリケーションの動作を連携制御する方法を説明する方法フロー図である。例示的な一実施形態による、再構成された無線ネットワークにおいてサービスされるＨＡＳクライアントをグラフで示す図である。

例示的な実施形態は様々な変形および代替的な形態が可能であるとともに、その実施形態が図面中に例示的に示され、本明細書において詳細に説明される。しかし、例示的な実施形態を開示される特定の形態に限定する意図はなく、むしろ、例示的な実施形態は、特許請求の範囲の範囲内に入るすべての変形例、均等物、および代替例を包含することが理解されなければならない。図の説明を通して、同様な番号は同様な要素を表す。

例示的な実施形態をより詳細に説明する前に、いくつかの例示的な実施形態が、フロー図として示される工程または方法として説明されることに留意されたい。フロー図は動作を逐次的な工程として説明するが、動作の多くは、並列に、一斉に、または同時に実施され得る。加えて、動作の順序は再配置され得る。工程は、それらの動作が完了したときに終了され得るが、図に含まれない追加的なステップをさらに含み得る。工程は、メソッド、関数、プロシージャ、サブルーチン、サブプログラムなどに対応し得る。

いくつかがフロー図により示される後述の方法は、ハードウェア、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語、またはそれらの任意の組み合わせにより実装され得る。ソフトウェア、ファームウェア、ミドルウェア、またはマイクロコード、フィールドプログラマブルゲートアレイ（ＦＰＧＡ：ｆｉｅｌｄｐｒｏｇｒａｍｍａｂｌｅｇａｔｅａｒｒａｙ）、特定用途向け集積回路（ＡＳＩＣ：ａｐｐｌｉｃａｔｉｏｎｓｐｅｃｉｆｉｃｉｎｔｅｇｒａｔｉｏｎｃｉｒｃｕｉｔ）において実装されるとき、必要なタスクを実施するためのプログラムコードまたはコードセグメントは、非一時的記憶媒体などの記憶媒体などの機械またはコンピュータ可読媒体に記憶され得る。プロセッサは、これらの必要なタスクを実施し得る。

本明細書において開示される特定の構造的および機能的な詳細は、例示的な実施形態を説明する目的における代表例にすぎない。しかし、本発明は多くの代替的な形態で具現化され得、本明細書に記載される実施形態のみに限定されると解釈されてはならない。

第１、第２などの用語が様々な要素を説明するために本明細書において使用され得るが、これらの要素は、これらの用語により限定されてはならないことが理解されるであろう。これらの用語は、１つの要素を別の要素と区別するために使用されるのみである。例えば、例示的な実施形態の範囲から逸脱することなく、第１の要素が第２の要素と呼ばれ得、同様に、第２の要素が第１の要素と呼ばれ得る。本明細書で使用される場合、「および／または（ａｎｄ／ｏｒ）」という用語は、関係する列記された項目のうちの１つまたは複数の任意のおよびすべての組み合わせを含む。

要素が別の要素に「接続された（ｃｏｎｎｅｃｔｅｄ）」または「結合された（ｃｏｕｐｌｅｄ）」と表現されるとき、要素が他の要素に直接接続または結合され得るか、または、介在要素が存在し得ることが理解されるであろう。対照的に、要素が別の要素に「直接接続された（ｄｉｒｅｃｔｌｙｃｏｎｎｅｃｔｅｄ）」または「直接結合された（ｄｉｒｅｃｔｌｙｃｏｕｐｌｅｄ）」と表現されるとき、介在要素が存在しない。要素間の関係を説明するために使用される他の用語は、類似の手法で解釈されなければならない（例えば、「の間（ｂｅｔｗｅｅｎ）」に対する「直接的に−の間（ｄｉｒｅｃｔｌｙｂｅｔｗｅｅｎ）」、「隣接した（ａｄｊａｃｅｎｔ）」に対する「直接隣接した（ｄｉｒｅｃｔｌｙａｄｊａｃｅｎｔ）」など）。

本明細書で使用される用語は、特定の実施形態を説明することだけを目的とし、例示的な実施形態の限定であることは意図されない。本明細書で使用される場合、「１の（ａ）」、「１の（ａｎ）」、および「その（ｔｈｅ）」といった単数形の表現は、文脈上そうでないことが明示されない限り、複数形も同様に含むことが意図される。「備える（ｃｏｍｐｒｉｓｅｓ）」、「備える（ｃｏｍｐｒｉｓｉｎｇ）」、「含む（ｉｎｃｌｕｄｅｓ）」、および／または「含む（ｉｎｃｌｕｄｉｎｇ）」という用語は、本明細書において使用されるとき、記載される特徴、整数、ステップ、動作、要素、および／またはコンポーネントの存在を特定するが、１つまたは複数の他の特徴、整数、ステップ、動作、要素、コンポーネント、および／またはこれらのグループの存在または追加を除外しないことがさらに理解されるであろう。

いくつかの代替的な実装例において、記載される機能／アクションは、図中に示される順序以外で起こり得ることにも留意しなければならない。例えば、連続して示される２つの図は、実際には同時に実行され得るか、または、場合によっては、関与する機能／アクションに応じて逆の順序で実行され得る。

別段の定義がされない限り、本明細書で使用される（技術用語および科学用語を含む）すべての用語が、例示的な実施形態が属する技術分野の当業者により一般的に理解される意味と同じ意味をもつ。用語、例えば、一般的に使用される辞書において定義される用語は、関連する技術分野の文脈におけるそれらの意味と一致する意味をもつと解釈されなければならず、本明細書でそのように明示的に定義されない限り、理想的な意味にも過度に形式的な意味にも解釈されないことがさらに理解されるであろう。

例示的な実施形態の一部および対応する詳細な説明は、ソフトウェアまたはアルゴリズム、およびコンピュータメモリ内のデータビット上における動作の記号表現の観点から提示される。これらの説明および表現は、これらの説明および表現により当業者が、これらの説明および表現の働きの本質を他の当業者に効果的に伝達するものである。アルゴリズムは、アルゴリズムという用語が本明細書において使用されるように、および、アルゴリズムという用語が一般的に使用されるように、所望の結果をもたらすステップの首尾一貫したシーケンスであると考えられる。ステップは、物理量の物理的処理を必要とするものである。通常、必ずと言うわけではないが、これらの量は、格納され、移送され、組み合わされ、比較され、および別のやり方で処理されることが可能な光学的な、電気的な、または磁気的な信号の形態をとる。場合によっては、主に一般的な使用という理由から、これらの信号をビット、値、要素、記号、文字、用語、数などとして表すと利便性の高いことが判明している。

以下の説明では、例示的な実施形態が、特定のタスクを実施するか、または特定の抽象データ型を実装し、既存のネットワーク要素における既存のハードウェアを使用して実装され得るルーチン、プログラム、オブジェクト、コンポーネント、データ構造体などを含むプログラムモジュールまたは機能的工程として実装され得る（例えば、フロー図の形態の）アクションおよび動作の記号表現を参照しながら説明される。このような既存のハードウェアは、１つまたは複数の中央処理ユニット（ＣＰＵ：ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）、デジタル信号プロセッサ（ＤＳＰ：ｄｉｇｉｔａｌｓｉｇｎａｌｐｒｏｃｅｓｓｏｒ）、特定用途向け集積回路、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）コンピュータなどを含み得る。

しかし、これらの用語および同様の用語のすべてが、適切な物理量に関係し、これらの量に適用される利便性の高いラベルにすぎないことに留意しなければならない。そうではないことが明示的に記載されない限り、または説明から明らかであるように、例えば、「処理（ｐｒｏｃｅｓｓｉｎｇ）」、「計算（ｃｏｍｐｕｔｉｎｇ）」、「計算（ｃａｌｃｕｌａｔｉｎｇ）」、「決定（ｄｅｔｅｒｍｉｎｉｎｇ）」、または「表示（ｄｉｓｐｌａｙｉｎｇ）」などの用語は、コンピュータシステムのレジスタおよびメモリ内における物理的な、電子的な量として表されるデータを、コンピュータシステムメモリまたはレジスタ内における物理量として同様に表される他のデータに処理および変換するコンピュータシステムまたは同様の電子コンピューティングデバイスの、または、他のこのような情報記憶装置、送信またはディスプレイデバイスのアクションおよび工程を表す。

例示的な実施形態のソフトウェアにより実装される態様は、典型的には何らかの形態のプログラム記憶媒体において符号化されるか、または何らかの種類の伝送媒体上で実装されることにさらに注意されたい。プログラム記憶媒体は、磁気的なもの（例えば、フロッピーディスクまたはハードドライブ）または光学的なもの（例えば、コンパクトディスク読み取り専用メモリ、または「ＣＤＲＯＭ」）などの任意の非一時的記憶媒体であり得、読み取り専用またはランダムアクセスであり得る。同様に、伝送媒体は、より線ペア、同軸ケーブル、光ファイバー、または当技術分野において知られた何らかの他の適切な伝送媒体であり得る。例示的な実施形態は、任意の所与の実装例のこれらの態様により限定されない。

基本方法論
少なくとも１つの例示的な実施形態は、ＬＴＥＲＡＮメトリックを使用してＨＡＳアプリケーションレベルの承認制御およびリソース消費ポリシーを計算する方法に関係し得る。ポリシーは、次に、ＨＡＳアプリケーション機能に通信され得、ポリシーは、次のセグメントの要求のためのアプリケーション機能適応型ストリーミングレート選択決定およびペーシングに影響を与えるために使用され得、このことは、輻輳状態におけるベストエフォート無線接続を使用するＨＡＳアプリケーションが連携して、利用可能なＲＡＮリソースの有効性を最大化することを可能にする。

本方法は、無線ＲＡＮスケジューラに変更を加えることなく、ベストエフォート無線アプリケーショントラフィックを使用して実装され得る。方法は、ｅＮＢスケジューラおよびＭＡＣ層から抽出されたＬＴＥメトリック情報に基づいてリンクレベルＬＴＥメトリックを計算し得るネットワークインサイト機能（ＮＩＦ）４０５（図５に関連して以下で説明される）を使用し得る。特に、方法は、輻輳下でビデオを含むＵＥの数を最大化しながら、連携した手法でＨＡＳクライアントがベストエフォート無線リソースを使用することを可能にするために、ＬＴＥＲＡＮスケジューラ、ＭＡＣ、およびＲＬＣ情報を使用し得、これは、後述の２つの基本部分において実現され得る。

パート１：アプリケーションレベルの承認制御は、承認されたＵＥの数を最大化しながら実装され得る。この承認制御は、リソースおよび／またはチャンネル制限に起因して、ＨＡＳビデオを再生するための最低（最小）必要ビデオレートを受信することができない非常に低質のチャンネル状態を経験するＵＥを承認しないことにより、いくつかのＲＡＮリソースを解放し得る。この承認制御は、影響を受けたＵＥがビデオセグメントを要求することを停止するまで、または、ネットワーク輻輳が解決されるまで、施行され続け得る。

パート２：すべての承認されたＵＥがビデオを受信することを確実なものとするために、「承認された」ＵＥ間における利用可能なベストエフォートリソースの適切な分配を施行するポリシーを実施すること。この施行は、（ｉ）「より良好な」状態にあるＵＥが選択し得る最大ビデオレートを制限し得る、および、（ｉｉ）ＨＡＳＵＥが「ハングリー状態」にある（すなわち、再生前バッファが満杯でない）ときに、最大アプリケーションレベルスループットを制限し得るアプリケーションレベルポリシーを介して実現され得る。

本方法は、ＨＡＳクライアントの（ＰＲＢからなる）ＲＡＮリソースプールは、他のベストエフォートトラフィックリソースから離間され得るときに最良に動作し得るが、本方法は、これらのリソースプールが組み合わされる状況に拡張され得る。

ベストエフォート（ＢＥ：ＢｅｓｔＥｆｆｏｒｔ）無線接続を使用したＵＥのための承認制御およびポリシー生成のための入力：
本方法において使用され得る入力（すなわち、無線ＲＡＮおよびＨＡＳビデオセッションメトリック）は、以下を含み得る。

Ａ）ＲＡＮリソースプールを共有し得るＨＡＳサービスにアクセスすることを試みるＵＥ（例えば、単一の無線ＢＥベアラを使用する各ＵＥ）の数（リソースプールは、例えば、単一のｅＮＢに関係するリソースであり得る）。この入力は、「Ｎ」と表記され得る。

Ｂ）各ＵＥ番号ｋに対して利用可能な（ビット／秒で測定された）ＨＡＳビデオビットレート。この入力は、次のように表記され得る。

式中、ｋはＵＥインデックスであり、ｍｋは、ＵＥに利用可能な異なるビデオ符号化レートの数である。

Ｃ）任意選択的な入力は、例えば、ゴールド、シルバー、ブロンズなどのＵＥサービス選好を含み得る。

Ｄ）ＰＲＢメトリック当たりの「有用」ビットの平均数の形態で表され得、

のように表記された、各ＵＥｋに対する平均チャンネル状態。「有用」ビットという用語は、再送信されたビットでないデータビットであるビットとみなされ得る。一実施形態において、この入力メトリックは、米国特許出願第１４／７２４，３５２号「ＳｙｓｔｅｍａｎｄＭｅｔｈｏｄｆｏｒＣｏｎｔｒｏｌｌｉｎｇａｎＯｐｅｒａｔｉｏｎｏｆａｎＡｐｐｌｉｃａｔｉｏｎ」において説明される方法を介して計算され得、その内容は、引用によりその全体が組み込まれている。

Ｅ）平均の共有された無線リソースレート（例えば、共有されたリソースプールにおける１秒当たりのＰＲＢの数Ｓ）であり、この入力は、「Ｓ」と表記され得る（例えば、２０ＭｈｚｅＮＢの場合、利用可能な共有リソースレートは、Ｓ＝１００，０００ｐｒｂｓ／秒であり得る）。

Ｆ）ＨＡＳＵＥ間において共有されるように利用可能な、共有された無線リソースの平均割合（例えば、１秒当たりの物理リソースブロック）であり、この入力は、「ｘ」と表記され得る。乗算Ｓ×ｘは、ＨＡＳＵＥ間において共有され得る無線リソースの平均レート（例えば、１秒当たりのＰＲＢの数）を表し得る。乗算Ｓ×ｘは、スケジューリングされた共有リソースレート情報とみなされ得る。

例示的な方法の概括的な動作：
例示的な方法の概括的な動作は、以下の基本ステップを含み得る。

Ｉ）入力を受信する（入力は、上述のように列記される）。

ＩＩ）ＵＥは、順序付けされ得る。この順序付けは、（上述の入力（Ｄ）である）低下するチャンネル状態メトリックに基づき得る。この順序付けは、次のように表記され得る。

チャンネル状態メトリックにおけるより高い値が、より良好なチャンネル状態に対応し得ることに留意されたい。より小さな順序番号をもつＵＥは、より大きな順序番号をもつＵＥより前に承認される。任意選択的なサービス選好クラスがさらに実装される場合（上述の入力（Ｃ）を参照）、式１に基づいて、各サービスクラス内のＵＥが独立して順序付けされ得、次に、クラス間の順序付けが、サービスプロバイダーの選好に従って確立され得る。

ＩＩＩ）承認制御が実装され得る。上述のステップ（ＩＩ）に従って順序付けられたＵＥを使用して、次の式２を満たすＵＥの第１の番号Ｎ’のみが承認され得る。

式中、Ｓおよびｘは、入力（Ｅ）および（Ｆ）から得られ、□は、設定可能なバッファ増加マージンであり得（例えば、この値は、０．１または０．３の間から選択され得る）、入力（Ｂ）からのｒ１（ｋ）は、ＵＥｋに利用可能な最低ビデオレートであり得る。したがって、Ｎ’からＮまでの順序番号をもつＨＡＳＵＥは、承認されないものであり得る。これらの承認されないＵＥのためのポリシーは、０（ゼロ）の最大ビデオレートと０（ゼロ）の最大の許可されたアプリケーションスループットとを割り当てることを含み得、このことが、これらのＨＡＳＵＥがビデオセグメントを要求することを停止するように強制する。式２の左側は、すべての承認されたＵＥに対して最小ビデオレートをサポートするために必要な１秒当たりの物理リソースブロックの平均アグリゲートレートを表す。式２の右側は、増加する再生バッファのためのマージンを可能にするマージンファクター（１＋δ）により低減される、ＨＡＳＵＥ間において共有されるように利用可能であり得る無線リソースの平均レート（例えば、１秒当たりのＰＲＢの数）を表す。

ＩＶ）承認されたＵＥｋに対して、ポリシーは、ＵＥごとのタプルを含み得、これは、ＵＥのためのスループット制約を提供し、これは、＜Ｒ（ｋ）ｍａｘ，Ｔ（ｋ）ｍａｘ＞と表記され得、式中、Ｒ（ｋ）ｍａｘは、選択され得る最大の許可されたビデオビットレートであり、Ｔ（ｋ）ｍａｘは、最大の許可されたスループットであり得る（これらの制限は、ビデオセグメントを要求することにおいてＵＥがどれほど欲張りであり得るかを制約し得る）。Ｔ（ｋ）ｍａｘは、次式を使用して、次のビデオセグメントｎを要求する前に、最小遅延ｄ（ｋ）ｎを計算するアプリケーション機能により使用され得る。

式中、Ｌ（ｋ）ｎは、ＭＰＤまたはマニフェストファイルから知らされたセグメントｎの長さであり得、ｔ（ｋ）ｎは、レート決定機能により測定されたセグメントｎのダウンロード時間であり得る。

Ｖ）ポリシー計算は、次のように、セル／セクタによりサービスされるユーザのＨＡＳユーザ経験をアグリゲートするために、体感品質（ＱｏＥ）効用関数を最大化することにより実施され得る。

式中、ａおよびｂは、設定可能なパラメータであり得る。

ＶＩ）式（１）におけるＵＥの順序付けは、次式により示されるように、順序付けの前側におけるＵＥが後側におけるＵＥより高いレートをもつことを意味する。

これは、可能な順列の数を著しく少なくし得る。すなわち、Ｎ’個のＵＥに対する順列の総数、および、ｍ個の異なるビデオレートクラスは、次のように計算され得る。

この方法は、効用関数の最大値を計算するために単純で完全な数え上げの使用を可能にし得る。例えば、１４の承認されたユーザと４つの異なるビデオレートの場合である（図３に示される例において、順列の数は９５２０である）。効用関数の最大値は、各順列に対して効用関数の値を計算することと、次に、計算された値の間で最大値を選択することにより計算され得る。

特定の例示的な方法
上述の概括的な方法の理解に基づいて、以下の説明は、図５−図８に関連して示される特定の例示的なシステムおよび方法に関する。

図５は、例示的な実施形態により再構成されたネットワーク１０ａを示す。ネットワーク１０ａは、（図６により詳細に示されるように）再構成されたｅＮＢ１０５ａ内に位置し得るネットワークインサイト機能（ＮＩＦ）エージェント４００を含み得る。別のネットワークインサイト機能（ＮＩＦ）４０５が、再構成されたＩＰ−ＣＡＮ１００ａ内に存在し得る。ＮＩＦ４０５は、ネットワークインサイト機能ポリシーメーカー（ＮＩＦＰ：ｎｅｔｗｏｒｋｉｎｓｉｇｈｔｆｕｎｃｔｉｏｎｐｏｌｉｃｙ−ｍａｋｅｒ）４１５を含み得る。ＮＩＦ４０５（および関係するＮＩＦＰ４１５）は、１つを上回る再構成されたｅＮＢ１０５ａから（上述の入力の列記項目により説明される）ベアラメトリックを集めることが可能であり得るが、簡潔であるために、図５には１つのｅＮＢ１０５ａのみが示される。ＮＩＦ４０５は、（上述のように列記された概括的な動作において説明されるように）承認制御およびポリシー作製を実施し得る。ＮＩＦ４０５は、次に、それぞれの再構成されたＩＰ−ＰＤＮ１００１ａおよび／または再構成されたＵＥ１１０ａ内に位置し得るアプリケーション機能１０９ａ／１１５ａを連携制御するために使用され得る。アプリケーション機能１０９ａは、再構成されたＩＰ−ＰＤＮ１００１ａ内の専用独立型サーバであり得る。

図６は、例示的な一実施形態による再構成されたｅＮＢ１０５ａを示す。特に、ｅＮＢ１０５ａは、ＮＩＦエージェント４００を含み得る。ＮＩＦエージェント４００は、ｅＮＢ１０５ａ内に存在する専用プロセッサであり得る独立型専用プロセッサであり得る。または、図６に示されるように、ＮＩＦエージェント４００は、プロセッサ２２０内に位置し得る。ＮＩＦエージェント４００の機能は、図８において概説される方法ステップに関連して以下で説明される。

図７は、例示的な一実施形態によるＮＩＦ４０５を示す。ＮＩＦ４０５（および関係するＮＩＦＰ４１５）は、（図５と図７とに示されるように）専用独立型サーバであり得る。代替的に、ＮＩＦ４０５（およびＮＩＦＰ４１５）は、ＭＭＥ１０８、ＳＧＷ１０１、またはＰＣＲＦ１０６またはＰＧＷ１０３などの、再構成されたＩＰ−ＣＡＮ１００ａ内における別の既存のネットワークノード内に位置し得る。ＮＩＦ４０５は、ＮＩＦ４０５の動作を制御するプロセッサ４０６を含み得る。ＮＩＦＰ４１５は、別の独立型専用プロセッサであり得る。または、代替的に、図７に示されるように、ＮＩＦＰ４１５はプロセッサ４０６内に常駐し得る。ＮＩＦＰ４１５の機能は、図８において概説される方法ステップに関連して以下で説明される。ＮＩＦ４０２は、１つまたは複数のｅＮＢ１０５ａ、ＰＣＲＦ１０６、およびアプリケーション機能１０９ａおよび／または１１５ａと通信することが可能な通信インターフェース４０２をさらに含み得る。メモリ４０４が、さらに、バッファデータに対して提供される。

ＶＲＡＮアーキテクチャを使用すると、ＮＩＦエージェント４００およびＮＩＦ４０５の様々なコンポーネントが、ＶＲＡＮまたは仮想無線コアクラウド内における複数の処理回路および複数の物理ノードにわたって分散され得る。

図８は、例示的な一実施形態による再構成されたネットワーク１０ａ内においてアプリケーションを連携制御する方法を説明する方法のフロー図である。特に、図８は、図５に示される構造の機能を説明する。

図８のステップＳ６００において、ｅＮＢ１０５ａのプロセッサ２２０は、ＮＩＦエージェント４００が、ベアラ当たりのチャンネル情報（上述のように列記された入力Ｄであるベアラ当たりのＰＲＢ当たりのビット数）と一緒に、ベアラ当たりの利用可能なＰＲＢレート情報を抽出することをもたらし得る（そこから、上述の入力の列記項目において列記された入力Ｅが、例えば、ベアラ当たりの利用可能なＰＲＢレートにＨＡＳクライアントの数を乗算することにより、ＮＩＦサーバ４０５により導出され得る）。ＮＩＦエージェント４００は、次に、この情報を、それぞれのベアラに対するグローバルに一意なベアラ識別子と一緒に、ＮＩＦサーバ４０５に渡し得る。一実施形態において、ベアラ当たりの利用可能なＰＲＢレート情報を計算することは、米国特許出願第１４／５３４，９６８号「ＳｙｓｔｅｍａｎｄＭｅｔｈｏｄｆｏｒＤｅｔｅｒｍｉｎｉｎｇＣｅｌｌＣｏｎｇｅｓｔｉｏｎＬｅｖｅｌ」において説明される手順に従って、特定のベアラのために割り当てられると想定され得るＰＲＢの平均数を計算することにより実現され得、その内容は、引用によりその全体が組み込まれている。一実施形態において、ベアラ当たりのＰＲＢ当たりのビット数の計算は、米国特許出願第１４／７２４，３５２号「ＳｙｓｔｅｍａｎｄＭｅｔｈｏｄｆｏｒＣｏｎｔｒｏｌｌｉｎｇａｎＯｐｅｒａｔｉｏｎｏｆａｎＡｐｐｌｉｃａｔｉｏｎ」において説明される手順により実現され得、その内容は、引用によりその全体が組み込まれている。一実施形態において、この集められた情報をＮＩＦサーバ４０５に送信することは、米国特許出願第１４／５３４，４９１号「ＳｙｓｔｅｍＡｎｄＭｅｔｈｏｄｆｏｒＥｘｐｏｒｔｉｎｇＲｅａｌ−ＴｉｍｅＵｓｅｒＥｑｕｉｐｍｅｎｔＡｎｄＢｅａｒｅｒＳｔａｔｅＩｎｆｏｒｍａｔｉｏｎ」において説明される手順を使用して実現され得、その内容は、引用によりその全体が組み込まれている。

図８のステップＳ６０２において、ＮＩＦ４０５のプロセッサ４０６が、ｅＮＢ１０５ａのための目的のベアラに関係する１つまたは複数のそれぞれのアプリケーション機能１０９ａ／１１５ａから、利用可能なビデオレートを受信する。一実施形態において、これらのビデオレートは、ＨＡＳクライアント１１０ａから受信され得る。別の一実施形態において、これらのビデオレートは、アプリケーション機能１０９ａと関連付けられ得るビデオコンテンツサーバ（ＣＤＮ）から受信され得る。

図８のステップＳ６０４において、ＮＩＦサーバ４０５のプロセッサ４０６は、本明細書の「概括的な動作」のセクションにおいて説明されるようにＵＥごとのポリシーを計算し得る。

図８のステップＳ６０６において、ＮＩＦサーバ４０５のプロセッサ４０６は、（アプリケーション機能１０９ａ／１１５ａが、クライアントＵＥ１１０ａのアプリケーション機能１１５ａであるか、ＩＰ−ＰＤＮ１００１ａ内におけるＣＤＮ／ビデオコンテンツサーバ内のアプリケーション機能１０９ａであるかによらず）ポリシーをそれぞれのアプリケーション機能１０９ａ／１１５ａに送信し得る。

アプリケーション機能１０９ａ／１１５ａは、この方法の目的のために、ＨＡＳクライアントにより選択されたビデオレートを制御するためのポリシーを適用し得ることが理解されなければならない。一実施形態において、アプリケーション機能は、ＮＩＦの配信されたポリシーを利用し得、その結果、アプリケーション機能は、米国特許第８，９４９，４４０号「ＳｙｓｔｅｍａｎｄＭｅｔｈｏｄｆｏｒＡｄａｐｔｉｖｅＲａｔｅＤｅｔｅｒｍｉｎａｔｉｏｎｉｎＭｏｂｉｌｅＶｉｄｅｏＳｔｒｅａｍｉｎｇ」において説明されるように適応型レート決定機能として機能し得、これは、引用によりその全体が本明細書に組み込まれている。

一実施形態において、ＮＩＦ４０５のプロセッサ４０６は、次のようにネットワークアプリケーションを制御するようにアプリケーション機能に指示するために、ポリシーを設定するために使用され得る。プロセッサ４０６は、（上述の）式２に基づいて承認制御スキームを使用することにより承認され得る共有されたリソースプールをどのＨＡＳＵＥが使用しているかを計算し得、承認されないＵＥのために最大レートＲ（ｋ）ｍａｘ＝０と最大スループットＴ（ｋ）ｍａｘ＝０とを割り当て、承認されたＵＥに対して最大レートＲ（ｋ）ｍａｘ＝ｒ（ｋ）を割り当て、式中、ｒ（ｋ）は、（次の）式７を満たし、さらに式４において説明される効用関数を最大化する（上述のように列記された）入力（Ｂ）からのレートである。

式７は、最低レート

が、入力（Ｂ）の利用可能なレートの列記項目からのｒ^（ｋ）で置換されているという点で式２とは異なることが留意されなければならない。効用関数は、式５および式７を満たすレートの各順列に対して式４を使用して計算され得る。各ＵＥｋに対するｒ^（ｋ）は、効用関数の値が最大化され得るように選択され得る。プロセッサ４０６は、次に、式８を使用して最大スループットを割り当てるステップを実施し得る。
Ｔ（ｋ）ｍａｘ＝（１＋δ１）Ｒ（ｋ）ｍａｘ −− 式８
式中、δ１は、式２および式７におけるδ以下であり得る設定可能なパラメータである。

図８において説明される例示的な方法に基づいて、ＨＡＳアプリケーションなどのアプリケーションをより多数のＵＥ１０５ａが動作させることを可能にするために、ネットワークの性能が大幅に改善され得る。例えば、図９にグラフで示されるように、シミュレーションは、ビデオを見ることが可能なＵＥの数の７倍の改善（増加）をもたらし得る。（図３に示されるような）ビデオを見ることができる２つのみのＵＥ４００ａの代わりに、承認された１４個のＵＥのグループ５００が存在し（残りの４つが拒否され）、１４個の承認されたＵＥ１０５ａのすべてがビデオを再生し得る。

上述の方法およびシステムがＬＴＥＩＰ−ＣＡＮに限定されないことが理解されなければならない。むしろ、方法およびシステムは、アップリンクまたはダウンリンクスケジューラを使用してセルの物理リソース（すなわち、物理リソースブロックまたは他のリソースユニット）を割り当てる任意の無線技術（例えば、２Ｇ、３Ｇ、４Ｇ、５Ｇなど）に対して実装され得、無線リンクスループットは、リソース割り当てとチャンネル状態メトリックに応じて算出され得る。仮想無線アクセスネットワーク（ＶＲＡＮ）アーキテクチャを使用すると、ＮＩＦエージェント４００およびＮＩＦ４０５の様々なコンポーネントが、ＶＲＡＮまたは仮想無線コアクラウド内における複数の処理回路および複数の物理ノードにわたって分散され得ることがさらに理解されなければならない。

例示的な実施形態が上記のように説明されてきたので、例示的な実施形態が多くの手法で変更され得ることが明らかとなるであろう。このような変形例は、例示的な実施形態の意図される趣旨および範囲から逸脱するものとはみなされるべきではなく、当業者に明らかであるようなこのような変更のすべてが、後述の特許請求の範囲の範囲内に含まれることが意図される。

Claims

無線ネットワーク（１０ａ）においてアプリケーションの動作を連携制御する方法であって、
ネットワークリソースを共有するベアラのためのスケジューリングされた共有リソースレート情報とチャンネル状態情報とを、少なくとも１つのネットワークノードの１つまたは複数のプロセッサにより取得すること（Ｓ６００）であって、チャンネル状態情報が、物理リソースブロック（ＰＲＢ）当たりの有用ビットの平均数を含み、有用ビットが、再送信されたビットではない複数のデータビットである、取得することと、
ベアラに関係する１つまたは複数のアプリケーション機能から、利用可能なビデオレート情報を、１つまたは複数のプロセッサにより受信すること（Ｓ６０２）と、
スケジューリングされた共有リソースレート情報と、チャンネル状態情報と、利用可能なビデオレート情報とに基づいて、ベアラに関係するユーザ機器（ＵＥ）のためのユーザ機器（ＵＥ）ポリシーを、１つまたは複数のプロセッサにより計算することであって、ＵＥポリシーが、ＵＥのためのスループット制約を含む、計算すること（Ｓ６０４）と、
ＵＥのうちの少なくとも１つにより使用されるアプリケーションの動作を連携制御するために、１つまたは複数のアプリケーション機能にＵＥポリシーを、１つまたは複数のプロセッサによりエクスポートすること（Ｓ６０６）と、
を含む、方法。
チャンネル状態情報から導出されるチャンネル状態メトリックに基づいて、ＵＥを順序付けすることと、
チャンネル状態メトリックとＵＥの順序付けとを使用してＵＥのための承認制御を呼び出すことと、
をさらに含む、請求項１に記載の方法。
最小の利用可能なビデオレートによりビデオを再生することをサポートするために必要とされる、スケジューリングされた共有リソースレートの平均アグリゲート値の和が、利用可能なネットワークリソースの平均アグリゲートレート以下である場合、承認制御の呼び出しが、アプリケーションサービスを受信するためにＵＥの第１のサブセットを承認することを含み、利用可能なネットワークリソースの平均アグリゲートレートが、設定可能なマージンファクターを含み、
チャンネル状態メトリックのより高い値が、より良好なチャンネル状態に対応する、
請求項２に記載の方法。
スケジューリングされた共有リソースレート情報が、ハイパーテキスト転送プロトコル適応型ストリーミング（ＨＡＳ）アプリケーショントラフィックを搬送するすべてのベアラに割り当てられることが想定される平均数の物理リソースブロック（ＰＲＢ）を含む平均アグリゲート物理リソースブロック（ＰＲＢ）レートである、
請求項１に記載の方法。
少なくとも１つのネットワークノード（１０ａ）であって、
ネットワークリソースを共有するベアラのためのスケジューリングされた共有リソースレート情報とチャンネル状態情報とを取得すること（Ｓ６００）であって、チャンネル状態情報が、物理リソースブロック（ＰＲＢ）当たりの有用ビットの平均数を含み、有用ビットが、再送信されたビットではない複数のデータビットである、取得することと、
ベアラに関係する１つまたは複数のアプリケーション機能から、利用可能なビデオレート情報を受信すること（Ｓ６０２）と、
スケジューリングされた共有リソースレート情報と、チャンネル状態情報と、利用可能なビデオレート情報とに基づいて、ベアラに関係するユーザ機器（ＵＥ）のためのユーザ機器（ＵＥ）ポリシーを計算することであって、ＵＥポリシーが、ＵＥのためのスループット制約を含む、計算すること（Ｓ６０４）と、
ＵＥのうちの少なくとも１つにより使用されるアプリケーションの動作を連携制御するために、１つまたは複数のアプリケーション機能にＵＥポリシーをエクスポートすること（Ｓ６０６）と、
を行うように構成された１つまたは複数のプロセッサ、
を備える、少なくとも１つのネットワークノード（１０ａ）。
１つまたは複数のプロセッサが、
チャンネル状態情報から導出されるチャンネル状態メトリックに基づいて、ＵＥを順序付けすることと、
チャンネル状態メトリックとＵＥの順序付けとを使用してＵＥのための承認制御を呼び出すことと、
を行うようにさらに構成された、
請求項５に記載の少なくとも１つのネットワークノード。
最小の利用可能なビデオレートによりビデオを再生することをサポートするために必要とされるスケジューリングされた共有リソースレートの平均アグリゲート値の和が、利用可能なリソースの平均アグリゲートレート以下である場合、１つまたは複数のプロセッサが、アプリケーションサービスを受信するためにＵＥの第１のサブセットを承認することにより、承認制御を呼び出し、利用可能なリソースの平均アグリゲートレートが、設定可能なマージンファクターを含み、
チャンネル状態メトリックのより高い値が、より良好なチャンネル状態に対応する、
請求項６に記載の少なくとも１つのネットワークノード。
スケジューリングされた共有リソースレート情報が、ハイパーテキスト転送プロトコル適応型ストリーミング（ＨＡＳ）アプリケーショントラフィックを搬送するすべてのベアラに割り当てられることが想定される平均数の物理リソースブロック（ＰＲＢ）を含む平均アグリゲート物理リソースブロック（ＰＲＢ）レートである、請求項５に記載の少なくとも１つのネットワークノード。