doc.: IEEE /0450r0 Submission March 2006 Eleanor Hepworth, Siemens Roke ManorSlide 1 Proposal for Emergency Service Support Notice: This document has been prepared to assist IEEE 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 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 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at. Date: Authors:

doc.: IEEE /0450r0 Submission March 2006 Eleanor Hepworth, Siemens Roke ManorSlide 2 Abstract This proposal addresses requirement R9I1: Define IEEE functionality which would be required to support and Emergency Call service as part of an overall, multi-layer solution.

doc.: IEEE /0450r0 Submission March 2006 Eleanor Hepworth, Siemens Roke ManorSlide 3 Scope The solution developed is assumed to be part of a larger emergency call infrastructure. However, it is not within the scope of this proposal to define the complete service. This proposal does not consider location aspects, these are in scope of other IEEE TGs.

doc.: IEEE /0450r0 Submission March 2006 Eleanor Hepworth, Siemens Roke ManorSlide 4 Solution Components Network Detection: determining whether the network provides support for emergency services. This is an extension of the network selection process. Network Join: STA needs to be able to join the network without any credentials. Admission Control and Traffic Conditioning: emergency services traffic needs to be admitted to the network as high priority, and given appropriate QoS treatment.

doc.: IEEE /0450r0 Submission March 2006 Eleanor Hepworth, Siemens Roke ManorSlide 5 Issues Consensus that ES traffic should be prioritised over the air –Therefore, need some way to correlate between prioritisation request and traffic using it This could be implemented in a number of ways; but there are trade-offs –If ES call transparent to MAC, network policy must prevent applications abusing the service –If MAC is ES aware, it’s easier to police the air interface, but with an associated loss in transparency –If MAC has to be ES aware, it implies that existing associations cannot be used How are ESs supported in the rest of the network? –This is out of scope of the group to define, but may impact aspects of the solution –Is the AP hard wired to a particular ES “server” –Who provides the ES support, is it the responsibility of the user’s SSPN?

doc.: IEEE /0450r0 Submission March 2006 Eleanor Hepworth, Siemens Roke ManorSlide 6 Assumptions There is a higher layer standardised protocol for making emergency calls Authentication or encryption of the emergency services can be implemented at higher layers Maintenance of the existing connection is not required AP separates backhaul of emergency services traffic from other traffic When using an emergency services connection, only emergency services can be accessed

doc.: IEEE /0450r0 Submission March 2006 Eleanor Hepworth, Siemens Roke ManorSlide 7 Proposed Architecture Based on use of Virtual APs –These provide open access to limited connectivity at Layer 3 –Emergency Service are configured across an ESS –Capability is advertised in an IE included in the Beacon/Probe Response Configuration of the service is flexible, and could be different for Public or Private Enterprise networks

doc.: IEEE /0450r0 Submission March 2006 Eleanor Hepworth, Siemens Roke ManorSlide 8 Network Selection Advertisement of emergency service support is provided by an Interworking Capability IE. This is included in Beacon and Probe. Element IDLength Interworking Capabilities Octets: 11 2 Emergency Call Support Reserved Bits: 114 Bit 0Bit 1Bit 15

doc.: IEEE /0450r0 Submission March 2006 Eleanor Hepworth, Siemens Roke ManorSlide 9 Network Join Use of emergency services is implied by the user associating with the virtual AP. The AP is configured for open access, so no authentication exchange takes place.

doc.: IEEE /0450r0 Submission March 2006 Eleanor Hepworth, Siemens Roke ManorSlide 10 Admission Control and Traffic Conditioning TSINFO field of the TSPEC is used to indicate that the traffic stream is for an emergency service STA could use its existing association to perform emergency signalling –May be difficult to verify that it is an emergency call in progress however. The emergency service bit not only provides prioritisation of the traffic stream, it may also initiate other related functionality in the AP, e.g. location determination.

doc.: IEEE /0450r0 Submission March 2006 Eleanor Hepworth, Siemens Roke ManorSlide 11 Admission Control and Traffic Conditioning In order to avoid abuse of this service, higher layers must implement filtering to restrict traffic to only that required for an emergency service to particular destinations.

doc.: IEEE /0450r0 Submission March 2006 Eleanor Hepworth, Siemens Roke ManorSlide 12 Advantages and Disadvantages Advantages –Can be used in private enterprise as well as public networks –The current IEEE state machine and security associations are not changed The “E911” BSS independently defines any security associations and policies needed. Disadvantages –Legacy STAs may continually try to attach to what is inherently an open access point without realising access to higher layer services is restricted. –Policing admission control on the air interface needs some backend policy co-ordination among the components.

doc.: IEEE /0450r0 Submission March 2006 Eleanor Hepworth, Siemens Roke ManorSlide 13 General Requirements R9G1: this proposal does not impact battery consumption (no changes to the IEEE protocol) R9G2: support for unauthenticated access to emergency services creates an insecure ESS that may have to co-exist with secure infrastructure. It is expected that higher layer policy and filtering will prevent misuse of the service. R9G3: STAs that are not TGu capable may attempt to associate with the emergency service ESS without realizing that access to other network services is prohibited.