JP5475189B2 - 発信メッセージの失敗を管理するためのフレームワーク - Google Patents

Description

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

移動通信ネットワークにおける様々なタイプのアプリケーションに対する要望が増すのに従い、サービスプロバイダは、拡張機能性を確実に提供するために、プロバイダ自身のシステムを絶えずアップグレードしている。かつては音声通信のためだけに設計されたシステムだったものは、多目的ネットワークアクセスポイントになり、テキストメッセージ通信、マルチメディアストリーミング、および一般インターネットアクセスを含む、無数のアプリケーションへのアクセスを提供するようになった。このようなアプリケーションをサポートするために、プロバイダは、自社の既存音声ネットワークの上に、新たなネットワークを構築した。第２および第３世代ネットワークに見られるように、音声サービスは、専用の音声チャネルを介して搬送され、回路交換コアに向けられなければならないが、他のサービス通信は、インターネットプロトコル（ＩＰ）に従って送信され、異なるパケット交換コアに向けられる。このことが、アプリケーションプロビジョニング、測定および課金、ならびに体感品質（ＱｏＥ）保証に関する特有の問題につながった。

第２および第３世代のデュアルコア手法を簡単にすることを目指して、第３世代パートナーシッププロジェクト（３ＧＰＰ）は、３ＧＰＰが「ロングタームエボリューション」（ＬＴＥ）と呼ぶ新たなネットワーク方式を推奨している。ＬＴＥネットワークでは、すべての通信が、ユーザ機器（ＵＥ）から、進化型パケットコア（ＥＰＣ）と呼ばれる全ＩＰコアに、ＩＰチャネルを介して搬送される。ＥＰＣは次いで、他のネットワークへのゲートウェイアクセスを提供するとともに、受容可能ＱｏＥを確保し、加入者の特定のネットワーク活動の料金を加入者に課す。

３ＧＰＰは概して、いくつかの技術仕様において、ＥＰＣの構成要素および構成要素相互の対話について記載している。具体的には、３ＧＰＰ ＴＳ ２９．２１２、３ＧＰＰ ＴＳ ２９．２１３、および３ＧＰＰ ＴＳ ２９．２１４は、ＥＰＣのポリシーおよび課金規則機能（ＰＣＲＦ）、ポリシーおよび課金施行機能（ＰＣＥＦ）、ならびにベアラバインディングおよびイベント報告機能（ＢＢＥＲＦ）について記載している。こうした仕様は、こうした要素が、信頼できるデータサービスを提供し、加入者にサービス使用料金を課すためにどのように対話するかに関して、何らかの指針をさらに提供する。

たとえば、３ＧＰＰ ＴＳ ２９．２１２および３ＧＰＰ ＴＳ ２９．２１４は、ＥＰＣに関連づけられた様々な要素におけるＰＣＲＦによって、規則のインストールに関する何らかの指針を提供する。こうした標準は、ある要素が、ある規則のインストールのエラーに遭遇したとき、このエラーをＰＣＲＦに報告するべきであると規定している。その後、ＰＣＲＦは、その規則が運用可能でない可能性があるので、他のすべての関連要素に、規則をアンインストールするよう命令するべきである。このプロセスは、しかしながら、失敗した規則が他の要素においてインストールされたままでないようにするプロセスに対して、かなりの量のオーバーヘッドを引き起こす。

３ＧＰＰ ＴＳ ２９．２１２ ３ＧＰＰ ＴＳ ２９．２１３ ３ＧＰＰ ＴＳ ２９．２１４

上記に鑑みて、規則をインストールする、堅牢で効率的なシステムを提供することが望ましいであろう。特に、失敗した規則インストールなどの失敗の扱いに関連した処理オーバーヘッドを最小限にするシステムを提供することが望ましいであろう。

規則をインストールする、堅牢で効率的なシステムの本必要性に鑑み、様々な例示的実施形態の手短な概要が提示される。以下の概要では、いくつかの簡略化および省略が行われる場合があるが、これは、様々な例示的実施形態のいくつかの態様を強調し紹介することを意図しているのであって、本発明の範囲を限定することは意図していない。当業者が本発明の概念を組み立て、用いることを可能にするのに適した好ましい例示的実施形態の詳細な説明が、以降のセクションにおいて続く。

様々な例示的実施形態は、ポリシーおよび課金規則ノード（ＰＣＲＮ）において、第１のサービスデータフロー（ＳＤＦ）の確立を求める要求を要求側ノードから受信すること、要求に応答して第１のＳＤＦを実行するための第１の規則セットを生成すること、規則セットのうち第１の規則を、第１の規則のインストールのために第１のノードに送信すること、一定の期間、第１のノードからの応答を待つこと、第１のノードにおける第１の規則のインストールが失敗したか、それとも成功したかを応答から判断すること、および第１の規則のインストールが成功した場合、第１の規則セットのうち第２の規則を、第２の規則のインストールのために第２のノードに送信することのうちの１つまたは複数を含む方法および関連ネットワークノードに関する。

上記によれば、システムが、失敗した規則インストールなどの失敗の扱いに関連した処理オーバーヘッドを最小限にする。特に、少なくともいくつかの送信メッセージへの応答を待つことによって、ＰＣＲＮは、失敗の知らせにインテリジェントに応答し、失敗によって不必要または無益にされる命令または他のアクションを排除することができる。

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

様々なデータサービスを提供する例示的な加入者ネットワークを示す図である。 様々なノードにおいて、規則をインストールし、次いで、失敗した規則をアンインストールするための例示的なメッセージ交換を示す図である。 発信メッセージの失敗を管理する例示的なポリシーおよび課金規則ノード（ＰＣＲＮ）を示す図である。 発信メッセージの失敗を管理するための例示的なメッセージ交換を示す図である。 様々なノードにメッセージを送信するための例示的な汎用メッセージツリーを示す図である。 様々なノードにおいて規則をインストールするための例示的なメッセージツリーを示す図である。 様々なノードにおいて規則をアンインストールするための例示的なメッセージツリーを示す図である。 規則インストールの失敗を管理するための例示的なメッセージツリーを示す図である。 メッセージツリーをマージするための例示的なデータ配置を示す図である。 発信メッセージの失敗を管理する例示的な方法を示す図である。 メッセージグループをマージする例示的な方法を示す図である。

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

図１は、様々なデータサービスを提供する例示的な加入者ネットワーク１００を示す。例示的な加入者ネットワーク１００は、様々なサービスへのアクセスを提供する、ＬＴＥまたは４Ｇ移動通信ネットワークなどの通信ネットワークであり得る。ネットワーク１００は、ユーザ機器１１０、基地局１２０、進化型パケットコア（ＥＰＣ）１３０、パケットデータネットワーク１４０、およびアプリケーション機能（ＡＦ）１５０を含み得る。

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

基地局１２０は、ユーザ機器１１０とＥＰＣ１３０との間の通信を可能にする装置であり得る。たとえば、基地局１２０は、３ＧＰＰ標準で定義される進化型ノードＢ（ｅノードＢ）などの送受信基地局でもよい。したがって、基地局１２０は、無線波など、第１の媒体を介してユーザ機器１１０と通信するとともに、イーサネット（登録商標）ケーブルなど、第２の媒体を介してＥＰＣ１３０と通信する装置であり得る。基地局１２０は、ＥＰＣ１３０と直接通信することもでき、いくつかの中間ノード（図示せず）を介して通信することもできる。様々な実施形態において、複数の基地局（図示せず）が、ユーザ機器１１０に移動性を提供するために存在してもよい。様々な代替実施形態において、ユーザ機器１１０は、ＥＰＣ１３０と直接通信し得ることに留意されたい。このような実施形態では、基地局１２０は存在しなくてもよい。

