JP3983716B2 - 課金記録情報収集装置 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、移動パケット通信サービスにおいてパケット通信料を課金するための基礎データである課金データ情報を収集する課金記録情報収集装置に関する。
【０００２】
【従来の技術】
第２．５世代や第３世代とよばれる種類の携帯電話システムにおいて、パケット通信サービスが行われている。このような移動パケット通信サービスにおいては、回線接続時間に対して課金を行う回線交換の場合とは異なり、データ伝送量に応じた課金方式（従量課金）が採用されている。
【０００３】
第３世代の携帯電話システムにおけるパケット通信サービスについて、図９を参照して説明する。
この図において、５１は移動通信端末（ＭＳ）、５２は無線ネットワーク制御システム（ＲＮＳ：Radio Network Subsystem）、５３はＧＰＲＳ（General Packet Radio Service）網などのコアネットワーク、５４は前記ＲＮＳ５３とコアネットワーク５３とのゲートウエイであるＳＧＳＮ（Serving GPRS Support Node，加入者交換機）、５５はコアネットワーク５３とＩＰネットワーク５７とのゲートウエイであるＧＧＳＮ（Gateway GPRS Support Node，関門交換機）、５６はトランスポート層の最適化を行うＴＣＰＲ（TCP Router）、５７はインターネットなどのＩＰネットワーク、５８，５９はＩＰネットワーク５７に接続され、各種サービスを提供するアプリケーションサービスノードであり、５８はメールサーバー、５９はウェブサーバーである。
【０００４】
このように構成されたパケット通信システムにおいて、移動通信端末５１からのユーザーデータ（ＩＰパケット）あるいは移動通信端末５１へのユーザーデータ（ＩＰパケット）は、ＲＮＳ５２，ＳＧＳＮ５４，ＧＧＳＮ５５間でＧＴＰ（GPRS Tunneling Protocol）プロトコルを用いてトンネリングされる。すなわち、図中に示すように、移動通信端末５１からのＩＰパケットは、ＲＮＳ５２において、ＧＴＰヘッダ、ＵＤＰヘッダ及びＩＰヘッダからなるＧＰＲＳヘッダ（あて先ＳＧＳＮ５４、発信元ＲＮＳ５２）が付加されてカプセル化され、ＳＧＳＮ５４に転送される。さらに、ＳＧＳＮ５４において、あて先をＧＧＳＮ５５、発信元をＳＧＳＮ５４とするＧＰＲＳヘッダに変更されて、ＧＧＳＮ５５に転送される。そして、ＧＧＳＮ５５において、ＧＰＲＳヘッダが除去され、該カプセルから解放されたユーザーのＩＰパケットがＴＣＰＲ５６を経てＩＰネットワーク５７に転送される。一方、移動通信端末５１へのＩＰパケットの場合には、上記とは逆方向にカプセル化されて移動通信端末５１に転送される。
【０００５】
ここで、パケットに対して従量課金を行うために、ＳＧＳＮ５４とＧＧＳＮ５５の双方で課金記録情報（ＣＤＲ：Charging Data Record / Call Detail Record）を収集するようにしている。すなわち、ＧＧＳＮ５５で上り（ＭＳ５１→ＩＰネットワーク５７）分、ＳＧＳＮ５４で下り（ＩＰネットワーク５７→ＭＳ５１）分のＣＤＲを収集するようにしている。
また、第２．５世代の移動パケット通信システムにおいては、パケット交換機（ＳＧＳＮ，ＧＧＳＮ）においてあて先ＩＰアドレスに応じてパケット通信料の課金／非課金を判別し、ＣＤＲを作成するようにしていた。
【０００６】
【発明が解決しようとする課題】
第２．５世代の移動パケット網を利用する場合と第３世代の移動パケット網を使用する場合とで、異なる料金体系となることは望ましいことではなく、第３世代の移動パケット通信サービスにおいても、第２．５世代の移動パケット通信サービスと同様のパケット課金ポリシーが継続されることが求められている。
しかしながら、図９に示したような、ＧＴＰが適用されたＩＰトンネリングを行う３Ｇベアラネットワークにおいては、ユーザーパケットがカプセル化されているため、パケット交換機（ＳＧＳＮ５４，ＧＧＳＮ５５）ではユーザーパケットの内容が不明であり、あて先ＩＰアドレスなどをもとにした課金／非課金の判別を行うことができない。また、ＩＰヘッダを含めたＩＰパケット（カプセル化されたデータ部分）が課金対象となっていた。
そこで本発明は、柔軟な通信料課金を実現することができる課金記録情報収集装置を提供することを目的としている。
【０００７】
【課題を解決するための手段】
上記目的を達成するために、本発明の課金記録情報収集装置は、移動パケット通信システムにおける課金データ情報を収集する課金記録情報収集装置であって、コアネットワークとＩＰネットワークとを結ぶ伝送路に挿入された分岐装置と、該分岐装置により分岐されたＩＰパケットを分析して、各プロトコルのアプリケーションセッション単位に、少なくとも、開始時刻、終了時刻、サーバーのＩＰアドレスとポート番号、加入者ＩＰアドレス、上りのデータ伝送量及び下りのデータ伝送量を含むパケットログを生成するパケット情報生成手段と、前記コアネットワークのパケット交換機からの情報に基づいて、各ＲＡＤＩＵＳセッションごとに、少なくとも、開始時刻、終了時刻、加入者電話番号及び加入者ＩＰアドレスを含むセッションログを生成するセッション情報生成手段と、前記パケットログと前記セッションログとの関連付けを行い、各ＲＡＤＩＵＳセッションごとに、データ伝送量を予め設定したクラスごとに集計した課金記録情報を生成するＣＤＲ生成手段とを有するものである。
さらに、前記伝送路に現用系と待機系の２個の前記分岐装置が挿入されており、該２個の分岐装置の間に該伝送路上を伝送される信号を増幅する手段が設けられているものである。
【０００８】
さらにまた、前記クラスは、接続先のサーバーのＩＰアドレス、接続先のサーバーのＩＰアドレスとポート番号の組み合わせ、又は、利用しているプロトコル種別に応じて設定されているものである。
さらにまた、前記パケットログには、ＨＴＴＰリクエストに含まれているＵＲＬ又はＭＩＭＥタイプも記録されており、前記クラスは、ＵＲＬ又はＭＩＭＥタイプに応じて設定されているものである。
さらにまた、前記パケットログには、前記上りのデータ伝送量及び前記下りのデータ伝送量が各レイヤーごとに集計されており、前記ＣＤＲ生成手段により生成される課金記録情報にどのレイヤーにおけるデータ伝送量を含ませるのかを選択することができるようになされているものである。
さらにまた、前記パケットログには、上りの再送パケットのデータ伝送量と下りの再送パケットのデータ伝送量も集計するようになされており、前記ＣＤＲ生成手段による生成される課金記録情報に再送パケットのデータ伝送量を減算したデータ伝送量を含ませるか否かを選択することができるようになされているものである。
さらにまた、前記ＣＤＲ生成手段は、当該ＲＡＤＩＵＳセッションがあらかじめ設定された時刻をまたぐものであるとき、その課金記録情報を該設定された時刻により分割して出力することができるようになされているものである。
【０００９】
【発明の実施の形態】
本発明の課金記録情報収集装置の一実施の形態について、図１を参照して説明する。
図１において、１は移動通信端末（ＭＳ）、２はＧＰＲＳ（General Packet Radio Service）網などのコアネットワーク、３は前述したＳＧＳＮ、４は前述したＧＧＳＮ、５はユーザーの認証を行なうＲＡＤＩＵＳサーバ（Authentication）、６は本発明の課金記録情報収集装置（ＰＣＮ：Packet Charging Node）、７は前記ＧＧＳＮ４とＴＣＰＲ８とを接続する伝送路（具体的には、1000Base-SXなど）、８はＴＣＰルーター（ＴＣＰＲ）、９はインターネットなどのＩＰネットワーク、１０はメールサーバー、１１はウェブサーバー、１２は課金処理システムである。
ここで、前記課金記録情報収集装置（ＰＣＮ）６は、前記ＧＧＳＮ４とＴＣＰＲ８とを結ぶ伝送路７に挿入された分岐装置（ＴＡＰ）２１と、該分岐装置２１からのＩＰパケットを集計してパケットログを生成するパケット情報生成手段２２と、前記ＲＡＤＩＵＳサーバー５に接続され、ＲＡＤＩＵＳサーバー（Accounting）機能を有するとともに、セッションログを生成するセッション情報生成手段２３と、前記パケット情報生成手段２２で生成されたパケットログと前記セッション情報生成手段２３で生成されたセッションログとの関連付けを行い、課金記録情報（一次ＣＤＲ）を生成する一次ＣＤＲ生成手段２４と、該一次ＣＤＲを圧縮し、複数の一次ＣＤＲをまとめたＣＤＲファイルを生成して、前記課金処理システム１２からのポーリングに応じて出力するＣＤＲファイル出力手段２５とを有している。ここで、前記パケット情報生成手段２２、セッション情報生成手段２３、一次ＣＤＲ生成手段２４及びＣＤＲファイル出力手段２５は、ＮＴＰ（Network Time Protocol）サーバーを用いてシステム標準時刻との同期がとられており、それぞれにおいて使用するタイムスタンプにこの時刻を適用するようになされている。
【００１０】
このように構成された本発明の課金記録情報収集装置の動作について詳細に説明する。
本発明においては、ユーザーの認証等の処理を行なうためにＲＡＤＩＵＳ（Remote Authentication Dial In User Service、RFC2138，2139）を用いている。ＲＡＤＩＵＳは、ダイヤルアップユーザーの認証システムの一つであり、ＲＡＤＩＵＳクライアントからのユーザーの認証要求に対して、ＲＡＤＩＵＳユーザー情報管理データベースを参照して認証処理（Authentication）を行なうとともに、認証されネットワークへの接続が許可されると、ユーザーごとにその接続時間を算出して課金処理（Accounting）を行うことができるものである。
本発明においては、前記ＧＧＳＮ４がＲＡＤＩＵＳクライアント機能を有しており、前記ＲＡＤＩＵＳサーバ５が、認証用のRADIUS Authenticationサーバーとして動作するとともに、課金用のRADIUS Accountingプロトコルのデータを前記ＰＣＮ６中に設けられたＲＡＤＩＵＳサーバー（Accounting）機能を有するセッション情報生成手段２３に振り分ける動作を行う。
【００１１】
移動通信端末１のユーザーからアクセスがあったとき、ＲＡＤＩＵＳクライアント機能を有するＧＧＳＮ４は、そのユーザーのユーザーＩＤとパスワードを含むAuthorization Requestを認証サーバーであるＲＡＤＩＵＳサーバー（Authentication）５に送信する。このAuthorization Requestを受信したＲＡＤＩＵＳサーバー５は、ユーザーの接続を許可するために必要な情報が格納されているデータベースを検索してそのユーザーの正当性を検査し、正当性が認められたときは、そのユーザーの接続パラメータに関する情報を含むAuthentication Ack応答をＧＧＳＮ４に返す。ＧＧＳＮ４は、受信した接続パラメータに基づいて設定を行い、そのユーザーをＩＰネットワーク９に接続する（RADIUS Authenticationプロトコル）。
【００１２】
ＧＧＳＮ４は、ユーザーの認証に成功し、パラメータの設定が終了した時点（ＲＡＤＩＵＳセッションが確立した時点）で、RADIUS Accounting Request（Acct-Status-Type=Accounting-start）を作成し、アカウンティングサーバーに送信する。本発明においては、該RADIUS Accounting Request（Acct-Status-Type=Accounting-start）は、ＲＡＤＩＵＳサーバー５によりＰＣＮ６内のセッション情報生成手段２３に振り分けられ、セッション情報生成手段２３は、その内容（加入者電話番号MSISDNとIPアドレスの対応）をタイプスタンプ（ＲＡＤＩＵＳセッション開始時刻）とともにファイルに記録して、Accounting Response応答を返す。
また、ＲＡＤＩＵＳセッション終了の際には、ＧＧＳＮ４よりRADIUS Accounting Request要求（Acct-Status-Type=Accounting-stop）を発信し、これを受け取ったセッション情報生成手段２３は、タイムスタンプ（ＲＡＤＩＵＳセッション終了時刻）を付すとともに、加入者のMSIDSDNとＩＰアドレスの対応を解放し、RADIUS Accounting ResponseをＧＧＳＮ４に対して返送する（RADIUS Accountingプロトコル）。
このように、セッション情報生成手段２３において、ユーザーのＲＡＤＩＵＳセッションごとに、MSISDN（加入者電話番号）、加入者ＩＰアドレス及びＲＡＤＩＵＳセッションの有効期間（開始時刻〜終了時刻）の情報を記録したセッションログが生成される。
【００１３】
上述のようにしてユーザーの認証に成功し、ＲＡＤＩＵＳセッションが開始された後、前記伝送路７にはＳＭＴＰ（Simple Mail Transfer Protocol）やＨＴＴＰ（Hypertext Transfer Protocol）などのユーザートラヒック（ＩＰパケット）が通過する。前記分岐装置（ＴＡＰ）２１はこれらのＩＰパケットを分岐して前記パケット情報生成手段２２に出力する。ここで、前記伝送路７は例えば1000Base-SXなどのギガビットイーサネット(TM)であり、伝送路７が1000Base-SXの場合には、分岐装置２１として例えばビームスプリッタが用いられる。
【００１４】
前記パケット情報生成手段２２では、前記分岐装置２１を介して収集されるウェブやメールなどのＩＰパケットを分析し、各ウェブやメールなどの各プロトコルのアプリケーションセッション単位に、その開始時刻、終了時刻、サーバーのＩＰアドレスとポート番号、加入者ＩＰアドレス、データ伝送量などのＣＤＲ生成に必要な情報（パケットログ）を生成する。
【００１５】
まず、ＴＣＰ（Transmission Control Protocol）又はＵＤＰ（User Data Protocol）を利用してデータを送信するときのプロトコル・スタックとデータのカプセル化について、図２を参照して説明する。
よく知られているように、送信されるユーザーデータは、図２のプロトコルスタックを下層に向かって転送され、各層において、データが相手先に届くように、各種のヘッダが追加される。アプリケーションによりアプリケーションヘッダが付加されたユーザーデータは、トランスポート層プロトコル（ＴＣＰ又はＵＤＰ）に送られ、ＴＣＰ又はＵＤＰヘッダが付加される。このＴＣＰヘッダ又はＵＤＰヘッダには、送り手と受け手のアプリケーションを識別するために、発信元とあて先のポート番号が含まれている。ＴＣＰ又はＵＤＰヘッダが付加されたデータは、ネットワーク層のＩＰプロトコルによりＩＰヘッダが付加される。ＩＰヘッダには発信元のＩＰアドレス、あて先のＩＰアドレス、そのデータが所属する層を示すプロトコルフィールド（「６」がＴＣＰ、「１７」がＵＤＰを示す。）などが含まれている。ＩＰヘッダが付加されたＩＰデータグラムは、Ethernet(TM)ドライバにより、Ethernetヘッダ及びEthernetトレーラが付加されて、前記伝送路７上を転送される。
なお、受信側では、上記プロトコルスタックを上昇し、それぞれ対応する階層で個々のヘッダが取り除かれていくこととなる。
【００１６】
前記パケット情報生成手段２２では、前記分岐装置２１を介して収集したデータリンク層のパケットから、Ethernet(TM)ヘッダとEthernet(TM)トレーラーを取り除き、ＩＰデータグラム（ＩＰヘッダ、ＴＣＰ又はＵＤＰヘッダ、アプリケーションデータ）を分析し、パケットログを生成する。なお、前記分岐装置２１からパケットを受け取ったときに、その時刻を示すタイムスタンプを付与しておく。
【００１７】
図３は、前記パケット情報生成手段２２において前記ＩＰパケットを分析することにより生成されるパケットログの一構成例を示す図である。
この図に示すように、パケットログには、ウェブやメールなどの各プロトコルのアプリケーションセッションごとに、そのセッションの開始時刻と終了時刻、サーバーのＩＰアドレスとポート番号、クライアントのＩＰアドレスとポート番号、セッションがＨＴＴＰであるときは、ＭＩＭＥタイプ、ＵＲＬのホスト、ＵＲＬパス、レイヤー３〜レイヤー５のそれぞれについて、上り（クライアント→サーバー）と下り（サーバー→クライアント）の転送バイト数、同じく再送パケットによる転送バイト数、プロトコル（ＴＣＰ／ＵＤＰの別）などが記録されたものである。
【００１８】
ＩＰパケットの分析はつぎのように行なわれる。
まず、そのパケット（ＩＰデータグラム）のＩＰヘッダ部に含まれているプロトコル・フィールドの値を参照し、その値が「０６」であればＴＣＰ、「１７」であればＵＤＰであると判断する。その結果、ＵＤＰであるときには、そのＵＤＰセッションが終了した後に、そのＵＤＰセッションのパケットログの開始時刻フィールドにそのＵＤＰセッション内の最初のパケットの受信タイムスタンプを、終了時刻フィールドにそのセッションの最後のパケットの受信タイムスタンプを、そのセッションのサーバーＩＰアドレスとポート番号、クライアントＩＰアドレスとポート番号の各フィールドにそれぞれ対応するデータを書き込み、さらに、それぞれのネットワークレイヤーに対応したバイト数のフィールドにそれぞれの転送バイト数の計数値を上り／下り別々に記録する。すなわち、図２に示すように、レイヤー３（Ｌ３）についてはイーサネットペイロード部（ＩＰヘッダ部＋ＴＣＰ／ＵＤＰヘッダ部＋アプリケーションデータ部）のバイト数、レイヤー４（Ｌ４）についてはＩＰペイロード部（ＴＣＰ／ＵＤＰヘッダ部＋アプリケーションデータ部）のバイト数、レイヤー５（Ｌ５）についてはＴＣＰ／ＵＤＰペイロード部（アプリケーションデータ部）のバイト数を上り／下り別々に集計する。
【００１９】
また、ＴＣＰの場合には、そのＴＣＰヘッダに含まれているポート番号を分析し、該ポート番号により、そのＴＣＰセッションがＨＴＴＰセッションを含むか否かを判断する。例えば、ポート番号が「８０」、「４４３」などのときはＨＴＴＰであると判定する。
そして、ＨＴＴＰセッションを含まない場合には、そのＴＣＰセッションが終了してから（ＦＩＮフラグとＡＣＫを検出してから）、ＵＤＰの場合と同様に、そのＴＣＰセッションの開始時刻、終了時刻、サーバーのＩＰアドレスとポート番号、クライアントのＩＰアドレスとポート番号、各レイヤーの上り／下りの転送バイト数をそれぞれ対応するフィールドに記録する。さらに、ＴＣＰヘッダに含まれているシーケンス番号が同一であるパケットが存在する場合には、そのパケットを再送パケットであるとみなし、各ネットワークレイヤーに対応した再送バイト数のフィールドにシーケンス番号が重複したパケットに対応するバイト数を上り／下り別々に出力する。
【００２０】
一方、ＨＴＴＰセッションを含む場合には、前記ＨＴＴＰセッションを含まない場合と同様に、そのＴＣＰセッションの開始時刻、終了時刻、サーバーのＩＰアドレスとポート番号、クライアントのＩＰアドレスとポート番号、各レイヤーの上り／下り別々の転送バイト数、各レイヤーの上り／下り別々の再送バイト数をそれぞれに対応するフィールドに出力するとともに、そのＨＴＴＰリクエストのデータの中から、「URL_HOST」，「URL_PATH」，「MIME_TYPE」，「MIME_SUBTYPE」に対応する情報を検索し、それぞれに対応するフィールドへ出力する。なお、HTTP/1.1の持続的接続などにより、単一のＴＣＰコネクション上で複数のＨＴＴＰリクエストが送信される場合には、各ＨＴＴＰセッションごとに上記パケットログを作成する。
また、ＵＤＰでもＴＣＰでもないときには、解読することのできる情報を含む情報をそのパケットのパケットログとして作成する。
【００２１】
このようにして作成されたパケットログは、そのセッションの開始時刻と終了時刻、サーバーのＩＰアドレスとポート番号、クライアントのＩＰアドレス（ＭＳＩＰアドレス）とポート番号、レイヤー３〜レイヤー５の各レイヤーごとの上りと下りの転送バイト数を含んでいる。また、ＴＣＰセッションのパケットに対応するパケットログは、さらに、レイヤー３〜レイヤー５の各レイヤーごとの上りと下りの再送パケット数を含んでおり、ＨＴＴＰセッションのパケットに対応するパケットログには、さらにまた、そのＨＴＴＰリクエストに含まれているＵＲＬホストとパス、及び、ＭＩＭＥタイプとサブタイプの情報が含まれている。
【００２２】
さて、前述のように、前記伝送路７上を流れるＩＰパケットには加入者電話番号（ＭＳＩＳＤＮ）は含まれていない。
そこで、前記一次ＣＤＲ生成手段２４において、前記パケット情報生成手段２２において各プロトコルのアプリケーションセッションごとに生成されたパケットログと、前記セッション情報生成手段２３においてＲＡＤＩＵＳセッションごとに生成されたセッションログとを照合して、各加入者ごとのアプリケーションサービス単位の伝送データ量を含む一次ＣＤＲを生成する。この一次ＣＤＲは、各ＲＡＤＩＵＳセッションを単位とし、そのＲＡＤＩＵＳセッションにおけるウェブやメールなどの各アプリケーションサービスの利用の詳細を示す情報を記述したものであり、ＲＡＤＩＵＳセッションの情報を示すセッションＣＤＲと、ウェブやメールの各トラヒック情報を示すパケットＣＤＲの２種類に分けて生成される。このパケットＣＤＲは利用サービスに応じたクラス分けを行なって、クラスとそれに該当する伝送データ量の合計を上り／下り別に記述したものである。なお、このクラスに応じて課金単価を決定することができる。
【００２３】
図４を参照して、一次ＣＤＲの作成の例について説明する。
この図に示す例は、MSISDNが09012345678であるユーザーＡがＲＡＤＩＵＳセッションを10:00:00に開始し、10:10:00に終了した場合を示している。このＲＡＤＩＵＳセッションのセッションログと前記パケットログとを照合して、パケットログのセッション開始／終了時刻がＲＡＤＩＵＳセッションの有効時間（開始時刻〜終了時刻）内であり、かつ加入者ＩＰアドレスが等しいパケットログを該ＲＡＤＩＵＳセッションログと関連付ける。その結果、利用サービス詳細に示すように、ウェブページＡの閲覧（上り２００バイト／下り８００バイト）、メールの送信（上り４００バイト／下り１００バイト）、ウェブページＢの閲覧（上り２５０バイト／下り１０００バイト）及びウェブページＣの閲覧（上り３００バイト／下り５００バイト）に対応するパケットログが関連付けられたものとする。
ここで、各サービスに応じてクラス分けが行なわれ、ウェブページＡの閲覧とウェブページＢの閲覧がともにクラス１、ウェブページＣの閲覧がクラス２、メールがクラス３と設定されていたとする。
このとき、一次ＣＤＲ生成部２４では、図示するように、ユーザーのMSISDNをキーとし、ＲＡＤＩＵＳセッションのスタート時刻と有効時間とを記録したセッションＣＤＲと、利用したサービスをクラスごとに集約した３つのパケットＣＤＲからなる一次ＣＤＲを作成する。このパケットＣＤＲは、MSISDNをキーとして各クラスごとに作成され、各クラスごとの上りの転送バイト数と下りの転送バイト数の集計値を記録したものである。
【００２４】
以下、一次ＣＤＲ作成処理について詳細に説明する。
前述のように、前記パケット情報生成手段２２において、サーバーのＩＰアドレスとポート番号、レイヤーごとの転送バイト数及び再送バイト数、ＵＲＬ情報及びＭＩＭＥタイプなど各種の情報を記録したパケットログを生成している。したがって、この一次ＣＤＲ生成手段２４において一次ＣＤＲを生成するにあたり、データ量の計数の対象とするレイヤーの選択や再送パケットのデータ量を伝送データ量から減算するか否かの選択を任意に行なうことができるようになされている。
また、各クラスを、ソケット（ＩＰアドレスとポート番号）を判別し、接続先のサーバーや利用しているプロトコル種別に応じて設定すること、あるいは、ＨＴＴＰリクエストのＵＲＬやＭＩＭＥタイプを判別して、ＵＲＬやＭＩＭＥタイプに応じて設定することができるようにしている。
さらにまた、予め設定された時刻となったときに、その時刻によりＣＤＲ情報を分割して出力することができる機能を持たせ、予め設定された期間に応じて適用する料金を変更したり、時間帯別に料金を変更すること（期間適用）ができるようにしている。
【００２５】
一次ＣＤＲ生成手段２４では、まず、前記パケット情報生成手段２２において生成されたパケットログ（図３）について、そのパケットログのアプリケーションセッション開始時刻からセッション終了時刻が、前記予め設定された時刻（規定時刻）に跨がっていないか否かを判定する。
その結果、規定時刻を跨がっているときには、そのパケットログを開始時刻から規定時刻、規定時刻から終了時刻の２つのパケットログに分割し、厳密に期間適用を行うことができるようにしている。この機能を、「パーシャルアウトプット機能」とよぶ。
【００２６】
このパーシャルアウトプット機能について、図５を参照して説明する。
図５に示すように、時刻ｔ１に開始し、時刻ｔ５に終了するＲＡＤＩＵＳセッションがあり、その中に時刻ｔ２に開始し、時刻ｔ４に終了するＴＣＰセッションがあった場合に、規定時刻ｔ３が設定されており、ｔ２＜ｔ３＜ｔ４であったとする。
このときは、そのＴＣＰセッションのパケットログを時刻ｔ２を開始時刻とし時刻ｔ３を終了時刻とする第１のパケットログ（ａ）と、時刻ｔ３を開始時刻とし時刻ｔ４を終了時刻とする第２のパケットログ（ｂ）とに分割する。このとき、分割前のパケットログ中に含まれていた転送バイト数のデータは、（ｔ３−ｔ２）と（ｔ４−ｔ３）とで比例配分して、それぞれのパケットログ中に記録する。
このように規定時刻を跨がったＴＣＰセッションについては、パケットログを分割することにより、期間適用を厳密に行うことが可能となる。
【００２７】
次に、前記パケットログから選択されているレイヤーのデータのみを選択し、さらに、再送パケットを減算して課金の対象からはずすことが設定されている場合には、前記選択されたレイヤーのデータからそのレイヤーの再送パケットのデータを減算して新たなデータとする処理（アップリンク／ダウンリンクバイト計算処理）を行なう。
すなわち、必要に応じてパーシャルアウトプットされた各パケットログにおいて、レイヤー選択により設定されたレイヤーにおける上り／下りのデータ量が選択される。そして、再送パケットの減算を行なうと設定されているときには、前記選択されたレイヤーにおける上り／下りのデータ量からそのレイヤーの上り／下りにおける再送パケットのデータ量を減算して、その結果のデータ量を選択されたレイヤーのデータ量とする。
【００２８】
次に、このようにして修正したパケットログと、前記セッション情報生成手段２３において生成されたＲＡＤＩＵＳセッションログとの関連付けを行なう。すなわち、パケットログに含まれているアプリケーションセッションの開始時刻，終了時刻及びＭＳＩＰアドレス（加入者ＩＰアドレス）と、前記ＲＡＤＩＵＳセッションログに含まれているＲＡＤＩＵＳセッションの開始時刻，終了時刻、ＭＳＩＳＤＮ（加入者電話番号）及びＭＳＩＰアドレスとを比較し、パケットログがどのＲＡＤＩＵＳセッションに含まれるものであるかを決定する。
【００２９】
そして、そのパケットログに含まれているソケット（サーバーＩＰアドレスとポート番号の組み合わせ）及びＵＲＬ（ＭＩＭＥタイプ）に応じて、クラスを決定する。
クラスの決定の一例について、図６を参照して説明する。
まず、パケットログに含まれているソケットが、どの分類に属しているかが判定される（ソケットフィルタ処理）。すなわち、前記パケットログに含まれているソケット（サーバーＩＰアドレスとポート番号の組み合わせ）を予め定義され設定されている（ａ）〜（ｈ）の各クラスに対応するソケットと比較して、そのいずれに属するかを判定する。なお、この比較において、ＩＰアドレスについては、完全一致、前方一致あるいはドントケアの判定を行ない、ポート番号については、完全一致、範囲指定あるいはドントケアの判定を行なうことができるようになされている。なお、対象外のソケットはＮ／Ａ（Not Applicable）とされる。なお、この例では、クラスは、ソケットクラス＋詳細クラスで定義されており、各クラスに対応してタリフ（課金単価）が決定されている。
【００３０】
ソケットフィルタ処理の結果、（ａ）メール系（無料：例えばダイジェスト受信）に属する場合には、ソケットクラス０１、詳細クラス００とされ、（ｂ）メール系（有料）の場合には、ソケットクラス０１、詳細クラス０１とされる。
また、ソケットのみでマッチする（ｃ）ウェブ系（無料）、（ｄ）ウェブ系（ＪＡＶＡ(TM)）あるいは（ｅ）ウェブ系（動画）の場合には、ソケットクラスが０２とされ、詳細クラスが順に００，０１，０２とされる。
さらに、ＵＲＬを参照する（ｆ）ウェブ系（ページ）の場合には、ＨＴＴＰリクエスト中に含まれていたＵＲＬホスト，ＵＲＬパス及びＭＩＭＥタイプ／サブタイプを予め設定されているＵＲＬホスト／パス及びＭＩＭＥタイプ／サブタイプと比較するＵＲＬフィルタ処理を行ない、その属するアプリケーションクラスを決定する。すなわち、前記（ｆ）ウェブ系（ページ）であるとの判定により、ソケットクラスは０３とされるが、詳細クラスは、ＵＲＬフィルタ処理の結果により決定される。ここで、この比較において、完全一致、前方一致、拡張子完全一致及びドントケアの判定を行うことができるようになされている。
このＵＲＬフィルタ処理の結果、詳細クラスは、（ｉ）ウェブ系（無料）の場合には００、（ｊ）ウェブ系（有料Ａ）の場合には０１、前記（ｊ）とは単価が異なる（ｋ）ウェブ系（有料Ｂ）の場合には０２というように、それぞれ決定される。
さらにまた、メールやウェブ以外のアプリケーションである（ｇ）その他（無料）又は（ｈ）その他（有料Ａ）の場合には、ソケットクラスが０４とされ、詳細クラスが００又は０１とされる。
このようにして、各パケットログに含まれているアプリケーションセッションがどのクラス（ソケットクラス＋詳細クラス）に属するかが決定される。
なお、このクラス体系は一例にすぎず、他の体系とすることは任意である。
【００３１】
次に、同一のＲＡＤＩＵＳセッションに含まれているパケットログについて、同一のクラスに属するパケットログのデータ量（上り／下り）を集計して、前記図４に示したようなクラス単位のパケットＣＤＲを作成する。また、前記ＲＡＤＩＵＳセッションに対応するセッションＣＤＲを作成する。これにより、そのＲＡＤＩＵＳセッションに対応する一次ＣＤＲ（＝セッションＣＤＲ＋１又は複数のパケットＣＤＲ）が作成された。
【００３２】
このようにして生成された一次ＣＤＲはＣＤＲファイル出力手段２５に出力され、該ＣＤＲファイル出力手段２５において、複数の一次ＣＤＲがまとめられたＣＤＲファイルが作成される。
図７は、ＣＤＲファイルの構成を示す図である。
この図に示すように、ＣＤＲファイルは、ＣＤＲ１，ＣＤＲ２，…で示す複数の一次ＣＤＲをまとめたものであり、このようなＣＤＲファイルは、レコード数（一次ＣＤＲ数）が一定値に達したとき、又は一定時間間隔で作成される。
そして、作成されたＣＤＲファイルは、圧縮された後、前記ＣＤＲファイル出力手段２５における記録装置にＣＤＲファイル格納ディレクトリに格納される。そして、前記課金処理システム１２から例えば所定時間間隔で発せられるポーリングに応じて、前記ＣＤＲファイル格納ディレクトリに格納されているＣＤＲファイル１，…，ＣＤＲファイルｎが読み出され、前記課金処理システム１２に転送されることとなる。課金処理システム１２では、このようにして収集したＣＤＲに基づいて各ユーザーに対する課金処理を行う。なお、このときに、前記クラスに応じて対応する単価が適用されることとなる。
【００３３】
次に、信頼性を向上させた本発明の課金処理装置の実施の形態について図８を参照して説明する。
図８において、前記図１と同一の構成要素には同一の番号を付して説明を省略する。一般に、移動パケット通信システムにおいては、信頼性を向上させるために系が２重化されている。すなわち、図８に示すように、前記コアネットワーク２とインターネットなどのＩＰネットワーク９とを結ぶ伝送路は２重化されており、７−１（現用系）と７−２（待機系）の２系統設けられている。そして、前記ＧＧＳＮ４と経路７−１，７−２とをレイヤー２スイッチ（Ｌ２ＳＷ）３１，３２により切り換えて接続することができるようになされている。
そこで、この実施の形態においては、２重化されている伝送路７−１，７−２に分岐装置を挿入するとともに、該分岐装置及びパケット情報生成手段なども２重化構成として課金記録情報収集装置６の信頼性を向上させるようにしている。
【００３４】
図８において、２１−１と２１−２はともに前記現用系の伝送路７−１に挿入された分岐装置、２１−３と２１−４はともに前記待機系の伝送路７−２に挿入された分岐装置である。そして、分岐装置２１−１と２１−３の出力はともに第１のパケット情報生成手段２２−１に選択的に入力され、分岐装置２１−２と２１−４の出力はともに第２のパケット情報生成手段２２−２に選択的に入力されるようになされている。なお、図示していないが、各パケット情報生成手段２２−１及び２２−２の後段には、それぞれ、一次ＣＤＲ生成手段２４−１，２４−２、セッション情報生成手段２３−１，２３−２及びＣＤＲファイル出力手段２５−１，２５−２が設けられており、課金記録情報収集装置６は完全２重系とされている。これにより、万が一、分岐装置やパケット情報生成手段などに障害が発生しても、課金記録情報の収集を継続して行うことができる。
なお、このように一つの伝送路（７−１／７−２）に２つの分岐装置（２１−１と２１−２／２１−３と２１−４）を挿入することにより、信号強度が低下することが考えられる。そこで、この実施の形態においては、分岐装置２１−１と２１−２との間にレイヤー２スイッチ（Ｌ２ＳＷ）３３を挿入し、分岐装置２１−３と２１−４との間にＬ２ＳＷ３４を挿入している。Ｌ２ＳＷは信号（伝送路が1000BASE-SXである場合には光信号）を再生中継する機能を有しているため、減衰した信号を増幅し、分岐装置を挿入したことによる信号強度の低下を補償することが可能となる。
なお、この実施の形態においては、Ｌ２ＳＷを用いて信号強度の低下を補償するようにしたが、これに限られることはなく、光増幅器など信号を増幅あるいは再生することができるものを使用することができる。
【００３５】
【発明の効果】
以上説明したように、本発明の課金記録情報収集装置によれば、ＩＰアドレス別の課金、ＵＲＬ別の課金、ＴＣＰ再送パケット非課金、利用サービス（ウェブ／メール）別課金、時間帯別課金、課金対象レイヤーの変更などの機能を実現することができる。
また、分岐装置を挿入して分岐したＩＰパケットに基づいて課金に必要な情報を取得するようにしたために、ＰＣＮ装置が故障したとしても、ユーザーサービスに影響を与えることがない。
さらにまた、分岐装置を冗長構成とするとともに、分岐装置間に信号を増幅する手段を設けた本発明によれば、分岐装置を挿入したことによる信号強度の低下を補償することができる。
【図面の簡単な説明】
【図１】 本発明の課金記録情報収集装置の一実施の形態の概略構成を示すブロック図である。
【図２】 ＴＣＰ又はＵＤＰを利用してデータを送信するときのプロトコル・スタックとデータのカプセル化について説明するための図である。
【図３】 パケットログの構成例を示す図である。
【図４】 ＣＤＲについて説明するための図である。
【図５】 パーシャルアウトプット機能について説明するための図である。
【図６】 アプリケーションクラスについて説明するための図である。
【図７】 複数の一次ＣＤＲがまとめられたＣＤＲファイルの構成を説明するための図である。
【図８】 本発明の課金記録情報収集装置の他の実施の形態の要部構成を示す図である。
【図９】 第３世代携帯電話システムにおけるパケット通信サービスについて説明するための図である。
【符号の説明】
１：移動通信端末、２コアネットワーク、３：ＳＧＳＮ、４：ＧＧＳＮ、５：ＲＡＤＩＵＳサーバー、６：課金記録情報収集装置（ＰＣＮ）、７：伝送路、８：ＴＣＰルーター、９：ＩＰネットワーク、１０：メールサーバー、１１：ウェブサーバー、１２：課金処理システム、２１：分岐装置、２２：パケット情報生成手段、２３：セッション情報生成手段、２４：一次ＣＤＲ生成手段、２５：ＣＤＲファイル出力手段

