Flexible routing policy for Wi-Fi offloaded cellular data

A system/router that flexibly routes Wi-Fi offloaded data receives a data packet from a user equipment via an access point of a Wi-Fi network. The data packet includes an access point name (“APN”) and an Internet Protocol (“IP”) address. The system defines two or more routing policies, each routing policy including a routing criteria and a priority. The system evaluates the data packet based on the routing policies, and routes the data packet to one of at least two possible destinations based at least on the routing policies, including the priorities.

FIELD

One embodiment is directed generally to a communication system, and in particular to a communication system for offloading cellular data onto a Wi-Fi network.

BACKGROUND INFORMATION

Mobile data offloading generally refers to the use of complementary network technologies for delivering data originally targeted for cellular networks. Cellular operators perform and encourage offloading to ease congestion of cellular networks. The primary complementary network technologies used for mobile data offloading are Wi-Fi, “femtocells”/“small cells” and Integrated Mobile Broadcast.

An increasing need for offloading solutions is caused by the explosion of Internet data traffic, especially the growing portion of traffic going through mobile networks. This has been enabled by smartphone devices possessing Wi-Fi capabilities together with large screens and different Internet applications, from browsers to video and audio streaming applications. In addition to smartphones, laptops and tablets with 3G/4G access capabilities are also a major source of mobile data traffic. Further, Wi-Fi is typically much less costly to build than cellular networks.

SUMMARY

One embodiment is a system/router that flexibly routes Wi-Fi offloaded data. The system receives a data packet from a user equipment via an access point of a Wi-Fi network. The data packet includes an access point name (“APN”) and an Internet Protocol (“IP”) address. The system defines two or more routing policies, each routing policy including a routing criteria and a priority. The system evaluates the data packet based on the routing policies, and routes the data packet to one of at least two possible destinations based at least on the routing policies, including the priorities.

DETAILED DESCRIPTION

One embodiment is a Wi-Fi offload solution which includes a flexible policy based routing that selectively offloads data traffic. Parameters returned from the policy server or information contained in the data packet can be used to make the selective offload decisions.

FIG. 1is an overview diagram of a network50including network elements that implement embodiments of the present invention and/or interact with embodiments of the present invention. Network50includes user equipment (“UE”)53that is able to connect to a Wi-Fi access point (“AP”)52. UE53may be any device used by an end-user for Wi-Fi communication, including a smartphone, a laptop computer, a tablet, etc. UE53may be in communication with AP52using known methods. AP52is coupled to an access controller (“AC”)51.

Network50further includes a security gateway60, also referred to as a “multi-service security gateway” (“MSG”), a “wireless access gateway” (“WAG”) or an evolved packet data gateway (“ePDG”), coupled to a “authentication, authorization and accounting” (“AAA”) server54. Security gateway60functions, in general, as a high performance tunneling gateway for heterogeneous networks, while AAA server54functions, in general, as a security architecture for distributed systems for controlling which users are allowed access to which services, and tracking which resources they have used. In one embodiment, SG60is implemented by a multi-core network processor.

AAA server54in embodiments functions in accordance to either Remote Authentication Dial In User Service (“RADIUS” or “Radius”) or “Diameter” protocol specifications. Radius is a networking protocol that provides centralized AAA management for users that connect and use a network service. Diameter is an AAA protocol for computer networks that has largely replaced Radius.

Security gateway60is further coupled to an accounting server (“AS”)55, and a gateway general packet radio service (“GPRS”) support node (“GGSN”)56. Security gateway60is in communication with GGSN56through a GPRS tunneling protocol (“GTP”) tunnel62.

Security gateway60is coupled through a default gateway57to the Internet59. GGSN56is coupled to a cellular operator's core network58. A core network, in general, is the central part of a telecommunication network that provides various services to customers who are connected by the access network. The core network is responsible for handling voice/data traffic over the public switched telephone network (“PSTN”), an IP network, or any other combination of networks.

FIG. 2is a block diagram of a computer server/system10in accordance with an embodiment of the present invention. System10can be used to implement any of the network elements shown inFIG. 1as necessary in order to implement any of the functionality of embodiments of the invention disclosed in detail below. Although shown as a single system, the functionality of system10can be implemented as a distributed system. Further, the functionality disclosed herein can be implemented on separate servers or devices that may be coupled together over a network. Further, one or more components of system10may not be included. For example, for functionality of user equipment, system10may be a smartphone that includes a processor, memory and a display, but may not include one or more of the other components shown inFIG. 2.

System10includes a bus12or other communication mechanism for communicating information, and a processor22coupled to bus12for processing information. Processor22may be any type of general or specific purpose processor. System10further includes a memory14for storing information and instructions to be executed by processor22. Memory14can be comprised of any combination of random access memory (“RAM”), read only memory (“ROM”), static storage such as a magnetic or optical disk, or any other type of computer readable media. System10further includes a communication device20, such as a network interface card, to provide access to a network. Therefore, a user may interface with system10directly, or remotely through a network, or any other method.

