CN118055393A - 一种业务处理方法及装置 - Google Patents

Abstract

本申请提出了一种业务处理方法及装置，会话管理功能网元设备获取业务配置文件及其管理的各用户面功能网元设备的状态信息后，可以基于业务配置文件中为各用户面功能网元设备分配到的各业务配置的初始服务能力值以及状态信息，获得该会话管理功能网元设备对当前支持的各业务的实际服务能力值后，向网络仓储功能网元设备发送包含针对会话管理功能网元设备当前支持的各业务的实际服务能力值的服务消息，以使得接入和移动性管理功能网元设备能够据此针对所请求业务，可靠选择合适的会话管理功能网元设备实现。其中，支持同一业务的不同会话管理功能网元设备对应的实际服务能力值越大，会话管理功能网元设备分配到相应业务请求的概率越高。

Description

一种业务处理方法及装置

技术领域

本申请主要涉及通信技术领域，更具体地说是涉及一种业务处理方法及装置。

背景技术

在5G(5th-Generation，第五代移动通信)通信系统中，如图1所示，通常需要部署多个业务网元设备，例如AMF(Access and Mobility ManagementFunction，接入和移动性管理功能)网元设备、NRF(Network Repository Function，网络仓储功能)网元设备、SMF(Session Management Function，会话管理功能)网元设备、UPF(User Plane Function，用户面功能)网元设备等，按照如图1所示的网元连接关系，满足接入网络的各用户终端UE(User Equipment)的业务处理需求。

其中，针对AMF网元设备获得的来自不同UE的业务请求，通常是按照各SMF网元设备的服务注册信息，通过相应的SMF网元设备发送至UPF网元设备，为UE提供所需的会话业务服务。然而，在UPF网元设备故障或UPF网元设备与SMF网元设备之间的通信断开的情况下，将导致该SMF网元设备无法执行注册的业务服务，也就无法满足相应UE的业务处理需求。

发明内容

为了解决上述技术问题，本申请提供了以下技术方案：

一方面，本申请提出了一种业务处理方法，所述方法包括：

获取会话管理功能网元设备的业务配置文件，以及所述会话管理功能网元设备管理的各用户面功能网元设备的状态信息；所述业务配置文件包括为所述各用户面功能网元设备分配到的各业务配置的初始服务能力值；

基于所述初始服务能力值和所述状态信息，获得所述会话管理功能网元设备对当前支持的各所述业务的实际服务能力值；

向网络仓储功能网元设备发送服务消息；所述服务消息包含针对所述会话管理功能网元设备当前支持的各所述业务的实际服务能力值；

其中，支持同一所述业务的不同所述会话管理功能网元设备对应的所述实际服务能力值越大，所述会话管理功能网元设备分配到相应业务请求的概率越高。

可选的，所述基于所述初始服务能力值和所述状态信息，获得所述会话管理功能网元设备对当前支持的各所述业务的实际服务能力值，包括：

基于所述状态信息，从所述会话管理功能网元设备管理的多个所述用户面功能网元设备中，确定出处于通信连接状态下的待定用户面功能网元设备；

从所述业务配置文件中，确定出为各所述待定用户面功能网元设备分配到的各所述业务配置的初始服务能力值；

利用各所述待定用户面功能网元设备对应的所述初始服务能力值，获得所述会话管理功能网元设备对当前支持的各所述业务的实际服务能力值。

可选的，所述利用各所述待定用户面功能网元设备对应的所述初始服务能力值，获得所述会话管理功能网元设备对当前支持的各所述业务的实际服务能力值，包括：

确定同一所述业务分配到不同所述待定用户面功能网元设备对应的所述初始服务能力值；

对分配到不同所述待定用户面功能网元设备的同一所述业务配置的多个所述初始服务能力值进行合并，得到所述会话管理功能网元设备当前支持该业务的实际服务能力值。

可选的，所述获取会话管理功能网元设备的业务配置文件，包括：

获得会话管理功能网元设备管理的各用户面功能网元设备的设备信息，以及所述会话管理功能网元设备支持的各业务的业务识别信息；任一所述业务被分配到至少一个所述用户面功能网元设备；

基于所述设备信息和所述业务识别信息，确定针对各所述用户面功能网元设备分配到的各所述业务配置的初始服务能力值；

利用与所述设备信息和所述业务识别信息对应的所述初始服务能力值，构成所述会话管理功能网元设备的业务配置文件。

可选的，所述基于所述初始服务能力值和所述状态信息，获得所述会话管理功能网元设备对当前支持的各所述业务的实际服务能力值，包括：

从所述业务配置文件中，确定出各所述业务识别信息对应的至少一个所述初始服务能力值和所述用户面功能网元设备的设备信息；

基于所述状态信息，确定处于通信连接状态下的所述用户面功能网元设备的第一设备信息，以及处于通信断开状态下的所述用户面功能网元设备的第二设备信息；

将任一所述业务识别信息对应各所述第一设备信息对应配置的所述初始服务能力值增加至所述会话管理功能网元设备支持的相应所述业务的服务能力值，并将对应各所述第二设备信息对应配置的所述初始服务能力值确定为零后增加至所述会话管理功能网元设备支持的相应所述业务的服务能力值，得到所述会话管理功能网元设备当前支持的相应所述业务的实际服务能力值。

可选的，所述方法还包括：

基于所述状态信息，确定任一所述用户面功能网元设备与所述会话管理功能网元设备之间的通信状态发生变化；

从所述业务配置文件中，确定为所述通信状态发生变化的所述用户面功能网元设备分配到的各所述业务配置的所述初始服务能力值；

基于确定的所述初始服务能力值，更新所述会话管理功能网元设备支持的对应所述业务的实际服务能力值，

向所述网络仓储功能网元设备发送服务更新消息；所述服务更新消息包括针对所述会话管理功能网元设备当前支持的相应所述业务更新后的实际服务能力值。

另一方面，本申请还提出了一种业务处理方法，所述方法包括：

获得业务请求；所述业务请求包含请求目标业务的目标业务识别信息；

基于所述目标业务识别信息，确定网络仓储功能网元设备存储的支持所述目标业务的至少一个会话管理功能网元设备针对所述目标业务的实际服务能力值；

基于所述至少一个会话管理功能网元设备各自针对所述目标业务的实际服务能力值，确定目标会话管理功能网元设备；

将所述业务请求分配至所述目标会话管理功能网元设备，由所述目标会话管理功能网元设备响应所述业务请求；

其中，支持同一业务的不同所述会话管理功能网元设备对应的所述实际服务能力值越大，所述会话管理功能网元设备分配到相应业务请求的概率越高。

可选的，所述基于所述至少一个会话管理功能网元设备各自针对所述目标业务的实际服务能力值，确定目标会话管理功能网元设备，包括

如果所述网络仓储功能网元设备存储有与所述目标业务识别信息对应的多个会话管理功能网元设备各自针对所述目标业务的实际服务能力值，将最大所述实际服务能力值对应的一个所述会话管理功能网元设备确定为目标会话管理功能网元设备；

如果最大所述实际服务能力值对应的所述会话管理功能网元设备是多个，随机或按照这多个所述会话管理功能网元设备排序选择其中的一个所述会话管理功能网元设备为目标会话管理功能网元设备。

又一方面，本申请还提出了一种业务处理装置，所述装置包括：

业务配置文件获取模块，用于获取会话管理功能网元设备的业务配置文件；所述业务配置文件包括为所述会话管理功能网元设备管理的各用户面功能网元设备分配到的各业务配置的初始服务能力值；

状态信息获取模块，用于获取所述会话管理功能网元设备管理的各用户面功能网元设备的状态信息；

实际服务能力值获得模块，用于基于所述初始服务能力值和所述状态信息，获得所述会话管理功能网元设备对当前支持的各所述业务的实际服务能力值；

服务消息发送模块，用于向网络仓储功能网元设备发送服务消息；所述服务消息包含针对所述会话管理功能网元设备当前支持的各所述业务的实际服务能力值；其中，支持同一所述业务的不同所述会话管理功能网元设备对应的所述实际服务能力值越大，所述会话管理功能网元设备分配到相应业务请求的概率越高。

又一方面，本申请还提出了一种业务处理装置，所述装置包括：

业务请求获得模块，用于获得业务请求；所述业务请求包含请求目标业务的目标业务识别信息；

实际服务能力值确定模块，用于基于所述目标业务识别信息，确定网络仓储功能网元设备存储的支持所述目标业务的至少一个会话管理功能网元设备针对所述目标业务的实际服务能力值；

目标会话管理功能网元设备确定模块，用于基于所述至少一个会话管理功能网元设备各自针对所述目标业务的实际服务能力值，确定目标会话管理功能网元设备；

