CN115277571B - 处理方法和处理系统 - Google Patents

Abstract

本申请公开一种处理方法和处理系统，该方法和系统预先为UPF网元构建用于分流管控的负载均衡模块，借助负载均衡模块接收需发送至UPF网元的待处理业务流量，并由负载均衡模块根据预设分流规则和待处理业务流量的报文头中预定字段的字段信息，在多个UPF网元实例中进行业务流量分流，通过分流管控实现对各个UPF网元实例的负载均衡处理。基于负载均衡模块的上述负载均衡处理，本申请可实现将待处理业务流量在不同UPF网元实例间进行精细化、相对均衡的分流控制，解决了同一基站传统场景下无法分流的瓶颈，并能够基于精细化、相对均衡的分流控制满足用户面的高性能转发需求。

Description

处理方法和处理系统

技术领域

本申请属于通信技术领域，尤其涉及一种处理方法和处理系统。

背景技术

5G UPF(User Plane Function，用户面功能)网元，是5G核心网系统架构的重要组成部分，主要负责5G核心网用户面数据包的路由和转发相关功能。UPF在5G面向低时延、大带宽的边缘计算和网络切片技术上发挥着举足轻重的作用。作为用户面功能，目前的5GUPF网元在实际应用过程中，仍然缺乏一些重要的功能，主要体现在：

1)基于云化提供的核心网方案，特别是用户面想要满足高性能的转发，UPF网元基于云原生提供的负载均衡机制满足不了性能要求；

2)UPF网元不支持业务自动弹缩；

即，不能依据实际的业务需求提供业务能力的动态扩缩容功能，特别是一些场馆类、跨时段需求类的行业专网，按需使用显得尤为重要；

3)UPF网元不支持主备；

4)UPF网元不支持升级。

缺乏上述功能，导致5G核心网上云并未带来云特有的一些优势和价值。因此，需至少部分的解决5G UPF网元存在的技术问题。

发明内容

为此，本申请公开如下技术方案：

一种处理方法，包括：

基于UPF网元的负载均衡模块，接收待处理业务流量；所述UPF网元包括处于运行状态的多个UPF网元实例；

所述负载均衡模块确定所述待处理业务流量的报文头中预定字段的字段信息；

根据预设分流规则和所述预定字段的字段信息，所述负载均衡模块确定用于处理所述待处理业务流量的目标UPF网元实例；

所述负载均衡模块将所述待处理业务流量传输至所述目标UPF网元实例进行处理。

可选的，所述负载均衡模块确定所述待处理业务流量的报文头中预定字段的字段信息，包括：

确定所述待处理业务流量的流量类型；

根据所述流量类型对应的解析规则，解析所述待处理业务流量的报文头，基于解析结果提取所述待处理业务流量的报文头中预定字段的字段信息。

可选的，所述根据预设分流规则和所述预定字段的字段信息，所述负载均衡模块确定用于处理所述待处理业务流量的目标UPF网元实例，包括：

根据预设分流规则对所述预定字段的字段信息进行处理，得到处理结果，根据所述处理结果确定一UPF网元实例标识或容器标识；

将所述UPF网元实例标识对应的UPF网元实例或所述容器标识所指示容器中部署的UPF网元实例确定为目标UPF网元实例；

其中，不同UPF网元实例分别部署在不同的容器中。

可选的，UPF网元包括处于运行状态的主用UPF网元和未处于运行状态的备用UPF网元；所述备用UPF网元通过同步所述主用UPF网元的数据，使得与所述主用UPF网元的数据一致；

所述方法还包括：

响应于检测到所述主用UPF网元的下线事件，对所述备用UPF网元进行主备切换，使所述备用UPF网元作为切换后的主用UPF网元处于运行状态；

利用所述负载均衡模块获取与记录切换后的主用UPF网元的预设信息，并建立所述负载均衡模块与所述切换后的主用UPF网元间的连接。

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

检测各个UPF网元实例对业务流量的负载状况；

响应于UPF网元实例的负载状况满足相应负载条件，对UPF网元进行对应的扩缩容处理；

利用所述负载均衡模块执行与所述扩缩容处理相匹配的处理。

可选的，所述响应于UPF网元实例的负载状况满足相应负载条件，对UPF网元进行对应的扩缩容处理，包括：

如果UPF网元实例的负载状况满足第一负载条件，对UPF网元进行扩容处理；如果UPF网元实例的负载状况满足第二负载条件，对UPF网元进行缩容处理；

其中，所述扩容处理包括：为UPF网元增加UPF网元实例，和/或，提升UPF网元的已有UPF网元实例中至少一个UPF网元实例的处理能力；所述缩容处理包括：减少UPF网元的UPF网元实例，和/或，降低UPF网元的已有UPF网元实例中至少一个UPF网元实例的处理能力。

可选的，所述利用所述负载均衡模块执行与所述扩缩容处理相匹配的处理，包括：

