通信服务建模原则和典型场景研究

[谢晓军 石彦彬 喻琦]

1 引言

通信服务提供商（Communication Service Provider，CSP）企业数据模型（Enterprise Data Model，EDM）重视产品（Product）和资源（Resource）的建模和管理，长久以来对服务（Service）建模都较为忽视，无论是面向客户的服务（Customer Facing Service，CFS）还是面向资源的服务（Resource Facing Service，RFS）[1]。每次网络升级换代，CSP为抢占市场先发优势，尽量缩短产品上市时间，直接基于网络资源进行产品设计和实现，在设备采购和安装完成后迅速将产品推向市场。于是EDM只对产品模型和资源模型进行构建，升级业务支撑系统（Business Supporting System，BSS）和运营支撑系统（Operation Support System，OSS）后，迅速实现业务的受理、开通和计费。但随着网络和业务的演进和发展，也会暴露出越来越多的问题。采用一案一议的业务加载方案，解决了业务支撑问题，但是网络能力可复用性和开放性较差。如果基于存量网络资源设计新产品，一方面由于缺乏对资源必要的抽象，新产品设计需要了解很多网络实现细节，沟通成本高，设计难度大；另一方面，由于没有对资源进行统一的划分和组织，新产品在推广时也会碰到很多场景差异，成本和效率都难以令人满意。随着SDN/NFV技术快速发展，越来越多的网络服务（Network Service，NS）被显式的编排和管理[2]，比如5G推出的网络切片[3]。在此基础上，CSP着力推进云网融合战略，希望能够比照基础设施即服务（Infrastructure as a Service，IaaS），将资源抽象组合成服务，以网络即服务（Network as a Service，NaaS）的形式交付产品，使网络产品达到云产品（如虚机、容器和存储等）一致的客户体验。

TM Forum共享信息数据（Shared Information/Data，SID）作为模型框架，定义了一套从产品到服务、再到资源的完整模型要素和关联方式，但CSP还需要根据自身通信业务运营特点和标准开发组织（Standards Development Organization，SDO）拟定的实现架构对具体的通信服务模型进行构建，以满足网络运营、新产品研发和OSS建设的需要。本文针对服务模型的识别、区分和构建等问题，分析服务的定位及作用，基于服务建模需求探讨服务建模原则，最后给出供参考的典型场景。

2 服务概述

2.1 服务概念

在以服务形式交付产品之前，服务很多时候被建模成产品或资源的附属活动，尤其跟人工活动相关，泛指按预定步骤执行的流程活动。但是，TM Forum在SID框架中提出的服务概念[1]却早就不止于此，它还包括更加重要的由网络设备提供的通信服务，如连接服务。这一概念与ITIL定义的服务概念比较接近，只不过一个是电信服务（Telecommunications Service），一个是IT服务（IT Service）[4]。

不过ITIL体系不存在产品的概念，服务也是产品。TM Forum SID则不同，产品是对市场销售相关概念的抽象[1]，比如产品的开发、促销、定价和下架，以及客户和其他人购买的产品实例。服务和资源是对产品实现方式的抽象，如图1所示。当然，服务也可以直接面向市场进行销售，但它需被包装成产品。这是“面向客户”的服务CFS和“面向资源”的服务RFS之间本质区别。

图1 产品、服务和资源（PSR）关系图[1]

底层的资源为网络功能虚拟化构建了逻辑资源的子类——资源功能（Resource Function，RF）[12]，可用于抽象和封装ETSI定义的虚拟化网络功能（Virtual Network Function，VNF）和NS[10]，IETF定义的服务功能和服务功能链（Service Function Chain，SFC）[11]，以及路由器和内容分发网络（Content Delivery Network，CDN）等物理网络功能（Physical Network Functions，PNF）。同时，对连接模式的RF进行了深入分析[13]。

如图1所示，服务的作用是衔接产品和资源。一方面，让产品和资源的关联关系变得更加灵活，既可以提升资源的利用率，也可以增加产品设计的灵活性，缩短产品加载时间；另一方面，实现了产品和资源的解耦，既可以屏蔽技术发展导致的资源变化对前端产品体系的冲击，也可以屏蔽前端营销体系的调整对后端运营维护体系的影响。

2.2 服务交付

TM Forum定义数字服务参考架构（Digital Services Reference Architecture，DSRA）[5]支持以服务的形式交付产品，并建议采用平台（Platform）[6]作为其实现方式。作为服务交付的主体——高内聚的功能块，它不仅拥有自己的属性数据，还有可以被调用的操作流程，并通过标准接口向外提供，同时它还包含团队和系统。

