云原生5G移动系统中的服务弹性

摘要

一方面，为了应对移动数据流量的巨大增长，另一方面，每用户平均收入增长有限，移动运营商一直在探索网络虚拟化和云计算技术，以构建成本效益高且具有弹性的移动网络，并将其作为云服务提供。在这种基于云的移动网络中，确保服务弹性是一个重要的挑战。事实上，高可用性和服务可靠性是运营商级别的关键要求，但并不一定是云计算的固有特性。因此，在一个可能无法始终保证高可靠性的平台上构建需要达到五个九的可靠性的系统，是一项重大难题。实际上，在运营商云中，运行在虚拟机（VM）上的任何网络功能（NF）发生故障都可能严重影响服务弹性。本文提出了一种框架以及高效且主动的恢复机制，以确保运营商云中的服务弹性。由于网络功能故障的恢复会影响潜在数量的用户，本文还提出了适当的网络过载控制机制。我们建立了一个数学模型，用于评估所提机制的性能。获得的结果令人鼓舞，表明所提出的机制能够高效地实现其设计目标。

一、引言

5G移动网络架构的一个重要愿景是在虚拟化平台上实现移动网络的按需创建，并将其作为云服务进行管理和提供，从而充分利用云计算所带来的诸多优势，例如服务弹性、按需使用和按使用付费等。这种运营商云愿景为移动运营商提供了一种高效解决方案，使其能够在控制资本支出（CAPEX）和运营支出（OPEX）在可承受范围内的同时，应对持续增长的移动数据流量[1][2]。在演进分组系统（EPS）[3][4],的背景下，运营商云可以通过对演进分组核心网（EPC）和无线接入网（RAN）进行联合或独立的虚拟化而形成[2]。网络功能虚拟化（NFV）通过利用虚拟硬件抽象技术，将移动核心网/无线接入网节点的软件组件与其专用硬件解耦[5]，从而使移动网络功能转变为可在任何通用商用现成（COTS）多业务多租户节点（例如运营商级刀片服务器）上的标准虚拟机（VM）中运行的软件。

移动网络功能的虚拟化实例化（例如，移动性管理实体‐ MME、服务网关‐S‐GW和分组数据网络网关‐ PDN‐GW），结合适当的编排与管理框架（例如， OpenStack），能够实现移动网络的灵活和按需创建，最终实现EPC即服务（EPCaaS）[6]的愿景。可采用适当的软件定义网络（SDN）技术，在同一数据中心（ DC）或跨多个数据中心的不同虚拟机（VM）上互联不同的虚拟化网络功能（VNFs）。VNF使移动运营商在云上部署其移动网络时具备高度灵活性。因此，可以保证移动服务（例如，机器类型通信–MTC）的快速部署，因为网络功能可以根据需求以动态方式在虚拟机上启动[7]。

图1展示了所设想的虚拟化移动核心网络（即，EPC即服务）的示意图，其中关键的移动网络功能（例如， MME、S‐GW和PDN‐GW）作为虚拟网络功能（VNF）运行在数据中心内的虚拟机之上。这些虚拟网络功能在云基础设施上的初始部署、运行时管理以及互连支持由一个适当的服务编排器（SO）来完成，详见[2][6]。服务弹性是任何通信系统中的一个重要要求，尤其是在以其五个九的可靠性著称的移动网络中。此外，根据ITU‐T E.800定义的服务可用性与可靠性，构成了服务质量（QoS）特性的关键参数。在运营商云的背景下，确保服务弹性成为一个挑战。事实上，高可用性是运营商级别的一个重要要求，但并不一定是云计算的固有特性。构建一个系统，使其在可能无法始终保证可靠性的平台上实现五个九的可靠性，因此成为一个障碍。实际上，在运营商云中，任何运行在虚拟机上的虚拟网络功能（VNF）发生故障都可能严重影响服务弹性。VNF故障可能由多种因素引起，例如硬件故障（如因硬件规格不当）、运行中的VNF（特别是当VNF由多个VNF组件组成，每个组件部署在同一或不同硬件上的独立虚拟机上）或其对应虚拟机中的软件漏洞和缺陷、由于配置错误导致的虚拟机监控层（hypervisor level）故障、同一物理主机上其他VNF带来的负面性能影响，以及针对VNF或虚拟机管理器（即管理程序）的恶意攻击[12]。在运营商云中，VNF故障可能影响控制平面（例如MME）以及用户数据面（例如S‐GWs或PDN‐GWs）。在控制平面中，MME的作用至关重要，因为它负责多项重要过程（例如与大量用户数据面节点/VNF的连接建立、用户设备（UE）移动性管理以及用户设备认证）。其故障将显著影响服务提供，因此有必要通过定义及时、可扩展且可靠的恢复机制来研究EPC即服务（EPCaaS）的服务弹性，以应对MME虚拟网络功能（ MME VNF）等组件的故障恢复问题。

本文的主要目标并非解决实际的VNF故障问题，而是集中研究恢复机制及其对用户设备的影响。此外，我们的关注点在于MME虚拟网络功能故障恢复过程，因为MME虚拟网络功能故障可能影响大量用户设备，并导致服务中断，继而导致信令消息风暴，可能使网络过载[8]。在当前的3GPP规范中，针对MME故障提出的解决方案仍然效率低下[9][10],，因为这些方案基于系统必须等待故障MME重启的假设，在等待期间，由受影响MME处理的用户设备通信将受到严重影响。一种确保服务弹性的可行替代方案是引入冗余。在运营商云环境中，这需要在多个虚拟机上实例化目标VNF（例如MME VNF）的多个实例。通常情况下，冗余会为运营商带来不期望的额外成本。在运营商云场景下，冗余还会增加VNF实例管理的复杂性，并可能导致可扩展性问题，因为可能需要更多的软件定义网络规则来有效引导移动流量。最后但同样重要的是，基于冗余的恢复解决方案并不总是运营商所期望的[9]。

为解决上述问题，我们提出了一种主动式的VNF故障恢复方法，并以MME VNF故障为例进行说明。在所提出的解决方案中，一旦MME VNF停机或开始出现故障，EPC即服务业务编排器[2][6]将立即实例化一个新的MME VNF（即在没有可用的正常工作的MME VNF且具备充足云资源的情况下）。随后，受影响的UE将根据第三代合作伙伴计划（ 3GPP）当前的规范[3]，执行向新的MME VNF实例的重定位。该解决方案的核心思想是主动触发MME VNF重定位并恢复受影响UE丢失的状态信息，以避免服务中断在后期阶段造成中断。需要指出的是，尽管EPC即服务业务编排器[2][6]可能深度参与VNF故障恢复机制，但理想情况下它应保持对服务的无关性：即不了解底层的故障恢复机制。

