JP2011504311A - 通信セッションに関するリソース制限をアプリケーション機能に通知するための方法および装置 - Google Patents

Abstract

本発明は、通信ネットワークにおけるアプリケーション機能であるＡＦに、通信セッションに関するリソース制限を通知する方法に関するものである。このネットワークには、セッションにおけるデータのフローを認可し、そして制御するために、ポリシーおよび課金ルール機能であるＰＣＲＦを含んでいる。本方法では、ＡＦは通信セッションを確立するために認可リクエストをＰＣＲＦに送信する。この認可リクエストには、ＡＦがセッションにおいてデータ・フローに対するリソース制限を通知されるべきであるという表示を含んでいる。ＰＣＲＦは、ＡＦにリソース制限を通知する。
【選択図】 なし

Description

本発明は、マルチメディア通信ネットワークにおいて、ユーザ機器にリソース制限を通知できるようにする方法および装置に関するものである。

ＩＰマルチメディア・サブシステム（ＩＭＳ）は、移動通信ネットワークでＩＰマルチメディア・サービスを提供するために、第３世代パートナーシップ・プロジェクト（３ＧＰＰ）によって定義される技術である。ＩＰマルチメディア・サービスは、同一のセッション内で、音声、映像、メッセージング、データ等を動的に組み合わせて提供する。基本アプリケーションの数、および組み合わせできるメディアが増加すると、エンドユーザに提供されるサービスの数は増加し、個人向けの、豊富なマルチメディア通信サービスの新世代を生み出すことになるであろう。ＩＭＳは、３ＧＰＰ仕様書２３．２２８に定義されている。

ＩＭＳは、ユーザ端末間（またはユーザ端末とアプリケーション・サーバとの間）で呼またはセッションをセットアップし、そして、制御するために、セッション開始プロトコル（ＳＩＰ）を使用する。ＳＩＰシグナリングによって搬送されるセッション記述プロトコル（ＳＤＰ）は、セッションのメディアコンポーネントを記述し、そしてネゴシエート（negotiate）ために使用される。ＳＩＰはユーザ対ユーザのプロトコルとして創り出されたものである一方で、ＩＭＳは、オペレータおよびサービスプロバイダがサービスへのユーザ・アクセスを制御し、そしてそれに応じてユーザに課金できるようにする。

図１は、ＧＰＲＳ／ＰＳアクセス・ネットワークの場合に、どのようにＩＭＳ３が移動ネットワークアーキテクチャに順応するかを概略的に説明している。図１に示されるように、通信の制御は、３つのレイヤ（またはプレーン）で発生する。最下位のレイヤは、接続レイヤ１であり、これは、またベアラ・プレーン、またはトラヒック・プレーンとも呼ばれ、そして、これを通して信号が、ネットワークにアクセスするユーザ端末に向けられる／から向かってくる。ＧＰＲＳネットワークは、様々なＧＰＲＳサポート・ノード（ＧＳＮ）２ａ、２ｂを含んでいる。ゲートウェイＧＰＲＳサポート・ノード（ＧＧＳＮ）２ａは、ＧＰＲＳバックボーン・ネットワークと他のネットワーク（無線ネットワークおよびＩＭＳネットワーク）との間のインタフェースとして機能する。サービング（在圏）ＧＰＲＳサポート・ノード（ＳＧＳＮ）２ｂは、個々の移動端末の位置を追跡し、そして、セキュリティ機能およびアクセス制御を実行する。ＩＭＳ加入者によるＩＭＳ３へのアクセスは、ＩＰ接続アクセス・ネットワーク（ＩＰ−ＣＡＮ）を通して実行される。図１では、ＩＰ−ＣＡＮは、接続レイヤ１を経由してユーザ機器とＩＭＳ３をリンクするエンティティを含むＧＰＲＳネットワークである。

ＩＭＳ３は、中間の制御レイヤ４および接続レイヤ１で動作する、コア・ネットワーク３ａ、およびサービス・ネットワーク３ｂを含んでいる。ＩＭＳコア・ネットワーク３ａには、接続レイヤ１でＧＧＳＮ２ａを経由して信号をＧＰＲＳネットワークに送信し、／ＧＰＲＳネットワークから受信するノード、および呼／セッション制御機能（ＣＳＣＦ）群５を含むネットワーク・ノードを含む。ＣＳＣＦ群５には、サービングＣＳＣＦ（Ｓ−ＣＳＣＦ）群およびプロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）群を含み、Ｐ−ＣＳＣＦ群は中間の制御レイヤにおいてＩＭＳ内のＳＩＰプロキシ群として動作する。

アプリケーション・レイヤ６は最上部にあり、ＩＭＳサービス・ネットワーク３ｂを含んでいる。アプリケーション・サーバ（ＡＳ）群７は、ＩＭＳサービス機能を実現するために提供される。アプリケーション・サーバ群７は、サービスをエンドユーザにセッション単位で提供し、そして、エンドポイントとして単一のユーザに接続される、または二人以上のユーザ間でのセッションに「リンクイン（linked in）される」場合がある。あるアプリケーション・サーバ群７は、加入者アイデンティティ（identities）（被呼加入者か発呼加入者のいずれかで、どちらかがアプリケーション・サーバ７を制御するネットワークによって「所有されて」いる）に依存する動作を実行することになる。

これらのセッションに基づくアプリケーション群は、一人以上のユーザが、動画、音声、チャット、ゲームのような対話型ユーザ・セッションおよびバーチャル・リアリティのセッションに参加することができるようにする。ＩＭＳアーキテクチャは、また、二人以上のユーザがＳＩＰセッション中にデータを交換する、ピア・ツー・ピア・アプリケーションを展開できるようにする。そのようなピア・ツー・ピア・アプリケーションの例には、マルチメディアテレフォニー（ＭＭＴｅｌ）、セルラー・オーバー・プッシュ・ツー・トーク（ＰｏＣ）、ストリーミング、リアルタイムビデオ共有、ファイル共有、ゲーム等がある。トランスポート接続（群）は、２つのエンドポイント（ユーザ端末）間での、ＳＩＰ／ＳＤＰプロトコル交換によって動的にネゴシエートされる。

しかしながら、そのようなピア・ツー・ピア・アプリケーションをサポートするために、２つの基本的な要件が存在する。（ｉ）加入者のＩＭＳセッション（群）に関連付けられているＳＩＰ信号フローを選択的に制御するためのメカニズムが必要であり、そして（ｉｉ）サービスの使用に対して効率的な課金を適用するために、動的にネゴシエートされたトランスポート接続を通してＩＰフローを制御するための機能が必要である。１つの重要な態様は、セッションに対して要求されるリソースに関係しており、リソースはセッションに対して提供されるサービス品質（ＱｏＳ）（たとえば、データがエンドユーザ間で転送されるデータレート）に影響を与えることになるであろう。以下の議論で、用語ＱｏＳは、エンドユーザが体験するサービス品質を判定する、要求されたセッションまたは実行中のセッションのそれらのパラメータを言及するために使用される。ＱｏＳに影響する主要なベアラ・リソースは、セッションに利用できる帯域幅である。

３ＧＰＰは、これらの必要性を認識していて、そしてポリシーおよび課金制御（ＰＣＣ）アーキテクチャを定義している（３ＧＰＰ技術仕様書 ２３．２０３参照）。図２は、ＰＣＣアーキテクチャの基本的な概要を表わしている。アプリケーション機能（ＡＦ）１６は、トラヒック・プレーンのリソースの動的なポリシー制御および課金制御の少なくとも一方を必要とするアプリケーションを提供する要素である。アプリケーション・サービスが開始され、そして、サービス特性がアプリケーション・レイヤ６で（たとえば、アプリケーション・サーバ７により−図１参照）ネゴシエートされるけれども、ＣＳＣＦ５（Ｐ−ＣＳＣＦ）は、ＳＩＰシグナリングプレーン（制御レイヤ４）でＡＦ１６の役割を担う。接続レイヤ１におけるポリシーおよび課金執行機能（ＰＣＥＦ：Policy Charging and Enforcement Function）１２は、サービス・データ・フローをモニタし、そしてネットワーク・ポリシーを実施する。ＰＣＥＦ１２は、また、モニタされるデータ・フローおよび適用される課金ポリシーに基づいて課金を適用する。この情報は、Ｇｙインタフェースを介するオンライン課金システム１３に提供される。図２に示されるように、ＰＣＥＦ１２は、アクセス・ゲートウェイ・ノード内に含まれる。ＧＰＲＳアクセス・ネットワーク内では、ＰＣＥＦ１２は、ＧＧＳＮ２ａに配置されている。３ＧＰＰリリース８で定義されているシステム・アーキテクチャの進化には、ＰＣＥＦは公衆データネットワーク（ＰＤＮ）ゲートウェイにある。

