JP2013527999A - 多様なメッセージの同期 - Google Patents

Abstract

様々な例示的実施形態は、多様なソースからの複数のメッセージの受信、関連付け、および同期に関する方法、および関連するネットワークノード、および機械可読記憶媒体に関する。様々な実施形態は、ポリシー課金および規則ノード（ＰＣＲＮ）が、少なくとも２つのソースから関連メッセージを受信し、受信したメッセージのセッションバインディング識別子（ＳＢＩ）に関連するロックを取得することに関する。ＰＣＲＮは、ロックを使用して、共通ＳＢＩを共有する関連要求の処理を優先順位付けすることができる。様々な実施形態は、ＰＣＲＮが、後続の関連要求がより高い優先順位のものでない限り、その後続の要求を拒否することに関する。様々な他の実施形態は、ＰＣＲＮが、第１の要求を完全に処理する前に、後続の要求の受信を待機することに関する。

Description

本明細書で開示される様々な例示的実施形態は、一般には電気通信ネットワーク内のポリシーおよび課金に関する。

モバイル電気通信ネットワーク内の様々な応用分野に対する需要が増大するにつれて、サービスプロバイダは、拡張された機能を確実に提供するために、サービスプロバイダのシステムを常に更新しなければならない。かつてはもっぱら音声通信用のシステムであったものが、最近では、一般のインターネットアクセスと共に、様々な通信プラットフォームへのアクセス、テキストメッセージング、およびマルチメディアストリーミングを可能にする異種システムに成長している。そのような応用分野をサポートするために、サービスおよびインフラストラクチャプロバイダは、既存の音声通信インフラストラクチャの上に新しいネットワークを構築している。これにより、明らかなサービス中断なしに追加の機能が可能となったが、そのようなその場しのぎの修正は、通信インフラストラクチャのための理想的な長期的解決策として働いているとは言えない。第２世代および第３世代ネットワークによって証明されているように、専用音声チャネルを介して従来型回線交換コアに向けて音声サービスを搬送しなければならず、一方、インターネットプロトコル（ＩＰ）に従う、異なるパケット交換コアを介して、ＩＰ使用可能データおよび通信などの他のサービスを伝送することができる。これにより、例えばアプリケーションプロビジョン、計量および課金、ならびにエクスペリエンス品質（ＱｏＥ）保証を含む、固有の問題が生じている。

国際電気通信連合によって定義されたモバイル電気通信規格の第２世代（２Ｇ、２．５Ｇ）および第３世代（３Ｇ）のデュアルコア手法を改善しようとする最近の１つの試みは、新しい１組の規格の形態であった。Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ（３ＧＰＰ）は、「Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ」（ＬＴＥ）とみなされる新しいネットワーク方式を推奨している。新しい規格の下では、ＬＴＥネットワーク内のすべての通信が、ＩＰチャネルを介して、携帯電話やスマートフォンなどのユーザ機器（ＵＥ）から、進化型パケットコア（ＥＰＣ）と呼ばれる全ＩＰコアに搬送される。次いで、ＥＰＣは、他のネットワークへのゲートウェイアクセスを提供することができると共に、さらに、ユーザのネットワーク活動にとって受け入れられるＱｏＥを保証し、そのような活動に関して加入者に適切に課金する。

３ＧＰＰは一般に、いくつかの技術的仕様、具体的にはＥＰＣのポリシーおよび課金規則機能（ＰＣＲＦ）、ポリシーおよび課金実施機能（ＰＣＥＦ）、ベアラバインディングおよびイベント報告機能（ＢＢＥＲＦ）などの構成要素を記述する３ＧＰＰ ＴＳ ２９．２１２、３ＧＰＰ ＴＳ ２９．２１３、および３ＧＰＰ ＴＳ ２９．２１４で、ＥＰＣの構成要素および各構成要素の互いの対話を記述する。こうした技術的仕様は、こうした構成要素間の対話に関するいくつかの詳細も与えた。こうした仕様は、ＩＰネットワークの使用に関して確実に加入者に課金すると共に、ＥＰＣがユーザに信頼性の高いデータサービスをどのように提供することができるかに関する、ある程度の手引きを与えた。

例えば、３ＧＰＰ ＴＳ ２９．２１２、３ＧＰＰ ＴＳ ２９．２１３、および３ＧＰＰ ＴＳ ２９．２１４は、ＥＰＣに特定のユーザデバイスを接続するために複数のゲートウェイを使用することができるときに接続性を処理することに関する、ある程度の手引きを与える。具体的には、仕様は、ＢＢＥＲＦやＰＣＥＦからのメッセージなどの、異なるソースからの複数のメッセージを処理することに関する、ある程度の手引きを与える。しかし、技術的仕様は、システムが多様なソースからの関連メッセージをどのように処理すべきかに関して沈黙している。

上記に鑑みて、関連メッセージを処理する能力がより高いシステムおよび方法を提供することが望ましいであろう。具体的には、複数のソースから関連メッセージを受信するときに適切な処置を取ることのできるシステムを提供することが望ましいであろう。

多様なソースからの関連メッセージを処理する方法の現在の必要に照らして、様々な例示的実施形態の簡潔な概要が提示される。以下の概要では、本発明の範囲を限定することでなく、様々な例示的実施形態のいくつかの態様を強調および紹介することを意図した、いくつかの単純化および省略が行われることがある。後のセクションでは、当業者が本発明の概念を作成および使用することを十分に可能にする好ましい例示的実施形態の詳細な説明が続く。

様々な実施形態は、複数のデバイスから受信した少なくとも２つのメッセージを処理するためにポリシーおよび課金規則ノード（ＰＣＲＮ）によって実施される方法に関するものとすることができ、この方法は、以下のうちの１つまたは複数を含む：第１のデバイスから第１の要求を受信することであって、第１の要求が、第１の加入者プロファイルに関連する少なくとも１つの属性を含む第１のセッションバインディング識別子（ＳＢＩ）に関連すること、第１の要求に関連する第１のＳＢＩを識別すること、第１のＳＢＩに関連するロックを取得することであって、ロックの取得が、他の要求によって処理を中断することができないことを示すこと、第１の要求を処理すること、第１の要求を処理したことに応答して、第１のデバイスに応答メッセージを送信すること、ロックを修正して、少なくとも１つの優先タスクの受信によって第１の要求の処理を修正できることを示すこと、少なくとも第１の要求を処理した後、得られるメッセージを少なくとも第２のデバイスに送信すること、およびロックを解除すること。

