面向云网一体的分层解耦的运营支撑系统架构演进方法研究

杨振东（中国联通广东分公司，广东广州 510627）

1 概述

5G 时代，各行业数字化转型速度加快，数字经济推动云网一体加速发展，云网融合诉求增强。5G时代是万物互联、万智互联的智能时代，通信连接产业的价值由联网升级到联云。云网融合是新型信息基础设施的核心，云服务由底层服务走向主导服务，云的重要性越发突出，未来5年所有的内容、应用、服务、数据、客户都要上云。政府部门、事业单位、企业上云进程加速，企业新建的基础设施将逐步部署在云上，预计到2025 年将达到85%的比例。随着企业生产系统上云的普及，云网融合成为“刚需”。企业规模越大，上云的系统越关键，对云网融合的要求越高，多云（公有云、私有云、专属云、混合云）部署成为普遍需求。

在云网协同、云网融合、云网一体的需求下，需要有与之相匹配的云网运营支撑系统架构进行支撑。开放网络自动化平台（Open Network Automation Platform，ONAP）是Linux基金会旗下两大开源MANO 工作组Open-O 和ECOMP 合并后成立的一个组织，ONAP致力于打造全球最大的NFV/SDN 网络协同与编排器开源社区，面向物联网、5G、企业和家庭宽带等场景，打造网络全生命周期管理平台，使运营商业务开发更灵活、业务上线更快捷、网络运维更高效。ONAP 提出设计态和运行态两态分离的理念以及模型驱动的理念，为电信运营商业务编排设计和上线部署提供了基本框架。ONAP 已成为业界对于云网编排协同的主流标准，全球各主流运营商如中国移动、中国电信、AT&T、沃达丰、法国电信等均参照或借鉴此架构和理念进行OSS运营支撑系统的规划建设和运营。

2 需求分析

ONAP 架构设计全面，各种功能组件比较丰富和完备，其中设计态组件包括对象设计与创建、策略创建、业务流程设计和其他周边组件，运行态组件包括业务编排、控制器适配、数据采集/分析、全局资源库、策略框架和其他周边组件。在实际部署过程中，由于不同通信运营商的业务应用场景、OSS 系统架构现状及演进策略以及资源禀赋有所不同，ONAP 架构与现有实际业务应用场景并不完全吻合，与现有OSS 系统存在较大差异，各运营商的演进策略也有快慢之分，不适宜直接全盘照搬部署。而且，现有ONAP 方案在编排架构上没有分层编排和分步实施的考虑，对云网业务自动化的编排协同架构演进缺乏可落地的指导技术方案。如果一次性构建业务和能力编排，存在如下问题。

a）现有的业务/应用较为简单，业务灵活编排组合或业务之间嵌套的需求不多，基于ONAP 的业务编排能力暂时无须使用。

b）ONAP 组织成立于2017 年，其相关架构、技术和组件还在发展完善中，对ONAP 的理念理解和使用经验不足，相关的应用案例、应用场景还不够丰富，需要逐步积累。

c）ONAP 组件较多，实现了OSS域所有模块功能，代码量较大。一次性、一步到位构建全套/全栈业务和能力编排协同平台投资较大，但无法全部发挥作用，浪费投资。

d）新的ONAP 架构对开发和运维人员需求较大，团队职能还未整合，人员的能力无法在短时间内满足新架构运营的要求。

e）部分运营商现有的业务编排能力还未迁移到云网协同器承载或参照ONAP 架构部署，对业务/应用层面编排协同的需求还未凸显。

5G 时代，经济社会数字化转型进程加快，云网能力协同、云网业务融合、云网一体化运营对云网运营支撑架构的资源/能力编排协同层的演进需求，相对于业务/应用编排协同层的演进需求，更为突出和迫切。需要找到一条切实可行的路径和方法，满足以上需求。

3 面向云网一体的运营支撑系统架构演进方法

3.1 面向云网一体的运营支撑系统目标架构

