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

Abstract

様々な例示的な実施形態は、ネットワーク全体にわたってパケットトラフィックを管理するためのＰＣＣルールを生成する方法に関する。方法は、要求ネットワークコンポーネントからＰＣＣルールを求める要求メッセージを受信するステップと、第１のトラフィックマッピングのための第１の要求帯域幅を認可するステップと、少なくとも第２のトラフィックマッピングのための第３の帯域幅を認可するステップであって、認可された第３の帯域幅が、第２の要求帯域幅から第１の要求帯域幅をマイナスした差以下である、ステップと、第１のトラフィックマッピングに対応するサービスフローと、第１の認可帯域幅と：を含む第１のＰＣＣルールを生成するステップと、第２のトラフィックマッピングに対応するサービスフローと、第３の認可帯域幅と：を含む第２のＰＣＣルールを生成するステップと：を含むことができる。様々な例示的な実施形態は、ＰＣＣルールを生成するためのポリシーおよび制御ルールノード（ＰＣＲＮ）に関する。ＰＣＲＮは、インタフェースと、サービスフロー抽出器と、ポリシーエンジンと、ルール生成器と、ルールストレージと、ルールマネージャとを含むことができる。

Description

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

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

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

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

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

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

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

上述の事柄に鑑みて、不完全なＱｏＳ情報を用いてトラフィックマッピングについてのＰＣＣルールを生成することが可能なＰＣＲＦを実施する、ポリシーおよび課金ルールノード（ＰＣＲＮ：Ｐｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｒｕｌｅｓ Ｎｏｄｅ）を提供することが望ましい。特に、後のメッセージでＱｏＳ情報が到着した場合に、ＰＣＣルールを更新することが望ましい。

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

様々な例示的な実施形態は、ネットワーク全体にわたってパケットトラフィックを管理するためのポリシーおよび制御課金（ＰＣＣ）ルールを生成する方法に関する。方法は、要求ネットワークコンポーネントからＰＣＣルールを求める要求メッセージを受信するステップと、第１のトラフィックマッピングのための第１の要求帯域幅を認可するステップと、少なくとも第２のトラフィックマッピングのための第３の帯域幅を認可するステップであって、認可された第３の帯域幅が、第２の要求帯域幅と第１の要求帯域幅の間の差に基づく、ステップと、第１のＰＣＣルールを生成するステップと、第２のＰＣＣルールを生成するステップと：を含むことができる。要求メッセージは、ネットワーク全体にわたって送信されるパケットのフローを記述する第１のトラフィックマッピングと、ネットワーク全体にわたって送信されるパケットの第２のフローを記述する第２のトラフィックマッピングと、第１のトラフィックマッピングにだけ適用可能な第１の要求帯域幅の表示と、少なくとも第１のトラフィックマッピングと第２のトラフィックマッピングに適用可能な第２の要求帯域幅の表示と：を含むことができる。第１のＰＣＣルールは、第１のトラフィックマッピングに対応するサービスフローと、第１の認可帯域幅とを含むことができる。第２のＰＣＣルールは、第２のトラフィックマッピングに対応するサービスフローと、第３の認可帯域幅とを含むことができる。方法は、追加のトラフィックマッピングおよび帯域幅を含む要求メッセージについてのＰＣＣルールを生成することができる。様々な例示的な実施形態は、ポリシーおよびルール課金ノードがＰＣＣルールを生成するための命令として、機械可読記憶媒体上に符号化される、上述の方法に関する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

アップリンク方向とダウンリンク方向の両方において帯域幅を割り当てることができることは明らかであろう。帯域幅という用語は、アップリンク方向とダウンリンク方向における１組の帯域幅を総称的に指すために使用することができる。帯域幅に対して数学的演算が実行される場合、演算は、各方向の帯域幅に対して別々に実行することができる。例えば、第１の帯域幅を第２の帯域幅から減算する場合、第１のアップリンク帯域幅を第２のアップリンク帯域幅から減算することができ、第１のダウンリンク帯域幅を第２のダウンリンク帯域幅から減算することができる。

