MEC用例协议导读：从SD-WAN到边缘计算 - 极术社区

转自：边缘计算社区
作者：牧之

1 前言

原本说好的是MEC用例协议导读，怎么又给整到SD-WAN去了。别急，这正是协议导读的开篇。几个考量：

_ETSI GS MEC 002_ 协议的用例部分，是由3大类36个相对独立的用例组成，不容易组织成阅读文体，所以索性就导读得彻底一些：从相关行业的视角，来试图串联这些用例。
SD-WAN从业者，大多会往边缘计算演进。抛开各种愿景和口号，一个直接的现实问题是：SD-WAN五花八门的功能特性，哪些是值得长期投入做深壁垒，可以在边缘计算中得到最大的投资复用？等等。
此外，从平时交流可知，熟悉边缘计算的人，可能并不熟悉SD-WAN及其发展趋势，所以也可以从“网络演进”的视角，来看看对“计算演进”的支撑，最终融合到边缘计算之中——即：物联网不再是纯粹的网络，边缘计算也不再是纯粹的计算。

全文逻辑：

了却君王天下事，赢得生前身后名。从SD-WAN演进的视角，来看看对边缘计算的支撑。
为什么群雄会扎堆在一个40-60亿美金的市场？为何会对端到端管控如此痴迷？
相关MEC用例梳理分类。

2 SD-WAN的生前身后名

经历过18-19年SD-WAN会议的疯狂，以为这个领域已经退火，与包括投资咨询在内的交流来看，似乎大家兴趣还在，不过已经更为理性。其中比较关心的一个问题是，SD-WAN的演进趋势。

趋势应该是由底层逻辑来推动的，所以可以从历史角度来看一下演进逻辑。一个更为原始的问题：为什么需要SD（Software Defined）？一堆理由，经受时间检验的靠谱的大概有两个：

一方面，转控分离，软件定义，是在范式层面根本性地解决网络安全问题的必需，具体可参考《深入理解SASE（五）：新的安全范式》第4.3.3章；SD-WAN理念在这方面的价值无可撼动，不做架构变革就没有未来。

另一个，就是为了应用，应用的种类越来越丰富，性能越来越夸张，需求越来越多元。这样的趋势，使得传统的孤立封闭的网络系统，越来越难以适应。所以，与其说“用软件来重新定义网络”，不如说“用软件来重新定义网络应用”，进而衍生出按场景所需的云网融合；现代应用基本都是网络应用，所以，这也是一个难以抗拒的趋势。

在这个大逻辑下，SDN是比SD-WAN起的更早的一波。遗憾的是，2019年，带头大哥Gartner官宣SDN社死（Obsolete before plateau），悼词有些悲壮：SDN is Dead; Long Live SDN. 大意是：“SDN挂了，但他的精神永远活在我们心中，阿门”。

SDN为什么给社死了？悼词写得很明白：并不是SDN不好，而是SDN已经深入人心了。该用SDN的，都已经用上了；用不上SDN的，再跟他们去掰扯，也是乌龟壳上找毛——白费劲。既然接下来没啥直接的新市场可以去拱拱了，那带头大哥再不宣布它社死，岂不是容易被居心叵测的小人利用，坑害无辜的创业者和投资者继续掉坑么。

所以，SDN的社死，并非技术理念原因，而是产品形态原因。SDN的主要落地产品形态是DCN（Data Center Network，数据中心网络）和DCI（Data Center Interconnect，数据中心互连网络），离用户远，离应用远。

带头大哥在官宣SDN社死的同时，鼎力支持SD-WAN再升一级，甚至在2020年，更是让其跨界到网络安全领域，宣称它是在未来两年会被采纳的高价值领域（high benefit and less than two years to adopt category），这个评价甚至高于IPS和WAF（moderate benefit and less than two years to adopt category）。

继承SDN精神的SD-WAN，可以摆脱SDN类产品的机房限制，飞入寻常百姓家，离用户更近，离应用更近。

SD-WAN凭什么比SDN更接近用户，更接近应用？一个直接的答案就在于SD-WAN的CPE。

CPE又是个什么？有些问题，可能会被平时的“太熟悉”消磨殆尽，然后就被脑回路直接忽视掉。

CPE全称Customer Premise Equipment，直译“客户前置设备”，这个名字，跟SD-WAN就没半毛钱关系！

这种东西可以叫CPE——这可能是SD-WAN从业者司空见惯的最熟悉的。

这种东西也可以叫CPE，就是运营商放在各家各户，然后平时就在那默默吃灰的。

这种东西也可以叫CPE，可以放在各种工业场合——这里贴先进一点的图片，因为丑一点的可能只有亲妈才能认出来。

