JP5468180B2 - サービス要求に基づいてｐｃｃルールを生成するためのシステムおよび方法 - Google Patents

Description

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

モバイル通信ネットワーク内における様々なタイプのアプリケーションに対する要求が高まるにつれて、サービスプロバイダは、この拡張された機能性を高い信頼性で提供するために、システムを常にアップグレードし続けなければならない。かつては単に音声通信のためだけに設計されたシステムであったものが、テキストメッセージング、マルチメディアストリーミング、および一般的なインターネットアクセスを含む、多数のアプリケーションへのアクセスを提供する、汎用ネットワークアクセスポイントに成長した。第２世代および第３世代ネットワークに見られるように、音声サービスは、専用音声チャネルを介して搬送され、回路交換コアに送られるが、他のサービス通信は、インターネットプロトコル（ＩＰ）に従って伝送され、異なるパケット交換コアに送られる。このことが、アプリケーション提供、計測および課金、ならびにエクスペリエンス品質（ＱｏＥ）保証に関する特有の問題を引き起こす。

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

３ＧＰＰは、数多くの技術仕様書において、ＥＰＣの構成要素と、それらが互いに行う対話について全般的に説明している。具体的には、３ＧＰＰ ＴＳ ２９．２１２、３ＧＰＰ ＴＳ ２９．２１３、３ＧＰＰ ＴＳ ２９．２１４は、ＥＰＣのポリシーおよび課金ルール機能（ＰＣＲＦ：Ｐｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｒｕｌｅｓ Ｆｕｎｃｔｉｏｎ）、ポリシーおよび課金施行機能（ＰＣＥＦ：Ｐｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｅｎｆｏｒｃｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）、ベアラバインディングおよびイベント報告機能（ＢＢＥＲＦ：Ｂｅａｒｅｒ Ｂｉｎｄｉｎｇ ａｎｄ Ｅｖｅｎｔ Ｒｅｐｏｒｔｉｎｇ Ｆｕｎｃｔｉｏｎ）について説明している。さらに、これらの仕様書は、信頼性の高いデータサービスを提供し、その使用についての課金を加入者に対して行うために、これらの要素がどのように対話するかに関する、いくつかのガイダンスを提供する。

例えば、３ＧＰＰ ＴＳ ２９．２１２、２９．２１３、および２９．２１４仕様書は、ポリシーおよび課金制御（ＰＣＣ：ｐｏｌｉｃｙ ａｎｄ ｃｈａｒｇｉｎｇ ｃｏｎｔｒｏｌ）ルールの生成に関する、いくつかのガイダンスを提供する。３ＧＰＰ ＴＳ ２９．２１２は、ＰＣＲＦが、ＰＣＣルールを求める要求をＰＣＥＦから、またはサービス品質（ＱｏＳ）ルールを求める要求をＢＢＥＲＦから受信したときに、ＰＣＲＦによって取られるステップについて説明している。３ＧＰＰ ＴＳ ２９．２１３は、サービスデータフロー（ＳＤＦ）のための要求されたＱｏＳに基づいたＱｏＳ認可について説明している。３ＧＰＰ ＴＳ ２９．２１４は、ＰＣＲＦが、ＰＣＣルールを求める要求をアプリケーション機能（ＡＦ：ａｐｐｌｉｃａｔｉｏｎ ｆｕｎｃｔｉｏｎ）から受信したときに、ＰＣＲＦによって取られるステップについて説明している。

しかし、仕様書は、要求メッセージがＱｏＳ情報を十分に提供しない場合に、ＰＣＣルールをどのように生成するかについて説明していない。例えば、ＡＦからの要求は、必ずしもすべてのメディアサブコンポーネント（ｍｅｄｉａ ｓｕｂ−ｃｏｍｐｏｎｅｎｔ）についてのＱｏＳ情報を含まないことがある。仕様書は、情報が不足している場合にＰＣＣルールを生成するための詳細を僅かしか提供しない。ＰＣＥＦからの要求も、複数のパケットフィルタを含む場合に、同じ問題に直面する。

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

上述の事柄に鑑みて、不完全なＱｏＳ情報を用いてトラフィックマッピングについてのＰＣＣルールを生成することが可能なＰＣＲＦを実施する、ポリシーおよび課金ルールノード（ＰＣＲＮ：Ｐｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｒｕｌｅｓ Ｎｏｄｅ）を提供することが望ましい。特に、ＱｏＳ情報が不完全なことがあっても、サービス要求を効果的に実行するＰＣＣルールを生成することが望ましい。

不完全なＱｏＳ情報を用いてトラフィックマッピングについてのＰＣＣルールを生成することが可能なＰＣＲＮが現在必要とされていることに鑑みて、様々な例示的な実施形態の簡潔な要約が提示される。以下の要約では、いくつかの簡略化および省略が行われることがあるが、それは、様々な例示的な実施形態のいくつかの態様を強調して紹介することを意図したものであり、本発明の範囲を限定する意図はない。当業者が本発明の概念を作成および使用することを可能にするのに適した好ましい例示的な実施形態についての詳細な説明が、これ以降のセクションにおいて行われる。

様々な例示的な実施形態は、ネットワーク全体にわたってパケットトラフィックを管理するためのポリシーおよび制御課金（ＰＣＣ）ルールを生成する方法に関し、方法は、要求ネットワークコンポーネントからＰＣＣルールを求める要求メッセージを受信するステップと、要求された１組のＱｏＳ情報に基づいて１組のＱｏＳ情報を認可するステップと、ＰＣＣルールを生成するステップと、ＰＣＣルールを施行ネットワークコンポーネントに送信するステップとを含むことができる。要求メッセージは、要求帯域幅を含む要求された１組のＱｏＳ情報と、ネットワーク全体にわたって送信されるパケットのフローを記述する第１のトラフィックマッピングと、ネットワーク全体にわたって送信されるパケットの第２のフローを記述する第２のトラフィックマッピングとを含むことができる。ＰＣＣルールは、認可された１組のＱｏＳ情報と、第１のトラフィックマッピングに対応する第１のフロー記述と、第２のトラフィックマッピングに対応する第２のフロー記述とを含むことができる。様々な例示的な実施形態は、ＰＣＲＮがＰＣＣルールを生成するための命令として機械可読記憶媒体上に符号化される、上述の方法に関する。

様々な例示的な実施形態は、ポリシーおよび制御課金ＰＣＣルールを生成するためのポリシーおよび課金ルールノード（ＰＣＲＮ）に関する。ＰＣＲＮは、要求ネットワークコンポーネントからＰＣＣルールを求める要求メッセージを受信する第１のインタフェースと、要求された１組のＱｏＳ情報に基づいてＱｏＳ情報を認可するポリシーエンジンと、ＰＣＣルールを生成するルール生成器と、ＰＣＣルールを施行ネットワークコンポーネントに送信する第２のインタフェースとを含むことができる。メッセージは、要求帯域幅を含む要求された１組のＱｏＳ情報と、ネットワーク全体にわたって送信されるパケットのフローを記述する第１のトラフィックマッピングと、ネットワーク全体にわたって送信されるパケットの第２のフローを記述する第２のトラフィックマッピングとを含むことができる。ＰＣＣルールは、認可された１組のＱｏＳ情報と、第１のトラフィックマッピングに対応する第１のフロー記述と、第２のトラフィックマッピングに対応する第２のフロー記述とを含むことができる。

