State-less GTP-u load balancer

Abstract

The invention relates to a method for load balancing data traffic in a communication system. The method comprises receiving, at a load balancer, a first data packet from a first network gateway in accordance with a first communication protocol. The first data packet encapsulates a second data packet according to a tunneling protocol. The second data packet comprises a header including a destination identifier. The load balancer extracts the destination identifier from the second data packet and generates an address by combining a predetermined prefix and the destination identifier. The load balancer encapsulates the second data packet and the generated address in a third data packet according to a second communication protocol. The generated address is the destination address of the third data packet and the load balancer transmits the third data to a node of a second network gateway indicated by the generated address.

Description

[0001] State-less GTP-U load balancer

[0002] The invention relates to a method for load balancing data traffic in in a communication system.

[0003] In radio communication systems, the GTP-U (GPRS Tunneling Protocol - User Plane) as defined in 3GPP TS 29.281 is widely used to transmit user data packets between network elements. Examples for such network elements are an SGW (Serving Gateway) and a PGW (Packet Gateway), eNodeB in EPS (Evolved Packet System) or an SGSN (Serving GPRS Support Node) and a GGSN (Gateway GPRS Support Node) in a GPRS core network. The GPRS Tunneling Protocol is also used in 5G networks, for instance on the user plane on the N9 (UPF to UPF) and N3 (UPF to gNodeB or Access Network) reference points, where UPF stands for User Plane Function. GTP-U encapsulates user data packets by adding a specific header to them. This header contains information needed for internal routing and delivery of user traffic. Similar to other IP tunneling protocols like VxLAN or GENEVE, GTP-U uses UDP (User Datagram Protocol) as a transport protocol and specific destination UDP port 2152.

[0004] The GTP-U header includes a field for tunnel identification, the tunnel end-point identifier (TEID). The TEID ensures that packets are correctly associated with the appropriate tunnel endpoint during encapsulation and de-capsulation. It therefore serves as a destination identifier. GTP-U is an end-to-end tunneling protocol where both gateways (e.g., SGW and PGW or SGSN and GGSN) prior to the establishment of GTP-U tunnels use “out-of-band” communication approach by employing GTP-C protocol to communicate and setup all necessary configuration to establish GTP-U tunnels (i.e., end-point IP addresses and designated TEIDs). In addition, a GTP-U tunnel is unidirectional; thus, in general the two gateways are establishing two unidirectional GTP-U tunnels - one for uplink, and a second one for downlink. As per 3GPP TS 23.214 the legacy monolith architecture has been broken up and evolved into CUPS (control and user plane separation) where both GTP-C and GTP- U interactions are managed by dedicated and decoupled nodes of the respective gateways.

[0005] As a result of all the above and following 3GPP standards, a GTP-U tunnel is state-full and end-to-end with 3-value tuple of {Destination IP; Source IP; TEID} to separate and isolate encapsulated traffic transferred between the gateways. The sending gateway transmits packages using the destination IP and TEID as indicated by the control plane during set up of the tunnel. The receiving gateway has also been set up by the control plane and recognizes the respective tunnel from the TEID. The term “state-full” refers here to the fact that the tunnel keeps track and maintains the current state or context of a connection or session for the data transfer between the endpoints. The expression “the tunnel keeps track and maintains...” is a short way to indicate that tunnel nodes, i.e. , a first and a second gateway such as, for instance, the SGW and the PGW, maintain information (or states) related to tunnels; the latter being logical separators of multiple connections received by the nodes.

[0006] Due to large amounts of data traffic that may need to be handled by the gateways, it can be desirable to establish as method of balancing the load of data traffic between different nodes of the respective gateways. However, because of the unidirectional and state-full nature of the GTP-U protocol, conventional IP-based load-balancing techniques based on the usual 5-value tuple of {Destination IP; Destination Port; Source IP; Source Port; Protocol} are not directly applicable to GTP-U. This is because the GTP-U nodes need to be set up for the respective GTP-U tunnels, and packets belonging to the same tunnel cannot be flexibly routed to different nodes.

[0007] Thus, an approach has previously been applied, which involves an additional load balancer as a separate node to load-balance the traffic between the nodes of the gateway. In this approach, the load balancer is required to keep track of the running sessions including TEIDs of uplink and downlink GTP-U tunnels and IP addresses of related nodes of the gateways. This data is stored internally in the load balancer to correctly route incoming GTP-U packets to the destination node based on the TEID. The load balancer is furthermore required to be updated by an external node (i.e. GTP-C node) about new mappings of TEIDs to GTP-U nodes, when a new tunnel is established or an existing connection is modified. Therefore, the load balancing itself and the corresponding load balancer is statefull in this approach, which makes the system prone to failures and entirely dependent on the load balancer. For instance, when the load balancer fails, all previous state information is lost, and the system becomes non-functional until a new load balancer is provisioned, and previous state information is restored. In addition, the state-full load balancing causes plenty of limitations and restrictions when developing and deploying cloud-native network functions (CNFs). Conventional load balancing techniques have the further disadvantage that the load balancer receives IP traffic from an IPX / GRX network in form of data packets according to the IPv4 protocol. Globally, the IPv4 protocol is used in these networks. Thus, when the load balancer is supposed to forward the IPv4 packets in accordance with the internal table to the respective PGW-U node, each node requires an individual public IPv4 address. However, IPv4 addresses are a scarce resource, which may limit the number of PGW-U nodes that can be used.

[0008] In this context, it is the object of the invention to provide a method for load balancing traffic in a communication system that is reliable, allows for a scalable architecture, requires less address space and is cloud-native.

[0009] In a first aspect of the invention the problem is solved by a method for load balancing data traffic in a communication system. The method may be used for load balancing data traffic in a core network or in a core network element of a wireless communication system. The method comprises receiving, at a load balancer, a first data packet from a first network gateway (or first gateway) in accordance with a first communication protocol, the first data packet encapsulating a second data packet according to a tunneling protocol, wherein the second data packet comprises a header including a destination identifier (or node / endpoint identifier). The method also comprises extracting, by the load balancer, the destination identifier from the second data packet and generating an address by combining a predetermined prefix and the destination identifier, wherein the generated address is in accordance with a second communication protocol. Further, the method comprises encapsulating, by the load balancer, the second data packet and the generated address in a third data packet according to the second communication protocol, the generated address being the destination address of the third data packet; and transmitting the third data packet in accordance with the second communication protocol to a node of a second network gateway (or second gateway) indicated by the generated address.

