1、MEC的优势
      MEC 运行于网络边缘，逻辑上并不依赖于网络的其他部分，这点对于安全性要求较高的应用来说非常重要。另外，MEC 服务器通常具有较高的计算能力，因此特别适合于分析处理大量数据。同时，由于 MEC 距离用户或信息源在地理上非常邻近，使得网络响应用户请求的时延大大减小，也降低了传输网和核心网部分发生网络拥塞的可能性。最后，位于网络边缘的 MEC 能够实时获取例如基站 ID、可用带宽等网络数据以及与用户位置相关的信息，从而进行链路感知自适应，并且为基于位置的应用提供部署的可能性，可以极大地改善用户的服务质量体验。
2、MEC架构
      从 2014 年 12 月开始，ETSI MEC ISG 开始致力于 MEC 的研究，旨在提供在多租户环境下运行第三方应用的统一规范。经过努力，ISG MEC 已经公布了关于 MEC 的基本技术需求和参考架构的相关规范。在参考文献[1]中，ISG MEC 对MEC 的网络框架和参考架构进行了定义。图 1 是MEC 的基本框架，该框架从一个比较宏观的层次出发，对 MEC 下不同的功能实体进行了网络（network）、ME（mobile edge）主机水平（ME host level）和 ME 系统水平（ME system level）这 3 个层次的划分。其中，MEC 主机水平包含 MEC 主机（ME host）和相应的 ME 主机水平管理实体（ME host-level management entity），ME 主机又可以进一步划分为 ME 平台（ME platform）、ME 应用（ME application）和虚拟化基础设施（virtualization infrastructure）。网络水平主要包含 3GPP 蜂窝网络、本地网络和外部网络等相关的外部实体，该层主要表示 MEC 工作系统与局域网、蜂窝移动网或者外部网络的接入情况。最上层是 ME 系统水平的管理实体，负责对 MEC 系统进行全局掌控。

      图 2 是一个更为详细的 MEC 参考架构，该架构在图 1 所示的高水平框架的基础之上还详细定义了各个功能实体之间的相互关联，并抽象出 3 种不同类型的参考点。其中，Mp 代表和 ME 平台应用相关的参考点，Mm 代表和管理相关的参考点，Mx 代表和外部实体相关的参考点。

      在图 2 所示架构下，ME 主机由 ME 平台、ME 应用和虚拟化基础设施组成。虚拟化基础设施可以为 ME 应用提供计算、存储和网络资源，并且可以为 ME 应用提供持续的存储和时间相关的信息，它包含一个数据转发平面来为从 ME 平台接收到的数据执行转发规则，并在各种应用、服务和网络之间进行流量的路由。ME 平台从 ME平台管理器、ME 应用或 ME 服务处接收流量转发规则，并且基于转发规则向转发平面下发指令。另外，ME平台还支持本地域名系统（domain name system，DNS）代理服务器的配置，可以将数据流量重定向到对应的应用和服务。ME 平台还可以通过 Mp3 参考点与其他的 ME 平台进行通信，在分布式 MEC 系统的协作机制中，Mp3 参考点可以作为不同 ME 平台互联的基础。
      ME 应用是运行在 ME 虚拟化基础设施上的虚拟机实例，这些应用通过 Mp1 参考点与 ME 平台相互通信。Mp1 参考点还可提供标识应用可用性、发生 ME 切换时为用户准备或重定位应用状态等额外功能。
      ME 平台管理器（ME platform manager，MEPM）具有 ME 平台元素管理、ME 应用生命周期管理以及 ME 应用规则和需求管理等功能。ME应用生命周期管理包括 ME 应用程序的创建和终止，并且为 ME 编排器（ME orchestrator，MEO）提供应用相关事件的指示消息。ME 应用规则和需求管理包括认证、流量规则、DNS 配置和冲突协调等。ME 平台和 MEPM 之间使用 Mm5 参考点，该参考点实现平台和流量过滤规则的配置，并且负责管理应用的重定位和支持应用的生命周期程序。Mm2 是操作支持系统（OSS）和 MEPM 之间的参考点，负责 ME 平台的配置和性能管理。Mm3是 MEO 和 MEPM 之间的参考点，负责为应用的生命周期管理和应用相关的策略提供支持，同时为 ME 的可用服务提供时间相关的信息。
      MEO 是 ME 提供的核心功能，MEO 宏观掌控 ME 网络的资源和容量，包括所有已经部署好的 ME 主机和服务、每个主机中的可用资源、已经被实例化的应用以及网络的拓扑等。在为用户选择接入的目标 ME 主机时，MEO 衡量用户需求和每个主机的可用资源，为其选择最为合适的 ME主机，如果用户需要进行 ME 主机的切换，则由MEO 来触发切换程序。MEO 与OSS 之间通过Mm1 参考点来触发 ME 应用的实例化和终止。MEO 与虚拟化基础设施管理器（VIM）之间通过Mm4 参考点来管理虚拟化资源和应用的虚拟机映像，同时维持可用资源的状态信息。
      从 ME 系统的角度来看，OSS 是支持系统运行的最高水平的管理实体。OSS 从面向用户服务（customer-facing service，CFS）门户和用户终端（UE）接收实例化或终止 ME 应用的请求，检查应用数据分组和请求的完整性和授权信息。经过OSS 认证授权的请求数据分组会通过 Mm1 参考点被转发到 MEO 进行进一步处理。
      CFS 门户实体相当于第三方接入点，开发商使用该接口将自己开发的各种应用接入运营商的ME 系统中，企业或者个人用户也可以通过该接口选择其感兴趣的应用，并指定其使用的时间和地点。CFS 通过Mx1 参考点与 OSS 实现通信。
      用户应用生命周期代理（user app LCM proxy）是供 ME 用户使用来请求应用相关的实例化和终止等服务的实体。该实体可以实现外部云和 ME 系统之间的应用重定位，负责对所有来自外部云的请求进行认证，然后分别通过 Mm8 和Mm9 参考点发送给 OSS 和 MEO 做进一步处理。值得注意的是，LCM 只能通过移动网络接入，Mx2 参考点提供了 UE 与 LCM 相互通信的基础。
      VIM 用于管理 ME 应用的虚拟资源，管理任务包括虚拟计算、存储和网络资源的分配和释放，软件映像也可以存储在VIM上以供应用的快速实例化。同时，VIM 还负责收集虚拟资源的信息，并通过 Mm4 参考点和 Mm6 参考点分别上报给MEO 和 MEPM 等上层管理实体。
