Dispersion method and dispersal unit thereof

Abstract

To provide a dispersion method and a dispersal unit thereof.SOLUTION: A distribution unit for a distribution method is coupled to a network entity cluster. In the distribution method, a first packet is received and a first network entity is selected from a plurality of network entities of the network entity cluster. A target MAC address of the first packet is rewritten to a MAC address of the first network entity, and the first packet to the first network entity is transmitted. In the distribution method, a PDU session migration from a busy or failed network entity to an idle network entity can be within a few seconds to avoid service interruption.SELECTED DRAWING: Figure 3

Description

[Technical field]

[0001] The present invention relates to a distribution method and a distribution unit thereof, and more particularly to a distribution method and a distribution unit thereof capable of quickly switching network entities. [Background technology]

[0002] Mobile operators prefer to deploy User Plane Functions (UPFs) in an N:M redundancy model due to the resulting cost benefits and operational simplicity. However, an N:M deployed UPF may incur very long failover times (resulting in longer service interruptions). Therefore, operators deploy UPFs using different redundancy models depending on the service level agreements (SLAs) required by different types of services, failing to achieve optimal cost benefits and operational simplicity. In addition, the Session Management Function (SMF) has no way to know the health / status of the UPF(s) and cannot switch to a running UPF(s) in case of a UPF failure. The existing criteria used by the SMF for UPF selection cannot ensure proper load balancing. In practice, the traffic of each Protocol Data Unit (PDU) session varies over a wide range, but there is no PDU session transition to move a PDU session from a busy / failed UPF to an idle UPF. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] US Patent Application Publication No. 2015 / 0326478 [Patent Document 2] China Patent Application Publication No. 112073503 [Patent Document 3] US Patent Application Publication No. 2021 / 0112049 Summary of the Invention

[0004] Therefore, an object of the present invention is to provide a distribution method and a distribution unit thereof for quickly switching network entities, thereby avoiding service interruptions and improving availability.

[0005] One embodiment of the present invention discloses a distribution method for a distribution unit coupled to a network entity cluster, the distribution method including the steps of receiving a first packet, selecting a first network entity from a plurality of network entities of the network entity cluster, rewriting a target Medium Access Control (MAC) address of the first packet to a MAC address of the first network entity, and sending the first packet to the first network entity.

[0006] One embodiment of the present invention discloses a distributed unit coupled to a network entity cluster, the distributed unit comprising a processing circuit and a storage circuit, the processing circuit configured to execute program code, the storage circuit coupled to the processing circuit and configured to store the program code, the program code instructing the processing circuit to perform the steps of receiving a first packet, selecting a first network entity from a plurality of network entities of the network entity cluster, rewriting a target Medium Access Control (MAC) address of the first packet to a MAC address of the first network entity, and transmitting the first packet to the first network entity.

[0007] In one embodiment, the distribution unit is configured to select the first network entity according to traffic of the multiple network entities.

[0008] In one embodiment, the distributed unit is a cluster and includes a plurality of nodes, a first node of the plurality of nodes is selected from the plurality of nodes according to a hash algorithm to rewrite the target MAC address, and each of the plurality of nodes is a load balancer.

[0009] In one embodiment, the distributed unit or the network entity cluster includes a management network, and one node is selected by the management network from the multiple nodes of the distributed unit according to a hash algorithm, or one network entity is selected by the management network from the multiple network entities of the network entity cluster according to traffic or status of the multiple network entities.

[0010] In one embodiment, the first network entity is configured to translate a private IP address to a shared public IP address of the network entity cluster, or to translate a shared public IP address of the distributed unit to a private IP address.

[0011] In one embodiment, the nodes of the distributed unit are located within the user plane functions, the radio units, the distributed units, or the central units, respectively. Alternatively, the distributed unit is located independently outside the user plane functions, the radio units, the distributed units, or the central units.

[0012] These and other objectives of the present invention will no doubt become obvious to those of ordinary skill in the art after reading the following detailed description of the preferred embodiment that is illustrated in the various figures and drawings. [Brief description of the drawings]