進化型パケットコア（ＥＰＣ）１３０は、パケットデータネットワーク１４０へのゲートウェイアクセスをユーザ機器１１０に提供する装置でも、装置の集合体でもよい。ＥＰＣ１３０はさらに、提供されたデータサービスの使用料金を加入者に課し、特定の体感品質（ＱｏＥ）標準が確実に満たされるようにすることができる。したがって、ＥＰＣ１３０は、少なくとも部分的には、３ＧＰＰ ＴＳ ２９．２１２、２９．２１３、および２９．２１４標準に従って実装すればよい。したがって、ＥＰＣ１３０は、サービングゲートウェイ（ＳＧＷ）１３２、パケットデータネットワークゲートウェイ（ＰＧＷ）１３４、ポリシーおよび課金規則ノード（ＰＣＲＮ）１３６、ならびに加入プロファイルリポジトリ（ＳＰＲ）１３８を含み得る。あるいは、ＥＰＣ１３０は、当業者に知られている他の任意のパケットコアでもよい。

一次サービングゲートウェイ（Ｐ−ＳＧＷ）１３２は、ＥＰＣ１３０へのゲートウェイアクセスをネットワーク１００のエンドユーザに提供する装置であり得る。Ｐ−ＳＧＷ１３２は、ユーザ機器１１０によって送られたパケットを受信する、ＥＰＣ１３０内の最初の装置とすることができる。Ｐ−ＳＧＷ１３２は、このようなパケットをＰＧＷ１３４にフォワードすることができる。Ｐ−ＳＧＷ１３２は、たとえば、複数の基地局（図示せず）の間でのユーザ機器１１０の移動性の管理、およびサービングされる各フローに対する特定のサービス品質（ＱｏＳ）特性の施行など、いくつかの機能を実施することができる。プロキシモバイルＩＰ（ＰＭＩＰ）標準を実装するものなど、様々な実装形態において、Ｐ−ＳＧＷ１３２は、ベアラバインディングおよびイベント報告機能（ＢＢＥＲＦ）を含み得る。様々な例示的実施形態において、ＥＰＣ１３０は、複数のサービングゲートウェイ（ＳＧＷ）（図示せず）を含むことができ、各ＳＧＷは、複数の基地局（図示せず）と通信することができる。このような実施形態では、追加ＳＧＷ（図示せず）が、ユーザ機器１１０用の非一次ＳＧＷ（ＮＰ−ＳＧＷ）（図示せず）として指定され得る。

パケットデータネットワークゲートウェイ（ＰＧＷ）１３４は、パケットデータネットワーク１４０へのゲートウェイアクセスをネットワーク１００のエンドユーザに提供する装置であり得る。ＰＧＷ１３４は、Ｐ−ＳＧＷ１３２を介してユーザ機器１１０によってパケットデータネットワーク１４０に送られたパケットを受信する、ＥＰＣ１３０内の最後の装置とすることができる。ＰＧＷ１３４は、各サービスデータフロー（ＳＤＦ）に対してポリシーおよび課金制御（ＰＣＣ）規則を施行するポリシーおよび課金施行機能（ＰＣＥＦ）を含み得る。したがって、ＰＧＷ１３４は、ポリシーおよび課金施行ノード（ＰＣＥＮ）であり得る。ＰＧＷ１３４は、たとえばパケットフィルタリング、精密パケット検査、および加入者課金サポートなど、いくつかの追加特徴を含み得る。ＰＧＷ１３４は、未知のアプリケーションサービスのための資源割振りの要求も担い得る。未知のアプリケーションサービスを求める要求をＵＥ１１０から受信すると、ＰＧＷ１３４は、資源の適切な割振りを要求するクレジット制御要求（ＣＣＲ）を組み立て、その要求をＰＣＲＮ１３６にフォワードし得る。

例示的なネットワーク１００は、ロングタームエボリューション（ＬＴＥ）の特定の一実装形態に対応するが、多くの変形形態が存在し得ることに留意されたい。たとえば、ＳＧＷ１３２が存在しなくてもよく、ＰＧＷ１３４が存在しなくてもよく、かつ／またはＳＧＷ１３２およびＰＧＷ１３４の機能は、単一の装置に統合されても、複数の追加装置に拡散されてもよい。あるいは、たとえばＧＰＲＳや４Ｇなどの非ＬＴＥネットワークが使われる場合もあり得る。

ポリシーおよび課金規則ノード（ＰＣＲＮ）１３６は、サービスデータフロー（ＳＤＦ）およびＩＰ−ＣＡＮセッションに関連した要求を受信し、ＰＣＣ規則を生成し、ＰＧＷ１３４および／または他のＰＣＥＮ（図示せず）にＰＣＣ規則を提供する装置であり得る。ＰＣＲＮ１３６は、Ｒｘインタフェースを介してＡＦ１５０と通信することができる。ＰＣＲＮ１３６は、ＡＡ−要求（ＡＡＲ）１６０の形のアプリケーション要求をＡＦ１５０から受信し得る。ＡＡＲ１６０を受信すると、ＰＣＲＮ１３６は、アプリケーション要求１６０を満たす少なくとも１つの新規ＰＣＣ規則を生成することができる。

ＰＣＲＮ１３６は、Ｐ−ＳＧＷ１３２、およびＰＧＷ１３４などのＳＧＷとも、それぞれＧｘｘおよびＧｘインタフェースを介して通信することができる。ＰＣＲＮ１３６は、クレジット制御要求（ＣＣＲ）１７０の形の要求をＳＧＷ１３２またはＰＧＷ１３４から受信し得る。ＡＡＲ１６０と同様に、ＣＣＲ１７０を受信すると、ＰＣＲＮは、それに応答して、たとえば、ＣＣＲ１７０を満たし、かつ／またはＣＣＲ１７０に応答する少なくとも１つの新規ＰＣＣ規則を生成するなど、適切なアクションをとることができる。様々な実施形態において、ＡＡＲ１６０およびＣＣＲ１７０は、別々に処理されるべき２つの独自要求を表し得るが、他の実施形態では、ＡＡＲ１６０およびＣＣＲ１７０は、単一の要求に関する情報を搬送することができ、ＰＣＲＮ１３６は、ＡＡＲ１６０とＣＣＲ１７０の組合せに基づいてアクションをとることができる。様々な実施形態において、ＰＣＲＮ１３６は、単一メッセージ要求およびペアになったメッセージ要求の両方を扱うことが可能であり得る。

新規ＰＣＣ規則を作成すると、またはＰＧＷ１３４によって要求されると、ＰＣＲＮ１３６は、Ｇｘインタフェースを介してＰＧＷ１３４にＰＣＣ規則を提供することができる。たとえばＰＭＩＰ標準を実装するものなど、様々な実施形態において、ＰＣＲＮ１３６は、サービス品質（ＱｏＳ）規則を生成することもできる。新規ＱｏＳ規則を作成すると、またはＳＧＷ１３２によって要求されると、ＰＣＲＮ１３６は、Ｇｘｘインタフェースを介してＳＧＷ１３２にＱｏＳ規則を提供することができる。

図２−１１を参照して後でさらに詳しく説明されるように、規則のインストールが、たとえばＰ−ＳＧＷ１３２など、いずれかの要素において失敗した場合、その要素は、規則がインストールされ得なかったことをＰＣＲＮ１３６に知らせることができる。続いて、ＰＣＲＮ１３６は、その規則が他のいずれの要素においてもインストールされたままでないようにするためのアクションをとることができる。たとえば、ＰＣＲＮ１３６は、規則が既にインストール済みである場合、規則をアンインストールするよう、ＰＧＷ１３４に命令することができる。あるいは、ＰＣＲＮ１３６は、規則をすべてインストールするよう、ＰＧＷ１３４に命令するのを控えて、アンインストール命令を送る必要をなくすことができる。

パケットデータネットワーク１４０は、ユーザ機器１１０と、ＡＦ１５０など、パケットデータネットワーク１４０に接続された他の装置との間のデータ通信を提供するネットワーク（たとえば、インターネットや、別の通信装置ネットワーク）であり得る。パケットデータネットワーク１４０は、たとえば、パケットデータネットワーク１４０と通信する様々なユーザ装置に電話および／またはインターネットサービスをさらに提供することができる。

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

