Method and device for policy-based routing

A mobile device performs a method for policy-based routing. The method includes creating a first set of marking rules based on routing policy data provisioned in the mobile device, wherein each marking rule indicates labeling for packets, wherein the labeling is used in selecting one of a plurality of active network interfaces in the mobile device to route the packets over a set of access networks available to the mobile device. The method further includes creating a first set of routing tables corresponding to the labeling indicated by the first set of marking rules, wherein each routing table directs the mobile device to a different one of the active network interfaces of the plurality of active network interfaces.

FIELD OF THE DISCLOSURE

The present disclosure relates generally to wireless communications and more particularly to a method and device for policy-based routing.

BACKGROUND

As it becomes more and more common for wireless communication devices to implement multiple wireless access technologies, wireless network operators are beginning to deploy different wireless access networks (also referred to in the art as radio access networks (RANs) and also referred to herein simply as access networks) that share a same core network. For example, some operators of networks that implement and/or are compliant with one or more 3rdGeneration Partnership Project (3GPP) standards or specifications, such as Long Term Evolution (LTE) networks, are planning to integrate WiFi networks into their existing cellular network infrastructure. Such WiFi networks are termed in the standards as “trusted” WiFi networks.

To take advantage of the expansion in available wireless access network coverage, wireless communications devices are increasingly being designed with the capability of maintaining multiple active network interfaces over one or more available wireless access networks. Accordingly, the wireless communication devices should also be capable of handling routing policy or preferences, e.g., of the network operator and/or users of the device, for the multiple active network interfaces. A current technique used to support routing across different active network interfaces involves populating a routing table with suitable entries that direct the routing of packets over particular network interfaces based on an endpoint identification such as a destination Internet Protocol (IP) address. However, since wireless communication devices are being provisioned with increasingly complicated routing policies, the approach of routing packets with a single routing table based on endpoint identification is insufficient.

DETAILED DESCRIPTION

Generally speaking, pursuant to the various embodiments, are methods and a wireless communication device, also referred to herein as a mobile device, configured for policy-based routing. In accordance with one particular embodiment is a method for policy-based routing, which includes creating a first set of marking rules based on routing policy data provisioned in the mobile device. Each marking rule indicates labeling for packets, wherein the labeling is used in selecting one of a plurality of active network interfaces in the mobile device to route the packets over a set of access networks available to the mobile device. The method further includes creating a first set of routing tables corresponding to the labeling indicated by the first set of marking rules, wherein each routing table directs the mobile device to a different one of the active network interfaces of the plurality of active network interfaces.

In accordance with another embodiment is a mobile device configured for policy-based routing. The mobile device includes a memory component and a processor coupled to the memory component. The memory component is configured to store provisioned routing policy data. The processor is configure to create a first set of marking rules based on the routing policy data provisioned in the mobile device, wherein each marking rule indicates labeling for packets, wherein the labeling is used in selecting one of a plurality of active network interfaces in the mobile device to route the packets over a set of access networks available to the mobile device. The processor is further configured to create a first set of routing tables corresponding to the labeling indicated by the first set of marking rules, wherein each routing table directs the mobile device to a different one of the active network interfaces of the plurality of active network interfaces.

In accordance with at least some of the various embodiments of the present teachings, a mobile device can implement policy-based routing over multiple active network interfaces with more flexibility than possible with conventional routing mechanisms. For example, the present teachings regarding policy-based routing can easily accommodate updates to routing policy provisioned in the mobile device by a network operator through a network device or by a user of the mobile device through a user interface. Moreover, the present teachings regarding policy-based routing can also accommodate changes to the active network interfaces and changes to access networks that are available to the mobile device. In addition, the present teachings regarding policy-based routing do not require implementing complicated user-plane tasks that introduce user-plane delays (such as comparing each packet with the provisioned policy) but can be implemented by configuring a routing layer within the mobile device (i.e., the software layer that implements a protocol such as Internet Protocol, which handles packet routing), which is more efficient and requires less processing than comparing each packet with the provisioned policy and making routing decisions. Furthermore, the present teachings regarding policy-based routing can support more than destination address or endpoint identification based routing but also supports other types of routing including, but not limited to, application or source based routing, user preference based routing, etc.