3、MEC、微云及雾计算
      微云是由移动计算和云计算融合而来的新型网络架构元素，它代表移动终端、微云和云 3 层架构的中间层，可以被视作“盒子里的数据中心”。微云是 OEC（Open Edge Computing）的研究成果，该项目最初由美国卡耐基梅隆大学发起，而后受到了包括 Intel（英特尔）、华为、Vodafone（沃达丰）在内的多家公司的广泛支持，主要致力于对边缘计算应用场景、关键技术和统一 API 的研究。OEC 基于 OpenStack 开源项目进行扩展，从而得到了微云，目前其源码以及搭建方法也可以在OEC 的官网上免费获得。微云的设计灵感来自于触觉互联网（tactile network），致力于实现信息的超低时延传输。相比于 MEC 和雾计算来说，微云主要用于移动增强，能够为移动设备提供丰富的计算资源，尤其关注边缘的视频分析应用，能够提取边缘数据的标签和元数据并传输到云，以实现高效的全局搜索。此外，微云还可以直接运行在终端上，比如车辆、飞机等。
——”移动边缘计算综述”（李子姝（北京邮电大学）等. 《电信科学》2018.1）
      Cloudlet是2009年由卡内基梅隆大学的Satyanarayanan和Bahl等人提出的移动云计算的实现模式之一，称为朵云，也就是微云，它很好的解决了移动云计算中的高延迟问题。Cloudlet为拥有完整计算和存储能力的计算机或计算机集群，且本地化的部署在与移动设备同一个局域网络中，用户不需要经过核心网就可直接连接到朵云端。Cloudlet的架构图如图1-4所示，Cloudlet通过稳定的回传链路与核心网云端连接，将云端计算服务前置，最大限度地发挥云端的处理能力的同时，又能使用户与计算资源的距离控制在一跳范围内。这里所说的＂一跳＂范围是指的Cloudlet—般会通过WIFI和用户连接，WIFI覆盖范围内的移动设备都可以使用Cloudlet提供的计算和存储服务。与普通的移动云计算模式相比，Cloudlet同样具有丰富的计算能力，且与移动用户只存在一跳的传输距离，面对实时性要求较高的业务时，能够有效地减少服务的延迟。Cloudlet这样的移动云计算实现模式虽然解决了高时延的问题，而它与用户的连接靠的是本地局域网或者WIFI，导致用户在使用移动云计算服务的时候，移动性会受到极大的影响，不能做到“随时随地”地接入云端。

      为了使移动用户能够享有移动云计算服务，时解决移动云计算中的高时延、用户移动性受限的问题，2012年，欧盟的FP7项目组提出了：基于联合小小区的分布式计算、存储、无线资源配置（Distributed computing, storage, and radio resource allocation over cooperative smallcells, ROPIC）项目。该项目提出赋予小小区基站额外的、有限的计算功能，称这样的基站为小小区云增强型节点（SmallcellcloudenhancedeNodeB, SCceNB）。通过这样的方式，移动用户能够在短距离内通过小小区蜂窝网，访问云计算服务器，获得计算功能。SCceNB的部署场景如图1-5所示，多个SCceNB连接着具有计算和存储能力的微云（Femtocloud），微云控制器通过这些SCceNB给连接的用户提供虚拟机和云计算服务。与此同时，多个微云连接至核心网内计算能力更强大的云服务器。当用户的计算请求能够被本地的SCceNB或者微云所服务的时候，数据的传输和计算就在本地端完成，当请求超出了微云的能力时，数据会通过回传链路传输到核心网的云端完成计算。基于联合小小区的分布式移动云计算架构使得移动网络资源和计算资源更接近用户，提高了网络和计算方面的可扩展性，解决了传统移动运算的高时延问题。

