服务控制网络系统的制作方法

文档序号:7550967阅读:79来源:国知局
专利名称:服务控制网络系统的制作方法
技术领域
本发明一般地涉及一种服务控制网络系统,更具体地涉及一种可以针对每个应用为各个用户提供服务的服务控制网络系统。此外,本发明还涉及服务控制网络系统中的服务器管理服务信息以及对终端单元提供该服务的服务执行单元。
背景技术
作为一种提供为各个用户定制的通信服务的传统技术,已经公开了一种通过减少要在服务控制程序中保持的个体用户信息量,从而减少由于在各服务控制单元之间传送信息而引起的服务控制单元中的服务控制程序的负荷的方法。(例如,请参考专利文献1)此外,还公开了一种根据设置在服务控制单元中的处理策略,提供针对各个用户定制的服务的方法,其中服务控制单元存储了各个用户的情况以及各用户的处理策略集,该处理策略集包括请求与一用户进行通信的对端用户、所请求的用户的情况以及对应于请求内容的处理。(例如,请参考专利文献2)同时,最近几年,提出了基于策略的连网(PBN,Policy-BasedNetworking)的概念,这是一种用于控制IP网络的框架。在PBN中,策略服务器(policy server)将网络运行策略设置到网络设备内。通过参考这些策略,网络设备执行网络服务,以满足QoS(服务质量)要求等。
然而,鉴于将策略设置在各个移动终端(用户)内,所以要求为具有支持这种移动终端的可能性的全部设备设置策略,这样导致整个网络上的策略设置处理量增加。此外,为了将PBN中通报的信息应用于由移动IP等指定的各基本服务,需要制订应用于各个服务的具体规范,并对实施过程进行研究。
为了避免出现上述的策略设置处理量增加的问题,可以考虑一种利用用户主机终端对网络进行连接验证处理或移动协议(例如,移动IP)位置注册处理的方法。根据该方法,各个用户的服务控制信息包括在在具有主机验证过程的各设备之间传送的消息中。该服务控制信息被分配给边缘路由器(edge router,位于核心网的边缘区域的路由器)。边缘路由器参考所获得的服务控制信息,并根据获取的服务控制信息,控制服务行为。
然而,边缘路由器执行的这种服务控制适于封闭在网络层中的服务(OSI参考模型中的第三层,或IP层)。
与在上述层中执行的服务相比,在比第四层高的层,例如第七层(或应用层)中执行的服务具有以下描述的特征。(以下将该服务称为“高层服务”。)通常,高层服务不依赖于数据包传送路径等。这种服务并不总是适于在核心网的边缘区域内执行。
此外,通常,无法识别高层服务是不是在验证用户终端的接入时请求的。例如,对于开始在公众无线LAN服务区内使用的用户,不能识别该用户是要首先使用IP电话服务,还是要访问web服务。
日本专利申请公开特开平8-256367号公报(第3-5页,以及图1)[专利文献2]国际公开号为00/19326的PCT公报发明内容考虑到上述背景技术提出本发明。本发明的目的是提供针对用户,以及针对应用的定制高层服务。
为了达到上述目的,根据本发明的服务控制网络系统包括服务执行单元,为终端单元提供服务;以及服务器,用于管理服务信息,该服务信息规定了要提供给终端单元的服务。服务执行单元进一步包括请求传输部,用于在从终端单元接收到服务启动请求或注册请求时,向服务器发送参考请求,请求对应于该服务启动请求或注册请求的服务信息;以及服务提供部,用于根据请求传输部发送来的参考请求所参考的服务信息,为终端单元提供服务。此外,服务器包括服务信息发送部,用于将对应于服务执行单元发出的参考请求的服务信息发送到服务执行单元。
此外,根据本发明,该服务控制网络系统包括第一域、容纳在第一域中的第一服务器、第一服务执行单元以及终端单元。第一服务器进一步包括存储部,用于存储第一服务信息,该第一服务信息规定将为终端单元提供的服务;以及服务信息发送部,用于在从第一服务执行单元接收到所述参考请求时,根据第一服务信息的参考请求,将存储在存储部中的第一服务信息发送到第一服务执行单元。第一服务执行单元包括第一请求发送部,用于在从终端单元接收到服务启动请求或注册请求时,向第一服务器发送参考请求,请求与服务启动请求或注册请求相对应的第一服务信息;以及第一服务提供部,用于根据第一请求发送部发送来的请求所参考的第一服务信息,为终端单元提供服务。
另外,根据本发明,该服务控制网络系统包括容纳第一服务器和终端单元的第一域,以及容纳第二服务器和第二服务执行单元的第二域,终端单元移动到第二域中。第一服务器包括存储部,用于存储第一服务信息,第一服务信息规定将为终端单元提供的服务;以及服务信息发送部,用于在从第二服务器接收到参考请求时,根据第一服务信息的参考请求,将存储在存储部中的第一服务信息发送到第二服务器。第二服务执行单元包括第二请求发送部,用于在从终端单元接收到服务启动请求或注册请求时,向第二服务器发送参考请求,请求对应于服务启动请求或注册请求的第一服务信息;以及第二服务提供部,用于根据第二请求发送部发送来的请求所参考的第一服务信息,为终端单元提供服务。第二服务器包括传送部,用于将第二请求发送部发出的参考请求传送到第一服务器,而将第一服务器发出的第一服务信息传送到第二服务执行单元。
在此,“注册请求”表示请求对于预定的服务对终端单元的存在进行注册的请求。例如,它包括对于VoIP中的SIP服务,终端单元进行的对其自身的存在进行注册的请求。
根据本发明,在从终端单元接收到服务启动请求或注册请求时,服务执行单元向服务器请求对应于该服务启动请求或注册请求的服务信息(服务控制信息)。这样可以识别用户要求接收的服务。此外,服务执行单元可以获取对应于所识别的服务的服务信息。因此,服务执行单元可以执行与各个用户以及提供给用户的服务相对应的服务控制。
此外,根据本发明,服务器容纳在通信网络内形成的第一域中。服务器包括存储部,用于存储第一服务信息,第一服务信息规定了将为容纳在第一域内的终端单元提供的服务;接收部,用于接收从容纳在第一域内、用于为终端单元提供服务的第一服务执行单元发出的第一服务信息参考请求;以及发送部,用于根据接收部接收到的参考请求,将存储在存储部内的第一服务信息发送到第一服务执行单元。
此外,根据本发明,容纳在通信网络内形成的第一域中的服务器包括存储部,用于存储第一服务信息,第一服务信息规定了将为容纳在第一域内并移动到通信网络内形成的第二域中的终端单元提供的服务;接收部,用于接收从容纳在第二域内、用于为终端单元提供服务的第二服务执行单元发送、并由容纳在第二域内的第二服务器传送的第一服务信息参考请求;以及发送部,用于根据接收部接收到的参考请求,通过第二服务器,将存储在存储部内的第一服务信息发送到第二服务执行单元。
根据本发明,服务执行单元设置在通信网络内,用于为接入该通信网络的终端单元提供服务。该服务执行单元包括存储部,用于存储规定服务的服务信息;发送部,用于在从终端单元接收到服务启动请求或注册请求时,向设置在该通信网络中用于管理服务信息的服务器发送参考请求,请求规定与该服务启动请求或注册请求相对应的服务的服务信息;接收部,用于根据发送部发出的参考请求,接收服务器发出的服务信息,并将接收到的服务信息存储到存储部中;以及服务提供部,用于根据存储在存储部中的服务信息,为终端单元提供服务。
通过以下参考附图对本发明实施例进行说明,本发明的其他目标和特征将变得更加明显。