响应于增加UPF网元实例，所述负载均衡模块获取与记录扩容时所增加的UPF网元实例的预设信息并建立与所增加的UPF网元实例间的连接；

或者，响应于减少UPF网元实例，所述负载均衡模块至少断开与缩容时所关闭的UPF网元实例间的连接。

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

响应于获得的升级请求，利用构建的独立于待升级UPF网元的UPF网元实例部署实现升级所需的功能，得到升级后的UPF网元；

运行升级后的UPF网元；

所述负载均衡模块至少记录升级后的UPF网元的预设信息，并建立所述负载均衡模块与所述升级后的UPF网元间的连接，以完成升级；

其中，在获得所述升级请求至完成升级之前，基于所述待升级UPF网元提供业务流量处理能力。

可选的，所述负载均衡模块通过旁路模式接收待处理业务流量，并将待处理业务流量传输至对应的目标UPF网元实例；

所述旁路模式，为无需所述负载均衡模块所处设备的系统内核进行流量收发处理的模式。

一种处理系统，至少包括UPF网元和为所述UPF网元设置的负载均衡模块，所述UPF网元包括处于运行状态的多个UPF网元实例；

其中，所述负载均衡模块用于：

接收待处理业务流量；

确定所述待处理业务流量的报文头中预定字段的字段信息；

根据预设分流规则和所述预定字段的字段信息，确定用于处理所述待处理业务流量的目标UPF网元实例；

将所述待处理业务流量传输至所述目标UPF网元实例进行处理。

由以上方案可知，本申请公开的处理方法和处理系统，预先为UPF网元构建用于分流管控的负载均衡模块，借助负载均衡模块接收需发送至UPF网元的待处理业务流量，并由负载均衡模块根据预设分流规则和待处理业务流量的报文头中预定字段的字段信息，在多个UPF网元实例中进行业务流量分流，通过分流管控实现对各个UPF网元实例的负载均衡处理。基于负载均衡模块的上述负载均衡处理，本申请可实现将待处理业务流量在不同UPF网元实例间进行精细化、相对均衡的分流控制，解决了同一基站传统场景下无法分流的瓶颈，并能够基于精细化、相对均衡的分流控制满足用户面的高性能转发需求。

附图说明

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

图1是本申请提供的处理方法的一种流程示意图；

图2是现有技术中UPF产品的安装部署架构图；

图3是本申请提供的UPF产品的安装部署架构图；

图4是本申请提供的VPP框架中负载均衡模块的各功能节点的挂接方式图；

图5是本申请提供的slb-arp节点的一个示例性ARP处理流程图；

图6是本申请提供的slb-ip4/slb-ip6节点的一个示例性上下行数据报文处理流程图；

图7是本申请提供的主备模式下的UPF产品部署架构图；

图8是本申请提供的处理方法的另一种流程示意图；

图9是本申请提供的处理方法的又一种流程示意图；

图10是本申请提供的处理方法的再一种流程示意图；

图11是本申请提供的弹缩模式下的UPF产品部署框架图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请实施例公开一种处理方法和处理系统，通过在UPF网元侧新增用于分流管控的负载均衡模块(SLB)，实现对业务流量在不同UPF网元实例间的精细化分流控制，以解决同一基站传统场景下无法分流的瓶颈，满足用户面的高性能转发需求，并解决UPF网元的不支持自动扩缩容、不支持主备、不支持升级等问题。

参见图1示出的处理方法流程图，本申请实施例公开的处理方法至少包括以下处理过程：

步骤101、基于UPF网元的负载均衡模块，接收待处理业务流量；UPF网元包括处于运行状态的多个UPF网元实例。

参见图2示出的现有技术中UPF产品的安装部署架构图，现有技术中UPF产品的安装部署总体上包括OAM(Operation Administration and Maintenance，操作管理维护)、UPF网元两部分，各部分功能如下：

OAM：主要负责UPF网元的操作管理维护，例如配置管理、日志告警等；

UPF网元：主要包括基础转发和N4控制两个部分，其中N4控制负责跟CP(ControlPlane，控制面)面交互PFCP(Packet Forwarding Control Protocol，报文转发控制协议)信令，以在UPF网元维护PDU(packet data unit，分组数据单元)会话表，基础转发主要根据维护的PDU回话表，在上下行数据处理过程中匹配PDU会话表，对业务流量进行转发。

图3为本申请提供的UPF产品的安装部署架构图，除了OAM和UPF网元，本申请还预先在UPF网元侧增加负载均衡模块，通过增加负载均衡模块，来提供业务数据流在不同UPF实例间的动态负载均衡能力，该模块支持多种负载控制策略，负载控制灵活。可选的，该模块还支持对UPF网元的手动/自动扩缩容，以及对UPF网元的无状态升级。

可选的，在业务数据流的动态负载均衡方面，负载均衡模块负责对UPF网元N3、N4、N6、N9接口的流量进行分流管控，具体按照业务流量的分类，通过分流规则分发N3/N4/N6/N9各个接口的数据流量到后端的不同业务处理单元，即分发到后端的不同UPF网元实例，尽可能保证各UPF网元实例的负载均衡，相应支持在UPF网元对业务流量的高性能路由、转发。