业务请求分配模块，用于将所述业务请求分配至所述目标会话管理功能网元设备，由所述目标会话管理功能网元设备响应所述业务请求；

其中，支持同一业务的不同所述会话管理功能网元设备对应的所述实际服务能力值越大，所述会话管理功能网元设备分配到相应业务请求的概率越高。

附图说明

为了更清楚地说明本申请实施例或相关技术中的技术方案，下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为一种5G通信系统的结构示意图；

图2为本申请提出的业务处理方法的可选实施例一的流程示意图；

图3为本申请提出的业务处理方法的可选实施例二的流程示意图；

图4为本申请提出的业务处理方法的可选实施例三的流程示意图；

图5为本申请提出的业务处理方法的可选实施例四的流程示意图；

图6为本申请提出的业务处理方法的可选实施例五的流程示意图；

图7为本申请提出的业务处理装置的一可选实施例的结构示意图；

图8为本申请提出的业务处理装置的另一可选实施例的结构示意图。

具体实施方式

结合背景技术部分的描述内容，参照图1所示的5G通信系统，为了更准确理解技术方案，下面先对系统中的各网元设备的功能进行解释：

AMF(Access and Mobility ManagementFunction，接入和移动性管理功能)网元设备作为系统的核心单元，可以负责用户终端UE(User Equipment)在开机后的整个生命周期内的注册管理、连接管理、接入性管理、移动性管理以及与安全和访问管理和授权相关的各种功能，支持网络切片，实现SMF(Session Management Function，会话管理功能)网元设备的选择。在系统的SBA架构下，该核心网网元可以通过SBI(Service Based Interfcae，基于服务的接口/服务化接口)，实现与其他网元设备的通信连接。

NRF(Network Repository Function，网络仓储功能)网元设备，用于进行网元设备的网络功能登记注册、管理、状态检测，实现各网元设备的管理。

SMF网元设备负责处理用户的业务，实现会话管理包括UE IP地址分配与管理，UPF(User Plane Function，用户面功能)网元设备的选择与控制、下行数据通知等，可以与AMF网元设备一起支持定制的移动性管理方案。

UPF网元设备负责核心网中用户平面数据包的路由和转发相关功能，可以支持UE业务数据的路由和转发、数据和业务识别、动作和策略执行等，在实际应用中，可以通过N4接口与SMF网元设备交互，由SMF网元设备直接控制和管理，并根据SMF发布的各种策略执行业务流处理。

DNN(Data Network Name，数据网络名称，本申请可以称为业务访问网络名称)，可以用于区分不同数据网络的接入，根据DNN可以将会话分流汇聚到不同的SMF网元设备，进而分流到下游的不同UPF网元设备，实现用户终端定向访问。

结合上文描述的各网元设备的功能和通信连接关系，为了解决背景技术部分描述的技术问题，本申请提出在任一SMF网元设备中，将其支持业务的服务能力分担到与该SMF网元设备连接的各UPF网元设备上，为每个UPF网元设备绑定的各业务配置一定的服务能力值(serviceability)，从而使该SMF网元设备能够基于其连接的各UPF网元设备的状态，将初始配置的各业务的服务能力值合并，作为该SMF网元设备对相应业务的当前服务能力值，及时上报至NRF网元设备，使得AMF网元设备能够准确得知系统中各SMF网元设备支持的各业务的当前服务能力值，辅助其选择最合适的SMF网元设备请求业务，可靠且高效满足UE的业务处理需求。

由此可见，系统中的各SMF网元设备会结合所连接的各UPF网元设备的状态，来精准确定该SMF网元设备对当前支持的各业务的实际服务能力值，这样，因UPF网元设备故障或SMF网元设备与该UPF网元设备失去连接，使得该SMF网元设备无法继续与该UPF网元设备完成N4通信的情况，或者是故障的某UPF网元设备恢复正常，能够继续对分配到的至少一种业务提供服务的情况下，都可以按照这种业务处理方法，动态更新该SMF网元设备对当前支持的各业务的实际服务能力值，并及时上报至NRF网元设备，从而使AMF网元设备能够基于各SMF网元设备当前对各业务的实际服务能力值，对请求业务选择合适的SMF网元设备，可靠满足UE的业务处理需求，不会再将业务请求发送至无法提供相应服务的SMF网元设备，避免了因该SMF网元设备无法继续与相应UPF网元设备通信连接，导致业务流程失败的情况发生，提高了请求业务可靠性。

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，本申请使用流程图用来说明根据本申请实施例的系统所执行的操作。需要说明的是，流程图中前面或后面操作不一定按照顺序来精确地执行，根据实际业务处理需求，也可以按照倒序或同时处理各个步骤，或者互换特定的顺序或先后次序，以使下文描述的本申请实施例能够以除了附图所示或文字描述以外的顺序实施。当然，还可以将其他操作添加到这些过程中，或从这些过程移除某一步或数步操作，得到其他实施例。显然，本申请下文所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

参照图2，为本申请提出的业务处理方法的可选实施例一的流程示意图，该业务处理方法可以应用于5G通信系统，本实施例可以从SMF网元设备侧描述本申请提出的业务处理方法。需要说明，本申请提供的业务处理方法也可以应用于未来演进的其他通信系统，如6G(6th Generation，第六代)通信系统等，由其中相当于5G通信系统的SMF网元设备的设备执行本实施例描述的业务处理方法。本申请下文各实施例仅以5G通信系统的应用场景为例进行说明，结合1所示的5G通信系统的网络架构，如图2所示，本实施例中提出的业务处理方法可以包括：

步骤S21，获取SMF网元设备的业务配置文件，以及SMF网元设备管理的各UPF网元设备的状态信息；该业务配置文件包括为各UPF网元设备分配到的各业务配置的初始服务能力值；

本申请实际应用中，结合上文对本申请技术方案的相关描述，可以在SMF网元设备的服务注册过程中，可以配置该SMF网元设备能够管理的至少一个UPF网元设备以及支持的至少一种业务，并将各业务分配到该SMF网元设备能够管理的UPF网元设备，使得任一UPF网元设备能够分配到至少一种业务，由于本申请是将该SMF网元设备的业务服务能力分担到不同UPF网元设备，可以为任一UPF网元设备分配到的各业务配置一一对应的初始服务能力值，来表达该UPF网元设备与SMF网元设备正常通信情况下，能够为分配到的对应类型业务所提供的服务能力，从而结合这些配置内容，生成该SMF网元设备的业务配置文件。

需要说明，本申请对任一SMF网元设备配置管理的UPF网元设备类型和数量，所注册支持的业务数量和类型，为每个UPF网元设备分配到的业务以及对每个业务配置的初始服务能力值的数值等均不做限制，可以依据实际通信资源以及通信场景需求确定。

其中，由于5G通信网络可以采用网络切片架构，以优化网络性能，这样，可以通过多个网络切片，实现无线接入网络、承载网到核心网上的逻辑隔离，适配各种类型的应用，实现不同业务。对于各网络切片，可以配置对应的通过S-NSSAI(Single Network SliceSelection Assistance Information)参数来进行识别，通过SST(Slice/Serive Type，切片/服务类型)，如8位字段长度标识，来指示S-NSSAI的切片服务类型即业务切片类型。

针对基于网络切片架构所确定的不同数据网络的接入点和接入方式，可以配置对应的DNN(Data NetworkName，数据网络名称，本申请可以称为业务访问网络名称)，这样，对于SMF网元设备支持的不同业务，如各种即时通信业务、各视频播放业务以及各视频通信业务，可以由SST和DNN的组合进行区分，但并不局限于这种业务区分方式。

示例性的，结合上述分析，以图1所示的5G通信系统架构为例进行说明，参照下表1所示的SMF1网元设备的业务配置文件，以及表2所示的SMF2网元设备的业务配置文件，表中“业务切片类型SST”字段和“业务访问网络名称DNN”字段下的内容可以是业务的不同属性，这两个字段内容组合表示一种业务，其并不局限于表1和表2所支的内容。对于每个SMF网元设备连接的各UPF网元设备，可以采用键值key-value方式进行管理，如将UPF网元设备的名称确定为key，将该UPF网元设备的IP地址等配置参数确定为value，以通过key识别不同的UPF网元设备，但并不局限于本申请描述的这种不同UPF网元设备的识别以及管理方法。

基于此，如表1所示，SMF1网元设备所支持的具有“SST1+DNN1”属性的业务，可由UPF1网元设备和UPF2网元设备提供服务，而具有“SST2+DNN2”或“SST3+DNN3”属性的业务，都是由一个UPF网元设备(表1中同一行所示的“服务的UPF网元设备”这一字段的内容)提供相应业务服务。同理，如表2所示配置的SMF2网元设备，对于其支持的具有“SST1+DNN1”属性的业务，以及具有“SST5+DNN5”属性的业务都可以由UPF3网元设备提供服务。