このようにして、様々な例示的な実施形態が、トラフィックマッピングについてのＰＣＣルールを不完全なＱｏＳ情報を用いて生成することが可能なＰＣＲＮを可能にすることが明らかであろう。特に、複数のサービスデータフローを有するＰＣＣルールを生成することによって、ＰＣＲＮは、トラフィックマッピングが、トラフィックマッピングよりも高いレベルの要求メッセージに含まれるＱｏＳ情報を共用することを可能にすることができる。さらに、複数のサービスデータフローを有するＰＣＣルールは、特別な帯域幅を割り当てることなく、サービス要求を実行することができる。

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

データサービスを提供するための例示的な加入者ネットワークを示す図である。 ポリシーおよび課金制御（ＰＣＣ）ルールを生成するための例示的なポリシーおよび制御ルールノード（ＰＣＲＮ）を示す図である。 ＡＡ要求（ＡＡＲ）メッセージの形式を取る例示的なネットワーク発信型のサービス要求メッセージを示す図である。 信用管理要求（ＣＣＲ）メッセージの形式を取る例示的なユーザ機器発信型のサービス要求メッセージを示す図である。 ＰＣＣルールを記憶するための例示的なデータ構成を示す図である。 ２つ以上のサービスデータフローについてのＰＣＣルールを生成するための例示的な方法を示す図である。 ２つ以上のサービスデータフローを有するＰＣＣルールを実施する例示的な通信リンクを示す図である。

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

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

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

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

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

サービングゲートウェイ（ＳＧＷ）１３２は、基地局１２０とＰＧＷ１３４の間のデータ経路を管理するデバイスとすることができる。データ経路は、固有のサービス品質（ＱｏＳ）特性を有するベアラと呼ばれる仮想コンテナを含むことができる。ベアラは、サービスデータフロー（ＳＤＦ）と呼ばれる仮想コネクションを含むことができる。ユーザ機器１１０がモバイルデバイスであり、基地局１２０がｅＮｏｄｅＢである、様々な実施形態では、ＳＧＷ１３２は、モバイルデバイスがｅＮｏｄｅＢを変更したときに、新しいベアラの確立を担当することができる。ＳＧＷ１３２は、３ＧＰＰ ＴＳ ２９．２１２、２９．２１３、および２９．２１４規格に従って、ベアラバインディングおよびイベント報告機能（ＢＢＥＲＦ：ｂｅａｒｅｒ ｂｉｎｄｉｎｇ ａｎｄ ｅｖｅｎｔ ｒｅｐｏｒｔｉｎｇ ｆｕｎｃｔｉｏｎ）を実施することができる。様々な実施形態では、ＥＰＣ１３０は、複数のサービングゲートウェイを含むことができる。

パケットデータネットワークゲートウェイ（ＰＧＷ）１３４は、パケットデータネットワーク１４０へのゲートウェイアクセスを提供するデバイスとすることができる。ＰＧＷ１３４は、ユーザ機器１１０によってパケットデータネットワーク１４０に向けて送信されたパケットをＳＧＷ１３２を介して受信する、ＥＰＣ１３０内の最後のデバイスとすることができる。ＰＧＷ１３４は、各サービスデータフロー（ＳＤＦ）に対してポリシーおよび課金制御（ＰＣＣ）ルールを実施する、ポリシーおよび課金施行機能（ＰＣＥＦ）を含むことができる。したがって、ＰＧＷ１３４は、ポリシーおよび課金施行ノード（ＰＣＥＮ：ｐｏｌｉｃｙ ａｎｄ ｃｈａｒｇｉｎｇ ｅｎｆｏｒｃｅｍｅｎｔ ｎｏｄｅ）とすることができる。ＰＧＷ１３４は、Ｇｘインタフェースを介してＣＣＲメッセージを送信することによって、新しいＰＣＣルールをＰＣＲＮ１３６に要求することができる。ＰＧＷ１３４は、例えば、パケットフィルタリング、ディープパケットインスペクション（ｄｅｅｐ ｐａｃｋｅｔ ｉｎｓｐｅｃｔｉｏｎ）、および加入者課金サポートなど、多くの追加の機能も含むことができる。

ポリシーおよび課金ルールノード（ＰＣＲＮ）１３６は、アプリケーションサービスを求める要求を受信し、ＰＣＣルールを生成し、ＰＣＣルールをＰＧＷ１３４および／または他のＰＣＥＮ（図示されず）に提供する、デバイスとすることができる。ＰＣＲＮ１３６は、Ｒｘインタフェースを介してＡＮ１５０と通信することができる。ＡＮ１５０および図３に関して以下でさらに詳細に説明するように、ＰＣＲＮ１３６は、サービス要求を、ＡＡ要求（ＡＡＲ）１６０の形式で、ＡＮ１５０から受信することができる。ＡＡＲ１６０を受信すると、ＰＣＲＮ１３６は、サービス要求１６０を実行するための少なくとも１つの新しいＰＣＣルールを生成することができる。

ＰＣＲＮ１３６はまた、それぞれＧｘｘおよびＧｘインタフェースを介して、ＳＧＷ１３２およびＰＧＷ１３４と通信することができる。図４に関して以下でさらに詳細に説明するように、ＰＣＲＮ１３６は、サービス要求を、信用管理要求（ＣＣＲ：ｃｒｅｄｉｔ ｃｏｎｔｒｏｌ ｒｅｑｕｅｓｔ）１７０の形式で、ＳＧＷ１３２またはＰＧＷ１３４から受信することができる。ＡＡＲ１６０の場合と同様に、ＣＣＲ１７０を受信すると、ＰＣＲＮ１３６は、サービス要求１７０を実行するための少なくとも１つの新しいＰＣＣルールを生成することができる。様々な実施形態では、ＡＡＲ１６０およびＣＣＲ１７０は、別々に処理される２つの独立したサービス要求を表すことができるが、他の実施形態では、ＡＡＲ１６０およびＣＣＲ１７０は、単一のサービス要求に関する情報を伝えることができ、ＰＣＲＮ１３６は、ＡＡＲ１６０とＣＣＲ１７０の組み合わせに基づいて、少なくとも１つのＰＣＣルールを生成することができる。様々な実施形態では、ＰＣＲＮ１３６は、単一メッセージサービス要求とペアメッセージサービス要求の両方を処理することが可能とすることができる。

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

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

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

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

図２は、サービス要求に応答して新しいポリシーおよび課金制御（ＰＣＣ）ルールを生成するための、例示的なポリシーおよび課金ルールノード（ＰＣＲＮ）２００を示している。ＰＣＲＮ２００は、例示的な加入者ネットワーク１００のＰＣＲＮ１３６に対応することができる。ＰＣＲＮ２００は、Ｇｘｘインタフェース２０５と、Ｇｘインタフェース２１０と、Ｒｘインタフェース２１５と、サービスフロー抽出器２２０と、ポリシーエンジン２２５と、Ｓｐインタフェース２３０と、ルール生成器２３５と、ルールストレージ２４０と、ゲートウェイ制御セッションマネージャ２４５とを含むことができる。

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

