云原生5G中的服务弹性机制

云原生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）或跨多个DC的不同虚拟机（VM）上互联不同的虚拟网络功能（VNFs）。VNF将为移动运营商在云上部署其移动网络提供高度灵活性。因此，移动服务（例如，机器类型通信–MTC）的快速部署可以得到保障，因为网络功能可以根据需求以动态方式在虚拟机上启动[7]。图1展示了设想中的虚拟化移动核心网（即，EPCaaS）的示意图，其中关键的移动网络功能（例如，MME、S‐GW和PDN‐GW）作为VNFs运行在数据中心内虚拟机之上。这些VNFs在云基础设施上的初始部署、运行时管理以及互连支持由一个适当的服务编排器（SO）来完成，如[2][6]中所述。服务弹性是任何通信系统中的重要要求，尤其是在以其五个九的可靠性著称的移动网络中。此外，根据ITU‐T E.800定义的服务可用性和可靠性，构成了服务质量（QoS）特性的关键参数。在运营商云的背景下，确保服务弹性成为一个挑战。事实上，高可用性是运营商级的重要要求，但并不一定是云计算的固有特性。构建一个系统，使其在可能无法始终保证五个九的可靠性的平台上实现这一要求，因此成为一个障碍。实际上，在运营商云中，运行在虚拟机上的任何VNF的故障都可能严重影响服务弹性。VNF故障可能由多种因素引起，例如硬件故障（如因硬件配置不当）、正在运行的VNF中的软件漏洞和缺陷（特别是当VNF由多个VNF组件组成，每个组件部署在同一或不同硬件上的独立虚拟机上时），或其对应虚拟机的故障、由于配置错误导致的虚拟机监控层（hypervisor level）故障、由于同一物理主机上托管的其他VNF带来的负面性能影响，以及针对VNF或虚拟机管理器（即虚拟机监视器（hypervisor））的恶意攻击[12]。在运营商云中，VNF故障可能影响控制平面（例如MME）以及用户数据平面（例如S‐GWs或PDN‐GWs）。

在控制平面中，MME的作用至关重要，因为它负责许多重要过程（例如，与大量用户数据平面节点/VNFs的连接建立、用户设备（UE）移动性管理以及用户设备认证）。其故障会显著影响服务提供，因此有必要通过定义快速、可扩展且可靠的恢复机制来研究EPC即服务（EPCaaS）的服务弹性，以应对MME VNF（作为示例）发生故障后的恢复问题。

本文的主要目标并非解决实际的VNF故障问题，而是专注于恢复机制及其对用户设备的影响。此外，我们的研究重点是MME VNF故障的恢复过程，因为MME VNF故障可能影响大量用户设备，并导致服务中断，进而引发信令消息风暴，可能使网络过载[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将根据第三代合作伙伴计划的现行规范[3]，执行向新的MME VNF实例的MME重定位。该提出方案的核心思想是主动触发MME VNF重定位并恢复受影响UE丢失的状态信息，以避免服务中断在后期阶段造成中断。需要指出的是，尽管EPC即服务业务编排器[2][6]可能深度参与VNF故障恢复机制，但理想情况下它应保持对服务的无关性：即不了解底层的故障恢复机制。

该方法针对处于ECM（EPS连接管理）空闲模式和激活模式的用户设备。对于前者，通过“计划/随机”重新附着操作触发所有受影响的空闲模式用户设备重新接入网络[8]。对于后者，允许正在进行的通信继续，并根据预定义的优先级按计划触发受影响的用户设备执行跟踪区更新1（TAU）操作。这两种机制都会导致为受影响的用户设备选择另一个MME虚拟网络功能（或实例化一个新的MME虚拟网络功能），并主动恢复其上下文。还设想了若干机制，以促进为受影响的用户设备选择新的MME虚拟网络功能以及主动恢复用户设备的上下文/状态信息。

此外，为了应对与重新附着过程相关的可能大量信令消息，我们提出了两种减轻负载的替代方案：（i）批量信令，即仅创建一条单一消息来批量替换一定数量的信令消息；（ii）创建消息配置文件，即通过配置文件ID替换消息中的重复信息元素，从而减少信令消息头部，这在理念上类似于[11]。

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

II. 背景与现有技术

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

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

考虑到演进型分组核心网（EPC）中最重要的节点之一虚拟网络功能（VNF），即本文的重点MME，我们在图3中展示了在当前3GPP标准[3][4],定义的流程中，MME故障后到达的IMS（IP多媒体子系统）终接呼叫的典型MME故障场景。具体步骤如下：

1) MME（VNF）发生故障（即由于软件或硬件原因）并已重启（即在硬件故障恢复后于同一服务器上实例化MME VNF镜像，或在另一服务器上的虚拟机中实例化MME VNF镜像）。