需要说明，由于下表中并未示出相应SMF网元设备所支持的所有业务属性字段以及提供服务的所有UPF网元设备，对于支持下表中当前示出的各业务的提供服务的UPF网元设备包括但并不局限于上文描述的内容，本申请仅以下表中当前示出内容为例进行说明，应该理解，在下表内容(即相应SMF网元设备的配置文件内容)更新或补充后，可以按照上文描述的技术思路确定SMF网元设备所支持的每一业务提供服务的各UPF网元设备，本申请不做一一举例详述。

可选的，对于通信系统中任一SMF网元设备所管理的任一UPF网元设备，为其分配到的每一业务配置的初始服务能力值可以相同，如下表1和表2所示的“服务能力值”这一字段中的10。此外，也可以结合不同SMF网元设备所能够提供的业务服务能力和支持的业务类型和数量，以及各UPF网元设备所能提供的服务能力等，综合确定各UPF网元设备为每一业务提供服务的初始服务能力值，此时确定的各初始服务能力值可能不同，即各SMF网元设备的业务配置文件中“服务能力值”这一字段中的数值可以不一致，可以从0-255中取值，确定各初始服务能力值。

表1

表2

结合上文对业务配置文件的相关描述，对于任一SMF网元设备支持的各业务对应的配置内容，本申请也可以采用key-value方式记录，如上表1和表2所示的业务配置文件，可以将表中每一行的“业务切片类型SST”字段和“业务访问网络名称DNN”字段的组合内容，与“服务的UPF网元设备”字段的内容一起构成key，将该行“服务能力值”字段对应的初始服务能力值确定为value参数。需要说明，关于SMF网元设备的业务配置文件内容的表示方式和记录方式，包括但并不局限于上文描述的内容。

在实际应用中，由于通信系统中各UPF网元设备是否正常工作，以及各UPF网元设备与其对应的SMF网元设备之间是否通信连接等，直接影响该SMF网元设备能否实现所支持的相应业务，即UPF网元设备与SMF网元设备之间能否正常通信，决定能否为用户终端提供该UPF网元设备分配到的业务。为了避免AMF网元设备将业务请求继续发送至该通信异常的SMF网元设备，导致请求业务流程失败的情况发生，本申请将结合UPF网元设备与SMF网元设备之间的实际通信情况，动态确定SMF网元设备实际所能提供的业务服务能力，以保证AMF网元设备所选择响应业务请求的SMF网元设备，能够与提供请求业务服务的UPF网元设备正常通信，保证业务流程成功。

因此，通信系统中的任一SMF网元设备可以实时或周期性或按照其他规则获得所管理的各UPF网元设备的状态信息，该状态信息能够表示当前对应UPF网元设备能否正常工作，以及该UPF网元设备与对应SMF网元设备之间的通信是否正常等，本申请对各UPF网元设备的状态信息的内容及其获得方法不做限制。

步骤S22，基于初始服务能力值和状态信息，获得SMF网元设备对当前支持的各业务的实际服务能力值；

结合上文对业务配置文件的相关描述，由于SMF网元设备是将其具有的业务服务能力分担到所管理的各UPF网元设备上，满足所支持业务的服务需求，且需要UPF网元设备自身运行正常，且其与对应SMF网元设备(即管理该UPF网元设备的SMF网元设备)通信连接，才能够保证各UPF网元设备实现所分配到的业务。一旦其中的任一UPF网元设备故障或与该SMF网元设备的通信连接断开，该UPF网元设备分配到的业务服务能力失效，导致使该SMF网元设备的业务服务能力下降，甚至会导致其原来支持的某业务无法实现。

因此，为了精准确定SMF网元设备当前具有的业务服务能力，本申请可以先确定分担到部分业务服务能力的各UPF网元设备当前能否实现所分担到的业务服务能力。如上述分析，本申请可以通过对当前获得的各UPF网元设备的状态信息进行分析，来确定相应UPF网元设备分担到的业务服务能力是否有效，以便统计各有效的业务服务能力，确定相应SMF网元设备当前所具有的业务服务能力。

这样，通过分析任一UPF网元设备的状态信息，确定该UPF网元设备是否出符合业务实现要求，如确定该UPF网元设备自身运行正常，且与对应的SMF网元设备成功通信连接，说明该UPF网元设备符合业务实现要求；确定该UPF网元设备自身故障，或与对应SMF网元设备之间的通信连接断开，说明该UPF网元设备不符合业务实现要求，即该UPF网元设备与对应SMF网元设备通信失败，无法继续提供所分配到的业务服务，不能再参与相应业务场景，后续可以使用剩余的其他UPF网元设备(即符合业务实现要求的UPF网元设备)参与后续处理。本申请对UPF网元设备的状态信息的分析方法不做限制，可以直接识别该状态信息的内容，来确定相应UPF网元设备与SMF网元设备通信是否正常。

之后，由于本申请是采用对UPF网元设备对应分配到的任一业务配置对应的初始服务能力值，来表示该UPF网元设备对实现该业务所能提供的业务服务能力大小，如该初始服务能力值越大，表示该UPF网元设备对实现该业务所提供的业务服务能力越大。所以，按照上文描述的方法，对于任一SMF网元设备，从其管理的各UPF网元设备中，确定与该SMF网元设备通信正常的UPF网元设备后，可以对确定出的各UPF网元设备分配到的各业务所配置的初始服务能力值进行统计，如对分配到同一业务的至少一个UPF网元设备各自对应的初始服务能力值求和，得到该SMF网元设备对该业务当前所能提供的实际服务能力值。

可见，在SMF网元设备管理的至少一个UPF网元设备所分担的业务服务能力失效或恢复，会使得该SMF网元设备对相应业务(即分配给该UPF网元设备的业务)所能提供的服务能力不同，本申请可以按照上文描述的方法，动态获得该SMF网元设备对所支持的各业务的实际服务能力值，即动态确定当前该SMF网元设备对实现任一业务实际能提供的业务服务能力，包括但并不局限于上文描述的实现方法。

步骤S23，向NRF网元设备发送服务消息；该服务消息包含针对SMF网元设备当前支持的各业务的实际服务能力值，支持同一业务的不同SMF网元设备对应的实际服务能力值越大，SMF网元设备分配到相应业务请求的概率越高。

对于通信系统中的任一SMF网元设备，可以在确定其管理的任一UPF网元设备的状态信息发生变化，或者按照预设的更新检测规则(如周期性检测规则等)，系统时间达到本次更新检测时间，或者接收到来自AMF网元设备的检测指令等，都可以按照上文描述的方法，确定当前该SMF网元设备实际支持的业务及其对应的实际服务能力值，并将其及时上报至NRF网元设备，以使AMF网元设备可以控制NRF网元设备，基于当前各SMF网元设备支持的不同业务的实际服务能力值，选择用于实现请求业务最合适的SMF网元设备，保障业务可靠实现。

其中，在不同SMF网元设备的选择过程中，由于不同SMF网元设备当前具有的针对不同业务的实际服务能力值，表征了该SMF网元设备当前所能提供的实际服务能力，这样，对于能够实现同一业务的多个SMF网元设备，就可以据此辅助AMF网元设备快速且准确，选择当前具有实现该业务的最大服务能力的SMF网元设备，可靠实现该业务，避免选择因SMF网元设备与UPF网元设备之间的通信失败，或因SMF网元设备所具有的服务能力较差，不足以支持实现相应业务等情况，而导致当前无法实现该业务的SMF网元设备继续响应业务请求，使得业务流程失败的情况发生，提高了业务实现效率和可靠性。

示例性的，参照图1所示的通信系统以及上表1所示的SMF1网元设备的业务配置文件，正常情况下，运行正常的UPF1网元设备可以通过N4接口与SMF1网元设备通信连接，以实现该UPF1网元设备所分配到的至少一种业务，如具有“SST1+DNN1”属性的业务1和具有“SST2+DNN2”属性的业务2，在用户终端请求该业务1和业务2的情况下，AMF网元设备请求业务1或业务2时，都可以将对应的业务请求发送至SMF1网元设备，通过SMF1网元设备与UPF1网元设备的通信实现所请求的业务1或业务2。

然而，在UPF1网元设备发生故障或其与SMF1网元设备的连接断开等异常情况下，该UPF1网元设备针对业务1和业务2分担到的业务服务能力无法再发挥，使得该SMF1网元设备对实现业务1和业务2各自具有的业务服务能力下降，甚至会导致该SMF1网元设备无法实现对应业务。面对这种情况，本申请通过当前获得的各UPF网元设备的状态信息，及时发现UPF1网元设备的异常情况，结合该UPF1网元设备对分配到的业务1和业务2各自配置的初始服务能力值，及时更新SMF1网元设备对支持业务1和业务2各自的服务能力值，如减小其对支持业务1和业务2各自的实际服务能力值，及时且准确地确定当前SMF1网元设备对支持业务1和业务2各自的实际服务能力值，将其发送至NRF网元设备。