[0010] The communication system may for instance be a radio or wireless communication system. Specifically, the communication system may be a GPRS core network. The communication system may be a GSM, UMTS, LTE and 5G NR radio network or a part thereof. The first and second network gateways may be the SGW and PGW, in one example. The gateways may comprise a number of separate, independent nodes. The communication protocols may be IP based communication protocols. According to an example, the first communication protocol and the second communication protocol are the same. According to another example, the first communication protocol may be different than the second communication protocol. For example, the first communication protocol may be the IPv4 protocol, and the second communication protocol may be the IPv6 protocol. The tunnelling protocol may be the GTP-U protocol used in the GPRS core network. A packet according to one of these protocols refers to a data packet that is built according to the provision provided by this protocol. The destination identifier may be the tunnel endpoint identifier included in the header of a GTP-U data packet. The predetermined prefix may be any predetermined sequence of bits that defines a subnetwork of nodes included in the PGW, i.e. the second network gateway. The generated address may be an IPv6 address built by appending the TEID to the predetermined prefix.

[0011] The first data packet from the first network gateway is an IP based packet and may be received at the load balancer via an Internet Protocol (IP) Packet exchange (IPX) network or GPRS roaming exchange (GRX). For example, the load balancer may receive IP traffic from the IPX / GRX network in form of data packets according to the IPv4 protocol.

[0012] In an example of the first aspect, the first data packet according to a first protocol is an incoming packet and may further include a header indicating the source IP and the destination IP of the first data packet. The second data packet may be included in a UDP packet in a tunneling protocol format. The UDP packet may further include a UDP header indicating a source and a destination port.

[0013] The third data packet may be a packet resulting from repackaging, e.g. by the load balancer, the first (incoming) data packet to form an outgoing data packet. The first (incoming) and third (outgoing or repackaged) data packet may be formed according to the same communication protocol or according to different communication protocols.

[0014] The invention solves the problems mentioned above by employing a custom load balancer that is state-less by design, more appropriate for cloud-native deployments and repackages the incoming packet into an outgoing or repackaged packet including a newly generated destination identifier-dependent destination address. The custom load balancer may utilize separate communication protocols for incoming and outgoing data to dispatch the traffic among nodes. Instead of using any internal or external database or lookup table to map the destination identifier, such as a TEID, to an address of a specific node, such as for example a PGW-U node in the core network, the load balancer at least partially extracts the header of the incoming second data packet and converts the incoming first data packets, which are generated according to a first communication protocol, to the third data packet, which is generated according to a second communication protocol. The load balancer also constructs (builds or generates) an address of the target node based on the value of the extracted destination identifier, and accordingly forwards the resulting third data packet to the target node. The addresses of the target nodes may be preset, and the address constructed by the load balancer corresponds to one of the addresses of the nodes. Thus, the invention provides a method to load balance traffic by repacking the data packets, for example from IPv4 to IPv6, and distributing it to the target nodes, i.e. nodes of the second gateway like PGW or GGSN.

[0015] In some embodiments, the destination identifier is a tunnel endpoint identifier, TEID. In these embodiments the tunnel endpoint is directly related to the generated address to which the third data packet is transmitted.

[0016] In another embodiment, the predetermined prefix is a prefix common to all addresses according to the second communication protocol of nodes of the second network gateway. This has the technical effect that the nodes form a subnetwork and each of the nodes of the network gateway may be addressed by combining the predetermined prefix with further information like for instance the destination identifier. In general, the predetermined prefix may be any sufficiently long sequence of bits. For example, the predetermined prefix can be a sequence of 72 bits (i.e. 18 hexadecimal places). It can be arranged that this sequence of bits is the common prefix of all addresses of nodes of the second network gateway. In the case of IPv6 as the second communication protocol, this defines an IPv6 subnetwork of nodes like PGW or GGSN or any general GTP (or more specifically GTP-U) nodes.

[0017] In an embodiment, an address space according to the second communication protocol is larger than an address space according to the first communication protocol. This has the advantage that when the address space according to the first communication protocol is exhausted or close to exhaustion, the second communication protocol may still have plenty of free addresses and thus nodes of a second gateway may be assigned an individual or even a number of addresses according to the second communication protocol.

[0018] In another embodiment, combining the predetermined prefix and the destination identifier comprises concatenating the predetermined prefix and the destination identifier by appending the destination identifier to the predetermined prefix. This has the advantage that the destination identifier immediately follows the predetermined prefix in the generated address. Thus, routing of the third data packet can be done by applying a longest prefix match rule. In this way, data packets with the same destination identifier or destination identifiers differing only in the last few digits can be routed to the same gateway node.

[0019] In yet another embodiment, the first communication protocol is the internet protocol version 4, and the second communication protocol is the internet protocol version 6. In the case of IPv4 and IPv6 as first and second communication protocol, the address spaces of the first and second communication protocol are made up of 2A32 and 2A128 addresses, respectively. This is because IPv4 uses 32 bits addresses and IPv6 128 bits addresses. Thus, the address space according to the second communication protocol is 2A96 times as large as the address space of the first communication protocol in this example. This large factor allows to assign large ranges of addresses to individual nodes of the second network gateway since address space in IPv6 is not particularly limited.

[0020] The use of IP protocols has the additional advantage that the delivery of the IPv6 packets towards the designated target nodes is performed by the IP / Ethernet routing principles (FIB lookup, ARP, gateway). Thus, the load balancer is off-loading routing logic to an underlying IP router in this embodiment. All target nodes of the second network gateway may be assigned with a specific set or range of IPv6 addresses instead of one specific IPv6 address, thus enabling the target to receive all packets that are destined to an IPv6 address within the assigned address set or range.

[0021] The tunneling protocol, in some embodiments, is the GPRS tunneling protocol, GTP. More specifically, the tunneling protocol can be the GPRS tunneling protocol for user data tunneling, GTP-U.

[0022] The method may be applied to a 3G, 4G or 5G core network. In these embodiments, the first network gateway is a serving gateway in an Evolved Packet Core or a serving GPRS support node in a GPRS core network, or a User Plane Function or Session Management Function in a 5G Core Network.

[0023] As described above, the second network gateway may comprise a plurality of network nodes. An embodiment of the method according to the invention further comprises associating each of a plurality of nodes of a second network gateway with one of a plurality of predetermined sets and / or ranges of destination identifiers. The third data packet is transmitted, in this embodiment, from the load balancer to one of the plurality of nodes that is associated with a predetermined set and / or range of destination identifiers that includes the destination identifier from the header of the second data packet. This embodiment has the advantage that the load may be flexibly balanced between the nodes by choosing the set and / or ranges appropriately.

[0024] In a related embodiment, every node of the plurality of nodes is associated with a different predetermined set and / or range of destination identifiers and the predetermined sets and / or ranges of different nodes do not overlap. This has the advantage that the third data packet will only be transmitted to one of the nodes.

[0025] In another embodiment, the method further comprises transmitting, by the node to which the third data packet is transmitted, a fourth data packet in accordance with the first communication protocol comprising a fifth data packet in accordance with the tunneling protocol to the first network gateway. In particular, the fourth data packet may comprise the return traffic from the second gateway to the first gateway. The fifth data packet may also be according to the GTP-U tunneling protocol and the fifth data packet may be associated to a unidirectional GTP-U tunnel. This has the advantage that the node may respond to the network traffic received from the first network gateway. Accordingly, the fourth data packet constitutes return traffic, which according to this embodiment may be directed to the first gateway directly and without being handled by the load balancer.