ポリシーおよび課金ルール機能（ＰＣＲＦ）１４は、ＡＦ１６とＰＣＥＦ１２との間に存在する。ＰＣＲＦ１４は、モニタされるデータ・フローに基づいて課金を制御するエンティティである。ＰＣＲＦ１４は、特定の加入者に対して適用される課金ポリシーに関するルールを、加入プロファイル・リポジトリ（ＳＰＲ）１８からＳｐインタフェースを介して取得し、このＳＰＲは、加入者情報のデータベースを含んでいる。ＰＣＲＦ１４は、これらのＰＣＣルールをＧｘインタフェースを介してＰＣＥＦ１２にインストールする。ＰＣＣルールは、要求されるサービスに関連付けられている認可されたメディア・フローのみが許容されることを保証する。加えて、ＰＣＥＦ１２にインストールされているＰＣＣルールは、最適な帯域幅、最適な課金および最適な優先権が最適なベアラによって適用されることを保証する。

一旦セッション特性が通信相手（ピア：peer）間でネゴシエートされ、そして、セッション特性がＩＭＳコア・ネットワーク３ａ内で認可されると、ＡＦ１６は、対応するリソース予約が接続レイヤ１で認可できるように、ベアラ・リソースの認可をＲｘインタフェースを介してＰＣＲＦ１４に提供する。ＰＣＣアーキテクチャは、ベアラ・リソースを制御するために使用され、そして、このようにしてサービスが適切な品質−すなわち、提供される特定のサービスに対して要求される品質で、またユーザのアクセス加入およびアクセスオペレータのポリシーに従って配信されることを保証する。ＩＰ−ＣＡＮオペレータは、通常、所与の時点でユーザが利用できる同時帯域幅（たとえば、２００ｋｂｐｓビット・パイプ（bit pipe））の観点から帯域幅制限を適用する。アクセスオペレータは、また、あるアクセス技術に対して利用できる帯域幅を制限する場合がある（たとえば、ＵＴＲＡＮアクセスに対しては、許容最大帯域幅は８０ｋｂｐｓである）。アクセス・ネットワークオペレータは、また、ユーザが利用できる同時ベアラ／サービスの数を制限する場合がある。これらの制限に達し、そして、サービスに対する品質が保証できなくなる場合、ＰＣＣアーキテクチャは、サービスに対するベアラ・リソースを拒否することになるであろう。このＰＣＣ構成では、ＰＣＲＦは、ＡＦが適切な動作を行なう（たとえば、セッションを拒否する、セッションを再ネゴシエートする等）ことができるように、ＡＦに拒否の理由を通知することになるであろう。ＡＦが存在しない（Ｒｘが使用されない）状況では、ＰＣＲＦは、品質を落とすか、またはＵＥからのベアラ確立またはベアラ変更の試行を拒否さえすることになるであろう。

しかしながら、これらの制限は、アクセス・ネットワーク（ＩＰ−ＣＡＮ）オペレータによって制御され、そして管理されており、ＵＥ群およびクライアント群が制限に気付かないことを意味している。今日、使用中のＵＥ群には、最新のコーデックを使用するような高度な能力をサポートするものが多く含まれている。将来、ＵＥ群はなお一層の高度な能力をサポートできるであろう。これらのＵＥ群は、サポートする最高の能力を使用するサービスを開始することを試行するであろう。たとえば、ＩＭＳクライアントのＵＥは、通常、アクセスオペレータによって設定される任意の帯域幅制限を無視して、（他に手動で設定される場合を除き）サポートするコーデックをすべて提供することによって、セッションを開始しようと試行することになる。同様に、ユーザは、また、端末上で同時に多くのサービスを実行しようとする場合がある。たとえば、ユーザは、ＭＭＴｅｌテレビ電話をしながら同時に、電子メールをダウンロードし、そしてファイル転送プロトコル（ＦＴＰ）を使用してファイルを転送したい場合がある。この場合、ＵＥは複数のベアラを確立することを試行する可能性がある。同時に、アクティブにすることができるベアラの数は、一方ではＵＥ製造業者の実装によって制限される（すなわち、端末は同時ベアラの最大数を処理することができる）。他方、端末の能力に係わらず、ユーザが確立することが許容されるベアラの数に、ネットワークによって課される制限が存在する場合がある。

要約すると、ネットワークベースのメカニズムは、セッションに対するリソースの使用量を制御するために使用されるが、しかし、ＵＥ群は最先端の能力を使用する複数の同時サービスを保持しようとする場合がある。これは、しばしば追加の制御シグナリングをもたらすことになる。アプリケーション・レベルで、一連のリクエストおよび拒否の制御メッセージに続いて、アクセスオペレータが確立する制限を越えることなく、セッションを確立しようとして、種々の特性を使用して（たとえば、低帯域幅に対するリクエストでＱｏＳを低下させて、必要なコーデックを抑えて、または特定のメディア・タイプの使用を制限して）、元のリクエストを再試行する。ベアラ・レベルで、一連のリクエスト／拒否制御シグナリングメッセージ、またはＱｏＳの低下がサービス配信にとって容認できない場合に、潜在的にベアラ終結が結果として起こる一連のリクエスト／応答（低下したＱｏＳを容認する）メッセージかのいずれかになるであろう。

本発明は、上述を考慮して着想している。

本発明の第１の態様に従って、ＩＰ接続アクセス・ネットワークであるＩＰ−ＣＡＮにアクセスするユーザ機器ＵＥにネットワーク・リソース制限を通知する方法が提供される。ＩＰ−ＣＡＮは、ネットワーク・サービスのＵＥへの提供（プロビジョン）を認可し、そして制御する。この方法では、ＵＥから発信するメッセージがＩＰ−ＣＡＮ内で受信される。このメッセージに応答して、ＩＰ−ＣＡＮは、ＵＥに関連するネットワーク・サービスの提供に適用できるリソース制限情報を含むリプライ（reply）を送信する。リソース制限情報はそれからＵＥに転送される。

リソース制限情報は、適用されるＩＰ接続アクセス・ネットワークであるＩＰ−ＣＡＮの制限についての情報を備える場合がある。リソース制限情報は、ユーザあたりの帯域幅制限および／またはＩＰ−ＣＡＮ技術タイプ毎の帯域幅制限、および／またはユーザあたりの同時ベアラの最大数、および／またはＩＰ−ＣＡＮ技術タイプ毎の同時ベアラの最大数および／またはＩＰ−ＣＡＮリソースの使用のためのその他のオペレータが定義した制限を備える場合がある。

高い成功度でアプリケーション・セッションおよびベアラ手順を開始することができるように、アクセスオペレータによって設定されるＩＰ−ＣＡＮ制限についての情報が、ＵＥに提供されることは、利点である。言い換えると、ＵＥによって開始されるサービスの実施は、少なくともＩＰ−ＣＡＮリソース制限を超過しているためでは、拒否されることはない。

リソース制限情報は、その時点のＩＰ−ＣＡＮセッション確立手順内で−たとえば、プロトコル設定オプション（ＰＣＯ：Protocol Configuration Option）パラメータを使用して、ＵＥに伝えられることができるのは、さらなる利点である。

一旦この情報がＵＥで利用できると、ＵＥは（多分、実際のユーザの助けを借りて）、サービスリクエストが受信した帯域幅制限内に収まるように（たとえば、帯域幅を小さくすることを要求すること、必要なコーデックを抑えてリクエストすること、または特定のメディア・タイプの使用を制限することによって）サービスリクエストに適応できる。ＵＥは、また、新規のサービスリクエストに対する余地を作るために、品質を低下させるか、または存続しているフローのいくつかを終了することを選択する場合がある。

本発明の実施形態では、ＩＰ−ＣＡＮは、アクセスオペレータのポリシーを制御し、そして、ＩＰ−ＣＡＮ内でＵＥのユーザに適用するリソース制限を判定するために、ポリシーおよび課金ルール機能であるＰＣＲＦを備える。