Processor22may further be coupled via bus12to a display24, such as a Liquid Crystal Display (“LCD”). A keyboard26and a cursor control device28, such as a computer mouse, may further be coupled to bus12to enable a user to interface with system10on an as needed basis.

In one embodiment, memory14stores software modules that provide functionality when executed by processor22. The modules include an operating system15that provides operating system functionality for system10. The modules further include a Wi-Fi offload module16for performing Wi-Fi offloading of cellular data, flexible policy routing, and all other functionality disclosed herein. System10can be part of a larger system, such as added functionality to the “Oracle Communications Security Gateway” from Oracle Corp. Therefore, system10can include one or more additional functional modules18to include the additional functionality. A database17is coupled to bus12to provide centralized storage for modules16and18.

Wi-Fi Offload Message Flows

FIGS. 3-15below, in general, are message flows of IP address assignment and data flow setup using DHCP in accordance with embodiments of the invention.FIG. 3is a DHCP-based message flow setup when interworking with a GGSN in accordance with one embodiment. The message flow is as follows:

1. An IP security (“IPsec”) tunnel is created between AP52and SG60at the time AP52is booted. AP52will relay all traffic between UE53and SG60over the IPsec tunnel. In some embodiments, the IPsec tunnel is an optional feature that is provided when security is desired between AP52and SG60. When the IPsec tunnel is created as needed, all traffic between AP52and SG60will be protected by IPsec.

2. UE53connects to AP52over Wi-Fi, and uses Extensible Authentication Protocol (“EAP”)-SIM authentication to authenticate with AAA server54.

3. The 802.1x connection setup completes, and UE53is now connected.

4. UE53broadcasts a DHCP Discover message in order to receive an IP address. The DHCP message contains the media access control (“MAC”) address of the UE in the DHCP “chaddr” field.

5. AP52acts as a BOOTP/DHCP relay server, and relays the DHCP broadcast towards SG60.

6. SG60receives the DHCP Discover message.a. If the address assignment will be done through a local address pool, SG60will assign the UE IP address prior to contacting AAA server54. Otherwise, AAA server54will be responsible for assigning the UE IP address.b. The DHCP Discover message is converted into an AAA Access-Request, which is sent to AAA server54.

7. AAA server54receives the Access-Request, and associates the MAC address with UE53that is already authenticated over EAP-SIM. If AAA server54is responsible for allocating the UE IP address, an IP will be assigned to UE53. AAA server54retrieves the GPRS profile information for UE53, and responds with an Access-Accept message.

8. SG60receives the Access-Accept, and generates a DHCP Offer with the IP address that was allocated to UE53. The profile information is stored in SG60to be used when later setting up the GTP tunnel. SG60stores the UE's profile returned in Access-Accept from AAA server54to be used later when setting up the GTP tunnel or re-authenticating the UE when it roams in and out of the Wi-Fi range.

9. AP52receives the DHCP Offer, and relays it back to UE53.

10. UE53wishes to accept the DHCP Offer, and sends a DHCP Request message.

11. AP52receives the DHCP Request, and relays it to SG60.

12. SG60receives the DHCP Request, and validates that the requested IP address matches the one offered. SG60determines that the policy for UE53is to route to GGSN56. SG60then initiates the GTP tunnel setup with GGSN56by sending a Create-PDP-Context Request to GGSN56.

14. The GTP-U tunnel is now established. SG60programs the flows between the GTP-U tunnel and the IPsec tunnel, if it was previously determined that the IPsec tunnel was needed for security and was previously created.

16. AAA Server54responds with an Accounting-Response, acknowledging the request.

17. SG60responds to the DHCP Request with a DHCP ACK message. This confirms that the IP address was successfully allocated to UE53for use.

18. AP52relays the DHCP ACK back to UE53.

19. UE53sends and receives data using the allocated IP address. AP52manages routing the traffic to and from SG60, and SG60will route the traffic to and from GGSN56over the GTP-U tunnel.

FIG. 4is a DHCP-based message flow setup when interworking with a default gateway, such as default gateway57, in accordance with one embodiment. The signaling flows when routing to default gateway57are identical to those ofFIG. 3except the Gn′ interface has been removed. Further, inFIG. 4, flows12-14ofFIG. 3replaced with the following flow:

12. Based on the UE profile information received from AAA server54(i.e., access point name (“APN”)), SG60determines that the policy is to route the UE traffic to default gateway57instead of GGSN56ofFIG. 3.

FIG. 5is a UE initiated DHCP-based teardown message flow when interworking with a GGSN in accordance with one embodiment. The message flow is as follows:

3. AAA server54responds back to the Accounting-Request.

