WO2020148263A1

WO2020148263A1 - Routed IP Traffic Offload

Info

Publication number: WO2020148263A1
Application number: PCT/EP2020/050781
Authority: WO
Inventors: David Neil; Jason Cooper
Original assignee: Attocore Ltd
Priority date: 2019-01-18
Filing date: 2020-01-14
Publication date: 2020-07-23
Also published as: GB201900720D0; GB2580721A; GB201905239D0

Abstract

A method for offloading packet data in a mobile communication network connected to the Internet, where the network comprises at least one User Equipment, UE, at least one eNodeB, and a core network comprising at least one packet gateway, at least one serving gateway and a Routed IP Traffic Offload (RIPTO) module where the RIPTO module includes rules for determining whether the packet data should be offloaded, the method comprising the steps of: receiving packet data at the RIPTO module from a UE; determining if the received packet data is on a bearer supported by the RIPTO and so is suitable to be offloaded; and executing RIPTO rules to determine whether the packet data that can be offloaded, sending the packet data to be offloaded to the internet. A method of handling responses to the offloaded data in the reverse direction from the internet to a UE is also described.

Description

Routed IP Traffic Offload

Field of Invention

This invention relates to mobile telecommunications and particularly 4G LTE (Long Term Evolution) telecommunication networks. In particular, the field of the invention relates to a method of offloading data that is sent between user equipment and the Internet to avoid traversing the LTE Core Network.

Background of Invention

In a traditional LTE network, when a User Equipment (UE) such as a mobile telecommunication device, or other suitably enabled communication device, first attaches to the LTE network the UE sets up a default bearer to carry general purpose data between the UE and the Internet. During the attach procedure, the MME (Mobility Management Entity) in the LTE Core Network chooses an SGW (Serving Gateway) and a PGW (Packet Gateway) to handle the data for the UE. The Core Network then assigns an Internet Protocol (IP) address to the UE, this address may be a static IP address configured in the HSS (Home Subscriber Service) or may be a dynamic IP address allocated by the PGW.

If the UE subsequently wants to communicate with another network (other than the Internet), or with multiple networks then the PDN (Packet Data Network) Connectivity procedure is used to establish a default bearer between the UE and the chosen network. For example, the UE could have one connection to the Internet (the one set up during the initial attach procedure), one additional connection to an IMS (IP multimedia subsystem) network, and one additional connection to a private LAN. During this PDN Connectivity procedure, the Core Network chooses an additional PGW which can provide access to the other network. The additional PGW may be the same as the original PGW or it may be different. Each PGW can provide access to one or more PDNs. If the PGW chosen during the initial attach procedure also provides connectivity to the PDN requested in the PDN Connectivity procedure, then the MME is likely (but is not mandated to) choose the same PGW. The Core Network then assigns an IP address to the UE for use on this network, this may be a static IP address configured in the HSS (Home Subscriber Service) or may be a dynamic IP address allocated by the PGW. After a UE has a default bearer with a PGW, additional bearers can be created between the UE and the PGW each providing a different Quality of Service (QoS). For example, if the EE is connected to the IMS PDN, then the default bearer is used for signalling, but when a call is setup, an additional bearer is created to carry the voice/video data.

An SI GW between an eNodeB and an MME is used to aggregate the SI connections from multiple eNodeBs into a single SI connection to the LTE Core Network. In a home or domestic deployment of eNodeBs, a single eNodeB is typically sufficient to provide coverage for the home. In an enterprise deployment of eNodeBs, covering a larger area, multiple eNodeBs may be needed to cover a company premises; in this case, an S1GW may be used to make all the eNodeBs in the enterprise appear as a single eNodeB at the LTE Core Network.

In a traditional LTE network, once bearers have been established, user data is sent from the UE via the eNodeB and SGW to a PGW which sends it to the required destination. The destination may be any IP address on the target network. For example, if a user performs an internet search on an enabled device, the destination IP address would be the address of the server for the search engine. In the other direction, data is sent from the network to the PGW which sends it via the SGW and eNodeB to the UE.