[0013] [Figure 1] FIG. 2 is a schematic diagram of a cluster according to an embodiment of the present application. [Diagram 2]1 is a schematic diagram of a distributed system according to an embodiment of the present application. [Diagram 3] 1 is a schematic diagram of a communication system and a corresponding communication method according to an embodiment of the present application; [Figure 4] 1 is a schematic diagram of a communication system and a corresponding communication method according to an embodiment of the present application; [Diagram 5] 1 is a schematic diagram of a communication system and a corresponding communication method according to an embodiment of the present application; [Figure 6] 1 is a schematic diagram of a communication system and a corresponding communication method according to an embodiment of the present application; [Figure 7] 1 is a schematic diagram of a communication system according to an embodiment of the present application; DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] 1 is a schematic diagram of a cluster 14 according to an embodiment of the present application. The cluster 14 may include multiple (cluster) nodes (e.g., 140N1, 140N2) and a management network 140M.

[0015] The external interfaces (e.g., local area network (LAN) interfaces) of all the nodes (e.g., 140N1 and 140N2) are combined to create a virtual cluster interface. All the nodes may communicate, talk, control, or exchange data with each other using the management network 140M. The cluster 14 may be an active-active cluster. All the nodes may receive, send, or process data. The management network 140M may arbitrate (e.g., according to a hashing algorithm used by ClusterIP) to select one of all the nodes to receive, send, or process data.

[0016] In one embodiment, the cluster 14 may have a (shared) Internet Protocol (IP) address, which may be a private IP address or a public IP address. For example, the (shared) IP address IP1 of the cluster 14 may be 192.168.10.3, and the media access control (MAC) address MAC1 of the cluster 14 may be 01:02:03:04:05:06. In one embodiment, the network segment of the management network 140M may be, for example, 192.168.20.0 / 24. The IP addresses IP11 and IP12 of the node 140N1 may be, for example, 192.168.10.1 and 192.168.20.1, respectively. The IP addresses IP21 and IP22 of the node 140N2 may be, for example, 192.168.10.2 and 192.168.20.2, respectively. The network segment of a device connected to node 140N1 or 140N2 may be, for example, 192.168.10.0 / 24. Nodes 140N1 and 140N2 may have different MAC addresses.

[0017] In one embodiment, the cluster 14, the nodes (e.g., 140N1 or 140N2), or the management network 140M may be implemented using different combinations of software, firmware, and / or hardware (e.g., circuit(s) or processor(s)). In one embodiment, the cluster 14 (or an active-active cluster of size m or n) may be implemented using ClusterIP, which may be part of the Netfilter code. In one embodiment, the management network 140M may be a switch, such as, for example, a workgroup switch. In one embodiment, the cluster 14 may be a distributed cluster (e.g., 341, 441, 541, or 641), and the nodes (e.g., 140N1 or 140N2) may perform load distribution or load balancing using different combinations of software, firmware, and / or hardware (e.g., load balancer(s)). In one embodiment, the cluster 14 may be a network entity cluster (e.g., 242, 342, 442, 542, or 642) and the nodes (e.g., 140N1 or 140N2) may be network entities such as a User Plane Function (UPF), an Access and Mobility Management Function (AMF), a Network Repository Function (NRF), a Session Management Function (SMF), a Radio Unit (RU), a Distributed Unit (DU), or a Central Unit (CU).

[0018] 2 is a schematic diagram of a distributed system 20 according to one embodiment of the present application. The distributed system 20 may include a distributed unit 241 and a network entity cluster 242. The network entity cluster 242 may include multiple network entities 242TT1-242TTn. The distributed unit 241 or the network entities (e.g., 242TT1 or 242TTn) may be implemented using different combinations of software, firmware, and / or hardware. In one embodiment, the distributed unit 241 may be a distributed cluster and thus includes multiple nodes.

[0019] The distribution unit 241 may receive a packet and select a network entity (e.g., 242TT1) from the network entities 242TT1-242TTn. The distribution unit 241 may rewrite the target MAC address of the packet to the MAC address of the selected network entity (e.g., 242TT1) and send the packet to the selected network entity (e.g., 242TT1). In other words, the distribution unit 241 may perform load distribution or load balancing according to the load / status of all the network entities 242TT1-242TTn and may allocate / assign / distribute tasks across one of the network entities 242TT1-242TTn. This avoids uneven overloading of any particular network entity (e.g., 242TT1) while other network entities (e.g., 242TT2-242TTn) remain idle. It also ensures continuity of service provision by selecting another network entity (eg, 242TT1) if any of the network entities 242TT1 to 242TTn is unresponsive or fails.

