JP4482030B2 - パケットデータフローの課金に基づく再認証の処理方法 - Google Patents

Description

本発明はパケットデータの課金分野に関し、特にパケットデータフローの課金に基づく再認証の処理方法に関する。

パケットデータサービスの幅広い応用に伴い、パケットデータサービスに対する正しく且つ合理的な課金処理の方法が運営側に関心される問題になっている。

図１はパケットデータプロトコルコンテキスト（ＰＤＰ Ｃｏｎｔｅｘｔ，Ｐａｃｋｅｔ Ｄａｔａ Ｐｒｏｔｏｃｏｌ Ｃｏｎｔｅｘｔ）のアクティブ、データ伝送、非アクティブのフローチャートを示す図である。図１に示すように、汎用パケット無線サービス（ＧＰＲＳ，Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ）において、ＰＤＰ Ｃｏｎｔｅｘｔをアクティブにし、外部パケットデータネットワーク（ＰＤＮ，Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ）とデータのやりとりを行い、該ＰＤＰ Ｃｏｎｔｅｘｔを非アクティブにする実現プロセスは以下のステップを含む。

ステップ１０１で、移動端末（ＭＳ）はサービングＧＰＲＳサポートノード（ＳＧＳＮ，Ｓｅｒｖｉｎｇ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ）へＰＤＰ Ｃｏｎｔｅｘｔアクティブ要求（Ａｃｔｉｖａｔｅ ＰＤＰ Ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔ）を送信し、該Ａｃｔｉｖａｔｅ ＰＤＰ Ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔにはネットワーク層サービスアクセスポイント識別子（ＮＳＡＰＩ，Ｎｅｔｗｏｒｋ Ｌａｙｅｒ Ｓｅｒｖｉｃｅ Ａｃｃｅｓｓ Ｐｏｉｎｔ Ｉｄｅｎｔｉｆｉｅｒ）、ＰＤＰタイプ、アクセスポイントネーム（ＡＰＮ，Ａｃｃｅｓｓ Ｐｏｉｎｔ Ｎａｍｅ）、要求するサービス品質（ＱｏＳ）のパラメータ、トランザクション識別子（ＴＩ，Ｔｒａｎｓａｃｔｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ）などの情報が付けられている。ここで、ＮＳＡＰＩは、ＳＧＳＮとゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ，Ｇａｔｅｗａｙ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ）の間で、トンネル識別子（ＴＩＤ，Ｔｕｎｎｅｌ Ｉｄｅｎｔｉｆｉｅｒ）の構成部分としてＰＤＰ Ｃｏｎｔｅｘｔの識別に用いられる。ＰＤＰタイプは、ピアツーピアプロトコル（ＰＰＰ，Ｐｅｅｒ−Ｐｅｅｒ Ｐｒｏｔｏｃｏｌ）タイプ、インターネットプロトコル（ＩＰ，Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）タイプなどを含む。ＡＰＮについては、ＭＳによりＳＧＳＮに提供されることができ、ＳＧＳＮはＡＰＮに基づいて相応のＧＧＳＮにアドレッシング（ａｄｄｒｅｓｓｉｎｇ）し、ＧＧＳＮはＡＰＮに基づいてＭＳのアクセスしようとする外部ネットワークを決定する。ＭＳがＡＰＮをＳＧＳＮに提供しないことも可能であり、この場合、ＳＧＳＮにてＭＳユーザの契約情報に基づいてデフォルトＡＰＮを選択する。ＱｏＳパラメータは、ＭＳに指定されたパケットデータサービスの達成する必要な品質要求である。ＴＩは、あるＰＤＰ ｃｏｎｔｅｘｔの識別のためにＭＳに用いられるものである。

ステップ１０２で、Ａｃｔｉｖａｔｅ ＰＤＰ Ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔを受信したＳＧＳＮは、ＭＳとセキュリティ検査及び暗号化を行い、該ステップはオプションである。

ステップ１０３で、ＳＧＳＮはＡＰＮに基づいてＧＧＳＮのアドレス情報を解析し、ＳＧＳＮがＡＰＮに基づいてＧＧＳＮのアドレス情報を解析できる場合、ＰＤＰ ＣｏｎｔｅｘｔのためにＴＥＩＤが確立され、該ＴＥＩＤはＩＭＳＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ）とＮＳＡＰＩの組合せであることができる。その後、ＳＧＳＮはＧＧＳＮへＰＤＰ Ｃｏｎｔｅｘｔ確立要求（Ｃｒｅａｔｅ ＰＤＰ Ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔ）を送信し、該ＰＤＰ Ｃｏｎｔｅｘｔ確立要求にはＰＤＰタイプ、ＰＤＰアドレス、ＡＰＮ、ＱｏＳパラメータ、ＴＥＩＤ、選択モードなどが付けられている。ここで、ＰＤＰアドレスはＭＳのＩＰアドレスであることができ、ＰＤＰアドレスはオプションである。ＰＤＰ Ｃｏｎｔｅｘｔ確立要求にＰＤＰアドレスが付けられないこともでき、この場合、後続の処理プロセスにおいて、ＧＧＳＮにてＭＳにＩＰアドレスを割り当てることもでき、最終にＭＳと接続を確立するＰＤＮにてＭＳにＩＰアドレスを割り当てることもできる。選択モードとはＡＰＮの選択モード、即ち、ＡＰＮがＭＳによって選定されるか、それともＳＧＳＮによって選定されるかを指すものである。ＳＧＳＮがＡＰＮに基づいてＧＧＳＮのアドレス情報を解析できない場合、ＳＧＳＮはＭＳから開始されたＰＤＰ Ｃｏｎｔｅｘｔアクティブ要求を拒否する。