As the number of UEs has increased and the amount of data used in the mobile network has increased, the SGW and PGW in the Core Network have struggled to handle all the data. This has motivated various approaches that allow some of the user data to be offloaded without going through the Core Network.

The 3 GPP (Third Generation Partnership Project) standards have defined two approaches known as SIPTO (Selective IP Traffic Offload) and LIPA (Local IP Access). Conceptually, these approaches are very similar; they both involve putting a LGW (Local Gateway) (very similar to a PGW) into the network co-located with or near the eNodeB. When using either the SIPTO or LIPA method, the Core Network chooses the LGW to handle the data for the UE instead of one of the PGWs in the Core Network. The eNodeB and the LGW coordinate with each other so that the user data goes directly between the eNodeB and the LGW without going through the SGW. The architecture of a prior art network using SIPTO is shown in figure 1. The eNodeB (125) contains a normal control plane (123) and user plane (121) functionality along with an LGW (119). The Control Plane (123) has a SIPTO CTRL interface to LGW (119) and the User Plane (121) to allow the Control Plane to setup a shortcut for data using the LGW. The Core Network (106) contains standard components, an MME (113), and HSS (107), an SGW (115) and in this case two PGWs (109 and 111).

The behaviour for setting up a SIPTO bearer as known in the prior art is shown in figure 2. The UE 200 attempts to Attach to the network by sending an Attach Request (210). The eNodeB 202 forwards the Attach Request to the MME 204 in an Initial UE Message and indicates its support for SIPTO by including the address of the LGW (212). The MME 204 updates the UEs 200 location in the HSS (213) and in response receives the UEs 200 subscription data from the HSS (214); this includes information about whether the UE 200 is permitted to use SIPTO. Based on the UEs permission to use SIPTO and the eNodeBs 202 indication for support of SIPTO the MME 204 decides whether to offload data using SIPTO or whether to send the data to the PGW as normal (215). In this example, the MME 204 decides to use SIPTO. The MME 204 creates the data session in the SGW (216) and instructs the SGW 206 to use the LGW 208 address. The SGW 206 creates the data session in the LGW (218) which allocates an IP address for the UE 200 and responds back to the SGW (220) which then responds back to the MME (222). The MME 204 then sends an Initial Context Setup to the eNodeB 202 containing an Attach Accept message for the UE (224). The eNodeB 202 uses the information in the Initial Context Setup to setup the bearer and to setup the shortcut so that data is exchanged directly between the eNodeB 202 and the LGW 208 without taking the traditional path through the SGW (226). The eNodeB 202 forwards the Attach Accept to the UE (228) and responds to the Inital Context Setup to the MME (230). The UE 200 responds to the Attach Accept with an Attach Complete (232), which is forwarded by the eNodeB 202 to the EPC (234). At this point the bearers are all setup. When the UE 200 sends uplink data (236) the eNodeB 202 forwards it directly to the LGW (238) which sends it out to the Internet (240). Response packets from the Internet (242) go through the LGW 208, are forwarded to the eNodeB (244) which sends them on to the UE (246).

The UE 117, 200 may subsequently choose to setup a bearer to another network (e.g IMS). When this occurs, the MME 204 will choose to use one of the Core Network PGWs 109, 111 instead of the LGW 208. At this point, the eNodeB 125,202 will send traffic to the Internet via the LGW 119,208 and traffic to the IMS network via the SGW 115, 206 and PGW 109, 111 in the Core Network.

The downside of these standards-based approaches is that it requires changes in the MME 204,113 in the Core Network 106. These changes have been slow to be adopted and the Core Networks 106 often charge a large premium for using this functionality. For this reason, approaches to data offload which are transparent to the Core Network are desirable.