本発明の実施形態では、本方法は、さらに、ＩＰ−ＣＡＮによって開始されるＩＰ−ＣＡＮセッション修正リクエストで、またはＵＥによって開始されるＩＰ−ＣＡＮセッション修正リクエストに応答して、更新されたリソース制限をＵＥに通知することを備える。ＩＰ−ＣＡＮがＧＰＲＳネットワークである場合、ＩＰ−ＣＡＮセッション確立コマンドおよびＩＰ−ＣＡＮセッション修正コマンドは、プロトコル設定オプション（ＰＣＯ）パラメータを備える、ＵＥまたはＧＧＳＮが開始したＰＤＰコンテキストリクエスト／修正手順に対応していても良く、ここで、ＰＣＯパラメータは、リソース制限情報を搬送するために使用される。

本発明の実施形態では、リソース制限情報は、アプリケーション・レベルシグナリング手順を使用して、アプリケーション機能からＵＥに送信されても良い。アプリケーション機能は、認可リクエストの応答で、またはＲｘ参照点でＰＣＲＦから受信される再認可リクエストで、リソース制限に関する情報を受信しても良い。アプリケーション機能は、プロキシ−呼セッション制御機能であるＰ−ＣＳＣＦに備えられていても良く、そして、リソース制限情報は、ＳＩＰ登録手順およびＳＩＰ再登録手順中に、ＵＥにプッシュダウンされても良い。

別の実施形態では、リソース制限情報はプロファイル配信サーバであるＰＤＳからＵＥにＳＩＰシグナリングを使用して転送される。ＰＤＳは、プロキシ−呼セッション制御機能であるＰ−ＣＳＣＦ内に備えられる場合がある。ＰＤＳは、リソース制限情報をＰＣＲＦから取得する場合があり、または、ＰＤＳはＰＣＲＦ内に備えられる場合がある。ＵＥは、ＩＰ−ＣＡＮ制限情報の変更通知を受信するためにＰＤＳに同意する場合がある。

本発明の実施形態では、ＰＣＲＦは、リプライを送信する前にＰＣＲＦ内のメモリからリソース制限情報を取得する、または、別のソース、たとえば、加入プロファイル・リポジトリであるＳＰＲからリソース制限情報を取得する。

好ましくは、本方法は、さらに、リソース制限情報をＵＥで記憶することを備える。

本発明の第２態様に従えば、ＩＰ通信ネットワークによって、ネットワークにアクセスするユーザ機器であるＵＥに提供される、サービスリクエストを起動するまたは受諾する方法が提供される。この方法では、ＵＥには適用できるネットワーク・リソース制限に関する情報がすでに提供されている。本方法は、所望のサービスリクエストに対する制限に適合するサービス品質であるＱｏＳを確認するためにリソース制限をチェックすること、そして、それから、ＱｏＳに対するリソースの仕様を含むサービスリクエストメッセージを生成すること、または応答することを含んでいる。サービスリクエストメッセージまたは応答メッセージは、それからネットワークに送信される。

ＱｏＳに対するリソースの仕様は、ＩＰ−ＣＡＮのために確立される制限内にあるサービス特性を備える場合がある。リソース制限をチェックした後、ＵＥが制限に適合するＱｏＳを確認できない場合、ＵＥはサービスリクエストを起動するまたは受諾する試行を放棄する、または、制限に適合する一連の改訂ＱｏＳパラメータを判定することによってサービスリクエストのＱｏＳを調整する。一連の改訂ＱｏＳパラメータは、ＵＥ内の移動端末によって、ＩＰ−ＣＡＮ制限内にあるＱｏＳ特性に従ってＩＰ−ＣＡＮベアラを確立するまたは修正する移動端末によって、またはＩＰ−ＣＡＮ制限に適合するようにセッションリクエストを調整する、ＵＥ１０内のクライアント・アプリケーションによって、判定することが可能である。ＵＥは、優先順位付けされたサービスに基づいて、ＱｏＳパラメータを改訂可能であり、このＱｏＳパラメータの改訂には、品質を低下させること、またはサービスの優先度に基づいて１つのサービスを終了させて別のサービスを選択することを備える。ＵＥは、予め設定されたユーザプリファレンスに基づいてサービスを優先順位付けする、またはサービスの優先順位付けを判定するためにユーザにポーリングをかけることができる。

本発明の第３の態様に従えば、ＩＰ−ＣＡＮにアクセスすることによって通信セッションに参加するように構成されているユーザ機器であるＵＥが提供される。ＩＰ−ＣＡＮは、ＵＥへのネットワーク・サービスの提供を認可し、そして制御して、そしてリソース制限をＵＥに提供されるサービスに適用する。ＵＥは、プロセッサ、およびネットワークにメッセージを送信し、そしてネットワークからメッセージを受信するための送受信機を備える。ＵＥは、リクエストメッセージを生成し、そしてネットワークにリクエストメッセージを送信するように構成されていて、リクエストメッセージに応答してネットワークからリプライを受信するように構成され、このリプライはＵＥに適用できるリソース制限を識別する情報を備えており、そして、リソース制限に従ってサービスの提供に対するリクエストを生成するように構成される。

ＵＥは、好ましくは、移動端末および１つ以上のクライアント・アプリケーションを備える。好ましくは、ＵＥは、さらに、リソース制限を識別する情報を記憶するためのメモリを備え、そして、プロセッサは、制限に適合するサービスに対する一連の改訂ＱｏＳパラメータを確認するために、メモリ内のリソース制限情報をチェックする。ＵＥ内のメモリは、改訂ＱｏＳパラメータを確認する根拠として使用される大量の優先順位付けされたサービスを備える場合がある。

本発明の別の態様に従って、ＩＰ通信ネットワークにおいて、ネットワークを介して通信するＵＥ群へのネットワーク・サービスの提供を認可し、そして制御するように構成されるポリシーおよび課金ルール機能であるＰＣＲＦ（Policy Charging Rules Function）が提供される。このＰＣＲＦは、ＵＥに提供されるサービスに適用できるネットワーク・リソース制限の通知をＵＥがリクエストしていることを示すメッセージを受信するための手段、ネットワーク・リソース制限を識別するための手段、およびリソース制限を識別する情報を備えるメッセージを送信するための手段を含んでいる。

ＵＥがリソース制限情報をリクエストしていることを示すメッセージは、Ｒｘ参照点で受信されるＤｉａｍｅｔｅｒ認可リクエスト、またはＧｘ参照点で受信されるＤｉａｍｅｔｅｒ課金制御リクエストのいずれかに対応する場合がある。リソース制限を識別する情報を備えるメッセージは、Ｒｘ参照点またはＧｘ参照点を介して送信されるＤｉａｍｅｔｅｒ再認可リクエスト、またはＧｘ参照点を介して送信されるＤｉａｍｅｔｅｒ課金制御回答（Answer）のいずれかに対応する場合がある。

どのようにＩＭＳが移動ネットワークアーキテクチャに順応するかを示すＧＰＲＳ／ＰＳアクセス・ネットワークの概略説明図である。 ネットワーク・エンティティのアーキテクチャ、ポリシーおよび課金制御（ＰＣＣ）システムの概略説明図である。 本発明の１つの実施形態に従う、ＵＥとＰＣＣエンティティとの間での信号フローの説明図である。 本発明の別の実施形態に従う、ＵＥとＰＣＣエンティティとの間での信号フローの説明図である。 たとえば、本発明に従ってＵＥがサービスの実施をどのように処理するかを示す、ＵＥとＰＣＣエンティティとの間での信号フローの説明図である。

図３は、ＩＰ接続アクセス・ネットワーク（ＩＰ−ＣＡＮ）を経由してＩＭＳに登録しているユーザ機器（ＵＥ）１０、たとえば、移動端末に対して（図２に示される）ＰＣＣノード間での信号フローを示している。ステップ３０１で、ＵＥは、セッション確立リクエストをＩＰ−ＣＡＮに送信することによって、ＩＰ接続アクセス・ネットワーク（ＩＰ−ＣＡＮ）に接続することを試行する。ここで、セッション確立リクエストは、ＰＣＥＦ１２で受信される。（図１に示される）ＧＰＲＳ ＩＰ−ＣＡＮに対して、ＰＣＥＦ１２はＧＧＳＮ２であり、そして、ＵＥのこのリクエストは、最初のＰＤＰコンテキストリクエストに対応する。ＰＤＰ（パケット・データ・プロトコル）コンテキストは、ＵＥあるいは移動端末と、ＧＰＲＳネットワーク上で動作するＰＤＮ（公衆データネットワーク）との間での論理結合である。ＰＤＰコンテキストは、ルーティング、ＱｏＳ（サービス品質）、セキュリティ、支払請求等のような態様を定義する。ステップ３０２で、ＰＣＥＦ１２は、（３ＧＰＰ ＴＳ２９．２１２で定義される）Ｇｘ参照点で、Ｄｉａｍｅｔｅｒ課金制御リクエスト（ＣＣＲ）メッセージをＰＣＲＦ１４に送信する。ＣＣＲメッセージには、セッションをリクエストしているＵＥ１０のＩＰアドレスを含み、そして、この実施形態に従って、ＩＰ−ＣＡＮ制限情報が提供されるリクエストも含んでいる。