ポリシーエンジン２２５は、受信したサービス要求および／またはサービスフロー抽出器２２０によって生成されたＳＤＦオブジェクトのＱｏＳ情報を認可するように構成された、ハードウェアおよび／または機械可読記憶媒体上の実行可能命令を含むことができる。グループ化されていないＳＤＦの場合、ポリシーエンジン２２５は、要求されたストリーム帯域幅を認可することができる。グループ化されたＳＤＦの場合、最初に、ポリシーエンジン２２５は、ストリーム帯域幅を使用して、各ＳＤＦに対して要求帯域幅を認可することができる。次に、ポリシーエンジン２２５は、より高いレベルの帯域幅からストリーム帯域幅を減算することができる。その後、ポリシーエンジン２２５は、ストリーム帯域幅を使用するＳＤＦをグループから除去することができる。最後に、ポリシーエンジン２２５は、グループの残りのＳＤＦに対して、調整されたより高いレベルの帯域幅を認可することができる。

いくつかのＳＤＦは、計算を必要とするストリーム帯域幅を含むことができる。ポリシーエンジン２２５は、ストリームのフロー使用に基づいて、個々のストリームのための帯域幅を計算することができる。例えば、データフローはリアルタイムトランスポート制御プロトコル（ＲＴＣＰ）フローであることをフロー使用が示す場合、最初に、ポリシーエンジン２２５は、ＲＳ帯域幅およびＲＲ帯域幅などの特別に定義された値に基づいて、ストリーム帯域幅を計算しようと試みることができる。定義された値が利用可能ではない場合、ポリシーエンジン２２５は、より高いレベルの帯域幅の５％としてストリーム帯域幅を計算することができる。その後、ポリシーエンジン２２５は、より高いレベルの帯域幅からストリーム帯域幅を減算することができる。

ポリシーエンジン２２５は、ＳＰＲ１３８に記憶された加入者データに基づいて、認可されたＱｏＳ情報を調整することができる。ポリシーエンジン２２５は、Ｓｐインタフェース２３０を介してＳＰＲ１３８に加入者データ記録を要求することができる。要求されたＱｏＳ情報が、加入者データ記録によって許可されたＱｏＳを超過する場合、ポリシーエンジン２２５は、加入者データ記録に適合するように、要求されたＱｏＳ情報を低減することができる。要求されたＱｏＳ情報が加入者データによって許可されない場合、ポリシーエンジン２２５は、サービス要求を拒否することもできる。ポリシーエンジン２２５は、要求されたベアラのＱｏＳ限界に基づいて、要求されたＱｏＳ情報を制限することもできる。

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

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

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

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

ルールマネージャ２５０は、ルールストレージ２４０に記憶されたＰＣＣルールを選択および更新するように構成された、ハードウェアおよび／または機械可読記憶媒体上の実行可能命令を含むことができる。ルールマネージャ２５０は、フロー記述を含む要求を受信したとき、受信したフロー記述をルールストレージ２４０内のＰＣＣルールのフロー記述と照合することによって、ＰＣＣルールを選択することができる。ルールマネージャ２５０は、ＰＣＣルールに属するフロー記述を除去することによって、ＰＣＣルールを更新することができる。ルールマネージャ２５０は、ＰＣＣルールの帯域幅を調整することもできる。代替として、ルールマネージャ２５０は、ＰＣＣルールを削除し、ルール生成器２３５が置換ルールを生成することを可能にすることによって、ＰＣＣルールを更新することができる。

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

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

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

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

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

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

例えば、メディアサブコンポーネント３５０は、フロー番号フィールド３５２と、フロー記述フィールド３５４と、ＭＲＢ ＵＬフィールド３５６と、ＭＲＢ ＤＬフィールド３５８とを含むことができる。フロー番号フィールド３５２は、メディアコンポーネント３４０内のメディアサブコンポーネント３５０に関連するフローを識別するために使用される番号を含むことができる。フロー番号フィールド３５２は、番号１を含むことができる。フロー記述フィールド３５４は、メディアサブコンポーネント３５０のフローに関連するパケットを識別するために使用されるパケットフィルタを含むことができる。フロー記述フィールド３５４は、トラフィックマッピングと見なすことができる。ＭＲＢ ＵＬフィールド３５６は、アップリンク方向においてメディアサブコンポーネント３５０によって使用される最大帯域幅が１０ｍｂｐｓであることを示すことができる。ＭＲＢ ＤＬフィールド３５６は、ダウンリンク方向においてメディアサブコンポーネント３５０によって使用される最大帯域幅も１０ｍｂｐｓであることを示すことができる。

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

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

