EdgeCloudSim：一种用于边缘计算系统性能评估的环境

1 引言

边缘计算涵盖了多种计算概念，例如移动云计算、1基于云粒的计算、2雾计算、3以及多接入边缘计算（MEC）。4这些计算范式的共同目标是使客户端能够从地理位置上邻近的服务器获取服务。通常，边缘计算范式为时间敏感型应用以及无法访问云的移动环境提供了明显优势。将整个应用程序或其部分在网络边缘执行，也为资源受限的移动设备带来了显著优势。例如，计算能力较低的移动设备可以通过利用边缘服务器来处理复杂操作，同时减少电池消耗。此外，由于在边缘计算中客户端无需经历广域网（WAN）延迟，因此边缘计算相比云计算具有更低的传输延迟。因此，实时人脸识别或语音识别等延迟敏感型应用可以在网络边缘更高效地执行。5

边缘计算正呈现出日益增长的趋势，许多研究人员正在设计新的方案来实现新方法。在提出新的边缘计算解决方案时，一个关键挑战是在考虑相关工程参数的情况下，真实地评估预期系统的性能。研究人员可以使用真实云环境、6实验测试平台、7或模拟器8来评估他们的方法。选择这些选项各有优缺点。由于部署需求，使用真实云环境并非成本效益较高的选择。另一方面，在实验测试平台上开展工作会带来实验可重复性和所提出架构可扩展性方面的困难。9此外，边缘计算系统的客户端大多是移动客户端。在真实云环境或测试平台上操作移动客户端是一个具有挑战性的问题。因此，研究人员通常更倾向于使用模拟器来评估和优化他们的边缘计算方法与设计。

模拟器为研究人员提供了诸多优势。然而，从模拟器开发者的角度来看，仍存在一些建模挑战。与传统的云计算模拟器相比，我们预计模拟边缘计算环境将带来更复杂的问题和挑战。虚拟化资源的建模（例如，CPU、内存和存储）及其供应是首要需要解决的挑战。由于已有云计算模拟器的存在，我们可以借鉴或参考一些现有解决方案。然而，在考虑客户端（代理）时，这些计算范式上运行的应用程序具有不同的特性。例如，无线传感器设备的应用通常采用感知‐处理‐执行模型，这超出了在数据中心分配虚拟机（VM）的范畴。因此，整合虚拟化资源与雾设备的计算模型需要更加复杂的应用模型。移动性的建模是该领域的另一项挑战。在云计算模拟器中，移动性通常被忽略，因为其主要关注如何根据客户端请求来供应虚拟化资源。但在边缘计算架构中，雾设备和边缘服务器的移动性是一个不可忽视的重要因素。随着设备移动性的增强，系统设计将变得更加复杂，因为移动性会影响许多其他模块。第三个挑战是网络建模。在边缘计算中，用户、边缘节点和云之间的交互可能需要不同的接入技术和拓扑结构。例如，移动用户可以通过无线局域网（WLAN）向边缘节点传输数据，而边缘节点则通过广域网（WAN）将接收到的数据转发至云。在这种系统中使用固定的端到端传输延迟是不合理的，因为用户数量通常被认为非常庞大。因此，建模工具应能够采用不同的延迟模型来模拟各种接入技术，如Wi‐Fi、蓝牙、第四代移动通信技术（4G）和第五代移动通信技术（5G）。可扩展性成为处理边缘计算架构中大量实体的另一重大挑战。可扩展性与高细节层次之间存在权衡。如果组件被高度抽象，则工具会变得不真实；另一方面，如果考虑过多细节，则会导致可扩展性差。可扩展性也是研究者在选择模拟器时需要考虑的重要因素。研究人员通常在其研究中使用不同的架构和应用模型，因此他们需要根据自身需求定制和扩展建模工具。提供可扩展模块是另一个需要考虑的挑战。最后，分析便捷性是模拟器用户所需的关键功能。仿真结果可以从多个方面进行分析。确定收集多少日志以及其输出格式，是在开发边缘计算模拟器时最后需要考虑的挑战。