Ｇｘインタフェース２１０は、ＰＧＷ１３４などのＰＧＷと通信するように構成された、ハードウェアおよび／または機械可読記憶媒体上に符号化された実行可能命令を含む、インタフェースとすることができる。そのような通信は、３ＧＰＰ ＴＳ ２９．２１２に従って実施することができる。したがって、Ｇｘインタフェース２１０は、ＰＣＣルールを求める要求を受信し、設定のためにＰＣＣルールを送信することができる。さらに、Ｇｘインタフェース２１０は、ＣＣＲ１７０などのＣＣＲの形式で、ＵＥ発信型のサービス要求を受信することができる。

Ｒｘインタフェース２１５は、ＡＮ１５０などのＡＮと通信するように構成された、ハードウェアおよび／または機械可読記憶媒体上に符号化された実行可能命令を含む、インタフェースとすることができる。そのような通信は、３ＧＰＰ ＴＳ ２９．２１４に従って実施することができる。例えば、Ｒｘインタフェース２０５は、ＡＮ１５０からＡＡＲのようなサービス要求を受信することができる。

サービスフロー抽出器２２０は、要求されたサービスを提供するための少なくとも１つのＳＤＦをサービス要求から決定するように構成された、ハードウェアおよび／または機械可読記憶媒体上の実行可能命令を含むことができる。図３−図４に関して以下でさらに詳細に説明するように、サービス要求は、要求されたサービスを提供するための多くのストリームを識別することができる。各ストリームは、ストリームに関連するパケットを記述する、パケットフィルタなどのトラフィックマッピングを含むことができる。その場合、サービスフロー抽出器２２０は、要求された各データストリームを表すために、ＳＤＦオブジェクトを生成することができる。各ＳＤＦオブジェクトは、例えば、要求帯域幅、トラフィックマッピング、加入者識別子、および／またはデータストリームタイプなどの、サービス要求によって記述された情報を含むことができる。サービス要求は、各ストリームのために要求される特定の帯域幅を指示しないことがある。サービスフロー抽出器２２０は、それらのストリームからもたらされるＳＤＦに、例えば、より高いレベルで要求される帯域幅など、サービス要求内の他のＱｏＳ情報に基づいて、要求帯域幅を割り当てることができる。サービスフロー抽出器２２０は、ストリーム内に含まれる要求帯域幅を無視し、サービス要求内の他のＱｏＳ情報に基づいて、要求帯域幅を割り当てることもできる。その後、サービスフロー抽出器２２０は、ＳＤＦを、そのＳＤＦにおいて使用されるＱｏＳ情報に基づいて、一緒にグループ化することができる。例えば、ＡＡＲメッセージの場合、サービスフロー抽出器２２０は、メディアサブコンポーネント毎にＳＤＦを生成し、メディアコンポーネント記述内に見出されるＱｏＳ情報に従ってＳＤＦをグループ化することができる。

ポリシーエンジン２２５は、受信したサービス要求および／またはサービスフロー抽出器２２０によって生成されたＳＤＦオブジェクトのＱｏＳ情報を認可するように構成された、ハードウェアおよび／または機械可読記憶媒体上の実行可能命令を含むことができる。ＱｏＳ情報によってグループ化されたＳＤＦオブジェクトの場合、ポリシーエンジン２２５は、複数のＳＤＦオブジェクトに対して１組のＱｏＳ情報を認可することができる。ポリシーエンジン２２５は、ＳＰＲ１３８に記憶された加入者データに基づいて、ＱｏＳ情報を認可することができる。ポリシーエンジン２２５は、Ｓｐインタフェース２３０を介してＳＰＲ１３８に加入者データ記録を要求することができる。要求されたＱｏＳ情報が、加入者データ記録によって許可されたＱｏＳを超過する場合、ポリシーエンジン２２５は、加入者データ記録に適合するように、要求されたＱｏＳ情報を低減することができる。要求されたＱｏＳ情報が加入者データによって許可されない場合、ポリシーエンジン２２５は、サービス要求を拒否することもできる。ポリシーエンジン２２５は、要求されたベアラのＱｏＳ限界に基づいて、要求されたＱｏＳ情報を制限することもできる。

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

ルール生成器２３５は、受信したサービス要求、サービスフロー抽出器２２０によって生成されたＳＤＦオブジェクト、および／または認可されたＱｏＳ情報に基づいて、新しいＰＣＣルールを生成するように構成された、ハードウェアおよび／または機械可読記憶媒体上の実行可能命令を含むことができる。最初に、ルール生成器は、新しいＰＣＣルールオブジェクトを生成することができる。次に、ルール生成器２３５は、新しいＰＣＣルールのための名前を生成し、それをＰＣＣルールオブジェクトに記憶することができる。ＰＣＣルール名は、例えば、先に割り当てられたルール名をインクリメントすること、またはランダムな名前を生成することなど、当業者に知られている任意の方法に従って生成することができる。ルール生成器２３５は、例えば、帯域幅、フローステータス、および／またはフロー記述など、ＡＡＲ、ＣＣＲ、および／またはＳＤＦから確定される情報を含む他のデータを、ＰＣＣルールに挿入することもできる。ルール生成器２３５は、２つ以上のフロー記述をＰＣＣルールに挿入することができる。フロー記述は、１組のＱｏＳ情報に関連するＳＤＦのグループ内の各ＳＤＦのフロー記述とすることができる。グループのためのＱｏＳ情報は、ＰＣＣルールに挿入することができる。したがって、ＰＣＣルールは、同じ組のＱｏＳ情報を共用する複数のフロー記述を有することができる。この時点で、新しいＰＣＣルールは、設定のための準備ができた有効なルールとなることができる。ルール生成器２３０は、設定のためにＧｘインタフェース２１０を介してＰＧＷ１３４にルールを送信することができる。ルール生成器２３５は、ルールストレージ２４０にルールを記憶することもできる。

ルールストレージ２４０は、ＰＣＲＮ２００によって生成されたＰＣＣルールを記憶することが可能な任意の機械可読媒体とすることができる。したがって、ルールストレージ２４０は、リードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリデバイス、および／または類似の記憶媒体などの、機械可読記憶媒体を含むことができる。図５に関して以下でさらに詳細に説明するように、ルールストレージ２４０は、ＰＣＲＮ２００によって生成された多くのＰＣＣルールの定義を記憶することができる。そのような定義は、例えば、ルール名、サービスデータフローフィルタ、ＱｏＳパラメータ、および課金パラメータを含むことができる。

ゲートウェイ制御セッションマネージャ２４５は、ＳＧＷまたはゲートウェイ制御セッションを実施する他のノードにおける設定のために、ＱｏＳルールを生成および送信するように構成された、ハードウェアおよび／または機械可読記憶媒体上の実行可能命令を含むことができる。ＰＭＩＰを利用する実施形態など、ＱｏＳ保証を提供するためにゲートウェイ制御セッションを利用する様々な実施形態では、ゲートウェイ制御セッションマネージャ２４５は、ＰＣＣルールからＱｏＳルールを生成するために必要な情報を抽出することができる。例えば、ゲートウェイ制御セッションマネージャ２４５は、ルール名、サービスデータフローフィルタ、およびＱｏＳパラメータをＰＣＣルールから抽出し、新しいＱｏＳルールを生成することができる。その後、ゲートウェイ制御セッションマネージャ２４５は、新しいＱｏＳルールをＧｘｘインタフェース２０５を介してＳＧＷまたは他の適切なノードに転送することができる。