様々な他の実施形態はまた、複数のデバイスから受信した少なくとも２つのメッセージを処理するためのポリシーおよび課金規則ノード（ＰＣＲＮ）に関するものとすることができ、このＰＣＲＮは、以下のうちの１つまたは複数を含む：第１の要求を第１のデバイスから受信することであって、第１の要求が、第１の加入者プロファイルに関連する少なくとも１つの属性を含む第１のセッションバインディング識別子（ＳＢＩ）に関連すること、および第１の要求を処理したことに応答して、第１のデバイスに応答メッセージを送信することを行う第１のインターフェース、第１の要求に関連するＳＢＩを識別するメッセージメイトチェッカ、第１のＳＢＩに関連するロックを維持するロッキングデバイス、第１の要求を処理すること、ロッキングデバイスからロックを取得することであって、ロックの取得が、他の要求によって処理を中断することができないことを示すこと、ＳＢＩに関連するロックを修正して、少なくとも１つの優先タスクによって第１の要求の処理を修正できることを示すこと、およびロックを解除することを行うように構成された規則プロセッサ、ならびに少なくとも第１の要求を処理した後、得られるメッセージを少なくとも第２のデバイスに送信する第２のインターフェース。

このようにして、様々な例示的実施形態が、多様なソースから発信される複数のメッセージの動的バインディングを可能にすることが明らかなはずである。具体的には、ＰＣＲＮが多様なソースからのメッセージを同期することを可能にすることにより、システムは、可能な限り少ない待ち時間でユーザに対して完全に働くことができる。

様々な例示的実施形態をより良く理解するために、添付の図面に参照が行われる。

様々なデータサービスを提供する例示的加入者ネットワークを示す図である。 複数のソースから複数の関連メッセージを受信するＰＣＲＮに関する例示的ネットワークを示す図である。 複数のソースから受信したメッセージを処理する例示的ポリシーおよび課金規則ノード（ＰＣＲＮ）を示す図である。 アプリケーションノードによる修正要求に応答してメッセージを同期する例示的方法を示す図である。 ＵＥが開始したリソース要求に応答してメッセージを同期する例示的方法を示す図である。 ＰＣＲＮが少なくとも１つメッセージを受信することに失敗したときに、多様なソースからのメッセージを同期する例示的方法を示す図である。 第１のソースから受信したメッセージが第２のソースから受信したメッセージと競合するときに、多様なソースからのメッセージを同期する例示的方法を示す図である。

ここで図面を参照すると、同様の番号が同様の構成要素またはステップを指しており、様々な例示的実施形態の広範な態様が開示されている。

図１に、様々なデータサービスを提供する例示的加入者ネットワーク１００を示す。例示的加入者ネットワーク１００は、電気通信ネットワーク、または様々なサービスへのアクセスを実現する他のネットワークでよい。例示的加入者ネットワーク１００は、少なくとも１つのユーザ機器（ＵＥ）１１０、基地局１２０、進化型パケットコア（ＥＰＣ）１３０、パケットデータネットワーク１４０、およびアプリケーションノード（ＡＮ）１５０を含むことができる。

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

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

進化型パケットコア（ＥＰＣ）１３０は、パケットデータネットワーク１４０へのゲートウェイアクセスをＵＥ１１０に与えるデバイスまたはデバイスのネットワークでよい。ＥＰＣ１３０はさらに、提供されるデータサービスの使用に関して加入者に課金し、特定のエクスペリエンス品質（ＱｏＥ）基準が満されることを保証することができる。したがって、少なくとも部分的に、３ＧＰＰ ＴＳ ２９．２１２、２９．２１３、２９．２１４技術的仕様に従ってＥＰＣ１３０を実装することができる。したがって、ＥＰＣ１３０は、サービングゲートウェイ（ＳＧＷ）１３２、パケットデータネットワークゲートウェイ（Ｐ−ＧＷ）１３４、ポリシーおよび課金規則ノード（ＰＣＲＮ）１３６、および加入プロファイルリポジトリ（ＳＰＲ）１３８を含むことができる。

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

パケットデータネットワークゲートウェイ（Ｐ−ＧＷ）１３４は、パケットデータネットワーク１４０にゲートウェイアクセスを与えるデバイスでよい。Ｐ−ＧＷ１３４は、ユーザ機器１１０によってＳＧＷ１３２を介してパケットデータネットワーク１４０に向けて送信されるパケットを受信するＥＰＣ１３０内の最終デバイスでよい。Ｐ−ＧＷ１３４は、各サービスデータフロー（ＳＤＦ）についてポリシーおよび課金制御（ＰＣＣ）規則を実施するポリシーおよび課金実施機能（ＰＣＥＦ）を含むことができる。したがって、Ｐ−ＧＷ１３４はポリシーおよび課金実施ノード（ＰＣＥＮ）でよい。Ｐ−ＧＷ１３４は、例えば、パケットフィルタリング、ディープパケットインスペクション、加入者課金サポートなどのいくつかの追加の機能を含むことができる。

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

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

加入プロファイルリポジトリ（ＳＰＲ）１３８は、加入者ネットワーク１００への加入者に関する情報を格納するデバイスでよい。したがって、ＳＰＲ１３８は、読取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリデバイス、および／または類似の記憶媒体などの機械可読記憶媒体を含むことができる。ＳＰＲ１３８はＰＣＲＮ１３６の構成要素でよく、またはＥＰＣ１３０内の独立ノードを構成することができる。ＳＰＲ１３８によって格納されるデータは、各加入者の識別子と、帯域幅制限、課金パラメータ、加入者優先順位などの各加入者についての加入情報の表示とを含むことができる。

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

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

