CN101217480B - 一种ip多媒体子系统中多终端用户的第三方注册的方法 - Google Patents

Abstract

本发明公开了一种IP多媒体子系统中多终端用户的第三方注册方法，包括以下步骤：(1)当终端向S-CSCF发起注册时，S-CSCF查询与该终端对应的PUI是否已经在应用服务器上进行了第三方注册；如果是，则S-CSCF不再发起第三方注册请求；如果该PUI尚未注册或者重新进行注册，则S-CSCF向应用服务器发起第三方注册请求，执行下一步；(2)应用服务器接到第三方注册请求后，完成鉴权、认证，并向S-CSCF反馈注册成功响应；(3)S-CSCF在本地保存该PUI的注册信息。本发明减少重复的多次消息雷同的第三方注册、应用服务器状态订阅对网络资源的无效的占用，以提高效率，降低运营成本，提高网络用户容量。

Description

一种IP多媒体子系统中多终端用户的第三方注册的方法

技术领域

本发明涉及通讯领域，尤其涉及一种IP多媒体子系统中多终端用户的第三方注册的方法。

背景技术

IMS(IP Multimedia Subsystem，IP多媒体子系统)是第三代合作伙伴组织(3rd Generation Partnership Proiect，简称3GPP)定义的下一代网络的标准，它的显著特点是采用了会话发起协议(Session Initiation Protocol，简称SIP)体系，通讯与接入无关，可以具备多种媒体业务控制功能与承载能力分离，呼叫与会话分离，应用与服务分离，业务与网络分离，以及移动网与英特网业务融合等多种能力，IMS的提出顺应了通讯网融合发展的趋势。

在IMS中，一个用户可以拥有多个不同的终端，称之为多终端用户，这些多终端用户拥有相同的公共用户标识(Public User Identity，简称PUI)以及不同的私有用户标识(Private User Identity，简称PVI)，一个PUI可以关联多个PVI，当然一个PVI也可以关联多个PUI。目前IMS系统对多终端用户的支持也在日益加强，允许这些终端同时在线，同时进行不同对话。由于多终端用户拥有的多个终端的能力差异很大，不同终端对IMS核心要求也不同，应此要求IMS系统对不同终端提供差异化服务将成为一种趋势。

图1为一个PUI拥有三个终端UE1、UE2、UE3的网络结构图，图中的架构包括了应用服务器(Application Server，简称AS)-101、S-CSCF(ServingCall Session Control Function，服务呼叫会话控制功能)-102，P-CSCF(ProxyCall Session Control Function，代理呼叫会话控制功能)-103、用户终端1(User Equipment No.1，简称UE1)-104、用户终端2(User Equipment No.2，简称UE2)-105、用户终端3(User Equipment No.3，简称UE3)-106。图中的UE1、UE2、UE3拥有为同一个用户的三个不同终端，分别为不同的设备，拥有很大差异的终端能力，它们在IMS系统中成功注册后，绑定了不同的联系地址，分别为：UE1@home.com，UE2@home.com，UE3@home.com。

用户在使用IMS业务之前，必须成功执行注册过程，而用户在使用特定的应用之前，也必须到制定的应用服务器进行第三方注册，而在完成第三方注册之后，应用服务器对该用户进行状态订阅，如果一个PUI对应的多个终端依次进行了注册，则将在应用服务器上进行多次第三方注册、应用服务器也将进行多次状态订阅。

图2是目前IMS系统拥有多终端用户的多个终端分别完成注册、状态订阅的流程示意图。图2中的用户有3个不同的终端UE1、UE2以及UE3，这三个终端使用相同的PUI。UE1、UE2、UE3都在同一个IMS系统中注册、并完成第三方注册，应用服务器状态订阅的流程包括以下步骤。

S201，用户终端UE1在S-CSCF上成功注册，绑定联系地址UE1@home.com，并完成用户状态订阅，这部分流程在本发明中不需要特别关注，不进行展开描述；

