JP5587436B2 - ポリシーおよび課金規則ノードの期限切れメッセージの処理 - Google Patents

Description

本明細書において開示されるさまざまな例示的な実施形態は、概して、通信ネットワークにおけるポリシーおよび課金に関する。

モバイル通信ネットワーク内でさまざまな種類のアプリケーションに対する需要が増大するにつれて、サービスプロバイダは、この増大した機能を信頼性高く提供するためにそれらのサービスプロバイダのシステムを絶えずアップグレードしなければならない。かつては単に音声通信のために設計されたシステムであったものが、テキストメッセージング、マルチメディアストリーミング、および通常のインターネットアクセスを含む無数のアプリケーションに対するアクセスを提供する汎用的なネットワークアクセスポイントへと成長した。そのようなアプリケーションをサポートするために、プロバイダは、それらのプロバイダの既存の音声ネットワークの上に新しいネットワークを構築し、明快とは言い難いソリューションをもたらした。第２世代および第３世代ネットワークに見られるように、音声サービスは、その他のサービスの通信が、インターネットプロトコル（ＩＰ）にしたがって送信され、異なるパケット交換コアに導かれるのに対し、専用の音声チャネルによって搬送され、回線交換コアに導かれなければならない。このことは、アプリケーションのプロビジョン、測定および課金、ならびに体感品質（ＱｏＥ）の保証に関する固有の問題をもたらした。

第２世代および第３世代の２コア手法を簡潔にしようとして、第３世代パートナーシッププロジェクト（３ＧＰＰ）は、「ロングタームエボリューション」（ＬＴＥ）と称する新しいネットワークスキームを勧告した。ＬＴＥネットワークにおいては、すべての通信が、ユーザ機器（ＵＥ）から進化型パケットコア（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）（ＥＰＣ）と呼ばれるオールＩＰコアにＩＰチャネルによって搬送される。そのとき、ＥＰＣは、許容可能なＱｏＥを保証し、加入者にそれらの特定のネットワーク活動についての課金をしながら、その他のネットワークへのゲートウェイアクセスを提供する。

概して、３ＧＰＰは、いくつかの技術仕様書に、ＥＰＣのコンポーネントと、それらのコンポーネントの互いのインタラクションとを記載する。具体的には、３ＧＰＰ ＴＳ２９．２１２、３ＧＰＰ ＴＳ２９．２１３、および３ＧＰＰ ＴＳ２９．２１４が、ＥＰＣのポリシーおよび課金規則機能（Ｐｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｒｕｌｅｓ Ｆｕｎｃｔｉｏｎ）（ＰＣＲＦ）、ポリシーおよび課金施行機能（Ｐｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｅｎｆｏｒｃｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）（ＰＣＥＦ）、ならびにベアラバインディングおよびイベント報告機能（Ｂｅａｒｅｒ Ｂｉｎｄｉｎｇ ａｎｄ Ｅｖｅｎｔ Ｒｅｐｏｒｔｉｎｇ Ｆｕｎｃｔｉｏｎ）（ＢＢＥＲＦ）を記載する。これらの仕様書は、これらの要素が、信頼性の高いデータサービスを提供し、加入者にそれらのデータサービスの使用について課金するためにどのようにインタラクションするかについての何らかの手引きをさらに提供する。

例えば、３ＧＰＰ ＴＳ２９．２１２、２９．２１３、および２９．２１４の仕様書は、例えば、アプリケーションノード（ＡＮ）およびＰＣＥＦなどの少なくとも２つの異なるソースからメッセージを受信するときのＰＣＲＦによるＰＣＣ規則の生成について何らかの手引きを提供する。これらの仕様書は、第１のメッセージが受信されるときにタイマーを使用することを提案しており、タイマーが、ＰＣＣ規則を生成する前に第２のメッセージの受信を期待して待つための期間をＰＣＲＦに設定させる。タイマーが切れる前にＰＣＲＦが第２のメッセージを受信するとき、ＰＣＲＦは、第１の受信されたメッセージと第２の受信されたメッセージの両方に含まれる情報を用いてＰＣＣ規則を生成する。

しかしながら、３ＧＰＰ規格は、タイマーが切れる前にＰＣＲＦが１つのメッセージだけを受信するときにＰＣＣ規則の生成をどのように処理するべきかについては記載していない。そのような機能は、ＥＰＣの動作にとって極めて重要である。そのような事態を処理する十分な手段がなければ、ＰＣＲＦは、サービス要求を完全に破棄する可能性があり、そのことは、システムの機能全体に大きな悪影響を及ぼす可能性がある。

上記の内容を考慮すると、相補的なメッセージを処理するための方法を提供することが望ましいことになる。特に、１つの期待されるメッセージが受信されない場合に相補的なメッセージを処理することができるＰＣＲＦを提供することが望ましいことになる。

ＰＣＲＦによって期限切れメッセージを処理するための方法に対する現在のニーズに鑑みて、さまざまな例示的な実施形態の簡潔な概要が示される。以下の概要においていくつかの簡略化および省略が行われる可能性があり、そのことは、さまざまな例示的な実施形態のいくつかの態様を強調し、紹介するように意図されており、本発明の範囲を限定するように意図されていない。当業者が本発明の概念を実施し、使用することを可能にするのに適した好ましい例示的な実施形態の詳細な説明が後の節に続く。

さまざまな例示的な実施形態は、第１のデバイスからの第１の要求メッセージを処理して少なくとも１つのポリシーおよび課金制御（Ｐｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｃｏｎｔｒｏｌ）（ＰＣＣ）規則を生成するためにポリシーおよび課金規則ノード（Ｐｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｒｕｌｅｓ Ｎｏｄｅ）（ＰＣＲＮ）によって実行される方法に関し、この方法は、第１の要求メッセージを受信するステップと、ＰＣＲＮが第１のＰＣＣ規則を生成する前に第２のデバイスからの第２のメッセージを受信するための期間を開始するためにタイマーを開始するステップであって、第２のメッセージが、第１のメッセージと対をなす、ステップと、タイマーが切れるときに、ＰＣＲＮによって受信された少なくとも第１の要求メッセージで受信された情報に少なくとも基づいて第１のＰＣＣ規則を生成するステップと、第１のＰＣＣ規則を少なくとも１つのゲートウェイに転送するステップとを含む。

さまざまな例示的な実施形態は、第１のデバイスからの第１の要求メッセージを処理して少なくとも１つのポリシーおよび課金制御（ＰＣＣ）規則を生成するためにポリシーおよび課金規則ノード（ＰＣＲＮ）によって実行される方法にも関連することが可能であり、この方法は、フロー情報を含む第１の要求メッセージを受信するステップと、第１の要求メッセージに関連するＰａｃｋｅｔ−Ｆｉｌｔｅｒ−Ｏｐｅｒａｔｉｏｎの状態を判定するステップと、フロー情報と対になる第１のＰＣＣ規則が存在するかどうかを判定するステップと、サービスフローに含まれる少なくとも１つのマーカー（ｍａｒｋｅｒ）を調べるステップと、フロー情報と対になる第１のＰＣＣ規則が存在しないときに、ＰＣＲＮによって受信された情報を用いて第１のＰＣＣ規則を生成するステップと、第２のデバイスからの第２のメッセージを受信するための期間を開始するタイマーを開始するステップであって、第２のメッセージが、第１のメッセージと対をなす、ステップと、第１のＰＣＣ規則を少なくとも１つのゲートウェイにプッシュするステップとを含む。

さまざまな例示的な実施形態は、少なくとも第１の要求メッセージを処理して少なくとも１つのポリシーおよび課金制御（ＰＣＣ）規則を生成するためのポリシーおよび課金規則ノード（ＰＣＲＮ）にも関連することが可能であり、このポリシーおよび課金規則ノード（ＰＣＲＮ）は、アプリケーションノードからの第１の要求メッセージを受信するＲｘインターフェースと、ゲートウェイからの第２の要求メッセージを受信するＧｘインターフェースであって、第２の要求メッセージが、第１の要求メッセージと対をなし、サービスフローと相補的なフロー情報を含む、Ｇｘインターフェースと、ＰＣＲＮが第１のメッセージおよび第２のメッセージのうちの少なくとも１つを受信するときに、ＰＣＲＮが対をなすメッセージを受信したかどうかを判定する対チェッカー（ｍａｔｅ ｃｈｅｃｋｅｒ）と、ＰＣＲＮが第１のメッセージおよび第２のメッセージのうちの少なくとも１つを受信し、対をなすメッセージをまだ受信していなかったときに、対をなすメッセージを受信するための期間を開始するためのタイマーと、期間が経過したときに第１のメッセージおよび第２のメッセージのうちの少なくとも１つを用いてＰＣＣ規則を生成するための規則プロセッサとを含む。

このようにして、さまざまな例示的な実施形態が、ネットワークから生じたアプリケーション要求に応答して、ポリシーおよび課金制御規則を動的に生成することを可能にすることは明らかであるに違いない。特に、アプリケーション要求メッセージをいくつかの要求されたサービスフローに変換することによって、ポリシーおよび課金規則ノードは、要求されたアプリケーション、加入者データ、および／または規則に基づくポリシーの決定に動的に基づく、それぞれの要求されたサービスフローを提供するための規則を生成することができる。

さまざまな例示的な実施形態をより深く理解するために、添付の図面に対する参照がなされる。