加入者ネットワーク１００の構成要素を記載してきたので、加入者ネットワーク１００の動作の手短な概要が与えられる。以下の説明は、加入者ネットワーク１００の動作の概略を提供することを意図されており、したがっていくつかの点では簡略版であることが明らかなはずである。加入者ネットワーク１００の詳細な動作は、図２−１１に関連して後でさらに詳しく説明される。

ＰＣＲＮ１３６は、たとえばＡＡＲ１６０など、２つのサービスデータフロー（ＳＤＦ）の確立を求める要求を受信することができる。ＰＣＲＮ１３６は、２つのＳＤＦを実行するための２つの規則セット、すなわち規則セットＡおよび規則セットＢを作成することができる。ＰＣＲＮ１３２は次いで、各規則セットＡ、Ｂから、ＱｏＳ規則など、適切な規則をインストールするための再認可要求（ＲＡＲ）の形の命令をＰ−ＳＧＷ１３２に送ることができる。その後、ＰＣＲＮ１３６は、２つの規則のいずれかに関してインストールが成功したか、それとも失敗したかを示す再認可回答（ＲＡＡ）で、Ｐ−ＳＧＷがＲＡＲに応答するのを待つことができる。たとえば、Ｐ−ＳＧＷ１３２が、ＱｏＳ規則Ｂのインストールには成功したが、ＱｏＳ規則Ａはインストールすることができなかった場合、Ｐ−ＳＧＷ１３２は、この状態を示すＲＡＡをＰＣＲＮ１３６に送ることができる。ＰＣＲＮ１３６は次いで、それ以上のいずれのノードにも、規則セットＡから規則をインストールするよう命令するのを控えることができる。たとえば、ＰＣＲＮ１３６は、規則セットＢからのＰＣＣ規則など、ただ１つの適切な規則をインストールするようＰＧＷ１３４に命令する第２のＲＡＲのＰＧＷ１３４への送付を進めることができる。

図２は、様々なノードにおいて、規則をインストールし、次いで、失敗した規則をアンインストールするための例示的なメッセージ交換２００を示す。メッセージ交換２００は、ＡＦ１５０、ＰＣＲＮ１３６、Ｐ−ＳＧＷ１３２、ＰＧＷ１３４、およびＮＰ−ＳＧＷ２１０の間で起こり得る。

メッセージ交換２２０は、２つのＳＤＦ、すなわちＳＤＦ ＡおよびＳＤＦ Ｂの確立を要求するＡＡＲ２２０をＡＦ１５０がＰＣＲＮ１３６に送ったときに始まり得る。ＰＣＲＮ１３６は、要求の受信に成功し、かつ／または対応する規則の生成が成功したことを示すＡＡ−回答（ＡＡＡ）２２２を、ＡＦ１５０に最初に返送することによって応答することができる。ＰＣＲＮ１３６は、ＲＡＲ２２４をＰ−ＳＧＷ１３２に、ＲＡＲ２２８をＰＧＷ１３４に、およびＲＡＲ２３２をＮＰ−ＳＧＷ２１０に送ることにより、関連ノードそれぞれにおける規則のインストールを進めることができる。各ＲＡＲ２２４、２２８、２３２は、受信側ノードが、それぞれＳＤＦ ＡおよびＳＤＦ Ｂを実行するための規則Ａおよび規則Ｂをインストールするべきであることを示し得る。異なるＲＡＲ２２４、２２８、２３２中の対応する規則は、同一でなくてもよいことに留意されたい。たとえば、ＲＡＲ２２４および２３２はＱｏＳ規則を含み得るが、ＲＡＲ２２８はＰＣＣ規則を含み得る。「規則Ａ」および「規則Ｂ」という用語は概して、対応するＳＤＦを実行するための、いずれの適用可能規則を指すのにも使われる。

ＰＣＲＮ１３６は、次のＲＡＲ２２８または２３２の送出に進む前に、ノードからの応答を待たなくてもよい。したがって、各ＲＡＡ２２５、２３０、２３４は、対応するＲＡＲ２２４、２２８、２３２が送られた後、他のいずれのメッセージにも関係なく、いつでも到着する可能性がある。たとえば、ＲＡＡ２２６は、ＲＡＲ２２４の直後にも、ＲＡＡ２３４が到着した後にも到着する場合がある。

例示的なメッセージ転送２００において、ＲＡＡ２３０、２３４は、適用可能ノードにおける規則のインストールの完全な成功を示すが、Ｐ−ＳＧＷ１３２は、規則Ａをインストールすることができない場合がある。これは、不十分な資源やできの悪い規則など、様々な要因により起こり得る。原因に関わらず、ＰＣＲＮ１３６は、ＲＡＡ２２６を受信し、規則Ａが他のすべてのノードからアンインストールされるべきであると判断することができる。したがって、ＰＣＲＮは、規則Ａがアンインストールされるべきであることを示すＲＡＲ２３６をＰＧＷ１３２に、およびＲＡＲ２４０をＮＰ−ＳＧＷ２１０に送信することができる。ＰＧＷ１３２およびＮＰ−ＳＧＷ２１０は、それぞれ、規則Ａのアンインストール成功を示すＲＡＡ２３８、２４２で応答し得る。最終的に、例示的なメッセージ交換２００は、Ｐ−ＳＧＷ１３２での失敗の結果として、ＳＤＦ Ａが確立され得なかったことを示すＲＡＲ２４４をＰＣＲＮ１３６がＡＦ１５０に送信したときに終わり得る。

図３は、発信メッセージの失敗を管理する例示的なポリシーおよび課金規則ノード（ＰＣＲＮ）３００を示す。ＰＣＲＮ３００は、ＰＣＲＮ１３６に対応することができ、Ｒｘインタフェース３０５、規則ジェネレータ３１０、メッセージストレージ３１５、メッセージ送信機３２０、Ｇｘインタフェース３２５、Ｇｘｘインタフェース３３０、応答ハンドラ３３５、およびエラーハンドラ３４０を含み得る。

Ｒｘインタフェース３０５は、ＡＦ１５０などのＡＦと通信するように構成された、ハードウェアおよび／または機械可読記憶媒体にエンコードされた実行可能命令を含むインタフェースであり得る。このような通信は、３ＧＰＰ ＴＳ ２９．２１４に従って実行され得る。たとえば、Ｒｘインタフェース２１５は、アプリケーション要求、セッション要求、およびイベント通知を、ＡＡＲの形で受信し、回答および他の状況通知を、ＡＡＡまたはＲＡＲの形で送信することができる。

規則ジェネレータ３１０は、Ｒｘインタフェース３０５、Ｇｘインタフェース３２５、および／またはＧｘｘインタフェース３３０を介して、少なくとも１つのＳＤＦの確立を求める要求を受信し、要求されたＳＤＦを確立するための１つまたは複数の規則セットを生成するように構成された、ハードウェアおよび／または機械可読記憶媒体上の実行可能命令を含み得る。規則ジェネレータ３１０は、要求に含まれる情報、加入者プロファイルリポジトリ（ＳＰＲ）（図示せず）からの情報、ポリシー決定（図示せず）の結果、およびまたは各ＳＤＦ用の適切な規則を生成する際に有用であると当業者に認識される他の任意の情報もしくは方法も使うことができる。

要求されたＳＤＦを確立するための規則セットを生成した後、規則ジェネレータ３１０は、該当ネットワーク要素に規則をインストールするための順序つきメッセージセットをさらに作成することができる。規則ジェネレータ３１０は、順序つきメッセージセットをメッセージストレージ３１５に記憶することができる。たとえば、規則ジェネレータは、ＱｏＳ規則をインストールするようＰ−ＳＧＷ１３２に命令するＲＡＲと、ＰＣＣ規則をインストールするようＰＧＷ１３４に命令するＲＡＲと、ＱｏＳ規則をインストールするようＮＰ−ＳＧＷ２１０に命令するＲＡＲとを含むメッセージセットを作成することができる。メッセージセットは、順序つきおよび／または階層状でよく、そうすることによって、含まれるメッセージが送信されるべき順序を示す。

