CN114915929A

CN114915929A - 确定策略的方法和通信装置

Info

Publication number: CN114915929A
Application number: CN202110179154.1A
Authority: CN
Inventors: 周晓云; 朱奋勤
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2021-02-09
Filing date: 2021-02-09
Publication date: 2022-08-16
Also published as: WO2022170798A1

Abstract

本申请提供了一种确定策略的方法和通信装置。该方法可以包括：第一网元接收来自第二网元的请求消息，该请求消息包括应用所需的业务链的信息；第一网元根据该应用所需的业务链的信息，为应用制定业务链策略，并且向第三网元发送该应用对应的业务链策略。这样，当确定要提供应用增值服务的情况下，可以在请求消息中将所需的业务链的相关信息通知给第二网元，从而第二网元可以根据该所需的业务链的信息，直接制定业务链策略，从而可以快速响应对业务链的快速变化的需求。

Description

确定策略的方法和通信装置

技术领域

本申请涉及通信技术领域，尤其涉及一种确定策略的方法和通信装置。

背景技术

在一些***中，如第五代(5th generation，5G)***中，用户接入网络后建立协议数据单元(protocol data unit，PDU)会话(PDU session)，并通过PDU会话访问外部数据网络，与部署在数据网络中的应用服务器交互。通过部署移动服务增值网络，即提供业务链的方式，可以为用户提供质量体验(quality of experience，QoE)，减少网络带宽压力。如何能够满足对业务链的快速变化的需求是亟需解决的问题。

发明内容

本申请提供一种确定策略的方法和通信装置，以期可以快速响应对业务链的快速变化的需求。

第一方面，提供了一种确定策略的方法，该方法可以由网络设备执行，或者，也可以由用于网络设备的芯片、芯片***或电路执行，本申请对此不作限定。为了便于描述，下面以由第一网元执行为例进行说明。

该方法可以包括：第一网元接收来自第二网元的第一请求消息，第一请求消息包括应用所需的业务链的信息；第一网元向第三网元发送应用对应的业务链策略，应用对应的业务链策略是根据应用所需的业务链的信息制定的。

示例地，该第一网元例如可以为策略控制功能(policy control function，PCF)网元、或者拜访地策略控制功能(visited-policy control function，V-PCF)网元等。

示例地，该第二网元例如可以为应用功能(application function，AF)网元、或者能力开放功能(network exposure function，NEF)网元等。

示例地，该第三网元例如可以为会话管理功能(session management function，SMF)网元，或者其它可以实现该网元功能的网络设备。

示例地，第一请求消息可以为数据导向消息，或者也可以为服务质量请求消息。

示例地，方法还可以包括：根据应用所需的业务链的信息，制定应用对应的业务链策略。制定应用对应的业务链策略，例如可以理解为，对用户访问的应用制定业务导向策略(traffic steering policy，TSP)。

基于上述技术方案，当确定要提供应用增值服务的情况下，在请求制定业务链策略时，可以携带应用所需的业务链的信息。从而，第一网元可以根据请求中携带的应用所需的业务链的信息确定是否授权，或者第一网元可以直接根据请求中携带的应用所需的业务链的信息来制定业务链策略。从而，可以快速响应应用对业务链的快速变化需求。

结合第一方面，在第一方面的某些实现方式中，应用所需的业务链的信息为应用所需的业务链标识。

基于上述技术方案，第一网元可以基于应用所需要的业务链标识，制定应用对应的业务链策略。

结合第一方面，在第一方面的某些实现方式中，应用所需的业务链的信息为应用所需的一个或多个业务功能的信息。

基于上述技术方案，第一网元可以基于应用所需要的一个或多个业务功能的信息，制定应用对应的业务链策略。

结合第一方面，在第一方面的某些实现方式中，方法还包括：第一网元根据应用所需的一个或多个业务功能的信息，确定支持应用的一个或多个业务功能的信息，并向第二网元发送支持应用的一个或多个业务功能的信息。

基于上述技术方案，第一网元可以基于应用所需要的一个或多个业务功能的信息，确定支持应用的一个或多个业务功能的信息，例如，该支持应用的一个或多个业务功能，属于应用所需的一个或多个业务功能中的部分业务功能。从而第二网元可以基于第一网元支持的一个或多个业务功能的信息，进行灵活调整和处理。

结合第一方面，在第一方面的某些实现方式中，一个或多个业务功能的信息，为一个或多个业务功能的标识或类型。

基于上述技术方案，业务功能可以用标识或类型来标识。

结合第一方面，在第一方面的某些实现方式中，第一网元接收来自第二网元的第一请求消息，第一请求消息包括应用所需的业务链的信息，包括：第一网元接收来自第二网元的第一请求消息，第一请求消息包括应用所需的业务链的信息与数据网络接入标识之间的对应关系。

也就是说，第一请求消息中包括的应用所需的业务链的信息具体为，应用所需的业务链的信息与数据网络接入标识之间的对应关系。

一示例，第一请求消息中具体包括应用所需的业务链标识与数据网络接入标识之间的对应关系。

又一示例，第一请求消息中具体包括应用所需的一个或多个业务功能与数据网络接入标识之间的对应关系。

基于上述技术方案，可以在第一请求消息中携带应用所需的业务链的信息与数据网络接入标识之间的对应关系，这样可以根据应用所需的业务链的信息确定应用对应的业务链策略，进而可以得到业务链策略与数据网络接入标识之间的对应关系。

结合第一方面，在第一方面的某些实现方式中，第一网元向第三网元发送应用对应的业务链策略与数据网络接入标识之间的对应关系。

示例地，应用对应的业务链策略与数据网络接入标识之间的对应关系，是根据应用所需的业务链的信息与数据网络接入标识之间的对应关系确定的。

结合第一方面，在第一方面的某些实现方式中，方法还包括：第一网元向第四网元发送第二请求消息，第二请求消息包括应用对应的业务链策略和访问应用的用户的标识，第二请求消息用于请求对用户访问的应用对应的业务链策略进行授权。

基于上述技术方案，在有些场景下，如在漫游场景下，第一网元根据请求制定业务链策略后，可以向第四网元发送该业务链策略，以便进行第四网元的进一步授权。

结合第一方面，在第一方面的某些实现方式中，方法还包括：在第一网元向第四网元发送第二请求消息之前，方法还包括：第一网元接收第三网元发送的第一数据网络接入标识，第一网元根据第一数据网络接入标识确定用户访问应用对应的业务链策略；或者，第一网元接收第三网元发送的用户访问应用对应的业务链策略。

示例地，应用对应的业务链策略与数据网络接入标识之间具有对应关系，该数据网络接入标识包括第一数据网络接入标识。

结合第一方面，在第一方面的某些实现方式中，方法还包括：第一网元向第四网元发送第三请求消息，第三请求消息包括支持的一个或多个业务功能的信息和访问应用的用户的标识，第三请求消息用于请求对用于访问的应用支持的一个或多个业务功能的信息进行授权。

基于上述技术方案，在有些场景下，如在漫游场景下，第一网元根据请求确定支持的业务功能后，可以向第四网元发送该业务功能的信息，以便进行第四网元的进一步授权。

结合第一方面，在第一方面的某些实现方式中，在第一网元向第四网元发送第三请求消息之前，方法还包括：第一网元接收第三网元发送的第一数据网络接入标识，根据第一数据网络接入标识确定支持用户访问的应用的一个或多个业务功能；或者，第一网元接收第三网元发送的用户访问应用对应的业务链策略，根据用户访问应用对应的业务链策略确定支持用户访问的应用的一个或多个业务功能。

第二方面，提供了一种确定策略的方法，该方法可以由网络设备执行，或者，也可以由用于网络设备的芯片、芯片***或电路执行，本申请对此不作限定。为了便于描述，下面以由第二网元执行为例进行说明。

该方法可以包括：向第一网元发送第一请求消息，第一请求消息包括应用所需的业务链的信息；接收来自第一网元的指示信息，指示信息用于指示接受应用所需的业务链的请求。

示例地，该第二网元例如可以为AF网元、或者NEF网元等。

基于上述技术方案，当确定要提供应用增值服务的情况下，在请求制定业务链策略时，可以携带应用所需的业务链的信息。从而，可以使得第一网元根据请求中携带的应用所需的业务链的信息确定是否授权，或者直接根据请求中携带的应用所需的业务链的信息来制定业务链策略。相比于需要依靠运营商策略来为应用制定业务链策略的方案，本申请实施例提供的方案能够快速响应应用对业务链的快速变化需求。

结合第二方面，在第二方面的某些实现方式中，应用所需的业务链的信息为以下任一项：应用所需的业务链标识、应用所需的外部业务链标识、应用所需的一个或多个业务功能的信息、应用所需的一个或多个外部业务功能的信息、应用所需的业务链的信息与数据网络接入标识之间的对应关系。

结合第二方面，在第二方面的某些实现方式中，方法还包括：第二网元接收来自第一网元的支持应用的一个或多个业务功能的信息。

示例地，应用所需的业务链的信息为应用所需的一个或多个业务功能的信息。

结合第二方面，在第二方面的某些实现方式中，方法还包括：第二网元接收来自第一网元的支持应用的一个或多个外部业务功能的信息。

示例地，应用所需的业务链的信息为应用所需的一个或多个外部业务功能的信息。

结合第二方面，在第二方面的某些实现方式中，一个或多个业务功能的信息，为一个或多个业务功能的标识或类型。

结合第二方面，在第二方面的某些实现方式中，在向第一网元发送第一请求消息之前，方法还包括：第二网元向第五网元发送第二请求消息，第二请求消息包括查询的业务链的信息；第二网元接收来自第五网元的支持查询的业务链的以下一项或多项信息：业务功能标识、业务链标识、业务功能标识和数据网络接入标识对应关系、业务链标识和数据网络接入标识对应关系。

示例地，查询的业务链的信息包括查询的业务功能的类型。

基于上述技术方案，第二网元可以动态请求业务链。例如，第二网元可通过查询获得相应的业务功能或业务链。

第三方面，提供了一种确定策略的方法，该方法可以由网络设备执行，或者，也可以由用于网络设备的芯片、芯片***或电路执行，本申请对此不作限定。为了便于描述，下面以由第五网元执行为例进行说明。

该方法可以包括：第五网元接收来自第二网元的请求消息，请求消息包括应用所需的业务链的信息；第五网元对应用所需的业务链的信息进行处理，并向第一网元发送处理后的业务链的信息。

示例地，该第五网元例如可以为NEF网元，或者其它可以实现该网元功能的网络设备。

基于上述技术方案，第二网元通过第五网元请求应用所需要的业务链处理时，在请求的信息中可以携带应用所需的业务链的信息，然后该第五网元可以先对该应用所需的业务链的信息进行处理，然后将处理后的信息发送给第一网元。这样，可以实现第一网元基于第二网元的请求，确定对应的业务链策略，或者说进行授权。从而，能够快速响应应用对业务链的快速变化的需求。

结合第三方面，在第三方面的某些实现方式中，应用所需的业务链的信息为应用所需的外部业务链标识，第五网元对应用所需的业务链的信息进行处理，包括：第五网元将外部业务链标识，映射为内部业务链标识；第五网元向第一网元发送处理后的业务链的信息，包括：第五网元向第一网元发送内部业务链标识。

结合第三方面，在第三方面的某些实现方式中，应用所需的业务链的信息为应用所需的外部业务功能的信息，第五网元对应用所需的业务链的信息进行处理，包括：第五网元将外部业务功能，映射为内部业务功能；第五网元向第一网元发送处理后的业务链的信息，包括：第五网元向第一网元发送内部业务功能的信息。

结合第三方面，在第三方面的某些实现方式中，方法还包括：第五网元根据应用所需的一个或多个外部业务功能的信息，确定支持应用的一个或多个外部业务功能的信息，并向第二网元发送支持应用的一个或多个外部业务功能的信息。

结合第三方面，在第三方面的某些实现方式中，一个或多个外部业务功能的信息，为一个或多个外部业务功能的标识或类型。

结合第三方面，在第三方面的某些实现方式中，应用所需的业务链的信息为应用所需的外部业务链标识与数据网络接入标识之间的对应关系，或者，应用所需的业务链的信息为应用所需的一个或多个外部业务功能与数据网络接入标识之间的对应关系。

结合第三方面，在第三方面的某些实现方式中，应用所需的业务链的信息为应用所需的外部业务链标识与数据网络接入标识之间的对应关系，第五网元对应用所需的业务链的信息进行处理，包括：第五网元将外部业务链标识，映射为内部业务链标识；第五网元向第一网元发送处理后的业务链的信息，包括：第五网元向第一网元发送应用所需的内部业务链标识与数据网络接入标识之间的对应关系。

结合第三方面，在第三方面的某些实现方式中，应用所需的业务链的信息为应用所需的外部业务功能与数据网络接入标识之间的对应关系，第五网元对应用所需的业务链的信息进行处理，包括：第五网元将外部业务功能，映射为内部业务功能；第五网元向第一网元发送处理后的业务链的信息，包括：第五网元向第一网元发送应用所需的内部业务功能与数据网络接入标识之间的对应关系。

结合第三方面，在第三方面的某些实现方式中，方法还包括：第五网元接收来自业务链管理设备的注册请求消息，该注册请求消息中包括注册的业务链的以下一项或多项信息：业务功能类型和业务功能标识的对应关系、业务功能类型和外部业务链标识的对应关系、业务功能类型、业务功能标识和数据网络接入标识的对应关系、业务功能标识、外部业务链标识和数据网络接入标识的对应关系的对应关系。

第四方面，提供了一种确定策略的方法，该方法可以由网络设备执行，或者，也可以由用于网络设备的芯片、芯片***或电路执行，本申请对此不作限定。为了便于描述，下面以由第三网元执行为例进行说明。

