May 2014 doc.: IEEE 802.11-14/0699r0
IEEE P802.11
Wireless LANs
Date: 2014-05-14
Author(s):
Name / Affiliation / Address / Phone / email
Joe Kwak / InterDigital / Hawkesbury, ON / 613-739-4159 /
Gabor Bajko / MediaTek /
Vinko Erceg / Broadcom / San Diego, CA /
IEEE P802.11
Wireless LANs
Excerpts from document submitted as 11-14-0572-00-000m-ls-response-to-letter-from-3gpp
Date: 2014-05-14
Author(s):
Name / Affiliation / Address / Phone / email
Joe Kwak / InterDigital / Hawkesbury, ON / 613-739-4159 /
Gabor Bajko / MediaTek /
The 3rd Generation Partnership Project (3GPP) submitted a letter to the IEEE 802.11 Working Group (WG). The letter is documented in 11-14/0519r0. This document contains recommended response text drafted by members of the IEEE 802.11 Task Group MC.
Summary of the letter from 3GPP
According to the letter the 3GPP Working Group RAN2 developed a letter to the IEEE 802.11 Working Group during the 3GPP TSG-RAN2 Meeting #85bis. The letter reports that “3GPP TSG-RAN WG2 (RAN2) is developing a mechanism for inter-working between 3GPP RATs [Radio Access Technologies] (UMTS and LTE) and WLAN.” To allow for efficient inter-working of IEEE 802.11 WLAN and 3GPP’s radio technologies, the 3GPP WG RAN2 intends to develop mechanisms that provide access network selection and traffic routing. The proposed 3GPP mechanism allows a device to steer traffic from one radio technology to another based on signal strength measurements and other, additional parameters. In their letter, the 3GPP WG RAN2 asks about the applicability of certain measurement functionality in the IEEE Std 802.11. The questions are as follows.
· Question 1: Does IEEE 802.11 WG consider WLAN RCPI a suitable metric of WLAN signal strength such that it can be compared to thresholds as in the above described mechanism?
· Question 2: Does IEEE 802.11 WG consider WLAN RSNI a suitable metric of WLAN signal quality such that it can be compared to thresholds as in the above described mechanism?
· Question 3: Does IEEE 802.11 WG consider any other WLAN signal metric more suitable for the above described mechanism?
Summary of this reply letter
The authors developed this reply letter for discussion by the 11mc TG and approval by the 802.11 Working Group. This letter provides responses to the questions above within a comprehensive technical framework explaining the use of metrics for network selection.
The 11mc TG is invited to consider, critique and improve this draft letter for submission to the 802.11 Working Group.
DETAILED DISCUSSION:
The 802.11 specification describes many metrics suitable for WLAN network selection. There is no single WLAN metric which is adequate for network selection for radio technology steering. WLAN Network selection has been studied extensively to support WiFi roaming within a WLAN network. In this context, the “best” target Access Point (AP) for handoff (called BSS transition) when roaming is evaluated continuously by the mobile WiFi STA. The WiFi STA may use any or all of the defined 802.11 metrics to assist in the selection of the “best” BSS for roaming transition.
Table 1, below, lists the metrics for WLAN network selection and reselection.
A technically sound approach for selecting a BSS for transition is based on a two step selection process. In the first step, the STA scans all channels for available BSSs and then uses certain key metrics, screening metrics, and policy considerations to filter available BSSs to form a smaller subset of BSS transition candidates, all of which meet the minimum requirements of the STA. In the second step, the STA uses a single scalar metric, the ranking metric, along with user preferences to rank transistion candidates in the list. The BSS at the top of the ranked list is the best BSS in the list of transition candidates for initial network selection. For network reselection, the ranking metric value of the best BSS candidate is compared to the ranking metric of the current BSS. When the metric for the best candidate exceeds the value of the metric for the current BSS, a BSS transition is scheduled.
The STA should continuously scan all the BSSs in the transistion candidate list. After each scan, the STA should use the new scanning measurements to update, screen and rank the BSSs in the transition candidate list. After each screening and ranking, the STA selects and saves the best BSS candidate to use if a transition is required. If a candidate BSS falls below the minimum requirement for any of the screening metrics, it is removed from the candidate list.
Table 1: 802.11 Metrics Suitable for WLAN Selection and Reselection.
Metric Name / ForScreen-ing / For
Rank-ing / Avail in
Beacon / Avail in Probe
Response / Avail in
Measu-rement / Avail via
ANQP / Notes
RCPI / Y / Y / Y / from Beacon Measurement by STA. See Note 2
RSNI / Y / Y / Y / from Beacon Measurement by STA. See Note 2
ANPI / Y / Y / from Noise Histogram Measurement By STA. See Note 2
Channel Load / Y / Y / from Channel Load Measurement By STA or AP
BSS Load / Y / Y / Y / measured at AP
BSS Avg Access Delay / Y / Y / Y / See Note 1 / Y / From STA Statistics Measurement measured at AP for non-QOS STA
BSS AC Access Delay / Y / Y / Y / See Note 1 / Y / From STA Statistics Measurement measured at AP for QOS STA
BSS Available Admission Capacity / Y / Y / See Note 1 / estimated at AP
FCS Error Count / Y / Y / from STA Statistics Measurement
Retry Count / Y / Y / from STA Statistics Measurement
Retry AMSDU Count / Y / Y / from STA Statistics Measurement
Supported Operating Classes / Y / Y / Y / from AP for BSS
BSS Capabilities / Y / Y / Y / from AP for BSS
Roaming Consortium / Y / Y / Y / Y / from AP for BSS
NAI Realm / Y / Y / from AP in ANQP Query
3GPP Cell Network / Y / Y / from AP in ANQP Query
Capability Lists / Y / Y / from AP in ANQP Query
WAN Metrics / Y / Y / from AP in ANQP Query, this is vendor specific metric used by Wi-Fi Alliance
NOTE1: Available when requested in Probe Request using optional Request Elements.
NOTE2: RCPI has a specified accuracy requirement of ±5dB. There is no explicit accuracy requirement for RSNI, but RSNI is calculated as RCPI minus ANPI which both has accuracy requirements of ±5dB, and hence RSNI has an implicit accuracy requirement of ±5dB.
The STA should periodically (1-5 minutes) scan each channel for all BSSs and then use screening metrics and policy to filter the scanned BSS measurements (step 1) to continuously augment and update the BSS transition candidate list. If the number of candidates on the transistion list falls to 2 or 3, the STA should immediately scan all channels and screen all BSSs in order to renew the BSS transisition candidate list.
Note that no single metric will be sufficient for network selection. For instance RCPI may be used to determine the BSS with the strongest RF signal. But selecting the BSS with the strongest signal may not provide adequate throughput rate, access delay or backhaul capacity for the required QOS for the service the STA is using. Selecting the BSS with the lowest access delay for the STA service may not provide adequate admission capacity, RSNI or throughput rate for the STA. Technically sound network selection must use multiple metrics.
Finally note that for QOS services, averaged metrics may be misleading and must be carefully considered. For instance, a BSS with a high or very high BSS load may have more than enough capacity to support an additional high priority QOS voice stream. Averaged metrics may be useful for network selection for non-QOS STAs. For QOS STAs seeking a QOS service, the BSS AC Access Delay should be used to make a sound network selection decision.
IEEE P802.11
Wireless LANs
Excerpts from document submitted as 11-14-0678-00-000m-ls-response-to-letter-from-3gpp
Date: 2014-05-12
Author(s):
Name / Affiliation / Address / Phone / email
Vinko Erceg / Broadcom / San Diego, CA /
Discussion
In our understanding, there exist two main drivers for the work, which are:
- Load balancing between operators 3GPP and WLAN networks
- Ensuring that end user Quality of Service remains at the same level or improves, when subscriber data is offloaded from the operator’s 3GPP network to the operator’s WLAN network.
These above aspects have been captured in the 3GPP TR37.834 Study on Wireless Local Area Network (WLAN) - 3GPP radio interworking, Rel-12, with the following assumptions:
1. Operator deployed WLAN networks are often under-utilized;
2. User experience is suboptimal when the UE connects to an overloaded WLAN network;
Additionally the designed solution shall fulfil the requirements set forward in 3GPP TR 37.834 Section 5.2 as follows:
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 a lower quality experience but preferably in an improved 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. additional power consumption due to WLAN scanning/discovery should be offset by reduced power consumption due to offload to WLAN).
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 mechanism of choice in 3GPP RAN2 for such a solution assumes the use of one or more RAN rules residing on the cellular modem of the terminal device which, when conditions of the rule(s) are satisfied, may trigger the selection of an AP and/or steering traffic between the cellular domain and the WLAN.
By selecting specific RAN rule(s) and setting the threshold values for comparison in the selected rule(s), the cellular network operator should be able to balance the load between 3GPP cellular network and operator controlled WLAN network(s), and ensure that end user Quality of Service remains at the same level or improves, when subscriber data is steered from one network to another.
For network selection, a solution shall select a WLAN AP that can provide:
- Minimum required QoS which should not degrade, but preferably improve the user experience;
For traffic steering from cellular to WLAN, a solution shall achieve:
- Per user and per APN traffic differentiation;
- Minimum required QoS per APN which should not degrade, but preferably improve the user experience;
Furthermore, it is our understanding that the provided solution shall not interfere with other WLAN procedures that allow seamless handover between different WLAN APs.
RCPI and RSNI are defined in the IEEE 802.112012 specification as follows:
received channel power indicator (RCPI): An indication of the total channel power (signal, noise, and
interference) of a received frame measured on the channel and at the antenna connector used to receive the frame.
For HighThroughput Physical layer (802.11n), sub-clause 20.3.21.6 specifies that RF power in the channel is measured over the data portion of the received frame.
received signal to noise indicator (RSNI): An indication of the signal to noise plus interference ratio of a
received frame. RSNI is defined by the ratio of the received signal power (RCPI-ANPI) to the noise plus
interference power (ANPI) as measured on the channel and at the antenna connector used to receive the frame.
The margin of error specified for the RCPI and ANPI parameters is ±5 dB. Additionally,we note that RCPI and RNSI measurement is defined for a single PHY frame, and does not specify any averaging over multiple frames. Furthermore, WLAN throughput performance is a function of many parameters including frequency band of operation, transmission bandwidth, interference from both BSS and OBSS, RSSI etc. Throughput is also affected by AP and STA capabilities such as MIMO (e.g. number of spatial streams), support of advanced options like LDPC and beamforming, and supported coding and modulation levels. Therefore, we believe that examining a single threshold value for RCPI and/or RSNI criteria as part of a RAN rule cannot guarantee, or be used to effectively evaluate or differentiate the radio performance that the corresponding WLAN networks can provide. Our belief is that in order to make a reasonable comparison among various WLAN choices to ascertain the best selection for traffic routing, one would need to define:
1) A test or threshold value that would take into account at least:
a) Operating band
b) Supported operating bandwidth
c) STA capability
d) AP capability
e) Existing BSS load
2) Suitable time averaging of link quality characteristics
Without fine tuning the threshold value based on the above conditions, a simple RCPI or RSNI threshold would likely end up being either too high, thereby restricting data offloading to the WLAN networks and thus reducing operators’ WLAN network utilization or too low, thereby pushing subscribers connections to the WLAN netoworks that cannot ensure that end user Quality of Service remains at the same level or improves compared to the QoS of the 3GPP network, thereby failing to meet the specified objectives. For these reasons, we believe that the use of RCPI and RSNI as the only parameters for direct comparison for either WLAN network selection or traffic steering mechanism is unsuitable.
Instead of relying on WLAN metrics like RCPI and RSNI which can correlate poorly with performance (actual QoS), it is more suitable to use measured and/or estimated values of throughput to make offload decisions (based on the considerations outlined above).
Submission page 1 Joe Kwak, InterDigital