Turning now toFIG. 1, illustrated therein is a schematic diagram of an example environment100within which may be implemented methods and devices for policy-based routing, in accordance with the present teachings. In this particular embodiment, a wireless communication device102, which in this example is a mobile or portable device, is configured for establishing wireless links to infrastructure equipment within multiple access networks, e.g., an access network104and an access network110, to, for instance, exchange data and voice communications with other mobile or portable devices or with other devices such as printers and servers. At any given point in time, the access networks that are in range of a wireless communication device and with which the wireless communication device is configured to establish wireless links are termed herein as available access networks to the wireless communication device. The two access networks104and110can use any type of access technology for a wireless communication device to access and communicate using the access network; but in one embodiment, two different access technologies are used to, respectively, communicate over the two access networks104and110. Access technologies are also referred to herein as wireless access technologies and also known in the art as radio access technologies (RATs).

In this illustrative embodiment, the access network104is a Wireless Local Area Network (WLAN) having at least one access point, e.g.,106,108, for facilitating wireless links, e.g.,126, using Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards, also referred to in the art as WiFi technology. Thus, access network104is also referred to herein as a WiFi network or a WiFi access network. However, any other type of wireless access technology such as Worldwide Interoperability for Microwave Access (WiMax) or a cellular or cellular-based access technology may be implemented in the access network104.

The access network110is a cellular access network, also referred to herein as a cellular network, having at least one cellular tower or base station, e.g.,112, for facilitating wireless links, e.g.,138, to the access network110. As shown, the cellular network110and a core network that supports communications using the cellular network110are implemented using 3GPP standards also referred to herein as 3GPP specifications, for example as an LTE network. More particularly, the cellular network110is an Evolved UMTS Terrestrial Radio Access Network (E-UTRAN) or a legacy UTRAN having at least one eNodeB, e.g.,112, for facilitating wireless links to user equipment (UE) such as the wireless communication device102.

In an embodiment, the cellular access network110uses E-UTRA as the RAT. However, any other cellular or cellular-based access technology can be used including, but not limited to: an analog access technology such as Advanced Mobile Phone System (AMPS); a digital access technology such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Global System for Mobile communication (GSM), integrated Digital Enhanced Network (iDEN), General Packet Radio Service (GPRS), Enhanced Data for GSM Evolution (EDGE), etc.; and/or a next generation access technology such as Universal Mobile Telecommunication System (UMTS), Wideband CDMA (WCDMA), IEEE 802.16, etc., or variants thereof.

The core network that supports and interconnects the WiFi network104and the cellular network110is, in this embodiment, a System Architecture Evolution (SAE) core, also referred to in the art as an Evolved Packet Core (EPC). The EPC subcomponents can include, among other subcomponents, a Mobility Management Entity (MME) not shown, a Serving Gateway (S-GW)118, a PDN Gateway (P-GW)120, a Home Subscriber Server (HSS) not shown, an Access Network Discovery and Selection Function (ANDSF) server128, and an Evolved Packet Data Gateway (ePDG) not shown.

The ANDSF server128interfaces to the mobile device102using a S14 interface130that enables IP level communications between the ANDSF server128and an ANDSF client (not shown) in the mobile device102. The cellular network110interfaces to the EPC using an S5 interface124between the P-GW120and the S-GW118. In the present embodiment, the WiFi network104is implemented as a trusted WiFi network and, therefore, includes a Trusted WiFi Access Gateway (TWAG)116. The WiFi network104interfaces to the EPC using an S2a interface122between the P-GW120and the TWAG116. The 3GPP interfaces, also referred to in the 3GPP specifications as reference points, and the 3GPP EPC subcomponents and other 3GPP network devices, e.g., the TWAG116, shown inFIG. 1are well known and are specified in various 3GPP specifications. Therefore, details of their functionality, operation, construct, and/or implementation are omitted herein for the sake of brevity.

As shown, the wireless communication device102maintains two physical wireless links used to support one or more active communication sessions in order to communicate data such as video and/or voice. More particularly, the wireless communication device102has a wireless link126to the access point108in the WiFi network104to communicate data using the WiFi network104; and the wireless communication device102has a wireless link138to the base station112in the cellular network110to communicate data using the WiFi network110.

