JP4261382B2 - 通信統計情報収集機能を備えたアクセスサーバ - Google Patents

Description

本発明は、通信統計情報収集機能を備えたアクセスサーバに関し、更に詳しくは、ユーザアクセス網とインターネットサービスプロバイダ網（ＩＳＰ網）に接続され、ユーザ端末毎に収集した通信統計情報を上記ＩＳＰ網に接続された通信統計情報管理用の課金サーバに通知する機能を備えたアクセスサーバに関する。

インターネットに代表されるＩＰ(Internet Protocol)ネットワークにおいて、ユーザ端末をＩＰネットワークに接続するためのサービスを提供する通信業者（網管理業者）は、インターネットサービスプロバイダ（ＩＳＰ：Internet Service Provider）と呼ばれている。ＩＳＰは、ユーザ端末によるアクセスサーバの利用に先立って、接続要求ユーザが予め契約した正規ユーザであることを確認して、アクセスサーバとユーザ端末との間にセッションを確立する。

アクセスサーバとユーザ端末との間にセッションを確立するための通信プロトコルとしては、ＰＰＰ（Point-to−Point Protocol）が広く利用されている。ＰＰＰは、元来、電話線や専用線などのシリアル回線上でＴＣＰ／ＩＰなどのリンクを提供するためのプロトコルであり、ＩＥＴＦ（Internet Engineering Task Force）においてＲＦＣ（Request For Comments）１６６１として標準化されている。

ＰＰＰは、ＯＳＩ参照モデルのデータリンク層で動作するＬＣＰ（Link Control Protocol）と、ネットワーク層で動作するＮＣＰ(Network Control Protocol)とで構成されている。ＬＣＰは、リンクを制御するプロトコルであり、データサイズ、データ圧縮の有無、伝送速度などの通信条件に関するネゴシエーション作業を経て、２つの通信装置間にデータリンクを確立した後、データリンクの検査および解放のための制御を行う。一方、ＮＣＰは、ＬＣＰによるリンク（ＬＣＰセッション）確立後に、ネットワーク層の上位プロトコルの選択やネットワークアドレスの割り当て／設定等を行う。尚、ＮＣＰには、ネットワークプロトコルの種類に応じた複数の制御プロトコルが用意されており、ＩＰやＡｐｐｌｅＴａｌｋなど各種プロトコルに適合できる。

ＩＳＰは、ユーザに関する個人情報および統計情報を属性（アトリビュート）値としてデータベース化し、例えば、認証サーバや課金サーバ等の管理サーバで一元的に管理している。上記管理サーバは、一般的にＩＰ網を介してインターネットのアクセスサーバと通信可能となっている。また、これらのサーバ間と、アクセスサーバとユーザ端末間のセッション管理には、通常、ＲＡＤＩＵＳ（Remote Authentication Dial In User Service）が利用される。ＲＡＤＩＵＳに関する通信プロトコルは、例えば、ＲＦＣ２１３８、ＲＦＣ２１３９、ＲＦＣ２８６５、ＲＦＣ２８６６、ＲＦＣ２８６９として規定されている。

ＲＡＤＩＵＳは、サーバ−クライアント方式を採用しており、上述したユーザ情報や統計情報などの属性情報を管理するサーバをＲＡＤＩＵＳサーバとし、ユーザからのアクセスを受け付けるアクセスサーバをＲＡＤＩＵＳクライアントとして動作させることによって、アクセスサーバとＲＡＤＩＵＳサーバ間での属性情報の送受信を可能としている。

ＲＡＤＩＵＳサーバの第１の役割は、ユーザ認証情報の管理にある。例えば、ユーザ端末からインターネット接続要求を受信したアクセスサーバは、該接続要求からユーザ名、パスワード等のユーザ認証情報を抽出し、これをＲＡＤＩＵＳ認証プロトコルに従ってＲＡＤＩＵＳサーバに送信する。ＲＡＤＩＵＳサーバは、アクセスサーバからユーザ認証情報を受信すると、データベースに予め登録されたユーザ認証情報と照合することによって、要求者が予め契約された正規のユーザか否かを判定し、判定結果をアクセスサーバに通知する。アクセスサーバは、上記認証の結果、接続要求ユーザが正規ユーザと判明した場合、ユーザ端末とアクセスサーバとの間にＰＰＰセッションの接続制御を実行する。

ＲＡＤＩＵＳサーバの第２の役割は、ユーザ毎の統計情報の管理にある。アクセスサーバは、ユーザ認証とＰＰＰ接続に成功した時、ユーザがインターネット利用を開始したことを示す制御パケットをＲＡＤＩＵＳサーバに送信し、該ユーザに関する統計情報の収集を開始する。ユーザがデータリンクを終了させた場合は、リンク解放（インターネット利用の終了）を示す制御パケットをＲＡＤＩＵＳサーバに送信する。この制御パケットによって、例えば、ＰＰＰリンクの接続時間や送受信データ量などの統計情報をＲＡＤＩＵＳサーバに通知できる。また、各制御パケットには、ユーザを識別するための識別子（ＩＤ）が付与されている。ＩＳＰの殆どは、上述したＲＡＤＩＵＳの機能を利用して、ユーザ認証や、課金情報およびネットワーク増設計画等の管理情報の収集を行っている。

近年、インターネットユーザの増加に伴って、既存のＩＰｖ４の他に、新たなアドレス体系をもつＩＰｖ６も使用できるデュアルスタックのネットワーク構築が行われている。ＰＰＰ上でＩＰｖ６を使用するためには、ＮＣＰにＩＰｖ６用の制御プロトコルを装備し、ＲＡＤＩＵＳにＩＰｖ６用のアトリビュートを定義することが必要となる。前者に関しては、既にＲＦＣ２４７２でＩＰｖ６ＣＰが定義されており、後者に関しては、ＲＦＣ３１６２でＲＡＤＩＵＳのＩＰｖ６サポートアトリビュートが定義されている。

ＰＰＰ上で使用すべきＩＰバージョンの指定は、認証要求に応答してＲＡＤＩＵＳサーバがアクセスサーバに返送する応答パケット（認証成功パケット）のアトリビュートとして、ＩＰｖ４関連のアトリビュートのみを送信するか、ＩＰｖ６関連のアトリビュートのみを送信する、ＩＰｖ４／ＩＰｖ６の両方のアトリビュートを送信するかによって、適用可能なＩＰプロトコルがそれぞれＩＰｖ４、ＩＰｖ６、ＩＰｖ４／ＩＰｖ６である旨を指定できる。

一方、ＮＣＰは、各ユーザ端末で独自に動作させることが可能であり、各ユーザは、ＬＣＰによりリンクを確立した後、リンクが解放されるまでの間に任意のＮＣＰを随時に確立し、随時に解放することが可能である。ユーザの管理は、アクセスサーバ内で設定したリンク（ＬＣＰセッション）毎にユニークなＩＤで管理される。そのため、従来は、上述したように１つのＰＰＰ上に複数のＮＣＰセッションが確立された場合、ＬＣＰで確立したリンク（ＬＣＰセッション）単位での統計情報は収集できるが、接続時間やデータ量などの統計情報をＮＣＰ単位で収集することはできなかった。

尚、通信統計情報の収集に関する従来技術として、例えば、特開２０００−１６３３７６号公報（特許文献１）には、ＩＰパケットのヘッダ解析によって、ＩＰパケットの利用プロトコルの種別、例えば、電子メール利用かＷｅｂ利用かを判定し、利用プロトコル別に最初のパケットから最後のパケットまでの通信時間を計測して、これを利用者毎のプロトコル別セッション時間として記録するトラフィック監視装置が提案されている。