ステップ１０４で、ＰＤＰ Ｃｏｎｔｅｘｔ確立要求を受信したＧＧＳＮは、ＡＰＮに基づいて外部ＰＤＮを決定してから、課金識別子（Ｃｈａｒｇｉｎｇ ＩＤ）を割り当て、課金を起動し、且つＱｏＳを協議（Ｃｃｏｎｆｅｒ）する。ＧＧＳＮはＱｏＳパラメータのサービス品質要求を満足できる場合、ＳＧＳＮへＰＤＰ Ｃｏｎｔｅｘｔ確立応答（Ｃｒｅａｔｅ ＰＤＰ Ｃｏｎｔｅｘｔ Ｒｅｓｐｏｎｓｅ）を返信し、該ＰＤＰ Ｃｏｎｔｅｘｔ確立応答にはＴＥＩＤ、ＰＤＰアドレス、バックボーンベアラ（Ｂａｃｋｂｏｎｅ Ｂｅａｒｅｒ）プロトコル、協議して決定されたＱｏＳパラメータ、Ｃｈａｒｇｉｎｇ ＩＤなどの情報が付けられている。ＧＧＳＮがＱｏＳパラメータのサービス品質要求を満足できない場合、ＧＧＳＮはＳＧＳＮから開始されたＰＤＰ Ｃｏｎｔｅｘｔ確立要求を拒否し、その後、ＳＧＳＮにてＭＳから開始されたＰＤＰ Ｃｏｎｔｅｘｔアクティブ要求を拒否する。

ステップ１０５で、ＰＤＰ Ｃｏｎｔｅｘｔ確立応答を受信したＳＧＳＮは、ＰＤＰ Ｃｏｎｔｅｘｔの識別のためのＮＳＡＰＩとＧＧＳＮアドレス情報をＰＤＰ Ｃｏｎｔｅｘｔに挿入し、且つ協議して決定されたＱｏＳパラメータに基づいて無線優先権を選択してから、ＭＳへＰＤＰ Ｃｏｎｔｅｘｔアクティブ応答（Ａｃｔｉｖａｔｅ ＰＤＰ Ｃｏｎｔｅｘｔ Ａｃｃｅｐｔ）を返信し、該ＰＤＰ Ｃｏｎｔｅｘｔアクティブ応答にはＰＤＰタイプ、ＰＤＰアドレス、ＴＩ、協議して決定されたＱｏＳパラメータ、無線優先権、ＰＤＰコンフィギュレーションオプション（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｏｐｔｉｏｎｓ）などの情報が付けられている。ＳＧＳＮは課金を起動する。ＰＤＰ Ｃｏｎｔｅｘｔアクティブ応答がＭＳに受信された場合、ＭＳとＧＧＳＮとの直接ルーティングが既に確立されて、パケットデータの伝送が可能になっている。

ステップ１０６で、ＭＳはＳＧＳＮ、ＧＧＳＮとＰＤＮを介してパケットデータのやりとりを実施する。

ステップ１０７で、パケットデータのやりとりが完了された後、ＭＳはＳＧＳＮへＰＤＰ Ｃｏｎｔｅｘｔ非アクティブ要求（Ｄｅａｃｔｉｖａｔｅ ＰＤＰ Ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔ）を送信し、該ＰＤＰ Ｃｏｎｔｅｘｔ非アクティブ要求にはＴＩが付けられている。

ステップ１０８で、ＰＤＰ Ｃｏｎｔｅｘｔ非アクティブ要求を受信したＳＧＳＮは、ＭＳとセキュリティ検査及び暗号化を行い、該ステップはオプションである。

ステップ１０９〜１１１で、ＳＧＳＮはＧＧＳＮへＰＤＰ Ｃｏｎｔｅｘｔ削除要求（Ｄｅｌｅｔｅ ＰＤＰ Ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔ）を送信し、該ＰＤＰ Ｃｏｎｔｅｘｔ削除要求にはＴＥＩＤが付けられている。ＰＤＰ Ｃｏｎｔｅｘｔ削除要求を受信したＧＧＳＮは、ＭＳに対する課金を終了し、ＴＥＩＤに対応するＰＤＰ Ｃｏｎｔｅｘｔを削除してから、ＳＧＳＮへＰＤＰ Ｃｏｎｔｅｘｔ削除応答（Ｄｅｌｅｔｅ ＰＤＰ Ｃｏｎｔｅｘｔ Ｒｅｓｐｏｎｓｅ）を送信し、該ＰＤＰ Ｃｏｎｔｅｘｔ削除応答にはＴＥＩＤが付けられている。ＰＤＰ Ｃｏｎｔｅｘｔ削除応答を受信したＳＧＳＮは、ＭＳに対する課金を終了し、ＴＥＩＤに対応するＰＤＰ Ｃｏｎｔｅｘｔを削除してから、ＭＳへＰＤＰ Ｃｏｎｔｅｘｔ非アクティブ応答（Ｄｅａｃｔｉｖａｔｅ ＰＤＰ Ｃｏｎｔｅｘｔ Ｒｅｓｐｏｎｓｅ）を送信し、該ＰＤＰ Ｃｏｎｔｅｘｔ非アクティブ応答にはＴＩが付けられている。ＰＤＰ Ｃｏｎｔｅｘｔ非アクティブ応答を受信したＭＳは、ＴＩに対応するＰＤＰ Ｃｏｎｔｅｘｔを削除する。

