WO2016122369A1

WO2016122369A1 - Throughput reporting from wlan to a 3gpp network

Info

Publication number: WO2016122369A1
Application number: PCT/SE2015/051356
Authority: WO
Inventors: Angelo Centonza; Icaro L. J. Da Silva; Gino Luca Masini
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2015-01-30
Filing date: 2015-12-16
Publication date: 2016-08-04

Abstract

A WLAN AP reports throughput predictions and measurements to a 3GPP node, possibly including throughput measurements per incoming UE. Embodiments described herein reduce the amount of information that needs to be reported via the inter-node interface from potential target WLAN APs to source eNBs, because the WLAN reports a throughput prediction that can be used by the eNB to take traffic steering decisions. The embodiments can also be used to enhance traffic steering decisions from eNodeB to WLAN, based on the fact that the eNodeB is able to compare what throughput is predicted with what throughput is subsequently achieved.

Description

THROUGHPUT REPORTING FROM WLAN TO A 3GPP NETWORK

TECHNICAL FIELD

The present invention generally relates to communication networks, and particularly relates to carrier aggregation involving unlicensed frequency bands.

BACKGROUND

Operators of mobile networks are today primarily taking advantage of wireless local-area networks (WLANs), such as Wi-Fi networks, simply to offload traffic from the mobile networks. However, the opportunity to improve end user experience regarding performance is also becoming more important. To date, these opportunities are complicated by the fact that current Wi-Fi deployments are typically totally separate from mobile networks, and are to be seen as non-integrated.

The usage of Wi-Fi is mainly driven due to the free and wide unlicensed spectrum, and the increased availability of Wi-Fi in mobile terminals like smartphones and tablets. The end users are also becoming more and more at ease with using Wi-Fi, for example, at offices and homes. The different business segments for Wi-Fi with integration possibilities can be divided into models based on mobile-operator-hosted/controlled Wi-Fi access points (APs) and models based on third-party-hosted/controlled Wi-Fi APs. For example, a third party is seen as any entity other than the mobile operator that is not trusted by the mobile operator. A third party could be, for example a commercial Wi-Fi network operator, or even an end-user him/herself. Note that in both of the business models referred to above, there can exist public/hotspot, enterprise and residential deployments.

The members of the 3rd-Generation Partnership Project (3 GPP) have specified mechanisms for WLAN/3GPP Radio interworking. These mechanisms improve operator control with respect to how a wireless terminal, such as a user equipment (UE) in 3 GPP documentation, performs access selection and traffic steering between 3 GPP and WLANs belonging to the mobile network operator or its partners. It may even be the case that the specified mechanisms can be used for other, non-operator, WLANs as well, although this is not the main target of the specifications. 3 GPP is currently specifying mechanisms for access selection and/or traffic steering between 3 GPP networks and WLAN. These mechanisms are described in the 3 GPP document 3GPP TS 36.300 vl2.2.0 (June 2014), which is available at http://www.3gpp.org. An excerpt from 3GPP TS 36.300, reformatted with references removed, provides a simplified description of this mechanism:

23.6.1 General principles

This version of the specification supports E-UTRAN assisted UE based bi-directional traffic steering between E-UTRANand WLAN for UEs in RRC IDLE and RRC CONNECTED.

E-UTRAN provides assistance parameters via broadcast and dedicated RRC signalling to the UE. The RAN assistance parameters may include E-UTRAN signal strength and quality thresholds, WLAN channel utilization thresholds, WLAN backhaul data rate thresholds, WLAN signal strength and quality thresholds and Offload Preference Indicator (OPI). E-UTRAN can also provide a list of WLAN identifiers to the UE via broadcast signalling. WLANs provided by E-UTRAN may include an associated priority.

The UE uses the RAN assistance parameters in the evaluation of: Traffic steering rules defined in TS 36.304; orANDSF policies defined in TS 24.312 for traffic steering decisions between E-UTRANand WLAN as specified in TS 23.402. The OPI is only used in ANDSF policies as specified in TS 24.312. WLAN identifiers are only used in traffic steering rules defined in TS 36.304.

If the UE is provisioned with ANDSF policies it shall forward the received RAN assistance parameters to upper layers, otherwise it shall use them in the traffic steering rules defined in section 23.6.2 and TS 36.304. The traffic steering rules defined in section 23.6.2 and TS 36.304 are applied only to the WLANs of which identifiers are provided by the E-UTRAN.

The UE in RRC CONNECTED shall apply the parameters obtained via dedicated signalling if such have been received from the serving cell; otherwise, the UE shall apply the parameters obtained via broadcast signalling.

The UE in RRC IDLE shall keep and apply the parameters obtained via dedicated signalling, until cell reselection or a timer has expired since the UE entered RRC IDLE upon which the UE shall apply the parameters obtained via broadcast signalling. In the case of RAN sharing, each PLMN sharing the RAN can provide independent sets of RAN assistance parameters.

23.6.2 Access network selection and traffic steering rules

The UE indicates to upper layers when (and for which WLAN identifiers along with associated priorities, if any) access network selection and traffic steering rules defined in TS

36.304 are fulfilled. The selection among WLAN APs that fulfill the access network selection and traffic steering rules is up to UE implementation.

When the UE applies the access network selection and traffic steering rules defined in TS 36.304, it performs traffic steering between E-UTRAN WLAN with APN granularity.

User preference takes precedence (FFS whether it does not apply to particular scenarios).

Below is a more detailed description of the access network selection and traffic steering rules. This is a re-formatted version of what can be found in 3GPP TS 36.304, vl2.3.0 (January 2015): 5.6 RAN-assisted WLAN interworking

The purpose of this procedure is to facilitate RAN-assisted WLAN interworking.

5.6.1 RAN assistance parameter handling in RRC IDLE

RAN assistance parameters may be provided to the UE in

SystemInformationBlockTypel7 or in the RRCConnectionReconfiguration message. RAN assistance parameters are used only if the UE is camped normally.

Upon T350 expiry or upon selection/reselection of a cell which was not the PCell when RAN assistance parameters were received in the RRCConnectionReconfiguration message, the UE shall discard the RAN assistance parameters received in the RRCConnectionReconfiguration message and apply the RAN assistance parameters received in SystemLnformationBlockType 17. Note that in RRC CONNECTED, upon cell selection initiated by RRC connection re- establishment, the UE does not discard RAN assistance parameters received in the

RRCConnectionReconfiguration message.

The upper layers in the UE shall be notified (see TS 24.302) whenever changes in the current RAN assistance parameters occur, if upper layers require so.

5.6.2 Access network selection and traffic steering rules The rules in this sub-clause are only applicable for WLAN for which an identifier has been signaled to the UE by E-UTRAN and the UE is capable of access network selection and traffic steering rules. Coexistence with ANDSF based WLAN selection and traffic

steering methods on the UE is based on mechanism described in TS 23.402. The rules refer to the following quantities:

Table 1

The upper layers in the UE shall be notified (see TS 24.302) when and for which WLAN identifiers (part of the list in subclause 5.6.3) the following conditions 1 and 2 for steering traffic from E-UTRAN to WLAN are satisfied for a time interval Tsteeringw∑AN-^'

1. In the E-UTRAN serving cell:

RSRPmeas < ThreshservingOffloadwiAN, LOWP_: or

RSRQmeas < Thresh servmgOffloadwiAN,

2. In the target WLAN:

ChannelUtilizationWLAN < ThreshchutuwiAN, Low,^' and BackhaulRateDlWLAN > ThreshBackhRateDLWLAN, mgh,^' and Backhaul RateUlWLAN > Thresh_BackhRateULivuM. High, and

BeaconRSSI > ThreshBeaconRssiwiAN, High.

The UE shall not consider the metrics for which a threshold has not been provided. The UE shall evaluate the E-UTRAN conditions on PCell only. If not all metrics related to the provided thresholds can be acquired for a WLAN BSS, the UE shall exclude that WLANBSS from the evaluation of the above rule.

The upper layers in the UE shall be notified (see TS 24.302) when the following conditions 3 or 4 for steering traffic from WLAN to E-UTRAN are satisfied for a time interval

TsteeringwLAN-^'

3. In the source WLAN:

ChannelUtilizationWLAN > ThreshchutnwLAN, High! or

BackhaulRateDlWIAN < ThreshBackhRateDLWLAN, Low,^' or Backhaul RateUlWLAN ThreshBackhRateULWLAN. Low; or BeaconRSSI < Thresh BeaconRssiwuN, Low

4. In the target E-UTRAN cell:

RSRPmeas > Thresh_SerVingOffloadWLAN, HighP; and

RSRQmeas > Thresh servingOfjioadWLAN, _ghQ.

The UE shall not consider the metrics for which a threshold has not been provided. The UE shall evaluate the E-UTRAN conditions on PCell only.

5.6.3 RAN assistance parameters definition

The following RAN assistance parameters for RAN -assisted WLAN interworking may be provided:

Thresh ServingOffloadWLAN, LowP

This specifies the RSRP threshold (in dBm) used by the UE for traffic steering to from E- UTRAN to WLAN.

ThreshservingOffloadWLAN, HighP

This specifies the RSRP threshold (in dBm) used by the UE for traffic steering from WLAN to E-UTRAN

ThreshservingOffloadWLAN,

This specifies the RSRQ threshold (in dB) used by the UE for traffic steering from E- UTRAN to WLAN. ThreshservingOffloadWLAN, HighQ

This specifies the RSRQ threshold (in dB) used by the UE for traffic steering from WLAN to E-UTRAN

ThreshchutuwLAN, Low

This specifies the WLAN channel utilization (BSS load) threshold used by the UE for traffic steering from E-UTRAN to WLAN

ThreshchUtilWLAN, High

This specifies the WLAN channel utilization (BSS load) threshold used by the UE for traffic steering from WLAN to E-UTRAN.

TfiresflBackhRateDL WLAN, Low

This specifies the backhaul available downlink bandwidth threshold used by the UE for traffic steering from WLAN to E-UTRAN.

ThreshBackhRateDLWLAN, High

This specifies the backhaul available downlink bandwidth threshold used by the UE for traffic steering from E-UTRAN to WLAN.

TfiresflBackhRateUL WLAN, Low

This specifies the backhaul available uplink bandwidth threshold used by the UE for traffic steering from WLAN to E-UTRAN.

TfiresflBackhRateULWLAN, High