また、特開２０００−２５２９７９号公報（特許文献２）は、多数のユーザ端末を収容したＣＡＴＶ網とインターネットとの接続システムにおいて、データ量プローブ部が、中継すべきＩＰパケットのヘッダ内容から、送信元アドレス、データ量、プロトコル種別（データ種別を含む）を判定し、これを内部バスを介してデータ量集計部に通知し、データ量集計部でＩＰアドレス別およびプロトコル別に統計データを集計することが提案されている。

特開２０００−１６３３７６号公報

特開２０００−２５２９７９号公報

前述したＲＡＤＩＵＳサーバに各ユーザの通信統計情報をＮＣＰ毎に収集するためには、例えば、ＲＡＤＩＵＳの属性（アトリビュート）として新たな属性を追加すればよいが、新たな属性の追加は、ＲＡＤＩＵＳサーバ側とＲＡＤＩＵＳクライアント（アクセスサーバ）側の双方でソフトウェアの変更が必要となるため、変更作業量が大きくなるという問題がある。

本発明の目的は、ＲＡＤＩＵＳへの属性追加を行うことなく、ＮＣＰ毎の統計情報の収集を可能としたアクセスサーバを提供することにある。

上記目的を達成するため、本発明は、ユーザ毎のセッション管理機能を備えたアクセスサーバにおいて、１つのデータリンク（ＰＰＰセッション）上に確立されたＬＣＰセッションとＮＣＰの双方について、接続時間や入出力データ量などの通信統計情報を計測する機能と、ＬＣＰセッション毎の統計情報とＮＣＰセッション毎の統計情報をインターネットサービスプロバイダ（ＩＳＰ）網に接続されたユーザ別通信情報管理用の課金サーバに所定のタイミングで通知する機能を備えたことを特徴とする。

更に詳述すると、本発明は、ユーザアクセス網とインターネットサービスプロバイダ（ＩＳＰ）網に接続されたアクセスサーバであって、上記ユーザアクセス網に接続されたユーザ端末からのデータリンク確立要求に伴ってＬＣＰで形成されるセッション毎に通信統計情報を収集しておき、上記データリンクが解放された時、上記ＩＳＰ網に接続された通信統計情報管理用の課金サーバに対して該当ＬＣＰセッションの統計情報を通知するための第１手段と、上記ＬＣＰセッション上に確立されたＮＣＰセッション毎に通信統計情報を収集しておき、ＮＣＰセッションが解放された時、上記課金サーバに対して解放ＮＣＰセッションの統計情報を通知するための第２手段を有することを特徴とする。

本発明の１つの特徴は、上記第１手段が、ＬＣＰセッションの確立に伴って、課金サーバに該ＬＣＰセッションの統計処理開始要求を送信し、データリンクが解放された時、上記課金サーバに対して該当ＬＣＰセッションの統計情報を含む統計処理終了要求を送信し、上記第２手段が、ＮＣＰセッションの確立に伴って、上記課金サーバに該ＮＣＰセッションの統計処理開始要求を送信し、ＮＣＰセッションが解放された時、上記課金サーバに対して解放ＮＣＰセッションの統計情報を含む統計処理終了要求を送信するようにした点にある。但し、アクセスサーバから課金サーバへの統計情報の通知は、上述したように、データリンクまたはＮＣＰセッションの解放時に限定されるものではなく、ユーザ端末が通信状態にある間に周期的に行われてもよい。

本発明の他の特徴は、上記第１手段が、ＬＣＰセッション毎に固有の識別子を付したパケットによって、ＬＣＰセッション統計情報を課金サーバに通知し、上記第２手段が、ＮＣＰセッション毎に固有の識別子を付したパケットによって、解放ＮＣＰセッションの統計情報を上記課金サーバに通知する。ここで、ＮＣＰセッション識別子は、例えば、ＩＰＣＰやＩＰｖ６ＣＰのように、適用するＩＰ制御プロトコルの種類よって異なるだけでなく、同一のＩＰ制御プロトコルによるセッションであっても、一旦解放して再度確立したセッションには従前のものとは異なる識別子を付与することができる。

本発明の好適な実施例では、課金サーバ側でＬＣＰセッション統計情報とＮＣＰセッション統計情報との対応付けができるように、上記第２手段が、ＮＣＰセッション毎に固有の識別子と該ＮＣＰセッションが所属するＬＣＰセッションの識別子との組み合せからなるセッション識別子を含むパケットによって、解放ＮＣＰセッションの統計情報を課金サーバに通知する。

また、上記課金サーバが、ユーザ認証機能を備えたＲＡＤＩＵＳサーバとしてＩＳＰ網に接続されていた場合、上記第１、第２手段が、それぞれの統計情報をＲＡＤＩＵＳプロトコルに従ったパケット形式で上記課金サーバに通知する。

本発明によれば、同一のユーザが同一のリンク（ＰＰＰセッション）上で複数のＮＣＰプロトコルを動作させた場合でも、アクセスサーバ側が、ＮＣＰセッション毎に統計情報を収集し、これにセッション毎に固有のＩＤを付与して課金サーバ（ＲＡＤＩＵＳサーバ）に通知することによって、課金サーバ側で、接続時間や入出力データ量などの統計情報をユーザ毎、セッション毎に区分けして管理することが可能となる。インターネットにおいては、ＩＰｖ４セッションとＩＰｖ６セッションが、それぞれ別々のバックボーンで運営される場合があるため、本発明のようにＮＣＰセッション毎に統計情報を管理することによって、ネットワークの運用と設計に有効な情報が得られる。

以下に、本発明の実施形態について図面を参照して説明する。

図１は、本発明のアクセスサーバが適用されるネットワーク構成の第１実施例を示す。

図１において、１は複数のユーザ端末３０（３０−１、３０−２、…）が接続されるユーザアクセス網、２はインターネットサービスプロバイダ（ＩＳＰ）網、３はＩＳＰ網２に接続されたインターネットを示す。ユーザアクセス網１は、例えば、公衆の電話交換機網や、ＡＤＳＬやＦＴＴＨ等のブロードバンド網からなる。ＩＳＰ網２には、認証サーバ１０と統計情報を管理する課金サーバ２０とが接続されている。また、インターネット３には、ユーザが利用する各種情報サービス用のサーバ７（７−１、７−２、…）が接続されている。

ユーザ端末３０（３０−１、３０−２、…）は、インターネットサービスプロバイダに属するユーザ端末であり、ユーザアクセス網１とアクセスサーバ４を介してＩＳＰインターネットサービスプロバイダ網２に接続されている。ユーザ端末３０とアクセスサーバ４との間では、ユーザ端末が使用するリンクの確立、ユーザ認証およびＩＰアドレスの割当を行うためのプロトコルとしてＰＰＰが使用される。ＰＰＰは、ユーザアクセス網１に直接接続されたユーザ端末３０−１の場合は、ユーザ端末３０−１が終端し、例えば、家庭用のルータ６を介してユーザアクセス網１に接続されたユーザ端末３０−２の場合は、ルータ６が終端することになる。

図２は、図１に示したネットワークにおいて、ユーザ端末３０−１とインターネット３上の目的サーバ７が、アクセスサーバ４を介して通信するための必要となる主信号系転送プロトコルスタックの１例を示す。

