1. Evolving Emergency Services Capabilities of IEEE 802.11
October 2006
doc.: IEEE /1563r0
October 2006
Evolving Emergency Services Capabilities of IEEE
Date:
Authors:
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 < 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 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
Harry Worstell, AT&T Research
Harry Worstell, AT&T Research

2. Evolving Emergency Services Capabilities of IEEE 802.11
October 2006
doc.: IEEE /1563r0
October 2006
Abstract
Evolving Emergency Services Capabilities of IEEE
Harry Worstell, AT&T Research
Harry Worstell, AT&T Research

3. October 2006
doc.: IEEE /1563r0
October 2006
Introduction
IEEE is addressing the three following aspects of Emergency Services provision:
Emergency Service Identification
Location
Unauthenticated Network Access
The general intent is to amend the IEEE standard at layer 1 and layer 2 to provision secure WLAN systems with these capabilities over the air interface.
Harry Worstell, AT&T Research
Harry Worstell, AT&T Research

4. This Presentation Background Assumptions Architecture
October 2006
doc.: IEEE /1563r0
October 2006
This Presentation
Background
Assumptions
Architecture
Emergency Service Identification
Location
Unauthenticated Network Access
Admission Control
Next Steps
Harry Worstell, AT&T Research
Harry Worstell, AT&T Research

5. October 2006
doc.: IEEE /1563r0
October 2006
Background I
Different signaling systems such as SIP, H.323, etc. can be deployed for supporting emergency calling. Clients can also use different codecs such as G.711, AMR, Skype-like, etc.
The access network (i.e. IEEE ) cannot ensure that all factors are compatible for the emergency call to actually take place. The client may have to register with a call manager (e.g. SIP agent) for the call to be placed successfully. The call manager may also verify that an emergency call is being placed so that appropriate level of resources can be granted to the emergency call.
Harry Worstell, AT&T Research
Harry Worstell, AT&T Research

6. October 2006
doc.: IEEE /1563r0
October 2006
Background II
Therefore, it is essential to distinguish between the minimum level of support provided by IEEE emergency services, and support of emergency services at higher layers (i.e. above layer 2). By “IEEE emergency services” we refer to the direct support in IEEE of such services, independently of what solutions are adopted at higher protocol layers.
Under all circumstances, changes to the IEEE layer 2 should be kept to the minimum necessary and only guarantee priority for emergency traffic both for the initial call establishment and during an ongoing emergency call.
Harry Worstell, AT&T Research
Harry Worstell, AT&T Research

7. October 2006
doc.: IEEE /1563r0
October 2006
Assumptions
It is assumed that there is a high layer standardized protocol (or protocol suite) for making emergency calls or using any other emergency services.
Any authentication or encryption of the emergency services can occur at the higher layer rather than at the MAC layer.
Maintenance of an existing connection is not required when the client needs to make use of the emergency services. A pre-existing association with the access point could be discarded prior to the emergency call.
The access point may separate the backhaul of emergency services traffic from other traffic, for an unauthenticated client. This may be in the form of a separate physical link, dedicated VLAN, tunnelling protocol, etc.
Harry Worstell, AT&T Research
Harry Worstell, AT&T Research

8. Public Access Architecture
October 2006
doc.: IEEE /1563r0
October 2006
Public Access Architecture
Local Network
Client
IEEE AN
AAA Proxy
Gateway
Subscriber Network
AAA Server
Emergency Call Network
Harry Worstell, AT&T Research
Harry Worstell, AT&T Research

9. October 2006
doc.: IEEE /1563r0
October 2006
Architecture
Diagram shows an example architecture, although scope of IEEE AN (access network) is quite small.
Standard signaling passes to the AAA server in the subscriber network via the AAA proxy. Traffic then follows through the Gateway.
Emergency signaling is re-directed by the AAA proxy to an emergency call network.
In both cases traffic then follows through a gateway.
Harry Worstell, AT&T Research
Harry Worstell, AT&T Research

10. Emergency Service Identification
October 2006
doc.: IEEE /1563r0
October 2006
Emergency Service Identification
Requirement
Determine whether the network provides support for emergency services. There needs to be an indication from the network about it’s ability to support Emergency services.
There needs to be an indication for
availability of location services
availability of appropriate QoS services
availability of network access in different states
availability of a high level entity to manage overall call process (broadcast of appropriate SSPN).
Harry Worstell, AT&T Research
Harry Worstell, AT&T Research

11. Emergency Service Identification
October 2006
doc.: IEEE /1563r0
October 2006
Emergency Service Identification
Solution
Access Network support is indicated to the Station (mobile terminal)
Signaled using capability bit in either the beacon or probe response
Assumptions:
Access networks can be isolated intranets
Not all access networks are VoIP capable
Harry Worstell, AT&T Research
Harry Worstell, AT&T Research