さまざまなデータサービスを提供するための例示的な加入者ネットワークを示す図である。 対をなすサービス要求を受信するＰＣＲＮに関する例示的なネットワークを示す図である。 受信されたサービス要求に応答して、新しいポリシーおよび課金制御（ＰＣＣ）規則を生成するための例示的なポリシーおよび課金規則ノード（ＰＣＲＮ）を示す図である。 アプリケーションノード（ＡＮ）からメッセージを受信するときにＰＣＣ規則を生成するための例示的な方法を示す図である。 アプリケーションノードからメッセージを受信するときにＰＣＣ規則を生成するための例示的な方法をさらに示す図である。 ポリシー課金および施行機能（ＰＣＥＦ）からメッセージを受信するときにＰＣＣ規則を生成するための例示的な方法を示す図である。 ポリシー課金および施行機能（ＰＣＥＦ）からメッセージを受信するときにＰＣＣ規則を生成するための例示的な方法をさらに示す図である。 ポリシー課金および施行機能（ＰＣＥＦ）からメッセージを受信するときにＰＣＣ規則を生成するための例示的な方法をさらに示す図である。

ここで、同様の番号が同様のコンポーネントまたはステップを指す図面を参照して、さまざまな例示的な実施形態の幅広い態様が開示される。

図１は、さまざまなデータサービスを提供するための例示的な加入者ネットワーク１００を示す。例示的な加入者ネットワーク１００は、さまざまなサービスへのアクセスを提供するための通信ネットワークまたはその他のネットワークであってもよい。例示的な加入者ネットワーク１００は、ユーザ機器１１０、基地局１２０、進化型パケットコア（ＥＰＣ）１３０、パケットデータネットワーク１４０、およびアプリケーションノード（ＡＮ）１５０を含み得る。

ユーザ機器１１０は、エンドユーザにデータサービスを提供するためにパケットデータネットワーク１４０と通信するデバイスであってもよい。そのようなデータサービスは、例えば、音声通信、テキストメッセージング、マルチメディアストリーミング、およびインターネットアクセスを含み得る。より具体的には、さまざまな例示的な実施形態において、ユーザ機器１１０は、パーソナルもしくはラップトップコンピュータ、無線電子メールデバイス、セル電話、テレビセットトップボックス、またはＥＰＣ１３０を介してその他のデバイスと通信することができる任意のその他のデバイスである。

基地局１２０は、ユーザ機器１１０とＥＰＣ１３０の間の通信を可能にするデバイスであってもよい。例えば、基地局１２０は、３ＧＰＰ規格によって定義された進化型ｎｏｄｅＢ（ｅＮｏｄｅＢ）などの無線基地局であってもよい。したがって、基地局１２０は、無線通信などの第１の媒体を介してユーザ機器１１０と通信し、イーサネット（登録商標）ケーブルなどの第２の媒体を介してＥＰＣ１３０と通信するデバイスである可能性がある。基地局１２０は、ＥＰＣ１３０と直接通信していることが可能であるか、またはいくつかの中間ノード（図示せず）を介して通信することが可能である。さまざまな実施形態において、ユーザ機器１１０にモビリティを提供するために複数の基地局（図示せず）が存在する可能性がある。さまざまな代替的な実施形態において、ユーザ機器１１０は、進化型パケットコアと直接通信することができることに留意されたい。そのような実施形態においては、基地局１２０は存在しない可能性がある。

進化型パケットコア（ＥＰＣ）１３０は、ユーザ機器１１０にパケットデータネットワーク１４０へのゲートウェイアクセスを提供するデバイスであっても、またはデバイスのネットワークであってもよい。さらに、ＥＰＣ１３０は、提供されるデータサービスの使用について加入者に課金し、特定の体感品質（ＱｏＥ）の基準が満たされることを保証することができる。このように、ＥＰＣ１３０は、少なくとも部分的に、３ＧＰＰ ＴＳ２９．２１２、２９．２１３、および２９．２１４規格に準じて実装され得る。したがって、ＥＰＣ１３０は、サービングゲートウェイ（ＳＧＷ）１３２と、パケットデータネットワークゲートウェイ（ＰＧＷ）１３４と、ポリシーおよび課金規則ノード（ＰＣＲＮ）１３６と、加入プロファイルリポジトリ（ｓｕｂｓｃｒｉｐｔｉｏｎ ｐｒｏｆｉｌｅ ｒｅｐｏｓｉｔｏｒｙ）（ＳＰＲ）１３８とを含み得る。

サービングゲートウェイ（ＳＧＷ）１３２は、ＥＰＣ１３０へのゲートウェイアクセスを提供するデバイスであってもよい。ＳＧＷ１３２は、ユーザ機器１１０によって送信されたパケットを受信するＥＰＣ１３０内の第１のデバイスである可能性がある。ＳＧＷ１３２は、そのようなパケットをＰＧＷ１３４に転送することができる。ＳＧＷ１３２は、例えば、複数の基地局（図示せず）間のユーザ機器１１０のモビリティの管理、および提供されている各フローに関する保証されたビットレートなどの特定のサービス品質（ＱｏＳ）特性の施行などのいくつかの機能を実行することができる。プロキシモバイルＩＰ（Ｐｒｏｘｙ Ｍｏｂｉｌｅ ＩＰ）（ＰＭＩＰ）規格を実装する実装形態などのさまざまな実装形態において、ＳＧＷ１３２は、ベアラバインディングおよびイベント報告機能（ＢＢＥＲＦ）を含み得る。さまざまな例示的な実施形態において、ＥＰＣ１３０は、複数のＳＧＷ（図示せず）を含むことが可能であり、各ＳＧＷは、複数の基地局（図示せず）と通信することが可能である。

パケットデータネットワークゲートウェイ（ＰＧＷ）１３４は、パケットデータネットワーク１４０へのゲートウェイアクセスを提供するデバイスであってもよい。ＰＧＷ１３４は、ユーザ機器１１０によってＳＧＷ１３２を介してパケットデータネットワーク１４０に送信されたパケットを受信するＥＰＣ１３０内の最後のデバイスである可能性がある。ＰＧＷ１３４は、各サービスデータフロー（ＳＤＦ）に関するポリシーおよび課金制御（ＰＣＣ）規則を施行するポリシーおよび課金施行機能（ＰＣＥＦ）を含み得る。したがって、ＰＧＷ１３４は、ポリシーおよび課金施行ノード（ｐｏｌｉｃｙ ａｎｄ ｃｈａｒｇｉｎｇ ｅｎｆｏｒｃｅｍｅｎｔ ｎｏｄｅ）（ＰＣＥＮ）であってもよい。ＰＧＷ１３４は、例えば、パケットフィルタリング、ディープパケットインスペクション、および加入者課金のサポートなどのいくつかの追加的な特徴を含み得る。

ポリシーおよび課金規則ノード（ＰＣＲＮ）１３６は、サービスの要求を受信し、ＰＣＣ規則を生成し、ＰＣＣ規則をＰＧＷ１３４および／またはその他のＰＣＥＮ（図示せず）に提供するデバイスであり得る。ＰＣＲＮ１３６は、Ｒｘインターフェースを介してＡＮ１５０と通信していることが可能である。ＰＣＲＮ１３６は、ＡＮ１５０、ＳＧＷ１３２、またはＰＧＷ１３４から要求を受信することが可能である。サービス要求を受信すると、ＰＣＲＮ１３６は、当該サービス要求を満たすための少なくとも１つの新しいＰＣＣ規則を生成することができる。

ＰＣＲＮ１３６は、それぞれＧｘｘおよびＧｘインターフェースを介してＳＧＷ１３２およびＰＧＷ１３４とやはり通信していることが可能である。新しいＰＣＣ規則を生成すると、またはＰＧＷ１３４によって要求されると、ＰＣＲＮ１３６は、ＰＣＣ規則をＧｘインターフェースを介してＰＧＷ１３４に提供することができる。例えば、ＰＭＩＰ規格を実装する実施形態などのさまざまな実施形態において、ＰＣＲＮ１３６は、ＱｏＳ規則も生成することが可能である。新しいＱｏＳ規則を生成すると、またはＳＧＷ１３２によって要求されると、ＰＣＲＮ１３６は、ＱｏＳ規則をＧｘｘインターフェースを介してＳＧＷ１３２に提供することができる。

加入プロファイルリポジトリ（ＳＰＲ）１３８は、加入者ネットワーク１００への加入者に関連する情報を記憶するデバイスであってもよい。したがって、ＳＰＲ１３８は、読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスクストレージ媒体、光学式ストレージ媒体、フラッシュメモリデバイス、および／または同様のストレージ媒体などの機械可読ストレージ媒体を含み得る。ＳＰＲ１３８は、ＰＣＲＮ１３６のコンポーネントであっても、またはＥＰＣ１３０内の独立したノードを構成してもよい。ＳＰＲ１３８によって記憶されるデータは、各加入者の識別子と、帯域幅の制限、課金パラメータ、および加入者の優先度などの各加入者に関する加入情報の指示とを含み得る。

パケットデータネットワーク１４０は、ユーザ機器１１０と、ＡＮ１５０などのパケットデータネットワーク１４０に接続されたその他のデバイスとの間のデータ通信を提供するための任意のネットワークであってもよい。パケットデータネットワーク１４０は、パケットデータネットワーク１４０と通信しているさまざまなユーザデバイスに、例えば、電話および／またはインターネットサービスをさらに提供することが可能である。

アプリケーションノード（ＡＮ）１５０は、アプリケーション機能（ＡＦ）を含み、ユーザ機器１１０にアプリケーションサービスを提供するデバイスであってもよい。したがって、ＡＮ１５０は、ユーザ機器１１０に、例えば、ビデオストリーミングまたは音声通信サービスを提供するサーバまたはその他のデバイスであり得る。さらに、ＡＮ１５０は、Ｒｘインターフェースを介してＥＰＣ１３０のＰＣＲＮ１３６と通信していることが可能である。ＡＮ１５０がユーザ機器１１０へのアプリケーションサービスの提供を開始すべきとき、ＡＮ１５０は、ＰＣＲＮ１３６に通知するために、Ｄｉａｍｅｔｅｒプロトコルに準じたＡＡ−Ｒｅｑｕｅｓｔ（ＡＡＲ）などの要求メッセージを生成することができる。この要求メッセージは、アプリケーションサービスを使用する加入者の識別、および要求されたサービスを提供するために確立されなければならない特定のサービスデータフローの識別などの情報を含み得る。ＡＮ１５０は、そのようなアプリケーション要求をＲｘインターフェースを介してＰＣＲＮ１３６に伝達することができる。

