一种IMS网络可靠性实现方法转让专利
申请号 : CN200510085400.8
文献号 : CN1905472B
文献日 : 2010-05-05
发明人 : 文楷 , 顾炯炯
申请人 : 华为技术有限公司
摘要 :
本发明公开了一种IMS网络可靠性实现方法，以解决现有IMS中在用户注册成功到用户发起重注册期间，因网络实体失效而可能导致用户服务长时间中断的问题；该方法由IMS网络中的第一网络实体获知保存有用户注册相关数据的第二网络实体是否失效；以及在所述第一网络实体获知所述第二网络实体失效时，通知与失效的第二网络实体相关的注册用户重新注册。本发明还同时公开了一种获知IMS网络中网络实体状态变化的方法。
权利要求 :
1.一种IMS网络可靠性实现方法，其特征在于，包括如下步骤：
由IMS网络中的第一网络实体检测保存有用户注册相关数据的第二网络实体是否失效，该第一网络实体为业务呼叫会话控制功能S-CSCF实体；以及在所述第一网络实体获知所述第二网络实体失效时，通知与失效的第二网络实体相关的已注册用户重新注册。
2.如权利要求1所述的方法，其特征在于，所述第一网络实体通过向IMS网络中检测网络设备状态的心跳服务器订阅第二网络实体的状态来获知该第二网络实体是否失效。
3.如权利要求1所述的方法，其特征在于，用户终端向第一网络实体订阅第二网络实体的状态，所述第一网络实体在获知第二网络实体失效时，依据维护的订阅关系通知用户终端重新注册。
4.如权利要求3所述的方法，其特征在于，所述订阅关系包括隐含的订阅关系。
5.如权利要求1所述的方法，其特征在于，第一网络实体利用用户终端注册成功后已订阅的注册状态事件包通知用户终端重新注册。
6.如权利要求3或权利要求5所述的方法，其特征在于，终端设备收到所述通知消息后进一步匹配自身维护的订阅状态，以确定该通知消息是否可信任，并在确定通知消息可信任后发起重新注册。
7.如权利要求4或权利要求5所述的方法，其特征在于，在用户注册过程中，将该用户标识以及保存有该用户注册相关数据的网络实体标识关联并保存在指定网络实体上，所述第一网络实体从该指定的网络实体获取与失效的第二网络实体相关的注册用户，针对这些用户下发通知，要求其重新注册。
8.如权利要求1所述的方法，其特征在于，所述第二网络实体包括代理-呼叫会话控制功能P-CSCF实体；在用户注册过程中，将P-CSCF实体的标识和相关的用户标识关联保存在所述第一网络实体上；该第一网络实体确定P-CSCF实体失效时通知相关用户重新注册。
9.如权利要求8所述的方法，其特征在于，所述第一网络实体发出的通知消息经另一P-CSCF实体传送到用户终端，该另一P-CSCF实体的标识在用户注册过程中携带给第一网络实体，由第一网络实体保存。
10.如权利要求1所述的方法，其特征在于，所述第二网络实体包括S-CSCF实体，该第二网络实体失效时由第一网络实体通过用户注册时为用户提供服务的P-CSCF实体通知用户重新注册。
11.如权利要求10所述的方法，其特征在于，在用户注册过程中，所述用户标识、为用户提供服务的P-CSCF实体的标识信息和所述第二网络实体的标识关联并保存在归属用户服务器HSS上，所述第一网络实体根据所述第二网络实体的标识信息从HSS上获知所述相关用户和为用户提供服务的P-CSCF实体。
12.如权利要求1所述的方法，其特征在于，所述第二网络实体包括HSS，所述第一网络实体获知HSS失效后通过用户注册时为用户提供服务的P-CSCF实体通知注册到所述HSS上的用户重新注册。
13.如权利要求1所述的方法，其特征在于，所述第二网络实体包括应用服务器(AS)，该AS失效时，由第一网络实体通过用户注册时为用户提供服务的P-CSCF实体通知用户重新注册。
14.如权利要求1、2、3、4或5所述的方法，其特征在于，终端设备接收到进行重注册的通知消息时，利用预先获取的P-CSCF实体的地址验证该通知消息的源地址，以确定该通知消息是否可信，并在确定通知消息可信任后向网络发起重新注册。
15.如权利要求1、2、3、4或5所述的方法，其特征在于，终端设备在收到重注册的通知消息后，在响应消息中携带认证挑战，由发送所述通知消息的网络实体根据该认证挑战生成相应的认证响应发送到终端设备，由终端设备对所述认证响应进行验证以确定该通知消息是否可信，并在确定通知消息可信任后向网络发起重新注册。
说明书 :
技术领域
本发明涉及通信领域的IP多媒体子系统(IMS)技术，尤其涉及IMS网络可靠性实现方法。
背景技术
IMS作为固定和移动网络的核心会话控制层，已成为目前业界讨论的重点，在3GPP以及TISPAN标准中定义了很多IMS相关规范，包括网络架构、接口、协议等。IMS采用SIP协议作为呼叫控制信令。在IMS网络中，IMS用户的签约数据集中在归属用户服务器(HSS)管理，业务由应用服务器(AS)提供，会话控制由业务-呼叫会话控制功能(S-CSCF)实体完成，S-CSCF实体与AS在网络结构上分离，业务通过S-CSCF实体触发至AS处理，多个AS间可协同工作。用户通过当前所在地代理节点代理-呼叫会话控制功能(P-CSCF)实体接入IMS，会话和业务控制则由其注册地的归属域服务节点完成，因此用户在不同接入点能得到同样服务。IMS网络实现了业务管理、会话控制及承载接入的三者分离以及与接入和位置无关的业务提供。
通常每个IMS网络设备内部有相应的可靠性机制。例如，网络设备通常有多块处理板组成，处理板间配置为主备用关系，业务由主用工作板提供，当主用工作板故障，相应的备用工作板切换为主用接替故障板的工作，从而保证业务提供的连续性。
除了设备内的可靠性机制外，运营商还关心网络的容灾能力。IMS网络包含以上多种网络实体，相互间关联性强，当某一网络设备故障后，如何使该网络设备的故障对整个IMS网络影响最小，对用户的影响最小，是“IMS组网可靠性”技术领域要解决的问题。
IMS网络基于SIP协议，RFC3263(Locating SIP Servers)结合SIP网络可靠性的相关需求，描述了如何通过域名服务器(DNS)查询定位下一跳SIP服务器。利用该机制，在SIP消息路径中的某一实体失效时，将消息传送给其备份实体。如图1A所示：用户通过DNS解析，可获得网络实体P1和P2的地址，并且知道网络实体P1的优先级别高于网络实体P2。当网络实体P1故障而失效时，用户可向低优先级的备用网络实体P2发送呼叫请求。
将此机制应用到IMS系统，可解决查询-呼叫会话控制功能(I-CSCF)实体失效时的消息转发问题，即当某一I-CSCF实体失效时将消息送往另一个I-CSCF实体。但P-CSCF实体或S-CSCF实体失效时，无法使用此机制，因实体保存用户服务相关的状态，即使消息能够送往另一个P-CSCF实体或S-CSCF实体，由于没有相关状态数据，无法处理收到的消息。
另外，3GPP TS23228描述了用户注册和重注册的过程.利用现有用户注册/重注册流程，实现IMS网络可靠性的方法如图2所示：S-CSCF实体向终端发送的表明注册成功的200响应中携带了要求终端发起重注册的间隔时长，在此间隔时长超时前，终端发起重注册.I-CSCF实体将重注册请求REGISTER路由到用户已注册的S-CSCF实体.当用户已注册的S-CSCF实体故障，I-CSCF实体从HSS获取用户要求的S-CSCF实体能力集，I-CSCF实体依据能力集信息，重新选择一个S-CSCF实体，并将REGISTER请求路由到新选择的S-CSCF实体.该S-CSCF实体认为这是新的用户注册请求，回401响应对用户鉴权，鉴权成功后，回200响应表明注册成功.
因此，在用户注册或重注册过程中，当为该用户服务的S-CSCF实体故障时，通过I-CSCF实体对S-CSCF实体进行重新选择的流程，保证了用户要求的后续服务能够由新的S-CSCF实体继续提供。
3GPP约定，S-CSCF实体向用户终端(UE)返回的注册成功200响应中，终端重注册时长为600000s(相当于一周)，当然S-CSCF实体也可以根据本地策略，决定缩短用户的重注册时长。但如果用户的重注册时长过短，将导致大量重注册消息产生，占用网络资源和无线空口资源。在RFC3261中，缺省重注册时长为7200s。
用户注册成功到用户发起重注册这段时间内，若相应的S-CSCF实体故障，用户将无法得到服务。例如，用户在这段时间内将无法接听入呼叫。为了减少在S-CSCF实体故障情况下用户服务中断的时间而缩短用户的重注册时长，会增加网络负荷和占用过多的网络资源。另外，以上方案仅适用于S-CSCF实体故障情况，并不适用于P-CSCF实体等其他IMS网络实体故障的情况。
通常每个IMS网络设备内部有相应的可靠性机制。例如，网络设备通常有多块处理板组成，处理板间配置为主备用关系，业务由主用工作板提供，当主用工作板故障，相应的备用工作板切换为主用接替故障板的工作，从而保证业务提供的连续性。
除了设备内的可靠性机制外，运营商还关心网络的容灾能力。IMS网络包含以上多种网络实体，相互间关联性强，当某一网络设备故障后，如何使该网络设备的故障对整个IMS网络影响最小，对用户的影响最小，是“IMS组网可靠性”技术领域要解决的问题。
IMS网络基于SIP协议，RFC3263(Locating SIP Servers)结合SIP网络可靠性的相关需求，描述了如何通过域名服务器(DNS)查询定位下一跳SIP服务器。利用该机制，在SIP消息路径中的某一实体失效时，将消息传送给其备份实体。如图1A所示：用户通过DNS解析，可获得网络实体P1和P2的地址，并且知道网络实体P1的优先级别高于网络实体P2。当网络实体P1故障而失效时，用户可向低优先级的备用网络实体P2发送呼叫请求。
将此机制应用到IMS系统，可解决查询-呼叫会话控制功能(I-CSCF)实体失效时的消息转发问题，即当某一I-CSCF实体失效时将消息送往另一个I-CSCF实体。但P-CSCF实体或S-CSCF实体失效时，无法使用此机制，因实体保存用户服务相关的状态，即使消息能够送往另一个P-CSCF实体或S-CSCF实体，由于没有相关状态数据，无法处理收到的消息。
另外，3GPP TS23228描述了用户注册和重注册的过程.利用现有用户注册/重注册流程，实现IMS网络可靠性的方法如图2所示：S-CSCF实体向终端发送的表明注册成功的200响应中携带了要求终端发起重注册的间隔时长，在此间隔时长超时前，终端发起重注册.I-CSCF实体将重注册请求REGISTER路由到用户已注册的S-CSCF实体.当用户已注册的S-CSCF实体故障，I-CSCF实体从HSS获取用户要求的S-CSCF实体能力集，I-CSCF实体依据能力集信息，重新选择一个S-CSCF实体，并将REGISTER请求路由到新选择的S-CSCF实体.该S-CSCF实体认为这是新的用户注册请求，回401响应对用户鉴权，鉴权成功后，回200响应表明注册成功.
因此，在用户注册或重注册过程中，当为该用户服务的S-CSCF实体故障时，通过I-CSCF实体对S-CSCF实体进行重新选择的流程，保证了用户要求的后续服务能够由新的S-CSCF实体继续提供。
3GPP约定，S-CSCF实体向用户终端(UE)返回的注册成功200响应中，终端重注册时长为600000s(相当于一周)，当然S-CSCF实体也可以根据本地策略，决定缩短用户的重注册时长。但如果用户的重注册时长过短，将导致大量重注册消息产生，占用网络资源和无线空口资源。在RFC3261中，缺省重注册时长为7200s。
用户注册成功到用户发起重注册这段时间内，若相应的S-CSCF实体故障，用户将无法得到服务。例如，用户在这段时间内将无法接听入呼叫。为了减少在S-CSCF实体故障情况下用户服务中断的时间而缩短用户的重注册时长，会增加网络负荷和占用过多的网络资源。另外，以上方案仅适用于S-CSCF实体故障情况，并不适用于P-CSCF实体等其他IMS网络实体故障的情况。
发明内容
本发明提供一种IMS网络可靠性的实现方法，以解决现有IMS中在用户注册成功到用户发起重注册期间，因网络实体失效而可能导致用户服务长时间中断的问题。
本发明提供以下技术方案：
一种IMS网络可靠性实现方法，包括步骤：
由IMS网络中的第一网络实体检测保存有用户注册相关数据的第二网络实体是否失效，该第一网络实体为业务呼叫会话控制功能S-CSCF实体；以及
在所述第一网络实体获知所述第二网络实体失效时，通知与失效的第二网络实体相关的已注册用户重新注册。
所述第一网络实体通过向IMS网络中检测网络设备状态的心跳服务器订阅第二网络实体的状态来获知该第二网络实体是否失效。
用户终端向第一网络实体订阅第二网络实体的状态，所述第一网络实体在获知第二网络实体失效时，依据维护的订阅关系通知用户终端重新注册。
所述订阅关系包括隐含的订阅关系。
第一网络实体利用用户终端注册成功后已订阅的注册状态事件包通知用户终端重新注册。
终端设备收到所述通知消息后进一步匹配自身维护的订阅状态，以确定该通知消息是否可信任，并在确定通知消息可信任后发起重新注册。
在用户注册过程中，将该用户标识以及保存有该用户注册相关数据的网络实体标识关联并保存在指定网络实体上，所述第一网络实体从该指定的网络实体获取与失效的第二网络实体相关的注册用户，针对这些用户下发通知，要求其重新注册。
所述第二网络实体包括代理-呼叫会话控制功能P-CSCF实体；在用户注册过程中，将P-CSCF实体的标识和相关的用户标识关联保存在所述第一网络实体上；该第一网络实体确定P-CSCF实体失效时通知相关用户重新注册.所述第一网络实体发出的通知消息经另一P-CSCF实体传送到用户终端，该另一P-CSCF实体的标识在用户注册过程中携带给第一网络实体，由第一网络实体保存.
所述第二网络实体包括S-CSCF实体，该第二网络实体失效时由第一网络实体通过用户注册时为用户提供服务的P-CSCF实体通知用户重新注册。
在用户注册过程中，所述用户标识、为用户提供服务的P-CSCF实体的标识信息和所述第二网络实体的标识关联并保存在归属用户服务器HSS上，所述第一网络实体根据所述第二网络实体的标识信息从HSS上获知所述相关用户和为用户提供服务的P-CSCF实体。
所述第二网络实体包括HSS，所述第一网络实体获知HSS失效后通过用户注册时为用户提供服务的P-CSCF实体通知注册到所述HSS上的用户重新注册。
所述第二网络实体包括应用服务器(AS)，该AS失效时，由第一网络实体通过用户注册时为用户提供服务的P-CSCF实体通知用户重新注册。
终端设备接收到进行重注册的通知消息时，利用预先获取的P-CSCF实体的地址验证该通知消息的源地址，以确定该通知消息是否可信，并在确定通知消息可信任后向网络发起重新注册。
终端设备在收到重注册的通知消息后，在响应消息中携带认证挑战，由发送所述通知消息的网络实体根据该认证挑战生成相应的认证响应发送到终端设备，由终端设备对所述认证响应进行验证以确定该通知消息是否可信，并在确定通知消息可信任后向网络发起重新注册。
本发明在IMS网络中的P-CSCF实体或者S-CSCF实体失效时，能够及时地通过备用的网络实体通知用户进行重注册，因而能够极在地缩短用户服务的中断时间，提高网络的可靠性。
本发明提供以下技术方案：
一种IMS网络可靠性实现方法，包括步骤：
由IMS网络中的第一网络实体检测保存有用户注册相关数据的第二网络实体是否失效，该第一网络实体为业务呼叫会话控制功能S-CSCF实体；以及
在所述第一网络实体获知所述第二网络实体失效时，通知与失效的第二网络实体相关的已注册用户重新注册。
所述第一网络实体通过向IMS网络中检测网络设备状态的心跳服务器订阅第二网络实体的状态来获知该第二网络实体是否失效。
用户终端向第一网络实体订阅第二网络实体的状态，所述第一网络实体在获知第二网络实体失效时，依据维护的订阅关系通知用户终端重新注册。
所述订阅关系包括隐含的订阅关系。
第一网络实体利用用户终端注册成功后已订阅的注册状态事件包通知用户终端重新注册。
终端设备收到所述通知消息后进一步匹配自身维护的订阅状态，以确定该通知消息是否可信任，并在确定通知消息可信任后发起重新注册。
在用户注册过程中，将该用户标识以及保存有该用户注册相关数据的网络实体标识关联并保存在指定网络实体上，所述第一网络实体从该指定的网络实体获取与失效的第二网络实体相关的注册用户，针对这些用户下发通知，要求其重新注册。
所述第二网络实体包括代理-呼叫会话控制功能P-CSCF实体；在用户注册过程中，将P-CSCF实体的标识和相关的用户标识关联保存在所述第一网络实体上；该第一网络实体确定P-CSCF实体失效时通知相关用户重新注册.所述第一网络实体发出的通知消息经另一P-CSCF实体传送到用户终端，该另一P-CSCF实体的标识在用户注册过程中携带给第一网络实体，由第一网络实体保存.
所述第二网络实体包括S-CSCF实体，该第二网络实体失效时由第一网络实体通过用户注册时为用户提供服务的P-CSCF实体通知用户重新注册。
在用户注册过程中，所述用户标识、为用户提供服务的P-CSCF实体的标识信息和所述第二网络实体的标识关联并保存在归属用户服务器HSS上，所述第一网络实体根据所述第二网络实体的标识信息从HSS上获知所述相关用户和为用户提供服务的P-CSCF实体。
所述第二网络实体包括HSS，所述第一网络实体获知HSS失效后通过用户注册时为用户提供服务的P-CSCF实体通知注册到所述HSS上的用户重新注册。
所述第二网络实体包括应用服务器(AS)，该AS失效时，由第一网络实体通过用户注册时为用户提供服务的P-CSCF实体通知用户重新注册。
终端设备接收到进行重注册的通知消息时，利用预先获取的P-CSCF实体的地址验证该通知消息的源地址，以确定该通知消息是否可信，并在确定通知消息可信任后向网络发起重新注册。
终端设备在收到重注册的通知消息后，在响应消息中携带认证挑战，由发送所述通知消息的网络实体根据该认证挑战生成相应的认证响应发送到终端设备，由终端设备对所述认证响应进行验证以确定该通知消息是否可信，并在确定通知消息可信任后向网络发起重新注册。
本发明在IMS网络中的P-CSCF实体或者S-CSCF实体失效时，能够及时地通过备用的网络实体通知用户进行重注册，因而能够极在地缩短用户服务的中断时间，提高网络的可靠性。
附图说明
图1A为现有技术中通过DNS查询定位服务器的示意图；
图1B为现有技术中利用用户注册/重注册实现IMS网络可靠性的流程图；
图2为同一地网络实体同时失效的示意图；
图3A、图3B分别为本发明中S-CSCF实体和P-CSCF实体失效时通知用户终端重注册的流程图；
图4为用户注册时所涉及的网络设备的示意图；
图5为现有技术用户终端订阅注册状态事件及相应事件通知的处理流程图；
图6A、图6B为终端收到重新注册通知进行认证的流程图；
图7A、7B为利用心跳服务器检测网络设备状态的流程图；
图8为向心跳服务器订阅设备状态的流程图。
图1B为现有技术中利用用户注册/重注册实现IMS网络可靠性的流程图；
图2为同一地网络实体同时失效的示意图；
图3A、图3B分别为本发明中S-CSCF实体和P-CSCF实体失效时通知用户终端重注册的流程图；
图4为用户注册时所涉及的网络设备的示意图；
图5为现有技术用户终端订阅注册状态事件及相应事件通知的处理流程图；
图6A、图6B为终端收到重新注册通知进行认证的流程图；
图7A、7B为利用心跳服务器检测网络设备状态的流程图；
图8为向心跳服务器订阅设备状态的流程图。
具体实施方式
为解决现有IMS中在用户注册成功到用户发起重注册期间，由于网络实体失效而造成用户服务可能长时间中断的问题，本发明由IMS网络中的第一网络实体获知保存有用户注册相关数据的第二网络实体是否失效；并在所述第一网络实体获知所述第二网络实体失效时，通知与失效的第二网络实体相关的注册用户重新注册。
本文所述的“失效”是指网络设备故障后重新启动，或因不可控因素导致网络设备彻底损坏的情况。
网络中保存用户注册相关数据的第二网络实体包括：代理-呼叫会话控制功能(P-CSCF)实体、业务-呼叫会话控制功能(S-CSCF)实体、归属用户服务器(HSS)和应用服务器(AS)等；通知用户重新注册的第一网络实体的逻辑功能可以是与各第二网络实体相关联的IMS网络现有实体实现，当然也可是一个专用的网络实体实现。
在针对第二网络实体失效而对受影响用户进行通知的过程中，第一网络实体都需要确切知道失效网络实体对应的受影响用户到底是哪些。因此，本发明采用在用户注册过程中，在IMS网络某个指定的网络实体上保存与该注册用户相关的网络设备标识，当第二网络实体故障，第一网络实体可从该指定的网络实体获取通知用户重新注册所需要的信息。网络实体的标识可以是网络实体的名称，也可以是网络实体的地址。
业务-呼叫会话控制功能(S-CSCF)实体在用户终端注册过程中从HSS下载用户签约数据，同时保存Contact、PATH等用户注册状态相关信息。S-CSCF实体失效，在该S-CSCF实体注册的用户将无法做主叫发起呼叫，此时用户可主动尝试重新注册，注册中I-CSCF实体选择状态正常的S-CSCF实体，注册成功后继续业务。但如果用户处于待机状态，则用户丢失所有入呼叫业务，只有当重注册定时器超时后，发起重注册而注册到状态正常的S-CSCF实体后才可恢复。
针对S-CSCF实体失效后用户在一段时间内无法获得服务这种情况，本发明采用第一网络实体向受影响用户发通知要求用户终端重新注册的方法以继续用户服务。用户终端通过P-CSCF实体在S-CSCF实体注册时，S-CSCF将用户标识以及所述S-CSCF实体和对应的P-CSCF实体标识信息关联并保存在指定网络实体；当所述S-CSCF实体的第一网络实体检测到该S-CSCF实体失效，根据该失效S-CSCF实体的标识信息从所述指定的网络实体获取受影响的用户标识以及相应P-CSCF实体标识，第一网络实体通过对应的P-CSCF实体通知受影响用户进行重注册。
P-CSCF实体失效，P-CSCF实体保存的用户注册相关数据(如SA)丢失，用户终端无法发起和接听呼叫。当用户无法发起呼叫，用户可通过另一P-CSCF实体重新发起注册，继续主叫业务。如果用户处于待机状态，只有当重注册定时器超时，终端才发现P-CSCF实体失效，此前用户丢失所有入呼叫。
针对P-CSCF实体失效，本发明采用第一网络实体向受影响用户发送通知要求用户重新注册的方法使用户继续获得服务。用户终端通过P-CSCF实体在S-CSCF实体注册，P-CSCF实体的第一网络实体可以是对应的S-CSCF实体。
用户终端通过P-CSCF实体在S-CSCF实体注册，P-CSCF实体将自身地址在Path头域带给S-CSCF实体，此外，该P-CSCF实体还携带相关P-CSCF实体标识信息，S-CSCF实体在用户注册数据中保存P-CSCF实体的地址以及相关P-CSCF实体的地址。当所述S-CSCF实体检测所述P-CSCF实体失效，根据失效P-CSCF实体的标识从自身的用户注册状态数据中获知受影响用户，并通过用户注册状态数据中保存的相关P-CSCF实体向用户终端发送通知。
针对P-CSCF实体的失效，本发明还可以是采用与失效P-CSCF实体处在同一漫游域的第一网络实体设备主动通知用户，用户重新注册以继续服务.例如，第一网络实体是与失效P-CSCF实体处于同一IMS漫游域的另一个P-CSCF实体.当第一网络实体感知P-CSCF实体失效，通过向用户发送通知，用户接收通知后重新注册以继续获得服务.在IMS网络部署中，用户归属域与漫游域通常不属于同一个运营商.采用这种方式，漫游域网络设备故障由漫游域运营商解决，从而避免了不同运营商间的耦合.
用户注册过程HSS也保存用户注册相关数据，通常记录用户注册状态，记录为该用户分配的S-CSCF实体。HSS故障，后续用户业务受影响。例如正常情况下，用户做被叫，被叫归属域I-CSCF实体向HSS查询以决定将呼叫请求路由到相应S-CSCF实体，HSS故障，I-CSCF实体无法获知被叫当前注册在哪个S-CSCF实体，最终导致用户无法接听入呼叫。
针对HSS故障，本发明也可采用由第一网络实体通知受影响用户重新注册的方法使用户继续获得服务。第一网络设备可以是S-CSCF实体，归属域有多个HSS时，S-CSCF实体通过Dx接口与SLF交互确定注册用户对应的HSS后，在用户注册状态数据中记录注册用户相应的HSS地址。某HSS故障，归属域中的所有S-CSCF实体依据自身保存的注册用户与HSS对应关系，各自向因HSS故障受影响的用户终端发送通知。当归属域中仅有一个HSS，该HSS故障，S-CSCF实体向所有已注册用户发送通知。
用户注册过程中，某些为用户提供业务的应用服务器AS保存用户注册相关数据。例如，某AS为用户提供在线状态服务，用户注册时，S-CSCF实体依据该用户的初始过滤规则，向该AS发起第三方注册，AS从而知道用户已注册且可达。
保存用户注册相关数据的AS故障后，无法为用户提供相应业务，当不提供相应业务则影响用户正常使用时，运营商通过第一网络实体向受影响用户终端发送通知，用户终端重新注册后获得服务。第一网络实体可以是S-CSCF实体，当某一个AS故障，S-CSCF实体检查自身保存的注册用户数据，向涉及到故障AS的所有用户终端发送通知，用户终端接收通知后重新注册，在重新注册过程中，S-CSCF实体选择向另一可提供相同业务的AS发送第三方注册。
网络设备故障，第一网络实体向用户终端发通知有先后顺序，此过程中，如果受网络设备故障影响的用户终端因未正常发起呼叫而已重新注册，因第一网络实体不知道，该终端仍会接到相应的重新注册通知，虽然会导致终端再次注册一次，但这不会造成错误。
以上对各类存有用户注册相关数据的网络设备失效情况下的处理方法，可以分别单独使用或相互结合使用。例如，根据IMS网络实际组网情况，仅针对S-CSCF实体失效情况下采用本发明的方法来通知用户重新注册，而针对P-CSCF实体失效采用其他网络可靠性实现方法。
前述针对各类网络设备失效的方法也可应用于同一IMS网络。例如，AS失效时由第一网络实体通知相关用户，S-CSCF实体失效时也由第一网络实体通知相关用户。如图2所示，当地点2的AS3与S-CSCF3实体同时故障，作为S-CSCF3的第一网络实体S-CSCF1和S-CSCF2向HSS获取受S-CSCF3故障影响的用户，向这些用户终端发送通知。作为AS3的第一网络实体S-CSCF1，S-CSCF2和S-CSCF3，应分别检查自己所服务的用户中哪些用到AS3提供的服务，并向相应的用户终端发送通知。显然由于S-CSCF3也故障，不能作为AS3的第一网络实体向相关用户下发通知，但由于S-CSCF1与S-CSCF2作为S-CSCF3的第一网络实体已向原注册在S-CSCF3上的所有用户终端发送了通知，因AS3故障而受影响的用户自然也包含在其中。
参阅图3A所示，S-CSCF失效时通知用户终端重新注册的处理流程如下(省略对用户的认证过程)：
步骤1-2：用户终端(UE)通过P-CSCF1向归属域发注册请求REGISTER。
步骤3-5：I-CSCF与HSS交互后，将REGISTER请求转发给相应的S-CSCF1。
步骤6-7：S-CSCF1认证该注册请求后接受用户注册。S-CSCF1将PATH头域中P-CSCF1地址保存在用户的注册状态数据。依3GPP协议流程，S-CSCF1通过SAR/SAA与HSS交互，通知HSS为注册用户服务的S-CSCF1名字以及下载用户签约数据。本发明，SAR还携带为相应注册用户服务的P-CSCF1地址，HSS保存注册用户与S-CSCF1，P-CSCF1三者间的对应关联。
步骤8-10：S-CSCF1向用户终端返回200响应表明注册成功。
步骤50：S-CSCF1实体故障。
步骤51-52：在本发明，S-CSCF2获知S-CSCF1故障后，S-CSCF2向HSS发送SRR(Service Restore Request)请求，其中包含S-CSCF1标识。HSS在SRA(Service Restore Answer)响应中，返回已在S-CSCF1注册的用户的相关信息，包括用户标识及相应P-CSCF1地址。当用户相关信息通过SRA传给S-CSCF2后，HSS删除与该用户相关的注册状态信息。SRR与SRA为本发明新增流程。
步骤53-56：S-CSCF2通过由HSS获得相关信息，向已在S-CSCF1注册的用户发送NOTIFY通知用户重新注册。向用户终端发通知时，需要通过相应的为该用户终端服务的P-CSCF1实体。
以上流程，S-CSCF1的第一网络实体不限于S-CSCF2一个，例如，第一网络实体还可以有S-CSCF3和S-CSCF4等，HSS配置S-CSCF1与相应第一网络实体间对应关系，只有属于S-CSCF1第一网络实体的其他S-CSCF才允许通过SRR/SRA与HSS交互获取注册到S-CSCF1实体上的用户相关信息。当收到多个第一网络实体的SRR请求时，HSS可以将注册在S-CSCF1实体上的用户信息均匀的分配给各个第一网络实体。由这些第一网络实体S-CSCF并行向用户发出重新注册通知，加快通知速度，使网络负荷更均匀。
HSS还可以配置用户的重要性级别，向第一网络实体S-CSCF优先传送重要性级别高的用户相关数据，以便这些用户能够获得优先通知。
在上述流程中，第一网络实体完成的逻辑功能可以存在于S-CSCF，也可以存在于其他类型的网络实体，例如AS等。
另外，S-CSCF第一网络实体还可以为漫游域的网络设备，例如P-CSCF。由P-CSCF感知S-CSCF的故障后，P-CSCF通知相关受影响的UE重新发起注册。
参阅图3B所示，P-CSCF失效时主动通知用户终端重新注册的处理流程如下(省略了对用户注册的认证)：
步骤1-2：用户终端(UE)通过P-CSCF1向归属域发注册请求REGISTER。本发明，P-CSCF1配置与其相关的P-CSCF2地址(当P-CSCF1故障，P-CSCF2作为通知请求消息到达用户终端的通道)。P-CSCF1增加PATH头域将自身地址包含在其中，同时也在PATH头域中新增一个参数，用于携带P-CSCF2地址。
步骤3-5：I-CSCF与HSS交互后，将REGISTER请求转发给相应的S-CSCF1。
步骤6-7：S-CSCF1认证该注册请求后接受用户注册。S-CSCF1将PATH头域中的P-CSCF1地址保存在用户注册数据中，同时也保存与P-CSCF1相关联的P-CSCF2地址。
步骤8-10：S-CSCF1向用户终端返回200响应表明注册成功。
步骤80：P-CSCF1实体故障。
步骤81-82：S-CSCF1获知P-CSCF1故障，依据自身的用户注册数据，获知哪些用户因P-CSCF1故障而受到影响，对这些用户发送的NOTIFY通知请求，是通过保存的与P-CSCF1相关联的P-CSCF2地址，到达用户终端，以通知用户终端发起重新注册。
步骤83-84：用户终端返回200响应。
与P-CSCF1相关联的P-CSCF2，是指P-CSCF2收到由S-CSCF发来的目的地为原通过P-CSCF1注册的UE的请求消息，可以将该消息发往相应UE。这至少要求P-CSCF2实体与P-CSCF1实体处于同一IP地址域。
以上流程，P-CSCF1的第一网络实体为S-CSCF。本发明中，P-CSCF1的第一网络实体还可以是其他网络设备，例如，P-CSCF2也可以作为P-CSCF1的第一网络实体。用户终端通过P-CSCF1注册成功后，P-CSCF1告知P-CSCF2通过P-CSCF1已注册成功的用户标识，当P-CSCF1故障，P-CSCF2可向因P-CSCF1故障而受影响的用户终端发送通知请求。
针对HSS故障或AS故障而由第一网络实体通知用户终端重新注册的具体流程与上述流程在原理上是相同的，不再赘述。
以上所描述的针对各类网络设备失效的通知方法，第一网络实体依据不同的策略发现受某网络设备失效影响的用户。本发明也可采用统一的方法来获得因某网络设备失效而影响的用户标识。图4描述了用户终端注册过程所涉及的各类网络设备。在注册流程中，S-CSCF实体作为为用户提供注册功能的核心设备，在接收消息5时，可从SIP请求REGISTER获得P-CSCF实体及I-CSCF实体地址。存在多个HSS时，S-CSCF实体通过SLF可知道确切的保存相应用户数据的HSS地址。同时，S-CSCF实体也依据用户的初始过滤规则，为用户向相关的业务服务器进行第三方注册，S-CSCF实体因此知道与用户注册相关的AS1与AS2地址。S-CSCF实体在完成与用户注册相关所有操作后，向一个指定网络设备发送消息，其中包含已注册成功的用户标识以及与该用户注册相关联的各类网络设备标识信息。例如，图4中，S-CSCF实体将此信息保存在操作维护系统OMC。这样网络任何第一网络实体都可通过OMC获得因某网络设备故障受影响的相关用户的用户标识，进而向这些用户发送通知。OMC中还可配置某第二网络实体对应的第一网络实体有哪些(一个第二网络实体可以同时有多个相应第一网络实体)，依据此配置信息决定是否允许第一网络实体的查询请求，以及决定在相应查询响应中返回的数据，例如将与第二网络实体相关的所有用户标识均匀分配在不同的查询响应中。
以上所描述的针对各类网络设备失效的通知方法中，依据用户开户的签约信息，IMS网络认为当相关网络设备故障时需要通知相应用户，相当于用户对相应“网络设备故障”事件包进行了缺省的订阅，是一种隐含的订阅关系。或者，用户终端可以在注册成功后，向第一网络实体发送SUBSCRIBE显式订阅相应“网络设备故障”事件包。当相关网络设备故障，第一网络实体基于用户终端的已有订阅向用户终端发通知。
当用户是通过签约而隐式订阅“网络设备故障”事件包，相应网络设备故障后，第一网络实体通过向终端发送NOTIFY请求来通知，该NOTIFY请求消息体的格式由运营商与手机终端商定。
当第一网络实体是在用户归属域向用户终端发通知，本发明可以利用现有IMS注册状态事件通知机制，通知用户终端相应注册状态失效，要求用户重新发起注册以继续获得服务.IMS网络已应用的用户注册状态事件通知机制，详细内容可参考IETF RFC3680(A SIP Event Package for Registrations)，3GPPTS24.229(对用户终端及P-CSCF订阅用户注册状态事件的相关描述，如5.1.1.3
Initial subscription to the registration-state event package)。如图5所示，该机制的主要处理流程如下(省略了P-CSCF、I-CSCF、HSS等网络实体)：
步骤310-340：UE通过S-CSCF的认证后，在S-CSCF注册成功。
步骤350-360：UE收到对注册请求REGISTER的200响应，针对已在S-CSCF注册成功的用户标识订阅注册状态事件包。UE收到对SUBSCRIBE的200响应后，维护相应的Dialog状态以及订阅状态。
步骤370-380：因某些业务需求，如运营商更改了用户签约数据，S-CSCF向UE发NOTIFY请求，通知终端发起重新注册。此NOTIFY请求的发送是基于步骤350-360中用户终端与S-CSCF之间建立的Dialog及订阅状态。
当S-CSCF作为HSS或AS的第一网络实体，当HSS或AS故障，需要向注册在自身的某些用户发送通知，可利用现有机制，基于通过用户注册状态事件订阅已建立的Dialog及订阅状态来发送。
进一步，当S-CSCF接受用户对注册状态事件的订阅后，除自身维护Dialog及相关订阅状态，还将这些状态信息保存在相应第一网络实体上，当该S-CSCF故障，基于目前已有的机制，相应第一网络实体可基于已保存的Dialog以及订阅状态，发送NOTIFY通知终端相应的注册状态为非激活(deactive)，从而要求终端发起重注册。
利用现有的注册状态事件通知机制，不需要为实现网络设备通知用户重新注册而扩展现有协议。针对S-CSCF本身故障，仅需要S-CSCF动态备份与用户订阅状态相关的少量信息到相应的第一网络实体上。
如前述第一网络实体通过用户终端对“网络设备故障”事件的显示订阅或通过终端对注册状态事件的订阅来通知终端重新注册，UE收到NOTIFY通知后可匹配其自身维护的Dialog以及订阅状态(通过call-id等信息)，据此确认该通知是自己曾订阅的事件，当UE先前通过安全通道发起注册状态事件订阅，则该通知是可信的，因为除可信任网络设备，没有第三方能获取用户对其自身注册状态事件订阅的相关状态信息，也无法仿冒发出相应的NOTIFY通知。某个IMS网络设备故障，对每个用户仅发送一次NOTIFY通知，之后终端发起新的注册和订阅，因此即使该NOTIFY在向用户终端传送过程中没有受安全通道保护，被第三方截获也没有意义。
在上述过程中，当S-CSCF1实体故障，S-CSCF2实体通过P-CSCF1实体向终端发送通知请求NOTIFY。UE与P-CSCF1间已建立安全通道，UE由安全通道接收的NOTIFY是可信任的归属域设备发来的，因此UE可依据NOTIFY指示发起用户重新注册过程。而对于P-CSCF1实体故障的情况，UE与P-CSCF1实体间建立的安全通道将丢失。S-CSCF1实体通过P-CSCF2实体向UE发送NOTIFY通知信息，由于UE与P-CSCF2实体间没有安全通道，UE无法确认该NOTIFY的发送者是否是可信任的网络设备。
在用户终端与网络设备间没有安全通道的情况下，当用户终端接收到第一网络实体的通知，只有UE信任NOTIFY的发送者，才进行重新注册操作.如前述用户可根据接收到的NOTIFY是否与自身维护的Dialog以及订阅状态相匹配来决定是否信任收到NOTIFY请求.此外，用户终端还可以通过如下机制来认证网络的通知请求.
当发送通知的设备为S-CSCF时，UE可采用以下两种方式对发送者S-CSCF进行验证：
1、利用AKA认证中的AUTS参数认证网络设备真实性
如图6A所示，S-CSCF在发向用户的NOTIFY中携带WWW-Authorization头域，依据保存的用户鉴权信息，WWW-Authorization头域的nonce参数中包含RAND，AUTN等AKA相关参数。UE收到的NOTIFY请求中包含该头域，可依据RAND，AUTN等信息，验证网络设备的身份是否可信任。
2、UE对收到的NOTIFY请求进行Digest认证
如图6B所示，其主要流程如下：
步骤100-130：用户接收NOTIFY请求后，回401响应对该请求的发送者进行Digest身份认证。UE在401中携带WWW-Authenticate认证挑战头域。
步骤140-150：S-CSCF收到401后，通过MAR/MAA与HSS交互，获得用于Digest认证计算Response参数的HA1值。S-CSCF依据HA1，计算出Response参数，生成WWW-Authorization头域。
步骤160-190：S-CSCF在发往终端UE的NOTIFY请求中携带WWW-Authorization头域。终端认证成功后，回送200响应。表明接受了网络的事件通知。
HA1值也可以在发送第一个NOTIFY之前，由S-CSCF在通过SRR/SRA与HSS交互获取用户签约信息的过程中向HSS获取并保存在S-CSCF。
另外，用户终端可以通过如下方法来信任发送通知请求的P-CSCF。这适用于发出通知的第一网络实体为漫游域的P-CSCF，并且，当用户终端信任发送请求的P-CSCF，由于S-CSCF与P-CSCF间相互信任，依据信任的传递关系，用户终端也是信任S-CSCF的，因此如下方法也同样可以应用在对S-CSCF发送的NOTIFY进行认证的情况。
3、利用IP地址验证网络设备P-CSCF的真实性
对于IP地址不可仿冒的组网，UE获取IP地址时，通过DHCP过程同时获得P-CSCF1和P-CSCF2地址。如果UE与P-CSCF间的IP网络，已由IP层组网保证了IP地址不可仿冒(如Early IMS所要求)，则UE接收到P-CSCF2来的通知请求，若检查其源IP正是DHCP过程所获取的P-CSCF2地址，则可认为该NOTIFY请求来自可信任的网络设备。
4、通过建立TLS连接验证网络设备P-CSCF真实性
在每个P-CSCF都有相应数字证书(数字证书是经发证机构签名的P-CSCF公有秘钥)，P-CSCF向网络发通知前，P-CSCF作为客户端向用户终端发起TLS连接请求(ClientHello)，在后续P-CSCF与用户终端间为TLS连接建立而协商的过程中，P-CSCF向用户终端提供其自身的数字证书，因而终端是可以信任P-CSCF。TLS连接建立后，P-CSCF向用户终端发送通知请求。
OMA标准组织为了实现设备管理Device Management需求，定义了相应架构和协议。此架构通过Device Management Server(DM Server)与用户终端交互，完成对用户终端管理，例如运营商对用户终端软件的自动升级。通常用户终端无法被动等待来自DM Server的连接请求，或因为安全原因终端不能打开端口等待来自DM Server的连接，当设备管理业务流程由DM Server端触发，DM Server可以向终端发送“notification”通知终端主动向DM Server建立连接以完成相应设备管理业务。详细流程可参见OMA-TS-DM-Notification-V1_2-20050607-C。
本发明，无论第二网络实体是哪种网络实体，第一网络实体的逻辑功能都可以由此OMA设备管理架构中的DM Server来实现。DM Server获知第二网络实体失效时，通过查询特定数据库(例如查询图4中保存有注册成功用户标识以及相关的网络实体标识的OMC)得知第二网络实体失效所影响的用户，基于前述现有OMA设备管理架构中DM Server向用户终端发送通知消息的流程，向相应的用户终端发送通知，要求用户终端重新发起向IMS网络的注册过程。本发明要求对现有通知消息“trigger-messsage”的格式有所扩展，DM Server可通过该扩展指示用户终端是重新发起注册，而不是建立与DM Server之间的设备管理Session。
从上述可知，在本发明中，第一网络实体需要获知相关网络设备的故障。具体方法，可以通过网管接口采用人工方式下发指令，显式的指明某个网络设备已故障。另外，也可采用下述的IMS网络设备状态检测和状态通知方法：
1、IMS网络设备状态检测
运营商网内有“心跳服务器”，用于检测各IMS网络设备状态。以检测S-CSCF状态为例，如图7A所示，心跳服务器向被检测实体S-CSCF周期性发送SIP请求OPTION，如收到响应，表明被检查实体S-CSCF状态可用。
如果S-CSCF死机后立即重启，且这段时间没收到心跳服务器的检测消息OPTION(即S-CSCF的死机和重启动发生于发送OPTION周期之间)，则心跳服务器会误以为被检测对象S-CSCF正常工作。由于S-CSCF死机重启动导致所有用户数据丢失，心跳服务器需能检测出这种状态。因此，本发明在心跳服务器与被检测实体间保留对OPTION消息个数的计数器，当心跳服务器收到200响应中的携带的OPTION计数器等于自身曾向被检测实体发送的OPTION数量，表明被检测实体状态正常。如心跳服务器发送OPTION后，在规定时间内没有收到相应200响应，表明被检测实体死机。
如被检测实体死机重启，心跳服务器收到200响应中携带的计数器值为“0”，因此知道被检测实体已死机并重启动。心跳服务器发现被检测实体死机重启动后，发送OPTION请求并携带“计数器同步指示”，以进行两边计数器的同步，如图7B所示。
上述这种检测方法还可进一步应用到对IMS网络设备内部业务处理板级别的状态检测监控。
2、IMS网络设备状态订阅/通知机制
心跳服务器保存S-CSCF1状态，并作为Presence Server提供“订阅服务”，其他网络设备如S-CSCF2实体可向心跳服务器发起订阅获得S-CSCF1实体的状态。如图8所示，在步骤410-420，S-CSCF2实体向心跳服务器订阅S-CSCF1实体的状态，在步骤430-440，心跳服务器在检测到S-CSCF1状态由正常变化为失效时，向S-CSCF2实体发送通知消息。
如订阅者与被订阅者属于不同运营商，运营商可能在某些情况下限制不属同一域的网络设备获取自己网络设备的相关状态，这可在心跳服务器设定订阅规则实现。
同一运营商内部的I-CSCF也可以通过订阅获取域内各个S-CSCF的可用状态.这样S-CSCF的状态信息可直接应用于S-CSCF的选择过程，而不需要等消息重传失败后，再尝试其他S-CSCF.
利用以上状态检测和订阅通知的方法，第一网络实体可以自动发现相关网络设备的状态变化。或者，由心跳服务器检测到的网络设备状态，供网络维护人员参考，为是否下发人工指令提供依据。如，网络维护人员可能需要确认故障原因是否是由于短时间内的网线连接问题。
本领域的普通技术人员根据上述的说明，可以得知采用网络中S-CSCF实体和P-CSCF实体之外的其他网络实体作为第一网络实体，其实现过程与上述同理，在此不再赘述。
显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若对本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。
本文所述的“失效”是指网络设备故障后重新启动，或因不可控因素导致网络设备彻底损坏的情况。
网络中保存用户注册相关数据的第二网络实体包括：代理-呼叫会话控制功能(P-CSCF)实体、业务-呼叫会话控制功能(S-CSCF)实体、归属用户服务器(HSS)和应用服务器(AS)等；通知用户重新注册的第一网络实体的逻辑功能可以是与各第二网络实体相关联的IMS网络现有实体实现，当然也可是一个专用的网络实体实现。
在针对第二网络实体失效而对受影响用户进行通知的过程中，第一网络实体都需要确切知道失效网络实体对应的受影响用户到底是哪些。因此，本发明采用在用户注册过程中，在IMS网络某个指定的网络实体上保存与该注册用户相关的网络设备标识，当第二网络实体故障，第一网络实体可从该指定的网络实体获取通知用户重新注册所需要的信息。网络实体的标识可以是网络实体的名称，也可以是网络实体的地址。
业务-呼叫会话控制功能(S-CSCF)实体在用户终端注册过程中从HSS下载用户签约数据，同时保存Contact、PATH等用户注册状态相关信息。S-CSCF实体失效，在该S-CSCF实体注册的用户将无法做主叫发起呼叫，此时用户可主动尝试重新注册，注册中I-CSCF实体选择状态正常的S-CSCF实体，注册成功后继续业务。但如果用户处于待机状态，则用户丢失所有入呼叫业务，只有当重注册定时器超时后，发起重注册而注册到状态正常的S-CSCF实体后才可恢复。
针对S-CSCF实体失效后用户在一段时间内无法获得服务这种情况，本发明采用第一网络实体向受影响用户发通知要求用户终端重新注册的方法以继续用户服务。用户终端通过P-CSCF实体在S-CSCF实体注册时，S-CSCF将用户标识以及所述S-CSCF实体和对应的P-CSCF实体标识信息关联并保存在指定网络实体；当所述S-CSCF实体的第一网络实体检测到该S-CSCF实体失效，根据该失效S-CSCF实体的标识信息从所述指定的网络实体获取受影响的用户标识以及相应P-CSCF实体标识，第一网络实体通过对应的P-CSCF实体通知受影响用户进行重注册。
P-CSCF实体失效，P-CSCF实体保存的用户注册相关数据(如SA)丢失，用户终端无法发起和接听呼叫。当用户无法发起呼叫，用户可通过另一P-CSCF实体重新发起注册，继续主叫业务。如果用户处于待机状态，只有当重注册定时器超时，终端才发现P-CSCF实体失效，此前用户丢失所有入呼叫。
针对P-CSCF实体失效，本发明采用第一网络实体向受影响用户发送通知要求用户重新注册的方法使用户继续获得服务。用户终端通过P-CSCF实体在S-CSCF实体注册，P-CSCF实体的第一网络实体可以是对应的S-CSCF实体。
用户终端通过P-CSCF实体在S-CSCF实体注册，P-CSCF实体将自身地址在Path头域带给S-CSCF实体，此外，该P-CSCF实体还携带相关P-CSCF实体标识信息，S-CSCF实体在用户注册数据中保存P-CSCF实体的地址以及相关P-CSCF实体的地址。当所述S-CSCF实体检测所述P-CSCF实体失效，根据失效P-CSCF实体的标识从自身的用户注册状态数据中获知受影响用户，并通过用户注册状态数据中保存的相关P-CSCF实体向用户终端发送通知。
针对P-CSCF实体的失效，本发明还可以是采用与失效P-CSCF实体处在同一漫游域的第一网络实体设备主动通知用户，用户重新注册以继续服务.例如，第一网络实体是与失效P-CSCF实体处于同一IMS漫游域的另一个P-CSCF实体.当第一网络实体感知P-CSCF实体失效，通过向用户发送通知，用户接收通知后重新注册以继续获得服务.在IMS网络部署中，用户归属域与漫游域通常不属于同一个运营商.采用这种方式，漫游域网络设备故障由漫游域运营商解决，从而避免了不同运营商间的耦合.
用户注册过程HSS也保存用户注册相关数据，通常记录用户注册状态，记录为该用户分配的S-CSCF实体。HSS故障，后续用户业务受影响。例如正常情况下，用户做被叫，被叫归属域I-CSCF实体向HSS查询以决定将呼叫请求路由到相应S-CSCF实体，HSS故障，I-CSCF实体无法获知被叫当前注册在哪个S-CSCF实体，最终导致用户无法接听入呼叫。
针对HSS故障，本发明也可采用由第一网络实体通知受影响用户重新注册的方法使用户继续获得服务。第一网络设备可以是S-CSCF实体，归属域有多个HSS时，S-CSCF实体通过Dx接口与SLF交互确定注册用户对应的HSS后，在用户注册状态数据中记录注册用户相应的HSS地址。某HSS故障，归属域中的所有S-CSCF实体依据自身保存的注册用户与HSS对应关系，各自向因HSS故障受影响的用户终端发送通知。当归属域中仅有一个HSS，该HSS故障，S-CSCF实体向所有已注册用户发送通知。
用户注册过程中，某些为用户提供业务的应用服务器AS保存用户注册相关数据。例如，某AS为用户提供在线状态服务，用户注册时，S-CSCF实体依据该用户的初始过滤规则，向该AS发起第三方注册，AS从而知道用户已注册且可达。
保存用户注册相关数据的AS故障后，无法为用户提供相应业务，当不提供相应业务则影响用户正常使用时，运营商通过第一网络实体向受影响用户终端发送通知，用户终端重新注册后获得服务。第一网络实体可以是S-CSCF实体，当某一个AS故障，S-CSCF实体检查自身保存的注册用户数据，向涉及到故障AS的所有用户终端发送通知，用户终端接收通知后重新注册，在重新注册过程中，S-CSCF实体选择向另一可提供相同业务的AS发送第三方注册。
网络设备故障，第一网络实体向用户终端发通知有先后顺序，此过程中，如果受网络设备故障影响的用户终端因未正常发起呼叫而已重新注册，因第一网络实体不知道，该终端仍会接到相应的重新注册通知，虽然会导致终端再次注册一次，但这不会造成错误。
以上对各类存有用户注册相关数据的网络设备失效情况下的处理方法，可以分别单独使用或相互结合使用。例如，根据IMS网络实际组网情况，仅针对S-CSCF实体失效情况下采用本发明的方法来通知用户重新注册，而针对P-CSCF实体失效采用其他网络可靠性实现方法。
前述针对各类网络设备失效的方法也可应用于同一IMS网络。例如，AS失效时由第一网络实体通知相关用户，S-CSCF实体失效时也由第一网络实体通知相关用户。如图2所示，当地点2的AS3与S-CSCF3实体同时故障，作为S-CSCF3的第一网络实体S-CSCF1和S-CSCF2向HSS获取受S-CSCF3故障影响的用户，向这些用户终端发送通知。作为AS3的第一网络实体S-CSCF1，S-CSCF2和S-CSCF3，应分别检查自己所服务的用户中哪些用到AS3提供的服务，并向相应的用户终端发送通知。显然由于S-CSCF3也故障，不能作为AS3的第一网络实体向相关用户下发通知，但由于S-CSCF1与S-CSCF2作为S-CSCF3的第一网络实体已向原注册在S-CSCF3上的所有用户终端发送了通知，因AS3故障而受影响的用户自然也包含在其中。
参阅图3A所示，S-CSCF失效时通知用户终端重新注册的处理流程如下(省略对用户的认证过程)：
步骤1-2：用户终端(UE)通过P-CSCF1向归属域发注册请求REGISTER。
步骤3-5：I-CSCF与HSS交互后，将REGISTER请求转发给相应的S-CSCF1。
步骤6-7：S-CSCF1认证该注册请求后接受用户注册。S-CSCF1将PATH头域中P-CSCF1地址保存在用户的注册状态数据。依3GPP协议流程，S-CSCF1通过SAR/SAA与HSS交互，通知HSS为注册用户服务的S-CSCF1名字以及下载用户签约数据。本发明，SAR还携带为相应注册用户服务的P-CSCF1地址，HSS保存注册用户与S-CSCF1，P-CSCF1三者间的对应关联。
步骤8-10：S-CSCF1向用户终端返回200响应表明注册成功。
步骤50：S-CSCF1实体故障。
步骤51-52：在本发明，S-CSCF2获知S-CSCF1故障后，S-CSCF2向HSS发送SRR(Service Restore Request)请求，其中包含S-CSCF1标识。HSS在SRA(Service Restore Answer)响应中，返回已在S-CSCF1注册的用户的相关信息，包括用户标识及相应P-CSCF1地址。当用户相关信息通过SRA传给S-CSCF2后，HSS删除与该用户相关的注册状态信息。SRR与SRA为本发明新增流程。
步骤53-56：S-CSCF2通过由HSS获得相关信息，向已在S-CSCF1注册的用户发送NOTIFY通知用户重新注册。向用户终端发通知时，需要通过相应的为该用户终端服务的P-CSCF1实体。
以上流程，S-CSCF1的第一网络实体不限于S-CSCF2一个，例如，第一网络实体还可以有S-CSCF3和S-CSCF4等，HSS配置S-CSCF1与相应第一网络实体间对应关系，只有属于S-CSCF1第一网络实体的其他S-CSCF才允许通过SRR/SRA与HSS交互获取注册到S-CSCF1实体上的用户相关信息。当收到多个第一网络实体的SRR请求时，HSS可以将注册在S-CSCF1实体上的用户信息均匀的分配给各个第一网络实体。由这些第一网络实体S-CSCF并行向用户发出重新注册通知，加快通知速度，使网络负荷更均匀。
HSS还可以配置用户的重要性级别，向第一网络实体S-CSCF优先传送重要性级别高的用户相关数据，以便这些用户能够获得优先通知。
在上述流程中，第一网络实体完成的逻辑功能可以存在于S-CSCF，也可以存在于其他类型的网络实体，例如AS等。
另外，S-CSCF第一网络实体还可以为漫游域的网络设备，例如P-CSCF。由P-CSCF感知S-CSCF的故障后，P-CSCF通知相关受影响的UE重新发起注册。
参阅图3B所示，P-CSCF失效时主动通知用户终端重新注册的处理流程如下(省略了对用户注册的认证)：
步骤1-2：用户终端(UE)通过P-CSCF1向归属域发注册请求REGISTER。本发明，P-CSCF1配置与其相关的P-CSCF2地址(当P-CSCF1故障，P-CSCF2作为通知请求消息到达用户终端的通道)。P-CSCF1增加PATH头域将自身地址包含在其中，同时也在PATH头域中新增一个参数，用于携带P-CSCF2地址。
步骤3-5：I-CSCF与HSS交互后，将REGISTER请求转发给相应的S-CSCF1。
步骤6-7：S-CSCF1认证该注册请求后接受用户注册。S-CSCF1将PATH头域中的P-CSCF1地址保存在用户注册数据中，同时也保存与P-CSCF1相关联的P-CSCF2地址。
步骤8-10：S-CSCF1向用户终端返回200响应表明注册成功。
步骤80：P-CSCF1实体故障。
步骤81-82：S-CSCF1获知P-CSCF1故障，依据自身的用户注册数据，获知哪些用户因P-CSCF1故障而受到影响，对这些用户发送的NOTIFY通知请求，是通过保存的与P-CSCF1相关联的P-CSCF2地址，到达用户终端，以通知用户终端发起重新注册。
步骤83-84：用户终端返回200响应。
与P-CSCF1相关联的P-CSCF2，是指P-CSCF2收到由S-CSCF发来的目的地为原通过P-CSCF1注册的UE的请求消息，可以将该消息发往相应UE。这至少要求P-CSCF2实体与P-CSCF1实体处于同一IP地址域。
以上流程，P-CSCF1的第一网络实体为S-CSCF。本发明中，P-CSCF1的第一网络实体还可以是其他网络设备，例如，P-CSCF2也可以作为P-CSCF1的第一网络实体。用户终端通过P-CSCF1注册成功后，P-CSCF1告知P-CSCF2通过P-CSCF1已注册成功的用户标识，当P-CSCF1故障，P-CSCF2可向因P-CSCF1故障而受影响的用户终端发送通知请求。
针对HSS故障或AS故障而由第一网络实体通知用户终端重新注册的具体流程与上述流程在原理上是相同的，不再赘述。
以上所描述的针对各类网络设备失效的通知方法，第一网络实体依据不同的策略发现受某网络设备失效影响的用户。本发明也可采用统一的方法来获得因某网络设备失效而影响的用户标识。图4描述了用户终端注册过程所涉及的各类网络设备。在注册流程中，S-CSCF实体作为为用户提供注册功能的核心设备，在接收消息5时，可从SIP请求REGISTER获得P-CSCF实体及I-CSCF实体地址。存在多个HSS时，S-CSCF实体通过SLF可知道确切的保存相应用户数据的HSS地址。同时，S-CSCF实体也依据用户的初始过滤规则，为用户向相关的业务服务器进行第三方注册，S-CSCF实体因此知道与用户注册相关的AS1与AS2地址。S-CSCF实体在完成与用户注册相关所有操作后，向一个指定网络设备发送消息，其中包含已注册成功的用户标识以及与该用户注册相关联的各类网络设备标识信息。例如，图4中，S-CSCF实体将此信息保存在操作维护系统OMC。这样网络任何第一网络实体都可通过OMC获得因某网络设备故障受影响的相关用户的用户标识，进而向这些用户发送通知。OMC中还可配置某第二网络实体对应的第一网络实体有哪些(一个第二网络实体可以同时有多个相应第一网络实体)，依据此配置信息决定是否允许第一网络实体的查询请求，以及决定在相应查询响应中返回的数据，例如将与第二网络实体相关的所有用户标识均匀分配在不同的查询响应中。
以上所描述的针对各类网络设备失效的通知方法中，依据用户开户的签约信息，IMS网络认为当相关网络设备故障时需要通知相应用户，相当于用户对相应“网络设备故障”事件包进行了缺省的订阅，是一种隐含的订阅关系。或者，用户终端可以在注册成功后，向第一网络实体发送SUBSCRIBE显式订阅相应“网络设备故障”事件包。当相关网络设备故障，第一网络实体基于用户终端的已有订阅向用户终端发通知。
当用户是通过签约而隐式订阅“网络设备故障”事件包，相应网络设备故障后，第一网络实体通过向终端发送NOTIFY请求来通知，该NOTIFY请求消息体的格式由运营商与手机终端商定。
当第一网络实体是在用户归属域向用户终端发通知，本发明可以利用现有IMS注册状态事件通知机制，通知用户终端相应注册状态失效，要求用户重新发起注册以继续获得服务.IMS网络已应用的用户注册状态事件通知机制，详细内容可参考IETF RFC3680(A SIP Event Package for Registrations)，3GPPTS24.229(对用户终端及P-CSCF订阅用户注册状态事件的相关描述，如5.1.1.3
Initial subscription to the registration-state event package)。如图5所示，该机制的主要处理流程如下(省略了P-CSCF、I-CSCF、HSS等网络实体)：
步骤310-340：UE通过S-CSCF的认证后，在S-CSCF注册成功。
步骤350-360：UE收到对注册请求REGISTER的200响应，针对已在S-CSCF注册成功的用户标识订阅注册状态事件包。UE收到对SUBSCRIBE的200响应后，维护相应的Dialog状态以及订阅状态。
步骤370-380：因某些业务需求，如运营商更改了用户签约数据，S-CSCF向UE发NOTIFY请求，通知终端发起重新注册。此NOTIFY请求的发送是基于步骤350-360中用户终端与S-CSCF之间建立的Dialog及订阅状态。
当S-CSCF作为HSS或AS的第一网络实体，当HSS或AS故障，需要向注册在自身的某些用户发送通知，可利用现有机制，基于通过用户注册状态事件订阅已建立的Dialog及订阅状态来发送。
进一步，当S-CSCF接受用户对注册状态事件的订阅后，除自身维护Dialog及相关订阅状态，还将这些状态信息保存在相应第一网络实体上，当该S-CSCF故障，基于目前已有的机制，相应第一网络实体可基于已保存的Dialog以及订阅状态，发送NOTIFY通知终端相应的注册状态为非激活(deactive)，从而要求终端发起重注册。
利用现有的注册状态事件通知机制，不需要为实现网络设备通知用户重新注册而扩展现有协议。针对S-CSCF本身故障，仅需要S-CSCF动态备份与用户订阅状态相关的少量信息到相应的第一网络实体上。
如前述第一网络实体通过用户终端对“网络设备故障”事件的显示订阅或通过终端对注册状态事件的订阅来通知终端重新注册，UE收到NOTIFY通知后可匹配其自身维护的Dialog以及订阅状态(通过call-id等信息)，据此确认该通知是自己曾订阅的事件，当UE先前通过安全通道发起注册状态事件订阅，则该通知是可信的，因为除可信任网络设备，没有第三方能获取用户对其自身注册状态事件订阅的相关状态信息，也无法仿冒发出相应的NOTIFY通知。某个IMS网络设备故障，对每个用户仅发送一次NOTIFY通知，之后终端发起新的注册和订阅，因此即使该NOTIFY在向用户终端传送过程中没有受安全通道保护，被第三方截获也没有意义。
在上述过程中，当S-CSCF1实体故障，S-CSCF2实体通过P-CSCF1实体向终端发送通知请求NOTIFY。UE与P-CSCF1间已建立安全通道，UE由安全通道接收的NOTIFY是可信任的归属域设备发来的，因此UE可依据NOTIFY指示发起用户重新注册过程。而对于P-CSCF1实体故障的情况，UE与P-CSCF1实体间建立的安全通道将丢失。S-CSCF1实体通过P-CSCF2实体向UE发送NOTIFY通知信息，由于UE与P-CSCF2实体间没有安全通道，UE无法确认该NOTIFY的发送者是否是可信任的网络设备。
在用户终端与网络设备间没有安全通道的情况下，当用户终端接收到第一网络实体的通知，只有UE信任NOTIFY的发送者，才进行重新注册操作.如前述用户可根据接收到的NOTIFY是否与自身维护的Dialog以及订阅状态相匹配来决定是否信任收到NOTIFY请求.此外，用户终端还可以通过如下机制来认证网络的通知请求.
当发送通知的设备为S-CSCF时，UE可采用以下两种方式对发送者S-CSCF进行验证：
1、利用AKA认证中的AUTS参数认证网络设备真实性
如图6A所示，S-CSCF在发向用户的NOTIFY中携带WWW-Authorization头域，依据保存的用户鉴权信息，WWW-Authorization头域的nonce参数中包含RAND，AUTN等AKA相关参数。UE收到的NOTIFY请求中包含该头域，可依据RAND，AUTN等信息，验证网络设备的身份是否可信任。
2、UE对收到的NOTIFY请求进行Digest认证
如图6B所示，其主要流程如下：
步骤100-130：用户接收NOTIFY请求后，回401响应对该请求的发送者进行Digest身份认证。UE在401中携带WWW-Authenticate认证挑战头域。
步骤140-150：S-CSCF收到401后，通过MAR/MAA与HSS交互，获得用于Digest认证计算Response参数的HA1值。S-CSCF依据HA1，计算出Response参数，生成WWW-Authorization头域。
步骤160-190：S-CSCF在发往终端UE的NOTIFY请求中携带WWW-Authorization头域。终端认证成功后，回送200响应。表明接受了网络的事件通知。
HA1值也可以在发送第一个NOTIFY之前，由S-CSCF在通过SRR/SRA与HSS交互获取用户签约信息的过程中向HSS获取并保存在S-CSCF。
另外，用户终端可以通过如下方法来信任发送通知请求的P-CSCF。这适用于发出通知的第一网络实体为漫游域的P-CSCF，并且，当用户终端信任发送请求的P-CSCF，由于S-CSCF与P-CSCF间相互信任，依据信任的传递关系，用户终端也是信任S-CSCF的，因此如下方法也同样可以应用在对S-CSCF发送的NOTIFY进行认证的情况。
3、利用IP地址验证网络设备P-CSCF的真实性
对于IP地址不可仿冒的组网，UE获取IP地址时，通过DHCP过程同时获得P-CSCF1和P-CSCF2地址。如果UE与P-CSCF间的IP网络，已由IP层组网保证了IP地址不可仿冒(如Early IMS所要求)，则UE接收到P-CSCF2来的通知请求，若检查其源IP正是DHCP过程所获取的P-CSCF2地址，则可认为该NOTIFY请求来自可信任的网络设备。
4、通过建立TLS连接验证网络设备P-CSCF真实性
在每个P-CSCF都有相应数字证书(数字证书是经发证机构签名的P-CSCF公有秘钥)，P-CSCF向网络发通知前，P-CSCF作为客户端向用户终端发起TLS连接请求(ClientHello)，在后续P-CSCF与用户终端间为TLS连接建立而协商的过程中，P-CSCF向用户终端提供其自身的数字证书，因而终端是可以信任P-CSCF。TLS连接建立后，P-CSCF向用户终端发送通知请求。
OMA标准组织为了实现设备管理Device Management需求，定义了相应架构和协议。此架构通过Device Management Server(DM Server)与用户终端交互，完成对用户终端管理，例如运营商对用户终端软件的自动升级。通常用户终端无法被动等待来自DM Server的连接请求，或因为安全原因终端不能打开端口等待来自DM Server的连接，当设备管理业务流程由DM Server端触发，DM Server可以向终端发送“notification”通知终端主动向DM Server建立连接以完成相应设备管理业务。详细流程可参见OMA-TS-DM-Notification-V1_2-20050607-C。
本发明，无论第二网络实体是哪种网络实体，第一网络实体的逻辑功能都可以由此OMA设备管理架构中的DM Server来实现。DM Server获知第二网络实体失效时，通过查询特定数据库(例如查询图4中保存有注册成功用户标识以及相关的网络实体标识的OMC)得知第二网络实体失效所影响的用户，基于前述现有OMA设备管理架构中DM Server向用户终端发送通知消息的流程，向相应的用户终端发送通知，要求用户终端重新发起向IMS网络的注册过程。本发明要求对现有通知消息“trigger-messsage”的格式有所扩展，DM Server可通过该扩展指示用户终端是重新发起注册，而不是建立与DM Server之间的设备管理Session。
从上述可知，在本发明中，第一网络实体需要获知相关网络设备的故障。具体方法，可以通过网管接口采用人工方式下发指令，显式的指明某个网络设备已故障。另外，也可采用下述的IMS网络设备状态检测和状态通知方法：
1、IMS网络设备状态检测
运营商网内有“心跳服务器”，用于检测各IMS网络设备状态。以检测S-CSCF状态为例，如图7A所示，心跳服务器向被检测实体S-CSCF周期性发送SIP请求OPTION，如收到响应，表明被检查实体S-CSCF状态可用。
如果S-CSCF死机后立即重启，且这段时间没收到心跳服务器的检测消息OPTION(即S-CSCF的死机和重启动发生于发送OPTION周期之间)，则心跳服务器会误以为被检测对象S-CSCF正常工作。由于S-CSCF死机重启动导致所有用户数据丢失，心跳服务器需能检测出这种状态。因此，本发明在心跳服务器与被检测实体间保留对OPTION消息个数的计数器，当心跳服务器收到200响应中的携带的OPTION计数器等于自身曾向被检测实体发送的OPTION数量，表明被检测实体状态正常。如心跳服务器发送OPTION后，在规定时间内没有收到相应200响应，表明被检测实体死机。
如被检测实体死机重启，心跳服务器收到200响应中携带的计数器值为“0”，因此知道被检测实体已死机并重启动。心跳服务器发现被检测实体死机重启动后，发送OPTION请求并携带“计数器同步指示”，以进行两边计数器的同步，如图7B所示。
上述这种检测方法还可进一步应用到对IMS网络设备内部业务处理板级别的状态检测监控。
2、IMS网络设备状态订阅/通知机制
心跳服务器保存S-CSCF1状态，并作为Presence Server提供“订阅服务”，其他网络设备如S-CSCF2实体可向心跳服务器发起订阅获得S-CSCF1实体的状态。如图8所示，在步骤410-420，S-CSCF2实体向心跳服务器订阅S-CSCF1实体的状态，在步骤430-440，心跳服务器在检测到S-CSCF1状态由正常变化为失效时，向S-CSCF2实体发送通知消息。
如订阅者与被订阅者属于不同运营商，运营商可能在某些情况下限制不属同一域的网络设备获取自己网络设备的相关状态，这可在心跳服务器设定订阅规则实现。
同一运营商内部的I-CSCF也可以通过订阅获取域内各个S-CSCF的可用状态.这样S-CSCF的状态信息可直接应用于S-CSCF的选择过程，而不需要等消息重传失败后，再尝试其他S-CSCF.
利用以上状态检测和订阅通知的方法，第一网络实体可以自动发现相关网络设备的状态变化。或者，由心跳服务器检测到的网络设备状态，供网络维护人员参考，为是否下发人工指令提供依据。如，网络维护人员可能需要确认故障原因是否是由于短时间内的网线连接问题。
本领域的普通技术人员根据上述的说明，可以得知采用网络中S-CSCF实体和P-CSCF实体之外的其他网络实体作为第一网络实体，其实现过程与上述同理，在此不再赘述。
显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若对本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。