Technology Platforms

Jari Jokela

WLAN: Current developments and future challenges

Nokia/Technology Platforms 8.3.2007 TUT/ Wireless LANs / Langattomat lhiverkot Material partly based on Srinivas Sreemanthulas and Jarkko Kneckts material

Outline
Standardization status generally New standards and usage scenarios
802.11r 802.11s 802.11u 802.11v 802.11w 802.11y

Future challenges

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

WLAN Standardization generally

IEEE 802.11 is home of WLAN standardization
Responsible of functional specifications http://grouper.ieee.org/groups/802/11/

WiFi Alliance is in charge of interoperability testing

Responsible of protocol test requirements, test plan creation and actual certification http://www.wi-fi.org/

Nowadays the border between IEEE 802.11 and WiFi Alliance is not always clear
WPA/WPA2 IEEE 802.11i WMM 802.11e WiFi Protected Setup

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

Active groups in IEEE 802.11

802.11k Radio Resource Measurements 802.11n High Throughput 802.11r- Fast roaming 802.11s - ESS mesh 802.11p - Wireless access for the vehicular environment

802.11T -Wireless performance prediction 802.11v - Wireless network management

802.11u - Wireless interworking with external networks 802.11w - Protected Management Frames 802.11mb - Standard maintenance

802.11y - 3650-3700 MHz Operation in USA

JTC1-SC6 SC - ISO/IEC JTC1-SC6 interface

DLS SG - Direct Link Setup enhacements

QoS alignment SG - WMM and 802.11e harmonisation

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

802.11r

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

IEEE 802.11r: Introduction

Provides Fast BSS Roaming/Transition within IEEE WLAN networks meeting the real-time handover requirements without compromising the security principles Fast BSS Roaming is possible only within a certain area called the mobility domain (MD), inter-MD cases are not covered Mobility Domain (MD): Set of BSS grouped together with the same 48bit MD Identifier
TGr Roaming

BSS #13

TGr Roaming TGr Roaming

BSS #23

TGr Roaming

BSS #11

BSS #12
TGr Roaming

BSS #21

BSS #22
TGr Roaming

Mobility Domain #1

(Not in TGr scope)

Mobility Domain #2

Inter-MD Roaming (TGi)

6 2007 Nokia TUT_8_3_2007.ppt / 2007-03-08 / JJo

IEEE 802.11r: Overview

FT functionality seeks to provide handover performance for RT services (<50ms) Functionality on top of 802.11i to handle the fast security mechanisms
Resulted in a key hierarchy definition

The performance benefit is to complete authentication and key derivation before re-association to target AP FT Signaling protocol support for over-the-air (OTA) or over-the-DS (OTD) cases FT provides two mechanisms
Base mechanism Reservation that allows QoS resources to be setup before re-association

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

FT Usage Classification
Non-RSN Robust Secure Network (RSN)

Over-the-Air