図２は、ＰＣＲＮがサービス要求に関する複数のメッセージを受信する例示的な通信ネットワークを示す。システム２００は、システム１００と同様であり、アプリケーションノード（ＡＮ）２０１、ポリシーおよび課金規則ノード（ＰＣＲＮ）２０２、パケットデータネットワークゲートウェイ（ＰＧＷ）２０３、ユーザ機器２０４、およびパケットデータネットワーク２０５が、ＡＮ１５０、ＰＣＲＮ１３６、ＰＧＷ１３４、ＵＥ１１０、およびパケットデータネットワーク１４０にそれぞれ対応する。

システム２００において、ＵＥ２０４は、ＡＮ２０１およびＰＧＷ２０３などの複数のデバイスを通じて複数の関連するサービス要求を送信することが可能であり、その要求は最終的にＰＣＲＮ２０２に送信される。そのとき、ＰＣＲＮ２０２は、受信されたサービス要求を取得し、受信された情報およびその他の利用可能な情報を用いてＰＣＣ規則を形成することができる。次いで、ＰＣＲＮ２０２は、ＰＣＣ規則をＰＧＷ２０３に転送することができ、ＰＧＷ２０３は、そのＰＣＣ規則をＳＧＷ１３２などのその他のゲートウェイに送信することができる。

ＵＥ２０４は、アプリケーションノード（ＡＮ）２０１によって処理され得るセッション開始プロトコル（ＳＩＰ）サービス要求を送信することができる。ＡＮ２０１は、パケットデータネットワーク２０５およびＰＧＷ２０３を通じてサービス要求を受信することができる。ＡＮ２０１は、受信されたサービス要求をメッセージ（ＭＳＧ１）にパッケージ化することができ、次いで、そのメッセージ（ＭＳＧ１）が、Ｒｘインターフェースを介してＰＣＲＦ２０２に送信されることができる。ＡＮ２０１によって送信されるメッセージは、必要とされる帯域幅および必要とされる媒体の種類に関する情報を含み得る。ＡＮ２０１によってＰＣＲＮ２０２に送信されるメッセージは、ＰＣＲＦ２０２がその他のコンポーネントから受信するその他のメッセージよりも優先され得るので、ＰＣＲＦ２０２がその他のコンポーネント（例えば、ＰＧＷ２０３）から衝突する情報を受信するとき、ＰＣＲＦ２０２は、ＡＮ２０１から送信されたメッセージに含まれる情報を使用することができる。

ＡＮ２０１によって送信されるメッセージは、ＡＡ−Ｒｅｑｕｅｓｔコマンドの形態であってもよい。ＡＡ−Ｒｅｑｕｅｓｔコマンドは、（例えば、Ｆｏｒｗａｒｄ−ＩＰ−Ａｄｄｒｅｓｓ ＡＶＰまたはＦｒａｍｅｄ−ＩＰｖ６−Ｐｒｅｆｉｘ ＡＶＰの）ＵＥ２０４のＩＰアドレスと、（例えば、Ｍｅｄｉａ−Ｃｏｍｐｏｎｅｎｔ−Ｄｅｓｃｒｉｐｔｉｏｎ ＡＶＰの）サービス情報とを含む複数の情報を含み得る。ＡＡ−Ｒｅｑｕｅｓｔは、（例えば、ＡＦ−Ａｐｐｌｉｃａｔｉｏｎ−Ｉｄｅｎｔｉｆｉｅｒ ＡＶＰの）セッションが属する可能性がある特定のサービスを示す情報も含み得る。

ＵＥ２０４は、ＡＮ２０１に前に送信されたＳＩＰサービス要求に関連する別のサービス要求を送信することもできる。関連するサービス要求は、ＰＧＷ２０３を通じてＰＣＲＦ２０２に送信可能であり、ＰＧＷ２０３は、当該サービス要求をＣＣ Ｒｅｑｕｅｓｔメッセージの形態で送信する。ＰＧＷ２０３は、ＰＣＥＦを含めることが可能であり、ＰＣＥＦは、ＰＣＲＦ２０２に送信されるメッセージ（ＭＳＧ２）にサービス要求を含めることができる。ＰＧＷ２０３から送信されるメッセージは、ＰＣＲＦ２０２がＰＣＣ規則を生成するときに両方の受信されたメッセージからの相補的な情報を使用することができるので、ＡＮ２０１によって送信されたメッセージに対する対をなすメッセージであり得る。ＰＧＷ２０３から送信されるメッセージに含まれる情報は、例えば、所要の保証されるビットレートを含み得る。

ＰＧＷ２０３は、メッセージをＣＣ Ｒｅｑｕｅｓｔの形態で送信することができる。ＣＣ Ｒｅｑｕｅｓｔは、Ｅｖｅｎｔ−Ｔｒｉｇｇｅｒ ＡＶＰおよびＰａｃｋｅｔ−Ｆｉｌｔｅｒ−Ｏｐｅｒａｔｉｏｎ ＡＶＰを含む可能性があり、ＰＣＲＮ２０２による特定のアクションを引き起こすことができ、このことは、図５Ａ−５Ｃに関連して以下で検討される。ＣＣ Ｒｅｑｕｅｓｔは、対応するＰａｃｋｅｔ−Ｆｉｌｔｅｒ−Ｉｎｆｏｒｍａｔｉｏｎ ＡＶＰも含み得る。

ＰＣＲＮ２０２は、情報を含む複数のメッセージを受信することが可能であり、それらの情報を用いてＰＣＣ規則を形成することができる。ＰＣＲＮ２０２は、ＰＣＲＮ２０２が受信する最初のメッセージに基づいて異なるプロシージャを使用することが可能である。例えば、ＰＣＥＦを含むＰＧＷ２０３がＰＣＣ規則のプロビジョニングの要求を求める場合、ＰＣＲＦ２０２は、図４Ａ−４Ｂに関連してさらに検討されるようにＰＵＳＨプロシージャを実施することができ、ＰＣＲＮ２０２は、ＰＧＷ２０３へのＲｅ−ａｕｔｈｏｒｉｚａｔｉｏｎ Ｒｅｑｕｅｓｔ（ＲＡＲ）コマンドでＰＣＣ規則をプロビジョニングする。あるいは、この要求が求められていない（例えば、この要求がＡＮ２０１から来る）とき、ＰＣＲＦ２０２は、図５Ａ−５Ｃに関連してさらに検討されるようにＰＵＬＬコマンドを実施することができ、ＰＣＲＮ２０２は、ＰＣＣ規則を生成し、ＰＣＣ規則をＣＣＡメッセージに含める。

加入者ネットワーク１００、２００のコンポーネントを説明したところで、加入者ネットワーク１００、２００の動作の簡潔な概要が与えられる。以下の説明は、加入者ネットワーク１００、２００の動作のあらましを与えるように意図されており、したがって、いくつかの点で簡略化されていることは明らかであるに違いない。加入者ネットワーク１００、２００の詳細な動作が、図３−５に関連して以下でさらに詳細に説明される。

さまざまな例示的な実施形態によれば、ユーザ機器２０４は、ユーザ機器２０４がサービスを受けることを望むことを示すためにＡＮ２０１、ＳＧＷ１３２、またはＰＧＷ２０３を含む複数のデバイスと通信することができる。そのような通信は、ＥＰＣ１３０およびパケットデータネットワーク２０５を介して、またはその他の通信チャネル（図示せず）を介して行われ得る。そのとき、ＡＮ２０４、ＳＧＷ１３２、またはＰＧＷ２０３は、要求されたサービスを提供するのに必要な、必要な加入者およびデータフロー情報の一部を含むメッセージを組み立てることができる。必要な情報のすべては、ＡＮ２０１、ＳＧＷ１３２、ＳＰＲ１３８、およびＰＧＷ２０３などの複数のデバイスに散らばっている可能性がある。次いで、ＡＮ２０１、ＳＧＷ１３２、ＳＰＲ１３８、またはＰＧＷ２０３は、必要なインターフェースを通じて、生成されたメッセージをＰＣＲＮ２０２に転送することができる。第１のメッセージを受信すると、ＰＣＲＮ２０２は、第２の対をなすメッセージを待つためのタイマーを開始することができる。このタイマーは、ＰＣＣ規則の生成をＰＣＲＮ２０２の実行キューの最後にプッシュすることができる。例えば、ＡＮ２０１が第１のメッセージをＰＣＲＮ２０２に送信する可能性があり、そのとき、ＰＣＲＮ２０２はＰＧＷ２０３からの第２のメッセージを期待して待つ可能性がある。そのとき、ＰＣＲＮ２０２は、ＰＣＣ規則の生成をそのＰＣＲＮ２０２の実行キューの最後に置き、その他の機能を実行しながら第２のメッセージが到着するのを効果的に待つことができる。ＰＣＲＮ２０２が、タイマーが切れる前に第２のメッセージを受信するとき、ＰＣＲＮ２０２は、両方のメッセージからの情報を用いてＰＣＣ規則を直ちに生成することができる。