図１に説明した実現プロセスからわかるように、従来のＧＰＲＳ課金システムにおいて、課金のスタートポイントがＰＤＰ Ｃｏｎｔｅｘｔのアクティブ時に設定され、課金のエンドポイントがＰＤＰ Ｃｏｎｔｅｘｔの削除時に設定されるため、ＰＤＰ Ｃｏｎｔｅｘｔ伝送のデータトラフィックに基づいて、又はＰＤＰ Ｃｏｎｔｅｘｔがアクティブ状態にある時間の長さに基づいて課金を行うことしかできない。しかしながら、実際の応用において、ＭＳとＰＤＮがデータやりとりを行った後、該ＭＳは一つのアクティブにしたＰＤＰ Ｃｏｎｔｅｘｔに基づいて多種のサービスを行うことができる。即ち、電子メール（Ｅｍａｉｌ）の受送信サービス、ワイヤレスアプリケーションプロトコル（ＷＡＰ，Ｗｉｒｅｌｅｓｓ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）に基づくブラウザサービス、フェイルトランスファープロトコル（ＦＴＰ，Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）に基づくフェイル伝送などのような多種のサービスがＰＤＮにより提供できる場合、ＭＳと該ＰＤＮが伝送チャネルを確立した後、該ＰＤＮの提供できる各種サービスは一つのアクティブにしたＰＤＰ Ｃｏｎｔｅｘｔによって搭載されることができる。しかし、運営側は各種サービスの課金モードに対して異なる課金方式を採用する可能性がある。例えば、Ｅｍａｉｌ受送信サービスに対してはＥｍａｉｌ受信と送信イベントのトリガー回数に基づいて課金することができ、ＷＡＰブラウザサービスに対してはトラフィックに基づいて課金することができ、フェイル伝送サービスに対してはトラフィックに基づいて課金することもできるが、ＷＡＰブラウザサービスのレートとフェイル伝送サービスのレートは異なっている。このように、従来のＧＰＲＳ課金システムによっては、同一ＰＤＰ Ｃｏｎｔｅｘｔに搭載された異なるサービスに対して区別して課金することが不可能である。

上記の情況に対して、現在、第３世代パートナーシッププロトコル（３ＧＰＰ，Ｔｈｅ ３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）ではＩＰフローに基づく課金（ＦＢＣ，Ｆｌｏｗ Ｂａｓｅｄ Ｃｈａｒｇｉｎｇ）の実現方法について検討している。一つのパケットデータサービスにとって、ＭＳユーザが該サービスを使用する場合、伝送と受信された全てのＩＰフロー（ＩＰ Ｆｌｏｗ）はＩＰパケット（ＩＰ ｐａｃｋｅｔ）であることができ、サービスデータフロー（Ｓｅｒｖｉｃｅ Ｄａｔａ Ｆｌｏｗ）と総称される。即ち、サービスデータフローは複数のＩＰフローからなる集合であり、そのため、ＩＰフローに基づく課金はあるサービスデータフローの資源占用情況を確実に反映することができる。ＩＰフローに基づく課金は、同一ＰＤＰ Ｃｏｎｔｅｘｔに搭載された異なるサービスのＩＰフローをふるいと類似しているいくらかのフィルターを通じてそれぞれふるって選別してから、異なるフィルターによってフィルタリングされたＩＰフローに対してそれぞれ課金することで、異なるサービスデータフローに対してそれぞれ課金する目的を達成していると認められる。このように、ＩＰフローに基づく課金の粒状性（ｇｒａｎｕｌａｒｉｔｙ）は一つのＰＤＰ Ｃｏｎｔｅｘｔに基づく課金の粒状性より遥かに小さい。粒状性はふるいの穴のサイズと認められる。一つのＰＤＰ Ｃｏｎｔｅｘｔに基づく課金の粒状性について、一つのＰＤＰ Ｃｏｎｔｅｘｔが一つのふるいの穴であれば、ＩＰフローに基づく課金の粒状性については、一つのＩＰサービスデータフローが一つのふるいの穴であり、つまり、一つのＰＤＰ Ｃｏｎｔｅｘｔには複数のふるいの穴が含まれる。そのため、ＩＰフローに基づく課金は運営側又はサービスプロバイダーに一つのＰＤＰ Ｃｏｎｔｅｘｔに基づく課金より更に豊かな課金手段を提供することができる。

３ＧＰＰではＦＢＣのシステムアーキテクチャー、機能要求及びメッセージやりとりプロセスなどの部分がすべて説明されている。オンライン課金をサポートするＦＢＣシステムアーキテクチャーは図２Ａに示すようである。そのうち、オンライン課金システム（ＯＣＳ，Ｏｎｌｉｎｅ Ｃｈａｒｇｉｎｇ Ｓｙｓｔｅｍ）２０６は、ＣＡＭＥＬ（Ｃｕｓｔｏｍｉｓｅｄ Ａｐｐｌｉｃａｔｉｏｎ ｆｏｒ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ Ｅｎｈａｎｃｅｄ Ｌｏｇｉｃ）に基づくサービスコントロールポイント（ＳＣＰ，Ｓｅｒｖｉｃｅ Ｃｏｎｔｒｏｌ Ｐｏｉｎｔ）２０１とサービスデータフローの課金に基づくクレジットコントロールファンクション（ＣＣＦ，Ｓｅｒｖｉｃｅ Ｄａｔａ Ｆｌｏｗ Ｂａｓｅｄ Ｃｒｅｄｉｔ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）２０２とを備える。ＣＣＦ ２０２はＲｙインターフェースによりサービスデータフローの課金に基づく課金ルールファンクション（ＣＲＦ，Ｓｅｒｖｉｃｅ Ｄａｔａ Ｆｌｏｗ Ｂａｓｅｄ Ｃｈａｒｇｉｎｇ Ｒｕｌｅ Ｆｕｎｃｔｉｏｎ）２０３と相互接続され、ＣＲＦ ２０３はＲｘインターフェースによりアプリケーションファンクション（ＡＦ，Ａｐｐｌｉｃａｔｉｏｎ Ｆｕｎｃｔｉｏｎ）２０４と相互接続され、ＣＲＦ ２０３はＧｘインターフェースによりトラフィックプランファンクション（ＴＰＦ，Ｔｒａｆｆｉｃ Ｐｌａｎｅ Ｆｕｎｃｔｉｏｎ）２０５と相互接続され、ＣＣＦ ２０２はＧｙインターフェースによりＴＰＦ ２０５と相互接続されている。

