CN105323792B - 移动性管理实体及其容灾方法和容灾系统 - Google Patents

Abstract

本发明公开了一种移动性管理实体及其容灾方法和容灾系统，涉及无线通信领域。本发明实施例通过当前服务的MME将用户容灾数据同步到HSS，当前服务的MME故障时，接管的MME从HSS获取用户容灾数据，进而实时恢复用户的主叫业务和被叫业务，无需等待用户重新附着到接管的MME才恢复业务，提高LTE网络的可靠性以及业务服务质量。

Description

移动性管理实体及其容灾方法和容灾系统

技术领域

本发明涉及无线通信领域，特别涉及一种移动性管理实体及其容灾方法和容灾系统。

背景技术

在长期演进(Long Term Evolution，LTE)网络中，移动性管理实体(MobilityManagement Entity，MME)设备是负责移动性管理、会话管理、用户鉴权、漫游控制以及分组数据网关(Packet Gateway，PGW)、服务网关(Service Gateway，SGW)的选择等方面功能。归属用户服务器(Home Subscriber Server，HSS)是用于存储用户签约信息的数据库，负责保存用户相关信息，包括用户标识、编号和路由信息、安全信息、位置信息和概要信息等。SGW作为演进型基站(eNodeB，eNB)和PGW之间的用户数据承载通道，完成数据包的路由和前转。PGW是作为SGW和应用服务器(AF)之间的用户数据承载通道，负责用户设备(UE)的IP(Internet Protocol，互联网协议或网际协议)地址分配、业务计费、数据包的路由和前转。eNodeB主要完成无线接入功能，包括空口资源管理功能、MME选择功能以及用户面数据调度管理等方面。

若主备MME之间容灾数据相互同步，额外消耗大量资源，同步有效性低，容灾可靠性差，所以主备MME之间不宜采用相互同步，备用接管MME不会保存当前用户容灾信息。目前MME容灾恢复流程如图1所示。对于主叫业务恢复，当用户当前服务的MME1故障，用户发起的业务请求经过eNodeB送至接管的MME2，接管的MME2由于没有容灾数据，直接拒绝用户请求，将会中断本次呼叫并指示终端发起重新附着，随后用户发起重新附着流程，在按照标准流程成功完成附着接入后，如果用户再次重新发起业务请求，接管的MME2才能完成主叫业务的处理。对于被叫业务恢复，当用户服务的MME1故障时，SGW会将下行数据请求发到一个可用的接管MME2上，同样由于接管MME2没有用户容灾数据，接管MME2将会发送请求拒绝消息给SGW，从而中断被叫业务，此时也无法通知用户进行重新附着，只能等待周期性TAU(跟踪区更新)更新，而目前按照国际规范要求，周期性TAU更新的周期大约为1个小时，那么等待大约1个小时候，周期性更新的TAU送至接管MME2，MME2由于无法向旧的MME1获取用户的上下文数据，才会发现当前服务MME故障而触发用户进行重新附着，用户附着成功后，被叫业务才能随之恢复。

目前LTE网络中MME设备集中部署，容量较大，覆盖范围广，当主用MME设备故障时，接管MME设备没有容灾数据无法实时恢复主叫和被叫业务，从而导致大面积业务长时间瘫痪，对LTE语音业务影响尤为严重。

发明内容

本发明实施例所要解决的一个技术问题是：解决当主用MME设备故障时，接管MME设备没有容灾数据无法实时恢复主叫和被叫业务的问题。

根据本发明实施例的一个方面，提出一种移动性管理实体容灾方法，包括：移动性管理实体接收到业务请求后，检测本地是否有所述业务请求相应的用户数据；响应于本地没有所述业务请求相应的用户数据的检测结果，所述移动性管理实体确定当前服务的移动性管理实体发生故障，从用户归属的归属用户服务器获取用户容灾数据；所述移动性管理实体根据所述用户容灾数据恢复用户业务。