所提出的方案针对处于ECM（EPS连接管理）空闲模式和激活模式的用户设备（UE）。对于前者，它通过“计划/随机”重新附着操作触发所有受影响的空闲模式用户设备重新接入网络[8]。对于后者，它允许正在进行的通信继续，并根据预定义的优先级按计划触发受影响的用户设备执行跟踪区更新1（TAU）操作。这两种机制都会导致为受影响的用户设备选择另一个MME虚拟网络功能（或实例化一个新的MME虚拟网络功能），并主动恢复其上下文。还设想了若干机制，以促进为受影响的用户设备选择新的MME虚拟网络功能，并主动恢复用户设备的上下文/状态信息。此外，为了处理与重新附着过程相关的确可能大量的信令消息，我们提出了两种减轻负载的替代方案：（i）批量信令，即仅创建一条单一消息来替代一定数量的信令消息；（ii）创建消息配置文件，即通过配置文件标识符（ID）替换消息中的重复信息元素，从而减少信令消息头部，其思想与[11]类似。

本文的其余部分组织如下。第二部分讨论了本文的一些背景，并介绍了相关研究工作。第三部分详细介绍了我们提出的MME VNF恢复解决方案，涉及ECM空闲模式和ECM连接模式下用户设备的批量信令和配置文件创建。第四部分介绍了我们设想的马尔可夫模型，用于对所提出解决方案的分析模型和性能评估。第五部分讨论了获得的结果。第六部分为本文的结论。

II. 背景与现有技术

由于VNF在网络配置灵活性、可扩展性和弹性方面提供了众多优势，它已成为电信领域不同利益相关者研究的重要课题。已有若干开创性研究工作致力于实现基于云的移动网络的创建和运行时管理，探讨了不同的实现选项 [6]，并设计了一个完整的框架，用于在云端创建端到端移动服务，包括移动传输网络[2]。软件定义网络（S DN）也被应用于基于OpenFlow的网络中对移动网络功能进行虚拟化[27][28]。其他研究还考虑使用SDN将移动网络的控制平面在云端进行虚拟化[29]。NFV的概念也在 [30][31],中得到探讨，重点关注控制平面的虚拟化，可单独进行，也可与用户数据面联合进行。

在这样的云原生5G移动网络中，由于EPC节点功能的软件与其底层硬件解耦[2][6]，服务连续性支持成为一个重要的挑战。因此，节点故障（即网络功能故障）的可能性显著增加。实际上，根据VNF的部署方式（即[6]中的实现选项），VNF故障的来源可能有所不同。最简单的 方式是将现有的VNF软件作为镜像运行在专用虚拟机上，并在底层管理程序提供的虚拟资源上执行。在这种情况下，系统中新增的软件引入了新的故障源，例如管理程序层的故障。其他VNF部署场景可能包括将底层硬件切分为由多个VNF共享的一组资源，如图2b所示。这为系统引入了另一个故障源。例如，如果资源隔离未适当实施，某个特定VNF可能会影响共享同一管理程序的其他VNF的性能。在另一种场景中，单个VNF的组件可以实例化在运行于不同管理程序上的多个虚拟机上，如图2c所示。在这种情况 下，由于底层硬件故障或连接组件/管理程序的通信路径上的故障，可能导致一个或多个组件发生单个或多个故障。总之，无论VNF的部署模式如何，i) 快速且准确的VNF故障检测机制以及ii) 全面的VNF故障恢复机制都至关重要 [9][10]。

考虑到演进分组核心网（EPC）中一个最重要的节点的虚拟网络功能（VNF），即本文的重点移动性管理实体（ MME），我们在图3中展示了一个典型的MME故障场景，该场景基于3GPP标准中当前定义的流程[3][4],，重点关注在MME故障后到达的IMS（IP多媒体子系统）终接呼叫。

发生以下步骤： 1) MME（VNF）已失败（即由于软件或硬件原因），并已重新启动（即在硬件故障恢复后于同一服务器上实例化MME VNF镜像，或在另一服务器的虚拟机上实例化MME VNF镜像）。2) S‐GW（无论是VNF还是传统的S‐GW）通过GTP ‐ GPRS隧道协议 ‐（回声消息）中递增的MME重启计数器检测到MME重启，并删除此前在此MME VNF上处理的所有用户设备（UE）资源。需要注意的是，资源的删除不会直接向上传播到PDN‐GW（分组数据网络网关 ‐ 无论是VNF还是传统的PDN‐GW），即在PDN‐GW中分配的IP地址和S5/S8隧道配置保持有效[3]。3) 用于呼叫建立的IMS信令到达PDN‐GW。4) 来自IMS的数据包到达S‐GW，但由于未知的TEIDs（隧道端点标识符）而被丢弃。5)(a) S‐GW向PDN网关发送拒绝消息；(b) PDN‐GW在接收到该消息后，删除与相关IP地址关联的所有资源。6) SIP（会话初始协议）信令消息的丢失导致IMS中出现错误情况，影响服务并最终影响系统弹性。

直观来看，上述解决方案的一个主要问题是其描述的方法是反应式的。事实上，它需要等待故障的MME VNF重启，在此期间，由受影响的MME VNF处理的用户设备的通信将受到显著影响。

鉴于网络实体故障恢复在移动系统服务提供中的重要性，近期文献对此进行了广泛研究，并提出了多种解决方案。[15]中包含了一个框架，描述了在无线接入网络中实现容错的初步尝试，重点关注全球移动通信系统，其主要容错手段是引入传输冗余、覆盖冗余以及服务器复制。在云计算领域，特别是针对虚拟机部署的容错技术也得到了深入研究，以确保系统弹性。[31],中提出了一种冗余虚拟机部署方案，该方案在部署决策中考虑的主要约束是所产生的成本，其目标是最小化为确保预设保护级别所需分配的总资源。[32],中也提出了一种基于保护级别的方案，该方案能够根据目标服务的QoS需求变化，灵活调整保护级别。总体而言，云环境中的弹性和安全已通过多个研究项目（如SECCRIT [33]）得到了广泛研究。

