CN115918044A - 移动通信网络中用于动态且高效的负载均衡的方法和设备 - Google Patents

Abstract

本公开涉及一种将用于在4G系统之后支持更高的数据速率的5G通信系统与IoT技术集成的通信技术及其系统。本公开能够被应用于基于5G通信技术和IoT相关技术的智能服务(例如，智能家居、智能建筑、智能城市、智能汽车或联网汽车、卫生保健、数字教育、零售商业、安防和安全相关服务或类似服务)。本公开公开了一种动态且高效的负载均衡方法和设备。

Description

移动通信网络中用于动态且高效的负载均衡的方法和设备

技术领域

本公开涉及移动通信系统，具体地涉及一种在这样的移动通信系统中用于负载均衡的方法和设备。更具体地，本公开涉及一种在移动通信网络中用于动态且高效的负载均衡的方法和设备。

背景技术

为了满足自4G通信系统的部署以来不断增加的对无线数据业务的需求，已做出努力来开发改进的5G或准5G通信系统。因此，5G或准5G通信系统还被称作“超越4G网络”或“后LTE系统”。

考虑将5G通信系统实现在更高的频率(mmWave)频带(例如60GHz频带)中，以便实现更高的数据速率。为了减小无线电波的传播损耗并且增加传输距离，在5G通信系统中讨论了波束形成、大规模多输入多输出(MIMO)、全维MIMO(FD-MIMO)、阵列天线、模拟波束形成、大规模天线技术。

另外，在5G通信系统中，针对系统网络改进的开发基于高级小小区、云无线接入网络(RAN)、超密集网络、装置到装置(D2D)通信、无线回程、移动网络、协作通信、协调多点(CoMP)、接收端干扰消除等进行着。

在5G系统中，已开发了作为高级编码调制(ACM)的混合FSK与QAM调制(FQAM)和滑动窗口叠加编码(SWSC)，以及作为高级接入技术的滤波器组多载波(FBMC)、非正交多址(NOMA)和稀疏码多址(SCMA)。

同时，因特网最近正在从信息由人们创建并消费的基于人的连接网络演进为在诸如物的分布式组件之间交换并处理信息的物联网(IoT)网络。此外，万物互联(IoE)技术也正在兴起，在IoE技术中，大数据处理技术通过与云服务器等的连接与IoT技术关联起来。IoT的实现方式需要诸如例如以下的各种技术要素：传感技术、有线和无线通信以及联网基础设施，并且需要服务接口技术和安全技术，因此，最近正在对诸如传感器网络、机器到机器(M2M)通信和机器类型通信(MTC)的技术进行研究。在IoT环境中，能够提供智能IT(因特网技术)服务，该IT服务收集并分析从连接的物生成的数据以在人类生活中创造新价值。IoT可以通过现有信息技术(IT)与各个行业之间的融合被应用于诸如例如以下的各种技术领域：智能家居、智能建筑、智能城市、智能汽车或联网汽车、智能电网、卫生保健、智能家电、高级医疗服务等。

因此，已做出各种尝试来将5G通信系统应用于IoT网络。例如，正在使用诸如波束形成、MIMO和阵列天线的5G通信技术来实现诸如传感器网络、机器到机器(M2M)通信、机器类型通信(MTC)等的技术。以上描述的与大数据处理技术一起应用云无线接入网络(云RAN)可以是5G技术与IoT技术的这种融合的示例。

另一方面，已为了支持这样的5G通信系统而改进了核心网络，并且支持5G通信系统的核心网络可以被称为5G核心(5GC)。在这种情况下，需要对用于调节构成这种改进核心网络的各种网络实体的负载的负载均衡进行改进。

发明内容

技术问题

本公开的各方面是为了解决至少以上提及的问题和/或缺点并且提供一种即使在网络资源未得到充足保证的情形下也高效地执行负载均衡的方法。

此外，通过提出用于高效地处理各种请求的负载均衡方案，本公开提供了一种用于动态地执行针对数据业务进行了优化的负载均衡的方法。

技术方案

根据为了解决上述技术问题的本公开的实施例，提供了一种负载均衡的方法，所述方法包括：接收与网络实体相关的服务请求；基于与所述服务请求相关的策略来选择执行负载均衡的引擎；创建包括所选择的引擎的负载均衡实例；以及通过所述负载均衡实例针对与所述服务请求相关的数据分组执行所述负载均衡。

根据为了解决上述技术问题的本公开的实施例，提供了一种负载均衡器，所述负载均衡器包括：至少一个引擎；编排器(orchestrator)，所述编排器用于根据预设策略来选择所述至少一个引擎；以及控制器，所述控制器连接到所述至少一个引擎和所述编排器以控制所述负载均衡器，其中，所述控制器接收与网络实体相关的服务请求，所述编排器基于与所述服务请求相关的策略来选择执行负载均衡的引擎，所述控制器创建包括所选择的引擎的负载均衡实例，并且所选择的引擎通过所述负载均衡实例针对与所述服务请求相关的数据分组执行所述负载均衡。

有益效果

根据本公开中提出的实施例，可以对请求进行分类并且据此执行负载均衡，从而根据请求提供经过优化的服务。此外，可以通过负载均衡器(或负载均衡实例)来根据请求呈现经过优化的结果，因此，能够高效地节省用于负载均衡的网络资源。