Outside of the 3GPP standards, EP1916803A1 proposed an offload solution in a 3G network based on the idea of an Access Point (roughly equivalent to an eNodeB) forwarding traffic with some service properties to the GGSN (Gateway GPRS (General Packet Radio Service) Support Node) (roughly equivalent to a PGW) and forwarding traffic with other service properties directly to the Internet. This is good in theory, but there are various practical problems to solve which means it is not easy to turn this abstract idea into reality. Problems include: a) The IP address is assigned to the UE by the Core Network and not by the Access Point. This traffic cannot be just "forwarded to the Internet" as the source IP address will have an incorrect value for use on the local network connected to the Access Point. The packets need to be modified to have an appropriate private source address for use on the Access Point. The packets then need to be NATted (Network Address Translation) so that they go out of the Access Point with the address of the Access Point. Response packets need to be deNATted to go back to the private source address and then to be modified to set the destination address back to the IP address allocated by the Core Network. b) A UE can have multiple bearers, each designed to handle different flows of traffic. When the UE sends packets, it chooses which bearer to use. If traffic from multiple bearers is "forwarded to the Internet", then corresponding response packets will be received at the Access Point. The Access Point does not have the information about which bearer to assign the packets to. c) When a UE goes inactive, the bearers in the AP are released, but the bearers in the Core Network are retained. If the Core Network subsequently receives a downlink packet for the UE, the Core Network wakes up the UE by sending a Paging message to the UE. If you forward some traffic to the Internet, then you break this mechanism for waking up the UE. Any downlink packets from the Internet for the UE will be received by the Access Point instead of the Core Network. The Access Point is not able to wake up the UE. d) EP1916803A1 does not elaborate on the criteria by which packets could be selected for offload. e) EP1916803A1 does not discuss mobility. What happens to the UE internet traffic when the UE moves from one eNodeB to another. In the solution described in EP1916803A1, the UE internet connections would break and would have to be re-established in the new eNodeB.

Summary of the Invention

Accordingly, the invention seeks to mitigate, alleviate or eliminate one or more of the above- mentioned disadvantages singly or in combination.

According to the invention there is provided a method for offloading packet data in a mobile communication network connected to the Internet, where the network comprises at least one User Equipment, UE, at least one eNodeB, and a Core Network comprising at least one packet gateway, at least one serving gateway and a Routed IP Traffic Offload (RIPTO) module where the RIPTO module includes rules for determining whether the packet data should be offloaded, the method comprising the steps of: receiving packet data at the RIPTO module from a UE; determining if the received packet data is on a bearer supported by the RIPTO and so is suitable to be offloaded; and executing RIPTO rules to determine whether the packet data can be offloaded; sending the packet data to be offloaded to the Internet.

In a preferred embodiment of the invention the method further comprises the steps of: the RIPTO module replacing a source IP address of the packet data with a private IP address allocated by the RIPTO module, and the RIPTO module storing the mapping between the source IP address and the allocated IP address.

In a further preferred embodiment of the invention, wherein when the RIPTO module encounters a source IP address it has previously received, the RIPTO module allocates the private IP address previously allocated to that source IP address. Alternatively, when the RIPTO module encounters a new source IP address the RIPTO module allocates a new private IP address. In a further preferred embodiment of the invention the method further comprises the step of processing the packet data with a source NAT to modify the allocated private IP address to the public address of the eNodeB.

In an embodiment of the invention, the RIPTO module includes a rule module that determines whether the data packet should be offloaded.

Preferably, the rules in said rule module include one or more of rules concerning: the destination IP address of the data packet; a specified IP protocol for the packet data; whether packet data should go to a specific TCP or UDP port. Further preferably, the rules are executed sequentially, or are logically combined for execution.

Preferably, the RIPTO module further comprised a metadata store to track active connections between the UE and the internet. Preferably, key metadata (e.g. addresses, ports, protocols) from the packet to be offloaded to the internet is written to the metadata store.

