WO2019179634A1

WO2019179634A1 - Method and apparatus for dynamic network address translation

Info

Publication number: WO2019179634A1
Application number: PCT/EP2018/057546
Authority: WO
Inventors: Hans-Jochen Morper; Markus Bauer-Hermann
Original assignee: Nokia Solutions And Networks Oy
Priority date: 2018-03-23
Filing date: 2018-03-23
Publication date: 2019-09-26

Abstract

The application relates to the selection of one of at least two instances (51, 52) of a network application to be served for a terminal device (10) and the setting of at least one rule for address translation, based on the selected instance, to be applied at a network address translation function (40) for an address context of at least one of the terminal device (10) and the network application. The at least one rule for address translation is requested from the network based on the address context of a received transmission packet and the network address translation for the received transmission packet is performed by using the received at least one rule for address translation.

Description

Method and apparatus for dynamic network address translation

Field

Various example embodiments relate to the field of network address translation in data networks.

Background

A cellular network or mobile network is a communication network where the last link between the network access device (e.g. base station) and the mobile device is wireless. The access network is distributed over land areas called cells, each served by at least one fixed-location transceiver of the network access device. These network access devices provide the cell with the network coverage which can be used for transmission of voice, data and others. Additionally, the core network offers numerous services to customers who are interconnected by the access network. Facilities and devices used for the core or backbone networks are usually routers and switches. Moreover, gateways are used in the core network for accessing other networks. The functionality of gateways depends on the kind of network to which it is connected.

In telecommunication, Long-Term Evolution (LTE) is a standard for highspeed wireless communication for mobile devices and data terminals. It increases the capacity and speed using a different radio interface together with core network improvements. The standard is developed by the 3GPP (3rd Generation Partnership Project) and is specified as fourth generation (4G) wireless service.

The next step in mobile technology is the fifth generation (5G). 5G core networks allow to offer services with low latency.

Summary

There is provided according to a first example a method comprising:

selecting one of at least two instances of a network application to be served for a terminal device; and setting based on the selected instance at least one rule for address translation to be applied at a network address translation function for an address context of at least one of the terminal device and the network application.

The at least two instances of the network application may be located at different data centres of the network.

The selecting and setting step may be performed at an application function of the network.

The at least one rule for address translation may comprise header modification rules for incoming and outgoing transmission packets.

The method of the first example may further comprise deciding to move control of the application to another one of the at least two instances of the network application.

The method may comprise reporting a corresponding at least one new rule for address translation to the network address translation function. As an example, this decision to move control of the application may be based on at least one of a server load at the selecting one of the at least two instances of the network application and a location of the terminal device.

According to a second example there is provided a method comprising: receiving a transmission packet with at least one of a source address and a destination address in a network;

requesting or causing a request to be transmitted, at least one rule for address translation based on the at least one of the source address and the destination address of the received transmission packet;

receiving at least one rule for address translation for the at least one of the source address and the destination address; and

performing network address translation for the received transmission packet by using the received at least one rule for address translation. The requesting may be from the network or an entity thereof.

The receiving may be from the network or an entity thereof.

It is noted that throughout this application the term“network” is to be understood to cover all entities and applications and application control functions involved in the described embodiments and thus also covers application eco system (s). It is not restricted to a core network or other specific network part(s).

The at least one rule for address translation may comprises header modification rules for incoming and outgoing transmission packets.

The header modification rules for incoming transmission packets may comprise replacing the destination address of the received transmission packet by a predetermined network address of a selected instance of a destination application. Alternatively or additionally, the header modification rules for outgoing transmission packets may comprise replacing the source address of the received transmission packet by the predetermined network address of the selected instance of the destination application.

The step of requesting at least one rule for address translation may comprise sending a query to with the at least one of the source address and the destination address of the received transmission packet to an application function of the network.

The transmission packet may be received from one of at least two instances of a network application.

According to a third example there is provided an apparatus comprising: at least one processor; and

at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus to select one of at least two instances of a network application to be served for a terminal device, and to set based on the selected instance at least one rule for address translation to be applied at a network address translation function for an address context of at least one of the terminal device and the network application.

