Method and apparatus for dynamic and efficient load balancing in mobile communication networks

Abstract

The present disclosure relates to a communication technology and system for integrating a 5G communication system, designed to support higher data rates after 4G systems, with IoT technology. The present disclosure can be applied to smart services based on 5G communication technology and IoT-related technologies (e.g., smart homes, smart buildings, smart cities, smart cars or connected cars, healthcare, digital education, retail commerce, security and safety-related services, or similar services). The present disclosure also discloses a dynamic and efficient load balancing method and device.

Description

Technical Field

[0001] The present disclosure relates to a mobile communication system, and more particularly to a method and apparatus for load balancing in such a mobile communication system. More particularly, the present disclosure relates to a method and apparatus for dynamic and efficient load balancing in a mobile communication network. Background Art

[0002] To meet the increasing demand for wireless data services since the deployment of 4G communication systems, efforts have been made to develop improved 5G or quasi-5G communication systems. Therefore, 5G or quasi-5G communication systems are also referred to as "beyond 4G networks" or "post-LTE systems."

[0003] 5G communication systems are being considered for implementation in higher frequency (mmWave) bands (e.g., the 60 GHz band) to achieve higher data rates. To reduce radio wave propagation losses and increase transmission distances, beamforming, massive multiple-input multiple-output (MIMO), full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and massive antenna technologies are being discussed in 5G communication systems.

[0004] In addition, in 5G communication systems, development of system network improvements is being carried out based on advanced small cells, cloud radio access networks (RAN), ultra-dense networks, device-to-device (D2D) communication, wireless backhaul, mobile networks, collaborative communications, coordinated multipoint (CoMP), and receiver-side interference cancellation.

[0005] In 5G systems, hybrid FSK with QAM modulation (FQAM) and sliding window superposition coding (SWSC) have been developed as advanced coding modulation (ACM), and filter bank multi-carrier (FBMC), non-orthogonal multiple access (NOMA) and sparse code multiple access (SCMA) as advanced access technologies.

[0006] At the same time, the Internet is evolving from a human-based connected network where information is created and consumed by people to an Internet of Things (IoT) network where information is exchanged and processed between distributed components such as objects. Furthermore, the Internet of Everything (IoE) is also emerging, in which big data processing technologies are linked to IoT technologies through connections to cloud servers and other platforms. Implementing the IoT requires various technical elements, such as sensing technology, wired and wireless communications, and networking infrastructure, as well as service interface technologies and security technologies. Consequently, research is currently underway on technologies such as sensor networks, machine-to-machine (M2M) communications, and machine-type communications (MTC). Within the IoT environment, intelligent IT (Internet of Things) services can be provided that collect and analyze data generated by connected objects to create new value in human life. The IoT can be applied to various technological fields, such as smart homes, smart buildings, smart cities, smart cars (connected cars), smart grids, healthcare, smart appliances, and advanced medical services, by integrating existing information technology (IT) with various industries.

[0007] Therefore, various attempts have been made to apply 5G communication systems to IoT networks. For example, 5G communication technologies such as beamforming, MIMO, and array antennas are being used to implement technologies such as sensor networks, machine-to-machine (M2M) communication, and machine-type communication (MTC). The application of cloud radio access networks (cloud RAN) along with big data processing technologies described above can be an example of this fusion of 5G technology and IoT technology.

[0008] On the other hand, the core network has been improved to support such a 5G communication system, and the core network supporting the 5G communication system can be referred to as a 5G core (5GC). In this case, it is necessary to improve load balancing for regulating the load of various network entities constituting such an improved core network. Summary of the Invention

[0009] Technical issues

[0010] Aspects of the present disclosure are to address at least the above-mentioned problems and / or disadvantages and provide a method of efficiently performing load balancing even in a situation where network resources are not sufficiently guaranteed.

[0011] Furthermore, by proposing a load balancing solution for efficiently processing various requests, the present disclosure provides a method for dynamically performing load balancing optimized for data services.

[0012] Technical Solution

[0013] According to an embodiment of the present disclosure in order to solve the above-mentioned technical problems, a load balancing method is provided, which includes: receiving a service request related to a network entity; selecting an engine for performing load balancing based on a policy related to the service request; creating a load balancing instance including the selected engine; and performing the load balancing for data packets related to the service request through the load balancing instance.

[0014] According to an embodiment of the present disclosure to solve the above-mentioned technical problems, a load balancer is provided, comprising: at least one engine; an orchestrator, the orchestrator being configured to select the at least one engine according to a preset policy; and a controller, the controller being connected to the at least one engine and the orchestrator to control the load balancer, wherein the controller receives a service request related to a network entity, the orchestrator selects an engine to perform load balancing based on a policy related to the service request, the controller creates a load balancing instance including the selected engine, and the selected engine performs load balancing on data packets related to the service request through the load balancing instance.

[0015] Beneficial effects

[0016] According to the embodiments of the present disclosure, requests can be classified and load balancing can be performed accordingly, thereby providing optimized services based on the requests. In addition, the load balancer (or load balancing instance) can present optimized results based on the requests, thereby efficiently saving network resources used for load balancing. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 is a diagram illustrating a core network structure and network entities thereof related to an embodiment of the present disclosure.