附图说明

图1是图示了与本公开的实施例相关的核心网络结构及其网络实体的图。

图2是图示了与本公开的实施例相关的网络元件的负载均衡过程的示意图。

图3是图示了根据本公开的实施例的负载均衡过程的示意图。

图4是图示了根据本公开的实施例的负载均衡过程及负载均衡器的结构的图。

图5是图示了根据本公开的实施例的负载均衡过程的流程图。

图6是图示了根据本公开的实施例的负载均衡过程及负载均衡器的结构的图。

图7是图示了根据本公开的实施例的负载均衡过程的流程图。

图8是图示了根据本公开的实施例的核心网络结构和网络实体的图。

具体实施方式

以下，将参考附图详细地描述本公开的优选实施例。在此时，应当注意，在整个附图中，如果可能的话，相同或相似的组件由相同或相似的附图标记来表示。此外，可以省略对可能使本公开的要点模糊的公知功能和配置的详细描述。

在本公开中描述各种实施例时，应当注意，可以省略对在本公开所属技术领域中公知的并且与本公开不直接相关联的技术内容的任何描述。这是为了通过省略此类不必要的描述来更清楚地揭示本公开的主题，而不使本公开的主题模糊。

出于相同原因，可以在附图中放大、省略或者示意性地图示一些组件。此外，每个图中的每个组件的大小可能不完全反映其实际大小。在每个图中，相同或对应的元件被指配了相同或相似的附图标记。

通过参考结合附图在下面详细地描述的实施例，本公开的优点和特征以及用于实现这些优点和特征的方法将变得清楚。然而，本公开不限于在下面公开的实施例，并且可以以各种不同形式来实现。并且仅仅提出那些实施例以使得本公开的公开内容更完整，并对本公开所属技术领域的技术人员进行充分地告知。因此，本公开的范围将仅仅由权利要求的范围限定。相似的附图标记在本公开中自始至终指相似的元件。

在此时，应理解，可以通过计算机程序指令来执行任何流程图的每个框以及流程图的组合。这些计算机程序指令可以被安装在通用计算机、专用计算机或其他可编程数据处理设备的处理器中，使得由计算机或其他可编程数据处理设备的处理器执行的指令创建用于执行流程图框中描述的功能的装置。这些计算机程序指令还可以被存储在计算机可用或计算机可读存储器中，这些计算机程序指令能够引导计算机或其他可编程数据处理设备以某种方式并且因此在计算机可用或计算机可读存储器中实现功能，因此，还可以产生包含使存储在计算机可用或计算机可读存储器中的指令执行流程图框中描述的功能的指令装置的制品。计算机程序指令还可以被安装到计算机或其他可编程数据处理设备上，所以指令还可以通过使计算机或其他可编程数据处理设备执行一系列操作步骤以创建计算机执行的进程来提供用于执行流程图框中描述的功能的操作步骤。

此外，每个框可以表示包括用于执行指定逻辑功能的一个或更多个可执行指令的代码的模块、片段或部分。此外，应当注意，在一些替代实现方式中，各框中提及的功能还可以无序发生。例如，可以基本上同时地执行一个接一个地布置的两个连续框，或者有时可以根据对应功能以相反次序执行这些框。

如本公开的各种实施例中使用的，术语“～单元(或模块)”可以包括在诸如例如FPGA或ASIC的软件或硬件组件中实现以执行某种功用或功能的单元。然而，术语“～单元(或模块)”不是仅限于软件或硬件。这样的单元或模块可以被配置为驻留在可寻址存储介质上或者可以被配置为再生一个或更多个处理器。因此，例如，术语“～单元(或模块)”可以包括诸如以下的各种组件：软件组件、面向对象的软件组件、类组件和任务组件、进程、功能、属性、过程、子例程、程序代码段、驱动程序、固件、微码、电路系统、数据、数据库、数据结构、表、数组、变量等。组件和单元(或模块)中提供的功能可以被组合成更小数量的组件和单元(或模块)，或者进一步分成额外的组件和单元(或模块)。此外，组件和单元(或模块)可以被实现为在装置或安全多媒体卡中再生一个或更多个CPU。

同时，以下，终端(或用户设备(UE))可以包括移动终端和固定终端二者，所述移动终端诸如例如被提供有移动通信服务的移动用户的移动电话、智能电话或膝上型电脑。基站(BS)可以包括演进型节点B(eNB)、下一代节点B(gNB)、发送点(TP)、发送和接收点(TRP)、无线接入网络(RAN)节点等作为通过无线信道向用户终端提供通信服务的实体。

以下，在详细地描述本公开的实施例时，主要对分组核心(或者，5G系统、5G核心网络或NG核心(下一代核心))进行描述，该分组核心是由包括3GPP(第三代合作伙伴计划)和ESTI(欧洲电信标准机构)的移动通信规范标准化组织指定的移动通信标准上的核心网络，但是在不显著地背离本公开的范围的情况下，本公开的主旨还可以稍加变化地应用于具有相同或类似技术背景的其他通信系统。这种应用在本公开的技术领域的专家的确定下将是可能的。