建模过程将交付主体抽象成一个黑盒的平台，通过OpenAPI[7]暴露平台能力。然后基于开放数字架构（Open Digital Architecture，ODA）框架对这些不同服务的实现平台进行集成，比如针对5G业务[8]，规划了交付服务管理和编排（Production Service Management& Orchestration）、资源服务管理和编排（Resource Service Management & Orchestration）和技术域（Technical Domain）等平台。其中交付服务管理和编排平台围绕操作域（Operational Domain）[9]实现CFS交付，这里的操作域是指包含一组网络资源功能实例的操作和管理边界，与前述的高内聚功能块对应，对外提供标准接口。底层的技术域根据SDO，比如3GPP，或者供应商的实现方式定义其功能范围和对外接口。中间的资源服务管理和编排平台实现RFS交付，将底层的技术域映射和集成到上层的操作域。

CSP无论是否以服务的形式交付产品，网络架构和运营体系都一定会进行技术域和操作的划分，既然它们是服务提供的主体，也就为CFS/RFS/RF的识别、区分和构建提供了帮助。其中由SDO和供应商确定的技术域划分，可以是网络分段（如接入、回传和核心），也可以是网络分层（如IP、以太网和光传输），CFS/RFS/RF可以按照这些技术域或者它们的组合进行规划和设计。CSP根据运营管理要求将这些技术域纳入到不同操作域进行统一管理，不同操作域之间可能会重叠和交叉，这会给CFS/RFS/RF规划和设计带来一定的困难，要做到不重不漏，横向到边（分段），纵向到底（分层），需要进行一定的调整和剪裁。

3 服务建模

3.1 建模需求

服务建模的主要目的是定义技术中立的服务模型，具体需求包括：服务模型要能够对不同技术体制或者不同供应商技术实现进行抽象，定义独立于资源的服务，使得底层技术的演进和发展尽量不要影响向上层暴露服务接口的稳定性；服务模型要能够支持不同技术体制（SDO派生出的RFS）与不同供应商技术实现间的模型映射和转换，与底层资源进行关联；服务模型要能够支持将连接服务分解到不同操作域，也可以将不同操作域服务组合成端到端服务，即使涉及其他CSP；服务模型能够支持基于意图驱动，通过操作域内的闭环控制来实现；服务模型能够支持多层级的编排，每一层都能够提供基于意图的服务，内部实现闭环控制、策略管理、人工智能等自动化技术。

为满足上述需求，CSP服务建模重点是服务目录库和服务实例库所需模型，如图2所示。左边是服务模型静态部分，包括CFS/RFS的服务规格CSP_XXX_ServiceSpec模型和存于服务目录库的特定服务CSP_XXX_Service模型；右边是服务动态部分，包括与服务订单相关的资源功能规格CSP_XXX_RFSpec模型和存于服务实例库具体客户的特定服务CSP_XXX_RF。另外ServiceSpecification、Service、ResouceFunctionSpec和ResourceFunction父类是由SID定义的，作为CSP服务模型的框架和参考。

图2 CSP服务模型概览

3.2 建模原则

为满足上述需求，在服务建模过程中CFS/RFS/RF识别、区分和构建等建议考虑以下原则，以确定其必要性和合理性。

① 基于技术域的划分及其连接和承载关系拟定备选服务

技术域的划分主要是参考SDO定义的技术体制，相对容易达成共识，作为服务建模的起点比较合适。比如移动数据接入方面，按照3GPP给出的高层参考架构[3]可以定义无线接入网、回传网和核心网三项技术域服务。是否作为CFS/RFS/RF还要根据操作域的划分进行进一步确认。

② 围绕操作域规划服务规格种类

基于不同技术域的备选服务会纳入到操作域进行管理，有时情况会有不同。比如在骨干网，光传输和IP分属不同操作域，可以视为不同CFS/RFS/RF；而在宽带接入方面，如果光传输及其承载的以太网和IP属于同一个操作域统一管理，且没有共享需要，则可以视为一个完整的CFS/RFS/RF。同时，相同的技术域，也可以根据不同的操作域抽象出不同的CFS/RFS/RF，比如按接入、汇聚和骨干划分。

③ 通过RFS建模实现服务的串接、承载和选择

原则上CFS用于屏蔽不同技术体制的差异，RFS用于屏蔽不同供应商实现方式的差异。实际上，CSP通常会要求供应商按照SDO定义的标准组网，因此会在资源建模中尽量屏蔽技术实现的差异。RFS定义更多的作用主要针对网络分段的串接，网络分层的承载，以及不同技术体制选择的情况。

④ 根据CSP为客户提供的产品定义客户可见的CFS

根据技术域和操作域划分拟定了服务，还需要根据其是否直接面向客户提供确定其服务类型，CFS或者RFS。例如宽带接入服务，根据技术不同可以分为ADSL接入、以太网接入和PON接入。为屏蔽接入技术差异，可将宽带服务建模为CFS，而将ADSL接入服务、以太网接入服务和光纤接入服务分别建模为RFS。