Claims (8)

1. 移動パケット通信システムにおける課金データ情報を収集する課金記録情報収集装置であって、
   コアネットワークとＩＰネットワークとを結ぶ伝送路に挿入された分岐装置と、
   該分岐装置により分岐されたＩＰパケットを分析して、各プロトコルのアプリケーションセッション単位に、少なくとも、開始時刻、終了時刻、サーバーのＩＰアドレスとポート番号、加入者ＩＰアドレス、上りのデータ伝送量及び下りのデータ伝送量を含むパケットログを生成するパケット情報生成手段と、
   前記コアネットワークのパケット交換機からの情報に基づいて、各ＲＡＤＩＵＳセッションごとに、少なくとも、開始時刻、終了時刻、加入者電話番号及び加入者ＩＰアドレスを含むセッションログを生成するセッション情報生成手段と、前記パケットログと前記セッションログとの関連付けを行い、各ＲＡＤＩＵＳセッションごとに、データ伝送量を予め設定したクラスごとに集計した課金記録情報を生成するＣＤＲ生成手段と
   を有することを特徴とする課金記録情報収集装置。
2. 前記ＣＤＲ生成手段で生成した課金記録情報を圧縮し、該圧縮した複数の課金記録情報をまとめた課金記録情報ファイルを作成する手段と、課金処理システムからの要求に応じて、前記課金記録情報ファイルを該課金処理システムに送出する手段と
   を有することを特徴とする請求項１記載の課金記録情報収集装置。