为了描述的方便，以下，可以使用3GPP标准规范和ETSI标准规范中定义的一些术语和名称。然而，本公开不受这些术语和名称限制，并且可以同样地适用于符合其他技术标准的通信系统。

此外，如在下面阐述的公开内容中使用的，提及核心网络的对象的术语、提及核心网络中的消息的术语、提及网络实体之间的接口的术语以及提及各种标识信息的术语都是为了描述的方便而举例说明的。因此，这些术语不限于本公开中使用的那些术语，并且可以使用提及具有等同或类似技术含义的对象的其他术语。例如，术语“网络实体”可以具有与诸如网络元件、网络功能、网络实例、网络节点等的各种术语相同的技术含义。

图1是图示了与本公开的实施例相关的核心网络结构和网络实体的图。

执行由5G移动通信系统提供的每个功能的单元可以被定义为网络实体、网络元件(NE)或网络功能(NF)。在图1中示出了5G移动通信系统的核心网络结构和构成该核心网络结构的网络实体。

代表性网络实体可以包括例如：管理终端的网络接入和移动性的接入和移动性管理功能(AMF)、执行会话相关功能的会话管理功能(SMF)、负责传送用户平面数据的用户平面功能(UPF)、协助考虑服务要求来控制用户平面路由状态的应用功能(AF)、执行将核心网络实体的功能暴露给外部的功能的网络暴露功能(NEF)、负责数据存储和管理的统一数据管理(UDM)和统一数据储存库(UDR)、负责管理计费和策略的策略和控制功能(PCF)、针对来自终端的对分组数据网络(PDN)会话的请求使用网络切片选择辅助信息(NSSAI)来选择特定网络切片的网络切片选择功能(NSSF)、为各种类型的服务提供订户的统一认证的认证服务器功能(AUSF)、监测核心网络NF的服务状态并且支持NF之间的交互工作的网络储存库功能(NRF)、以及作为用于向终端提供运营商或第三方任一方的服务的服务网络的数据网络(DN)。

图1所示的网络实体可以经由彼此之间定义的接口彼此连接。例如，可以将AMF与SMF之间的接口定义为N11，可以将SMF与UPF之间的接口定义为N4，将UPF与DN之间的接口定义为N6，将AMF与RAN之间的接口定义为N2，并且将RAN与UPF之间的接口定义为N3。

此外，为特定网络实体定义了基于服务的接口(SBI)，例如，可以将NSSF的接口定义为Nnssf，将AMF的接口定义为Namf，将SMF的接口定义为Nsmf，将PCF的接口定义为Npcf等。

图1中描述的核心网络结构仅仅是示例，核心网络可以包括用于提供移动通信服务的更大数量的其他网络实体。另外，上述网络实体和接口的名称仅仅是示例，可以根据个人偏好而不同地提及网络实体的那些名称和功能以及接口的名称。换句话说，将在下面描述的本公开的内容不应当被解释为限于图1所示的网络实体和接口的定义和描述。

同时，最近已对软件定义网络(SDN)和网络功能虚拟化(NFV)进行了各种研究和开发。因此，将对SDN和NFV进行描述。

首先，术语“SDN”是将网络实体的负责控制功能的部分与负责发送/接收功能的部分分离的概念。也就是说，它可以意味着网络实体仅负责发送/接收功能，并且控制功能被转移到单独的通用服务器。通过这种分离，负责控制功能的单独的服务器能够对多个网络装置进行高效控制。

单独地，术语“NFV”可以意指使网络实体虚拟化。具体地，NFV可以指在逻辑上划分物理网络实体的资源，使得它能够与多个用户或装置一起被共享和使用。因此，能够通过经由NFV允许网络实体的资源由多个虚拟机(VM)共享来提高资源使用效率，能够通过软件/硬件的分离来降低网络构造成本，并且与物理网络实体相比，更灵活的安装是可能的。

通过如上所述使物理网络资源虚拟化，即使物理网络配置发生改变，也可以使虚拟网络配置保持相同，以免影响VM虚拟化网络功能(VNF)。在这种上下文中，物理网络可以被称为底层网络，而虚拟网络可以被称为覆盖网络。

除了以上提及的内容之外，最近还对使telco(telecommunicationcompany，电信公司)网络云化进行了研究和开发。云具有能够使用比上述虚拟机或NFV更灵活的容器的优点。因此，最近正在通过使面向telco的VNF容器化来构建telco云网络来对网络实体的灵活操作和扩展进行研究和开发。

这样的telco云网络可以指由常规商业平台提供的技术、产品、解决方案等的基于云的实现方式。在telco云网络中，用于确定其性能可靠性的主要指标可以包括例如可用性、服务质量(QoS)、服务连续性等。

图2是图示了与本公开的实施例相关的网络元件的示例负载均衡过程的示意图。

以下描述中使用的网络元件可具有与如上定义的网络实体、网络功能、网络实例和网络节点相同的含义。

构成核心网络的网络元件可以经由预定接口与其他网络元件通信以发送和接收分组。在此过程中，为了高效地处理由网络元件接收到的分组或请求，通常需要考虑负载状态，并且，这种考虑网络元件(或网络实体)之间的负载状态、根据预定准则来共享或者分配用于处理分组或请求的负载的方式可以被称为负载均衡。

