从起点开始：5G MEC需求协议导读

1 概述

Multi-access Edge Computing (MEC); Phase 2: Use Cases and Requirements 描述的是一些高阶需求，离产品落地还较远，不过它是所有其它协议的起点，可以用于导出参考框架、架构、实现等所有后续。

文中如果发现有涉及MEC的协议术语，可以随时参考事先准备好的 《5G MEC规范中的术语》；这是在综合了多份协议文档之后，回过头来翻译整理的，已经力求准确了。

2 总则（Generic principles）

协议里有句原文：理解以下基本原则，对理解MEC规范上下文非常重要。初看时，感觉不强；越往后，觉得此言非虚。

2.1 NFV对齐（NFV alignment）

从移动通信系统的演进方面来讲，MEC在以往仅是一个锦上添花的存在，而在5G时代，成为了达成三大业务场景的必需。从接入网到核心网，5G已经在力所能及的范围内，全面完成了虚拟化。说力所能及，是因为接入网还得再看看Open RAN（可能是个马蜂窝，暂时不敢捅）。所以，为了最大程度地保护运营商的投资，MEC需要复用5G网络的NFV环境。

这个NFV环境，也是由ETSI负责在规范的。不熟悉ETSI历史地位的同学，可以点此 传送门 稍作了解。稍后也尽可能对ETSI NFV做个导读。

图2-1：ETSI NFV Architectural Framework；来源：ETSI

这条需求的协议原文，不过短短4句，所以反倒有必要做更多解读：

• 如果纯粹从技术层面来理解，这条需求可能是句无感的“废话”；但从行业或者说产品落地层面来理解，就会非常有意思。尤其是在国内的行业环境，很多传统行业都有遗留的特制的“竖井”系统，没去碰过传统行业的ICT人员，可能压根不知道这些竖井系统的存在，反倒是胆敢拿SD-WAN去做企业组网的人员，可能或多或少是被现实教育过的。整个MEC的大背景是全面的云网融合，尤其是被5G首次打开的移动通信网领域的云网融合，目标是从服务大众消费扩展到服务千行百业，而一旦要涉及到行业，就会不得不面对大量的遗留应用。当前它们是由哪些供应商开发的？它们是否可以跑在NFV环境里？如果不行，当前谁最适合去做适配？当前谁最有动机去做适配？当前谁最有能力去实施整体解决方案？是否会让这些传统的行业应用，形成一个类似AppStore的新的行业应用生态？国内的2B SaaS严重滞后，这些是否会和2B SaaS的生态演进有关联？如此等等，都会是一些非常有意思的问题。人总是容易倾向于高估自己会的东西的重要性，并轻视自己的未知领域，所以更有必要时时自省，这些看着有点琐碎的“与本司产品无关”的“外部因素”，反倒可能更为重要，毕竟，没有应用，缺乏应用，一切免谈。
• 反过来讲，这里也可以附带理解另一个大势：云原生（如果细读协议的需求部分，可以发现大量与此相关的内容）；尤其是在产业互联网阶段，这些产品多是2B应用，会融入到客户的价值链中，客户自己就在拥抱变化，那么面向未来的基础设施就更得支撑这些变化。拥抱大势者在机会来临时，可能会有同业竞争的红利。所谓大势，在底层逻辑，大概率都是相互支撑相互成就的吧。
• 此外，关注相关行业的同学，尤其是创业同学，可能会慢慢觉得有些“可怕”。大公司的战略纵深，原本就要比创业公司要深几个数量级，创业公司的机会，更像是在“看准赛道后提前在赛道的某个预判位置耕耘等待”，然而，在这个基础行业领域，大公司产品规划的视野和纵深，正在慢慢拉开更大的距离。以AWS为代表的行业巨头为例：很多人也都陆续听到过AWS“从中心向边缘延伸“的产品发布落地，例如：AWS Lambda@Edge，AWS Local Zones，AWS Wavelength Zones，AWS Outposts，AWS IoT Greengrass，AWS IoT SiteWise，AWS IoT Things Graph，等等，这些看似零散的产品正在迅速成为“成体系的基础设施”，逐步浮现出一个至少面向未来5-10年的基础设施框架。另一方面，尽管通信行业可能长期受到互联网厂商的漠视，但AWS似乎比较“屈从”相关行业组织的规范，早早就在往ETSI NFV框架靠：Mapping AWS Services to the NFV Framework (见下图；微信不支持外链，请自行搜索相关文档，相关新闻动态亦同)。结合以上两点，就可以支撑起AWS近期在5G方面的相对密集的新闻动态了：DISH（运营商）与AWS（云厂商）合建5G；Telefonica（运营商）与爱立信（设备商）和AWS（云厂商）合建5G；诺基亚（设备商）与AWS（云厂商）合作提供5G方案，等等。为什么需要关注此类巨头合作？因为电信领域是个相对特殊的基础领域，巨头的技术储备和历史案例，有助于为5G的虚拟化和2B应用落地，提供更加令人信服的背书。5G的虚拟化和2B应用落地的落地难度，可以从“加拿大运营商Roges的5G网络全国断网26小时”的事故中得到警示（电信行业标准要求每年不超过5.26分钟；不用查了，加拿大不可能用华为，是爱立信的软件更新所致）。维护一代，生产一代，研发一代、探索一代，基础行业属于国之重器，基本上属于这个模式，设备商一直是在按这个模式行事的（代表“网”的技术），新入坑的云厂商巨头（代表“云”的技术），也会具备相应的规划能力，“云网融合”相关的创业机会，可能就更得把此当作外部因素去找借力点找细分突破了。

