向意图驱动的自智 网络服务管理演进

网络中的自智程度，是根据运营决策制定以及在网络中实施这些决策所需的人为干预量来衡量的，并以零接触(Zero-Touch)范式作为最终目标。

走向自智网络，可以通过具备以下特性的网络运营来实现：数据驱动、自我感知、自我修复、自我优化、解决冲突、持续学习、自适应和主动前瞻。自智网络的特点在于其能够:

• 持续监控所有相关指标
• 对自身的状态进行推理分析，识别
• 需要改进的问题和机会
• 自动查找和应用解决方案
• 不断寻求优化其状态
• 发现并缓解相互冲突的需求
• 从观察中学习
• 适应新的情况和要求
• 预测、预见和避免问题

理想情况下，人与自智网络的互动应限于告知网络预期应达成的目标，然后退回到监控状态以确保网络按预期运行。任何需要进一步人为干预的情况都会降低其自主性。这些情况不仅可能是由于网络错误而引起的，也可能是由于新产品和新服务的引入导致的，或是由于网络发生变化(如升级或资源扩容)带来的。高效的自智网络将能在这些情况下进行自我调整。

意图(Intent)的概念

将运营需求作为独立的信息对象进行表达和管理是迈向自智网络的一个关键步骤。这种方法提高了抽象层次的同时，也将需求对应的理论知识、与服务编排和保障解决方案提供的需求处理进行了分离。到目前为止，服务管理中建立和保障的服务特性和行为需求，都被定义为服务水平目标（Service Level Objectives，SLO）。SLO是在服务目录中作为重要组成工件实现其生命周期管理的。然而，SLO在服务管理的典型实现中，与编排和保障结合使用的方式是相对静态的。SLO通常是人为确定和管理的工件。此外，由SLO表达的需求变化并不会传递到现有的服务和资源实例中。它们只在服务创建和配置时被考虑。

意图是一类基于需求承载的认知对象的演进产物。意图具有一个基于应用程序编程接口(API)的动态生命周期，这些API专门设计用于允许自动化系统在相关服务及其派生服务实例的生命周期中、按需动态设置和修改需求。通过意图表达的需求变更，预期将立即对已部署的服务和资源实例产生影响，并使其遵从新需求。这种对实例层面的影响，是传统的SLO和基于意图的系统之间的关键区别。SLO承载与服务相关的需求，然而意图在此基础上还预期服务实例将适应意图的变化。据此设计服务编排和保障，是服务管理向基于意图运营过渡的一个核心挑战。

TM论坛、3GPP (3rd Generation Partnership Project)等各种标准组织定义的Intent API规定了检查可行性、协商需求和提供保证的方法。基于意图的操作也被嵌入在自智网络的通用架构中，在该架构中，自动化意图管理器在相互之间使用意图进行需求沟通，并使用意图报告对需求的满足程度提供反馈。

需要注意的是，意图不一定与特定的服务绑定。除了为网络域提供通用性要求，意图可以引入服务和产品需要遵守的附加要求，以间接影响它们的处理方。然而，近期将意图纳入专用服务管理API的做法，已成为推动核心商业流程、服务编排和保障实现向意图驱动系统演进的关键因素。作为承载需求的工件，意图将补充或取代SLO。因此，实现服务管理解决方案需要演进，以支持意图需求的动态化。

自智网络架构

根据TM论坛提出的通用架构，自智网络被细分为多个自治域。这些自治域被分配在网络运营软件堆栈的各层内，例如业务层、服务层或资源层。在一个层内可以并存多个自治域，或者这些自治域也会存在于更多的子层级中。

基于这个通用架构，自治域在整个自智网络中持有特定的职责。自治域之间使用意图、通过设置需求进行交互。一种通用的工作方式是：每个自治域都有自己需要实现和优化的最终目标，为了达到该目标，此自治域同时需要其他自治域的贡献和遵循特定需求。在我们层级化的意图管理方法中，意图将会在这些不同层级间用于需求的沟通和管理。

自智网络中的每个自治域都将实现意图管理并包含一个意图管理器，该意图管理器通过认知闭环实现。意图管理器是使用意图来设置需求的相互通信实体。同时，意图管理器还与其领域内的其他功能进行协作，以确定如何实现需求。