2) S‐GW（无论是VNF还是传统S‐GW）通过GTP ‐ GPRS隧道协议 ‐（回声消息）中递增的MME重启计数器检测到MME重启，并删除此前由该MME VNF处理的所有用户设备（UE）资源。需要注意的是，资源的删除不会直接向上传播至PDN‐GW（分组数据网络网关 ‐ 无论是VNF还是传统PDN‐

网关），即在PDN‐GW中分配的IP地址和S5/S8隧道配置保持有效[3]。3) 用于呼叫建立的IMS信令到达PDN‐GW。4) 来自IMS的数据包到达服务网关并被丢弃，原因是TEID（隧道端点标识符）未知。5) (a) 服务网关向PDN‐GW发送拒绝消息；(b) PDN‐GW在接收到该消息后，删除与相关IP地址关联的所有资源。6) SIP（会话初始协议）信令消息的丢失导致IMS中出现错误情况，影响服务以及最终的系统弹性。

直观来看，上述解决方案的一个主要问题是其描述的方法属于被动响应型。事实上，它需要等待故障的MME虚拟网络功能重启，在此期间，由受影响的MME虚拟网络功能处理的与用户设备之间的通信将受到显著影响。

鉴于网络实体故障对移动系统中服务提供的关键性，近年来的相关文献已对此进行了广泛研究，并提出了多种解决方案。[15]中包含了一个框架，描述了在无线接入网络中实现容错的初步尝试，主要针对GSM，其主要容错手段是引入传输和覆盖冗余以及服务器复制。在云计算领域，特别是虚拟机部署方面的容错也得到了深入研究，以确保系统弹性。[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或S‐GW池[13]。此类池可服务于特定eNB，使其能够同时连接到多个MME和SGW。这样，当某个MME或S‐GW发生故障时，相关eNB内的受影响UE可以选择同一池中的另一个实体。据作者所知，此前尚无研究工作涉及EPS控制平面和数据平面节点的故障检测与恢复。由于控制平面至关重要，本文旨在设计避免双重移动注册的控制平面故障检测与恢复方法。此外，本文还引入了批量信令，该机制改进了现有方法，降低了核心网内的信令开销以及相应MME和HSS（归属用户服务器）的处理负担。我们的设想是将此类故障恢复服务作为自组织网络（SON）提供

函数[24][25],，使得网络节点能够自主处理并适应MME池，同时受影响的MMEs的重新配置过程是无缝的。

III. VNF故障恢复：MME虚拟网络功能案例

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

在图4a中，单个VNF以一对一映射方式在单个虚拟机上实例化。在图4b中，单个VNF的组件以一对多映射方式在一组虚拟机上实例化。其中一个虚拟机运行负载均衡器，将传入请求的处理任务分配给运行底层VNF逻辑（即VNF‐L）的多个虚拟机。中央数据库可以在一个独立的虚拟机上实例化，用于存储连接到该VNF的所有用户设备的状态信息。对于一对一映射的实现选项，一旦发生VNF故障（即提供该虚拟机的物理硬件层面或VNF软件层面的故障），需通过在另一个虚拟机上快速实例化一个类似的VNF、从其他网络节点恢复丢失的状态信息（如下文所述），并将受影响的部分或全部用户设备重新定位到新实例化的VNF（或另一个合适的现有VNF）来实现及时恢复。对于一对多映射的实现选项，运行VNF逻辑的任一虚拟机发生故障时，可通过将传入请求重新分配给正常工作的VNF‐L虚拟机进行缓解，直至新的VNF‐L虚拟机被实例化。

运行负载均衡功能的虚拟机发生故障也可通过迅速实例化一个新的虚拟机，在各VNF‐L虚拟机之间执行负载均衡来轻松恢复。然而，中央数据库虚拟机发生故障可能导致重要状态信息的丢失，且这些信息难以恢复。还可能阻碍VNF‐L虚拟机的正常运行，从而导致整个VNF完全失效。

部分丢失的状态信息可从服务于受影响用户设备的其他网络节点恢复，具体如下文所述。在本文其余部分，我们考虑最坏情况，即整个VNF发生故障，如一对一映射实现选项中的情形（或者，在一对多映射实现选项中，中央数据库虚拟机发生故障的情况）。

所提出的VNF故障恢复框架结合了多种机制，每种机制都有特定的目标，但均旨在实现主动且及时的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故障也可由邻近的MME VNF（即部署在其他数据中心以覆盖其他服务区域的VNF）通过S10协议手段，或由S‐GW VNF通过S11协议手段检测。在本节后续部分中，我们将分别讨论如何为处于ECM空闲模式和ECM激活模式的用户设备实现MME VNF的恢复。

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

1) 原理