图1是根据本发明的实施例的服务控制网络系统的示例结构的方框图。
图2A示出了本地SPC的示例。
图2B示出了全局SPC的示例。
图3示出了由验证模块执行的L-SPC请求消息处理流程的流程图。
图4示出了从用户主机终端发出服务启动消息到服务执行单元发出G-SPC请求消息并接收G-SPC响应消息的处理流程的顺序图。
图5示出了在应用验证模块内执行的发送G-SPC请求消息的处理流程的流程图。
图6A示出了G-SPC请求消息和L-SPC请求消息的数据结构。
图6B示出了G-SPC响应消息和L-SPC响应消息的数据结构。
图7示出了在应用验证模块中执行的G-SPC响应消息和L-SPC响应消息的接收处理流程的流程图。
图8示出了由验证服务器分别管理的主SPC表、L-SPC表以及G-SPC表的示例。
图9示出了操作示例1中的服务控制网络系统的示例结构框图。
图10示出了操作示例1中的服务控制网络系统的处理流程的顺序图。
图11示出了操作示例2中的服务控制网络系统的示例结构框图。
图12示出了操作示例2中的服务控制网络系统的处理流程的顺序图。
图13示出了操作示例3中的服务控制网络系统的示例结构框图。
图14示出了操作示例3中的服务控制网络系统的处理流程的顺序图。
图15示出了操作示例4中的服务控制网络系统的示例结构框图。
图16示出了操作示例4中的服务控制网络系统的处理流程的顺序图。
具体实施例方式
以下参考