另一方面，常规负载均衡由布置在网络元件外的单独的服务器执行，这种负载均衡方法没有完全地满足对上述容器化的核心网络的要求。例如，常规负载均衡可以是适合于应用了L4协议或L7协议的云网络或web规模的用例的解决方案。因此，根据常规负载均衡方法，在不得不处理两种协议的情况下，必须在针对每种协议依次连接负载均衡器的级联连接中实现负载均衡器。

然而，由于以下原因，这种类型的常规负载均衡方法导致不可能满足telco云网络的要求。

首先，需要使用单个负载均衡器来支持各种协议(例如，流控制传输协议(SCTP)、超文本传送协议版本2(HTTP2.0)等)的处理。特别地，在网络资源不足以实现多级负载均衡器来支持多个协议或层的边缘场景或远边缘场景中，需要与常规负载均衡方法不同的新负载均衡方案。

其次，需要能够动态地调整负载均衡拓扑的能力。换句话说，为了动态地控制或者改变诸如例如网络上的中间、边缘和直通(pass-through)负载均衡的各种拓扑，需要与常规负载均衡方法不同的负载均衡方法的新方案。

再次，需要针对分类或telco相关属性进行了优化的负载均衡。也就是说，为了动态地反映这样的分类和属性，与现有技术相反，需要一种利用基于内核的路由或硬件分流的新型负载均衡方案。

最后，当配置负载均衡链以处理根据请求接收到的分组时，需要配置差异化和优先化的负载均衡路径。也就是说，需要一种新型负载均衡方案来基于所接收到的分组的性质(如源、目的地以及它是语音还是数据)根据优先级高效地配置负载均衡链。

图3是图示了根据本公开的实施例的示例负载均衡过程的示意图。

在以下实施例中，提出了用于对递送给核心网络的网络实体的请求进行智能且动态的处理的负载均衡方法以及用于该负载均衡方法的负载均衡器。

根据本公开的实施例的负载均衡方法和负载均衡器能够提供一种解决方案，该解决方案能够支持对根据客户端的请求接收到的分组流的数据分组分类和增强性平台感知(EPA)，以及提供具有低延时、低占用面积、资源优化等的改进的性能。

可以根据图3所示的关系来定义负载均衡方法和负载均衡器与网络元件的关系。根据所提出的实施例的负载均衡器300可以被实现为对应于特定网络元件310，以及执行负载均衡以检测从客户端向网络元件310发送的请求并处理该请求。

更具体地，根据实施例的负载均衡器300可以从客户端接收对由网络元件310提供的各种服务(例如，图3中的服务A、服务B、服务C等)的请求，并且对该请求执行负载均衡，使得网络元件310能够高效地利用网络资源来处理该请求。

特别地，如上所述，由于可能从不同客户端接收到根据不同层的协议和分组特性的请求，所以负载均衡器300不得不智能地执行负载均衡，以允许网络元件310高效地处理这些请求。为此目的，负载均衡器300将不得不对客户端的请求进行分类，使得网络元件310能够提供经过优化的服务。

此外，负载均衡器300可以被实现为对应于网络元件310。也就是说，根据参考图2描述的常规负载均衡方法，存在用于处理特定网络元件的负载均衡的单独的服务器，但是如所提出的根据实施例的负载均衡器300可以被实现为对应于(或者依赖于)网络元件310。

因此，通过这种关系可以理解，网络元件310可以在内部或在外部具有它自己的负载均衡器300，并且网络元件310可以包括对应于它自己的一个或更多个负载均衡器300。例如，当从客户端接收到的请求的数量相对大时，网络元件310可以包括用于处理这些请求的多个负载均衡器300。

图4是图示了根据本公开的实施例的示例负载均衡过程及负载均衡器的结构的图。

根据实施例，用于(或者对应于)网络元件450的负载均衡器400可以包括图4所示的各种组件。例如，根据实施例的负载均衡器400可以包括控制器410、引擎组420和编排器430，并且本领域的专家将容易地领会，所图示的结构和配置仅仅是示例。

图4所示的负载均衡器400的每个组件可以是在软件中实现的逻辑配置，或者可以例如用服务、容器或其他概念性配置来实现。或者，可以将一些或所有组件实现为硬件。以下，详细地描述图4所示的每个组件。

首先，引擎组420可以包括一个或更多个引擎(图4中的引擎A、引擎B、引擎C等)，并且包括在引擎组420中的一个或更多个引擎(或模块)可以针对分组流执行实际的负载均衡。为此目的，引擎组420可以针对一个或更多个引擎(或模块)执行后端列表、当前状态、连接跟踪和特定后端的选择。

特别地，包括在引擎组420中的每个引擎可以针对特定协议执行负载均衡。例如，引擎组420可以包括针对SCTP协议执行分组流的负载均衡的ipvsadm引擎(或模块)，并且可以包括针对HTTP2.0协议执行分组流的负载均衡的envoy引擎(或模块)或ngnix引擎(或模块)。此外，引擎组420可以包括智能网络接口卡(NIC)或现场可编程门阵列(FPGA)作为用于分流并处理大容量分组的硬件加速器。此外，这些引擎或模块可以执行与诸如L4或L7等的各个层的协议相关的负载均衡。