[0018] Figure 2 is a schematic diagram illustrating a load balancing process of a network element related to an embodiment of the present disclosure.

[0019] Figure 3 is a schematic diagram illustrating a load balancing process according to an embodiment of the present disclosure.

[0020] Figure 4 is a diagram illustrating a load balancing process and a structure of a load balancer according to an embodiment of the present disclosure.

[0021] Figure 5 is a flow chart illustrating a load balancing process according to an embodiment of the present disclosure.

[0022] Figure 6is a diagram illustrating a load balancing process and a structure of a load balancer according to an embodiment of the present disclosure.

[0023] Figure 7 is a flow chart illustrating a load balancing process according to an embodiment of the present disclosure.

[0024] Figure 8 is a diagram illustrating a core network structure and network entities according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0025] Hereinafter, preferred embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. It should be noted that throughout the drawings, identical or similar components are denoted by identical or similar reference numerals, where possible. Furthermore, detailed descriptions of known functions and configurations that may obscure the key points of the present disclosure may be omitted.

[0026] When describing various embodiments in this disclosure, it should be noted that any description of technical content that is well known in the art to which this disclosure belongs and is not directly related to this disclosure may be omitted. This is to more clearly reveal the subject matter of this disclosure by omitting such unnecessary descriptions, without obscuring the subject matter of this disclosure.

[0027] For the same reason, some components may be enlarged, omitted or schematically illustrated in the accompanying drawings. In addition, the size of each component in each figure may not fully reflect its actual size. In each figure, the same or corresponding elements are assigned the same or similar reference numerals.

[0028] The advantages and features of the present disclosure, as well as methods for achieving these advantages and features, will become apparent by reference to the embodiments described in detail below in conjunction with the accompanying drawings. However, the present disclosure is not limited to the embodiments disclosed below and may be implemented in a variety of different forms. These embodiments are presented solely to make the disclosure more complete and to fully inform those skilled in the art. The scope of the present disclosure is therefore limited solely by the scope of the claims. Like reference numerals refer to like elements throughout this disclosure.

[0029] At this point, it should be understood that each block of any flowchart and the combination of flowcharts can be executed by computer program instructions. These computer program instructions can be installed in a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, so that the instructions executed by the processor of the computer or other programmable data processing device create a device for performing the functions described in the flowchart blocks. These computer program instructions can also be stored in a computer-usable or computer-readable memory, and these computer program instructions can guide the computer or other programmable data processing device to implement the functions in a certain manner and thus in the computer-usable or computer-readable memory. Therefore, an article of manufacture containing instruction means for causing the instructions stored in the computer-usable or computer-readable memory to perform the functions described in the flowchart blocks can also be produced. The computer program instructions can also be installed on a computer or other programmable data processing device, so the instructions can also provide the operational steps for performing the functions described in the flowchart blocks by causing the computer or other programmable data processing device to perform a series of operational steps to create a computer-executed process.

[0030] In addition, each block may represent a module, segment or portion of code comprising one or more executable instructions for performing a specified logical function. In addition, it should be noted that in some alternative implementations, the functions mentioned in each block may also occur out of order. For example, two consecutive blocks arranged one after another may be executed substantially simultaneously, or sometimes the blocks may be executed in reverse order according to the corresponding functions.

[0031] As used in various embodiments of the present disclosure, the term "~ unit (or module)" may include a unit implemented in a software or hardware component such as an FPGA or ASIC to perform a certain function or functionality. However, the term "~ unit (or module)" is not limited to software or hardware. Such a unit or module can be configured to reside on an addressable storage medium or can be configured to regenerate one or more processors. Thus, for example, the term "~ unit (or module)" may include various components such as: software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, program code segments, drivers, firmware, microcode, circuit systems, data, databases, data structures, tables, arrays, variables, etc. The functions provided in the components and units (or modules) can be combined into a smaller number of components and units (or modules), or further divided into additional components and units (or modules). In addition, the components and units (or modules) can be implemented to regenerate one or more CPUs in a device or secure multimedia card.

[0032] Meanwhile, hereinafter, a terminal (or user equipment (UE)) may include both mobile terminals and fixed terminals, the mobile terminal being, for example, a mobile phone, a smartphone, or a laptop of a mobile user provided with a mobile communication service. A base station (BS) may include an evolved Node B (eNB), a next generation Node B (gNB), a transmission point (TP), a transmission and reception point (TRP), a radio access network (RAN) node, etc. as an entity providing communication services to a user terminal through a wireless channel.

[0033] Hereinafter, when describing the embodiments of the present disclosure in detail, the packet core (or, 5G system, 5G core network or NG core (next generation core)) is mainly described. The packet core is a core network based on the mobile communication standard specified by the mobile communication specification standardization organizations including 3GPP (3rd Generation Partnership Project) and ESTI (European Telecommunications Standards Institute). However, without significantly departing from the scope of the present disclosure, the subject matter of the present disclosure can also be applied to other communication systems with the same or similar technical background with slight changes. Such application will be possible under the determination of experts in the technical field of the present disclosure.

