WO2012149954A1

WO2012149954A1 - Traffic offload in communication networks

Info

Publication number: WO2012149954A1
Application number: PCT/EP2011/056987
Authority: WO
Inventors: Janne Petteri Tervonen
Original assignee: Nokia Siemens Networks Oy
Priority date: 2011-05-03
Filing date: 2011-05-03
Publication date: 2012-11-08

Abstract

A method, apparatuses and a computer-readable medium are provided for traffic steering in a communication network, the method comprising receiving at a first network element a traffic steering instruction from a second network element and activating the traffic steering instruction, wherein the traffic steering instruction is created by the second network element based on at least one identified application and wherein the application is identified based on the traffic created by the application.

Description

Title Traffic offload in communication networks FIELD OF THE INVENTION

The present invention relates to traffic offload in

communication systems. In particular, the present invention relates to a method, apparatuses and a computer program product for offloading traffic between a cellular radio access network and a wireless local area network. BACKGROUND ART

3^rd Generation Partnership Project (3GPP) has developed standards for cellular mobile telecommunication systems evolving from Global System for Mobile communication (GSM) and its packet data enhancements like General Packet Radio Service (GPRS) . For example, 3GPP has provided technical specifications and reports defining 3^rd generation (3G) cellular telecommunication system called Universal Mobile Telecommunications System (UMTS) , comprising UMTS terrestrial radio access network (UTRAN) or High-Speed Packet Access

(HSPA) and UMTS core network, and 4G telecommunication system called Evolved Packet System (EPS) , comprising Long Term Evolution (LTE) radio network and Evolved Packet Core (EPC) . In a UMTS network the data session is established with a Packet Data Protocol (PDP) Context Activation procedure.

Before the PDP context can be established the UE must do an Attach procedure. The Attach procedure is used to alert the Serving GPRS Support Node (SGSN) that the UE has powered up. After the Attach procedure is completed, the UE does a

Primary PDP Context that will establish the data session and allocate an IP address to the UE . This PDP Context will have a Quality of Service (QoS) associated with it based on the needs in the request. If the UE needs to have multiple data sessions, due to various QoS, the UE will do a Secondary PDP Context activation. In a LTE based system, there are two types of data session setups. The first is called a Default EPS Bearer. The second is the Dedicated EPS Bearer. The first is established as part of the Attach procedure. The Default EPS Bearer will only support a nominal QoS, but that should be sufficient for application signaling. When the UE needs to establish a service a Dedicated EPS Bearer will be established. This will have the QoS requirements needed for the service.

The LTE Attach/Default EPS Bearer is similar to the UMTS Attach and a Primary PDP Context establishment procedure. The Secondary PDP Context Activation is similar to the Dedicated EPS Bearer Setup procedure. The key parameters in these messages are an Access Point Name (APN) , IP address type, and QoS parameters. The APN identifies an IP Packet Data Network (PDN) that a mobile data user wants to communicate with. In addition to identifying a PDN, an APN may also be used to define the type of service, (e.g. connection to wireless application protocol (WAP) server, multimedia messaging service (MMS) ) , that is provided by the PDN.

Wireless Local Area Network, also known as WLAN or Wi-Fi, is an alternative to cabled LAN specified in the IEEE 802.11 group of standards. It provides users mobility to move from one location to another without thinking about the wires. It has grown in popularity along with the rise of laptop

computers and smartphones that made mobile computing within reach for most people. WLAN provides a connection through an Access Point (AP) to the wider internet or to other networks. The basic service set (BSS) is a set of all stations that can communicate with each other. Each BSS has an ID called a BSS Service Set Identifier (SSID) . SSID is a 32-character unique identifier attached to the header of packets sent over a WLAN and acts as a password when a mobile device tries to connect to the BSS. The SSID differentiates one WLAN from another, so all access points and all devices attempting to connect to a specific WLAN must use the same SSID. A device will not be permitted to join the BSS unless it can provide the unique SSID. Because an SSID can be sniffed in plain text from a packet it does not supply any security to the network. An SSID is also referred to as a network name because

essentially it is a name that identifies a wireless network. Both technologies, WLAN and 3GPP networks are developing to enable more bandwidth and faster data rates for the end users and represent in many areas complementary solutions. Due to the recent high traffic growth experienced in cellular networks, any solution to increase the capacity of the networks is desirable. One possible solution is wireless local area network (WLAN) offload. In WLAN offload, traffic is routed via WLAN instead of mobile telecommunication networks, e.g. 3^rd generation partnership project (3GPP) networks like UMTS or EPS There are two different kinds of WLAN offload scenarios available from the 3GPP point of view:

1) WLAN radio access is used to offload traffic from 3GPP radio access networks, e.g. from LTE/UTRAN to WLAN. From WLAN network, the traffic is routed to 3GPP operator core network, e.g. to evolved packet core (EPC) /UMTS core.

2) WLAN radio access is used to offload traffic from 3GPP radio access networks, e.g. from LTE/UTRAN to WLAN, and from WLAN network the traffic is routed directly to the internet (EPC/UMTS core bypassed) .