还有，猜猜，它扪想不想当CPE？反正作者觉得它们正是为了抢入口而来。额，是不是有点不敢接着往下想。

图2-8：智能音箱

既然CPE不是SD-WAN特有的，也就说明CPE其实也不是SD-WAN所必需的。CPE是帮了你，但她没和你领证，她是你朋友，不是你配偶啊，所以，如果一个SD-WAN产品，非要一厢情愿去缠着CPE，那就是单相思是孽缘了，容易产生一些悲剧。这在某种程度上，也正是印证了进化论对疾病的观点：疾病是生物进化的产物。即，进化只是让利益和风险在特定的环境下达到了某种适应和平衡。任何一种平衡，都会随着物种自身的发展被打破——很多疾病的根源，其实正是上一次进化时留下来的优势。CPE在早期帮助SD-WAN取代SDN的同时，也在后期成为了一个隐隐发作的病灶。

其实，带头大哥在明升SD-WAN的同时，也在悄悄安排他的后事了，就是在2019-2020成熟度曲线图中那个迅速崛起的SASE，一下子从Innovation Trigger窜升到Peak of Inflated Expectations。

SASE的全称是Secure Access Service Edge，直译“安全访问服务边缘”，是带头大哥明示的“面向物联网和边缘计算的演进”，可以离用户更近，离应用更近，离边缘更近，更贴心，更安全，基本满足了当下对未来生产网络的所有幻想。

这里直接偷懒，如需了解SASE的演进逻辑，可以参考：

从广域网云化推演SASE：面向物联网和边缘计算的SD-WAN演进

我们可以看到：

3 SD-WAN之于边缘计算

从趋势分析来看，不知是否会冒出一个问题：把产品触点，或者说的再low一点，把某种CPE，往用户&应用&边缘侧推近一些就真的更好了吗？

在回答这个问题之前，让我们再来思考一个相对诡异的现象：设备商、运营商、云厂商、网络服务商、还有大量的创业公司，一股脑儿蜂拥在一个被Gartner以及IDC号称有40-60亿美金的SD-WAN市场，他们是炒概念炒疯了么？！

解答一个事件的疑惑，或者在开骂之前，得先花点时间去了解他。所以，让我们先来看一下SD-WAN的典型架构。

以下是主流SD-WAN产品的典型系统架构。

Subscriber Web Potal：基于Web的自服务门户，一般会与供应商的BSS/OSS系统打通，形成与商务层面的联动。
Service Orchestrator：编排器，负责将用户在自服务门户上输入的业务意图，编排成一系列的网络服务。服务编排器与自服务门户之间的接口，就是通常所说的北向接口。它相当于是连接了产品和系统。
SD-WAN Controller：控制器，负责将各种网络服务，进一步翻译成网络设备可懂的设备语言。控制器与网络设备之间的接口，就是通常所说的南向接口。它相当于是连接了系统和设备。
SD-WAN Edge：网络边缘设备，即俗称的CPE，执行具体网络策略的设备。在有些设备商的方案中，会有专门的强大一些的CPE，可以放到POP端做局端设备。注意，这里更为官方的名字是叫Edge，正是边缘计算的Edge。

以下是主流SD-WAN产品的典型网络架构。

接入侧：CPE-POP之间的网络部分，属于供应商的弱管控范围，底层承载的质量通常不可控。这也是在边缘计算时代，尤其是在MEC场景中，会发生巨变的一段。为了能在MEC场景中去理解它，我们甚至不得不再去拆分它。
骨干侧：POP-POP之间的网络部分，属于供应商的强管控范围，底层承载的质量通常可控（例如Aryaka的全球二层骨干网）。当然，理论而言，骨干侧并不是必须的，不过如果考虑的大背景是面向物联网和边缘计算的应用场景，有骨干资源的供应商，会有极大优势。
端到端隧道：CPE-CPE之间的逻辑连接，通常这是overlay隧道。基本原理如下：在一对CPE之间，基于用户在自服务门户上输入的业务意图（例如连接两个业务站点），通过编排器和控制器的编排翻译，向目标CPE下发设备配置，建立起支撑客户业务意图的一条条端到端隧道。

直接为客户提供服务的，正是这一条条的端到端管控的隧道。所有的花样，也就开始在这上面展开来玩。花样的复杂性，取决于各自的技术功底了，有些是擅长网络的、有些是擅长存储的、有些是擅长计算的；底层支撑的技术能力越多，可以玩出的花样就越多，当然前提还是要与目标场景相契合，即与自己的目标市场相接轨。绝对不要去羡慕巨头设备商五花八门的功能，更不要去直接抄作业；人家可能正在为自己的肥胖而苦恼，正在寻思着该怎么瘦身呢。