——”基于移动边缘计算的任务迁移策略研究”（邓茂菲.北京邮电大学硕士毕业论文.2017.3）
      雾计算是指将计算、通信、控制和存储资源与服务分布给用户或靠近用户的设备与系统，从而将云计算模式扩展到网络边缘。雾计算最初是由思科提出来的，更侧重于在物联网上的应用。2015 年 11月，ARM、思科、戴尔、英特尔、微软和美国普林斯顿大学联合成立了开放雾联盟（Open Fog Consortium），该联盟旨在通过开发开放式架构、分布式计算、联网和存储等核心技术以及实现物联网全部潜力所需的领导力，加快雾计算的部署。Open Fog 架构利用开放的标准方法，将云端的无缝智能与物联网终端联合在一起。2017 年 2 月，开放雾联盟宣布发布了 Open Fog参考架构（reference architecture，RA），这是一个旨在支持物联网、5G 和人工智能应用的数据密集型需求的通用技术架构，该架构为雾节点（智能互联设备）与网络、部署模式、层次模型和用例提供了一个中高层次的系统架构视图，标志着雾计算向制定标准迈出了重要的一步，未来的工作将更偏向于新需求和底层细节的研究。
      MEC 与微云、雾计算的概念相似，其基本思想都集中在将云计算能力迁移至网络边缘，都属于边缘计算的范畴。但三者在一些基本细节上仍存在一些需要区分之处，表 1 对这 3 种概念的不同之处进行了简要的归纳和总结。

4、基于MEC的在线视频系统
      图 3 是英特尔中国研究院与英特尔网络平台事业部、中国移动及爱奇艺合作开发的一款在线视频系统。该系统利用 MEC 进行视频加速，视频提供商利用 MEC 的计算、存储和网络功能，通过对用户视频请求数据分组进行分析，为特定的高清付费用户提供充足带宽，以保证其观看体验。OTT（互联网应用服务） 在使用上述系统时，无需对自己的应用网络进行架构性变动，由此可以大幅降低使用成本，加速业务创新。该系统目前已在业界知名的世界移动通信大会（Mobile World Congress，MWC）上现身，并引起广泛关注，并被 ETSI MEC ISG采纳为典型业务场景之一。

5、MEC应用于VR
      中兴也提出了基于 5G 的 MEC 解决方案，该方案适用于 VR 这一典型应用场景。MEC部署在 RAN 或 C-RAN（cloud RAN）侧以获取利于统计分析的关键信息，提供低时延的本地化业务服务。运营商不仅可以有效减少核心网的网络负载，还能通过本地化的部署，提供实时性高、低时延的 VR 体验，增强 VR 实时互动。该系统的架构如图 4 所示。