図２に、ＰＣＲＮが複数のデバイスから複数のメッセージを受信する例示的通信ネットワークを示す。システム２００はシステム１００と同様でよく、アプリケーションノード（ＡＮ）２０１、ポリシーおよび課金規則ノード（ＰＣＲＮ）２０２、パケットデータネットワークゲートウェイ（Ｐ−ＧＷ）２０３、および加入者プロファイルリポジトリ（ＳＰＲ）２０６が、それぞれＡＮ１５０、ＰＣＲＮ１３６、Ｐ−ＧＷ１３４、およびＳＰＲ１３８に対応する。システム２００はまた、１次サービスゲートウェイ（Ｐ−ＳＧＷ）２０４および非１次サービスゲートウェイ（ＳＧＷ）２０５をも含むことができる。

システム２００では、ＡＮ２０１、Ｐ−ＧＷ２０３、Ｐ−ＳＧＷ２０４、ＳＧＷ２０５などの複数のデバイスを通じて、複数の関連メッセージを送信することができ、各メッセージは、最終的にＰＣＲＮ２０２に送信される。次いでＰＣＲＮ２０２は、各メッセージから情報を取得し、受信したメッセージが、ＰＣＲＮ２０２が受信した何らかの他のメッセージに関係するかどうかを判定する。次いでＰＣＲＮ２０２は、共通ロックを使用して、処理関連メッセージを規制することができ、処理関連メッセージはまた、共通確立セッションを共有する関連メッセージをも含むことができる。

例えば、ＡＮ２０１は、ＡＮ２０１のセッション識別、ＩＰｖ４アドレス、少なくとも１つの加入識別子、アクセスポイント名（ＡＰＮ）などの情報を含むメッセージ（ＭＳＧ１）をＰＣＲＮ２０２に送信することができる。同様のメッセージがＩＰｖ６プレフィックスを含むこともできる。次いで、ＰＣＲＮ２０２は、ＭＳＧ１に含まれる情報を使用して、ＰＣＲＮ２０２が何らかの関連情報を以前に受信したかどうかを判定し、そうである場合、そのメッセージに関連するロックが解除されているか、それとも占有されているかを判定することができる。これにより、ＰＣＲＮ２０２が同一の構成要素内の複数のメッセージを同期することを可能にし、複数のメッセージが共通セッションを共有することを可能にすることができる。

ＰＣＲＮ２０２は、Ｓｐインターフェースを介してＳＰＲ２０６に照会することにより、ＭＳＧ１が以前に受信または格納されたメッセージに関係するかどうかを判定することができる。ＰＣＲＮ２０２によって受信される各メッセージについて、ＰＣＲＮ２０２は、セッションバインディング識別子（ＳＢＩ）を構築することができる。次いでＰＣＲＮ２０２は、メッセージのＳＢＩに含まれる属性を使用して、ＳＰＲ２０６に格納された加入者プロファイルと比較することができる。ＳＢＩは、例えばＩＰｖ４アドレス、ＩＰｖ６プレフィックス、ＡＰＮ、および／または加入識別子（複数可）含む、加入者プロファイルに含まれるすべての情報を含むことができる。しかし、メッセージのＳＢＩは、特定のメッセージ内に含まれる情報のみを有することができる。システム２００では、例えば、ＡＮ２０１からＰＣＲＮ２０２に送信されるＭＳＧ１のＳＢＩは、セッション識別子、ＩＰｖ４アドレス、ＡＰＮ、および加入識別子（複数可）のみを含むことができるが、ＳＢＩはＩＰｖ６プレフィックスを含まない。

その後で、ＰＣＲＮ２０２は、別のデバイスから別のメッセージを受信することができる。例えば、Ｐ−ＳＧＷ２０４は、ＰＣＲＮ２０２に第２のメッセージ（ＭＳＧ２）を送信することができる。第２のメッセージのＳＢＩは、ＭＳＧ１のＳＢＩとは対照的に、異なるセッション識別子、ＡＰＮ、および（恐らくは異なる）加入識別子（複数可）を含むことができる。ＰＣＲＮ２０２が２つのメッセージを直接比較する場合、ＰＣＲＮ２０２は、ＭＳＧ１およびＭＳＧ２のＳＢＩに含まれる情報が互いに直接的に合致しない（例えば、セッションと加入識別子が合致しない）ので、２つのメッセージが関係すると判定することができない。実際、直接的に合致する２つのメッセージ内の唯一の情報は、例えばＩＰｖ４アドレスであることがある。別の例では、合致することのできる唯一の値はＡＰＮであることがあり、各メッセージからの情報が同一の加入者に対応する。多くの場合には、ＰＣＲＮ２０２がＳＰＲ２０６に格納された加入プロファイルを使用するとき、ＰＣＲＮ２０２は、ＭＳＧ１とＭＳＧ２が同一の加入者プロファイルに関係し、したがってグループとしてバインドし、処理すべきであると判定することができる。このことは、例えば、ＭＳＧ１によって使用されるアプリケーションセッションをＭＳＧ２によって使用されるゲートウェイセッションにバインドすることを含むことができる。このことはまた、共通ロックを使用してＭＳＧ１およびＭＳＧ２を処理するＰＣＲＮ２０２を規制することも含むことができる。

例示的動作中に、ＰＣＲＮ２０２は、受信時に第１のメッセージＭＳＧ１の処理を直ちに開始することができる。このことは、第１のメッセージＭＳＧ１に含まれる要求を処理するためにＰＣＲＮ２０２内の複数の構成要素が行う動作のシーケンスを含むことができる。この例示的動作では、ＭＳＧ１に関係するＰＣＲＮ２０２によって第２のメッセージＭＳＧ２を受信することができ、一方ＰＣＲＮ２０２は、ＭＳＧ１を処理するためのシーケンス中の動作を依然として行っている。ＰＣＲＮ２０２は、ＭＳＧ１およびＭＳＧ２のＳＢＩを検査し、互いに比較することによってこの関係を検出することができる。ある実施形態では、ＰＣＲＮ２０２はＭＳＧ１の処理を中止し、ＭＳＧ２の処理を開始することができる。このことは、ＭＳＧ２の優先順位レベルがＭＳＧ１よりも高いためでよい。別の実施形態では、ＰＣＲＮ２０２は、ＰＣＲＮ２０２がＭＳＧ１の処理を終了するまで、ＭＳＧ２を遅延または拒否することができる。

