1. Emergency Services for 802
March 2007
doc.: IEEE /0505r1
March 2007
Emergency Services for 802
Date:
Authors:
S. McCann et al
S. McCann et al

2. March 2007
doc.: IEEE /0505r1
March 2007
Note
This presentation was originally produced for an IEEE 802 tutorial on 13th March This version has been re-formatted and shortened for:
IEEE/IETF ECRIT meeting in Prague, March 2007
2nd SDO Emergency Workshop, Washington D.C. 2007
S. McCann et al
S. McCann et al

3. Content Scope & Motive Introduction Requirements IEEE 802.11
March 2007
doc.: IEEE /0505r1
March 2007
Content
Scope & Motive
Introduction
Requirements
IEEE
Use Case with IEEE IS
Vehicular Communications
Concluding Issues
S. McCann et al
S. McCann et al

4. March 2007
doc.: IEEE /0505r1
March 2007
Introduction
This presentation reflects work in progress. Its intention is to inform members about ongoing efforts to standardise emergency services within IEEE 802.
It does not attempt to provide definitive solutions to all problems.
It hopefully will encourage all projects and members to consider whether their technology will meet the future requirements of regulatory bodies for emergency service provision.
S. McCann et al
S. McCann et al

5. Scope Within this tutorial we define Emergency Services as:
March 2007
doc.: IEEE /0505r1
March 2007
Scope
Within this tutorial we define Emergency Services as:
Suitable for IEEE 802 Wireless technologies
Emergency voice calls
Network push alerts (e.g. Emergency Alert System – EAS)
Vehicle communication
non-VoIP calls (e.g. multi-media)
Three types of Emergency Service (ES)
citizen-to-authority
authority-to-citizen
authority-to-authority
S. McCann et al
S. McCann et al

6. March 2007
doc.: IEEE /0505r1
March 2007
Motive
There is an overarching concern for a consistent approach by standards development organizations (SDOs – see later) to address social policy expectations, such as full Emergency Service capability, in relation to emerging access technologies.
Location identification and callback capability represent baseline requirements for emergency service.
Call integrity is of prime concern
S. McCann et al
S. McCann et al

7. Requirements March 2007 March 2007 doc.: IEEE 802.11-07/0505r1
S. McCann et al
S. McCann et al

8. Emergency Calls in Random Countries
March 2007
doc.: IEEE /0505r1
March 2007
Emergency Calls in Random Countries
Philippines: 112 or 911; police 117
Singapore: fire and medical 995; police 999; 112 and 911 can be dialed from mobile phones
South Korea: police 112; fire and medical 119
Sri Lanka: police emergency 119 accident service
Lithuania: 112; fire 01, 101, or 011; police 02, 102, or 022; medical 03, 103, or 033. Note: the non-112 numbers are for separate emergency services differ in distinct telecommunications networks, whereas 112 available on all networks.
Vietnam: 115; police 113; fire 114
Switzerland: fire 118; police 117; medical 144; poison 145; road emergency 140; psychological support (free and anonymous) 143; psychological support for teens and children (free and anonymous) 147; helicopter air-rescue (Rega) 1414 or by radio on MHz.
S. McCann et al
S. McCann et al

9. Emergency Alert System (EAS)
March 2007
doc.: IEEE /0505r1
March 2007
Emergency Alert System (EAS)
S. McCann et al
S. McCann et al

10. IEEE 802.11 March 2007 March 2007 doc.: IEEE 802.11-07/0505r1
S. McCann et al
S. McCann et al

11. Generalized Emergency Call procedure
March 2007
doc.: IEEE /0505r1
March 2007
Generalized Emergency Call procedure
Location determination ( in cellular networks, this might be done by the network on behalf of the mobile phone) with Location Configuration Protocols (LCP)
Location representation (geo, civic: cell-id for cellular)
Mapping database discovery
Location to Service Translation (LoST)
Location conveyance
S. McCann et al
S. McCann et al

12. Issues to be solved for IEEE 802.11
March 2007
doc.: IEEE /0505r1
March 2007
Issues to be solved for IEEE
ES identification
Location information
Some procedure to fetch the location information by higher layers when initializing the call may be required.
Mobile terminal
Network edge device (e.g. Access Point, Base Station)
Unauthenticated Network Access (e.g. IEEE )
Admission Control
QoS – dedicated bandwidth
preemption
S. McCann et al
S. McCann et al

13. IEEE 802.11 Emergency Call Setup
March 2007
doc.: IEEE /0505r1
March 2007
IEEE Emergency Call Setup
S. McCann et al
S. McCann et al

14. March 2007
doc.: IEEE /0505r1
March 2007
Location
Location information is being developed by IEEE k (Geospatial) and IEEE v (Geospatial & Civic)
Request/Response paradigm
Client may request from the access point
it’s own location
the location of the access point
GeoPriv used to wrap location information
Location standard formats supported include GEO and CIVIC
Control and Measurement mechanisms to enable tracking continuously
S. McCann et al
S. McCann et al

