Stateless GTP-C Proxy Message Processing

Abstract

A proxy device for a wireless communication system, comprising: a plurality of nodes for providing a plurality of connections between an ingress gateway and an egress gateway; a first load balancer configured to process incoming traffic from the ingress gateway; and a second load balancer configured to process incoming traffic from the egress gateway, wherein the first load balancer is configured to receive a message from the ingress gateway and select a node from the plurality of nodes; and wherein the node is configured, in response to being selected by the load balancer, to retrieve state information related to a previous state from a database, replace the IP address of the ingress gateway with the IP address of the second load balancer in the received message, and send the received message including the IP address of the second load balancer to the egress gateway.

Description

[Technical Field]

[0001] The present invention relates to a proxy device for the GTP protocol. The GTP protocol and mobile core architecture are standardized by 3GPP (3rd Generation Partnership Project). Proxy devices between gateways are not standardized by 3GPP. However, proxy devices are known, and for further information see, for example, European Patent Application EP 20 206 283.2. [Background technology]

[0002] The GPRS Tunneling Protocol (GTP) corresponds to an IP-based communication protocol used to support general packet radio communication systems within networks based on the Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), and LTE (Long Term Evolution) systems. This divides GTP into several protocols depending on the plane in which it is provided: in the control plane, GTP Control (GTP-C) is used for signaling; in the user plane, GTP User (GTP-U) is provided for user data transport.

[0003] Additionally, there exists a protocol called GTP' (GTP prime), which is a largely separate protocol from GTP that can be used with User Datagram Protocol (UDP) and / or Transmission Control Protocol (TCP). GTP' uses the same structure as GTP, i.e., it employs GTP-C and GTP-U as well.

[0004] GTP is used in mobile core networks, such as those for General Packet Radio Communication System (GPRS), UMTS, and / or LTE, for signaling between a Serving GPRS Support Node (SGSN) (for GPRS and UMTS) or a Serving Gateway (SGW) (for LTE) and a Gateway GPRS Support Node (GGSN) (for GPRS and UMTS) or a Packet Data Network Gateway (PGW) (for LTE). In the case of a 5G core network, GTP may also be employed to provide connectivity between the Access and Mobility Management Function (AMF), the Session Management Function (SMF), and the User Plane Function (UPF), which more or less correspond to the SGSN / SGW and GGSN / PGW in 5G.

[0005] GTP-C control messages enable the creation, modification, and / or deletion of user sessions and the establishment of Packet Data Protocol (PDP) contexts between participating gateways on the control plane. This encompasses the establishment of tunnel connections between participating gateways. These tunnel connections are assigned to specific sessions and / or specific contexts created by the respective session / context creation request and / or response messages, as defined, for example, in 3GPP TS 23.401. This in turn allows for movement toward the user plane, implemented by the GTP-U portion of GTP. Using GTP-U, GTP-U tunnels can be created and / or deleted. User data can then be transported within the core network via these tunnels.

[0006] According to the GTP protocol, there is an initial message that establishes a tunnel connection and subsequent messages associated with previously established tunnel connections. Each tunnel can be identified by its respective tunnel endpoint identifier. A tunnel endpoint identifier (TEID) is defined for each endpoint of a tunnel connection. There may be different identifiers, TEID-c and TEID-u, for the control and user planes. Accordingly, a GTP tunnel may be defined by four TEIDs, for example, TEID-c and TEID-u for a first device where the tunnel originates or terminates, and TEID-c and TEID-u for a second device connected to the first device via the tunnel connection.

[0007] To establish a tunnel connection, the devices connected to such a tunnel connection need to exchange their respective TEIDs. This exchange occurs in an initial message. The GTP protocol defines a Create PDP Context / Session Request message and a Create PDP Context / Session Response message. According to the GTP protocol, these messages have a header Tunnel Endpoint Identifier (TEID) and may carry additional information fields. When establishing a new connection, a first device sends a Create PDP Context / Session Request message with its header TEID set to zero and an origin TEID set to the TEID of the new connection defined by the first device requesting the new connection.

[0008] For example: The initial Create PDP Context / Session Request message from the SGSN / SGW to the GGSN or PGW has the header TEID equal to zero and the origin TEID set to the TEID-c and TEID-u of the tunnel connection at the SGSN / SGW.

[0009] The Create PDP Context / Session Request message is sent to the second device, which in turn receives the TEID-c and TEID-u for the new connection from the first device. In response, the second device defines the TEID-c and TEID-u for the new connection and sends a Create PDP Context / Session Response message that carries the first device's TEID-c as the header TEID, allowing the first device to identify the response as a message for the requested tunnel. The response also carries the second device's TEID-c and TEID-u as the origin TEID.

[0010] For example: the initial Create PDP Context / Session Response message from the PGW or GGSN to the SGSN / SGW has the header TEID set to the SGSN / SGW's TEID-c and keeps the GGSN / PGW's TEID-c and TEID-u as the origin TEID.

[0011] Thus, after receiving the response message, the first device knows the TEID-c and TEID-u of the second device associated with the requested tunnel. As a result, after the exchange of request and response messages, both devices know the TEID-c and TEID-u for the other device's tunnel connection. The established tunnel is associated with these four TEIDs for the control and user planes.

[0012] To send subsequent messages through the established GTP tunnel from one device to another, the header TEID of the subsequent message is sent to the respective TEID of the destination device: for control messages, the TEID-c of the destination device is used, and for user plane messages, the TEID-u of the destination device is used.

[0013] For example, a subsequent GTP message from the SGSN / SGW to the GGSN / PGW has the header TEID set to the GGSN / PGW's TEID-c for the particular tunnel connection. Optionally, the message may also have the origin TEID-c and TEID-u information fields set to the SGSN / SGW's TEID-c and TEID-u for this tunnel connection.

[0014] For example, a subsequent GTP message from the GGSN / PGW to the SGSN / SGW has the header TEID set to the SGSN / SGW's TEID-c for the particular tunnel connection. Optionally, the message may also have the origin TEID-c and TEID-u information fields set to the GGSN / PGW's TEID-c and TEID-u for this tunnel connection.

[0015] As is clear from the above, the GTP protocol is connection-oriented, where a connection is defined, among other things, by a TEID, and therefore it needs to remember and consider the transient state of each connection during a complete connection cycle. In other words, for the GTP protocol to function, it needs to store the connection state, i.e., setup, modification, active, closing, closed, for each connection. This need to maintain state makes the GTP protocol unsuitable for use in such cloud environments, since a cloud-native approach is naturally stateless.

[0016] A further problem is that there is currently no standardized definition and description of how the GTP proxies provided between the endpoints, specifically gateways, should be implemented. Instead, there are several proprietary implementations of GTP proxy solutions, which are conventionally implemented, for example, as roaming hubs, firewalls, and / or routers. Unfortunately, these are usually implemented in hardware.

[0017] Furthermore, while several software proxy solutions exist, they often suffer from a unified and therefore monolithic, state-based architecture, making them inflexible and susceptible to the addition of new features over time due to high component coupling within them. See, for example, European Patent Application EP 20 206 283.2. Furthermore, components in these systems are very difficult to replace without affecting (or even damaging) the entire system. The monolithic nature can also mean that a proxy node failure can result in the loss of all previous transactions, meaning that in the event of a disaster, all connections are lost. Therefore, horizontal scaling of the system entails some drawbacks. For example, because there is a fixed correlation between tunnel connections and serving GTP proxies, it is necessary to ensure that the correct GTP proxy handles a dedicated tunnel connection. If this GTP proxy were to fail, all existing sessions served by this dedicated GTP proxy would be lost. Therefore, any significant improvement in performance can only be achieved using vertical scaling of hardware. As a further drawback, in existing solutions, the GTP-C and GTP-U are typically provided as part of the same instance and are therefore interconnected with each other. All of these drawbacks make current software and / or hardware solutions for GTP proxies unsuitable for deployment in cloud environments.

[0018] However, the use of GTP within cloud environments is generally desirable due to its wide adoption and the flexibility of such cloud environments.

[0019] A GTP proxy is an element that resides between an SGSN / SGW and a GGSN / PGW. A GTP proxy device can be used to provide a GTP firewall, a GTP router, or a roaming hub. These solutions are highly specialized and based on traditional, hardware-bound, monolithic applications that are not suitable for cloud-native deployments. The proxy device acts as an intermediary between two gateways by terminating a first GTP tunnel connection from a first gateway and establishing a second GTP tunnel connection to a second gateway. The proxy forwards messages received from the first gateway via the first tunnel connection to the second gateway via the second tunnel connection, for example, based on the origin and destination IP addresses contained in the GTP message. In principle, the proxy device creates a tunnel endpoint identifier (TEID) that identifies the tunnel endpoint for the control and user planes for a particular connection, terminates the first tunnel connection, and then creates a new tunnel endpoint identifier to set up the second tunnel connection. The proxy device then connects both tunnel connections, identified by their respective TEIDs. The proxy device stores information about both connections. The proxy device replaces each TEID in the forwarded message with the TEID created for the tunnel connection through which the message is to be forwarded. Thus, the proxy device enables a message received via a first tunnel connection to be forwarded via a second, different tunnel connection. In addition, the sequence number SEQ of the message may be replaced by a new value generated by the proxy device. A tunnel connection is identified by the TEID and the IP addresses of the devices involved, which may be the SGSN / SGW, GGSN / PGW, and proxy device.

[0020] For example, to establish a connection between an SGSN / SGW and a GGSN / PGW via a proxy device, the SGSN may send a Create Initial PDP Context / Session Request message to the proxy device with the header TEID equal to zero and origin TEID-c and TEID-u set to the TEIDs created by the SGSN / SGW for this connection.

[0021] The proxy device forwards the Create PDP Context / Session Request message but sets the origin TEID-c and TEID-u to the TEID-c and TEID-u of the proxy device for the second connection between that proxy and the GGSN / PGW.

[0022] After receiving the Create PDP Context / Session Request message, the GGSN / PGW therefore knows the TEID-c and TEID-u of the proxy device for the connection between the GGSN / PGW and the proxy device.

[0023] The GGSN / PGW sends a Create PDP Context / Session Response message carrying the proxy device's TEID-c for the connection between the proxy device and the GGSN / PGW as the header TEID, and the GGSN / PGW's TEID-c and TEID-u for this connection as the origin's TEID-c and TEID-u.