[0026] When the method of the previous embodiments is applied to a 3G, 4G or 5G core network, a related embodiments provides that the second network gateway is a packet data network gateway in an Evolved Packet Core or a gateway GRPs support node in a GPRS core network, or a User Plane Function or Session Management Function in a 5G Core Network.

[0027] In yet another embodiment, the nodes are assigned to a user plane of the network traffic for handling user data transmitted using the tunneling protocol. This has the additional advantage that the method is compatible with control and user plane separation, which is commonly employed in core networks.

[0028] Another embodiment provides that the step of associating each of the plurality of nodes with one of the plurality of predetermined sets and / or ranges of destination identifiers comprises for each of the plurality of nodes, setting addresses of the node. The addresses are in accordance with the second communication protocol and are set to the addresses that can be generated by combining the predetermined prefix with one destination identifier of the predetermined set and / or range of destination identifiers to be associated with the node. This embodiment ensures that the transmission of the third data packet to the node which is associated with the respective destination identifier is automatically realized when transmitting the third data packet as intended by the second communication protocol. Thus, the routing of the data packet follows the conventions of the second communication protocol. In this embodiment, the transmission of the third data packet to the correct node associated with the destination identifier of the third data packet is achieved by setting the addresses of the respective nodes in accordance with the associated set and / or range of destination identifiers. For example, a node may be configured to receive all data packets according to the second communication protocol which are addressed to any address in an address space defined by a respective node prefix. A node prefix for each of the nodes is made up from the predetermined prefix concatenated with a range identifier. The predetermined prefix is the same for each node. The range identifier is different for every node. In one example, the predetermined prefix may be 72 bits long and the range identifier may be 8 bits long. In this case, one node receives every data packet addressed to a subnetwork defined by a node prefix which makes up the first 80 bits of the address according to the second communication protocol. In the embodiments in which the destination identifier is a 32-bit TEID, the range identifier indicates that the served TEID range is given by all TEIDs which have the range identifier as their first bits. Therefore, a node associated with the range identifier serves all TEIDs or the tunnels associated with the respective TEIDs which first bits correspond to the range identifier. The range identifier can for instance specify the first 8 bits of the served TEIDs. The node prefix (e.g., 80 bits) may accordingly be made up from the predetermined prefix concatenated (e.g., 72 bits) with the range identifier (e.g., 8 bits).

[0029] In another embodiment, the method comprises receiving, by one of the plurality of nodes, from a control plane node a signal to modify the predetermined set and / or range of destination identifiers associated with the node and updating the addresses of the node accordingly. This allows to dynamically control the load balancing by the control plane node and to assign certain ranges or even specific destination identifiers to the specific node whose set and / or range is modified. For example, the control plane node may reduce the range of identifiers handled by a specific node that is running close to its maximum capacity.

[0030] In a second aspect of the invention, a solution to the problem above is provided by a load balancer for a network element for handling data packet transmissions in a communication system. The load balancer is configured to receive, from a first network gateway, a first data packet in accordance with a first communication protocol. The first data packet encapsulates a second data packet according to a tunneling protocol, wherein the second data packet comprises a header including a destination identifier. The load balancer is further configured to extract the destination identifier from the second data packet and to generate an address by combining a predetermined prefix and the destination identifier. The generated address is in accordance with a second communication protocol. The load balancer is further configured to encapsulate the second data packet and the generated address in a third data packet according to the second communication protocol, wherein the generated address is the destination address of the third data packet.

[0031] In some embodiments of the second aspect of the invention, the network element is implemented as a communication device, e.g. a PGW or GGSN. Accordingly, the communication system may be a wireless or radio communication system, e.g. a GSM, UMTS, LTE and 5G NR radio network or a part thereof. In other embodiments, it is software implemented on a server that is part of the communication system. The network element may comprise the load balancer and the second gateway comprising a plurality of nodes.

[0032] In some embodiments of the load balancer, the destination identifier is a tunnel endpoint identifier, TEID. In another embodiment, the predetermined prefix is a prefix common to all addresses according to the second communication protocol of nodes of a second network gateway. In an embodiment, an address space according to the second communication protocol is larger than an address space according to the first communication protocol. In another embodiment of the load balancer, combining the predetermined prefix and the destination identifier comprises concatenating the predetermined prefix and the destination identifier by appending the destination identifier to the predetermined prefix. In yet another embodiment, the first communication protocol is the internet protocol version 4, and the second communication protocol is the internet protocol version 6. The tunneling protocol, in some embodiments of the load balancer, is the GPRS tunneling protocol, GTP. More specifically, the tunneling protocol can be the GPRS tunneling protocol for user data tunneling, GTP-U. In some embodiments, the first network gateway is a serving gateway in an Evolved Packet Core or a serving GPRS support node in a GPRS core network, or a User Plane Function or Session Management Function in a 5G Core Network.

[0033] Thus, the load balancer, in an embodiment, is configured to receive an IPv4 packet, which encapsulates a GTP-U packet The GTP-U packet comprises a header including a TEID. The load balancer extracts the TEID and generates an IPv6 address by combining a predetermined prefix and the TEID. This is done by concatenating the predetermined prefix with the TEID in this order. If the result is shorter than a 128 bits IPv6 address, trailing zeros are added until the address is 128 bits long. The load balancer then encapsulates the received GTP-U packet into a new IPv6 packet, wherein the generated address is the destination address of the IPv6 packet.

[0034] Further, each node of the gateway may be configured to serve a distinct address space of the IPv6 address space identified by the range identifier. Thus, the load balancer distributes the GTP tunnel connections among the nodes of the gateway. In other words, the packets are distributed among the nodes based on the TEID comprised in the header of the encapsulated GTP-U packet.

[0035] The advantages of these embodiments are the same as outlined for the method according to the first aspect. The load balancer is state-less by design and applicable for cloud-native developments. By using appropriate protocols, the problem of address space exhaustion can be overcome while still being able to receive traffic using the IPv4 protocol. The load balancing may be flexibly adjustable within a subnetwork of nodes.

[0036] In other embodiments the load balancer according to the second aspect of the invention is configured to implement the method according to the embodiments of the first aspect of the invention as described above.

[0037] In a third aspect of the invention, a network element for handling data packet transmissions in a communication system is provided, wherein the network element comprises a load balancer according to the second aspect of the invention. The network element may further comprise a plurality of nodes of a second network gateway, e.g., a PGW or GGSN.

[0038] In an embodiment of the third aspect of the invention, the network element comprises a plurality of nodes of a second network gateway, wherein each of the plurality of nodes is associated with one of a plurality of predetermined sets and / or ranges of destination identifiers. The load balancer is further configured to transmit the third data packet to one of the plurality of nodes that is associated with a predetermined set and / or range of destination identifiers that includes the destination identifier from the header of the second data packet.