自治域中的意图管理器，是基于意图的操作中涉及的关键实体。每个意图都严格定义有一个所有者(Owner)和一个处理程序(Handler)角色。如果意图管理器定义了另一个域需要遵循的需求，那么它就扮演了意图所有者的角色（Owner）。反之，如果它接收到自己的域中必须遵守的需求，那么它就在承担意图处理程序（Handler）的角色。图1右侧显示了意图管理器在业务层、服务层和资源操作层的分配情况。

图1：分层意图管理架构中的产品和服务分解

意图API演进

意图管理器使用API来管理意图中表达的需求。TM论坛已经发布了TMF921 API，用于通用的意图管理。它具体规范化了意图所有者(Owner)和处理程序(Handler)之间的通信方式，同时还定义了如提供意图、报告合规状态、修改需求和删除意图等主要操作，以及诸如请求提案、提供反馈或检查需求可行性等高级操作。

TM论坛目前正基于爱立信在自智网络领域贡献的广泛研究和开发成果，将意图管理能力集成到其现有的产品和服务管理API、以及其开放数字架构（Open Digital Architecture）之中。API集成过程涉及几个关键改变。首先是在服务目录中添加了带有产品和服务规范链接的意图规范说明。相关的API是TMF620（产品目录管理），和即将发布的TMF633和TMF634版本（服务和资源目录管理）。

第二个关键变化是在服务订购阶段获取意图值和参照变量。当与订购的产品及其相应的面向客户的服务(CFS)相关联时，这些意图就是业务意图。在订购用于实现产品的服务时，这些意图将转化为操作性意图。TMF622被用于在产品订购中传递意图，TMF641则是用于服务订购，这些API还将允许意图实现生命周期管理(LCM)，包括动态修改和删除。

第三个关键变化是在基于意图的系统中创建了一个新的操作⸺意图报告，它创建了一个需求处理成功时的隐式反馈渠道。创建报告期望，也被定义为TMF622和TMF641订购API的一部分。意图处理程序（Handler）将负责根据报告期望组装意图报告，并使该信息可提供给意图所有者（Owner）和/或外部使用。TMF679 API（产品供应）和TMF645 API（服务资格）中额外定义的意图资质检查是另一个重要的变化，这使得根据意图说明检查意图的有效性成为可能。最后，还需要做出意图维护能力的改变，在实例级别的产品和服务注册中予以能力实现，并对应到各自的产品和服务实例中。

将意图的概念引入到服务管理API中，对于当前业务流程的无缝过渡、以及意图的逐步引入来说是非常重要的。更进一步的意图管理能力将在后续引入，这将使意图满足度的可行性分析、意图需求协商、以及如何要求和提供保证等成为可能，也许将基于意图资质检查、或服务订单、或通过专用的TMF921意图API开放接口等方式来实现。

基于意图的服务管理

服务管理领域的起点是要说清楚什么是意图，因为这是网络运营的核心点，意图也是自治化网络运营的前提。

上述图1的左侧部分，介绍了自智网络各个层级间如何分配产品和服务、及其各自意图。业务意图管理器，是由核心业务功能所实现的。在产品订购过程中，业务意图将在核心业务功能中被获取。当产品订单被解析为服务订单时，业务意图也必须被解析、并在多个层级中转化为服务意图。第一个解析步骤必须在面向客户服务(CFS)这个级别中进行：这是客户在订购产品时所考虑的服务需求，这也是传统的需求级别（也称之为SLO）。

图2提供了一个示例，说明如何在后续解析过程中使用意图所提供的信息。端到端(E2E)服务意图管理器将以交付期望机制为原则。交付期望，将指定需要交付的内容，并提供与之相关的细节。基于意图的产品/服务将被分析细化到需要用于交付的面向客户服务(CFS)集合。

图2：从带有示例的意图内引用服务

更多产品维度的意图中所提出的需求，例如资源期望和基于关键KPI所设置的条件，将被分配到面向客户服务(CFS)的具体意图中执行。

将面向用户服务(CFS)解析为适当的面向资源服务(RFS)、并关联到运营意图上，是位于服务操作层的端到端服务意图管理器的职责。该意图管理器涉及服务编排等功能。

面向资源服务(RFS)通常是对用户不可见的。这意味着端到端服务意图管理器可以更自由地组合合适的服务。意图内的交付期望机制具有一定的灵活性，可以指定要使用的具体服务，也可以无需指定要使用的具体服务、而只对所需功能类型进行松散分类。面向客户服务(CFS)中的意图期望，将用于描述合适的面向资源服务(RFS)的属性选项。

