21-09-0071-00-0000 1

IEEE 802 EMERGENCY SERVICES ECSG DCN: 00-09-000x-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

21-09-0071-00-0000 2

IEEE 802 presentation release statementsThis 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 <http://standards.ieee.org/guides/opman/sect6.html#6.3> and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/guide.html> 

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 05-116 has the general requirements to support VoIP based 911 calls;

– New and Emerging Technologies 911 Improvement Act of 2008 (extends FCC 05-116)

• NENA NG 9-1-1 covers text, video, other multimedia 911/112 type calls – Canada: CRTC 2005-21– EC: ETSI EMTEL

• TR 102 180: Basis of requirements for communication of individuals with authorities/organizations in case of distress (Emergency call handling)

• TS 102 182: Requirements for communications from authorities/organizations to the citizens during emergencies

• TR 102 299: Collection of European Regulatory Texts and orientations • TR 102 476: Emergency calls and VoIP: possible short and long term solutions and

standardization activities• TR 102 758 Emergency Communications (EMTEL);

Study on unauthenticated and unregistered access to emergency services – 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. 2005

– 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, 802.16 emergency services L2 identity, 802.11u multiple ES functions, 802.11v 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 802.16

– IETF ECRIT– 3GPP TS 23.167: “IP Multimedia Subsystem (IMS) emergency sessions”– 3GPP TR 23.869: “Support for IMS Emergency Calls over GPRS and EPS” – 802.16 (IEEE 802.16-2009, 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:Country Number Country Number Argentina 101 Japan 110 Australia 000 Mexico 08 Brazil 190 Moscow 051 Canada 911 New Zeeland 111 Columbia 123 Philippines 117 Denmark 112 Poland 997 France 17 Romania 961 Germany 110 South Africa 112 Greece 100 Spain 532 Iceland 0112 Sweden 112 Israel 100 Thailand 191 Italy 112 U.S.A. 911 Jamaica 119 UK 999

–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:

User

Terminal Link PONAAP/Router

Internet

PSAP

1

4

3

2

1. User originates an emergency call. Terminal initiates connection using L2 EmSvc identity2. Link provides connection (802.3, .11, .16, etc.)3. PONA (AP/Router combined) receives EmSvc connection request from terminal, sets up SIP connection to local PSAP only. Terminal MAC & location and PONA MAC & location, plus other EmSvc info such as user terminal id, etc are included in the SIP request (IETF ECRIT format)

Citizen to Authority

Multi Node Emergency Services 911 type call using EmSvc Identity:

User

Terminal 802.11 Link

PONASwitch/Router

PSAP

1

4

32

1. User originates an emergency call. Terminal initiates connection using L2 EmSvc identity2. Link provides 802.11 connection to Node 13. Node 1 connects 802.11 with 802.16d links4. Link provides 802.16d connection to Node 25. Node 2 connects 802.16d link with 802.3 local LAN6. Link provides 802.3 conncection to PONA7. PONA (Switch/Router combined) receives EmSvc connection request from terminal via intermediate nodes and links, sets up SIP connection to local PSAP only. Terminal MAC & location, Node 1 MAC & location, Node 2 MAC & location and PONA MAC & location, plus other EmSvc info (user terminal E.164, language, etc.) are included in the SIP request (IETF ECRIT format)

802.3 Link5

Node 2

POA/Node 1

6

7

The Behavior in Nodes 1 and 2 need to be defined such that a connection using the unique EmSvc identity is forwarded up through the architecture to the PONA. Some means to accurately provision/audit location in all nodes would improve accuracy and efficiency in handling 911 type calls.The SIP request from PONA to PSAP would follow established format for IETF ECRIT with possible modification for MAC/location chaining (list of terminal, intermediate node(s) and PONA MAC & Location).

Citizen to Authority

Citizen to Authority• PSAP Call Back for Emergency Services 911 type call using EmSvc Identity:

User

Terminal 802.11 Link

PONASwitch/Router

PSAP

1

4

32

For callback, the PSAP follows the MAC chain back to the originating terminal. This should work even for unauthenticated users.Use of the EmSvc Identity on the call back may require additional functionality in nodes and PONA.

Inte

rnet

802.16D Link

802.3 Link5

Node 2

Node 1

6

7

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 08-99 CMAS

– Canada: • CRTC 2007d Telecom Decision 2007-13.• CTRC 2007-20: Emergency alert services

– Japan: J Alert

Authority to Citizen

• Harmonization examples– IETF draft-baker-alert-system-00.txt

http://www.ietf.org/old/2009/proceedings/07mar/slides/ecrit-0/sld5.htm

– EC: ETSI EMTEL • EN 300 468: Service Information (SI) in DVB• TS 102 444 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)• < x, > 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

• 2007 2nd Report & Order and FNPRM (Next Generation EAS) • 2005 1st 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)• 1998 3rd Report & Order (Channel Override)• 1997 2nd 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 102 181 Requirements for communication between authorities/organizations during emergencies

– TR 170 001Project MESA;Service Specification Group - Services and Applications;Statement of Requirements (SoR)

– TR 170 002Project MESA;Service Specification Group - Services and Applications;Definitions, symbols and abbreviations

– TR 170 003Project MESA;Service Specification Group - Services and Applications;Basic requirementsTR 170 012Project MESA;Technical Specification Group - System;System Overview

– TR 102 653Project MESA; Technical Specification Group - System;System and Network Architecture

Citizen to Citizen

• TS 102 410: Basis of requirements for communications between individuals and between individuals and authorities whilst emergencies are in progress – 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.