⑤ 将连接服务建模成资源功能RF

作为将资源建模为服务（即RFS）的另一种方法，对功能相同的传统网络设备或网络应用程序进行功能建模，更便于虚拟化，可以通过灵活的组合来支持产品或服务。它们支持使用模板文件将表达抽象意图的服务与底层技术关联起来，参见IG1194[14]。

⑥ 将能够独立部署的功能单元建模成RF

有时服务是由一组独立部署的网元提供的，则可以将它们建模成RF。比如5G核心网RFS，就是由UDM、PCF、AMF、SMF、UPF等网元提供的，可以把这些网元建模为RF。如果支持切片，还可以进一步将这一组网元RF组合成切片实例RF。围绕RF，配以交付和管理能力可以构成RFS（可选），然后组合成CFS交付给最终客户。

⑦ 在服务定义的边界范围内能够实现闭环控制

为实现服务的闭环控制，以此可以划定维护团队、网络设备或者管理系统的范围边界，虽然不一定形成严格的黑盒，即使会有两个服务共享团队、设备或者系统的情况，也可以进一步明确其职责划分和资源分配。在这个边界内共享闭环控制、策略管理和人工智能等功能，并通过标准的接口向外暴露服务能力。

⑧ 在服务定义的边界范围内外采取不同数据一致性策略

闭环控制形成的服务边界可以成为事务一致性的边界，与边界之外的服务需要的话只能实现最终一致性，如果不能接受，那就需要重新考虑服务边界问题，或者重新为服务建模。可以选择将两个服务合并，或者构建一个公共的新服务，形成分层依赖关系，通过CFS/RFS/RF的OpenAPI[7]进行访问。

4 典型场景

以5G为例，为客户提供移动数据通信服务，可以定义移动数据通信CFS，通过移动数据通信产品提供给客户，如图3所示。从技术实现上讲，移动数据通信服务可以有4G和5G等不同技术体制，因此可以定义4G数据通信RFS和5G数据通信RFS。具体到5G数据通信RFS，根据3GPP给出的架构，可以分为接入网、回传网和核心网3个技术域，如果分别由不同操作域运营维护，可以分别定义4G核心网RFS、回传网（如IPRAN）RFS和5G接入网RFS，另外基站作为网元可以在资源层中定义（图中未画出）。5G通信服务是通过网络切片提供的，可以将切片实例定义为资源层的RF，比如图3中的核心网切片实例，该切片实例还可以包含若干网元，如NRF、UDM、PCF、AMF、SMF和UPF等，都可以定义为RF。另外NSSF作为跨切片的网元定义成独立的RF。

图3 5G CFS/RFS/RF示意图

上述建模过程中，没有为客户建立的每一个协议数据单元（Protocol Data Unit，PDU）会话连接进行建模，主要是因为CSP一般不会将这些动态建立的连接纳入支撑系统管理，如果需要也可以将其定义为连接服务RF[13]。这里再分析一个含连接服务建模的场景：PON云专网。该业务在为用户提供虚拟专网产品基础上，还可以为后续增加新的接入点提供接入侧的普通补点和云测补点等产品，如图4所示。

图4 PON云专网 CFS/RFS/RF示意图

其中虚拟专网产品由IP VPN CFS提供，考虑骨干网和城域网技术实现和运营维护的差异分别定义骨干网RFS和城域网RFS，用以支持IP VPN CFS等业务。定义RFS的目的一方面是为了使上层不同的CFS可以共享该服务，如客户已开通PON接入的固定入网专线，在加装宽带、固话时可以直接复用PON链路RFS，只需要配置城域网接入VLAN通道RFS即可实现业务开通。另一方面可以针对MPLS或者SR等不同技术实现上的差异定义不同种类的RFS。

类似的情况也适用于普通补点产品，为数据接入专线CFS实现定义了PON链路RFS，同时还可以考虑IPRAN伪纤RFS和VLAN通道RFS等。而对于承接云侧补点产品的到云专线CFS，一般采用VLAN接入，且由云管理平台同一配置，因此定义VLAN RF直接由上层CFS进行组合并向用户提供服务。与此同时，还在资源层既定义了连接模式的光路、隧道和VLAN等RF，以及ONU、ASBR和PE等面向PNF的RF，以满足上层CFS/RFS的需要。

5 结束语

本文以5G和云网融合的PON云专网为例，针对CFS/RFS/RF的识别、区分和构建等问题，分析服务的定位及作用，基于服务建模需求探讨服务建模原则，最后按照TM Forum SID框架给出了5G相关CFS/RFS/RF建模示例，为CSP通信服务CFS/RFS/RF定义提供参考。然而TM Forum SID作为模型框架，还有支持多种方式实现通信服务的建模，还需要笔者在未来的建模实践中深入研究，并加以优化。