TEMU 2016 - Emynos Workshop- Next Generation Emergency Communication

1. TEMU 2016
Workshop on Next Generation Emergency Communications
Dr. Evangelos Markakis
TEI of Crete
EMYNOS
nExt generation eMergencY
commuNicatiOnS

2.  Overview
 Limitations
 Objectives
 High level Concept
 Technologies Used
 WebRTC
 Linphone
 RTT
EMYNOS Outline
2

3.  EMYNOS: nExt generation eMergencY
commuNicatiOnS
 EMYNOS is a European project submitted to/
accepted in the call (H2020, Secure societies –
Protecting freedom and security of Europe and its
citizens)
 Website: http://www.emynos.eu/
 Project started: September 2015
 Duration: 30 months
EMYNOS: Overview

4. Participant No Participant organisation name Short name Country
1 (Coordinator) Fraunhofer Gesellschaft zur Förderung der
angewandten Forschung e.V.
Fraunhofer Germany
2 Turksat Turksat Turkey
3 (Tech.
Management)
Technological Educational Institute of Crete TEIC Greece
4 Navcert Navcert Germany
5 Public Safety Communication Europe PSCE Belgium
6 The Special Telecommunications Service STS Romania
7 Voztelecom Voz Spain
8 Harpo Sp. Z o.o. Harpo Poland
9 Hellenic Open University HOU Greece
10 Österreichisches Rotes Kreuz ARC Austria
11 MCS Data Labs MCS Germany
Research Institutes, 2 Operators, 2 End Users, 2 Universities, 4 SMEs,
Partners

5. • No Standard underlying technology
o Multiple Standards (Lack of Policy)
• No Multimedia(e.g. Video, Picture,)
o Based on PSTN, ISDN
• No Unified platform
o Among EU countries
Current Emergency Systems: Limitations 1/2

6. • No Advanced features: such as caller location
o Partially Implementation
• No Integration of social media
o Live Monitoring
• No IP-based eCall
o GSM Based Service
Current Emergency Systems: Limitations 2/2

7. EMYNOS Objectives 1/2
• A common Next Generation emergency
management platform that:
 addresses the limitations of today's Emergency Systems
 can manage both extreme emergency situations such as
natural disasters and terrorist attacks as well as usual
emergency situations (such as calls to ambulance and
police)
 Is standardized

8. EMYNOS Objectives 2/2
• A common Next Generation emergency
management platform that:
 Full support of new communication and information
technologies (mobile devices, photos, video, GPS,
WebRTC, etc)
 Accurate user/device position (civic address, geodetic
location)
 Special focus on disabled persons

9. EMYNOS Concept

10. Location information
10
• Location information encoding and retrieval is implemented in
EMYNOS according to the IETF standards
• Both Location-by-Value (LbyV) and Location-by-Reference (LbyR)
are implemented
• The LbyR concept applies where LbyV is not feasible or even
approved
• In LbyR, an identifier is provided by a location server and can be
used as a reference to a location object
• Both formats Geodesic and Civic are supported and encoded in
PIDF-LO objects (RFC 3863).
• SIP client on Android gets directly the GPS coordinates from the
mobile device
• Location Configuration Protocols (LCP) supported: DHCP, HELD,
and soon LLDP-MED

11. Location determination when using
WebRTC
11
• Browsers provide Geolocation API (specified by W3C)
• Usage is transparent to the application and can involve
different techniques and information depending on
the device:
 IP address
 Nearby/used Wifi network
 GPS

12. Use of WebRTC for Emergency Calling
 WebRTC: innovative technology for real time communication between
browsers
 WebRTC does not require any proprietary extension to be used in the browser
 Standardized by IETF RTCWeb working group and World Wide Web
Consortium (W3C)
 Allows to implement a SIP softphone as a webpage
 Emergency calling from the web

13. EMYNOS WebRTC Emergency client

14. EMYNOS WebRTC Emergency client

15. EMYNOS WebRTC Emergency client
• The web based emergency client uses standard SIP messages
(uses Websocket instead of UDP/TCP → requires capable SIP
proxy)
• Uses also the pre-defined emergency service URNs
• Location information is conveyed directly in the form of a
PIDF-LO
• Secure transport: WebRTC requires encrypted media transport
(DTLS-SRTP)

16. Support for Disabled People
Examples of messages composed
with the use of picture symbols
Sensors modules
 Total conversation (audio, video, real time text) provision
 Integration of total conversation with devices being used by
disabled people in their everyday activities
 Integration of total conversation with Set-top boxes to enable
