一种演进网络架构下的移动性管理方法

摘要

本发明公开了一种演进网络架构下的移动性管理方法，在确定用户设备需要进行锚点迁移时，由用户设备要迁移到的新锚点提供用于支持用户设备后续通信的通信资源，该通信资源通常是：用于支持用户设备后续通信的用户面、通信地址。本发明方法使得在移动性管理过程中不会出现现有技术中的网络传输资源浪费、通信时延增加等情况，而是使得网络传输资源得到节省、通信时延被有效减少，因而可以明显提高用户设备的通信质量，进而显著提高用户满意度。

说明书

技术领域

本发明涉及通信领域，具体涉及一种演进网络架构下的移动性管理方法。

背景技术

随着通信技术的发展，演进网络架构正在逐渐被深入研究；其中，一种被广泛接受的演进网络架构如图1所示，图1为现有技术的演进网络结构图。图1中，用户设备(UE)101可以通过长期演进无线接入网(LTE-RAN)102接入移动管理实体(Mobility Management Entity，MME)103、用户面实体(User Plane Entity，UPE)104，并与UPE 104所连接的锚点(Anchor)109通信；同理，UE 101还可以通过LTE-RAN 102接入MME 107、UPE 108，并与UPE 108所连接的Anchor109通信。

随着UE的移动，UE可能从为自身提供业务的服务区移动到另一个服务区；在这种情况下，UE有可能进行MME/UPE重选过程。针对非实时业务和实时业务而言，UE所进行的MME/UPE重选过程可能有所不同，下面通过图2、图3对MME/UPE重选过程进行简单介绍。

参见图2，图2为现有技术中针对非实时业务的MME/UPE重选过程。图2中，当接受非实时业务的UE 201从第一服务区向第二服务区移动时，UE 201在不同位置可能会接入LTE-RAN实体(Entity)1、LTE-RAN Entity2、LTE-RAN Entity 3、LTE-RAN Entity 4或LTE-RAN Entity 5。并且，在位于第一服务区时，UE 201会通过LTE-RAN Entity接入MME/UPE 202；而在位于第二服务区时，UE 201则会通过LTE-RAN Entity接入MME/UPE203。但是，无论UE 201接入的是MME/UPE 202还是MME/UPE 203，UE 201都将通过其所接入的MME/UPE固定的与原来为UE 201服务的Anchor 204通信，而不会转而与其它Anchor通信。

UE 201固定的与Anchor 204通信的情况，不可避免地会导致一些通信问题：随着UE 201的移动，Anchor 204可能不再是最有利于UE 201通信的Anchor，如：Anchor 204到UE 201的路由不再是最佳路由等；这显然会导致网络传输资源的浪费，UE 201的通信时延也会因路由变差而明显增加，使得UE 201的通信质量显著降低，进而严重降低用户满意度。

参见图3，图3为现有技术中针对实时业务的MME/UPE重选过程。图3中，当接受实时业务的UE 301从第一服务区向第二服务区移动时，UE 301在不同位置可能会接入LTE-RAN实体(Entity)1、LTE-RAN Entity 2、LTE-RAN Entity 3、LTE-RAN Entity 4或LTE-RAN Entity 5。并且，在所述实时业务尚未结束时，UE 301会始终接入于MME/UPE 302；而在所述实时业务结束并且UE 301位于第二服务区时，UE 301则会通过LTE-RAN Entity接入位于第二服务区的MME/UPE 303。但是，无论UE 301接入的是MME/UPE 302还是MME/UPE 303，UE 301都将通过其所接入的MME/UPE固定的与原来为UE 301服务的Anchor 304通信，而不会转而与其它Anchor通信。

与针对图2所阐述的问题相同，UE 301固定的与Anchor 304通信的情况不可避免地会导致一些通信问题：随着UE 301的移动，Anchor 304可能不再是最有利于UE 301通信的Anchor，如：Anchor 304到UE 301的路由不再是最佳路由等；这显然会导致网络传输资源的浪费，UE 301的通信时延也会因路由变差而明显增加，使得UE 301的通信质量显著降低，进而严重降低用户满意度。

发明内容

有鉴于此，本发明的主要目的在于提供一种演进网络架构下的移动性管理方法，以提高UE的通信质量。

为达到上述目的，本发明的技术方案是这样实现的：

本发明公开了一种演进网络架构下的移动性管理方法，该方法包括：

在确定UE需要进行Anchor迁移时，由UE要迁移到的新Anchor提供用于支持UE后续通信的通信资源。

新Anchor提供所述通信资源的方法为：

新Anchor建立用于支持UE后续通信的用户面、并为UE分配用于支持UE后续通信的通信地址。

新Anchor建立所述用户面的方法为：

新Anchor与当前为UE服务的UPE直接或间接交互，在新Anchor与该用户面实体UPE之间建立用于支持UE通信的用户面。

所述UPE是一直为UE服务的UPE，或是因发生UE位置更新而新选择的为UE提供服务的UPE。

新Anchor建立所述用户面的方法为：

向当前为UE服务的UPE发送激活会话上下文请求；新UPE根据收到的激活会话上下文请求为UE分配传输通道资源，再将该传输通道资源中的必要参数发送给新Anchor；新Anchor根据收到的所述必要参数为要新建的承载分配(网际协议)IP地址并分配数据传输通道资源。

所述必要参数是被携带于创建会话上下文请求中发送给新Anchor的。

新Anchor与所述UPE之间的交互是通过当前为UE提供服务的MME实现的。

所述MME是一直为UE提供服务的MME，或是因发生UE位置更新而新选择的为UE提供服务的MME。

确定UE需要进行Anchor迁移的方法为：

根据以静态方式预先设置的锚点迁移信息和/或以动态方式获取的锚点迁移参数来确定UE是否需要进行Anchor迁移。

根据所述锚点迁移信息确定UE是否需要进行Anchor迁移的方法为：

预先设置为UE服务的网络服务器(Network Sever)和相连的各Anchor之间的路由度量，并判断具有最优路由度量的Anchor是否为当前与UE通信的Anchor，如果是，确定UE不需要进行Anchor迁移；否则，确定UE需要进行Anchor迁移。

进一步将具有最优路由度量的Anchor确定为UE应迁移到的Anchor。

根据所述锚点迁移参数确定UE是否需要进行Anchor迁移的方法为：

获取为UE服务的Network Sever所连接的各Anchor的状态参数，并将获取的各Anchor状态参数中的一个或多个对应比较以得出状态参数占优势最多的Anchor，再判断该Anchor是否就是当前与UE通信的Anchor，并在判断结果为否时确定UE需要进行Anchor迁移。

进一步将状态参数占优势最多的所述Anchor确定为UE应迁移到的Anchor。

根据所述锚点迁移参数确定UE是否需要进行Anchor迁移的方法为：

获取为UE服务的Network Sever所连接的各Anchor的状态参数以及各Anchor与该Network Sever之间的路由度量，并判断状态参数占优势最多的Anchor与Network Sever之间的路由度量是否低于预先设置的路由度量底限，在判断结果为否时进一步判断该Anchor是否就是当前与UE通信的Anchor，并在判断结果为否时确定UE需要进行Anchor迁移。

进一步将状态参数占优势最多并且路由度量不低于路由度量底限的Anchor确定为UE应迁移到的Anchor。

根据所述锚点迁移参数确定UE是否需要进行Anchor迁移的方法为：

获得为UE服务的Network Sever所连接的各Anchor的状态参数以及各Anchor与该Network Sever之间的路由度量，判断路由度量最优的Anchor的状态参数是否优于预先设置的底限状态参数，在判断结果为是时进一步判断该Anchor是否就是当前与UE通信的Anchor，并在判断结果为否时确定UE需要进行Anchor迁移。

进一步将路由度量最优并且状态参数优于底限状态参数的Anchor确定为UE应迁移到的Anchor。

该方法所包含的操作是由UE发起的位置区更新过程所触发的。

进一步向HSS发起UE位置更新过程。

触发该方法所包含操作的是所述位置区更新过程中，由UE发送的位置区更新请求。

所述Anchor是第三代合作组织锚点，或是互通接入系统锚点。

进一步删除UE进行Anchor迁移之前为UE服务的Anchor所保存的UE上下文。

在新Anchor提供所述通信资源之前，该方法进一步包括：针对UE进行认证鉴权过程。