According to a fourth example there is provided an apparatus comprising: means for selecting one of at least two instances of a network application to be served for a terminal device, and

means for setting based on the selected instance at least one rule for address translation to be applied at a network address translation function for an address context of at least one of the terminal device and the network application.

According to a fifth example there is provided an apparatus comprising: a selector configured to select one of at least two instances of a network application to be served for a terminal device; and

a setting unit configured to set based on the selected instance at least one rule for address translation to be applied at a network address translation function for an address context of at least one of the terminal device and the network application.

According to a sixth example there is provided an apparatus configured to cause the apparatus to select one of at least two instances of a network application to be served for a terminal device, and to set based on the selected instance at least one rule for address translation to be applied at a network address translation function for an address context of at least one of the terminal device and the network application.

According to a seventh example there is provided an apparatus

comprising:

at least one processor; and

at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus to receive a transmission packet with at least one of a source address and a destination address in a network, request from the network at least one rule for address translation based on the at least one of the source address and the destination address of the received transmission packet, receive from the network the at least one rule for address translation for the at least one of the source address and the destination address, and perform network address translation for the received transmission packet by using the received at least one rule for address translation.

According to an eighth example there is provided an apparatus comprising: means for receiving a transmission packet with at least one of a source address and a destination address in a network;

means for requesting work at least one rule for address translation based on the at least one of the source address and the destination address of the received transmission packet;

means for receiving the at least one rule for address translation for the at least one of the source address and the destination address; and

means for performing network address translation for the received transmission packet by using the received at least one rule for address translation.

According to a ninth example there is provided an apparatus configured to receive a transmission packet with at least one of a source address and a destination address in a network, request from the network at least one rule for address translation based on the at least one of the source address and the destination address of the received transmission packet, receive from the network the at least one rule for address translation for the at least one of the source address and the destination address, and perform network address translation for the received transmission packet by using the received at least one rule for address translation.

According to a tenth example there is provided an apparatus comprising: a receiver for receiving a transmission packet with at least one of a source address and a destination address in a network;

a requestor for requesting at least one rule for address translation based on the at least one of the source address and the destination address of the received transmission packet; and

an address translator for performing network address translation for the received transmission packet by using the received at least one rule for address translation;

wherein the receiver is configured to receive the at least one rule for address translation for the at least one of the source address and the destination address.

According to an eleventh example there is provided a system comprising an application function with an apparatus according to the third, fourth, fifth or sixth aspect and at least one network address translation function with an apparatus according to the seventh, eighth, ninth or tenth aspect.

According to a twelfth example there is provided a computer program comprising program instructions for causing a computer to perform the method according to any of the method examples.

According to another example there is provided an apparatus comprising means for:

selecting one of at least two instances of a network application to be served for a terminal device, and

setting based on the selected instance at least one rule for address translation to be applied at a network address translation function for an address context of at least one of the terminal device and the network application.

receiving a transmission packet with at least one of a source address and a destination address in a network; requesting at least one rule for address translation based on the at least one of the source address and the destination address of the received transmission packet;

receiving the at least one rule for address translation for the at least one of the source address and the destination address; and

performing network address translation for the received transmission packet by using the received at least one rule for address translation.

According to another example there is provided a method comprising:

causing a request to be transmitted for at least one rule for address translation based on the at least one of a source address and a destination address of a packet;

receiving at least one rule for address translation for at least one of the source address and the destination address; and

performing network address translation for at least one source address and destination address using the received at least one rule for address translation.

According to another example there is provided an apparatus comprising: at least one processor; and

at least one memory including computer program code;

the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus to cause a request to be transmitted for at least one rule for address translation based on at least one of a source address and a destination address, receive at least one rule for address translation for at least one of the source address and the destination address, and perform network address translation for at least one of the source address and the destination address by using the received at least one rule for address translation.

The computer program product may be stored on a medium and may cause an apparatus to perform the method as described herein.

A chipset may comprise the apparatus as described herein. Summary of the Figures

For a better understanding of the present application, reference will now be made by way of example to the accompanying drawings in which:

Figures 1 A and 1 B show schematically a network architecture with different traffic paths with and without dynamic placement of the UPF, respectively;