emergency calls from TV monitors
 Emergency warnings alerts for disabled persons

17. e-Health Monitoring & Support
Sensor
Network
Call Origin Side
PSAP
Side
Emergency
Decision
Framework
All IP Network
(SIP/IMS)
Network
Side
XML
File
Set top Boxes
Smart phones
VoIP phones
WebRTC
Haptics
Home
GW
IP
SIP Proxy Location Server
Service
mappingWebRTC GW
Emergency Call Manager
IP
SIP Proxy
WebRTC
Data Analytics
Storage, Logging,
Recording
Emergency Services
Dispatcher
Border
GW

18. e-Health Monitoring & Support
EMYNOS envisions the support of persons with disabilities
with health monitoring sensor platforms and haptic devices.
Health sensors provide the status of a person to the emergency services.
Position sensors (i.e., a belt worn by the person of interest) identifies the position
of the persons’ torso.
In case the person looses its balance and drops, or the health sensors indicate a
vital measurement above critical thresholds, then an automated SIP-based
emergence call to the appropriate PSAP is initiated.
As already stated, parts of this information will be transmitted via the MSD and
therefore the MSD, as used in conventional eCall, has to be expanded.
The health monitored data will be incorporated in an enhanced Minimum Set of
Data (MSD) of an extended eCall, that will increase the knowledge base of the
first responders, regarding the status of the person involved.

19. eCall Enhancement
eCall: the emergency solution for vehicles in case of crash

20. Integration of Social Media
 Reach quickly a wider
audience
 Settle a trusted entity
for information and
facts dissemination
 Mobilize citizens and
incent them to
participate in the
safety activities
 Update the
population about an
event

21. Questions?

22. Backup Slides

23. <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gml="http://www.opengis.net/gml"
entity="pres:dc0e6d0bed4e33381fbb@10.147.67.244">
<dm:device id="test device">
<gp:geopriv>
<gp:location-info>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>52.5259087 13.3142924</gml:pos>
</gml:Point>
</gp:location-info>
<gp:usage-rules>
<gbp:retransmission-allowed>false</gbp:retransmission-allowed>
<gbp:retention-expiry>0116-07-20T14:26:53+01:00</gbp:retention-expiry>
</gp:usage-rules>
<gp:method>Held</gp:method>
</gp:geopriv>
<dm:timestamp>2016-07-19T14:26:53+02:00</dm:timestamp>
</dm:device>
</presence>
Location by Value (Geodetic)

24. Location by Value (Civic)
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gml="http://www.opengis.net/gml"
entity="pres:5a6526d62acbbba2af03@10.147.67.244">
<dm:person id="test person">
<gp:geopriv>
<gp:location-info>
<cl:civicAddress xml:lang="DE">
<cl:country>DE</cl:country>
<cl:A1>Berlin</cl:A1>
<cl:A3>Berlin</cl:A3>
<cl:RD>Kaiserin-Augusta</cl:RD>
<cl:STS>Allee</cl:STS>
<cl:HNO>31</cl:HNO>
<cl:FLR>5</cl:FLR>
<cl:NAM>eGov Lab</cl:NAM>
<cl:PC>10589</cl:PC>
</cl:civicAddress>

25. </gp:location-info>
<gp:usage-rules>
<gbp:retransmission-
allowed>false</gbp:retransmission-allowed>
<gbp:retention-expiry>0116-07-
20T14:26:53+01:00</gbp:retention-expiry>
</gp:usage-rules>
<gp:method>Held</gp:method>
</gp:geopriv>
<dm:timestamp>2016-07-
19T14:26:53+02:00</dm:timestamp>
</dm:person>
</presence>
Location by Value (Civic) cont.

26. <locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationURISet expires="0116-07-20T14:26:53+01:00">
<locationURI>http://10.147.67.244/pidflo/pidflo665b3175aff8ee089cd96c6357dc04e2256029d.xml</locatio
nURI>
</locationURISet>
</locationResponse>
Location by Reference

27. Emynos and AML
27
• In Emynos, we looked at AML, however, we have
several concerns,
• Concern 1: is PIDF-LO going to be used as a standard
for encoding the location information for instance
• Concern 2: It seems not all the European countries are
in favor of Location information provided by the end
device
• Concern 3: Can this be achieved at the application
level without interfering with the phone hardware
(switch on WiFi, check battery level, etc). The
involvement of mobile phones manufacturers seems to
be mandatory
• Concern 4: too restrictive as only mobile phones are
conserned. Hard phones will be still in use