In an embodiment, the link126supports a direct WLAN connection, which refers to a layer 3 or network layer connection that corresponds to and is implemented using a network or data interface (for instance an Internet Protocol (IP) interface having associated therewith an IP address), for non-seamless WLAN offload routing through the WiFi network104. The link126may also support a packet data network (PDN) layer 3 connection that corresponds to and is implemented using a separate data interface for access point name (APN) routing through the WiFi network104. More particularly, as shown and described in more detail by reference toFIG. 3, the mobile device102can have multiple active network or data interfaces using the single physical WiFi link126: one direct interface (such as a Direct WLAN interface350shown inFIG. 3corresponding to a Direct WLAN connection) and zero or more virtual private network (VPN) interfaces (such as a WLAN PDN interface352shown inFIG. 3corresponding to a WLAN PDN connection). The direct interface is created when the mobile device102connects to and establishes the physical link126using the access point108. A VPN interface (WLAN PDN) can be created later to establish a logical layer 3 connection between the mobile device102and a Packet Data Network (PDN) connected to a P-GW, e.g.,120ofFIG. 1, in the core network (EPC). A PDN can be, for example, an enterprise network, an IP Multimedia Subsystem (IMS), the Internet, etc. Accordingly, as used herein: a link refers to a physical connection; a layer 3 or network connection refers to a logical connection (that may be represented by an APN, security methods, an IP address, etc.) used by the mobile device102to route data packets using a particular network (which may include a particular PDN) using a given physical link; and a data, network, or VPN interface refers to a logical construct that the mobile device uses which corresponds to and facilitates routing using a given network connection. As such, a layer 3 connection and its corresponding data interface may be referred to herein interchangeably.

All packets that go to the direct interface (Direct WLAN) are delivered to the WLAN104, which then routes them forward. On the contrary, all packets that go to a VPN interface (WLAN PDN) are forwarded to a P-GW in the EPC, which then forwards them to an external PDN. In other words: packets sent to the direct interface do not traverse EPC (are offloaded directly to the WLAN104); and packets sent to a WLAN PDN interface go to EPC. Note that traffic sent to the direct interface is interrupted when WiFi is lost (cannot be handed over to EPC), hence this traffic is called “non-seamless WLAN offload” traffic. However, traffic sent to a WLAN PDN interface can be seamlessly handed over to UTRAN/E-UTRAN when the WiFi is lost, hence this traffic is called “seamless WLAN offload” traffic. In accordance with the teachings herein, methods can be performed by the wireless communication device102for policy-based routing over a plurality of active network interfaces, for example over multiple active network interfaces corresponding to the wireless links126and138.

Referring now toFIG. 2, there is provided a block diagram illustrating example internal hardware components200of the wireless communication device102ofFIG. 1, in accordance with the present embodiment. The wireless communication device102is intended to be representative of a variety of mobile devices or UE including, for example, cellular telephones, personal digital assistants (PDAs), smart phones, laptop computers, tablets, phablets, or other handheld or portable electronic devices. As shown inFIG. 2, the internal hardware elements or components200include one or more transceivers202, one or more processors210, output components212, a component interface220, one or more sensors222, a memory component224, input components226, and a power supply234. As further illustrated, the internal components200are coupled to one another, and in communication with one another, by way of one or more internal communication links236, for instance an internal bus. A limited number of device components202,210,212,220,222,224,226, and234are shown at200for ease of illustration, but other embodiments may include a lesser or greater number of such components in a device, such as device102. Moreover, other elements needed for a commercial embodiment of a device that incorporates the components shown at200are omitted fromFIG. 2for clarity in describing the enclosed embodiments.

We now turn to a brief description of the components within the schematic diagram200. In general, the processor210and memory224may be configured with functionality in accordance with embodiments of the present disclosure as described in detail below with respect to the remainingFIGS. 3-5. “Adapted,” “operative,” “capable” or “configured,” as used herein, means that the indicated components are implemented using one or more hardware elements, which may or may not be programmed with software and/or firmware as the means for the indicated components to implement their desired functionality. Such functionality is supported by the other hardware shown inFIG. 2, including the device components202,212,220,222,226, and/or234.

Continuing with the brief description of the device components shown at200, as included within the device102, the wireless transceivers202include a cellular transceiver204, a WLAN transceiver206, and a Global Positioning System (GPS) transceiver208. More particularly, the cellular transceiver204is configured to implement any suitable cellular or cellular-based technology to conduct cellular communications of data over a cellular network, such as the cellular network110. The WLAN transceiver206is a WiFi transceiver206configured to conduct WiFi communications over a WiFi network, such as the WiFi network104, in accordance with the IEEE 802.11 (a, b, g, n or ac) standard.

The processor210includes arithmetic logic and registers necessary to perform the digital processing required by the device102to, for example, perform policy-based routing in a manner consistent with the embodiments described herein. For one embodiment, the processor(s)210represent a primary microprocessor or central processing unit (CPU) of the device102such as an application processor of a smartphone102. In another embodiment, the processor(s)210represent a baseband processor or other ancillary or standalone processor to the CPU that is used by one or more of the wireless transceivers202to provide the processing capability, in whole or in part, needed for the device102to perform its intended functionality including wireless transmissions to facilitate the device's operation in accordance with the present teachings, for instance by reference to the flow diagrams shown inFIGS. 4-5. Depending at least in part on the particular function being performed and a given device102design, various functionality or protocols may be executed by the processor210in hardware or as software or firmware code.