[0024] After receiving the Create PDP Context / Session Response message, the proxy device therefore knows the TEID-c and TEID-u of the GGSN / PGW for the connection between the proxy device and the GGSN / PGW.

[0025] The proxy device forwards the PDP context / session creation response message by setting the header TEID to the TEID-c of the SGSN / SGW and the origin TEID-c and TEID-u to the TEID-c and TEID-u of the proxy device for the connection between the proxy device and the SGSN / SGW.

[0026] Accordingly, after the initial message exchange, the SGSN / SGW knows the TEID-c and TEID-u of the proxy device for the connection between the SGSN / SGW and the proxy device as well as its own TEID-c and TEID-u for the connection between the SGSN / SGW and the proxy device. Similarly, the GGSN / PGW knows the TEID-c and TEID-u of the proxy device for the connection between the proxy device and the GGSN / PGW as well as its own TEID-c and TEID for this connection.

[0027] Furthermore, the proxy device knows the respective TEIDs for both connections and can therefore communicate via the first tunnel connection with the SGSN / SGW and via the second tunnel connection with the GGSN / PGW. The SGSN / SGW does not have any information about the TEIDs of the GGSN / PGW. The GGSN / PGW does not have any information about the TEIDs of the SGSN / SGW.

[0028] Subsequent messages sent from the SGSN / SGW carry the TEID-c of the proxy device as the header TEID of the connection between the proxy device and the SGSN / SGW. Optionally, the message further carries the TEID-c and TEID-u of the SGSN / SGW for this connection.

[0029] Subsequent messages from the proxy device to the GGSN / PGW carry the GGSN / PGW's TEID-c as the header TEID for the connection between the proxy device and the GGSN / PGW. Optionally, the message also carries the proxy device's TEID-c and TEID-u for this connection.

[0030] Subsequent messages sent from the GGSN / PGW to the proxy device carry the TEID-c of the proxy device as the header TEID of the connection between the proxy device and the GGSN / PGW. Optionally, the messages further carry the TEID-c and TEID-u of the GGSN / PGW for this connection.

[0031] Subsequent messages from the proxy device to the SGSN / SGW carry the TEID-c of the SGSN / SGW as the header TEID of the connection between the proxy device and the SGSN / SGW. Optionally, the message also carries the TEID-c and TEID-u of the proxy device for this connection.

[0032] Thus, GTP tunnels are established by exchanging the TEIDs of the devices between which the tunnel is established. Messages carry a TEID, indicating the destination device's destination TEID as the header TEID. Initial request and response messages may also carry the user and control plane TEIDs of the sending and / or destination devices. Responses can then be sent back through the tunnel identified by these TEIDs. For example, a response to a received message with one of the sent control and user plane TEIDs received in the initialization message as the header TEID may be sent back. Messages may also carry the IP addresses of the origin and destination devices to enable proper routing. A GTP tunnel is defined by four TEIDs, two corresponding to the control and user planes of each device. After the initial exchange of request and response messages, each participating device knows the TEID of its respective partner. That is, the first gateway knows the IP address and TEID of the second gateway, and vice versa. In other words, the SGSN / SGW knows its own TEID and the TEID of the GGSN / PGW. Subsequent messages for the same tunnel connection will consequently carry the respective control plane associated TEID of the destination device as the header TEID, and thus the destination device receiving the message will have associated the message with the respective tunnel connection.

[0033] In the traditional approach, all transient state, e.g., F-TEID, TEID, TEID-c, TEID-u, IP addresses, and sequence numbers associated with tunnel connections, are stored within the SGSN / SGW / GGSN / PGW or respective SGSN-c / SGW-c / GGSN-c / PGW-c. However, each user plane or control plane component may also store only its own user plane or control plane state information; e.g., SGSN-c / SGW-c / GGSN-c / PGW-c may store TEID-c, and SGSN-u / SGW-u / GGSN-u / PGW-u may store TEID-u. The traditional GTP approach is connection-oriented and therefore stateful. Each unit, e.g., a GGSN, must remember and handle the state of each connection that is terminated or terminated at this particular GGSN; therefore, other GGSNs cannot take over because they do not have information about the connection. This concept also applies to GTP proxies, as there are two separate GTP tunnel connections between which the proxy relays messages from the first gateway to the second gateway. Each tunnel connection is a GTP tunnel between one of the gateways and the proxy device. As a result, in the event of a power outage or failure condition, information will be lost.

[0034] A proxy device may contain separate nodes that are separate and can forward messages from one gateway to another. However, after a gateway sends an initial message to one of the nodes, state information is stored in that particular node. Therefore, the tunnel connection must always terminate at this node. The same applies to tunnels established from the node; the tunnel endpoints are associated with a particular node, and only this node stores the corresponding state information. A node may also be called a tunneling node or a working tunneling node.

[0035] In contrast to traditional approaches, a stateless GTP proxy does not store any transient state of any connection within a node because state is maintained externally in a database separate from the node of the proxy device. The proxy device includes one or more nodes that process incoming and outgoing messages and do not store any state information, a database, and a load balancer that distributes the load among the nodes. The present invention separates GTP state handling into components by using an external database, e.g., a key-value store (KVS), in which connection state is stored; addressing and retrieving connection state from the database are part of connection processing. By retrieving connection state from a database, e.g., a KVS, GTP connections can be handled in a stateless manner, allowing for the creation of scalable mobile core solutions. Summary of the Invention [Problem to be solved by the invention]

[0036] For this reason, it is an object of the present invention to provide a GTP proxy that is suitable for deployment in a cloud environment. Accordingly, the present invention is based on the recognition that, to provide such compatibility, a cloud-native GTP proxy must be capable of being provided in a stateless manner. Accordingly, the present invention is based on the understanding that a GTP proxy that is suitable for a cloud environment does not need to store the state of connections provided through the GTP proxy. Therefore, it is an object of the present invention to provide a stateless GTP proxy. [Means for solving the problem]

[0037] This object is solved by a proxy device for a wireless communication system including a plurality of tunneling nodes for providing a plurality of connections between an ingress gateway, e.g., an SSGN / SGW, and an egress gateway, e.g., a GGSN / PGW, at least one load balancing entity, and a memory configured to store a plurality of state information values ​​for the plurality of connections, wherein the at least one load balancing entity is configured to receive a message from the ingress gateway and select a working tunneling node from the plurality of tunneling nodes, and the working tunneling node is configured, in response to the selection by the load balancing entity, to communicate with the memory to retrieve from the memory state information related to a previous state, provide from the ingress gateway state information related to a current state, and store said state information related to the current state in the memory, to establish a connection to the egress gateway.

[0038] A proxy device may include several subsystems. The subsystems may be hardware or software located in different or co-located locations and performing different or the same functions. A proxy device may include one or more load balancers and one or more nodes. A node may also be referred to as a tunneling node or a working tunneling node. Hereinafter, a node may be referred to as a GTP node for the control plane (GTO-c), a GTP node for the user plane (GTP-u), or more generally as a GTP node. A node of a proxy device processes incoming traffic or messages. A load balancer may receive a message, data, or packet from a gateway and forward the message, data, or packet(s) to a node. The load balancer may use an algorithm to select a node to which the message, data, or packet will be forwarded. The load balancer may forward the message, data, or packet based on a load criterion. The load criterion may be based on the load of the node. The load balancer may select a node using an algorithm. The algorithm may be a round-robin algorithm or any other suitable algorithm. A node may be an entity that performs tasks according to the GPRS tunneling protocol. The tasks may conform to GTPv1 and GTPv2. The node may represent—depending on the tunnel direction—a standard SGNS / SGW or GGSN / PGW role conforming to 3G / 4G / 5G telecommunications standards. The node may terminate a GTP tunnel connection. The node may establish a GTP tunnel connection. The GTP proxy may further include a memory. The memory may be a database, e.g., a key-value store. The proxy device terminates a first tunnel connection from a first gateway, e.g., an ingress gateway or an SSGN / SGW. The proxy device establishes a second tunnel connection with a second gateway, e.g., an egress gateway. The ingress gateway may be an SSGN / SGW. The egress gateway may be a GGSN / PGW. The proxy device associates the first tunnel connection with the second tunnel connection.Tunnel connections may be associated by storing state information for the first tunnel connection and the second tunnel connection together. The state information may be stored in memory. The state information for a tunnel connection may include an IP address, a tunnel endpoint identifier (TEID), optionally a sequence number (SEQ), and a timestamp. For example, the state information for a first tunnel connection may include the IP address of the ingress gateway, the TEID of the ingress gateway for the first connection, optionally a sequence number, the IP address of a load balancer of the proxy device responsible for forwarding messages, data, or packets from the ingress gateway, and the TEID and SEQ of the proxy device associated with the first connection. There may be separate IP addresses and TEIDs for the control and user planes. Each GTP-c node of the proxy device may query the memory to obtain state information of a previous state in response to selection by the load balancer. The load balancer may route incoming messages to the selected node by using an internal IP address. The selected node may also query the memory in response to receiving a message from the load balancer. In other words, a node may be selected by forwarding a message to the selected node. The query may be based on a received International Mobile Subscriber Identity (IMSI) or TEID in the data, message, or packet received from the load balancer. If the state information is obtained based on the IMSI or TEID, the node serves as an end point and a start point for the first and second tunnel connections, respectively, based on the obtained state information including state information of the first and second tunnel connections. The node's acquisition of state information associated with a previous state enables it to process tunnel connections on a message-by-message basis, instead of associating each tunnel with one particular device that stores its tunnel information. Messages, data, or packets are thus received at the proxy device through one of the two tunnel connections associated with the state information associated with the state, and are forwarded by the other of the two tunnel connections associated with the state information.The node then stores in memory state information for the states, including state information for the first tunnel connection and the second tunnel connection. Any subsequent messages received from one of the gateways or forwarded by the load balancer may be forwarded to a different GTP-c node, which may query the memory to retrieve state information associated with the previous state from the memory. Thus, each node may be able to receive and send messages associated with the first and second tunnel connections by retrieving state information for the previous state from the memory based on the IMSI or TEID associated with the previous state.