[0039] In a related embodiment, every node of the plurality of nodes is associated with a different predetermined set and / or range of destination identifiers and the predetermined sets and / or ranges of different nodes do not overlap. In another related embodiment, the second network gateway is a packet data network gateway in an Evolved Packet Core or a gateway GRPs support node in a GPRS core network, or a User Plane Function or Session Management Function in a 5G Core Network

[0040] In another embodiment of the network element, the network element is further configured to transmit, using the node to which the third data packet is transmitted, a fourth data packet in accordance with the first communication protocol comprising a fifth data packet in accordance with the tunneling protocol to the first network gateway. In yet another embodiment, the nodes are assigned to a user plane of the network traffic for handling user data transmitted using the tunneling protocol.

[0041] Another embodiment provides that the addresses of each of the plurality of nodes are set when they are associated to one of the plurality of predetermined sets and / or ranges of destination identifiers. The addresses are in accordance with the second communication protocol and are set to the addresses that can be generated by combining the predetermined prefix with one destination identifier of the predetermined set and / or range of destination identifiers to be associated with the node. This embodiment directly connects the addresses of the nodes to the associated destination identifiers. They are set to exactly the addresses that the load balancer would create from the predetermined prefix and the destination identifiers associated with this node. As explained in relation to the first aspect of the invention, this embodiment ensures that the transmission of the third data packet to the node which is associated with the respective destination identifier is automatically realized when the third data packet is transmitted as intended by the second communication protocol. Thus, the routing of the data packet follows the conventions of the second communication protocol, e.g. the IPv6 protocol. In the example given above, the node is configured to receive all data packets addressed to a subnetwork identified by a node prefix that can for example be 80 bits long. It is made up from the predetermined prefix, which is identical for all nodes, and a node-specific range identifier. The predetermined prefix may for instance be 72 bits long and the range identifier may be 8 bits long.

[0042] In some embodiments, the network element further comprises at least one control plane node. The network element is further configured to receive, by one of the plurality of nodes, from the control plane node a signal to modify the predetermined set and / or range of destination identifiers associated with the node and to update the addresses of the node accordingly. This embodiment allows to adjust the load balancing dynamically. In the previously given example, this step comprises updating the range identifier of the nodes and thereby updating the addresses of the node. A fourth aspect of the invention provides a computer program product comprising instructions which, when executed by one or more processors, cause the one or more processors to perform the method steps as described in the first aspect of the invention and its embodiments above. As indicated above the network element according to a third aspect of the invention may be software implemented on a server that is part of the communication system. In these cases, the computer program product according to the fourth aspect may be configured for running on the network element.

[0043] A further aspect of the invention provides a non-transitory computer readable medium comprising program instructions that, when executed by one or more processors, cause the one or more processors to perform the method steps as described in the first aspect of the invention and its embodiments above.

[0044] The above-mentioned and features of the invention and the embodiments are also illustrated by the following description with reference to the figures.

[0045] Fig. 1 shows the connection between the SGSN / SGW and the GGSN / PGW in the control and user plane as well as the respective interfaces and protocols as is known in the prior art.

[0046] Fig. 2 shows another configuration, in which both gateways comprise dedicated control plane and user plane nodes.

[0047] Fig. 3 shows an example of state-full load balancing by a load balancer maintaining a list of the respective tunnels in operation.

[0048] Fig. 4 shows an architecture, in which a state-less load balancer is employed to serve GTP- U worker nodes.

[0049] Fig. 5 illustrates an embodiment of a method according to the invention carried out by the load balancer.

[0050] Fig. 6 illustrates the process of the address generation from a predetermined prefix and a destination identifier. In the following as well as in Figs. 5 and 6, the operator « n denotes a left arithmetic shift by n bits, vertical bar | denotes a bitwise OR operation, the double colon :: represents consecutive blocks of zeros and the slash I at the end of an IP address indicates the length of the network prefix in bits. The latter notation is, for instance, used for the same purpose in IPv6. The prefix Ox of a number indicates that the following number is written in its hexadecimal representation.

[0051] Fig. 1 illustrates the basic principle of communication between a first gateway 1 and a second gateway 2 using the GTP-C / U (GPRS Tunneling Protocol - Control / User Plane) as, for example, defined in 3GPP TS 29.281 . As described in relation to the background of the invention, the two gateways may be an SGW (Serving Gateway) and a PGW (Packet Gateway), eNodeB in EPS (Evolved Packet System) or an SGSN (Serving GPRS Support Node) and a GGSN (Gateway GPRS Support Node) in a GPRS core network. The GTP Protocol is also used in 5G networks, for instance on the user plane on the N9 (UPF to UPF) and N3 UPF to (eNodeB, gNodeB, or Access Network) reference points. Therefore, the two gateways may also be either one of these gateways.

[0052] Throughout the description, as already indicated before, the terms first network gateway 1 and first gateway 1 are interchangeably used to indicate the same network entity. Same holds also true for the terms second network gateway 2 and second gateway 2.

[0053] As shown in Fig. 1 , the GTP-C connection is bidirectional, while the GTP-U tunnel is unidirectional. Therefore, the gateways require two separate GTP-U tunnels for uplink and downlink respectively, while the set-up and management of tunnels in the GTP-C plane is done with just one GTP-C tunnel. Figure 1 also shows the possible interfaces via which the communication between the first gateway 1 and the second gateway 2 may occur. For instance, the Gn interface is the interface between the SGSN and the GGSN in the case that they exist within the same mobile network. If the SGSN and the GGSN are in different mobile networks, the interface between the two gateways is the Gp interface instead. The S5 and S8 interfaces, which are also shown as possible examples, are interfaces of the LTE evolved packet core between the SGW and the PGW. In a 5G Core Network the N9 interface connects 2 UPFs, for instance an Intermediate User Plane Function (l-UPF) and an UPF terminating the N6 interface of a Protocol Data Unit, PDU, session (also indicated as UPF Session Anchor or PDU Session Anchor, PSA).

[0054] Fig. 2 still shows a setup of example gateways, such as the PGW and SGW. In this case, the control and user plane are separated also internally within each of the two gateways. Accordingly, the first gateway 1 (SGW in Fig. 2) and the second gateway 2 (PGW in Fig. 2) each comprise a respective dedicated control plane node, SGW-C 23 and PGW-C 24. In addition, a plurality of user plane nodes, SGW-U 21 and PGW-U 22, may be used for handling the user plane traffic. The protocols used for communication and the respective interfaces are the same in this separated architecture as in the monolith architecture shown in Fig. 1 . In Fig. 2, the internal connections between the control plane and the user plane of the SGW 1 and the PGW 2 are labelled Sxa and Sxb, respectively. These are the new interfaces required for the CUPS architecture. Via these interfaces, the required information like for instance TEIDs of a GTP-U tunnel to initiate a new tunnel are communicated from the control plane to the user plane.