这样，AMF网元设备能够从NRF网元设备的存储内容中，准确得知SMF1网元设备当前对实现业务1或业务2实际能提供的服务能力，如对实现业务2的实际服务能力值为零，说明SMF1网元设备无法实现业务2，不会再将业务2请求发送至SMF1网元设备，避免发送给SMF1网元设备而导致业务2流程失败，可以选择发送给其他能够实现业务2的SMF网元设备，实现过程可以参照下文从AMF网元设备侧描述的业务处理方法，本实施例在此不做详述。

需要说明，关于不同网元设备之间的通信方式，包括但并不局限于图1所示的方式，对于任一SMF网元设备最新获得的各业务的实际服务能力值，可以按照相应通信方式对应通信机制，生成包含但并不局限于各实际服务能力值的服务消息，将该服务消息上报至NRF网元设备。本申请对整个通信系统中的各SMF网元设备执行业务处理方法的各步骤的执行时机不做限制，不同SMF网元设备执行业务处理方法的过程可以相互独立。

参照图3，为本申请提出的业务处理方法的可选实施例二的流程示意图，本实施例可以对上文提出的业务处理方法的一可选细化实现方法进行描述，如图3所示，SMF网元设备执行的业务处理方法可以包括：

步骤S31，获取SMF网元设备的业务配置文件，以及SMF网元设备管理的各UPF网元设备的状态信息；该业务配置文件包括为各UPF网元设备分配到的各业务配置的初始服务能力值；

关于步骤S31的实现过程，可以按照上下文相应部分的描述，如步骤S21相应部分的描述内容，本实施例在此不做赘述。

步骤S32，基于该状态信息，从SMF网元设备管理的多个UPF网元设备中，确定出处于通信连接状态下的待定UPF网元设备；

结合上文对本申请技术方案的相关描述，由于SMF网元设备是将自身的业务服务能力分担到其管理的UPF网元设备，并为每个UPF网元设备分配至少一个业务后，依据该UPF网元设备对该业务所提供的业务服务能力，配置对应的初始服务能力值，构成该SMF网元设备的业务配置文件，如上文表1和表2所示的内容。因此，在任一UPF网元设备故障或SMF网元设备与该UPF网元设备失去连接，使得该SMF网元设备无法继续与该UPF网元设备完成N4通信的情况下，该UPF网元设备不能再对其分配到的业务提供服务，对于该SMF网元设备来说，该情况会导致为其支持的业务提供服务的UPF网元设备数量变少，甚至会不存在能提供业务服务的UPF网元设备，从而影响SMF网元设备实际所具有的业务服务能力。

基于此，为了精准确定当前SMF网元设备实际所具有的业务服务能力，本申请将结合其管理的各UPF网元设备的当前状态信息，来确定当前仍能实现其分担到的业务服务能力的UPF网元设备，也就是当前与该SMF网元设备之间的通信状态处于通信连接状态下的UPF网元设备，记为待定UPF网元设备。

在一些实施例中，对于上述获得的状态信息可以包括UPF网元设备处于通信连接状态或通信异常状态(其是指该UPF网元设备与SMF网元设备之间无法正常通信的状态)的状态标识，如1或0等，这样，可以通过识别各UPF网元设备的状态标识，确定出待定UPF网元设备。在另一些实施例中，SMF网元设备也可以通过向其管理的各UPF网元设备发送通信检测消息，若两者之间正常通信，能够接收到UPF网元设备反馈的通信响应消息；反之，无法接收到该通信响应消息，这样就可以将发送通信响应消息的UPF网元设备确定为待定UPF网元设备等。本申请对这类UPF网元设备的监测实现方法不做限制，可以结合通信需求进行灵活调整，本申请不做一一举例详述。

步骤S33，从该业务配置文件中，确定出为各待定UPF网元设备分配到的各业务配置的初始服务能力值；

步骤S34，利用各待定UPF网元设备对应的初始服务能力值，获得SMF网元设备对当前支持的各业务的实际服务能力值；

本申请实施例中，从任一SMF网元设备管理的全部UPF网元设备中，确定出的能够与该SMF网元设备正常通信的各待定UPF网元设备，是当前能够对用户终端提供业务服务的网元设备，本实施例可以对每一待定UPF网元设备在业务配置文件中对应配置的初始服务能力值进行统计，确定出该SMF网元设备当前对任一业务所能提供的总服务能力值，即对该业务的实际服务能力值，该实际服务能力值越大，表征当前该SMF网元设备对相应业务所能提供的服务能力越强，该SMF网元设备能够被选择实现该业务的概率越大。

如上述分析，在任一UPF网元设备故障或SMF网元设备与该UPF网元设备失去连接等通信异常情况下，按照上文描述的方法确定的该SMF网元设备对相应业务(即该UPF网元设备分配到的业务)的服务能力值会减小，降低了该SMF网元设备在实现该业务场景下的竞争力，即减小该SMF网元设备被选择实现该业务的概率；在该通信异常情况恢复后，仍可以按照上下文描述的方法，重新确定该SMF网元设备对相应业务的服务能力值，此时所得的实际服务能力值会增大，从而提高该SMF网元设备在实现该业务场景下的竞争力，即增大该SMF网元设备被选择实现该业务的概率。

可见，随着任一SMF网元设备管理的能够正常通信的UPF网元设备的数量变化，本申请将基于该SMF网元设备的业务配置文件内容，动态调整该SMF网元设备对各业务具有的实际服务能力值，保证该实际服务能力值精准表征该SMF网元设备对实现相应业务的服务能力。

在一种可能的实现方式中，本申请可以从该SMF网元设备的业务配置文件中，确定同一业务分配到不同待定UPF网元设备对应的初始服务能力值，再对分配到不同待定UPF网元设备的同一业务配置的多个初始服务能力值进行合并，得到SMF网元设备当前支持该业务的实际服务能力值。

示例性的，如表1所示的SMF1网元设备的业务配置文件，对于具有“SST1+DNN1”属性的业务1，将其分配给UPF1网元设备和UPF2网元设备，由这两个网元设备共同承担实现该业务1的服务能力，因此，将UPF1网元设备和UPF2网元设备对实现业务1配置的初始服务能力值(如表1中的10)合并，即10+10＝20，将得到的总服务能力值(即20)确定为该SMF1网元设备实现业务1的实际服务能力值。

而对于SMF1网元设备支持被分配给一个UPF网元设备的业务，无需合并处理，直接将该UPF网元设备对该业务配置的初始服务能力值，确定为SMF1网元设备实现该业务具有的实际服务能力值。如表1中，分配给UPF1网元设备的具有“SST2+DNN2”属性的业务2，以及分配给UPF2网元设备的具有“SST3+DNN3”属性的业务3等，由此确定SMF1网元设备实现业务2的实际服务能力值为10，实现业务3的实际服务能力值也为10。可以理解的是，在SMF1网元设备管理的UPF网元设备发生变化，或UPF网元设备分配到的业务或其配置的初始服务能力值发生变化的情况下，都可以按照上文描述的方法及时更新SMF1网元设备实现对应业务的实际服务能力值，实现过程类似，本申请不做详述。

以图1所示的通信系统架构，以及表1和表2各自所示的业务配置文件内容为例，按照上文实施例描述的SMF网元设备实现各业务的实际服务能力值得获取方法，可以对应得到表3所示的SMF1网元设备实现业务1、业务2和业务3各自的实际服务能力值，以及表4所示的SMF2网元设备实现业务1、业务5(即具有“SST5+DNN5”属性的业务)和业务6(即具有“SST6+DNN6”属性的业务)各自的实际服务能力值：

表3

表4

步骤S35，向NRF网元设备发送服务消息；该服务消息包含针对SMF网元设备当前支持的各业务的实际服务能力值。

本实施例实际应用中，通信系统中的任一SMF网元设备确定其对任一业务的服务能力发生变化，按照上文描述的方法，及时且准确获得当前对该业务的实际服务能力值后，可以通过SBI服务化的消息向NRF网元设备通告自己当前对该业务具有的服务能力，由于该服务能力是由该SMF网元设备管理的下游的UPF网元设备的服务能力统计得到，使得NRF网元设备以及能够访问该NRF网元设备的AMF网元设备能够据此得知该SMF网元设备下游的UPF网元设备是否正常通信，是否具有满足业务所需的服务能力，保证所选择响应业务请求的SMF网元设备能够可靠实现请求业务流程，提高业务实现效率和可靠性。

