WO2015065267A1 - Methods and apparatuses for policy based wifi/3gpp integration - Google Patents

Abstract

The present embodiments relates to a user equipment (1500) and method therein for network access selection, and a network node (1) and a method therein for providing policies to the UE. The method in the UE (1500) comprises: receiving from the network node (1) a policy index to identify a policy set stored in the UE (1500). The method further comprises selecting a policy from the identified policy set and selecting a network based on the selected policy. The network (1) assigns policy set(s) and policy indices and sends the information to the UE (1500) and then selects a policy index and sends it to the UE enabling the UE to select a network based on the selected policy.

Description

Methods and Apparatuses for policy based Wifi/3GPP

integration

Technical Field

The present disclosure relates generally to wireless communications and more particular to policy-based Wifi/3GPP integrations inclosing a device e.g. user equipment and a network node and methods therein.

Background

The Evolved UMTS Terrestrial Radio Access Network (E-UTRAN) consists of base stations called enhanced NodeBs (eNBs or eNodeBs), which provide the E-UTRA user plane and control plane protocol terminations towards the User Equipment (UE). The eNBs are interconnected with each other by means of the X2 interface. The eNBs are also connected by means of the S1 interface to the EPC (Evolved Packet Core), more specifically to the MME (Mobility Management Entity), by means of the S1-MME interface, and to the Serving Gateway (S-GW) by means of the S1 -U interface. The S1 interface supports many-to-many relations between MMEs / S-GWs and eNBs. The E-UTRAN architecture is illustrated in Figure 1. The E- UTRAN is also known as Long Term Evolution (LTE)