この実施形態では、ＰＣＲＦ１４は、ＩＰベアラ・リソース使用量に適用する制限を含めて、アクセスオペレータのポリシーを管理する。ある実施形態では、ＰＣＲＦ１４はＩＰ−ＣＡＮ制限情報を記憶するメモリを含んでいる。このようにして、ステップ３０３で、ＰＣＲＦ１４は、自身のメモリから制限情報を取得する。別の実施形態では、ＰＣＲＦは、ＩＰ−ＣＡＮ制限情報に対するリクエストの受信時で、この情報をステップ３０３で別の情報源、たとえば、ＳＰＲ８（図２参照）から取得するように構成される。

ステップ３０４で、ＰＣＲＦは、Ｄｉａｍｅｔｅｒ課金制御回答（ＣＣＡ）メッセージをＰＣＥＦに返信する。ＣＣＡメッセージには、現在設定されているように、ＩＰ−ＣＡＮセッションに適用する、予め定義されたＰＣＣルールを含んでいる。その上、この実施形態に従って、ＣＣＡメッセージには、ＩＰ−ＣＡＮセッションに適用することになる制限についての情報を含んでいる。これらの制限には、ＰＣＲＦ１４によってリクエストされ、そして取得されるように、ＩＰ−ＣＡＮ制限についての情報だけでなく帯域幅制限（ＢＣＭ）を含む。

ステップ３０５で、ＰＣＥＦ１２は、ＩＰ−ＣＡＮセッション確立応答をＵＥ１０に送信する。これには、プロトコル設定オプション（ＰＣＯ）パラメータを使用する。このＰＣＯパラメータは、ＩＰ−ＣＡＮセッション確立手順のなかの既存のパラメータである。この実施形態に従って、ＩＰ−ＣＡＮ制限情報は、このＰＣＯパラメータを使用するＩＰ−ＣＡＮセッション確立応答に含まれる。

ステップ３０６で、ＵＥはＩＰ−ＣＡＮセッション確立応答で受信している、ＩＰ−ＣＡＮ制限に関連する情報を記憶する。ＵＥは、それから、以下でさらに詳細に説明するように、この情報を使用する状態にある。

上述した手順の結果、ＵＥに提供されるＩＰ−ＣＡＮ制限に関する情報の例には、
●ユーザあたりの帯域幅消費量限度
●ＩＰ−ＣＡＮアクセス技術ごとの帯域幅消費量限度−たとえば、ＧＰＲＳ、ＧＥＲＡＮ（ＧＳＭ−ＥＤＧＥ無線アクセス・ネットワーク）、Ｉ−ＷＬＡＮ（インターネット無線ローカル・エリア・ネットワーク）、ＤＯＣＳＩＳ（データ・オーバ・ケーブル・サービス・インタフェース仕様）等で動作するＩＰ−ＣＡＮに適用する様々な制限
●同時ベアラの最大数（ユーザ／アクセスあたり）
●ＩＰ−ＣＡＮリソースの使用に対して他のオペレータが定義した制限
がある（これに限定されない）。

現行の手順内で、ＧＰＲＳネットワークオペレータは、すでに、同時ベアラの最大数（ＧＰＲＳにおけるＰＤＰコンテキスト）をある程度制御していることに注意されたい。各加入者に対してサポートされているＰＤＰコンテキストは、移動端末がネットワークにつなげる場合の手順の一部として、ホーム・ロケーション・レジスタ（ＨＬＲ）によってＳＧＳＮ２ｂ（図１参照）に提供される。ＨＬＲは、また、加入者あたりＰＤＰコンテキストの最大数を指定する場合がある。ＳＧＳＮ２ｂは、また、設定パラメータとして、ＳＧＳＮのパフォーマンス能力に基づいて加入者あたり処理できるアクティブＰＤＰコンテキストの最大数を設定できる。しかしながら、オペレータは、依然として、動的なポリシー制御に基づいて（たとえば、時間帯に基づいて）特定ユーザに対する同時ＰＤＰコンテキストの最大数を、ＨＬＲおよびＳＧＳＮの少なくとも一方によって制御されるこれらのある程度の静的な制限以下に限定したいこともあるだろう。

一般に、ＩＰ−ＣＡＮセッション確立中にネットワークがＵＥに通知しているＩＰ−ＣＡＮ制限は、それほど頻繁に変化しないある条件を解析することによって計算される。たとえば、あるアクセス・ネットワークにおける物理的な制限があることがあり、この物理的制限は、アクセスオペレータがＩＰ−ＣＡＮセッションに対してある帯域幅以上を提供できないということを意味する。加入データは、別の要因である（たとえば、加入者に対する最大帯域幅がユーザのカテゴリに依存することがある）。これらの条件は頻繁に変化することは予期されないけれども、これらの条件は修正することができる（たとえば、物理的条件は、たとえば、ユーザが異なるＩＰ−ＣＡＮにローミングしている場合に変化し得る）。それゆえ、条件の変更が、ＩＰ−ＣＡＮセッションが修正されることを必要とする場合、ＰＣＲＦは、ＩＰ−ＣＡＮ制限が変更されているかどうかを判定し、そして、それからＵＥに通知しなければならないであろう。

この実施形態では、ＩＰ−ＣＡＮセッション確立中に使用されたものと同一のＰＣＯに基づくメカニズムが、また、ＩＰ−ＣＡＮ制限に対する更新をＵＥに提供するために使用される。このようにして、ＧＰＲＳネットワークに対して、ＧＧＳＮが開始したＰＤＰコンテキスト修正手順の中で新規の制限についての情報をＵＥに送信するために、ＰＣＯパラメータが使用される。

この実施形態内の手法の結果、移動端末（ＭＴ）は、ＵＥ内のベアラ・リソースを管理していて、ＩＰ−ＣＡＮ制限情報をＵＥ１０内に存在する種々のクライアント・アプリケーションに提供する。さらに、ＵＥ１０内に存在するクライアント・アプリケーションは、サービスがベアラ・レイヤにおいてＩＰ−ＣＡＮリソース制限によって課される限度内で実行できるかどうかを判定しなければならないであろう。サービスがリソース制限内で保証できない場合、ＵＥ１０内のクライアント・アプリケーションは、とるべき特定の動作（たとえば、このサービスまたは別のサービスの拒否、またはサービスの選択肢のユーザへの提供等）を決定することになる。これには、ＵＥ内のＭＴとクライアント・アプリケーションとの間のインタフェースが、ベアラ・レイヤにおいてＩＰ−ＣＡＮリソースの使用量制限に従って、サービスリクエストの認可を許可することが必要である。ユーザと利用できるリソースに依存するアプリケーションとの間で、ある特性のネゴシエーションを必要とするサービスに対して、ＵＥのＭＴ部は、サービスを実行するために容認できるＱｏＳ特性を、クライアント・アプリケーションがそれに応じてリクエストを調整できるように提供することになろう。

図４は、アクセス・ネットワークオペレータによって設定されるＩＰ−ＣＡＮ制限についての情報をＵＥに提供する代替の方法を示している。上述の実施形態におけるように、ＩＰ−ＣＡＮシグナリング手順によって、ＵＥに情報を提供する代わりに、この実施形態では、ＩＰ−ＣＡＮ制限情報は、アプリケーション・レベルシグナリング手順（たとえば、ＳＩＰ）を使用してＵＥに送信される。