オフライン課金をサポートするＦＢＣシステムアーキテクチャーは図２Ｂに示すように、ＣＲＦ ２０３がＲｘインターフェースによりＡＦ ２０４と相互接続され、ＣＲＦ ２０３がＧｘインターフェースによりＴＰＦ ２０５と相互接続され、ＴＰＦ ２０５がＧｚインターフェースにより課金ゲートウェイファンクション（ＣＧＦ，Ｃｈａｒｇｉｎｇ Ｇａｔｅｗａｙ Ｆｕｎｃｔｉｏｎ）２０７及び課金コレクションファンクション（ＣＣＦ，Ｃｈａｒｇｉｎｇ Ｃｏｌｌｅｃｔｉｏｎ Ｆｕｎｃｔｉｏｎ）２０８とそれぞれ相互接続されている。

ＴＰＦ ２０５はＩＰフローを搭載し、ＩＰフローのベアラが確立されるとき、ＴＰＦ ２０５はＧｘインターフェースによりＣＲＦ ２０３へ課金ルール要求を送信し、該課金ルール要求にはユーザとＭＳに関連する情報、ベアラ特性及びネットワークに関連する情報などが付けられている。ここで、ユーザとＭＳに関連する情報はＭＳＩＳＤＮ（Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ ＩＳＤＮ）、ＩＭＳＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ）などであってよく、ネットワークに関連する情報はＭＮＣ（Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ Ｃｏｄｅ）、ＭＣＣ（Ｍｏｂｉｌｅ Ｃｏｕｎｔｒｙ Ｃｏｄｅ）などであってよい。また、ＩＰフローの伝送プロセスにおいて、ベアラに対して修正を行うため、例えば、ＱｏＳパラメータに対して再協議を行うため、ユーザが使用する同一サービスのＱｏＳパラメータが異なっている場合、課金ルールが異なる可能性があり、例えばＱｏＳパラメータが下降する場合相応のレートも下降する。この場合、ＴＰＦ ２０５は、ベアラ修正時にＣＲＦ ２０３へ課金ルール要求を再送信し、新しい課金ルールを要求することができる。ＣＲＦ ２０３はＴＰＦ ２０５から提供された上記入力情報に基づいて適当な課金ルールを選択し、且つ選定された課金ルールをＴＰＦ ２０５へ返信し、課金ルールには課金メカニズム、課金タイプ、課金キー、サービスデータフローフィルター、課金ルール優先度などの情報が含まれている。ここで、課金メカニズムは、オンライン課金を採用するか又はオフライン課金を採用するのものであってよい。課金タイプは、時間長さに基づく課金又はデータフローに基づく課金であってよい。課金キーは、課金レートに関連するパラメータであり、ＣＲＦ ２０３は課金レートをＴＰＦ ２０５に直接に提供せずに、ＴＰＦ ２０５にただ課金レートに関連するパラメータを提供することができる。サービスデータフィルターは、どのＩＰフローに対してフィルタリングを行うかをＴＰＦ ２０５に指示するものであり、その後、ＴＰＦ ２０５は課金ルールに従ってフィルタリングしたＩＰフローに対して課金を行う。サービスデータフィルターは、ＩＰクインティプル（Ｑｕｉｎｔｕｐｌｅ）を含むことができ、ＩＰクインティプルには送り元／宛先ＩＰアドレス、送り元／宛先ポート番号（Ｐｏｒｔ Ｎｕｍｂｅｒ）、プロトコル識別子（Ｐｒｏｔｏｃｏｌ ＩＤ）などの情報が含まれていい。例えば、ＴＰＦ ２０５は、送り元アドレスが１０．０．０．１であり、宛先アドレスが１０．０．０．２であり、送り元／宛先ポート番号が２０であり、プロトコルタイプがトランスファコントロールプロトコル（ＴＣＰ）であるＩＰフローに対してフィルタリングを行うようにＣＲＦ ２０３から指示され、課金ルールに従ってフィルタリングされたＩＰフローに対して課金を行う。

ＣＲＦ ２０３はイベントトリガー（Ｅｖｅｎｔ Ｔｒｉｇｇｅｒ）をＴＰＦ ２０５へ提供することで、特定イベントの発生時新しい課金ルールをＣＲＦ ２０５に要求するようにＴＰＦ ２０５に要求することができる。例えば、ＴＰＦ ２０５は、あるベアラの修正イベントの発生時新しい課金ルールをＣＲＦ ２０３に要求するようにＣＲＦ ２０３から要求される。

ＣＲＦ ２０３はＴＰＦ ２０５から提供された入力情報に基づいて適当な課金ルールを選択する以外に、ＡＦ ２０４又はＯＣＳ ２０６の入力情報に基づいて適当な課金ルールを選択することもでき、例えば、ユーザの現在使用しているサービスタイプがＡＦ ２０４からＣＲＦ ２０３に通知され、ＣＲＦ ２０３は該サービスタイプに基づいて相応の課金ルールを選択する。

ＯＣＳ ２０６はＳＣＰ ２０１とＣＣＦ（Ｓｅｒｖｉｃｅ Ｄａｔａ Ｆｌｏｗ Ｂａｓｅｄ Ｃｒｅｄｉｔ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）２０２という二つのファンクションからなり、ここで、ＣＣＦ（Ｓｅｒｖｉｃｅ Ｄａｔａ Ｆｌｏｗ Ｂａｓｅｄ Ｃｒｅｄｉｔ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）２０２はクレジットコントロールを実行するファンクションであり、オンライン課金システムのみに応用され、従来のＯＣＳ ２０６に新しい機能を追加することで実現されることができる。オンライン課金のプロセスにおいて、ＣＣＦ（Ｓｅｒｖｉｃｅ Ｄａｔａ Ｆｌｏｗ Ｂａｓｅｄ Ｃｒｅｄｉｔ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）２０２はユーザのクレジットに対して管理とコントロールを行い、ユーザがサービスを使用する場合、ＣＣＦ（Ｓｅｒｖｉｃｅ Ｄａｔａ Ｆｌｏｗ Ｂａｓｅｄ Ｃｒｅｄｉｔ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）２０２は該ユーザのクレジットプール（ｐｏｏｌ）内のクレジットに対して認証を行い、且つユーザが使用できるクレジットをＧｙインターフェースによりＴＰＦ ２０５へ送信する。