通信运营商为满足云网一体运营需求，支撑云网产品电商化服务体验，优化云网一体运营支撑架构实现分层解耦，研发和部署云网协同器，实现云网能力快速持续输出，支撑差异化云网创新产品快速部署。通过重构云网一体化运营支撑系统架构，贯通B 域和O 域，实现云网协同能力开放。云网运营支撑体系分层解耦，将业务应用层、云网协同层、云网控制层/网管平台分层解耦，分层解耦的云网协同运营支撑系统架构包含如下模块。

a）业务受理平台。负责业务统一受理、客户资源管理、计费账务等。

b）调度系统或服务开通系统。云网融合产品订单BO 贯通入口，负责业务开通流程调度，包括云网资源核实分配、云网资源激活去活、装机运维派单等环节。

c）资源管理系统。负责云网资源数据、用户数据、业务数据统一管理、资源在线核配等。

d）云网协同器。南向对接云网控制层/网管平台实现跨专业、跨厂家、跨域（网络域、业务域）的云网配置激活、数据查询等指令适配下发；北向面向BO 域应用业务平台输出云网编排协同能力和云网状态感知能力。在本文描述的架构中，云网协同器南向对接CPE控制器、IP/光网络控制器、5G切片管理平台、云管平台，北向对接调度或服务开通系统，实现对省内多云、多网的能力统一封装，向上层业务应用平台开放云网能力。

e）通信网络和云资源控制层/网管平台。包括网资源（光网、IP 网、无线网、核心网、宽带网、城域网等通信网络资源）和云资源（行业云、公有云、边缘云等云资源）等云网原子能力解耦封装。

f）云网资源层。云网基础资源池，包括通信网络转发面和云资源池。

引入云网协同器带来如下益处。

a）云网运营支撑系统架构分层解耦。上层业务应用平台专注于业务流程处理，产品、业务层面的内容展示，以及与客户交互界面的友好便捷；云网协同器专注于云网底层能力的封装和协同，专注于云网业务的实现逻辑和处理复杂繁琐的技术实现细节。

b）人员的定位解耦。业务应用平台人员专注产品、业务的展现逻辑和业务流程；云网协同器人员专注云网底层CT+IT 能力实现，实现不同团队人员的专业化。

c）前台与中台解耦。轻量快捷敏捷的前端业务应用平台与厚重复杂的云网能力中台解耦，前端业务平台敏捷高效响应市场需求，云网能力中台实现云网能力沉淀积累。

d）云网协同层与云网设备控制层分离和解耦。云网协同器可以根据运营商的业务、产品发展需要，快速进行个性化、差异化能力的开发和迭代，降低对底层设备厂家协同控制器的依赖，提升运营商自主创新能力和新产品新业务上线速度。

3.2 面向云网一体的运营支撑系统架构演进方法

基于以上系统架构，本文提出一种分层解耦、分步部署的基于ONAP/TMF 架构理念的云网协同运营支撑架构演进方法，在云网运营支撑系统架构的设计和部署上将云网资源/能力编排协同层与云网业务/应用编排协同层分离解耦，先将云网资源/能力编排协同层参考ONAP/TMF 架构理念进行部署，再根据需要将云网业务/应用编排协同层迁移到ONAP/TMF架构。

运营商受技术水平和使用经验不足、已有业务编排的复杂度不高、投资规模、人员组织架构分属不同团队以及现有运营支撑系统架构与目标架构不完全匹配等因素影响，在ONAP/TMF 编排架构部署无法一步到位的情况下，可以通过分层解耦、分步部署的方法，通过云网协同器拉通底层云网能力，通过TOSCA的拓扑建模和工作流程引擎技术的使用，将所有云和网络的资源对象进行抽象和建模，构建统一的逻辑网络和云资源层，向上层业务层开放云网能力，业务层感知到的只是云网能力集合和标准化接口参数，云网协同器对业务层屏蔽云网资源层的异构接口差异。将云网协同器作为云网资源/能力编排协同层的功能承载平台并按照ONAP 架构进行部署，既支撑了新的业务需求并向业界先进主流编排架构迁移，又保障了对现有业务流程的继承和支撑，以及业务和服务的延续性。

3.2.1 TMF分层模型架构说明