様々な実施形態において、メッセージは、重要または非重要のどちらかとして分類され得る。重要メッセージは、ＳＤＦが確立されるために、含まれる規則をインストールしなければならない要素に向けられたメッセージに対応し得る。たとえば、Ｐ−ＳＧＷ１３２またはＰＧＷ１３４が規則をインストールするのに失敗した場合、ＳＤＦは、正しく確立することができない。このようなケースでは、Ｐ−ＳＧＷ１３２またはＰＧＷ１３４に向けられたメッセージは、重要メッセージと考えられ得る。非重要メッセージは、一方、ＳＤＦの実行に必須ではない要素に向けられたメッセージに対応し得る。たとえば、ＮＰ−ＳＧＷ２１０が規則をインストールするのに失敗した場合、対応するＳＤＦは依然として、対応する規則のインストールが他のネットワーク要素において成功していた場合は機能し得る。このようなケースでは、ＮＰ−ＳＧＷ２１０に向けられたメッセージは、非重要メッセージと考えられ得る。様々な実施形態において、規則ジェネレータ３１０は、たとえば、メッセージに関連づけられた重要／非重要フラグをセットし、またはメッセージセットの階層中の適切なポイントにメッセージを置くことによって、メッセージが重要か、それとも非重要かを示すことができる。

メッセージストレージ３１５は、少なくとも１つのＳＤＦの確立に関連して他のノードに送信するためのメッセージセットを記憶することが可能な任意の機械可読媒体でもよい。したがって、メッセージストレージ３１５は、読出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光学記憶媒体、フラッシュメモリデバイス、および／または同様の記憶媒体などの機械可読記憶媒体を含み得る。図５−８を参照して後でさらに詳しく説明されるように、規則ストレージ２３５は、多くの可能データ構造の１つ、たとえば順序つきリストまたはツリーなどでメッセージを記憶することができる。

メッセージ送信機３２０は、メッセージストレージ３１５からのメッセージを該当受信側に送信するように構成された、ハードウェアおよび／または機械可読記憶媒体上の実行可能命令を含み得る。たとえば、メッセージ送信機３２０は、メッセージセットが送られる準備ができたという指示を、規則ジェネレータ３１０から受信することができる。メッセージ送信機３２０は次いで、メッセージセットから最初のメッセージを取り出し、該当受信側に向けて送信することができる。たとえば、メッセージセット中の最初のメッセージが、Ｐ−ＳＧＷ１３２に送信するためのＲＡＲである場合、メッセージ送信機３１５は、ＲＡＲを、Ｇｘｘインタフェース３３０を介してＰ−ＳＧＷ１３２に送信することができる。メッセージを送信すると、メッセージ送信機は、メッセージストレージ３１５内でメッセージに送付済みと印をつけても、またはメッセージセットからメッセージを削除してもよい。

メッセージを送信した後、メッセージ送信機３２０は、メッセージセット中の次のメッセージを送るべきであるという指示を待ってもよい。このような指示は、たとえば、規則ジェネレータ３１０、応答ハンドラ３３５、および／またはエラーハンドラ３４０から来る場合がある。メッセージセット中のメッセージが重要または非重要として分類される様々な実施形態において、規則ジェネレータ３１０は、重要メッセージを送信した後、このように待つだけでよい。このような実施形態において、規則ジェネレータ３２０は、非重要メッセージを送信した後、次のメッセージの転送に直ちに移ることができる。メッセージ送信機３２０は、たとえば、メッセージに関連づけられたフラグを読み、階層中のメッセージの位置を観察し、またはメッセージタイプおよび／または受信側に基づく判断そのものを行うことによって、メッセージが重要か、それとも非重要かを判断するように構成され得る。メッセージの重要性を判断する他の方法が、当業者には明らかであろう。

Ｇｘインタフェース３２５は、ＰＧＷ１３４などのＰＧＷと通信するように構成された、ハードウェアおよび／または機械可読記憶媒体上でエンコードされた実行可能命令を含むインタフェースであり得る。このような通信は、３ＧＰＰ ＴＳ ２９．２１２に従って実行され得る。したがって、Ｇｘインタフェース３２５は、インストール用のＰＣＣ規則を受信し送信し、規則のインストールが成功したかどうかを示す回答を受信することができる。Ｇｘインタフェース３２５は、ＣＣＲの形の、ＵＥ発生アプリケーション要求、セッション要求、およびイベント通知をさらに受信することができる。

Ｇｘｘインタフェース３３０は、Ｐ−ＳＧＷ１３２および／またはＮＰ−ＳＧＷ２１０などのＳＧＷと通信するように構成された、ハードウェアおよび／または機械可読記憶媒体上にエンコードされた実行可能命令を含むインタフェースであり得る。このような通信は、３ＧＰＰ ＴＳ ２９．２１２に従って実行され得る。したがって、Ｇｘｘインタフェース３３０は、インストール用のＱｏＳ規則を送信し、規則インストールが成功したかどうかを示す回答を受信することができる。Ｇｘｘインタフェース３３０は、ＣＣＲの形の、ＵＥ発生アプリケーション要求、セッション要求、およびイベント通知をさらに受信することができる。

応答ハンドラ３３５は、Ｒｘインタフェース３０５、Ｇｘインタフェース３２５、および／またはＧｘｘインタフェース３３０を介して応答を受信し、扱うように構成された、ハードウェアおよび／または機械可読記憶媒体上の実行可能命令を含み得る。たとえば、Ｐ−ＳＧＷ１３２、ＰＧＷ１３４、および／またはＮＰ−ＳＧＷ２１０は、１つまたは複数の規則のインストールが成功したかどうかを示すＲＡＡの形で、返信を送るように構成され得る。このようなメッセージを受信すると、応答ハンドラ３３５は、メッセージが規則インストールの完全な成功を示すかどうかを判断することができる。成功の場合、応答ハンドラ３３５は、関連メッセージセットからの次のメッセージが送出されるべきであるという指示をメッセージ送信機３２０に送ることができる。一方、メッセージが規則インストールの何らかの失敗を示す場合、応答ハンドラ３３５は、受信した応答メッセージをエラーハンドラ３４０に渡すことができる。

エラーハンドラ３４０は、１つまたは複数の規則のインストールの失敗を示すメッセージを受信し、処理するように構成された、ハードウェアおよび／または機械可読記憶媒体上の実行可能命令を含み得る。メッセージを重要または非重要として分類する様々な実施形態において、エラーハンドラ３４０は最初に、応答が重要それとも非重要メッセージに応答して送られたかを判断することができる。応答メッセージが非重要メッセージに応答して送られた場合、エラーハンドラ３４０は単に、アクションをとらなくてもよく、該当メッセージセットからの次のメッセージが送られるべきであることをメッセージ送信機３２０に指示してもよい。

一方、応答が、重要メッセージに応答している場合、エラーハンドラ３４０は、メッセージストレージ３１５内の該当メッセージセットを修正するためのステップをとることができる。同様のアクションは、メッセージを重要または非重要と分類しない実施形態において、すべての応答メッセージに対してとることができる。図５−１１を参照して以下で詳細に説明されるように、エラーハンドラ３４０は、メッセージを削除し、修正し、かつ／または関連づけられたメッセージセットに追加することができる。たとえば、エラーハンドラ３４０は、失敗した規則をインストールするさらなる命令が送信されないようにすることができる。さらに、エラーハンドラ３４０は、ＳＤＦ確立の失敗を要求側装置に折り返し報告するメッセージを追加することができる。最終的に、メッセージストレージ３１５内のメッセージセットへの適切ないずれの修正も完了した後、エラーハンドラ３４０は、メッセージセット中の次のメッセージを送信するべきであるという指示をメッセージ送信機３２０に送ることができる。

図４は、発信メッセージの失敗を管理するための例示的なメッセージ交換４００を示す。メッセージ交換４００は、ＡＦ１５０、ＰＣＲＮ３００、Ｐ−ＳＧＷ１３２、ＰＧＷ１３４、およびＮＰ−ＳＧＷ２１０の間で起こり得る。