需要说明，对于任一SMF网元设备生成的上述服务消息，也可以直接发送至AMF网元设备，或者将服务消息发送至AMF网元设备和NRF网元设备，以使该AMF网元设备可以及时且正确了解当前各SMF网元设备对不同业务的实际服务能力值。

另外，对于步骤S35的服务消息包括但并不局限于SBI服务消息，可以结合通信系统的服务架构确定，本申请仅以图1所示的架构为例进行说明。基于此，SMF网元设备发送的服务消息的Nfprofile可以按在3GPP规范定义，在服务消息smfinfo中增加字段serviceability(即服务能力值)，得到JSON(JavaScript Object Notation,轻量级的数据转换格式)结构的smfinfo：{sNssaiSmfInfoList:[{sNssai:{sst:sst_value,sd:sd_value},dnnSmfInfoList:[{dnn:dnn_value，serviceability:value}]}]}。可见，该smfinfo依次包含上表3和表4中“业务切片类型SST”字段、“业务访问网络名称DNN”字段以及“服务能力值”字段的内容。示例性的，参照表1所示内容，针对SMF1网元设备的各业务服务能力的服务消息Nfprofile中，实现业务1的smfinfo可以为：

同理，对于表示SMF1网元设备实现其他业务的实际服务能力值的服务消息内容，可以按照上述格式表达，本实施例不再一一举例详述。此外，对于各SMF网元设备，可以在服务消息中说明网元设备id，如nfInstanceId:smf1，其所属的网元设备nf的类型，即nfType:SMF，网元设备是否已注册/登记(REGISTERED)状态，如nfStatus:REGISTERED，该SMF网元设备支持的业务容量capacity，如表3中的capacity:3。

根据需要还可以通过心跳计时器heartBeatTimer来记录对应网元设备的更新次数，确定各网元设备的接入点配置信息，如mcc(mobile country code,移动国家号码，用于识别移动客户所属国家的唯一标识):460,mnc(mobile networkcode，移动网络号码，用于识别移动客户所属网络的标识):30等。此外，还可以在服务消息中配置其ipv4(InternetProtocolversion 4，互联网通信协议第四版)Addresses(地址)，如10.42.137.81等。对于每一SMF网元设备可以配置对应的服务实例id，如serviceInstanceId:smf1，对应的服务名称，如serviceName:nsmf-pdusession，以及对应的版本(versions)信息，如apiVersionInUri:v1，apiFullVersion:1.0.0。按照上述服务地址进行数据传输遵循的传输协议transport和传输端口port，如transport:TCP，port:80等内容，本申请对服务消息的内容不做限制，可以依据通信格式要求确定。

参照图4，为本申请提出的业务处理方法的可选实施例三的流程示意图，本实施例可以对上文提出的业务处理方法的另一可选细化实现方法进行描述，如对SMF网元设备的业务配置文件的获取过程，以及对支持的各种业务的实际服务能力值的获取方法进行细化描述，但并不局限于本实施例描述的这种实现方式。如图4所示，任一SMF网元设备执行的业务处理方法可以包括：

步骤S41，获得SMF网元设备管理的各UPF网元设备的设备信息，以及SMF网元设备支持的各业务的业务识别信息；任一业务被分配到至少一个UPF网元设备；

结合上文实施例对SMF网元设备的业务配置文件的相关描述，通信系统中任一SMF网元设备支持的任一业务的业务识别信息可以包括该业务的各种属性信息，如上述“业务切片类型SST”字段和“业务访问网络名称DNN”字段对应的内容，用以识别该SMF网元设备所支持的不同业务。当然，业务识别信息还可以包括相应业务的其他属性信息，本申请对其内容不做限制，可视情况而定。

本申请实施例中，可以通过UPF网元设备的设备信息，来识别通信系统所配置的不同UPF网元设备，因此，该设备信息可以是区别不同UPF网元设备的唯一标识信息，如UPF网元设备的名称等key，以便据此读取对应UPF网元设备的网络地址即IP地址，如上述表1和表2中“服务的UPF网元设备”字段记录的内容，本申请对各UPF网元设备的设备信息的内容及其获得方法不做限制。

步骤S42，基于该设备信息和业务识别信息，确定针对各UPF网元设备分配到的各业务配置的初始服务能力值；

由于本申请的SMF网元设备是将其业务的服务能力分担到不同的UPF网元设备，从而将SMF网元设备支持实现的每一个业务，分配给下游的至少一个UPF网元设备，使得每一UPF网元设备分配到至少一个业务，参照表1和表2的内容，对于每一个UPF网元设备分配到的每一个业务，可以配置对应的初始服务能力值，如默认相同的能力值10，并不局限于该数值。这种情况下，基于设备信息和业务识别信息，识别该SMF网元设备所管理的各UPF网元设备以及所支持实现的各业务，按照业务分配结果，配置对应的初始服务能力值，如表1和表2中“服务能力值”这一字段的各单元内容。

如步骤S42描述的实现方法，本申请可以通过各UPF网元设备的设备信息进行分析，确定相应UPF网元设备所能提供的最大服务能力，可以通过UPF网元设备所具有的性能确定，再通过对分配到的各业务的业务识别信息，确定所分配到的业务所需的服务能力，来综合确定相应UPF网元设备对分配到的每一业务能够提供的服务能力，其小于该UPF网元设备能提供的最大服务能力，从而基于不同服务能力与服务能力值之间的对应关系，来配置任一UPF网元设备对分配到的每一业务的初始服务能力值。

在另一些实施例中，对于SMF网元设备支持实现的每一业务，也可以基于SMF网元设备将其分担到不同UPF网元设备上的服务能力，以及不同服务能力与服务能力值之间的对应关系，来确定各UPF网元设备对分配到的每一业务的初始服务能力值。本申请对步骤S42的实现方法不做限制。

需要说明，对于不同SMF网元设备的下游UPF网元设备对分配到的各业务的初始服务能力值的获得方法可以相同也可以不同，且所配置的各初始服务能力值可以相同也可以不同，可以依据实际业务要求确定，本申请实施例仅以表1和表2所示的各初始服务能力值相同的实现方式为例进行说明，在各初始服务能力值不同的场景下，据此确定各SMF网元设备实现各业务的实际服务能力值的实现方法类似，本申请不做一一举例详述。

步骤S43，利用与该设备信息和业务识别信息对应的初始服务能力值，构成该SMF网元设备的业务配置文件；

本申请实施例中，可以在各SMF网元设备的服务注册阶段，按照上文描述的方法，确定其业务配置文件，该业务配置文件至少包括了相应SMF网元设备为下游的各UPF网元设备分配到的各业务配置的初始服务能力值，根据业务服务实际需求，还可以包括其他内容，本申请对业务配置文件的内容及其表示方式不做限制。

步骤S44，获得SMF网元设备管理的各UPF网元设备的状态信息；

步骤S45，从该SMF网元设备的业务配置文件中，确定出各业务识别信息对应的至少一个初始服务能力值和UPF网元设备的设备信息；

步骤S46，基于各UPF网元设备的状态信息，确定处于通信连接状态下的UPF网元设备的第一设备信息，以及处于通信断开状态下的UPF网元设备的第二设备信息；

在本申请实际应用中，SMF网元设备可能会将同一业务分配给下游的多个UPF网元设备，需要统计这多个UPF网元设备各自对应配置的初始服务能力值，才能确定该SMF网元设备实现该业务的实际服务能力值。而且，SMF网元设备能否与UPF网元设备正常通信，直接决定了该SMF网元设备能否使用该UPF网元设备所提供的服务能力，从而影响该SMF网元设备实现该业务所具有的实际服务能力。

因此，在确定SMF网元设备实现各业务所能提供的实际服务能力过程中，不仅需要分析SMF网元设备的业务配置文件内容，确定每一业务分配到每个UPF网元设备后配置的初始服务能力值，还需要确定当前各UPF网元设备与该SMF网元设备是否处于通信连接状态，为了方便描述方案，可以将处于通信连接状态的UPF网元设备记为第一UPF网元设备，将其具有的设备信息记为第一设备信息，并将处于通信断开状态的UPF网元设备记为第二UPF网元设备，将其具有的设备信息记为第二设备信息。

步骤S47，将任一业务识别信息对应各第一设备信息对应配置的初始服务能力值增加至该SMF网元设备支持的相应业务的服务能力值，并将对应各第二设备信息配置的初始服务能力值确定为零后增加至该SMF网元设备支持的相应业务的服务能力值，得到该SMF网元设备当前支持的相应业务的实际服务能力值；