図４に示される実施形態では、ＩＰ−ＣＡＮ制限情報は、ＳＩＰ登録処理中にＵＥに引き渡される。ステップ４０１で、ＵＥは、ＩＭＳに登録するために最初のＳＩＰ登録メッセージを送信する。ＳＩＰ登録メッセージは、Ｐ−ＣＳＣＦに転送される（上述したように、Ｐ−ＣＳＣＦは、また、ＰＣＣインフラストラクチャ内でＡＦ１６としての機能を果たす）。ステップ４０２で、Ｐ−ＣＳＣＦは、ＳＩＰ登録メッセージをＩＭＳに転送し、そして、ステップ４０３で、Ｐ−ＣＳＣＦは、ＳＩＰ２００ＯＫ応答メッセージを受信する。ステップ４０１からステップ４０３は、ＩＭＳにＵＥを登録するための通常の信号フローである。通常、この時点で、Ｐ−ＣＳＣＦは、ＵＥに、登録成功を通知する２００ＯＫメッセージを転送するであろう。しかしながら、本発明のこの実施形態では、ステップ４０４で、Ｐ−ＣＳＣＦ／ＡＦ１６は、ＲｘインタフェースでＤｉａｍｅｔｅｒ認可リクエスト（ＡＡＲ）メッセージをＰＣＲＦに送信する。ステップ４０５で、ＰＣＲＦは認可回答（ＡＡＡ）メッセージで返信する。このＡＡＡメッセージには、ＩＰ−ＣＡＮリソース制限に関する情報を含んでいる。図３の実施形態におけるように、ＰＣＲＦは、ＰＣＲＦのメモリ内から情報を取得する、または他の情報源、たとえば、ＳＰＲ１８（図２参照）から情報を取得する。ステップ４０６で、ＡＦ１６（ＩＭＳ Ｐ−ＣＳＣＦ）は２００ＯＫメッセージを、２００ＯＫ成功応答内にＩＰ−ＣＡＮ関連のポリシー制限についての情報を含めて、送信する。

この実施形態の利点は、ＩＰ−ＣＡＮ制限情報がＩＰ−ＣＡＮのタイプに係わらず、ＵＥに提供できることである。この実施形態は、また、この情報がＵＥ内のアプリケーション・レイヤで直接受信されるので、ＵＥ内で（すなわち、クライアント・アプリケーションとＵＥの移動端末部との間で）ＩＰ−ＣＡＮ制限を内部的にチェックすることを回避する。これまでの実施形態で提案されるように、ＵＥ内でアプリケーションとＩＰベアラ・プラットホームとの間の内部インタフェースが公開されなければ、ＵＥ１０内のＩＭＳアプリケーション・プラットホームが他のＩＰ−ＣＡＮ制限（たとえば、同時ベアラの最大数）に気付かなくてよいので、ＩＰ−ＣＡＮ制限情報は、この実施形態の場合、帯域幅制限に限定される可能性があろう。

再度図４を参照して、この実装形態では、ステップ４０７およびステップ４０８でＤｉａｍｅｔｅｒ再認可リクエストおよび再認可回答（ＲＡＲ／ＲＡＡ）メッセージを通して、更新されたＩＰ−ＣＡＮ制限情報をＲｘインタフェースで、ＡＦ／Ｐ−ＣＳＣＦ１６に通知する。ステップ４０９からステップ４１１におけるように、ＳＩＰ ｒｅ−ＲＥＧＩＳＴＥＲ（再登録）および２００ＯＫメッセージを交換することによって、ＵＥがＩＭＳに再登録する場合の後に、ＡＦ／Ｐ−ＣＳＣＦ１６は、ステップ４０７で受信される更新されたＩＰ−ＣＡＮ制限情報を、ステップ４１２でＵＥに送信される２００ＯＫメッセージに含めることができるであろう。ＵＥ群は、時々およびＵＥが異なるＩＰ−ＣＡＮにローミングしている場合にまた、ＩＭＳに再登録しなければならない。

別の実施形態では、エンドユーザのＵＥ内に存在するＳＩＰユーザ・エージェント（ＵＡ）は、ＩＰ−ＣＡＮ制限についての情報をプロファイル配信サーバ（ＰＤＳ）から直接取得する。ＵＡはＵＥ内のＩＭＳ／ＳＩＰレイヤを表し、このＩＭＳ／ＳＩＰレイヤは、ＵＥにおけるＩＭＳアプリケーションおよびＳＩＰシグナリングを管理する。インターネットエンジニアリングタスクフォースは、インターネット標準を発展させる責務を負っており、ＩＥＴＦ draft-ietf-sipping-config-framework-12には、ＳＩＰ ＵＡ群がプロファイル配信サーバと直接通信するための手段を仕様化している。

したがって、ＵＡは直接ＰＤＳと連絡をとり、そして設定（configuration）についての情報をＰＤＳから取得できる。この実施形態のために、設定情報はＩＰ−ＣＡＮ制限を含んでいる。ＵＡが初めてＰＤＳと連絡をとる場合、ＵＡは、受信する設定情報内のＩＰ−ＣＡＮ制限の通知に同意する（すなわち、通知を受けたい）ことをＰＤＳに通知する。原理的には、ＵＡは、ＩＰ−ＣＡＮ制限の変更通知に同意し、そして変更通知を取得するために、いつでもプロファイル配信サーバと連絡をとることができる。しかしながら、この便利さは、ユーザがＩＭＳシステム内に引き続き登録されている間に利用できるだけである可能性もある。図１および図２に示されるように、ＩＭＳおよびＰＣＣアーキテクチャ内で、Ｐ−ＣＳＣＦ５ｂまたはＳＩＰ対応のＰＣＲＦ１４のいずれかが、プロファイル配信サーバとしての機能を果たすことができる。Ｐ−ＣＳＣＦ５ｂがプロファイル配信サーバとしての機能を果たす場合、ＰＣＲＦ１４はＩＰ−ＣＡＮ制限情報を、図４に関連して上述したものと同一の手順（Ｒｘを介する、ＡＡＲ／ＡＡＡメッセージおよびＲＡＲ／ＲＡＡメッセージ）を使用して、Ｐ−ＣＳＣＦ５ｂに提供する。

この実施形態は、ＩＰ−ＣＡＮ制限情報の即時更新をＵＥに提供し、そして更新の通知がｒｅ−ＲＥＧＩＳＴＲＡＴＩＯＮが発生することを待機しなければならない、図４の実施形態の方法よりも遥かに効率がよい（すなわち、高速でそしてより頻繁である）。

この制限は、確立されたＩＰ−ＣＡＮセッション中にアクティブなサービスのすべてに対してユーザが使用できるＩＰ−ＣＡＮリソースの限度を表している。ネットワークは、ＩＰ−ＣＡＮ制限のいずれもが超過していると、新規のサービスを開始する試行を拒否する。それゆえ、一旦、ＵＥがＩＰ−ＣＡＮ制限情報を取得していると、ＵＥは、後に続くサービスに対するリクエストで、リクエストが拒否されることを回避するためにこの情報を使用できる。どのようにＵＥが情報を使用するかを示す例が、図５の信号フロー図に示される。

最初に、ＵＥ１０（ＵＥ１０内に様々なクライアント・アプリケーションおよびベアラ・リソースを処理する移動端末を備えている）は、ＩＭＳに登録していて、そして上述の方法のうちの１つに従ってＩＰ−ＣＡＮ制限に気付いている。ＰＣＣノードに加えて、この例では、ユーザにサービスを提供する２つのアプリケーション機能、ＡＦ１ １６ａおよびＡＦ２ １６ｂ、を示している。

ステップ５０１で、ユーザは帯域幅が５０ｋｂｐｓのサービス１を使用するセッションを開始しようとしている。ＵＥ１０は、ＩＰ−ＣＡＮ制限をチェックして、そして利用できる帯域幅が１００ｋｂｐｓであるので、ＯＫであることに気付く。このようにして、ステップ５０２で、ＵＥはＩＰ−ＣＡＮベアラ確立リクエストをＰＣＥＦ１２に送信する。ＩＰ−ＣＡＮベアラ確立リクエストは、ステップ５０３でＣＣＲメッセージの形式でＰＣＲＦ１４に転送される。ステップ５０４で、ＰＣＲＦはリクエストがＩＰ−ＣＡＮ制限に適合することをチェックし、そして、ステップ５０５で、ＣＣＡメッセージでＰＣＥＦ１２に応答する。ステップ５０６で、ＰＣＥＦ１２は、セッション確立成功応答をＵＥ１０に送信する。