在一个实施例中，所述归属用户服务器中的用户容灾数据是所述当前服务的移动性管理实体在用户进行初始附着时或者用户位置变化发起跟踪区更新时同步到所述归属用户服务器的。

在一个实施例中，当移动性管理实体接收到的业务请求是用户设备发起的主叫业务请求时，所述移动性管理实体根据所述用户容灾数据恢复用户业务包括：所述移动性管理实体从所述用户容灾数据中找到当前服务的服务网关信息，根据所述当前服务的服务网关信息向相应的服务网关发起修改承载流程；并根据本移动性管理实体的属性向所述用户设备发起全球唯一临时用户设备标识GUTI更新流程。

在一个实施例中，当移动性管理实体接收到的业务请求是发往用户设备的下行数据时，所述移动性管理实体根据所述用户容灾数据恢复用户业务包括：所述移动性管理实体从所述用户容灾数据中找到系统架构演进临时移动用户标识S-TMSI和跟踪区域列表TAlist，根据S-TMSI和TAlist对所述用户设备进行寻呼；并根据本移动性管理实体的属性向所述用户设备发起GUTI更新流程；从所述用户容灾数据中找到当前服务的服务网关信息，根据所述当前服务的服务网关信息向相应的服务网关发起修改承载流程。

根据本发明实施例的再一方面，提出一种用于容灾的移动性管理实体，包括：检测模块，用于接收到业务请求后，检测本地是否有所述业务请求相应的用户数据；容灾数据获取模块，用于响应于本地没有所述业务请求相应的用户数据的检测结果，确定当前服务的移动性管理实体发生故障，从用户归属的归属用户服务器获取用户容灾数据；业务恢复模块，用于根据所述用户容灾数据恢复用户业务。

在一个实施例中，所述归属用户服务器中的用户容灾数据是所述当前服务的移动性管理实体在用户进行初始附着时或者用户位置变化发起跟踪区更新时同步到所述归属用户服务器的。

在一个实施例中，当移动性管理实体接收到的业务请求是用户设备发起的主叫业务请求时，所述业务恢复模块，具体用于：从所述用户容灾数据中找到当前服务的服务网关信息，根据所述当前服务的服务网关信息向相应的服务网关发起修改承载流程；并根据本移动性管理实体的属性向所述用户设备发起全球唯一临时用户设备标识GUTI更新流程。

在一个实施例中，当移动性管理实体接收到的业务请求是发往用户设备的下行数据时，所述业务恢复模块，具体用于：从所述用户容灾数据中找到系统架构演进临时移动用户标识S-TMSI和跟踪区域列表TAlist，根据S-TMSI和TAlist对所述用户设备进行寻呼；并根据本移动性管理实体的属性向所述用户设备发起GUTI更新流程；从所述用户容灾数据中找到当前服务的服务网关信息，根据所述当前服务的服务网关信息向相应的服务网关发起修改承载流程。

根据本发明实施例的又一方面，提出一种移动性管理实体容灾系统，包括：归属用户服务器和接管的移动性管理实体；所述接管的移动性管理实体如前所述；所述归属用户服务器用于接收并存储当前服务的移动性管理实体同步的用户容灾数据，并在所述当前服务的移动性管理实体故障时根据所述接管的移动性管理实体的请求将存储的用户容灾数据发送给所述接管的移动性管理实体。

在一个实施例中，该系统还包括：当前服务的移动性管理实体，用于在用户进行初始附着时或者用户位置变化发起跟踪区更新时将用户容灾数据同步到所述归属用户服务器。

本发明实施例通过当前服务的MME将用户容灾数据同步到HSS，当前服务的MME故障时，接管的MME从HSS获取用户容灾数据，进而实时恢复用户的主叫业务和被叫业务，无需等待用户重新附着到接管的MME才恢复业务，提高LTE网络的可靠性以及业务服务质量。