3. 前記伝送路に現用系と待機系の２個の前記分岐装置が挿入されており、
   該２個の分岐装置の間に該伝送路上を伝送される信号を増幅する手段が設けられていることを特徴とする請求項１又は２に記載の課金記録情報収集装置。
4. 前記クラスは、接続先のサーバーのＩＰアドレス、接続先のサーバーのＩＰアドレスとポート番号の組み合わせ、又は、利用しているプロトコル種別に応じて設定されていることを特徴とする請求項１乃至３のいずれかに記載の課金記録情報収集装置。
5. 前記パケットログには、ＨＴＴＰリクエストに含まれているＵＲＬ又はＭＩＭＥタイプも記録されており、
   前記クラスは、ＵＲＬ又はＭＩＭＥタイプに応じて設定されていることを特徴とする請求項１乃至４のいずれかに記載の課金記録情報収集装置。
6. 前記パケットログには、前記上りのデータ伝送量及び前記下りのデータ伝送量が各レイヤーごとに集計されており、
   前記ＣＤＲ生成手段により生成される課金記録情報にどのレイヤーにおけるデータ伝送量を含ませるのかを選択することができるようになされていることを特徴とする請求項１乃至５のいずれかに記載の課金記録情報収集装置。
7. 前記パケットログには、上りの再送パケットのデータ伝送量と下りの再送パケットのデータ伝送量も集計するようになされており、
   前記ＣＤＲ生成手段による生成される課金記録情報に再送パケットのデータ伝送量を減算したデータ伝送量を含ませるか否かを選択することができるようになされていることを特徴とする請求項１乃至６のいずれかに記載の課金記録情報収集装置。
8. 前記ＣＤＲ生成手段は、当該ＲＡＤＩＵＳセッションがあらかじめ設定された時刻をまたぐものであるとき、その課金記録情報を該設定された時刻により分割して出力することができるようになされていることを特徴とする請求項１乃至７のいずれかに記載の課金記録情報収集装置。

Images