最後の例として、メディアサブコンポーネント３８０は、フロー番号フィールド３８２と、フロー記述フィールド３８４とを含むことができる。フロー番号フィールド３８２は、このケースでは番号「４」である、メディアサブコンポーネント３８０に関連するフローを識別するために使用される番号を含むことができる。フロー記述フィールド３８４は、メディアサブコンポーネント３７０のフローに関連するパケットを識別するために使用されるフィルタを含むことができる。フロー記述フィールド３７４は、トラフィックマッピングと見なすことができる。フロー使用フィールド３８６は、メディアサブコンポーネント３８０の使用の表示を含むことができる。いくつかの使用は、帯域幅、または帯域幅を計算するために使用できるルールに関連することができる。例えば、フロー使用フィールド３８６は、メディアサブコンポーネント３８０がリアルタイムトランスポート制御プロトコル（ＲＴＣＰ）フローであることを示すことができる。図２に関して説明したように、ＲＴＣＰフローは、帯域幅を計算するための特別のルールを使用することができる。

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

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

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

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

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

ベアラ情報４２７は、例えば、識別子が「０ｘ２８Ｂ２」であるベアラなど、トラフィックを搬送するための要求されたベアラを示すことができる。ベアラ情報４２７が既存のベアラと一致しない場合、要求は、新しい専用ベアラのためのものとすることができる。ベアラ情報４２７が含まれない場合、トラフィックは、専用ベアラ、デフォルトベアラ、またはＱＣＩフィールド４３１に基づいて選択されるベアラに割り当てることができる。

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

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

パケットフィルタ情報の一例として、パケットフィルタ情報フィールド４４０は、優先順位が４であるＴＦＴパケットフィルタ「０ｘ１０Ｆ２ＣＥ３２」を記述する。別の例として、パケットフィルタ情報フィールド４５０は、優先順位が３であるＴＦＴパケットフィルタ「０ｘ２９２９Ｂ９２Ｃ」を記述する。別の例として、パケットフィルタ情報フィールド４６０は、優先順位が２であるＴＦＴパケットフィルタ「０ｘ３２Ｂ５６ＦＥ１」を記述する。最後の例として、パケットフィルタ情報フィールド４７０は、優先順位が１であるＴＦＴパケットフィルタ「０ｘ４５１９２Ｂ８３２」を記述する。

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

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

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

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

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

データ構成５００のエントリの別の例として、ルール５４５は、ルール名が「０ｘ８２Ａ１」であるルールを示す。ルール５４５は、メディアサブコンポーネント３５０に対応するＰＣＣルールとすることができる。ルール５４５は、１つのフロー記述「０ｘ１０Ｆ２ＣＥ３２」を含む。フローステータスは、オープンであり、トラフィックが流れることを許可され得ることを示す。トラフィックのＱＣＩは、６である。ＭＲＢ ＵＬは、１０ｍｂｐｓであり、ＭＲＢ ＤＬは、１０ｍｂｐｓである。ＰＣＣルールに関連するトラフィックは、ベアラ「０ｘ２８Ｂ２」に割り当てられ、セッション「０ｘ７３２Ａ」に関連付けられる。

データ構成５００のエントリの別の例として、ルール５５０は、ルール名が「０ｘ８２Ａ２」であるルールを示す。ルール５５０は、メディアサブコンポーネント３６０および３７０に対応するＰＣＣルールとすることができる。ルール５５０は、２つのフロー記述「０ｘ２９２９Ｂ９２Ｃ」および「０ｘ３２Ｂ５６ＦＥ１」を含む。フローステータスは、オープンであり、トラフィックが流れることを許可され得ることを示す。トラフィックのＱＣＩは、６である。ＭＲＢ ＵＬは、９ｍｂｐｓであり、ＭＲＢ ＤＬは、９ｍｂｐｓである。ＰＣＣルールに関連するトラフィックは、ベアラ「０ｘ２８Ｂ２」に割り当てられ、セッション「０ｘ７３２Ａ」に関連付けられる。