通过以下参照附图对本发明的示例性实施例的详细描述，本发明的其它特征及其优点将会变得清楚。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为现有技术的MME容灾恢复流程示意图。

图2为本发明MME容灾数据备份流程示意图。

图3为本发明MME的业务容灾恢复流程示意图。

图4为本发明MME的主叫业务容灾恢复流程示意图。

图5为本发明MME的被叫业务容灾恢复流程示意图。

图6为本发明容灾系统一个实施例的结构示意图。

图7为本发明MME一个实施例的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。以下对至少一个示例性实施例的描述实际上仅仅是说明性的，决不作为对本发明及其应用或使用的任何限制。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本发明的范围。

同时，应当明白，为了便于描述，附图中所示出的各个部分的尺寸并不是按照实际的比例关系绘制的。

对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为授权说明书的一部分。

在这里示出和讨论的所有示例中，任何具体值应被解释为仅仅是示例性的，而不是作为限制。因此，示例性实施例的其它示例可以具有不同的值。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步讨论。

为了实现实时容灾恢复，本发明的容灾方案增加一个容灾数据备份流程，但不是主用MME和接管MME之间的直接同步，而是在用户进行初始附着或者基于用户位置变化的TAU更新时触发用户容灾数据同步到HSS。图2为本发明MME容灾数据备份流程示意图。如图2所示，该实施例的容灾数据备份方法包括以下步骤：

步骤S202，在用户进行初始附着时，或者用户位置变化发起TAU更新时，用户设备发起的附着请求或者TAU更新请求经由eNodeB传送至当前服务的MME1。

需要说明的是，本实施例中的TAU更新请求是基于位置变化的TAU更新，而非周期性的TAU更新，可以减少信令流量。

步骤S204，MME1完成相关处理后，发送附着接受或者TAU更新响应给用户设备。

步骤S206，针对为初始附着和基于位置变化的TAU，MME1向HSS发送数据同步请求消息，在数据同步请求消息中携带用户容灾数据，从而同步用户容灾数据。

其中，用户容灾数据例如包括用户当前的TAList(跟踪区域列表)、S-TMSI(系统架构演进临时移动用户标识)、SGW信息(如ID以及IP地址)、GUTI(全球唯一临时用户设备标识)等内容。

其中，数据同步请求及其携带的用户容灾数据例如可以通过扩展Notify(通知)消息参数实现。

步骤S208，HSS存储用户容灾数据，发送数据同步响应消息至MME1。

上述实施例，在用户进行附着请求或基于位置变化的跟踪区更新时，当前服务的MME将用户容灾数据备份到用户归属的HSS。后续，若当前服务的MME故障，接管的MME通过HSS下载用户容灾数据，从而实时恢复用户的主叫业务和被叫业务。

图3为本发明MME的业务容灾恢复流程示意图。如图3所示，本实施例的业务容灾恢复过程如下：

步骤S302，移动性管理实体接收到业务请求后，检测本地是否有业务请求相应的用户数据。

步骤S304，响应于本地没有业务请求相应的用户数据的检测结果，移动性管理实体确定当前服务的移动性管理实体发生故障，从用户归属的归属用户服务器获取用户容灾数据。

步骤S306，移动性管理实体根据用户容灾数据恢复用户业务。

上述实施例，在当前服务的MME将用户容灾数据同步到HSS后，若当前服务的MME故障，接管的MME从HSS获取用户容灾数据，进而实时恢复用户的主叫和被叫等业务，无需等待用户重新附着到接管的MME才恢复业务，提高LTE网络的可靠性以及业务服务质量。

对于MME的主叫业务容灾方案，若当前服务的MME故障，用户发起主叫业务请求会由eNodeB送到一个可用的接管MME上，此时接管MME虽然没有容灾用户数据，但是可以从HSS下载之前已经保存的用户容灾数据，同时根据接管MME属性要求用户更改GUTI值，这样接管MME不再需要先中断用户当前呼叫而触发重新附着就能实时恢复主叫业务。图4为本发明MME的主叫业务容灾恢复流程示意图。如图4所示，本实施例的主叫业务容灾恢复过程如下：

