| 编辑推荐: |
文章讲述5G与MEC，MEC业务场景，多接入/移动边缘计算（MEC），希望对您有所帮助
本文来自于百度，由火龙果软件Delores编辑推荐 |
|
美国的Big 5G Event在Denver举办,这是北美业界的一个最大的论坛/展会, 该来的都来了, 设备商则为赞助伙伴, 包括Cisco, Ericsson, Huawei, Qualcomm, Intel, 等一个都不少
与4G时代的类似专业论坛不一样, 以前主要是电信运营商及諷设备商参加,外加一些产业链上的小伙伴. 现在的5G时代, 除了他们以外,互联网的各路神仙也都积极参与,不管是每年的MWC, 还是其它的区域展会/论坛. LightReading的一则关于移动边缘计算MEC(Mobile Edge Computing)我觉得可以仔细研究一下.
仔细看看,问题也没啥! 在这个行业这类事情多了去了. 上面说, 关于边缘计算, 炒作太"厉害", 虽然大家都相信边缘计算在5G技术中的关键作用, 但在移动运营及数据中心领域内一些较高端的行家对这个"炒作"在短期甚至中期都表示严重关切.有人说, 在这个行业呆久了, 就发现有些新技术, 竟然炒作提前了5-10年, 如micro DC 就是一例.
在数据中心(DC)的业界大佬Equinix的VP Jim认为移动运营商在5G网络为了让边缘计算能够达至预期应该彻底改变其针对语音的网络的设计. 而加拿大运营商Telus的CTO则担心MEC的标准化进程会熄火(陷进去). 他从ORAN(Open RAN)的情况感觉到MEC会更加困难(标准化).
当然边缘计算的支持者, 也有意见. 他们认为现在的internet网的"集中"的特性不支持5G希望提供的"瞬时""突发"的实时业务, 如AU(自动驾驶), VR等. 这些业务需要与用户的连接立即可用,边缘计算的设计可以保证在地理位置上接近用户的DC可以为这类业务提供立即的连接(低延迟特性). 另外,也有人估计了一下, 从一个DC集中布署, 变成多个mico DC的设计,也就只降低了延迟1-2ms.
5G与EC/MEC本身不是一个直接相关的问题. 5G是否需要EC/MEC, 主要取决于业务形态.边缘计算(EC)是否一定要5G, 则完全可以说不一定!
在IMT-2020/2030的5G宏图中, MEC则成为了与network slicing一起的必备, 由此才带来了至少业界对此巨大的期望. 另外, 有人问我5.17世界电信日时, 为什么腾讯阿里也在渗和? 其实不是为了凑热闹,而是因为今年都在炒5G, EC/MEC是5G 终极开放融合网络的一个入口, 自然,也要来刷一下存在感 , 表达一下对行业的前瞻 性看法. 前面这个Big 5G Event不一样有OTT/互联网的玩家参加.
上面提到两个其实有些不太完全一致的概念:EC & MEC (边缘计算 & 移动边缘计算). 上面的新闻中提到的业界人士其实他们说的也是有差异的.
边缘计算（EC）
边缘计算(EC: Edge computing)是一种分散式运算的架构，将应用程序，数据与服务的运算，由网路中心节点(数据中心DC, 云中心等)，移往网路逻辑上的边缘节点来处理。边缘运算将原本完全由中心节点处理大型服务加以分解，切割成更小与更容易管理的部份，分散到边缘节点去处理。边缘节点更接近于用户终端装置，可以加快资料的处理与传送速度，减少延迟。在这种架构下，资料的分析与知识的产生，更接近于数据资料的来源，因此更适合处理大数据相关的业务/服务。通常在IT领域的边缘计算, 可以与通常的云计算相反,当作一个分布式的数据中心(mini/micro DC), 边缘云计算(edge-cloud), 或者其它类似的概念.
纯粹IT意义上的EC, 我不过多的详述. 传统意义上的IT厂商对有边缘计算需求的场景也在努力的推广之中, 取决于业务的属性, 通过建立DC - mini/micro DC二级甚至三级架构, 来满足业务的需要(如高速, 低延迟等). 这些方面的解决方案可以从第三方IT厂家获得大量的方案介绍.需要说明一下的是, 纯粹IT式的EC, 运营商依然只是一个接入管道的角色, 业务的运营等与运营商关系不大, 我想这不是运营商在5G时代想要的角色, 因此,重点介绍一下ETSI的MEC. 另外，EC与xG等都没有任何绝对的关联。
多接入/移动边缘计算（MEC）
ETSI的ISG(Industry Specification Group)在2014年结合EC与跨行业的应用,提出了MEC(Mobile EC)的概念. 2017年后, 再重新定位了一下为Multi-Access Edge Computing (MEC). 充分说明了, 不仅定位于移动接入, 还包括了其它现有的甚至未来的接入模式.
Multi-access Edge Computing (MEC) offersapplication developers and content providerscloud-computing capabilities and an IT service environment at the edge of the network. This environment is characterized byultra-low latencyandhigh bandwidthas well asreal-time accessto 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. (from ETSI)
从上面ETSI对MEC的定义定位可以看出, 其基本的目标就是网络开放. 通过在网络边缘向开发者或者第三方的内容服务商提供云计算的能力及IT服务的环境.MEC提供了一个新的生态及价值链系统. 网络运营商通过开放其网络(RAN等), 以便第三方能够向其移动客户,企业及垂直行业客户快速灵活地布署创新的应用及服务.
MEC是移动业务接入点(2/3/4/5G RAN, WiFi, ETH, xDSL, xPON, etc.)融合发展要求的一个结果. 通过开放运营商网络能力,向行业及个人客户提供专业及创新的服务。
一些MEC的常见用例:
video analytics 视频分析
location services 位置服务
Internet-of-Things (IoT) IoT业务
augmented reality 增强现实AR
optimized local content distribution and data caching优化的本地内容容分发及caching.
MEC允许应用获取本地的内容及实时的接入网络信息. 通过把不同的服务或者内容布署在网络边缘以更接近用户, 可以有效地防止网络拥塞, 更有效地为本地用户提供高质量的服务.
另外,从ETSI对MEC的定义, 可以非常明显地看见,cloud-computing capabilities云计算的能力是最重要的一点. 因此,作为运营商在MEC的规划上, 必须将5GC与MEC统一规划,就个人的经验来说, 甚至不应该将5GC与MEC割裂开来看. 这是与4G或者之前的网络非常不一样的特点.MEC不过就是一个在网络边缘接入点的NFV应用平台. 网络的任何业务的提供均与5GC-MEC相关, 这是cloud-native的网络, 基于NFV, SDN/SD-WAN, Container, Microservices, DevOps的天然特性, 是一个能力开放, 接入灵活的网络.
大家可以问一下度娘"中国移动边缘计算技术体系白皮书", 我本来是想了解一下世界第一大移动通信运营商对MEC的看法,结果, 非常令人失X, 这份白皮书我标注评论了一半, 就不忍心再看下去了, 然后发给其他朋友了, 其本上只是一个边缘计算EC的概念, 而且概念混乱, 目标不清楚.。
MEC对业务的影响可以参考下图说明:
. VNF(Virtual Network Function)由于缺少一致的标准, 对硬件网络的依存度较高(NFVI的多厂家异构特性), API也不支持灵活的扩展等, 甚至不支持多租户(multi-
tenancy). 而cloud-native的VNF则可以解决部分上面这些存在的问题, 特别是在self-management及扩展性方面,microservices (VNF)则在automation方面大为提升了API的灵活性, 自动安装/配置/扩展/监控/升级. 可见, 即便是MEC, 与我们谈到的cloud-native 5GC并没有差别, 仅仅是处于网络的位置而带来的对业务方面的差异.
ETSI MEC要达到预期的目标,还面临巨大的挑战. 如移动性管理,业务及网络安全性, 对业务流的LI(合法监听)较困难,计费, 业务布署的灵活性等. ETSI MEC的参考网络架构如下:
从ETSI MEC的参考架构可以看出,MEC 与NFV是非常相似的. 因此,再次理解边缘计算不过是一个在网络边缘(SAP点, 如RAN等)完成计算工作的业务接入平台或者一个分布式的cloud.
MEC与NFV结合, 主要特点:
低延迟,扩展能力: NFV可以使网络资源/功能(VNF)按需布署,与MEC的低延迟结合,则可提供动态,快速和可靠的计算能力及服务. 一些具有本地存储要求的业务,则可以将数据存储在边缘DC,分流了到云/DC中心的数据.
网络切片:
上一贴
说了不少, 5G的颠覆性在于网络切片的商业模式,以及一张网络提供了针对不同场景业务(eMBB, mMTC, uRLCC)的统一服务. 没有NFV功能的MEC, 则是前面1中介绍的第三方miniDC, 运营商仅为提供一个管道连接. 对于需要边缘计算,存储或者网络带宽的业务, 按需分配MEC资源, 与NFV一起形成特定需求的切片网络, 提供服务.
多层架构: 取决于网络及业务的情况, 参见下图.
MEC的规划是一个复杂的问题, 更多的要取决于业务场景,上面仅为对MEC的一些基本要求.同时,必须结合5G核心网络一起统一考虑及规划.下图虽然啰嗦,也基本说到了重点. 如果读者本身对cloud-native有深度的理解,那么,下面的说法也就没有太多额外的内涵了. 业务的场景,可以从ETSI的网站上参考一些use cases.
MEC有巨大的市场需求驱动, 借用ETSI的图示:
再次重复一句, 5G需要MEC, 而MEC并非离开5G就不存在了. 未来5G的生态链及商业模式是否如运营商热情所期望般发展, 根本取决于运营商本身. 不管是cloud-native 5GC, 还是MEC, 标准化均面临极大的挑战. 甚至, 完全达至目标后, 运营商本身的网络运营能力也会面临极大的挑战.一个DevOps的全流程业务特性,究竟是运营商的角色,还是设备商的角色, 而如果是后者, 那么,快速,敏捷,灵活...etc又将成为一句设备商忽悠运营商的口号. 可见,传统运营商要转型比唐僧去西天取经还难, 主要是孙悟空太少.
下图简单的描述了在网络各个节点会涉及到的一些需要考虑的问题:
一些简单的业务场景描述, 包括网络功能,服务及use cases:
MEC业务场景
通过一些会涉及MEC的应用场景,进一步了解MEC的特性. 更多的应该参考ETSI及第三方的use cases .
. 
从上面的业务场景中的MEC来看, 对于MEC的规划,需要考虑的是业务形态. 而5GC与MEC的最基本的cloud-native的要求是一致的. 在具体的业务方面, 也是需要两者的配合. 很难想像将两者分割的规划会是什么样的(可参考中移动MEC白皮书). 下图是CISCO的一个NFVI/MEC的布署场景图:
. 
而Open API的示例如下:
. 
5G与MEC
5G有许多高带宽,低延迟,高数据传输要求的应用, MEC可以很好的匹配这些业务的要求, 从而减轻对核心网络的压力, 也更能够增强用户的业务体验. 然而, 不管是5G还是MEC, 都有过度炒作的风气, 运营商与设备商以及第三方, 都鸡血满满, 然而, 各方的背景及期望完全不同. 在过度炒作之中,往往会失去方向及判断, 从而总有一方会做出错误的决策. 5G终极的商业模式及未来的intelligent connectivity社会, 仅是一个比较远的目标, 炒作并不会把未来提前, 路还得一步一步走.
|