进一步为UE建立用于支持后续通信的无线接入承载。

所述通信资源包括作为通信地址的IP地址，进一步将该IP地址通过为UE建立的所述无线接入承载发送给UE。

所述通信地址是IP地址，进一步将该IP地址携带于位置区更新接受消息中发送给UE。

UE进一步应用所述IP地址向上层服务网络注册。

所述上层服务网络是网际协议多媒体子系统、MSN或网络内容服务网络。

与现有技术相比，本发明所提供的演进网络架构下的移动性管理方法，在确定UE需要进行Anchor迁移时，由UE要迁移到的新Anchor提供用于支持UE后续通信的通信资源，该通信资源通常是：用于支持UE后续通信的用户面、通信地址。可见，本发明方法可以明显提高UE的通信质量，进而显著提高用户满意度。

附图说明

图1为现有技术的演进网络结构图；

图2为现有技术中针对非实时业务的MME/UPE重选过程；

图3为现有技术中针对实时业务的MME/UPE重选过程；

图4为本发明的移动性管理流程简图；

图5为本发明的另一移动性管理流程简图；

图6为本发明实施例1的移动性管理流程图；

图7为本发明实施例2的移动性管理流程图；

图8为本发明实施例3的移动性管理流程图；

图9为本发明实施例4的移动性管理流程图；

图10为本发明实施例5的移动性管理流程图；

图11为本发明实施例6的移动性管理流程图；

图12为本发明实施例7的移动性管理流程图；

图13为本发明实施例8的移动性管理流程图；

图14为本发明实施例9的移动性管理流程图；

图15为本发明实施例10的移动性管理流程图；

图16为本发明实施例11的移动性管理流程图；

图17为本发明实施例12的移动性管理流程图；

图18为本发明实施例13的移动性管理流程图。

具体实施方式

下面结合附图及具体实施例对本发明详细说明。

本发明所提供的演进网络架构下的移动性管理方法，在确定UE需要进行Anchor迁移时，由UE要迁移到的新Anchor提供用于支持UE后续通信的通信资源，该通信资源通常是：用于支持UE后续通信的用户面、通信地址。

参见图4，图4为本发明的移动性管理流程简图，该流程包括以下步骤：

步骤401：UE应用现有技术发起位置区更新；并且，接入网络为UE选择新Network Sever。

具体而言，UE通常以向接入网络发送位置区更新请求的方式发起位置区更新；接入网络则可以应用目前使用比较广泛的Flex原则为UE选择新Network Sever。

步骤402：旧Network Sever向新Network Sever转移针对UE的上下文(Context)。

具体而言，新Network Sever可以从来自UE的位置区更新请求中获得UE发起位置区更新之前所处位置区的标识，并根据该标识查找到UE发起本次位置区更新前所注册的旧Network Sever的地址。基于此，新NetworkSever向旧Network Sever发送针对UE的Context转移请求，该请求中包含UE的分组-临时移动用户标识(P-TMSI)、UE所处位置区的标识(Track AreaIdentifier)、临时逻辑链路标识(Temporary Logical Link Identity，TLLI)、新Network Sever地址等参数；旧Network Sever收到来自新Network Sever的Context转移请求时，将UE的Context发送给新Network Sever。

步骤403：新Network Sever通过逻辑判断，确定UE需要进行Anchor迁移。

在实际应用中，新Network Sever可以根据以静态方式预先设置的锚点迁移信息和/或以动态方式获取的锚点迁移参数来确定UE是否需要进行Anchor迁移。

针对所述静态方式而言，可以在新Network Sever中预先设置该NetworkSever及其相连的各Anchor之间的路由度量；这样，新Network Sever就可以确定与自身具有最优路由度量的Anchor，并判断该Anchor是否为当前与UE通信的Anchor，如果是，新Network Sever确定UE不需要进行Anchor迁移；否则，新Network Sever确定UE需要进行Anchor迁移，并将具有最优路由度量的Anchor确定为UE应迁移到的Anchor。

针对所述动态方式而言，新Network Sever可以实时性或周期性地获取与自身相连的各Anchor的状态参数，如：系统资源负载状况、UE连接数目、链路资源负载状况等，并将获取的各Anchor状态参数中的一个或多个对应比较以得出状态参数占优势最多的Anchor，将该Anchor确定为最有利于UE通信的Anchor，再判断该Anchor是否就是当前与UE通信的Anchor，如果是，新Network Sever确定UE不需要进行Anchor迁移；否则，新NetworkSever确定UE需要进行Anchor迁移，并且确定状态参数占优势最多的所述Anchor是UE应迁移到的Anchor。

当然，除了上述的Anchor状态参数以外，新Network Sever也可以将自身及所连接的各Anchor之间的路由度量考虑在内，如：新Network Sever获取各Anchor的状态参数以及自身与各Anchor之间的路由度量，在得出状态参数占优势最多的Anchor时判断该Anchor与新Network Sever之间的路由度量是否低于预先设置的路由度量底限，并且只在判断结果为不低于时将该Anchor确定为最有利于UE通信的Anchor，再进一步判断该Anchor是否就是当前与UE通信的Anchor，如果是，新Network Sever确定UE不需要进行Anchor迁移；否则，新Network Sever确定UE需要进行Anchor迁移，并确定状态参数占优势最多并且路由度量不低于路由度量底限的Anchor是UE应迁移到的Anchor。

另外，当新Network Sever获得各Anchor的状态参数以及自身与各Anchor之间的路由度量时，还可以选择路由度量最优的Anchor并判断该Anchor的状态参数是否优于预先设置的底限状态参数，并且只在判断结果为是时将该Anchor确定为最有利于UE通信的Anchor，再进一步判断该Anchor是否就是当前与UE通信的Anchor，如果是，新Network Sever确定UE不需要进行Anchor迁移；否则，新Network Sever确定UE需要进行Anchor迁移，并确定路由度量最优并且状态参数优于底限状态参数的Anchor是UE应迁移到的Anchor。

在实际应用中，所述路由度量可以是预先配置的，也可以是新Network Sever通过路由协议所获取到的；并且，在确定UE是否需要进行Anchor迁移以及迁移到哪个Anchor的操作中，路由度量通常是非常重要的参数。

由以上所述可以明显看出，新Network Sever通常将所述最有利于UE通信的Anchor确定为UE需要迁移到的新Anchor；相对而言，当前与UE通信的Anchor则被认为是旧Anchor。

步骤404：在确定UE需要进行Anchor迁移后，可以进一步在UE、新Network Sever甚至进一步与归属用户服务器(HSS)之间进行目前比较常见的认证鉴权过程；这样做通常是出于安全原因考虑，比如：当UE的密钥已失效时，为了保证通信安全，就需要进行所述认证鉴权过程。

当然，在实际应用中，也可以不进行所述认证鉴权过程，而是默认可以为UE提供服务，进而直接进入步骤405。

步骤405：新Network Sever请求新Anchor为UE分配新的用户面和业务层地址，新Anchor收到来自新Network Sever的请求时为UE分配新的用户面和业务层地址。所述业务层地址通常为网际协议(IP)地址。

具体而言，新Network Sever向新Anchor发送包含UE Context的用户面分配请求；新Anchor收到来自新Network Sever的用户面分配请求时，根据该请求中包含的UE Context为UE建立相应的用户面信息，并为UE分配业务层地址。分配所述业务层地址的操作可以通过查询域名解析系统(DNS)服务器等多种方式进行。

为UE建立好用户面信息后，新Network Sever与新Anchor之间既建立好了用以支持UE通信的连接关系。

步骤406：新Network Sever请求旧Anchor删除针对UE的旧用户面。

具体而言，新Network Sever向旧Anchor发送包含UE Context的用户面删除请求；旧Anchor收到来自新Network Sever的用户面删除请求时，删除曾为UE建立的用户面信息。这样，新Network Sever与旧Anchor之间就不再存在用以支持UE通信的连接关系了。

步骤407：新Network Sever通知HSS UE发生了位置区更新。

具体而言，新Network Sever向HSS发送针对UE的位置更新消息，HSS收到该位置更新消息时向旧Network Sever发送针对UE的位置取消消息；旧Network Sever收到来自HSS的位置取消消息时，删除存储的UE的位置信息并向HSS返回位置取消确认消息，HSS收到该位置取消确认消息时将UE的签约数据发送给新Network Sever；新Network Sever根据收到的UE签约数据为UE创建新的Context，并向HSS发送插入用户数据确认消息；HSS收到该插入用户数据确认消息时，向新Network Sever返回位置更新确认消息。