図３は、ＡＡＲ３００の形式を取る例示的なネットワーク発信型のサービス要求メッセージを示している。ＡＡＲ３００は、ダイアメータメッセージプロトコルおよび／または３ＧＰＰ ＴＳ ２９．２１４に従って構成することができる。したがって、ＡＡＲ３００は、ヘッダ３１０と、加入ＩＤフィールド３３０と、メディアコンポーネントフィールド３４０と、多くの追加フィールド３２０、３７０とを含むことができる。ＡＡＲ３００のフィールドの順序は様々であり得ることに留意されたい。したがって、例えば、加入ＩＤフィールド３３０は、メディアコンポーネントフィールド３４０の後に配置することができる。

ヘッダ３１０は、メッセージ３００がＡＡＲであることを示す、標準的なダイアメータヘッダとすることができる。したがって、ヘッダ３１０は、ダイアメータプロトコルおよび３ＧＰＰ ＴＳ ２９．２１４によって提供されるような、値が２６５に設定されたコマンドコードフィールドと、設定されたコマンドフラグフィールドのＲビットフィールドとを含むことができる。

加入ＩＤフィールド３３０は、特定の要求に関連する加入を指示するための属性値ペア（ＡＶＰ：ａｔｔｒｉｂｕｔｅ−ｖａｌｕｅ ｐａｉｒ）とすることができる。例えば、加入ＩＤフィールド３３０は、値「１０００００００００００００１」によって識別される加入がＡＡＲ３００に関連することを示す。この情報は、加入プロファイル記録にアクセスし、要求されたサービスに関して適切な加入者に課金するために使用することができる。

メディアコンポーネント記述フィールド３３０は、要求されたサービスのメディアコンポーネントに関するサービス情報を含むことができる。ＡＡＲ３００の例では、要求は、ストリーミングビデオのためのものとすることができる。メディアコンポーネント３３０は、例えば、ストリームのビデオ部分に対応することができる。メディアコンポーネントフィールド３４０は、最大要求帯域幅（ＭＲＢ）アップリンク（ＵＬ）フィールド３４２、最大要求帯域幅（ＭＲＢ）ダウンリンク（ＤＬ）フィールド３４４、メディアタイプフィールド３４６、および例えばメディアサブコンポーネント３５０、３６０などの１つまたは複数のメディアサブコンポーネントをさらに含むことができる。

ＭＲＢ ＵＬフィールド３４２は、ＵＥ１１０からＡＮ１５０へのアップリンク方向で使用する、メディアコンポーネントのために要求される帯域幅の量を示すことができる。ＭＲＢ ＵＬフィールド３４２は、メディアコンポーネント３４０についての任意のパケットトラフィックに適用することができる。例えば、ＭＲＢ ＵＬフィールド３４２は、メディアコンポーネント３４０がアップロードトラフィックのために５ｍｂｐｓを要求することを示すことができる。ＭＲＢ ＤＬフィールド３４４は、ＡＮ１５０からＵＥ１１０へのダウンリンク方向で使用する、サービスのために要求される帯域幅の量を示すことができる。ＭＲＢ ＤＬフィールド３４４は、メディアコンポーネント３４０についての任意のパケットトラフィックに適用することができる。例えば、ＭＲＢ ＤＬフィールド３４４は、メディアコンポーネント３４０がダウンロードトラフィックのために２０ｍｂｐｓを要求することを示す。メディアタイプフィールド３４６は、例えば、オーディオ、ビデオ、データ、アプリケーション、制御、テキスト、メッセージ、または他のサービスなど、メディアコンポーネントによって提供されるサービスのタイプを示すことができる。メディアタイプフィールド３４６の内容は、ＱｏＳクラス識別子（ＱＣＩ：ＱｏＳ ｃｌａｓｓ ｉｄｅｎｔｉｆｉｅｒ）にマッピングすることができる。ＭＲＢ ＵＬフィールド３４２、ＭＲＢ ＤＬフィールド３４４、およびメディアタイプフィールド４３６は、要求のメディアコンポーネントレベルのための１組のＱｏＳ情報と見なすことができる。

メディアサブコンポーネント３５０、３６０は各々、要求されたサービスを提供するために必要な独立したデータストリームを示すことができる。メディアサブコンポーネント３５０、３６０は、フロー番号、フロー記述、および、最大要求帯域幅のためのフィールド、ならびにメディアサブコンポーネントを定義するのに役立つ他の任意のフィールドを含むことができる。メディアサブコンポーネントは、上で列挙したよりも少数のフィールドしか含まないこともある。

例えば、メディアサブコンポーネント３５０は、フロー番号フィールド３５２と、フロー記述フィールド３５４とを含むことができる。メディアサブコンポーネント３５０は、要求帯域幅を示すフィールドを欠いていてもよい。フロー番号フィールド３５２は、メディアサブコンポーネント３５０に関連するフローを識別するために使用される番号を含むことができる。フロー記述フィールド３５４は、メディアサブコンポーネント３５０のフローに関連するパケットを識別するために使用されるフィルタを含むことができる。フロー記述フィールド３５４は、トラフィックマッピングと見なすことができる。

別の例として、メディアサブコンポーネント３６０は、フロー番号フィールド２６２と、フロー記述フィールド２６４とを含むことができる。メディアサブコンポーネント３６０は、要求帯域幅を示すフィールドを欠いていてもよい。フロー番号フィールド３６２は、メディアサブコンポーネント３６０に関連するフローを識別するために使用される番号を含むことができる。フロー記述フィールド３６４は、メディアサブコンポーネント３６０のフローに関連するパケットを識別するために使用されるフィルタを含むことができる。フロー記述フィールド３５４は、トラフィックマッピングと見なすことができる。

追加フィールド３２０、３７０は、ダイアメータプロトコルおよび／または３ＧＰＰ ＴＳ ２９．２１４によって規定されるような、追加情報を含むことができる。したがって、追加フィールド３２０、３６０は、例えば、発信ホストＡＶＰ、宛先ホストＡＶＰ、サポート機能ＡＶＰ、フレームＩＰアドレスＡＶＰなどの、追加の属性値ペア（ＡＶＰ）を含むことができる。追加フィールド３２０、３７０は、例えば、フロー識別情報など、他の役立つ情報を抽出する際に使用することができる。

図４は、ＣＣＲ４００の形式を取る例示的なユーザ機器発信型のサービス要求メッセージを示している。ＣＣＲ４００は、ダイアメータメッセージプロトコルおよび／または３ＧＰＰ ＴＳ ２９．２１２に従って構成することができる。したがって、ＣＣＲ４００は、ヘッダ４１０と、加入ＩＤフィールド４２０と、ベアラ操作フィールド４２５と、ＱｏＳ情報フィールド４３０と、パケットフィルタ情報フィールド４４０、４５０と、多くの追加フィールド４６０とを含むことができる。ＣＣＲ４００のフィールドの順序は様々であり得ることに留意されたい。したがって、例えば、加入ＩＤフィールド４２０は、ＱｏＳ情報フィールド４３０または、パケットフィルタ情報フィールド４４０、４５０の後に配置することができる。ＣＣＲメッセージは、例えば、ＧＰＲＳおよびＥＰＳ／ＬＴＥなど、異なるタイプのネットワークに対して使用することができる。図４はＧＰＲＳネットワークのための要求として示されているが、ＥＰＳ／ＬＴＥまたは他のネットワークも類似の情報を使用して要求を行うことができることを理解されたい。

