Edge Native技术架构白皮书1.0.pdf

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