例如，基于CFS的服务级业务意图可能会提出需要一项通信服务，要求的端到端时延为100ms。端到端服务级意图管理器可以选择满足要求的网络切片级服务，并指定无线接入网必须满足60ms的时延要求。因此，意图管理器会选择与所需功能匹配的面向资源服务(RFS)，并将端到端需求分解为特定领域的要求。

资源域意图管理器接收RFS下发的订单指令。意图与面向资源服务(RFS)相关联时，被称为操作意图而不是业务意图。此级别的意图管理器负责进一步的解析，从而对应特定于领域的操作。这方面的例子可以是对网络资源的供应和配置操作，或者，向支持意图感知的资源和网络功能发送进一步的意图。

在服务管理中逐步引入意图

将意图引入服务管理需要一个多阶段的平稳演进的过程，而不是全部推倒重来。通信服务提供商必须在不干扰现行业务连续性的情况下调整并升级其编排域和业务保障域。

图3阐释了我们对意图感知服务管理的分阶段演进的建议。起点是第0阶段:基于SLO的编排和保障。在此阶段，对服务特征的需求已经从服务订单中被解析出来，并通过SLO进行具体的表述。服务编排器使用基于特定服务的策略，来分析和决定如何根据SLO定义的需求提供与之对应的配置和网络。

主要工具如TOSCA(云应用程序的拓扑和编排规范)和业务流程建模表示法(BPMN, Business Process Modeling Notationdeined)可以用于指导编排器(Orchestrator)的工作。编排器还具备了自动化监控和自恢复能力以保证服务流程。

图3：意图感知服务管理的阶段性演进

在第0阶段中，既不使用意图，也不使用涉及基于意图的动态服务实例生命周期管理、或在服务实例的生命周期中进行意图内容的动态修改。这是为了保持与当前产品和服务管理流程的兼容性。随着时间的推移，产品和服务管理可以向多个阶段持续演进，以引入这些意图概念。

第1阶段：基于意图的保障

第1阶段，如图3的下半部所示，将遵循TM Forum定义的与意图相关的产品和服务管理可选扩展进行。在服务操作中引入意图的概念，逐步取代传统固化的SLO。业务意图细节是由核心商务流程与面向客户服务(CFS)订单一起通过TMF641服务化API获取的，这个API将使订购服务和管理各自的意图成为可能。这不是强制要求用户在订购产品时就必须开始捕获其业务意图，但是提供了获取意图的可能性。最新版本的TMF622产品订单管理API已经支持此功能。

意图的详细说明收录于产品和服务目录中，并与产品和服务的详细说明相关联。使用TMF679或TMF645API，意图资质鉴定可以与意图说明对应的产品或服务资质鉴定一起完成。进一步的意图可行性检查和需求协商操作可以使用TMF921意图API、或使用TMF645作为资质鉴定的一部分来执行。意图实例与端到端服务是持续进行的，并且意图需求的生命周期必须与服务一起管理。

端到端服务编排器将应用目录中的信息进行组合，以决定需要配置或实例化的面向资源服务(RFS)，并基于意图定义的需求来决定资源供给。相对第0阶段，第1阶段的重大变化是引入意图感知保障闭环。编排器将基于TMF921API把意图装备在保障闭环中，实现业务保障。这可以是按顺序接收的相同需求，也可以是基于特定服务和资源的额外需求。相关的意图报告将通知到服务水平协议（Service Level Agreement）管理系统，提供服务质量和需求满足的状况。

基于意图的闭环业务保障的主要任务是监控操作域并确保其符合操作意图需求。它将通过一套测量分析设施进行观察，并采取符合意图的行动，例如，通过网络管理重新配置资源，或通过编排器修改服务或订购额外的服务。一个自适应的、意图驱动的业务控制闭环可以很好地实现这一目标。

在这个阶段，可以引入如效用最大化决策等高级功能。这个概念使用意图来传达“效用”信息。效用，是在意图中特指的一个概念，它是通过将观测到的指标数值映射到规范化分数的方式来实现的。这个分数体现了一个指标的观测值有多大的价值。基于效用的决策，是指根据资源可用性和当前有效需求选择最有价值的可替代解决方案。因此，它也能很好地解决冲突问题。

上述提到的概念和组件，包括意图本身，都是非必须项，也就是说，阶段1的引入意图的过渡可以逐步完成，并且可以在单个用例或者单项功能的基础上完成过渡。例如，意图可以用于新的用例和那些对动态需求有要求的服务，而对于已建立的服务则可以继续基于SLO。