しかし、第２のメッセージが、タイマーが切れる前に到着しないとき、ＰＣＲＮ２０２は、例えば、既存のＰＣＣ規則からの情報を含み得るその他のソースからの情報に加えて、第１のメッセージからの情報を含み得る利用可能な情報を用いてＰＣＣ規則を生成することができる。ＰＣＲＮ２０２は、ＰＣＣ規則を生成するときに、ＳＰＲ１３８からの加入者データと内部で生成されたポリシーの決定とを考慮に入れることもできる。次に、ＰＣＲＮ２０２は、生成されたＰＣＣ規則を、インストールのためにＧｘインターフェースを介してＰＧＷ２０３に送信することができる。ＰＣＣ規則を送信した後に、ＰＣＲＮ２０２が第２のメッセージを受信する可能性があり、このことは、タイマーが切れた後で起こる可能性がある。この例においては、第１の生成されたＰＣＣ規則がＰＧＷ２０３にプッシュされた後に、ＰＣＲＮ２０２が、ＰＧＷ２０３から第２のメッセージを受信する可能性がある。そのとき、ＰＣＲＮ２０２は、前に生成されたＰＣＣ規則の情報、具体的には第１のメッセージからの情報と、第２のメッセージの情報との両方を用いて第２の新しいＰＣＣ規則を生成することができる。次いで、ＰＣＲＮ２０２は、前に生成された規則をＰＧＷ２０３から取り除き、新しいＰＣＣ規則をゲートウェイＰＧＷ２０３に送信することができる。ＰＣＣ規則のインストールの後、ＰＧＷ２０３は、加入者に適切に課金し、特定のＱｏＳが満たされることを保証しながら、要求されたデータフローに関するデータ通信を許可することができる。

図３は、少なくとも１つのサービス要求に応答して新しいポリシーおよび課金制御（ＰＣＣ）規則を生成するための例示的なポリシーおよび課金規則ノード（ＰＣＲＮ）３００を示す。ＰＣＲＮ３００は、例示的な加入者ネットワーク１００、２００のＰＣＲＮ１３６、２０２に対応することが可能性である。ＰＣＲＮ３００は、Ｒｘインターフェース３０１、タイマー３０３、規則ストレージ３０５、メッセージ対チェッカー３０７、Ｓｐインターフェース３０９、規則プロセッサ３１１、およびＧｘインターフェース３１３を含み得る。

Ｒｘインターフェース３０１は、ＡＮ１５０、２０１に含まれるアプリケーション機能（ＡＦ）などのＡＦと通信するように構成された、ハードウェア、および／または機械可読ストレージ媒体において符号化された実行可能命令を含むインターフェースであってもよい。そのような通信は、３ＧＰＰ ＴＳ２９．２１４に準じて実施され得る。具体的には、Ｒｘインターフェース３０１は、ＡＮ１５０からのアプリケーション要求（ＡＡＲ）などのメッセージでサービス要求を受信することができる。ＰＣＲＮ２００は、アプリケーションノードからの受信サービス要求メッセージをサービスフローに変換することができる。サービスフローは、例えば、要求された帯域幅、加入者の識別子、および／またはデータストリームの種類などの、アプリケーションメッセージによって記述された情報を含み得る。

タイマー３０３は、ＰＣＲＮ３００が第１のサービス要求メッセージを受信した後に第２の対をなすサービス要求メッセージが到達するのを待つ期間を開始するように構成された、ハードウェア、および／または機械可読ストレージ媒体における実行可能命令を含み得る。タイマー３０３は、ＰＣＲＮ３００が第２のメッセージの受信を明示的に待つクロック期間を設定する時間であることが可能である。代替的な実施形態において、タイマー３０３は、ＰＣＲＮ３００をトリガさせて、ＰＣＣ規則の生成の優先度を実行キューの後ろに置くことにより、そのような生成を遅らせることができる。そのような場合、ＰＣＲＮ３００は、そのＰＣＲＮ３００の実行キュー内でより上位のその他の機能を実行することによって、ある期間の間、受動的に「待つ」。ＰＣＣ規則生成コマンドが実行キューで再び発生するとき、ＰＣＲＮ３００は、第２の対をなすサービス要求メッセージが実際に到着したかどうかを判定するためのチェックを再び行うことができる。

規則ストレージ３０５は、ＰＣＲＮ３００によって生成されたＰＣＣ規則を記憶することができる任意の機械可読媒体であってもよい。したがって、規則ストレージ３０５は、読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスクストレージ媒体、光学式ストレージ媒体、フラッシュメモリデバイス、および／または同様のストレージ媒体などの機械可読ストレージ媒体を含み得る。規則ストレージ３０５は、ＰＣＲＮ３００によって生成された多数のＰＣＣ規則の定義を記憶することができる。そのような定義は、例えば、規則名、サービスデータフローフィルタ、ＱｏＳパラメータ、および課金パラメータを含み得る。

メッセージ対チェッカー３０７は、複数のインターフェースからメッセージを受信し、それらのメッセージが対をなすかどうかを判定するように構成された、ハードウェア、および／または機械可読ストレージ媒体における実行可能命令を含み得る。ＵＥ１１０は、複数のデバイスに相補的なメッセージを送信する可能性がある。これらのメッセージは、複数の情報を含む可能性があり、一部の情報は、そのメッセージが相補的なメッセージを期待して待っているかどうかということである。したがって、メッセージ対チェッカー３０７は、合致するアプリケーションノード（ＡＮ）要求またはゲートウェイ要求の形態の合致するメッセージが存在するかどうかを判定することによって少なくとも２つのメッセージを相互に関連付けることができる。図４−５に関連して以下で検討されるように、メッセージ対チェッカーは、対をなすメッセージが期待されるべきであるか、および受信メッセージが対をなすメッセージが到着するのをまだ待っているかどうかを判定するために複数のマーカーを調べることができる。

Ｓｐインターフェース３０９は、ＳＰＲ１３８などのＳＰＲと通信するように構成された、ハードウェア、および／または機械可読ストレージ媒体において符号化された実行可能命令を含むインターフェースであってもよい。したがって、Ｓｐインターフェース３０９は、レコード要求を送信し、加入プロファイルレコードを受信することができる。

規則プロセッサ３１１は、例えば、サービス要求メッセージに含まれる情報に基づいて新しいＰＣＣ規則を生成するように構成された、ハードウェア、および／または機械可読ストレージ媒体における実行可能命令を含み得る。規則プロセッサ３１１は、最初に、ＰＣＲＮ３００によって受信された情報から新しいＰＣＣ規則オブジェクトを生成することができる。次に、規則プロセッサ３１１は、新しいＰＣＣ規則のＰＣＣ規則名を生成し、記憶することができる。ＰＣＣ規則名は、例えば、前に割り当てられた規則名をインクリメントすること、またはランダムな名前を生成することなど、当業者に知られている任意の方法によって生成され得る。規則プロセッサ３１１は、ＰＣＣ規則にその他のデータを挿入することもできる。この時点で、新しいＰＣＣ規則は、インストールの準備ができた有効な規則であっても、またはさらなる修正を必要としてもよい。

Ｇｘインターフェース３１３は、ＰＧＷ１３４などのＰＧＷと通信するように構成された、ハードウェア、および／または機械可読ストレージ媒体において符号化された実行可能命令を含むインターフェースであってもよい。そのような通信は、３ＧＰＰ ＴＳ２９．２１２に準じて実施され得る。したがって、Ｇｘインターフェース３１３は、ＰＣＣ規則の要求を受信し、インストールするためのＰＣＣ規則を送信することができる。

図４Ａ−４Ｂは、ＡＮ１５０からのサービス要求に応答して新しいポリシーおよび課金制御（ＰＣＣ）規則を生成するための例示的な方法４００、４５０を示す。方法４００、４５０は、少なくともＡＮ１５０からのサービス要求によって特定されたサービスデータフローに関するＰＣＣ規則を確立するためにＰＣＲＮ１３０および／またはＰＣＲＮ２００、３０２のコンポーネントによって実行され得る。

方法４００は、ステップ４０１において始まり、ＰＣＲＮ１３０が、ＡＮ１５０からのサービス要求をＲｘインターフェースを介してサービスフローの形態で受信することが可能であるステップ４０３に進むことができる。ＰＣＲＮ１３０が最初にＡＮ１５０からメッセージを受信するので、対応するＰＣＣ規則は、「Ｎｅｔｗｏｒｋ−Ｉｎｉｔｉａｔｅｄ」とラベル付けされる可能性がある。サービスフローは、ＡＮメッセージのコンポーネントの階層から導出され得る。ＡＮメッセージは、各メディアコンポーネント（Ｍｅｄｉａ Ｃｏｍｐｏｎｅｎｔ）（ＭＣ）が複数のメディアサブコンポーネント（Ｍｅｄｉａ Ｓｕｂ−Ｃｏｍｐｏｎｅｎｔ）（ＭＳＣ）を含む複数のメディアコンポーネントからなる可能性がある。各メディアサブコンポーネントは、１つかまたは２つかのどちらかのフローディスクリプション（ｆｌｏｗ ｄｅｓｃｒｉｐｔｉｏｎ）（ＦＤ）を含み得る。サービスフローは、１つまたは２つのフローディスクリプションを対応するメディアコンポーネントおよびメディアサブコンポーネントとマッチングさせる、この階層の平坦化された表現である可能性がある。各サービスフローは、ゲートウェイＳＧＷ１３２またはＰＧＷ１３４にインストールされ得る別個のＰＣＣ規則にマッピングすることが可能である。したがって、ＰＣＣ規則は、そのＰＣＣ規則の生成に使用されたサービスフローへの参照を含み得る。