在移动IP网络中，通过在不同代理处复制移动性信息可以实现恢复和故障恢复。因此，当一个代理发生故障时，另一个代理可作为备份继续运行。文献[16],描述了该策略的一种实现方式，其中主备移动性代理以动态方式组织，同时考虑负载均衡。另一种针对移动IP的变体在文献 [17],中提出，通过双重绑定确保故障的移动性代理能被备份代理迅速替换，而无需收集任何移动性信息。该研究进一步分析了一种容错协议来管理双重绑定，以及一种负载均衡方法，用于在无故障的移动性代理之间分配负载。类似的方法在UMTS中也有应用，文献[18],提出了一种基于用户的检查点机制用于归属位置寄存器（HLR）。所提出的方法根据用户活动调节HLR信息的复制，以降低相关开销。文献[19],中引入了UMTS中的计费服务故障机制，重点关注用于传输计费数据记录的GTP协议。该分析有助于运营商降低误故障检测的概率并缩短检测延迟。

鉴于移动用户的高动态性以及移动应用数量和类型的增加，维持双重移动性注册不仅是一个高成本的过程，而且还需要大量的同步工作，效率低下。因此，文献[20]中提出了一些替代方法，用于按需动态选择备用移动性代理。具体而言，一旦移动性代理发生故障，系统会估算受影响的负载，通过负载均衡选择备用移动性代理，并对受影响的移动用户发起系统驱动的主动切换。文献[21]提出了一种类似的分布式方法，考虑了丢失数据的恢复问题。

3GPP LTE在PCRF（策略与计费规则功能）方面采用了相同的故障检测与恢复方法[10][22]。在PCRF场景中，故障可通过DIAMETER协议[23]或在PCRF应用层进行检测。当PCRF发生故障时，只需使用其他PCRF实体即可，对数据平面影响较小。

在3GPP LTE网络中，S1‐flex的采用为演进分组核心网（EPC）中各个网络元素之间的网络冗余提供了基本手段，从而形成MME或服务网关（SGW）池[13]。此类池可服务于特定的eNB，使其能够同时连接到多个MME和服务网关。这样，当某个MME或服务网关发生故障时，相关eNB内的受影响UE可以选择同一池中的另一个实体。

据作者所知，此前尚无研究工作涉及EPS控制平面和数据平面节点的故障检测与恢复。由于控制平面至关重要，本文旨在设计避免双重移动性注册的控制平面故障检测与恢复方法。此外，本文还引入了批量信令，该机制改进了现有方法，降低了核心网内的信令开销以及相应MME和 HSS（归属用户服务器）的处理负担。我们的愿景是将此类故障恢复服务作为自组织网络（SON）的一部分来提供函数[24][25],，使得网络节点能够自主处理并适应 MME池，同时受影响的MMEs的重新配置过程是无缝的。

III. VNF故障恢复：MME VNF案例

VNF故障的恢复在很大程度上取决于VNF的实现方式。可以设想多种实现选项[6]。图4展示了其中两个示例。

单个虚拟机上运行单个VNF，(b) 虚拟机池上运行单个VNF。)

在图4a中，单个VNF以一对一映射方式实例化在一个 VM上。在图4b中，单个VNF的组件以1:N映射方式实例化在一个VM资源池上。其中一个VM运行负载均衡器，将传入请求的处理任务分发到多个运行底层VNF逻辑（即 VNF‐L）的VM上。中央数据库可实例化在一个独立的 VM上，用于存储所有连接到该VNF的用户设备的状态信息。对于1:1实现选项，若发生VNF故障（即提供该VM的物理硬件层面或VNF软件层面故障），需通过在另一个 VM上快速实例化一个类似的VNF来进行及时恢复，从其他网络节点恢复丢失的状态信息（如下文所述），并将受影响的全部或部分用户设备重定向至新实例化的VNF（或另一个合适的现有VNF）。对于1:N实现选项，任何运行 VNF逻辑的VM发生故障时，可通过将传入请求重新分配给正常工作的VNF‐L VM来缓解问题，直至新的VNF‐L VM被实例化。运行负载均衡功能的VM发生故障时，也可通过迅速实例化一个新的VM来恢复对VNF‐L VM之间的负载均衡。然而，中央数据库VM发生故障可能导致重要状态信息丢失且难以恢复，还可能阻碍VNF‐L VM的正常运行，从而导致整个VNF完全失败。部分丢失的状态信息可从服务于受影响用户设备的其他网络节点恢复（如下文所述）。在本文其余部分中，我们考虑最坏情况，即整个VNF发生故障，如1:1实现选项中的情形（或者，在 1:N实现选项中，中央数据库VM发生故障的情形）。

所提出的虚拟网络功能故障恢复框架结合了多种机制，每种机制都有特定的目标，但均旨在实现主动且快速的 VNF故障恢复，以确保运营商云的服务弹性。首先，存在多种检测VNF故障的方法。第一种方法可通过底层数据中心监控实体（例如OpenStack的Ceilometer）的显式干预/通知来实现。事实上，运行VNF的虚拟机的任何异常行为均可由监控实体发现，并直接报告给运营商云服务编排器[2][6]。VNF故障也可由该VNF所属的演进分组核心网（EPC）的操作与维护（O&M）系统进行检测。具体而言，O&M可以通过以下方式检测VNF故障：i）基于在同一VNF上运行或托管在其他虚拟机上的监控软件守护进程提供的反馈；ii）基于周期性的心跳/回声消息及其响应；iii）在VNF崩溃前立即向O&M发送告警（例如，在部分故障或虚拟机缺陷情况下可能实现）；或iv）通过分析来自其他VNF/网络节点的相关信息（例如MME VNF故障时的切换发生情况）。对于本文重点关注的MME VNF故障，eNB也可通过S1‐MME接口直接检测（即使用流控制传输协议 ‐ SCTP ‐[34]的心跳消息）。此外，邻近的 MME VNF（即部署在其他数据中心以覆盖其他服务区域的VNF）可通过S10协议手段，或S‐GW VNF通过S11协议手段检测MME VNF故障。在本节后续部分中，我们将分别讨论如何为处于ECM空闲模式和ECM激活模式的用户设备实现MME VNF的恢复。

A. 空闲模式用户设备的MME虚拟网络功能恢复

1) 原理