[0055] Fig. 3 is an illustration of a state-full GTP-U load balancer. Fig. 3 shows one SGW-U node 21 that maintains three GTP-U tunnels. The GTP-U tunnel is state-full and end-to-end with the 3-value tuple of {Destination IP; source IP; TEID} to separate and isolate encapsulated traffic transferred between the nodes. The three tunnels are therefore associated with separate TEIDs labelled TEID A, TEID B and TEID C. In Fig. 3, a separate device is used as a state-full load balancer 31 . It receives all the traffic from a single SGW-U node 21 and distributes it to a plurality of PGW-U nodes 22. In the case illustrated in Fig. 3, these are three distinct PGW-U nodes 22. One for each of the three GTP-U tunnels. In order to ensure that every PGW-U node 22 receives all the traffic associated with the respective tunnel, the state-full load balancer 31 needs to maintain a database in form of a table, which lists the TEIDs and the assigned PGW-U nodes 22. When a new tunnel is established via the control plane, the control plane needs to update this table of the state-full load balancer 31 to ensure correct routing of the data packets associated with the new tunnel. Only by referring to the table, the state-full load balancer 31 can ensure that each GTP-U packet 52 is forwarded to the right PGW-U node 22 that is maintaining the traffic in this tunnel. Thus, the state-full load balancer 31 is necessarily state-full in this setup. This state-full approach causes a number of limitations, particularly when deploying cloud-native functions. Typically, the traffic between the GTP-U nodes 22 is transmitted via the IPv4 protocol. Therefore, each new GTP-U node requires a public IPv4 address. This is for instance the case when the connection is established by a Mobile Network Operator (MNO) and a Mobile Virtual Network Operator (MVNO). In this case the traffic between a first gateway 1 , e.g., the SGW, deployed by the MNO, and a second gateway 2 deployed by the MVNO, is delivered through the Internet Protocol Packet exchange (IPX) network or GPRS Roaming exchange (GRX) network (in short IPX / GRX) 42. IPX / GPX carriers 42 only support IPv4 packets, so that in IPX / GPX IPv4 is solely used. Therefore, each node, such as the SGW and PGW, connected and / or exposed to the IPX / GPX 42 should have a unique IPv4 address. However, this is a scarce resource which limits the number of nodes 22 that can be used. Furthermore, the 3GPP standards do not define any mechanisms or procedures for dynamically distributing or re-routing GTP-U tunnels seamlessly between different PGW-U nodes 22, for example if a PGW GTP-U node 22 fails. In the scenario of Fig. 3, the different PGW-U nodes 22 are also not hidden behind a common load balancer but are perceived as separate entities by the SGW-U node 21 which would receive return traffic from different nodes 22. Finally, if the state-full load balancer 31 fails in this scenario, all the GTP-U tunnels are necessarily disrupted even when a backup load balancer is provided. This is because the backup would not have access to the states maintained by the state-full load balancer 31 previously in charge and the full session information would have to be restored via the control plane.

[0056] Fig. 4 shows a high-level architecture of a solution improving the state-full solution described in Fig. 3, for instance but not only to address the problem of scarcity of resources and improved flexibility and scalability. In the configuration of Fig. 4 a load balancer 41 serves as a single entry point to a plurality of GTP-U worker nodes 22 which may be comprised in a network gateway 2. This is an example of the second network gateway 2. The (second) network gateway 2 may, for example, be implemented as a PGW or GGSN, a GTP Proxy, a UPF. The load balancer 41 may also be part of the network gateway 2, such as a PGW or GGSN, a GTP Proxy, a UPF. Fig. 4 shows three GTP-U worker nodes 22, which are in the following just referred to as nodes 22. While Fig. 4 shows a configuration including three nodes 22, the number of nodes 22 hidden behind the load balancer 31 is not limited to three and may be scaled up or down based on service requirements and available resources. The first gateway 1 (e.g., SGW / SGSN) is not shown in Fig. 4. Instead, the Internet Protocol (IP) Packet exchange (IPX) network or GPRS roaming exchange (GRX) network 42 is shown in Fig. 4 as data exchange models between the first gateway 1 and the second gateway 2. The IPX or GRX 42 is the network via which the two gateways, like PGW and SGW or SGSN and GGSN, may exchange IP based data packets in this example. Other kinds of networks may also be used for transmitting the data packets between the two gateways. Each of the connections between the nodes 22, the load balancer 41 and the network 42 are indicated by an arrow also including the direction of the transmitted data packet. Each arrow is further labelled with the respective protocol stack. For instance, the IPX / GRX network 42 communicates with the load balancer 41 using the IPv4 protocol. This encapsulates a UDP packet, including the GTP-U packet. The depicted protocol stack may not be complete. The payload of the GTP-U packet may for instance be an IPv4 or IPv6 packet. These are illustrative examples of the respective protocol stacks and payloads. The invention is not limited to these specific types of stacks or payloads.

[0057] As can be appreciated from Fig. 4, the load balancer 41 receives all traffic from the IPX / GRX network 42 in form of data packets 51 according to the IPv4 protocol. The IPv4 packet 51 encapsulates a data packet 52 according to a tunneling protocol, which may be the GTP-U protocol. The load balancer 41 transmits data packets 53 to the GTP-U nodes according to the IPv6 protocol. Also, these data packets 53 encapsulate a data packet 52 according to the GTP-U tunneling protocol. Thus, the load balancer 41 repackages the incoming traffic to form an IPv6 packet 53 from an IPv4 packet 51 .

[0058] The term “repackage” is intended here as any operation on an incoming package 51 extracting information from the incoming package 51 , processing the extracted information, and using the processed information to generate a new packet 53, or in other word repackage the processed information in a new packet 53. In the example of figure 4 and following features, reference is made to different types of packets, specifically IPv4 and IPv6 packets. However, the same format (e.g., IPv6) for the incoming and processed (repackaged) packet, or alternatively different formats other than IPv4 and IPv6 for incoming and repackaged packet may be used.

[0059] The load balancer 41 can be built as a computation device equipped with the according hardware to perform the functions described herein. In particular, the load balancer 41 may comprise one or more communication units for receiving and transmitting the respective data packets. It may further include control or processing units carrying out the computational steps as described herein. A memory unit of the load balancer 41 may store the related instructions including a constant predetermined prefix as described below. The load balancer 41 may be implemented as part of the second gateway 2 or a core network element having the function of controlling data traffic within the core network.

[0060] Fig. 4 also illustrates traffic returned from the GTP-U nodes 22 to the IPX / GRX network 42. This traffic is transmitted in accordance with the IPv4 protocol, i.e. , the one also used between IPX / GRX 42 and the load balancer 41 . Since these data packets are also related to a GTP-U tunnel they also encapsulate data packets according to the GTP-U.