该方法可以包括：第三网元接收来自第一网元的应用对应的业务链策略与数据网络接入标识之间的对应关系的信息，其中，数据网络接入标识包括第一数据网络接入标识；第三网元根据第一数据网络接入标识选择用户面网元，并指示用户面网元执行第一业务链策略，第一业务链策略为第一数据网络接入标识对应的业务链策略。

示例地，该第三网元例如可以为SMF网元，或者其它可以实现该网元功能的网络设备。

结合第四方面，在第四方面的某些实现方式中，方法还包括：第三网元向第一网元发送第一数据网络接入标识；或者，第三网元向第一网元发送第一业务链策略。

第五方面，提供了一种确定策略的方法，该方法可以由网络设备执行，或者，也可以由用于网络设备的芯片、芯片***或电路执行，本申请对此不作限定。为了便于描述，下面以由第一网元执行为例进行说明。

该方法可以包括：第一网元向第四网元发送请求消息，请求消息用于请求对一个或多个业务功能进行授权，或者，请求消息用于请求对应用对应的业务链策略进行授权；第一网元接收来自第四网元的该请求消息的响应消息。

示例地，该第一网元例如可以为V-PCF网元等，或者其它可以实现该网元功能的网络设备；该第四网元例如可以为归属地策略控制功能(home-policy control function，H-PCF)网元等，或者其它可以实现该网元功能的网络设备。

第六方面，提供了一种确定策略的方法，该方法可以由网络设备执行，或者，也可以由用于网络设备的芯片、芯片***或电路执行，本申请对此不作限定。为了便于描述，下面以由第四网元执行为例进行说明。

该方法可以包括：第四网元接收来自第一网元的请求消息，请求消息用于请求对一个或多个业务功能进行授权，或者，请求消息用于请求对应用对应的业务链策略进行授权；第四网元向第一网元发送该请求消息的响应消息。

例如，第四网元进行授权后，发送指示接受的确认信息。

基于上述技术方案，在有些场景下，如在漫游场景下，第一网元根据请求制定业务链策略后，可以向第四网元发送该业务链策略，以便进行第四网元的进一步授权。或者第一网元根据请求确定支持的业务功能后，可以向第四网元发送该业务功能的信息，以便进行第四网元的进一步授权。

结合第五方面或第六方面，在某些实现方式中，第一网元向第四网元发送请求消息，请求消息包括应用对应的业务链策略和访问该应用的用户的标识，该请求消息用于请求对用户访问的应用对应的业务链策略进行授权。

结合第五方面或第六方面，在某些实现方式中，第一网元向第四网元发送请求消息，请求消息包括一个或多个业务功能的信息和访问应用的用户的标识，该请求消息用于请求对用户访问的应用的一个或多个业务功能的信息进行授权。

第七方面，提供了一种业务链管理的方法，该方法可以由网络设备执行，或者，也可以由用于网络设备的芯片、芯片***或电路执行，本申请对此不作限定，为了便于描述，下面以由第五网元执行为例进行说明。

该方法可以包括：第五网元接收来自第二网元的请求消息，请求消息包括查询的业务链的信息；第五网元向第二网元发送响应消息，该响应消息用于指示支持的业务链的信息。

示例地，方法还可以包括：第五网元接收来业务链管理设备(service chainmanager)的注册请求消息，该注册请求消息中包括注册的业务链的以下一项或多项信息：业务功能类型和业务功能标识的对应关系、业务功能类型和外部业务链标识的对应关系、业务功能类型、业务功能标识和数据网络接入标识的对应关系、业务功能标识、外部业务链标识和数据网络接入标识的对应关系的对应关系。

第八方面，提供了一种业务链管理的方法，该方法可以由网络设备执行，或者，也可以由用于网络设备的芯片、芯片***或电路执行，本申请对此不作限定，为了便于描述，下面以由第二网元执行为例进行说明。

该方法可以包括：第二网元向第五网元发送请求消息，请求消息包括查询的业务链的信息；第二网元接收来自第五网元的响应消息，该响应消息用于指示支持的业务链的信息。

结合第七方面或第八方面，在某些实现方式中，请求消息中携带的查询的业务链的信息，包括：需要的业务功能(service function)的类型以及数据网络接入标识信息。

示例地，第五网元可以根据数据网络接入标识信息，返回数据网络接入标识对应支持的service function或者业务链标识以及包括的service function类型。

示例地，第五网元可以根据service function的类型，返回对应的servicefunction标识或是业务链标识以及包括的service function类型。

第九方面，提供一种通信装置，该装置用于执行上述第一方面至第八方面提供的方法。具体地，该装置可以包括用于执行第一方面至第八方面提供的方法的单元和/或模块，如处理单元和/或通信单元。

在一种实现方式中，该装置为网络设备。当该装置为网络设备时，通信单元可以是收发器，或，输入/输出接口；处理单元可以是处理器。

在另一种实现方式中，该装置为用于网络设备中的芯片、芯片***或电路。当该装置为用于通信设备中的芯片、芯片***或电路时，通信单元可以是该芯片、芯片***或电路上的输入/输出接口、接口电路、输出电路、输入电路、管脚或相关电路等；处理单元可以是处理器、处理电路或逻辑电路等。

一可能情况，该装置为第一网元或第一网元中的芯片、芯片***或电路。在该情况下，该装置可以包括用于执行第一方面、第五方面提供的方法的单元和/或模块，如处理单元和/或通信单元。

又一可能情况，该装置为第二网元或第二网元中的芯片、芯片***或电路。在该情况下，该装置可以包括用于执行第二方面、第八方面提供的方法的单元和/或模块，如处理单元和/或通信单元。

又一可能情况，该装置为第三网元或第三网元中的芯片、芯片***或电路。在该情况下，该装置可以包括用于执行第四方面提供的方法的单元和/或模块，如处理单元和/或通信单元。

又一可能情况，该装置为第四网元或第四网元中的芯片、芯片***或电路。在该情况下，该装置可以包括用于执行第六方面提供的方法的单元和/或模块，如处理单元和/或通信单元。

又一可能情况，该装置为第五网元或第五网元中的芯片、芯片***或电路。在该情况下，该装置可以包括用于执行第三方面、第七方面提供的方法的单元和/或模块，如处理单元和/或通信单元。

可选地，上述收发器可以为收发电路。可选地，上述输入/输出接口可以为输入/输出电路。

第十方面，提供一种通信装置，该装置包括：存储器，用于存储程序；处理器，用于执行存储器存储的程序，当存储器存储的程序被执行时，处理器用于执行上述第一方面至第八方面提供的方法。

在一种实现方式中，该装置为网络设备(如上述各个网元)。

在另一种实现方式中，该装置为用于网络设备(如上述各个网元)中的芯片、芯片***或电路。

第十一方面，本申请提供一种处理器，用于执行上述各方面提供的方法。在执行这些方法的过程中，上述方法中有关发送上述信息和获取/接收上述信息的过程，可以理解为由处理器输出上述信息的过程，以及处理器接收输入的上述信息的过程。在输出上述信息时，处理器将该上述信息输出给收发器，以便由收发器进行发射。该上述信息在由处理器输出之后，还可能需要进行其他的处理，然后才到达收发器。类似的，处理器接收输入的上述信息时，收发器获取/接收该上述信息，并将其输入处理器。更进一步的，在收发器收到该上述信息之后，该上述信息可能需要进行其他的处理，然后才输入处理器。

基于上述原理，举例来说，前述方法中提及的接收请求消息可以理解为处理器接收输入的信息。

对于处理器所涉及的发射、发送和获取/接收等操作，如果没有特殊说明，或者，如果未与其在相关描述中的实际作用或者内在逻辑相抵触，则均可以更加一般性的理解为处理器输出和接收、输入等操作，而不是直接由射频电路和天线所进行的发射、发送和接收操作。

在实现过程中，上述处理器可以是专门用于执行这些方法的处理器，也可以是执行存储器中的计算机指令来执行这些方法的处理器，例如通用处理器。上述存储器可以为非瞬时性(non-transitory)存储器，例如只读存储器(Read Only Memory，ROM)，其可以与处理器集成在同一块芯片上，也可以分别设置在不同的芯片上，本申请实施例对存储器的类型以及存储器与处理器的设置方式不做限定。

第十二方面，提供一种计算机可读存储介质，该计算机可读介质存储用于设备执行的程序代码，该程序代码包括用于执行上述第一方面至第八方面提供的方法。

第十三方面，提供一种包含指令的计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述第一方面至第八方面提供的方法。

第十四方面，提供一种芯片，所述芯片包括处理器与通信接口，所述处理器通过所述通信接口读取存储器上存储的指令，执行上述第一方面至第八方面提供的方法。

可选地，作为一种实现方式，所述芯片还可以包括存储器，所述存储器中存储有指令，所述处理器用于执行所述存储器上存储的指令，当所述指令被执行时，所述处理器用于执行上述第一方面至第八方面提供的方法。

第十五方面，提供一种通信***，包括以下一项或多项：第一网元、第二网元、第三网元、第四网元、第五网元。

附图说明

图1示出了适用于本申请实施例的网络架构的一示意图。

图2示出了适用于本申请实施例的网络架构的另一示意图。

图3是本申请一实施例提供的一种确定策略的方法300的示意图。

图4是根据本申请另一实施例提供的一种确定策略的方法400的示意图。

图5是适用于本申请一实施例的确定策略的一示意性流程图。

图6是适用于本申请一实施例的确定策略的又一示意性流程图。

图7是适用于本申请一实施例的确定策略的又一示意性流程图。

图8是适用于本申请一实施例的确定策略的又一示意性流程图。

图9是适用于本申请一实施例的确定策略的又一示意性流程图。

图10是适用于本申请一实施例的确定策略的又一示意性流程图。

图11是适用于本申请实施例的业务链管理的示意性流程图。

图12是根据本申请实施例提供的通信装置的示意性框图。

图13是根据本申请实施例提供的通信装置的另一示意性框图。

图14是本申请实施例提供的一种通信装置的结构示意图。

具体实施方式

下面将结合附图，对本申请中的技术方案进行描述。

本申请实施例的技术方案可以应用于各种通信***，例如：第五代(5thgeneration，5G)***或新无线(new radio，NR)、长期演进(long term evolution，LTE)***、LTE频分双工(frequency division duplex，FDD)***、LTE时分双工(time divisionduplex，TDD)等。本申请提供的技术方案还可以应用于未来的通信***，如第六代移动通信***。本申请实施例的技术方案还可以应用于设备到设备(device to device，D2D)通信，车辆外联(vehicle-to-everything，V2X)通信，机器到机器(machine to machine，M2M)通信，机器类型通信(machine type communication，MTC)，以及物联网(internet ofthings，IoT)通信***或者其他通信***。

为便于理解本申请实施例，首先结合图1和图2详细说明适用于本申请实施例的通信***。

作为示例性说明，图1示出了适用于本申请实施例的网络架构的一示意图。如图1所示，该网络架构例如可以包括但不限于以下：用户设备(user equipment，UE)、接入网(access network，AN)、接入和移动性管理功能(access and mobility managementfunction，AMF)网元、会话管理功能(session management function，SMF)网元、用户面功能(user plane function，UPF)网元、策略控制功能(policy control function，PCF)网元、统一数据管理(unified data management，UDM)网元、应用功能(applicationfunction，AF)、数据网络(data network，DN)等。

下面对图1中示出的各网元做简单介绍：

1、终端设备：可以称为用户设备(user equipment，UE)、接入终端、用户单元、用户站、移动站、移动台(mobile station，MS)、移动终端(mobile terminal，MT)、远方站、远程终端、移动设备、用户终端、终端、无线通信设备、用户代理或用户装置。终端设备可以是一种向用户提供语音/数据连通性的设备，例如，具有无线连接功能的手持式设备、车载设备等。目前，一些终端的举例可以为：手机(mobile phone)、平板电脑(pad)、带无线收发功能的电脑(如笔记本电脑、掌上电脑等)、移动互联网设备(mobile internet device，MID)、虚拟现实(virtual reality，VR)设备、增强现实(augmented reality，AR)设备、工业控制(industrial control)中的无线终端、无人驾驶(self driving)中的无线终端、远程医疗(remote medical)中的无线终端、智能电网(smart grid)中的无线终端、运输安全(transportation safety)中的无线终端、智慧城市(smart city)中的无线终端、智慧家庭(smart home)中的无线终端、蜂窝电话、无绳电话、会话启动协议(session initiationprotocol，SIP)电话、无线本地环路(wireless local loop，WLL)站、个人数字助理(personal digital assistant，PDA)、具有无线通信功能的手持设备、计算设备或连接到无线调制解调器的其它处理设备、车载设备、可穿戴设备，5G网络中的终端设备或者未来演进的公用陆地移动通信网络(public land mobile network，PLMN)中的终端设备等。

此外，终端设备还可以是物联网(Internet of things，IoT)***中的终端设备。IoT是未来信息技术发展的重要组成部分，其主要技术特点是将物品通过通信技术与网络连接，从而实现人机互连，物物互连的智能化网络。IoT技术可以通过例如窄带(narrowband，NB)技术，做到海量连接，深度覆盖，终端省电。

此外，终端设备还可以包括智能打印机、火车探测器、加油站等传感器，主要功能包括收集数据(部分终端设备)、接收网络设备的控制信息与下行数据，并发送电磁波，向网络设备传输上行数据。

应理解，终端设备可以是任何可以接入网络的设备。终端设备与接入网设备之间可以采用某种空口技术相互通信。

可选地，UE可以用于充当基站。例如，UE可以充当调度实体，其在V2X或D2D等中的UE之间提供侧行链路信号。比如，蜂窝电话和汽车利用侧行链路信号彼此通信。蜂窝电话和智能家居设备之间通信，而无需通过基站中继通信信号。

2、接入网(access network，AN)：接入网可以为特定区域的授权用户提供入网功能，包含无线接入网(radio access network，RAN)设备和AN设备。RAN设备主要是第三代合作伙伴计划(3rd Generation Partnership Project，3GPP)网络无线网络设备，AN设备可以是非3GPP(non-3GPP)定义的接入网设备。

