通信人家园
标题: MEC在5G能走多远？ [查看完整版帖子] [打印本页]
时间: 2020-8-7 10:32
作者: 溯溪而上
标题: MEC在5G能走多远？
边缘计算技术（Mobile Edge Computing）是ICT融合的产物，结合日渐成熟的SDN/NFV、大数据、人工智能等技术，5G网络成为各行业数字化转型的关键基础设施之时，MEC也成为支撑运营商进行5G网络转型的关键技术，以满足高清视频、VR/AR、工业互联网、车联网等业务发展需求。MEC作为新兴IT技术的代表，终于在电信运营商的网络中有立足之地。它能在传统的CT领域融入多深？走多远？
MEC标准的发展
早在2009年，3GPP尝试在R10的3G/4G标准中引入LIPA-SIPTO(本地IP接入，本地IP分流)方案，用于数据不经过核心网，直接在家庭小站的分流，此时已经具备了“边缘分流”的基本功能。在宏蜂窝网络中的方案也后续完成，但是只能以APN为粒度，并且需要在终端侧进行手工配置。2017年，3GPP在R14的4G网络构架中引入了CUPS（控制面和用户面分离），控制面可以根据APN选择用户面，分流功能更进一步。但是此时5G呼之欲出，运营商和设备商都已经无意在4G网络中大力推动这项技术了。终于在R155G标准中，3GPP SA2下一代网络构架研究（TR23.799）以及5G系统架构（TR23.501）中对边缘计算予以了支持。MEC可以根据应用信息（应用标识、IP地址、数据流规则等）通过5G控制面AF传递给PCF，从而影响SMF进行UPF选择及PDU会话建立。
MEC从R10的最原始的分流功能，历经近10年，跨越了5个3GPP的版本，伴随着5G核心网SBA构架的形成和云计算的快速发展，形成了现在的边缘计算的技术形态。
MEC标准是双规发展制。一方面3GPP着重定义MEC和5GC网元的交互方式，另一方面ETSI着重在MEC的平台、虚机和API等等的管理。从2014年到2016年，ETSI陆陆续续完成关于MEC平台构架，虚机管理，API管理等等规范。在ETSI眼中，MEC是ETSI与3GPP融合发展的典范。
但是目前的融合也仅仅能支持业务本地化、本地分流等的基本功能。更进一步的能力，无线网络能力开放，位置服务，和移动性管理等能力，需要等待3GPP R17的Deployment guidelines for typical edge computing use cases in 5G Core network(5GC)、Study on enhancement of support for Edge Computing in 5G Core network(5GC)、Architecture for enabling Edge Applications(EA)等研究成果了。ETSI设想的MEC融合C-RAN，最深度融入蜂窝网络，提供最短时延的方式，在3GPP里还无计划。
且不说标准成熟度能否支撑商用。就电信行业现行的商业模式，跨越“G”的技术，如从4G到5G，由于设备商看重市场份额，运营商和设备商都会加快推动新技术的落地。如果属于同一“G”中的演进类版本中的技术，大多数都难以商业部署，这一点从MEC在R10到R14的遭遇就可以看到；其实很多3G/4G在3GPP中的演进技术的商业落地都很缓慢。但这并不能改变MEC作为两大标准体系的结合的典范。
从上图可以看到，5G中实现超低时延，5G系统本身的作用是极其有限的。即使URLLC辛辛苦苦把空口时延从10ms降低到1ms，对整体230-2130ms级别时延的影响微乎其微。将MEC插入到核心网（CoreNetwork）之前，则可以迅速将时延缩。MEC才是现实5G超低时延最关键的技术。
上图是中国联通白皮书中对MEC全国部署构想，区域DC在全国范围内大约有70-80个，端到端时延小于50ms，服务全国。本地DC在全国范围内大约有600-700个，端到端时延小于20ms，部署位置位于地级市和省内重点县级市。边缘DC在全国范围内约有6000-7000个，端到端时延小于10ms，边缘DC化改造主体是汇聚机房。综合接入局房在全国范围内约有6万-7万个，端到端时延在2ms-5ms之间。
如此巨大的投资，运营商自然是希望能从MEC得到回报的。
MEC的商业潜力
从4G开始，移动互联网打破电信运营商封闭的花园，OTT多种多样服务类型的快速出现，以BAT为代表的OTT公司的收入利润快速增长，运营商却只能眼睁睁的看着流量指数级增长，自己的收入利润原地踏步，一步步沦为数据“哑管道”。运营商从OTT增长中找到新增长点的渴望已经是司马昭之心—路人皆知。运营商自然不会轻易放弃从MEC盈利的机会。根据Chetan Sharma的预计MEC能在2030年在全球带来超过4万亿美元的收入增长，但是超过75%的收入都是来自应用的，运营商的连接收入增长少得可怜。要知道，GSMA估计2019年全球运营商无线网络收入也就1万亿美元左右。从4万亿的商业潜力中分得一杯羹，对增长乏力运营商来说，太重要了。
另一家咨询公司Mobile Expert则给出了更详细的预测，到2025年低时延无线连接给美国运营商带来的增量收入，大约只有12亿美元。2019年美国运营商的无线连接收入大约为250亿美元。12亿美元的增长实在是微乎其微。
看到了不同业务领域的巨大的商业潜力差距，不难理解Analysys Mason针对全球运营商的一项调研显示：63%的运营商希望直接进入MEC的应用服务这块巨大的蛋糕，70%的运营商希望提供PaaS。
从中国运营商发布的MEC白皮书可以看出，运营商希望通过管控住MEC，把握住流量的入口，尽可能从流量中提现价值。
以中国联通的边缘计算白皮书为例，书中就明确提出了除了区域DC会进行区域MANO和统一云管平台的部署，实现对整个通信云基础设施的管理。中国联通对传统的MANO管理域进行扩展，最终实现对边缘业务平台以及第三方APP的管理。MEP-O支持对第三方APP特性的描述直接进行处理，例如选择合适的边缘平台，对MEP-M进行特性配置等；MEP-M对第三方APP规则和需求管理（例如TrafficRules、DNSRules）和生命周期管理。
对于小OTT玩家而言，也许还能接受这个模式。但是现在有能力推动部署低时延业务（如VR/AR游戏，高精地图等）的公司都将是BAT级别的大公司。技术上，这些互联网公司可能完全无法接受自己的IT系统被一个新进入IT系统的电信公司管理，而且得和每一家运营商分别协调。商业上，OTT也不想被其他人控制住流量入口。互联网公司希望和移动互联网时代一样，经过TCP/IP协议的完美隔离，可以随意开发自己的业务，而无须和运营商进行任何协商，快速统一部署。电信运营商则希望通过MEC接入5GC的入口，从互联网公司收入中切下一块蛋糕。巨大商业利益造成OTT和运营商在技术构架上互不相让的局面，必然会减缓MEC的普及速度和商业价值的实现。
MEC的商业模式
根据MEC部署的不同位置和主导方，现在MEC的主要商业模式有以下：
一、厂区专业边缘计算
特点：MEC和UPF一起部署在厂区，医院等地区。小范围覆盖，配合5G无线能力，提供高带宽低时延能力，主要用于建设智能制造、智能医院等专网。
优点：受众单一，一个运营商覆盖一个厂区即可，独立部署，应用是工厂医院等自有，无须协调第三方。
缺点：工厂医院已有的应用需要二次开发迁移到MEC平台。
二、汇聚节点/城市/大区部署MEC+运营商云（Telco Could）
特点：运营商可以根据需要，在汇聚，城市或大区等部署不同级别MEC节点，提供不同等级的低时延。运营商自建云。
优点：运营商统一管理。
缺点：运营商和设备商希望控制OTT，寻求新收入来源是一个宏大的想法。这种商业模式需要OTT为每一个运营商平台都来适配，难以建立生态。伴随着Verizon Cloud,Vodafone Cloud的相续消失，这种商业模式逐渐消失。爱立信推广的Edge Gravity曾希望为OTT打造面对所有运营商的统一平台，打造MEC应用生态，最后也无果而终。看来IT和DT之间，仍有一道难以跨越的鸿沟。IT不懂DT的稳定，DT不明白IT的灵活。
三、汇聚节点/城市/大区部署MEC+OTT云接单一运营商
特点：运营商开放UPF和MEC之间N6接口。OTT可以根据需要，在某一运营商的汇聚机房，城市或大区等不同级别节点部署MEC，提供不同等级的低时延。
优点：OTT自己灵活部署，该模式在北美被认可。
缺点：运营商某种程度上仍然是“哑管道”，只是增加了根据MEC地理位置不同收流量费的能力，无法实现中国运营商构想的对OTT的完全把控。OTT需要在每个运营商节点都建立一套自己的MEC，重复投资。
四、汇聚节点/城市/大区部署MEC+OTT云接多运营商
特点：运营商开放UPF和MEC之间N6接口。OTT可以根据需要在汇聚机房、城市或大区等不同级别节点部署MEC，同时接入多个运营商，同时提供不同等级的低时延。
优点：OTT可以灵活部署，节省投资，北美OTT接受程度最高。
缺点：由于不同运营商汇聚机房地址位置分布可能完全不同，OTT的MEC难以实现在汇聚机房级别的协同，无法达到小于10ms的时延。OTT的云在三个运营商之间互联互通，运营商服务无差异化，几乎沦为机房出租商。在前文Analysys Mason的调研中，这也是运营商最不希望的商业模式（Real-Estate Provider）。
除了模式一现在有明确的发展模式，模式二、三和四都还处于胶着状态。
MEC在5G的未来
MEC现在在5G网络（R15）中仅仅实现了本地分流一个功能。无线网络能力开放，位置服务，和移动性管理等能力都还有待开发和完善。
如Gartner在2019年的边缘计算成熟度曲线中的所示，现在大众对边缘计算预期处于顶峰状态。但由于标准成熟不足，运营商和OTT对利益分配未达成一致，生态发展缓慢等原因，基于MEC的各种耀眼的业务（如AR/VR，自动驾驶，MEC+切片等）将难以在短期内商业化，戳破现在MEC的泡沫，大众对MEC的期望迅速下滑。作为ICT的融合典范，作为5G降低时延的重要网元，一方面，3GPP R16针对URLLC和V2X进行了加强，为全网实现低时延提供了基础；另一方面，MEC作为IT技术也会持续改进。CT和IT技术共同进步，胶着的商业模式一定会被打破，MEC会陆续支持一些高体验低时延的业务，如AR/VR游戏，大众对MEC的预期会稳步爬升和恢复。
MEC的能力何时可以达到2019年的顶峰预期呢？如果以自动驾驶为例，假设实现全网99.9%的10ms延迟（暂无任何机构给出数据），需要整个产业链从运营商、设备商、终端、操作系统、芯片、甚至铁塔公司一起协调。不知道届时，是不是MEC in 6G来挑起这个重任，甚至建立一个新的更高的预期？
本文作者：天生少数派
附件: 640?wx_fmt=png (2020-8-7 10:32, 56.07 KB) / 下载次数 2
https://www.txrjy.com/forum.php?mod=attachment&aid=NDUwMjQ0fDA5YjU0ODc2fDE3NTI3MjgzNjh8MHww
附件: 640?wx_fmt=png (2020-8-7 10:32, 158.1 KB) / 下载次数 1
https://www.txrjy.com/forum.php?mod=attachment&aid=NDUwMjQ1fGE4NmVlZTE5fDE3NTI3MjgzNjh8MHww
附件: 640?wx_fmt=png (2020-8-7 10:32, 14.67 KB) / 下载次数 0
https://www.txrjy.com/forum.php?mod=attachment&aid=NDUwMjQ2fDliZDk4NTg1fDE3NTI3MjgzNjh8MHww
附件: 640?wx_fmt=png (2020-8-7 10:32, 152.73 KB) / 下载次数 0
https://www.txrjy.com/forum.php?mod=attachment&aid=NDUwMjQ3fGFlODc2ZGMwfDE3NTI3MjgzNjh8MHww
附件: 640?wx_fmt=png (2020-8-7 10:32, 111.37 KB) / 下载次数 0
https://www.txrjy.com/forum.php?mod=attachment&aid=NDUwMjQ4fDNkNzI5MmUyfDE3NTI3MjgzNjh8MHww
附件: 640?wx_fmt=png (2020-8-7 10:32, 101.26 KB) / 下载次数 0
https://www.txrjy.com/forum.php?mod=attachment&aid=NDUwMjQ5fGJlMjFmN2ZifDE3NTI3MjgzNjh8MHww
附件: 640?wx_fmt=png (2020-8-7 10:32, 86.49 KB) / 下载次数 1
https://www.txrjy.com/forum.php?mod=attachment&aid=NDUwMjUwfDA0YjkyNGZkfDE3NTI3MjgzNjh8MHww
附件: 640?wx_fmt=png (2020-8-7 10:32, 142.17 KB) / 下载次数 0
https://www.txrjy.com/forum.php?mod=attachment&aid=NDUwMjUxfDI4Njk3ZDc4fDE3NTI3MjgzNjh8MHww
附件: 640?wx_fmt=png (2020-8-7 10:32, 154.77 KB) / 下载次数 0
https://www.txrjy.com/forum.php?mod=attachment&aid=NDUwMjUyfGNmMjNjNmQwfDE3NTI3MjgzNjh8MHww
时间: 2020-8-7 15:13
作者: qkb_75@163.com
总结得相当好啦！ 赞一个！
时间: 2020-8-7 17:41
作者: wuluguo
学习了
时间: 2020-8-7 22:25
作者: 聊胜于无
本帖最后由 聊胜于无 于 2020-8-7 22:35 编辑
我一年前跟踪R16标准的时候，在论坛帖子里就多次提到MEC了，今年也有幸实地参观了几次。
我个人的几个观点，欢迎讨论：
（1）MEC是有不同含义的：R16里的是“设备商”视角， 一些SaaS说的“边缘”概念是和“多云”相关的， 一些终端盒子厂商则更多把边缘下层到用户侧， 还不用说物联网中的概念更纷繁复杂。前三个概念业务逻辑上都说的通；商业上，无论是设备畅销、还是公司上市，都有成功案例；所以说MEC要结合语境，标准要读，但不能尽读（说句题外话，如果以后核心网设备都主要内循环了，那为什么要遵照“官僚的”3GPP标准，国内搞个GB、GB/T 不就可以了吗）
时间: 2020-8-7 22:33
作者: 聊胜于无
（2）我理解MEC的意义，不仅仅在于时延，更关键的是流量的运营权，按现在流行的话说，就是现在有了做网络侧“数据控制者”的机会。根据现在《数据安全法（草案）》，就获得一张数据“存储、加工、使用”的门票，这个遐想是无限的；同时无论是做等保、“双新”、DSMM评估，成本都是可控的。
时间: 2020-8-8 13:51
作者: superrap1981
MEC现在是不是名字更新成了MECG了
时间: 2020-8-8 14:51
作者: superrap1981
另外看了时延的图，发现到核心云数据中心，数据中心本身的计算处理时延是100-2000MS，即使是最低的100MS也已经基本是接入到承载网络时延的时延总和了，那么即便把MEC下沉到边缘DC，这个计算处理的时延怎么解决了？是因为边缘后，每个计算单元处理的内容少了，所以可以减少了？那么有没有研究过，这个计算的处理时延能低到什么程度？
时间: 2020-8-8 14:52
作者: superrap1981
另外看了时延的图，发现到核心云数据中心，数据中心本身的计算处理时延是100-2000MS，即使是最低的100MS也已经基本是接入到承载网络时延的时延总和了，那么即便把MEC下沉到边缘DC，这个计算处理的时延怎么解决了？是因为边缘后，每个计算单元处理的内容少了，所以可以减少了？那么有没有研究过，这个计算的处理时延能低到什么程度？
时间: 2020-8-8 17:04
作者: 没事来看看
superrap1981 发表于 2020-8-8 14:52 
另外看了时延的图，发现到核心云数据中心，数据中心本身的计算处理时延是100-2000MS，即使是最低的100MS也已 ...
所以需要 以5G为代表的CT技术，以计算为代表的IT技术，以及以TSN为代表的OT技术的相互融合。特别是TSN
时间: 2020-8-8 19:48
作者: wqfreebird
好文，mark
时间: 2020-8-9 20:39
作者: spirit1996
好文
时间: 2020-8-10 14:48
作者: beanwar
好文，mark
时间: 2020-8-10 16:41
作者: Joechau
MEC的平台由运营商提供吗？
时间: 2020-8-11 09:34
作者: 悠然见南山
聊胜于无 发表于 2020-8-7 22:33
（2）我理解MEC的意义，不仅仅在于时延，更关键的是流量的运营权，按现在流行的话说，就是现在有了做网络侧 ...
这个理解没问题啊，以后MEC可能会造就一批园区运营商、专业运营商
时间: 2020-8-11 10:31
作者: really
总结的很到位
时间: 2020-8-11 14:55
作者: ax420647300
Joechau 发表于 2020-8-10 16:41
MEC的平台由运营商提供吗？
运营商目前是这么想的 能不能做到 两说
时间: 2020-8-12 11:34
作者: 马云的云
说了这么半天，低延迟到底有没有需求？
如果有，是否可以直接基于终端本地来做？
对网络延迟的硬要求的应用，到底存不存在？
如果不存在，低延迟就是一句空话。
反倒是私域流量（此私域流量不同于彼私域流量）倒是MEC的一个唯一有价值的地方。
时间: 2020-8-18 15:32
作者: timberth
初期一定是野蛮粗暴的，MEC堪忧
时间: 2020-8-24 15:12
作者: jumpingbean
好文，mark
时间: 2020-9-11 10:38
作者: alun998
耐森雷特电子科技（上海）有限公司，专业的5GC核心网提供商，欢迎垂询！
时间: 2020-9-19 19:00
作者: ivanwxl
虽然有点悲观，但是也解开了我一直以来的MEC和5GC的关系问题~谢谢。
| 通信人家园 (https://www.txrjy.com/) |
Powered by C114 |