[0061] Fig. 5 illustrates how the repacking by the load balancer 41 is carried out. On the left-hand side of Fig. 5 the first data packet 51 is shown, in this example an IPv4 data packet. This first data packet 51 includes a header indicating the source IP and the destination IP of the IPv4 packet. Each IPv4 address is 32 bits long and can be represented by 4 decimal numbers ranging from 0 to 255 separated by a full stop. The first data packet 51 may comprise a UDP data packet with a UDP header indicating a source and a destination port. Moreover, the UDP packet comprises a second data packet 52 in accordance with a tunneling protocol. In Fig. 5 this is the GTP-U protocol. The second data packet 52 comprises a header indicating a destination identifier, which is a TEID in this case. The TEID is 32 bits long and may be represented by 8 hexadecimal places. The GTP-U data packet 52 also comprises a payload, which can be for instance an IPv4 or IPv6 data packet or any other kind of payload.

[0062] The logic applied by the load balancer 41 is illustrated in the center of Fig. 5. Accordingly, the load balancer receives at step S1 the incoming IPv4 packet 51 and extracts at step S3 the TEID. This may require a preceding step S2 of at least partially parsing the received data packet 51 , for instance parsing the GTP-U header, and reading the TEID from the header. Once the TEID, or any other destination identifier, is received, the load balancer 41 generates at step S4 an IPv6 destination IP address. This may comprise concatenating a predetermined prefix and the destination identifier, for example the TEID, by appending the destination identifier to the predetermined prefix. In the example shown in Fig. 5, the predetermined prefix has a length of 72 bits represented by 18 hexadecimal places. However, any other number of bits may be used for the predetermined prefix and 72 bits is only chosen as an illustrative example. The load balancer 41 uses the same predetermined prefix every time an IPv6 address is generated at step S4.

[0063] The predetermined prefix may be chosen such that it is in the range of an internal network of the network element. This internal network may comprise all IP devices of the network element to which an IP address is assigned. This internal network may include all GTP-U nodes 22 of the network element and the load balancer 41 . Furthermore, the predetermined prefix is the common prefix of the respective IPv6 addresses of the GTP-U nodes 22. The predetermined prefix thus identifies a subnetwork formed by the plurality of nodes 22 of the second gateway 2, e.g., the PGW or GGSN.

[0064] IPv6 addresses are 128 bits long. The concatenation of the predetermined prefix (72 bits) and the TEID (32 bits) in the example of the figures is only 104 bits long. In cases where the concatenation is shorter than the length of an IPv6 address (128 bits), the load balancer 41 may fill the remaining places with trailing zeros. In such cases, the step S4 of generating the address also comprises adding trailing zeros to generate an address according to the IPv6 protocol. In Fig. 5, these are 6 trailing zeros in the hexadecimal representation of the generated IPv6 address. In other deployments, the concatenation of the predetermined prefix and the TEID already comprises the number of bits of an IPv6 address, i.e., 128 bits, and no trailing zeros are added in the address generation step S4. In either way, a full IPv6 address is generated by the load balancer 41 based on the TEID of the incoming data packet 51 and the predetermined prefix which is independent of the received data packet 51 .

[0065] Optionally, the load balancer 41 may also calculate an IPv6 source IP address from the IPv4 source IP address included in the header of the received IPv4 packet 51 . This can be done in the conventional way of mapping IPv4 addresses to IPv6 addresses as described in RFC 3056. This is called the “6to4” transition mechanism, in which IPv4 addresses are mapped onto a specifically allocated 2002: / 16 IPv6 prefix.

[0066] In the last step S5 shown in center of Fig. 5, the load balancer 41 encapsulates the received GTP-U packet 52 in an IPv6 data packet 53 and sets the calculated IPv6 address as the destination IP address in the header of the generated IPv6 data packet 53. The repacking may involve removing the IPv4 header of the received packet 51 and replacing it with an IPv6 header. In another example implementation, the repacking may involve encapsulating the entire incoming first data packet 51 into the IPv6 data packet 53 as described below. In both cases the generated IPv6 data packet will also encapsulate the second data packet, for example as a GTP-U packet 52. If the load balancer 41 has also calculated an IPv6 source IP this is also included in the header of the resulting IPv6 data packet 53. The result is illustrated on the right-hand side of Fig. 5. An IPv6 data packet 53 is generated with the destination IP as generated from the TEID of the received packet 51 and the predetermined prefix. The IPv6 packet 53 includes the same UDP packet including the same GTP-U packet 52 and the same payload as the first data packet 51 . Accordingly, the load balancer 41 is configured to repack an IPv4 packet 51 including a GTP-U packet 52 into an IPv6 packet 53 including the same GTP-U packet 52 and determining the destination IP address from the TEID of the GTP-U packet 52. In order carry out this task and operate as intended, the load balancer 41 is only provisioned with the predetermined prefix. No information or session awareness other than the predetermined prefix is maintained.

[0067] The second data packet 52, i.e. the GTP-U packet in Fig. 5, may include, as an example, an IPv4 packet with IPv4 header and IPv4 as a payload. In alternative realizations, the second data packet 52 encapsulated in the first data packet 51 may include an IPv6 packet with IPv6 header and an IPv6 payload. Other payloads may also additionally or alternatively be included in the second data packet 52. After repacking the received first data packet 51 to form a third data packet 53 (repack- aged / outgoing packet) in and by the load balancer 41 , the load balancer 41 transmits the repackaged data packet 53 to one of the nodes 22 indicated by the generated IPv6 address. This can be realized as illustrated in Fig. 6. The left half of Fig. 6 illustrates the same functionality as Fig. 5, where the details not relevant for the explanation of the basic working principle of the load balancer 41 were omitted for simplicity. The incoming IPv4 packet 51 is shown on the left hand side of Fig.6. It includes a TEID of 32 bits length (a0:0000:01 in HEX format). The load balancer 41 extracts at steps S2 and S3 the TEID and generates at step S4 an IPv6 address out of a predetermined prefix stored in the load balancer 41 (ffff :ffff :ffff :ffff :ff in HEX format), the TEID and trailing zeros. This process and the resulting address of 128 bits length (ffff :ffff :ffff :ffff :ffaO:OOOO:O100:0000) is shown in the table in the top left of Fig. 6. The detailed calculation of the destination IPv6 address is shown in Fig. 5 as step S4. Accordingly, the load balancer first performs an arithmetic shift by 24 bits of the TEID, resulting in a0:0000:0100:0000 in HEX format in the shown example. The number of bits of the bit shift depends in general on the length of the TEID and the predetermined prefix and the resulting number of required trailing zeros. The number of bits of the bit shift may have different values in various configurations. The load balancer subsequently performs a bitwise OR operation of the shifted TEID with the predetermined IPv6 prefix. In the shown slash notation, the predetermined prefix written as ffff :ffff :ffff :ffff :ff : : / 72 is understood as a 72 bit prefix to an IPv6 address, which is 128 bits in length. Accordingly, the result of the logic OR operation is the concatenation of the prefix with the shifted TEID, i.e. ffff :ffff :ffff :ffff :ffaO:OOOO:O100:0000 in the illustrated example. The outgoing IPv6 packet 52 transmitted by the load balancer 41 includes the address generated in the above described manner as its destination address.