This specifies the backhaul available uplink bandwidth threshold used by the UE for traffic steering from E-UTRAN to WLAN.

ThreshseaconRSSLWLAN, Low

This specifies the Beacon RSSI threshold used by the UE for traffic steering from WLAN to E-UTRAN.

ThreshseaconRSSLWLAN, High

This specifies the Beacon RSSI threshold used by the UE for traffic steering from E-

UTRANto WLAN.

TsteeringwLAN

This specifies the timer value Tsteeringw_LAN during which the rules should be fulfilled before starting traffic steering between E-UTRAN and WLAN. WLAN identifiers

Only the SSIDs, BSSIDs and HESSIDs which are provided in this parameter shall be considered for traffic steering between E-UTRAN and WLAN based on the rules in this subclause.

As discussed above, 3 GPP is specifying a network-assisted WLAN interworking mechanism for Release 12 of the 3 GPP specifications. However, a fully network-controlled solution may be specified. A fully network-controlled WLAN/3GPP interworking solution follows principles similar to CONNECTED mode operations in 3 GPP, where a few main steps are employed for traffic steering. These steps are illustrated in Figure 1 and described below.

1. Measurement control configuration: The 3GPP radio access network (RAN) sends information to the UE that includes details such as the target WLAN(s) to be measured (e.g., specific identities, such as SSIDs/BSSIDs/HESSIDs, or more general information like operating frequencies), events/thresholds for triggering measurement reports (e.g., when WLAN signal becomes better/worse than a certain threshold, WLAN signal becomes better/worse than a certain threshold and 3GPP signal becomes worse/better than another threshold, etc.).

2. Measurement reporting: When the conditions for triggering thresholds, as configured in Step 1 above, are fulfilled, the UE sends a measurement report to the 3 GPP RAN.

3. Traffic steering: Based on the measurement report received in Step 2, the RAN evaluates the received measurements and other relevant information obtained in eNB/RNC and as a result of this sends a traffic steering command to the UE, which can specify the traffic to be steered. This can include an explicit indication of each bearer to be moved (i.e., by specifying data radio bearer IDs or DRB/RB-IDs) or can include a more general indication of which bearers are to be moved, such as a quality-of-service (QoS) Class Identifier (QCI), which can apply to many bearers at once.

4. UE ACK/Response: In this step, the UE indicates to the RAN whether or not the action dictated by the traffic steering command was successfully performed or not.

UEs in IDLE mode can request to setup a Radio Resource Control (RRC) connection for the sake of sending measurement reports when the conditions of Step 1 are satisfied.

Alternatively, Steps 1 or 2, which are equally applicable to both IDLE and CONNECTED UEs, might be employed for handling IDLE UEs, while Step 3 is used only for CONNECTED UEs. Another possibility for 3GPP/Wi-Fi interworking can be referred to as "3GPPAVLAN joint coordination." A study item (SI) entitled "Multi-RAT Joint Coordination" was started in the 3 GPP TSG RAN3 working group. (See the 3 GPP document 3 GPP TR 37.870, available at www.3gpp.org) At the RAN3 #84 meeting, the scope and requirements for the Multi-RAT Joint Coordination SI were further defined. (See, 3 GPP TSG-RAN3 Meeting #84, "Way Forward on Multi-RAT Joint Coordination," Seoul, Korea, May 19-23, 2014.) In particular, for the 3GPP- WLAN coordination part, it was agreed to focus on non-integrated 3GPP/WLAN nodes, since integrated nodes are a matter of implementation.

Potential enhancements of RAN interfaces and procedures to support joint operation among different radio access technologies (RATs), including WLAN, have been studied. It has also been agreed that: i) the coordination involving WLAN and 3 GPP is in the priority of the study item, and ii) the statements on 3GPP/WLAN coordination must be complementary to RAN2 work. This complement could be achieved by the specification of an interface between the E-UTRAN and WLAN. The main functionality so far envisioned for this interface is the support for traffic steering from Long-Term Evolution (LTE) networks to WLAN, via the reporting of different sets of information from WLAN to the eNodeB (the base station in LTE networks) so that educated steering decisions can be taken.

A list of WLAN parameters useful to be exchanged from the WLAN to the eNodeB may be seen, in fact, as the basis of such a specification. Some of these parameters are listed below:

BSS load: The BSS load element defined in IEEE Std 802.11™-2012, IEEE Standard for Information technology-Telecommunications and information exchange between systems-Local and metropolitan area network, contains three metrics: station count, channel utilization, and the available admission control.

The STA Count field is interpreted as an unsigned integer that indicates the total number of STAs currently associated with this BSS.

The Channel Utilization field is defined as the percentage of time, linearly scaled with 255 representing 100%, that the AP sensed the medium was busy, as indicated by either the physical or virtual carrier sense (CS) mechanism. When more than one channel is in use for the BSS, the Channel Utilization field value is calculated only for the primary channel. The Available Admission Capacity field is 2 octets long and contains an unsigned integer that specifies the remaining amount of medium time available via explicit admission control, in units of 32 μβ/β. The field is helpful for roaming STAs to select an AP that is likely to accept future admission control requests, but it does not represent an assurance that the HC admits these requests.

WAN metrics: WAN metrics defined in Wi-Fi Alliance® Technical Committee, Hotspot 2.0 Technical Task Group Hotspot 2.0 (Release 2) Technical Specification Version 3.11, includes the Downlink/Uplink speed and the Downlink/Uplink load, as follows:

The Downlink Speed is a 4-octet positive integer whose value is an estimate of the WAN Backhaul link current downlink speed in kilobits per second. For backhaul links that do not vary in speed or those for which no accurate estimation can be made, this attribute contains the nominal speed.

The Uplink Speed is a 4-octet positive integer whose value is an estimate of the WAN Backhaul link's current uplink speed in kilobits per second. For backhaul links that do not vary in speed or those for which no accurate estimation can be made, this attribute contains the nominal speed.

The Downlink Load is a 1 -octet positive integer representing the current percentage loading of the downlink WAN connection, scaled linearly with 255 representing 100%, as measured over an interval the duration of which is reported in Load Measurement Duration.

The Uplink Load is a 1 -octet positive integer representing the current percentage loading of the uplink WAN connection, scaled linearly with 255 representing 100%, as measured over an interval the duration of which is reported in Load Measurement Duration.

Besides, it is noted that the backhaul available downlink bandwidth can be calculated as the Downlink Speed * (1 - Downlink Load/255). And the backhaul available uplink bandwidth is defined similarly. The current backhaul speed/load or available bandwidth may limit the expected throughput for a new coming UE.

UE average throughput (data rate) in WLAN APs: The UE average data rate in WLAN APs may calculate on downlink and uplink separately. For downlink, the UE average data rate in an AP may be calculated as total data successfully sent out by the AP, dividing the UE numbers and dividing the monitoring time. The calculation of uplink average data rate is similar. Besides, this metric may be calculated in different RCPI/RSNI level and in different ACs for QoS APs.

The AP divides reported Received Channel Power Indicator/Received Signal to Noise Indicator (RCPI/RSNI) into several levels. For STAs that belong to the same level of

RCPI/RSNI, the AP calculates the average data rate separately. The RAN may compare the UE average data rate of each AP with the throughput obtained in the serving cell to determine if the AP is a candidate for offloading. This metric may be collected correlated with the RCPI/RSNI. The above WLAN metrics are not exhaustive and can be extended if needed.

The solutions for 3GPP/WLAN joint coordination discussed in RAN3 consider the possibility that the above parameters are used by an eNodeB to predict what the data rates in the WLAN AP would be, compared to the currently achieved data rates in LTE, i.e., to predict whether any improvement in data rates would arise from steering the UE from LTE to WLAN. Based on this comparison, QoS-based steering decisions can be taken. In order to perform this prediction the eNodeB must be informed about a set of parameters pi ... pN from the WLAN AP, regarding each specific UE, in order to take proper decisions. It has also been argued that in order to improve the decisions at the eNodeB about when bring to UEs back (i.e., to steer the UEs from WLAN to LTE ), the UE average data rates measured at the WLAN APs should also be reported after traffic steering from LTE to WLAN. This is illustrated in Error! Reference source not found. 2.

Under this assumption, that the eNodeB performs a prediction of the UE throughput on WLAN, one of the goals of the Study Item concerning this use case is to agree on exactly which WLAN parameters are important to be reported to the eNodeBs, so that the prediction of UE throughput in WLAN can be performed properly.

SUMMARY

Existing solutions for 3GPP/WLAN joint coordination consider the prediction of UE throughput in WLAN at the eNodeB, relying on information reported from neighbor WLAN APs. Different vendors may have their own proprietary algorithms for the prediction, with each relying on different sets of information that should be reported from WLAN to 3 GPP. The consequence of this is that a large part of the reported information might be seen as non- essential. Therefore, the current solution might lead to the reporting of lots of useless information over the inter-node interface from the WLAN APs and the eNB.

An alternative could be to report a minimum set of essential information. However, different equipment vendors would certainly have different opinions on which information was "essential." In that case, the compromises that would be necessary would likely result in some implementations lacking the information that the equipment designers would prefer to have available.

Described in detail below are techniques whereby a WLAN AP reports throughput predictions and measurements to a 3 GPP node, possibly including throughput measurements per incoming UEs. The approaches described below reduce the amount of information that needs to be reported via the inter-node interface from potential target WLAN APs to source eNBs, compared to existing solutions being discussed in RAN3. This reduction arises from the fact that the WLAN reports a throughput prediction, so that the eNB is able to take traffic steering decisions. In addition, the mechanisms detailed below can be used to enhance traffic steering decisions from eNodeB to WLAN, based on the fact that the eNodeB is able to compare what is promised (the predicted throughput) with what is subsequently achieved, in terms of throughput.

According to some embodiments, a method, in one or more nodes of a wide-area cellular network, includes measuring a throughput in the wide-area cellular network for a wireless terminal and receiving, from a WLAN, an indication of a predicted throughput in the WLAN for the wireless terminal or for a group of wireless terminals including or like the wireless terminal. The method also includes comparing the measured throughput in the wide-area cellular network to the predicted throughput in the WLAN and determining whether or not to offload the wireless terminal to the WLAN, based on the comparing.