The cooperation between 3GPP and WLAN networks enables additional radio capacity for 3GPP networks and on the other hand common usage of existing 3GPP core architecture, when desired. 3GPP has standardised interworking between non-3GPP access networks (e.g. WLAN) and 3GPP networks, e.g. in specifications TS 23.234 vlO.0.0 and TS 23.402 vl0.3.0. One requirement for integrating 3GPP and WLAN networks is to have a dual-mode UE which has the capability of accessing networks of both technologies. When a mobile station is covered by both networks in the integrated WLAN/3GPP systems, the access control problem arises to decide which network it should be admitted to and when it should switch from one network to the other through vertical handover. To allow an operator to influence on WLAN offload, the network selection rules - often called network selection policies - need to be transferred from the network to the terminals. For this, 3GPP has defined an Access Network Discovery and Selection

Function (ANDSF) server. Similar work is also under way in internet engineering task force (IETF), where the solutions are based on existing server notifications, e.g. dynamic host configuration protocol (DHCP) options.

SUMMARY

It is therefore an object of this invention to address some of the above mentioned problems by providing a method, apparatuses and a computer program product for traffic offload .

According to a first aspect of the invention, there is provided a method for traffic steering in a communication network comprising receiving at a first network element a traffic steering instruction (e.g. a traffic steering policy) from a second network element and activating the traffic steering instruction, wherein the traffic steering

instruction is created by the second network element based on at least one identified application and wherein each of the at least one application is identified based on the traffic created by the application. In the method, the at least one application may be identified during network planning. The identification may be based on historical data. In some embodiments, the at least one application may be identified dynamically based on real-time traffic analyzing, for example using Deep Packet Inspection or Policy and Charging Control mechanisms.

In the method, the traffic steering instruction may comprise an instruction to forward traffic of an application to a first access network. The first access network may comprise e.g. a cellular network or a wireless local area network. The wireless local area network may comprise e.g. a wireless local area network identified with service set identifier or an unspecified wireless local area network. The cellular network may comprise e.g. a 3rd generation partnership project radio access network.

In the method, each of the at least one application may be identified based on the traffic created by the application, e.g. by total amount of transferred data of the application during a specific timeframe, amount of transferred data of the application with relation to available resources, or amount of signalling data created by the application.

In the method, the traffic steering instruction may comprise at least one rule for offloading traffic from a cellular network to a wireless local area network. In some

embodiments, traffic may be routed via wireless local area network to mobile core network. In some embodiments, traffic may be routed via wireless local area network to internet.

In the method, the traffic steering instruction may comprise at least one rule for offloading traffic from a wireless local area network to a cellular network.

In the method, the cellular network may comprise a 3rd generation partnership project radio access network. In the method, the second network element may comprise a decision engine (100) or a decision engine functionality located in any network element. In the method, the first network element may comprise a policy and charging rules function. The activating may comprise providing the traffic steering instruction to a policy and charging enforcement function. The activating may further comprise providing the traffic steering instruction to a policy and charging enforcement function as a policy and charging control rule or as a part of a policy and charging control rule. In some embodiments, the policy and charging enforcement function may be located in a user plane gateway. In some embodiments the activating may comprise providing the traffic steering instruction to a policy and charging

enforcement function to be taken into use by modifying packet forwarding or routing decisions of the user plane gateway (wherein the policy and charging enforcement function may be located) or by modifying content of at least one routing advertisement to be sent to a host or to a terminal.

In the method, the first network element may comprise an information server. The information server may comprise an access network discovery and selection function. The

activating may comprise providing policy information to a terminal. The policy information may comprise the received traffic steering instruction. In some embodiments, the providing may comprise providing policy information in a dynamic host configuration protocol message, in a router advertisement message, or in an access network discovery and selection function management object.

According to a second aspect of the invention, there is provided an apparatus in a communication network comprising an input (or some other receiving means) configured to receive information on at least one identified application, a processor (or some other processing means) configured to create a traffic steering instruction (e.g. a traffic

steering policy) , and an output (or some other sending means) configured to send the traffic steering instruction to a first network element in the communication network, wherein the traffic steering instruction is created based on the received information on the at least one identified

application and wherein the at least one application is identified based on the traffic created by the application. According to some embodiments, the traffic steering

instruction may comprise an instruction to forward traffic of an application to a first access network. The first access network may comprise e.g. a cellular network or a wireless local area network. The wireless local area network may comprise e.g. a wireless local area network identified with service set identifier or an unspecified wireless local area network. The cellular network may comprise e.g. a 3rd

generation partnership project radio access network. According to some embodiments, the information on at least one identified application may comprise at least one of: a source IP address, a source IP address range, a destination IP address, a destination IP address range, a source port, a destination port, a transport protocol, and type of service.

According to some embodiments, each of the at least one application may be identified based on the traffic created by the application, e.g. by total amount of transferred data of the application during a specific timeframe, amount of transferred data of the application with relation to

available resources, or amount of signalling data created by the application.

According to some embodiments, the traffic steering

instruction may comprise at least one rule for offloading traffic from a cellular network to a wireless local area network. In some embodiments, traffic may be routed via wireless local area network to mobile core network. In some embodiments, traffic may be routed via wireless local area network to internet.

According to some embodiments, the traffic steering