[0034] For the convenience of description, some terms and names defined in the 3GPP standard specifications and ETSI standard specifications may be used below. However, the present disclosure is not limited by these terms and names and can be equally applied to communication systems that comply with other technical standards.

[0035] In addition, as used in the disclosure set forth below, terms referring to objects of the core network, terms referring to messages in the core network, terms referring to interfaces between network entities, and terms referring to various identification information are all exemplified for the convenience of description. Therefore, these terms are not limited to those used in this disclosure, and other terms referring to objects with equivalent or similar technical meanings may be used. For example, the term "network entity" may have the same technical meaning as various terms such as network element, network function, network instance, network node, etc.

[0036] Figure 1 is a diagram illustrating a core network structure and network entities related to an embodiment of the present disclosure.

[0037] The unit that performs each function provided by the 5G mobile communication system can be defined as a network entity, a network element (NE), or a network function (NF). Figure 1 The core network structure of the 5G mobile communication system and the network entities that constitute the core network structure are shown in FIG.

[0038] Representative network entities may include, for example: an access and mobility management function (AMF) that manages network access and mobility of terminals, a session management function (SMF) that performs session-related functions, a user plane function (UPF) responsible for transmitting user plane data, an application function (AF) that assists in controlling the user plane routing state in consideration of service requirements, a network exposure function (NEF) that performs the function of exposing the functions of core network entities to the outside, a unified data management (UDM) and a unified data repository (UDR) that are responsible for data storage and management, a policy and control function (PCF) that is responsible for managing charging and policies, a network slice selection function (NSSF) that uses network slice selection assistance information (NSSAI) to select a specific network slice for a request for a packet data network (PDN) session from a terminal, an authentication server function (AUSF) that provides unified authentication of subscribers for various types of services, a network repository function (NRF) that monitors the service status of core network NFs and supports interworking between NFs, and a data network (DN) that is a service network for providing services of either an operator or a third party to the terminal.

[0039] Figure 1 The network entities shown may be connected to each other via interfaces defined between each other. For example, the interface between AMF and SMF may be defined as N11, the interface between SMF and UPF may be defined as N4, the interface between UPF and DN may be defined as N6, the interface between AMF and RAN may be defined as N2, and the interface between RAN and UPF may be defined as N3.

[0040] In addition, service-based interfaces (SBIs) are defined for specific network entities. For example, the interface of NSSF can be defined as Nnssf, the interface of AMF can be defined as Namf, the interface of SMF can be defined as Nsmf, the interface of PCF can be defined as Npcf, and so on.

[0041] Figure 1 The core network structure described in the foregoing is merely an example, and the core network may include a greater number of other network entities for providing mobile communication services. In addition, the names of the network entities and interfaces described above are merely examples, and the names and functions of the network entities and the names of the interfaces may be referred to differently according to personal preference. In other words, the contents of the present disclosure to be described below should not be interpreted as being limited to Figure 1 Definitions and descriptions of the network entities and interfaces shown.

[0042] Meanwhile, various research and developments have recently been conducted on software-defined networking (SDN) and network function virtualization (NFV). Therefore, SDN and NFV will be described.

[0043] The term "SDN" refers to the concept of separating the control portion of a network entity from the transmit / receive portion. In other words, it can mean that a network entity is solely responsible for transmit / receive functions, with the control function being transferred to a separate, general-purpose server. This separation allows the single control server to efficiently control multiple network devices.

[0044] The term "NFV" alone can refer to virtualizing network entities. Specifically, NFV can refer to logically dividing the resources of a physical network entity so that it can be shared and used with multiple users or devices. Therefore, by allowing the resources of a network entity to be shared by multiple virtual machines (VMs) through NFV, resource utilization efficiency can be improved, network construction costs can be reduced through software / hardware separation, and more flexible installation is possible compared to physical network entities.

[0045] By virtualizing physical network resources as described above, even if the physical network configuration changes, the virtual network configuration can remain the same so as not to affect the VM virtualized network function (VNF). In this context, the physical network can be referred to as the underlay network, and the virtual network can be referred to as the overlay network.

[0046] In addition to the aforementioned, recent research and development is focused on cloudification of telco (telecommunication company) networks. Cloud computing offers the advantage of enabling the use of containers, which are more flexible than virtual machines or NFV. Consequently, research and development is underway to build telco cloud networks by containerizing telco-specific VNFs, aiming to achieve flexible operation and scalability of network entities.

[0047] Such a telco cloud network may refer to a cloud-based implementation of technologies, products, solutions, etc. provided by a conventional business platform. In a telco cloud network, the main indicators used to determine its performance reliability may include, for example, availability, quality of service (QoS), service continuity, etc.

[0048] Figure 2 is a schematic diagram illustrating an example load balancing process for network elements related to embodiments of the present disclosure.

[0049] The network element used in the following description may have the same meaning as the network entity, network function, network instance and network node as defined above.

[0050] The network elements that make up the core network can communicate with other network elements via predetermined interfaces to send and receive packets. In this process, to efficiently process packets or requests received by the network elements, it is generally necessary to consider the load status. This approach of considering the load status between network elements (or network entities) and sharing or distributing the load for processing packets or requests according to predetermined criteria is referred to as load balancing.