如图5所示，所提出的流程基于对寻呼流程的增强，从而实现对由特定MME[35]服务的所有用户设备的寻呼。实际上，“批量”寻呼的特点是使用MME信息——即全球唯一临时标识（Globally Unique Temporary Identity）的前导部分——作为标识符[3]。如图5所示，在检测到MME虚拟网络功能1发生故障后，所有通过S1‐MME接口与MME虚拟网络功能1相连的eNBs将启动对由该失败的MME虚拟网络功能1所服务的所有用户设备的批量寻呼，使用失败的MME虚拟网络功能的标识以及一些用于过载避免的指示信息（例如，随机化的时间间隔）。稍后将详细解释。在重新附着过程中，eNB会考虑负载均衡，将响应的用户设备重新分配给仍在运行的MME虚拟网络功能。由用户设备发起的服务请求流程作为对寻呼的响应，将间接导致重新附着，其顺序如下：实际上，用户设备向 eNB发送SERVICE REQUEST消息。由于最初分配的 MME虚拟网络功能发生故障，eNB需要通过释放无线资源控制（RRC）连接（例如，使用原因“需要负载均衡TAU” [3]）将该用户设备重新分配到另一个MME虚拟网络功能。用户设备将重新建立RRC连接，随后执行跟踪区更新。该机制原则上会导致大量用户设备同时重新附着。为避免新选中的MME虚拟网络功能过载，应将重新附着尝试在时间上分散进行。这可以通过多种机制实现，具体将在后面说明。除了上述基于服务请求的流程外，用户设备在收到寻呼消息后也可能重新附着到网络，这种情况是由于MME虚拟网络功能故障所致（即通过寻呼消息中的标志指示），并遵循常规的附着流程[3]。处于空闲模式且受MME虚拟网络功能故障影响的用户设备的寻呼也可由邻近MME虚拟网络功能发起。一般来说，如果MME A和MME B在其管理的服务区域中至少有一个共同的跟踪区域，则称MME虚拟网络功能A为 MME虚拟网络功能B的邻近MME虚拟网络功能。实际上，一个或多个邻近MME虚拟网络功能可能检测到某个MME虚拟网络功能的故障。随后，它们将发起针对空闲模式用户设备的批量寻呼，包含失败的MME虚拟网络功能的标识以及一些过载避免指示信息，以触发相应用户设备重新附着到网络（例如，如[3]中所示，指示“需要负载均衡TAU”）。在此解决方案中，应尽量减少重复寻呼，甚至完全避免。这可以通过不同的方法实现。如果相邻的MME虚拟网络功能检测到MME虚拟网络功能故障，则立即启动对相关用户设备的寻呼，并通知其相邻的MME虚拟网络功能，表明已对相关UE进行寻呼，对方无需再执行此操作。该机制假设 MME虚拟网络功能事先已知能够覆盖失败MME虚拟网络功能的MME虚拟网络功能池。如果运营与维护（O&M）检测到MME故障并通知相邻的MME虚拟网络功能，运营与维护 （O&M）会明确指示每个MME虚拟网络功能应寻呼的跟踪区域。此外，eNBs可过滤来自不同MME虚拟网络功能的重复寻呼消息。在不可避免接收到重复寻呼消息的情况下，用户设备仅处理第一个寻呼消息，并丢弃后续的消息。为了实现负载均衡，相关的eNBs将运行MME虚拟网络功能负载均衡方案（排除失败的MME虚拟网络功能），以确保并非所有用户设备都连接到[3]中的同一个MME虚拟网络功能。若用于处理受影响UE的MME虚拟网络功能采用上述1:N方式实现，则可在eNBs侧省略此类负载均衡。

2) 批量信令管理

虽然通过考虑负载均衡可以在 MME虚拟网络功能上避免由于大量受影响的UE同时尝试导致的信令拥塞，但也可以通过对受影响的UE的信令消息进行批量处理来避免这种迫在眉睫的拥塞。实际上，为了应对MME虚拟网络功能可能存在的约束

就每秒可处理的最大信令消息数（例如图6中的跟踪区域更新）而言，eNB可以暂缓来自用户设备的信令消息（例如TAU），以便将它们聚合后以单个消息发送至MME。MME也可以对发往归属用户服务器的多个位置更新（即 TAU流程的一部分）执行相同的操作（图6）。例如， MME可以等待预定义超时，或直到收到一定数量的位置更新请求（或两者同时满足），再将批量的位置更新请求发送至HSS。利用如图6所示的由大量用户设备发起的 TAU消息在eNB处可能实现的聚合，我们展示了与现有技术相比批量MTC信令的潜力。TAU消息包含必选字段（共15字节）以及一组可选字段（见图7）。由于我们仅关注与同一MME虚拟网络功能相关联的用户设备，因此唯一与UE相关的参数是M‐TMSI（MME临时移动用户标识），用于在一个MME虚拟网络功能中识别设备。其余字段共11字节，占总15字节中的大部分，对于所有与该 MME虚拟网络功能相关联的用户设备而言是共用的。假设N个受影响的用户设备与同一个MME虚拟网络功能相关联，则可将N个TAU聚合为一条大小为(4 N + 11) 字节的消息，而若使用单独消息则需要(N x 15) 字节。如图6所示，在MME虚拟网络功能处还可进一步向HSS进行聚合；这意味着消息内容可以大幅压缩。此外，解析多个消息参数的工作量也降至最低，从而显著减少整个流程所需的时间。因此，即使众多原始信令消息的所有信息元素 （IE）各不相同，仅通过避免处理多条消息（例如每条消息都需确认，即协议状态需维持一段时间）和实现更高效 的解析，也能提升信令效率。同样至关重要的是，应避免 eNB因受事件影响的用户设备发送过多信令消息而发生拥塞。这可以通过调度寻呼和/或其响应来实现。事实上，可在MME虚拟网络功能或eNB上按批次执行批量寻呼

基于特定的优先级指标（例如接入等级）或使用预定义的 随机化时间以随机方式，针对特定组的用户设备。用户设备的响应也可以通过哈希函数在一定时间间隔内以随机方式进行，该哈希函数以用户设备的唯一标识符（例如国际移动用户识别码 ‐ IMSI、用户设备处可用的订阅信息等）作为输入取值（基于新的用户设备功能）。

3) 基于配置文件ID的信令管理

尽管批量处理信令消息（例如TAU消息）具有一些优势，但其主要缺点是增加了消息处理的延迟。实际上，发送节点（即eNB）必须等待超时或接收到一定数量的信令消息后，才能将信令消息传递给接收方（例如MME虚拟网络功能）。本文提出的解决方案旨在实现“批量”减少网络上传输流量的目标，同时不增加处理消息的延迟。该解决方案定义了动态创建和管理配置文件标识符的方法，这些配置文件标识符对应于与用户设备组相关消息中的公共信息元素，并用所创建的配置文件ID替换这些公共信息元素。通过创建用于引用这些公共IEs的配置文件ID并发送该配置文件ID