6、MEC关键技术
（1）虚拟化技术
      虚拟化技术与网络的结合催生了网络功能虚拟化（network function virtualization，NFV）技术，该技术将网络功能整合到行业标准的服务器、交换机和存储硬件上，并且提供优化的虚拟化数据平面，可通过服务器上运行的软件实现管理从而取代传统的物理网络设备。
（2）云技术
      云技术与移动网络的结合还促进了C-RAN 这一创新性应用的产生。C-RAN将原本位于基站的基带处理单元等需要耗费计算和存储资源的模块迁移到云上，在很大程度上解决了基站的容量受限问题，提高了移动网络的系统能量效率。
      MEC 技术在网络边缘提供计算和存储资源，NFV 和云技术能够帮助 MEC 实现多租户的共建。由于 MEC 服务器的容量相对于大规模数据中心来说还是较小，不能提供大规模数据中心带来的可靠性优势，所以需要结合云技术引入云化的软件架构，将软件功能按照不同能力属性分层解耦地部署，在有限的资源条件下实现可靠性、灵活性和高性能。
（3）SDN技术
      SDN 技术是一种将网络设备的控制平面与转发平面分离，并将控制平面集中实现的软件可编程的新型网络体系架构。SDN 技术采用集中式的控制平面和分布式的转发平面，两个平面相互分离，控制平面利用控制—转发通信接口对转发平面上的网络设备进行集中控制，并向上提供灵活的可编程能力，这极大地提高了网络的灵活性和可扩展性。
      利用 SDN 技术将核心网的用户面和控制面进行分离，可以实现网关的灵活部署，简化组网。在参考文献[2]中，结合 NFV 技术、SDN 技术和 MEC，设计了一个新型的移动网络系统 SD-MEC。该系统在不同接入点分布式部署 MEC 服务器，将业务进行本地卸载，从而降低了核心网的信令开销，降低了由于长距离传输而发生网络突发状况的可能性，增强了用户的服务质量体验。另外，SD-MEC 有专门的控制器对系统进行管控，从而降低了管理的复杂性，同时使得新服务的部署变得更加灵活。
7、MEC与CDN
      研究表明，在移动数据流量中有超过一半的部分是视频流量，并且该比例呈逐年上升趋势。从用户角度来说，观看视频可以分为点播和直播。点播是指在被请求视频已经存在于源服务器的情况下用户向视频服务器发送视频观看请求，直播则指在内容产生的同时用户对内容进行观看。在传统的视频系统中，内容源将产生的数据上传到Web 服务器，然后再由 Web 服务器响应用户的视频请求。在这种传统方式下，内容基于 TCP 和HTTP 进行下载，或是以流的形式传递用户。但是TCP 并不能快速适应 RAN 的变化，信道环境改变、终端的加入和离开等都会导致链路容量的变化，另外，这种长距离的视频传输也增大了链路故障的概率，同时造成很大的时延，从而不能保证用户的服务质量体验。为了改善上述问题，当下学术界和产业界普遍采用 CDN 分发机制，将内容分发到各个 CDN 节点上，再由各个 CDN 节点响应对应区域中的用户请求。CDN 分发机制的引进的确在一定程度上缓解了上述问题，但这种改进对于直播这种高并发，并且对实时性和流畅性要求很高的场景来说仍然有力不从心之处。
      MEC 技术的引入可以解决上述问题，内容源可以直接将内容上传到位于网络边缘的 MEC 服务器，再由 MEC 服务器响应用户的视频请求，这样可以极大地降低用户观看视频的时延。同时，由于MEC 具有强大的计算能力，可以实时感知链路状态并根据链路状态对视频进行在线转码，从而保障视频的流畅性，实现智能视频加速。另外，MEC服务器还可以负责本区域用户的空口资源的分配和回收，从而增加网络资源的利用率。
