1. doc.: IEEE 802.11-06/0268r0 Submission March 2006 Dave Stephenson, Cisco Systems, Inc.Slide 1 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, 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 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.http:// ieee802.org/guides/bylaws/sb-bylaws.pdfstuart.kerry@philips.compatcom@ieee.org Date: 2006-02-17 Authors:

2. doc.: IEEE 802.11-06/0268r0 Submission March 2006 Dave Stephenson, Cisco Systems, Inc.Slide 2 Abstract This document describes an arguably complete proposal for requirement R9I1.

3. doc.: IEEE 802.11-06/0268r0 Submission March 2006 Dave Stephenson, Cisco Systems, Inc.Slide 3 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

4. doc.: IEEE 802.11-06/0268r0 Submission March 2006 Dave Stephenson, Cisco Systems, Inc.Slide 4 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

5. doc.: IEEE 802.11-06/0268r0 Submission March 2006 Dave Stephenson, Cisco Systems, Inc.Slide 5 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

6. doc.: IEEE 802.11-06/0268r0 Submission March 2006 Dave Stephenson, Cisco Systems, Inc.Slide 6 ADDTS Action Frame Format OrderInformation 1Category 2Action 3Dialog Token 4TSPEC 5-nTCLAS (optional) n+1TCLAS processing (optional) n+2Expedited Bandwidth Request (optional)

7. doc.: IEEE 802.11-06/0268r0 Submission March 2006 Dave Stephenson, Cisco Systems, Inc.Slide 7 Expedited Bandwidth Request Element Element IDLengthTSIDBandwidth Use Octets:1111 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.

8. doc.: IEEE 802.11-06/0268r0 Submission March 2006 Dave Stephenson, Cisco Systems, Inc.Slide 8 Bandwidth Use BW Use valueDescription 0Emergency call 1First Responder (public entity) 2First Responder (private entity) 3MLPP Level A 4MLPP Level B 5MLPP Level 0 6MLPP Level 1 7MLPP Level 2 8MLPP Level 3 9MLPP Level 4 10-255Reserved

9. doc.: IEEE 802.11-06/0268r0 Submission March 2006 Dave Stephenson, Cisco Systems, Inc.Slide 9 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

10. doc.: IEEE 802.11-06/0268r0 Submission March 2006 Dave Stephenson, Cisco Systems, Inc.Slide 10 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)

11. doc.: IEEE 802.11-06/0268r0 Submission March 2006 Dave Stephenson, Cisco Systems, Inc.Slide 11 Part 2: 911 calls from clients with public security credentials

12. doc.: IEEE 802.11-06/0268r0 Submission March 2006 Dave Stephenson, Cisco Systems, Inc.Slide 12 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

13. doc.: IEEE 802.11-06/0268r0 Submission March 2006 Dave Stephenson, Cisco Systems, Inc.Slide 13 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

14. doc.: IEEE 802.11-06/0268r0 Submission March 2006 Dave Stephenson, Cisco Systems, Inc.Slide 14 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 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

15. doc.: IEEE 802.11-06/0268r0 Submission March 2006 Dave Stephenson, Cisco Systems, Inc.Slide 15 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

16. doc.: IEEE 802.11-06/0268r0 Submission March 2006 Dave Stephenson, Cisco Systems, Inc.Slide 16 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

17. doc.: IEEE 802.11-06/0268r0 Submission March 2006 Dave Stephenson, Cisco Systems, Inc.Slide 17 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

18. doc.: IEEE 802.11-06/0268r0 Submission March 2006 Dave Stephenson, Cisco Systems, Inc.Slide 18 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.

19. doc.: IEEE 802.11-06/0268r0 Submission March 2006 Dave Stephenson, Cisco Systems, Inc.Slide 19 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.

20. doc.: IEEE 802.11-06/0268r0 Submission March 2006 Dave Stephenson, Cisco Systems, Inc.Slide 20 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.

21. doc.: IEEE 802.11-06/0268r0 Submission March 2006 Dave Stephenson, Cisco Systems, Inc.Slide 21 Feedback?