针对特定协议的分组流的负载均衡可以由包括在引擎组420中的一个引擎(模块)以及支持该协议的多个不同引擎(模块)处理。相反地，不言而喻，多个不同的协议的分组流可以由一个引擎(模块)处理。

另一方面，包括在引擎组420中的一个或更多个引擎或模块可以使用诸如服务或容器等的虚拟资源来实现，并且与以上所述相反，一个或更多个引擎或模块可以实现在包括在引擎组中的硬件中。在硬件中实现的引擎或模块可以暗示负载均衡器400和所对应的引擎或模块在物理上连接。

接下来，编排器430被配置为存储并管理与负载均衡相关的策略和配置。换句话说，编排器430可以具有并保持关于负载均衡器400能够使用的负载均衡方案和引擎(或模块)的信息，并且与网络元件450交互，从而动态地确定要为对由网络元件450提供的服务460的客户端请求405选择哪个负载均衡方案。

可以根据输入到编排器430的策略和准则来执行此确定过程。例如，编排器430可以根据与请求相对应的分组流的特性或协议的类型来确定能够满足分组流的服务级别协定(SLA)和服务质量(QoS)的负载均衡方案。大体上可以将编排器430确定负载均衡方案的过程描述为确定是否在应用级别(即，L7)执行负载均衡、是否在内核级别(即，L4)执行负载均衡、或者是否在硬件级别执行负载均衡的过程。此外，编排器430除了确定这样的负载均衡方案之外还可以选择用于执行负载均衡的特定引擎。

最后，控制器410可以控制负载均衡器400的整体操作。例如，一旦检测到客户端请求405，控制器410就可以发起负载均衡器400的实例化，并且生成包括由编排器430选择的负载均衡方案和引擎(或模块)的负载均衡实例。此外，在根据情况负载均衡实例需要改变的情况下，控制器410可以改变或者更新负载均衡器400的配置。

当根据控制器410的请求来配置负载均衡器400或负载均衡实例时，负载均衡器400或负载均衡实例可以为网络元件450指配容器组(pod)470以提供对应于分组流的服务(例如，服务X、服务Y等)。例如，可以指配多个用于提供服务的容器组470，并且负载均衡器400或负载均衡实例可以指配这些容器组470，使得网络元件450能够处理分组流。

另一方面，如上所述，负载均衡器400或负载均衡实例可以被实现为对应于网络元件450，并且可以在各种方案中实现负载均衡器400或负载均衡实例的拓扑。例如，如图4所示，负载均衡器400或负载均衡实例可以被实现为位于网络元件400外部的协议终止拓扑，并且如虚线480所示，可以以位于网络元件480内部的基于直通的中间代理拓扑来实现。此外，在Kubernetes环境中，它可以以边车(sidecar)拓扑来实现。

在上述各种拓扑的示例中，负载均衡器400或负载均衡实例可以连接(例如，490)到网络元件450以发送并接收信令，通过该信令能够实现针对分组流的平滑负载均衡。

图5是图示了根据本公开的实施例的示例负载均衡过程的流程图。图5所示的流程图图示了根据上述实施例的负载均衡器或负载均衡实例在时间顺序流上的操作。

同时，图5所示的流程图仅仅是提出的负载均衡过程的示例，并且在其中图示的操作的流程可以按照不同次序执行，而不限于此。换句话说，与图5中描述的实施例不同，它可以被同样实现为使得在负载均衡器或负载均衡实例的组件之间的一些操作被同时地执行，或者使得它们之间的特定操作早于(或者晚于)其他操作被执行。

首先，在操作510中，负载均衡器(或负载均衡实例)可以检测客户端请求。此过程可以被理解为从外部接收对服务的请求。

当检测到请求时，在操作520中，负载均衡器(或负载均衡实例)可以发起其实例化。具体地，上述负载均衡器(或负载均衡实例)的控制器可以确定有必要根据请求执行负载均衡，并且发起(或者启动)用于配置负载均衡实例的操作。

然后，在操作530中，负载均衡器(或负载均衡实例)可以按照根据请求检测到的分组流的协议来创建负载均衡实例。此过程可以被描述为以下过程：由负载均衡器(或负载均衡实例)的控制器向编排器发送请求，并且识别由编排器选择的负载均衡方案和引擎(或模块)以确定执行负载均衡的引擎组。

在操作540中，负载均衡器(或负载均衡实例)可以使用所配置的引擎组中的引擎来执行负载均衡。也就是说，负载均衡器(或负载均衡实例)可以执行选择并分配用于提供服务的容器组使得网络实体能够处理在请求之后实际接收到的分组流的过程。

负载均衡器(或负载均衡实例)可以通过选择并配置容器组使得网络实体能够为连续接收到的分组流提供要动态且高效处理的服务来执行分配网络资源。

另一方面，在操作550中，负载均衡器(或负载均衡实例)可以检测在负载均衡过程期间需要负载均衡实例的改变。例如，当特定容器组被重新启动或者网际协议(IP)信息通过网络资源的横向扩容或横向缩容发生改变时，负载均衡器(或负载均衡实例)可以确定需要负载均衡实例的改变。