接入网络可以为采用不同接入技术的接入网络。目前的无线接入技术有两种类型：3GPP接入技术(例如3G、4G或5G***中采用的无线接入技术)和非3GPP(non-3GPP)接入技术。3GPP接入技术是指符合3GPP标准规范的接入技术，例如，5G***中的接入网设备称为下一代基站节点(next generation Node Base station，gNB)或者RAN。非3GPP接入技术是指不符合3GPP标准规范的接入技术，例如，以无线保真(wireless fidelity，WiFi)中的接入点(access point，AP)为代表的空口技术、全球互联微波接入(worldwideinteroperability for microwave access，WiMAX)、码分多址(code division multipleaccess，CDMA)网络等。接入网设备(AN设备)可以允许终端设备和3GPP核心网之间采用非3GPP技术互连互通。

基于无线通信技术实现接入网络功能的接入网可以称为RAN。无线接入网能够负责空口侧的无线资源管理、服务质量(quality of service，QoS)管理、数据压缩和加密等功能。无线接入网为终端设备提供接入服务，进而完成控制信号和用户数据在终端和核心网之间的转发。

无线接入网例如可以包括但不限于：宏基站、微基站(也称为小站)、无线网络控制器(radio network controller，RNC)、节点B(Node B，NB)、基站控制器(base stationcontroller，BSC)、基站收发台(base transceiver station，BTS)、家庭基站(例如，homeevolved NodeB，或home Node B，HNB)、基带单元(baseband unit，BBU)，WiFi***中的AP、无线中继节点、无线回传节点、传输点(transmission point，TP)或者发送接收点(transmission and reception point，TRP)等，还可以为5G(如，NR)***中的gNB或传输点(TRP或TP)，5G***中的基站的一个或一组(包括多个天线面板)天线面板，或者，还可以为构成gNB或传输点的网络节点，如基带单元(BBU)，或，分布式单元(distributed unit，DU)，或者下一代通信6G***中的基站等。本申请实施例对无线接入网设备所采用的具体技术和具体设备形态不做限定。

接入网可以为小区提供服务。终端设备可以通过接入网设备分配的传输资源(例如，频域资源，或者说，频谱资源)与小区通信。

3、AMF网元：主要用于移动性管理和接入管理等，如用户位置更新、用户注册网络、用户切换等。AMF还可用于实现移动性管理实体(mobility management entity，MME)中除会话管理之外的其它功能。例如，合法监听、或接入授权(或鉴权)等功能。

4、SMF网元：主要用于会话管理、UE的网际协议(Internet Protocol，IP)地址分配和管理、选择可管理用户平面功能、策略控制、或收费功能接口的终结点以及下行数据通知等。在本申请实施例中，SMF主要用户负责移动网络中的会话管理，如会话建立、修改、释放等。具体功能例如可以包括为终端设备分配IP地址、选择提供报文转发功能的UPF等。

5、UPF网元：负责终端设备中用户数据的转发和接收。UPF网元可以从数据网络(data network，DN)接收用户数据，通过接入网设备传输给终端设备。UPF网元还可以通过接入网设备从终端设备接收用户数据，转发到数据网络。UPF网元中为终端设备提供服务的传输资源和调度功能由SMF网元管理控制的。

6、PCF网元：用于指导网络行为的统一策略框架，为控制平面功能网元(例如AMF，SMF网元等)提供策略规则信息，负责获取与策略决策相关的用户签约信息等。

7、AF网元：主要支持与3GPP核心网交互来提供服务，例如影响数据路由决策、与策略控制功能(PCF)交互、或者向网络侧提供第三方等。

8、UDM网元：用于生成认证信任状，用户标识处理(如存储和管理用户永久身份等)，接入授权控制和签约数据管理等。

9、数据网络(DN)：用于为用户提供数据服务的服务网络。例如，因特网(Internet)、第三方的业务网络、IP多媒体服务业务(IP multi-media service，IMS)网络等。

在图1所示的网络架构中，各网元之间可以通过图中所示的接口通信，部分接口可以采用服务化接口的方式实现。如图1所示，UE和AMF之间可以通过N1接口进行交互，交互消息例如可以称为N1消息(N1 Message)。RAN和AMF之间可以通过N2接口进行交互，N2接口可以用于非接入层(non-access stratum，NAS)消息的发送等。RAN和UPF之间可以通过N3接口进行交互，N3接口可以用于传输用户面的数据等。SMF和UPF之间可以通过N4接口进行交互，N4接口可以用于传输例如N3连接的隧道标识信息，数据缓存指示信息，以及下行数据通知消息等信息。AF与PCF之间可以通过N5接口进行交互，N5接口可以用于应用业务请求下发以及网络事件上。UPF和DN之间可以通过N6接口进行交互，N6接口可以于传输用户面的数据等。PCF与SMF之间可以通过N7接口进行交互，N7接口可以用于下发协议数据单元(protocoldata unit，PDU)会话(PDU session)粒度以及业务数据流粒度控制策略等。AMF与UDM之间可以通过N8接口进行交互，N8接口可以用于AMF向UDM获取接入与移动性管理相关签约数据与鉴权数据，以及AMF向UDM注册UE当前移动性管理相关信息等。SMF与UDM之间可以通过N10接口进行交互，N10接口可以用于SMF向UDM获取会话管理相关签约数据，以及SMF向UDM注册UE当前会话相关信息等。SMF与AMF之间可以通过N11接口进行交互，N11接口可以用于传递RAN和UPF之间的PDU会话隧道信息、传递发送给UE的控制消息、传递发送给RAN的无线资源控制信息等。PCF与AMF之间可以通过N15接口进行交互，N15接口可以用于下发UE策略及接入控制相关策略等。其他接口与各网元之间的关系如图1中所示，为了简洁，这里不一一详述。

应理解，上述应用于本申请实施例的网络架构仅是示例性说明，适用本申请实施例的网络架构并不局限于此，任何能够实现上述各个网元的功能的网络架构都适用于本申请实施例。

还应理解，图1中所示的AMF、SMF、UPF、PCF、UDM等可以理解为用于实现不同功能的网元，例如可以按需组合成网络切片。这些网元可以各自独立的设备，也可以集成于同一设备中实现不同的功能，或者可以是硬件设备中的网络元件，也可以是在专用硬件上运行的软件功能，或者是平台(例如，云平台)上实例化的虚拟化功能，本申请对于上述网元的具体形态不作限定。

还应理解，上述命名仅为便于区分不同的功能而定义，不应对本申请构成任何限定。本申请并不排除在5G网络以及未来其它的网络中采用其他命名的可能。例如，在6G网络中，上述各个网元中的部分或全部可以沿用5G中的术语，也可能采用其他名称等。

还应理解，图1中的各个网元之间的接口名称只是一个示例，具体实现中接口的名称可能为其他的名称，本申请对此不作具体限定。此外，上述各个网元之间的所传输的消息(或信令)的名称也仅仅是一个示例，对消息本身的功能不构成任何限定。

在一些***中(如5G***中)，UE接入网络后建立PDU会话，并通过PDU会话访问外部数据网络DN，与部署在DN中的应用服务器交互。根据用户访问的DN不同，网络可以根据网络策略选择接入DN的UPF作为锚点(anchor)，如记为PDU会话锚点(PDU session anchor，PSA)，并通过PSA的N6接口访问应用服务器。运营商或者第三方应用提供商可以部署移动服务增值网络，为用户提供质量体验(quality of experience，QoE)，减少网络带宽压力，并提供增值服务。

作为示例性说明，图2示出了适用于本申请实施例的网络架构的另一示意图。

图2主要以一种局域网(local area network，LAN)(如N6-LAN)的动态业务链的方案以适应于弹性的快速的服务部署变动，同时降低资本支出(capital expenditure，CAPX)的架构为例进行了示例性说明。以图2所示的架构为例，PCF可以对用户访问的应用制定数据导向策略(traffic steering policy，TSP)。TSP规则通常包括业务数据流描述信息以及对应的业务链(service chain)标识。UPF对业务数据进行检测后，将对应业务链标识标记在业务数据流的数据包上。交换机(switch)将根据业务链标识，将数据包动态的导向到相应的业务功能(service function)节点，也称使能器(enabler)。如图2所示，switch1根据业务链标识，将数据包动态的导向到相应的业务功能节点1和业务功能节点2上，switch 2根据业务链标识，将数据包动态的导向到相应的业务功能节点3和业务功能节点4上。

在现有方式中，PCF通常是根据用户的签约和运营商配置的策略制定TSP。这种方式，动态业务链的调整周期相对较长，不能快速响应应用对业务链的快速变化的需求。

本申请提供一种方法，能够快速响应应用对业务链的快速变化需求。应理解，本申请实施例不仅可以适用于上述图1和图2所示的架构，也可以适用于其他架构，对此不作限定。例如，本申请实施例可以适用于网络设备为应用制定业务链的策略的任何场景中；又如，本申请实施例可以适用于为应用部署业务链的任何场景中。

下面将结合附图详细说明本申请提供的各个实施例。

图3是本申请一实施例提供的一种确定策略的方法300的示意图。方法300可以包括如下步骤。

310，第二网元向第一网元发送请求消息#1，该请求消息#1包括应用所需的业务链的信息。相应地，第一网元接收该请求消息#1。

应理解，请求消息#1是为区分做的命名，其命名不对本申请实施例的保护范围造成限定。

应用所需的业务链的信息，例如可以包括但不限于：应用所需的业务链标识(service chain identifier，SC Id)、应用所需的外部业务链标识(external servicechain identifier，external SC Id)、应用所需的一个或多个业务功能(servicefunction)的信息、应用所需的一个或多个外部service function的信息、应用所需的业务链的信息与数据网络接入标识(data network access identification，DNAI)之间的对应关系、或应用对应的业务链策略的信息。作为示例而非限定，应用所需的业务链的信息与DNAI之间的对应关系，例如可以为应用所需的业务链标识与DNAI之间的对应关系，或者可以为应用所需的一个或多个业务功能与DNAI之间的对应关系。具体地，下文详细介绍。

可选地，方法300还可以包括步骤320。

320，第一网元根据应用所需的业务链的信息，确定应用对应的业务链策略。

通过本申请实施例，当需要提供应用增值服务的情况下，在发送请求时，可以携带应用所需的业务链的信息。从而，可以根据请求中携带的应用所需的业务链的信息确定是否授权，或者直接根据请求中携带的应用所需的业务链的信息来制定业务链策略。相比于需要依靠运营商策略来为应用制定业务链策略的方案，本申请实施例提供的方案能够快速响应应用对业务链的快速变化需求。

应理解，本申请实施例关于第一网元和第二网元的具体形式不作限定。在需要提供应用增值服务的情况下，第二网元表示请求的设备，如第二网元在请求消息#1中携带应用所需的业务链的信息；第一网元表示授权的设备或者确定业务链策略的设备，如第一网元根据请求消息#1中携带的应用所需的业务链的信息，授权或者制定业务链策略。

作为示例而非限定，第一网元例如可以为PCF，或者也可以为V-PCF，等等，对此不作限定。第二网元例如可以为AF，或者也可以为能力开放功能(network exposurefunction，NEF)，等等，对此不作限定。

作为示例而非限定，下面介绍几种可能的实现方式。

实现方式1，应用所需的业务链的信息包括应用所需的业务链标识，第一网元根据应用所需的业务链标识，确定应用对应的业务链策略。

一示例，第一网元为PCF，第二网元为AF。例如，AF向PCF发送应用所需的业务链标识，PCF根据应用所需的业务链标识，确定应用对应的业务链策略。

又一示例，第一网元为PCF，第二网元为NEF。例如，NEF接收应用所需的外部业务链标识，如NEF接收来自AF的应用所需的外部业务链标识。NEF将应用所需的外部业务链标识映射为内部业务链标识(即业务链标识)，并且将该内部业务链标识发送给PCF。PCF根据应用所需的业务链标识，确定应用对应的业务链策略。

实现方式2，应用所需的业务链的信息包括应用所需的一个或多个业务功能的信息，第一网元根据应用所需的一个或多个业务功能的信息，确定应用对应的业务链策略。其中，业务功能的信息，例如可以包括业务功能的标识和/或业务功能的类型。

一示例，第一网元为PCF，第二网元为AF。例如，AF向PCF发送应用所需的业务功能的信息，PCF根据应用所需的业务功能的信息，确定应用对应的业务链策略。

又一示例，第一网元为PCF，第二网元为NEF。例如，NEF接收应用所需的外部业务功能的信息，如NEF接收来自AF的应用所需的外部业务功能的信息。NEF将应用所需的外部业务功能映射为内部业务功能(即业务功能)，并且将该内部业务功能的信息发送给PCF。PCF根据应用所需的内部业务功能的信息，确定应用对应的业务链策略。

实现方式3，应用所需的业务链的信息包括应用所需的业务链标识与DNAI之间的对应关系，第一网元根据应用所需的业务链标识与DNAI之间的对应关系，确定应用对应的业务链策略。

一示例，第一网元为PCF，第二网元为AF。例如，AF向PCF发送应用所需的业务链标识与DNAI之间的对应关系，PCF根据应用所需的业务链标识与DNAI之间的对应关系，确定应用对应的业务链策略。

又一示例，第一网元为PCF，第二网元为NEF。例如，NEF接收应用所需的外部业务链标识与DNAI之间的对应关系，如NEF接收来自AF的应用所需的外部业务链标识与DNAI之间的对应关系。NEF将应用所需的外部业务链标识映射为内部业务链标识(即业务链标识)，并且将该内部业务链标识与DNAI之间的对应关系发送给PCF。PCF根据应用所需的业务链标识与DNAI之间的对应关系，确定应用对应的业务链策略。