[0020] 3 is a schematic diagram of a communication system 30 and a communication method thereof according to an embodiment of the present application. The communication system 30 may include a user equipment (UE) 310UE, an RU 320RU, DUs 320DU1 and 320DU2, CUs 320CU1 and 320CU2, a router 330AR, an AMF 340AMF, an SMF 340SMF, an NRF 340NRF, a virtual UPF 340UPF, and a server 350SVR, which may be communicatively coupled or interconnected with each other. The router 330AR (e.g., an aggregation router) is located between the CUs 320CU1 and 320CU2 and the virtual UPF 340UPF.

[0021] 3, the virtual UPF 340UPF may include a distributed cluster 341 and a network entity cluster 342. The distributed cluster 341 may include m load balancers 341LB1-341LBm (and may be an active-active cluster of size m with a load balancing method of direct server return). The load balancers 341LB1-341LBm, which may be used as (cluster) nodes, may control, negotiate, or exchange data with each other via a management network of the distributed cluster 341 (between cluster nodes). The load balancers 341LB1-341LBm of the distributed cluster 341 (or the distributed cluster 341) may have the same (shared) private IP address or port (e.g., port number). Upon startup, a distributed cluster 341 (e.g., an active-active cluster of load balancers) may register with SMF 340SMF (with / using a private IP address and / or port) as a virtual UPF 340UPF having / with a (shared) IP address / port, which may be a private IP address / port.

[0022] The network entity cluster 342 may include n UPFs 342UPF1-342UPFn. The UPFs 342UPF1-342UPFn, which may be used as nodes, may control, negotiate, or exchange data with each other via a management network of the network entity cluster 342. The UPFs 342UPF1-342UPFn of the network entity cluster 342 may each have a different private IP address, but the (network entity cluster 342 or) UPFs 342UPF1-342UPFn have the same (shared) public IP address or port.

[0023] 3, the UE 310UE intends to send data to the server 350SVR. After the UE 310UE registers with the SMF 340SMF through the AMF 340AMF, the SMF 340SMF may select a UPF (e.g., virtual UPF 340UPF) from / using a local repository or the NRF 340NRF and allocate / assign the selected UPF to a protocol data unit (PDU) session of the UE 310UE. In one embodiment, the private IP address and / or port of the selected UPF (e.g., virtual UPF 340UPF) is a (shared) private IP address and / or port of the distributed cluster 341 (i.e., an active-active cluster of load balancers).

[0024] 3, a packet sent by the UE 310UE and destined for the server 350SVR passes through the RU 320RU, the DU 320DU1, the CU 320CU1, and the router 330AR (e.g., an aggregation router) and is then sent to a (shared) private IP address and / or port of the distributed cluster 341 (i.e., an active-active cluster of load balancers). In one embodiment, the source IP address may be the private IP address of the UE 310UE and the target IP address may be the (shared) private IP address of the distributed cluster 341.

[0025] Since the private IP addresses of the load balancers 341LB1-341LBm are the same, the management network of the distributed cluster 341 may select one of the load balancers 341LB1-341LBm (e.g., 341LB1) (e.g., according to a hash algorithm used by ClusterIP) so that the selected load balancer (e.g., 341LB1) picks up the packet. The selected load balancer (e.g., 341LB1) may rewrite the target MAC address of the packet to the MAC address of one UPF (e.g., 342UPF1) selected by the (selected) load balancer (e.g., 341LB1).

[0026] In one embodiment, state information of all PDU sessions is stored in memory 343 (e.g., distributed cache memory system, memcached, or Redis) so that a (selected) load balancer (e.g., 341LB1) may select one UPF (e.g., 342UPF1) in the network entity cluster 342 based on the traffic of PDU sessions on backend UPFs 342UPF1-342UPFn. In this way, PDU session migration from a busy / failed UPF (e.g., 342UPFn) to an idle UPF (e.g., 342UPF1) can be within a very short time (e.g., 3 seconds) to avoid service interruption of the UE 310UE.