在这样的情况下，负载均衡器(或负载均衡实例)的控制器可以改变负载均衡器(或负载均衡实例)的负载均衡方案或者重新配置引擎(或模块)，从而构建针对这种变化进行了优化的负载均衡实例。也就是说，在操作560中，负载均衡器(或负载均衡实例)可以更新负载均衡实例。

然后，当确定不再需要负载均衡时，在操作570中，负载均衡器(或负载均衡实例)可以终止负载均衡实例。例如，当满足预定条件时，诸如当接收到显式终止输入时或者当在某个时间段内未接收到分组流时，负载均衡器(或负载均衡实例)可以终止负载均衡实例。

图6是图示了根据本公开的实施例的负载均衡过程及负载均衡器的结构的图。图6描述了负载均衡实例被配置为根据在上面参考图4和图5描述的实施例对分组流执行负载均衡的过程。

当控制器610接收到客户端的请求并且识别由编排器630从引擎组620中选择的负载均衡方案和引擎(或模块)时，控制器610可以创建包括这样的引擎(例如，引擎D)的负载均衡实例600。

负载均衡实例600可以执行负载均衡，使得接收网络元件650能够高效地处理分组流605；并且可以分配多个容器组，使得网络元件650能够高效地提供分组流605。这样，网络元件650就可以配置多个容器组(例如，容器组z1、容器组z2、容器组z3、容器组z4)以提供服务Z，从而处理分组流605。

图7是图示了根据本公开的实施例的负载均衡过程的流程图。图7中描述了负载均衡器(或负载均衡实例)在接收到各种请求时具体地配置负载均衡实例的示例。

如上所述，负载均衡器(或负载均衡实例)的编排器能够确定负载均衡方案并且管理用于选择引擎的准则、策略和设置。可以从用户或从外部系统将此类准则、策略和设置提供给编排器，并且编排器可以根据这些准则、策略和设置来选择哪个负载均衡方案来处理接收到的请求。

以下，将更详细地描述此类准则、策略和设置的示例。由编排器管理并且用于创建负载均衡实例的准则、策略和设置可以包括以下元素中的至少一者或更多者。

源/目的地对(Source/Destination Pair)：此元素是关于从哪个客户端接收到哪个服务请求的参数，用于配置处理该请求的最佳负载均衡实例及其拓扑。如果需要后端服务不支持的特定协议，或者在请求从不可靠的连接到达时需要立即响应，则基于此参数创建的负载均衡实例可能变成基于终止的负载均衡实例。

是否支持应用协议(Whether Application Protocol Is Supported)：此元素是对应于所接收到的请求是例如HTTP2、gRPC(谷歌远程过程调用)还是SQL(结构化查询语言)的情况的参数。当接收到与此参数匹配的请求时，控制器和编排器可以提供具有服务感知能力的应用协议支持，并且可以推导诸如例如每秒请求数、每队列消息数等的遥测数据，以便适当地管理具有这种支持能力的后端上的负载。根据实施例，可以选择诸如例如envoy或nginix L7代理的引擎作为用于支持这样的应用协议的引擎，并且边车模式可以变成用于负载均衡实例的拓扑的高效拓扑。

延时关键请求(Latency Critical Request)：此元素是指示与正在接收的请求相关联的数据业务(诸如语音处理)的类型对延迟高度重要且敏感的参数。控制器和编排器可以被配置有负载均衡实例，该负载均衡实例包括能够支持硬件加速以便使处理延迟最小化的引擎或模块(例如，dpdk、P4可编程模块)。

是否支持内核栈(Whether Kernel Stack Is Supported)：此元素是对应于要通过稳定地处理诸如Linux内核中支持的SCTP等的一些协议来提供连接的情况的参数。当接收到与此参数匹配的请求时，控制器和编排器可以选择ipvsadm引擎(或模块)作为示例，并且根据实施例的负载均衡实例可以以基于直通的拓扑被配置并且通过执行连接跟踪和网络地址转换(NAT)来减少开销。

上述元素和参数仅仅是用于配置负载均衡实例的准则、策略和设置的各种示例，并且可以以各种方式考虑其他元素和参数，而不限于此。例如，控制器和编排器可以考虑诸如例如以下中的一个或更多个元素和/或参数来配置负载均衡实例及其拓扑：所需性能、与请求相关的协议类型、要求、数据分组的类型(语音、数据等)或数据分组的层级(tier)或重要性。

例如，如图7所示，负载均衡器720可以接收各种请求710，对请求进行分类，配置负载均衡实例，并且执行负载均衡处理。

例如，当根据请求的数据分组是SCTP相关业务时，将配置包括用于处理SCTP相关业务并且能够进行L4处理的引擎的负载均衡实例。作为另一示例，当根据请求的数据分组与SCTP协议不相关并且延时重要性也低时，将配置包括用于处理HTTP相关业务并且能够进行L7处理的引擎的负载均衡实例。作为另一示例，当根据请求的数据分组与SCTP协议不相关但是具有高延时重要性时，那么将配置包括能够作为硬件加速器运行的引擎的负载均衡实例。

如上所述，为了执行针对各种类型的请求进行了优化的负载均衡，负载均衡器(或负载均衡实例)可以对请求进行分类并且配置对应于其的高效负载均衡实例。