instruction may comprise at least one rule for offloading traffic from a wireless local area network to a cellular network .

According to some embodiments, the cellular network may comprise a 3rd generation partnership project radio access network .

According to some embodiments, the first network element may comprise a policy and charging rules function or an

information server.

According to some embodiments, the apparatus may comprise a decision engine or a decision engine functionality located in any network element.

According to a third aspect of the invention, there is provided an apparatus in a communication network comprising an input (or some other receiving means) configured to receive a traffic steering instruction (e.g. a traffic steering policy) from a second network element in the

communication network, and a processor (or some other

processing means) configured to activate the received traffic steering instruction, wherein the received traffic steering instruction comprises an instruction for forwarding traffic of an application to a first access network.

The first access network may comprise e.g. a cellular network or a wireless local area network. The wireless local area network may comprise e.g. a wireless local area network identified with service set identifier or an unspecified wireless local area network. The cellular network may

comprise e.g. a 3GPP radio access network.

According to some embodiments, the traffic steering

According to some embodiments, the apparatus may comprise a policy and charging rules function.

According to some embodiments, the apparatus may further comprise an output configured to provide policy information to a policy and charging enforcement function and wherein the processor may be further configured to activate the received traffic steering instruction by providing the traffic

steering instruction to a policy and charging enforcement function. In some embodiments, the traffic steering

instruction may be provided to a policy and charging

enforcement function as a policy and charging control rule or as a part of a policy and charging control rule. In some embodiments, the policy and charging enforcement function may be located in a user plane gateway. In some embodiments, the traffic steering instruction may be provided to a policy and charging enforcement function to be taken into use by

modifying packet forwarding or routing decisions of the user plane gateway (wherein the policy and charging enforcement function may be located) or by modifying content of at least one routing advertisement to be sent to a host or to a terminal .

According to some embodiments, the apparatus may comprise an information server and the information server may comprise an access network discovery and selection function. In some embodiments, the apparatus may further comprise an output (or some other sending means) configured to provide policy information to a terminal and wherein the processor may be further configured to activate the received traffic steering instruction by causing the output to provide the policy information to a terminal.

According to some embodiments, the policy information may comprise the received traffic steering instruction. In some embodiments, the policy information may be provided in a dynamic host configuration protocol message, in a router advertisement message, or in an access network discovery and selection function management object. According to some embodiments, the second network element may comprise a decision engine or a decision engine functionality located in any network element.

According to a fourth aspect of the invention, there is provided a mobile terminal comprising an input (or some other receiving means) configured to receive a traffic steering instruction (e.g. a traffic steering policy) from an

information server, and a processor (or some other processing means) configured to change behaviour of the mobile terminal based on the received traffic steering instruction, wherein the received traffic steering instruction comprises an instruction for forwarding traffic of an application to a first access network. The first access network may comprise e.g. a cellular network or a wireless local area network. The wireless local area network may comprise e.g. a wireless local area network identified with service set identifier or an unspecified wireless local area network. The cellular network may

comprise e.g. a 3GPP radio access network.

In some embodiments, the traffic steering instruction may be received in a dynamic host configuration protocol message, in a router advertisement message, or in an access network discovery and selection function management object.

According to some embodiments, the traffic steering

instruction may comprise at least one rule for offloading traffic from a wireless local area network to a cellular network.

According to some embodiments, the processor (or some other processing means) may be further configured to change

behaviour of the mobile terminal by forwarding certain application data over the wireless local area network instead of the cellular network.

behaviour of the mobile terminal by forwarding certain application data over the cellular network instead of the wireless local area network.

According to a fifth aspect of the invention, there is provided a computer-readable medium encoded with instructions that, when executed in hardware, perform a process, the process comprising receiving at a first network element a traffic steering instruction (e.g. a traffic steering policy) from a second network element and activating the traffic steering instruction, wherein the received traffic steering instruction comprises an instruction for forwarding traffic of an application to a first access network. The first access network may comprise e.g. a cellular network or a wireless local area network. The wireless local area network may comprise e.g. a wireless local area network identified with service set identifier or an unspecified wireless local area network. The cellular network may

comprise e.g. a 3GPP radio access network.

In the process, the at least one application may be

identified during network planning and the identification may be based on historical data. In some embodiments, the at least one application may be identified dynamically based on real-time traffic analyzing, for example using Deep Packet Inspection or Policy and Charging Control mechanisms.

In the process, the traffic steering instruction may comprise at least one rule for offloading traffic from a cellular network to a wireless local area network. In some

In the process, the traffic steering instruction may comprise at least one rule for offloading traffic from a wireless local area network to a cellular network. In the process, the cellular network may comprise a 3rd generation partnership project radio access network. The second network element may comprise a decision engine or a decision engine functionality located in any network element. In the process, the first network element may comprise a policy and charging rules function. The activating may comprise providing the traffic steering instruction to a policy and charging enforcement function. The activating may further comprise providing the traffic steering instruction to a policy and charging enforcement function as a policy and charging control rule or as a part of a policy and charging control rule. In some embodiments, the policy and charging enforcement function may be located in a user plane gateway. In some embodiments the activating may comprise providing the traffic steering instruction to a policy and charging