また、ＯＣＳ ２０６は、再認証トリガー（Ｒｅ−ａｕｔｈｏｒｉｓａｔｉｏｎ ｔｒｉｇｇｅｒｓ）が発生する場合それを報告するようにＴＰＦ ２０５に要求することができる。その後、ＯＣＳ ２０６はＴＰＦ ２０５から報告された相応の再認証トリガーに従ってユーザに対して再認証を行う。ユーザのクレジットを再計算する可能性もある。例えば、ＯＣＳ ２０６からＴＰＦ ２０５へ提供されたユーザクレジットの使用が終わった場合、ＴＰＦ ２０５は再認証トリガー内のクレジット期限切れ許可イベントに従って、それの許可するユーザクレジット使用の期限切れイベントの発生をＯＣＳ ２０６に報告する必要であり、ＯＣＳ ２０６はユーザの余剰アカウント情報に基づいて、ユーザの使用できるクレジットに対して再計算を行う。例えば、領域に分けて課金する場合、ＯＣＳ ２０６はユーザの現在の位置によって課金レートを決定し、且つ該課金レートに基づいてユーザのクレジットを計算する。ユーザが別の位置に移動する場合で、ＳＧＳＮが変化する場合、ＴＰＦ ２０５は再認証トリガー内のＳＧＳＮ変化イベントに従って、ＳＧＳＮ変化イベントの発生をＯＣＳ ２０６に報告する必要であり、ＯＣＳ ２０６はユーザの更新された後の現在の位置によって課金レートを再決定し、且つユーザクレジットを再計算する。例えば、ＯＣＳ ２０６がユーザの使用するサービスの現在ＱｏＳパラメータによって課金レートを決定する場合で、ユーザがＱｏＳパラメータに対して修正を行う場合、ＴＰＦ ２０５は再認証トリガー内のベアラ修正イベントに従って、ベアラ修正イベントの発生をＯＣＳ ２０６に報告する必要であり、ＯＣＳ ２０６はユーザに修正されたＱｏＳパラメータによって課金レートを決定し、且つユーザのクレジットを再計算する。標準に定義された再認証トリガーには、クレジット期限切れ許可（ｃｒｅｄｉｔ ａｕｔｈｏｒｉｚａｔｉｏｎ ｌｉｆｅｔｉｍｅ ｅｘｐｉｒｙ）イベント、ユーザアイドルタイムアウト（ｉｄｌｅ ｔｉｍｅｏｕｔ）イベント、課金ルール変化（ｃｈａｒｇｉｎｇ ｒｕｌｅ ｉｓ ｃｈａｎｇｅｄ）イベントが含まれることができ、またＳＧＳＮ変化（ＳＧＳＮ ｃｈａｎｇｅ）イベント、ＱｏＳパラメータ変化（ＱｏＳ ｃｈａｎｇｅｓ）イベント、無線アクセス技術（ＲＡＴ）タイプ変化（ＲＡＴ ｔｙｐｅ ｃｈａｎｇｅ）イベントなどのイベントも含まれることができる。

ＧＰＲＳネットワークに対応する場合、ＴＰＦ ２０５はＧＧＳＮであり、ＡＦはＰＤＮ内の一つのサービスゲートウェイ又はサービスサーバであり、ＣＲＦ ２０３は新しく追加された論理エンティティである。ＴＰＦ ２０５は課金ルールの実行ポイントであり、ＣＲＦ ２０３は課金ルールのコントロールポイントである。

現在、３ＧＰＰに定義された、ベアラ確立時、オンライン課金の場合で、ＴＰＦがＣＲＦに課金ルールを要求する処理プロセスは図３に示すようである。

ステップ３０１で、ユーザ設備（ＵＥ）はＴＰＦへベアラ確立要求（Ｅｓｔａｂｌｉｓｈ Ｂｅａｒｅｒ Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ）を送信し、ＧＰＲＳネットワークでは、Ｃｒｅａｔｅ ＰＤＰ Ｃｏｎｔｅｘｔ ＲｅｑｕｅｓｔがＧＧＳＮに受信される。

ステップ３０２で、ベアラ確立要求を受信したＴＰＦは、ＣＲＦへ課金ルール要求（Ｒｅｑｕｅｓｔ Ｃｈａｒｇｉｎｇ Ｒｕｌｅｓ）を送信し、該課金ルール要求にはＣＲＦに課金ルールを決定させるための入力情報が付けられている。

ステップ３０３〜３０４で、課金ルール要求を受信したＣＲＦは、該課金ルール要求に付けられている入力情報に基づいて、またはＡＦから提供された関連の入力情報に基づいて、適当な課金ルールを選択してから、ＴＰＦへ提供課金ルール（Ｐｒｏｖｉｓｉｏｎ Ｃｈａｒｇｉｎｇ Ｒｕｌｅｓ）を返信し、該提供課金ルールには選定された課金ルールと課金ルール操作指示が付けられることができる。

ステップ３０５で、提供課金ルールを受信したＴＰＦは、課金ルール操作指示に従ってＣＲＦに選定された課金ルールに対して相応の操作を行う。

ステップ３０６で、ＴＰＦはクレジット要求をＯＣＳへ送信して、ユーザのクレジットをＯＣＳに要求する。