图8是图示了根据本公开的实施例的核心网络结构和网络实体的图。

参考图8，除了图1的核心网络结构之外，还图示了根据上述实施例与每个网络实体相对应地配置负载均衡器(或负载均衡实例)的情形。图8所示的每个负载均衡器LB均指示上述负载均衡实例。

此外，图8中图示了为每个网络实体的每个接口配置负载均衡器(或负载均衡实例)的情形。然而，如上所述，能够根据来自客户端的请求创建负载均衡器(或负载均衡实例)，因此，在特定时间点可以不为网络实体配置负载均衡器(或负载均衡实例)。此外，在一个时间点，可以配置一个负载均衡器(或负载均衡实例)，而在另一时间点，可以配置多个负载均衡器(或负载均衡实例)。

此外，尽管在图8中图示了为特定网络实体配置多个负载均衡器(或负载均衡实例)，但是它仅是为了帮助容易地理解一个网络实体经由接口连接到其他网络实体的情形而图示的示例。因此，尽管在图8中图示了特定网络实体被配置有若干LB，但是对应的LB也可以暗示单个负载均衡器(或负载均衡实例)。

这样的负载均衡器(或负载均衡实例)可以被配置为考虑每个网络实体或接口的特殊性。也就是说，可以考虑其对应的网络实体或接口来定制负载均衡器(或负载均衡实例)。

例如，在用户平面功能(UPF)的情况下，存在与其他网络实体相比处理大量分组的特性。因此，与其他网络实体相比，可以为UPF配置更大数量的负载均衡器(或负载均衡实例)。

又如，由于AMF与RAN之间的N2接口(或下一代应用协议(NGAP))使用SCTP协议来通信，所以可以基于包括ipvsadm引擎的Linux内核来配置用于处理AMF与RAN之间的分组流的负载均衡器(或负载均衡实例)。此外，在这样的N4接口的情况下，它具有这样的特征，即，接收到的数据分组在通过负载均衡器(或负载均衡实例)的过程中不应当执行源NAT(SNAT)。因此，可以配置按适于反映这样的特征的负载均衡方案及其拓扑所定制的负载均衡器(或负载均衡实例)，并且作为这种定制的示例，可以执行将容器组的默认路由设置为负载均衡实例的额外操作，以在容器组被创建时将这些容器组的默认路由设置为负载均衡实例。

又如，SMF与UPF之间的N4接口使用GTP-C(通用分组无线服务隧传协议控制)协议来通信，所以将可以配置包括envoy或nginix引擎(或模块)的负载均衡实例。此外，即使对于经由N4接口从UPF接收分组的负载均衡器(或负载均衡实例)，也不应当执行数据分组的SNAT，类似于N2接口，因此将可能通过反映上述定制来配置并操作负载均衡器(或负载均衡实例)。

又如，RAN与UPF之间的N3接口和UPF与DN之间的N6接口使用GTP-U(GTP用户)协议来通信，其中通过带宽发送和接收大量分组，从而导致大量分组处理负担。因此，负载均衡器(或负载均衡实例)可以被配置为包括硬件加速器，并且它可以被配置为包括例如具有智能NIC(网络接口卡)、FPGA NIC、NIC加速等的图形处理单元(GPU)。

又如，基于服务的接口(SBI)，即诸如例如Nnssf、Namf、Nausf、Nsmf、Nudm、Npcf、Nnef、Naf、Nnrf等接口使用HTTP2.0协议或按基于gRPC的请求通信，所以负载均衡实例可以被配置为通过envoy引擎(或模块)提供基于L7的负载均衡或者提供另一LBaaS(负载均衡即服务)解决方案。

根据按照上面参考图1至图8描述的各种实施例的负载均衡方案和负载均衡器(或负载均衡实例)，能够提供针对分组流和据此的数据分组进行了优化的服务。特别地，能够根据基于包括客户端的请求的特性的各种参数对请求进行分类的结果来配置负载均衡实例，从而不仅满足请求和性能的要求，而且还能够实现网络资源的高效使用。

另外，可以配置针对准则、策略和设置所优化的引擎、负载均衡方案及其拓扑，使得即使在用于依次布置多个负载均衡器的资源不充足的情形下，也能够仅用一个负载均衡器(或负载均衡实例)执行高效负载均衡。

此外，根据按照本文公开的实施例的负载均衡器和负载均衡方法，不需要用于元数据或服务路径的单独的网络服务报头(NSH)，所以不需要具有网络实体的服务报头处理模块。因此，这种负载均衡器及其负载均衡方法具有这样的优点，即，它们能够在不受网络环境或架构约束的情况下被最优地应用于任何网络实体。

此外，由于这种负载均衡器被定位为完全地跨网络分布，所以不会发生根据对请求进行分类的结果不可避免地选择特定网络实体的情形。此外，它能够被应用于没有服务功能链(SFC)和用例的特定组合的一般用例。

至此参考本公开和附图而披露的这些实施例仅作为特定示例被提供以容易地描述本公开的内容并且帮助理解本公开的内容，而不旨在将本公开的范围限于此。因此，本公开的范围应当被解释为除了本文公开的实施例之外还包括基于本公开推导的所有变化或修改。

