从起点开始：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做个导读。

这条需求的协议原文，不过短短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 移动性支持（Mobility support）

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

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

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

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

2.3 灵活部署（Deployment independence）

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

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

一方面，这条需求与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”，读起来比较拗口，加一张下面的图示就相对容易理解了。

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

3 通用需求（Generic Requirements）

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

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

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

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

3.1 框架需求（Requirements on the framework）

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

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

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典型用例。用例是通信行业常用的一种软件工程方法，它从使用场景的视角出发，重新梳理汇总需求，可以帮助提升需求理解的完备性和一致性。

推荐阅读

注：本文只代表作者个人观点，与任何组织机构无关，如有错误和不足之处欢迎在留言中批评指正。
尊重知识，转载时请保留全文，并包括本行及如下二维码。感谢您的阅读和支持！