In the embodiment shown, the output components212include: one or more visual output components214such as a liquid crystal display and/or light emitting diode indicator; one or more audio output components216such as a speaker, alarm, and/or buzzer; and one or more mechanical output components218such as a vibrating mechanism. Similarly, the input components226include one or more visual input components228such as a camera lens and photosensor; one or more acoustic receiver or audio input components230such as one or more transducers (e.g., microphones), including for example a microphone array and beamformer arrangement or a microphone of a Bluetooth headset; and one or more mechanical input components232such as a touchscreen display, a flip sensor, keyboard, keypad selection button, and/or switch.

As mentioned above, this embodiment of internal components200also includes one or more of various types of sensors222as well as a sensor hub to manage one or more functions of the sensors. The sensors222include, for example, proximity sensors (e.g., a light detecting sensor, an ultrasound transceiver or an infrared transceiver), touch sensors, altitude sensors, an accelerometer, a tilt sensor, and a gyroscope, to name a few.

The memory component224encompasses, in some embodiments, one or more memory elements of any of a variety of forms, for example read-only memory, random access memory, static random access memory, dynamic random access memory, etc. In an embodiment, the processor210uses the memory component224to store and retrieve data. In some embodiments, the memory component224is integrated with the processor210into a single component such as on an integrated circuit. However, such a single component still usually has distinct portions/sections that perform the different processing and memory functions.

The data that is stored by the memory component224includes, but need not be limited to, operating systems, programs (e.g., applications, protocols, and other code), and informational data. Each operating system includes executable code that controls basic functions of the wireless communication device102, such as interaction among the various components included among the internal components200, communication with external devices via the wireless transceivers202and/or the component interface220, and storage and retrieval of programs and data, to and from the memory component224. As for programs, each program includes executable code that utilizes an operating system to provide more specific functionality, such as file system service and handling of protected and unprotected data stored in the memory component224. Such programs include, among other things, programming for sending and receiving various data such as voice and/or video and for enabling the wireless communication device102to perform methods or processes such as described below by reference toFIGS. 3-5. Finally, with respect to informational data, this is non-executable code or information such as routing policy data that an operating system or program references and/or manipulates, in one embodiment, for performing functions of the wireless communication device102.

In an embodiment, the component interface220provides a direct physical connection to auxiliary components such as a docking station or printer or accessories for additional or enhanced functionality. For example, the component interface can be implemented as one or more Universal Serial Bus (USB) ports, RS-232 or other serial connectors, etc. The power supply234, such as a battery, provides power to the other internal components200while enabling the wireless communication device102to be portable.

FIG. 3is a block diagram illustrating functional aspects of the present teachings including, but not limited to, programs and corresponding informational data that can be stored in memory and executed by a processor within a wireless communication device, such as the device102ofFIG. 1. More particularly,FIG. 3shows at300an example implementation of a protocol stack or protocol suite having multiple “layers” that each have, include, contain, or implement one or more protocols, procedures, and/or algorithms that enable various functionality of the wireless communication device102in accordance with the present disclosure illustrated, for instance, by reference toFIGS. 3-5. In one embodiment, the protocol stack shown at300is executed by one or more processors210using protocols, procedures, algorithms, and informational data (such as provisioned routing policy and marking rules and corresponding routing tables created in accordance with the present teachings), stored in the memory component224.

The protocol stack shown at300includes three layers or sections: (a) an application layer360; (b) an OS framework layer314; and (c) a routing layer316. The protocol stack can include other layers not shown, for instance other layers corresponding to an Open System Interconnection (OSI) model of networking or corresponding to an Internet Protocol suite. Such layers include, for example, a physical layer, a data link or link layer, a transport layer, a session layer, or a presentation layer.

The application layer360contains various applications including, but not limited to, a Skype application (app)302, an IMS-based application304(also referred to herein as an IMS client) that supports voice or video over IP, file sharing, etc., and a third application APP-3306, e.g. a Multimedia Messaging Service (MMS) application. Applications302,304, and306initiate the establishment of an active communication session, for instance a voice call by the Skype application302and a video session by the IMS client304. An active communication session occurs between specific points in time when the session is established and torn down using the requisite signaling to enable ongoing communication of traffic between two endpoints. The traffic can be in the form of data chunks referred to herein generally as packets. During an active communication session, an application generates outgoing traffic or packets that are provided to and/or forwarded using one of a plurality of active network interfaces selected in accordance with the present teachings for routing the packets to an endpoint over the access network associated with and/or identified by the selected access network interface.