According to some embodiments, a method, in one or more nodes of a wide-area cellular network, includes measuring throughput in the wide-area cellular network for a wireless terminal and receiving, from a WLAN, an indication of a predicted throughput in the WLAN for the wireless terminal or for a group of wireless terminals including or like the wireless terminal. The method also includes evaluating one or more statistics of measured throughput in the wide-area cellular network and one or more statistics of the predicted throughput in the WLAN and determining whether or not to offload the wireless terminal to the WLAN, based on the evaluating. According to some embodiments, a method, in one or more nodes of a wide-area cellular network, includes receiving, from a WLAN AP, one or more indications of predicted throughput in the WLAN AP for a wireless terminal or for a group of wireless terminals including or like the wireless terminal. The method also includes receiving, from the WLAN AP, one or more indications of measured throughput in the WLAN for the wireless terminal or for the group of wireless terminals and evaluating a prediction accuracy for the WLAN AP, based on the received indications of predicted throughput and received indications of measured throughput.

According to some embodiments, a method, in one or more nodes of a wide-area cellular network, includes sending a request for a report from a WLAN and receiving the report indicating a predicted throughput for a wireless terminal in the WLAN or for a group of wireless terminals including or like the wireless terminal. The method also includes making an offloading decision for the wireless terminal, based on the predicted throughput indicated by the report.

According to some embodiments, a method, in one or more nodes of a wide-area cellular network, includes sending a request for a report from a WLAN and receiving the report indicating a measured throughput for a wireless terminal in the WLAN or for a group of wireless terminals including or like the wireless terminal. The method also includes making an offloading decision for the wireless terminal, based on the measured throughput indicated by the report.

According to some embodiments, an apparatus in a wide-area cellular network includes processing circuitry adapted to measure a throughput in the wide-area cellular network for a wireless terminal and receive, from a WLAN, an indication of a predicted throughput in the WLAN for the wireless terminal or for a group of wireless terminals including or like the wireless terminal. The processing circuitry is also adapted to compare the measured throughput in the wide-area cellular network to the predicted throughput in the WLAN and determine whether or not to offload the wireless terminal to the WLAN, based on the comparing.

According to some embodiments, an apparatus in a wide-area cellular network includes processing circuitry adapted to measure throughput in the wide-area cellular network for a wireless terminal and receive, from a WLAN, an indication of a predicted throughput in the WLAN for the wireless terminal or for a group of wireless terminals including or like the wireless terminal. The processing circuitry is also adapted to evaluate one or more statistics of measured throughput in the wide-area cellular network and one or more statistics of the predicted throughput in the WLAN and determine whether or not to offload the wireless terminal to the WLAN, based on the evaluating.

According to some embodiments, an apparatus in a wide-area cellular network for use in a WLAN includes processing circuitry adapted to receive, from a WLAN AP, one or more indications of predicted throughput in the WLAN AP for a wireless terminal or for a group of wireless terminals. The processing circuitry is also adapted to receive, from the WLAN AP, one or more indications of measured throughput in the WLAN for the wireless terminal or for the group of wireless terminals and evaluate a prediction accuracy for the WLAN AP, based on the received predicted throughputs and received indications of measured throughput.

According to some embodiments, a method in a node of a WLAN includes detecting a trigger event indicating that a report for at least one wireless terminal associated with a wide-area cellular network is to be sent and determining a predicted throughput for the at least one wireless terminal in the WLAN. The method also includes sending the report to a node in the wide-area cellular network, the report indicating the predicted throughput for the at least one wireless terminal in the WLAN.

According to some embodiments, a method in a node of a WLAN includes detecting a trigger event indicating that a report for at least one wireless terminal associated with a wide-area cellular network is to be sent, determining a measured throughput for the at least one wireless terminal in the WLAN and sending the report to a node in the wide-area cellular network, the report indicating the measured throughput for the at least one wireless terminal in the WLAN.

According to some embodiments, an apparatus in a WLAN includes processing circuitry adapted to detect a trigger event indicating that a report for at least one wireless terminal associated with a wide-area cellular network is to be sent and determine a predicted throughput for the at least one wireless terminal in the WLAN. The processing circuitry is also adapted to send the report to a node in the wide-area cellular network, the report indicating the predicted throughput for the at least one wireless terminal in the WLAN.

According to some embodiments, an apparatus in a WLAN includes processing circuitry adapted to detect a trigger event indicating that a report for at least one wireless terminal associated with a wide-area cellular network is to be sent and determine a measured throughput for the at least one wireless terminal in the WLAN. The processing circuitry is also adapted to send the report to a node in the wide-area cellular network, the report indicating the measured throughput for the at least one wireless terminal in the WLAN.

Of course, the present invention is not limited to the above features and advantages. Those of ordinary skill in the art will recognize additional features and advantages upon reading the following detailed description, and upon viewing the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 illustrates steps in fully network-controlled 3GPP/WLAN integration.

Figure 2 illustrates the reporting of a large set of parameters from WLAN to eNodeB, including the measured throughput after traffic steering.

Figure 3 shows an example of an evolved UMTS Terrestrial Radio Access Network (E-

UTRAN) architecture as part of an LTE-based communications system.

Figure 4 illustrates throughput prediction reporting, according to some embodiments.

Figure 5 illustrates throughput measurement reporting, according to some embodiments.

Figure 6 is a process flow diagram illustrating an example implementation of some of the techniques disclosed herein.

Figure 7 is a process flow diagram illustrating an adjustment of an outer loop of a traffic steering algorithm.

Figure 8 illustrates example information created by evaluating throughput reports and measurement reports.

Figures 9 and 10 illustrate example methods implemented in one or more nodes of a

WLAN.

Figures 11, 12, 13, 14, 15, and 16 illustrate example methods implemented in one or more nodes of a wide-area cellular network.

Figure 17 is a block diagram illustrating components of an example node in a wide-area cellular network.

Figure 18 is a block diagram illustrating components of an example node in a WLAN.

Figure 19 is a block diagram illustrating components of an example UE.

Figures 20-24 are block diagrams of example functional implementations of a node in a wide-area cellular network. Figures 25-26 are block diagrams of example functional implementations of a node in a WLAN.

DETAILED DESCRIPTION

A cell in a wide-area cellular network, such as an LTE network, is associated with a radio access network (RAN) node, where a RAN node comprises in a general sense any node transmitting radio signals in the downlink (DL) to a terminal device and/or receiving radio signals in the uplink (UL) from a terminal device. Some example RAN nodes, or terms used for describing RAN nodes, are base station, eNodeB, eNB, NodeB, macro/micro/pico/femto radio base station, home eNodeB (also known as a femto base station), relay, repeater, sensor, radio network controller (RNC), transmitting-only radio nodes or receiving-only radio nodes, WLAN Access Point (AP) or WLAN access controller (AC). A RAN node may operate or at least perform measurements in one or more frequencies, carrier frequencies or frequency bands and may be capable of carrier aggregation. It may also be a single-radio access technology (RAT), multi-RAT, or multi-standard node, e.g., using the same or different base band circuitry for different RATs. The signaling described is either via direct links or logical links (e.g., via higher layer protocols and/or via one or more network nodes). For example, signaling from a coordinating node may pass another network node, e.g., a radio node.

Figure 3 shows an example diagram of an E-UTRAN architecture as part of an LTE- based communications system 2. Nodes in the core network 4 include one or more Mobility Management Entities (MMEs) 6, a key control node for the LTE access network, and one or more Serving Gateways (SGWs) 8 which route and forward user data packets while acting as a mobility anchor. They communicate with base stations 10, which are generally referred to in LTE specifications as eNBs or eNodeBs, over an interface, for example an S 1 interface.

The eNBs 10 can include the same or different categories of eNBs, e.g. macro eNBs, and/or micro/pico/femto eNBs. The eNBs 10 communicate with each other over an interface, for example an X2 interface. The SI interface and X2 interface are defined in the LTE standard. A UE 12 can receive downlink data from and send uplink data to one of the base stations 10 with that base station 10 being referred to as the serving base station of the UE 12. A WLAN AP 14 may be part of a WLAN, although it will be appreciated that the WLAN and AP 14 are not part of the E-UTRAN architecture. As is known in the art, the UE 12 may be capable of aggregating multiple carriers from a single eNB 10 or multiple eNBs 10, and in accordance with certain embodiments, the UE 12 is capable of aggregating a carrier from the LTE network 2 with a carrier from the WLAN AP 14.

Embodiments described below include methods whereby a WLAN AP 14 signals a throughput report to an eNB 10 via an inter-node interface, perhaps through an Xw interface. According to several of these methods, these reports are signaled upon request or configuration from the same eNB 10 to which the report is sent, or from any central node. These throughput reports contain throughput predictions and/or throughput measurements. The throughput values within these reports can either be per WLAN AP 14 or per UE 12 (or UE group e.g. grouped based on capabilities). Other level of granularities are also considered e.g. per UL/DL, per UE capability group, etc. Figure 4 illustrates an example of throughput prediction reporting, while Figure 5 illustrates an example of throughput measurement reporting.

Traffic steering decisions may be improved upon using these reports. According to some embodiments, a WLAN AP 14 indicates, to a 3 GPP network node such as an eNB 10, throughput predictions (per WLAN AP node or per UE) before traffic steering from 3 GPP to WLAN occurs, i.e., before the UE 12 is connected to the WLAN. The eNB 10 may measure throughput for a UE 12. Traffic may be steered in a proper way when the eNB 10 decides whether or not to offload some of its active UEs 12 to the appropriate WLAN APs 14, based on these throughput predictions. In some cases, the measured throughput in the 3 GPP network is compared to the predicted throughput in the WLAN. In other cases, statistics of the measured throughput in the 3 GPP network and statistics of the predicted throughput in the WLAN are evaluated.

The WLAN AP 14 may indicate, to the eNB 10, throughput measurements after traffic steering from 3 GPP to WLAN occurs, i.e., after the UE 12 is connected to WLAN. Predicted accuracy for a WLAN AP 14 may then be evaluated based on the received indications.

In some cases, reports are requested from the WLAN. In other cases, reports are sent by the WLAN upon detecting a trigger event.

In the event that UEs 12 are offloaded, the WLAN AP 14 reports throughput measurements (e.g., measured data rates) per UE 12, to the source eNB 10 (or other network node). This may be done, for example, on an eNB's 10 request, or according to some pre- configuration that can be performed by the eNB 10 or by some other node, e.g., at the Operations Support System (OSS) or at the core network.

