IMS容灾备份方案研究.ppt

中国移动集团重点/联合研发项目结题汇报报告,2010年11月22日,项目名称：IMS网络容灾备份技术研究项目编号：2010_LH_65,一.开题计划完成情况,目 录,二、主要研究成果（整合后）,1.1 研究背景及目标,研究背景：2010年中国移动在全网部署CM-IMS商用网络。中国移动CM-IMS核心网中主要网元S-CSCF、I-CSCF、P-CSCF、HSS等均采用以省或区域为单位集中设置的方式，且单个网元的容量较大。未来的核心网络是以IMS为核心的，保证IMS网络的安全可靠至关重要，有必要研究IMS核心网元的容灾备份技术。研究目标：本课题旨在中国移动IMS网络采用相对集中设置、大容量核心网元的情况下，对IMS核心网各重要网元的容灾备份机制进行研究。针对各网元，分别从容灾效果、容灾资源配置方式、倒换方式、备份网元的组网方式、各种方案的适用条件以及设备实现能力等方面来提出容灾备份方案。综合考虑技术可行性、方案可操作性、投资，提出IMS容灾备份方案建议。,1.2 主要研究内容及分工（开题报告）,课题开题评审后确定了如下主要研究内容：,跟踪相关国际规范了解目前IMS容灾备份相关国际规范情况及其成熟度，作为本课题方案研究时的参考。对IMS设备厂家进行调研考察各厂家IMS设备容灾备份机制实现方案。考察各厂家设备支持情况。其他运营商IMS网络容灾备份部署经验。结合中国移动CM-IMS网络组网情况对各网元的容灾备份机制进行研究。研究各网元容灾备份方案、网络组织方案、倒换方式、方案适用条件。研究容灾备份对网元的功能和接口要求。研究并提出备份方案实施中需要网元自身、以及DNS等配置的数据内容。对各方案进行比较，提出适合中国移动网络实际情况的CM-IMS容灾备份建议。,1.2 主要研究内容及分工（开题报告）,主要研究单位的分工如下：,集团设计院：侧重技术方案的分析研究；组织与相关厂家进行技术交流，调研各厂家设备情况等；负责课题研究项目的总体时间进度和课题编制。江苏公司：参与技术方案的分析和研究；提供现网中容灾方案可行性的参考意见；,1.3 开题计划完成情况总结,本课题研究内容、时间进度、人员分工等均满足开题计划的要求。,一.开题计划完成情况,目 录,二、主要研究成果（整合后）,2.1 课题研究成果及适用场景,课题研究成果综述本课题研究主要是制定CM-IMS网络容灾方案，CM-IMS重要网元的容灾备份及倒换恢复的方案，主要包括ENUM/DNS、SBC、P-CSCF、I/S/E-CSCF/BGCF、HSS、MGCF，以有效的保障中国移动CM-IMS网络安全、平稳、高效运行，在核心网元发生故障退出服务的情况下，备用网元或负荷分担设备能够迅速地接管主用设备承载的业务，使业务尽快恢复。本课题研究适用场景本课题中研究的容灾备份方案是网元级的容灾方案。备用网元设备整体接管主用设备承担的业务，不涉及一个独立网元内部不同模块间的容灾备份。为保障网元级容灾的效果，主备用网元或成对负荷分担设备应设置在不同的局址，而且各自使用独立的电源和传输资源。,2.1 课题研究成果展列,1、故障检测机制介绍基于SIP OPTION的故障检测基于Diameter的链路检测2、ENUM/DNS容灾方案组网方案数据同步方案负荷分担方案3、SBC容灾方案SBC负荷分担机制SBC异本地网容灾方案固定接入用户对SBC的故障恢复机制PS域接入用户对SBC的故障恢复机制对终端和其它网元要求4、P-CSCF容灾方案P-CSCF负荷分担机制倒换机制倒回机制容灾效果分析对终端和其它网元要求,2.1 课题研究成果展列,5、I/S/E-CSCF/BGCF容灾方案I/S/E-CSCF/BGCF负荷分担机制I/S/E-CSCF/BGCF动态数据备份机制倒换机制倒回机制容灾效果分析对终端和其它网元的要求6、HSS/SLF容灾备份方案数据同步要求倒换机制倒回机制容灾效果分析对其它网元的要求7、MGCF/IM-MGW容灾方案负荷分担方案8、业务放通机制基本通话业务的放通被叫一号通业务放通,2.2 故障检测机制,基于SIP OPTION的故障检测SBC与P-CSCF之间、CSCF之间、AS与S-CSCF之间、MGCF与CSCF/BGCF之间采用基于SIP OPTION的状态检测机制，有如下两种方式：启发式SIP OPTION状态检测机制自发式SIP OPTION状态检测机制两种方式的比较如下：,2.2 故障检测机制,基于SIP OPTION的故障检测两种检测方式的适用场境：OPTION检测方是为了识别对端网元设备出现故障，不要将业务请求发往该故障网元。因此，OPTION检测方的发起机制，应该与如何获取对端网元设备信息的方式相关，建议按照两种场景分类：（1）由于CSCF与他省CSCF存在网状连接关系，且连接关系不固定。如漫游时，漫游地P-CSCF和归属I/S-CSCF之间不是固定的连接关系，同时跨省呼叫时主叫 S-CSCF和被叫I-CSCF之间的路由也不是固定的连接关系，因此CSCF故障检测建议采用启发式，便于维护。（2）SBC寻址P-CSCF（从属关系）、MGCF寻址I-CSCF、AS寻址I/S-CSCF(AS始发呼叫寻址S-CSCF建议都从I-CSCF入口)的关系都比较固定，建议采用自发式检测。,2.2 故障检测机制,基于Diameter的链路检测I-CSCF、S-CSCF、AS与HSS/SLF之间采用基于Diameter的链路监测机制。客户端（业务网元）在TCP/SCTP链路上周期性的发送握手心跳消息Device-Watchdog-Request（DWR）/Device-Watchdog-Answer(DWA)来检测对端服务器是否故障，心跳消息在IETF RFC3588中定义。Diameter链路检测时长应可配置为0-10秒。,2.3 ENUM/DNS容灾备份方案,ENUM/DNS组网方案ENUM/DNS数据同步方案ENUM/DNS负荷分担方案,2.3.1 ENUM/DNS组网方案,ENUM/DNS组网方案若省内分局址设置多套IMS核心网（CSCF），建议ENUM/DNS也分局址设置两套，采用负荷分担的工作方式，两套ENUM/DNS存储的数据保持同步。,2.3.2 ENUM/DNS数据同步方案,BOSS和网管系统对ENUM/DNS中数据更新机制有如下三种方式：方式一：ENUM/DNS主备同步方案。正常情况下BOSS系统或网管系统向ENUM/DNS系统（主）发送数据，由该ENUM/DNS系统（主）同步数据给另一套ENUM/DNS系统（备）。发生容灾时，BOSS系统或网管系统向另一套ENUM/DNS（备）系统下发数据。两套ENUM/DNS之间的数据同步机制和流程遵循RFC1995和RFC1996，采用标准DNS机制和FTP机制进行主备系统之间的数据同步。当需同步的数据量较小时，采用标准DNS机制进行同步；当需同步的数据量较大时，采用FTP机制进行同步。方式二：基于BOSS系统或网管系统的数据同步。BOSS系统或网管系统向两套ENUM/DNS同步数据，并支持失败回滚等机制。若厂家配置了业务开通网关，支持由业务开通网关向两套ENUM/DNS同步数据。方式三：ENUM/DNS采用前端+后端架构，后端数据库/存储服务器向前端同步数据。BOSS系统或网管系统向ENUM/DNS后端数据库发开通或数据配置指令数据，由后端数据库向多个前端同步数据。若ENUM/DNS的前端+后端设备做为一套完整的ENUM/DNS设备，则也需要采用基于BOSS或网管系统向两套ENUM/DNS同步。,BOSS和网管系统对ENUM/DNS中数据更新机制三种方式比较：,2.3.2 ENUM/DNS数据同步方案,2.3.2 ENUM/DNS数据同步方案,厂家设备架构及对三种数据更新机制的适用性：各厂家ENUM/DNS的设备构架如下：华为、中兴采用ENUM/DNS前台处理和后台数据库服务器合设的架构；爱立信、诺西、上海贝尔均采用前、后端分开的方式，前台负责接受查询处理，后台负责数据存储和管理，并向前端更新数据。因此根据各厂家设备实现架构不同，对于ENUM/DNS主备设备为同厂家的情况下，上述三种方式的各厂家支持情况如下表：,根据上述对三种数据更新机制研究比较以及各厂家ENUM/DNS的设备构架，对于ENUM/DNS数据同步方案建议如下：方式一对BOSS/网管系统要求较低，且有数据仲裁机制，但异厂家设备之间较难实现，部分厂家不支持。对于采用前台+后台架构方式的厂家（爱立信、诺西、上海贝尔），根据安全性要求不同，可选用方式三的两种组网模式之一。异厂家组网时，选用方式二。,2.3.3 ENUM/DNS负荷分担方案,两套ENUM/DNS系统应实现负载均衡，有以下三种方案：方案一：分区域主备方式方案二：Forwarder方式方案三：Anycast方式方案比较：方案一：实现简单，对一级ENUM/DNS和二级ENUM/DNS都没有额外的功能要求。但以省或者大区为单位划分的服务区，难以实现完全的负荷分担。并且各省业务的发展速度不均衡，服务区内的负荷更加难以控制。方案二：负载均衡效果较好。由于RTT值会根据网络情况和服务器负荷情况发生变化，客户端总能选择最近和相对负荷较小的服务器，实现负载均衡。方案三：IT领域比较专业的解决方案，目前全球Internet网里13台根DNS里有6台是采用Anycast技术实现多服务器负荷分担。在节点数量较多的情况下该方案优势比较大。但该方案存在的问题是对IP专网的路由数据配置将会增加，且目前在中国移动网络内没有应用，运维人员缺乏相关经验。建议采用方案一或方案二。,2.4 SBC容灾方案,SBC负荷分担机制SBC异本地网容灾方案固定接入用户对SBC的故障恢复机制PS域接入用户对SBC的故障恢复机制对终端和其它网元要求,2.4.1 SBC负荷分担机制,SBC负荷分担机制SBC的负荷分担主要取决于UE注册时对于SBC的选择。UE对SBC的负荷分担有如下两种方式：方式一：公网DNS通过轮询或基于优先级、权重的方式的方式将UE接入本地网内多套SBC中的一套SBC。方式二：公网DNS通过设置View的方式将UE接入区域内的一套SBC，同时支持故障倒换。对两负荷分担的方式分析及应用场景建议：方案一配置简单，适用于本地网内各区域无法细分用户源IP地址段的场景，或SBC在本地网内部署较集中，用户从本地网内不同区域接入SBC在承载网的路径类似时。方案二需要区分本地网内各区域的用户源IP地址段，在本地网内SBC分散部署（如部署在不同的区县）时，对于SBC的就近接入效果较佳。,2.4.2 SBC异本地网容灾,SBC异本地网容灾若本地网内只有一套SBC，可采用上节方式二的方法进行异本地网容灾。即公网DNS对应每个本地网配置返回SBC的地址列表，其中列表中第一个IP地址为该本地网SBC的IP地址，列表中第二个IP地址为作为容灾的另一个本地网的SBC IP地址。SBC异地容灾有两种方式：方式一：各本地网循环容灾。方式二：选取某个SBC（如省会SBC）做为其他SBC的容灾SBC。两种方式的比较如下：,2.4.2 SBC异本地网容灾,SBC异本地网容灾上述两种方式均要求SBC支持虚拟SBC的功能，要求SBC根据不同的虚拟SBC，配置多个PANI（P-Access-Network-Info）和PhoneContext，以支持计费、紧急呼叫等需求。目前各厂家虚拟SBC的实现机制有三种方式：方式一：华为、中兴、诺西的SBC支持配置两套或多套SBC设备名和IP地址。方式二：爱立信的SBC支持依据UE源地址段的不同配置多个PANI（P-Access-Network-Info）和PhoneContext。方式三：上海贝尔SBC为分布式SBC，其中信令面在省中心集中设置，媒体面BGW设置在各本地网。三种方式的分析如下：上述三种方式均能满足SBC异本地网容灾备份的需求，方式二的数据配置和维护较复杂，CMNET公网IP地址段信息的更新均要同步更新到SBC。,2.4.3 固定接入用户对SBC的故障恢复机制,倒换机制以UE的主用SBC为SBC1，备用SBC为SBC2说明对于已注册用户的倒换流程：UE已经在SBC上注册，并向SBC1发送各种请求。SBC1不响应，UE发现SBC1掉线。UE向SBC2发送注册请求，完成在SBC2设备上的注册过程，UE将后续所有请求消息均发往SBC2。UE将主叫请求消息均发往SBC2。因UE通过SBC2注册，所有被叫请求，均通过SBC2发往UE。对于正发起注册用户的倒换流程：SBC1故障。终端发起注册。SBC1不响应。终端从DNS返回的SBC列表中，选择其他SBC2地址。终端向SBC2发送注册请求。SBC2将终端的请求转发给核心网，并将核心网的响应消息，转回给终端。完成终端在SBC2的注册过程。终端的后续主被叫消息，全部通过SBC2转发。,倒回机制UE发起呼叫请求时，从本地IP地址列表中选择第一个IP，向该SBC发起呼叫请求，SBC向UE发送错误码502，指示UE重新注册。UE重新发起初始注册时，从本地IP地址列表中选择第一个IP，向该SBC发起重新注册，如果该SBC已恢复正常，UE就注册成功。从而实现UE倒回到主用SBC，后续由此SBC为这个UE提供服务。,2.4.4 PS域接入用户对SBC的故障恢复机制,倒换机制在现有网络情况下，PS域做为与其它接入网对等的网络接入IMS，PS接入用户也采用基于SBC域名解析的DNS发现方式，因此相应故障恢复机制与固定接入用户相同；若未来对GGSN进行改造支持SBC发现机制和故障检测机制，可以采用基于GGSN的故障恢复机制。倒换机制如下：用户发起接入请求，GGSN/PDG-GW返回SBC的地址列表。用户选择一个SBC注册。GGSN监测SBC的状态，发现SBC故障，GGSN通知UE有两种方式方式一：GGSN通过PDP上下文更新给用户发送一个新的SBC地址列表（将故障SBC地址删除）。UE收到消息后比对，自身注册的SBC是否在新列表中，若不在列表中，则UE从新列表中选择一个SBC重新发起注册。方式二：GGSN向所有涉及故障SBC的UE发送SBC不可达消息。UE收到消息后，从列表中重新选择一个SBC发起注册。倒回机制GGSN监测到SBC故障恢复，则在用户发起新接入请求时，在返回的SBC列表中添加已恢复的SBC IP地址。,2.4.5 SBC容灾对终端和其它网元的要求,对终端的要求：（1）对于上海贝尔SBC，由于采用分布式架构，且根据IP地址+端口号区分虚拟SBC，因此要求终端支持SRV查询。（2）为支持终端对主备用SBC的故障倒换，要求终端至少能存储2个SBC IP地址。（3）要求终端能多次尝试连接。（4）要求终端在重新注册或发起呼叫时，优选主用SBC，以便主用SBC故障恢复时能倒回主用SBC。（5）为减少SBC倒换对用户业务的影响，未来可要求终端支持SIP OPTION检测来快速检测SBC状态，以实现快速倒换倒回。对终端注册刷新时间的建议：终端注册刷新时间过小会影响核心网性能，过小又会影响业务体验，建议设置为6003600秒之间。对CMNET DNS的要求：配置数据支持对SBC的容灾。对GGSN的要求：（1）要求支持SBC发现（2）支持与SBC之间的故障监测机制,2.5 P-CSCF容灾方案,P-CSCF负荷分担机制倒换机制倒回机制容灾效果分析对终端和其它网元要求,2.4.1 P-CSCF负荷分担机制,P-CSCF的负荷分担主要取决于UE注册时，SBC对P-CSCF的选择。SBC对P-CSCF的负荷分担选择有如下三种方式：方式一：静态配置主备用P-CSCF（同时支持配置主机名和IP地址两种方式）。方式二：基于DNS的负荷分担方式。方式三：SBC配置多个P-CSCF的主机名和静态权重，根据权重负荷分担选择P-CSCF。对三种负荷分担的方式分析：方式二的负荷分担效果较好，且数据维护简单，建议采用方式二。,2.4.2 P-CSCF倒换机制,对于正在发起注册用户的倒换流程SBC收到UE的注册请求，从P-CSCF列表中选择第一个可用的P-CSCF，向该P-CSCF发起注册请求，如果P-CSCF已宕机，就不会给SBC回响应消息，SBC就从P-CSCF地址列表中选择下一个P-CSCF，向新的P-CSCF发起注册请求。从而实现UE倒换到新的可用P-CSCF。对于已注册用户的倒换流程SBC收到UE重注册刷新请求时，转发Register到P-CSCF2，以实现UE倒换到新的可用P-CSCF。对于新发起呼叫的倒换SBC收到UE的invite请求时，检测到UE原先注册的P-CSCF1故障，返回错误消息给UE（如502），UE收到502后重新发起注册请求（需要UE功能支持）。SBC收到UE的注册请求后，转发Register到P-CSCF2，以实现UE倒换到P-CSCF2。对于被叫业务的倒换被叫侧S-CSCF收到用户发起业务请求；被叫侧S-CSCF判断主用P-CSCF1故障，将业务请求发往备用的P-CSCF2处理；备用P-CSCF2上没有用户相关接入信息，无法找到用户，因此呼叫建立失败。对于正在进行呼叫的倒换P-CSCF1故障时，正在进行的通话无法正常释放，需要通过终端的Session Timer或者周边网元的超长通话时长定时器或者周边网元的Long Call Audit机制来释放。UE收到呼叫释放的错误消息后，需要重新发起注册，由SBC倒换到P-CSCF2。,2.4.3 P-CSCF倒回机制,倒回流程当SBC检测到原故障的P-CSCF已恢复正常，就把该P-CSCF置为可用状态。SBC后续收到UE呼叫请求时，SBC从本地P-CSCF地址列表中选择第一个可用的P-CSCF，向该P-CSCF发起呼叫请求。主用P-CSCF收到呼叫并判断用户从SBC接入且没有注册，可以通过502错误码通知用户重新注册。SBC后续收到UE初始注册请求时，SBC从本地P-CSCF地址列表中选择第一个可用的P-CSCF，向该P-CSCF发起注册。从而实现UE倒回到主用P-CSCF，后续由此P-CSCF为这个UE提供服务。,2.4.4 容灾效果分析,倒换时间已注册用户的倒换最大时间，由终端的注册刷新时间确定。注册刷新时间在核心网配置，当SBC启用注册刷新过滤功能时，终端的注册刷新时间由SBC上配置的终端注册刷新时间确定。新注册用户不感知倒换过程，对业务、用户感知均无影响。倒换对业务的影响和用户感知对于主叫业务，若终端支持根据错误码进行重注册，主叫业务无影响。对于被叫业务，由于S-CSCF无法处理后续请求或者响应，呼叫建立失败。正在进行的呼叫将会损失。在用户发送重注册消息或发起主叫业务之后，因故障P-CSCF不响应，SBC倒换到备份P-CSCF，完成核心网注册过程，业务恢复正常。因此被叫业务影响时间理论上最长为终端重注册刷新时间。对计费的影响对于正在进行中的会话，由于提供服务的P-CSCF网元故障，因此没法给CCF发送终止ACR。但CCF自身有超长话单保护机制，如果CCF在一定时长内没有收到中间ACR或终止ACR，就会以之前收到的起始ACR和中间ACR生成话单，并停止计费。倒回倒回由终端发起，用户不感知，不影响业务。倒回时间取决于UE重新初始注册或发起呼叫的时间。,2.4.5 对终端和其它网元的要求,对终端的要求终端发起业务请求时，如果收到SBC返回的502错误响应，终端需要立即发起注册，以倒换到备用的P-CSCF。对SBC的要求要求SBC检测到主用P-CSCF恢复后，接收到后续终端重新注册或发起呼叫请求时，优选主用P-CSCF，以便倒回主用P-CSCF。,2.5 I/S/E-CSCF/BGCF容灾方案,I/S/E-CSCF/BGCF容灾方案无动态数据备份I/S/E-CSCF/BGCF负荷分担机制倒换机制倒回机制容灾效果分析对终端的要求I/S/E-CSCF/BGCF容灾方案支持动态数据备份I/S/E-CSCF/BGCF动态数据备份机制倒换机制倒回机制容灾效果分析对终端和其它网元的要求两种容灾方案的比较,2.5.1 负荷分担机制,I-CSCF的负荷分担机制对于I-CSCF的负荷分担主要取决于UE注册时P-CSCF对I-CSCF的选择、UE做被叫时，主叫域S-CSCF对被叫域I-CSCF的选择：（1）P-CSCF根据注册用户域名，比如“ims.省名缩写”或“ims.省名缩写.企业域名”，向DNS查询，根据DNS返回的A记录或SRV记录实现对I-CSCF的负荷分担。（2）S-CSCF根据被叫用户域名，比如“ims.省名缩写”或“ims.省名缩写.企业域名”，向DNS查询，根据DNS返回的A记录或SRV记录实现对I-CSCF的负荷分担。DNS上对用户域名的解析建议采用同局址优先的方式配置，以减少跨局址的信令交互。,2.5.1 负荷分担机制,S-CSCF的负荷分担机制对S-CSCF的负荷分担取决于UE注册时，I-CSCF对S-CSCF的选择。I-CSCF选择S-CSCF有三种方式：方式一：能力集方式HSS为I-CSCF返回S-CSCF的能力集，I-CSCF选择满足能力集要求的S-CSCF（如果多个S-CSCF都具备这些必选能力，那么选择具备最多可选能力的S-CSCF）。方式二：配置统一域名方式HSS为I-CSCF返回预先配置的S-CSCF通用域名，I-CSCF根据DNS查询选择其中一个S-CSCF。方式三：用户指定S-CSCF方式用户开户时，为每个用户指定为用户服务的特定S-CSCF。如在开户时，对于地市1、地市2的用户指定S-CSCF1，对于地市3、地市4的用户指定S-CSCF2。建议采用方式一或方式二,2.5.2 倒换机制,由于CM-IMS一期工程中，I-CSCF、S-CSCF、E-CSCF、BGCF合设为一个网元，因此发生故障时也为整体故障，下述描述均基于I/S/E-CSCF/BGCF网元整体故障的倒换倒回。对于正在发起注册用户的倒换流程P-CSCF收到用户发起初始注册/刷新注册/注销；P-CSCF判断主用I/S/E-CSCF/BGCF故障，将注册消息发往备用的I/S/E-CSCF/BGCF处理；对于已注册用户的倒换流程（重注册）P-CSCF收到UE重注册刷新请求时，判断主用I/S/E-CSCF/BGCF1故障，将重注册请求发到备用的I/S/E-CSCF/BGCF2，I-CSCF2向HSS发起UAR查询请求；HSS给I-CSCF返回UAA消息，消息携带该用户之前注册的S-CSCF设备标识；I-CSCF判断用户当前归属的S-CSCF1故障，I-CSCF向HSS重新发起UAR（查询S-CSCF能力）。HSS给I-CSCF返回UAA消息，消息携带S-CSCF能力集参数或默认的S-CSCF域名。I-CSCF将注册消息发送给的备用S-CSCF2。,2.5.2 倒换机制,对于正在发起注册用户的倒换流程P-CSCF收到用户发起初始注册/刷新注册/注销；P-CSCF判断主用I/S/E-CSCF/BGCF故障，将注册消息发往备用的I/S/E-CSCF/BGCF处理；IMS用户做被叫时，主叫S-CSCF、MGCF对被叫域I/S/E-CSCF/BGCF的倒换流程S-CSCF/MGCF收到用户发起业务请求；S-CSCF/MGCF转发请求到被叫域I-CSCF，I-CSCF查询HSS获得用户注册的S-CSCF1，I-CSCF判断被叫S-CSCF1故障I-CSCF向HSS发LIR消息请求S-CSCF能力，I-CSCF从符合能力要求的S-CSCF列表中重新选择一个，转发请求给容灾S-CSCF被叫用户未在容灾S-CSCF上注册，容灾S-CSCF无法处理请求，呼叫建立失败IMS用户发起呼叫时，P-CSCF对I/S/E-CSCF/BGCF的倒换流程P-CSCF转发呼叫请求给I/S/E-CSCF/BGCF，无响应；P-CSCF返回502错误响应给UE；UE收到502错误响应后立即发起重新注册流程，UE注册在备份I/S/E-CSCF/BGCF上，实现倒换。对于正在进行呼叫的倒换I/S/E-CSCF/BGCF故障时，正在进行的通话无法正常释放，需要通过终端的Session Timer或者周边网元的超长通话时长定时器或者周边网元的Long Call Audit机制来释放。UE收到呼叫释放的错误消息后，需要重新发起注册，倒换到备份I/S/E-CSCF/BGCF2。,2.5.3 倒回机制,主用I/S/E-CSCF/BGCF恢复后，周边网元的倒回流程如下：对于发起重新注册的用户P-CSCF收到用户发起初始注册请求；P-CSCF判断主用I/S/E-CSCF/BGCF故障恢复，将注册消息发往主用的I-CSCF处理；I-CSCF向HSS重新发起UAR（查询S-CSCF能力）；I-CSCF1选择主用S-CSCF1（合设的S-CSCF），I-CSCF将注册消息发送给的主用S-CSCF1。用户注册在主用I/S/E-CSCF/BGCF1上。对于发起重注册用户P-CSCF收到用户发起重注册请求；P-CSCF判断主用I/S/E-CSCF/BGCF故障恢复，将注册消息发往主用的I-CSCF1处理，I-CSCF1向HSS发起UAR查询请求；HSS给I-CSCF1返回UAA消息，消息携带该用户之前注册的S-CSCF2设备标识；用户仍重注册在备用的I/S/E-CSCF/BGCF2上。若故障期间用户倒换到备份I/S/E-CSCF/BGCF2，用户发起主叫业务或做被叫时仍由备用的I/S/E-CSCF/BGCF2为用户服务。,2.5.3 倒回机制,若主用I/S/E-CSCF/BGCF1故障期间，用户未发生倒换，用户发起主叫业务或做被叫时由于主用I/S/E-CSCF/BGCF1在故障恢复时可能会丢失数据，或者无法信任数据，因此I/S/E-CSCF/BGCF1无法进行后续接续，会给用户返回错误响应，取决于用户进行重新注册进行后续业务。因此在用户在备用I/S/E-CSCF/BGCF上注册成功后，即使主用I/S/E-CSCF/BGCF故障恢复，该用户的所有重注册、业务请求均在备用I/S/E-CSCF/BGCF上处理（不实施倒回）。只有当用户注销后、下次再发起初始注册时，I-CSCF会选择主用的I/S/E-CSCF/BGCF来作为该用户的归属I/S/E-CSCF/BGCF。主用I/S/E-CSCF/BGCF故障恢复后会有较长时间无法将负荷倒回主用I/S/E-CSCF/BGCF的情况，造成主备用I/S/E-CSCF/BGCF负载不均衡。,2.5.4 容灾效果分析,倒换时间已注册用户的倒换最大时间，由终端的注册刷新时间确定。若用户由接入设备（如IAD、AG、PBX等）代理接入，且接入设备下用户较活跃，则单个用户发起重注册或业务请求即可发起所有接入设备下用户的倒换，该场景下倒换时间较短。新注册用户不感知倒换过程，对业务、用户感知均无影响。倒换对业务的影响和用户感知对于主叫业务，若终端支持根据错误码进行重注册，主叫业务无影响。对于被叫业务，无法处理后续请求或者响应，呼叫建立失败。在用户发送重注册消息或发起主叫业务之后，倒换到备份I/S/E-CSCF/BGCF，业务恢复正常。因此被叫业务影响时间理论上最长为终端重注册刷新时间。正在进行的呼叫将会损失。倒回业务倒回主用I/S/E-CSCF/BGCF取决于用户重新发起初始注册。因此主用I/S/E-CSCF/BGCF故障恢复后会有较长时间无法将负荷倒回主用I/S/E-CSCF/BGCF的情况，造成主备用I/S/E-CSCF/BGCF负载不均衡。,2.5.5 对终端的需求,对终端的需求终端发起业务请求时，如果收到网络返回的502错误响应，终端需要立即发起初始注册，以倒换到备用的I/S/E-CSCF/BGCF。,2.5 I/S/E-CSCF/BGCF容灾方案,I/S/E-CSCF/BGCF容灾方案无动态数据备份I/S/E-CSCF/BGCF负荷分担机制倒换机制倒回机制容灾效果分析对终端的要求I/S/E-CSCF/BGCF容灾方案支持动态数据备份I/S/E-CSCF/BGCF动态数据备份机制倒换机制倒回机制容灾效果分析对终端和其它网元的要求两种容灾方案的比较,2.5.6 动态数据备份机制,S-CSCF动态数据备份机制该方案下，I/S/E-CSCF/BGCF的负荷分担方式与上节相同，不同的是增加了对S-CSCF上动态数据的备份：（1）在初始注册过程中，S-CSCF通过3GPP 29.228定义的SAR中Restoration-Info AVP携带容灾数据，保存在HSS中。Path中SIP PROXY的列表，如P-CSCF的IP地址Contact信息：包括Contact地址和Contact头域信息鉴权信息（2）用户重注册时，S-CSCF检查收到的注册请求中IMPI、Contact、Path信息是否和本地对应IMPI的Contact、Path信息一致，如果不一致，需要将信息更新到HSS。（3）倒换过程中容灾S-CSCF从HSS获取备份数据和签约数据以恢复用户服务。,2.5.7 倒换机制,由于CM-IMS一期工程中，I-CSCF、S-CSCF、E-CSCF、BGCF合设为一个网元，因此发生故障时也为整体故障，下述描述均基于I/S/E-CSCF/BGCF网元整体故障的倒换倒回。对于正在发起注册用户的倒换流程P-CSCF收到用户发起初始注册/刷新注册/注销；P-CSCF判断主用I/S/E-CSCF/BGCF1故障，将注册消息发往备用的I/S/E-CSCF/BGCF2处理；I-CSCF2优选本局S-CSCF2作为注册服务器，S-CSCF2从 HSS恢复用户数据，完成用户注册，同时完成HSS上容灾数据的更新。注册完成后，在容灾局进行业务处理，如同主用局一样对于用户发起流程的倒换用户发起呼叫或其他业务请求，P-CSCF无法联系Route头域中的S-CSCFP-CSCF返回502错误响应给UE；UE收到502错误响应后立即发起重新注册流程，UE注册在备份I/S/E-CSCF/BGCF上，实现倒换。,2.5.7 倒换机制,对于用户终结流程的倒换S-CSCF/MGCF收到用户发起业务请求；S-CSCF/MGCF转发请求到被叫域I-CSCF，I-CSCF查询HSS获得用户注册的S-CSCF1，I-CSCF判断被叫S-CSCF1故障I-CSCF向HSS发LIR消息请求S-CSCF能力，I-CSCF从符合能力要求的S-CSCF列表中重新选择一个，转发请求给容灾S-CSCF被叫用户未在容灾S-CSCF上注册，容灾S-CSCF向HSS发送SAR消息获取用户的注册数据和容灾数据。HSS更新用户注册的S-CSCF信息。容灾S-CSCF进行后续的业务处理。对于AS、MGCF发起流程的倒换AS或MGCF发起业务请求给S-CSCF，发现S-CSCF故障AS或MGCF重新发送业务请求给I-CSCF，I-CSCF如被叫流程一样处理，向HSS发LIR消息请求S-CSCF能力，I-CSCF从符合能力要求的S-CSCF列表中重新选择一个，转发请求给容灾S-CSCF容灾S-CSCF向HSS发送SAR消息获取用户的注册数据和容灾数据。HSS更新用户注册的S-CSCF信息。容灾S-CSCF进行后续的业务处理,2.5.8 倒回机制,倒回情况与2.5.3节“无动态备份机制”类似，在用户在备用I/S/E-CSCF/BGCF上注册成功后，即使主用I/S/E-CSCF/BGCF故障恢复，该用户的所有重注册、业务请求均在备用I/S/E-CSCF/BGCF上处理（不实施倒回）。只有当用户注销后、下次再发起初始注册时，I-CSCF会选择主用的I/S/E-CSCF/BGCF来作为该用户的归属I/S/E-CSCF/BGCF。主用I/S/E-CSCF/BGCF故障恢复后会有较长时间无法将负荷倒回主用I/S/E-CSCF/BGCF的情况，造成主备用I/S/E-CSCF/BGCF负载不均衡。不同的是，在动态备份机制下，对于主用I/S/E-CSCF/BGCF1故障期间未进行倒换的用户，其业务可以进行恢复。,2.5.8 倒回机制,若主用I/S/E-CSCF/BGCF1故障期间，用户未发生倒换，对于用户发起的流程P-CSCF根据Route中信息，将业务请求发给主用S-CSCF1由于主用I/S/E-CSCF/BGCF1在故障恢复时可能会丢失数据，或者无法信任数据，S-CSCF1发送SAR给HSS，HSS会比对S-CSCF1与存储在HSS中为用户制定的S-CSCF名是否相同若相同，则HSS返回用户注册信息，S-CSCF完成后续接续。若S-CSCF名不同，说明在S-CSCF1故障过程中，已经为用户重新指定S-CSCF，这时，HSS会返回错误信息给S-CSCF。S-CSCF返回错误码给用户，由用户重新发起注册。若主用I/S/E-CSCF/BGCF1故障期间，用户未发生倒换，对于用户终结的流程被叫域I-CSCF查询HSS获得用户注册的S-CSCF1由于主用I/S/E-CSCF/BGCF1在故障恢复时可能会丢失数据，或者无法信任数据，S-CSCF1发送SAR给HSS获取未注册业务数据，若HSS上存储有容灾数据，也同时返回给S-CSCF1。S-CSCF1根据HSS返回数据进行后续接续。,2.5.9 容灾效果分析,倒换时间倒换时间取决于网元之间SIP OPTION定时器检测时长，对业务、用户感知影响较小。倒换对业务的影响和用户感知对于主被叫业务均无影响。正在进行的呼叫将会损失。倒回业务倒回主用I/S/E-CSCF/BGCF取决于用户重新发起初始注册。因此主用I/S/E-CSCF/BGCF故障恢复后会有较长时间无法将负荷倒回主用I/S/E-CSCF/BGCF的情况，造成主备用I/S/E-CSCF/BGCF负载不均衡。,2.5.10 对CSCF的影响分析,正常注册流程的影响：根据CM-IMS一期业务模型，注册流程处理（包括重注册）占S-CSCF总性能处理约2025%，根据动态数据备份的需求，假设每次注册、重注册均需要在HSS更新数据，有动态数据备份要求情况下注册处理能力要求约为无备份要求的1.2-1.4倍，因此增加CSCF动态数据备份功能后，对CSCF的性能影响约为4%10%，影响较小，具有可实施性。S-CSCF容灾倒换场景的影响：省内多套S-CSCF中，若有一套S-CSCF故障，需要由其他S-CSCF接管业务，根据S-CSCF资源池内S-CSCF的数量不同，影响不同。即资源池内S-CSCF数量越多，对单套S-CSCF的影响越小。假设省内有N套S-CSCF，每套S-CSCF容量为A，则为保证故障倒换时不造成话务损失，每套S-CSCF冗余配置量应为A/(N-1)。,2.5.11 对HSS的影响分析,正常注册流程的影响根据CM-IMS一期业务模型，注册流程处理（包括重注册）占HSS总性能处理约20%，根据动态数据备份的需求，假设每次注册、重注册均需要在HSS更新数据，有动态数据备份要求情况下注册处理能力要求约为无备份要求的1.2-1.4倍，因此增加HSS动态数据备份功能后，对HSS的性能影响约为4%8%，影响较小。S-CSCF容灾倒换的场景的影响这个时间段内注册消息、呼叫消息均类似一个注册消息处理流程，需要CSCF重新从HSS获取数据（SAR/SAA、SNR/SNA），按照中国移动的话务模型，1个倒换用户占用的HSS性能相当于1个正常用户的180%。特定模型估算假设单套HSS容量为100万，单套S-CSCF容量为50万，若HSS负责100万用户的动态数据备份，并需承载单套S-CSCF故障的倒换则HSS配置容量为（1+8%）+50/100*（180%100%）148%。即需要增配约50%的硬件。,2.5.12 S-CSCF容灾方案比较,综合分析：若不启动CSCF的动态数据备份，在容灾效果上有一定影响。支持CSCF动态数据备份的方案倒换时间较短、用户体验较好，对I-CSCF、S-CSCF、HSS有一定的功能要求和性能影响，在投资可控的情况下，也可做为一种可选方案。,有无动态数据备份的比较：,2.6 HSS容灾方案,HSS N+1非实时备份方案方案描述数据同步要求倒换机制倒回机制容灾