メッセージ交換２２０は、２つのＳＤＦ、すなわちＳＤＦ ＡおよびＳＤＦ Ｂの確立を要求するＡＡＲ２２０をＡＦ１５０がＰＣＲＮ３００に送ったときに始まり得る。ＰＣＲＮ３００は、要求の受信が成功し、かつ／または対応する規則の生成が成功したことを示すＡＡ−回答（ＡＡＡ）２２２をＡＦ１５０に最初に返送することによって応答することができる。様々な代替実施形態において、ＰＣＲＮ３００は、ＡＡＲ４２０を受信した後、ＡＡＡ４２２を直ちに送るのではなく、ＰＣＲＮ３００が該当ノード１３２、１３４、２１０それぞれにおける規則のインストールを試みるまで待ってもよい。ＰＣＲＮ３００は、ＲＡＲ４２４を送信することによって、Ｐ−ＳＧＷ１３２における規則Ａ、Ｂのインストール試行に進んでよい。その後、ＰＣＲＮ３００は、ＳＤＦ Ａ、Ｂの確立に関してそれ以上のアクションをとる前に、Ｐ−ＳＧＷ１３２からのＲＡＡ４２６を待ってもよい。

ＲＡＡ４２６を受信した後、ＰＣＲＮ３００は、Ｐ−ＳＧＷ１３２における規則Ａのインストールが失敗したと判断し得る。したがって、ＰＣＲＮ３００によって送られる次のメッセージ、たとえばＲＡＲ４２８は、規則ＢをインストールするようＰＧＷ１３４に命令するだけでよい。再度、ＰＣＲＮ３００は、先に進む前に応答を待つことができる。ＲＡＡ４３０を受信した後、ＰＣＲＮ３００は、規則Ｂのインストールが成功したと判断し、ＲＡＲ４３２の送信に進むことができる。規則Ｂのインストールが成功したというＲＡＡ４３４でＮＰ−ＳＧＷ２１０が応答した後、ＰＣＲＮ３００は、ＳＤＦ Ａの確立が失敗したことを示すＲＡＲ４４４をＡＦ１５０に送信することができる。ＰＣＲＮ３００がすべての適切な規則を関連装置１３２、１３４、２１０にインストールするのを試みるまで、ＰＣＲＮ３００がＡＡＲ２２０に回答するのを待つ様々な代替実施形態において、ＰＣＲＮ３００は、ＡＡＡ４２２およびＲＡＲ４４４の両方の代わりにＳＤＦ Ａに関して失敗を示すためのＡＡＡ（図示せず）を送信することができる。様々な実施形態において、ＲＡＲ４４４、またはその代替ＡＡＡ（図示せず）は、代替ＳＤＦが要求され得るように、ＳＤＦ確立失敗の理由を判断する際にＡＦ１５０または他のいずれの要求側ノードにとっても有益な、および／または要求を修正する際に有用な情報を含み得る。

図５は、様々なノードにメッセージを送信するための例示的な汎用メッセージツリー５００を示す。メッセージツリー５００は、ＰＣＲＮ３００によって、特定のメッセージを配置するべき、順序つきメッセージセット中の適切な位置を判断するために、たとえば、図６−８を参照して詳しく記載されたツリーなど、様々なメッセージツリーを組み立てる際に使われ得る。したがって、メッセージツリー５００は、たとえば、テンプレートまたは基準データ構造でよい。様々な代替実施形態において、メッセージツリーを組み立てる際のＰＣＲＮ３００の挙動は、たとえば、規則エンジンによる使用のために定義されたハードコーディングまたは規則など、他のやり方で定義され得る。このような実施形態において、汎用メッセージツリー５００は単に、例示目的のための抽象化した例であり得る。

汎用メッセージツリー５００は、複数のメッセージ５１０、５２０、５３０、５３５、５４０、５４５、５５０、５５５を含み得る。汎用メッセージツリー５００の階層中でのメッセージの位置は、メッセージの送信のための順序つき位置および／またはメッセージが重要かどうかを示し得る。一例として、様々な実施形態において、メッセージ５１０は、ツリーの最上位にあるので、適用可能なＰ−ＳＧＷ向けのＲＡＲが、最初に送信されるべきメッセージであることを示し得る。さらに、メッセージ５１０には兄弟メッセージがないので、ＰＣＲＮ３００は、他のいずれのメッセージを送信する前に、Ｐ−ＳＧＷから応答が到着するのを待つことができる。

次に、メッセージ５２０は、Ｐ−ＳＧＷから応答を受信した後、該当ＰＧＷにＲＡＲが送信されるべきであることを示し得る。やはり、メッセージツリー５００は、メッセージ５２０に兄弟メッセージがないことにより、ＰＣＲＮ３００が、先に進む前にＰＧＷからの応答を待つべきであることを示し得る。

メッセージ５３０、５３５は、任意の数のメッセージを表し得る。メッセージ５３０、５３５は、ＮＰ−ＳＧＷに向けられたいずれのＲＡＲも、ＰＧＷから応答が受信された後に送信されるべきであることをさらに示し得る。様々な実施形態において、メッセージ５３０、５３５は兄弟ノードなので、ＰＣＲＮ３００は、メッセージ５３０、５３５に対応するすべてのメッセージを直ちに送信することができる。同様に、ＰＣＲＮは、適切なＡＦに向けられたいずれのＲＡＲでもよい、メッセージ５４０、５４５に対応するメッセージ、および／または適切なＡＦに向けられたどのＡＳＲでもよい、メッセージ５５０、５５５に対応するメッセージを直ちに送信してよい。

汎用メッセージツリー５００は、必ずしも、送信用の実際のメッセージを含む実際のメッセージツリーでなくてもよいことに留意されたい。したがって、実際のメッセージツリーは、汎用メッセージツリー５００に含まれるすべてのメッセージを含まない場合がある。たとえば、メッセージツリーは、すべてのＳＤＦ確立が失敗したので、ＡＦへの送信用のＡＳＲは含み得るが、同じＡＦへの送信用のＲＡＲは含まなくてもよい。というのは、このようなメッセージは、冗長または他の意味で不適切な場合があるからである。

さらに、様々な実施形態は、汎用メッセージツリー５００に対する変形体を含み得る。たとえば、メッセージ５２０はツリーのルートであってもよく、メッセージ５１０はメッセージ５２０のチルドであってもよい。このようなツリーは、ＲＡＲが、最初にＰＧＷに、次いでＰ−ＳＧＷに送られるべきであることを示し得る。別の例として、ベアラバインディングおよび報告機能（ＢＢＥＲＦ）を使用しない実施形態など、様々な実施形態において、汎用メッセージツリー５００は、メッセージ５１０、５３０、５３５を全く含まなくてもよい。汎用メッセージツリー５００に対するさらなる変形体が、当業者には明らかであろう。

図６は、様々なノードにおいて規則をインストールするための例示的なメッセージツリー６００を示す。メッセージツリー６００は、たとえば図４のＡＡＲ４２０など、２つのＳＤＦ、すなわちＡ、Ｂの確立を求める要求に応答して生成され得る。メッセージツリー６００は、様々な適切なネットワーク装置の間で、２つの規則、すなわちＡ、Ｂをインストールするための３つのメッセージ６１０、６２０、６３０を含み得る。メッセージツリー６００中でのメッセージの配置は、ＰＣＲＮ３００などのＰＣＲＮによってメッセージがどの順序で送信されるように意図されるかを示し得る。様々な実施形態が、メッセージを様々に順序づけることができる。たとえば、メッセージ６２０が最初のメッセージであり、その後にメッセージ６１０、およびメッセージ６３０が続いてもよい。当業者にとって有用と認識される任意の順序づけ方式も使われ得る。