实现方式4，应用所需的业务链的信息包括应用所需的一个或多个业务功能的信息与DNAI之间的对应关系，第一网元根据应用所需的一个或多个业务功能的信息与DNAI之间的对应关系，确定应用对应的业务链策略。

一示例，第一网元为PCF，第二网元为AF。例如，AF向PCF发送应用所需的业务功能与DNAI之间的对应关系，PCF根据应用所需的业务功能与DNAI之间的对应关系，确定应用对应的业务链策略。

又一示例，第一网元为PCF，第二网元为NEF。例如，NEF接收应用所需的外部业务功能与DNAI之间的对应关系，如NEF接收来自AF的应用所需的外部业务功能与DNAI之间的对应关系。NEF将应用所需的外部业务功能映射为内部业务功能(即业务功能)，并且将该内部业务功能与DNAI之间的对应关系发送给PCF。PCF根据应用所需的内部业务功能与DNAI之间的对应关系，确定应用对应的业务链策略。

实现方式5，第一网元根据应用对应的业务链策略与DNAI之间的对应关系，确定应用对应的业务链策略。其中，应用对应的业务链策略与DNAI之间的对应关系，可以携带于应用所需的业务链的信息中，或者基于应用所需的一个或多个业务功能的信息与DNAI之间的对应关系确定，或者基于应用所需的业务链标识与DNAI之间的对应关系确定。

应理解，上述几种可能的实现方式仅是示例性说明，对此不作严格限定。只要在请求时，第二网元可以将应用所需的业务链的相关信息通知给第一网元，第一网元可以根据应用所需的业务链的相关信息，直接授权或者确定相应的应用链策略的方案，都落入本申请实施例的保护范围。

330，第一网元向第三网元发送应用对应的业务链策略。相应地，第三网元接收该应用对应的业务链策略。

可选地，第一网元还可以向第二网元发送指示信息，该指示信息用于指示接受请求。

或者可以理解为，通过指示信息，指示对请求的业务链授权成功。

可选地，第一网元还可以根据应用所需的一个或多个业务功能的信息，确定支持应用的一个或多个业务功能的信息，并向第二网元发送该支持所述应用的一个或多个业务功能的信息。

第一网元确定支持应用的一个或多个业务功能的方式有很多，对此本申请实施例不作限定。一种可能的实现方式，第一网元可以根据与应用的签约和网络配置，确定用户访问应用可以支持的一个或多个业务功能。

应理解，上面仅是简单的说明，具体地，下面结合图5至图10所示的流程详细说明。

图4是根据本申请另一实施例提供的一种确定策略的方法400的示意图。方法400可以包括如下步骤。

410，第一网元向第四网元发送请求消息#2，请求消息#2用于请求支持用户访问应用的对一个或多个业务功能进行授权，或者，请求消息#2用于请求对用户访问应用对应的业务链策略进行授权。相应地，第四网元接收该请求消息#2。

一种可能的情况，第一网元向第四网元发送请求消息#2，请求消息#2包括应用对应的业务链策略和访问该应用的用户的标识，该请求消息#2用于请求对应用对应的业务链策略进行授权。

又一种可能的情况，第一网元向第四网元发送请求消息#2，请求消息#2包括一个或多个业务功能的信息和访问应用的用户的标识，该请求消息#2用于请求对支持用户访问应用的一个或多个业务功能进行授权。

420，第一网元接收第四网元的响应消息。相应地，第四网元向第一网元发送该响应消息。

例如，第四网元进行授权后，向第一网元发送指示接受的确认信息。

可选地，方法400还可以包括步骤401。

401，第一网元确定应用对应的业务链策略。示例地，第一网元可以根据方法300所述的方案确定应用对应的业务链策略。

通过本申请实施例，在有些场景下，如在漫游场景下，第一网元根据请求制定业务链策略后，可以向第四网元发送该业务链策略，以便进行第四网元的进一步授权。或者第一网元根据请求确定支持的业务功能后，可以向第四网元发送该业务功能的信息，以便进行第四网元的进一步授权。

应理解，本申请实施例关于第四网元的具体形式不作限定。在需要提供应用增值服务的情况下，第四网元可以表示授权的设备。作为示例而非限定，第一网元例如为V-PCF，第四网元例如为H-PCF。

方法400和方法300可以结合使用，也可以单独使用，对此不作限定。以结合使用为例，第一网元可以先通过方法300所示的方案定应用对应的业务链策略，然后通过方法400的方案请求业务链的授权。

为便于理解，结合图5至图10介绍可能的具体流程进行示例性说明。下面，为简洁，用SC Id表示业务链标识，用service function表示业务功能。

图5是适用于本申请一实施例的业务链处理的一示意性流程图。

如图5所示，方法500主要以UE、AMF、UPF、SMF、PCF以及AF之间的交互为例进行示例性说明。作为示例而非限定，图5所示的方法500可以用于AF在为应用请求网络资源时，向网络请求应用所需要的业务链处理流程。在方法500中，第二网元例如可以为AF，第一网元例如可以为PCF。图5所示的方法500可以包括如下步骤。

501，PDU会话的建立过程(PDU session establishment procedure)。

例如，UE发起PDU会话的建立，网络为PDU选择PSA，网络给UE分配地址。UE通过建立的PDU会话，可以访问DN网络中的应用服务器。可以理解，PDU会话建立后，也就是建立了终端设备和DN的数据传输通道。

如前所述，SMF主要用户负责移动网络中的会话管理。PDU会话可以在UE和SMF之间可以通过NAS会话管理(session management，SM)信令进行建立、修改或释放。

上述仅是示例性说明，对于步骤501本申请实施例不作限定。例如，步骤501可以参考现有技术或以后出现的方式。

502，AF向PCF发送SC Id的信息。

AF决定为UE正在访问的应用请求资源以及应用增值服务的情况下，AF可以向PCF发送请求业务链授权的请求消息，并且在该请求消息中携带SC Id的信息。

SC Id可以是AF提前获知的。例如，SC Id可以是应用和运营商之前协商好的业务链标识，或者也可以是协议或网络预先定义好的业务链标识，对此不作限定。

可选地，如果AF对应用上下行数据有不同的上下行业务量需求，那么AF可以提供不同的上下行SC Id。例如，AF可以针对上行提供一个上行的SC Id，针对下行提供一个下行的SC Id，在步骤502中，AF向PCF发送的SC Id的信息可以包括上行的SC Id和下行的SC Id。

一种可能的实现方式，AF可以向PCF发送Npcf接口策略授权建立请求(Npcf_PolicyAuthorization_Create Request)消息，该消息中包含SC Id的信息。其中，Npcf接口为PCF对外提供的服务化接口。可选地，该消息中还可以包括但不限于：业务流描述信息(如五元组信息)、请求的服务质量(quality of service，QoS)需求。其中，五元组信息通常是指源IP地址，源端口，目的IP地址，目的端口和传输层协议。

应理解，Npcf_PolicyAuthorization_Create Request消息，仅是示例性说明，对此不作限定。只要AF可以向PCF发送SC Id的信息，该SC Id的信息携带于任何消息中均是可行的。

PCF收到来自AF的SC Id的信息后，可以保存接收到的信息。此外，PCF可以向AF发送响应。

503，PCF向AF发送确认信息。

当PCF对AF请求业务链授权成功时，PCF向AF发送指示接受的确认信息。

一种可能的实现方式，PCF可以向AF发送Npcf接口策略授权建立响应(Npcf_PolicyAuthorization_Create Response)消息，该消息中包含指示接受的确认信息。

应理解，Npcf_PolicyAuthorization_Create Response消息，仅是示例性说明，对此不作限定。只要PCF可以向AF指示接受的确认信息，该指示接受的确认信息携带于任何消息中均是可行的。

504，PCF制定策略计费控制(policy and charging control，PCC)规则。

PCF可以根据AF的请求，制定PCC规则。该PCC规则中包括PCF根据SC Id确定的TSPId。

可以理解，规则即表示与PDU会话或业务数据流相关的策略信息元素，对此可以参考现有描述，此处不作限定。

可选地，如果PCF决策的上下行TSP不同，那么PCC规则中可以包括不同的上下行TSP Id。例如，PCF可以针对上行确定一个TSP Id(如PCF可以根据上行的SC Id确定一个上行的TSP Id)，针对下行确定一个TSP Id(如PCF可以根据下行的SC Id确定一个下行的TSPId)，在步骤504中，PCF制定的PCC规则中可以包括上行的TSP Id和下行的TSP Id。

505，PCF向SMF发送PCC规则。

PCC规则中包括PCF根据SC Id确定的TSP Id。如PCC规则中包括上行的TSP Id和下行的TSP Id。

一种可能的实现方式，PCF可以向SMF发送会话管理策略控制更新请求(Npcf_SMPolicyControl_UpdateNotify Request)消息，该消息中包含PCC规则的信息。

应理解，Npcf_SMPolicyControl_UpdateNotify Request消息，仅是示例性说明，对此不作限定。只要PCF可以向SMF指示PCC规则的信息，该PCC规则的信息携带于任何消息中均是可行的。

506，SMF向PCF发送确认信息。

SMF安装PCC规则后，可以向PCF返回确认信息。

一种可能的实现方式，SMF可以向PCF发送会话管理策略控制更新响应(Npcf_SMPolicyControl_UpdateNotify Response)消息。

应理解，Npcf_SMPolicyControl_UpdateNotify Response消息，仅是示例性说明，对此不作限定。

507，SMF制定N4规则。

SMF可以根据PCC规则，制定N4规则。该N4规则中可以包括分组检测规则(packetdetection rule，PDR)和关联的转发动作规则(forwarding action rule，FAR)。PDR中包括业务流描述信息，FAR中包括TSP Id。

一可能的实现方式，SMF与UPF之间进行N4会话修改(N4 session modification)，以制定N4规则。

508，UPF进行业务路由(traffic steering)。

一种可能的实现方式，UPF根据PDR匹配到业务数据流，UPF根据FAR在数据流的数据包进行标记后，发送给局域网(如N6-LAN)。局域网中的交换机将根据数据包的标记将数据依次发送给业务功能节点。

上文结合图5所示的步骤501-508示例地介绍了一种可能的业务链处理流程，如应用在为应用请求网络资源时，向网络请求应用所需要的业务链处理的场景。应理解，上述各个步骤仅是示例性说明，对此不作严格限定。此外，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。例如，上述步骤503和步骤504之间并没有严格的先后顺序，如可以先执行步骤503，再执行步骤504；或者也可以先执行步骤504，再执行步骤503；或者也可以同步进行，对此不作限定。

基于上述方案，网络可动态的根据应用的请求，进行业务链的决策。例如，AF向网络请求业务数据流需要的应用增值服务(即业务链)时，携带应用所需要的业务链标识。这样，PCF基于AF的请求(即应用所需要的业务链标识)，确定对应的业务链策略，或者说进行授权。从而，能够快速响应应用对业务链的快速变化的需求。

图6是适用于本申请一实施例的业务链处理的又一示意性流程图。

如图6所示，方法600主要以UE、AMF、UPF、SMF、PCF、NEF以及AF之间的交互为例进行示例性说明。作为示例而非限定，图6所示的方法600可以用于AF在为应用请求网络资源时，通过NEF向网络请求应用所需要的业务链处理流程。在方法600中，第二网元例如可以为NEF，第一网元例如可以为PCF。图6所示的方法600可以包括如下步骤。

601，PDU会话的建立过程。

例如，UE发起PDU会话的建立，网络为PDU选择PSA，网络给UE分配地址。UE通过建立的PDU会话，可以访问DN网络中的应用服务器。

对于步骤601本申请实施例不作限定，例如，可以参考上述步骤501的描述。步骤601可以参考现有技术或以后出现的方式，此处不再介绍。

602，AF向NEF发送外部业务链标识external SC Id的信息。

AF决定为UE正在访问的应用请求资源以及应用增值服务的情况下，AF可以向NEF发送请求业务链授权的请求消息，并且在该请求消息中携带external SC Id的信息。

external SC Id可以是AF提前获知的。例如，external SC Id可以是应用和运营商之前协商好的业务链标识，或者也可以是协议或网络预先定义好的业务链标识，对此不作限定。

可选地，如果AF对应用上下行数据有不同的上下行业务量需求，那么AF可以提供不同的上下行external SC Id。例如，AF可以针对上行提供一个上行的external SC Id，针对下行提供一个下行的external SC Id，在步骤602中，AF向NEF发送的external SC Id的信息可以包括上行的external SC Id和下行的external SC Id。

一种可能的实现方式，AF可以向NEF发送Nnef接口有QoS的AF会话建立请求(Nnef_AFsessionWithQoS_Create Request)消息，该消息中包含external SC Id的信息。其中，Nnef接口为NEF对外提供的服务化接口。可选地，该消息中还可以包括但不限于：业务流描述信息(如五元组信息)、请求的QoS需求。

应理解，Nnef_AFsessionWithQoS_Create Request消息，仅是示例性说明，对此不作限定。只要AF可以向NEF发送external SC Id的信息，该external SC Id的信息携带于任何消息中均是可行的。

603，NEF进行处理。

NEF可以确定对AF的请求进行授权。NEF可以将external SC Id映射为内部业务链标识(internal service chain identifier，internal SC Id)，即NEF可以获得应用所需的internal SC Id。

可选地，如果AF提供不同的上下行external SC Id，如包括一个上行的externalSC Id和一个下行的external SC Id，那么，NEF可以将上行的external SC Id映射为上行的internal SC Id，将下行的external SC Id映射为下行的internal SC Id。

NEF获得应用所需的internal SC Id，可以将该internal SC Id发送给PCF。

604，NEF向PCF发送internal SC Id的信息。

一种可能的实现方式，NEF可以向PCF发送Npcf_PolicyAuthorization_CreateRequest消息，该消息中包含internal SC Id的信息。可选地，该消息中还可以包括但不限于：业务流描述信息(如五元组信息)、请求的QoS需求。

