JP5575928B2 - 多様なソースメッセージの関連付け - Google Patents

Description

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

モバイル通信ネットワーク内の様々なタイプのアプリケーションに対する需要が高まるにつれて、サービスプロバイダは、この拡張された機能性を確実に提供するために、そのシステムを常に更新しなければならない。かつて単に音声通信に関して設計されたシステムだったものは、テキストメッセージング、マルチメディアストリーミング、および一般的なインターネットアクセスを含めて、無数のアプリケーションに対するアクセスを提供する汎用ネットワークアクセスポイントに成長した。そのようなアプリケーションをサポートするために、プロバイダは、その既存の音声ネットワークの上に、洗練されていない解決策をもたらす新しいネットワークを構築した。第２世代ネットワークおよび第３世代ネットワークに見られるように、音声サービスは、その他のサービス通信が、インターネットプロトコル（ＩＰ）に従って送信され、異なるパケット交換コアに向けられるのに対して、専用音声チャネルを介して搬送され、回線交換コアに向けられなければならない。これはアプリケーション規定、計測および課金、ならびに体感品質（ｑｕａｌｉｔｙ ｏｆ ｅｘｐｅｒｉｅｎｃｅ）（ＱｏＥ）保証に関して、独自の問題をもたらした。

第２世代および第３世代のデュアルコア手法を簡素化する努力において、第３世代パートナーシッププロジェクト（３ＧＰＰ）は、当該プロジェクトが「ロングタームエボリューション（ＬＴＥ）」と呼ぶ新しいネットワーク方式を推奨した。ＬＴＥネットワークでは、すべての通信は、ＩＰチャネルを介してユーザ装置（ＵＥ）から進化型パケットコア（ＥＰＣと呼ばれるａｌｌ−ＩＰコアに搬送される。次いで、ＥＰＣは、容認できるＱｏＥを確実にして、その特定のネットワーク活動に関して加入者に課金すると同時に、他のネットワークにゲートウェイアクセスを提供する。

３ＧＰＰは、一般に、ＥＰＣの構成要素、およびいくつかの技術仕様におけるそれらのＥＰＣ構成要素同士の間の相互作用を記述する。詳細には、３ＧＰＰ ＴＳ２９．２１２、３ＧＰＰ ＴＳ２９．２１３、および３ＧＰＰ ＴＳ２９．２１４は、ＥＰＣのポリシーおよび課金規則機能（Ｐｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｒｕｌｅｓ Ｆｕｎｃｔｉｏｎ）（ＰＣＲＦ）、ポリシーおよび課金施行機能（Ｐｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｅｎｆｏｒｃｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）（ＰＣＥＦ）、ならびにベアラバインドおよびイベント報告機能（Ｂｅａｒｅｒ Ｂｉｎｄｉｎｇ ａｎｄ Ｅｖｅｎｔ Ｒｅｐｏｒｔｉｎｇ Ｆｕｎｃｔｉｏｎ）（ＢＢＥＲＦ）を記述する。これらの仕様は、信頼性のあるデータサービスを提供して、その使用に関して加入者に課金するために、これらの要素がどのように相互作用するかについて何らかの指針をさらに規定する。

例えば、３ＧＰＰ ＴＳ２９．２１２仕様、３ＧＰＰ ＴＳ２９．２１３仕様、および３ＧＰＰ ＴＳ２９．２１４仕様は、異なるソースからの複数のメッセージおよび動的なセッション管理を処理することに関する何らかの指針を提供する。しかし、これらの仕様は、受信されるそれぞれのメッセージが、関連するメッセージをバインドするために使用される情報を伴って、常に同じ量の情報を含むことを想定する。しかし、仕様および実世界のアプリケーションは異なるメッセージが異なる情報を含むことを可能にするため、システムが常にそのような出来事に遭遇するとは限らない。

前述の説明に鑑みて、関連するメッセージのバインドを処理するための方法を提供することが望ましいことになる。詳細には、複数の関連するメッセージを受信して、それらをＰＣＲＦの形でバインドできるシステムを提供することが望ましいことになる。

複数の関連するメッセージを処理およびバインドするための方法に関する現在の必要性に照らして、様々な例示的な実施形態の概要が提示される。本発明の範囲を限定するためではなく、様々な例示的な実施形態のいくつかの態様を強調および導入するための以下の概要において、何らかの簡素化および省略が行われる場合がある。当業者が本発明の概念を構成し、その概念を使用することを十分に可能にする、好ましい例示的な実施形態の詳細な説明が後の節に続く。

様々な例示的な実施形態は、複数のデバイスから受信された少なくとも２つのメッセージを関連付けるために、ポリシーおよび課金規則ノード（ＰＣＲＮ）内のダイアメータプロキシエージェント（Ｄｉａｍｅｔｅｒ Ｐｒｏｘｙ Ａｇｅｎｔ）（ＤＰＡ）によって実行される方法であって、第１のデバイスから、第１の加入者プロファイルに関連する少なくとも１つの属性を含む第１のセッションバインド識別子（ＳＢＩ）を含む第１のメッセージを受信するステップと、ＰＣＲＮを含む複数のＰＣＲＮブレード内の第１のＰＣＲＮブレードに第１のメッセージを転送するステップであって、第１のＰＣＲＮブレードが第１のメッセージに関する第１のセッションを作成する、転送するステップと、第２のデバイスから、第２の加入者プロファイルに関連する少なくとも１つの属性を含む第２のＳＢＩを含む第２のメッセージを受信するステップと、第１のメッセージの第１のＳＢＩおよび第２のメッセージの第２のＳＢＩが同じ加入者プロファイルに関連するとき、ＤＰＡによって、第２のメッセージを第１のＰＣＲＮブレードに転送するステップとを含む方法に関する。

様々な実施形態は、複数のデバイスから受信された少なくとも２つのメッセージを関連付けるためのポリシーおよび課金規則ノード（ＰＣＲＮ）であって、第１のデバイスから、第１の加入者プロファイルに関連する少なくとも１つの属性を含む第１のセッションバインド識別子（ＳＢＩ）を含む少なくとも第１のメッセージを受信して、第２のデバイスから、第２の加入者プロファイルに関連する少なくとも１つの属性を含む第２のＳＢＩを含む第２のメッセージを受信するためのダイアメータプロキシエージェントと、第１のメッセージを受信して、第１のメッセージに関する第１のセッションを作成するための、ＰＣＲＮを含む複数のＰＣＲＮブレード内の少なくとも第１のＰＣＲＮブレードとを含み、第１のメッセージの第１のＳＢＩおよび第２のメッセージの第２のＳＢＩが同じ加入者プロファイルに関連するとき、ＤＰＡが第２のメッセージを第１のＰＣＲＮブレードに転送するポリシーおよび課金規則ノード（ＰＣＲＮ）にも関連し得る。

