1.1 系列导读
本文是SD-WAN相关行业分析报告的完结篇。前两篇分别是：
第一篇：《SD-WAN行业理解：从广域网云化看SD-WAN》。提供了一个从“广域网云化”的视角去理解SD-WAN的思路：通过「行业背景」挖掘「行业本质」；通过「行业玩家」理清「行业生态」；通过「行业动态」推演「行业趋势」；通过「行业预测」预测「产品方向」。
第二篇：《从广域网云化推演SASE：面向物联网和边缘计算的SD-WAN演进》。承续前一篇的判断：“SD-WAN在单点技术上可能不是革命性的创新，但它改造的对象是广域网，后者已经是一项渗透到现代社会方方面面的基础设施，这种连接型创新会对整个行业造成非常深远的影响”。以“广域网云化和网络安全相结合”为例，推演当前最具前景的SASE：从「背景分析」挖掘「领域问题」；再从「领域问题」推演「产品分析」；再从「产品分析」梳理「行业玩家」；最后再回到「领域问题」，推演SASE的「未来展望」。
本篇填上两个旧坑和一个新坑：
为什么要关注“面向物联网和边缘计算的产品演进”？
为什么说“之前相对平行的行业（指传统行业和互联网行业）马上要见面了”？
为什么说MEC是最深的云网融合？
备注：所谓完结篇，是指之后不再特别提供SD-WAN视角的分析。也希望通过这三篇的分析报告，可以说明最初的看法：“SD-WAN不是一种技术，也不是一个产品，更像是一种生产方式的变迁”。SD-WAN的从业者，可以不必局限于SD-WAN；非SD-WAN的从业者，也可以了解一下SD-WAN。
1.2 本文导读
第二章，介绍基础概念，推演基本趋势，作为全文背景。
第三章，“最大的悲剧是战胜了所有对手，却输给了时代”。诺基亚之于苹果，余音缭绕；英特尔之于英伟达，历历在目。功能机的巅峰，输给了移动互联网时代；CPU的巅峰，输给了人工智能时代。做竞品分析时，最可怕的竞争对手，可能都没在视野范围内。本章从一则行业新闻开始，先从商业角度分析其相关性，再从技术角度分析其颠覆性。
第四章，从应用优化扩展到SD-WAN另一大广泛存在的产品形态：企业组网。本章将继续推演MEC在企业组网方面的新趋势，方便读者结合自己的业态分析竞合关系，规划产品演进。本章会从技术原理出发，重新回到MEC在商业落地上的独特优势。
第五章，为有兴趣进一步了解MEC的同学，提供一些说明。
备注：以上诺基亚指诺基亚手机；以下诺基亚指诺基亚网络。诺基亚有四大业务：手机，网络，软件和技术。
2 基础概念
2.1 什么是边缘计算
边缘计算是一种分布式计算范式 (distributed computing paradigm)，它把计算和存储部署到更接近需要的位置（一般是更靠近应用的数据源或使用者），从而缩短响应时间并节省带宽。
Edge computing is a distributed computing paradigm that brings computation and data storage closer to the location where it is needed, to improve response times and save bandwidth. — Wikipedia
可以推出，CDN产品是边缘计算的一种早期形态；也可以理解，CDN厂商会是一类重要的行业玩家。
此外，既然是一种范式，边缘计算就会有非常多的落地形态，例如本文的主角，多接入边缘计算（Multi-access Edge Computing, MEC）。
2.2 为什么需要边缘计算
这个问题其实是与一系列问题高度关联的。推演这个问题的逻辑时，顺带也会推出“为什么需要物联网”、“为什么需要5G”、“为什么需要人工智能/机器学习”等一系列问题的答案。
以云计算为基础的算力爆发（算力） + 以消费互联网行业为代表的数据积累（算料） + 以深度学习为代表的人工智能算法突破（算法）= 令人兴奋的智能应用（智能）；这个模式已经被实证了，并且三要素还在快速演进。
“Two things are infinite: the universe and human stupidity; and I’m not sure about the universe.” — Albert Einstein
人类的欲望是无止尽的。前三次工业革命解放了人类的双手，极大提升了人类的体力边界，第四次工业革命能否解放人类的大脑，提升人类的脑力边界？自然的第一步就是：能不能将已经实证的智能模式，扩展到其他领域？能。
智能的扩张需要数量更多的数据来喂养。物联网技术会将人、物、环境、过程等数字化，带来前所未有的数据广度和数据深度。这也会直接催化一个产业互联网的大势，比如行业估值惊人的工业物联网。
消费互联网过渡到产业互联网，会遭遇怎样的根本性矛盾？网络主体的变化必然会导致网络本质的变化：消费互联网的主要参与者是人，产业互联网的主要参与者是机器。人与机器有什么最大的不同？答案是人弱爆了：例如100ms的应用响应延迟，对人而言几乎无感，但对机器而言，可能已是“沧海桑田”了。
如何解决“快”的问题？一方面，就是以5G为代表的下一代通信技术。5G从设计之初，定位的通信主体就是物/机器，涵盖了对增强型移动宽带（enhanced Mobile Broad Band, eMBB）、大规模机器类型通信（massive Machine Type Communications, mMTC）、超可靠低延迟通信（ultra-Reliable and Low Latency Communications,uRLLC）三大场景的支持，为此重点投入到一系列关键技术：
切片（Slicing）：三大应用场景属于“既要又要还要”的“无理要求”，太刺激太挑战了，需要通过切片技术让同一张物理网络具备变形金刚的能力，即将同一张物理网络按需动态切分成各个子网络。
控制与数据面分离（Control and User Plane Separation,CUPS）：延续了4G的趋势，但是为了支持切片分离得更为彻底了，彻底到连网元的命名都功能化了。
基于服务的架构（Service-Based Architecture, SBA）：核心网网元被彻底打散，各网元会按场景所需灵活部署到所需位置，架构上就借鉴了互联网行业松耦合的SBA架构。
用户数据面功能（User Plane Function, UPF）：UPF是唯一的核心网数据面网元，也是MEC和5G网络的连接点，其灵活下沉的能力是5G实现三大场景的关键之一。
网络功能虚拟化（Network Function Virtualization, NFV）：为了摆脱被硬件捆绑和被位置束缚，从核心网到接入网都被NFV搞得面目全非，各网元甚至都没了“正经名字”。
软件定义网络（Software-Defined Networking, Software-Defined WAN, SDN/SD-WAN）：承载网应对三大场景挑战的大势所趋。
不过5G的网络再强，光速也会是一个无法突破的物理限制，那该怎么办呢？“山不过来，我就过去”，把计算和存储，部署到更靠近数据源或用户的位置。这不就回到了边缘计算的定义了么。
图2-1: 5G的三大应用场景；来源: https://www.etsi.org/technologies/5g
以上，边缘计算和5G、物联网、人工智能/机器学习等领域，都是产业互联网时代，或者说“泛智能时代”的必然趋势，只不过各有分工侧重而已。
小结一下，为什么需要边缘计算？突破以下限制：
物理限制：端到端的应用时延无法突破光速。
安全限制：特定行业要求数据不出园区。
经济限制：原始数据直接回传会产生大量的带宽费用和存储费用（一辆智能汽车一天产生的数据量约为4TB — Intel），在近数据源预处理后再协同，可以极大地降本增效。
网络限制：莫非定律，突破对可靠连接的依赖。
图2-2: Imperatives That Determine the Value of Edge Computing；来源: 2021 Strategic Roadmap for Edge Computing
2.3 什么是多接入边缘计算
理解了什么是边缘计算，那么什么又是多接入边缘计算呢？
多接入边缘计算（Multi-access Edge Computing, MEC）在网络边缘为应用程序开发者和内容提供商，提供了云计算能力和IT服务环境。这种环境的特点是超低时延和超高带宽，并且应用程序可以使用无线网络侧的实时信息。MEC提供了新的生态系统和价值链。运营商可以向授权的第三方开放其无线接入网的边缘，从而使他们能够灵活、快速地向移动网络用户、企业用户和细分垂直市场，部署创新的应用程序和服务。
Multi-access Edge Computing (MEC) offers application developers and content providers cloud-computing capabilities and an IT service environment at the edge of the network. This environment is characterized by ultra-low latency and high bandwidth as well as real-time access to radio network information that can be leveraged by applications. MEC provides a new ecosystem and value chain. Operators can open their Radio Access Network (RAN) edge to authorized third-parties, allowing them to flexibly and rapidly deploy innovative applications and services towards mobile subscribers, enterprises and vertical segments. — ETSI
值得一提的是，“超低时延和超高带宽”很直观很好理解，“可以使用无线网络侧的实时信息”又有什么特别之处吗？太重要了！应用程序具备了获取实时无线信道特性的可能性，当前没有比这更为彻底的云网融合的方式了。科班同学可以回忆一下数字通信原理，信道编码的目的就是基于不同的信道特性，设计出匹配信道特性的码元，从而提升整个系统的抗干扰能力，发挥最大的系统性能。不是相关专业的读者，有兴趣的话可以参考下图的来源链接；暂时不理解也无妨，后续会拆解多个相关用例，给出多个形象化的说明。
图2-3: 数字通信系统原理；来源: http://www.ecsponline.com/yz/B0DA2CFC0D1DC4C279849FF3A55BE9F1A000.pdf
备注：无线接入网（Radio Access Network, RAN）是移动通信系统（有时也被称为“蜂窝移动通信系统”）的重要组成部分，就是手机直接连接的这个网络；后续会结合上下文需要，逐步给出相关介绍。
2.4 为什么需要MEC
十亿级人口，千亿级设备的第一入口，并且可以支持广域网级别的移动性，这个理由足够了吗。
2.5 MEC的现状
多接入边缘计算，原名移动边缘计算（Mobile Edge Computing, MEC），这个概念最早出现于2013年。
2013年，IBM与诺基亚网络共同推出了全球第一款移动边缘计算平台，可在基站侧提供富媒体服务。
2014年，欧洲电信标准协会（European Telecommunications Standards Institute, ETSI）成立MEC规范工作组，正式宣布推动MEC的标准化。
2016年，ETSI把MEC的接入方式从蜂窝网络扩展到WLAN等其他接入方式，即把移动边缘计算的概念，扩展成为了多接入边缘计算。
此外，MEC还将作为5G的关键技术之一，用于支撑5G的低时延业务场景。2020年12年，ETSI发布了5G MEC集成报告，并宣布扩展规范工作组的对应职能。所以，可以认为当前MEC标准由ETSI和3GPP共同制定：ETSI负责定义整个MEC的框架和架构，包括应用部署环境，管理软件架构、应用场景和API接口等；3GPP负责定义5G网络对MEC的支撑和实现，以及如何提供服务质量保障。
3 MEC在应用优化领域的融合演进
3.1 从一则新闻说起
2020年04月29日，中国联通首张MEC规模商用网络正式发布。其中披露：2019年，中国联通联合腾讯、中兴在深圳进行了基于MEC的vCDN边缘加速和TCPO的规模化商用试点验证。一方面，通过MEC边缘云与部署在云端的DNS、CDN及移动客户端联动，利用MEC实现vCDN下沉和本地流量卸载，减小时延提升用户感知；另一方面，在MEC部署TCP优化能力，解决无线丢包导致的服务器降速问题。本次商业试点涉及近百个现网基站，日用户连接建立数最大近3万，忙时小时粒度流量达到2.5T。测试结果表明，通过部署边缘vCDN，平均降低40%接入时延，并减少30%卡顿；通过部署TCPO功能，上传平均速率增益15%，下载平均速率增益56%，可极大提升用户体验。— 声明：利益不相关
这则新闻包含了两个关键特性：
通过部署边缘vCDN，平均降低40%接入时延，并减少30%卡顿
通过部署TCPO特性，上传平均速率增益15%，下载平均速率增益56%，可极大提升用户体验
为了简化分析但不失逻辑，这里把vCDN特性，简化为静态内容加速方案；把TCPO特性，简化为动态内容加速方案。
鉴于当前的SD-WAN类型产品，一大卖点就是“提升应用体验”，所以先从商业竞争角度分析一下关联性：
这则新闻说明了什么？诞生了一种新产品，可以大幅提升最终用户的应用体验，包括静态内容和动态内容。
新产品的产品形态？不需要额外的硬件和软件，后台可以即时开通，即可以做到最终用户无感开通。
新对手是谁？好家伙，巨无霸，进来一个基础运营商。
新产品的供应范围？理论上只要是基站信号可以覆盖的区域，都可以提供。顺便插播两则“坏消息”：
作为基建狂魔，中国是全球基站信号覆盖最好的国家之一。
中国的智能手机普及率为69%。上限在哪呢？可以参考一下其他国家：美国为77%；同属东亚文化体系的韩国为94%，即东亚人相对更加腼腆，更偏好智能终端。
新对手的客户资源？理论上拥有包括消费用户和企业用户在内的所有用户。开发存量客户和开发新客户之间的难度差别，不可同日而语。对手一次原型测试，就可以做到“日用户连接建立数最大近3万”。
小结一下对比参考：
客户资源：对手在接入侧掌握着全部用户，即上述的“十亿级人口和千亿级设备的第一入口”。
开通速度：对手可以零等待，无感开通。
边际交付成本：对手几乎零成本。
产品价值 = (新体验 - 旧体验 - 迁移成本) x 用户规模
在“迁移成本”和“用户规模”方面，对方完胜；在2B市场的品牌形象方面，对手也具有压倒性的优势。剩下能比拼的就是在特定的细分场景下，“新体验”和“旧体验”之间，到底有多少差异了；当然还有就是时间问题，时间会影响稳定性和价格等。不过，因为对手掌握着全部客户，并且可以做到无感交付，这意味着一个什么样的战略态势？“先为不可胜，以待敌之可胜”，所以，时间站在了运营商那一边。
以上是外部视角分析，新产品落地时需要考虑的问题很多，远非外部视角分析那么简单。本文的目的也不是为了制造焦虑，而是为了提供新维度，便于读者结合各自的内部视角进一步分析。
备注：vCDN边缘加速，前期大概率不是为了和当前的CDN产品去做商业竞争，而是为了解决运营商自己的回传压力，也就是说，初衷可能是为了与同等规模的运营商去竞争网络体验。但在另一个维度上，它同时也是坏消息，“神仙打架，凡人遭殃”，即使不直接参与商业竞争，也是会和CDN厂家合作演化，在源头直接消灭一批客户需求。
3.2 vCDN边缘加速
以下从技术角度，继续挖掘这则新闻。vCDN边缘加速，更为正式的名称可能是：移动边缘缓存本地内容 (Local content caching at the mobile edge)。该用例是MEC众多用例中，技术难度相对较低，容易早期实现的，其本质是“将CDN功能下沉到基站”。
第一个问题：我们不是已经有了CDN吗，为什么要在移动边缘缓存本地内容？
在回答这个问题之前，以及为了便于真正理解MEC，需要先做一段预备科普。
互联网行业人员，习惯把运营商网络叫做“管”，习惯了之后就容易被迷惑了。这个所谓的“管”，其实是一个庞大而复杂的系统，可能是世界上最为复杂的民用系统之一。以移动通信网为例，在最宏观层面进行拆解，可以分为无线接入网（Radio Access Network, RAN）、核心网（Core Network, CN）和承载网三部分。我们的手机通过各种制式的无线接入技术（Radio Access Technology, RAT）连接到无线接入网；无线接入网再通过各种回传（Backhaul）技术连接到核心网；经过核心网之后，才会进入互联网。大家所熟悉的CDN系统，大多就部署在核心网之后，其实离最终用户很远，可以参考下图。
图3-1: Mobile Network Problems Before MEC；来源: https://qwilt.com/5g-mec/qwilts-5g-mec-solution/
有了对移动通信网络的预备科普之后，为了能理解问题的本质，还缺了对其承载的主要业态的推演。
现阶段的互联网有个别称，叫“移动互联网时代”，它的几个特点：1、人是网络主体；2、智能终端已普及；3、高速网络已建立。有一个行业的充分条件已经具备，只缺在源头推它一把，这个源头就是：人类是一个特别有八卦精神的种族。在移动互联网时代，每个人都有一个可以随时随地随意匿名生产/消费八卦的终端，任何一个火星，都有可能激活一个链式反应，被网络急剧放大，造就了一大批新型社交媒体类型的巨头：Facebook、Twitter、YouTube、Instagram，微博等。热点会以病毒式传播，多媒体内容会在同一地区，几乎同时被消耗很多倍，而被寄予厚望的CDN系统，对此却无能为力。
综上，移动互联网在逻辑结构上适合社交媒体业务的发展，但在物理结构上又难以适应它的爆发，结果就是：普罗大众盼着第一时间吃瓜的体验不爽；运营商在管道层面承受着巨大的压力；需求被层层上捅之后，就容易导致丁振凯，史上最惨新浪程序员。呜呼哀哉，我等无辜码农是相对最不八卦的群体了，最终却被八卦伤得最深。
究其原因，根源就在于当前的内容分发系统（比如CDN），与移动通信系统，是两套相对独立的系统。移动通信系统，就负责通信，真的在认认真真做管道，属于运营商的强管控范围；内容分发系统，是一套互联网应用系统，属于互联网公司的强管控范围，两者是脱离的。
如此，通过MEC部署vCDN的价值及意义，相对就更加明确了。MEC可以在最接近用户的地理边缘，缓存本地热点内容。最终用户可以大幅提升用户体验，运营商可以节省回传费用，内容提供商也可以躺着增收。
图3-2: MEC - Outcomes for Mobile Service Providers；来源: https://qwilt.com/5g-mec/qwilts-5g-mec-solution/
备注：
以上“八卦”是个中性词，包含着“看看别人在干些什么，然后发表评价/发挥想象/结成群体”等广义含义，没有贬义成分。八卦其实是个严肃的话题，它是人类社会的根基，是人类得以在万千物种中胜出的根本。有兴趣可以参考一下《人类简史》。
为了避免画图找了两张示意图。图片来自国外公司，所以出现了“Mobile Backhaul”的无线回传方式。国外普遍挖沟不便，采用无线方式回传相对较多，我国国情不同，多采用有线回传方式，特此说明。
应用系统和移动通信系统两者的脱离，有移动通信系统技术演进方面的历史原因。移动通信设备，长期是一个“系统复杂，硬件专用，软件定制”的相对封闭的行业，但也是一直在努力往“通用化-池化-云化”方向努力，部分读者可能听说的C-RAN（C一般是指Centralized，在不同的上下文中，也可能指Clean, Collaborative或Cloud）就是一个最好的例子。O-RAN就又是在这方面一个喧闹的方向，喧闹到已经可以看到国家层面的博弈了。不过在技术上，在争论的可能更多是一个“迈多大的步子可以不扯到蛋”的问题，很欢乐很有意思，而且MEC会与O-RAN之间存在较强关联，有兴趣可进一步参考相关文档。本文已很长，不再展开。
3.3 TCPO特性
中国联通在白皮书中也给出了“基于MEC的CDN边缘加速方案图”，包含了vCDN特性和TCPO特性。
图3-3: 基于MEC的CDN边缘加速方案图；来源: 《中国联通5G MEC边缘云平台架构及商用实践白皮书》
这类PR的方案图一般经过处理，只会让你看到“牛逼”不会让你看到原理，以下就从外部视角来做一下相关的技术拆解。
TCPO特性，更为正式的名称可能是：基于TCP吞吐指引的移动视频分发优化（Mobile video delivery optimization using throughput guidance for TCP）。名字中带着“移动视频分发”是因为视频是移动网络上最受欢迎的内容（占总流量的55+％），但是这类TCP优化特性，并不局限于视频应用，可以适用于所有基于TCP的服务和应用，包括Web业务和文件下载。
TCP吞吐指引特性，应该会是直播、在线教育等实时音视频领域玩家感兴趣的，因为一些常用的流媒体协议，要么直接将TCP做为传输协议，例如Adobe的RTMP（Real Time Messaging Protocol），要么会基于HTTP流来完成，而HTTP流又通常基于TCP协议，比如Adobe的HTTP-FLV，以及Apple的HLS（HTTP Live Streaming）。
一个类似的问题？不是已经有了很多实时音视频优化类产品了，为什么还要MEC的TCP吞吐指引特性来优化？
也是一样，在回答这个问题之前，以及便于深入理解MEC，还需要再做一段预备科普。
在移动通信系统中，无线接入网的信道条件，其复杂性要远远超过固定网络：天气、地形、建筑、从步行速率到高铁速率的各种移动性，从普通电话到高清视频的各种多样性，导致了“只有想不到，没有不可能”的信道复杂性。一个最平凡的例子，你身边的任何人，都可能会随时进入网络并随时离开，这些都会造成系统负载和信道条件，在几秒之内就发生一个数量级的剧变。而在另一方面，TCP太古老了，在发明TCP时，压根就没考虑过无线信道这回事。到了移动互联网时代了，大量的应用被搬到移动环境了，TCP也就只能硬着头皮上了。这好比：你明明学的是计算机，但过年回家总会有亲友让你帮忙修一下电脑——你心里明明知道这可不是一回事，但也只能硬着头皮上，毕竟舍你其谁，你说是吧。
综上，传统的TCP难以适应快速变化的网络条件，会导致无线网络资源的低效使用，最终降低移动应用的性能和最终用户的体验。
在进一步介绍TCP吞吐指引特性之前，可能还得再来为细心的读者解答两个可能的疑问：
既然TCP那么不适应无线环境，那为什么不干脆在开启移动互联网时代时另起炉灶？这是因为基础设施行业具有很强的传承性，有时候比拼的不是技术的先进性，而是方案的传承性：你可以在旧方案上修补，但是不能完全抛弃。比如，即使都已经进入高铁时代了，车厢的宽度最终还是要取决于两匹马的马屁宽度，你到哪里说理去？有什么技术先进性可言吗？
好吧，听上去这是一个普遍的问题，那为什么不在运营商这一端做代理？本质上还是一样的原因，这会突破“通信系统”和“应用系统”之间的边界，之前缺少一个类似MEC这样的落位。这不仅仅是地理上的落位，也包括逻辑上的落位。而且，事实上MEC和TCP吞吐指引在4G时代就已被提出，但是并不普及，只不过在5G时代，MEC不再是一个锦上添花的分支，而是变成了一个系统必需。
终于可以来介绍一下TCP吞吐指引特性了。TCP吞吐指引是一个基于MEC服务构建的带无线分析（radio analytics）功能的MEC应用程序，它可以为后端的应用服务器提供接近实时的无线信道质量指示，这个指示叫做吞吐指引（Throughput Guidance, TG）。吞吐指引是一个特定于应用程序的数字，它为应用服务器提供了一个在即将到来的时间周期内，无线信道可以预期承载的比特率的提示，应用服务器可以据此信息来辅助TCP拥塞控制。有了吞吐指引，TCP就可以不必为探测可用资源而导致网络过载，也不必在拥塞发生后像传统算法那样过于保守。
互联网工程任务组（Internet Engineering Task Force, IETF）已经给出了吞吐指引的原理、方案及效果。ETSI也给出了在MEC运行TCP吞吐指引的参考模型：
启用带有吞吐指引功能的应用程序后，将使用MEC平台的服务注册表（service registry）来查找可以提供无线网络信息的服务程序（service）。
通过MEC平台，应用程序在连接匹配的服务程序后，可以获得所需的无线网络信息，然后计算出特定于应用的吞吐指引，然后通过MEC平台将吞吐指引带内传送给应用服务器。
终端用户设备上的客户端，可以不做任何修改。
图3-4: Throughput Guidance Mechanism；来源: IETF：https://www.ietf.org/proceedings/93/slides/slides-93-iccrg-3.pdf
值得说明的是，第一句其实是重要的，暗含了MEC里的生态关系。运营商是没有能力解决万千应用问题的，他们有很大的战略优势，但也需要整个生态的配合。MEC的魅力之一，也在于它第一次提供了一个极好的云网融合的协作平台，在这个生态里，目前可以预测的有：
网络运营商（Network Service Provider）：不同运营商有不同的覆盖范围。
房地产商（Real estate owner）：比如中国铁塔、各类园区和综合体等。
云厂商（Cloud capability provider）：这是一个大类，可以进一步细分，比如提供计算能力的，提供存储能力的，另外一个细分维度是提供资的和提供服务的，等等。
应用服务提供方（Application/service provider）：一方面跟当前应用市场类似，可能会有个人开发者和公司等多种形态；另一方面也会具有云市场的一些特点，即有些供应商它不直接生产软件，但会基于第三方软件提供服务。
有能力的玩家，可以身兼多职；而且觉得ETSI有点回避了平台方这个角色，可能会是个“既心知肚明又暗中较劲”的领域吧。
There is more than one stakeholder in this ecosystem, e.g. Network Service Provider, Real estate owner, Cloud capability (compute and storage resource) provider, Application/service provider. An entity can assume more than one role. From network operators point of view there may be “Cloud provider” or “Cloud service provider” depending on the roles assumed by external entity.
以上，可以看出TCP吞吐指引特性在技术上并不复杂，逻辑抽象之后就更为简单：特定于应用的吞吐指引生成器，可以看作是应用服务器部署在无线接入网侧的一个分布式组件，如下图。
图3-5: Throughput Guidance Solution Architecture；来源: IETF：https://www.ietf.org/proceedings/92/slides/slides-92-tsvwg-12.pdf
TCPO的实际效果，联通已经在生产环境中给出，此外，IETF也给出了吞吐指引在改善传统TCP慢启动方面的实测图，对比感更强。
图3-6: TCP Optimization about Slow Start；来源: IETF：https://www.ietf.org/proceedings/93/slides/slides-93-iccrg-3.pdf
备注：
以上关于吞吐指引的说明，使用了有关无线信道和当前负载的最新信息。还可以使用来自基站的其他关于IP流的特定信息来进一步优化过程。例如，获取有关当前可用缓冲区大小的信息，这对于调整TCP窗口大小可能会很有用。即，随着这个领域开放后，还有不少潜力待挖掘。
并不否认，可能会发展出其他替代方案来缓解上述问题，但不会像MEC方案这样直击云网融合的本质。
4 MEC在企业组网领域的融合演进
4.1 统一企业通信
ETSI给出了统一企业通信 (Unified enterprise communications)的示意图。这张图比较简单，但也已经足够有意思了。
图4-1: Multi-access Edge Computing based breakout to an enterprise network；来源: ETSI GS MEC 002 MEC Use Cases and Requirements
第一个问题：图中的小基站（Small Cells）是什么？为了便于介绍MEC在企业组网领域的交融演进，再来做一下基站科普。平时偶尔也能听到大家会说起基站，然后发现指代的多是那个大铁塔（其实不准确，不过先不管了），这种叫做宏基站（Macro Cell）。宏基站主要用于满足广覆盖的需求，比如为什么周边国家有时会收到“欢迎来到xx，中国移动竭诚为您服务”，就是因为宏站甚至可以覆盖数百公里的半径；另一类就是小基站（Small Cell），主要用来补充室内和热点区域的覆盖和容量。小基站还只是一类统称，遵照“微米-纳米-皮米-飞米”的细化，小基站在市场竞争下就出现了“微基站”（MicroCell），“纳基站”（NanoCell），“皮基站”（PicoCell），“飞基站”（FemtoCell）。它们到底长什么样？其实跟大家平时见的WiFi路由器类似，给一张作者参与过的小基站的实物图。
图4-2: Nokia’s Flexi Zone Indoor Pico small cell；来源: Nokia
第二个问题：既然说是企业组网，那么边界在哪？如果说MEC是边界，那么通过小基站在本地上连的企业设备怎么办？如果他们在边界外，那么再结合前文给出的移动通信系统的科普，岂不意味着小基站下的本地设备，要去核心网（示意图中的Mobile Core）绕一大圈再回来？是的，示意图很简单，但稍一分析，就可以发现已经蕴含着挺多“坑”了，或者说马上就要引到当前5G和MEC发展过程中的一些热点问题了。这些坑，会留在后续的专题，暂不展开了。不过，有一个问题已经是可以非常明确的了：套用当前的企业组网模型，把包括MEC在内的任何节点作为边界，都是不合适的。边界会越来越模糊，越来越灵活。此外，为什么SD-WAN要那么强调Hybrid-WAN以及一系列配套的苛刻的切换特性，如果换个参照系，可能会理解得更加彻底。
第三个问题：会有那么多小基站吗？这其实是一个不是问题的问题。从“第一性原理”出发，也就是从电磁波的物理特性上来看，5G为了支撑eMBB场景的大带宽，必定会往高频段走，高频段就会牺牲电磁波的衍射能力，仅凭这一点，就可以断言小基站在5G时代的重要性会远超之前。非相关专业的读者可能不理解这个逻辑，那就再来看看现实情况的映衬：关注MWC等相关展会的读者，可能已经发现，越来越多的厂家在第一次进入5G这个领域，选择的切入点就是小基站，比如新华三。
一旦企业网络具备了强大的覆盖范围和计算容量，企业就具备了开始向真正的移动办公迁移的条件：可以使用任何终端基于身份随处访问基于云原生的业务工具和流程。类似趋势已经在消费互联网市场上上演过一遍了，在产业互联网阶段，大概率会延续。在企业场所中部署的小基站，会使MEC成为在移动网络边缘支持企业应用程序的自然选择。
这种形态的企业网络，具备哪些独特的优势：
基于切片的网络：借助5G的切片特性，企业通过选择适合性价比的切片级别，就可以直接交付一张企业专有网络。这张企业专有网络可以具备敏捷、弹性、按量付费等特性。
基于身份的网络：网络行为可以与用户的企业身份相关联，以支持基于用户身份的流量规则。
提供算力的网络：可以进一步结合MEC的“应用程序计算卸载”特性（后续详述），让企业可以突破云计算时代的产品限制。具体突破哪些限制，可以参考第二章，此处不再赘述。
备注：
ETSI还给出了统一企业通信用例的其它优势，略去了部分与中国国情不符的特性。如果主打全球市场，可以进一步参考ETSI材料。
4.2 应用程序计算卸载
图4-3: Application computation off-loading using MEC；来源: ETSI GS MEC 002 MEC Use Cases and Requirements
应用程序计算卸载（Application computation off-loading）是指：通过在MEC主机上提供丰富的计算资源，将用户应用程序的计算卸载到MEC主机上，最典型的应用比如AR/VR等。
是不是有点似曾相识的感觉，是的，传统云计算的老生常谈。不过位置的变化和通信主体的变化，会让MEC的计算卸载有些本质不同：
就像云计算改变了端/云的Capex分配以及组网模型，MEC的计算卸载带来了端/边/云的新维度，会进一步重塑IT系统的Capex分配及组网模型。云计算是云接收端的卸载，MEC则可能会基于不同业务类型，接受端和云两侧的卸载，最典型的应用比如传感器数据清理，监控视频分析等，这类业务无论放端放云可能都不合适。“一生二，二生三，三生万物”，每增加一个新维度，在技术和商业上带来的灵活性和复杂度，都是容易在事先被严重低估的。
通信主体不同，终端数量巨大，每种应用场景都会有一个最佳的端边云成本配比；外加MEC会更加拓展到传统企业场景，这意味着MEC市场一方面对场景需求会更加苛刻，另一方面对小供应商会更加包容。
位置的特殊性，使得MEC的计算卸载，可能会突破传统云计算下的C/S模型，这意味着无论是基础设施还是应用程序，可能都会面临更大的变数和机会。例如，终端可能会演化成分布式计算机的I/O子系统，部分软件也面临着重构或适配。
图4-4: 冯诺依曼计算机模型；来源: 互联网
综上：
有个“跨界产品”会让企业组网环境发生巨变，甚至包括业态的变化。如果要做长期产品演进，不理解这个大环境，只想一厢情愿地塞一个CPE进去，很可能会真的有些一厢情愿。
“talk is cheap show me the code”，与泛泛畅想不同，这个变化基本是可以分析到一些轮廓痕迹了，包括：标准组织的规划演进，相关企业的真金白银投入，相关行业的合作孵化。
此外，既然上一篇的题目叫《从广域网云化推演SASE：面向物联网和边缘计算的SD-WAN演进》，本篇的延续主题是“边缘计算”，希望在本篇可以看到SASE的一些影子：
SASE的“薄分支-厚云端”，MEC的“计算卸载”。
SASE的“不假设任何边界”，MEC的“难以区分边界”。
SASE的“以身份为核心”，MEC的“基于身份”。
SASE的“云原生”，MEC的“云原生”。
最后，再次说明，本文不是为了制造焦虑，而是为了提供新的行业视角。值得庆幸的是，变化对弱者而言，是机会成分更大；对强者而言，是风险成分更大，不然每个时代如日中天的巨头们，怎么会倒下呢。
5 后续
预测趋势要比预测时间点简单的多。泛智能时代的应用场景，会融合物联网、边缘计算、人工智能等领域，MEC会是承载它们进行融合的大舞台。准备开始一个系列，梳理一下5G MEC相关的框架和规范。两个目的：
一部分的行业新知，可以通过梳理规范/协议的来龙去脉来获得，这些可以算是“巨人的肩膀”。只不过规范/协议类的文档，为了追求工程表述的准确性，通常很干很枯燥，大部分人不会去读。设备商和云网行业产研背景，对两者均有一定了解，可以在这方面做一些力所能及的输出。
另一部分的行业新知，需要通过相关行业的场景交流来获得，所以也想借此机会，了解相关行业的结合应用作为输入，还望不吝交流赐教。
欢迎加「知乎主页」交流：https://www.zhihu.com/people/hickoryfans
参考：
ETSI GS MEC 002 MEC Use Cases and Requirements, ETSI, 2018-10
《中国联通5G MEC边缘云平台架构及商用实践白皮书》，中国联通，2020-04