ヘッダ４１０は、メッセージ４００がＣＣＲであることを示す、標準的なダイアメータヘッダとすることができる。したがって、ヘッダ４１０は、ダイアメータプロトコルおよび／または３ＧＰＰ ＴＳ ２９．２１２によって提供されるような、値が２５８に設定されたコマンドコードフィールドと、設定されたコマンドフラグフィールドのＲビットフィールドとを含むことができる。

加入ＩＤフィールド４２０は、特定の要求に関連する加入を指示するための属性値ペア（ＡＶＰ）とすることができる。例えば、加入ＩＤフィールド４３０は、値「１０００００００００００００２」によって識別される加入がＣＣＲ４００に関連することを示す。この情報は、加入プロファイル記録にアクセスし、要求されたサービスに関して適切な加入者に課金するために使用することができる。

ベアラ操作フィールド４２５は、サービス要求が新しい専用ベアラを要求しているかどうかを示すことができる。ベアラ操作が確立であることをベアラ操作フィールド４２５が示す場合、ＰＣＲＮ１３６は、要求を実行するために、専用ベアラを生成することができる。例えば、ＬＴＥネットワークからのＣＣＲなど、様々な代替実施形態では、ベアラ操作フィールド４２５は、パケットフィルタ操作フィールドとすることができ、そのケースでは、追加の操作が、専用ベアラを求める要求を示すことができる。

ＱｏＳ情報フィールド４３０は、要求されたサービスのための要求されたＱｏＳ設定を含むことができる。ＱｏＳ情報フィールド４３０は、ＣＣＲ４００に含まれるすべてのパケット情報フィールドに適用することができ、そのため、ＱｏＳ情報フィールド４３０は、トップレベルの１組のＱｏＳ情報と見なすことができる。ＱｏＳ情報フィールド４３０は、ＱｏＳクラス識別子（ＱＣＩ）フィールド４３１と、ＭＲＢ ＵＬフィールド４３２と、ＭＲＢ ＤＬフィールド４３３と、保証ビットレートＵＬフィールド４３５と、保証ビットレートＤＬフィールド４３５と、ベアラ識別子４３６と、ＡＲＰ４３７とを含むことができる。ＱＣＩフィールド４３１は、要求されたトラフィックのタイプを示す識別子を含むことができる。ＭＲＢ ＵＬ５３２は、アップロード方向でサービスによって使用される最大帯域幅が１６ｍｂｐｓであることを示すことができる。ＭＲＢ ＤＬフィールド４３３は、ダウンロード方向で要求されたサービスによって使用される最大帯域幅が１６ｍｂｐｓであることを示すことができる。保証ビットレートＵＬ４３４は、アップロード方向でサービスによって要求される最小帯域幅が０ｍｂｐｓであることを示すことができる。保証ビットレートＤＬ４３５は、ダウンロード方向でサービスによって要求される最小帯域幅が０ｍｂｐｓであることを示すことができる。

パケットフィルタ情報フィールド４４０、４５０は、要求されたサービスのための要求された各フローに関するサービス情報を含むことができる。例えばＬＴＥを実施する実施形態など、様々な実施形態では、パケットフィルタ情報フィールド４４０、４５０は、パケットフィルタ情報ＡＶＰとすることができる。例えばＧＰＲＳを実施する実施形態など、様々な代替実施形態では、パケットフィルタ情報フィールド４４０、４５０は、ＴＦＴパケットフィルタ情報ＡＶＰとすることができる。パケットフィルタ情報フィールド４４０、４５０は、優先順位フィールドと、フィルタ内容フィールドと、例えば、サービスのタイプ、トラフィッククラス、および／またはフローラベルなどの、追加情報とを含むことができる。例えば、パケットフィルタ情報フィールド４４０は、優先順位が２であるＴＦＴパケットフィルタ「０ｘＢ２Ｂ５８ＦＥ１」を記述する。別の例として、パケットフィルタ情報フィールド４５０は、優先順位が１であるＴＦＴパケットフィルタ「０ｘ３４Ｂ９９Ａ０２」を記述する。パケットトラフィックのフローを識別するためにフィルタ情報を使用できるので、パケットフィルタ情報フィールドは、トラフィックマッピングと見なすことができる。サービスフロー抽出器２２０は、パケットフィルタを３ＧＰＰ ＴＳ ２９．２１４に従ったフロー記述としてフォーマットすることによって、パケットフィルタ情報からフロー記述を導出することができる。

追加フィールド４６０は、ダイアメータプロトコルおよび／または３ＧＰＰ ＴＳ ２９．２１２によって規定されるような追加情報を含むことができる。したがって、追加フィールド４６０は、ＣＣ要求タイプＡＶＰ、フレームＩＰアドレスＡＶＰ、３ＧＰＰ−ＳＧＳＮアドレスＡＶＰなどの、追加の属性値ペア（ＡＶＰ）を含むことができる。追加フィールド４６０は、例えば、フロー識別情報など、他の役立つ情報を抽出する際に使用することができる。

図５は、ＰＣＣルールを記憶するための例示的なデータ構成を示している。データ構成５００は、例えば、ルールストレージ２４０に記憶されたデータベースのテーブルとすることができる。代替として、データ構成５００は、一連のリンクリスト、配列、または類似のデータ構造とすることができる。したがって、データ構成５００は基礎をなすデータの抽象化であり、このデータの記憶に適したものであればどのようなデータ構造でも使用できることは明らかであろう。

データ構成５００は、例えば、ルール名フィールド５０５、サービスデータフローフィルタフィールド５１０、フローステータスフィールド５１５、ＱｏＳパラメータフィールド５２０、課金パラメータフィールド５２５、およびベアラフィールド５３０などの、データフィールドを含むことができる。データ構成５００は、ＰＣＣルールを定義する際に必要な、または役立つ、追加フィールド（図示されず）を含むことができる。データ構成５００は、例えば、ルール５３５、５４０、５４５など、ルールのための複数のエントリを含むことができる。

ルール名フィールド５０５は、ＰＣＣルールに割り当てられるルール名を示すことができる。ルール名は、ルールが生成されるときに、ルール生成器２３５によって割り当てることができる。サービスデータフローフィルタフィールド５１０は、データフローに関連するトラフィックパケットを記述する１つまたは複数のパケットフィルタを含むことができる。パケットフィルタは、そのフロー番号順に列挙することができる。サービスデータフローフィルタフィールド５１０内のパケットフィルタの存在は、そのＰＣＣルールをパケットフィルタに一致するいずれのパケットにも適用すべきであることを示すことができる。フローステータスフィールド５１５は、パケットフィルタに一致するトラフィックがいずれかの方向に流れることを許可されているかどうかを示すことができる。ＱｏＳパラメータフィールド５２０は、例えば、ＱＣＩ、ＭＲＢ ＵＬ、およびＭＲＢ ＤＬなど、ＰＣＣルールについてのＱｏＳ情報を含むことができる。ＱｏＳパラメータフィールド５２０は、ネットワークがトラフィックまたはサービスを中止しなければならない場合に、要求されたサービスのプライオリティを示すことができる、割り当て保持プライオリティ（ＡＲＰ：Ａｌｌｏｃａｔｉｏｎ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ）を含むことができる。課金パラメータ５２５は、ＰＣＣルールに関連するトラフィックに適用される課金方法を示すことができる。ベアラフィールド５３０は、ＰＣＣルールに関連するトラフィックを搬送できるベアラを識別することができる。ベアラが識別されない場合、デフォルトベアラがトラフィックを搬送することができる。