様々な実施形態は、ポリシーおよび課金規則ノード（ＰＣＲＮ）内のダイアメータプロキシエージェント（ＤＰＡ）が複数のデバイスから受信された少なくとも２つのメッセージを関連付けるための命令を用いて符号化された機械可読記憶媒体であって、第１のデバイスから、第１の加入者プロファイルに関連する少なくとも１つの属性を含む第１のセッションバインド識別子（ＳＢＩ）を含む第１のメッセージを受信するための命令と、ＰＣＲＮを含む複数のＰＣＲＮブレード内の第１のＰＣＲＮブレードに第１のメッセージを転送するための命令であって、第１のＰＣＲＮブレードが第１のメッセージに関する第１のセッションを作成する、転送するための命令と、第２のデバイスから、第２の加入者プロファイルに関連する少なくとも１つの属性を含む第２のＳＢＩを含む第２のメッセージを受信するための命令と、第１のメッセージの第１のＳＢＩおよび第２のメッセージの第２のＳＢＩが同じ加入者プロファイルに関連するとき、ＤＰＡによって、第２のメッセージを第１のＰＣＲＮブレードに転送するための命令とを含む機械可読記憶媒体にも関連し得る。

このように、様々な例示的な実施形態は、多様なソースから発生する複数のメッセージの動的なバインドを可能にする点は明らかであろう。詳細には、セッションバインド識別子を使用することによって、ＰＣＲＦは、同じ情報セットを含み得るメッセージをバインドすることが可能であり、適用可能なセッション内でそのようなメッセージを実施することが可能である。

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

様々なデータサービスを提供するためのある例示的な加入者ネットワークを示す図である。 ＰＣＲＮが複数のソースから複数の関連するメッセージを受信するためのある例示的なネットワークを示す図である。 ＰＣＲＮ内の複数のメッセージを処理するためのある例示的なポリシーおよび課金規則ノード（ＰＣＲＮ）と、その構成要素であるＰＣＲＮブレードを示す図である。 ゲートウェイによって作成された新しいセッションを確立するためのある例示的な方法を示す図である。 ＩＰ−ＣＡＮセッションを複数のゲートウェイからの主ゲートウェイとバインドするためのある例示的な方法を示す図である。 新しいＩＰ−ＣＡＮセッションまたはゲートウェイ制御セッションをマッチする既存のセッションにバインドするためのある例示的な方法を示す図である。 アプリケーションノード（ＡＮ）によって確立されたセッションをゲートウェイによって確立されたＩＰ−ＣＡＮセッションにバインドするためのある例示的な方法を示す図である。

次に、類似の数字が類似の構成要素またはステップを指す図面を参照して、様々な例示的な実施形態の幅広い態様が開示される。

図１は、様々なデータサービスを提供するためのある例示的な加入者ネットワーク１００を示す。例示的な加入者ネットワーク１００は、様々なサービスに対するアクセスを提供するための通信ネットワークまたはその他のネットワークであってよい。例示的な加入者ネットワーク１００は、ユーザ装置１１０と、基地局１２０と、進化型パケットコア（ＥＰＣ）１３０と、パケットデータネットワーク１４０と、アプリケーションノード（ＡＮ）１５０とを含むことが可能である。

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

基地局１２０は、ユーザ装置１１０とＥＰＣ１３０との間の通信を可能にするデバイスであってよい。例えば、基地局１２０は、３ＧＰＰ標準によって定義されるような進化型ノードＢ（ｅノードＢ）など、ベーストランシーバステーションであってよい。したがって、基地局１２０は、無線通信など、第１の媒体を経由してユーザ装置１１０と通信し、イーサネット（登録商標）ケーブルなど、第２の媒体を経由してＥＰＣ１３０と通信するデバイスであってよい。基地局１２０は、ＥＰＣ１３０と直接通信することも、またはいくつかの中間ノード（図示せず）を経由して通信することもできる。様々な実施形態では、複数の基地局（図示せず）は、ユーザ装置１１０に移動性を提供するために存在する場合がある。様々な代替実施形態では、ユーザ装置１１０は、進化型パケットコアと直接通信することができる点に留意されたい。そのような実施形態では、基地局１２０は存在しなくてよい。

進化型パケットコア（ＥＰＣ）１３０は、パケットデータネットワーク１４０に対するゲートウェイアクセスをユーザ装置１１０に提供するデバイス、またはデバイスのネットワークであってよい。ＥＰＣ１３０は、提供されたデータサービスの使用に関して加入者に課金して、特定の体感品質（ＱｏＥ）標準が満たされることを確実にすることがさらに可能である。したがって、ＥＰＣ１３０は、少なくとも一部、３ＧＰＰ ＴＳ２９．２１２標準、３ＧＰＰ ＴＳ２９．２１３標準、および３ＧＰＰ ＴＳ２９．２１４標準に従って実施可能である。したがって、ＥＰＣ１３０は、サービス提供ゲートウェイ（ＳＧＷ）１３２と、パケットデータネットワークゲートウェイ（ＰＧＷ）１３４と、ポリシーおよび課金規則ノード（ＰＣＲＮ）１３６と、加入プロファイルリポジトリ（ＳＰＲ）１３８とを含むことが可能である。

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

パケットデータネットワークゲートウェイ（ＰＧＷ）１３４は、パケットデータネットワーク１４０に対するゲートウェイアクセスを提供するデバイスであってよい。ＰＧＷ１３４は、ＳＧＷ１３２を経由してパケットデータネットワーク１４０に向けてユーザ装置１１０によって送られたパケットを受信する、ＥＰＣ１３０内の最後のデバイスである。ＰＧＷ１３４は、それぞれのサービスデータフロー（ＳＤＦ）に関するポリシーおよび課金制御（ＰＣＣ）規則を施行するポリシーおよび課金施行機能（ＰＣＥＦ）を含むことが可能である。したがって、ＰＧＷ１３４は、ポリシーおよび課金施行ノード（ＰＣＥＮ）であってよい。ＰＧＷ１３４は、例えば、パケットフィルタリング、ディープパケットインスペクション、および加入者課金サポートなど、いくつかの追加の特徴を含むことが可能である。

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

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

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

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

アプリケーションノード（ＡＮ）１５０は、アプリケーション機能部（ＡＦ）を含むデバイスであってよく、アプリケーションサービスをユーザ装置１１０に提供する。したがって、ＡＮ１５０は、例えば、ビデオストリーミングもしくは音声通信サービスをユーザ装置１１０に提供するサーバまたはその他のデバイスであってよい。ＡＮ１５０は、Ｒｘインターフェースを経由してＥＰＣ１３０のＰＣＲＮ１３６とさらに通信可能である。ＡＮ１５０がアプリケーションサービスをユーザ装置１１０に提供し始めるとき、ＡＮ１５０は、ＰＣＲＮ１３６に通知するために、ダイアメータプロトコルに従って、ＡＡ要求（ＡＡＲ）などの要求メッセージを生成することが可能である。この要求メッセージは、アプリケーションサービスを使用している加入者の識別、および要求されたサービスを提供するために確立されなければならない特定のサービスデータフローの識別などの情報を含むことが可能である。ＡＮ１５０は、Ｒｘインターフェースを経由して、そのようなアプリケーション要求をＰＣＲＮ１３６に通信することができる。

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