ユーザ端末３０−１とアクセスサーバ４はＰＰＰによって接続されているため、ユーザ端末３０−１のプロトコルスタック５００とアクセスサーバ４のプロトコルスタック５０１には、ＰＰＰプロトコルスタックが存在する。ＰＰＰよりも下位のプロトコルスタックは、ユーザアクセス網１のリンク層のタイプによって異なる。図では、１例として、リンク層がイーサネット（Ｅｔｈｅｒｎｅｔ：登録商標名）の場合を示している。アクセスサーバ４から目的サーバ７までは、プロトコルスタック５０２、５０３が示すように、ＩＰｖ４／ＩＰｖ６（ＩＰｖ４プロトコルまたはＩＰｖ６プロトコル）に従って転送される。

図３は、ユーザ認証情報、統計情報（課金情報）およびその収集条件などの制御情報の通信に必要となる制御系転送プロトコルスタックの１例を示す。

プロトコルスタック５０４、５０５が示すように、ユーザ端末３０−１とアクセスサーバ４との間では、制御情報がＰＰＰプロトコルによって通信される。一方、アクセスサーバ４とＩＳＰ網の認証サーバ１０、課金サーバ２０との間では、プロトコルスタック５０６、５０７が示すように、ＲＡＤＩＵＳプロトコルによって制御情報が通信される。後述するように、ＲＡＤＩＵＳプロトコルでは、ＲＡＤＩＵＳアトリビュート（属性値）が規定されており、認証サーバ１０と課金サーバ２０は、パケットのデータ部（ペイロード部）にそれぞれが必要とするアトリビュートを付与することによって、アクセスサーバ４との間で認証処理および統計情報収集（課金処理）に必要な制御情報を送受信する。

図４は、アクセスサーバ４のハードウエア構成の１例を示すブロック図である。

アクセスサーバ４は、サーバ全体の制御を行なう制御処理部４４と、パケットを所定の回線に出力するためのスイッチ部４３と、データリンク層やその上位層であるＩＰプロトコルを処理する複数のプロトコル処理部４２（４２−１〜４２−ｎ）と、それぞれ接続回線の種別に応じた物理層終端機能を備えた複数の回線インタフェース（ＩＦ）４１（４１−１Ａ〜４１−ｎＢ）とからなる。ここで、回線インタフェース４１−１Ａ、４１−２Ａ、…４１−ｎＡは入力回線用のインタフェース、回線インタフェース４１−１Ｂ、４１−２Ｂ、…４１−ｎＢは出力回線用のインタフェースを示している。

図５は、アクセスサーバ４を制御する制御処理部４４の１実施例を示すブロック図である。

制御処理部４４は、メモリ５０と、データプロセッサ（ＣＰＵ）４４１と、外部に設置された制御端末と通信するための制御端末インタフェース（ＣＬＩ：Command Line Interface）４４２と、プロトコル処理部４２と通信するためのプロトコル処理部インタフェース４４３と、スイッチ部４３と通信するためのＳＷ部インタフェース４４４とで構成される。ＣＰＵ４４１は、メモリ５０に用意された後述する各種のプログラムを実行する。

メモリ５０には、本発明に関係するプログラムとして、例えば、ＣＬＩ（Command Line Interface）処理ルーチン５１と、ルーティングプロトコル処理ルーチン５２と、警報監視処理ルーチン５３と、ＰＰＰプロトコル処理ルーチン５４と、ＲＡＤＩＵＳプロトコル処理ルーチン５７が記憶され、この他に、ＰＰＰユーザ管理テーブル５５とセッション管理テーブル５６が形成されている。

ＣＬＩ処理ルーチン５１は、アクセスサーバ４を制御するためにシステム管理者が図示しない制御端末からＣＬＩ４４２に入力した制御コマンドを処理するためのプログラムである。ルーティングプロトコル処理ルーチン５２は、各ルーティングプロトコル処理部４２が、回線インタフェース４１からの入力パケットを宛先アドレスに対応した他の何れかの回線インタフェースに転送する際に必要とするルーティング情報を処理するためのプログラムである。システム管理者が指定したルーティング情報は、上記ルーティングプロトコル処理ルーチン５２によって、各プロトコル処理部４２が備えるＩＰｖ４用またはＩＰｖ６用のルーティングテーブル（図示せず）に設定される。

各プロトコル処理部４２は、受信パケットを上記ルーティングテーブルを参照してルーティング処理する。すなわち、各入力回線インタフェース４１−ｉＡ（ｉ＝１〜ｎ）がネットワークから受信したパケットは、プロトコル処理部４２−ｉにおいて、例えば、パケットヘッダの宛先アドレスと対応したルーティング情報を含む内部ヘッダを付加した後、スイッチ部４３に転送される。ＰＰＰプロトコル処理およびＲＡＤＩＵＳプロトコル処理に必要な情報は、制御処理部４４に転送される。スイッチ部４３は、各プロトコル処理部４２からの入力パケットを内部ヘッダが示すルーティング情報に従って他の何れかのプロトコル処理部に転送する。各プロトコル処理部４２−ｊ（ｊ＝１〜ｎ）は、スイッチ部４３から受信したパケットから内部ヘッダを除去し、該パケットを出力回線インタフェース４１−ｊＢに出力する。

警報監視処理ルーチン５３は、アクセスサーバ４の内部で発生する警報信号を監視し、警報信号に応答した動作を行なうプログラムである。また、ＰＰＰプロトコル信号を処理するＰＰＰプロトコル処理ルーチン５４は、プロトコル処理部４２と連携して、ＲＦＣ１３３２、ＲＦＣ１６６１、ＲＦＣ１９９４、ＲＦＣ２４７２、ＲＦＣ２５１６などのＰＰＰに関するＲＦＣに従って、ＰＰＰ終端処理、ＬＣＰ（Link Control Protocol）処理、ＰＡＰ（Password Authentication Protocol）やＣＨＡＰ（Challenge Handshake Authentication Protocol）などの認証処理、ＩＰＣＰ（Internet Protocol Control Protocol）やＩＰｖ６ＣＰなどのＮＣＰ処理のようなＩＰレイヤ、ＩＰｖ６レイヤの処理を実行する。

ＲＡＤＩＵＳプロトコル処理ルーチン５７は、ＲＦＣ２１３８、ＲＦＣ２１３９、ＲＦＣ２８６５、ＲＦＣ２８６６、ＲＦＣ３１６２などのＲＡＤＩＵＳプロトコルの全般を扱い、ＰＰＰ認証時には、ＰＰＰプロトコル処理ルーチン５４と連携して、認証サーバ１０にユーザＩＤやパスワードなどの情報を転送する。

ユーザ認証に成功した場合、認証サーバ１０は、認証されたユーザに関するアトリビュート情報として、例えば、該ユーザが使用すべきＩＰアドレスなどのネットワーク設定条件をアクセスサーバ４に通知する。アクセスサーバ４は、認証サーバ１０から通知された各ユーザに関するアトリビュート情報を、ＰＰＰセッションが解放されるまでの間、ＰＰＰユーザ管理テーブル５５に記憶する。

認証に成功したユーザ端末３０が、アクセスサーバ４との間にＬＣＰセッションを確立すると、アクセスサーバ４は、統計情報（課金情報）の収集処理を開始する。統計情報としては、接続時間やパケット通過量などの情報をＬＣＰセッション毎、ＮＣＰセッション毎に収集する必要がある。本発明では、ＬＣＰおよびＮＣＰの新たなセッションが確立された時、セッション管理テーブル５６に新たなセッション識別子をもつエントリを生成し、該エントリで接続時間やパケット通過量などの統計情報を管理する。好ましいセッション識別子の生成方法については、後で詳述する。