边缘计算系统特有的一个独特需求是在评估其性能时需要考虑移动性、网络和计算资源。据我们所知，现有的解决方案中尚无仿真环境能够以高效且简便的方式处理这些概念。图1展示了边缘计算仿真建模在独立轴上的主要方面。传统网络模拟器如NS2,11 Omnet++,12和Riverbed Modeler13能够有效建模各种类型的网络协议和拓扑结构。然而，这些工具并未处理云计算元素和场景，因此在建模与边缘计算相关的计算方面时需要大量的实现工作量。至于云计算模拟器，它们允许对云计算基础设施和应用服务进行建模。其中最流行的面向云计算环境的仿真工具之一是 CloudSim.14从边缘计算的角度来看，CloudSim的主要缺点包括：（i）缺乏动态无线局域网和广域网通信模型；（ii）总体上缺乏移动节点和移动性支持；（iii）缺乏真实的边缘类型负载生成器模型。通常情况下，研究人员会根据其研究主题的需求通过实现缺失部分来扩展CloudSim。例如，IOTSim15和iFogSim16就是通过扩展 CloudSim实现的。尽管它们在生成物联网和雾计算场景的相关工作负载方面具有实用性，但这些工具并未考虑移动性和动态网络模型。当综合考虑上述所有缺点时，可以看出需要一种新工具来满足对边缘计算场景进行真实仿真的需求。

在这项工作中，我们介绍了一种名为EdgeCloudSim的新仿真器，它涵盖了图1中所示的全部能力范围。EdgeCloudSim提供了一种模块化架构，以支持多种关键功能，例如针对无线局域网（WLAN）和广域网（WAN）的网络建模、设备移动性模型以及可调且真实的负载生成器。EdgeCloudSim在设计上支持多层场景的仿真，其中多个边缘服务器与上层云解决方案协同运行。针对这一需求，EdgeCloudSim提供了一个边缘协调器模块，使用户能够建模在边缘计算场景中常见的编排操作。为了对计算任务（如以特定容量创建虚拟机）进行建模，EdgeCloudSim依赖于CloudSim的功能，后者拥有长期验证且可靠的代码基础，适用于计算操作的仿真。

EdgeCloudSim作为开源项目公开提供。17 EdgeCloudSim的模块化设计和开源代码基础使其用户能够在仿真实验中融入其特定场景的需求。

EdgeCloudSim可用于分析边缘计算领域中的不同工程问题。这些问题的解决方案可应用于不同的时间尺度。例如，为了改善服务时间，可以采用多种解决方法，如增加容量、更改卸载决策以及使用更高效的资源分配算法。其中，增加容量可以在更长的时间尺度上处理，因为它需要新的部署。而更改卸载决策则会在较短的时间尺度内显现效果，因为它可以在边缘服务器上动态完成。EdgeCloudSim可用于在广泛的时间尺度上评估不同的设计决策。

为了展示EdgeCloudSim的这些能力，我们设计了三个示例仿真设置。在第一个设置中，考察了具有不同内部组织结构的多种边缘计算架构。在第二个设置中，分析了边缘服务器容量规划问题。最后，在第三个设置中，探讨了移动性的影响。这些仿真设置通过使用EdgeCloudSim进行的大量实验得到了评估。这些实验的结果清楚地描述了网络、移动性和架构参数对边缘计算系统整体性能的影响。

本文的组织结构如下。在第2节中，详细介绍了边缘计算的背景及相关工作。在第3节中，解释了 EdgeCloudSim的设计和架构。在第4和第5节中，总结了示例仿真设置，并评估了实验结果。第6节总结了我们的研究，并提出了未来研究方向的可能路径。

2 边缘计算背景与相关工作

边缘计算的主要动机基本上是在位于网络边缘的附近资源上执行计算。附近的资源可能是客户端与云数据中心之间的网络资源或计算资源。边缘计算、基于云计算点的计算、雾计算和移动边缘计算在本质上是相同的概念。类似的概念。在我们的研究中，为了保持一致性，我们专注于使用“边缘计算”这一术语。塔莱布等人18的研究阐述了边缘计算范式的发展历史。基于萨蒂亚纳拉延南等人的定义而形成的云粒概念，是该领域的首次研究。2云粒可被视为位于用户附近的微云，移动用户通过无线网络部署和管理自己的虚拟机。在各种边缘计算方法中，云粒值得进一步关注。随后，思科提出了雾计算3，其理念与云粒相似。雾计算架构通常由许多位于网络边缘并具备无线通信能力的设备组成。最终，这些方法引起了电信服务提供商的关注。欧洲电信标准协会（ETSI）提出了移动边缘计算（MEC）的概念，以加快边缘计算在蜂窝网络中的扩展。19他们的主要动机是通过将边缘和云计算能力引入无线接入网络（RAN）的边缘，从而为用户提供对服务的实时访问。为了不仅覆盖蜂窝网络，还包括Wi‐Fi等其他接入技术，ETSI在保持缩写不变的情况下，将MEC中的mobile一词更改为multiaccess。在MEC架构中，接入点可以仅支持Wi‐Fi、仅支持蜂窝网络，或同时支持这两种接入技术。典型的边缘计算架构及终端用户设备如图2所示。

