网络统计信息服务系统及因特网接入服务器 【发明领域】
本发明涉及网络统计信息服务系统及因特网接入服务器。
背景技术
以因特网为代表的IP(Internet Protocol：因特网协议)网络上，根据IP协议传送数据。提供用于将用户终端连接于IP网络上的因特网连接服务的通信运营商叫作因特网服务提供商ISP(InternetService Provider：因特网服务提供商)。因特网使用者将用户终端连接于因特网时，以前通过拨号经由ISDN(Integrated ServiceDigital Network：集成服务数字网络)/电话线路网路径连接于因特网服务提供商，但近年来随着宽带的迅速普及，经由FTTH(Fiber ToThe Home：光纤入户)、DSL(Digital Subscriber Line：数字用户线)、电缆网络、无线(FWA/Fixed Wireless Access：固定无线接入)等高速接入线路网，可连接于因特网服务提供商。
利用电话线路的原来的因特网连接中，因特网服务提供商根据因特网使用时间向使用者收取从量制的计费。另一方面，在宽带环境中，与使用原来的电话线路的从量制计费不同，因特网服务提供商引入按月向使用者收取一定费用的定额计费制度。通过该定额计费制度的引入，因特网使用者不需要关心费用，可将用户终端常时连接于因特网上。
另外，因特网服务提供商经由容纳上述各种高速接入线路的接入服务器，对使用者提供因特网连接服务。此时，作为接入服务器与用户终端之间的通信协议，广泛使用PPP(Point-to-Point Protocol：点对点协议)。PPP原来是为了在电话线、专用线等串行线路上提供TCP/IP等链接而提出的协议，在因特网工程特别小组(IETF：Internet Engineering Task Force)中标准化为请求注释(Requestfor Comments)(RFC)1661。
PPP由OSI参照模型的数据链接层中工作的LCP(Link ControlProtocol：链接控制协议)和在网络层工作地NCP(Network ControlProtocol：网络控制协议)构成。LCP是用于控制文字链接的协议，经与数据大小、有无数据压缩、传送速度等通信条件有关的协商(妥协)作业在2个通信装置间确立数据链接后，进行检查和释放数据链接的控制。NCP在LCP的数据链接确立后，进行网络层的上级协议的选择和网络地址的分配/设定等。PPP在宽带环境下广泛使用，例如，作为以太网(Ethernet：注册商标名)上利用的PPP协议，已知有RFC2516规定的PPPoE(PPP Over Ethernet：以太网上的PPP)。
因特网服务提供商预先将与使用者有关的信息和统计数据作为属性(特性)值进行数据化，由认证服务器和计费服务器进行一维管理。认证服务器和计费服务器一般可经IP网与接入服务器通信。这些服务器之间的通信，通常利用RADIUS(Remote AuthenticationDial In User Service：远程用户拨号认证系统)。与RADIUS有关的通信协议例如规定为RFC2865、RFC2866、RFC2869。
RADIUS利用服务器客户方式，通过将RADIUS服务器、接入服务器作为RADIUS客户使认证服务器和计费服务器工作，实现这些服务器之间的使用者属性值的发送接收。具体说，从用户终端接收到因特网连接请求的接入服务器，根据RADIUS认证协议发送从上述连接请求中提取出的用户名和口令(密码)，向认证服务器询问请求源用户终端是否为预先订立合约(契约)的正规服务器。
从认证服务器接收表示用户认证正常结束的响应时，接入服务器许可请求源用户终端连接到因特网，在其与用户终端之间确立PPP会话(session)。由此，用户终端可接入因特网上的各种服务器。若接入服务器许可用户终端接入因特网，则开始收集该用户终端(使用者)的计费信息(网络统计信息)，根据RADIUS计费协议向计费服务器发送计费信息。计费服务器根据用户名来识别各个终端使用者，按每个使用者累计管理计费信息。
例如在日本特开2001-257722号公报中，公开了一种网络监视系统，按通信流单位来收集包含上述计费信息在内的统计监视信息。
目前，因特网服务提供商由计费服务器管理的计费信息，例如是各使用者的因特网连接时间、发送接收信息包数、发送接收数据量。在定额收费制度的常时连接服务中，这些计费信息不通知用户，留给因特网服务提供商自身，用于掌握网络的利用状况和作为对后续的网络设计的反馈信息来使用。
这是由于当前的因特网连接服务几乎都以尽可能达到最完善，但信息包传输中是不作任何保证的最大努力(best effort)型通信服务为前提，对于因特网服务提供商而言，例如在提供因特网连接服务中，即便由于网络上的阻塞造成了暂时的信息包损失，其也不负有向各使用者作出信息包损失的产生和损失信息包的报告义务。
近年来，随着因特网连接服务的竞争日益激烈，因特网服务提供商为体现与其他服务商的服务差别，增加了导入SLA(ServiceLevel Agreement服务水平协定：服务品质保证制度)的情况。所谓SLA服务意味着保证一定通信品质水平的通信服务的提供契约，是通信品质低于预先保证的基准时，例如向使用者支付保证金等的、按每个使用者缔结更精细的契约的因特网连接服务。作为SLA服务的具体的契约菜单，有例如在通信服务中发现异常时保证在规定时间内将服务故障传送到使用者、保证增加一定时间(或一定比例(％))的服务时间等。
为向使用者提供SLA服务，因特网服务提供商仅管理像原来的计费信息一样的因特网连接时间和发送接收信息包数等统计信息是不够的，需要具有以下功能：收集在因特网连接期间中产生的损失信息包数、服务中断时间等比原来更详细的统计信息，并将这些信息作为每个使用者的新的网络利用信息进行管理。
另外，随着宽带接入普及、对因特网的常时连接普遍化，至此处于从Web服务器接收内容信息的立场的因特网使用者中的一部分，正在变化为拥有自身的Web服务器的信息发送者。这样的环境下，因特网使用者需要将表示从因特网到自身的终端(例如使用者构筑的Web服务器)的接入状况的信息作为新的统计信息。但是，在使用者个人收集接入自身终端的接入信息并进行管理时，由于与网络的操作有关的高度的技术和专用的网络监视装置的设置为前提，因此实际上难以实现。
【发明内容】
本发明的目的是提供一种网络统计信息服务系统和接入服务器，能自动收集、管理因特网使用者所希望的统计信息，并向使用者公开。
本发明的其他目的是提供一种网络统计信息服务系统和接入服务器，能扩展现有计费系统的功能，对因特网使用者所需要的统计信息进行通知服务。
为达到上述目的，本发明的网络统计信息服务系统，包括：服务提供系统，其具有用于与用户识别符对应地存储统计数据和用户希望的统计信息收集条件的数据库；接入服务器，在经接入网从用户终端接收到认证请求时，向上述服务提供系统发送认证请求信息包，从上述服务提供系统接收表示认证结果和请求源用户的识别符、统计信息收集条件及应收集的统计参数的响应信息包，根据该响应信息包表示的认证结果对上述用户终端作出响应；
上述接入服务器具有：管理表，与用户识别符和会话识别符对应地存储来自上述服务提供系统的响应信息包表示的统计信息收集条件和统计参数；统计数据更新单元，在上述用户终端正连接在因特网上时，根据上述管理表表示的统计信息收集条件和统计参数来收集信息，更新上述管理表的统计数据；更新请求生成单元，生成表示上述更新了的统计数据的更新请求信息包，发送到上述服务提供系统，上述服务提供系统根据从上述接入服务器接收的更新请求信息包的内容，更新上述数据库的统计数据，对应来自用户终端的请求，来公开与该用户终端的用户识别符对应地存储在上述数据库中的统计数据的至少一部分。
更具体说，上述接入服务器具有的更新请求生成单元的特征是，例如向上述服务提供系统发送在用户终端正连接在因特网上时按规定周期定期生成的更新请求信息包、及随着对因特网的连接结束而与上述用户终端之间的会话释放时生成的更新请求信息包。上述服务提供系统的特征是包括：统计信息管理服务器，管理上述数据库，对来自上述接入服务器的认证请求信息包和更新请求信息包进行响应；Web服务器，响应来自上述用户终端的请求执行用于统计数据公开的处理。
本发明的网络统计信息服务系统的特征是，上述更新请求生成单元在例如产生由上述统计信息收集条件预先指定的特定事件时，生成表示该内容的更新请求信息包，发送到上述服务提供系统。
具体说，本发明的1个实施例中，上述统计信息收集条件之一指定监视IP地址和阈值，上述统计数据更新单元对以上述监视IP地址为发送源的信息包数进行计数，在上述信息包数在上述阈值以上时，上述更新请求生成单元生成表示该内容的更新请求信息包，发送到上述服务提供系统。
本发明的另一实施例中，上述统计信息收集条件之一指定损失信息包数的计数，上述统计数据更新单元对网络阻塞时产生的损失信息包数进行计数，上述更新请求生成单元在阻塞恢复时生成表示上述损失信息包数的更新请求信息包，发送到上述服务提供系统。
本发明的再一实施例中，上述统计信息收集条件之一指定服务中断时间的计数，上述统计数据更新单元对网络阻塞造成的服务中断时间进行计数，上述更新请求生成单元在阻塞恢复时生成表示上述服务中断时间的更新请求信息包，发送到上述服务提供系统。
本发明的一个特征是上述服务提供系统除上述统计信息管理服务器和Web服务器外，还包括：邮件服务器，在从上述接入服务器接收随着特定事件的产生的更新请求信息包时，将上述特定事件的产生通知相关的用户终端。
本发明的因特网接入服务器，具备如下功能：在从用户终端接收到认证请求时，向服务提供系统发送认证请求信息包，从上述服务提供系统接收表示认证结果和请求源用户的识别符、统计信息收集条件以及应收集的统计参数的响应信息包时，根据该响应信息包表示的认证结果对上述用户终端作出响应，具有：管理表，与用户识别符和会话识别符对应地存储来自上述服务提供系统的响应信息包表示的统计信息收集条件和统计参数；统计数据更新单元，在上述用户终端正连接在因特网上时，根据上述管理表表示的统计信息收集条件和统计参数来收集信息，更新上述管理表的统计数据；更新请求生成单元，生成表示上述更新了的统计数据的更新请求信息包，发送到上述服务提供系统。
另外，上述接入服务器和服务提供系统之间使用例如RADIUS协议的属性来发送接收上述统计信息收集条件和统计参数。
根据本发明，对于因特网连接中的每个用户终端，可根据预先指定的统计信息收集条件来收集信息包损失和服务中断时间等统计信息，将其向使用者公开，可进行按每个使用者缔结更精细的契约的因特网连接服务和网络统计信息服务。
【附图说明】
图1是包含本发明涉及的网络统计信息服务系统的网络结构图。
图2是表示图1的网络中使用的主信号传送协议栈的一个例子的图。
图3是表示图1的网络中使用的控制信号传送协议栈的一个例子的图。
图4是表示图1所示的接入服务器的硬件4的详细情形的框图。
图5是表示图4的接入服务器4的控制处理部44的详细情形的框图。
图6是表示本发明的网络统计信息服务系统的工作的顺序图。
图7是表示图6的步骤S04～S06的详细工作的序列图。
图8是表示图6的网络统计信息的更新步骤S10的详细情形和用户终端对网络统计信息的参照工作的顺序图。
图9A、图9B是表示认证/计费服务器21包括的计费管理数据库的一个例子的图。
图10是表示从图1的认证/计费服务器21向接入服务器4发送的access accept(接受接入)信息包的格式的图。
图11是说明图1的认证/计费服务器21和接入服务器4之间交换的Vendor Specific(供应商指定)属性的内容的图。
图12是表示图5的PPP用户管理表56的一个例子的图。
图13是表示从图1的接入服务器4向认证/计费服务器21发送的accounting request(start)(计数(记账)请求(开始))信息包的格式的图。
图14是表示从图1的接入服务器4向认证/计费服务器21发送的accounting request(interim-update)(计数请求(过渡更新))信息包的格式的图。
图15是表示从图1的接入服务器4向认证/计费服务器21发送的accounting request(stop)(计数请求(停止))信息包的格式的图。
图16是表示本发明的网络统计信息服务系统的网络阻塞检测时的工作的顺序图。
图17是表示本发明的网络统计信息服务系统的超出监视信息包阈值时的工作的顺序图。
【具体实施方式】
下面，参考附图说明本发明涉及的网络统计信息服务系统的1个实施例。
图1表示包含本发明涉及的网络统计信息服务系统的网络结构图。
图1中，接入服务器4能经由IP网3，与构成因特网服务提供商2的认证服务器和统计信息管理服务器(下面称作计费服务器)通信。这里，认证服务器和计费服务器作为一个服务器(认证/计费服务器)21表示，但它们可分开为2个服务器来构成。因特网服务提供商2除认证/计费服务器21外，还包括与因特网1连接的路由器22-1、与IP网3连接的路由器22-2、邮件(mail)服务器23、及Web服务器24。211是认证/计费服务器21管理的计费管理数据库，231是用于对因特网使用者的邮件地址、及成为对使用者公开的公开信息的统计数据进行存储的数据库，由邮件服务器23和Web服务器24利用。
用户终端6(6-1，6-2)是属于因特网服务提供商2的使用者的终端，连接于因特网1时，经接入网5向接入服务器4发送连接请求。用户终端6和接入服务器4之间使用PPP，PPP作为用于用户终端使用的链接的确立、用户认证和IP地址分配的协议。作为接入网5，使用例如电话交换网、ADSL、FTTH等宽带接入网。
Web服务器24是可从用户终端接入的服务器，向因特网使用者提供数据库23中存储的公开用的网络统计数据(参数信息)。各因特网使用者通过使用用户终端6接入Web服务器24，可取得自身最新的参数信息。邮件服务器23管理各因特网使用者的邮件地址，如后所述，在特定事件产生时，或对应来自使用者的请求，以电子邮件形式通知统计数据。
图2表示在图1所示的网络统计信息的服务系统中，用户终端6(6-1，6-2)和因特网1上的目的服务器经由接入服务器4进行通信所需要的主信号传送协议栈的一个例子。
由于用户终端6和接入服务器4由PPP连接，用户终端6的协议栈601和接入服务器4的协议栈401中存在PPP。比PPP下层的协议栈因接入网5的链接层的类型而不同。图2中，作为一个例子，表示出下层为以太网(Ethernet：注册商标名)时的协议栈。从接入服务器到目的服务器，如协议栈402和101所示，根据IP协议(IPv4/IPv6)来传送数据。
图3表示用户认证信息、统计信息收集条件、应收集统计参数等控制信息的通信所需要的控制系统传送协议栈的一个例子。
如协议栈602和411所示，用户终端6和接入服务器4之间，控制信息通过PPP协议通信。另一方面，如协议栈412和2101所示，接入服务器4和认证/计费服务器21之间，根据RADIUS协议对认证信息和网络统计信息进行通信。
RADIUS协议中，如后所述，规定RADIUS属性(属性值)，接入服务器4和认证/计费服务器21通过向信息包的数据部(payload部：有效负载部)加上各自需要的属性，可互相发送接收认证信息、统计信息收集条件、统计参数、统计数据等网络统计信息处理所需的控制信息。
图4表示接入服务器4的硬件结构的一个例子的框图。
接入服务器4包括：进行服务器的整体控制的控制处理部44、将信息包输出到规定线路用的开关(SW)部43、处理数据链接层和作为其上层的IP协议的多个协议处理部42(42-1～42-n)、分别具有与连接线路的种类相对应的物理层终端功能的多个线路接口(IF)41(41-1A～41-nB)。这里，线路接口41-1A、41-2A、…41-nA表示输入线路用的接口，线路接口41-1B、41-2B…41-nB表示输出线路用的接口。
图5是表示控制处理部44的1个实施例的框图。
控制处理部44包括数据处理器(CPU)441、存储器50、用于与协议处理部42通信的协议处理部接口(IF)443、用于与开关部(转换部)43通信的SW部接口444、用于与在外部设置的控制终端进行通信的控制终端接口442。CPU441执行存储器50中准备的各种程序。
存储器50中，作为与本发明有关的程序，例如存储着CLI(CommandLine Interface：命令线接口)处理例程(routine)51、路由协议处理例程52、警报监视处理例程53、PPP协议处理例程54、RADIUS协议处理例程55，形成为了按每个因特网使用者来收集各自的统计信息而参照的PPP用户管理表56。
CLI处理例程51是用于为了控制接入服务器4而处理由系统管理者从未示出的控制终端输入的控制命令的程序。路由协议处理例程52是用于处理将从各线路接口41向接入服务器4输入的信息包，传送到与目的地地址对应的其他某个线路接口41时需要的路由信息的程序。
系统管理者已指定的路由信息，由路由协议处理例程52设定在各协议处理部42包括的路由表(未示出)中。各输入线路接口41-iA(i＝1～n)从网络接收到的信息包，在协议处理部42-i中附加例如包含与信息包标题的目的地地址相对应的路由信息的内部标题后，被传送到SW部43中。SW部43根据内部标题所示的路由信息，向其他某一个协议处理部传送来自各协议处理部42的输入信息包。各协议处理部42-j(j＝1～n)从由SW部43接收到的信息包中去除内部标题，将该信息包输出到输出线路接口41-jB中。
警报监视处理例程53是监视在接入服务器4的内部产生的警报信息、进行对应于警报信号的工作的程序。处理PPP协议信号的PPP协议处理例程54与协议处理部42协同工作，根据RFC1332、RFC1661、RFC1994等与PPP有关的RFC，来执行PPP终端处理、LCP处理、PAP(Password Authentication Protocol：口令认证协议)、CHAP(Challenge Handshake Authentication Protocol：询问握手认证协议)等认证处理、IPCP(Internet Protocol Control Protocol：因特网协议控制协议)等NCP处理用的程序。
RADIUS协议处理例程55处理RFC2138、RFC2139、RFC2865、RFC2866、RFC3162等RADIUS协议的全部，PPP认证时，与PPP协议处理例程54协同工作，向认证/计费服务器21发送用户ID、口令等信息。
用户认证已成功的情况下，认证/计费服务器21将例如用户能使用的IP地址等网络设定条件、和后述的有无损失信息包数通知的统计信息收集条件，作为与认证的用户有关的属性信息通知给接入服务器4。接入服务器4在释放PPP会话之前的期间，在PPP用户管理表56中存储从认证/计费服务器21通知的与各用户有关的属性信息。
认证成功了的用户终端6在与接入服务器4之间确立PPP会话时，接入服务器4开始统计信息的收集处理。接入服务器4根据PPP用户管理表56所示的统计信息收集条件，来收集例如连接时间、信息包通过量、损失信息包数等各种参数所表示的统计信息。本实施例中，为了以PPP会话单位来收集统计信息，在PPP用户管理表56中登录与用户识别符、会话识别符对应的统计数据(参数信息)管理用的多个入口(entry)。
接入服务器4在确认PPP用户的会话确立后，由RADIUS协议处理例程55生成计费(统计信息收集)处理的开始请求信息包，将其发送到认证/计费服务器21。PPP用户的会话被释放的情况下，接入服务器4由RADIUS协议处理例程55生成计费处理结束请求信息包，将其发送到认证/计费服务器21。
接入服务器4在PPP会话正继续时，根据PPP用户管理表56表示的统计信息收集条件，来收集因特网使用者预先用参数指定的统计信息。接入服务器4定期地或以网络的阻塞和故障的产生/恢复等事件为契机，通过RADIUS协议处理例程55来生成表示所收集的统计信息的计费处理中间信息包，将其发送到认证/计费服务器21。
从下面的说明可以明确，从接入服务器4向认证/计费服务器21发送的计费处理开始请求信息包、计费处理结束请求信息包、计费处理中间信息包的详细情形、及接入服务器4与认证/计费服务器21之间的通信顺序。
图6～图8表示用户终端6从接入服务器4接收因特网连接服务时的通信顺序。其中，为了简化说明，这里例示的顺序图不过是表示出本发明的主要的协议消息，不应解释为了正确地表示出了在实际应用中用户终端和接入服务器之间、接入服务器和认证/计费服务器之间交换的全部消息。
如图6所示，因特网使用者的用户终端6在与接入服务器4之间执行由RFC2516表示的PPPoE的初始化处理(S01)。该处理尤其在接入网5为FTTH网构成的情况下，为了识别在以太网上复用化的PPP帧是必要的。接入服务器4中，例如协议处理部42-1～42-n执行上述PPPoE初始化处理。
通过PPPoE初始化处理来确立PPPoE会话时，接入服务器4的控制处理部44通过PPP协议处理例程54执行PPP的协议信号处理。确立PPPoE会话后(S01)，控制处理部44通过链接控制协议(LCP：Link Control Protocol)处理来设定链接层(S02)，响应于来自用户终端6的用户认证请求(S03)，根据例如RFC1994所示的询问握手认证协议(CHAP：Challenge Handshake Authentication Protocol)向认证/计费服务器21请求用户认证。
本实施例中，向认证/计费服务器21请求用户认证时，控制处理部44执行RADIUS协议处理例程55，通过RFC2865等所示的RADIUS协议向认证/计费服务器21发送表示用户ID、口令等的accessrequest信息包(接入请求信息包)(S04)。接收到access request信息包的认证/计费服务器21判定认证请求源终端6的用户是否为预先已、登录的正规使用者。
如图7所示，接收了access request信息包的认证/计费服务器21将接收信息包所示的用户名作为关键码，从计费管理数据库(DB)211中检索请求源用户的契约服务内容(S17)，向接入服务器4返回表示认证结果和契约服务内容的access accept信息包(接入接受信息包)(S05)。
例如图9A所示，计费管理数据库211表示出对应于用户名211-1分配的IP地址211-2、口令211-3、连接时间211-4、输入信息包数211-5、输出信息包数211-6、损失信息包数211-7、中断时间211-8、选项序号211-9、表示应监视信息包的发送源的监视地址211-10、与上述监视地址相当的信息包数211-11、阈值211-12。计费管理数据库211中实际上包含用户的住所、因特网连接契约的种类、计费额、支付账号等计费管理所需的其他项目信息，但这些信息与本发明无直接关系，因此图中省略了。
例如图9B所示，选项序号211-9对作为选项内容211-20应该由接入服务器4预先执行的数据收集服务(契约服务)的内容进行确定。这里，例如access request信息包的用户名为“tanaka”的情况下，认证/计费服务器21通过access request信息包所表示的口令与在计费管理数据库211中按用户名“tanaka”登录的口令“aaaa”是否一致，来判定请求源用户是否为正规的使用者。口令一致的情况下，从用户名“tanaka”的入口取得应分配给请求源用户终端的IP地址211-2(100.100.10.12)和选项序号211-9(“1”)。
认证/计费服务器21在用户认证已成功的情况下，向接入服务器4返回图10所示的access accept信息包300(S05)。上述accessaccept信息包300中，设定从计费管理数据库211取得的用户分配IP地址和确定契约服务内容的选项序号。
图10表示的access accept信息包300格式的1个例子。
本实施例的access accept信息包300在具有IP标题310和UDP标题320的IP信息包的有效负载部，包含表示该信息包是accessaccept信息包的Radius Code 330和Radius属性500。
Radius属性500包含表示成为用户终端的识别符的用户名的User-Name属性501、表示向用户终端分配的IP地址的Framed-IP-Address属性508和Vendor-Specific属性526。
图10的Radius属性中，末尾用括号表示的数字表示按规定来定义的属性序号，例如User-Name属性501由属性序号“1”、后续的数据长度、用户名的组合来记述。Vendor Specific属性526是为了实现由具有按规定来定义的属性序号的一般的属性不能指定的特殊性能而被使用的。
图11中，表示本实施例中作为Vendor-Specific属性526使用的Vendor Type(提供商类型)与定义内容的关系。这里所示的例子中，作为Vendor Type，准备了“1”～“7”的7种，按每个VendorType预先定义选项种类和参数种类等属性。上述用户名“tanaka”的access accept信息包300的情况下，Vendor-Specific属性526中，通过指定Vendor Type(1)＝“1”，对接入服务器4，指示执行关于用户名为“tanaka”的终端应执行由选项序号“1”定义的信息包(损失信息包数和中断时间)的信息收集服务。
从认证/计费服务器21接收到access accept信息包300的接入服务器4分析接收信息包的属性，在PPP用户管理表56中，与请求源用户的识别符对应地登录表示统计信息收集条件和统计数据的新入口(S18)。
图12表示在PPP用户管理表56中登录的信息的一个例子。
PPP用户管理表56的各入口包含：用户名56-1、表示分配的IP地址的Framed IP Address 56-2、用于在接入服务器4内惟一地对连接中的PPP会话进行识别的Session ID 56-3、表示PPP会话的连接时间的Session Time 56-4、表示PPP会话中的输入数据信息包数的Input Packets 56-5、表示输出信息包数Output Packets 56-6、表示损失信息包数的Loss Packets 45-7、表示由信息包损失带来的服务中断时间的Congestion Time 56-8、表示应监视信息包的发送源地址(监视地址)的Monitored Address 56-9、表示与上述监视地址相当的监视信息包数的Monitored Packets 56-10、及阈值56-11。
上述用户名为“tanaka”的情况下，紧接着接收最初的accessaccept信息包300之后，在PPP用户管理表56中，登录用户名56-1＝“tanaka”、Framed IP Address 56-2＝“100.100.100.12”、SessionID 56-3＝“ww”、Session Time 56-4＝“00:00:00”、Input Packets56-5＝“0”、Output Packets 56-6＝“0”、Loss Packets 45-7＝“0”、Congestion Time 56-8＝“0”的入口。
接入服务器4结束对PPP用户管理表56的入口登录(S18)后，向请求源用户终端6发送用户认证响应(S06)。用户终端6接收上述用户认证响应后，根据RFC1332所示的IPCP(IP Control Protocol：IP控制协议)，与接入服务器4之间执行用于IP层设定的通信顺序(S07)。对用户终端6设定IP地址和基于协议信号处理设定PPP会话结束后，用户终端6可连接到因特网1上。
接入服务器4在完成了与用户终端6之间的PPP会话设定后，开始计费(统计信息收集)处理。此时，本发明中，接入服务器4的控制处理部44执行RADIUS协议处理例程55，根据在PPP用户管理表56上追加的新的入口信息，作成计费处理开始请求信息包、即Accounting request(start)信息包301，将其发送到认证/计费服务器21(S08)。
图13表示Accounting request(start)信息包301的格式。
Accounting request(start)信息包301作为Radius属性500包含：表示用户名的User-Name属性501、表示用户终端分配IP地址的Framed-IP-Address属性508、表示计费处理请求信息包的种类的Acct-Status-Type属性540、表示用户终端和接入服务器之间的PPP会话识别符的Acct-Session-ID属性544。Acct-Status-Type属性540表示Accounting request是计费处理的开始请求、结束请求还是中间的计数请求的区别，在信息包301中，设定表示计费处理的开始请求“start”的代码“1”。
在用户名为“tanaka”的例子中，Radius属性500中设定User-Name属性501＝“tanaka”、Framed-IP-Address属性508＝“100.100.100.12”、Acct-Session-ID属性544＝“ww”。
认证/计费服务器21从接入服务器4接收上述Accountingrequest(start)信息包301后，返回响应信息包(Accountingresponse)(S09)，对于具有由接收信息包指定的用户名的因特网使用者，开始统计信息的收集工作。
接着，参考图8说明用户终端6正连接在因特网上的期间执行的计费(统计信息收集)处理工作。
用户终端6正连接在因特网上1的期间，接入服务器4根据图7的步骤S18中登录在PPP用户管理表56中的入口信息，按每个用户终端来收集例如输入输出信息包数、损失信息包数等参数所表示的统计信息，周期地更新PPP用户管理表56(S19)。Session Time 56-4在每次更新PPP用户管理表56时，加上从上次更新时刻开始经过的时间。
用户名为“tanaka”的用户终端的情况下，通过上述周期更新，在PPP用户管理表上，统计数据的值如下变化，例如Session Time56-4＝“00:05:00”、Input Packets 56-5＝“2250”、Output Packets56-6＝“2567”、Loss Packets 45-7＝“100”、Congestion Time 56-8＝“30”。
接入服务器4根据RADIUS协议处理例程55，周期地生成计费处理中间请求信息包、即Accounting request(interim-update)信息包302，将其发送到认证/计费服务器21(S10)。在Accountingrequest(interim-update)信息包302中，设定PPP用户管理表56表示的统计数据的值。
图14表示Accounting request(interim-update)信息包302的格式。Accounting request(interim-update)信息包302作为属性500，与图13所示的Accounting request(start)信息包301同样，包括：表示用户名的User-Name属性501、表示用户终端分配的IP地址的Framed-IP-Address属性508、表示计费处理请求信息包的种类的Acct-Status-Type属性540、及表示PPP会话识别符的Acct-Session-ID属性504。Acct-Status-Type属性540设定表示该信息包是中间计数“interim-update”用的信息包的代码“3”。
Accounting request(interim-update)信息包302除上述属性外，还包含：表示PPP会话的连接时间的计数Session Time属性546、表示输入信息包数的Acct-Input-Packets属性547、表示输出信息包数的Acct-Output-Packets属性548、及Vendor-Specific属性526。此外，包含例如Accounting request(interim-update)信息包302的生成时刻的Event-Timestamp属性(555)等，但图中省略了。
在用户名为“tanaka”的用户终端的情况下，PPP用户管理表56表示的Loss Packets 56-7＝“100”、Congestion Time 56-8＝“30”等统计数据，根据图11所示Vendor Type定义来设定VendorSpecific属性526，例如Vendor Type(4)＝100、Vendor Type(5)＝30。
认证/计费服务器21从接入服务器4接收Accounting request(interim-update)信息包302后，如图8所示，根据接收信息包所示的Radius属性500的内容，更新计费管理数据库211的相当于用户名501的入口的统计数据的值(S20)，将更新的统计数据通知给Web服务器24，而且向接入服务器4发送响信息包(Accountingresponse)(S11)。
Web服务器24根据上述统计数据来更新数据库231的公开用参数信息(S21)。因此，因特网使用者通过接入上述Web服务器24可实时阅览、取得自身的参数信息。
用户终端6的使用者结束因特网连接时，如图6所示，在用户终端6和接入服务器4之间，执行IPCP的结束处理(termination处理)(S12)、LCP的结束处理(S13)、PPPoE会话的释放处理(S14)。接入服务器4在完成PPPoE会话的释放处理后，生成计费处理结束请求信息包、即图15所示的Accounting request(stop)信息包303，将其发送到认证/计费服务器21(S15)。
Accounting request(stop)信息包303具有与图14所示的Accounting request(interim-update)信息包302相同的格式，在Acct-Status-Type属性540中设定表示该信息包是计费处理结束“stop”用的信息包的代码“2”，在Radius属性500中设定PPP用户管理表56的最新的统计数据值。
认证/计费服务器21接收上述Accounting request(stop)信息包303后，执行统计数据的最后的更新处理(图8的步骤S20)，向接入服务器4返回Accounting response(计数响应)(S16)。此时，Web服务器23也执行公开用参数信息的最后的更新处理(图8的步骤S20)。
接着，参考图16的顺序图说明由于网络上的阻塞而产生信息包损失、因特网连接服务暂时中断的情况下的计费处理工作。
接入服务器4检测出网络上的阻塞(S23)后，根据由PPP用户管理表56指定的统计信息收集条件，按每个用户(会话)对阻塞时间、损失信息包数的参数值进行计数，更新PPP用户管理表56的统计数据(S24)。通过上述计数工作，在上述的用户名为“tanaka”的情况下，例如图12所示，如下更新统计数据的值：Session Time 56-4＝“00:05:30”、Input Packets 56-5＝“2250”、Output Packets56-6＝“2567”、Loss Packets 45-7＝“100”、Congestion Time 56-8＝“30”。
接入服务器4检测出网络上的阻塞恢复(S25)后，根据RADIUS协议处理例程55生成包含图14所示的Vendor-Specific属性的Accounting request(interim-update)信息包302，向认证/计费服务器21发送PPP用户管理表56表示的统计数据(S10)。例如，用户名为“tanaka”的情况下，损失Loss Packets 45-7的值为VendorType(4)＝“100”、或拥塞时间58-8的值为Vendor Type(5)＝“30”，通知给认证/计费服务器21。
认证/计费服务器21接收上述Accounting request(interim-update)信息包302后，计费管理数据库211的接收信息包用户名501所示的入口中，执行与接收信息包的VendorSpecific属性的内容相对应的数据更新(S26)。之后，对邮件服务器23通知用户名、由于阻塞产生的损失信息包数、及服务中断时间等的统计数据(S26)，而且对接入服务器4发送成为上述Accountingrequest(interim-update)信息包302的接收响应的Accountingresponse信息包(S11)。
邮件服务器23根据来自认证/计费服务器21的通知内容更新数据库231(S27)后，对使用者的邮件地址发送统计信息(该例子中是阻塞信息)(S28)。通过以上顺序，可按每个因特网使用者进行信息包损失数或服务中断时间等预先由参数指定的统计信息的实时分配。
接着，参考图17所示的顺序图，说明本发明特有的统计信息公开服务，例如由接入服务器4监视将特定IP地址作为发送源的信息包通信量，信息包通信量超出预先确立的与使用者之间的契约值时，以电子邮件形式向使用者进行通知。
接入服务器4监视将作为Monitored Address 56-9在PPP用户管理表56中登录的特定的IP地址作为发送源的信息包数(通信量)，将该信息包的个数作为监视信息包数56-10进行计数(S29)。接入服务器4比较监视信息包数和预先指定的阈值56-11，超出阈值时(S30)，将表示该内容的Accounting request(interim-update)信息包302发送到认证/计费服务器21(S10)。该Accounting request(interim-update)信息包302与图16的步骤S10发送的Accountingrequest(interim-update)信息包相比，仅Vendor-Specific属性信息不同。
例如，图7的计费管理数据库211中用户名为“yamada”的入口所示，假定用户“yamada”预先与因特网服务提供商2之间订立了契约如下：在从Monitored Address 211-10(10.1.1.0/24)向自身终端发送的信息包数超出指定作为阈值211-12的“1000”时，通过邮件通知该内容。此时，从用户名为“yamada”的用户终端请求连接因特网时，认证/计费服务器21通过在access request信息包300的Vendor Specific属性526中指定Vendor Type(1)＝“2”、VendorType(2)＝“10.1.1.0/24”、Vendor Type(3)＝“1000”向接入服务器4通知上述契约条件。
接入服务器4将上述契约条件存储在PPP用户管理表56的用户名为“yamada”的入口中，执行监视信息包数56-10的计数(S29)和超出阈值的判定。用户名为“yamada”的监视信息包数超出阈值时，接入服务器4通过RADIUS协议处理例程55生成例如Vendor-Specific属性指定为Vendor Type(6)＝“1001”、VendorType(7)＝“设定值超出”的Account ing request(interim-update)信息包302，将其发送给认证/计费服务器21(S10)。
认证/计费服务器21接收上述Accounting request(interim-update)信息包302后，更新计费管理数据库211的用户名为“yamada”的入口的统计数据(S31)。之后，请求邮件服务器23向用户名为“yamada”的邮件地址发送通知超出监视信息包数的邮件(S310)，而且向接入服务器4发送成为Accounting request(interim-update)信息包302的接收响应的Accounting response信息包数(S11)。
邮件服务器23根据来自认证/计费服务器21的通知内容更新数据库231(S32)后，对于指定的使用者的邮件地址发送监视信息包数超出的通知邮件(S33)。通过以上顺序，因特网使用者可实时地通知来自预先指定的IP地址的信息包通信量超出了指定值。
以上实施例中，作为预先在使用者与因特网服务提供商之间建立的契约条件，将信息包损失数和来自指定IP地址的信息包通信量分别作为独立的参数进行设定，但在例如指定多个监视IP地址、将信息包损失数限定在来自特定IP地址的信息包等的、监视服务应收集的统计信息的种类和指定形式中许可有实施例以外的种种变形。
实施例中，在接入服务器4和认证/计费服务器21之间的交换信息包中，由Vendor-Specific属性内的Vendor Type指定各种参数信息，但可使用由RFC2866作为reserved(包租)规定的属性。