enforcement function to be taken into use by modifying packet forwarding or routing decisions of the user plane gateway or by modifying content of at least one routing advertisement to be sent to a host or to a terminal.

In the process, the first network element may comprise an information server. The information server may comprise an access network discovery and selection function. The

activating may comprise providing policy information to a terminal. The policy information may comprise the received traffic steering instruction. In some embodiments, the providing may comprise providing the information in a dynamic host configuration protocol message, in a router

advertisement message, or in an access network discovery and selection function management object.

Embodiments of the present invention may have one or more of following advantages:

a simple method for traffic offload from a mobile telecommunication network to a wireless local area network

easy implementation with small changes to the existing standardized procedures

no need for heavy traffic analyzing mechanisms

only a small amount of traffic needed to be

transferred between information servers and terminals BRIEF DESCRIPTION OF DRAWINGS Figure 1 illustrates a reference architecture for a multi^¬ access 4G system according to 3GPP specifications.

Figure 2 illustrates an architecture according to some exemplary embodiments of the present invention.

Figure 3 illustrates a method according to some exemplary embodiments of the invention. Figure 4 illustrates a further method according to some exemplary embodiments of the invention.

Figure 5 illustrates a further method according to some exemplary embodiments of the invention.

Figure 6 illustrates yet a further method according to some exemplary embodiments of the invention.

Figure 7 illustrates a decision engine according to some exemplary embodiments of the invention.

Figure 8 illustrates a first network element according to some exemplary embodiments of the invention. Figure 9 illustrates an information server according to some exemplary embodiments of the invention.

Figure 10 illustrates a Policy and Charging Rules Function according to some exemplary embodiments of the invention.

Figure 11 illustrates a terminal according to some exemplary embodiments of the invention.

Figure 12 illustrates a Policy and Charging Enforcement Function according to some exemplary embodiments of the invention . DETAILED DESCRIPTION OF SOME EMBODIMENTS

3GPP has defined a reference architecture for a multi-access 4G 3GPP system where heterogeneous access systems (e.g. 3GPP, 3GPP2, WiMax, WLAN) are connected to a common core network (in this case EPC) , which is specified e.g. in TS 23.402 vl0.3.0, section 4.2.2 and in the present Figure 1. In the figure, non-3GPP Access Networks are IP access networks that use access technology whose specification is out of the scope of 3GPP, e.g. WLAN networks, as in the present invention.

There are two logical gateways (GW) presented: a serving GW (S-GW) and a packet data network GW (PDN-GW) , which may be implemented in one physical node or separated physical nodes. The S-GW routes and forwards user data packets, manages and stores UE contexts, e.g. parameters of the IP bearer service, network internal routing information and also performs replication of the user traffic in case of lawful

interception. The PDN-GW provides connectivity to the UE to external packet data networks (PDN) via SGi interface by being the point of exit and entry of traffic for the UE . A UE may have simultaneous connectivity with more than one PDN-GW for accessing multiple PDNs . The PDN-GW performs policy enforcement, packet filtering for each user, charging

support, lawful interception and packet screening. Another key role of the PDN-GW is to act as the anchor for mobility between 3GPP and non-3GPP technologies. Between the S-GW and PDN-GW, there is a S5 reference point providing user plane tunneling and tunnel management. S5 can support both General Tunneling Protocol (GTP) and Proxy Mobile IPv6 (ΡΜΙΡνβ) protocols .

EPC distinguishes between "trusted" and "untrusted" non-3GPP accesses and it is up to the operator to decide if a non-3GPP access is trusted or untrusted. The decision is not based just on the access network technology but may depend also on business considerations. Interworking with an untrusted access is performed via an evolved packet data gateway (ePDG) , which is similar to a virtual private network (VPN) concentrator: The UE has to establish an IP security (IPsec) tunnel with the ePDG to access operator's services. The ePDG may also implement IP mobility protocols. S2b reference point provides the user plane with related control and mobility support between the ePDG and the P-GW, including support for Proxy Mobile IPv6 (ΡΜΙΡνδ) mobility protocol.

In case of a trusted non-3GPP access, the UE does not need to establish an IPsec tunnel with the ePDG in advance but mobility protocols can be used directly between the non-3GPP access network and the EPC core network. S2a reference point provides the user plane with related control and mobility support between trusted non-3GPP IP access and the P-GW, including support for Proxy Mobile IPv6 (ΡΜΙΡνδ) and Mobile IPv4 (MIPv4) mobility protocols. In this case, the non-3GPP access gateway can run the protocols.

The Policy and Charging Control (PCC) function, specified e.g. in 3GPP TS 23.203 vll.1.0, applies operator's policy, QoS and charging control to any kind of 3GPP IP connectivity access network (IP-CAN) and to non-3GPP access system