Figure 2 shows schematically a block diagram of a network architecture with a dynamic NAT function according to a first exemplary embodiment;

Figure 3 shows schematically a signalling diagram of a procedure with a dynamic NAT function according to the first exemplary embodiment;

Figure 4 shows schematically a block diagram of a network architecture with multiple instances of a dynamic NAT function according to a second exemplary embodiment;

Figure 5 shows schematically a signalling diagram of an application-initiated procedure with a dynamic NAT function according to a third exemplary embodiment; and

Figure 6 shows schematically different stages of a network implementation with dynamic offload capabilities.

Embodiments of the Application

Typically, in pre-5G networks like LTE, all traffic from users to users or from users to services, e.g. Internet services, is conveyed via gateways (e.g. serving gateway (S-GW) and packet data gateway (P-GW)) so that all traffic is suffering additional propagation delay resulting from terrestrial (optical) transmission lines. For example, if a gateway is located about 2000 km apart from two users which are located close to each other (even being in the same room) the additional propagation round-trip delay may sum up to almost 50ms taking into account that speed of light in optical fibres is only 200000km/s and optical lines do not follow the shortest distance between user access and gateways.

The 5G core network comprises various network functions or entities including, among others, a session management function (SMF), a policy control function (PCF), an authentication server function (AUSF), a user plane function (UPF), and user data management (UDM). If a user equipment (UE), e.g. mobile terminal, smartphone or the like, has multiple sessions, different SMFs may be allocated to each session to manage them individually and possibly provide different functionalities per session. Additionally, an application eco system (which may be run by any over-the-top (OTT) service provider or by a mobile network operator (MNO)) provides and application function (AF) which is an entity outside the 5G core network and which communicates with the 5G Core network. The AF provides information on the packet flow to the PCF responsible for policy control to support quality of service (QoS). User plane and control plane are separated. The user plane carries user traffic while the control plane carries signaling in the network. The UPF is in the user plane and all other network functions are in the control plane. Separating the user and control planes allows each plane resource to be scaled independently. It may also allows UPFs to be deployed separately from control plane functions in a distributed fashion. In the 5G architecture, UPFs may be deployed very close to UEs to shorten the round-trip time (RTT) between UEs and data network for applications requiring low latency.

The AF informs the network about possible locations (e.g. data centres) for an application or service and in return will be informed by the network if a user is better served from another location. When implementing a service that is based on applications that can be multi-instantiated and which are controlled by the AF, there are currently no rules or specifications available on how this interworking shall apply. Thus, it is in the responsibility of a service provider how this application/AF interworking is realized, as long as the interworking between the AF and the 5G core network is in line with 3GPP specifications. However, there are some addressing issues that are common for any possible implementation, and those are related to Internet Protocol (IP) address mapping or network address translation (NAT).

According to the 3GPP specifications, if a new UPF is instantiated to convey traffic to a different egress (outgoing location), i.e. to a data centre at a different location, the UE shall be kept unaffected. Thus, there will be no specific service interworking, especially no change of IP address (neither client/UE nor application). Additionally, 3GPP allows Internet Protocol version 6 (IPv6) multihoming. However, this would require full IPv6 support at application side, devices and mobile core network - which might be considered unlikely. This demands for a solution in the application/AF framework that allows to keep IP address contexts end-to-end and to mediate local/global IP addresses accordingly. In today’s networks (e.g. the Internet), this role may be taken by the NAT function that, for example, mediates private IP addresses of a home or campus network to public IP addresses and vice versa.

In a flexible application instance or served UE context, the role of this NAT function needs to be extended in order to allow flexible IP address interworking inside-out and outside-in. This issue may become visible when first implementing an application framework as described above.

In the following, exemplary embodiments are described based on an exemplary 5G network architecture with enhanced NAT function that can be dynamically re-configured to allow flexible network address mappings.

