JP2010213302A

JP2010213302A - パケットデータサービスの課金制御方法

Info

Publication number: JP2010213302A
Application number: JP2010091482A
Authority: JP
Inventors: Xiaoqin Duan; 小琴段
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2004-04-01
Filing date: 2010-04-12
Publication date: 2010-09-24
Anticipated expiration: 2025-03-28
Also published as: EP1732264B1; US20120033560A1; EP1732264A1; US20110280192A1; US8009573B2; JP5190085B2; ATE424068T1; JP2007529925A; DE602005012935D1; EP1732264B8; CN1303781C; WO2005096547A1; US20070060101A1; EP1732264A4; US8531971B2; CN1645805A

Abstract

【課題】パケットデータサービスの課金制御を妥当かつ完全なものにする。
【解決手段】本方法は、複数のイベントトリガを監視することと、上記イベントトリガの１つの発生条件が満たされたとき、トラフィックプレーン機能（ＴＰＦ）から課金ルール機能（ＣＲＦ）への課金ルール要求を送信することを含む。本発明では、ＴＰＦがＣＲＦからの課金ルールを要求するように求められるもとになる複数のイベントトリガがＣＲＦによってセットされてＴＰＦへ供給される。上記要求には課金関連入力情報が供給され、ＣＲＦはこれに基づいて適切な課金ルールを決定し、決定された課金ルールをＴＰＦへ送信する。こうして、ＴＰＦがＣＲＦからの課金ルールを要求するタイミングを制御でき、ＴＰＦからの不要な課金ルールにより引き起こされる冗長情報を回避できる。
【選択図】図６

Description

本発明は課金方法に関し、より具体的には、パケットデータサービスの課金制御方法に関する。

パケットデータサービスの広範な利用に伴い、パケットデータサービスを正確かつ合理的に課金する方法は運営者にとって共通の関心事となっている。

図１は、パケットデータプロトコルコンテキスト（ＰＤＰコンテキスト）の起動、データ送信及び停止を示すフローチャートである。図１に示されるように、汎用パケット無線サービス（ＧＰＲＳ）においては、ＰＤＰコンテキストの起動、データ送信及び停止の実行手順は下記のステップを含む。

ステップ１０１：ユーザ装置（ＵＥ）はサービス側ＧＰＲＳサポートノード（ＳＧＳＮ）へＰＤＰコンテキスト起動要求を送信し、このＰＤＰコンテキスト起動要求は、ネットワーク層サービスアクセス点識別子（ＮＳＡＰＩ）、ＰＤＰタイプ、アクセス点名（ＡＰＮ）、複数のサービス品質（ＱｏＳ）パラメータ、トランザクション識別子（ＴＩ）等の情報を搬送する。但し、ＮＳＡＰＩは、ＰＤＰコンテキストを識別するために、ＳＧＳＮとゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）との間のトンネル識別子（ＴＥＩＤ）のコンポーネントとして使用される。ＰＤＰタイプには、ピア−ピアプロトコル（ＰＰＰ）タイプ、インターネットプロトコル（ＩＰ）タイプ、その他が含まれる。ＡＰＮは、ＳＧＳＮに対してＵＥにより供給されることが可能であり、これによりＳＧＳＮは対応するＧＧＳＮをアドレス指定し、ＧＧＳＮはＵＥによってアクセスされるべき外部ネットワークを決定する。もしくは、ＵＥはＳＧＳＮに対してＡＰＮを供給しないことを選択する可能性もあり、この場合、ＳＧＳＮは、ＵＥの加入者情報に従ってデフォルトＡＰＮを選択する。ＱｏＳパラメータは、ＵＥにより指定されるパケットデータサービスによって要求される品質を表す。ＴＩは、ＵＥがＰＤＰコンテキストを識別するために使用される。

ステップ１０２：ＳＧＳＮは、ＰＤＰコンテキスト起動要求を受信後、セキュリティチェック及びＵＥによる暗号化を実行する。このステップは任意選択である。

ステップ１０３：ＳＧＳＮは、ＡＰＮに従ってＧＧＳＮアドレス情報を分析し、ＳＧＳＮがＡＰＮに従ってＧＧＳＮアドレス情報を発見すれば、ＰＤＰコンテキストに対してＴＥＩＤが生成される。ＴＥＩＤは、ＳＧＳＮとＧＧＳＮとの間のＰＤＰコンテキストを一意に識別するために国際移動加入者識別番号（ＩＭＳＩ）とＮＳＡＰＩとの組合せであってもよい。次に、ＳＧＳＮはＧＧＳＮへＰＤＰコンテキスト生成要求を送信し、このＰＤＰコンテキスト生成要求はＰＤＰタイプ、ＰＤＰアドレス、ＡＰＮ、ＱｏＳパラメータ、ＴＥＩＤ及び選択モードを搬送する。ＰＤＰアドレスはＵＥのＩＰアドレスであり、任意選択のパラメータである。ＰＤＰコンテキスト生成要求がＰＤＰアドレスを搬送しない場合、ＩＰアドレスは後続プロセスにおいてＧＧＳＮにより割当てられる場合もあれば、ＵＥにより最終的に接続されるパケットデータネットワーク（ＰＤＮ）により割り当てられる場合もある。選択モードはＡＰＮ選択モードをいい、即ち、ＡＰＮがＵＥによって選択されるか、ＳＧＳＮによって選択されるかをいう。ＡＰＮに従ってＳＧＳＮに対してＧＧＳＮアドレス情報がアクセスされなければ、ＳＧＳＮはＵＥからのＰＤＰコンテキスト起動要求を拒否する。

ステップ１０４：ＧＧＳＮは、ＰＤＰコンテキスト生成要求を受信後、ＡＰＮに従って外部ＰＤＮを決定し、次いで課金ＩＤを割り当て、課金を開始し、ＱｏＳを参照する。サービス品質要件が満たされると、ＧＧＳＮはＳＧＳＮへＰＤＰコンテキスト生成応答を返送。このＰＤＰコンテキスト生成応答は、ＴＥＩＤ、ＰＤＰアドレス、バックボーンベアラプロトコル、ＱｏＳパラメータ及び課金ＩＤの情報を搬送する。ＧＧＳＮがＱｏＳパラメータのサービス品質要件を満たしていなければ、ＧＧＳＮはＳＧＳＮからのＰＤＰコンテキスト生成要求を拒否し、次いでＳＧＳＮはＵＥからのＰＤＰコンテキスト起動要求を拒否する。