8、MEC运用于车联网
      车联网场景下有大量的终端用户，如车辆、道路基础设施、支持 V2X 服务的智能手机等，同时对应着多种多样的服务，例如一些紧急事件的广播等基本的道路安全服务以及一些由应用开发商和内容提供商提供的增值服务，例如停车定位、增强现实或其他娱乐服务等。MEC 服务器可以部署于沿道路的 LTE 基站上，利用车载应用和道路传感器接收本地信息，对其加以分析。并对那些优先级高的紧急事件以及需要进行大量计算的服务进行处理，从而确保行车安全、避免交通堵塞，同时提升车载应用的用户体验。在此方面，德国已经研发了数字高速公路试验台来提供交通预警服务，该试验台用于在 LTE 环境下在同一区域内进行车辆预警消息的发布[3]。
9、MEC服务器部署场景
      在设计 MEC 解决方案时，还必须考虑 MEC服务器在网络中的部署位置。MEC 服务器可以被部署在网络的多个位置，例如可以位于 LTE 宏基站（eNode B）侧、3G 无线网络控制器（radio network controller，RNC）侧、多无线接入技术（multi-radio access technology，multi-RAN）蜂窝汇聚点侧或者核心网边缘。本节旨在介绍 MEC 服务器的几个主要的部署场景，并且对不同部署方式的优势和存在问题加以简要分析。
<<1>> 4G EPC 架构下的 MEC 部署
（1）MEC 服务器部署在无线接入网（RAN）侧
      如图 5 所示，MEC 可以部署在 RAN 侧的多个eNode B 汇聚节点之后，这是目前比较常见的部署方式。MEC 服务器也可以部署在单个 eNode B 节点之后，如图 6 所示，这种方式适合学校、大型购物中心、体育场馆等热点区域下 MEC 的部署。将 MEC 服务器部署在 RAN 侧的优势在于可以更方便地通过监听、解析 S1 接口的信令来获取基站侧无线相关信息，但是该方案需要进一步解决计费和合法监听等安全性问题。


（2）MEC 服务器部署在核心网（CN）侧
      MEC 服务器也可以部署在核心网边缘，在PGW 之后（或与 PGW 集成在一起），从而解决RAN 部署方案下的计费和安全问题。但部署在核心网侧会存在距离用户较远、时延较大和占用核心网资源的问题。图 7 所示方案是不改变现有的 EPC架构，将 MEC 服务器与 PGW 部署在一起。UE 发起的数据业务经过 eNode B、汇聚节点、SGW、PGW+MEC 服务器，然后到互联网。图 8 所示方案需要改变现有的 EPC 架构，将原 PGW 拆分成P1GW 和 P2GW（即 DGW），其中，P1GW 驻留在原位置，DGW 下移到 RAN 侧或者核心网边缘，DGW 负责计费、监听、鉴权等功能，MEC 服务器和 DGW 部署在一起。在此方案下，P1GW 和 DGW之间为私有接口，需由同一设备厂商提供。


<<2>> 5G 架构下的 MEC 部署
      如图 9 所示，在 5G 架构下，MEC 服务器也有两种部署方式，分别如图 9 中 MEC 服务器 1和 MEC 服务器 2。MEC 服务器可以部署在一个或多个 Node B 之后，使数据业务更靠近用户侧，如图 9 中粗实线所示，UE 发起的数据业务经过Node B、MEC 服务器 1，然后到达互联网，同样地，在该方式下计费和合法监听问题需进一步解决。MEC 服务器也可以部署在用户平面网关GW-UP 后，如图 9 中粗虚线所示，UE 发起的数据业务经过 Node B、GW-UP、MEC 服务器 2，最后到达互联网，同理，此部署方法将以牺牲一部分时延为代价。

——”移动边缘计算综述”（李子姝（北京邮电大学）等. 《电信科学》2018.1）

[1]ETSI. Mobile edge computing (MEC); framework and reference architecture[S]. 2016.
[2]SALMAN O, ELHAJJ I, KAYSSI A, et al. Edge computing enabling the internet of things[C]//Internet of Things, Dec 14-16, 2015, Milan, Italy. Piscataway: IEEE Press, 2015: 603-608.
[3]AHMED A, AHMED E. A survey on mobile edge computing[C]//2016 10th International Conference on Intelligent Systems and Control (ISCO), Jan 7-8, 2016, Coimbatore, India. Piscataway: IEEE Press, 2016: 1-8.
[4]HU Y C, PATEL M, SABELLA D, et al. Mobile edge computing—a key technology towards 5G[S]. ETSI White Paper, 2015: 1-16.