システム２００内で、ＡＮ２０１、ＰＧＷ２０３、Ｐ−ＳＧＷ２０４、およびＳＧＷ２０５など、複数のデバイスを通して複数の関連するメッセージを送ることが可能であり、それぞれのメッセージは最終的にＰＣＲＮ２０２に送られる。次いで、ＰＣＲＮ２０２は、それぞれのメッセージからの情報を利用して、受信されたメッセージが、ＰＣＲＮ２０２が受信した何らかのその他のメッセージに関連するかどうかを決定することが可能である。次いで、ＰＣＲＮ２０２は、共通の確立されたセッションを共有する関連メッセージを含むことも可能な任意のメッセージを一緒にバインドすることができる。

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

ＰＣＲＮ２０２は、Ｓｐインターフェースを経由してＳＰＲ２０６に問い合わせることによって、ＭＳＧ１が先に受信されたメッセージまたは記憶されたメッセージに関連するかどうかを決定することができる。ＰＣＲＮ２０２によって受信されたそれぞれのメッセージに関して、ＰＣＲＮ２０２は、セッションバインド識別子（ＳＢＩ）を構築することができる。次いで、ＰＣＲＮ２０２は、メッセージのＳＢＩ内に含まれた属性を使用して、ＳＰＲ２０６内に記憶された加入者プロファイルと比較することができる。ＳＢＩは、例えば、ＩＰｖ４アドレス、ＩＰｖ６プレフィックス、ＡＰＮ、および／または加入識別子を含めて、加入者プロファイル内に含まれた任意の情報およびすべての情報を含むことが可能である。しかし、メッセージのＳＢＩは、特定のメッセージ内に含まれた情報だけを有することができる。システム２００内で、例えば、ＡＮ２０１からＰＣＲＮ２０２に送られたＭＳＧ１のＳＢＩは、セッション識別子、ＩＰｖ４アドレス、ＡＰＮ、および加入識別子だけを含むことが可能であるが、ＳＢＩは、ＩＰｖ６プレフィックスを含まない。

ＰＣＲＮ２０２は、続いて別のデバイスから別のメッセージを受信することができる。例えば、Ｐ−ＳＧＷ２０４は、第２のメッセージ（ＭＳＧ２）をＰＣＲＮ２０２に送ることができる。第２のメッセージのＳＢＩは、ＭＳＧ１のＳＢＩと対照的に、セッション識別子と、ＡＰＮと、加入識別子とを含むことが可能である。ＰＣＲＮ２０２が２つのメッセージを直接比較する場合、ＭＳＧ１のＳＢＩ内およびＭＳＧ２のＳＢＩ内に含まれた情報は互いと直接マッチしない（例えば、セッションと加入識別子とはマッチしない）ため、ＰＣＲＮ２０２は、それらの２つのメッセージが関連することを決定しなくてもよい。実際には、直接マッチする２つのメッセージ内の唯一の情報は、例えば、ＡＰＮである可能性がある。しかし、ＰＣＲＮ２０２がＳＰＲ２０６内に記憶された加入プロファイルを使用するとき、ＰＣＲＮ２０２は、ＭＳＧ１およびＭＳＧ２が同じプロファイルに関連し、したがって、グループとしてバインドされて、処理されるべきであることを決定することが可能である。これは、例えば、ＭＳＧ１によって使用されるアプリケーションセッションをＭＳＧ２によって使用されるゲートウェイセッションとバインドすることを含むことが可能である。これは、これらのメッセージをＰＣＲＮ２０２の同じブレード内に記憶することを含むことも可能である。

次に図３を参照すると、ある例示的なポリシーおよび課金規則ノード（ＰＣＲＮ）が示される。ＰＣＲＮ３００は、それぞれ、システム１００および２００のＰＣＲＮ１３６ならびにＰＣＲＮ２０２に類似し得る。ＰＣＲＮ３００は、アクティブダイアメータプロキシエージェント（ＤＰＡ）３０１と、スタンバイＤＰＡ３０２と、複数のアクティブＰＣＲＮブレード３０３ａ−ｃと、複数のスタンバイＰＣＲＮブレード３０４ａ−ｃとを含むことが可能である。ＰＣＲＮ３００は、並列処理の実施によりパフォーマンスを強化するために、複数のＰＣＲＮブレード３０３ａ−ｃ、３０４ａ−ｃを含むことが可能であり、それぞれのＰＣＲＮブレード３０３ａ−ｃ、３０４ａ−ｃは、並列の冗長ＰＣＲＮエンジンを有する。ＰＣＲＮ３００が別のデバイスからメッセージを受信するとき、そのメッセージは、処理されて、複数の重複しないアクティブＰＣＲＮブレード３０３ａ−ｃのうちの１つの中に記憶され得る。ＰＣＲＮ３００は、メッセージをＰＣＲＮブレードのそれぞれのバックアップ３０４ａ−ｃ内に記憶することもできる。

ダイアメータプロキシエージェント（ＤＰＡ）３０１は、ＰＣＲＮ３００内のすべての設置されたＰＣＲＮブレード３０３ａ−ｃ、３０４ａ−ｃに関するプロキシとして機能することが可能である。ＤＰＡ３０１はアクティブであり、したがって、ＰＣＲＮ３００に送られたそれぞれのメッセージを受信し、次いで、指定された基準に基づいて、そのメッセージを特定のＰＣＲＮブレード、例えば、ＰＣＲＮブレード３０３ｂに導くことが可能である。例えば、ＤＰＡ３０１は、Ｓｐインターフェースを経由して、受信されたメッセージのＳＢＩをＳＰＲ１３８内に記憶された加入者プロファイルと比較するための表検索を実行することができる。代替実施形態では、ＤＰＡ３０１がメッセージを特定のＰＣＲＮブレード３０３ａ−ｃに転送するときに、ＤＰＡ３０１は受信されたすべてのメッセージのＳＢＩを記憶することができるため、ＤＰＡ３０１は、着信メッセージのＳＢＩを先に受信されたメッセージの記憶されたＳＢＩと比較することだけが可能である。着信メッセージのＳＢＩの解析がマッチという結果である場合、ＤＰＡ３０１は、その着信メッセージを関連するメッセージを処理しているＰＣＲＮブレードに転送することができる。そうでない場合、ＤＰＡ３０１は、着信メッセージをＰＣＲＮブレード３０３ａ−ｃに割り当てるために有用であるとして当業者に知られている他の基準または方法を用いることができる。