ステップ１０５：ＳＧＳＮは、ＰＤＰコンテキスト生成応答を受信後、ＰＤＰコンテキストを識別するために、ＰＤＰコンテキストへＮＳＡＰＩ及びＧＧＳＮアドレス情報を追加し、ＱｏＳパラメータに従って無線手順を選択し、次いでＵＥへＰＤＰコンテキスト起動受容を返す。このＰＤＰコンテキスト起動受容は、ＰＤＰタイプ、ＰＤＰアドレス、ＴＩ、ＱｏＳパラメータ、無線手順及び幾つかのＰＤＰ構成オプションの情報を搬送する。さらに、ＳＧＳＮは課金を開始する。ＵＥはＰＤＰコンテキスト起動受容を受信し、ＧＧＳＮによるルートを確立する。この時点までに、ＵＥとＰＤＮとの間の伝送チャネルは確立され、データ送信を開始することができる。

ステップ１０６：ＵＥは、ＰＤＮによりＳＧＳＮ及びＧＧＳＮを介してデータを伝送する。

ステップ１０７：ＵＥは、データ伝送を終了すると、ＳＧＳＮへＰＤＰコンテキスト停止要求を送信し、このＰＤＰコンテキスト停止要求はＴＩを搬送する。

ステップ１０８：ＳＧＳＮは、ＰＤＰコンテキスト停止要求を受信後、セキュリティチェック及びＵＥによる暗号化を実行するが、このステップは任意選択である。

ステップ１０９乃至ステップ１１１：ＳＧＳＮは、ＴＥＩＤを搬送するＰＤＰコンテキスト削除要求をＧＧＳＮへ送信する。ＧＧＳＮは、このＰＤＰコンテキスト削除要求を受信後、ＵＥの課金を終了し、ＴＥＩＤに対応するＰＤＰコンテキストを削除し、次いでＰＤＰコンテキスト削除応答をＳＧＳＮへ送信する。ＰＤＰコンテキスト削除応答は、ＴＥＩＤを搬送する。ＰＤＰコンテキスト削除応答を受信後、ＳＧＳＮはＵＥの課金を終了し、ＴＥＩＤに対応するＰＤＰコンテキストを削除し、次いでＴＩを搬送するＰＤＰコンテキスト停止応答をＵＥへ送信する。ＵＥは、ＰＤＰコンテキスト停止応答を受信後、ＴＩに対応するＰＤＰコンテキストを削除する。

図１に示されるように、現在のＧＲＰＳ課金システムにおいては、課金はＰＤＰコンテキストの起動時に始まり、ＰＤＰコンテキストが停止されたとき終了となる。これは、現在の課金システムは、送信されるデータフロー又はＰＤＰコンテキストの起動持続時間に従った課金しかできないことを意味する。しかしながら、実際には、ＰＤＮとの伝送チャネルを確立後、ＵＥは１つの起動されたＰＤＰコンテキストに基づいて複数のサービスを実行する。即ち、ＰＤＮが、Ｅメール送受信サービス、無線アプリケーションプロトコル（ＷＡＰ）ベースのブラウズサービス、ファイル転送プロトコル（ＦＴＰ）ベースのファイル転送サービス等の複数のサービスを提供することができれば、起動されるＰＤＰコンテキストは、ＵＥがこのＰＤＮとの伝送チャネルを確立した後に、ＰＤＮによって提供される様々なサービスに耐えることができる。一方で、運営者又はサービスプロバイダは様々なサービスの異なる課金モードに対して異なる課金手法を採用することが可能であり、例えば、Ｅメール送受信サービスは送信及び受信イベントのトリガ時間に基づいて課金されてもよく、ＷＡＰブラウズサービスはフローに従って課金されてもよく、ファイル転送サービスもまたフローに従って課金されてもよく、しかもＷＡＰブラウズサービスの課金レートはファイル転送サービスの課金レートとは異なる。従って、同じＰＤＰコンテキストが担う異なるサービスに対して従来のＧＲＰＳ課金システムで別々の課金を実行することは、全く不可能である。

上記に鑑みて、第３世代パートナーシッププロジェクト（３ＧＰＰ）では、ＩＰフローベース課金（ＦＢＣ）を如何にして実装するかに関する検討が行われている。パケットデータサービスに関する限り、ＵＥユーザが上記サービスを使用する場合、送信されかつ受信されるＩＰフロー又はＩＰパケットは全てサービスデータフローと呼ぶことが可能であり、即ち、サービスデータフローは複数のＩＰフローの集合であり、故にＩＰフローベース課金は所定のサービスのリソース占有を真に反映することができる。ＩＰフローベース課金は次のように記述することができる。即ち、同じＰＤＰコンテキストが担う異なるサービスのＩＰフローは、篩に似た幾つかのフィルタを介して別々に選別して除かれ、次に異なるフィルタで選別されたＩＰフローは、異なるサービスデータフローを別々に課金するという目的を達成するように別々に課金される。こうして、ＩＰフローに基づく課金細分性はＰＤＰコンテキストに基づくものより遙かに少ない。課金細分性は篩の穴のサイズと見なすことができ、よって、１つのＰＤＰコンテキストに基づく課金細分性は１つのＰＤＰコンテキストによって決定される篩の穴のようなものであるのに対して、ＩＰフローに基づく課金細分性は１つのＩＰフローによって決定される篩の穴のようなものであって、つまりは、１つのＰＤＰコンテキストには２つ以上の篩の穴が包含される。従って、１つのＰＤＰコンテキストに基づく課金と比較して、ＩＰフローに基づく課金は、運営者又はサービスプロバイダに対してより多くの課金手法を提供できる。

３ＧＰＰでは、システムアーキテクチャ、機能要件及び双方向メッセージのフローのようなＦＢＣの複数の態様が記述されている。図２Ａには、オンライン課金をサポートするＦＢＣシステムアーキテクチャが示される。本図において、オンライン課金システム（ＯＣＳ）２０６は、移動ネットワーク強化論理のためのカスタマイズドアプリケーション（ＣＡＭＥＬ）のサービス制御点（ＳＣＰ）２０１と、サービスデータフローベースのクレジット制御機能（ＣＣＦ）２０２とから構成される。ＣＣＦ２０２は、インタフェースＲｙを介してサービスデータフローベースの課金ルール機能（ＣＲＦ）２０３と接続される。ＣＲＦ２０３はインタフェースＲｘを介してアプリケーション機能（ＡＦ）２０４と接続され、かつインタフェースＧｘを介してトラフィックプレーン機能（ＴＰＦ）２０５と接続される。ＣＣＦ２０２は、インタフェースＧｙを介してＴＰＦ２０５と接続される。

