“ONAP 应 用 部署模式” 来自运 营商 的观 点 Linux 网络基 金会 最终用户 咨询组 （EUAG ） 2020 年 6 月 目录 1. 介绍. 1 2. 关于本白 皮书 . 2 3. 应用部署 模式的 选择与 分 析 . 4 3.1 ONAP 与 SDO 协同 . 4 3.2 ONAP 快速 应用方 案及应 用部署模 式 . 6 4. ONAP 运营 商调研 与主要 发现 . 9 4.1 应用规划 . 9 4.2 应用组件 . 9 4.3 研发模式 . 10 4.4 部署模式 . 10 4.5 合作模式 . 10 4.6 目标业务 . 11 4.7 OSS 集成 . 12 4.8 组织模式 . 12 4.9 网络控制 . 13 5. 结论、建 议与意 见 . 14 致谢 . 16 附录: 类 似组织 示例 . 17 附录: 通 用术语 . 19 1 1. 介绍 开源项目是一种聚合资源、共同创造、并形成新兴技术领域共识的有力方式。更准 确地说，开源软件是源代码公开的软件，如果符合相关的许可和消费义务，则可供他 人使用。 对于通信运营商来说，其选择因素通常包括以下两种类型其一或结合。 自研软件或开源软件 通信运营商对选择自研软件亦或开源软件的看法有所不同，主要在以下几点上： 基础功能与技术 v/s 业务与支持 对厂商开放 v/s 社区协 作 厂商领导 v/s 业界的集 体智慧，或事实标准化 软件开发和演进的速度以及发言权 影响或贡献到公司蓝图与计划里的能力 Capex v/s Opex （注意 ：开源 免费/ 廉价） 其他 截至目前，针对运营商应 用自研和开源采取的不 同方法已有一些比较和 研究; 然而， 对于运营商应如何准备使用像开放网络自动化平台 （ONAP ） 这样的 大型开源项目， 没有很多现成的信息。 本文试图揭示 ONAP 应 用部署方面的挑战、关键考虑因素、模式。 LFN （Linux 网络基金会 ）创建了最终用户咨询组 EUAG ，在使用者间共享观点、挑 战和最佳实践，从而为社区开发者明确新的应用场景和需求。EUAG 由来自最终用户组 织的代表组成，这些组织包括电信服务提供商，有线电视服务提供商，网络提供商、 计算或存储服务提供商。在本文中，该组织成员统称为运营商。 作为最终用户的声音，重要的是要支持 ONAP 的发展及其在行业中的广泛应用，同 时贡献用例和需求，从而为整个行业带来最大的价值。 EUAG 的 ONAP 工作组 在撰写本文过程中，就如何实现最终用户的顺利部署，围绕 考虑因素、潜在机会和限制因素交流了看法。 2 2. 关于本白 皮书 我们越来越多地生活在“ 即时经济“ 中，每个人都希望所有事物是即时和实时的。延 迟和长时间的周转日益成为每个行业消费者敏捷高效的数据业务体验瓶颈。颠覆性数 字化所提倡的灵活敏捷、速度高效最终使智能社会覆盖各类垂直领域，包括卫生、教 育、旅游、科技研究等。考虑到基础架构现代化的重要性和价值，通信运营商正在经 历包括云、部署 NFV 和 SDN 在内的重大转型 计划，并正朝着开启 5G 时代迈进。这些 新举措正在影响技术体系结构，并创建 DSP （ 数字服务提供商）需要的新业务模式和 服务，以满足“ 即时经济” 消费者的需求。 网络提供 商正在采 用互 联网公司 所使用的 技术 和方法， 以使其运 营更 加灵活和 高效。 通信运营商正在发展这些新功能，以满足大型网络基础设施的需求，这些基础设施需 要具有高度的弹性，能实现整合跨地域的多个数据中心。如何在提供卓越的客户体验 同时提高效率，并最终使网络对用户和消费者透明是关键。技术和基础设施现代化提 供模式从硬件转向软件，这意味着“X 即服务“ 。基于软件的模型将服务设计、部署和管 理的平台 概念演变为新的敏捷模式，从而在优化成本的同时，可以及时响应客户需求。 这类平台是基于开放标准的，并完全是由软件驱动的，其具有以下关键的特性，例 如： 服务开放- API 驱动， 服务编排- 基于意图的工作流， 基于模板的服务设计- 卓越的设计态， 数据分析- 实现最新的 用例， 网络与应用控制器 关键 网元功能的自动化， 运维工具- 轻松运营未 来网络 此类平台的可用性可以帮助通信运营商实现所需的业务转型，并解决物理和虚拟 环境中云、网络和应用程序工作负载协调以及自动化管理的运营难题。 当通信行业开始其转型之路时，业界就开源准则达成了广泛共识，以实现不断增 长的价值。然而，现实情况是，每个领域存在众多开源项目计划，因此很难正确评估 和测试供应商产品，也很难选择电信级别的、以及云原生的解决方案。ONAP 旨在补 充各种标准组织 SDO （例如 ETSI-MANO ，ZSM ，MEC ，3GPP-4G ，5G ，Radio ，MEF ， TMForum ）及其他开源 项目计划（如 OVP ）的成果 ，以加快市场推广，并为这些组织 提供相关反馈。ONAP 将标准组织的知识和经验与开源项目的协作创新、开放特性相 结合。SDN/NFV 标准/ 开源社区的协作也在不断深化，这类协作正为软件驱动的网络创 新开拓出发展之路。 3 图 1 在过去 的三 年中，LFN 社区一 直在 迭代构 建开 源网络 自动 化平台 （ONAP ），从许 多通信运营商和活跃的厂商、社区成员获得资源投入。 ONAP 的技术研发主要 体现在以下方面: 平台的技术稳健性与现代软件开发实践应用 平台的功能成熟度，主要包括网络自动化方案/ 支持领域个数 平台的运营准备，与未来网络保持对齐，如何进行平台操作 随着 ONAP 平台的发展和成熟，其有机会在整个通信运营商环境中得到更广的应用。 本白皮书的主旨是为正在考虑引入并采用 ONAP 平台的通信运营商提供帮助指导。应 用部署 ONAP 平台的场景 有很多，就本白皮书而言，我们将仅关注在通信运营商的观 点、采用 ONAP 的考量 因素和 应用部署模式的选择等方面。 作为本文的一部分，LFN EUAG 针对通信运营 商如何应用部署 ONAP 进行了一项全 面的调查，本白皮书整理了这些信息。 4 3. 应用部 署模 式的选择 与分 析 未来的通 信运营 商服务 将与现在 有很大 的不同 ，了解这 些需求 是运营 商与相关 企业 研发、部 署、拓展下一代网络与服务的基础。未来的服务交付必须实现自动化、灵活 、 可靠，无需与底层基础架构绑定即可大规模扩展。正是出于这些原因，ONAP 近年来 通过简化 服务、降低成本和创建敏捷服务，为运营商提供了潜在 价 值。 部分运营商和 其他活跃成员正在体验、学习使用 ONAP ， 并 将其项目集成到其现有环境中。 在可预见的未来，物 理、虚拟和云原生网络 将需要共存。关键服务 将需要跨 现代和 传统网络创建，因此 ONAP 必须能够与传统网 络、EMS /NMS 、OSS/BSS 系统进行互操 作，以实现跨混合网络服务部署，同时充分使用私有云和公共云的 功能。ONAP 的最 终目标是 从关键用例开始，提供 即时的价值，其目标是 作为端到端的 全局服务 管理平 台，通过设计和提供服务，高效运营跨数据中心的混合网络。 通信运营商在决定集成 ONAP 到现有环境中 主要的考量因素包括： 具有单个 ONAP 模块的 电信级版本的集成解决方案 在 ONAP 环境中建立并 运行的服务模型、应用以及微服务 与 ONAP 兼容的网络基 础架构（物理/ 虚拟），包括 PNF ，VNF ，域 控制器等 运行与管理 ONAP 所需 要的运维操作 采用 ONAP 交付和运营 服务所需的一系列开发人员、测试人员和设计人员 确保 ONAP 在设计上是 安全的产品，避免和具体业务场景绑定的硬编码实现 其他考虑因素 将 ONAP 引入现有的运营商环境是很复杂的，面临的挑战不仅是管理逐步采用 ONAP 组件的转变，还 要让它们与现有管理系统共存。ONAP 的框架 是可重复使用的， 其 具有管理与运维、自动化、AI/ML, 自适应的 策略、信息模型、服务编排的能力。 这 些是未来 用于服务模式和用例的可选产 品， 这些 模式和用例也可以用于支持其他垂直 行业。 ONAP 是一个模块化项 目，可满足许多通信运营商的要求，这些通信运营商通常在 网络领 域依赖 传统 与 行 业标准 。回顾初 心 ，如果我们 能定 义 ONAP 的发展 演进 策略来 解决这一集成难题，就应该关注解决 EMS 、NMS 、OSS 以及 BSS 之间的互操作问题； 这是以最 小成 本推广 ONAP 平台应 用部 署的捷 径 。我 们认 为， 针对这 些来自 运营 商的 典型集成 场景 提供 针对性 解决方 案 ，将 为 ONAP 的后 续部 署应 用 提供 一种有 效的 推进 方式。 3.1 ONAP 与 SDO 协同 一些通信 运营商 对所使 用的解决 方案有 很强的 标准依赖 性，构 建跨组 织协作网 络成 为大家普遍采用的策略（比如，与 3GPP 对齐 的方案 或 与 GSMA 对 齐的规范）。标准 组织可以 协助优化开源项目的架构、质量以及互操作，同时增强产业 价值链的整体活 力。 图 2 概述了开源项目和 SDO 之间的当前形势和关系： 5 图 2 ONAP 社区意识到了这 种合作的重要性，并努力保持一致性和协调性。 ONAP 是一个框架，可以作为可部署平台或参考框架使用，因为它突显了所有相 关 SDO 的最佳开发能 力。遵循开源、标准协同合作的方式将使业界能够选择和组合来 自不同供 应商 的不 同解决 方案和 模块 以适 应 ONAP 框架 ，从而 实现未 来网络 服务 管理 所需的敏捷性与高效性，以及良好的开源生态。 最新的 ONAP 白皮 书 1 发出了统一开源和标准解决 5G 切片等核心技 术问题的倡议 。 1 Harmonizing Open Source and Standards: A Case for 5G Slicing: onap/wp-content/uploads/sites/20/2020/03/ONAP_HarmonizingOpenSourceStandards_031520.pdf 6 3.2 ONAP 快速应 用方案 及应用 部署模 式 与所有新技术的应用情况一样，社区正在定义 ONAP 的最小集可用产 品作为可部署 的解决方 案，以推动有效的业务案例。这将允许根据通信运营商的组织成熟度和业务 驱动因素进行转换，为 ONAP 提供不同的 应用部署阶段。定义 ONAP 应用阶段对于通 信运营商来说是很重要的，ONAP EUAG 社区 相信这种阶段性的方案是一个好的开端， 以下是一些需要考虑的点： (a) 首先考虑解决南向接口集成与协同工作的问题，网元也是第一个需要考虑的因 素，如何将网元与 ONAP 进行集成； (b) 其次是“ 业务管理” 计划，以协调和交付模型驱动的服务，以及 (c) 为更显著 地发挥 其引入 价值，通 信运营 商应结 合其所在 领域的 ML/AI 角度 来考 虑提高运营效率，并最终实现闭环。 ONAP 这类项目可通过 多种方式在通信运营商中实现应用部署: a) 在内部研发软件并实现交付（全自主模式） b) 系统集成商交付（全外包模式） c) 采购专业开源技术支撑服务（开源外包模式） d) 以 ONAP 为参考选择合 作商/ 厂商（标准参考模式） 下表为以上的各类模型进行了展开说明： ONAP 应用部署 模式 优点 缺点 示例 在内部研发软件 并实现交付（全 自主模式） 运营商完全掌控代码 如果不适合直接使用 ONAP ，则运营商可对 ONAP 进行自定义/ 增 强/ 更改 运营商变得更类似互联 网企业 运营商必须更多地参与 论坛和信息的交流、贡 献，并增加参与度 确定软件功能和构 建团队需要花费时 间和精力 管理观念、运营模 式、组织架构需要 根据开源软件进行 调整，这可能对一 些运营商来说具有 挑战性 包括早期应 用 ONAP 的 AT T 、 Bell Canada、 Orange， 并且该列表 还在不断发 展 7 ONAP 应用部署 模式 优点 缺点 示例 系统集成商交付 （全外包模式） 这是全外包模式，在此 模式中，固定的系统集 成商/ 主要供应商将负 责开发、测试和部署- 意味着运营商仍对其进 行监督，并以“ 委托” 的 方式负责 交付出现问题的风险降 低了，因为专业的系统 集成商/ 主要供应商在 设计上更加成熟、专业 运营商必须跟踪交 付内容的变更，确 定可能的增强功能 点、需求，并通过 对应的固定系统集 成商/ 主要供应商完 成交付 如果“ 委托” 的合作伙 伴承担了大部分繁 重的工作，运营商 可能变得对其过于 依赖 ONAP 支持 的早期系统 集成商例如 Amdocs 、 Accenture ，而且该列 表还在不断 发展 采购专业开源技 术支撑服务（开 源外包模式） 与 Openstack 类似， ONAP 存在“ 社区版” 、 “ 发行版” （基于社区版 进行特定增强的）、 “ 定制版” （针对运营商 应用场景的产品化版 本） 从发行版到定制版的研 发过程可以： o 在运营商内部研发 团队完成 o 由外部系统集成商 / 主要供应商完成 o 由发行版提供商完 成 发行版提供商的职责还 包括与社区的功能特 性、缺陷修复的发展保 持一致 如果选择的交付选 项与专业机构不 同，交付中的摩擦 可能会逐渐扩大， 可能会产生一些多 团队管理挑战 运营商需要持续监 控“ 社区版” 与“ 发行 版” 的一致性 Aarna Networks ， 而且这个列 表有望不断 发展 以 ONAP 为参考 选择合作商/ 厂商 （标准参考模 式） ONAP 遵循各类 SDO ，例如，对于 TMF 、3GPP 、ETSI 、 GSMA 等.，此模式使 运营商可以在选择供应 需要更多地监控软 件实现与标准的一 致性 对供应商的依赖性 仍然很高，但这可相关示例 较多 ，包 括法电、 NTT 等运营 商，该列表 8 ONAP 应用部署 模式 优点 缺点 示例 商产品的同时向供应商 要求特定的 SDO 合规 性; 并将 ONAP 作为可 参考的体系结构，获得 最符合标准的产品 根据所选的供应商，其 应用程序的维护完全由 供应商自主负责 能并非在所有情况 下都构成挑战-取决 于不同运营商的策 略，它也可能转化 为优势 也在不断发 展中 9 4. ONAP 运营商 调研与主 要发 现 2020 年 1 月，LFN EUAG 针对通信运营商如何 应用部署 ONAP 进行了一项全面的问 卷调查，包含 15 个问 题，内容涵盖了： (a) ONAP 部署 (b) 社区参与 (c) 互操作 (d) ONAP 用例与业务场景 (e) 传统 OSS/ 其他系统与 ONAP 的集成 这些问题是通信运营商在制定如何应用部署 ONAP 的计划时通常需要 考虑的共性问 题。问卷结果提供了当前 ONAP 应用现状的概 况说明，以及通信运营商关注的用例/ 业 务场景。 这份 问卷 调研对 象包括 已经 在现 网应用 部署 ONAP 的 、以及 当前正 在制 定应 用部署计划的运营商。 4.1 应用规划 a. 45.45% 通信运营商反馈，其目前已完成相应的 ONAP 平台实际现 网部署工作或 有着清晰明确的应用规划，将在 1 年内实现 ONAP 投产 b. 其余 36.36% 运营商对于 ONAP 平台能力和组件仍然在测评（实验室测试、试点 测试等）阶段 c. 没有运 营商 反馈 他们 不 计划明 年内 在现 网或 者 实验环 境中 应用 部署 ONAP ， 然 而有 18.18% 运营商不确定或者没有办法给出回应 大约 80%运营商表示 已经/ 计划部署和积极 尝试在实验环境评估 ONAP ，没有人表 示他们不计划采用 ONAP 。这表明，在 LFN EUAG 成员反馈结果中，ONAP 是其网络计 划中 明确 的一 部分 ，通 信运 营商 正在 采取 重大 举措 ，在 近期 内提 高 ONAP 的应用 部署 水平。 4.2 应用组件 a. 9.09% 运营商计划构建独立于业务场景的完整通用平台 b. 大多数（54.55% ）计划按需引入社区部分成熟模块（比如 APP-C, DCAE, SO 等）， 并重点考虑与已有其他网管功能模块的互操作 c. 其余 9.09%计划重新架 构独立于业务场 景的未 来通用网管体系 ，按需 引入社区 ” 虽然近一半的受访通信运营商有在现网采用 ONAP 的具体计划，但仍有一些运营 商选择在实验室中进行评估。EUAG 建议 ONAP 社区探寻是否有运营商普遍关注的 特定领域（比如简化部署，改进质量等），以提升 ONAP 在现网生产 中的应用比 例。为进一步加速 ONAP 应用推广，EUAG 应更多地识别 ONAP 部署 的阻碍因素。” 10 部分成熟模块 d. 27.27% 没有明确的计划或者无法分享回应 4.3 研发模式 a. 全自主模式 - 选择采用 该模式的运营商占 27.27% b. 全外包模式 - 选择采用 该模式的运营商占 36.36% c. 开源外包模式 - 选择采 用该模式的运营商占 9.09% d. 标准参考模式 - 选择采 用该模式的运营商占 27.27% 关于 ONAP 应用 模型 的调研 反馈情 况较 为平 均，大 部分运 营商 都不 仅仅选 择采用 单一的 应用模式 ，综合整体情况分析，采用“ 全外包” 模式的运营商最多，“ 全自主” 与 “ 标准 参考” 模式的运营商数量次之，“ 开源外包” 模式最少，选择情况大致呈现小部分 聚集的形式，并且每个应用模式基本均有两家以上运营商采用。 4.4 部署模式 a. 集中部署：运营商在全网集中部署一套 ONAP, 调研结果反映当前有 27.27% 运营 商选择了该模式 b. 分域部署：运营商在每个管理的业务域或者专业域单独部署一套 ONAP ， 9.09% 运营商选择了该模式 c. 分级部署：运营商在每个管理域的不同地理区域单独部署一套 ONAP ，不同管 理域之间 ONAP 与上层 ONAP 互通，最后再与传统 OSS 互通，9.09% 的运营商选 择了该模式进行部署 54.54% 运营商表示当前 未部署 ONAP, 或不确定/ 不方便透露 4.5 合作模式 a. 9.09% 运营商反馈其内部团队负责独立设计、开发、部署、运维 b. 运营商与第三方合作厂家联合设计与开发, 运营商负责部署和运维，该方式占 比为 27.27% c. 运营商发布技术架构、 功能需求、接口协议、 信息模型等企业规范， 要求厂家 “ 虽然集中部署模式收到的反馈最多，但鉴于缺乏明确的反馈，ONAP 社区应提供灵 活且可解耦的体系架构，从而允许运营商灵活选择不同的部署模式” “ 为了最大程度满足运营商的部署计划，建议 ONAP 社区支持所有 应用部署模式 ” 。 “ 可以开展进一步研究，以明确采用特定的 ONAP 组件的考虑因素，这将为其他开源 社区提供有关应用部署规划的有用信息” 。 11 对照标准提供 相应解决 方案，同时考 察是否基 于社区代码或 社区参与 程度, CSP 负责产品测试、部署和运维，该方式占 36.36% d. 运营商发布技术架构、 功能需求、接口协议、 信息模型等企业规范， 要求厂家 对照标准提供相应解决方案，不要求基于社区代码, 运营商负责产品测试、部 署和运维，该方式占比为 18.18% e. 9.09% 表示不确定或不方便透露 参与 ONAP 部署、运维 、测试的运营商共计占比达 90% 以上，大部分运营商均或 多或少参与负责了部署、运维与测试过程。 4.6 目标业务 业务类型 现网部署 比例 未来关注 比例 业务成熟 度指标 （现网部 署/ 未来关 注） Transport VPN 18.18% 45.45% 40% Wireline Layer1-3 27.27% 54.55% 50% L3VPN 9.09% 18.18% 50% SD-CPE (uCPE) 9.09% 18.18% 50% Mobility 36.36% 64.64% 57% SD-WAN 27.27% 45.45% 60% Voice 27.27% 36.36% 75% Security 9.09% 9.09% 100% L2VPN 9.09% 9.09% 100% 这以上列 表中， 业务成 熟度指标 反映了 当前业 务的研究 成熟程 度，成 熟度指标 越低 的业务， 其研究潜力越大，成熟度指标越高的业务，其研究空间较小，也即该类业务 当前已相对成熟或业务需求较低，无需在未来投入较多成本进行更深的研究。从业务 成熟度 来看 ，当 前最为 成熟的 业务 为安 全业务 与 L2VPN ，SD-WAN 与语音 业务 、移动 业务有一 定的新网部署成熟经验，同时在未来也有很多运营商仍投以较大的关注度。 当前现网部署较不成熟，未来研究潜力较大的业务有 Transport VPN 、Wireline Layer1-3 、 L3VPN 和 SD-CPE， 其中 Transport VPN 成熟度最低，ONAP 社区未来需要着重针对该类 业务展开方案研究，Wireline Layer1-3 成熟度 次之，虽与其它两类业务具有相同的成熟 度，但其未来关注度相对较高，达 54% ，是社区未来主推的业务方向。 “ 社区需要创建一个应用模型 v/s 部署模型的 比较列表；以及参与的运营商、供应 商/ 系统集成商进行的各种活动的统计信息与模式；在决定是否采用 ONAP 时，这 可能是运营商可以参考的社区资产” 。 12 4.7 OSS 集成 对基于 ONAP 的业务 场景与用例，针对现有网元和新网元管理方式，18% 运营商表 示 ONAP 仅管理部署新 网元，80% 以上的运营商表示 ONAP 同时管理 现有网元和新网元。 针对不同类型的网 元管 理方式，90%以上运营 商表示他们的 ONAP 平台部署会与 OSS 进行集成，9% 运营商表示不确定是否会采取集成的方式管理不同类型网元。 可以看到 ，对于 不同类 型网元的 管理方 式，大 部分运营 商代表 均表示 会选择与 现有 OSS 系统集成，这也是目前的大趋势所在。针对选取了与 OSS 集成的运营商，当前的 集成方案有以下几种: a. ONAP 与 OSS 管理对象 不同，单 独建设 ，互不 相 关，分别 进行端 到端业 务 开通和告 警 性能监控 ，选取 了这类 集 成方案的 运营商 占 18.18% b. ONAP 与 OSS 管 理对象 不同，单 独建设 ，ONAP 负责新网 元、统 一接入 传 统 OSS 负责 端到端业 务开通 ，这类 运 营商占 36.36% c. ONAP 与 OSS 管理对 象不同，单独建设，OSS 负责传统网元、统一接入 ONAP 负责端到端业务开通，这类运营商占 9.09% 除此以外，有 9.09% 的运营商表示他们会依据不同情况和 use case 来决定不同的 集成方式 ，不采 用单一 的集成方 案；也 有 27.27% 运营商 表示不 确定 当前的集 成方案或 者不愿意公开。 集成方式中 ONAP 负责 新网元、统一接入 OSS 负责 E2E 业务开通的方案选择比例 较高，是当前运营商较为普遍常用的集成方案。 4.8 组织模式 该问卷调研为运营商内部团队定义了 3 种基本的工作模式：a. 独立模式，b. 松耦 合模式 与 c. 紧耦合模 式。 a. 独立模式：社区团队与 产品团队以及运维团队 相互独立，没有内部例 行沟通和 共同规划 “EUAG 调研结果显示，在某些情况下，ONAP 和 OSS 提供的功能存在 重复性。ONAP 社区必须确保的关键点是如何保证各种南向接口和北向接口的集成工作。此外，提 供用于解释 OSS 功能以 及 ONAP 如何发挥集成 增值作用的指南手册将非常有用。” “EUAG 在运营商中进 行了 一系列业务/ 用例的调查 ，关于其中一些开放式的问题， 目前的运营商关注重点似乎暗示了其倾向于关注较新的业务类型， 这些业务有更 多的自动化空间。EUAG 认为， ONAP 应发展成为一个更加成熟的平台，使其可以 成为未来业务、甚至是尚未发展的业务或用例的推动者。” 13 b. 松耦合模式：社区团队 、产品团队以及运维团 队相互独立，但有内部 例行沟通 和共同规划 c. 紧耦合模式：社区团队、产 品团队以及运维团队隶属 于内部同一个项目或研发 部门， 进行周期 性统一 规划与 对 齐 在调研结果中，选择了 松耦合模式的运营商达 到 45.45%，占比最大，选择独立模 式与紧耦合模式的比例各占 9.09% 。 其余 36.36% 表示不确定或者不方便透露。4.9 网络控制 使用 ONAP 的方法有很 多种，但并非所有运营商都计划在它所支持的所有类型操作 中使用它。结果如下表所示： 网络功能操作类型 当前使用的 计划使用 NF 实例化 45% 82% NF 配置 45% 82% NF 切换管理 27% 45% NF 监控 36% 63% NF 控制闭环 36% 55% 其他/ 无（未在现网使 用） 55% 36% 这些问题的回复总体上相当平均，但结果表明，在生产中使用或计划使用 ONAP 的 运营商 对服 务交 付（ 实 例化、 配置 ）方 面比 ONAP 提供的服务保 证 （监视 、控 制闭环 ） 能力更感兴趣。 “ 运营商当前正在使用 或计划利用整套 ONAP 的服务交付和服务保证能力来实现网络 功能，至少最开始更注重的是服务交付方面。” “ONAP 社区负有在多个方面提供帮助的重要责任。最终，每个运营商才能找到最合 适的工作模式。并获得社区尽可能多的支持。” 14 5. 结论、 建议 与意见 从本文以及关于 ONAP 应用部署模式以及 ONAP 应用部署生态情况的调研结果中可 以明显看 出，这显然不是一个容易分析的话 题。 对于选择一个准确的 应用部署模式来 说，并没 有正确的答案。其存在着多种选择和依赖的关系，每种选择和依赖关系都有 着运营商 不同的权衡，对于一个运营商而言最有效与最适合的选择对于另一个运营商 来说可能有很大的不同。 通过对调 研答案 的统计 和分析可 以看出 ，各个 运营商的 愿景存 在很多 分歧，这 也许 是因为其 中大多数都处于部署的早期阶段。问题的设计方式代表了针对不同问题的从 当前到短期以及从中期到长期的观点。 LFN EUAG 从这份问卷 调研中得出了一些建议和意见，总结如下: 调研话题 建议/ 意见 ONAP 应用与部署： 现状和未 来 近一半 的受访 通信运 营商 有在现 网采用 ONAP 的 具体计 划，并有一 些运营商 选择在 实验室 中 进行评估 。EUAG 建议 ONAP 社 区探寻 是否 有运营商普遍关注的特定领域（比如简化部署，改进质量等），以 提升 ONAP 在现网生产中应用比例。为进一步加速 ONAP 应用推 广，EUAG 应更多 地去识 别 ONAP 部 署的阻 碍因素 。 对于正在应用并且有 计划部署的运营商， 哪些 ONAP 组件 是他 们计划使 用的 可以开展进 一步研究 ，以 明确采用特 定的 ONAP 组件的考虑 因素， 这将为其 他开源 社区提 供 有关应用 部署规 划的有 用 信息 通信运营商计划采用 什么 ONAP 应用 部署 模式 为了最大 程度满 足运营 商 的部署计 划，LFN EUAG 建议 ONAP 社 区能 够支持所 有的应 用部署 模 式 通信运营商计划遵循 哪种部署 模式 虽然集中部署 模式收到 的 反馈最多，但 鉴于缺乏 明 确的反馈，ONAP 社区应提供灵活且可解耦的体系架构，从而允许运营商灵活选择不 同的部署 模式 通信运营商如何与厂 商协同设计、研发、 部署？ 社区需要 创建一 个应用 模 型 v/s 部署模 型的比 较列 表；以及 参与的 运 营商、供应 商/ 系 统集成 商进行的各 种活动 的统计 信息与模式 ；在决 定是否采 用 ONAP 时，这 可能是运 营商可 以参考 的 社区资产 运营商使用或者计划 使用 ONAP 支撑 的目 标业务 EUAG 在运营 商中进 行了 一系列业 务/用例 的 调查 ，关于其 中一些 开 放 式的问题 ， 目 前的运营 商关注重 点似乎 暗示了其 倾向于关 注较 新 的业务类 型， 这些业 务 有更多的 自动化 空间， 因此 ONAP 应该 提供 这些 业务支持。EUAG 认为， ONAP 应发展成为一个 更加成熟的 平 台，使其可以成为未来业务、甚至是尚未发展的业务或用例的推动 者。 ONAP 与现有 OSS 的 集成 EUAG 调研结 果显示 ，在 某些情况 下，ONAP 和 OSS 提 供的功 能存在 重复性。ONAP 社区 必须 确保的关 键点是 如何保 证 各种南向 接口和 北 向接口的 集成工 作。此 外 ，提供用 于解释 OSS 功 能以及 ONAP 如何 发挥集成 增值作 用的指 南 手册将非 常有用 。 组织模式 ONAP 社区负 有在多 个方 面提供帮 助的重 要责任 。 最终，每 个运营 商 才能找到 最合适 的工作 模 式，并获 得社区 尽可能 多 的支持。