アクセスサーバ４は、ＰＰＰユーザのＬＣＰセッションの確立を確認すると、ＲＡＤＩＵＳプロトコル処理ルーチン５７で課金（統計情報収集）処理の開始要求パケットを生成し、これを課金サーバ２０に送信する。ＰＰＰユーザがＮＣＰまたはＬＣＰセッションを解放した場合、アクセスサーバ４は、ＲＡＤＩＵＳプロトコル処理ルーチン５７で解放セッションの課金処理終了要求パケットを生成し、これを課金サーバ２０に送信する。

アクセスサーバ４は、ＰＰＰセッションが継続中に収集した統計情報をセッション管理テーブル５６に蓄積しておき、セッション解放時に生成される上記課金処理終了要求パケットによって統計情報を課金サーバ２０に通知する。但し、定期的またはネットワークにおける輻輳や障害の発生／回復などのイベントを契機として、ＲＡＤＩＵＳプロトコル処理ルーチン５７で統計情報の現在値を示す中間アカウンティングパケットを生成し、これを課金サーバ２０に送信するようにしてもよい。統計情報は、送信パケットのデータ部に、ＲＡＤＩＵＳプロトコルで規定されたＲＡＤＩＵＳアトリビュートを設定することによって、任意種類の情報を送受信できる。

次に、図６〜図１１を参照して、本発明のアクセスサーバ４の動作について説明する。

図６は、ユーザ端末３０（ＰＰＰユーザ）からデータリンクの確立要求を受信してからＰＰＰセッションを解放するまでの間のアクセスサーバ４の動作を示す。

アクセスサーバ４は、ユーザ端末３０やルータ６からＰＰＰ接続要求を受信すると、ユーザ端末との間でデータリンク（ＰＰＰセッション）の確立手順とＬＣＰネゴシエーションを実行し（ステップ１００）、ユーザ端末からの認証要求を待つ。ユーザ端末から認証要求を受信すると、ＲＡＤＩＵＳプロトコル処理部５７で認証サーバ１０宛の認証要求パケットを生成し、これを認証サーバ１０に送信して、認証サーバ１０からの応答を待つ（１０２）。認証が失敗した場合は、セッション接続を拒否してこのルーチン終了する（１１４）。認証に成功した場合は、ＰＰＰユーザ管理テーブル５５にＰＰＰユーザと対応する新たなエントリを作成する（１０３）。

ＰＰＰユーザ管理テーブル５５の１例を図８に示す。ここに示した例では、ＰＰＰユーザ管理テーブル５５の各エントリ５５０（５５０−１、５５０−２、５５０−３、…）は、ユーザ名（ユーザＩＤ）フィールド５５１と、ユーザに与えるＩＰｖ４アドレスを示すFramed IP Addressフィールド５５２と、ユーザに与えるＩＰｖ６プレフィックスを示すFramed IPv6 Prefixフィールド５５３とからなる。ＰＰＰコネクションは、ユーザによって異なったネットワーク条件で設定される可能性があるため、ＰＰＰユーザ管理テーブル５５の各エントリは、上記全てのフィールドにデータ登録がなされるとは限らない。また、テーブルエントリには、５５１〜５５３以外の他のフィールドが追加される場合もある。

アクセスサーバ４は、ＰＰＰユーザ管理テーブル５５に新たなエントリを追加した後、ＬＣＰセッション用のＩＤを生成し（１０４）、セッション管理テーブル５６に該ＬＣＰセッションＩＤもつ新たなエントリを追加する（１０５）。ＰＰＰセッション確立時に生成されるＬＣＰ用セッションＩＤは、既に確立している他のＰＰＰセッションのＬＣＰセッションＩＤとは異なるユニークな値となっている。

図９は、セッション管理テーブル５６の１例を示す。

セッション管理テーブル５６の各エントリ５６０（５６０−１、５６０−２、５６０−３、…）は、セッションＩＤフィールド５６１と、ユーザ名フィールド５６２と、ＬＣＰセッション上で適用されるネットワーク層プロトコルを示すＮＣＰフィールド５６３と、セッションの接続開始時刻を示すフィールド５６４と、統計情報の計数フィールドとからなっている。ここに示した例では、統計情報の計数フィールドは、入力パケット計数フィールド５６５ａと、出力パケット計数フィールド５６５ｂとを含んでいる。ＬＣＰセッション確立時に作成されたエントリでは、例えば、エントリ５６０−１が示すように、ＮＣＰフィールド５６３が空欄となっている。

アクセスサーバ４は、セッション管理テーブル５６にエントリを追加した後、ＬＣＰセッションの統計情報の測定を開始する（１０６）。ＬＣＰ用の統計情報は、ＮＣＰ５６３が不特定となっているため、ＰＰＰ上の全てのＮＣＰを対象として統計データが測定される。この測定は、ＰＰＰの終端点となるプロトコル処理回路４２−ｉで行われ、ここで測定された統計データが定期的にセッション管理テーブル５６に収集される。

アクセスサーバ４は、ＬＣＰセッションを確立した後、課金サーバ２０に対してＬＣＰセッションの統計処理の開始を要求する課金開始要求パケットを送信する（１０７）。上記課金開始要求パケット（Accounting-Request[start]には、ＲＡＤＩＵＳのアトリビュートとして、例えば、インターネット接続要求元となったユーザ端末３０を識別するためのユーザ名を示すUser-Nameアトリビュート、ユーザ端末に割り当てたＩＰアドレスを示すFramed-IP-Addressアトリビュート、要求パケットの種別（課金開始、課金終了、中間アカウンティングの区別）を示すAcct-Status-Typeアトリビュート、ユーザ端末とアクセスサーバとの間のデータリンク（ＬＣＰセッション）を識別するためのAcct-Session-IDアトリビュートが含まれる。

課金開始要求パケットのAcct-Status-Typeアトリビュートには、課金処理の開始要求であることを示すstart(1)コードが設定される。Acct-Session-IDアトリビュートには、ＬＣＰ用セッションＩＤを割り当てればよく、User-Nameアトリビュート、Framed-IP-Addressアトリビュートなどの設定値は、ＰＰＰユーザ管理テーブル５５から得られる。

リンクレベルの全ての処理が完了すると、アクセスサーバ４は、ネットワーク層プロトコルをいつでもオープンできるように、該当ＰＰＰセッションをネットワーク層プロトコルフェーズに移行する（１０８）。ネットワーク層プロトコルフェーズの動作については、図７を参照して後述する。アクセスサーバ４は、回線切断要求や強制的な回線切断などのイベントが発生しない限り、ネットワーク層プロトコルフェーズを維持する。回線切断要求や強制的な回線切断イベントが発生すると、以下に説明するリンク終了フェーズに遷移する（１０９）。

リンク終了フェーズへ遷移すると、アクセスサーバ４は、ＬＣＰセッション用の統計情報の測定を終了し、解放されたＬＣＰセッション（ＰＰＰ）と対応するプロトコル処理回路４２−ｉから該当する統計情報をセッション管理テーブル５６に収集する（１１０）。この後、統計情報を含む課金終了要求パケット（Accounting-Request[stop]）を生成し、これを課金サーバ２０に送信する（１１１）。上記課金終了パケットの具体的なフォーマットについては後述する。