[0027] 3, the selected load balancer (e.g., 341LB1) sends the packet to the selected UPF (e.g., 342UPF1). In one embodiment, the source IP address may be a private IP address of the UE 310UE, and the target IP address may be a private IP address of the selected UPF (e.g., 342UPF1).

[0028] The packet is then sent to the selected UPF (e.g., 342UPF1), which translates the private IP address to a public IP address based on source network address translation (SNAT). In other words, when the packet travels within the core network, it is the private IP address assigned to the UE 310UE by the SMF 340SMF that is used. When / before the packet enters or is sent through the Internet, the packet is translated from the private IP address (of the UE 310UE) to a public IP address (for which the traffic is globally routable). In one embodiment, the public IP address is a (shared) public IP address shared by the UPFs 342UPF1-342UPFn, and the private IP address is a private IP address assigned to the UE 310UE by the SMF 340SMF (for packet forwarding within the core network or to provide local routable). 3, the selected UPF (e.g., 342UPF1) may then send the packet (having the public IP address and / or port and the multicast MAC address) to server 350SVR. In one embodiment, the source IP address may be a public IP address shared by UPFs 342UPF1-342UPFn, and the target IP address may be the public IP address of server 350SVR.

[0029] 3, the server 350SVR may send the (responded) packet back to the network entity cluster 342 (e.g., UPF cluster) since the source IP address in the packet's header is the (shared) public IP address of the network entity cluster 342. In one embodiment, the source IP address may be the public IP address of the server 350SVR, and the target IP address may be the (shared) public IP address shared by the UPFs 342UPF1-342UPFn. That is, load balancing by direct server return may be realized.

[0030] After the network entity cluster 342 receives the (responded) packet from the server 350SVR, one UPF of the network entity cluster 342 may process the (responded) packet. In one embodiment, the previously selected UPF (e.g., 342UPF1) may process the (responded) packet (according to the instruction(s) of the management network of the network entity cluster 342). In one embodiment, if the previously selected UPF (e.g., 342UPF1) is unresponsive or malfunctioning, the management network of the network entity cluster 342 may arbitrate and select an (idle) UPF (e.g., 342UPFn) from the network entity cluster 342. The selected UPF (e.g., 342UPFn) may process the (responded) packet using the relevant information stored in the memory 343. In this way, a PDU session(s) may be transitioned from a busy / failed UPF (e.g., 342UPF1) to an idle UPF (e.g., 342UPFn) within a very short time to avoid service interruption to the UE 310UE.

[0031] The selected UPF (e.g., 342UPF1) or UPF cluster may then route the (responded) packet to the (original) UE 310UE, as shown in steps S319-S323 of Figure 3. In one embodiment, the source IP address may be a private IP address of the selected UPF (e.g., 342UPF1 or 342UPFn) and the target IP address may be a private IP address of the UE 310UE.

[0032] In one embodiment, the UE 310UE may be, for example, a mobile phone, and the server 450SVR may be, for example, an application (APP) server, a web server, or an IP multimedia subsystem (IMS) server. The UE 310UE may send a request to the server 450SVR, and the server 450SVR may send back a response according to the request after execution. However, the present invention is not limited thereto.

[0033] 4 is a schematic diagram of a communication system 40 and a communication method thereof according to an embodiment of the present application. The communication system 40 may include a UE 410UE, an RU 420RU, DUs 420DU1 and 420DU2, CUs 420CU1 and 420CU2, a router 430AR, an AMF 440AMF, an SMF 440SMF, an NRF 440NRF, a distributed cluster 441, a network entity cluster 442, and a server 450SVR.

[0034] In one embodiment (as shown in FIG. 7), the UE 410UE may be, for example, a camera, and the server 450SVR may be, for example, an artificial intelligence (AI) server or an IMS server. The server 450SVR may be communicatively coupled / connected to the UE 410UE or may send request(s) to the UE 410UE, and the UE 410UE may respond by sending image(s) or multimedia / video / audio data to the server 450SVR. The UE 410UE and the server 450SVR may support Real Time Streaming Protocol (RTSP) streaming. However, the present invention is not limited thereto.

