ネットワーク全体にわたってパケットトラフィックを管理するためのポリシーおよび制御課金PCCルールを生成する方法であって、要求ネットワークコンポーネントからPCCルールを求める要求メッセージを受信するステップであって、メッセージが、ネットワーク全体にわたって送信されるパケットのフローを記述する第1のトラフィックマッピングと、ネットワーク全体にわたって送信されるパケットの第2のフローを記述する第2のトラフィックマッピングと、第1のトラフィックマッピングに関連する第1の要求帯域幅の表示と、少なくとも第1のトラフィックマッピングと第2のトラフィックマッピングに関連する第2の要求帯域幅の表示とを含む、ステップと、第1のトラフィックマッピングのための第1の要求帯域幅を認可するステップと、少なくとも第2のトラフィックマッピングのための第3の帯域幅を認可するステップであって、認可された第3の帯域幅が、第2の要求帯域幅と第1の要求帯域幅の間の差に基づく、ステップと、第1のトラフィックマッピングに対応するサービスフローフィルタと、第1の認可帯域幅とを含む、第1のPCCルールを生成するステップと、第2のトラフィックマッピングに対応するサービスフローフィルタと、第3の認可帯域幅とを含む、第2のPCCルールを生成するステップとを含む、方法。要求メッセージが、認可および認証要求AARメッセージであり、第1の要求帯域幅が、メディアサブコンポーネントのための最大アップリンク帯域幅と、最大ダウンリンク帯域幅とを含み、第2の要求帯域幅が、メディアコンポーネントのための最大アップリンク帯域幅と、最大ダウンリンク帯域幅とを含む、請求項1に記載の方法。第1の要求帯域幅の表示が、第1のトラフィックマッピングが、リアルタイムトランスポート制御プロトコルRTCPフロー用である旨の表示を含み、方法が、RTCPフローについてのルールに従って、第1の要求帯域幅を計算するステップをさらに含み、計算するステップが、第2の要求帯域幅の5パーセントとして第1の要求帯域幅を計算するステップを含む、請求項1に記載の方法。要求メッセージが、ただ1つのトラフィックマッピングにしか関連しない要求帯域幅を2つ以上含み、第2の認可帯域幅が、第2の要求帯域幅から、ただ1つのトラフィックマッピングにしか関連しない帯域幅の合計をマイナスした差に等しい、請求項1に記載の方法。要求メッセージが、相補的メッセージであり、方法が、相補的な一致したPCCルールに基づいて、第1のPCCルールおよび第2のPCCルールを生成するステップと、第1のトラフィックマッピングから第1のフロー記述を抽出するステップと、第1のフロー記述を既存のPCCルールのフロー記述と照合するステップと、一致したPCCルールを削除するステップとをさらに含む、請求項1に記載の方法。ポリシーおよび制御課金PCCルールを生成するためのポリシーおよび課金ルールノードPCRNであって、要求ネットワークコンポーネントからPCCルールを求める要求メッセージを受信する第1のインタフェースであって、メッセージが、ネットワーク全体にわたって送信されるパケットのフローを記述する第1のトラフィックマッピングと、ネットワーク全体にわたって送信されるパケットの第2のフローを記述する第2のトラフィックマッピングと、第1のトラフィックマッピングに関連する第1の要求帯域幅の表示と、少なくとも第1のトラフィックマッピングと第2のトラフィックマッピングに関連する第2の要求帯域幅の表示とを含む、第1のインタフェースと、第1のトラフィックマッピングのための第1の要求帯域幅を認可し、少なくとも第2のトラフィックマッピングのための第3の帯域幅を認可するポリシーエンジンであって、第3の帯域幅が、第2の要求帯域幅と第1の要求帯域幅の差に基づく、ポリシーエンジンと、第1の認可帯域幅と、第1のトラフィックマッピングに対応する第1のサービスフローフィルタとを含む、第1のPCCルールと、第3の認可帯域幅と、第2のトラフィックマッピングに対応する第2のサービスフローフィルタとを含む、第2のPCCルールとの、少なくとも2つのPCCルールを生成するルール生成器とを備える、PCRN。要求メッセージからトラフィックマッピングと帯域幅の表示とを抽出し、トラフィックマッピングに対応するサービスデータフローを生成するサービスフロー抽出器であって、サービスフロー抽出器が、サービスデータフローをグループに分類し、各グループが、より高いレベルの帯域幅に関連するサービスデータフローを含む、サービスフロー抽出器をさらに備える、請求項6に記載のPCRN。ルール生成器によって生成されたPCCルールを記憶するルールストレージと、相補的メッセージから抽出されたサービスフローを、ルールストレージ内のPCCルールのサービスフローと照合し、一致したPCCルールをルールストレージから削除するルールマネージャとをさらに備え、ルール生成器が、一致したPCCルールからの情報と、相補的メッセージからの情報とに基づいて、少なくとも2つのPCCルールを生成する、請求項6に記載のPCRN。第1の要求帯域幅の表示が、第1のトラフィックマッピングが、リアルタイムトランスポート制御プロトコルRTCPフロー用である旨の表示を含み、ポリシーエンジンが、第2の要求帯域幅の5パーセントとして第1の要求帯域幅を計算する、請求項6に記載のPCRN。第2のPCCルールから少なくとも第2のフロー記述と第3の帯域幅とを抽出し、サービス品質QoSルールを生成するゲートウェイ制御セッションマネージャと、QoSルールをサービングゲートウェイに送信するGxxインタフェースとをさらに備える、請求項6に記載のPCRN。上述の事柄に鑑みて、不完全なQoS情報を用いてトラフィックマッピングについてのPCCルールを生成することが可能なPCRFを実施する、ポリシーおよび課金ルールノードPCRN:PolicyandChargingRulesNodeを提供することが望ましい。特に、後のメッセージでQoS情報が到着した場合に、PCCルールを更新することが望ましい。不完全なQoS情報を用いてトラフィックマッピングについてのPCCルールを生成することが可能なPCRNが現在必要とされていることに鑑みて、様々な例示的な実施形態の簡潔な要約が提示される。以下の要約では、いくつかの簡略化および省略が行われることがあるが、それは、様々な例示的な実施形態のいくつかの態様を強調して紹介することを意図したものであり、本発明の範囲を限定する意図はない。当業者が本発明の概念を作成および使用することを可能にするのに適した好ましい例示的な実施形態についての詳細な説明が、これ以降のセクションにおいて行われる。様々な例示的な実施形態は、ネットワーク全体にわたってパケットトラフィックを管理するためのポリシーおよび制御課金PCCルールを生成する方法に関する。方法は、要求ネットワークコンポーネントからPCCルールを求める要求メッセージを受信するステップと、第1のトラフィックマッピングのための第1の要求帯域幅を認可するステップと、少なくとも第2のトラフィックマッピングのための第3の帯域幅を認可するステップであって、認可された第3の帯域幅が、第2の要求帯域幅と第1の要求帯域幅の間の差に基づく、ステップと、第1のPCCルールを生成するステップと、第2のPCCルールを生成するステップと:を含むことができる。要求メッセージは、ネットワーク全体にわたって送信されるパケットのフローを記述する第1のトラフィックマッピングと、ネットワーク全体にわたって送信されるパケットの第2のフローを記述する第2のトラフィックマッピングと、第1のトラフィックマッピングにだけ適用可能な第1の要求帯域幅の表示と、少なくとも第1のトラフィックマッピングと第2のトラフィックマッピングに適用可能な第2の要求帯域幅の表示と:を含むことができる。第1のPCCルールは、第1のトラフィックマッピングに対応するサービスフローと、第1の認可帯域幅とを含むことができる。第2のPCCルールは、第2のトラフィックマッピングに対応するサービスフローと、第3の認可帯域幅とを含むことができる。方法は、追加のトラフィックマッピングおよび帯域幅を含む要求メッセージについてのPCCルールを生成することができる。様々な例示的な実施形態は、ポリシーおよびルール課金ノードがPCCルールを生成するための命令として、機械可読記憶媒体上に符号化される、上述の方法に関する。様々な例示的な実施形態は、PCCルールを生成するためのポリシーおよび課金ルールノードPCRNに関する。PCRNは、要求ネットワークコンポーネントからPCCルールを求める要求メッセージを受信する第1のインタフェースと、第1のトラフィックマッピングのための第1の要求帯域幅を認可し、少なくとも第2のトラフィックマッピングのための第3の帯域幅を認可するポリシーエンジンであって、第3の帯域幅が、第2の要求帯域幅と第1の要求帯域幅の差に基づく、ポリシーエンジンと、少なくとも2つのPCCルールを生成するルール生成器と:を含むことができる。要求メッセージは、ネットワーク全体にわたって送信されるパケットのフローを記述する第1のトラフィックマッピングと、ネットワーク全体にわたって送信されるパケットの第2のフローを記述する第2のトラフィックマッピングと、第1のトラフィックマッピングに関連する第1の要求帯域幅の表示と、少なくとも第1のトラフィックマッピングと第2のトラフィックマッピングに関連する第2の要求帯域幅の表示と:を含むことができる。第1のPCCルールは、第1の認可帯域幅と、第1のトラフィックマッピングに対応する第1のフロー記述とを含むことができる。第2のPCCルールは、第3の認可帯域幅と、第2のトラフィックマッピングに対応する第2のフロー記述とを含むことができる。PCRNは、追加のトラフィックマッピングおよび帯域幅を含む要求メッセージに基づいて、PCCルールを生成することができる。このようにして、様々な例示的な実施形態が、トラフィックマッピングについてのPCCルールを不完全なQoS情報を用いて生成することが可能なPCRNを可能にすることが明らかであろう。特に、複数のサービスデータフローを有するPCCルールを生成することによって、PCRNは、トラフィックマッピングが、トラフィックマッピングよりも高いレベルの要求メッセージに含まれるQoS情報を共用することを可能にすることができる。さらに、より高いレベルの帯域幅から、個々のフローに割り当てられた帯域幅を減算することによって、PCRNは、特別な帯域幅を割り当てることなく、サービス要求を実行することができる。様々な例示的な実施形態をより良く理解するため、添付の図面を参照する。ここで図面を参照すると、様々な例示的な実施形態についての広範な態様が開示されており、図面中、同様の番号は、同様の構成要素またはステップを指す。図1は、様々なデータサービスを提供するための例示的な加入者ネットワーク100を示している。例示的な加入者ネットワーク100は、様々なサービスへのアクセスを提供するための通信ネットワークまたは他のネットワークとすることができる。例示的な加入者ネットワーク100は、ユーザ機器110と、基地局120と、進化型パケットコアEPC130と、パケットデータネットワーク140と、アプリケーションノードAN150とを含むことができる。ユーザ機器110は、エンドユーザにデータサービスを提供するための、パケットデータネットワーク140と通信するデバイスとすることができる。そのようなデータサービスは、例えば、音声通信、テキストメッセージング、マルチメディアストリーミング、およびインターネットアクセスを含むことができる。より具体的には、様々な例示的な実施形態では、ユーザ機器110は、パーソナルもしくはラップトップコンピュータ、ワイヤレス電子メールデバイス、セルフォン、スマートフォン、テレビジョンセットトップボックス、またはEPC130を介して他のデバイスと通信することが可能な他の任意のデバイスである。基地局120は、ユーザ機器110とEPC130の間の通信を可能にするデバイスとすることができる。例えば、基地局120は、3GPP規格によって定義されたような進化型ノードBeNodeBなどのトランシーバ基地局とすることができる。したがって、基地局120は、電波などの第1の媒体を介してユーザ機器110と通信し、イーサネット登録商標ケーブルなどの第2の媒体を介してEPC130と通信する、デバイスとすることができる。基地局120は、EPC130と直接的に通信することができ、または多くの中間ノード図示されずを介して通信することができる。様々な実施形態では、ユーザ機器110にモビリティを提供するために、複数の基地局図示されずが存在することができる。様々な代替実施形態では、ユーザ機器110は、進化型パケットコア130と直接的に通信できることに留意されたい。そのような実施形態では、基地局120は、存在しなくてもよい。進化型パケットコアEPC130は、ユーザ機器110にパケットデータネットワーク140へのゲートウェイアクセスを提供する、デバイスまたはデバイスのネットワークとすることができる。さらに、EPC130は、提供されるデータサービスの使用に対して加入者に課金を行い、特定のエクスペリエンス品質QoE基準が満たされることを保証することができる。したがって、EPC130は、少なくとも部分的に、3GPPTS29.212、29.213、および29.214規格に従って実施することができる。したがって、EPC130は、サービングゲートウェイSGW132と、パケットデータネットワークゲートウェイPGW134とポリシーおよび課金ルールノードPCRN136と、加入者プロファイルリポジトリSPR138とを含むことができる。サービングゲートウェイSGW132は、基地局120とPGW134の間のデータ経路を管理するデバイスとすることができる。データ経路は、固有のサービス品質QoS特性を有するベアラと呼ばれる仮想コンテナを含むことができる。ベアラは、サービスデータフローSDFと呼ばれる仮想コネクションを含むことができる。ユーザ機器110がモバイルデバイスであり、基地局120がeNodeBである、様々な実施形態では、SGW132は、モバイルデバイスがeNodeBを変更したときに、新しいベアラの確立を担当することができる。SGW132は、3GPPTS29.212、29.213、および29.214規格に従って、ベアラバインディングおよびイベント報告機能BBERF:bearerbindingandeventreportingfunctionを実施することができる。様々な実施形態では、EPC130は、複数のサービングゲートウェイを含むことができる。パケットデータネットワークゲートウェイPGW134は、パケットデータネットワーク140へのゲートウェイアクセスを提供するデバイスとすることができる。PGW134は、ユーザ機器110によってパケットデータネットワーク140に向けて送信されたパケットをSGW132を介して受信する、EPC130内の最後のデバイスとすることができる。PGW134は、各サービスデータフローSDFに対してポリシーおよび課金制御PCCルールを実施する、ポリシーおよび課金施行機能PCEFを含むことができる。したがって、PGW134は、ポリシーおよび課金施行ノードPCEN:policyandchargingenforcementnodeとすることができる。PGW134は、Gxインタフェースを介してCCRメッセージを送信することによって、新しいPCCルールをPCRN136に要求することができる。PGW134は、例えば、パケットフィルタリング、ディープパケットインスペクションdeeppacketinspection、および加入者課金サポートなど、多くの追加の機能も含むことができる。ポリシーおよび課金ルールノードPCRN136は、アプリケーションサービスを求める要求を受信し、PCCルールを生成し、PCCルールをPGW134および/または他のPCEN図示されずに提供する、デバイスとすることができる。PCRN136は、Rxインタフェースを介してAN150と通信することができる。AN150および図3に関して以下でさらに詳細に説明するように、PCRN136は、サービス要求を、認可および認証要求AAR:authorizationandauthenticationrequest160の形式で、AN150から受信することができる。AAR160を受信すると、PCRN136は、サービス要求160を実行するための少なくとも1つの新しいPCCルールを生成することができる。PCRN136はまた、それぞれGxxおよびGxインタフェースを介して、SGW132およびPGW134と通信することができる。図4に関して以下でさらに詳細に説明するように、PCRN136は、サービス要求を、信用管理要求CCR:creditcontrolrequest170の形式で、SGW132またはPGW134から受信することができる。AAR160の場合と同様に、CCR170を受信すると、PCRN136は、サービス要求170を実行するための少なくとも1つの新しいPCCルールを生成することができる。様々な実施形態では、AAR160およびCCR170は、別々に処理される2つの独立したサービス要求を表すことができるが、他の実施形態では、AAR160およびCCR170は、単一のサービス要求に関する情報を伝えることができ、PCRN136は、AAR160とCCR170の組み合わせに基づいて、少なくとも1つのPCCルールを生成することができる。PCRN136は、1つのメッセージに基づいて、第1のルールを生成し、その後、第2のメッセージに基づいて、そのルールを更新することもできる。様々な実施形態では、PCRN136は、単一メッセージサービス要求とペアメッセージサービス要求の両方を処理することが可能とすることができる。新しいPCCルールを生成したとき、またはPGW134によって要求されたとき、PCRN136は、Gxインタフェースを介してPGW134にPCCルールを提供することができる。例えば、PMIP規格を実施する実施形態など、様々な実施形態では、PCRN136は、QoSルールも生成することができる。新しいQoSルールを生成したとき、またはSGW132によって要求されたとき、PCRN136は、Gxxインタフェースを介してSGW132にQoSルールを提供することができる。加入プロファイルリポジトリSPR138は、加入者に関する情報を加入者ネットワーク100に記憶するデバイスとすることができる。したがって、SPR138は、リードオンリメモリROM、ランダムアクセスメモリRAM、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリデバイス、および/または類似の記憶媒体などの、機械可読記憶媒体を含むことができる。SPR138は、PCRN136の構成要素とすることができ、またはEPC130内の独立のノードを構成することができる。SPR138によって記憶されるデータは、各加入者の識別子、ならびに帯域幅制限、課金パラメータ、加入者プライオリティ、および加入者サービスプリファレンスなどの各加入者の加入情報の表示を含むことができる。パケットデータネットワーク140は、ユーザ機器110とパケットデータネットワーク140に接続されたAN150などの他のデバイスとの間のデータ通信を提供するための、任意のネットワークとすることができる。さらに、パケットデータネットワーク140は、例えば、電話サービスおよび/またはインターネットサービスを、パケットデータネットワーク140と通信する様々なユーザデバイスに提供することができる。アプリケーションノードAN150は、アプリケーションサービスをユーザ機器110に提供するデバイスとすることができる。したがって、AN150は、例えば、ストリーミングビデオサービスをユーザ機器110に提供する、サーバまたは他のデバイスとすることができる。AN150はさらに、Rxインタフェースを介してEPC130のPCRN136と通信することができる。AN150は、アプリケーションサービスをユーザ機器110に提供し始めるとき、ダイアメータプロトコルに従ったAA要求AARなどのサービス要求メッセージを生成して、アプリケーションサービスのためにリソースを割り当てるべきであることをPCRN136に通知することができる。そのようなサービス要求メッセージは、アプリケーションサービスを使用する加入者の識別情報、および要求されたサービスを提供するためにIP-CANセッション内で確立しなければならない特定のサービスデータフローSDFの識別情報などの情報を含むことができる。AN150は、そのようなサービス要求をRxインタフェース215を介してPCRNに伝えることができる。図2は、サービス要求に応答して新しいポリシーおよび課金制御PCCルールを生成するための、例示的なポリシーおよび課金ルールノードPCRN200を示している。PCRN200は、例示的な加入者ネットワーク100のPCRN136に対応することができる。PCRN200は、Gxxインタフェース205と、Gxインタフェース210と、Rxインタフェース215と、サービスフロー抽出器220と、ポリシーエンジン225と、Spインタフェース230と、ルール生成器235と、ルールストレージ240と、ゲートウェイ制御セッションマネージャ245と、ルールマネージャ250とを含むことができる。Gxxインタフェース205は、SGW132などのSGWと通信するように構成された、ハードウェアおよび/または機械可読記憶媒体上に符号化された実行可能命令を含む、インタフェースとすることができる。そのような通信は、3GPPTS29.212に従って実施することができる。したがって、Gxxインタフェース205は、QoSルールを求める要求を受信し、設定のためにQoSルールを送信することができる。さらに、Gxxインタフェース205は、CCRの形式で、UE発信型のサービス要求を受信することができる。Gxインタフェース210は、PGW134などのPGWと通信するように構成された、ハードウェアおよび/または機械可読記憶媒体上に符号化された実行可能命令を含む、インタフェースとすることができる。そのような通信は、3GPPTS29.212に従って実施することができる。したがって、Gxインタフェース210は、PCCルールを求める要求を受信し、設定のためにPCCルールを送信することができる。さらに、Gxインタフェース210は、CCR170などのCCRの形式で、UE発信型のサービス要求を受信することができる。Rxインタフェース215は、AN150などのANと通信するように構成された、ハードウェアおよび/または機械可読記憶媒体上に符号化された実行可能命令を含む、インタフェースとすることができる。そのような通信は、3GPPTS29.214に従って実施することができる。例えば、Rxインタフェース205は、AN150からサービス要求AARを受信することができる。サービスフロー抽出器220は、要求されたサービスを提供するための少なくとも1つのSDFをサービス要求から決定するように構成された、ハードウェアおよび/または機械可読記憶媒体上の実行可能命令を含むことができる。図3-図4に関して以下でさらに詳細に説明するように、サービス要求は、要求されたサービスを提供するための多くのストリームを識別することができる。各ストリームは、例えば、フロー記述またはパケットフィルタなどの、トラフィックマッピングによって識別することができる。その場合、サービスフロー抽出器220は、要求された各データストリームを表すために、SDFを生成することができる。各SDFは、例えば、要求帯域幅、トラフィックマッピング、加入者識別子、および/またはデータストリームタイプなどの、サービス要求によって記述された情報を含むことができる。アプリケーション要求は、各ストリームのためのストリーム帯域幅を指示しないことがある。サービスフロー抽出器220は、それらのデータストリームを表すSDFに、例えば、メディアコンポーネント帯域幅または汎用QoS情報内の帯域幅など、データストリームに適用されるサービス要求内のより高いレベルの帯域幅に基づいて、要求帯域幅を割り当てることができる。その後、サービスフロー抽出器220は、より高いレベルの帯域幅を使用するSDFを、そのSDFにおいて使用されるより高いレベルの帯域幅に基づいて、グループにグループ化することができる。要求されたストリーム帯域幅を含み、より高いレベルの帯域幅に関連付けられたストリームは、より高いレベルの帯域幅の代わりに、そのストリーム帯域幅を使用することができる。そのようなストリームを表すSDFは、より高いレベルの帯域幅によって一時的にグループ化することができる。アップリンク方向とダウンリンク方向の両方において帯域幅を割り当てることができることは明らかであろう。帯域幅という用語は、アップリンク方向とダウンリンク方向における1組の帯域幅を総称的に指すために使用することができる。帯域幅に対して数学的演算が実行される場合、演算は、各方向の帯域幅に対して別々に実行することができる。例えば、第1の帯域幅を第2の帯域幅から減算する場合、第1のアップリンク帯域幅を第2のアップリンク帯域幅から減算することができ、第1のダウンリンク帯域幅を第2のダウンリンク帯域幅から減算することができる。ポリシーエンジン225は、受信したサービス要求および/またはサービスフロー抽出器220によって生成されたSDFオブジェクトのQoS情報を認可するように構成された、ハードウェアおよび/または機械可読記憶媒体上の実行可能命令を含むことができる。グループ化されていないSDFの場合、ポリシーエンジン225は、要求されたストリーム帯域幅を認可することができる。グループ化されたSDFの場合、最初に、ポリシーエンジン225は、ストリーム帯域幅を使用して、各SDFに対して要求帯域幅を認可することができる。次に、ポリシーエンジン225は、より高いレベルの帯域幅からストリーム帯域幅を減算することができる。その後、ポリシーエンジン225は、ストリーム帯域幅を使用するSDFをグループから除去することができる。最後に、ポリシーエンジン225は、グループの残りのSDFに対して、調整されたより高いレベルの帯域幅を認可することができる。いくつかのSDFは、計算を必要とするストリーム帯域幅を含むことができる。ポリシーエンジン225は、ストリームのフロー使用に基づいて、個々のストリームのための帯域幅を計算することができる。例えば、データフローはリアルタイムトランスポート制御プロトコルRTCPフローであることをフロー使用が示す場合、最初に、ポリシーエンジン225は、RS帯域幅およびRR帯域幅などの特別に定義された値に基づいて、ストリーム帯域幅を計算しようと試みることができる。定義された値が利用可能ではない場合、ポリシーエンジン225は、より高いレベルの帯域幅の5としてストリーム帯域幅を計算することができる。その後、ポリシーエンジン225は、より高いレベルの帯域幅からストリーム帯域幅を減算することができる。ポリシーエンジン225は、SPR138に記憶された加入者データに基づいて、認可されたQoS情報を調整することができる。ポリシーエンジン225は、Spインタフェース230を介してSPR138に加入者データ記録を要求することができる。要求されたQoS情報が、加入者データ記録によって許可されたQoSを超過する場合、ポリシーエンジン225は、加入者データ記録に適合するように、要求されたQoS情報を低減することができる。要求されたQoS情報が加入者データによって許可されない場合、ポリシーエンジン225は、サービス要求を拒否することもできる。ポリシーエンジン225は、要求されたベアラのQoS限界に基づいて、要求されたQoS情報を制限することもできる。Spインタフェース230は、SPR138などのSPRと通信するように構成された、ハードウェアおよび/または機械可読記憶媒体上に符号化された実行可能命令を含む、インタフェースとすることができる。したがって、Spインタフェース230は、記録要求を送信し、加入プロファイル記録を受信することができる。ルール生成器235は、受信したサービス要求、サービスフロー抽出器220によって生成されたサービスフローオブジェクト、および/または認可されたQoS情報に基づいて、新しいPCCルールを生成するように構成された、ハードウェアおよび/または機械可読記憶媒体上の実行可能命令を含むことができる。最初に、ルール生成器235は、各個別SDFおよびSDFの各グループのための新しいPCCルールオブジェクトを生成することができる。次に、ルール生成器235は、新しいPCCルールのための名前を生成し、それをPCCルールオブジェクトに記憶することができる。PCCルール名は、例えば、先に割り当てられたルール名をインクリメントすること、またはランダムな名前を生成することなど、当業者に知られている任意の方法に従って生成することができる。ルール生成器235は、AAR、CCR、SDF、ならびに/または例えば、認可された帯域幅、フローステータス、および/もしくはフロー記述など、既存のPCCルールから確定される情報を含む他のデータを、PCCルールオブジェクトに挿入することもできる。ルール生成器235は、2つ以上のフロー記述をPCCルールに挿入することができる。フロー記述は、より高いレベルの帯域幅に基づいたSDFのグループ内の各SDFのフロー記述とすることができる。帯域幅を含む、グループについてのQoS情報を、PCCルールに挿入することができる。したがって、PCCルールは、同じQoS情報を共用する複数のフロー記述を有することができる。この時点で、新しいPCCルールは、設定のための準備ができた有効なルールとなることができる。ルール生成器230は、設定のためにGxインタフェース210を介してPGW134にルールを送信することができる。ルール生成器235は、ルールストレージ240にルールを記憶することもできる。ルールストレージ240は、PCRN200によって生成されたPCCルールを記憶することが可能な任意の機械可読媒体とすることができる。したがって、ルールストレージ240は、リードオンリメモリROM、ランダムアクセスメモリRAM、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリデバイス、および/または類似の記憶媒体などの、機械可読記憶媒体を含むことができる。図5に関して以下でさらに詳細に説明するように、ルールストレージ240は、PCRN200によって生成された多くのPCCルールの定義を記憶することができる。そのような定義は、例えば、ルール名、サービスデータフローフィルタ、QoSパラメータ、および課金パラメータを含むことができる。ゲートウェイ制御セッションマネージャ245は、SGWまたはゲートウェイ制御セッションを実施する他のノードにおける設定のために、QoSルールを生成および送信するように構成された、ハードウェアおよび/または機械可読記憶媒体上の実行可能命令を含むことができる。PMIPを利用する実施形態など、QoS保証を提供するためにゲートウェイ制御セッションを利用する様々な実施形態では、ゲートウェイ制御セッションマネージャ245は、PCCルールからQoSルールを生成するために必要な情報を抽出することができる。例えば、ゲートウェイ制御セッションマネージャ245は、ルール名、サービスデータフローフィルタ、およびQoSパラメータをPCCルールから抽出し、新しいQoSルールを生成することができる。その後、ゲートウェイ制御セッションマネージャ245は、新しいQoSルールをGxxインタフェース205を介してSGWまたは他の適切なノードに転送することができる。ルールマネージャ250は、ルールストレージ240に記憶されたPCCルールを選択および更新するように構成された、ハードウェアおよび/または機械可読記憶媒体上の実行可能命令を含むことができる。ルールマネージャ250は、フロー記述を含む要求を受信したとき、受信したフロー記述をルールストレージ240内のPCCルールのフロー記述と照合することによって、PCCルールを選択することができる。ルールマネージャ250は、PCCルールに属するフロー記述を除去することによって、PCCルールを更新することができる。ルールマネージャ250は、PCCルールの帯域幅を調整することもできる。代替として、ルールマネージャ250は、PCCルールを削除し、ルール生成器235が置換ルールを生成することを可能にすることによって、PCCルールを更新することができる。図3は、AAR300の形式を取る例示的なネットワーク発信型のサービス要求メッセージを示している。AAR300は、ダイアメータメッセージプロトコルおよび/または3GPPTS29.214に従って構成することができる。したがって、AAR300は、ヘッダ310と、加入IDフィールド320と、メディアコンポーネントフィールド340と、多くの追加フィールド330とを含むことができる。AAR300のフィールドの順序は様々であり得ることに留意されたい。したがって、例えば、加入IDフィールド320は、メディアコンポーネントフィールド340の後に配置することができる。ヘッダ310は、メッセージ300がAARであることを示す、標準的なダイアメータヘッダとすることができる。したがって、ヘッダ310は、ダイアメータプロトコルおよび3GPPTS29.214によって提供されるような、値が265に設定されたコマンドコードフィールドと、設定されたコマンドフラグフィールドのRビットフィールドとを含むことができる。加入IDフィールド320は、特定の要求に関連する加入を指示するための属性値ペアAVP:attribute-valuepairとすることができる。例えば、加入IDフィールド330は、値100000000000001によって識別される加入がAAR300に関連することを示す。この情報は、加入プロファイル記録にアクセスし、要求されたサービスに関して適切な加入者に課金するために使用することができる。メディアコンポーネントフィールド330は、要求されたサービスのメディアコンポーネントに関するサービス情報を含むことができる。AAR300の例では、要求は、ストリーミングビデオのためのものとすることができる。メディアコンポーネント330は、例えば、ストリームのビデオ部分に対応することができる。メディアコンポーネントフィールド340は、最大要求帯域幅MRBアップリンクULフィールド342、最大要求帯域幅MRBダウンリンクDLフィールド344、メディアタイプフィールド346、および例えばメディアサブコンポーネント350、360、370、380などの1つまたは複数のメディアサブコンポーネントをさらに含むことができる。MRBULフィールド342は、UE110からAN150へのアップリンク方向で使用する、メディアコンポーネントのために要求される帯域幅の量を示すことができる。MRBULフィールド342は、メディアコンポーネント340についての任意のパケットトラフィックに適用することができる。例えば、MRBULフィールド342は、メディアコンポーネント340がアップリンクトラフィックのために20mbpsを要求することを示すことができる。MRBDLフィールド344は、AN150からUE110へのダウンリンク方向で使用する、サービスのために要求される帯域幅の量を示すことができる。MRBDLフィールド344は、メディアコンポーネント340についての任意のパケットトラフィックに適用することができる。例えば、MRBDLフィールド344は、メディアコンポーネント340がダウンリンクトラフィックのために20mbpsを要求することを示す。メディアタイプフィールド346は、例えば、オーディオ、ビデオ、データ、アプリケーション、制御、テキスト、メッセージ、または他のサービスなど、メディアコンポーネントによって提供されるサービスのタイプを示すことができる。メディアタイプフィールド346の内容は、QoSクラス識別子QCI:QoSclassidentifierにマッピングすることができる。メディアサブコンポーネント350、360、370、380は各々、要求されたサービスを提供するために必要な独立したデータストリームを示すことができる。メディアサブコンポーネントは、フロー番号、フロー記述、最大要求帯域幅、およびフロー使用のためのフィールド、ならびにメディアサブコンポーネントを定義するのに役立つ他の任意のフィールドを含むことができる。メディアサブコンポーネントは、上で列挙したよりも少数のフィールドしか含まないこともある。例えば、メディアサブコンポーネント350は、フロー番号フィールド352と、フロー記述フィールド354と、MRBULフィールド356と、MRBDLフィールド358とを含むことができる。フロー番号フィールド352は、メディアコンポーネント340内のメディアサブコンポーネント350に関連するフローを識別するために使用される番号を含むことができる。フロー番号フィールド352は、番号1を含むことができる。フロー記述フィールド354は、メディアサブコンポーネント350のフローに関連するパケットを識別するために使用されるパケットフィルタを含むことができる。フロー記述フィールド354は、トラフィックマッピングと見なすことができる。MRBULフィールド356は、アップリンク方向においてメディアサブコンポーネント350によって使用される最大帯域幅が10mbpsであることを示すことができる。MRBDLフィールド356は、ダウンリンク方向においてメディアサブコンポーネント350によって使用される最大帯域幅も10mbpsであることを示すことができる。別の例として、メディアサブコンポーネント360は、フロー番号フィールド362と、フロー記述フィールド364とを含むことができる。メディアサブコンポーネント360は、要求帯域幅を示すフィールドを欠いていてもよい。フロー番号フィールド362は、このケースでは番号2である、メディアサブコンポーネント360に関連するフローを識別するために使用される番号を含むことができる。フロー記述フィールド364は、メディアサブコンポーネント360のフローに関連するパケットを識別するために使用されるフィルタを含むことができる。フロー記述フィールド364は、トラフィックマッピングと見なすことができる。別の例として、メディアサブコンポーネント370は、フロー番号フィールド372と、フロー記述フィールド374とを含むことができる。メディアサブコンポーネント380は、要求帯域幅を示すフィールドを欠いていてもよい。フロー番号フィールド372は、このケースでは番号3である、メディアサブコンポーネント370に関連するフローを識別するために使用される番号を含むことができる。フロー記述フィールド374は、メディアサブコンポーネント370のフローに関連するパケットを識別するために使用されるフィルタを含むことができる。フロー記述フィールド374は、トラフィックマッピングと見なすことができる。最後の例として、メディアサブコンポーネント380は、フロー番号フィールド382と、フロー記述フィールド384とを含むことができる。フロー番号フィールド382は、このケースでは番号4である、メディアサブコンポーネント380に関連するフローを識別するために使用される番号を含むことができる。フロー記述フィールド384は、メディアサブコンポーネント370のフローに関連するパケットを識別するために使用されるフィルタを含むことができる。フロー記述フィールド374は、トラフィックマッピングと見なすことができる。フロー使用フィールド386は、メディアサブコンポーネント380の使用の表示を含むことができる。いくつかの使用は、帯域幅、または帯域幅を計算するために使用できるルールに関連することができる。例えば、フロー使用フィールド386は、メディアサブコンポーネント380がリアルタイムトランスポート制御プロトコルRTCPフローであることを示すことができる。図2に関して説明したように、RTCPフローは、帯域幅を計算するための特別のルールを使用することができる。追加フィールド330は、ダイアメータプロトコルおよび/または3GPPTS29.214によって規定されるような、追加情報を含むことができる。したがって、追加フィールド330は、例えば、発信ホストAVP、宛先ホストAVP、サポート機能AVP、フレームIPアドレスAVPなどの、追加の属性値ペアAVPを含むことができる。追加フィールド330は、例えば、フロー識別情報など、他の役立つ情報を抽出する際に使用することができる。図4は、CCR400の形式を取る例示的なユーザ機器発信型のサービス要求メッセージを示している。CCR400は、ダイアメータメッセージプロトコルおよび/または3GPPTS29.212に従って構成することができる。したがって、CCR400は、ヘッダ410と、加入IDフィールド420と、ベアラ操作フィールド425と、QoS情報フィールド430と、パケットフィルタ情報フィールド440、450、460、470と、多くの追加フィールド480とを含むことができる。CCR400のフィールドの順序は様々であり得ることに留意されたい。したがって、例えば、加入IDフィールド420は、QoS情報フィールド430の後に配置することができる。CCRメッセージは、例えば、GPRSおよびEPS/LTEなど、異なるタイプのネットワークに対して使用することができる。図4はGPRSネットワークのための要求として示されているが、EPS/LTEまたは他のネットワークも類似の情報を使用して要求を行うことができることを理解されたい。ヘッダ410は、メッセージ400がCCRであることを示す、標準的なダイアメータヘッダとすることができる。したがって、ヘッダ410は、ダイアメータプロトコルおよび/または3GPPTS29.212によって提供されるような、値が258に設定されたコマンドコードフィールドと、設定されたコマンドフラグフィールドのRビットフィールドとを含むことができる。加入IDフィールド420は、特定の要求に関連する加入を指示するための属性値ペアAVPとすることができる。例えば、加入IDフィールド430は、値100000000000001によって識別される加入がCCR400に関連することを示す。この情報は、加入プロファイル記録にアクセスし、要求されたサービスに関して適切な加入者に課金するために使用することができる。ベアラ操作フィールド425は、サービス要求が新しい専用ベアラを要求しているかどうかを示すことができる。ベアラ操作が確立であることをベアラ操作フィールド425が示す場合、PCRN136は、要求を実行するために、専用ベアラを生成することができる。例えば、LTEネットワークからのCCRなど、様々な代替実施形態では、ベアラ操作フィールド425は、パケットフィルタ操作とすることができ、そのケースでは、追加の操作が、専用ベアラを求める要求を示すことができる。ベアラ情報427は、例えば、識別子が0x28B2であるベアラなど、トラフィックを搬送するための要求されたベアラを示すことができる。ベアラ情報427が既存のベアラと一致しない場合、要求は、新しい専用ベアラのためのものとすることができる。ベアラ情報427が含まれない場合、トラフィックは、専用ベアラ、デフォルトベアラ、またはQCIフィールド431に基づいて選択されるベアラに割り当てることができる。QoS情報フィールド430は、要求されたサービスのための要求されたQoS設定を含むことができる。QoS情報フィールド430は、CCR400に含まれるすべてのパケット情報フィールドに適用することができる。QoS情報フィールド430は、QoSクラス識別子QCIフィールド431と、MRBULフィールド432と、MRBDLフィールド433と、QoSを記述するのに役立つ他のフィールドとを含むことができる。QCIフィールド431は、要求されたトラフィックのタイプを示す識別子を含むことができる。MRBULフィールド532は、サービスによって使用される最大帯域幅がアップリンク方向では20mbpsであることを示すことができる。MRBDLフィールド433は、要求されたサービスによって使用される最大帯域幅がダウンリンク方向では20mbpsであることを示すことができる。パケットフィルタ情報フィールド440、450、460、470は、要求されたサービスのための要求された各フローに関するサービス情報を含むことができる。例えばLTEを実施する実施形態など、様々な実施形態では、パケットフィルタ情報フィールド440、450、460、470は、パケットフィルタ情報AVPとすることができる。例えばGPRSを実施する実施形態など、様々な代替実施形態では、パケットフィルタ情報フィールド440、450、460、470は、TFTパケットフィルタ情報AVPとすることができる。パケットフィルタ情報フィールド440、450、460、470は、優先順位フィールドと、フィルタ内容フィールドと、例えば、サービスのタイプ、トラフィッククラス、および/またはフローラベルなどの、追加情報とを含むことができる。パケットトラフィックのフローを識別するためにフィルタ情報を使用できるので、パケットフィルタ情報フィールドは、トラフィックマッピングと見なすことができる。サービスフロー抽出器220は、フロー記述を3GPPTS29.214に従ったフロー記述としてフォーマットしたパケットフィルタ情報からフロー記述を導出することができる。パケットフィルタ情報フィールドは、帯域幅を含まないことがあり、そのため、サービスフロー抽出器220は、QoS情報431に含まれるものなど、より高いレベルの帯域幅に基づいて、帯域幅を割り当てることができる。パケットフィルタ情報の一例として、パケットフィルタ情報フィールド440は、優先順位が4であるTFTパケットフィルタ0x10F2CE32を記述する。別の例として、パケットフィルタ情報フィールド450は、優先順位が3であるTFTパケットフィルタ0x2929B92Cを記述する。別の例として、パケットフィルタ情報フィールド460は、優先順位が2であるTFTパケットフィルタ0x32B56FE1を記述する。最後の例として、パケットフィルタ情報フィールド470は、優先順位が1であるTFTパケットフィルタ0x45192B832を記述する。追加フィールド480は、ダイアメータプロトコルおよび/または3GPPTS29.212によって規定されるような追加情報を含むことができる。したがって、追加フィールド480は、CC要求タイプAVP、フレームIPアドレスAVP、3GPP-SGSNアドレスAVPなどの、追加の属性値ペアAVPを含むことができる。追加フィールド480は、例えば、フロー識別情報など、他の役立つ情報を抽出する際に使用することができる。図5は、PCCルールを記憶するための例示的なデータ構成を示している。データ構成500は、例えば、ルールストレージ240に記憶されたデータベースのテーブルとすることができる。代替として、データ構成500は、一連のリンクリスト、配列、または類似のデータ構造とすることができる。したがって、データ構成500は基礎をなすデータの抽象化であり、このデータの記憶に適したものであればどのようなデータ構造でも使用できることは明らかであろう。データ構成500は、例えば、ルール名フィールド505、サービスデータフローフィルタフィールド510、フローステータスフィールド515、QoSパラメータフィールド520、課金パラメータフィールド525、ベアラフィールド530、およびセッションフィールド535などの、データフィールドを含むことができる。データ構成500は、PCCルールを定義する際に必要な、または役立つ、追加フィールド図示されずを含むことができる。データ構成500は、例えば、ルール540、545、550、555、560など、ルールのための複数のエントリを含むことができる。ルール名フィールド505は、PCCルールに割り当てられるルール名を示すことができる。ルール名は、ルールが生成されるときに、ルール生成器235によって割り当てることができる。サービスデータフローフィルタフィールド510は、データフローに関連するトラフィックパケットを記述する1つまたは複数のパケットフィルタを含むことができる。パケットフィルタは、そのフロー番号順に列挙することができる。サービスデータフローフィルタフィールド510内のパケットフィルタの存在は、そのPCCルールをパケットフィルタに一致するいずれのパケットにも適用すべきであることを示すことができる。フローステータスフィールド515は、トラフィックが各方向に流れることを許可されているかどうかを示すことができる。QoSパラメータフィールド520は、例えば、QCI、MRBUL、およびMRBDLなど、PCCルールについてのQoS情報を含むことができる。QoSパラメータフィールド520は、ネットワークがトラフィックまたはサービスを中止しなければならない場合に、要求されたサービスのプライオリティを示す、割り当て保持プライオリティARP:AllocationRetentionPriorityを含むことができる。課金パラメータ525は、PCCルールに関連するトラフィックに適用される課金方法を示すことができる。ベアラフィールド530は、PCCルールに関連するトラフィックを搬送できるベアラを識別することができる。例えば、UE専用ベアラ制御モードを用いるGPRSを使用する実施形態など、様々な実施形態では、ベアラが識別されない場合、デフォルトベアラがトラフィックを搬送することができる。例えば、LTEの場合など、様々な代替実施形態では、ベアラ識別子を必要としなくてよく、各PCCルールは、専用ベアラで搬送することができる。セッションフィールド535は、PCCルールに関連するIP-CANセッションを示すことができる。データ構成500のエントリの一例として、ルール540は、ルール名が0xE426であるルールを示す。ルール540は、CCR400のサービス要求を実行するPCCルールとすることができる。ルール540は、4つのフロー記述:0x10F2CE32、0x2929B92C、0x32B56FE1、および0x45192B832を含む。各方向のフローステータスは、クローズドであり、トラフィックが流れることを許可され得ないことを示す。トラフィックのQCIは、6である。MRBULは、20mbpsであり、MRBDLは、20mbpsである。PCCルールは、ただ1組のQoS情報しか含まないので、サービスデータフローは、要求帯域幅を共用することができる。この例示的なPCCルールには、1メガバイトのデータ転送当たり5セントの料金を課金することができる。ルールは、ルールが生成されたときに専用ベアラとして生成できる、ベアラ0x28B2によってトラフィックを搬送することができることを示している。ルールは、IP-CANセッションとすることができるセッション0x732Aに関連付けられる。データ構成500のエントリの別の例として、ルール545は、ルール名が0x82A1であるルールを示す。ルール545は、メディアサブコンポーネント350に対応するPCCルールとすることができる。ルール545は、1つのフロー記述0x10F2CE32を含む。フローステータスは、オープンであり、トラフィックが流れることを許可され得ることを示す。トラフィックのQCIは、6である。MRBULは、10mbpsであり、MRBDLは、10mbpsである。PCCルールに関連するトラフィックは、ベアラ0x28B2に割り当てられ、セッション0x732Aに関連付けられる。データ構成500のエントリの別の例として、ルール550は、ルール名が0x82A2であるルールを示す。ルール550は、メディアサブコンポーネント360および370に対応するPCCルールとすることができる。ルール550は、2つのフロー記述0x2929B92Cおよび0x32B56FE1を含む。フローステータスは、オープンであり、トラフィックが流れることを許可され得ることを示す。トラフィックのQCIは、6である。MRBULは、9mbpsであり、MRBDLは、9mbpsである。PCCルールに関連するトラフィックは、ベアラ0x28B2に割り当てられ、セッション0x732Aに関連付けられる。データ構成500のエントリの別の例として、ルール555は、ルール名が0x82A3であるルールを示す。ルール555は、メディアサブコンポーネント380に対応するPCCルールとすることができる。ルール555は、1つのフロー記述0x45192B832を含む。フローステータスは、オープンであり、トラフィックが流れることを許可され得ることを示す。トラフィックのQCIは、6である。MRBULは、1mbpsであり、MRBDLは、1mbpsである。PCCルールに関連するトラフィックは、ベアラ0x28B2に割り当てられ、セッション0x732Aに関連付けられる。図6は、サービス要求に応答して、2つ以上のサービスフローについてのPCCルールを生成するための例示的な方法600を示している。方法600は、サービス要求によって識別されるSDFについてのPCCルールを確立するために、PCRN136および/またはPCRN200のコンポーネントによって実行することができる。方法600は、ステップ605で開始して、ステップ610に進むことができ、ステップ610において、PCRN200は、Rxインタフェース215を介してAARの形式で、および/またはGxxインタフェース205もしくはGxインタフェース210を介してCCRの形式で、サービス要求を受信することができる。その後、方法は、ステップ615に進むことができ、ステップ615において、サービスフロー抽出器220は、受信したメッセージが、先に受信した、または受信することが予想される別の相補的メッセージcomplementarymessageに対応するかどうかを決定することができる。相補的メッセージについてのPCCルールが生成されていない場合、サービスフロー抽出器220は、相補的サービス要求を処理する、当業者に知られた任意の方法に従って、完全なサービス要求を生成することができる。例えば、サービスフロー抽出器220は、衝突が生じた場合には、AARメッセージからの情報に優先権を与えて、両方の要求メッセージからの情報を組み合わせることができる。相補的メッセージについてのPCCルールがすでに生成されている場合、相補的メッセージは、更新メッセージと見なすことができ、方法600は、ステップ620に進むことができる。受信したメッセージが更新メッセージではない場合、方法600は、ステップ630に進むことができる。ステップ620において、サービスフロー抽出器220は、受信したメッセージのトラフィックマッピングに対応する1つまたは複数のフロー記述を、ルールマネージャ250に送信することができる。その後、ルールマネージャ250は、メッセージからのフロー記述に一致するフロー記述を含むPCCルールを求めて、ルールストレージ240を検索することができる。ルールストレージ240が一致するPCCルールを含む場合、ルールマネージャ250は、そのPCCルールをサービスフロー抽出器220に返すことができる。PCCルールは、相補的メッセージと同じ情報を提供し、PCCルールを更新するために使用することができる。次に、方法は、ステップ630に進むことができる。ステップ630において、サービスフロー抽出器220は、サービス要求からサービスフロー情報を抽出し、各トラフィックマッピングについてのSDFを生成することができる。AARの場合、サービスフロー抽出器220は、AARからメディアコンポーネントおよびメディアサブコンポーネントを抽出し、各メディアサブコンポーネントについてのSDFを確立することができる。メディアサブコンポーネントについてのSDFは、フロー記述AVP354および364などのフロー記述からのトラフィックマッピングを含むことができる。CCRの場合、サービスフロー抽出器220は、例えば、パケットフィルタ情報440および450などの、各パケットフィルタ情報フィールドについてのサービスフローオブジェクトを確立することができる。サービスフロー抽出器220は、例えば、TFTフィルタAVPまたはフィルタ内容AVPなどのトラフィックマッピングを、パケットフィルタ情報フィールドから抽出することができる。その後、サービスフロー抽出器220は、トラフィックマッピングからフロー記述を導出し、フロー記述をSDFに記憶することができる。サービス要求が、AARメッセージとCCRメッセージの両方からの情報、または一致したPCCルールからの情報を含む場合、サービスフロー抽出器220は、各データストリームについての単一のSDFを生成するために、フロー記述をパケットフィルタと照合することができる。その後、方法600は、ステップ635に進むことができる。ステップ635において、サービスフロー抽出器220は、より高いレベルの帯域幅によってSDFをグループ化することができる。AARメッセージの場合、より高いレベルの帯域幅は、メディアコンポーネントのために要求される帯域幅を含むことができる。メディアコンポーネント内のメディアサブコンポーネントに対応する各SDFは、一時的に一緒にグループ化することができる。CCRメッセージの場合、より高いレベルの帯域幅は、CCRメッセージ内のすべてのパケットフィルタ情報に適用される、QoS情報フィールド430などのQoS情報フィールド内の帯域幅を含むことができる。CCRメッセージ内の1組のパケットフィルタ情報に対応する各SDFは、一時的に一緒にグループ化することができる。その後、サービスフロー抽出器220は、グループ化されたSDFをポリシーエンジン225に送信することができる。その後、方法600は、ステップ640に進むことができる。ステップ640において、ポリシーエンジン225は、グループ内のいずれかのSDFがストリーム帯域幅を含むかどうかを決定することができる。ストリーム帯域幅は、単一のSDFのために要求される帯域幅の何らかの表示とすることができる。例えば、メディアサブコンポーネント350などのメディアサブコンポーネントは、MRBUL356およびMRBDL358を含むことができる。別の例として、メディアサブコンポーネント380などのメディアサブコンポーネントは、SDFがRTCPフローであることを示すフロー使用フィールド386を含むことができる。ポリシーエンジン225は、RTCPフローのためのストリーム帯域幅を計算することができる。ストリーム帯域幅は、CCRメッセージのパケットフィルタ情報フィールド内に含むことができる。グループ内のSDFがストリーム帯域幅を含む場合、方法600は、ステップ645に進むことができる。グループ内のSDFがストリーム帯域幅を含まない場合、方法600は、ステップ660に進むことができる。ステップ645において、ポリシーエンジン225は、グループのより高いレベルの帯域幅から、SDFのストリーム帯域幅を減算することができる。例えば、ポリシーエンジン225は、メディアコンポーネントに割り当てられた帯域幅から、メディアサブコンポーネントに割り当てられた帯域幅を減算することができる。減算演算は、アップリンク帯域幅とダウンリンク帯域幅の両方に対して実行することができる。減算演算の結果、より高いレベルの帯域幅が負になった場合、ポリシーエンジン225は、サービス要求に誤りがあると判定し、要求を拒否することができる。その後、方法は、ステップ650に進むことができ、ステップ650において、ポリシーエンジン225は、SDFのためのストリーム帯域幅を認可することができる。ポリシーエンジン225は、この時点で、SDFのための他のQoS情報も認可することができる。その後、方法は、ステップ655に進むことができ、ステップ655において、ポリシーエンジン225は、グループからSDFを除去することができる。その後、方法は、ステップ640に戻ることができ、ステップ640において、ポリシーエンジン225は、グループがストリーム帯域幅を含むいずれかのSDFをまだ含むかどうかを判定することができる。ステップ660において、ポリシーエンジン225は、SDFのグループのためのより高いレベルの帯域幅を認可することができる。認可されたより高いレベルの帯域幅は、ステップ645において帯域幅が減算された場合は、最初に要求されたものよりも低いことがある。ポリシーエンジン225は、サービス要求に含まれる情報に基づいて、SDFのグループのための他のQoS情報も認可することができる。ポリシーエンジン225は、QoS情報をひとたび認可すると、サービスデータフローをルール生成器235に渡すことができ、方法600は、ステップ665に進むことができる。ステップ665において、ルール生成器235は、SDFに基づいて、PCCルールを生成または更新することができる。ルール生成器235は、同じ認可された帯域幅を共用するSDFの各グループについての1つのルールと、ストリーム帯域幅を使用する各個別SDFについての1つのルールを生成することができる。ルール生成器235は、ルールストレージ240内に見出されたPCCルールを更新する場合、SDFのグループについての情報を使用して、見出されたPCCルールを更新し、各個別SDFについての新しいルールを生成することができる。各ルールは、各SDFについてのQoS情報とサービスフロー情報の認可された組を含むことができる。サービスフロー情報の各組は、サービスフローフィルタと、サービスフローフィルタを適用する順序を決定するためのフロー番号とを含むことができる。フロー番号は、AARメッセージからのフロー番号、またはCCRメッセージからの優先順位値に基づくことができる。ルール生成器235は、ポリシーエンジン225によって決定された課金パラメータをPCCルールに含めることができる。サービス要求がベアラ識別子を含む場合、ルール生成器235は、ベアラ識別子をPCCルールに含めることができる。ルール生成器235は、例えば、ルール名およびフローステータスなど、PCCルールについての他の情報も生成することができる。ルール生成器245は、PCCルールをルールストレージ240に保存することができる。その後、方法は、ステップ670に進むことができ、ステップ670において、Gxインタフェース210は、PCCルールをPGW134に送信することができる。その後、PGW134は、各PCCルール内のサービスフローフィルタのすべてにQoS情報が適用されるように、PCCルールを実施することができる。このようにして、PCCルールは、要求されたサービスを提供する。その後、方法は、ステップ675に進むことができ、ステップ675において、終了する。図7は、2つ以上のSDFを有するPCCルールを実施する例示的な通信リンク700を示している。通信リンク700は、IP-CANセッション705と、ベアラ710と、PCCルール720、730、750と、サービスデータフロー725、735、737、745とを含むことができる。IP-CANセッション705は、UE110とPGW134の間で通信リンクを確立するセッションとすることができる。IP-CANセッション705は、パケットデータネットワーク140との通信を可能にするために、IPアドレスをUE110に割り当てることができる。IP-CANセッション705は、ベアラ710などのベアラを含むことができる。IP-CANセッション705は、デフォルトベアラおよび他の専用ベアラなどの、他のベアラ図示されずも含むことができる。ベアラ710は、要求メッセージにおいて指示されたトラフィックを搬送するために、AAR300に応答して生成されるベアラとすることができる。ベアラ710は、IP-CANセッション705内のベアラを一意的に識別するために、識別子0x28B2を含むことができる。ベアラ710は、QoSを管理するために、PCCルール720、730、740を含むことができる。PCCルール720は、アップリンクでは10mbpsの、またダウンリンクでは10mbpsの最大帯域幅を確立することができる。PCCルール720は、QoSを管理し、サービスに対して課金を行うための、他のQoS情報も含むことができる。PCCルール720は、例えば、サービスデータフロー725などの、1つまたは複数のサービスデータフローを含むことができる。サービスデータフロー725は、メディアサブコンポーネント350のフロー記述と一致するフロー記述によって指示されるので、メディアサブコンポーネント350に対応することができる。サービスデータフロー725は、PCCルール720内のただ1つのサービスデータフローであり、そのため、サービスデータフロー725は、PCCルール720のすべての帯域幅を使用することができる。帯域幅は、メディアサブコンポーネント350のために要求された帯域幅に対応することができる。PCCルール730は、アップリンクでは9mbpsの、またダウンリンクでは9mbpsの最大帯域幅を確立することができる。PCCルール730は、サービスデータフロー735および737を含むことができる。これらのサービスデータフローは、一致するフロー記述によって指示されるので、メディアサブコンポーネント360および370にそれぞれ対応することができる。PCCルール730は、2つのサービスデータフローを含み、そのため、サービスデータフロー735および737は、PCCルール730の帯域幅を共用することができる。帯域幅は、メディアコンポーネント340のために要求された帯域幅から、メディアコンポーネント340内のメディアサブコンポーネントに割り当てられたストリーム帯域幅をマイナスしたものに対応することができる。PCCルール740は、アップリンクでは1mbpsの、またダウンリンクでは1mbpsの最大帯域幅を確立することができる。PCCルール740は、サービスデータフロー745を含むことができる。サービスデータフロー745は、一致するフロー記述によって指示されるので、メディアサブコンポーネント380に対応することができる。PCCルール740は、ただ1つのサービスデータフローを含み、そのため、サービスデータフロー745は、PCCルール740のすべての帯域幅を使用することができる。帯域幅は、メディアコンポーネント380のために要求された帯域幅に対応することができる。例示的な加入者ネットワーク100およびPCRN200の動作のための例示的なコンポーネントおよび方法を説明してきたが、例示的なネットワーク100およびPCRN200の動作の一例が、今から図1-図6を参照しながら提供される。PCRN136は、PCRN200に対応することができる。AAR300は、AAR160に対応することができる。CCR400は、CCR170に対応することができる。データ構成500は、ルールストレージ240の内容に対応することができる。プロセスは、PCRN200がSGW134からCCR400を受信したときに開始することができる。CCR400は、サービスを求める第1のメッセージとすることができ、相補的メッセージまたは更新メッセージと見なさなくてよい。サービスフロー抽出器220は、パケットフィルタ情報440、450、460、470の各々に1つの、4つのトラフィックマッピングをCCR400から抽出することができる。次に、サービスフロー抽出器220は、トラフィックマッピングの各々についてのSDFを生成することができる。SDFを生成するには、パケットフィルタ情報からフロー記述を導出することが必要なことがある。その後、サービスフロー抽出器220は、MRBUL432およびMRBUL433のより高いレベルの帯域幅がトラフィックマッピングの各々に適用されるので、SDFを一緒にグループ化することができる。ポリシーエンジン225は、パケットフィルタ情報のいずれもがストリーム帯域幅を含まないので、グループのための帯域幅を認可することができる。ポリシーエンジン225は、QoS情報フィールド431内の他のQoS情報を認可し、課金パラメータを決定することもできる。ルール生成器235は、SDFのグループに基づいて、サービス要求についてのルール530などのPCCルールを生成することができる。ルール530は、CCR400から抽出されたSDFの各々についての、サービスフローフィルタを含む、フロー情報を含む。ルール530は、QoS情報フィールド431からの認可されたQoS情報も含む。プロセスは、PCRN200がAN150からAAR300を受信したときに続行することができる。AAR300は、CCR400と同じサービスを要求する相補的メッセージとすることができる。AAR300は、PCRN200がCCR400に応答してPCCルールをすでに生成した後に到着することがあり、そのため、AAR300は、更新メッセージであることもある。サービスフロー抽出器220は、例えば、フロー記述354などの、AAR300のフロー記述をルールマネージャ250に送信することができる。ルールマネージャ250は、フロー記述を使用して、PCCルールストレージ240を検索することができる。ルールマネージャ250は、フロー記述354がルール530のサービスデータフローフィルタの1つと一致するので、ルール530を見つける。ルールマネージャ250は、ルール530が更新され得るように、ルール530をサービスフロー抽出器に渡すことができる。サービスフロー抽出器220は、AAR300の各メディアサブコンポーネントからトラフィックマッピングを抽出することによって、新しいPCCルールの生成を続行することができる。サービスフロー抽出器220は、トラフィックマッピングを一致したルール530のSDFフィルタと照合することもできる。次に、サービスフロー抽出器220は、各トラフィックマッピングについてのSDFを生成し、MRBUL342およびMRBDL344内に見出されるより高いレベルの帯域幅に基づいて、それらを一緒にグループ化することができる。メディアサブコンポーネント350およびメディアサブコンポーネント380についてのSDFは、ストリーム帯域幅を含むことができるが、一時的にメディアサブコンポーネント360および370とグループ化することができる。最初に、ポリシーエンジン225は、メディアサブコンポーネント350がMRBUL356およびMRBDL358を含むので、メディアサブコンポーネント350のためのSDFがストリーム帯域幅を含むことを決定することができる。次に、ポリシーエンジン225は、SDFのグループのためのより高いレベルの帯域幅から、メディアサブコンポーネント350のための帯域幅を減算することができる。減算演算は、SDFのグループのために、アップリンクでは10mbpsを、またダウンリンクでは10mbpsを残す。その後、ポリシーエンジン225は、メディアサブコンポーネント350のための、MRBUL356およびMRBDL358内の帯域幅を認可することができる。その後、ポリシーエンジン225は、グループからメディアサブコンポーネント350のためのSDFを除去することができる。次に、ポリシーエンジン225は、メディアサブコンポーネント380がフロー使用フィールド386によって示されるようにRTCPフローであるので、メディアサブコンポーネント380のためのSDFがストリーム帯域幅を含むことを決定することができる。ポリシーエンジン225は、メディアコンポーネントのために要求された帯域幅の5パーセントとして、メディアサブコンポーネント380のためのストリーム帯域幅を計算することができる。したがって、メディアサブコンポーネント380は、アップリンクでは1mbpsの、またダウンリンクでは1mbpsのストリーム帯域幅を有することができる。次に、ポリシーエンジン225は、この帯域幅をSDFのグループのためのより高いレベルの帯域幅から減算して、アップリンクでは9mbpsの、またダウンリンクでは9mbpsの帯域幅を残すことができる。その後、ポリシーエンジン225は、メディアサブコンポーネント380のために、アップリンクでは1mbpsの、またダウンリンクでは1mbpsの帯域幅を認可することができる。その後、ポリシーエンジン225は、SDFのグループからメディアサブコンポーネント380のためのSDFを除去することができる。その後、ポリシーエンジン225は、SDFのグループがストリーム帯域幅を有するSDFを含まないことを決定することができる。その後、ポリシーエンジン225は、SDFのグループのために、アップリンクでは9mbpsの、またダウンリンクでは9mbpsのより高いレベルの帯域幅を認可することができる。その後、ポリシーエンジン225は、SDFをルール生成器235に渡すことができる。ルール生成器235は、ストリーム帯域幅を含む各SDFについての、またSDFの各グループについての、PCCルールを生成することができる。最初に、ルール生成器235は、メディアサブコンポーネント350に対応するSDFについてのルール535を生成することができる。次に、ルール生成器235は、メディアサブコンポーネント360および370に対応するSDFのグループについてのルール540を生成することができる。このルールは、ルール530に対する更新とすることができる。最後に、ルール生成器235は、メディアサブコンポーネント380に対応するSDFについてのルール545を生成することができる。これらのルールの詳細は、図7に関して上で説明された。PCCルールは、Gxインタフェース210を介してPGW134に送信することができ、PGW134において、PCCルールは、要求されたサービスを提供するために使用することができる。PCCルールは、ルールストレージ240に記憶することもできる。ゲートウェイ制御セッションマネージャ245は、データ構成500からQoS関連部分を抽出し、QoSルールをGxxインタフェース205を介してSGW132に送信することによって、PCCルールからQoSルールを生成することができる。上述の説明によれば、様々な例示的な実施形態は、トラフィックマッピングについてのPCCルールを不完全なQoS情報を用いて生成することが可能なPCRNを提供する。特に、複数のサービスデータフローを有するPCCルールを生成することによって、PCRNは、トラフィックマッピングが、トラフィックマッピングよりも高いレベルの要求メッセージに含まれるQoS情報を共用することを可能にすることができる。さらに、より高いレベルの帯域幅から、個々のフローに割り当てられた帯域幅を減算することによって、PCRNは、特別な帯域幅を割り当てることなく、サービス要求を実行することができる。本発明の様々な例示的な実施形態は、ハードウェアおよび/またはファームウェアで実施できることが、上述の説明から明らかであろう。さらに、様々な例示的な実施形態は、機械可読記憶媒体上に記憶された命令として実施することができ、命令は、本明細書で詳細に説明された動作を実行するために、少なくとも1つのプロセッサによって読み込み、実行することができる。機械可読記憶媒体は、パーソナルもしくはラップトップコンピュータ、サーバ、または他のコンピューティングデバイスなどの機械によって可読な形式で情報を記憶するための、任意の機構を含むことができる。したがって、機械可読記憶媒体は、リードオンリメモリROM、ランダムアクセスメモリRAM、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリデバイス、および類似の記憶媒体を含むことができる。本明細書のどのブロック図も、本発明の原理を具現する例示的な回路の概念図を表していることを当業者であれば理解されたい。同様に、いずれのフローチャート、フロー図、状態遷移図、および疑似コードなども、様々なプロセスを表しており、様々なプロセスは、実質的に機械可読媒体内に表すことができ、そのため、コンピュータまたはプロセッサが明示的に示されているかどうかに係わらず、そのようなコンピュータまたはプロセッサによって実行できることが理解されよう。様々な例示的な実施形態が、実施形態のある例示的な態様を特に参照して、詳細に説明されたが、本発明は他の実施形態も可能であり、その詳細は様々な明らかな点において変更が可能であることを理解されたい。当業者には容易に明らかなように、本発明の主旨および範囲内に留まりながら、変形および変更を施すことができる。したがって、上述の開示、説明、および図は、説明を目的としたものにすぎず、特許請求の範囲によってのみ確定される本発明をいかなる形でも限定するものではない。