ＰＣＲＮ２０２は、ＳＢＩに関連するロックの使用により、関連要求を処理することができる。関連メッセージが同一のＳＢＩを共有するとき、ロックを使用して、関連要求の処理を優先順位付けすることができる。ＰＣＲＮ２０２は、第１のメッセージＭＳＧ１の受信時に、ＭＳＧ１を処理するために、ＭＳＧ１のＳＢＩに関するロックを生成し、ロックを取り出すことができる。ある実施形態では、ロックが処理のためにＭＳＧ１によって保持されるので、ＰＣＲＮ２０２は、ＭＳＧ１としてＳＢＩを含む、受信した任意の後続の要求を拒否することができる。別の実施形態では、ＰＣＲＮ２０２は、ＭＳＧ１が中断できないメッセージであるので、任意の後続の要求を拒否することができる。ＰＣＲＮ２０２は、ＭＳＧ１の処理の開始時に、中断可能なメッセージまたは中断できないメッセージとなるようにＭＳＧ１のステータスを修正することができる。

別の実施形態では、ＰＣＲＮ２０２はまず、ＭＳＧ１および後続の受信したメッセージＭＳＧ２の優先順位レベルをチェックして、ＭＳＧ１の現在の処理を取り消し、ＭＳＧ２に対するロックを再割当てし、そのメッセージに関する処理を開始するかどうかを判定する。別の実施形態では、ＰＣＲＮ２０２は、ＭＳＧ１を部分的に処理し、ＭＳＧ１を完全に処理する前に、ＭＳＧ２を受信するために定義された待機期間の間待機することができる。ＭＳＧ２が到着したとき、ＰＣＲＮ２０２は、ＭＳＧ２の処理と共にＭＳＧ１の処理を完了することができる。ＰＣＲＮ２０２が後続のメッセージＭＳＧ２を決して受信しない場合、ＰＣＲＮ２０２は、待機期間が経過した後、元のメッセージＭＳＧ１の処理を完了することができる。

図３に、多様なソースからの複数の要求を処理する例示的ポリシーおよび課金規則ノード（ＰＣＲＮ）３００を示す。ＰＣＲＮ３００は、例示的加入者ネットワーク１００のＰＣＲＮ１３６および／または例示的システム２００のＰＣＲＮ２０２に対応することができる。ＰＣＲＮ３００は、Ｒｘインターフェース３０１、タイマ３０３、規則ストレージ３０５、メッセージメイトチェッカ３０７、Ｓｐインターフェース３０９、規則ジェネレータ３１１、Ｇｘインターフェース３１３、Ｇｘｘインターフェース３１５、およびロッキングモジュール３１７を含むことができる。

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

タイマ３０３は、ＰＣＲＮ３００が第１のサービス要求メッセージを受信した後、第２のメイトサービス要求メッセージが到着するのをＰＣＲＮ３００が待機する期間をトリガするように構成されたハードウェアおよび／または機械可読記憶媒体上の実行可能命令を含むことができる。タイマ３０３は、ＰＣＲＮ３００でのタスクに関するセットクロック周期を使用して、第２のメッセージを明示的に待機することができる。代替実施形態では、タイマ３０３は、ＰＣＲＮ３００をトリガして、タスクを処理する優先順位を実行キューの後ろに配置することによってタスクの処理を遅延することができる。そのような場合、ＰＣＲＮ３００は、その実行キュー内の優先順位のより高い他の機能を実行することにより、ある期間、受動的に「待機する」。タスクが実行キュー内で再び生じるとき、ＰＣＲＮ３００は再び、第２のメイトサービス要求メッセージが実際に到着したかどうかを判定するためにチェックすることができる。そうでない場合、ＰＣＲＮ３００は、メイトメッセージなしにタスクを処理することができる。

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

メッセージメイトチェッカ３０７は、複数のインターフェースからメッセージを受信し、メッセージがメイトであるかどうかを判定するように構成されたハードウェアおよび／または機械可読記憶媒体上の実行可能命令を含むことができる。ＵＥ１１０は、複数のデバイスに補足的メッセージを送信することができる。こうしたメッセージは複数の情報を含むことができ、情報は、補足的メッセージを予期しているかどうかに関する表示を少なくとも含むことができる。したがって、メッセージメイトチェッカ３０７は、マッチングアプリケーションノード（ＡＮ）要求またはゲートウェイ要求の形態のマッチングメッセージがあるかどうかを判定することにより、少なくとも２つのメッセージを相関させることができる。メッセージを規則ジェネレータ３１１によって処理することができ、得られる規則は、ＰＣＲＮ３００が別のデバイスからマッチングメッセージを受信するまで、規則ストレージ３０７に格納される。

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

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

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

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

ロッキングデバイス３１７は、ＰＣＲＮ３００によって追跡される各ＳＢＩに関連するロックを作成および制御するように構成されたハードウェアおよび／または機械可読記憶媒体上に符号化された実行可能命令を含むデバイスでよい。例えば、Ｒｘインターフェース３０１、Ｇｘインターフェース３１３、またはＧｘｘインターフェース３１５を通じて要求を受信するとき、着信メッセージはＳＢＩを含むことができる。ロッキングデバイス３１７は、その特定のＳＢＩに関連するロックを生成することができる。例示的動作中、規則ジェネレータ３１１は、ＳＢＩに関連する要求を処理するとき、ＳＢＩに関連するロックをチェックアウトすることができる。その後で、ＰＣＲＮ３００が同一のＳＢＩに関連する別の要求を受信する場合、規則ジェネレータ３１１がロッキングデバイス３１７にロックを解除するまで、規則ジェネレータ３１１は、この後続のメッセージの処理を停止することができる。このことは、要求を処理すること、および生成したＰＣＣ規則を例えばＰ−ＧＷ２０３などのデバイスに転送することのどちらも含むことができる。このことはまた、生成または修正したＰＣＣ規則を規則ストレージ３０５に格納することをも含むことができる。