データ構成５００のエントリの別の例として、ルール５５５は、ルール名が「０ｘ８２Ａ３」であるルールを示す。ルール５５５は、メディアサブコンポーネント３８０に対応するＰＣＣルールとすることができる。ルール５５５は、１つのフロー記述「０ｘ４５１９２Ｂ８３２」を含む。フローステータスは、オープンであり、トラフィックが流れることを許可され得ることを示す。トラフィックのＱＣＩは、６である。ＭＲＢ ＵＬは、１ｍｂｐｓであり、ＭＲＢ ＤＬは、１ｍｂｐｓである。ＰＣＣルールに関連するトラフィックは、ベアラ「０ｘ２８Ｂ２」に割り当てられ、セッション「０ｘ７３２Ａ」に関連付けられる。

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

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

ステップ６２０において、サービスフロー抽出器２２０は、受信したメッセージのトラフィックマッピングに対応する１つまたは複数のフロー記述を、ルールマネージャ２５０に送信することができる。その後、ルールマネージャ２５０は、メッセージからのフロー記述に一致するフロー記述を含むＰＣＣルールを求めて、ルールストレージ２４０を検索することができる。ルールストレージ２４０が一致するＰＣＣルールを含む場合、ルールマネージャ２５０は、そのＰＣＣルールをサービスフロー抽出器２２０に返すことができる。ＰＣＣルールは、相補的メッセージと同じ情報を提供し、ＰＣＣルールを更新するために使用することができる。次に、方法は、ステップ６３０に進むことができる。

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

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

ステップ６４０において、ポリシーエンジン２２５は、グループ内のいずれかのＳＤＦがストリーム帯域幅を含むかどうかを決定することができる。ストリーム帯域幅は、単一のＳＤＦのために要求される帯域幅の何らかの表示とすることができる。例えば、メディアサブコンポーネント３５０などのメディアサブコンポーネントは、ＭＲＢ ＵＬ３５６およびＭＲＢ ＤＬ３５８を含むことができる。別の例として、メディアサブコンポーネント３８０などのメディアサブコンポーネントは、ＳＤＦがＲＴＣＰフローであることを示すフロー使用フィールド３８６を含むことができる。ポリシーエンジン２２５は、ＲＴＣＰフローのためのストリーム帯域幅を計算することができる。ストリーム帯域幅は、ＣＣＲメッセージのパケットフィルタ情報フィールド内に含むことができる。グループ内のＳＤＦがストリーム帯域幅を含む場合、方法６００は、ステップ６４５に進むことができる。グループ内のＳＤＦがストリーム帯域幅を含まない場合、方法６００は、ステップ６６０に進むことができる。

ステップ６４５において、ポリシーエンジン２２５は、グループのより高いレベルの帯域幅から、ＳＤＦのストリーム帯域幅を減算することができる。例えば、ポリシーエンジン２２５は、メディアコンポーネントに割り当てられた帯域幅から、メディアサブコンポーネントに割り当てられた帯域幅を減算することができる。減算演算は、アップリンク帯域幅とダウンリンク帯域幅の両方に対して実行することができる。減算演算の結果、より高いレベルの帯域幅が負になった場合、ポリシーエンジン２２５は、サービス要求に誤りがあると判定し、要求を拒否することができる。その後、方法は、ステップ６５０に進むことができ、ステップ６５０において、ポリシーエンジン２２５は、ＳＤＦのためのストリーム帯域幅を認可することができる。ポリシーエンジン２２５は、この時点で、ＳＤＦのための他のＱｏＳ情報も認可することができる。その後、方法は、ステップ６５５に進むことができ、ステップ６５５において、ポリシーエンジン２２５は、グループからＳＤＦを除去することができる。その後、方法は、ステップ６４０に戻ることができ、ステップ６４０において、ポリシーエンジン２２５は、グループがストリーム帯域幅を含むいずれかのＳＤＦをまだ含むかどうかを判定することができる。

ステップ６６０において、ポリシーエンジン２２５は、ＳＤＦのグループのためのより高いレベルの帯域幅を認可することができる。認可されたより高いレベルの帯域幅は、ステップ６４５において帯域幅が減算された場合は、最初に要求されたものよりも低いことがある。ポリシーエンジン２２５は、サービス要求に含まれる情報に基づいて、ＳＤＦのグループのための他のＱｏＳ情報も認可することができる。ポリシーエンジン２２５は、ＱｏＳ情報をひとたび認可すると、サービスデータフローをルール生成器２３５に渡すことができ、方法６００は、ステップ６６５に進むことができる。

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

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