connected via EPC complying with 3GPP specifications. Policy control means the process whereby the Policy and Charging Rules Function (PCRF) indicates to the Policy and Charging Enforcement Function (PCEF) how to control the IP CAN bearer. Policy control includes QoS control and/or gating control. PCC rule is a set of information enabling the detection of a service data flow and providing parameters for policy control and/or charging control. The Gx reference point enables the PCRF to have dynamic control over the PCC behavior at a PCEF. The PCEF enforces the policy control indicated by PCRF and is often located in PDN-GW. If located in S-GW, it may be denoted by the Bearer Binding and Event Reporting Function (BBERF) . The PCC system uses IETF defined Diameter protocol and especially Credit Control application for signaling. From release-8 onwards, EPS provides an ANDSF as a supplementary function. The purpose of the ANDSF is to assist UE to discover non-3GPP access networks - such as WLAN or Worldwide Interoperability for Microwave Access (WiMAX) - that can be used for data communications in addition to 3GPP access networks (such as High Speed Packet Access (HSPA) or LTE) and to provide the UE with rules policing the connection to these networks. ANDSF provides the UE with three sets of information: inter-system mobility policies, inter-system routing policies, and access network discovery information. With WLAN offload, one problem is to identify which traffic should be offloaded (i.e. routed via WLAN) . From a network operator point of view, the optimum solution is to be able to identify the traffic that should be offloaded and the traffic that should not be offloaded. For example, the operator voice traffic is something that may be best not to offload, but the bulk internet traffic it may be ok to offload via WLAN. The aim within standardization bodies has been to define a mechanism that is able to tackle all kinds of traffic at the same time. However, this kind of full blown solution may be difficult to specify and expensive to implement and run. In the present invention, a light-weight mechanism for traffic steering for WLAN offload is proposed. Instead of identifying all the traffic going through the operator networks, the invented mechanism concentrates on the few applications creating a major amount or most of the traffic. The

identification of these applications may be based on the measurement of the traffic created by the applications.

The measurement of the traffic created by an application may be based for example on the total amount of transferred data during a specific timeframe, e.g. during a month, a day, or an operator defined busy hour. It may also be based on the amount of transferred data with relation to available