The eNB hosts functionalities such as Radio Resource Management (RRM), radio bearer control, admission control, header compression of user plane data towards serving gateway, and routing of user plane data towards the serving gateway. The MME is the control node that processes the signaling between the UE and the core network. The main functions of the MME are related to connection management and bearer management, which are handled via Non Access Stratum (NAS) protocols. The S-GW is the anchor point for UE mobility, and also includes other functionalities such as temporary downlink data buffering while the UE is being paged, packet routing and forwarding the right eNB, gathering of information for charging and lawful interception. The P-GW (Packet Data Network (PDN) Gateway (GW)) is the node responsible for UE IP address allocation, as well as Quality of Service (QoS) enforcement (this is explained further in later sections Using Wifi/WLAN (the two terms are used interchangeably throughout this document) to offload traffic from the mobile networks is becoming more and more interesting from both the operator's and end user's points of view. Some of the reasons for this tendency are:

• Additional frequency: by using Wifi, operators may access an additional 85MHz of radio bandwidth in the 2.4GHz band and another (close to) 500MHz in the 5GHz band.

• Cost: From the operator's point of view, Wifi uses unlicensed frequency that is free of charge. On top of that, the cost of Wifi Access Points (APs), both from capital expense (CAPEX) and operational expenses (OPEX) aspects is considerably lower than that of a 3GPP base station (BS/eNB). Operators may also take advantage of already deployed APs that are already deployed in hotspots such as train stations, airports, stadiums, shopping malls, etc. Most end users are also currently used to having Wifi for free at home (as home broadband subscriptions are usually flat rate) and public places.

• Terminal support: Many UEs including virtually all smartphones and other portable devices currently available in the market support Wifi. In the Wifi world, the term Station (STA) is used instead of UE, and as such the terms UE, STA and terminal are used interchangeably in this document.

• High data rate: Under low interference conditions and assuming the user is close to the Wifi AP, Wifi may provide peak data rates that outshine that of current mobile networks (for example, theoretically up to 600Mbps for IEEE 802.1 1 η deployments with MIMO (Multiple Input Multiple Output)).

A very simplified Wifi architecture is illustrated in Figure 2 and in Figure 3. On the user plane (Figure 2) depicting a simplified Wifi user plane architecture, a very lean architecture is employed, where the UE/STA is connected to the Wifi AP, which may directly be connected an application via the Internet (IP). In the simplified Wifi control plane architecture (Figure 3), a Wifi Access point Controller handles the management of the AP. One controller usually handles the management of several APs. Security/authentication of users is handled via an Authentication, Authorization and Accounting (AAA) entity, which is shown as a Remote Administration Dial In User Service (RADIUS) server in Figure 3. RADIUS is the most widely used network protocol for providing a centralized AAA management

The Access Network Discovery and Selection Function (ANDFS) is an entity defined by 3GPP for providing access discovery information as well as mobility and routing policies to the UE. ANDFS is a new entity added to the 3GPP architecture. A simplified ANDSF architecture is depicted in Figure 4. As shown in the figure, the ANDSF (server) is connected to the UE, and its main goal is to provide the UE with access network information in a resource efficient and secure manner. The communication between the UE and the ANDSF server is defined as an IP- based S14-interface. A GW is also shown and also a Wifi AP and a 2G/3G/4G eNB.

By supplying information about both available 3GPP and non-3GPP access networks (e.g. Wifi access network) to the UE, the ANDSF enables an energy-efficient mechanism of network discovery, where the UE may avoid continuous and energy-consuming background scanning. Furthermore, the ANDSF provides the mobile operators with a tool for the implementation of flexible and efficient UE steering of access mechanisms, where policy control may guide UEs to select one particular RAN over another. Note that this may be an overstatement if ANDSF is implemented as an "app", since it then relies on operating system (OS) support and prioritization of ANDSF in relation to other "apps". This condition may be only partly fulfilled, which thus makes the control of the UE via the ANDSF somewhat unreliable.

The ANDSF (server) supplies three types of information - discovery information, inter-system mobility policies (ISMP) and inter-system routing policies (ISRP). All these are summarized and implemented via ANDSF managed objects (MO), which are communicated to the UEs via an over-the-top (OTT) signaling channel, as SOAP-XML messages.

The discovery information provides the UE with information regarding the availability of different RATs (Radio Access Technologies) in the UE's vicinity. This helps the UE to discover available 3GPP and non-3GPP access networks without the burden of continuous background scanning. ISMP are policies which guide the UE to select the most preferable 3GPP or non-3GPP access. The ISMP are used for UEs that access a single access (3GPP or Wifi) at a time. The ISMP information specifies the behavior of UEs that may be connected to only one access network at a given time (either 3GPP, WLAN, WiMAX, etc.). If the UE, however, supports connection to several access networks at the same time, the operator may use the third type of information, ISRP, to increase the granularity of the RAN selection. In that case, the UEs will be provided with policies that specify how the traffic flows should be distributed over the different RAN. For example, voice might be only allowed to be carried over 3GPP RA (Radio Access), while Internet video streaming and best-effort traffic may be routed via WLAN. The ANDSF provides mobile operators with a tool to determine how the UEs connect to different RANs and hence allows them to add more flexibility in their traffic planning. Simplified examples of ANDSF rules are given in Table 1 and Table 2.

Table 1 : ANDSF MO - Discovery Information

Table 1 consists of two access network discovery entries. The first rule, for example, states that there is a WLAN access network (with SSID "OperatorSSID812") available in the area, described by the geographical coordinates. The second rule states that there is a WLAN access network available in two 3GPP cells, indicated by their respective cell IDs.

Table 2: ANDSF MO - ISRP

Rule ForFlowBased Roaming PLMN UpdatePolicy

Priority

1 IPFIow: 0 (UE not 24009 0 (UE not required

-StartSourcePortNumber = 22 roaming) to update the policy)

-EndSourcePortNumber = 23

(SSH, Telnet) -StartDestPortNumber = 22

-EndDestPortNumber = 23

ValiditvArea:

-Anc orLatitude = 5536988

-Anc orLongtitude = 836620

-Radius = 40

RoutinaRules:

-AccessTec nology = 1 (3GPP)

2 IPFlow: 0 (UE not 24009 0 (UE not required

- ProtocolType = 6 (TCP) roaming) to update the policy)

ValiditvArea:

-AnchorLatitude = 5536988

-AnchorLongtitude = 836620

-Radius = 40

TimeOfDav:

-TimeStart = 170000

-TimeStop = 180000

RoutinaRules:

-AccessTechnology = 3 (WLAN)

-Accessld = OperatorSSID812

With the proliferation of devices that have both Wifi and 3GPP mobile broadband support, offloading traffic to the Wifi network is becoming very interesting, both from the user's and the operator's perspectives. The main difference between traffic steering in the Wifi case as compared to steering between 3GPP networks (or 3GPP-"friendly" networks such as CDMA2000) is that it is the terminal that decides when it shall select a Wifi Access Point (AP), while in the latter case it is the network that is in charge of the network access decisions. Due to technical and historical reasons, the Wifi deployment scenario is in many cases fundamentally different than the cellular deployment. For this reason, special considerations have to be made when integrating Wifi to 3GPP networks.

Table 2 contains a description of two rules that apply to the same location, in this case represented by geographical coordinates that specify a "Validity Area." Note that the rules overlap, since the first one characterizes all data-flows carried via ports 20 to 23 (all of which usually carry TCP traffic). At the same time, the second rule applies to all TCP traffic, hence the second rule is more generic. In order to make sure that the Telnet and SSH traffic (ports 22 and 23 respectively) is carried over 3GPP RA, the first rule is given a higher priority (the lower number means higher priority). Different standards organizations have started to recognize the needs for an enhanced user experience for Wifi access, this process being driven by 3GPP operators. An example of this is the Wifi Alliance with a so-called Hot-Spot 2.0 (HS2.0) initiative, now officially called PassPoint ("Hotspot 2.0 (Release 1). HS2.0 is primarily geared toward Wifi networks. HS2.0 builds on IEEE 802.1 1 u, and adds requirements on authentication mechanisms and auto-provisioning support.

The momentum of Hot-Spot 2.0 is due to its roaming support, its mandatory security requirements and for the level of control it provides over the terminal for network discovery and selection. Even if the current release of HS2.0 is not geared toward 3GPP interworking, 3GPP operators are trying to introduce additional traffic steering capabilities, leveraging HS2.0 802.1 1 u mechanisms. Because of the high interest of 3GPP operators, there will be a second release of HS2.0 focusing on 3GPP interworking requirements.

HS2.0 contains the following procedures:

1 Discovery: where the terminal discovers the Wifi network, and probes it for HS2.0 support, using 802.1 1 u and HS 2.0 extensions.

2 Registration is performed by the terminal toward the Wifi Hot-spot network if there is no valid subscription for that network.

3 Provisioning: Policy related to the created account is pushed toward the terminal. This only takes place when a registration takes place.

4 Access: cover the requirements and procedures to associate with a HS2.0 Wifi network.

When it comes to Wifi/3GPP Integration/non integration mechanisms, the following description is provided. For the non-integration mechanism, most current Wifi deployments are totally separate from mobile networks, and are to be seen as non-integrated. From the terminal perspective, most mobile operating systems (OS) for UEs such as Android and iOS support a simple Wifi offloading mechanism, where the UEs immediately switch all their PS (Packet Switched) bearers to a Wifi network upon a detection of such a network with a certain signal level. The decision to offload to a Wifi or not is referred henceforth as access selection strategy and the aforementioned strategy of selecting Wifi whenever such a network is detected is known as "Wifi-if-coverage". There are several drawbacks of the Wifi-if-coverage strategy

• Though the user/UE may save previous passcodes for already accessed Wifi Access Points (APs), hotspot login for previously un-accessed APs usually requires user intervention, either by entering the passcode in Wifi connection manager or using a web interface.

• Interruptions of ongoing services may occur due to the change of IP address when the UE switches to the Wifi network. For example, a user who started a VoIP call while connected to a mobile network is likely to experience call drop when arriving home and the UE switching to the Wifi network automatically. Though some applications are smart enough to handle this and to survive the IP address change the majority of current applications cannot. It also places a lot of burden on application developers if they have to ensure service continuity.

• No consideration of expected radio performance is made, and this may lead to a UE being handed over from a high data rate mobile network link to a low data rate via the Wifi link. Even though the UE's OS or some high level software is smart enough to make the offload decisions only when the signal level on the Wifi is considerably better than the mobile network link, there may still be limitations on the backhaul that the Wifi AP is using that may end up being the bottle neck.

• No consideration of the load conditions in the mobile network and Wifi are made. As a result, the UE might still be offloaded to a Wifi AP that is serving several UEs while the mobile network (e.g., LTE) that it was previously connected to is rather unloaded.

• No consideration of the UE's mobility is made. Due to this, a fast moving UE may end up being offloaded to a Wifi AP for a short duration, just to be handed over back to the mobile network. This is specially a problem in scenarios like cafes with open Wifi, where a user walking by or even driving by the cafe might be affected by this. Such ping pong between the Wifi and mobile network may cause service interruptions as well as generate considerable unnecessary signaling (e.g. towards authentication servers) In order to combat these problems, several Wifi/3GPP integration mechanisms have been proposed.

When it comes to Common Authentication, the idea behind it is based on the use of automatic SIM-based authentication in both access types. Extensible Authentication Protocol (EAP) is an authentication framework that provides support for the different authentication methods. This protocol is carried directly over data-link layer (DLL) and is currently widely deployed in WLANs. The EAP framework specifies over 40 different methods for authentication, and EAP-SIM (Subscriber Identity Module) is the one that is becoming widely available in UEs and networks. The main benefit of common authentication is that the user doesn't necessarily have to be actively involved in the authentication process, which will increase the chances of more traffic to be steered to the Wifi side, paving the way for network centric control.

The Wifi user plane integration provides the mobile operator the opportunity to provide the same services, like parental control and subscription based payment methods, for the end users when connected both via 3GPP and via Wifi. The solutions also include the possibility to offload parts of the user plane from the mobile core so that not all traffic needs to be brought to the mobile core network.

Different solutions are being standardized in 3GPP. Overlay solutions (S2b, S2c) are specified since 3GPP Rel-8, while integration solutions (S2a) are currently a work-in-progress (S2a, S2b, S2c indicate the 3GPP interface/reference point name towards the PDN-GW).

A further level of integration may be realized via access selection based on RAN information on both 3GPP and Wifi, in addition to the common authentication and user plane integration methods discussed above.

A functional entity known as a Smart RAN Controller (SRC) is introduced. The SRC may be used as an information sharing point for the Wifi and 3GPP networks. Optimal traffic steering may then be performing by considering the situation at each network. Using such an abstraction, even legacy UEs could be able to benefit from Wifi integration. For example, consider a legacy UE that is already connected to a 3GPP network and comes to a Wifi coverage area, while employing the "Wifi-if-coverage" access selection mechanism described above. When the UE tries to connect to the Wifi network, the Wifi AP/AC may connect to the SRC to request information about the current user's Quality of Service (QoS) in the 3GPP network, and if it is found that the user's quality-of-service (QoS) is going to be degraded if the connection is switched to Wifi, a rejection could be sent to the UE from the Wifi in order keep it connected to the 3GPP network. A tighter integration may also be formed if the Wifi AP and eNB are co-located and have direct communication between them rather communicating via the SRC (similar one may think of direct communication between the AC, RNC, BSS, etc .).

The different deployment scenarios for Wifi may be categorized into three groups as Private Wifi, Public Wifi and Integrated Wifi., The different scenarios are explained below:

Private Wifi (residential, enterprise)

o Access selection controlled by end user

o Operator services supported over the top and/or with S2b (S2c)

o No charging

Public Wifi (3^rd Party, Operator/Shared Hotspot)

o Access selection depending on roaming agreements, end user, etc.

o Possible to use HS2.0 mechanism for authentication (EAP-SIM) and roaming

^■ Access selection based on operator policies (ANDSF/HS2.0) may be supported in the future terminals.

o Operator services supported over the top and/or with S2b (S2c)

o Different charging models typically used in Wifi compared to cellular (e.g. flat-rate, bucket charging).

Integrated Wifi (Wifi as a part of Heterogeneous network)

o Wifi network is managed by the operator.

o Access selection controlled by operator via network based mechanism and/or ANDSF/HS2.0 policies sent to the UE

o Seamless Wifi offloading experience for end user (i.e. user does not need to care about which interfaces are used for the traffic)

o All operator services supported using smart service selection and user plane integration (e.g. S2a, S2b over trusted Wifi)

o Possibility to optimize network performance and end user experience

o Future support for seamless IP session continuity

o Similar charging model in Wifi and cellular. For the Private and the Public Wifi (Wifi roaming) scenarios it is expected that only limited network control may be used due to e.g. different charging models typically used in Wifi compared to cellular. Examples of network control mechanisms that could be also applicable in these scenarios are ANDSF and HS2.0.

Device connection managers are installed in various terminals either in operating systems or as an OTT (Over The Top) application. The connection manager may discover available access networks, and make connection decisions based on service type, user preference and potentially link quality in order to get better QoE (Quality of Experience).

There are however problems to be pointed out:

The behavior of connection manager-based access selection and traffic steering varies significantly between operating systems and applications, which makes it very difficult for operators to troubleshoot and optimize user experience. With very limited operator control, the terminal behaviors may be unpredictable; hence network performance is easily degraded.

ANDSF policies are either static or semi-static, and they are not adaptive to fast changing radio environments and system loads. Even though it is possible to enhance the ANDSF to include radio link quality into the policies, the current mechanisms limit the update frequency of the policies. Therefore, the current ANDSF approach is not capable of reliably and consistently guiding the terminal to an access that provides better QoE.

In terms of 3GPP interworking, HS2.0 is mainly to improve usability and to facilitate access selection by providing the Wifi loads. It is not expected that HS2.0 will support operator controlled dynamic access selection.

The ANDSF and HotSpot2.0 mechanisms described above are not targeting a tight integration of Wifi that considers network information (e.g., load in different accesses, bitrates, etc.). The reason for this is that the exact UE behavior is not specified and the existing parameters do not include radio information. However, there is work starting in 3GPP SA2 and Wifi Alliance HotSpot2.0 Release 2 to enhance ANDSF to take into account the Hotspot 2.0 solutions. One example is that the ANDSF policy could define UE actions based on the information received from the Wifi AP about the BSS load and WAN metric. UE-based solutions such as the currently available ones in Android and iOS based phones have several drawbacks, as described above. Network-based solutions such as ANDSF, as mentioned above, use rather static rules and thus don't reflect current network conditions. RAN level integration via SRC is able to consider both UE and network performance in a dynamic fashion. However, the SRC-based solution may become complex to realize, as there is a need to maintain the context of each UE in the different access networks. Also, each offloading decision requires the involvement of the SRC entity, thus a UE in IDLE mode in 3GPP and not connected to Wifi will not be able to utilize the benefits of SRC based solutions.

According to several embodiments of the present embodiments, a dynamic and flexible solution to 3GPP/Wifi integration that overcomes the aforementioned problems of existing solutions is provided. Note that while the case of 3GPP and WLAN is used as an exemplary scenario in the description that follows, the main ideas disclosed herein may be applied to other kinds of networks as well.

Brief Summary

According to several embodiments of the present embodiments, a dynamic and flexible solution to 3GPP/Wifi integration that overcomes the aforementioned problems of existing solutions is provided.

According to an aspect of exemplary embodiments, at least some the previously stated problems are solved by means of a method implemented in or by a user equipment for access selection. The method comprising: receiving from a network node a policy index informing the user equipment which Access Network Discovery and Selection Function (ANDSF) policy set to be used by the user equipment; the user equipment having stored sets of ANDSF policies and associated policy indices, each policy identifying a ANDSF policy set. The method further comprising selecting an ANDSF policy from the ANDSF policy set identified by the received policy index, and selecting an access network based on at least the selected ANDSF policy.

According to another aspect of exemplary embodiments, at least some of the previously stated problems are solved by means of a method implemented in or by a network node for providing ANDSF policies to at least one user equipment for access selection, the method comprising: defining sets of ANDSF policies for said at least one user equipment; assigning for each ANDSF policy set, an policy index; sending, to the at least one user equipment, the sets of ANDSF policies and the assigned policy indices; selecting and sending a policy index to the at least one user equipment; informing the UE which ANDSF policy set to select among the sets of ANDSF policies.

According to another aspect of exemplary embodiments, at least some of the previously stated problems are solved by means of a user equipment for network access selection. The user equipment comprising a receiver unit configured to receive, from a network node, a policy index; informing the user equipment which ANDSF policy set to be used by the UE; the UE having stored in a data storage sets of ANDSF policies and associated policy indices, each policy index identifying a ANDSF policy set. The user equipment further comprising a processing circuit configured to select an ANDSF policy from the ANDSF policy set identified by the received policy index; and the processing circuit is further configured to select an access network based on at least the selected ANDSF policy.

According to another aspect of exemplary embodiments, at least some of the previously stated problems are solved by means of a network node for providing ANDSF policies to at least one user equipment for access selection. The network node being configured to: define sets of ANDSF policies for said at least one UE; assign for each ANDSF policy set, an policy index; send, to the at least one user equipment, the sets of ANDSF policies and the assigned policy indices; and select and sending a policy index to the at least one user equipment informing the user equipment which ANDSF policy set to select among the sets of ANDSF policies.

Several embodiments of the present embodiments enable dynamic operator control over access selection and traffic steering between access networks by defining a number of (semi-dynamic) policy sets for each terminal. A dynamic network policy index may be broadcasted to all terminals (or user equipments) or/and communicated in a unicast fashion to a given terminal to indicate a proper set of policies to use. In addition to using the policy index for the selection of policy set, the terminal or user equipment may further select the policy from the indicated policy set based on its current state, such as connection status and ongoing traffic.

Several advantages are achieved. For example: A dynamic and flexible way for operators to control/support their users and distribute traffic among the different access networks.

A possibility to consider the performance of both individual UE as well as the overall network. A possibility to set user specific policies (e.g. depending on user profile, terminal capability, current UE state, etc.). A possibility to set policies that are coherent with the current state of the network (load conditions, operating mode, etc.). A possibility to do so, without explicitly revealing the current state of the network (such as load), as the reason behind the policy rules and indexes are only known at the network.

Additional embodiments and solutions will be described below in the detailed description in conjunctions with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other aspects, features and advantages will be apparent and elucidated from the following description of various embodiments, reference being made to the accompanying drawings, in which:

Figure 1 is an example of an E-UTRAN architecture.

Figure 2 illustrates another simplified Wifi architecture.

Figure 3 illustrates another simplified Wifi architecture.

Figure 4 illustrates a simplified ANDSG architecture.

Figure 5 is a flow diagram illustrating a method performed by a UE according to exemplary embodiments herein.

Figure 6 is a process flow diagram illustrating an approach according to some embodiments herein.

Figure 7 is an example showing selecting of a policy.

Figure 8 is an example of an ANDSF policy.

Figure 9 shows an example of providing parameters to a UE from a network.

Figure 10 shows an example of providing radio access blocks for a UE.

Figure 11 illustrates an exemplary embodiment of actions performed by a network node.

Figure 12 is a flow diagram illustrating a method performed by a network node according to exemplary embodiments herein.

Figure 13 illustrates an exemplary embodiment of actions performed by a UE.

Figure 14 illustrates a block diagram depicting a terminal or UE according to exemplary embodiments herein. Figure 15 illustrates a block diagram depicting a network node according to exemplary embodiments herein.

Detailed description

In the discussion that follows, specific details of particular embodiments of the present embodiments are set forth for purposes of explanation and not limitation. Furthermore, in some instances detailed descriptions of well-known methods, nodes, interfaces, circuits, and devices are omitted so as not obscure the description with unnecessary detail. Those skilled in the art will appreciate that the functions described may be implemented in one or in several nodes. Some or all of the functions described may be implemented using hardware circuitry, such as analog and/or discrete logic gates interconnected to perform a specialized function, ASICs, PLAs, etc. Likewise, some or all of the functions may be implemented using software programs and data in conjunction with one or more digital microprocessors or general purpose computers. Where nodes that communicate using the air interface are described, it will be appreciated that those nodes also have suitable radio communications circuitry. Moreover, the technology may additionally be considered to be embodied entirely within any form of computer-readable memory, including non-transitory embodiments such as solid-state memory, magnetic disk, or optical disk containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein.

Hardware implementations of the present embodiments may include or encompass, without limitation, digital signal processor (DSP) hardware, a reduced instruction set processor, hardware (e.g., digital or analog) circuitry including but not limited to application specific integrated circuit(s) (ASIC) and/or field programmable gate array(s) (FPGA(s)), and (where appropriate) state machines capable of performing such functions.

In terms of computer implementation, a computer is generally understood to comprise one or more processors or one or more controllers, and the terms computer, processor, and controller may be employed interchangeably. When provided by a computer, processor, or controller, the functions may be provided by a single dedicated computer or processor or controller, by a single shared computer or processor or controller, or by a plurality of individual computers or processors or controllers, some of which may be shared or distributed. Moreover, the term "processor" or "controller" also refers to other hardware capable of performing such functions and/or executing software, such as the example hardware recited above.

This disclosure focuses on several aspects of integrating Wifi to 3GPP networks, in order to realize optimal steering of traffic while considering both the end user's as well as the network's performance. Note however that while the case of 3GPP and Wifi/WLAN is used as an exemplary scenario in the description that follows, the main ideas disclosed herein may be applied to other kinds of networks as well.

Figure 5 is a flow diagram illustrating the main steps of a method performed by a user equipment (UE) or terminal for access selection in according with exemplary embodiments herein.

As shown in the method comprises:

Receiving 510 from a network node a policy index informing the UE which ANDSF policy set to be used by the UE. The UE having stored sets of ANDSF policies and associated policy indices, each policy index identifying a ANDSF policy set;

Selecting 520 an ANDSF policy from the ANDSF policy set identified by the received policy index; and

Selecting 530 an access network based on at least the selected ANDSF policy.

Hence, an example method implemented by the terminal or UE configured to support communications via both WLAN technology and WAN (or 3GPP) technology (whether simultaneously or at separate times), begins with receiving a network policy index from a first access network, the network policy index identifying one of a plurality of sets of network access policies. The method continues with a selection of a policy in the identified set, based on a current state for the terminal or UE, followed by a subsequent selection of a second access network based on the selected policy. It should be mentioned. The second access network may or may not be the same as the first access network. For example, the first and second access network may be Wifi-based networks, or 3GPP-based networks. In another example, the first access network maybe a 3GPP network and the second access network a Wifi network or vice versa.

As will be explained, the network policy index may be received via a broadcast or unicast message or via a terminal-specific message, such as an SMS message. The network policy may be the ANDSF policy. The terminal or UE may receive data defining one or more of the policies or sets of policies from a third access network, which third access network may be the same as or different from either or both of the first and second access networks.

According to an embodiment, selecting of the access network is further based on a state of the UE such as connection status (e.g. in IDLE or CONNECTED mode), ongoing traffic and UE profile.

According to an embodiment, selecting an access network comprises selecting between a Wifi access network and a 3GPP access network.

According to another exemplary embodiment, the selection of the access network based on the selected policy may be based on one or more of the following parameters: a Reference Signal Received Power (RSRP), a Reference Signal Received Quality (RSRQ), a Reference Signal Code Power (RSCP), a Received Signal Strength Indicator, and a parameter representing a load for an access network.

In the following, details of embodiments herein will be described.

Figure 6 is a process flow diagram illustrating an approach according to several embodiments. Details of the different steps and the changes required on the network as well as the UE are described below.

In various embodiments, access network selection by a terminal or UE is controlled by network configured policies. A policy may also be viewed as an ANDSF policy as described earlier, which is used for access network discovery, access network selection and/or traffic steering.

Two types of policies are shown in Figure 6 and which may be used for access network selection by a UE in cooperation with at least one network node:

A static policy is similar to the ANDSF policies described earlier, which are used for access network discovery and a dynamic policy consists/comprising of a set of attributes, a set of actions and rules to select actions based on measured attribute values. It is used to control the access selection of a terminal based on the current conditions observed by the terminal. The attributes are parameters which have impacts on access selection and may be measured by the terminal. Examples of attributes are:

• LTE Reference Received Signal Power (RSRP); Reference Received Signal Quality (RSRQ); system load

• WCDMA Received Signal Code Power (RSCP); Signal or Carrier-to-Noise ratio (e.g., EcNO); system load

• Wifi Received Signal Strength Indicator (RSSI); access point load

While the load information of the Wifi network is already available to the terminals via BSS and WAN metric, the load information in the 3GPP networks is currently not available to the terminals.

The rules are sets of constrains on the attributes, e.g. a range or threshold of a certain attribute. The terminal evaluates the attributes based on the rules. When the constraints of a rule are satisfied, the corresponding actions will be performed.

The actions may be, for example, the setting up or terminating of a connection or changing connection states to a network. Examples of actions are:

• Connect / disconnect to Wifi

• Go to IDLE in LTE/WCDMA

An example of a policy is given below. Table 3: An example of a policy

Since the static and dynamic policy may become both valid at the same time, the network may define which policy (static or dynamic) have priority over the other and communicate this along with the policies to the terminals. Note that these policies may be realized either by extending ANDSF and its policy format, or by introducing new policy communication protocol. The policies may be communicated to the terminals at a higher layer, e.g., using SMS as in the current case for ANDSF, or some lower layer signaling such as RRC. As shown in figure 6, the network or network node defines the static access selection policies 610 and dynamic access selection policies. These may be communicated to UEs 630. The network or network node further communicates current network policy index to be used by the UE(s) in a broadcast or unicast fashion 650. The UE may then choose the appropriate policy from the set of policies in the current index that matches its current state 650.

Terminal policy index and network policy index.

The optimized policy depends on terminal states, e.g. whether or not being connected to a Wifi network, and network conditions, e.g. the LTE cell load. Therefore it is necessary to define a policy for each combination of terminal and network conditions.

Note that in this disclosure the "index" represents or corresponds to the ANDSF parameter. The ANDSF parameter may be sent by the RAN node to the UE to point out or indicate which ANDSF policy the UE should use.

In the example of Figure 7, each policy is associated to one terminal policy index (y) and one network policy index (x). A policy will be activated only when it is selected based on the two indexes. Thus, as described in further detail below, a terminal that receives a network policy index (indicating a column of possible policies in Figure 7) then selects the appropriate terminal policy based on its current state. The chosen policy is shown.

Terminal policy index

Different policies are needed to optimize the access network selection when the terminal is in different states, e.g. whether connected to Wifi or not, whether in IDLE mode in 3GPP or CONNECTED mode, etc. Therefore, different policies may be defined for different terminal states.

Examples of terminal states are:

• Connected to Wifi: yes or no

• Status in 3GPP: IDLE or CONNECTED

• Active traffic: yes or no • Battery status: high or low

Network policy index

A wireless network is usually heterogeneous in both hardware deployment and traffic distribution. It is expected that the policy should be adaptive to network states, i.e. network capability, load and configurations. Therefore, different polices are defined for different network states. And the network node may inform the terminal which policy to use by signaling the network policy index to the terminal or UE. One network state is defined by a combination of network attributes. It should be noticed that the network state associated to each network policy index is transparent to the terminal. In other words, the terminal need only respond to a particular index - it does not need to know what network state corresponds to that index.

Examples of network attributes are:

• Network load

o Air interface load

o Backhaul load

• Feature support

o Ml MO support

o Carrier aggregation support

o Energy saving

Another usage of the network policy index is to switch between policies based on high level policies, e.g. between limiting and encouraging the usage of a Wifi network.

Network configured user or user-group specific policies

When a terminal or UE chooses a policy based on the terminal and network states, it is not necessary that the terminal has network connection. Therefore, all the policies are delivered by the network and stored in the terminal. For example, the policies may be communicated when the terminal is in connected mode and later used during IDLE mode. Policies may either be pushed to the terminal when it is in connected state or sent to the terminal when it requests it.

Different sets of policies may be configured for different users. For example, individual policy configuration for each subscription group may make golden users have a higher chance to be connected to a network which may provide guaranteed QoS. Another example is to provide special policy for a complaining user in order to improve his/her user experience and avoid churning. Different sets of policies may also be configured for different terminals, as a given user may own several terminals with different capabilities.

Network policy index signaling

The network node may signal to the UE a network policy index which tells the UE which policy, or set of policies, shall be used. The network policy index may be a numerical value, a letter, etc.

The network node may base the selection of the value of the signaled network policy index, for example, on the current network state or on a network, wanted UE behavior:

• Current network state - The network may have defined a set of policies for scenarios when the network load is high. If so, the network may signal the policy index for the high network load policies when the network load is high.

• Wanted UE behavior - The network node may also signal a network policy index based on wanted UE behavior. For example, the network may have defined a set of policies with network policy index X which ensures that all UEs connects to LTE and another set of policies with network policy index Y which ensures that all UEs connect to Wifi. If the network for example wants all UEs which monitors a certain network policy index to connect to LTE or Wifi it could signal value X or Y respectively for that network policy index.

Note that it is possible for the network not to define multiple network states.

As mentioned earlier, the network policy index may be broadcasted to the terminals or UEs on a broadcast channel. One benefit of broadcasting the network policy index is that a terminal may be able to receive it when being in IDLE-mode. Another benefit of broadcasting the network policy index is that signaling is reduced.

The network node may also broadcast multiple network policy indexes. Different sets of UEs may monitor different network policy indexes. Which network policy index a specific UE shall monitor may depend on predefined parameters, may be signaled from the network, or may be autonomously determined by the UE. For example, a UE may follow predefined rules or parameters - Which network policy index the UE shall monitor may be determined by predefined rules. Examples of such rules may be that the UE shall, or shall not, have one or more specific features enabled. There may also be parameters in the UE indicating which network policy index the UE shall monitor. This may, for example, depend on different subscription types, e.g. Gold-subscription, Silver-subscription, Bronze-subscription, and depending on the subscription type the UEs shall be given different service quality. These different sets of UEs may then monitor different network policy index. The benefit of this alternative is that it is possible to distinguish which network policy index different sets of UEs monitor.

According to previously described embodiments, network node indicates the policy index to the UE enabling the UE to monitor for the policy index. This may for example be signaled to the UE at initial connection (e.g. call setup, RRC connection establishment, etc.), at handover or in a per-need basis. The eNB or network node may then achieve a per UE-control over which network policy index the UEs are monitoring. For example if the network has determined that a specific UE is using a service for which a RAT reselection is not beneficial, it would, with this alternative, be possible to let this UE monitor an network policy index that indicates a policy or policy set for which RAT reselections is not likely. While another UE, which is using a service for which RAT reselections are acceptable, is ordered to monitor another network policy index which indicates a policy or policy set that is aimed to ensure that the UE connects to the RAT that provides the highest throughput but not necessarily few RAT reselections.

In the case that there is only one network state defined, no explicit communication or broadcasting of a network policy index is necessary.

According to an embodiment another alternative for signaling the network policy index is to unicast it to the UEs, for example using Radio Resource Control (RRC) signaling. This will allow for a UE-specific network policy index, which improves flexibility.

According to an embodiment, the policy selection may be terminal (or UE) state dependent. The current state of the terminal then determines which policy shall be employed by the terminal. For example there may be one policy which the terminal shall use when it has ongoing traffic and another policy when it has no ongoing traffic. Note that the terminal state may depend on many other parameters as explained above. The terminal may determine which state it is in by evaluating the parameters which define the state. Similarly the terminal may determine which policy the terminal shall select based on the terminal state from a policy set that are associated with the current network state. The terminal may, for example, associate each terminal state with an index, such as A, B and C, which is associated with a policy or set of policies ((P_A,i , P_A,2 and P_A,3) and (P_B,i , PB,2 and P_B,3) and (P_c,i , Pc,2 and P_c,3). This is illustrated in Table 4, where a terminal has three sets of policies: A, B and C, each with three policies numbered 1 , 2 and 3. If the terminal has identified itself to be in a state associated with index A, the UE selects one of policy P_A,i , P_A,2 and P_A,3. If the UE has instead identified itself to be in a state associated with index B, then the UE selects one of policy P_B,i , P_B,2 and P_B,₃.

Table4: Example policy matrix

UE State

A B c

Network

policy

index

Different alternatives for state identification may be envisioned. The terminal (or UE) may determine which state is applicable by periodically evaluating the parameters that determine the state. The periodicity may be predefined, for example, in a standard, or explicitly signaled to the terminal by the network. The periodicity may also be adjusted based on the current state of the terminal (for example, when the UE's battery is very low, the frequency of state update may be reduced). In addition to or as an alternative to this, a network policy index change may trigger the terminal to re-evaluate its state.

Some terminal state parameters are changing in a discrete manner, for example, Wifi state will either be on or off. For Wifi state it may be so that the entity which controls Wifi state will send an indicator to the UE state entity upon Wifi state change which triggers terminal state change.

Some other terminal state parameters are changing gradually, for example battery level which may gradually go from full to empty. Such parameters may depend on thresholds. Thresholds are set so that when the parameter value falls below (or goes above) a certain threshold the state for this parameter is considered changed, and the terminal may change its state. In the example of battery level, there may be one threshold at 10% and when the power falls below this value the battery state changes to low and when the power goes above this value the UE battery state changes to medium.

As mentioned earlier and in accordance with some embodiments herein, a terminal or a UE is configured to receive from the RAN (Radio Access Network) an ANDSF parameter used as input to an operator defined ANDSF policy. The operator or network operator may therefore design or define or introduce the ANDSF policies such that the RAN signaled ANDSF parameter is considered in the ANDSF policy in a correct way.

An example is shown in Figure 8 depicting of RAN signaled ANDSF parameter. In the example the UE would, based on the RAN signaled parameter, prioritize WLANs and 3GPP differently for traffic to APN A. Note that this is just an example and other ANDSF policies are also possible where the RAN signaled ANDSF-parameter is used.

To select which metric the RAN signaled parameters should represent and in accordance with an exemplary embodiment, one approach is to look at or determine which metrics are relevant for mobility between 3GPP and WLAN (or Wifi), these include radio interface load, mobility, enabled features, backhaul load, RAN processing capacity, alternative available frequencies, signal strength, etc. as previously mentioned. As the system evolves, it is also likely that in the future new metrics should be considered. Hence the list above is not restrictive. As many metrics may be considered for mobility between 3GPP and WLAN it is not feasible that the RAN signaled ANDSF parameter is restricted to represent any particular single metric. For example introducing such a RAN parameter; in Rel 12 or any 3GPP release capable in handling such parameter(s) in accordance with embodiments herein, representing e.g. PRB utilization one may later identify that that it is important to also consider available frequencies in the 3GPP network, then a new signalling maybe required for this and also update ANDSF to consider this new signalling. However one approach would be to consider a ANDSF parameter as a generic parameter which is not limited to represent any particular metric. The network operator then may have the freedom and flexibility to design the parameter such that it considers the metric relevant for the operator's network.

With this approach the operator may configure the RAN to signal ANDSF parameter values to the UE, considering metrics suitable for its particular network. Note that an advantage is that the parameter value does not need to have any particular meaning outside the operator's policy and hence it is avoided that different UEs have different interpretations of the ANDSF parameter. One may compare this with the PRB utilization approach in which different UEs may have different interpretations of which load is "high load". Hence, according to an exemplary embodiment herein, we introduce the RAN signaled ANDSF parameter to be a generic parameter which is not limited to represent any particular metric.

Below is an exemplary embodiment wherein applicability of the embodiments described above may be used in accordance with the present invention.

Parameter provisioning.

As discussed above, the RAN or a network node (eNB or base station in the RAN) is configured to provide to the UE parameters used for mobility between 3GPP and WLAN. Parameters may be provided by broadcast signalling to do steering in e.g. IDLE mode as mentioned before. To support per UE distinction the RAN may also signal dedicated parameters to a UE. An example is shown in Figure 9 wherein UE A would apply the dedicated parameters while UE B would apply the broadcasted parameters. Hence, in this example the UE which has received a parameter with dedicated signalling may be configured to apply this dedicated instead of the broadcasted parameters.

The table below shows which parameters the RAN provides.

Signal threshold:

The RAN may provide to the UE threshold values dictating when the UE should offload to WLAN/3GPP. These thresholds may be dynamically changed by the RAN to for example "push" a UE to WLAN if the RAN foresees that this particular UE should be offloaded to WLAN. It would also be possible to set these thresholds to "extreme" values so as to make sure that a UE is kept in 3GPP, or to make sure that a UE moves to WLAN as soon as WLAN is detected. This is described further.

Traffic identifiers

To allow per traffic steering the solution may for example support sending a bearer indicator to the UE indicating which radio access bearer(s) (RABs) should be kept in 3GPP and which are eligible for offloading to WLAN. In e.g. 3GPP Rel-12 timeframe the highest granularity for offloading is per APN offloading resulting in that an APN connection for a UE cannot be split between 3GPP and WLAN. To avoid this and in accordance with an example embodiment herein, the UE is configured to ensure that when it has been indicated to the UE by the RAN or network (or network node) that one of the RABs in an APN connection should be kept in 3GPP, then all the other RABs belonging to that APN is also kept in 3GPP. An example is shown in Figure 10. If e.g. the RAN node has indicated to the UE that RAB 2 should be kept in 3GPP then the UE would also keep RAB 1 in 3GPP so as to avoid that the IMS APN is not split over 3GPP and WLAN. This would also ensure that the UE does not detach as the RAN may indicate to the UE that at least one bearer (implicitly one APN) should be kept in 3GPP and hence the UE will remain attached.

Measurement configuration

According to an example embodiment, the RAN may configure the UE to perform reporting of WLAN (or Wifi) measurements. The RAN may configure the UE with a WLAN measurement event similar to a so called event B2 in LTE. The UE may trigger a WLAN measurement report when the 3GPP signal becomes worse than a threshold and WLAN indicating under which conditions the UE should report WLAN measurements, for example such a configuration could contain a 3GPP signal related threshold and a WLAN signal related threshold indicating that the UE should report a WLAN report when the 3GPP signal level is below a certain threshold and the WLAN signal is above a certain threshold.

For example, when the UE sends the WLAN measurement report the UE would provide to the RAN a report containing WLAN signal level measurements for the WLANs which are considered by the UE as well as a related WLAN identifier. The UE may reports e.g. the X strongest cells, where the value X is configurable by the RAN node(s). Hence this principle may apply the WLAN measurements, i.e. the UE would report the X strongest WLANs.

It may also be considered that, if available, the UE also includes the BSS load in the measurement report. Note that BSS load is given as an integer value from 0 to 255.

Measurement report example is shown below:

WLAN identifier Signal indication BSS load

BSSID Y -60 dBm / "High" 212

BSSID X -70 dBm / 20

"Medium"

BSSID Z -75 dBm / 104

"Medium"

Hence, the RAN node(s) may then take into account the WLAN measurement report when deciding suitable parameters for this UE. WLAN (or Wifi) identifiers

To support the case when ANDSF is not present it may be necessary that the RAN may provide to the UE so called WLAN identifiers. These WLAN identifiers are used to indicate to the UE which WLANs the UE should apply the thresholds to, for example to avoid that the UE applies the thresholds to WLANs which the network operator does not intend to offload to, e.g. WLANs not under control of the operator.

Examples of WLAN identifiers are SSID, BSSID, HESSID, etc.

As discussed earlier an ANDSF parameter may be sent to the UE and is intended to be used in the UE's ANDSF policy. When the threshold(s) indicate that the UE should offload to WLAN the UE would feed this parameter to the ANDSF entity and the parameter may be considered in the ANDSF policy, as described previously.

For the access selection, the UE may perform access network selection based on rules defined in the e.g. 3GPP RAN-specifications for connected mode and/or idle mode. The rules may consider the 3GPP signal thresholds and WLAN signal thresholds provided by RAN node(s). The RAN rules may apply to the WLANs which matches the WLAN identifier provided by RAN, for example if the RAN has indicated a BSSID to the UE, the UE only needs to apply the procedure to WLANs with has this BSSID.

Rule examples are shown below to better understand some example embodiments herein.

Example 1 : Rule example for steering to WLAN. if measured3gppSignal <

threshold3GPPSignalLow AND

measuredWlanSignal >

thresholdWlanSignalHigh {

goToWlan ( )

} Example 2: Rule example for steering to 3GPP.

if measured3gppSignal

>

threshold3GPPSignalHigh OR

measuredWlanSignal

<

thresholdWlanSignalLow {

goTo3gpp ( )

}

If the RAN node(s) finds it suitable, for example based on a WLAN measurement report from the UE that a particular UE does not move to WLAN it would be possible for the RAN to provide thresholds such that the UE does not move to WLAN. This may for example be achieved by setting the thresholds as below. It is also possible to "push" a UE to WLAN by setting the thresholds in the opposite direction: threshold3GPPSignalLow = - Infinity

thresholdWlanSignalHigh = Infinity

threshold3GPPSignalHigh = - Infinity

thresholdWlanSignalLow = Infinity

Upon fulfilment of the rules, i.e. rule may indicate "Go To WLAN" or "goTo 3gpp", and hence the UE may route traffic over WLAN or 3GPP respectively. The UE would when the rules indicate "goTo Wlan" feed the ANDSF-parameter to the ANDSF entity to be considered in the ANDSF policy.

Traffic routing

When the RAN rules indicate "Go To Wlan" the UE should route traffic over WLAN. How to decide which traffic is routed over WLAN and which traffic is routed over 3GPP depend on whether or not the UE has a valid ISRP rule for the WLAN the UE has connected to. These two exemplary cases are described in the below two subsection.

When the RAN rules indicate "Go To 3gpp" the UE should route the traffic over 3GPP.

With ISRP

If the UE has a valid ISRP rule for the WLAN which the UE has connected to the UE applies the ISRP rule when doing traffic routing. The UE should have fed the ANDSF parameter to the ANDSF entity so that the parameter may be considered in the ISRP rule. It should be noted that this RAN signaled ANDSF-parameter may be changed dynamically by the RAN, e.g. to activate another part of the UE's ANDSF policy.

Without ISRP

If the UE does not have a valid ISRP for the WLAN which the UE is connected to the UE would perform traffic routing according to RAN signaled traffic identifiers. For example, the RAN node(s) may have indicated to the UE that a bearer which contains voice services should not be routed over WLAN and the UE would then route voice over 3GPP.

Several advantages are achieved in addition the ones described above. For example:

A dynamic and flexible way for operators to control/support their users and distribute traffic among the different access networks.

A possibility to consider the performance of both individual UE as well as the overall network A possibility to set user specific policies (e.g. depending on user profile, terminal capability, current UE state, etc.).

A possibility to set policies that are coherent with the current state of the network (load conditions, operating mode, etc.). A possibility to do so, without explicitly revealing the current state of the network (such as load), as the reason behind the policy rules and indexes are only known at the network

A possibility to control/support/steer UEs that are IDLE in the 3GPP network

Referring to Figure 11 , there is provided yet another example illustrating some exemplary actions herein performed by a network node. In this example the RAN network node first creates or defines 1 1 10 a set of (ANDSF) policies for a UE (or group of UEs if it is suitable that multiple UEs use the same policy set). The network node assigns 1 120 an index to the policies in the policy set which can be used in later steps to indicate to the UE which policy within a policy set the UE should use. During these two steps the network node is configured to consider, as input, network specific information 1 180 and UE specific information 1 170 when assigning the policy sets and indexes. Example of such information can include static capability and subscription information as well as dynamic information about the performance of the network (transport, radio) and ongoing UE services, changing radio conditions, mobility etc. as previously described. Once the network has assigned this policies and their associated indexes it will send 1 130 this information to the terminal as a part of the access selection policies. The network node may then determine the index of the "suitable" policy 1 150 which is then indicates 1 160 to the UE the index of the suitable policy. The network will then in a more dynamic fashion steer the UE by sending updated values of the index to the UE. Also this process will consider network and UE parameters.

Referring to Figure 12, there is illustrated the main steps summarizing a method performed by a network node for providing ANDSF policies to at least one UE for access selection, in accordance with previously described embodiments. As shown, the method comprises:

Defining 1210 sets of ANDSF policies for said at least one UE;

Assigning 1220 for each ANDSF policy set a policy index;

Sending 1230, to the at least one UE, the sets of ANDSF policies and the assigned policy indices; and

Selecting and sending 1240 a policy index to the at least one UE informing the at least one UE which ANDSF policy set to select among the sets of ANDSF policies.

According to an embodiment and as previously described the method comprises, the network node sending the policy index to the UE in a broadcasting fashion or in a unicast fashion by means of e.g. RRC signaling. According to an embodiment, selecting a policy index by the network node is based on one or more of: an air interface load, a backhaul load. Additional examples have already been described and are not repeated again.

Figure 13 shows yet another exemplary embodiment of actions performed by a UE. In this example the UE receives 1310 a set of policies for access selection from the network node where the policies are associated with different values of one or more indexes. In addition the UE receives 1320 from the network node one or more index value as a separate message. The UE acts accordingly to the policies which match the index value received from the network node also considering as input UE information about radio conditions, capabilities, services etc. 1340. This is shown in 1330 where the UE performs access selection and traffic steering according to the policies indicated by the index.

Several of the techniques and methods described above may be implemented using radio circuitry and electronic data processing circuitry provided in a terminal. Figure 14 illustrates features of an example terminal 1500 according to several embodiments of the present disclosure. Terminal 1500, which may be a UE configured for operation with an LTE network (E- UTRAN) and that also supports Wifi, for example, comprises a transceiver unit 1520 for communicating with one or more base stations as well as a processing circuit 1510 for processing the signals transmitted and received by the transceiver unit 1520. Transceiver unit 1520 includes a transmitter 1525 coupled to one or more transmit antennas 1528 and receiver 1530 coupled to one or more receiver antennas 1533. The same antenna(s) 1528 and 1533 may be used for both transmission and reception. Receiver 1530 and transmitter 1525 use known radio processing and signal processing components and techniques, typically according to a particular telecommunications standard such as the 3GPP standards for LTE. The transmitter unit 1525 may comprise separate radio and/or baseband circuitry for each of two or more different types of radio access network, such as radio/baseband circuitry adapted for E- UTRAN access and separate radio/baseband circuitry adapted for Wifi access. The same applies to the antennas - while in some cases one or more antennas may be used for accessing multiple types of networks, in other cases one or more antennas may be specifically adapted to a particular radio access network or networks. Because the various details and engineering tradeoffs associated with the design and implementation of such circuitry are well known and are unnecessary to a full understanding of the invention, additional details are not shown here.

According to embodiments herein, the receiver unit/circuit 1530 is configured to receive, from a network node, a policy index, informing the UE or terminal 1500 which ANDSF policy set to be used by the UE; the UE having stored in data storage 1555 or memory 1550 sets of ANDSF policies and associated policy indices, each policy index identifying a ANDSF policy set. As shown, the terminal or UE 1500 further comprises a processing circuit 1510 which is configured to select an ANDSF policy from the ANDSF policy set identified by the received policy index and the processing circuit 1510 is further configured to select an access network based on at least the selected ANDSF policy. The processing circuit 1510 is further configured to select the access network based on a state of the terminal or UE as connection status, ongoing traffic and UE profile as previously described. The processing circuit 1510 is further configured to select between Wifi access network and a 3GPP access network.

The processing circuit 1510 is shown comprising one or more processors 1540 coupled to one or more memory devices 1550 that make up the data storage memory 1555 and a program storage memory 1560. Processor 1540, identified as CPU 1540 in Figure 14, may be a microprocessor, microcontroller, or digital signal processor, in some embodiments. More generally, processing circuit 1510 may comprise a processor/firmware combination, or specialized digital hardware, or a combination thereof. Memory 1550 may comprise one or several types of memory such as read-only memory (ROM), random-access memory, cache memory, flash memory devices, optical storage devices, etc. Because terminal 1500 supports multiple radio access networks, processing circuit 1510 may include separate processing resources dedicated to one or several radio access technologies, in some embodiments. Again, because the various details and engineering tradeoffs associated with the design of baseband processing circuitry for mobile devices are well known and are unnecessary to a full understanding of the application, additional details are not shown here.

Typical functions of the processing circuit 1510 may further include modulation and coding of transmitted signals and the demodulation and decoding of received signals. In several embodiments of the present application, processing circuit 1510 is adapted, using suitable program code stored in program storage memory 1560, for example, to carry out one of the techniques described above and presented in the claims for access network selection. Of course, it will be appreciated that not all of the steps of these techniques are necessarily performed in a single microprocessor or even in a single module.

Similarly, several of the techniques and processes described above may be implemented in a network node, such as an eNodeB. Figure 15 is a schematic illustration of a network node 1 in which a method embodying any of the presently described network-based techniques may be implemented. A computer program for controlling the node 1 to carry out a method embodying the present application is stored in a program storage 30, which comprises one or several memory devices. Data used during the performance of a method embodying the present application is stored in a data storage 20, which also comprises one or more memory devices. During performance of a method embodying the present application, program steps are fetched from the program storage 30 and executed by a Central Processing Unit (CPU) 10, retrieving data as required from the data storage 20. Output information resulting from performance of a method embodying the present application may be stored back in the data storage 20, or sent to an Input/Output (I/O) interface 40, which includes a network interface for sending and receiving data to and from other network nodes and which may also include a radio transceiver for communicating with one or more terminals. The network node 1 is configured to define sets of ANDSF policies for at least one UE or terminal. This may be performed by the processing unit 10. The network node 1 is further configured to assign for each ANDSF policy set an policy index. This may also be performed by the processing unit 10. The network node 1 is further configured to send to the at least one UE, the sets of ANDSF policies and the assigned policy indices. This may be performed by the I/O interface 40 which may be connected to one or several antennas. The network node 1 is further configured to select, by means of the processing unit 10, a policy index and to send, by means of I/O interface 40, the selected policy index to the at least one UE informing the UE which ANDSF policy set to select among the sets of ANDSF policies. As previously described, the sending of the policy index may be performed in a broadcast or unicast fashion. This may also be the case when the sets of ANDSF policies and the assigned policy indices are send to the at least one UE. The network node 1 may make use of RRC signaling for send the policy index. Selection of the policy index to send to the at least one UE may be based on one or more of: an air interface load, a backhaul load.

It should be noted that in various embodiments of the application, processing circuits, such as the CPU 10 in Figure 15, are configured to carry out one or more of the techniques described in detail above. Likewise, other embodiments include radio network controllers including one or more such processing circuits. In some cases, these processing circuits are configured with appropriate program code, stored in one or more suitable memory devices, to implement one or more of the techniques described herein. Of course, it will be appreciated that not all of the steps of these techniques are necessarily performed in a single microprocessor or even in a single module.

As mentioned earlier, some key advantages of the techniques and apparatus described above are that several embodiments provide for example: A dynamic and flexible way for operators to control/support their users and distribute traffic among the different access networks. A possibility to consider the performance of both individual UE as well as the overall network. A possibility to set user specific policies (e.g. depending on user profile, terminal capability, current UE state, etc.). A possibility to set policies that are coherent with the current state of the network (load conditions, operating mode, etc.). A possibility to do so, without explicitly revealing the current state of the network (such as load), as the reason behind the policy rules and indexes are only known at the network. A possibility to control UEs that are IDLE in the 3GPP network.

It will be appreciated by the person of skill in the art that various modifications may be made to the above described embodiments without departing from the scope of the present application. For example, it will be readily appreciated that although the above embodiments are described with reference to parts of a 3GPP network, an embodiment of the present application will also be applicable to like networks, such as a successor of the 3GPP network, having like functional components. Therefore, in particular, the terms 3GPP and associated or related terms used in the above description and in the enclosed drawings and any appended claims now or in the future are to be interpreted accordingly.

Examples of several embodiments of the present application have been described in detail above, with reference to the attached illustrations of specific embodiments. Because it is not possible, of course, to describe every conceivable combination of components or techniques, those skilled in the art will appreciate that the present application may be implemented in other ways than those specifically set forth herein, without departing from essential characteristics of the application. The present embodiments are thus to be considered in all respects as illustrative and not restrictive.

Claims

1 . A method implemented in a user equipment, UE, (1500) for network access selection, the method comprising:

- receiving (510), from a network node (1), a policy index; informing the UE which Access Network Discovery and Selection Function, ANDSF, policy set to be used by the UE; the UE having stored sets of ANDSF policies and associated policy indices, each policy index identifying a ANDSF policy set;

-selecting (520) an ANDSF policy from the ANDSF policy set identified by the received policy index; and

- selecting (530) an access network based on at least the selected ANDSF policy.

2. The method according to claim 1 wherein selecting (530) an access network is further based on a state of the UE such as connection status, ongoing traffic and UE profile.

3. The method according to claim 1 or claim 2 wherein selecting (530) an access network comprises selecting between a Wifi access network and a 3GPP access network.

4. A method implemented in a network node (1), for providing Access Network Discovery and Selection Function, ANDSF, policies to at least one user equipment, UE, (1500) for access selection, the method comprising:

- defining (1210) sets of ANDSF policies for said at least one UE;

- assigning (1220) for each ANDSF policy set, an policy index;

- sending (1230), to the at least one UE, the sets of ANDSF policies and the assigned policy indices; and - selecting and sending (1240) a policy index to the at least one UE informing the UE which ANDSF policy set to select among the sets of ANDSF policies.

5. The method according to claim 4 wherein said sending (1240) a policy index comprises broadcasting the policy index to the at least one UE.

6. The method according to claim 4 wherein sending (1240) a policy index comprises unicasting the policy index to the at least one UE using radio resource control, RRC, signaling.

7. The method according to claim 4 wherein selecting (1240) a policy index is based on one or more of: an air interface load, a backhaul load.

8. A user equipment, UE, (1500) for network access selection, the UE comprising:

- a receiver unit (1530) configured to receive, from a network node, a policy index; informing the UE which Access Network Discovery and Selection Function, ANDSF, policy set to be used by the UE; the UE having stored in a data storage (1555) sets of ANDSF policies and associated policy indices, each policy index identifying a ANDSF policy set;

- a processing circuit (1510) configured to select an ANDSF policy from the ANDSF policy set identified by the received policy index; and the processing circuit (1510) is further configured to select an access network based on at least the selected ANDSF policy.

9. The user equipment (1500) according to claim 8 wherein the processing circuit (1510) is further configured to select the access network based on a state of the UE such as connection status, ongoing traffic and UE profile.

10. The user equipment (1500) according to claim 8 or claim 9 wherein the processing circuit (1500) is configured to select between a Wifi access network or a 3GPP access network.

1 1 . A network node (1), for providing Access Network Discovery and Selection Function, ANDSF, policies to at least one user equipment, UE, for access selection, the network node being configured to:

- define sets of ANDSF policies for said at least one UE;

- assign for each ANDSF policy set, an policy index;

- send, to the at least one UE, the sets of ANDSF policies and the assigned policy indices; and

- select and sending a policy index to the at least one UE informing the UE which ANDSF policy set to select among the sets of ANDSF policies.

12. The network node according to claim 1 1 is configured to send the policy index by broadcasting the policy index to the at least one UE.

13. The network node according to claim 1 1 is configured to send the policy index by unicasting the policy index to the at least one UE using radio resource control, RRC, signaling.

14. The network node according to anyone of claims 1 1 -13 is configured to select the policy index is based on one or more of: an air interface load, a backhaul load.