May 2006
doc.: IEEE 802.11-06/0616r0
IEEE P802.11
Wireless LANs
Emergency Call Problem Statement
Date: 2006-05-05
Author(s):
Name
Stephen McCann
Company
Roke Manor
Research (A
Siemens
Company)
Address
Phone
Roke Manor, Old Salisbury
Lane, Romsey, Hampshire,
SO51 0ZN, UK
+44 1794 833341
email
[email protected]
Abstract
The following document provides a quick introduction to the problem referred to as emergency call support, and
explains the motivation behind addressing this problem specifically within IEEE 802.11u, and desirable properties
of the solution.
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
<[email protected]> 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 <[email protected]>.
Submission
page 1
Stephen McCann (Roke Manor Research)
May 2006
doc.: IEEE 802.11-06/0616r0
Contents
INTRODUCTION .......................................................................................................................................................... 3
HIGHER LAYER SUPPORT........................................................................................................................................... 3
KEY COMPONENTS .................................................................................................................................................... 5
ASSUMPTIONS............................................................................................................................................................ 6
SYSTEM ASPECTS FOR SUPPORTING EMERGENCY SERVICES ...................................................................................... 6
Solution Space ...................................................................................................................................................... 6
SCENARIOS ................................................................................................................................................................ 6
UNAUTHENTICATION ACCESS.................................................................................................................................... 7
AUTHENTICATION ACCESS ........................................................................................................................................ 7
REFERENCES .............................................................................................................................................................. 7
Submission
page 2
Stephen McCann (Roke Manor Research)
May 2006
doc.: IEEE 802.11-06/0616r0
Introduction
The following document provides a quick introduction to the problem referred to as emergency call support, and
explains the motivation behind addressing this problem specifically within IEEE 802.11u, and desirable properties
of the solution.
Background
With the proliferation of VoWLAN capabilities and improvement in WLAN mobility IEEE 802.11 networks are
being increasingly used to support Voice calls. Various devices with WiFi capability are now supporting Voice calls
and these devices are also required to support Emerency Services, e.g. e911 in North Amreica and e112 in Europe.
Supporting emergency services requires a multi-layer solution with support at various layers. Apart from MAC level
access and support for transfer of data between STA and AP with appropriate QoS there is a need to setup the call,
conduct call control and management, and use an appropriate standardized audio codec.
Current IEEE 802.11 solutions provide no special handling for emergency services. Currently there are no
mechanisms for a user to determine whether an access point can provide any support for emergency services. In
order to use a public access point a user must go through the standard authentication process (e.g. EAP-based or
UAM) before being able to use the access point for emergency calls. This requires user credentials to be available,
and slows down the process of joining the network. Once the user has access to the network, there is no mechanism
to prioritise their emergency traffic over that of other users.
Location information may also be required as part of an emergency services solution. However, this is outside the
scope of IEEE 802.11u. It is believed that IEEE 802.11k together with IEEE 802.11v are working on this.
There is a need to support these emergency services both when the user has a relationship with the IEEE 802.11
network (credentials to access the network) and also when it does not have any relationship with the IEEE 802.11
network. In the latter case the STA must be able to access the network in unauthenticated state and make an
emergency service call. (As a use case consider the example when a user arrives in a new country and needs to make
an emergency call where it has no relationship with current network. However all IEEE 802.11 networks (such as
enterprise and private networks at home) may not be required to support these emergency services.
Higher Layer Support
It is essential to distinguish between IEEE 802.11 emergency services, and support of higher layer emergency
services. By “IEEE 802.11 emergency services” we refer to the direct support in IEEE 802.11 of such services,
independently of what solutions are adopted at higher protocol layers.
Within North America, if the user dials “911” in a VoIP application (e.g. SIP based), the VoIP application may
simply setup a SIP call, in which case it is transparent to IEEE 802.11. This would result in the establishment of a
higher layer emergency service. In other cases, the terminal may react by dropping the connections for the VoIP
application, and use the IEEE 802.11 emergency calls solution.
Submission
page 3
Stephen McCann (Roke Manor Research)
May 2006
doc.: IEEE 802.11-06/0616r0
SSPN
AAA Server
Local Network
AAA Proxy
Gateway
IEEE 802.11
AN
Emergency Call
Network
STA
Figure 1: Public Access Architecture
Submission
page 4
Stephen McCann (Roke Manor Research)
May 2006
doc.: IEEE 802.11-06/0616r0
Enterprise Network
AAA Server
Gateway
IEEE 802.11
AN
Emergency Call
Network
STA
Figure 1 : Enterprise Architecture
Key Components
Three key components of an IEEE 802.11u emergency services solution are:
1) Network selection – determining 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 (TGk/v), availability of appropriate QoS services
(TGe/v), availability of network access in different states (TGu) and availability of a high level entity to
manage overall call process (broadcast of appropriate SSPN).
2) Network join – the STA needs to be able to join the network without any user credentials. Network access:
The user should be able to access the network and make an emergency call both when it has credentials to
access the network (State 3) and also when it does not have credentials to access the network (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 802.11,
802.16, etc. as well.
3) Admission control and traffic conditioning – the emergency services traffic needs to be admitted to the
network as a high priority, and given appropriate QoS treatment. In addition, the AP 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 e911 call. However for unauthenticated users
there needs to be some implementation of rate control to limit the impact of rogue users making crank e911
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 at the 802.11 level. Other higher layers in the
system need to recognize this and take appropriate steps.
Submission
page 5
Stephen McCann (Roke Manor Research)
May 2006
doc.: IEEE 802.11-06/0616r0
4) Fast BSS transition solutions as developed by TGr should contine to apply for all cases under which user
makres an e911 call. Solutions developed to support e911 Emergency calling should not impact
mechanisms developed by TGr.
Assumptions
A number of assumptions have been made:
1) It is assumed that there is a high layer standardized protocol (or protocol suite) for making emergency calls
or using any other emergency services.
2) Any authentication or encryption of the emergency services can occur at the higher layer rather than at the
MAC layer.
3) Maintenance of an existing connection is not required when the STA needs to make use of the emergency
services. A pre-existing association with the AP could be discarded prior to the emergency call. Typically,
in today’s networks supporting emergency services, there is no need and no interest in maintaining the
current services and connections, since the priority is on the establishment of emergency services.
4) The access point separates the backhaul of emergency services traffic from other traffic. This may be in the
form of a separate physical link, dedicated VLAN, tunnelling protocol, etc.
5) When using the emergency communications access only emergency services can be accessed.
System aspects for supporting Emergency Services
Different signaling systems such as SIP, H.323, etc. can be deployed for supporting emergency calls. Clients can
also use different codecs such as G.711, AMR, Skype-like, etc. The access network like IEEE 802.11 by itself
cannot ensure that all factors are compatible for the emergency call to actually take place. The client device needs to
register with a call manager (SIP agent or some other signaling endpoint) for the call to be placed successfully. The
call manager may also verify that an appropriate emergency call is being placed so that appropriate level of
resources can be granted to the emergency call.
Solution Space
As in a cellular network, it is proposed that a user can make use of the emergency call service either by using
existing credentials, or by using an explicit unauthenticated access mechanism.
One of the security challenges is that the unauthenticated user should not be able to interfere with broadcast traffic
of other users, but does need to have broadcast support (for DHCP, ARP, etc).
Scenarios
The solutions described below primarily address the public access hotpot situation. However, consideration has to
be made for both enterprise and home scenarios, where emergency call provision may not be required. This may
result in an optional standard for the public access hotspot.
There are also some corner case scenarios, such as:
1.
Public access hotspots, which provide local intranet services only (e.g. airport timetables and departure
information), until authentication and payment is received from the user , whereupon full internet use is
authorised.
2.
Enterprise networks which support voice services, but are not connected to a fully blown AAA backend
infrastructure. In addition, some operators may not want to tie their emergency call authentication
exchange to AAA infrastructure that may be outside of their control - whilst AAA infrastructure has to be
reliable, it currently doesn't have strict high availability requirements on it
Submission
page 6
Stephen McCann (Roke Manor Research)
May 2006
doc.: IEEE 802.11-06/0616r0
Unauthentication Access
For the unauthenticated access mechanism there are several candidate techniques:
1.
Virtual AP (here referred to as “VAP solution”)
One solution to the support of unauthenticated users is for the emergency service to be provided on a
separate virtual AP. This means that the emergency user broadcast traffic is separated from that of normal
users (and the unauthenticated user does not need their group key). In particular, the solution should
ensure that unauthenticated emergency users cannot interfere with the broadcast traffic (such as DHCP,
ARP) of other authenticated users.
2.
Signalling in Association messages (here referred to as “direct signalling solution”)
An alternative to the virtual AP solution is to explicitly signal in the association exchange (direct
signalling solution) that the association is being made for the emergency calls service. No authentication
(and no 4-way handshake) is performed. The broadcast traffic must then be separately managed for the
emergency service user (which is sent unauthenticated in the clear) and the authenticated users (which
share a group key).
3.
New Ethertype for Emergency Services
The IEEE 802.1x port access entity shall allow data frames using this new Emergency services ethertype
to pass through it’s uncontrolled port. Since the uncontrolled port is always open, frames of the
emergency call service shall always pass through this port, irrespective of authentication or whether keys
are in place or not. Further this mechanism is now scalable across different networks since the same
ethertype can be used across different networks.
Authentication Access
Since this scenario implies that the user is already authenticated, a layer 3 session will already be in place, so that
end-to-end emergency call services can be provided. Hence it is not required for any standardisation to be put in
place within IEEE 802.11 and therefore this scenario can be regarded as out of scope.
References
[1] 11-06-0280r0
[2] 11-06-0288r0
[3] 11-06-0290r0
Submission
page 7
Stephen McCann (Roke Manor Research)