如今，随着云计算研究的日益普及，已经提出了许多云计算模拟器。20本质上，这些模拟器提供了虚拟化云环境的计算模型，对于中央处理器、内存和存储模型以及能耗模型非常有用。一些流行的云模拟器包括CloudSim，14 GreenCloud，21和iCanCloud。22

CloudSim 主要用于建模基础设施即服务云计算环境。14它支持对云组件（如数据中心、主机和虚拟机）以及资源分配策略（如中央处理器、存储、内存和带宽利用率模型）进行建模。CloudSim 是传统云计算场景中最常用的云模拟器。23在传统云计算中，客户端向数据中心发出请求，创建一组虚拟机并在相关虚拟机上运行一系列任务。当数据中心接收到此类请求时，会尝试创建虚拟机并执行相关任务。这些任务被视为一系列操作，使虚拟机持续忙碌数小时。这种操作流程类似于从亚马逊 EC224 和微软Azure25等数据中心运营商处租用虚拟机一段时间。然而，边缘计算场景与传统云计算场景不同，因为任务不需要太长时间即可执行完毕。移动设备卸载到边缘服务器的任务通常在亚秒级时间内处理完成。由于任务规模较小，为每个请求创建新的虚拟机并不高效。

GreenCloud 是 NS2 模拟器的一个扩展。21 GreenCloud 模拟器的主要动机是捕捉计算和通信元件的能量使用情况。作为 NS2 的扩展，GreenCloud 能够实现完整的 TCP/IP 协议参考模型。实现完整的 TCP/IP 协议参考模型可以对网络交换机和链路的能耗进行详细建模。然而，这带来了系统在内存使用和仿真时间方面的开销，成为 GreenCloud 的一个劣势。

iCanCloud 是一个基于 OMNeT++ 的模拟器平台。22 iCanCloud 的主要目标是对包含数千个节点的大规模环境进行建模和仿真。性能和可扩展性是 iCanCloud 的主要目标，因此它支持并行仿真的执行。与其他模拟器一样，它允许对虚拟化云环境的计算方面进行建模。iCanCloud 提供了一个图形用户界面来描述仿真场景。

与云计算系统相比，边缘计算系统在用户和网络拓扑结构方面具有不同的特性。边缘计算架构中的用户具有移动性，但现有的云计算模拟器并未考虑这一移动性。在云计算模拟器中，端到端传输延迟通常被视为一个静态值。然而，移动用户与边缘设备之间的通信需要通过无线接口，这就要求进行更详细的网络建模。此外，在考虑物联网设备时，边缘计算中使用应用程序也具有不同的特性。为了满足上述所有不同的需求，亟需开发专注于雾、边缘或物联网应用场景的新型模拟器。IOTSim、15 SimIoT、26和iFogSim16便是这类模拟器的一些示例。

IOTSim 是另一个通过扩展 CloudSim 实现的模拟器。15它被提出用于模拟物联网应用程序将大量数据发送到大数据处理系统的边缘计算环境。它在 CloudSim 中添加了存储层和大数据处理层，以支持大数据处理系统。在存储层中，模拟了物联网应用程序的网络和存储延迟。在大数据处理层方面，它模拟了 MapReduce 大数据处理模型，以支持面向批处理的数据处理范式。

SimIoT是通过扩展SimIC27模拟器开发的。它基本在SimIC中添加了一个物联网层，以允许所需数量的物联网设备请求云资源。SimIoT有两个关键模块，即物联网设备输入系统和通信代理。物联网设备输入系统负责收集传感器事件，并将其重定向到通信代理。通信代理将传感器数据转换为情境化信息，并生成请求发送给默认 SimIC云实体。

iFogSim 基于 CloudSim 运行。16它通过建模传感器、执行器、雾设备和云等组件，用于模拟物联网和雾环境。iFogSim 允许定义从雾服务器获取服务的设备的位置。然而，该信息是静态的，并不会由任何移动性模型进行更新。iFogSim 中的网络模型过于简化，其中链路被分配固定延迟，忽略了网络负载对操作的影响。如上所述，为了对边缘计算方案进行真实评估，应以足够的精度考虑网络资源和计算资源。据我们所知，目前尚未提出覆盖上述问题的边缘计算模拟器。因此，我们提出了 EdgeCloudSim，作为一个基于 CloudSim 的复杂工具，向研究社区开放，用于边缘计算方案的性能评估。

3 EdgeCloudSim 架构