图2-2：AWS_services_mapping_to_the_ETSI_NFV_framework；来源：AWS

2.2 移动性支持（Mobility support）

需要服务的应用千变万化，一些MEC应用程序不可避免会是有状态的。所以，由于UE的移动性，MEC系统需要支持三个级别的移动性：

• 服务的连续性；
• 虚拟化平台上的应用程序的移动性；
• 特定于应用程序上的用户相关信息的移动性。

移动性是3GPP网络的基本功能，而且可能也是MEC最大的特色之一。协议有一大部分的复杂性，源于对移动性支持的需要。而且因为是多接入，所以还需要考虑各种异构场景，部分规范工作也会超出ETSI的工作范围，落入诸如IETF等组织。

之前不做移动网络的同学，很可能会低估移动性带来的复杂性。在移动网络中，甚至固定的UE也可能会“移动”，例如在小区负载发生剧烈变化时，或者UE在切换RAT时（不同的RAT具有不同的性价比）；MEC节点本身可能也会移动，比如车载MEC主机，无线回传系统等。

图2-3：移动的MEC节点（可以尝试理解一个热门话题：到底是“把计算机搬进了汽车”，还是“汽车成为了计算机的外设”）；来源：ETSI

2.3 灵活部署（Deployment independence）

出于性能，成本，可伸缩性，运营商部署偏好等原因，MEC需要支持不同的部署方式，至少包括：

• 部署在无线节点（radio node）
• 部署在汇聚点（aggregation point）
• 部署在核心网的边缘（例如在分布式数据中心或网关中）
• 其它

图2-3：不同的部署位置；来源：互联网

一方面，这条需求与5G的网络架构演进直接相关，MEC需要适配5G的各种部署模式。

另一方面，这条需求也可以直接回答一个问题：“5G的MEC和边缘云有啥区别和联系”？觉得这个问题可能会有普遍性，也就摘在这里。

“边缘”本来就是个地理上的相对概念，就像“广东人会把福建人都叫做北方人”一样，谁都可以说出一堆理由说自己是边缘，尤其是现在在各个厂家的PR之下，所以更是没有必要去争论哪里是“边缘”了。但如果回到产品规划或产品架构角度，作者觉得边缘更像是一个厂商可以端到端管控的网络边缘，如此，边缘才有能力成为第四次科技革命核心生产要素的出入口，即：采集企业数据/知识的入口，分发厂商算力/智能的出口，才有资格值得各路英雄竞相折腰。MEC就更是如此，会成为十亿级人口，千亿乃至万亿级设备终端的边缘。更多底层逻辑，可以出门左转参考《最深的云网融合：多接入边缘计算（MEC）》第二章。