オフライン課金をサポートするＦＢＣシステムアーキテクチャが、図２Ｂに示される。本図において、ＣＲＦ２０３はインタフェースＲｘを介してＡＦ２０４と接続され、かつインタフェースＧｘを介してＴＰＦ２０５と接続され、ＴＰＦ２０５はＧｚを介してそれぞれ課金ゲートウェイ機能（ＣＧＦ）２０７及び課金収集機能（ＣＣＦ）２０８と接続される。

ＦＢＣを実装する機能に関する３ＧＰＰの規定に従って、ＴＰＦ２０５はＩＰフローをベアラサービスで伝送する。ＩＰフローの伝送中及びその確立する期間、ＴＰＦ２０５はＧｘインタフェースを介してＣＲＦ２０３へ課金ルール要求を送信する。課金ルール要求は、加入者及びＵＥの関連情報、ベアラサービスの特性、ネットワーク情報等を搬送する。加入者及びＵＥの関連情報は、移動局ＩＳＤＮ（ＭＳＩＳＤＮ）、国際移動加入者識別番号（ＩＭＳＩ）、その他であってもよい。さらに、ベアラサービスはＩＰフロー伝送の間に修正されてもよい。例えば、同じサービスのＱｏＳパラメータが異なる場合、課金ルールは適宜異なってもよい。例えば、課金レートはＱｏＳパラメータの低下に伴って低下してもよい。従って、ＱｏＳパラメータの再検討は必要である。この場合、ベアラサービスを修正する間に、ＴＰＦ２０５はＣＲＦ２０３へ課金ルール要求を再送信して新しい課金ルールを要求する。ＣＲＦ２０３はＴＰＦ２０５によって供給される上記入力情報に従って適切な課金ルールを選択し、次いでこの選択された課金ルールをＴＰＦ２０５へ返す。課金ルールは、課金機構、課金タイプ、課金キー、サービスデータフローフィルタ及び課金ルールの優先順位の情報を含む。課金機構は、オンライン課金であっても、オフライン課金であってもよい。課金タイプは、タイムスパンベースのタイプであってもよい。課金キーは課金レートに関連するパラメータであり、ＣＲＦ２０３は、ＴＰＦ２０５の課金レートを直接供給するのではなく、ＴＰＦ２０５の課金レートに関連するパラメータのみを供給してもよい。サービスデータフローフィルタは、ＴＰＦ２０５にどのＩＰフローをろ波すべきかを指示するために使用され、次いでＴＰＦ２０５は課金ルールに従ってこれらのろ波されたＩＰフローに課金する。サービスデータフローフィルタは、送信元／宛先ＩＰアドレス、送信元／宛先ポート番号及びプロトコルＩＤといった情報を有するＩＰ５タプル（IP quintuple）を含んでもよい。例えば、ＣＲＦ２０３はＴＰＦ２０５に、送信元ＩＰアドレス１０．０．０．１、宛先ＩＰアドレス１０．０．０．２、送信元／宛先ポート番号２０及びプロトコルタイプの伝送制御プロトコル（ＴＣＰ）を有するＩＰフローをろ波するように指示し、次いでろ波されたＩＰフローを課金ルールに従って課金する。最後に、ベアラサービスを削除する間、ＴＰＦ２０５もまたＣＲＦ２０３へ課金ルール要求を送信してＣＲＦからの新しい課金ルールを要求してもよい。この時点で、ＣＲＦ２０３はＴＰＦ２０５に、先にインストールされた課金ルールを削除するように要求してもよい。

さらにＣＲＦ２０３は、ＴＰＦ２０５の入力情報以外にＡＦ２０４又はＯＣＳ２０６の入力情報に従って課金ルールを決定してもよい。例えば、ＡＦ２０４はＣＲＦ２０３へユーザにより使用されている現在のサービスタイプを通知してもよく、ＣＲＦ２０３はこのサービスタイプに従って対応する課金ルールを選択してもよい。

ＧＰＲＳネットワークの場合、ＴＰＦ２０５はＧＧＳＮであり、ＡＦはＰＤＮにおけるサービスゲートウェイ又はサービスサーバであり、ＣＲＦ２０３は追加の論理エンティティである。ＴＰＦ２０５は課金ルールの実行点であり、ＣＲＦ２０３は課金ルールの制御点である。

図３Ａは、ベアラサービスが確立されるときの課金ルールの発行を示すフローチャートである。図３Ａに示されるように、ベアラサービスが確立されるときの課金ルールの発行の実行手順は、下記のステップを含む。

ステップ３０１Ａ：ＵＥはＴＰＦへベアラサービス確立要求を送る一方、ＧＰＲＳネットワークでは、対応するプロセスとしてＧＧＳＮがＰＤＰコンテキスト生成要求を受信する。

ステップ３０２Ａ：ＴＰＦは、ベアラサービス確立要求を受信後、ＣＲＦへ課金ルール要求を送信する。この課金ルール要求は、ＣＲＦが課金ルールを決定するための入力情報を搬送する。

ステップ３０３Ａ乃至３０４Ａ：ＣＲＦは、課金ルール要求を受信後、課金ルール要求によって搬送された入力情報に従って課金ルールを選択し、次いで課金ルール供給を返す。この課金ルール供給は、選択された課金ルールを搬送してもよい。

ステップ３０５Ａ乃至３０６Ａ：ＴＰＦは、課金ルール供給を受信後、ＣＲＦによって選択された課金ルールに従って新しい課金ルールをインストールし、若しくは元の課金ルールを削除し、若しくは元の課金ルールを削除しながら新しい課金ルールをインストールする。次に、ＴＰＦはＵＥによって始動されたベアラサービス確立要求を受信し、ベアラサービス確立受容をＵＥへ返し、後続ステップであるベアラサービス確立プロセスを継続する。