EdgeCloudSim 提供了一个模块化架构，其中每个模块通过明确定义的接口处理边缘计算的特定方面。为了便于快速原型开发，每个模块都包含一个默认实现，可以通过仿真参数进行调整。如前几节所述，EdgeCloudSim 依赖 CloudSim 的功能来建模计算任务。由主机提供的虚拟机基本上是 CloudSim 提供的标准虚拟机，但具有较低的容量和更真实的 CPU 利用率模型。在 CloudSim 中，创建虚拟机时会限制带宽、内存、中央处理器和存储资源。对于任务而言，在虚拟机上运行的任务数量没有限制。如果有大量任务需要运行，则任务的执行时间会相应变长。然而，这种执行时间的建模方式与边缘计算的方法不兼容，因为我们期望边缘服务器能够在较短的时间间隔内处理传入的任务。因此，我们为虚拟机实现了一种新的 CPU 利用率模型，限制了虚拟机上并行运行的最大任务数量。单个任务的 CPU 利用率是静态的，并在配置文件中定义，但也可以通过重写相关的 CPU 利用率类来实现动态利用率模型。EdgeCloudSim 模块的详细框图也在图3中展示。

3.1 EdgeCloudSim 模块

EdgeCloudSim 使用 CloudSim 提供云计算能力，例如在数据中心分配虚拟机、在虚拟机上执行任务、云资源供应以及对数据中心的功耗建模。除了云计算能力外，EdgeCloudSim 还提供了其他独特的模块来处理边缘计算

3.1 EdgeCloudSim 模块（续）

如图4所示的场景。在当前的EdgeCloudSim版本中，有五个主要模块，分别是核心仿真、网络、负载生成器、移动性和边缘协调器。

核心仿真模块主要负责从配置文件中加载和运行边缘计算场景。EdgeCloudSim 可以动态加载边缘数据中心的属性、应用程序的特性以及基本的仿真设置。因此，用户可以在不更改其源代码的情况下，通过不同的配置运行各种仿真场景。核心仿真模块的另一个重要特性是日志功能。仿真日志对于评估结果非常重要。EdgeCloudSim 将仿真结果记录为逗号分隔值数据格式。文件的内容和格式也可以根据需要进行修改。

边缘编排器模块旨在实现编排过程，这是边缘计算系统中的一个关键问题。ETSI 已经提出了移动边缘编排器。类似于移动边缘编排器，我们提出了一种边缘编排器，以提高整体系统性能的方式管理资源。边缘编排器会做出一些关键决策，例如创建新的副本、终止边缘虚拟机、管理主机的计算资源，以及将任务卸载到云或边缘服务器。为了使决策过程更加高效，它需要从其他实体收集信息。因此，它与其他模块紧密耦合。图5给出了一个通用边缘计算架构。该架构包含两个层级：第一层包含移动设备和边缘服务，第二层包含全球云服务。在我们的设计中，边缘编排器位于这两个层级之间，并以集中控制方式运行。

网络模块特别通过考虑上传和下载数据来处理WLAN和WAN中的传输延迟。移动客户端可以使用蜂窝网络或 WLAN访问云服务。在CloudSim中，可以在网络组件之间添加链路延迟，但这些延迟对于所有用户来说是静态且固定的。然而，如果考虑到移动设备，网络链路质量可能会随时间变化。此外，如果有大量设备使用同一个 Wi‐Fi接入点，大量设备将不可避免地增加局域网（LAN）或WLAN通信的链路延迟。为了更准确地建模局域网、城域网和广域网通信，EdgeCloudSim提供了网络模块。在将任务发送到虚拟机或将任务结果从虚拟机下载之前，网络链路模型会计算上传/下载操作的传输延迟。网络模块的默认实现基于单服务器队列模型。EdgeCloudSim的用户可以将他们自己的网络行为模型集成到网络模块中。目前，我们正在进行一个大规模广域网延迟特征众包项目，并计划将一个真实的广域网延迟分布模型集成到网络模块中。

移动性模块为EdgeCloudSim提供了在云计算模拟器中普遍缺乏的关键功能之一——移动性支持。由于当前的模拟器主要关注传统云计算原理，因此在框架中并未考虑移动性。然而，在边缘计算环境中使用的设备大多是移动设备。忽略此类系统中的移动性可能导致错误的结果，因为无线网络的覆盖范围有限，用户移动会引发拥塞、延迟和丢包等问题。EdgeCloudSim考虑了移动性，因此移动设备的位置会根据移动性模块进行更新。在我们的设计中，每个移动设备都具有x和y坐标，这些坐标根据动态管理的哈希表进行更新。在当前版本中，移动设备按照游牧式移动模型进行移动，但可以根据计划的仿真场景扩展为其他移动模型。除了移动设备外，我们还定义了专用Wi‐Fi接入点所在的位置。默认的无线电行为假设Wi‐Fi接入点的覆盖范围是固定的，并且所有被覆盖的客户端链路质量相同，而不论其与相关接入点的距离如何。