[0068] As also illustrated in Fig. 6, the GTP-U nodes 22 are configured to form an IPv6 subnetwork to which the IPv6 packet 53 is transmitted. The subnetwork is identified by the predetermined prefix, which is the common prefix of the respective IPv6 addresses of the GTP-U nodes 22. By building up the subnetwork of the GTP-U nodes 22 in this way, each GTP-U node 22 can be hidden behind the load balancer 41 while serving its designated TEID space. The delivery of the generated IPv6 packet 53 towards the designated GTP-U node 22 can be performed via the IP / Ethernet routing principles (FIB lookup, ARP, gateway). This is illustrated in the bottom center of Fig. 6. The longest prefix match rule is applied to route the IPv6 packet 53 to the designated GTP-U node 22. This means that the IPv6 packet 53 that is transmitted by the load balancer 41 is routed to the GTP-U node 22 whose IPv6 address has the longest matching prefix with the destination address of the IPv6 packet 53. In the example in Fig. 6, the GTP-U node #1 has the longest matching prefix with the IPv6 destination address of the data packet 53 transmitted by the load balancer 41 . Thus, the GTP-U node #1 receives the data packet 53 for further processing. Which GTP-U node 22 receives the data packet 53 transmitted by the load balancer 41 therefore depends on the TEID included in the GTP-U header of the respective data packet 52.

[0069] In this manner, for a given TEID range additional GTP-U nodes 22 can be added to the pool, or an existing one can be shut-down for maintenance or replaced without affecting the working of the load balancer 41 . As long as the additional or replacement GTP-U node 22 is given the correct TEID range, incoming packets can be correctly routed without the need of tearing down connections and performing reconnection that might lead to service degradation and impair customer experience.

[0070] By generating IPv6 addresses that depend on the respective TEID, the load balancer 41 is essentially off-loading the routing logic to an underlying IP router. Different scenarios for the IP routing may be considered. For example, the GTP-U nodes 22 may belong to the same subnet of the load balancer 41 . In this case, if the load balancer 41 knows already the MAC address of the GTP-U node 22, the load balancer 41 may transmit the packet 53 to the GTP-U node 22 directly using the generated IPv6 address. In case the MAC address of the GTP-U node 22 is unknown to the load balancer 41 , the latter will get the MAC address from the IP router and then route the packet to the correct GTP-U node 22. Alternatively, the GTP-U nodes 22 may belong to a different subnet than the subnet to which the load balancer 41 belongs. In this case, forwarding of the packet 53 to the correct GTP- U node 22 will be done through the IP router according to a routing scheme, like for instance the longest prefix match routing scheme. The IP router is not shown in the figure for simplicity.

[0071] All GTP-U nodes 22 are assigned an IPv6 node prefix and not only one specific IPv6 address. The node prefix is longer than the predetermined prefix by the length of a range identifier. The GTP-U nodes 22 are configured to receive all packets 53 that are destined to IPv6 addresses with the assigned IPv6 node prefix. The illustrated example in Figs. 5 and 6 uses a predetermined prefix that is 72 bits long (e.g., ffff :ffff :ffff :ffff :ff in HEX format). Each GTP-U node 22 (or GTP-U worker node) within the subnetwork is further identified by a number of additional bits of its IP address prefix. This is referred to as the range identifier (ID) or TEID Range Identifier (ID). The range identifier indicates a TEID range served by the specific GTP-U worker 22. In the example described above and shown in Fig. 6, the TEID range is indicated by 8 bits, i.e. , two further hexadecimal places following the 72-Bits predetermined prefix. Each node 22 serves at least all TEIDs which start with these 8 bits. As an example, the GTP-U node #1 of figure 6 may serve the TEID range spanning the values OxaOOOOOOO to OxaOffffff. Based on the longest prefix match the repackaged packet 53 including in its prefix the TEID a000:0001 will be routed to the GTP-U node 22 having as range ID OxaO.

[0072] According to this approach up to 256 separate GTP-U nodes 22 and associated TEID ranges could be used in this example because 256 different range identifiers can be represented by 8 bits. An 80 bits node prefix specific to a GTP-U node 22 is thus generated by concatenating the common predetermined prefix of 72 bits and the additional 8 bits range identifier in this order. This is illustrated in the top right of Fig. 6. Accordingly, the IPv6 addresses of a GTP-U node 22 are given by all IPv6 addresses which start with the node prefix made up of the predetermined prefix of 72-bit length and the additional 8 bits indicating the served TEID range. In this configuration, the node 22 receives all data packets 53 addressed to a subnetwork identified by the node 22 prefix which is made up from these 80 bits.

[0073] In the example of GTP-U node #1 in Fig. 6, the 80 bits node prefix is given by ffff :ffff :ffff :ffff :ffaO in HEX format. The TEIDs are grouped in this case into 256 ranges (0x00000000 to OxOOffffff; 0x01000000 to 0x01 ffffff ; ....; OxffOOOOOO to Oxffffffff) corresponding to the 256 range IDs given by the possible combination of the 8-bit part of the prefix. The GTP-U node#1 serves the range of TEIDs OxaOOOOOOO to OxaOffffff]. The node #1 in this specific embodiment is therefore configured to receive all data packets addressed to a subnetwork defined by the 780 prefix ffff :ffff :ffff :ffff :ffaO, which would give the longest prefix match.

[0074] Figure 6 shows an example with only three GTP-U nodes 22 for simplicity, but different associations between GTP-U node number, TEID range and TEID range ID can also be chosen without departing from the principles underlying the invention. Following table illustrates the routing rule described above applied to a different association between TEID ranges and GTP-U nodes 22:

[0075] The length of the TEID range identifier may be chosen as appropriate for the given application. For example in networks with an extremely large amount of traffic, it may be desirable to use more than 256 nodes. In this case, a longer TEID range identifier may be used to identify the TEID range served by each node 22. A longer TEID range identifier corresponds to a larger possible number of nodes and a smaller TEID range served by each node. If, on the other hand, the load should be balanced between fewer nodes, a shorter TEID range identifier may be sufficient.

[0076] By this method, routing of the repackaged IPv6 packet 53 can be done within an IPv6 network by referring to the range ID assigned to the GTP-U nodes 22 and based on the longest prefix match without the need of referring to a fixed association between range ID and TEID ranges stored in a lookup table.