现在就可以来回答段首的疑问了？蜂拥进入一个“40-60亿美金市场”的巨头们是疯了吗？没有，人家可能都精着呢。SD-WAN意味着空前强大的端到端管控能力——而巨头对端到端管控这么痴迷，也是有原因的：

第四次科技革命的核心生产要素不是煤、不是石油、不是电力、而是过渡到了对数据的挖掘和使用。可以理解，这句话很多人听得都已耳朵起茧，不够直观；别急，下一篇会补上实际一例，直观显示由数据迸发出的无与伦比的生产力，以及以数据为主要生产资料的生产方式，会对包括网络在内的基础设施有着什么样的不同需求。

据IDC预测，2025年超过70%的数据和应用将在边缘产生和处理。

矛盾在哪？海量的数据在边缘，庞大的算力在中心。

幸运在哪？无论数据也好，算力也罢，都不再是煤、石油类似的具体实物，而是虚拟形态的生产要素，是有机会灵活“瞬移”的——这是以往的生产方式，想都不敢想的。

再直白一些，边缘的海量数据，需要的不是为它搬来一套庞大的基础设施，而是为其匹配适宜行业场景的算力即可。

端到端管控的网络，正如当下石油航道一般重要。所以，巨头对端到端管控能力的痴迷，跟海军对不停下饺子的痴迷，其逻辑是一样一样的。即，边缘计算是一种系统能力，只有建立在端到端管控的网络能力之上的那个边缘，才是真正的边缘；脱离网络能力孤悬海外的边缘，那叫飞地，迟早会失守。

这也正是SD-WAN之于边缘计算的意义：

采集企业数据/知识的入口；
分发厂商算力/智能的出口。

直接一些的，浅显一些的理解是，SD-WAN可以把流量拐走。这个层面的理解，可能还是在名义市场层面。

如果结合MEC协议中，对边缘计算时代里应用程序架构的构想，那就可以再宏观一些，即：如果整个网络都是云网融合的计算网络，那么SD-WAN拐走的就不仅仅是所谓的流量，而是决定着计算网络中的总线调度，那就会成为某种分布式操作系统类似进程/线程/IO调度器的一部分。脑子是个好东西，大家都想要，这可能是分布式大脑的一部分。

4 MEC用例协议导读

做完了以上铺垫，直接的导读部分就可以开始了。

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

Use Cases，即用例，是源自通信行业的一种常用的工程方法，它从使用场景的视角出发，重新梳理汇总需求，可以帮助提升需求理解的完备性和一致性。

所以，为了开发适当的MEC架构和API，用例协议描述了许多用例，以便得出一致的要求集，推导出MEC系统为支持上述特性而需要具备的能力。

协议将用例划分成了三个类别：

面向消费者的服务（Consumer-oriented services）：这些通常是创新服务，而且可以使最终用户直接受益；最终用户（end-user）是指使用UE的用户。包括：
游戏
远程桌面应用程序
增强和辅助现实（augmented and assisted reality）
认知协助（cognitive assistance）
等等
运营商和第三方服务（Operator and third party services）：这些通常是创新服务，但不是使最终用户直接受益，而是充分利用了运营商网络边缘附近的计算和存储设施，与第三方公司的服务一起运行。包括：
主动设备位置跟踪（active device location tracking）
大数据
安防安全（security, safety）
企业服务
等等
网络性能和QoE改进（Network performance and QoE improvements）：这些并不是面向最终用户的创新性服务；这些服务一般会通过特定应用程序，或者常规的改进来提升网络性能，通常可以改善用户体验。包括：
内容缓存/DNS缓存
性能优化
视频优化
等等

牧之注：注意security和safety这两个表示“安全”的英文，含义是不同的，如果全都翻译成“安全”之后不容易区分。大致区别在于是否具有主观故意：safety主要是指针对非恶意或非故意操作的保护措施；security主要是指针对恶意或故意操作的保护措施。所以全文将security翻译成“安防”，将safety翻译成“安全”。

个人觉得这个用例分类可能会有点混淆（好在分类不会影响推导），原因在于：这个分类标准比较依赖于“是否需要联合第三方来一起提供服务”，“是否是面向最终用户的服务”、“是否是创新服务”，而实际情况是：

不同国家的运营商的边界不同，例如，中国的三大运营商都还保留着云业务，而绝大多数海外运营商，尤其是北美运营商，其实是放弃云业务而在转售公有云的（在写文章时，刚刚发生：AT&T宣布将5G核心网全部迁移至Azure；微软同时宣布收购AT&T的网络云平台技术及相关人才，关系就更凌乱了，哇哈哈），欧洲运营商又会有些不同。这样，就没法准确区分“是否需要联合第三方来一起提供服务”了。
业务范围不同，也就进一步很难准确界定“是否面向最终用户”，“是否需要与第三方一起提供服务”，“是否是创新服务”了。