In a second embodiment of the invention there is provided a method for offloading downlink packet data in a mobile communications network connected to the internet, where the network comprises at least one User Equipment, UE, at least one eNodeB and a core network comprising at least one packet gateway, at least one serving gateway and a routed IP traffic Offload (RIPTO) module, the method comprising the steps of: receiving downlink packet data at the RIPTO module in response to uplink packets offloaded to the internet; updating the packet destination IP address to the address of the appropriate UE; sending the downlink packet data to the UE with the public address. In an example of the invention the method further comprises the step of de-NATing the packet; looking up the destination IP address for the packet data from the RIPTO module; replacing the destination IP address with the public IP address of a UE.

Preferably, the method further comprising the steps of deNATing the received packet data, so the destination IP address is a private IP address as allocated by the RIPTO module. In an example of the invention, the method further comprising the step of looking up the destination IP address in an IP map in the RIPTO module to determine the replacement public IP address of the UE.

In a further example of the invention the method also comprises the step of using the RIPTO module to determine a bearer for the UE, and sending said packet data to the UE on the chosen bearer. Preferably, the metadata stored by the RIPTO module is used to determine the bearer for the UE.

In an example of the invention the method further comprises the steps of determining that there are no existing bearers that are currently using the allocated private IP address; buffering the packet data and sending a test packet to the UE IP address from the IP map; resulting in the UE reconnecting to the network and re-establishing bearers.

In an embodiment of the invention, wherein the test packet is a ping packet and when the bearer is re-established the buffered packet data is sent to the UE on the bearer.

Preferably, the RIPTO module is run on the eNodeB of the mobile communication network. Alternatively, the RIPTO module is run on an SI GW within the core network

In an example of the invention the RIPTO will support one or more bearers for each UE. Further preferably, the RIPTO only supports the first bearer of the UE.

In an example of the invention, the RIPTO module associates the bearers with the public and private addresses used on the bearers.

Thus, the following problem(s) has (have) been resolved, by the present invention

. The method of this invention helps to solve the problems of:

- How to modify IP addresses in packets during offload.

- How to assign received traffic to appropriate bearers.

- How to wake the UE up if traffic is received while the UE is inactive.

- How to select packets for offload - RIPTO in the SI GW handles the problem of mobility amongst the eNodeBs handled by the SI GW.

These and other aspects, features and advantages of the invention will be apparent from, and elucidated with reference to, the embodiments described hereinafter.

Brief Description of the figures

Figure 1 illustrates the architecture of a prior art network using SIPTO;

Figure 2 illustrates the set-up of an SIPTO bearer in known prior art networks;

Figure 3 illustrates a Routed IP Traffic Offload (RIPTO) according to invention as running on an eNodeB;

Figure 4 illustrates an alternative RIPTO according to the invention running in an S1GW;

Figure 5 is a flowchart showing the steps in the RIPTO process for uplink data;

Figure 6 is a flowchart showing the steps in the RIPTO process for downlink data Figure 7 shows the RIPTO module in more detail.

Detailed Description

Routed IP Traffic Offload (RIPTO) is a function that can be put on the user data path between the UE and the Core Network to allow IP traffic to be offloaded. The traffic maybe packet data from the UE to be offloaded to the Internet, or may be corresponding downlink responses packets from the internet to be returned to a UE. In a first example of the invention the traffic offload may be run on the eNodeB as in Figure 3, or alternatively, the traffic offload could be run in an SI GW (SI Gateway) as in Figure 4.

In Figure 3, the eNodeB 325 is shown to contain a Control Plane 323, a User Plane 321 and RIPTO 319. The Control Plane 323 represents all the functionality in the eNodeB 325 that handles signalling with the UE 317 and with the Core Network 306; this would include functionality such as RRC (Radio Resource Control) and S1AP (SI Application Part). The User Plane 321 represents the functionality in the eNodeB 325 that handles the user data to and from the UE 317; this would include functionality such as PDCP (Packet Data Convergence Protocol) and GTP. The RIPTO module 317 connects to the User Plane 321 to processes each user data packet, the RIPTO module 317 receives information from the control plane over the RIPTO CTRL interface to inform it about which bearers have been created and deleted.