課金終了要求パケットの送信後、アクセスサーバ４は、セッション管理テーブル５６から上記解放ＬＣＰセッションに該当するエントリを削除し（１１２）、ＰＰＰユーザ管理テーブル５５から上記解放ＬＣＰセッションに該当するユーザのエントリを削除して（１１３）、このルーチンを終了する。

次に、図７を参照して、ネットワーク層プロトコル（ＮＣＰ）フェーズに移行（１０８）したアクセスサーバ４の動作について説明する。

ネットワーク層プロトコルフェーズでは、任意のＮＣＰを随時に確立できる。アクセスサーバ４は、ユーザ端末３０からのＮＣＰのｏｐｅｎ要求を監視し（１２０）、ｏｐｅｎ要求があった場合は、ＮＣＰ用の新たなセッションＩＤを生成する（１２１）。ＮＣＰ用のセッションＩＤは、同一ＰＰＰ上の形成されるＮＣＰセッション毎にユニークな値となる。上記セッションＩＤの値は、他種類のＮＣＰのセッションＩＤと異なるだけでなく、同一ＮＣＰで確立されたセッションであっても、セッションを一旦解放して、その後に再びセッションを確立した場合は、これらを別々のセッションとして識別できるように、セッション毎に異なった値とする。

アクセスサーバ４は、上記セッションＩＤをもつ新たなエントリを生成して、セッション管理テーブル５６に追加し（１２２）、ＮＣＰセッション用の統計情報の収集を開始する（１２３）。ここで生成されるテーブルエントリは、ＬＣＰセッション確立時に作成されたエントリ５６０−１とは異なって、例えば、エントリ５６０−２、５６０−３が示すように、ＮＣＰフィールド５６３に、“ＩＰＣＰ”や“ＩＰｖ６ＣＰ”などの適用ＮＣＰの識別情報を含んでいる。

ＮＣＰセッション用の統計情報の測定では、セッション管理テーブル５６で指定された特定のＮＣＰを対象として、各ユーザの通信統計情報が測定される。この測定は、ＬＣＰセッション用の統計情報と同様、ＰＰＰの終端点となるプロトコル処理回路４２−ｉで行われ、ここで測定された統計データが定期的にセッション管理テーブル５６の計数フィールドに収集される。

アクセスサーバ４は、ＮＣＰによるセッションが確立した時点で、課金サーバ２０に課金開始要求パケットを送信する（１２４）。ここで送信される課金開始要求パケット（Accounting request[start]）は、ＬＣＰ用統計情報の測定開始時に、図６のステップ１０７で送信された課金開始要求パケットのＲＡＤＩＵＳアトリビュートの他に、例えば、ＩＰＣＰでユーザ端末に割り当てたＩＰアドレスを示すFramed-IP-Addressアトリビュートのように、適用ＮＣＰによるユーザ割り当て情報を示すアトリビュートを含む。

ここで、ユーザ端末とアクセスサーバとの間のＰＰＰセッションの識別子となるAcct-Session-IDアトリビュートの設定値には、多少の工夫が必要となる。なぜなら、ＲＡＤＩＵＳサーバでは、課金開始要求パケットの送信元アクセスサーバのＩＰアドレスとAcct-Session-IDアトリビュートが示すＰＰＰセッション識別子によって、課金要求パケットを識別している。従って、上述したように、ＮＣＰ用セッションＩＤとＬＣＰ用セッションＩＤとを異なった値にしておけば、課金サーバ２０側では、ステップ１０８で送信された要求パケットとステップ１２４で送信された要求パケットを別々の課金開始要求パケットとして処理することが可能となる。しかしながら、この場合は、課金サーバ２０において、ＬＣＰセッションと、その上に多重化されるＮＣＰセッションとの関連付けが困難となってしまう。

図１０は、ＮＣＰ用のセッションＩＤとＬＣＰ用のセッションＩＤとの関連付けを可能としたAcct-Session-ID６０７の１例を示す。

ＲＦＣの規定では、Acct-Session-ID用の文字として、数字以外にアルファベットも使用可能であり、文字数の制限もない。そこで、Acct-Session-ID６０７として、図１０に示すように、ＬＣＰのセッションＩＤ６４１と、ＮＣＰ識別子６４２と、ＮＣＰセッションＩＤ６４３と、その他識別子６４４との組み合せからなる文字列を適用すれば、課金サーバ２０で統計情報を処理する際に、ＮＣＰセッションの課金開始要求パケットに付されたAcct-Session-IDから、このＮＣＰセッションとＬＣＰセッションとを関連付けることができる。

図７に戻って、課金開始要求パケットを送信したアクセスサーバ４は、ユーザ端末からのＮＣＰクローズ要求の受信を待機し（１２５）、クローズ要求を受信した時、該当するプロトコル処理回路４２−ｉにＮＣＰ用統計情報の測定終了を指示し、クローズされたＮＣＰの統計情報をセッション管理テーブル５６に収集する（１２６）。アクセスサーバ４は、上記ＮＣＰの統計情報を含む課金終了要求パケットを生成し、これを課金サーバ２０に送信（１２７）した後、セッション管理テーブル５６から上記クローズされたＮＣＰと対応するテーブルエントリを削除する（１２８）。ここで、データリンク解放の有無をチェックし（１２９）、データリンクが解放されていなければ、ステップ１２０に戻って、新たなＮＣＰのｏｐｅｎ要求を待つ（１２０）。

データリンクが解放された場合は、ネット層プロトコル（ＮＣＰ）フェーズの処理を終了し、図６に示したステップ１０９以降の処理を実行する。尚、アクセスサーバ４は、課金開始要求パケットを送信（１２４）した後、定期的に中間アカウンティング用のパケットを生成し、最新の統計情報を課金サーバに通知するようにしてもよい。

図１１は、ＩＰｖ４用の課金終了要求パケット（Accounting-Request [stop]）６００Ａのフォーマットの１例を示す。

ＩＰｖ４用の課金終了要求パケット６００Ａは、ＩＰヘッダ６０１およびＵＤＰヘッダ６０２と、このパケットが課金処理用の要求パケットであることを示すＲＡＤＩＵＳ識別コードフィールド６０３と、これに続くＲＡＤＩＵＳアトリビュート領域とからなる。ここで、ＲＡＤＩＵＳアトリビュート領域に記述された各アトリビュートの括弧内の数字は、ＲＦＣで規定されているアトリビュートタイプの値を示している。

ＩＰｖ４用の課金終了要求パケット６００Ａのアトリビュート領域には、インターネット接続要求元となるユーザ端末の識別情報となるユーザ名を示すUser-Nameアトリビュート６０４と、ユーザに割り当てられたＩＰｖ４アドレスを示すFramed-IP-Addressアトリビュート６０５Ａと、課金要求パケットの種別コード、課金終了の場合はstop(2)を示すAcct-Status-Typeアトリビュート６０６と、セッション識別用のAcct-Session-IDアトリビュート６０７と、セッションの存続時間を示すAcct-Session-Timeアトリビュート６０８と、セッションの終了要因を示すアトリビュート６０９と、入出力データ量を示すAcct-Input-Octetsアトリビュート６１０、Acct-Output-Octetsアトリビュート６１１、Acct-Input-Packetsアトリビュート６１２、Acct-Output-Packetsアトリビュート６１３、Acct-Input-Gigawordsアトリビュート６１４、Acct-Output-Gigawordsアトリビュート６１５が含まれる。入出力データ量などの統計情報は、全てＩＰｖ４に関係するものとなる。