[0051] Conventional load balancing, on the other hand, is performed by separate servers deployed outside of network elements. This load balancing approach does not fully meet the requirements of the aforementioned containerized core network. For example, conventional load balancing may be a suitable solution for cloud networks or web-scale use cases that utilize L4 or L7 protocols. Therefore, with conventional load balancing approaches, when handling two protocols, the load balancer must be implemented in a cascaded connection, with a load balancer for each protocol connected sequentially.

[0052] However, this type of conventional load balancing approach makes it impossible to meet the requirements of telco cloud networks due to the following reasons.

[0053] First, a single load balancer needs to support processing of various protocols, such as Stream Control Transmission Protocol (SCTP), Hypertext Transfer Protocol version 2 (HTTP 2.0), etc. In particular, in edge or far-edge scenarios where network resources are insufficient to implement a multi-level load balancer to support multiple protocols or layers, a new load balancing solution that differs from conventional load balancing methods is needed.

[0054] Secondly, the ability to dynamically adjust the load balancing topology is required. In other words, in order to dynamically control or change various topologies such as intermediate, edge, and pass-through load balancing on the network, a new load balancing method different from the conventional load balancing method is needed.

[0055] Third, there is a need for load balancing that is optimized for classification or telco-related attributes. In other words, in order to dynamically reflect such classification and attributes, a new load balancing solution that utilizes kernel-based routing or hardware offload is needed, contrary to existing technologies.

[0056] Finally, when configuring a load balancing chain to process packets received in response to a request, it is necessary to configure differentiated and prioritized load balancing paths. In other words, a new load balancing solution is needed to efficiently configure load balancing chains based on the priority of the received packet, such as its source, destination, and whether it is voice or data.

[0057] Figure 3 is a schematic diagram illustrating an example load balancing process according to an embodiment of the present disclosure.

[0058] In the following embodiments, a load balancing method for intelligently and dynamically processing requests delivered to a network entity of a core network and a load balancer used for the load balancing method are proposed.

[0059] The load balancing method and load balancer according to the embodiments of the present disclosure can provide a solution that can support data packet classification and enhanced platform awareness (EPA) for packet flows received according to client requests, as well as provide improved performance with low latency, low footprint, resource optimization, etc.

[0060] Can be based on Figure 3 The load balancing method and the relationship between the load balancer and the network element are defined by the relationship shown. The load balancer 300 according to the proposed embodiment can be implemented to correspond to a specific network element 310, and perform load balancing to detect a request sent from a client to the network element 310 and process the request.