The reports sent from the WLAN to the 3 GPP network node should contain WLAN AP 14 identities, so that the eNB 10 is able to identify which AP 14 is reporting the predictions and measurements. Additionally, these reports may in some embodiments also include UE 12 identities, so that the eNB 10 or other network node can identify the UEs 12 to which the report is referring. Upon the reception of the measured throughput, outer loop adjustments are performed in the traffic steering algorithm.

It will be appreciated that being "connected" to the WLAN can mean any of several different things, as exemplified by the existence of one or more of the below conditions:

802.11 authentication (Authentication to the WLAN AP 14) has been completed or is under way;

802. lx EAP-SEVI authentication (Authentication to the AAA-servers) has been completed or is under way;

Four way hand-shake between the terminal 12 and the WLAN has been completed;

An IP address has been assigned to the terminal 12 in WLAN;

A Public Data Network (PDN) connection has been established through the WLAN, i.e., a connection between the terminal 12 and the PDN gateway has been established; or

Data traffic has been started through the WLAN.

As noted above, the techniques described herein include methods according to which a

WLAN AP 14 signals a throughput report to an eNB 10, via an inter-node interface. These reports are signaled upon request or according to a configuration from the same eNB 10 or from another central node. The following describes the content of the reports, included predicted throughputs and/or throughput measurements, and the content of the

request/configuration messages.

Throughput Predictions

In some embodiments, the throughput report signaled from a WLAN AP to a given eNodeB contains one or multiple throughput metrics related to a prediction of a maximum achievable throughput in the WLAN. These maximum achievable predictions at the WLAN AP can either: i) assume best case scenario(s) in terms of radio conditions and UE capabilities on WLAN, for the given load at the period for which report is being signaled, and thus provide single values for the predictions; or ii) provide multiple predictions for any two or more different WLAN conditions, including the WLAN conditions described above.

The aggregation (or granularity) level of these throughput prediction(s) can be per WLAN AP, in some embodiments, i.e., such that throughput is predicted based on WLAN AP- specific information such as load metrics, like channel utilization and/or the number of devices associated with the WLAN AP. The report may also contain additional information about the WLAN AP, such as a brand or model and/or a capability of the WLAN AP. Since the latter are more static information, this information could also or instead be obtained by the eNodeB via OAM procedures, or an even more static procedure.

The aggregation (or granularity) level of these throughput prediction(s) can be per UE, in some embodiments. In this case, the predictions rely on UE-specific information, such as UE capabilities in WLAN, or UE measurements (such as radio conditions), which are eventually available or estimated during WLAN association. For example, given that the prediction is supposed to help the eNodeB to gain a better understanding of whether UEs can be offloaded to the WLAN AP, the radio conditions considered may be those of UEs closer to the serving eNBs cell center. Since the reports can be per-UE or per-UE group (where a group could be based on UE capability) they may contain UE or UE group identifiers interpretable at the eNodeB.

A traffic steering algorithm at the 3 GPP network node receives these predictions as inputs to make offloading decisions. These decisions may be made according to vendor-specific implementations, in some embodiments. This algorithm may also have access to UE

measurement reports about the UE conditions in a given WLAN AP. Then, if multiple potential predictions per radio conditions intervals are signaled, the eNodeB is able to get the proper prediction for a given UE. Detailed examples are provided below.

The reporting from the WLAN can be done using a message similar to or equivalent to the X2: RESOURCE STATUS UPDATE message, defined in the 3 GPP document 3 GPP TS 36.423, v. 12.4.2 (Jan. 2015), available at http://www.3gpp.org. The reporting message is sent via the inter-node interface between WLAN and eNodeB.

The throughput reporting to the eNB can be triggered by an event, such as an association attempt of a given UE that is already associated to a given eNodeB. It may instead or also be triggered according to pre-configured schedules or conditions provided to the WLAN AP by the eNB, a core network node, or any other central node such as a node at the OSS.

A throughput report containing the predicted throughput(s) may be requested by the eNodeB. The request can be done, for example, using a message similar or equivalent to the X2: RESOURCE STATUS REQUEST message defined in 3 GPP TS 36.423, where the message is sent via the inter-node interface between WLAN and eNodeB. In some embodiments, in the event that the eNodeB wants UE-specific (or UE group -specific) predictions, the eNB sends within the request some UE identifier that is known or that can be interpreted at the WLAN AP.

A request from the eNodeB to the WLAN AP may contain UE-specific information about the conditions of that specific UE within that AP that can be obtained. These conditions may include, for example, information obtained from UE measurement reports, or static information such as the UE's capability in WLAN.

These requests can be triggered, for example, by the reception at a 3 GPP network node of a UE measurement report containing WLAN information. For example, the UE may be configured to send measurement reports to the eNodeB when the received-signal-strength indicator (RSSI) for a WLAN AP is above a certain threshold - upon the reception of these measurement reports, the eNodeB can then request one or more predictions of the maximum achievable throughput to the WLAN AP.

As noted above, the report sent from the WLAN AP to the 3 GPP network node may consist of a throughout prediction, which is sent before one or more UEs is offloaded to WLAN. Other reports, described in more detail below, may include actual throughputs for one or more UEs that are served by the AP are experiencing.

Throughput Measurements

In some embodiments, a throughput report signaled from a WLAN AP to a given eNodeB contains throughput measurements, where these measurements can be per WLAN AP or per UE. In the case of measurements per WLAN AP, the reported measurement could simply be: i) the throughput (or data rate) averaged over all the UEs served by the WLAN AP during a given time window (which window may be pre-configured by the eNodeB, in some

embodiments, or arbitrarily defined by the WLAN AP in others); ii) any set of throughput statistics within this time window, such as average and/or standard deviation and/or maximum throughput and/or minimum throughput. Either the averaged measurements or the other statistics can be grouped per WLAN conditions. In the case of throughput measurements per UE, the reported throughput can be, in various embodiments: i) an averaged throughput for that UE within a pre-defined time window; and/or ii) throughput statistic per UE, computed over a given time window.

The reporting can be done, for example, using a message similar to or equivalent to the

X2: RESOURCE STATUS UPDATE message defined in TS 36.423, and sent via the inter-node interface between WLAN and eNodeB. The throughput reporting to the eNodeB can be triggered by an event, such as a successful association to the WLAN of a given UE previously or currently active in a given eNodeB. The reporting may also be according to schedules or conditions that are pre-configured by the eNB, a core network node, or any other central node such as a node at the OSS.

The throughput report may be requested by the eNodeB, in some embodiments. This request can be sent, for example, using a message similar to or equivalent to the X2:

RESOURCE STATUS REQUEST message defined in TS 36.423, and sent via the inter-node interface between WLAN and eNodeB. Such a request may include, for example, one or more of the following: a measurement period; a request to report throughput measurements for uplink, for downlink, or both; and a throughput threshold according to which the AP reports an indication that the throughput fulfilled the threshold for the whole duration of the measurement period. These reports can be per-UE or per- UE group, where a UE group may be constituted by UEs having the same capabilities, for example, and where the request may contain information specifying reporting for the specific group. The reports may thus contain UE or UE group identifiers interpretable at the eNodeB.

Based on the reported measurements and/or statistics, the eNB may deduce information about the quality of service (QoS) received at the target WLAN AP. Also, the eNB may deduce information concerning events such as ping pong mobility between LTE and WLAN. A ping pong between LTE and WLAN can be defined as a sequence of events where the UE attaches and detaches to/from WLAN, while also moving to/from Idle and Active states in the LTE network. Note that it would still be a ping pong if the UE remained Active in LTE and attached/detached from WLAN consecutively.

By means of receiving the reported throughput information from the newly serving AP, the eNB can deduce whether the UE traffic is served via the AP and correlate such information to events where the UE traffic is served via the eNB. If the alternation and frequency of such events exceeds preconfigured values, a ping pong event may be declared.

In some embodiments, a traffic steering algorithm implemented in an eNodeB or other network node receives these measurements, processes them and performs outer loop adjustments in the traffic steering algorithm.

UE identifiers

Some of the reporting messages described above include an identifier for the wireless terminal (a UE, in 3GPP terminology). Possible identifiers include the 3 GPP cell radio-network temporary identifier (C-RNTI), the WLAN medium access control (MAC) identifier, an Internet Protocol (IP) address, and an identifier for the terminals that is shared by the 3 GPP and WLAN entities.

In some embodiments, a generic identifier for the UE may be included in the report. This identifier may be provided by the 3 GPP RAN node, e.g., the 3 GPP RAN node has indicated the generic identity to the terminal and the terminal indicates this to the WLAN AP (e.g., during the connection procedure). The WLAN AP may then use this identifier in reports sent to the 3GPP RAN. The benefit of the generic identity is that it can be terminal-specific and yet be applicable regardless of the terminal's state in 3GPP. This is not the case for the C-RNTI, for example, since the C-RNTI, while being terminal-specific in a 3 GPP cell, is released when the terminal moves from CONNECTED to IDLE mode and hence is not applicable in IDLE mode.

Enhancements to Traffic Steering

Figure 6 is a flowchart illustrating a method for enhancing traffic steering, according to some embodiments. In this example, an eNB measures the throughput (provided by the eNB) of a given UE. This measured throughput, which can be denoted Tm LTE, is then compared to reported predicted throughput received from the neighbor WLAN AP. The predicted throughput for a given UE or group of UEs, which can be denoted Tp_WLAN(i) for the z^'-th neighbor AP is received at the eNB (or other network node) via the inter-node interface, e.g., the Xw interface, according to the mechanisms described above

When the measured throughput in the LTE network is higher than the maximum predicted by any of the WLAN APs, i.e., when Tm LTE > max[7p _WLAN(i)] for any of the neighbor WLAN APs, the eNodeB performs no action to make the UE steer its traffic towards any of the WLAN AP. An offset can be included in the previous comparison, to account for measurement uncertainty and/or to provide a certain amount of hysteresis in the decision process. Indeed, the eNB may perform actions aimed at retaining the UEs, such as increasing the measurement thresholds configured at the UE for the WLAN AP signal, where such thresholds constitute the triggering point that, if achieved, would make the UE move to the WLAN AP. Otherwise, i.e., if the measured throughput is lower than the throughput predicted by one or more of the WLAN APs, the eNodeB should steer the UE to the i-t * WLAN AP, for example, where /^'*= arg max (Tp WLANfi) + delta) where delta is a defined margin. The Tm LTE measurement can be an average over a specified time period, the latest measured sample or any other representative statistic within a given time window.

The eNB can also or instead perform a comparison between the distributions of both

