Tag Archives: Interworking

Solution 1: RAN-assisted Network Selection and Traffic Steering

This solution relies on the RAN providing relevant information that may be used by a UE to decide:

1. If and when to connect/disconnect to/from an available WLAN

2. Steer one or more data flows from/to 3GPP RAN to/from WLAN

The UE is assumed to receive network selection and traffic steering rules and/or polices either via ANDSF or user preferences or operator provisioning. The solution can be applied in both RCC_IDLE and RRC_CONNECTED modes. More specifically, the figure below, taken from doc R2-132055, illustrates the procedure when UE is idle mode.

ImageThe steps involved in this procedure are as follows:

  • When the UE establishes RRC connection with 3GPP RAN, it transfers interworking capability info to the network
  • If the UE has indicated support for WLAN interworking and 3GPP RAN also wants to interwork with WLAN, the latter may provide assistance info to UE via dedicated signalling at the time of RRC connection release.
  • In addition, RAN may broadcast System Information which includes assistance info. If UE has valid assistance information provided through dedicated signalling previously, it ignores the related broadcast information.
  • UE selects the access network based on information provided by RAN, information obtained from WLAN and rules/policies/preferences.

Note that no traffic steering happens in this case as the UE is in IDLE mode. The procedure is similar when the UE is in CONNECTED mode, as shown below.Image

  • As in the previous case, the UE transfers its interworking capability information to RAN at the time of RRC Connection establishment.
  • While the UE is connected to RAN, it receives assistance information from RAN through dedicated signalling, if the UE supports WLAN interworking and RAN wants to interwork with WLAN.
  • UE selects the access network based on the assistance info provided by RAN, acquired information from WLAN and rules.

In both cases, the assistance information may include the following:

  • 3GPP Network load
  • Resources allocation for UE
  • WLAN thresholds (e.g. RSSI)
  • RAN thresholds (e.g. RSRP)

3GPP-WLAN Interworking – Part III : Access Network Selection and Traffic Steering

At the recent RAN2 meeting (May 20-24, 2013), the discussions focused mainly on access network selection and traffic steering in 3GPP-WLAN interworking scenarios. The proposed solutions addressed the following cases:

UE is within UTRAN/E-UTRAN coverage, is using 3GPP and goes into WLAN AP coverage

B.  UE is within UTRAN/E-UTRAN and WLAN coverage, is using WLAN and goes out of WLAN AP coverage

C.  UE is within the coverage area of both, UE using WLAN, all or a subset of the UE’s traffic should be routed via UTRAN/E-UTRAN instead

D.  UE is within the coverage area of both, UE using UTRAN/E-UTRAN,  all or a subset of the UE’s traffic should be routed via WLAN instead

E.   UE using both accesses and should be connected to only one (WLAN or UTRAN/E-UTRAN) or some traffic should be moved to the other access

In broad terms, there are 3 solutions currently being discussed in RAN2:

Solution 1: 3GPP RAN provides UE with information that assists in network selection and traffic steering. This information may be combined with ANDSF rules and/or UE configuration to decide whether to connect to a WLAN, if one is available, and to steer one or more flows to the WiFi link.

Solution 2: 3GPP RAN provides the access network selection parameters, based on which the UE decides when to connect to a WLAN. These parameters may includes thresholds, priorities, rules etc.

Solution 3: UE reports available WLAN(s) based on measurements configured by 3GPP RAN and the decisions related to WLAN selection as well as traffic steering are taken by the network.

In the next post, I will discuss each of these solutions in more detail.

3GPP-WLAN Interworking – Part II : Requirements and Scenarios

In the previous post, I had written about the scope of the Release 12 Study Item (SI) on 3GPP-WLAN Interworking. As with any other SI, the first step was define the requirements and scenarios for this study. While the focus is on Carrier WiFi deployments only, this includes the case where an independent WLAN provider partners with a 3GPP operator to provide WLAN access to the latter’s subscribers. The requirements for the candidate solutions have been captured in 3GPP TR 37.834 and they are reproduced below:

1.   Solutions should provide improved bi-directional load balancing between WLAN and 3GPP radio access networks in order to provide improved system capacity. 

2.   Solutions should improve performance (WLAN interworking should not result in decreased but preferable in better user experience).

3.   Solutions should improve the utilization of WLAN when it is available and not congested.

4.   Solutions should reduce or maintain battery consumption (e.g. due to WLAN scanning/discovery).

5.   Solutions should be compatible with all existing CN WLAN related functionality, e.g. seamless and non-seamless offload, trusted and non-trusted access, MAPCON and IFOM.

6.   Solutions should be backward compatible with existing 3GPP and WLAN specifications, i.e. work with legacy UEs even though legacy UEs may not benefit from the improvements provided by these solutions.

7.   Solutions should rely on existing WLAN functionality and should avoid changes to IEEE and WFA specifications.

8.   Per target WLAN system distinction (e.g. based on SSID) should be possible.

9.   Per-UE control for traffic steering should be possible.

10. Solutions should ensure that access selection decisions should not lead to ping-ponging between UTRAN/E-UTRAN and WLAN.

The candidate solutions should be based on the understanding that there is no RAN level information exchange between H(e)NBs/eNBs/RNCs  and APs via standardized interface. Based on these requirements and the working assumption, a set of solutions are being currently discussed by 3GPP RAN2. These will be described in the next post.