用配置文件 ID 替代所有公共 IEs 必将减少 eNB 与 MME VNF 之间交换的流量。考虑到规范每次发布都会增加消息大小，通过配置文件 ID 替代消息中的公共 IEs 的重要性更加凸显，这一思路类似于鲁棒性头压缩（ ROCH）。图8展示了为TAU消息创建配置文件ID的示例。如批量信令管理方案中所述，TAU消息包含必选字段（共 15字节）以及一组可选字段。仅考虑与同一MME VNF相关联的用户设备（UE），唯一特定于UE的参数是 M‐TMSI。因此，其他信息元素（IEs）均为公共信息，可以被分组并由一个配置文件ID替代，如图8所示。参考 图6，可能参与配置文件ID创建的节点包括eNB和用于恢复的MME VNF。配置文件ID可以是随机值，也可以是相关UE的组ID和其他指标的函数。组ID可以在消息中显式指示，或从相关UE的eNB（和/或其他信息元素）推断得出，或从按需下载或预先从归属用户服务器（HSS）或其他相关节点获取的UE订阅数据中推断得出，或从相关流程与相关UE位置（例如小区、跟踪区域、服务区域等）之间的映射关系中推断得出。第二步，eNB将配置文件 ID及其特征通知给MME VNF，该通知可选择性地附带在接收端删除配置文件ID的时间、事件类型等指令。此通知可以采用专用信令消息的形式，也可以插入到配置文件创建后发送的第一个相关消息中。配置文件通知消息可选择性地由MME VNF进行确认。作为响应，MME VNF存储该配置文件ID及其属性。对于后续与该配置文件ID相关的消息，eNB不再插入公共IEs，而仅插入配置文件ID。通过这种方式，可以减少两个实体（eNB和MME VNF）之间接口上的通信量；当受失败的MME VNF影响的 UE数量较多时，这种减少尤为重要。再次以TAU消息为例，

配置文件 ID 将生成 (Nx6) 字节（当有 n个用户设备 受影响时），这比经典流程的 (Nx15) 字节少，但多于批量情况下的 (4N+11)。然而，基于配置文件 ID 的信令管理方案显著降低了处理信令消息的延迟。

B. 激活模式下受影响的UE从MME虚拟网络功能故障中的恢复

关于处于ECM连接模式且受MME虚拟网络功能故障影响的用户设备，目标是获取其先前在故障的MME VNF上存在的上下文/状态信息，这些信息分布在不同的网络实体（例如S‐GW VNF、P‐GW VNF和eNB）中，同时不影响用户设备正在进行的会话。从不同网络实体中恢复状态信息片段可能是一种可行的方法，特别是在以 1:N方式实现的网络功能虚拟化中，运行中央数据库的虚拟机发生故障的情况下。现有技术的解决方案是将所有信息复制/镜像到高弹性节点或VNF的数据库实现中。因此，一旦MME VNF发生故障，用户设备的上下文信息即可从这些镜像中立即恢复。然而，这种方法在配置方面显然成本较高。相比之下，本节后续描述的解决方案基于网络元素或功能之间更智能、协作的行为，从而实现更为简化的 MME VNF实现，符合运营商云愿景[2][6]。具体而言，新选择的MME VNF（在服务MME VNF发生故障后）将从 eNBs（图9中的步骤1）和S‐GW VNFs（图9中的步骤3）恢复状态信息。新的MME VNF从S‐GW VNFs恢复的状态信息（步骤3）包括每个用户设备的承载信息，如 IMSI、移动设备标识、用于S11/S4接口的S‐GW TEID （隧道端点标识符）、PDN‐GW IP地址以及用于S5/S8 接口的TEID、用于S1‐u接口的eNB TEID、PDN计费特性以及EPS承载QoS。新的MME VNF从eNBs恢复的状态信息（图9中的步骤1）包括每个用户设备的EPS承载信息（TEID和eNB IP地址）以及聚合最大比特率 （AMBR）。由于需要为大量用户设备交换每个UE和 EPS承载的信息，因此eNB/SGW与MME虚拟网络功能之间的信息交换（步骤1‐4）也可以通过批量信令或配置文件ID创建的方式实现（即每个UE和EPS承载的信息可在一次信令交互中进行聚合）。图9展示了该解决方案的流程图。该机制适用于所有位于曾由失败的MME VNF提供服务的跟踪区域内的eNB。它仅涉及那些曾经注册到失败的MME VNF且当前处于连接模式的用户设备。请注意， eNB可以轻松识别这些用户设备。该解决方案的步骤如下：

1) eNB检测到MME VNF故障，并从其余正在运行的 MME VNF中选择一个新的MME VNF。如果无其他可用的MME VNF，可触发EPC即服务业务编排器来实例化一个新的MME VNF [2][6]。在选择新的MME VNF时需考虑负载均衡，特别是在VNF以一对一映射方式实现的情况下 [6]。MME VNF的选择可以针对单个激活的用户设备 （UE），也可以针对具有一些共同因素的一组激活的用户设备（例如被分配了相同的S‐GW VNF、即将发生切换等），并通过本地分配的唯一标识符（例如根据[9]定义的连接集标识（Connection Set ID））进行定义。可以设想对用户设备或形成的用户设备组进行优先级排序，直观上，即将发生切换的用户设备应优先于其他用户设备。

2) eNB向所选的MME VNF发送UE的S1承载信息，请求更新UE上下文。提供的上下文信息可能包括UE的 IMSI、相应的S‐GW VNF以及更新原因（即相关 MME VNF发生故障）。对于每个形成的UE组，也可以执行批量更新请求。

3) 随后，MME VNF向相应的S‐GW VNF发送更新接入承载请求，查询UE的S1承载信息。MME VNF反过来还可以将UE分组成不同的组，每组具有唯一且本地标识，并对每个形成的用户设备组发送一批更新承载请求。

4) 作为响应，S‐GW VNF发送更新接入承载响应。此处还可以包含相应的PDN‐GW VNF的信息。

5) 作为确认，新选择的MME VNF向eNB回复S1 UE上下文更新响应。

6) 当UE检测到MME VNF故障（例如，在尝试使用旧GUTI发起新的PDN连接后收到错误消息）或被触发执行TAU（例如，通过eNB发送的RRC连接信令消息），它将发送跟踪区更新。随后将发生MME VNF重定位，且不影响用户面，从而确保服务连续性。