The 5G network architecture offers flexibility with respect to placing a user plane anchor such that the terrestrial line that needs to be bridged is significantly smaller. The service related to this feature is called dynamic traffic off load or local breakout (LBA). However, flexible placing of the UPF based on the users’ location requires a decent interworking between application (s) and the 5G core network. To allow minimizing the terrestrial distance between a user/UE, respectively, and service, or application, respectively, the application should also be moved or multi- instantiated at different locations or data centres. Therefore, a handshake between the application and the 5G core network is necessary, which can be achieved by the role of the AF. It is proposed to indicate a possible move of an UE (“early notification”) to the AF allowing the AF to bring an application instance into a mode in which it can continue to serve a user/UE from another location. The network can inform the AF when a move has been successfully carried out, i.e., a new UPF instance is setup and traffic will be conveyed via this instance (“late notification”) indicating to the AF that the user/UE shall be served by the new application or instance. The AF may then instruct the new application instance to serve and the current instance to stop serving.

Figures 1 A and 1 B show network architectures with two respective scenarios involving a 5G core network (Figure 1 B) and a“pre-5G” network (Figure 1A) with resulting difference in latency and terrestrial traffic paths. In the network of Figure 1A, the traffic of a first UE 10 which intends to communicate with a second UE 12 is routed based on a NAT function (not shown) via a first path 100 to a fixed predetermined (central) UPF (e.g. data centre) 30 and from there via a second traffic path 130 to the second UE 12, although another UPF 20 would be located much closer to the first and second UEs 10, 12.

In the 5G core network of Figure 1 B, a configurable NAT function (not shown) can be controlled to allow dynamic placement of the UPF based on the location of the first and second UEs 10, 12. The NAT function may thus ensure proper service continuity in case a UPF relocation takes place. Here, the traffic of the first UE 10 which intends to communicate with the second UE 12 is routed to the nearby UPF 20 via a much shorter first path 100 and from there via a much shorter second traffic path 120 to the second UE 12.

Thus, due to the proposed dynamic placement of the UPF in the scenario of Figure 1 B, traffic paths can be shortened leading to less overall traffic in the network and lower delays in individual connections.

Figure 2 shows an implementation of a configurable NAT function 40 according to a first exemplary embodiment. The operation of the NAT function 40 and its interworking with other entities will be explained later with reference to Figure 3.

In Figure 2, an AF 60 is configured to control activities of an application with respect to an individual connection to a UE 10 with an IP address“IP-UE”. In this example, the application is instantiated twice by the AF 60 as a first application instance (AppX1 ) 51 running on a first server S1 with a first IP address“IP-S1” and as a second application instance (AppX2) 52 running on a second server S2 with a second IP address“IP-S2”, while both application instances 51 , 52 may be resided in the same data centre. The NAT function 40 is provided in a data centre of a third server S3. Consequently, the first application instance 51 can be addressed by the IP address“IP-S1 " and the second application instance 52 by the IP address “IP-S2” inside the data centre. In order to keep the application framework hidden to the user, the application may be addressable by a generic IP address ΊR-appx”. This IP address can be registered, alongside with a uniform resource locate r (URL), e.g.“www.appx.com” at a domain name server (DNS) 70. The registration at the DNS 70 may be done by the AF 60. Thus, whenever the UE 10 requests to contact the application by opening a browser (e.g. typing the URL), the DNS 70 will deliver“IP-appx” as IP address.

The AF 60 can decide, based on rules, e.g. based on server load etc., which of the first and second application instances 51 , 52 will serve an individual connection. The AF 60 and the first and second application instances 51 , 52 can be implemented such that even during a running session a switch-over between the first and second application instances 51 , 52 is possible without affecting the quality of the session. This can either be achieved by keeping session-relevant state information in a data pool accessible by both application instances 51 , 52 (e.g. shared data layer) or by keeping the application itself stateless, at least on the server side.

The AF 60 will then configure (dynamically) the NAT function 40 in a manner that IP packet headers of incoming and outgoing IP packets are modified such that the UE 10 will always use ΊR-appx” as destination IP address and will be addressable by its IP address“IP-UE” regardless of what instance of the application is used for serving.

Figure 3 shows schematically a signalling diagram with a message flow of a procedure with the dynamic NAT function 40 according to the first exemplary embodiment in the network environment of Figure 2. Entities shown in Figure 2, such as the NAT function 40 and the AF 60 may be configured to include an apparatus comprising at least one processor and at least one memory including computer program code, wherein the at least one memory and the computer program code may be configured to, with the at least one processor, cause the apparatus to perform action described in connection with Figure 3.