図２からの例に続いて、ＤＰＡ３０１は、第１のメッセージＭＳＧ１を受信することが可能である。そのメッセージは受信された第１のメッセージであるため、ＳＢＩの比較は、結果として、受信された先のメッセージとのマッチをもたらさないことになる。ＤＰＡ３０１は、したがって、宛先ＰＣＲＮブレード３０３ａ−ｃを選択するために、別の方法を用いることができる。例えば、ＤＰＡ３０１は、特定のブレードを過負荷にしないように、ＰＣＲＮブレード３０３ａ−ｃを選択するために負荷分散技術を使用することができる。その他の実施形態では、ＤＰＡ３０１は、加えて、または代わりに、ラウンドロビン技術を用い、結果として、ＰＣＲＮブレード３０３ａ−ｃに関する待ち行列をもたらすことが可能であり、この場合、ＤＰＡ３０１は、まず、新しいマッチしないメッセージをＰＣＲＮブレード３０３ａに送り、次いで、次に新しいマッチしないメッセージＰＣＲＮブレード３０３ｂを送ることができる、等々である。代替実施形態は、ＤＰＡ３０１に２つの技術の組合せを使用させることが可能であり、ＤＰＡ３０１は、まず、負荷分散技術を使用し、目標ＰＣＲＮブレード３０３ａ−ｃに関して等しく実行可能な候補が存在する場合、次いで、ラウンドロビン技術を使用する。当業者は、着信メッセージを候補ＰＣＲＮブレード３０３ａ−ｃに割り当てるための他の技術に精通していよう。この例では、ＤＰＡ３０１は、ＭＳＧ１をＰＣＲＮブレード３０３ａに割り当てる。

ＭＳＧ１をＰＣＲＮブレード３０３ａに割り当てる間、ＤＰＡ３０１は、ＭＳＧ１のＳＢＩを含むＭＳＧ１の位置および宛先ＰＣＲＮブレード（すなわち、ＰＣＲＮブレード３０３ａ）を記憶することができる。ＤＰＡ３０１は、スタンバイＤＰＡ３０２内に新しい相関をバックアップすることも可能である。ＭＳＧ１は、次いで、ＰＣＲＮ３０３ａに送られる。ＰＣＲＮ３０３ａは、まず、着信メッセージをスタンバイＰＣＲＮブレード３０４ａ内に記憶することができる。ＰＣＲＮブレード３０３ａは、まず、着信メッセージのセッションＩＤを検査して、着信メッセージのソースを決定することができる。これは、図４−６に関して下で議論されるように、ＰＣＲＮブレード３０３ａがどの検査方法を使用することになるかを決定できる。マッチするメッセージが存在しないため、ＰＣＲＮブレード３０３ａは、次いで、着信メッセージのセッションＩＤに基づいて、ＭＳＧ１に関する新しいセッションを用いることが可能である。例えば、ＭＳＧ１は、ＰＣＲＮブレード３０３ａにアプリケーションセッションを開始させることが可能な「ＡＦセッション」のセッションＩＤを有することができる。例えば、Ｇｘインターフェースを経由して、ＰＧＷ１３４と通信して、作成されたポリシー課金制御（ＰＣＣ）規則をゲートウェイに転送するために、ＰＣＲＮブレード３０３ａは、作成されたアプリケーションセッションを用いて新しいＩＰ−ＣＡＮセッションを確立することも可能である。

ＤＰＡ３０１は、図２に関して上で議論されたように、後のある時点で、第２のメッセージＭＳＧ２を受信することができる。したがって、この例では、ＭＳＧ２は、ＭＳＧ１に関連し、それぞれのメッセージのＳＢＩは同じ一意の加入者に属するため、リンクされたＳＢＩを有する。したがって、ＤＰＡ３０１がＳｐインターフェースを経由して、その記憶されたＳＢＩおよび対応する加入者プロファイルに対してＭＳＧ２のＳＢＩを比較するとき、その結果は、リンクされたＳＢＩの共通加入者プロファイルによるＭＳＧ１とＭＳＧ２との間の関係であり得る。結果として、ＤＰＡ３０１は、関連するメッセージＭＳＧ１の宛先を決定することができ、これは、この例では、ＰＣＲＮブレード３０３ａである。次いで、ＤＰＡ３０１は、第２のメッセージＭＳＧ２をＭＳＧ１と同じＰＣＲＮブレード（ＰＣＲＮブレード３０３ａ）に転送して、第２のメッセージの宛先ＰＣＲＮブレード３０３ａを記憶することが可能である。

ＰＣＲＮブレード３０３ａに達した後で、ＰＣＲＮブレード３０３ａは、まず、第２のメッセージのセッションＩＤを検査することによって、第２のメッセージの発信元を決定することができる。これは、図４−６に関して下で議論されるように、ＰＣＲＮブレード３０３ａが用いることになる検査方法を決定できる。この例では、ＭＳＧ２は、「ＧＷＣ２」のセッションＩＤを有し、これは、ＰＣＲＮブレード３０３ａに、まず、ゲートウェイ制御セッションを確立させる。図５に関して議論されるように、ＰＣＲＮブレード３０３ａは、次いで、着信メッセージのＳＢＩの他の基準を調査して、ＰＣＲＮブレード３０３ａが第１のメッセージを受信したとき、新しく確立されたゲートウェイ制御セッションを確立されたＩＰ−ＣＡＮセッションとバインドするかどうかを決定することができる。ＡＰＮがマッチし、加入ＩＤが同じ加入者に属すとき、組み合わされたアプリケーションと、ゲートウェイ制御と、ＩＰ−ＣＡＮセッションとを使用して、第１のメッセージＭＳＧ１および第２のメッセージＭＳＧ２がＰＣＲＮブレード３０３ａ内でバインドされた状態で、ＰＣＲＮブレード３０３ａはゲートウェイ制御セッションとＩＰ−ＣＡＮセッションとをバインドすることができる。図４−５に関して下で議論されるように、ＰＣＲＮブレード３０３ａは、ＰＧＷ１３４、および非主ゲートウェイＳＧＷ２０５など、他のデバイスからの後続のメッセージをすべてＰＣＲＮブレード３０３ａ内で確立されたセッションを共有するメッセージとマッチさせることも可能である。

次に図４を参照すると、確立されたセッションを用いて新しいゲートウェイセッションを作成するために、ＰＣＲＮ２０２によって実行されるある例示的な方法が提供される。ＰＣＲＮ２０２がＰＧＷ２０３、Ｐ−ＳＧＷ２０４、またはＳＧＷ２０５からメッセージを受信するとき、そのメッセージは新しいセッション要求をトリガする可能性がある。ＰＣＲＮブレード３０３ａ−ｃは、その要求に基づいて、新しいセッションを確立するかどうかを決定するために、方法４００を用いることができる。

方法４００は、ＰＣＲＮ２０２がＧｘインターフェースまたはＧｘｘインターフェースのいずれかを経由して着信メッセージから新しいセッション確立要求を受信することが可能なステップ４０１−４０３から始まる。メッセージがＧｘｘインターフェースを経由してサービスゲートウェイ（Ｐ−ＳＧＷ２０４またはＳＧＷ２０５）から受信される場合、新しいセッション要求は、新しいゲートウェイ制御セッションに関連し得る。そうでなければ、メッセージがＧｘインターフェースを経由してパケットデータネットワークゲートウェイＰＧＷ２０３から受信される場合、新しいセッション要求は、新しいＩＰ−ＣＡＮセッションに関連し得る。次いで、ＰＣＲＮ２０２は、ステップ４０９−４３３に進むことができ、ここで、ＰＣＲＮ２０２は着信メッセージのＳＢＩの様々な属性を検査して、その要求内で指定されたセッションと完全にまたは部分的にマッチする既存のセッションがすでに存在するかどうかを決定することができる。