図３Ｂは、ベアラサービスが修正されるときの課金ルールの発行を示すフローチャートである。図３Ｂに示されるように、ベアラサービスが修正されるときの課金ルールの発行の実行手順は、下記のステップを含む。

ステップ３０１Ｂ：ＵＥはＴＰＦへベアラサービス修正要求を送る一方、ＧＰＲＳネットワークでは、対応するプロセスとしてＧＧＳＮがＰＤＰコンテキスト更新要求を受信する。

ステップ３０２Ｂ：ＴＰＦは、ベアラサービス修正要求を受信後、ＣＲＦへ課金ルール要求を送信する。この課金ルール要求は、ＣＲＦが課金ルールを決定するための入力情報を搬送する。

ステップ３０３Ｂ乃至３０４Ｂ：ＣＲＦは、課金ルール要求を受信後、この課金ルール要求によって搬送された入力情報に従って課金ルールを選択し、次いでこの選択された課金ルールを搬送する課金ルール供給を返す。

ステップ３０５Ｂ乃至３０６Ｂ：ＴＰＦは、課金ルール供給を受信後、ＣＲＦによって選択された課金ルールに従って新しい課金ルールをインストールし、若しくは元の課金ルールを削除し、若しくは元の課金ルールを削除しながら新しい課金ルールをインストールする。次に、ＴＰＦはＵＥによって始動されたベアラサービス修正要求を受信し、ベアラサービス修正受容をＵＥへ返し、後続ステップであるベアラサービス修正プロセスを継続する。

図３Ｃは、ベアラサービスが削除されるときの課金ルールの発行を示すフローチャートである。図３Ｃに示されるように、ベアラサービスが削除されるときの課金ルールの発行の実行手順は、下記のステップを含む。

ステップ３０１Ｃ：ＵＥはＴＰＦへベアラサービス除去要求を送信する一方、ＧＰＲＳネットワークでは、対応するプロセスとしてＧＧＳＮがＰＤＰコンテキスト削除要求を受信する。

ステップ３０２Ｃ：ＴＰＦは、ベアラサービス除去要求を受信後、ＣＲＦへ課金ルール要求を送信する。この課金ルール要求は、ＣＲＦが課金ルールを決定するための入力情報を搬送する。

ステップ３０３Ｃ乃至３０４Ｃ：ＣＲＦは、課金ルール要求を受信後、この課金ルール要求によって搬送された入力情報に従って課金ルールを選択し、次いでこの選択された課金ルールを搬送する課金ルール供給を返す。

ステップ３０５Ｃ乃至３０６Ｃ：ＴＰＦは、課金ルール供給を受信後、ＣＲＦによって選択された課金ルールに従って新しい課金ルールをインストールし、若しくは元の課金ルールを削除し、若しくは元の課金ルールを削除しながら新しい課金ルールをインストールする。次に、ＴＰＦはベアラサービス除去受容をＵＥへ返し、ＵＥによって始動されたベアラサービス除去要求を受容し、後続ステップであるベアラサービス除去プロセスを継続する。

加えて、ＣＲＦはまた、自発的にＴＰＦへ課金ルールを送ってもよい。例えば、ＵＥとＡＦとの間のデータ伝送プロセスにおいては、ＣＲＦは、ＡＦの課金に関連する入力情報を受信後、ＡＦによって供給された入力情報に従って適切な課金ルールを選択し、次いでこの選択された課金ルールを自発的にＴＰＦへ発行する。図４にＣＲＦに対して課金の入力情報を供給するＡＦの特定の実行手順を示す。

ステップ４０１：ＡＦは、ＣＲＦへアプリケーション／サービスデータフロー課金情報を送信する。

ステップ４０２：ＣＲＦは、アプリケーション／サービスデータフロー課金情報を受信後、ＡＦへ肯定応答（Ａｃｋ）を返し、ＡＦにより送信されたアプリケーション／サービスデータフロー課金情報を既に受信したことをＡＦに通知する。

図５は、ＣＲＦによるＴＰＦへの自発的な課金ルールの発行を示すフローチャートである。図５に示されるように、ＣＲＦによるＴＰＦへの自発的な課金ルールの発行の実行手順は下記のステップを含む。

ステップ５０１：ＣＲＦは、ＡＦによるＣＲＦへの課金ルール選択の入力情報の送信イベント等の所定の内部又は外部トリガイベント及びこのイベントについての関連情報を受信する。

ステップ５０２：ＣＲＦは、取得される情報に従って対応する課金ルールを選択する。取得される情報は、ＡＦにより供給される課金関連の入力情報であってもよい。例えば、ユーザはＡＦの所定のサービスを使用していて、このサービスは特定の課金要件を有し、例えば課金レートが他のサービスの課金レートと異なれば、ＡＦはＣＲＦに対してこのサービスの関連課金情報を供給する。取得される情報は、ＴＰＦにより供給される課金関連の入力情報であってもよい。

ステップ５０３：ＣＲＦは、必要に応じてＴＰＦへ課金ルール供給を送信する。この課金ルール供給は、選択された課金ルールを搬送してもよい。

ステップ５０４：ＴＰＦは、課金ルール供給を受信後、ＣＲＦによって選択された課金ルールに従って新しい課金ルールをインストールし、若しくは元の課金ルールを削除し、若しくは元の課金ルールを削除しながら新しい課金ルールをインストールする。

特開２００３−１５２７７８号公報。国際出願の国際公開ＷＯ０２／９３８３５号公報。

現在のところ、ＴＰＦとＣＲＦ間の課金ルールに関する双方向モードは、３ＧＰＰ仕様において次のように定義されている。即ち、所定のトリガイベントの発生条件が満たされると、ＴＰＦはＣＲＦへ課金ルール要求を送信する。トリガイベントは、ベアラサービスの確立、修正又は削除というイベントであってもよい。ＣＲＦは、課金ルール要求において搬送される情報に従って適切な課金ルールを選択し、選択された課金ルールをＴＰＦへ送信する。こうして、課金ルール要求のイベントトリガはＴＰＦによって制御される。課金ルール要求のイベントトリガは、事前にＴＰＦにセットされるものとする。ベアラサービスの確立、修正又は削除というイベントの発生条件が満たされる度に、ＴＰＦはＣＲＦへ課金ルール要求を送信する。但し、ベアラサービスを修正する間にＱｏＳパラメータが修正されたとき、修正されたＱｏＳパラメータと元のＱｏＳパラメータとの間にほとんど差が無く、課金ルールを修正する必要が無い場合がある。このような場合、ＴＰＦが課金ルール要求を送信するとＣＲＦは元の課金ルールに類似する課金ルールを選択してＴＰＦへ送信する可能性があり、これにより、多くの冗長情報が生成される。