S202，S-CSCF在成功处理完成UE1的注册请求后，向应用服务器发起第三方注册请求，本次第三方注册请求我们命名为“第三方注册1”；

S203，应用服务器接到“第三方注册1”，完成鉴权、认证后，向S-CSCF发送第三方注册1的注册成功响应；

S204，应用服务器发起对UE1所对应的PUI的状态订阅请求，本次应用服务器发起的状态订阅请求命名为“应用服务器状态订阅1”，简称“订阅1”；

S205，S-CSCF接收应用服务器的订阅，发送订阅成功响应，此时UE1完成了注册、并且应用服务器也完成了对UE1所对应的PUI的状态订阅；

S206，与用户终端UE1共享同一个PUI的另外一个终端UE2，也在S-CSCF上成功注册，绑定联系地址UE2@home.com，并完成用户状态订阅；

S207，S-CSCF在成功处理完成UE2的注册请求后，向应用服务器发起第三方注册请求，本次第三方注册请求我们命名为“第三方注册2”；在这里“第三方注册2”报文内容与“第三方注册1”报文内容大抵相仿，主要区别表现在联系地址不同：“第三方注册1”的联系地址为UE1@home.com，而“第三方注册2”的联系地址为UE2@home.com，以及可能注册过期时间的差异；

S208，应用服务器接到“第三方注册2”，完成鉴权、认证后，向S-CSCF发送第三方注册成功响应；

S209，应用服务器发起对UE2所对应的PUI的状态订阅请求，本次应用服务器发起的状态订阅请求命名为“应用服务器状态订阅2”，简称“订阅2”，由于状态订阅是针对PUI的，所以“订阅1”与“订阅2”是应用服务器对同一PUI的两次重复的订阅，“订阅1”与“订阅2”报文内容几乎完全相同；

S210，S-CSCF接收应用服务器的“订阅2”，发送订阅成功响应，此时UE2完成了注册、并且应用服务器也完成了对UE2所对应的PUI的状态订阅；

S211，用户终端UE3也与用户终端UE1、UE2共享同一个PUI，也在S-CSCF上成功注册，绑定联系地址UE3@home.com，并完成用户状态订阅；；

S212，S-CSCF在成功处理完成UE3的注册请求后，向应用服务器发起第三方注册请求，本次第三方注册请求我们命名为“第三方注册3”；在这里“第三方注册3”报文内容也与“第三方注册1”、“第三方注册2”报文内容大抵相仿，主要不同为联系地址不同，以及可能注册过期时间的差异；

S213，应用服务器接到“第三方注册3”，完成鉴权、认证后，向S-CSCF发送第三方注册成功响应；

S214，应用服务器发起对UE3所对应的PUI的状态订阅请求，本次应用服务器发起的状态订阅请求命名为“应用服务器状态订阅3”，简称“订阅3”，订阅1”、“订阅2”与“订阅2”是应用服务器对同一PUI的重复的订阅，报文内容也几乎完全相同；

S215，S-CSCF接收应用服务器的“订阅3”，发送订阅成功响应，此时UE3完成了注册、并且应用服务器也完成了对UE3所对应的PUI的状态订阅；

在图2所示的客户端订阅过程中，我们可以看出：  拥有同一个PUI的三个不同的终端UE1、UE2、UE3分别在同一个IMS核心网中注册的过程中，S-CSCF为这三个终端进行了三次流程完全相同，报文也几乎一致的第三方注册流程，同时应用服务器对终端对应PUI的相同的状态订阅也进行了三次。

图3是现有技术中三个终端在状态发生变化，以及需要进行订阅刷新时的流程示意图，基本流程如下：

S301，当三个终端中某个终端发生状态变化，或者由终端主动发起了重注册时；

S302-S303，S-CSCF获知有终端发生状态变化，如果终端状态变化为IMS核心网中网元检测到终端发生变化，则S302为某个网元通知S-CSCF，这个不属于本发明关注的内容，这里不进行详细描述，而如果终端主动发起重注册请求时，S302则是一个注册过程；