新しいセッション確立要求の受信に続いて、ステップ４０９−４１９において、ＰＣＲＮは、まず、着信メッセージのＳＢＩが指定された属性を含むかどうかを決定することができる。ステップ４０９において、ＰＣＲＮ２０２は、ＭＳＧ１に関するＳＢＩがセッションＩＤを含むかどうかを決定することができる。属性がＳＢＩ内に含まれている場合、ＰＣＲＮ２０２は、次のステップ（ステップ４１１）において、その属性がいずれかの先のメッセージの属性とマッチするかどうかを決定することができ、そうでない場合、それぞれの新しいセッションに関するセッションＩＤが要求される可能性があるため、ステップ４１２において、新しいセッション要求はＰＣＲＮ２０２によって拒否され得る。例えば、ＭＳＧ１は、「ＡＦセッション」に対応するセッションＩＤを含む。したがって、ステップ４１１において、ＰＣＲＮ２０２は、既存のセッションが対応するセッションＩＤをすでに有するかどうかを決定することができる。既存のセッションが存在する場合、新しいセッション要求は無効になる可能性があり、ＰＣＲＮ２０２はステップ４１２に進むことができ、この場合、セッションＩＤが一意である可能性があり、したがって、いずれのマッチも、ＳＢＩ内のいずれの他の値にもかかわらず、マッチするセッションを表示する可能性があるため、新しいセッション要求はＰＣＲＮ２０２によって拒否され得る。しかし、マッチするセッションＩＤが存在しないとき、ＰＣＲＮ２０２は、ＳＢＩ内の他の属性に関して検査するためにステップ４１３に進むことができる。

次に、ステップ４１３を参照すると、（ＩＰｖ４アドレスに関する）ステップ４１３−４１５および（ＩＰｖ６プレフィックスに関する）ステップ４１７−４１９は類似しており、この場合、ＰＣＲＮ２０２は、まず、第１のステップで、ＳＢＩが関連情報を含むかどうかを決定するために検査することが可能であり、メッセージがそのような情報を含むとき、その情報が既存のセッションとマッチするかどうかを検査する。マッチが存在する場合、ＰＣＲＮ２０２は、新しいセッション要求のＡＰＮに対して既存のセッションのＡＰＮを検査するために、ステップ４２７に進むことができる。そうでない場合、関連情報が含まれていない場合、または関連情報がマッチしない場合、方法４００は、次いで、別の属性の検査に進むことができる。

単一の加入者は複数の加入ＩＤを所有することが可能であるため、ステップ４２３において、ＰＣＲＮ２０２が、マッチを単に探す代わりに、加入ＩＤが同じ加入者に属するかどうかを決定することができる点を除いて、ステップ４２１−４２３は４０９−４１９の先のステップに類似する。例えば、ステップ４２３において、ＰＣＲＮ２０２がＭＳＧ１とＭＳＧ２とを比較するとき、ＰＣＲＮ２０２は、実際の加入ＩＤがマッチしない場合ですら、ＭＳＧ１の加入ＩＤ「ｅ」とＭＳＧ２の加入ＩＤ「ｂ」とが同じ加入者（「Ｊｏｅ」）に属することを決定することができる。属性のうちのいずれかが既存の属性とマッチする場合、その要求は無効である可能性があり、ＰＣＲＮ２０２はステップ４２７に進むことができ、ここで、ＰＣＲＮ２０２は、新しいセッション確立要求のＡＰＮに対して既存のセッションのＡＰＮを比較する。そうでない場合、ＰＣＲＮ２０２はステップ４２５に進むことができ、ここで、ＰＣＲＮ２０２は、その要求に応答して新しいセッションを作成することができる。新しいセッションを作成するとき、ＰＣＲＮ２０２は、そのメッセージが新しいゲートウェイ制御セッションを要求したときですら、ＩＰ−ＣＡＮセッションを確立することも可能である。図５に関して下で議論されるように、２つのセッションに関する属性はマッチし、ゲートウェイ制御セッションはＰＣＲＮ２０２によって作成された最新のタイプのそのようなセッションであったため、ＰＣＲＮ２０２は、次いで、新しく確立されたゲートウェイ制御セッションをＩＰ−ＣＡＮセッションとバインドすることができる。

ステップ４２７において、ＰＣＲＮ２０２は、まず、ＳＢＩがＡＰＮを含むかどうかを決定する。ＡＰＮがＳＢＩ内に含まれている場合、ステップ４２９において、ＰＣＲＮ２０２は、他の先のメッセージのＡＰＮとのマッチが存在するかどうかを決定する。マッチが存在しない場合、ＰＣＲＮ２０２は、ステップ４３３において、要求された新しいセッションを確立することができる。しかし、マッチするＡＰＮが存在する場合、またはＡＰＮが含まれていない場合、ＰＣＲＮ２０２は、ステップ４３１において、ステップ４１２と類似のステップで新しいセッション要求を拒否することができる。メッセージは他の共通の属性を有する場合があり、異なるＳＢＩが依然として異なるセッションを要求するため、ＰＣＲＮ２０２は、まず、ＡＰＮを検査することが可能である。例えば、第１のメッセージＭＳＧ−Ａは、「ｆｏｏ」のＡＰＮを有する１０．１．１．１のＩＰｖ４アドレスを有する場合がある。しかし、第２のメッセージＭＳＧ−Ｂも、１０．１．１．１のＩＰｖ４アドレスを有するが、「ｂａｒ」のＡＰＮを有した場合、これら２つのメッセージは、同じセッションを共有しないことになる。しかし、いずれのメッセージもＡＰＮを有さない（すなわち、ＡＰＮがヌルに等しい）場合、そのそれぞれのＳＢＩ内の他の属性がマッチする場合、それらのメッセージは、依然として同じセッションを共有する。

次に図５Ａを参照すると、ゲートウェイセッションをバインドするある例示的な方法が示される。ＰＣＲＮ２０２は、ＤＰＡ３０１またはＰＣＲＮブレード３０３ａのいずれかを使用して、サービスゲートウェイ（Ｐ−ＳＧＷ２０４、ＳＧＷ２０５）に関連するゲートウェイ制御セッションとＰＧＷ２０３に関連するＩＰ−ＣＡＮセッションとをバインドするために方法５００を用いることが可能である。使用中のプロトコルに応じて、サービスゲートウェイは、ＰＣＲＮと通信できない場合がある。したがって、方法５００はステップ５０１−５０３に進み、ここで、ＰＣＲＮ２０２は、まず、使用中の通信プロトコルのタイプを決定することができる。使用中のプロトコルがＧＰＲＳトンネリングプロトコル（ＧＴＰ）である場合、ＰＧＷ２０３はＰＣＲＮ２０２と通信中の唯一のゲートウェイである。ＰＣＲＮ２０２は、したがって、ステップ５０４に進むことができ、ここで、ＰＣＲＮ２０２はＧｘインターフェースを経由してＩＰ−ＣＡＮセッションを作成することができる。