データ構成５００のエントリの一例として、ルール５３５は、ルール名が「０ｘＥ４２６」であるルールを示す。ルール５３５は、ＡＡＲ３００のサービス要求を実行するＰＣＣルールとすることができる。ルール５３５は、２つのサービスデータフローフィルタ「０ｘ９０Ｆ２ＣＥ３２」および「０ｘ３９２０Ｂ９２Ｃ」を含む。フローステータスは、どちらの方向についてもオープンであり、トラフィックが流れることを許可され得ることを示す。トラフィックのＱＣＩは、８である。ＭＲＢ ＵＬは、５ｍｂｐｓであり、ＭＲＢ ＤＬは、２０ｍｂｐｓである。ＰＣＣルールは、ただ１組のＱｏＳ情報しか含まないので、ＳＤＦは、要求帯域幅を共用することができる。この例示的なＰＣＣルールには、１メガバイトのデータ転送当たり５セントの料金を課金することができる。ＰＣＣルールに関連するトラフィックは、ベアラ０ｘ６８４Ｃに割り当てられる。

データ構成５００のエントリの別の例として、ルール５４０は、ルール名が「０ｘ９９Ｂ２」であるルールを示す。ルール５４０は、ＣＣＲ４００のサービス要求を実行するＰＣＣルールとすることができる。ルール５４０は、２つのサービスデータフローフィルタ「０ｘＢ２Ｂ５６ＦＥ１」および「０ｘ３４Ｂ８８Ａ０２」を含む。フローステータスは、どちらの方向についてもオープンであり、トラフィックが流れることを許可され得ることを示す。トラフィックのＱＣＩは、６である。ＭＲＢ ＵＬは、１６ｍｂｐｓであり、ＭＲＢ ＤＬは、１６ｍｂｐｓである。ＰＣＣルールは、ただ１組のＱｏＳ情報を含むので、ＳＤＦは、要求帯域幅を共用することができる。この例のＰＣＣルールは、１分当たり１０セントの料金を課金することができる。ＰＣＣルールに関連するトラフィックは、ベアラ０ｘ２８Ｂ２に割り当てられる。エントリ５４５は、データ構成５００が追加のルールのための追加のエントリを含むことができることを示すことができる。

図６は、サービス要求に応答して、２つ以上のＳＤＦについてのＰＣＣルールを生成するための例示的な方法６００を示している。方法６００は、サービス要求によって識別されるＳＤＦについてのＰＣＣルールを確立するために、ＰＣＲＮ１３６および／またはＰＣＲＮ２００のコンポーネントによって実行することができる。

方法６００は、ステップ６０５で開始して、ステップ６１０に進むことができ、ステップ６１０において、ＰＣＲＮ２００は、Ｒｘインタフェース２１５を介してＡＡＲの形式で、および／またはＧｘｘインタフェース２０５もしくはＧｘインタフェース２１０を介してＣＣＲの形式で、サービス要求を受信することができる。この時点で、サービスフロー抽出器２２０は、受信したメッセージが、先に受信した、または受信することが予想される別の相補的メッセージ（ｃｏｍｐｌｅｍｅｎｔａｒｙ ｍｅｓｓａｇｅ）に対応するかどうかを決定することができる。そのような場合、サービスフロー抽出器２２０は、相補的サービス要求を処理する、当業者に知られた任意の方法に従って、完全なサービス要求を生成することができる。

その後、方法６００は、ステップ６１５に進むことができ、ステップ６１５において、サービスフロー抽出器２２０は、サービス要求からトラフィックマッピングを抽出することができる。ＡＡＲの場合、サービスフロー抽出器２２０は、ＡＡＲからメディアコンポーネントおよびメディアサブコンポーネントを抽出し、各メディアサブコンポーネントについてのＳＤＦオブジェクトを確立することができる。メディアサブコンポーネントについてのＳＤＦオブジェクトは、フロー記述ＡＶＰ３５４および３６４などのフロー記述からのトラフィックマッピングを含むことができる。ＣＣＲの場合、サービスフロー抽出器２２０は、例えば、パケットフィルタ情報４４０および４５０などの、各パケットフィルタ情報フィールドについてのＳＤＦオブジェクトを確立することができる。サービスフロー抽出器２２０は、例えば、ＴＦＴフィルタＡＶＰまたはフィルタ内容ＡＶＰなどのトラフィックマッピングを、パケットフィルタ情報フィールドから抽出することができる。その後、サービスフロー抽出器２２０は、トラフィックマッピングからフロー記述を導出し、フロー記述をＳＤＦオブジェクトに記憶することができる。その後、方法６００は、ステップ６２０に進むことができる。

ステップ６２０において、サービスフロー抽出器２２０は、より高いレベルのＱｏＳ情報によってＳＤＦをグループ化することができる。ＡＡＲメッセージの場合、より高いレベルのＱｏＳ情報は、メディアコンポーネントのために要求される帯域幅を含むことができる。メディアコンポーネント内のメディアサブコンポーネントに対応する各ＳＤＦは、一緒にグループ化することができる。ＣＣＲメッセージの場合、より高いレベルのＱｏＳ情報は、ＣＣＲメッセージ内のすべてのパケットフィルタ情報に適用される、ＱｏＳ情報フィールド４３０などのＱｏＳ情報フィールドを含むことができる。ＣＣＲメッセージ内の１組のパケットフィルタ情報に対応する各ＳＤＦは、一緒にグループ化することができる。その後、サービスフロー抽出器２２０は、グループ化されたＳＤＦをポリシーエンジン２２５に送信することができる。その後、方法６００は、ステップ６２５に進むことができる。

ステップ６２５において、ポリシーエンジン２２５は、各ＳＤＦまたはＳＤＦのグループに割り当てられたＱｏＳを認可することができる。ポリシーエンジン２２５は、Ｓｐインタフェース２３０を介してＳＰＲ１３８に加入者記録を要求することができる。その後、ポリシーエンジン２２５は、要求したＱｏＳ情報を加入者記録内の許容されるＱｏＳ情報と比較することができる。ポリシーエンジン２２５は、加入者の統合された要求したＱｏＳが加入者記録によって許容されるかどうかを判定するために、同じ加入者のための他のルールについてもルールストレージ２３５をチェックすることができる。加入者記録は、加入者のための様々なタイプのトラフィックについての課金パラメータも含むことができる。ポリシーエンジン２２５は、要求したＱｏＳに基づいて、課金パラメータを選択することができる。ポリシーエンジン２２５は、ＱｏＳ情報を認可すると、ＳＤＦオブジェクトをルール生成器２３５に渡すことができ、方法は、ステップ６３０に進むことができる。

