IEEE 802 EMERGENCY SERVICES ECSG DCN: x-00-ECSG Title: Emergency Services Overview Date Submitted: September 22, 2009 Presented at IEEE 802 EmSvc ECSG session #1 in Kona, Hawaii Authors or Source(s): G. Scott Henderson (RIM) Abstract: Emergency Services Overview

IEEE 802 presentation release statements This document has been prepared to assist the IEEE 802 Em Svc ECSG. 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. 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. The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual and in Understanding Patent Issues During IEEE Standards Development Section 6.3 of the IEEE-SA Standards Board Operations Manualhttp://standards.ieee.org/guides/opman/sect6.html#6.3

Emergency Services EC SG Emergency Services Overview Sep 22, 2009

Categories Citizen to Authority (first priority) –911/112 etc calls Authority to Citizen (second priority) –Emergency Alert Broadcasts Authority to Authority (future study) –Ad Hoc emergency wireless networks –Priority/pre-emption Citizen to Citizen (future study) –ETSI requirements

Citizen to Authority Regulatory overview: –USA: FCC has the general requirements to support VoIP based 911 calls; –New and Emerging Technologies 911 Improvement Act of 2008 (extends FCC ) NENA NG covers text, video, other multimedia 911/112 type calls –Canada: CRTC –EC: ETSI EMTEL TR : Basis of requirements for communication of individuals with authorities/organizations in case of distress (Emergency call handling)TR TS : Requirements for communications from authorities/organizations to the citizens during emergenciesTS TR : Collection of European Regulatory Texts and orientationsTR TR : Emergency calls and VoIP: possible short and long term solutions and standardization activitiesTR TR Emergency Communications (EMTEL); Study on unauthenticated and unregistered access to emergency servicesTR –Japan: summarized in H. Arai and M. Kawanishi, “Emergency call requirements for IP telephony services in japan,” draft-arai-ecrit-japan-req-00, Internet Draft, Feb –some EmSvc requests may be routed to private entities SAPs

Citizen to Authority Summary technical requirements: –call request directed to correct PSAP based on point of origin (also private SAPs) –priority for emergency calls/multi media requests –unauthenticated user requests must be handled –call back (PSAP to originator) –call integrity (call is maintained, no spoofing) –handover between RATs (not in current regulatory requirements, but an anticipated extension)

Citizen to Authority Proposed solution: –develop a unique IEEE 802 Layer 2 identity (EmSvc identity) for emergency services connections (e.g. a new Ethertype) –IEEE 802 will provide the layer 1/layer 2 functionality and work with external SDOs to develop a set of behaviors at the point of network attachment (e.g. working with IETF ECRIT) which generates an IP connection request with the nearest PSAP (Public Service Answering Point). This request would include at least: MAC of originating terminal MAC (and location depending on regulatory regime) of wireless point of attachment (POA) MAC (if different from above) and location of the network POA –This solution requires support by terminals whereby attempts to make 911/112 type calls generate the unique, defined L2 EmSvc identity, plus whatever other information is available to the terminal (location, E.164 identity, language, media type, etc.). –VoIP service providers could also implement a behavior which directs a terminal attempting to make a 911/112 type call into the VoIP service provider to re-originate the connection using the specific L2 EmSvc identity (e.g. for older or non-conforming terminals). Use of the native EmSvc number for the terminal (911, 112, 119, etc.) would result in a common IEEE 802 L2 EmSvc identity which would be properly handled by the local infrastructure even if the dialed number is not correct for EmSvc in the current service area. –Unauthenticated connection request could also be supported because the unique connection identifier would result in only a connection to the PSAP. –The chain of MAC ids would be used to support PSAP Call Back to the originator. –Notes: No PHY changes are anticipated in the project. Also, no major MAC changes are anticipated and if there are any MAC changes required, these would be requested of the appropriate IEEE 802 WG. POA/PONA location would be provisioned by the network supplier, and miss matches (POA loc different than PONA loc) could be used to resolve actual location (PONA wins?). Also, AP setup could include verification of location with PONA when setting up service. Where a complex L2 infrastructure exists, MAC id and available location information (dependent on regulatory domain) of intermediate elements could be appended to the connection setup request. Development of this functionality in IEEE 802 will simplify the services provided by IETF ECRIT by providing defined/identified emergency connections and providing more reliable location information.