In Figure 4, the S1GW 425 is shown to contain a Control Plane 423, a User Plane 421 and RIPTO 419. The Control Plane 423 represents all the functionality in the SI GW 425 that handles signalling interworking between the eNodeB 427,429,431 and the Core Network 406. The User Plane 421 represents the functionality in the eNodeB 427, 429,431 that handles the user data to and from the UE 417. The RIPTO module 419 connects to the User Plane 421 to processes each user data packet, the RIPTO module 419 receives information from the control plane 423 over the RIPTO CTRL interface to inform it about which bearers have been created and deleted.

In either case, RIPTO module 419, processes each user packet from the UE 417 to decide whether to send the packet data to the Internet 405 or whether to send the packet data to the PGW 411. In the reverse direction, RIPTO module 419 receives packet data for the UE 417 from either the Internet 405 or from the SGW 415 /PGW 409,411, processes the packet data and forwards the packet data to the UE 417.

RIPTO module 319, 419, 700 is shown in more detail in figure 7. In an example of the invention the module 319, 419, 700 can be configured with a set of rules 730 that determine whether the data packet should be offloaded. In an example of the invention, the rules may describe which packets should be sent directly to the Internet and which should be sent to the SGW/PGW. The rules could take many forms, but likely examples include:

- Any packet with a specified destination IP address.

- Any packet going to a specified destination network address i.e. If the most significant bits of the destination IP address have a specified value.

- Any packet of a specified IP protocol (e.g. TCP (Transmission Control Protocol), UDP (User Datagram Protocol)).

- Any packet to a specified UDP port.

- Any packet to a specified TCP port. - Any packet to a specified UDP port range.

- Any packet to a specified TCP port range.

- Any packet with a specified TCP protocol (e.g. HTTP).

In an example of the invention, the rules may be both positive or negative. For example, the rule may be that anything with a specified destination IP address goes to the Internet, or the rule may be that anything with a specified destination IP address goes to the SGW/PGW.

In an alternative example of the invention, the rules may be logically combined, with AND or OR relationships. For example, any packet to a specified destination IP address AND a specified TCP port should go to the Internet.

Alternatively, the rules may be executed sequentially, such that as soon as a rule is matched, a decision is made about where to send the packet, and no subsequent rules are run. For example, if the rules are:

1) Any packet with a destination IP address of 10.1.2.3 should go to the Internet.

2) Any packet to TCP port 123 should go to the SGW/PGW.

Then a packet with a destination IP address of 10.1.2.3 and with a TCP port of 123 would go to the Internet, as rule number 1 was run first and matched and hence rule number 2 was never run.

In an example of the invention the RIPTO module can be configured to support one or more bearers for the UE or alternatively, the RIPTO module may be configured to only support the first bearer of the UE Only supporting just the first bearer to be established is the simplest option and will get most of the benefits. The first bearer established is intended to carry general purpose traffic with best effort quality of service. Almost all Internet traffic will go over this first bearer. Supporting all bearers is more complicated as RIPTO needs to determine which bearer to use when sending downlink traffic to the UE. The location of the RIPTO module is typically determined according to the type of network that the invention is implemented in. For example, if the invention is to be implemented in a domestic context, then the RIPTO module is preferably located in the residence of the user. In an alternative, commercial use of the invention, the RIPTO module is located within an SI GW located in the commercial premises. In an example of the invention, the RIPTO module stores an IP map 750 which provides a mapping between public IP addresses allocated by PGWs of the core network, and private IP addresses used internally by RIPTO module. The address mapping is 1-2-1, and each public IP address maps to a single private IP address. Entries are added to this map each time a private IP address is allocated for a new UE by the RIPTO module. Entries are not removed from this address map during periods of UE inactivity, when the UE has released its SI connection. Entries may optionally be removed from this map if they remain unused for extended periods of time.

RIPTO keeps track of all the bearers used by all of the UEs using the eNodeB 740. It is informed by the control plane when bearers are created and deleted. In an example of the invention the RIPTO module associates the bearers of the UE with the public and private IP addresses used on those bearers. In an example of the invention the RIPTO module maintains the mapping from public IP address to a private IP address after the bearers that uses the addresses are released.