其中，N3接口是NG-RAN(5G接入网)与UPF网元间的接口，基于GTPU(GPRSTunnelling Protocol for the user plane，GPRS用户面隧道协议)进行用户数据的传输。N4接口是5G SMF(Session Management Function，会话管理功能)单元与UPF网元间的接口，负责UPF网元与CP面的PFCP信令交互，以维护PDU会话表，N6接口是UPF网元和外部DN(Data Network，数据网络)之间的接口，可基于IP(Internet Protocol，网际互连协议)与DN网络通信，N9接口是UPF网元之间的接口，两个UPF网元之间使用GTPU协议进行用户面报文的传输。

可选的，本实施例中，负载均衡模块对外采用通用二三层(指OSI七层网络模型中的第二层-数据链路层和第三层-网络层)转发技术，进行业务流量转发，通用性较强，部署灵活，能够有效满足UPF转发性能要求，作为一种通用技术，后续也可以为其他产品提供相应机制和能力。

另外，可选的，UPF网元和负载均衡模块均基于容器部署，本实施例将用于部署UPF网元的容器称为用户面容器，即UP(User Plane，用户面)container，将用于部署负载均衡模块的容器称为负载均衡容器，即SLB container，其中，SLB container的主要功能是代理真实的UP container的IP层配置，以使得对外呈现的UP container二层(OSI七层网络模型中的第二层-数据链路层)信息实际是SLB container的二层相关信息。UP container为UPF网元的真实容器，主要用作实现UPF网元的功能，如业务数据流处理，消息同步(如主备或升级中不同UPF网元实例间的会话同步)等，另外，本申请中的OAM除了传统功能，还可以提供配置SLB container和UP container的分流类型，分流规则等功能。

UPF网元对应包括多个UPF网元实例，UPF网元实例为针对已被启用的UPF网元所生成的运行实例，各个UPF网元实例均处于运行状态，且各个UPF网元实例分别通过各自的接口与负载均衡模块连接。可选的，一个UP container中部署一个UPF网元实例。

其中，对于每一UPF网元实例，可以但不限于预先基于OAM通过GRPC(远程过程调用)业务配置方式，将UPF网元实例的接口与负载均衡模块接口间的连接通道打通，实现在两者间构建通信连接。可选的，针对UPF网元N3/N4/N6/N9接口的分流管控需求，本申请相应为每一UPF网元实例设置用于接入负载均衡模块的4种接口：lf(interface，接口)1、lf2、lf3和lf4(图3中针对UPF，仅示出了两种接口lf1、lf2)，依次用于在UPF网元实例与负载均衡模块之间转发来自N3接口、N4接口、N6接口、N9接口的数据。

基于增加的负载均衡模块，当5G核心网产生需由UPF网元负责的待处理业务流量时，可借助负载均衡模块的邻居代理功能，在负载均衡模块接收该待处理业务流量。

待处理业务流量可以是控制信令或业务数据，不作限制，视实际情况而定，在5G核心网中，控制信令具体可以是来自UPF网元对应的N4接口的PFCP信令，业务数据可以是来自UPF网元对应的N3/N6/N9接口的数据。

步骤102、负载均衡模块确定待处理业务流量的报文头中预定字段的字段信息。

针对所接收的待处理业务流量，负载均衡模块可确定其所属的流量类型，根据所属流量类型对应的解析规则，解析待处理业务流量的报文头，并基于解析结果提取待处理业务流量的报文头中预定字段的字段信息。

所提取的预定字段的字段信息，用于作为数据依据，参与负载均衡模块后续对待处理业务流量的转发/分流控制。

待处理业务流量的流量类型，可以是但不限于GTPU流量类型或非GTPU流量类型。待处理业务流量的报文头中预定字段的字段信息，包括但不限于GTPU报文/非GTPU报文头中的IP五元组信息，即源IP地址(scrIP)、源端口(scrPort)、目的IP地址(dstIP)、目的端口(dstPort)、应用协议组成的五元组信息。

不同流量类型，对其报文头进行解析的解析规则不同，示例性的，本实施例中，负载均衡模块按照GTPU和非GTPU两种流量类型对接收的待处理业务流量进行区分，例如将UPF流量、普通数通业务流量以及每种应用的不同流量等按其来源(如N3/N6/N9)分类为GTPU流量类型和非GTPU流量类型，其中，将来源于N3接口或者N9接口的业务流量划分为GTPU流量类型，将来源于N6接口的业务流量划分为非GTPU流量类型。实际应用中，还可以根据需求将负载均衡模块对业务流量类型的划分与识别拓展到其他类型。

针对GTPU和非GTPU流量类型，分别预先根据不同流量类型各自的报文头特征，为不同流量类型设计相匹配的解析规则，并针对接收的待处理业务流量，按识别出的流量类型调用相匹配的解析规则，对其报文头进行解析，并于解析基础上提取其中的IP五元组信息。