尚、ＬＣＰ用の統計情報測定終了時に送信される課金終了要求パケットでは、Acct-Session-IDアトリビュート６０７、Acct-Session-Timeアトリビュート６０８、セッションの終了要因アトリビュート６０９が、それぞれ終了したＰＰＰセッションの識別子、存続時間、終了要因を示し、入出力データ量を示すアトリビュート６１０〜６１５は、全て上記ＰＰＰセッションにおける測定値を示す。一方、ＮＣＰ用の統計情報測定終了時に送信される課金終了要求パケットでは、Acct-Session-IDアトリビュート６０７、Acct-Session-Timeアトリビュート６０８、セッションの終了要因アトリビュート６０９が、それぞれ終了したＮＣＰ、例えば、ＩＰＣＰ用のセッションの識別子、存続時間、終了要因を示し、入出力データ量を示すアトリビュート６１０〜６１５は、全て上記ＮＣＰセッションにおける測定値を示す。

図１２は、ＩＰｖ６用の課金終了要求パケット６００Ｂのフォーマットの１例を示す。

ＩＰｖ６用の課金終了パケット６００Ｂも、ＩＰヘッダ６０１およびＵＤＰヘッダ６０２と、ＲＡＤＩＵＳ識別コードフィールド６０３と、これに続くＲＡＤＩＵＳアトリビュート領域とからなり、ＲＡＤＩＵＳアトリビュート領域に、ＩＰｖ４用の課金終了パケット６００Ａと同様のアトリビュートを含む。但し、Framed-IP-Addressアトリビュート６０５Ａの代りに、ユーザに割り当てられたＩＰｖ６プレフィックスを示すFramed-IPv6-Prefixアトリビュート６０６Ｂを含み、入出力データ量などの統計情報は、全てＩＰｖ６に関するものとなる。

また、ＮＣＰ用の統計情報測定終了時に送信されるＩＰｖ６用の課金終了要求パケットでは、Acct-Session-IDアトリビュート６０７、Acct-Session-Timeアトリビュート６０８、セッションの終了要因アトリビュート６０９が、それぞれ終了したＮＣＰ、例えば、ＩＰｖ６ＣＰ用のセッションの識別子、存続時間、終了要因を示し、入出力データ量を示すアトリビュート６１０〜６１５は、全て上記ＮＣＰセッションにおける測定値を示す。

図１３と図１４は、図１に示したシステム構成におけるユーザ端末３０（３０−１、３０−２）からインターネット３への接続手順と、アクセスサーバ４による統計情報（課金情報）の収集手順を示すシーケンス図である。

図１３は、ユーザ端末３０が、データリンク（ＰＰＰセッション）上に、ＩＰｖ４を扱うＩＰＣＰによるセッションとＩＰｖ６を扱うＩＰｖ６ＣＰによるセッションとを確立して、ＩＳＰ網２を介してインターネット３側のサーバとデータ通信する場合のシーケンスを示している。但し、ここでは、説明を簡単化するために、本発明に関係する主要シーケンスを示したに過ぎず、実際の応用においてユーザ端末３０とアクセスサーバ４、アクセスサーバ４と課金サーバ２０との間で交信される全てのメッセージを正確に示したものではない。

ユーザ端末３０は、アクセスサーバ４との間で、データリンクを確立（Ｓ４０）した後、ＬＣＰネゴシエーション（Ｓ４１）を行う。データリンク（ＰＰＰセッション）は、ユーザ端末３０が、例えば、ＲＦＣ２５１６で示されるＰＰＰｏＥの初期化処理を実行し、上記ユーザ端末３０に接続されたアクセスサーバ４のプロトコル処理回路４２−ｉが、ＰＰＰｏＥの初期化処理を実行し、制御処理部４４がＰＰＰプロトコル処理ルーチン５４を実行することによって確立される。ＰＰＰセッションが確立されると、アクセスサーバ４の制御処理部４４は、ユーザ端末３０との間でＬＣＰのネゴシエーションを実行し、リンクレイヤを設定する（Ｓ４１）。
アクセスサーバ４は、ユーザ端末３０からの認証要求（Ｓ４２）に応答して、例えば、ＲＦＣ１９９４に示されるＣＨＡＰ（Challenge Handshake Authentication Protocol
）に従って、認証サーバ１０にユーザ認証を要求する（Ｓ４３）。具体的には、アクセスサーバ４の制御処理部４４が、ＲＡＤＩＵＳプロトコル処理ルーチン５７を実行し、ユーザ名やパスワードを示す認証要求（Access-Request）パケットを認証サーバ１０に送信する。
認証サーバ１０は、上記認証要求パケットが示すパスワードが、予めユーザ名と対応して登録されたものか否かによって、ユーザ端末３０にＩＳＰ網２への接続の可否を判定し、判定結果をアクセスサーバ４に通知する（Ｓ４４）。ユーザ認証に成功した場合は、アクセスサーバ４は、ユーザ端末３０に対して、認証成功を示す応答パケットを送信し（Ｓ４５）、図６のステップ１０３〜１０６で説明したように、セッション管理テーブルにＬＣＰ用テーブルエントリを生成し、ＬＣＰ用統計情報の測定を開始した後、課金サーバ２０に対して、統計情報収集（ＬＣＰ課金処理）の開始要求パケット（Accounting-Request [start]）を送信する（Ｓ４６）。課金サーバ２０は、上記開始要求パケットが示すユーザ名に従って、課金情報データベースにおける課金情報管理レコードの有無を確認し、その後にアクセスサーバ４から送信されてくる統計情報の記録準備を整えて、課金確認応答パケット（Accounting-Response）を返送する（Ｓ４７）。
アクセスサーバ４は、ＬＣＰ課金開始要求を送信した後、図７で説明したネットワーク層プロトコルフェーズに移行して、ユーザ端末からのＮＣＰのｏｐｅｎ要求待ちの状態となっている。本実施例では、認証成功の応答パケット（Ｓ４５）を受信したユーザ端末３０が、先ず、ＩＰｖ４対応のＩＰＣＰのｏｐｅｎ要求を発行した場合を想定している。
アクセスサーバ４は、上記ＩＰＣＰ（ＩＰｖ４）のｏｐｅｎ要求を受信すると、ユーザ端末３０との間でＮＣＰネゴシエーション（Ｓ５０）を行う。ネゴシエーションに成功すると、アクセスサーバ４は、図７のステップ１２１〜１２３で説明したように、セッション管理テーブルにＮＣＰ（ＩＰＣＰ）用のテーブルエントリを生成し、ＮＣＰ用統計情報の収集を開始した後、課金サーバ２０に対して、ＩＰｖ４統計情報収集（ＩＰｖ４課金処理）の開始要求パケット（Accounting-Request [start]）を送信する（Ｓ５１）。課金サーバ２０は、課金情報データベースにおける課金情報管理レコードの有無を確認し、統計情報の記録準備を整えて、課金確認応答パケット（Accounting-Response）を返送する（Ｓ５２）。
ユーザ端末３０は、ＮＣＰネゴシエーション（Ｓ５０）が完了すると、ＩＳＰ網２を介して、インターネット３側のサーバとＩＰｖ４プロトコルによるデータ通信状態（Ｓ５３）となる。本実施例では、ユーザ端末が上記ＩＰｖ４プロトコルによるデータ通信状態を維持したまま、ＩＰｖ６ＣＰのｏｐｅｎ要求を発行した場合を想定している。
アクセスサーバ４は、上記ＩＰｖ６ＣＰのｏｐｅｎ要求を受信すると、ユーザ端末３０との間でＮＣＰネゴシエーション（Ｓ６０）を行う。ネゴシエーションに成功すると、アクセスサーバ４は、図７のステップ１２１〜１２３で説明したように、セッション管理テーブルにＮＣＰ（ＩＰｖ６ＣＰ）用のテーブルエントリを生成し、ＮＣＰ用統計情報の収集を開始した後、課金サーバ２０に対して、ＩＰｖ６統計情報収集（ＩＰｖ６課金処理）の開始要求パケット（Accounting-Request [start]）を送信する（Ｓ６１）。課金サーバ２０は、ＩＰｖ４課金処理の開始要求時と同様、課金情報データベースにおける課金情報管理レコードの有無を確認し、統計情報の記録準備を整えて、課金確認応答パケット（Accounting-Response）を返送する（Ｓ６２）。