继上述分析，本申请可以对通过识别第一设备信息，对分配到同一个业务的各第一UPF网元设备对应的初始服务能力值进行累加求和，得到SMF网元设备实现该业务的实际服务能力值。当然，如步骤S47描述的实现方式，在分配到同一个业务的多个UPF网元设备中，存在至少一个第二UPF网元设备，本申请也可以将该第二UPF网元设备对应配置的初始服务能力值更新为0，再对够分配到该业务的所有UPF网元设备对应配置的初始服务能力值进行累加，从而得到该SMF网元设备实现该业务的实际服务能力值。

示例性的，SMF1网元设备可以从其业务配置文件(如表1所示内容)中检索各不同业务的配置内容，如检索分配到具有“SST1+DNN1”属性的业务1的所有UPF网元设备及其对应配置的初始服务能力值，若其中任一UPF网元设备处于通信断开状态，将其初始服务能力值更新为0，累加到该SMF1网元设备对该业务1的服务能力值上，对于任一UPF网元设备处于通信连接状态，将其原始配置的初始服务能力值直接累加到该SMF1网元设备对该业务1的服务能力值上，由此得到SMF1网元设备对该业务1的实际服务能力值。

步骤S48，向NRF网元设备发送服务消息；该服务消息包含针对SMF网元设备当前支持的各业务的实际服务能力值。

在任一SMF网元设备管理的各UPF网元设备的状态信息确定后，按照上文描述的方法，获得相应通信状态下该SMF网元设备实现各业务的实际服务能力值后，可以随着该SMF网元设备的服务注册内容，将包含各实际服务能力值的服务消息发送至NRF网元设备进行存储，实现过程可以参照但并不继续局限于上文描述的实现方法。

由此可见，对于通信系统中的任一SMF网元设备将业务服务能力分担到下游的各UPF网元设备，配置对应的初始服务能力值后，将结合当前SMF网元设备与各UPF网元设备的实际通信状态，确定当前哪一个或多个UPF网元设备能够继续为其分配到的业务提供服务，哪一个或多个UPF网元设备当前无法继续为其分配到的业务提供服务，从而据此精准获得该SMF网元设备对支持的各业务的实际服务能力值，并及时上报至NRF网元设备，以辅助AMF网元设备在请求业务时，能够依据各SMF网元设备当前对支持的各业务的实际服务能力值，准确选择能够成功实现该业务的SMF网元设备，提高业务实现效率和可靠性。

参照图5，为本申请提出的业务处理方法的可选实施例四的流程示意图，在上文各实施例描述的业务处理方法的各步骤实现过程的基础上，可以对任一SMF网元设备与下游的UPF网元设备的通信状态发生变化的场景下，及时更新该SMF网元设备实现相应业务的实际服务能力值的一可选细化实现方法进行描述，关于各SMF网元设备的业务配置文件的获得方法，可以参照上文实施例对应部分的描述，本实施例不做详述。如图5所示，任一SMF网元设备执行的业务处理方法可以包括：

步骤S51，获得SMF网元设备管理的各UPF网元设备的状态信息；

步骤S52，基于该状态信息，确定任一UPF网元设备与SMF网元设备之间的通信状态发生变化；

本申请实施例中，可以实时或周期性或按照其他规则，获取UPF网元设备的状态信息，由此确定该UPF网元设备与上游的SMF网元设备之间的通信状态是否发生了变化，以便在发生变化时，能够及时刷新该SMF网元设备的实际服务能力值，并及时上报给NRF网元设备和/或AMF网元设备。因此，结合上文对该状态信息的描述，该通信状态发送变化可以包括：任一UPF网元设备与SMF网元设备之间的通信状态从上一次的通信连接状态变化成通信断开状态，或者是从上一次的通信断开状态变化成通信连接状态。

其中，上述通信断开状态可能是因UPF网元设备自身故障，无法正常运行；SMF网元设备自身故障，无法正常运行；以及SMF网元设备和UPF网元设备自身正常运行，但两者之间的通信异常导致无法连接等至少一种情况导致该通信状态，本申请可以用不检测导致该通信断开状态的原因，只要确定该UPF网元设备的通信状态发生变化，即可基于实际变化，如表征该通信状态的标识内容的变化，执行后续步骤。

步骤S53，从该SMF网元设备的业务配置文件中，确定为通信状态发生变化的UPF网元设备分配到的各业务配置的初始服务能力值；

步骤S54，基于确定的初始服务能力值，更新SMF网元设备支持的对应业务的实际服务能力值；

结合上文对SMF网元设备的实际服务能力值的相关描述，对于从通信连接状态变化成通信断开状态的任一UPF网元设备，由于其不能再对分配到的各业务提供服务，将其对应配置的初始服务能力值更新为零，再与分配到相应业务的其他UPF网元设备对应的初始服务能力值累加求和，得到该SMF网元设备支持的对应业务的实际服务能力值，即更新该SMF网元设备实现对应业务的服务能力值。

同理，对于从通信断开状态变化成通信连接状态的任一UPF网元设备，如任一UPF网元设备的通信异常恢复后，该UPF网元设备能够继续对分配到的业务提供服务，对应SMF网元设备会将该UPF网元设备配置的初始服务能力值，累加到当前该SMF网元设备支持的对应业务的服务能力值，得到对应的实际服务能力值，并不局限于本实施例描述的实际服务能力值更新实现方法。

步骤S55，向NRF网元设备发送服务更新消息；该服务更新消息包括针对SMF网元设备当前支持的相应业务更新后的实际服务能力值。

按照上文描述的方法，SMF网元设备确定对任一业务的实际服务能力值发生变化，可以生成至少包含更新后的实际服务能力值的服务更新消息，将其发送至NRF网元设备和/或AMF网元设备，关于服务更新消息的生成及其发送方式，可以参照上文服务消息的实现过程，本申请在此不做详述。

综上所述，在本申请提出的业务处理方法中，由于系统中的各SMF网元设备将业务的服务能力分担到其下游的UPF网元设备，由下游的各UPF网元设备对分配到的各业务的服务能力，来表达对应SMF网元设备实现相应业务所具有的服务能力。这样，通过监测系各SMF网元设备与其下游UPF网元设备之间的通信状态变化情况，动态调整SMF网元设备实现各业务的实际服务能力值，并及时上报至NRF网元设备，保证AMF网元设备能够据此精准了解当前各SMF网元设备对不同业务所能提供的实际服务能力，以便选择高服务能力的SMF网元设备与UPF网元设备通信，成功执行相应业务流程，避免选择不具有业务服务能力或业务服务能力不足的SMF网元设备响应业务请求，提高了业务实现效率和可靠性。

参照图6，为本申请提出的业务处理方法的可选实施例五的流程示意图，本实施例可以从通信系统的AMF网元设备侧描述该业务处理方法，如图6所示，该业务处理方法可以包括：

步骤S61，获得业务请求；该业务请求包含请求目标业务的目标业务识别信息；

步骤S62，基于目标业务识别信息，确定NRF网元设备存储的支持目标业务的至少一个SMF网元设备针对目标业务的实际服务能力值；

本申请实施例中，AMF网元设备请求的目标业务可以是用户终端UE发起的任一会话业务，如即时通信业务、视频播放业务或视频会议业务等，本申请对业务类型不做限制，对于不同类型业务可以有唯一的业务识别信息区别，如上述“业务切片类型SST”字段和“业务访问网络名称DNN”字段各自所表示的业务属性内容。可以理解的是，对于业务请求内容，除了用于识别所请求的业务(记为目标业务)的业务识别信息(记为目标业务识别信息)之外，还可以包括请求业务执行的处理动作或其他要求等，本申请对业务请求内容及其格式不做限制。

关于NRF网元设备存储的各SMF网元设备针对各业务的实际服务能力值的获取方法，可以参照上文从SMF网元设备侧描述的业务处理方法对应部分的描述，本实施例在此不做详述。其中，不同业务配置有一一对应的业务识别信息，这样，对于请求任一目标业务，可以从NRF网元设备存储的不同SMF网元设备各自当前支持的各业务的实际服务能力值中，确定出目标业务识别信息对应的至少一个SMF网元设备各自的实际服务能力值，该检索过程本申请不做详述。

需要说明的是，若SMF网元设备将对各业务的实际服务能力值上报至AMF网元设备，AMF网元设备也可以基于目标识别信息，从自身存储的不同SMF网元设备各自当前支持的各业务的实际服务能力值，确定支持目标业务的各SMF网元设备当前具有的实际服务能力值。

步骤S63，基于至少一个SMF网元设备各自针对目标业务的实际服务能力值，确定目标SMF网元设备；

步骤S64，将该业务请求分配至目标SMF网元设备，由目标SMF网元设备响应该业务请求。