ＩＰ−ＣＡＮセッション７０５は、ＵＥ１１０とＰＧＷ１３４の間で通信リンクを確立するセッションとすることができる。ＩＰ−ＣＡＮセッション７０５は、パケットデータネットワーク１４０との通信を可能にするために、ＩＰアドレスをＵＥ１１０に割り当てることができる。ＩＰ−ＣＡＮセッション７０５は、ベアラ７１０などのベアラを含むことができる。ＩＰ−ＣＡＮセッション７０５は、デフォルトベアラおよび他の専用ベアラなどの、他のベアラ（図示されず）も含むことができる。

ベアラ７１０は、要求メッセージにおいて指示されたトラフィックを搬送するために、ＡＡＲ３００に応答して生成されるベアラとすることができる。ベアラ７１０は、ＩＰ−ＣＡＮセッション７０５内のベアラを一意的に識別するために、識別子「０ｘ２８Ｂ２」を含むことができる。ベアラ７１０は、ＱｏＳを管理するために、ＰＣＣルール７２０、７３０、７４０を含むことができる。

ＰＣＣルール７２０は、アップリンクでは１０ｍｂｐｓの、またダウンリンクでは１０ｍｂｐｓの最大帯域幅を確立することができる。ＰＣＣルール７２０は、ＱｏＳを管理し、サービスに対して課金を行うための、他のＱｏＳ情報も含むことができる。ＰＣＣルール７２０は、例えば、サービスデータフロー７２５などの、１つまたは複数のサービスデータフローを含むことができる。サービスデータフロー７２５は、メディアサブコンポーネント３５０のフロー記述と一致するフロー記述によって指示されるので、メディアサブコンポーネント３５０に対応することができる。サービスデータフロー７２５は、ＰＣＣルール７２０内のただ１つのサービスデータフローであり、そのため、サービスデータフロー７２５は、ＰＣＣルール７２０のすべての帯域幅を使用することができる。帯域幅は、メディアサブコンポーネント３５０のために要求された帯域幅に対応することができる。

ＰＣＣルール７３０は、アップリンクでは９ｍｂｐｓの、またダウンリンクでは９ｍｂｐｓの最大帯域幅を確立することができる。ＰＣＣルール７３０は、サービスデータフロー７３５および７３７を含むことができる。これらのサービスデータフローは、一致するフロー記述によって指示されるので、メディアサブコンポーネント３６０および３７０にそれぞれ対応することができる。ＰＣＣルール７３０は、２つのサービスデータフローを含み、そのため、サービスデータフロー７３５および７３７は、ＰＣＣルール７３０の帯域幅を共用することができる。帯域幅は、メディアコンポーネント３４０のために要求された帯域幅から、メディアコンポーネント３４０内のメディアサブコンポーネントに割り当てられたストリーム帯域幅をマイナスしたものに対応することができる。

ＰＣＣルール７４０は、アップリンクでは１ｍｂｐｓの、またダウンリンクでは１ｍｂｐｓの最大帯域幅を確立することができる。ＰＣＣルール７４０は、サービスデータフロー７４５を含むことができる。サービスデータフロー７４５は、一致するフロー記述によって指示されるので、メディアサブコンポーネント３８０に対応することができる。ＰＣＣルール７４０は、ただ１つのサービスデータフローを含み、そのため、サービスデータフロー７４５は、ＰＣＣルール７４０のすべての帯域幅を使用することができる。帯域幅は、メディアコンポーネント３８０のために要求された帯域幅に対応することができる。

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

プロセスは、ＰＣＲＮ２００がＳＧＷ１３４からＣＣＲ４００を受信したときに開始することができる。ＣＣＲ４００は、サービスを求める第１のメッセージとすることができ、相補的メッセージまたは更新メッセージと見なさなくてよい。サービスフロー抽出器２２０は、パケットフィルタ情報４４０、４５０、４６０、４７０の各々に１つの、４つのトラフィックマッピングをＣＣＲ４００から抽出することができる。次に、サービスフロー抽出器２２０は、トラフィックマッピングの各々についてのＳＤＦを生成することができる。ＳＤＦを生成するには、パケットフィルタ情報からフロー記述を導出することが必要なことがある。その後、サービスフロー抽出器２２０は、ＭＲＢ ＵＬ４３２およびＭＲＢ ＵＬ４３３のより高いレベルの帯域幅がトラフィックマッピングの各々に適用されるので、ＳＤＦを一緒にグループ化することができる。