步骤S402，UE向eNodeB发送业务请求，eNodeB发现当前服务的MME1已经故障，根据数据配置选择一个可用的MME2进行业务接管，并将用户发起的业务请求转发至接管的MME2。

步骤S404，接管的MME2发现没有用户数据，向用户归属的HSS发送数据下载请求消息。

其中，数据下载请求消息例如可以通过位置更新请求UpdateLocationRequest消息实现。

步骤S406，HSS向MME2发送数据下载响应消息，携带之前保存的用户容灾数据。

其中，数据下载响应消息例如可以通过扩展位置更新响应UpdateLocationResponse相关参数消息实现，并在消息中携带用户容灾数据。

步骤S408，MME2从用户容灾数据中找到当前服务的SGW信息，并根据该信息向当前服务的SGW发起修改承载请求。

步骤S410，SGW对原有的业务承载通道相关数据进行更新，例如，更新信令面连接数据(如接管MME标识、IP、隧道端点标识符TEID)以及用户面连接数据(如eNodeB侧的IP、TEID)。

步骤S412，SGW向当前服务的PGW发送修改承载请求消息。

步骤S414，PGW对原有的业务承载通道相关数据进行更新，例如，更新信令面连接数据(如接管MME标识、IP)。

步骤S416，PGW向SGW返回修改承载响应消息。

步骤S418，SGW向MME2返回修改承载响应消息。

步骤S420，接管的MME2根据本MME2的属性对用户的GUTI值进行更新，发起更新GUTI请求，该更新GUTI请求经由eNodeB传送至UE。

步骤S422，UE返回更新GUTI响应消息。

步骤S424，MME2向用户发送业务接受消息。

上述实施例，当前服务的MME故障时，接管的MME从HSS下载之前已经保存的用户容灾数据，根据容灾数据中的SGW信息可以向SGW发起业务承载通道的修改，同时根据接管MME属性要求用户更改GUTI值，这样接管MME不再需要先中断用户当前呼叫而触发重新附着就能实时恢复主叫业务。

对于MME的被叫业务容灾方案，当前服务的MME故障时，SGW会将下行数据通知发送到一个可用的接管MME上，此时接管MME虽然没有容灾用户数据，但是通过从HSS下载之前已经保存的用户容灾数据，同时根据接管MME属性要求用户更改GUTI值，接管MME不会拒绝被叫的业务请求，这样就能实时恢复被叫业务，不再需要等待一个TAU更新周期(约一个小时)。图5为本发明MME的被叫业务容灾恢复流程示意图。如图5所示，本实施例的被叫业务容灾恢复过程如下：

步骤S502，PGW将收到的下行数据发送至用户当前服务的SGW。

步骤S504，SGW发现当前业务通道不可用时，并发现当前服务的MME1故障后，根据数据配置选择一个可用的MME2进行业务接管，将下行数据通知发送至接管的MME2。

步骤S506，MME2向SGW返回下行数据通知响应消息。

步骤S508，MME2发现没有用户容灾数据，从用户归属的HSS下载容灾数据，发送数据下载请求消息至HSS。

其中，数据下载请求例如通过UpdateLocationRequest消息实现。

步骤S510，HSS将之前保存的用户容灾数据通过数据下载响应消息送至MME2。

其中，数据下载响应例如可通过扩展UpdateLocationResponse消息相关参数实现，在消息中携带用户容灾数据。

步骤S512，MME2根据用户容灾数据中的TAlist、S-TMSI对用户设备进行寻呼，向用户设备发送寻呼请求消息。

步骤S514，用户设备向MME2发送寻呼响应消息。

步骤S516，MME2根据本MME2的属性对用户的GUTI值进行更新，发送更新GUTI请求消息至用户设备；

