]除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本发明的范围。
[0028]同时，应当明白，为了便于描述，附图中所示出的各个部分的尺寸并不是按照实际的比例关系绘制的。
[0029]对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为授权说明书的一部分。
[0030]在这里示出和讨论的所有示例中，任何具体值应被解释为仅仅是示例性的，而不是作为限制。因此，示例性实施例的其它示例可以具有不同的值。
[0031]应注意到:相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步讨论。
[0032]为了实现实时容灾恢复，本发明的容灾方案增加一个容灾数据备份流程，但不是主用MME和接管MME之间的直接同步，而是在用户进行初始附着或者基于用户位置变化的TAU更新时触发用户容灾数据同步到HSS。图2为本发明MME容灾数据备份流程示意图。如图2所示，该实施例的容灾数据备份方法包括以下步骤:
[0033]步骤S202，在用户进行初始附着时，或者用户位置变化发起TAU更新时，用户设备发起的附着请求或者TAU更新请求经由eNodeB传送至当前服务的MME1。
[0034]需要说明的是，本实施例中的TAU更新请求是基于位置变化的TAU更新，而非周期性的TAU更新，可以减少信令流量。
[0035]步骤S204，MME1完成相关处理后，发送附着接受或者TAU更新响应给用户设备。
[0036]步骤S206，针对为初始附着和基于位置变化的TAU，MME1向HSS发送数据同步请求消息，在数据同步请求消息中携带用户容灾数据，从而同步用户容灾数据。
[0037]其中，用户容灾数据例如包括用户当前的TAList(跟踪区域列表)、S-TMSI (系统架构演进临时移动用户标识)、SGW信息(如ID以及IP地址)、⑶TI (全球唯一临时用户设备标识)等内容。
[0038]其中，数据同步请求及其携带的用户容灾数据例如可以通过扩展Notify (通知)消息参数实现。
[0039]步骤S208，HSS存储用户容灾数据，发送数据同步响应消息至MME1。
[0040]上述实施例，在用户进行附着请求或基于位置变化的跟踪区更新时，当前服务的MME将用户容灾数据备份到用户归属的HSS。后续，若当前服务的MME故障，接管的MME通过HSS下载用户容灾数据，从而实时恢复用户的主叫业务和被叫业务。
[0041]图3为本发明MME的业务容灾恢复流程示意图。如图3所示，本实施例的业务容灾恢复过程如下:
[0042]步骤S302，移动性管理实体接收到业务请求后，检测本地是否有业务请求相应的用户数据。
[0043]步骤S304，响应于本地没有业务请求相应的用户数据的检测结果，移动性管理实体确定当前服务的移动性管理实体发生故障，从用户归属的归属用户服务器获取用户容灾数据。
[0044]步骤S306，移动性管理实体根据用户容灾数据恢复用户业务。
[0045]上述实施例，在当前服务的MME将用户容灾数据同步到HSS后，若当前服务的MME故障，接管的MME从HSS获取用户容灾数据，进而实时恢复用户的主叫和被叫等业务，无需等待用户重新附着到接管的MME才恢复业务，提高LTE网络的可靠性以及业务服务质量。
[0046]对于MME的主叫业务容灾方案，若当前服务的MME故障，用户发起主叫业务请求会由eNodeB送到一个可用的接管MME上，此时接管MME虽然没有容灾用户数据，但是可以从HSS下载之前已经保存的用户容灾数据，同时根据接管MME属性要求用户更改GUTI值，这样接管MME不再需要先中断用户当前呼叫而触发重新附着就能实时恢复主叫业务。图4为本发明MME的主叫业务容灾恢复流程示意图。如图4所示，本实施例的主叫业务容灾恢复过程如下:
[0047]步骤S402, UE向eNodeB发送业务请求，eNodeB发现当前服务的MME1已经故障，根据数据配置选择一个可用的MME2进行业务接管，并将用户发起的业务请求转发至接管的 MME2。
[0048]步骤S404，接管的MME2发现没有用户数据，向用户归属的HSS发送数据下载请求消息。
[0049]其中，数据下载请求消息例如可以通过位置更新请求UpdateLocat1nRequest消息实现。
[0050]步骤S406，HSS向MME2发送数据下载响应消息，携带之前保存的用户容灾数据。
[0051]其中，数据下载响应消息例如可以通过扩展位置更新响应UpdateLocat1nResponse相关参数消息实现,并在消息中携带用户容灾数据。
[0052]步骤S408，MME2从用户容灾数据中找到当前服务的SGW信息，并根据该信息向当前服务的SGW发起修改承载请求。
[0053]步骤S410，SGW对原有的业务承载通道相关数据进行更新，例如，更新信令面连接数据(如接管MME标识、IP、隧道端点标识符TEID)以及用户面连接数据(如eNodeB侧的IP、TEID)。
[0054]步骤S412，SGW向当前服务的PGW发送修改承载请求消息。
[0055]步骤S414，PGW对原有的业务承载通道相关数据进行更新，例如，更新信令面连接数据(如接管MME标识、IP)。
[0056]步骤S416，PGW向SGW返回修改承载响应消息。
[0057]步骤S418，SGW向MME2返回修改承载响应消息。
[0058]步骤S420，接管的MME2根据本MME2的属性对用户的GUTI值进行更新，发起更新⑶TI请求,该更新⑶TI请求经由eNodeB传送至UE。
[0059]步骤S422，UE返回更新⑶TI响应消息。
[0060]步骤S424，MME2向用户发送业务接受消息。
[0061]上述实施例，当前服务的MME故障时，接管的MME从HSS下载之前已经保存的用户容灾数据，根据容灾数据中的SGW信息可以向SGW发起业务承载通道的修改，同时根据接管MME属性要求用户更改GUTI值，这样接管MME不再需要先中断用户当前呼叫而触发重新附着就能实时恢复主叫业务。
[0062]对于MME的被叫业务容灾方案，当前服务的MME故障时，SGW会将下行数据通知发送到一个可用的接管MME上，此时接管MME虽然没有容灾用户数据，但是通过从HSS下载之前已经保存的用户容灾数据，同时根据接管MME属性要求用户更改GUTI值，接管MME不会拒绝被叫的业务请求，这样就能实时恢复被叫业务，不再需要等待一个TAU更新周期(约一个小时)。图5为本发明MME的被叫业务容灾恢复流程示意图。如图5所示，本实施例的被叫业务容灾恢复过程如下:
[0063]步骤S502，PGW将收到的下行数据发送至用户当前服务的SGW。
[0064]步骤S504，SGW发现当前业务通道不可用时，并发现当前服务的MME1故障后，根据数据配置选择一个可用的MME2进行业务接管，将下行数据通知发送至接管的MME2。
[0065]步骤S506，MME2向SGW返回下行数据通知响应消息。
[0066]步骤S508，MME2发现没有用户容灾数据，从用户归属的HSS下载容灾数据，发送数据下载请求消息至HSS。
[0067]其中，数据下载请求例如通过UpdateLocat1nRequest消息实现。
[0068]步骤S510，HSS将之前保存的用户容灾数据通过数据下载响应消息送至MME2。
[0069]其中，数据下载响应例如可通过扩展UpdateLocat1nResponse消息相关参数实现，在消息中携带用户容灾数据。
[0070]步骤S512，MME2根据用户容灾数据中的TAlist、S-TMSI对用户设备进行寻呼，向用户设备发送寻呼请求消息。
[0071]步骤S514，用户设备向MME2发送寻呼响应消息。
[0072]步骤S516，MME2根据本MME2的属性对用户的⑶TI值进行更新，发送更新⑶TI请求消息至用户设备；
[0073]步骤S518，用户设备向MME2发送更新⑶TI响应消息。
[0074]然后，执行步骤S520?S530，其中步骤S520?S530与步骤S408?S418相同，这里不再赘述。
[0075]步骤S532，SGW发现业务承载通道可用后将下行数据发送至用户。
[0076]上述实施例，当前服务的MME故障时，接管的MME从HSS下载之前