如此，观察到的当前边缘的几种常见落地形态：

• 1、边缘云，本质上是把边缘节点原本相对单一的资源/服务，扩展成为包括计算、存储、网络在内的综合云化，对外提供各种场景化的服务。
  • 谁拥有最多的边缘节点？一个直观可见的答案是CDN厂商，所以当下大多是CDN厂商在做：例如Akamai的IEP（Intelligent Edge Platform），Cloudflare的Cloudflare Workers，以及Fastly的ECP（Edge Cloud Platform）。
  • 云厂商也在这里有涉足，典型的独立产品形态像阿里云的ENS（Edge Node Service），相对隐蔽一些的产品形态像AWS的Lambda@Edge产品（藏在Amazon CloudFront）；其实这些产品的基础也是云厂商的CDN产品，只不过云厂商有着更大的资源摊簿优势和产品协同优势，所以大概率会继续保持对CDN厂商的压迫态势。
  • 也会有新的变量，因为边缘云的产品形态，非常取决于厂商的地理位置优势，所以预感当前还有些玩家并未完全入场。
• 2、云边缘，本质上是公有云把自己的云服务延伸到了边缘，从“攻”方面而言，可以为自己的云服务“导流”；从“防”方面而言，可以防止对手来“截流”。大多是云厂商在做，比如AWS的AWS IoT Greengrass，阿里云的Link Edge，华为云的IEF（Intelligent EdgeFabric）。从计算架构上来讲，这个云边缘的产品形态确实也是有必要的，两方面原因：
  • 无论边缘云如何发展，中心云依旧掌握着最强大或者说是最具性价比的算力，以及最全面的算法框架平台，边缘智能需要这些算力和算法的平台支撑，例如用中心云完成模型的学习/更新，然后将模型参数下放到云边缘来完成模型的实时推理，如此，可以以最佳性价比达成“实时”的“智能”。
  • 云边缘的形态，大多会跟随白牌厂家的设备摆脱云节点的束缚，要比边缘云形态更加接近近场计算。与在住宅小区执行垃圾分类的目的类似，越靠近近场的云边缘的清洗服务，可以大幅提升整系统的带宽性价比和模型学习效率。
• 3、边缘网关，本质上是在把设备或网关资源云化，对外提供服务，服务各种场景。大多是设备厂商在做。偏传统的设备厂商基本都会起心动念，比如Dell EMC有一个和Vmware合作的边缘网关系列；也相信必定会有更多的设备商，甚至包括设备型的SD-WAN创业公司，都会在这方面动手。它的优势是离感知的源头或需要响应的执行点更近了，劣势是资源相对而言也更少了。所以，需要将其作为各司更大产品架构中的一部分来规划，即与端边云功能分配强相关，故不展开。

回到问题本身，这些和MEC有什么关联？按ETSI标准，MEC是一个通用方案，需要可以在上述三个位置都可以部署的。即，从园区级别、局端级别，以及中心云级别。

一方面，这可能是为了支持更多的场景，另一方面，从稍后的用例来看，也是为了支撑更大的愿景：分布式的应用程序模型。一个在逻辑层面统一的环境，显然会具备更大的协同优势。

备注：为了保持“边缘下沉”逻辑的完整性，还有端级别的边缘配合，以及芯片级别的边缘配合形态，与本文关联不大，不再列举，有兴趣可参考《从广域网云化推演SASE：面向物联网和边缘计算的SD-WAN演进》第五章。

2.4 简单可控的API（Simple and controllable APIs）

在前文介绍MEC的发展时，已经指出MEC不是5G特有的，MEC早在4G时代就已经存在了。这个需求的意图是让MEC在演进时，尽可能考虑如何平滑演进，为此ETSI在2018年发布过专门的白皮书 MEC Deployments in 4G and Evolution Towards 5G 进行指导。

2.5 应用程序的智能落位（Smart application location）

某些应用程序可能会在时延（latency），包括时延公平性（latency fairness）等方面有要求，外加上述的“移动性支持”，这就需要MEC支持应用程序的智能落位。

