(57)【要約】  無線アクセス・ネットワーク（ＲＡＮ）内の輻輳を制御するためのシステムおよび方法が開示される。一実施形態は、ネットワークの課金システムを備える。課金システムは、ＲＡＮの領域内の輻輳状態を示す、ＲＡＮについてのトラフィック報告を受信する。次いで、課金システムは、輻輳状態に応じて、ＲＡＮの領域内の加入者を識別し、加入者のサービス・プランを識別し、加入者のサービス・プランにおける事前に定義されたルールから逸脱する、修正されたルールを生成する。次いで、課金システムは、加入者によって要求されたサービスのポリシーおよび課金制御を実行する、ポリシーおよび課金ルール機能（ＰＣＲＦ）などのネットワーク・エンティティに、修正されたルールを提供する。
2015537408.tif 000002
【特許請求の範囲】
【請求項１】
パケット・コア・ネットワークを介して確立されたセッションに課金するように構成された課金システムを備えるシステムであって、前記課金システムが、
モバイル・デバイスの接続性を前記パケット・コア・ネットワークに提供する無線アクセス・ネットワーク（ＲＡＮ）についてのトラフィック報告を受信し、前記ＲＡＮの領域内の輻輳状態を検出するために前記トラフィック報告を解析するように構成されたトラフィック・ユニットと、
加入者のサービス・プランを記憶するように構成されたルール・コントローラとを備え、
前記ルール・コントローラが、前記ＲＡＮの前記領域内の前記輻輳状態の検出に応じて、前記ＲＡＮの前記領域に位置する加入者を識別し、前記加入者のために事前に定義されたルールを含むサービス・プランを識別し、前記輻輳状態に対処するために、前記加入者の前記サービス・プランにおいて前記事前に定義されたルールから逸脱する、修正されたルールを生成し、前記加入者によって要求されたサービスが前記輻輳状態の間にどのように提供されるかを一時的に変更できるようにするために、前記サービスのためにポリシーおよび課金制御を実行するネットワーク・エンティティに前記修正されたルールを提供するように構成される、システム。
【請求項２】
前記ルール・コントローラが、前記輻輳状態に応じて、前記サービス・プランにおいて事前に定義されたサービス品質（ＱｏＳ）をダウングレードまたはアップグレードするために、前記修正されたルールを生成するようにさらに構成される、請求項１に記載のシステム。
【請求項３】
前記ルール・コントローラが、前記輻輳状態に応じて、前記サービス・プランにおいて事前に定義された料金を上げる、または下げるために、前記修正されたルールを生成するようにさらに構成される、請求項１に記載のシステム。
【請求項４】
前記ルール・コントローラが、前記加入者のモバイル・デバイスに、前記修正されたルールを記述する通知を送信するようにさらに構成される、請求項１に記載のシステム。
【請求項５】
前記ネットワーク・エンティティが、ポリシーおよび課金ルール機能（ＰＣＲＦ）を備え、
前記課金システムが、ダイアメータＳｙインターフェースを介して前記ＰＣＲＦに接続するように構成され、
前記トラフィック・ユニットが、前記ＲＡＮについての前記トラフィック報告を前記ＰＣＲＦから受信するようにさらに構成され、
前記課金システムが、前記ＰＣＲＦから、前記ＲＡＮの前記領域のセル識別子を定義する属性値ペア（ＡＶＰ）を含むメッセージを受信するようにさらに構成され、
前記課金システムが、前記ＰＣＲＦから、前記ＲＡＮの前記領域の輻輳レベルを定義する属性値ペア（ＡＶＰ）を含むメッセージを受信するようにさらに構成される、請求項１に記載のシステム。
【請求項６】
パケット・コア・ネットワークを介して確立されたセッションに課金する課金システムにおいて動作可能な方法であって、
前記課金システムにおいて、モバイル・デバイスの接続性を前記パケット・コア・ネットワークに提供する無線アクセス・ネットワーク（ＲＡＮ）についてのトラフィック報告を受信するステップと、
前記課金システムによって、前記ＲＡＮの領域内の輻輳状態を検出するために、前記トラフィック報告を解析するステップと、
前記課金システムによって、前記ＲＡＮの前記領域内の前記輻輳状態の検出に応じて、前記ＲＡＮの前記領域に位置する加入者を識別するステップと、
前記加入者のために事前に定義されたルールを含むサービス・プランを識別するステップと、
前記課金システムによって、前記輻輳状態に対処するために、前記加入者の前記サービス・プランにおいて前記事前に定義されたルールから逸脱する、修正されたルールを生成するステップと、
前記加入者によって要求されたサービスが前記輻輳状態の間にどのように提供されるかを一時的に変更できるようにするために、前記課金システムから、前記サービスについてポリシーおよび課金制御を実行するネットワーク・エンティティに前記修正されたルールを提供するステップとを備える、方法。
【請求項７】
前記修正されたルールを生成するステップが、
前記輻輳状態に応じて、前記サービス・プランにおいて事前に定義されたサービス品質（ＱｏＳ）をダウングレードするステップを備える、請求項６に記載の方法。
【請求項８】
前記修正されたルールを生成するステップが、
前記輻輳状態に応じて、前記サービス・プランにおいて事前に定義された料金を上げるステップを備える、請求項６に記載の方法。
【請求項９】
前記加入者のモバイル・デバイスに、前記修正されたルールを記述する通知を送信するステップをさらに備える、請求項６に記載の方法。
【請求項１０】
前記ネットワーク・エンティティが、ポリシーおよび課金ルール機能（ＰＣＲＦ）を備え、
前記課金システムから前記修正されたルールを提供するステップが、ダイアメータＳｙインターフェースを介して前記ＰＣＲＦに接続するステップを備え、
前記ＲＡＮについての前記トラフィック報告を受信するステップが、前記ＰＣＲＦから前記ＲＡＮについての前記トラフィック報告を受信するステップを備え、
前記ＲＡＮについての前記トラフィック報告を受信するステップが、前記ＰＣＲＦから、輻輳している前記ＲＡＮの前記領域のセル識別子を定義する属性値ペア（ＡＶＰ）を含むメッセージを受信するステップを備え、
前記ＲＡＮについての前記トラフィック報告を受信するステップが、前記ＰＣＲＦから、前記ＲＡＮの前記領域内の輻輳レベルを定義する属性値ペア（ＡＶＰ）を含むメッセージを受信するステップを備える、請求項６に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ネットワークの分野に関し、具体的には、無線アクセス・ネットワーク（ＲＡＮ）内の輻輳を制御することに関する。
【背景技術】
【０００２】
一般的に、サービス・プロバイダは、多数の音声およびデータ・サービスをエンド・ユーザ（加入者とも呼ばれる）に提供する。音声サービスの例には、音声呼、着信転送、キャッチ・ホン等がある。データ・サービスの例には、ストリーミング・オーディオ、ストリーミング・ビデオ、ボイス・オーバー・インターネット・プロトコル（ＶｏＩＰ）、オンライン・ゲーム、およびＩＰ−ＴＶがある。データ・サービスは、エンド・ユーザと、インターネットなどの外部パケット・データ・ネットワーク（ＰＤＮ）をインターフェースで接続する、パケット・コア・ネットワークによって管理される。パケット・コア・ネットワークのいくつかの例には、汎用パケット無線サービス（ＧＰＲＳ）・コア・ネットワーク、進化型パケット・コア（ＥＰＣ）・ネットワーク等がある。データ・サービスを利用するために、エンド・ユーザは、携帯電話などのモバイル・デバイスを使用して、無線アクセス・ネットワーク（ＲＡＮ）と接続する。ＲＡＮは、ＩＰ接続性アクセス・ネットワーク（ＣＡＮ）とも呼ばれる、ＩＰ接続性を提供するパケット・ベースのネットワークでよい。次に、ＲＡＮは、エンド・ユーザにデータ・サービスへのアクセスを提供するために、パケット・コア・ネットワークと接続する。
【０００３】
モバイル・デバイスがセッション（たとえば、ＩＰ−ＣＡＮセッション）を開始するとき、モバイル・デバイスからのセッション要求は、要求されたサービス（たとえば、オンライン・ゲーム、ＩＰ−ＴＶ等）の記述を含む。パケット・コア・ネットワークは、モバイル・デバイスを認証して、モバイル・デバイスが受信を許可されるのはどのサービスかを決定する。要求されたサービスが許可される場合には、パケット・コア・ネットワークが、選択されたパケット・データ・ネットワーク（ＰＤＮ）を介して、定義された容量、遅延、およびビット・エラー・レートのベアラ・パス（たとえば、ＩＰ  ＣＡＮベアラ）を確保する。次いで、ＰＤＮを介して、サービス・データ・フローと呼ばれる、サービスのためのパケットのフローを開始することができる。
【０００４】
ネットワーク・オペレータは、サービスがエンド・ユーザにどのように提供されるかを制御するために、それらのネットワーク内にポリシーおよび課金制御（ＰＣＣ）を実装する。ポリシー制御は、ベアラ確立、サービス品質（ＱｏＳ）制御、およびゲーティング制御（パケットが通過することをブロックする、または許す）などのための、サービス・データ・フローのためのベアラ・パスを制御するプロセスを指す。ポリシー・ルールは、エンド・ユーザごとに事前に定義されており、エンド・ユーザがアクセスを許されるのはどのネットワーク・サービスか、提供される帯域幅レベル、いつサービスが許されるか、どのくらい長くサービスが許されるか等を管理する。課金制御は、サービス・データ・フローのパケットを課金キーまたは課金識別子に関連付けて、必要に応じてオンライン課金および／またはオフライン課金を適用するプロセスを指す。課金ルールは、エンド・ユーザごとに事前に定義されており、サービスに適用される課金のタイプ、サービスに適用される料金（ｔａｒｉｆｆ）等を管理する。ポリシー・ルールおよび課金ルールは、エンド・ユーザが加入しているサービス・プランに記載されている。
【０００５】
第３世代パートナーシップ・プロジェクト（３ＧＰＰ、３ＧＰＰ２）は、パケット・コア・ネットワークのポリシーおよび課金制御を提供するＰＣＣアーキテクチャを定めている。ＰＣＣアーキテクチャの一例は、３ＧＰＰ  ＴＳ  ２３．２０３（Ｒｅｌｅａｓｅ  ９）に記載されている。３ＧＰＰによって提案されるＰＣＣアーキテクチャには、ポリシーおよび課金ルール機能（ＰＣＲＦ）、ポリシーおよび課金施行機能（ＰＣＥＦ）を備えるＰＤＮゲートウェイ、アプリケーション機能（ＡＦ）、ベアラ・バインディングおよびイベント報告機能（ＢＢＥＲＦ）、ホーム加入者サーバ（ＨＳＳ）／加入プロファイル・リポジトリ（ＳＰＲ）、オンライン課金システム（ＯＣＳ）、ならびにオフライン課金システム（ＯＦＣＳ）がある。ＰＣＣアーキテクチャの要素のうちのいくつかの簡単な説明として、ＰＣＲＦが、サービス・データ・フローのためにどのＰＣＣルールを実装するべきか選択するために、ポリシー制御判断およびフロー・ベースの課金制御判断を行う。ゲートウェイ内のＰＣＥＦが、サービス・データ・フロー検出、ユーザ・プレーン・トラフィック処理、ＱｏＳ処理、サービス・データ・フロー測定、およびオンライン／オフラインの課金相互作用を提供する。ＨＳＳ／ＳＰＲは、加入者プロファイルなどの、エンド・ユーザについての加入者データおよび加入関連情報を記憶する。
【０００６】
ＰＣＣアーキテクチャ内のＰＣＲＦは、エンド・ユーザがサービスを要求するとＰＣＣ判断を行う。現在、ＰＣＲＦは、エンド・ユーザのサービス・プランに記載された、そのエンド・ユーザのために事前に定義されたポリシー・ルールと課金ルールのセットに基づいてＰＣＣ判断を行う。たとえば、エンド・ユーザは、１０Ｍｂｐｓのダウンロード速度および２Ｍｂｐｓのアップロード速度を保証する、「ゴールド」クラスのサービスに加入することができる。ネットワーク・オペレータは、ほとんどの時間、これらのダウンロードおよびアップロード速度を保証することができる。しかし、ＲＡＮの領域内に輻輳が発生している場合など、これらの速度が可能でない可能性がある場合がある。ネットワーク・オペレータは、ＲＡＮ内などの、ネットワーク内の輻輳問題を処理するための方法を模索し続けている。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】３ＧＰＰ  ＴＳ  ２３．２０３（Ｒｅｌｅａｓｅ  ９）
【発明の概要】
【課題を解決するための手段】
【０００８】
本明細書に記載の実施形態は、ＲＡＮ内の輻輳問題に対処するために、エンド・ユーザのサービス・プランにおいて事前に定義されているポリシーおよび／または課金ルールを動的に修正する。ＲＡＮの領域内に輻輳状態がある場合、課金システムにトラフィック報告が提供される。トラフィック報告は、ＲＡＮ内に輻輳（または、無状態（ｎｏ  ｃｏｎｄｉｔｉｏｎ））が発生していることを示すことができる。ＲＡＮの輻輳の影響を緩和するために、課金システムは、ＲＡＮの輻輳によって影響を受けるエンド・ユーザのポリシーおよび／または課金ルールを変更する。たとえば、エンド・ユーザのサービス・プランがＱｏＳを定義する場合、課金システムは、輻輳が発生しているＲＡＮの領域内にエンド・ユーザが位置している間、ＱｏＳをダウングレードすることができる。エンド・ユーザのサービス・プランが音声呼の料金を定義する場合、課金システムは、輻輳が発生しているＲＡＮの領域内にエンド・ユーザが位置している間、料金を上げることができる。エンド・ユーザのポリシーおよび／または課金ルールへの調整は、輻輳が発生しているＲＡＮの領域内に位置している間は、エンド・ユーザがセッションを開始することを思いとどまらせることを意図する。十分な数のエンド・ユーザがセッション開始を思いとどまると、ＲＡＮ内の輻輳状態の深刻さが緩和し、将来的に発生しなくなる。
【０００９】
課金システムは、輻輳が発生しておらず、十分に活用されていないＲＡＮの他の領域の使用を奨励するために、エンド・ユーザのポリシーおよび／または課金ルールも変更することができる。たとえば、課金システムは、低トラフィック量を処理しているＲＡＮの領域内にエンド・ユーザが位置している場合、ＱｏＳをアップグレードする、料金を下げる、あるいはポリシーおよび／または課金ルールを調整することができる。エンド・ユーザのポリシーおよび／または課金ルールへの調整は、輻輳が発生しているＲＡＮの領域を使用する代わりに、十分に活用されていないＲＡＮの領域内に位置するときに、エンド・ユーザがセッションを開始することを奨励することを意図する。
【００１０】
ある実施形態は、ＲＡＮの領域内の輻輳状態を示す、ＲＡＮについてのトラフィック報告を受信するように構成された課金システムを備える。課金システムは、輻輳状態に応じて、ＲＡＮの領域内の加入者を識別し、加入者のサービス・プランを識別し、加入者のサービス・プランにおける事前に定義されたルールから逸脱する修正されたルールを生成するようにさらに構成される。課金システムは、加入者によって要求されたサービスのポリシーおよび課金制御を実行する、ポリシーおよび課金ルール機能（ＰＣＲＦ）などのネットワーク・エンティティに、修正されたルールを提供するようにさらに構成される。
【００１１】
別の実施形態では、課金システムは、サービス・プランにおいて事前に定義されたサービス品質（ＱｏＳ）をダウングレードまたはアップグレードするために、修正されたルールを生成するようにさらに構成される。
【００１２】
別の実施形態では、課金システムは、サービス・プランにおいて事前に定義された料金を上げる、または下げるために、修正されたルールを生成するようにさらに構成される。
【００１３】
別の実施形態では、課金システムは、加入者のモバイル・デバイスに、修正されたルールを記述する通知を送信するようにさらに構成される。
【００１４】
別の実施形態では、課金システムは、ダイアメータＳｙインターフェース（Ｄｉａｍｅｔｅｒ  Ｓｙ  ｉｎｔｅｒｆａｃｅ）を介してＰＣＲＦに接続する。課金システムは、メッセージ（たとえば、ダイアメータＳｙメッセージ）内のＰＣＲＦから、ＲＡＮについてのトラフィック報告を受信するようにさらに構成される。メッセージは、ＲＡＮの領域のセル識別子について定義された属性値ペア（ＡＶＰ）、ＲＡＮの領域の輻輳レベルを定義するＡＶＰ、および／またはＲＡＮの領域が輻輳状態を経験する時間を定義するＡＶＰを含み得る。
【００１５】
別の実施形態は、ＲＡＮ内の輻輳状態に基づいて加入者のためのルールを修正する方法を備える。本方法は、課金システムにおいて、ＲＡＮの領域内の輻輳状態を示す、ＲＡＮについてのトラフィック報告を受信するステップを含む。本方法は、輻輳状態に応じて、ＲＡＮの領域内の加入者を識別し、加入者のサービス・プランを識別し、加入者のサービス・プランにおける事前に定義されたルールから逸脱する修正されたルールを生成するステップをさらに含む。本方法は、課金システムから、加入者によって要求されたサービスのポリシーおよび課金制御を実行する、ポリシーおよび課金ルール機能（ＰＣＲＦ）などのネットワーク・エンティティに、修正されたルールを提供するステップをさらに含む。
【００１６】
別の実施形態は、ネットワークのＰＣＣアーキテクチャを備える。本アーキテクチャは、ダイアメータＳｙインターフェースを介してＰＣＲＦに結合された課金システムを含む。本課金システムは、ＲＡＮの領域内の輻輳状態を示すメッセージを、ダイアメータＳｙインターフェースを介してＰＣＲＦから受信するように構成される。本課金システムは、ＲＡＮの領域内の加入者を識別し、加入者のサービス・プランを識別し、ＲＡＮの領域内の輻輳状態に対処するために加入者のサービス・プランからルールを修正して、ダイアメータＳｙインターフェースを介してＰＣＲＦに修正されたルールを提供するようにさらに構成される。ＰＣＲＦは、課金システムによって提供された、修正されたルールに基づいて、加入者のためのＰＣＣ判断を行うように構成される。
【００１７】
別の実施形態では、本アーキテクチャは、ＲＡＮについてのトラフィック・データを受信し、ＲＡＮの領域内の輻輳状態を検出し、ＲＡＮの領域内の輻輳状態を示す報告をＰＣＲＦに送信するように構成されたトラフィック・データ機能（ＴＤＦ）を含む。
【００１８】
以下で、他の例示的実施形態を説明する。
【００１９】
ここでは、ほんの一例として、添付の図面を参照して、本発明のいくつかの実施形態を説明する。すべての図面において、同じ参照番号は、同じ要素または同じタイプの要素を表す。
【図面の簡単な説明】
【００２０】
【図１】例示的実施形態における、パケット・コア・ネットワークのポリシーおよび課金制御（ＰＣＣ）アーキテクチャを示す図である。
【図２】例示的実施形態における、サービス・プランからルールを修正する方法を示す流れ図である。
【図３】別の例示的実施形態における、ＰＣＣアーキテクチャを示す図である。
【図４】例示的実施形態における、セッションの確立を示すメッセージ図である。
【図５】例示的実施形態における、ＲＡＮ内の輻輳に対処するためにポリシーおよび／または課金ルールを修正する課金システムを示すメッセージ図である。
【発明を実施するための形態】
【００２１】
図面および以下の説明は、本発明の特定の例示的実施形態を示している。したがって、当業者は、本明細書には明示的に記載または図示されていないが、本発明の原理を具体化し、本発明の範囲内に含まれる、様々な構成を考案するできることが理解されよう。さらに、本明細書に記載の任意の例は、本発明の原理の理解を助けることを意図するものであり、そのような具体的に列挙された例および状態に限定されないものとして解釈されるべきである。結果として、本発明は、以下に記載される特定の実施形態または例に限定されないが、特許請求の範囲、およびそれらの均等物に限定される。
【００２２】
図１は、例示的実施形態における、パケット・コア・ネットワークのポリシーおよび課金制御（ＰＣＣ）アーキテクチャ１００を示している。たとえば、ＰＣＣアーキテクチャ１００は、ロング・ターム・エボリューション／進化型パケット・コア（ＬＴＥ／ＥＰＣ）・ネットワーク、または別のタイプの４Ｇネットワークにおいて使用され得る。ＰＣＣアーキテクチャ１００は、パケット・コア・ネットワーク内のポリシーおよび課金制御（ＰＣＣ）ソリューションをともに提供する、ポリシーおよび課金ルール機能（ＰＣＲＦ）１０２、ならびにポリシーおよび課金施行機能（ＰＣＥＦ）１０４を含む。ＰＣＲＦ１０２は、エンド・ユーザによって要求されるサービスのＰＣＣルールを構築するネットワークのノードまたはエンティティであり、本明細書ではＰＣＣ判断を行うことと呼ばれる。ＰＣＲＦ１０２は、エンド・ユーザのために定義されたポリシーおよび／または課金ルールに基づいてＰＣＣ判断を行う、ポリシー・エンジン（図示せず）を有することができる。本明細書では「ＰＣＲＦ」という用語が使用されているが、ＰＣＲＦ１０２の機能は、パケット・コア・ネットワーク内のポリシーおよび課金制御を実行する任意のネットワーク・エンティティに適用可能である。
【００２３】
ＰＣＥＦ１０４は、エンド・ユーザによって要求されたサービスのＰＣＣルールを施行するノードである。たとえば、ＰＣＥＦ１０４は、サービスのためのベアラ接続を設定し、既存のベアラ接続を修正し、許可されたサービス・データ・フローだけが確立されることを保証し、ＱｏＳ制限を超えないことを保証すること等ができる。一般的に、ＰＣＥＦ１０４は、ＥＰＣネットワーク内のパケット・データ・ネットワーク・ゲートウェイ（Ｐ−ＧＷ）などの、エンド・ユーザとパケット・データ・ネットワークとの間のゲートウェイ（ＧＷ）１０６に実装される。
【００２４】
ＰＣＣアーキテクチャ１００は、ベアラ・バインディングおよびイベント報告機能（ＢＢＥＲＦ）１１２、アプリケーション機能（ＡＦ）１１４、加入者プロファイル・リポジトリ（ＳＰＲ）１１６、ならびにトラフィック・データ機能（ＴＤＦ）１１８をさらに含む。アプリケーション機能（ＡＦ）１１４は、エンド・ユーザによって要求されたサービスを提供する、パケット・データ・ネットワーク（たとえば、インターネット、ＩＭＳ等）内のノードである。ＡＦ１１４は、ダイアメータＲｘインターフェースまたは他の適切なプロトコル・インターフェースを介して、要求されたサービスをＰＣＲＦ１０２に記述する。たとえば、ＡＦ１１４は、要求されたサービスのＩＰアドレス、ポート番号、ビット・レート、遅延感度等を、ＰＣＲＦ１０２に提供することができる。次いで、ＰＣＲＦ１０２は、ＰＣＣ判断を行うときにこの情報を使用することができる。
【００２５】
ＳＰＲ１１６は、エンド・ユーザの加入者プロファイルを記憶する。加入者プロファイルは、ＰＣＣ判断を行うためにＰＣＲＦ１０２によって使用される、ポリシー・ルール（および、可能であれば課金ルール）を含み得る。ポリシー・ルールは、エンド・ユーザがアクセスを許可されるのはどのネットワーク・サービスか、提供される帯域幅レベル、サービスが許可される時間、サービスが許可される長さ等を管理する。本明細書では、ポリシー・ルールおよび課金ルールは、ともにエンド・ユーザ（または、加入者）のサービス・プラン（または、ＰＣＣプラン）と呼ばれる。ＳＰＲ１１６は、ダイアメータＳｐインターフェース、またはＰＣＲＦ１０２とポリシー・ルールを交換するために使用される他の任意のプロトコルを介して、ＰＣＲＦ１０２とインターフェースで接続する。
【００２６】
ＴＤＦ１１８は、アクセス・ネットワーク、および／またはパケット・コア・ネットワークについてのトラフィック・データを記憶する。トラフィック・データは、時間、位置、サービス・フロー、サービス方向等によって変化してよい。ＴＤＦ１１８は、ＰＣＣ判断についてのトラフィック・データ（リアルタイム、または過去の）を送信するために、ダイアメータＳｄインターフェース、または他の何らかの適切なプロトコル・インターフェースを介して、ＰＣＲＦ１０２とインターフェースで接続する。
【００２７】
やはり図１に示されているのは、エンド・ユーザのモバイル・デバイス１３６に接続性を提供する、無線アクセス・ネットワーク（ＲＡＮ）１３２、およびサービング・ゲートウェイ（Ｓ−ＧＷ）１３４である。ＲＡＮ１３２は、無線周波数を使用してモバイル・デバイスと通信する、複数のトランシーバを含む。一般的に、トランシーバは基地局と呼ばれるが、アクセス・ポイント、セル・サイト等とも呼ばれる。ＲＡＮ１３２の各基地局は「セル」を形成する。基地局は、セルが、ＲＡＮ１３２のサービス・エリアを定義するハニカム状の構成を形成できるようにするために、大きな領域にわたって分散され得る。一般的に、各セルは、干渉を避け、各セル内の保証された帯域幅を提供するために、隣接セルとは周波数の異なるセットを使用する。
【００２８】
アーキテクチャ１００は、課金システム１２０も含む。課金システム１２０は、パケット・コア・ネットワークを介して確立されたセッションに課金することができる。たとえば、課金システム１２０は、ＰＣＥＦ１０４などのネットワーク要素から課金要求を受信することができる。課金要求に応じて、課金システムはセッション（またはサービス）を評価して、課金要求を送信したネットワーク要素に課金応答を提供することができる。この実施形態では、課金システム１２０は、オンライン課金システム（ＯＣＳ）、オフライン課金システム（ＯＦＣＳ）、または、オンライン課金とオフライン課金の両方を提供する収束された課金システムを表すことができる。ＯＣＳは、エンド・ユーザによってアクセスされるサービス／セッションについてのオンライン課金を提供する。さらに、ＯＣＳは、ＰＣＲＦ１０２がＰＣＣ判断を行うときに使用することができる、エンド・ユーザについての課金ルールを記憶する。たとえば、課金ルールは、エンド・ユーザはプリペイド加入者であることを定義することができ、また、エンド・ユーザによって要求される異なるサービスについての料金を定義することができる。ＯＦＣＳは、エンド・ユーザによってアクセスされるサービス／セッションについてのオフライン課金を提供する。ＯＦＣＳは、オフライン課金動作を処理するための、課金データ機能（ＣＤＦ）および課金ゲートウェイ機能（ＣＧＦ）を含み得る。
【００２９】
以下の実施形態では、課金システム１２０は、ＲＡＮ１３２内で検出された輻輳状態に対処するために強化される。課金システム１２０は、ＲＡＮ１３２のトラフィック状態に基づいて、エンド・ユーザのサービス・プロファイルにおいて事前に定義されたポリシーおよび／または課金ルールを修正することによって、輻輳状態を処理する。次いで、修正されたルールは、ＰＣＣ判断を行うときにＰＣＲＦ１０２によって使用され得る。
【００３０】
課金システム１２０は、ＲＡＮ１３２内のトラフィック状態についてのデータを受信して維持する、トラフィック・ユニット１２２を含む。トラフィック・ユニット１２２は、ＲＡＮ１３２についてのトラフィック報告を様々なソースから受信することができる。たとえば、トラフィック・ユニット１２２は、ＲＡＮ１３２についてのトラフィック報告を、ダイアメータＳｙインターフェースを介してＰＣＲＦ１０２から受信することができる。また、トラフィック・ユニット１２２は、ＲＡＮ１３２についてのトラフィック報告を、ＴＤＦ１１８または他の要素から受信することができる。
【００３１】
課金システム１２０は、加入者のサービス・プランを記憶する、またはそれにアクセスするルール・コントローラ１２４も含む。サービス・プランは、その加入者のために事前に定義された、ポリシーおよび／または課金ルールを示す。また、ルール・コントローラ１２４は、ＲＡＮ１３２内に存在することが判明した輻輳状態を考慮する、修正されたルールを生成するために、加入者のサービス・プランにおいて見つかった、事前に定義された（ポリシーおよび／または課金）ルールを調整することができる。たとえば、ルール・コントローラ１２４は、加入者のサービス・プランにおいて事前に定義されたＱｏＳから、サービスのＱｏＳをダウングレードすることができる。別の例では、ルール・コントローラ１２４は、加入者のサービス・プランにおいて事前に定義された料金から、サービスの料金を上げることができる。ポリシーおよび／または課金ルールへのこのような修正は、加入者が、輻輳が発生しているＲＡＮ１３２の領域を通じてサービスにアクセスすることを思いとどまらせることができる。これによって、ＲＡＮ１３２内の輻輳の深刻さが軽減するか、将来の輻輳が回避される。課金システム１２０のより詳細な動作は、図２に示されている。
【００３２】
図２は、例示的実施形態における、サービス・プランからルールを修正する方法２００を示す流れ図である。方法２００のステップを、図１のＰＣＣアーキテクチャ１００を参照して説明するが、本明細書に記載の方法は、他のノードまたはシステムでも実行され得る。本明細書に記載の流れ図のステップは包括的なものではなく、図示されていない他のステップを含み得る。ステップは、別の順序でも実行され得る。
【００３３】
ステップ２０２で、課金システム１２０のトラフィック・ユニット１２２が、ＲＡＮ１３２についての１つまたは複数のトラフィック報告を受信する。トラフィック報告は、ＲＡＮ１３２内のトラフィックに関する任意のデータまたは情報（たとえば、量またはタイプ）を備える。トラフィック・ユニット１２２は、トラフィック報告を定期的に受信してもよく、ＰＣＣアーキテクチャ１００に示される要素にトラフィック報告を要求してもよい。次いで、トラフィック・ユニット１２２は、ＲＡＮ１３２についてのトラフィック報告を記憶して解析する。この実施形態についての１つの仮定は、ＲＡＮ１３２のある領域内（すなわち、カバレージ・エリアの部分内）で輻輳状態が識別されることである。輻輳状態は、ＲＡＮ１３２の領域内で過剰なトラフィックが識別される状態を表すことができる。たとえば、トラフィック・ユニット１２２は、ＲＡＮ１３２内の１つまたは複数の基地局が、期間内にしきい値を超えるいくつかのサービス要求を受信していることを検出するために、トラフィック報告を解析することができる。また、輻輳状態は、ＲＡＮ１３２の領域内で中程度または低いトラフィックが識別される状態を表すことができる。たとえば、トラフィック・ユニット１２２は、ＲＡＮ１３２内の１つまたは複数の基地局が少数の（たとえば、基地局のしきい値セットをかなり下回る）サービス要求を処理していることを検出するために、トラフィック報告を解析することができる。
【００３４】
トラフィック報告自体は、ＲＡＮ１３２内の領域内の輻輳状態を表すことができる。輻輳状態は、セルＩＤ、輻輳レベル、輻輳の時間等によって示すことができる。
【００３５】
ＲＡＮ１３２内の輻輳状態が識別されると、ステップ２０４で、ルール・コントローラ１２４が、ＲＡＮ１３２の領域内に位置する加入者を識別する。輻輳状態は、特定のセルまたはセルのグループなどの、ＲＡＮ１３２内の特定の位置に関連する。ルール・コントローラ１２４は、輻輳状態によって影響を受けた領域内に位置しているものとして、加入者を識別することができる。本明細書で「加入者」という用語が使用される場合、その用語は、個々のエンド・ユーザ、エンド・ユーザのモバイル・デバイス（たとえば、ＵＥ）、および／または個々のエンド・ユーザとモバイル・デバイスの組合せに適用することができる。
【００３６】
ステップ２０６で、ルール・コントローラ１２４は、ＲＡＮ１３２の領域内に位置する加入者のサービス・プランを識別する。上述のように、サービス・プランは、サービスを提供するために加入者について事前に定義された（ポリシーおよび／または課金）ルールを含む。しかしながら、ＲＡＮ１３２には輻輳状態が発生しているので、サービス・プランにおいて事前に定義されたルールは、加入者によって要求されたサービスに効率的に作用しない場合がある。したがって、ステップ２０８で、ルール・コントローラ１２４は、輻輳状態に応じて、修正されたルールを生成する。修正されたルールは、ＲＡＮ１３２内で見つかった輻輳状態に対処するために、加入者のサービス・プランにおいて事前に定義されたルールとは異なるか、逸脱する。たとえば、ルールへの修正によって、輻輳が発生しているＲＡＮ１３２の領域内に加入者が位置している間、その加入者による利用を思いとどまらせることができる。ルール・コントローラ１２４は、加入者による利用を思いとどまらせるために、１つまたは複数のサービスについてサービス・プランにおいて事前に定義されたサービス品質（ＱｏＳ）をダウングレードしてもよく、１つまたは複数のサービスについてサービス・プランにおいて事前に定義された料金を上げてもよく、あるいはサービス・プランから（ポリシーおよび／または課金）ルールを修正してもよい。ルールへの修正によって、加入者がＲＡＮ１３２のこの領域内に位置している間、その加入者による利用を奨励することができる。ルール・コントローラ１２４は、１つまたは複数のサービスについてサービス・プランにおいて事前に定義されたＱｏＳを上げてもよく、１つまたは複数のサービスについてサービス・プランにおいて事前に定義された料金を下げてもよい。
【００３７】
ステップ２１０で、ルール・コントローラ１２４は、修正されたルールをＰＣＲＦ１０２に送信する。次いで、ＰＣＲＦ１０２は、加入者によって要求されたサービスについてＰＣＣ判断を行うときに、修正されたルールを使用することができる。この実施形態では、加入者は、ルール・コントローラ１２４が修正されたルールをＰＣＲＦ１０２に提供するときに、まだサービスを要求していない場合がある。別の実施形態では、加入者がサービスを受信できるようにするためにセッションが確立されてよく、ルール・コントローラ１２４が、セッションの途中で新しいＰＣＣ判断のための修正されたルールを提供してよい。いかなる場合でも、ＰＣＲＦ１０２は、加入者のサービス・プランにおいて定義されたルールの代わりに、課金システム１２０によって提供された、修正されたルールに基づいてＰＣＣ判断を行うことができる。次いで、方法２００のステップ２０４−２１０は、ＲＡＮ１３２のこの領域内に位置する他の加入者のために繰り返される。
【００３８】
課金システム１２０は、パケット・コア・ネットワークによってサービスがどのように提供されるかを一時的に変更するために、加入者のための修正されたルールを提供する。課金システム１２０は、実際には、加入者のサービス・プランにおいて事前に定義されたルールを変更しないが、ＰＣＣ判断のためにＰＣＲＦ１０２に送信されたルールを変更する。言い換えれば、課金システム１２０は、修正されたルールがＰＣＣ判断のために使用されるようにするために、サービス・プランからの事前に定義されたルールの代わりに、修正されたルールをＰＣＲＦ１０２に送信する。ＲＡＮ１３２内の輻輳状態が終了した後、サービス・プランからの事前に定義されたルールをＰＣＣ判断のために再び使用することができる。
【００３９】
ルール・コントローラ１２４は、修正されたルールが使用される方法への制限を指定することができる。たとえば、修正されたルールは、２時間などの時間にわたって有効でよい。修正されたルールは、加入者が特定の位置にいる間は有効でよい。修正されたルールは、特定のサービス／媒体タイプについて有効でよい。ルール・コントローラ１２４は、修正されたルールへの制限をＰＣＲＦ１０２に示すことができる。
【００４０】
課金システム１２０が加入者のための修正されたルールを生成するとき、修正されたルールを加入者に通知することが有利である場合がある。したがって、ルール・コントローラ１２４は、加入者のモバイル・デバイス１３６に、修正されたルールを記述する通知を送信することができる。たとえば、修正されたルールが、ダウングレードされたＱｏＳを含む場合、通知は、ＱｏＳがダウングレードされたこと、ＱｏＳの量がダウングレードされたこと等を示すことができる。修正されたルールが上がった料金を含む場合、通知は、料金がどれだけ上がったか、および／または新たに上がった料金を示すことができる。通知は、モバイル・デバイス１３６にテキスト・メッセージ（たとえば、ＳＭＳまたはＭＭＳ）、電子メール等として送信され得る。
【００４１】
課金システム１２０がＲＡＮ１３２についてのトラフィック報告を受信できるようにするために、以下の実施形態では、ＰＣＲＦ１０２と課金システム１２０との間のインターフェースを強化することができる。図示された図面では、ＰＣＲＦ１０２と課金システム１２０との間のインターフェースはダイアメータＳｙインターフェースである。トラフィック報告を課金システム１２０に提供するために、ダイアメータＳｙインターフェースについての新しい属性値ペア（ＡＶＰ）が定義される。新しいＡＶＰのうちの１つが、ＲＡＮ１３２内の輻輳状態が発生している位置を示すデータについて定義される。たとえば、輻輳状態が発生している位置を示すために、セル識別子（ＩＤ）が使用され得る。したがって、セルＩＤについて新しいＡＶＰを定義することができ、「Ｃｏｎｇｅｓｔｉｏｎ−Ｃｅｌｌ−ＩＤ」、または類似する何かと名付けることができる。
【００４２】
新しいＡＶＰのうちの別の１つが、ＲＡＮ１３２内の輻輳のレベルを示すデータについて定義される。輻輳レベルは、０〜１０、０〜１００などの範囲の整数値でよい。新しいＡＶＰは、「輻輳−レベル」、または類似する何かと名付けることができる。
【００４３】
新しいＡＶＰのうちの別の１つが、ＲＡＮ１３２内に輻輳状態が発生している時間を示すデータについて定義される。このＡＶＰは、輻輳状態が最初に識別された時の開始タイムスタンプを含むことができ、輻輳状態が続くと予測される長さ（たとえば、期間またはタイムスタンプ）を示すこともできる。新しいＡＶＰは、「Ｃｏｎｇｅｓｔｉｏｎ−Ｔｉｍｅｓ」、または類似する何かと名付けることができる。
【００４４】
ＲＡＮ１３２内に検出された輻輳状態のために、加入者のためのルールを修正することによって、課金システム１２０は、ＲＡＮ１３２内の特定の位置におけるモバイル・デバイスの利用を思いとどまらせる、または奨励することができる。たとえば、セルが鉄道駅ターミナル、バスターミナル、または類似する位置の近くに位置すると仮定する。平日の午後５時頃、職場から帰宅する人々の数のために、このセルは深刻に輻輳する場合がある。この問題に対処するために、課金システム１２０は、エンド・ユーザがこのセル内に位置している間に、ポリシーおよび／または課金ルールを調整することができる。課金システム１２０は、この基地局の範囲内のエンド・ユーザのＱｏＳをダウングレードする、料金を上げる、あるいはポリシーおよび／または課金ルールを調整することができる。ルールへの修正によって、エンド・ユーザが、この基地局を通じてモバイル・ネットワークにアクセスすることを思いとどまらせ、基地局での輻輳問題の軽減に役立つ。
【００４５】
同時に、エンド・ユーザが、十分に活用されていないセルによってサービスされている位置に移動すると、課金システム１２０は、より輻輳しやすいセルの代わりにこれらのセルを用いることについて、これらのエンド・ユーザに報いることができる。課金システム１２０は、エンド・ユーザが、輻輳していないＲＡＮ１３２の領域内に位置している場合、ＱｏＳをアップグレードするために、料金を下げるために、あるいはポリシーおよび／または課金ルールを調整するために、ルールを修正することができる。これによって、エンド・ユーザが、電話をかける、ウェブ・サーフィンをする、電子メールを送る等を行う前に、ＲＡＮ１３２の輻輳していない領域に入るまで待つことを奨励することができる。したがって、課金システム１２０は、加入者のポリシーおよび／または課金ルールを修正することによって、ＲＡＮ１３２内のトラフィックを形作ることができる。
【００４６】
実施例
図３〜図５は、課金システム内のポリシーおよび／または課金ルールを修正することによって、ＲＡＮ内の輻輳を処理する例を示している。図３は、例示的実施形態における、別のＰＣＣアーキテクチャ３００を示している。ＰＣＣアーキテクチャ３００は、アーキテクチャ３００内の課金システム３２０が収束された課金システムを表すこと以外は、図１と類似している。課金システム３２０は、それがオンライン課金システム（ＯＣＳ）とオフライン課金システム（ＯＦＣＳ）の両方を含むという点で収束されている。課金システム３２０は、課金および制御ルールを事前に定義する、加入者のサービス・プランについての情報（たとえば、料金プラン、使用量ベースの割引、バケット／ボーナス・プラン）を維持する。
【００４７】
課金システム３２０は、トラフィック・ユニット３２２、ルール・コントローラ３２４、オンライン課金機能（ＯＣＦ）３２５、および課金データ機能（ＣＤＦ）３２６を含む。ＯＣＦ３２５は、ＰＣＥＦ１０４から受信したダイアメータ・クレジット要求に基づいてオンライン課金動作を実行する。ＣＤＦ３２６は、ＰＣＥＦ１０４から受信したダイアメータ・アカウンティング要求に基づいて課金データ・レコード（ＣＤＲ）を生成することによって、オフライン課金動作を実行する。課金システム３２０は、アカウント・バランス管理機能（ＡＢＭＦ）およびレーティング機能（ＲＦ）などの、オンライン課金システムまたはオフライン課金システムの他の要素を含み得る。
【００４８】
ＲＡＮ１３２はネットワークのアクセス部分を表す。この例では、ＲＡＮ１３２は、トラフィック状態をＴＤＦ１１８に報告することができるプローブ（図示せず）を含む。プローブからのトラフィック報告は、輻輳しているＲＡＮ１３２の領域を示すセルＩＤ、輻輳の時間を示すタイムスタンプ、および、可能であれば輻輳のレベルを含む。ＴＤＦ１１８がＲＡＮプローブからトラフィック報告を受信すると、ＴＤＦ１１８は報告を処理して、輻輳状態／レベル、および時間／セルＩＤを、Ｓｄリファレンス・ポイントを通じてＰＣＲＦ１０２に入力する。
【００４９】
サービス・データ・フローがＴＤＦ１１８を通ると、ＴＤＦ１１８は、トラフィックを検出するために、内蔵ディープ・パケット・インスペクション（ＤＰＩ）（ストリーミング、Ｐ２Ｐ、ＶｏＩＰ、メッセージング、ブラウジング、ダウンロード、およびマルチメディアなど）、およびシャロー・インスペクション（Ｓｈａｌｌｏｗ  Ｉｎｓｐｅｃｔｉｏｎ）（ポート、宛先、プロトコル）機能を任意で有することができる。次いで、ＴＤＦ１１８は、輻輳状態／レベルを検出して、それらをＰＣＲＦ１０２に報告することができる。
【００５０】
次いで、ＰＣＲＦ１０２は、ダイアメータＳｙインターフェースを介して、トラフィック報告を課金システム３２０に提供することができる。課金システム３２０が、ＰＣＲＦ１０２からトラフィック報告を受信すると、課金システム３２０は、トラフィック・データを内部トラフィック・データベースに記憶して維持する。データベースは、輻輳しているセルＩＤ、タイムスタンプ、輻輳している領域内に位置している加入者等についての情報を記憶する。
【００５１】
この例では、モバイル・デバイス１３６のエンド・ユーザが、サービス・プロバイダとのサービス・プランに加入すると仮定する。サービス・プランの一部として、エンド・ユーザのためのポリシー・ルールおよび課金ルールが事前に定義される。一般的に、ポリシー・ルールおよび課金ルールは、エンド・ユーザのために開始されるセッションについてのＰＣＣ判断を行うときにＰＣＲＦ１０２によって使用される。以下で提供される例では、課金システム３２０は、ＲＡＮ１３２内に輻輳が発生している場合、ＰＣＣ判断のためにＰＣＲＦ１０２に送信されるポリシーおよび／または課金ルールを修正する。
【００５２】
図４は、例示的実施形態における、セッションの確立を示すメッセージ図である。図４において開始するために、モバイル・デバイス１３６は、ＩＰ−ＣＡＮセッションを確立するために、ＲＡＮ１３２およびＳ−ＧＷ１３４を通じて、Ｐ−ＧＷ３０６（ＰＣＥＦ１０４を含む）へのセッション要求を開始する。次いで、ＰＣＥＦ１０４が、セッション要求をＴＤＦ１１８に転送する。セッション要求に応じて、ＴＤＦ１１８が、ＰＣＲＦ１０２にダイアメータＳｄセッション要求を送信する。ＰＣＲＦ１０２が、ダイアメータＳｄセッション応答でＴＤＦ１１８に応答して、ＴＤＦ１１８が、セッションのために確立されたサービス・データ・フロー内のトラフィック監視および制御のための検出基準を設定する。
【００５３】
次いで、ＰＣＥＦ１０４が、ＩＰ−ＣＡＮセッション確立を開始して、許可されたサービスおよびＰＣＣルール情報の承認を要求するために、ダイアメータＧｘ  Ｃｒｅｄｉｔ−Ｃｏｎｔｒｏｌ−Ｒｅｑｕｅｓｔ（ＣＣＲ）［ｉｎｉｔｉａｌ］をＰＣＲＦ１０２に送信する。ＰＣＲＦ１０２がＧｘ  ＣＣＲ［ｉｎｉｔｉａｌ］メッセージを受信すると、ＰＣＲＦ１０２が、モバイル・デバイス１３６のエンド・ユーザについての加入者プロファイルを要求する、ダイアメータＳｈ  Ｕｓｅｒ−Ｄａｔａ−Ｒｅｑｕｅｓｔ（ＵＤＲ）をＳＰＲ１１６に送信する。ＳＰＲ１１６は、エンド・ユーザについての加入者プロファイルを検索して、加入者プロファイルを含むダイアメータＳｈ  Ｕｓｅｒ−Ｄａｔａ−Ａｎｓｗｅｒ（ＵＤＡ）でＰＣＲＦ１０２に応答する。
【００５４】
次いで、ＰＣＲＦ１０２が、ダイアメータＳｙ  Ｓｐｅｎｄｉｎｇ−Ｌｉｍｉｔ−Ｒｅｑｕｅｓｔ（ＳＬＲ）を課金システム３２０に送信することによって、課金システム３２０に情報を問い合わせる。ＳＬＲが、サービス・プロファイルにおいてエンド・ユーザまたはサービス・プロバイダによって事前に定義された、加入者アカウンティング・データおよび課金ポリシー・データを要求する。課金システム３２０は、セッションのレーティング、制御ルール、ゲーティング制御、および同等物等のうちの１つまたは複数を示す、ダイアメータＳｙ  Ｓｐｅｎｄｉｎｇ−Ｌｉｍｉｔ−Ａｎｓｗｅｒ（ＳＬＡ）でＰＣＲＦ１０２に返答する。次いで、ＰＣＲＦ１０２が、エンド・ユーザについてのポリシーおよび課金ルールに基づいて、ＰＣＣ判断を行う。言い換えれば、課金システム３２０によって提供された情報に基づいて、ＰＣＲＦ１０２がセッションについてのＰＣＣルールを生成する。次いで、施行のために、ＰＣＲＦ１０２が、ＰＣＣルールとともに、およびＩＰ−ＣＡＮセッションの承認とともに、ダイアメータＧｘ  Ｃｒｅｄｉｔ−Ｃｏｎｔｒｏｌ−Ａｎｓｗｅｒ（ＣＣＡ）［ｉｎｉｔｉａｌ］をＰＣＥＦ１０２に送信することによって、ＰＣＣルールをＰＣＥＦ１０４に提供する。ＰＣＥＦ１０４は、ＰＣＲＦ１０２からのＰＣＣルールを施行する。次いで、ＩＰ−ＣＡＮセッションのために、サービス・データ・フローが、パケット・データ・ネットワーク３４０に向かって確立され得る。図４には示されていないが、ＰＣＥＦ１０４が、サービス・データ・フローに課金するために、ダイアメータＧｙまたはＧｚ課金要求を課金システム３２０に向かって送信する。課金システム３２０がセッションへの課金を開始して、その結果ＰＣＥＦ１０４に応答する。
【００５５】
図５は、例示的実施形態における、ＲＡＮ１３２内の輻輳に対処するためにポリシーおよび／または課金ルールを修正する課金システム３２０を示すメッセージ図である。このメッセージ図は、ＴＤＦ１１８が、セッションの間にＲＡＮ１３２内の輻輳を検出するシナリオを示している。課金システム３２０は、ＲＡＮ１３２内の輻輳状態に応じて、加入者の課金ポリシーを動的に変更することができる。まず、ＲＡＮプローブが、ＲＡＮ１３２内の１つまたは複数の輻輳しているセルを検出する。次いで、ＲＡＮプローブが、輻輳しているセルのセルＩＤを示すトラフィック報告を生成し、トラフィック報告をＴＤＦ１１８に送信する。ＴＤＦ１１８は、サービス・データ・フローの開始の間に設定されたトラフィック・ゲーティング制御を有する。したがって、ＴＤＦ１１８が、アプリケーション変更またはネットワーク・トラフィック変更、およびこれらの変更がポリシー・ルールにおいて定義されたしきい値をヒットしたことを検出する。したがって、ＴＤＦ１１８が、変更を報告するダイアメータＳｄ  ＣＣＲ［ｕｐｄａｔｅ］をＰＣＲＦ１０２に送信する。ＰＣＲＦ１０２が、ダイアメータＳｄ  ＣＣＡ［ｕｐｄａｔｅ］でＴＤＦ１１８に返答する。
【００５６】
ＰＣＲＦ１０２が、ＲＡＮトラフィック・データ（たとえば、位置、時間、輻輳レベル）をキャッシュする。また、ＰＣＲＦ１０２は、ＲＡＮ１３２の影響を受けた領域内の加入者を確認するために、ＳＰＲ１１６とインターフェースして、ローカル・データベースに加入者ＩＤを記憶することができる（これらのステップは、図５には示されていない）。この例では、モバイル・デバイス１３６のサービス・データ・フローが、輻輳しているセル内に位置しているという理由で、ＲＡＮ１３２のこの領域内で検出された輻輳によって影響を受ける。
【００５７】
ＰＣＲＦ１０２が、ダイアメータＳｙ  ＳＬＲ［ｕｐｄａｔｅ］を、ＲＡＮ１３２のトラフィック報告とともに課金システム３２０に送信する。トラフィック報告は、輻輳しているセルによってサービスされているモバイル・デバイスの位置、時間、輻輳レベル、および可能であれば識別子などの輻輳状態の記述を含む。Ｓｙ  ＳＬＲ［ｕｐｄａｔｅ］の一例は、以下の通りでよい。
＜ＳＬ−Ｒｅｑｕｅｓｔ＞：：＝＜Ｄｉａｍｅｔｅｒ  Ｈｅａｄｅｒ：  ｘｘｘ，  ＲＥＱ，  ＰＸＹ＞
＜Ｓｅｓｓｉｏｎ−Ｉｄ＞
｛Ａｕｔｈ−Ａｐｐｌｉｃａｔｉｏｎ−Ｉｄ｝
｛Ｏｒｉｇｉｎ−Ｈｏｓｔ｝
｛Ｏｒｉｇｉｎ−Ｒｅａｌｍ｝
｛Ｄｅｓｔｉｎａｔｉｏｎ−Ｒｅａｌｍ｝
｛Ｄｅｓｔｉｎａｔｉｏｎ−Ｈｏｓｔ｝
｛Ｒｅ−Ａｕｔｈ−Ｒｅｑｕｅｓｔ−Ｔｙｐｅ｝
［Ｕｓｅｒ−Ｎａｍｅ］
［Ｓｕｐｐｏｒｔｅｄ−Ｆｅａｔｕｒｅｓ］
［Ｓｕｂｓｃｒｉｐｔｉｏｎ−Ｉｄ］
［Ｏｒｉｇｉｎ−Ｓｔａｔｅ−Ｉｄ］
［Ｅｖｅｎｔ−Ｒｅｐｏｒｔ−Ｉｎｄｉｃａｔｉｏｎ］
［Ｎｅｔｗｏｒｋ−Ｒｅｑｕｅｓｔ−Ｓｕｐｐｏｒｔ］
［Ｐａｃｋｅｔ−Ｆｉｌｔｅｒ−Ｉｎｆｏｒｍａｔｉｏｎ］
［Ｐａｃｋｅｔ−Ｆｉｌｔｅｒ−Ｏｐｅｒａｔｉｏｎ］
［Ｂｅａｒｅｒ−Ｉｄｅｎｔｉｆｉｅｒ］
［Ｂｅａｒｅｒ−Ｏｐｅｒａｔｉｏｎ］
［Ｆｒａｍｅｄ−ＩＰ−Ａｄｄｒｅｓｓ］
［Ｆｒａｍｅｄ−ＩＰｖ６−Ｐｒｅｆｉｘ］
［ＩＰ−ＣＡＮ−Ｔｙｐｅ］
［ＲＡＴ−Ｔｙｐｅ］
［Ｔｅｒｍｉｎａｔｉｏｎ−Ｃａｕｓｅ］
［Ｕｓｅｒ−Ｅｑｕｉｐｍｅｎｔ−Ｉｎｆｏ］
［３ＧＰＰ−ＳＧＳＮ−ＭＣＣ−ＭＮＣ］
［３ＧＰＰ−ＳＧＳＮ−Ａｄｄｒｅｓｓ］
［３ＧＰＰ−ＳＧＳＮ−ＩＰｖ６−Ａｄｄｒｅｓｓ］
［ＲＡＩ］
［３ＧＰＰ−Ｕｓｅｒ−Ｌｏｃａｔｉｏｎ−Ｉｎｆｏ］
［３ＧＰＰ−ＭＳ−ＴｉｍｅＺｏｎｅ］
［Ｃａｌｌｅｄ−Ｓｔａｔｉｏｎ−ＩＤ］
［Ｂｅａｒｅｒ−Ｕｓａｇｅ］
［Ｅｖｅｎｔ−Ｔｒｉｇｇｅｒ］
［Ｃｏｎｇｅｓｔｉｏｎ−Ｃｅｌｌ−ＩＤｓ］
［Ｃｏｎｇｅｓｔｉｏｎ−Ｌｅｖｅｌ］
［Ｃｏｎｇｅｓｔｉｏｎ−Ｔｉｍｅｓ］
［Ｅｖｅｎｔ−Ｔｉｍｅｓｔａｍｐ］
［Ｓｅｒｖｉｃｅ−Ｉｎｆｏｒｍａｔｉｏｎ］
［Ｐｒｏｘｙ−Ｉｎｆｏ］
［Ｒｏｕｔｅ−Ｒｅｃｏｒｄ］
［ＡＶＰ］
【００５８】
ダイアメータＳｙインターフェースを介して課金システム３２０にトラフィック報告を提供するために、Ｓｙインターフェース内で新しいＡＶＰが定義される（上記に太字で示されている）。ＲＡＮ１３２内の輻輳状態の位置を示すデータのために、第１の新しいＡＶＰが定義される。第１の新しいＡＶＰは「Ｃｏｎｇｅｓｔｉｏｎ−Ｃｅｌｌ−ＩＤ」と名付けられ、輻輳しているセルの１つまたは複数のセルＩＤを示すためのデータ・タイプを有する。ＲＡＮ１３２内の輻輳のレベルを示すデータのために、第２の新しいＡＶＰが定義される。第２の新しいＡＶＰは「Ｃｏｎｇｅｓｔｉｏｎ−Ｌｅｖｅｌ」と名付けられ、整数の範囲などの輻輳のレベルを示すためのデータ・タイプを有する。ＲＡＮ１３２内に輻輳状態が存在する時間を示すデータのために、第３の新しいＡＶＰが定義される。第３の新しいＡＶＰは「Ｃｏｎｇｅｓｔｉｏｎ−ｔｉｍｅｓ」と名付けられ、輻輳状態の開始時間、輻輳状態の終了時間、輻輳状態の期間等を示すためのデータ・タイプを有する。
【００５９】
ダイアメータＳｙ  ＳＬＲに応じて、課金システム３２０が、トラフィック・ユニット３２２に記憶されたＲＡＮ１３２のトラフィック・データを更新する。次いで、ルール・コントローラ３２４が、ＲＡＮ１３２についてのトラフィック報告に基づいて所望される、課金ルールおよび課金レート変更があるかどうかを確認するために、ルール・エンジンを実行する。変更がトラフィック報告に基づいて所望される場合、次いで、ルール・コントローラ３２４が、ＲＡＮ１３２内の輻輳状態によって影響を受けるエンド・ユーザを識別する。また、ルール・コントローラ３２４は、輻輳状態によって影響を受けるエンド・ユーザのためのサービス・プランを識別する。次いで、ルール・コントローラ３２４は、ＲＡＮ１３２内で見つかった輻輳状態に応じて、エンド・ユーザのサービス・プランにおいて事前に定義されたルールから逸脱する、修正されたルールを生成する。次いで、ルール・コントローラ１２４は、ダイアメータＳｙ  ＳＬＡをＰＣＲＦ１０２に送信することによって、修正されたルールをＰＣＲＦ１０２に提供する。以下は、修正されたルールを示す、ダイアメータＳｙ  ＳＬＡの例を示している。
＜ＳＬ−Ａｎｓｗｅｒ＞：：＝＜Ｄｉａｍｅｔｅｒ  Ｈｅａｄｅｒ：  ｘｘｘ，  ＲＥＱ，  ＰＸＹ＞
＜Ｓｅｓｓｉｏｎ−Ｉｄ＞
｛Ａｕｔｈ−Ａｐｐｌｉｃａｔｉｏｎ−Ｉｄ｝
｛Ｏｒｉｇｉｎ−Ｈｏｓｔ｝
｛Ｏｒｉｇｉｎ−Ｒｅａｌｍ｝
｛Ｄｅｓｔｉｎａｔｉｏｎ−Ｒｅａｌｍ｝
｛Ｄｅｓｔｉｎａｔｉｏｎ−Ｈｏｓｔ｝
｛Ｒｅ−Ａｕｔｈ−Ｒｅｑｕｅｓｔ−Ｔｙｐｅ｝
［Ｓｕｐｐｏｒｔｅｄ−Ｆｅａｔｕｒｅｓ］
［Ｓｅｓｓｉｏｎ−Ｒｅｌｅａｓｅ−Ｃａｕｓｅ］
［Ｏｒｉｇｉｎ−Ｓｔａｔｅ−Ｉｄ］
［Ｅｖｅｎｔ−Ｔｒｉｇｇｅｒ］
［Ｅｖｅｎｔ−Ｒｅｐｏｒｔ−Ｉｎｄｉｃａｔｉｏｎ］
［ＱｏＳ−Ｒｕｌｅ−Ｒｅｍｏｖｅ］
［ＱｏＳ−Ｒｕｌｅ−Ｉｎｓｔａｌｌ］
［Ｃｈａｒｇｉｎｇ−Ｒｕｌｅ−Ｒｅｍｏｖｅ］
［Ｃｈａｒｇｉｎｇ−Ｒｕｌｅ−Ｉｎｓｔａｌｌ］
［Ｄｅｆａｕｌｔ−ＥＰＳ−Ｂｅａｒｅｒ−ＱｏＳ］
［ＱｏＳ−Ｉｎｆｏｒｍａｔｉｏｎ］
［Ｒｅｖａｌｉｄａｔｉｏｎ−Ｔｉｍｅ］
［Ｐｒｏｘｙ−Ｉｎｆｏ］
［Ｒｏｕｔｅ−Ｒｅｃｏｒｄ］
［ＡＶＰ］
【００６０】
ダイアメータＳｙ  ＳＬＡに応じて、ＰＣＲＦ１０２が、加入者のサービス・プランにおいて定義されたルールの代わりに、課金システム３２０によって提供された、修正されたルールに基づいて、新しいＰＣＣ判断を行う。次いで、ＰＣＲＦ１０２が、ダイアメータＲｅ−Ａｕｔｈｏｒｉｚａｔｉｏｎ  Ｒｅｑｕｅｓｔ（ＲＡＲ）をＰＣＥＦ１０２に送信する。ＰＣＥＦ１０４が、Ｒｅ−Ａｕｔｈｏｒｉｚａｔｉｏｎ  Ａｎｓｗｅｒ（ＲＡＡ）でＰＣＲＦ１０２に返答する。次いで、ＰＣＥＦ１０４が、セッションについての新しいＰＣＣルールを要求するために、ダイアメータＧｘ  ＣＣＲ［ｕｐｄａｔｅ］をＰＣＲＦ１０２に送信する。ＰＣＲＦ１０２が、更新されたＰＣＣルールを含むダイアメータ  ＣＣＡ［ｕｐｄａｔｅ］でＰＣＥＦ１０４に返答する。次いで、ＰＣＥＦ１０４が更新されたＰＣＣルールを施行して、更新されたＰＣＣルールに基づいてダイアメータＧｙまたはＧｚ更新要求を課金システム３２０に送信する。課金システム３２０は、新しい課金情報を使用して、更新されたＩＰ−ＣＡＮセッションのレートを決定することができる。ＰＤＮ３４０へのサービス・データ接続は、新しいポリシーおよび他のパラメータで更新される。
【００６１】
課金システム３２０はエンド・ユーザのルールを修正することができるので、課金システム３２０は、輻輳しているセルによってサービスされている間は、エンド・ユーザが現在のセッションを継続すること、または、新しいセッションを開始することを思いとどまらせることができる。類似の修正が、輻輳したセルの領域内にいる他のエンド・ユーザに発生する。したがって、課金システム３２０は、基本的に、これらの輻輳したセルから離れてトラフィックを形作り、十分に活用されていない他のセルに向かうトラフィックへの分散を助けることができる。たとえば、エンド・ユーザが混雑している鉄道ターミナルに位置している間に電話をかける代わりに、エンド・ユーザは、周囲のセルが十分に活用されておらず、輻輳がない、あまり密集していない領域に自分が移動するまで待つことができる。
【００６２】
図面に示される、または本明細書に記載の様々な要素のうちのいずれも、ハードウェア、ソフトウェア、ファームウェア、またはこれらの何らかの組合せとして実装され得る。たとえば、要素は専用ハードウェアとして実装され得る。専用ハードウェア要素は、「プロセッサ」、「コントローラ」、または何らかの類似の用語と呼ばれ得る。プロセッサによって提供される場合、機能は単一の専用プロセッサによって、単一の共有プロセッサによって、またはそのうちのいくつかが共有され得る複数の個々のプロセッサによって提供され得る。さらに、「プロセッサ」または「コントローラ」という用語の明示的な使用は、ソフトウェアを実行することができるハードウェアだけを指すものと解釈されるべきではなく、これに限定されないが、デジタル信号プロセッサ（ＤＳＰ）・ハードウェア、ネットワーク・プロセッサ、特定用途向け集積回路（ＡＳＩＣ）または他の回路、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、ソフトウェアを記憶するための読出し専用メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、不揮発性記憶装置、ロジック、あるいは他の何らかの物理的ハードウェア・コンポーネントまたはモジュールを暗示的に含んでよい。
【００６３】
また、要素は、要素の機能を実行するために、プロセッサまたはコンピュータによって実行可能な命令として実装され得る。命令のいくつかの例には、ソフトウェア、プログラム・コード、およびファームウェアがある。命令は、プロセッサに、要素の機能を実行するよう指示するために、プロセッサによって実行されると動作可能である。命令は、プロセッサによって読取り可能な記憶装置に記憶され得る。記憶装置のいくつかの例には、デジタルまたはソリッド・ステート・メモリ、磁気ディスクおよび磁気テープなどの磁気記憶媒体、ハード・ドライブ、または光学的に読取り可能なデジタル・データ記憶媒体がある。
【００６４】
本明細書では特定の実施形態を説明したが、本発明の範囲はそれらの特定の実施形態に限定されない。本発明の範囲は、以下の特許請求の範囲、およびそれらの任意の均等物によって定義される。
【図１】
2015537408.tif 000003
【図２】
2015537408.tif 000004
【図３】
2015537408.tif 000005
【図４】
2015537408.tif 000006
【図５】
2015537408.tif 000007
【国際調査報告】
2015537408.tif 000008
2015537408.tif 000009
2015537408.tif 000010