Citizen to Authority Harmonization –Maximum reuse and harmonization of existing IEEE 802 development (e.g. IEEE 802.1ab and 802.1x location, emergency services L2 identity, u multiple ES functions, v location, etc.). –External SDOs (in addition to ETSI EMTEL): TIA (J-STD-036, 36a, 36a-1), TIA TR 45 –The concept of using a unique emergency services layer 2 identity already exists in 3GPP and –IETF ECRIT –3GPP TS : “IP Multimedia Subsystem (IMS) emergency sessions” –3GPP TR : “Support for IMS Emergency Calls over GPRS and EPS” – (IEEE , pages 89, 745 etc.) –The proposed approach will follow these examples as much as possible for a general IEEE 802 solution. –Measurable success for this project will be defining functionality within IEEE 802 which meets regulatory requirements as listed above (in cooperation with other SDOs for layer 3 and above development). –As no PHY changes are anticipated, there should be no hardware backward compatibility issues. Software/firmware updates may be necessary.

Sample Emergency Numbers: –Some countries use separate numbers for ambulance/police/fire; others don’t. Most European countries are moving to the common ‘112’ number for the EU. Citizen to Authority

Simple Emergency Services 911 type call using EmSvc Identity: Citizen to Authority

Multi Node Emergency Services 911 type call using EmSvc Identity: Citizen to Authority

PSAP Call Back for Emergency Services 911 type call using EmSvc Identity:

Authority to Citizen Emergency Alert Broadcast (EAB) –Weather Severe Thunder Storm Tornado Hurricane Flood –Geological Tsunami Earthquake –Disaster Bomb/explosion/chemical spill Forest/major fire Airline/train crash –Local Amber Alerts Security lock downs Major accident –Multi lingual

Authority to Citizen Regulatory examples: –USA: FCC 47 Part 11 Emergency Alert System FCC CMAS –Canada: CRTC 2007d Telecom Decision CTRC : Emergency alert services –Japan: J Alert

Authority to Citizen Harmonization examples –IETF draft-baker-alert-system-00.txt ar/slides/ecrit-0/sld5.htm ar/slides/ecrit-0/sld5.htm –EC: ETSI EMTEL EN : Service Information (SI) in DVB TS v1.2.1: Requirements for communications from authorities/ organizations to individuals, groups or the general public during emergencies

Authority to Citizen Scaling Emergency Alerts –Geographic Scope Neighborhood: lockdown, lost child, accident, fire City/county: Amber Alert, civil unrest/terrorism, weather, forest/range fire State: escape prisoner, weather, quake National: pandemic, large scale terrorist attack Multi National: Hurricane, Tsunami –Urgency Eminent threat Current emergency event Recovery –Persistence Short term < x hours Medium term > x hours < y days Long term > y days –Control Authority Police/Fire Dept FEMA, etc –Severity Single individual (Amber Alert) > 1, < x individuals (large traffic accident, local fire, hostage) y individuals/property (forest/brush fire, tornado, bombing) Large scale (pandemic/plague/chemical accident/attack, tsunami, severe hurricane)

Authority to Citizen (Supplemental) FCC –Title 47 Part 11 Emergency Alert System (EAS) –Orders & NPRMs nd Report & Order and FNPRM (Next Generation EAS) st Report & Order and FNPRM (Digital) 2005 Report & Order (Wireless) 2004 NPRM (Digital) 2004 NPRM (Wireless Cable Systems) 2002 Report & Order (New Codes, e.g., Amber Alert) rd Report & Order (Channel Override) nd Report & Order (Cable Systems) 1995 Memorandum Opinion and Order (Exemption for FM Translators) 1994 Report & Order and FNPRM (Establishment of EAS)

Authority to Authority Requirement examples: –Preemption –Priority –Ad hoc networks MESH Peer to Peer

Authority to Authority ETSI –TS Requirements for communication between authorities/organizations during emergenciesTS –TR Project MESA; Service Specification Group - Services and Applications; Statement of Requirements (SoR)TR –TR Project MESA; Service Specification Group - Services and Applications; Definitions, symbols and abbreviationsTR –TR Project MESA; Service Specification Group - Services and Applications; Basic requirements TR Project MESA; Technical Specification Group - System; System OverviewTR TR –TR Project MESA; Technical Specification Group - System; System and Network ArchitectureTR

Citizen to Citizen TS : Basis of requirements for communications between individuals and between individuals and authorities whilst emergencies are in progressTS –Individuals within the emergency area Involved individuals - being directly hurt/influenced by the circumstances, e.g. by being injured. Affected individuals - being present in the emergency area, but not directly involved or hurt/influenced. –Individuals outside the emergency area Concerned individuals –There are two kinds of information that concerns close relatives and friends: Information about the accident (why it did happen, the consequences and the current situation). Information about the status of named persons.