[0035] 4, distributed cluster 441 may include m load balancers 441LB1-441LBm (and may be an active-active cluster of size m with a load balancing method of direct server return). The load balancers 441LB1-441LBm, which may be used as (cluster) nodes, may control, negotiate, or exchange data with each other via a management network of distributed cluster 441 (between cluster nodes). The load balancers 441LB1-441LBm of distributed cluster 441 (or distributed cluster 441) may have the same (shared) public IP address or port.

[0036] The network entity cluster 442 may include n UPFs 442UPF1-442UPFn. The UPFs 442UPF1-442UPFn, which may be used as nodes, may control, negotiate, or exchange data with each other via the management network of the network entity cluster 442. The UPFs 442UPF1-442UPFn of the network entity cluster 442 may have different public IP addresses, but the (network entity cluster 442 or) UPFs 442UPF1-442UPFn have the same (shared) private IP address or port. At startup, the network entity cluster 442 (e.g., an active-active cluster of UPFs) may register with the SMF 440SMF (with / using a private IP address and / or port) as a virtual UPF 440UPF having / with a (shared) IP address / port, which may be a private IP address / port.

[0037] 4, the server 450SVR intends to transmit data to the UE 410UE. After the UE 410UE registers with the SMF 440SMF through the AMF 440AMF, the SMF 440SMF may select a UPF (e.g., virtual UPF 440UPF) from / using a local repository or the NRF 440NRF and allocate / assign the selected UPF to the PDU session of the UE 410UE. In one embodiment, the private IP address and / or port of the selected UPF (e.g., virtual UPF 440UPF) is a (shared) private IP address and / or port of the network entity cluster 442.

[0038] 4, packets sent by server 450SVR and destined for UE 410UE are sent to a (shared) public IP address and / or port of distributed cluster 441 (i.e., an active-active cluster of load balancers). In one embodiment, packets may be sent from a public IP address of server 450SVR to a (shared) public IP address of distributed cluster 441.

[0039] Since the public IP addresses of the load balancers 441LB1-441LBm are the same, the management network of the distributed cluster 441 may select one of the load balancers 441LB1-441LBm (e.g., 441LB1) (e.g., according to a hash algorithm used by ClusterIP) so that the selected load balancer (e.g., 441LB1) picks up the packet. The selected load balancer (e.g., 441LB1) may rewrite the target MAC address of the packet to the MAC address of one UPF (e.g., 442UPF1) selected by the (selected) load balancer (e.g., 441LB1).

[0040] In one embodiment, the state information of all PDU sessions is stored in memory 443 so that the (selected) load balancer (e.g., 441LB1) may select one UPF (e.g., 442UPF1) in the network entity cluster 442 based on the traffic of PDU sessions on backend UPFs 442UPF1-442UPFn. This allows transfer of PDU session(s) from busy / failed UPF (e.g., 442UPFn) to idle UPF (e.g., 442UPF1) within a very short time (e.g., 3 seconds) to avoid service interruption of UE 410UE.

[0041] As shown in step S405 of FIG. 4, after the selected load balancer (e.g., 441LB1) sends the packet to the public IP address of the selected UPF (e.g., 442UPF1), the selected UPF (e.g., 442UPF1) may translate the public IP address to a private IP address according to destination network address translation (DNAT). In one embodiment, the public IP address is a (shared) public IP address shared by the distributed cluster 441, and the private IP address is a private IP address allocated to the UE 410UE by the SMF 440SMF. As shown in steps S407-S417 of FIG. 4, the selected UPF (e.g., 442UPF1) may then send the packet (having the private IP address and / or port and the multicast MAC address) to the UE 410UE. In one embodiment, the packet may be sent from a private IP address shared by the network entity cluster 442, via a router 440AR (e.g., an aggregation router), a CU 420CU1, a DU 420DU1, and a RU 420RU, to a private IP address of the UE 410UE.

[0042] 4, the UE 410UE may send the (responded) packet back to the network entity cluster 442. In one embodiment, the (responded) packet may be sent from a private IP address of the UE 410UE to a (shared) private IP address shared by the network entity cluster 442.