Tm LTE and Tp WLANfi) over a given time window, using any method of statistical distance, rather than simply comparing two single metrics.

In a variant of the above approach, an eNodeB receiving throughput prediction reports Tp WLANfi) associated to a given UE (or group of UEs) stores these reports using the AP identity (e.g., Service Set Identifier or SSID, Basic SSID or BSSID) to identify this

information later on, e.g., for use in network performance monitoring, to evaluate the prediction accuracies for a given WLAN AP, etc. The eNodeB may create an "AP context" or "AP group context" either based on capability, vendor or a combination of both. For the AP group context, the eNodeB uses information reported via the inter-node interface or via Operations, Administration and Management (OAM).

In another variant, the eNB implements an association between the predicted throughput and measured throughput so the eNB is able to identify that both reports relate to the same traffic steering event. This is done by assigning an event identity elD once the predicted throughput Tp WLANfi) for a given UE is received and, when the throughput measurement Tm WLANfi) for the same UE is received after traffic steering, the same elD is assigned to the measurements. By doing this, an eNB is able to compute metrics reflecting the prediction accuracy /error associated to each of the traffic steering events from the eNB to WLAN APs, as shown in Figure 7. These steps would produce prediction error/accuracy per AP (or AP group) per traffic steering event. To give an example, the eNB can use the latest received throughput prediction and the first throughput measurement received and compute the following metric: Error = Tm_WLAN(i) - Tp_WLAN(i) / Tm_WLAN(i)

for each session elD. Again, this information can be saved and used for network performance monitoring and evaluation, in this case with per-session granularity. Multiple traffic steering events can be associated to the same AP or AP group.

The eNB may also trigger a timer Tl (with an expiration time window Tlmax) when it is notified by a traffic steering event so only throughput measurements reports within Tl < Tlmax are considered as part of the association described earlier assigned by the elD. Within this time window Tlmax, it could be assumed that the traffic demand for the UE remain the same after the traffic steering event, so this time window parameter can be optimized based on statistics of traffic demands per UE. If the timer has expired when these measurements arrive, the throughput measurements are discarded and the predictions are deleted from the AP or AP group context.

According to some embodiments, processing can be performed on the stored error/accuracy samples in order to classify different WLAN APs as trustable or not in terms of what they have promised at the time of sending the throughput prediction information and what they have achieved at the time of serving the offloaded UEs. These metrics can be an aggregated average, median, standard deviation, maximum error or any other relevant metric. There can be some WLAN APs always reporting overestimations of the predicted achievable throughput that are not equivalent to the real throughput the UEs would experience right after traffic steering. Or there can also be WLAN APs with not so good prediction algorithms. In that case, based on the processed statics of the prediction accuracy/error the traffic steering algorithm is able to consider the AP estimation non-trustable in later occasions, or apply offsets so that it is more difficult to move to specific APs or so to gain a more realistic estimation of the throughput the AP can provide, given the calculated predicted throughput. Additional details are provided below. In addition to aggregating the statics associated with the different events for each AP, the eNB can group the error/accuracy statics per WLAN AP group, based on WLAN AP capability, vendor, or any other common information for the different APs, given only that this association between WLAN AP identity and grouping criteria (e.g., capability, vendor, etc.) is available at the eNB. This information can be provided to the eNB via OAM, or by enhancing the predicted/measured throughput reports, in various embodiments. In another embodiment, based on these error/accuracy metrics that can be grouped in different ways (per AP, per AP capability, per AP vendor, per AP-eNodeB pair, etc.) an outer loop adjustment on the traffic steering algorithm can perform some of the following actions. A priority list can be created based on the statistics of the estimation error, i.e., APs in the same coverage area with better estimations are prioritized, so that the traffic steering will perform more accurately. APs can be blacklisted with too high estimation errors, if other APs in the neighborhood are available. Also, estimation errors can be compensated with some threshold adaptation. If the estimation for an AP or group of APs is an overestimation X% of the time, the algorithm assumes the real estimation is lower, and adjusts the threshold for traffic steering accordingly. An example of the processed information that might be provided in embodiments according to the techniques described above is shown in Figure 8.

Ping-pong Avoidance

According to some embodiments, the mechanisms for throughput measurements are used for the sake of ping-pong detection and avoidance. By receiving throughput measurements, the eNodeB can deduce whether the UE is subject to ping-pong mobility between LTE and WLAN. More particularly, the eNodeB can detect whether the non-zero and zero throughput periods in LTE and in WLAN are correlated. For example, when the UE moves to WLAN and if the UE is still active in LTE, throughput will be zero or very low in LTE while it will be non-zero in WLAN. Likewise, if the UE moves out of WLAN and moves its data traffic to LTE, throughput may be reported by WLAN as zero (or very low) but throughput may be non-zero and high in LTE. The latter events, if repeated consecutively, highlight a situation where the UE repeatedly moves from LTE to WLAN and from WLAN to LTE, thereby generating a so-called ping-pong condition.

An eNB can be configured to detect a ping-pong event from the measured throughput statistics collected by the eNB and the measured throughput statistics signaled to the eNB from the WLAN. Based on this detection, eNB can modify the thresholds used for triggering UE offloading to WLAN, which thresholds are broadcast to the served UEs and/or signaled to UEs individually. Such modification should prevent the ping-pong event from occurring again. For example, the change may consist of increasing the WLAN thresholds (i.e., in a direction so as to increase UE retention at LTE) so as to ensure that the UE moves to WLAN only when the AP's signal strength is strong enough to make a ping-pong event unlikely. If the eNB is able to also configure at the UE (either via direct signaling or via signaling to the WLAN AP and consequent signaling from the WLAN AP to the UE) thresholds for mobility from WLAN to LTE, the eNB may increase the LTE thresholds, i.e., the thresholds that if fulfilled by the LTE signal would trigger a transition of the UE to Active in LTE. In this way, the eNB may increase the permanence time of the UE in WLAN and therefore make the ping-pong event unlikely.

Example Implementations

Given the several detailed examples above, which were described in the context of a 3 GPP network node 10, and a WLAN, it should be appreciated that these techniques may be applied more generally, i.e., in the context of any wide-area cellular network and a WLAN, where there is provided a means for a node in the wide-area cellular network 10 (e.g., a base station, a radio network controller, etc.) and a node in the WLAN 14 (e.g., a WLAN AP, WLAN access controller, etc.) to communicate with one another.

Figure 9 is a process flow diagram illustrating an example method 900, according to some of the above-described techniques, as implemented in a node of a WLAN, such as in a

WLAN AP or WLAN AC. As shown at block 910, the method includes detecting a trigger event indicating that a report for at least one wireless terminal associated with a wide-area cellular network is to be sent. The method 900, at block 920, also includes determining a predicted throughput for the at least one wireless terminal in the WLAN. A report is then sent to a node in the wide-area cellular network. The first report indicates a predicted throughput in the WLAN for the at least one wireless terminal. This is shown at block 930. This may be sent via an interface between a WLAN AP and a base station in the wide-area cellular network, for example. The first report may include an identifier for a wireless terminal or group of wireless terminals to which the first report applies.

In some embodiments, detecting the trigger event comprises receiving a request for the first report from the wide-area cellular network. This may be received via an interface between a WLAN access point (AP) and a base station in the wide-area cellular network, in some embodiments.

In some embodiments, detecting the trigger event comprises detecting that a wireless terminal associated with the wide-area cellular network is attempting to associate with the WLAN. In some embodiments, detecting the trigger event comprises determining that some other preconfigured condition in the WLAN has been satisfied. In some of these methods, the operations illustrated in Figure 9 are preceded by receiving, from the wide-area cellular network, configuration information defining the preconfigured condition. This configuration information may specify a periodic reporting interval for predicted throughput reports, for example.

In some embodiments, the first report indicates a maximum achievable throughput in the

WLAN for a wireless terminal. The determining of the maximum achievable throughput may be based on terminal-specific radio channel conditions, or based on terminal-specific capabilities with respect to the WLAN, or based on both. In other embodiments, the first report indicates a maximum achievable throughput in the WLAN for a group of wireless terminals having one or more shared capabilities with respect to the WLAN. The determining of the maximum achievable throughput in these embodiments may be based on one or more load metrics for the WLAN, for example.

Figure 10 is a process flow diagram illustrating another example method suitable for implementation in one or more nodes of a WLAN. It should be appreciated that the method shown in Figure 10, as well as any of its variants discussed below, can be directly combined with the method shown in Figure 9, and/or its variants.

As shown at block 1010, the illustrated method 1000 begins with detecting a trigger event indicating that a report for at least one wireless terminal associated with the WLAN is to be sent to a wide-area cellular network. As shown at block 1020, the measured throughput in the WLAN for the at least one wireless terminal is determined. A report is sent to the wide-area cellular network, as shown at block 1030, the report indicating the measured throughput for the at least one wireless terminal. This report may be sent via an interface between a WLAN AP and a base station in the wide-area cellular network, for example. It should be noted that while the sending of the report is responsive to the triggering event, the measuring of the throughput may be performed before the trigger event is detected, in some embodiments or in some instances.

In some embodiments, detecting the trigger event comprises receiving a request for the report from the wide-area cellular network. Again, this request may be received via an interface between a WLAN AP and a base station in the wide-area cellular network, for example.

In some embodiments, detecting the trigger event comprises detecting that a wireless terminal associated with the wide-area cellular network is also associated with the WLAN. In some embodiments, detecting the trigger event comprises determining that some other preconfigured condition in the WLAN has been satisfied. In such cases, the one or more nodes in the WLAN receive, from the wide-area cellular network, configuration information defining the preconfigured condition - this configuration information may specify a periodic reporting interval for predicted throughput reports, for example.

In some embodiments, the report indicates a measured average throughput in the WLAN for a wireless terminal. In other embodiments, the report indicates that a wireless terminal has achieved a throughput exceeding a predetermined threshold for a measurement duration. In still other embodiments, the report indicates a measured average throughput in the WLAN for a group of wireless terminals having one or more shared capabilities with respect to the WLAN. In any of these embodiments, the report may comprise an identifier for a wireless terminal or group of wireless terminals to which the first report applies.

Figure 11 illustrates an example method 1100 as implemented in one or more nodes of a wide-area cellular network, such as in an eNB of an LTE network. It should be appreciated that this method is complementary to the method shown in Figure 9.

As shown at block 1120, the illustrated method includes receiving, from a node in a

