March 2006

Dave Stephenson, Cisco Systems, Inc.Slide 1

doc.: IEEE 802.11-06/0268r0

Submission

Expedited Bandwidth Request

Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.

Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11.

Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair <stuart.kerry@philips.com> as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>.

Date: 2006-02-17

Name Company Address Phone email Dave Stephenson Cisco Systems 170 W. Tasman Dr.

San Jose, CA 95134

+1-408-527-7991 daves@cisco.com

Authors:

March 2006

Dave Stephenson, Cisco Systems, Inc.Slide 2

doc.: IEEE 802.11-06/0268r0

Submission

Abstract

This document describes an arguably complete proposal for requirement R9I1.

March 2006

Dave Stephenson, Cisco Systems, Inc.Slide 3

doc.: IEEE 802.11-06/0268r0

Submission

TGu Requirement R9I1

• Define IEEE 802.11 functionality which would be required to support an Emergency Call (e.g. E911) service as part of an overall, multi-layer solution. Specifically:– Capability Advertisement

– Authentication issues

March 2006

Dave Stephenson, Cisco Systems, Inc.Slide 4

doc.: IEEE 802.11-06/0268r0

Submission

Overview

• This proposal is divided into two parts– Part 1: signaling from QSTA to QAP to identify additional

information about the nature of the bandwidth request (including whether it’s an emergency call). This proposal builds upon 06/0003r0 by M. Montemurro.

– Part 2: proposal for providing 911 service to clients having only public security credentials

March 2006

Dave Stephenson, Cisco Systems, Inc.Slide 5

doc.: IEEE 802.11-06/0268r0

Submission

Background for TSPEC Signaling

• For access categories configured for mandatory admission control, a non-AP QSTA requests bandwidth using a TSPEC Request in an ADDTS action frame

• The TSPEC Request includes parameters describing the characteristics of the traffic stream, but no information on the use of the traffic stream

• To address “use” of a traffic stream, we propose the addition of an “Expedited Bandwidth” element– One of the enumerated uses is an emergency call– To make use of this element, it is the responsibility of the handset to

“connect the dots” with call signaling messages– How this is done is out of scope for TGu

• If the AP knows the “use” of the traffic stream, it can invoke additional policy which may be configured on the AP to accept the TSPEC request when it would be otherwise be denied

March 2006

Dave Stephenson, Cisco Systems, Inc.Slide 6

doc.: IEEE 802.11-06/0268r0

Submission

ADDTS Action Frame Format

Order Information

1 Category

2 Action

3 Dialog Token

4 TSPEC

5-n TCLAS (optional)

n+1 TCLAS processing (optional)

n+2 Expedited Bandwidth Request (optional)

March 2006

Dave Stephenson, Cisco Systems, Inc.Slide 7

doc.: IEEE 802.11-06/0268r0

Submission

Expedited Bandwidth Request Element

Element ID Length TSID BandwidthUse

Octets: 1 1 1 1

The benefit of this approach is that one octet is employed which easily supports numerous different bandwidth uses. Prior proposals are limited by the number of available reserved bits in the TSPEC TS_INFO field.

March 2006

Dave Stephenson, Cisco Systems, Inc.Slide 8

doc.: IEEE 802.11-06/0268r0

Submission

Bandwidth UseBW Use value Description

0 Emergency call

1 First Responder (public entity)

2 First Responder (private entity)

3 MLPP Level A

4 MLPP Level B

5 MLPP Level 0

6 MLPP Level 1

7 MLPP Level 2

8 MLPP Level 3

9 MLPP Level 4

10-255 Reserved

March 2006

Dave Stephenson, Cisco Systems, Inc.Slide 9

doc.: IEEE 802.11-06/0268r0

Submission

Bandwidth Use Description

• The lower the value of Bandwidth Use, the higher the relative priority– Emergency calls identified and have the highest priority

• Policy configured at AP defines how these values will be operated upon and is out of scope. Examples include:– No action– Pre-emptive action: delete a TS of lower priority if necessary to

make room for new TS– Use bandwidth allocated for non-voice services if priority is above

a certain value (assuming TSPEC is for AC_VO)– Interpret MLPP codes per 3GPP specification– Interpret MLPP codes per proprietary specification

March 2006

Dave Stephenson, Cisco Systems, Inc.Slide 10

doc.: IEEE 802.11-06/0268r0

Submission

Bandwidth Use Description (cont.)

• Bandwidth use extended from 06/0003r0 to include:– Public first responders and private first responders (e.g., enterprise

security department) identified

– MLPP (multi-level precedence and pre-emption) supported for “free”; with this element, the service is extended to VoWLAN• Used by subscription service for 3GPP (3GPP TS 22.067)

• Used by H.323 (ITU-T H.460.14)

• Used by military organizations (the general’s call “always” goes through)

March 2006

Dave Stephenson, Cisco Systems, Inc.Slide 11

doc.: IEEE 802.11-06/0268r0

Submission

Part 2: 911 calls from clients with public security credentials

March 2006

Dave Stephenson, Cisco Systems, Inc.Slide 12

doc.: IEEE 802.11-06/0268r0