上記に鑑みて、現在の３ＧＰＰ仕様では、ＣＲＦが課金ルールの制御点であるにも関わらず、ＣＲＦは課金を完全に制御することができない。

上記に鑑みて、本発明の目的は、パケットデータサービスの課金制御を妥当かつ完全なものにするようなパケットデータサービスの課金制御方法を提供することにある。

上述の目的を達成するために、本発明においてパケットデータサービスの課金制御方法が提供される。本方法は、
トラフィックプレーン機能（ＴＰＦ）によって、課金ルール機能（ＣＲＦ）から少なくとも１つのイベントトリガを受信するステップと、
前記ＴＰＦによって、前記少なくとも１つのイベントトリガを監視するステップと、
前記少なくとも１つのイベントトリガのうちのいずれかの発生条件が満たされたとき、前記ＴＰＦから前記ＣＲＦへ課金ルール要求を送信するステップと、
前記ＣＲＦにより、課金ルール供給手順により課金ルールを供給することにより前記課金ルール要求に応答するステップとを含む。

好適には、前記少なくとも１つのイベントトリガは、前記ＣＲＦによりセットされ、ベアラ修正要求を含む。好適には、前記ＴＰＦは、前記ＣＲＦから受信される前記少なくとも１つのイベントトリガを格納する。
好適には、前記ＴＰＦから前記ＣＲＦに送信される前記課金ルール要求は、発生条件を満たしたイベントトリガを示すイベント識別子を含む。好適には、前記課金ルール供給手順による課金ルールは、前記発生条件を満たしたイベントトリガに従って供給される。

好適には、前記少なくとも１つのイベントトリガは、前記ＣＲＦ自体に格納された情報に従って、又は、前記ＴＰＦによって供給される課金関連入力情報に従ってセットされ、前記課金関連入力情報は、加入者及びＵＥに関連した情報と、ベアラ特性情報と、ネットワーク情報とのうちの少なくとも１つを含む。
好適には、前記少なくとも１つのイベントトリガは、前記ＣＲＦによってセットされ、サービス側汎用パケット無線サービスサポートノード（ＳＧＳＮ）の変更、公衆陸上移動網（ＰＬＭＮ）の変更、無線アクセス技術（ＲＡＴ）型の変更、トラフィックフローテンプレート（ＴＦＴ）の変更、及びＱｏＳの変更のうちの少なくとも１つを含む。

本発明においては、イベントトリガのうちの１つの発生条件が満たされるとＴＰＦがＣＲＦから対応する課金ルールを要求するように、複数のイベントトリガがセットされる。このイベントトリガは、ＴＰＦにおいてセットされる場合もあれば、ＣＲＦにより決定される場合もある。ＣＲＦは、ＴＰＦが課金ルールの要求を必要とする根拠となるイベントトリガを決定し、上記イベントトリガをＴＰＦへ送信する。上記イベントトリガのうちの１つの発生条件が満たされると、ＴＰＦはＣＲＦからの課金ルールを要求し、ＣＲＦへ課金関連の入力情報を供給する。次いで、ＣＲＦは上記課金関連入力情報に従って適切な課金ルールを選択し、選択された課金ルールをＴＰＦへ送信する。このようにして、ＴＰＦがＣＲＦからの課金ルールを要求するタイミングを制御することが可能であり、望まれない課金ルール要求をＣＲＦへ送信するときにＴＰＦにより引き起こされる冗長情報が回避され、これにより、ＴＰＦとＣＲＦとの間の情報交流はより効果的になり、パケットデータサービスの課金制御はより妥当かつ完全なものになる。本発明では、ＴＰＦで静的イベントトリガのみがセットされ、ＣＲＦはＴＰＦへ動的イベントトリガを供給する必要がない。これにより、ＴＰＦとＣＲＦとの間のメッセージ負荷が低減される。

さらに、ＣＲＦはＡＦ又はＯＣＳにより供給される課金関連入力情報を入手することが可能であるので、課金関連入力情報は課金ルールに影響を与える可能性がある。本発明の方法によれば、ＣＲＦは課金関連入力情報に従ってイベントトリガを柔軟にセットし、この現在のイベントトリガをＴＰＦへ送信することができ、よってＴＰＦは、所定のイベントトリガの発生条件が満たされたときにＣＲＦから新しい課金ルールを要求する。このようにして、課金ルールの柔軟かつ多様なアプリケーションが実装され得る。しかしながら、上述の機能が従来のＴＰＦ／ＣＲＦ間の相互作用方法によって達成されることは全く不可能である。

ＰＤＰコンテキストの起動、データ送信及び停止のフローを例示するフローチャートである。オンライン課金ＦＢＣシステムの構成を例示する概略図である。オフライン課金ＦＢＣシステムの構成を例示する概略図である。ベアラサービスが確立されるときの課金ルールの発行を示すフローチャートである。ベアラサービスが修正されるときの課金ルールの発行を示すフローチャートである。ベアラサービスが削除されるときの課金ルールの発行を示すフローチャートである。ＣＲＦに対してＡＦが課金入力情報を供給するフローチャートである。ＣＲＦがＴＰＦへ課金ルールを自発的に発行するフローチャートである。本発明においてＣＲＦがＴＰＦによる課金ルール要求の送信を制御するフローチャートである。本発明の実施形態１を例示する概略図である。本発明の実施形態２を例示する概略図である。

以後、添付の図面を参照して本発明を詳しく説明する。

本発明においては、イベントトリガのうちの１つの発生条件が満たされるとＴＰＦがＣＲＦから対応する課金ルールを要求するように、複数のイベントトリガがセットされる。これらのイベントトリガは、ＴＰＦにおいてセットされる場合もあれば、ＣＲＦによって決定される場合もある。ＣＲＦは、ＴＰＦが課金ルールの要求を必要とする根拠となるイベントトリガを決定し、上記イベントトリガをＴＰＦへ送信する。上記イベントトリガのうちの１つの発生条件が満たされると、ＴＰＦはＣＲＦからの課金ルールを要求し、課金関連の入力情報を供給する。ＣＲＦは上記課金関連入力情報に従って適切な課金ルールを選択し、選択された課金ルールをＴＰＦへ送信する。このようにして、ＴＰＦがＣＲＦからの課金ルールを要求するタイミングを制御することが可能であり、望まれない課金ルール要求をＣＲＦへ送信する場合にＴＰＦにより引き起こされる冗長情報が回避される。