根据电信管理论坛（Telecommunication Management Forum，TMF）的标准，电信业务PSR 模型分层划分为产品（Product）、面向客户的服务（Customer Facing Service，CFS）、面向资源的服务（Resource Facing Service，RFS）和资源（Resource，RES）。运营商可以通过云网协同器先行实现RFS 和RES 层面的编排协同，然后根据需要在云网协同器增加CFS层面的编排协同能力，或者由上层业务平台实现CFS 层面的编排协同。具体说明如下。

P：Product，产品是面向客户提供最小可销售单元的功能和操作能力，产品涉及的网络属性和网络服务通过服务层获取。

S：Service，服务分为2层，包含CFS和RFS。

CFS：面向客户的服务，指的是客户可感知的端到端网络通信能力，由面向云网资源的服务组装而成，包括点到点、点到网等能力。CFS 由一个或多个RFS组合而成，CFS 与CFS 之间可存在嵌套关系。CFS 一般是跨网络域或跨业务域的。

RFS：面向资源的服务，指的是各通信网络、云资源提供的云网能力，由云网资源提供的原子能力组装而成，也可直接出租给客户，包括5GC、PON、城域网、骨干网、省内/本地传输网、云资源池IaaS/PaaS 等提供的业务服务。RFS由一个或多个RES提供的原子能力组装而成，RFS一般是某个网络域或业务域内的。

R 或RES：Resource，资源是网络中涉及的物理资源（网络设备、线路等）、逻辑资源（IP、端口、链路、VLAN、码号等）、网元（UPF、UDM、PCF 等）、虚拟资源（虚拟机、容器等）、业务平台等的总称。

电信业务的产品层、服务层和资源层的分层模型架构如图1所示。

图1 TMF PSR分层架构

3.2.2 基于ONAP和TMF架构的演进方法

基于ONAP/TMF 的编排架构，云网协同器分为设计态和运行态2 个独立的工作区。在设计态工作区，部署云网资源（RES）对象、云网能力（RFS）对象、业务流程、API 接口、服务策略的编排设计模块，包括面向RFS、RES的对象设计、编排协同流程设计、API接口设计和服务策略设计，生成基于TOSCA 模型和工作流模板的编排包（即CSAR文件）。

将编排包文件加载到运行态工作区，通过编排包就绪模块进行编排包校验和测试验证，再通过服务接收和实例化，逆向逐层解析（即把1个RFS 对象分解为若干个RES 对象并实例化），最后将分解后的面向南向各个域控制器的API接口指令按照设计态工作区设定的工作流顺序下发给各个域控制器执行。云网协同器功能模块图如图2所示。

图2 云网协同器功能模块

在此基础上，在各方面条件成熟的时候可进行下一步部署，包含但不限于如下情况。

a）运营商的业务/应用进一步丰富，2B/2C/2H 业务进一步融合，业务灵活编排组合或各业务之间嵌套的需求进一步凸显。

b）ONAP相关架构、技术和组件进一步完善，使用经验更加丰富，相关应用案例和应用场景进一步丰富。

c）人员支撑和整合更有保障，人员具备可进行CFS/RFS/RES 全栈的设计、编排、开发、测试和运维的能力。

d）原有业务已完成迁移到云网协同器进行处理。

在以上条件满足时，可考虑将业务/应用编排流程（即CFS）基于新的ONAP架构部署实施，包括2种可选的实施方式。

方式1：在现有的云网协同器平台架构内增加部署独立的CFS设计、编排、测试模块，并与现有的RFS、RES 设计、编排、测试流程整合，具体设计内容包括如下2种情况。

a）基于云网协同器已有的和新增的RFS 对象进行编排组合，形成CFS。如图3 所示，在设计态将RFS1/RFS2/RFS3 进行编排设计，构建生成CFS1 编排包，然后将编排包加载到运行态，当在运行态进行CFS1 编排包调用时，将CFS1 解析为RFS1/RFS2/RFS3，并执行后续解析和实例化操作。

图3 基础的CFS设计和编排