[0077] The scheme described above with reference to Figures 5 and 6 is only a possible implementation example. In particular, it is not necessary that each node 22 serves a continuous range of TEID ranges. Instead, some or all nodes 22 may serve more a plurality of ranges that are identified by a plurality of range identifiers. The respective ranges may be consecutive or not. For example both range identifiers aO and cO may be associated with the same GTP-U worker node. The node associated with these two TEID range identifiers would then receive all GTP-U packets with a TEID identifier either in the range of a0:00:00:00 to aO:ff:ff:ff or in the range of c0:00:00:00 to cO:ff:ff:ff. Of course, any kind of combinations of range identifiers associated with a plurality of nodes 22 can be chosen. This allows even more freedom in distributing the TEIDs among the GTP-U nodes 22.

[0078] In the proposed solution for load balancing GTP-U traffic, the GTP-C node 24 may communicate with the selected GTP-U node 22 and request the assignment of TEIDs before starting to set up the GTP-U tunnels. However, the state-less load balancer is not restricted to this particular implementation and there are multiple ways how GTP-C node 24 and GTP- U nodes 22 could communicate and manage the TEID space assigned to each of the nodes Referring again to Fig. 4, the GTP-U nodes 22 may also deal with return traffic from the second 2 to the first gateway 1 . In this case, the “Direct Server Response” approach may be applied. This approach includes that the GTP-U nodes 22 send return traffic directly to the first gateway 1 via the respective IP network 42 (e.g. IPX or GRX). This may be done by transmitting IPv4 packets but setting the source IPv4 address of the outgoing IPv4 packets to the IPv4 address of the load balancer 41 . In this way, the nodes 22 remain completely hidden behind the load balancer 41 . To the first gateway 1 , the communication does not seem any different to one with a single GTP-U node 22.

Claims

Claims1. A method for load balancing data traffic in a communication system, the method comprising receiving (S1 ), at a load balancer (41 ), a first data packet (51 ) from a first network gateway (1 ) in accordance with a first communication protocol, the first data packet (51 ) encapsulating a second data packet (52) according to a tunneling protocol, wherein the second data packet (52) comprises a header including a destination identifier; extracting (S2, S3), by the load balancer (41 ), the destination identifier from the second data packet (52); generating (S4), by the load balancer, an address by combining a predetermined prefix and the destination identifier, wherein the generated address is in accordance with a second communication protocol; encapsulating (S5), by the load balancer (41 ), the second data packet (52) and the generated address in a third data packet (53) according to the second communication protocol, the generated address being the destination address of the third data packet (53); and transmitting, by the load balancer (41 ), the third data packet (53) in accordance with the second communication protocol to a node (22) of a second network gateway (2) indicated by the generated address.

2. The method according to claim 1 , wherein the destination identifier is a tunnel endpoint identifier, TEID.

3. The method according to any of the previous claims, wherein the predetermined prefix is a prefix common to all addresses according to the second communication protocol of nodes (22) of the second network gateway (2).

4. The method according to any of the previous claims, wherein an address space according to the second communication protocol is larger than an address space according to the first communication protocol.

5. The method according to any of the preceding claims, wherein combining the predetermined prefix and the destination identifier comprises concatenating the predetermined prefix and the destination identifier by appending the destination identifier to the predetermined prefix.

6. The method according to one of the preceding claims, wherein the first communication protocol is the internet protocol version 4, and the second communication protocol is the internet protocol version 6.

7. The method according to any of the preceding claims, wherein the tunneling protocol is the GPRS tunneling protocol, GTP.

8. The method according to one of claims 1 to 6, wherein the tunneling protocol is the GPRS tunneling protocol for user data tunneling, GTP-U.

9. The method according to any of the preceding claims, wherein the first network gateway (1 ) is a serving gateway in an Evolved Packet Core or a serving GPRS support node in a GPRS core network, or a User Plane Function or Session Management Function in a 5G Core Network.

10. The method according to any of the previous claims further comprising associating each of a plurality of nodes (22) of a second network gateway (2) with one of a plurality of predetermined sets and / or ranges of destination identifiers; wherein the third data packet (53) is transmitted from the load balancer (41 ) to one of the plurality of nodes (22) that is associated with a predetermined set and / or range of destination identifiers that includes the destination identifier from the header of the second data packet (52).11 . The method according to claim 10, wherein every node (22) of the plurality of nodes (22) is associated with a different predetermined set and / or range of destination identifiers and the predetermined sets and / or ranges of different nodes (22) do not overlap.

12. The method according to one of claims 10 or 11 , further comprising transmitting, by the node (22) to which the third data packet (53) is transmitted, a fourth data packet in accordance with the first communication protocol comprising a fifth data packet in accordance with the tunneling protocol to the first network gateway (1 ).

13. The method according to one of claims 10 to 12, wherein the second network gateway (2) is a packet data network gateway in an Evolved Packet Core or a gateway GRPs support node in a GPRS core network, or a User Plane Function or Session Management Function in a 5G Core Network.

14. The method according to one of claims 10 to 13, wherein the nodes (22) are assigned to a user plane of the network traffic for handling user data transmitted using the tunneling protocol.

15. The method according to one of claims 10 to 14, wherein the step of associating each of the plurality of nodes (22) with one of the plurality of predetermined sets and / or ranges of destination identifiers comprises for each of the plurality of nodes (22), setting addresses of the node (22), which are addresses in accordance with the second communication protocol, to the addresses that can be generated by combining the predetermined prefix with one destination identifier of the predetermined set and / or range of destination identifiers to be associated with the node (22).

16. The method according to claim 15 further comprising receiving, by one of the plurality of nodes (22), from a control plane node (24) a signal to modify the predetermined set and / or range of destination identifiers associated with the node (22) and updating the addresses of the node (22) accordingly.

17. A load balancer (41 ) for a network element for handling data packet transmissions in a communication system, wherein the load balancer (41 ) is configured to: receive (S1 ), from a first network gateway (1 ), a first data packet (51 ) in accordance with a first communication protocol, the first data packet (51 ) encapsulating a second data packet (52) according to a tunneling protocol, wherein the second data packet (52) comprises a header including a destination identifier; extract (S2, S3) the destination identifier from the second data packet (52), generate (S4) an address by combining a predetermined prefix and the destination identifier, wherein the generated address is in accordance with a second communication protocol, and encapsulate (S5) the second data packet (52) and the generated address in a third data packet (53) according to the second communication protocol, the generated address being the destination address of the third data packet (53), transmit the third data packet in accordance with the second communication protocol to a node (22) of a second network gateway (2) indicated by the generated address.

18. A network element for handling data packet transmissions in a communication system, wherein the network element comprises the load balancer (41 ) according to claim 17.

19. The network element according to claim 18, further comprising a plurality of nodes (22) of a second network gateway (2), wherein each of the plurality of nodes (22) is associated with one of a plurality of predetermined sets and / or ranges of destination identifiers; wherein the load balancer (41 ) is configured to transmit the third data packet (53) to one of the plurality of nodes (22) that is associated with a predetermined set and / or range of destination identifiers that includes the destination identifier from the header of the second data packet (52).

20. A computer program product comprising instructions which, when executed by a processor, cause the processor to perform the method according to any of claims 1 to 16.

Images