4. AAA server54associates the accounting stop from AP52with the accounting session on SG60, and generates a Radius Disconnect-Request message to SG60, with the UE MAC address in the User-Name field.

5. SG60initiates GTP tunnel teardown by sending a Delete-PDP-Context request to GGSN56.

7. SG60removes all flow information for GTP and DHCP, and cleans up any active contexts.

9. AAA server54will release the IP address if allocated, and collect any accounting information. AAA server54then sends an Accounting-Response (Stop) back to SG60.

10. SG60responds to the Disconnect-Request with a Disconnect-ACK, signaling that all contexts have been cleared.

In another embodiment, a UE initiated DHCP-based teardown message flow is performed with a default gateway, such as default gateway57, instead of interworking with a GGSN as inFIG. 5. In this embodiment, the message flow is identical toFIG. 5except flows5and6are removed.

FIG. 6is a DHCP-based initiated release or timeout message flow when interworking with a GGSN in accordance with one embodiment. The message flow is as follows:

1. UE53may send a DHCP Release message to release the IP address that was allocated. The procedure would be the same as if the DHCP lease or other internal timers expire, so both procedures are covered in this example.

2. AP52relays the DHCP Release over the IPsec tunnel. As previously discussed, the IPsec tunnel is optional. If the IPsec tunnel was established during the offload initiation procedure, then the DHCP Release will be sent over the IPsec tunnel. Otherwise, it will be sent without using the IPsec tunnel.

3. SG60receives the DHCP Release, or an internal SG timer expires. SG60initiates GTP tunnel teardown by sending a Delete-PDP-Context request to GGSN56.

5. SG60removes all flow information for GTP and DHCP, and cleans up any active contexts.

7. AAA server54will release the IP address if allocated, and collect any accounting information. AAA server54then sends an Accounting-Response (Stop) back to SG60.

In another embodiment, a DHCP-based initiated release or timeout message flow is performed with a default gateway, such as default gateway57, instead of interworking with a GGSN as inFIG. 6. In this embodiment, the message flow is identical toFIG. 6except flows3and4are removed.

FIG. 7is a DHCP-based GGSN initiated teardown message flow in accordance with one embodiment. The message flow is as follows:

1. GGSN56initiates GTP tunnel teardown by sending a Delete-PDP-Context request to SG60.

3. SG60removes all flow information for GTP and DHCP, and cleans up any active contexts.

5. AAA server54will release the IP address if allocated, and collect any accounting information. AAA server54then sends an Accounting-Response (Stop) back to SG60.

Embodiments shown inFIGS. 8-10below are Internet Key Exchange version 2, under RFC 4306 (“IKE”)-based message flows. These message flows are based on the tunnel terminating gateway (“TTG”) functionality defined in Annex F of 3GPP TS 23.234 V11.0.0 Release 11 3GPP, “System to Wireless Local Area Network (WLAN) interworking”, the disclosure of which is hereby incorporated by reference. In the embodiments, there is an IPsec tunnel from each UE to the SG. The IKE exchanges are consolidated into Request and Response messages for clarity.

FIG. 8is an IKE-based message flow setup when interworking with a GGSN in accordance with one embodiment. The message flow is as follows:

1. UE53connects to AP52over Wi-Fi, and uses EAP-SIM authentication to authenticate with AAA server54.

2. The 802.1x connection setup completes, and UE53is now connected.

3. UE53attempts to establish an IPsec tunnel to SG60using IKE.

4. During IKE negotiation:a. If SG60is responsible for allocating the UE inner IP, an address is allocated from a local address pool.b. SG60triggers an Access-Request to AAA server54in order to authenticate the user and/or obtain an IP address and GPRS profile (see Table 2 above).

5. AAA server54responds with an Access-Accept, and includes the GPRS profile information, and IP address if allocated (see Table 3 above).

6. SG60receives the Access-Accept, and based on the profile information, determines the flow is to GGSN56.

7. SG60initiates the GTP tunnel setup with GGSN56by sending a Create-PDP-Context Request to GGSN56(see Table 6 above).

10. AAA server54responds with an Accounting-Response, acknowledging the request.

11. SG60completes IKE negotiation with the client, and returns the IP address that was allocated for UE53. The GTP-U tunnel is now established. SG60programs the flows between the GTP-U tunnel and the IPsec tunnel.

12. Data flows over the IPsec tunnel between UE53and SG60, and is routed to and from GGSN56.

In another embodiment, an IKE-based message flow setup is performed with a default gateway, such as default gateway57, instead of interworking with a GGSN as inFIG. 8. In this embodiment, the message flow is identical toFIG. 8except flows7and8are removed. Instead of establishing a connection with GGSN56, SG60determines that the flow is to a default gateway, and programs the data flow accordingly.

FIG. 9is an IKE-based message flow teardown when interworking with a GGSN that is IKE initiated in accordance with one embodiment. The message flow is as follows:

2. SG60initiates GTP tunnel teardown by sending a Delete-PDP-Context request to GGSN56.

4. SG60completes the IKE teardown procedure with the client.

5. SG60removes all flow information for GTP and IPsec, and cleans up any active contexts.

7. AAA server54will release the IP address if allocated, and collect any accounting information. AAA server54then sends an Accounting-Response (Stop) back to SG60.

In another embodiment, an IKE-based message flow teardown that is IKE initiated is performed with a default gateway, such as default gateway57, instead of interworking with a GGSN as inFIG. 9. In this embodiment, the message flow is identical toFIG. 9except flows2and3are removed.

FIG. 10is an IKE-based message flow teardown when interworking with a GGSN that is GGSN initiated in accordance with one embodiment. The message flow is as follows:

1. GGSN56initiates GTP tunnel teardown by sending a Delete-PDP-Context request to SG60.

3. UE53responds back to SG60and completes the teardown procedure.

5. SG60removes all flow information for GTP and IPsec, and cleans up any active contexts.

7. AAA server54will release the IP address if allocated, and collect any accounting information. AAA server54then sends an Accounting-Response (Stop) back to SG60.

Embodiments shown inFIGS. 11-14below are based on ePDG functionality as defined in 3GPP TS 23.402 V11.4.0 Release 11, “Architecture enhancements for non-3GPP accesses”, the disclosure of which is hereby incorporated by reference.FIGS. 11-14include a packet data network (“PDN”) gateway (“GW”), and a Home Subscriber Service (“HSS”) which manages the user database for AAA services.FIGS. 11-14further include a Policy and Charging Rules Function (“PCRF”) for policy control and charging rules. When roaming is involved, the PCRF is referred to as the “hPCRF” in the home network, and “vPCRF” in the visiting network.

FIG. 11is an ePDG based message flow for Initial Attach with GTP on S2b in accordance with one embodiment.FIG. 12is an ePDG based message flow for Detach and PDN Disconnection with GTP on S2b in accordance with one embodiment. S2b is the interface connection between ePDG and the PDN gateway.

FIG. 13is an ePDG based message flow for handover from 3GPP access (4G/3G) to untrusted Wi-Fi in accordance with one embodiment.FIG. 13includes a Mobility Management Entity (“MME”) which handles the signaling (control plane) related to mobility and security for the E-UTRAN access (LTE access).

1. UE53acquires LTE access to the core network.

2. UE53initiates the handover procedure and performs the mutual authentication towards the ePDG by using the IKEv2/EAP-AKA.

4. UE53requests an IP address in the IKEv2 message exchange. The ePDG creates and sends the “Create Session Request” message containing the IMSI, MSISDN and other parameters to the PDN GW.

6. The PDN GW sends the “Create Session Response” back; this contains the IP address to be assigned to UE53(the same IP as was being used by UE on the Radio access network (“RAN”)).

7. The ePDG will return the IP address to the UE using the IKEv2 message exchange. The IPSec and the GTP tunnels are established for the data traffic.

FIG. 14is an ePDG based message flow for Handover from Wi-Fi access to 3GPP access (3G/4G) in accordance with one embodiment.

FIG. 15is message flow for AP to AP roaming in accordance with one embodiment. The message flow forFIG. 15is as follows:

1. In case UE53roams from AP1to AP2, SG60will get a DHCP request message from AP2(once it detects that UE53has roamed from AP1) with the IP/MAC of UE53. Once received, SG60will know that the UE is now connected to AP2and the internal tables of SG60are updated.

2. The DHCP ACK is sent back to the AP2.

3. SG60will be able to reuse the GTP tunnel on the core side.

Wi-Fi Offload Accounting Support

Embodiments provide accounting support for Wi-Fi offload solutions, such as the solution shown inFIG. 3. This feature enables SG60to collect statistics about offloaded data per UE session and send the collected information to external RADIUS and Diameter AAA servers residing in the network.

The Radius accounting start request will be generated from SG60per UE53to AAA server54for the following events:1. After MSG gets a GTP-C Create PDP Context Response from GGSN56;2. In the case of “Routing to Gateway” call flow (as perFIG. 4above), after SG60gets a DHCP request with IP+MAC; or3. In the case of “IKE initiated flow to Gateway” call flow (as perFIG. 8above with default gateway), after SG60gets an Access-Accept from AAA server54.
The start request will contain the attributes disclosed in Table 9 below.