たとえば、メッセージ６１０は、ＰＣＲＮ３００によって送信されるように意図された最初のメッセージであってもよく、規則Ａ、ＢをインストールするようＰ−ＳＧＷ１３２に命令するＲＡＲであってもよい。メッセージ６１０は、ＳＤＦ Ａ、Ｂを確立するためのＱｏＳ規則定義を含み得る。メッセージ６２０は、メッセージ６１０の送信の後でＰＧＷ１３４への送信を意図されたＲＡＲであってもよい。メッセージ６２０は、ＳＤＦ Ａ、Ｂを確立するためのＰＣＣ規則定義を含み得る。最後に、メッセージ６３０は、メッセージ６２０の送信後にＮＰ−ＳＧＷ２１０への送信を意図されたＲＡＲであってもよい。メッセージ６３０は、ＳＤＦ Ａ、Ｂを確立するためのＱｏＳ規則定義も含み得る。

メッセージツリー６００、ならびに以降で記載するいずれのメッセージツリーも、メッセージツリーの一例として意図されていることが明らかなはずである。たとえば、ユーザ機器１１０に関連づけられたネットワーク要素の数およびタイプ、ならびにＰＣＲＮ３００がＡＡＲに直ちに応答するかどうかなど、様々な要因により、メッセージツリー６００は、追加メッセージを含むことができる。たとえば、ＰＣＲＮは、他のＮＰ−ＳＧＷ（図示せず）への送信用の、メッセージ６３０と同様の追加メッセージを含んでもよい。さらなる例として、メッセージツリーは、たとえばＡＦ１５０など、いずれの適切なＡＦにも、ＳＤＦ確立の成功または失敗を報告するＡＡＡを含んでいることができる。さらに、特定のノード上で規則を含まない、またはインストールしない様々なネットワークにおいて、それらのノードにアドレス指定されたメッセージは、省かれてもよい。たとえば、ＳＧＷ上でＱｏＳ規則をインストールしない実施形態において、メッセージツリー６００は、メッセージ６１０、６３０を含んでいなくてもよい。

図７は、様々なノードにおいて規則をアンインストールするための例示的なメッセージツリー７００を示す。メッセージツリー７００は、たとえば図４のＲＡＡ４２６など、規則のインストールが別のノードにおいて失敗したという指示に応答して生成され得る。メッセージツリー７００は、ＳＤＦ確立失敗に関して、規則Ａをアンインストールし、ＡＦを通知するための３つのメッセージ７２０、７３０、７５０を含み得る。

たとえば、メッセージ７２０は、ＰＣＲＮ３００によって送信され、かつ／または検討されることになる最初のメッセージであり得る。メッセージ７２０は、ＰＧＷ１３４への送信用のＲＡＲであってもよく、規則ＡをアンインストールするようＰＧＷ１３４に命令することができる。メッセージ７３０は、メッセージ７２０の送信後の、ＮＰ−ＳＧＷ２１０への送信用のＲＡＲであり得る。メッセージ７３０も、規則ＡをアンインストールするようＮＰ−ＳＧＷ２１０に命令することができる。最後に、メッセージ７５０は、メッセージ７２０の送信後の、ＡＦ１５０への送信用のＲＡＲであってもよく、ＳＤＦ Ａの確立の失敗に関してＡＦ１５０に知らせることができる。メッセージ７５０は、ＡＦ１５０によって、ＳＤＦが何に失敗したか、および／またはどのようにして代替ＳＤＦの要求に成功したかを判断する際に使用するための情報をさらに含み得る。

メッセージツリー７００のツリー構造は、メッセージ７３０、７５０の非重要性を含意し得ることに留意されたい。メッセージ７３０およびメッセージ７５０は両方とも、メッセージ７２０に依存する。メッセージツリー７００がそのまま送信されることになる実施形態において、ＰＣＲＮは、別のメッセージを送信する前に、別のネットワークノードからのメッセージ７２０への応答を待つことができる。このような応答を受信した後、ＰＣＲＮは、最初に他のいずれの応答も待たずに、メッセージ７３０、７５０を送信することができる。

メッセージツリー６００と同様に、メッセージツリー７００は、実施形態および／または状況に依存して、追加および／または代替メッセージを含み得る。たとえば、様々な実施形態において、ＰＣＲＮ３００は、規則をインストールするのに失敗したノードに、同じ規則をアンインストールするよう命令する必要があり得る。このようなケースでは、メッセージツリー７００は、規則ＡをアンインストールするようＰ−ＳＧＷ１３２に命令する追加メッセージ（図示せず）を含み得る。

図８は、規則インストールの失敗を管理するための例示的なメッセージツリー８００を示す。メッセージツリー８００は、メッセージツリー６００と７００を組み合わせた結果であり得る。メッセージツリーの組合せは、メッセージの組合せを含み得る。ＰＣＲＮ３００は、たとえば、メッセージツリー６００に含まれるメッセージが、メッセージツリー７００中の異なるメッセージに対応するかどうかを判断することができる。ＰＣＲＮ３００は、この判断を、たとえば、メッセージのタイプおよび／またはメッセージの受信側に基づいて行うことができる。ＰＣＲＮ３００は次いで、２つの対応するメッセージを組み合わせて、両方のメッセージの目標を達成する新規メッセージを生成することができる。たとえばメッセージ８１０など、いくつかのメッセージは、影つきボックスで示されるように、既に送信済みであり、またはそれ以外では実行済みである場合がある。様々な代替実施形態において、送信済みメッセージは、メッセージツリー８００から単に削除することができる。

メッセージツリーは、４つのメッセージ８１０、８２０、８３０、７５０を含み得る。メッセージ８１０は、メッセージツリー６００のメッセージ６１０と同様であり得る。メッセージ８１０は、メッセージツリー６００と７００の組合せによって変えられなくてよい。というのは、メッセージ８１０の影によって示されるように、メッセージツリー７００中には対応するメッセージが存在しなかったからであり、かつ／またはメッセージ８１０がＰ−ＳＧＷ１３２に既に送信されていたからである。

メッセージ８２０は、メッセージ８１０の送信後の送信を意図され得る。メッセージ８１０は既に送信済みである場合があるので、メッセージ８２０は事実上、新規メッセージツリー８００からの最初の送信メッセージであり得る。メッセージ８２０は、メッセージ６２０とメッセージ７２０を組み合わせた結果であり得る。たとえば、メッセージ６２０が、規則Ａ、ＢをインストールするようＰＧＷ１３４に命令し、メッセージ７２０が、規則Ａをアンインストールするよう同じ装置に命令したので、メッセージ８２０は、規則ＢをインストールするようＰＧＷ８２０に命令するだけでよい。同様の理由により、メッセージ８２０は、メッセージ６３０と７３０のマージに基づいてよく、規則ＢのみをインストールするようＮＰ−ＳＧＷ２１０に命令することができる。メッセージ７５０は、対応するメッセージをメッセージツリー６００が含んでいなかったので、メッセージツリー７００から直接、メッセージツリー８００に追加され得る。

図９は、メッセージツリーをマージするための例示的なデータ配置９００を示す。データ配置は、エラーハンドラ３４０によって、たとえばメッセージツリー６００、７００など、２つのメッセージツリーをどのようにして組み合わせるか判断するのに使われ得る。データ配置９００は、たとえば、エラーハンドラ３４０、メッセージストレージ３１５、またはＰＣＲＮ３００の内部もしくは外部にあるとともにエラーハンドラ３４０によってアクセス可能である他のどの要素に格納されたデータベース中のテーブルでもよい。あるいは、データ配置９００は、一連のリンクリスト、アレイ、同様のデータ構造でもよく、またはＰＣＲＮ３００の動作にハードコードされてもよい。したがって、データ配置９００は基底データの抽象化であり、基底データの記憶に適した任意のデータ構造も使ってよいことが明らかなはずである。