[0039] The state information for the second tunnel connection may include the IP address of the egress gateway, the TEID of the egress gateway for the second connection, the TEID of the proxy device associated with the second tunnel connection, optionally a sequence number (SEQ) for the request and response messages, respectively, and the IP address of the load balancer of the proxy device responsible for forwarding the message, data, or packet from the egress gateway. There may be separate IP addresses and TEIDs for the control and user planes.

[0040] The state information of the first tunnel connection and the state information of the second tunnel connection are stored as state information of a previous state. For example, the previous state corresponds to the first and second tunnel connections associated through the proxy device. Thus, the state information may include not only information about the first and second tunnel connections, but also information about how these connections are associated to forward messages through the proxy device. The state information of the previous state may be stored by a memory.

[0041] In one embodiment, the present invention relates to a proxy device for a wireless communication system, the system including: a plurality of nodes for providing a plurality of connections between a first gateway and a second gateway; a first load balancer that processes incoming traffic from the first gateway; a second load balancer that processes incoming traffic from the second gateway; and a database configured to store a plurality of state information for the plurality of connections, wherein a memory stores state information regarding pairs of connections between the proxy device and the first gateway and between the proxy device and the second gateway, the state information regarding the pairs of connections includes information regarding a first connection between the proxy device and the first gateway, the first connection using or including a first tunnel endpoint identifier of the first gateway and a second tunnel endpoint identifier of the proxy device, and information regarding a second connection between the proxy device and the second gateway, the second connection using or including a third tunnel endpoint identifier of the second gateway and a fourth tunnel endpoint identifier of the proxy device; the load balancer is configured to receive a first message from the first gateway, the first message carrying one of the second tunnel endpoint identifiers of the proxy device as a header TEID and optionally the first tunnel endpoint identifier of the first gateway as an origin tunnel endpoint identifier; the first load balancer is further configured to select one of the nodes among the plurality of nodes and forward the message to the selected node; the selected node is configured to communicate with a database to request state information associated with the header TEID of the first message; the selected node is further configured to replace the header TEID of the first message with one of the third tunnel endpoint identifiers of the second gateway and optionally replace the origin TEID of the first message with a fourth tunnel endpoint identifier of the proxy device; the selected node then forwards the first message with the replaced TEID to the second gateway; and the second load balancer is configured to receive the second message from the second gateway;The second message carries one of the fourth tunnel endpoint identifiers of the proxy device as a header tunnel identifier and optionally the third tunnel identifier of the second gateway as an origin tunnel endpoint identifier, the second load balancer is further configured to select one of the nodes from the plurality of nodes and forward the second message to the selected node, the selected node is configured to communicate with a database to request state information associated with the header TEID of the second message, the selected node is further configured to replace the header TEID of the second message with one of the first tunnel endpoint identifiers of the first gateway and optionally replace the origin TEID of the second message with the second tunnel endpoint identifier of the proxy device, and the selected node then forwards the second message with the replaced TEID to the first gateway.

[0042] In a preferred embodiment, the proxy device further uses the General Packet Radio Service (GPRS) Tunneling Protocol (GTP). Preferably, the proxy device processes messages according to GTP version 1 and / or version 2. Therefore, messages processed by the proxy device can be processed by a GTP-compatible entity as specified by the GPRS and GTP standards.

[0043] In a preferred embodiment, the plurality of nodes are configured to provide a plurality of connections between the first gateway and the second gateway, such that a plurality of GTP tunnel connections can be established between the first gateway and each node and between each node and the second gateway.

[0044] In a more preferred embodiment, the first message and the second message are GTP control messages, and the connection is a GTP tunnel connection. For example, the messages may be a Create PDP Context / Session Request message and a Create PDP Context / Session Response message. In another example, the messages may carry the TEID for the control plane of each destination device as a header TEID.

[0045] In a preferred embodiment, the header is a GTP header, specifically the header after the UDP / TCP header.

[0046] In another preferred embodiment, the message from the first gateway further includes a subscriber identifier for identifying the device to which the connection is to be established, and the node is further configured to provide the subscriber identifier and the TEID for the connection to the memory for storage, whereby the subscriber identifier and the TEID for the connection are correlated and stored with the established connection. The subscriber identifier may be an IMSI.

[0047] In a preferred embodiment, the node is further configured to mask the tunnel connection identifier and / or the device identifier before providing it to the memory for storage.

[0048] In another preferred embodiment, the at least one load balancer is configured to select a node from the plurality of tunneling nodes by selecting a node from the plurality of tunneling nodes based on a load criterion.

[0049] In another preferred embodiment, the at least one load balancer is configured to select a node from the plurality of tunneling nodes by selecting a node from the plurality of tunneling nodes in a round robin manner.

[0050] In another preferred embodiment, the at least one load balancer is configured to select a node from the plurality of tunneling nodes based on a suitable selection mechanism or selection criteria. Those skilled in the art are familiar with different well-known selection criteria, such as round robin, randomization, or quasi-randomization. The present invention can be implemented using any known or to-be-developed selection criteria or selection mechanism.

[0051] In another preferred embodiment, the tunnel endpoint identifier is a tunnel endpoint identifier according to the GTP protocol, specifically according to GTP protocol version 1 and version 2.

[0052] In another preferred embodiment, the memory uses a key-value store.

[0053] In a preferred embodiment, the present invention relates to a method for using a proxy device in a wireless communication system to provide connectivity between a first gateway and a second gateway, the method comprising: storing, by the memory, state information relating to pairs of connections between the proxy device and a first gateway and between the proxy device and a second gateway, the state information relating to the pairs of connections including information relating to a first connection between the proxy device and the first gateway using a first tunnel endpoint identifier, a TEID of the first gateway and a second tunnel endpoint identifier of the proxy device, and information relating to a second connection between the proxy device and the second gateway using a third tunnel endpoint identifier of the second gateway and a fourth tunnel endpoint identifier of the proxy device; receiving, by a first load balancer, a first message from a first gateway, the first message carrying one of the second tunnel endpoint identifiers of the proxy device as a header tunnel identifier and optionally the first tunnel endpoint identifier of the first gateway as an origin tunnel endpoint identifier; selecting, by a first load balancer, one of the nodes from the plurality of nodes; - forwarding the message to the selected node by a load balancer; communicating, by the selected node, with a database to request state information associated with the header TEID of the first message; replacing, by the selected node, the header TEID of the first message with one of the third tunnel endpoint identifiers of the second gateway and optionally replacing the origin TEID of the first message with the fourth tunnel endpoint identifier of the proxy device, wherein the selected node then forwards the first message with the replaced TEID to the second gateway; receiving, by a second load balancer, a second message from the second gateway, the second message carrying one of the fourth tunnel endpoint identifiers of the proxy device as a header tunnel identifier and optionally the third tunnel identifier of the second gateway as an origin tunnel endpoint identifier; selecting, by a second load balancer, one of the nodes from the plurality of nodes; forwarding, by a second load balancer, the second message to the selected node; communicating with the memory, by the selected node, to request state information associated with the header TEID of the second message; replacing, by the selected node, the header TEID of the second message with one of the first tunnel endpoint identifiers of the first gateway and optionally replacing the origin TEID of the second message with the second tunnel endpoint identifier of the proxy device, whereby the selected node then forwards the second message to the first gateway with the replaced TEID. The method includes the step of:

[0054] In a preferred embodiment, when the system processes a GTP-c message, the first message carries the TEID for the control plane of the second tunnel endpoint identifier as the header TEID. The selected node replaces the header TEID of the first message with the TEID for the control plane of the third tunnel endpoint identifier. The second message carries the TEID for the control plane of the fourth tunnel endpoint identifier as the header TEID. The selected node replaces the header TEID of the second message with the TEID for the control plane of the first tunnel endpoint identifier.

[0055] In another preferred embodiment, when the system processes GTP-c messages and the first message is a Create PDP Context / Session Request message, the first message carries a header TEID that is zero, i.e., 0x000000000, since the TEID for the control plane for the GTP proxy is not created at this point.

[0056] In a preferred embodiment, the method further includes the step of selecting a node from the plurality of tunneling nodes includes selecting a node from the plurality of tunneling nodes in a round robin manner or based on a load criterion.

[0057] In a preferred embodiment, the memory is a key-value store and the step of communicating with the key-value store includes using the IMSI as a key.

[0058] Another preferred embodiment relates to a computer program product comprising instructions which, when executed by a processor, cause the processor to perform the method steps set out above. [Brief explanation of the drawings]

[0059] [Figure 1] 1 shows a schematic example of the present invention. [Figure 2]10 shows the call flow for a create request. [Figure 3] 1 illustrates a call flow of a GTP message processed by a proxy device. [Figure 4] The system is illustrated with respect to generic GTP messages. [Figure 5] 1 illustrates an example of a proxy device connecting a first gateway and a second gateway. [Figure 6] 1 shows a schematic example of the present invention. [Figure 7] This is a schematic example. DETAILED DESCRIPTION OF THE INVENTION

[0060] Figure 1 shows a schematic example of a setup incorporating the present invention. Two user devices 1 and 2 are attached via a radio access network (RAN) 3, which provides connectivity between the user devices and the core network. There may be one or more SGSNs or SGWs 4. The SGNS / SGWs forward messages and data from the user devices to a load balancer 5 in the proxy device. The load balancer 5 processes GTP-c messages from the SSGN(s) / SGW(s). There may be two or more load balancers, specifically one load balancer 5 for the control plane and optionally one load balancer 10 for the user plane. There may also be only one load balancer that provides load balancing for all messages. The proxy device further includes one or more nodes 7, 8, 9, 11, 12, and 13. The nodes may be tunneling nodes. The proxy device may include dedicated nodes for the control plane 7, 8, and 8 and dedicated nodes for the user plane 11, 12, and 13. The proxy device further includes one or more load balancers 14 that process data, messages, and packets from the GGSN(s) / PGW 17. There may be one load balancer for the control plane 14 and optionally one load balancer for the user plane. Alternatively, there may be one load balancer for all traffic. The proxy device includes a database 16. The database may be a key-value store. The database may be a fast-access database.

[0061] 2 shows one aspect of the call flow of a create PDP context / session request message sent from the first gateway SGNS / SGW 24 to a proxy device. The message can be a create PDP context request message or a create session request message, as specified by 3GPP for different versions of the GTP protocol. The message carries at least the IP address of the destination device, which is the load balancer 25 of the proxy device. The message also carries the origin IP address, i.e., the IP address of the first gateway. The message may carry separate IP addresses for the control and user planes of the first gateway. According to the IP address, the message is routed to the load balancer 25.