步骤103、根据预设分流规则和所述预定字段的字段信息，所述负载均衡模块确定用于处理待处理业务流量的目标UPF网元实例。

在从待处理业务流量的报文头中提取其预定字段的字段信息之后，负载均衡模块进一步对其进行基于分流规则的转发处理，具体的，负载均衡模块可根据预设分流规则对提取的预定字段的字段信息进行处理，得到处理结果，根据处理结果确定一UPF网元实例标识或容器标识，并将UPF网元实例标识对应的UPF网元实例或容器标识所指示容器中部署的UPF网元实例确定为目标UPF网元实例，以便于负载均衡模块对所接收的待处理业务流量进行转发。

容易理解，目标UPF网元实例，为UPF网元对应的多个UPF网元实例中的一个UPF网元实例。

以下进一步以预定字段的字段信息为IP五元组信息为例，对确定目标UPF网元实例的过程进行说明。

可选的，具体可基于预设的哈希(hash)算法对提取的IP五元组信息进行哈希运算，并基于UPF网元实例数目对哈希运算结果进行求余运算，将求余运算结果作为一UPF网元实例编号或UP container编号，进而将该编号对应的UPF网元实例或该编号所指示UPcontainer中部署的UPF网元实例，确定为目标UPF网元实例。该实施方式下，预设分流规则，相应为基于上述哈希运算和求余运算的分流规则。

其他实施例中，在上述哈希运算和求余运算基础上，还可以结合UP container的当前容量情况确定目标UPF网元实例。UP container的容量是指UP container基于其业务处理能力所能支持的业务量。

该实施方式中，在根据哈希运算和求余运算得到一求余运算结果后，将该结果作为一UPF网元实例编号或UP container编号，并确定与该UPF网元实例编号或UP container编号匹配的UP container当前的空闲容量比例(空闲容量在总容量中的占比)或剩余容量，在当前的空闲容量比例或剩余容量达到设定阈值情况下，将该编号匹配的UPF网元实例确定为目标UPF网元实例。否则，若未达到，则将该编号匹配的UPF网元实例排除，继续针对其他UPF网元实例，基于上述的哈希运算和求余运算(基于所述其他UPF网元实例的数目进行求余运算)，并结合UP container的当前容量情况确定目标UPF网元实例，以尽可能保证分流控制中各UPF网元实例的负载均衡。

该实施方式下，预设分流规则，相应为基于上述哈希运算和求余运算，以及结合UPcontainer当前容量情况的分流规则。

步骤104、负载均衡模块将待处理业务流量传输至目标UPF网元实例进行处理。

在确定出用于处理待处理业务流量的目标UPF网元实例之后，负载均衡模块将待处理业务流量转发至目标UPF网元进行处理，从而实现基于分流规则对业务数据流在不同UPF网元实例之间进行分流控制，尽可能保证不同UPF网元实例的负载均衡，进而满足用户面的高性能数据转发需求。

后续，目标UPF网元可根据维护的PDU会话表，对接收的待处理业务流量进行路由。

由以上方案可知，本实施例的方法，预先为UPF网元构建用于分流管控的负载均衡模块，借助负载均衡模块接收需发送至UPF网元的待处理业务流量，并由负载均衡模块根据预设分流规则和待处理业务流量的报文头中预定字段的字段信息，在多个UPF网元实例中进行业务流量分流，通过分流管控实现对各个UPF网元实例的负载均衡处理。基于负载均衡模块的上述负载均衡处理，本申请可实现将待处理业务流量在不同UPF网元实例间进行精细化、相对均衡的分流控制，解决了同一基站传统场景下无法分流的瓶颈，并能够基于精细化、相对均衡的分流控制满足用户面的高性能转发需求。

可选的，在一实施例中，本申请借助VPP(Vector Packet Processor，矢量包处理器)用户态高性能转发框架，通过在VPP内部增加SLB插件(plugin)，提供负载均衡模块所需的邻居代理、负载均衡控制、后端成员接口管理等一系列功能。

以下进一步提供借助VPP用户态高性能转发框架，部署、实现负载均衡模块的一个示例。参见图4，该示例基于VPP的节点框架，通过提供slb_input、slb-ip4、slb-ip6、slb-arp等一系列功能节点来实现负载均衡模块的功能部署，各节点的挂接方式如图4所示。

可选的，为了提升转发性能，将负载均衡模块的功能处理放在ethernet(以太网)节点上。所有上下行数据到达负载均衡模块后，负载均衡模块在input阶段识别报文类型后分发到具体节点进行处理。

针对负载均衡模块，所提供的各节点的功能如下：

slb-input：主要负责所有从ethernet-input节点过来的报文，主要做报文协议头关键信息提取并分类处理。

slb-arp：主要负责外部接口和内部接口之间arp报文的处理；其进一步分为error-drop(错误处理)、interface-output(出接口处理)、arp-input(arp输入处理)等几个子功能。

