移动边缘计算中的热点缓解
摘要
由于从云数据中心访问服务的延迟较长，移动边缘计算（MEC）被提出以在靠近移动用户的位置提供云计算能力。移动设备可以将计算密集型应用卸载到MEC服务器，以提升性能并降低功耗。由于用户移动性，MEC服务器的工作负载会剧烈变化，导致负载不均衡并引发热点服务器问题。以往关于节能和热点管理的研究将适用于云数据中心的机制应用于MEC服务器，但由于MEC服务器的计算和通信能力有限，这些研究可能并不适用。因此，我们提出了一种面向MEC的热点缓解的互补卸载（COHM）方案。COHM包含针对处于不同状态（即繁忙、空闲和可用）的MEC服务器的机制，这些机制联合考虑不同状态MEC服务器上的计算任务，以实现热点缓解。仿真结果表明，COHM能够在不降低应用服务质量的前提下减少热点服务器的数量。
索引词
5G网络，移动边缘计算，热点缓解，节能
1 引言
国际电信联盟（ITU）和欧洲电信标准协会（ETSI）提出第五代（5G）无线移动网络，以应对海量的移动流量[1]。其中很大一部分移动流量可能由计算密集型移动应用产生，例如互动游戏、虚拟/增强现实以及3D全息图像。这些应用通常依赖高性能计算能力，并导致高功耗。例如，典型的人脸识别应用包含五个任务：图像采集、人脸检测、预处理、特征提取和分类[2]。计算能力有限的移动设备可完成图像采集，而其他任务则可卸载到云端的远程服务器上执行。然而，将计算任务卸载到远程中心云数据中心（CDCs）可能会带来更高的传输延迟和额外的带宽消耗。移动边缘计算（MEC）被提出，通过在无线接入网（RANs）边缘部署服务器，为用户提供就近的云计算能力[3]。移动服务提供商可通过基于虚拟化技术将应用迁移到MEC服务器，从而缩短传输延迟。目前，虚拟化技术主要有两种类型：虚拟机（VM）和容器[4]。本文聚焦于基于虚拟机（VM）的虚拟化技术，原因在于容器之间存在复杂的依赖关系。
大多数关于多接入边缘计算卸载的研究都集中在降低移动设备的功耗[5]。这些研究假设MEC服务器的功耗与云中的服务器相似，并且假设采用虚拟化技术以实现灵活的资源供应。基于虚拟机的虚拟化技术可以执行不同类型的虚拟机迁移，即冷迁移、热迁移和实时迁移[6],[7]。MEC卸载面临的挑战如下所列。
- MEC服务器在数量和容量上均有限，与云数据中心（CDC）中的计算资源相比。
- 由多接入边缘计算服务器执行的任务通常对延迟敏感且计算密集。例如，增强现实应用要求响应延迟小于6毫秒。由于多接入边缘计算服务器中的资源相对有限，用于虚拟机迁移的资源消耗可能过高，从而影响同一主机上的其他服务。
- 虚拟机迁移可能会导致系统停机。例如，冷迁移或热迁移可能会关闭或暂停客户操作系统[6]。尽管实时迁移可以缩短系统停机时间，但应用程序的服务水平仍然会下降[11]。
- 由于用户移动性，MEC服务器的工作负载可能会发生剧烈变化，从而可能导致流量不平衡和MEC服务器过载。过载的服务器被称为热点[12]–[15]。一个热点可能由于网络带宽或中央处理器过载而产生。由于多接入边缘计算服务器将计算密集型任务从移动设备上卸载，过载的MEC服务器将导致更高的功耗和温度，而较高的温度可能会损坏硬件设备。
以往针对云计算的热点管理研究可能不适用于MEC服务器，因为这些研究仅处理过载或过热问题[12]–[15]。负载均衡方案也可以缓解热点问题[12]。然而，负载均衡可能会引发更多的虚拟机迁移，导致源和目标MEC服务器产生较高的迁移开销[16]。MEC服务器之间虚拟机迁移的网络开销也比中央数据中心更大。据我们所知，目前尚无关于MEC环境下热点缓解的研究。因此，我们尝试在MEC环境中通过不迁移虚拟机的方式来缓解热点问题。
在本研究中，我们提出了一种新的方案——用于缓解MEC服务器热点的互补卸载方案（COHM），该方案无需执行虚拟机迁移即可缓解MEC服务器的热点问题。我们方案的贡献如下：
- 通过转发来避免虚拟机迁移的想法
- 将请求分配到不同的MEC服务器的方案被提出。
- 分析了多接入边缘计算的请求转发延迟和功耗。
- 针对不同状态的MEC服务器开发了三种机制，以减少热点数量和功耗。
本文的其余部分组织如下。在第2节中，我们介绍背景知识。第3节给出了系统模型。我们在第4节介绍了所提出的方案。第5节展示了仿真结果。第6节对本文进行总结。
2 背景
2.1 移动边缘计算
移动云计算旨在为远程CDC[17]上的移动设备提供计算服务。然而，移动设备与远程CDC之间的距离过长可能导致应用的延迟过高而无法接受。此外，移动设备与远程CDC之间的数据传输还会消耗大量带宽，从而降低回传网络的性能。
云微粒是多接入边缘计算三层架构的首个提议[18]。它采用多个虚拟机为附近用户提供低延迟应用支持。云微粒可部署在蜂窝基站或Wi‐Fi接入点（AP）中，距离移动设备仅一到两跳的距离[19]。它可以将移动设备的计算和数据卸载到定制的虚拟机上。计算卸载为移动设备提供了额外的计算能力。数据卸载通过在云微粒中缓存数据，改善了移动设备与云之间的数据传输。由于Wi‐Fi网络覆盖范围有限，基于云微粒的架构无法保证服务的普遍可用性[20]。此外，由于计算资源有限，云微粒也无法容纳大量用户。
多接入边缘计算（MEC）的概念由欧洲电信标准协会（ETSI）进一步扩展，其中MEC被定义为一种新兴平台，“在无线接入网（如3G/4G宏小区和小蜂窝基站）中靠近移动用户的位置提供IT和云计算能力”[3]。在MEC的网络架构中，服务器部署在蜂窝网络中，每个MEC服务器连接一个附近基站。电信云定期从所有基站收集无线接入网上下文信息（小区ID、位置、网络负载和无线资源）。基于这些信息，可确定新计算任务的部署以及现有计算任务的迁移。
2.2 热点与功耗
热点是由远程设备将任务卸载到云计算服务器所引起的。MEC服务器的热点是由于执行来自移动设备的计算密集型应用任务而产生的。这些移动应用包括游戏、基于人工智能的智能服务或增强现实等视觉应用。由于移动设备资源有限，这些任务被卸载到基站的MEC服务器上。由用户移动性引起的多变移动流量可能导致负载不均衡，从而形成热点。热点通常消耗更多电力，并导致更高的运行温度。因此，一个热点MEC服务器可能成为一个过热节点，并增加停机概率。
2.2.1 MEC服务器的功耗
MEC服务器的功耗取决于其组件（如中央处理器、存储、内存和网络接口）的使用率[17]。我们假设MEC服务器的功耗模型与中央数据中心中服务器的功耗模型相同。CPU利用率是云服务器功耗最具影响力的因素[7]。先前的研究表明，服务器的功耗与CPU利用率比率呈线性关系[7]–[9]。我们假设有 I个同构边缘计算服务器，每个服务器部署在基站附近。服务器 i在时间间隔t内的功耗与其CPU利用率之间的关系可以表示为
$$
P_i(t)= P_{idle}(t)+(P_{peak}(t)− P_{idle}(t))U_i(t), \quad \forall i \in I \quad (1)
$$
其中， $P_{idle}(t)$和 $P_{peak}(t)$分别表示服务器$i$在完全空载和满载条件下的功耗。 $U_i(t)$表示服务器使用率。在另一项研究中，通过综合考虑使用率和电源使用效率（PUE），利用以下公式[22]计算服务器的功耗：
$$
P_i(t)=P_{idle}(t)+(P_{peak}(t)− P_{idle}(t))U_i(t)+(PUE − 1)P_{peak}(t). \quad (2)
$$
PUE（电源使用效率）表示计算机设施消耗的总电量与提供给计算设备的电量之比，其中总功耗包括用于冷却和其他运行计算设备所需的开销。较低的PUE值表示更高的能效。采用冷水冷却的中央数据中心（CDC）的PUE值可低至1.07[23]。由于基站（BS）通常部署在城市化地区，中央数据中心中先进的冷却技术无法应用于这些基站。在本研究中，我们假设MEC服务器的PUE值为1.5。
先前的研究表明，移动设备在安全通信[24]上会额外消耗约10J的功耗。对于移动设备而言，由于电池容量有限，这种额外的功耗可能带来较大的开销。然而，MEC服务器具有足够的计算能力来处理加密算法。因此，我们假设安全通信带来的额外功耗可以忽略不计。
2.2.2 中央数据中心的虚拟机管理
云服务提供商基于虚拟机迁移[12]来管理计算资源。管理策略包括服务器整合、负载均衡和热点缓解。我们将其介绍如下：
- 服务器整合 ：旨在减少低负载服务器的数量。以往的方案通过将空闲服务器上的负载整合到少量活动服务器上，使空闲服务器进入睡眠模式。传统中心云数据中心的节能方案依赖动态按需调整策略来预测服务器利用率。相应地，可以通过迁移虚拟机来关闭空闲服务器。
- 负载均衡 ：旨在均衡服务器的负载。因此，负载均衡方案也能减少热点。然而，此类方案会导致更高的迁移开销，因为需要迁移更多任务以平衡不同服务器之间的流量负载。
- 热点缓解 ：一个热点可能会导致其虚拟机无法获得足够的资源，从而无法满足服务质量的要求（服务质量）。这些虚拟机可以迁移到其他服务器以缓解热点问题。Beloglazov等人采用具有不同阈值的最佳适配策略进行虚拟机迁移[14]。他们的方案使用最大迁移时间来检测热点位置[15]。Mishra等人综合考虑中央处理器、内存和网络利用率，用于整合、负载均衡和热点缓解[12]。Sohrabi等人基于中位迁移时间和最大利用率进行虚拟机迁移[13]。据我们所知，目前尚无针对多接入边缘计算的热点问题的研究工作。
虚拟机迁移技术包括冷迁移、热迁移和实时迁移。冷迁移在迁移整个虚拟机堆栈（包括磁盘和内存）之前，可能会使虚拟机长时间停止运行[26]。虚拟机实时迁移仅在短时间内停止虚拟机，以传输最近使用的内存内容[27]。所有迁移技术不仅会产生系统停机时间，还会增加功耗[6],[16]。
2.2.3 移动边缘计算的虚拟机管理
已有研究提出了针对移动设备或MEC服务器的节能方法。本文重点关注面向MEC服务器节能问题的研究。我们提出了一种高效的在线算法——ENGINE（能量受限的卸载与休眠），在保持低能耗的同时最大化服务质量[30]。ENGINE同时考虑了计算卸载和基站休眠。该算法采用李雅普诺夫优化技术进行在线计算，无需预测服务器负载即可实现近似最优性能。然而，同时关闭基站及其连接的MEC服务器可能会显著增加其他MEC服务器的负载。Carrega等人提出了对OpenStack的扩展，通过虚拟机迁移实现功耗管理与服务质量保障[31]。他们的研究表明，虚拟机迁移可能带来开销，包括数据丢失、丢包和网络拥塞。
另一个新概念通过能量收集技术利用可再生能源为移动设备供电[34]。EARN利用配备太阳能电池板的绿色微云，最小化服务器和迁移的总功耗。采用混合整数线性规划（MILP）工具箱来求解NP难问题[16]。
总之，传统的针对中心云数据中心或MEC的节能方案主要基于虚拟机迁移技术。然而，在MEC中迁移虚拟机会为延迟敏感型应用带来较高的成本和延迟。因此，我们提出了一种新的方案，用于缓解MEC服务器的热点问题，且无需执行虚拟机迁移。
3 系统模型
在介绍所提出的机制之前，我们描述了适用于本方案的多接入边缘计算（MEC）系统模型。每个基站（BS）配备有一个MEC服务器和一个微小区管理器（MCM），其中 MCM负责管理虚拟化的计算和/或存储资源。图1展示了 MEC系统中MCM之间的通信架构。该系统由 I个小区组成。MCM之间通过专用链路（图1中的虚线）交换控制消息。这些控制消息包括网络信息、存储容量以及各MEC服务器中的计算资源。因此，MEC服务器可以直接相互获取信息，而无需经过服务网关（SGW）。
缩短传输延迟。蜂窝网络中的用户数据通过服务网关转发。如上所述，多接入边缘计算（MEC）与云计算的网络架构不同。在数据中心中，虚拟机迁移的网络成本低于MEC系统中的网络成本。由于MEC服务器位于不同的小区，两个 MEC服务器之间的数据传输可能需要数毫秒（ms）。因此，在MEC中应避免对延迟敏感和计算密集型应用进行虚拟机迁移。本文假设管理系统按计划每天执行一次虚拟机迁移。相应地，我们的方案尝试通过将流量从繁忙和空闲服务器卸载，而不是在MEC服务器之间迁移虚拟机来实现负载均衡。流量卸载通过将请求转发至邻近MEC服务器上的虚拟机来实现。当某个MEC服务器过于繁忙而无法处理请求时，它可以通过服务网关（SGW）将请求转发给其他MEC服务器。随后，这些MEC服务器处理请求并将响应返回给原始MEC服务器。
接下来，我们分析该请求转发机制的转发延迟和功耗。
3.0.1 转发延迟
我们首先分析请求转发机制的转发延迟，其中符号定义列于表1中。假设在小区 i内有 N个用户随机移动。用户 u ∈ N在间隔 t内到最近的MEC服务器 i的传输延迟表示为
$$
D_{u-i}(t)=D_{up}^{u-i}(t)+2 × D_{BS}^i(t)+ D_{MEC}^{i,u}(t)+ D_{down}^{i-u}(t)+ \sigma D_{forward}^{i-j}(t). \quad (3)
$$
$D_{up}^{u-i}(t)$表示用户u到最近的MEC服务器 i的上行链路传输延迟。 $D_{down}^{i-u}$是从最近的MEC服务器 i到用户 u的下行链路传输延迟。 $D_{BS}^i(t)$表示基站的处理延迟。$D_{MEC}^{i,u}(t)$是MEC服务器 i对用户 u任务的处理延迟。$D_{forward}^{i-j}(t)$被定义为
$$
D_{forward}^{i-j}(t)=D_{i-g}(t)+2 × D_{SGW}^g(t)+ D_{g-j}(t)+ D_{j-g}(t)+ D_{g-i}(t), \quad (4)
$$
| 符号 | 含义 |
|---|---|
| u | 小区 i中的用户 |
| N | 小区 i中的用户数量。 |
| $D_{u-i}(t)$ | 用户 u到MEC服务器 i的传输时延 在间隔 t。 |
| $D_{up}^{u-i}(t)$ | 用户 u上行链路中的传输延迟 最近的MEC服务器 i在间隔 t。 |
| $D_{down}^{i-u}(t)$ | 下行链路中从closet的传输延迟 MEC服务器 i在间隔 t内向用户 u发送。 |
| $D_{BS}^i(t)$ | MEC服务器 i在该间隔内的基站处理延迟 t. |
| $D_{MEC}^{i,u}(t)$ | MEC服务器 i处理用户任务的处理延迟 用户 u在时间间隔 t内的任务。 |
| $D_{forward}^{i-j}(t)$ | 从MEC服务器 i传输到另一个 MEC服务器 j在时间间隔 t内的传输延迟。 |
| $\sigma$ | 转发到另一个MEC服务器的数据包比例 j. |
| g | MEC系统中的服务网关。 |
| $D_{SGW}^g(t)$ | 服务网关在区间 t的处理延迟 g。 |
| $D_{th}^A(t)$ | 应用 A在互连时的最大响应时间 值 t。 |
| $D_{CDC}^c(t)$ | 在时间间隔内，远程云 c中的处理延迟 t. |
| $D_{up}^{u-c}(t)$ | 从用户 u到上行链路的传输延迟 远程云 c在时间间隔 t。 |
| $C_u(t)$ | 处理所需的CPU周期数 在间隔 t卸载的工作负载 |
| $f_i(t)$ | MEC服务器 i在区间 t的处理速率。 |
| d | $D_{MEC}^i$的退化因子(t)。 |
| $\gamma$ | MEC服务器 i在间隔 t内的虚拟机数量。 |
| $D_U(T)$ | MEC系统在该区间内的平均延迟 T. |
其中 $D_{SGW}^g(t)$是服务网关 g的处理延迟。在本文中，我们假设 $D_{BS}^i(t)$和 $D_{SGW}^g(t)$足够短，可以忽略不计。
中心云数据中心的应用管理系统根据蜂窝流量确定是否在 MEC服务器中部署移动应用的副本。由于MEC服务器资源有限，仅部署延迟敏感型或计算密集型应用的副本。若应用 A满足 $D_{u-i}(t) \leq D_{th}^A(t)$，其中 $D_{th}^A(t)$为最大响应时间，则该应用为延迟敏感型。 $D_{th}^A(t)$通常小于或等于100 ms。
当基站收到用户的请求时，会检查该应用是否已在连接的 MEC服务器上部署。如果连接的MEC服务器中存在该应用的副本，则基站将把这些请求转发到MEC服务器。否则，这些请求将被转发至远程CDCs。用户 u到远程云 c的平均延迟定义为
$$
D_{u-c}(t)=D_{up}^{u-c}(t)+2 × D_{BS}^i(t)+ D_{i-g}(t)+2 × D_{SGW}^g(t)+ D_{g-c}(t)+ D_{CDC}^c(t)+ D_{c-g}(t)+ D_{g-i}(t)+ D_{down}^{i-u}(t), \quad (5)
$$
其中 $D_{CDC}^c(t)$是远程CDC中的处理延迟。从蜂窝网络到远程CDC的长传输延迟可能会降低满足延迟要求的数据包比例。
每个MEC服务器并行为不同用户的独立计算任务分配 $\gamma$ 个虚拟机[36]。服务器 i, $D_{MEC}^{i,u}$的处理时间可通过以下公式计算：$D_{MEC}^{i,u}(t)= C_u(t) / f_i(t)$。 $C_u(t)$表示在时段 t处理卸载工作负载所需的CPU周期数， $f_i(t)$是MEC服务器 i的处理速率。我们不考虑卸载任务的排队延迟。由于多个虚拟机共享多接入边缘计算服务器的计算和存储资源，多接入边缘计算服务器中不同虚拟机之间的I/O干扰可能会产生。基于先前的研究[37],，我们通过以下公式计算使用I/O接口时的处理延迟： $D_{MEC}^{i,u}(t) = D_{MEC}^{i,u}(t) \cdot (1 + d(\gamma - 1))$，其中d为退化因子。我们还采用了先前研究[37]中相同的 d=0.2值。当MEC服务器 i将数据包转发到另一个MEC服务器 j时，MEC服务器 j对传入的数据包也需要$D_{MEC}^{j,u}(t)$的处理时间。
3.0.2 功耗
接下来，我们考虑MEC服务器的功耗。表2列出了相关符号的定义。MEC服务器 i, $P_i(t)$的功耗通过使用公式(2)进行计算。每个MEC服务器定期将其资源使用率和功耗信息通知其基站的 MCM。然后，中心云数据中心周期性地从各MCM收集无线接入网上下文信息。当某个MEC服务器 i, $U_i(t)$的CPU使用率小于或等于服务器低负载阈值（或 $U_{lth}$）时，该MEC服务器被标记为空闲。如果$U_i(t)$大于或等于服务器过载阈值（或$U_{uth}$），则 MEC服务器 i被标记为繁忙，即该MEC服务器成为热点。既非空闲也非繁忙的服务器状态为可用，即 $0 < U_{lth} < U_i(t) < U_{uth} < 1$。
以图1中的示例为例， Cell3中的MEC服务器处于忙碌状态。 Cell1和 Cell6中的MEC服务器处于空闲状态，其他服务器处于可用状态。 Cell3中服务器的开销是由其基站伴随大量移动用户所产生的密集流量引起的。由于忙碌服务器会导致更多的失败响应，中心云数据中心应将 Cell 3中的流量卸载到其他处于可用状态的MEC服务器，以降低服务器使用率。在之前的研究[38],中，低负载阈值设置为百分之二十，即 $U_{lth}=20\%$，过载阈值设置为百分之一百，即 $U_{uth}=100\%$。
当MEC服务器 i向MEC服务器 j转发数据包时，MEC服务器 j需要消耗额外的功耗 $P_{forward}^i(t)$来处理这些数据包。MEC j的功耗表示为
$$
P_j(t)= P_{local}^j(t)+ \sigma P_{forward}^i(t). \quad (6)
$$
$P_{local}^j(t)$是MEC服务器 j处理其自身蜂窝网络中数据包的功耗。 $P_{forward}^i(t)$是来自MEC服务器 i的数据包的功耗。
| 符号 | 含义 |
|---|---|
| $U_{peak}^i(t)$ | MEC服务器 i的最大CPU利用率 间隔 t。 |
| $P_i(t)$ | MEC服务器 i在区间 t的使用率 |
| $U_{lth}$ | MEC服务器的CPU利用率低于阈值 old. |
| $U_{uth}$ | MEC服务器的中央处理器利用率过载阈值 old. |
| $P_{local}^j(t)$ | MEC服务器 j处理的功耗 来自其自身的蜂窝网络的数据包。 |
| $P_{forward}^i(t)$ | MEC服务器数据包的功耗 i在间隔 t处。 |
| $P_I(T)$ | MEC系统的平均功耗 在区间 T期间。 |
我们通过以下公式得出MEC系统的平均功耗 $P_I(T)$以及平均延迟$D_U(T)$：
$$
P_I(T)= \frac{\sum_{t\in T}\sum_{i\in I} P_i(t)}{IT} \quad (7)
$$
$$
D_U(T)= \frac{\sum_{t\in T}\sum_{u\in U} D_u(t)}{UT}. \quad (8)
$$
$D_u(T)$可能等于 $D_{u-i}(T)$或 $D_{u-c}(T)$。我们注意到 $P_I(T)$与 $D_U(T)$之间存在权衡。最小化$P_I(t)$可能会降低系统性能，因为没有足够的服务器来处理请求，从而可能导致部分服务器过载并形成热点。相反，最小化 $D_U(t)$可能会因有更多活跃的服务器而产生额外的功耗。我们致力于开发一种方案，能够在多接入边缘计算中同时提高满足 $D_{th}^A$的数据包比例并减少热点数量。
4 热点缓解的提出机制
所提出的方案，即热点缓解的互补卸载（COHM），在中心云数据中心中实施。对于在小区 i 中随机移动的 N 个用户，其计算密集型和延迟敏感型应用被卸载到 MEC 服务器。在时间间隔 t 内，MEC 服务器 i 处理每个任务需要 $C_u(t)$ CPU周期；因此， $U_i(t)= C_u(t)/f_i(t)$。先前的研究表明，无线网络和有线网络具有不同的流量特征[39]。由于用户移动性，在典型蜂窝网络中预测移动流量趋势较为困难[40]。在本研究中，我们假设当前流量与前一个时间间隔的流量相关。因此，COHM 利用前一个时间间隔的网络信息和 CPU 利用率来确定下一个时间间隔内的请求转发安排。
我们在图2中展示了COHM的过程。系统部署了一个协调器来管理MEC服务器的任务转发。在每个区间开始时，例如 t，COHM协调器收集每个蜂窝网络中的流量统计信息以及上一个区间内繁忙、空闲和可用服务器的列表。然后，协调器利用区间 t − 1的信息生成区间 t中繁忙和空闲服务器的候选列表，该候选列表包含一组处于可用状态的服务器，可用于卸载空闲或繁忙的MEC服务器。随后，为每个小区生成一个转发列表，以指明来自候选列表中用于卸载的MEC服务器。该转发列表包括源基站、目标基站和卸载的流量负载。最后，协调器将转发列表提供给每个小区。每个基站在区间t根据转发列表转发请求。相应地，通过将请求转发到一个或多个MEC服务器，MEC服务器 i的流量可以在不降低性能的情况下被卸载。我们将在以下章节中介绍生成繁忙和空闲服务器候选列表及转发列表的过程。
移动边缘计算中的热点缓解
4 热点缓解的提出机制（续）
4.1 繁忙、空闲和可用服务器的列表
COHM协调器维护着繁忙、空闲和可用服务器的三个列表，用于生成转发列表。它获取每台服务器的统计信息，以确定其在每个时间间隔内是繁忙、空闲还是可用服务器。这些服务器将根据其状态被插入相应的列表中。
生成可用服务器列表的过程如算法1所示，其中时间复杂度为 O(n)。
算法1 生成繁忙、空闲和可用服务器列表的过程
1: function YIELDLISTOFSERVERS(t)
2: input: 服务器状态
3: output: 可用列表, 空闲列表, 繁忙列表
4: 可用列表 = []
5: 空闲列表 = []
6: 繁忙列表 = []
7: 对于 服务器 i 在所有多接入边缘计算服务器中，时间间隔为 t 执行
8: 如果 $U_i(t) \geq U_{uth}$ 那么
9: 忙碌服务器 i 表示为一个忙碌服务器
10: 将服务器 i 插入忙碌列表
11: 结束如果
12: 如果 $U_i(t) \leq U_{lth}$ 那么
13: 空闲服务器 i 表示为空闲服务器
14: 将服务器 i 插入空闲列表
15: 结束如果
16: 如果 $U_{lth} \leq U_i(t) \leq U_{uth}$ 那么
17: 服务器 i 表示为可用服务器
18: 将服务器 i 插入可用列表
19: 结束如果
20: 结束循环
21: return 可用列表, 空闲列表, 繁忙列表
22: 结束函数
4.2 忙服务器的转发列表
利用忙、空闲和可用服务器列表，COHM生成针对忙服务器的转发列表。由于忙服务器可能会接收大量任务而导致高使用率，因此需要更多的可用服务器进行流量卸载。如果可用服务器不足以缓解忙服务器的负载，我们的方案会将部分空闲服务器切换为可用服务器。忙服务器 i 的转发容量 $F_U^i(t)$ 通过以下公式计算：
$$
F_U^i(t) = U_i(t) - U_{uth} \quad (9)
$$
为了缓解忙碌服务器的负载，计算可用服务器的剩余容量。可用服务器 j 的剩余容量 $SU_j(t)$ 由以下公式得出：
$$
SU_j(t) = U_{uth} - U_j(t) \quad (10)
$$
算法2 为繁忙服务器生成转发列表的过程
1: function 为繁忙服务器生成转发列表(t)
2: 输入: 服务器状态，可用列表，忙碌列表
3: output: ForwardList
4: 转发列表 = []
5: 按服务器使用率降序排列忙碌列表
6: 按服务器使用率升序对可用列表进行排序
7: 对于 每个忙碌服务器 i 在忙碌列表中执行
8: 对于 每个可用服务器 j 在可用列表中执行
9: 如果 $D_{u-i}(t) \leq D_{th}^A(t)$ 那么
10: calculate $SU_j(t)$ 和 $F_U^i(t)$
11: 如果 $SU_j(t) \geq F_U^i(t)$ 且 $BW_j(t) < BW_{uth}$ 那么
12: 转发列表[i] = {Celli: {j: $F_U^i(t)$}}
13: continue
14: 结束如果
15: 结束如果
16: 结束循环
17: /* 查找合适的空闲服务器作为可用服务器 */
18: 如果 转发列表[i] 为空 则
19: 将空闲服务器 j 插入可用列表
20: 转发列表[i] = {Celli: {j: $F_U^i(t)$}}
21: 结束如果
22: 结束循环
23: 结束函数
对于每个忙服务器，选择使用率最低（或具有最大 $SU_j(t)$）的可用服务器 j 来转发流量。COHM协调器找到满足总延迟不超过 $D_{th}^A$ 的可用服务器，然后计算这些可用服务器的剩余容量和忙服务器的负载，以生成转发列表。
在为所有忙服务器生成转发列表后，我们的系统将每个转发列表广播到相应的基站。然后，每个基站根据转发列表将其请求转发到其他MEC服务器。由于MEC服务器与其基站共享通往服务网关的带宽，因此使用一个阈值 $BW_{uth}$ 来限制MEC服务器的带宽利用率，以避免因流量卸载而导致潜在的网络拥塞。我们假设 $BW_{uth}$ 等于 $U_{uth}$。根据该阈值，此过程不会将请求转发至流量负载大于 $BW_{uth}$ 的可用服务器。
转发列表表示为 {源小区: {目标服务器: 卸载流量}}。源小区表示待卸载的空闲服务器对应的基站，目标服务器是使用率最低的可用服务器。目标服务器还需满足其流量负载小于 $BW_{uth}$。卸载流量表示从源服务器卸载到目标服务器的应用工作负载百分比。
可能没有足够的可用服务器来卸载所有忙服务器的流量。系统仍然可以卸载忙服务器的部分工作负载。协调器可以记录流量卸载的成功率。运营商应升级成功率较低的服务器以减轻处理开销。算法2的时间复杂度为 $O(n^2)$。
4.3 为空闲服务器生成转发列表
COHM协调器进一步为每个空闲服务器生成一个转发列表，以将空闲服务器的流量卸载，从而实现节能。
算法3 为空闲服务器生成转发列表的过程
1: function YIELDFORWARDLISTFORIDLESERVERS(t)
2: 输入: 服务器状态，可用列表，空闲列表
3: output: ForwardList
4: 转发列表 = []
5: 按服务器使用率降序排列空闲列表
6: 按服务器使用率升序对可用列表进行排序
7: 对于 空闲列表中的每个空闲服务器 i 执行
8: 对于 每个可用服务器 j 在可用列表中执行
9: 如果 $D_{u-i}(t) \leq D_{th}^A(t)$ 那么
10: calculate $SU_j(t)$
11: 如果 $SU_j(t) \leq U_{lth}$ 则
12: 选择空闲服务器 k 作为可用服务器
13: 从空闲列表中移除 k
14: 将 k 添加到可用列表
15: 结束如果
16: 如果 $SU_j(t) \geq U_i(t)$ 且 $BW_j < BW_{uth}$ 则
17: 转发列表[i] = {Celli: {j: $U_i(t)$}}
18: continue
19: 结束如果
20: 结束如果
21: 结束循环
22: /* 查找合适的空闲服务器作为可用服务器 */
23: 如果 转发列表[i] 为空 则
24: 将空闲服务器 j 插入可用列表
25: 转发列表[i] = {Celli: {j: $F_U^i(t)$}}
26: 结束如果
27: 结束循环
28: 结束函数
通过将这些空闲服务器的计算任务卸载到其他服务器，空闲服务器可以被切换到睡眠模式以最小化功耗。如果可用服务器的剩余使用率小于空闲服务器的负载，则将部分空闲服务器切换为可用服务器。为空闲服务器生成转发列表的过程如算法3所示。它依次将空闲服务器的任务卸载到负载最轻的可用服务器上。时间复杂度是 $O(n^2)$。
同样，用于流量卸载的任何可用服务器必须满足带宽消耗低于 $BW_{uth}$ 的条件。系统为所有空闲服务器生成转发列表后，会将每个转发列表传播到相应的基站。
5 仿真结果
在本节中，我们展示了本方案的性能评估。仿真基于 Python 版 CloudSim[41] 进行。网络拓扑如图3所示。我们采用与先前研究[42]相同的传输延迟配置，其中从每个小区到服务网关（SGW）的传输延迟为5毫秒，从SGW到分组数据网络网关（PGW）的传输延迟为18毫秒。从PGW到远程 CDC 的传输延迟为6毫秒[43]。在实验中，每个MEC服务器连接到每个小区的基站。因此，由于基站与其MEC服务器之间采用高速光纤链路，我们忽略两者之间的延迟。每个基站可以是微小区或小小区，采用时分双工模式与用户设备通信。下行链路和上行链路流量的比例根据数据包的优先级进行分配[44]。
在之前的实验中采用了文献[20]中的无线模型。每个基站的传输范围为500米。每个小区内有三十个用户随机移动，并使用五个15兆赫兹信道。发射功率为100毫瓦，背景噪声为‐100分贝毫瓦。每个小区内的信道增益与用户和其基站之间的距离相关，路径损耗因子为4。我们使用先前持续144小时的数据集[45]，基于泊松分布（K=5）生成每个小区的流量。每个上行数据包为150字节，每个下行数据包为1000字节[46]。平均任务大小为27.93千字节[45]。由于移动应用可能具有不同的延迟要求，我们随机部署了两个延迟敏感型应用A和B用于多接入边缘计算。应用A的延迟为40毫秒，应用B的延迟为80毫秒。我们还部署了另一个应用C，其延迟为190毫秒，用于云[47]。由于未来5G网络的流量持续增长，我们将实际流量乘以30倍。
我们使用公式(2)来计算MEC服务器 i 的功耗，其中 $P_{peak}^i$ 为500瓦， $P_{idle}^i$ 为300瓦，该设定基于以下假设：空闲服务器的功耗约为忙碌服务器峰值功耗的一半[48],[49]。PUE的值为1.5。我们设置 $U_{lth} = 20\%$[38]。一个MEC服务器的CPU容量为10吉赫兹[20]，每个数据包比特消耗1500个CPU周期[36]。
5.1 不同 $U_{uth}$ 取值下COHM的性能
第一次仿真评估了COHM在不同 $U_{uth}$ 值下的性能。图4展示了COHM每小时转发的平均工作负载，其中图4(a)显示了转发任务的数量，图4(b)描绘了以CPU利用率表示的转发工作负载。根据公式(10)，较高的 $U_{uth}$ 值使得可用服务器对输入工作负载具有更多的剩余容量。因此，如图4(a)所示，通过设置 $U_{uth} = 0.9$ 的值，COHM转发了最多数量的任务。转发工作负载的CPU使用率与转发任务的数量成正比，如图4(b)所示。
我们进一步考虑了在图5中不同 $U_{uth}$ 值下的关注性能指标。这些性能指标按每小时测量，包括平均响应时间（图5(a)）、QoS数据包百分比（图5(b)）、每个MEC服务器的功耗（图5(c)），以及热点平均数量（图5(d)）。QoS数据包是指延迟要求得到满足的数据包。我们使用QoS数据包的百分比来衡量不同配置下的服务质量性能。
由于COHM通过设置 $U_{uth} = 0.9$ 可以从热点中缓解更多工作负载，因此数据包处理时间可以显著减少，如图5(a)所示。因此，通过设置更大的 $U_{uth}$ 值可以提高QoS数据包的比例。可用服务器中的更大剩余容量也增加了睡眠服务器的数量，从而降低总功耗。图5(d)表明，通过设置更大的 $U_{uth}$ 值，COHM能够有效消除热点。
图5表明，COHM通过将更多工作负载从热点迁移到其他服务器，使用 $U_{uth} = 0.9$ 可提供最佳性能。因此，在接下来的实验中，我们为COHM设置 $U_{uth} = 0.9$。
5.2 性能比较
接下来，我们将COHM与另外三种机制进行比较：MEC、Migration和Sleep。其中，MEC机制假设每个MEC服务器仅处理来自其所在小区的用户请求；Migration机制则可能通过将虚拟机从一个MEC服务器迁移到其他服务器，以实现节能和热点缓解；最后一种机制Sleep通过将空闲服务器切换至睡眠模式，并将请求转发至远程CDC，从而最小化MEC服务器的功耗。
首先，我们在图6中展示了每小时的平均响应时间。我们还在图中展示了下载和上传流量，以显示工作负载的影响，其中第93和94小时没有工作负载。对于迁移机制，虚拟机迁移会带来额外的延迟。虚拟机VMi的迁移延迟，记为 $D_{migration}^i$，可通过以下公式计算得出： $D_{migration}^i = S_{memory}^i / BW_i$[15]，其中 $S_{memory}^i$ 表示VM i所使用的内存大小， $BW_i$ 表示可用网络带宽。每个MEC服务器的可用网络带宽为10 Gbps。额外的CPU使用率通过以下公式测量： $0.1 \cdot \int D_{migration}^i U_i(t) dt$，其中 $U_i(t)$ 表示VM i 的CPU使用率。MEC、迁移、睡眠和COHM的平均结果分别为31.58 ms、29.78 ms、36.90 ms和27.74 ms。COHM的平均响应时间最低，优于其他方案。
这些机制。它优于MEC机制，因为它可以将请求转发到其他 MEC服务器，以避免高负载服务器带来的长时间计算延迟。迁移机制由于额外的迁移延迟，其响应时间略高于COHM。睡眠机制导致了最长的响应时间，因为它会关闭空闲的 MEC服务器，相应的基站因此将请求转发至远程CDCs，从而造成较高的响应时间，尤其是在工作负载较轻的小时段。我们还注意到，在工作负载较轻的时段，COHM为了节能可能会将请求转发到其他MEC服务器，从而产生额外的转发延迟。
接下来，我们在图7中展示了每小时QoS数据包的百分比，其中四种机制的平均百分比分别为79.02%、80.47%、73.26%和80.57%。COHM表现最佳，性能方面，由于具有最短的响应时间，因此表现最佳。Migration机制在QoS数据包方面的性能也较为优越，因为它避免了向中心云数据中心传输时产生的长传播延迟以及热点带来的高计算延迟。然而，与COHM相比，其迁移延迟仍然降低了QoS数据包百分比。Sleep机制在这四种机制中性能最差，因其响应时间较长，这是由于向中央数据中心传输时存在较长的传播延迟所致。MEC机制的性能略低于COHM和 Migration，因为在重工作负载下会遭受较长的计算延迟。
我们在图8中进一步展示了不同机制下热点（或满载的 MEC服务器）的平均数量。在所有机制中，COHM的热点数量最少。尽管迁移机制也能缓解热点问题，但由于虚拟机迁移带来的额外CPU使用率，仍会导致更多的热点。休眠机制导致的热点最多，因为它没有执行任何操作来缓解热点问题。MEC机制与休眠机制的热点数量相同。四种机制的热点平均数量分别为8.3、11.0、8.3和8.1。
图9显示了不同机制下睡眠MEC服务器的平均数量。Sleep机制由于总是将空闲服务器切换到睡眠模式，因此具有最多的睡眠服务器。相比之下，MEC机制在存在任务时不会产生任何睡眠服务器。COHM能够根据所有小区的工作负载自适应地调整睡眠服务器的数量，因此通过缓解热点问题，导致睡眠服务器数量更少。Migration机制由于迁移会产生额外的CPU使用率，其睡眠服务器数量略少于COHM。平均结果为 Migration、Sleep 和 COHM 分别为 8.3、32.0 和 11.2。
图10中的最后结果显示了每个MEC服务器的平均功耗。不同机制的平均结果分别为649.1、654.1、300.4和616.6。由于服务器的功耗与睡眠服务器的数量成反比，因此Sleep机制表现最佳，而MEC机制表现最差。Migration机制由于迁移带来的额外CPU使用率，其功耗略高于COHM。
5.3 可扩展性性能
在最后一次实验中，COHM与另外三种机制在不同小区数量下进行比较，以展示可扩展性性能。图11显示了在不同小区数量下的平均响应时间、平均QoS数据包、热点平均数量和平均功耗的结果。随着小区数量的增加，Migration和 COHM都可以利用更多的多接入边缘计算服务器来减少响应时间。因此，这两种机制的服务质量性能也随着小区数量的增加而得到改善。Sleep机制在所有机制中的响应时间最高。由于额外的小区降低了热点服务器的数量，Sleep的响应时间也随之缩短。COHM导致的热点服务器数量最少，且其功耗低于MEC和Migration。Sleep在所有机制中功耗最低，因为随着小区数量增加，睡眠服务器数量也更多。尽管 Migration的响应时间和服务质量性能与COHM相似，但它会带来额外的迁移开销，从而增加热点数量。
6 结论
在本研究中，我们提出了一种用于多接入边缘计算（MEC）的新型热点缓解方案COHM。该方案通过自适应地管理处于不同状态的MEC服务器来维持服务器负载。通过将用户任务从空闲和忙服务器进行转发，可以在不降低应用服务质量性能的前提下减少总体功耗。仿真结果表明，COHM能够减少热点服务器的数量，同时增加睡眠服务器的数量以实现节能。与原始MEC架构相比，COHM还实现了更优的响应时间。因此，COHM有助于以更高的能效支持延迟敏感和计算密集型移动应用的部署。
扫一扫
1110
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