In an example of the invention the RIPTO module optionally maintains a metadata store (760). Typically, this will store of the packet metadata (e.g. addresses, protocols and ports) for recently transmitted uplink packets and which bearer originated the packets. Entries in the metadata store time out after a configurable period of inactivity which is typically a few minutes but could be as long as 24 hours. The metadata store is used to track the active connections between the UE and the Internet. This is used when processing downlink packets to ensure the downlink packets are assigned to the correct bearer. On receiving a downlink packet, the Metadata store is searched to find the active connection which triggered this downlink packet, the bearer that initiated the connection is then chosen for the downlink packet.

This metadata store is only required if RIPTO operates on multiple bearers; if RIPTO only operates on the first bearer, then the metadata store is not needed.

RIPTO behaviour for uplink packets:

In an example of the invention the RIPTO module can support offloading uplink packet data in a network, as described in figures 3 and 4. When the UE sends an uplink packet data 501 the UE chooses which bearer to use typically based on where the packet is going, RIPTO receives the packet data from the UE. The RIPTO module first checks the bearer chosen by the UE to determine if the bearer supports RIPTO 503. If the bearer supports RIPTO then we can examine the packet further to determine whether it can be offloaded, if the bearer does not support RIPTO then the packet is sent to the SGW/PGW 521. The RIPTO rules described above are executed on the packet 505 to determine whether the packet data can be offloaded. If the rules determine that the packet should be sent to the SGW/PGW then the packet can be immediately sent to the SGW/PGW 521. If the rules determine that the packet should be sent to the Internet to be offloaded, then the packet source IP address and port need to be modified before the packet data can be transmitted to the internet to be offloaded. The RIPTO module looks up the packet source IP address in the stored IP Map 507 to determine whether this source IP address has been used before. If the RIPTO module encounters a source IP address it has previously received, the RIPTO module uses the private IP address previously allocated to that source IP address. If no entry exists in the stored IP Map for the address, so the source address is a new address, the RIPTO module allocates a new replacement private IP address for the UE 500 and stores this replacement address in the IP Map 511. The source address of the packet data is changed from the UE public IP address as allocated by the Core Network to the private IP address in the IP Map 513. Metadata from the packet data and the bearer used by the packet data is optionally added to the RIPTO Metadata store 515. The packet data then goes through a source NAT/PAT 517 to modify the allocated private IP address to the public IP address of the eNodeB so it can be sent on the network connected to the eNodeB and to change its source port to a value that is unused on the eNodeB. Finally, the packet is sent out of the eNodeB towards the Internet 519.

RIPTO behaviour for downlink packets:

In an example of the invention, when downlink packet data is received from the SGW/PGW 601, the bearer for the packet is chosen based on which GTP (GPRS (General Packet Radio Service) Tunnelling Protocol) tunnel the packet was received on 603 (each bearer has a one-to-one mapping with a GTP tunnel), the packet is then sent on to the UE 621.

When downlink packet data is received from the Internet in response to offloaded uplink packet data 605 the destination IP address for the packet data will be the public IP address of the eNodeB. The received packet data is deNATed so that the packet destination IP address becomes one of the RIPTO allocated private IP addresses 607. The destination IP address (the allocated private IP address) for the packet data is then looked up in the stored IP Map 409 of the RIPTO module to find the public IP address allocated by the Core Network and then to determine whether any bearers are currently using these IP addresses 611. If there are bearers using the destination IP address, then the destination IP address in the packet data is changed to the replacement public IP address for the UE from the IP Map (613). If the RIPTO module is only running on one bearer (615), then the packet is assigned to the one bearer running RIPTO (619). If RIPTO is running on multiple bearers, then the Metadata store 760 is used to choose the appropriate bearer (617). That is the RIPTO module will determine the bearer to use, and send the packet data to the UE on the chosen bearer. The Metadata store records what uplink packets have been sent by the UE and which bearer was used by the UE for each packet. On receiving a downlink packet, the Metadata store is searched to find which uplink packet triggered this downlink packet, as the metadata store may associate downlink packets with corresponding uplink packets. RIPTO chooses the same bearer as was used by the UE when sending the triggering uplink packet. The packet data is then sent to the UE on the chosen bearer (621). If at step 611, no bearers are identified as currently using the private IP address, then the downlink packet data is buffered (623) and a harmless IP test packet (in a preferred example this IP packet is a ping packet) is sent to the public IP address of the UE as obtained from the IP Map (623). RIPTO then waits for bearers to be re-established (627).