第2阶段:基于意图的组合和服务选择

在基于意图的业务保障体系建立之后，下一阶段是意图处理功能在意图管理器层级中的配置。图3显示意图处理功能的配置可以是一个独立的流程(RFS的选择/组合)，但在现实中，它们是作为编排器的一部分实现的。因此，带有意图的服务指令将在意图管理层内终止。进一步的决策完全基于所述意图需求的实现情况而定。

如果未满足意图要求，系统将触发纠正措施进行闭环处理。在这种情况下，一个典型的解决方案可能涉及编排器，并根据订购的服务提供额外的资源。作为该解决方案的一部分，意图管理器可以选择需要使用的面向资源服务(RFS)集，并确定每个后续资源域的意图需求细化。

相反，如果意图表达的所有需求都已经得到满足，就无需任何额外行动。然
后，意图管理器将立即进入监控状态并且在需求不再被满足之前不会采取
更多行动。向意图的过渡可以逐步完成，并以每个用例和特性为基础。

在服务层的意图管理器实现中，所有的操作决策，包括最初的实现和随后的保证、修复和优化，都是为了解决网络无法以最优方式满足所有需求的情况。这些操作决策行为可能涉及资源配置、选择和编排RFS，或者将CFS意图中接收到的需求解析为特定于资源领域的意图。这意味着，基于意图的服务组合提供了一个基于动态服务组合的灵活层级，并可持续监控和优化。第2阶段还会引入非常重要的系统层级解耦和分离的概念，因为用于实现客户需求和交付客户所期望服务的资源对客户不可见、也无法在客户订购服务或产品时直接得到明确。相反，自治服务层将根据可用的RFS寻求解决方案，以最佳地利用资源。这也意味着服务管理系统将不会被绑定服务于预定义紧耦合的方案实现中。这是一个基于人工智能算法的环境，具有寻找创造性解决方案和进行人力所不能及
的优化潜力，可以提供巨大的价值。

第3阶段:适应现有的面向资源的服务实例

第2阶段中引入的基于意图的服务组合功能可以灵活地使用RFS，但依然需要从预定义的服务目录中进行选择。第3阶段中，其思想是服务实例本身可以实现自演进。自智网络可以引入新的服务管理构件，或对现有构件进行变异，以更好地体现可用资源。此外，对资源使用和配置的更改可以通过修改服务实例来实现。在此阶段，自智网络具有充分的自适应能力，可以重塑现有服务实例，使其能够承载新服务的需求。

例如，新的资源可能由新的业务合作伙伴提供。他们也可能提供更好的扩展能力或更快的响应时间，或者从总拥有成本(TCO)的角度来看更高效。通过添加新的资源详细说明和相关的RFS说明，这些新资源将可提供给编排功能使用。新的服务订单可以立即使用这些资源，在已部署的资源和服务实例中进行新资源替换、也是有价值的。

在第3阶段的演进中，自智网络可以决定重塑现有的服务实例，在实例可回收时，将其转换为新的资源。将服务实例转换为新资源的决策将是意图处理功能做出的优化性决策，该功能持续提供新的可替代解决方案，以改善系统状态并提高业务价值。这种动态重构的过程导致更高级别的意图实现和更高的业务效用。换句话说，一旦新资源可用，意图管理功能将以优化潜能为目地去实现它。这实际上涉及到服务管理系统对服务的重组。这种动态自适应是自智网络的关键能力。

结论

很明显，创建高质量的零接触自智网络将需要在网络运营和服务管理方面进行重大变革，但我们的研究表明，随着时间的推移，随着自治水平的提高，逐步引入必要的变革是可能的。自适应能力的实现往往具有挑战性，需要将人工智能方法与各类接口和架构结合使用，以加强网络运营层之间的抽象化和关注点分离。服务管理为这一目的提供了很好的资源抽象，特别是和基于意图的交互式动态需求管理相结合时。

爱立信在服务管理演进过程中的分阶段方法论，使通信服务提供商能够根据自己的市场情况、商业模式和战略，以自己的节奏踏上这段旅程。我们目前只建议那些需要从灵活的需求处理中获利的服务和网络领域、引入基于意图的运营。其他场景用例可以保持现状。在第一阶段，有可能在不改变现有服务管理流程的情况下，从自智网络技术中获得优势。大多数现有的服务管理构件和流程都可以在基于意图的系统中复用，直到有明确的业务需
求出现可作进一步演进。