“ONAP应用部署模式”来自运营商的观点_21页_1mb
报告摘要
ONAP 应用部署模式总结
核心内容
本白皮书由 Linux 网络基金会(LFN)的最终用户咨询组(EUAG)发布,旨在分析通信运营商在部署 ONAP(开放网络自动化平台)时的选择与挑战。ONAP 是一个开源平台,支持网络自动化、服务编排、数据分析、AI/ML 集成等关键特性,旨在帮助运营商实现更高效、灵活和智能的网络管理。
主要观点
- 开源与自研的平衡:运营商在选择自研或开源方案时,会考虑技术能力、成本(Capex vs Opex)、社区协作、厂商支持、标准兼容性等多方面因素。
- ONAP 的优势:ONAP 提供模块化架构,支持跨物理、虚拟和云原生环境的部署,与传统 OSS/BSS 系统互操作,适用于未来网络服务管理。
- 部署模式多样性:ONAP 可以根据运营商的需求,采用集中部署、分域部署、分级部署等多种方式。
- 集成与互操作性:大多数运营商计划将 ONAP 与现有 OSS 系统集成,以实现新旧网元的统一管理,同时优化自动化能力。
- 合作模式:运营商采用不同的合作方式,包括内部独立开发、与系统集成商合作、与第三方厂商合作等,社区需提供灵活支持。
关键信息
3.1 ONAP 与 SDO 协同
- ONAP 与多个标准组织(如 ETSI、3GPP、TMForum 等)协同工作,以增强平台的互操作性和行业兼容性。
- ONAP 作为可部署平台或参考框架,能够整合不同 SDO 的最佳实践,支持行业标准的落地。
- EUAG 建议 ONAP 社区推动与标准组织的协同,以统一开源和标准,解决 5G 切片等关键问题。
3.2 ONAP 快速应用方案及部署模式
ONAP 的应用部署模式包括以下几种:
| 部署模式 | 优点 | 缺点 | 示例 |
|---|---|---|---|
| 全自主模式 | 运营商完全掌控代码,可自定义增强 | 需要内部团队投入,管理复杂 | AT&T、Bell Canada、Orange |
| 全外包模式 | 专业供应商负责开发、测试和部署 | 运营商依赖性高,需持续跟踪变更 | Amdocs、Accenture |
| 开源外包模式 | 社区版本、发行版、定制版可灵活选择 | 可能出现多团队管理问题 | Aarna Networks |
| 标准参考模式 | 基于 SDO 标准选择供应商 | 仍需监控标准与实现的一致性 | 法电、NTT 等 |
4.1 应用规划
- 45.45% 的运营商已完成 ONAP 现网部署或有明确的部署计划。
- 36.36% 的运营商仍在评估或测试 ONAP 的能力。
- 18.18% 的运营商尚未决定是否部署 ONAP。
4.2 应用组件
- 9.09% 的运营商计划构建独立通用平台。
- 54.55% 的运营商按需引入成熟模块(如 APP-C、DCAE、SO 等)。
- 27.27% 的运营商未明确计划或无法分享。
4.3 研发模式
- 27.27% 采用全自主模式。
- 36.36% 采用全外包模式。
- 9.09% 采用开源外包模式。
- 27.27% 采用标准参考模式。
- 多数运营商采用混合模式,结合多种部署和研发策略。
4.4 部署模式
- 27.27% 采用集中部署。
- 9.09% 采用分域部署。
- 9.09% 采用分级部署。
- 54.54% 的运营商尚未部署或不确定。
4.5 合作模式
- 9.09% 由内部团队独立完成。
- 27.27% 与系统集成商合作。
- 36.36% 与厂商合作,依据标准提供解决方案。
- 18.18% 与厂商合作,但不依赖社区代码。
- 大多数运营商参与了部署、运维和测试过程。
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,而 Transport VPN 和 Wireline Layer1-3 等业务具有较高的未来关注度和研究潜力。
4.7 OSS 集成
- 80% 以上的运营商计划同时管理现有和新网元。
- 90% 以上的运营商表示其 ONAP 平台将与 OSS 集成。
- 集成方案中,ONAP 负责新网元,OSS 负责端到端业务开通的比例最高。
- 部分运营商表示会根据 use case 选择不同集成方式,或不确定当前方案。
4.8 组织模式
- 45.45% 采用松耦合模式。
- 9.09% 采用独立模式。
- 9.09% 采用紧耦合模式。
- 36.36% 不确定或不方便透露。
4.9 网络控制
- 当前使用 ONAP 的网络功能操作包括 NF 实例化(45%)、NF 配置(45%)、NF 监控(36%)、NF 控制闭环(36%)。
- 82% 的运营商计划使用 ONAP 的服务交付能力(实例化、配置)。
- 63% 计划使用 ONAP 的服务保证能力(监控、控制闭环)。
结论、建议与意见
- 部署模式选择无统一答案:不同运营商基于自身战略和需求选择不同的部署和合作模式。
- 建议:
- ONAP 社区应识别并解决部署中的阻碍因素。
- 提供统一的集成指南,以增强与 OSS 系统的互操作性。
- 开发更清晰的应用模型与部署模型对比列表。
- 加强对新兴业务(如 Transport VPN、Wireline Layer1-3)的支持。
- 推动与 SDO 标准的协同,以增强平台的行业适用性。
附录:类似组织示例
| 项目 | 描述 |
|---|---|
| OpenStack | 云操作系统,支持计算、存储、网络资源池管理 |
| OpenDaylight | 开源 SDN/NFV 平台,支持网络自动化和创新 |
| Tungsten Fabric | 支持网络虚拟化与安全,提供通用协议和组件 |
| OSM | 提供 ETSI NFV 信息模型一致的 MANO 栈 |
附录:通用术语
- LFN:Linux Foundation Networking
- EUAG:End User Advisory Group
- CSP:Communication Service Providers
- DSP:Digital Service Provider
- ETSI:European Telecommunication Standards Institute
- MANO:Management & Orchestration
- ZSM:Zero Touch Service Management
- MEC:Mobile Edge Compute
- 3GPP:3rd Generation Partnership Project
- MEF:Metro Ethernet Forum
- TMForum:Telecommunication Management Forum
- EMS/NMS:Element Management Systems / Network Management Systems
- OSS/BSS:Operational Support Systems / Business Support Systems
展开完整摘要
试读结束,高清完整版pdf/doc/ppt,请点下载