怎么理解时延公平性？可以进一步参考 MEC Metrics Best Practice and Guidelines 的Latency章节, "RTT fairness would be important for applications such as the on-line gaming, where all the users need to have a relatively similar latency to deliver a fair behaviour." 诸如在线游戏等应用，为了维持公平性，需要为所有用户维持一个相对公平的时延环境。

此外，由于移动性等原因，系统环境会随着时间的变化而变化，所以MEC需要提供系统级别的应用程序生命周期管理。

2.6 跨系统的应用程序移动性（Application mobility to/from an external system）

跨系统的应用程序移动性，例如，需要支持将在外部云环境中运行的MEC应用程序，重落位到满足MEC应用程序要求的MEC主机中；将MEC主机中运行的MEC应用程序，重落位到外部的云环境中。

特别的，这里也简单描述了5G网络和MEC系统如何协作。“当将MEC部署在5G网络中时，可以根据UE的位置，以及对应的MEC应用程序所在的MEC主机所连接的数据网络，选择目标UPF”，读起来比较拗口，加一张下面的图示就相对容易理解了。

图2-4: Integrated MEC deployment in 5G network；来源: MEC in 5G networks

同样，这条需求也再次契合了一下云原生的大势。

3 通用需求（Generic Requirements）

注意！以下内容会涉及工程风格的需求条目，绝大部分读者可以略过，只看一下作者做的说明即可，有兴趣可以再去了解一些原理和背景知识。

如果是做工程实践的同学，倒建议直接参考原文，产品是基于原理的工程化，工程化讲求需求的完备性，没法偷懒。

为什么建议大部分人跳过？

• 出于工程描述的精确性，这类需求条目比较拗口，大部分人是不习惯读的；
• 很大一部分需求条目是层次递进的，高级需求依赖基础需求，也就是说有很多重复内容。

3.1 框架需求（Requirements on the framework）

需要能支持包括固网在内的多种接入方式。MEC的M是Multi-access，多接入，不再局限于Mobile，移动。

需要能支持移动节点，一些典型的移动节点类型：无线回传（wireless backhaul）系统，客运车辆（passenger vehicle）。回传是个移动通信系统领域术语，为了便于理解，举一个其实很多人都见过的无线回传系统的例子，例如大型集会时的应急通信车用的微波系统。既然无线回传系统已经广泛存在使用了，那MEC对此还有什么作用吗，为什么值得特地说明？其实原理已经在《最深的云网融合：多接入边缘计算（MEC）》里说明过了，如果还是没能联系起来，稍等后续的协议用例导读吧。

图3-1：无线回传示例（应急通信车）；来源：互联网

MEC系统需要具备代表应用程序与5G核心网进行交互的能力，以便影响流量路由，UPF的选择和重选择的策略控制，以便将相应的用户流量路由到MEC主机上运行的应用程序。这部分内容会涉及5G网络对MEC的支撑和实现，以及如何提供服务质量保障，所以大部分内容还是要去参考3GPP协议，MEC在5G网络规范中的协议实体是AF（Application Function，应用功能）。仅系统架构和系统交互这部分，就需要从上千页的协议中去抽丝剥茧参考整理，所以还得慢慢消化慢慢啃。

备注：上千页是指完整的系统架构和系统交互，MEC相关部分并不需要如此之多，但是需要从这个上下文中去抽丝剥茧参考整理。

3.2 应用程序生命周期（Application lifecycle）

如果只是为了了解，可以略过，转去直接了解一下Kubernetes即可，顺带还学了Kubernetes。

可能值得一提的一点是：MEC管理（MEC management）需要支持在上架应用程序时，附带上应用程序支持的操作区域或应用程序可服务的区域信息。这些信息会被用来干嘛？一个可能的推演是，当前的应用市场，主要是2C的应用市场；行业应用起来时，可能会有一个2B的应用市场，这类应用上架时，大概率需要提供这类可用范围信息。

3.3 应用程序环境（Applications environment）

应用程序环境描述了在MEC主机托管MEC应用程序时的安全性、打包和运行时环境模型。所以，如果只是为了了解，也可以略过，直接去了解一下Kubernetes即可。