应理解，Npcf_PolicyAuthorization_Create Request消息，仅是示例性说明，对此不作限定。只要NEF可以向PCF发送internal SC Id的信息，该internal SC Id的信息携带于任何消息中均是可行的。

605，PCF向NEF发送确认信息。

当PCF对请求的业务链授权成功时，PCF向NEF发送指示接受的确认信息。

一种可能的实现方式，PCF可以向NEF发送Npcf_PolicyAuthorization_CreateResponse消息，该消息中包含指示接受的确认信息。

应理解，Npcf_PolicyAuthorization_Create Response消息，仅是示例性说明，对此不作限定。只要PCF可以向NEF指示接受的确认信息，该指示接受的确认信息携带于任何消息中均是可行的。

606，NEF向AF发送确认信息。

一种可能的实现方式，NEF可以向AF发送Nnef接口有QoS的AF会话建立响应(Nnef_AFsessionWithQoS_Create Response)消息，该消息中包含指示接受的确认信息。

应理解，Nnef_AFsessionWithQoS_Create Response消息，仅是示例性说明，对此不作限定。只要NEF可以向AF指示接受的确认信息，该指示接受的确认信息携带于任何消息中均是可行的。

607，PCF制定PCC规则。

PCF可以根据AF的请求(即通过NEF转达的请求)，制定PCC规则。该PCC规则中包括PCF根据SC Id(即步骤604中接收到的internal SC Id)确定的TSP Id。

可选地，如果PCF决策的上下行TSP不同，那么PCC规则中可以包括不同的上下行TSP Id。例如，PCF可以针对上行确定一个TSP Id(如PCF可以根据上行的internal SC Id确定一个上行的TSP Id)，针对下行确定一个TSP Id(如PCF可以根据下行的internal SC Id确定一个下行的TSP Id)，在步骤607中，PCF制定的PCC规则中可以包括上行的TSP Id和下行的TSP Id。

608，PCF向SMF发送PCC规则。

对于步骤608，例如可以参考上述步骤505的描述，此处不再介绍。

609，SMF向PCF发送确认信息。

对于步骤609，例如可以参考上述步骤506的描述，此处不再介绍。

610，SMF制定N4规则。

对于步骤610，例如可以参考上述步骤507的描述，此处不再介绍。

611，UPF进行业务路由。

对于步骤611，例如可以参考上述步骤508的描述，此处不再介绍。

上文结合图6所示的步骤601-611示例地介绍了一种可能的业务链处理流程，如应用在为应用请求网络资源时，通过NEF向网络请求应用所需要的业务链处理的场景。应理解，上述各个步骤仅是示例性说明，对此不作严格限定。此外，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。例如，上述步骤605和步骤607之间并没有严格的先后顺序，如可以先执行步骤605，再执行步骤607；或者也可以先执行步骤607，再执行步骤605；或者也可以同步进行，对此不作限定。

基于上述方案，网络可动态的根据应用的请求，进行业务链的决策。例如，AF通过NEF向网络请求应用所需要的业务链处理时，携带外部业务链标识。NEF将该外部业务链标识映射为内部业务链标识后，将该内部业务链标识发送给PCF。这样，PCF基于AF的请求(即内部业务链标识)，确定对应的业务链策略，或者说进行授权。从而，能够快速响应应用对业务链的快速变化的需求。

图7是适用于本申请一实施例的业务链处理的又一示意性流程图。

如图7所示，方法700主要以UE、AMF、UPF、SMF、PCF、NEF、统一数据存储(unifieddata repository，UDR)以及AF之间的交互为例进行示例性说明。作为示例而非限定，图7所示的方法700可以用于AF通过NEF向网络提供各个DNAI对应的应用的业务链处理流程。在方法700中，第二网元例如可以为UDR或NEF，第一网元例如可以为PCF。图7所示的方法700可以包括如下步骤。

701，AF向NEF发送外部业务链标识external SC Id与DNAI的对应关系的信息。

external SC Id与DNAI的对应关系的信息可以通过列表的形式发送。例如，AF可以向NEF发送external SC Id与DNAI的对应关系列表。

一种可能的实现方式，AF可以向NEF发送Nnef接口流量引导建立请求(Nnef_TrafficInfluence_Create Request)消息，该消息中包含数据导向请求信息，该数据导向请求信息中包括external SC Id与DNAI的对应关系列表。可选地，该数据导向请求信息中还可以包括但不限于：适用的用户外部组标识或任意用户的指示信息。

应理解，Nnef_TrafficInfluence_Create Request消息，仅是示例性说明，对此不作限定。只要AF可以向NEF发送external SC Id与DNAI的对应关系的信息，该external SCId与DNAI的对应关系的信息携带于任何消息中均是可行的。

702，NEF进行处理。

NEF可以确定对AF的请求进行授权。NEF可以将external SC Id映射为internalSC Id，即NEF可以获得internal SC Id与DNAI的对应关系。NEF还可以将外部组标识映射为内部组标识。

703，NEF将internal SC Id与DNAI的对应关系保存到UDR。

一种可能的实现方式，UDR从NEF处接收internal SC Id与DNAI的对应关系，并且保存internal SC Id与DNAI的对应关系。

示例地，NEF可以将在步骤701中接收到的数据导向请求信息保存到UDR中。可以理解，在步骤702中，NEF可以将external SC Id映射为internal SC Id，还可以将外部组标识映射为内部组标识，因此，UDR中保存的数据导向请求信息中可以包括：internal SC Id与DNAI的对应关系，适用的用户内部标识或任意用户的指示信息。

704，NEF向AF发送确认信息。

一种可能的实现方式，NEF可以向AF发送Nnef接口流量引导建立响应(Nnef_TrafficInfluence_Create Response)消息，该消息中包含指示接受的确认信息。

应理解，Nnef_TrafficInfluence_Create Response消息，仅是示例性说明，对此不作限定。只要NEF可以向AF指示接受的确认信息，该指示接受的确认信息携带于任何消息中均是可行的。

705，UDR将数据导向请求信息通知给相应的PCF。

数据导向请求信息中可以包括：internal SC Id与DNAI的对应关系，适用的用户内部标识或任意用户的指示信息。

706，UE建立PDU会话。

例如，UE发起PDU会话的建立，网络为PDU选择PSA，网络给UE分配地址。

对于步骤706本申请实施例不作限定，例如，可以参考上述步骤501的描述。步骤706可以参考现有技术或以后出现的方式，此处不再介绍。

707，PCF制定PCC规则。

一可能的情况，如果数据导向请求信息中包括任意用户指示信息，或者UE属于内部组标识标识的用户组的成员，那么PCF制定对应的PCC规则。

PCF可以根据internal SC Id确定的TSP Id。PCC规则可以包括数据导向策略，并且在数据导向策略中可以包括internal SC Id对应的TSP Id与DNAI的对应关系。

可选地，如果PCF决策的上下行TSP不同，那么PCC规则中可以包括不同的上下行TSP Id。例如，PCF可以针对上行确定一个TSP Id(如PCF可以根据上行的internal SC Id确定一个上行的TSP Id，或者说确定上行的TSP Id与DNAI的对应关系)，针对下行确定一个TSP Id(如PCF可以根据下行的internal SC Id确定一个下行的TSP Id，或者说确定下行的TSP Id与DNAI的对应关系)，在步骤707中，PCF制定的PCC规则中可以包括上行的internalSC Id对应的TSP Id与DNAI的对应关系，以及下行的internal SC Id对应的TSP Id与DNAI的对应关系。

708，PCF向SMF发送PCC规则。

PCC规则中包括TSP Id与DNAI的对应关系列表。如PCC规则中包括上行的TSP Id与DNAI的对应关系列表，以及下行的TSP Id与DNAI的对应关系列表。

一种可能的实现方式，PCF可以向SMF发送Npcf_SMPolicyControl_UpdateNotifyRequest消息，该消息中包含PCC规则的信息。

709，SMF向PCF发送确认信息。

SMF安装PCC规则后，可以向PCF返回确认信息。

一种可能的实现方式，SMF可以向PCF发送Npcf_SMPolicyControl_UpdateNotifyResponse消息。

710，SMF和UPF进行用户面配置(configuration)(或重配置(reconfiguration))。

SMF可以为PDU会话确定目标DNAI。示例地，SMF可以根据UE的位置、运营商策略以及DNAI列表，为PDU会话确定目标DNAI。

SMF可以根据目标NDAI确定新的PSA以及TSP Id。

此外，SMF还可以根据PCC规则制定N4规则。该N4规则中可以包括PDR和关联的FAR。PDR中包括业务流描述信息，FAR中包括TSP Id。

711，UPF进行traffic steering。

上文结合图7所示的步骤701-711示例地介绍了一种可能的业务链处理流程，如应用通过NEF向网络提供各个DNAI对应的业务链处理的场景。应理解，上述各个步骤仅是示例性说明，对此不作严格限定。此外，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

基于上述方案，AF在向网络提供数据导向请求信息时，可以提供DNAI和外部业务链标识对应关系的列表。NEF将该外部业务链标识映射为内部业务链标识后，将DNAI和该内部业务链标识对应关系的列表发送给PCF。PCF根据内部业务链标识，确定对应的TSP Id，从而在向SMF发送的PCC规则中携带DNAI与TSP Id的对应关系。SMF可以根据选择的目标DNAI确定对应的TSP Id，从而当UE通过目标DNAI访问应用时，业务数据流可以导向到对应的业务功能(service function)。

图8是适用于本申请一实施例的业务链处理的又一示意性流程图。

如图8所示，方法800主要以UE、AMF、UPF、SMF、PCF、NEF以及AF之间的交互为例进行示例性说明。作为示例而非限定，图8所示的方法800可以用于AF通过NEF向网络提供业务增值功能需求流程。在方法800中，第二网元例如可以为NEF，第一网元例如可以为PCF。图8所示的方法800可以包括如下步骤。

801，PDU会话的建立过程。

对于步骤801本申请实施例不作限定，例如，可以参考上述步骤501的描述。步骤801可以参考现有技术或以后出现的方式，此处不再介绍。

802，AF向NEF发送外部service function的列表。

外部service function的列表，包括一个或多个service function的信息。其中，service function可以用具体的标识或是类型来标识，对此不作限定。例如，servicefunction可以用service function的Id来标识，即外部service function的列表中包括外部service function的Id。又如，service function可以用service function的类型来标识，即外部service function列表中包括外部service function的类型。

外部service function的信息可以通过列表的形式发送。例如，AF可以向NEF发送外部service function的列表，作为示例而非限定，这个列表例如可以按照servicefunction被使用的顺序来携带。

AF决定为UE正在访问的应用请求资源以及应用增值服务的情况下，AF可以向NEF发送请求业务链授权的请求消息，并且在该请求消息中携带外部service function的信息。

可选地，如果AF对应用上下行数据有不同的上下行业务量需求，那么AF可以提供不同的上下行外部service function的列表。例如，AF可以针对上行提供一个上行的service function的列表，针对下行提供一个下行的service function的列表，在步骤802中，AF向NEF发送的service function的列表可以包括上行的service function的列表和下行的service function的列表。

一种可能的实现方式，AF可以向NEF发送Nnef_AFsessionWithQoS_CreateRequest消息，该消息中包含外部service function的列表。可选地，该消息中还可以包括但不限于：业务流描述信息(如五元组信息)、请求的QoS需求。

应理解，Nnef_AFsessionWithQoS_Create Request消息，仅是示例性说明，对此不作限定。只要AF可以向NEF发外部service function的列表，该外部service function的列表携带于任何消息中均是可行的。

803，NEF进行处理。

NEF可以确定对AF的请求进行授权。NEF可以将外部service function映射为内部service function，即NEF可以获得内部service function的列表。

可选地，如果AF提供不同的上下行外部service function的列表，如包括一个上行的外部service function的列表和一个下行的外部service function的列表，那么，NEF可以将上行的外部service function的列表映射为上行的内部service function的列表，将下行的外部service function的列表映射为下行的内部service function的列表。

804，NEF向PCF发送内部service function的列表。

一种可能的实现方式，NEF可以向PCF发送Npcf_PolicyAuthorization_CreateRequest消息，该消息中包含内部service function的列表。可选地，该消息中还可以包括但不限于：业务流描述信息(如五元组信息)、QoS需求。

应理解，Npcf_PolicyAuthorization_Create Request消息，仅是示例性说明，对此不作限定。只要NEF可以向PCF发送内部service function的列表，该内部servicefunction的列表携带于任何消息中均是可行的。

805，PCF向NEF发送确认信息。

当PCF对请求的业务链授权成功时(即PCF对请求的service function授权成功时)，PCF向NEF发送指示接受的确认信息。作为示例而非限定，PCF可以根据网络配置和运营商策略确定是否向NEF返回确认消息，即确定对请求的业务链是否授权。

可选地，该确认信息中还可以包括：PCF授权的内部service function的列表。NEF可以向PCF发送多个内部service function时，PCF可能对该多个内部service function中的部分内部service function授权，或者PCF可能对该多个内部service function中的全部内部service function授权，对此不作限定。

一种可能的实现方式，PCF可以向NEF发送Npcf_PolicyAuthorization_CreateResponse消息，该消息中包含指示接受内部service function的确认信息。

应理解，Npcf_PolicyAuthorization_Create Response消息，仅是示例性说明，对此不作限定。只要PCF可以向NEF指示接受内部service function的确认信息，该指示接受内部service function的确认信息携带于任何消息中均是可行的。

806，NEF向AF发送确认信息。

可选地，该确认信息中还可以包括：PCF授权的内部service function的列表。

一种可能的实现方式，NEF可以向AF发送Nnef_AFsessionWithQoS_CreateResponse消息，该消息中包含指示接受内部service function的确认信息。

应理解，Nnef_AFsessionWithQoS_Create Response消息，仅是示例性说明，对此不作限定。只要NEF可以向AF指示接受内部service function的确认信息，该指示接受内部service function的确认信息携带于任何消息中均是可行的。

