本発明は課金方法に関し、より具体的には、パケットデータサービスの課金制御方法に関する。
パケットデータサービスの広範な利用に伴い、パケットデータサービスを正確かつ合理的に課金する方法は運営者にとって共通の関心事となっている。
図1は、パケットデータプロトコルコンテキスト(PDPコンテキスト)の起動、データ送信及び停止を示すフローチャートである。図1に示されるように、汎用パケット無線サービス(GPRS)においては、PDPコンテキストの起動、データ送信及び停止の実行手順は下記のステップを含む。
ステップ101:ユーザ装置(UE)はサービス側GPRSサポートノード(SGSN)へPDPコンテキスト起動要求を送信し、このPDPコンテキスト起動要求は、ネットワーク層サービスアクセス点識別子(NSAPI)、PDPタイプ、アクセス点名(APN)、複数のサービス品質(QoS)パラメータ、トランザクション識別子(TI)等の情報を搬送する。但し、NSAPIは、PDPコンテキストを識別するために、SGSNとゲートウェイGPRSサポートノード(GGSN)との間のトンネル識別子(TEID)のコンポーネントとして使用される。PDPタイプには、ピア−ピアプロトコル(PPP)タイプ、インターネットプロトコル(IP)タイプ、その他が含まれる。APNは、SGSNに対してUEにより供給されることが可能であり、これによりSGSNは対応するGGSNをアドレス指定し、GGSNはUEによってアクセスされるべき外部ネットワークを決定する。もしくは、UEはSGSNに対してAPNを供給しないことを選択する可能性もあり、この場合、SGSNは、UEの加入者情報に従ってデフォルトAPNを選択する。QoSパラメータは、UEにより指定されるパケットデータサービスによって要求される品質を表す。TIは、UEがPDPコンテキストを識別するために使用される。
ステップ102:SGSNは、PDPコンテキスト起動要求を受信後、セキュリティチェック及びUEによる暗号化を実行する。このステップは任意選択である。
ステップ103:SGSNは、APNに従ってGGSNアドレス情報を分析し、SGSNがAPNに従ってGGSNアドレス情報を発見すれば、PDPコンテキストに対してTEIDが生成される。TEIDは、SGSNとGGSNとの間のPDPコンテキストを一意に識別するために国際移動加入者識別番号(IMSI)とNSAPIとの組合せであってもよい。次に、SGSNはGGSNへPDPコンテキスト生成要求を送信し、このPDPコンテキスト生成要求はPDPタイプ、PDPアドレス、APN、QoSパラメータ、TEID及び選択モードを搬送する。PDPアドレスはUEのIPアドレスであり、任意選択のパラメータである。PDPコンテキスト生成要求がPDPアドレスを搬送しない場合、IPアドレスは後続プロセスにおいてGGSNにより割当てられる場合もあれば、UEにより最終的に接続されるパケットデータネットワーク(PDN)により割り当てられる場合もある。選択モードはAPN選択モードをいい、即ち、APNがUEによって選択されるか、SGSNによって選択されるかをいう。APNに従ってSGSNに対してGGSNアドレス情報がアクセスされなければ、SGSNはUEからのPDPコンテキスト起動要求を拒否する。
ステップ104:GGSNは、PDPコンテキスト生成要求を受信後、APNに従って外部PDNを決定し、次いで課金IDを割り当て、課金を開始し、QoSを参照する。サービス品質要件が満たされると、GGSNはSGSNへPDPコンテキスト生成応答を返送。このPDPコンテキスト生成応答は、TEID、PDPアドレス、バックボーンベアラプロトコル、QoSパラメータ及び課金IDの情報を搬送する。GGSNがQoSパラメータのサービス品質要件を満たしていなければ、GGSNはSGSNからのPDPコンテキスト生成要求を拒否し、次いでSGSNはUEからのPDPコンテキスト起動要求を拒否する。
ステップ105:SGSNは、PDPコンテキスト生成応答を受信後、PDPコンテキストを識別するために、PDPコンテキストへNSAPI及びGGSNアドレス情報を追加し、QoSパラメータに従って無線手順を選択し、次いでUEへPDPコンテキスト起動受容を返す。このPDPコンテキスト起動受容は、PDPタイプ、PDPアドレス、TI、QoSパラメータ、無線手順及び幾つかのPDP構成オプションの情報を搬送する。さらに、SGSNは課金を開始する。UEはPDPコンテキスト起動受容を受信し、GGSNによるルートを確立する。この時点までに、UEとPDNとの間の伝送チャネルは確立され、データ送信を開始することができる。
ステップ106:UEは、PDNによりSGSN及びGGSNを介してデータを伝送する。
ステップ107:UEは、データ伝送を終了すると、SGSNへPDPコンテキスト停止要求を送信し、このPDPコンテキスト停止要求はTIを搬送する。
ステップ108:SGSNは、PDPコンテキスト停止要求を受信後、セキュリティチェック及びUEによる暗号化を実行するが、このステップは任意選択である。
ステップ109乃至ステップ111:SGSNは、TEIDを搬送するPDPコンテキスト削除要求をGGSNへ送信する。GGSNは、このPDPコンテキスト削除要求を受信後、UEの課金を終了し、TEIDに対応するPDPコンテキストを削除し、次いでSGSNへ送信する。PDPコンテキスト削除応答は、TEIDを搬送する。PDPコンテキスト削除応答を受信後、SGSNはUEの課金を終了し、TEIDに対応するPDPコンテキストを削除し、次いでTIを搬送するPDPコンテキスト停止応答をUEへ送信する。UEは、PDPコンテキスト停止応答を受信後、TIに対応するPDPコンテキストを削除する。
図1に示されるように、現在のGRPS課金システムにおいては、課金はPDPコンテキストの起動時に始まり、PDPコンテキストが停止されたとき終了となる。これは、現在の課金システムは、送信されるデータフロー又はPDPコンテキストの起動持続時間に従った課金しかできないことを意味する。しかしながら、実際には、PDNとの伝送チャネルを確立後、UEは1つの起動されたPDPコンテキストに基づいて複数のサービスを実行する。即ち、PDNが、Eメール送受信サービス、無線アプリケーションプロトコル(WAP)ベースのブラウズサービス、ファイル転送プロトコル(FTP)ベースのファイル転送サービス等の複数のサービスを提供することができれば、起動されるPDPコンテキストは、UEがこのPDNとの伝送チャネルを確立した後に、PDNによって提供される様々なサービスに耐えることができる。一方で、運営者又はサービスプロバイダは様々なサービスの異なる課金モードに対して異なる課金手法を採用することが可能であり、例えば、Eメール送受信サービスは送信及び受信イベントのトリガ時間に基づいて課金されてもよく、WAPブラウズサービスはフローに従って課金されてもよく、ファイル転送サービスもまたフローに従って課金されてもよく、しかもWAPブラウズサービスの課金レートはファイル転送サービスの課金レートとは異なる。従って、同じPDPコンテキストが担う異なるサービスに対して従来のGRPS課金システムで別々の課金を実行することは、全く不可能である。
上記に鑑みて、第3世代パートナーシッププロジェクト(3GPP)では、IPフローベース課金(FBC)を如何にして実装するかに関する検討が行われている。パケットデータサービスに関する限り、UEユーザが上記サービスを使用する場合、送信されかつ受信されるIPフロー又はIPパケットは全てサービスデータフローと呼ぶことが可能であり、即ち、サービスデータフローは複数のIPフローの集合であり、故にIPフローベース課金は所定のサービスのリソース占有を真に反映することができる。IPフローベース課金は次のように記述することができる。即ち、同じPDPコンテキストが担う異なるサービスのIPフローは、篩に似た幾つかのフィルタを介して別々に選別して除かれ、次に異なるフィルタで選別されたIPフローは、異なるサービスデータフローを別々に課金するという目的を達成するように別々に課金される。こうして、IPフローに基づく課金細分性はPDPコンテキストに基づくものより遙かに少ない。課金細分性は篩の穴のサイズと見なすことができ、よって、1つのPDPコンテキストに基づく課金細分性は1つのPDPコンテキストによって決定される篩の穴のようなものであるのに対して、IPフローに基づく課金細分性は1つのIPフローによって決定される篩の穴のようなものであって、つまりは、1つのPDPコンテキストには2つ以上の篩の穴が包含される。従って、1つのPDPコンテキストに基づく課金と比較して、IPフローに基づく課金は、運営者又はサービスプロバイダに対してより多くの課金手法を提供できる。
3GPPでは、システムアーキテクチャ、機能要件及び双方向メッセージのフローのようなFBCの複数の態様が記述されている。図2Aには、オンライン課金をサポートするFBCシステムアーキテクチャが示される。本図において、オンライン課金システム(OCS)206は、移動ネットワーク強化論理のためのカスタマイズドアプリケーション(CAMEL)のサービス制御点(SCP)201と、サービスデータフローベースのクレジット制御機能(CCF)202とから構成される。CCF202は、インタフェースRyを介してサービスデータフローベースの課金ルール機能(CRF)203と接続される。CRF203はインタフェースRxを介してアプリケーション機能(AF)204と接続され、かつインタフェースGxを介してトラフィックプレーン機能(TPF)205と接続される。CCF202は、インタフェースGyを介してTPF205と接続される。
オフライン課金をサポートするFBCシステムアーキテクチャが、図2Bに示される。本図において、CRF203はインタフェースRxを介してAF204と接続され、かつインタフェースGxを介してTPF205と接続され、TPF205はGzを介してそれぞれ課金ゲートウェイ機能(CGF)207及び課金収集機能(CCF)208と接続される。
FBCを実装する機能に関する3GPPの規定に従って、TPF205はIPフローをベアラサービスで伝送する。IPフローの伝送中及びその確立する期間、TPF205はGxインタフェースを介してCRF203へ課金ルール要求を送信する。課金ルール要求は、加入者及びUEの関連情報、ベアラサービスの特性、ネットワーク情報等を搬送する。加入者及びUEの関連情報は、移動局ISDN(MSISDN)、国際移動加入者識別番号(IMSI)、その他であってもよい。さらに、ベアラサービスはIPフロー伝送の間に修正されてもよい。例えば、同じサービスのQoSパラメータが異なる場合、課金ルールは適宜異なってもよい。例えば、課金レートはQoSパラメータの低下に伴って低下してもよい。従って、QoSパラメータの再検討は必要である。この場合、ベアラサービスを修正する間に、TPF205はCRF203へ課金ルール要求を再送信して新しい課金ルールを要求する。CRF203はTPF205によって供給される上記入力情報に従って適切な課金ルールを選択し、次いでこの選択された課金ルールをTPF205へ返す。課金ルールは、課金機構、課金タイプ、課金キー、サービスデータフローフィルタ及び課金ルールの優先順位の情報を含む。課金機構は、オンライン課金であっても、オフライン課金であってもよい。課金タイプは、タイムスパンベースのタイプであってもよい。課金キーは課金レートに関連するパラメータであり、CRF203は、TPF205の課金レートを直接供給するのではなく、TPF205の課金レートに関連するパラメータのみを供給してもよい。サービスデータフローフィルタは、TPF205にどのIPフローをろ波すべきかを指示するために使用され、次いでTPF205は課金ルールに従ってこれらのろ波されたIPフローに課金する。サービスデータフローフィルタは、送信元/宛先IPアドレス、送信元/宛先ポート番号及びプロトコルIDといった情報を有するIP5タプル(IP quintuple)を含んでもよい。例えば、CRF203はTPF205に、送信元IPアドレス10.0.0.1、宛先IPアドレス10.0.0.2、送信元/宛先ポート番号20及びプロトコルタイプの伝送制御プロトコル(TCP)を有するIPフローをろ波するように指示し、次いでろ波されたIPフローを課金ルールに従って課金する。最後に、ベアラサービスを削除する間、TPF205もまたCRF203へ課金ルール要求を送信してCRFからの新しい課金ルールを要求してもよい。この時点で、CRF203はTPF205に、先にインストールされた課金ルールを削除するように要求してもよい。
さらにCRF203は、TPF205の入力情報以外にAF204又はOCS20の入力情報に従って課金ルールを決定してもよい。例えば、AF204はCRF203へユーザにより使用されている現在のサービスタイプを通知してもよく、CRF203はこのサービスタイプに従って対応する課金ルールを選択してもよい。
GPRSネットワークの場合、TPF205はGGSNであり、AFはPDNにおけるサービスゲートウェイ又はサービスサーバであり、CRF203は追加の論理エンティティである。TPF205は課金ルールの実行点であり、CRF203は課金ルールの制御点である。
図3Aは、ベアラサービスが確立されるときの課金ルールの発行を示すフローチャートである。図3Aに示されるように、ベアラサービスが確立されるときの課金ルールの発行の実行手順は、下記のステップを含む。
ステップ301A:UEはTPFへベアラサービス確立要求を送る一方、GPRSネットワークでは、対応するプロセスとしてGGSNがPDPコンテキスト生成要求を受信する。
ステップ302A:TPFは、ベアラサービス確立要求を受信後、CRFへ課金ルール要求を送信する。この課金ルール要求は、CRFが課金ルールを決定するための入力情報を搬送する。
ステップ303A乃至304A:CRFは、課金ルール要求を受信後、課金ルール要求によって搬送された入力情報に従って課金ルールを選択し、次いで課金ルール供給を返す。この課金ルール供給は、選択された課金ルールを搬送してもよい。
ステップ305A乃至306A:TPFは、課金ルール供給を受信後、CRFによって選択された課金ルールに従って新しい課金ルールをインストールし、若しくは元の課金ルールを削除し、若しくは元の課金ルールを削除しながら新しい課金ルールをインストールする。次に、TPFはUEによって始動されたベアラサービス確立要求を受信し、ベアラサービス確立受容をUEへ返し、後続ステップであるベアラサービス確立プロセスを継続する。
図3Bは、ベアラサービスが修正されるときの課金ルールの発行を示すフローチャートである。図3Bに示されるように、ベアラサービスが修正されるときの課金ルールの発行の実行手順は、下記のステップを含む。
ステップ301B:UEはTPFへベアラサービス修正要求を送る一方、GPRSネットワークでは、対応するプロセスとしてGGSNがPDPコンテキスト更新要求を受信する。
ステップ302B:TPFは、ベアラサービス修正要求を受信後、CRFへ課金ルール要求を送信する。この課金ルール要求は、CRFが課金ルールを決定するための入力情報を搬送する。
ステップ303B乃至304B:CRFは、課金ルール要求を受信後、この課金ルール要求によって搬送された入力情報に従って課金ルールを選択し、次いでこの選択された課金ルールを搬送する課金ルール供給を返す。
ステップ305B乃至306B:TPFは、課金ルール供給を受信後、CRFによって選択された課金ルールに従って新しい課金ルールをインストールし、若しくは元の課金ルールを削除し、若しくは元の課金ルールを削除しながら新しい課金ルールをインストールする。次に、TPFはUEによって始動されたベアラサービス修正要求を受信し、ベアラサービス修正受容をUEへ返し、後続ステップであるベアラサービス修正プロセスを継続する。
図3Cは、ベアラサービスが削除されるときの課金ルールの発行を示すフローチャートである。図3Bに示されるように、ベアラサービスが削除されるときの課金ルールの発行の実行手順は、下記のステップを含む。
ステップ301C:UEはTPFへベアラサービス除去要求を送信する一方、GPRSネットワークでは、対応するプロセスとしてGGSNがPDPコンテキスト削除要求を受信する。
ステップ302C:TPFは、ベアラサービス除去要求を受信後、CRFへ課金ルール要求を送信する。この課金ルール要求は、CRFが課金ルールを決定するための入力情報を搬送する。
ステップ303C乃至304C:CRFは、課金ルール要求を受信後、この課金ルール要求によって搬送された入力情報に従って課金ルールを選択し、次いでこの選択された課金ルールを搬送する課金ルール供給を返す。
ステップ305C乃至306C:TPFは、課金ルール供給を受信後、CRFによって選択された課金ルールに従って新しい課金ルールをインストールし、若しくは元の課金ルールを削除し、若しくは元の課金ルールを削除しながら新しい課金ルールをインストールする。次に、TPFはベアラサービス除去受容をUEへ返し、UEによって始動されたベアラサービス除去要求を受容し、後続ステップであるベアラサービス除去プロセスを継続する。
加えて、CRFはまた、自発的にTPFへ課金ルールを送ってもよい。例えば、UEとAFとの間のデータ伝送プロセスにおいては、CRFは、AFの課金に関連する入力情報を受信後、AFによって供給された入力情報に従って適切な課金ルールを選択し、次いでこの選択された課金ルールを自発的にTPFへ発行する。図4にCRFに対して課金の入力情報を供給するAFの特定の実行手順を示す。
ステップ401:AFは、CRFへアプリケーション/サービスデータフロー課金情報を送信する。
ステップ402:CRFは、アプリケーション/サービスデータフロー課金情報を受信後、AFへ肯定応答(Ack)を返し、AFにより送信されたアプリケーション/サービスデータフロー課金情報を既に受信したことをAFに通知する。
図5は、CRFによるTPFへの自発的な課金ルールの発行を示すフローチャートである。図5に示されるように、CRFによるTPFへの自発的な課金ルールの発行の実行手順は下記のステップを含む。
ステップ501:CRFは、AFによるCRFへの課金ルール選択の入力情報の送信イベント等の所定の内部又は外部トリガイベント及びこのイベントについての関連情報を受信する。
ステップ502:CRFは、取得される情報に従って対応する課金ルールを選択する。取得される情報は、AFにより供給される課金関連の入力情報であってもよい。例えば、ユーザはAFの所定のサービスを使用していて、このサービスは特定の課金要件を有し、例えば課金レートが他のサービスの課金レートと異なれば、AFはCRFに対してこのサービスの関連課金情報を供給する。取得される情報は、TPFにより供給される課金関連の入力情報であってもよい。
ステップ503:CRFは、必要に応じてTPFへ課金ルール供給を送信する。この課金ルール供給は、選択された課金ルールを搬送してもよい。
ステップ504:TPFは、課金ルール供給を受信後、CRFによって選択された課金ルールに従って新しい課金ルールをインストールし、若しくは元の課金ルールを削除し、若しくは元の課金ルールを削除しながら新しい課金ルールをインストールする。
現在のところ、TPFとCRF間の課金ルールに関する双方向モードは、3GPP仕様において次のように定義されている。即ち、所定のトリガイベントの発生条件が満たされると、TPFはCRFへ課金ルール要求を送信する。トリガイベントは、ベアラサービスの確立、修正又は削除というイベントであってもよい。CRFは、課金ルール要求において搬送される情報に従って適切な課金ルールを選択し、選択された課金ルールをTPFへ送信する。こうして、課金ルール要求のイベントトリガはTPFによって制御される。課金ルール要求のイベントトリガは、事前にTPFにセットされるものとする。ベアラサービスの確立、修正又は削除というイベントの発生条件が満たされる度に、TPFはCRFへ課金ルール要求を送信する。但し、ベアラサービスを修正する間にQoSパラメータが修正されたとき、修正されたQoSパラメータと元のQoSパラメータとの間にほとんど差が無く、課金ルールを修正する必要が無い場合がある。このような場合、TPFが課金ルール要求を送信するとCRFは元の課金ルールに類似する課金ルールを選択してTPFへ送信する可能性があり、これにより、多くの冗長情報が生成される。
上記に鑑みて、現在の3GPP仕様では、CRFが課金ルールの制御点であるにも関わらず、CRFは課金を完全に制御することができない。
上記に鑑みて、本発明の目的は、パケットデータサービスの課金制御を妥当かつ完全なものにするようなパケットデータサービスの課金制御方法を提供することにある。
上述の目的を達成するために、本発明においてパケットデータサービスの課金制御方法が提供される。本方法は、複数のイベントトリガをセットするステップと、前記複数のイベントトリガの発生条件が満たされたとき、トラフィックプレーン機能(TPF)から課金ルール機能(CRF)へ課金ルール要求を送信するステップと、を含む。
好適には、前記複数のイベントトリガをセットするステップは、前記TPFにおいて複数の静的イベントトリガがセットされることを含む。前記静的イベントトリガの発生条件が満たされる前に、本方法はさらに、前記TPFが前記静的イベントトリガの発生を監視するステップを含む。
好適には、前記CRFにより複数の動的イベントトリガがセットされ、前記TPFへ供給される。
好適には、前記イベントトリガのうちの1つの発生条件が満たされる前に、本方法はさらに、前記TPFが前記CRFから受信した前記複数の動的イベントトリガを格納し、前記複数の動的イベントトリガの何れかの発生条件が満たされるかどうかを監視することを含む。
好適には、前記CRFが複数の動的イベントトリガをセットするステップは、前記複数の動的イベントトリガが前記CRFにおける自己格納情報に従ってセットされることを含む。
好適には、前記CRFが複数の動的イベントトリガをセットすることは、前記複数の動的イベントトリガが、アプリケーション機能(AF)、オンライン課金システム(OCS)、前記TPF又は前記AF、前記OCS及び前記TPFの組合せにより供給される課金関連の入力情報に従ってセットされることを含む。
好適には、前記TPFから前記CRFへの課金ルール要求の送信後、本方法はさらに、CRFによる課金ルール要求の受信後、前記複数の動的イベントトリガがセットされて前記TPFへ供給されることを含む。
好適には、前記課金ルール要求は、対応するトリガイベントを指示するイベント識別子を含む。
好適には、前記TPFから前記CRFへの前記課金ルール要求の送信後、本方法はさらに、課金ルールが前記TPFへ供給されることを含む。
好適には、前記CRFは前記イベントトリガに従って前記課金ルールを決定する。
本発明においては、イベントトリガのうちの1つの発生条件が満たされるとTPFがCRFから対応する課金ルールを要求するように、複数のイベントトリガがセットされる。このイベントトリガは、TPFにおいてセットされる場合もあれば、CRFにより決定される場合もある。CRFは、TPFが課金ルールの要求を必要とする根拠となるイベントトリガを決定し、上記イベントトリガをTPFへ送信する。上記イベントトリガのうちの1つの発生条件が満たされると、TPFはCRFからの課金ルールを要求し、CRFへ課金関連の入力情報を供給する。次いで、CRFは上記課金関連入力情報に従って適切な課金ルールを選択し、選択された課金ルールをTPFへ送信する。このようにして、TPFがCRFからの課金ルールを要求するタイミングを制御することが可能であり、望まれない課金ルール要求をCRFへ送信するときにTPFにより引き起こされる冗長情報が回避され、これにより、TPFとCRFとの間の情報交流はより効果的になり、パケットデータサービスの課金制御はより妥当かつ完全なものになる。本発明では、TPFで静的イベントトリガのみがセットされ、CRFはTPFへ動的イベントトリガを供給する必要がない。これにより、TPFとCRFとの間のメッセージ負荷が低減される。
さらに、CRFはAF又はOCSにより供給される課金関連入力情報を入手することが可能であるので、課金関連入力情報は課金ルールに影響を与える可能性がある。本発明の方法によれば、CRFは課金関連入力情報に従ってイベントトリガを柔軟にセットし、この現在のイベントトリガをTPFへ送信することができ、よってTPFは、所定のイベントトリガの発生条件が満たされたときにCRFから新しい課金ルールを要求する。このようにして、課金ルールの柔軟かつ多様なアプリケーションが実装され得る。しかしながら、上述の機能が従来のTPF/CRF間の相互作用方法によって達成されることは全く不可能である。
以後、添付の図面を参照して本発明を詳しく説明する。
本発明においては、イベントトリガのうちの1つの発生条件が満たされるとTPFがCRFから対応する課金ルールを要求するように、複数のイベントトリガがセットされる。これらのイベントトリガは、TPFにおいてセットされる場合もあれば、CRFによって決定される場合もある。CRFは、TPFが課金ルールの要求を必要とする根拠となるイベントトリガを決定し、上記イベントトリガをTPFへ送信する。上記イベントトリガのうちの1つの発生条件が満たされると、TPFはCRFからの課金ルールを要求し、課金関連の入力情報を供給する。CRFは上記課金関連入力情報に従って適切な課金ルールを選択し、選択された課金ルールをTPFへ送信する。このようにして、TPFがCRFからの課金ルールを要求するタイミングを制御することが可能であり、望まれない課金ルール要求をCRFへ送信する場合にTPFにより引き起こされる冗長情報が回避される。
図6は、TPFによる課金ルール要求の送信に対するCRFの制御を示すフローチャートである。図6に示されるように、上記制御の実行は下記のステップを含む。
ステップ601:TPFにおいて、ベアラサービスの確立を表す静的イベントトリガ等の、TPFがCRFからの対応する課金ルールを要求するようにトリガされることを有効化する静的イベントトリガをセットする。静的イベントトリガの発生条件が満たされると、TPFはCRFへ課金ルール要求を送信する。この課金ルール要求は、加入者及びUEに関する情報、ベアラサービスの特性及びネットワークに関する情報等の課金関連入力情報を搬送する。またこの課金ルール要求は、上記静的イベントトリガによって現在の課金ルール要求がトリガされていることを指示するイベント識別子も搬送してもよい。
さらに、TPFにおいては、ベアラサービスの確立、ベアラサービスの削除等といった2つ以上の静的イベントトリガがセットされてもよい。これらのうちの所定の静的イベントトリガの発生条件が満たされると、TPFはCRFからの課金ルールを要求する。一方で、TPFはTPFにおいて静的イベントトリガをセットしなくてもよく、ベアラサービスが確立されるときCRFへ周期的に課金ルール要求を送信する。
ステップ602:CRFは、課金ルール要求を受信後、TPFがその時点で課金ルールを要求することを求められる動的イベントトリガをセットし、TPFへ動的イベント報告要求を送信する。この動的イベント報告要求は、動的イベントトリガA、動的イベントトリガB及び動的イベントトリガC等の動的イベントトリガのリストを搬送する。これらのイベントは、SGSN、公衆陸上移動網(PLMN)、無線アクセス技術(RAT)型、トラフィックフローテンプレート及びQoSの各変更等、複数の種々の修正ベアラサービスイベントであってもよい。
ステップ603:CRFは、課金ルール要求により搬送される課金関連入力情報に従って、適切な課金ルールを選択し、TPFへ課金ルール供給を送信する。この課金ルール供給は、課金ルール1等の選択された課金ルールを搬送してもよい。
ステップ602及び603においてCRFがTPFへ送信する情報は、1つのメッセージで搬送されてもよい。
ステップ604:動的イベントトリガのリスト及びCRFによりその時点で選択された課金ルールを受信後、TPFはこの動的イベントトリガリストを格納し、選択された課金ルールに従って課金情報統計を実行し、動的イベントトリガの何れかの発生条件が満たされるかどうかを監視する。
ステップ605:TPFは、動的イベントトリガAの発生を監視し、次いでCRFへ課金ルール要求を送信する。この課金ルール要求は、動的イベントトリガAの発生インジケータを搬送する。
ステップ606:CRFは、課金ルール要求を受信後、動的イベントトリガAの発生インジケータに従ってこの課金ルール要求が動的イベントトリガAによりトリガされていることを確認し、同じく動的イベントトリガAに従って適切な課金ルールを選択し、次いでTPFへ課金ルール供給を送信する。この課金ルール供給は、課金ルール2等の新しく選択された課金ルールを搬送する。
ステップ607:TPFは、課金ルール供給を受信後、この課金ルール供給に従って課金情報統計を実行する。
2つ以上の動的イベントトリガが存在するならば、TPFは、他の動的イベントトリガのうちの何れかの発生条件が満たされるかどうかの監視を継続する。
ステップ608:TPFは、動的イベントトリガBの発生を監視し、CRFへ課金ルール要求を送信する。この課金ルール要求は、動的イベントトリガBの発生インジケータを搬送する。
ステップ609:CRFは、課金ルール要求を受信後、動的イベントトリガBの発生インジケータに従ってこの課金ルール要求が動的イベントトリガBによりトリガされていることを確認し、同じく動的イベントトリガBに従って適切な課金ルールを選択する。次いで、CRFはTPFへ課金ルール供給を送信する。この課金ルール供給は、課金ルール3等の新しく選択された課金ルールを搬送する。
ステップ610:TPFは、課金ルール供給を受信後、この課金ルール供給に従って課金情報の統計をとる。
以後のフローは上述のフローに類似するものであり、さらなる説明は省略する。
加えて、同じセッションにおいて、CRFは動的イベントトリガを複数回セットしてもよく、これらの動的イベントトリガをTPFへ送信する。ここで、同じセッションとは、GPRSネットワークにおける同一のPDPコンテキストを意味する。例えば、AF又はOCSから課金関連入力情報を受信すると、CRFはこの課金関連入力情報に従って新しい動的イベントトリガをセットすることが必要とされているかどうかを決定し、必要とされていれば、CRFは新しい動的イベントトリガをセットし、その点をTPFへ送信する。TPFは、新しい動的イベントトリガを受信後、この新しい動的イベントトリガを格納し、動的イベントトリガの発生を監視する。
さらに、CRFからの課金ルールを要求するこの静的イベントトリガはTPFにおいてセットされてもよいので、ベアラサービスの確立、ベアラサービスの修正、ベアラサービスの削除、フロー又は持続時間の固定値に達した場合のイベント発生等といったベアラサービス変更のルーチンイベントは、TPFにおいて事前に構成された静的イベントトリガによってCRFへ直接報告されてもよく、よってCRFはTPFへ動的イベントトリガを送信する必要がない。運営者又はサービスプロバイダによっては、ベアラサービス変更のルーチンイベントが常時いくつか存在する場合があり、例えば、サービスフローが10Mに達すると、若しくは上記サービスが100分間作動されると、TPFは常時CRFへ報告することを要求され、他のイベント点は動的構成を必要としない。この場合、TPFでは適切な静的イベントトリガのみが予め構成され、動的イベントトリガはCRFによって発行されない。よって、TPFとCRFとの間の信号伝達負荷の低減が可能である。
図7は、本発明の実施形態1を例示する概略図である。本図において、TPFがCRFからの課金ルールを要求するための静的イベントトリガはベアラサービスの確立としてセットされ、CRFは、ベアラサービスが修正又は除去されるとTPFがCRFへ課金ルール要求を送信することを要求される動的イベントトリガをセットし、TPFによる課金ルール要求の送信をCRFが制御することを示す実行手順は、下記のステップを含む。
ステップ701:UEは、TPFへベアラサービス確立要求を送信する。GPRSネットワークにおいてこれに対応するステップは、GGSNがPDPコンテキスト生成要求を受信することである。
ステップ702:TPFは、ベアラサービス確立要求を受信後、静的イベントトリガの発生を確認し、CRFへ課金ルール要求を送信する。この課金ルール要求は、加入者及びUEの関連情報、ベアラサービスの特性及びネットワーク情報等の課金関連入力情報を搬送する。またこの要求は、現在の課金ルール要求が静的イベントトリガによってトリガされていることを示すイベント識別子を搬送してもよい。
ステップ703乃至704:CRFは、課金ルール要求を受信後、イベント識別子に従って課金ルール要求が静的イベントトリガによってトリガされていることを確認し、ベアラサービスの修正及びベアラサービスの削除を含む動的イベントトリガのリストをセットし、TPFへ動的イベント報告要求を送信する。この動的イベント報告要求は、動的イベントトリガのリストを搬送する。さらに、CRFは、ベアラサービスの修正という動的イベントトリガにおいて様々なQoSパラメータ優先順位等の複数の様々な値を設定してもよく、各値は独立した動的イベントトリガであってもよい。
ステップ705乃至706:CRFは、課金ルール要求によって搬送される課金関連入力情報に従って適切な課金ルールを選択し、TPFへ課金ルール応答を送信する。この課金ルール応答は、選択された課金ルールを搬送する。
ステップ707乃至708:TPFは、CRFによりセットされた動的イベントトリガリスト及びCRFにより選択された課金ルールを受信後、動的イベントトリガリストを格納し、その課金ルールに従って課金情報統計を実行し、動的イベントトリガの発生を監視する。TPFはUEへベアラサービス確立受容メッセージを返し、UEにより始動されたベアラサービス確立要求を受容し、後続ステップであるベアラサービス確立フローを継続する。
ステップ709:しばらくすると、UEはTPFへベアラサービス修正要求を送信する。GPRSネットワークにおいてこれに対応するステップは、GGSNがPDPコンテキスト更新要求を受信することである。
ステップ710:ベアラサービス修正要求を受信後、TPFは動的イベントトリガリストにおけるベアラサービスの修正という動的イベントトリガが発生していることを確認し、CRFへ課金ルール要求を送信する。この課金ルール要求は、動的イベントトリガの発生インジケータを搬送する。
ステップ711乃至712:CRFは、課金ルール要求を受信後、この動的イベントトリガの発生インジケータに従って課金ルール要求がベアラサービス修正という動的イベントトリガによってトリガされていることを確認し、このベアラサービス修正に従って適切な課金ルールを選択し、TPFへ課金ルール供給を送信する。この課金ルール供給は、選択された課金ルールを搬送してもよい。
ステップ713乃至714:TPFは、課金ルール供給を受信後、CRFによって選択された課金ルールに従って新しい課金ルールをインストールし、若しくは元の課金ルールを除去し、若しくは元の課金ルールを削除しながら新しい課金ルールをインストールし、次いでUEへベアラサービス修正受容を返し、UEによって始動されたベアラサービス修正要求を受容し、後続ステップであるベアラサービス修正フローを継続する。
ステップ715:しばらくすると、UEはTPFへベアラサービス除去要求を送信する。GPRSネットワークにおいてこれに対応するステップは、GGSNがPDPコンテキスト削除要求を受信することである。
ステップ716:TPFは、ベアラサービス除去要求を受信後、動的イベントトリガリストにおけるベアラサービス除去という動的イベントトリガが発生していることを確認し、CRFへ課金ルール要求を送信する。この課金ルール要求は、動的イベントトリガの発生インジケータを搬送する。
ステップ717乃至718:CRFは、課金ルール要求を受信後、動的イベントトリガの発生インジケータに従って課金ルール要求がベアラサービス削除という動的イベントトリガによってトリガされていることを確認し、ベアラサービス削除に従って適切な課金ルールを選択し、TPFへ課金ルール供給を送信する。この課金ルール供給は、選択された課金ルールを搬送してもよい。
ステップ719乃至720:CRFは、課金ルール供給を受信後、CRFによって選択された課金ルールに従って新しい課金ルールをインストールし、若しくは元の課金ルールを削除し、若しくは元の課金ルールを削除しながら新しい課金ルールをインストールし、次いでUEへベアラサービス除去受容メッセージを返し、UEによって始動されたベアラサービス除去要求を受容し、後続ステップであるベアラサービス削除フローを継続する。
先行技術においては、AFは、アプリケーション/サービスデータフローの課金情報を、CRFが課金ルールを選択するための課金関連入力情報としてCRFへ送信する。次いで、本発明において提供される方法では、AFは、アプリケーション/サービスデータフローの課金情報を、CRFが動的イベントトリガを動的にセットするための入力情報としてCRFへ送信する。
図8は、本発明の実施形態2を例示する概略図である。図8に示されるように、CRFがTPFへ動的イベントトリガを発行するための本発明における実行手順は、下記のステップを含む。
ステップ801:CRFは、所定の内部又は外部トリガイベントを受信する。例えば、AFは、認可されたアクティビティをユーザに提供する。あるユーザによってアクセスされたこのAFの所定のサービスのデータフローが設定値に到達すれば、このサービスに対する上記ユーザのその後の課金レートは低減される。この場合、所定のサービスフィルタのデータフローが設定値に到達したときに、AFは、後続のデータフローに関しては課金情報統計を考慮して有利な課金レートを採用するようにCRFに要求する。或いは、ユーザがこのAFの所定のサービスにアクセスしている持続時間が設定値に到達すれば、このサービスに対する上記ユーザのその後の課金レートは低減される。この場合、所定のサービスフィルタが使用されている持続時間が設定値に達したときに、AFは、後続のデータフローに関しては課金情報統計を実行して有利な課金レートを採用するようにCRFに要求する。
ステップ802:CRFは、例えば、所定のサービスフィルタのデータフローが設定値に到達したとき、若しくは所定のサービスフィルタが設定されたタイムスパンに渡って使用されたとき等の動的イベントトリガをセットする。さらに、CRFは、TPFによって供給されるユーザ/端末情報、ベアラサービスの特性及びネットワーク情報等、その時点で取得されている情報に従って、適切な課金ルールを選択してもよい。
ステップ803:CRFは動的イベントトリガの現在のリストを搬送する動的イベント報告要求をTPFへ送信し、TPFにその動的イベントトリガの発生条件が満たされたときにCRFからの課金ルールを要求するように求める。
ステップ804:CRFはTPFへ課金ルール供給を送信する。この課金ルール供給は、その時点で選択されている課金ルールを搬送する。このステップは、任意選択である。
ステップ805:TPFはCRFによってセットされた動的イベントトリガの現在のリストを受信し、この動的イベントトリガリストを格納する。TPFが課金ルール供給をも受信すれば、TPFはCRFによって選択された課金ルールに従って新しい課金ルールをインストールし、若しくは元の課金ルールを削除し、若しくは元の課金ルールを削除しながら新しい課金ルールをインストールする。
ステップ806:しばらくすると、TPFは動的イベントトリガの発生を監視し、CRFへ課金ルール要求を送信する。この課金ルール要求は、動的イベントトリガの発生インジケータを搬送する。
ステップ807乃至808:CRFは、課金ルール要求を受信後、この動的イベントトリガの発生インジケータに従ってどの動的イベントトリガがこの課金ルール要求をトリガしているかを確認する。例えば、このイベントは、所定のサービスフィルタのデータフローが設定値に到達するというイベントであっても、所定のサービスフィルタが設定されたタイムスパンに渡って使用されたというイベントであってもよい。次いでCRFは、この動的イベントトリガに従って適切な課金ルールを選択し、TPFへ課金ルール供給を送信する。この課金ルール供給は、選択された課金ルールを搬送してもよい。
ステップ809:TPFは、課金ルール供給を受信後、CRFによって選択された課金ルールに従って新しい課金ルールをインストールし、若しくは元の課金ルールを削除し、若しくは元の課金ルールを削除しながら新しい課金ルールをインストールする。
さらに、CRFはまた、ユーザのクレジットに関してOCSにより送信される課金関連入力情報に従って動的イベントトリガを動的にセットしてもよい。対応するフローは基本的に上述のフローと同じものであり、さらなる説明は省略する。
要するに、上述の説明は本発明の好適な実施形態であるに過ぎず、本発明の保護範囲を限定するものとして解釈されるべきではない。
PDPコンテキストの起動、データ送信及び停止のフローを例示するフローチャートである。
オンライン課金FBCシステムの構成を例示する概略図である。
オフライン課金FBCシステムの構成を例示する概略図である。
ベアラサービスが確立されるときの課金ルールの発行を示すフローチャートである。
ベアラサービスが修正されるときの課金ルールの発行を示すフローチャートである。
ベアラサービスが削除されるときの課金ルールの発行を示すフローチャートである。
CRFに対してAFが課金入力情報を供給するフローチャートである。
CRFがTPFへ課金ルールを自発的に発行するフローチャートである。
本発明においてCRFがTPFによる課金ルール要求の送信を制御するフローチャートである。
本発明の実施形態1を例示する概略図である。
本発明の実施形態2を例示する概略図である。