The OS framework layer314implements a set of functions that support the communication between the application layer360and, at least, a transport layer (not shown). Layer314enables the applications302,304,306to utilize the transport services provided by the transport layer and also to utilize other services provided by other layers not shown inFIG. 3. Such services may include location services, media rendering services, content encoding, presentation services, etc. The Operating System (OS) framework layer314includes an ANDSF client326having functionality for communicating with an ANDSF server, such as the ANDSF server128shown in environment100ofFIG. 1, in accordance with the 3GPP specifications, e.g., Technical Specification (TS) 24.312 and TS 23.402 clause 4.8. The OS framework layer314further includes a routing manager332in accordance with the present teachings, as described in detail later.

The routing layer316, also referred to as a network layer of the OSI model and as the Internet layer of an Internet Protocol suite, enables packets to be effectively routed through a set of, meaning one or more, access networks. In this particular embodiment, the routing layer316is an IP layer in a Linux kernel. The routing layer316includes a packet marking function340and a policy-based routing function348to implement policy-based routing in accordance with the present teachings, as explained in detail later. The remaining couplings or interfaces between the components and layers of the protocol suite shown at300and the corresponding functionality of such components is described by reference to flow diagrams illustrated inFIGS. 4 and 5.

We turn now to a detailed description of the functionality of the device102ofFIG. 1and device components200ofFIG. 2implementing protocols, procedures, and/or algorithms in accordance with the teachings herein illustrated by reference toFIGS. 4 and 5and by further reference to aspects illustrated inFIG. 3.FIGS. 4 and 5show logical flow diagrams illustrating general methods400and500, respectively, performed by a device, such as the device102, for policy-based routing in accordance with the present teachings. More particularly,FIG. 4is directed to a method400that can be implemented to configure the routing layer316for policy-based routing over multiple active network interfaces based on routing policy data provisioned in the mobile device102.FIG. 5is directed to a method500that can be implemented to route packets using the routing layer configurations resulting from implementing method400. In a particular implementation, at least some portions of the methods400and500are performed using at least one processor210and the memory224of the device102.

Turning now to the details of method400(also described by reference to aspects ofFIG. 3), the mobile device102receives402and is, thereby, provisioned with routing policy data. Routing policy data also referred to herein interchangeably as routing policy, as used herein, includes one or more rules that identify network operator (operator) and/or mobile device user preferences of access networks to route certain application traffic. In one embodiment, the routing policy data includes user directed policy328that is provisioned322in the mobile device102through a user interface of the mobile device102, e.g., one or more of the input components226. For example, a user can set preferences for using a WiFi network or a cellular network for particular applications. In another embodiment, the routing policy data is provisioned using an interface to a network device within a core network that supports the set of access networks available to the mobile device.

For example, an ANDSF client326within the OS framework layer314of the mobile device102can be provisioned324with network or operator routing policy over the S14 interface130to the Access Network Discovery and Selection Function server128of the Evolved Packet Core of a 3rdGeneration Partnership Project compliant network. In accordance with the 3GPP specifications, the ANDSF client326can be provisioned324by the ANDSF server128with ANDSF policies including Inter-APN Routing Policy (IARP) and/or Inter-System Routing Policy (ISRP). The IARP contains interface selection policies for selecting an IP interface to route packets among a choice of available IP interfaces in both 3GPP and non-3GPP access networks. The ISRP contains interface selection rules (similar to IARP) for traffic distribution for different types of traffic flows from different types of applications over different access networks for mobile devices that are configured for various features as defined in the 3GPP specifications. All these policies can be valid in any location and time or can be valid in a given location and/or for a given time.

In accordance with the described embodiment, a set of one or more routing policies of a plurality of routing policies provisioned in the mobile device102is selected404based on the selection criteria defined in 3GPP specifications to be an active routing policy330used by the mobile device102. The active routing policy330is the routing policy that the mobile device102applies, to the exclusion of other possible routing policies provisioned in the mobile device102, to control how packets are routed across the active network interfaces, for instance, during a particular time period and/or within a given location area. The active routing policy data330can be based on or selected from the network routing policy324, the user routing policy328, or both, which is provisioned in the mobile device102. In the 3GPP specifications for instance, ISRP rules have a number of validity conditions, e.g. time of day and location, that may be set and would, therefore, need to be met or satisfied in order for the mobile device102to select the ISRP as the active routing policy330. The ISRP rules also have a number of results, e.g., preferred access technology and restricted access technology for type of traffic, that the mobile device102should implement when a given ISRP rule is active in order to route this type of traffic in compliance to the ISRP rule. IAPR rules also have validity conditions, such as validity area and time of day, and associated results when an IARP rule is selected as the active routing policy.