ステップ３０７で、クレジット要求を受信したＯＣＳは、ユーザのクレジットを決定してから、クレジット応答（Ｃｒｅｄｉｔ Ｒｅｓｐｏｎｓｅ）をＴＰＦへ返信する。ユーザのクレジットがＯＣＳによって決定された場合、該クレジット応答にはユーザのクレジットが付けられ、ユーザのクレジットがＯＣＳによって決定されなかった場合、該クレジット応答にはエラーの原因値が付けられることができる。

ステップ３０８で、クレジット応答を受信したＴＰＦは、ＵＥへベアラ確立応答（Ｅｓｔａｂｌｉｓｈ Ｂｅａｒｅｒ Ｓｅｒｖｉｃｅ Ａｃｃｅｐｔ）を返信し、クレジット応答にユーザのクレジットが付けられている場合、ＴＰＦはＵＥから開始されたベアラ確立要求を受け入れ、且つ後続のベアラ確立フローを継続し、クレジット応答にユーザのクレジットが付けられていない場合、ＴＰＦはＵＥから開始されたベアラ確立要求を拒否する。

オンライン課金の場合にとって、再認証がＴＰＦからＯＣＳへ要求されるプロセスはベアラ修正によりトリガーされ、具体的な実現プロセスは図４に示すようである。

ステップ４０１で、ＵＥはＴＰＦへベアラ修正要求（Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ）を送信し、ＧＰＲＳネットワークでは、ＰＤＰ Ｃｏｎｔｅｘｔ更新要求がＧＧＳＮに受信される。

ステップ４０２で、ベアラ修正要求を受信したＴＰＦは、ベアラ修正イベントと予め記憶した再認証トリガーを比較して、マッチングできる場合、ステップ４０３に進み、そうでない場合、現在の再認証のプロセスを終了する。

ステップ４０３で、ＴＰＦはＯＣＳへクレジットコントロール要求（Ｃｒｅｄｉｔ Ｃｏｎｔｒｏｌ Ｒｅｑｕｅｓｔ）を送信し、該クレジットコントロール要求にはユーザの余剰クレジットと、関連の課金ルール情報が付けられて、ユーザのクレジットを再計算することをＯＣＳに要求する。ＴＰＦからＯＣＳに提供された関連の課金ルール情報はＣＲＦからのであることができる。

ステップ４０４で、クレジットコントロール要求を受信したＯＣＳは、ユーザのクレジットに対して再計算してから、ＴＰＦへクレジットコントロール応答（Ｃｒｅｄｉｔ Ｃｏｎｔｒｏｌ Ａｎｓｗｅｒ）を返信し、ユーザのクレジットがＯＣＳによって計算された場合、該クレジットコントロール応答にはＯＣＳによって再計算されたユーザのクレジットが付けられ、ユーザのクレジットがＯＣＳによって計算されなかった場合、該クレジット応答にはエラーの原因値が付けられることができる。

ステップ４０５で、クレジットコントロール応答を受信したＴＰＦは、ベアラ修正応答（Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｓｅｒｖｉｃｅ Ａｃｃｅｐｔ）をＵＥへ返信し、クレジットコントロール応答にユーザのクレジットが付けられている場合、ＴＰＦはＵＥから開始されたベアラ修正要求を受け入れ、且つ後続のベアラ修正プロセスを継続し、クレジットコントロール応答にユーザのクレジットが付けられていない場合、ＴＰＦはＵＥから開始されたベアラ修正要求を拒否する。

目下、標準では、オンライン課金の場合、ＴＰＦは、ベアラ修正時、再認証トリガーの発生に従って再認証プロセスをＯＣＳへ開始し、ユーザのクレジットを再計算し且つＴＰＦへ返信することをＯＣＳに要求することができると定義されているが、現在の標準においてＴＰＦの再認証トリガーのソースが提出されていないため、再認証プロセスの実現上の不確実性を招く。

本発明は上記に鑑みてなされたものであって、再認証プロセスの実現を明確にする、パケットデータフローの課金に基づく再認証の処理方法を提供することを目的とする。

上記目的を達成するため、本発明はパケットデータフローの課金に基づく再認証の処理方法を提供する。パケットデータフローの課金に基づく再認証の処理方法であって、ＴＰＦが再認証トリガー情報をモニターするステップと、再認証トリガーの発生がＴＰＦに感知された場合、ＴＰＦ がユーザに対する再認証をＯＣＳに要求するステップとを含む。前記ＴＰＦが再認証トリガー情報をモニターすることは、予めＴＰＦに再認証トリガーを記憶する、ことを含む。前記ＴＰＦが再認証トリガー情報をモニターすることは、ＯＣＳから提供された再認証トリガー情報がＴＰＦに受信される、ことを含む。

前記再認証トリガー情報は、再認証トリガーである。前記ＴＰＦが再認証トリガー情報をモニターすることは、予めＴＰＦに再認証トリガーを記憶し、ＯＣＳから提供された再認証トリガー情報がＴＰＦに受信される、ことを含む。前記再認証トリガー情報は、再認証トリガー識別子、又は再認証トリガー、又は以上の二者の組合せ、又は空白の再認証トリガー情報である。前記再認証トリガー情報は、ベアラ確立時、クレジット応答がＯＣＳからＴＰＦへ返信されるときに提供され、又はベアラ修正時、クレジットコントロール応答がＯＣＳからＴＰＦへ返信されるときに提供される。現在の再認証プロセスをトリガーする再認証トリガーがＴＰＦからＯＳＣへ提供される、ことをさらに含む。ＯＣＳがユーザのクレジットに対して再計算を行い、再計算されたユーザクレジットをＴＰＦへ返信する、ことをさらに含む。