しかし、使用中のプロトコルがＰＭＩＰである場合、ＰＧＷ２０３とサービスゲートウェイ２０４、２０５は両方ともＰＣＲＮ２０２と通信することが可能である。ＰＭＩＰの事例では、１つのＩＰ−ＣＡＮセッションだけが存在する場合があるが、１つまたは複数のサービスゲートウェイ２０４、２０５によって作成された複数のゲートウェイ制御セッションが存在する場合もある。ＰＣＲＮ２０２は、したがって、複数のサービスゲートウェイ２０４、２０５のうちの１つを主ゲートウェイ２０４として指定することを試みることができ、一方、他方のゲートウェイ２０５は非主ゲートウェイまたはバックアップゲートウェイのいずれかであってよい。ＰＣＲＮ２０２は、主ゲートウェイ２０４の割当ての基礎を、それぞれのＩＰ−ＣＡＮセッションおよびゲートウェイ制御セッションに関して作成されたＳＢＩの属性に応じたＩＰ−ＣＡＮセッションとの最善のマッチに置くことができる。例えば、ＰＧＷ２０３に関連するＩＰ−ＣＡＮセッションは、非主ゲートウェイ２０５に関連する第１のゲートウェイ制御セッション（ＧＷＣ１）と主ゲートウェイ２０４に関連する第２のゲートウェイ制御セッション（ＧＷＣ２）の両方にバインド可能である。ＩＰ−ＣＡＮセッションは、両方にバインド可能であるが、主制御セッションとして指定された第２のゲートウェイ制御セッションＧＷＣ２を有する。

したがって、ステップ５０５において、ＰＣＲＮ２０２は、ＩＰ−ＣＡＮセッションの属性に対してゲートウェイ制御セッションの属性を検査することができる。これは、ＳＢＩ内の２つの属性がマッチするかどうかを決定するために、ＰＣＲＮ２０２によって用いられる方法４００に類似し得る。しかし、ステップ５０５において、それらのセッションがバインドされるためには、すべての属性はマッチしなければならない（すなわち、ＩＰｖ４アドレスとＩＰｖ６プレフィックスはマッチし、加入ＩＤは同じ加入者に属し、それらのＡＰＮはマッチするか、または両方とも存在しない）（下で議論されるように、これは、図６に関連して用いられたマッチ基準方法に類似し得る）。可能性のあるゲートウェイ制御セッションがＩＰ−ＣＡＮセッションのすべての属性とマッチする場合、ＰＣＲＮ２０２は、次いで、ステップ５０７に進むことができ、ここで、そのバインドの記録がデータベース内に記録されて、ゲートウェイ制御セッションがＩＰ−ＣＡＮセッションにバインドされ得る。ゲートウェイ制御セッションがＩＰ−ＣＡＮセッションのすべての基準とマッチしない場合、ステップ５０８において、ＰＣＲＮ２０２は、データベース内に新しいセッションを作成することができるが、適切なマッチが見つかるまで、新しいセッションは、ＩＰ−ＣＡＮセッションにバインドされていない状態に残ることが可能である。

次に、図５Ｂを参照すると、ＰＣＲＮ２０２が新しいＩＰ−ＣＡＮセッションおよびゲートウェイ制御セッションを適切なマッチにバインドする関連方法が例示される。新しいＩＰ−ＣＡＮセッションまたは新しいゲートウェイセッションのいずれかが作成された場合、ＰＣＲＮ２０２は、既存のメイトセッションをそのセッションにバインドするために方法５１２を用いることができる。新しいセッションは、主または非主／バックアップのいずれかとして、１つまたは複数のゲートウェイ制御セッションの再度の割当てを伴う場合もある。新しいセッションを受信した後で、ステップ５０９において、ＰＣＲＮ２０２は、新しく確立されたセッションに関してマッチするセッションが存在するかどうかを決定することができる。これは、例えば、ＩＰｖ４アドレス、ＩＰｖ４プレフィックス、一意の加入者識別、およびマッチするＡＰＮをマッチさせる、図５Ａに関して上で議論されたステップと類似のステップを伴う場合がある。マッチするセッションが存在しない場合、ＰＣＲＮ２０２はステップ５１０に進むことができ、ここで、データベース内に新しいセッションが確立されるが、適切なマッチが見つかるまで、そのセッションはバインドされていない状態に残ることが可能である。

新しいセッションが確立されるとき、ステップ５１１において、ＰＣＲＮ２０２は、確立されている新しいセッションのタイプを決定する。新しいＩＰ−ＣＡＮセッションが確立されているとき、方法５１２はステップ５１３に進むことができ、ここで、新しいＩＰ−ＣＡＮセッションは、すべて新しいＩＰ−ＣＡＮセッションの基準とマッチする複数の候補ゲートウェイ制御セッションにバインドされ得る。この複数の候補ゲートウェイ制御セッションから、ＩＰ−ＣＡＮセッションのすべての基準とマッチするだけでなく、新しいＩＰ−ＣＡＮセッションを確立する要求と同じＩＰ−ＣＡＮタイプも有するゲートウェイ制御セッションは、そのバインドの記録がデータベース内に記憶されて、主ゲートウェイ制御セッションとしてＰＣＲＮ２０２によってバインド可能である。マッチする基準と、新しいＩＰ−ＣＡＮセッションに対するＩＰ−ＣＡＮタイプの両方を有する複数のゲートウェイ制御セッションが存在する場合、新しいＩＰ−ＣＡＮセッションは、最後に作成されたゲートウェイ制御セッションを主として割り当てることができる。その後、ステップ５１５において、新しいＩＰ−ＣＡＮセッションの基準にマッチする他のゲートウェイ制御セッションも、そのバインドの記録がデータベース内に記憶されて、ＰＣＲＮ２０２によって新しいＩＰ−ＣＡＮセッションにバインド可能である。

ステップ５１１に戻ると、新しいゲートウェイ制御セッションが確立されている場合、ステップ５１７において、ＰＣＲＮ２０２は、データベース内にそのバインドを記録する間に、新しいゲートウェイ制御セッションをマッチする属性を有する既存のＩＰ−ＣＡＮセッションにバインドすることができる。ステップ５１９において、ＰＣＲＮ２０２は、次いで、新しいゲートウェイ制御セッションを確立する要求のＩＰ−ＣＡＮタイプを検査して、それが、マッチするＩＰ−ＣＡＮセッションのＩＰ−ＣＡＮタイプとマッチするかどうかを決定することができる。マッチが存在する場合、ＰＣＲＮ２０２は、次いで、ステップ５２１において、新しいゲートウェイ制御セッションを主として割り当てることができる。次に、ステップ５２５において、ＰＣＲＮは、次いで、いずれかの先の主ゲートウェイ制御セッションを非主ゲートウェイ制御セッション／バックアップゲートウェイ制御セッションとして再度割り当て、その再度の割当てをデータベース内に記録することができる。しかし、ステップ５１９において、新しいゲートウェイ制御セッションのＩＰ−ＣＡＮタイプおよびＩＰ−ＣＡＮセッションがマッチしないことが分かった場合、ステップ５２５において、新しいゲートウェイ制御セッションは、ＰＣＲＮ２０２によって非主ゲートウェイとしてＩＰ−ＣＡＮセッションにバインド可能である。