此外，由于原文并未对所有用例都标明类别，所以以下会基于自己的理解，将未标明类别的用例也归入三类之一：

面向消费者的服务（Consumer-oriented services）
5 增强现实，辅助现实，虚拟现实，认知辅助（Augmented reality, assisted reality, virtual reality, cognitive assistance）
6 游戏和低延迟云应用（Gaming and low latency cloud applications）
15 基于位置的服务推荐（Location-based service recommendation）
22 统一企业通信（Unified enterprise communications）
23 应用程序计算卸载（Application computation off-loading）
运营商和第三方服务（Operator and third party services）
4 安保、安全和数据分析（Security, safety, data analytics）
7 活跃设备位置跟踪（Active device location tracking）
8 应用程序可移植性（Application portability）
9 SLA管理（SLA management）
10 MEC边缘视频编排（MEC edge video orchestration）
12 与MEC应用程序的直接交互（Direct interaction with MEC application）
14 车辆对基础设施通信（Vehicle-to-infrastructure communication）
17 MEC平台使用来自运营商信任的MEC应用程序的信息（MEC platform consuming information from operator trusted MEC application）
21 聚合点中的无线网络信息生成（Radio network information generation in aggregation point）
25 摄像头即服务（Camera as a service）
26 在体育场馆环境中的视频制作和分发（Video production and delivery in a stadium environment）
28 未来工厂（Factories of the Future）
29 基于容器的灵活部署（Flexible development with Containers）
31 多用户多网络应用（Multi user, multi network applications）
36 车载MEC主机可支持汽车工作负载（In-vehicle MEC hosts supporting automotive workloads）
网络性能和QoE改进（Network performance and QoE improvements）
2 基于TCP吞吐指引的移动视频分发优化（Mobile video delivery optimization using throughput guidance for TCP）
3 移动边缘缓存本地内容（Local content caching at the mobile edge）
11 移动回传优化（Mobile backhaul optimization）
13 流量去重（Traffic deduplication）
16 应用程序带宽分配管理（Bandwidth allocation manager for applications）
18 视频缓存压缩和分析服务链（Video caching, compression and analytics service chaining）
19 无线接入承载监控（Radio access bearer monitoring）
20 密集网络环境中的MEC主机部署（MEC host deployment in dense-network environment）
24 多接入网络中的QoE和资源利用率优化（Optimizing QoE and resource utilization in multi-access network）
27 边缘媒体分发优化（Media Delivery Optimizations at the Edge）
30 第三方云提供商（Third Party Cloud Provider）
32 室内精确定位和内容推送（Indoor Precise Positioning and Content Pushing）
33 多无线接入技术应用程序计算卸载（Multi-RAT application computation offloading）
34 IPTV over WTTx
35 在5G环境中部署MEC系统（MEC System deployment in 5G environment）
37 受运营商信任的MEC应用程序（Operator trusted MEC applications）

以上，起始数字代表原文章节，这主要是为了便于感兴趣的读者，可以当作目录，直接回溯感兴趣的用例。

既然它们值得写入协议文档，所以每个用例都认真看了一遍整理了一遍。稍后就会按照类别，选取部分用例分篇叙述。

作者会尽可能将相关用例在干什么，用这个铺垫里的语言，转述给有兴趣的同行；如果对哪部分特别感兴趣，就可以直接根据索引去查阅原文内容了。

精力有限，会结合反馈来安排节奏和顺序；毕竟，如果只有少部分人有兴趣，更有价值的精力分配方式是直接交流——将协议文体写成普通文体，有点太费心力。

5 附录

为了保证文章主体顺畅，部分逻辑存在跳跃，故用附注方式说明。如读者未发现，可略过本章，不影响阅读。

第2章中，对于CPE病灶的解法，理论上可能有两种：

一种是往SASE，往边缘计算方向进行云化演进，即脱离硬件形态，脱离Capex形态，按场景所需，形成服务场景的逻辑CPE实体，用更大的产品架构来粘合，比如下图型态。如有兴趣，具体可参考《SD-WAN的生前身后名》。
另一种是创造一个实体，南向兼容各家设备。作者觉得兼容各家的SDN设备，这是有可能的，也仅仅是有可能，因为这还是在干线侧；而妄想去兼容不同厂家的Edge设备，敬你是一条汉子，想法很宏大，反正作者真不太看好。所以，直接跳过这个逻辑分支，是想尽早堵上这个取巧的想法。

第3章的推导，按严格逻辑，应该基于SASE来推导。不过交流下来，包括运营商在内，对SASE的理解程度，还是偏早期的，所以当前还是继续拿SD-WAN来分析推导。

推荐阅读

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