[0061] More specifically, the load balancer 300 according to the embodiment may receive requests from clients for various services (e.g., Figure 3 and performs load balancing on the request, so that the network element 310 can efficiently utilize network resources to process the request.

[0062] In particular, as described above, since requests based on protocols and packet characteristics at different layers may be received from different clients, load balancer 300 has to intelligently perform load balancing to allow network element 310 to efficiently process these requests. To this end, load balancer 300 has to classify the client's requests so that network element 310 can provide optimized services.

[0063] In addition, the load balancer 300 can be implemented to correspond to the network element 310. That is, according to the reference Figure 2 The conventional load balancing method described above has a separate server for handling load balancing of a specific network element, but the load balancer 300 according to the embodiment as proposed may be implemented to correspond to (or depend on) the network element 310 .

[0064] Therefore, it can be understood from this relationship that network element 310 can have its own load balancer 300 internally or externally, and network element 310 can include one or more load balancers 300 corresponding to itself. For example, when the number of requests received from clients is relatively large, network element 310 may include multiple load balancers 300 for processing these requests.

[0065] Figure 4 is a diagram illustrating an example load balancing process and a structure of a load balancer according to an embodiment of the present disclosure.

[0066] According to an embodiment, the load balancer 400 for (or corresponding to) the network element 450 may include Figure 4 For example, the load balancer 400 according to the embodiment may include a controller 410, an engine group 420, and an orchestrator 430, and experts in the art will easily appreciate that the illustrated structures and configurations are merely examples.

[0067] Figure 4 Each component of the load balancer 400 shown may be a logical configuration implemented in software, or may be implemented, for example, using a service, container, or other conceptual configuration. Alternatively, some or all components may be implemented as hardware. Figure 4 Each component shown.

[0068] First, the engine group 420 may include one or more engines ( Figure 4 In the example, engine A, engine B, engine C, etc. in the engine group 420 may be included, and one or more engines (or modules) included in the engine group 420 may perform actual load balancing for the packet flows. To this end, the engine group 420 may perform backend lists, current status, connection tracking, and selection of specific backends for one or more engines (or modules).

[0069] In particular, each engine included in the engine group 420 can perform load balancing for a specific protocol. For example, the engine group 420 may include an ipvsadm engine (or module) that performs load balancing of packet streams for the SCTP protocol, and may include an envoy engine (or module) or an ngnix engine (or module) that performs load balancing of packet streams for the HTTP2.0 protocol. In addition, the engine group 420 may include an intelligent network interface card (NIC) or a field programmable gate array (FPGA) as a hardware accelerator for diverting and processing large-capacity packets. In addition, these engines or modules can perform load balancing related to protocols at various layers such as L4 or L7.

[0070] Load balancing of packet flows for a specific protocol can be processed by one engine (module) and multiple different engines (modules) supporting the protocol included in engine group 420. Conversely, it goes without saying that packet flows of multiple different protocols can be processed by one engine (module).

[0071] On the other hand, one or more engines or modules included in the engine group 420 may be implemented using virtual resources such as services or containers, and, contrary to the above, one or more engines or modules may be implemented in hardware included in the engine group. An engine or module implemented in hardware may imply that the load balancer 400 and the corresponding engine or module are physically connected.

[0072] Next, orchestrator 430 is configured to store and manage policies and configurations related to load balancing. In other words, orchestrator 430 may have and maintain information about load balancing solutions and engines (or modules) that load balancer 400 can use, and interact with network element 450 to dynamically determine which load balancing solution to select for client request 405 to service 460 provided by network element 450.

[0073] This determination process can be performed based on policies and criteria input to orchestrator 430. For example, orchestrator 430 can determine a load balancing scheme that satisfies the service level agreement (SLA) and quality of service (QoS) of the packet flow based on the characteristics of the packet flow corresponding to the request or the type of protocol. The process by which orchestrator 430 determines a load balancing scheme can generally be described as determining whether to perform load balancing at the application level (i.e., L7), whether to perform load balancing at the kernel level (i.e., L4), or whether to perform load balancing at the hardware level. Furthermore, in addition to determining such a load balancing scheme, orchestrator 430 can also select a specific engine for performing load balancing.

[0074] Finally, controller 410 can control the overall operation of load balancer 400. For example, upon detecting client request 405, controller 410 can initiate the instantiation of load balancer 400 and generate a load balancing instance that includes the load balancing scheme and engine (or module) selected by orchestrator 430. In addition, if the load balancing instance needs to be changed according to the situation, controller 410 can change or update the configuration of load balancer 400.

[0075] When load balancer 400 or a load balancing instance is configured according to a request from controller 410, load balancer 400 or a load balancing instance may assign a pod 470 to network element 450 to provide a service (e.g., service X, service Y, etc.) corresponding to a packet flow. For example, multiple pods 470 for providing services may be assigned, and load balancer 400 or a load balancing instance may assign these pods 470 so that network element 450 can process the packet flow.

[0076] On the other hand, as described above, the load balancer 400 or the load balancing instance can be implemented to correspond to the network element 450, and the topology of the load balancer 400 or the load balancing instance can be implemented in various schemes. Figure 4 As shown, load balancer 400 or a load balancing instance can be implemented as a protocol termination topology located outside of network element 400, and as shown by dashed line 480, can be implemented in a cut-through based middle proxy topology located inside network element 480. Furthermore, in a Kubernetes environment, it can be implemented in a sidecar topology.

[0077] In the various topology examples described above, load balancer 400 or load balancing instances may be connected (eg, 490 ) to network element 450 to send and receive signaling that enables smooth load balancing for packet flows.

[0078] Figure 5 is a flow chart illustrating an example load balancing process according to an embodiment of the present disclosure. Figure 5 The flowchart shown illustrates the operation of the load balancer or load balancing instance in a time-sequential flow according to the above-described embodiments.

[0079] at the same time, Figure 5 The flowchart shown is merely an example of the proposed load balancing process, and the flow of operations illustrated therein may be performed in a different order without limitation. Figure 5 Unlike the embodiments described in , it can also be implemented so that some operations between components of a load balancer or a load balancing instance are executed simultaneously, or so that specific operations between them are executed earlier (or later) than other operations.

[0080] First, in operation 510, the load balancer (or load balancing instance) may detect a client request. This process may be understood as receiving a request for a service from the outside.

[0081] When a request is detected, the load balancer (or load balancing instance) may initiate its instantiation in operation 520. Specifically, the controller of the load balancer (or load balancing instance) may determine that it is necessary to perform load balancing based on the request and initiate (or start) an operation for configuring the load balancing instance.

[0082] Then, in operation 530, the load balancer (or load balancing instance) may create a load balancing instance according to the protocol of the packet flow detected according to the request. This process can be described as follows: the controller of the load balancer (or load balancing instance) sends a request to the orchestrator, and identifies the load balancing scheme and engine (or module) selected by the orchestrator to determine the engine group to perform load balancing.

[0083] In operation 540, the load balancer (or load balancing instance) may perform load balancing using the engines in the configured engine group. That is, the load balancer (or load balancing instance) may perform a process of selecting and allocating a container group for providing a service so that the network entity can process the packet stream actually received after the request.

[0084] A load balancer (or load balancing instance) may perform allocation of network resources by selecting and configuring container groups so that network entities can provide services for continuously received packet flows to be processed dynamically and efficiently.

[0085] On the other hand, the load balancer (or load balancing instance) may detect that a change in the load balancing instance is required during the load balancing process in operation 550. For example, when a particular container group is restarted or Internet Protocol (IP) information changes due to scale-out or scale-out of network resources, the load balancer (or load balancing instance) may determine that a change in the load balancing instance is required.

[0086] In such a case, the controller of the load balancer (or load balancing instance) can change the load balancing scheme of the load balancer (or load balancing instance) or reconfigure the engine (or module) to build a load balancing instance optimized for such changes. In other words, in operation 560, the load balancer (or load balancing instance) can update the load balancing instance.

[0087] Then, when it is determined that load balancing is no longer needed, the load balancer (or load balancing instance) may terminate the load balancing instance in operation 570. For example, the load balancer (or load balancing instance) may terminate the load balancing instance when a predetermined condition is met, such as when an explicit termination input is received or when no packet flow is received within a certain time period.

[0088] Figure 6 is a diagram illustrating a load balancing process and a structure of a load balancer according to an embodiment of the present disclosure. Figure 6 Describes how the load balancing instance is configured according to the above reference Figure 4 and Figure 5 The described embodiments perform a process of load balancing packet flows.

[0089] When controller 610 receives a client's request and identifies a load balancing scheme and an engine (or module) selected by orchestrator 630 from engine group 620 , controller 610 may create a load balancing instance 600 including such an engine (eg, engine D).

[0090] Load balancing instance 600 can perform load balancing so that receiving network element 650 can efficiently process packet flow 605, and can allocate multiple container groups so that network element 650 can efficiently provide packet flow 605. In this way, network element 650 can configure multiple container groups (e.g., container group z1, container group z2, container group z3, and container group z4) to provide service Z and thereby process packet flow 605.

[0091] Figure 7 is a flow chart illustrating a load balancing process according to an embodiment of the present disclosure. Figure 7 An example of how a load balancer (or load balancing instance) specifically configures a load balancing instance when receiving various requests is described in

[0065] .

[0092] As described above, the orchestrator of a load balancer (or load balancing instance) can determine the load balancing scheme and manage the criteria, policies, and settings used to select an engine. Such criteria, policies, and settings can be provided to the orchestrator from a user or from an external system, and the orchestrator can select which load balancing scheme to handle a received request based on these criteria, policies, and settings.

[0093] Examples of such criteria, policies, and settings are described in more detail below. The criteria, policies, and settings managed by the orchestrator and used to create a load balancing instance may include at least one or more of the following elements.

[0094] Source / Destination Pair: This element specifies the parameters for which service request was received from which client and is used to configure the optimal load balancing instance and its topology to handle the request. Load balancing instances created based on this parameter may become termination-based if a specific protocol is required that the backend service doesn't support, or if an immediate response is required when a request arrives over an unreliable connection.

[0095] Whether Application Protocol Is Supported: This element is a parameter corresponding to whether the received request is, for example, HTTP2, gRPC (Google Remote Procedure Call), or SQL (Structured Query Language). When a request matching this parameter is received, the controller and orchestrator can provide application protocol support with service awareness capabilities, and can derive telemetry data such as, for example, the number of requests per second, the number of messages per queue, etc., in order to appropriately manage the load on the backend with such support capabilities. According to an embodiment, an engine such as, for example, envoy or nginix L7 proxy can be selected as the engine for supporting such application protocols, and the sidecar pattern can become an efficient topology for the topology of load balancing instances.

[0096] Latency Critical Request: This element is a parameter that indicates that the type of data traffic associated with the request being received (such as voice processing) is highly latency-critical and sensitive. Controllers and orchestrators can be configured with a load balancing instance that includes an engine or module (e.g., DPDK, P4 programmable module) that can support hardware acceleration to minimize processing latency.

[0097] Whether Kernel Stack Is Supported: This parameter corresponds to providing a connection by stably processing some protocols, such as SCTP supported in the Linux kernel. When a request matching this parameter is received, the controller and orchestrator may select the ipvsadm engine (or module) as an example, and the load balancing instance according to an embodiment may be configured in a cut-through topology and reduce overhead by performing connection tracking and network address translation (NAT).

[0098] The above elements and parameters are merely examples of various criteria, policies, and settings for configuring a load balancing instance, and other elements and parameters may be considered in various ways, without limitation. For example, the controller and orchestrator may consider one or more of the following elements and / or parameters to configure the load balancing instance and its topology: required performance, protocol type associated with the request, requirements, type of data packet (voice, data, etc.), or tier or importance of the data packet.

[0099] For example, Figure 7 As shown, the load balancer 720 can receive various requests 710, classify the requests, configure load balancing instances, and perform load balancing processing.

[0100] For example, when the requested data packets are SCTP-related traffic, a load balancing instance including an engine capable of L4 processing and used to process SCTP-related traffic will be configured. As another example, when the requested data packets are not SCTP-related and latency is of low importance, a load balancing instance including an engine capable of L7 processing and used to process HTTP-related traffic will be configured. As another example, when the requested data packets are not SCTP-related but latency is of high importance, a load balancing instance including an engine capable of operating as a hardware accelerator will be configured.

[0101] As described above, in order to perform load balancing optimized for various types of requests, a load balancer (or load balancing instance) may classify requests and configure efficient load balancing instances corresponding thereto.

[0102] Figure 8 is a diagram illustrating a core network structure and network entities according to an embodiment of the present disclosure.

[0103] refer to Figure 8 ,Apart from Figure 1 In addition to the core network structure, the diagram also illustrates a situation where a load balancer (or load balancing instance) is configured corresponding to each network entity according to the above embodiment. Figure 8 Each load balancer LB shown indicates the above-mentioned load balancing instance.

[0104] also, Figure 8 The diagram illustrates a scenario where a load balancer (or load balancing instance) is configured for each interface of each network entity. However, as described above, a load balancer (or load balancing instance) can be created based on a request from a client. Therefore, a load balancer (or load balancing instance) may not be configured for a network entity at a particular point in time. Furthermore, at one point in time, one load balancer (or load balancing instance) may be configured, while at another point in time, multiple load balancers (or load balancing instances) may be configured.

[0105] In addition, despite Figure 8 , multiple load balancers (or load balancing instances) are configured for a specific network entity, but this is only an example for helping to easily understand the situation where one network entity is connected to other network entities via an interface. Figure 8 , a specific network entity is illustrated as being configured with several LBs, but the corresponding LB may also imply a single load balancer (or load balancing instance).

[0106] Such a load balancer (or load balancing instance) can be configured to take into account the particularities of each network entity or interface. In other words, the load balancer (or load balancing instance) can be customized taking into account its corresponding network entity or interface.

[0107] For example, in the case of a user plane function (UPF), there is a characteristic of processing a large number of packets compared to other network entities. Therefore, a larger number of load balancers (or load balancing instances) can be configured for the UPF compared to other network entities.

[0108] For another example, since the N2 interface (or Next Generation Application Protocol (NGAP)) between the AMF and the RAN uses the SCTP protocol for communication, a load balancer (or load balancing instance) for processing packet flows between the AMF and the RAN can be configured based on the Linux kernel including the ipvsadm engine. Furthermore, in the case of such an N4 interface, it has the characteristic that source NAT (SNAT) should not be performed on received data packets while passing through the load balancer (or load balancing instance). Therefore, a load balancer (or load balancing instance) customized to a load balancing scheme and its topology that reflect such characteristics can be configured. As an example of such customization, an additional operation of setting the default route of a container group to the load balancing instance can be performed to set the default route of these container groups to the load balancing instance when the container groups are created.

[0109] For another example, the N4 interface between the SMF and the UPF uses the GTP-C (General Packet Radio Service Tunneling Protocol Control) protocol for communication, so it will be possible to configure a load balancing instance including an envoy or nginix engine (or module). In addition, even for a load balancer (or load balancing instance) that receives packets from the UPF via the N4 interface, SNAT of the data packets should not be performed, similar to the N2 interface, so it will be possible to configure and operate the load balancer (or load balancing instance) by reflecting the above customization.

[0110] For another example, the N3 interface between the RAN and the UPF and the N6 interface between the UPF and the DN use the GTP-U (GTP User) protocol for communication, where a large number of packets are sent and received over bandwidth, resulting in a large packet processing burden. Therefore, the load balancer (or load balancing instance) can be configured to include a hardware accelerator, and it can be configured to include, for example, a graphics processing unit (GPU) with an intelligent NIC (network interface card), an FPGA NIC, NIC acceleration, etc.

[0111] For example, service-based interfaces (SBI), such as Nnssf, Namf, Nausf, Nsmf, Nudm, Npcf, Nnef, Naf, Nnrf, etc., use the HTTP2.0 protocol or communicate according to gRPC-based requests, so the load balancing instance can be configured to provide L7-based load balancing through the envoy engine (or module) or provide another LBaaS (load balancing as a service) solution.

[0112] According to the above reference Figures 1 to 8 The load balancing solutions and load balancers (or load balancing instances) of the various described embodiments can provide services optimized for packet flows and the data packets therefrom. Specifically, load balancing instances can be configured based on the results of classifying requests based on various parameters, including characteristics of client requests, thereby not only meeting request and performance requirements but also achieving efficient use of network resources.

[0113] In addition, the engine, load balancing scheme and its topology optimized for criteria, policies and settings can be configured so that efficient load balancing can be performed with only one load balancer (or load balancing instance) even when there are insufficient resources to arrange multiple load balancers in sequence.

[0114] Furthermore, according to the load balancer and load balancing method according to the embodiments disclosed herein, a separate network service header (NSH) for metadata or service paths is not required, so a service header processing module of the network entity is not required. Therefore, the load balancer and load balancing method thereof have the advantage that they can be optimally applied to any network entity without being constrained by the network environment or architecture.

[0115] Furthermore, since this load balancer is positioned to be fully distributed across the network, there is no situation where a specific network entity is inevitably selected based on the result of classifying the request. In addition, it can be applied to general use cases without a specific combination of service function chains (SFCs) and use cases.

[0116] The embodiments disclosed so far with reference to the present disclosure and the accompanying drawings are provided only as specific examples to easily describe the content of the present disclosure and to help understand the content of the present disclosure, and are not intended to limit the scope of the present disclosure thereto. Therefore, the scope of the present disclosure should be interpreted as including all changes or modifications derived based on the present disclosure in addition to the embodiments disclosed herein.

[0117] Furthermore, it should be understood that one or more embodiments disclosed herein may be performed in combination with each other, and that some or all of certain embodiments may be performed in combination with some or all of the other embodiments.

Claims

1. A method for performing multi-level load balancing using multiple layer protocols in a communication system, performed by a load balancer, the method comprising: receiving a service request associated with a network entity configured by the load balancer; identifying a protocol corresponding to the service request based on classifying the service request according to protocol type; In a case where the protocol corresponds to a first protocol among the plurality of protocols, determining a first load balancing scheme of a first level for processing traffic related to the first protocol, and selecting a first engine that supports the first protocol; In a case where the protocol corresponds to a second protocol among the plurality of protocols, determining a second load balancing scheme of a second level for processing traffic related to the second protocol, and selecting a second engine that supports the second protocol; Creating a load balancing instance including the first load balancing solution and the first engine or including the second load balancing solution and the second engine; as well as According to the load balancing instance, load balancing is performed on the data packets related to the service request.

2. The method according to claim 1, in, The first load balancing scheme corresponds to kernel-level load balancing with layer 4 L4 processing, and the first protocol includes a stream control transmission protocol (SCTP), and The second load balancing scheme corresponds to application-level load balancing with layer 7 L7 processing, and the second protocol includes Hypertext Transfer Protocol HTTP.

3. The method according to claim 1, in, The first engine and the second engine are included in an engine group configured to perform load balancing by the load balancer, and The engine group includes one or more of the following: an envoy engine, an ipvsadm engine, an ngnix engine, an intelligent network interface card (NIC), or a field programmable gate array (FPGA) NIC.

4. The method according to claim 1, in, The multiple different protocols include two or more of the following: L4 protocol, L7 protocol, Stream Control Transmission Protocol SCTP, Hypertext Transfer Protocol version 2 HTTP2.0, General Packet Radio Service Tunneling Protocol Control GTP-C and GTP User GTP-U, Google Remote Procedure Call gRPC or Structured Query Language SQL.

5. The method according to claim 1, in, Each of the first engine and the second engine is configured by an engine chain including two or more engines, and The load balancing path of the engine chain is determined according to the priorities of the two or more engines.

6. The method according to claim 1, further comprising: Determining a change to the load balancing instance based on at least one condition; as well as According to the determination result, the load balancing instance is updated. The conditions include a condition that the pod allocated by the load balancing instance is restarted and a condition that the Internet Protocol IP information is changed.

7. A load balancer for performing multi-level load balancing using multiple layer protocols in a communication system, the load balancer comprising: an engine group including a first engine and a second engine; An orchestrator, configured to select a load balancing solution and an engine according to a preset strategy; as well as a controller electrically connected to the engine group and the orchestrator to control the load balancer, wherein the controller is configured to: receiving a service request associated with a network entity configured by the load balancer; identifying a protocol corresponding to the service request based on classifying the service request according to protocol type; In a case where the protocol corresponds to a first protocol among the plurality of protocols, determining a first load balancing scheme of a first level for processing traffic related to the first protocol, and selecting a first engine that supports the first protocol; In a case where the protocol corresponds to a second protocol among the plurality of protocols, determining a second load balancing scheme of a second level for processing traffic related to the second protocol, and selecting a second engine that supports the second protocol; Creating a first load balancing instance including the first load balancing solution and the first engine and a second load balancing instance including the second load balancing solution and the second engine; and According to the load balancing instance, load balancing is performed on the data packets related to the service request.

8. The load balancer according to claim 7, in, The first load balancing scheme corresponds to kernel-level load balancing with layer 4 L4 processing, and the first protocol includes a stream control transmission protocol (SCTP), and The second load balancing scheme corresponds to application-level load balancing with layer 7 L7 processing, and the second protocol includes Hypertext Transfer Protocol HTTP.

9. The load balancer according to claim 7, in, The first engine and the second engine are included in an engine group configured to perform load balancing by the load balancer, and The engine group includes one or more of the following: an envoy engine, an ipvsadm engine, an ngnix engine, an intelligent network interface card (NIC), or a field programmable gate array (FPGA) NIC.

10. The load balancer according to claim 7, in, The multiple different protocols include two or more of the following: L4 protocol, L7 protocol, Stream Control Transmission Protocol SCTP, Hypertext Transfer Protocol version 2 HTTP2.0, General Packet Radio Service Tunneling Protocol Control GTP-C and GTP User GTP-U, Google Remote Procedure Call gRPC or Structured Query Language SQL.

11. The load balancer according to claim 7, wherein: Each of the first engine and the second engine is configured by an engine chain including two or more engines, and The load balancing path of the engine chain is determined according to the priorities of the two or more engines.

12. The load balancer according to claim 7, wherein: The controller is configured to: determining a change to the load balancing instance based on at least one condition, and According to the determination result, the load balancing instance is updated. The conditions include a condition that the pod allocated by the load balancing instance is restarted and a condition that the Internet Protocol IP information is changed.

Images