データ配置９００は、４つのフィールド、すなわち、古いツリーにあるメッセージのフィールド９１０と、古いツリー中の送信済みメッセージのフィールド９２０と、新しいツリーにあるメッセージのフィールド９３０と、アクションフィールド９４０とを含み得る。「古いツリー」という用語は、エラーメッセージの受信の前に存在するツリー、たとえばメッセージツリー６００などを指し得る。「新しいツリー」という用語は、エラーメッセージに応答して生成されたツリー、たとえばメッセージツリー７００などを指し得る。古いツリーにあるメッセージのフィールド９１０は、所与のタイプのメッセージが古いツリーに存在するかどうかに関する論理値を示すフィールドであり得る。古いツリー中の送信済みメッセージのフィールド９２０は、所与のタイプのメッセージが古いツリー中で送信済みであるかどうかに関する論理値を示すフィールドであり得る。新しいツリーにあるメッセージのフィールド９３０は、所与のタイプのメッセージが新しいツリーに存在するかどうかに関する論理値を示すフィールドであり得る。最後に、アクションフィールド９４０は、特定のメッセージまたはメッセージセットにレコードが適用可能なときにとられるべきアクションを示し得る。

一例として、レコード９５０は、対応するメッセージが古いツリーおよび新しいツリーの両方に存在するが、古いツリー中のメッセージが既に送信されているとき、新しいツリー中のメッセージは現状のまま使われるべきであることを示し得る。レコード９５５は、古いツリー中で送信済みのメッセージが新しいツリー中のいずれのメッセージにも対応しないとき、そのメッセージに関して何も行われるべきでないことを示し得る。レコード９６０は、対応するメッセージが古いツリーおよび新しいツリーの両方に存在し、古いツリー中のメッセージがまだ送信されていないとき、２つのメッセージがマージされて、単一のメッセージを生じるべきであることを示し得る。レコード９６５は、古いツリー中の未送信メッセージが、新しいツリー中に対応するメッセージをもたないとき、古いメッセージは現状のまま使われるべきであることを示し得る。レコード９７０は、新しいツリー中のメッセージが古いツリー中のいずれのメッセージにも対応しないとき、新規メッセージは現状のまま使われるべきであることを示し得る。最後に、レコード９７５は、どのメッセージも検討されていないときは何もアクションがとられないことを示し得る。

図１０は、発信メッセージの失敗を管理する例示的な方法１０００を示す。方法１０００は、ＰＣＲＮ３００の構成要素、たとえば、規則ジェネレータ３１０、メッセージ送信機３２０、応答ハンドラ３３５、および／またはエラーハンドラ３４０などによって実施され得る。

方法１０００は、ステップ６１００５で始まり、ステップ１０１０に進むことができ、ここでＰＣＲＮ３００は、たとえば、１つまたは複数のＳＤＦの確立を要求するメッセージを受信し得る。ＰＣＲＮ３００は次いで、ステップ６１０１５で、要求されたＳＤＦを確立するための少なくとも１つの規則セットを生成することができる。方法９００は次いで、ステップ１０２０に進むことができ、ここでＰＣＲＮ３００は、様々な適切なネットワークノードに規則をインストールするためのいくつかのメッセージを生成し、順序づけることができる。ステップ１０２５で、ＰＣＲＮ３００は、順序つきメッセージセット中の最初のメッセージを取り出し、続いて、そのメッセージをステップ１０３０で、メッセージの指定受信側に送信することができる。

ステップ６１０３５で、ＰＣＲＮ３００は、たとえば、送信されたばかりのメッセージが重要と印づけられていたかどうかを判断し、かつ／またはメッセージ受信側を検討することによって、メッセージが重要メッセージだったかどうかを判断することができる。メッセージが重要だった場合、方法１０００はステップ１０４０に進み得る。重要でない場合、方法１０００は直接ステップ１０５０に進み得る。様々な実施形態において、ＰＣＲＮ３００は、重要メッセージと非重要メッセージとを区別しなくてもよく、すべてのメッセージが重要であるかのように、ステップ１０４０に進むだけでよい。ステップ１０４０で、ＰＣＲＮ３００は、送信メッセージへの応答を受信するのを待つことができる。応答を受信した後、ＰＣＲＮ３００は、ステップ６１０４５で、応答がインストール成功を示すかどうかを判断することができる。インストールが成功した場合、方法１０００はステップ１０５０に進み得る。応答が規則インストールの何らかの失敗を示す場合、方法１０００はステップ６１０５５に進んでもよく、ここでＰＣＲＮ３００は、メッセージを、応答に従って送信されるように修正することができる。この修正は、当業者に知られているいずれの方法に従っても、本明細書に提示されるとともに図１１に関して後でさらに詳しく説明される方法に従っても実施され得る。

ＰＣＲＮ３００は、ステップ１０５０で、たとえば、順序つきメッセージセット中にいずれかの未送信メッセージが存在するかどうかを判断することによって、最終メッセージが送信済みであるかどうかを判断することができる。送信されるべきメッセージが残っていない場合、方法１０００は、ステップ６１０６５で終わり得る。まだ送信するべきメッセージがある場合、ＰＣＲＮ３００は、ステップ１０６０で次のメッセージを取り出すことが可能であり、方法１０００はステップ１０３０にループバックし得る。

図１１は、メッセージグループをマージする例示的な方法１１００を示す。方法１１００は、方法１０００のステップ６１０５５に対応することができ、ＰＣＲＮ３００の構成要素、たとえば、エラーハンドラ３４０などによって実施され得る。

方法１１００は、ステップ１１０５で始まり、ステップ１１１０に進むことができ、ここで、規則失敗の指示に応答して、ＰＣＲＮ３００は、新規メッセージセットを生成し、順序づけることができる。次いで、ステップ１１１５で、ＰＣＲＮ３００は、新規メッセージセットから新規メッセージを取り出すことができる。ステップ１１２０で、ＰＣＲＮ３００は、新規メッセージが、予め生成された主要メッセージセット中のいずれかの古いメッセージと一致するかどうかを、たとえば、方法１０００や方法１１００の事前実行に従って判断することができる。ＰＣＲＮ３００は、この比較を、たとえば、メッセージタイプおよび／または受信側に従って行うことができる。一致する場合、方法１１００はステップ１１２５に進み得る。一致しない場合、方法１１００はステップ１１３５に進み得る。

ステップ１１２５で、ＰＣＲＮ３００は、たとえば、メッセージに関連づけられたフラグがセットされているかどうかを判断することによって、一致する古いメッセージがまだ送信されていないかどうかを判断することができる。メッセージが、送信後に単にメッセージセットから削除される様々な実施形態において、方法１１００は、ステップ１１２５をスキップしてもよい。古いメッセージが送信されていない場合、方法１１００はステップ１１３０に進み得る。送信済みの場合、方法１１００はステップ１１３５に進み得る。

ＰＣＲＮ３００は、ステップ１１３０で、一致するメッセージをマージして、２つのメッセージの組み合わされた目標を達成する単一のメッセージを生じることができる。このような、メッセージのマージは、当業者に知られているいずれの方法に従っても遂行され得る。メッセージの様々な組合せは、無効になる場合もある。たとえば、１つのメッセージが、ある規則をインストールすることを意図され、対応するメッセージが、同じ規則をアンインストールすることを意図されている場合、その結果生じるメッセージは単に、どちらの命令も含まない場合がある。

ステップ１１２０によって判断されるように、新規メッセージには、一致する古いメッセージがない場合、またはステップ１１２５によって判断されるように、対応する古いメッセージが存在するが既に送信されている場合、方法１１００は、ステップ１１３５を実行することができる。ステップ１１３５で、ＰＣＲＮ３００は、新規メッセージを主要メッセージセットに現状のまま追加するだけでよい。方法１１００は次いで、ステップ１１４０に進むことができ、ここでＰＣＲＮ１１４０は、処理するべき追加メッセージが新規メッセージセット中にあるかどうかを判断することができる。すべてのメッセージが処理されている場合、方法１１００は単に、ステップ１１４５で終わってもよい。一方、新規メッセージセットがまだ未処理メッセージを含んでいる場合、方法１１００はステップ１１１５にループバックし得る。