The Radius accounting stop request will be generated from SG60per UE53to AAA server54for the following events:1. Once SG60gets a GTP-C Delete PDP Context Response from GGSN56(as perFIG. 5above);2. If GGSN56is not involved in the call flow, once SG60receives a Disconnect-Request with UE MAC from AAA server54(as perFIG. 5above with default gateway);3. If GGSN56is not involved in the call flow, once SG60gets a DHCP release or lease timeout (as perFIG. 6above with default gateway);4. If GGSN56initiated the tunnel teardown, after SG60sends a GTP-C Delete PDP Context Response (as perFIG. 7above);5. In case of “IKE initiated tear-down” call flow without GGSN, after SG60sends a IKE tunnel disconnect response (as perFIG. 9above with default gateway); or6. Any unexpected error happened in the system after Accounting start record is sent.
The start request will contain the attributes disclosed in Table 9 below.

The following table discloses the Radius attributes in accordance with one embodiment:

For the Diameter start record, the format of an Accounting-Request (“ACR”) message that SG60will send to AAA server54in one embodiment is as follows:

<ACR> ::= < Diameter Header: 271, REQ >{ Session-Id }{ Origin-Host }{ Origin-Realm }{ Destination-Realm }{ Destination-Host }{ Accounting-Record-Type }{ Accounting-Record-Number }[ Acct-Application-Id ][ User-Name ][ Event-Timestamp ][ Framed-IP-Address ][ Calling-Station-Id ][3GPP-IMSI][3GPP-GGSN-Address][3GPP-WLAN-APN-Id][3GPP-PDP-IP-Address][3GPP-RAT-Type]The ACR AVPs:Session-Id AVP (263)—will be used to uniquely identify this session.Origin-Host AVP (264)—will be populated from the hostname field in the account-config data object and the origin-realm field and the domain-name-suffix field in the account-server sub-object for which server the request is destined to.Origin-Realm AVP (296)—will be populated from the origin-realm field and the domain-name-suffix field in the account-server sub-object for which server the request is destined to.Destination-Realm AVP (283)—will be populated by the value of the Origin-Realm AVP in the CEA received from the server for this connection.Destination-Host AVP (293)—will be populated by the value of the Origin-Host AVP in the CEA received from the server for this connection.Accounting-Record-Type AVP (480)—will be populated by the appropriate value for what type of accounting message is being sent, for START records the value is 2.Accounting-Record-Number AVP (485)—This is a value that uniquely identifies this message in the session. It amounts to a sequence number for this connection.Acct-Application-Id AVP (259)—will be set to the value of 3, this the value the base RFC calls for in Diameter based accounting messages.User-Name AVP (1)—is of type string and contains the MAC address of the UE.Event-Timestamp AVP (55)—This is the time in seconds that indicates the time when the GTP tunnel is established.Framed-IP-Address AVP (8)—contains the IP address allocated for the UE.Calling-Station-Id AVP (31)—This contains the MSISDN of the UE.3GPP-IMSI AVP (1)—This contains the IMSI of the UE.3GPP-GGSN-Address AVP (847)—This contains the IP address of the GGSN server.3GPP-WLAN-APN-Id AVP (100)—This contains the W-APN Id from which the user receives service from.3GPP-PDP-IP-Address AVP (1227)—This contains the IP address of the UE related to a particular PDP context.3GPP-RAT-Type AVP (21)—This contains the RAT that is currently serving the UE.

For the Diameter stop record, the format of ACR message that SG60will send to AAA server54in one embodiment is as follows:

<ACR> ::= < Diameter Header: 271, REQ >{ Session-Id }{ Origin-Host }{ Origin-Realm }{ Destination-Realm }{ Destination-Host }{ Accounting-Record-Type }{ Accounting-Record-Number }[ Acct-Application-Id ][ User-Name ][ Event-Timestamp ][ Termination-Cause ][ Acct-Session-Time ][ Framed-IP-Address ][ Calling-Station-Id ][ Accounting-Input-Octets ][ Accounting-Output-Octets ][ Accounting-Input-Packets ][ Accounting-Output-Packets ][3GPP-IMSI][3GPP-GGSN-Address][3GPP-WLAN-APN-Id][3GPP-UE-IP-Address][3GPP-PDP-IP-Address][3GPP-RAT-Type]The ACR AVPs:Acct-Session-Time AVP (46)—contains the length of the tunnel lifetime in seconds. It can only be present in ACR messages for Interim Record or Stop Record.Accounting-Input-Octets AVP (363)—contains the number of octets into the UE.Accounting-Output-Octets AVP (364)—contains the number of octets out of the UE.Accounting-Input-Packets (365)—contains the number of packets into the UE.Accounting-Output-Packets (366)—contains the number of IP packets out of the UE.The new 3GPP attributes description is the same as disclosed above for the Start record.

DHCP IP Address Assignment for Endpoints