次に、方法４００は、ＰＣＲＮ１３６内のポリシー決定モジュール２４０が、受信されたサービスフローに合致するＰＣＣ規則が規則ストレージ２６０に存在するかどうかを判定することができるステップ４０５に進むことができる。合致するＰＣＣ規則が存在する場合、方法４００は、図４Ｂに関連してさらに検討される方法４５０のステップ４０７に対応するステップ４０７に進む。合致するＰＣＣ規則が存在しない場合、このことは、ＡＮ１５０からのメッセージがＰＣＣ規則の要求を開始したことを示す可能性があり、したがって、方法は、ポリシー決定モジュール２４０が新しいＰＣＣ規則の要求を生成することができるステップ４０９に進む。

ステップ４１１において、基本規則ジェネレータ２２０が、ゲートウェイ要求待ち受け（Ｗａｉｔｉｎｇ ｆｏｒ Ｇａｔｅｗａｙ Ｒｅｑｕｅｓｔ）（ＷＧＲ）マーカーを含むＰＣＣ規則を生成することができる。ＰＣＣ規則に含まれるＷＧＲマーカーは、対をなすゲートウェイ要求がＰＣＲＮ１３６によって受信されることをサービスフローがまだ待っていることを示すブール値であり得る。基本ＰＣＣ規則の生成は、例えば、ＰＣＣ規則名、サービスデータフローフィルタ、および初期ＱｏＳ帯域幅パラメータを生成することも含み得る。このステップの間に、ＰＣＲＮ１３６は、メッセージに、対をなすゲートウェイ要求が受信されることをサービスフローが待っていることを示す「ｔｒｕｅ」の印をつけることができる。ステップ４１３において、ＰＣＲＮ１３６は、ＰＧＷ１３４から対をなすメッセージを受信するのを待つためのタイマーを開始することができる。ＰＣＲＮ１３６は、対をなすメッセージが、サービスフローで受信されたメッセージと相補的な情報を含み得るので、対をなすメッセージを待つ可能性がある。

ＰＣＲＮ１３６は、タイマーが切れるか、または対をなすゲートウェイ要求が到着するかのいずれかまで待つことができる。どちらの場合も、方法４００は、ＰＣＲＮ１３６が、現在、規則ストレージ２６０に合致するＰＣＣ規則が存在するかどうかを判定するステップ４１５に進む。存在する場合、このことは、タイマーがまだ切れていない間にゲートウェイ要求が到着したことを示す。この場合、方法４００は、ＰＣＣ規則がサービスフローとゲートウェイ要求のフロー情報との両方からの関連する情報を有するのでＰＣＲＮ１３６が何もしないステップ４１７に進む。

しかし、合致するＰＣＣ規則が存在しない場合、このことは、対をなすゲートウェイ要求がＰＣＲＮのタイマーが切れる時間までに到着しなかったことを示す。この場合、方法４００は、基本規則ジェネレータ２２０がＡＮ１５０からのサービスフロー情報を用いてＰＣＣ規則を生成するステップ４１９に進む。これは、対をなすゲートウェイ要求からの更新をまだ待つことができるので第１のＰＣＣ規則である可能性がある。ＰＣＲＮ１３６は、ＰＣＲＮ１３６が、ベアラ制御モード動作（Ｂｅａｒｅｒ Ｃｏｎｔｒｏｌ Ｍｏｄｅ Ｏｐｅｒａｔｉｏｎ）（ＢＣＭＯ）マーカーを、ＰＣＣ規則がＡＮ１５０からのサービス要求のみの結果として生成されたことを示す「Ｎｅｔｗｏｒｋ−ｉｎｉｔｉａｔｅｄ」に設定するステップ４２１においてそのような状態を示すことができる。ＢＣＭＯマーカーが「ＵＥ−ｉｎｉｔｉａｔｅｄ」に設定されている場合、このことは、ＰＣＣ規則が、ＰＧＷ１３４を通じたＵＥ１１０からのサービス要求またはＡＮ１５０からのサービス要求の結果として生成されたことを示す可能性がある。

ステップ４２３において、最初に、ＰＣＲＮ１３６は、ＷＧＲマーカーの値を調べることによって、サービスフローがＡＮ要求を待っていないことを保証する。ＷＧＲマーカーがｆａｌｓｅに設定されている場合、ＰＣＲＮ１３６は、そのＷＧＲマーカーの値を変更しない。あるいは、ＷＧＲマーカーがｔｒｕｅに設定されている場合、ＰＣＲＮ１３６は、ＷＧＲマーカーの値をｆａｌｓｅに変更することができる。これは、ＰＣＲＮ１３６が、既に到着した対をなすメッセージを誤って待つことがないことを保証することができる。

ステップ４２５において、最初に、ＰＣＲＮ１３６は、アプリケーションノード要求待ち受け（Ｗａｉｔｉｎｇ ｆｏｒ Ａｐｐｌｉｃａｔｉｏｎ Ｎｏｄｅ Ｒｅｑｕｅｓｔ）（ＷＡＮＲ）マーカーの値を調べることによって、ＰＣＣ規則のＷＡＮＲマーカーがｆａｌｓｅに設定されていることを保証する。マーカーがｆａｌｓｅである場合、ＰＣＲＮ１３６は、そのマーカーの値を変更しない。あるいは、ＷＡＮＲマーカーがｔｒｕｅに設定されている場合、ＰＣＲＮ１３６は、ＷＧＲマーカーの値をｆａｌｓｅに変更することができる。次いで、ＰＣＲＮ１３６は、ＰＣＲＮ１３６がＰＣＣ規則をＰＧＷ１３４にプッシュするステップ４２７に進む。

方法４５０は、方法４００の続きであり、受信されたサービスフローに関して規則ストレージ２６０に格納された合致するＰＣＣ規則が存在するときのＰＣＲＮ１３６のアクションを示すことができる。方法４００のステップ４０７に対応するステップ４５１に続いて、方法４５０は、ポリシー決定モジュール２４０がサービスフローのフローの状態がｒｅｍｏｖｅｄかどうかを判定するステップ４５３に進む。サービスフローのフローの状態がｒｅｍｏｖｅｄであるとき、方法４５０は、ＰＣＲＮ１３６がサービス要求が終了要求であると判定するステップ４５４に進む。終了要求にしたがって、ステップ４５６において、ＰＣＲＮ１３６は、受信されたサービスフローに合致したＰＣＣ規則を取り除く。ステップ４５８において、ＰＣＲＮ１３６は、サービスフローに「ｒｅｍｏｖｅｄ」と印をつけ、新しいＰＣＣ規則を生成せず、受信されたサービスフローに対してさらなるアクションを何もしない。

しかし、サービスフローがｒｅｍｏｖｅｄと印をつけられない場合、方法４５０はステップ４５５に進み、ステップ４５５において、ＰＣＲＮ１３６は、サービス要求が、受信されたサービスフローに合致したＰＣＣ規則が少なくとも受信されたサービスフローに含まれる情報を用いて修正され得ることを示す規則修正要求であると判定する。ステップ４５５に続いて、ステップ４５７において、ＰＣＲＮは、ＰＣＣ規則に含まれるＢＣＭＯマーカーを調べる。ＰＣＣ規則がＮｅｔｗｏｒｋ−ｉｎｉｔｉａｔｅｄであることをＢＣＭＯマーカーが示す場合、方法４５０は、ステップ４６０に進む。しかし、規則がＵＥ−ｉｎｉｔｉａｔｅｄと印をつけられている場合、方法４５０は、ステップ４７１に進む。

ステップ４６０において、ＰＣＲＮ１３６は、例えば、ＰＧＷ１３４からのフロー情報などのその他のデバイスからの新しく受信された情報を用いて前に合致したＰＣＣ規則を更新する。これは、ＰＧＷ１３４から受信された新しい情報を反映するために規則ストレージ２６０に記憶された既存のＰＣＣ規則を修正するポリシー決定規則モディファイア（ｐｏｌｉｃｙ ｄｅｃｉｓｉｏｎ ｒｕｌｅ ｍｏｄｉｆｉｅｒ）２５０を取り除くことを両方含み得る。これは、ＰＣＲＮ１３６によって前に送信された既存のＰＣＣ規則を更新するためにＰＣＲＮ１３６がＰＧＷ１３４にＣＣ Ａｎｓｗｅｒを送信することも含み得る。

ステップ４６１および４６５において、ＰＣＲＮ１３６は、ステップ４２３および４２５と同様に動作し、ＰＣＲＮ１３６は、ＷＡＮＲマーカーがｆａｌｓｅに設定されていることを調べることによって新しいＰＣＣ規則がＡＮ要求を待っていないことを保証し、次に、ＷＧＲが対をなすゲートウェイ要求を待っていないものとして印をつけられていることを保証する。次いで、方法４５０は、ＰＣＲＮ１３６が、前のＰＣＣ規則を取り除き、新しく生成されたＰＣＣ規則をＰＧＷ１３４のＰＣＥＦにプッシュし、ＰＣＥＦが、更新されたＰＣＣ規則をその他のゲートウェイに転送することができるステップ４６９に進む。

ステップ４５７に戻ると、ＰＣＣ規則のＢＣＭＯがＵＥ−ｉｎｉｔｉａｔｅｄと印をつけられている場合、方法４５０は、それぞれ、方法４００および４５０のステップ４２７および４６１に対応するステップ４７１に進み、ＰＣＲＮが、ＰＣＣのＷＡＮＲマーカーを調べて、ＰＣＣ規則が対をなすＡＮ要求を待っているかどうかを判定する。ＷＡＮＲマーカーがｔｒｕｅに設定されている場合、ＰＣＣ規則は、ＡＮ要求を待っており、このことは、対をなすゲートウェイ要求が既に到着したことを示す可能性がある。