Submission

Thoughts from an AP Perspective

• AP cannot know whether emergency service will be provided or not by SSPN – AP is a L2 device, not an application layer device– Emergency services can take different forms

• Different signaling systems, e.g., SIP, H.323, proprietary• Different codecs supported by clients (G.711, AMR, Skype-like) • 3GPP does not require emergency service to be supported when client lacks

security credentials• Not limited to voice (3GPP TS 23.167)

– AP is not a SIP user agent nor signaling endpoint so client MUST register to a call manager before emergency call can be placed.

– AP cannot by itself verify whether emergency services are being transported or bandwidth is being hijacked

– If IPSEC tunnel is used between client and gateway, AP cannot know if handset was able to successfully register with a call manager

March 2006

Dave Stephenson, Cisco Systems, Inc.Slide 13

doc.: IEEE 802.11-06/0268r0

Submission

Thoughts from an AP Perspective (cont.)

• Use EAP authentication mechanism when supplicant has security credentials (e.g., SIM card in handset)– No special security requirements as emergency call can take place

like any other call placed by an authenticated user

March 2006

Dave Stephenson, Cisco Systems, Inc.Slide 14

doc.: IEEE 802.11-06/0268r0

Submission

Thoughts from an AP Perspective (cont.)• Use EAP authentication mechanism even when supplicant doesn’t

have security credentials (e.g., no SIM card in handset)– If supplicant “knows” it doesn’t have security credentials but needs to

place an emergency call, it attempts EAP authentication with a public user account whose identity indicates the need to place an emergency call

• This is currently under consideration in 3GPP TSG SA WG2 Architecture http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_51_Denver/Docs/S2-060843.zip

• AP employs normal 802.11i and 802.1x functionality• AP does not have to allow open association to client—if client can’t register

with a call manager in SSPN, it can’t complete the emergency call anyway– SSPN’s AAA server authenticates client and provides keying material to

authenticator and supplicant, thereby securing the 802.11i link– SSPN’s AAA server provides VLAN ID back to AP (AAA servers

already support this capability)—this VLAN is the “emergency” VLAN– AP or DS infrastructure performs per-user policing for this VLAN ID

ensuring upper-limit on resource usage commensurate with an emergency call

– SSPN’s call manager routes call to proper PSAP

March 2006

Dave Stephenson, Cisco Systems, Inc.Slide 15

doc.: IEEE 802.11-06/0268r0

Submission

Thoughts from an AP Perspective (cont.)

• Client responsibilities:– Recognize the user’s request to make an emergency call

– Ensure WLAN supports QoS and Expedited bandwidth request capability

– Request location information from WLAN and pass to its call manager via signaling (client ensures LCI request is not responded to with Incapable bit set; or uses TBD TGv method)

– Select one of possibly several SSPNs advertising support for emergency service and VoIP service

March 2006

Dave Stephenson, Cisco Systems, Inc.Slide 16

doc.: IEEE 802.11-06/0268r0

Submission

Proposal

• Emergency service advertisement:– Emergency service is from SSPN advertisement, not from AP providing

network access (so 911 requirement moves to network selection cluster with consequent impact to those proposals)

– SSPN advertisement must also include whether it supports VoIP service (e.g., support for end-to-end QoS)

• AP advertises:– 802.11e capability (for QoS transport)– 802.11k/v capability (for location information)– 802.11u capability (expedited bandwidth request element)

• 802.11 security association– Employs RSN and 802.1x

• Authentication to SSPN via EAP method

March 2006

Dave Stephenson, Cisco Systems, Inc.Slide 17

doc.: IEEE 802.11-06/0268r0

Submission

Benefits of Proposal

• No changes needed to 802.11 (other than means to signal TSPEC request is for emergency purposes)

• SSPN responsible for emergency service– Validates call is routed to PSAP

– Ensures end-to-end QoS for good audio fidelity

– Knows when emergency session is over and can terminate it at that time

• Layer 2 resources are only be used for emergency service—limits DoS exposure

March 2006

Dave Stephenson, Cisco Systems, Inc.Slide 18

doc.: IEEE 802.11-06/0268r0

Submission

G1 Analysis

• All proposals (whichever requirements they address) shall describe how they minimize battery consumption for mobile devices. – This proposal has negligible effect on battery consumption.

March 2006

Dave Stephenson, Cisco Systems, Inc.Slide 19

doc.: IEEE 802.11-06/0268r0

Submission

G2 Analysis

• All proposals (whichever requirements they address) shall describe the security impact of the functions they propose. – This proposal places security impact at L3 with EAP

authentication for a client with only public security credentials.

March 2006

Dave Stephenson, Cisco Systems, Inc.Slide 20

doc.: IEEE 802.11-06/0268r0

Submission

G3 Analysis

• All proposals must allow APs to serve legacy STAs in addition to STAs that have been upgraded to 11u. Proposals must describe how this is achieved.– Legacy STAs will not be capable of obtaining emergency service

from SSPN.

March 2006

Dave Stephenson, Cisco Systems, Inc.Slide 21

doc.: IEEE 802.11-06/0268r0

Submission

Feedback?