ポリシーエンジン２２５は、パケットフィルタ情報のいずれもがストリーム帯域幅を含まないので、グループのための帯域幅を認可することができる。ポリシーエンジン２２５は、ＱｏＳ情報フィールド４３１内の他のＱｏＳ情報を認可し、課金パラメータを決定することもできる。ルール生成器２３５は、ＳＤＦのグループに基づいて、サービス要求についてのルール５３０などのＰＣＣルールを生成することができる。ルール５３０は、ＣＣＲ４００から抽出されたＳＤＦの各々についての、サービスフローフィルタを含む、フロー情報を含む。ルール５３０は、ＱｏＳ情報フィールド４３１からの認可されたＱｏＳ情報も含む。

プロセスは、ＰＣＲＮ２００がＡＮ１５０からＡＡＲ３００を受信したときに続行することができる。ＡＡＲ３００は、ＣＣＲ４００と同じサービスを要求する相補的メッセージとすることができる。ＡＡＲ３００は、ＰＣＲＮ２００がＣＣＲ４００に応答してＰＣＣルールをすでに生成した後に到着することがあり、そのため、ＡＡＲ３００は、更新メッセージであることもある。サービスフロー抽出器２２０は、例えば、フロー記述３５４などの、ＡＡＲ３００のフロー記述をルールマネージャ２５０に送信することができる。ルールマネージャ２５０は、フロー記述を使用して、ＰＣＣルールストレージ２４０を検索することができる。ルールマネージャ２５０は、フロー記述３５４がルール５３０のサービスデータフローフィルタの１つと一致するので、ルール５３０を見つける。ルールマネージャ２５０は、ルール５３０が更新され得るように、ルール５３０をサービスフロー抽出器に渡すことができる。サービスフロー抽出器２２０は、ＡＡＲ３００の各メディアサブコンポーネントからトラフィックマッピングを抽出することによって、新しいＰＣＣルールの生成を続行することができる。サービスフロー抽出器２２０は、トラフィックマッピングを一致したルール５３０のＳＤＦフィルタと照合することもできる。次に、サービスフロー抽出器２２０は、各トラフィックマッピングについてのＳＤＦを生成し、ＭＲＢ ＵＬ３４２およびＭＲＢ ＤＬ３４４内に見出されるより高いレベルの帯域幅に基づいて、それらを一緒にグループ化することができる。メディアサブコンポーネント３５０およびメディアサブコンポーネント３８０についてのＳＤＦは、ストリーム帯域幅を含むことができるが、一時的にメディアサブコンポーネント３６０および３７０とグループ化することができる。

最初に、ポリシーエンジン２２５は、メディアサブコンポーネント３５０がＭＲＢ ＵＬ３５６およびＭＲＢ ＤＬ３５８を含むので、メディアサブコンポーネント３５０のためのＳＤＦがストリーム帯域幅を含むことを決定することができる。次に、ポリシーエンジン２２５は、ＳＤＦのグループのためのより高いレベルの帯域幅から、メディアサブコンポーネント３５０のための帯域幅を減算することができる。減算演算は、ＳＤＦのグループのために、アップリンクでは１０ｍｂｐｓを、またダウンリンクでは１０ｍｂｐｓを残す。その後、ポリシーエンジン２２５は、メディアサブコンポーネント３５０のための、ＭＲＢ ＵＬ３５６およびＭＲＢ ＤＬ３５８内の帯域幅を認可することができる。その後、ポリシーエンジン２２５は、グループからメディアサブコンポーネント３５０のためのＳＤＦを除去することができる。

次に、ポリシーエンジン２２５は、メディアサブコンポーネント３８０がフロー使用フィールド３８６によって示されるようにＲＴＣＰフローであるので、メディアサブコンポーネント３８０のためのＳＤＦがストリーム帯域幅を含むことを決定することができる。ポリシーエンジン２２５は、メディアコンポーネントのために要求された帯域幅の５パーセントとして、メディアサブコンポーネント３８０のためのストリーム帯域幅を計算することができる。したがって、メディアサブコンポーネント３８０は、アップリンクでは１ｍｂｐｓの、またダウンリンクでは１ｍｂｐｓのストリーム帯域幅を有することができる。次に、ポリシーエンジン２２５は、この帯域幅をＳＤＦのグループのためのより高いレベルの帯域幅から減算して、アップリンクでは９ｍｂｐｓの、またダウンリンクでは９ｍｂｐｓの帯域幅を残すことができる。その後、ポリシーエンジン２２５は、メディアサブコンポーネント３８０のために、アップリンクでは１ｍｂｐｓの、またダウンリンクでは１ｍｂｐｓの帯域幅を認可することができる。その後、ポリシーエンジン２２５は、ＳＤＦのグループからメディアサブコンポーネント３８０のためのＳＤＦを除去することができる。