[0043] After the network entity cluster 442 receives the (responded) packet from the UE 410UE, one UPF of the network entity cluster 442 may process the (responded) packet. In one embodiment, the previously selected UPF (e.g., 442UPF1) may process the (responded) packet (according to instruction(s) of the management network of the network entity cluster 442). In one embodiment, if the previously selected UPF (e.g., 442UPF1) does not respond or fails, the management network of the network entity cluster 442 may arbitrate and select an (idle) UPF (e.g., 442UPFn) from the network entity cluster 442. The selected UPF (e.g., 442UPFn) may process the (responded) packet using relevant information stored in the memory 444. This allows migration of PDU session(s) from a busy / failed UPF (e.g., 442UPF1) to an idle UPF (e.g., 442UPFn) within a very short time to avoid service interruption for the UE 410UE.

[0044] As shown in step S433 of FIG. 4, the selected UPF (e.g., 442UPFn) or UPF cluster may then route the (responded) packet to the (original) server 450SVR. In one embodiment, the (responded) packet may be sent from the public IP address of the selected UPF (e.g., 442UPF1) to the public IP address of server 450SVR. That is, load balancing by direct server return may be achieved.

[0045] 5 is a schematic diagram of a communication system 50 and a communication method thereof according to an embodiment of the present application. The communication system 50 may include a UE 510UE, an RU 520RU, a DU 520DU1, CUs 520CU1-520CUm, a router 530AR, a network entity cluster 542, a memory 543, a switch 560SW (e.g., a Layer 3 (L3) switch), and a server 550SVR.

[0046] In FIG. 5, the CUs 520CU1-520CUm may include network controllers 520NIC1-520NICm, respectively. The network controllers 520NIC1-520NICm, each of which may be implemented by a system on chip (SoC), may include load balancers 541LB1-541LBm, respectively. The load balancers 541LB1-541LBm may form / configure a distributed cluster 541, function as nodes of the distributed cluster 541, and control, negotiate, or exchange data with each other via a management network 541mgmtnetL of the distributed cluster 541. The load balancers 541LB1-541LBm of the distributed cluster 541 (or the distributed cluster 541) may have the same (shared) private IP address or port. In other words, the load balancers 541LB1-541LBm may be realized / implemented by utilizing the computing resources of the CUs 520CU1-520CUm.

[0047] 5, the network entity cluster 542 may include n UPFs 542UPF1-542UPFn. The UPFs 542UPF1-542UPFn, which may be used as nodes, may control, negotiate, or exchange data with each other via a management network 542mgmtnetU of the network entity cluster 542. The UPFs 542UPF1-542UPFn of the network entity cluster 542 may have different private IP addresses, but the (network entity cluster 542 or) UPFs 542UPF1-542UPFn have the same (shared) public IP address or port.

[0048] As shown in steps S501-S504 and S512 of FIG. 5, a packet sent by the UE 510UE and destined for the server 550SVR is sent to the distributed cluster 541. As shown in step S512 of FIG. 5, because the private IP addresses shared by the load balancers 541LB1-541LBm are the same, the management network 541mgmtnetL of the distributed cluster 541 may select one of the load balancers 541LB1-541LBm (e.g., 541LB1) to pick up the packet. The selected load balancer (e.g., 541LB1) may rewrite the target MAC address of the packet to the MAC address of one UPF (e.g., 542UPF1) selected by the load balancer (e.g., 541LB1). In one embodiment, state information of all PDU sessions is stored in memory 543 so that a (selected) load balancer (e.g., 541LB1) may select one UPF (e.g., 542UPF1) in the network entity cluster 542 based on the traffic of PDU sessions on backend UPFs 542UPF1 to 542UPFn.

[0049] As shown in steps S513-S514 of FIG. 5, after the selected load balancer (e.g., 541LB1) sends the packet to the private IP address of the selected UPF (e.g., 542UPF1), the selected UPF (e.g., 542UPF1) may translate the private IP address to a public IP address based on source network address translation. In one embodiment, the public IP address is a (shared) public IP address shared by UPFs 542UPF1-542UPFn. As shown in steps S515-S516 of FIG. 5, the selected UPF (e.g., 542UPF1) may send the packet (with the public IP address and / or port and multicast MAC address) to the server 550SVR.