WLAN, a report indicating a predicted throughput in the WLAN for at least one wireless terminal associated with the wide-area cellular network. This report may be received via an interface between a WLAN AP and a base station in the wide-area cellular network, in some embodiments. As shown at block 1130, the method further comprises making an offloading decision for the at least one wireless terminal, based on the first report.

In some embodiments, as shown at block 110, the method further comprises sending a request for the first report to the WLAN. In other embodiments or other instances, however, the reports may be sent by the WLAN without such a request. This may be done, for example, on the basis of configuration information sent to the WLAN by the one or more nodes of the wide- area cellular network, this configuration information defining one or more conditions for sending the report to the wide-area cellular network. This configuration may specify a periodic reporting interval for predicted throughput reports, for example.

In some embodiments, the received report indicates a maximum achievable throughput in the WLAN for a wireless terminal. In some embodiments, this may be based on terminal-specific radio channel conditions, or based on terminal-specific capabilities with respect to the WLAN, or based on both. In other embodiments, the report indicates a maximum achievable throughput in the WLAN for a group of wireless terminals having one or more shared capabilities with respect to the WLAN. This may be based on one or more load metrics for the WLAN, for example. In any of these embodiments, the report may include an identifier for a wireless terminal or group of wireless terminals to which the report applies.

Figure 12 illustrates another example method 1200 that can be carried out in one or more nodes of a wide-area wireless network. This method complements the WLAN-based method shown in Figure 10, and can be directly combined with the method of Figure 11.

The method includes, as shown at block 1220, receiving, from a node in a WLAN, a report indicating a measured throughput in the WLAN for at least one wireless terminal associated with the WLAN. This report may be received via an interface between a WLAN AP and a base station in the wide-area cellular network. In some embodiments, the method may further comprise sending a request for the report to the WLAN, as shown at block 1210. In other embodiments or other instances, however, the reports may be sent by the WLAN without such a request. Again, this may be done, for example, on the basis of configuration information sent to the WLAN by the one or more nodes of the wide-area cellular network, this configuration information defining one or more conditions for sending the report to the wide-area cellular network. This configuration may specify a periodic reporting interval for measured throughput reports, for example.

In some embodiments, the report indicates a measured average throughput in the WLAN for a wireless terminal. In other embodiments, the report indicates that a wireless terminal has achieved a throughput exceeding a predetermined threshold for a measurement duration. In still other embodiments, the report indicates a measured average throughput in the WLAN for a group of wireless terminals having one or more shared capabilities with respect to the WLAN. In any of these and in other embodiments, the report may include an identifier for a wireless terminal or group of wireless terminals to which the first report applies.

Figure 13 illustrates another example method 1300 as implemented in one or more nodes of a wide-area cellular network. This method includes, as shown at block 1310, measuring a throughput in the wide-area cellular network for a wireless terminal, and further includes, as shown at block 1320, receiving, from a WLAN, an indication of a predicted throughput in the WLAN for the wireless terminal or for a group of wireless terminals including or like the wireless terminal. Note that these operations can be performed in any order. Next, as shown at block 1330, the measured throughput in the wide-area cellular network and the predicted throughput in the WLAN are compared. Based on this comparison, a decision is made as to whether or not to offload the wireless terminal to the WLAN, as shown at block 1340.

In some embodiments, determining whether or not to offload the wireless terminal to the

WLAN comprises determining to offload the wireless terminal to the WLAN in response to determining that the predicted throughput in the WLAN exceeds the measured throughput in the wide-area cellular network. In other embodiments, determining whether or not to offload the wireless terminal to the WLAN comprises determining to offload the wireless terminal to the WLAN in response to determining that the predicted throughput in the WLAN exceeds the measured throughput in the wide-area cellular network by more than a predetermined offset. In some of these embodiments, the method further comprises storing the indication of the predicted throughput, in association with an identifier for a WLAN AP from which the indication was received and/or in association with an identifier for a WLAN AP group to which said WLAN AP belongs. This operation is not shown in Figure 13, but may be performed at any time after the predicted throughput is received.

Figure 14 illustrates a variation 1400 of the method 1300 shown in Figure 13. In this variation, statistics for predicted throughputs in the WLAN and the measured throughputs in the wide-area network are evaluated, as shown at block 1430. The offloading decision, shown at block 1440, is based on this evaluation.

Figure 15 illustrates yet another method 1500 for implementation in one or more nodes of a wide-area cellular network. This method includes, as shown at block 1510, receiving, from a WLAN AP, one or more indications of predicted throughput in the WLAN AP for a wireless terminal or for a group of wireless terminals. As shown at block 1520, the method also includes receiving, from the WLAN AP, one or more indications of measured throughput in the WLAN for the wireless terminal or for the group of wireless terminals. As shown at block 1530, the method still further comprises evaluating a prediction accuracy for the WLAN AP, based on the received predicted throughputs and received indications of measured throughput.

In some embodiments, as shown at block 1540, the method further includes making an offloading decision for a wireless terminal, wherein said offloading decision takes into account the prediction accuracy for the WLAN AP. In some embodiments, the offloading decision takes into account the prediction accuracy for the WLAN AP by blacklisting the WLAN AP if the prediction accuracy is worse than a predetermined level. In other embodiments, the offloading decision takes into account the prediction accuracy for the WLAN AP by adjusting one or more predictions of throughput for the WLAN AP, based on the prediction accuracy. In still other embodiments, the offloading decision takes into account the prediction accuracy for the WLAN AP by prioritizing the WLAN AP, relative to one or more other WLAN APs, based on the prediction accuracy.

Figure 16 illustrates still another method 1600 for implementation in one or more nodes of a wide-area cellular network. This method includes, as shown at block 1610, performing one or more measurements of throughput in the wide-area cellular network for a wireless terminal. The method further includes, as shown at block 1620, receiving, from a WLAN, one or more reports indicating measurements of throughput in the WLAN for the wireless terminal. As shown at block 1630, the measurements of throughput in the wide-area cellular network and the indicated measurements of throughput in the WLAN are evaluated. A ping-pong condition for the wireless terminal is then detected, as shown at block 1640, based on said evaluating. As discussed above, a ping-pong condition comprises consecutive transitions of the wireless terminal between operating in the wide-area cellular network and the WLAN.

In some embodiments, as shown at block 1650, the method further includes adjusting an offloading threshold for transitions from the wide-area cellular network to the WLAN, in response to said detecting, wherein the at least one offload threshold is used by the one or more nodes in the wide-area cellular system, in conjunction with predicted throughput and/or measured throughput for a wireless terminal, to determine whether and when to offload the wireless terminal to the WLAN.

In some of these and in some other embodiments, the method further includes adjusting an offloading threshold for transitions from the wide-area cellular network to the WLAN, in response to said detecting, and sending the adjusted threshold to the WLAN for use by the WLAN, in conjunction with predicted throughput and/or measured throughput for a wireless terminal, to determine whether and when to offload the wireless terminal from the WLAN to the wide-area cellular network. This is shown at block 1660.

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 to enact special 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 can 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 invention 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 and/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.

Figure 17 shows a node 10 configured for operation in a wide-area cellular network (for example a base station, NodeB or an eNodeB) that can be adapted for use in example embodiments described above. The node 10 comprises a processing unit 40 that controls the operation of the node 10. The processing circuit 40 comprises one or more digital processing circuits, e.g., one or more microprocessors, microcontrollers, DSPs, FPGAs, Complex

Programmable Logic Devices (CPLDs), ASICs, or any mix thereof. More generally, the processing circuit 40 may comprise fixed circuitry, or programmable circuitry that is specially adapted via the execution of program instructions implementing the functionality taught herein, or may comprise some mix of fixed and programmed circuitry. The processing circuit 40 may be a multi-core based processing circuit having two or more processor cores utilized for enhanced performance, reduced power consumption, and more efficient simultaneous processing of multiple tasks.

The processing unit 40 is connected to a transmitter or a transceiver 42 (which comprises a receiver and a transmitter) with associated antenna(s) 44 which are used to transmit signals to, and receive signals from, terminal devices 12 in the network 2. The transceiver circuit 42 may include transmitter circuits, receiver circuits, and associated control circuits that are collectively configured to transmit and receive signals according to a radio access technology, for the purposes of providing cellular communication services. According to various embodiments, cellular communication services may be operated according to any one or more of the 3 GPP cellular standards, GSM, GPRS, WCDMA, HSDPA, LTE and LTE- Advanced.

The node 10 also comprises a memory unit 46 that is connected to the processing unit 40 and that stores computer program code and other information and data required for the operation of RAN node 10. The memory unit 46 provides non-transitory storage for the computer program executed by processing unit 40 and it may comprise one or more types of computer-readable media, such as disk storage, solid-state memory storage, or any mix thereof. Here, "non-transitory" means permanent, semi-permanent, or at least temporarily persistent storage and encompasses both long-term storage in non-volatile memory and storage in working memory, e.g., for program execution. By way of non-limiting example, the memory unit 46 comprises any one or more of SRAM, DRAM, EEPROM, and FLASH memory. In the case of a multi-core processing circuit, a large number of processor cores may share resources, such as memory unit 46.

Together, the processing unit 40 and memory unit 46 may be referred to as a processing circuit. The node 10 also includes components and/or circuitry 48 for allowing the node 10 to exchange information with other nodes 10 (for example via an X2 interface) and components and/or circuitry 49 for allowing the node 10 to exchange information with nodes in the core network 4 (for example via the SI interface). It will be appreciated that nodes for use in other types of network (e.g. UTRAN or WCDMA RAN) will include similar components to those shown in Figure 17 and appropriate interface circuitry 48, 49 for enabling communications with the other network nodes in those types of networks (e.g. other base stations, mobility management nodes and/or nodes in the core network).

The node 10 shown in Figure 17 can be adapted, e.g., using appropriate program code stored in memory unit 46 for execution by processing unit 40, to carry out any one or several of the wide-area network-based methods described herein, including the methods illustrated in

Figures 11-16 and the several variations described in connection with those figures and in the detailed examples provided above.

Figure 18 shows a WLAN node 14 (such as a WLAN AP or WLAN AC) that can be used in the example embodiments described above. The node 14 comprises a processing unit 60 that controls the operation of the node 14. Once again, the processing unit 60 comprises one or more digital processing circuits, e.g., one or more microprocessors, microcontrollers,