需要注意的是，尽管在上述流程中，连接模式下的每个用户设备的跟踪区更新请求是单独处理的，但对于处于连接模式下的用户设备，也可采用相同的批量信令处理方式，空闲模式，可以应用。

第四节 分析模型

A. 系统模型

在详细描述了运营商云中提出的VNF故障恢复解决方案后，本节我们将重点放在为整个框架提供一个分析模型上。该设想模型的关键目标是估计当MME VNF发生故障时活跃/空闲用户设备的数量。这里我们考虑一个EPC即服务系统，该系统包含一个MME虚拟网络功能、一个 eNB和 n个UEs。我们假设每个用户设备处于空闲模式或激活模式之一。我们假设用户设备在空闲模式（分别地，激活模式）下的持续时间服从速率为 µ（分别地， λ）的指数分布。同样地，MME VNF故障前的持续时间以及从 MME VNF故障中恢复的持续时间均服从指数分布，其对应的速率分别为 f和 r。这些假设使我们能够使用马尔可夫链 X={Xt, t ≥ 0}对系统进行建模，其状态空间 S由S={(i, j) | i= 0, . . ., n和 j= 0, 1}构成，其中 每个 n ≥ 1。在此模型中， Xt=(i, j)表示在时间 t，网络中有 i个激活的用户设备，且MME VNF处于状态 j。其中 j= 0表示MME VNF处于故障状态， j= 1表示 MME VNF正常工作。图10展示了设想系统的状态转移图。不同的转换如下：

如果一个用户设备在已有 i(0 ≤ i ≤n−1)个用户设备处于激活模式且MME虚拟网络功能处于激活状态时进入激活模式，则系统状态从(i, 1)转移到(i+ 1, 1)，转移速率为(n − i)λ。

如果一个用户设备在已有 i(1 ≤ i ≤ n)个用户设备处于激活状态且MME虚拟网络功能处于激活状态时进入空闲模式，则系统状态将从(i, 1)以速率iµ转移到(i−1, 1)。

如果在已有 i(0 ≤ i ≤ 0)处于激活状态且MME VNF处于激活状态时发生MME VNF故障，则系统将从状态(i, 1)转移到状态(i, 0)，并伴随 f。

如果MME VNF在已有 i （0 ≤i ≤ n）处于激活状态时已恢复，则系统以速率 r从状态（i,0）转移到状态 （0.0）。我们认为此转移的原因是：从MME虚拟网络功能故障中恢复将导致其在新虚拟机上重启或实例化类似的MME VNF。然而，在eNBs变为

eNBs通过GTP隧道接收到递增的MME重启计数器，从而立即感知MME VNF状态的任何变化。

我们用 A表示 X的无穷小生成元。因此，矩阵 A的非对角线元素为

A(i,0),(i+1,0)=(n − i)λ, for i= 0,…, n − 1,

A(i,0),(i−1,0)= iµ, for i= 1,…, n,

A(i,0),(i,1)= f, for i= 0,…, n,

A(i,1),(0,0)= r, for i= 0,…, n.

A 的对角线元素为 i= 0，…， n， A(i,1),(i,1)=−((n− i)λ+ iµ+ r) 和 A(i,0),(i,0)= −r。

马尔可夫链 X具有不可约性和有限状态空间，因此存在一个极限分布，我们将其记为π。于是，对于每个(i, j) ∈ S，有limt−→∞ P{Xt=(i, j)}= π(i,j)。为了计算平稳分布 π，我们引入集合 S0={(i, 0) | i= 0，⋯， n}和S1={(i, 1) | i= 0，⋯， n}。该状态空间的划分S导致矩阵 A的分解

A=( Q D1 C D2),

其中，矩阵 Q包含S1状态之间的转移速率，矩阵 D1包含从 S1状态到 S0状态的转移速率，矩阵 C包含从 S0状态到 S1状态的转移速率，矩阵 D2包含 S0状态之间的转移速率。注意，我们有 D1= fI和D2= −rI，其中 I是 (n+1, n+1)单位矩阵。平稳分布 π满足

πA= 0 and ∑(i,j)∈S π(i,j)= 1.

我们使用划分 S1、 S0 对行向量 π 进行分解，如下所示：

π=(π(1), π(0)).

线性系统 πA= 0 可以表示为

{ π(1)Q+ π(0)C= 0 π(1)D1+ π(0)D2= 0.

然后我们有 π(0)= fπ(1)/r。我们用1表示所有元素都等于1的列向量；其维度由使用上下文确定。我们得到

1= π1= π(1) 1+ π(0) 1= f+ r r π(1) 1.

因此我们得到

π( 1 ) (Q+ fC/r)= 0 with π( 1 ) 1= r f+ r .

矩阵 T= Q+ fC/r 是状态空间 S1 上不可约马尔可夫链的转移速率矩阵。其平稳解 y 满足 yT= 0，其中 y1 = 1。因此 我们得到

π ( 1 ) = r f+ r y and π ( 0 ) = f f+ r y.

为了计算 y，我们考虑线性系统 yT=0，其可以表示为：

  

−nλy0+(µ+ f)y1+ f(y2+ · · ·+ yn)= 0

(n − i+ 1)λyi−1 −((n − i)λ+ iµ+ f)yi

+(i+ 1)µyi+1= 0, for i= 1,…, n − 1

λyn−1 −(nµ+ f)yn= 0

或等价地表示为

  

−(nλ+ f)y0+ µy1+ f= 0

(n − i+ 2)λyi−2 −((n − i+ 1)λ+(i − 1)µ+ f)yi−1

• iµyi= 0, for i= 2,…, n

y0+ y1+ · · ·+ yn= 1, (1) 其中，前一个系统的最后一个方程已被归一化条件 y1= 1所替代。随后我们得到以下递推关系

   y1= nλ+ f µ y0 − µf yi=(n − i+ 1)λ+(i − 1)µ+ f iµ yi−1

−(n − i+ 2)λ iµ yi−2, for i= 2,…, n.

为了解决这个递推关系，我们从 y0 的任意正值开始，例如 y0= 1，然后计算所有 yi，对应 i= 1，…， n，最后通过将每个计算值除以 yi 的总和得到 yi 的真实取值。一旦获得 y， 我们就能容易地得到向量 π(1) 和 π(0)，从而得到向量 π。

我们用NI（分别用NA）表示MME VNF已恢复时处于空闲（分别激活）模式的用户设备数量。然后有NA +NI = n

P{NA= ℓ}= πℓ,0 and P{NI= ℓ}= πn−ℓ,0

因此，期望是

E[NA]= ∑nℓ=1 ℓπℓ,0 and E[NI]= n − E[NA].

B. 性能指标

了解激活/空闲用户设备的平均数量后，我们可以评估所提出的两种信令管理解决方案——批量信令和基于配置文件ID的信令管理的性能。作为对比项，我们采用了另外两种传统解决方案：一种是所有用户设备同时被通知；另一种是采用随机通知方案来通知用户设备。实际上，一旦MME VNF发生故障，受影响的用户设备将根据以下四种方案执行时间提前更新：（i）无智能的TAU，即所有用户设备同时执行TA更新；（ii）基于随机通知的TAU，即用户设备根据随机分布接收何时执行TA更新的通知；（iii）基于批量信令的TAU，即用户设备的通知方式类似于基于随机通知的TAU，并且eNB additionally 执行批量信令；（iv）基于配置文件 ID 的 TAU，即使用相应的配置文件 ID 对 TAU 消息进行压缩，并且所有用户设备基于随机通知执行更新。本文考虑的大多数指标均针对 MME恢复情况，此时受影响的用户设备处于空闲模式。回顾一下，我们使用的是均匀分布

一种均值 Tu/2，用于允许用户设备随机执行时间提前更新。Tu 是用于分散用户设备信令以避免同时传输的时间周期T。

1) 信令开销