In connection with the message flow disclosed in conjunction withFIG. 3above, SG60will mimic the functionality of a DHCP server in order to assign UE IP addresses in one embodiment. In one embodiment, the IP address assignment is as follows:In flows2and3ofFIG. 3, UE53connects to AP52over 802.1x, and is initially authenticated using EAP-SIM between AP52and AAA server54.Once UE53is connected to AP52, it will send a DHCPDISCOVER broadcast message in order to obtain an IP address, as shown in flow4ofFIG. 3.AP52will be responsible for relaying the DHCP requests between UE53and SG60. The connection between AP52and SG60may be secured with a single IPsec tunnel per AP/SSID. In this case, the DHCP messages will be relayed over the IPsec tunnel, as shown in flow5ofFIG. 3.When SG60receives the DHCPDISCOVER request, it will first determine who is responsible for assigning the IP address. The method for IP address assignment will be configurable. The addresses may be assigned through a local address pool in the same fashion as already implemented for IKE local address pools, or AAA server54can be responsible for assigning the IP address.If SG60is allocating the IP addresses, the address will be allocated prior to the AAA exchange, otherwise AAA server54will return the allocated IP address. SG60converts the DHCPDISCOVER into an Access-Request message, as shown in flow6bofFIG. 3.AAA server54receives the Access-Request message, and associates the UE MAC with the UE that already authenticated with AP52using EAP-SIM. If AAA server54is responsible for allocating the UE IP Address, it will assign an IP which will be returned in the response. AAA server54will also query the GPRS profile information for the user, and return those parameters in the Access-Accept message sent to SG, as shown in flow7ofFIG. 3.SG60receives the Access-Accept response from AAA server54, and converts it into a DHCPOFFER request that is sent towards UE53. The offer includes the IP address that was allocated for UE53, as shown in flow8ofFIG. 3.The DHCPOFFER will be forwarded back to UE53, and UE53will determine if it wishes to accept the offer. If so, it will send a DHCPREQUEST message, requesting the IP address that was in the offer message, as shown in flows9-11ofFIG. 3.SG60receives the DHCPREQUEST message, and validates it against the offer. If the request is invalid, such as an invalid IP address, SG60responds with a DHCPNAK and the transaction terminates.Depending on the UE profile information received from AAA server54, along with local configuration, SG60may contact GGSN56to establish a GTP tunnel for UE53, as disclosed above. When contacting GGSN56, a “remote” inner IP address may be assigned by GGSN56. In this case, the UE's IP address will be replaced by this GGSN assigned “inner IP” for the user traffic (GTP data channel) between SG60and GGSN56.SG60may start accounting at this point, as disclosed above.If all flows installed correctly and any GTP tunnels are set up, a DHCPACK message is sent back to the client, and the client is free to send and receive data traffic.

FIG. 16is a flow diagram of the functionality of Wi-Fi offload module16ofFIG. 2when performing Wi-Fi offload in accordance with embodiments of the present invention. In one embodiment, the functionality of the flow diagram ofFIG. 16, andFIG. 17below, is implemented by software stored in memory or other computer readable or tangible medium, and executed by a processor. In other embodiments, the functionality may be performed by hardware (e.g., through the use of an application specific integrated circuit (“ASIC”), a programmable gate array (“PGA”), a field programmable gate array (“FPGA”), etc.), or any combination of hardware and software. In general, the functionality ofFIG. 16is implemented by SG60ofFIG. 1, while interacting with other network elements ofFIG. 1.

At1610, an IP security tunnel is optionally created between AP52and SG60.

At1620, SG60receives a DHCP broadcasted message that was broadcast by UE53and relayed by AP52.

At1630, SG60assigns an IP address through a local address pool for UE53, or through AAA server54, and converts the DHCP message into an AAA access request that is sent to AAA server54.

At1640, SG60receives an AAA access accept from AAA server54and generates a DHCP offer.

At1650, SG60receives a DHCP request with an IP address from1630and, based on a policy for UE53, initiates a GTP tunnel setup with GGSN56.

At1660, SG60programs message flows between the GTP-U tunnel and the IPsec tunnel, if the tunnel is created at1610.

As disclosed, embodiments provide Wi-Fi offload functionality for cellular data. Embodiments include a DHCP server to process DHCP requests from mobile devices (i.e., UEs) and interact with policy servers (i.e., AAA servers) to authorize UE access and get proper access parameters (e.g., APN, IP, SUBNET MASK, DNS, etc.). Embodiments can assign IP addresses from a local address pool or from the policy server on the UE side (for traffic between the UE and the SG) and optionally, the GGSN can assign an IP address for the UE for traffic between the SG and the GGSN.

Embodiments further include an SG routing agent that can set up the routing decision based on routing policies configured and the parameters from the UE and the policy server. Further, a GTP agent interacts with a DHCP agent to set up GTP tunnel with provisioned GGSN gateway if GTP routing is selected.

In embodiments, once a GGSN server is selected and a GTP tunnel is established, GTP traffic flows (inbound and outbound) are created on a dedicated hardware platform to handle GTP tunnel traffic in real-time to support high throughput. Further, an accounting agent creates various accounting records to accounting servers (e.g., AAA or diameter).