Returning again to method400ofFIG. 4, the routing manager332of mobile device102creates406a set of one or more marking rules338based on the active routing policy330in the mobile device102. The routing manager332further creates408a set of one or more routing tables362corresponding to packet labeling indicated by the set of marking rules. Each routing table directs packets to a different one of the active network interfaces of a plurality of active network interfaces in the mobile device102.

A marking rule specifies or indicates a manner in which to mark or label a packet, wherein the labeling is used to facilitate selecting one of a plurality of active network interfaces in a mobile device for routing packets over a set of access networks available to the mobile device. A routing table lists a path, in this case a particular IP interface, for routing packets through the access network which supports the IP interface.

Where the routing layer is implemented as an IP layer in a Linux kernel, as shown inFIG. 3, the routing manager332can use commands and/or applications that are compatable with Linux to create the marking rules338and to create and enforce the routing tables362. In a particular embodiment, the routing manager332creates the set of marking rules338using an iptables command334to specify how to mark or label the packets that are, for instance, deemed by the mobile device102as requiring marking in accordance with the active routing policy330. Moreover, in this Linux implementation, the routing manager332configures the corresponding set of routing tables362using an ip route command336, which is part of a collection of utilities for controlling IP networking in Linux. However, any suitable applications, commands, and/or utilities can be used to create the marking rules338and corresponding routing tables362, based at least in part on the particular OS implementation in the mobile device102.

Turning back to the method400ofFIG. 4, a benefit of the present teachings is the ability to dynamically re-configure the routing layer316to enforce changes to the policy-based routing, which results, for instance, from an active network interface change416for the mobile device102and/or updates or changes412to the routing policy for the mobile device102. At410, the mobile device102monitors the conditions at412and416and where the mobile device102detects changes with respect to any one or more of these conditions, the mobile device102makes appropriate changes or updates, where needed, to the active routing policy at404, the marking rules at406, and/or the corresponding routing tables at408.

In an embodiment, condition416is satisfied: when a new active network interface is created because the mobile device102connects to a new access network (e.g., WLAN); and when the mobile device102creates a new VPN connection (e.g. a WLAN PDN or 3GPP PDN connection) over an already connected access network. Condition416is also satisfied when an active network interface is terminated. When416is satisfied, the mobile device102creates new marking rules and routing tables. The condition412is satisfied: when the mobile device enters an area (or time of day) in which some policy rules become valid and possibly others become invalid; when new network routing policy324is received by the ANDSF client326; or when new user routing policy322is configured based on user input. When412is satisfied, the mobile device102derives new active policy and creates new marking rules and routing tables.

For example, the mobile device102detects a change416in active network interfaces when the device102moves into or out of a coverage area for an access network and connects to or disconnects from this access network. One illustrative scenario is where a user is a passenger in an automobile and has cellular data coverage over the cellular network110using the link138. When the user arrives at a coffee shop, the mobile device102discovers and connects to a WiFi network104, which is provided by the coffee shop. This creates a direct WLAN350interface in the mobile device. Accompanying the creation of this new interface, the routing manager332might, in response to detecting the change in the active network interfaces, create406updated marking rules338based on the active routing policy330and also create408corresponding updated routing tables362based on the labeling indicated by the updated marking rules338.

Moreover, upon moving within the coverage area of the WiFi network104, the mobile device102could thereafter form one or more PDN connections over the WiFi network104and form one or more corresponding active network interfaces352, thereby satisfying condition416. For instance, the mobile device102can form a PDN connection to IMS in order to access IMS services over WiFi. In an alternative scenario, the mobile device102releases an existing PDN connection over the WiFi network104and deletes the accompanying active network interface352. In either scenario, the routing manager332might create406updated marking rules338based on the updated routing policy330and also create408corresponding updated routing tables362based on the labeling indicated by the updated marking rules338.

In another implementation scenario, the mobile device102periodically re-evaluates the provisioned ANDSF routing rules to determine when the active policy330must be updated. When, for example, the mobile device102enters a new location area, some routing rules may become valid and some other rules may become invalid. Thus, the mobile device102might detect a change in the routing policy provisioned in the mobile device102based on a change in its location and re-evaluate the routing policy data to select or determine updated active routing policy data. In an additional example use case, when the ANDSF server128provides new network routing policy324, the mobile device102determines an updated active policy330based on the new network routing policy324. Correspondingly, the routing manager332might create406updated marking rules338based on the updated routing policy and also create408corresponding updated routing tables362based on the labeling indicated by the updated marking rules338.