信令开销使我们能够在MME VNF发生失败后、在预定时间周期T内，根据交换的信令消息所产生的成本，对上述方案进行比较。对于无智能的TAU操作，交换消息的平均大小如下所示：

E[msg]= 15E[NI] 此处的开销大小仅取决于将用户设备从一个MME虚拟网络功能重新定位到另一个MME虚拟网络功能或重新连接到已重启的 MME虚拟网络功能所需的TAU消息数量。由于所有用户设备同时被通知，所有处于空闲模式的用户设备都需要发送一条15字节的跟踪区更新消息。基于随机通知的跟踪区更新方法则不同，用户设备会根据随机分布明确获知执行跟踪区更新的时机。因此，此种情况下由信令消息引起的平均开销为：

E[msg | NI= ℓ]= 15 ∑ℓi=1 i( ℓ i)p i(1 −p)ℓ−i

也就是说

E[msg]= 15 ∑nℓ=0 ∑ℓi=1 i( ℓ i)p i(1 −p)ℓ−iπn−ℓ,0,

其中 p是用户设备在时间间隔T内发送跟踪区更新消息的概率。该概率等于 T/Tu，其中T ≤ Tu。

对于基于批量信令的TAU方案，信令消息的平均大小如下所示：

E[msg | NI= ℓ]= 11+ 4 ∑⌈ℓ/k⌉i=1 i(⌈ℓ/k⌉ i)p i (1 −p)⌈ ℓ/k⌉−i

即

E[msg]= 11+ 4 ∑nℓ=0 ∑⌈ℓ/k⌉i=1 i(⌈ℓ/k⌉ i)p i (1 −p)⌈ ℓ/k⌉−i πn−ℓ,0

其中 ⌈ℓ/k⌉是批量的大小，表示eNB必须等待的TAU消息数量，以创建一个批量。

最后，对于基于配置文件ID的TAU方案，平均信令开销由以下公式给出：

E[msg | NI= ℓ]= 11 ∑ℓi=1 i( ℓ i) p i (1 −p) ℓ − i

也就是说

E[msg]= 11 ∑nℓ=0 ∑ℓi=1 i( ℓ i) p i (1 −p) ℓ − i π n − ℓ,0 .

2) eNB处的丢弃概率

该指标表示在MME虚拟网络功能故障后，用户设备发送的TAU信令消息在eNB处的丢弃概率。我们用 CeNB表示eNB同时处理TAU消息的能力。

对于没有附加智能的基准TAU方案， loss事件是事件{NI > CeNB}。因此，eNB处的丢弃概率推导如下：

Pdrop= P{loss}= P{NI> CeNB}

=∑n ℓ=CeNB+1 πn−ℓ,0=∑ n−CeNB−1 ℓ=0 πℓ,0.

对于基于随机通知的TAU方案，该概率由以下公式给出

Pdrop=∑nℓ=CeNB+1 P{loss | NI= ℓ}P{NI= ℓ}

=∑n ℓ=CeNB+1∑ℓ i=CeNB+1( ℓ i)p i(1 −p)ℓ−iπn−ℓ,0

最后，对于基于批量信令的TAU方案，其表达如下：

Pdrop=∑nℓ=CeNB+1 P{loss | NI= ℓ}P{NI= ℓ}

=∑n ℓ=C eNB +1∑⌈ℓ/k⌉i=C eNB +1( ⌈ℓ/k⌉ i)pi(1 −p)⌈ℓ/k⌉−iπn−ℓ,0

值得注意的是，在使用基于配置文件ID的信令管理机制的情况下，掉话概率与基于随机通知的TAU方案相同。这归因于基于配置文件ID的TAU方法虽然压缩了TAU消息大小，但并未减少网络中TAU消息的数量。

3) 总体处理时间

该指标有助于展示减少信令消息数量（批量信令方法）或其大小（基于配置文件ID的方法）对核心网实体处理每条消息所需处理时间的影响。为此，我们假设有M个实体参与特定流程（例如，在TAU流程中， M= 5，涉及eNB、MME VNF、S‐GW VNF、 PDN‐GW VNF和归属用户服务器），每个实体具有平均比特处理速度P以及进程间延迟 d。

对于不涉及附加智能的基准TAU方案，在时间间隔T内所需的处理时间为：

processing= M(15NI P + dNI) if NI ≤ CeNB M(15CeNB P + dCeNB) if NI> CeNB

预期处理时间由以下公式给出

E[processing | NI= ℓ]= M( 15 P + d)(ℓ1{ ℓ ≤ C eNB } + C eNB 1{ ℓ>C eNB })

也就是说

E[processing]= M( 15 P + d)(∑ C eNBℓ=0 ℓπ n − ℓ,0 + C eNB∑n ℓ= C eNB +1 π n − ℓ,0)

对于基于随机通知的TAU方案，平均处理时间推导如下：

E[processing | NI= ℓ]= M(1P5+ d)(∑ℓ i=0( ℓ i)p i(1 −p)ℓ−i1{ℓ≤CeNB}+ CeNB1{ℓ<CeNB})

即