DSPs, FPGAs, CPLDs, ASICs, or any mix thereof. More generally, the processing circuit 60 may comprise fixed circuitry, or programmable circuitry that is specially adapted via the execution of program instructions implementing the functionality taught herein, or may comprise some mix of fixed and programmed circuitry. The processing circuit 40 may be a multi-core based processing circuit having two or more processor cores utilized for enhanced performance, reduced power consumption, and more efficient simultaneous processing of multiple tasks.

The processing unit 60 is connected to a transmitter or a transceiver circuit 62 (which comprises a receiver and a transmitter) with associated antenna(s) 64 which are used to transmit signals to, and receive signals from, terminal devices 12. The transceiver circuit 62 may include transmitter circuits, receiver circuits, and associated control circuits that are collectively configured to transmit and receive signals according to a WLAN radio access technology, for the purposes of providing WLAN services. According to various embodiments, these WLAN services may be operated according to any one or more of the IEEE 802.11 standards, for example.

The node 14 also comprises a memory unit 66 that is connected to the processing unit 60 and that stores computer program code and other information and data required for the operation of the node 14. The memory unit 66 provides non-transitory storage for a computer program executed by processing unit 60 and it may comprise one or more types of computer- readable media, such as disk storage, solid-state memory storage, or any mix thereof. Here, "non-transitory" means permanent, semi-permanent, or at least temporarily persistent storage and encompasses both long-term storage in non-volatile memory and storage in working memory, e.g., for program execution. Together, the processing unit 60 and memory unit 66 may be referred to as a processing circuit. The node 14 also includes components and/or circuitry 68 for connecting the node 14 to a telephone line or other broadband connection.

The node 14 shown in Figure 18 can be adapted, e.g., using appropriate program code stored in memory unit 66 for execution by processing unit 60, to carry out any one or several of the WLAN -based methods described herein, including the methods illustrated in Figures 9 and 10 and the several variations described in connection with those figures and in the detailed examples provided above.

Figure 19 shows a block diagram of a wireless terminal, such as UE 12. UE 12 includes a transceiver circuit 32 with an antenna 34. The UE 12 also includes a processing unit 30 and a memory unit 36 that includes program instructions that when executed by processing unit 30 perform so as to implement the described techniques. As used herein, the terms "mobile terminal," "wireless terminal," "user equipment," or "UE" may be used to refer to any device that receives data from and transmits data to a communication network, any of which may be for example, a mobile telephone ("cellular" telephone), laptop/portable computer, pocket computer, hand-held computer, desktop computer, a machine to machine (M2M) or MTC type device, a sensor with a wireless communication interface, etc. These devices may, in many cases, be configured for operation in a WLAN as well as in a wide-area cellular network, such as 3GPP- specified wireless network. The processing unit 30 is configured to cause the UE 12 to perform operations necessary to complement the methods 900-1600 described above.

Example embodiments have been described herein, with reference to block diagrams and/or flowchart illustrations of computer-implemented methods, apparatus (systems and/or devices) and/or computer program products. It is understood that a block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by computer program instructions that are performed by one or more computer circuits. These computer program instructions may be provided to a processor circuit of a general purpose computer circuit, special purpose computer circuit, and/or other programmable data processing circuit to produce a machine, such that the instructions, which execute via the processor of the computer and/or other programmable data processing apparatus, transform and control transistors, values stored in memory locations, and other hardware components within such circuitry to implement the functions/acts specified in the block diagrams and/or flowchart block or blocks, and thereby create means (functionality) and/or structure for implementing the functions/acts specified in the block diagrams and/or flowchart block(s).

These computer program instructions may also be stored in a tangible computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instructions which implement the functions/acts specified in the block diagrams and/or flowchart block or blocks. Accordingly, embodiments of present inventive concepts may be embodied in hardware and/or in software (including firmware, resident software, micro-code, etc.) running on a processor such as a digital signal processor, which may collectively be referred to as "circuitry," "a module" or variants thereof.

It should also be noted that in some alternate implementations, the functions/acts noted in the blocks may occur out of the order noted in the flowcharts. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality/acts involved. Moreover, the functionality of a given block of the flowcharts and/or block diagrams may be separated into multiple blocks and/or the functionality of two or more blocks of the flowcharts and/or block diagrams may be at least partially integrated. Finally, other blocks may be added/inserted between the blocks that are illustrated, and/or blocks/operations may be omitted without departing from the scope of inventive concepts.

Figure 20 illustrates a functional implementation of a network node 10 executed by the processing circuitry 40, according to some embodiments. The implementation includes a measuring module 2002 for measuring a throughput in the wide-area cellular network for a wireless terminal and a receiving module 2004 for receiving, from a WLAN, an indication of a predicted throughput in the WLAN for the wireless terminal or for a group of wireless terminals including or like the wireless terminal. The implementation also includes a comparing module 2006 for comparing the measured throughput in the wide-area cellular network to the predicted throughput in the WLAN and a determining module 2008 for determining whether or not to offload the wireless terminal to the WLAN, based on the comparing. Figure 21 illustrates a functional implementation of a network node 10 executed by the processing circuitry 40, according to some embodiments. The implementation includes a measuring module 2102 for measuring throughput in the wide-area cellular network for a wireless terminal and a receiving module 2104 for receiving, from a WLAN, one or more indications of predicted throughput in the WLAN for the wireless terminal or for a group of wireless terminals including or like the wireless terminal. The implementation also includes an evaluating module 2106 for evaluating one or more statistics of measured throughput in the wide-area cellular network and one or more statistics of the predicted throughput in the WLAN and a determining module 2108 for determining whether or not to offload the wireless terminal to the WLAN, based on the evaluating.

Figure 22 illustrates a functional implementation of a network node 10 executed by the processing circuitry 40, according to some embodiments. The implementation includes a receiving module 2202 for receiving, from a WLAN AP, one or more indications of predicted throughput in the WLAN AP for a wireless terminal or for a group of wireless terminals including or like the wireless terminal. The receiving module 2202 is also for receiving, from the WLAN AP, one or more indications of measured throughput in the WLAN for the wireless terminal or for the group of wireless terminals and an evaluating module 2204 for evaluating a prediction accuracy for the WLAN AP, based on the received indications of predicted throughput and received indications of measured throughput.

Figure 23 illustrates a functional implementation of a network node 10 executed by the processing circuitry 40, according to some embodiments. The implementation includes a requesting module 2302 for sending a request for a report from a WLAN and a receiving module 2304 for receiving the report indicating a predicted throughput for a wireless terminal in the WLAN or for a group of wireless terminals including or like the wireless terminal. The implementation also includes a decision module 2306 for making an offloading decision for the wireless terminal, based on the predicted throughput indicated by the report.

Figure 24 illustrates a functional implementation of a network node 10 executed by the processing circuitry 40, according to some embodiments. The implementation includes a requesting module 2402 for sending a request for a report from a WLAN and a receiving module 2404 for receiving the report indicating a measured throughput for a wireless terminal in the WLAN or for a group of wireless terminals including or like the wireless terminal. The implementation also includes a decision module 2406 for making an offloading decision for the wireless terminal, based on the measured throughput indicated by the report.

Figure 25 illustrates a functional implementation of a WLAN node 14 executed by the processing circuitry 60, according to some embodiments. The implementation includes a detecting module 2502 for detecting a trigger event indicating that a report for at least one wireless terminal associated with a wide-area cellular network is to be sent and a determining module 2504 for determining a predicted throughput for the at least one wireless terminal in the WLAN. The implementation also includes a sending module 2506 for sending the report to a node in the wide-area cellular network, the report indicating the predicted throughput for the at least one wireless terminal in the WLAN.

Figure 26 illustrates a functional implementation of a WLAN node 14 executed by the processing circuitry 60, according to some embodiments. The implementation includes a detecting module 2602 for detecting a trigger event indicating that a report for at least one wireless terminal associated with a wide-area cellular network is to be sent and a determining module 2604 for determining a measured throughput for the at least one wireless terminal in the WLAN. The implementation also includes a sending module 2606 for sending the report to a node in the wide-area cellular network, the report indicating the measured throughput for the at least one wireless terminal in the WLAN.

The techniques and apparatuses described above facilitate the minimization of the information reported over an inter-node interface between WLAN APs and eNodeBs (or other wide-area wireless network nodes) to support QoS-based traffic steering. This is done by having the target node report i) the predicted QoS before traffic steering and ii) the achieved QoS after traffic steering, where QoS is illustrated in the detailed examples given above as the throughput or data rate for a wireless terminal or group of wireless terminals.

In some embodiments, a traffic steering function implemented in the eNB (or other wireless network node) first uses the reported prediction as a criterion to steer UEs to the target node. After receiving the achieved throughput measurements, the eNB performs an association so that the predicted and measured throughputs can be correlated and error statistics computed, and then stores and process them in an WLAN AP (or AP group) context. When this is done, the traffic steering function can be adjusted in an outer loop, so that APs are classified according to their prediction accuracy. In some embodiments, measured throughput information reported from the WLAN AP is used to detect and avoid ping-pong events.

Note that although terminology from specifications for LTE or E-UTRAN are used in this disclosure to exemplify embodiments of the inventive concepts, this should not be seen as limiting the scope of the presently disclosed techniques to only these systems. Devices designed for use in other wireless systems, including variations and successors of 3 GPP LTE systems, and WCDMA (UMTS) systems, WiMAX (Worldwide Interoperability for Microwave Access), UMB (Ultra Mobile Broadband), HSDPA (High-Speed Downlink Packet Access), GSM (Global System for Mobile Communications), etc., may also benefit from exploiting embodiments of present inventive concepts disclosed herein.

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 invention. For example, although embodiments of the present invention have been described with examples that reference a communication system compliant to the 3GPP-specified LTE standards, it should be noted that the solutions presented may be equally well applicable to other networks. The specific embodiments described above should therefore be considered exemplary rather than limiting the scope of the invention. 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 invention can be implemented in other ways than those specifically set forth herein, without departing from essential characteristics of the invention. The present embodiments are thus to be considered in all respects as illustrative and not restrictive.

As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. Well-known functions or constructions may not be described in detail for brevity and/or clarity. The term "and/or" includes any and all combinations of one or more of the associated listed items. As used herein, the terms "comprise", "comprising", "comprises", "include", "including", "includes", "have", "has", "having", or variants thereof are open-ended, and include one or more stated features, integers, elements, steps, components or functions but does not preclude the presence or addition of one or more other features, integers, elements, steps, components, functions or groups thereof. BLANK AT THE TIME OF FILING