OverOver-thethe-Air no RR in RSN (OTA(OTA-nono-RR)

OverOver-thethe-Air w/ RR in RSN (OTA(OTA-RR)

Over-the-DS

OverOver-thethe-DS no RR in RSN (OTD(OTD-nono-RR)

OverOver-thethe-DS w/ RR in RSN (OTD(OTD-RR)

Base Mechanism (No ResourceReservation)

ResourceReservation(RR)

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

BSS Transition: Protocol Options

Over the Air Transition: STA interacts with target AP over the air (on the specified channel) => STA is not present on the channel to receive data during this time (assuming the neighbor APs are operating in different channels) Over the DS Transition: STA utilizes current AP to redirect the transition protocol to the target AP over the DS. Remote Request Broker (RRB) will provide the forwarding/processing functionality => STA remains on channel
Fast BSS Roaming s-AP RRB t-AP RRB

CH 1 BSS #1

CH 6

BSS #2

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

Over-the-Air FT Over-the-DS FT

 Resource Reservation (RR) is to setup QoS resources in one or more target AP during FT transition mechanism RR is based on one round-trip negotiation Why RR?
RR Setup only follows successful PTK derivation STA requests certain QoS and t-AP provides as much or less QoS STA has priori knowledge of which target supports its services without degradation No delay during re-association for RR (RIC) processing Better application service quality during FT roaming Without RR, STA may realize target AP does not have enough resources at the time of reassociation => quality suffers due to lower QoS resources

Resource Reservation

Why not RR?

RR is optional for AP and STA

STA may reserve at multiple AP but use only one => cost Increased AP complexity Offline load information (QBSSLoad IE in beacon) may be sufficient to measure load AP advertises the capability in the Beacon frame STA has the choice to initiate the RR procedure

10

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

*PMK can also be Generated from

TGr Key Hierarchy

Authentication Server MSK PMK

Pre-Shared-Key (PSK) Network nodes are mutually authenticated With Secure Communication channels

R0-Key Holder

Network
PMK* PMK-R0 PMK-R1-A PMK-R1-B

Side Key Hierarchy

R1-Key Holder-A PMK-R1 PTK/GTK

R1-Key Holder-B PMK-R1 PTK/GTK

STA PMK* PMK-R0 PMK-R1 PTK/GTK

Derive
11 2007 Nokia TUT_8_3_2007.ppt / 2007-03-08 / JJo

EAP Distribution

Distribution mechanism to be defined in IETF

STA

FT Initial Association

AP

Beacon (FT Capability[MDIE]) Authentication Request (Open) Authentication Response (Open) (Re)association Request (MDIE, RSNIE) (Re)association Response (MDIE, FTIE[R0KH-ID, R1-KH-ID], RSNIE)

802.1X EAP Authentication (bypassed if PSK is used) EAPOL-Key (0, 0, 1, 0, P, 0, Anonce, 0) EAPOL-Key (0, 1, 0, 0, P, 0, Snonce, MIC, RSNIE[PMKR1Name], MDIE, FTIE) EAPOL-Key (1, 1, 1, 1, P, 0, Anonce, MIC, RSNIE[PMKR1Name], MDIE, GTK[N], FTIE, TIE[reas], TIE[key] ) EAPOL-Key (1, 1, 0, 0, P, 0, 0, MIC) 802.1X Controlled Port Unblocked

4-way handshake for PTK Derivation

Application Services setup

12

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

FT: Over-The-Air w/o Resource Reservation

STA
Ongoing Session Beacon (FT Capability[MDIE]) Handover Decision FT handshake for PTK Derivation Authentication Request (FT, MDIE, RSNIE, FTIE[Snonce, R0-KH-ID], RSNIE[PMKR0Name]) Authentication Response (FT, MDIE, RSNIE, FTIE[Anonce, Snonce, R0-KH-ID, R1-KH-ID], RSNIE[PMKR0Name])

s-AP

t-AP

Reassociation Request (MDIE, FTIE[MIC, Anonce, Snonce], RSNIE[PMKR1Name], RIC-Request)

Reassociation Response (MDIE, FTIE[MIC, Anonce, Snonce, GTK[N]], RSNIE[PMKR1Name], RIC-Response)

802.1X Controlled Port Unblocked

Session Data through new AP

13

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

FT: Over-The-DS w/o Resource Reservation

STA
Ongoing Session Beacon (FT Capability[MDIE]) Handover Decision

s-AP

t-AP

FT handshake for PTK Derivation

FT Action Request( STA, t-AP, MDIE, FTIE[Snonce, R0-KH-ID], RSNIE[PMKR0Name]) FT Action Respone (STA, t-AP, MDIE, RSNIE, FTIE[Anonce, Snonce, R0-KH-ID, R1-KH-ID], RSNIE[PMKR0Name]) Reassociation Request (MDIE, FTIE[MIC, Anonce, Snonce], RSNIE[PMKR1Name], RIC-Request)

Reassociation Response (MDIE, FTIE[MIC, Anonce, Snonce, GTK[N]], RSNIE[PMKR1Name], RIC-Response)

802.1X Controlled Port Unblocked

Session Data through new AP

14

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

FT: Over-The-Air w/ Resource Reservation

STA
Ongoing Session Beacon (FT Capability[MDIE]) Handover Decision FT handshake for PTK Derivation Authentication Request (FT, MDIE, RSNIE, FTIE[Snonce, R0-KH-ID], RSNIE[PMKR0Name]) Authentication Response (FT, MDIE, RSNIE, FTIE[Anonce, Snonce, R0-KH-ID, R1-KH-ID], RSNIE[PMKR0Name]) Authentication Confirm (FT, MDIE, FTIE[MIC, Anonce, Snonce], RSNIE[PMKR1Name], RIC-Request) RR Exchange Authentication ACK (FT, MDIE, FTIE[MIC, Anonce, Snonce], RSNIE[PMKR1Name], RIC-Response)

s-AP

t-AP

Reassociation only if QoS RR is acceptable Reassociation Request (MDIE, FTIE[MIC, Anonce, Snonce], RSNIE[PMKR1Name]) Reassociation Response (MDIE, FTIE[MIC, Anonce, Snonce, GTK[N]], RSNIE[PMKR1Name]) 802.1X Controlled Port Unblocked Session Data through new AP
15 2007 Nokia TUT_8_3_2007.ppt / 2007-03-08 / JJo

FT: Over-The-DS w/ Resource Reservation

STA
Ongoing Session Beacon (FT Capability[MDIE]) Handover Decision

s-AP

t-AP

FT handshake for PTK Derivation

FT Action Request( STA, t-AP, MDIE, FTIE[Snonce, R0-KH-ID], RSNIE[PMKR0Name]) FT Action Respone (STA, t-AP, MDIE, RSNIE, FTIE[Anonce, Snonce, R0-KH-ID, R1-KH-ID], RSNIE[PMKR0Name]) FT Action Confirm( STA, t-AP, MDIE, FTIE[Snonce, R0-KH-ID], RSNIE[PMKR1Name], RIC-Request)

RR Exchange

FT Action ACK (STA, t-AP, MDIE, RSNIE, FTIE[Anonce, Snonce, R0-KH-ID, R1-KH-ID], RSNIE[PMKR1Name], RIC-Response) Reassociation Request (MDIE, FTIE[MIC, Anonce, Snonce], RSNIE[PMKR1Name]) Reassociation Response (MDIE, FTIE[MIC, Anonce, Snonce, GTK[N]],RSNIE[PMKR1Name])

802.1X Controlled Port Unblocked Session Data through new AP

16

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

802.11r Performance

Source: Sangeetha Bangolae, Carol Bell, Emily Qi, Performance study of fast BSS transition using IEEE 802.11r, International Conference On Communications And Mobile Computing, 2006 17 2007 Nokia TUT_8_3_2007.ppt / 2007-03-08 / JJo

IETF Role
Most of 802.11 security related work in done in CAPWAP Mailing list disc. indicate some rule it out as out of scope for current charter, some indicate that there is immediate support for 802.11r in CAPWAP in at least split MAC scenarios
Authenticator and key hierarchy reside in AC AC pushes the PTK to WTP with Add-Mobile message based on 802.11r message triggering

Relevant Drafts

http://www.ietf.org/internet-drafts/draft-ietf-capwap-protocol-bindingieee80211-01.txt http://tools.ietf.org/id/draft-sarikaya-capwap-fastbss-00.txt http://www1.tools.ietf.org/html/draft-ye-capwap-fbsskey-distributionps-00

18

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

IEEE 802.11r: Timeline

Standard is quite mature but still some sticky issues that keep coming up Expected IEEE ratification Q2/08

19

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

802.11s

20

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

802.11s scope
802.11s standard defines MAC enhancements, routing, security and interworking principles for WLAN MESH networking.
MAC enhancements are concentrating to forwarded frames format, beaconing, EDCA use and power save. Routing defines one default routing protocol + enables other routing protocol usage in MESH networking Security: network authentication and security of forwarded traffic.
routing done in MAC layer

802.11s defines new device classes (supported functionality for each device next slide)

MESH Point (MP) is device, capable to operate in MESH backbone MESH AP (MAP) is device capable to operate as AP and MESH Point (MP) Non-Forwarding MP is device participating in MESH network, but does not forward any traffic (for instance operating in stand-by power save)
1-hop range entity LW-MP is WLAN terminal in enhanced ad hoc operation mode

MESH Portal is device, which connects the MESH network to IP backbone or with other MESH network. One network may have 0 multiple portals.

21

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

Mesh Point (MP) Devices and their capabilities

Feature: Uses 4 Address Association (providing the DS-service) Association (using the DS-service) To/From DS: 00 To/From DS: 01 To/From DS: 10 To/From DS: 11 Mesh Link security MDA (scheduled transmission times) DFS (5GHz Europe) Discovery & peer link establishment Path selection Forwarding Interworking Congestion Control Beaconing Synchronization Power Management (provide, support neighbors in doing so) Power Saving (actively going to doze/sleep mode) MAP M M M U U M O M M M M M O M O O MP M M M U M O M M M M M O M O O O Selfish MP non-forwarding MP M M U M O M M M M O M O O O 1-hop range entity LW-MP M U M O M M M O O O STA M U U M -

22

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

M = mandatory, U = Uses, O = Optional

Large scale MESH networks, requirements

The WLAN MESH networks are offering the same AP STA interface as normal infrastructure networks. On top of this interface the radios are forwarding the traffic to/from Internet (creating backhaul network). The requirements for backhaul and AP-STA interface are controversial:
Backhaul should transmit large frames for good throughput and efficient delivery The access network should offer good service (fast TXOP obtaining times for terminals) in order to enable efficient power save and similar service as with normal APs. Easiest solution would be to differentiate backhaul and access networks.

WLAN MESH devices are required to be cheap and simple in order to compete against fixed, wired WLAN networks and cellular networks.

23

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

Mesh Options
Each node has a single radio
Access and backhaul share radio All nodes tune to same frequency Mesh nodes use omni-directional antennas

Each node has two radios

Access and backhaul are in separate bands 2.4 GHz client access, 5 GHz backhaul

Each node has multiple radios

Client access independent from mesh backhaul

24

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

 In ad hoc use scenario devices desire to exchange data between each other. In Home network use scenario:

Small network use scenario: Ad hoc and home

Real time TV and home entertainment systems content streaming inside the home. Radio connectivity between all devices in home. Possibilities to create connectivity within neighborhood and to share the same IP backbone. Direct Link setup (DLS) (New study group starting in IEEE for DLS)

Multiple solutions enabling direct data transfer between WLAN radios:

WLAN terminals operating under the same AP. DLS is reducing transmission time over-air by reducing the amount of transmission. Requires support for DLS in both end points and in AP. Connection to infrastructure network is maintained -> terminals stay connected with AP

Ad hoc (IBSS) (Original IBSS network defined in base 802.11, enhanced in 802.11s)

MESH networking (defined in 802.11s)

The communicating terminals create 1-hop network Link specific authentication If terminal is operating only in Ad hoc mode, the infrastructure network with Internet connectivity is lost Multihop network with routing protocols and data forwarding capability Infrastructure network connectivity may be obtained through MESH forwarding. Different device roles enable some devices to operate in power save and other in full power. MESH wide authentication

25

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

 IBSS Beaconing: (joint ATIM period for all devices in the network)

802.11s MAC enhancements for ad hoc

IBSS station

Beaconing affects to network connectivity and stand-by power consumption. New concepts:

Beacon broadcaster -> one terminal transmits all beacons reduced random delay before beacon is transmitted More reliable beaconing -> the beacon transmission opportunity is not randomly selected among all nodes. The beacon broadcaster may select new beacon broadcaster and the role may be rotated in a network Enables more state information maintaining (i.e. power save mode info) and special operation mode for beacon broadcaster

26

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

Challenges in the use of ad hoc.

Device/service discovery protocols used in ad hoc should be easier.
There are multiple discovery protocols with a little different capabilities (UPnP, BonJour, etc). Not clear which should be the default protocol used by all

Simultaneous use of ad hoc and infrastructure network creates new requirements for WLAN implementation.

Encryption needs to be changed fast. Data may be received from multiple networks Networks may be operating in different channels Beacons may be transmitted with different periodicity -> challenges in the receiver scheduling

27

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

 First review in IEEE held

Status of 802.11s
Draft was not approved ~5000 comments received

Expected ratification Q4/08

28

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

802.11u

29

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

IEEE 802.11u: Interworking with External Networks

IEEE 802.11u (TGu) works on MAC enhanced to interwork with external networks (IEEE and non-IEEE) Major interworking services work items:
Network selection (utilizes 802.21 semantics) / Support for IEEE 802.21 IS queries in state-1 (unauthenticated/unassociated) Emergency call support Distribution of QoS mapping information in the core MAC Layer Management Entity (MLME) amendments to support IEEE 802.21 link services Subscription Service Provider Network (SSPN) Interface

Interworking service management is located in the Station management Entity (SME)

30 2007 Nokia TUT_8_3_2007.ppt / 2007-03-08 / JJo

Network Selection Problem

STA (clients) need to know the roaming suitability before authenticating/associating (in state-1) with the AP Roaming information includes Roaming information of various hotspots is not scalable to be configured on the client
Is this WLAN suitable for roaming? What is the SSID that client to connect? The home network (called SSPN in TGu terminology) or A trusted source that has this roaming information

Who provides this information?

But could the home SSPN be located far away? What are the query semantics used?
31 2007 Nokia TUT_8_3_2007.ppt / 2007-03-08 / JJo

How is the query routed/switched to the destination?

Network Selection
Solution
External query services are named as Generic Advertisement Services (GAS) Solution is to
Broadcast the interworking service capability over beacons/probe responses Povide a general MAC management facility in state-1 for various advertisement services
GAS Initial Request/Response GAS Comeback Request/Response

GAS type identifies a particular service query used => query protocol types are extensible One of the GAS type is IEEE 802.21 MIS query AP maintains a state for a brief time till the response is delivered
IP MAC facility encapsulating 802.21 GAS type

GAS Server

IP

802.21 MIS Server

SSPN

Local network

AP

32

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

MAC Facility: Unicast Mechanism

STA
Probe Request Probe Response (GAS Capability)

Network Selection
AP

Advertisement Server

GAS Initial Request (Req) GAS Initial Response (GAS Query ID, GAS time delay) Retrieve info for Req time delay Resp GAS Comeback Request (GAS Query ID) GAS Comeback Response (GAS Query Req, GAS Query ID, Resp)

Not defined in Specification

33 2007 Nokia TUT_8_3_2007.ppt / 2007-03-08 / JJo

MAC Facility: Multicast Mechanism

STA
Probe Request Probe Response (GAS Capability)

Network Selection
AP

Advertisement Server

GAS Initial Request (Req) GAS Initial Response (GAS Query ID, Multicast Address) Retrieve info for Req
When GASTIM count reaches 0

Resp

GAS Comeback Response (GAS Query Req, GAS Query ID, Resp) GAS Comeback Response (GAS Query Req, GAS Query ID, Resp)

GAS Comeback Response (GAS Query Req, GAS Query ID, Resp)

Not defined in Specification

34 2007 Nokia TUT_8_3_2007.ppt / 2007-03-08 / JJo

TGu Emergency (e911) call Scope

Ensure E911 call setup with best success rate under various scenarios within regulation Emergency call handling requires support from various layers, 802.11 will do its part
Call servers to handle E911 calls are deeper in network

STA already associated will have means to indicate e911 call setup to AP. Why?
AP can prioritize the traffic from that STA to improve call success rate Ensure adequate QoS as per configured AP policies Configure traffic handling in the DS (backend)

35

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

TGu Emergency (e911) call Scope - contd

STA with no authentication credentials will be allowed to initiate e911 calls Capability advertisements for Emergency support Location information is explicitly not covered here
Tgu emergency interworking capability Information about local emergency infrastructure To meet regulatory requirement Access control limited to only e911 calls

Possible for STA to use AP location, if provisioned or others (TGv) DHCP server (ECRIT)

36

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

 Public User Credentials

E911 Support with no Security Credentials

Open Auth SSID

Allow WPA capable SSID to support e911 calls A well known public user id (NAI) is used for dummy authentication AAA server downloads restricted e911 policy to AP to restrict traffic Draft standard does not discuss security keys for encryption EBR in QoS Setup

Special SSID without any security support is configured for emergency Simple MAC level solution, with no AAA involvement => Applicable for certain situations Open auth association but AP may configure this SSID to only use a certain VLAN destined for emergency use only EBR in QoS Setup

37

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

 Provides a MAC management facility for STA to request the QoS map set from AP in state-3

QoS Map Distribution

Requirement is to have completed successful EAP exchange => AP will have filtering info for that STA

A QoS map set is a map of User Priority (UP, QoS levels in 802.11) to DSCP range values Exceptions are also provided for specific DSCP value matches within the range and the corresponding UP STA shall use the corresponding UP on WLAN for the DSCP code values used in IP header QoS Map updates (if changed) are provided unsolicited

38

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

MLME Amendments due to 802.21

MLME-LinkUp.indication MLME-LinkDown.indication MLME-LinkGoingDown.indication MLME-LinkEventRollback.indication MLME-LinkParemetersChange.indication MLME-LinkHandoverImminent.indication MLME-LinkHandoverComplete.Indication

There are other MLME updates related to TGus own functionality

39

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

SSPN Interface Elements

40

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

Status of 802.11u
One group internal review held No letter ballot yet Expected ratification Q1/09

41

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

802.11v

42

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

General
Started Q3/04 Purpose of the project (as stated in PAR):
The purpose of this document is to provide amendments to the IEEE 802.11 PHY/MAC layers that enables management of attached stations in a centralized or in a distributed fashion (e.g. monitoring, configuring, and updating) through a layer 2 machanism. While the 802.11k Task Group is defining messages to retrieve information from the station, the ability to configure the station is not in its scope. The proposed Task Group will also create an Access Port Management Information Base (AP MIB). The current IEEE 802.11 specification implies that stations may be managed via a Simple Network Management Protocol (SNMP). The use of SNMP intruduces the following problems: 1. Very few stations in the market include SNMP capabilities. 2. The use of secure SNMP protocol (e.g. SNMPv3) requires significant pre-configuration of the station. 3. Management of a station may be required prior to the establishment of an IP connection. There are cases where a device must be managed because it cannot get IP connectivity. Therefore, a standarized approach to manage stations is required. 802.11 APs have significantly increased in complexity and features, which cannot be controlled via the current MIB. The Task Group needs to expand on the existing MIB (or creat a MIB) to support these new devices.
2007 Nokia TUT_8_3_2007.ppt / 2007-03-08 / JJo

43

802.11v main features

Multicast Diagnostics Event procedures

Flexible broadcast/multicast
Transition events RSNA events Peer-to-peer link events Syslog events

Diagnostics procedures Presence procedures Load balancing

STA report

Co-located interference reporting

Some modifications/enhancements to 802.11k procedures + probably more until spec. is finished

2007 Nokia TUT_8_3_2007.ppt / 2007-03-08 / JJo

44

Multicast Diagnostics
Idea is to enable very simple monitoring of broadcast/multicast receptions
In base specification there are no means to detect whether bc/mc frames are lost

Report is triggered if the STA does not receive any bc/mc traffic during specific time interval Procedures also include mechanism to indicate STAs maximum bc/mc reception rate Usage of Multicast Diagnostics
AP can get rough feeling on how reliable bc/mc transmissions are and what is maximum bc/mc data rate that can be used

45

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

Flexible broadcast/multicast service

In legacy WLAN networks broadcast and multicast delivery is not optimal from terminals power save perspective
Wake-up interval typically short (e.g. 100 ms) No indication what bc/mc frames are buffered

With FBMS it is possible to create longer sleep intervals and terminal can exactly specify the bc/mc services it is interested in Furthermore the AP can exactly indicate to which bc/mc services the buffered frames belongs to

Terminal can enter to sleep mode very quickly if no frames targeted to it are buffered If supported then missing DTIM beacons is not so crucial anymore

Includes also indication of whether the AP/network supports proxy ARP

46

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

Legacy vs. FBMS

= DTIM beacon, all the legacy power save terminals wake up

= broadcast data = multicast stream 1 (for STA1) = multicast stream 2 (for STA2)

= Normal beacon, power save terminals does not wake up

a)
STA1 and STA2 awake STA1 and STA2 awake STA1 and STA2 awake

b)
STA2 awake STA1 awake STA1 awake STA1 awake STA1 awake

47

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

Event procedures
Event procedures are meant to enable real-time diagnostics of the WLAN network
Event type Transition Purpose Used to collect information about transition events (i.e. roaming events). Can be conditional => if too many transitions during given time => report is generated Used to collect information about performed authentications

AP can request event reports from the STAs AP can set up event report conditions so that if problems occurs the STA sends report Transition events RSNA events Peer-to-peer link events Syslog events

RSNA

Four types of event procedures

Peer-to-peer Used to collect information about DLS operation

Syslog

Used to collect Syslog (IETF RFC 3164) info from the terminals

48

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

Diagnostics procedures
Provides means to diagnose and debug WLAN network problems Four types of diagnostics procedures
STA report 802.11 authentication Association 802.1X authentication
Diagnostics type STA report Purpose Used to collect information (capabilities, manufacturer info, operational info) about terminal. Used to verify whether the STA is able to perform 802.11 authentication with given parameteres Used to verify whether the STA is able to perform association with given parameteres Used to verify whether the STA is able to perform 802.1X authentication with given parameteres

802.11 authentication

Association

802.1X authetication

49

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

Presence procedures
AP and/or terminal can configure presence service
AP can configure how often and in which channels terminal(s) sends presence indications Terminal can configure how often it wants to receive location information AP can configure all the terminals or it can configure each terminal separately It is also possible to use one-time requests May include radio related parameters => signal strength based location estimate May include motion related info (i.e., is terminal static or in motion) Requested location data (local = terminal, remote = AP or peer terminal) Indicates the required location data format, resolution and accuracy Location data format: Civic, GEO (RFC 4119, RFC 3693) Resolution, encoding (RFC 3825, RFC 4119, X.694) and accuracy Actual location data (either local or remote) Location source identifier (RFC 3693) Radio information Timing information (TOA support)

Presence indications can be used to calculate terminals location

Responses to precense indication may include actual location data and/or additional info that can be used to determine location

Actual method(s) how location is determined are not specified

50

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

Load balancing
AP has possibility to command terminals to roam for load balancing reasons AP gives prioritized list of target AP candidates
Specification does not specify when the AP should/shall/should-not/shall-not use the load balancing feature AP can indicate that some APs are excluded i.e., the terminal should not try to roam to that AP if roaming to non-excluded AP is possible Not binding target AP decision is still in terminal side

51

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

Co-located interference reporting

Terminal can indicate it is realizing co-located interference that is causing performance degradation to WLAN device Typical scenarios
BT-WLAN
BT and WLAN operating in same frequency and using single antenna VoIP over WLAN to BT headset BT streaming while active WLAN data transfer Cellular harmonics may distort WLAN operation

Cellular-WLAN

BT-WLAN is big problem as there is no way to control WLAN DL transmissions With this reporting mechanism the AP can
1. Schedule WLAN DL transmissions so that degradation is minimised 2. Adjust its rate adaptation logic so that the problem is not made worse
TUT_8_3_2007.ppt / 2007-03-08 / JJo

52

2007 Nokia

Modifications to 802.11k procedures

Added triggered operation STA statistics measurement Added RSNA counters to STA statistics measurement Neighbor Report modifications (load balancing)

53

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

Status of 802.11v
One internal review held
First letter ballot assumed to start after May 2007 meeting

Expected IEEE ratification: Q4/09

54

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

802.11w

55

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

General
Started Q1/05 Purpose of the project (as stated in PAR):
The proposed project seeks to create enhancements to the IEEE 802.11 Medium Access Control layer to provide, as appropriate, mechanisms that enable data integrity, data origin authenticity, replay protection, and data confidentiality for selected IEEE 802.11 management frames including but not limited to: action management frames, deauthentication and disassociation frames. The current IEEE 802.11 standard including amendment 'i' (security) addresses security of data frames but systems are still vulnerable to malicious attack because management frames are unprotected. For example, network disruption can be caused by malicious systems generating false information and impersonating valid equipment. The work envisioned in this PAR will reduce the susceptibility of systems to such attack and is of importance to all the current applications of IEEE 802.11 and both existing and anticipated amendments. While all 802.11 users will benefit from the proposed amendment, the stakeholders are the Access Point and Network Interface Card vendors.
2007 Nokia TUT_8_3_2007.ppt / 2007-03-08 / JJo

56

General
Basic idea of 802.11w is to extend 802.11i to provide protection for selected management frames Disassociation and Deauthentication frames are considered to be especially important

If not protected then it is easy to perform DoS attack On the other hand even protection of these frames does not guarantee that DoS attacks cannot happen (there are simple ways to implement attacks)

Provides also protection for broadcast/multicast management frames

57

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

802.11y

58

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

Extensions for deployment in other non-UNII bands 802.11y

Frequency of operation (3650 3700 MHz) - US Spectrum sharing :
With multiple users sharing this spectrum through the use of contention-based protocols to minimize interference among fixed and mobile operations all licensees have the mutual obligation to cooperate and avoid harmful interference to one another Fixed stations will be allowed to operate with a peak power limit of 1W/MHz EIRP (cellular range) but Mobile and Portable Stations are limited to 40mW/MHz EIRP Fixed stations for fixed service are registered, and do not move from their civic address Base stations for mobile service are registered, and do not move from their civic address Mobile and portable stations for mobile service are not registered. Both can operate only if they can positively receive and decode an enabling signal transmitted by a base station
Portable stations are those that operate within 20 cm of human contact Mobile stations are those that operate at distances greater than, or equal to, 20 cm from human contact

Type of equipments/STAs

59

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

Extensions for deployment in other non-UNII bands 802.11y

Capabilities
All stations operating in the US 3650 MHz band shall
use CCA-Energy Detect Clear Channel Assessment to better coexist with other primary users all stations shall use Multi-Domain capability, Spectrum Management capability, Regulatory Classes and the OFDM PHY. fixed and enabling stations in the 3650 MHz band shall be capable of operation using 5-, 10-, and 20-MHz channel widths, and dependent stations are capable of operation using 5 Mhz channel widths

Channel spacing and number of channels (5 Mhz from lower band edge 3.65 GHz and upper band edge 3.7 GHz)

Channel Spacing 10 MHz 5 MHz 20 Mhz

No of channels 2 4 8

60

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

Challenges and future topics

61

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

Challenges
Amount of standardized features is increasing
Interoperability issues Variation between the deployments IEEE standards are becoming toolboxes and final decision whether the features are really implemented is done in WiFi Alliance or somewhere else How to keep WLAN simple and cheap? Terminal may include multiple of radios that may be used simultaneously Good example is VoIP call over WLAN to Bluetooth headset Active mode power consumption is tolerable Standby mode power consumption could be better

Multiradio use cases are causing some challenges in terminal side

Power consumption

62

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

Future topics
WLAN evolution
Illustration of capabilities of IMT-2000 and systems beyond IMT-2000

ITU IMT-Advanced

Local area bit rate target: 1Gbit/s Not clear whether WLAN will have any role

Systems beyond IMT-2000 will encompass the capabilities of previous systems Mobility New capabilities of systems beyond IMT-2000 High Enhanced IMT-2000
Enhancement

Maturization of existing/forthcoming features

Takes several years
Low

New mobile access

Dashed line indicates that the exact data rates associated with systems beyond IMT-2000 are not yet determined

New nomadic/local area wireless access

10 100 Peak useful data rate (Mbit/s)

1 000

Denotes interconnection between systems via networks, which allows flexible use in any environment without making users aware of constituent systems Nomadic/local area access systems Digital broadcast systems

63

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo

Summary
Many ongoing standard activities
IEEE 802.11 is in charge of functional specifications WiFi Alliance is in charge of interoperability testing Interoperability will be a challenge Different deployments will likely vary a lot from the supported features perspective

New standards radically increase amount of features in WLAN

64

2007 Nokia

TUT_8_3_2007.ppt / 2007-03-08 / JJo