[0050] Since the source IP address of the packet's header is the (shared) public IP address of the network entity cluster 542, in steps S517-S518 of FIG. 5, the server 550SVR may send the (responded) packet back to the network entity cluster 542. That is, load balancing by direct server return may be achieved. In one embodiment, in step S518 of FIG. 5, the previously selected UPF (e.g., 542UPF1) may process the (responded) packet (according to the instruction(s) of the management network 542mgmtnetU of the network entity cluster 542). In one embodiment, in step S518 of FIG. 5, if the previously selected UPF (e.g., 542UPF1) does not respond or fails, the management network 542mgmtnetU of the network entity cluster 542 may arbitrate and select an (idle) UPF (e.g., 542UPFn) from the network entity cluster 542. The selected UPF (eg, 542UPFn) may utilize the relevant information stored in memory 543 to process the (responded) packet.

[0051] As shown in steps S519 to S523 of FIG. 5, the selected UPF (eg, 542UPFn) or UPF cluster may then route the (responded) packet to the (originating) UE 510UE.

[0052] 6 is a schematic diagram of a communication system 60 and a communication method thereof according to an embodiment of the present application. The communication system 60 may include a UE 610UE, a RU 620RU, a DU 620DU1, CUs 620CU1-620CUm, a router 630AR, a distributed cluster 641, a network entity cluster 642, a memory 643, a switch 660SW (e.g., an L3 switch), and a server 650SVR. In other words, the distributed cluster 641 (e.g., a load balancer cluster) is added between the network entity cluster 642 (e.g., a UPF cluster) and the server 650SVR.

[0053] The distributed cluster 641 may include m load balancers 641LB1 to 641LBm. The load balancers 641LB1 to 641LBm, which may be used as nodes, may control, negotiate, or exchange data with each other via a management network 641mgmtnetL of the distributed cluster 641. The load balancers 641LB1 to 641LBm of the distributed cluster 641 (or the distributed cluster 641) may have the same (shared) public IP address or port.

[0054] The network entity cluster 642 may include n UPFs 642UPF1-642UPFn. The UPFs 642UPF1-642UPFn, which may be used as nodes, may control, negotiate, or exchange data with each other via a management network 642mgmtnetU of the network entity cluster 642. The UPFs 642UPF1-642UPFn of the network entity cluster 642 may each have a different public IP address, but the (network entity cluster 642 or) UPFs 642UPF1-642UPFn have the same (shared) private IP address or port.

[0055] In one embodiment, the UPFs 642UPF1-642UPFn may include computing circuits 642NIC1-642NICm, each of which may be implemented by a SoC. The computing circuits 642NIC1-642NICm may include load balancers 641LB1-641LBm, respectively. In other words, the load balancers 641LB1-641LBm may be realized / implemented by utilizing the computing resources of the UPFs 642UPF1-642UPFn. However, the load balancers 641LB1-641LBm may also be independently configured / located outside the UPFs 642UPF1-642UPFn, as shown in FIG. 6.

[0056] As shown in steps S601-S602 of FIG. 6, a packet sent by the server 650SVR and destined for the UE 610UE is sent to the distributed cluster 641. As shown in step S603 of FIG. 6, since the public IP address shared by the load balancers 641LB1-641LBm is the same, the management network 641mgmtnetL of the distributed cluster 641 may select one of the load balancers 641LB1-641LBm (e.g., 641LB1) to pick up the packet. The selected load balancer (e.g., 641LB1) may rewrite the target MAC address of the packet to the MAC address of one UPF (e.g., 642UPF1) selected by the load balancer (e.g., 641LB1). In one embodiment, state information of all PDU sessions is stored in memory 643 so that a (selected) load balancer (e.g., 641LB1) may select one UPF (e.g., 642UPF1) in the network entity cluster 642 based on the traffic of PDU sessions on backend UPFs 642UPF1 to 642UPFn.

[0057] As shown in steps S604-S605 of Figure 6, after the selected load balancer (e.g., 641LB1) sends the packet to the public IP address of the selected UPF (e.g., 642UPF1), the selected UPF (e.g., 642UPF1) may translate the public IP address to a private IP address according to destination network address translation. As shown in steps S607-S617 of Figure 6, the selected UPF (e.g., 642UPF1) may then send the packet (with the private IP address and / or port and the multicast MAC address) to the UE 610UE.