The ping packet will go to the SGW/PGW as the destination address for the ping packet is the IP address of the UE as allocated by the SGW/PGW. The SGW/PGW, on receiving the packet data, will also determine that the UE currently does not have any bearers. This SGW/PGW will then inform the MME which will page the UE. The UE on receiving the page will reconnect to the network and re-establish bearers. Once the bearers are re-established, RIPTO can send the buffered packet data to the UE.

As described above, the sending of downlink packet data to the UE is possible when the UE has become inactive, this is typically enabled by maintaining the IP address mapping from public IP addresses to private IP addresses even when bearers are deleted, and by pinging the UE on receiving data for the inactive UE. In this way, the UE is woken up from an idle mode, and can receive the downlink packet data.

In the embodiments of the invention as described above the RIPTO module is running on the eNodeB of the communications network. In an alternative embodiment of the invention, the RIPTO module may alternatively be run on an SI GW. The RIPTO behaviour is essentially the same in both deployment scenarios, but the use of RIPTO in an SI GW has an added benefit over other offload options. RIPTO in the SI GW will support mobility between all the eNodeBs behind the SI GW. As the UE moves between the eNodeBs, the bearers to the PGW will remain and the traffic can continue to be offloaded using RIPTO.

In the examples of the invention described above offloading packet data traffic to the Internet is possible by allocating private IP addresses to the UE and editing the uplink packets to include the private IP address and by performing NAT on the uplink packets.

It will be appreciated that, for clarity purposes, the above description has described embodiments of the invention with reference to different functional units and processors. However, it will be apparent that any suitable distribution of functionality between different functional units, processors or domains may be used without detracting from the invention. For example, functionality illustrated to be performed by separate processors or controllers may be performed by the same processor or controller. Hence, references to specific functional units are only to be seen as references to suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organization.

Aspects of the invention may be implemented in any suitable form including hardware, software, firmware or any combination of these. The invention may optionally be implemented, at least partly, as computer software running on one or more data processors and/or digital signal processors. Thus, the elements and components of an embodiment of the invention may be physically, functionally and logically implemented in any suitable way. Indeed, the functionality may be implemented in a single unit, in a plurality of units or as part of other

functional units.

Although the invention has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope of the present invention is limited only by the claims. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognize that various features of the described embodiments may be combined in accordance with the invention. Furthermore, although individually listed, a plurality of means, elements or method steps may be implemented by, for example, a single unit or processor. Additionally, although individual features may be included in different claims, these may possibly be advantageously combined, and the inclusion in different claims does not imply that a combination of features is not feasible and/or advantageous. Also, the inclusion of a feature in one category of claims does not imply a limitation to this category, but rather the feature may be equally applicable to other claim categories, as appropriate.

Furthermore, the order of features in the claims does not imply any specific order in which the features must be performed and in particular the order of individual steps in a method claim does not imply that the steps must be performed in this order. Rather, the steps may be performed in any suitable order. In addition, singular references do not exclude a plurality. Thus, references to‘a’, ‘an’,‘first’,‘second’, etc. do not preclude a plurality.

Thus, a method for offloading packet data in a mobile communication network has been described, which substantially addresses at least some of the shortcomings of past and present techniques and/or mechanisms.

Claims