S304，因为图2中的应用服务器在S-CSCF上成功订阅了“订阅1”，S-CSCF向应用服务器发送状态通知(NOTIFY消息)请求；

S305，应用服务器收到“订阅1”的状态通知后，向S-CSCF发送状态通知响应；

S306，图2中的应用服务器在S-CSCF上成功订阅了“订阅2”，S-CSCF向应用服务器发送状态通知(NOTIFY消息)请求，“订阅2”的状态通知请求与“订阅1”的状态通知请求都是反映同一个PUI的同一个终端发生了状态变更或者重注册，因此内容完全雷同；

S307，应用服务器收到“订阅2”的状态通知后，向S-CSCF发送状态通知响应；

S308，图2中的应用服务器在S-CSCF上成功订阅了“订阅3”，S-CSCF向应用服务器发送状态通知(NOTIFY消息)请求，“订阅3”的状态通知请求也与“订阅1”、“订阅2”的状态通知请求完全一致；

S309，应用服务器收到“订阅3”的状态通知后，向S-CSCF发送状态通知相应；

由此可见，在先行技术中，多终端用户只要有个终端发生状态变化或者重注册，S-CSCF都会发送等于终端订阅总数的通知消息给应用服务器；而多终端用户的每个终端都有可能发生状态变化，都会进行定期重注册，应此对于拥有多个终端的用户而言，状态变化或者重注册将是相当频繁的，而每次状态变化或者重注册，S-CSCF都需要向应用服务器发送多个内容雷同的状态通知消息。

图4是现有技术中三个终端进行重订阅的流程，三个状态订阅(“订阅1”、“订阅2”、“订阅3”)的超时可能并不相同，因此三个状态订阅的重订阅也有可能并不同步，这里为了表述更清晰，只画出每个状态订阅的一次重订阅，其基本流程如下：

S401，应用服务器需要实时监控所有订阅是否超时，此时应用服务器发现“订阅1”需要重订阅；

S402，应用服务器向S-CSCF发起“订阅1”的重订阅请求；

S403，S-CSCF返回“订阅1”的重订阅请求的回应；

S404，应用服务器发现“订阅2”需要重订阅；

S405，应用服务器向S-CSCF发起“订阅2”的重订阅请求，“订阅2”请求与“订阅1”请求内容相仿，应此这里的“订阅2”的重订阅请求也与“订阅1”的重订阅请求内容相仿；

S406，S-CSCF返回“订阅2”的重订阅请求的回应；

S407，应用服务器发现“订阅3”需要重订阅；

S408，应用服务器向S-CSCF发起“订阅3”的重订阅请求，“订阅3”的重订阅请求与“订阅1”的重订阅、“订阅2”的重订阅请求内容相仿；

S409，S-CSCF返回“订阅3”的重订阅请求的回应；

由此我们可以看到图2至图4中同一PUI对应的三个UE在注册过程中，S-CSCF与应用服务器都进行了完全相同的操作：第三方注册、应用服务器用户状态订阅，消息雷同，占用了大量网络资源；由于对同一UE重复订阅，所以每次UE发生状态变化，S-CSCF将产生数个相同的通知消息发给应用服务器；并且应用服务器端发起的订阅刷新请求也需要发送多次。如果一个PUI对应的终端数量更大，这些终端同时在线，每个终端都将在规定的时间内进行在IMS网络的重注册，以及其它情况的状态变更，对于PUI而言，变化将非常频繁，而每次变化将产生多个消息通知，并且由于通知消息体较大，浪费大量的网络资源。如果能够减少对这些资源无效的占用，是非常值得研究的。

发明内容

本发明要解决的技术问题是提供一种IP多媒体子系统中多终端用户的第三方注册方法，减少了重复的多次消息雷同的第三方注册、应用服务器状态订阅对网络资源的无效的占用。

为了解决上述问题，本发明提供了一种IP多媒体子系统中多终端用户的第三方注册方法，包括以下步骤：