ステップ５０７で、ユーザは帯域幅が３０ｋｂｐｓの別のサービスであるサービス２を使用しようとしている。サービス２はアプリケーション機能ＡＦ１ １６ａによって提供される。ＵＥ１０は、ＩＰ−ＣＡＮ制限を承知しており、ＩＰ−ＣＡＮ制限をチェックして、まだ、５０ｋｂｐｓの利用できる帯域幅があることが分かり、そして、それで、ステップ５０８で、ＳＤＰ提示（offer）をＡＦ１ １６ａに送信する。この提示には、ＵＥがこのサービスのためにサポートするコーデックだけでなく、特定の帯域幅を含んでいる。ステップ５０９で、この提示は確立されたセッションのネゴシエーション手順を使用してネゴシエートされる。ステップ５１０で、ＡＦ１ １６ａは認可リクエストＡＡＲメッセージをＰＣＲＦ１４に送信する。ステップ５１１で、ＰＣＲＦ１４は、ＩＰ−ＣＡＮ制限をチェックし、そしてこれらが超過していないので、肯定的な認可回答をＡＦ１ １６ａに送信する。ＡＦ１ １６ａは、それから、ステップ５１３でＳＤＰ回答（answer）をＵＥ １０に送信する。これは、リクエストされたサービス２が提供されるであろうということを示している。ステップ５１４で、ＰＣＲＦ１４は、ＩＰ−ＣＡＮリソースをＵＥ１０のために予約する。

このようにして、ユーザが新規のサービスを開始しようとした場合、リクエストされた提案ＱｏＳがＩＰ−ＣＡＮによって設定された制限のいずれにも違反していないことを、ＵＥがチェックしたということが分かる。図５にある例では、ＵＥは、リクエストされた帯域幅がＩＰ−ＣＡＮリソースの使用量に対してアクセスオペレータの制限内にあるかどうかをチェックした。しかしながら、チェックされることを必要としているであろう他の制限、たとえば、対応するベアラ手順がＩＰ−ＣＡＮによって設定される限度内に収まるかどうか、および提供されたいずれのコーデックが利用できる帯域幅を考慮して最も適切であろうかが、またある場合がある。

制限が超過していない場合、ＵＥ１０は通常の方法で新規のサービスの確立を開始することになる。制限のうちのいずれかが超過している場合、ＵＥはサービスを開始する試行を放棄する、または可能であれば、ＩＰ−ＣＡＮ制限に適合するようにサービスリクエストを調整するかのいずれかをするオプションを有するであろう。図５の例を続けると、ステップ５１５で、ＵＥ１０は、アプリケーション機能ＡＦ２ １６ｂから、ユーザにセッションに参加することを招待するＳＤＰ提示を受信する。ＳＤＰ提示は、セッションに好適なＱｏＳがコーデックの選択で３０ｋｂｐｓの帯域幅が必要であることを示唆する。ステップ５１６で、ＵＥ１０は、３０ｋｂｐｓの帯域幅がＩＰ−ＣＡＮ制限に適合するかどうかを確認し、そして利用できる帯域幅が（８０ｋｂｐｓがすでに他のベアラに予約されているので）２０ｋｂｐｓのみであることに気付く。この場合、ＵＥ１０は、セッションに参加することができるが、しかし２０ｋｂｐｓの帯域幅でのみ、そして選択されたコーデック１で可能であるという表示を提供する。この例では、ステップ５１７で、ＵＥはＡＦ２ １６ｂに利用できる帯域幅および選択されたコーデックを示すＳＤＰ回答を送信する。ＡＦ２は、それから、サービスがこの低下したＱｏＳで提供できるかどうかを判定することになる。これが容認できる場合、セッション特性が今度はＩＰ−ＣＡＮによって確立される限度内にあるので、必要とされるＱｏＳリソースがステップ５１８からステップ５２０で首尾よく承認され、そして、ステップ５２１で予約されることになる。

ＵＥ１０が、ＩＰ−ＣＡＮ制限をチェックし、そしてこの実施形態に従って、ＰＤＰコンテキストリクエスト内でまたはＳＤＰ提示／回答内で指定される帯域幅がＱｏＳに対して不十分であることを見出す場合、ＵＥは、
●サービスリクエストを開始、または容認する意図を（たとえば、着信サービスリクエストを拒否すること、またはサービスを実行するために新規の専用ＰＤＰコンテキストの開始を試行さえしないことによって）放棄する
●サービス要件を、可能であれば（たとえば、サービスリクエストを送信する前にセッション特性およびメディア特性を調整すること、またはリクエストされたＱｏＳパラメータを専用ＰＤＰコンテキストのリクエスト内で調整することによって）ＩＰ−ＣＡＮ制限に合わせて調整する
のいずれかに対する選択肢を有するであろう。

別の可能性は、ＵＥ１０がサービスを優先順位付けし、他の実施中のサービスより新規のサービスリクエストを選択することができようということである。たとえば、ＵＥは、ステップ５１５で受信するＳＩＰ ＩＮＶＩＴＥ（ＳＩＰ招待）でリクエストされるサービスが、サービス１またはサービス２のいずれよりも高い優先度を有していることを決定することができよう。したがって、ＵＥは、ＳＩＰ ＩＮＶＩＴＥをリクエストされた帯域幅で容認し、そしてその代わりに帯域幅を減らすか、またはサービス１およびサービス２のうちどちらかを放棄することができよう。リクエストされている新規のサービスがＱｏＳをダウングレードさせることが容認できない場合、ＵＥは低優先度のサービス（たとえば、サービス１またはサービス２）を終了し、そして新規のサービスに移ることが可能である。この場合、ＵＥは、予め設定されたユーザプリファレンス（たとえば、「新規の着信ＭＴＳＩ呼に十分な帯域幅を有しない場合、他のいずれかのサービスを打ち切る」）に基づいて、サービスを優先順位付け可能である。

別の代替案は、ＵＥが実際のユーザを決定に関与させることである。たとえば、ユーザがテレビ会議に参加しており、メールボックスを読み、そしてウェブ・ページにアクセスしていて、そして、それから着信音声呼を受信すると、ＵＥは、ユーザが選択するための選択肢を提供するポップアップ・メッセージを端末画面上に表示するように構成することができる。たとえば、ポップアップ・メッセージは、「新規のエントリ呼出にはリソースが不足しています。差し支えなければ、エキスプローラを停止します。許可します／拒否します”と示すことができよう。

しかしながら、これらの制限は、アクセス・ネットワーク（ＩＰ−ＣＡＮ）オペレータによって制御され、そして管理されており、ＵＥ群およびクライアント群が制限に気付かないことを意味している。今日、使用中のＵＥ群には、最新のコーデックを使用するような高度な能力をサポートするものが多く含まれている。将来、ＵＥ群はなお一層の高度な能力をサポートできるであろう。これらのＵＥ群は、サポートする最高の能力を使用するサービスを開始することを試行するであろう。たとえば、ＩＭＳクライアントのＵＥは、通常、アクセスオペレータによって設定される任意の帯域幅制限を無視して、（他に手動で設定される場合を除き）サポートするコーデックをすべて提供することによって、セッションを開始しようと試行することになる。同様に、ユーザは、また、端末上で同時に多くのサービスを実行しようとする場合がある。たとえば、ユーザは、ＭＭＴｅｌテレビ電話をしながら同時に、電子メールをダウンロードし、そしてファイル転送プロトコル（ＦＴＰ）を使用してファイルを転送したい場合がある。この場合、ＵＥは複数のベアラを確立することを試行する可能性がある。同時に、アクティブにすることができるベアラの数は、一方ではＵＥ製造業者の実装によって制限される（すなわち、端末は同時ベアラの最大数を処理することができる）。他方、端末の能力に係わらず、ユーザが確立することが許容されるベアラの数に、ネットワークによって課される制限が存在する場合がある。
更なる例によれば、３ＧＰＰ ＴＳ ２３．０６０ バージョン７．５．０は、汎用パケット無線サービス（ＧＰＲＳ）に対するサービス記述を定義する。この仕様に従えば、ＰＤＰコンテキストの形式で、個々のＩＰ−ＣＡＮベアラを確立する場合あるいは修正する場合は、ＭＳはこのベアラに対して要求されているＱｏＳを含むリクエストを、サービングＧＰＲＳサポートノード（ＳＧＳＮ）へ送信する。次に、このＳＧＳＮは、要求されているＱｏＳに制限して、これを「ネゴシエートされたＱｏＳ」としてゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）へ送信することができる。次に、ＧＧＳＮは、ネゴシエートされたＱｏＳをＳＧＳＮへ返信するまえにそのネゴシエートされたＱｏＳを更に制限することができる。この時点は、ＳＧＳＮが、このネゴシエートされたＱｏＳをＭＳへ返信する前にネゴシエートされたＱｏＳを追加的に制限することができる時点である。次に、ＭＳは、このＩＰ−ＣＡＮベアラをおそらくデアクティベーションすることになるＩＰ−ＣＡＮによって判定される、ネゴシエートされたＱｏＳを受け付けることができない場合がある。更に、ＭＳは、ＭＳとＩＰ−ＣＡＮとの間のセッションに適用されるリソース制限における情報を持っていないので、ＭＳは、更に、これらの制限に合致しない更なるベアラ確立リクエストを送信する可能性があり、その結果、更なる失敗した試行を行なうことになる。