步骤408：新Network Sever将新Anchor为UE所分配的业务层地址通知UE。

具体而言，新Network Sever获得新Anchor为UE所分配的所述业务层地址，并将该业务层地址携带于位置区更新接受消息中发送给UE。在实际应用，新Network Sever可能还为UE分配了一些新的参数，如：P-TMSI、新位置区标识(TAI)等。新Network Sever可以将这些参数及新的用户IP地址携带于所述位置区更新接受消息中或是其它消息格式中发送给UE。

步骤409：UE收到来自新Network Sever的业务层地址后，使用该业务层地址应用现有技术向上层服务网络注册；以使上层服务网络获知UE被新分配的该业务层地址，保证上层服务网络后续能应用该业务层地址与UE正常通信。

以上流程中，步骤405和步骤406之间没有明显的时间先后顺序，可以先执行步骤405或步骤406，也可以同时执行步骤405和步骤406。

由图4可见，当UE发起位置区更新时，有可能会为UE选择新NetworkSever以支持UE通信；该新Network Sever能够确定UE是否需要进行Anchor迁移以及应迁移到哪个Anchor，还能请求UE要迁移到的新Anchor为UE建立新的用户面以及为UE分配业务层地址，以便UE能够应用新分配的业务层地址进行后续的上层服务网络注册等操作，保证上层服务网络后续能应用该业务层地址与UE正常通信。

当然，如果新Network Sever确定UE不需要进行Anchor迁移，那么后续涉及到新Anchor的操作就都无须执行了，而只是应用现有技术进行UE的位置区更新操作即可。

显然，图4所示流程能够尽量保证将UE迁移到当前最有利于通信的Anchor，这样不仅不会出现现有技术中所发生的网络传输资源浪费、UE通信时延增加等问题，还能明显节省网络传输资源并且能有效减少UE通信时延，使得UE的通信质量显著提高，进而明显提高用户满意度。

参见图5，图5为本发明的另一移动性管理流程简图，该流程包括以下步骤：

步骤501：UE应用现有技术发起位置区更新，但接入网络并没有为UE选择新Network Sever。

步骤502：当前为UE提供服务的Network Sever通过逻辑判断，确定UE需要进行Anchor迁移。

在实际应用中，Network Sever可以根据以静态方式预先设置的锚点迁移信息和/或以动态方式获取的锚点迁移参数来确定UE是否需要进行Anchor迁移。

针对所述静态方式而言，可以在Network Sever中预先设置该NetworkSever及其相连的各Anchor之间的路由度量；这样，Network Sever就可以确定与自身具有最优路由度量的Anchor，并判断该Anchor是否为当前与UE通信的Anchor，如果是，Network Sever确定UE不需要进行Anchor迁移；否则，Network Sever确定UE需要进行Anchor迁移，并将具有最优路由度量的Anchor确定为UE应迁移到的Anchor。

针对所述动态方式而言，Network Sever可以实时性或周期性地获取与自身相连的各Anchor的状态参数，如：系统资源负载状况、UE连接数目、链路资源负载状况等，并将获取的各Anchor状态参数中的一个或多个对应比较以得出状态参数占优势最多的Anchor，将该Anchor确定为最有利于UE通信的Anchor，再判断该Anchor是否就是当前与UE通信的Anchor，如果是，Network Sever确定UE不需要进行Anchor迁移；否则，Network Sever确定UE需要进行Anchor迁移，并且确定状态参数占优势最多的所述Anchor是UE应迁移到的Anchor。

当然，除了上述的Anchor状态参数以外，Network Sever也可以将自身及所连接的各Anchor之间的路由度量考虑在内，如：Network Sever获取各Anchor的状态参数以及自身与各Anchor之间的路由度量，在得出状态参数占优势最多的Anchor时判断该Anchor与Network Sever之间的路由度量是否低于预先设置的路由度量底限，并且只在判断结果为不低于时将该Anchor确定为最有利于UE通信的Anchor，再进一步判断该Anchor是否就是当前与UE通信的Anchor，如果是，Network Sever确定UE不需要进行Anchor迁移；否则，Network Sever确定UE需要进行Anchor迁移，并确定状态参数占优势最多并且路由度量不低于路由度量底限的Anchor是UE应迁移到的Anchor。

另外，当Network Sever获得各Anchor的状态参数以及自身与各Anchor之间的路由度量时，还可以选择路由度量最优的Anchor并判断该Anchor的状态参数是否优于预先设置的底限状态参数，并且只在判断结果为是时将该Anchor确定为最有利于UE通信的Anchor，再进一步判断该Anchor是否就是当前与UE通信的Anchor，如果是，Network Sever确定UE不需要进行Anchor迁移；否则，Network Sever确定UE需要进行Anchor迁移，并确定路由度量最优并且状态参数优于底限状态参数的Anchor是UE应迁移到的Anchor。

在实际应用中，所述路由度量可以是预先配置的，也可以是NetworkSever通过路由协议所获取到的；并且，在确定UE是否需要进行Anchor迁移以及迁移到哪个Anchor的操作中，路由度量通常是非常重要的参数。

由以上所述可以明显看出，Network Sever通常将所述最有利于UE通信的Anchor确定为UE需要迁移到的新Anchor；相对而言，当前与UE通信的Anchor则被认为是旧Anchor。

步骤503：在确定UE需要进行Anchor迁移后，可以进一步在UE、Network Sever甚至进一步与HSS之间进行目前比较常见的认证鉴权过程。

当然，在实际应用中，也可以不进行所述认证鉴权过程，而是直接进入步骤504。

步骤504：Network Sever请求新Anchor为UE分配新的用户面和业务层地址，新Anchor收到来自Network Sever的请求时为UE分配新的用户面和业务层地址。本步骤的操作方法与步骤405的相应操作方法相同。

为UE建立好用户面信息后，Network Sever与新Anchor之间既建立好了用以支持UE通信的连接关系。

步骤505：Network Sever请求旧Anchor删除针对UE的旧用户面。具体的删除方法与步骤406中的相应删除方法相同。

完成本步骤后，Network Sever与旧Anchor之间就不再存在用以支持UE通信的连接关系了。

步骤506：Network Sever将新Anchor为UE所分配的业务层地址通知UE。具体的通知方法与步骤408中的相应通知方法相同。

步骤507：UE收到来自Network Sever的业务层地址后，使用该业务层地址应用现有技术向上层服务网络注册。具体的注册方法与步骤409中的相应注册方法相同。

以上流程中，步骤504和步骤505之间没有明显的时间先后顺序，可以先执行步骤504或步骤505，也可以同时执行步骤504和步骤505。

由图5可见，当UE发起位置区更新时，有可能不为UE选择新NetworkSever而是仍沿用当前为UE服务的Network Sever；该Network Sever能够确定UE是否需要进行Anchor迁移以及应迁移到哪个Anchor，还能请求UE要迁移到的新Anchor为UE建立新的用户面以及为UE分配业务层地址，以便UE能够应用新分配的业务层地址进行后续的上层服务网络注册等操作，保证上层服务网络后续能应用该业务层地址与UE正常通信。

当然，如果所述Network Sever确定UE不需要进行Anchor迁移，那么后续涉及到新Anchor的操作就都无须执行了，而只是应用现有技术进行UE的位置区更新操作即可。

显然，图5所示流程能够尽量保证将UE迁移到当前最有利于通信的Anchor，这样不仅不会出现现有技术中所发生的网络传输资源浪费、UE通信时延增加等问题，还能明显节省网络传输资源并且能有效减少UE通信时延，使得UE的通信质量显著提高，进而明显提高用户满意度。

需要说明的是，图4、图5中的Network Sever可以是合为一个逻辑实体的MME/UPE，也可以是在MME、UPE分离为两个逻辑实体情况下的MME，或者是其它能为UE提供通信服务的通信实体。图4、图5中的Anchor可以是第三代合作组织锚点(3GPP Anchor)，也可以是互通接入系统锚点(Inter Access System Anchor，IASA)等；并且，图4、图5的Anchor中还可以设置有UPE实体；再有，图4、图5中的网际协议多媒体子系统(IMS)只是所述上层服务网络中的一种，该上层服务网络也可以是MSN或网络内容服务网络等。