その後、ポリシーエンジン２２５は、ＳＤＦのグループがストリーム帯域幅を有するＳＤＦを含まないことを決定することができる。その後、ポリシーエンジン２２５は、ＳＤＦのグループのために、アップリンクでは９ｍｂｐｓの、またダウンリンクでは９ｍｂｐｓのより高いレベルの帯域幅を認可することができる。その後、ポリシーエンジン２２５は、ＳＤＦをルール生成器２３５に渡すことができる。ルール生成器２３５は、ストリーム帯域幅を含む各ＳＤＦについての、またＳＤＦの各グループについての、ＰＣＣルールを生成することができる。最初に、ルール生成器２３５は、メディアサブコンポーネント３５０に対応するＳＤＦについてのルール５３５を生成することができる。次に、ルール生成器２３５は、メディアサブコンポーネント３６０および３７０に対応するＳＤＦのグループについてのルール５４０を生成することができる。このルールは、ルール５３０に対する更新とすることができる。最後に、ルール生成器２３５は、メディアサブコンポーネント３８０に対応するＳＤＦについてのルール５４５を生成することができる。これらのルールの詳細は、図７に関して上で説明された。ＰＣＣルールは、Ｇｘインタフェース２１０を介してＰＧＷ１３４に送信することができ、ＰＧＷ１３４において、ＰＣＣルールは、要求されたサービスを提供するために使用することができる。ＰＣＣルールは、ルールストレージ２４０に記憶することもできる。ゲートウェイ制御セッションマネージャ２４５は、データ構成５００からＱｏＳ関連部分を抽出し、ＱｏＳルールをＧｘｘインタフェース２０５を介してＳＧＷ１３２に送信することによって、ＰＣＣルールからＱｏＳルールを生成することができる。

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

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

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

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

Claims (10)

1. ネットワーク全体にわたってパケットトラフィックを管理するためのポリシーおよび制御課金（ＰＣＣ）ルールを生成する方法であって、
   要求ネットワークコンポーネントからＰＣＣルールを求める要求メッセージを受信するステップであって、メッセージが、
   ネットワーク全体にわたって送信されるパケットのフローを記述する第１のトラフィックマッピングと、
   ネットワーク全体にわたって送信されるパケットの第２のフローを記述する第２のトラフィックマッピングと、
   第１のトラフィックマッピングに関連する第１の要求帯域幅の表示と、
   少なくとも第１のトラフィックマッピングと第２のトラフィックマッピングに関連する第２の要求帯域幅の表示と
   を含む、ステップと、
   第１のトラフィックマッピングのための第１の要求帯域幅を認可するステップと、
   少なくとも第２のトラフィックマッピングのための第３の帯域幅を認可するステップであって、認可された第３の帯域幅が、第２の要求帯域幅と第１の要求帯域幅の間の差に基づく、ステップと、
   第１のトラフィックマッピングに対応するサービスフローフィルタと、第１の認可帯域幅とを含む、第１のＰＣＣルールを生成するステップと、
   第２のトラフィックマッピングに対応するサービスフローフィルタと、第３の認可帯域幅とを含む、第２のＰＣＣルールを生成するステップと
   を含む、方法。