上記によれば、様々な例示的実施形態が、失敗した規則インストールなどの失敗の扱いに関連した処理オーバーヘッドを最小限にするシステムを提供する。特に、少なくともいくつかの送信メッセージへの応答を待つことによって、ＰＣＲＮは、失敗の知らせに知的に応答し、失敗によって不必要または無益にされる命令または他のアクションを排除することができる。

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

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

様々な例示的実施形態について、そのいくつかの例示的態様を具体的に参照して詳しく記載したが、本発明は、他の実施形態も可能であり、その細部は、様々な自明の点において修正可能であることを理解されたい。当業者には容易に明らかであるように、本発明の精神および範囲内のまま、変形形態および変更形態を取りうる。したがって、上記開示、記述、および図面は、例示目的のために過ぎず、本発明を限定するものでは全くなく、本発明は、特許請求の範囲によってのみ定義される。

Claims (13)

1. ポリシーおよび課金規則ノード（ＰＣＲＮ）において実施される、失敗を管理する方法であって、
   ＰＣＲＮにおいて、第１のサービスデータフロー（ＳＤＦ）の確立を求める要求を要求側ノードから受信すること（１０１０）、
   受信した要求に応答して、第１のＳＤＦを実行するための第１の規則セットを生成すること（１０１５）、
   生成された第１の規則セットのうち第１の規則を、第１の規則のインストールのために第１のノードに送信すること（１０３０）、
   一定の期間、第１のノードからの応答を待つこと（１０４０）、
   第１のノードにおける第１の規則のインストールが失敗したか、それとも成功したかを第１のノードからの応答から判断すること（１０４５）、および
   第１の規則のインストールが成功した場合、生成された第１の規則セットのうち第２の規則を、第２の規則のインストールのために第２のノードに送信すること（１０３０）
   を含む、方法。
2. 第１の規則のインストールが失敗した場合、
   第２の規則を第２のノードに送信するのを控えること、および
   第１のＳＤＦの確立が失敗したことを示すメッセージを要求側ノードに送信すること
   をさらに含む、請求項１に記載の方法。
3. 要求側ノードからの要求が、第２のＳＤＦの確立を要求し、
   要求側ノードからの要求に応答して、第２のＳＤＦを実行するための第２の規則セットを生成すること（１０１５）、
   生成された第２の規則セットのうち第３の規則を、生成された第１の規則セットのうち第１の規則とともに、第１の規則および第３の規則のインストールのために第１のノードに送信すること（１０３０）、
   第１のノードからの応答から、第１のノードにおける第３の規則のインストールが失敗したか、それとも成功したかを判断すること（１０４５）、ならびに
   第３の規則のインストールが成功した場合、生成された第２の規則セットのうち第４の規則を、第４の規則のインストールのために第２のノードに送信すること（１０３０）であって、第４の規則が、第１のノードにおける第１の規則のインストールが成功したかどうかに関わらず送信される、こと
   をさらに含む、請求項２に記載の方法。
4. 判断するステップが、
   第１のノードからの応答が、期間が経過する前に到着したかどうかを判断すること、および
   第１のノードからの応答が到着しなかった場合、第１の規則のインストールが失敗したと判断すること
   を含む、請求項１に記載の方法。
5. 第１の規則のインストールが成功した場合、
   第２のノードへの第２の規則の送信が重要か、それとも非重要かを判断すること（１０３５）、
   第２のノードへの第２の規則の送信が重要である場合、
   第２の規則を第２のノードに送信した後、一定の期間、第２のノードからの応答を待つこと（１０４０）、
   第１のノードにおける第２の規則のインストールが失敗したか、それとも成功したかを第２のノードからの応答から判断すること（１０４５）、
   第２の規則のインストールが成功した場合、第１の規則セットのうち第３の規則を、第３の規則のインストールのために第３のノードに送信すること（１０３０）、および
   第２の規則のインストールが失敗した場合、第３の規則を第３のノードに送信するのを控えること、ならびに
   第２のノードへの第２の規則の送信が非重要である場合、第３の規則を、インストールのために第３のノードに直ちに送信すること（１０３０）
   をさらに含む、請求項１に記載の方法。
6. 第２の規則が第１の規則である、請求項１に記載の方法。
7. 要求側ノードが、第１のノードまたは第２のノードのいずれかである、請求項１に記載の方法。
8. 要求側ノードからの要求メッセージを受信する（１０１０）第１のインタフェースを含む複数のインタフェース（３０５、３２５、３３０）であって、受信された要求メッセージが、サービスデータフロー（ＳＤＦ）の確立を求める要求を含む、インタフェースと、
   ＳＤＦを実行するための規則セットを生成し（１０１５）、生成された規則セット中の規則を他のノードにおいてインストールするための順序つきメッセージセットを生成する（１０２０）規則ジェネレータ（３１０）と、
   順序つきメッセージセットからの第１のメッセージを、複数のインタフェースのうちの１つのインタフェースを介して第１のノードに送信し（１０３０）、順序つきメッセージセットからのあるメッセージが送信されるべきであるという指示を待ち（１０４０）、順序つきメッセージセットからの第２のメッセージを、複数のインタフェースのうちの１つのインタフェースを介して第２のノードに送信する（１０３０）メッセージ送信機（３２０）と、
   複数のインタフェースのうちの１つのインタフェースを介して第１のノードからの応答を受信し（１０４０）、第１のメッセージ中で指示されたすべての規則のインストールが成功したかどうかを第１のノードからの応答から判断し（１０４５）、第１のメッセージ中で指示されたすべての規則のインストールが成功した場合、順序つきメッセージセットからのあるメッセージが送信されるべきであるという指示をメッセージ送信機に送る応答ハンドラ（３３５）とを備える、
   ハードウェアポリシーおよび課金規則ノード（ＰＣＲＮ）。
9. メッセージ送信機（３２０）がさらに、
   第２のメッセージが重要か、それとも非重要かを判断し、
   第２のメッセージが重要である場合、
   順序つきメッセージセットからのあるメッセージが送信されるべきであるという指示を待ち、
   順序つきメッセージセットからの第３のメッセージを、複数のインタフェースのうちの１つのインタフェースを介して第３のノードに送信し（１０３０）、
   第２のメッセージが非重要である場合、第３のメッセージを第３のノードに直ちに送信する（１０３０）、
   請求項８に記載のハードウェアＰＣＲＮ。
10. 第１のメッセージ中で指示された少なくとも１つの規則のインストールが成功しなかったとき、応答ハンドラから応答を受信し（１０４０）、
    第１のノードからの応答に基づいて、順序つきメッセージセットを修正し（１０５５）、
    順序つきメッセージセットからのあるメッセージが送信されるべきであるという指示をメッセージ送信機に送るエラーハンドラ（３４０）
    をさらに備える、請求項８に記載のハードウェアＰＣＲＮ。
11. エラーハンドラ（３４０）が、メッセージ送信機が第１のメッセージを送信した後、一定の期間が経過したかどうかをさらに判断し、一定の期間が経過しており、第１のノードからの応答が到着していない場合、第１のメッセージ中で指示されたすべての規則のインストールが成功しなかったと判断する、請求項１０に記載のハードウェアＰＣＲＮ。
12. 順序つきメッセージセットを修正する際、エラーハンドラ（３４０）が、
    第１のノードからの応答に基づいて新規メッセージセットを生成し、
    新規メッセージセット中の各新規メッセージに対して、
    順序つきメッセージのセットが、新規メッセージに対応する古い未送信メッセージを含むかどうかを判断し、
    順序つきメッセージのセットが、新規メッセージに対応する古い未送信メッセージを含む場合、
    新規メッセージを古い未送信メッセージとマージして、マージされたメッセージを作成し、
    マージされたメッセージを、順序つきメッセージのセットに追加し、
    順序つきメッセージのセットが、新規メッセージに対応する古い未送信メッセージを含まない場合、新規メッセージを順序つきメッセージのセットに追加する、
    請求項１１に記載のハードウェアＰＣＲＮ。
13. 順序つきメッセージセットがツリーである、請求項８に記載のハードウェアＰＣＲＮ。

Images