Claims

CLAIMS What is claimed is:

1. A method (1300), in one or more nodes of a wide-area cellular network (10), the method comprising:

measuring (1310) a throughput in the wide-area cellular network for a wireless terminal

(12);

receiving (1320), from a wireless local-area network, WLAN, an indication of a predicted throughput in the WLAN for the wireless terminal (12) or for a group of wireless terminals (12) including or like the wireless terminal (12);

comparing (1330) the measured throughput in the wide-area cellular network to the

predicted throughput in the WLAN; and

determining (1340) whether or not to offload the wireless terminal (12) to the WLAN, based on the comparing.

2. The method (1300) of claim 1 , wherein determining (1340) whether or not to offload the wireless terminal (12) to the WLAN comprises determining to offload the wireless terminal (12) to the WLAN in response to determining that the predicted throughput in the WLAN exceeds the measured throughput in the wide-area cellular network.

3. The method (1300) of claim 1 , wherein determining (1340) whether or not to offload the wireless terminal (12) to the WLAN comprises determining to offload the wireless terminal (12) to the WLAN in response to determining that the predicted throughput in the WLAN exceeds the measured throughput in the wide-area cellular network by more than a predetermined offset.

4. The method (1300) of claim 1 , wherein determining (1340) whether or not to offload the wireless terminal (12) to the WLAN comprises determining to not offload the wireless terminal (12) to the WLAN in response to determining that the predicted throughput in the WLAN is lower than the measured throughput in the wide-area cellular network by more than a predetermined offset.

5. The method (1300) of claim 1 , wherein determining (1340) whether or not to offload the wireless terminal (12) to the WLAN comprises determining to offload the wireless terminal (12) to the WLAN in response to determining that the measured throughput in the wide-area cellular network is lower than the predicted throughput in the WLAN by more than a predetermined offset.

6. The method (1300) of claim 1 , wherein determining (1340) whether or not to offload the wireless terminal (12) to the WLAN comprises determining to not offload the wireless terminal (12) to the WLAN in response to determining that the measured throughput in the wide-area cellular network exceeds the predicted throughput in the WLAN by more than a predetermined offset.

7. The method (1300) of any of claims 1-6, further comprising storing the predicted throughput, in association with an identifier for a WLAN access point, AP, (14) from which the indication was received and/or in association with an identifier for a WLAN AP group to which the WLAN AP (14) belongs.

8. The method (1300) of any of claims 1-7, wherein the the predicted throughput comprises a maximum achievable throughput in the WLAN.

9. The method (1300) of any of claims 1-8, wherein the predicted throughput is specific to a WLAN Access Point, AP, (14) or a WLAN Access Controller, AC (14).

10. The method (1300) of any of claims 1 -9, wherein the predicted throughput is based on capability information specific to the wireless terminal and/or based on measurements specific to the wireless terminal.

11. A method (1400), in one or more nodes of a wide-area cellular network (10), comprising: measuring (1410) throughput in the wide-area cellular network for a wireless terminal

(12);

receiving (1420), from a wireless local-area network, WLAN, an indication of a predicted throughput in the WLAN for the wireless terminal (12) or for a group of wireless terminals (12) including or like the wireless terminal (12);

evaluating (1430) one or more statistics of measured throughput in the wide-area cellular network and one or more statistics of the predicted throughput in the WLAN; and determining (1440) whether or not to offload the wireless terminal (12) to the WLAN, based on the evaluating.

12. The method (1400) of claim 11, wherein the one or more statistics comprise at least one of an average throughput, an error, a standard deviation, a maximum throughput and a minimum throughput.

13. The method (1400) of claim 11 or 12, wherein the one or more statistics comprise one or more statistics per wireless terminal.

14. The method (1400) of any of claims 11-13, wherein the one or more statistics are computed over a time window.

15. The method (1400) of any of claims 11-14, wherein the one or more statistics are aggregated per WLAN Access Point, AP, (14) or WLAN AP group.

16. A method (1500), in one or more nodes of a wide-area cellular network (10), comprising: receiving (1510), from a wireless local-area network, WLAN, access point, AP, (14) one or more indications of predicted throughput in the WLAN AP (14) for a wireless terminal (12) or for a group of wireless terminals (12) including or like the wireless terminal (12);

receiving (1520), from the WLAN AP, (14) one or more indications of measured

throughput in the WLAN for the wireless terminal (12) or for the group of wireless terminals (12); and evaluating (1530) a prediction accuracy for the WLAN AP, (14) based on the received indications of predicted throughput and received indications of measured throughput.

17. The method (1500) of claim 16, further comprising making (1540) an offloading decision for a wireless terminal, wherein said offloading decision takes into account the prediction accuracy for the WLAN AP (14).

18. The method (1500) of claim 17, wherein the offloading decision takes into account the prediction accuracy for the WLAN AP (14) by blacklisting the WLAN AP (14) if the prediction accuracy is worse than a predetermined level.

19. The method (1500) of claim 17, wherein the offloading decision takes into account the prediction accuracy for the WLAN AP (14) by adjusting one or more predictions of throughput for the WLAN AP (14), based on the prediction accuracy.

20. The method (1500) of claim 19, wherein adjusting the one or more predictions of throughput for the WLAN AP (14) comprises adjusting the one or more predictions of throughput according to a threshold adaption that is set based on a size of an estimation error and a size of a standard deviation associated with respective ones of the one or more indications of predicted throughput.

21. The method (1500) of claim 17, wherein the offloading decision takes into account the prediction accuracy for the WLAN AP (14) by prioritizing the WLAN AP (14), relative to one or more other WLAN APs (14), based on the prediction accuracy.

22. The method (1500) of any of claims 16-21, wherein evaluating the predication accuracy comprises triggering a timer and evaluating the prediction accuracy for the WLAN AP (14), based on received indications of measured throughput that are received during the timer.

23. The method (1500) of any of claims 16-22, wherein evaluating the predication accuracy comprises evaluating the prediction accuracy for the WLAN AP (14) based on a size of an estimation error and size of a standard deviation associated with respective ones of the one or more indications of predicted throughput.

24. The method (1500) of any of claims 16-23, wherein the one or more indications of predicted throughput are predicted before the wireless terminal (12) or the group of wireless terminals (12) is connected to the WLAN.

25. The method (1500) of any of claims 16-24, wherein the one or more indications of measured throughput are measured after the wireless terminal (12) or the group of wireless terminals (12) is connected to the WLAN.

26. An apparatus in a wide-area cellular network (10) comprising processing circuitry (40) adapted to: measure a throughput in the wide-area cellular network for a wireless terminal (12); receive, from a wireless local-area network, WLAN, an indication of a predicted

throughput in the WLAN for the wireless terminal (12) or for a group of wireless terminals (12) including or like the wireless terminal (12);

compare the measured throughput in the wide-area cellular network to the predicted

throughput in the WLAN; and

determine whether or not to offload the wireless terminal (12) to the WLAN, based on the comparing.

27. The apparatus (10) of claim 26, wherein the processing circuitry (40) is further adapted to perform the method of any of claims 2-10.

28. An apparatus in a wide-area cellular network (10) comprising processing circuitry (40) adapted to:

measure throughput in the wide-area cellular network for a wireless terminal (12);

receive, from a wireless local-area network, WLAN, an indication of a predicted

evaluate one or more statistics of measured throughput in the wide-area cellular network and one or more statistics of the predicted throughput in the WLAN; and determine whether or not to offload the wireless terminal (12) to the WLAN, based on the evaluating.

29. The apparatus (10) of claim 28, wherein the processing circuitry (40) is further adapted to perform the method of any of claims 9-12.

30. An apparatus in a wide-area cellular network (10) for use in a wireless local-area network, WLAN, the apparatus comprising processing circuitry (40) adapted to:

receive, from a WLAN access point, AP, (14) one or more indications of predicted

throughput in the WLAN AP (14) for a wireless terminal (12) or for a group of wireless terminals (12);

receive, from the WLAN AP (14), one or more indications of measured throughput in the

WLAN for the wireless terminal (12) or for the group of wireless terminals (12); and

evaluate a prediction accuracy for the WLAN AP (14), based on the received predicted throughputs and received indications of measured throughput.

31. The apparatus (10) of claim 30, wherein the processing circuitry (40) is further adapted to perform the method of any of claims 12-15.

32. A computer program product comprising program instructions that, when executed by a processor (40) in a node of a wide-area cellular network (10), cause the node (10) to carry out a method according to any of claims 1 -27.

33. A computer-readable medium (46) comprising, stored thereupon, the computer program product of claim 32.

34. An apparatus in a wide-area cellular network (10), comprising:

a measuring module (2002) for measuring a throughput in the wide-area cellular network for a wireless terminal (12);

a receiving module (2004) for receiving, from a wireless local-area network, WLAN, an indication of a predicted throughput in the WLAN for the wireless terminal (12) or for a group of wireless terminals (12) including or like the wireless terminal

(12);

a comparing module (2006) for comparing the measured throughput in the wide-area cellular network to the predicted throughput in the WLAN; and

a determining module (2008) for determining whether or not to offload the wireless

terminal (12) to the WLAN, based on the comparing.

35. An apparatus in a wide-area cellular network (10), comprising:

a measuring module (2102) for measuring throughput in the wide-area cellular network for a wireless terminal (12);

a receiving module (2104) for receiving, from a wireless local-area network, WLAN, an indication of a predicted throughput in the WLAN for the wireless terminal (12) or for a group of wireless terminals (12) including or like the wireless terminal

(12);

an evaluating module (2106) for evaluating one or more statistics of measured throughput in the wide-area cellular network and one or more statistics of the predicted throughput in the WLAN; and a determining module (2108) for determining whether or not to offload the wireless terminal (12) to the WLAN, based on the evaluating.

36. An apparatus in a wide-area cellular network (10) for use in a wireless local-area network, WLAN, comprising:

a receiving module (2202) for:

receiving, from a WLAN access point, AP (14), one or more indications of

predicted throughput in the WLAN AP (14) for a wireless terminal (12) or for a group of wireless terminals (12);

receiving, from the WLAN AP (14), one or more indications of measured

throughput in the WLAN for the wireless terminal (12) or for the group of wireless terminals (12); and

an evaluating module (2204) for evaluating a prediction accuracy for the WLAN AP (14), based on the received predicted throughputs and received indications of measured throughput.