ゲートウェイ要求が到着している場合、方法４５０は、基本規則ジェネレータ２２０が、最初に受信されたサービスフローの情報および既存のＰＣＣ規則の情報を用いて新しいＰＣＣ規則を生成することができるステップ４７３に進むことができる。新しいＰＣＣ規則を生成した後、ステップ４７５−４７７において、ＰＣＲＮ１３６は、対をなす要求がＰＣＲＮ１３６によって受信されることをＰＣＣ規則およびサービスフローがもはや待っていないことを示すために、対応するＷＡＮＲマーカーとＷＧＲマーカーの両方にｆａｌｓｅの印をつける。ステップ４６９に対応するステップ４７９において、ＰＣＲＮは、新しいＰＣＣ規則をＰＧＷ１３４のＰＣＥＦにプッシュし、ＰＣＥＦが、新しいＰＣＣ規則をその他のゲートウェイに送信することができる。

ステップ４７１に戻ると、ＷＡＮＲマーカーがｆａｌｓｅに設定されている場合、これは、ＰＣＣ規則がＡＮ要求を待っていなことを示す可能性があり、このことは、対をなすゲートウェイ要求が到着していないことを示す可能性がある。したがって、方法４５０は、ＰＣＲＮ１３６が、対応するサービスフローのＷＧＲマーカーに、サービスフローが対をなすゲートウェイ要求を待っていることを示し得るｔｒｕｅの印をつけるステップ４８０に進む。その後、方法４５０は、ＰＣＲＮ１３６が対をなすゲートウェイ要求を待つためのタイマーを開始するステップ４８１に進む。

ステップ４８３において、方法４５０は、ＷＧＲマーカーがｔｒｕｅに設定されているかどうかを判定する。ＷＧＲマーカーは、対をなすゲートウェイ要求がＧｘインターフェース２８５を介してＰＣＲＮ１３６によって受信されるときにはいつもｆａｌｓｅに設定され得る。ＰＣＲＮ１３６によるそのような受信は、タイマーが切れる前に起こり得る。ＷＧＲマーカーがｆａｌｓｅに設定されているとき、これは、タイマーが切れる前にゲートウェイ要求が到着し、ゲートウェイが規則を別途入手した可能性があることを示し得る。この場合、方法４５０は、ＰＣＲＮ１３６がさらなるアクションを行わないステップ４８５に進む。そうではなく、ステップ４８３において、ＷＧＲ要求がｔｒｕｅに設定されている場合、サービスフローは対をなすゲートウェイ要求をまだ待っており、方法４５０はステップ４８７に進む。

ステップ４８７において、ＰＣＲＮ１３６は、受信されたサービスフローの情報を用いて既存のＰＣＣ規則を修正することができる。したがって、新しく修正されたＰＣＣ規則は、サービスフローに含まれる情報の変更を除いて、前に生成されたＰＣＣ規則と同様である可能性がある。４６１に対応するステップ４９１において、ＰＣＲＮ１３６は、新しいＰＣＣ規則のＷＡＮＲマーカーがｆａｌｓｅに設定されていることを保証する。ステップ４９５において、ＰＣＲＮ１３６は、ＰＧＷ１３４からフロー情報を受信していない可能性があり、部分的な情報を用いて生成された可能性があるので、受信されたサービスフローのＷＧＲマーカーがやはりｔｒｕｅに設定されていることを保証する可能性がある。その後、ステップ４９７において、ＰＣＲＮ１３６は、新しいＰＣＣ規則をＰＧＷ１３４のＰＣＥＦに転送することができ、次いで、ＰＣＥＦが、現在のＰＣＣ規則をその他のゲートウェイに転送することができる。

図５Ａ−５Ｃは、ＰＧＷ１３４からのサービス要求に応答してポリシーおよび課金制御（ＰＣＣ）規則を生成するための例示的な方法５００、５２０、５６０を示す。方法５００、５２０、５６０は、少なくともＰＧＷ１３４のＰＣＥＦからのサービス要求によって特定されたフローディスクリプションに関するＰＣＣ規則を確立するためにＰＣＲＮ１３０および／またはＰＣＲＮ２００、３０２のコンポーネントによって実行され得る。

ここで図５Ａを参照すると、方法５００は、最初に、ＰＣＲＮ１３６が、フロー情報を含むＰＧＷ１３４からのサービス要求を受信するステップ５０１−５０３で始まる。フロー情報は、サービス要求に含まれるＰａｃｋｅｔ−Ｆｉｌｔｅｒ−Ｉｎｆｏｒｍａｔｉｏｎ ＡＶＰ内に含まれ得る。サービス要求は、対応するＰａｃｋｅｔ−Ｆｉｌｔｅｒ−Ｏｐｅｒａｔｉｏｎ ＡＶＰも含み得る。この場合、ＰＧＷ１３４がサービス要求を開始し、結果として、ＰＣＲＮ１３６は、対応するＰａｃｋｅｔ−Ｆｉｌｔｅｒ−Ｏｐｅｒａｔｉｏｎ ＡＶＰの値に基づいてサービス要求を処理することができる。

したがって、ＰＣＲＮ１３６は、ステップ５０５において、Ｐａｃｋｅｔ−Ｆｉｌｔｅｒ−Ｏｐｅｒａｔｉｏｎ ＡＶＰがａｄｄｉｔｉｏｎに設定されているかどうかを調べることができる。Ｐａｃｋｅｔ−Ｆｉｌｔｅｒ−Ｏｐｅｒａｔｉｏｎ ＡＶＰがａｄｄｉｔｉｏｎに設定されている場合、方法５００は、以下でさらに詳細に検討される図５Ｂの方法５２０を開始するステップ５０６に進み、そうでない場合、方法５００は、ＰＣＲＮ１３６がＰａｃｋｅｔ−Ｆｉｌｔｅｒ−Ｏｐｅｒａｔｉｏｎ ＡＶＰがｍｏｄｉｆｉｃａｔｉｏｎに設定されているかどうかを判定する５０７に進む。ステップ５０７において、ＰＣＲＮがＰａｃｋｅｔ−Ｆｉｌｔｅｒ−Ｏｐｅｒａｔｉｏｎ ＡＶＰがｍｏｄｉｆｉｃａｔｉｏｎに設定されていると判定する場合、方法５００は、以下でさらに詳細に検討される図５Ｃの方法５６０を開始するステップ５０８に進み、そうでない場合、方法５００は、ＰＣＲＮ１３６がＰａｃｋｅｔ−Ｆｉｌｔｅｒ−Ｏｐｅｒａｔｉｏｎ ＡＶＰがｔｅｒｍｉｎａｔｉｏｎに設定されているかどうかを判定する５０９に進む。設定されていない場合、Ｐａｃｋｅｔ−Ｆｉｌｔｅｒ−Ｏｐｅｒａｔｉｏｎは誤った動作に設定されており、したがって、方法５００は、さらなる動作が終了するステップ５１９に進む。

Ｐａｃｋｅｔ−Ｆｉｌｔｅｒ−Ｏｐｅｒａｔｉｏｎ ＡＶＰがｔｅｒｍｉｎａｔｉｏｎに設定されているとき、方法５００は、ＰＣＲＮ１３６が規則ストレージ２６０が合致するＰＣＣ規則を含むかどうかを判定するステップ５１１に進む。規則ストレージ２６０が合致するＰＣＣ規則を含まない場合、ＰＣＲＮ１３６が取り除くべき規則は存在せず、したがって、方法５００は、ＰＣＲＮ１３６がさらなるアクションを行わないステップ５１３に進む。そうではなく、合致する規則が存在する場合、方法５００は、ＰＣＲＮ１３６が合致するＰＣＣ規則を規則ストレージ２６０から取り除くステップ５１５に進み、ステップ５１７において、ステップ５１９のさらなる動作の終了に進む前に、合致するＰＣＣ規則に対応するサービスフローにｒｅｍｏｖｅｄの印をつける。

ここで図５Ｂを参照すると、ＰＣＲＮ１３６が、Ｐａｃｋｅｔ−Ｆｉｌｔｅｒ−Ｏｐｅｒａｔｉｏｎ ＡＶＰがａｄｄｉｔｉｏｎに設定されているときの方法５２０を実施する。そのような場合、サービス要求を含んでいたＣＣ Ｒｅｑｕｅｓｔは、ＵＥによって要求された各パケットフィルタに関するＰａｃｋｅｔ−Ｆｉｌｔｅｒ−Ｉｎｆｏｒｍａｔｉｏｎ ＡＶＰと、パケットフィルタに関する要求されたサービス品質を示し得るＱｏＳ−Ｉｎｆｏｒｍａｔｉｏｎ ＡＶＰとをさらに含む可能性がある。方法５２０は、図５Ａの方法５００のステップ５０６に対応するステップ５２１で開始することができる。

方法５００のステップ５１１に対応する可能性があるステップ５２２において、ＰＣＲＮ１３６は、合致するＰＣＣ規則が規則ストレージ２６０に存在するかどうかを判定することができる。合致する規則が規則ストレージ２６０に存在する場合、方法５２０は、ＰＣＲＮ１３６が、ＰＧＷ１３４からの受信されたサービス要求のフロー情報を用いて、規則ストレージ２６０に記憶された既存のＰＣＣ規則を修正することができるステップ５２３に進む。次いで、ＰＣＲＮ１３６は、ステップ５２６−５２８において、それぞれ、ＰＣＣ規則のＢＣＭＯマーカーにＵＥ−ｉｎｉｔｉａｔｅｄと印をつけ、ＰＣＣ規則のＷＡＮＲマーカーにｆａｌｓｅと印をつけ、サービスフローのＷＧＲマーカーにｆａｌｓｅと印をつけることができる。ステップ５２９において、ＰＣＲＮ１３６は、新しいＰＣＣ規則をＰＧＷ１３４に返すことができ、次いで、ＰＧＷ１３４が、新しいＰＣＣ規則をその他のゲートウェイにプッシュすることができる。