2. 要求メッセージが、認可および認証要求（ＡＡＲ）メッセージであり、第１の要求帯域幅が、メディアサブコンポーネントのための最大アップリンク帯域幅と、最大ダウンリンク帯域幅とを含み、第２の要求帯域幅が、メディアコンポーネントのための最大アップリンク帯域幅と、最大ダウンリンク帯域幅とを含む、請求項１に記載の方法。
3. 第１の要求帯域幅の表示が、第１のトラフィックマッピングが、リアルタイムトランスポート制御プロトコル（ＲＴＣＰ）フロー用である旨の表示を含み、方法が、ＲＴＣＰフローについてのルールに従って、第１の要求帯域幅を計算するステップをさらに含み、計算するステップが、第２の要求帯域幅の５パーセントとして第１の要求帯域幅を計算するステップを含む、請求項１に記載の方法。
4. 要求メッセージが、ただ１つのトラフィックマッピングにしか関連しない要求帯域幅を２つ以上含み、第２の認可帯域幅が、第２の要求帯域幅から、ただ１つのトラフィックマッピングにしか関連しない帯域幅の合計をマイナスした差に等しい、請求項１に記載の方法。
5. 要求メッセージが、相補的メッセージであり、
   方法が、
   相補的な一致したＰＣＣルールに基づいて、第１のＰＣＣルールおよび第２のＰＣＣルールを生成するステップと、
   第１のトラフィックマッピングから第１のフロー記述を抽出するステップと、
   第１のフロー記述を既存のＰＣＣルールのフロー記述と照合するステップと、
   一致したＰＣＣルールを削除するステップと
   をさらに含む、請求項１に記載の方法。
6. ポリシーおよび制御課金（ＰＣＣ）ルールを生成するためのポリシーおよび課金ルールノード（ＰＣＲＮ）であって、
   要求ネットワークコンポーネントからＰＣＣルールを求める要求メッセージを受信する第１のインタフェースであって、メッセージが、
   ネットワーク全体にわたって送信されるパケットのフローを記述する第１のトラフィックマッピングと、
   ネットワーク全体にわたって送信されるパケットの第２のフローを記述する第２のトラフィックマッピングと、
   第１のトラフィックマッピングに関連する第１の要求帯域幅の表示と、
   少なくとも第１のトラフィックマッピングと第２のトラフィックマッピングに関連する第２の要求帯域幅の表示と
   を含む、第１のインタフェースと、
   第１のトラフィックマッピングのための第１の要求帯域幅を認可し、少なくとも第２のトラフィックマッピングのための第３の帯域幅を認可するポリシーエンジンであって、第３の帯域幅が、第２の要求帯域幅と第１の要求帯域幅の差に基づく、ポリシーエンジンと、
   第１の認可帯域幅と、第１のトラフィックマッピングに対応する第１のサービスフローフィルタとを含む、第１のＰＣＣルールと、第３の認可帯域幅と、第２のトラフィックマッピングに対応する第２のサービスフローフィルタとを含む、第２のＰＣＣルールとの、少なくとも２つのＰＣＣルールを生成するルール生成器と
   を備える、ＰＣＲＮ。
7. 要求メッセージからトラフィックマッピングと帯域幅の表示とを抽出し、トラフィックマッピングに対応するサービスデータフローを生成するサービスフロー抽出器であって、サービスフロー抽出器が、サービスデータフローをグループに分類し、各グループが、より高いレベルの帯域幅に関連するサービスデータフローを含む、サービスフロー抽出器
   をさらに備える、請求項６に記載のＰＣＲＮ。
8. ルール生成器によって生成されたＰＣＣルールを記憶するルールストレージと、
   相補的メッセージから抽出されたサービスフローを、ルールストレージ内のＰＣＣルールのサービスフローと照合し、一致したＰＣＣルールをルールストレージから削除するルールマネージャと
   をさらに備え、
   ルール生成器が、一致したＰＣＣルールからの情報と、相補的メッセージからの情報とに基づいて、少なくとも２つのＰＣＣルールを生成する、
   請求項６に記載のＰＣＲＮ。
9. 第１の要求帯域幅の表示が、第１のトラフィックマッピングが、リアルタイムトランスポート制御プロトコル（ＲＴＣＰ）フロー用である旨の表示を含み、
   ポリシーエンジンが、第２の要求帯域幅の５パーセントとして第１の要求帯域幅を計算する、
   請求項６に記載のＰＣＲＮ。
10. 第２のＰＣＣルールから少なくとも第２のフロー記述と第３の帯域幅とを抽出し、サービス品質（ＱｏＳ）ルールを生成するゲートウェイ制御セッションマネージャと、
    ＱｏＳルールをサービングゲートウェイに送信するＧｘｘインタフェースと
    をさらに備える、請求項６に記載のＰＣＲＮ。

Images