可能值得一提的一点是：MEC系统应支持分布式边缘云部署，并在这种情况下支持水平和垂直分布的应用程序：“水平”是指需要支持应用程序组件的对等连接，“垂直”是指不同应用程序组件之间的分层连接。

3.4 移动性支持（Support of mobility）

直接体现了“云网融合”，在执行3GPP的UE切换（handover）时，MEC系统需要支持使用接入网、核心网的信息，以便优化支持将MEC应用程序重落位到与小区相关或不相关的MEC主机上。即，以往的切换，更多的是网络切换，即使有网络和应用同时切换，两者也是分别考虑的；MEC希望至少在应用角度，把两者一并考虑起来。

4 服务需求（Services requirements）

4.1 通用需求（General）

部署在MEC主机上的MEC平台需要提供一个框架，用于向运行在MEC主机上的MEC应用程序交付MEC服务，以及其他必不可少的平台功能。这个框架需要支持MEC服务的提供和消费。说白了还是可以去了解一下Kubernetes，所以以下仅列举觉得可能会有些特色的需求。

4.2 平台必备功能（Platform essential functionality）

• MEC服务（MEC services）
• 连接性（Connectivity）
• 存储功能（Storage）
• 流量路由（Traffic routing）
  • 第1-8条，MEC平台需要支持一个经过认证的MEC应用程序在数据面的相关需求，包括审查（inspect）、修改（modify）、整形（shape）等操作，涉及三大方向：
    • 1、MEC应用程序跟UE侧的上下行的连通性；
    • 2、MEC应用程序跟网络侧上下行的连通性；
    • 3、MEC应用程序之间的连通性。
  • 第9条，MEC平台需要支持应用程序级别的流量选择，优先级处理，以及路由。
  • 第10-12条，MEC管理需要通过设置流量规则（traffic rules）来做流量调度，流量规则可以通过基于IP地址、隧道地址（Tunnel Endpoint ID, TEID）、用户标识（Subscriber Profile ID, SPID）、质量等级指示符（Quality Class Indicator, QCI）等包级别的过滤方式来设置。
  • 第13-14条，需要在MEC主机层面支持封装/解封装，以及流量路由的处理。
  • 第15-16条，MEC系统需要支持应用级别的多播组播处理。
• DNS支持（DNS support）
• 授时支持（Timing）

4.3 特性（Features）

特性会被定义为一组分配有唯一名称的相关联的需求，主要用以满足不同部署方案的不同需求。MEC管理需要识别特定MEC主机可以支持的特性和服务。

这些特性多半会和业务场景有点关联了，所以更合适放到用例部分来介绍。

• 用户应用程序特性（Feature UserApps）
• 智能重落位特性（Feature SmartRelocation）
• 无线网络信息特性（Feature RadioNetworkInformation）：无线网络信息的粒度，可以是UE级别，小区级别，时间周期级别。这些信息的测量方式需要由3GPP来定义。
• 定位服务特性（Feature LocationService）
• 带宽管理特性（Feature BandwidthManager）
• 用户身份识别特性（Feature UEIdentity）：如果MEC系统支持用户身份识别特性，意味着也得支持可以过滤特定用户的数据包。
• WLAN信息特性（Feature WLANInformation）
• 车联网特性（Feature V2XService）：内容相对比较多，也是当前“全民造车”下的一个热点，适合当专题。
• 5G核心网支持特性（Feature 5GCoreConnect）

5 其他

协议的其余章节是以下内容：

• 运营和管理需求（Operation and management requirements）
• 安全，合规和计费需求（Security, regulation and charging requirements）

这些专业性很强，尤其是安全和合规相关，包含了合法监听（Lawful Interception, LI）和留存数据（Retained Data, RD）等方面，原文本身也只是一个提纲式概览，适合在至少介绍完框架和架构后回来整理专题。

6 参考

• ETSI GS MEC 002 V2.1.1（2018-10）

7 待续

后续会整理ETSI给出的MEC典型用例。用例是通信行业常用的一种软件工程方法，它从使用场景的视角出发，重新梳理汇总需求，可以帮助提升需求理解的完备性和一致性。