図６は、ＴＰＦによる課金ルール要求の送信に対するＣＲＦの制御を示すフローチャートである。図６に示されるように、上記制御の実行は下記のステップを含む。

ステップ６０１：ＴＰＦにおいて、ベアラサービスの確立を表す静的イベントトリガ等の、ＴＰＦがＣＲＦからの対応する課金ルールを要求するようにトリガされることを有効化する静的イベントトリガをセットする。静的イベントトリガの発生条件が満たされると、ＴＰＦはＣＲＦへ課金ルール要求を送信する。この課金ルール要求は、加入者及びＵＥに関する情報、ベアラサービスの特性及びネットワークに関する情報等の課金関連入力情報を搬送する。またこの課金ルール要求は、上記静的イベントトリガによって現在の課金ルール要求がトリガされていることを指示するイベント識別子も搬送してもよい。

さらに、ＴＰＦにおいては、ベアラサービスの確立、ベアラサービスの削除等といった２つ以上の静的イベントトリガがセットされてもよい。これらのうちの所定の静的イベントトリガの発生条件が満たされると、ＴＰＦはＣＲＦからの課金ルールを要求する。一方で、ＴＰＦはＴＰＦにおいて静的イベントトリガをセットしなくてもよく、ベアラサービスが確立されるときＣＲＦへ周期的に課金ルール要求を送信する。

ステップ６０２：ＣＲＦは、課金ルール要求を受信後、ＴＰＦがその時点で課金ルールを要求することを求められる動的イベントトリガをセットし、ＴＰＦへ動的イベント報告要求を送信する。この動的イベント報告要求は、動的イベントトリガＡ、動的イベントトリガＢ及び動的イベントトリガＣ等の動的イベントトリガのリストを搬送する。これらのイベントは、ＳＧＳＮ、公衆陸上移動網（ＰＬＭＮ）、無線アクセス技術（ＲＡＴ）型、トラフィックフローテンプレート及びＱｏＳの各変更等、複数の種々の修正ベアラサービスイベントであってもよい。

ステップ６０３：ＣＲＦは、課金ルール要求により搬送される課金関連入力情報に従って、適切な課金ルールを選択し、ＴＰＦへ課金ルール供給を送信する。この課金ルール供給は、課金ルール１等の選択された課金ルールを搬送してもよい。

ステップ６０２及び６０３においてＣＲＦがＴＰＦへ送信する情報は、１つのメッセージで搬送されてもよい。

ステップ６０４：動的イベントトリガのリスト及びＣＲＦによりその時点で選択された課金ルールを受信後、ＴＰＦはこの動的イベントトリガリストを格納し、選択された課金ルールに従って課金情報統計を実行し、動的イベントトリガの何れかの発生条件が満たされるかどうかを監視する。

ステップ６０５：ＴＰＦは、動的イベントトリガＡの発生を監視し、次いでＣＲＦへ課金ルール要求を送信する。この課金ルール要求は、動的イベントトリガＡの発生インジケータを搬送する。

ステップ６０６：ＣＲＦは、課金ルール要求を受信後、動的イベントトリガＡの発生インジケータに従ってこの課金ルール要求が動的イベントトリガＡによりトリガされていることを確認し、同じく動的イベントトリガＡに従って適切な課金ルールを選択し、次いでＴＰＦへ課金ルール供給を送信する。この課金ルール供給は、課金ルール２等の新しく選択された課金ルールを搬送する。

ステップ６０７：ＴＰＦは、課金ルール供給を受信後、この課金ルール供給に従って課金情報統計を実行する。

２つ以上の動的イベントトリガが存在するならば、ＴＰＦは、他の動的イベントトリガのうちの何れかの発生条件が満たされるかどうかの監視を継続する。

ステップ６０８：ＴＰＦは、動的イベントトリガＢの発生を監視し、ＣＲＦへ課金ルール要求を送信する。この課金ルール要求は、動的イベントトリガＢの発生インジケータを搬送する。

ステップ６０９：ＣＲＦは、課金ルール要求を受信後、動的イベントトリガＢの発生インジケータに従ってこの課金ルール要求が動的イベントトリガＢによりトリガされていることを確認し、同じく動的イベントトリガＢに従って適切な課金ルールを選択する。次いで、ＣＲＦはＴＰＦへ課金ルール供給を送信する。この課金ルール供給は、課金ルール３等の新しく選択された課金ルールを搬送する。

ステップ６１０：ＴＰＦは、課金ルール供給を受信後、この課金ルール供給に従って課金情報の統計をとる。

以後のフローは上述のフローに類似するものであり、さらなる説明は省略する。

加えて、同じセッションにおいて、ＣＲＦは動的イベントトリガを複数回セットしてもよく、これらの動的イベントトリガをＴＰＦへ送信する。ここで、同じセッションとは、ＧＰＲＳネットワークにおける同一のＰＤＰコンテキストを意味する。例えば、ＡＦ又はＯＣＳから課金関連入力情報を受信すると、ＣＲＦはこの課金関連入力情報に従って新しい動的イベントトリガをセットすることが必要とされているかどうかを決定し、必要とされていれば、ＣＲＦは新しい動的イベントトリガをセットし、その点をＴＰＦへ送信する。ＴＰＦは、新しい動的イベントトリガを受信後、この新しい動的イベントトリガを格納し、動的イベントトリガの発生を監視する。

さらに、ＣＲＦからの課金ルールを要求するこの静的イベントトリガはＴＰＦにおいてセットされてもよいので、ベアラサービスの確立、ベアラサービスの修正、ベアラサービスの削除、フロー又は持続時間の固定値に達した場合のイベント発生等といったベアラサービス変更のルーチンイベントは、ＴＰＦにおいて事前に構成された静的イベントトリガによってＣＲＦへ直接報告されてもよく、よってＣＲＦはＴＰＦへ動的イベントトリガを送信する必要がない。運営者又はサービスプロバイダによっては、ベアラサービス変更のルーチンイベントが常時いくつか存在する場合があり、例えば、サービスフローが１０Ｍに達すると、若しくは上記サービスが１００分間作動されると、ＴＰＦは常時ＣＲＦへ報告することを要求され、他のイベント点は動的構成を必要としない。この場合、ＴＰＦでは適切な静的イベントトリガのみが予め構成され、動的イベントトリガはＣＲＦによって発行されない。よって、ＴＰＦとＣＲＦとの間の信号伝達負荷の低減が可能である。