此外，不言而喻，可以彼此结合地执行本文公开的一个或更多个实施例，并且可以与其他实施例中的一些或全部实施例相结合地执行某些实施例中的一些或全部实施例。

Claims (15)

1.一种由通信系统的负载均衡器执行的负载均衡的方法，所述方法包括：

接收与网络实体相关的服务请求；

基于与所述服务请求相关的策略来选择执行负载均衡的引擎；

创建包括所选择的引擎的负载均衡实例；以及

经由所述负载均衡实例对与所述服务请求相关的数据分组执行负载均衡。

2.根据权利要求1所述的方法，所述方法还包括根据所述策略对所述服务请求进行分类，

其中，所选择的引擎是根据所述分类的结果从包括多个引擎的引擎组中选择的。

3.根据权利要求2所述的方法，其中，所述引擎组包括以下一者或更多者：envoy引擎、ipvsadm引擎、ngnix引擎、智能网络接口卡(NIC)或现场可编程门阵列(FPGA)NIC。

4.根据权利要求1所述的方法，

其中，所述策略包括与所述服务请求有关的源、目的地、协议类型、延时重要性、请求的性能、要求、数据分组的类型、数据分组的层级、数据分组的重要性、或者所述网络实体或网络接口的特性中的至少一者，

其中，所述负载均衡器被配置为支持多个不同的协议，并且

其中，所述多个不同的协议包括以下两者或更多者：L4协议、L7协议、流控制传输协议(SCTP)、超文本传送协议版本2(HTTP2.0)、通用分组无线服务隧传协议控制(GTP-C)和GTP用户(GTP-U)、谷歌远程过程调用(gRPC)或结构化查询语言(SQL)。

5.根据权利要求1所述的方法，所述方法还包括基于所述策略来选择所述负载均衡实例的拓扑，

其中，所述负载均衡实例是根据所述拓扑来创建的，并且

其中，所述拓扑包括中间、边缘、直通、边车或协议终止中的任何一者。

6.根据权利要求1所述的方法，其中，所选择的引擎由包括两个或更多个引擎的引擎链配置而成，并且

其中，所述引擎链的负载均衡路径是根据所述两个或更多个引擎的优先级确定的。

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

确定所述负载均衡实例需要改变；以及

根据所述确定的结果更新所述负载均衡实例，

其中，当由所述负载均衡实例分配的容器组被重新启动、网络资源的横向扩容或横向缩容被检测到、或者所述网络资源的网际协议(IP)信息发生改变时，确定所述负载均衡实例需要改变。

8.一种用于在通信系统中执行负载均衡的负载均衡器，所述负载均衡器包括：

至少一个引擎；

编排器，所述编排器用于根据预设策略来选择所述至少一个引擎；以及

控制器，所述控制器电连接到所述至少一个引擎和所述编排器以控制所述负载均衡器，其中，所述控制器被配置为：

接收与网络实体相关的服务请求；

基于与所述服务请求相关的策略，选择执行负载均衡的引擎；

创建包括所选择的引擎的负载均衡实例；以及

经由所述负载均衡实例对与所述服务请求相关的数据分组执行负载均衡。

9.根据权利要求8所述的负载均衡器，其中，所述编排器根据所述策略对所述服务请求进行分类，并且

其中，所选择的引擎是根据所述分类的结果从包括多个引擎的引擎组中选择的。

10.根据权利要求9所述的负载均衡器，其中，所述引擎组包括以下一者或更多者：envoy引擎、ipvsadm引擎、ngnix引擎、智能网络接口卡(NIC)或现场可编程门阵列(FPGA)NI。

11.根据权利要求8所述的负载均衡器，

其中，所述策略包括与所述服务请求有关的源、目的地、协议类型、延时重要性、请求的性能、要求、数据分组的类型、数据分组的层级、数据分组的重要性、或者所述网络实体或网络接口的特性中的至少一者，

其中，所述负载均衡器被配置为支持多个不同的协议，并且

其中，所述多个不同的协议包括以下两者或更多者：L4协议、L7协议、流控制传输协议(SCTP)、超文本传送协议版本2(HTTP2.0)、通用分组无线服务隧传协议控制(GTP-C)和GTP用户(GTP-U)、谷歌远程过程调用(gRPC)或结构化查询语言(SQL)。

12.根据权利要求8所述的负载均衡器，其中，所述编排器基于所述策略来选择所述负载均衡实例的拓扑，

其中，所述负载均衡实例是根据所述拓扑来创建的，并且

其中，所述拓扑包括中间、边缘、直通、边车或协议终止中的任何一者。

13.根据权利要求8所述的负载均衡器，其中，所选择的引擎由包括两个或更多个引擎的引擎链配置而成，并且

其中，所述引擎链的负载均衡路径是根据所述两个或更多个引擎的优先级确定的。

14.根据权利要求8所述的负载均衡器，其中，所述控制器确定所述负载均衡实例需要改变，并且根据所述确定的结果更新所述负载均衡实例。

15.根据权利要求14所述的负载均衡器，其中，当由所述负载均衡实例分配的容器组被重新启动、网络资源的横向扩容或横向缩容被检测到、或者所述网络资源的网际协议(IP)信息发生改变时，确定所述负载均衡实例需要改变。

Images