図４に、アプリケーションノードによる修正要求に応答してメッセージを同期する例示的方法を示す。方法４００は、システム１００およびシステム２００の構成要素と同様の構成要素間の対話を含むいくつかのステップを含むことができる。各ライフライン４０１−４０７についての活動化ボックス（すなわち方法呼出しボックス）の長さは、他の活動化ボックスに対して相対的なものであることがあり、縮尺通りでないことがある。方法４００で使用される構成要素は、アプリケーションノード（ＡＮ）４０１、パケットデータネットワークゲートウェイ（Ｐ−ＧＷ）４０３、ポリシーおよび課金規則ノード（ＰＣＲＮ）４０５、ロッキングデバイス４０７を含むことができる。ロッキングデバイス４０７は、ＰＣＲＮ４０５内部の構成要素でよい。別々には列挙されないＰＣＲＮ４０５内の構成要素により、ＰＣＲＮ４０５によって実施される動作を行うことができる。

方法４００はステップ４１０で始まり、ステップ４１０では、ＡＮ４０１がＰＣＲＮ４０５にメッセージを送信する。メッセージはＲｘ ＡＡ−Ｒｅｑｕｅｓｔ（ＡＡＲ）の形態でよい。次いでステップ４１２で、ＰＣＲＮ４０５は、受信したアプリケーションメッセージからセッションバインディング識別子（ＳＢＩ）を求めることができる。ＡＡＲがメッセージに含まれる場合、ＡＡＲからＳＢＩを抽出することができる。別の実施形態では、ＰＣＲＮ４０５は、ＡＡＲ内のｄｉａｍｅｔｅｒ−ｓｅｓｓｉｏｎ−ｉｄを使用して、対応するＡＦセッションを見つけることにより、アプリケーションメッセージに関連するＳＢＩを求めることができる。次いで、ＰＣＲＮ４０５は、ＡＦセッションからＳＢＩを抽出することができる。

ステップ４１４では、ＰＣＲＮ４０５は、ロッキングデバイス４０７からロックを取得することができる。ＰＣＲＮ４０５は、アプリケーションメッセージに関連するＳＢＩに関連するロックを取得するように試みることができる。ロックが解除されていない場合、ロッキングデバイス４０７は要求を拒否することができ、ロックがロッキングデバイス４０７に解除されるまで、ＰＣＲＮ４０５は、アプリケーション要求の処理を開始することができない。そうではなく、ロックが解除されている場合、ステップ４１６で、ＰＣＲＮ４０５は、ロッキングデバイス４０７からロックを取得することができる。ある実施形態では、ＰＣＲＮ４０５は、規則プロセッサがロックを取得したメッセージを処理しているが、受信したアプリケーションメッセージがより高い優先順位であるとき、例えば規則ジェネレータ３１１などの別の構成要素からロックを取得することができる。取得したロックは、受信したアプリケーションメッセージの処理を他の要求によって中断することができないことを示す。ある実施形態では、後続の受信したメッセージの優先順位レベルがアプリケーションメッセージの優先順位レベルよりも高い場合にのみ、処理を中断することができる。

ステップ４１８では、ＰＣＲＮ４０５はアプリケーションメッセージを処理することができる。ある実施形態では、ＰＣＲＮ４０５は、アプリケーションメッセージの処理を完了しないことがある。このことは例えば、より高い優先順位の要求を受信しているためであることがある。別の実施形態では、アプリケーションメッセージがＰＣＲＮ４０５に関連メッセージを待機させるとき、処理を停止することができる。そのような場合、ＰＣＲＮ４０５は、待機期間の間、後続のメッセージを受信するために待機し、後続のメッセージが到着したとき、アプリケーションメッセージの処理を完了することができる。ＰＣＲＮ４０５は、関連メッセージ内の情報を使用して、アプリケーションメッセージの処理を完了することができる。アプリケーションメッセージの処理が完了したとき、ステップ４２０で、ＰＣＲＮ４０５は、ＡＡ−Ａｎｓｗｅｒ（ＡＡＡ）の形態の応答をＡＮ４０１に返す。

ステップ４２２で、ＰＣＲＮ４０５は、アプリケーションメッセージに関連するロックを修正することができる。ＰＣＲＮ４０５は、ロックを修正して、アプリケーションメッセージの処理を優先順位メッセージによって中断できることを示すことができる。優先順位メッセージは、ＡＦセッション終了要求、またはＩＰ−ＣＡＮセッション終了要求を含むメッセージを含むことができる。これは処理時間を節約することができる。関連するセッションが終了を要求している場合、アプリケーションメッセージを完全に処理する必要がないからである。

ステップ４２４では、ＰＣＲＮ４０５は、ＡＮ４０１によって要求されるリソース変更を反映するメッセージをＰ−ＧＷ４０３に送信することができる。ＰＣＲＮ４０５によってＰ−ＧＷ４０３に送信されるメッセージは、Ｇｘ Ｒｅ−Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｒｅｑｕｅｓｔ（ＲＡＲ）の形態でよく、アプリケーションメッセージを処理した結果を含むことができる。ＲＡＲの内容は、例えば、少なくともアプリケーションメッセージ内の情報を使用して生成されたポリシーおよび課金制御（ＰＣＣ）規則を含むことができる。ステップ４２６で、Ｐ−ＧＷ４０３は、ＰＣＲＮ４０５にメッセージを返信することによって応答することができる。ＰＣＲＮ４０５によって受信されるメッセージは、Ｇｘ Ｒｅ−Ａｕｔｈｏｒｉｚａｔｉｏｎ Ａｎｓｗｅｒ（ＲＡＡ）の形態でよい。Ｐ−ＧＷ４０３から応答を受信した後、次いでステップ４２８で、ＰＣＲＮ４０５は、ロッキングデバイス４０７にロックを解除する。

図５に、ＵＥが開始したリソース要求に応答してメッセージを同期する例示的方法を示す。方法５００は、方法４００のステップと同様のステップを含むことができる。方法５００はまた、方法４００で使用される構成要素と同様の構成要素を使用することができ、ＡＮ５０１、Ｐ−ＧＷ５０３、ＰＣＲＮ５０５、およびロッキングデバイス５０７が、同様に番号付けされた構成要素４０１−４０７に対応する。方法５００はまた、将来タスクモジュール５０９も使用することができ、将来タスクモジュール５０９は、ＰＣＲＮ５０５内の別々の構成要素でよい。将来タスクモジュールは、別々のハードウェアデバイスまたは規則ジェネレータ３１１の構成要素でよい。