(1)当终端向服务呼叫会话控制功能模块S-CSCF发起注册时，S-CSCF查询与该终端对应的PUI是否已经在应用服务器上进行了第三方注册；如果是，则S-CSCF不再发起第三方注册请求；如果该PUI尚未注册或者重新进行注册，则S-CSCF向应用服务器发起第三方注册请求，执行下一步；

(2)应用服务器接到第三方注册请求后，完成鉴权、认证，并向S-CSCF反馈注册成功响应；

(3)S-CSCF在本地保存该PUI的注册信息。

进一步的，本发明所述的方法，其中，步骤(1)中，还包括：

当所述用户终端发起注册时，经查询该PUI已经在应用服务器上进行了第三方注册，则S-CSCF不再发起第三方注册请求，之后应用服务器检测该PUI是否进行了状态订阅。

进一步的，本发明所述的方法，其中，步骤(1)中，应用服务器实时监控所有订阅，如果订阅发生超时，则应用服务器向S-CSCF重新发起订阅请求。

进一步的，本发明所述的方法，其中，在步骤(1)中，当所述用户终端发起注册时，经查询该PUI已经在应用服务器上进行了第三方注册，则S-CSCF不再向应用服务器发起第三方注册请求，当检测到尚未进行PUI状态订阅或者重新发起状态订阅请求时，则还执行以下步骤：

(I)应用服务器向S-CSCF发起对该PUI的状态订阅请求；

(II)S-CSCF接收应用服务器的订阅请求，发送订阅成功响应，应用服务器完成对该PUI的状态订阅。

进一步的，本发明所述的方法，其中，在步骤(1)中，当所述用户终端发起注册时，经查询该PUI已经在应用服务器上进行了第三方注册，则S-CSCF不再向应用服务器发起第三方注册请求，且检测到该用户终端已经完成了PUI状态订阅，则执行以下步骤：

(i)S-CSCF向应用服务器发送状态通知消息，通知应用服务器该PUI已经在S-CSCF上注册成功且已经进行了PUI状态订阅；

(ii)应用服务器收到状态通知请求后，向S-CSCF发送状态通知响应。

与现有技术相比，本发明减少了重复的多次消息雷同的第三方注册、应用服务器状态订阅对网络资源的无效的占用，以提高效率，降低运营成本，提高网络用户容量。

附图说明

图1是现有技术中多终端用户在IMS系统中的网络架构示意图；

图2是现有技术中多终端用户在IMS系统中注册、订阅流程的示意图；

图3是现有技术中多终端用户在IMS系统中终端状态变化通知流程示意图；

图4是现有技术中多终端用户在IMS系统中应用服务器状态订阅刷新流程示意图；

图5是本发明的应用实例中多终端用户在IMS系统中注册、订阅的示意图；

图6是本发明的应用实例中多终端用户在IMS系统中终端状态变化通知流程示意图；

图7是本发明的应用实例中多终端用户在IMS系统中应用服务器状态订阅刷新流程示意图。

具体实施方式

本发明核心思想是：S-CSCF在完成用户终端的注册请求之后，不再直接向相关的应用服务器发起第三方注册；先查询该终端对应的PUI是否已经在应用服务器上存在当前有效的注册；如果不存在，则发起第三方注册请求，请求完成后，在本地记录该PUI的注册标识；如果存在，将不再不发起第三方注册请求。

另外，状态订阅也要对PUI进行查询，如果该PUI已经存在状态订阅，则不必再发起状态订阅请求。

因此，对应同一PUI的终端，不会发起重复的第三方注册请求和状态订阅请求，减少了对网络资源的无效的占用。

本发明为了解决传统技术方案存在的弊端，通过以下具体实施例进一步阐述本发明所述的一种IP多媒体子系统中多终端用户的第三方注册的方法，以下对具体实施方式进行详细描述，但不作为对本发明的限定。

图5是本发明的应用实例中多终端用户在IMS系统中注册、订阅的示意图。