It is assumed in Figure 3 that the AF 60 has decided in step S300 to serve the next connection request for the application by the first application instance (AppX1 ) 51. This decision can be based on load conditions and/or on reports from the 5G core network reflecting UE tracking activity. Consequently, the AS 60 controls the DNS 70 in step S301 to assign the general IP address“IP-appx” to the URL“www.appx.com”.

As a first activity, the user will access in step S302 the service by a query associated with the URL“www.appx.com” by typing in the URL into the browser at the UE 10. A lookup at the DNS 70 will thus provide the IP address“IP-appx” as associated IP address (step S303). In the given exemplary architecture of Figure 2, an IP packet with source IP address (SRC)“IP-UE” and destination IP address (DST)“IP-appx” will be conveyed in step S304 from the UE 10 towards the data centre with the two servers S1 and S2, which are both running respective application instances 51 , 52 of the requested application and could thus serve the user. In the embodiment, an instance of the NAT function 40 will be traversed first (for incoming packets). Since the IP packet has“IP-appx” as destination IP address (which likely cannot be resolved as a valid IP address within the data centre), the NAT function 40 requires a rule for how to deal with this source/destination IP address. For this purpose, the NAT function 40 requires a rule set for each pair of generic service IP address (e.g.“IP-appx”) and user IP address (e.g.“IP-UE”) (or other UE identifier). This rule set comprises header modification rules for incoming and outgoing packets.

In the given example of Figure 3, headers of incoming IP packets with source IP address“!P-UE” and destination IP address“IP-appx” will be mediated such that the destination IP address“IP-appx” will be replaced by the IP address“IP-S1” as selected by the AS 60. For outgoing IP packets, the source IP address“IP-S1” will be swapped with“IP-appx”.

In case the NAT function 40 cannot find an appropriate rule set (as is the case in the given example of Figure 3), it will query in step S305 the AF 60 for a rule set by forwarding the pair of generic service IP address (e.g.“IP-appx”) and user IP address (e.g.“IP-UE”) with the query. In response to the query, the AF60 will provide in step S306 the appropriate rule set in its response message. Now, the NAT function 40 is configured with the following rule set for the IP address pair “IP-UE” and”IP-appx”:

Incoming: Replace destination IP address“IP-appx” with“IP-S1”

Outgoing: Replace source IP address“IP-S1” with“IP-appx”

Accordingly, the destination IP address of the IP packet received from the UE 10 will be translated by the NAT function 40 in line with the above rule set and the IP packet with the new destination IP address will be forwarded in step S307 to the first application instance 51. Moreover, IP packets from the first application instance 51 will be forwarded in step S308 to the NAT function 40 where their source IP address is translated in line with the rule set, and the IP packet with the new source IP address is forwarded in step S309 based on its destination IP address to the UE 10.

If the AF 60 decides to move the application control, e.g. from the first application instance 51 to the second application instance 52 in step S310 of the example of Figure 3, it will instruct the first application instance 51 in step S311 to stop serving the UE 10 and will instruct the second application instance 52 in step S312 to prepare for serving the UE 10. This could e.g. comprise providing for the second application instance 52 access to state data of the communication between the first application instance 51 and the UE 10. In the next step S313, the AE 60 reports the following new rule set to the NAT function 40 for the IP address pair“IP- UE” and”IP-appx”:

Incoming: Replace destination IP address“IP-appx” with“IP-S2”

Outgoing: Replace source IP address“IP-S2” with“IP-appx”

Accordingly, the destination IP address of an IP packet received from the UE 10 in step S314 will be translated by the NAT function 40 in line with the above new rule set and the IP packet with the new destination IP address will be forwarded in step 315 to the second application instance 52. Moreover, an IP packet from the second application instance 52 will be forwarded in step S316 to the NAT function 40 where their source IP address is translated in line with the new rule set, and the IP packet with the new source IP address is forwarded in step S317 based on its destination IP address to the UE 10.

According to the above first exemplary embodiment described with reference to Figures 2 and 3, multiple instances of one application are handled within one data centre.