如图5所示，所提出的流程基于对寻呼流程的增强，从而实现对由特定MME[35]服务的所有用户设备的寻呼。实际上，“批量”寻呼的特点是使用MME信息——即全球唯一临时标识符（GUTI）的主部分——作为标识符[3]。如图5所示，在检测到MME虚拟网络功能1发生故障后，所有通过S1‐MME接口与MME虚拟网络功能1相连的eNBs将针对该故障的MME虚拟网络功能1所服务的所有用户设备发起批量寻呼，寻呼消息中包含故障MME虚拟网络功能的标识以及用于避免过载的一些指示信息（例如，随机化时间间隔）。

稍后将详细说明。在重新附着过程中，eNB会考虑负载均衡，将响应的UE重新分配到仍在运行的MME虚拟网络功能上。由UE发起的服务请求流程作为对寻呼的响应，将间接导致重新附着，其顺序如下：实际上，UE向eNB发送SERVICE REQUEST消息。由于最初分配的MME虚拟网络功能发生故障，eNB需要通过释放无线资源控制（RRC）连接（例如，使用原因“需要负载均衡TAU”[3]）将UE重分配到另一个MME虚拟网络功能。UE将重新建立RRC连接，随后执行跟踪区更新。该机制原则上会导致大量UE同时重新附着。为了避免新选中的MME虚拟网络功能过载，应将重新附着尝试在时间上分散进行。这可以通过多种机制实现，具体将在后文解释。除了上述基于服务请求的流程外，UE在接收到因MME虚拟网络功能故障而触发的寻呼消息后（例如，通过寻呼消息中的标志指示），也可按照常规附着流程[3]重新附着到网络。处于空闲模式且受MME虚拟网络功能故障影响的UE的寻呼，也可由相邻MME虚拟网络功能发起。一般来说，如果两个MME在其管理的服区中至少共享一个共同的跟踪区，则称MME虚拟网络功能A为MME虚拟网络功能B的邻居[13]。实际上，一个或多个相邻MME虚拟网络功能可能检测到某MME虚拟网络功能的故障，随后启动针对空闲模式UE的批量寻呼，包含故障MME虚拟网络功能的标识以及一些避免过载的指示信息，以触发相应UE重新附着到网络（例如，如[3]所示，指示“需要负载均衡TAU”）。

在此方案中，重复寻呼将被最小化，甚至完全避免。这可以通过不同的方法实现。如果相邻的MME虚拟网络功能检测到MME虚拟网络功能故障，则立即启动对相关用户设备的寻呼，并通知其相邻的MME虚拟网络功能，已对相关用户设备进行了寻呼，对方无需再执行此操作。该机制假设MME虚拟网络功能事先了解能够覆盖故障MME虚拟网络功能的MME虚拟网络功能池。如果运营与维护（O&M）检测到MME故障并通知相邻的MME虚拟网络功能，则运营与维护（O&M）会明确指示每个MME虚拟网络功能应寻呼的跟踪区。此外，eNB可过滤来自不同MME虚拟网络功能的重复寻呼消息。在不可避免接收到重复寻呼消息的情况下，用户设备仅处理第一个寻呼消息，并丢弃后续的寻呼消息。为了实现负载均衡，相关的eNB运行MME虚拟网络功能负载均衡方案（排除故障的MME虚拟网络功能），以确保并非所有用户设备都连接到[3]中的同一个MME虚拟网络功能。若用于处理受影响UE的MME虚拟网络功能采用上述1:N方式实现，则可在eNB处省略此类负载均衡。

2) 批量信令管理

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

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

同样重要的是，应避免eNB因受事件影响的用户设备发送过多信令消息而发生拥塞。这可以通过调度寻呼和/或其响应来实现。事实上，可在MME虚拟网络功能或eNB处按批次执行批量寻呼

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

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

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

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

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

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

对于处于ECM连接模式且受到MME虚拟网络功能故障影响的用户设备，其目标是在不影响用户设备正在进行会话的前提下，从分布在不同网络实体（例如S‐GW虚拟网络功能、P‐GW虚拟网络功能和eNB）上的信息中恢复此前在故障的MME虚拟网络功能中存储的上下文/状态信息。从不同的网络实体中恢复状态信息片段可能是一种可行的方法，特别是在以1:N方式实现的网络功能虚拟化中，运行中央数据库的虚拟机发生故障时尤为适用。现有技术的解决方案是将所有信息复制/镜像到高弹性节点或VNFs的高弹性数据库实现中。因此，每当MME虚拟网络功能发生故障时，用户设备的上下文信息即可从这些镜像中立即恢复。然而，这种方法在配置方面显然成本较高。相比之下，本节后续所述的解决方案基于网络元或功能之间更智能、协作性的行为，从而实现显著简化的MME虚拟网络功能实现，符合运营商云愿景[2][6]。具体而言，在服务中的MME虚拟网络功能发生故障后，新选中的MME虚拟网络功能将从eNBs（图9中的步骤1）和S‐GW虚拟网络功能（图9中的步骤3）恢复状态信息。