在一些实施例中，若实现目标业务的SMF网元设备数量为多个，即NRF网元设备或AMF网元设备存储有与目标业务识别信息对应的多个SMF网元设备各自针对目标业务的实际服务能力值，为了保证目标业务实现的可靠性，可以将其中最大实际服务能力值对应的一个SMF网元设备确定为目标SMF网元设备，即使用实现所请求目标业务的SMF网元设备。其中，若该最大实际服务能力值对应的SMF网元设备是多个，可以随机或按照这多个SMF网元设备排序，选择其中的一个SMF网元设备为目标SMF网元设备。可见，支持同一业务的不同SMF网元设备对应的实际服务能力值越大，SMF网元设备分配到相应业务请求的概率越高，但并不局限于本实施例描述的目标SMF网元设备选择实现方法。

可以理解，若实现目标业务的SMF网元设备数量为一个，可以直接将这一个SMF网元设备确定为实现目标业务的目标SMF网元设备。另外，结合上文对SMF网元设备的实际服务能力值的动态调整的相关描述，在其任一UPF网元设备的通信状态发生变化，分配给其的各业务的服务能力发生变化，可以及时更新该SMF网元设备对相应业务的实际服务能力值，通过服务化消息传递到NRF网元设备和/或AMF网元设备，以及更新其中该SMF网元设备对相应业务的实际服务能力值，使得AMF网元设备可以按照各SMF网元设备最新对各业务的实际服务能力值，实现对各目标业务的目标SMF网元设备，这样，将请求业务发送至所选择的目标SMF网元设备，能够通过与分配到该目标业务的UPF网元设备通信，能够可靠实现目标业务。

这样，对于同一个目标业务，在各SMF网元设备对该目标业务的实际服务能力值发生变化后，导致具有最高服务能力值的目标SMF网元设备发生变化，可以及时将该业务请求切换发送至新的目标SMF网元设备，由该目标SMF网元设备继续响应该业务请求，保证目标业务实现效率和可靠性，提高会话建立的成功率和稳定性，提升用户体验。

参照图7，为本申请提出的业务处理装置的一可选实施例的结构示意图，该业务处理装置可以适用于任一SMF网元设备，如图7所示，该业务处理装置可以包括：

业务配置文件获取模块71，用于获取会话管理功能网元设备的业务配置文件；所述业务配置文件包括为所述会话管理功能网元设备管理的各用户面功能网元设备分配到的各业务配置的初始服务能力值；

状态信息获取模块72，用于获取所述会话管理功能网元设备管理的各用户面功能网元设备的状态信息；

实际服务能力值获得模块73，用于基于所述初始服务能力值和所述状态信息，获得所述会话管理功能网元设备对当前支持的各所述业务的实际服务能力值；

服务消息发送模块74，用于向网络仓储功能网元设备发送服务消息；

本申请实施例中，上述服务消息包含针对所述会话管理功能网元设备当前支持的各所述业务的实际服务能力值；其中，支持同一所述业务的不同所述会话管理功能网元设备对应的所述实际服务能力值越大，所述会话管理功能网元设备分配到相应业务请求的概率越高。

在一些实施例中，实际服务能力值获得模块73可以包括：

第一确定单元，用于基于所述状态信息，从所述会话管理功能网元设备管理的多个所述用户面功能网元设备中，确定出处于通信连接状态下的待定用户面功能网元设备；

第二确定单元，用于从所述业务配置文件中，确定出为各所述待定用户面功能网元设备分配到的各所述业务配置的初始服务能力值；

第一获得单元，用于利用各所述待定用户面功能网元设备对应的所述初始服务能力值，获得所述会话管理功能网元设备对当前支持的各所述业务的实际服务能力值。

在一种实现方式中，上述第一获得单元可以包括：

第一确定子单元，用于确定同一所述业务分配到不同所述待定用户面功能网元设备对应的所述初始服务能力值；

合并子单元，用于对分配到不同所述待定用户面功能网元设备的同一所述业务配置的多个所述初始服务能力值进行合并，得到所述会话管理功能网元设备当前支持该业务的实际服务能力值。

在又一些实施例中，上述业务配置文件获取模块71可以包括：

第二获得单元，用于获得会话管理功能网元设备管理的各用户面功能网元设备的设备信息，以及所述会话管理功能网元设备支持的各业务的业务识别信息；任一所述业务被分配到至少一个所述用户面功能网元设备；

第三确定单元，用于基于所述设备信息和所述业务识别信息，确定针对各所述用户面功能网元设备分配到的各所述业务配置的初始服务能力值；

业务配置文件构成单元，用于利用与所述设备信息和所述业务识别信息对应的所述初始服务能力值，构成所述会话管理功能网元设备的业务配置文件。

基于此，上述实际服务能力值获得模块73可以包括：

第四确定单元，用于从所述业务配置文件中，确定出各所述业务识别信息对应的至少一个所述初始服务能力值和所述用户面功能网元设备的设备信息；

第五确定单元，用于基于所述状态信息，确定处于通信连接状态下的所述用户面功能网元设备的第一设备信息，以及处于通信断开状态下的所述用户面功能网元设备的第二设备信息；

服务能力值累加单元，用于将任一所述业务识别信息对应各所述第一设备信息对应配置的所述初始服务能力值增加至所述会话管理功能网元设备支持的相应所述业务的服务能力值，并将对应各所述第二设备信息对应配置的所述初始服务能力值确定为零后增加至所述会话管理功能网元设备支持的相应所述业务的服务能力值，得到所述会话管理功能网元设备当前支持的相应所述业务的实际服务能力值。

综合上文各实施例描述的任一SMF网元设备中的业务处理装置，其还可以包括：

通信状态确定模块，用于基于所述状态信息，确定任一所述用户面功能网元设备与所述会话管理功能网元设备之间的通信状态发生变化；

初始服务能力值确定模块，用于从所述业务配置文件中，确定为所述通信状态发生变化的所述用户面功能网元设备分配到的各所述业务配置的所述初始服务能力值；

实际服务能力值更新模块，用于基于确定的所述初始服务能力值，更新所述会话管理功能网元设备支持的对应所述业务的实际服务能力值，

服务更新消息发送模块，用于向所述网络仓储功能网元设备发送服务更新消息；所述服务更新消息包括针对所述会话管理功能网元设备当前支持的相应所述业务更新后的实际服务能力值。

参照图8，为本申请提出的业务处理装置的另一可选实施例的结构示意图，该业务处理装置可以适用于任一AMF网元设备，如图8所示，该业务处理装置可以包括：

业务请求获得模块81，用于获得业务请求；所述业务请求包含请求目标业务的目标业务识别信息；

实际服务能力值确定模块82，用于基于所述目标业务识别信息，确定网络仓储功能网元设备存储的支持所述目标业务的至少一个会话管理功能网元设备针对所述目标业务的实际服务能力值；

目标会话管理功能网元设备确定模块83，用于基于所述至少一个会话管理功能网元设备各自针对所述目标业务的实际服务能力值，确定目标会话管理功能网元设备；

业务请求分配模块84，用于将所述业务请求分配至所述目标会话管理功能网元设备，由所述目标会话管理功能网元设备响应所述业务请求；

其中，支持同一业务的不同所述会话管理功能网元设备对应的所述实际服务能力值越大，所述会话管理功能网元设备分配到相应业务请求的概率越高。

可选的，上述目标会话管理功能网元设备确定模块83可以包括：

确定单元，用于如果所述网络仓储功能网元设备存储有与所述目标业务识别信息对应的多个会话管理功能网元设备各自针对所述目标业务的实际服务能力值，将最大所述实际服务能力值对应的一个所述会话管理功能网元设备确定为目标会话管理功能网元设备；

选择单元，用于如果最大所述实际服务能力值对应的所述会话管理功能网元设备是多个，随机或按照这多个所述会话管理功能网元设备排序选择其中的一个所述会话管理功能网元设备为目标会话管理功能网元设备。

需要说明的是，关于上述各装置实施例中的各种模块、单元等，均可以作为程序模块存储在相应侧网元设备(如SMF网元设备或AMF网元设备)的存储器中，由该侧网元设备中的处理器执行存储在存储器中的上述程序模块，以实现相应的功能，关于各程序模块及其组合所实现的功能，以及达到的技术效果，可以参照上述方法实施例相应部分的描述，本实施例不再赘述。

本申请还提出了一种计算机可读存储介质，其上可以存储计算机程序，该计算机程序可以被处理器调用并加载，以实现上述实施例描述的业务处理方法的各个步骤。

本申请还提出了一种计算机程序产品，该计算机程序产品中存储有计算机可读指令，当计算机可读指令在任一SMF或AMF网元设备上运行时，使得相应网元设备侧的业务处理方法被执行，提高业务实现效率和可靠性，从而提高用户体验。