本発明に提出された方法において、予めＴＰＦに再認証トリガーが記憶され、又はＯＣＳによりＴＰＦへ再認証トリガーが提供されて、ＴＰＦはモニターする必要な再認証トリガーを正確に察知でき、再認証トリガーの発生がＴＰＦよりモニターされ、再認証トリガーが発生した場合、ＴＰＦはユーザに対する再認証をＯＣＳに要求し、ＯＣＳはユーザのクレジットに対して再計算を行い、再計算されたユーザクレジットをＴＰＦへ返信する。これで、再認証トリガー提供方式の追加によって、パケットデータフローの課金に基づく再認証プロセスの実現がさらに明確且つクリアされている。また、ＴＰＦはユーザに対する再認証をＯＣＳに要求するとき、現在の再認証プロセスをトリガーする再認証トリガーをＯＣＳへさらに提供することができ、これにより、ＴＰＦとＯＣＳの間における再認証の情報やりとりがさらに合理且つ完璧されている。

本発明の目的、技術方案とメリットを更に明確にするため、以下、図面を参照して本発明を更に詳しく説明する。

本発明において、予めＴＰＦに再認証トリガーが記憶され、又はＯＣＳによってＴＰＦへ再認証トリガーが提供され、ＴＰＦにて再認証トリガーの発生をモニターし、再認証トリガーの発生時、ＯＣＳはユーザに対する再認証をＴＰＦから要求され、ＯＣＳはユーザのクレジットに対して再計算を行い、再計算されたユーザクレジットをＴＰＦへ返信する。

図５は、本発明に係るオンライン課金ベアラの確立時のフローチャートである。図５に示すように、オンライン課金ベアラの確立時の具体的な実現プロセスは以下のステップを含む。
ステップ５０１〜５０６とステップ３０１〜３０６はほぼ同じである。

ステップ５０７で、クレジット要求を受信したＯＣＳは、ユーザのクレジットを決定してから、ＴＰＦへクレジット応答を返信し、ユーザのクレジットがＯＣＳにより決定された場合、該クレジット応答にはユーザのクレジットが付けられ、且つ再認証トリガー情報がさらに付けられて、相応の再認証トリガーの発生をモニターすることをＴＰＦに要求する。ユーザのクレジットがＯＣＳにより決定されなかった場合、該クレジット応答にはエラーの原因値が付けられることができる。本発明の上記再認証トリガー情報は再認証トリガーであることができ、再認証トリガー識別子であることができ、再認証トリガーと再認証トリガー識別子の組合せであることができ、空白であることもできる。

ＴＰＦに再認証トリガーが記憶されていない場合、ＯＣＳからＴＰＦへ提供される再認証トリガー情報は再認証トリガーであり、ＴＰＦはＯＣＳから提供された再認証トリガーの発生をモニターすることを要求される。予めＴＰＦに再認証トリガーが記憶されている場合、再認証トリガー情報は再認証トリガー識別子であることができ、ＴＰＦは相応の識別子に対応する再認証トリガーの発生をモニターすることを要求され、再認証トリガー情報は再認証トリガーと再認証トリガー識別子の組合せであることができ、ＴＰＦはＯＣＳから提供された再認証トリガーと、相応の識別子に対応する再認証トリガーの発生をモニターすることを要求され、再認証トリガー情報は空白であってもよく、ＴＰＦは予めの設定によって、予め記憶された全ての再認証トリガーの発生をモニターすること、又はいかなる再認証トリガーの発生もモニターしないことをＯＣＳから要求されたのを察知する。

ＴＰＦに再認証トリガーが予め記憶されている場合、再認証トリガー情報は再認証トリガーだけであることができ、ＴＰＦは予めの設定によって、ＯＣＳから提供された再認証トリガーと予め記憶された全ての再認証トリガーの発生をモニターすること、又はＯＣＳから提供された再認証トリガーの発生のみをモニターすることをＯＣＳから要求されたのを察知する。

ステップ５０８で、クレジット応答を受信したＴＰＦは、該クレジット応答に再認証トリガー情報が付けられている場合、再認証トリガー情報に基づいて、相応の再認証トリガーの発生をモニターしはじめ、相応の再認証トリガーの発生を感知した場合、ユーザに対する再認証をＯＣＳに要求する。

ステップ５０９とステップ３０８はほぼ同じである。ステップ５０８とステップ５０９の間には明らかな前後順序がない。本発明で、再認証トリガー情報は、クレジット応答に付けられること、または独立のメッセージに付けられることによってＯＣＳからＴＰＦに送信されることができる。

図６は、本発明に係る、ベアラ修正時、再認証がＴＰＦからＯＣＳへ要求される実施例のフローチャートである。図６に示すように、本実施例において、ベアラ修正時、再認証がＴＰＦからＯＣＳへ要求される実現プロセスは以下のステップを含む。

ステップ６０１〜６０２とステップ４０１〜４０２はほぼ同じである。
ステップ６０３で、ＴＰＦはＯＣＳへクレジットコントロール要求（Ｃｒｅｄｉｔ Ｃｏｎｔｒｏｌ Ｒｅｑｕｅｓｔ）を送信し、該クレジットコントロール要求にはユーザの余剰クレジットと、関連の課金ルール情報が付けられて、ユーザのクレジットを再計算することをＯＣＳに要求する。ＴＰＦからＯＣＳに提供される関連の課金ルール情報はＣＲＦからのであることができる。クレジットコントロール要求には現在発生した再認証トリガーがさらに付けられることができ、現在の再認証プロセスをトリガーした具体的な再認証トリガーをＯＣＳに通知することに用いられる。
ステップ６０４〜６０５とステップ４０４〜４０５はほぼ同じである。

図７は、本発明に係る、ベアラ修正時、再認証がＴＰＦからＯＣＳへ要求される他の実施例のフローチャートである。図７に示すように、本実施例において、ベアラ修正時、再認証がＴＰＦからＯＣＳへ要求される実現プロセスは以下のステップを含む。
ステップ７０１〜７０２とステップ４０１〜４０２はほぼ同じである。
ステップ７０３とステップ６０３はほぼ同じである。
ステップ７０４で、クレジットコントロール要求を受信したＯＣＳは、ユーザのクレジットに対して再計算してから、ＴＰＦへクレジットコントロール応答を返信しユーザのクレジットが、ＯＣＳにより計算された場合、該クレジットコントロール応答にはＯＣＳによって再計算されたユーザのクレジットが付けられ、ユーザのクレジットがＯＣＳにより計算されなかった場合、例えば、ユーザクレジットが足りない場合、該クレジット応答にはエラーの原因値が付けられることができる。クレジットコントロール要求には再認証トリガー情報がさらに付けられることができ、ＴＰＦはモニターする再認証トリガーの更新を要求される。