负载生成模块负责为给定的应用配置生成任务。移动性和负载生成模块是向其他组件提供输入的主要组件，它们在如图3所示的同一（移动客户端）层中进行处理。由于在大多数情况下服务器提供多种服务，因此可以在 EdgeCloudSim中定义多种应用类型。例如，移动用户可以将其与人脸识别、健康监测和增强现实应用相关的任务进行卸载。默认情况下，EdgeCloudSim中的任务根据泊松到达过程生成。如果需要其他负载生成模型，则应修改移动设备管理模块。需要注意的是，数据大小和任务长度应根据所选的任务生成分布采用适当的分布来确定。默认情况下，这些变量为指数分布随机数，因为任务到达遵循泊松过程。

3.2 易用性和可配置性

模拟器主要用于通过考虑多个方面来比较不同模型的性能。例如，网络拓扑结构、仿真中使用的实体数量或算法参数都可以变化。以编程方式处理所有这些可变选项是一个具有挑战性的问题。EdgeCloudSim 使用三个配置文件来减少编程工作量并提供可配置性。第一个文件包含作为仿真参数的键值对，例如仿真时间、预热期以及场景中使用的移动设备数量。第二个文件包含用于仿真的应用程序及其特性的XML描述，例如任务长度、输入/输出数据大小、应用程序的空闲/活跃期、到达间隔时间

由相关应用程序生成的任务，以及执行新出现任务所需的指令数。负载生成模块在创建任务时会使用应用程序的特征。第三个文件确定边缘服务器的拓扑结构以及与相应位置关联的接入点。该文件以XML格式定义了边缘接入点的位置和边缘设备的规格。图6展示了一个示例XML文件的部分内容。EdgeCloudSim允许用户通过命令行选项传入相关文件，从而以不同配置运行仿真。这样做使得实验的配置和执行更加简便。

3.3 可扩展性

可扩展性是软件工具最重要的特性之一。它提供了一个可定制的环境，开发者可以在不修改现有代码库的情况下更改组件的行为。如果可扩展性较低，开发者通常不愿意使用相关工具，因为他们必须深入了解现有架构的细节才能进行定制和增强。EdgeCloudSim 提供了本节前面提到的模块的默认实现。例如，它包含游牧式移动模型作为移动性模块，以及简单队列模型作为网络模块。然而，用户可能希望根据自身需求以不同的方式实现这些模块。为了防止修改现有代码库，EdgeCloudSim 采用工厂模式，从而更易于集成新模块。如图7所示，场景工厂类了解抽象模块的创建逻辑，并为其提供具体实现。因此，用户可以通过利用该模式在 EdgeCloudSim 中使用自己的模块。场景工厂是一个抽象类，主要提供四种不同的模块，即移动性模块、负载生成器模块、网络模块和边缘协调器模块。该抽象类可以被扩展，以支持自定义模块的建模。

3.4 复杂度评估

EdgeCloudSim 基于使用离散事件仿真20引擎的 CloudSim 运行。因此，EdgeCloudSim 的复杂性取决于仿真中创建的事件数量以及模块中使用的算法。例如，如果设计的边缘协调器过于复杂，则更可能导致内存消耗较高且

仿真的持续时间较长。在我们的研究中，设置了一个实验，以展示EdgeCloudSim使用了多少内存以及执行一次普通仿真需要多长时间。实验中使用了一台基于Linux操作系统、配备Intel Core i7‐5600U处理器和16 GB内存的基本个人计算机。模拟了在一小时时长内轻负载和高负载场景下的真实事件。实验中使用的边缘计算架构称为带边缘协调器的双层架构，该架构由移动设备、边缘服务器和云服务器组成。移动设备运行三种不同的应用程序，分别对应增强现实、信息娱乐和健康监测应用程序。这些应用程序、移动性、网络以及带边缘协调器的双层架构的建模在第4节中进行了说明。