ステップ５２２に戻ると、ＰＣＲＮ１３６が規則ストレージ２６０内の合致するＰＣＣ規則を発見しない場合、方法５２０は、ＰＣＲＮ１３６がそのＰＣＲＮ１３６がゲートウェイ要求のフロー情報に関する合致するサービスフローを受信したかどうかを判定することができるステップ５３０に進むことができる。ＰＣＲＮ１３６が合致するサービスフローを発見する場合、これは、最初にＡＮ１５０からのサービス要求が到着しており、ＰＣＲＮ１３６がゲートウェイ要求の受信を待つためのタイマーを既に作動させた可能性があることを示す可能性がある。したがって、ＰＣＲＮ１３６は、ＰＣＲＮ１３６が、ゲートウェイ要求に含まれるフロー情報および受信されたサービスフローに含まれる情報を用いて新しいＰＣＣ規則を生成するステップ５３２に進むことができる。続いて、ステップ５３４において、ＰＣＲＮ１３６は、新しいＰＣＣ規則にＵＥ−ｉｎｉｔｉａｔｅｄと印をつけ、新しいＰＣＣ規則のＷＡＮＲマーカーを、新しいＰＣＣ規則がＡＮ要求を待っていないことを示すｆａｌｓｅに設定することができる。ステップ５３６において、ＰＣＲＮ１３６は、受信されたサービスフローのＷＧＲマーカーを、そのサービスフローが対をなすＡＮ要求を待っていないことを示すｆａｌｓｅに設定することができる。ステップ５３８において、ＰＣＲＮ１３６は、新しいＰＣＣ規則をＰＧＷ１３４に返すことができ、続いて、ＰＧＷ１３４が、新しいＰＣＣ規則をその他のゲートウェイにプッシュすることができる。

ステップ５３０に戻ると、合致するサービスフローが存在しない場合、これは、最初にゲートウェイ要求がＰＣＲＮ１３６に到着したことを示す可能性がある。したがって、ステップ５４０において、ＰＣＲＮ１３６は、ゲートウェイ要求に含まれるフロー情報を用いてＰＣＣ規則を生成することができる。ステップ５４１において、ＰＣＲＮ１３６は、新しく生成されたＰＣＣ規則のＢＣＭＯマーカーを、ＰＣＣ規則がゲートウェイによって開始された要求に応答して生成されたことを示すＵＥ−ｉｎｉｔｉａｔｅｄに設定することができる。ステップ５４２において、次に、ＰＣＲＮ１３６は、新しく生成されたＰＣＣ規則をＰＧＷ１３４に返すことができ、続いて、ＰＧＷ１３４が、新しく生成されたＰＣＣ規則をネットワーク内のその他のゲートウェイにプッシュすることができる。

次いで、ＰＣＲＮ１３６は、加入規則モディファイア（ｓｕｂｓｃｒｉｐｔｉｏｎ ｒｕｌｅ ｍｏｄｉｆｉｅｒ）が、ＳＰＲ１３８と交信することによって、ＵＥ１１０の加入者が既知のサービスにアクセスしているかどうかを判定するステップ５４３に進むことができる。加入者が既知のサービスにアクセスしていない場合、方法５２０は、ステップ５４４に進むことができる。この場合、ＰＣＲＮ１３６は、ゲートウェイから受信されたフロー情報を含み得る利用可能な情報を用いて既存のＰＣＣ規則を修正することができる。次に、ＰＣＲＮ１３６は、ＰＣＲＮ１３６が、新しい規則をＰＧＷ１３４にプッシュすることができ、続いて、ＰＧＷ１３４が、新しいＰＣＣ規則をその他のゲートウェイに転送することができるステップ５４５に進むことができる。

ここでステップ５４３に戻ると、加入者が知られているサービスにアクセスしているとＰＣＲＮ１３６が判定する場合、ＰＣＲＮ１３６は、ＰＣＣ規則のＷＡＮＲマーカーを、そのＰＣＣ規則が対をなすＡＮ要求をまだ待っていることを示すｔｒｕｅに設定することができる。それから、ＰＣＲＮ１３６は、ステップ５４８においてタイマーを開始し、タイマーの継続時間の間、対をなすＡＮ要求を待つことができる。ステップ５５０において、次いで、ＰＣＲＮ１３６は、ＷＡＮＲマーカーを再び調べて、そのＰＣＣ規則が対をなすＡＮ要求をまだ待っているかどうかを判定することができる。ＷＡＮＲマーカーが現在ｆａｌｓｅである場合、ＰＣＲＮ１３６は、ＰＣＣ規則がもはや対をなす要求を待っていないので、ステップ５５２に進み、さらなるアクションを行わない可能性がある。そうでない場合、ＰＣＲＮ１３６は、続いて、加入者が構成された「未知の」アプリケーションを有するかどうかをＰＣＲＮ１３６が判定することができるステップ５５４に進むことができる。加入者が構成された未知のアプリケーションを有する場合、次に、ＰＣＲＮ１３６は、ステップ５５６において、未知のアプリケーションに含まれる情報を用いて既存のＰＣＣ規則を更新することができる。しかし、加入者が構成された未知のアプリケーションを持たない場合、ＰＣＲＮは、ステップ５５８において、前に生成され、インストールされた規則を取り除くことができる。

ここで図５Ｂを参照すると、ＰＣＲＮ１３６が、Ｐａｃｋｅｔ−Ｆｉｌｔｅｒ−Ｏｐｅｒａｔｉｏｎ ＡＶＰがｍｏｄｉｆｉｃａｔｉｏｎに設定されているときの方法５６０を実施する。方法５６０は、図５Ａの方法５００のステップ５０８に対応するステップ５６１で開始する。方法５６０は、合致するＰＣＣ規則が規則ストレージ２６０に存在するときをＰＣＲＮ１３６が判定することによってステップ５６２で始まる。合致するＰＣＣ規則が存在しない場合、修正すべきＰＣＣ規則は存在せず、したがって、ＰＣＲＮ１３６は、ステップ５６３において、修正要求を無効であるとして拒否する。ステップ５６２において合致するＰＣＣ規則が規則ストレージ２６０に存在するとき、ＰＣＲＮ１３６は、合致するＰＣＣ規則のＢＣＭＯマーカーを調べて、ＰＣＣ規則が「Ｎｅｔｗｏｒｋ−ｉｎｉｔｉａｔｅｄ」と印をつけられているかどうかを判定する。ＰＣＣ規則がＮｅｔｗｏｒｋ−ｉｎｉｔｉａｔｅｄと印をつけられている場合、これは、ＵＥ−ｉｎｉｔｉａｔｅｄであるＰＣＣ入力が無効であることを示す可能性がある。したがって、ＰＣＲＮ１３６は、ＰＣＲＮ１３６が修正要求を拒否し、規則ストレージ２６０に記憶された合致するＰＣＣ規則、および合致するサービスフローを取り除くことができるステップ５６５に進むことができる。

しかし、ＢＣＭＯマーカーが合致するＰＣＣ規則がＵＥ−ｉｎｉｔｉａｔｅｄであることを示す場合、ＰＣＲＮは、ＰＣＲＮ１３６がゲートウェイ要求に関する合致するサービスフローが存在するかどうかを判定するステップ５６６に進むことができる。合致するサービスフローが存在しない場合、これは、ゲートウェイ要求がＰＣＣ規則の生成を開始したことを示す可能性がある。したがって、ＰＣＲＮ１３６は、ステップ５６８において、ゲートウェイ要求のフロー情報を用いて既存のＰＣＣ規則を修正することができる。次いで、ＰＣＲＮ１３６は、ステップ５６９において、修正されたＰＣＣ規則をＰＧＷ１３４に返すことができ、続いて、ＰＧＷ１３４が、修正されたＰＣＣ規則をその他のゲートウェイにプッシュすることができる。

ステップ５６６に戻ると、受信されたゲートウェイ要求に関する合致するサービスフローが存在する場合、ＰＣＲＮ１３６は、ステップ５７０に進み、サービスフローのＷＧＲマーカーを調べて、そのサービスフローがゲートウェイ要求をまだ待っているかどうかを判定することができる。サービスフローが対をなすゲートウェイ要求が到着するのを待っている場合、これは、ＡＮ要求が既にＰＣＲＮ１３６によって受信されたことと、ＰＣＲＮ１３６が既にＰＣＣ規則を生成し、その規則をＰＧＷ１３４にプッシュしたか、またはタイマーを開始し、ゲートウェイ要求を待っているかのいずれかであることとを示す可能性がある。どちらの場合も、方法５６０は、ＰＣＲＮ１３６が、サービスフローからの情報およびゲートウェイ要求からのフロー情報を用いて既存のＰＣＣ規則を修正することができるステップ５７２に進む。次に、ＰＣＲＮ１３６は、ＰＣＲＮ１３６がＷＡＮＲマーカーおよびＷＧＲマーカーのそれぞれにｆａｌｓｅと印をつけることができるステップ５７４−５７６に進むことができる。ステップ５７８において、次いで、ＰＣＲＮ１３６は、修正されたＰＣＣ規則をＰＧＷ１３４に返すことができ、続いて、ＰＧＷ１３４が、新しいＰＣＣ規則をその他のゲートウェイに転送することができる。