Turning again momentarily toFIG. 3, next described is a particular use case scenario wherein the mobile device102configures the routing layer316by creating marking rules338and corresponding routing tables362, in accordance with the present teachings using, for instance, the method400described above. During a given time frame and within a given location, the mobile device102has, as mentioned above, established: the connection for direct WLAN offload routing of packets through the WiFi access network104and the PDN connection using the IMS APN for routing packets to the IMS subsystem through the WiFi access network104and EPC; and the PDN connection using the MMS APN for routing packets corresponding to MMS messaging through the cellular access network110. The mobile device102has accordingly established the direct WLAN active network interface350and the WLAN PDN active network interface352corresponding to and associated with the link126, and a 3GPP PDN active network interface354corresponding to and associated with the link138.

With further regard to this use case scenario, the ANDSF server128has pushed to the ANDSF client326of the mobile device102an IARP that contains two rules: (1) a rule for APN routing, e.g., ForApn-1; and (2) a rule for non-seamless WLAN offload routing, e.g., ForNswo-1. The ForApn-1 rule indicates that traffic from an IMS client (e.g.,304) and traffic to port5060should be routed to the IP interface (the active network interface) corresponding to the IMS APN connection and should not be routed to the IP interface corresponding to an MMS APN. The ForNswo-1 rule indicates that traffic from a Skype application (e.g.,302) and traffic to port80or443should be routed to the IP interface corresponding to the direct WLAN connection.

Using its active policy selecting algorithm, the mobile device102selects the IARP containing the ForApn-1 and ForNswo-1 rules as the active routing policy330. To enforce this active routing policy, the routing manager332in the mobile device102creates a set of two marking rules, wherein each marking rule in the set of marking rules indicates a different marking value to serve as labeling for applying to packets. A marking value can be or can indicate any alpha-numeric value applied, added, and/or affixed to a packet. Where IP encapsulation is used, for example, the marking value indicates labeling that is other than an identifier for a particular endpoint. Accordingly, the marking value is not and does not indicate a particular IP address, destination address, port, MAC address, or any other addressing or destination identification mechanism from which an identity of a particular endpoint could be ascertained. Moreover, the marking value does not change the packet headers (e.g. the Transmission Control Protocol (TCP) or IP headers) and the payload information in the packet. It is only a value associated with the packet for as long as the packet remains in the routing layer316of the mobile device102.

For example, the mobile device102creates a first marking rule to enforce the ForNswo-1 rule, wherein the first marking rule specifies that packets generated by the Skype application302and packets to ports80and443are marked with a value of 1. Similarly, the mobile device102creates a second marking rule to enforce the ForApn-1 rule, wherein the second marking rule specifies that packets generated by the IMS client304and packets to port5060are marked with a value of 2. As can be seen with respect to this use case, at least some of the routing policy data provisioned in the mobile device102and used to create the set of marking rules indicates routing policy based on a type of application that generates the packets. This was not possible using prior art routing tables that facilitated routing based on destination address related encapsulation.

In connection with generating the marking rules338, the routing manager332of the mobile device102further creates a set of routing tables362that correspond to the labeling indicated by the set of marking rules338. Each routing table directs the mobile device to a different one of the active network interfaces of the plurality of network interfaces350,352, and354. In one example implementation, each routing table in the set of routing tables362indicates a single default route for a different one of the active network interfaces of the plurality of active network interfaces. A default route means that the packets to which the routing table is applied are sent to the same active network interface irrespective of the application(s) that generated the packets or the endpoint identification, e.g., destination address, or any other attribute of the packets. Moreover, in a further example implementation, each routing table in the set of routing tables362directs the mobile device to a different one of the active network interfaces of the plurality of active network interfaces based on a different one of the marking values indicated by the set of marking rules.

In this case, there are two marking rules in the set of marking rules. Accordingly, the mobile device102creates two routing tables342and344in the set of routing tables362. More particularly, since the first marking rule labels packets that should be routed to the IP interface corresponding to the direct WLAN connection using the link126, a routing table342is created that directs the packets labeled with the marking value 1 to the direct WLAN active network interface350as the default route for routing packets using the WiFi access network104. Similarly, since the second marking rule labels packets that should be routed to the IP interface corresponding to the IMS APN connection using the link126, a routing table344is created that directs the packets labeled with the marking value 2 to the WLAN PDN active network interface352as the default route for routing packets using the WiFi access network104.