ステップ５１０から始めて、方法５００のステップ５１０−５１８は、方法４００のステップ４１０−４１８に相関し、ステップ５１０−５１８では、ＰＣＲＮ５０５がＡＮ５０１からＡＡＲを受信し、受信したメッセージに関連するＳＢＩを取り出し、取り出したＳＢＩに関連するロックを取得するように試み、ロックが取得されたとき、メッセージの処理を開始する。

ステップ５２０で、ＰＣＲＮ４０５は、将来タスクモジュール５０９で将来タスクを作成する。将来タスクは、定義された期間の間待機し、ＰＣＲＮ５０５がアプリケーションメッセージと同一のＳＢＩを有するＰ−ＧＷ５０３からクレジットおよび制御要求（ＣＣＲ）を受信したかどうかをチェックする役割を有する。対応するゲートウェイメッセージが到着した場合、将来タスクは、アプリケーションメッセージの処理を中断し、ゲートウェイメッセージを処理することができる。そうではなく、ＰＣＲＮ４０５が対応するゲートウェイメッセージを受信しないとき、ＰＣＲＮ４０５は、アプリケーションメッセージの処理を終了し、Ｐ−ＧＷ５０３にＡＡＲを送信することができる。ステップ５２２はステップ４２０に対応することができ、ステップ５２２では、ＰＣＲＮはＡＮ５０１にＡＡＡを返す。

ステップ５２４では、将来タスクモジュール５０９が、ロッキングデバイス５０７内のロックを修正する。将来タスクモジュール５０９は、ロックを修正して、優先メッセージ（ｓｕｐｅｒｓｅｄｉｎｇ ｍｅｓｓａｇｅ）によってアプリケーションメッセージの処理を修正できることを示すことができる。優先メッセージは、より高い優先順位の要求を含むことができ、より高い優先順位の要求は、例えば、ＡＦセッション終了、ＩＰ−ＣＡＮセッション要求、またはロックのＳＢＩに関連するＧｘ ＣＣＲ要求を含むことができる。将来タスクモジュール５０９はまた、ロックが取得されたときはいつでも、ロックを修正して、将来タスクモジュール５０９に通知することができる。次いでロックは、例えば、対応するゲートウェイメッセージが到着し、その後でロックを取得したとき、将来タスクモジュール５０９に通知することができる。したがって、通知は、後続の関連メッセージが到着したことを将来タスクモジュールに示すことができる。

ステップ５２６で、将来タスクモジュール５０９は、定義された期間の間、ＰＣＲＮ５０５が対応するゲートウェイメッセージを受信するのを待機することができる。将来タスクモジュール５０９はタイマを使用して、定義された待機期間の間待機することができる。別の実施形態では、将来タスクモジュールは、ＰＣＲＮ５０５がその実行キュー内の前の動作を処理するのにかかる時間によって待機期間を定義することができるように、ＰＣＲＮ５０５の実行キューの終わりにタスクをスケジュールする。ステップ５２８で、ＰＣＲＮ５０５は、対応するゲートウェイメッセージを受信し、対応するゲートウェイメッセージはＧｘ ＣＣＲ要求でよい。ＰＣＲＮ５０５は、例えばメッセージがマッチングＳＢＩを有することを判定することにより、受信したゲートウェイメッセージがアプリケーションメッセージに対応することを判定することができる。

ステップ５２４で、対応するゲートウェイメッセージによる中断を許可するようにロックが修正されたので、ステップ５３０で、ＰＣＲＮ５０５は、アプリケーションメッセージによって保持されるロックを取得する。このことは、ＰＣＲＮ５０５がアプリケーション要求の処理を完了した後に行うことができる。優先順位メッセージのみによってゲートウェイメッセージの処理を中断することができるようにロックを修正することもできる。そのような優先順位メッセージは、例えば、ＡＦセッション終了要求やＩＰ−ＣＡＮセッション終了要求などの要求を含むことができる。ステップ５３２で、ロッキングデバイス５０７が、ロックがゲートウェイメッセージによって取得されたことを将来タスクモジュール５０９に通知することができる。次いでステップ５３４で、将来タスクモジュール５０９は将来タスクを終了する。

ステップ５３６で、ＰＣＲＮ５０５はゲートウェイメッセージを処理することができる。ＰＣＲＮ５０５は、例えばＣＣＲメッセージおよび前に処理したＡＡＲ内に含まれる情報を使用して、ゲートウェイ要求を処理することができる。ＰＣＲＮ５０５は、ＣＣＲを使用して新しいＰＣＣ規則を作成することができ、または既存のＰＣＣ規則を修正することができる。ステップ５３８で、ＰＣＲＮ５０５は、Ｐ−ＧＷ５０３にメッセージを返す。メッセージは課金および制御応答（ＣＣＡ）の形態でよく、新しいＰＣＣ規則または修正されたＰＣＣ規則を含むことができる。次いでステップ５４０で、ＰＣＲＮ５０５は、ロッキングデバイス５０７にロックを解除する。

図６に、ＰＣＲＮが少なくとも１つメッセージを受信することに失敗したときに、多様なソースからのメッセージを同期する例示的方法を示す。方法６００は、方法４００、５００のステップと同様のステップを含む。方法６００はまた、方法４００、５００で使用される構成要素と同様の構成要素を使用することができ、ＡＮ６０１、Ｐ−ＧＷ６０３、ＰＣＲＮ６０５、およびロッキングデバイス６０７が、それぞれ同様に番号付けされた構成要素４０１−４０７および５０１−５０９に対応する。