纵观图4、图5可知，图4与图5所示流程的区别只在于是否为发起位置区更新的UE选择了新Network Sever；然而，无论是否为发起位置区更新的UE选择了新Network Sever，UE都能尽量迁移到当前最有利于通信的Anchor，使得UE的通信质量显著提高，进而明显提高用户满意度。

图4、图5只是对本发明的移动性管理方法进行了原则性的概括说明，在实际应用中，由于Network Sever可以是合为一个逻辑实体的MME/UPE，也可以是在MME、UPE分离情况下的MME，再加上移动性管理过程中有可能为UE选择新Network Sever，即：重选MME和或UPE；这会使得不同情况下的移动性管理过程不尽相同；因此，下面通过大量实施例对不同情况下的移动性管理过程进行详细描述，以尽量清楚、详尽地阐述本发明移动性管理方法的具体操作细节。需要说明的是，虽然是否重选MME和或UPE以及MME、UPE是否合为一个逻辑实体能够使移动性管理过程发生一定的变化，但不同通信实体针对相同的消息结构所进行的操作通常没有多大变化。

实施例1：MME和UPE合为一个逻辑实体MME/UPE，并且重选MME/UPE；

参见图6，图6为本发明实施例1的移动性管理流程图，该流程包括以下步骤：

步骤601：要进行位置区更新的UE向其所在的位置区中的新MME/UPE发送位置区更新请求(TAU Request)，该更新请求中包括P-TMSI、UE发起位置区更新之前所处的位置区的标识(old TAI)、更新类型(Update Type)等参数。

通常，UE可以因进入了一个新的位置区而进行位置区更新，也可以只是周期性地进行位置区更新。

步骤602：新MME/UPE根据收到的TAU Request中的old TAI，查询到UE发起位置区更新之前所注册的旧MME的地址，并根据该地址向旧MME发送针对UE的上下文请求(Context request)。所述Context request中包含一些必要的信息，如：P-TMSI，oldTAI，TLLI，新MME地址等。

步骤603：旧MME/UPE将UE的Context携带于上下文响应(Contextresponse)中发送给新MME/UPE。

步骤604：新MME/UPE通过逻辑判断，确定UE需要进行Anchor迁移。

步骤605：在确定UE需要进行Anchor迁移后，新MME/UPE可以进一步与UE、甚至与HSS之间针对UE进行目前比较常见的认证鉴权过程。

当然，在实际应用中，也可以不进行所述认证鉴权过程，而是直接进入步骤606。

步骤606：新MME/UPE收到来自旧MME/UPE的Context response后，可以进一步向旧MME/UPE返回上下文转移确认消息(contextAcknowledge)。在实际应用，也可以不进行本步骤操作，而是直接进入步骤607。

步骤607：新MME/UPE向UE要迁移到的新Anchor发送携带有UEContext的建立用户面上下文请求(Create context request)，并请求新Anchor为UE分配新IP地址。

步骤608：新Anchor收到来自新MME/UPE的Create context request时，根据该请求中包含的UE Context为UE建立相应的用户面信息，并为UE分配新IP地址；之后，还将为UE建立的用户面信息和分配的所述IP地址发送给新MME/UPE。所述用户面信息和IP地址均可以被携带于建立用户面上下文响应(Create context response)中发送给新MME/UPE。

步骤609：新MME/UPE向旧MME/UPE发送针对UE的删除用户上下文请求(Delete PDP context request)。

步骤610：旧MME/UPE将来自新MME/UPE的Delete PDP contextrequest发送给UE发起位置区更新之前与UE通信的旧Anchor。

步骤611：旧Anchor收到旧MME/UPE所转发的Delete PDP contextrequest时删除存储的UE Context，并向旧MME/UPE返回删除用户上下文响应(Delete PDP context response)。

步骤612：旧MME/UPE将来自旧Anchor的Delete PDP context response发送给新MME/UPE。

步骤613：新MME/UPE向HSS发送位置更新(Update location)消息，该消息中可能包括UE的国际移动用户识别码(IMSI)、取消类型(Cancellation Type)等。

步骤614：HSS向旧MME/UPE发送针对UE的位置取消(Cancellocation)请求。

步骤615：旧MME/UPE收到来自HSS的Cancel location请求时删除所存储的UE位置信息，并向HSS返回位置取消确认(Cancel location Ack)。

步骤616至步骤618：HSS将UE的签约数据携带于插入用户数据(InsertSubscriber Data)请求中发送给新MME/UPE；新MME/UPE收到来自HSS的Insert Subseriber Data请求时确认UE已位于新的位置区，并为UE创建新的context，还向HSS返回插入用户数据确认(Insert Subscriber Data Ack)消息；HSS收到来自新MME/UPE的Insert Subscriber Data Ack消息后，向新MME/UPE返回位置更新确认(Update location Ack)消息。

步骤619：新MME/UPE将新Anchor为UE建立的用户面信息和分配的IP地址发送UE。所述用户面信息和IP地址可以被携带于位置区更新接受(TA update accept)消息中发送给UE，所述用户面信息可能包括针对UE的新P-TMSI、新TAI等。

步骤620：UE收到来自新MME/UPE的IP地址后，向新MME/UPE返回位置区更新完成(TA update Complete)消息。

步骤621：UE根据收到的所述用户面信息和IP地址配置自身的IP层面相关参数，并使用所述IP地址应用现有技术向IMS等上层服务网络注册。

实施例2：MME和UPE合为一个逻辑实体MME/UPE，并且未重选MME/UPE；

参见图7，图7为本发明实施例2的移动性管理流程图，该流程包括以下步骤：

步骤701：要进行位置区更新的UE向一直为其服务的MME/UPE发送TAU Request。

步骤702：MME/UPE通过逻辑判断，确定UE需要进行Anchor迁移。

步骤703：在确定UE需要进行Anchor迁移后，MME/UPE可以进一步与UE、甚至与HSS之间针对UE进行目前比较常见的认证鉴权过程。

当然，在实际应用中，也可以不进行所述认证鉴权过程，而是直接进入步骤704。

步骤704：MME/UPE向UE要迁移到的新Anchor发送Create contextrequest，并请求新Anchor为UE分配新IP地址。

步骤705：新Anchor收到来自MME/UPE的Create context request时为UE建立相应的用户面信息，并为UE分配新IP地址；之后，还将为UE建立的用户面信息和分配的所述IP地址发送给MME/UPE。所述用户面信息和IP地址均可以被携带于Create context response中发送给MME/UPE。

步骤706：MME/UPE向旧Anchor发送针对UE的Delete PDP contextrequest。

步骤707：旧Anchor收到来自MME/UPE的Delete PDP context request时删除存储的UE Context，并向MME/UPE返回Delete PDP context response。

步骤708：MME/UPE将新Anchor为UE建立的用户面信息和分配的IP地址发送UE。所述用户面信息和IP地址可以被携带于TA update accept消息中发送给UE。

步骤709：UE收到来自MME/UPE的IP地址后，向MME/UPE返回TAupdate Complete消息。

步骤710：UE根据收到的所述用户面信息和IP地址配置自身的IP层面相关参数，并使用所述IP地址应用现有技术向IMS等上层服务网络注册。

实施例3：MME、UPE分离为两个逻辑实体，UPE和Anchor合为一个逻辑实体UPE/Anchor；并且，重选MME；

参见图8，图8为本发明实施例3的移动性管理流程图，该流程包括以下步骤：

步骤801：要进行位置区更新的UE向其所在的位置区中的新MME发送TAU Request。

步骤802：新MME根据收到的TAU Request向旧MME发送针对UE的Context request。

步骤803：旧MME将UE的Context携带于Context response中发送给新MME。

步骤804：新MME通过逻辑判断，确定UE需要进行Anchor迁移。

步骤805：在确定UE需要进行Anchor迁移后，新MME可以进一步与UE、甚至与HSS之间针对UE进行目前比较常见的认证鉴权过程。

当然，在实际应用中，也可以不进行所述认证鉴权过程，而是直接进入步骤806。

步骤806：新MME收到来自旧MME的Context response后，可以进一步向旧MME返回context Acknowledge。在实际应用，也可以不进行本步骤操作，而是直接进入步骤807。