Embodiments further support high availability (“HA”) with HA setup and protects real time traffic from switchovers. All UE's profiles, SG routing decisions, GTP tunnels on hardware, etc. are synchronized to a standby system in real time to guarantee no traffic interruption. Embodiments support IKEv2 and IPsec protection if configured between an AP/Wi-Fi hot-spot and a security gateway access interface. Finally, if a UE can get an IP address from an AP, embodiments support IKEv2/IPSEC between a UE and a security gateway access interface (LTE mode).

As disclosed above, embodiments provide Wi-Fi offload of cellular data to offload traffic from a service provider's Radio Access Network (“RAN”) to IP networks using Wi-Fi connections. Wi-Fi offload offers a cost-effective means of offloading large amounts of mobile data traffic while delivering a variety of new services. As disclosed above, IPsec is optional for Wi-Fi offload in accordance to embodiments. However, some embodiments include a policy based routing of the offloaded Wi-Fi data independent of whether or not IPSec is involved.

In one embodiment, SG60includes a routing policy for egress traffic of UE53(i.e., data received from UE53). In this embodiment, each UE is associated with an APN (i.e., an “associated access point name”) or International Mobile Subscriber Identity (“IMSI”) during Wi-Fi signaling. SG60will route each UE's traffic based on the associated APN or IMSI. Although APN/IMSI based routing is disclosed, other embodiments can be applied to other identity based routing. Embodiments use an “sg-policy”parameter that can be configured for each APN/IMSI to define how to route traffic for the UEs associated with each particular APN/IMSI. Embodiments may route traffic to a pre-configured GGSN56or directly to the Internet.

In one embodiment, during the initialization process of UE53, such as shown inFIG. 3above, SG60will assign a unique IP address (locally or through AAA server54) to UE53and UE53will also be associated with a specific APN/IMSI. The sg-policy configured for the APN/IMSI will indicate where to route the traffic. It can specify to route traffic from UE53(based on the assigned IP-APN/IMSI association) to GGSN56server (via GTP tunnel62) or to Internet59(through the policy's egress realm). Therefore, as UE53finishes signaling, SG60has all the information to set-up a message flow for the egress traffic.

Specifically, the IP address assigned to UE53from either SG60or AAA server54is used to match the egress message flow. SG60also maintains an association between the UE's IP and its APN/IMSI. From the configured sg-policy for each APN, SG60knows the GGSN and its associated User Datagram Protocol (“UDP”) ports. In one embodiment, instead sending traffic to a GGSN, the sg-policy for the UE's APN/IMSI is to route the UE's traffic directly to the Internet59.

One embodiment provides routing for ingress traffic to UE53when GTP-U (GTP user data tunneling) packets come in on the well-known UDP port2152. As a result, SG60can classify the ingress traffic as either GTP-U or non-GTP-U packets. For any traffic coming in from the Internet (non GTP traffic), it would be processed the same way as SG's60data pass-through traffic. For the traffic coming in from a GGSN as GTP-U traffic, its GTP/UDP/IP tunnel header needs to be removed first and its inner destination IP (UE's assigned IP) would be used to match the UE's NAT flow for further processing.

One embodiment routes a UE's ingress traffic from GGSN (GTP tunneled packets). In this embodiment, for any inbound packets classified as GTP-U traffic, a “GTP-ingress-process” will be called for inbound GTP processing, which would remove their outer GTP/UDP header and get the inner user data packets (destined to UE's IP addresses). During each UE's signaling (IKE/DHCP/GTP), the UE's assigned IP address, TEID (tunnel endpoint identifier), interface and vlan id, GGSN's IP and port will be sent to the multi-processor core of SG60and maintained by an UE hashTable indexed by UE's IP. The GTP-ingress-process does not require the detailed information for an UE, but the information can be used to verify whether the tunneled GTP packet is valid for the UE and the hashEntry for the UE can be used to save statistics for the UE. The GTP-ingress-process does the following:Check a GTP packet to see whether it is host bound (GTP-U error). If yes, the packet will be sent to the host.For GTP-U echo request, the GTP-U response will be formed and sent out by the ingress port.For GTP-U data pass-through packet, remove its GTP/UDP/IP tunnel header, switch to a new tag based on its inner destination IP (unique to the UE).Verify the de-tunneled packet by TEID with UE's IP, GGSN IP and port, interface/vlan ID.The de-tunneled packet will be matched against the SG's inbound data pass-through flow and be processed the same way as the SG's pass-through data packets afterwards.