Figure 4 shows schematically a block diagram of a network architecture with multiple instances (NAT 1 , NAT2) 41 , 42 of the dynamic NAT function in different data centres 81 , 82 according to a second exemplary embodiment. Thereby, a generalization of the configurable or dynamic NAT principle is provided across data centres, e.g., for a complete (mobile) network.

The multiple instances 41 , 42 of the NAT function, i.e. one per data centre, are controlled by one AF 60. The AF may place respective rule sets for network translation at each of the instances 41 , 42 for respective IP address pair contexts “app[x]” and“UE[y]”, where x represents the number of different applications (where each application may have z instances across the network) and x represents the number of UEs.

In the example of Figure 4, the first and second application instances 51 and 52 of the application of the first embodiment and the first instance 41 of the NAT function are provided in a first data centre (DC A) 81 , and additional third and fourth application instances 53 and 54 of the application of the first exemplary embodiment are provided in respective fifth and sixth severs S5, S6 of a second data centre (DC B) 82 and the second instance 42 of the NAT function is provided in a fourth server S4 of the second data centre (DC B) 82. The remaining components of Figure 4 correspond to those of Figure 2 and are therefore not described again here.

The message flow of the dynamic or configurable address translation of the second embodiment basically corresponds to Figure 3 with the difference that the AF 60 now controls two instances 41 , 42 of the NAT function by respective rule sets so that the addresses of IP packets received from the UE 10 are translated in line with the rule sets and the packets are routed through a respective one of the two instances 41 , 42 of the NAT function to a selected one of the four application instances 51 -54.

Figure 5 shows schematically a signalling diagram of an application-initiated procedure with a dynamic NAT function 40 according to a third exemplary embodiment. Entities shown in Figure 4, such as the NAT functions 41 and 42 and the AF 60 may be configured to include an apparatus comprising at least one processor and at least one memory including computer program code, wherein the at least one memory and the computer program code may be configured to, with the at least one processor, cause the apparatus to perform action described in connection with Figure 5. Here, the initiative of a communication between the application (e.g. the first application instance 51 in the example of Figure 5) and the UE 10 is started from the application rather than from the UE 10 (for whatever reason) by sending an IP packet with source IP address (e.g. “IP-S1”) and destination IP address (e.g.“IP-UE”) in step S401. The NAT function 40 or one of several instances thereof detects that is has no rule set for the received address pair context, sends in step S402 a query with the address pair to the AF 60, and in return receives in step S403 the following rule set:

Incoming: Replace destination IP address“IP-appx” with“IP-S1”

Outgoing: Replace source IP address“IP-S1” with“IP-appx”

Accordingly, the source IP address of the IP packet received from the first application instance 51 will be translated by the NAT function 40 in line with the above new rule set and the IP packet with the new source IP address“IP-appx” will be forwarded in step S404 to the UE 10.

Similar to the first exemplary embodiment of Figure 3, the AF 60 may decide that, e.g. due to changed load conditions, the second application instance 52 shall take over further serving of the UE 10 (not shown in Figure 5).

The outside-in network address translation of the third exemplary embodiment may deal with issues associated with the proposed dynamic multiinstance environment.

Figure 6 shows schematically five different stages or steps of a network implementation of embodiments with dynamic offload capabilities.

More specifically, steps 1 to 5 show a handshake between an AF and a core network in a UPF relocation scenario. In step 1 , the AF controls a NAT function (not shown) in a manner so that an application requested by an UE is served from a remote central data centre (UPF). Then, in step 2, the core network detects a move of the UE into an area where an instance of the application of the UE is available in a local data centre (UPF UL CL). For this purpose, in steps 3 and 4, a new UPF will be setup by the AF based on the trigger of the core network and an uplink classifier UL CL. Finally, in step 5, the UE will now be served by an application instance located in the closer local data centre. Thus, for every new UPF instance an instance of a NAT function will be associated which works according to the principles described above. Due to the fact that multiple instances of applications and/or NAT functions are involved, the delay (i.e. round-trip delay) can be lower as the terrestrial propagation delay. Even if a UE moves for some 100km, the delay can be kept lower than the calculated propagation delay of the moving distance, since the application can be re- instantiated at another location.