b）基于a）已有的CFS/RFS 对象进行编排组合或嵌套，形成新的内容更为丰富、较为复杂的CFS。如图4 所示，在设计态将RFS4/RFS5/CFS1 进行编排设计，构建生成CFS2 编排包，然后将编排包加载到运行态。当在运行态进行CFS2 编排包调用时，将CFS2 解析为RFS4/RFS5/CFS1，然后再进一步将CFS1 解析为RFS1/RFS2/RFS3，并执行后续解析和实例化操作。

图4 复杂的CFS设计和编排

升级后的云网编排协同器将成为一个功能完备的、全栈的业务和能力编排协同器，即具备CFS/RFS/RES的设计、编排运行能力，其北向对接现有的业务受理平台（比如订单平台），承载业务开通指令；东西向对接资源管理系统，负责业务开通相关资源的申请；南向对接各个域控制器，负责对底层网元、平台的数据配置。云网协同器升级后，待已有业务完全割接到云网协同器后，可将现网的调度、服务开通系统逐步退出服务。升级后的云网编排协同器功能模块图如图5所示。

图5 升级后的云网协同器功能模块

需说明的是，新增加的CFS 层与现有RFS/RES 层完全融合，在设计态工作区将对象设计、业务流程设计、策略设计、API 设计和编排包构建模块完全整合在一起，在运行态工作区将编排包就绪、服务接收、实例分解、业务流程执行和策略执行模块完全整合在一起。先在设计态基于RES→RFS→CFS 的顺序进行建模并结合工作流技术构建编排包，然后将设计态工作区构建的编排包加载到运行态工作区，通过编排包就绪模块进行编排包校验和测试，接着通过服务接收和实例化，按照设计的工作流流程，逐层逆向解析（即先把1 个CFS 对象分解为若干个RFS 对象，再把每个RFS 对象分解为若干个RES 对象，并进行实例化），最后将分解后的面向南向各个域控制器的API接口指令按照设计的工作流流程下发给各个域控制器执行。

方式2：升级现有的调度、服务开通系统为业务编排平台，以支持CFS 设计、编排、测试功能，或参考ONAP/TMF 架构理念，另外独立部署业务/应用编排平台，负责CFS 层面的设计、编排和测试，该平台南向通过REST API与云网协同器对接，直接调用云网协同器的RFS/RES 编排能力，从而最终完成目标ONAP 架构的部署。待已有业务完全割接到业务/应用编排平台后，可将现网的调度、服务开通系统逐步退出服务。业务编排平台的具体设计内容包括如下2种情况。

a）业务/应用编排平台的CFS 由若干个RFS 对象组成，业务/应用编排平台按照设定的业务流程将CFS拆解成RFS，然后直接调用云网协同器的RFS/RES 编排能力。

b）业务/应用编排平台的CFS 由若干个较为简单的CFS 和RFS 对象嵌套组成，在业务/应用编排平台按照设定的业务流程将复杂的CFS 拆解成RFS，然后直接调用云网协同器的RFS/RES编排能力。

升级后的业务编排平台东西向对接资源管理系统，负责云网资源的核实分配，升级后的业务层和能力层设计编排功能模块如图6所示。

图6 升级后的业务层和能力层设计编排功能模块

本文提出的云网协同运营支撑架构分层解耦、分步部署的演进方法，具有现实可行、平滑升级、灵活扩展、经济节约等特点，可以为运营商的云网协同运营支撑系统架构向ONAP/TMF 架构转型的分步部署实施提供清晰的路径指引和参考。运营商可以根据业务需求、技术成熟度、平台建设进度和人员支撑情况，自主掌控云网协同运营支撑系统架构演进进度。

4 结束语

本文介绍了一种分层解耦、分步部署的云网协同运营支撑系统架构演进方法，在云网运营支撑系统架构的设计和部署上将云网资源/能力编排协同层与云网业务/应用编排协同层分离解耦，先将云网资源/能力编排协同层参考ONAP/TMF 架构理念进行部署，再根据需要将云网业务/应用编排协同层迁移到ONAP/TMF 架构。本文介绍的方法可以为运营商的云网协同运营支撑系统架构向ONAP/TMF 架构转型的分步部署实施提供清晰的路径指引和参考。