新的MME虚拟网络功能从S‐GW虚拟网络功能中恢复的状态信息（步骤3）包括每个用户设备的承载信息，如国际移动用户识别码、移动设备标识、用于S11/S4接口的S‐GW隧道端点标识符、PDN网关IP地址以及用于S5/S8接口的隧道端点标识符、用于S1‐u接口的eNB隧道端点标识符、PDN计费特性以及EPS承载QoS。新的MME虚拟网络功能从eNBs中可恢复的状态信息（图9中的步骤1）包括每个用户设备的EPS

承载信息（TEID和eNB IP地址）以及聚合最大比特率（AMBR）。由于需要为大量用户设备交换每个UE和EPS承载的信息，eNB/SGW与MME虚拟网络功能之间的信息交换（步骤1‐4）也可以通过批量信令或配置文件ID创建来实现（即每个UE和EPS承载的信息可以在一次信令交换中聚合）。提出方案的流程图如图9所示。该机制适用于每个位于曾由故障的MME虚拟网络功能服务的跟踪区内的eNB。它仅涉及那些处于连接模式且已向故障MME虚拟网络功能注册的用户设备。请注意，eNB可以轻松识别这些用户设备。该方案的步骤如下：

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

2) eNB向选定的MME虚拟网络功能发送用户设备的S1承载信息，请求进行用户设备上下文更新。提供的部分上下文信息可包括用户设备的国际移动用户识别码、对应的S‐GW虚拟网络功能以及更新原因（即相关MME虚拟网络功能发生故障）。对于每组形成的用户设备，也可执行批量更新请求。

3) MME虚拟网络功能随后向相应的S‐GW虚拟网络功能发送更新接入承载请求，以查询用户设备的S1承载信息。MME虚拟网络功能还可以将用户设备分组为不同的组，并通过唯一且本地标识的方式，对每个形成的用户设备组批量发送更新承载请求。

4) 作为响应，S‐GW虚拟网络功能发送一条更新接入承载响应。此处还可以包含相应的PDN‐GW虚拟网络功能的信息。5) 作为确认，新选中的MME虚拟网络功能向eNB发送S1 UE上下文更新响应。6) 当用户设备检测到MME虚拟网络功能故障（例如，在尝试使用旧GUTI发起新的PDN连接后收到错误消息）或被触发执行跟踪区更新（例如，通过eNB发送的RRC连接信令消息），它将发送跟踪区更新。随后将发生MME虚拟网络功能重定位，且不影响用户面，从而确保服务连续性。

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

IV. 分析模型

A. 系统模型

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

不同的转换如下：

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

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

如果在已有i（0 ≤ i ≤ 0）处于激活状态且MME虚拟网络功能处于激活状态时发生MME虚拟网络功能故障，则系统将从状态（i, 1）转移到状态（i, 0），并伴随f。

如果MME虚拟网络功能在已有i（0 ≤i ≤ n）激活的情况下恢复，则系统以速率r从状态（i,0）转移到状态（0.0）。

我们认为这一转移的原因是：从MME虚拟网络功能故障中恢复将导致其重启，或在新的虚拟机上实例化一个类似的MME虚拟网络功能。然而，在eNBs变为激活之前，没有用户设备会附着到已重启或已实例化的MME虚拟网络功能上。

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虚拟网络功能恢复后处于空闲（或激活）模式的用户设备数量。然后有NA +NI = n

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

因此期望是

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

B. 性能指标

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

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

1) 信令开销

在MME虚拟网络功能发生故障后、以及一个预定义的时间周期T内，信令开销使我们能够比较上述方案因交换的信令消息所产生的成本。对于无智能的跟踪区更新操作，交换的信令消息的平均大小如下所示：

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

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内发送TAU消息的概率。该概率等于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的跟踪区更新方案，平均信令开销由以下公式给出：

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信令消息的丢弃概率。我们用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和HSS），每个实体具有平均比特处理速度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. 场景

本节使用上述基于马尔可夫链的分析模型对上述四种机制的性能进行评估和比较。设想的网络由一个MME、一个eNB以及连接到该eNB的200个用户设备组成。我们

定义ρ= λ µ 为用户设备处于空闲模式的时间长度与处于激活模式的时间长度之比。ρ的值越高，用户设备处于激活模式的可能性就越高。我们假设eNB无法同时处理超过20个TAU请求；当同时到达eNB的TAU请求超过此数量时，多余的请求将被拒绝

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

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

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

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

B. 结果

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

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

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

在图13中也观察到了类似的趋势，该图绘制了在四种信令管理方案下以及在两种场景中的平均处理时间。基于批量信令的机制优于所有其他机制，因为它显著减少了需要处理的消息数量，从而大幅