参见图5，提供了slb-arp节点的一个示例性ARP处理流程。其核心流程为：对于从基站、DN或者其他UPF进来并到达SLB的ARP报文，SLB根据收包接口的接口索引判断入方向接口的类型，然后依据入方向的接口类型确定与其匹配一致的出方向接口类型(例如，若入方向的接口类型为N3，则与其匹配的出方向接口类型为N3-LAN)，并基于确定出的出方向接口类型对ARP报文进行转发。

其中，图5中的N3-LAN、N6-LAN、N9-LAN接口，分别为设置于UPF容器与负载均衡模块之间的与N3、N6、N9接口一一对应的接口。

slb-ip4/slb-ip6：主要负责IP报文的处理，其中slb-ip4主要用于处理ipv4报文的转发，如上行报文如何通过选择策略算法分担到后端的UPF网元，以及从UPF网元下来的下行数据如何从slb转发到基站等；slb-ip6则主要用于处理ipv6报文的转发。

slb-ip4节点进一步分为error-drop(错误处理)、interface-output(出接口处理)、ip4-lookup(ip4报文路由处理)等几个子功能；slb-ip6节点进一步分为error-drop(错误处理)、interface-output(出接口处理)、ip6-input(ipv6报文输入处理)、ip6-lookup(ipv6报文路由处理)等几个子功能。

参见图6，提供了slb-ip4/slb-ip6节点的一个示例性上下行数据报文处理流程。其核心流程为：对于从基站、DN或者其他UPF进来并到达SLB的报文，SLB根据收包接口的接口索引判断入方向接口的类型，然后依据入方向的接口类型和IP地址分别对报文进行转发。其中，对于N3\N6\N9业务数据负载均衡：GTPU报文只会存在N3/N9接口，N6接口不处理GTPU报文，对于N3/N9接口进来的GTPU报文，偏移到内层的IP头解析出源IP地址(UE的地址)，根据源IP地址散列到一个目标UPF。对于N3-LAN/N9-LAN接口(即UPF容器与负载均衡模块SLB之间的接口)收到的GTPU报文，直接通过N3/N9接口发出，N6-LAN接口(同样为UPF容器与SLB之间的接口)不会收到GTPU报文，从而不做处理。对于N3/N9接口的非GTPU报文，统一交给转发平台的路由模块处理(符合路由条件才转发，否则drop)。

另外，可选的，本申请基于VPP实现的负载均衡模块，采用用户态高性能旁路模式转发业务数据。

旁路模式为无需负载均衡模块所处设备的系统内核进行流量收发处理的模式，旁路模式下，负载均衡模块接收待处理业务流量并转发的路径为：接口(N3/N6/N9)→VPP(SLB)→UPF网元，由于无需负载均衡模块所处设备的系统内核参与流量收发，从而进一步提升了负载均衡模块的流量收发效率。

可选的，在一实施例中，本申请基于增添的负载均衡模块对UPF网元进行冗余模式设计，冗余模式下，在5G核心网部署有互为冗余的两套UPF网元，并在冗余模式基础上设计对UPF网元的主备应用。在主备应用中，互为冗余的两套UPF网元，相应包括实际被启用并处于运行状态的主用UPF网元和未被启用处于未运行状态的备用UPF网元。

主用UPF网元进一步包括处于运行状态的多个UPF网元实例。

在主用UPF网元运行过程中，备用UPF网元通过同步主用UPF网元的数据(如PDU会话表)，维持与主用UPF网元的数据一致。结合参见图7示出的主备模式下的UPF产品部署架构，其中UPF1为主用UPF网元，UPF2为备用UPF网元，UPF2可通过DB并基于消息同步机制，同步UPF1的相关动态数据，如DPU会话表等。

该实施例中，参见图8示出的处理方法流程图，本申请公开的处理方法还可以包括以下处理步骤：

步骤105、响应于检测到主用UPF网元的下线事件，对备用UPF网元进行主备切换，使备用UPF网元作为切换后的主用UPF网元处于运行状态。

在主用UPF网元因故障或运维等原因而需要下线时，启用备用UPF网元，并对备用UPF网元执行主备切换处理。

对备用UPF网元执行的主备切换处理，包括但不限于启动备用UPF网元使其处于运行状态，将原主用UPF网元已接收还未完成处理的业务流量和还未向备用UPF网元同步的PDU会话表，同步至备用UPF网元，并将备用UPF网元的状态切换配置为主用状态。

步骤106、利用负载均衡模块获取与记录切换后的主用UPF网元的预设信息，并建立负载均衡模块与切换后的主用UPF网元间的连接。

同时，负载均衡模块获取并记录切换后的主用UPF网元的预设信息，包括但不限于获取并记录切换后的主用UPF网元对应的容器ID、容器属性、MAC地址等信息，并基于这些信息打通与切换后的主用UPF网元的接口间的连接通道，实现建立负载均衡模块与切换后的主用UPF网元间的通信连接。

