The Access Network Discovery and Selection Function (ANDSF) framework was introduced first in 3GPP Release 8 to standardize operator policy mechanism and since then it has evolved in the standard to provide further enhancements like flow mobility and more specific traffic identification.
3GPP Release 8
In Release 8, the ANDSF framework provides access network information; for instance, leveraging Wi-Fi Access Points in the vicinity of the UE location, to enhance the way the UE discovers new non-3GPP Access Networks. It also provides mobility policies in order for the operator to guide the UE to select the proper radio technology in any given location at any given time. Release 8 does not allow simultaneous connections to multiple access networks. For this reason, the Inter System Mobility Policies (ISMPs) were defined independent of the traffic sent by the UE. For example, when a device discovers the presence of Wi-Fi, all the traffic must be offloaded to Wi-Fi or all the traffic must stay on 3G, regardless of what type of traffic is being generated by the applications running on the device.
3GPP Release 10
In Release 10, simultaneous network connections to multiple radio access technologies were enabled by Multi Access PDN Connectivity (MAPCON), IP Flow Mobility (IFOM) and non- seamless Wi-Fi offload. To take this into account, the ANDSF framework has been enhanced with the introduction of Inter System Routing Policies (ISRP), allowing the operator to provide policies based on the traffic exchanged by the UE.
In this way the operator can indicate preferred or forbidden radio access technologies as a function of the type of traffic the UE sends. Specifically an ISRP can be based on:
- the PDN identifier (i.e. Access Point Name or APN) the UE uses for a given connection,
- the destination IP address the UE sends traffic to,
- the destination port number the UE connects to, or
- a combination of the above three elements.
Inter System Routing Policies (ISRP) Example
The example shows how an operator policy can be as simple as policy #1 where it is only checking the destination port to determine if traffic should only be allowed on 3GPP – for example, VoIP data traffic. And the same framework allows an operator to define a more complicated policy such as policy #5 where two parameters – the Access Point Name (APN) and the Destination Port can be combined in a logical AND function to come up with a custom policy.
In recent years a clear trend of aggregation of the Internet traffic into few transport ports has emerged. Fewer and fewer ports carry most of the Internet traffic and in particular a very large amount of the Internet traffic is carried over port 80 (HTTP). Recent data shows that more than 50% of the total Internet traffic is carried over port 80 of various types such as web browsing, video streaming, email, and application data.
These trends impact the 3GPP Release 10 ANDSF and ISRP framework discussed in the previous section. For example, the operator with the current framework is not able to discriminate between video streaming (e.g., www.youtube.com) and web browsing (e.g., www.google.com). As another example, the operator will not be able to set different policies for different applications downloaded by a mobile device from an application store unless they are designed to use different port numbers.
3GPP Release 11
Given the limitations analyzed in the previous section, there is a need to more clearly identify the traffic to which a given ISRP applies. Operators can benefit significantly if they can identify a subset of traffic which has specific characteristics (e.g., video streaming) but shares the same port number characteristics of other types of traffic (e.g., port 80 for HTTP traffic).
Some ways of identifying traffic independent of destination IP and port are:
- IP flow throughput. All IP flows that generate more than a given throughput threshold (e.g., 1 Mbps) should be handled in a certain way (e.g., Wi-Fi preferred).
- File size. In some situations a file download is anticipated by a protocol where the file size of the download is provided by the server to the client. FTP is an example of this case, but some podcast synchronization applications which run over HTTP have this property as well. In this case, it could be possible for the operator to guide the UE to download (or upload) large files only in a given network or location.
- Application name or identifier. The name or an identifier of the application which generates a given IP flow can be used to identify the traffic. This cannot be a general solution which applies to all applications but can be used by well-known applications or operator-provided applications (e.g., an audio streaming application which is pre-loaded in an operator phone).
- Role identifier. Similarly, an abstraction of the characteristics of the application could be used. We refer to it as the “role” of the application and can be, for example “VoIP,” “Video Streaming,” etc. This role can be either inferred by the entity in the UE which enforces the routing decision or can be provided via an API by the application.
- FQDN. Instead of using the destination IP address, the destination FQDN can be used. This would allow a simpler configuration and would allow having a common set of policies even in case there are a set of distributed web servers (CDNs).
References
- 3GPP TS 23.261 v10.1.0 (2010-09), “IP flow mobility and seamless Wireless Local Area Network (WLAN) offload; Stage 2”.
- 3GPP TR 23.855 v0.1.0 (2011-04), “Data identification in ANDSF”.
- 3GPP TS 24.312 v10.2.1 (2011-04), “Access Network Discovery and Selection Function (ANDSF) Management Object (MO)”.
- 3GPP TS 23.402 v10.3.0 (2011-03), “Architecture enhancements for non-3GPP accesses”.