resources, for example available resources on uplink (i.e. radio resources), available resources on downlink (i.e. radio resources), available transmission capacity (e.g. between a base station and a core network gateway) , available capacity in a gateway, or available APN routing capacity (e.g.

operator' s APN "internet" and the corresponding GWs behind that APN name is/are overloaded; this could be a trigger for WLAN offload policy evaluation) . Further, the measurement of the traffic created by an application may be based on the amount of signalling data created by an application: It is possible to use WLAN offload also for applications that create a lot of signalling load (consecutive PDP context setup and tear down) even if the actual amount of transferred data is not significant for an application (e.g. applications with presence information that need to updated regularly) Figure 2 shows an architecture according to some exemplary embodiments of the present invention, wherein procedures for offloading traffic from a first network (e.g. cellular radio network) to a second network (e.g. WLAN) may be performed. Only functional entities necessary for understanding the invention are shown in the figure. A decision engine 100 may be capable of connecting both to an ANDSF 200 and a PCRF 300. The ANDSF 200 may connect to user equipment (UE) or terminals 400 directly or via base stations or gateways. In the method according to some exemplary embodiments of the present invention, as illustrated in Figure 3, the operator identifies only few (or a few) most heavily used applications in its network (s), as described above. At least one

application may be identified (step SO) based on the traffic created by the application, or on the network resource usage of the application. The identification may be done during network planning e.g. based on historical data or it may be done dynamically e.g. based on real-time traffic analyzing. For example, existing policy and charging control (PCC) or Deep Packet Inspection (DPI) mechanisms may be used.

DPI means an act of any packet network element, which is not an endpoint of a communication, using non-header content (typically the actual payload) for some purpose. This is performed as the packet passes an inspection point, searching for protocol non-compliance, viruses, spam, intrusions or predefined criteria to decide what actions to take on the packet, including collecting statistical information. DPI (and filtering) enables advanced network management, user service, and security functions. Depending on the network, DPI functionality may reside in a gateway, e.g. in a PDN-GW in case of 4G or in a GGSN in case of 3G, or it may be a standalone server having a DPI functionality. There may be an interface between the DPI functionality and a decision engine (see below) .

If PCC mechanism is used for the identification, PCEF, located e.g. in a PDN-GW or an ePDG, may report the results of the identification to policy and charging rules function (PCRF) which is further connected to a decision engine 100 (see below), i.e. there may be an interface between PCRF and the decision engine 100.

In its simplest form, the application identification may be done with a destination IP address (or an IP address range) only. For example, if a lot of traffic is generated to/from a certain IP address (or to a certain IP address range) , it may be enough to identify this IP address (or IP address range) . For example, if a specific video service is the source of major share of network traffic, the mechanism may just store the address/addresses used with this service. Depending on the situation, the used protocol, source and/or destination ports, or a so called 5-tuple (including source & destination IP address, source & destination ports, type of service) may act as a basis for the application identification. Further, currently many applications use hypertext transfer protocol (HTTP) as a transport protocol (with port 80), thus the destination address may be the only available mechanism to identify an application with certain services. A decision engine 100 may receive (step SI) information on the identified application ( s ) via an interface between the entity (e.g. DPI) and the decision engine 100. The way how the applications are identified in this interface may be agreed with those two entities: for example, the applications may be identified with 5-tuples as described above, or some other mechanisms may be defined on this particular interface, e.g. defining specific identifiers for the most common applications or application classes (e.g. application ID = YouTube, or application class = VoIP, etc.) In principle, this interface may contain information how much resources (radio, gateway or transmission, etc.) an application uses and what application it is. The decision engine 100 may translate (step S2) the

information into traffic steering policies. The policies may comprise rule(s) for offloading traffic from a first network to a second network, e.g. from a cellular network like 3GPP radio access network to a WLAN network and/or to bypass the mobile core network (e.g. 3GPP core network) directly to internet .

The decision engine 100 may forward (step S3) the formulated traffic steering policies to other network elements that may then take the traffic steering policies into use (step S4) . These network elements may comprise for example a PCRF300, and/or information servers 200 (e.g. ANDSF server) that provide the traffic steering policies to the terminals 400. In the case of PCRF 300, the PCRF 300 may provide the

received traffic steering policies to the PCEF 500 (step

S4A) , i.e. to a user plane gateway (e.g. PDN-GW, or in GGSN in case of 3G) to be taken into use. The user plane gateway may modify its behaviour (packet forwarding, routing

decisions, etc.) accordingly or it may deliver the policies to hosts or terminals e.g. by modifying content of at least one routing advertisement. In the case of information servers 200, the information server 200 may provide (step S4B) corresponding policy information to terminals 400. According to an embodiment, as illustrated in Figures 4 and 5, the information server 200 may receive (step S21) at least one traffic steering policy from the decision engine 100 and activate (step S22) the policy. The activating may comprise providing policy information to terminal (s) 400. The terminal 400 may receive (step S41) a traffic steering policy from the information server 200 and change (step S42) its behaviour based on the traffic steering policy e.g. by forwarding certain application data over a wireless local area network instead of a cellular network. For example, a new received traffic steering policy may indicate that certain application data will be forwarded over a certain WLAN network identified with service set identifier (SSID) , while some other

application data will be forwarded to any unspecified WLAN network and yet another application data will be forwarded to a 3GPP radio access network (e.g. internet high-speed packet access (IHSPA), long-term evolution (LTE) , home evolved node B (eNB) ) . In this way, the access networks that the

operator's subscribers are using can be influenced

dynamically, based on e.g. a new load situation or used applications on the operator networks .

Several mechanisms are available for carrying the traffic steering policies from the network information server 200 to terminals 400. In IETF, there are ongoing activities to define how such information may be transferred, e.g. with DHCP options or within Router Advertisement messages. 3GPP solution is based on the use of an ANDSF 200. ANDSF 200 may provide three kinds of information: Inter-System Mobility Policies (ISMP), Network Discovery Information and Inter- System Routing Policies (ISRP) . ISRP can be used to provision application specific routing rules, i.e. traffic steering policies. It has been defined that ANDSF 200 uses Open Mobile Alliance Device Management (OMA DM) framework for ANDSF information representation and information exchange. In the method of the present invention, e.g. the ANDSF Management Object (MO) may be used, which is specified in 3GPP TS

24.312, section 4 (rel-10, vlO.1.0 (2010-12)).

According to an exemplary embodiment, as illustrated in

Figure 6, the PCRF 300 may receive S31 at least one traffic steering policy from the decision engine 100 and activate S32 the policy. The activating may comprise providing the policy to the PCEF 500, i.e. to a user plane gateway, as a PCC rule or as a part of a PCC to be taken into use e.g. by modifying packet forwarding or routing decisions or providing the policies to hosts or terminals e.g. by modifying content of at least one routing advertisement. The activating may also comprise using Wi-Fi Alliance specified methods (e.g. HotSpot 2.0) to deliver the policies to hosts or terminals.

The decision engine 100 may be a software or a hardware and it may reside basically anywhere in the network, e.g. within the network operations and maintenance functionality, as a part of the PCC structure, it may reside in some GW (e.g. PDN GW) or it may be a standalone server. Further, the decision engine 100 may have interface (s) to provide the modified traffic steering policies to the affected network elements. In addition, if ANDSF 200 is used, the decision engine may have an interface to ANDSF 200 to modify the ANDSF 200 policies. If the decision engine resides within a gateway, an interface between the decision engine 100 and a router sending RAs, and/or between the decision engine 100 and a DHCP server may be implemented, or an existing management interface (s) may be used for that. If PCC is used, similar modifications may be applied to support the modified decision engine policies also in PCRF.

The decision engine 100, as illustrated in Figure 7, may comprise a processor 102 configured to create at least one traffic steering policy and an output 103 configured to send the traffic steering policy to the information server 200 or to a PCRF 300 in the communication network. The decision engine 100 may further comprise an input 101 configured to receive information on the identified application ( s ) from a network element.

The information server 200, as illustrated in Figure 8 and 9, may comprise an input 201 configured to receive at least one traffic steering policy from the decision engine 100 and a processor 202 configured to activate the traffic steering policy. The information server 200 may further comprise an output 203 configured to provide policy information to a terminal 400.

The PCRF 300, as illustrated in Figure 8 and 10, may comprise an input 301 configured to receive at least one traffic steering policy from the decision engine 100 and a processor 302 configured to activate the traffic steering policy. It may further comprise an output 303 configured to provide said policy to the PCEF 500 as a PCC rule or as a part of a PCC rule . The terminal 400, as illustrated in Figure 11, may comprise an input 401 configured to receive at least one traffic steering policy from the information server 300 and a

processor 402 configured to change behaviour of the mobile terminal 400 based on the traffic steering policy.

The PCEF 500, as illustrated in Figure 12, may comprise an input 501 configured to receive at least one traffic steering policy from the PCRF 300 as a PCC rule or as a part of a PCC rule, and a processor 502 configured to enforce the traffic steering policy. It may further comprise an output 503 configured to deliver the policies to hosts or terminals 400.

The processor 102, 202, 302, 402, 502 may comprise a central processing unit (CPU) or any other means for processing. The input 101, 201, 301, 401, 501 may comprise a receiver or any other means for receiving. The output 103, 203, 303, 503 may comprise a transceiver or any other means for transmitting. The processor 102, 202, 302, 402, 502 the input 101, 201, 501 and output 103, 203, 303, 503 may exchange information over an internal interface of the corresponding apparatus 100, 200, 300, 400, 500. The input 101, 201, 301, 401, 501 and the output 103, 203, 303, 503 of the apparatus 100, 200, 300, 400, 500 may be functionalities running on the processor 102, 202, 302, 402, 502 of the apparatus 100, 200, 300, 400, 500, or may

alternatively be separate functional entities or means. They may also be implemented as integral transceivers. The input

101, 201, 301, 401, 501 and the output 103, 203, 303, 503 may be implemented e.g. as physical transmitters/receivers for transceiving via the air interface, as routing entities for sending/receiving data packets in a PS (packet switched) network, or as any suitable combination thereof.

The processor 102, 202, 302, 402, 502 may be configured to process various data inputs and to control input 101, 201, 301, 401, 501 and the output 103, 203, 303, 502. The

apparatus 100, 200, 300, 400, 500 may further comprise a memory that may serve for storing code means for carrying out e.g. the methods according to the examples of the present invention, when run e.g. on the processor 102, 202, 302, 402, 502.

In all above described embodiments, the at least one traffic steering policy is created based on at least one identified application and the application is identified based on the measurement of the traffic created by the application. The measurement of the traffic created by an application may be based e.g. on the total amount of transferred data during a specific timeframe. It may also be based on the amount of transferred data with relation to available resources or on the amount of signalling data created by an application.

The above described mechanism may be most efficient when the application identification can be done in real-time and the results of the identification can automatically be given as an input to the decision engine. When all the above is automated, it is possible to build a dynamic system that can by itself control the usage of network resources: when e.g. load situation changes in some part of the network, the proposed mechanism can ensure that UEs are instructed to use e.g. different network, or different parts of network. Also, the above described mechanism may be executed continuously so that the changing load situations can be tackled in real-time taking most out of the existing network hardware.

This kind of "light-weight" solution, where only a few applications creating most of the traffic are identified, can be realized without heavy traffic analyzing mechanisms. The benefits gained by identifying the few applications with heaviest traffic is enough to free capacity for other more precious traffic, and the traffic that is not "identified" can remain ignored. Further, if satisfactory results are not initially achieved, the above described mechanism may be re- executed with identifying couple of more applications until satisfactory state of the network is achieved. Further, when identifying only a few applications, the information that is needed to be transferred from information server (e.g. ANDSF) 200 to the terminals 400 remains reasonable small making the whole mechanism more useful and simple.

One having ordinary skill in the art will readily understand that the invention as discussed above may be practiced with steps in a different order, and/or with hardware elements in configurations which are different than those which are disclosed. Therefore, although the invention has been

described based upon these preferred embodiments, it would be apparent to those of skill in the art that certain

modifications, variations, and alternative constructions would be possible, while remaining within the scope of the invention. Is should be specifically noted that the present invention applies offloading traffic between 3GPP network and WLAN in either direction. Thus, the invention may also be applied for offloading traffic from WLAN to 3GPP network.

Claims

1. A method for traffic steering in a communication network comprising :

receiving (S21, S31) at a first network element (23) a traffic steering instruction from a second network element (100); and

activating (S22, S32) said traffic steering instruction; wherein said traffic steering instruction is created by said second network element (100) based on at least one identified application and wherein each of said at least one application is identified based on the traffic created by said application.

2. The method according to claim 1, wherein said traffic steering instruction comprises at least one rule for

offloading traffic from a cellular network to a wireless local area network.

3. The method according to claim 1 or 2, wherein said traffic steering instruction comprises at least one rule for

offloading traffic from a wireless local area network to a cellular network.

4. The method according to any of claim 1 to 3, wherein said second network element (100) comprises a decision engine (100) .

5. The method according to any of preceding claims, wherein said first network element (23) comprises a policy and charging rules function (300) .

6. The method according to claim 5, wherein said activating (S22, S32) comprises providing said traffic steering

instruction to a policy and charging enforcement function (500) .

7. The method according to any of claims 1 to 4, wherein said first network element (23) comprises an information server (200) .

8. The method according to claim 7, wherein said information server (200) comprises an access network discovery and selection function.

9. The method according to claim 7 or 8, wherein said

activating (S22, S32) comprises providing policy information to a terminal (400) .

10. The method according to claim 9, wherein said policy information comprises said received traffic steering

instruction.

11. The method according to claim 9 or 10, wherein said providing comprises providing said information in a dynamic host configuration protocol message, in a router

12. An apparatus (100) in a communication network comprising: an input (101) configured to receive information on at least one identified application;

a processor (102) configured to create a traffic

steering instruction; and

an output (103) configured to send said traffic steering instruction to a first network element (23) in said

communication network;

wherein said traffic steering instruction is created based on the received information on the at least one

identified application and wherein each of said at least one application is identified based on the traffic created by said application.

13. The apparatus (100) according to claim 12, wherein said information comprises at least one of a source IP address, a source IP address range, a destination IP address, a

destination IP address range, a source port, a destination port, a transport protocol, and type of service.

14. The apparatus (100) according to claim 12 or 13, wherein each of said at least one application is identified based on total amount of transferred data of said application during a specific timeframe, amount of transferred data of said application with relation to available resources, or amount of signalling data created by said application.

15. The apparatus (100) according to any of claims 12 to 14, wherein said traffic steering instruction comprises at least one rule for offloading traffic from a cellular network to a wireless local area network.

16. The apparatus (100) according to any of claims 12 to 14, wherein said traffic steering instruction comprises at least one rule for offloading traffic from a wireless local area network to a cellular network.

17. The apparatus (100) according to any of claims 12 to 16, wherein said first network element (23) comprises a policy and charging rules function (300) or an information server (200) .

18. The apparatus (100) according to any of claims 12 to 17, wherein said apparatus (100) comprises a decision engine (100) .

19. An apparatus (23) in a communication network comprising: an input (231) configured to receive a traffic steering instruction from a second network element (100) in said communication network; and

a processor (232) configured to activate said received traffic steering instruction; wherein said received traffic steering instruction comprises an instruction for forwarding traffic of an

application to a first access network.

20. The apparatus of claim 19, wherein said first access network comprises a cellular network or a wireless local area network .

21. The apparatus (23) according to claim 19 or 20, wherein said traffic steering instruction comprises at least one rule for offloading traffic from a cellular network to a wireless local area network.

22. The apparatus (23) according to claim 19 or 20, wherein said traffic steering instruction comprises at least one rule for offloading traffic from a wireless local area network to a cellular network.

23. The apparatus (23) according to any of claims 19 to 22, wherein said first network element (23) comprises a policy and charging rules function (300) .

24. The apparatus (23, 300) according to claim 23, further comprising an output (303) configured to provide policy information to a policy and charging enforcement function (500) and wherein said processor (232, 302) is further configured to activate said received traffic steering

instruction by causing said output (303) to provide said policy information to a policy and charging enforcement function (500) .

25. The apparatus (23) according to any of claims 19 to 22, wherein said first network element (23) comprises an

information server (200).

26. The apparatus (23, 200) according to claim 25, wherein said information server (200) comprises an access network discovery and selection function.

27. The apparatus (23, 200) according to claim 25 or 26, further comprising an output (203) configured to provide policy information to a terminal (400) and wherein said processor (232, 202) is further configured to activate said received traffic steering instruction by causing said output (203) to provide said policy information to a terminal (400) .

28. The apparatus (23, 200) according to claim 27, wherein said policy information comprises said received traffic steering instruction.

29. The apparatus (23, 200) according to claim 27 or 28, wherein said policy information is provided in a dynamic host configuration protocol message, in a router advertisement message, or in an access network discovery and selection function management object.

30. The apparatus (23) according to any of claims 19 to 29, wherein said second network element (100) comprises a

decision engine (100).

31. A mobile terminal (400) comprising:

an input (401) configured to receive a traffic steering instruction from an information server (200); and

a processor (402) configured to change behaviour of said mobile terminal (400) based on said received traffic steering instruction ;

wherein said received traffic steering instruction comprises an instruction for forwarding traffic of an

application to a first access network.

32. The mobile terminal (400) according to claim 31, wherein said first access network comprises a cellular network or a wireless local area network.

33. The mobile terminal (400) according to claim 31 or 32, wherein said traffic steering instruction comprises at least one rule for offloading traffic from a cellular network to a wireless local area network.

34. The mobile terminal (400) according to claim 31 or 32, wherein said traffic steering instruction comprises at least one rule for offloading traffic from a wireless local area network to a cellular network.

35. The mobile terminal (400) according to any of claims 31 to 34, wherein said processor (402) is further configured to change behaviour of said mobile terminal (400) by forwarding certain application data over said wireless local area network instead of said cellular network.

36. A computer-readable medium encoded with instructions that, when executed in hardware, perform a process, the process comprising:

receiving (S21, S31) at a first network element (23) a traffic steering policy from a second network element (100); and

activating (S22, S32) said traffic steering policy;

application to a first access network.

37. The computer-readable medium according to claim 36, wherein said first access network comprises a cellular network or a wireless local area network.

38. The computer-readable medium according to claim 36 or 37, wherein said traffic steering instruction comprises at least one rule for offloading traffic from a cellular network to a wireless local area network.

39. The computer-readable medium according to claim 36 or 37, wherein said traffic steering instruction comprises at least one rule for offloading traffic from a wireless local area network to a cellular network.