可选的，采用OAM实时检测当前整个环境中正在工作的UP container，通过GRPC消息向SLB container配置当前处于工作状态的容器的相关信息，如容器ID，容器属性等，借助OAM的实时检测及向SLB container的信息配置功能，使得在发生主备切换事件时，实现新上线主用UPF网元的容器ID、容器属性等信息在负载均衡模块的配置、记录。

主备切换时，对于新上线的主用UPF网元的MAC地址的获取，当原来运行的主用UPF网元因异常/故障等原因导致触发主备切换时，负载均衡模块向所在环境广播arp(AddressResolution Protocol，地址解析协议)请求，新上线的主用UPF网元会作出应答，将其MAC地址响应给负载均衡模块，由负载均衡模块进行记录，该过程即为图3中示出的“arp漂移”，用于针对5G核心网中UPF网元的主备切换(或后续的UPF升级)，实时定位并记录新上线的UPF网元的MAC地址。

本实施例通过基于增添的负载均衡模块对UPF网元进行主备设计，解决了现有UPF网元不支持主备的问题，进而避免了当前UPF网元因缺乏容灾机制所带来的业务中断影响。

可选的，在一实施例中，本申请还基于增添的负载均衡模块及上述的冗余模式，为UPF网元设计动态升级机制，该机制基于冗余模式下部署的互为冗余的两套UPF网元，实现对UPF网元的动态、平滑升级。

该实施例中，参见图9示出的处理方法流程图，本申请公开的处理方法还可以包括以下处理步骤：

步骤107、响应于获得的升级请求，利用构建的部署实现升级所需的功能，得到升级后的UPF网元。

该独立于待升级UPF网元的UPF网元实例，可以是备用UPF网元的网元实例，待升级的UPF网元可以是当前的主用UPF网元，在主用UPF网元运行过程中，备用UPF网元通过同步主用UPF网元的数据(如PDU会话表)，维持与主用UPF网元的数据一致，且主用UPF网元运行过程中，备用UPF网元处于未被启用的非运行状态，未向外提供服务。

当因漏洞修复、功能改进等原因需对当前的主用UPF网元进行升级时，触发对主用UPF网元的升级请求，并响应该请求，在备用UPF网元的网元实例已同步主用UPF网元的数据(如PDU会话表)基础上，部署升级所需的一系列功能，除此之外，还需要将主用UPF网元当前已接收还未完成的业务流量和当前还未向备用UPF网元同步的PDU会话表，同步至备用UPF网元，并将完成以上功能部署及数据同步的备用UPF网元作为升级后的UPF网元加以启用。

步骤108、运行升级后的UPF网元。

之后，启动并运行升级后的UPF网元。

步骤109、利用负载均衡模块至少记录升级后的UPF网元的预设信息，并建立负载均衡模块与升级后的UPF网元间的连接，以完成升级。

同时，负载均衡模块获取并记录升级后的UPF网元的预设信息，包括但不限于获取并记录升级后的UPF网元对应的容器ID、容器属性、MAC地址等信息，并基于这些信息打通与升级后的UPF网元的接口间的连接通道，实现建立负载均衡模块与升级后的UPF网元的通信连接。

具体可借助OAM的实时检测及向SLB container的信息配置功能，实现将升级后的UPF网元的容器ID、容器属性等信息向负载均衡模块的配置、记录，并可基于arp漂移，实时定位与记录升级后新上线的UPF网元的MAC地址。

在建立负载均衡模块与升级后的UPF网元间的连接后，可将原有待升级的UPF网元下线，至此完成对UPF网元的升级。其中，在获得升级请求至完成升级之前，基于原有的待升级UPF网元提供业务流量处理能力。

本实施例通过基于增添的负载均衡模块对UPF网元进行升级设计，解决了现有UPF网元不支持无状态升级的问题，可实现对UPF网元的动态、平滑升级，整个升级过程对业务处理无影响。

可选的，在一实施例中，本申请基于增添的负载均衡模块对UPF网元进行弹缩模式设计，并在弹缩模式下支持对UPF网元的扩缩容处理。

该实施例中，参见图10示出的处理方法流程图，本申请公开的处理方法还可以包括以下处理步骤：

步骤110、检测各个UPF网元实例对业务流量的负载状况。

可选的，OAM设定分别用于触发扩容和缩容的阈值，包括但不限于针对单一UPcontainer设置用于触发扩容(负载分担)的内存占用阈值、cpu占用阈值、流量承载阈值，以及用于触发缩容的内存占用阈值、cpu占用阈值、流量承载阈值等，并通过GRPC消息将设置的相关阈值下发给每一UP container。UP container基于接收的阈值定时上报其当前的容器状态，如容器的内存占用、cpu占用、流量承载是否超出对应的用于触发扩容的阈值等。

步骤111、响应于UPF网元实例的负载状况满足相应负载条件，对UPF网元进行对应的扩缩容处理。