步骤807：新MME向UE要迁移到的新UPE/Anchor发送Create contextrequest，并请求新UPE/Anchor为UE分配新IP地址。

步骤808：新UPE/Anchor收到来自新MME的Create context request时为UE建立相应的用户面信息，并为UE分配新IP地址；之后，还将为UE建立的用户面信息和分配的所述IP地址发送给新MME。所述用户面信息和IP地址均可以被携带于Create context response中发送给新MME。

步骤809：新MME通知旧UPE/Anchor删除UE Context。

具体的删除操作通常为：新MME向旧MME发送针对UE的Delete PDPcontext request；旧MME将来自新MME的Delete PDP context request发送给旧UPE/Anchor；旧UPE/Anchor收到旧MME所转发的Delete PDP contextrequest时删除存储的UE Context，并向旧MME返回Delete PDP contextresponse；旧MME将来自旧UPE/Anchor的Delete PDP context response发送给新MME。

步骤810：新MME向HSS发送Update location消息。

步骤811：HSS向旧MME发送针对UE的Cancellocation请求。

步骤812：旧MME收到来自HSS的Cancellocation请求时删除所存储的UE位置信息，并向HSS返回Cancellocation Ack。

步骤813至步骤815：HSS将UE的签约数据携带于Insert Subscriber Data请求中发送给新MME；新MME收到来自HSS的Insert Subscriber Data请求时确认UE已位于新的位置区，并为UE创建新的context，还向HSS返回Insert Subscriber Data Ack消息；HSS收到来自新MME的Insert SubscriberData Ack消息后，向新MME返回Update location Ack消息。

步骤816：新MME将新UPE/Anchor为UE建立的用户面信息和分配的IP地址发送UE。所述用户面信息和IP地址可以被携带于TA update accept消息中发送给UE。

步骤817：UE收到来自新MME的IP地址后，向新MME返回TA updateComplete消息。

步骤818：UE根据收到的所述用户面信息和IP地址配置自身的IP层面相关参数，并使用所述IP地址应用现有技术向IMS等上层服务网络注册。

实施例4：MME、UPE分离为两个逻辑实体，UPE和Anchor合为一个逻辑实体UPE/Anchor；并且，未重选MME；

参见图9，图9为本发明实施例4的移动性管理流程图，该流程包括以下步骤：

步骤901：要进行位置区更新的UE向一直为其服务的MME发送TAURequest。

步骤902：MME通过逻辑判断，确定UE需要进行Anchor迁移。

步骤903：在确定UE需要进行Anchor迁移后，MME可以进一步与UE、甚至与HSS之间针对UE进行目前比较常见的认证鉴权过程。

当然，在实际应用中，也可以不进行所述认证鉴权过程，而是直接进入步骤904。

步骤904：MME向UE要迁移到的新UPE/Anchor发送Create contextrequest，并请求新UPE/Anchor为UE分配新IP地址。

步骤905：新UPE/Anchor收到来自MME的Create context request时为UE建立相应的用户面信息，并为UE分配新IP地址；之后，还将为UE建立的用户面信息和分配的所述IP地址发送给MME。所述用户面信息和IP地址均可以被携带于Create context response中发送给MME。

步骤906：MME向旧UPE/Anchor发送针对UE的Delete PDP contextrequest。

步骤907：旧UPE/Anchor收到来自MME的Delete PDP context request时删除存储的UE Context，并向MME返回Delete PDP context response。

步骤908：MME将新UPE/Anchor为UE建立的用户面信息和分配的IP地址发送UE。所述用户面信息和IP地址可以被携带于TA update accept消息中发送给UE。

步骤909：UE收到来自MME的IP地址后，向MME返回TA updateComplete消息。

步骤910：UE根据收到的所述用户面信息和IP地址配置自身的IP层面相关参数，并使用所述IP地址应用现有技术向IMS等上层服务网络注册。

实施例5：MME、UPE、Anchor分别分离为三个逻辑实体，并且重选MME；

参见图10，图10为本发明实施例5的移动性管理流程图，该流程包括以下步骤：

步骤1001：要进行位置区更新的UE向其所在的位置区中的新MME发送TAU Request。

步骤1002：新MME根据收到的TAU Request向旧MME发送针对UE的Context request。

步骤1003：旧MME将UE的Context携带于Context response中发送给新MME。

步骤1004：新MME通过逻辑判断，确定UE需要进行Anchor迁移。

步骤1005：在确定UE需要进行Anchor迁移后，新MME可以进一步与UE、甚至与HSS之间针对UE进行目前比较常见的认证鉴权过程。

当然，在实际应用中，也可以不进行所述认证鉴权过程，而是直接进入步骤1006。

步骤1006：新MME收到来自旧MME的Context response后，可以进一步向旧MME返回context Acknowledge。在实际应用，也可以不进行本步骤操作，而是直接进入步骤1007。

步骤1007：新MME与UE要迁移到的新Anchor交互，由新Anchor为UE建立新的用户面并分配新的IP地址。

具体操作为：新MME向新Anchor发送Create context request，并请求新Anchor为UE分配新IP地址；新Anchor收到来自新MME的Create contextrequest时为UE建立相应的用户面信息，并为UE分配新IP地址，还将为UE建立的用户面信息和分配的所述IP地址发送给新MME。所述用户面信息和IP地址均可以被携带于Create context response中发送给新MME。

步骤1008：新MME通知旧Anchor删除UE Context。

具体的删除操作通常为：新MME向旧MME发送针对UE的Delete PDPcontext request；旧MME将来自新MME的Delete PDP context request发送给旧Anchor；旧Anchor收到旧MME所转发的Delete PDP context request时删除存储的UE Context，并向旧MME返回Delete PDP context response；旧MME将来自旧Anchor的Delete PDP context response发送给新MME。

步骤1009：新MME向HSS发送Update location消息。

步骤1010：HSS向旧MME发送针对UE的Cancel location请求。

步骤1011：旧MME收到来自HSS的Cancel location请求时删除所存储的UE位置信息，并向HSS返回Cancel location Ack。

步骤1012至步骤1014：HSS将UE的签约数据携带于Insert SubscriberData请求中发送给新MME；新MME收到来自HSS的Insert Subscriber Data请求时确认UE已位于新的位置区，并为UE创建新的context，还向HSS返回Insert Subscriber Data Ack消息；HSS收到来自新MME的InsertSubscriber Data Ack消息后，向新MME返回Update location Ack消息。

步骤1015：新MME将新Anchor为UE建立的用户面信息和分配的IP地址发送UE。所述用户面信息和IP地址可以被携带于TA update accept消息中发送给UE。

步骤1016：UE收到来自新MME的IP地址后，向新MME返回TA updateComplete消息。

步骤1017：UE根据收到的所述用户面信息和IP地址配置自身的IP层面相关参数，并使用所述IP地址应用现有技术向IMS等上层服务网络注册。

实施例6：MME、UPE、Anchor分别分离为三个逻辑实体，并且未重选MME、UPE；

参见图11，图11为本发明实施例6的移动性管理流程图，该流程包括以下步骤：

步骤1101：要进行位置区更新的UE向一直为其服务的MME发送TAURequest。

步骤1102：MME通过逻辑判断，确定UE需要进行Anchor迁移。

步骤1103：在确定UE需要进行Anchor迁移后，MME可以进一步与UE、甚至与HSS之间针对UE进行目前比较常见的认证鉴权过程。

当然，在实际应用中，也可以不进行所述认证鉴权过程，而是直接进入步骤1104。

步骤1104：MME与UE要迁移到的新Anchor交互，由新Anchor为UE建立新的用户面并分配新的IP地址。

具体操作为：MME向新Anchor发送Create context request，并请求新Anchor为UE分配新IP地址；新Anchor收到来自MME的Create contextrequest时为UE建立相应的用户面信息，并为UE分配新IP地址，还将为UE建立的用户面信息和分配的所述IP地址发送给MME。所述用户面信息和IP地址均可以被携带于Create context response中发送给MME。

步骤1105：MME通知旧Anchor删除UE Context。

具体的删除操作通常为：MME向旧Anchor发送针对UE的Delete PDPcontext request；旧Anchor收到来自MME的Delete PDP context request时删除存储的UE Context，并向MME返回Delete PDP context response。

步骤1106：MME将新Anchor为UE建立的用户面信息和分配的IP地址发送UE。所述用户面信息和IP地址可以被携带于TA update accept消息中发送给UE。