図７は、本発明の実施形態１を例示する概略図である。本図において、ＴＰＦがＣＲＦからの課金ルールを要求するための静的イベントトリガはベアラサービスの確立としてセットされ、ＣＲＦは、ベアラサービスが修正又は除去されるとＴＰＦがＣＲＦへ課金ルール要求を送信することを要求される動的イベントトリガをセットし、ＴＰＦによる課金ルール要求の送信をＣＲＦが制御することを示す実行手順は、下記のステップを含む。

ステップ７０１：ＵＥは、ＴＰＦへベアラサービス確立要求を送信する。ＧＰＲＳネットワークにおいてこれに対応するステップは、ＧＧＳＮがＰＤＰコンテキスト生成要求を受信することである。

ステップ７０２：ＴＰＦは、ベアラサービス確立要求を受信後、静的イベントトリガの発生を確認し、ＣＲＦへ課金ルール要求を送信する。この課金ルール要求は、加入者及びＵＥの関連情報、ベアラサービスの特性及びネットワーク情報等の課金関連入力情報を搬送する。またこの要求は、現在の課金ルール要求が静的イベントトリガによってトリガされていることを示すイベント識別子を搬送してもよい。

ステップ７０３乃至７０４：ＣＲＦは、課金ルール要求を受信後、イベント識別子に従って課金ルール要求が静的イベントトリガによってトリガされていることを確認し、ベアラサービスの修正及びベアラサービスの削除を含む動的イベントトリガのリストをセットし、ＴＰＦへ動的イベント報告要求を送信する。この動的イベント報告要求は、動的イベントトリガのリストを搬送する。さらに、ＣＲＦは、ベアラサービスの修正という動的イベントトリガにおいて様々なＱｏＳパラメータ優先順位等の複数の様々な値を設定してもよく、各値は独立した動的イベントトリガであってもよい。

ステップ７０５乃至７０６：ＣＲＦは、課金ルール要求によって搬送される課金関連入力情報に従って適切な課金ルールを選択し、ＴＰＦへ課金ルール応答を送信する。この課金ルール応答は、選択された課金ルールを搬送する。

ステップ７０７乃至７０８：ＴＰＦは、ＣＲＦによりセットされた動的イベントトリガリスト及びＣＲＦにより選択された課金ルールを受信後、動的イベントトリガリストを格納し、その課金ルールに従って課金情報統計を実行し、動的イベントトリガの発生を監視する。ＴＰＦはＵＥへベアラサービス確立受容メッセージを返し、ＵＥにより始動されたベアラサービス確立要求を受容し、後続ステップであるベアラサービス確立フローを継続する。

ステップ７０９：しばらくすると、ＵＥはＴＰＦへベアラサービス修正要求を送信する。ＧＰＲＳネットワークにおいてこれに対応するステップは、ＧＧＳＮがＰＤＰコンテキスト更新要求を受信することである。

ステップ７１０：ベアラサービス修正要求を受信後、ＴＰＦは動的イベントトリガリストにおけるベアラサービスの修正という動的イベントトリガが発生していることを確認し、ＣＲＦへ課金ルール要求を送信する。この課金ルール要求は、動的イベントトリガの発生インジケータを搬送する。

ステップ７１１乃至７１２：ＣＲＦは、課金ルール要求を受信後、この動的イベントトリガの発生インジケータに従って課金ルール要求がベアラサービス修正という動的イベントトリガによってトリガされていることを確認し、このベアラサービス修正に従って適切な課金ルールを選択し、ＴＰＦへ課金ルール供給を送信する。この課金ルール供給は、選択された課金ルールを搬送してもよい。

ステップ７１３乃至７１４：ＴＰＦは、課金ルール供給を受信後、ＣＲＦによって選択された課金ルールに従って新しい課金ルールをインストールし、若しくは元の課金ルールを除去し、若しくは元の課金ルールを削除しながら新しい課金ルールをインストールし、次いでＵＥへベアラサービス修正受容を返し、ＵＥによって始動されたベアラサービス修正要求を受容し、後続ステップであるベアラサービス修正フローを継続する。

ステップ７１５：しばらくすると、ＵＥはＴＰＦへベアラサービス除去要求を送信する。ＧＰＲＳネットワークにおいてこれに対応するステップは、ＧＧＳＮがＰＤＰコンテキスト削除要求を受信することである。

ステップ７１６：ＴＰＦは、ベアラサービス除去要求を受信後、動的イベントトリガリストにおけるベアラサービス除去という動的イベントトリガが発生していることを確認し、ＣＲＦへ課金ルール要求を送信する。この課金ルール要求は、動的イベントトリガの発生インジケータを搬送する。

ステップ７１７乃至７１８：ＣＲＦは、課金ルール要求を受信後、動的イベントトリガの発生インジケータに従って課金ルール要求がベアラサービス削除という動的イベントトリガによってトリガされていることを確認し、ベアラサービス削除に従って適切な課金ルールを選択し、ＴＰＦへ課金ルール供給を送信する。この課金ルール供給は、選択された課金ルールを搬送してもよい。

ステップ７１９乃至７２０：ＣＲＦは、課金ルール供給を受信後、ＣＲＦによって選択された課金ルールに従って新しい課金ルールをインストールし、若しくは元の課金ルールを削除し、若しくは元の課金ルールを削除しながら新しい課金ルールをインストールし、次いでＵＥへベアラサービス除去受容メッセージを返し、ＵＥによって始動されたベアラサービス除去要求を受容し、後続ステップであるベアラサービス削除フローを継続する。

先行技術においては、ＡＦは、アプリケーション／サービスデータフローの課金情報を、ＣＲＦが課金ルールを選択するための課金関連入力情報としてＣＲＦへ送信する。次いで、本発明において提供される方法では、ＡＦは、アプリケーション／サービスデータフローの課金情報を、ＣＲＦが動的イベントトリガを動的にセットするための入力情報としてＣＲＦへ送信する。