12. October 2006
doc.: IEEE /1563r0
October 2006
Location
Requirement
Determine whether the network provides support for location services.
There needs to be an indication from the network about it’s ability to support Location services.
Network mechanisms to help determine location while in motion and stationary
Secure mechanisms for treating location
There needs to be an indication for
availability of location service types
availability of location accuracies supported
availability of location formats and encodings supported
Geo, CIVIC…etc
Text, binary…etc
Harry Worstell, AT&T Research
Harry Worstell, AT&T Research

13. October 2006
doc.: IEEE /1563r0
October 2006
Location
Solution
Location information is being developed by IEEE k and IEEE v
Request/Response paradigm
Client may request from the access point
it’s own location
the location of the access point
GeoPriv (RFC 4119) used to wrap location information
Location standard formats supported include GEO and CIVIC
Control and Measurement mechanisms to enable tracking continuously
Harry Worstell, AT&T Research
Harry Worstell, AT&T Research

14. Unauthenticated Network Access
October 2006
doc.: IEEE /1563r0
October 2006
Unauthenticated Network Access
Requirement
The client needs to be able to join the network without any user credentials. The user should be able to access the network and make an emergency call both when it has credentials to access the network (IEEE State 3) and also when it does not have credentials to access the network (IEEE State 1).
In both cases the user should preferably use a common mechanism to initiate the emergency call.
It would be preferable if this can be a common access mechanism across different 802 networks such as IEEE , IEEE , etc.
Harry Worstell, AT&T Research
Harry Worstell, AT&T Research

15. Unauthenticated Network Access
October 2006
doc.: IEEE /1563r0
October 2006
Unauthenticated Network Access
Solution
Public user credentials. In this situation, a client uses the defined network selection method to query candidate networks to determine which one (or several) supports VoIP, end-to-end QoS and emergency services. Once this has been determined, the client associates to the SSID corresponding to the chosen network using public user credentials.
Use an SSID configured for Open Authentication, that is only suitable for obtaining emergency service (i.e., and not suited for obtaining other hotspot services such as internet access). Network elements necessary to complete an emergency call are reachable via this SSID. How to reach these network elements (e.g., a Call Manager) and which protocol to use (e.g., SIP) are outside the scope of IEEE
Harry Worstell, AT&T Research
Harry Worstell, AT&T Research

16. Admission Control Requirement
October 2006
doc.: IEEE /1563r0
October 2006
Admission Control
Requirement
Admission control and traffic conditioning - the emergency call traffic needs to be admitted to the network as a high priority, and given appropriate QoS treatment. The access point needs to limit the use of the emergency service network access to emergency service traffic.
The network should provide a mechanism for appropriate QoS capabilities to initiate the emergency call. However for unauthenticated users there needs to be some implementation of rate control to limit the impact of rogue users making hoax emergency calls.
The possibility of DoS (Denial of Service) attack already exists when supporting emergency services for unauthenticated users and not much can be done about it within IEEE Other higher layers in the system need to recognize this and take appropriate steps.
Harry Worstell, AT&T Research
Harry Worstell, AT&T Research

17. Admission Control Solution
October 2006
doc.: IEEE /1563r0
October 2006
Admission Control
Solution
A QoS enabled client requests bandwidth using a TSPEC Request in an action frame.
Currently a TSPEC Request includes parameters describing the characteristics of the traffic stream, but no information on the actual use of the traffic stream.
To indicate emergency call initiation, it is proposed that a new “Expedited Bandwidth Request” element is used. It is the responsibility of the client to transmit this element.
Harry Worstell, AT&T Research
Harry Worstell, AT&T Research

18. Next Steps All solutions are still subject to approval by IEEE 802.11
October 2006
doc.: IEEE /1563r0
October 2006
Next Steps
All solutions are still subject to approval by IEEE
Comments are appreciated from the Emergency Services Community.
Harry Worstell, AT&T Research
Harry Worstell, AT&T Research

19. Contacts Harry Worstell : IEEE 802.11 Vice-chair
October 2006
doc.: IEEE /1563r0
October 2006
Contacts
Harry Worstell : IEEE Vice-chair
Richard Paine : IEEE k chairman
Stephen McCann : IEEE u chairman
Pat Calhoun : IEEE v chairman
Harry Worstell, AT&T Research
Harry Worstell, AT&T Research

20. References 11-06-0009-00-000v-location-presentation.ppt
October 2006
doc.: IEEE /1563r0
October 2006
References
v-location-presentation.ppt
u-japanese-emergency-call-regulation.ppt
u-emergency-call-problem-statement.doc
u-emergency-services-with-expedited-bandwidth-request.doc
RFC 4119, “A Presence-based GEOPRIV Location Object Format”
Harry Worstell, AT&T Research
Harry Worstell, AT&T Research