Edgem Native技术架构白皮书-5G确定性网络产业联网.pdf

Edge Native 技术架构白皮书1.02021 年2 月5G确定性网络产业联网贡献单位（排名不分先后）：中国信息通信研究院中国移动通信集团公司研究院中国联合网络通信有限公司研究院中国电信股份有限公司研究院华为技术有限公司西安电子科技大学大陆智源科技（北京）有限公司云迅智能科技南京有限公司讯琥（上海）物联网科技有限公司青岛海尔工业智能研究院树根互联技术有限公司浙江九州云信息科技有限公司网络通信与安全紫金山实验室国网山东省电力公司青岛供电公司序 言.1前 言.2第 1 章 边缘计算发展现状及 5G 行业市场对边缘的需求.31.1 边缘计算 2.0 及 5G MEC.31.2 5G MEC 产业现状及价值呈现.51.3 5G MEC 存在部分挑战.9第 2 章 Edge Native 产业理念及主要能力.102.1 Edge Native 概念和产业价值.102.2 Edge Native 平台架构能力.12第 3 章 Edge Native 产业实践.173.1 EdgeGallery：Edge Native 的开源实践.173.2 基于 Edge Native 的中国移动 OpenSigma 平台实践.203.3 基于 Edge Native 的中国联通 MEC 平台实践.22第 4 章 行业探索和未来展望.23CONTENTS目录序言1当前全球数字化浪潮蓬勃兴起，边缘计算通过就近提供计算、存储、传输等关键能力，加速赋能经济转型升级，已逐步成为计算体系的新方向、信息领域的新业态、产业转型的新平台，整体上处于高速增长阶段，受到了学术界和产业界的广泛关注。Gartner、IEEE 等权威机构将边缘计算作为 2020 年十大技术方向，中国科学院和中国工程院在2020 研究前沿、全球工程前沿 2020中，将边缘计算列入信息领域十大技术前沿。据 CB Insights 预测，2023 年全球边缘计算市场有望达到 340 亿美元。经过近年来的不断探索与培育，边缘计算正从概念普及加速走向务实部署。一方面通过工业互联网行动计划等工作的持续推动，边缘计算不断与行业需求相结合，创新应用实践不断涌现，场景覆盖日益广泛，形成了众多典型应用模式。例如，三一重工、格力、海尔、商飞等一批工业企业已开始利用边缘计算模式改变传统的制造方式。另一方面，边缘计算原生性技术不断涌现，Edge Native（边缘原生）技术概念加速孕育，极大拓展边缘计算创新空间。Edge Native 是一个全新的概念，其通过边缘智能、边缘协同、边缘可信、算网融合等核心技术，满足各类应用敏捷联接、实时可靠、数据优化、应用智能等方面的关键需求。Edge Native 技术将与云原生技术、边缘网络技术协同化演进，不断夯实边缘计算技术体系。针对 Edge Native 这一新兴技术方向，工业互联网产业联盟、边缘计算产业联盟、5G 确定性网络产业联盟、EdgeGallery 开源社区联合组织编写了Edge Native 技术架构白皮书，旨在总结 Edge Native概念的内涵与外延、技术体系、产业实践，揭示 Edge Native 技术对产业数字化转型和新型基础设施建设的重要作用及赋能路径，为产业界推动 Edge Native 发展提供必要的参考。Edge Native 的概念成熟与技术发展需要产业各方的共同参与，我们欢迎业界伙伴一起推进边缘计算原生技术的发展，实现边缘计算+行业的价值最大化，为制造强国和网络强国建设作出新的更大贡献！中国信息通信研究院院长、工业互联网产业联盟理事长、边缘计算产业联盟副理事长余晓晖余晓晖自从 ETSI 2015 年提出 MEC（Multi-access Edge Computing）概念后，边缘计算能力在电信领域的应用已经得到了长足的发展。但随着 2020 年 5G 行业应用的快速发展，当前的边缘计算能力在实际应用中体现出部分不足，无法完全满足各类行业场景的实际诉求。一个关键因素在于 MEC 平台无法完全独立于运营商 5G 网络之外，网络能力与计算能力两者必须相互协同以进一步提升方案效率。在这样的背景下，本白皮书提出面向未来网络演进的 Edge Native 理念以支持运营商与行业面向未来的行业数字化转型。本白皮书分为四个章节：第一章 边缘计算发展现状及 5G 行业市场边缘需求：边缘计算进入 2.0，但在 5G MEC 部署过程中仍然存在若干痛点。因此需要新的 Edge Native 理念；第二章 Edge Native 产业理念及主要技术能力：Edge Native 提供联接+计算的高效协同，是运营商网络以行业市场为主的中期目标架构。其中包含边缘编排、边缘智能、边缘安全等多种增强技术能力；第三章 Edge Native 产业实践：当前主要有 EdgeGallery 开源社区、中国移动 OpenSigma 平台及中国联通 MEC 平台等主要实践；第四章 行业探索和未来展望：介绍边缘计算在智能工厂、机器人应用方面的行业实践，以及 Edge Native 未来展望和下一步计划。前 言2前言Edge Native技术架构白皮书1.0301边缘计算发展现状及5G行业市场对边缘的需求Edge Native产生的背景和需求边缘计算 2.0 及 5G MEC1.1边缘计算产业联盟（ECC）2017 年发布的边缘计算参考架构 1.0 给出了边缘计算 1.0 定义。随着边缘计算产业的发展逐步从产业共识走向落地实践，边缘计算的主要落地形态、技术能力发展方向、软硬件平台的关键能力等问题逐渐成为产业界的关注焦点，边缘计算 2.0 应运而生。边缘计算 2.0主要包括云边缘、边缘云和边缘网关三类落地形态；以“边云协同”和“边缘智能”为核心能力发展方向；软件平台需要考虑导入云理念、云架构、云技术，提供端到端实时、协同式智能、可信赖、可动态重置等能力；硬件平台需要考虑异构计算能力，如X86、ARM、GPU、NPU 等。图 1-1 边缘计算 2.0 架构边缘计算是在靠近物或数据源头的网络边缘侧，融合网络、计算、存储、应用核心能力的开放平台，就近提供边缘智能服务，满足行业数字化在敏捷联接、实时业务、数据优化、应用智能、安全与隐私保护等方面的关键需求。终端边缘计算云计算边云协同/边缘智能边云协同/边缘智能手机制造矿山钢铁电力医疗媒体边缘网关AI云边缘AI边缘云/MECAI边云协同/边缘智能网络IoT行业应用应用应用网络IoT行业平台平台平台IaaS4Edge Native技术架构白皮书1.0Edge Native产生的背景和需求与 云 边 缘 相 比，边 缘 云/MEC（以 下 统 一 简称MEC）同时具有电信联接和IT计算融合的特征。ETSI 与 3GPP 均在架构中分别定义了 MEC 架构以及MEC 在 5G网络架构中的地位及功能。因此在上述三个边缘层次中，MEC 是当前运营商 5G 网络中最为广泛部署的边缘节点 设备。在架构上，5G MEC 包括了 5G 网关 UPF、边缘应用平台 MEP、行业应用 APP，以及虚拟化基础设施。在部署形态上，5G MEC 作为一体式设备部署在靠近终端用户侧的边缘位置，提供大带宽、低时延的网络联接能力，AI、图像渲染等计算能力，以及面向行业的安全能力。基于 MEC，5G 行业场景可以最终降低终端的成本和管理复杂度，提升用户的体验。云边缘是中心云服务在边缘侧的延伸，逻辑上仍是中心云服务的一部分，主要的能力提供及核心业务逻辑的处理依赖于中心云服务或需要与中心云服务紧密协同。如华为云提供的IEF 解决方案、阿里云提供的 Link Edge 解决方案、AWS 提供的 Outposts 解决方案等均属于此类。边缘云是在边缘侧构建中小规模云服务或类云服务能力，主要的能力提供及核心业务逻辑的处理主要依赖于边缘侧自处理。如多接入边缘计算（MEC）、CDN。边缘网关以云化技术与能力重构原有嵌入式网关系统，并在边缘侧提供协议/接口转换、边缘计算等能力，部署在云侧的控制器提供边缘节点的资源调度、应用管理与业务编排等能力。云边缘边缘云/MEC边缘网关5Edge Native技术架构白皮书1.0Edge Native产生的背景和需求5G MEC产业现状及价值呈现1.2据不完全统计，全球在 2020 年开展了超过 5000 个行业试点项目，其中约 60%均涉及 MEC 部署。以中国三大运营商为例，已在 40 多个城市开展了 100 多个基于边缘计算的 5G 商业应用试点项目，覆盖了多个行业和应用场景，包括智慧工厂、矿山、能源等。2020 年中国工业和信息化部的“绽放杯”5G 应用大赛中，5G MEC 的使用率达到 43%，相比去年增长 10 个百分点，在参加总决赛的 30 个项目中，MEC 的使用率超过 80%，5G MEC 已成为 5G 应用关键使能技术。图 1-2 2020 绽放杯总决赛 MEC 项目泛媒体22223工业制造能源医疗交通矿山2020 绽放杯总决赛包含 MEC 项目占比超过 80%136Edge Native技术架构白皮书1.0Edge Native产生的背景和需求M E C5G核心网代理5G传输射频单元基带处理单元基带处理单元射频单元5G传输5G传输环网矿山业务服务器（M EC备份可选）煤矿运营商5G核心网5G网络智慧工厂以工业制造为代表的智慧工厂场景中设备种类多、数量大，数据类型复杂且多样化，因此对数据的传输在安全性、传输速度和时效性方面有很高的需求。2020 年工业制造行业的 5G 试点中，多以生产辅助系统，尤其AGV（Automated Guided Vehicle 自动导引车）为主。例如，三一重工与中国电信在 5G 创新试点项目中合作，在厂区部署 MEC，并以移动工作平台和 AGV 取代传统履带式传送，大幅提升了工作效率。其中，5G MEC 平台集成了 AGV 大流量视觉数据采集分析、路径调整、调度管理等软件功能，在提升 AGV 效率、降低 AGV 成本的同时，对数据的实时性（20ms）、安全性和计算能力复杂度都提供了有效保障。图 1-3 智慧矿山组网方案智慧矿山矿山（如，煤矿）为了实现安全生产，需要大量视频数据的采集、传输，以及海量传感器的应用。5G网络充分考虑矿山场景应用的这些特点，提供大带宽、海量联接、低时延传输的特征以满足井下少人或无人矿井的 设备远程控制要求。同时，煤矿本地部署 MEC 实现业务分流至矿山自有业务服务器，即能够准确、全面、清晰地获取井下各种安全生产数据和环境视频，实现井上井下高清音视频通话、各种数据快速传输、设备远程智能控制等应用，又能够保障数据不出煤矿园区。为矿井减人提效、安全生产，以及煤矿智能化建设奠定了有力的数字基础。由于矿山对安全要求尤为严格，因此 MEC 还应支持与5G核心网应急系统的共部署模式。在极端故障场景下，5G 核心网应急系统可作为备份设备继续提供业务，保证无线通信及数据传输的可靠、稳定，满足井上井下安全隔离的相关规定。7Edge Native技术架构白皮书1.0Edge Native产生的背景和需求智慧交通交通行业日常产生大量图像或视频数据，包括道路监控、道路养护维修巡检等。当前这些视频、图像回传速度慢，人工作业方式效率较低。另一方面交通行业数字化过程中需要引入智能化手段改善原有工作模式，包括基于高清图像的智能动态异常分析、对相关生产易故 障环节进行监控等。因此，在智慧交通场景中需要 MEC 作为视频分析与视觉识别等技术的 AI 智能分析平台，将 5G 高清视频设备所采集的现场数据，包括多路高清视频实时回传等，进行实时监测、快速判断，紧急报警；对生产环节关键 状态、性能与损耗在线智能检测、即时诊断。智慧能源传统电力行业在输电、变电环节采用的主要通信方式为光纤通信，追求低时延、大带宽以及光纤传输的介质安全性。而配电网和用电侧因为覆盖面积广，终端数量高，普遍采用了 2G/3G/4G 公网通信作为辅助通信手段。但公网通信的安全性相对较低，作为对信息安全有着绝对要求的电力行业，无法依靠这种方式传输带有控制指令的业务。5G MEC 结合 UPF 下沉使电力行业的数据流不经过外网，直接分流到电力行业内部的应用系统。从而在一定程度上提升数据安全性，促进控制类业务向5G通信方式拓展。其次，全景式的智能变电站本地可能产生海量基础数据，包括各类测量值、影音图像等。此类数据直接上送至电力行业主站需要占用大量的电力通信带宽。因此 需要同时具备强联接与强计算的 MEC 设备，一方面将基础数据在变电站园区内进行初步计算，另一方面将计算分析所得数据结果及时上送电网主站。这样既能满足原始数据不出园区的安全性需求，又节省了电力通信的城 域带宽资源。8Edge Native技术架构白皮书1.0Edge Native产生的背景和需求智慧医疗时间就是生命，快速、安全是现代化医疗的核心诉求。在要求快速方面，医护流动性大，需要随时随地接入办公；医院的影像类数据占医疗数据的 60%以上，需要快速处理。在安全方面，信息安全需要符合医院等保要求，做到对数据防篡改、防泄漏；医疗对网络可靠性存在诉求，需要保证医疗数据传输的稳定可靠。5G 医疗虚拟专网融合了 MEC 和切片技术能力，可以为医疗业务提供业务本地分流、安全隔离和可保障的SLA 功能。其中专享的 MEC 可以实现数据就近转发，数据不出医院，保障业务交互低时延，另外远程会诊平台部署在 MEC 平台，提供秒级时延。智慧场馆目前，体育赛事等大型活动的转播制作主要依靠在现场部署转播车完成转播任务。随着制作技术的不断进步，转播制作内容开始向多元化方向发展，超高清、VR、多声道等技术的应用对制作设备、人员及制作环境均提出更高的要求，中心化、远程化、轻量化的转播制作成为可行的发展方向。以此为基础，5G MEC 在赛事转播制作方面的应用需求主要有三点：现场制作轻量化和敏捷部署：对于制作标准相对简化的低级别赛事，转播车等大型制作设备周转及部署成本较高，通过 5G MEC 将多机位信号同步低时延传输至远程制作中心进行制作分发可以有效提升制作质量，降低制作成本，并提高转播团队对不同级别赛事的响应速度，扩大赛事转播方对全体育赛事转播业务的服务能力；制作能力前移至边缘：对于部分对时效性要求较高且可实现自动化制作的工作环节，如实时赛事数据分析、实时赛事回放剪辑、多视频格式转码等，可以将制作能力部署于 MEC，用于转播内容的快速生成，提高内容时效性，压缩制作流程，降低制作成本，提升制作质量和内容丰富度。并可在后续将中心化制作流程部署于边缘云端，进一步提升制作资源的轻量化程度。9Edge Native技术架构白皮书1.0Edge Native产生的背景和需求5G MEC存在部分挑战1.3结合上述行业实践，我们可以看出当前 5G MEC 技术上仍然存在一些不足。这些不足主要体现在网络部署及设备能力、软件开发两个方面。在网络部署及设备能力上：MEC 可较好满足单一场景需要，但各场景对 MEC的部署位置、形态等差异较大，因此需要 MEC 可以支持更丰富的异构设备及组网形态；MEC 平台及其承载的应用需要更强的数据分析能力，尤其是基于 AI 的高效智能化数据分析，因此需要MEC 在软硬件上都要提升 AI 能力；行业应用对于网络传输、可靠性要求普遍较高，因此MEC 需要与行业应用、运营商网络进行高效协同；系统隔离、数据安全能力仍有待进一步提高。在边缘应用软件开发方面，开发者面对 5G MEC 的场景以及多样的 MEC 平台形态，需要考虑最大化的使用到 5G MEC 的开放能力。一个典型的 MEC 应用开发者流程如下：选择服务框架：根据应用开发者的语言技能，结合应用的最终运行场景进行应用开发态包含如应用框架、三方件、数据库等的选择。即在同一个 MEC 平台上，多微服务框架之间可以进行互相的注册发现、通信以及相关的服务治理 定义Rest API：简而言之，是应用开发者需要确定自身应用对外的交互接口，对外能提供什么能力 使用 5G 网络能力：充分使用 5G 网络的低时延，大带宽等能力，并且是代码级的使用。即 5G 网络能力能够进行抽象，为开发者提供如 SDK/Rest API 等方便编程的能力；或者能够抽象为应用模板，使得开发者能够直接使用 Orchestrator 进行编排管理，而不需要关心里面具体的实现细节适配多种平台：这里的平台需要区分为两 层，即 IaaS 和 PaaS 层，即既需要应用能够适配X86/ARM等平台，同时也需要能够使用Openstack/Kubernetes 等 IaaS 平台，同时 MEP平台也能够提供如基础数据库、安全、人工智能、区块链等边缘 解决方案能力DevSecOps/Orchestration：即 应 用 需 要 端 到 端 的DevSecOps 工具链支撑，同时也需要能够端到端的能力编排，如应用在部署时的依赖应用、三方能力等最后在应用开发完成后，需要通过一系列的应用认证测试，最终可以发布到应用商店/仓库。因此，无论是运营商、行业厂商还是开发者均需要一个新的架构能力以弥补现有 MEC 的不足，并提升行业的最终用户满意度。图 1-4 基于 MEC平台的开发者流程图应用发布ME C 应用开发使用5G网络能力适配多种平台定义Rest API选择服务框架C I C DDevOpsEdge Native技术架构白皮书1.01002Edge Native 产业理念及主要能力Edge Native 概念和产业价值2.1通过上述分析，为了更好地满足未来 5G 行业市场的发展，5G 确定性网络产业联盟（5GDNA）、EdgeGallery开源社区、边缘计算产业联盟（ECC）和工业互联网联盟（AII）共同提出 Edge Native（边缘原生）的产业理念。首先，Edge Native 与 Cloud Native（云原生）类似，都是一种长期文化与理念。因此其包含的范畴可能随着产业的发展而发生变化。就如同 Cloud Native 诞生之初更关心软件开发的 12 因子原则，而随后 2018 年 CNCF 将Cloud Native 定义为一种范式，让应用更加适应并使用云的特性，如弹性、分布式，而不需要关心底层的技术实现，从而实现快速部署、按需伸缩、不停机交付的特性。其次，Edge Native 与 Cloud Native 是一体两面，体现了 ICT 产业的重心不断向边缘转移。在这一转移过程中，Cloud Native 的技术面临了一些挑战，包括：端到云中心 RTT 时间较长所有的计算、存储、网络消耗以及管理需要在中心终结传输成本与计算成本相对较高隐私与数据安全的挑战而 Edge Native 则体现出了部分截然不同的特征和价值：Edge Native联接+计算并重轻量化边缘节点多样化硬件异构有限或不支持扩缩容应用需要有清晰的依赖图谱远程管理，边缘自治，跨节点编排面向接入的组网方式重视 5G 移动接入Cloud Native以计算为中心中心大型数据中心通用硬件资源灵活扩缩容应用独立部署集中自动化管理，水平编排面向互联网的组网方式重视骨干传输互联Edge Native产业理念及主要能力11Edge Native技术架构白皮书1.0Edge Native产业理念及主要能力对于开发者而言，由于 Edge Native 融合了更多的电信联接概念，导致熟悉 IT 的开发者较难理解边缘环境的一些架构、参数、特征等。所以边缘平台需要面向开 发者将网络属性，包括 3GPP 等定义的具体参数进行友 好的抽象表达。另外，对于5G网络行业数字化转型而言，EdgeNative 也是网络的目标架构。基于 Edge Native可在边缘云环境下深度利用边缘计算特有价值特性，高效构建、运行和维护管理时延敏感的边缘应用。Edge Native 的代表技术包括：以边缘侧 5G 网络能力开放为特征的边缘服务、基于云边协同和边边协同的边缘网格技术、面向复杂场景跨网络的边缘编排技术、支持多语言/serverless 和边缘自治的边缘框架技术、大量异构初始数据的低时延/实时预处理分析的边缘数据技术、基于认证加密和区块链的边缘可信技术、基于异构边缘智能硬件和硬件加速的边缘 AI 技术。图 2-1 Edge Native 技术架构图EdgeInfra:支持异构加速硬件EdgeOrchestratorEdgeDevSecOps一站式敏捷安全开发体验EdgeFramework开放能力编排框架X86轻量化分布式高性能EdgeData区块链加持认证加密安全可信EdgeSecurity网络自动化容灾 调度EdgeMesh5 G 能力开放便捷EdgeNetwork云边网端协同EdgeCollaboration统一模型智能调用EdgeAI跨多云、多语言平台编排，简化电信网络配置与操作，Mobility，标准协同12Edge Native技术架构白皮书1.0Edge Native产业理念及主要能力Edge Native 平台架构能力2.22.2.1 边缘基础设施 EdgeInfra边缘基础设施是 Edge Native 的底层基础，包括硬件与平台技术。硬件上，边缘基础设施不仅需要考虑增强计算能力，也需要考虑如何更好的支持 5G 网络所需要的大流量转发能力。因此需要支持异构硬件如 CPU（ARM 或 X86）、GPU、NP 等。平台技术上，目前越来越多的应用逐渐容器化/虚拟化。底层基础设施平台逐渐收敛至 Kubernetes 相关产品。但是 Kuberenetes 对于 MEC 应用的容器安全性、隔离性等有一些限制，需要对基础设施提出更高的诉求：增 强 的 电 信 网 络 支 持：电 信 MEC 场 景 需要 Kubernetes 增强应用及平台的多网络平面隔离，多 租户增强，以及电信网络能力增强（如 TSN等）。EdgeInfra 可以引入 Multus 等 CNI 组件，或对现有 CNI 进行增强，通过 Kubernetes 标准接口或者部署 文件对于电信网络特性进行抽象以及配置，方便应 用调用；容器与虚机的混合编排能力：电信网络功能及边缘应用厂商的容器化甚至虚拟化进展较慢，需要支持容器与虚机的混合编排。目前优选将虚拟机打包成以容器镜像的格式进行编排管理，同时 Openstack社区也有 Starlingx 方案。2.2.2 边缘网络 EdgeNetwork边缘计算平台作为联接 5G 网络与应用、最终用户的桥梁，需要在保障自身网络联接能力的基础上进一步加强与应用的协同，提供完善的 5G 网络开放能力：5G 网络能力开放：ETSI MEC 定义了一系列网络开放能力，如位置信息等；同时 3GPP 与电信运营商也定义了基于 3GPP NEF 的网络开放架构。MEC 需要能够基于 ETSI 或 3GPP 架构便捷地上线新的 5G网络能力，并为用户提供便捷的调用方式。最终为开发者提供5G网络开放能力的SDK、开放样例代码，从而最大程度上使得应用能够发挥 5G 的优势；算网一体的边缘计算平台：MEC 对下承载 5G 网络能力的打通，对上提供应用必须的计算与网络资源。MEC 平台需要对 5G 网络基础连接能力、计算能力、行业所需的确定性网络能力进行高效编排。为了描述应用对网络的诉求，可以将应用描述模板分为两层，一层纯计算资源的描述，使用底层自身描述文件，如 Kubernetes的 Helm，Openstack 的 heat模板等；另一层对电信网络资源的依赖，需要 Edge Network 技术将电信网络进行抽象，提供网络模板，以供上层编排调度13Edge Native技术架构白皮书1.0Edge Native产业理念及主要能力2.2.3 边缘编排器 EdgeOrchestrator由于边缘节点具有容量较小，部署环境复杂等特征，需要在整体边缘领域提供较强的边缘编排能力，以满足以行业为代表的业务 SLA：边缘自治：边缘节点面临的弱网络等情况可能导致其与中心节点断联，出现如数据不同步，应用难以恢复等问题。EdgeOrchestrator 需要支持断网场景下边缘节点的相对自治，以及网络环境恢复后，中心测与边缘侧信息的重新同步移动性：EdgeOrchestrator需要保证移动用户跨运营商接入的一致体验，支持运营商之间的信息共享，提供应用在不同运营商平台之间平滑的迁移等功能。声明式的资源抽象：用于描述最终的资源（配置）形态，不需要最终的应用部署/运维人员通过命令式命令（Imperative commands）来告诉具体的操作。例如对于应用部署时依赖的平台能力，三方组件，网络信息都可以通过 APP 模板中的依赖关系来描述。同时资源抽象也可以解决 IT 与 CT 之间名词的不统 一，在 APPD 中可以将这些电信参数抽象成 IT开发 人员更加容易理解的名词，便于开发者更加高效的 使用电信网络能力。插件式的多云支持：EdgeOrchestrator需要针对不同场景适配典型的基础设施层（如各种云平台/裸金属），如集群场景下可以支持 Kubernetes、Openstack，单机场景下支持 K3S、MicroKubernetes，裸金属场景下可能需要支持如 RunC。2.2.4 边缘协同 EdgeCollaborationMEC 边缘节点，即需要与运营商网络增强协同，也需要支撑最终应用客户端的协同，同时也需要考虑在多个 MEC 节点之间的协同，如算力的共享，网络的编排等等：边边协同：结合EdgeOrchestrator 可以对整网的MEC 节点进行统一的协同编排。若当前边缘节点的计算能力不足以支撑当前任务，可以将计算任务进行切分，最终在某一个边缘节点进行整合，从而达到整网的最优使用。又如最终用户在跨边缘节点漫游时，通过边边协同可以快速的将应用的镜像同步到新节点进行部署，从而达到快速提供服务的目的。边云协同：由于云端/中心端通常具备海量计算能力，并且能提供给应用一系列的开放能力，通过边云协同可以使 MEC 上的应用充分使用云端的能力。在中心、边缘侧提供边缘协同的组件也可以将公有云的开放能力通过 API 网关提供给最终应用，使得应用在云上与 MEC 上有一致的体验。边端协同：由于VR/AR/视频为代表的终端应用对时延有严格的要求，同时也对图像渲染等能力有一定要求，因此需要从架构/技术上保证 MEC 节点到端侧的高效通信，提供边端的高效数传协议，并通过 MEC 提供图像处理、渲染等能力。14Edge Native技术架构白皮书1.0Edge Native产业理念及主要能力2.2.5 边缘智能 EdgeAI边缘计算与人工智能结合的课题，目前在学术界与工业界都有比较深度的分析与研究。无论基于边缘计算节点进行就近训练，还是将中心节点训练好的模型下载到边缘进行推理，都有比较多的场景。结合目前高校与业界的深度讨论与探索，目前诉求如下：统一的边缘智能框架与模型：结合边缘、终端、中心协同，提供模型分割、数据分割、分布式学习、增量/迁移学习的引擎，以及对应的算法与协议接口。例如当前业界比较流行的统一 AI 模型格式 ONNX（Open Neural Network Exchange）可以在边缘与中心、端侧协同的场景下，进行对最终开发者更加通用的抽象；又如通过业界比较流行的 KubeFlow支持多框架模型服务，进行最终 AI 共有的编排；AI 异构算力的统一调度能力：边缘计算平台可以提供 HAL（Hardware Abrastraction Layer）层为最终应用提供异构硬件的资源抽象，提供屏蔽异构差异的统一硬件资源，并由 MEC 智能调度合适的硬件资源运行不同类型的服务为应用提供最佳的运行效率。同时可以根据业务/资源等指标进行 AI 算力的卸载，实现如边边协同，边端协同的场景；2.2.6 边缘安全 EdgeSecurity边缘平台的安全要求毋庸置疑，结合行业对于安全 的诉求，EdgeSecurity 需求包括如下：提供边缘平台端到端安全机制：边缘平台需要提供基础设施安全可信、网络安全可信（如网络隔离，网络监测与防护预警）、数据安全可信、应用安全可信等能力。如为防止 MEP 与 APP 等之间的通信数据被拦截、篡改，MEP 与 APP 等之间的数据传输应启用机密性、完整性、防重放保护等等功能。此功能需要结合 MEC 平台框架提供如 MEP 与 APP 之间接口的认证授权，传输保护，并提供对接入到边缘计算节点的终端用户进行日志记录，可用作如事后审计等功能。需要从认证、通信协议、防攻击、接入安全、隔离性、隐私数据保护、虚拟化安全加 固等多方面进行考虑。透明的隐私可验证平台：通过区块链技术结合密码学算法，提供如密码承诺机制，零知识证明，可验证加密、通信内容与可验证加密内容一致性验证等 功能。不可篡改的数据保存联盟链：通过抽象应用镜像摘要如 Hash 等 Meta 信息，并对此 Meta 信息加密后保存到区块中，将每个边缘节点作为私有区块数据存储点进行管理，同时接入统一的公有链进行协同，保障了应用的端到端数据安全15Edge Native技术架构白皮书1.0Edge Native产业理念及主要能力2.2.7 边缘网格 EdgeMesh由于单个 MEC 节点资源有限，需要整体 MEC 解决方案进行全网调度。同时单个 MEC 节点可能运行多厂商应用，因此也需要针对应用提供更加细粒度的管理。结合 Service Mesh 相关技术，需要为应用提供更高效优化的功能：灵活的算力调度及整网优化：通过EdgeMesh 的Sidecar，可以利用非侵入式修改获取应用以及当前 MEC 节点的算力、资源占用率等信息，为上层EdgeMesh 控制器或编排器提供必要的信息，进行调度策略配置以实现整网的资源优化；细粒度的应用优化：结合 UPF 相关能力，使应用无需 感知整 网环 境，直 接通 过 EdgeMesh 的Sidecar 调用，使应用达到最优调配，并可以基于用户和业务的不同，选择不同的网络平面进行数据通信。高效的边端协议支撑：通过 EdgeMesh sidecar 承载边缘协议，使得边缘与端侧可以进行高效通信。2.2.8 边缘存储 EdgeData目前包括 IEEE 等研究组织都在对边缘计算上的存储进行多方面研究。此外边缘计算的分布式特点也对其存储系统提出了相应的诉求：分布式存储：其数据一致性需要 EdgeData 系统自行保持一致，支持去中心化存储系统之间的互联互通，包含冗余，容灾，边边数据协同等场景。异构化存储：边缘设备针对场景可采用不同存储软件或存储介质，EdgeData 需要解决不同存储软件或者存储数据的抽象问题。轻量化存储：例如针对 IoT 场景海量设备的监控数据和业务消息，可以提供轻量化的 TSDB 方案(如TDEngine 等)。边缘计算存储感知能力：对于部分应用的核心算法以及核心数据，平台需要能够感知数据隐私性，为应用提供加密存储。同时也可以根据自身平台的存储能力，结合EdgeAI能力，决定是否在本地进行分流或转存其他边缘。16Edge Native技术架构白皮书1.0Edge Native产业理念及主要能力2.2.9 边缘框架 EdgeFramework边缘框架主要的目标是为应用最终提供能够运行的基础框架，同时也能支撑边缘节点拥有者对应用进行相关计费、审计等策略的制定，提供安全、标准的对外行为：通用的 API 框架：可参考 3GPP 标准定义的 CAPIF（Common API Framework）。其主要功能与 ETSIMP1 接口兼容但有更大的扩充，包含跨域 API 安全调用、多 CAPIF 框架之间的标准调用流程、分布式部署、端到端API认证鉴权策略等功能。同时API 框架也需要支持调用次数，调用方等标准的审计点，为后续 MEC 节点拥有者提供计费、审计等提供打点 信息；轻量化、跨平台、插件式的框架：边缘节点硬件设 备千差万别，和端侧交互的协议也成千上万。例如工业场景需要应用支持 MQTT，OPC-UA 等协议；云游戏需要支持多种输入设备（如手柄，键盘）。EdgeFramework需要提供插件式的协议框架，使应用开发者方便地集成所需的协议栈；同时也需要通过硬件抽象屏蔽底层硬件差异性（如 x86/ARM/异构 AI），并结合EdgeAI为应用提供灵活的开发框架。按需部署框架：为适配不同边缘硬件资源与上层应用，需要将 MEC 平台进行组件化抽象。例如将MEP 平台抽象为核心服务，提供基础的服务注册发现、安全认证，以及 AI/存储/网络服务等组件。通过设计态框架，结合业界的 IaC 技术，可支持应用针对平台的按需部署，例如应用仅需 5G 网络能力，则只部署核心服务与 5G 网络服务的组件即可。2.2.10 边缘安全敏捷开发 EdgeDevSecOps从开发者的工具链体验上来看，MEC 的开发模式更加倾向于在一个模拟环境下完成端到端的环境功能打通，尤其是在 5G 环境以及终端设备场景比较难以获得的前提下，对云原生的 DevSecOps 提出了不同的需求：端到端的模拟开发环境体验：包括边缘对外开放能力的模拟器，以及最终5G设备的行为模拟，都需要在开放过程中持续提供模拟环境，确保应用测试 通过并且无阻塞运行。比如边缘 UPF 的分流行为、MEP 对外提供的位置信息等。流水线的安全流程全介入：边缘平台需要提供静态安全分析工具，保障应用不会引入具有高危漏洞的组件。同时对于代码和最终部署环境进行全量的扫描，保证无已知的安全漏洞。针对应用部署之后的测试，需要提供全流程自动测试化用例，并且提供身份验证和授权等自动化体验。边缘定制化的工具链/SDK：为方便边缘应用开发者组织与调用电信网络底层对应的接口能力，需要定制化的工具链/SDK；同时由于边缘的最终设备形态千差万别，针对如 X86 架构到 ARM 架构代码互相转换的工具链也是开发者亟需的。图 2-2 CAPIF架构图CAPIF core functionCAPIF-1ePLMNTrust Domain3rd party TrustDomainCAPIF-2eCAPIF-2eCAPIF-2eCAPIF-2CAPIF-2eCAPIF-1eCAPIF-1CAPIF-3CAPIF-2CAPIF-5eCAPIF-4CAPIF-5CAPIF-3eCAPIF-4eCAPIF APIsAPI invoker 1API invoker 2API invoker 3Service APIs API exposing functionAPI publishing functionAPI management function API provder domain 2API exposing functionAPI publishing functionAPI management functionAPI provder domain 1ServiceAPIsCAPIF-7eEdge Native技术架构白皮书1.017Edge Native产业实践03Edge Native 产业实践EdgeGallery：Edge Native 的开源实践3.1EdgeGallery 是由设备厂商、运营商，垂直行业伙伴等联合发起的一个 5G 边缘计算开源项目。目的是打造一个符合 5G MEC“联接+计算”特点的边缘计算公共平台，以 Edge Native 技术为底座，实现网络能力（尤其是 5G 网络）开放的标准化和 MEC 应用开发、测试、迁移和运行等生命周期管理流程的通用化。EdgeGallery 项目于 2020 年 8 月正式对外开源，提图 3-1 EdgeGallery 架构图供面向应用和开发者的端到端解决方案，将为应用开发者、边缘运营及运维人员提供一站式服务。目前社区共有 8 家高级会员和 17 家普通会员。八家初创会员分别是信通院、中国移动、中国联通、华为、腾讯、九州云、紫金山实验室、安恒信息等。EdgeGallery 目前 V1.0 版本（Chocolate Release）的架构图如下图所示：应用开发集成平台应用包设计应用开发能力设计SDK/API应用测试设计应用镜像设计应用设计态应用分发态基础设施管理Kubernetes/Micro