OAM可根据各UP container上报的信息，识别各个UPF网元实例对业务流量的负载状况。并按照设定的负载算法进行计算，判定是否需要进行扩容/缩容，如判断是否需要增加或者减少UPF网元实例(UP container)，并在需要时，通过GRPC消息向SLB container下发进行扩容/缩容处理的指示，如下发增加或者减少UP container的相关指令信息等。

其中，如果UPF网元实例的负载状况满足第一负载条件，则判定需对UPF网元进行扩容处理；如果UPF网元实例的负载状况满足第二负载条件，则判定对UPF网元进行缩容处理。

UPF网元实例的负载状况满足第一负载条件，可以是但不限于，UPF网元实例所对应UP container的内存占用、cpu占用和/或流量承载超出设定的用于触发扩容的相应阈值。UPF网元实例的负载状况满足第二负载条件，可以是但不限于，UPF网元实例所对应UPcontainer的内存占用、cpu占用和/或流量承载低于设定的用于触发缩容的相应阈值。

对UPF网元的扩容处理，可通过如下任一种方式或两种方式的结合实现：

11)为UPF网元增加UPF网元实例；

参见图11提供的弹缩模式下的UPF产品部署框架图，其中UPF1表示5G核心网中原有的UPF网元，UPF2表示动态扩容后所增加的UPF网元。

12)提升UPF网元的已有UPF网元实例中至少一个UPF网元实例的处理能力；如，为一个或多个UPF网元实例增加分配一定的CPU/内存等。

相类似，对UPF网元的缩容处理，可通过如下任一种方式或两种方式的结合实现：

21)减少UPF网元的UPF网元实例；

22)降低UPF网元的已有UPF网元实例中至少一个UPF网元实例的处理能力，如，减少一个或多个UPF网元实例的CPU/内存占用量等。

步骤112、利用负载均衡模块执行与扩缩容处理相匹配的处理。

同时，需在负载均衡模块执行与扩缩容处理相匹配的处理。

其中，针对扩容处理，响应于在扩容处理中增加UPF网元实例，利用负载均衡模块获取与记录扩容时所增加的UPF网元实例的预设信息，并建立与所增加的UPF网元实例间的连接。

所增加的UPF网元实例的预设信息，包括但不限于所增加UPF网元实例对应的容器ID、容器属性、MAC地址等信息。具体可借助OAM的实时检测及向SLB container的信息配置功能，实现所增加的UPF网元实例的容器ID、容器属性等信息向负载均衡模块的配置、记录，并可基于arp漂移，实时定位与记录扩容后新上线的UPF网元的MAC地址。

负载均衡模块具体基于扩容时所增加UPF网元实例对应的容器ID、MAC地址等信息，打通与所增加UPF网元实例的接口间的连接通道，实现建立负载均衡模块与所增加UPF网元实例间的连接。

针对缩容处理，响应于减少UPF网元实例，至少断开负载均衡模块与缩容时所关闭的UPF网元实例间的连接。

本实施例通过基于增添的负载均衡模块对UPF网元进行弹缩模式设计，并在弹缩模式下对UPF网元按需进行扩/缩容处理，解决了现有UPF网元不支持动态扩缩容的问题，可在不影响业务处理情况下，实现UPF网元的业务自动弹缩。

本申请实施例还公开一种处理系统，至少包括UPF网元和为UPF网元设置的负载均衡模块，UPF网元包括处于运行状态的多个UPF网元实例；

其中，负载均衡模块用于执行如上文任一实施例公开的处理方法，通过执行本申请公开的处理方法，提供对UPF网元业务数据流的动态负载均衡能力，以及提供对UPF网元的手动/自动扩缩容能力、无状态升级能力，并为后续做1+1(两套UPF网元，如主+备)、N+1(多套UPF网元)等多种场景提供基础平台支撑。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

为了描述的方便，描述以上系统或装置时以功能分为各种模块或单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

最后，还需要说明的是，在本文中，诸如第一、第二、第三和第四等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (9)

1.一种处理方法，包括：

基于UPF网元的负载均衡模块，接收待处理业务流量；所述UPF网元包括处于运行状态的多个UPF网元实例；

所述负载均衡模块确定所述待处理业务流量的报文头中预定字段的字段信息；

根据预设分流规则和所述预定字段的字段信息，所述负载均衡模块确定用于处理所述待处理业务流量的目标UPF网元实例；

所述负载均衡模块将所述待处理业务流量传输至所述目标UPF网元实例进行处理；

UPF网元包括处于运行状态的主用UPF网元和未处于运行状态的备用UPF网元；所述备用UPF网元通过同步所述主用UPF网元的数据，使得与所述主用UPF网元的数据一致；

所述方法还包括：

响应于检测到所述主用UPF网元的下线事件，对所述备用UPF网元进行主备切换，使所述备用UPF网元作为切换后的主用UPF网元处于运行状态；

利用所述负载均衡模块获取与记录切换后的主用UPF网元的预设信息，并建立所述负载均衡模块与所述切换后的主用UPF网元间的连接；