Some embodiments may have the selection of one of at least two instances of a network application to be served for a terminal device and setting of at least one rule for address translation, based on the selected instance, to be applied at a network address translation function for an address context of at least one of the terminal device and the network application. The at least one rule for address translation may be requested from the network based on the address context of a received transmission packet and the network address translation for the received transmission packet can be performed by using the received at least one rule for address translation.

It is noted that the embodiments may be implemented in any network environment with a network address translation function.

The embodiments may thus vary within the scope of the attached claims. In general, the various embodiments of the invention may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. For example, some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device, although the invention is not limited thereto. While various aspects of the invention may be illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

The embodiments may be implemented by computer software stored in a memory and executable by at least one data processor of the involved entities (e.g. NAT function(s), AF, etc.), or by hardware, or by a combination of software and hardware. Further in this regard it should be noted that any procedures, e.g., as in Figures 3, 5 and 6, may represent program steps, or interconnected logic circuits, blocks and functions, or a combination of program steps and logic circuits, blocks and functions. The software may be stored on such physical media as memory chips, or memory blocks implemented within the processor, magnetic media such as hard disk or floppy disks, and optical media such as for example DVD and the data variants thereof, CD.

The memory may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The data processors may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASIC), gate level circuits and processors based on multi-core processor architecture, as non-limiting examples.

Embodiments of the inventions may be practiced in various components such as integrated circuit modules. The design of integrated circuits is by and large a highly automated process. Complex and powerful software tools are available for converting a logic level design into a semiconductor circuit design ready to be etched and formed on a semiconductor substrate.

The foregoing description has provided by way of exemplary and nonlimiting examples a full and informative description of exemplary embodiments of this invention. However, various modifications and adaptations may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings and the appended claims. However, all such and similar modifications of the teachings of this invention will still fall within the scope of this invention as defined in the appended claims.

Claims

CLAIMS:

1. A method comprising:

selecting one of at least two instances of a network application to be served for a terminal device; and

2. The method according to claim 1 , wherein the at least two instances of the network application are located at different data centres of the network.

3. The method according to claim 1 or 2, further comprising performing the selecting and setting steps at an application function of the network.

4. The method according to claim 1 , wherein the at least one rule for address translation comprises header modification rules for incoming and outgoing transmission packets.

5. The method according to any one of claims 1 to 4, further comprising deciding to move control of the application to another one of the at least two instances of the network application and reporting a corresponding at least one new rule for address translation to the network address translation function.

6. The method according to claim 5, wherein the decision to move control of the application is based on at least one of a server load at the selecting one of the at least two instances of the network application and a location of the terminal device.

7. A method comprising:

receiving a transmission packet with at least one of a source address and a destination address in a network; requesting at least one rule for address translation based on the at least one of the source address and the destination address of the received

transmission packet;

8. The method according to claim 7, wherein the at least one rule for address translation comprises header modification rules for incoming and outgoing transmission packets.

9. The method according to claim 8, wherein the header modification rules for incoming transmission packets comprise replacing the destination address of the received transmission packet by a predetermined network address of a selected instance of a destination application, and wherein the header modification rules for outgoing transmission packets comprise replacing the source address of the received transmission packet by the predetermined network address of the selected instance of the destination application.

10. The method according to any one of claims 7 to 9, wherein the step of requesting from the network at least one rule for address translation comprises sending a query to with the at least one of the source address and the destination address of the received transmission packet to an application function of the network.

11. The method according to any one of claims 7 to 10, wherein the

transmission packet is received from one of at least two instances of a network application.

12. An apparatus comprising:

at least one processor; and

13. An apparatus comprising:

at least one processor; and

at least one memory including computer program code;

the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus to receive a transmission packet with at least one of a source address and a destination address in a network, request at least one rule for address translation based on the at least one of the source address and the destination address of the received

transmission packet, receive from the network the at least one rule for address translation for the at least one of the source address and the destination address, and perform network address translation for the received transmission packet by using the received at least one rule for address translation.

14. A system comprising an application function with an apparatus according to claim 12 and at least one network address translation function with an apparatus according to claim 13.

15. A computer program comprising program instructions for causing a computer to perform the method of claims 1 or 7.