本发明的优选实施例。
<服务控制网络系统的结构示例>
图1示出了根据本发明的实施例的服务控制网络系统的结构示例的方框图。作为示例,该服务控制网络系统具有3个网络,它们是接入网1、2以及核心网3。
接入网1是(例如)LAN、无线LAN等,它们由用户操作的用户主机终端H1(例如,个人计算机、电话机或具有电话机的个人计算机)接入。此外,接入网2是(例如)LAN、无线LAN等,它们由用户主机终端H2(例如,个人计算机、电话机或具有电话机的个人计算机)接入。
核心网3是(例如)IPv6因特网。根据本发明的实施例,核心网3被划分为(例如)3个局部网(partial network,域),它们被称为域D1、域D2以及中继域D3。
在域D1中设置有验证服务器A1、边缘单元EN1以及服务执行单元SN1。在域D2中设置有验证服务器A2、边缘单元EN2以及服务执行单元SN2。在中继域D3中设置有中继单元(例如,路由器)R3。此外,作为示例,图1中示出了两个域D1、D2。此外,在各个域中示出了一个边缘单元和一个服务执行单元。然而,在网络中也可以包括3个以上的域。此外,在各个域中可以存在2个以上的边缘单元以及2个以上的服务执行单元。
各个验证服务器A1、A2是(例如)AAA(验证、授权以及记帐,Authentication,Authorization,Accounting)服务区,它们执行验证、授权以及记帐功能。
验证服务器A1设置在它所负责的域D1内,在访问时,验证服务器A1对归属链路(home link)是域D1的用户主机终端(例如,用户主机终端H1)进行验证。验证服务器A1还保留并管理服务概要高速缓存(ServiceProfile Cache,SPC),SPC中包含在服务执行单元(例如,服务执行单元SN1)为相关的用户主机终端执行服务时要参考的服务合同条件(服务信息和服务控制信息)。在从服务执行单元接收到SPC分配请求时,验证服务器A1提取保留在其内的SPC,并将该SPC分配给始发该请求的服务执行单元。
验证服务器A2还对归属链路是验证服务器2负责的域D2的用户主机终端(例如,用户主机终端H2)进行验证,并为相关的用户主机终端保留并管理SPC。在服务执行单元发出请求时,验证服务器A2将SPC分配给始发该请求的服务执行单元。
如下所述,为各个用户的各个应用(服务)提供SPC。各个SPC被进一步划分为保持在验证服务器A1和A2内的本地SPC和全局SPC。因为为各个用户的各个应用设置SPC,所以可以针对应用以及针对用户为用户提供定制服务。
服务执行单元SN1、SN2是用于执行各种服务的单元。服务执行单元SN1、SN2分别是提供IP电话功能(IP语音,或VoIP)的对话控制服务器(SIP服务器,其中“SIP”表示对话启动协议)、任何类型的Web服务器等。在该实施例中,将以下说明的应用验证模块安装到提供通用服务的这种服务器内。
边缘单元EN1、EN2是位于各个域D1、D2的边缘处的网络单元。例如,边缘单元EN1、EN2是分别位于域D1与外部接入网1之间的边界,以及域D2与外部接入网2之间的边界上的边缘路由器。
用户主机终端H1、H2是根据各个主机确定的合同条件分别接收服务的终端单元。域D1是用户主机终端H1的归属链路(归属网络),域D2是用户主机终端H2的归属链路(归属网络)。相应的,验证服务器A1保留并管理用户主机终端H1的SPC(本地SPC和全局SPC),而验证服务器A2保留并管理用户主机终端H2的SPC(本地SPC和全局SPC)。
用户主机终端H1、H2可以分别具有与各个服务执行单元SN1、SN2提供的服务相关的客户端功能等。例如,在使用VoIP时,在各个用户主机终端中安装用于控制SIP(Session Initiation Protocol,对话启动协议)等的通话软件。
<SPC的内容>
如上所述,验证服务器A1、A2分别为各个用户主机终端(用户)保留并管理SPC。SPC是一个数据集,其中描述了控制各个合同用户(合同用户主机终端)使用的服务所需的服务行为。利用该SPC,可以为各个用户提供单独的服务。SPC被划分为本地SPC(Local SPC,以下简称为L-SPC)和全局SPC(Global SPC,以下简称为G-SPC),并相应地进行管理。
(1)L-SPC的内容L-SPC是位于与容纳合同用户主机终端的域(合同用户主机终端的归属链路)相同的域内的服务执行单元所参考的SPC。例如,在图1中,容纳在域D1内的服务执行单元SN1参考容纳在同一域D1内的验证服务器A1中保留的L-SPC。
因为在与容纳请求服务的主机的域相同的域内参考L-SPC,所以L-SPC将这种条件描述为可以公共地应用于各个服务,而与服务执行单元无关。例如,L-SPC包括端口号、协议信息等。
此外,L-SPC中描述的服务是在有关用户主机终端始发数据包时可以识别以执行的服务。例如,该服务相当于不取决于特定ASP(应用服务提供商),而根据特定协议类型启动的服务。即,该服务相当于使用本发明的功能为站点提供的流式广播服务提供公共附加值的情况。
服务执行单元中的L-SPC与对端用户主机终端内的G-SPC一起被称为执行判定条件。即,在为始发服务请求(数据包)的用户主机终端提供对应于合同条件的单独服务时,L-SPC被称为执行条件。
图2A是L-SPC的示例。在该图中,项目1表示在不规定站点而利用HTTP(超文本传输协议)提供信息服务的情况下,对从服务执行单元发送到用户主机终端的数据进行压缩。此外,项目2表示在不规定电话运营公司而提供IP电话(VoIP)的情况下,在开始通信之前,将语音商业消息(commercial message,CM)转发到用户主机终端,并因为该CM的插入而对用户主机终端的电话费打折。
(2)G-SPC的内容
G-SPC是存在于与容纳合同用户主机终端的域不同的域内的服务执行单元所参考的SPC。例如,在图1中,服务执行单元SN2参考容纳在域D1内的验证服务器A1保留的G-SPC。G-SPC的内容描述了各单独服务的行为。
G-SPC中规定的服务类型描述了提供应用的各个站点的控制内容。作为典型示例,对于流式服务,在规定特定信息的服务(例如,只对于音乐节目)时,在G-SPC内规定该特定服务。
图2B示出了G-SPC的示例。与图2A相比,容易理解,在图2A中没有规定站点,图2B中规定了站点,该站点作为公司A的流式站点(streamingsite)。例如,在项目1,在从公司A的流式站点接收服务时,在开始广播之前,广播30秒的商业消息。这样,用户主机终端可以得到服务费的减免。
<L-SPC的分配方法>
接着,以下将说明验证服务器将L-SPC分配给服务执行单元的方法。
L-SPC是与设置在直接容纳用户主机终端的域(用户主机终端的归属链路)中的服务执行单元执行的服务相关的SPC。必须在执行应用的同时分配L-SPC。
关于L-SPC分配方法,可以应用以下两种方法一种方法是在执行服务之前,在注册服务时进行分配;另一种方法是在执行服务时顺序进行分配。以下将详细说明这两种方法。
(1)在注册服务时进行分配在某些IP服务中,除了在每次启动服务时,还在把用户主机终端的位置注册到特定域(子网)中时,或者在接收到访问验证时,在服务执行单元中注册服务执行授权。例如,在用于进行VoIP对话控制的SIP中,利用“注册(Register)”消息,用户主机终端把它自己注册在相邻SIP服务器上。
在用户主机终端停留在有关域中的时期中,该注册消息有效。在特定时间中L-SPC的内容不频繁发生变化的情况下,在使用该服务之前进行注册时,服务执行单元请求对相关用户主机终端进行验证的验证服务器发送始发该请求的用户主机终端的L-SPC。响应于该请求,验证服务器在应答消息中将L-SPC分配给服务执行单元。然后,将分配的L-SPC存储到服务执行单元中。
在因为用户主机终端移动到外部等原因使得L-SPC没有必要时,删除分配并存储到服务执行单元中的L-SPC。利用用于管理与该用户主机终端相关的注册消息的有效期的管理表,服务执行单元对删除等管理所需的有效期进行管理。这样,就不必设置专门用于L-SPC的管理机制。
即,在用户主机终端位于该服务执行单元附近时,注册消息进行注册以使用服务执行单元执行的SIP。在诸如用户主机终端移动到外部的特定条件下,服务执行单元确定保持期结束,并删除所注册的信息。同时,因为在注册消息的有效期中使用了L-SPC,所以可以结合注册消息的管理表,执行诸如删除无用L-SPC的动作。这样就不必在服务执行单元中设置专门用于L-SPC的管理机制。
因此,通过结合注册消息管理在服务执行单元中进行L-SPC管理,专用L-SPC管理机制就没有必要了,这样就减小了服务执行单元的负荷。
触发服务执行单元向验证服务器请求L-SPC的定时可以与上述在服务注册表中进行注册的过程同步。在以下的说明中,作为示例,将说明服务执行单元是SIP服务器的情况。用户主机终端向最靠近该用户主机终端的SIP服务器发送第一注册消息。在将有关该用户主机终端注册到设置在SIP服务器中的用户主机终端信息表中时,SIP服务器向验证服务器请求有关该用户主机终端的L-SPC。然后,SIP服务器从验证服务器接收L-SPC,并存储接收到的L-SPC。
(2)在执行服务时连续进行分配如果作为服务特征,服务执行单元具有在用户使用该服务之前进行用户主机终端注册(验证)的功能,则可以应用上述的在服务注册时执行的分配方法。在不频繁修改SPC的情况下这种方法是合适的。
相反,关于服务注册过程(例如,在每次接收到请求时要执行的服务),存在另一种在服务没有注册过程时可以应用于服务执行单元的L-SPC分配方法。在这种情况下,在执行服务时连续地分配L-SPC。
在该连续分配过程中,在服务执行单元从用户主机终端接收到服务请求(例如,HTTP请求消息)时,要求服务执行单元识别接收到的消息是始发该请求的用户主机终端发出的第一请求消息(在过去的一段时间中的第一个)。
为此,服务执行单元保持并管理一个服务使用条件管理表,并参考该管理表。如果该服务使用条件管理表中不存在与始发该请求消息的用户主机终端有关的信息,则服务执行单元认为该消息是第一请求消息。然后,服务执行单元向位于始发该请求的用户主机终端的域中的验证服务器请求L-SPC。此后,服务执行单元将包含在验证服务器发出的响应消息中的L-SPC存储在服务使用条件管理表中。
此外,服务执行单元以特定时间间隔监视服务使用条件管理表,并删除保存期已经过特定时间的用户主机终端注册信息。因此,可以降低管理不频繁使用的用户主机终端的成本(考虑到存储容量、进行管理所需时间等)。
<G-SPC的分配方法>
可以结合用户主机终端的接入验证或位置注册过程,将与第3层(网络层、IP层)的服务,例如QoS(服务质量)和数据包过滤(packetfiltering)有关的SPC分配给边缘单元。
相反,高层应用(通常是第7层)的特征在于,服务执行位置随着服务的内容而不同。例如,在网络中的最佳位置,设置最佳数量的用于提供VoIP服务或各种Web服务的服务执行单元(服务器)。因此,分配SPC的位置取决于提供服务的服务执行单元。
因此,关于高层服务,为了针对各个合同用户主机终端,根据各自的条件分配SPC,需要研究一种适于散布在网络中的各单独服务执行单元的SPC分配方法。
根据本发明的实施例,以如下方式为服务执行单元分配G-SPC在订购服务的用户主机终端向服务执行单元发送服务启动请求消息时,服务执行单元请求用于管理有关用户主机终端的合同和验证信息的验证服务器发送该用户主机终端的G-SPC。通过发送包括该用户主机终端的G-SPC的响应消息,验证服务器响应该请求。
在此,在服务执行单元的域不同于始发该请求的用户主机终端的域时,通过位于服务执行单元的域中的另一个验证服务器(本地验证服务器),服务执行单元向位于始发该请求的用户主机终端的域中的验证服务器请求G-SPC。
在本发明的该实施例中,将上述过程的一系列动作称为“应用验证(application authentication)”,利用该应用验证,服务执行单元获得用户主机终端的G-SPC,并确定是否执行该服务,以及执行哪个服务内容。
不考虑用户的合同条件,对于同样条件下提供的服务,不需要这种单独服务控制。如果在通用条件之外,还存在针对各个用户的合同用户条件,则可以应用上述应用验证。
<应用验证功能>
存在于网络中的各种服务执行单元采用不同的执行开始定时以及不同的协议。因此,为了提供根据本发明的实施例的服务控制,需要设置公共装置(common means),以使各个服务执行单元获得请求执行服务的用户主机终端的L-SPC或G-SPC。
作为这种公用装置,将应用验证模块(作为示例,由软件构成)附加到根据本发明的实施例的服务执行单元(例如,SIP服务器或Web服务器)中。应用验证表示获取G-SPC的过程和根据所获取的G-SPC的描述判定服务执行内容的过程。
应用验证模块具有扩展AAA客户机功能和G-SPC管理功能。在此,“扩展AAA客户机功能”设置在服务执行单元端,使应用验证功能与验证服务器(AAA服务器)交互,以从支持有关用户主机终端的验证服务器处获得用户主机终端的G-SPC以进行服务控制。此外,设置“G-SPC管理功能”以便将各个用户主机终端的G-SPC保持特定的时间。
在执行服务时,服务执行单元根据G-SPC内容工作。
以下将说明应用验证模块执行的L-SPC请求消息传输处理、G-SPC请求消息传输处理以及L-SPC/G-SPC响应消息接收处理。
图3示出了应用验证模块执行的L-SPC请求消息传输处理的流程图。
应用验证模块处于消息接收等待状态下(S21)。在接收到消息时(S21中的“是”),应用验证模块检查该消息中的TCP(传输控制协议)或UDP(用户数据报协议)端口号。如果该端口号是服务执行单元正在监视的端口号,则应用验证模块执行由这个消息接收所触发的以下处理。
首先,根据用户主机终端发出的服务启动消息,应用验证模块判定用户主机终端是否与有关服务执行单元位于同一个域中(S23)。通过将该消息的源地址(IP地址)与服务执行单元的地址(IP地址)进行比较,进行此判定。
如果该服务启动消息是由同一个域中的用户主机终端始发的(S23中的“是”),则应用验证模块从服务启动消息中提取始发该服务启动请求的用户主机终端信息(S24)。该用户主机终端信息至少是该用户主机终端的IP地址(该服务启动消息的传输源地址)和该用户主机终端的NAI(网络接入标识符,Network Access Identifier)之一。
相反,如果该服务启动消息不是由同一个域中的用户主机终端始发的,则L-SPC没有必要,并因此使应用验证模块返回消息接收等待状态。
接着进入步骤S24,应用验证模块判定是否可以根据所提取的用户主机终端信息,唯一地识别用户主机终端(S25)。例如,如果该服务启动消息是通过代理服务器传输的,则代理服务器会隐藏始发该服务请求的用户主机终端的地址。在这种情况下,请求源地址变成代理服务器的地址,因此,不能唯一地识别用户主机终端。
这样,在不能唯一地识别用户主机终端时(S25中的“否”),应用验证模块将预定的缺省L-SPC(规定值)设置到L-SPC请求参数中(S27)。相反,在可以唯一地识别用户主机终端时(S25中的“是”)时,应用验证模块将可以唯一识别用户主机终端的信息设置到L-SPC请求参数中(S26)。
此后,应用验证模块生成L-SPC请求消息(S28),并将生成的L-SPC请求消息发送到同一个域中的验证服务器(S29)。
发送该L-SPC请求消息后,应用验证模块返回消息等待状态(S21)。
图6A示出了L-SPC请求消息(或G-SPC请求消息)的数据结构。L-SPC请求消息(或G-SPC请求消息)包括IP/TCP/UDP数据包报头、消息类型代码、用于进行服务控制的主机标识信息1(例如,用户主机终端的IP地址)以及用于进行服务控制的主机标识信息2(例如,用户主机终端的NAI)。
IP/TCP/UDP数据包报头包括用于识别特定服务(应用)的端口号。关于利用主机标识信息1或主机标识信息2识别的主机终端(用户)的SPC,验证服务器搜索并提取与利用端口号识别的服务相关的L-SPC(或G-SPC)。这样,服务执行单元就可以针对各个用户,并针对各个应用获得SPC。
消息类型代码表示有关消息是L-SPC请求消息还是G-SPC请求消息。根据该消息类型代码,位于接收端的单元(在此为验证服务器)识别该消息并识别是搜索、提取L-SPC,还是搜索、提取G-SPC。主机标识信息1或2是将在步骤S26或S27中设置为L-SPC请求参数的信息。
图4示出了从用户终端发出服务启动消息到服务执行单元发出G-SPC请求消息并接收G-SPC响应消息的处理流程的顺序图。该图示出了举例说明图1所示的服务控制网络系统的顺序图。
首先,用户操作用户主机终端H1并向服务执行单元SN2请求服务,因此,用户主机终端H1将有关服务的服务启动消息发送到服务执行单元SN2(S1)。该服务启动消息是(例如)访问服务执行单元SN2(Web服务器)的主页的消息。
在此,也可以是在服务执行单元SN1中接收该服务启动消息,并且服务执行单元SN1判定是否需要与用户主机终端H1相关的L-SPC。此外,作为这个判定的结果,如果判定L-SPC是必要的,则服务执行单元SN1可以向验证服务器A1请求L-SPC并从其接收L-SPC。
在接收到服务启动消息时,服务执行单元SN2判定是否必需参考G-SPC来判定服务启动消息中表示的服务是否必要(S2)。根据有效G-SPC(即,有效期过期之前的G-SPC)是否存储在服务执行单元SN2中,以及在执行有关服务时,服务执行单元SN2是否必需参考始发该请求的用户主机终端中的G-SPC,进行该判定。
在服务执行单元SN2判定参考G-SPC是必要的(S2中的“是”)时,服务执行单元SN2生成G-SPC请求消息,向验证服务器A2请求发出执行服务的请求的用户主机终端H1的G-SPC,并将该请求发送到域D2中的验证服务器A2(S3)。G-SPC请求消息具有上述图6A所示的数据结构。
根据G-SPC请求消息的内容(即,用户主机终端H1的IP地址或NAI,参考图6A),验证服务器A2识别出用户主机终端H1是容纳在验证服务器A1(即,域D1)中(并被验证服务器A1管理),并将接收到的G-SPC请求消息传送到验证服务器A1。在此,这两个验证服务器具有互信关系,而且各个验证服务器事先分别具有另一个验证服务器的IP地址。根据对端服务器的该IP地址,传送G-SPC请求消息。
在接收到G-SPC请求消息时,验证服务器A1搜索用户主机终端H1的G-SPC(S4)。如果存在用户主机终端H1的G-SPC,则验证服务器A1生成包含所搜索到的G-SPC的G-SPC响应消息,并将该响应消息发送到始发该请求的服务执行单元SN2(S5)。
图6B示出了G-SPC响应消息(或L-SPC响应消息)的数据结构。G-SPC响应消息(或L-SPC响应消息)包括IP/TCP/UDP数据包报头、消息类型代码、主机标识信息1(例如,用户主机终端H1的IP地址)、主机标识信息2(例如,用户主机终端H1的NAI)、搜索到的SPC以及返回码。
“消息类型代码”表示有关消息是G-SPC响应消息还是L-SPC响应消息。根据该消息类型代码,位于接收端的单元(服务执行单元SN2)识别该消息。“搜索到的SPC”是验证服务器搜索和发现的G-SPC(或L-SPC)。“返回码”是与信息处理结果等相关的信息,例如,它具有表示搜索成功完成的值“0”、表示搜索未发现对应于该请求的SPC的值“2”,以及表示包含在该消息中的SPC是缺省SPC的值“3”。
返回去参考图4,将该G-SPC响应消息发送到验证服务器A2,此后,将它从验证服务器A2传送到服务执行单元SN2。
在接收到G-SPC响应消息时,服务执行单元SN2检验G-SPC响应消息的正常性(S6)。利用G-SPC响应消息是否包含G-SPC来检验G-SPC响应消息的这种正常性。在包含G-SPC时,判定G-SPC响应消息正常。
在判定G-SPC响应消息正常时,服务执行单元SN2提取包含在G-SPC响应消息中的G-SPC,并将G-SPC存储到SPC管理表中(S7)。
图5示出了应用验证模块执行的传输G-SPC请求消息的传输处理流程的流程图。该图示出了在服务执行单元SN2(应用验证模块)中执行的传输G-SPC请求消息的详细传输处理过程(图4中的步骤S3的细节)。
应用验证模块保持消息接收等待状态(S31)。在接收到消息时(S31中的“是”),应用验证模块检验所接收消息的TCP/UDP端口号。如果该端口号是由该消息接收触发而由服务执行单元监视的端口号,则执行以下处理。
首先,应用验证模块判定是否支持由用户主机终端发出的服务启动消息请求启动的应用(S33)。根据包含在服务启动消息中的端口号等进行此判定。
如果服务执行单元支持该应用(S33中的“是”),则应用验证模块从服务启动消息中提取用于始发服务启动请求的用户主机终端信息(S34)。该用户主机终端信息至少是用户主机终端的IP地址(服务启动消息的传输源地址)和用户主机终端的NAI(网络接入标识符)之一。
相反,如果服务执行单元不支持该应用,则G-SPC不是必要的,因此,应用验证模块返回消息接收等待状态。
接着,进入步骤S34,根据提取的用户主机终端信息,应用验证模块判定是否可以唯一地识别用户主机终端(S35)。例如,如果通过代理服务器发送服务启动消息,则代理服务器会隐藏始发服务请求的用户主机终端的地址。在这种情况下,请求源地址变成代理服务器的地址,因此,不能唯一地识别用户主机终端。
在不能唯一地识别用户主机终端时(S35中的“否”),应用验证模块将预定的缺省G-SPC(规定值,如下所述)设置到G-SPC请求参数中(S37)。相反,在可以唯一地识别用户主机终端时(S35中的“是”)时,应用验证模块将可以唯一地识别用户主机终端的信息设置到L-SPC请求参数中(S36)。
此后,应用验证模块生成G-SPC请求消息(S38),并将生成的G-SPC请求消息发送到同一个域中的验证服务器(S39)。然后,应用验证模块返回消息等待状态。
接下来将说明应用验证模块(服务执行单元)执行的G-SPC响应消息和L-SPC响应消息的接收处理。图7示出了应用验证模块执行的G-SPC响应消息和L-SPC响应消息的接收处理的流程图。
应用验证模块处于消息等待状态(S41)。在每次接收到消息时(S41中的“是”),应用验证模块监视所接收消息的消息类型代码(S42)。根据图6B所示的消息类型代码判定消息类型代码。
在应用验证模块根据消息类型代码判定所接收消息是SPC响应消息(L-SPC响应消息或G-SPC响应消息)时(S43中的“是”),应用验证模块根据返回码检验该消息的正常性(参照图6B)(S44)。同时,在接收消息不是SPC响应消息时,应用验证模块重新返回消息等待状态(S41)。
在步骤S43,在判定该消息正常时,应用验证模块判定该消息是否包含SPC(L-SPC或G-SPC)(S45)。
在包含SPC时(S45中的“是”),应用验证模块提取该SPC,并将提取的SPC注册到SPC管理表中(S46)。即,应用验证模块将G-SPC注册到G-SPC管理表中,而将L-SPC注册到L-SPC管理表中(S49,S50)。在其他情况下,应用验证模块执行消息错误处理(S51)。此后,应用验证模块返回消息接收等待状态(S41)。
在步骤S45,在不包含SPC时,应用验证模块在G-SPC请求参数中设置缺省G-SPC(S48),此后返回消息接收等待状态(S41)。
在步骤S44,在判定消息不正常时,应用验证模块执行消息错误处理(S47),然后,返回消息接收等待状态(S41)。
<验证服务器中的G-SPC和L-SPC管理功能>
如上所述,验证服务器(AAA服务器)保持各个合同用户(用户主机终端)的SPC(L-SPC和G-SPC)。
为了管理各个用户的SPC,根据本发明的实施例,为验证服务器设置主SPC表,规定各个用户的L-SPC和G-SPC;各个用户的L-SPC表,针对各个用户规定L-SPC;以及各个用户的G-SPC表,针对各个用户规定G-SPC。
如图8所示,主SPC表包括用于识别各个合同用户的用户号和基本合同信息,这两种信息都作为各个用户的基本信息。此外,主SPC表包括L-SPC指针,表示指向各个用户的L-SPC表的指针;以及G-SPC指针,表示指向各个用户的G-SPC表的指针。
为各个用户设置的L-SPC表是用于针对各个用户管理L-SPC的表。在图8中,示出了用户号为000001的用户的L-SPC。各个用户的L-SPC表包含SPC号、应用该L-SPC的条件1和条件2、以及SPC内容。
各个用户的G-SPC表是用于针对各个用户管理G-SPC的表。在图8中,示出了用户号为000001的用户的G-SPC。各个用户的G-SPC表包含SPC号、应用该G-SPC的条件1和条件2以及SPC内容。
通过利用这些表管理SPC,验证服务器可以设置并保持多个信息集(搜索关键字),用于针对各个应用,分别对于G-SPC和L-SPC识别主机。
在此,在服务执行单元中,可能存在因为用户主机终端始发的服务执行请求被HTTP代理服务器等截取,所以不能获取始发请求的用户主机终端的固有信息的情况。例如,对于通过HTTP代理服务器传输的HTTP请求,由与代理服务器相关的信息代替请求源信息(传输源地址等)。因此,不能识别始发该请求的用户主机终端的地址。
在这种情况下,在“详细请求源信息不可用”的状态下,服务执行单元中的应用验证功能将SPC请求消息发送到最近的验证服务器。在接收到该消息时,最近的验证服务器估计表示请求源信息的、始发该请求的用户主机终端距离代理服务器的位置,并返回不识别特定用户的通用条件的G-SPC。这种SPC被称为缺省SPC。
<操作示例>
接着,将以采用VoIP的电话通信为例,说明该服务控制网络系统的典型操作示例。
(1)操作示例1
操作示例1代表在服务合同用户的各用户主机终端(电话呼叫的主叫方和被叫方)位于同一归属链路上,而且服务执行单元与用户主机终端存在于同一链路上时,应用验证过程触发的执行SPC分配和单独服务控制的执行过程的示例。
图9示出了这种情况下的服务控制网络系统的结构示例的方框图。图10示出了这种情况下的服务控制网络系统的处理流程的顺序图。
在图9中,设置在用户住宅等中的主叫方用户主机终端H1位于归属链路(域D1)上。设置在呼叫中心的被叫方用户主机终端H3也位于同一个域D1中。此外,服务执行单元SN1也存在于该同一个域D1中,而且从域D1中的验证服务器A1获取用户主机终端H1的L-SPC(L-SPC(A))和用户主机终端H3的L-SPC(L-SPC(C))。此外,用户主机终端H1和用户主机终端H3容纳在接入网中。
用户主机终端H1的用户(服务合同用户)使用用户主机终端H1中提供的IP电话功能(例如,VoIP软件),并通过指定对端方(在此为用户主机终端H3)而操作该终端以始发呼叫(图10中的S61)。
在被用户的拨号操作启动时,用户主机终端H1生成指定对端用户主机终端H3的服务启动消息(对话启动消息(SIP邀请消息,SIP Invite))。然后,通过边缘单元EN1,用户主机终端H1将生成的服务启动消息发送到最近的服务执行单元(SIP服务器)SN1(图9中带箭头的实线(1))。因为用户主机终端H1事先知道服务执行单元SN1的位置(IP地址等),所以用户主机终端H1可以将服务启动消息发送到服务执行单元SN1。
通过从用户主机终端H1接收SIP邀请消息,服务执行单元SN1检测服务的启动。然后,服务执行单元SN1判定是否需要在执行服务(即,生成VoIP对话)时请求(向验证服务器A1请求)用户主机终端H1的L-SPC(A)(图9中的标号(2),以及图10中的S62)。
如上所述,在事先利用注册消息获取了L-SPC(A)时,或者在上一次执行服务时利用L-SPC请求消息获取的L-SPC(A)仍然有效并且未被删除时,判定L-SPC(A)的请求没有必要。同时,在还未获得L-SPC(A)时,或者在因为有效期过期而删除了曾经获得的L-SPC(A)时,判定L-SPC(A)的请求是必要的。在以下的描述中,假设判定L-SPC(A)的请求是必要的。
根据该判定,服务执行单元SN1生成L-SPC请求消息,并将生成的L-SPC请求消息发送到用于管理用户主机终端H1的验证服务器A1(图10中的S63)。在此,利用(例如)作为主机验证协议的Diameter发送该L-SPC请求消息。
在从服务执行单元SN1接收到与用户主机终端H1相关的L-SPC请求消息时,验证服务器A1在数据库中搜索L-SPC(A),并从中提取该L-SPC(A)(图10中的S64)。
验证服务器A1将提取的L-SPC(A)发送回利用L-SPC响应消息始发了请求的服务执行单元SN1(例如,Diameter验证响应消息)(S65)。
在此,在L-SPC(A)已经处于服务执行单元SN1中时,省略处理步骤S63至S65。
然后,服务执行单元SN1提取包含在从验证服务器A1接收到的L-SPC响应消息中的L-SPC(A),并将该提取的L-SPC(A)存储到属于服务执行单元SN1的管理表中(图10中的S66),并根据L-SPC的描述内容启动服务执行功能(图9中的标号(3),和图10中的S67)。
由L-SPC(A)的设置过程触发后,服务执行单元SN1将服务启动消息(SIP邀请消息)传送到目标用户主机终端H3(图9中带箭头的实线(4))。
在将SIP邀请消息发送到用户主机终端H3后,服务执行单元SN1等待用户主机终端H3的响应(电话终端的摘机操作)。
如果因为用户主机终端H3忙或任何其他原因,用户主机终端H3不能接受该呼叫,则利用另一个通信协议,在使用户主机终端H1保持等待的一段时间中,服务执行单元SN1执行L-SPC(A)规定的服务(例如,15秒的语音CM广播服务,仍需等待的时间、等待人数的信息服务等)(图9中带箭头的虚线(4))。
在用户主机终端H3的用户(服务合同用户)操作该终端以响应用户主机终端H1发出的连接请求时,用户主机终端H3发送由这个操作触发的服务响应消息(SIP-Ack(确认)消息)(图10中的S68)。
通过服务执行单元SN1,用户主机终端H3发出的SIP-Ack消息被转发到用户主机终端H1。
当用户主机终端H1从用户主机终端H3接收到SIP-Ack消息时,在用户主机终端H1与用户主机终端H3之间建立对话。此后,在这些用户主机终端之间双向交换语音数据包,这样,这两个用户主机终端的用户就可以通信了。
此外,图9所示的L-SPC(C)是用户主机终端H3的L-SPC,在需要时,验证服务器A1将它发送到服务执行单元SN1。
(2)操作示例2操作示例2代表在服务合同用户的各用户主机终端位于同一个归属链路上,而且服务执行单元存在于用户主机终端的归属链路之外时,由应用验证过程触发的SPC分配和单独服务控制的执行过程的示例。
图11示出了这种情况下的服务控制网络系统的结构示例的方框图。图12示出了这种情况下的服务控制网络系统的处理流程的顺序图。
图11与图9的不同之处在于,在图11中,呼叫中心的用户主机终端H2容纳在域D2中,域D2位于用户主机终端H1的域D1(归属链路)之外,相应的,由域D2中的服务执行单元SN2执行服务。在这种情况下,服务执行单元SN2向验证服务器A1请求执行服务所需的、用户主机终端H1的G-SPC(被称为G-SPC(A))。
此外,在图11中,服务执行单元SN1和服务执行单元SN2设置在核心网中,用于中继这些服务执行单元的控制协议的中继单元TS设置在中继域中。这是基于VoIP语音通信网络的层级结构类似于传统电话交换系统的情况。
用户主机终端H1的用户(服务合同用户)使用用户主机终端H1的IP电话功能(例如,VoIP软件),并执行指定对端方(用户主机终端H2)的呼叫始发操作(图12中的S71)。
通过该用户的拨号操作,用户主机终端H1生成指定了对端用户主机终端H2的服务启动消息(对话启动消息,SIP邀请消息),并将该消息发送到最近的服务执行单元SN1(SIP服务器)(图11中的箭头(1))。用户主机终端H1事先知道服务执行单元SN1的位置(IP地址等),因此用户主机终端H1可以将服务启动消息发送到服务执行单元SN1。
通过从用户主机终端H1接收SIP邀请消息,服务执行单元SN1检测服务的启动。在执行服务(生成VoIP对话)时,服务执行单元SN1判定是否需要参考主叫方,即用户主机终端H1的L-SPC(A)(图12中的S72)。该判定过程的判据是服务执行单元各自拥有的控制规则。
在此,假定已经利用注册消息获取了L-SPC(A),而且假定不需要参考。根据这个判定,服务执行单元SN1不执行与获取L-SPC(A)相关的处理。
利用常规的SIP消息处理功能,通过中继单元TS,服务执行单元SN1将SIP邀请消息发送到服务执行单元(SIP服务器)SN2(图11中的箭头(1)),其中,服务执行单元SN2容纳被叫用户主机终端H2。
在从服务执行单元SN1接收到SIP邀请消息时,服务执行单元SN2将该消息识别为从外部域D1接收到的SIP邀请消息。此后,在启动有关服务时,服务执行单元SN2检验是否需要参考用户主机终端H1的单独服务条件,即用户主机终端H1的G-SPC(G-SPC(A)) (图11中的标号(2)SPC(A),图12中的S73)。在此,在以下的描述中,假定判定需要参考G-SPC(A)。
根据此判定,对于用户主机终端H1,服务执行单元SN2生成G-SPC请求消息(Diameter消息)。然后,通过位于服务执行单元SN2的域D2中的验证服务器A2,服务执行单元SN2将生成的G-SPC请求消息发送到主叫用户主机终端H1的归属链路中的验证服务器A1(图11中带箭头的虚线(3),以及图12中的S74)。
在从服务执行单元SN2接收到G-SPC请求消息时,验证服务器A1搜索数据库并从中提取G-SPC(A)(图12中的S75)。
接着,利用G-SPC响应消息(Diameter验证响应消息),验证服务器A1将提取的G-SPC(A)发送回始发该请求的服务执行单元SN2(图11中带箭头的虚线(4),以及图12中的S76)。
服务执行单元SN2从G-SPC响应消息中提取G-SPC(A),并将G-SPC(A)存储到属于服务执行单元SN2的管理表中(图12中的S77)。接着,根据G-SPC(A)的描述内容,服务执行单元SN2启动服务执行功能(图11中的标号(5),以及图12中的S78)。
在由服务执行单元SN2中的G-SPC(A)集触发后,服务执行单元SN2向被叫用户主机终端H2发送SIP邀请消息,然后等待用户主机终端H2发出的响应(电话终端的摘机操作)。在等待响应期间,SPC(A)用户主机终端H1根据G-SPC(A),从服务执行单元SN2接收服务(CM广播、关于等待时间的信息等)(图11中带箭头的虚线(6))。
通过操作该终端,对于用户主机终端H1发出的连接请求,用户主机终端H2的用户对用户主机终端H1作出响应。利用该操作,用户主机终端H2发出服务响应消息(SIP-Ack(确认)消息)(图12中的S79)。通过服务执行单元SN2、中继单元TS以及服务执行单元SN1,将用户主机终端H2发出的SIP-Ack消息转发到用户主机终端H1。
在用户主机终端H1接收到用户主机终端H2发出的SIP-Ack消息时,在用户主机终端H1与用户主机终端H2之间建立对话。此后,在这两个用户主机终端之间双向交换语音数据包,并进行通信。
此外,图11所示的L-SPC(C)是用户主机终端H2的L-SPC,在需要时,将该L-SPC从验证服务器A2发送到服务执行单元SN2。
(3)操作示例3操作示例3代表在服务合同用户的用户主机终端移到归属链路之外并进入另一个链路(域),而且服务执行单元存在于本地链路中时,由应用验证过程触发的执行SPC分配和单独服务控制的执行过程的示例。
图13示出了这种情况下的服务控制网络系统的结构示例的方框图。图14示出了这种情况下的服务控制网络系统的处理流程的顺序图。
在图13中,示出了利用位于用户住宅中的固定线路进行通信的用户主机终端H1的用户(服务合同用户)移到到同一个网络运营商提供的临时接入网(例如,无线LAN热点(hot spot)),并启动从该点到设置在呼叫中心的用户主机终端H3的呼叫的情况。用户主机终端H1的用户使用位于该用户所移动到的位置处的用户主机终端H1’(例如,便携式电话)。然而,这两个用户主机终端(即,用户主机终端H1和用户主机终端H1’)是由同一个服务订约人使用的,因此,由同一个L-SPC(L-SPC(A))或同一个G-SPC(G-SPC(A))规定为这两个用户主机终端H1、H1’提供的服务。此外,临时接入网、用户主机终端H1’以及用户主机终端H3容纳在域3中。域3包括验证服务器A3和服务执行单元SN3。
首先,用户主机终端H1’的用户(服务合同用户)操作该终端的IP电话功能,以指定进行通信的对端方(即,用户主机终端H3)而始发呼叫。
由用户的拨号操作启动之后,用户主机终端H1’生成指定对端方的用户主机终端H3的服务启动消息(SIP邀请消息),并将生成的服务启动消息发送到最近的服务执行单元(SIP服务器)SN3(图13中的箭头(1)和图14中的S81)。用户主机终端H1’事先知道最近SIP服务器的位置,从而将该服务启动消息发送到服务执行单元SN3。
服务执行单元SN3接收用户主机终端H1’发出的SIP邀请消息。在执行有关服务(生成VoIP对话)时,服务执行单元SN3判定需要参考主叫方的用户主机终端H1’的L-SPC(A)(图14中的S82)。需要L-SPC(A)的原因是因为,在初始条件下,L-SPC(A)不存在于该用户主机终端H1’所移动到的域D3中的服务执行单元SN3中。
在此,用户主机终端H1’容纳在不同于域D1的域D3中。然而,因为服务执行单元SN3在同一个域D3中提供服务,所以参考L-SPC(A),而不参考G-SPC(A)。
作为这个判定的结果,服务执行单元SN3将与用户主机终端H1’(H1)的L-SPC(A)相关的L-SPC请求消息发送到域D3中的验证服务器A3(图13中带箭头的虚线(3))。
在从服务执行单元SN3接收到L-SPC请求消息时,验证服务器A3根据该消息内容检测到用户主机终端H1’(H1)容纳在验证服务器A1中,并将接收到的L-SPC请求消息发送到位于域D1中的验证服务器A1(图13中带箭头的虚线(3))。
然后,验证服务器A1接收L-SPC请求消息,从数据库中提取与用户主机终端H1相关的L-SPC(A),并且利用L-SPC响应消息,将提取的L-SPC(A)发送回始发该请求的服务执行单元SN3。通过验证服务器A3,将L-SPC响应消息发送到服务执行单元SN3(图13中带箭头的虚线(4))。
服务执行单元SN3在从验证服务器A3接收到的L-SPC响应消息中提取与用户主机终端H1相关的L-SPC,并将提取的L-SPC存储到属于服务执行单元SN3的SPC管理表中。此外,根据所获取的L-SPC的描述内容,服务执行单元SN3对服务执行功能进行初始化(图14中的S86)。
在由服务执行单元SN3中的L-SPC(A)集触发后,服务执行单元SN3将SIP邀请消息传送到目标用户主机终端H3。
然后,服务执行单元SN3等待用户主机终端H3发出响应(电话终端的摘机操作)。在此期间,服务执行单元SN3根据L-SPC(A)内容为用户主机终端H1’提供服务(参考带箭头的虚线(5))。例如,通过适当的消息向用户主机终端H1’提供广告等。
通过操作主机终端,用户主机终端H3的用户响应用户主机终端H1’发出的连接请求。作为这个操作的结果,用户主机终端H3发出SIP-Ack(确认)消息,作为对用户主机终端H1’的响应。
通过服务执行单元SN3,将用户主机终端H3发出的SIP-Ack消息转发到用户主机终端H1’。
在用户主机终端H1’从用户主机终端H3接收SIP-Ack消息时,在用户主机终端H1’与用户主机终端H3之间建立对话。此后,在用户主机终端H1’、H3之间双向交换语音数据包。
此外,在图13中,L-SPC(D)是用户主机终端H3的L-SPC。
(4)操作示例4操作示例4表示在服务合同用户的用户主机终端移到归属链路之外进入另一个链路并停留在其中,而且对端方的另一个服务合同用户的用户主机终端以及服务执行单元位于外部链路上时,由应用验证过程触发的执行SPC分配和单独服务控制的执行过程的示例。
图15示出了这种情况下的服务控制网络系统的结构示例的方框图。图16示出了这种情况下的服务控制网络系统的处理流程的顺序图。
在图15中,在用户主机终端H1的服务合同用户移动到归属链路(域D1)之外,而停留在另一个链路(域D4)中的情况下,与位于外部域D2中的对端用户主机终端H2进行通信,而且是服务执行单元SN2执行服务。图15所示的结构与图13所示的结构类似。图15与图13所示结构的不同之处在于,在图15中,被用户主机终端H1呼叫的一方是位于另一个域D2中的用户主机终端H2(呼叫中心)。(在图13中,用户主机终端H1’和被叫用户主机终端H3位于同一个域中。)首先,用户主机终端H1’的用户(服务合同用户)操作该终端的IP电话功能,以指定进行通信的对端方(即,用户主机终端H2)而始发呼叫(图16中的S91)。
在由用户的拨号操作启动之后,用户主机终端H1’生成指定对端用户主机终端H2的服务启动消息(SIP邀请消息),并且,将生成的服务启动消息发送到最近的服务执行单元SN3(SIP服务器) (图15中带箭头的实线(1)和图16中的S91)。用户主机终端H1’事先知道最近SIP服务器的位置,从而将该服务启动消息发送到服务执行单元SN3。
服务执行单元SN3接收到用户主机终端H1’发出的SIP邀请消息。在执行有关服务(生成VoIP对话)时,服务执行单元SN3判定是否需要参考主叫用户主机终端H1’的L-SPC(A)(图16中的S92)。在此,在以下的描述中,假定L-SPC(A)已经保持在服务执行单元SN3中,因此判定不需要进行进一步参考。因此,省略了向验证服务器A1请求L-SPC(A)的参考请求处理。
通过中继单元TS,服务执行单元SN3将SIP邀请消息发送到被叫用户主机终端H2的服务执行单元SN2(图15中带箭头的实线(1))。
在接收到SIP邀请消息时,服务执行单元SN2检测服务的启动,而且还识别用户主机终端H1’是由位于域D2之外的域D1管理的。然后,服务执行单元SN2判定是否要参考用户主机终端H1’的G-SPC(G-SPC(A))(图15中的标号(2),图16中的S93)。在此,在以下的描述中,假定判定需要参考。
根据此判定,服务执行单元SN2生成用于请求G-SPC(A)的G-SPC请求消息,并将生成的请求消息发送到位于服务执行单元SN2的域D2中的验证服务器A2(图15中带箭头的虚线(3),以及图16中的S94)。也可以利用Diameter消息传送这个G-SPC请求消息。
验证服务器A2从G-SPC请求消息的内容中识别出这个消息要传送到验证服务器A1,并相应地传送该消息。
在接收到该G-SPC请求消息时,验证服务器A1搜索并提取G-SPC(A),并利用G-SPC响应消息,通过验证服务器A2,将提取的G-SPC(A)发送到服务执行单元SN2(图15中带箭头的虚线(6),以及图16中的S96)。
验证服务器A2获取G-SPC(A),并存储该G-SPC(A)(图16中的S97)。然后,根据G-SPC(A)的内容,验证服务器A2提供服务(例如,向主叫用户主机终端H1’等发送广告消息)。此外,验证服务器A2将服务启动消息传送到用户主机终端H2,并等待用户主机终端H2的响应。
通过操作终端单元,用户主机终端H2的用户对用户主机终端H1’的连接请求进行应答。在由这个操作启动后,用户主机终端H2发出SIP-Ack(确认)消息以应答用户主机终端H1’。
通过服务执行单元SN2,将用户主机终端H2发出的SIP-Ack消息转发到用户主机终端H1’。
在用户主机终端H1’从用户主机终端H2接收到SIP-Ack消息时,在用户主机终端H1’与用户主机终端H2之间建立对话。此后,在用户主机终端H1’、H3之间双向交换语音数据包。
此外,在图15中,L-SPC(C)是用户主机终端H2的L-SPC。
从上述说明中可以理解,根据本发明的实施例,将规定与用户无关的服务内容的SPC(L-SPC或G-SPC)送到服务执行单元,而不送到边缘单元。因此,对于第3层服务以上的高层服务,可以为各个用户提供单独服务。
总之,根据本发明,可以提供为各个用户和各个应用定制的服务。
以上描述的实施例并不将本发明限制于所述示例的特定细节。任何适当修改和等效物均属于本发明范围之内。所附权利要求涵盖了属于本发明范围的本发明的所有特征和优点。
权利要求
1.一种服务控制网络系统,包括服务执行单元,用于为终端单元提供服务;以及服务器,用于管理服务信息,所述服务信息规定了要提供给所述终端单元的服务,所述服务执行单元进一步包括请求发送部,用于在从所述终端单元接收到服务启动请求或注册请求时,向所述服务器发送与所述服务启动请求或所述注册请求相对应的服务信息的参考请求;以及服务提供部,用于根据由于所述请求发送部发出的参考请求而参考的服务信息,为所述终端单元提供服务,而且所述服务器包括服务信息发送部,用于将对应于所述服务执行单元发出的参考请求的服务信息发送到所述服务执行单元。
2.根据权利要求1所述的服务控制网络系统,其中,所述服务控制网络系统至少划分为一个容纳所述服务器和终端单元的第一域和一个第二域,所述的服务信息包括第一服务信息,在服务执行单元容纳在第一域中的情况下,或者在服务执行单元容纳在第二域中而且终端单元移动到第二域的情况下参考该第一服务信息;以及第二服务信息,在服务执行单元容纳在第二域中而且终端单元或者容纳在第一域中或者移动到不是第一域或第二域的域中的情况下,参考该第二服务信息,以及所述服务执行单元中的请求发送部在所述服务执行单元容纳在第一域中时,或者在所述服务执行单元容纳在第二域中而且终端单元移动到第二域中时,发出第一服务信息的参考请求;或者在所述服务执行单元容纳在第二域中而且终端单元或者容纳在第一域中或者移动到不是第一域或第二域的域中时,发出第二服务信息的参考请求。
3.根据权利要求2所述的服务控制网络系统,其中,在第二域中,容纳有与所述服务器具有互信关系的第二服务器,而且在服务执行单元容纳在第二域中时,请求发送部将参考请求发送到第二服务器,而第二服务器将该参考请求传送到所述服务器。
4.根据权利要求1至3中任何一项所述的服务控制网络系统,其中,在所述服务执行单元已经保持了有效服务信息时,请求发送部不发送参考请求。
5.一种包括第一域、容纳在所述第一域中的第一服务器、第一服务执行单元以及终端单元的服务控制网络系统,所述第一服务器包括存储部,用于存储第一服务信息,所述的第一服务信息规定了要提供给终端单元的服务;以及服务信息发送部,用于在从第一服务执行单元接收到第一服务信息参考请求时,根据该参考请求,将存储在存储部中的第一服务信息发送给第一服务执行单元,所述第一服务执行单元包括第一请求发送部,用于在从终端单元接收到服务启动请求或注册请求时,将对应于所述服务启动请求或所述注册请求的第一服务信息的参考请求发送到第一服务器;以及第一服务提供部,用于根据由于第一请求发送部发出的请求而参考的第一服务信息,为终端单元提供服务。
6.根据权利要求5所述的服务控制网络系统,其中,在所述第一服务执行单元已经保持了有效的第一服务信息时,第一请求发送部不发送参考请求。
7.根据权利要求5或6所述的服务控制网络系统,进一步包括第二域,以及分别容纳在所述第二域中的第二服务器和第二服务执行单元,其中,存储部还存储第二服务信息,所述的第二服务信息规定了要提供给终端单元的服务,而且,在从第二服务器接收到第二服务信息的参考请求时,根据所述的参考请求,服务信息发送部将存储在存储部中的第二服务信息发送到第二服务器,第二服务执行单元包括第二请求发送部,用于在从终端单元接收到服务启动请求时,将对应于所述服务启动请求的第二服务信息的参考请求发送到第二服务器;以及第二服务提供部,用于根据由于第二请求发送部发出的请求而参考的第二服务信息,为终端单元提供服务,而第二服务器包括传送部,用于将第二请求发送部发出的参考请求传送到第一服务器,而且还将第一服务器发出的第二服务信息传送到第二服务执行单元。
8.根据权利要求7所述的服务控制网络系统,其中,在所述第二服务执行单元已经保持了有效的第二服务信息时,第二请求发送部不发送参考请求。
9.一种服务控制网络系统,包括容纳有第一服务器和终端单元的第一域,以及容纳有第二服务器和第二服务执行单元的第二域,所述终端单元移动到第二域中,所述第一服务器包括存储部,用于存储第一服务信息,所述的第一服务信息规定了要提供给终端单元的服务;以及服务信息发送部,用于在从第二服务器接收到第一服务信息参考请求时,根据所述的参考请求,将存储在存储部中的第一服务信息发送到第二服务器,所述第二服务执行单元包括第二请求发送部,用于在从终端单元接收到服务启动请求或注册请求时,将对应于所述服务启动请求或所述注册请求的第一服务信息的参考请求发送到第二服务器;以及第二服务提供部,用于根据由于第二请求发送部发出的请求而参考的第一服务信息,为终端单元提供服务,而所述第二服务器包括传送部,用于将第二请求发送部发出的参考请求传送到第一服务器,而且将第一服务器发出的第一服务信息传送到第二服务执行单元。
10.根据权利要求9所述的服务控制网络系统,其中,在所述第二服务执行单元已经保持了有效的第一服务信息时,第二请求发送部不发送参考请求。
11.根据权利要求9或10所述的服务控制网络系统,进一步包括第三域,以及容纳在所述第三域中的第三服务器和第三服务执行单元,其中,存储部还存储第三服务信息,所述的第三服务信息规定了要提供给终端单元的服务,而且,在从第三服务器接收到第三服务信息参考请求时,服务信息发送部将存储在存储部中的第三服务信息发送到第三服务器,第三服务执行单元包括第三请求发送部,用于在从终端单元接收到服务启动请求时,将对应于所述服务启动请求的第三服务信息的参考请求发送到第三服务器;以及第三服务提供部,用于根据由于第三请求发送部发出的请求而参考的第三服务信息,为终端单元提供服务,而第三服务器包括传送部,用于将第三请求发送部发出的参考请求传送到第一服务器,并将第一服务器发出的第三服务信息传送到第三服务执行单元。
12.根据权利要求11所述的服务控制网络系统,其中,在所述第三服务执行单元已经保持了有效的第三服务信息时,第三请求发送部不发送参考请求。
13.一种容纳在通信网络中形成的第一域中的服务器,该服务器包括存储部,用于存储第一服务信息,所述的第一服务信息规定了要提供给容纳在第一域中的终端单元的服务;接收部,用于接收从容纳在第一域中、用于为终端单元提供服务的第一服务执行单元发出的第一服务信息参考请求;以及发送部,用于根据接收部接收到的参考请求,将存储在存储部中的第一服务信息发送到第一服务执行单元。
14.根据权利要求13所述的服务器,其中,存储部还存储第三服务信息,该第三服务信息规定了要提供给终端单元的服务,接收部还接收由容纳在通信网络中形成的第三域中的第三服务执行单元发出、并由容纳在第三域中的第三服务器传送的第三服务信息参考请求,并且,根据接收部接收到的第三服务信息参考请求,发送部还通过第三服务器将存储在存储部中的第三服务信息发送到第三服务执行单元。
15.一种容纳在通信网络中形成的第一域中的服务器,该服务器包括存储部,用于存储第一服务信息,该第一服务信息规定了要为容纳在第一域中并移动到在该通信网络中形成的第二域的终端单元提供的服务;接收部,用于接收从容纳在第二域中、用于为终端单元提供服务的第二服务执行单元发出并由容纳在第二域中的第二服务器传送的第一服务信息参考请求;以及发送部,用于根据接收部接收到的参考请求,通过第二服务器,将存储在存储部中的第一服务信息发送到第二服务执行单元。
16.根据权利要求15所述的服务器,其中,存储部还存储第二服务信息,该第二服务信息规定了要提供给终端单元的服务,接收部还接收由容纳在该通信网络中形成的第二域中的第二服务执行单元发出、并由容纳在所述第二域中的第二服务器传送的第二服务信息参考请求,并且,根据接收部接收到的第二服务信息参考请求,发送部进一步将存储在存储部中的第二服务信息发送到第二服务执行单元。
17.一种包含在通信网络中、用于为接入所述通信网络的终端单元提供服务的服务执行单元,所述服务执行单元包括存储部,用于存储规定服务的服务信息;发送部,用于在从终端单元接收到服务启动请求或注册请求时,向设置在该通信网络中、用于管理服务信息的服务器发送参考请求,请求规定与所述服务启动请求或所述注册请求相对应的服务的服务信息;接收部,用于根据发送部发出的参考请求,接收服务器发出的服务信息,并将接收到的服务信息存储到存储部中;以及服务提供部,用于根据存储在存储部中的服务信息,为终端单元提供服务。
18.根据权利要求17所述的服务执行单元,其中,在存储部已经保持了有效的服务信息时,发送部不发送参考请求。
全文摘要
为了提供针对各个用户和各个应用定制的服务,在用户主机终端H1利用VoIP与用户主机终端H2通信时,终端H1向服务执行单元SN1和SN2发送服务启动消息。通过该消息,服务执行单元SN1和SN2分别向验证服务器A1请求与终端H1的VoIP服务相关的服务信息L-SPC(A)和服务信息G-SPC(A)。服务执行单元SN1和SN2分别根据L-SPC(A)和G-SPC(A)执行服务。这样,服务执行单元可以提供针对各个用户和各个应用定制的服务。
文档编号H04L29/08GK1503537SQ20031011369
公开日2004年6月9日 申请日期2003年11月19日 优先权日2002年11月19日
发明者五十岚洋一郎, 明, 高瀬正明, 掛水光明 申请人:富士通株式会社
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1