807，PCF制定PCC规则。

PCF可以根据授权的内部service function的列表，确定对应的业务链，从而进一步确定对应的TSP Id。PCF制定PCC规则，在PCC规则中包括TSP Id。

可选地，如果PCF决策的上下行TSP不同，那么PCC规则中可以包括不同的上下行TSP Id。

808，PCF向SMF发送PCC规则。

对于步骤808，例如可以参考上述步骤505的描述，此处不再介绍。

809，SMF向PCF发送确认信息。

对于步骤809，例如可以参考上述步骤506的描述，此处不再介绍。

810，SMF制定N4规则。

对于步骤810，例如可以参考上述步骤507的描述，此处不再介绍。

811，UPF进行业务路由。

对于步骤811，例如可以参考上述步骤508的描述，此处不再介绍。

上文结合图8所示的步骤801-811示例地介绍了一种可能的业务链处理流程，如应用通过NEF向网络提供业务增值功能需求的场景。应理解，上述各个步骤仅是示例性说明，对此不作严格限定。此外，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。例如，上述步骤805和步骤807之间并没有严格的先后顺序，如可以先执行步骤805，再执行步骤807；或者也可以先执行步骤807，再执行步骤805；或者也可以同步进行，对此不作限定。

基于上述方案，网络可动态的根据应用的请求，进行业务链的决策。例如，AF通过NEF向网络请求应用所需要的业务链处理时，携带外部业务功能的列表。NEF将该外部业务功能映射为内部业务功能后，将该内部业务功能的列表发送给PCF。这样，PCF基于AF的请求(即内部业务功能的列表)，根据授权的内部业务功能的列表，确定对应的业务链，从而进一步确定对应的业务链策略。从而，能够快速响应应用对业务链的快速变化的需求。

图9是适用于本申请一实施例的业务链处理的又一示意性流程图。

如图9所示，方法900主要以UE、AMF、UPF、SMF、V-PCF、H-PCF、NEF以及AF之间的交互为例进行示例性说明。作为示例而非限定，图9所示的方法900可以用于UE处于本地疏导的漫游场景下，AF在为应用请求网络资源时，向网络请求应用所需要的业务链处理流程。在方法900中，第二网元例如可以为NEF，第一网元例如可以为V-PCF，第四网元例如可以为H-PCF。图9所示的方法900可以包括如下步骤。

901，PDU会话的建立过程。

例如，UE在本地疏导的漫游场景下，建立PDU会话，网络为PDU选择PSA，网络给UE分配地址。UE通过建立的PDU会话，可以访问DN网络中的应用服务器。

一种可能的实现方式，UE发送会话建立请求消息，会话建立请求消息中可以包括但不限于：单一网络切片选择辅助信息(single network slice selection assistanceinformation，S-NSSAI)、数据网络名称(data network name，DNN)、订阅永久标识符(subscription permanent identifier，SUPI)。SMF与V-PCF交互，建立会话管理策略关联，从PCF获取PCC策略。

对于步骤901本申请实施例不作限定，步骤901可以参考现有技术或以后出现的方式，此处不再介绍。

902，AF向NEF发送外部业务链标识external SC Id的信息。

AF决定为UE正在访问的应用请求资源以及业务增值服务的情况下，AF可以向NEF发送请求业务链授权的请求消息，并且在该请求消息中携带external SC Id的信息。

可选地，如果AF对应用上下行数据有不同的上下行业务量需求，那么AF可以提供不同的上下行external SC Id。例如，AF可以针对上行提供一个上行的external SC Id，针对下行提供一个下行的external SC Id，在步骤902中，AF向NEF发送的external SC Id的信息可以包括上行的external SC Id和下行的external SC Id。

一种可能的实现方式，AF可以向NEF发送Nnef_AFsessionWithQoS_CreateRequest消息，该消息中包含external SC Id的信息。可选地，该消息中还可以包括但不限于：业务流描述信息(如五元组信息)、请求的QoS需求。

903，NEF进行处理。

NEF可以确定对AF的请求进行授权。NEF可以将external SC Id映射为internalSC Id。

904，NEF向V-PCF发送internal SC Id的信息。

一种可能的实现方式，NEF可以向V-PCF发送Npcf_PolicyAuthorization_CreateRequest消息，该消息中包含internal SC Id的信息。可选地，该消息中还可以包括但不限于：业务流描述信息(如五元组信息)、请求的QoS需求。

应理解，Npcf_PolicyAuthorization_Create Request消息，仅是示例性说明，对此不作限定。只要NEF可以向V-PCF发送internal SC Id的信息，该internal SC Id的信息携带于任何消息中均是可行的。

905，V-PCF制定PCC规则。

V-PCF可以根据AF的请求(即通过NEF转达的请求)，进行授权。V-PCF可以根据internal SC Id确定对应的TSP Id。V-PCF制定PCC规则，在PCC规则中包括TSP Id。

可选地，如果V-PCF决策的上下行TSP不同，那么PCC规则中可以包括不同的上下行TSP Id。例如，V-PCF可以针对上行确定一个TSP Id(如V-PCF可以根据上行的internal SCId确定一个上行的TSP Id)，针对下行确定一个TSP Id(如V-PCF可以根据下行的internalSC Id确定一个下行的TSP Id)，在步骤905中，V-PCF制定的PCC规则中可以包括上行的TSPId和下行的TSP Id。

906，V-PCF向H-PCF发送PCC授权请求消息。

V-PCF确定UE为漫游用户，V-PCF可以向H-PCF发送PCC授权请求消息，该PCC授权请求消息中可以携带：UE的标识(如SUPI)、DNN、S-NSSAI。V-PCF可以根据SUPI确定UE的归属地运营商后，通过拜访地的网络存储功能(NF repository function，NRF)选择H-PCF，或者通过归属地的NRF选择H-PCF。

此外，该PCC授权请求消息中可以包括以下一项或多项：V-PCF确定的PCC规则、V-PCF确定的TSP Id、V-PCF确定的internal SC Id、V-PCF授权的service function列表。其中，PCC规则中包括V-PCF根据SC Id确定的TSP Id。如PCC规则中包括上行的TSP Id和下行的TSP Id。

其中，service function可以用具体的标识或是类型来标识，对此不作限定。例如，service function可以用service function的Id来标识，即service function列表中包括V-PCF授权的service function的Id。又如，service function可以用servicefunction的类型来标识，即service function列表中包括V-PCF授权的service function的类型。

一种可能的实现方式，V-PCF可以向H-PCF发送Npcf接口PCC授权建立请求(Npcf_PccAuthorization_Create Request)消息。应理解，Npcf_PccAuthorization_CreateRequest消息，仅是示例性说明，对此不作限定。

907，H-PCF向V-PCF发送确认信息。

在步骤907中，H-PCF进行授权后，向V-PCF发送指示接受的确认信息。

一种可能的实现方式，H-PCF可以向V-PCF发送Npcf接口PCC授权建立响应(Npcf_PccAuthorization_Create Response)消息。应理解，Npcf_PccAuthorization_CreateResponse消息，仅是示例性说明，对此不作限定。

908，V-PCF向NEF发送确认信息。

一种可能的实现方式，V-PCF可以向NEF发送Npcf_PolicyAuthorization_CreateResponse消息。应理解，Npcf_PolicyAuthorization_Create Response消息，仅是示例性说明，对此不作限定。

909，NEF向AF发送确认信息。

一种可能的实现方式，NEF可以向AF发送Nnef_AFsessionWithQoS_CreateResponse消息。应理解，Nnef_AFsessionWithQoS_Create Response消息，仅是示例性说明，对此不作限定。

910，V-PCF向SMF发送PCC规则。

PCC规则中包括TSP Id。如PCC规则中包括上行的TSP Id和下行的TSP Id。

一种可能的实现方式，V-PCF可以向SMF发送Npcf_SMPolicyControl_UpdateNotify Request消息，该消息中包含PCC规则的信息。

应理解，Npcf_SMPolicyControl_UpdateNotify Request消息，仅是示例性说明，对此不作限定。只要V-PCF可以向SMF指示PCC规则的信息，该PCC规则的信息携带于任何消息中均是可行的。

911，SMF向V-PCF发送确认信息。

SMF安装PCC规则后，可以向V-PCF返回确认信息。

一种可能的实现方式，SMF可以向V-PCF发送Npcf_SMPolicyControl_UpdateNotify Response消息。应理解，Npcf_SMPolicyControl_UpdateNotify Response消息，仅是示例性说明，对此不作限定。

912，SMF制定N4规则。

对于步骤912，例如可以参考上述步骤507的描述，此处不再介绍。

913，UPF进行业务路由。

对于步骤913，例如可以参考上述步骤508的描述，此处不再介绍。

上文结合图9所示的步骤901-913示例地介绍了一种可能的业务链处理流程，如UE处于本地疏导的漫游场景下，应用在为应用请求网络资源时，向网络请求应用所需要的业务链处理的场景。应理解，上述各个步骤仅是示例性说明，对此不作严格限定。此外，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。例如，上述步骤908和步骤910之间并没有严格的先后顺序，如可以先执行步骤908，再执行步骤910；或者也可以先执行步骤910，再执行步骤908；或者也可以同步进行，对此不作限定。

基于上述方案，在漫游场景下，V-PCF可以根据AF的请求制定业务链策略(即TSP策略)，并向H-PCF发送该业务链策略，以便进行H-PCF的进一步授权。

图10是适用于本申请一实施例的业务链处理的又一示意性流程图。

如图10所示，方法1000主要以UE、AMF、UPF、SMF、V-PCF、H-PCF、UDR、NEF以及AF之间的交互为例进行示例性说明。作为示例而非限定，图10所示的方法1000可以用于UE处于本地疏导的漫游场景下，AF在提供数据导向请求信息时，向网络请求应用所需要的业务链处理的场景。在方法1000中，第二网元例如可以为UDR或NEF或H-PCF，第一网元例如可以为V-PCF，第四网元例如可以为H-PCF。图10所示的方法1000可以包括如下步骤。

1001，AF向NEF发送外部业务链标识external SC Id与DNAI的对应关系的信息。

一种可能的实现方式，AF可以向NEF发送Nnef_TrafficInfluence_CreateRequest消息，该消息中包含数据导向请求信息，该数据导向请求信息中包括external SCId与DNAI的对应关系列表。可选地，该数据导向请求信息中还可以包括但不限于：适用的用户外部组标识或任意用户的指示信息。

1002，NEF进行处理。

1003，NEF将internal SC Id与DNAI的对应关系保存到UDR。

示例地，NEF可以将在步骤1001中接收到的数据导向请求信息保存到UDR中。可以理解，在步骤1002中，NEF可以将external SC Id映射为internal SC Id，还可以将外部组标识映射为内部组标识，因此，UDR中保存的数据导向请求信息中可以包括：internal SCId与DNAI的对应关系，适用的用户内部标识或任意用户的指示信息。

1004，NEF向AF发送确认信息。

一种可能的实现方式，NEF可以向AF发送Nnef_TrafficInfluence_CreateResponse消息。应理解，Nnef_TrafficInfluence_Create Response消息，仅是示例性说明，对此不作限定。

1005，UDR将数据导向请求信息通知给相应的PCF。

例如，UDR将数据导向请求信息通知给V-PCF和H-PCF。数据导向请求信息中可以包括：internal SC Id与DNAI的对应关系，适用的用户内部标识或任意用户的指示信息。

1006，UE建立PDU会话。

对于步骤1006，例如可以参考上述步骤901的描述，此处不再介绍。

1007，V-PCF制定PCC规则。

一可能的情况，如果数据导向请求信息中包括任意用户指示信息，或者UE属于内部组标识标识的用户组的成员，那么V-PCF制定对应的PCC规则。

V-PCF可以根据internal SC Id与DNAI的对应关系，确定的internal SC Id对应的TSP Id与DNAI的对应关系。PCC规则可以包括数据导向策略，并且在数据导向策略中可以包括internal SC Id对应的TSP Id与DNAI的对应关系。

可选地，如果V-PCF决策的上下行TSP不同，那么PCC规则中可以包括不同的上下行TSP Id。例如，V-PCF可以针对上行确定一个TSP Id(如V-PCF可以根据上行的internal SCId确定一个上行的TSP Id，或者说确定上行的TSP Id与DNAI的对应关系)，针对下行确定一个TSP Id(如V-PCF可以根据下行的internal SC Id确定一个下行的TSP Id，或者说确定下行的TSP Id与DNAI的对应关系)，在步骤1007中，PCF制定的PCC规则中可以包括上行的internal SC Id对应的TSP Id与DNAI的对应关系，以及下行的internal SC Id对应的TSPId与DNAI的对应关系。

1008，V-PCF向SMF发送PCC规则。

1009，SMF向V-PCF发送确认信息。

SMF安装PCC规则后，可以向V-PCF返回确认信息。

一种可能的实现方式，SMF可以向V-PCF发送Npcf_SMPolicyControl_UpdateNotify Response消息。

1010，SMF和UPF进行用户面配置(或重配置)。

SMF可以为PDU会话确定目标DNAI。示例地，SMF可以根据UE的位置、运营商策略、网络配置以及DNAI列表，为PDU会话确定目标DNAI。

SMF可以根据目标NDAI确定新的PSA以及TSP Id。

1011，SMF向V-PCF发送目标DNAI的信息和/或TSP Id，用于请求业务链策略授权。

一种可能的实现方式，SMF可以向V-PCF发送Npcf_SMPolicyControl_UpdateRequest消息，该消息中携带确定的目标DNAI和/或TSP Id。

应理解，Npcf_SMPolicyControl_Update Request消息，仅是示例性说明，对此不作限定。

1012，V-PCF向H-PCF发送PCC授权请求消息。