所述利用所述负载均衡模块获取与记录切换后的主用UPF网元的预设信息包括：

负载均衡模块实时检测当前整个环境中正在工作的用户面容器，向负载均衡容器配置当前处于工作状态的用户面容器的相关信息，所述相关信息包括容器ID、容器属性；

负载均衡模块向当前环境广播地址解析协议请求，记录新上线的主用UPF网元应答响应的MAC地址。

2.根据权利要求1所述的方法，所述负载均衡模块确定所述待处理业务流量的报文头中预定字段的字段信息，包括：

确定所述待处理业务流量的流量类型；

根据所述流量类型对应的解析规则，解析所述待处理业务流量的报文头，基于解析结果提取所述待处理业务流量的报文头中预定字段的字段信息。

3.根据权利要求2所述的方法，所述根据预设分流规则和所述预定字段的字段信息，所述负载均衡模块确定用于处理所述待处理业务流量的目标UPF网元实例，包括：

根据预设分流规则对所述预定字段的字段信息进行处理，得到处理结果，根据所述处理结果确定一UPF网元实例标识或容器标识；

将所述UPF网元实例标识对应的UPF网元实例或所述容器标识所指示容器中部署的UPF网元实例确定为目标UPF网元实例；

其中，不同UPF网元实例分别部署在不同的容器中。

4.根据权利要求1所述的方法，所述方法还包括：

检测各个UPF网元实例对业务流量的负载状况；

响应于UPF网元实例的负载状况满足相应负载条件，对UPF网元进行对应的扩缩容处理；

利用所述负载均衡模块执行与所述扩缩容处理相匹配的处理。

5.根据权利要求4所述的方法，所述响应于UPF网元实例的负载状况满足相应负载条件，对UPF网元进行对应的扩缩容处理，包括：

如果UPF网元实例的负载状况满足第一负载条件，对UPF网元进行扩容处理；如果UPF网元实例的负载状况满足第二负载条件，对UPF网元进行缩容处理；

其中，所述扩容处理包括：为UPF网元增加UPF网元实例，和/或，提升UPF网元的已有UPF网元实例中至少一个UPF网元实例的处理能力；所述缩容处理包括：减少UPF网元的UPF网元实例，和/或，降低UPF网元的已有UPF网元实例中至少一个UPF网元实例的处理能力。

6.根据权利要求5所述的方法，所述利用所述负载均衡模块执行与所述扩缩容处理相匹配的处理，包括：

响应于增加UPF网元实例，所述负载均衡模块获取与记录扩容时所增加的UPF网元实例的预设信息并建立与所增加的UPF网元实例间的连接；

或者，响应于减少UPF网元实例，所述负载均衡模块至少断开与缩容时所关闭的UPF网元实例间的连接。

7.根据权利要求1所述的方法，所述方法还包括：

响应于获得的升级请求，利用构建的独立于待升级UPF网元的UPF网元实例部署实现升级所需的功能，得到升级后的UPF网元；

运行升级后的UPF网元；

所述负载均衡模块至少记录升级后的UPF网元的预设信息，并建立所述负载均衡模块与所述升级后的UPF网元间的连接，以完成升级；

其中，在获得所述升级请求至完成升级之前，基于所述待升级UPF网元提供业务流量处理能力。

8.根据权利要求1所述的方法，其中，所述负载均衡模块通过旁路模式接收待处理业务流量，并将待处理业务流量传输至对应的目标UPF网元实例；

所述旁路模式，为无需所述负载均衡模块所处设备的系统内核进行流量收发处理的模式。

9.一种处理系统，至少包括UPF网元和为所述UPF网元设置的负载均衡模块，所述UPF网元包括处于运行状态的多个UPF网元实例，UPF网元包括处于运行状态的主用UPF网元和未处于运行状态的备用UPF网元；所述备用UPF网元通过同步所述主用UPF网元的数据，使得与所述主用UPF网元的数据一致；

其中，所述负载均衡模块用于：

接收待处理业务流量；

确定所述待处理业务流量的报文头中预定字段的字段信息；

根据预设分流规则和所述预定字段的字段信息，确定用于处理所述待处理业务流量的目标UPF网元实例；

将所述待处理业务流量传输至所述目标UPF网元实例进行处理；

响应于检测到所述主用UPF网元的下线事件，对所述备用UPF网元进行主备切换，使所述备用UPF网元作为切换后的主用UPF网元处于运行状态；

利用所述负载均衡模块获取与记录切换后的主用UPF网元的预设信息，并建立所述负载均衡模块与所述切换后的主用UPF网元间的连接；

所述利用所述负载均衡模块获取与记录切换后的主用UPF网元的预设信息包括：

负载均衡模块实时检测当前整个环境中正在工作的用户面容器，向负载均衡容器配置当前处于工作状态的用户面容器的相关信息，所述相关信息包括容器ID、容器属性；

负载均衡模块向当前环境广播地址解析协议请求，记录新上线的主用UPF网元应答响应的MAC地址。