步骤1107：UE收到来自MME的IP地址后，向MME返回TA updateComplete消息。

步骤1108：UE根据收到的所述用户面信息和IP地址配置自身的IP层面相关参数，并使用所述IP地址应用现有技术向IMS等上层服务网络注册。

实施例7：MME、UPE、Anchor分别分离为三个逻辑实体；重选MME并且发生UPE迁移；

参见图12，图12为本发明实施例7的移动性管理流程图，该流程包括以下步骤：

步骤1201：要进行位置区更新的UE向其所在的位置区中的新MME发送TAU Request。

步骤1202：新MME根据收到的TAU Request向旧MME发送针对UE的Context request。

步骤1203：旧MME将UE的Context携带于Context response中发送给新MME。

步骤1204：新MME通过逻辑判断，确定UE需要进行Anchor迁移。

步骤1205：在确定UE需要进行Anchor迁移后，新MME可以进一步与UE、甚至与HSS之间针对UE进行目前比较常见的认证鉴权过程。

当然，在实际应用中，也可以不进行所述认证鉴权过程，而是直接进入步骤1206。

步骤1206：新MME收到来自旧MME的Context response后，可以进一步向旧MME返回context Acknowledge。在实际应用，也可以不进行本步骤操作，而是直接进入步骤1207。

步骤1207：新MME选择将要为UE服务的新UPE，并与UE要迁移到的新Anchor交互，由新Anchor为UE建立新的用户面并分配新的IP地址。具体而言，新MME选择所述新UPE的方法有多种，如：新MME获取各UPE的负载，并确定负载最轻的UPE是要为UE服务的新UPE；或者，新MME获取各UPE与UE之间的路由度量，并根据获取的路由度量确定与UE之间路由最优的UPE是要为UE服务的新UPE。

当然，新MME也可以将所述UPE负载和路由度量综合考虑，如：新MME获取各UPE的负载并选出负载最轻的UPE，再获取该UPE与UE之间的路由度量并判断获取的路由度量是否低于预先设置的路由度量底限，并且只在判断结果为不低于时确定该UPE是要为UE服务的新UPE；或者，新MME获取各UPE与UE之间的路由度量并根据获取的路由度量选出与UE之间路由最优的UPE，再获取该UPE的负载并判断获取的负载是否高于预先设置的负载上限，并且只在判断结果为不高于时确定该UPE是要为UE服务的新UPE。

步骤1208：新MME通知旧Anchor删除UE Context。本步骤操作与步骤1008的操作相同。

步骤1209：新MME向HSS发送Update location消息。

步骤1210：HSS向旧UPE发送针对UE的Cancellocation请求。

步骤1211：旧UPE收到来自HSS的Cancellocation请求时删除所存储的UE位置信息，并向HSS返回Cancellocation Ack。

步骤1212至步骤1214：HSS将UE的签约数据携带于Insert SubscriberData请求中发送给新MME；新MME收到来自HSS的Insert Subscriber Data请求时确认UE已位于新的位置区，并为UE创建新的context，还向HSS返回Insert Subscriber Data Ack消息；HSS收到来自新MME的InsertSubscriber Data Ack消息后，向新MME返回Update location Ack消息。

步骤1215：新MME将新Anchor为UE建立的用户面信息和分配的IP地址发送UE。所述用户面信息和IP地址可以被携带于TA update accept消息中发送给UE。

步骤1216：UE收到来自新MME的IP地址后，向新MME返回TA updateComplete消息。

步骤1217：UE根据收到的所述用户面信息和IP地址配置自身的IP层面相关参数，并使用所述IP地址应用现有技术向IMS等上层服务网络注册。

图12中所描述的选择新UPE的方法也可以应用于其它流程图中，只要该流程图中有操作涉及到将要为UE提供服务的新UPE即可。

实施例8：MME、UPE、Anchor分别分离为三个逻辑实体；未重选MME并且发生UPE迁移；

参见图13，图13为本发明实施例8的移动性管理流程图，该流程包括以下步骤：

步骤1301：要进行位置区更新的UE向一直为其服务的MME发送TAURequest。

步骤1302：MME通过逻辑判断，确定UE需要进行Anchor迁移。

步骤1303：在确定UE需要进行Anchor迁移后，MME可以进一步与UE、甚至与HSS之间针对UE进行目前比较常见的认证鉴权过程。

当然，在实际应用中，也可以不进行所述认证鉴权过程，而是直接进入步骤1304。

步骤1304：MME选择将要为UE服务的新UPE，并与UE要迁移到的新Anchor交互，由新Anchor为UE建立新的用户面并分配新的IP地址。

步骤1305：MME通知旧Anchor删除UE Context。

步骤1306：MME将新Anchor为UE建立的用户面信息和分配的IP地址发送UE。所述用户面信息和IP地址可以被携带于TA update accept消息中发送给UE。

步骤1307：UE收到来自MME的IP地址后，向MME返回TA updateComplete消息。

步骤1308：UE根据收到的所述用户面信息和IP地址配置自身的IP层面相关参数，并使用所述IP地址应用现有技术向IMS等上层服务网络注册。

在上述的图6至图13中，当出现重选MME、UPE的情况时，无论MME是否与UPE合为一个逻辑实体，都可以在涉及到新Anchor删除UE Context的流程中，进一步由旧MME、旧UPE删除所保存的UE Context。

再有，MME与新Anchor交互使新Anchor为UE建立用户面并分配IP地址的操作，通常是通过UPE进行的；该UPE是一直为UE服务的UPE，或是选择的要为UE服务的新UPE。具体而言，MME需要通过所述UPE请求新Anchor为UE建立用户面并分配IP地址，所述用户面通常是指该UPE与新Anchor之间用以支持UE通信的用户面，建立该用户面通常需要UPE与新Anchor进行通信交互和协商；并且，要发送给UE的用户面信息和IP地址一般也是通过UPE转发给MME后再发送给UE的。

在实际应用中，当MME、UPE、Anchor分别分离为三个逻辑实体时，还可以进行图14至图18所示流程。

具体而言，图14至图18中有可能出现重选MME和或UPE的情况，这使得不同情况下的移动性管理过程不尽相同，甚至出现不同通信实体均可针对相同的消息结构进行逻辑操作的情况；但需要说明的是，不同通信实体针对相同的消息结构所进行的操作通常没有多大变化。

实施例9：发生UPE迁移但未重选MME；

参见图14，图14为本发明实施例9的移动性管理流程图，该流程包括以下步骤：

步骤1401：UE向LTE-RAN发送TAU Request，LTE-RAN在该TAURequest的消息头中增加UE当前所在的位置区标识后发送给一直为UE服务的MME。

步骤1402：MME与UE进行目前比较常见的安全认证过程，所述安全认证过程与之前所述的认证鉴权过程类似，都是为了确定UE是否有资格接受服务。

当然，在实际应用中，也可以不进行所述安全认证过程，而是默认可以为UE提供服务，进而直接进入步骤1403。

步骤1403：MME通过逻辑判断，确定UE需要进行Anchor迁移，进而向旧Anchor发送携带有UE标识的删除会话上下文请求(Delete SessionContext Request)。

步骤1404：旧Anchor收到来自MME的Delete Session Context Request时，根据其中所包含的UE标识释放UE占用的资源，之后向MME发送删除会话上下文响应(Delete Session Context Response)。UE占用的所述资源通常包括IP地址和数据通道资源等。

步骤1405：MME选择将要为UE服务的新UPE，并向旧UPE发送携带有UE标识的去激活会话上下文请求(Deactivate Session Context Request)。

步骤1406：旧UPE收到来自MME的Deactivate Session Context Request时，根据其中所包含的UE标识释放为UE所分配的用户面资源，并向MME返回去激活会话上下文响应(Deactivate Session Context Response)。

步骤1407：MME向新UPE发送激活会话上下文请求(Activate SessionContext Request)，该请求中包含UE标识、服务质量(QoS)、UE能力、加密密钥等。

步骤1408：新UPE收到来自MME的Activate Session Context Request时，根据其中所包含的UE能力和自身所支持的加密算法选择将要使用的加密算法，并根据Activate Session Context Request所包含的QoS为UE分配传输通道资源，再将该传输通道资源和选择的所述加密算法等参数携带于激活会话上下文响应(Activate Session Context Response)中发送给MME。