One embodiment provides flow matching for Wi-Fi offload. With well-known UDP port2152, or other configured port, defined for GTP-U traffic, SG60will classify a GTP-U packet in a UE's inbound packet processing. Once classified as GTP-U, the GTP-ingress-process would be called for GTP-U de-tunneling and the inner IP would be used for nat-flow match and any further processing afterwards. For a UE's outbound traffic, the UE's assigned IP can be used for GTP-egress-process. A simplified GTP-Packet Processing Module (“PPM”) will be defined to handle communication between host and SG60, and setup hashEntry for a UE dynamically during the UE's signaling process (IKE/DHCP/GTP).

Therefore, embodiments include a flexible policy based routing for traffic originating from mobile users via UE53through SG60, in contrast with the current often used routing for Wi-Fi offload solutions, APN only based routing. Embodiments base the routing on flexible policies for each access interface (or routing realm). Each policy can be configured with a routing criteria, which can be based on APN, the UE's IP network, IMSI, MSISDN, or QOS, or a future application. In addition, each policy is also configured with a priority number so, for example, the lower the number, the higher the priority. If multiple policies are assigned to a routing realm, the policies are matched by the policies' priority. The policy match is flexible as well: it can be “exact match”, a “prefix match” or a “regular expression (“regex” match”) in one embodiment. For example, “[A-Z]123456” would match any string which starts with a capital letter followed by “123456”.

Below are some examples of simplified routing policies to illustrate routing decisions in accordance with embodiments of the present invention:

1. A service provider customer requires that traffic from any UE with an APN of “foo.com” is to be routed to its dedicated GGSN server by GTP tunneling. Further, traffic from other UEs is to be routed to the Internet by a router. As a result, two policies (“gtp-policy” and “internet-policy”) need to be configured for this customer's routing demands.

When a UE53registers through Wi-Fi with SG60, it could be assigned the APN value “foo.com”. With the above policies, the traffic from UE53would match “gtp-policy” and be routed to a GGSN server with GTP tunneling (depending which gtp-profile to use by “hunt” method). For any other UEs (not assigned with APN “foo.com”), the traffic would be routed to a router defined by “ip-policy”. The policy “internet-policy”, “match-field none” acts as a default policy for traffic.

2. An enterprise customer requires that UE53within a certain IMSI range be routed to a protected network and anything else be routed to its general network. As a result, two policies (“protect-policy” and “internet-policy”) need to be configured for this customer's routing demands.

When a UE53registers with SG60with an IMSI beginning with “3101501234”, its traffic would match policy “protect-policy” and its traffic would be routed to the protected network defined by “subnet-profile”. Again, traffic from other UEs would be routed by policy “internet-policy”.

FIG. 17is a flow diagram of the functionality of Wi-Fi offload module16ofFIG. 2when performing a flexible routing policy for Wi-Fi offloaded data in accordance with embodiments of the present invention.

At1702, a data packet is received from a UE. The data packet was offload from a cellular network onto a Wi-Fi network via a Wi-Fi access point, as disclosed inFIG. 16above. The data packet has an associated APN and an associated IP address.

At1704, the data packet is evaluated based on two or more defined routing policies, with each routing policy having a routing criteria and a priority. The routing criteria can be based on an identifier of the data packet, such as its APN or IP address. Each routing policy routes the data packet to a different destination, such as a GGSN server or to an Internet router.

At1704, based on the routing policy and the priority, the data packet is routed to one of at least two different possible destinations.

In one example embodiment, for a specific deployment, four policies are configured in a routing realm: (1) APN routing for foo1.com and route traffic to GGSN1 with priority=10; (2) IMSI routing for prefix “12345” and route traffic to GGSN2 with priority=20; (3) APN routing with regex matching for “foo*.com” and route traffic to GGSN3 with priority=30; (4) default route (no match) to a gateway (“GW”) with priority=40. With the above policies, for a UE with an APN=foo1.com, its traffic would be routed to GGSN1. For a UE with IMSI=12345999 and its APN is not foo1.com, its traffic would be routed to GGSN2. For any UE with APN=foo555 and its IMSI, if present, does not have the prefix of 12345, its traffic would be routed to GGSN3. For any UE which has an APN that does not match policy 1 or policy 3 and its IMSI, if present, does not has the prefix of 12345, its traffic would be routed to the GW. As a result, by configuring different policies with different routing criteria and priorities, a UE's traffic can be routed flexibly. With new applications emerging for UEs, new routing criteria can be defined and be used to route this new traffic.

As disclosed, embodiments provide a flexible policy based selective offload. Parameters returned from the policy server or the information contained in the data packets of Wi-Fi offloaded data is used to make selective offload decisions. For example, as described above, a UE's APN, IMSI, MSISDN, QOS profile, and optionally a UE's IP can be obtained from the policy server and can be configured in a sg-policy for routing. Therefore, intelligent routing of data traffic directly to the Internet or to the GGSN (i.e., mobile core) is provided. Further, as disclosed, embodiments provide flexible IP address management, optional IPSec protection, high performance, unique 1:1 redundancy and accounting support.