[0058] In steps S618-S630 of FIG. 6, the UE 610UE may send the (responded) packet back to the network entity cluster 642. In one embodiment, in step S631 of FIG. 6, the previously selected UPF (e.g., 642UPF1) may process the (responded) packet (according to the instruction(s) of the management network 642mgmtnetU of the network entity cluster 642). In one embodiment, in step S631 of FIG. 6, if the previously selected UPF (e.g., 642UPF1) does not respond or malfunctions, the management network 642mgmtnetU of the network entity cluster 642 may arbitrate and select an (idle) UPF (e.g., 642UPFn) from the network entity cluster 642. The selected UPF (e.g., 642UPFn) may process the (responded) packet utilizing the relevant information stored in the memory 643.

[0059] 6, the selected UPF (e.g., 642UPFn) may then route the (responded) packet to the (original) server 650SVR, i.e., load balancing by direct server return may be achieved.

[0060] In one embodiment, steps S501-S504, S516, S517, and S519-S523 correspond approximately to steps S301-S304, S316, S317, and S319-S323. Steps S601, S605, S607, S608, S615-S620, S629-S630, and S633 correspond approximately to steps S401, S405, S407, S408, S415-S420, S429-S430, and S433.

[0061] In summary, when a PDU session is sent to a network entity (e.g., UPF), the present invention allows for a fast switch between a busy / malfunctioning network entity and an idle network entity using a distributed unit (or a management network of a network entity cluster), which allows the sending of PDUs to the idle network entity to avoid service interruptions and improve availability. The present invention achieves the same end-user experience as seen in a 1:1 redundancy model when a network entity (e.g., UPF) fails, but with lower capital expenditure. Furthermore, essentially all network entities (e.g., UPF) are used without being idle, but even in the case of an N:M redundancy model, M / (N+M) network entities (e.g., UPF) are idle. In addition, the load balancing of the network entities (e.g., UPF) is enhanced to enable a scale-out of the network entities (e.g., UPF) and thus a (high) throughput of the core network. Furthermore, a packet is forwarded through the distributed unit, but another packet responding to this packet does not pass through the distributed unit, thereby enabling a direct server return.

[0062] Those skilled in the art will readily recognize that numerous modifications and variations of the devices and methods may be made while retaining the teachings of the present invention. Accordingly, the above disclosure should be construed as limited only by the metes and bounds of the appended claims.

Claims

1. 1. A distribution method for a distributed cluster coupled to a network entity cluster, comprising: receiving a first packet; selecting a first network entity from a plurality of network entities of the network entity cluster; rewriting a target Medium Access Control (MAC) address of the first packet to a MAC address of the first network entity; transmitting the first packet to the first network entity; A dispersion method comprising:

2. 2. The distributed method of claim 1, wherein the distributed cluster or the network entity cluster registers with a session management function as a virtual user plane function having a private Internet Protocol (IP) address, the private IP address being shared by multiple nodes of the distributed cluster or shared by the multiple network entities of the network entity cluster.

3. 2. The distributed method of claim 1, wherein the first network entity is selected by the distributed cluster from the plurality of network entities of the network entity cluster to transmit the first packet sent from the first entity to the distributed cluster via the first network entity to a second entity, and a second network entity from the plurality of network entities is selected by a management network of the network entity cluster to receive a second packet from the second entity and transmit the second packet to the first entity, and the first network entity and the second network entity are the same network entity or different network entities.

4. a plurality of nodes of the distributed cluster have a shared private IP address and a plurality of network entities of the network entity cluster have a shared public IP address; or the plurality of nodes of the distributed cluster have a shared public IP address and the plurality of network entities of the network entity cluster have a shared private IP address. The dispersion method according to claim 1 .

5. a distributed cluster coupled to the network entity cluster, a processing circuit configured to execute program code; a memory circuit coupled to the processing circuit and configured to store the program code; the program code causing the processing circuit to: receiving a first packet; selecting a first network entity from a plurality of network entities of the network entity cluster; rewriting a target Medium Access Control (MAC) address of the first packet to a MAC address of the first network entity; transmitting the first packet to the first network entity; Instruct the distributed cluster to execute.

Images