Sharing MSD data across the rescue chain

Luca BergonziSales executive EMEA & AsiaBeta 80 Group

September 19-20, 2017

Agenda

• Interoperability among PSAPs

– PSAP models

– The concept of “Incident form”

– The proposed standard: CAP

• Interaction with TPSPs

– EN-16102 and beyond

– CAP for TPSPs

– Unsolved problems

Interoperability among PSAPs

3

Emergency call(eCall)

Call qualificationand localization

Dispatch

• Emergency call to 112

• Call taker qualifies the call and locates the caller

• Dispatcher sends the most appropriate resources

PSAP models

4

Model no.1 (France) Models no.2 & 3 (Italy, UK)

Model no.4 (Madrid, Spain) Model no.5 (Finland)

Model no.6 (Czech Republic)

The concept of “Incident form”

5

Incident form

Caller number Caller location Call qualification Other data

Names

Notes

Etc.

Etc.

Etc.

MSD

Data exchange today

6

eCall Call qualification and localization Dispatch

• eCall to 112

• Call taker creates an incident form

• Information is passed to the Dispatcher to send the most appropriate resources

Is often a proprietary format or just voice

MSDIncident form

Application of CAP

7

eCall Call qualification and localization Dispatch

• CAP “envelope”

• Open source format regulated by

• Readable by simple feed readers

• Message defined by profiles

MSDIncident form

CAP’d Incident form

Applying CAP to 112 models

8

Model no.1 (France) Models no.2 & 3 (Italy, UK)

Model no.4 (Madrid, Spain) Model no.5 (Finland)

Model no.6 (Czech Republic)

Applying CAP to 112 models

9

Model no.1 (France) Models no.2 & 3 (Italy, UK)

Model no.4 (Madrid, Spain) Model no.5 (Finland)

Model no.6 (Czech Republic)

Cross-border data exchange

MSD (incident form) into CAP: objectives and rationale

To design a Pan-European, flexible and extensible “CAP profile”, forexchanging eCall related information between PSAPs, with thefollowing principles:

– the CAP “envelope” will contain the information to• uniquely identify the messages

• link updates to the original alert, and

• specify the intended recipient(s)

– MSD (incident form) mandatory fields mapped and carriedwithin specific CAP fields, to be immediately accessible evenbefore decoding the whole MSD

– whole MSD content is carried as a “resource”

Results of the analysis #1 :MSD conformity

• Mapping of mandatory MSD fields– 16 out of 18 can be mapped onto CAP fields

– MSD “version” and “identifier” would be accessible after decoding the CAPMSD “resource”

• Mapping of optional and additional MSD fields– optional fields (e.g. number of passengers) can be mapped in specific CAP

extended fields dedicated to non conventional data

– Those data who don’t find specific placement in CAP extend fields are anywaycarried as original “resource” to be decoded by the PSAP

Results of the analysis #2:CAP conformity

• Mandatory CAP fields– most of them must be inserted by the sender, while

preparing the message for other PSAPs• these are the ones containing information about the sender and

the intended recipient(s), as well as the sending time of themessage

– other may be compiled using pre-defined values or rules• this is the case, for example, of alert.info.event and

alert.info.category fields

• Optional CAP fields– some of them, like the alert.info.headline, may be built from

some information available in the MSD message

Elements deserving further analysis

• Handling of MSD additional data

– HGV extended set of data to be addressed

– P2W eCall format to be adressed

Interaction with TPSPs

• Considerations based on EN 16102

PSAP

TPSP

PLMN

DATA

Data Gateway

VOICE

PBX

PBX

eCallApplication

TSDClient

Voice & Data

eCallApplication

Data

eCallModem

Data

Possible voice connection between PSAP and vehicle

occupants

PLMN

TSD Server

Vo

ice

Voice

Dat

aTr

ansf

er

Pan-European eCall

TPS eCall

TPSPs data exchange with PSAPs

TPSP 1

TPSP 2

TPSP 2

PSAP 1

PSAP 2

PSAP 3

EN 16102 transitional arrangement: web service pull mechanism (page 44, picture B.1)

• TSD information (MSD plus optional data) is published in a web service

• Availability of new emergency data is notified to the PSAP via voice call

• PSAP gets access to the web service, using the provided logincredentials

NO STANDARDISED INFORMATION STRUCTURE -> NOT SUITABLE FOR

MACHINE-TO-MACHINE INTERACTION

CAP messaging applied to TPS eCall

17

TPS eCall TPSP

• TPS eCall

• Operator creates an incident form

• Information is passed to the CAP webservice in EN16102 or otherformat

• PSAP retrieves his own CAP’d TPS form from the feed

TSD

EN16102 or other

PSAP

CAP web service

CAP’d TPS form

TSD into CAP: objectives and rationale

To design a Pan-European, flexible and extensible “CAP profile”, forexchanging eCall related information between PSAPs, with the followingprinciples:• All that was discussed about MSD to CAP conversion, plus:• Proposal based on EN 16102 XSD, but customizable• Includes:

– TPS-eCall-UID and TPS-eCall-SID fields– TPS callback number and Vehicle phone number fields– reference to the XSD of the enclosed MSD message, according to the EN

15722– reference to an additional XSD, describing the way of including Additional

Information

• The proposed Additional Information structure for TSD contains morethan 50 XML fields– no one of these fields is mandatory

TPSP 1

TPSP 2

TPSP 2

PSAP 1

PSAP 2

PSAP 3

TPSPs data exchange with PSAPs

Interaction using CAP

TPSP 1

TPSP 2

TPSP 2

PSAP 1

PSAP 2

PSAP 3

Elements deserving further analysis

• Formats different from EN 16102 can be mapped butneed analysis

• Creation of a registry of communicating TPSPs andPSAP authorities, and for the definition of theaddressing rules

– ownerships and maintenance issues

• Missing common PSAP E164 phone database registry

MSDin SIP payload

The future

What about CAP and the introduction of IMS network +NG 112 (NG eCall) ?

official NG 112 call (SIP extension for MSD, QoS, etc.) managed by IMSnetworks directly

“normal” VoIP call between PSAPs, not managed as NG 112 call (no QoS,no SIP extensions, etc.)

SIP eCall Call qualification and localization Dispatch

Incident form

CAP’d Incident form

Important reminderTPS to PSAP integration pilot site in Varese, Italy.

• Three different TPS will send their eCalls to the PSAP, who will seamlessly manage the received data, thanksto CAP integration.

• Period: 1st week of november (exact data TBD)• Everyone is invited to check the results.• Invite other TPSs to join as watchers• Contact me, Uberto Del Prato or Piero Brambilla for

details on the event.

The floor is open for discussion

24

Contact details:

Luca BergonziBeta 80 GroupeMail : luca.Bergonzi@beta80group.itPhone : +39 348 744 7059