以通用分组无线服务隧道协议(GTP)隧道为例，为UE分配的所述传输通道资源通常包括新UPE接收来自新Anchor的下行数据时所使用的IP地址、端口和隧道端标识(TEID)，还包括新UPE接收来自LTE-RAN的上行数据时所使用的IP地址、端口和TEID。

步骤1409：MME保存Activate Session Context Response中所包含的参数，并向新Anchor发送创建会话上下文请求(Create Session ContextRequest)；该请求中通常携带有UE标识、建立承载所要求的QoS、新UPE为接收新Anchor的下行数据所分配的通道标识等参数。

以GTP隧道为例，Create Session Context Request中所携带的参数包括：新UPE接收新Anchor的下行数据时所使用的IP地址、端口和TEID。

步骤1410：新Anchor收到来自MME的Create Session Context Request时为要新建的承载分配IP地址，并根据Create Session Context Request中的QoS分配数据传输通道资源，再将分配的所述IP地址和数据传输通道资源携带于创建会话上下文响应(Create Session Context Response)中发送给MME。Create Session Context Response中通常包含分配的所述IP、新Anchor所能允许的QoS和分配的所述数据传输通道资源等。

以GTP隧道为例，Create Session Context Response中所携带的参数包括：新Anchor通过新建的所述承载接收来自新UPE的上行数据所使用的IP地址、端口和TEID。

步骤1411：MME保存来自新Anchor的Create Session Context Response中所包含的参数，应用现有技术向LTE-RAN发起无线接入承载建立过程，把收到的QoS和新UPE为接收来自LTE-RAN上行数据所分配的数据通道资源标识通知给LTE-RAN。

以GTP隧道为例，新UPE为接收来自LTE-RAN上行数据所分配的数据通道资源标识通常是：新UPE通过新建的所述承载接收来自LTE-RAN的上行数据时所使用的IP地址、端口和TEID。

LTE-RAN根据来自MME的QoS应用现有技术和UE协商，完成空口承载建立；并为接收来自新UPE的下行数据分配数据通道资源，还将协商成功的QoS和分配的所述下行数据通道资源标识返回给MME。

以GTP隧道为例，所述下行数据通道资源标识通常为：LTE-RAN为接收来自新UPE的下行数据所使用的IP地址、端口和TEID。

步骤1412：MME保存LTE-RAN返回的协商成功的QoS和分配的所述下行数据通道资源标识等信息，并将最终确定的QoS、LTE-RAN为接收来自新UPE的下行数据所分配的所述数据通道资源标识携带于更新会话上下文(Update Session Context)消息中，再将该消息发送给新UPE。

以GTP隧道为例，LTE-RAN为接收来自新UPE的下行数据所分配的所述数据通道资源标识通常为：LTE-RAN为接收来自新UPE的下行数据所使用的IP地址、端口和TEID。

在上述操作的某个步骤中，新Anchor还要为UE分配用于进行后续通信的新IP地址，并将该IP地址通知给MME。

步骤1413：MME向UE发送TA Update Accept消息，该消息包含新Anchor为UE分配的IP地址、为支持UE通信而建立的承载所对应的IP地址、新UPE指定的终端使用的数据加密算法、新的用户临时身份标识等。

步骤1414：UE向MME返回TA Update Complete消息，通知MME收到了新分配的IP地址和用户身份临时标识等参数。

UE收到为其分配的IP地址后，使用该IP地址应用现有技术初始化IP链路层。至此，UE就可以顺利地与新Anchor通信了。

当然，UE可以进一步应用现有技术进行在IMS等上层服务网络中的注册过程。

可见，实施例9中，创建或删除IP承载的操作都是由MME控制的，UPE和Anchor之间没有进行涉及创建IP承载的信令交互。

在实际应用中，也可以像实施例10那样，通过UPE和Anchor之间所进行交互来完成IP承载的建立或释放。

参见图15，图15为本发明实施例10的移动性管理流程图，该流程包括以下步骤：

步骤1501：UE通过LTE-RAN向一直为UE服务的MME发送TAURequest。

步骤1502：MME与UE进行目前比较常见的安全认证过程。当然，在实际应用中，也可以不进行所述安全认证过程，而是直接进入步骤1503。

步骤1503：MME通过逻辑判断，确定UE需要进行Anchor迁移；MME还选择将要为UE服务的新UPE，并向旧UPE发送Deactivate Session ContextRequest。

步骤1504：旧UPE收到来自MME的Deactivate Session Context Request时释放为UE所分配的用户面资源，还向旧Anchor发送Delete SessionContext Request。

步骤1505：旧Anchor收到来自旧UPE的Delete Session Context Request时释放UE占用的资源，之后向旧UPE发送Delete Session Context Response。

步骤1506：旧UPE收到来自旧Anchor的Deactivate Session ContextRequest时向MME发送Deactivate Session Context Response。

步骤1507：MME收到来自旧UPE的Deactivate Session Context Response时，向新UPE发送Activate Session Context Request。

步骤1508：新UPE收到来自MME的Activate Session Context Request时为UE分配传输通道资源并进行加密算法选择等操作；并且，新UPE向新Anchor发送Create Session Context Request。

步骤1509：新Anchor收到来自新UPE的Create Session Context Request时，为要新建的承载分配IP地址并分配数据传输通道资源，再将分配的所述IP地址和数据传输通道资源携带于Create Session Context Response中发送给新UPE。

步骤1510：新UPE收到来自新Anchor的Create Session Context Response时保存其中包含的参数，并将曾为UE分配的所述传输通道资源、加密算法等参数携带于Activate Session Context Response中发送给MME。

步骤1511：MME保存来自新UPE的Activate Session Context Response中所包含的参数，并应用现有技术向LTE-RAN发起无线接入承载建立过程。

步骤1512：MME保存与LTE-RAN建立承载相关的参数，并将这些参数携带于Update Session Context消息中发送给新UPE。

在上述操作的某个步骤中，新Anchor还要为UE分配用于进行后续通信的新IP地址，并将该IP地址通知给MME。

步骤1513：MME向UE发送至少包含新分配的IP地址的TA UpdateAccept消息。

步骤1514：UE向MME返回TA Update Complete消息，通知MME收到了新分配的IP地址等参数。

UE收到为其分配的IP地址后，使用该IP地址应用现有技术初始化IP链路层。至此，UE就可以顺利地与新Anchor通信了。

当然，UE可以进一步应用现有技术进行在IMS等上层服务网络中的注册过程。

由以上所述可见，图14和图15的关键区别就在于创建IP承载的方法不同。

在实际应用中，创建和删除IP承载之间的时间顺序可以和图14、图15中的相应顺序有所区别，如实施例11所示。

参见图16，图16为本发明实施例11的移动性管理流程图，该流程包括以下步骤：

步骤1601：UE通过LTE-RAN向一直为UE服务的MME发送TAURequest。

步骤1602：MME与UE进行目前比较常见的安全认证过程。当然，在实际应用中，也可以不进行所述安全认证过程，而是直接进入步骤1603。

步骤1603：MME通过逻辑判断，确定UE需要进行Anchor迁移；MME还选择将要为UE服务的新UPE，并向新UPE发送Activate Session ContextRequest。

步骤1604：新UPE收到来自MME的Activate Session Context Request时选择将要使用的加密算法并为UE分配传输通道资源，再将该传输通道资源和选择的所述加密算法等参数携带于Activate Session Context Response中发送给MME。

步骤1605：MME保存Activate Session Context Response中所包含的参数，并向新Anchor发送Create Session Context Request。

步骤1606：新Anchor收到来自MME的Create Session Context Request时为要新建的承载分配IP地址并分配数据传输通道资源，再将分配的所述IP地址和数据传输通道资源携带于Create Session Context Response中发送给MME。

步骤1607：MME保存来自新Anchor的Create Session Context Response中所包含的参数，并应用现有技术向LTE-RAN发起无线接入承载建立过程。

步骤1608：MME保存与LTE-RAN建立承载相关的参数，并将这些参数携带于Update Session Context消息中发送给新UPE。

步骤1609：MME向旧Anchor发送Delete Session Context Request。

步骤1610：旧Anchor收到来自MME的Delete Session Context Request时释放UE占用的资源，之后向MME发送Delete Session Context Response。

步骤1611：MME向旧UPE发送Deactivate Session Context Request。