V-PCF确定UE为漫游用户，V-PCF可以向H-PCF发送PCC授权请求消息，该PCC授权请求消息中可以携带：UE的SUPI、DNN、S-NSSAI。V-PCF可以根据SUPI确定UE的归属地运营商后，通过拜访地的NRF选择H-PCF，或者通过归属地的NRF选择H-PCF。

此外，该PCC授权请求消息中可以包括以下一项或多项：目标DNAI对应的V-PCF确定的PCC规则(PCC规则中包括TSP Id)、目标DNAI对应的V-PCF确定的TSP Id、目标DNAI对应的V-PCF确定的internal SC Id、目标DNAI对应的V-PCF授权的service function列表、TSPId对应的V-PCF授权的service function列表。其中，service function可以用具体的标识或是类型来标识，对此不作限定。

一种可能的实现方式，V-PCF可以向H-PCF发送Npcf_PccAuthorization_CreateRequest消息。应理解，Npcf_PccAuthorization_Create Request消息，仅是示例性说明，对此不作限定。

1013，H-PCF向V-PCF发送确认信息。

在步骤1013中，H-PCF进行授权后，向V-PCF发送指示接受的确认信息。

一种可能的实现方式，H-PCF可以向V-PCF发送Npcf_PccAuthorization_CreateResponse消息。应理解，Npcf_PccAuthorization_Create Response消息，仅是示例性说明，对此不作限定。

1014，V-PCF向SMF发送确认信息。

V-PCF向SMF发送确认信息，以指示业务链策略授权。

一种可能的实现方式，V-PCF可以向SMF发送Npcf_SMPolicyControl_UpdateResponse消息。应理解，Npcf_SMPolicyControl_Update Response消息，仅是示例性说明，对此不作限定。

1015，UPF进行traffic steering。

对于步骤1015，例如可以参考上述步骤508的描述，此处不再介绍。

上文结合图10所示的步骤1001-1015示例地介绍了一种可能的业务链处理流程，如UE处于本地疏导的漫游场景下，应用在提供数据导向请求信息时，向网络请求应用所需要的业务链处理的场景。应理解，上述各个步骤仅是示例性说明，对此不作严格限定。此外，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。例如，上述步骤1003和步骤1004之间并没有严格的先后顺序，如可以先执行步骤1003，再执行步骤1004；或者也可以先执行步骤1004，再执行步骤1003；或者也可以同步进行，对此不作限定。

基于上述方案，在漫游场景下，V-PCF可以根据AF的请求制定业务链策略(即TSP策略)，并向H-PCF发送该业务链策略，以便进行H-PCF的进一步授权。例如，AF在向网络提供数据导向请求信息时，提供DNAI和外部业务链标识对应关系的列表。NEF将该外部业务链标识映射为内部业务链标识后，将DNAI和该内部业务链标识对应关系的列表发送给V-PCF。V-PCF根据该内部业务链标识，确定对应的TSP Id，从而在PCC规则中携带DNAI与TSP Id的对应关系。当SMF确定目标DNAI后，报告给V-PCF，V-PCF进一步发送对应的业务链策略(即TSP策略)请求H-PCF进一步授权。

上面结合图5至图10详细地介绍了适用于方法300和方法400的可能的流程。作为示例，图5至图10可用于执行方法300的方案，图9至图10还可用于执行方法400的方案。

在本申请实施例中，考虑到在发送请求时，携带应用所需的业务链的信息，故本申请实施例提供一种关于业务链管理的方法。下面结合图11介绍关于业务链管理的可能的流程。

图11是适用于本申请实施例的业务链管理的示意性流程图。

如图11所示，方法1100主要以业务链管理设备(service chain manager)、NEF以及AF之间的交互为例进行示例性说明。作为示例而非限定，图11所示的方法1100可以用于当运营商或是第三方应用部署了service function后，将service function注册到NEF，当第三方需要请求业务链处理时，第三方请求查询获取业务链的流程。在方法1100中，第二网元例如可以为AF。图11所示的方法1100可以包括如下步骤。

1101，创建、修改或删除service function。

业务链管理设备，如运营商或是第三方应用，部署了service function后，可以感知对于service function的操作。关于service function的操作，例如可以包括但不限于：创建、修改或删除。

1102，业务链管理设备和NEF之间交互业务链登记(service chainregistration)的信息。

一种可能的实现方式，业务链管理设备向NEF发送service chain registration的信息，该service chain registration的信息中可以携带以下一项或多项信息：servicefunction类型和service function标识的对应关系、service function类型和externalSC Id的对应关系、service function类型、service function标识和DNAI的对应关系、service function标识、external SC Id标识和DNAI的对应关系的对应关系。其中，service function例如可以包括如创建、修改或删除的service function。

1103，AF触发。

也就是说，在步骤1103中，AF接收到触发，决定需要请求业务链处理。如AF决定为UE正在访问的应用请求资源以及业务增值服务。

1104，AF向NEF发送业务链发现(service chain discovery)请求消息。

可选地，该请求消息可以携带：需要的service function的类型以及DNAI信息。

NEF可以根据DNAI信息，返回DNAI对应支持的service function或者SC Id以及包括的service function类型。

NEF可以根据service function的类型，返回对应的service function Id或是SCId以及包括的service function类型。

此后，作为示例，AF可以发起如前面方法500至方法1000实施例的请求消息。

上文结合图11所示的步骤1101-1104示例地介绍了一种可能的业务链处理流程，如当运营商或是第三方应用部署了service function后，将service function注册到NEF，当第三方需要请求业务链处理时，第三方请求查询获取业务链的场景。应理解，上述各个步骤仅是示例性说明，对此不作严格限定。此外，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

基于上述方案，第三方应用可以动态请求业务链。例如，网络将支持的业务功能或业务链注册到NEF，第三方应用可通过查询获得相应的业务功能或业务链。

应理解，在上述一些实施例中，涉及到一些消息名称，如接口请求消息或接口响应消息，等等，应理解，其命名不对本申请实施例的保护范围造成限定。

还应理解，在上述一些实施例中，多次提到业务链的信息，如需要的业务链的信息或者查询的业务链的信息，其用于表示与业务链相关的信息，例如可以包括SC Id、external SC Id、service function的信息、外部service function的信息，DNAI等等。

还应理解，在上述一些实施例中，主要以现有的网络架构中的网元为例进行了示例性说明(如AF、PCF、SMF等等)，应理解，对于网元的具体形式本申请实施例不作限定。例如，在未来可以实现同样功能的网元都适用于本申请实施例。此外，在未来可以部署业务链的任何架构都适用于本申请实施例。

还应理解，在上述一些实施例中，主要以请求应用对应的业务链策略为例进行示例性说明，应理解，对此不作限定。例如，在任何提供业务链的场景中，都可以使用本申请实施例的方案制定业务链策略。

本文中描述的各个实施例可以为独立的方案，也可以根据内在逻辑进行组合，这些方案都落入本申请的保护范围中。例如，方法400和方法300可以结合使用，也可以独立使用。又如，方法1100可以单独使用，也可以作为方法500-方法1000的准备工作结合使用，等等。

可以理解的是，上述各个方法实施例中，由网络设备(如各个网元)实现的方法和操作，也可以由可用于网络设备的部件(例如芯片或者电路)实现。

以上，结合图3至图11详细说明了本申请实施例提供的方法。以下，结合图12至图14详细说明本申请实施例提供的装置。应理解，装置实施例的描述与方法实施例的描述相互对应，因此，未详细描述的内容可以参见上文方法实施例，为了简洁，这里不再赘述。

图12是本申请实施例提供的装置1200的示意性框图。该装置1200包括收发单元1210和处理单元1220。收发单元1210可以实现相应的通信功能，处理单元1220用于进行数据处理。收发单元1210还可以称为通信接口或通信单元。

可选地，该装置1200还可以包括存储单元，该存储单元可以用于存储指令和/或数据，处理单元1220可以读取存储单元中的指令和/或数据，以使得装置实现前述方法实施例。

该装置1200可以用于执行上文方法实施例中网络设备(如各个网元)所执行的动作，这时，该装置1200可以为网络设备或者可配置于网络设备的部件，收发单元1210用于执行上文方法实施例中网络设备侧的收发相关的操作，处理单元1220用于执行上文方法实施例中网络设备侧的处理相关的操作。

作为一种设计，该装置1200用于执行上文方法实施例中第一网元所执行的动作。

一种可能的实现方式，收发单元1210，用于接收来自第二网元的第一请求消息，第一请求消息包括应用所需的业务链的信息；收发单元1210，还用于向第三网元发送应用对应的业务链策略，应用对应的业务链策略是根据应用所需的业务链的信息制定的。

可选地，处理单元1220，用于根据应用所需的业务链的信息，确定应用对应的业务链策略。

该装置1200可实现对应于根据本申请实施例的方法实施例中的第一网元执行的步骤或者流程，该装置1200可以包括用于执行方法实施例中的第一网元执行的方法的单元。并且，该装置1200中的各单元和上述其他操作和/或功能分别为了实现方法实施例中的第一网元中的方法实施例的相应流程。

其中，当该装置1200用于执行图3中的方法300时，收发单元1210可用于执行方法300中的步骤310、330；处理单元1220可用于执行方法300中的处理步骤，如步骤320。

当该装置1200用于执行图4中的方法400时，收发单元1210可用于执行方法400中的步骤410、420；处理单元1220可用于执行方法400中的处理步骤，如步骤401。

当该装置1200用于执行图5中的方法500时，收发单元1210可用于执行方法500中的步骤502、503、505、506；处理单元1220可用于执行方法500中的处理步骤，如步骤504。

当该装置1200用于执行图6中的方法600时，收发单元1210可用于执行方法600中的步骤604、605、608、609；处理单元1220可用于执行方法600中的处理步骤，如步骤607。

当该装置1200用于执行图7中的方法700时，收发单元1210可用于执行方法700中的步骤705、708、709；处理单元1220可用于执行方法700中的处理步骤，如步骤707。

当该装置1200用于执行图8中的方法800时，收发单元1210可用于执行方法800中的步骤804、805、808、809；处理单元1220可用于执行方法800中的处理步骤，如步骤807。

当该装置1200用于执行图9中的方法900时，收发单元1210可用于执行方法900中的步骤904、906-908、910、911；处理单元1220可用于执行方法900中的处理步骤，如步骤905。

当该装置1200用于执行图10中的方法1000时，收发单元1210可用于执行方法1000中的步骤1005、1008、1009、1011-1014；处理单元1220可用于执行方法1000中的处理步骤，如步骤1007

应理解，各单元执行上述相应步骤的具体过程在上述方法实施例中已经详细说明，为了简洁，在此不再赘述。

作为另一种设计，该装置1200用于执行上文方法实施例中第二网元所执行的动作。

一种可能的实现方式，收发单元1210，用于向第一网元发送第一请求消息，第一请求消息包括应用所需的业务链的信息；收发单元1210，还用于接收来自第一网元的指示信息，指示信息用于指示接受应用所需的业务链的请求。

该装置1200可实现对应于根据本申请实施例的方法实施例中的第二网元执行的步骤或者流程，该装置1200可以包括用于执行方法实施例中的第二网元执行的方法的单元。并且，该装置1200中的各单元和上述其他操作和/或功能分别为了实现方法实施例中的第二网元中的方法实施例的相应流程。

其中，当该装置1200用于执行图3中的方法300时，收发单元1210可用于执行方法300中的步骤310、320；处理单元1220可用于执行方法300中的处理步骤，如步骤301。

当该装置1200用于执行图5中的方法500时，收发单元1210可用于执行方法500中的步骤502、503；处理单元1220可用于执行方法500中的处理步骤，如步骤501。

当该装置1200用于执行图6中的方法600时，收发单元1210可用于执行方法600中的步骤602、604、605、606；处理单元1220可用于执行方法600中的处理步骤，如步骤603。

当该装置1200用于执行图7中的方法700时，收发单元1210可用于执行方法700中的步骤701、704、或705；处理单元1220可用于执行方法700中的处理步骤，如步骤702。

当该装置1200用于执行图8中的方法800时，收发单元1210可用于执行方法800中的步骤802、804、805、806；处理单元1220可用于执行方法800中的处理步骤，如步骤803。

当该装置1200用于执行图9中的方法900时，收发单元1210可用于执行方法900中的步骤902、904、909、或者904、906-908；处理单元1220可用于执行方法900中的处理步骤，如步骤903或905。

当该装置1200用于执行图10中的方法1000时，收发单元1210可用于执行方法1000中的步骤1001、1004、1005、1008、1009、1011-1014；处理单元1220可用于执行方法1000中的处理步骤，如步骤1002、1003、或1007。

当该装置1200用于执行图11中的方法1100时，收发单元1210可用于执行方法1100中的步骤1104；处理单元1220可用于执行方法1100中的处理步骤。

作为另一种设计，该装置1200用于执行上文方法实施例中第四网元所执行的动作。

一种可能的实现方式，收发单元1210，用于接收来自第一网元的请求消息，请求消息用于请求对一个或多个业务功能进行授权，或者，请求消息用于请求对应用对应的业务链策略进行授权；收发单元1210，还用于向第一网元发送该请求消息的响应消息。

一示例，收发单元1210，具体用于接收来自第一网元的请求消息，请求消息包括应用对应的业务链策略和访问该应用的用户的标识，该请求消息用于请求对用户访问的应用对应的业务链策略进行授权。

又一示例，收发单元1210，具体用于接收来自第一网元的请求消息，请求消息包括一个或多个业务功能的信息和访问应用的用户的标识，该请求消息用于请求对用户访问的应用对应的一个或多个业务功能的信息进行授权。

该装置1200可实现对应于根据本申请实施例的方法实施例中的第四网元执行的步骤或者流程，该装置1200可以包括用于执行方法实施例中的第四网元执行的方法的单元。并且，该装置1200中的各单元和上述其他操作和/或功能分别为了实现方法实施例中的第四网元中的方法实施例的相应流程。