步骤S518，用户设备向MME2发送更新GUTI响应消息。

然后，执行步骤S520～S530，其中步骤S520～S530与步骤S408～S418相同，这里不再赘述。

步骤S532，SGW发现业务承载通道可用后将下行数据发送至用户。

上述实施例，当前服务的MME故障时，接管的MME从HSS下载之前已经保存的用户容灾数据，根据容灾数据中的TAlist、S-TMSI可以寻呼到UE，根据容灾数据中的SGW信息可以向SGW发起业务承载通道的修改，同时根据接管MME属性要求用户更改GUTI值，这样接管MME不会拒绝被叫的业务请求，无需等待一个TAU更新周期，就能实时恢复被叫业务。

图6为本发明容灾系统一个实施例的结构示意图。如图6所示，本实施例的容灾系统包括：接管的MME602、HSS604、还包括当前服务的MME606。

当前服务的MME606，用于在用户进行初始附着时或者用户位置变化发起跟踪区更新时将用户容灾数据同步到HSS604。

HSS604用于接收并存储当前服务的MME606同步的用户容灾数据，并在当前服务的MME606故障时根据接管的MME602的请求将存储的用户容灾数据发送给接管的MME602。

接管的MME602接收到业务请求后，检测本地是否有相应的用户数据，若本地没有，则当前服务的MME606发生故障，从用户归属的HSS604获取用户容灾数据，并根据用户容灾数据恢复用户业务。

其中，HSS604可以进一步细分，包括用户数据管理和容灾控制模块，其中用户数据管理模块负责归属的用户相关签约数据的管理功能，容灾控制模块负责用户容灾数据信息的存储备份和下载控制。

图7为本发明用于容灾的MME一个实施例的结构示意图。如图7所示，本实施例的MME602包括：

检测模块702，用于接收到业务请求后，检测本地是否有业务请求相应的用户数据；

容灾数据获取模块704，用于响应于本地没有业务请求相应的用户数据的检测结果，确定当前服务的移动性管理实体发生故障，从用户归属的归属用户服务器获取用户容灾数据；

业务恢复模块706，用于根据用户容灾数据恢复用户业务。

其中，归属用户服务器中的用户容灾数据是当前服务的移动性管理实体在用户进行初始附着时或者用户位置变化发起跟踪区更新时同步到归属用户服务器的。

当移动性管理实体接收到的业务请求是用户设备发起的主叫业务请求时，业务恢复模块706，具体用于：从用户容灾数据中找到当前服务的服务网关信息，根据当前服务的服务网关信息向相应的服务网关发起修改承载流程；并根据本移动性管理实体的属性向用户设备发起全球唯一临时用户设备标识GUTI更新流程。

当移动性管理实体接收到的业务请求是发往用户设备的下行数据时，业务恢复模块706，具体用于：从用户容灾数据中找到S-TMSI和TAlist，根据S-TMSI和TAlist对用户设备进行寻呼；并根据本移动性管理实体的属性向用户设备发起GUTI更新流程；从用户容灾数据中找到当前服务的服务网关信息，根据当前服务的服务网关信息向相应的服务网关发起修改承载流程。

MME602还可以包括移动性管理模块、会话管理模块。其中移动性管理负责用户附着、TAU更新的管理，会话管理模块完成用户会话创建以及触发修改业务承载。

上述实施例，在当前服务的MME将用户容灾数据同步到HSS后，若当前服务的MME故障，接管的MME从HSS获取用户容灾数据，进而实时恢复用户的主叫和被叫等业务，无需等待用户重新附着到接管的MME才恢复业务，提高LTE网络的可靠性以及业务服务质量。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (8)

1.一种移动性管理实体容灾方法，包括：

移动性管理实体接收到业务请求后，检测本地是否有所述业务请求相应的用户数据；