步骤1612：旧UPE收到来自MME的Deactivate Session Context Request时释放为UE所分配的用户面资源，并向MME返回Deactivate SessionContext Response。

步骤1613：MME向UE发送至少包含新分配的IP地址的TA UpdateAccept消息。

步骤1614：UE向MME返回TA Update Complete消息，通知MME收到了新分配的IP地址等参数。

UE收到为其分配的IP地址后，使用该IP地址应用现有技术初始化IP链路层。至此，UE就可以顺利地与新Anchor通信了。

当然，UE可以进一步应用现有技术进行在IMS等上层服务网络中的注册过程。

实施例12：发生UPE迁移并且重选MME；

图17为本发明实施例12的移动性管理流程图，该流程包括以下步骤：

步骤1701：UE向LTE-RAN发送TAU Request，LTE-RAN选择要为UE服务的新MME，并在收到的TAU Request的消息头中增加UE当前所在的位置区标识后发送给新MME。

步骤1702：新MME根据收到的TAU Request中的位置区标识，查询到UE发起位置区更新之前所注册的旧MME的地址，并根据该地址向旧MME发送针对UE的Context request。并且，新MME通过逻辑判断确定UE需要进行Anchor迁移，新MME还选择将要为UE服务的新UPE。

步骤1703：旧MME将UE的Context携带于Context response中发送给新MME。

步骤1704：新MME与UE进行目前比较常见的安全认证过程。当然，在实际应用中，也可以不进行所述安全认证过程，而是直接进入步骤1705。

步骤1705：新MME针对UE与HSS应用现有技术进行位置更新过程。

具体操作通常为：新MME向HSS发送针对UE的Update location消息；HSS向旧MME发送针对UE的Cancel location请求；旧MME收到来自HSS的Cancel location请求时删除所存储的UE位置信息，并向HSS返回Cancellocation Ack；之后，HSS将UE的签约数据携带于Insert Subscriber Data请求中发送给新MME；新MME收到来自HSS的Insert Subscriber Data请求时确认UE已位于新的位置区，并为UE创建新的context，还向HSS返回Insert Subscriber Data Ack消息；HSS收到来自新MME的Insert SubscriberData Ack消息后，向新MME返回Update location Ack消息。

在图14至图16中，新MME也可以针对UE与HSS进行上述位置更新过程。

步骤1706：旧MME在收到来自HSS的Cancel location请求时，向UE发起位置区更新之前为UE服务的旧UPE发送Deactivate Session ContextRequest。

步骤1707：旧UPE收到来自旧MME的Deactivate Session ContextRequest时释放为UE所分配的用户面资源，并向旧MME返回DeactivateSession Context Response。

步骤1708：新MME向UE在发起位置区更新之前与UE通信的旧Anchor发送Delete Session Context Request。

步骤1709：旧Anchor收到来自MME的Delete Session Context Request时释放UE占用的资源，之后向MME新发送Delete Session ContextResponse。

步骤1710：新MME向新UPE发送Activate Session Context Request。

步骤1711：新UPE收到来自新MME的Activate Session Context Request时选择将要使用的加密算法并为UE分配传输通道资源，再将该传输通道资源和选择的所述加密算法等参数携带于Activate Session Context Response中发送给新MME。

步骤1712：新MME保存Activate Session Context Response中所包含的参数，并向新Anchor发送Create Session Context Request。

步骤1713：新Anchor收到来自新MME的Create Session Context Request时为要新建的承载分配IP地址并分配数据传输通道资源，再将分配的所述IP地址和数据传输通道资源携带于Create Session Context Response中发送给新MME。

步骤1714：新MME保存来自新Anchor的Create Session ContextResponse中所包含的参数，并应用现有技术向LTE-RAN发起无线接入承载建立过程。

步骤1715：新MME保存与LTE-RAN建立承载相关的参数，并将这些参数携带于Update Session Context消息中发送给新UPE。

在上述操作的某个步骤中，新Anchor还要为UE分配用于进行后续通信的新IP地址，并将该IP地址通知给新MME。

步骤1716：新MME向UE发送至少包含新分配的IP地址的TA UpdateAccept消息。

步骤1717：UE向新MME返回TA Update Complete消息，通知新MME收到了新分配的IP地址等参数。

UE收到为其分配的IP地址后，使用该IP地址应用现有技术初始化IP链路层。至此，UE就可以顺利地与新Anchor通信了。

当然，UE可以进一步应用现有技术进行在IMS等上层服务网络中的注册过程。

实施例13：UPE未迁移并且未重选MME；

参见图18，图18为本发明实施例13的移动性管理流程图，该流程包括以下步骤：

步骤1801：UE通过LTE-RAN向一直为UE服务的MME发送TAURequest。

步骤1802：MME与UE进行目前比较常见的安全认证过程。当然，在实际应用中，也可以不进行所述安全认证过程，而是直接进入步骤1803。

步骤1803：MME通过逻辑判断确定UE需要进行Anchor迁移，并向UE发起位置区更新之前与UE通信的旧Anchor发送Delete Session ContextRequest。

步骤1804：旧Anchor收到来自MME的Delete Session Context Request时释放UE占用的资源，之后向MME发送Delete Session Context Response。

步骤1805：MME向UPE发送Deactivate Session Context Request。

步骤1806：UPE收到来自MME的Deactivate Session Context Request时释放为UE所分配的用户面资源，并向MME返回Deactivate SessionContext Response。

步骤1807：MME向UPE发送Activate Session Context Request。

步骤1808：UPE收到来自MME的Activate Session Context Request时选择将要使用的加密算法并为UE分配传输通道资源，再将该传输通道资源和选择的所述加密算法等参数携带于Activate Session Context Response中发送给MME，以保证所述传输通道资源和所述加密算法能支持UE更新位置区后所进行的正常通信过程。

步骤1809：MME保存Activate Session Context Response中所包含的参数，并向新Anchor发送Create Session Context Request。

步骤1810：新Anchor收到来自MME的Create Session Context Request时为要新建的承载分配IP地址并分配数据传输通道资源，再将分配的所述IP地址和数据传输通道资源携带于Create Session Context Response中发送给MME。

步骤1811：MME保存来自新Anchor的Create Session Context Response中所包含的参数，并应用现有技术向LTE-RAN发起无线接入承载建立过程。

步骤1812：MME保存与LTE-RAN建立承载相关的参数，并将这些参数携带于Update Session Context消息中发送给UPE。

在上述操作的某个步骤中，新Anchor还要为UE分配用于进行后续通信的新IP地址，并将该IP地址通知给MME。

步骤1813：MME向UE发送至少包含新分配的IP地址的TA UpdateAccept消息。

步骤1814：UE向MME返回TA Update Complete消息，通知MME收到了新分配的IP地址等参数。

UE收到为其分配的IP地址后，使用该IP地址应用现有技术初始化IP链路层。至此，UE就可以顺利地与新Anchor通信了。

当然，UE可以进一步应用现有技术进行在IMS等上层服务网络中的注册过程。

图18中，MME还可以针对UE与HSS应用现有技术进行位置更新过程。

实际上，在图6至图13中，同样要执行图14至图18中所示的无线接入承载建立过程；图6至图13中没有标明该无线接入承载建立过程，只是因为该过程不是图6至图13所要描述的关键部分。在实际应用中，也可以在所述无线接入承载建立过程完成时，将为UE分配的所述IP地址通过建立的该无线接入承载发送给UE。

由以上所述的图4、图5所示的移动性管理简要流程、以及图6至图18的各实施例可以知道，无论是否重选MME、是否迁移UPE以及MME、UPE、Anchor中的至少两个通信实体是否合为一个逻辑实体，本发明的移动性管理方法可以为UE选择最有利于通信的Anchor；这保证UE后续与该Anchor通信时不会出现现有技术中的网络传输资源浪费、通信时延增加等情况，而是使得网络传输资源得到节省、通信时延被有效减少，因而可以明显提高UE的通信质量，进而显著提高用户满意度。

需要说明的是：以上所描述的选择最有利于通信的Anchor的操作都是由UE所发起的位置区更新操作来触发的；在实际应用中，也可以周期性触发或者因为UE的激活状态与空闲状态之间的转换而触发。

由以上所述可以看出，本发明所提供的演进网络架构下的移动性管理方法，可以明显提高UE的通信质量，进而显著提高用户满意度。