15. Unauthenticated Network Access
March 2007
doc.: IEEE /0505r1
March 2007
Unauthenticated Network Access
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. It may be necessary to define a default EAP method along with the credentials in order enable this operation.
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
S. McCann et al
S. McCann et al

16. March 2007
doc.: IEEE /0505r1
March 2007
Admission Control
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.
S. McCann et al
S. McCann et al

17. Use Case using an IEEE 802.21 Information Server (IS)
March 2007
doc.: IEEE /0505r1
March 2007
Use Case using an IEEE Information Server (IS)
S. McCann et al
S. McCann et al

18. Architecture March 2007 AAA Carrier Network IEEE 802.21
doc.: IEEE /0505r1
March 2007
Architecture
AAA
Carrier Network
IEEE
Information Server
VLAN #5
Note: There does NOT need to be a 1-to-1 mapping between this and SSID #5.
DHCP AP
(11u-capable)
SSID #5
STA
(11u-capable)
S. McCann et al
S. McCann et al

19. IEEE 802.21 Information Server (IS)
March 2007
doc.: IEEE /0505r1
March 2007
IEEE Information Server (IS)
Networks may support means to determine, help in determining or provide the location to the clients at various layers
Link layer specific ones: LLDP[-MED], U-TDoA, D-TDoA
Link layer agnostic ones: DHCP, OMA SUPL, RELO, HELD (HTTP based)
Other SDOs defined different LCPs
Service providers need flexibility on how location services are offered in their network
IEEE provides a logical place to support a comprehensive list of all support options using IS
S. McCann et al
S. McCann et al

20. Emergency Call with 802.21 IS March 2007 March 2007
doc.: IEEE /0505r1
March 2007
Emergency Call with IS
S. McCann et al
S. McCann et al

21. Vehicular Communications
March 2007
doc.: IEEE /0505r1
March 2007
Vehicular Communications
S. McCann et al
S. McCann et al

22. Vehicular Communications
March 2007
doc.: IEEE /0505r1
March 2007
Vehicular Communications
Emergency communications is a major focus of ITS (Intelligent Transport Systems) activity, and it was a significant topic at the March 2005 ITU Workshop.
Project MESA is also helping to call attention to this area and providing high-level direction.
Two distinct areas for wireless communications:
MBW: New work item in ISO/TC204/WG16: “Specific Mobile Broadband Wireless Access Communications Systems”, e.g. IEEE e, IEEE
DSRC : IEEE 1609 continues work on application layer standards for IEEE p
S. McCann et al
S. McCann et al

23. Vehicular Communications
March 2007
doc.: IEEE /0505r1
March 2007
Vehicular Communications
DSRC/WAVE. Dedicated short-range communications (DSRC) at 5.9 GHz using an IEEE p base is now called WAVE (Wireless Access in Vehicular Environments).
The U.S. FCC has allocated 75 MHz of bandwidth for ITS applications in this band, with emphasis on public safety and, in the U.S., WAVE may become a U.S. federally funded vehicle-data network separate from the cellular network.
S. McCann et al
S. McCann et al

24. Vehicular Communications
March 2007
doc.: IEEE /0505r1
March 2007
Vehicular Communications
Mobile wireless broadband (MWB) represents an important part of a public sector (particularly public safety) solution. MWB can provide a consistent and robust capacity that can serve routine operations, but provide priority for emergencies.
MWB is useful for commercial applications of ITS as well as to support public agency and public safety applications, due to its ability to function well over large distances and at high travel speeds. It is vitally important for commercial and public uses of MWB to remain consistent with one another, including the ability to prioritise messages, especially in case of emergencies.
S. McCann et al
S. McCann et al

25. 2nd SDO emergency services coordination workshop
March 2007
doc.: IEEE /0505r1
March 2007
2nd SDO emergency services coordination workshop
2nd SDO Emergency Services Workshop hosted by the U.S. Department of Transportation (DOT).
The workshop will be held April 10, 11 & 12, 2007, from 8:30 am - 6:00 pm., in the Jefferson Building of the Library of Congress, located at 101 Independence Avenue SE in Washington, D.C.
Please find updated information at this webpage:
S. McCann et al
S. McCann et al

26. Concluding Issues March 2007 March 2007 doc.: IEEE 802.11-07/0505r1
S. McCann et al
S. McCann et al

27. March 2007
doc.: IEEE /0505r1
March 2007
Concluding Issues
Don’t assume that IEEE 802 technologies can already support all ES requirements:
call back facilities ?
terminal location ? geospatial or civic?
does Civic location, make sense, for large scale systems?
How far do we want to pre-empt upcoming regulations?
2 years?
10 years?
What does the market require?
Similar issues to Legal Intercept?
Does IEEE 802 want closer liaisons with other SDOs
Comments welcome
S. McCann et al
S. McCann et al