zoukankan      html  css  js  c++  java
  • Mobile Edge Computing: A Survey on Architecture and Computation Offloading学习笔记

    文章目录

    前言

    MEC简介

    一、用例和服务场景

          1:面向消费者的服务

          2:运营商和第三方服务

          3:网络性能和QoE改善服务

    二、MEC计算卸载决策

         1:完全卸载

               (1)最小化执行延迟

                 (2)满足执行时间限制的条件下最小化能量消耗

               (3)二者折衷

          2:部分卸载

              (1)满足时间延迟要求下进行能量消耗最小化

              (2)折衷

    三、计算资源的分配

        1:单个节点的资源分配

        2:多个节点的资源分配

           (1)执行延迟与功耗

           (2)平衡通信与计算负载

    四、移动性管理

    前言

     

    MEC将计算和存储资源引入移动网络的边缘,使其能够在满足严格延迟要求的同时在UE上运行高要求的应用程序。这篇文章先是MEC的主要用例和场景,和一些标准的东西。重点:本文将计算卸载的研究分为三个重点领域:1)计算卸载的决策;2) MEC内计算资源的分配;3)移动管理。

    MEC简介

    为了解决长等待时间的问题,云服务应该被移动到UE的附近,即,如在新兴的边缘计算范例中所考虑的,移动到移动网络的边缘。边缘计算可以理解为MCC的特定情况。尽管如此,在常规的MCC中,云服务是通过Internet连接访问的,而在边缘计算的情况下,计算/存储资源应该位于UE的附近(从网络拓扑的角度来看)。因此,与MCC相比,MEC可以提供更低的延迟和抖动。另一方面,相对于MCC,边缘计算仅提供有限的计算和存储资源。

     一、用例和服务场景

    1:面向消费者的服务

    第一个用例类别是面向消费者的,因此应直接对最终用户有利。通常,用户主要通过计算卸载从MEC中获利,这使得能够在UE处运行新出现的应用程序。受益于计算分流的应用程序之一是Web加速浏览器,其中大多数浏览功能(Web内容评估,优化的传输等)都分流到了MEC。此外,人脸/语音识别或图像/视频编辑也适合于MEC,因为它们需要大量的计算和存储

    最重要的是,运行低延迟应用程序(例如在线游戏或远程桌面)的用户可能会受益于附近的MEC。在这种情况下,在适当的移动边缘主机处启动特定应用程序的新实例,以减少UE处应用程序的等待时间和资源需求。

    2:运营商和第三方服务

    对于操作员或第三方有利的用例的一个例子是从用户或传感器收集大量数据。此类数据首先在MEC进行预处理和分析。然后,将预处理后的数据发送到遥远的中央服务器以进行进一步分析。可以将其用于安全和保障目的,例如监视区域(例如停车场监视)。

    另一个用例是将MEC用于IoT(物联网)。基本上,IoT设备使用各种通信协议通过各种无线电技术(例如3G,LTE,WiFi等)连接。因此,需要低等待时间的聚合点来处理各种协议,消息的分发以及处理。可以通过充当物联网网关的MEC来启用此功能,其目的是将物联网服务聚合并交付到高度分布式的移动基站中,以使应用程序能够实时响应。

    3:网络性能和QoE改善服务

    一种这样的用例是启用无线电和回程网络之间的协调。到目前为止,如果回程或无线电链路的容量下降,则也会对整个网络性能产生负面影响,因为网络的另一部分(分别为无线电或回程)并不知道该性能下降。在这方面,利用MEC的分析应用程序可以提供有关无线电/回程网络流量需求的实时信息。然后,运行在MEC上的优化应用程序将按应用程序调整流量或按需重新路由流量。

    改善网络性能的另一种方法是通过在移动边缘缓存本地内容来缓解拥塞的回程链路。这样,MEC应用程序可以存储在其地理区域中使用的最受欢迎的内容。如果内容是用户要求的,则不必通过回程网络进行传输。

    除了减轻和优化回程网络外,MEC还可以帮助进行无线网络优化。例如,从UE收集相关信息并在边缘处进行处理将导致更有效的调度。此外,MEC还可以用于TCP(传输控制协议)的吞吐量指导的移动视频传输优化。TCP具有固有的困难,以适应无线电信道上快速变化的条件,从而导致资源的低效使用。为了解决这个问题,分析MEC应用程序可以向后端视频服务器提供关于估计吞吐量的实时指示,以便将应用程序级编码与估计吞吐量相匹配。

    二、MEC计算卸载决策

    1:全部卸载

    全部卸载的主要目标是:尽量减少执行延迟,在满足预定的延迟约束条件下,最小化UE处的能量消耗,或者在能量消耗和执行延迟之间找到一个合适的平衡点。

    (1)最小化执行延迟

    执行延迟包含三个部分:

    • 卸载数据到MEC的传输时间
    • MEC的计算时间
    • 从MEC拿回计算书的传输时间

    下图是一个仅考虑计算延迟的卸载决策示例。其中D0,D1分别是分流的延迟和本地计算的延迟,只考虑延迟,那么谁的延迟小就采取哪种策略。

    ①通过一维搜索算法来完成,该算法根据应用程序缓冲区排队状态UE和MEC服务器上的可用处理能力以及UE与MEC服务器之间的信道特性,找到最佳的卸载决策策略。计算卸载决策本身通过计算卸载策略模块在UE处完成。该模块在每个时隙中决定在缓冲区中等待的应用程序是在本地处理还是在MEC处理,同时最小化执行延迟。仿真结果表明,所提出的最优策略能够应对高密度的云计算,因此能够将执行延迟减少多达80%(与本地执行策略相比),并减少了多达44%(与云执行策略相比)。应用程序的到来。

    在这方面,作者提出了一种基于Lyapunov优化的低复杂度动态计算卸载(LODCO)算法。LODCO在每个时隙中做出卸载决策,然后为UE分配CPU周期(如果执行本地执行)或分配传输功率(如果执行计算卸载)。该建议能够完全防止卸载的应用程序被丢弃的情况

    上述文章的缺点:由于快速的电池耗尽在当代网络中构成了重大障碍,因此卸载决策并未考虑UE端的能耗。

    (2)满足执行时间限制条件下最小化能量消耗

    主要目标是在满足应用程序执行延迟约束的情况下,最小化UE处的能源消耗。一方面,由于不需要在本地进行计算,所以将计算任务交给MEC可以节省UE的电池电量。另一方面,传输和接收数据都需要一定的能量消耗。下图是根据能量进行卸载的过程:E1,E0分别是本地计算和卸载所需要的能量消耗,下面两个用户设备都能满足D0<Dmax,也就是满足执行时间限制,此时他们选择能量消耗最小的方式决定是否卸载。

     

    在每个时隙中周期性地做出关于计算卸载的决定,在此期间,所有UE被分为两组。虽然允许第一组的UE将计算卸载到MEC,但是MEC上的计算资源不可用,第二组的UE必须在本地执行计算(请注意,在本文中,计算是在服务SCeNB上完成的) )。根据队列的长度,即根据它们需要处理的数据量,将UE分为几类。在允许UE卸载计算之后,通过找到UE的最佳传输功率以及将SCeNB的计算资源分配给所有单个UE来执行通信和计算资源的联合分配。根据取决于数据到达强度的平均队列长度以及在UE和SCeNB处使用的天线的数量来评估提议的性能。

    缺点:它仅假设了一个SCeNB,因此,连接到各个SCeNB的UE之间没有干扰。

    ②作者提出一种分布式迭代算法,该算法利用收敛到局部最优解的连续凸逼近(SCA)。数值结果表明,所提出的无线电和计算资源的联合优化明显优于分别优化无线电和计算的方法。而且,已经表明,要卸载的数据量较少,同时需要大量CPU周期进行处理的应用程序更适合于计算卸载。结果表明,随着SCeNB数量的增加(即,云数量的增加),UE的能耗成比例地降低。

     (3)能耗与执行延迟之间的权衡

    卸载决策是倾向于最小化能耗还是执行延迟由一个权重参数决定。论文的主要目的有两个;1)根据权重参数选择任务是否向MEC进行卸载;2)在进行计算卸载时,选择最合适的无线信道进行数据传输。

    作者提出了一种实现纳什均衡的分布式计算卸载算法。根据两个性能指标比较了最佳集中式解决方案和分布式算法。1)有利于UE进行计算分流的UE数量,以及2)通过权衡能耗和执行延迟来表示的计算开销。在上述两个性能指标中,分布式算法的性能仅比集中式算法稍差。

    ②另一种计算卸载决策的算法,该算法权衡了UE的能耗和执行延迟。如果MEC的计算资源不足,则假定计算也可以卸载到远程集中式云(CC)。计算卸载决策以顺序方式完成。在第一步中,UE决定是否将应用程序卸载到MEC。如果将应用程序卸载到MEC,则MEC在第二步中评估它是否能够满足请求,或者是否应该将计算进一步传递给CC。该问题被公式化为非凸二次约束二次程序(QCQP),但是,它是NP难的。因此,提出了一种基于半确定松弛的启发式算法以及一种新颖的随机方法。拟议的启发式算法能够显着降低总系统成本(即总能耗的加权总和

    2:部分卸载

    (1)满足时间延迟要求下进行能量消耗最小化

    将应用程序分为一个不可卸载部分和N个可卸载部分,如下图所示。主要目的是确定哪些可卸部件应卸给MEC。

     并且要注意任务之间的依赖关系

     上图中的依赖关系是一种执行先后次序的依赖

    (2)能耗与执行延迟之间的权衡

    卸载决策考虑以下参数:1)要处理的比特总数,2)UE和MEC的计算能力,3)UE与提供对MEC的访问的服务SCeNB之间的信道状态,以及4) UE的能量消耗。

    卸载的应用程序首先交付给MEC内的本地调度程序。调度程序检查是否存在具有足够计算资源的计算节点。如果存在具有足够可用资源的计算节点,则会在该节点上分配VM。然后在此MEC节点处处理应用程序,最后将其发送回UE。但是,如果MEC服务器提供的计算能力不足,则调度程序会将应用程序委派给远程CC。为了在满足延迟要求的同时最大化在MEC中处理的应用程序的数量,作者提出了一种基于优先级的合作策略,该策略为每个优先级定义了几个缓冲区阈值。因此,如果缓冲区已满,则将应用程序发送到CC。缓冲区阈值的最佳大小是通过低复杂度递归算法找到的。提议的合作策略能够在允许的延迟内将应用程序完成的可能性提高25%。

    三、计算资源的分配

    如果决定将应用程序全部或部分卸载给MEC(如前一节所述),则必须对计算资源进行适当分配。与计算卸载决策类似,计算位置的选择也受到卸载应用程序并行化/分区的能力的影响。如果应用程序不能并行化/分区,则只能为计算分配一个物理节点,因为应用程序不能被分割成几个部分(在图15中,UE1将整个应用程序卸载到eNB,因为这个应用程序不能被分区)。在相反的情况下,卸载的应用程序可能由分布在多个计算节点上的资源来处理。

    1:单个节点的资源分配

     当用户上传任务时它被放在一个堆栈里,如果此时有可用计算能力的节点,就将节点分配,否则传送到中心云端

    2:多个节点的资源分配

     

    ①首先节点试图独立服务它们自己的问题,因为这会导致最短的通信延迟。(例如,在下图中,SCeNB1将计算资源分配给UE1和UE2等)只有当SCeNB不能单独处理应用程序时,它才会被转发到同一集群中的所有SCeNB(UE3的计算是在SCeNB2和SCeNB3处完成的)。数值结果表明,与仅在服务场景下进行计算相比,该方案能够将执行延迟降低50%。

     ②集群形成是与UE调度一起完成的。分为两个步骤。第一步,标记为本地计算资源分配,每个SCeNB根据特定的调度规则,例如应用程序延迟约束,计算负载或最小所需计算能力,将其计算资源分配给自己的UE。第二步,标记为建立计算集群,为无法由其服务SCeNB服务的每个UE创建计算群集。作者提出了三种算法实现方式,它们在应用程序优先级划分(例如,最早的截止日期优先或根据应用程序的计算大小)和目标方面有所不同。仿真表明,该算法的实现可以使用户满意度达到95%以上,同时保持所有计算节点的中等功耗。

  • 相关阅读:
    如何 Xcode 开发工具里安装一个空的项目末模板
    推荐完成项目要使用的常用工具
    仿照 QQ 的 cell 的左滑删除、置顶、标记未读效果
    API接口文档的撰写
    UI:动画
    UI:多线程 、用GCD创建线程
    UI:UICollectionView
    开发中的一些零碎知识点
    UI:数据库练习、滤镜效果
    UI:地图和定位
  • 原文地址:https://www.cnblogs.com/redzzy/p/13492964.html
Copyright © 2011-2022 走看看