ステップ６１０から始めて、方法６００のステップ６１０−６２６は、方法５００のステップ５１０−５２６に相関し、ステップ６１０−６２６では、ＰＣＲＮ６０５がＡＮ６０１からＡＡＲを受信し、受信したメッセージに関連するＳＢＩを取り出し、取り出したＳＢＩに関連するロックを取得するように試み、ロックが取得されたとき、メッセージの処理を開始する。将来タスクモジュール６０９が将来タスクを作成し、次いでＰＣＲＮ６０５は、ＡＮ６０１に応答を返す。将来タスクは、ロックを修正して、処理が優先メッセージによって中断できることを示す。次いで、将来タスクは、対応するゲートウェイメッセージが到着するのを待機する。

しかし、ステップ６２８で、ＰＣＲＮ６０５が対応するゲートウェイメッセージを受信することなく、待機期間が満了する。したがって、ステップ６３０で、将来タスクモジュール６０９は、Ｐ−ＧＷ６０３にメッセージを送信することができる。メッセージはＧｘ ＲＡＲの形態でよく、ゲートウェイメッセージに含まれる情報なしに作成されたＰＣＣ規則を含むことができる。ＰＣＣ規則は、アプリケーション要求を処理するときに作成されたＰＣＣ規則でよい。ステップ６３２で、Ｐ−ＧＷ６０３は、将来タスクモジュール６０９にＧｘ ＲＡＡの形態のメッセージを返すことができる。次いでステップ６３４で、将来タスクモジュール６０９は、ロッキングデバイス６０７にロックを解除することができる。

図７に、第１のソースから受信したメッセージが第２のソースから受信したメッセージと競合するときに、多様なソースからのメッセージを同期する例示的方法を示す。方法７００は、方法４００のステップと同様のステップを含むことができる。方法７００はまた、方法４００で使用される構成要素と同様の構成要素を使用することができ、ＡＮ７０１、Ｐ−ＧＷ７０３、ＰＣＲＮ７０５、およびロッキングデバイス７０７が、同様に番号付けされた構成要素４０１−４０７に対応する。

ステップ７１０から始めて、方法７００のステップ７１０−７２２は、方法４００のステップ４１０−４１８に相関することができ、ステップ７１０−７２２では、ＰＣＲＮ７０５がＡＮ７０１からＡＡＲを受信し、受信したメッセージに関連するＳＢＩを取り出し、取り出したＳＢＩに関連するロックを取得するように試み、ロックが取得されたとき、メッセージの処理を開始する。次いで、ＰＣＲＮ７０５は、受信したメッセージの処理を開始した後、ＡＮ７０１にＡＡＡを送信することができる。次いで、ＰＣＲＮ７０５は、ロックを修正して、アプリケーション要求の処理を優先順位メッセージによって中断できることを示すことができ、優先順位メッセージは、例えば、ＡＦセッション終了要求またはＩＰ−ＣＡＮセッション終了要求を含むことができる。

ステップ７２４で、ＰＣＲＮ７０５は、Ｐ−ＧＷ７０３からメッセージを受信する。ＰＣＲＮ７０５によって受信されるゲートウェイメッセージはＧｘ ＣＣＲの形態でよく、イベント通知を含むことができる。この通知は、処理を開始する要求でよい。ステップ７２６のＰＣＲＮ７０５は、ＣＣＲ要求からＳＢＩを抽出することにより、受信したゲートウェイメッセージのＳＢＩを取得することができる。ステップ７２６はステップ７１２と相関することができ、ステップ７２６では、ＰＣＲＮ７０５が、例えばｄｉａｍｅｔｅｒ−ｓｅｓｓｉｏｎ−ｉｄを使用して、対応するＩＰ−ＣＡＮセッションを見つけ、次いでＩＰ−ＣＡＮセッションからＳＢＩを抽出することにより、ＳＢＩを取得するように試みることができる。ＳＢＩを取得した後、ステップ７２８で、ＰＣＲＮは、ロッキングデバイス７０７からロックを取得するように試みることができる。

ステップ７３０で、ＣＣＲ要求が優先タスクではなかった可能性があり、したがってアプリケーション要求の処理を中断することができなかった可能性があるので、ＰＣＲＮ７０５は、ロッキングデバイス７０７０からロックを取得することに失敗することがある。したがって、ステップ７３２で、ＰＣＲＮ７０５は、要求を処理することができなかったことを示すメッセージをＧｘ ＣＣＡの形態でＰ−ＧＷ７０３に返す。

ステップ７３４で、ＰＣＲＮ７０５は、Ｐ−ＧＷ７０３に後続のメッセージを送信することができる。後続のメッセージはＧｘ ＲＡＲの形態でよい。後続のメッセージは、ＡＮ７０１によってそのアプリケーションメッセージで要求されるリソース変更を含むことができる。そのようなリソース変更は、例えば、ＰＣＣ規則の生成または修正を含むことができる。次いで、ＰＣＲＮ７０５は、Ｐ−ＧＷ７０３からＧｘ ＲＡＡの形態で応答を受信することができる。次いでステップ７３８で、ＰＣＲＮ７０５は、ロッキングデバイス７０７にロックを解除する。

上記に従って、様々な例示的実施形態が、ＰＣＲＮによって受信されたときに、多様なソースからのメッセージの動的関連付けおよび同期を実現する。具体的には、各着信メッセージに含まれる固有セッションバインディング識別子（ＳＢＩ）に関連するロックを使用することにより、ＰＣＲＮは、関連メッセージの処理を適時に調整することができ、異なる優先順位レベルを有する関連メッセージを処理することができ、したがって処理時間およびリソースを節約する。

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

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

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

Claims (11)

1. 複数のデバイスから受信した少なくとも２つのメッセージを処理するためにポリシーおよび課金規則ノード（ＰＣＲＮ）によって実施される方法であって、
   第１のデバイスから第１の要求を受信することであって、第１の要求が、第１の加入者プロファイルに関連する少なくとも１つの属性を含む第１のセッションバインディング識別子（ＳＢＩ）に関連すること、
   第１の要求に関連する第１のＳＢＩを識別すること、
   第１のＳＢＩに関連するロックを取得することであって、ロックの取得が、他の要求によって処理を中断することができないことを示すこと、
   第１の要求を処理すること、
   第１の要求を処理したことに応答して、第１のデバイスに応答メッセージを送信すること、
   ロックを修正して、少なくとも１つの優先タスクの受信によって第１の要求の処理を修正できることを示すこと、
   少なくとも第１の要求を処理した後、得られるメッセージを少なくとも第２のデバイスに送信すること、および
   ロックを解除すること
   を含む、方法。