[0062] The load balancer 25 selects one of the proxy device nodes 27, 28, 29. The load balancer 25 may select a node based on a load criterion. The load criterion may be based on a round-robin method, a priority queue, a weight associated with each node 27, 28, 29, or any other suitable load criterion. The nodes 27, 28, 29 may be nodes capable of processing GTP-c traffic or messages. The load balancer 25 forwards the message to the selected node. The message, which may be a GTP message, includes a GTP tunnel endpoint identifier (TEID) of the first gateway (SSGN / SGW) and a header TEID with a value of zero. The load balancer may forward the message according to the private IP address.

[0063] Specifically, the message includes, for example, a GTP-c header as specified in 3GPP TS 26.060 Section 8.2 or a GTPv2 header as specified in GPP TS.26.274 Section 5.5. The create PDP context / session request message includes a header TEID with a value of zero, an IMSI that may be associated with the user equipment (UE) connected to the first gateway (GW) and requesting the PDP context / session creation, an APN, and the TEIDs of the first gateway for the control and user planes (TEID-c and TEID-u), which may be associated with a particular context / session and the IP addresses for the control and user planes of the first gateway 24 as the origin IP address. Furthermore, the header optionally includes a sequence number SEQ for the context / session. SEQ is present if a response message is expected. For example, in the case of a session request message, a create session response message is expected. The response can be associated with the request via the sequence number. TEID-c and TEID-u define the tunnel endpoints at the first gateway 24 for the control and user planes, respectively. These TEIDs identify the tunnel endpoints for any subsequent messages; for example, the header TEID of the subsequent message is set to one of these TEIDs. For example, in the case of a session creation response, the header TEID is set to TEID-c. The GTP message may further include an IMSI and APN. The IMSI may belong to the user equipment connected to the origin gateway. The APN may be selected by the user equipment or by a rule or policy of the access network. The APN is resolved in the access network by querying a DNS request, and the response is a GTP-c IP address belonging to the GTP-c load balancer 25. As a result, the message carrying the resolved APN is routed to the load balancer. Additionally, the message may include a sequence number.The sequence number is used as a transaction identifier for signaling messages with a response message defined for a request message, the sequence number value being copied from the request to the response message header, thus allowing responses to be associated with requests and vice versa.

[0064] Following the load balancer forwarding the message to the selected node, the proxy device, specifically, for example, the selected GTP-c node to which the message is forwarded, generates four new TEIDs. The first two TEIDs are the proxy device's TEIDs for the connection between the first gateway and the proxy device's node (control and user plane). The second two TEIDs are the proxy device's new TEIDs for the second connection between the proxy device's node and the second gateway. The proxy device also generates a new sequential number SEQ. The generated TEIDs are unique within the system. The generation may be based on a random number. The generation may be based on the current time. The SEQ may also be generated based on a random number. The generated TEIDs are unique at least as long as the connection exists. That is, the TEIDs can be reused only after the session / context is deleted.

[0065] The proxy device masks the TEID-c and TEID-u in the message by replacing these information elements with the TEID generated for the second connection to the second gateway.

[0066] The header TEID value remains zero. In addition, the field holding the IP addresses for the control and user planes of the first gateway 4, 24 can be replaced by the load balancer 5, 25 holding the IP addresses for the control plane of the load balancer 14, 211 and the IP addresses for the user plane of the GTP-u node 11, 12, 13 (shown in FIG. 1 ) that processes the message from the second gateway 217, e.g., GGSN / PGW. In this way, the proxy device spoofs the origin IP address(es) of the first gateway 24 included in the forwarded message. The second gateway 217 to which the message is forwarded identifies the load balancer 214 and GTP-u node 11, 12, 13 whose IP address(es) are included in the message as the message's origin. Thus, the second gateway 217 receives a message containing the generated pair of IP addresses of the load balancer 214 and GTP-u nodes 11, 12, 13 that are processing the message from the second gateway, as well as the TEID specifying the tunnel endpoint for the second connection at the proxy device 26. The second gateway can therefore return the message to the load balancer 214 and GTP-u nodes 11, 12, 13 of the proxy device.

[0067] The sequence number SEQ in the Create PDP Context Request / Create Session Request message may be replaced by a sequence number generated by the proxy device.