ユーザ端末３０は、ＮＣＰネゴシエーション（Ｓ６０）が完了すると、ＩＳＰ網２を介して、インターネット３側のサーバとＩＰｖ６プロトコルによるデータ通信状態（Ｓ６３）となる。

図１４は、ＮＣＰセッションおよびインターネット接続の終了時のシーケンスを示している。
ＩＰｖ４、ＩＰｖ６でデータ通信状態（Ｓ５３、Ｓ６３）状態にあったユーザ端末３０が、ＩＰｖ４ＮＣＰの終了要求であるＩＰＣＰターミネーション要求を送信すると（テップＳ５４）、アクセスサーバ４は、該当ＮＣＰ（＝ＩＰＣＰ）における統計情報収集の終了処理（図７のステップ１２６）を実行した後、ＮＣＰ課金サーバ２０に対して、上記統計情報を含む図１１に示したＩＰｖ４用課金終了要求パケットを送信する（Ｓ５５）。課金サーバ２０は、上記ＩＰｖ４用課金終了要求パケットが示す統計情報に基づいて課金データベースを更新した後、アクセスサーバ４に課金確認応答（Accounting-Response）パケットを返信する（Ｓ５６）。
これと同様に、ユーザ端末３０が、ＩＰｖ６ＣＰのターミネーション要求を送信すると（Ｓ６４）、アクセスサーバ４は、該当ＮＣＰ（＝ＩＰｖ６ＣＰ）における統計情報収集の終了処理を実行した後、ＮＣＰ課金サーバ２０に対して、上記統計情報を含む図１２に示したＩＰｖ６用課金終了要求パケットを送信する（Ｓ６５）。課金サーバ２０は、上記ＩＰｖ６用課金終了要求パケットが示す統計情報に基づいて課金データベースを更新した後、アクセスサーバ４に課金確認応答（Accounting-Response）パケットを返信する（Ｓ６６）。

この後、ユーザ端末３０が、データリンクを解放すると（Ｓ７０）、アクセスサーバ４は、図６に示したステップ１１０、１１１に従って、ＬＣＰ用の統計情報測定の終了処理を実行した後、上記統計情報を含むＬＣＰ課金終了要求パケットを生成し、これを課金サーバ２０に送信する（Ｓ７１）。課金サーバ２０は、上記ＬＣＰ課金終了要求パケットが示す統計情報に基づいて課金データベースを更新した後、アクセスサーバ４に課金確認応答（Accounting-Response）パケットを返信する（Ｓ７２）。

図１５は、本発明によるアクセスサーバが適用されるネットワーク構成の第２実施例を示す。

第２実施例では、インターネットサービスプロバイダ網２に接続されるＲＡＤＩＵＳサーバとして、認証サーバ１０と課金サーバ２０の他に、ＩＰｖ４統計情報管理に専用の課金サーバ２０Ａと、ＩＰｖ６統計情報管理に専用の課金サーバ２０Ｂを設けたことを特徴としている。
この場合、アクセスサーバ４は、適用されるＮＣＰの種類によって、課金開始要求および課金終了要求の宛先サーバが異なるため、ＲＡＤＩＵＳプロトコル処理ルーチン５７に、例えば、図１６に示すように、適用ＮＣＰ５８１と課金サーバアドレス５８２との関係を定義した課金サーバアドレステーブル５８を準備する。適用ＮＣＰが不定の場合は、課金サーバアドレス５８２として、ＬＣＰセッション毎の統計情報を管理する課金サーバ２０のアドレスを指定する。

本実施例の場合、ＬＣＰ統計情報は課金サーバ２０、ＩＰｖ４統計情報は課金サーバ２０Ａ、ＩＰｖ６統計情報は課金サーバ２０Ｂに集計されるため、第１実施例のように、課金サーバ２０に課金データベースの蓄積情報をＬＣＰ別、ＮＣＰ別に分類、整理する機能を持たせる必要がなくなる。
尚、図１５では、統計情報管理をＬＣＰ用課金サーバ２０、ＩＰｖ４ＮＣＰ用課金サーバ２０Ａ、ＩＰｖ６ＮＣＰ用課金サーバ２０Ｂで分散する構成を示したが、課金サーバ２０を省略し、課金サーバアドレステーブル５８を変更することによって、ＬＣＰ統計情報をＩＰｖ４ＮＣＰ用課金サーバ２０ＡまたはＩＰｖ６ＮＣＰ用課金サーバ２０Ｂの何れかで集計、管理するようにしてもよい。また、第１、第２実施例のシステム構成において、ＲＡＤＩＵＳサーバ側での負荷分散のために、認証サーバおよび課金サーバ（２０、２０Ａ、２０Ｂ）をそれぞれ複数台にした冗長化システム構成を採用してもよい。

以上の実施例によれば、ＲＡＤＩＵＳに新たな属性（アトリビュート）を追加することなく、ＮＣＰ毎の接続時間や入出力データ量などの統計情報を収集できる。

以上の実施例から明らかなように、本発明によれば、アクセスサーバが、ＬＣＰセッション毎の統計情報の他に、同一のＬＣＰセッション上に多重化または時分割で形成されるＮＣＰセッション毎の統計情報を収集し、これを課金サーバに通知できるため、従来よりも詳細な統計情報管理が可能となる。

本発明のアクセスサーバが適用されるネットワーク構成の第１実施例を示す図。 図１のネットワークに適用される主信号系転送プロトコルスタックの１例を示図。 図１のネットワークに適用される制御系転送プロトコルスタックの１例を示図。 アクセスサーバ４のハードウエア構成の１例を示すブロック図。 アクセスサーバ４の制御処理部４４の１実施例を示すブロック図。 ユーザ端末からセッション確立要求を受信してからセッションが解放されるまでの間のアクセスサーバ４の動作を示すフローチャート。 図６におけるネットワーク層プロトコルフェーズへの移行（ステップ１０８）後のアクセスサーバの動作を示すフローチャート。 制御処理部４４が備えるＰＰＰユーザ管理テーブル５５の１実施例を示す図。 制御処理部４４が備えるセッション管理テーブル５６の１実施例を示す図。 アクセスサーバ４から課金サーバ２０に送信される課金パケットに適用されるＡｃｃｔ−Ｓｅｓｓｉｏｎ−ＩＤの１例を示す図。 ＩＰＣＰセッション解放時にアクセスサーバ４から課金サーバ２０に送信される出力される課金終了要求パケットのフォーマットを示す図。 ＩＰｖ６ＣＰセッション解放時にアクセスサーバ４から課金サーバ２０に送信される出力される課金終了要求パケットのフォーマットを示す図。 図１のネットワークにおけるユーザ端末３０とインターネット３との接続時の通信シーケンスの１例を示す図。 図１のネットワークにおけるユーザ端末３０とインターネット３との接続の解放時の通信シーケンスの１例を示す図。 本発明のアクセスサーバが適用されるネットワーク構成の第２実施例を示す図。 本発明の第２実施例でアクセスサーバ４に適用される課金サーバアドレステーブル２３０の１実施例を示す図。