ステップ６３０において、ルール生成器２３５は、ＳＤＦオブジェクトに基づいて、ＰＣＣルールを生成することができる。ルール生成器２３５は、同じＱｏＳ情報を共用するＳＤＦオブジェクトのグループについての１つのルールを生成することができる。ルールは、グループについてのＱｏＳ情報の認可された組と各ＳＤＦプロジェクトについてのサービスフロー情報の組を含むことができる。サービスフロー情報の各組は、フロー記述を適用する順序を決定するためのフロー番号を含むことができる。フロー番号は、ＡＡＲメッセージからのフロー番号に基づくことができる。ルール生成器２３５は、ポリシーエンジン２２５によって決定された課金パラメータをＰＣＣルールに含めることができる。サービス要求がベアラ識別子を含む場合、ルール生成器２３５は、ベアラ識別子をＰＣＣルールに含めることができる。ルール生成器２３５は、例えば、ルール名およびフローステータスなど、ＰＣＣルールについての他の情報も生成することができる。ルール生成器２４５は、ＰＣＣルールをルールストレージ２４０に保存することができる。その後、方法は、ステップ６３５に進むことができ、ステップ６３５において、Ｇｘインタフェース２１０は、ＰＣＣルールをＰＧＷ１３４に送信することができる。その後、ＰＧＷ１３４は、ＰＣＣルール内のフロー記述のすべてにＱｏＳ情報が適用されるように、ＰＣＣルールを実施することができる。このようにして、ＰＣＣルールは、要求されたサービスを提供する。その後、方法は、ステップ６４０に進むことができ、ステップ６４０において、終了する。

図７は、２つ以上のＳＤＦを有するＰＣＣルールを実施する例示的な通信リンク７００を示している。通信リンク７００は、ＩＰ−ＣＡＮセッション７０５と、ベアラ７１０、７４０と、ＰＣＣルール７２０、７５０と、サービスデータフロー７３０、７３５、７６０、７６５とを含むことができる。

ＩＰ−ＣＡＮセッション７０５は、ＵＥ１１０とＰＧＷ１３４の間で通信リンクを確立するセッションとすることができる。ＩＰ−ＣＡＮセッション７０５は、パケットデータネットワーク１４０との通信を可能にするために、ＩＰアドレスをＵＥ１１０に割り当てることができる。ＩＰ−ＣＡＮセッション７０５は、ベアラ７１０、７４０などの複数のベアラを含むことができる。

ベアラ７１０は、要求メッセージにおいて指示されたトラフィックを搬送するために、ＡＡＲ３００に応答して生成されるベアラとすることができる。ベアラ７１０は、ＩＰ−ＣＡＮセッション７０５内のベアラを一意的に識別するために、識別子「０ｘ６８４Ｃ」を含むことができる。ベアラ７１０は、ＱｏＳを管理するために、ＰＣＣルール７２０を含むことができる。ＰＣＣルール７２０は、アップロードでは５ｍｂｐｓの、またダウンロードでは２０ｍｂｐｓの最大帯域幅を確立することができる。ＰＣＣルール７２０は、ＱｏＳを管理し、サービスに対して課金を行うための、他のＱｏＳ情報も含むことができる。ＰＣＣルール７２０は、例えば、サービスデータフロー７３０、７３５などの、複数のサービスデータフローを含むことができる。サービスデータフロー７３０および７３５は各々、パケットがそのサービスデータフローに属するかどうかを判定するためのフロー記述を含むことができる。サービスデータフロー７３０および７３５は、ＰＣＣルール７２０のＱｏＳ情報を共用することができる。したがって、サービスデータフロー７３０または７３５によって識別されるトラフィックは、ＱｏＳ配送および課金について同じ方式で扱うことができる。

ベアラ７４０は、要求メッセージにおいて指示されたトラフィックを搬送するために、ＣＣＲ４００に応答して生成されるベアラとすることができる。ベアラ７４０は、ＩＰ−ＣＡＮセッション７０５内のベアラを一意的に識別するために、識別子「０ｘ２８Ｂ２」を含むことができる。ベアラ７４０は、ＱｏＳを管理するために、ＰＣＣルール７５０を含むことができる。ＰＣＣルール７５０は、アップロードでは１６ｍｂｐｓの、またダウンロードでは１６ｍｂｐｓの最大帯域幅を確立することができる。ＰＣＣルール７５０は、ＱｏＳを管理し、サービスに対して課金を行うための、他のＱｏＳ情報も含むことができる。ＰＣＣルール７５０は、例えば、サービスデータフロー７６０および７６５などの、複数のサービスデータフローを含むことができる。サービスデータフロー７６０および７６５は各々、パケットがそのサービスデータフローに属するかどうかを判定するためのフロー記述を含むことができる。サービスデータフロー７６０および７６５は、ＰＣＣルール７５０のＱｏＳ情報を共用することができる。したがって、サービスデータフロー７６０または７６５によって識別されるトラフィックは、ＱｏＳ配送および課金について同じ方式で扱うことができる。

例示的な加入者ネットワーク１００およびＰＣＲＮ２００の動作のための例示的なコンポーネントおよび方法を説明してきたが、例示的なネットワーク１００およびＰＣＲＮ２００の動作の一例が、今から図１−図７を参照しながら提供される。ＰＣＲＮ１３６は、ＰＣＲＮ２００に対応することができる。ＡＡＲ３００は、ＡＡＲ１６０に対応することができる。ＣＣＲ４００は、ＣＣＲ１７０に対応することができる。データ構成５００は、ルールストレージ２４０の内容に対応することができる。

プロセスは、ＰＣＲＮ２００がＡＮ１５０からＡＡＲ３００を受信したときに開始することができる。サービスフロー抽出器２２０は、メディアサブコンポーネント３５０のために１つと、メディアサブコンポーネント３６０のために１つの、２つのトラフィックマッピングをＡＡＲ３００から抽出することができる。次に、サービスフロー抽出器２２０は、各トラフィックマッピングについてのＳＤＦオブジェクトを生成することができる。メディアサブコンポーネント３５０および３６０は、いかなるＱｏＳ情報も含まず、そのため、サービスフロー抽出器２２０は、メディアコンポーネント３４０のためのＱｏＳ情報に基づいて、ＳＤＦをグループに割り当てることができる。メディアコンポーネント３４０は、５ｍｂｐｓを示すＭＲＢ ＵＬ３４２と、２０ｍｂｐｓを示すＭＲＢ ＤＬ３４４とを含む。サービスフロー抽出器２２０は、このＱｏＳ情報をＳＤＦオブジェクトのグループに割り当てることができる。その後、サービスフロー抽出器２２０は、ＳＤＦオブジェクトのグループをポリシーエンジン２２５に渡すことができる。

その後、ポリシーエンジン２２５は、要求されたＱｏＳ情報を認可することができる。ポリシーエンジン２２５は、Ｓｐインタフェース２３０を介してＳＰＲ１３８に加入者プロファイルを要求することができる。要求されたＱｏＳ情報が、加入者プロファイルおよび／または内部ポリシールールによって許容されない場合、ポリシーエンジン２２５は、要求されたＱｏＳ情報を引き下げること、または要求を拒否することができる。要求されたＱｏＳ情報が、許容される場合、ポリシーエンジン２２５は、要求されたＱｏＳ情報を認可し、ＳＤＦオブジェクトをルール生成器２３５に渡すことができる。ポリシーエンジン２２５は、認可されたＱｏＳ情報とともに、加入者プロファイルに基づいて決定された課金パラメータを含むことができる。

