一种低延迟高可靠性的移动边缘计算系统实现
摘要
由于移动边缘计算（MEC）靠近移动用户，通常能够比移动云计算提供更低通信延迟的服务。与车载设备处理相比，MEC提供了更丰富的感知和计算资源。本文通过在边缘计算系统上的实际实验，验证了为移动用户提供低延迟和高可靠性的服务的效率和性能。我们首先描述了该系统的架构。然后，在静态和动态移动环境中进行实地测试以评估系统性能。结果表明，该系统具备低延迟和高可靠性，可用于运行一些非关键任务但计算密集型的任务。
相关服务：日本云服务器租用
Index Terms —移动边缘计算，低延迟，高可靠性，计算密集型
一、引言
在第五代（5G）技术蓬勃发展的推动下，物联网（IoT）也迅速发展。然而，大量的物联网设备将产生海量数据，这些数据的处理与传输值得关注。一辆自动驾驶汽车每天可产生高达4TB的数据[1]。此外，越来越多的智能网联汽车（ICVs）借助车联网（V2X）技术接入蜂窝网络。一方面，尽管5G技术保证了更大规模的移动设备连接，但难以应对数据流量的指数级增长；另一方面，巨大的数据流量可能导致严重的网络拥塞。
由于智能网联汽车（ICV）和其他物联网设备的可用资源（如计算和存储资源）受限，虽然可以通过升级设备硬件来提升其性能，但这将导致高昂的成本。因此，一些非关键性但计算密集型的任务，例如基于视觉的目标检测与识别、异构数据融合，可以卸载到其他更强大的服务器上执行。一种可能的解决方案是移动云计算（MCC）[2]。
然而，由于云服务器与移动用户之间的物理距离过长，将任务卸载至云服务器会带来较长的传播延迟，导致许多实时应用（尤其是自动驾驶）无法实现[3]。为解决该问题，移动边缘计算（MEC）被广泛认为是一种有前景的解决方案[4]。MEC旨在将计算能力迁移至网络边缘的小型服务器。相比之下，与MCC相比，用户到边缘服务器的通信延迟更低。此外，由于连接了大量传感器，MEC拥有更丰富的资源。而且，MEC还具备宏观调度能力，例如对交叉路口大量车辆进行车辆碰撞检测与预警。
本文描述了一种边缘计算系统的设计，其具有以下特征。该边缘计算系统也可应用于支持车对车通信和车联网任务卸载的车辆环境[5],[6]。
1) 低通信延迟。在静态场景下，系统端到端延迟不超过100毫秒；在动态场景下，系统端到端延迟从72.4毫秒到290.4毫秒。系统调度算法的性能也在[7]中得到验证。
2) 高服务可靠性。在静态实验中，数据包丢包率（PLR）为0；在动态实验中，丢包率（PLR）为0.03%。
本文的其余部分结构如下。在第二节中，我们描述了系统的设计。在第三节中，进行了一些实验来评估系统的性能。我们在第四节中得出结论。
II. 系统模型
A. 架构
通常，MEC系统可以分为三层[8]，如图1所示。第一层是移动设备（MD）层，可以是手机、智能网联汽车以及其他物联网设备。各种类型的移动设备都可以通过LTE或5G网络接入边缘服务器（ESs）。第二层是MEC服务器层。与移动设备相比，边缘服务器具有更强大的计算和感知资源。由于移动设备的可用资源受限，它们需要将一些计算密集型任务卸载到边缘服务器。这样，移动设备的部分任务在本地完成，其他任务则可能被卸载到边缘服务器上执行。MEC服务器可以部署在基站或其他无线接入点旁边。
第三层是云服务器层。与边缘服务器相比，将任务卸载到云服务器会导致更长的传播延迟。因此，一些非延迟敏感服务（如人脸识别）可以部署在云服务器上。
MEC网络的关键组件包括移动设备和边缘服务器。边缘服务器是规模较小的数据中心，通常部署在更靠近终端用户的位置，一般与无线接入点（例如基站或WIFI接入点）共址。根据通用的MEC架构，我们设计了一个边缘计算系统，该系统可分为两层：移动设备层和边缘服务器层。第一层由两个智能手机组成的移动设备构成，第二层则由两个部署在靠近基站处的边缘服务器组成。系统架构如图2所示。在该图中，科学信息网络是由日本国立情报学研究所建设并运营的学术信息基础设施，为日本全国各地的大学和研究中心的科研活动提供支持。
B. 工作原理
该系统在NII构建。移动设备可以通过LTE‐SINET平台接入部署在SINET上的边缘服务器。如图2所示，SINET网络可通过一些网关设备与LTE连接。为了实现部署，需要将系统划分为两个独立的平面：一个是用于信令的控制平面，移动设备向控制器发送信息以获取MEC卸载决策；另一个是数据平面，任务根据控制器的指令进行卸载。移动设备根据卸载算法的指示将任务卸载至边缘服务器，在这种方式下，我们可以评估所实现的MEC调度算法（参见参考文献[9]）以及基于LTE的MEC系统的性能。
为了调度边缘服务器，我们使用加权轮询作为调度算法。让我们使用
阶段1 阶段2 阶段3 阶段4 阶段5 第6阶段
KLAB电梯地铁站 （神保町） 地铁站 （西小岛） 站地台铁1 平地台铁2 公寓
S={Si|0< i< n; i, n ∈ Z+} 表示边缘服务器的集合。Wi 表示第 ith 个服务器节点的权重。Ti 表示第 ith 个节点需要处理的任务数量。因此，我们通过为每个服务器节点分配权重
$$
Wi = \frac{Ti}{\sum_{i=1}^{n} Ti} \cdot \frac{\sum_{i=1}^{n} Wi}{n}
$$
其中 $\sum_{i=1}^{n} Ti$ 和 $\sum_{i=1}^{n} Wi$ 可以为常数，Wi 与 Ti 成正比。换句话说，ES 处理的任务越多，其权重越高。
III. 性能评估
A. 实验设置
系统构建完成后，我们通过实验评估系统性能，从而分析通信延迟的丢包率（PLR）和往返时间（RTT）。实验使用边缘服务器和智能手机进行。实验分为两种类型：静态和动态。在静态实验中，数据包从智能手机发送到边缘服务器，而在动态实验中则相反。静态实验在室内完成，动态实验在东京室外完成。对于每种类型的实验，我们发送大小为64字节的数据包，数据速率为每秒1个数据包。
B. 实验与结果分析
1) 静态实验与结果
在静态实验中，数据包从智能手机发送到ES。在此情况下，智能手机被视为客户端。当ES接收到数据包后，会向智能手机作出响应。我们每次向ES发送1800个数据包，然后计算数据传输的丢包率和往返时延。静态实验结果如表I所示。显然，大部分延迟产生于移动网络。从基站到ES的延迟非常低。
| 网络部件 | RTT均值（毫秒） | PLR |
|---|---|---|
| 移动网络 | 67.02 | 0 |
| NII中的SINET5 | 9.015 | 0 |
| 实验室 | 0.267 | 0 |
2) 动态实验与结果
动态实验可分为六个阶段，如图3所示。在第一阶段，我们离开实验室，乘坐电梯到达NII的一楼。接着，在第二阶段，我们走出室外，步行前往神保町地铁站（新宿线）。在第三阶段，我们进入地铁站并等待地铁。在第四阶段，我们乘坐前往西大島站（新宿线）的地铁。在第五阶段，我们到达目的地后下地铁并出站。在最后一阶段，我们在公寓外步行。
图4描述了系统性能随时间的变化情况。图像的X轴表示时间，单位为秒，Y轴表示延迟（RTT）的变化，单位为毫秒。动态实验的结果分析如表二所示。我们使用往返时延的一半来表示端到端通信延迟，详细分析如下所述。
在阶段1中，我们看到（如图4(a)所示），初始阶段的通信延迟相对较高。由于电梯的外壳由金属构成，这可能是电梯门关闭时信号干扰所致。但这种情况持续时间不长。这可能是因为智能手机在电梯场景下具有特定的信号模式设计，使得手机信号更稳定。阶段1持续90秒，平均端到端延迟为290.4毫秒。
在阶段2中，我们看到（如图4(b)所示），延迟的变化相对稳定。该路段的无线信号覆盖较好，干扰相比前一阶段较少。阶段2持续182秒，平均端到端延迟为72.4毫秒。
在阶段3，通信出现急剧增加延迟（见图4(c)）可能是由于从开阔区域进入地下时受到地下建筑的干扰所致。阶段3持续863秒，平均端到端延迟为119.4毫秒。
在阶段4中，延迟相比地面较大（见图4(d)和图4(b)），但变化并不剧烈。阶段4持续857秒，平均端到端延迟为123.4毫秒。
在第5阶段，我们看到（如图4(e)所示），延迟的变化更加稳定。阶段5持续了151秒，平均端到端延迟为127.5毫秒。
在第6阶段，我们看到（如图4(f)所示），延迟的变化比第2阶段更大。由于该阶段的实验在农村地区进行，信号质量不如城市地区强，因此信号变化可能更大。但延迟的变化相当稳定。阶段6持续了909秒，平均RTT为106.4毫秒。
| 实验阶段 | 数据包数量 | RTT/2的平均值/最小值/最大值（毫秒） |
| — | — | — |
| 阶段1 | 30 | 290.4/19.7/2462.0 |
| 阶段2 | 182 | 72.4/18.4/190.0 |
| 阶段3 | 863 | 119.4/20.8/1638.0 |
| 阶段4 | 857 | 123.4/18.2/310.0 |
| 第5阶段 | 151 | 127.5/21.2/294.5 |
| 第6阶段 | 909 | 106.4/17.5/355.0 |
IV. 结论
为了为移动设备提供低通信延迟服务，我们设计了一个边缘计算系统。通过一些实验对该系统的性能进行了评估。静态测试的结果显示，该边缘计算系统的延迟（RTT）约为76.3毫秒。在动态测试场景中，不同阶段的通信延迟变化很大。动态实验中各阶段的平均端到端延迟从72.4毫秒到290.4毫秒不等，显著高于静态实验。此外，动态环境下的系统可靠性低于静态环境。在静态实验中，丢包率为0，而在动态实验中为0.03%。性能分析表明，该边缘计算系统能够为移动设备提供低延迟和高可靠性服务。