複数のインターネット・プロトコル・フローのグループ・セッション管理およびアドミッション制御
本発明は、１つまたは複数のアプリケーションをサポートするためにアプリケーション・サーバと複数のユーザ機器との間で複数のフローを確立する方法を提供する。この方法は、アプリケーション・サーバからポリシ・サーバへ、グループ要求を送信するステップを含む。グループ要求は、フローを確立するためのものであり、フローの間の１つまたは複数の関係を示す情報を含む。この方法は、アプリケーション・サーバでポリシ・サーバから、関係（１つまたは複数）によって課せられる１つまたは複数の制約を条件としてフローが確立されたかどうかを示す、グループ要求に対する応答を受信するステップをも含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、全般的には通信システムに関し、より具体的には無線通信システムに関する。
【背景技術】
【０００２】
無線通信システムは、通常、無線接続性をユーザ機器に提供するために多数のアクセス・ネットワークを実施し、ユーザ機器は、モバイル・ユニット、移動局、加入者ステーション、加入者、および類似物と称する場合もある。最初の無線通信システムは、ほぼ排他的に音声呼をモバイル・ユーザに提供することに焦点を合わせた。しかし、ユーザ機器の機能性、アクセス・ネットワークによってサポートされるアップリンクおよびダウンリンクでのエア・インターフェース帯域幅、ならびに無線ネットワークの容量は、指数関数的に増加し、増加し続けると期待される。ユーザ機器および無線ネットワークの能力のこの増加は、サービス・プロバイダがより洗練されたアプリケーションをサポートすることを可能にしてきた。たとえば、ユーザ機器は、しばしば、ビデオ・データを受け取ることができる比較的高解像度のカラー・スクリーンと、ビデオ・データを生成し、無線ネットワークを介して送信できるカメラ（またはカメラ用の接続）とを含む。既存の音声／オーディオ・サービスと組み合わせて使用される時に、ネットワークおよびユーザ機器のビデオ能力を使用して、ビデオ通信会議、ゲーム、および他のマルチメディア・アプリケーションをサポートすることができる。
【０００３】
無線通信システム内のアプリケーション・サーバを使用して、ビデオ通信会議、ゲーム、および他のマルチメディア・アプリケーションを含むさまざまなアプリケーションをサポートすることができる。アプリケーションは、サービスを提供するのに使用される複数のインターネット・プロトコル（ＩＰ）フローをオープンすることができる。たとえば、ビデオ会議アプリケーションは、会議のメンバごとにビデオＩＰフローおよびオーディオＩＰフローのためにベアラをオープンすることを要求することができる。この要求は、フローごとの所望のおよび／または要求される待ち時間、遅延、ジッタ、および／または帯域幅を示す情報を含むことができる。この要求は、通常はポリシ制御およびルール機能（ｐｏｌｉｃｙ ｃｏｎｔｒｏｌ ａｎｄ ｒｕｌｅｓ ｆｕｎｃｔｉｏｎ、ＰＣＲＦ）に送信され、ＰＣＲＦは、ＰＣＲＦによって使用される各メンバのユーザ・プロファイル内で示される優先順位に基づいて、フローごとに要求されるリソースを割り当てることを試みる。その後、ＰＣＲＦは、メンバに接続性を提供するアクセス・ネットワーク（１つまたは複数）に、ベアラごとにリソースの要求を送信する。
【０００４】
各ＩＰフローは、ＰＣＲＦによって別々に要求されるので、アクセス・ネットワーク（１つまたは複数）は、セッションに調整されない別々のＩＰフローを見、たとえば、アクセス・ネットワークは、ユーザごとにビデオＩＰフローとは独立にオーディオＩＰフローをオープンし、扱う。したがって、アクセス・ネットワークは、輻輳した状況でオーディオＩＰフローを確立することを可能にするが、関連するビデオＩＰフローを可能にしない場合がある。しかし、会議のビデオ部分が重要と考えられる場合には、これは、オーディオＩＰフローと関連するビデオＩＰフローとの両方を確立できる時に限ってユーザを受け入れることの望みに矛盾する可能性がある。その代わりに、アクセス・ネットワークが、ユーザのサブセットについてオーディオＩＰフローおよびビデオＩＰフローにリソースを割り当てるが、他のユーザのオーディオＩＰフローを拒否する場合がある。会議のビデオ部分が重要と考えられない場合には、これは、少なくともオーディオＩＰフローを使用して会議に参加するユーザの人数を増やすためにビデオＩＰフローの前にオーディオＩＰフローを許すことの望みに矛盾する可能性がある。
【０００５】
この問題に対処する１つの従来の手法は、アプリケーションに関連するＩＰフローのためのリソースの所望の割当を近似するために異なるＩＰフローに関連する優先順位を調整するために、ネットワーク内の優先順位制御機構を使用することである。たとえば、無線通信システムは、通常、各ユーザに関連する優先順位を示すユーザ・プロファイルを維持するポリシおよび課金ルール機能（ｐｏｌｉｃｙ ａｎｄ ｃｈａｒｇｉｎｇ ｒｕｌｅｓ ｆｕｎｃｔｉｏｎ、ＰＣＲＦ）を実施する。ＰＣＲＦは、アプリケーションにとってそれほどクリティカルではないＩＰフローから外れてリソースをステアリングしながら、より高い優先順位のＩＰフローに向けてリソースを案内するために、各ユーザに関連するさまざまなＩＰフローの優先順位を調整することができる。しかし、この手法は、所望のリソース割当を近似するリソース割当につながる値を優先順位にセットするために、ある量の当て推量を必要とする。優先順位が正しくセットされない場合には、異なるＩＰフローへのリソースの実際の割当が、所望の割当から大きく逸脱する可能性がある。さらに、異なるＩＰフローの優先順位を単純に調整することは、同一セッションに属する異なるユーザのＩＰフローの相関を可能にはしない。アプリケーションの必要に基づくフロー優先順位の動的変更も、現在の技術では不可能である。たとえば、異なるＩＰフローの優先順位の単純な調整は、複数の参加者を有するビデオ会議セッションまたはゲーム・セッションのオーディオＩＰフローおよび／またはビデオＩＰフローの間の所望の相関をネットワークが判定することを可能にしない。さらに、ビデオ会議アプリケーションは、ＰＣＲＦからのフィードバックに基づいてＩＰフローの優先順位関係を調整できないはずである。
【発明の概要】
【課題を解決するための手段】
【０００６】
開示される主題は、上で示された問題のうちの１つまたは複数の影響に対処することを対象とする。次では、開示される主題のいくつかの態様の基本的な理解を提供するために、開示される主題の単純化された概要を提示する。この概要は、開示される主題の網羅的概要ではない。開示される主題の主要なまたはクリティカルな要素を識別することも、開示される主題の範囲を区切ることも、意図されていない。その唯一の目的は、後で述べるより詳細な説明の前置きとして、単純化された形でいくつかの概念を提示することである。
【０００７】
一実施形態では、１つまたは複数のアプリケーションをサポートするためにアプリケーション・サーバと複数のユーザ機器との間で複数のフローを確立する方法が提供される。この方法は、アプリケーション・サーバからポリシ・サーバへグループ要求を送信するステップを含む。グループ要求は、フローを確立するためのものであり、フローの間の１つまたは複数の関係を示す情報を含む。この方法は、アプリケーション・サーバでポリシ・サーバから、関係（１つまたは複数）によって課せられる１つまたは複数の制約を条件としてフローが確立されたかどうかを示す、グループ要求に対する応答を受信するステップをも含む。
【０００８】
もう１つの実施形態では、１つまたは複数のアプリケーションをサポートするためにアプリケーション・サーバとユーザ機器との間でフローを確立する方法が提供される。この方法は、ポリシ・サーバでアプリケーション・サーバからフローを確立するためのグループ要求を受信するステップを含む。グループ要求は、フローの間の１つまたは複数の関係を示す情報を含む。この方法は、ポリシ・サーバで、関係（１つまたは複数）によって課せられる１つまたは複数の制約を条件としてフローを確立できるかどうかを判定するステップをも含む。この方法は、ポリシ・サーバからアプリケーション・サーバへ、フローが確立されたかどうかを示すグループ要求に対する応答を送信するステップをも含む。
【０００９】
第３の実施形態では、１つまたは複数のアプリケーションをサポートするためにアプリケーション・サーバとユーザ機器との間でフローを確立する方法が提供される。この方法は、ポリシ・サーバでアプリケーション・サーバから、フローを確立するためのグループ要求を受信するステップを含む。グループ要求は、フローの間の１つまたは複数の関係を示す情報を含む。この方法は、ポリシ・サーバで、関係（１つまたは複数）によって課せられる１つまたは複数の制約を条件としてフローを確立できるかどうかを判定するステップをも含む。この方法は、ポリシ・サーバからアプリケーション・サーバへ、フローが確立されたかどうかを示すグループ要求に対する応答を送信するステップをも含む。この方法は、ポリシ・サーバが、存在するグループ要求に関するＩＰフローの間の関係を変更するためにアプリケーション・サーバから追加要求を受信するステップをも含む。
【００１０】
第４の実施形態では、１つまたは複数のアプリケーションをサポートするためにアプリケーション・サーバとユーザ機器との間でフローを確立する方法が提供される。この方法は、ポリシ・サーバでアプリケーション・サーバから、フローを確立するためのグループ要求を受信するステップを含む。グループ要求は、フローの間の１つまたは複数の関係を示す情報を含む。この方法は、ポリシ・サーバで、関係（１つまたは複数）によって課せられる１つまたは複数の制約を条件としてフローを確立できるかどうかを判定するステップをも含む。この方法は、ポリシ・サーバからアプリケーション・サーバへ、フローが確立されたかどうかを示すグループ要求に対する応答を送信するステップをも含む。この方法は、ポリシ・サーバが、加入者のプロファイル、グループ・プロファイル、および／またはアプリケーションとポリシ・サーバとの間のネゴシエーションに基づいて、異なるアクセス・ネットワーク技術で失敗したベアラ（１つまたは複数）またはフロー（１つまたは複数）のリソースの割当を試みるステップをも含む。
【００１１】
開示される主題を、添付図面に関連して解釈される次の説明を参照することによって理解することができ、添付図面では、類似する符号が、類似する要素を識別する。
【図面の簡単な説明】
【００１２】
【図１】無線通信システムの第１の例示的実施形態での情報フローを概念的に示す図である。
【図２】無線通信システムの第２の例示的実施形態を概念的に示す図である。
【図３】１つのアプリケーションに関連するフローの間の関係を確立する方法の１つの例示的実施形態を概念的に示す図である。
【発明を実施するための形態】
【００１３】
開示される主題は、さまざまな変更および代替形態を許すが、その特定の実施形態を、例として図面に示し、本明細書で詳細に説明する。しかし、特定の実施形態の本明細書での説明が、開示される主題を開示される特定の形態に限定することを意図されたものではなく、逆に、その意図が、添付の特許請求の範囲に含まれるすべての修正形態、同等物、および代替形態を包含することであることを理解されたい。
【００１４】
例示的実施形態を、下で説明する。明瞭さのために、実際の実施態様の特徴の一部が、本明細書で説明されない。もちろん、すべてのそのような実際の実施形態の開発で、実施態様ごとに異なるシステム関連制約およびビジネス関連制約の遵守など、開発者の特定の目標を達成するために、多数の実施態様固有の判断を行わなければならないことを了解されたい。さらに、そのような開発努力が、複雑で時間のかかるものである可能性があるが、それでも、本開示の利益を有する当業者の日常の仕事であることを了解されたい。
【００１５】
開示される主題を、これから、添付図面を参照して説明する。さまざまな構造、システム、およびデバイスが、説明のみのために、また、当業者に周知の詳細で本発明を不明瞭にすることがないように、図面では概略的に示されている。それでも、添付図面は、開示される主題の例示的な例を記述し、説明するために含まれる。本明細書で使用される単語および句は、当業者によるこれらの単語および句の理解と一貫する意味を有すると理解され、解釈されなければならない。用語または句の特殊な定義すなわち、当業者によって理解される通常の慣例的な意味とは異なる定義が、本明細書での用語または句の一貫した使用によって暗示されることは、意図されていない。用語または句が、特殊な意味すなわち、当業者によって理解されるものとは異なる意味を有することが意図される範囲で、そのような特殊な定義は、用語または句の特殊な定義を直接に明確に提供する定義的な形で本明細書で特に示される。
【００１６】
一般的に言って、本願は、アプリケーションが通信システム内のデータ・フローの間の関係を指定することを可能にするために通信システム内で実施できる技法および機能性を説明する。関係を、個々のユーザまたはユーザのグループの間のデータ・フローについて指定することができる。本明細書で説明される制御能力の例示的実施形態は、アプリケーション（ビデオ会議、ゲーム、および類似物など）が、合同で所望のサービスを作成する複数のアップリンクおよび／またはダウンリンクのデータ・フローの間の１つまたは複数の関係を示し、ポリシ・サーバからのフィードバックに基づいてこれらの関係を変更することを可能にする。たとえば、アプリケーションは、参加者のリスト、サービスを提供するのに使用されるデータ・フローのセット、データ・フローの優先順位、およびデータ・フローの間の関係を含む情報をポリシ・サーバに送信することができる。その後、ポリシ・サーバは、アプリケーションによって提供された情報を使用して、フロー・ポリシおよび／またはルールを確立し、たとえば１つまたは複数のアクセス・ネットワークに、データ・フローのためのリソースを要求することができる。データ・フローのセットは、複数のユーザおよび複数の技術にまたがることができ、ユーザは、単一のまたは複数のサービス・プロバイダによってサービスされ得る。各データ・フローを、そのデータ・フローの優先権およびそのデータ・フローの相互依存性を反映する形で他のデータ・フローに関係付けることができる。ポリシ・サーバによってアプリケーション・サーバに提供される情報に基づいて、アプリケーション・サーバは、以前に確立されたグループ要求に関する変更要求をポリシ・サーバに発行することを選択することができる。
【００１７】
１つの例示的実施形態では、アプリケーションは、特定のサービスを作成するために１ユーザあたり４つのデータ・フローを使用することができる、すなわち、フローＡ、Ｂ、Ｃ、およびＤを、そのサービスをサポートするのに使用することができる。記号Ａ１は、ユーザ１のためのフローＡを示し、Ｂ２は、ユーザ２のためのフローＢを示し、以下同様である。アプリケーションによって指定できる１つの例示的な関係は、Ａ１およびＡ２が、最高の優先順位を与えられ、一緒に割り当てられるか全く割り当てられないかのどちらかにならなければならないことである。アプリケーションは、フローＢ１、Ｂ２、Ｃ１、およびＣ２が、相互に関係し、同時に割り当てられなければならないことを示すこともできる。アプリケーションは、さらに、フローＤ１およびＤ２が、最低の優先順位であり、他のフローのいずれに対しても相互依存性を有しないことを示すことができる。その後、ポリシ・サーバは、指定された関係を使用して、ポリシ・ルールを確立し、リソースを要求することができる。本明細書で詳細に述べるように、関係は、満足されなければならない厳しいルールおよび／または可能な場合に満足されなければならない相対的に厳しくないルールを示すことができる。さらに、ポリシ・サーバおよびアプリケーションは、指定された関係の性質をネゴシエートすることができる。たとえば、ポリシ・サーバが、関係の初期セットによって関係付けられる十分な個数のフローをサポートするためのリソースを入手できない場合には、ポリシ・サーバおよびアプリケーションは、サービスをサポートするのに十分な個数のフローのためのリソースを入手することを試みるために、関係の新しいセットをネゴシエートすることができる。
【００１８】
図１に、無線通信システム１００の第１の例示的実施形態での情報フローを概念的に示す。図示の実施形態では、無線通信システム１００は、１つまたは複数のアプリケーション１０５、１つまたは複数のポリシ制御およびルール機能（ＰＣＲＦ）１１０、ならびにエア・インターフェースを介して無線接続性を提供するのに使用される１つまたは複数のアクセス・ネットワーク１１５を含む。単一のアプリケーション１０５、ＰＣＲＦ １１０、およびアクセス・ネットワーク１１５が、無線通信システム１００内の情報のフローを明瞭に例示するために図１に示されている。しかし、本開示の利益を有する当業者は、無線通信システム１００の代替実施形態が、任意の個数のアプリケーション１０５、ＰＣＲＦ １１０などのポリシ・サーバ、およびアクセス・ネットワーク１１５を含むことができることを了解するに違いない。さらに、当業者は、アクセス・ネットワーク１１５に関連してまたはこれに加えて無線接続性を提供するために、他のタイプのデバイスを使用できることを了解するに違いない。例示的デバイスは、基地局、基地局ルータ、ＩＥＥＥ標準規格および／またはプロトコルに従って動作するアクセス・ポイント、Ｂｌｕｅｔｏｏｔｈ標準規格および／またはプロトコルに従って動作するデバイス、ならびに類似物を含む。
【００１９】
アプリケーション１０５は、当初に、サービスに関連する情報フローをサポートするようにベアラに要求する。情報フローは、無線通信システム１００内のユーザ機器に情報を提供し、ユーザ機器から情報を受信することが意図されている。要求は、この情報をアプリケーション１０５とＰＣＲＦ １１０との間で搬送するために定義されるメッセージ、データ構造、および／または言語を使用してＰＣＲＦ １１０に提供される。また、アプリケーション１０５は、要求されるフローの間の所望の関係を示す情報を提供し、フローへのリソースの割当を、要求される関係をサポートし、これと一貫する形で要求する。ＰＣＲＦ １１０は、オプションで、要求の受信を肯定応答することができる。要求の受信時に、ＰＣＲＦ １１０は、ベアラの個数、要求されるベアラの終端点（たとえば、ユーザ機器識別子、デバイスに割り当てられたＩＰアドレス、およびサブスクリプションＩＤ）、帯域幅、待ち時間、および／またはジッタ要件を示す情報など、ベアラ要求内の情報を使用して、ベアラの動作を支配するポリシおよび／またはルールを定式化することができる。定式化されるポリシおよび／またはルールは、ベアラ／フローとベアラ要求内で指定されたすべての優先順位との間の関係をも反映する。
【００２０】
ＰＣＲＦ １１０は、提供されるポリシおよび／またはルールに従ってベアラを確立する要求と共に、フロー・ポリシおよび／またはルールをアクセス・ネットワーク１１５に送信する。この要求は、フローおよび／またはベアラのそれぞれの識別子を含むこともできる。アクセス・ネットワーク１１５は、ベアラおよび／またはフローの相互依存性とベアラおよび／またはフローに関連する優先順位とを反映するポリシに従って、要求されたベアラおよび／またはフローを確立することを試みる。たとえば、アクセス・ネットワーク１１５は、指定されたポリシおよび／または優先順位に従って使用可能なリソースを割り当てることによって、要求されたベアラおよび／またはフローを確立することを試みることができる。その後、アクセス・ネットワーク１１５は、どのベアラおよび／またはフローが成功して確立されたのかならびにどのベアラおよび／またはフローが成功して確立されなかったのかを示すメッセージを返すことができる。その後、ＰＣＲＦ １１０は、要求されたベアラおよび／またはフローを確立する試みの成功および／または失敗についてアプリケーション１０５に知らせる。アプリケーション１０５およびＰＣＲＦ １１０は、いくつかの場合に、本明細書で述べるように、要求されたベアラおよび／またはフローを確立する試みの成功および／または失敗に基づいて、要求されたリソース、関係、優先順位または他のパラメータをネゴシエートすることができる。
【００２１】
図２に、無線通信システム２００の第２の例示的実施形態を概念的に示す。図示の実施形態では、アプリケーション・サーバ２０５は、相互に関係するフロー２１５、２１６、２１７、２１８を使用してユーザ機器２１０に１つまたは複数のアプリケーションを提供するのに使用される。たとえば、フロー２１５（１）を使用して、会議、ゲーム、または他の通信アプリケーションに使用されるオーディオ・インターネット・プロトコル（ＩＰ）フローを搬送することができる。フロー２１５（２）を使用して、同一のアプリケーションのビデオＩＰフローを搬送することができる。フロー２１５（１〜２）は、相互に関係し、アプリケーション・サーバ２０５は、フロー２１５の間の関係を指定し、リソースがフロー２１５のために割り当てられる時にこれらの関係が維持されることを要求することができる。フローの対２１６、２１７、２１８も、オーディオＩＰフローおよびビデオＩＰフローなどの相互に関係するフローの対を表すことができる。さらに、フロー２１５、２１６、２１７、２１８は、アプリケーション・サーバ２０５によって提供される特定のアプリケーションに応じて、情報のアップリンクおよび／またはダウンリンクのフローをサポートすることができる。
【００２２】
アプリケーション・サーバ２０５は、アプリケーション・サーバ２０５がベアラおよび／またはフロー２１５、２１６、２１７、２１８の確立を要求する時にフロー２１５、２１６、２１７、２１８の間の関係を指定する。たとえば、アプリケーション・サーバ２０５が、ユーザ機器２１０のユーザの間でビデオ会議を確立することを試みる場合に、アプリケーション・サーバ２０５は、要求されるフロー２１５、２１６、２１７、２１８ならびにこれらのフローの間の相互関係を示す要求をＰＣＲＦサーバ２２０に送信することができる。これらのフローの間の相互関係の１つの可能な組は、フローの対２１５、２１６、２１７、２１８を独立に確立できるが、フローの対２１５、２１６、２１７、２１８のそれぞれの中の個々のフローを一緒に確立しなけれればならないことを述べる。その代わりに、フローの対２１５、２１６、２１７、２１８のそれぞれの中の個々のフローの一方がより重要と考えられる場合には、これらのフローの間の相互関係のもう１つの可能な組は、できる限り多数のフロー２１５、２１６、２１７、２１８が確立されるが、フローの対２１５、２１６、２１７、２１８のうちの好ましい１つだけが確立されなければならないことを要求することができる。たとえば、指定される相互関係は、フローの対２１５、２１６、２１７、２１８のそれぞれのうちのオーディオＩＰフロー２１５（１）が優先的に確立されることを要求することができる。
【００２３】
フローの間の関係は、ユーザ機器２１０に関連する優先順位を反映することもできる。たとえば、ユーザ機器２１０（１）を、ビデオ会議の議長とすることができ、より高い優先順位を与えることができる。アプリケーション・サーバ２０５は、この優先順位を反映する関係を指定することができ、たとえば、アプリケーション・サーバ２０５は、ビデオ会議を開始できる前に、議長ユーザ機器２１０（１）へのフロー２１５が割り当てられなければならないことを述べる、ユーザ機器２１０に関連するフローの間の関係を指定することができる。アプリケーション・サーバ２０５は、オーディオＩＰフロー２１５（１）とビデオＩＰフロー２１５（２）との両方が、ビデオ会議を行うために確立されなければならないことを指定することもできる。その代わりに、アプリケーション・サーバ２０５は、オーディオＩＰフロー２１５（１）など、フローのうちの１つだけが、ビデオ会議を開始できる前に確立されることを指定することができる。いくつかの実施形態では、アプリケーション・サーバ２０５は、ユーザ機器のグループの間の相互関係を指定することもできる。たとえば、アプリケーション・サーバ２０５は、ユーザ機器２１０のそれぞれへの少なくとも１つのフロー２１５、２１６、２１７、２１８が、ビデオ会議を開始できる前に確立されなければならないという関係を指定することができる。もう１つの例として、アプリケーション・サーバ２０５は、少なくとも最小個数のユーザ機器２１０へのフローが、ビデオ会議を開始できる前に確立されなければならないことを指定することができる。
【００２４】
ＰＣＲＦサーバ２２０は、アプリケーション・サーバ２０５から受信された情報に基づいて、要求されたフロー２１５、２１６、２１７、２１８のポリシおよび／またはルールを確立する。確立されたポリシおよび／またはルールをさまざまなアクセス・ネットワーク２２５に送信することができ、このアクセス・ネットワーク２２５は、ＰＣＲＦサーバ２２０によって伝えられたポリシおよび／またはルールによって課せられる制約を条件として、リソースを割り振ることを試みる。図示の実施形態では、アクセス・ネットワーク２２５は、要求されたフロー２１５、２１６、２１８をサポートするためにリソースを割り当てることができるが、要求されたフロー２１７をサポートするためにリソースを割り当てることはできない（破線によって示されるように）。したがって、アクセス・ネットワーク２２５（１、３）は、フロー２１５、２１６、２１８のリソースの成功の割当を示す肯定応答をＰＣＲＦサーバ２２０に送信する。アクセス・ネットワーク２２５（２）も、リソースが要求されたフロー２１７に成功して割り当てられなかったことを示す否定応答をＰＣＲＦサーバ２２０（２）に送信することができる。本開示の利益を有する当業者は、ＰＣＲＦサーバ２２０および／またはアクセス・ネットワーク２２５が、同一のまたは異なる標準規格、プロトコル、および／またはアクセス技術に従って動作できることを了解するに違いない。
【００２５】
ＰＣＲＦサーバ２２０は、アプリケーション・サーバ２０５がどのように進行すべきかを判断できるようにするために、アプリケーション・サーバ２０５に肯定応答の内容を伝える。一実施形態では、アプリケーション・サーバ２０５は、十分な個数の要求されたベアラおよび／またはフローが割り当てられたと判定し、アプリケーションを開始する。その後、フロー２１７の要求を、棄て、キューに入れ、かつ／または周期的に再サブミットすることができる。代替案では、アプリケーション・サーバ２０５は、フロー２１７のうちの１つまたは複数を、アプリケーションを開始する前に割り当てなければならないと判定することができる。その後、アプリケーション・サーバ２０５は、ベアラ要求および／またはフロー要求を改訂しまたは変更することができる。たとえば、アプリケーション・サーバ２０５は、より少ない帯域幅またはより弱い遅延制約および／もしくはジッタ制約を要求することができる。もう１つの例として、アプリケーション・サーバ２０５は、フロー２１７が一緒に割り当てられることを要求した以前の関係を変更し、フロー２１７のうちの少なくとも１つが割り当てられることを要求する新しい関係を送信することができる。アプリケーション・サーバ２０５およびＰＣＲＦサーバ２２０は、十分な個数のユーザ機器２１０が許されたとアプリケーション・サーバ２０５が判定するまで、または終了判断基準に達するまで、このネゴシエーション・プロセスを反復して繰り返すことができる。
【００２６】
フロー２１５、２１６、２１７、２１８の間の関係を、動的に変更することもできる。たとえば、要求されたフロー２１５、２１６、２１８が確立された後に、アプリケーション・サーバ２０５は、ユーザ機器２１０へのアプリケーションの提供を開始することができる。その後、無線通信システム２００内のさまざまなエンティティは、存在するフロー２１５、２１６、２１８を使用してアプリケーションが提供されつつある間に、動作条件および／または動作パラメータを監視することができる。無線通信システム２００内の変化は、アプリケーション・サーバ２０５によって指定された関係の変更につながる可能性がある。たとえば、アクセス・ネットワーク２２５によってサポートされるエア・インターフェースに関連する環境条件および／またはチャネル条件の変化は、アクセス・ネットワーク２２５がより多くのまたはより少ないリソースを割り当てることを可能にする場合があり、これが、アクセス・ネットワーク２２５がより多くのまたはより少ないフローをサポートすることを可能にする場合がある。この情報を、アプリケーション・サーバ２０５に伝えることができ、アプリケーション・サーバ２０５は、この情報を使用して、たとえばより多くのリソースが使用可能である時により厳密な関係を要求することによって、またはより少ないリソースが使用可能である時により厳密でない関係を要求することによって、指定された関係を変更するかどうかを判断することができる。もう１つの例として、追加のユーザ機器が、アプリケーション・サーバ２０５によって提供されるサービスへの許可を要求する場合があり、あるいは、既存のフローを有する他のユーザ機器が、サービスを中断する場合がある。たとえば、より少ないユーザ機器がアプリケーションを使用することを求める時により厳密な関係を要求することによって、またはより多くのユーザ機器がアプリケーションを使用することを求める時により厳密でない関係を要求することによる、ユーザ機器の加算または減算に応答して、関係を変更することができる。
【００２７】
図３に、１つのアプリケーションに関連するフローの間の関係を確立する方法３００の１つの例示的実施形態を概念的に示す。図示の実施形態では、ユーザは、（３０５で）オーディオＩＰフローおよび／もしくはビデオＩＰフローまたは他のＩＰデータ・フローなどの複数のフローによってそれぞれがサービスされる複数のユーザを有するサービスについてグループ・セッションを開始する。開始するユーザは、グループの議長であり、ＵＥ−Ｍと指定されるユーザ機器を操作する。グループ内の１人または複数の他のユーザは、ＵＥと指定されるユーザ機器を操作する。議長は、方法３００の例示的実施形態でグループ・セッションを開始するが、本開示の利益を有する当業者は、無線通信システムへのアクセスを有する任意のエンティティが、その代わりにグループ・セッションを開始できることを了解するに違いない。グループ・セッションの開始（３０５での）は、グループ・セッションの、Ｇｒｏｕｐ＿ＩＤなどの識別子を定義することおよび／またはこれを提供することを含むことができる。
【００２８】
グループ・セッションが開始されることに応答して、グループ・セッションのサービスまたはアプリケーションを提供するアプリケーション・サーバ（ＡＳ）は、たとえばアプリケーション・サーバ内のメモリもしくは他のストレージ・デバイスまたは他所で実施されるデバイスから、グループ・セッションに関連するデータを取り出す。その後、アプリケーション・サーバは、たとえばＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）招待メッセージをユーザ機器に提供することによって、ユーザをグループ・セッションに招待する（３０５で）。招待メッセージを、１つまたは複数のアクセス・ネットワーク（ＡＮ）およびシステム内の任意の他の介在するネットワークまたはサポートするネットワークを介してユーザ機器に配送することができる。さまざまな代替実施形態では、参加者を、複数のアクセス技術、ネットワーク、および／またはサービス・プロバイダにまたがってネットワークにアタッチし、かつ／または接続することができる。その後、ユーザ機器およびアプリケーション・サーバは、セッションを当初に定義するのに使用されるパラメータを定義し、判定し、ネゴシエートし、合意することができる。
【００２９】
アプリケーション・サーバは、ネゴシエートされたセッション・パラメータを使用して、アプリケーションによって提供されるフローの間の１つまたは複数の関係を判定する（３１０で）。関係は、グループ・サービス品質許可要求（Ｇｒｏｕｐ Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｒｅｑｕｅｓｔ）メッセージなどの許可要求メッセージを定義するのに使用される。一実施形態では、グループＱｏＳ許可要求メッセージは、グループ・セッションに参加するユーザのリスト、グループ・セッションに参加するユーザのそれぞれに関連するデータ・フローのリスト、データ・フローおよび／またはユーザの間の判定された関係、ならびにデータ・フローおよび／またはユーザに関連する優先順位を含む。本開示の利益を有する当業者は、許可要求メッセージの代替実施形態が追加情報を含むことができることを了解するに違いない。その後、許可要求メッセージは、ＰＣＲＦサーバなどの１つまたは複数のポリシ・サーバに送信される（３１５で）。
【００３０】
ポリシ・サーバ（１つまたは複数）は、許可要求メッセージから情報を抽出し、この情報を使用して、フロー関係ならびにベアラおよび／またはフローに関連する優先順位によって課される制約を条件として、要求されるベアラおよび／またはフローを確立するためのポリシおよび／またはルールを判定する（３２０で）。たとえば、各ＰＣＲＦは、グループ許可要求を処理し、適当なポリシ／ルールを判定し、グループ・セッションのためのリソースを許可しまたは要求することができる。各ＰＣＲＦは、グループ相関ＩＤ（Ｇｒｏｕｐ Ｃｏｒｒｅｌａｔｉｏｎ−ＩＤ、ＧＣ−ＩＤ）などの識別子をグループ・セッションに割り当てることもできる。その後、ＰＣＲＦは、リソースがグループ・セッションの参加者に割り当てられることを要求するメッセージを送信する（３２５で）。このメッセージは、アプリケーション・サーバによって送信されたフロー関係を反映するポリシおよび／またはルールを条件としてリソースが割り当てられなければならないことをも示す。たとえば、ＰＣＲＦは、サービスまたはアプリケーションを受信しつつあるユーザのうちの１人または複数に無線接続性を提供する各アクセス・ネットワークに接続セットアップ（Ｃｏｎｎｅｃｔｉｏｎ−Ｓｅｔ−Ｕｐ）メッセージを送信することができる。このメッセージは、各ユーザに関連するフローごとの、リソースの割当と専用ベアラの確立とをトリガする。
【００３１】
アクセス・ネットワーク（１つまたは複数）は、要求されたリソースを割り当て（３３０で）、専用ベアラを確立することを試みる。一実施形態では、ＬＴＥのｅＮＢなどのアドミッション制御の責任を負うアクセス・ネットワーク内のネットワーク・エンティティが、ＧＣ−ＩＤと一緒にグループ・セッションを許す要求を受信し、その要求を処理する。その後、このエンティティは、要求されたベアラおよび／またはフローに、使用可能なリソースを割り当てる（３３０で）。リソースが、グループ・セッション内の要求されたフローのすべてを許すために使用可能ではない場合には、アドミッション制御エンティティは、残りのフローのために適当なリソースをキューに入れることができる。すべての要求されたフローのために十分なリソースが使用可能になる場合に、アクセス・ネットワークは、要求されたベアラおよび／またはフローにリソースを割り当てることができる（３３０で）。しかし、たとえばあらかじめ定められた時間間隔内に、十分なリソースが使用可能にならない場合には、リソースを、要求されたベアラおよび／またはフローのサブセットに割り当てることしかできない（３３０で）。たとえば、最高優先順位フローがまずリソースを割り当てられる（３３０で）ように、ベアラおよび／またはフローの優先順位に基づいて、リソースの限られたプールを、要求されたベアラおよび／またはフローのサブセットに割り当てることができる（３３０で）。
【００３２】
いくつかの実施形態では、無線通信システムは、複数の無線アクセス技術をサポートするアクセス・ネットワークを含むことができる。アクセス・ネットワーク（１つまたは複数）は、要求されたリソースを割り当て（３３０で）、初期無線アクセス技術を使用して専用ベアラを確立し、この初期無線アクセス技術は、加入者のプロファイル内で、グループ・プロファイル内で、および／またはアプリケーションとポリシ・サーバとの間のネゴシエーションによって指定され得る。初期無線アクセス・ネットワーク技術を使用してすべての要求されたフローを許すリソースが使用可能ではない場合には、アドミッション制御エンティティは、異なるアクセス・ネットワーク技術を使用してリソースを割り当てる（３３０）ことを試みることができる。たとえば、ポリシ・サーバは、加入者のプロファイル、グループ・プロファイル、および／またはアプリケーションとポリシ・サーバとの間のネゴシエーションに基づいて、異なるアクセス・ネットワーク技術で、失敗したベアラ（１つまたは複数）またはフロー（１つまたは複数）のためのリソースを割り当てる（３３０）ことを試みることができる。
【００３３】
割当プロセスが完了した後に、アクセス・ネットワークは、リソースが成功して割り当てられたかどうか、ならびにどのベアラおよび／またはフローが割り当てられたリソースを受け取ったのかを示すメッセージを返す（３３５で）。この方法は、ベアラおよび／またはフローを確立するのに使用されたアクセス・ネットワーク技術を示す情報を含むこともできる。
【００３４】
ＰＣＲＦは、アクセス・ネットワークから受信する応答を処理し（３４０で）、要求されたベアラおよび／またはフローにリソースを割り当てる試みの結果についてアプリケーション・サーバに通知する。アプリケーション・サーバは、十分な個数のフローおよび／またはユーザが許されたと判定する時に、要求されたセッションを開始することができる。たとえば、アプリケーション・サーバは、すべての参加者が要求されたフローの少なくとも一部のためにリソースを割り当てられた場合に限って、要求されたセッションを開始することができる。代替案では、アプリケーション・サーバは、議長および少なくとも選択された人数のユーザが許された時に、要求されたセッションを開始することができる。
【００３５】
アプリケーション・サーバは、要求されたベアラおよび／またはフローのすべてより少数が、当初に判定されたサービス関係（１つまたは複数）によって課せられる制約を条件として許された時に、ＰＣＲＦとネゴシエートすることもできる（３４５で）。たとえば、ＰＣＲＦは、許されなかったユーザおよび／またはフローを識別することができる。アプリケーション・サーバは、ＰＣＲＦ（１つまたは複数）からの応答を処理し、すべてのユーザおよびフローを許すことに失敗する場合に、アプリケーション・サーバは、十分な数のユーザおよびフロー高優先順位フローが実現性のあるグループ・セッションを有するために許されたかどうかを判定する。不十分な数が許された場合には、アプリケーション・サーバは、要求を変更し（たとえば、要求されるリソースおよび／またはフロー相互関係を変更することによって）、変更された要求をＰＣＲＦに送り返すことができ、ＰＣＲＦは、その後、要求されたリソース割当をアクセス・ネットワークから入手することを試みることができる。このプロセスは、反復して進行することができる。
【００３６】
リソースが、要求されたベアラおよび／またはフローの少なくともサブセットに割り当てられた後に、アプリケーション・サーバは、相互に関係するフローを使用してグループ・セッションを開始することができる（３４５で）。本明細書で述べるように、通信システム内の要素は、さまざまなシステム・パラメータおよび／または条件を監視し続けることができ、その結果、フロー関係および／または要求されるリソースを、通信システムの状態の変化に応答して変更できるようになる。この監視は、相互に関係するフローを使用するグループ・セッションの提供（３４５での）と同時に発生することができる。
【００３７】
開示される主題の諸部分および対応する詳細な説明は、ソフトウェアすなわち、コンピュータ・メモリ内のデータ・ビットに対する動作のアルゴリズムおよび記号表現に関して提示される。これらの説明および表現は、当業者が彼らの作業の実質をそれによって他の当業者に効率的に伝える説明および表現である。アルゴリズムは、この用語が本明細書で使用される時に、および一般に使用される時に、所望の結果につながるステップの自己完結的シーケンスと考えられる。ステップは、物理的量の物理的操作を必要とするステップである。必ずではないが通常、これらの量は、格納され、転送され、組み合わされ、比較され、かつ他の形で操作され得る、光信号、電気信号、または磁気信号の形をとる。時々、主に一般的な使用の理由から、これらの信号をビット、値、要素、記号、文字、項、数、または類似物と称することが便利であることがわかっている。
【００３８】
しかし、これらおよび類似する用語のすべてが、適切な物理量に関連付けられなければならず、単にこれらの量に適用される便利なラベルであることに留意されたい。そうではないと特に述べられない限り、または議論から明白であるように、「処理」、「コンピューティング」、「計算」、「判定」、「表示」、または類似物などの用語は、コンピュータ・システムのレジスタおよびメモリ内の物理的電子的量として表されたデータを操作し、コンピュータ・システムメモリもしくはレジスタまたは他のそのような情報ストレージ・デバイス、情報伝送デバイス、または情報表示デバイス内の物理量として同様に表される他のデータに変換する、コンピュータ・システムまたは類似する電子コンピューティング・デバイスのアクションおよびプロセスを指す。
【００３９】
また、開示される主題のソフトウェア実施される諸態様が、通常は、ある形のプログラム記憶媒体上で符号化され、またはあるタイプの伝送媒体を介して実施されることに留意されたい。プログラム記憶媒体は、磁気（たとえば、フロッピ・ディスクまたはハード・ドライブ）または光学（たとえば、コンパクト・ディスク読取り専用メモリすなわち「ＣＤ ＲＯＭ」）とすることができ、読取り専用またはランダム・アクセスとすることができる。同様に、伝送媒体は、より対線、同軸ケーブル、光ファイバ、または当技術分野で既知のある他の適切な伝送媒体とすることができる。開示される主題は、任意の所与の実施態様のこれらの態様によって限定はされない。
【００４０】
上で開示された特定の実施形態は、例示にすぎない。というのは、開示される主題を、本明細書の教示の利益を有する当業者に明白な、異なるが同等の形で変更し、実施することができるからである。さらに、下の特許請求の範囲に記載されたものと異なる、本明細書で示された構成または設計の詳細への限定は、意図されていない。したがって、上で開示された特定の実施形態を、変更しまたは修正することができ、すべてのそのような変形形態が、開示される主題の範囲内と考えられることは、明白である。したがって、本明細書で求められる保護は、下の特許請求の範囲に示されている。
【技術分野】
【０００１】
本発明は、全般的には通信システムに関し、より具体的には無線通信システムに関する。
【背景技術】
【０００２】
無線通信システムは、通常、無線接続性をユーザ機器に提供するために多数のアクセス・ネットワークを実施し、ユーザ機器は、モバイル・ユニット、移動局、加入者ステーション、加入者、および類似物と称する場合もある。最初の無線通信システムは、ほぼ排他的に音声呼をモバイル・ユーザに提供することに焦点を合わせた。しかし、ユーザ機器の機能性、アクセス・ネットワークによってサポートされるアップリンクおよびダウンリンクでのエア・インターフェース帯域幅、ならびに無線ネットワークの容量は、指数関数的に増加し、増加し続けると期待される。ユーザ機器および無線ネットワークの能力のこの増加は、サービス・プロバイダがより洗練されたアプリケーションをサポートすることを可能にしてきた。たとえば、ユーザ機器は、しばしば、ビデオ・データを受け取ることができる比較的高解像度のカラー・スクリーンと、ビデオ・データを生成し、無線ネットワークを介して送信できるカメラ（またはカメラ用の接続）とを含む。既存の音声／オーディオ・サービスと組み合わせて使用される時に、ネットワークおよびユーザ機器のビデオ能力を使用して、ビデオ通信会議、ゲーム、および他のマルチメディア・アプリケーションをサポートすることができる。
【０００３】
無線通信システム内のアプリケーション・サーバを使用して、ビデオ通信会議、ゲーム、および他のマルチメディア・アプリケーションを含むさまざまなアプリケーションをサポートすることができる。アプリケーションは、サービスを提供するのに使用される複数のインターネット・プロトコル（ＩＰ）フローをオープンすることができる。たとえば、ビデオ会議アプリケーションは、会議のメンバごとにビデオＩＰフローおよびオーディオＩＰフローのためにベアラをオープンすることを要求することができる。この要求は、フローごとの所望のおよび／または要求される待ち時間、遅延、ジッタ、および／または帯域幅を示す情報を含むことができる。この要求は、通常はポリシ制御およびルール機能（ｐｏｌｉｃｙ ｃｏｎｔｒｏｌ ａｎｄ ｒｕｌｅｓ ｆｕｎｃｔｉｏｎ、ＰＣＲＦ）に送信され、ＰＣＲＦは、ＰＣＲＦによって使用される各メンバのユーザ・プロファイル内で示される優先順位に基づいて、フローごとに要求されるリソースを割り当てることを試みる。その後、ＰＣＲＦは、メンバに接続性を提供するアクセス・ネットワーク（１つまたは複数）に、ベアラごとにリソースの要求を送信する。
【０００４】
各ＩＰフローは、ＰＣＲＦによって別々に要求されるので、アクセス・ネットワーク（１つまたは複数）は、セッションに調整されない別々のＩＰフローを見、たとえば、アクセス・ネットワークは、ユーザごとにビデオＩＰフローとは独立にオーディオＩＰフローをオープンし、扱う。したがって、アクセス・ネットワークは、輻輳した状況でオーディオＩＰフローを確立することを可能にするが、関連するビデオＩＰフローを可能にしない場合がある。しかし、会議のビデオ部分が重要と考えられる場合には、これは、オーディオＩＰフローと関連するビデオＩＰフローとの両方を確立できる時に限ってユーザを受け入れることの望みに矛盾する可能性がある。その代わりに、アクセス・ネットワークが、ユーザのサブセットについてオーディオＩＰフローおよびビデオＩＰフローにリソースを割り当てるが、他のユーザのオーディオＩＰフローを拒否する場合がある。会議のビデオ部分が重要と考えられない場合には、これは、少なくともオーディオＩＰフローを使用して会議に参加するユーザの人数を増やすためにビデオＩＰフローの前にオーディオＩＰフローを許すことの望みに矛盾する可能性がある。
【０００５】
この問題に対処する１つの従来の手法は、アプリケーションに関連するＩＰフローのためのリソースの所望の割当を近似するために異なるＩＰフローに関連する優先順位を調整するために、ネットワーク内の優先順位制御機構を使用することである。たとえば、無線通信システムは、通常、各ユーザに関連する優先順位を示すユーザ・プロファイルを維持するポリシおよび課金ルール機能（ｐｏｌｉｃｙ ａｎｄ ｃｈａｒｇｉｎｇ ｒｕｌｅｓ ｆｕｎｃｔｉｏｎ、ＰＣＲＦ）を実施する。ＰＣＲＦは、アプリケーションにとってそれほどクリティカルではないＩＰフローから外れてリソースをステアリングしながら、より高い優先順位のＩＰフローに向けてリソースを案内するために、各ユーザに関連するさまざまなＩＰフローの優先順位を調整することができる。しかし、この手法は、所望のリソース割当を近似するリソース割当につながる値を優先順位にセットするために、ある量の当て推量を必要とする。優先順位が正しくセットされない場合には、異なるＩＰフローへのリソースの実際の割当が、所望の割当から大きく逸脱する可能性がある。さらに、異なるＩＰフローの優先順位を単純に調整することは、同一セッションに属する異なるユーザのＩＰフローの相関を可能にはしない。アプリケーションの必要に基づくフロー優先順位の動的変更も、現在の技術では不可能である。たとえば、異なるＩＰフローの優先順位の単純な調整は、複数の参加者を有するビデオ会議セッションまたはゲーム・セッションのオーディオＩＰフローおよび／またはビデオＩＰフローの間の所望の相関をネットワークが判定することを可能にしない。さらに、ビデオ会議アプリケーションは、ＰＣＲＦからのフィードバックに基づいてＩＰフローの優先順位関係を調整できないはずである。
【発明の概要】
【課題を解決するための手段】
【０００６】
開示される主題は、上で示された問題のうちの１つまたは複数の影響に対処することを対象とする。次では、開示される主題のいくつかの態様の基本的な理解を提供するために、開示される主題の単純化された概要を提示する。この概要は、開示される主題の網羅的概要ではない。開示される主題の主要なまたはクリティカルな要素を識別することも、開示される主題の範囲を区切ることも、意図されていない。その唯一の目的は、後で述べるより詳細な説明の前置きとして、単純化された形でいくつかの概念を提示することである。
【０００７】
一実施形態では、１つまたは複数のアプリケーションをサポートするためにアプリケーション・サーバと複数のユーザ機器との間で複数のフローを確立する方法が提供される。この方法は、アプリケーション・サーバからポリシ・サーバへグループ要求を送信するステップを含む。グループ要求は、フローを確立するためのものであり、フローの間の１つまたは複数の関係を示す情報を含む。この方法は、アプリケーション・サーバでポリシ・サーバから、関係（１つまたは複数）によって課せられる１つまたは複数の制約を条件としてフローが確立されたかどうかを示す、グループ要求に対する応答を受信するステップをも含む。
【０００８】
もう１つの実施形態では、１つまたは複数のアプリケーションをサポートするためにアプリケーション・サーバとユーザ機器との間でフローを確立する方法が提供される。この方法は、ポリシ・サーバでアプリケーション・サーバからフローを確立するためのグループ要求を受信するステップを含む。グループ要求は、フローの間の１つまたは複数の関係を示す情報を含む。この方法は、ポリシ・サーバで、関係（１つまたは複数）によって課せられる１つまたは複数の制約を条件としてフローを確立できるかどうかを判定するステップをも含む。この方法は、ポリシ・サーバからアプリケーション・サーバへ、フローが確立されたかどうかを示すグループ要求に対する応答を送信するステップをも含む。
【０００９】
第３の実施形態では、１つまたは複数のアプリケーションをサポートするためにアプリケーション・サーバとユーザ機器との間でフローを確立する方法が提供される。この方法は、ポリシ・サーバでアプリケーション・サーバから、フローを確立するためのグループ要求を受信するステップを含む。グループ要求は、フローの間の１つまたは複数の関係を示す情報を含む。この方法は、ポリシ・サーバで、関係（１つまたは複数）によって課せられる１つまたは複数の制約を条件としてフローを確立できるかどうかを判定するステップをも含む。この方法は、ポリシ・サーバからアプリケーション・サーバへ、フローが確立されたかどうかを示すグループ要求に対する応答を送信するステップをも含む。この方法は、ポリシ・サーバが、存在するグループ要求に関するＩＰフローの間の関係を変更するためにアプリケーション・サーバから追加要求を受信するステップをも含む。
【００１０】
第４の実施形態では、１つまたは複数のアプリケーションをサポートするためにアプリケーション・サーバとユーザ機器との間でフローを確立する方法が提供される。この方法は、ポリシ・サーバでアプリケーション・サーバから、フローを確立するためのグループ要求を受信するステップを含む。グループ要求は、フローの間の１つまたは複数の関係を示す情報を含む。この方法は、ポリシ・サーバで、関係（１つまたは複数）によって課せられる１つまたは複数の制約を条件としてフローを確立できるかどうかを判定するステップをも含む。この方法は、ポリシ・サーバからアプリケーション・サーバへ、フローが確立されたかどうかを示すグループ要求に対する応答を送信するステップをも含む。この方法は、ポリシ・サーバが、加入者のプロファイル、グループ・プロファイル、および／またはアプリケーションとポリシ・サーバとの間のネゴシエーションに基づいて、異なるアクセス・ネットワーク技術で失敗したベアラ（１つまたは複数）またはフロー（１つまたは複数）のリソースの割当を試みるステップをも含む。
【００１１】
開示される主題を、添付図面に関連して解釈される次の説明を参照することによって理解することができ、添付図面では、類似する符号が、類似する要素を識別する。
【図面の簡単な説明】
【００１２】
【図１】無線通信システムの第１の例示的実施形態での情報フローを概念的に示す図である。
【図２】無線通信システムの第２の例示的実施形態を概念的に示す図である。
【図３】１つのアプリケーションに関連するフローの間の関係を確立する方法の１つの例示的実施形態を概念的に示す図である。
【発明を実施するための形態】
【００１３】
開示される主題は、さまざまな変更および代替形態を許すが、その特定の実施形態を、例として図面に示し、本明細書で詳細に説明する。しかし、特定の実施形態の本明細書での説明が、開示される主題を開示される特定の形態に限定することを意図されたものではなく、逆に、その意図が、添付の特許請求の範囲に含まれるすべての修正形態、同等物、および代替形態を包含することであることを理解されたい。
【００１４】
例示的実施形態を、下で説明する。明瞭さのために、実際の実施態様の特徴の一部が、本明細書で説明されない。もちろん、すべてのそのような実際の実施形態の開発で、実施態様ごとに異なるシステム関連制約およびビジネス関連制約の遵守など、開発者の特定の目標を達成するために、多数の実施態様固有の判断を行わなければならないことを了解されたい。さらに、そのような開発努力が、複雑で時間のかかるものである可能性があるが、それでも、本開示の利益を有する当業者の日常の仕事であることを了解されたい。
【００１５】
開示される主題を、これから、添付図面を参照して説明する。さまざまな構造、システム、およびデバイスが、説明のみのために、また、当業者に周知の詳細で本発明を不明瞭にすることがないように、図面では概略的に示されている。それでも、添付図面は、開示される主題の例示的な例を記述し、説明するために含まれる。本明細書で使用される単語および句は、当業者によるこれらの単語および句の理解と一貫する意味を有すると理解され、解釈されなければならない。用語または句の特殊な定義すなわち、当業者によって理解される通常の慣例的な意味とは異なる定義が、本明細書での用語または句の一貫した使用によって暗示されることは、意図されていない。用語または句が、特殊な意味すなわち、当業者によって理解されるものとは異なる意味を有することが意図される範囲で、そのような特殊な定義は、用語または句の特殊な定義を直接に明確に提供する定義的な形で本明細書で特に示される。
【００１６】
一般的に言って、本願は、アプリケーションが通信システム内のデータ・フローの間の関係を指定することを可能にするために通信システム内で実施できる技法および機能性を説明する。関係を、個々のユーザまたはユーザのグループの間のデータ・フローについて指定することができる。本明細書で説明される制御能力の例示的実施形態は、アプリケーション（ビデオ会議、ゲーム、および類似物など）が、合同で所望のサービスを作成する複数のアップリンクおよび／またはダウンリンクのデータ・フローの間の１つまたは複数の関係を示し、ポリシ・サーバからのフィードバックに基づいてこれらの関係を変更することを可能にする。たとえば、アプリケーションは、参加者のリスト、サービスを提供するのに使用されるデータ・フローのセット、データ・フローの優先順位、およびデータ・フローの間の関係を含む情報をポリシ・サーバに送信することができる。その後、ポリシ・サーバは、アプリケーションによって提供された情報を使用して、フロー・ポリシおよび／またはルールを確立し、たとえば１つまたは複数のアクセス・ネットワークに、データ・フローのためのリソースを要求することができる。データ・フローのセットは、複数のユーザおよび複数の技術にまたがることができ、ユーザは、単一のまたは複数のサービス・プロバイダによってサービスされ得る。各データ・フローを、そのデータ・フローの優先権およびそのデータ・フローの相互依存性を反映する形で他のデータ・フローに関係付けることができる。ポリシ・サーバによってアプリケーション・サーバに提供される情報に基づいて、アプリケーション・サーバは、以前に確立されたグループ要求に関する変更要求をポリシ・サーバに発行することを選択することができる。
【００１７】
１つの例示的実施形態では、アプリケーションは、特定のサービスを作成するために１ユーザあたり４つのデータ・フローを使用することができる、すなわち、フローＡ、Ｂ、Ｃ、およびＤを、そのサービスをサポートするのに使用することができる。記号Ａ１は、ユーザ１のためのフローＡを示し、Ｂ２は、ユーザ２のためのフローＢを示し、以下同様である。アプリケーションによって指定できる１つの例示的な関係は、Ａ１およびＡ２が、最高の優先順位を与えられ、一緒に割り当てられるか全く割り当てられないかのどちらかにならなければならないことである。アプリケーションは、フローＢ１、Ｂ２、Ｃ１、およびＣ２が、相互に関係し、同時に割り当てられなければならないことを示すこともできる。アプリケーションは、さらに、フローＤ１およびＤ２が、最低の優先順位であり、他のフローのいずれに対しても相互依存性を有しないことを示すことができる。その後、ポリシ・サーバは、指定された関係を使用して、ポリシ・ルールを確立し、リソースを要求することができる。本明細書で詳細に述べるように、関係は、満足されなければならない厳しいルールおよび／または可能な場合に満足されなければならない相対的に厳しくないルールを示すことができる。さらに、ポリシ・サーバおよびアプリケーションは、指定された関係の性質をネゴシエートすることができる。たとえば、ポリシ・サーバが、関係の初期セットによって関係付けられる十分な個数のフローをサポートするためのリソースを入手できない場合には、ポリシ・サーバおよびアプリケーションは、サービスをサポートするのに十分な個数のフローのためのリソースを入手することを試みるために、関係の新しいセットをネゴシエートすることができる。
【００１８】
図１に、無線通信システム１００の第１の例示的実施形態での情報フローを概念的に示す。図示の実施形態では、無線通信システム１００は、１つまたは複数のアプリケーション１０５、１つまたは複数のポリシ制御およびルール機能（ＰＣＲＦ）１１０、ならびにエア・インターフェースを介して無線接続性を提供するのに使用される１つまたは複数のアクセス・ネットワーク１１５を含む。単一のアプリケーション１０５、ＰＣＲＦ １１０、およびアクセス・ネットワーク１１５が、無線通信システム１００内の情報のフローを明瞭に例示するために図１に示されている。しかし、本開示の利益を有する当業者は、無線通信システム１００の代替実施形態が、任意の個数のアプリケーション１０５、ＰＣＲＦ １１０などのポリシ・サーバ、およびアクセス・ネットワーク１１５を含むことができることを了解するに違いない。さらに、当業者は、アクセス・ネットワーク１１５に関連してまたはこれに加えて無線接続性を提供するために、他のタイプのデバイスを使用できることを了解するに違いない。例示的デバイスは、基地局、基地局ルータ、ＩＥＥＥ標準規格および／またはプロトコルに従って動作するアクセス・ポイント、Ｂｌｕｅｔｏｏｔｈ標準規格および／またはプロトコルに従って動作するデバイス、ならびに類似物を含む。
【００１９】
アプリケーション１０５は、当初に、サービスに関連する情報フローをサポートするようにベアラに要求する。情報フローは、無線通信システム１００内のユーザ機器に情報を提供し、ユーザ機器から情報を受信することが意図されている。要求は、この情報をアプリケーション１０５とＰＣＲＦ １１０との間で搬送するために定義されるメッセージ、データ構造、および／または言語を使用してＰＣＲＦ １１０に提供される。また、アプリケーション１０５は、要求されるフローの間の所望の関係を示す情報を提供し、フローへのリソースの割当を、要求される関係をサポートし、これと一貫する形で要求する。ＰＣＲＦ １１０は、オプションで、要求の受信を肯定応答することができる。要求の受信時に、ＰＣＲＦ １１０は、ベアラの個数、要求されるベアラの終端点（たとえば、ユーザ機器識別子、デバイスに割り当てられたＩＰアドレス、およびサブスクリプションＩＤ）、帯域幅、待ち時間、および／またはジッタ要件を示す情報など、ベアラ要求内の情報を使用して、ベアラの動作を支配するポリシおよび／またはルールを定式化することができる。定式化されるポリシおよび／またはルールは、ベアラ／フローとベアラ要求内で指定されたすべての優先順位との間の関係をも反映する。
【００２０】
ＰＣＲＦ １１０は、提供されるポリシおよび／またはルールに従ってベアラを確立する要求と共に、フロー・ポリシおよび／またはルールをアクセス・ネットワーク１１５に送信する。この要求は、フローおよび／またはベアラのそれぞれの識別子を含むこともできる。アクセス・ネットワーク１１５は、ベアラおよび／またはフローの相互依存性とベアラおよび／またはフローに関連する優先順位とを反映するポリシに従って、要求されたベアラおよび／またはフローを確立することを試みる。たとえば、アクセス・ネットワーク１１５は、指定されたポリシおよび／または優先順位に従って使用可能なリソースを割り当てることによって、要求されたベアラおよび／またはフローを確立することを試みることができる。その後、アクセス・ネットワーク１１５は、どのベアラおよび／またはフローが成功して確立されたのかならびにどのベアラおよび／またはフローが成功して確立されなかったのかを示すメッセージを返すことができる。その後、ＰＣＲＦ １１０は、要求されたベアラおよび／またはフローを確立する試みの成功および／または失敗についてアプリケーション１０５に知らせる。アプリケーション１０５およびＰＣＲＦ １１０は、いくつかの場合に、本明細書で述べるように、要求されたベアラおよび／またはフローを確立する試みの成功および／または失敗に基づいて、要求されたリソース、関係、優先順位または他のパラメータをネゴシエートすることができる。
【００２１】
図２に、無線通信システム２００の第２の例示的実施形態を概念的に示す。図示の実施形態では、アプリケーション・サーバ２０５は、相互に関係するフロー２１５、２１６、２１７、２１８を使用してユーザ機器２１０に１つまたは複数のアプリケーションを提供するのに使用される。たとえば、フロー２１５（１）を使用して、会議、ゲーム、または他の通信アプリケーションに使用されるオーディオ・インターネット・プロトコル（ＩＰ）フローを搬送することができる。フロー２１５（２）を使用して、同一のアプリケーションのビデオＩＰフローを搬送することができる。フロー２１５（１〜２）は、相互に関係し、アプリケーション・サーバ２０５は、フロー２１５の間の関係を指定し、リソースがフロー２１５のために割り当てられる時にこれらの関係が維持されることを要求することができる。フローの対２１６、２１７、２１８も、オーディオＩＰフローおよびビデオＩＰフローなどの相互に関係するフローの対を表すことができる。さらに、フロー２１５、２１６、２１７、２１８は、アプリケーション・サーバ２０５によって提供される特定のアプリケーションに応じて、情報のアップリンクおよび／またはダウンリンクのフローをサポートすることができる。
【００２２】
アプリケーション・サーバ２０５は、アプリケーション・サーバ２０５がベアラおよび／またはフロー２１５、２１６、２１７、２１８の確立を要求する時にフロー２１５、２１６、２１７、２１８の間の関係を指定する。たとえば、アプリケーション・サーバ２０５が、ユーザ機器２１０のユーザの間でビデオ会議を確立することを試みる場合に、アプリケーション・サーバ２０５は、要求されるフロー２１５、２１６、２１７、２１８ならびにこれらのフローの間の相互関係を示す要求をＰＣＲＦサーバ２２０に送信することができる。これらのフローの間の相互関係の１つの可能な組は、フローの対２１５、２１６、２１７、２１８を独立に確立できるが、フローの対２１５、２１６、２１７、２１８のそれぞれの中の個々のフローを一緒に確立しなけれればならないことを述べる。その代わりに、フローの対２１５、２１６、２１７、２１８のそれぞれの中の個々のフローの一方がより重要と考えられる場合には、これらのフローの間の相互関係のもう１つの可能な組は、できる限り多数のフロー２１５、２１６、２１７、２１８が確立されるが、フローの対２１５、２１６、２１７、２１８のうちの好ましい１つだけが確立されなければならないことを要求することができる。たとえば、指定される相互関係は、フローの対２１５、２１６、２１７、２１８のそれぞれのうちのオーディオＩＰフロー２１５（１）が優先的に確立されることを要求することができる。
【００２３】
フローの間の関係は、ユーザ機器２１０に関連する優先順位を反映することもできる。たとえば、ユーザ機器２１０（１）を、ビデオ会議の議長とすることができ、より高い優先順位を与えることができる。アプリケーション・サーバ２０５は、この優先順位を反映する関係を指定することができ、たとえば、アプリケーション・サーバ２０５は、ビデオ会議を開始できる前に、議長ユーザ機器２１０（１）へのフロー２１５が割り当てられなければならないことを述べる、ユーザ機器２１０に関連するフローの間の関係を指定することができる。アプリケーション・サーバ２０５は、オーディオＩＰフロー２１５（１）とビデオＩＰフロー２１５（２）との両方が、ビデオ会議を行うために確立されなければならないことを指定することもできる。その代わりに、アプリケーション・サーバ２０５は、オーディオＩＰフロー２１５（１）など、フローのうちの１つだけが、ビデオ会議を開始できる前に確立されることを指定することができる。いくつかの実施形態では、アプリケーション・サーバ２０５は、ユーザ機器のグループの間の相互関係を指定することもできる。たとえば、アプリケーション・サーバ２０５は、ユーザ機器２１０のそれぞれへの少なくとも１つのフロー２１５、２１６、２１７、２１８が、ビデオ会議を開始できる前に確立されなければならないという関係を指定することができる。もう１つの例として、アプリケーション・サーバ２０５は、少なくとも最小個数のユーザ機器２１０へのフローが、ビデオ会議を開始できる前に確立されなければならないことを指定することができる。
【００２４】
ＰＣＲＦサーバ２２０は、アプリケーション・サーバ２０５から受信された情報に基づいて、要求されたフロー２１５、２１６、２１７、２１８のポリシおよび／またはルールを確立する。確立されたポリシおよび／またはルールをさまざまなアクセス・ネットワーク２２５に送信することができ、このアクセス・ネットワーク２２５は、ＰＣＲＦサーバ２２０によって伝えられたポリシおよび／またはルールによって課せられる制約を条件として、リソースを割り振ることを試みる。図示の実施形態では、アクセス・ネットワーク２２５は、要求されたフロー２１５、２１６、２１８をサポートするためにリソースを割り当てることができるが、要求されたフロー２１７をサポートするためにリソースを割り当てることはできない（破線によって示されるように）。したがって、アクセス・ネットワーク２２５（１、３）は、フロー２１５、２１６、２１８のリソースの成功の割当を示す肯定応答をＰＣＲＦサーバ２２０に送信する。アクセス・ネットワーク２２５（２）も、リソースが要求されたフロー２１７に成功して割り当てられなかったことを示す否定応答をＰＣＲＦサーバ２２０（２）に送信することができる。本開示の利益を有する当業者は、ＰＣＲＦサーバ２２０および／またはアクセス・ネットワーク２２５が、同一のまたは異なる標準規格、プロトコル、および／またはアクセス技術に従って動作できることを了解するに違いない。
【００２５】
ＰＣＲＦサーバ２２０は、アプリケーション・サーバ２０５がどのように進行すべきかを判断できるようにするために、アプリケーション・サーバ２０５に肯定応答の内容を伝える。一実施形態では、アプリケーション・サーバ２０５は、十分な個数の要求されたベアラおよび／またはフローが割り当てられたと判定し、アプリケーションを開始する。その後、フロー２１７の要求を、棄て、キューに入れ、かつ／または周期的に再サブミットすることができる。代替案では、アプリケーション・サーバ２０５は、フロー２１７のうちの１つまたは複数を、アプリケーションを開始する前に割り当てなければならないと判定することができる。その後、アプリケーション・サーバ２０５は、ベアラ要求および／またはフロー要求を改訂しまたは変更することができる。たとえば、アプリケーション・サーバ２０５は、より少ない帯域幅またはより弱い遅延制約および／もしくはジッタ制約を要求することができる。もう１つの例として、アプリケーション・サーバ２０５は、フロー２１７が一緒に割り当てられることを要求した以前の関係を変更し、フロー２１７のうちの少なくとも１つが割り当てられることを要求する新しい関係を送信することができる。アプリケーション・サーバ２０５およびＰＣＲＦサーバ２２０は、十分な個数のユーザ機器２１０が許されたとアプリケーション・サーバ２０５が判定するまで、または終了判断基準に達するまで、このネゴシエーション・プロセスを反復して繰り返すことができる。
【００２６】
フロー２１５、２１６、２１７、２１８の間の関係を、動的に変更することもできる。たとえば、要求されたフロー２１５、２１６、２１８が確立された後に、アプリケーション・サーバ２０５は、ユーザ機器２１０へのアプリケーションの提供を開始することができる。その後、無線通信システム２００内のさまざまなエンティティは、存在するフロー２１５、２１６、２１８を使用してアプリケーションが提供されつつある間に、動作条件および／または動作パラメータを監視することができる。無線通信システム２００内の変化は、アプリケーション・サーバ２０５によって指定された関係の変更につながる可能性がある。たとえば、アクセス・ネットワーク２２５によってサポートされるエア・インターフェースに関連する環境条件および／またはチャネル条件の変化は、アクセス・ネットワーク２２５がより多くのまたはより少ないリソースを割り当てることを可能にする場合があり、これが、アクセス・ネットワーク２２５がより多くのまたはより少ないフローをサポートすることを可能にする場合がある。この情報を、アプリケーション・サーバ２０５に伝えることができ、アプリケーション・サーバ２０５は、この情報を使用して、たとえばより多くのリソースが使用可能である時により厳密な関係を要求することによって、またはより少ないリソースが使用可能である時により厳密でない関係を要求することによって、指定された関係を変更するかどうかを判断することができる。もう１つの例として、追加のユーザ機器が、アプリケーション・サーバ２０５によって提供されるサービスへの許可を要求する場合があり、あるいは、既存のフローを有する他のユーザ機器が、サービスを中断する場合がある。たとえば、より少ないユーザ機器がアプリケーションを使用することを求める時により厳密な関係を要求することによって、またはより多くのユーザ機器がアプリケーションを使用することを求める時により厳密でない関係を要求することによる、ユーザ機器の加算または減算に応答して、関係を変更することができる。
【００２７】
図３に、１つのアプリケーションに関連するフローの間の関係を確立する方法３００の１つの例示的実施形態を概念的に示す。図示の実施形態では、ユーザは、（３０５で）オーディオＩＰフローおよび／もしくはビデオＩＰフローまたは他のＩＰデータ・フローなどの複数のフローによってそれぞれがサービスされる複数のユーザを有するサービスについてグループ・セッションを開始する。開始するユーザは、グループの議長であり、ＵＥ−Ｍと指定されるユーザ機器を操作する。グループ内の１人または複数の他のユーザは、ＵＥと指定されるユーザ機器を操作する。議長は、方法３００の例示的実施形態でグループ・セッションを開始するが、本開示の利益を有する当業者は、無線通信システムへのアクセスを有する任意のエンティティが、その代わりにグループ・セッションを開始できることを了解するに違いない。グループ・セッションの開始（３０５での）は、グループ・セッションの、Ｇｒｏｕｐ＿ＩＤなどの識別子を定義することおよび／またはこれを提供することを含むことができる。
【００２８】
グループ・セッションが開始されることに応答して、グループ・セッションのサービスまたはアプリケーションを提供するアプリケーション・サーバ（ＡＳ）は、たとえばアプリケーション・サーバ内のメモリもしくは他のストレージ・デバイスまたは他所で実施されるデバイスから、グループ・セッションに関連するデータを取り出す。その後、アプリケーション・サーバは、たとえばＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）招待メッセージをユーザ機器に提供することによって、ユーザをグループ・セッションに招待する（３０５で）。招待メッセージを、１つまたは複数のアクセス・ネットワーク（ＡＮ）およびシステム内の任意の他の介在するネットワークまたはサポートするネットワークを介してユーザ機器に配送することができる。さまざまな代替実施形態では、参加者を、複数のアクセス技術、ネットワーク、および／またはサービス・プロバイダにまたがってネットワークにアタッチし、かつ／または接続することができる。その後、ユーザ機器およびアプリケーション・サーバは、セッションを当初に定義するのに使用されるパラメータを定義し、判定し、ネゴシエートし、合意することができる。
【００２９】
アプリケーション・サーバは、ネゴシエートされたセッション・パラメータを使用して、アプリケーションによって提供されるフローの間の１つまたは複数の関係を判定する（３１０で）。関係は、グループ・サービス品質許可要求（Ｇｒｏｕｐ Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｒｅｑｕｅｓｔ）メッセージなどの許可要求メッセージを定義するのに使用される。一実施形態では、グループＱｏＳ許可要求メッセージは、グループ・セッションに参加するユーザのリスト、グループ・セッションに参加するユーザのそれぞれに関連するデータ・フローのリスト、データ・フローおよび／またはユーザの間の判定された関係、ならびにデータ・フローおよび／またはユーザに関連する優先順位を含む。本開示の利益を有する当業者は、許可要求メッセージの代替実施形態が追加情報を含むことができることを了解するに違いない。その後、許可要求メッセージは、ＰＣＲＦサーバなどの１つまたは複数のポリシ・サーバに送信される（３１５で）。
【００３０】
ポリシ・サーバ（１つまたは複数）は、許可要求メッセージから情報を抽出し、この情報を使用して、フロー関係ならびにベアラおよび／またはフローに関連する優先順位によって課される制約を条件として、要求されるベアラおよび／またはフローを確立するためのポリシおよび／またはルールを判定する（３２０で）。たとえば、各ＰＣＲＦは、グループ許可要求を処理し、適当なポリシ／ルールを判定し、グループ・セッションのためのリソースを許可しまたは要求することができる。各ＰＣＲＦは、グループ相関ＩＤ（Ｇｒｏｕｐ Ｃｏｒｒｅｌａｔｉｏｎ−ＩＤ、ＧＣ−ＩＤ）などの識別子をグループ・セッションに割り当てることもできる。その後、ＰＣＲＦは、リソースがグループ・セッションの参加者に割り当てられることを要求するメッセージを送信する（３２５で）。このメッセージは、アプリケーション・サーバによって送信されたフロー関係を反映するポリシおよび／またはルールを条件としてリソースが割り当てられなければならないことをも示す。たとえば、ＰＣＲＦは、サービスまたはアプリケーションを受信しつつあるユーザのうちの１人または複数に無線接続性を提供する各アクセス・ネットワークに接続セットアップ（Ｃｏｎｎｅｃｔｉｏｎ−Ｓｅｔ−Ｕｐ）メッセージを送信することができる。このメッセージは、各ユーザに関連するフローごとの、リソースの割当と専用ベアラの確立とをトリガする。
【００３１】
アクセス・ネットワーク（１つまたは複数）は、要求されたリソースを割り当て（３３０で）、専用ベアラを確立することを試みる。一実施形態では、ＬＴＥのｅＮＢなどのアドミッション制御の責任を負うアクセス・ネットワーク内のネットワーク・エンティティが、ＧＣ−ＩＤと一緒にグループ・セッションを許す要求を受信し、その要求を処理する。その後、このエンティティは、要求されたベアラおよび／またはフローに、使用可能なリソースを割り当てる（３３０で）。リソースが、グループ・セッション内の要求されたフローのすべてを許すために使用可能ではない場合には、アドミッション制御エンティティは、残りのフローのために適当なリソースをキューに入れることができる。すべての要求されたフローのために十分なリソースが使用可能になる場合に、アクセス・ネットワークは、要求されたベアラおよび／またはフローにリソースを割り当てることができる（３３０で）。しかし、たとえばあらかじめ定められた時間間隔内に、十分なリソースが使用可能にならない場合には、リソースを、要求されたベアラおよび／またはフローのサブセットに割り当てることしかできない（３３０で）。たとえば、最高優先順位フローがまずリソースを割り当てられる（３３０で）ように、ベアラおよび／またはフローの優先順位に基づいて、リソースの限られたプールを、要求されたベアラおよび／またはフローのサブセットに割り当てることができる（３３０で）。
【００３２】
いくつかの実施形態では、無線通信システムは、複数の無線アクセス技術をサポートするアクセス・ネットワークを含むことができる。アクセス・ネットワーク（１つまたは複数）は、要求されたリソースを割り当て（３３０で）、初期無線アクセス技術を使用して専用ベアラを確立し、この初期無線アクセス技術は、加入者のプロファイル内で、グループ・プロファイル内で、および／またはアプリケーションとポリシ・サーバとの間のネゴシエーションによって指定され得る。初期無線アクセス・ネットワーク技術を使用してすべての要求されたフローを許すリソースが使用可能ではない場合には、アドミッション制御エンティティは、異なるアクセス・ネットワーク技術を使用してリソースを割り当てる（３３０）ことを試みることができる。たとえば、ポリシ・サーバは、加入者のプロファイル、グループ・プロファイル、および／またはアプリケーションとポリシ・サーバとの間のネゴシエーションに基づいて、異なるアクセス・ネットワーク技術で、失敗したベアラ（１つまたは複数）またはフロー（１つまたは複数）のためのリソースを割り当てる（３３０）ことを試みることができる。
【００３３】
割当プロセスが完了した後に、アクセス・ネットワークは、リソースが成功して割り当てられたかどうか、ならびにどのベアラおよび／またはフローが割り当てられたリソースを受け取ったのかを示すメッセージを返す（３３５で）。この方法は、ベアラおよび／またはフローを確立するのに使用されたアクセス・ネットワーク技術を示す情報を含むこともできる。
【００３４】
ＰＣＲＦは、アクセス・ネットワークから受信する応答を処理し（３４０で）、要求されたベアラおよび／またはフローにリソースを割り当てる試みの結果についてアプリケーション・サーバに通知する。アプリケーション・サーバは、十分な個数のフローおよび／またはユーザが許されたと判定する時に、要求されたセッションを開始することができる。たとえば、アプリケーション・サーバは、すべての参加者が要求されたフローの少なくとも一部のためにリソースを割り当てられた場合に限って、要求されたセッションを開始することができる。代替案では、アプリケーション・サーバは、議長および少なくとも選択された人数のユーザが許された時に、要求されたセッションを開始することができる。
【００３５】
アプリケーション・サーバは、要求されたベアラおよび／またはフローのすべてより少数が、当初に判定されたサービス関係（１つまたは複数）によって課せられる制約を条件として許された時に、ＰＣＲＦとネゴシエートすることもできる（３４５で）。たとえば、ＰＣＲＦは、許されなかったユーザおよび／またはフローを識別することができる。アプリケーション・サーバは、ＰＣＲＦ（１つまたは複数）からの応答を処理し、すべてのユーザおよびフローを許すことに失敗する場合に、アプリケーション・サーバは、十分な数のユーザおよびフロー高優先順位フローが実現性のあるグループ・セッションを有するために許されたかどうかを判定する。不十分な数が許された場合には、アプリケーション・サーバは、要求を変更し（たとえば、要求されるリソースおよび／またはフロー相互関係を変更することによって）、変更された要求をＰＣＲＦに送り返すことができ、ＰＣＲＦは、その後、要求されたリソース割当をアクセス・ネットワークから入手することを試みることができる。このプロセスは、反復して進行することができる。
【００３６】
リソースが、要求されたベアラおよび／またはフローの少なくともサブセットに割り当てられた後に、アプリケーション・サーバは、相互に関係するフローを使用してグループ・セッションを開始することができる（３４５で）。本明細書で述べるように、通信システム内の要素は、さまざまなシステム・パラメータおよび／または条件を監視し続けることができ、その結果、フロー関係および／または要求されるリソースを、通信システムの状態の変化に応答して変更できるようになる。この監視は、相互に関係するフローを使用するグループ・セッションの提供（３４５での）と同時に発生することができる。
【００３７】
開示される主題の諸部分および対応する詳細な説明は、ソフトウェアすなわち、コンピュータ・メモリ内のデータ・ビットに対する動作のアルゴリズムおよび記号表現に関して提示される。これらの説明および表現は、当業者が彼らの作業の実質をそれによって他の当業者に効率的に伝える説明および表現である。アルゴリズムは、この用語が本明細書で使用される時に、および一般に使用される時に、所望の結果につながるステップの自己完結的シーケンスと考えられる。ステップは、物理的量の物理的操作を必要とするステップである。必ずではないが通常、これらの量は、格納され、転送され、組み合わされ、比較され、かつ他の形で操作され得る、光信号、電気信号、または磁気信号の形をとる。時々、主に一般的な使用の理由から、これらの信号をビット、値、要素、記号、文字、項、数、または類似物と称することが便利であることがわかっている。
【００３８】
しかし、これらおよび類似する用語のすべてが、適切な物理量に関連付けられなければならず、単にこれらの量に適用される便利なラベルであることに留意されたい。そうではないと特に述べられない限り、または議論から明白であるように、「処理」、「コンピューティング」、「計算」、「判定」、「表示」、または類似物などの用語は、コンピュータ・システムのレジスタおよびメモリ内の物理的電子的量として表されたデータを操作し、コンピュータ・システムメモリもしくはレジスタまたは他のそのような情報ストレージ・デバイス、情報伝送デバイス、または情報表示デバイス内の物理量として同様に表される他のデータに変換する、コンピュータ・システムまたは類似する電子コンピューティング・デバイスのアクションおよびプロセスを指す。
【００３９】
また、開示される主題のソフトウェア実施される諸態様が、通常は、ある形のプログラム記憶媒体上で符号化され、またはあるタイプの伝送媒体を介して実施されることに留意されたい。プログラム記憶媒体は、磁気（たとえば、フロッピ・ディスクまたはハード・ドライブ）または光学（たとえば、コンパクト・ディスク読取り専用メモリすなわち「ＣＤ ＲＯＭ」）とすることができ、読取り専用またはランダム・アクセスとすることができる。同様に、伝送媒体は、より対線、同軸ケーブル、光ファイバ、または当技術分野で既知のある他の適切な伝送媒体とすることができる。開示される主題は、任意の所与の実施態様のこれらの態様によって限定はされない。
【００４０】
上で開示された特定の実施形態は、例示にすぎない。というのは、開示される主題を、本明細書の教示の利益を有する当業者に明白な、異なるが同等の形で変更し、実施することができるからである。さらに、下の特許請求の範囲に記載されたものと異なる、本明細書で示された構成または設計の詳細への限定は、意図されていない。したがって、上で開示された特定の実施形態を、変更しまたは修正することができ、すべてのそのような変形形態が、開示される主題の範囲内と考えられることは、明白である。したがって、本明細書で求められる保護は、下の特許請求の範囲に示されている。
【特許請求の範囲】
【請求項１】
少なくとも１つのアプリケーションをサポートするためにアプリケーション・サーバと複数のユーザ機器との間で複数のフローを確立する方法であって、
前記アプリケーション・サーバからポリシ・サーバへ、前記複数のフローを確立するためにグループ要求を送信するステップであって、前記グループ要求は、前記複数のフローのうちの少なくとも２つの間の少なくとも１つの関係を示す情報を含む、ステップと、
前記アプリケーション・サーバで前記ポリシ・サーバから、前記少なくとも１つの関係によって課せられる少なくとも１つの制約を条件として前記複数のフローが確立されたかどうかを示す、前記グループ要求に対する応答を受信するステップと
を含む方法。
【請求項２】
前記複数のフローに関するセッション・パラメータに基づいて前記複数のフローのうちの前記少なくとも２つの間の前記少なくとも１つの関係を判定するステップを含み、前記セッション・パラメータは、前記アプリケーション・サーバと前記複数のユーザ機器との間でネゴシエートされる、請求項１に記載の方法。
【請求項３】
前記グループ要求を送信するステップは、前記複数のユーザ機器に割り当てられた複数の優先順位を示すグループ要求を送信するステップを含む、請求項１に記載の方法。
【請求項４】
前記グループ要求に対する前記応答を受信するステップは、前記複数のフローのすべてより少数が要求通りに確立されたことを示す応答を受信するステップを含み、前記アプリケーション・サーバで、前記グループ要求に対する応答に基づいて、十分な個数の前記複数のフローが確立されたかどうかを判定するステップを含む、請求項１に記載の方法。
【請求項５】
十分な個数の前記複数のフローが確立されたと前記アプリケーション・サーバが判定する場合に前記確立されたフローを使用してアプリケーションを開始し、または、不十分な個数の前記複数のフローが確立されたことの判定に応答して、前記グループ要求を反復して変更し、前記変更されたグループ要求を前記アプリケーション・サーバから前記ポリシ・サーバに送信し、前記変更されたグループ要求に対する応答に基づいて、十分な個数の前記複数のフローが確立されたかどうかを判定するステップを含む、請求項４に記載の方法。
【請求項６】
前記少なくとも１つのアプリケーションは、少なくとも１つのビデオ会議アプリケーションを含み、前記複数のフローは、ユーザ機器ごとに少なくとも１つのオーディオ・インターネット・プロトコル（ＩＰ）フローおよび少なくとも１つのビデオＩＰフローを含み、前記複数のフローのうちの少なくとも２つの間の前記少なくとも１つの関係を示す前記グループ要求を送信するステップは、ユーザ機器ごとの前記オーディオＩＰフローと前記ビデオＩＰフローとの間の複数の関係を示すグループ要求を送信するステップを含む、請求項１に記載の方法。
【請求項７】
少なくとも１つのアプリケーションをサポートするためにアプリケーション・サーバと複数のユーザ機器との間で複数のフローを確立する方法であって、
ポリシ・サーバで前記アプリケーション・サーバから、前記複数のフローを確立するためのグループ要求を受信するステップであって、前記グループ要求は、前記複数のフローのうちの少なくとも２つの間の少なくとも１つの関係を示す情報を含む、ステップと、
前記ポリシ・サーバで、前記少なくとも１つの関係によって課せられる少なくとも１つの制約を条件として前記複数のフローを確立できるかどうかを判定するステップと、
前記ポリシ・サーバから前記アプリケーション・サーバへ、前記複数のフローが確立されたかどうかを示す前記グループ要求に対する応答を送信するステップと
を含む方法。
【請求項８】
前記複数のフローを確立できるかどうかを判定するステップは、
前記少なくとも１つの制約を条件として前記複数のフローのためのリソースに関する少なくとも１つの要求を生成するステップと、
前記複数のユーザ機器に無線接続性を提供する少なくとも１つのアクセス・ネットワークに前記少なくとも１つの要求を送信するステップと、
前記要求されたリソースが前記少なくとも１つのアクセス・ネットワークによって割り当てられたかどうかを示す少なくとも１つの応答を前記少なくとも１つのアクセス・ネットワークから受信するステップと
を含む、請求項７に記載の方法。
【請求項９】
前記グループ要求に対する前記応答を送信するステップは、前記要求されたリソースのすべてより少数が割り当てられたことを示す少なくとも１つの応答を前記少なくとも１つのアクセス・ネットワークから受信することに応答して、前記複数のフローのすべてより少数が要求通りに確立されたことを示す応答を送信するステップを含み、前記ポリシ・サーバで、不十分な個数の前記複数のフローが確立されたと前記アプリケーション・サーバが判定することに応答して変更されたグループ要求を反復して受信し、前記変更されたグループ要求に基づいて前記少なくとも１つのアクセス・ネットワークにリソースを要求し、前記変更されたグループ要求に基づいて前記複数のフローが確立されたかどうかを示すメッセージを前記アプリケーション・サーバに送信するステップを含む、請求項７に記載の方法。
【請求項１０】
前記少なくとも１つのアプリケーションは、少なくとも１つのビデオ会議アプリケーションを含み、前記複数のフローは、ユーザ機器ごとに少なくとも１つのオーディオ・インターネット・プロトコル（ＩＰ）フローと少なくとも１つのビデオＩＰフローとを含み、前記複数のフローのうちの少なくとも２つの間の前記少なくとも１つの関係を示す前記グループ要求を送信するステップは、ユーザ機器ごとの前記オーディオＩＰフローと前記ビデオＩＰフローとの間の複数の関係を示すグループ要求を送信するステップを含む、請求項７に記載の方法。
【請求項１】
少なくとも１つのアプリケーションをサポートするためにアプリケーション・サーバと複数のユーザ機器との間で複数のフローを確立する方法であって、
前記アプリケーション・サーバからポリシ・サーバへ、前記複数のフローを確立するためにグループ要求を送信するステップであって、前記グループ要求は、前記複数のフローのうちの少なくとも２つの間の少なくとも１つの関係を示す情報を含む、ステップと、
前記アプリケーション・サーバで前記ポリシ・サーバから、前記少なくとも１つの関係によって課せられる少なくとも１つの制約を条件として前記複数のフローが確立されたかどうかを示す、前記グループ要求に対する応答を受信するステップと
を含む方法。
【請求項２】
前記複数のフローに関するセッション・パラメータに基づいて前記複数のフローのうちの前記少なくとも２つの間の前記少なくとも１つの関係を判定するステップを含み、前記セッション・パラメータは、前記アプリケーション・サーバと前記複数のユーザ機器との間でネゴシエートされる、請求項１に記載の方法。
【請求項３】
前記グループ要求を送信するステップは、前記複数のユーザ機器に割り当てられた複数の優先順位を示すグループ要求を送信するステップを含む、請求項１に記載の方法。
【請求項４】
前記グループ要求に対する前記応答を受信するステップは、前記複数のフローのすべてより少数が要求通りに確立されたことを示す応答を受信するステップを含み、前記アプリケーション・サーバで、前記グループ要求に対する応答に基づいて、十分な個数の前記複数のフローが確立されたかどうかを判定するステップを含む、請求項１に記載の方法。
【請求項５】
十分な個数の前記複数のフローが確立されたと前記アプリケーション・サーバが判定する場合に前記確立されたフローを使用してアプリケーションを開始し、または、不十分な個数の前記複数のフローが確立されたことの判定に応答して、前記グループ要求を反復して変更し、前記変更されたグループ要求を前記アプリケーション・サーバから前記ポリシ・サーバに送信し、前記変更されたグループ要求に対する応答に基づいて、十分な個数の前記複数のフローが確立されたかどうかを判定するステップを含む、請求項４に記載の方法。
【請求項６】
前記少なくとも１つのアプリケーションは、少なくとも１つのビデオ会議アプリケーションを含み、前記複数のフローは、ユーザ機器ごとに少なくとも１つのオーディオ・インターネット・プロトコル（ＩＰ）フローおよび少なくとも１つのビデオＩＰフローを含み、前記複数のフローのうちの少なくとも２つの間の前記少なくとも１つの関係を示す前記グループ要求を送信するステップは、ユーザ機器ごとの前記オーディオＩＰフローと前記ビデオＩＰフローとの間の複数の関係を示すグループ要求を送信するステップを含む、請求項１に記載の方法。
【請求項７】
少なくとも１つのアプリケーションをサポートするためにアプリケーション・サーバと複数のユーザ機器との間で複数のフローを確立する方法であって、
ポリシ・サーバで前記アプリケーション・サーバから、前記複数のフローを確立するためのグループ要求を受信するステップであって、前記グループ要求は、前記複数のフローのうちの少なくとも２つの間の少なくとも１つの関係を示す情報を含む、ステップと、
前記ポリシ・サーバで、前記少なくとも１つの関係によって課せられる少なくとも１つの制約を条件として前記複数のフローを確立できるかどうかを判定するステップと、
前記ポリシ・サーバから前記アプリケーション・サーバへ、前記複数のフローが確立されたかどうかを示す前記グループ要求に対する応答を送信するステップと
を含む方法。
【請求項８】
前記複数のフローを確立できるかどうかを判定するステップは、
前記少なくとも１つの制約を条件として前記複数のフローのためのリソースに関する少なくとも１つの要求を生成するステップと、
前記複数のユーザ機器に無線接続性を提供する少なくとも１つのアクセス・ネットワークに前記少なくとも１つの要求を送信するステップと、
前記要求されたリソースが前記少なくとも１つのアクセス・ネットワークによって割り当てられたかどうかを示す少なくとも１つの応答を前記少なくとも１つのアクセス・ネットワークから受信するステップと
を含む、請求項７に記載の方法。
【請求項９】
前記グループ要求に対する前記応答を送信するステップは、前記要求されたリソースのすべてより少数が割り当てられたことを示す少なくとも１つの応答を前記少なくとも１つのアクセス・ネットワークから受信することに応答して、前記複数のフローのすべてより少数が要求通りに確立されたことを示す応答を送信するステップを含み、前記ポリシ・サーバで、不十分な個数の前記複数のフローが確立されたと前記アプリケーション・サーバが判定することに応答して変更されたグループ要求を反復して受信し、前記変更されたグループ要求に基づいて前記少なくとも１つのアクセス・ネットワークにリソースを要求し、前記変更されたグループ要求に基づいて前記複数のフローが確立されたかどうかを示すメッセージを前記アプリケーション・サーバに送信するステップを含む、請求項７に記載の方法。
【請求項１０】
前記少なくとも１つのアプリケーションは、少なくとも１つのビデオ会議アプリケーションを含み、前記複数のフローは、ユーザ機器ごとに少なくとも１つのオーディオ・インターネット・プロトコル（ＩＰ）フローと少なくとも１つのビデオＩＰフローとを含み、前記複数のフローのうちの少なくとも２つの間の前記少なくとも１つの関係を示す前記グループ要求を送信するステップは、ユーザ機器ごとの前記オーディオＩＰフローと前記ビデオＩＰフローとの間の複数の関係を示すグループ要求を送信するステップを含む、請求項７に記載の方法。
【図１】
【図２】
【図３】
【図２】
【図３】
【公表番号】特表２０１３−５１４０４０（Ｐ２０１３−５１４０４０Ａ）
【公表日】平成２５年４月２２日（２０１３．４．２２）
【国際特許分類】
【出願番号】特願２０１２−５４４５５６（Ｐ２０１２−５４４５５６）
【出願日】平成２２年１１月２３日（２０１０．１１．２３）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０５７７４１
【国際公開番号】ＷＯ２０１１／０７５２９３
【国際公開日】平成２３年６月２３日（２０１１．６．２３）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＢＬＵＥＴＯＯＴＨ
【出願人】（３９１０３０３３２）アルカテル−ルーセント (1,149)
【Ｆターム（参考）】
【公表日】平成２５年４月２２日（２０１３．４．２２）
【国際特許分類】
【出願日】平成２２年１１月２３日（２０１０．１１．２３）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０５７７４１
【国際公開番号】ＷＯ２０１１／０７５２９３
【国際公開日】平成２３年６月２３日（２０１１．６．２３）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＢＬＵＥＴＯＯＴＨ
【出願人】（３９１０３０３３２）アルカテル−ルーセント (1,149)
【Ｆターム（参考）】
[ Back to top ]