図８は、本発明の実施形態２を例示する概略図である。図８に示されるように、ＣＲＦがＴＰＦへ動的イベントトリガを発行するための本発明における実行手順は、下記のステップを含む。

ステップ８０１：ＣＲＦは、所定の内部又は外部トリガイベントを受信する。例えば、ＡＦは、認可されたアクティビティをユーザに提供する。あるユーザによってアクセスされたこのＡＦの所定のサービスのデータフローが設定値に到達すれば、このサービスに対する上記ユーザのその後の課金レートは低減される。この場合、所定のサービスフィルタのデータフローが設定値に到達したときに、ＡＦは、後続のデータフローに関しては課金情報統計を考慮して有利な課金レートを採用するようにＣＲＦに要求する。或いは、ユーザがこのＡＦの所定のサービスにアクセスしている持続時間が設定値に到達すれば、このサービスに対する上記ユーザのその後の課金レートは低減される。この場合、所定のサービスフィルタが使用されている持続時間が設定値に達したときに、ＡＦは、後続のデータフローに関しては課金情報統計を実行して有利な課金レートを採用するようにＣＲＦに要求する。

ステップ８０２：ＣＲＦは、例えば、所定のサービスフィルタのデータフローが設定値に到達したとき、若しくは所定のサービスフィルタが設定されたタイムスパンに渡って使用されたとき等の動的イベントトリガをセットする。さらに、ＣＲＦは、ＴＰＦによって供給されるユーザ／端末情報、ベアラサービスの特性及びネットワーク情報等、その時点で取得されている情報に従って、適切な課金ルールを選択してもよい。

ステップ８０３：ＣＲＦは動的イベントトリガの現在のリストを搬送する動的イベント報告要求をＴＰＦへ送信し、ＴＰＦにその動的イベントトリガの発生条件が満たされたときにＣＲＦからの課金ルールを要求するように求める。

ステップ８０４：ＣＲＦはＴＰＦへ課金ルール供給を送信する。この課金ルール供給は、その時点で選択されている課金ルールを搬送する。このステップは、任意選択である。

ステップ８０５：ＴＰＦはＣＲＦによってセットされた動的イベントトリガの現在のリストを受信し、この動的イベントトリガリストを格納する。ＴＰＦが課金ルール供給をも受信すれば、ＴＰＦはＣＲＦによって選択された課金ルールに従って新しい課金ルールをインストールし、若しくは元の課金ルールを削除し、若しくは元の課金ルールを削除しながら新しい課金ルールをインストールする。

ステップ８０６：しばらくすると、ＴＰＦは動的イベントトリガの発生を監視し、ＣＲＦへ課金ルール要求を送信する。この課金ルール要求は、動的イベントトリガの発生インジケータを搬送する。

ステップ８０７乃至８０８：ＣＲＦは、課金ルール要求を受信後、この動的イベントトリガの発生インジケータに従ってどの動的イベントトリガがこの課金ルール要求をトリガしているかを確認する。例えば、このイベントは、所定のサービスフィルタのデータフローが設定値に到達するというイベントであっても、所定のサービスフィルタが設定されたタイムスパンに渡って使用されたというイベントであってもよい。次いでＣＲＦは、この動的イベントトリガに従って適切な課金ルールを選択し、ＴＰＦへ課金ルール供給を送信する。この課金ルール供給は、選択された課金ルールを搬送してもよい。

ステップ８０９：ＴＰＦは、課金ルール供給を受信後、ＣＲＦによって選択された課金ルールに従って新しい課金ルールをインストールし、若しくは元の課金ルールを削除し、若しくは元の課金ルールを削除しながら新しい課金ルールをインストールする。

さらに、ＣＲＦはまた、ユーザのクレジットに関してＯＣＳにより送信される課金関連入力情報に従って動的イベントトリガを動的にセットしてもよい。対応するフローは基本的に上述のフローと同じものであり、さらなる説明は省略する。

要するに、上述の説明は本発明の好適な実施形態であるに過ぎず、本発明の保護範囲を限定するものとして解釈されるべきではない。

Claims

パケットデータサービスの課金を制御するための方法であって、
トラフィックプレーン機能（ＴＰＦ）によって、課金ルール機能（ＣＲＦ）から少なくとも１つのイベントトリガを受信するステップと、
前記ＴＰＦによって、前記少なくとも１つのイベントトリガを監視するステップと、
前記少なくとも１つのイベントトリガのうちのいずれかの発生条件が満たされたとき、前記ＴＰＦから前記ＣＲＦへ課金ルール要求を送信するステップと、
前記ＣＲＦにより、課金ルール供給手順により課金ルールを供給することにより前記課金ルール要求に応答するステップとを含むパケットデータサービスの課金制御方法。
前記少なくとも１つのイベントトリガは、前記ＣＲＦによりセットされ、ベアラ修正要求を含む請求項１記載のパケットデータサービスの課金制御方法。
前記ＴＰＦにより、前記ＣＲＦから受信される前記少なくとも１つのイベントトリガを格納するステップをさらに含む請求項２記載のパケットデータサービスの課金制御方法。
前記ＴＰＦから前記ＣＲＦに送信される前記課金ルール要求は、発生条件を満たしたイベントトリガを示すイベント識別子を含む請求項１記載のパケットデータサービスの課金制御方法。
前記課金ルール供給手順による課金ルールは、前記発生条件を満たしたイベントトリガに従って供給される請求項４記載のパケットデータサービスの課金制御方法。
前記少なくとも１つのイベントトリガは、前記ＣＲＦ自体に格納された情報に従って、又は、前記ＴＰＦによって供給される課金関連入力情報に従ってセットされ、前記課金関連入力情報は、加入者及びＵＥに関連した情報と、ベアラ特性情報と、ネットワーク情報とのうちの少なくとも１つを含む請求項１記載のパケットデータサービスの課金制御方法。
前記少なくとも１つのイベントトリガは、前記ＣＲＦによってセットされ、サービス側汎用パケット無線サービスサポートノード（ＳＧＳＮ）の変更、公衆陸上移動網（ＰＬＭＮ）の変更、無線アクセス技術（ＲＡＴ）型の変更、トラフィックフローテンプレート（ＴＦＴ）の変更、及びＱｏＳの変更のうちの少なくとも１つを含む請求項１記載のパケットデータサービスの課金制御方法。