响应于本地没有所述业务请求相应的用户数据的检测结果，所述移动性管理实体确定当前服务的移动性管理实体发生故障，从用户归属的归属用户服务器获取用户容灾数据；

所述移动性管理实体根据所述用户容灾数据恢复用户业务；

其中，当移动性管理实体接收到的业务请求是用户设备发起的主叫业务请求时，所述移动性管理实体根据所述用户容灾数据恢复用户业务包括：

所述移动性管理实体从所述用户容灾数据中找到当前服务的服务网关信息，根据所述当前服务的服务网关信息向相应的服务网关发起修改承载流程；并根据本移动性管理实体的属性向所述用户设备发起全球唯一临时用户设备标识GUTI更新流程。

2.根据权利要求1所述的方法，其特征在于，

所述归属用户服务器中的用户容灾数据是所述当前服务的移动性管理实体在用户进行初始附着时或者用户位置变化发起跟踪区更新时同步到所述归属用户服务器的。

3.根据权利要求1所述的方法，其特征在于，当移动性管理实体接收到的业务请求是发往用户设备的下行数据时，

所述移动性管理实体根据所述用户容灾数据恢复用户业务包括：

所述移动性管理实体从所述用户容灾数据中找到系统架构演进临时移动用户标识S-TMSI和跟踪区域列表TAlist，根据S-TMSI和TAlist对所述用户设备进行寻呼；并根据本移动性管理实体的属性向所述用户设备发起GUTI更新流程；从所述用户容灾数据中找到当前服务的服务网关信息，根据所述当前服务的服务网关信息向相应的服务网关发起修改承载流程。

4.一种用于容灾的移动性管理实体，包括：

检测模块，用于接收到业务请求后，检测本地是否有所述业务请求相应的用户数据；

容灾数据获取模块，用于响应于本地没有所述业务请求相应的用户数据的检测结果，确定当前服务的移动性管理实体发生故障，从用户归属的归属用户服务器获取用户容灾数据；

业务恢复模块，用于根据所述用户容灾数据恢复用户业务；

其中，当移动性管理实体接收到的业务请求是用户设备发起的主叫业务请求时，所述业务恢复模块，具体用于：

从所述用户容灾数据中找到当前服务的服务网关信息，根据所述当前服务的服务网关信息向相应的服务网关发起修改承载流程；并根据本移动性管理实体的属性向所述用户设备发起全球唯一临时用户设备标识GUTI更新流程。

5.根据权利要求4所述的移动性管理实体，其特征在于，

所述归属用户服务器中的用户容灾数据是所述当前服务的移动性管理实体在用户进行初始附着时或者用户位置变化发起跟踪区更新时同步到所述归属用户服务器的。

6.根据权利要求4所述的移动性管理实体，其特征在于，当移动性管理实体接收到的业务请求是发往用户设备的下行数据时，

所述业务恢复模块，具体用于：

从所述用户容灾数据中找到系统架构演进临时移动用户标识S-TMSI和跟踪区域列表TAlist，根据S-TMSI和TAlist对所述用户设备进行寻呼；并根据本移动性管理实体的属性向所述用户设备发起GUTI更新流程；从所述用户容灾数据中找到当前服务的服务网关信息，根据所述当前服务的服务网关信息向相应的服务网关发起修改承载流程。

7.一种移动性管理实体容灾系统，包括：归属用户服务器和接管的移动性管理实体；

所述接管的移动性管理实体如权利要求4-6任一项所述；

所述归属用户服务器用于接收并存储当前服务的移动性管理实体同步的用户容灾数据，并在所述当前服务的移动性管理实体故障时根据所述接管的移动性管理实体的请求将存储的用户容灾数据发送给所述接管的移动性管理实体。

8.根据权利要求7所述的系统，其特征在于，还包括：当前服务的移动性管理实体，用于在用户进行初始附着时或者用户位置变化发起跟踪区更新时将用户容灾数据同步到所述归属用户服务器。