符号の説明

１：ユーザアクセス網、２：インターネットサービスプロバイダ（ＩＳＰ）網、
３：インターネット、４：アクセスサーバ、６：ルータ、１０：認証サーバ、
２０、２０Ａ、２０Ｂ：課金サーバ、３０：ユーザ端末、４１：回線インタフェース、
４２：プロトコル処理部、４３：スイッチ部、４４：制御処理部、５０：メモリ、
５１：ＣＬＩ処理部、５２：ルーティングプロトコル処理ルーチン、
５３：警報監視ルーチン、５４：ＰＰＰプロトコル処理ルーチン、
５５：ＰＰＰユーザ管理テーブル、５６：セッション情報管理テーブル、
５７：ＲＡＤＩＵＳプロトコル処理部、５８：課金サーバアドレステーブル、
４４１：ＣＰＵ、４４２：制御端末インタフェース、
４４３：プロトコル処理回路インタフェース、４４４：スイッチ部インタフェース。

Claims (10)

1. ユーザアクセス網とインターネットサービスプロバイダ（ＩＳＰ）網に接続されたアクセスサーバであって、
   上記ユーザアクセス網に接続されたユーザ端末からのデータリンク確立要求に伴ってＬＣＰ（Link Control Protocol）で形成されるセッション毎に通信統計情報を収集しておき、上記データリンクが解放された時、上記ＩＳＰ網に接続された通信統計情報管理用の課金サーバに対して該当ＬＣＰセッションの統計情報を通知するための第１手段と、
   上記ＬＣＰセッション上に確立されたＮＣＰ（Network Control Protocol）セッション毎に通信統計情報を収集しておき、ＮＣＰセッションが解放された時、上記課金サーバに対して解放ＮＣＰセッションの統計情報を通知するための第２手段を有することを特徴とするアクセスサーバ。
2. 前記第１手段が、ＬＣＰセッションの確立に伴って、前記課金サーバに該ＬＣＰセッションの統計処理開始要求を送信し、データリンクが解放された時、上記課金サーバに対して該当ＬＣＰセッションの統計情報を含む統計処理終了要求を送信し、
   前記第２手段が、ＮＣＰセッションの確立に伴って、前記課金サーバに該ＮＣＰセッションの統計処理開始要求を送信し、ＮＣＰセッションが解放された時、上記課金サーバに対して解放ＮＣＰセッションの統計情報を含む統計処理終了要求を送信することを特徴とする請求項１に記載のアクセスサーバ。
3. 前記第１手段が、ＬＣＰセッション毎に固有の識別子を付したパケットによって、前記ＬＣＰセッション統計情報を前記課金サーバに通知し、
   前記第２手段が、ＮＣＰセッション毎に固有の識別子を付したパケットによって、前記解放ＮＣＰセッションの統計情報を前記課金サーバに通知することを特徴とする請求項１または請求項２に記載のアクセスサーバ。
4. 前記第１手段が、ＬＣＰセッション毎に固有の識別子を付したパケットによって、前記ＬＣＰセッション統計情報を前記課金サーバに通知し、
   前記第２手段が、ＮＣＰセッション毎に固有の識別子と該ＮＣＰセッションが所属するＬＣＰセッションの識別子との組み合せからなるセッション識別子を含むパケットによって、前記解放ＮＣＰセッションの統計情報を前記課金サーバに通知することを特徴とする請求項１または請求項２に記載のアクセスサーバ。
5. 前記第１、第２手段が、それぞれの統計情報をＲＡＤＩＵＳ（Remote Authentication Dial In User Service）プロトコルに従ったパケット形式で前記課金サーバに通知することを特徴とする請求項１〜請求項４の何れかに記載のアクセスサーバ。
6. ユーザアクセス網とインターネットサービスプロバイダ（ＩＳＰ）網に接続されたアクセスサーバであって、
   上記ユーザアクセス網に接続されたユーザ端末からのデータリンク確立要求に伴って、上記ＩＳＰ網に接続されたＲＡＤＩＵＳ（Remote Authentication Dial In User Service）サーバとの間でユーザ認証手順を実行した後、ＬＣＰ（Link Control Protocol）で形成されたセッション毎の通信統計情報の収集を開始し、上記データリンクが解放された時、上記ＲＡＤＩＵＳサーバに対して該当ＬＣＰセッションの統計情報を通知するための第１手段と、
   上記ＬＣＰセッション上に確立されたＮＣＰ（Network Control Protocol）セッション毎に通信統計情報を収集しておき、ＮＣＰセッションが解放された時、上記ＲＡＤＩＵＳサーバに対して解放ＮＣＰセッションの統計情報を通知するための第２手段を有することを特徴とするアクセスサーバ。
7. 前記第１手段が、ＬＣＰセッションの確立に伴って、前記ＲＡＤＩＵＳサーバに該ＬＣＰセッションの統計処理開始要求を送信し、データリンクが解放された時、上記ＲＡＤＩＵＳサーバに対して該当するＬＣＰセッションの統計情報を含む統計処理終了要求を送信し、
   前記第２手段が、ＮＣＰセッションの確立に伴って、前記ＲＡＤＩＵＳサーバに該ＮＣＰセッションの統計情報処理の開始を要求し、ＮＣＰセッションが解放された時、上記ＲＡＤＩＵＳサーバに対して解放ＮＣＰセッションの統計情報を含む統計処理終了要求を送信することを特徴とする請求項６に記載のアクセスサーバ。
8. 前記第１手段が、ＬＣＰセッション毎に固有の識別子をＡｃｃｔ−Ｓｅｓｓｉｏｎ―ＩＤとして含むＲＡＤＩＵＳパケットによって、前記ＬＣＰセッションの統計情報を前記ＲＡＤＩＵＳサーバに通知し、
   前記第２手段が、ＮＣＰセッション毎に固有の識別子をＡｃｃｔ−Ｓｅｓｓｉｏｎ―ＩＤとして含むＲＡＤＩＵＳパケットによって、前記解放セッションの統計情報を前記ＲＡＤＩＵＳサーバに通知することを特徴とする請求項６または請求項７に記載のアクセスサーバ。
9. 前記第２手段が、ＮＣＰセッション識別子と該ＮＣＰセッションが所属するＬＣＰセッションの識別子をＡｃｃｔ−Ｓｅｓｓｉｏｎ―ＩＤとして含むＲＡＤＩＵＳパケットによって、前記解放セッションの統計情報を前記ＲＡＤＩＵＳサーバに通知することを特徴とする請求項８に記載のアクセスサーバ。
10. 前記ＲＡＤＩＵＳサーバが、ＮＣＰ種類に対応した通信統計情報管理用の複数の課金サーバを備えた場合に、前記第２手段が、確立または解放されたＮＣＰセッションの種類と対応した課金サーバに対して、前記ＲＡＤＩＵＳパケットを送信することを特徴とする請求項８または請求項９に記載のアクセスサーバ。

Images