ＴＰＦに再認証トリガーが記憶されていない場合、ＯＣＳからＴＰＦへ提供される再認証トリガー情報は再認証トリガーであり、ＴＰＦはＯＣＳから提供された再認証トリガーの発生をモニターすることを要求される。予めＴＰＦに再認証トリガーが記憶されている場合、再認証トリガー情報は再認証トリガー識別子であることができ、ＴＰＦは相応の識別子に対応する再認証トリガーの発生をモニターすることを要求され、再認証トリガー情報は再認証トリガーと再認証トリガー識別子の組合せであることができ、ＴＰＦはＯＣＳから提供された再認証トリガーと相応の識別子に対応する再認証トリガーの発生をモニターすることを要求され、再認証トリガー情報は空白であることができ、ＴＰＦは予めの設定によって、予め記憶された全ての再認証トリガーの発生をモニターし、又はいかなる再認証トリガーの発生もモニターしないことをＯＣＳから要求されたのを察知する。

ＴＰＦに再認証トリガーが予め記憶されている場合、再認証トリガー情報は再認証トリガーだけであることができ、ＴＰＦは予めの設定によって、ＯＣＳから提供された再認証トリガーと、予め記憶された全ての再認証トリガーの発生をモニターし、又はＯＣＳに提供された再認証トリガーの発生のみをモニターすることをＯＣＳから要求されたのを察知する。

ステップ７０５で、クレジットコントロール応答を受信したＴＰＦは、該クレジットコントロール応答に再認証トリガー情報が付けられている場合、再認証トリガー情報に基づいて、相応の再認証トリガーの発生をモニターしはじめ、相応の再認証トリガーの発生が感知された場合、ユーザに対する再認証をＯＣＳに要求する。

ステップ７０６とステップ４０５はほぼ同じである。
上記は、本発明の好ましい実施例にすぎず、本発明の保護範囲を限定するものではない。本発明の精神と原則内で行われる種々の修正、均等切替、改善などは全て本発明の保護範囲内に含まれるべきである。

ＰＤＰ Ｃｏｎｔｅｘｔアクティブ、データ伝送、非アクティブのフローチャートである。 オンライン課金をサポートするＦＢＣシステムのアーキテクチャである。 オフライン課金をサポートするＦＢＣシステムのアーキテクチャである。 従来の技術に係るオンライン課金ベアラの確立時のフローチャートである。 従来の技術に係る、ベアラ修正時、再認証がＴＰＦからＯＣＳへ要求されるフローチャートである。 本発明に係るオンライン課金ベアラの確立時のフローチャートである。 本発明に係る、ベアラ修正時、再認証がＴＰＦからＯＣＳへ要求される実施例のフローチャートである。 本発明に係る、ベアラ修正時、再認証がＴＰＦからＯＣＳへ要求される他の実施例のフローチャートである。

符号の説明

ＭＳ 移動端末
ＳＧＳＮ サービングＧＰＲＳサポートノード
ＧＧＳＮ ゲートウェイＧＰＲＳサポートノード
ＰＤＮ パケットデータネットワーク

Claims (8)

1. パケットデータフローの課金に基づく再認証の処理方法であって、
   トラフィックプレンファンクション（ＴＰＦ）における少なくとも１つの再認証トリガーを予め記憶するステップまたはオンライン課金システム（ＯＣＳ）から再認証トリガー情報を受信するステップと、
   前記ＴＰＦが少なくとも１つの予め記憶された再認証トリガーまたは再認証トリガー情報に対応する少なくとも１つの再認証トリガーをモニターするステップと、
   再認証トリガーが予め記憶されたまたは再認証トリガー情報に対応することが検出された場合には、前記ＴＰＦが再認証をＯＣＳに要求するステップと、
   を含むことを特徴とするこの方法。
2. 前記再認証トリガー情報は、少なくとも１つの再認証トリガー識別子および再認証トリガーを備えることを特徴とする請求項１に記載の方法。
3. 前記再認証トリガー情報は、ベアラ確立時、クレジット応答がＯＣＳからＴＰＦへ返信されるときに提供され、又はベアラ修正時、クレジットコントロール応答がＯＣＳから前記ＴＰＦへ返信されるときに提供されることを特徴とする請求項１に記載の方法。
4. 現在の再認証プロセスをトリガーする再認証トリガーを前記ＴＰＦからＯＳＣへ提供するステップをさらに含むことを特徴とする請求項１に記載の方法。
5. ＯＣＳがユーザのクレジットの再計算を行うステップと、再計算されたユーザクレジットをＴＰＦへ返信するステップと、をさらに含むことを特徴とする請求項１に記載の方法。
6. ベアラがオンライン課金で確立された場合も、ベアラが修正された場合も、パケットデータフローの課金に基づく前記再認証は処理されることを特徴とする請求項１に記載の方法。
7. 前記ＴＰＦが再認証トリガーを予め記憶していない場合、前記ＯＣＳから受信した再認証トリガー情報は、少なくとも１つの再認証トリガーを備えることを特徴とする請求項１に記載の方法。
8. 前記ＴＰＦは、予め記憶された少なくとも１つの再認証トリガーを有し、
   前記ＯＣＳから受信した再認証トリガー情報は、少なくとも１つの再認証トリガー識別子および再認証トリガーを備えることを特徴とする請求項１に記載の方法。

Images