在实验中，针对两种不同情况分析了时间和内存复杂度。在第一种情况下，研究了随着移动设备数量变化的内存消耗和仿真过程持续时间。在高负载场景中，增强现实、信息娱乐和健康监测应用程序平均每2秒、5秒和10秒生成一次任务卸载请求；而在轻负载场景中，任务的平均到达间隔时间为10秒、25秒和50秒。仿真过程中特别是高负载场景下产生了大量事件。结果如图8A和图8B所示。从图中可以看出，即使是在高负载的密集场景下，使用标准便携式计算机仅需几分钟时间和约半GB内存即可完成仿真。在第二种情况下，研究了随着可变数量的边缘服务器变化的时间和内存复杂度。在此实验中，每个边缘服务器包含一个主机，该主机运行两个具有10每秒十亿条指令（GIPS）CPU处理能力的虚拟机。在高负载场景中使用了500个移动设备，而在轻负载场景中有200个移动设备。内存消耗和仿真过程持续时间如图8C和图8D所示。可以认为，当边缘服务器数量较多时，仿真场景的地理范围也较大。根据我们的评估，EdgeCloudSim能够在合理的时间范围内以可接受的内存消耗执行相对大规模的实例，例如包含500个移动设备、50个边缘服务器并运行100个边缘虚拟机的场景。

4 EdgeCloudSim 运行

为了展示EdgeCloudSim的功能，设计了三种仿真设置并对结果进行了评估。在这些设置中，研究了边缘计算架构、边缘服务器容量以及移动性对关键性能指标的影响。我们在实验中设计了一个类似于大学校园的虚拟环境。学生在校园内走动，并向位于特定区域建筑物中的边缘服务器请求服务。每栋建筑物都配备一个无线接入点，因此移动用户通过连接相应的接入点，并经由该连接卸载其任务。本节后续将详细描述如何逐步建模EdgeCloudSim的各个组件，以获得尽可能接近真实场景的评估结果。

4.1 步骤1：建模应用程序

在现实生活中，学生移动设备上运行的应用程序可能各不相同。例如，可以是谷歌眼镜上的增强现实应用28、信息娱乐应用29，或使用脚戴式惯性传感器的健康应用30。在我们的仿真中，移动设备使用三种不同的应用程序，边缘和云服务器提供相应的服务。EdgeCloudSim的负载生成模块用于表征上述应用程序生成的任务。这些应用程序的配置列于表1中。

通常，移动设备不会持续生成服务请求。我们采用空闲/活跃任务生成模式来恰当地模拟现实生活。根据该模式，用户在活跃期间创建任务，然后，

它们在空闲期内等待。可以认为每个客户端都有一个状态机，客户端可以处于活动状态或空闲状态。例如，当前的可穿戴设备支持心率和身体活动监测功能。可穿戴设备上收集的信息可以发送到附近设备以进行更复杂的数据处理。在这种情况下，可穿戴设备会收集一段时间的数据，然后将其发送到边缘服务。

应用程序生成的任务在指令数和需要上传/下载的输入/输出文件大小方面具有随机长度。例如，增强现实应用需要较高的中央处理器计算量、少量数据下载以及较大量的数据上传。因此，我们使用平均值

AR	I	HM
使用率 (%)	50	30
任务到达间隔时间 (秒)	2	5
空闲期持续时间 (秒)	20	25
活跃期持续时间 (秒)	40	45
上传数据大小 (kB)	1500	25
下载数据大小 (kB)	25	750
任务长度 (千兆指令)	20	7.5
任务的虚拟机利用率 (%)	10	5

表1 仿真中使用的应用程序

AR，增强现实；HM，健康监测；I，信息娱乐。

考虑到典型的jpeg图像，上传数据量为1500kB，下载数据量为15 kB，对应被识别人员的元数据。另一方面，信息娱乐应用相比增强现实应用需要较少的CPU处理能力。它发起的请求数据量较小，而相应的服务返回的数据量较大。任务长度直接影响被卸载到边缘服务器的任务执行时间，具体取决于在相关服务器上运行的虚拟机的计算能力。在我们的仿真中，假设云实体的计算资源在所有场景下均足够充足。因此，可以认为每个卸载到云服务器的任务都在虚拟机上执行且不会发生阻塞。然而，边缘服务器可能会出现拥塞。

4.2 步骤2：移动性建模

EdgeCloudSim的移动性模块用于对移动用户的移动性进行建模。在我们的实验中，学生的移动基于游牧式移动模型。他们在某一处等待一段随机的时间，然后移动到另一个位置。我们的模型中有三种不同吸引力等级的位置类型。如果某个位置的吸引力等级较高，学生更有可能在该位置停留较长时间。例如，学生在图书馆或咖啡馆的停留时间比在售货亭更长。图9展示了该移动性模型，其中 γ表示驻留时间， βij表示从一个位置i移动到另一个位置j的概率。在我们的仿真中，位置的吸引力等级直接影响学生在相应位置的驻留时间。移动到任意位置的概率对所有位置都是相同的。

4.3 第3步：建模网络延迟