ステップ５７０に戻ると、サービスフローのＷＧＲマーカーが、そのサービスフローが対をなすゲートウェイ要求を待っていないことを示すとき。結果として、そのとき、方法５６０は、ＰＣＲＮ１３６が、ゲートウェイ要求に含まれるフロー情報およびサービスフローに含まれる情報を用いて既存のＰＣＣ規則を修正することができるステップ５８０に進むことができる。次いで、ＰＣＲＮ１３６は、ステップ５８２において、実際にＡＮ要求が期待されているかどうかを判定することができる。対をなす要求が期待して待たれていない場合、方法５６０は、ステップ５８３に進み、修正されたＰＣＣ規則を返し、修正されたＰＣＣ規則をその他のゲートウェイにプッシュする。

しかし、対をなすＡＮ要求が期待されている場合、ステップ５８４において、ＰＣＲＮ１３６は、新しいＰＣＣ規則のＷＡＮＲマーカーを、その新しいＰＣＣ規則が対をなすＡＮ要求を待っていることを示すｔｒｕｅに設定することができる。ステップ５８５において、次に、ＰＣＲＮ１３６は、対をなすＡＮ要求を待つためのタイマーを開始し、タイマーが切れるまでＡＮ要求を待つことができる。ステップ５８６において、ＰＣＲＮ１３６は、ＷＡＮＲマーカーを再び調べて、そのＷＡＮＲマーカーがｆａｌｓｅであるかどうかを判定することができる。新しいＰＣＣ規則のＷＡＮＲマーカーがｔｒｕｅのままである場合、ステップ５８８において、ＰＣＲＮ１３６は、加入者が構成された「未知の」アプリケーションを有するかどうかを調べる。加入者が構成された未知のアプリケーションを有する場合、ステップ５９０において、ＰＣＲＮ１３６は、未知のアプリケーションからの情報を用いて既存のＰＣＣ規則を更新することができる。加入者が構成された未知のアプリケーションを持たない場合、ステップ５９２において、ＰＣＲＮ１３６は、前に生成され、インストールされたＰＣＣ規則を取り除くことができる。再びステップ５８６を参照すると、ＷＡＮＲマーカーがｆａｌｓｅに変わる場合、ＰＣＲＮ１３６は、ステップ５９４において、さらなるアクションを行わない。

上述の内容によれば、さまざまな例示的な実施形態は、複数のデバイスからの複数のサービス要求に応じたポリシーおよび課金制御規則の動的な生成をもたらす。特に、サービス要求の最初の受信の間に利用可能な情報に基づいて暫定的なＰＣＣ規則を生成することによって、ＰＣＲＮは、対をなすサービス要求が別のデバイスを通じて到着するのが遅かったという理由で特定のＰＣＣ規則を使用できなくすることなしに、通信システムが適切に機能することを可能にすることができる。

本発明のさまざまな例示的な実施形態がハードウェアおよび／またはファームウェアで実装され得ることは、上述の説明から明らかであるに違いない。さらに、さまざまな例示的な実施形態は、本明細書において詳細に説明された動作を実行するために少なくとも１つのプロセッサによって読まれ、実行され得る、機械可読ストレージ媒体に記憶された命令として実施可能である。機械可読ストレージ媒体は、パーソナルもしくはラップトップコンピュータ、サーバ、またはその他のコンピューティングデバイスなどの機械によって読まれ得る形態で情報を記憶するための任意の機構を含み得る。したがって、機械可読ストレージ媒体は、読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスクストレージ媒体、光学式ストレージ媒体、フラッシュメモリデバイス、および同様のストレージ媒体を含み得る。

本明細書の任意のブロック図が本発明の主要な点を実施する例示的な回路の概念図を示すことは、当業者に理解されるに違いない。同様に、任意のフローチャート、流れ図、状態遷移図、擬似コードなどは、機械可読媒体内に実質的に表現され、したがって、コンピュータまたはプロセッサによって、そのようなコンピュータまたはプロセッサが明示的に図示されているか否かに関わらず実行され得るさまざまな処理を示すことが理解されるであろう。

さまざまな例示的な実施形態がそれらの実施形態の特定の例示的な態様を特に参照して詳細に説明されたが、本発明は、その他の実施形態が可能であり、本発明の詳細はさまざまな明らかな観点で修正可能であることを理解されたい。当業者に極めて明らかであるように、変更形態および修正形態は、本発明の趣旨および範囲内にとどまったまま影響を与えられる可能性がある。したがって、上述の開示、説明、および図は、例示のみを目的とするものであり、本発明を全く限定せず、本発明は、特許請求の範囲によってのみ定義される。

Claims (10)

1. 第１のデバイスからの第１の要求メッセージを処理して少なくとも１つのポリシーおよび課金制御（ＰＣＣ）規則を生成するためにポリシーおよび課金規則ノード（ＰＣＲＮ）によって実行される方法であって、
   第１の要求メッセージを受信するステップと、
   ＰＣＲＮが第１のＰＣＣ規則を生成する前に第２のデバイスからの第２のメッセージを受信するための期間を開始するためにタイマーを開始するステップであって、第２のメッセージが、第１のメッセージが示すサービスと関連するサービス要求を含むメッセージである、ステップと、
   タイマーが切れたときに、ＰＣＲＮによって受信された少なくとも第１の要求メッセージで受信された情報に少なくとも基づいて第１のＰＣＣ規則を生成するステップと、
   第１のＰＣＣ規則を少なくとも１つのゲートウェイに転送するステップと
   を含む、方法。
2. ＰＣＲＮが、期間が経過した後、第２のメッセージを受信することなしに第１のＰＣＣ規則を生成する、請求項１に記載の方法。
3. 期間が経過した後、ＰＣＲＮが第２のメッセージを受信するとき、少なくとも第１のメッセージおよび第２のメッセージで受信された情報を少なくとも用いて第２のＰＣＣ規則をＰＣＲＮによって生成するステップ
   をさらに含む、請求項２に記載の方法。
4. 少なくとも１つのゲートウェイに既に転送された第１のＰＣＣ規則をＰＣＲＮによって取り消すステップと、
   第２のＰＣＣ規則を少なくとも１つのゲートウェイにＰＣＲＮによって転送するステップと
   をさらに含む、請求項３に記載の方法。
5. 第１のＰＣＣ規則が、
   どのデバイスが第１のＰＣＣ規則を生成するためのサービス要求を開始したかを示すためのベアラ制御モード動作（ＢＣＭＯ）マーカーと、
   第１のＰＣＣ規則が、第１のメッセージの示すサービスと関連するサービス要求を含む、アプリケーションノード（ＡＮ）要求を待っているかどうかを示すためのアプリケーションノード要求待ち受け（ＷＡＮＲ）マーカーと
   を含む、請求項１に記載の方法。
6. ＰＣＲＮが、受信された第１のメッセージまたは第２のメッセージのうちの１つから導出されたサービスを用いて第１のＰＣＣ規則を生成し、第１のメッセージまたは第２のメッセージのうちの少なくとも１つが、アプリケーションノードから受信される、請求項１に記載の方法。
7. サービスフローが、第１のメッセージの示すサービスと関連するサービス要求を含む、ゲートウェイ要求をサービスフローがまだ待っているかどうかを示すためのゲートウェイ要求待ち受け（ＷＧＲ）マーカーを含む、請求項６に記載の方法。
8. 第１のデバイスからの第１の要求メッセージを処理して少なくとも１つのポリシーおよび課金制御（ＰＣＣ）規則を生成するためにポリシーおよび課金規則ノード（ＰＣＲＮ）によって実行される方法であって、
   フロー情報を含む第１の要求メッセージを受信するステップと、
   第１の要求メッセージに関連するＰａｃｋｅｔ−Ｆｉｌｔｅｒ−Ｏｐｅｒａｔｉｏｎの状態を判定するステップと、
   第１の要求メッセージに含まれるフロー情報に基づいて生成された第１のＰＣＣ規則が存在するかどうかを判定するステップと、
   サービスフローに含まれる少なくとも１つのマーカーを調べるステップと、
   第１の要求メッセージに含まれるフロー情報に基づいて生成された第１のＰＣＣ規則が存在しないときに、ＰＣＲＮによって受信された情報を用いて第１のＰＣＣ規則を生成するステップと、
   第２のデバイスからの第２のメッセージを受信するための期間を開始するタイマーを開始するステップであって、第２のメッセージが、第１のメッセージが示すサービスと関連するサービス要求を含むメッセージである、ステップと、
   第１のＰＣＣ規則を少なくとも１つのゲートウェイにプッシュするステップと
   を含む、方法。
9. 少なくとも第１の要求メッセージを処理して少なくとも１つのポリシーおよび課金制御（ＰＣＣ）規則を生成するためのポリシーおよび課金規則ノード（ＰＣＲＮ）であって、
   アプリケーションノードからの第１の要求メッセージを受信するＲｘインターフェースと、
   ゲートウェイからの第２の要求メッセージを受信するＧｘインターフェースであって、第２の要求メッセージが、第１の要求メッセージが示すサービスと関連するサービス要求を含むメッセージであり、及び、該サービスフローと相補的なフロー情報を含む、Ｇｘインターフェースと、
   ＰＣＲＮが第１のメッセージおよび第２のメッセージのうちの少なくとも１つを受信するときに、ＰＣＲＮが他方のメッセージを受信したかどうかを判定する対チェッカーと、
   ＰＣＲＮが第１のメッセージおよび第２のメッセージのうちの少なくとも１つを受信し、他方のメッセージをまだ受信していなかったときに、他方のメッセージを受信するための期間を開始するタイマーと、
   期間が経過したときに第１のメッセージおよび第２のメッセージのうちの少なくとも１つを用いてＰＣＣ規則を生成する規則プロセッサと
   を含む、ポリシーおよび課金規則ノード（ＰＣＲＮ）。
10. ＰＣＲＮが、期間が経過した後他方の要求メッセージを受信することなしに第１のＰＣＣ規則を生成する、請求項９に記載のＰＣＲＮ。

Images