TEMU 2016Workshop on Next Generation Emergency

CommunicationsDr. Evangelos Markakis

TEI of Crete

EMYNOSnExt generation eMergencY

commuNicatiOnS

Overview Limitations Objectives High level Concept Technologies Used

WebRTC Linphone RTT

EMYNOS Outline

2

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

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

• No Standard underlying technology o Multiple Standards (Lack of Policy)

• No Multimedia(e.g. Video, Picture,) o Based on PSTN, ISDN

• No Unified platformo Among EU countries

Current Emergency Systems: Limitations 1/2

• No Advanced features: such as caller locationo Partially Implementation

• No Integration of social mediao Live Monitoring

• No IP-based eCallo GSM Based Service

Current Emergency Systems: Limitations 2/2

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

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

EMYNOS Concept

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

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

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

EMYNOS WebRTC Emergency client

EMYNOS WebRTC Emergency client

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)

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

e-Health Monitoring & Support

Sensor Network

Call Origin SidePSAP Side

Emergency Decision

Framework

All IP Network (SIP/IMS)

Network Side

XMLFile

Set top Boxes

Smart phonesVoIP phones

WebRTC

Haptics

Home GW

IP

SIP Proxy Location ServerService

mappingWebRTC GW

Emergency Call Manager

IPSIP Proxy

WebRTC

Data Analytics

Storage, Logging,Recording

Emergency ServicesDispatcher

Border GW

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.

eCall EnhancementeCall: the emergency solution for vehicles in case of crash

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

Questions?

Backup Slides

<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)

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>

</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.

<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</locationURI> </locationURISet></locationResponse>

Location by Reference

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