EdgeCloudSim的网络模块用于计算网络延迟。在我们的实验中，所提出的环境中的每个位置都由专用的Wi‐Fi接入点覆盖。当移动设备移动到接入点的覆盖区域时，它们会加入相应的WLAN。随后，移动设备开始向边缘服务器发送任务。如果决定将某个任务卸载到全局云，则使用Wi‐Fi接入点提供的WAN连接。EdgeCloudSim为 WLAN和WAN模型提供了一个默认简单队列模型作为网络模块。为了实现更真实的仿真环境，我们通过扩展默认网络模块，采用了一种实证无线局域网和广域网模型。如果使用不同的接入技术模型，也可以采用其他网络模型。该实验网络模型是通过对实际部署进行测量而开发的。对于WLAN延迟观测，使用了802.11系列接入点，并利用伊斯坦布尔的光纤互联网连接来观测WAN延迟。实证网络延迟分析的结果如图10所示。

4.4 步骤4：建模边缘计算架构

为了展示EdgeCloudSim的功能，我们进行了三个不同仿真设置的实验。在第一个仿真设置中，我们比较了三种不同的架构：（i）单层，（ii）双层，以及（iii）带边缘协调器（EO）的双层架构。如图5所示，通用边缘计算架构包括边缘服务器和云

云服务器。单层架构允许移动设备利用与学生位于同一栋建筑内的边缘服务器。而在双层架构中，移动设备可以通过接入点提供的广域网连接将任务发送到全局云。在真实场景中，选择使用哪种服务由边缘协调器决定。在我们的仿真中，卸载到云的卸载比率为10%，因此大约每10个任务中有1个被卸载到云。双层带EO架构具有显著优势，因为在第一层执行的任务中，只有双层带EO架构能够将任务卸载到位于不同建筑中的其他边缘服务器。在此仿真设置中，边缘协调器在第一层选择边缘服务器进行卸载时采用最小负载算法。假设边缘服务器和边缘协调器均连接到校园网络，因此它们可以快速交换信息。第一次仿真设置中使用的其他重要参数列于表2。

在第二次仿真设置中，研究了边缘服务器容量对结果的影响。在部署边缘系统之前，确定边缘服务器的容量是一个需要解决的重要问题。在此设置中，我们使用表2中给出的相同参数评估三种不同的部署场景。对于第一、第二和第三次部署，分别使用80、40和20 GIPS的边缘服务器。由于虚拟机的CPU速度为10 GIPS，因此每台边缘服务器的虚拟机数量分别为8、4和2。

在第三次仿真设置中，研究了学生驻留时间对结果的影响。由于我们使用了游牧式移动模型，因此在经过一段随机时间后，学生的所在位置会发生变化。学生的驻留时间是基于图9所示的模型计算得出的。在此设置中，我们针对每种位置类型采用了三种具有不同驻留时间选项的场景。第一种场景称为快速，表示在吸引力等级为1、2和3的地点的等待时间分别为0.5分钟、1分钟和2分钟。第二种场景称为正常，表示相关地点的等待时长分别为2、4和8分钟。最后，在第三种称为慢速的场景中，相关地点的等待时长分别为6、12和24分钟。其余仿真参数与表2中相同。

5 仿真结果与讨论

如前所述，为了展示EdgeCloudSim的能力，研究了三种仿真设置。第一种设置评估了不同边缘计算架构的性能。重要的性能指标如图11所示。在图11A中给出了任务失败率平均值随移动设备数量的变化情况。图11B展示了平均服务时间。在单层架构中，设备只能卸载到最近的边缘服务器，因此在用户数量相对较多的热门区域会出现拥塞现象。因此，单层架构中的任务失败数量高于其他架构。同样，由于热点位置发生拥塞，其平均服务时间也比其他架构更差。对于双层架构而言，它们的表现优于单层架构，因为部分任务可以卸载到云服务器。本研究中采用了一种基本的概率方法来决定任务是否卸载至云。粗略来说，约有10%的任务被发送到云，因此双层架构的性能略优于单层架构。如果设计出更复杂的卸载机制，性能差距将大于当前呈现的结果。带边缘协调器的双层架构表现优于其他架构，因为边缘协调器使得任务能够被发送到同一局域网内的任意边缘服务器，从而有效平衡边缘服务器的负载，并避免在用户密集的热门区域发生拥塞。

在图11C中，显示了平均无线局域网延迟值随移动设备数量的变化情况。根据我们的实验网络模型，当连接到同一无线局域网的用户数量增加时，移动设备与边缘服务器之间的延迟会变高。与单层架构相比，双层架构提供了更好的无线局域网延迟性能，因为它们可以将部分请求重定向到全局云。在带边缘协调器的双层架构中，局域网延迟的增长速度比双层架构更快。单独评估此图表具有误导性，因为结果还与任务丢失相关。在带边缘协调器的双层架构中，平均任务失败率非常低，因此同时发送/接收任务的移动设备数量更高。因此，在该架构中，随着移动设备数量的增加，无线局域网延迟增长得更快。