その後、ルール生成器２３５は、グループ化されたＳＤＦオブジェクトのためのＰＣＣルール５３０を生成することができる。ルール生成器２３５は、フロー記述３５４および３６４の両方をＰＣＣルールのサービスデータフローフィルタ５１０として含めることができる。認可されたＱｏＳ情報は、ＱｏＳパラメータ５２０に挿入することができる。同様に、ポリシーエンジン２２５によって決定された課金パラメータも、課金パラメータ５２５に挿入することができる。ルール生成器２３５は、例えば、ルール名５０５およびフローステータス５１５などの、他のルールフィールドのためのデータも生成することができる。ルール生成器２３５は、ＰＧＷ１３４に新しいルールを設定するために、ＣＣＡメッセージを生成することもできる。ゲートウェイ制御セッションマネージャ２４５は、必要な場合はＳＧＷ１３２を設定するためのＱｏＳルールを生成するために、ＰＣＣルールからＱｏＳ情報およびサービスデータフローフィルタを抽出することができる。

上述の説明によれば、様々な例示的な実施形態は、トラフィックマッピングについてのＰＣＣルールをＱｏＳ情報なしで生成することが可能なＰＣＲＮを提供する。特に、複数のサービスデータフローを有するＰＣＣルールを生成することによって、ＰＣＲＮは、トラフィックマッピングが、トラフィックマッピングよりも高いレベルの要求メッセージに含まれるＱｏＳ情報を共用することを可能にすることができる。さらに、複数のサービスデータフローを有するＰＣＣルールは、特別な帯域幅を割り当てることなく、サービス要求を実行することができる。

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

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

様々な例示的な実施形態が、実施形態のある例示的な態様を特に参照して、詳細に説明されたが、本発明は他の実施形態も可能であり、その詳細は様々な明らかな点において変更が可能であることを理解されたい。当業者には容易に明らかなように、本発明の主旨および範囲内に留まりながら、変形および変更を施すことができる。したがって、上述の開示、説明、および図は、説明を目的としたものにすぎず、特許請求の範囲によってのみ確定される本発明をいかなる形でも限定するものではない。

Claims (10)

1. ネットワーク全体にわたってパケットトラフィックを管理するためのポリシーおよび制御課金（ＰＣＣ）ルールを生成する方法であって、
   要求ネットワークコンポーネントからＰＣＣルールを求める要求メッセージを受信するステップであって、メッセージが、要求帯域幅を含む要求された１組のＱｏＳ情報と、ネットワーク全体にわたって送信されるパケットのフローを記述する第１のトラフィックマッピングと、ネットワーク全体にわたって送信されるパケットの第２のフローを記述する第２のトラフィックマッピングとを含む、ステップと、
   要求された１組のＱｏＳ情報に基づいて１組のＱｏＳ情報を認可するステップと、
   ＰＣＣルールを生成するステップであって、ＰＣＣルールが、認可された１組のＱｏＳ情報と、第１のトラフィックマッピングに対応する第１のフロー記述と、第２のトラフィックマッピングに対応する第２のフロー記述とを含む、ステップと、
   ＰＣＣルールを施行ネットワークコンポーネントに送信するステップと
   を含む、方法。
2. 要求メッセージが、ゲートウェイからの信用管理要求（ＣＣＲ）メッセージであり、第１および第２のトラフィックマッピングが、パケットフィルタ情報であり、方法が、
   第１のトラフィックマッピングから第１のフロー記述を導出するステップと、
   第２のトラフィックマッピングから第２のフロー記述を導出するステップであって、ＣＣＲメッセージが、専用ベアラを要求し、ＰＣＣルールが、専用ベアラに関連する、ステップと
   をさらに含む、請求項１に記載の方法。
3. 要求メッセージが、アプリケーションノードからのアプリケーション認可要求（ＡＡＲ：ａｐｐｌｉｃａｔｉｏｎ ａｕｔｈｏｒｉｚａｔｉｏｎ ｒｅｑｕｅｓｔ）メッセージであり、第１および第２のトラフィックマッピングが、メディアサブコンポーネントのフロー記述であり、要求された１組のＱｏＳ情報が、メディアコンポーネント最大要求アップロード帯域幅と、メディアコンポーネント最大要求ダウンロード帯域幅とを含む、請求項１に記載の方法。
4. 第１および第２のトラフィックマッピングが、ＴＦＴパケットフィルタ情報ＡＶＰ、パケットフィルタ情報ＡＶＰ、およびフロー記述ＡＶＰのうちの少なくとも１つを含む、請求項１に記載の方法。
5. 認可するステップが、
   要求されたＱｏＳ情報をＰＣＲＮが実行するべきかどうかを判定するステップと、
   要求されたＱｏＳ情報をＰＣＲＮが実行するべきではない場合、要求された帯域幅よりも小さい帯域幅を含むＱｏＳ情報を認可するステップと
   を含む、請求項１に記載の方法。
6. 第１のトラフィックマッピングが、要求帯域幅を含まず、第２のトラフィックマッピングが、要求帯域幅を含まない、請求項１に記載の方法。
7. ポリシーおよび制御課金ＰＣＣルールを生成するためのポリシーおよび課金ルールノード（ＰＣＲＮ）であって、
   要求ネットワークコンポーネントからＰＣＣルールを求める要求メッセージを受信する第１のインタフェースであって、メッセージが、要求帯域幅を含む要求された１組のＱｏＳ情報と、ネットワーク全体にわたって送信されるパケットのフローを記述する第１のトラフィックマッピングと、ネットワーク全体にわたって送信されるパケットの第２のフローを記述する第２のトラフィックマッピングとを含む、第１のインタフェースと、
   要求された１組のＱｏＳ情報に基づいてＱｏＳ情報を認可するポリシーエンジンと、
   ＰＣＣルールを生成するルール生成器であって、ＰＣＣルールが、認可された１組のＱｏＳ情報と、第１のトラフィックマッピングに対応する第１のフロー記述と、第２のトラフィックマッピングに対応する第２のフロー記述とを含む、ルール生成器と、
   ＰＣＣルールを施行ネットワークコンポーネントに送信する第２のインタフェースと
   を備える、ＰＣＲＮ。
8. ルール生成器によって生成されたＰＣＣルールを記憶するルールストレージと、
   加入者プロファイルリポジトリと通信し、加入者情報をポリシーエンジンに提供する、Ｓｐインタフェースであって、ポリシーエンジンが、要求された１組のＱｏＳ情報と、加入者情報とに基づいて、ＱｏＳ情報を認可する、Ｓｐインタフェースと
   をさらに備える、請求項７に記載のＰＣＲＮ。
9. 第１のインタフェースが、信用制御要求メッセージを受信し、第１および第２のトラフィックマッピングが、パケットフィルタ情報であり、サービスフロー抽出器が、第１のトラフィックマッピングから第１のフロー記述を導出し、第２のトラフィックマッピングから第２のフロー記述を導出する、請求項７に記載のＰＣＲＮ。
10. ＰＣＣルールに基づいてＱｏＳルールを生成するゲートウェイ制御セッションマネージャであって、ＱｏＳルールが、認可された１組のＱｏＳ情報と、第１のトラフィックマッピングに対応する第１のフロー記述と、第２のトラフィックマッピングに対応する第２のフロー記述とを含む、ゲートウェイ制御セッションマネージャ
    をさらに備える、請求項７に記載のＰＣＲＮ。

Images