S501，用户终端UE1在S-CSCF上成功注册，绑定联系地址UE1@home.com，并完成用户状态订阅；

S502，S-CSCF判断UE1对应PUI是否在相应的应用服务器上有有效的第三方注册，本次S-CSCF发现UE1对应的PUI目前在应用服务器上没有有效的第三方注册；

S503，因此S-CSCF在成功处理完成UE1的注册请求后，向应用服务器发起第三方注册请求；

S504，应用服务器接到第三方注册请求，完成鉴权、认证后，向S-CSCF发送第三方注册的注册成功响应；(此时该PUI已经在应用服务器上进行了第三方注册，但尚未进行PUI状态订阅)

S505，应用服务器发起对UE1所对应的PUI的状态订阅请求；

S506，S-CSCF接收应用服务器的订阅，发送订阅成功响应；

S507，S-CSCF将对该PUI进行的第三方注册请求的信息保存到本地，此时UE1完成了注册、并且应用服务器也完成了对UE1所对应的PUI的状态订阅；

S508，与用户终端UE1共享同一个PUI的另外一个终端UE2，也在S-CSCF上成功注册，绑定联系地址UE2@home.com，并完成用户状态订阅；

S509，S-CSCF判断UE2对应PUI是否在相应的应用服务器上有有效的第三方注册，本次S-CSCF发现UE2对应的PUI目前在应用服务器上已经有有效的第三方注册，因此不再进行第三方注册；

S510，S-CSCF发现该应用服务器已经对UE2对应的PUI进行了状态订阅，应此S-CSCF向应用服务器发送状态通知消息，通知应用服务器UE2已经在S-CSCF上注册成功；

S511，应用服务对状态通知消息进行确认；

S512，用户终端UE3也与用户终端UE1、UE2共享同一个PUI，也在S-CSCF上成功注册，绑定联系地址UE3@home.com，并完成用户状态订阅；

S513，S-CSCF判断UE2对应PUI是否在相应的应用服务器上有有效的第三方注册，本次S-CSCF发现UE2对应的PUI目前在应用服务器上已经有有效的第三方注册，因此不再进行第三方注册；

S514，S-CSCF发现该应用服务器已经对UE2对应的PUI进行了状态订阅，应此S-CSCF向应用服务器发送状态通知消息，通知应用服务器UE2已经在S-CSCF上注册成功；

S515，应用服务对状态通知消息进行确认；

本例中省略了后两次注册的第三方注册流程，而采用状态通知消息替代，由于第三方注册需要应用服务器与HSS进行交互，涉及的网元多而流程复杂，因此能够大大简化后两次的注册流程；同时也省略了后两次注册中应用服务器发起的用户状态订阅，而因为现有技术中的三次状态订阅内容大抵相同，而这些内容在进行第一次状态订阅时候，订阅的双方应用服务器与S-CSCF均已知晓，应此这样的省略也不会对现有应用带来影响。

图6是本发明的应用实例中多终端用户在IMS系统中终端状态变化通知流程示意图，此时该PUI已经在应用服务器上进行了第三方注册，但是发起了重新进行注册，则包括以下步骤：

S601，当三个终端中某个终端发生状态变化，或者由终端主动发起了重注册时；

S602-S603，S-CSCF获知有终端发生状态变化，如果终端状态变化为IMS核心网中网元检测到终端发生变化，则S602为某个网元通知S-CSCF，这个不属于本发明关注的内容，这里不进行详细描述，而如果终端主动发起重注册请求时，S602则是一个注册过程(与S502-S507相似)；

S604，S-CSCF向应用服务器发送状态通知(NOTIFY消息)请求；

S605，应用服务器收到状态通知请求后，向S-CSCF发送状态通知响应。

本例中可以看出，使用本发明提供的方法，当某个终端发生状态变化或者重注册的时候，S-CSCF只需要向应用服务器发送一个状态通知消息，而现有技术中需要发的三个状态通知消息完全雷同，因此这样的改动也不会对现有应用带了影响。