1. A method for offloading packet data in a mobile communication network connected to the Internet, where the network comprises at least one User Equipment, UE, at least one eNodeB, and a core network comprising at least one packet gateway, at least one serving gateway and a Routed IP Traffic Offload (RIPTO) module where the RIPTO module includes rules for determining whether the packet data should be offloaded,

the method comprising the steps of:

receiving packet data at the RIPTO module from a UE;

determining if the received packet data is on a bearer supported by the RIPTO and so is suitable to be offloaded; and executing RIPTO rules to determine whether the packet data can be offloaded

sending the packet data to be offloaded to the internet.

2. A method according to claim 1 wherein the method further comprises the steps of:

the RIPTO replacing a source IP address of the packet data with a private IP address allocated by the RIPTO module;

and the RIPTO module storing the mapping between the source IP address and the allocated IP address.

3. A method according to claim 2 wherein when the RIPTO module encounters a source IP address it has previously received, the RIPTO module allocates the private IP address previously allocated to that source IP address.

4. A method according to claim 2 wherein when the RIPTO module encounters a new source IP address the RIPTO module allocates a new private IP address.

5. A method according to any of claims 2 to 4 further comprising the step of processing the packet data with a source NAT to modify the allocated private IP address to the public address of the eNodeB.

6. A method according to any preceding claim wherein the RIPTO module includes a rule module that determines whether the data packet should be offloaded.

7. A method according to claim 6 wherein the rules in said rule module include one or more of rules concerning:

the destination IP address of the data packet;

a specified IP protocol for the packet data;

whether packet data should go to a specific TCP or UDP port

8. A method according to claim 7 wherein the rules are executed sequentially, or are logically combined for execution.

9. A method according to any preceding claim wherein the RIPTO module further comprises a metadata store to track active connections between the UE and the Internet.

10. A method according to claim 9 wherein key metadata (e.g. addresses, ports, protocols) from a data packet to be offloaded to the internet is written to the metadata store.

11. A method for offloading downlink packet data in a mobile communications network connected to the internet, where the network comprises at least one User Equipment, UE, at least one eNodeB and a core network comprising at least one packet gateway, at least one serving gateway and a routed IP traffic Offload (RIPTO) module, the method comprising the steps of:

receiving downlink packets at the RIPTO module in response to uplink packets offloaded to the internet;

updating the packet destination IP address to the address of the appropriate UE;

sending the downlink packet data to the UE with the public address.

12. A method according to claim 11 further comprising the steps of:

de-NATting the packet

looking up the destination IP address for the packet data from the RIPTO module; replacing the destination IP address with the public IP address of a UE.

13. A method according to claim 12 further comprising the steps of

deNATing the received packet data, so the destination IP address is a private IP address as allocated by the RIPTO module.

14. A method according to any of claims 11 to 13 further comprising the step of looking up the destination IP address in an IP map in the RIPTO module to determine the replacement public IP address of the UE.

15. A method according to any of claims 11 to 14 further comprising the step using the RIPTO module to determine a bearer for the UE, and sending said packet data to the UE on the chosen bearer.

16. A method according to claim 15 wherein the bearer is determined according to information in the metadata store of the RIPTO module.

17. A method according to any of claims 11 to 16 further comprising the steps of

determining that there are no existing bearers that are currently using the allocated private IP address;

buffering the packet data and sending a test packet to the UE IP address from the IP map;

resulting in the UE reconnecting to the network and re-establishing bearers.

18. A method according to claim 17 wherein, the test packet is a ping packet and when the bearer is re-established the buffered packet data is sent to the UE on the bearer.

19. A method according to any preceding claim wherein the RIPTO module is run on the eNodeB of the mobile communication network.

20. A method according to any of claims 1 to 18 where the RIPTO module is run on an SI GW within the core network

21. A method according to any preceding claim wherein the RIPTO will support one or more bearers for each UE.

22. A method according to claim 21 wherein the RIPTO only supports the first bearer of the UE.

23. A method according to claim 21 or claim 22 wherein the RIPTO module associates the bearers with the public and private addresses used on the bearers.