本申请还提供了一种业务处理设备，如SMF网元设备或AMF网元设备，可以执行上述从相应网元设备侧描述的业务处理方法，本申请对各网元设备的硬件结构及其工作原理，实现相应业务处理方法的过程不做详述。

本申请还提出了适用于本申请提出的业务处理方法的服务器，服务器可以包括至少一个存储器和至少一个处理器，处理器可以读取存储器存储的计算机程序，执行上述任一实施例描述的业务处理方法，实现过程本申请在此不做赘述。应该理解的是，该服务器的结构组成包括但并不局限于存储器和处理器，根据实际需求还可以包括至少一种通信模块，如WIFI模块、5G/6G(第五代移动通信网络/第六代移动通信网络)模块、GPRS模块等一种或多种，据此实现与其他设备(如用户终端或数据库或基站等)的无线通信。还可以包括如通用输入输出(general-purpose input/output，GPIO)接口、USB接口、通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口等数据端口，以实现服务器内容组成部分之间的数据交互等，本申请在此不做一一列举。

最后，需要说明的是，关于上述各实施例中，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其它的步骤或元素。由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

其中，在本申请实施例的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，在本申请实施例的描述中，“多个”是指两个或多于两个。

本申请涉及到的术语诸如“第一”、“第二”等仅用于描述目的，用来将一个操作、单元或模块与另一个操作、单元或模块区分开来，而不一定要求或者暗示这些单元、操作或模块之间存在任何这种实际的关系或者顺序。且不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量，由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。

另外，本说明书中各个实施例采用递进或并列的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置、设备而言，由于其与实施例公开的方法对应，所以描述的比较简单，相关之处参见方法部分说明即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种业务处理方法，所述方法包括：

获取会话管理功能网元设备的业务配置文件，以及所述会话管理功能网元设备管理的各用户面功能网元设备的状态信息；所述业务配置文件包括为所述各用户面功能网元设备分配到的各业务配置的初始服务能力值；

基于所述初始服务能力值和所述状态信息，获得所述会话管理功能网元设备对当前支持的各所述业务的实际服务能力值；

向网络仓储功能网元设备发送服务消息；所述服务消息包含针对所述会话管理功能网元设备当前支持的各所述业务的实际服务能力值；

其中，支持同一所述业务的不同所述会话管理功能网元设备对应的所述实际服务能力值越大，所述会话管理功能网元设备分配到相应业务请求的概率越高。

2.根据权利要求1所述的方法，所述基于所述初始服务能力值和所述状态信息，获得所述会话管理功能网元设备对当前支持的各所述业务的实际服务能力值，包括：

基于所述状态信息，从所述会话管理功能网元设备管理的多个所述用户面功能网元设备中，确定出处于通信连接状态下的待定用户面功能网元设备；

从所述业务配置文件中，确定出为各所述待定用户面功能网元设备分配到的各所述业务配置的初始服务能力值；

利用各所述待定用户面功能网元设备对应的所述初始服务能力值，获得所述会话管理功能网元设备对当前支持的各所述业务的实际服务能力值。

3.根据权利要求2所述的方法，所述利用各所述待定用户面功能网元设备对应的所述初始服务能力值，获得所述会话管理功能网元设备对当前支持的各所述业务的实际服务能力值，包括：

确定同一所述业务分配到不同所述待定用户面功能网元设备对应的所述初始服务能力值；

对分配到不同所述待定用户面功能网元设备的同一所述业务配置的多个所述初始服务能力值进行合并，得到所述会话管理功能网元设备当前支持该业务的实际服务能力值。

4.根据权利要求1所述的方法，所述获取会话管理功能网元设备的业务配置文件，包括：

获得会话管理功能网元设备管理的各用户面功能网元设备的设备信息，以及所述会话管理功能网元设备支持的各业务的业务识别信息；任一所述业务被分配到至少一个所述用户面功能网元设备；

基于所述设备信息和所述业务识别信息，确定针对各所述用户面功能网元设备分配到的各所述业务配置的初始服务能力值；

利用与所述设备信息和所述业务识别信息对应的所述初始服务能力值，构成所述会话管理功能网元设备的业务配置文件。

5.根据权利要求4所述的方法，所述基于所述初始服务能力值和所述状态信息，获得所述会话管理功能网元设备对当前支持的各所述业务的实际服务能力值，包括：

从所述业务配置文件中，确定出各所述业务识别信息对应的至少一个所述初始服务能力值和所述用户面功能网元设备的设备信息；

基于所述状态信息，确定处于通信连接状态下的所述用户面功能网元设备的第一设备信息，以及处于通信断开状态下的所述用户面功能网元设备的第二设备信息；

将任一所述业务识别信息对应各所述第一设备信息对应配置的所述初始服务能力值增加至所述会话管理功能网元设备支持的相应所述业务的服务能力值，并将对应各所述第二设备信息对应配置的所述初始服务能力值确定为零后增加至所述会话管理功能网元设备支持的相应所述业务的服务能力值，得到所述会话管理功能网元设备当前支持的相应所述业务的实际服务能力值。

6.根据权利要求1-5任一项所述的方法，所述方法还包括：

基于所述状态信息，确定任一所述用户面功能网元设备与所述会话管理功能网元设备之间的通信状态发生变化；

从所述业务配置文件中，确定为所述通信状态发生变化的所述用户面功能网元设备分配到的各所述业务配置的所述初始服务能力值；

基于确定的所述初始服务能力值，更新所述会话管理功能网元设备支持的对应所述业务的实际服务能力值，

向所述网络仓储功能网元设备发送服务更新消息；所述服务更新消息包括针对所述会话管理功能网元设备当前支持的相应所述业务更新后的实际服务能力值。

7.一种业务处理方法，所述方法包括：

获得业务请求；所述业务请求包含请求目标业务的目标业务识别信息；

基于所述目标业务识别信息，确定网络仓储功能网元设备存储的支持所述目标业务的至少一个会话管理功能网元设备针对所述目标业务的实际服务能力值；

基于所述至少一个会话管理功能网元设备各自针对所述目标业务的实际服务能力值，确定目标会话管理功能网元设备；

将所述业务请求分配至所述目标会话管理功能网元设备，由所述目标会话管理功能网元设备响应所述业务请求；

其中，支持同一业务的不同所述会话管理功能网元设备对应的所述实际服务能力值越大，所述会话管理功能网元设备分配到相应业务请求的概率越高。

8.根据权利要求7所述的方法，所述基于所述至少一个会话管理功能网元设备各自针对所述目标业务的实际服务能力值，确定目标会话管理功能网元设备，包括

如果所述网络仓储功能网元设备存储有与所述目标业务识别信息对应的多个会话管理功能网元设备各自针对所述目标业务的实际服务能力值，将最大所述实际服务能力值对应的一个所述会话管理功能网元设备确定为目标会话管理功能网元设备；

如果最大所述实际服务能力值对应的所述会话管理功能网元设备是多个，随机或按照这多个所述会话管理功能网元设备排序选择其中的一个所述会话管理功能网元设备为目标会话管理功能网元设备。

9.一种业务处理装置，所述装置包括：

业务配置文件获取模块，用于获取会话管理功能网元设备的业务配置文件；所述业务配置文件包括为所述会话管理功能网元设备管理的各用户面功能网元设备分配到的各业务配置的初始服务能力值；

状态信息获取模块，用于获取所述会话管理功能网元设备管理的各用户面功能网元设备的状态信息；

实际服务能力值获得模块，用于基于所述初始服务能力值和所述状态信息，获得所述会话管理功能网元设备对当前支持的各所述业务的实际服务能力值；

服务消息发送模块，用于向网络仓储功能网元设备发送服务消息；所述服务消息包含针对所述会话管理功能网元设备当前支持的各所述业务的实际服务能力值；

其中，支持同一所述业务的不同所述会话管理功能网元设备对应的所述实际服务能力值越大，所述会话管理功能网元设备分配到相应业务请求的概率越高。

10.一种业务处理装置，所述装置包括：

业务请求获得模块，用于获得业务请求；所述业务请求包含请求目标业务的目标业务识别信息；

实际服务能力值确定模块，用于基于所述目标业务识别信息，确定网络仓储功能网元设备存储的支持所述目标业务的至少一个会话管理功能网元设备针对所述目标业务的实际服务能力值；

目标会话管理功能网元设备确定模块，用于基于所述至少一个会话管理功能网元设备各自针对所述目标业务的实际服务能力值，确定目标会话管理功能网元设备；

业务请求分配模块，用于将所述业务请求分配至所述目标会话管理功能网元设备，由所述目标会话管理功能网元设备响应所述业务请求；

其中，支持同一业务的不同所述会话管理功能网元设备对应的所述实际服务能力值越大，所述会话管理功能网元设备分配到相应业务请求的概率越高。