图7是本发明的应用实例中多终端用户在IMS系统中应用服务器状态订阅刷新流程示意图，此时PUI已经在应用服务器上进行了第三方注册，包括以下步骤：

S701，应用服务器需要实时监控所有订阅是否超时，此时应用服务器发现需要重订阅；

S702，应用服务器向S-CSCF发起的重订阅请求；

S703，S-CSCF返回的重订阅请求的回应。

从图7所示的例子可以看出，应用服务器只需要对一个PUI维护一个状态订阅，而且一个状态订阅在一个超时周期内也只需要进行一次重订阅，节约了对应用服务器CPU的占用，减少了应用服务器本地数据的规模，减轻了网络负担。

综上所述，本发明同时对同一个PUI只进行了一次第三方注册、一次订阅；而后面UE的每次状态变化，只发一个通知消息给应用服务器；并且应用服务器多个终端用户只需要维护一个状态订阅，订阅刷新也只需要进行一次；对同一个PUI，S-CSCF只进行一次第三方注册，节省了大量的网络资源。

当然，本发明还可有其他多种实施例，在不背离本发明精神及其实质的情况下，熟悉本领域的技术人员可根据本发明做出各种相应的改变和变形，但这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。

Claims (5)

1.一种IP多媒体子系统中多终端用户的第三方注册的方法，其特征在于，包括以下步骤：

(1)当终端向服务呼叫会话控制功能模块发起注册时，服务呼叫会话控制功能模块查询与该终端对应的公共用户标识是否已经在应用服务器上进行了第三方注册；如果是，则服务呼叫会话控制功能模块不再发起第三方注册请求；如果该公共用户标识尚未注册或者重新进行注册，则服务呼叫会话控制功能模块向应用服务器发起第三方注册请求，执行下一步；

(2)应用服务器接到第三方注册请求后，完成鉴权、认证，并向服务呼叫会话控制功能模块反馈注册成功响应；

(3)服务呼叫会话控制功能模块在本地保存该公共用户标识的注册信息。

2.如权利要求1所述的方法，其特征在于，步骤(1)中，还包括：

当所述用户终端发起注册时，经查询该公共用户标识已经在应用服务器上进行了第三方注册，则服务呼叫会话控制功能模块不再发起第三方注册请求，之后应用服务器检测该公共用户标识是否进行了状态订阅。

3.如权利要求2所述的方法，其特征在于，步骤(1)中，应用服务器实时监控所有订阅，如果订阅发生超时，则应用服务器向服务呼叫会话控制功能模块重新发起订阅请求。

4.如权利要求3所述的方法，其特征在于，在步骤(1)中，当所述用户终端发起注册时，经查询该公共用户标识已经在应用服务器上进行了第三方注册，则服务呼叫会话控制功能模块不再向应用服务器发起第三方注册请求，当检测到尚未进行公共用户标识状态订阅或者重新发起状态订阅请求时，则还执行以下步骤：

(I)应用服务器向服务呼叫会话控制功能模块发起对该公共用户标识的状态订阅请求；

(II)服务呼叫会话控制功能模块接收应用服务器的订阅请求，发送订阅成功响应，应用服务器完成对该公共用户标识的状态订阅。

5.如权利要求2所述的方法，其特征在于，在步骤(1)中，当所述用户终端发起注册时，经查询该公共用户标识已经在应用服务器上进行了第三方注册，则服务呼叫会话控制功能模块不再向应用服务器发起第三方注册请求，且检测到该用户终端已经完成了公共用户标识状态订阅，则执行以下步骤：

(i)服务呼叫会话控制功能模块向应用服务器发送状态通知消息，通知应用服务器该公共用户标识已经在服务呼叫会话控制功能模块上注册成功且已经进行了公共用户标识状态订阅；

(ii)应用服务器收到所述状态通知消息后，向服务呼叫会话控制功能模块发送状态通知响应。

Images