E[processing]= M(1P5+ d)(∑CeNB ℓ=0 ∑ℓ i=1( ℓ i)p i(1 −p)ℓ−iπn−ℓ,0) +M(1P5+ d)(CeNB∑ n ℓ=CeNB+1 πn−ℓ,0)

对于基于批量信令的TAU方案，平均处理时间持续时间可按如下方式计算：

E[processing | NI= ℓ]= M(4 ⌈ℓ/k⌉+ d), 也就是说

E[processing]= M(4∑n ℓ=0 ⌈ℓ/k⌉πn−ℓ,0+ d)

最后，对于基于配置文件ID的TAU方法，平均处理时间以相同的方式推导如下：

E[processing]= M(1P1 + d)∑ C eNB ℓ=0 ∑ℓ i=1( ℓ i)p i(1 −p)ℓ−iπn−ℓ,0 + M(1P5 + d) CeNB∑ n ℓ=C eNB +1 πn−ℓ,0.

4) 批量大小

该指标仅与提出的批量信令管理解决方案相关。实际上，该指标表示在某个时间周期T内生成批量的概率。它取决于批量大小 Bsize和 T。具体如下所示：

P{bulk creation}= ∑nℓ=Bsize+1∑ℓ i=Bsize+1( ℓ i) p i (1 −p) ℓ−iπn−ℓ,0

其中 p= T/Tu。

V. 数值结果

A. 场景

本节使用上述基于马尔可夫链的分析模型对上述四种机制的性能进行评估和比较。设想的网络由一个移动性管理实体、一个eNB以及连接到该eNB的200个用户设备组成。我们定义 ρ= λ µ 为用户设备处于空闲模式的时间周期 T与处于激活模式的时间周期T之比。 ρ的值越高，用户设备处于激活模式的可能性就越高。假设eNB无法同时处理超过20个TAU请求；当同时有更多TAU请求到达eNB时，多余的

一些则被直接丢弃。考虑了两种MME虚拟网络功能故障的场景：

•高故障率，其中 f=1周和 r=3天。

•中等故障率，其中 f=3周和 r=3天。

表I 总结了用于推导数值结果的不同取值。

B. 结果

图11 绘制了两种场景下四种方案的信令开销。此处，批量大小设置为50条消息，即需要50条消息来创建一个批量。正如预期，我们观察到基于批量信令的方法取得了最佳效果，其次是基于Profile ID的机制。这种性能表现的原因在于，基于批量信令的方案减少了eNB与MME虚拟网络功能之间发送的信令消息数量，而基于Profile I D的方案通过创建专用的Profile ID来替代TAU消息中的公共IEs，从而压缩信令消息，减小了信令消息的大小。此外，我们注意到，除了基于批量信令的方案外，其他所有方案在高故障率场景下的信令开销均高于中等故障率场景下的开销。事实上，基于批量信令的方案在这两种场景下均保持了非常低的开销。从图中还可以观察到，当处于空闲模式的用户设备数量多于处于激活模式的用户设备时，信令开销会增加。最后，随机

基于通知的信令管理机制比基准TAU方法表现出更好的结果。这表明，在信令管理中引入一些简单的智能机制，即可在降低信令开销方面取得显著成效。

图12显示了在两种设想场景下TAU消息的丢弃概率。该图未绘制基于配置文件ID的信令管理方案的结果，因为其结果与基于随机通知的方案相似。同样，基于批量信令的机制表现出最佳性能，因为它将传输的消息数量减少到最低，不超过eNB容量。最差的情况出现在基准TAU方法中，其中丢弃概率保持在最大值（对于两种场景），直到激活/空闲UE的比例（ρ）达到10。我们认为这是因为当使用基准解决方案时，所有空闲用户设备同时尝试发送 TAU消息，导致大多数时间超过eNB容量。

在图13中也观察到了类似的趋势，该图绘制了四种信令管理方案在两种场景下的平均处理时间。基于批量信令的机制优于所有其他机制，因为它显著减少了需要处理的消息数量，从而大幅降低了处理时间。相比之下，基于配置文件ID的解决方案比基准TAU方法和基于随机通知的方案表现出更好的性能。这种更优的性能主要归因于基于配置文件ID的解决方案减小了TAU消息的大小，通过事先约定的配置文件ID替代了公共IEs。此外，我们发现当激活/空闲UE的比例小于8时，三种机制（无智能、随机和配置文件ID）的性能之间没有显著差异。这是因为在掉线概率较高时，处理时间主要依赖于CeNB，而这三种上述机制在(ρ ≤ 8)的情况下正是如此（见图12）。

根据目前得到的结果，基于批量信令的机制表现出最佳性能。然而，其良好性能的代价是增加了TAU消息实际传输的延迟，并最终导致用户设备重新接入网络的延迟。在图14中，我们绘制了在高故障率场景下，针对三种不同的活跃和空闲用户设备数量（即ρ=0.1、 ρ=1和 ρ=10），考虑四种批量大小（即10、20、50和100条TAU消息）时，在某一时间段（T）后生成批量的概率。这些图清楚地表明，当处于空闲状态的用户设备数量较多时（即 ρ取值较小），批量消息会在更短的时间内生成。然而，当空闲状态的用户设备较少时，批量消息的生成需要更长时间，即使是较小的批量大小进行组包也是如此。这一观察结果是显而易见的，因为空闲模式用户设备发送TAU消息的数量越多，快速生成批量消息的概率就越高。此外，还可以观察到，生成一个批量消息所需的时间在某种程度上与批量大小成正比。

总之，批量信令管理方案定义了在恢复MME虚拟网络功能故障后（尤其是在存在大量空闲模式用户设备的情况下）减轻信令过载的最佳方式。然而，如果空闲模式用户设备数量不多，基于配置文件ID的信令管理方法可能更具吸引力，因为它不会对TAU消息的传输以及用户设备重新连接造成任何延迟，其信令开销也仍在可接受范围内。

VI. 结论

本文中，我们设计了高效的主动恢复机制，以确保运营商云中的服务弹性。这些机制旨在减少因恢复MME VNF实体而产生的控制信令消息所导致的网络过载。第一种机制基于批量信令，即创建单个消息以批量替代一定数量的信令消息；第二种机制创建消息配置文件，即通过配置文件ID替换重复信息元素，从而减小信令消息头部。为评估所设计机制的性能，本文提供了一个基于马尔可夫链的分析模型。获得的结果表明，与当前3GPP解决方案相比，所提出的解决方案具有优越性。