本発明の第１の態様に従って、ＩＰ接続アクセス・ネットワークであるＩＰ−ＣＡＮにアクセスするユーザ機器ＵＥに、ＵＥとＩＰ−ＣＡＮとの間のＩＰ−ＣＡＮのセッションに適用可能なネットワーク・リソース制限を通知する方法が提供される。ＩＰ−ＣＡＮは、ネットワーク・サービスのＵＥへの提供（プロビジョン）を認可し、そして制御する。この方法では、ＵＥとＩＰ−ＣＡＮとの間のＩＰ−ＣＡＮのセッションの確立中に、ＵＥから発信するＩＰ−ＣＡＮセッション確立リクエストがＩＰ−ＣＡＮ内のポリシー及び課金執行機能であるＰＣＥＦで受信される。このリクエストに応答して、ポリシーおよび課金ルール機能であるＰＣＲＦにＩＰ−ＣＡＮリソース制限情報に対するリクエストを送信し、それに応じて、ＵＥとＩＰ−ＣＡＮとの間のＩＰ−ＣＡＮのセッションに適用可能なリソース制限情報を受信する。ＰＣＥＦは、ＩＰ−ＣＡＮのセッションのリソース制限情報を含むＩＰ−ＣＡＮセッション確立応答をＵＥに送信する。ＩＰ−ＣＡＮのセッションのリソース制限情報はそれからＵＥに記憶するために転送される。

本発明の第２態様に従えば、ＩＰ接続アクセスネットワークであるＩＰ−ＣＡＮにアクセスするユーザ機器であるＵＥに対するサービスリクエストを起動するまたは受諾する方法が提供される。この方法では、ＵＥには、ＵＥとＩＰ−ＣＡＮとの間のＩＰ−ＣＡＮセッションに適用できるネットワーク・リソース制限に関する情報がすでに提供されている。本方法は、所望のサービスリクエストに対する制限に適合するサービス品質であるＱｏＳを確認するために、ＩＰ−ＣＡＮセッションのリソース制限をチェックすること、そして、それから、ＱｏＳに対するリソースの仕様を含むサービスリクエストメッセージを生成すること、または応答することを含んでいる。サービスリクエストメッセージまたは応答メッセージは、それからＩＰ−ＣＡＮに送信される。

本発明の第３の態様に従えば、ＩＰ−ＣＡＮにアクセスすることによって通信セッションに参加するように構成されているユーザ機器であるＵＥが提供される。ＩＰ−ＣＡＮは、ＵＥへのネットワーク・サービスの提供を認可し、そして制御して、そしてリソース制限をＵＥとＩＰ−ＣＡＮとの間のＩＰ−ＣＡＮのセッションに適用する。ＵＥは、プロセッサ、およびＩＰ−ＣＡＮにメッセージを送信し、そしてＩＰ−ＣＡＮからメッセージを受信するための送受信機を備える。ＵＥは、リクエストメッセージを生成し、そしてＩＰ−ＣＡＮにリクエストメッセージを送信するように構成されていて、リクエストメッセージに応答してＩＰ−ＣＡＮからリプライを受信するように構成され、このリプライはＵＥに適用できるリソース制限を識別する情報を備えており、そして、ＩＰ−ＣＡＮのセッションのリソース制限に従ってサービスの提供に対するリクエストを生成するように構成される。

本発明の別の態様に従って、ＩＰアクセス接続ネットワークであるＩＰ−ＣＡＮにおいて、ＵＥとＩＰ−ＣＡＮとの間のＩＰ−ＣＡＮのセッションに適用可能なリソース制限を判定するように構成されるポリシーおよび課金ルール機能であるＰＣＲＦ（Policy Charging Rules Function）が提供される。このＰＣＲＦは、ＩＰ−ＣＡＮのセッションに適用できるネットワーク・リソース制限の通知をＵＥがリクエストしていることを示すメッセージを受信するための手段、ＩＰ−ＣＡＮのセッションのリソース制限を識別するための手段、およびＩＰ−ＣＡＮのセッションのリソース制限を識別する情報を備えるメッセージを送信するための手段を含んでいる。

ＵＥがＩＰ−ＣＡＮのセッションのリソース制限情報をリクエストしていることを示すメッセージは、Ｒｘ参照点で受信されるＤｉａｍｅｔｅｒ認可リクエスト、またはＧｘ参照点で受信されるＤｉａｍｅｔｅｒ課金制御リクエストのいずれかに対応する場合がある。ＩＰ−ＣＡＮのセッションのリソース制限を識別する情報を備えるメッセージは、Ｒｘ参照点またはＧｘ参照点を介して送信されるＤｉａｍｅｔｅｒ再認可リクエスト、またはＧｘ参照点を介して送信されるＤｉａｍｅｔｅｒ課金制御回答（Answer）のいずれかに対応する場合がある。

Claims (26)

1. ユーザ端末であるＵＥ（１０）にネットワーク・サービスの提供を認可し制御する、ＩＰ接続アクセス・ネットワークであるＩＰ−ＣＡＮにアクセスする前記ＵＥ（１０）に、ネットワーク・リソース制限を通知する方法であって、
   前記ＵＥ（１０）が関与するネットワーク・サービスの提供に適用可能なリソース制限情報を含むリプライ（３０５、４０５）を前記ＩＰ−ＣＡＮが送信することに応じて、前記ＵＥ（１０）から前記ＩＰ−ＣＡＮでメッセージ（３０１、４０４）を受信するステップ（３０１、４０４）と、
   前記リソース制限情報を前記ＵＥ（１０）へ転送するステップ（３０５、４０６）と
   を備えることを特徴とする方法。
2. 前記リソース制限情報は、適用する前記ＩＰ接続アクセス・ネットワークであるＩＰ−ＣＡＮについての情報を含み、
   前記ＩＰ接続アクセス・ネットワークであるＩＰ−ＣＡＮについての情報は、ユーザあたりの帯域幅制限、ＩＰ−ＣＡＮ技術タイプ毎の帯域幅制限、ユーザあたりの同時ベアラの最大数、ＩＰ−ＣＡＮ技術タイプ毎の同時ベアラの最大数、およびＩＰ−ＣＡＮリソースの使用のためのその他のオペレータが定義した制限の少なくとも１つを含む
   ことを特徴とする請求項１に記載の方法。
3. 前記ＩＰ−ＣＡＮは、アクセスオペレータのポリシーを制御し、かつ、前記ＩＰ−ＣＡＮ内で前記ＵＥのユーザに適用する前記リソース制限を判定するための、ポリシーおよび課金ルール機能であるＰＣＲＦ（１４）を備える
   ことを特徴とする請求項１または２に記載の方法。
4. 前記リソース制限情報は、ＩＰ−ＣＡＮセッション確立リクエスト（３０１）に応じて、プロトコル設定オプションパラメータによって、前記ＵＥ（１０）に転送される
   ことを特徴とする請求項１乃至３のいずれか１項に記載の方法。
5. 前記ＩＰ−ＣＡＮによって開始されるＩＰ−ＣＡＮセッション修正リクエストで、あるいは前記ＵＥ（１０）によって開始されるＩＰ−ＣＡＮセッション修正リクエストに応じて、更新されたリソース制限を前記ＵＥ（１０）に通知するステップ（４１２）を更に備える
   ことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
6. 前記ＩＰ−ＣＡＮはＧＰＲＳネットワークであり、
   前記ＩＰ−ＣＡＮセッション確立リクエストおよび前記ＩＰ−ＣＡＮセッション修正リクエストは、プロトコル設定オプション（ＰＣＯ）パラメータを備える、ＵＥ（１０）またはＧＧＳＮ（２ａ）が開始したＰＤＰコンテキストリクエスト／修正手順に対応し、
   前記プロトコル設定オプション（ＰＣＯ）パラメータは、前記リソース制限情報を搬送するために使用される
   ことを特徴とする請求項５に記載の方法。
