サービスイベントトリガ
通信ネットワークにおけるポリシー及び課金実施機能（ＰＣＥＦ）ノードは、セッション中のサービストラフィック検出を実行するサービストラフィック検出器を備える。プロセッサは、サービストラフィック検出から所定のサービスコンディションを検出する。ＰＣＥＦは、Ｇｘ参照ポイントを介してイベントトリガＡＶＰにおいて定義されているサービスイベントを用いて、検出されたサービスコンディションのポリシー及び課金ルール機能（ＰＣＲＦ）を通知する。ＰＣＲＦは、検出されたサービスコンディションの通知を受信し、例えばサービスに適用されるサービス品質を制御することによって、検出されたサービスコンディションに応じてサービス提供を制御する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービスイベントトリガに関し、より詳細には、セッション中の課金に基づくユーザセッションにおけるサービス品質パラメータの修正を許容するためのサービスイベントトリガに関するものである。
【背景技術】
【０００２】
モバイル通信ネットワークのコアネットワークでは、２人のユーザ間でデータを送信するために資源が提供されなければならない。提供された資源は、複数のユーザによって経験されるサービス品質を決定する。ＥＴＳＩ第３世代パートナーシッププロジェクト（３ＧＰＰ）によって定義されるネットワークにおいて、ポリシー及び課金ルール機能（ＰＣＲＦ）、ポリシー及び課金実施機能（ＰＣＥＦ）、及び、ＰＣＲＦとＰＣＥＦの間に横たわるＧｘ参照ポイントが定義される。３ＧＰＰ ＴＳ２９．２１２で定義されるように、Ｇｘ参照ポイントは、ＰＣＲＦからＰＣＥＦへのポリシー及び課金制御（ＰＣＣ）ルールの提供及び削除、ＰＣＥＦからＰＣＲＦへのトラフィックプレーンイベントの送信のために使用される。このように、Ｇｘ参照ポイントは、課金制御、ポリシー制御、又は、その両方のために使用されうる。
【０００３】
３ＧＰＰにおいて定義されるネットワークに場合において、ＰＣＥＦは、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）に実装されてもよく、ディープパケットインスペクション（ＤＰＩ）技術をサポートできるＧＧＳＮにおいて知られている。ＤＰＩ技術は、ノードがパケットインスペクションと、当該ノードを通過するデータ上でのサービス区分とを実行することを許容する。より詳細には、ＩＰパケットが、当該ＩＰパケットが特定のサービスセッションへ割り当てられるように、ルールの構造ツリーに従って区分される。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、既知のＧＧＳＮにおけるＤＰＩ技術の使用は、サービス区分に基づく任意のサービスの差別化を許容していない。
【課題を解決するための手段】
【０００５】
本発明の第１の形態によれば、通信ネットワークにおけるポリシー及び課金実施機能ノードが提供され、セッション中にサービストラフィック検出を実行するサービストラフィック検出器と、前記サービストラフィック検出から所定のサービスコンディションを検出するプロセッサと、Ｇｘ参照ポイント上でのイベントトリガＡＶＰで定義されるサービスイベントを用いて、前記検出されたサービスコンディションを、ポリシー及び課金ルール機能へ通知するインタフェースとを備えることを特徴とする。
【０００６】
これは、ポリシー及び課金ルール機能が適切なポリシー及び課金制御ルールをインストールできる、例えば、所望のサービス品質が検出されたサービスコンディションに対して達成されるという、利益を有する。
【０００７】
一実施形態において、インタフェースは、さらに、前記Ｇｘ参照ポイント上でのサービス開始停止ＡＶＰを用いて、検出されたサービスコンディションがサービス開始であるか又はサービス停止であるかをポリシー及び課金ルール機能へ通知するようにさらに適合される。これは、ポリシー及び課金ルール機能が、サービスが開始されると適切なポリシー及び課金制御ルールをインストールし、サービスが停止するとオリジナルのポリシー及び課金制御ルールを再インストールすることを許容する。
【０００８】
一実施形態において、インタフェースは、さらに、ＩＰアドレスＡＶＰを用いて、前記セッションにおける関連付けられたＩＰアドレスと、前記Ｇｘ参照ポイント上でのメディアコンポーネントディスクリプションを用いて、フロー情報とを、前記ポリシー及び課金ルール機能へ通知するように適合される。
【０００９】
一実施形態において、インタフェースは、さらに、前記Ｇｘ参照ポイント上でのアプリケーション識別子ＡＶＰを用いて、前記検出されたサービスコンディションが適用されるサービスを、前記ポリシー及び課金ルール機能へ通知するように適合される。
【００１０】
本発明の他の形態によれば、ポリシー及び課金実施機能からの通知を受信するポリシー及び課金ルール機能ノードを提供する。また、第１の形態におけるポリシー及び課金実施機能に対応する動作の方法について提供する。
【図面の簡単な説明】
【００１１】
【図１】本発明の一形態に従った通信の一部を示すブロック図である。
【図２】本発明の一形態に従った方法を示すフローチャートである。
【図３】図２の方法における第１部分中におけるメッセージフローを示す図である。
【図４】図２の方法における第２部分中におけるメッセージフローを示す図である。
【発明を実施するための形態】
【００１２】
図１は、通信ネットワークを示し、特に、３ＧＰＰの仕様書に定義されているように、モバイル通信ネットワークのコアネットワーク１０の一部を示す。
【００１３】
コアネットワーク１０の１つの要素は、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１２である。従来のように、モバイル通信ネットワークの無線アクセスネットワーク（ＲＡＮ）１４はＧＧＳＮ１２へ接続される。ＧＧＳＮ１２は、ユーザ装置（ＵＥ）１６が適切な無線インタフェースを介して呼を確立することを許容する。上記呼は、ＲＡＮを通じて上記ネットワークの他のＵＥに経路づけられるか、又は、インターネットなどのパケットデータネットワーク１８を介して固定回線若しくはモバイル通信デバイスへ、データセッションの場合はリモートサーバへ接続されうる。当該ネットワークのこの形態は、従来のものであり、さらなる詳細な説明は割愛する。
【００１４】
従来と同様に、ＧＧＳＮ１２は、ポリシー及び課金実施機能（ＰＣＥＦ）を含む。この場合、ＧＧＳＮに含まれるＰＣＥＦは、ディープパケットインスペクション（ＤＰＩ）を実行するサービストラフィック検出ブロック２２を有する。これは、それらが特定のサービスセッションへ割り当てられるようにルールの構造ツリーに従ったＩＰパケットの分類から成る、パケットインスペクション及びサービス区分を許容する。ＤＰＩ機能を有するノードは、ユーザと、シグナリングトラフィックと、を捕捉し、ＩＰパケットを特定のサービスセッションへ割り当て、サービス開始コンディション及びサービス停止コンディションを検出することができる。
【００１５】
ＰＣＥＦはまた、以下で詳細に説明する処理の一部を実行するプロセッサ２４と、コアネットワーク１０の他のブロックへ接続するためのインタフェースブロック２６とを備える。
【００１６】
図１はサービストラフィックブロック２２、プロセッサ２４、及びインタフェースブロック２６が理解を容易にするために個別のブロックとして示されているが、関係のある機能が任意の従来の手段によって実行され、それらのブロックが実際に明確に認識される必要はないことが理解されるであろう。
【００１７】
本発明の他の実施形態において、ＰＣＥＦは、パケットデータネットワーク（ＰＤＮ）ゲートウェイに実装されるてもよい。
【００１８】
従来と同じように、コアネットワーク１０はまた、ポリシー及び課金ルール機能（ＰＣＲＦ）２８を備え、その構造は、従来と同様であり、以下で詳細に説明する処理の一部を実行するプロセッサ３０と、コアネットワーク１０の他のブロックへ接続するためのインタフェースブロック３２とを備える。例えば、ＰＣＲＦ２８は、エリクソンサービスアウェアポリシー制御部（ＳＡＰＣ）に実装されてもよい。
【００１９】
図１は説明を容易にするために個別のブロックとしてプロセッサ３０及びインタフェースブロック３２を示しているが、関連のある機能が従来の任意の手段によって実行されてもよく、それらのブロックが実際に明確に認識される必要はないことが理解されるであろう。
【００２０】
ＰＣＥＦ２０はまた、オフライン課金システム（ＯＦＣＳ）３４と、モバイルネットワーク拡張ロジック（ＣＡＭＥＬ）サービス制御ポイント３８及びクレジット制御ブロック４０に基づくサービスデータフローのためのカスタマイズされたアプリケーションを含むオンライン課金システム３６へ接続される。
【００２１】
ＰＣＲＦ２８は、加入者プロファイルリポジトリ（ＳＰＲ）４２と、アプリケーション機能（ＡＦ）４４とに接続される。例えば、ＡＦ４４は、ＩＰマルチメディアサブシステム（ＩＭＳ）プロキシ呼セッション制御機能（Ｐ−ＣＳＣＦ）であってもよい。
【００２２】
ＰＣＥＦ２０及びＰＣＲＦ２８は、３ＧＰＰ ＴＳ２９．２１２で定義されるように、Ｇｘ参照ポイント上で通信を行う。Ｇｘ参照ポイントは、ＰＣＲＦからＰＣＥＦへのＰＣＣルールの提供及び削除と、ＰＣＥＦからＰＣＲＦへのトラフィックプレーンイベントの送信に使用される。Ｇｘ参照ポイントは課金制御、ポリシー制御、又はその両方に使用されうる。
【００２３】
ＰＣＲＦ２８及びＡＦ４４は、３ＧＰＰ ＴＳ ２９．２１４に定義されるように、Ｒｘ参照ポイント上で通信を行う。Ｒｘ参照ポイントは、ＰＣＲＦとＡＦとの間でアプリケーションレベルセッション情報を交換するために使用される。
【００２４】
ＰＣＥＦ２０とＯＣＳ３６がＧｙ参照ポイント上で通信を行い、ＰＣＲＦ２８とＳＰＲ４２とがＳｐ参照ポイント上で通信を行う間、ＰＣＥＦ２０及びＯＦＣＳ３４は、Ｇｚ参照ポイント上で通信を行う。
【００２５】
上述した一般的な構成が３ＧＰＰ ＴＳ２９．２１２において示されるため、さらなる詳細な説明は割愛する。
【００２６】
本発明に係る方法についてさらに詳細に図２のフローチャートと、図３及び図４に示す様々なノード間のメッセージフローを参照して説明する。特に、図２は、ＰＣＥＦ２０及びＰＣＲＦ２８で実行されるステップを示し、一方で、図３及び図４は、ＵＥ１６、ＰＣＥＦ２０、ＰＣＲＦ２８、及びＵＥ１６に接続される他のＵＥ又はサーバの間で送信されるメッセージを示す。
【００２７】
処理は、ＵＥ１６が遠隔ＵＥ／サーバと確立される一般用途のパケットデータプロトコル（ＰＤＰ）コンテキストを用意すると開始される。ステップ６０において、ＰＣＥＦは、データトラフィック上で、ディープパケットインスペクション（ＤＰＩ）、又は他の形式のサービストラフィック検出を実行する。
【００２８】
処理を開始する前に、ＰＣＥＦは、イベントがＰＣＲＦへ通知されるためのサービスセットとともに提供される。例えば、システムは、所定のサービスがプレミアムコンテンツとして特定され、一方で他のサービスが非プレミアムコンテンツとして特定されるような方法で構成されてもよい。より詳細な例として、タイムクリティカルな音楽、ビデオクリップ、及びオペレータ自身のポータルがプレミアムコンテンツとして特定され、一方でピアツーピアファイル交換などのサービスが非プレミアムコンテンツとして見なされるかもしれない。ＰＣＥＦは、それらのサービスいずれかを認識するように構成されるかもしれない。ＰＣＲＦは、同じサービスセットと、それらのサービスのそれぞれへ適用されるであろうポリシーとともに提供されべきである。
【００２９】
従って、ステップ６２において、ＰＣＥＦは提供されるサービスの１つの開始を検出するまで、図３のポイント６４に示すように、トラフィックを監視する。ＰＣＥＦは、任意の適切な技術によるサービスの開始を、例えば、ＤＰＩの使用によって可能となる発見的手法を用いて、検出することができる。
【００３０】
ＰＣＥＦがサービス開始コンディションを検出すると、ステップ６６において、非活動タイマを開始する。その後、ステップ６８において、ＰＣＥＦ２０は、新たに定義されるサービスイベントを示す値に設定されたイベントトリガＡＶＰによってＧｘインタフェース上でのクレジット制御要求（ＣＣＲ）コマンドを用いて、ＰＣＲＦ２８へサービス開始コンディションを通知する。
【００３１】
本発明の図示した実施形態において、新たに定義されるサービス情報ＡＶＰはＰＣＲＦが当該通知を扱うことを許容するために追加情報を伝送するために使用される。
【００３２】
サービス開始停止ＡＶＰはイベントがサービス開始又はサービス停止のいずれに対応するかどうかを示す（ここでは、サービス開始イベントを示すように設定される）。
【００３３】
フレイムドＩＰアドレス（ＡＶＰ）は、ＲＦＣ４００５で特定されるように符号化されたＩＰアドレスに関連付けられたＩＰ−ＣＡＮを含む。メディアコンポーネントディスクリプションＡＶＰなどの他のＡＶＰは、関連のあるフロー情報を含む。例えば、ＲＴＳＰシグナリングは、シグナリング中にネゴシエートされた、リアルタイムトランスポートプロトコル（ＲＴＰ）のオーディオ又はビデオデータフローに対応するＩＰアドレス及びポートについての情報を伝送する。これにより、ＰＣＲＦがそれらのネゴシエートされたＩＰアドレス及びポート下で第２のＰＤＰコンテキストを作成することができる。
【００３４】
アプリケーション識別子ＡＶＰは、検出された特定のサービス（例えば、リアルタイムストリーミングプロトコル（ＲＴＳＰ））を識別する情報を含む。当該情報は、異なるアプリケーションサービスにおける差別化されたＱｏＳを提供するためにＰＣＲＦによって使用されてもよい。
【００３５】
ステップ７０において、ＰＣＲＦは、ＰＣＥＦからの通知を受信し、通知が成功であったことを示す結果コードとともに、クレジット制御応答（ＣＣＡ）を送信することによって当該通知を信号制御する。
【００３６】
ステップ７２において、ＰＣＲＦは、Ｇｘ再認証要求（ＲＡＲ）メッセージをＰＣＥＦへ送信することによって対応ＰＣＣルールをインストールする。これは、より高い又はより低いＱｏＳ設定で、開始されているサービスに依存して、既存のベアラの修正（又は専用のベアラの作成）を許容する。ステップ７４において、ＰＣＥＦは、通知が成功であったことを示す結果コードとともに再認証応答をＰＣＲＦへ送信することによって、当該コマンドを承認する。
【００３７】
上記通知に応じて、ＰＣＲＦは、検出されたサービスコンディションに応じてサービス提供を制御するための任意の適切なステップを取ってもよい。これは、サービスセッションにおけるＱｏＳ設定の修正に影響を与えることができ、順に、以下の非完全なリストから以下のアクションの何れかから構成されてもよい。
Ｇｘ初期化ＰＤＰコンテキスト修正（即ち、ＧＧＳＮがＰＣＥＦとして動作する場合）；
既存のベアラにおけるトラフィックハンドリングプライオリティの変更（ＴＨＰ）；
既存のベアラにおける最大ビットレート（ＭＢＲ）の変更；
ＩＰフロー帯域幅管理；又は
動的ＰＣＣルールでの専用ＩＰ−ＣＡＮベアラのネットワーク初期化（即ち、ＧＧＳＮがＰＣＥＦとして動作する場合）。
【００３８】
例えば、より良いＱｏＳは、特定のサービスによって必要とされる帯域幅を保証するために、ネットワークオペレータのポータルページ、リングトーン、ミュージッククリップ若しくビデオクリップ、又は、コンテンツのサードパーティなどの、所定のプレミアムサービスに対して提供されうる。一方で、より悪いＱｏＳは、利用可能な場合にのみフルの帯域幅要件を受信するようなサービス、ピアツーピアファイル交換、スポンサーなしのダウンロードなどの所定の低い価値のサービスに対して提供されうる。
【００３９】
ＰＣＲＦにサービス開始コンディションが通知される場合、任意の他の動作をトリガとする可能性もあることを記載しておく。
【００４０】
その後、図３の７６に示すように、サービスフローが起動する。図３の７８によって例示され、かつ、上述したように、これは、ＵＥ１６とＰＣＥＦ２０との間の第２のＰＤＰコンテキスト８０を確立するために、適切なＰＤＰコンテキストシグナリングを必要としてもよい。他の場合において、当該サービスは、既存のＰＤＰコンテキスト上で実行されてもよく、第２のＰＤＰコンテキストを生成するためには必要とされない。
【００４１】
検出されたサービスが実行されている間、ＰＣＥＦは、非活動タイマが満了したかどうかを判定するために（即ち、タイマによって設定された所定の時間の間、当該サービスが無効化されているかどうかを判定するために）、図２に示す処理のステップ８２を実行する。そうでなければ、処理はステップ８４に進み、サービス停止コンディションが検出されたかどうかが判定される。検出されてなければ処理を８２に戻す。ＰＣＥＦは、適切な技術によってサービスの停止を、例えば、ＤＰＩの使用によって可能となる発見的手法を用いて、検出することができる。
【００４２】
ステップ８２において非活動タイマが満了したと判定されると、又は、ステップ８４においてサービス停止コンディションが検出されたと判定されると、処理はステップ８６に進み、ＰＣＥＦ２０が、新たに定義されるサービスイベントを示す値に設定されたイベントトリガＡＶＰによってＧｘインタフェース上でのクレジット制御要求（ＣＣＲ）コマンドを用いて、ＰＣＲＦ２８へサービス停止コンディションを通知する。
【００４３】
本発明の図示した実施形態において、新たに定義されるサービス情報ＡＶＰはＰＣＲＦが当該通知を扱うことを許容するために追加情報を伝送するために使用される。
【００４４】
サービス開始停止ＡＶＰは、ここでは、サービス停止イベントを示すように設定される。フレイムドＩＰアドレス（ＡＶＰ）は、ＲＦＣ４００５で特定されるように符号化されたＩＰアドレスに関連付けられたＩＰ−ＣＡＮを含む。アプリケーション識別子ＡＶＰなどの他のＡＶＰは、検出された特定のサービス（例えば、リアルタイムストリーミングプロトコル（ＲＴＳＰ））を識別する情報を含む。
【００４５】
ステップ８８において、ＰＣＲＦは、ＰＣＥＦからの通知を受信し、通知が成功したことを示す結果コードとともにクレジット制御応答（ＣＣＡ）メッセージを送信することによって当該通知を信号制御する。
【００４６】
ステップ９０において、ＰＣＲＦは、ＰＣＥＦへＧｘ再認証要求（ＲＡＲ）メッセージを送信することによって、前もってインストールされたＰＣＣルールを削除する。これは、既存のベアラの修正（即ち、当該サービスに対して生成された専用のベアラの削除）によってオリジナルのＱｏＳ設定の回復を許容する。ステップ９２において、ＰＣＥＦは、通知が成功したことを示す結果コードとともに再認証応答をＰＣＲＦへ送信することによって、当該コマンドを承認する。
【００４７】
図４に示すように、第２のＰＤＰコンテキストがＵＥ１６とＰＣＥＦ２０との間で確立された場合には、適切なＰＤＰコンテキストシグナリング９４がステップ９６で第２のＰＤＰコンテキストを解体するために使用される。
【００４８】
本発明は、ＰＣＥＦが特定のサービスにおけるサービス開始又はサービス停止の形式で所定のサービスコンディションに反応する場合の状況を参照しながら説明した。サービスの更新のイベントにおいても同様の手続きが実行されうる。
【００４９】
例えば、ユーザが実行ストリーミングサービスを停止する場合、又は、既存のＩＭＳ音声呼へビデオコンポーネントを追加するなど、新たなフローが既存のサービスに追加される場合、例えばＤＰＩの使用によって可能となる発見的手法を用いて、任意の適切な技術によるＰＣＥＦによって検出されうる。
【００５０】
ここでのサービス開始停止ＡＶＰは、サービス更新イベントを示すように設定され、ＰＣＲＦへの通知はサービスセッションにおけるＱｏＳパラメータの修正のトリガとすることができる。
【００５１】
これまで述べたように、本方法は、Ｇｘインタフェース上での送信に関するものである。しかしながら、Ｇｘに関連の無いローカルソリューションが適用されてもよい。この場合、ＰＣＥＦは、当該機能がトリガとされ、かつ、それらのサービスのそれぞれに対して適用するローカルポリシーで提供されるべきである、サービスセット（例えば、上述したＲＴＳＰなど）として提供されるべきである。ＰＣＥＦは、上述したように、サービス開始コンディションを検出するように構成され、検出すると、ＰＣＥＦは非活動タイマを開始する。当該サービスに対して提供されるローカルポリシーに基づき、ＰＣＥＦは、開始されるサービスに依存して、より高い又はより低いＱｏＳ設定の何れかでの、既存のベアラの修正又は専用のベアラの生成をトリガとしてもよい。ＰＣＥＦがサービス停止コンディションを検出するか、又は、非活動タイマが満了すると、ＰＣＥＦ（当該サービスに対して提供されるローカルポリシーに基づく）は、既存のベアラを修正することによって、又は、上記サービスに対して前に生成された専用のベアラを削除することによって、前回のＱｏＳ設定を回復すべきである。
【００５２】
これらは、サービストラフィック検出を実行することができるＰＣＥＦが特定のイベントを用いて、イベントトリガＡＶＰのサービスコンディションをＰＣＲＦへ通知することを許容するＧｘインタフェースへの強化を提供する。これは、特定のユーザセッションに対するＱｏＳパラメータを修正するために、ＰＣＲＦが対応するＰＣＣルールをインストールすることを許容する。
【技術分野】
【０００１】
本発明は、サービスイベントトリガに関し、より詳細には、セッション中の課金に基づくユーザセッションにおけるサービス品質パラメータの修正を許容するためのサービスイベントトリガに関するものである。
【背景技術】
【０００２】
モバイル通信ネットワークのコアネットワークでは、２人のユーザ間でデータを送信するために資源が提供されなければならない。提供された資源は、複数のユーザによって経験されるサービス品質を決定する。ＥＴＳＩ第３世代パートナーシッププロジェクト（３ＧＰＰ）によって定義されるネットワークにおいて、ポリシー及び課金ルール機能（ＰＣＲＦ）、ポリシー及び課金実施機能（ＰＣＥＦ）、及び、ＰＣＲＦとＰＣＥＦの間に横たわるＧｘ参照ポイントが定義される。３ＧＰＰ ＴＳ２９．２１２で定義されるように、Ｇｘ参照ポイントは、ＰＣＲＦからＰＣＥＦへのポリシー及び課金制御（ＰＣＣ）ルールの提供及び削除、ＰＣＥＦからＰＣＲＦへのトラフィックプレーンイベントの送信のために使用される。このように、Ｇｘ参照ポイントは、課金制御、ポリシー制御、又は、その両方のために使用されうる。
【０００３】
３ＧＰＰにおいて定義されるネットワークに場合において、ＰＣＥＦは、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）に実装されてもよく、ディープパケットインスペクション（ＤＰＩ）技術をサポートできるＧＧＳＮにおいて知られている。ＤＰＩ技術は、ノードがパケットインスペクションと、当該ノードを通過するデータ上でのサービス区分とを実行することを許容する。より詳細には、ＩＰパケットが、当該ＩＰパケットが特定のサービスセッションへ割り当てられるように、ルールの構造ツリーに従って区分される。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、既知のＧＧＳＮにおけるＤＰＩ技術の使用は、サービス区分に基づく任意のサービスの差別化を許容していない。
【課題を解決するための手段】
【０００５】
本発明の第１の形態によれば、通信ネットワークにおけるポリシー及び課金実施機能ノードが提供され、セッション中にサービストラフィック検出を実行するサービストラフィック検出器と、前記サービストラフィック検出から所定のサービスコンディションを検出するプロセッサと、Ｇｘ参照ポイント上でのイベントトリガＡＶＰで定義されるサービスイベントを用いて、前記検出されたサービスコンディションを、ポリシー及び課金ルール機能へ通知するインタフェースとを備えることを特徴とする。
【０００６】
これは、ポリシー及び課金ルール機能が適切なポリシー及び課金制御ルールをインストールできる、例えば、所望のサービス品質が検出されたサービスコンディションに対して達成されるという、利益を有する。
【０００７】
一実施形態において、インタフェースは、さらに、前記Ｇｘ参照ポイント上でのサービス開始停止ＡＶＰを用いて、検出されたサービスコンディションがサービス開始であるか又はサービス停止であるかをポリシー及び課金ルール機能へ通知するようにさらに適合される。これは、ポリシー及び課金ルール機能が、サービスが開始されると適切なポリシー及び課金制御ルールをインストールし、サービスが停止するとオリジナルのポリシー及び課金制御ルールを再インストールすることを許容する。
【０００８】
一実施形態において、インタフェースは、さらに、ＩＰアドレスＡＶＰを用いて、前記セッションにおける関連付けられたＩＰアドレスと、前記Ｇｘ参照ポイント上でのメディアコンポーネントディスクリプションを用いて、フロー情報とを、前記ポリシー及び課金ルール機能へ通知するように適合される。
【０００９】
一実施形態において、インタフェースは、さらに、前記Ｇｘ参照ポイント上でのアプリケーション識別子ＡＶＰを用いて、前記検出されたサービスコンディションが適用されるサービスを、前記ポリシー及び課金ルール機能へ通知するように適合される。
【００１０】
本発明の他の形態によれば、ポリシー及び課金実施機能からの通知を受信するポリシー及び課金ルール機能ノードを提供する。また、第１の形態におけるポリシー及び課金実施機能に対応する動作の方法について提供する。
【図面の簡単な説明】
【００１１】
【図１】本発明の一形態に従った通信の一部を示すブロック図である。
【図２】本発明の一形態に従った方法を示すフローチャートである。
【図３】図２の方法における第１部分中におけるメッセージフローを示す図である。
【図４】図２の方法における第２部分中におけるメッセージフローを示す図である。
【発明を実施するための形態】
【００１２】
図１は、通信ネットワークを示し、特に、３ＧＰＰの仕様書に定義されているように、モバイル通信ネットワークのコアネットワーク１０の一部を示す。
【００１３】
コアネットワーク１０の１つの要素は、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１２である。従来のように、モバイル通信ネットワークの無線アクセスネットワーク（ＲＡＮ）１４はＧＧＳＮ１２へ接続される。ＧＧＳＮ１２は、ユーザ装置（ＵＥ）１６が適切な無線インタフェースを介して呼を確立することを許容する。上記呼は、ＲＡＮを通じて上記ネットワークの他のＵＥに経路づけられるか、又は、インターネットなどのパケットデータネットワーク１８を介して固定回線若しくはモバイル通信デバイスへ、データセッションの場合はリモートサーバへ接続されうる。当該ネットワークのこの形態は、従来のものであり、さらなる詳細な説明は割愛する。
【００１４】
従来と同様に、ＧＧＳＮ１２は、ポリシー及び課金実施機能（ＰＣＥＦ）を含む。この場合、ＧＧＳＮに含まれるＰＣＥＦは、ディープパケットインスペクション（ＤＰＩ）を実行するサービストラフィック検出ブロック２２を有する。これは、それらが特定のサービスセッションへ割り当てられるようにルールの構造ツリーに従ったＩＰパケットの分類から成る、パケットインスペクション及びサービス区分を許容する。ＤＰＩ機能を有するノードは、ユーザと、シグナリングトラフィックと、を捕捉し、ＩＰパケットを特定のサービスセッションへ割り当て、サービス開始コンディション及びサービス停止コンディションを検出することができる。
【００１５】
ＰＣＥＦはまた、以下で詳細に説明する処理の一部を実行するプロセッサ２４と、コアネットワーク１０の他のブロックへ接続するためのインタフェースブロック２６とを備える。
【００１６】
図１はサービストラフィックブロック２２、プロセッサ２４、及びインタフェースブロック２６が理解を容易にするために個別のブロックとして示されているが、関係のある機能が任意の従来の手段によって実行され、それらのブロックが実際に明確に認識される必要はないことが理解されるであろう。
【００１７】
本発明の他の実施形態において、ＰＣＥＦは、パケットデータネットワーク（ＰＤＮ）ゲートウェイに実装されるてもよい。
【００１８】
従来と同じように、コアネットワーク１０はまた、ポリシー及び課金ルール機能（ＰＣＲＦ）２８を備え、その構造は、従来と同様であり、以下で詳細に説明する処理の一部を実行するプロセッサ３０と、コアネットワーク１０の他のブロックへ接続するためのインタフェースブロック３２とを備える。例えば、ＰＣＲＦ２８は、エリクソンサービスアウェアポリシー制御部（ＳＡＰＣ）に実装されてもよい。
【００１９】
図１は説明を容易にするために個別のブロックとしてプロセッサ３０及びインタフェースブロック３２を示しているが、関連のある機能が従来の任意の手段によって実行されてもよく、それらのブロックが実際に明確に認識される必要はないことが理解されるであろう。
【００２０】
ＰＣＥＦ２０はまた、オフライン課金システム（ＯＦＣＳ）３４と、モバイルネットワーク拡張ロジック（ＣＡＭＥＬ）サービス制御ポイント３８及びクレジット制御ブロック４０に基づくサービスデータフローのためのカスタマイズされたアプリケーションを含むオンライン課金システム３６へ接続される。
【００２１】
ＰＣＲＦ２８は、加入者プロファイルリポジトリ（ＳＰＲ）４２と、アプリケーション機能（ＡＦ）４４とに接続される。例えば、ＡＦ４４は、ＩＰマルチメディアサブシステム（ＩＭＳ）プロキシ呼セッション制御機能（Ｐ−ＣＳＣＦ）であってもよい。
【００２２】
ＰＣＥＦ２０及びＰＣＲＦ２８は、３ＧＰＰ ＴＳ２９．２１２で定義されるように、Ｇｘ参照ポイント上で通信を行う。Ｇｘ参照ポイントは、ＰＣＲＦからＰＣＥＦへのＰＣＣルールの提供及び削除と、ＰＣＥＦからＰＣＲＦへのトラフィックプレーンイベントの送信に使用される。Ｇｘ参照ポイントは課金制御、ポリシー制御、又はその両方に使用されうる。
【００２３】
ＰＣＲＦ２８及びＡＦ４４は、３ＧＰＰ ＴＳ ２９．２１４に定義されるように、Ｒｘ参照ポイント上で通信を行う。Ｒｘ参照ポイントは、ＰＣＲＦとＡＦとの間でアプリケーションレベルセッション情報を交換するために使用される。
【００２４】
ＰＣＥＦ２０とＯＣＳ３６がＧｙ参照ポイント上で通信を行い、ＰＣＲＦ２８とＳＰＲ４２とがＳｐ参照ポイント上で通信を行う間、ＰＣＥＦ２０及びＯＦＣＳ３４は、Ｇｚ参照ポイント上で通信を行う。
【００２５】
上述した一般的な構成が３ＧＰＰ ＴＳ２９．２１２において示されるため、さらなる詳細な説明は割愛する。
【００２６】
本発明に係る方法についてさらに詳細に図２のフローチャートと、図３及び図４に示す様々なノード間のメッセージフローを参照して説明する。特に、図２は、ＰＣＥＦ２０及びＰＣＲＦ２８で実行されるステップを示し、一方で、図３及び図４は、ＵＥ１６、ＰＣＥＦ２０、ＰＣＲＦ２８、及びＵＥ１６に接続される他のＵＥ又はサーバの間で送信されるメッセージを示す。
【００２７】
処理は、ＵＥ１６が遠隔ＵＥ／サーバと確立される一般用途のパケットデータプロトコル（ＰＤＰ）コンテキストを用意すると開始される。ステップ６０において、ＰＣＥＦは、データトラフィック上で、ディープパケットインスペクション（ＤＰＩ）、又は他の形式のサービストラフィック検出を実行する。
【００２８】
処理を開始する前に、ＰＣＥＦは、イベントがＰＣＲＦへ通知されるためのサービスセットとともに提供される。例えば、システムは、所定のサービスがプレミアムコンテンツとして特定され、一方で他のサービスが非プレミアムコンテンツとして特定されるような方法で構成されてもよい。より詳細な例として、タイムクリティカルな音楽、ビデオクリップ、及びオペレータ自身のポータルがプレミアムコンテンツとして特定され、一方でピアツーピアファイル交換などのサービスが非プレミアムコンテンツとして見なされるかもしれない。ＰＣＥＦは、それらのサービスいずれかを認識するように構成されるかもしれない。ＰＣＲＦは、同じサービスセットと、それらのサービスのそれぞれへ適用されるであろうポリシーとともに提供されべきである。
【００２９】
従って、ステップ６２において、ＰＣＥＦは提供されるサービスの１つの開始を検出するまで、図３のポイント６４に示すように、トラフィックを監視する。ＰＣＥＦは、任意の適切な技術によるサービスの開始を、例えば、ＤＰＩの使用によって可能となる発見的手法を用いて、検出することができる。
【００３０】
ＰＣＥＦがサービス開始コンディションを検出すると、ステップ６６において、非活動タイマを開始する。その後、ステップ６８において、ＰＣＥＦ２０は、新たに定義されるサービスイベントを示す値に設定されたイベントトリガＡＶＰによってＧｘインタフェース上でのクレジット制御要求（ＣＣＲ）コマンドを用いて、ＰＣＲＦ２８へサービス開始コンディションを通知する。
【００３１】
本発明の図示した実施形態において、新たに定義されるサービス情報ＡＶＰはＰＣＲＦが当該通知を扱うことを許容するために追加情報を伝送するために使用される。
【００３２】
サービス開始停止ＡＶＰはイベントがサービス開始又はサービス停止のいずれに対応するかどうかを示す（ここでは、サービス開始イベントを示すように設定される）。
【００３３】
フレイムドＩＰアドレス（ＡＶＰ）は、ＲＦＣ４００５で特定されるように符号化されたＩＰアドレスに関連付けられたＩＰ−ＣＡＮを含む。メディアコンポーネントディスクリプションＡＶＰなどの他のＡＶＰは、関連のあるフロー情報を含む。例えば、ＲＴＳＰシグナリングは、シグナリング中にネゴシエートされた、リアルタイムトランスポートプロトコル（ＲＴＰ）のオーディオ又はビデオデータフローに対応するＩＰアドレス及びポートについての情報を伝送する。これにより、ＰＣＲＦがそれらのネゴシエートされたＩＰアドレス及びポート下で第２のＰＤＰコンテキストを作成することができる。
【００３４】
アプリケーション識別子ＡＶＰは、検出された特定のサービス（例えば、リアルタイムストリーミングプロトコル（ＲＴＳＰ））を識別する情報を含む。当該情報は、異なるアプリケーションサービスにおける差別化されたＱｏＳを提供するためにＰＣＲＦによって使用されてもよい。
【００３５】
ステップ７０において、ＰＣＲＦは、ＰＣＥＦからの通知を受信し、通知が成功であったことを示す結果コードとともに、クレジット制御応答（ＣＣＡ）を送信することによって当該通知を信号制御する。
【００３６】
ステップ７２において、ＰＣＲＦは、Ｇｘ再認証要求（ＲＡＲ）メッセージをＰＣＥＦへ送信することによって対応ＰＣＣルールをインストールする。これは、より高い又はより低いＱｏＳ設定で、開始されているサービスに依存して、既存のベアラの修正（又は専用のベアラの作成）を許容する。ステップ７４において、ＰＣＥＦは、通知が成功であったことを示す結果コードとともに再認証応答をＰＣＲＦへ送信することによって、当該コマンドを承認する。
【００３７】
上記通知に応じて、ＰＣＲＦは、検出されたサービスコンディションに応じてサービス提供を制御するための任意の適切なステップを取ってもよい。これは、サービスセッションにおけるＱｏＳ設定の修正に影響を与えることができ、順に、以下の非完全なリストから以下のアクションの何れかから構成されてもよい。
Ｇｘ初期化ＰＤＰコンテキスト修正（即ち、ＧＧＳＮがＰＣＥＦとして動作する場合）；
既存のベアラにおけるトラフィックハンドリングプライオリティの変更（ＴＨＰ）；
既存のベアラにおける最大ビットレート（ＭＢＲ）の変更；
ＩＰフロー帯域幅管理；又は
動的ＰＣＣルールでの専用ＩＰ−ＣＡＮベアラのネットワーク初期化（即ち、ＧＧＳＮがＰＣＥＦとして動作する場合）。
【００３８】
例えば、より良いＱｏＳは、特定のサービスによって必要とされる帯域幅を保証するために、ネットワークオペレータのポータルページ、リングトーン、ミュージッククリップ若しくビデオクリップ、又は、コンテンツのサードパーティなどの、所定のプレミアムサービスに対して提供されうる。一方で、より悪いＱｏＳは、利用可能な場合にのみフルの帯域幅要件を受信するようなサービス、ピアツーピアファイル交換、スポンサーなしのダウンロードなどの所定の低い価値のサービスに対して提供されうる。
【００３９】
ＰＣＲＦにサービス開始コンディションが通知される場合、任意の他の動作をトリガとする可能性もあることを記載しておく。
【００４０】
その後、図３の７６に示すように、サービスフローが起動する。図３の７８によって例示され、かつ、上述したように、これは、ＵＥ１６とＰＣＥＦ２０との間の第２のＰＤＰコンテキスト８０を確立するために、適切なＰＤＰコンテキストシグナリングを必要としてもよい。他の場合において、当該サービスは、既存のＰＤＰコンテキスト上で実行されてもよく、第２のＰＤＰコンテキストを生成するためには必要とされない。
【００４１】
検出されたサービスが実行されている間、ＰＣＥＦは、非活動タイマが満了したかどうかを判定するために（即ち、タイマによって設定された所定の時間の間、当該サービスが無効化されているかどうかを判定するために）、図２に示す処理のステップ８２を実行する。そうでなければ、処理はステップ８４に進み、サービス停止コンディションが検出されたかどうかが判定される。検出されてなければ処理を８２に戻す。ＰＣＥＦは、適切な技術によってサービスの停止を、例えば、ＤＰＩの使用によって可能となる発見的手法を用いて、検出することができる。
【００４２】
ステップ８２において非活動タイマが満了したと判定されると、又は、ステップ８４においてサービス停止コンディションが検出されたと判定されると、処理はステップ８６に進み、ＰＣＥＦ２０が、新たに定義されるサービスイベントを示す値に設定されたイベントトリガＡＶＰによってＧｘインタフェース上でのクレジット制御要求（ＣＣＲ）コマンドを用いて、ＰＣＲＦ２８へサービス停止コンディションを通知する。
【００４３】
本発明の図示した実施形態において、新たに定義されるサービス情報ＡＶＰはＰＣＲＦが当該通知を扱うことを許容するために追加情報を伝送するために使用される。
【００４４】
サービス開始停止ＡＶＰは、ここでは、サービス停止イベントを示すように設定される。フレイムドＩＰアドレス（ＡＶＰ）は、ＲＦＣ４００５で特定されるように符号化されたＩＰアドレスに関連付けられたＩＰ−ＣＡＮを含む。アプリケーション識別子ＡＶＰなどの他のＡＶＰは、検出された特定のサービス（例えば、リアルタイムストリーミングプロトコル（ＲＴＳＰ））を識別する情報を含む。
【００４５】
ステップ８８において、ＰＣＲＦは、ＰＣＥＦからの通知を受信し、通知が成功したことを示す結果コードとともにクレジット制御応答（ＣＣＡ）メッセージを送信することによって当該通知を信号制御する。
【００４６】
ステップ９０において、ＰＣＲＦは、ＰＣＥＦへＧｘ再認証要求（ＲＡＲ）メッセージを送信することによって、前もってインストールされたＰＣＣルールを削除する。これは、既存のベアラの修正（即ち、当該サービスに対して生成された専用のベアラの削除）によってオリジナルのＱｏＳ設定の回復を許容する。ステップ９２において、ＰＣＥＦは、通知が成功したことを示す結果コードとともに再認証応答をＰＣＲＦへ送信することによって、当該コマンドを承認する。
【００４７】
図４に示すように、第２のＰＤＰコンテキストがＵＥ１６とＰＣＥＦ２０との間で確立された場合には、適切なＰＤＰコンテキストシグナリング９４がステップ９６で第２のＰＤＰコンテキストを解体するために使用される。
【００４８】
本発明は、ＰＣＥＦが特定のサービスにおけるサービス開始又はサービス停止の形式で所定のサービスコンディションに反応する場合の状況を参照しながら説明した。サービスの更新のイベントにおいても同様の手続きが実行されうる。
【００４９】
例えば、ユーザが実行ストリーミングサービスを停止する場合、又は、既存のＩＭＳ音声呼へビデオコンポーネントを追加するなど、新たなフローが既存のサービスに追加される場合、例えばＤＰＩの使用によって可能となる発見的手法を用いて、任意の適切な技術によるＰＣＥＦによって検出されうる。
【００５０】
ここでのサービス開始停止ＡＶＰは、サービス更新イベントを示すように設定され、ＰＣＲＦへの通知はサービスセッションにおけるＱｏＳパラメータの修正のトリガとすることができる。
【００５１】
これまで述べたように、本方法は、Ｇｘインタフェース上での送信に関するものである。しかしながら、Ｇｘに関連の無いローカルソリューションが適用されてもよい。この場合、ＰＣＥＦは、当該機能がトリガとされ、かつ、それらのサービスのそれぞれに対して適用するローカルポリシーで提供されるべきである、サービスセット（例えば、上述したＲＴＳＰなど）として提供されるべきである。ＰＣＥＦは、上述したように、サービス開始コンディションを検出するように構成され、検出すると、ＰＣＥＦは非活動タイマを開始する。当該サービスに対して提供されるローカルポリシーに基づき、ＰＣＥＦは、開始されるサービスに依存して、より高い又はより低いＱｏＳ設定の何れかでの、既存のベアラの修正又は専用のベアラの生成をトリガとしてもよい。ＰＣＥＦがサービス停止コンディションを検出するか、又は、非活動タイマが満了すると、ＰＣＥＦ（当該サービスに対して提供されるローカルポリシーに基づく）は、既存のベアラを修正することによって、又は、上記サービスに対して前に生成された専用のベアラを削除することによって、前回のＱｏＳ設定を回復すべきである。
【００５２】
これらは、サービストラフィック検出を実行することができるＰＣＥＦが特定のイベントを用いて、イベントトリガＡＶＰのサービスコンディションをＰＣＲＦへ通知することを許容するＧｘインタフェースへの強化を提供する。これは、特定のユーザセッションに対するＱｏＳパラメータを修正するために、ＰＣＲＦが対応するＰＣＣルールをインストールすることを許容する。
【特許請求の範囲】
【請求項１】
通信ネットワークにおけるポリシー及び課金実施機能ノードであって、
セッション中にサービストラフィック検出を実行するサービストラフィック検出器と、
前記サービストラフィック検出から所定のサービスコンディションを検出するプロセッサと、
Ｇｘ参照ポイント上でのイベントトリガＡＶＰで定義されるサービスイベントを用いて、前記検出されたサービスコンディションを、ポリシー及び課金ルール機能へ通知するインタフェースと
を備えることを特徴とするポリシー及び課金実施機能ノード。
【請求項２】
前記インタフェースは、さらにポリシー及び課金ルール機能に通知するように適合され、
前記Ｇｘ参照ポイント上でのサービス開始停止ＡＶＰを用いて、前記検出されたサービスコンディションがサービス開始であるか又はサービス停止であるかを通知することを特徴とする請求項１に記載のポリシー及び課金実施機能ノード。
【請求項３】
前記インタフェースは、ＩＰアドレスＡＶＰを用いて、前記セッションにおける関連付けられたＩＰアドレスと、前記Ｇｘ参照ポイント上でのメディアコンポーネントディスクリプションＡＶＰを用いて、フロー情報とを、前記ポリシー及び課金ルール機能へ通知するように適合されることを特徴とする請求項１に記載のポリシー及び課金実施機能ノード。
【請求項４】
前記インタフェースは、さらに、前記Ｇｘ参照ポイント上でのアプリケーション識別子ＡＶＰを用いて、前記検出されたサービスコンディションが適用されるサービスを、前記ポリシー及び課金ルール機能へ通知するように適合されることを特徴とする請求項１に記載のポリシー及び課金実施機能ノード。
【請求項５】
通信ネットワークにおけるポリシー及び課金実施機能ノードにおいてサービスの提供を制御するための方法であって、
セッション中にサービストラフィック検出を実行するステップと、
前記サービストラフィック検出から所定のサービスコンディションを検出するステップと、
Ｇｘ参照ポイント上でのイベントトリガＡＶＰで定義されるサービスイベントを用いて、前記検出されたサービスコンディションを、ポリシー及び課金ルール機能へ通知するステップと
を含むことを特徴とする方法。
【請求項６】
前記Ｇｘ参照ポイント上でのサービス開始停止ＡＶＰを用いて、前記検出されたサービスコンディションがサービス開始であるか又はサービス停止であるかを、前記ポリシー及び課金ルール機能へ通知するステップをさらに含むことを特徴とする請求項５に記載の方法。
【請求項７】
ＩＰアドレスＡＶＰを用いて、前記セッションにおける関連付けられたＩＰアドレスと、前記Ｇｘ参照ポイント上でのメディアコンポーネントディスクリプションＡＶＰを用いて、フロー情報とを、前記ポリシー及び課金ルール機能へ通知するステップをさらに含むことを特徴とする請求項５に記載の方法。
【請求項８】
前記Ｇｘ参照ポイント上でのアプリケーション識別子ＡＶＰを用いて、前記検出されたサービスコンディションが適用されるサービスを、前記ポリシー及び課金ルール機能へ通知するステップをさらに含むことを特徴とする請求項５に記載の方法。
【請求項９】
通信ネットワークにおけるポリシー及び課金ルール機能ノードであって、
ポリシー及び課金実施機能からの、Ｇｘ参照ポイント上でのイベントトリガＡＶＰで定義されるサービスイベントを用いて、検出された所定のサービスコンディションの通知を受信するインタフェースと、
前記検出されたサービスコンディションに応じてサービス提供を制御する制御部と
を備えることを特徴とするポリシー及び課金ルール機能ノード。
【請求項１０】
前記インタフェースは、さらに、前記Ｇｘ参照ポイントでのサービス開始停止ＡＶＰを用いて、前記検出されたサービスコンディションがサービス開始であるか又はサービス停止であるかの通知を受信するように適合されることを特徴とする請求項９に記載のポリシー及び課金ルール機能ノード。
【請求項１１】
前記インタフェースは、さらに、ＩＰアドレスＡＶＰを用いた前記セッションにおける関連付けられたＩＰアドレスと、前記Ｇｘ参照ポイント上でのメディアコンポーネントディスクリプションＡＶＰを用いたフロー情報との通知を受信するように適合されることを特徴とする請求項９に記載のポリシー及び課金ルール機能ノード。
【請求項１２】
前記インタフェースは、さらに、前記Ｇｘ参照ポイント上でのアプリケーション識別子ＡＶＰを用いた、前記検出されたサービスコンディションに適用されるサービスの通知を受信するように適合されることを特徴とする請求項９に記載のポリシー及び課金ルール機能ノード。
【請求項１３】
通信ネットワークにおけるノードのサービス提供を制御する方法であって、
ポリシー及び課金実施機能において、
セッション中にサービストラフィック検出を実行するステップと、
前記サービストラフィック検出から所定のサービスコンディションを検出するステップと、
Ｇｘ参照ポイント上でのイベントトリガＡＶＰで定義されるサービスイベントを用いて、前記検出されたサービスコンディションを、ポリシー及び課金ルール機能へ通知するステップと
を実行し、
ポリシー及び課金ルール機能において、
前記検出されたサービスコンディションの通知を受信するステップと、
前記検出されたサービスコンディションに応じてサービス提供を制御するステップと
を実行することを特徴とする方法。
【請求項１４】
前記ポリシー及び課金実施機能において、
前記Ｇｘ参照ポイント上でのサービス開始停止ＡＶＰを用いて、前記検出されたサービスコンディションがサービス開始であるか又はサービス停止であるかを、前記ポリシー及び課金ルール機能へ通知するステップをさらに実行することを特徴とする請求項１３に記載の方法。
【請求項１５】
前記ポリシー及び課金実施機能において、
ＩＰアドレスＡＶＰを用いて、前記セッションにおける関連付けられたＩＰアドレスと、前記Ｇｘ参照ポイント上でのメディアコンポーネントディスクリプションＡＶＰを用いてフロー情報とを、前記ポリシー及び課金ルール機能へ通知するステップをさらに実行することを特徴とする請求項１３に記載の方法。
【請求項１６】
前記ポリシー及び課金実施機能において、
前記Ｇｘ参照ポイント上でのアプリケーション識別子ＡＶＰを用いて、前記検出されたサービスコンディションが適用されるサービスを、前記ポリシー及び課金ルール機能へ通知するステップをさらに実行することを特徴とする請求項１３に記載の方法。
【請求項１】
通信ネットワークにおけるポリシー及び課金実施機能ノードであって、
セッション中にサービストラフィック検出を実行するサービストラフィック検出器と、
前記サービストラフィック検出から所定のサービスコンディションを検出するプロセッサと、
Ｇｘ参照ポイント上でのイベントトリガＡＶＰで定義されるサービスイベントを用いて、前記検出されたサービスコンディションを、ポリシー及び課金ルール機能へ通知するインタフェースと
を備えることを特徴とするポリシー及び課金実施機能ノード。
【請求項２】
前記インタフェースは、さらにポリシー及び課金ルール機能に通知するように適合され、
前記Ｇｘ参照ポイント上でのサービス開始停止ＡＶＰを用いて、前記検出されたサービスコンディションがサービス開始であるか又はサービス停止であるかを通知することを特徴とする請求項１に記載のポリシー及び課金実施機能ノード。
【請求項３】
前記インタフェースは、ＩＰアドレスＡＶＰを用いて、前記セッションにおける関連付けられたＩＰアドレスと、前記Ｇｘ参照ポイント上でのメディアコンポーネントディスクリプションＡＶＰを用いて、フロー情報とを、前記ポリシー及び課金ルール機能へ通知するように適合されることを特徴とする請求項１に記載のポリシー及び課金実施機能ノード。
【請求項４】
前記インタフェースは、さらに、前記Ｇｘ参照ポイント上でのアプリケーション識別子ＡＶＰを用いて、前記検出されたサービスコンディションが適用されるサービスを、前記ポリシー及び課金ルール機能へ通知するように適合されることを特徴とする請求項１に記載のポリシー及び課金実施機能ノード。
【請求項５】
通信ネットワークにおけるポリシー及び課金実施機能ノードにおいてサービスの提供を制御するための方法であって、
セッション中にサービストラフィック検出を実行するステップと、
前記サービストラフィック検出から所定のサービスコンディションを検出するステップと、
Ｇｘ参照ポイント上でのイベントトリガＡＶＰで定義されるサービスイベントを用いて、前記検出されたサービスコンディションを、ポリシー及び課金ルール機能へ通知するステップと
を含むことを特徴とする方法。
【請求項６】
前記Ｇｘ参照ポイント上でのサービス開始停止ＡＶＰを用いて、前記検出されたサービスコンディションがサービス開始であるか又はサービス停止であるかを、前記ポリシー及び課金ルール機能へ通知するステップをさらに含むことを特徴とする請求項５に記載の方法。
【請求項７】
ＩＰアドレスＡＶＰを用いて、前記セッションにおける関連付けられたＩＰアドレスと、前記Ｇｘ参照ポイント上でのメディアコンポーネントディスクリプションＡＶＰを用いて、フロー情報とを、前記ポリシー及び課金ルール機能へ通知するステップをさらに含むことを特徴とする請求項５に記載の方法。
【請求項８】
前記Ｇｘ参照ポイント上でのアプリケーション識別子ＡＶＰを用いて、前記検出されたサービスコンディションが適用されるサービスを、前記ポリシー及び課金ルール機能へ通知するステップをさらに含むことを特徴とする請求項５に記載の方法。
【請求項９】
通信ネットワークにおけるポリシー及び課金ルール機能ノードであって、
ポリシー及び課金実施機能からの、Ｇｘ参照ポイント上でのイベントトリガＡＶＰで定義されるサービスイベントを用いて、検出された所定のサービスコンディションの通知を受信するインタフェースと、
前記検出されたサービスコンディションに応じてサービス提供を制御する制御部と
を備えることを特徴とするポリシー及び課金ルール機能ノード。
【請求項１０】
前記インタフェースは、さらに、前記Ｇｘ参照ポイントでのサービス開始停止ＡＶＰを用いて、前記検出されたサービスコンディションがサービス開始であるか又はサービス停止であるかの通知を受信するように適合されることを特徴とする請求項９に記載のポリシー及び課金ルール機能ノード。
【請求項１１】
前記インタフェースは、さらに、ＩＰアドレスＡＶＰを用いた前記セッションにおける関連付けられたＩＰアドレスと、前記Ｇｘ参照ポイント上でのメディアコンポーネントディスクリプションＡＶＰを用いたフロー情報との通知を受信するように適合されることを特徴とする請求項９に記載のポリシー及び課金ルール機能ノード。
【請求項１２】
前記インタフェースは、さらに、前記Ｇｘ参照ポイント上でのアプリケーション識別子ＡＶＰを用いた、前記検出されたサービスコンディションに適用されるサービスの通知を受信するように適合されることを特徴とする請求項９に記載のポリシー及び課金ルール機能ノード。
【請求項１３】
通信ネットワークにおけるノードのサービス提供を制御する方法であって、
ポリシー及び課金実施機能において、
セッション中にサービストラフィック検出を実行するステップと、
前記サービストラフィック検出から所定のサービスコンディションを検出するステップと、
Ｇｘ参照ポイント上でのイベントトリガＡＶＰで定義されるサービスイベントを用いて、前記検出されたサービスコンディションを、ポリシー及び課金ルール機能へ通知するステップと
を実行し、
ポリシー及び課金ルール機能において、
前記検出されたサービスコンディションの通知を受信するステップと、
前記検出されたサービスコンディションに応じてサービス提供を制御するステップと
を実行することを特徴とする方法。
【請求項１４】
前記ポリシー及び課金実施機能において、
前記Ｇｘ参照ポイント上でのサービス開始停止ＡＶＰを用いて、前記検出されたサービスコンディションがサービス開始であるか又はサービス停止であるかを、前記ポリシー及び課金ルール機能へ通知するステップをさらに実行することを特徴とする請求項１３に記載の方法。
【請求項１５】
前記ポリシー及び課金実施機能において、
ＩＰアドレスＡＶＰを用いて、前記セッションにおける関連付けられたＩＰアドレスと、前記Ｇｘ参照ポイント上でのメディアコンポーネントディスクリプションＡＶＰを用いてフロー情報とを、前記ポリシー及び課金ルール機能へ通知するステップをさらに実行することを特徴とする請求項１３に記載の方法。
【請求項１６】
前記ポリシー及び課金実施機能において、
前記Ｇｘ参照ポイント上でのアプリケーション識別子ＡＶＰを用いて、前記検出されたサービスコンディションが適用されるサービスを、前記ポリシー及び課金ルール機能へ通知するステップをさらに実行することを特徴とする請求項１３に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公表番号】特表２０１３−５１１１７５（Ｐ２０１３−５１１１７５Ａ）
【公表日】平成２５年３月２８日（２０１３．３．２８）
【国際特許分類】
【出願番号】特願２０１２−５３８２０４（Ｐ２０１２−５３８２０４）
【出願日】平成２１年１１月１３日（２００９．１１．１３）
【国際出願番号】ＰＣＴ／ＥＰ２００９／０６５１６１
【国際公開番号】ＷＯ２０１１／０５７６７２
【国際公開日】平成２３年５月１９日（２０１１．５．１９）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
【公表日】平成２５年３月２８日（２０１３．３．２８）
【国際特許分類】
【出願日】平成２１年１１月１３日（２００９．１１．１３）
【国際出願番号】ＰＣＴ／ＥＰ２００９／０６５１６１
【国際公開番号】ＷＯ２０１１／０５７６７２
【国際公開日】平成２３年５月１９日（２０１１．５．１９）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
[ Back to top ]