2. 第１の要求に関連するＳＢＩの識別が、
   第１の要求に対する、対応するセッションを見つけることであって、第１の要求に含まれるｄｉａｍｅｔｅｒ−ｓｅｓｓｉｏｎ−ｉｄを使用することをさらに含むこと、および
   対応するセッションからセッションＳＢＩを抽出することであって、セッションＳＢＩが第１のＳＢＩと同等であること
   をさらに含む、請求項１に記載の方法。
3. 将来タスクを生成することをさらに含み、将来タスクが、
   ロックを修正して、少なくとも１つの優先タスクによって処理を中断できることを示すことであって、優先タスクが生じた場合、将来タスクが通知を受けること、
   定義された期間の間待機すること、
   第２のデバイスからの第２の要求の受信をチェックすることであって、第２の要求が第１のＳＢＩに関連すること、および
   第２の要求が到着しないとき、得られるメッセージを第２のデバイスに送信することであって、得られるメッセージが、第２のデバイスから情報を受信することなく作成されること
   を行う、請求項１に記載の方法。
4. 第２のデバイスから第２の要求を受信することであって、第２の要求が第１のＳＢＩに関連すること、
   第１の要求からロックを取得すること、
   ロックを修正して、少なくとも１つの優先タスクの受信によって第２の要求の処理を修正できることを示すこと、
   第２の要求がロックを取得したことを将来タスクに通知すること、
   将来タスクを終了すること、
   第２の要求を処理すること、および
   第２の要求を処理した後、得られるメッセージを少なくとも第２のデバイスに送信すること
   をさらに含む、請求項３に記載の方法。
5. 第２のデバイスから第２の要求を受信することであって、第２の要求が第１のＳＢＩに関連すること、
   第２の要求に関連する第２のＳＢＩを識別することであって、第２のＳＢＩが第１のＳＢＩと同等であること、
   第１のＳＢＩに関連するロックを取得するように試みること、
   第１のＳＢＩに関連するロックを取得する試行が失敗したとき、第２の要求を処理できないことを示す失敗メッセージを返すこと、および
   失敗メッセージに応答して、第２のデバイスから失敗応答を受信すること
   をさらに含む、請求項１に記載の方法。
6. 複数のデバイスから受信した少なくとも２つのメッセージを処理するポリシーおよび課金規則ノード（ＰＣＲＮ）であって、
   第１のデバイスから第１の要求を受信することであって、第１の要求が、第１の加入者プロファイルに関連する少なくとも１つの属性を含む第１のセッションバインディング識別子（ＳＢＩ）に関連すること、および第１の要求を処理したことに応答して、第１のデバイスに応答メッセージを送信することを行う第１のインターフェースと、
   第１の要求に関連するＳＢＩを識別するメッセージメイトチェッカと、
   第１のＳＢＩに関連するロックを維持するロッキングデバイスと、
   規則プロセッサであって、
   第１の要求を処理すること、
   ロッキングデバイスからロックを取得することであって、ロックの取得が、他の要求によって処理を中断することができないことを示すこと、
   ＳＢＩに関連するロックを修正して、少なくとも１つの優先タスクによって第１の要求の処理を修正できることを示すこと、および
   ロックを解除すること
   を行う規則プロセッサと、
   少なくとも第１の要求を処理した後、得られるメッセージを少なくとも第２のデバイスに送信する第２のインターフェースと
   を備える、ＰＣＲＮ。
7. メッセージメイトチェッカによる第１の要求に関連するＳＢＩの識別が、
   第１の要求に対する、対応するセッションを見つけることであって、第１の要求に含まれるｄｉａｍｅｔｅｒ−ｓｅｓｓｉｏｎ−ｉｄを使用することをさらに含むこと、および
   対応するセッションからセッションＳＢＩを抽出することであって、セッションＳＢＩが第１のＳＢＩと同等であること
   をさらに含む、請求項６に記載のＰＣＲＮ。
8. 将来タスクを生成する将来タスクモジュールをさらに備え、将来タスクが、
   ロックを修正して、少なくとも１つの優先タスクによって処理を中断できることを示すことであって、優先タスクが生じた場合、将来タスクが通知を受けること、
   ある期間の間待機すること、
   第２のデバイスからの第２の要求の受信をチェックすることであって、第２の要求が第１の要求に対応すること、および
   第２の要求が到着しないとき、第２のデバイスに紛失要求を送信することであって、紛失要求が、第２のデバイスから情報を受信することなく第２のデバイスに送信される要求を含むこと
   を行う、請求項６に記載のＰＣＲＮ。
9. 第２のインターフェースが、第２のデバイスから第２の要求を受信し、第２の要求が第１のＳＢＩに関連し、
   規則プロセッサが、第１の要求からロックを取得し、ロックを修正して、優先タスクによって第１の要求を修正できることを示し、第２の要求がロックを取得したことを将来タスクに通知し、第２の要求を処理し、
   将来タスクモジュールが将来タスクを終了し、
   第２のインターフェースが、第２の要求を処理した後、第２のデバイスに応答を送信する、請求項８に記載のＰＣＲＮ。
10. 第２のインターフェースが、第２のデバイスから第２の要求を受信し、第２の要求が第１のＳＢＩに関連し、
    メッセージメイトチェッカが、第２の要求に関連する第２のＳＢＩを識別し、第２のＳＢＩが第１のＳＢＩと同等であり、
    規則プロセッサが、第１のＳＢＩに関連するロックを取得するように試み、第１のＳＢＩに関連するロックを取得する試行が失敗したとき、第２の要求を処理できないことを示す失敗メッセージを返し、第１の要求を処理した後、第２のデバイスに要求を送った後、第２のデバイスから第２の応答を受信する、請求項６に記載のＰＣＲＮ。
11. 定義された期間が、規則プロセッサの実行キューの終わりに将来タスクをスケジュールすることによって定義される、請求項１５に記載のＰＣＲＮ。