7. 前記リソース制限情報は、アプリケーション・レベルシグナリング手順を使用して、アプリケーション機能（１６）から、前記ＵＥ（１０）へ送信される
   ことを特徴とする請求項３に記載の方法。
8. 前記アプリケーション機能（１６）は、認可リクエスト（３０５）の応答で、またはＲｘ参照点で前記ＰＣＲＦ（１４）から受信される再認可リクエストで、リソース制限に関する情報を受信する
   ことを特徴とする請求項７に記載の方法。
9. 前記アプリケーション機能（１６）は、プロキシ呼セッション制御機能であるＰ−ＣＳＣＦに備えられ、前記リソース制限情報は、セッション開始プロトコルであるＳＩＰ登録手順およびＳＩＰ再登録手順中に、前記ＵＥ（１０）にプッシュダウンされる
   ことを特徴とする請求項８に記載の方法。
10. 前記リソース制限情報は、ＳＩＰシグナリングを使用して、プロファイル配信サーバであるＰＤＳから前記ＵＥ（１０）へ転送される
    ことを特徴とする請求項３に記載の方法。
11. 前記ＰＤＳは、プロキシ呼セッション制御機能であるＰ−ＣＳＣＦに備えられていて、かつ、前記ＰＣＲＦ（１４）から前記リソース制限情報を取得する、あるいは前記ＰＣＲＦ（１４）に備えられている
    ことを特徴とする請求項１０に記載の方法。
12. 前記ＵＥ（１０）は、前記リソース制限情報の変更の通知を受信するために、前記ＰＤＳに同意する
    ことを特徴とする請求項１０または１１に記載の方法。
13. 前記ＲＣＲＦ（１４）は、前記リプライを送信する前に、前記ＲＣＲＦ（１４）のメモリから前記リソース制限情報を取得する、あるいは加入プロファイル・リポジトリであるＳＰＲ（１８）から前記リソース制限情報を取得する
    ことを特徴とする請求項１乃至１２のいずれか１項に記載の方法。
14. 前記ＵＥ（１０）において、前記リソース制限情報を記憶するステップを更に備える
    ことを特徴とする請求項１乃至１３のいずれか１項に記載の方法。
15. ＩＰ通信ネットワーク（３）にアクセスするユーザ機器であるＵＥ（１０）であって、適用可能なネットワーク・リソース制限に関連する情報が提供されているＵＥ（１０）に、前記ＩＰ通信ネットワーク（３）によって提供されるサービスリクエストを起動するまたは受諾する方法であって、
    所望のサービスリクエストに対する前記ネットワーク・リソース制限に適合するサービス品質であるＱｏＳを確認するために、前記ネットワーク・リソース制限（５０１、５０７、５１６）をチェックするステップと、
    前記ＱｏＳに対するリソースの仕様を含むサービスリクエストメッセージを生成する（５０２、５０８）または応答する（５１７）ステップと、
    前記サービスリクエストメッセージまたは応答メッセージを、前記ＩＰ通信ネットワーク（３）に送信するステップと
    を備えることを特徴とする方法。
16. 前記ＱｏＳに対する前記リソースの仕様は、ＩＰ−ＣＡＮのために確立される前記ネットワーク・リソース制限内にあるサービス特性を備え、
    前記ネットワーク・リソース制限をチェックした後、前記ＵＥが前記ネットワーク・リソース制限に適合するＱｏＳを確認できない場合、前記ＵＥはサービスリクエストを起動するまたは受諾する試行を放棄する、または、前記ネットワーク・リソース制限に適合する一連の改訂ＱｏＳパラメータを判定することによって前記サービスリクエストのＱｏＳを調整する
    ことを特徴とする請求項１５に記載の方法。
17. 前記一連の改訂ＱｏＳパラメータは、前記ＵＥ（１０）内の移動端末であって、前記ネットワーク・リソース制限内にあるＱｏＳ特性に従ってＩＰ−ＣＡＮベアラを確立するまたは修正する移動端末によって、または前記ネットワーク・リソース制限に適合するようにセッションリクエストを調整する前記ＵＥ１０内のクライアント・アプリケーションによって、判定される
    ことを特徴とする請求項１６に記載の方法。
18. 前記ＵＥ（１０）は、優先順位付けされたサービスに基づいて、前記一連の改訂ＱｏＳパラメータを改訂し、
    前記改訂には、品質を低下させること、または前記サービスの優先度に基づいて１つのサービスを終了させて別のサービスを選択することを含む
    ことを特徴とする請求項１７に記載の方法。
19. 前記ＵＥ（１０）は、予め設定されたユーザプリファレンスに基づいて前記サービスを優先順位付けする、または前記サービスの優先順位付けを判定するためにユーザにポーリングをかける
    ことを特徴とする請求項１８に記載の方法。
20. ＩＰ接続アクセス・ネットワークであるＩＰ−ＣＡＮにアクセスすることによって通信セッションに参加するように構成されているユーザ機器であるＵＥ（１０）であって、
    前記ＩＰ−ＣＡＮは、前記ＵＥ（１０）へのネットワーク・サービスの提供を認可し、かつ制御し、更に、リソース制限を前記ＵＥ（１０）に提供されるサービスに適用するものであり、
    前記ＵＥ（１０）は、プロセッサ、および前記ＩＰ接続アクセス・ネットワークにメッセージを送信し、そして前記ＩＰ接続アクセス・ネットワークからメッセージを受信するための送受信機を備え、
    前記ＵＥ（１０）は、更に、
    リクエストメッセージ（３０１、４０１）を生成して、前記ＩＰ接続アクセス・ネットワークにリクエストメッセージを送信し
    前記リクエストメッセージに応じて、前記ＵＥ（１０）に適用可能な前記リソース制限を識別する情報を備えるリプライ（３０５、４０６）を前記ＩＰ接続アクセス・ネットワークから受信し、
    前記リソース制限に従ってサービスの提供に対するリクエスト（５０１、５０７、５１６）を生成する
    ように構成されている
    ことを特徴とするユーザ機器。
21. 移動端末および１つ以上のクライアント・アプリケーションを備える
    ことを特徴とする請求項２０に記載のユーザ機器。
22. 前記リソース制限を識別する情報を記憶するためのメモリを更に備え、
    前記プロセッサは、前記リソース制限に適合する前記サービスに対する一連の改訂ＱｏＳパラメータを確認するために、前記メモリ内のリソース制限情報をチェックするように構成されている
    ことを特徴とする請求項２０または２１に記載のユーザ機器。
23. 前記メモリは、優先順位付けされたサービスを記憶し、
    前記プロセッサは、前記優先順位付けされたサービスに基づいて、前記一連の改訂ＱｏＳパラメータを確認する
    ことを特徴とする請求項２０に記載のユーザ機器。
24. ＩＰ通信ネットワークにおいて、前記ＩＰ通信ネットワークを介して通信するＵＥ群へのネットワーク・サービスの提供を認可し、制御するように構成されているポリシーおよび課金ルール機能であるＰＣＲＦ（１４）であって、
    ユーザ機器であるＵＥ（１０）に提供されるサービスに適用可能なネットワーク・リソース制限の通知を前記ＵＥ（１０）がリクエストしていることを示すメッセージを受信するための手段と
    前記ネットワーク・リソース制限を識別するための手段と、
    前記リソース制限を識別する情報を備えるメッセージ（３０４、４０５）を送信するための手段と
    を備えていることを特徴とするＰＣＲＦ（１４）。
25. ＵＥ（１０）がネットワーク・リソース制限の情報をリクエストしていることを示す前記メッセージは、Ｒｘ参照点で受信されるＤｉａｍｅｔｅｒ認可リクエスト、またはＧｘ参照点で受信されるＤｉａｍｅｔｅｒ課金制御リクエストのいずれかに対応する
    ことを特徴とする請求項２４に記載のＰＣＲＦ（１４）。
26. 前記ネットワーク・リソース制限を識別する情報を備える前記メッセージは、Ｒｘ参照点またはＧｘ参照点を介して送信されるＤｉａｍｅｔｅｒ再認可リクエスト、またはＧｘ参照点を介して送信されるＤｉａｍｅｔｅｒ課金制御回答のいずれかに対応する
    ことを特徴とする請求項２４に記載のＰＣＲＦ（１４）。

Images