[0068] The proxy device, for example, using node 27, determines the IP address of the second gateway 217. The determination may be based on the Access Point Name (APN). Matching the APN with the APN and IP address pair determines the IP address (APN mapping of the serving gateway's IP address). The APN may be included in the Create PDP Context Request / Create Session Request message. The proxy device, for example, using node 27, may obtain the destination address from a stored map of APN and / or IP address values.

[0069] The proxy device stores all state in a database 216, for example using node 27. The database can be a key-value store. The storage is done by storing database entries, for example in a Redis 1 This may include creating a hash using the header TEID, the original TEID for the control and user plane of the first gateway, the four generated TEIDs for the control and user plane for the first connection and the second connection, the first gateway IP address for the control and user plane, the proxy IP addresses for the control and user plane, i.e., the GTP-C IP addresses of the load balancers 214 and 25 and the GTP-U IP addresses of the GTP-u nodes 11, 12, 13, the original and masked sequence number and destination IP addresses, and the header TEID and / or IMSI as a key. Alternatively, the state information may be stored in JavaScript Object Notation, or as an array of values ​​(as opposed to a hash that additionally includes the field names), or as binary encoded in a base64 string, etc. 1 https: / / de.wikipedia.org / wiki / Redis

[0070] The proxy device 26 then forwards the modified / masked PDP context / create session request / create session request message to the second gateway (218). The modified masked message includes a TEID header with a value of zero and the generated TEID of the proxy device for the control and user planes of the second connection, as well as the IP address for the control plane of the load balancer 214 and the IP addresses for the user plane of the GTP-u nodes 11, 12, 13 as origin IP addresses.

[0071] Messages forwarded by proxy device 26 thus retain the masked TEID value, the masked sequence number, the IP address of load balancer 214, and the IP address of GTP-u node 11, 12, 13 as the origin IP address. Therefore, to second gateway 217, the message appears to originate from the proxy device, preferably GTP-u node 11, 12, 13, which is processing incoming messages from load balancer 214 and second gateway 217, without any indication that the message originally originated from the first gateway. As a result, forwarded GTP-c messages may be sent from the node and may bypass load balancer 214, but from an external perspective, the GTP-c messages appear to originate from load balancer 214. Storing the session information, including the original and masked values, in a way that the new values ​​are associated with the original information of the message received from first gateway 24, however, allows subsequent messages to be associated with a particular session and forwarded to the correct gateway. This association allows for two-way communication.

[0072] For example, the first message may include an origin IP address of 1.2.3.4, a destination IP address of 4.3.2.1, which is the IP address of the load balancer 25, and, for example, TEID-c 12, TEID-u 34, and SEQ 1, as well as a header TEID 0. In the case of GTPv2, these values ​​are included in the F-TEID. The message is sent from the first gateway 24 to the load balancer 25, addressed by the destination IP address of the load balancer 25, and the load balancer 25 forwards the message to the selected node 27 of the proxy device 26. The proxy device 26 generates four new TEIDs, 21, 43, 56, and 78: TEID-c 21 and TEID-u 43 belonging to the proxy device for the first connection, and TEID-c 56 and TEID-u 78 for the connection to the second gateway. These four TEIDs belong to the proxy device 26 and specify endpoints at the proxy device 26 for the connection between the first gateway 24 and the proxy device and the connection between the proxy device 26 and the second gateway 217. Therefore, the proxy device 26 terminated the first connection and established the second connection by providing the respective tunnel endpoints. The proxy device 26 also generates a new SEQ 2. The proxy replaces the SEQ and TEID-c and TEID-u received from the first gateway 24 with new values ​​2, 56, and 78. Furthermore, the origin IP address of the first gateway 24 is replaced with the IP address of the load balancer 214, which may be 5.6.7.8, and the destination IP address received from the first gateway (which was the IP address of the load balancer 25) is replaced with the IP address of the second gateway 217, which may be 8.7.6.5, and the IP address of the second gateway 217 may be received from the internal APN and / or IP address mapping. The proxy device 26 stores state information associated with the connection pair in the database 216. The storage / archive may be done by using key-value storage. Specifically, the proxy device may create a hash using the IMSI as the key.

[0073] The message is then forwarded to the second gateway 217, which now knows the generated TEID-c 56 and TEID-u 78 of the proxy device 26 as well as the generated sequence number 2.

[0074] The second gateway's response is also shown in FIG.

[0075] The second gateway 217 may then send a Create PDP Context / Create Session Response message, corresponding to the message sent from the right side in FIG. 2, by setting the header TEID to 56, which is the control plane tunnel endpoint at the proxy device 26, and replacing TEID-c and TEID-u with its own TEIDs for this connection, e.g., 65 and 87. The second gateway 217 sets the destination IP address to 5.6.7.8 (the address of the load balancer 214) and the origin IP address to its own, e.g., 8.7.6.5. The message is then sent to the load balancer 214 of the proxy device 26. The load balancer 214 selects a node based on load criteria. Based on the TEID, the node retrieves state information from the key-value store 216. The selected node, one of the nodes 27, 28, and 29, then has all state information, specifically, the association of the first connection with the second connection. Furthermore, one of the nodes 27, 28, 29 obtains the TEID-c 56 and TEID-u 78 for the second connection and serves as the endpoint for the message carrying the header TEID 56, which is equal to the TEID-c of the response message. The node 27, 28, 29 replaces the TEID-c / u with the TEID-c / u generated for the first connection, i.e., 21 and 43, and the header TEID is replaced with 12, which is the control plane TEID of the associated endpoint of the first connection, i.e., the first gateway 24 of the first connection. Furthermore, the origin IP address is replaced with the IP address of the load balancer 25, i.e., 4.3.2.1, and the destination IP address is replaced with the address of the first gateway 24, i.e., 1.2.3.4. Furthermore, the sequence number SEQ is replaced with its initial value 1. The first gateway 24 receives a message containing the TEID-c and TEID-u, 21 and 43, of the proxy device 26 for the first connection, and SEQ number 1, signaling that this message is a response to a request bearing the same SEQ.

[0076] 3 shows the call flow of a Create Response message from a Gateway (GW) 317. GW 317 may be a GGSN / PGW. The Create PDP Context Response / Create Session Response message is sent in response to a Create PDP Context Request / Create Session Request message, as described with respect to FIG. 2.

[0077] The create response message may be a create PDP session / context response message. The create response has a header TEID. The header TEID is sent by the create session / PDP context request message. The TEID-c may be generated by the proxy device 36. The generation may be performed by any of the GTP nodes 37, 38, 39 of the proxy device 36. For example, the TEID-c may be generated by the proxy device, e.g., by a selected GTP node of the proxy device 36. The create PDP context response / create session response message further includes the TEID for the control and user plane of the second gateway 317 that sends the message.

[0078] The create response message is forwarded by gateway 317 to load balancer 314. Load balancer 314 selects a GTP node 37, 38, 39. The selection may be based on load criteria, as described with respect to FIG.

[0079] The load balancer 314 forwards the create response message to the selected GTP node 37 (319). The selected GTP node 37 queries the database 316 regarding the previous session (320). Specifically, the database is queried for a hash using the header TEID and / or IMSI, and then the TEID and / or IMSI hash associated with the previous session is obtained (321). The GTP node can identify the hash of the previous session by using the header TEID. The TEID-c created for the second connection can be associated with the IMSI. Therefore, the node can obtain the IMSI based on the header TEID, which holds the TEID-c of the proxy device for the second connection. The IMSI can be used as a key for the IMSI hash created when saving session / context state information related to the state. The GTP node masks and unmasks the TEID in the following manner. By using the header TEID, which is set to TEID-c of the second connection in the load balancer, the IMSI can be obtained, which is used as a key to obtain the session state information, and the GTP node 37 then obtains the TEID for the control and user plane of the first gateway 34 sending the create PDP context / create session request message, e.g., the SGSN and corresponding IP address in Figure 2. The GTP node identifies the response request message as a response to the create request based on the sequence number.

[0080] For example, the GTP node masks the header TEID of the response message by replacing it with the TEID-c of the first gateway 314, as described with respect to FIG. 2, which is then stored in the database 316 by hash or the like. The TEID may also be stored in an array. The TEID may be stored together with the remaining necessary state information. The GTP node may also replace the TEID for the control plane with the generated TEID of the proxy device 36 for the first connection obtained from the hash. The GTP node 37 may also replace the origin IP address of the control plane with the IP address for the control plane of the load balancer 35 of the proxy device 36. The GTP node 37 also replaces the SEQ sequence number with the stored SEQ belonging to the first connection between the first gateway and the proxy device. Similarly, the destination IP address is replaced with the IP address of the first gateway 34. Additionally, the GTP node 37 restores the original SEQ in the header sent by the first gateway 34 by replacing the generated sequence number of the second connection with the original sequence number of the first connection. All state information is stored (322) in the database 316. The state information may be stored using key-value pairs, for example, a Redis hash, using the IMSI as the key.

[0081] In one embodiment, for example, as described with reference to FIG. 2, after the create session / PDP context request message is received by the proxy device, only two TEIDs (TEID-c and TEID-u) for the second connection are generated in the proxy device and stored in a hash. These TEIDs correspond to the proxy device's endpoints for the second connection, i.e., the connection between the proxy device and the second gateway. The TEIDs generated for the second connection and the TEID of the first gateway are then stored in a database. However, the hash does not yet include the proxy device's generated TEID for the first connection (the connection between the first gateway and the proxy device). Because the response message has not yet been sent, there is no need to create a TEID for the first tunnel connection at this point. The create session request message is forwarded to the second gateway as described with reference to FIG. 2. As described above, the create response message is modified and sent to the proxy device. However, when the session response message is received, the node of the proxy device generates the missing TEIDs of the proxy device for the first connection and masks the TEIDs for the user plane and the control plane with these generated TEIDs when forwarding the message to the first gateway. Thus, from the perspective of the first gateway, the session response message originates from the proxy device, since it carries the newly generated TEIDs. After that, all state information, including the two pairs of TEIDs generated for the first connection and the second connection, is stored in the database.

[0082] The create response message modified by the GTP node is forwarded to the first gateway of the create request message.

[0083] In summary, the create request and response process begins with the transmission of a message from the first gateway. The message includes a header TEID with a value of zero, the TEID and IP address of the first gateway, and a sequence number. The TEID and IP address for the control and / or user plane are masked by replacing them with one of two pairs: a newly generated TEID and the IP addresses of the proxy device's load balancer and GTP-u node. In the proxy device, the TEID and IP address of the first gateway are stored in a database along with the newly generated TEID for the control and user plane. Therefore, after forwarding this request message by the proxy device, the second gateway, which can be identified by its APN, knows the IP addresses of the proxy device's load balancer and GTP-u node responsible for processing the message from the second gateway, as well as the proxy device's generated TEID. The second gateway has no knowledge associated with the first gateway's IP address or TEID, respectively. The proxy device stores all state information as hashes associated with the IMSI. The proxy device stores the hashes in its database. Therefore, a GTP-c node may not have any state information after forwarding a message.

[0084] Database 16 of Figure 1 may be a key-value store (KVS). A KVS is a data storage paradigm designed to store, retrieve, and manage associative arrays, and data structures more commonly known today as dictionaries or hash tables. A dictionary contains a collection of objects, or records, which in turn have many different fields within them, each containing data. These records are stored and retrieved using a key that uniquely identifies the record and is used to find data within the database. 2Essentially, an array of data fields is associated and stored or retrieved by identifying it based on a key. In one embodiment, the IMSI in the GTP Create message will serve as the primary key for the lifetime of the context / session. 2 https: / / en.wikipedia.org / wiki / Key%E2%80%93value_database

[0085] The database 16 may store session information. The session information may relate to a previous session associated with an IMSI or APN or TEID. The GTP node may create a hash or IMSI hash based on the IMSI and TEID of the message. The IMSI hash can unambiguously identify the session. The IMSI hash can be stored in a KVS (e.g., Redis 3 It can be a key-value pair to a database (such as a database, DynamoDB, or other) where the key is, for example, the IMSI number itself and the value is an array containing session-specific information, e.g., TEID, generated TEID, SEQ, generated SEQ, IMSI, APN. 3 https: / / de.wikipedia.org / wiki / Redis

[0086] In one embodiment, session information may be stored as values ​​in a Redis hash. A Redis hash value is a series of string pairs, where the first string is the member name and the second string is the member value, e.g., key "IMSI_123456789012345" with value "IMSI 123456789012345 APN some.apn.com Activated 1", which would be parsed into a structure equal to Session = Session {IMSI: "123456789012345", APN: "some.apn.com", Activated: true,}. The value structure contains all GTP message related information, such as all TEIDs (newly generated, original; C-plane, U-plane; for SGSN / GGSN / SGW / PGW), APN used, GTP-U node and tunnel information, GGSN / SGSN / SGW / PGW IP addresses and origin port and address, timestamp, etc. The create message associates an IMSI key with such a value structure, and the TEID as the key with the IMSI as the value. The hash can be obtained by reading the header TEID to determine the IMSI, or it can be queried. The TEID value can then be obtained using the IMSI as the key. That is, the session information can be obtained using the information contained in the message header, including all relevant session information.

[0087] A hash can be obtained using one of the TEIDs, which allows the IMSI for the session to be obtained from the hash. A hash can be obtained using the IMSI to obtain the generated TEID. Other combinations of key values ​​are possible to allow for retrieval of session information.

[0088] For example, there is a GTP message and generated TEIDs, just in case. The IMSI from the GTP create message will serve as the primary key for the lifetime of the context / session. Generated TEIDs are generated during the create request processing and are used to avoid TEID collisions. These TEIDs replace the TEID-C and TEID-U information elements in the GTP message. All subsequent messages use these TEIDs in the GTP header.

[0089] For example, if the IMSI in the create request is "12345", the proxy device has two TEID-Cs generated: 0x123 and 0x456 (two additional TEID-Us may also be generated). During the generation of TEIDs, they are associated with a given IMSI and stored as a key-value pair: TEID as key, IMSI as value: "SET TEID_0x123 12345" "SET TEID_0x456 12345"

[0090] All information is then stored in a GTP struct: IMSI, original TEID, generated TEID, IP address, SEQ, timestamp, and all other relevant information. The GTP struct can be converted into Redis hash format - "member-value" pairs.

number

[0091] This hash is stored in a database, for example a Redis database, as a key-value pair: IMSI as key, hash as value: “HSET IMSI_12345 Activated 1 IMSI 12345 APN some.apn.com...”.

[0092] For all subsequent messages, the GTP header will have one of the generated TEID-c as header TEID-c. Using this TEID, the context / session information can be obtained.

[0093] "GET TEID_0x123" - returns IMSI value 12345

[0094] "HGETALL IMSI_12345" - returns the entire hash

[0095] The hash is then scanned into a GTP struct to work with.

[0096] FIG. 4 illustrates the present invention with respect to GTP messages, e.g., generic or subsequent GTP messages. A connection has previously been established through the proxy device using two GTP tunnel connections connecting the proxy device to each of two gateways. The establishment of the tunnel connections may include the exchange of create session request and create session response messages, as described above. The proxy device stores state information of the previous state, i.e., state information related to the first tunnel connection and the second tunnel connection, in memory 416. The first tunnel connection is associated with the GTP tunnel between the first gateway and the proxy device, and the second tunnel connection is the GTP tunnel between the proxy device and the second gateway. The state information includes an IP address, a TEID, and optionally, a sequence number, a timestamp, an APN, and an IMSI for each GTP tunnel connection. For example, the state information may include four TEIDs for the control plane, two TEIDs associated with the first tunnel connection, and the remaining two TEIDs associated with the second tunnel connection. There may also be four TEIDs for the user plane. Generally, the state information may include eight TEIDs, two pairs of TEIDs for the control and user planes for each tunnel connection. The state information also includes the IP addresses of each entity sending and receiving messages over the established tunnel connection. The IP addresses are used to route messages to each entity. For example, in the case of control and user plane separation (CUPS), there may be different IP addresses assigned to entities for the control and user planes.

[0097] FIG. 4 shows a subsequent GTP message sent (430) from the first gateway 44 to the proxy device 46. The message is received by the load balancer 45 of the proxy device. The load balancer selects a node 47, 48, or 49 of the proxy device. The load balancer 45 forwards (431) the message to the selected node 47. The message carries the TEID of the proxy device of the first connection as a header TEID. The header TEID may be, for example, a control plane TEID if the message is a control message. The message may optionally further include the TEID(s) of the first gateway 44 associated with the first tunnel connection. The node 47 queries (420) the database 416 for state information associated with a previous state. The query may be based on the header TEID. If the database stores state information associated with the previous state associated with the header TEID, the state information is retrieved (421) by the node 47. The node associates the message with the first tunnel connection based on the retrieved state information associated with the previous state. The association of the message with the previous state may be based on matching the TEID, i.e., the header TEID and / or the optional TEID of the first gateway 44, with the TEID(s) associated with the first tunnel connection stored in the state information of the previous state. The node then forwards (422) the message over the second tunnel connection stored in the state information associated with the previous state. To forward the message over the second GTP tunnel connection, the header TEID and optionally the origin TEID for the control and user planes, and information fields related to the origin and destination IP addresses are replaced with the corresponding values ​​of the second tunnel connection included by the state information associated with the previous state, i.e., the tunnel endpoint identifier of the second gateway 417 and the TEID for the control and user planes of the proxy device associated with the second tunnel connection.After replacing the header TEID and, optionally, the TEIDs for the control and user planes and the IP addresses of the origin and destination entities, these information fields of the message are masked, i.e., from the perspective of the second gateway 417, the message appears to originate from the proxy device 46. Accordingly, the message does not contain any information that can be linked to the first gateway 44. The node's acquisition of state information related to the previous state allows it to process tunnel connections on a message-by-message basis instead of associating each tunnel with one specific device that stores the tunnel information. When processing tunnel connections on a message-by-message basis, each message can be processed by a different entity, for example, node 47, 48, or 49 of the proxy device 46. After the node masks the relevant information fields, the node stores state information in memory, including the IP addresses and TEIDs of the first and second tunnel connections. The state information can be stored using a key-value store. The state information can be stored in a hash within the key-value store. The header TEID can be used as a key. The expected header TEID can be used as a key. For example, one of the TEIDs of the first or second tunnel connection associated with the proxy device can be used as a key because any message belonging to one of these tunnel connections can have one of the TEIDs associated with the first and second tunnel connections identifying the endpoint at the proxy device as the header TEID. Therefore, because nodes use the header TEID for each message to obtain state information, any generic GTP message that carries a TEID associated with stored state information related to a previous state can be processed by any of the nodes of the proxy device. Thereafter, for each forwarded message, the node updates its memory by storing information related to the current state in memory. Thus, for subsequent messages, this state information is the state information related to the previous state. The sequence number SEQ can also be masked, as described above in connection with FIGS. 2 and 3.That is, the SEQ present in the message header is stored with the state information for the first or incoming tunnel connection and replaces the generated SEQ for the second or outgoing tunnel connection.

[0098] As shown above, in contrast to established GTP processing, where each state is associated with two entities that exchange messages and store the relevant state information themselves, retrieval from memory based on specific information allows for memory-by-memory retrieval of state information, which in turn allows different entities to process messages associated with the same tunnel connection.

[0099] FIG. 5 illustrates a system after the establishment of two GTP tunnel connections connecting a first gateway and a second gateway via a proxy device 53. The first gateway, which may be an SSGN, is connected to the proxy device via the first tunnel connection. Respective tunnel endpoint identifiers are a first tunnel endpoint identifier 52 of the first gateway 51 and a second tunnel endpoint identifier 54 of the proxy device 53. The tunnel endpoint identifiers may include tunnel endpoint identifiers for the control and user planes of the tunnel connection. A second GTP tunnel is established between the proxy device 53 and the second gateway, which may be a GGSN. Respective tunnel endpoint identifiers defining the second tunnel connection are a fourth tunnel endpoint identifier 55 of the proxy device 53 and a third tunnel endpoint identifier 57 of the second gateway 56. Messages sent from the first gateway carry the control plane TEID of the second tunnel endpoint identifier 54 of the proxy device as the header TEID and, optionally, the first tunnel endpoint identifier 52 of the first gateway 51 as the origin TEID. Messages sent from the proxy device to the first gateway carry the control plane TEID of the first tunnel endpoint identifier 52 as the header TEID and optionally the second tunnel endpoint identifier 54 of the proxy device 53 as the origin TEID. Messages sent from the proxy device 53 to the second gateway 56 carry the control plane TEID of the third tunnel endpoint identifier 57 of the second gateway 56 as the header TEID and optionally the fourth tunnel endpoint identifier 55 of the proxy device 53 as the origin TEID.A message sent from the second gateway 56 to the proxy device 53 carries the control plane TEID of the fourth tunnel endpoint identifier 55 of the proxy device 53 as the header TEID and optionally the third tunnel endpoint identifier 57 of the second gateway 56 as the origin TEID.

[0100] Furthermore, any control message sent to the proxy device through one tunnel connection is processed by the load balancer such that only the selected node to which the message is forwarded queries the database for state information, i.e., the tunnel endpoint identifiers associated with the first and second tunnel connections, and then the node replaces the message's header TEID according to the state information and forwards the message through the other tunnel connection.

[0101] 6 shows a schematic diagram of a proxy device according to an example of the present invention. A message is sent from a user equipment (UE) 601, which may be a user device, e.g., a mobile phone. The user equipment (UE) 601 may be connected to a first or ingress gateway 604, which may be an SGSN or SGW, via a radio access network (RAN) 602. The first gateway 604 forwards the message to a proxy device 603. For example, the message may carry the IP address of the proxy device as the destination IP address.

[0102] The proxy device includes several nodes 609, 610, and 611. The proxy device further includes a first load balancer 607. The first load balancer may process traffic from a first gateway 604. The first load balancer may be a serving-side load balancer, or in short, a serving load balancer SLB 607. The first load balancer 607 may balance the load caused by incoming traffic from the first gateway among the nodes 609, 610, and 611 of the proxy device 603. The proxy device may include a second load balancer 616 configured to process incoming traffic from a second or egress gateway 618, which may be a GGSN or a PGW. The second load balancer may be a packet-side load balancer, or in short, a packet load balancer PLB 618. A message from the UE is received at the first gateway 604. The message may be, for example, a create request message (hereinafter also referred to as create session request message), an example of which may be, for example, a create PDP request message. An example of the structure of a create request message is given in the table below: [Table 1] With respect to the table above, different messages differ in message type. While headers are present in GTP messages, the information elements (IEs) vary by message type and may be different for messages of different types. The GTP version may also affect the structure of the create request message. For example, a message according to GTP version 2, GTPv2, has a header that is longer than the header of a message according to the GTP version 1 (GTPv1) protocol and contains different IEs than those present in a message according to the GTPv1 protocol.

[0103] The first gateway 604 forwards the incoming message to a first load balancer 607 (605). The first load balancer 607 selects a node 609, 610, or 611 of the proxy device 603 based on load criteria and forwards the incoming message to the selected node. The node analyzes the incoming message and determines that the header TEID of the message contains the control and / or user plane TEID of the proxy device, i.e., the message was sent through an established tunnel and therefore retains the TEID as the header TEID corresponding to the TEID of the proxy device for this tunnel. The proxy device then queries a database 617 for state information associated with the header TEID of the incoming message, thereby querying the database 617 for state information related to the previous state for this particular tunnel. The database 617 stores state information from multiple nodes of the proxy device, and the state information relates to the first tunnel connection between the first gateway 604 and the proxy device 603 and the second tunnel connection between the proxy device 603 and the second gateway 618. The state information thus stores the TEIDs for the two tunnel connections, enabling, for example, a node to forward a message from one tunnel to the other tunnel substituting the respective header fields. The state information relates to a connection between a first gateway and a second gateway. Specifically, the state information relates to a connection between the first gateway and the second gateway via a proxy device. Accordingly, the state information may include the headers TEI and TEID I, as well as the TEID control plane, for the tunnel connection between the first gateway and the proxy device and the associated tunnel connection from the proxy device to the second gateway.

[0104] The information related to the previous state includes the original value contained in the incoming message, i.e., the TEID of the proxy device 603 for the first incoming tunnel from the first gateway 604, and a masked value, i.e., the TEID of the proxy device for the second outgoing tunnel between the proxy device 603 and the second gateway, which has been replaced by the proxy device 603 so that the new value is associated with the original value of the incoming message received from the ingress gateway 604.

[0105] In the case of a create session request message, the header TEID of the incoming message is zero. Specifically, since there is no tunnel connection yet, the header TEID is zero. The message is forwarded to the node of the proxy device by the load balancer that processes the message. Because the header TEID is zero, the IMSI is used as a primary key for storing state information to check whether previous state information exists. Using the IMSI to check the existence of previous state information stored in the database can be done to close a dangling tunnel and create a new one. This can be useful, for example, when one or both gateways are restarted and send a new create request, and the proxy device has not received a delete request and therefore still has state information for the tunnel connection belonging to the stored IMSI. Because the header TEID is zero and the message is a create request, the proxy device accordingly deletes the state information associated with this IMSI. Specifically, the proxy device deletes the state information before storing the state information for the new create request. For a create session request message (e.g., a create PDP context request message), the header TEID is zero. The information elements "TEID Data I" and "TEID Control Plane" are TEIDs for the response message and will be used as header TEIDs in the response message. Therefore, the create session request message carries the TEID of the first gateway of the first tunnel to be established. Any response message carries one of these TEIDs as the header TEID. Accordingly, the first gateway 604 receiving a message with one of these TEIDs as the header TEID knows that the message belongs to the tunnel associated with these TEIDs. Upon receiving an incoming create session request message, the proxy device node may generate a new TEID. In the case of a create session request, the proxy device may generate a new TEID as the endpoint of the incoming tunnel and as the starting point for the second outgoing tunnel to the second gateway.Accordingly, the node then replaces the TEID Data I and the TEID Control Plane with the newly generated TEID associated with the starting point of the second tunnel.

[0106] However, a GTP node may also generate a new TEID if the header TEID in an incoming message is non-zero. This occurs, for example, in the case of a message update / modification. These messages already have some connection (the header TEID should be non-zero for an established connection), and the GTP nodes 609, 610, 611 may update it. In this case, the message may have a new TEID IE (Updated Tunnel ID Information field). For example, a pair of a first tunnel and a second tunnel is defined by eight TEIDs: a pair of TEIDs for the first gateway, a pair of TEIDs for the proxy device for the first tunnel connection between the first gateway 604 and the proxy device 603, a pair of TEIDs for the proxy device 603 for the second tunnel connection between the proxy device 603 and the second gateway 618, and a pair of TEIDs for the second gateway 618 for the second tunnel connection between the proxy device and the second gateway. In the case of a message update / modification, one of the tunnels may be updated. In response, the node generates a new TEID for this tunnel connection.

[0107] When other messages are received, for example, any subsequent messages after the session is created, the IMSI is not necessarily present, but a non-zero header TEID is used to obtain the previous state value. The state information is stored in a database 618. The state information includes the TEIDs of the first and second tunnel connections connecting the first gateway 604 to the second gateway 618 through the proxy device.

[0108] In the case of a newly established connection, the proxy device 603 generates a proxy device TEID for the control and user plane for the first connection between the ingress gateway 604 and the proxy device's node 609, 610, 611, i.e., the first tunnel connection, and a proxy device TEID for the control and user plane for the second connection between the egress gateway 618 and the proxy device's node, i.e., the second tunnel. In the case of a create request, i.e., if the message is a create request message, the header TEID should be 0 and the IMSI IE (information element) is present in the GTP message. Even in this case, upon receiving a request message with a header TEID equal to zero, the node to which the load balancer is forwarding the message still queries the database 617 because of a possible abnormal situation. For example, the SGW is restarted and sends a create request message for an IMSI to which the proxy device has already established a connection. In another situation, one of the proxy devices or nodes may have failed to delete the message for some reason, for example, due to a UDP undelivered problem. Therefore, the node of the proxy device queries the database for the IMSI in either case, which means that the node queries the database even if no connection is established for the IMSI associated with the UE. Furthermore, in the abnormal case where state information is stored in the database but there is no connection established for the IMSI, querying the database for that IMSI will confirm that state information is stored. However, because the header TEID is zero, the node determines that no connection can exist and overwrites the stored state information based on the received message.

[0109] If no previous state exists, the proxy device establishes the connection as described above.

[0110] Furthermore, if the request corresponds to an initial connection - no state information exists - but for some reason, e.g., due to an error, the request message carries a TEID that is not equal to zero, the request message is discarded.

[0111] For any other messages, e.g., Update / Delete / Modify / Change Notification messages, the header TEID may or may not be 0 depending on the message. Usually, i.e., in Update / Modify or Delete messages, the header TEID is non-zero. Thus, the previous state can be obtained by using the TEID. The TEID of a tunnel connection identifies the IMSI, which identifies the previous state data or state information.

[0112] Furthermore, some messages, such as change notification messages, have a header TEID=0, but the message also carries the IMSI, so the proxy device can obtain the previous state defining the tunnel connection GTP associated with that IMSI.

[0113] For example, for a message of type "change notification" with header TEID=0, a GTP node does not generate a new TEID.

[0114] Typically, the state information is obtained by the following conversion or association: "TEID → IMSI → previous state data" or, if the header TEID is 0, "IMSI → previous state data." Thus, the state information is obtained using the IMSI, either by directly obtaining the IMSI from the message if the IMSI IE is present, or by deriving the IMSI from the TEID if the IMSI associated with the state information is associated with the TEID carried by the message. In other words, the IMSI is the primary key for the data; for example, the IMSI is associated with the data so that the associated data can be obtained based on the IMSI. However, the tunnel's header TEID(s) can also be associated with the IMSI and then used to obtain previous state data or previous state information. The associated IMSI is identified based on the TEID, and state information is obtained based on the IMSI. Thus, for all messages of a tunnel that carry a header TEID associated with the tunnel, previous state information can be obtained based on the TEID. It is always possible to use the IMSI as a key. Therefore, complete state information can be associated with the IMSI. However, since the TEID of the tunnel is also associated with the IMSI, status information can be obtained for all messages carrying the header TEID belonging to that tunnel. Accordingly, status information of an established tunnel can be obtained based on the TEID alone. Other information may not be carried by the message, and status information can still be obtained using the header TEID.

[0115] The system obtains the previous state information either directly by using the IMSI or by using TEID->IMSI conversion. If the IMSI is not directly available in the message, the TEID can be used as a helper / secondary key to obtain the IMSI, which will then be used to obtain the state.

[0116] 7 shows the logic of a first load balancer 701 and a selected node 702 from multiple nodes 609, 610, 611 in a proxy device 703 for an incoming message 703 from an ingress gateway 704. Similar logic is implemented in a second load balancer 705 and the corresponding selected node for a response message 706 received by the proxy device 703 from an egress gateway 707 and directed to the proxy device 603.

[0117] An incoming message 708 from an ingress gateway may include a header TEID 709. The header TEID may be zero for the first message used to set up a tunneling connection between the ingress gateway 704 and the egress gateway 707. In this case, the incoming message 708 may include an IMSI 710, which is used as a primary key to check or retrieve previous state information 715 from a database 711 if any state information 715 was previously stored (and associated with this IMSI). For subsequent messages, the header TEID 709 includes a control or user plane TEID of the proxy device, which is used by the selected node 702 to retrieve previous state 715 information from the database state 711. The incoming message 708 includes the TEID 712 of the ingress gateway 704 and the control or user plane IP address of the ingress gateway 704. The first load balancer 701 receives the incoming message 708, selects a node 714, and forwards the incoming message 708 to the selected node 702. The selected node 702 queries the database 711 to obtain state information for the previous state 715 (716), generates proxy device TEIDs for the first and second tunnel connections as described above (717), and saves state information 718 in the database 711. Any information related to the IMSI is stored within the state information (previous state 715 / current state 718). As a result, the state information can be identified by the IMSI. All information related to the IMSI is captured within the state information: the original TEID 709, 712 sent by the gateway, IP 713, Seq, generated values ​​(specifically, the TEID and IP address created by the proxy device to mask data), timestamp, GTP version, etc. If the IMSI corresponds to a new connection, the database 711 will be empty for this IMSI because the IMSI and related state information are deleted when a delete request message is received to terminate the tunnel connection. Accordingly, the database 711 does not return any state information.Otherwise, this IMSI key exists in DB 711, and node 702 can retrieve previous state information 715 for this IMSI. Also, if only a few fields in the header of the forwarded incoming message 708 are overwritten, the changes are stored as current state information 718 associated with the IMSI and included in database 711. At the time node 702 retrieves previous state information 715, node 702 has no knowledge of any state information. Therefore, node 702 reads the information from database 711 at the time the state information is requested. For simplicity, FIG. 7 explicitly shows only some of the fields for the "current state state information." The same fields would be present in the "previous state state information."

[0118] The selected node 702 replaces the control and / or user plane IP address 713 of the ingress gateway 704 with the control and / or user plane IP address 719 of the second load balancer 705 in the received incoming message 708 and sends the modified message 720 to the egress gateway 707. In this way, the node 702 spoofs the source IP with that of the second load balancer 705. The source IP address, SRC IP, is a TCP / IP layer 3 IP address and is not the GTP message IP address, and needs to be spoofed so that the message may appear to have been sent from the second load balancer 705; i.e., the layer 3 IP address is replaced by the IP address of the proxy device when the proxy device forwards the message.

[0119] If a GTP message contains information elements that include IP addresses, the IP addresses are replaced accordingly. For example, the source IP address carried by an incoming message is replaced with the IP address of the load balancer that is processing the response to this message. IP addresses on the TCP / IP layer are replaced to spoof the original source address with the IP address of the proxy device. In addition, if the message contains information elements that include IP addresses, these IP addresses may also be replaced.

[0120] In addition to source IP 713 spoofing, GTP node 702 can mask the header TEID 709, the control and / or user plane TEID 712, if present, and the control and / or user plane IP address 713 in the GTP message. Additionally, the sequence number Seq, if present, is also replaced. The egress gateway 707 will use the control and / or user plane IP address of the second load balancer 705 as the return address for the response message. The second load balancer 705 selects a second working node, which may be different from node 702, which forwards the incoming message 708 to the egress gateway 707 and forwards the response message to the selected second working node. State information 715 of the previous state is stored in a database 711 commonly accessible to any node, so that the selected second node can seamlessly assume the existing tunnel to forward the response message to its destination.

[0121] The first and second load balancers 701, 705, which act as entry points for incoming messages 708 (from ingress 704 and egress 707 gateways), together with a database 711 common and accessible to all deployed worker nodes, allow for the implementation of stateless nodes, i.e., nodes that retrieve state information 715 on a per-message basis.

[0122] In this document, the phrase "at least one of A and B" or "at least one of: A and B" should be understood to mean "A only, B only, or both A and B."

[0123] List of examples of the present invention:

[0124] Example 1. In a first example, a proxy device for a wireless communication system includes: a plurality of nodes 7, 8, 9 for providing a plurality of connections between the first gateway 4 and the second gateway 17; a first load balancer that processes incoming traffic from the first gateway; a second load balancer that processes incoming traffic from the second gateway; a database 16 configured to store a plurality of state information for a plurality of connections; the memory 16 stores state information regarding pairs of connections between the proxy device and a first gateway and between the proxy device and a second gateway, the state information regarding the pairs of connections including information regarding a first connection between the proxy device and the first gateway using a first tunnel endpoint identifier, TEID, of the first gateway and a second tunnel endpoint identifier, TEID, of the proxy device, and information regarding a second connection between the proxy device and the second gateway using a third tunnel endpoint identifier, TEID, of the second gateway and a fourth tunnel endpoint identifier, TEID, of the proxy device; The first load balancer is configured to receive a first message from the first gateway, the first message carrying one of the second tunnel endpoint identifiers of the proxy device as a header tunnel identifier, the first load balancer is further configured to select one of the nodes of the plurality of nodes and forward the message to the selected node, the selected node is configured to communicate with a database to request state information associated with the header TEID of the first message, the selected node is further configured to replace the header TEID of the first message with one of the third tunnel endpoint identifiers of the second gateway, the selected node then forwards the first message to the second gateway and The load balancer is configured to receive a second message from the second gateway, the second message carrying one of the fourth tunnel endpoint identifiers of the proxy device as a header tunnel endpoint identifier, the second load balancer is further configured to select one of the nodes from the plurality of nodes and forward the second message to the selected node, the selected node is configured to communicate with a database to request state information associated with the header TEID of the second message, the selected node is further configured to replace the header TEID of the second message with the first tunnel endpoint identifier of the first gateway, and the selected node then forwards the second message to the first gateway.

[0125] Example 2. The proxy device according to example 1, wherein the proxy device further uses General Packet Radio Service (GPRS) Tunneling Protocol (GTP).

[0126] Example 3. The proxy device according to example 1, wherein the plurality of nodes are configured to provide a plurality of connections between the first gateway and the second gateway.

[0127] Example 4. The proxy device of any of the preceding examples, wherein the first message and the second message are GTP control messages and the connection is a GTP tunnel connection.

[0128] Example 5. The proxy device of any of the preceding examples, wherein the header is a GTP header, specifically, a header after the UDP / TCP header.

[0129] Example 6. The proxy device of any of the preceding examples, wherein the message from the first gateway further includes a subscriber identifier to identify the device to which the connection is to be established, and wherein the node is further configured to provide the subscriber identifier and the TEID for the connection to the memory for storage, whereby the subscriber identifier and the TEID for the connection are correlated and stored with the established connection.

[0130] Example 7. The proxy device of any of the preceding examples, wherein the node is further configured to mask the tunnel connection identifier and / or the device identifier before providing it to the memory for storage.

[0131] Example 8. The proxy device of any of the preceding examples, wherein the at least one load balancer is configured to select a node from the plurality of tunneling nodes by selecting from the plurality of tunneling nodes based on load criteria.

[0132] Example 9. The proxy device of any of the preceding examples, wherein the at least one load balancer is configured to select a node from the plurality of tunneling nodes by selecting from the plurality of tunneling nodes in a round robin manner.

[0133] Example 10. The proxy device according to example 9, wherein the tunnel endpoint identifier is a tunnel endpoint identifier according to the GTP protocol, specifically according to GTP protocol version 1 and / or version 2.

[0134] Example 11. The proxy device of any of the preceding examples, wherein the memory includes a key-value store.

[0135] Example 12. A method for providing connectivity between a first gateway and a second gateway using a proxy device in a wireless communication system, the method comprising: storing, by the memory, state information regarding pairs of connections between the proxy device and a first gateway and between the proxy device and a second gateway, the state information regarding the pairs of connections including information regarding a first connection between the proxy device and the first gateway using a first tunnel endpoint identifier of the first gateway and a second tunnel endpoint identifier of the proxy device, and information regarding a second connection between the proxy device and the second gateway using a third tunnel endpoint identifier of the second gateway and a fourth tunnel endpoint identifier of the proxy device; receiving, by a first load balancer, a first message from a first gateway, the first message carrying one of the second tunnel endpoint identifiers of the proxy device as a header tunnel identifier and optionally the first tunnel endpoint identifier of the first gateway as an origin tunnel endpoint identifier; selecting, by a first load balancer, one of the nodes from the plurality of nodes; - forwarding the message to the selected node by a load balancer; communicating, by the selected node, with a database to request state information associated with the header TEID of the first message; replacing, by the selected node, the header TEID of the first message with one of the third tunnel endpoint identifiers of the second gateway and optionally replacing the origin TEID of the first message with the fourth tunnel endpoint identifier of the proxy device, wherein the selected node then forwards the first message with the replaced TEID to the second gateway; receiving, by a second load balancer, a second message from the second gateway, the second message carrying one of the fourth tunnel endpoint identifiers of the proxy device as a header tunnel identifier and optionally the third tunnel identifier of the second gateway as an origin tunnel endpoint identifier; selecting, by a second load balancer, one of the nodes from the plurality of nodes; forwarding, by a second load balancer, the second message to the selected node; communicating with the memory, by the selected node, to request state information associated with the header TEID of the second message; replacing, by the selected node, the header TEID of the second message with one of the first tunnel endpoint identifiers of the first gateway and optionally replacing the origin TEID of the second message with the second tunnel endpoint identifier of the proxy device, wherein the selected node then forwards the second message to the first gateway. The method includes the step of:

[0136] Example 13. A method according to any of the preceding examples, wherein the selecting step selects a node from the plurality of tunneling nodes in a round-robin manner or by selecting a node from the plurality of tunneling nodes based on a load criterion.

[0137] Example 14. The method according to example 12, wherein the memory is a key-value store, and the step of communicating with the key-value store includes using the IMSI as the key.

[0138] Example 15. A computer program product comprising instructions that, when executed by a processor, cause the processor to perform a method according to any of Examples 12-14.

Claims

1. A proxy device (25, 603, 703) for a wireless communication system, comprising: a plurality of nodes (7, 8, 9, 609, 610, 611) for providing a plurality of connections between an ingress gateway (4, 604, 704) and an egress gateway (17, 618, 707); a first load balancer (5, 607, 701) configured to process incoming traffic from the ingress gateway (4, 604, 704) and a second load balancer (14, 616, 705) configured to process incoming traffic from the egress gateway (17, 618, 707); Including, The first load balancing device (5, 607, 701) receiving a message (708) from said ingress gateway (4, 604, 704); selecting a node (702) from a plurality of nodes (7, 8, 9, 609, 610, 611), said node (702) being selected by said load balancer (5, 607, 701); Retrieving state information associated with a previous state from a database (16, 617, 711); replacing the IP address of the ingress gateway (4, 604, 704) with the IP address of the second load balancer (14, 616, 705) in the received message (708); Sending the received message (708) including the IP address of the second load balancer (14, 616, 705) to the exit gateway (17, 618, 707). It is structured as follows: configured to: Proxy device (25, 603, 703).

2. 2. The proxy device of claim 1, wherein the plurality of nodes (7, 8, 9, 609, 610, 611) are configured to store state information for the plurality of connections in the database (16, 617, 711), the state information including original values ​​and masked values, and the masked values ​​are associated with the original information of the message received from the ingress gateway (4, 604, 704).

3. The proxy device (25, 603, 703) of claim 1 or claim 2, wherein the selected node (702) is further configured to provide state information (718) related to a current state of the message from the ingress gateway (4, 604, 704) to the database for storing the state information (718) related to the current state, and the provided state information (718) is retrievable by any node of the plurality of nodes (7, 8, 9, 609, 610, 611).

4. Proxy device (25, 603, 703) according to any of the preceding claims, wherein the previous state information (715) obtained by the node (702) was previously stored in the database by a different node.

5. A proxy device (25, 603, 703) as described in any preceding claim, wherein the message from the ingress gateway (4, 604, 704) includes at least one of the following: a tunnel connection identifier for identifying a tunnel connection between the ingress gateway (4, 604, 704) and the proxy device, and a device identifier for identifying the device to which the connection is established.

6. 6. The proxy device (25, 603, 703) of claim 5, wherein, in response to being selected by the load balancer, the node is further configured to replace, in the received message (708), the tunnel connection identifier identifying the tunnel connection between the entry gateway (4, 604, 704) and the proxy device (25, 603, 703) with a tunnel connection identifier identifying a tunnel connection between the proxy device (25, 603, 703) and the exit gateway (17, 618, 707).

7. 6. The proxy device (25, 603, 703) of claim 5, wherein the node (702) is further configured to provide at least one of the following: the device identifier and the tunnel connection identifier for the connection to the database for storage, the device identifier and the tunnel connection identifier being associated with each other and stored together with the connection between the entry gateway (4, 604, 704) and the exit gateway (17, 618, 707).

8. The proxy device (25, 603, 703) according to any one of claims 5 to 7, wherein the previous state information is retrieved from the database based on the tunnel connection identifier or based on the device identifier.

9. Proxy device (25, 603, 703) according to any of the preceding claims, wherein the load balancer (5, 607, 701) is configured to select the node (702) from the plurality of nodes by selecting from the plurality of nodes (7, 8, 9, 609, 610, 611) based on a load criterion.

10. Proxy device (25, 603, 703) according to any of the preceding claims, wherein the load balancer (5, 607, 701) is configured to select the node (702) from the plurality of nodes (7, 8, 9, 609, 610, 611) by selecting from the plurality of nodes in a round-robin manner.

11. The proxy device (25, 603, 703) according to any of claims 5 to 10, wherein the tunnel connection identifier corresponds to a Tunnel Endpoint Identifier (TEID) and / or the device identifier corresponds to an International Mobile Subscriber Identity (IMSI).

12. 6. A proxy device (25, 603, 703) according to any preceding claim, wherein the proxy device includes the database (16, 617, 711), the database (16, 617, 711) configured to store state information from the plurality of nodes (7, 8, 9, 609, 610, 611), and wherein any of the plurality of nodes can query the database (16, 617, 711) for any of the state information.

13. 1. A method for providing a tunnel connection between an ingress gateway (4, 604, 704) and an egress gateway (17, 618, 707) using a proxy device (25, 603, 703) in a wireless communication system, comprising: receiving, by a first load balancer (5, 607, 701), a message (708) from an ingress gateway (4, 604, 704); selecting a node from a plurality of nodes by the first load balancing device (5, 607, 701); retrieving, by said selected node, state information relating to a previous state (715) from a database (16, 617, 711); replacing, by the selected node, in the received message (708), the IP address of the ingress gateway (4, 604, 704) with the IP address of a second load balancer (14, 616, 705); sending, by the selected node, the received message (708) containing the IP address of the second load balancer (14, 616, 705) to the exit gateway (17, 618, 707); A method comprising the step of:

14. 14. The method of claim 13, further comprising: replacing, by the selected node (702), in the received message (708), a tunnel connection identifier identifying a tunnel connection between the ingress gateway (4, 604, 704) and the proxy device (25, 603, 703) with a tunnel connection identifier identifying a tunnel connection between the proxy device (25, 603, 703) and the egress gateway (17, 618, 707).

15. 15. The method of claim 14, further comprising providing the database (16, 617, 711) with the original and replaced tunnel connection identifiers for storage in the database in association with the connection between the ingress gateway (4, 604, 704) and the egress gateway (17, 618, 707).

16. 16. The method of claim 14, wherein the selecting step selects the node (702) from the plurality of nodes (7, 8, 9, 609, 610, 611) by selecting from the plurality of nodes (7, 8, 9, 609, 610, 611) in a round-robin manner or based on load criteria.

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

Images