次に図６を参照すると、アプリケーションセッションをＩＰ−ＣＡＮセッションにバインドするためのある例示的な方法が示される。アプリケーションノード（ＡＮ）２０１によって確立されたアプリケーションセッションは、ＩＰ−ＣＡＮセッションにバインド可能である。ＰＣＲＮ２０２は、着信メッセージのＳＢＩ属性を使用して、確立されたＩＰ−ＣＡＮセッションとマッチさせるために、方法６００を用いることができる。図４の方法４００に類似して、すべての利用可能な属性がＩＰ−ＣＡＮセッション基準とマッチする場合、ＰＣＲＮ２０２はステップ６２９に進むことができ、ここで、アプリケーションセッションは、ＰＣＲＮ２０２によって見出されたマッチするＩＰ−ＣＡＮセッションにバインドされる。そうでない場合、アプリケーションセッションのＳＢＩからの利用可能な属性のうちのいずれかが目標ＩＰ−ＣＡＮセッションの基準とマッチしない場合、ＰＣＲＮ２０２は、目標ＩＰ−ＣＡＮセッションがバインドに関して利用可能でない可能性があるステップ６３１に進むことができる。

ステップ６０５−６０６は、ＰＣＲＮ２０２が、アプリケーションセッションのＡＰＮと目標ＩＰ−ＣＡＮセッションのＡＰＮとがマッチするかどうかを確かめるために、それらのＡＰＮを比較することが可能な、図４の方法４００のステップ４２７−４２９に類似し得る。しかし、アプリケーションセッションのＡＰＮとＩＰ−ＣＡＮセッションのＡＰＮとがマッチする場合、またはアプリケーションセッションに関して利用可能なＡＰＮが存在しない場合、ＰＣＲＮ２０２はステップ６１３に進むことができ、ここで、ＰＣＲＮ２０２は、アプリケーションセッション内の別の潜在的なＳＢＩ属性を調査することができる。そうでない場合、アプリケーションセッション内の利用可能なＡＰＮがＩＰ−ＣＡＮセッションのＡＰＮとマッチしない場合、ＰＣＲＮ２０２はステップ６３１に進むことができ、ここで、セッションはバインドされていない状態に残ることが可能である。ステップ６１３−６１５（ＩＰｖ４アドレス）およびステップ６１７−６１９（ＩＰｖ６プレフィックス）は、アプリケーションセッションのＳＢＩ内の何らかの利用可能な属性が目標ＩＰ−ＣＡＮセッションの基準とマッチすることを確実するステップ６０５−６０６に類似し得る。

ステップ６２１において、ＰＣＲＮ２０２は、アプリケーションセッションの複数の加入ＩＤを検査することができる。加入ＩＤがマッチすることを確実にする代わりに、ＰＣＲＮ２０２は、ＰＣＲＮ２０２が、アプリケーションセッションの加入ＩＤに関連する加入者がやはりＩＰ−ＣＡＮセッションの加入ＩＤにも関連することを確実にすることが可能なステップ４２３に類似した形で動作することができる。先のステップに類似して、加入者がマッチする場合、ＰＣＲＮ２０２は、続いて次の属性を検査することができ、加入者がマッチしない場合、セッションは一緒にバインドされない。

ステップ６２５において、ＰＣＲＮ２０２は、バインドに関する目標として、マッチするＩＰ−ＣＡＮセッションが見出されたことを再度確認することができる。マッチするＩＰ−ＣＡＮセッションが見出された場合、ステップ６２７において、ＰＣＲＮ２０２は、アプリケーションセッションのＳＢＩ内のすべての利用可能な属性がそのＩＰ−ＣＡＮセッション内の適用可能な基準とマッチすることを再度確実にすることができる。属性がマッチする場合、ＰＣＲＮ２０２は、次いで、ステップ６２９に進むことができ、ここで、目標ＩＰ−ＣＡＮセッションが使用されて、アプリケーションセッションにバインドされる。基準がマッチしない場合、またはマッチするＩＰ−ＣＡＮセッションが見出されない場合、ＰＣＲＮ２０２はステップ６３１に進むことができ、ここで、ＰＣＲＮ２０２は、アプリケーションセッションを目標ＩＰ−ＣＡＮセッションとバインドしない。

前述の説明によれば、様々な例示的な実施形態は、ＰＣＲＮによって受信されたとき、様々なソースからメッセージの動的な関連付けを実現する。詳細には、それぞれの着信メッセージ内に含まれたセッションバインド識別子（ＳＢＩ）の利用可能な属性を比較することによって、ＰＣＲＮは、ＰＣＲＮの下位構成要素内にメッセージとその適用可能なセッションとを一緒に関連付けることができる。

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

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

様々な例示的な実施形態は、それらのある例示的な態様を特に参照して詳細に説明されているが、本発明は、他の実施形態が可能であり、その詳細は、様々な自明な点で修正可能である点を理解されたい。当業者に容易に明らかになるように、本発明の趣旨内および範囲内にとどまりながら、改変形態および修正形態が取られうる場合がある。従って、前述の開示、説明、および図面は、例示のためだけであり、特許請求の範囲によってだけ定義される本発明を決して限定しない。

Claims (10)

1. 複数のデバイスから受信された少なくとも２つのメッセージを関連付けるために、ダイアメータデバイスによって実行される方法であって、
   第１のデバイスから、第１の識別子を含む第１のメッセージを受信するステップと、
   第１のメッセージを処理するステップであって、処理は、第１のポリシーおよび課金規則ノード（ＰＣＲＮ）ブレードが第１のセッションを生成することをもたらす、処理するステップと、
   第２のデバイスから、第１の識別子とは異なる第２の識別子を含む第２のメッセージを受信するステップと、
   第２のメッセージが、ゲートウェイ制御セッションまたはアプリケーションノードセッションに関連しているかどうかを決定するステップと、
   第２のメッセージがゲートウェイ制御セッションに関連していることに基づいて、第２の識別子が、第１の識別子にマッチするかどうかを第１のマッチング方法にしたがって決定するステップと、
   第２のメッセージがアプリケーションノードセッションに関連していることに基づいて、第２の識別子が、第１の識別子にマッチするかどうかを第２のマッチング方法にしたがって決定するステップであって、第２のマッチング方法は、第１のマッチング方法と異なる、決定するステップと、
   第２の識別子が第１の識別子にマッチするという決定に基づいて、関連性に基づき第２のメッセージを処理するステップとを含む、方法。