图11中给出的结果是所有在边缘或云服务器上执行任务的应用程序的平均得分。EdgeCloudSim 也可以分别提供每个应用程序的得分。例如，图12显示了不同应用程序在边缘服务器上的平均处理时间。处理时间是指服务器执行任务请求期间所花费的时间。由于 EdgeCloudSim 运行在 CloudSim 之上，因此处理时间由核心 CloudSim 模块计算得出。本质上，当服务器上运行的任务数量增加时，处理时间会变得更长，因为我们在仿真中使用的主机采用了一种spaceshared虚拟机调度器。

参数	值
仿真时间	33分钟
预热期	3分钟
重复次数	100
类型1/2/3的地点数量	2/4/8
类型1/2/3地点的平均等待时间	8/4/2 分钟
边缘上的供应算法	负载最少
云卸载概率	0.1
每台边缘服务器的虚拟机数量	8
每个边缘/云虚拟机的CPU速度	10/200 GIPS
局域网传播延迟	5 ms

表2 仿真参数

GIPS，每秒十亿条指令；LAN，局域网；VM，虚拟机。

增强现实和信息娱乐应用程序生成的任务的平均处理时间分别如图12A和图12B所示。两张图中每种架构的斜率相似，但数值不同。这是预期的结果，因为增强现实应用的任务长度高于信息娱乐应用。各架构的平均处理时间性能与图11B中的平均服务时间性能相似。带有边缘协调器的双层架构优于其他架构，因为它可以在边缘服务器之间分配任务。双层架构的性能略优于单层架构，因为它可以将部分任务转发到云服务器。

在第二次仿真设置中，研究了边缘服务器容量对结果的影响。在图13中，比较了三种部署的性能。这些部署在 CPU处理能力方面包含不同的边缘服务器。最强大的边缘服务器可运行8个虚拟机，最弱的可运行2个虚拟机，另一个可运行4个虚拟机。图13A和图13B分别显示了由于虚拟机容量导致的平均失败任务数和平均处理时间值。具有2 个虚拟机的边缘服务器在超过150个移动设备后开始出现拥塞，而具有4个虚拟机的边缘服务器在350个设备后才开始出现拥塞。系统甚至可以处理500个移动设备，此时边缘服务器运行8个虚拟机。这些结果并不令人意外，实际上可以预估。研究此类仿真设置的主要动机是展示EdgeCloudSim如何用于评估和优化边缘服务器容量规划。

在最后一次仿真设置中，研究了移动性对仿真结果的影响。我们的仿真使用了游牧式移动模型，因此可以通过修改停留时间参数来配置移动设备的速度。在此设置中，评估了慢速、正常和快速场景，其中用户在每个地点的驻留时间

时间相应地进行了调整。由于移动性导致的平均失败任务数如图14A所示。当移动设备卸载任务后，在收到响应之前离开了WLAN的覆盖区域时，就会发生因移动性导致的任务失败。可以明显看出，由于移动性而失败的任务数量随着用户的停留时间增加而平行上升。由于WLAN故障导致的平均失败任务数如图14B所示。如果用户移动速度过快，则热点区域更容易发生拥塞。因此，由于WLAN拥塞导致的任务失败率与用户速度成正比。

6 结论与未来工作

向新型边缘计算范式的日益发展趋势，要求对所提出的架构和方法进行评估。在真实边缘/云环境或测试平台中开展实验的成本因素，促使研究人员通过使用模拟器来评估其方案。EdgeCloudSim 针对依赖于计算和网络两方面的边缘计算领域满足了这一需求。EdgeCloudSim 提供了移动性模型、网络链路模型和边缘服务器模型，以评估边缘计算的各个方面。除了仿真能力外，EdgeCloudSim 还通过提供一种从XML文件中获取设备和应用程序配置的机制，提升了可用性，而无需通过编程方式定义这些配置。我们已在GitHub上公开提供这一开放的边缘计算模拟器，以推动并促进边缘计算领域的研究工作。17作为未来的计划，我们拟在EdgeCloudSim中添加切换机制作为后续工作。该切换机制将通过虚拟机迁移方法减少因移动性导致的任务失败。我们规划的另一项未来工作是增加雾计算32功能，以增强移动设备的计算能力。在当前版本中，移动设备可将任务卸载到边缘或云服务器，但尚未建模在移动设备本地执行任务的情况。最后，我们希望为移动和边缘设备以及云数据中心添加能耗模型。