In a further embodiment, the set of routing tables362are created in addition to one or more routing tables346used to route packets that are not labeled with a marking value or otherwise labeled by a marking rule. The routing table346could be configured to select an active network interface (e.g.350,352,354) based on the endpoint identification, such as by destination IP address and/or port number, affixed to the encapsulated IP packet. The routing table346is configured to route packets that do not match any of the routing rules in the active policy330. In most cases, this routing table selects an active interface to route a packet based on the destination IP address in this packet.

Turning now toFIG. 5, wherein is illustrated a method500that can be used to route packets from multiple applications, e.g.,302,304,306, to the appropriate active network interfaces, e.g.,350,352,354, in the mobile device102using the marking rules338and routing tables362configured in accordance with the present teachings, e.g., configured based on the ForApn-1 and ForNswo-1 rules. The method500is also described by reference to aspects ofFIG. 3. More particularly,FIG. 3shows the Skype application302generating packets308, the IMS client304generating packets310, and the application APP-3306generating packets312. The packet marking function340in the routing layer316of the mobile device102receives502the packets308,310, and312and accesses the marking rules338to determine504whether and how a particular packet should be marked.

In general, in determining504that a particular packet should be marked, the packet marking function340selects the appropriate marking rule and applies506the indicated labeling to the packet. Specifically, upon receiving the packets308from the Skype application302, the packet marking function340selects506the first marking rule, and applies the marking value 1 to the packets308. Similarly upon receiving the packets310from the IMS client304, the packet marking function340selects506the second marking rule, and applies the marking value 2 to the packets310. The marked packets308and310are passed to the policy-based routing function348. Where the packet marking function340determines504to route a packet, e.g., the packets312from the application306, without marking the packets using the marking rules, the unmarked packets312are simply passed through to the policy-based routing function348.

The policy-based routing function348, in general, selects508the appropriate routing table for a given packet, and routes510the packet using the active network interface indicated by the routing table. For packets that were labeled by the packet marking function340, the policy-based routing function348selects a routing table from the set of routing tables362based on the labeling applied to the packet and then routes the packet using the active network interface indicated by routing table. For unmarked packets, the policy-based routing function348routes the packets using a routing table not included within the set of routing tables362, which correspond to the marking rules338. For example, the policy-based routing function348routes the packets using the routing table346. Where the routing layer316is an IP layer in a Linux kernel, as illustrated inFIG. 3, the policy-based routing function348is configured with the ip route command to select the appropriate routing table for a packet based on the marking value of the packet, if the packet is marked, or to select an alternative routing table (e.g.346) if the packet is unmarked.

With respect to the particular use case scenario herein described, for packets that were labeled by the packet marking function340, the policy-based routing function348selects a routing table from the set of routing tables362based on the labeling applied to the packet and then routes the packet using the active network interface indicated by the selected routing table. Specifically, upon receiving the packets308from the Skype application302, the policy-based routing function348selects508the routing table342based on the marking value 1 applied to the packets308. The association or correspondency between the marking value 1 and the routing table342is indicated by the similar hashing and the number “1” within the packets308and the routing table342. The routing table342indicates to the policy-based routing function348to forward510the packets308labeled with the marking value 1 to the direct WLAN active network interface350for routing the packets308over the WiFi access network104using the link126.

Similarly, upon receiving the packets310from the IMS client304, the policy-based routing function348selects508the routing table344based on the marking value 2 applied to the packets310. The association or correspondency between the marking value 2 and the routing table344is indicated by the similar hashing and the number “2” within the packets310and the routing table344. The routing table344indicates to the policy-based routing function348to forward510the packets310labeled with the marking value 2 to the WLAN PDN active network interface352for routing the packets310over the WiFi access network104using the link126. Upon receiving the unmarked packets312from the application306, the policy-based routing function348selects508the routing table346and, responsively, forwards510the unmarked packets312to any active network interface based on the destination IP address in these packets. The routing table346is configured to route packets associated with MMS messaging (i.e. those with destination IP address the IP address of the MMS proxy) to the 3GPP PDN active network interface354over the 3GPP cellular access network110using the link138.

It will be appreciated that some embodiments may be comprised of one or more generic or specialized processors (or “processing devices”) such as microprocessors, digital signal processors, customized processors and field programmable gate arrays (FPGAs) and unique stored program instructions (including both software and firmware) that control the one or more processors to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions of the method and/or apparatus described herein. Alternatively, some or all functions could be implemented by a state machine that has no stored program instructions, or in one or more application specific integrated circuits (ASICs), in which each function or some combinations of certain of the functions are implemented as custom logic. Of course, a combination of the two approaches could be used. Both the state machine and ASIC are considered herein as a “processing device” for purposes of the foregoing discussion and claim language.