2. 第１の識別子が、第１のセッションバインド識別子（ＳＢＩ）であり、第２の識別子が、第２のＳＢＩであり、第１のＳＢＩおよび第２のＳＢＩは、それぞれ、
   セッション識別、
   ＩＰｖ４アドレス、
   ＩＰｖ６アドレス、
   アクセスポイント名（ＡＰＮ）、および
   少なくとも１つの加入識別（ＳＩＤ）のうちの少なくとも１つを含み、
   第１のＳＢＩと第２のＳＢＩとを構成する属性が少なくとも１つの加入者プロファイルレコード内の属性も含む、請求項１に記載の方法。
3. 第１のマッチング方法は、第１のＳＢＩのＡＰＮが第２のＳＢＩのＡＰＮと同じであり、第１のＳＢＩのＩＰｖ４アドレスが、第２のＳＢＩのＩＰｖ４アドレスと同じであり、第１のＳＢＩのＩＰｖ６アドレスが、第２のＳＢＩのＩＰｖ６アドレスと同じであり、第１のＳＢＩの少なくとも１つのＳＩＤが、第２のＳＢＩの少なくとも１つのＳＩＤと同じ加入者に対応するときだけ、第２の識別子が第１の識別子とマッチすることを決定するステップを含む、請求項２に記載の方法。
4. 第１のマッチング方法および第２のマッチング方法のうちの少なくとも１つは、
   第２の識別子が加入者プロファイルレコードに対応することを決定するステップと、
   第１の識別子が加入者プロファイルレコードに対応するかどうかを決定するステップと、
   第１の識別子が加入者プロファイルレコードに対応するという決定に基づいて、第２の識別子が第１の識別子にマッチすることを決定するステップと、
   第１の識別子が加入者プロファイルレコードに対応しないという決定に基づいて、第２のメッセージを処理するステップであって、処理は、第２のＰＣＲＮブレードが第２のセッションをもたらす、処理するステップとを含む、請求項１に記載の方法。
5. 第２のマッチング方法は、
   第２のＳＢＩがＡＰＮを搬送するかどうかを決定するステップと、
   第２のＳＢＩがＡＰＮを搬送することに基づいて、第２のＳＢＩのＡＰＮが、第１のＳＢＩのＡＰＮと同じであるかどうかを決定するステップと、
   第２のＳＢＩがＩＰｖ４アドレスを搬送するかどうかを決定するステップと、
   第２のＳＢＩがＩＰｖ４アドレスを搬送することに基づいて、第２のＳＢＩのＩＰｖ４アドレスが、第１のＳＢＩのＩＰｖ４アドレスと同じであるかどうかを決定するステップと、
   第２のＳＢＩがＩＰｖ６アドレスを搬送するかどうかを決定するステップと、
   第２のＳＢＩがＩＰｖ６アドレスを搬送することに基づいて、第２のＳＢＩのＩＰｖ６アドレスが、第１のＳＢＩのＩＰｖ６アドレスと同じであるかどうかを決定するステップと、
   第２のＳＢＩが、少なくとも１つのＳＩＤを搬送するかどうかを決定するステップと、
   第２のＳＢＩが少なくとも１つのＳＩＤを搬送することに基づいて、第２のＳＢＩの少なくとも１つのＳＩＤが、第１のＳＢＩの少なくとも１つのＳＩＤと同じ加入者に対応するかどうかを決定するステップと、
   第２のＳＢＩが、ＡＰＮ、ＩＰｖ４アドレス、ＩＰｖ６アドレスおよび少なくとも１つのＳＩＤ、のうちの少なくとも１つを搬送しないとき、第２の識別子が第１の識別子にマッチすることを決定するステップとを含む、請求項２に記載の方法。
6. 第２のマッチング方法が、第２の識別子が第１の識別子にマッチすることを決定するステップは、
   第２のＳＢＩによって搬送されるＡＰＮ、ＩＰｖ４アドレス、ＩＰｖ６アドレスおよび少なくとも１つのＳＩＤのすべての基準が、第１のＳＢＩによって搬送される対応する基準と同じであるかどうかを決定するステップをさらに含む、請求項５に記載の方法。
7. 第２のメッセージの通信プロトコルを決定するステップであって、第２のメッセージが第１のゲートウェイ制御セッションと相関するセッションＩＤを含む、決定するステップと、
   第２のメッセージの第２のＳＢＩおよび第１のメッセージの第１のＳＢＩが同じ加入者プロファイルと相関するとき、主ゲートウェイとして、第１のゲートウェイ制御セッションをＩＰ−ＣＡＮセッションにバインドするステップと
   をさらに含む、請求項５に記載の方法。
8. 第３のデバイスから、第３の加入者プロファイルに関連する少なくとも１つの属性を含む第３のＳＢＩを含む第３のメッセージを受信するステップであって、第３のメッセージは、第２のゲートウェイ制御セッションと相関するセッションＩＤを含む、受信するステップと、
   第３のメッセージの第３のＳＢＩおよび第１のメッセージの第１のＳＢＩが同じ加入者プロファイルと相関するとき、主ゲートウェイとして、第２のゲートウェイ制御セッションをＩＰ−ＣＡＮセッションにバインドするステップと、
   第３のメッセージの第３のＳＢＩおよび第１のメッセージの第１のＳＢＩが同じ加入者プロファイルと相関するとき、非主ゲートウェイとして、第１のゲートウェイ制御セッションをＩＰ−ＣＡＮセッションにバインドするステップと
   をさらに含む、請求項７に記載の方法。
9. 複数のデバイスから受信された少なくとも２つのメッセージを関連付けるためのポリシーおよび課金規則ノード（ＰＣＲＮ）であって、
   第１のデバイスから、第１のセッションバインド識別子（ＳＢＩ）を含む少なくとも第１のメッセージを受信し、
   第２のデバイスから、第２のＳＢＩを含む第２のメッセージを受信し、
   第２のメッセージが、ゲートウェイ制御セッションまたはアプリケーションノードセッションに関連しているかどうかを決定し、
   第２のメッセージがゲートウェイ制御セッションに関連していることに基づいて、第２の識別子が、第１の識別子にマッチするかどうかを第１のマッチング方法にしたがって決定し、
   第２のメッセージがアプリケーションノードセッションに関連していることに基づいて、第２の識別子が、第１の識別子にマッチするかどうかを第２のマッチング方法にしたがって決定し、第２のマッチング方法は、第１のマッチング方法と異なり、
   第２の識別子が第１の識別子にマッチするという決定に基づいて、関連性に基づき第２のメッセージを処理する、
   ように構成されているダイアメータデバイスを具備する、ポリシーおよび課金規則ノード（ＰＣＲＮ）。
10. 第１および第２のＳＢＩは、それぞれ、
    セッション識別、
    ＩＰｖ４アドレス、
    ＩＰｖ６アドレス、
    アクセスポイント名（ＡＰＮ）、および
    少なくとも１つの加入識別（ＳＩＤ）のうちの少なくとも１つを含み、
    第１および第２のＳＢＩを構成する属性が少なくとも１つの加入者プロファイルレコード内の属性も含む、請求項９に記載のＰＣＲＮ。

Images