其中，当该装置1200用于执行图4中的方法400时，收发单元1210可用于执行方法400中的步骤410、420；处理单元1220可用于执行方法400中的处理步骤。

当该装置1200用于执行图9中的方法900时，收发单元1210可用于执行方法900中的步骤906、907；处理单元1220可用于执行方法900中的处理步骤。

当该装置1200用于执行图10中的方法1000时，收发单元1210可用于执行方法1000中的步骤1005、1012、1013；处理单元1220可用于执行方法1000中的处理步骤。

作为另一种设计，该装置1200用于执行上文方法实施例中第五网元所执行的动作。

一种可能的实现方式，收发单元1210，用于接收来自第二网元的请求消息，请求消息包括应用所需的业务链的信息；处理单元1220，用于对应用所需的业务链的信息进行处理；收发单元1210，还用于向第一网元发送处理后的业务链的信息。

该装置1200可实现对应于根据本申请实施例的方法实施例中的第五网元执行的步骤或者流程，该装置1200可以包括用于执行方法实施例中的第五网元执行的方法的单元。并且，该装置1200中的各单元和上述其他操作和/或功能分别为了实现方法实施例中的第五网元中的方法实施例的相应流程。

其中，当该装置1200用于执行图6中的方法600时，收发单元1210可用于执行方法600中的步骤602、604、605、605；处理单元1220可用于执行方法600中的处理步骤，如步骤603。

当该装置1200用于执行图7中的方法700时，收发单元1210可用于执行方法700中的步骤701、704；处理单元1220可用于执行方法700中的处理步骤，如步骤702。

当该装置1200用于执行图8中的方法800时，收发单元1210可用于执行方法800中的步骤802、804-806；处理单元1220可用于执行方法800中的处理步骤，如步骤803。

当该装置1200用于执行图9中的方法900时，收发单元1210可用于执行方法900中的步骤902、904、908、909；处理单元1220可用于执行方法900中的处理步骤，如步骤903。

当该装置1200用于执行图10中的方法1000时，收发单元1210可用于执行方法1000中的步骤1001、1004；处理单元1220可用于执行方法1000中的处理步骤，如步骤1002、1003。

上文实施例中的处理单元1220可以由至少一个处理器或处理器相关电路实现。收发单元1210可以由收发器或收发器相关电路实现。存储单元可以通过至少一个存储器实现。

如图13所示，本申请实施例还提供一种装置1300。该装置1300包括处理器1310，处理器1310与存储器1320耦合，存储器1320用于存储计算机程序或指令和/或数据，处理器1310用于执行存储器1320存储的计算机程序或指令和/或数据，使得上文方法实施例中的方法被执行。

可选地，该装置1300包括的处理器1310为一个或多个。

可选地，如图13所示，该装置1300还可以包括存储器1320。

可选地，该装置1300包括的存储器1320可以为一个或多个。

可选地，该存储器1320可以与该处理器1310集成在一起，或者分离设置。

可选地，如图13所示，该装置1300还可以包括收发器1330，收发器1330用于信号的接收和/或发送。例如，处理器1310用于控制收发器1330进行信号的接收和/或发送。

作为一种方案，该装置1300用于实现上文方法实施例中由网络设备(如上述各个网元)执行的操作。

本申请实施例还提供一种装置1400，该装置1400可以是网络设备也可以是芯片。该装置1400可以用于执行上述方法实施例中由网络设备(如上述各个网元)所执行的操作。

图14示出了一种简化的结构示意图。装置1400包括1410部分以及1420部分。1410部分主要用于射频信号的收发以及射频信号与基带信号的转换；1420部分主要用于基带处理，对基站进行控制等。1410部分通常可以称为收发单元、收发机、收发电路、或者收发器等。1420部分通常是基站的控制中心，通常可以称为处理单元，用于控制基站执行上述方法实施例中接收端设备侧的处理操作。

1410部分的收发单元，也可以称为收发机或收发器等，其包括天线和射频电路，其中射频电路主要用于进行射频处理。可选地，可以将1410部分中用于实现接收功能的器件视为接收单元，将用于实现发送功能的器件视为发送单元，即1410部分包括接收单元和发送单元。接收单元也可以称为接收机、接收器、或接收电路等，发送单元可以称为发射机、发射器或者发射电路等。

1420部分可以包括一个或多个单板，每个单板可以包括一个或多个处理器和一个或多个存储器。处理器用于读取和执行存储器中的程序以实现基带处理功能以及对基站的控制。若存在多个单板，各个单板之间可以互联以增强处理能力。作为一种可选的实施方式，也可以是多个单板共用一个或多个处理器，或者是多个单板共用一个或多个存储器，或者是多个单板同时共用一个或多个处理器。

应理解，图14仅为示例而非限定，上述包括收发单元和处理单元的网络设备可以不依赖于图14所示的结构。

当该装置1400为芯片时，该芯片包括收发单元和处理单元。其中，收发单元可以是输入输出电路、通信接口；处理单元为该芯片上集成的处理器或者微处理器或者集成电路。当然装置1400还可以为一个芯片***或处理***，使得安装该装置1400的设备可以实现本申请实施例的方法和功能。例如，处理单元1420可以为芯片***或处理***中的处理电路，实现对安装了该芯片***或处理***的设备的控制，还可以耦合链接存储单元，调用存储单元中的指令，使得设备可以实现本申请实施例的方法和功能，收发单元1410，可以为芯片***或处理***中的输入输出电路，将芯片***处理好的信息输出，或将待处理的数据或信令信息输入芯片***进行处理。

本申请实施例还提供一种计算机可读存储介质，其上存储有用于实现上述方法实施例中由网络设备(如各个网元)执行的方法的计算机指令。

例如，该计算机程序被计算机执行时，使得该计算机可以实现上述方法实施例中由网络设备执行的方法。

本申请实施例还提供一种包含指令的计算机程序产品，该指令被计算机执行时使得该计算机实现上述方法实施例中由网络设备(如各个网元)执行的方法。

本申请实施例还提供一种通信***，该通信***包括上文实施例中的网络设备(如各个网元)，如AF和PCF，或者，NEF和PCF，或者，AF、NEF以及PCF，等等。

上述提供的任一种装置中相关内容的解释及有益效果均可参考上文提供的对应的方法实施例，此处不再赘述。

应理解，本申请实施例中提及的处理器可以是中央处理单元(centralprocessing unit，CPU)，还可以是其他通用处理器、数字信号处理器(digital signalprocessor，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现成可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

还应理解，本申请实施例中提及的存储器可以是易失性存储器和/或非易失性存储器。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)。例如，RAM可以用作外部高速缓存。作为示例而非限定，RAM可以包括如下多种形式：静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic RAM，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data rate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlinkDRAM，SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM，DR RAM)。

需要说明的是，当处理器为通用处理器、DSP、ASIC、FPGA或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件时，存储器(存储模块)可以集成在处理器中。

还需要说明的是，本文描述的存储器旨在包括但不限于这些和任意其它适合类型的存储器。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的保护范围。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。此外，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元实现本申请提供的方案。

另外，在本申请各个实施例中的各功能单元可以集成在一个单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。例如，所述计算机可以是个人计算机，服务器，或者网络设备等。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘(solid state disk，SSD)等。例如，前述的可用介质可以包括但不限于：U盘、移动硬盘、只读存储器(read-onlymemory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims

1.一种确定策略的方法，其特征在于，包括：

第一网元接收来自第二网元的第一请求消息，所述第一请求消息包括应用所需的业务链的信息；

所述第一网元向第三网元发送应用对应的业务链策略，所述应用对应的业务链策略是根据所述应用所需的业务链的信息制定的。

2.根据权利要求1所述的方法，其特征在于，所述应用所需的业务链的信息为所述应用所需的业务链标识。

3.根据权利要求1所述的方法，其特征在于，所述应用所需的业务链的信息为所述应用所需的一个或多个业务功能的信息。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

所述第一网元根据所述应用所需的一个或多个业务功能的信息，确定支持所述应用的一个或多个业务功能的信息，并向所述第二网元发送所述支持所述应用的一个或多个业务功能的信息。

5.根据权利要求3或4所述的方法，其特征在于，

所述一个或多个业务功能的信息，为所述一个或多个业务功能的标识或类型。

6.根据权利要求1所述的方法，其特征在于，所述第一网元接收来自第二网元的第一请求消息，所述第一请求消息包括应用所需的业务链的信息，包括：

所述第一网元接收来自所述第二网元的所述第一请求消息，所述第一请求消息包括所述应用所需的业务链的信息与所述数据网络接入标识之间的对应关系。

7.根据权利要求6所述的方法，其特征在于，所述第一网元向第三网元发送应用对应的业务链策略，包括：

所述第一网元向所述第三网元发送所述应用对应的业务链策略与所述数据网络接入标识之间的对应关系。

8.根据权利要求1所述的方法，其特征在于，

第一网元向第四网元发送第二请求消息，所述第二请求消息包括所述应用对应的业务链策略和访问所述应用的用户的标识，所述第二请求消息用于请求对所述用户访问所述应用对应的业务链策略进行授权。

9.根据权利要求3所述的方法，其特征在于，

所述第一网元向第四网元发送第三请求消息，所述第三请求消息包括所述支持的一个或多个业务功能的信息和访问所述应用的用户的标识，所述第三请求消息用于请求对支持所述用户访问的所述应用的一个或多个业务功能进行授权。

10.一种确定策略的方法，其特征在于，包括：

第二网元向第一网元发送第一请求消息，所述第一请求消息包括应用所需的业务链的信息；

所述第二网元接收来自所述第一网元的指示信息，所述指示信息用于指示接受所述应用所需的业务链的请求。

11.根据权利要求10所述的方法，其特征在于，所述应用所需的业务链的信息为以下任一项：

所述应用所需的业务链标识、所述应用所需的外部业务链标识、所述应用所需的一个或多个业务功能的信息、所述应用所需的一个或多个外部业务功能的信息、所述应用所需的业务链的信息与数据网络接入标识之间的对应关系。

12.根据权利要求10或11所述的方法，其特征在于，所述方法还包括：

所述第二网元接收来自所述第一网元的支持所述应用的一个或多个业务功能的信息；或者，所述第二网元接收来自所述第一网元的支持所述应用的一个或多个外部业务功能的信息。

13.根据权利要求11或12所述的方法，其特征在于，所述一个或多个业务功能的信息，为所述一个或多个业务功能的标识或类型。

14.根据权利要求10至13中任一项所述的方法，其特征在于，在向所述第一网元发送第一请求消息之前，所述方法还包括：

所述第二网元向第五网元发送第二请求消息，所述第二请求消息包括查询的业务链的信息；

所述第二网元接收来自所述第五网元的支持所述查询的业务链的以下一项或多项信息：业务功能标识、业务链标识、业务功能标识和数据网络接入标识对应关系、业务链标识和数据网络接入标识对应关系。

15.一种通信装置，其特征在于，包括用于执行如权利要求1至9中任一项所述的方法的模块。

16.一种通信装置，其特征在于，包括用于执行如权利要求10至14中任一项所述的方法的模块。

17.一种通信***，其特征在于，所述通信***包括第一网元和第二网元；

所述第二网元，用于向所述第一网元发送第一请求消息，所述第一请求消息包括应用所需的业务链的信息；

所述第一网元，用于向第三网元发送应用对应的业务链策略，所述应用对应的业务链策略是根据所述应用所需的业务链的信息制定的。

18.根据权利要求17所述的通信***，其特征在于，所述通信***还包括第三网元，

所述第三网元，用于接收来自所述第一网元的应用对应的业务链策略与数据网络接入标识之间的对应关系的信息，其中，数据网络接入标识包括第一数据网络接入标识；根据所述第一数据网络接入标识选择用户面网元，并指示所述用户面网元执行第一业务链策略，所述第一业务链策略为所述第一数据网络接入标识对应的业务链策略。

19.根据权利要求18所述的通信***，其特征在于，所述第三网元还用于：向所述第一网元发送所述第一数据网络接入标识；或者，向所述第一网元发送所述第一业务链策略。

20.根据权利要求19所述的通信***，所述第一网元还用于：接收所述第三网元发送的所述第一数据网络接入标识，并根据所述第一数据网络接入标识确定所述用户访问所述应用对应的业务链策略；或者，接收所述第三网元发送的所述第一数据网络接入标识，并根据所述第一数据网络接入标识确定支持所述用户访问的所述应用的一个或多个业务功能；或者，所述第三网元向所述第一网元发送所述第一业务链策略，并根据所述第一业务链策略确定所述支持所述用户访问的所述应用的一个或多个业务功能。

21.根据权利要求17至20中任一项所述的通信***，其特征在于，所述通信***还包括第四网元，

所述第四网元，用于接收来自所述第一网元的第二请求消息或第三请求消息，其中，所述第二请求消息包括所述应用对应的业务链策略和访问所述应用的用户的标识，所述第二请求消息用于请求对所述用户访问所述应用对应的业务链策略进行授权；所述第三请求消息包括所述支持的一个或多个业务功能的信息和访问所述应用的用户的标识，所述第三请求消息用于请求对支持所述用户访问的所述应用的一个或多个业务功能进行授权。

22.根据权利要求17至21中任一项所述的通信***，其特征在于，所述通信***还包括第五网元，

所述第五网元，用于接收来自所述第二网元的所述第一请求消息；对所述应用所需的业务链的信息进行处理，并且向所述第一网元发送处理后的所述业务链的信息。

23.一种通信装置，其特征在于，包括至少一个处理器，所述至少一个处理器用于执行如权利要求1至9中任一项所述的方法。

24.一种通信装置，其特征在于，包括至少一个处理器，所述至少一个处理器用于执行如权利要求10至14中任一项所述的方法。

25.一种计算机可读存储介质，其特征在于，所述计算机可读介质存储有计算机程序；所述计算机程序由一个或多个处理器执行时，使得包括所述处理器的装置执行如权利要求1至14中任一项所述的方法。